Action not permitted
Modal body text goes here.
Modal Title
Modal Body
CVE-2024-49929 (GCVE-0-2024-49929)
Vulnerability from cvelistv5 – Published: 2024-10-21 18:01 – Updated: 2026-05-11 20:42| Vendor | Product | Version | CPE status | |
|---|---|---|---|---|
| Linux | Linux |
Affected:
5b577a90fb3d86447ee86f8e0c6ddbd5da2ef8c9 , < cbc6fc9cfcde151ff5eadaefdc6155f99579384f
(git)
Affected: 5b577a90fb3d86447ee86f8e0c6ddbd5da2ef8c9 , < 6dcadb2ed3b76623ab96e3e7fbeda1a374d01c28 (git) Affected: 5b577a90fb3d86447ee86f8e0c6ddbd5da2ef8c9 , < cdbf51bfa4b0411820806777da36d93d49bc49a1 (git) Affected: 5b577a90fb3d86447ee86f8e0c6ddbd5da2ef8c9 , < c0b4f5d94934c290479180868a32c15ba36a6d9e (git) Affected: 5b577a90fb3d86447ee86f8e0c6ddbd5da2ef8c9 , < 557a6cd847645e667f3b362560bd7e7c09aac284 (git) |
guessed | |
| Linux | Linux |
Affected:
3.14
Unaffected: 0 , < 3.14 (semver) Unaffected: 6.1.120 , ≤ 6.1.* (semver) Unaffected: 6.6.55 , ≤ 6.6.* (semver) Unaffected: 6.10.14 , ≤ 6.10.* (semver) Unaffected: 6.11.3 , ≤ 6.11.* (semver) Unaffected: 6.12 , ≤ * (original_commit_for_fix) |
guessed |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2024-49929",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2024-10-22T13:39:18.933944Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2024-10-22T13:48:43.528Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
},
{
"providerMetadata": {
"dateUpdated": "2025-11-03T20:42:04.998Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00001.html"
}
],
"title": "CVE Program Container"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/net/wireless/intel/iwlwifi/mvm/tx.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "cbc6fc9cfcde151ff5eadaefdc6155f99579384f",
"status": "affected",
"version": "5b577a90fb3d86447ee86f8e0c6ddbd5da2ef8c9",
"versionType": "git"
},
{
"lessThan": "6dcadb2ed3b76623ab96e3e7fbeda1a374d01c28",
"status": "affected",
"version": "5b577a90fb3d86447ee86f8e0c6ddbd5da2ef8c9",
"versionType": "git"
},
{
"lessThan": "cdbf51bfa4b0411820806777da36d93d49bc49a1",
"status": "affected",
"version": "5b577a90fb3d86447ee86f8e0c6ddbd5da2ef8c9",
"versionType": "git"
},
{
"lessThan": "c0b4f5d94934c290479180868a32c15ba36a6d9e",
"status": "affected",
"version": "5b577a90fb3d86447ee86f8e0c6ddbd5da2ef8c9",
"versionType": "git"
},
{
"lessThan": "557a6cd847645e667f3b362560bd7e7c09aac284",
"status": "affected",
"version": "5b577a90fb3d86447ee86f8e0c6ddbd5da2ef8c9",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/net/wireless/intel/iwlwifi/mvm/tx.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "3.14"
},
{
"lessThan": "3.14",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.120",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.55",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.10.*",
"status": "unaffected",
"version": "6.10.14",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.11.*",
"status": "unaffected",
"version": "6.11.3",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.12",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.1.120",
"versionStartIncluding": "3.14",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6.55",
"versionStartIncluding": "3.14",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.10.14",
"versionStartIncluding": "3.14",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.11.3",
"versionStartIncluding": "3.14",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.12",
"versionStartIncluding": "3.14",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: iwlwifi: mvm: avoid NULL pointer dereference\n\niwl_mvm_tx_skb_sta() and iwl_mvm_tx_mpdu() verify that the mvmvsta\npointer is not NULL.\nIt retrieves this pointer using iwl_mvm_sta_from_mac80211, which is\ndereferencing the ieee80211_sta pointer.\nIf sta is NULL, iwl_mvm_sta_from_mac80211 will dereference a NULL\npointer.\nFix this by checking the sta pointer before retrieving the mvmsta\nfrom it. If sta is not NULL, then mvmsta isn\u0027t either."
}
],
"providerMetadata": {
"dateUpdated": "2026-05-11T20:42:00.819Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/cbc6fc9cfcde151ff5eadaefdc6155f99579384f"
},
{
"url": "https://git.kernel.org/stable/c/6dcadb2ed3b76623ab96e3e7fbeda1a374d01c28"
},
{
"url": "https://git.kernel.org/stable/c/cdbf51bfa4b0411820806777da36d93d49bc49a1"
},
{
"url": "https://git.kernel.org/stable/c/c0b4f5d94934c290479180868a32c15ba36a6d9e"
},
{
"url": "https://git.kernel.org/stable/c/557a6cd847645e667f3b362560bd7e7c09aac284"
}
],
"title": "wifi: iwlwifi: mvm: avoid NULL pointer dereference",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2024-49929",
"datePublished": "2024-10-21T18:01:52.450Z",
"dateReserved": "2024-10-21T12:17:06.039Z",
"dateUpdated": "2026-05-11T20:42:00.819Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"epss": {
"cve": "CVE-2024-49929",
"date": "2026-09-28",
"epss": "0.00238",
"percentile": "0.13323"
},
"nvd": {
"cve": {
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/net/wireless/intel/iwlwifi/mvm/tx.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "cbc6fc9cfcde151ff5eadaefdc6155f99579384f",
"status": "affected",
"version": "5b577a90fb3d86447ee86f8e0c6ddbd5da2ef8c9",
"versionType": "git"
},
{
"lessThan": "6dcadb2ed3b76623ab96e3e7fbeda1a374d01c28",
"status": "affected",
"version": "5b577a90fb3d86447ee86f8e0c6ddbd5da2ef8c9",
"versionType": "git"
},
{
"lessThan": "cdbf51bfa4b0411820806777da36d93d49bc49a1",
"status": "affected",
"version": "5b577a90fb3d86447ee86f8e0c6ddbd5da2ef8c9",
"versionType": "git"
},
{
"lessThan": "c0b4f5d94934c290479180868a32c15ba36a6d9e",
"status": "affected",
"version": "5b577a90fb3d86447ee86f8e0c6ddbd5da2ef8c9",
"versionType": "git"
},
{
"lessThan": "557a6cd847645e667f3b362560bd7e7c09aac284",
"status": "affected",
"version": "5b577a90fb3d86447ee86f8e0c6ddbd5da2ef8c9",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/net/wireless/intel/iwlwifi/mvm/tx.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "3.14"
},
{
"lessThan": "3.14",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.120",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.55",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.10.*",
"status": "unaffected",
"version": "6.10.14",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.11.*",
"status": "unaffected",
"version": "6.11.3",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.12",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"configurations": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "8B527B5F-BDDA-424E-932E-16FCAAB575E2",
"versionEndExcluding": "6.6.55",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "4C16BCE0-FFA0-4599-BE0A-1FD65101C021",
"versionEndExcluding": "6.10.14",
"versionStartIncluding": "6.7",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "54D9C704-D679-41A7-9C40-10A6B1E7FFE9",
"versionEndExcluding": "6.11.3",
"versionStartIncluding": "6.11",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: iwlwifi: mvm: avoid NULL pointer dereference\n\niwl_mvm_tx_skb_sta() and iwl_mvm_tx_mpdu() verify that the mvmvsta\npointer is not NULL.\nIt retrieves this pointer using iwl_mvm_sta_from_mac80211, which is\ndereferencing the ieee80211_sta pointer.\nIf sta is NULL, iwl_mvm_sta_from_mac80211 will dereference a NULL\npointer.\nFix this by checking the sta pointer before retrieving the mvmsta\nfrom it. If sta is not NULL, then mvmsta isn\u0027t either."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: iwlwifi: mvm: evitar la desreferencia del puntero NULL iwl_mvm_tx_skb_sta() e iwl_mvm_tx_mpdu() verifican que el puntero mvmvsta no sea NULL. Recupera este puntero utilizando iwl_mvm_sta_from_mac80211, que est\u00e1 desreferenciando el puntero ieee80211_sta. Si sta es NULL, iwl_mvm_sta_from_mac80211 desreferenciar\u00e1 un puntero NULL. Solucione esto comprobando el puntero sta antes de recuperar el mvmsta de \u00e9l. Si sta no es NULL, entonces mvmsta tampoco lo es."
}
],
"id": "CVE-2024-49929",
"lastModified": "2026-06-17T08:00:45.277",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 5.5,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 3.6,
"source": "nvd@nist.gov",
"type": "Primary"
}
],
"ssvcV203": [
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"ssvcData": {
"id": "CVE-2024-49929",
"options": [
{
"exploitation": "none"
},
{
"automatable": "no"
},
{
"technicalImpact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2024-10-22T13:39:18.933944Z",
"version": "2.0.3"
}
}
]
},
"published": "2024-10-21T18:15:14.907",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/557a6cd847645e667f3b362560bd7e7c09aac284"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/6dcadb2ed3b76623ab96e3e7fbeda1a374d01c28"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/c0b4f5d94934c290479180868a32c15ba36a6d9e"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/cbc6fc9cfcde151ff5eadaefdc6155f99579384f"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/cdbf51bfa4b0411820806777da36d93d49bc49a1"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00001.html"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Modified",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "CWE-476"
}
],
"source": "nvd@nist.gov",
"type": "Primary"
}
]
}
},
"redhat_vex": {
"aggregate_severity": "Moderate",
"current_release_date": "2026-09-09T16:10:56+00:00",
"cve": "CVE-2024-49929",
"id": "CVE-2024-49929",
"initial_release_date": "2024-10-21T00:00:00+00:00",
"product_status:fixed": "305",
"product_status:known_affected": "98",
"product_status:known_not_affected": "14",
"source": "Red Hat CSAF VEX",
"status": "final",
"title": "kernel: wifi: iwlwifi: mvm: avoid NULL pointer dereference",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2024/cve-2024-49929.json",
"version": "3"
},
"vulnrichment": {
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2024-49929",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2024-10-22T13:39:18.933944Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2024-10-22T13:39:21.998Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/net/wireless/intel/iwlwifi/mvm/tx.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "cbc6fc9cfcde151ff5eadaefdc6155f99579384f",
"status": "affected",
"version": "5b577a90fb3d86447ee86f8e0c6ddbd5da2ef8c9",
"versionType": "git"
},
{
"lessThan": "6dcadb2ed3b76623ab96e3e7fbeda1a374d01c28",
"status": "affected",
"version": "5b577a90fb3d86447ee86f8e0c6ddbd5da2ef8c9",
"versionType": "git"
},
{
"lessThan": "cdbf51bfa4b0411820806777da36d93d49bc49a1",
"status": "affected",
"version": "5b577a90fb3d86447ee86f8e0c6ddbd5da2ef8c9",
"versionType": "git"
},
{
"lessThan": "c0b4f5d94934c290479180868a32c15ba36a6d9e",
"status": "affected",
"version": "5b577a90fb3d86447ee86f8e0c6ddbd5da2ef8c9",
"versionType": "git"
},
{
"lessThan": "557a6cd847645e667f3b362560bd7e7c09aac284",
"status": "affected",
"version": "5b577a90fb3d86447ee86f8e0c6ddbd5da2ef8c9",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/net/wireless/intel/iwlwifi/mvm/tx.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "3.14"
},
{
"lessThan": "3.14",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.120",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.55",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.10.*",
"status": "unaffected",
"version": "6.10.14",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.11.*",
"status": "unaffected",
"version": "6.11.3",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.12",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.1.120",
"versionStartIncluding": "3.14",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6.55",
"versionStartIncluding": "3.14",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.10.14",
"versionStartIncluding": "3.14",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.11.3",
"versionStartIncluding": "3.14",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.12",
"versionStartIncluding": "3.14",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: iwlwifi: mvm: avoid NULL pointer dereference\n\niwl_mvm_tx_skb_sta() and iwl_mvm_tx_mpdu() verify that the mvmvsta\npointer is not NULL.\nIt retrieves this pointer using iwl_mvm_sta_from_mac80211, which is\ndereferencing the ieee80211_sta pointer.\nIf sta is NULL, iwl_mvm_sta_from_mac80211 will dereference a NULL\npointer.\nFix this by checking the sta pointer before retrieving the mvmsta\nfrom it. If sta is not NULL, then mvmsta isn\u0027t either."
}
],
"providerMetadata": {
"dateUpdated": "2025-05-21T09:13:23.151Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/cbc6fc9cfcde151ff5eadaefdc6155f99579384f"
},
{
"url": "https://git.kernel.org/stable/c/6dcadb2ed3b76623ab96e3e7fbeda1a374d01c28"
},
{
"url": "https://git.kernel.org/stable/c/cdbf51bfa4b0411820806777da36d93d49bc49a1"
},
{
"url": "https://git.kernel.org/stable/c/c0b4f5d94934c290479180868a32c15ba36a6d9e"
},
{
"url": "https://git.kernel.org/stable/c/557a6cd847645e667f3b362560bd7e7c09aac284"
}
],
"title": "wifi: iwlwifi: mvm: avoid NULL pointer dereference",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2024-49929",
"datePublished": "2024-10-21T18:01:52.450Z",
"dateReserved": "2024-10-21T12:17:06.039Z",
"dateUpdated": "2025-05-21T09:13:23.151Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.1"
}
}
}
CERTFR-2025-AVI-0366
Vulnerability from certfr_avis - Published: 2025-05-02 - Updated: 2025-05-02
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, une élévation de privilèges 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 24.04 LTS",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 20.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-26928",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26928"
},
{
"name": "CVE-2024-35864",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35864"
},
{
"name": "CVE-2024-36899",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36899"
},
{
"name": "CVE-2024-26837",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26837"
},
{
"name": "CVE-2024-41014",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41014"
},
{
"name": "CVE-2024-41016",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41016"
},
{
"name": "CVE-2024-42122",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42122"
},
{
"name": "CVE-2024-42315",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42315"
},
{
"name": "CVE-2024-43900",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43900"
},
{
"name": "CVE-2024-44938",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44938"
},
{
"name": "CVE-2024-46784",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46784"
},
{
"name": "CVE-2024-46826",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46826"
},
{
"name": "CVE-2024-46809",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46809"
},
{
"name": "CVE-2024-46841",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46841"
},
{
"name": "CVE-2024-46871",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46871"
},
{
"name": "CVE-2024-47670",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47670"
},
{
"name": "CVE-2024-47671",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47671"
},
{
"name": "CVE-2024-47672",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47672"
},
{
"name": "CVE-2024-47673",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47673"
},
{
"name": "CVE-2024-47684",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47684"
},
{
"name": "CVE-2024-47685",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47685"
},
{
"name": "CVE-2024-47692",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47692"
},
{
"name": "CVE-2024-47693",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47693"
},
{
"name": "CVE-2024-47695",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47695"
},
{
"name": "CVE-2024-47696",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47696"
},
{
"name": "CVE-2024-47697",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47697"
},
{
"name": "CVE-2024-47698",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47698"
},
{
"name": "CVE-2024-47699",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47699"
},
{
"name": "CVE-2024-47704",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47704"
},
{
"name": "CVE-2024-47705",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47705"
},
{
"name": "CVE-2024-47706",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47706"
},
{
"name": "CVE-2024-47707",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47707"
},
{
"name": "CVE-2024-47709",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47709"
},
{
"name": "CVE-2024-47710",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47710"
},
{
"name": "CVE-2024-47712",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47712"
},
{
"name": "CVE-2024-47713",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47713"
},
{
"name": "CVE-2024-47718",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47718"
},
{
"name": "CVE-2024-47720",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47720"
},
{
"name": "CVE-2024-47723",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47723"
},
{
"name": "CVE-2024-47728",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47728"
},
{
"name": "CVE-2024-47730",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47730"
},
{
"name": "CVE-2024-47735",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47735"
},
{
"name": "CVE-2024-47737",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47737"
},
{
"name": "CVE-2024-47738",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47738"
},
{
"name": "CVE-2024-47739",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47739"
},
{
"name": "CVE-2024-47742",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47742"
},
{
"name": "CVE-2024-47745",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47745"
},
{
"name": "CVE-2024-47747",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47747"
},
{
"name": "CVE-2024-47748",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47748"
},
{
"name": "CVE-2024-47749",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47749"
},
{
"name": "CVE-2024-47756",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47756"
},
{
"name": "CVE-2024-47757",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47757"
},
{
"name": "CVE-2024-49851",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49851"
},
{
"name": "CVE-2024-49852",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49852"
},
{
"name": "CVE-2024-49855",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49855"
},
{
"name": "CVE-2024-49858",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49858"
},
{
"name": "CVE-2024-49860",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49860"
},
{
"name": "CVE-2024-49861",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49861"
},
{
"name": "CVE-2024-49863",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49863"
},
{
"name": "CVE-2024-49866",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49866"
},
{
"name": "CVE-2024-49867",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49867"
},
{
"name": "CVE-2024-49870",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49870"
},
{
"name": "CVE-2024-49871",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49871"
},
{
"name": "CVE-2024-49875",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49875"
},
{
"name": "CVE-2024-49877",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49877"
},
{
"name": "CVE-2024-49878",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49878"
},
{
"name": "CVE-2024-49879",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49879"
},
{
"name": "CVE-2024-49881",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49881"
},
{
"name": "CVE-2024-49882",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49882"
},
{
"name": "CVE-2024-49883",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49883"
},
{
"name": "CVE-2024-49886",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49886"
},
{
"name": "CVE-2024-49888",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49888"
},
{
"name": "CVE-2024-49890",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49890"
},
{
"name": "CVE-2024-49891",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49891"
},
{
"name": "CVE-2024-49892",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49892"
},
{
"name": "CVE-2024-49894",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49894"
},
{
"name": "CVE-2024-49895",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49895"
},
{
"name": "CVE-2024-49896",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49896"
},
{
"name": "CVE-2024-49898",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49898"
},
{
"name": "CVE-2024-49899",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49899"
},
{
"name": "CVE-2024-49900",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49900"
},
{
"name": "CVE-2024-49901",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49901"
},
{
"name": "CVE-2024-49902",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49902"
},
{
"name": "CVE-2024-49903",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49903"
},
{
"name": "CVE-2024-49906",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49906"
},
{
"name": "CVE-2024-49907",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49907"
},
{
"name": "CVE-2024-49909",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49909"
},
{
"name": "CVE-2024-49911",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49911"
},
{
"name": "CVE-2024-49912",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49912"
},
{
"name": "CVE-2024-49913",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49913"
},
{
"name": "CVE-2024-49914",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49914"
},
{
"name": "CVE-2024-49917",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49917"
},
{
"name": "CVE-2024-49918",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49918"
},
{
"name": "CVE-2024-49919",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49919"
},
{
"name": "CVE-2024-49920",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49920"
},
{
"name": "CVE-2024-49922",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49922"
},
{
"name": "CVE-2024-49923",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49923"
},
{
"name": "CVE-2024-49928",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49928"
},
{
"name": "CVE-2024-49929",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49929"
},
{
"name": "CVE-2024-49930",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49930"
},
{
"name": "CVE-2024-49931",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49931"
},
{
"name": "CVE-2024-49933",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49933"
},
{
"name": "CVE-2024-49935",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49935"
},
{
"name": "CVE-2024-49936",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49936"
},
{
"name": "CVE-2024-49937",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49937"
},
{
"name": "CVE-2024-49938",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49938"
},
{
"name": "CVE-2024-49939",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49939"
},
{
"name": "CVE-2024-49946",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49946"
},
{
"name": "CVE-2024-49949",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49949"
},
{
"name": "CVE-2024-49950",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49950"
},
{
"name": "CVE-2024-49954",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49954"
},
{
"name": "CVE-2024-49955",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49955"
},
{
"name": "CVE-2024-49957",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49957"
},
{
"name": "CVE-2024-49958",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49958"
},
{
"name": "CVE-2024-49959",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49959"
},
{
"name": "CVE-2024-49960",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49960"
},
{
"name": "CVE-2024-49961",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49961"
},
{
"name": "CVE-2024-49962",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49962"
},
{
"name": "CVE-2024-49963",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49963"
},
{
"name": "CVE-2024-49965",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49965"
},
{
"name": "CVE-2024-49966",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49966"
},
{
"name": "CVE-2024-49969",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49969"
},
{
"name": "CVE-2024-49972",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49972"
},
{
"name": "CVE-2024-49973",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49973"
},
{
"name": "CVE-2024-49974",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49974"
},
{
"name": "CVE-2024-49975",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49975"
},
{
"name": "CVE-2024-49981",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49981"
},
{
"name": "CVE-2024-49982",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49982"
},
{
"name": "CVE-2024-49985",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49985"
},
{
"name": "CVE-2024-49991",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49991"
},
{
"name": "CVE-2024-49996",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49996"
},
{
"name": "CVE-2024-50000",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50000"
},
{
"name": "CVE-2024-50001",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50001"
},
{
"name": "CVE-2024-50002",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50002"
},
{
"name": "CVE-2024-50006",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50006"
},
{
"name": "CVE-2024-50007",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50007"
},
{
"name": "CVE-2024-50008",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50008"
},
{
"name": "CVE-2024-50013",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50013"
},
{
"name": "CVE-2024-50014",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50014"
},
{
"name": "CVE-2024-50015",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50015"
},
{
"name": "CVE-2024-50017",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50017"
},
{
"name": "CVE-2024-50019",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50019"
},
{
"name": "CVE-2024-50020",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50020"
},
{
"name": "CVE-2024-50021",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50021"
},
{
"name": "CVE-2024-50022",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50022"
},
{
"name": "CVE-2024-50023",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50023"
},
{
"name": "CVE-2024-50024",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50024"
},
{
"name": "CVE-2024-50025",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50025"
},
{
"name": "CVE-2024-50027",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50027"
},
{
"name": "CVE-2024-50028",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50028"
},
{
"name": "CVE-2024-50031",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50031"
},
{
"name": "CVE-2024-50033",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50033"
},
{
"name": "CVE-2024-50035",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50035"
},
{
"name": "CVE-2024-50040",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50040"
},
{
"name": "CVE-2024-50041",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50041"
},
{
"name": "CVE-2024-50042",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50042"
},
{
"name": "CVE-2024-50044",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50044"
},
{
"name": "CVE-2024-50045",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50045"
},
{
"name": "CVE-2024-50046",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50046"
},
{
"name": "CVE-2024-50047",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50047"
},
{
"name": "CVE-2024-50048",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50048"
},
{
"name": "CVE-2024-50049",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50049"
},
{
"name": "CVE-2024-50055",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50055"
},
{
"name": "CVE-2024-50058",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50058"
},
{
"name": "CVE-2024-50059",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50059"
},
{
"name": "CVE-2024-50060",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50060"
},
{
"name": "CVE-2024-50061",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50061"
},
{
"name": "CVE-2024-50062",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50062"
},
{
"name": "CVE-2024-50063",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50063"
},
{
"name": "CVE-2024-50064",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50064"
},
{
"name": "CVE-2024-50069",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50069"
},
{
"name": "CVE-2024-50073",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50073"
},
{
"name": "CVE-2024-50074",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50074"
},
{
"name": "CVE-2024-50075",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50075"
},
{
"name": "CVE-2024-50076",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50076"
},
{
"name": "CVE-2024-50077",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50077"
},
{
"name": "CVE-2024-50078",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50078"
},
{
"name": "CVE-2024-50080",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50080"
},
{
"name": "CVE-2024-50012",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50012"
},
{
"name": "CVE-2024-50036",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50036"
},
{
"name": "CVE-2024-50067",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50067"
},
{
"name": "CVE-2024-50072",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50072"
},
{
"name": "CVE-2024-50126",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50126"
},
{
"name": "CVE-2024-50215",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50215"
},
{
"name": "CVE-2024-50218",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50218"
},
{
"name": "CVE-2024-50229",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50229"
},
{
"name": "CVE-2024-50230",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50230"
},
{
"name": "CVE-2024-50232",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50232"
},
{
"name": "CVE-2024-50233",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50233"
},
{
"name": "CVE-2024-50234",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50234"
},
{
"name": "CVE-2024-50235",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50235"
},
{
"name": "CVE-2024-50236",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50236"
},
{
"name": "CVE-2024-50237",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50237"
},
{
"name": "CVE-2024-50242",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50242"
},
{
"name": "CVE-2024-50243",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50243"
},
{
"name": "CVE-2024-50244",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50244"
},
{
"name": "CVE-2024-50245",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50245"
},
{
"name": "CVE-2024-50247",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50247"
},
{
"name": "CVE-2024-50250",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50250"
},
{
"name": "CVE-2024-50251",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50251"
},
{
"name": "CVE-2024-50252",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50252"
},
{
"name": "CVE-2024-50255",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50255"
},
{
"name": "CVE-2024-50256",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50256"
},
{
"name": "CVE-2024-50257",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50257"
},
{
"name": "CVE-2024-50259",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50259"
},
{
"name": "CVE-2024-50261",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50261"
},
{
"name": "CVE-2024-50262",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50262"
},
{
"name": "CVE-2024-50265",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50265"
},
{
"name": "CVE-2024-50267",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50267"
},
{
"name": "CVE-2024-50268",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50268"
},
{
"name": "CVE-2024-50269",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50269"
},
{
"name": "CVE-2024-50271",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50271"
},
{
"name": "CVE-2024-50272",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50272"
},
{
"name": "CVE-2024-50273",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50273"
},
{
"name": "CVE-2024-50276",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50276"
},
{
"name": "CVE-2024-50278",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50278"
},
{
"name": "CVE-2024-50279",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50279"
},
{
"name": "CVE-2024-50280",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50280"
},
{
"name": "CVE-2024-50282",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50282"
},
{
"name": "CVE-2024-50283",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50283"
},
{
"name": "CVE-2024-50284",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50284"
},
{
"name": "CVE-2024-50286",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50286"
},
{
"name": "CVE-2024-50287",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50287"
},
{
"name": "CVE-2024-50290",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50290"
},
{
"name": "CVE-2024-50292",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50292"
},
{
"name": "CVE-2024-50295",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50295"
},
{
"name": "CVE-2024-50296",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50296"
},
{
"name": "CVE-2024-50299",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50299"
},
{
"name": "CVE-2024-50301",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50301"
},
{
"name": "CVE-2024-50302",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50302"
},
{
"name": "CVE-2024-53042",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53042"
},
{
"name": "CVE-2024-53043",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53043"
},
{
"name": "CVE-2024-53052",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53052"
},
{
"name": "CVE-2024-53055",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53055"
},
{
"name": "CVE-2024-53058",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53058"
},
{
"name": "CVE-2024-53059",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53059"
},
{
"name": "CVE-2024-53061",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53061"
},
{
"name": "CVE-2024-53063",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53063"
},
{
"name": "CVE-2024-53066",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53066"
},
{
"name": "CVE-2024-53072",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53072"
},
{
"name": "CVE-2024-53081",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53081"
},
{
"name": "CVE-2024-53082",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53082"
},
{
"name": "CVE-2024-53088",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53088"
},
{
"name": "CVE-2024-53093",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53093"
},
{
"name": "CVE-2024-50226",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50226"
},
{
"name": "CVE-2024-49925",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49925"
},
{
"name": "CVE-2024-49945",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49945"
},
{
"name": "CVE-2024-50208",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50208"
},
{
"name": "CVE-2024-50082",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50082"
},
{
"name": "CVE-2024-50099",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50099"
},
{
"name": "CVE-2024-50110",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50110"
},
{
"name": "CVE-2024-50142",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50142"
},
{
"name": "CVE-2024-50192",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50192"
},
{
"name": "CVE-2024-47679",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47679"
},
{
"name": "CVE-2024-47690",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47690"
},
{
"name": "CVE-2024-47701",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47701"
},
{
"name": "CVE-2024-47734",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47734"
},
{
"name": "CVE-2024-47740",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47740"
},
{
"name": "CVE-2024-49856",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49856"
},
{
"name": "CVE-2024-49868",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49868"
},
{
"name": "CVE-2024-49884",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49884"
},
{
"name": "CVE-2024-49889",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49889"
},
{
"name": "CVE-2024-49893",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49893"
},
{
"name": "CVE-2024-49905",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49905"
},
{
"name": "CVE-2024-49915",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49915"
},
{
"name": "CVE-2024-49921",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49921"
},
{
"name": "CVE-2024-49924",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49924"
},
{
"name": "CVE-2024-49927",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49927"
},
{
"name": "CVE-2024-49944",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49944"
},
{
"name": "CVE-2024-49948",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49948"
},
{
"name": "CVE-2024-49952",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49952"
},
{
"name": "CVE-2024-49977",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49977"
},
{
"name": "CVE-2024-49983",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49983"
},
{
"name": "CVE-2024-49997",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49997"
},
{
"name": "CVE-2024-50038",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50038"
},
{
"name": "CVE-2024-50039",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50039"
},
{
"name": "CVE-2024-50093",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50093"
},
{
"name": "CVE-2024-50095",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50095"
},
{
"name": "CVE-2024-50096",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50096"
},
{
"name": "CVE-2024-50179",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50179"
},
{
"name": "CVE-2024-50180",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50180"
},
{
"name": "CVE-2024-50184",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50184"
},
{
"name": "CVE-2024-50186",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50186"
},
{
"name": "CVE-2024-50188",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50188"
},
{
"name": "CVE-2024-50189",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50189"
},
{
"name": "CVE-2024-50191",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50191"
},
{
"name": "CVE-2024-47703",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47703"
},
{
"name": "CVE-2024-49934",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49934"
},
{
"name": "CVE-2024-49968",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49968"
},
{
"name": "CVE-2024-49987",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49987"
},
{
"name": "CVE-2024-49989",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49989"
},
{
"name": "CVE-2024-50009",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50009"
},
{
"name": "CVE-2024-50026",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50026"
},
{
"name": "CVE-2024-50084",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50084"
},
{
"name": "CVE-2024-50087",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50087"
},
{
"name": "CVE-2024-50088",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50088"
},
{
"name": "CVE-2024-50098",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50098"
},
{
"name": "CVE-2024-50101",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50101"
},
{
"name": "CVE-2024-50103",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50103"
},
{
"name": "CVE-2024-50108",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50108"
},
{
"name": "CVE-2024-50115",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50115"
},
{
"name": "CVE-2024-50116",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50116"
},
{
"name": "CVE-2024-50117",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50117"
},
{
"name": "CVE-2024-50121",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50121"
},
{
"name": "CVE-2024-50124",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50124"
},
{
"name": "CVE-2024-50125",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50125"
},
{
"name": "CVE-2024-50127",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50127"
},
{
"name": "CVE-2024-50128",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50128"
},
{
"name": "CVE-2024-50130",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50130"
},
{
"name": "CVE-2024-50131",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50131"
},
{
"name": "CVE-2024-50134",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50134"
},
{
"name": "CVE-2024-50135",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50135"
},
{
"name": "CVE-2024-50136",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50136"
},
{
"name": "CVE-2024-50138",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50138"
},
{
"name": "CVE-2024-50139",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50139"
},
{
"name": "CVE-2024-50141",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50141"
},
{
"name": "CVE-2024-50145",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50145"
},
{
"name": "CVE-2024-50146",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50146"
},
{
"name": "CVE-2024-50147",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50147"
},
{
"name": "CVE-2024-50148",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50148"
},
{
"name": "CVE-2024-50150",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50150"
},
{
"name": "CVE-2024-50153",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50153"
},
{
"name": "CVE-2024-50154",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50154"
},
{
"name": "CVE-2024-50155",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50155"
},
{
"name": "CVE-2024-50156",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50156"
},
{
"name": "CVE-2024-50158",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50158"
},
{
"name": "CVE-2024-50159",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50159"
},
{
"name": "CVE-2024-50160",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50160"
},
{
"name": "CVE-2024-50166",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50166"
},
{
"name": "CVE-2024-50167",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50167"
},
{
"name": "CVE-2024-50169",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50169"
},
{
"name": "CVE-2024-50171",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50171"
},
{
"name": "CVE-2024-50172",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50172"
},
{
"name": "CVE-2024-50182",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50182"
},
{
"name": "CVE-2024-50183",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50183"
},
{
"name": "CVE-2024-50187",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50187"
},
{
"name": "CVE-2024-50194",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50194"
},
{
"name": "CVE-2024-50195",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50195"
},
{
"name": "CVE-2024-50196",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50196"
},
{
"name": "CVE-2024-50198",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50198"
},
{
"name": "CVE-2024-50200",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50200"
},
{
"name": "CVE-2024-50201",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50201"
},
{
"name": "CVE-2024-50205",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50205"
},
{
"name": "CVE-2024-50209",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50209"
},
{
"name": "CVE-2024-50216",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50216"
},
{
"name": "CVE-2024-50221",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50221"
},
{
"name": "CVE-2024-50224",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50224"
},
{
"name": "CVE-2024-50225",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50225"
},
{
"name": "CVE-2024-50231",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50231"
},
{
"name": "CVE-2024-50240",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50240"
},
{
"name": "CVE-2024-50246",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50246"
},
{
"name": "CVE-2024-50248",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50248"
},
{
"name": "CVE-2024-50274",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50274"
},
{
"name": "CVE-2024-50275",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50275"
},
{
"name": "CVE-2024-50289",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50289"
},
{
"name": "CVE-2024-50298",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50298"
},
{
"name": "CVE-2024-53045",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53045"
},
{
"name": "CVE-2024-53048",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53048"
},
{
"name": "CVE-2024-53051",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53051"
},
{
"name": "CVE-2024-53068",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53068"
},
{
"name": "CVE-2024-53076",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53076"
},
{
"name": "CVE-2024-53079",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53079"
},
{
"name": "CVE-2024-53085",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53085"
},
{
"name": "CVE-2024-53094",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53094"
},
{
"name": "CVE-2024-53095",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53095"
},
{
"name": "CVE-2024-53096",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53096"
},
{
"name": "CVE-2024-53100",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53100"
},
{
"name": "CVE-2024-53101",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53101"
},
{
"name": "CVE-2024-53104",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53104"
},
{
"name": "CVE-2024-53106",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53106"
},
{
"name": "CVE-2024-53108",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53108"
},
{
"name": "CVE-2024-53110",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53110"
},
{
"name": "CVE-2024-53112",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53112"
},
{
"name": "CVE-2024-53114",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53114"
},
{
"name": "CVE-2024-53121",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53121"
},
{
"name": "CVE-2024-53138",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53138"
},
{
"name": "CVE-2024-53142",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53142"
},
{
"name": "CVE-2024-47678",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47678"
},
{
"name": "CVE-2024-49859",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49859"
},
{
"name": "CVE-2024-49978",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49978"
},
{
"name": "CVE-2024-49992",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49992"
},
{
"name": "CVE-2024-50010",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50010"
},
{
"name": "CVE-2024-50083",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50083"
},
{
"name": "CVE-2024-50085",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50085"
},
{
"name": "CVE-2024-50086",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50086"
},
{
"name": "CVE-2024-50133",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50133"
},
{
"name": "CVE-2024-50143",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50143"
},
{
"name": "CVE-2024-50151",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50151"
},
{
"name": "CVE-2024-50162",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50162"
},
{
"name": "CVE-2024-50163",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50163"
},
{
"name": "CVE-2024-50168",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50168"
},
{
"name": "CVE-2024-50185",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50185"
},
{
"name": "CVE-2024-50193",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50193"
},
{
"name": "CVE-2024-50199",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50199"
},
{
"name": "CVE-2024-50202",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50202"
},
{
"name": "CVE-2024-53103",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53103"
},
{
"name": "CVE-2024-53113",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53113"
},
{
"name": "CVE-2024-53119",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53119"
},
{
"name": "CVE-2024-53120",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53120"
},
{
"name": "CVE-2024-53122",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53122"
},
{
"name": "CVE-2024-53123",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53123"
},
{
"name": "CVE-2024-53127",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53127"
},
{
"name": "CVE-2024-53129",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53129"
},
{
"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-53135",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53135"
},
{
"name": "CVE-2024-53136",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53136"
},
{
"name": "CVE-2024-53140",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53140"
},
{
"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-50016",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50016"
},
{
"name": "CVE-2024-50203",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50203"
},
{
"name": "CVE-2024-50211",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50211"
},
{
"name": "CVE-2024-53050",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53050"
},
{
"name": "CVE-2024-53090",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53090"
},
{
"name": "CVE-2024-53099",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53099"
},
{
"name": "CVE-2024-53105",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53105"
},
{
"name": "CVE-2024-53111",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53111"
},
{
"name": "CVE-2024-53117",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53117"
},
{
"name": "CVE-2024-53118",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53118"
},
{
"name": "CVE-2024-53125",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53125"
},
{
"name": "CVE-2024-53126",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53126"
},
{
"name": "CVE-2024-53133",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53133"
},
{
"name": "CVE-2024-53134",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53134"
},
{
"name": "CVE-2024-53141",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53141"
},
{
"name": "CVE-2024-53146",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53146"
},
{
"name": "CVE-2024-53148",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53148"
},
{
"name": "CVE-2024-53150",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53150"
},
{
"name": "CVE-2024-53151",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53151"
},
{
"name": "CVE-2024-53154",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53154"
},
{
"name": "CVE-2024-53155",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53155"
},
{
"name": "CVE-2024-53156",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53156"
},
{
"name": "CVE-2024-53157",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53157"
},
{
"name": "CVE-2024-53158",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53158"
},
{
"name": "CVE-2024-53160",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53160"
},
{
"name": "CVE-2024-53161",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53161"
},
{
"name": "CVE-2024-53162",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53162"
},
{
"name": "CVE-2024-53166",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53166"
},
{
"name": "CVE-2024-53169",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53169"
},
{
"name": "CVE-2024-53171",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53171"
},
{
"name": "CVE-2024-53173",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53173"
},
{
"name": "CVE-2024-53174",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53174"
},
{
"name": "CVE-2024-53180",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53180"
},
{
"name": "CVE-2024-53188",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53188"
},
{
"name": "CVE-2024-53190",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53190"
},
{
"name": "CVE-2024-53191",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53191"
},
{
"name": "CVE-2024-53200",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53200"
},
{
"name": "CVE-2024-53202",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53202"
},
{
"name": "CVE-2024-53206",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53206"
},
{
"name": "CVE-2024-53208",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53208"
},
{
"name": "CVE-2024-53209",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53209"
},
{
"name": "CVE-2024-53210",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53210"
},
{
"name": "CVE-2024-53213",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53213"
},
{
"name": "CVE-2024-53214",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53214"
},
{
"name": "CVE-2024-53215",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53215"
},
{
"name": "CVE-2024-53217",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53217"
},
{
"name": "CVE-2024-53222",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53222"
},
{
"name": "CVE-2024-53224",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53224"
},
{
"name": "CVE-2024-53229",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53229"
},
{
"name": "CVE-2024-53234",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53234"
},
{
"name": "CVE-2024-53237",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53237"
},
{
"name": "CVE-2024-56539",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56539"
},
{
"name": "CVE-2024-56549",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56549"
},
{
"name": "CVE-2024-56551",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56551"
},
{
"name": "CVE-2024-56562",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56562"
},
{
"name": "CVE-2024-56566",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56566"
},
{
"name": "CVE-2024-56567",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56567"
},
{
"name": "CVE-2024-56576",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56576"
},
{
"name": "CVE-2024-56582",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56582"
},
{
"name": "CVE-2024-56599",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56599"
},
{
"name": "CVE-2024-56604",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56604"
},
{
"name": "CVE-2024-56605",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56605"
},
{
"name": "CVE-2024-56645",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56645"
},
{
"name": "CVE-2024-56752",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56752"
},
{
"name": "CVE-2024-56754",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56754"
},
{
"name": "CVE-2024-56755",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56755"
},
{
"name": "CVE-2024-56756",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56756"
},
{
"name": "CVE-2024-53239",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53239"
},
{
"name": "CVE-2024-56548",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56548"
},
{
"name": "CVE-2024-56570",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56570"
},
{
"name": "CVE-2024-56575",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56575"
},
{
"name": "CVE-2024-56598",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56598"
},
{
"name": "CVE-2024-56619",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56619"
},
{
"name": "CVE-2024-56631",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56631"
},
{
"name": "CVE-2024-56704",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56704"
},
{
"name": "CVE-2024-36476",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36476"
},
{
"name": "CVE-2024-45828",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45828"
},
{
"name": "CVE-2024-47141",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47141"
},
{
"name": "CVE-2024-47143",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47143"
},
{
"name": "CVE-2024-47809",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47809"
},
{
"name": "CVE-2024-48873",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-48873"
},
{
"name": "CVE-2024-48881",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-48881"
},
{
"name": "CVE-2024-49569",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49569"
},
{
"name": "CVE-2024-49998",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49998"
},
{
"name": "CVE-2024-50051",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50051"
},
{
"name": "CVE-2024-52332",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-52332"
},
{
"name": "CVE-2024-53091",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53091"
},
{
"name": "CVE-2024-53168",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53168"
},
{
"name": "CVE-2024-53170",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53170"
},
{
"name": "CVE-2024-53172",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53172"
},
{
"name": "CVE-2024-53175",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53175"
},
{
"name": "CVE-2024-53194",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53194"
},
{
"name": "CVE-2024-53195",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53195"
},
{
"name": "CVE-2024-53196",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53196"
},
{
"name": "CVE-2024-53197",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53197"
},
{
"name": "CVE-2024-53198",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53198"
},
{
"name": "CVE-2024-53227",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53227"
},
{
"name": "CVE-2024-53230",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53230"
},
{
"name": "CVE-2024-53231",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53231"
},
{
"name": "CVE-2024-53232",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53232"
},
{
"name": "CVE-2024-53233",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53233"
},
{
"name": "CVE-2024-53236",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53236"
},
{
"name": "CVE-2024-53685",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53685"
},
{
"name": "CVE-2024-53690",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53690"
},
{
"name": "CVE-2024-55881",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-55881"
},
{
"name": "CVE-2024-55916",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-55916"
},
{
"name": "CVE-2024-56369",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56369"
},
{
"name": "CVE-2024-56531",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56531"
},
{
"name": "CVE-2024-56532",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56532"
},
{
"name": "CVE-2024-56533",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56533"
},
{
"name": "CVE-2024-56538",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56538"
},
{
"name": "CVE-2024-56543",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56543"
},
{
"name": "CVE-2024-56546",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56546"
},
{
"name": "CVE-2024-56557",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56557"
},
{
"name": "CVE-2024-56558",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56558"
},
{
"name": "CVE-2024-56568",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56568"
},
{
"name": "CVE-2024-56569",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56569"
},
{
"name": "CVE-2024-56572",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56572"
},
{
"name": "CVE-2024-56573",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56573"
},
{
"name": "CVE-2024-56574",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56574"
},
{
"name": "CVE-2024-53164",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53164"
},
{
"name": "CVE-2024-56577",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56577"
},
{
"name": "CVE-2024-56578",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56578"
},
{
"name": "CVE-2024-56584",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56584"
},
{
"name": "CVE-2024-56587",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56587"
},
{
"name": "CVE-2024-56588",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56588"
},
{
"name": "CVE-2024-56589",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56589"
},
{
"name": "CVE-2024-56590",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56590"
},
{
"name": "CVE-2024-56593",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56593"
},
{
"name": "CVE-2024-56594",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56594"
},
{
"name": "CVE-2024-56595",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56595"
},
{
"name": "CVE-2024-56596",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56596"
},
{
"name": "CVE-2024-56597",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56597"
},
{
"name": "CVE-2024-56602",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56602"
},
{
"name": "CVE-2024-56603",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56603"
},
{
"name": "CVE-2024-56606",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56606"
},
{
"name": "CVE-2024-56607",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56607"
},
{
"name": "CVE-2024-56609",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56609"
},
{
"name": "CVE-2024-56611",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56611"
},
{
"name": "CVE-2024-56614",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56614"
},
{
"name": "CVE-2024-56615",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56615"
},
{
"name": "CVE-2024-56616",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56616"
},
{
"name": "CVE-2024-56620",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56620"
},
{
"name": "CVE-2024-56622",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56622"
},
{
"name": "CVE-2024-56623",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56623"
},
{
"name": "CVE-2024-56625",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56625"
},
{
"name": "CVE-2024-56629",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56629"
},
{
"name": "CVE-2024-56630",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56630"
},
{
"name": "CVE-2024-56632",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56632"
},
{
"name": "CVE-2024-56634",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56634"
},
{
"name": "CVE-2024-56635",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56635"
},
{
"name": "CVE-2024-56636",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56636"
},
{
"name": "CVE-2024-56637",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56637"
},
{
"name": "CVE-2024-56641",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56641"
},
{
"name": "CVE-2024-56642",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56642"
},
{
"name": "CVE-2024-56643",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56643"
},
{
"name": "CVE-2024-56644",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56644"
},
{
"name": "CVE-2024-56648",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56648"
},
{
"name": "CVE-2024-56649",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56649"
},
{
"name": "CVE-2024-56651",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56651"
},
{
"name": "CVE-2024-56659",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56659"
},
{
"name": "CVE-2024-56662",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56662"
},
{
"name": "CVE-2024-56663",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56663"
},
{
"name": "CVE-2024-56670",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56670"
},
{
"name": "CVE-2024-56672",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56672"
},
{
"name": "CVE-2024-56677",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56677"
},
{
"name": "CVE-2024-56678",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56678"
},
{
"name": "CVE-2024-56681",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56681"
},
{
"name": "CVE-2024-56683",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56683"
},
{
"name": "CVE-2024-56687",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56687"
},
{
"name": "CVE-2024-56688",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56688"
},
{
"name": "CVE-2024-56690",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56690"
},
{
"name": "CVE-2024-56691",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56691"
},
{
"name": "CVE-2024-56694",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56694"
},
{
"name": "CVE-2024-56698",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56698"
},
{
"name": "CVE-2024-56700",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56700"
},
{
"name": "CVE-2024-56701",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56701"
},
{
"name": "CVE-2024-56705",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56705"
},
{
"name": "CVE-2024-56708",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56708"
},
{
"name": "CVE-2024-56716",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56716"
},
{
"name": "CVE-2024-56722",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56722"
},
{
"name": "CVE-2024-56723",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56723"
},
{
"name": "CVE-2024-56724",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56724"
},
{
"name": "CVE-2024-56729",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56729"
},
{
"name": "CVE-2024-56739",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56739"
},
{
"name": "CVE-2024-56745",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56745"
},
{
"name": "CVE-2024-56746",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56746"
},
{
"name": "CVE-2024-56747",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56747"
},
{
"name": "CVE-2024-56748",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56748"
},
{
"name": "CVE-2024-56759",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56759"
},
{
"name": "CVE-2024-56765",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56765"
},
{
"name": "CVE-2024-56767",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56767"
},
{
"name": "CVE-2024-56769",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56769"
},
{
"name": "CVE-2024-56774",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56774"
},
{
"name": "CVE-2024-56775",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56775"
},
{
"name": "CVE-2024-56776",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56776"
},
{
"name": "CVE-2024-56777",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56777"
},
{
"name": "CVE-2024-56778",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56778"
},
{
"name": "CVE-2024-56779",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56779"
},
{
"name": "CVE-2024-56780",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56780"
},
{
"name": "CVE-2024-56787",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56787"
},
{
"name": "CVE-2024-57791",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57791"
},
{
"name": "CVE-2024-57792",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57792"
},
{
"name": "CVE-2024-57798",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57798"
},
{
"name": "CVE-2024-57838",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57838"
},
{
"name": "CVE-2024-57849",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57849"
},
{
"name": "CVE-2024-57850",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57850"
},
{
"name": "CVE-2024-57874",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57874"
},
{
"name": "CVE-2024-57876",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57876"
},
{
"name": "CVE-2024-57890",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57890"
},
{
"name": "CVE-2024-57892",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57892"
},
{
"name": "CVE-2024-57896",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57896"
},
{
"name": "CVE-2024-57897",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57897"
},
{
"name": "CVE-2024-57903",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57903"
},
{
"name": "CVE-2024-57904",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57904"
},
{
"name": "CVE-2024-57906",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57906"
},
{
"name": "CVE-2024-57907",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57907"
},
{
"name": "CVE-2024-57908",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57908"
},
{
"name": "CVE-2024-57910",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57910"
},
{
"name": "CVE-2024-57911",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57911"
},
{
"name": "CVE-2024-57912",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57912"
},
{
"name": "CVE-2024-57913",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57913"
},
{
"name": "CVE-2024-57922",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57922"
},
{
"name": "CVE-2024-57929",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57929"
},
{
"name": "CVE-2024-57940",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57940"
},
{
"name": "CVE-2025-21646",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21646"
},
{
"name": "CVE-2024-53047",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53047"
},
{
"name": "CVE-2024-50258",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50258"
},
{
"name": "CVE-2024-50304",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50304"
},
{
"name": "CVE-2024-53187",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53187"
},
{
"name": "CVE-2024-53203",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53203"
},
{
"name": "CVE-2024-56592",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56592"
},
{
"name": "CVE-2024-56600",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56600"
},
{
"name": "CVE-2024-56601",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56601"
},
{
"name": "CVE-2024-56608",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56608"
},
{
"name": "CVE-2024-56610",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56610"
},
{
"name": "CVE-2024-56650",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56650"
},
{
"name": "CVE-2024-56658",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56658"
},
{
"name": "CVE-2024-56679",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56679"
},
{
"name": "CVE-2024-56693",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56693"
},
{
"name": "CVE-2024-56707",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56707"
},
{
"name": "CVE-2024-56715",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56715"
},
{
"name": "CVE-2024-56725",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56725"
},
{
"name": "CVE-2024-56726",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56726"
},
{
"name": "CVE-2024-56727",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56727"
},
{
"name": "CVE-2024-56728",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56728"
},
{
"name": "CVE-2024-56763",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56763"
},
{
"name": "CVE-2024-57802",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57802"
},
{
"name": "CVE-2024-57882",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57882"
},
{
"name": "CVE-2024-57884",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57884"
},
{
"name": "CVE-2024-57917",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57917"
},
{
"name": "CVE-2024-57931",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57931"
},
{
"name": "CVE-2024-57938",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57938"
},
{
"name": "CVE-2024-57946",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57946"
},
{
"name": "CVE-2025-21653",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21653"
},
{
"name": "CVE-2025-21664",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21664"
},
{
"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-21678",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21678"
},
{
"name": "CVE-2024-49994",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49994"
},
{
"name": "CVE-2024-50164",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50164"
},
{
"name": "CVE-2024-53124",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53124"
},
{
"name": "CVE-2024-53128",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53128"
},
{
"name": "CVE-2024-56703",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56703"
},
{
"name": "CVE-2024-57925",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57925"
},
{
"name": "CVE-2024-57939",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57939"
},
{
"name": "CVE-2024-57948",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57948"
},
{
"name": "CVE-2025-21631",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21631"
},
{
"name": "CVE-2025-21636",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21636"
},
{
"name": "CVE-2025-21637",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21637"
},
{
"name": "CVE-2025-21638",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21638"
},
{
"name": "CVE-2025-21639",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21639"
},
{
"name": "CVE-2025-21640",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21640"
},
{
"name": "CVE-2025-21648",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21648"
},
{
"name": "CVE-2025-21665",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21665"
},
{
"name": "CVE-2025-21680",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21680"
},
{
"name": "CVE-2025-21683",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21683"
},
{
"name": "CVE-2024-53177",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53177"
},
{
"name": "CVE-2024-56633",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56633"
},
{
"name": "CVE-2022-49034",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49034"
},
{
"name": "CVE-2024-47689",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47689"
},
{
"name": "CVE-2024-47691",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47691"
},
{
"name": "CVE-2024-47711",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47711"
},
{
"name": "CVE-2024-47726",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47726"
},
{
"name": "CVE-2024-49865",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49865"
},
{
"name": "CVE-2024-49880",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49880"
},
{
"name": "CVE-2024-49926",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49926"
},
{
"name": "CVE-2024-49988",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49988"
},
{
"name": "CVE-2024-50029",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50029"
},
{
"name": "CVE-2024-50030",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50030"
},
{
"name": "CVE-2024-50056",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50056"
},
{
"name": "CVE-2024-50057",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50057"
},
{
"name": "CVE-2024-50065",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50065"
},
{
"name": "CVE-2024-50066",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50066"
},
{
"name": "CVE-2024-50068",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50068"
},
{
"name": "CVE-2024-50070",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50070"
},
{
"name": "CVE-2024-50090",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50090"
},
{
"name": "CVE-2024-50104",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50104"
},
{
"name": "CVE-2024-50105",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50105"
},
{
"name": "CVE-2024-50107",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50107"
},
{
"name": "CVE-2024-50111",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50111"
},
{
"name": "CVE-2024-50112",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50112"
},
{
"name": "CVE-2024-50118",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50118"
},
{
"name": "CVE-2024-50120",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50120"
},
{
"name": "CVE-2024-50137",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50137"
},
{
"name": "CVE-2024-50140",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50140"
},
{
"name": "CVE-2024-50152",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50152"
},
{
"name": "CVE-2024-50170",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50170"
},
{
"name": "CVE-2024-50197",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50197"
},
{
"name": "CVE-2024-50206",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50206"
},
{
"name": "CVE-2024-50207",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50207"
},
{
"name": "CVE-2024-50220",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50220"
},
{
"name": "CVE-2024-50222",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50222"
},
{
"name": "CVE-2024-50223",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50223"
},
{
"name": "CVE-2024-50238",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50238"
},
{
"name": "CVE-2024-50239",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50239"
},
{
"name": "CVE-2024-50263",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50263"
},
{
"name": "CVE-2024-50270",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50270"
},
{
"name": "CVE-2024-50285",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50285"
},
{
"name": "CVE-2024-50288",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50288"
},
{
"name": "CVE-2024-50291",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50291"
},
{
"name": "CVE-2024-50294",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50294"
},
{
"name": "CVE-2024-50297",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50297"
},
{
"name": "CVE-2024-50300",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50300"
},
{
"name": "CVE-2024-50303",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50303"
},
{
"name": "CVE-2024-53044",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53044"
},
{
"name": "CVE-2024-53046",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53046"
},
{
"name": "CVE-2024-53053",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53053"
},
{
"name": "CVE-2024-53062",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53062"
},
{
"name": "CVE-2024-53067",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53067"
},
{
"name": "CVE-2024-53083",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53083"
},
{
"name": "CVE-2024-53084",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53084"
},
{
"name": "CVE-2024-53086",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53086"
},
{
"name": "CVE-2024-53087",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53087"
},
{
"name": "CVE-2024-53089",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53089"
},
{
"name": "CVE-2024-53107",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53107"
},
{
"name": "CVE-2024-53109",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53109"
},
{
"name": "CVE-2024-53115",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53115"
},
{
"name": "CVE-2024-53139",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53139"
},
{
"name": "CVE-2024-53145",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53145"
},
{
"name": "CVE-2024-53147",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53147"
},
{
"name": "CVE-2024-53163",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53163"
},
{
"name": "CVE-2024-53165",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53165"
},
{
"name": "CVE-2024-53176",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53176"
},
{
"name": "CVE-2024-53178",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53178"
},
{
"name": "CVE-2024-53181",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53181"
},
{
"name": "CVE-2024-53183",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53183"
},
{
"name": "CVE-2024-53184",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53184"
},
{
"name": "CVE-2024-53218",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53218"
},
{
"name": "CVE-2024-53219",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53219"
},
{
"name": "CVE-2024-53220",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53220"
},
{
"name": "CVE-2024-53221",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53221"
},
{
"name": "CVE-2024-53223",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53223"
},
{
"name": "CVE-2024-53226",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53226"
},
{
"name": "CVE-2024-53228",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53228"
},
{
"name": "CVE-2024-56540",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56540"
},
{
"name": "CVE-2024-56545",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56545"
},
{
"name": "CVE-2024-56685",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56685"
},
{
"name": "CVE-2024-56689",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56689"
},
{
"name": "CVE-2024-56692",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56692"
},
{
"name": "CVE-2024-56720",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56720"
},
{
"name": "CVE-2024-56721",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56721"
},
{
"name": "CVE-2024-56742",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56742"
},
{
"name": "CVE-2024-56744",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56744"
},
{
"name": "CVE-2024-56751",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56751"
},
{
"name": "CVE-2025-0927",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-0927"
},
{
"name": "CVE-2024-56579",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56579"
},
{
"name": "CVE-2024-56647",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56647"
},
{
"name": "CVE-2024-57889",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57889"
},
{
"name": "CVE-2025-21687",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21687"
},
{
"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-2025-21700",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21700"
},
{
"name": "CVE-2024-43098",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43098"
},
{
"name": "CVE-2024-47408",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47408"
},
{
"name": "CVE-2024-49571",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49571"
},
{
"name": "CVE-2024-53680",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53680"
},
{
"name": "CVE-2024-56581",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56581"
},
{
"name": "CVE-2024-56586",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56586"
},
{
"name": "CVE-2024-56626",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56626"
},
{
"name": "CVE-2024-56627",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56627"
},
{
"name": "CVE-2024-56640",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56640"
},
{
"name": "CVE-2024-56770",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56770"
},
{
"name": "CVE-2024-56781",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56781"
},
{
"name": "CVE-2024-56785",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56785"
},
{
"name": "CVE-2024-57807",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57807"
},
{
"name": "CVE-2024-57841",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57841"
},
{
"name": "CVE-2024-57900",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57900"
},
{
"name": "CVE-2024-57901",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57901"
},
{
"name": "CVE-2024-57902",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57902"
},
{
"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-2022-0995",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-0995"
},
{
"name": "CVE-2024-41932",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41932"
},
{
"name": "CVE-2024-41935",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41935"
},
{
"name": "CVE-2024-47794",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47794"
},
{
"name": "CVE-2024-48875",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-48875"
},
{
"name": "CVE-2024-48876",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-48876"
},
{
"name": "CVE-2024-56550",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56550"
},
{
"name": "CVE-2024-56565",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56565"
},
{
"name": "CVE-2024-56580",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56580"
},
{
"name": "CVE-2024-56583",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56583"
},
{
"name": "CVE-2024-56613",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56613"
},
{
"name": "CVE-2024-56621",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56621"
},
{
"name": "CVE-2024-56638",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56638"
},
{
"name": "CVE-2024-56771",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56771"
},
{
"name": "CVE-2024-56772",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56772"
},
{
"name": "CVE-2024-56773",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56773"
},
{
"name": "CVE-2024-56782",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56782"
},
{
"name": "CVE-2024-56786",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56786"
},
{
"name": "CVE-2024-57843",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57843"
},
{
"name": "CVE-2024-57872",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57872"
},
{
"name": "CVE-2024-58087",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58087"
},
{
"name": "CVE-2025-21701",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21701"
},
{
"name": "CVE-2025-21703",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21703"
},
{
"name": "CVE-2025-21756",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21756"
},
{
"name": "CVE-2025-21831",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21831"
},
{
"name": "CVE-2025-21702",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21702"
},
{
"name": "CVE-2025-21993",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21993"
},
{
"name": "CVE-2024-44955",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44955"
},
{
"name": "CVE-2025-2312",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-2312"
}
],
"initial_release_date": "2025-05-02T00:00:00",
"last_revision_date": "2025-05-02T00:00:00",
"links": [],
"reference": "CERTFR-2025-AVI-0366",
"revisions": [
{
"description": "Version initiale",
"revision_date": "2025-05-02T00:00:00.000000"
}
],
"risks": [
{
"description": "Ex\u00e9cution de code arbitraire \u00e0 distance"
},
{
"description": "Non sp\u00e9cifi\u00e9 par l\u0027\u00e9diteur"
},
{
"description": "D\u00e9ni de service"
},
{
"description": "Atteinte \u00e0 la confidentialit\u00e9 des donn\u00e9es"
},
{
"description": "\u00c9l\u00e9vation de privil\u00e8ges"
}
],
"summary": "De multiples vuln\u00e9rabilit\u00e9s ont \u00e9t\u00e9 d\u00e9couvertes dans le noyau Linux d\u0027Ubuntu. Certaines d\u0027entre elles permettent \u00e0 un attaquant de provoquer une ex\u00e9cution de code arbitraire \u00e0 distance, une \u00e9l\u00e9vation de privil\u00e8ges et 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-04-25",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7455-4",
"url": "https://ubuntu.com/security/notices/USN-7455-4"
},
{
"published_at": "2025-04-28",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7459-2",
"url": "https://ubuntu.com/security/notices/USN-7459-2"
},
{
"published_at": "2025-04-28",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7468-1",
"url": "https://ubuntu.com/security/notices/USN-7468-1"
},
{
"published_at": "2025-04-29",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7455-5",
"url": "https://ubuntu.com/security/notices/USN-7455-5"
}
]
}
CERTFR-2026-AVI-0316
Vulnerability from certfr_avis - Published: 2026-03-19 - Updated: 2026-03-19
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 | N/A | NodeJS Buildpack versions antérieures à 1.8.82 | ||
| VMware | Tanzu Platform | Tanzu for MySQL sur Tanzu Platform versions antérieures à 10.1.1 | ||
| VMware | N/A | Java Buildpack versions antérieures à 4.90.0 | ||
| VMware | N/A | NGINX Buildpack versions antérieures à 1.2.71 | ||
| VMware | N/A | HWC Buildpack versions antérieures à 3.1.91 | ||
| VMware | Tanzu Platform | Foundation Core for VMware Tanzu Platform versions antérieures à 3.1.9 |
| Title | Publication Time | Tags | ||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||||||||
{
"$ref": "https://www.cert.ssi.gouv.fr/openapi.json",
"affected_systems": [
{
"description": "NodeJS Buildpack versions ant\u00e9rieures \u00e0 1.8.82",
"product": {
"name": "N/A",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Tanzu for MySQL sur Tanzu Platform versions ant\u00e9rieures \u00e0 10.1.1",
"product": {
"name": "Tanzu Platform",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Java Buildpack versions ant\u00e9rieures \u00e0 4.90.0",
"product": {
"name": "N/A",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "NGINX Buildpack versions ant\u00e9rieures \u00e0 1.2.71",
"product": {
"name": "N/A",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "HWC Buildpack versions ant\u00e9rieures \u00e0 3.1.91",
"product": {
"name": "N/A",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Foundation Core for VMware Tanzu Platform versions ant\u00e9rieures \u00e0 3.1.9",
"product": {
"name": "Tanzu Platform",
"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-2026-28422",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-28422"
},
{
"name": "CVE-2024-36903",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36903"
},
{
"name": "CVE-2024-35875",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35875"
},
{
"name": "CVE-2022-50759",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50759"
},
{
"name": "CVE-2026-26007",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-26007"
},
{
"name": "CVE-2025-71075",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71075"
},
{
"name": "CVE-2024-49912",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49912"
},
{
"name": "CVE-2024-36026",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36026"
},
{
"name": "CVE-2026-23198",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23198"
},
{
"name": "CVE-2023-3640",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-3640"
},
{
"name": "CVE-2024-27435",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27435"
},
{
"name": "CVE-2025-40273",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40273"
},
{
"name": "CVE-2023-53714",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53714"
},
{
"name": "CVE-2024-42122",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42122"
},
{
"name": "CVE-2025-68230",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68230"
},
{
"name": "CVE-2026-28420",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-28420"
},
{
"name": "CVE-2022-49069",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49069"
},
{
"name": "CVE-2024-57875",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57875"
},
{
"name": "CVE-2022-27943",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-27943"
},
{
"name": "CVE-2025-40064",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40064"
},
{
"name": "CVE-2023-54129",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54129"
},
{
"name": "CVE-2025-66865",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-66865"
},
{
"name": "CVE-2024-41031",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41031"
},
{
"name": "CVE-2025-39992",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39992"
},
{
"name": "CVE-2025-69534",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-69534"
},
{
"name": "CVE-2025-61730",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-61730"
},
{
"name": "CVE-2022-49543",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49543"
},
{
"name": "CVE-2026-23202",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23202"
},
{
"name": "CVE-2025-38485",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38485"
},
{
"name": "CVE-2023-53562",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53562"
},
{
"name": "CVE-2025-68324",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68324"
},
{
"name": "CVE-2025-22026",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22026"
},
{
"name": "CVE-2023-54149",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54149"
},
{
"name": "CVE-2025-71086",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71086"
},
{
"name": "CVE-2024-50063",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50063"
},
{
"name": "CVE-2023-33875",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-33875"
},
{
"name": "CVE-2024-41001",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41001"
},
{
"name": "CVE-2024-42155",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42155"
},
{
"name": "CVE-2026-23167",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23167"
},
{
"name": "CVE-2025-36353",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-36353"
},
{
"name": "CVE-2025-68196",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68196"
},
{
"name": "CVE-2024-46770",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46770"
},
{
"name": "CVE-2023-53247",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53247"
},
{
"name": "CVE-2025-38042",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38042"
},
{
"name": "CVE-2025-22083",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22083"
},
{
"name": "CVE-2023-53829",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53829"
},
{
"name": "CVE-2025-58183",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-58183"
},
{
"name": "CVE-2023-54002",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54002"
},
{
"name": "CVE-2022-50550",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50550"
},
{
"name": "CVE-2022-0400",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-0400"
},
{
"name": "CVE-2022-49138",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49138"
},
{
"name": "CVE-2025-66199",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-66199"
},
{
"name": "CVE-2024-42239",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42239"
},
{
"name": "CVE-2022-49359",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49359"
},
{
"name": "CVE-2025-68342",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68342"
},
{
"name": "CVE-2022-48673",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48673"
},
{
"name": "CVE-2022-50425",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50425"
},
{
"name": "CVE-2025-38201",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38201"
},
{
"name": "CVE-2024-39293",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39293"
},
{
"name": "CVE-2023-53008",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53008"
},
{
"name": "CVE-2025-38669",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38669"
},
{
"name": "CVE-2025-40137",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40137"
},
{
"name": "CVE-2023-54052",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54052"
},
{
"name": "CVE-2025-22107",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22107"
},
{
"name": "CVE-2024-38306",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38306"
},
{
"name": "CVE-2023-53733",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53733"
},
{
"name": "CVE-2025-37775",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37775"
},
{
"name": "CVE-2025-21682",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21682"
},
{
"name": "CVE-2023-1386",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-1386"
},
{
"name": "CVE-2024-35939",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35939"
},
{
"name": "CVE-2024-39298",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39298"
},
{
"name": "CVE-2024-56703",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56703"
},
{
"name": "CVE-2026-23098",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23098"
},
{
"name": "CVE-2023-53347",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53347"
},
{
"name": "CVE-2023-28374",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-28374"
},
{
"name": "CVE-2023-52926",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52926"
},
{
"name": "CVE-2026-32597",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-32597"
},
{
"name": "CVE-2025-68286",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68286"
},
{
"name": "CVE-2025-9231",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-9231"
},
{
"name": "CVE-2024-36921",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36921"
},
{
"name": "CVE-2025-40057",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40057"
},
{
"name": "CVE-2024-41050",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41050"
},
{
"name": "CVE-2026-25500",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-25500"
},
{
"name": "CVE-2024-26656",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26656"
},
{
"name": "CVE-2025-38520",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38520"
},
{
"name": "CVE-2025-27558",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-27558"
},
{
"name": "CVE-2025-71094",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71094"
},
{
"name": "CVE-2026-21637",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-21637"
},
{
"name": "CVE-2024-35998",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35998"
},
{
"name": "CVE-2024-37891",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-37891"
},
{
"name": "CVE-2021-0076",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-0076"
},
{
"name": "CVE-2025-68788",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68788"
},
{
"name": "CVE-2024-58237",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58237"
},
{
"name": "CVE-2024-36909",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36909"
},
{
"name": "CVE-2024-42147",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42147"
},
{
"name": "CVE-2023-53529",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53529"
},
{
"name": "CVE-2024-50028",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50028"
},
{
"name": "CVE-2023-53042",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53042"
},
{
"name": "CVE-2022-50527",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50527"
},
{
"name": "CVE-2023-54280",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54280"
},
{
"name": "CVE-2025-21786",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21786"
},
{
"name": "CVE-2024-58094",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58094"
},
{
"name": "CVE-2024-11187",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-11187"
},
{
"name": "CVE-2025-52534",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-52534"
},
{
"name": "CVE-2025-40314",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40314"
},
{
"name": "CVE-2024-46705",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46705"
},
{
"name": "CVE-2022-50407",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50407"
},
{
"name": "CVE-2026-23196",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23196"
},
{
"name": "CVE-2024-26595",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26595"
},
{
"name": "CVE-2022-23825",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-23825"
},
{
"name": "CVE-2024-45775",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45775"
},
{
"name": "CVE-2025-40306",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40306"
},
{
"name": "CVE-2025-21881",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21881"
},
{
"name": "CVE-2022-49901",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49901"
},
{
"name": "CVE-2026-23126",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23126"
},
{
"name": "CVE-2025-38329",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38329"
},
{
"name": "CVE-2021-33096",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-33096"
},
{
"name": "CVE-2022-50230",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50230"
},
{
"name": "CVE-2024-35949",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35949"
},
{
"name": "CVE-2025-39947",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39947"
},
{
"name": "CVE-2025-68778",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68778"
},
{
"name": "CVE-2023-53588",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53588"
},
{
"name": "CVE-2024-41082",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41082"
},
{
"name": "CVE-2023-53685",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53685"
},
{
"name": "CVE-2025-5222",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-5222"
},
{
"name": "CVE-2025-23155",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23155"
},
{
"name": "CVE-2026-23054",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23054"
},
{
"name": "CVE-2025-37870",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37870"
},
{
"name": "CVE-2025-40254",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40254"
},
{
"name": "CVE-2022-49533",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49533"
},
{
"name": "CVE-2024-42253",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42253"
},
{
"name": "CVE-2020-26557",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-26557"
},
{
"name": "CVE-2025-71064",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71064"
},
{
"name": "CVE-2023-54201",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54201"
},
{
"name": "CVE-2021-33114",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-33114"
},
{
"name": "CVE-2025-69645",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-69645"
},
{
"name": "CVE-2025-68200",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68200"
},
{
"name": "CVE-2022-49518",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49518"
},
{
"name": "CVE-2024-56727",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56727"
},
{
"name": "CVE-2022-49125",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49125"
},
{
"name": "CVE-2024-36900",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36900"
},
{
"name": "CVE-2025-38501",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38501"
},
{
"name": "CVE-2024-26866",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26866"
},
{
"name": "CVE-2024-27010",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27010"
},
{
"name": "CVE-2025-27516",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-27516"
},
{
"name": "CVE-2025-68736",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68736"
},
{
"name": "CVE-2023-52561",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52561"
},
{
"name": "CVE-2025-68725",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68725"
},
{
"name": "CVE-2024-53221",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53221"
},
{
"name": "CVE-2024-41069",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41069"
},
{
"name": "CVE-2025-68176",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68176"
},
{
"name": "CVE-2025-37777",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37777"
},
{
"name": "CVE-2021-47432",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47432"
},
{
"name": "CVE-2025-68204",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68204"
},
{
"name": "CVE-2024-35878",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35878"
},
{
"name": "CVE-2023-53362",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53362"
},
{
"name": "CVE-2025-68795",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68795"
},
{
"name": "CVE-2025-68349",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68349"
},
{
"name": "CVE-2024-26756",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26756"
},
{
"name": "CVE-2022-50815",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50815"
},
{
"name": "CVE-2025-21931",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21931"
},
{
"name": "CVE-2025-39826",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39826"
},
{
"name": "CVE-2025-38036",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38036"
},
{
"name": "CVE-2025-2668",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-2668"
},
{
"name": "CVE-2025-71221",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71221"
},
{
"name": "CVE-2025-37778",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37778"
},
{
"name": "CVE-2025-39716",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39716"
},
{
"name": "CVE-2024-46860",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46860"
},
{
"name": "CVE-2025-22040",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22040"
},
{
"name": "CVE-2024-53095",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53095"
},
{
"name": "CVE-2025-22872",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22872"
},
{
"name": "CVE-2025-8277",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-8277"
},
{
"name": "CVE-2025-8941",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-8941"
},
{
"name": "CVE-2022-38457",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-38457"
},
{
"name": "CVE-2024-56665",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56665"
},
{
"name": "CVE-2025-38340",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38340"
},
{
"name": "CVE-2025-38109",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38109"
},
{
"name": "CVE-2023-53629",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53629"
},
{
"name": "CVE-2022-50178",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50178"
},
{
"name": "CVE-2025-39779",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39779"
},
{
"name": "CVE-2025-66866",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-66866"
},
{
"name": "CVE-2025-68283",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68283"
},
{
"name": "CVE-2023-7216",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-7216"
},
{
"name": "CVE-2025-37880",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37880"
},
{
"name": "CVE-2025-36427",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-36427"
},
{
"name": "CVE-2026-23217",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23217"
},
{
"name": "CVE-2025-15469",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-15469"
},
{
"name": "CVE-2025-37833",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37833"
},
{
"name": "CVE-2025-39761",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39761"
},
{
"name": "CVE-2024-38608",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38608"
},
{
"name": "CVE-2025-68246",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68246"
},
{
"name": "CVE-2025-68339",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68339"
},
{
"name": "CVE-2025-40287",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40287"
},
{
"name": "CVE-2023-53320",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53320"
},
{
"name": "CVE-2024-44961",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44961"
},
{
"name": "CVE-2026-23069",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23069"
},
{
"name": "CVE-2025-21656",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21656"
},
{
"name": "CVE-2024-46835",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46835"
},
{
"name": "CVE-2025-69650",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-69650"
},
{
"name": "CVE-2022-50554",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50554"
},
{
"name": "CVE-2023-53509",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53509"
},
{
"name": "CVE-2023-53421",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53421"
},
{
"name": "CVE-2025-11731",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-11731"
},
{
"name": "CVE-2026-22992",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22992"
},
{
"name": "CVE-2024-52005",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-52005"
},
{
"name": "CVE-2024-46775",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46775"
},
{
"name": "CVE-2025-39764",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39764"
},
{
"name": "CVE-2025-38207",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38207"
},
{
"name": "CVE-2022-49465",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49465"
},
{
"name": "CVE-2026-23004",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23004"
},
{
"name": "CVE-2024-26807",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26807"
},
{
"name": "CVE-2025-39720",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39720"
},
{
"name": "CVE-2023-54271",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54271"
},
{
"name": "CVE-2022-49742",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49742"
},
{
"name": "CVE-2025-71191",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71191"
},
{
"name": "CVE-2025-68295",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68295"
},
{
"name": "CVE-2025-68728",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68728"
},
{
"name": "CVE-2025-40780",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40780"
},
{
"name": "CVE-2025-68364",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68364"
},
{
"name": "CVE-2024-42118",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42118"
},
{
"name": "CVE-2025-40100",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40100"
},
{
"name": "CVE-2026-1965",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-1965"
},
{
"name": "CVE-2024-52560",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-52560"
},
{
"name": "CVE-2024-56604",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56604"
},
{
"name": "CVE-2026-23227",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23227"
},
{
"name": "CVE-2025-71087",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71087"
},
{
"name": "CVE-2023-37920",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-37920"
},
{
"name": "CVE-2023-52653",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52653"
},
{
"name": "CVE-2025-40285",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40285"
},
{
"name": "CVE-2023-52508",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52508"
},
{
"name": "CVE-2025-69647",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-69647"
},
{
"name": "CVE-2025-39827",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39827"
},
{
"name": "CVE-2024-50014",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50014"
},
{
"name": "CVE-2022-49108",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49108"
},
{
"name": "CVE-2024-56677",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56677"
},
{
"name": "CVE-2025-38717",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38717"
},
{
"name": "CVE-2026-3497",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-3497"
},
{
"name": "CVE-2025-22019",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22019"
},
{
"name": "CVE-2025-0913",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-0913"
},
{
"name": "CVE-2025-40208",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40208"
},
{
"name": "CVE-2025-39746",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39746"
},
{
"name": "CVE-2024-26767",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26767"
},
{
"name": "CVE-2025-21872",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21872"
},
{
"name": "CVE-2026-2219",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-2219"
},
{
"name": "CVE-2025-68287",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68287"
},
{
"name": "CVE-2025-40039",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40039"
},
{
"name": "CVE-2025-38208",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38208"
},
{
"name": "CVE-2024-35926",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35926"
},
{
"name": "CVE-2024-27389",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27389"
},
{
"name": "CVE-2024-26983",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26983"
},
{
"name": "CVE-2022-50627",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50627"
},
{
"name": "CVE-2024-50285",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50285"
},
{
"name": "CVE-2025-38099",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38099"
},
{
"name": "CVE-2025-38524",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38524"
},
{
"name": "CVE-2025-38029",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38029"
},
{
"name": "CVE-2022-49123",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49123"
},
{
"name": "CVE-2024-50289",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50289"
},
{
"name": "CVE-2023-53258",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53258"
},
{
"name": "CVE-2024-46813",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46813"
},
{
"name": "CVE-2024-38594",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38594"
},
{
"name": "CVE-2025-47907",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-47907"
},
{
"name": "CVE-2024-47658",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47658"
},
{
"name": "CVE-2022-41409",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-41409"
},
{
"name": "CVE-2025-38096",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38096"
},
{
"name": "CVE-2024-48873",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-48873"
},
{
"name": "CVE-2025-68746",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68746"
},
{
"name": "CVE-2023-53429",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53429"
},
{
"name": "CVE-2024-46765",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46765"
},
{
"name": "CVE-2022-50380",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50380"
},
{
"name": "CVE-2025-38039",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38039"
},
{
"name": "CVE-2022-48990",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48990"
},
{
"name": "CVE-2024-24864",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-24864"
},
{
"name": "CVE-2024-35832",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35832"
},
{
"name": "CVE-2024-36479",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36479"
},
{
"name": "CVE-2025-71133",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71133"
},
{
"name": "CVE-2026-23220",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23220"
},
{
"name": "CVE-2024-45782",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45782"
},
{
"name": "CVE-2022-50785",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50785"
},
{
"name": "CVE-2025-39745",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39745"
},
{
"name": "CVE-2024-35799",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35799"
},
{
"name": "CVE-2025-40103",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40103"
},
{
"name": "CVE-2026-23020",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23020"
},
{
"name": "CVE-2025-38595",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38595"
},
{
"name": "CVE-2025-71223",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71223"
},
{
"name": "CVE-2025-36098",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-36098"
},
{
"name": "CVE-2025-68796",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68796"
},
{
"name": "CVE-2025-40016",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40016"
},
{
"name": "CVE-2023-53765",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53765"
},
{
"name": "CVE-2025-38626",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38626"
},
{
"name": "CVE-2025-40356",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40356"
},
{
"name": "CVE-2026-1642",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-1642"
},
{
"name": "CVE-2025-45582",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-45582"
},
{
"name": "CVE-2023-53325",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53325"
},
{
"name": "CVE-2025-21752",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21752"
},
{
"name": "CVE-2026-27138",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-27138"
},
{
"name": "CVE-2025-40312",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40312"
},
{
"name": "CVE-2025-37852",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37852"
},
{
"name": "CVE-2025-68220",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68220"
},
{
"name": "CVE-2025-22125",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22125"
},
{
"name": "CVE-2019-6293",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-6293"
},
{
"name": "CVE-2024-26953",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26953"
},
{
"name": "CVE-2024-39282",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39282"
},
{
"name": "CVE-2025-21738",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21738"
},
{
"name": "CVE-2023-50868",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-50868"
},
{
"name": "CVE-2025-68302",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68302"
},
{
"name": "CVE-2024-50146",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50146"
},
{
"name": "CVE-2025-68238",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68238"
},
{
"name": "CVE-2024-56709",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56709"
},
{
"name": "CVE-2025-38063",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38063"
},
{
"name": "CVE-2025-68297",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68297"
},
{
"name": "CVE-2024-40975",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40975"
},
{
"name": "CVE-2025-68175",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68175"
},
{
"name": "CVE-2023-3817",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-3817"
},
{
"name": "CVE-2023-54227",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54227"
},
{
"name": "CVE-2023-46316",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-46316"
},
{
"name": "CVE-2024-47866",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47866"
},
{
"name": "CVE-2024-44970",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44970"
},
{
"name": "CVE-2022-49476",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49476"
},
{
"name": "CVE-2023-53855",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53855"
},
{
"name": "CVE-2026-23208",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23208"
},
{
"name": "CVE-2025-68804",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68804"
},
{
"name": "CVE-2025-39925",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39925"
},
{
"name": "CVE-2025-68769",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68769"
},
{
"name": "CVE-2024-50286",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50286"
},
{
"name": "CVE-2025-40139",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40139"
},
{
"name": "CVE-2025-68794",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68794"
},
{
"name": "CVE-2025-21768",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21768"
},
{
"name": "CVE-2022-48667",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48667"
},
{
"name": "CVE-2025-69419",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-69419"
},
{
"name": "CVE-2024-56744",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56744"
},
{
"name": "CVE-2025-38491",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38491"
},
{
"name": "CVE-2026-3783",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-3783"
},
{
"name": "CVE-2022-49161",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49161"
},
{
"name": "CVE-2021-21240",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-21240"
},
{
"name": "CVE-2022-48771",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48771"
},
{
"name": "CVE-2025-37961",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37961"
},
{
"name": "CVE-2025-23131",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23131"
},
{
"name": "CVE-2024-27400",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27400"
},
{
"name": "CVE-2023-52485",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52485"
},
{
"name": "CVE-2025-40309",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40309"
},
{
"name": "CVE-2022-49997",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49997"
},
{
"name": "CVE-2022-49469",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49469"
},
{
"name": "CVE-2025-38408",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38408"
},
{
"name": "CVE-2026-23179",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23179"
},
{
"name": "CVE-2025-68334",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68334"
},
{
"name": "CVE-2025-40343",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40343"
},
{
"name": "CVE-2025-38644",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38644"
},
{
"name": "CVE-2025-38692",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38692"
},
{
"name": "CVE-2022-0480",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-0480"
},
{
"name": "CVE-2025-68173",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68173"
},
{
"name": "CVE-2024-49932",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49932"
},
{
"name": "CVE-2026-23090",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23090"
},
{
"name": "CVE-2026-23035",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23035"
},
{
"name": "CVE-2023-53209",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53209"
},
{
"name": "CVE-2023-54253",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54253"
},
{
"name": "CVE-2025-38127",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38127"
},
{
"name": "CVE-2025-22103",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22103"
},
{
"name": "CVE-2025-1272",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-1272"
},
{
"name": "CVE-2025-21658",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21658"
},
{
"name": "CVE-2022-49651",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49651"
},
{
"name": "CVE-2025-68307",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68307"
},
{
"name": "CVE-2025-40308",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40308"
},
{
"name": "CVE-2024-26770",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26770"
},
{
"name": "CVE-2023-54324",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54324"
},
{
"name": "CVE-2024-27041",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27041"
},
{
"name": "CVE-2025-36184",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-36184"
},
{
"name": "CVE-2026-3195",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-3195"
},
{
"name": "CVE-2025-37743",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37743"
},
{
"name": "CVE-2025-40005",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40005"
},
{
"name": "CVE-2025-37920",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37920"
},
{
"name": "CVE-2024-56326",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56326"
},
{
"name": "CVE-2023-26242",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-26242"
},
{
"name": "CVE-2025-58185",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-58185"
},
{
"name": "CVE-2025-40315",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40315"
},
{
"name": "CVE-2023-52673",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52673"
},
{
"name": "CVE-2024-56722",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56722"
},
{
"name": "CVE-2021-33113",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-33113"
},
{
"name": "CVE-2022-48668",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48668"
},
{
"name": "CVE-2024-27418",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27418"
},
{
"name": "CVE-2025-68231",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68231"
},
{
"name": "CVE-2021-22930",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-22930"
},
{
"name": "CVE-2026-23064",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23064"
},
{
"name": "CVE-2025-38591",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38591"
},
{
"name": "CVE-2025-68806",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68806"
},
{
"name": "CVE-2022-50322",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50322"
},
{
"name": "CVE-2023-50782",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-50782"
},
{
"name": "CVE-2022-27635",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-27635"
},
{
"name": "CVE-2025-71098",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71098"
},
{
"name": "CVE-2024-49922",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49922"
},
{
"name": "CVE-2020-12317",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-12317"
},
{
"name": "CVE-2025-61731",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-61731"
},
{
"name": "CVE-2025-40251",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40251"
},
{
"name": "CVE-2024-42128",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42128"
},
{
"name": "CVE-2025-71078",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71078"
},
{
"name": "CVE-2024-49909",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49909"
},
{
"name": "CVE-2025-40355",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40355"
},
{
"name": "CVE-2021-42771",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-42771"
},
{
"name": "CVE-2021-4095",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-4095"
},
{
"name": "CVE-2022-50240",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50240"
},
{
"name": "CVE-2025-40054",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40054"
},
{
"name": "CVE-2024-45015",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45015"
},
{
"name": "CVE-2025-68184",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68184"
},
{
"name": "CVE-2024-36357",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36357"
},
{
"name": "CVE-2025-71074",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71074"
},
{
"name": "CVE-2025-38673",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38673"
},
{
"name": "CVE-2025-40107",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40107"
},
{
"name": "CVE-2025-11234",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-11234"
},
{
"name": "CVE-2025-71083",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71083"
},
{
"name": "CVE-2026-23061",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23061"
},
{
"name": "CVE-2023-53447",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53447"
},
{
"name": "CVE-2024-46754",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46754"
},
{
"name": "CVE-2021-0161",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-0161"
},
{
"name": "CVE-2018-1121",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-1121"
},
{
"name": "CVE-2022-49547",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49547"
},
{
"name": "CVE-2025-66863",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-66863"
},
{
"name": "CVE-2025-0622",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-0622"
},
{
"name": "CVE-2023-0286",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-0286"
},
{
"name": "CVE-2024-26757",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26757"
},
{
"name": "CVE-2024-49899",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49899"
},
{
"name": "CVE-2022-49484",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49484"
},
{
"name": "CVE-2024-40900",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40900"
},
{
"name": "CVE-2024-46748",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46748"
},
{
"name": "CVE-2025-68813",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68813"
},
{
"name": "CVE-2024-50164",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50164"
},
{
"name": "CVE-2026-27137",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-27137"
},
{
"name": "CVE-2023-53248",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53248"
},
{
"name": "CVE-2024-56788",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56788"
},
{
"name": "CVE-2016-8660",
"url": "https://www.cve.org/CVERecord?id=CVE-2016-8660"
},
{
"name": "CVE-2024-26691",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26691"
},
{
"name": "CVE-2026-23047",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23047"
},
{
"name": "CVE-2025-22121",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22121"
},
{
"name": "CVE-2024-1975",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-1975"
},
{
"name": "CVE-2025-38215",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38215"
},
{
"name": "CVE-2025-7519",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-7519"
},
{
"name": "CVE-2023-53491",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53491"
},
{
"name": "CVE-2025-68365",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68365"
},
{
"name": "CVE-2024-57804",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57804"
},
{
"name": "CVE-2024-49908",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49908"
},
{
"name": "CVE-2025-68265",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68265"
},
{
"name": "CVE-2024-50048",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50048"
},
{
"name": "CVE-2026-28421",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-28421"
},
{
"name": "CVE-2026-23119",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23119"
},
{
"name": "CVE-2025-37943",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37943"
},
{
"name": "CVE-2025-21918",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21918"
},
{
"name": "CVE-2025-37745",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37745"
},
{
"name": "CVE-2025-71085",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71085"
},
{
"name": "CVE-2026-27171",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-27171"
},
{
"name": "CVE-2022-50811",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50811"
},
{
"name": "CVE-2023-4133",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-4133"
},
{
"name": "CVE-2024-50183",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50183"
},
{
"name": "CVE-2025-38734",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38734"
},
{
"name": "CVE-2023-53366",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53366"
},
{
"name": "CVE-2022-49910",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49910"
},
{
"name": "CVE-2024-27062",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27062"
},
{
"name": "CVE-2022-49203",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49203"
},
{
"name": "CVE-2024-40918",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40918"
},
{
"name": "CVE-2024-27032",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27032"
},
{
"name": "CVE-2022-50236",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50236"
},
{
"name": "CVE-2024-35932",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35932"
},
{
"name": "CVE-2024-35839",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35839"
},
{
"name": "CVE-2025-68344",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68344"
},
{
"name": "CVE-2026-23137",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23137"
},
{
"name": "CVE-2025-40347",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40347"
},
{
"name": "CVE-2025-71154",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71154"
},
{
"name": "CVE-2025-37882",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37882"
},
{
"name": "CVE-2024-35971",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35971"
},
{
"name": "CVE-2024-46762",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46762"
},
{
"name": "CVE-2023-34983",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-34983"
},
{
"name": "CVE-2024-35868",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35868"
},
{
"name": "CVE-2023-53323",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53323"
},
{
"name": "CVE-2026-3731",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-3731"
},
{
"name": "CVE-2025-40198",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40198"
},
{
"name": "CVE-2024-0760",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-0760"
},
{
"name": "CVE-2025-39942",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39942"
},
{
"name": "CVE-2025-68310",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68310"
},
{
"name": "CVE-2026-23222",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23222"
},
{
"name": "CVE-2025-68229",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68229"
},
{
"name": "CVE-2023-52857",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52857"
},
{
"name": "CVE-2024-42107",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42107"
},
{
"name": "CVE-2025-68257",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68257"
},
{
"name": "CVE-2025-39929",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39929"
},
{
"name": "CVE-2022-50304",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50304"
},
{
"name": "CVE-2026-23226",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23226"
},
{
"name": "CVE-2020-26146",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-26146"
},
{
"name": "CVE-2024-43844",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43844"
},
{
"name": "CVE-2023-52920",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52920"
},
{
"name": "CVE-2023-52590",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52590"
},
{
"name": "CVE-2025-71084",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71084"
},
{
"name": "CVE-2024-22025",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-22025"
},
{
"name": "CVE-2026-23049",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23049"
},
{
"name": "CVE-2025-68321",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68321"
},
{
"name": "CVE-2021-0072",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-0072"
},
{
"name": "CVE-2025-40190",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40190"
},
{
"name": "CVE-2025-69652",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-69652"
},
{
"name": "CVE-2025-21635",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21635"
},
{
"name": "CVE-2025-37924",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37924"
},
{
"name": "CVE-2022-40133",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-40133"
},
{
"name": "CVE-2020-26143",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-26143"
},
{
"name": "CVE-2025-21712",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21712"
},
{
"name": "CVE-2025-38353",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38353"
},
{
"name": "CVE-2025-36009",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-36009"
},
{
"name": "CVE-2019-0154",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-0154"
},
{
"name": "CVE-2024-57982",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57982"
},
{
"name": "CVE-2023-52761",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52761"
},
{
"name": "CVE-2022-49773",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49773"
},
{
"name": "CVE-2023-53609",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53609"
},
{
"name": "CVE-2023-53478",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53478"
},
{
"name": "CVE-2024-42117",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42117"
},
{
"name": "CVE-2025-23160",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23160"
},
{
"name": "CVE-2023-53682",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53682"
},
{
"name": "CVE-2026-23229",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23229"
},
{
"name": "CVE-2025-40311",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40311"
},
{
"name": "CVE-2025-54770",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-54770"
},
{
"name": "CVE-2026-3442",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-3442"
},
{
"name": "CVE-2024-58238",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58238"
},
{
"name": "CVE-2024-13176",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-13176"
},
{
"name": "CVE-2025-68814",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68814"
},
{
"name": "CVE-2025-22039",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22039"
},
{
"name": "CVE-2025-37842",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37842"
},
{
"name": "CVE-2025-39933",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39933"
},
{
"name": "CVE-2025-40237",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40237"
},
{
"name": "CVE-2025-47908",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-47908"
},
{
"name": "CVE-2022-49722",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49722"
},
{
"name": "CVE-2026-23745",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23745"
},
{
"name": "CVE-2025-68780",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68780"
},
{
"name": "CVE-2024-35945",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35945"
},
{
"name": "CVE-2025-39990",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39990"
},
{
"name": "CVE-2025-15467",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-15467"
},
{
"name": "CVE-2025-71081",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71081"
},
{
"name": "CVE-2023-53780",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53780"
},
{
"name": "CVE-2020-35501",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-35501"
},
{
"name": "CVE-2024-58251",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58251"
},
{
"name": "CVE-2025-38710",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38710"
},
{
"name": "CVE-2025-9820",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-9820"
},
{
"name": "CVE-2023-52624",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52624"
},
{
"name": "CVE-2024-56557",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56557"
},
{
"name": "CVE-2022-49699",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49699"
},
{
"name": "CVE-2022-50700",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50700"
},
{
"name": "CVE-2023-52632",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52632"
},
{
"name": "CVE-2024-46836",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46836"
},
{
"name": "CVE-2026-23101",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23101"
},
{
"name": "CVE-2026-23099",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23099"
},
{
"name": "CVE-2024-38556",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38556"
},
{
"name": "CVE-2025-1180",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-1180"
},
{
"name": "CVE-2025-38060",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38060"
},
{
"name": "CVE-2022-48929",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48929"
},
{
"name": "CVE-2025-55130",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-55130"
},
{
"name": "CVE-2025-36070",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-36070"
},
{
"name": "CVE-2024-46820",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46820"
},
{
"name": "CVE-2025-39770",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39770"
},
{
"name": "CVE-2025-38105",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38105"
},
{
"name": "CVE-2025-37744",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37744"
},
{
"name": "CVE-2025-38705",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38705"
},
{
"name": "CVE-2023-53198",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53198"
},
{
"name": "CVE-2023-53846",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53846"
},
{
"name": "CVE-2025-71121",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71121"
},
{
"name": "CVE-2024-35942",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35942"
},
{
"name": "CVE-2022-1247",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-1247"
},
{
"name": "CVE-2025-40333",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40333"
},
{
"name": "CVE-2022-50234",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50234"
},
{
"name": "CVE-2025-38082",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38082"
},
{
"name": "CVE-2025-37884",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37884"
},
{
"name": "CVE-2024-58054",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58054"
},
{
"name": "CVE-2024-49934",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49934"
},
{
"name": "CVE-2025-39750",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39750"
},
{
"name": "CVE-2025-38022",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38022"
},
{
"name": "CVE-2026-23066",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23066"
},
{
"name": "CVE-2025-38562",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38562"
},
{
"name": "CVE-2023-4969",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-4969"
},
{
"name": "CVE-2024-50098",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50098"
},
{
"name": "CVE-2024-35946",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35946"
},
{
"name": "CVE-2023-44487",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-44487"
},
{
"name": "CVE-2023-53789",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53789"
},
{
"name": "CVE-2022-49858",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49858"
},
{
"name": "CVE-2025-39692",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39692"
},
{
"name": "CVE-2024-35959",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35959"
},
{
"name": "CVE-2023-5363",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-5363"
},
{
"name": "CVE-2025-36428",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-36428"
},
{
"name": "CVE-2023-53520",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53520"
},
{
"name": "CVE-2026-23085",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23085"
},
{
"name": "CVE-2023-52737",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52737"
},
{
"name": "CVE-2025-40360",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40360"
},
{
"name": "CVE-2026-23209",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23209"
},
{
"name": "CVE-2025-71136",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71136"
},
{
"name": "CVE-2024-35803",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35803"
},
{
"name": "CVE-2025-22105",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22105"
},
{
"name": "CVE-2024-8612",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-8612"
},
{
"name": "CVE-2023-52586",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52586"
},
{
"name": "CVE-2025-40332",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40332"
},
{
"name": "CVE-2021-46195",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-46195"
},
{
"name": "CVE-2025-68354",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68354"
},
{
"name": "CVE-2025-68801",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68801"
},
{
"name": "CVE-2021-33110",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-33110"
},
{
"name": "CVE-2025-37834",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37834"
},
{
"name": "CVE-2025-21833",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21833"
},
{
"name": "CVE-2025-40082",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40082"
},
{
"name": "CVE-2019-19378",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-19378"
},
{
"name": "CVE-2026-23150",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23150"
},
{
"name": "CVE-2024-40972",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40972"
},
{
"name": "CVE-2025-61985",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-61985"
},
{
"name": "CVE-2025-71073",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71073"
},
{
"name": "CVE-2025-38426",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38426"
},
{
"name": "CVE-2025-38436",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38436"
},
{
"name": "CVE-2024-36911",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36911"
},
{
"name": "CVE-2025-55131",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-55131"
},
{
"name": "CVE-2025-40104",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40104"
},
{
"name": "CVE-2024-36917",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36917"
},
{
"name": "CVE-2025-38097",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38097"
},
{
"name": "CVE-2026-23236",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23236"
},
{
"name": "CVE-2023-53068",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53068"
},
{
"name": "CVE-2025-22090",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22090"
},
{
"name": "CVE-2021-31615",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-31615"
},
{
"name": "CVE-2024-1737",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-1737"
},
{
"name": "CVE-2025-40097",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40097"
},
{
"name": "CVE-2022-49932",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49932"
},
{
"name": "CVE-2022-25837",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-25837"
},
{
"name": "CVE-2025-68258",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68258"
},
{
"name": "CVE-2024-49939",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49939"
},
{
"name": "CVE-2025-38239",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38239"
},
{
"name": "CVE-2024-49905",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49905"
},
{
"name": "CVE-2023-52831",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52831"
},
{
"name": "CVE-2023-53221",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53221"
},
{
"name": "CVE-2024-26719",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26719"
},
{
"name": "CVE-2022-44034",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-44034"
},
{
"name": "CVE-2022-40897",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-40897"
},
{
"name": "CVE-2023-53072",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53072"
},
{
"name": "CVE-2023-2007",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-2007"
},
{
"name": "CVE-2022-37341",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-37341"
},
{
"name": "CVE-2025-69648",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-69648"
},
{
"name": "CVE-2023-0466",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-0466"
},
{
"name": "CVE-2024-50298",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50298"
},
{
"name": "CVE-2025-36424",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-36424"
},
{
"name": "CVE-2025-21915",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21915"
},
{
"name": "CVE-2025-38590",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38590"
},
{
"name": "CVE-2024-46843",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46843"
},
{
"name": "CVE-2025-21792",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21792"
},
{
"name": "CVE-2023-54016",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54016"
},
{
"name": "CVE-2025-36387",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-36387"
},
{
"name": "CVE-2025-38709",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38709"
},
{
"name": "CVE-2024-58018",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58018"
},
{
"name": "CVE-2023-4408",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-4408"
},
{
"name": "CVE-2025-71235",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71235"
},
{
"name": "CVE-2023-53602",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53602"
},
{
"name": "CVE-2023-2828",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-2828"
},
{
"name": "CVE-2023-54035",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54035"
},
{
"name": "CVE-2025-40322",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40322"
},
{
"name": "CVE-2023-53867",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53867"
},
{
"name": "CVE-2023-0465",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-0465"
},
{
"name": "CVE-2025-37926",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37926"
},
{
"name": "CVE-2024-46715",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46715"
},
{
"name": "CVE-2025-38038",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38038"
},
{
"name": "CVE-2024-46802",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46802"
},
{
"name": "CVE-2025-39859",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39859"
},
{
"name": "CVE-2025-40313",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40313"
},
{
"name": "CVE-2023-52582",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52582"
},
{
"name": "CVE-2023-33053",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-33053"
},
{
"name": "CVE-2025-1152",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-1152"
},
{
"name": "CVE-2026-24051",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-24051"
},
{
"name": "CVE-2025-38015",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38015"
},
{
"name": "CVE-2024-26742",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26742"
},
{
"name": "CVE-2025-38449",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38449"
},
{
"name": "CVE-2025-21714",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21714"
},
{
"name": "CVE-2025-38261",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38261"
},
{
"name": "CVE-2024-36918",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36918"
},
{
"name": "CVE-2025-37853",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37853"
},
{
"name": "CVE-2025-69644",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-69644"
},
{
"name": "CVE-2022-49303",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49303"
},
{
"name": "CVE-2025-38126",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38126"
},
{
"name": "CVE-2023-46809",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-46809"
},
{
"name": "CVE-2025-59465",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-59465"
},
{
"name": "CVE-2025-39763",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39763"
},
{
"name": "CVE-2025-21972",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21972"
},
{
"name": "CVE-2023-54088",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54088"
},
{
"name": "CVE-2024-42320",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42320"
},
{
"name": "CVE-2025-38679",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38679"
},
{
"name": "CVE-2025-40271",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40271"
},
{
"name": "CVE-2024-53234",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53234"
},
{
"name": "CVE-2025-11961",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-11961"
},
{
"name": "CVE-2025-39877",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39877"
},
{
"name": "CVE-2022-3114",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-3114"
},
{
"name": "CVE-2023-52916",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52916"
},
{
"name": "CVE-2025-38064",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38064"
},
{
"name": "CVE-2026-22991",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22991"
},
{
"name": "CVE-2024-35937",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35937"
},
{
"name": "CVE-2022-50628",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50628"
},
{
"name": "CVE-2024-56718",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56718"
},
{
"name": "CVE-2024-43824",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43824"
},
{
"name": "CVE-2025-39886",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39886"
},
{
"name": "CVE-2022-50350",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50350"
},
{
"name": "CVE-2025-21831",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21831"
},
{
"name": "CVE-2022-50721",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50721"
},
{
"name": "CVE-2022-50095",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50095"
},
{
"name": "CVE-2025-40073",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40073"
},
{
"name": "CVE-2024-26662",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26662"
},
{
"name": "CVE-2026-3196",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-3196"
},
{
"name": "CVE-2025-61662",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-61662"
},
{
"name": "CVE-2025-68308",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68308"
},
{
"name": "CVE-2024-50217",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50217"
},
{
"name": "CVE-2021-0168",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-0168"
},
{
"name": "CVE-2026-22795",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22795"
},
{
"name": "CVE-2022-50479",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50479"
},
{
"name": "CVE-2022-50583",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50583"
},
{
"name": "CVE-2025-37806",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37806"
},
{
"name": "CVE-2024-38554",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38554"
},
{
"name": "CVE-2025-68822",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68822"
},
{
"name": "CVE-2025-40242",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40242"
},
{
"name": "CVE-2023-0030",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-0030"
},
{
"name": "CVE-2024-42110",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42110"
},
{
"name": "CVE-2025-37822",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37822"
},
{
"name": "CVE-2025-61727",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-61727"
},
{
"name": "CVE-2025-39838",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39838"
},
{
"name": "CVE-2025-37820",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37820"
},
{
"name": "CVE-2024-53179",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53179"
},
{
"name": "CVE-2024-57945",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57945"
},
{
"name": "CVE-2023-54233",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54233"
},
{
"name": "CVE-2024-43899",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43899"
},
{
"name": "CVE-2025-21986",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21986"
},
{
"name": "CVE-2019-15213",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-15213"
},
{
"name": "CVE-2025-38234",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38234"
},
{
"name": "CVE-2022-49935",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49935"
},
{
"name": "CVE-2021-44532",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-44532"
},
{
"name": "CVE-2025-38011",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38011"
},
{
"name": "CVE-2022-49534",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49534"
},
{
"name": "CVE-2024-57974",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57974"
},
{
"name": "CVE-2024-50012",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50012"
},
{
"name": "CVE-2025-68190",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68190"
},
{
"name": "CVE-2023-53010",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53010"
},
{
"name": "CVE-2024-35956",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35956"
},
{
"name": "CVE-2024-57888",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57888"
},
{
"name": "CVE-2024-35908",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35908"
},
{
"name": "CVE-2023-54237",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54237"
},
{
"name": "CVE-2025-37878",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37878"
},
{
"name": "CVE-2023-53424",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53424"
},
{
"name": "CVE-2026-23207",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23207"
},
{
"name": "CVE-2025-40252",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40252"
},
{
"name": "CVE-2022-49134",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49134"
},
{
"name": "CVE-2025-21946",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21946"
},
{
"name": "CVE-2025-21838",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21838"
},
{
"name": "CVE-2022-49333",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49333"
},
{
"name": "CVE-2023-53791",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53791"
},
{
"name": "CVE-2024-49994",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49994"
},
{
"name": "CVE-2025-53859",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-53859"
},
{
"name": "CVE-2019-19814",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-19814"
},
{
"name": "CVE-2022-49136",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49136"
},
{
"name": "CVE-2025-68255",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68255"
},
{
"name": "CVE-2025-47910",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-47910"
},
{
"name": "CVE-2023-54081",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54081"
},
{
"name": "CVE-2024-36898",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36898"
},
{
"name": "CVE-2024-44962",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44962"
},
{
"name": "CVE-2025-68322",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68322"
},
{
"name": "CVE-2024-35931",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35931"
},
{
"name": "CVE-2025-38702",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38702"
},
{
"name": "CVE-2026-22980",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22980"
},
{
"name": "CVE-2026-23138",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23138"
},
{
"name": "CVE-2025-39927",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39927"
},
{
"name": "CVE-2023-26551",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-26551"
},
{
"name": "CVE-2024-46857",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46857"
},
{
"name": "CVE-2024-58013",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58013"
},
{
"name": "CVE-2024-53210",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53210"
},
{
"name": "CVE-2023-54185",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54185"
},
{
"name": "CVE-2022-49342",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49342"
},
{
"name": "CVE-2015-8553",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-8553"
},
{
"name": "CVE-2025-40277",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40277"
},
{
"name": "CVE-2025-38250",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38250"
},
{
"name": "CVE-2024-36966",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36966"
},
{
"name": "CVE-2023-53332",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53332"
},
{
"name": "CVE-2024-35924",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35924"
},
{
"name": "CVE-2024-58095",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58095"
},
{
"name": "CVE-2024-45010",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45010"
},
{
"name": "CVE-2022-49471",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49471"
},
{
"name": "CVE-2025-68174",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68174"
},
{
"name": "CVE-2022-48976",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48976"
},
{
"name": "CVE-2025-21751",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21751"
},
{
"name": "CVE-2023-53753",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53753"
},
{
"name": "CVE-2024-41074",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41074"
},
{
"name": "CVE-2026-23234",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23234"
},
{
"name": "CVE-2025-40272",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40272"
},
{
"name": "CVE-2024-50106",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50106"
},
{
"name": "CVE-2025-23162",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23162"
},
{
"name": "CVE-2026-23133",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23133"
},
{
"name": "CVE-2025-71093",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71093"
},
{
"name": "CVE-2017-13694",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-13694"
},
{
"name": "CVE-2025-71102",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71102"
},
{
"name": "CVE-2026-23212",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23212"
},
{
"name": "CVE-2013-7445",
"url": "https://www.cve.org/CVERecord?id=CVE-2013-7445"
},
{
"name": "CVE-2026-23170",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23170"
},
{
"name": "CVE-2023-52701",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52701"
},
{
"name": "CVE-2024-49906",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49906"
},
{
"name": "CVE-2024-26647",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26647"
},
{
"name": "CVE-2025-68759",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68759"
},
{
"name": "CVE-2024-47809",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47809"
},
{
"name": "CVE-2026-23204",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23204"
},
{
"name": "CVE-2022-49317",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49317"
},
{
"name": "CVE-2026-23019",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23019"
},
{
"name": "CVE-2018-12928",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-12928"
},
{
"name": "CVE-2025-71188",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71188"
},
{
"name": "CVE-2023-38552",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-38552"
},
{
"name": "CVE-2024-40989",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40989"
},
{
"name": "CVE-2024-56607",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56607"
},
{
"name": "CVE-2025-40345",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40345"
},
{
"name": "CVE-2026-27142",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-27142"
},
{
"name": "CVE-2024-49904",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49904"
},
{
"name": "CVE-2023-53671",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53671"
},
{
"name": "CVE-2025-40354",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40354"
},
{
"name": "CVE-2024-26938",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26938"
},
{
"name": "CVE-2026-28417",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-28417"
},
{
"name": "CVE-2025-37931",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37931"
},
{
"name": "CVE-2024-35999",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35999"
},
{
"name": "CVE-2023-29942",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-29942"
},
{
"name": "CVE-2026-23125",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23125"
},
{
"name": "CVE-2026-0966",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-0966"
},
{
"name": "CVE-2022-48633",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48633"
},
{
"name": "CVE-2022-3238",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-3238"
},
{
"name": "CVE-2024-38557",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38557"
},
{
"name": "CVE-2026-22185",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22185"
},
{
"name": "CVE-2023-53781",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53781"
},
{
"name": "CVE-2023-53584",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53584"
},
{
"name": "CVE-2024-57809",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57809"
},
{
"name": "CVE-2025-38057",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38057"
},
{
"name": "CVE-2025-68733",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68733"
},
{
"name": "CVE-2024-56719",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56719"
},
{
"name": "CVE-2022-50418",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50418"
},
{
"name": "CVE-2023-53438",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53438"
},
{
"name": "CVE-2025-47906",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-47906"
},
{
"name": "CVE-2023-53460",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53460"
},
{
"name": "CVE-2026-23214",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23214"
},
{
"name": "CVE-2024-52559",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-52559"
},
{
"name": "CVE-2025-68188",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68188"
},
{
"name": "CVE-2025-40269",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40269"
},
{
"name": "CVE-2024-56671",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56671"
},
{
"name": "CVE-2025-68335",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68335"
},
{
"name": "CVE-2025-71079",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71079"
},
{
"name": "CVE-2025-62626",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-62626"
},
{
"name": "CVE-2025-39940",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39940"
},
{
"name": "CVE-2023-52751",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52751"
},
{
"name": "CVE-2022-49562",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49562"
},
{
"name": "CVE-2025-37861",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37861"
},
{
"name": "CVE-2023-53483",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53483"
},
{
"name": "CVE-2023-53673",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53673"
},
{
"name": "CVE-2025-37938",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37938"
},
{
"name": "CVE-2025-37746",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37746"
},
{
"name": "CVE-2022-38076",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-38076"
},
{
"name": "CVE-2025-38368",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38368"
},
{
"name": "CVE-2026-23178",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23178"
},
{
"name": "CVE-2025-59375",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-59375"
},
{
"name": "CVE-2025-31133",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-31133"
},
{
"name": "CVE-2026-22997",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22997"
},
{
"name": "CVE-2024-56368",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56368"
},
{
"name": "CVE-2025-40075",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40075"
},
{
"name": "CVE-2022-49172",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49172"
},
{
"name": "CVE-2024-40979",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40979"
},
{
"name": "CVE-2025-39977",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39977"
},
{
"name": "CVE-2025-38331",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38331"
},
{
"name": "CVE-2026-23240",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23240"
},
{
"name": "CVE-2025-68330",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68330"
},
{
"name": "CVE-2026-23228",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23228"
},
{
"name": "CVE-2024-49945",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49945"
},
{
"name": "CVE-2022-44033",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-44033"
},
{
"name": "CVE-2024-56757",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56757"
},
{
"name": "CVE-2023-53662",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53662"
},
{
"name": "CVE-2025-38069",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38069"
},
{
"name": "CVE-2022-49750",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49750"
},
{
"name": "CVE-2023-53707",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53707"
},
{
"name": "CVE-2023-53115",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53115"
},
{
"name": "CVE-2025-71196",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71196"
},
{
"name": "CVE-2025-21645",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21645"
},
{
"name": "CVE-2023-54107",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54107"
},
{
"name": "CVE-2022-48646",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48646"
},
{
"name": "CVE-2024-43912",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43912"
},
{
"name": "CVE-2024-35808",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35808"
},
{
"name": "CVE-2024-58012",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58012"
},
{
"name": "CVE-2025-50181",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-50181"
},
{
"name": "CVE-2025-61663",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-61663"
},
{
"name": "CVE-2025-68772",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68772"
},
{
"name": "CVE-2024-49891",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49891"
},
{
"name": "CVE-2024-36948",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36948"
},
{
"name": "CVE-2022-48887",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48887"
},
{
"name": "CVE-2024-40977",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40977"
},
{
"name": "CVE-2024-26948",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26948"
},
{
"name": "CVE-2023-53370",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53370"
},
{
"name": "CVE-2024-53187",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53187"
},
{
"name": "CVE-2023-45929",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-45929"
},
{
"name": "CVE-2025-68343",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68343"
},
{
"name": "CVE-2025-66382",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-66382"
},
{
"name": "CVE-2024-57795",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57795"
},
{
"name": "CVE-2025-37855",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37855"
},
{
"name": "CVE-2025-21816",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21816"
},
{
"name": "CVE-2021-33115",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-33115"
},
{
"name": "CVE-2025-21780",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21780"
},
{
"name": "CVE-2020-26559",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-26559"
},
{
"name": "CVE-2024-12705",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-12705"
},
{
"name": "CVE-2025-69421",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-69421"
},
{
"name": "CVE-2020-26140",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-26140"
},
{
"name": "CVE-2024-39508",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39508"
},
{
"name": "CVE-2026-23191",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23191"
},
{
"name": "CVE-2026-32249",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-32249"
},
{
"name": "CVE-2025-37899",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37899"
},
{
"name": "CVE-2026-23078",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23078"
},
{
"name": "CVE-2025-40362",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40362"
},
{
"name": "CVE-2025-68201",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68201"
},
{
"name": "CVE-2024-43831",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43831"
},
{
"name": "CVE-2023-30630",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-30630"
},
{
"name": "CVE-2025-40289",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40289"
},
{
"name": "CVE-2026-23169",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23169"
},
{
"name": "CVE-2025-38330",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38330"
},
{
"name": "CVE-2025-58188",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-58188"
},
{
"name": "CVE-2017-13693",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-13693"
},
{
"name": "CVE-2025-68768",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68768"
},
{
"name": "CVE-2024-50284",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50284"
},
{
"name": "CVE-2022-49306",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49306"
},
{
"name": "CVE-2024-49898",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49898"
},
{
"name": "CVE-2025-36423",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-36423"
},
{
"name": "CVE-2022-49622",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49622"
},
{
"name": "CVE-2025-68785",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68785"
},
{
"name": "CVE-2024-50211",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50211"
},
{
"name": "CVE-2025-38507",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38507"
},
{
"name": "CVE-2022-50284",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50284"
},
{
"name": "CVE-2025-39989",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39989"
},
{
"name": "CVE-2023-6240",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-6240"
},
{
"name": "CVE-2025-38014",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38014"
},
{
"name": "CVE-2025-22028",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22028"
},
{
"name": "CVE-2024-41008",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41008"
},
{
"name": "CVE-2024-27035",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27035"
},
{
"name": "CVE-2023-53218",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53218"
},
{
"name": "CVE-2022-25836",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-25836"
},
{
"name": "CVE-2024-37354",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-37354"
},
{
"name": "CVE-2025-68808",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68808"
},
{
"name": "CVE-2025-4674",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-4674"
},
{
"name": "CVE-2025-29934",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-29934"
},
{
"name": "CVE-2024-27005",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27005"
},
{
"name": "CVE-2025-68223",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68223"
},
{
"name": "CVE-2022-49133",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49133"
},
{
"name": "CVE-2024-36951",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36951"
},
{
"name": "CVE-2025-68783",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68783"
},
{
"name": "CVE-2025-71147",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71147"
},
{
"name": "CVE-2025-38438",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38438"
},
{
"name": "CVE-2025-40032",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40032"
},
{
"name": "CVE-2023-26555",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-26555"
},
{
"name": "CVE-2023-1193",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-1193"
},
{
"name": "CVE-2025-71220",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71220"
},
{
"name": "CVE-2024-46806",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46806"
},
{
"name": "CVE-2022-50073",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50073"
},
{
"name": "CVE-2025-68724",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68724"
},
{
"name": "CVE-2025-5278",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-5278"
},
{
"name": "CVE-2026-23103",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23103"
},
{
"name": "CVE-2026-23074",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23074"
},
{
"name": "CVE-2025-68786",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68786"
},
{
"name": "CVE-2025-39732",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39732"
},
{
"name": "CVE-2022-50393",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50393"
},
{
"name": "CVE-2025-68779",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68779"
},
{
"name": "CVE-2024-56433",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56433"
},
{
"name": "CVE-2025-21819",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21819"
},
{
"name": "CVE-2025-48514",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-48514"
},
{
"name": "CVE-2024-41030",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41030"
},
{
"name": "CVE-2025-71199",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71199"
},
{
"name": "CVE-2024-47664",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47664"
},
{
"name": "CVE-2024-36915",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36915"
},
{
"name": "CVE-2026-25749",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-25749"
},
{
"name": "CVE-2024-49504",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49504"
},
{
"name": "CVE-2025-38118",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38118"
},
{
"name": "CVE-2023-0464",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-0464"
},
{
"name": "CVE-2023-53367",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53367"
},
{
"name": "CVE-2022-50500",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50500"
},
{
"name": "CVE-2019-14899",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-14899"
},
{
"name": "CVE-2022-29526",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-29526"
},
{
"name": "CVE-2024-53098",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53098"
},
{
"name": "CVE-2025-68797",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68797"
},
{
"name": "CVE-2024-49968",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49968"
},
{
"name": "CVE-2025-68358",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68358"
},
{
"name": "CVE-2025-40206",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40206"
},
{
"name": "CVE-2026-23180",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23180"
},
{
"name": "CVE-2021-0164",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-0164"
},
{
"name": "CVE-2024-46870",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46870"
},
{
"name": "CVE-2022-49178",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49178"
},
{
"name": "CVE-2024-22195",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-22195"
},
{
"name": "CVE-2023-23931",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-23931"
},
{
"name": "CVE-2024-49929",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49929"
},
{
"name": "CVE-2025-40257",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40257"
},
{
"name": "CVE-2023-53748",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53748"
},
{
"name": "CVE-2024-26740",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26740"
},
{
"name": "CVE-2022-49173",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49173"
},
{
"name": "CVE-2024-45781",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45781"
},
{
"name": "CVE-2025-71125",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71125"
},
{
"name": "CVE-2025-21947",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21947"
},
{
"name": "CVE-2024-53056",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53056"
},
{
"name": "CVE-2022-50551",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50551"
},
{
"name": "CVE-2026-26269",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-26269"
},
{
"name": "CVE-2024-43872",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43872"
},
{
"name": "CVE-2025-71108",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71108"
},
{
"name": "CVE-2022-49401",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49401"
},
{
"name": "CVE-2025-71069",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71069"
},
{
"name": "CVE-2025-68312",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68312"
},
{
"name": "CVE-2025-68284",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68284"
},
{
"name": "CVE-2025-68194",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68194"
},
{
"name": "CVE-2023-52939",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52939"
},
{
"name": "CVE-2024-14027",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-14027"
},
{
"name": "CVE-2025-38269",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38269"
},
{
"name": "CVE-2025-69649",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-69649"
},
{
"name": "CVE-2024-53175",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53175"
},
{
"name": "CVE-2025-21734",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21734"
},
{
"name": "CVE-2024-49859",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49859"
},
{
"name": "CVE-2025-40336",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40336"
},
{
"name": "CVE-2025-37945",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37945"
},
{
"name": "CVE-2025-71195",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71195"
},
{
"name": "CVE-2022-49766",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49766"
},
{
"name": "CVE-2025-6141",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-6141"
},
{
"name": "CVE-2025-22043",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22043"
},
{
"name": "CVE-2024-49569",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49569"
},
{
"name": "CVE-2025-61984",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-61984"
},
{
"name": "CVE-2023-52569",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52569"
},
{
"name": "CVE-2024-56609",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56609"
},
{
"name": "CVE-2022-49940",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49940"
},
{
"name": "CVE-2026-23083",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23083"
},
{
"name": "CVE-2025-38422",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38422"
},
{
"name": "CVE-2024-56611",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56611"
},
{
"name": "CVE-2025-21927",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21927"
},
{
"name": "CVE-2026-23088",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23088"
},
{
"name": "CVE-2020-25743",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-25743"
},
{
"name": "CVE-2022-50167",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50167"
},
{
"name": "CVE-2025-68183",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68183"
},
{
"name": "CVE-2026-27704",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-27704"
},
{
"name": "CVE-2022-48064",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48064"
},
{
"name": "CVE-2023-45896",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-45896"
},
{
"name": "CVE-2025-37903",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37903"
},
{
"name": "CVE-2025-68774",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68774"
},
{
"name": "CVE-2024-49940",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49940"
},
{
"name": "CVE-2025-40263",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40263"
},
{
"name": "CVE-2021-3735",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-3735"
},
{
"name": "CVE-2025-40353",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40353"
},
{
"name": "CVE-2024-46861",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46861"
},
{
"name": "CVE-2025-40222",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40222"
},
{
"name": "CVE-2022-50634",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50634"
},
{
"name": "CVE-2025-52881",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-52881"
},
{
"name": "CVE-2025-54514",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-54514"
},
{
"name": "CVE-2025-71202",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71202"
},
{
"name": "CVE-2015-7837",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-7837"
},
{
"name": "CVE-2025-0677",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-0677"
},
{
"name": "CVE-2024-45780",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45780"
},
{
"name": "CVE-2024-46749",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46749"
},
{
"name": "CVE-2022-50492",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50492"
},
{
"name": "CVE-2024-49888",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49888"
},
{
"name": "CVE-2022-50406",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50406"
},
{
"name": "CVE-2023-26552",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-26552"
},
{
"name": "CVE-2024-49921",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49921"
},
{
"name": "CVE-2024-5535",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-5535"
},
{
"name": "CVE-2026-23108",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23108"
},
{
"name": "CVE-2025-71180",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71180"
},
{
"name": "CVE-2025-38232",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38232"
},
{
"name": "CVE-2025-68244",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68244"
},
{
"name": "CVE-2025-59691",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-59691"
},
{
"name": "CVE-2024-46830",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46830"
},
{
"name": "CVE-2023-52481",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52481"
},
{
"name": "CVE-2023-52888",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52888"
},
{
"name": "CVE-2025-22057",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22057"
},
{
"name": "CVE-2024-47666",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47666"
},
{
"name": "CVE-2025-22868",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22868"
},
{
"name": "CVE-2025-40278",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40278"
},
{
"name": "CVE-2023-0160",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-0160"
},
{
"name": "CVE-2024-50056",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50056"
},
{
"name": "CVE-2025-71194",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71194"
},
{
"name": "CVE-2026-1788",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-1788"
},
{
"name": "CVE-2023-53721",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53721"
},
{
"name": "CVE-2025-22113",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22113"
},
{
"name": "CVE-2025-40342",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40342"
},
{
"name": "CVE-2022-50256",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50256"
},
{
"name": "CVE-2024-42091",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42091"
},
{
"name": "CVE-2024-27983",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27983"
},
{
"name": "CVE-2025-37907",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37907"
},
{
"name": "CVE-2024-38625",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38625"
},
{
"name": "CVE-2025-23085",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23085"
},
{
"name": "CVE-2026-22796",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22796"
},
{
"name": "CVE-2023-4010",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-4010"
},
{
"name": "CVE-2025-38425",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38425"
},
{
"name": "CVE-2024-46727",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46727"
},
{
"name": "CVE-2023-54028",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54028"
},
{
"name": "CVE-2024-42129",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42129"
},
{
"name": "CVE-2023-54105",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54105"
},
{
"name": "CVE-2018-17977",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-17977"
},
{
"name": "CVE-2019-1010204",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-1010204"
},
{
"name": "CVE-2023-53992",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53992"
},
{
"name": "CVE-2026-26960",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-26960"
},
{
"name": "CVE-2025-40210",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40210"
},
{
"name": "CVE-2022-50354",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50354"
},
{
"name": "CVE-2025-61724",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-61724"
},
{
"name": "CVE-2026-22999",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22999"
},
{
"name": "CVE-2025-21812",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21812"
},
{
"name": "CVE-2025-71082",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71082"
},
{
"name": "CVE-2025-12801",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-12801"
},
{
"name": "CVE-2024-58015",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58015"
},
{
"name": "CVE-2026-23068",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23068"
},
{
"name": "CVE-2024-41079",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41079"
},
{
"name": "CVE-2025-68765",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68765"
},
{
"name": "CVE-2026-23089",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23089"
},
{
"name": "CVE-2024-43823",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43823"
},
{
"name": "CVE-2023-52589",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52589"
},
{
"name": "CVE-2022-41848",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-41848"
},
{
"name": "CVE-2026-23216",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23216"
},
{
"name": "CVE-2023-53434",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53434"
},
{
"name": "CVE-2023-29935",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-29935"
},
{
"name": "CVE-2023-35061",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-35061"
},
{
"name": "CVE-2025-71132",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71132"
},
{
"name": "CVE-2025-71225",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71225"
},
{
"name": "CVE-2026-21636",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-21636"
},
{
"name": "CVE-2026-23239",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23239"
},
{
"name": "CVE-2021-0172",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-0172"
},
{
"name": "CVE-2024-47662",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47662"
},
{
"name": "CVE-2018-12930",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-12930"
},
{
"name": "CVE-2026-23071",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23071"
},
{
"name": "CVE-2024-49970",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49970"
},
{
"name": "CVE-2024-41067",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41067"
},
{
"name": "CVE-2024-26844",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26844"
},
{
"name": "CVE-2025-23141",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23141"
},
{
"name": "CVE-2026-23056",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23056"
},
{
"name": "CVE-2025-40193",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40193"
},
{
"name": "CVE-2023-32644",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-32644"
},
{
"name": "CVE-2025-71077",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71077"
},
{
"name": "CVE-2025-21908",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21908"
},
{
"name": "CVE-2024-46681",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46681"
},
{
"name": "CVE-2024-36927",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36927"
},
{
"name": "CVE-2025-61732",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-61732"
},
{
"name": "CVE-2025-61723",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-61723"
},
{
"name": "CVE-2025-9232",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-9232"
},
{
"name": "CVE-2025-40012",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40012"
},
{
"name": "CVE-2025-40279",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40279"
},
{
"name": "CVE-2026-0964",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-0964"
},
{
"name": "CVE-2025-68328",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68328"
},
{
"name": "CVE-2023-53178",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53178"
},
{
"name": "CVE-2024-47141",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47141"
},
{
"name": "CVE-2024-8354",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-8354"
},
{
"name": "CVE-2023-54323",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54323"
},
{
"name": "CVE-2025-37952",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37952"
},
{
"name": "CVE-2023-45803",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-45803"
},
{
"name": "CVE-2025-0689",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-0689"
},
{
"name": "CVE-2022-50316",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50316"
},
{
"name": "CVE-2023-31347",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-31347"
},
{
"name": "CVE-2025-40084",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40084"
},
{
"name": "CVE-2025-22111",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22111"
},
{
"name": "CVE-2023-53657",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53657"
},
{
"name": "CVE-2024-49915",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49915"
},
{
"name": "CVE-2026-23063",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23063"
},
{
"name": "CVE-2025-55132",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-55132"
},
{
"name": "CVE-2023-52732",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52732"
},
{
"name": "CVE-2022-49759",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49759"
},
{
"name": "CVE-2026-23073",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23073"
},
{
"name": "CVE-2022-49167",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49167"
},
{
"name": "CVE-2025-68311",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68311"
},
{
"name": "CVE-2026-27903",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-27903"
},
{
"name": "CVE-2023-54023",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54023"
},
{
"name": "CVE-2024-27056",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27056"
},
{
"name": "CVE-2023-31082",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-31082"
},
{
"name": "CVE-2024-41088",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41088"
},
{
"name": "CVE-2025-0690",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-0690"
},
{
"name": "CVE-2025-71114",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71114"
},
{
"name": "CVE-2023-53052",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53052"
},
{
"name": "CVE-2026-23058",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23058"
},
{
"name": "CVE-2022-49234",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49234"
},
{
"name": "CVE-2022-50163",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50163"
},
{
"name": "CVE-2024-36922",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36922"
},
{
"name": "CVE-2025-71067",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71067"
},
{
"name": "CVE-2024-49919",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49919"
},
{
"name": "CVE-2026-23238",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23238"
},
{
"name": "CVE-2025-71182",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71182"
},
{
"name": "CVE-2020-26556",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-26556"
},
{
"name": "CVE-2025-46394",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-46394"
},
{
"name": "CVE-2025-66471",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-66471"
},
{
"name": "CVE-2026-23038",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23038"
},
{
"name": "CVE-2025-40341",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40341"
},
{
"name": "CVE-2025-38409",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38409"
},
{
"name": "CVE-2021-3826",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-3826"
},
{
"name": "CVE-2024-26699",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26699"
},
{
"name": "CVE-2024-57876",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57876"
},
{
"name": "CVE-2024-58019",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58019"
},
{
"name": "CVE-2026-25679",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-25679"
},
{
"name": "CVE-2026-22990",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22990"
},
{
"name": "CVE-2025-14017",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-14017"
},
{
"name": "CVE-2022-50390",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50390"
},
{
"name": "CVE-2026-23000",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23000"
},
{
"name": "CVE-2026-21441",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-21441"
},
{
"name": "CVE-2024-45337",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45337"
},
{
"name": "CVE-2025-71186",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71186"
},
{
"name": "CVE-2024-53220",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53220"
},
{
"name": "CVE-2026-23176",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23176"
},
{
"name": "CVE-2023-53539",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53539"
},
{
"name": "CVE-2025-40338",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40338"
},
{
"name": "CVE-2025-68821",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68821"
},
{
"name": "CVE-2025-31648",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-31648"
},
{
"name": "CVE-2026-1229",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-1229"
},
{
"name": "CVE-2025-0678",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-0678"
},
{
"name": "CVE-2024-41075",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41075"
},
{
"name": "CVE-2026-23026",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23026"
},
{
"name": "CVE-2024-56674",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56674"
},
{
"name": "CVE-2024-27982",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27982"
},
{
"name": "CVE-2025-40195",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40195"
},
{
"name": "CVE-2024-31884",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-31884"
},
{
"name": "CVE-2025-21976",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21976"
},
{
"name": "CVE-2019-1563",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-1563"
},
{
"name": "CVE-2026-23128",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23128"
},
{
"name": "CVE-2024-57975",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57975"
},
{
"name": "CVE-2023-53574",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53574"
},
{
"name": "CVE-2022-50166",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50166"
},
{
"name": "CVE-2025-61725",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-61725"
},
{
"name": "CVE-2025-68325",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68325"
},
{
"name": "CVE-2025-71190",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71190"
},
{
"name": "CVE-2024-56738",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56738"
},
{
"name": "CVE-2022-50778",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50778"
},
{
"name": "CVE-2024-42067",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42067"
},
{
"name": "CVE-2022-49971",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49971"
},
{
"name": "CVE-2025-71089",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71089"
},
{
"name": "CVE-2025-21693",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21693"
},
{
"name": "CVE-2025-71203",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71203"
},
{
"name": "CVE-2024-56657",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56657"
},
{
"name": "CVE-2025-39789",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39789"
},
{
"name": "CVE-2022-49124",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49124"
},
{
"name": "CVE-2024-49901",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49901"
},
{
"name": "CVE-2023-52700",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52700"
},
{
"name": "CVE-2024-56583",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56583"
},
{
"name": "CVE-2022-50195",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50195"
},
{
"name": "CVE-2025-40358",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40358"
},
{
"name": "CVE-2024-40998",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40998"
},
{
"name": "CVE-2024-56712",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56712"
},
{
"name": "CVE-2025-68318",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68318"
},
{
"name": "CVE-2022-49980",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49980"
},
{
"name": "CVE-2023-52634",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52634"
},
{
"name": "CVE-2025-22104",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22104"
},
{
"name": "CVE-2022-2795",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-2795"
},
{
"name": "CVE-2025-62526",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-62526"
},
{
"name": "CVE-2024-49918",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49918"
},
{
"name": "CVE-2025-68296",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68296"
},
{
"name": "CVE-2023-53785",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53785"
},
{
"name": "CVE-2025-55163",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-55163"
},
{
"name": "CVE-2024-45776",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45776"
},
{
"name": "CVE-2022-50090",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50090"
},
{
"name": "CVE-2025-40340",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40340"
},
{
"name": "CVE-2025-68332",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68332"
},
{
"name": "CVE-2020-14356",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-14356"
},
{
"name": "CVE-2025-68745",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68745"
},
{
"name": "CVE-2023-54263",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54263"
},
{
"name": "CVE-2025-71104",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71104"
},
{
"name": "CVE-2026-22978",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22978"
},
{
"name": "CVE-2023-53764",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53764"
},
{
"name": "CVE-2024-53687",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53687"
},
{
"name": "CVE-2025-39901",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39901"
},
{
"name": "CVE-2025-40283",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40283"
},
{
"name": "CVE-2025-5918",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-5918"
},
{
"name": "CVE-2024-38628",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38628"
},
{
"name": "CVE-2025-40324",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40324"
},
{
"name": "CVE-2025-38672",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38672"
},
{
"name": "CVE-2023-54181",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54181"
},
{
"name": "CVE-2025-0684",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-0684"
},
{
"name": "CVE-2025-10158",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-10158"
},
{
"name": "CVE-2025-68378",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68378"
},
{
"name": "CVE-2024-47794",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47794"
},
{
"name": "CVE-2026-23146",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23146"
},
{
"name": "CVE-2025-38272",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38272"
},
{
"name": "CVE-2024-10524",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-10524"
},
{
"name": "CVE-2025-40146",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40146"
},
{
"name": "CVE-2025-38359",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38359"
},
{
"name": "CVE-2019-20794",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-20794"
},
{
"name": "CVE-2023-53849",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53849"
},
{
"name": "CVE-2022-4543",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-4543"
},
{
"name": "CVE-2025-21899",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21899"
},
{
"name": "CVE-2024-35195",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35195"
},
{
"name": "CVE-2025-38129",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38129"
},
{
"name": "CVE-2026-23037",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23037"
},
{
"name": "CVE-2023-53627",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53627"
},
{
"name": "CVE-2025-40250",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40250"
},
{
"name": "CVE-2025-38091",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38091"
},
{
"name": "CVE-2023-53510",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53510"
},
{
"name": "CVE-2025-40264",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40264"
},
{
"name": "CVE-2025-38334",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38334"
},
{
"name": "CVE-2023-53575",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53575"
},
{
"name": "CVE-2022-49516",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49516"
},
{
"name": "CVE-2025-40778",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40778"
},
{
"name": "CVE-2025-38728",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38728"
},
{
"name": "CVE-2022-3523",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-3523"
},
{
"name": "CVE-2026-26157",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-26157"
},
{
"name": "CVE-2026-23001",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23001"
},
{
"name": "CVE-2023-38417",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-38417"
},
{
"name": "CVE-2025-68367",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68367"
},
{
"name": "CVE-2025-71224",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71224"
},
{
"name": "CVE-2025-22072",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22072"
},
{
"name": "CVE-2025-68820",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68820"
},
{
"name": "CVE-2021-45261",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-45261"
},
{
"name": "CVE-2025-40074",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40074"
},
{
"name": "CVE-2026-23193",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23193"
},
{
"name": "CVE-2025-40321",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40321"
},
{
"name": "CVE-2024-47736",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47736"
},
{
"name": "CVE-2023-53037",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53037"
},
{
"name": "CVE-2024-46842",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46842"
},
{
"name": "CVE-2025-71237",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71237"
},
{
"name": "CVE-2025-13462",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-13462"
},
{
"name": "CVE-2024-50112",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50112"
},
{
"name": "CVE-2025-69646",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-69646"
},
{
"name": "CVE-2023-54207",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54207"
},
{
"name": "CVE-2026-23215",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23215"
},
{
"name": "CVE-2024-28956",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-28956"
},
{
"name": "CVE-2025-68740",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68740"
},
{
"name": "CVE-2020-26142",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-26142"
},
{
"name": "CVE-2022-49955",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49955"
},
{
"name": "CVE-2023-53628",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53628"
},
{
"name": "CVE-2025-29943",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-29943"
},
{
"name": "CVE-2025-39978",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39978"
},
{
"name": "CVE-2023-31346",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-31346"
},
{
"name": "CVE-2024-9143",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-9143"
},
{
"name": "CVE-2025-40158",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40158"
},
{
"name": "CVE-2024-56201",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56201"
},
{
"name": "CVE-2025-38071",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38071"
},
{
"name": "CVE-2025-38140",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38140"
},
{
"name": "CVE-2022-50002",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50002"
},
{
"name": "CVE-2025-38621",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38621"
},
{
"name": "CVE-2025-68742",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68742"
},
{
"name": "CVE-2025-39908",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39908"
},
{
"name": "CVE-2026-24842",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-24842"
},
{
"name": "CVE-2024-49920",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49920"
},
{
"name": "CVE-2025-40282",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40282"
},
{
"name": "CVE-2026-23118",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23118"
},
{
"name": "CVE-2025-34034",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-34034"
},
{
"name": "CVE-2025-37984",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37984"
},
{
"name": "CVE-2025-59692",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-59692"
},
{
"name": "CVE-2022-50116",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50116"
},
{
"name": "CVE-2018-12931",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-12931"
},
{
"name": "CVE-2025-40168",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40168"
},
{
"name": "CVE-2025-37856",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37856"
},
{
"name": "CVE-2022-50224",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50224"
},
{
"name": "CVE-2025-22874",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22874"
},
{
"name": "CVE-2020-13791",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-13791"
},
{
"name": "CVE-2026-23950",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23950"
},
{
"name": "CVE-2024-49990",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49990"
},
{
"name": "CVE-2020-15802",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-15802"
},
{
"name": "CVE-2020-24240",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-24240"
},
{
"name": "CVE-2024-46718",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46718"
},
{
"name": "CVE-2025-68816",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68816"
},
{
"name": "CVE-2024-41045",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41045"
},
{
"name": "CVE-2023-53545",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53545"
},
{
"name": "CVE-2022-50552",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50552"
},
{
"name": "CVE-2021-0066",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-0066"
},
{
"name": "CVE-2025-38333",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38333"
},
{
"name": "CVE-2023-53376",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53376"
},
{
"name": "CVE-2023-53538",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53538"
},
{
"name": "CVE-2025-68192",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68192"
},
{
"name": "CVE-2024-5569",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-5569"
},
{
"name": "CVE-2025-68379",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68379"
},
{
"name": "CVE-2022-50357",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50357"
},
{
"name": "CVE-2024-57952",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57952"
},
{
"name": "CVE-2025-68256",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68256"
},
{
"name": "CVE-2025-68777",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68777"
},
{
"name": "CVE-2023-52671",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52671"
},
{
"name": "CVE-2022-50303",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50303"
},
{
"name": "CVE-2024-35870",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35870"
},
{
"name": "CVE-2025-68254",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68254"
},
{
"name": "CVE-2026-23221",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23221"
},
{
"name": "CVE-2025-38059",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38059"
},
{
"name": "CVE-2024-27014",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27014"
},
{
"name": "CVE-2024-36013",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36013"
},
{
"name": "CVE-2024-53176",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53176"
},
{
"name": "CVE-2025-37956",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37956"
},
{
"name": "CVE-2025-40196",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40196"
},
{
"name": "CVE-2024-49880",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49880"
},
{
"name": "CVE-2023-52676",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52676"
},
{
"name": "CVE-2025-38117",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38117"
},
{
"name": "CVE-2017-13165",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-13165"
},
{
"name": "CVE-2025-38556",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38556"
},
{
"name": "CVE-2025-68171",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68171"
},
{
"name": "CVE-2025-39932",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39932"
},
{
"name": "CVE-2024-47683",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47683"
},
{
"name": "CVE-2023-6237",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-6237"
},
{
"name": "CVE-2024-46811",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46811"
},
{
"name": "CVE-2025-21985",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21985"
},
{
"name": "CVE-2025-22109",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22109"
},
{
"name": "CVE-2025-38300",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38300"
},
{
"name": "CVE-2025-40040",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40040"
},
{
"name": "CVE-2023-53635",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53635"
},
{
"name": "CVE-2025-39810",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39810"
},
{
"name": "CVE-2026-22982",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22982"
},
{
"name": "CVE-2025-23132",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23132"
},
{
"name": "CVE-2024-47678",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47678"
},
{
"name": "CVE-2022-49531",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49531"
},
{
"name": "CVE-2022-49504",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49504"
},
{
"name": "CVE-2025-1376",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-1376"
},
{
"name": "CVE-2022-49810",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49810"
},
{
"name": "CVE-2025-47912",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-47912"
},
{
"name": "CVE-2025-71109",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71109"
},
{
"name": "CVE-2023-26586",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-26586"
},
{
"name": "CVE-2025-38373",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38373"
},
{
"name": "CVE-2025-66861",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-66861"
},
{
"name": "CVE-2025-40095",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40095"
},
{
"name": "CVE-2025-37957",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37957"
},
{
"name": "CVE-2025-38369",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38369"
},
{
"name": "CVE-2023-43804",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-43804"
},
{
"name": "CVE-2024-44950",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44950"
},
{
"name": "CVE-2025-39759",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39759"
},
{
"name": "CVE-2022-50332",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50332"
},
{
"name": "CVE-2023-53822",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53822"
},
{
"name": "CVE-2024-27408",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27408"
},
{
"name": "CVE-2025-71222",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71222"
},
{
"name": "CVE-2022-50461",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50461"
},
{
"name": "CVE-2025-21801",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21801"
},
{
"name": "CVE-2023-26554",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-26554"
},
{
"name": "CVE-2025-38486",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38486"
},
{
"name": "CVE-2021-26934",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-26934"
},
{
"name": "CVE-2023-53466",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53466"
},
{
"name": "CVE-2025-21629",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21629"
},
{
"name": "CVE-2025-71118",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71118"
},
{
"name": "CVE-2023-53168",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53168"
},
{
"name": "CVE-2022-49528",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49528"
},
{
"name": "CVE-2025-68160",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68160"
},
{
"name": "CVE-2022-45888",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-45888"
},
{
"name": "CVE-2022-49218",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49218"
},
{
"name": "CVE-2023-52749",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52749"
},
{
"name": "CVE-2025-39754",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39754"
},
{
"name": "CVE-2025-40286",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40286"
},
{
"name": "CVE-2022-49967",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49967"
},
{
"name": "CVE-2025-68327",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68327"
},
{
"name": "CVE-2024-2236",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-2236"
},
{
"name": "CVE-2022-49245",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49245"
},
{
"name": "CVE-2025-38098",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38098"
},
{
"name": "CVE-2023-52682",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52682"
},
{
"name": "CVE-2022-50871",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50871"
},
{
"name": "CVE-2025-71150",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71150"
},
{
"name": "CVE-2025-71229",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71229"
},
{
"name": "CVE-2026-23213",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23213"
},
{
"name": "CVE-2025-39958",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39958"
},
{
"name": "CVE-2018-8956",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-8956"
},
{
"name": "CVE-2025-40266",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40266"
},
{
"name": "CVE-2026-23091",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23091"
},
{
"name": "CVE-2025-68241",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68241"
},
{
"name": "CVE-2022-49420",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49420"
},
{
"name": "CVE-2022-40964",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-40964"
},
{
"name": "CVE-2026-3441",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-3441"
},
{
"name": "CVE-2024-36244",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36244"
},
{
"name": "CVE-2023-53149",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53149"
},
{
"name": "CVE-2026-23237",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23237"
},
{
"name": "CVE-2024-49987",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49987"
},
{
"name": "CVE-2025-60753",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-60753"
},
{
"name": "CVE-2022-50746",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50746"
},
{
"name": "CVE-2025-52565",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-52565"
},
{
"name": "CVE-2024-50034",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50034"
},
{
"name": "CVE-2025-38259",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38259"
},
{
"name": "CVE-2025-71192",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71192"
},
{
"name": "CVE-2023-53596",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53596"
},
{
"name": "CVE-2022-49943",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49943"
},
{
"name": "CVE-2022-50260",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50260"
},
{
"name": "CVE-2025-40135",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40135"
},
{
"name": "CVE-2026-23121",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23121"
},
{
"name": "CVE-2020-12319",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-12319"
},
{
"name": "CVE-2025-37951",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37951"
},
{
"name": "CVE-2023-50495",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-50495"
},
{
"name": "CVE-2024-49568",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49568"
},
{
"name": "CVE-2025-21750",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21750"
},
{
"name": "CVE-2024-36924",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36924"
},
{
"name": "CVE-2017-11164",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-11164"
},
{
"name": "CVE-2023-3397",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-3397"
},
{
"name": "CVE-2025-68734",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68734"
},
{
"name": "CVE-2024-26672",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26672"
},
{
"name": "CVE-2024-57924",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57924"
},
{
"name": "CVE-2025-37947",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37947"
},
{
"name": "CVE-2025-68776",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68776"
},
{
"name": "CVE-2025-61728",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-61728"
},
{
"name": "CVE-2025-71066",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71066"
},
{
"name": "CVE-2026-0965",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-0965"
},
{
"name": "CVE-2023-53806",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53806"
},
{
"name": "CVE-2025-21817",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21817"
},
{
"name": "CVE-2025-68972",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68972"
},
{
"name": "CVE-2025-68799",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68799"
},
{
"name": "CVE-2021-33139",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-33139"
},
{
"name": "CVE-2025-58186",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-58186"
},
{
"name": "CVE-2025-21825",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21825"
},
{
"name": "CVE-2025-38192",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38192"
},
{
"name": "CVE-2025-71236",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71236"
},
{
"name": "CVE-2025-68345",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68345"
},
{
"name": "CVE-2025-39800",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39800"
},
{
"name": "CVE-2024-50057",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50057"
},
{
"name": "CVE-2025-38343",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38343"
},
{
"name": "CVE-2025-71097",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71097"
},
{
"name": "CVE-2024-46808",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46808"
},
{
"name": "CVE-2026-26158",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-26158"
},
{
"name": "CVE-2025-38202",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38202"
},
{
"name": "CVE-2025-68288",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68288"
},
{
"name": "CVE-2025-38168",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38168"
},
{
"name": "CVE-2023-53547",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53547"
},
{
"name": "CVE-2019-20426",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-20426"
},
{
"name": "CVE-2025-71107",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71107"
},
{
"name": "CVE-2024-0727",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-0727"
},
{
"name": "CVE-2025-40310",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40310"
},
{
"name": "CVE-2026-29786",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-29786"
},
{
"name": "CVE-2025-58187",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-58187"
},
{
"name": "CVE-2025-40083",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40083"
},
{
"name": "CVE-2023-6129",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-6129"
},
{
"name": "CVE-2024-56584",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56584"
},
{
"name": "CVE-2026-23235",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23235"
},
{
"name": "CVE-2025-71111",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71111"
},
{
"name": "CVE-2022-4899",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-4899"
},
{
"name": "CVE-2025-71152",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71152"
},
{
"name": "CVE-2024-42139",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42139"
},
{
"name": "CVE-2024-56692",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56692"
},
{
"name": "CVE-2024-53196",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53196"
},
{
"name": "CVE-2025-38665",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38665"
},
{
"name": "CVE-2022-50212",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50212"
},
{
"name": "CVE-2026-23087",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23087"
},
{
"name": "CVE-2023-54259",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54259"
},
{
"name": "CVE-2025-68802",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68802"
},
{
"name": "CVE-2023-54067",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54067"
},
{
"name": "CVE-2025-1369",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-1369"
},
{
"name": "CVE-2022-3219",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-3219"
},
{
"name": "CVE-2025-68317",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68317"
},
{
"name": "CVE-2023-53231",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53231"
},
{
"name": "CVE-2025-71185",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71185"
},
{
"name": "CVE-2022-2961",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-2961"
},
{
"name": "CVE-2025-40331",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40331"
},
{
"name": "CVE-2025-4673",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-4673"
},
{
"name": "CVE-2022-49635",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49635"
},
{
"name": "CVE-2024-50017",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50017"
},
{
"name": "CVE-2026-23096",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23096"
},
{
"name": "CVE-2024-53241",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53241"
},
{
"name": "CVE-2025-38704",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38704"
},
{
"name": "CVE-2023-34969",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-34969"
},
{
"name": "CVE-2021-33155",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-33155"
},
{
"name": "CVE-2025-68337",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68337"
},
{
"name": "CVE-2024-57899",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57899"
},
{
"name": "CVE-2024-49928",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49928"
},
{
"name": "CVE-2025-21885",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21885"
},
{
"name": "CVE-2024-50187",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50187"
},
{
"name": "CVE-2022-50851",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50851"
},
{
"name": "CVE-2025-36001",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-36001"
},
{
"name": "CVE-2022-50464",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50464"
},
{
"name": "CVE-2025-38674",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38674"
},
{
"name": "CVE-2025-40093",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40093"
},
{
"name": "CVE-2020-26560",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-26560"
},
{
"name": "CVE-2024-26714",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26714"
},
{
"name": "CVE-2024-45777",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45777"
},
{
"name": "CVE-2025-38040",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38040"
},
{
"name": "CVE-2024-40954",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40954"
},
{
"name": "CVE-2022-49965",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49965"
},
{
"name": "CVE-2025-54771",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-54771"
},
{
"name": "CVE-2024-0564",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-0564"
},
{
"name": "CVE-2025-39825",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39825"
},
{
"name": "CVE-2025-71131",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71131"
},
{
"name": "CVE-2022-49961",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49961"
},
{
"name": "CVE-2025-69651",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-69651"
},
{
"name": "CVE-2025-38552",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38552"
},
{
"name": "CVE-2025-40335",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40335"
},
{
"name": "CVE-2025-40149",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40149"
},
{
"name": "CVE-2024-58098",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58098"
},
{
"name": "CVE-2025-22871",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22871"
},
{
"name": "CVE-2022-28667",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-28667"
},
{
"name": "CVE-2023-53383",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53383"
},
{
"name": "CVE-2024-46717",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46717"
},
{
"name": "CVE-2024-25743",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-25743"
},
{
"name": "CVE-2022-50704",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50704"
},
{
"name": "CVE-2025-40164",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40164"
},
{
"name": "CVE-2023-54125",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54125"
},
{
"name": "CVE-2025-10911",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-10911"
},
{
"name": "CVE-2026-23164",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23164"
},
{
"name": "CVE-2024-41036",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41036"
},
{
"name": "CVE-2023-53751",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53751"
},
{
"name": "CVE-2025-0033",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-0033"
},
{
"name": "CVE-2023-53743",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53743"
},
{
"name": "CVE-2024-42319",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42319"
},
{
"name": "CVE-2025-37928",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37928"
},
{
"name": "CVE-2017-13716",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-13716"
},
{
"name": "CVE-2024-22018",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-22018"
},
{
"name": "CVE-2025-71116",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71116"
},
{
"name": "CVE-2022-40735",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-40735"
},
{
"name": "CVE-2024-36024",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36024"
},
{
"name": "CVE-2025-21723",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21723"
},
{
"name": "CVE-2023-54190",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54190"
},
{
"name": "CVE-2023-52879",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52879"
},
{
"name": "CVE-2025-68281",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68281"
},
{
"name": "CVE-2023-52837",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52837"
},
{
"name": "CVE-2025-38440",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38440"
},
{
"name": "CVE-2026-23124",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23124"
},
{
"name": "CVE-2023-52981",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52981"
},
{
"name": "CVE-2024-53224",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53224"
},
{
"name": "CVE-2024-49910",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49910"
},
{
"name": "CVE-2025-68362",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68362"
},
{
"name": "CVE-2023-53105",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53105"
},
{
"name": "CVE-2025-68236",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68236"
},
{
"name": "CVE-2024-39286",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39286"
},
{
"name": "CVE-2025-14524",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-14524"
},
{
"name": "CVE-2024-49855",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49855"
},
{
"name": "CVE-2024-47081",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47081"
},
{
"name": "CVE-2025-68333",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68333"
},
{
"name": "CVE-2024-47689",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47689"
},
{
"name": "CVE-2025-71160",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71160"
},
{
"name": "CVE-2025-71232",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71232"
},
{
"name": "CVE-2023-52625",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52625"
},
{
"name": "CVE-2023-53353",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53353"
},
{
"name": "CVE-2024-58096",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58096"
},
{
"name": "CVE-2025-38225",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38225"
},
{
"name": "CVE-2023-53401",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53401"
},
{
"name": "CVE-2025-22037",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22037"
},
{
"name": "CVE-2023-53702",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53702"
},
{
"name": "CVE-2025-68290",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68290"
},
{
"name": "CVE-2025-40280",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40280"
},
{
"name": "CVE-2024-26842",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26842"
},
{
"name": "CVE-2025-40099",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40099"
},
{
"name": "CVE-2023-54059",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54059"
},
{
"name": "CVE-2025-71162",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71162"
},
{
"name": "CVE-2021-0170",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-0170"
},
{
"name": "CVE-2024-40966",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40966"
},
{
"name": "CVE-2024-53133",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53133"
},
{
"name": "CVE-2026-23075",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23075"
},
{
"name": "CVE-2022-50571",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50571"
},
{
"name": "CVE-2021-31879",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-31879"
},
{
"name": "CVE-2026-23120",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23120"
},
{
"name": "CVE-2025-40180",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40180"
},
{
"name": "CVE-2022-49393",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49393"
},
{
"name": "CVE-2024-6119",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-6119"
},
{
"name": "CVE-2025-68803",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68803"
},
{
"name": "CVE-2026-22996",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22996"
},
{
"name": "CVE-2024-53091",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53091"
},
{
"name": "CVE-2025-39851",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39851"
},
{
"name": "CVE-2025-71204",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71204"
},
{
"name": "CVE-2025-68331",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68331"
},
{
"name": "CVE-2025-38244",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38244"
},
{
"name": "CVE-2022-29217",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-29217"
},
{
"name": "CVE-2024-26758",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26758"
},
{
"name": "CVE-2025-38080",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38080"
},
{
"name": "CVE-2023-32651",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-32651"
},
{
"name": "CVE-2025-37747",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37747"
},
{
"name": "CVE-2026-2297",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-2297"
},
{
"name": "CVE-2026-23105",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23105"
},
{
"name": "CVE-2023-53036",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53036"
},
{
"name": "CVE-2025-38615",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38615"
},
{
"name": "CVE-2025-58181",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-58181"
},
{
"name": "CVE-2025-71115",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71115"
},
{
"name": "CVE-2026-22976",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22976"
},
{
"name": "CVE-2022-50862",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50862"
},
{
"name": "CVE-2025-1118",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-1118"
},
{
"name": "CVE-2024-50166",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50166"
},
{
"name": "CVE-2024-35862",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35862"
},
{
"name": "CVE-2023-53355",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53355"
},
{
"name": "CVE-2022-25265",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-25265"
},
{
"name": "CVE-2026-0967",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-0967"
},
{
"name": "CVE-2026-23181",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23181"
},
{
"name": "CVE-2025-37944",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37944"
},
{
"name": "CVE-2023-53558",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53558"
},
{
"name": "CVE-2025-47914",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-47914"
},
{
"name": "CVE-2025-68214",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68214"
},
{
"name": "CVE-2025-38703",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38703"
},
{
"name": "CVE-2026-23141",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23141"
},
{
"name": "CVE-2026-22860",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22860"
},
{
"name": "CVE-2025-36365",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-36365"
},
{
"name": "CVE-2025-9403",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-9403"
},
{
"name": "CVE-2025-40247",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40247"
},
{
"name": "CVE-2023-1255",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-1255"
},
{
"name": "CVE-2024-56641",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56641"
},
{
"name": "CVE-2024-43842",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43842"
},
{
"name": "CVE-2025-0686",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-0686"
},
{
"name": "CVE-2025-21739",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21739"
},
{
"name": "CVE-2024-49992",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49992"
},
{
"name": "CVE-2025-68781",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68781"
},
{
"name": "CVE-2025-39753",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39753"
},
{
"name": "CVE-2025-69418",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-69418"
},
{
"name": "CVE-2026-23182",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23182"
},
{
"name": "CVE-2021-0173",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-0173"
},
{
"name": "CVE-2025-71112",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71112"
},
{
"name": "CVE-2023-54285",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54285"
},
{
"name": "CVE-2024-45778",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45778"
},
{
"name": "CVE-2026-23086",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23086"
},
{
"name": "CVE-2024-47661",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47661"
},
{
"name": "CVE-2026-28418",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-28418"
},
{
"name": "CVE-2023-54151",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54151"
},
{
"name": "CVE-2025-22022",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22022"
},
{
"name": "CVE-2025-66864",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-66864"
},
{
"name": "CVE-2024-46803",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46803"
},
{
"name": "CVE-2025-22869",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22869"
},
{
"name": "CVE-2025-59466",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-59466"
},
{
"name": "CVE-2025-40192",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40192"
},
{
"name": "CVE-2025-38544",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38544"
},
{
"name": "CVE-2025-39797",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39797"
},
{
"name": "CVE-2025-68818",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68818"
},
{
"name": "CVE-2022-36351",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-36351"
},
{
"name": "CVE-2023-52921",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52921"
},
{
"name": "CVE-2025-15468",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-15468"
},
{
"name": "CVE-2024-36478",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36478"
},
{
"name": "CVE-2024-43832",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43832"
},
{
"name": "CVE-2026-1299",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-1299"
},
{
"name": "CVE-2024-54683",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-54683"
},
{
"name": "CVE-2025-1150",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-1150"
},
{
"name": "CVE-2024-46720",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46720"
},
{
"name": "CVE-2024-26658",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26658"
},
{
"name": "CVE-2026-2243",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-2243"
},
{
"name": "CVE-2025-38198",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38198"
},
{
"name": "CVE-2025-58189",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-58189"
},
{
"name": "CVE-2022-36087",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-36087"
},
{
"name": "CVE-2024-38564",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38564"
},
{
"name": "CVE-2021-0174",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-0174"
},
{
"name": "CVE-2025-8746",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-8746"
},
{
"name": "CVE-2025-36442",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-36442"
},
{
"name": "CVE-2025-38006",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38006"
},
{
"name": "CVE-2025-40102",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40102"
},
{
"name": "CVE-2026-0968",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-0968"
},
{
"name": "CVE-2025-40170",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40170"
},
{
"name": "CVE-2025-38437",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38437"
},
{
"name": "CVE-2025-40160",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40160"
},
{
"name": "CVE-2023-7008",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-7008"
},
{
"name": "CVE-2024-45779",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45779"
},
{
"name": "CVE-2025-40284",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40284"
},
{
"name": "CVE-2025-38125",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38125"
},
{
"name": "CVE-2025-40077",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40077"
},
{
"name": "CVE-2024-57857",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57857"
},
{
"name": "CVE-2024-4603",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-4603"
},
{
"name": "CVE-2022-50213",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50213"
},
{
"name": "CVE-2024-46823",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46823"
},
{
"name": "CVE-2023-32642",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-32642"
},
{
"name": "CVE-2025-71227",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71227"
},
{
"name": "CVE-2024-46733",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46733"
},
{
"name": "CVE-2024-41014",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41014"
},
{
"name": "CVE-2022-50015",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50015"
},
{
"name": "CVE-2025-40071",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40071"
},
{
"name": "CVE-2024-7883",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-7883"
},
{
"name": "CVE-2024-50271",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50271"
},
{
"name": "CVE-2022-50772",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50772"
},
{
"name": "CVE-2024-56717",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56717"
},
{
"name": "CVE-2025-68366",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68366"
},
{
"name": "CVE-2024-56707",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56707"
},
{
"name": "CVE-2023-54234",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54234"
},
{
"name": "CVE-2022-45885",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-45885"
},
{
"name": "CVE-2022-49783",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49783"
},
{
"name": "CVE-2025-40305",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40305"
},
{
"name": "CVE-2016-2781",
"url": "https://www.cve.org/CVERecord?id=CVE-2016-2781"
},
{
"name": "CVE-2023-29383",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-29383"
},
{
"name": "CVE-2025-47153",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-47153"
},
{
"name": "CVE-2025-40080",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40080"
},
{
"name": "CVE-2024-53216",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53216"
},
{
"name": "CVE-2022-49539",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49539"
},
{
"name": "CVE-2024-36347",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36347"
},
{
"name": "CVE-2024-26869",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26869"
},
{
"name": "CVE-2025-22870",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22870"
},
{
"name": "CVE-2025-68815",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68815"
},
{
"name": "CVE-2021-20255",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-20255"
},
{
"name": "CVE-2022-48979",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48979"
},
{
"name": "CVE-2025-40307",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40307"
},
{
"name": "CVE-2025-71193",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71193"
},
{
"name": "CVE-2023-54180",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54180"
},
{
"name": "CVE-2026-23095",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23095"
},
{
"name": "CVE-2024-46848",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46848"
},
{
"name": "CVE-2025-68346",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68346"
},
{
"name": "CVE-2025-38081",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38081"
},
{
"name": "CVE-2024-36009",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36009"
},
{
"name": "CVE-2025-71163",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71163"
},
{
"name": "CVE-2024-36350",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36350"
},
{
"name": "CVE-2023-25951",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-25951"
},
{
"name": "CVE-2025-40211",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40211"
},
{
"name": "CVE-2023-53152",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53152"
},
{
"name": "CVE-2021-0308",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-0308"
},
{
"name": "CVE-2025-68315",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68315"
},
{
"name": "CVE-2024-50009",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50009"
},
{
"name": "CVE-2025-39850",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39850"
},
{
"name": "CVE-2022-1205",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-1205"
},
{
"name": "CVE-2023-45927",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-45927"
},
{
"name": "CVE-2020-25742",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-25742"
},
{
"name": "CVE-2022-0987",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-0987"
},
{
"name": "CVE-2025-71096",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71096"
},
{
"name": "CVE-2025-71095",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71095"
},
{
"name": "CVE-2025-40217",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40217"
},
{
"name": "CVE-2025-38199",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38199"
},
{
"name": "CVE-2025-39905",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39905"
},
{
"name": "CVE-2025-21944",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21944"
},
{
"name": "CVE-2022-50720",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50720"
},
{
"name": "CVE-2025-71105",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71105"
},
{
"name": "CVE-2023-50387",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-50387"
},
{
"name": "CVE-2022-49529",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49529"
},
{
"name": "CVE-2025-68266",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68266"
},
{
"name": "CVE-2024-27057",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27057"
},
{
"name": "CVE-2025-68771",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68771"
},
{
"name": "CVE-2025-39961",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39961"
},
{
"name": "CVE-2025-68363",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68363"
},
{
"name": "CVE-2024-54456",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-54456"
},
{
"name": "CVE-2024-26876",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26876"
},
{
"name": "CVE-2025-40248",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40248"
},
{
"name": "CVE-2023-52657",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52657"
},
{
"name": "CVE-2025-37876",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37876"
},
{
"name": "CVE-2024-58089",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58089"
},
{
"name": "CVE-2024-36331",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36331"
},
{
"name": "CVE-2026-27571",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-27571"
},
{
"name": "CVE-2025-39748",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39748"
},
{
"name": "CVE-2026-22984",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22984"
},
{
"name": "CVE-2026-27139",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-27139"
},
{
"name": "CVE-2022-49127",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49127"
},
{
"name": "CVE-2020-25741",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-25741"
},
{
"name": "CVE-2022-50748",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50748"
},
{
"name": "CVE-2023-53767",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53767"
},
{
"name": "CVE-2025-21667",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21667"
},
{
"name": "CVE-2025-9230",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-9230"
},
{
"name": "CVE-2023-49083",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-49083"
},
{
"name": "CVE-2025-21696",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21696"
},
{
"name": "CVE-2025-68303",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68303"
},
{
"name": "CVE-2025-21955",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21955"
},
{
"name": "CVE-2025-39863",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39863"
},
{
"name": "CVE-2025-40259",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40259"
},
{
"name": "CVE-2023-53180",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53180"
},
{
"name": "CVE-2026-28419",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-28419"
},
{
"name": "CVE-2025-8677",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-8677"
},
{
"name": "CVE-2025-38560",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38560"
},
{
"name": "CVE-2023-53385",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53385"
},
{
"name": "CVE-2026-23206",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23206"
},
{
"name": "CVE-2025-68757",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68757"
},
{
"name": "CVE-2024-46678",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46678"
},
{
"name": "CVE-2024-58097",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58097"
},
{
"name": "CVE-2023-53620",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53620"
},
{
"name": "CVE-2022-50539",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50539"
},
{
"name": "CVE-2025-71068",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71068"
},
{
"name": "CVE-2025-23130",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23130"
},
{
"name": "CVE-2022-49496",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49496"
},
{
"name": "CVE-2025-38349",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38349"
},
{
"name": "CVE-2024-56782",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56782"
},
{
"name": "CVE-2025-39957",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39957"
},
{
"name": "CVE-2025-1352",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-1352"
},
{
"name": "CVE-2023-53540",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53540"
},
{
"name": "CVE-2022-49552",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49552"
},
{
"name": "CVE-2024-4741",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-4741"
},
{
"name": "CVE-2023-53261",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53261"
},
{
"name": "CVE-2026-23033",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23033"
},
{
"name": "CVE-2025-39726",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39726"
},
{
"name": "CVE-2024-26759",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26759"
},
{
"name": "CVE-2025-39931",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39931"
},
{
"name": "CVE-2023-54187",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54187"
},
{
"name": "CVE-2026-22977",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22977"
},
{
"name": "CVE-2026-23145",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23145"
},
{
"name": "CVE-2022-44032",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-44032"
},
{
"name": "CVE-2024-57895",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57895"
},
{
"name": "CVE-2023-53240",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53240"
},
{
"name": "CVE-2025-13735",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-13735"
},
{
"name": "CVE-2023-53694",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53694"
},
{
"name": "CVE-2024-53195",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53195"
},
{
"name": "CVE-2024-35794",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35794"
},
{
"name": "CVE-2023-52829",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52829"
},
{
"name": "CVE-2026-23003",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23003"
},
{
"name": "CVE-2025-21891",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21891"
},
{
"name": "CVE-2025-38716",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38716"
},
{
"name": "CVE-2025-11187",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-11187"
},
{
"name": "CVE-2024-56660",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56660"
},
{
"name": "CVE-2026-23076",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23076"
},
{
"name": "CVE-2023-54145",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54145"
},
{
"name": "CVE-2025-38033",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38033"
},
{
"name": "CVE-2024-41023",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41023"
},
{
"name": "CVE-2024-47704",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47704"
},
{
"name": "CVE-2025-21672",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21672"
},
{
"name": "CVE-2024-35801",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35801"
},
{
"name": "CVE-2024-49978",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49978"
},
{
"name": "CVE-2024-36910",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36910"
},
{
"name": "CVE-2025-15079",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-15079"
},
{
"name": "CVE-2024-49870",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49870"
},
{
"name": "CVE-2025-36366",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-36366"
},
{
"name": "CVE-2024-42125",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42125"
},
{
"name": "CVE-2025-36123",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-36123"
},
{
"name": "CVE-2024-56737",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56737"
},
{
"name": "CVE-2025-68168",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68168"
},
{
"name": "CVE-2025-21821",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21821"
},
{
"name": "CVE-2025-68206",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68206"
},
{
"name": "CVE-2020-11935",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-11935"
},
{
"name": "CVE-2023-54247",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54247"
},
{
"name": "CVE-2025-68309",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68309"
},
{
"name": "CVE-2023-52905",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52905"
},
{
"name": "CVE-2024-57852",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57852"
},
{
"name": "CVE-2025-40003",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40003"
},
{
"name": "CVE-2025-22042",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22042"
},
{
"name": "CVE-2025-71158",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71158"
},
{
"name": "CVE-2022-49803",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49803"
},
{
"name": "CVE-2024-57898",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57898"
},
{
"name": "CVE-2020-35503",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-35503"
},
{
"name": "CVE-2024-49923",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49923"
},
{
"name": "CVE-2024-56639",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56639"
},
{
"name": "CVE-2025-68372",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68372"
},
{
"name": "CVE-2026-23171",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23171"
},
{
"name": "CVE-2024-3651",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-3651"
},
{
"name": "CVE-2023-53002",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53002"
},
{
"name": "CVE-2021-0183",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-0183"
},
{
"name": "CVE-2025-39884",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39884"
},
{
"name": "CVE-2025-39747",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39747"
},
{
"name": "CVE-2024-36914",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36914"
},
{
"name": "CVE-2026-26996",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-26996"
},
{
"name": "CVE-2024-35826",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35826"
},
{
"name": "CVE-2026-23112",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23112"
},
{
"name": "CVE-2022-49764",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49764"
},
{
"name": "CVE-2025-68121",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68121"
},
{
"name": "CVE-2025-21651",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21651"
},
{
"name": "CVE-2025-38092",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38092"
},
{
"name": "CVE-2025-22124",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22124"
},
{
"name": "CVE-2025-68313",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68313"
},
{
"name": "CVE-2024-58053",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58053"
},
{
"name": "CVE-2023-26553",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-26553"
},
{
"name": "CVE-2025-60876",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-60876"
},
{
"name": "CVE-2025-37776",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37776"
},
{
"name": "CVE-2021-23840",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-23840"
},
{
"name": "CVE-2024-58077",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58077"
},
{
"name": "CVE-2024-6519",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-6519"
},
{
"name": "CVE-2024-46729",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46729"
},
{
"name": "CVE-2023-53850",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53850"
},
{
"name": "CVE-2023-2975",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-2975"
},
{
"name": "CVE-2022-50266",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50266"
},
{
"name": "CVE-2024-53178",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53178"
},
{
"name": "CVE-2025-71137",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71137"
},
{
"name": "CVE-2026-23084",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23084"
},
{
"name": "CVE-2023-53093",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53093"
},
{
"name": "CVE-2025-11065",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-11065"
},
{
"name": "CVE-2026-23190",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23190"
},
{
"name": "CVE-2025-40123",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40123"
},
{
"name": "CVE-2026-22979",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22979"
},
{
"name": "CVE-2025-68301",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68301"
},
{
"name": "CVE-2024-49991",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49991"
},
{
"name": "CVE-2022-50009",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50009"
},
{
"name": "CVE-2022-26047",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-26047"
},
{
"name": "CVE-2024-53240",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53240"
},
{
"name": "CVE-2026-23011",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23011"
},
{
"name": "CVE-2024-36949",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36949"
},
{
"name": "CVE-2023-53816",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53816"
},
{
"name": "CVE-2025-37877",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37877"
},
{
"name": "CVE-2024-2193",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-2193"
},
{
"name": "CVE-2025-4382",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-4382"
},
{
"name": "CVE-2022-28693",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-28693"
},
{
"name": "CVE-2025-71161",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71161"
},
{
"name": "CVE-2025-39706",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39706"
},
{
"name": "CVE-2025-22038",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22038"
},
{
"name": "CVE-2025-68217",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68217"
},
{
"name": "CVE-2023-54242",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54242"
},
{
"name": "CVE-2025-68289",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68289"
},
{
"name": "CVE-2025-40363",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40363"
},
{
"name": "CVE-2024-41062",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41062"
},
{
"name": "CVE-2025-40253",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40253"
},
{
"name": "CVE-2022-48816",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48816"
},
{
"name": "CVE-2025-37800",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37800"
},
{
"name": "CVE-2025-61726",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-61726"
},
{
"name": "CVE-2022-50518",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50518"
},
{
"name": "CVE-2022-49829",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49829"
},
{
"name": "CVE-2025-64756",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-64756"
},
{
"name": "CVE-2025-21967",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21967"
},
{
"name": "CVE-2016-2568",
"url": "https://www.cve.org/CVERecord?id=CVE-2016-2568"
},
{
"name": "CVE-2020-13817",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-13817"
},
{
"name": "CVE-2025-68245",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68245"
},
{
"name": "CVE-2018-12929",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-12929"
},
{
"name": "CVE-2024-26853",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26853"
},
{
"name": "CVE-2024-53147",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53147"
},
{
"name": "CVE-2025-39952",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39952"
},
{
"name": "CVE-2025-40317",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40317"
},
{
"name": "CVE-2024-45783",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45783"
},
{
"name": "CVE-2026-23110",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23110"
},
{
"name": "CVE-2023-53410",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53410"
},
{
"name": "CVE-2023-53254",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53254"
},
{
"name": "CVE-2024-34064",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-34064"
},
{
"name": "CVE-2023-47210",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-47210"
},
{
"name": "CVE-2025-68809",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68809"
},
{
"name": "CVE-2024-36920",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36920"
},
{
"name": "CVE-2021-0165",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-0165"
},
{
"name": "CVE-2025-0624",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-0624"
},
{
"name": "CVE-2022-49177",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49177"
},
{
"name": "CVE-2025-38205",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38205"
},
{
"name": "CVE-2026-23100",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23100"
},
{
"name": "CVE-2025-59464",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-59464"
},
{
"name": "CVE-2024-58241",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58241"
},
{
"name": "CVE-2025-21863",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21863"
},
{
"name": "CVE-2025-71120",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71120"
},
{
"name": "CVE-2025-38166",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38166"
},
{
"name": "CVE-2022-49833",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49833"
},
{
"name": "CVE-2026-23060",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23060"
},
{
"name": "CVE-2025-38321",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38321"
},
{
"name": "CVE-2025-68282",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68282"
},
{
"name": "CVE-2025-39705",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39705"
},
{
"name": "CVE-2025-68817",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68817"
},
{
"name": "CVE-2024-36021",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36021"
},
{
"name": "CVE-2025-38045",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38045"
},
{
"name": "CVE-2024-46726",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46726"
},
{
"name": "CVE-2025-40025",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40025"
},
{
"name": "CVE-2024-53079",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53079"
},
{
"name": "CVE-2025-68787",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68787"
},
{
"name": "CVE-2025-1125",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-1125"
},
{
"name": "CVE-2023-53647",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53647"
},
{
"name": "CVE-2025-37954",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37954"
},
{
"name": "CVE-2025-23133",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23133"
},
{
"name": "CVE-2025-0012",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-0012"
},
{
"name": "CVE-2020-12313",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-12313"
},
{
"name": "CVE-2025-71233",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71233"
},
{
"name": "CVE-2025-68782",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68782"
},
{
"name": "CVE-2021-0166",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-0166"
},
{
"name": "CVE-2025-21945",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21945"
},
{
"name": "CVE-2022-3872",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-3872"
},
{
"name": "CVE-2025-39744",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39744"
},
{
"name": "CVE-2025-71197",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71197"
},
{
"name": "CVE-2025-68177",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68177"
},
{
"name": "CVE-2025-68758",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68758"
},
{
"name": "CVE-2024-49931",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49931"
},
{
"name": "CVE-2024-43866",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43866"
},
{
"name": "CVE-2024-37021",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-37021"
},
{
"name": "CVE-2024-47728",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47728"
},
{
"name": "CVE-2025-68191",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68191"
},
{
"name": "CVE-2026-23031",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23031"
},
{
"name": "CVE-2024-46730",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46730"
},
{
"name": "CVE-2025-71113",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71113"
},
{
"name": "CVE-2025-71127",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71127"
},
{
"name": "CVE-2025-37786",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37786"
},
{
"name": "CVE-2024-46728",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46728"
},
{
"name": "CVE-2023-53561",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53561"
},
{
"name": "CVE-2026-22998",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22998"
},
{
"name": "CVE-2023-54172",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54172"
},
{
"name": "CVE-2026-23050",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23050"
},
{
"name": "CVE-2024-58100",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58100"
},
{
"name": "CVE-2020-0256",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-0256"
},
{
"name": "CVE-2025-21673",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21673"
},
{
"name": "CVE-2024-26954",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26954"
},
{
"name": "CVE-2025-21634",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21634"
},
{
"name": "CVE-2024-57999",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57999"
},
{
"name": "CVE-2025-38047",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38047"
},
{
"name": "CVE-2024-47738",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47738"
},
{
"name": "CVE-2025-68340",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68340"
},
{
"name": "CVE-2024-41013",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41013"
},
{
"name": "CVE-2023-54320",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54320"
},
{
"name": "CVE-2024-43911",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43911"
},
{
"name": "CVE-2025-37959",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37959"
},
{
"name": "CVE-2017-0537",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-0537"
},
{
"name": "CVE-2025-38191",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38191"
},
{
"name": "CVE-2023-32681",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-32681"
},
{
"name": "CVE-2025-68219",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68219"
},
{
"name": "CVE-2022-50232",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50232"
},
{
"name": "CVE-2025-38062",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38062"
},
{
"name": "CVE-2025-38531",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38531"
},
{
"name": "CVE-2023-26112",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-26112"
},
{
"name": "CVE-2018-6952",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-6952"
},
{
"name": "CVE-2020-14304",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-14304"
},
{
"name": "CVE-2024-46834",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46834"
},
{
"name": "CVE-2025-40288",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40288"
},
{
"name": "CVE-2025-68239",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68239"
},
{
"name": "CVE-2025-40258",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40258"
},
{
"name": "CVE-2025-21894",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21894"
},
{
"name": "CVE-2025-40281",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40281"
},
{
"name": "CVE-2025-68185",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68185"
},
{
"name": "CVE-2025-40304",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40304"
},
{
"name": "CVE-2025-38503",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38503"
},
{
"name": "CVE-2025-40110",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40110"
},
{
"name": "CVE-2026-24001",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-24001"
},
{
"name": "CVE-2025-37807",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37807"
},
{
"name": "CVE-2025-38131",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38131"
},
{
"name": "CVE-2022-50016",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50016"
},
{
"name": "CVE-2025-29481",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-29481"
},
{
"name": "CVE-2024-53219",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53219"
},
{
"name": "CVE-2023-53009",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53009"
},
{
"name": "CVE-2025-40268",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40268"
},
{
"name": "CVE-2025-61661",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-61661"
},
{
"name": "CVE-2026-23111",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23111"
},
{
"name": "CVE-2024-25740",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-25740"
},
{
"name": "CVE-2024-50246",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50246"
},
{
"name": "CVE-2023-3446",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-3446"
},
{
"name": "CVE-2024-57950",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57950"
},
{
"name": "CVE-2025-21759",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21759"
},
{
"name": "CVE-2025-40325",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40325"
},
{
"name": "CVE-2024-2511",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-2511"
},
{
"name": "CVE-2024-42321",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42321"
},
{
"name": "CVE-2026-23113",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23113"
},
{
"name": "CVE-2021-0176",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-0176"
},
{
"name": "CVE-2025-1151",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-1151"
},
{
"name": "CVE-2022-48998",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48998"
},
{
"name": "CVE-2025-68798",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68798"
},
{
"name": "CVE-2024-42273",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42273"
},
{
"name": "CVE-2025-68336",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68336"
},
{
"name": "CVE-2023-53794",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53794"
},
{
"name": "CVE-2026-23157",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23157"
},
{
"name": "CVE-2025-40303",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40303"
},
{
"name": "CVE-2025-68178",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68178"
},
{
"name": "CVE-2022-49974",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49974"
},
{
"name": "CVE-2025-40337",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40337"
},
{
"name": "CVE-2019-20633",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-20633"
},
{
"name": "CVE-2025-38264",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38264"
},
{
"name": "CVE-2021-3714",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-3714"
},
{
"name": "CVE-2023-54071",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54071"
},
{
"name": "CVE-2024-56566",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56566"
},
{
"name": "CVE-2025-40036",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40036"
},
{
"name": "CVE-2024-57993",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57993"
},
{
"name": "CVE-2024-47745",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47745"
},
{
"name": "CVE-2025-39833",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39833"
},
{
"name": "CVE-2026-23097",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23097"
},
{
"name": "CVE-2025-37980",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37980"
},
{
"name": "CVE-2024-53190",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53190"
},
{
"name": "CVE-2025-40262",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40262"
},
{
"name": "CVE-2024-35784",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35784"
},
{
"name": "CVE-2024-56591",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56591"
},
{
"name": "CVE-2024-56544",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56544"
},
{
"name": "CVE-2024-56647",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56647"
},
{
"name": "CVE-2025-71198",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71198"
},
{
"name": "CVE-2025-21649",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21649"
},
{
"name": "CVE-2024-57976",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57976"
},
{
"name": "CVE-2025-68819",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68819"
},
{
"name": "CVE-2025-0685",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-0685"
},
{
"name": "CVE-2024-57893",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57893"
},
{
"name": "CVE-2026-23231",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23231"
},
{
"name": "CVE-2025-37879",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37879"
},
{
"name": "CVE-2022-50071",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50071"
},
{
"name": "CVE-2025-40261",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40261"
},
{
"name": "CVE-2024-56180",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56180"
},
{
"name": "CVE-2023-39333",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-39333"
},
{
"name": "CVE-2025-38643",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38643"
},
{
"name": "CVE-2021-3864",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-3864"
},
{
"name": "CVE-2025-39771",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39771"
},
{
"name": "CVE-2023-52591",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52591"
},
{
"name": "CVE-2024-26648",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26648"
},
{
"name": "CVE-2025-66862",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-66862"
},
{
"name": "CVE-2020-11868",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-11868"
},
{
"name": "CVE-2020-24352",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-24352"
},
{
"name": "CVE-2024-36000",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36000"
},
{
"name": "CVE-2026-23021",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23021"
},
{
"name": "CVE-2025-39819",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39819"
},
{
"name": "CVE-2022-49296",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49296"
},
{
"name": "CVE-2024-49914",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49914"
},
{
"name": "CVE-2025-38360",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38360"
},
{
"name": "CVE-2025-68732",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68732"
},
{
"name": "CVE-2025-39715",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39715"
},
{
"name": "CVE-2025-36407",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-36407"
},
{
"name": "CVE-2024-0217",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-0217"
},
{
"name": "CVE-2025-40323",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40323"
},
{
"name": "CVE-2025-21732",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21732"
},
{
"name": "CVE-2021-47658",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47658"
},
{
"name": "CVE-2025-68285",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68285"
},
{
"name": "CVE-2019-12067",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-12067"
},
{
"name": "CVE-2024-57843",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57843"
},
{
"name": "CVE-2025-38512",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38512"
},
{
"name": "CVE-2024-50135",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50135"
},
{
"name": "CVE-2024-49916",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49916"
},
{
"name": "CVE-2025-68119",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68119"
},
{
"name": "CVE-2024-49988",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49988"
},
{
"name": "CVE-2023-52648",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52648"
},
{
"name": "CVE-2024-49861",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49861"
},
{
"name": "CVE-2026-23093",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23093"
},
{
"name": "CVE-2024-49893",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49893"
},
{
"name": "CVE-2024-44963",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44963"
},
{
"name": "CVE-2023-53348",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53348"
},
{
"name": "CVE-2022-48766",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48766"
},
{
"name": "CVE-2019-15794",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-15794"
},
{
"name": "CVE-2024-49917",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49917"
},
{
"name": "CVE-2022-50467",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50467"
},
{
"name": "CVE-2025-37849",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37849"
},
{
"name": "CVE-2024-48875",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-48875"
},
{
"name": "CVE-2024-41935",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41935"
},
{
"name": "CVE-2025-38162",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38162"
},
{
"name": "CVE-2022-23491",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-23491"
},
{
"name": "CVE-2025-22873",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22873"
},
{
"name": "CVE-2023-5678",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-5678"
},
{
"name": "CVE-2025-71183",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71183"
},
{
"name": "CVE-2023-54047",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54047"
},
{
"name": "CVE-2023-53382",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53382"
},
{
"name": "CVE-2024-50060",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50060"
},
{
"name": "CVE-2025-39677",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39677"
},
{
"name": "CVE-2023-53651",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53651"
},
{
"name": "CVE-2025-21832",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21832"
},
{
"name": "CVE-2025-68371",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68371"
},
{
"name": "CVE-2022-50383",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50383"
},
{
"name": "CVE-2025-39707",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39707"
},
{
"name": "CVE-2025-40275",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40275"
},
{
"name": "CVE-2023-53387",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53387"
},
{
"name": "CVE-2026-31802",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31802"
},
{
"name": "CVE-2024-45774",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45774"
},
{
"name": "CVE-2023-54019",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54019"
},
{
"name": "CVE-2025-22053",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22053"
},
{
"name": "CVE-2025-61664",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-61664"
},
{
"name": "CVE-2025-68211",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68211"
},
{
"name": "CVE-2026-25702",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-25702"
},
{
"name": "CVE-2023-52452",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52452"
},
{
"name": "CVE-2023-42366",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-42366"
},
{
"name": "CVE-2022-50863",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50863"
},
{
"name": "CVE-2025-39829",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39829"
},
{
"name": "CVE-2024-35843",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35843"
},
{
"name": "CVE-2025-71091",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71091"
},
{
"name": "CVE-2025-39781",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39781"
},
{
"name": "CVE-2025-39762",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39762"
},
{
"name": "CVE-2024-40999",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40999"
},
{
"name": "CVE-2023-53292",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53292"
},
{
"name": "CVE-2023-52576",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52576"
},
{
"name": "CVE-2024-27002",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27002"
},
{
"name": "CVE-2025-0167",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-0167"
},
{
"name": "CVE-2024-57887",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57887"
},
{
"name": "CVE-2025-21730",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21730"
},
{
"name": "CVE-2024-35865",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35865"
},
{
"name": "CVE-2025-71184",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71184"
},
{
"name": "CVE-2023-52660",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52660"
},
{
"name": "CVE-2024-35995",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35995"
},
{
"name": "CVE-2025-69420",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-69420"
},
{
"name": "CVE-2023-53371",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53371"
},
{
"name": "CVE-2025-38659",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38659"
},
{
"name": "CVE-2025-68227",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68227"
},
{
"name": "CVE-2025-22041",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22041"
},
{
"name": "CVE-2025-40339",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40339"
},
{
"name": "CVE-2025-22127",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22127"
},
{
"name": "CVE-2025-47273",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-47273"
},
{
"name": "CVE-2024-27025",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27025"
},
{
"name": "CVE-2025-38020",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38020"
},
{
"name": "CVE-2024-27011",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27011"
},
{
"name": "CVE-2025-15224",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-15224"
},
{
"name": "CVE-2024-26605",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26605"
},
{
"name": "CVE-2026-27904",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-27904"
},
{
"name": "CVE-2024-38543",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38543"
},
{
"name": "CVE-2025-68263",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68263"
},
{
"name": "CVE-2023-53187",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53187"
},
{
"name": "CVE-2025-38689",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38689"
},
{
"name": "CVE-2025-68800",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68800"
},
{
"name": "CVE-2025-38275",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38275"
},
{
"name": "CVE-2025-68261",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68261"
},
{
"name": "CVE-2022-48744",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48744"
},
{
"name": "CVE-2025-38070",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38070"
},
{
"name": "CVE-2025-68755",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68755"
},
{
"name": "CVE-2025-62525",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-62525"
},
{
"name": "CVE-2025-71238",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71238"
},
{
"name": "CVE-2021-0175",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-0175"
},
{
"name": "CVE-2024-36012",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36012"
},
{
"name": "CVE-2022-48706",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48706"
},
{
"name": "CVE-2025-40334",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40334"
},
{
"name": "CVE-2025-68767",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68767"
},
{
"name": "CVE-2024-46716",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46716"
},
{
"name": "CVE-2012-4542",
"url": "https://www.cve.org/CVERecord?id=CVE-2012-4542"
},
{
"name": "CVE-2021-3773",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-3773"
},
{
"name": "CVE-2025-61729",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-61729"
},
{
"name": "CVE-2022-49267",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49267"
},
{
"name": "CVE-2024-56592",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56592"
},
{
"name": "CVE-2025-37854",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37854"
},
{
"name": "CVE-2025-38189",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38189"
},
{
"name": "CVE-2022-48628",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48628"
},
{
"name": "CVE-2024-6345",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-6345"
},
{
"name": "CVE-2024-50138",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50138"
},
{
"name": "CVE-2025-40319",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40319"
},
{
"name": "CVE-2021-44534",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-44534"
},
{
"name": "CVE-2025-14831",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-14831"
},
{
"name": "CVE-2024-56565",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56565"
},
{
"name": "CVE-2025-68193",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68193"
},
{
"name": "CVE-2025-68727",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68727"
},
{
"name": "CVE-2024-57872",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57872"
},
{
"name": "CVE-2023-28720",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-28720"
},
{
"name": "CVE-2024-53093",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53093"
},
{
"name": "CVE-2026-23080",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23080"
},
{
"name": "CVE-2024-46833",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46833"
},
{
"name": "CVE-2024-47703",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47703"
},
{
"name": "CVE-2023-53742",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53742"
},
{
"name": "CVE-2025-38361",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38361"
},
{
"name": "CVE-2025-38041",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38041"
},
{
"name": "CVE-2024-53177",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53177"
},
{
"name": "CVE-2024-56588",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56588"
},
{
"name": "CVE-2023-53452",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53452"
},
{
"name": "CVE-2023-54121",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54121"
},
{
"name": "CVE-2023-6610",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-6610"
},
{
"name": "CVE-2023-54261",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54261"
},
{
"name": "CVE-2022-50616",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50616"
},
{
"name": "CVE-2025-66418",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-66418"
},
{
"name": "CVE-2023-53544",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53544"
},
{
"name": "CVE-2025-68264",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68264"
},
{
"name": "CVE-2024-49911",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49911"
},
{
"name": "CVE-2026-23154",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23154"
},
{
"name": "CVE-2022-50708",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50708"
},
{
"name": "CVE-2026-3784",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-3784"
},
{
"name": "CVE-2025-68764",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68764"
},
{
"name": "CVE-2025-9301",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-9301"
}
],
"initial_release_date": "2026-03-19T00:00:00",
"last_revision_date": "2026-03-19T00:00:00",
"links": [],
"reference": "CERTFR-2026-AVI-0316",
"revisions": [
{
"description": "Version initiale",
"revision_date": "2026-03-19T00: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": "2026-03-18",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 37219",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/37219"
},
{
"published_at": "2026-03-18",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 37211",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/37211"
},
{
"published_at": "2026-03-18",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 37215",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/37215"
},
{
"published_at": "2026-03-18",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 37218",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/37218"
},
{
"published_at": "2026-03-18",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 37220",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/37220"
},
{
"published_at": "2026-03-18",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 37216",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/37216"
},
{
"published_at": "2026-03-18",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 37221",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/37221"
},
{
"published_at": "2026-03-18",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 37213",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/37213"
},
{
"published_at": "2026-03-18",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 37217",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/37217"
},
{
"published_at": "2026-03-18",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 37212",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/37212"
},
{
"published_at": "2026-03-18",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 37214",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/37214"
},
{
"published_at": "2026-03-18",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 37222",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/37222"
}
]
}
CERTFR-2026-AVI-0326
Vulnerability from certfr_avis - Published: 2026-03-20 - Updated: 2026-03-20
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 Platform | Isolation Segmentation pour VMware Tanzu Platform versions antérieures à 6.0.26+LTS-T | ||
| VMware | Tanzu Platform | Isolation Segmentation pour VMware Tanzu Platform versions antérieures à 10.3.6 | ||
| VMware | Tanzu Platform | App Autoscaler CLI Plugin pour VMware Tanzu Platform versions antérieures à 250.6.9 | ||
| VMware | N/A | Python Buildpack versions antérieures à 1.8.83 | ||
| VMware | Tanzu Platform | Tanzu Platform versions antérieures à 3.1.9 | ||
| VMware | Tanzu Platform | Tanzu RabbitMQ sur Tanzu Platform versions antérieures à 2.4.4 | ||
| VMware | N/A | PHP Buildpack versions antérieures à 4.6.69 | ||
| VMware | Tanzu Platform | Tanzu Platform versions antérieures à 3.2.5 | ||
| VMware | Tanzu Platform | Elastic Application Runtime Windows add-on pour VMware Tanzu Platform versions antérieures à 10.2.9+LTS-T | ||
| VMware | Tanzu Platform | App Autoscaler CLI Plugin pour VMware Tanzu Platform versions antérieures à 250.5.17 | ||
| VMware | Tanzu Platform | Tanzu RabbitMQ pour Tanzu Platform versions antérieures à 10.1.2 | ||
| VMware | Tanzu Platform | Tanzu Platform versions antérieures à 2.4.6 | ||
| VMware | Tanzu Platform | Tanzu Platform versions antérieures à 1.16.18 | ||
| VMware | Tanzu Platform | Tanzu for Valkey sur Tanzu Platform versions antérieures à 10.2.2 | ||
| VMware | Tanzu Platform | Elastic Application Runtime Windows add-on pour VMware Tanzu Platform versions antérieures à 6.0.26+LTS-T | ||
| VMware | Tanzu Platform | Isolation Segmentation pour VMware Tanzu Platform versions antérieures à 10.2.9+LTS-T | ||
| VMware | Tanzu Platform | Elastic Application Runtime Windows add-on pour VMware Tanzu Platform versions antérieures à 10.3.6 |
{
"$ref": "https://www.cert.ssi.gouv.fr/openapi.json",
"affected_systems": [
{
"description": "Isolation Segmentation pour VMware Tanzu Platform versions ant\u00e9rieures \u00e0 6.0.26+LTS-T",
"product": {
"name": "Tanzu Platform",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Isolation Segmentation pour VMware Tanzu Platform versions ant\u00e9rieures \u00e0 10.3.6",
"product": {
"name": "Tanzu Platform",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "App Autoscaler CLI Plugin pour VMware Tanzu Platform versions ant\u00e9rieures \u00e0 250.6.9",
"product": {
"name": "Tanzu Platform",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Python Buildpack versions ant\u00e9rieures \u00e0 1.8.83",
"product": {
"name": "N/A",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Tanzu Platform versions ant\u00e9rieures \u00e0 3.1.9",
"product": {
"name": "Tanzu Platform",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Tanzu RabbitMQ sur Tanzu Platform versions ant\u00e9rieures \u00e0 2.4.4",
"product": {
"name": "Tanzu Platform",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "PHP Buildpack versions ant\u00e9rieures \u00e0 4.6.69",
"product": {
"name": "N/A",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Tanzu Platform versions ant\u00e9rieures \u00e0 3.2.5",
"product": {
"name": "Tanzu Platform",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Elastic Application Runtime Windows add-on pour VMware Tanzu Platform versions ant\u00e9rieures \u00e0 10.2.9+LTS-T",
"product": {
"name": "Tanzu Platform",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "App Autoscaler CLI Plugin pour VMware Tanzu Platform versions ant\u00e9rieures \u00e0 250.5.17",
"product": {
"name": "Tanzu Platform",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Tanzu RabbitMQ pour Tanzu Platform versions ant\u00e9rieures \u00e0 10.1.2",
"product": {
"name": "Tanzu Platform",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Tanzu Platform versions ant\u00e9rieures \u00e0 2.4.6",
"product": {
"name": "Tanzu Platform",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Tanzu Platform versions ant\u00e9rieures \u00e0 1.16.18",
"product": {
"name": "Tanzu Platform",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Tanzu for Valkey sur Tanzu Platform versions ant\u00e9rieures \u00e0 10.2.2",
"product": {
"name": "Tanzu Platform",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Elastic Application Runtime Windows add-on pour VMware Tanzu Platform versions ant\u00e9rieures \u00e0 6.0.26+LTS-T",
"product": {
"name": "Tanzu Platform",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Isolation Segmentation pour VMware Tanzu Platform versions ant\u00e9rieures \u00e0 10.2.9+LTS-T",
"product": {
"name": "Tanzu Platform",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Elastic Application Runtime Windows add-on pour VMware Tanzu Platform versions ant\u00e9rieures \u00e0 10.3.6",
"product": {
"name": "Tanzu Platform",
"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-2026-28422",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-28422"
},
{
"name": "CVE-2024-36903",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36903"
},
{
"name": "CVE-2024-35875",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35875"
},
{
"name": "CVE-2022-50759",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50759"
},
{
"name": "CVE-2026-26007",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-26007"
},
{
"name": "CVE-2025-71075",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71075"
},
{
"name": "CVE-2024-49912",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49912"
},
{
"name": "CVE-2024-36026",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36026"
},
{
"name": "CVE-2026-23198",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23198"
},
{
"name": "CVE-2023-3640",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-3640"
},
{
"name": "CVE-2024-27435",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27435"
},
{
"name": "CVE-2025-40273",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40273"
},
{
"name": "CVE-2023-53714",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53714"
},
{
"name": "CVE-2024-42122",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42122"
},
{
"name": "CVE-2025-68230",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68230"
},
{
"name": "CVE-2026-28420",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-28420"
},
{
"name": "CVE-2022-49069",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49069"
},
{
"name": "CVE-2024-57875",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57875"
},
{
"name": "CVE-2022-27943",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-27943"
},
{
"name": "CVE-2025-40064",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40064"
},
{
"name": "CVE-2023-54129",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54129"
},
{
"name": "CVE-2025-66865",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-66865"
},
{
"name": "CVE-2024-41031",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41031"
},
{
"name": "CVE-2025-39992",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39992"
},
{
"name": "CVE-2025-69534",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-69534"
},
{
"name": "CVE-2025-61730",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-61730"
},
{
"name": "CVE-2022-49543",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49543"
},
{
"name": "CVE-2026-23202",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23202"
},
{
"name": "CVE-2025-38485",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38485"
},
{
"name": "CVE-2023-53562",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53562"
},
{
"name": "CVE-2025-68324",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68324"
},
{
"name": "CVE-2025-22026",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22026"
},
{
"name": "CVE-2023-54149",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54149"
},
{
"name": "CVE-2025-71086",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71086"
},
{
"name": "CVE-2024-50063",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50063"
},
{
"name": "CVE-2023-33875",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-33875"
},
{
"name": "CVE-2024-41001",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41001"
},
{
"name": "CVE-2024-42155",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42155"
},
{
"name": "CVE-2026-23167",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23167"
},
{
"name": "CVE-2025-36353",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-36353"
},
{
"name": "CVE-2025-68196",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68196"
},
{
"name": "CVE-2024-46770",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46770"
},
{
"name": "CVE-2023-53247",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53247"
},
{
"name": "CVE-2025-38042",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38042"
},
{
"name": "CVE-2025-22083",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22083"
},
{
"name": "CVE-2023-53829",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53829"
},
{
"name": "CVE-2025-58183",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-58183"
},
{
"name": "CVE-2025-59830",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-59830"
},
{
"name": "CVE-2023-54002",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54002"
},
{
"name": "CVE-2022-50550",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50550"
},
{
"name": "CVE-2022-0400",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-0400"
},
{
"name": "CVE-2022-49138",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49138"
},
{
"name": "CVE-2025-66199",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-66199"
},
{
"name": "CVE-2024-42239",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42239"
},
{
"name": "CVE-2022-49359",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49359"
},
{
"name": "CVE-2025-68342",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68342"
},
{
"name": "CVE-2022-48673",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48673"
},
{
"name": "CVE-2022-50425",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50425"
},
{
"name": "CVE-2025-38201",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38201"
},
{
"name": "CVE-2024-39293",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39293"
},
{
"name": "CVE-2023-53008",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53008"
},
{
"name": "CVE-2025-38669",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38669"
},
{
"name": "CVE-2025-40137",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40137"
},
{
"name": "CVE-2023-54052",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54052"
},
{
"name": "CVE-2025-22107",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22107"
},
{
"name": "CVE-2024-38306",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38306"
},
{
"name": "CVE-2023-53733",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53733"
},
{
"name": "CVE-2025-37775",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37775"
},
{
"name": "CVE-2025-21682",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21682"
},
{
"name": "CVE-2023-1386",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-1386"
},
{
"name": "CVE-2024-35939",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35939"
},
{
"name": "CVE-2024-39298",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39298"
},
{
"name": "CVE-2024-56703",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56703"
},
{
"name": "CVE-2026-23098",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23098"
},
{
"name": "CVE-2023-53347",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53347"
},
{
"name": "CVE-2023-28374",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-28374"
},
{
"name": "CVE-2023-52926",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52926"
},
{
"name": "CVE-2026-32597",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-32597"
},
{
"name": "CVE-2025-68286",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68286"
},
{
"name": "CVE-2025-9231",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-9231"
},
{
"name": "CVE-2024-36921",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36921"
},
{
"name": "CVE-2025-40057",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40057"
},
{
"name": "CVE-2024-41050",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41050"
},
{
"name": "CVE-2026-25500",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-25500"
},
{
"name": "CVE-2024-26656",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26656"
},
{
"name": "CVE-2025-38520",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38520"
},
{
"name": "CVE-2025-27558",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-27558"
},
{
"name": "CVE-2025-71094",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71094"
},
{
"name": "CVE-2026-21637",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-21637"
},
{
"name": "CVE-2024-35998",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35998"
},
{
"name": "CVE-2024-37891",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-37891"
},
{
"name": "CVE-2021-0076",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-0076"
},
{
"name": "CVE-2025-68788",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68788"
},
{
"name": "CVE-2024-58237",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58237"
},
{
"name": "CVE-2024-36909",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36909"
},
{
"name": "CVE-2024-42147",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42147"
},
{
"name": "CVE-2023-53529",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53529"
},
{
"name": "CVE-2024-50028",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50028"
},
{
"name": "CVE-2023-53042",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53042"
},
{
"name": "CVE-2022-50527",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50527"
},
{
"name": "CVE-2023-54280",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54280"
},
{
"name": "CVE-2025-21786",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21786"
},
{
"name": "CVE-2024-58094",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58094"
},
{
"name": "CVE-2024-11187",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-11187"
},
{
"name": "CVE-2025-52534",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-52534"
},
{
"name": "CVE-2025-40314",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40314"
},
{
"name": "CVE-2024-46705",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46705"
},
{
"name": "CVE-2022-50407",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50407"
},
{
"name": "CVE-2026-23196",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23196"
},
{
"name": "CVE-2024-26595",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26595"
},
{
"name": "CVE-2022-23825",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-23825"
},
{
"name": "CVE-2024-45775",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45775"
},
{
"name": "CVE-2025-40306",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40306"
},
{
"name": "CVE-2025-21881",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21881"
},
{
"name": "CVE-2022-49901",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49901"
},
{
"name": "CVE-2026-23126",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23126"
},
{
"name": "CVE-2025-38329",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38329"
},
{
"name": "CVE-2021-33096",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-33096"
},
{
"name": "CVE-2022-50230",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50230"
},
{
"name": "CVE-2024-35949",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35949"
},
{
"name": "CVE-2025-39947",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39947"
},
{
"name": "CVE-2025-68778",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68778"
},
{
"name": "CVE-2023-53588",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53588"
},
{
"name": "CVE-2024-41082",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41082"
},
{
"name": "CVE-2023-53685",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53685"
},
{
"name": "CVE-2025-5222",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-5222"
},
{
"name": "CVE-2025-23155",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23155"
},
{
"name": "CVE-2026-23054",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23054"
},
{
"name": "CVE-2025-37870",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37870"
},
{
"name": "CVE-2025-40254",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40254"
},
{
"name": "CVE-2022-49533",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49533"
},
{
"name": "CVE-2024-42253",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42253"
},
{
"name": "CVE-2020-26557",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-26557"
},
{
"name": "CVE-2025-71064",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71064"
},
{
"name": "CVE-2023-54201",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54201"
},
{
"name": "CVE-2021-33114",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-33114"
},
{
"name": "CVE-2025-69645",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-69645"
},
{
"name": "CVE-2025-68200",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68200"
},
{
"name": "CVE-2022-49518",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49518"
},
{
"name": "CVE-2024-56727",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56727"
},
{
"name": "CVE-2022-49125",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49125"
},
{
"name": "CVE-2024-36900",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36900"
},
{
"name": "CVE-2025-38501",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38501"
},
{
"name": "CVE-2024-26866",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26866"
},
{
"name": "CVE-2024-27010",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27010"
},
{
"name": "CVE-2025-27516",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-27516"
},
{
"name": "CVE-2025-68736",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68736"
},
{
"name": "CVE-2023-52561",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52561"
},
{
"name": "CVE-2025-68725",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68725"
},
{
"name": "CVE-2024-3220",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-3220"
},
{
"name": "CVE-2024-53221",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53221"
},
{
"name": "CVE-2024-41069",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41069"
},
{
"name": "CVE-2025-68176",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68176"
},
{
"name": "CVE-2025-37777",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37777"
},
{
"name": "CVE-2021-47432",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47432"
},
{
"name": "CVE-2026-24734",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-24734"
},
{
"name": "CVE-2025-68204",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68204"
},
{
"name": "CVE-2024-35878",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35878"
},
{
"name": "CVE-2023-53362",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53362"
},
{
"name": "CVE-2025-68795",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68795"
},
{
"name": "CVE-2025-68349",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68349"
},
{
"name": "CVE-2024-26756",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26756"
},
{
"name": "CVE-2022-50815",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50815"
},
{
"name": "CVE-2025-21931",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21931"
},
{
"name": "CVE-2025-39826",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39826"
},
{
"name": "CVE-2025-38036",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38036"
},
{
"name": "CVE-2025-2668",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-2668"
},
{
"name": "CVE-2025-71221",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71221"
},
{
"name": "CVE-2025-37778",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37778"
},
{
"name": "CVE-2025-39716",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39716"
},
{
"name": "CVE-2024-46860",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46860"
},
{
"name": "CVE-2025-22040",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22040"
},
{
"name": "CVE-2024-53095",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53095"
},
{
"name": "CVE-2025-22872",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22872"
},
{
"name": "CVE-2025-8277",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-8277"
},
{
"name": "CVE-2025-8941",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-8941"
},
{
"name": "CVE-2022-38457",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-38457"
},
{
"name": "CVE-2024-56665",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56665"
},
{
"name": "CVE-2025-38340",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38340"
},
{
"name": "CVE-2025-38109",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38109"
},
{
"name": "CVE-2023-53629",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53629"
},
{
"name": "CVE-2022-50178",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50178"
},
{
"name": "CVE-2025-39779",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39779"
},
{
"name": "CVE-2025-66866",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-66866"
},
{
"name": "CVE-2025-68283",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68283"
},
{
"name": "CVE-2023-7216",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-7216"
},
{
"name": "CVE-2025-66614",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-66614"
},
{
"name": "CVE-2025-37880",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37880"
},
{
"name": "CVE-2025-36427",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-36427"
},
{
"name": "CVE-2026-23217",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23217"
},
{
"name": "CVE-2025-15469",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-15469"
},
{
"name": "CVE-2025-37833",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37833"
},
{
"name": "CVE-2025-39761",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39761"
},
{
"name": "CVE-2024-38608",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38608"
},
{
"name": "CVE-2025-68246",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68246"
},
{
"name": "CVE-2025-68339",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68339"
},
{
"name": "CVE-2025-40287",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40287"
},
{
"name": "CVE-2023-53320",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53320"
},
{
"name": "CVE-2024-44961",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44961"
},
{
"name": "CVE-2026-23069",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23069"
},
{
"name": "CVE-2025-21656",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21656"
},
{
"name": "CVE-2024-46835",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46835"
},
{
"name": "CVE-2025-69650",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-69650"
},
{
"name": "CVE-2022-50554",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50554"
},
{
"name": "CVE-2023-53509",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53509"
},
{
"name": "CVE-2023-53421",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53421"
},
{
"name": "CVE-2025-11731",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-11731"
},
{
"name": "CVE-2026-22992",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22992"
},
{
"name": "CVE-2024-52005",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-52005"
},
{
"name": "CVE-2024-46775",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46775"
},
{
"name": "CVE-2025-39764",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39764"
},
{
"name": "CVE-2025-38207",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38207"
},
{
"name": "CVE-2022-49465",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49465"
},
{
"name": "CVE-2026-23004",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23004"
},
{
"name": "CVE-2024-26807",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26807"
},
{
"name": "CVE-2025-39720",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39720"
},
{
"name": "CVE-2023-54271",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54271"
},
{
"name": "CVE-2022-49742",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49742"
},
{
"name": "CVE-2025-71191",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71191"
},
{
"name": "CVE-2025-68295",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68295"
},
{
"name": "CVE-2025-68728",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68728"
},
{
"name": "CVE-2025-40780",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40780"
},
{
"name": "CVE-2025-68364",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68364"
},
{
"name": "CVE-2024-42118",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42118"
},
{
"name": "CVE-2025-40100",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40100"
},
{
"name": "CVE-2026-1965",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-1965"
},
{
"name": "CVE-2024-52560",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-52560"
},
{
"name": "CVE-2024-56604",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56604"
},
{
"name": "CVE-2026-23227",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23227"
},
{
"name": "CVE-2025-71087",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71087"
},
{
"name": "CVE-2023-37920",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-37920"
},
{
"name": "CVE-2023-52653",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52653"
},
{
"name": "CVE-2025-40285",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40285"
},
{
"name": "CVE-2023-52508",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52508"
},
{
"name": "CVE-2025-69647",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-69647"
},
{
"name": "CVE-2025-39827",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39827"
},
{
"name": "CVE-2024-50014",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50014"
},
{
"name": "CVE-2022-49108",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49108"
},
{
"name": "CVE-2024-56677",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56677"
},
{
"name": "CVE-2025-38717",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38717"
},
{
"name": "CVE-2026-3497",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-3497"
},
{
"name": "CVE-2025-22019",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22019"
},
{
"name": "CVE-2025-0913",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-0913"
},
{
"name": "CVE-2025-40208",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40208"
},
{
"name": "CVE-2025-39746",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39746"
},
{
"name": "CVE-2024-26767",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26767"
},
{
"name": "CVE-2025-21872",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21872"
},
{
"name": "CVE-2026-2219",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-2219"
},
{
"name": "CVE-2025-68287",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68287"
},
{
"name": "CVE-2025-40039",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40039"
},
{
"name": "CVE-2025-38208",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38208"
},
{
"name": "CVE-2024-35926",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35926"
},
{
"name": "CVE-2024-27389",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27389"
},
{
"name": "CVE-2024-26983",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26983"
},
{
"name": "CVE-2022-50627",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50627"
},
{
"name": "CVE-2024-50285",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50285"
},
{
"name": "CVE-2025-38099",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38099"
},
{
"name": "CVE-2025-38524",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38524"
},
{
"name": "CVE-2025-38029",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38029"
},
{
"name": "CVE-2022-49123",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49123"
},
{
"name": "CVE-2024-50289",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50289"
},
{
"name": "CVE-2023-53258",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53258"
},
{
"name": "CVE-2024-46813",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46813"
},
{
"name": "CVE-2024-38594",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38594"
},
{
"name": "CVE-2025-47907",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-47907"
},
{
"name": "CVE-2024-47658",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47658"
},
{
"name": "CVE-2022-41409",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-41409"
},
{
"name": "CVE-2025-38096",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38096"
},
{
"name": "CVE-2024-48873",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-48873"
},
{
"name": "CVE-2025-68746",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68746"
},
{
"name": "CVE-2024-12797",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-12797"
},
{
"name": "CVE-2023-53429",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53429"
},
{
"name": "CVE-2024-46765",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46765"
},
{
"name": "CVE-2022-50380",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50380"
},
{
"name": "CVE-2025-12084",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-12084"
},
{
"name": "CVE-2025-38039",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38039"
},
{
"name": "CVE-2022-48990",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48990"
},
{
"name": "CVE-2024-24864",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-24864"
},
{
"name": "CVE-2024-35832",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35832"
},
{
"name": "CVE-2024-36479",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36479"
},
{
"name": "CVE-2025-71133",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71133"
},
{
"name": "CVE-2026-23220",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23220"
},
{
"name": "CVE-2024-45782",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45782"
},
{
"name": "CVE-2022-50785",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50785"
},
{
"name": "CVE-2025-39745",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39745"
},
{
"name": "CVE-2024-35799",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35799"
},
{
"name": "CVE-2025-40103",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40103"
},
{
"name": "CVE-2026-23020",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23020"
},
{
"name": "CVE-2025-38595",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38595"
},
{
"name": "CVE-2025-71223",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71223"
},
{
"name": "CVE-2025-36098",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-36098"
},
{
"name": "CVE-2025-68796",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68796"
},
{
"name": "CVE-2025-40016",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40016"
},
{
"name": "CVE-2023-53765",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53765"
},
{
"name": "CVE-2025-38626",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38626"
},
{
"name": "CVE-2025-40356",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40356"
},
{
"name": "CVE-2026-1642",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-1642"
},
{
"name": "CVE-2025-45582",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-45582"
},
{
"name": "CVE-2023-53325",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53325"
},
{
"name": "CVE-2025-21752",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21752"
},
{
"name": "CVE-2026-27138",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-27138"
},
{
"name": "CVE-2025-40312",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40312"
},
{
"name": "CVE-2025-37852",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37852"
},
{
"name": "CVE-2025-68220",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68220"
},
{
"name": "CVE-2025-22125",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22125"
},
{
"name": "CVE-2019-6293",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-6293"
},
{
"name": "CVE-2024-26953",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26953"
},
{
"name": "CVE-2024-39282",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39282"
},
{
"name": "CVE-2025-21738",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21738"
},
{
"name": "CVE-2023-50868",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-50868"
},
{
"name": "CVE-2025-68302",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68302"
},
{
"name": "CVE-2024-50146",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50146"
},
{
"name": "CVE-2025-68238",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68238"
},
{
"name": "CVE-2024-56709",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56709"
},
{
"name": "CVE-2025-38063",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38063"
},
{
"name": "CVE-2025-68297",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68297"
},
{
"name": "CVE-2024-40975",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40975"
},
{
"name": "CVE-2025-68175",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68175"
},
{
"name": "CVE-2025-6069",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-6069"
},
{
"name": "CVE-2023-3817",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-3817"
},
{
"name": "CVE-2023-54227",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54227"
},
{
"name": "CVE-2023-46316",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-46316"
},
{
"name": "CVE-2024-47866",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47866"
},
{
"name": "CVE-2024-44970",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44970"
},
{
"name": "CVE-2022-49476",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49476"
},
{
"name": "CVE-2023-53855",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53855"
},
{
"name": "CVE-2026-23208",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23208"
},
{
"name": "CVE-2025-68804",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68804"
},
{
"name": "CVE-2025-39925",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39925"
},
{
"name": "CVE-2025-68769",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68769"
},
{
"name": "CVE-2024-50286",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50286"
},
{
"name": "CVE-2025-40139",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40139"
},
{
"name": "CVE-2025-68794",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68794"
},
{
"name": "CVE-2025-21768",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21768"
},
{
"name": "CVE-2022-48667",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48667"
},
{
"name": "CVE-2025-69419",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-69419"
},
{
"name": "CVE-2024-56744",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56744"
},
{
"name": "CVE-2025-38491",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38491"
},
{
"name": "CVE-2026-3783",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-3783"
},
{
"name": "CVE-2022-49161",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49161"
},
{
"name": "CVE-2021-21240",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-21240"
},
{
"name": "CVE-2022-48771",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48771"
},
{
"name": "CVE-2025-37961",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37961"
},
{
"name": "CVE-2025-23131",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23131"
},
{
"name": "CVE-2024-27400",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27400"
},
{
"name": "CVE-2023-52485",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52485"
},
{
"name": "CVE-2025-40309",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40309"
},
{
"name": "CVE-2022-49997",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49997"
},
{
"name": "CVE-2022-49469",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49469"
},
{
"name": "CVE-2025-6075",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-6075"
},
{
"name": "CVE-2025-38408",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38408"
},
{
"name": "CVE-2026-23179",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23179"
},
{
"name": "CVE-2025-68334",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68334"
},
{
"name": "CVE-2025-40343",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40343"
},
{
"name": "CVE-2025-38644",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38644"
},
{
"name": "CVE-2025-38692",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38692"
},
{
"name": "CVE-2022-0480",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-0480"
},
{
"name": "CVE-2025-68173",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68173"
},
{
"name": "CVE-2024-49932",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49932"
},
{
"name": "CVE-2026-23090",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23090"
},
{
"name": "CVE-2026-23035",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23035"
},
{
"name": "CVE-2023-53209",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53209"
},
{
"name": "CVE-2023-54253",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54253"
},
{
"name": "CVE-2025-38127",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38127"
},
{
"name": "CVE-2025-22103",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22103"
},
{
"name": "CVE-2025-1272",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-1272"
},
{
"name": "CVE-2025-21658",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21658"
},
{
"name": "CVE-2022-49651",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49651"
},
{
"name": "CVE-2025-68307",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68307"
},
{
"name": "CVE-2025-40308",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40308"
},
{
"name": "CVE-2024-26770",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26770"
},
{
"name": "CVE-2023-54324",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54324"
},
{
"name": "CVE-2024-27041",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27041"
},
{
"name": "CVE-2025-36184",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-36184"
},
{
"name": "CVE-2026-3195",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-3195"
},
{
"name": "CVE-2025-37743",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37743"
},
{
"name": "CVE-2025-40005",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40005"
},
{
"name": "CVE-2025-37920",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37920"
},
{
"name": "CVE-2024-56326",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56326"
},
{
"name": "CVE-2023-26242",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-26242"
},
{
"name": "CVE-2025-58185",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-58185"
},
{
"name": "CVE-2025-40315",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40315"
},
{
"name": "CVE-2023-52673",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52673"
},
{
"name": "CVE-2024-56722",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56722"
},
{
"name": "CVE-2021-33113",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-33113"
},
{
"name": "CVE-2022-48668",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48668"
},
{
"name": "CVE-2024-27418",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27418"
},
{
"name": "CVE-2025-68231",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68231"
},
{
"name": "CVE-2021-22930",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-22930"
},
{
"name": "CVE-2025-14177",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-14177"
},
{
"name": "CVE-2026-23064",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23064"
},
{
"name": "CVE-2025-38591",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38591"
},
{
"name": "CVE-2025-68806",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68806"
},
{
"name": "CVE-2022-50322",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50322"
},
{
"name": "CVE-2023-50782",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-50782"
},
{
"name": "CVE-2022-27635",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-27635"
},
{
"name": "CVE-2025-71098",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71098"
},
{
"name": "CVE-2024-49922",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49922"
},
{
"name": "CVE-2020-12317",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-12317"
},
{
"name": "CVE-2025-61731",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-61731"
},
{
"name": "CVE-2025-40251",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40251"
},
{
"name": "CVE-2024-42128",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42128"
},
{
"name": "CVE-2025-71078",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71078"
},
{
"name": "CVE-2024-49909",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49909"
},
{
"name": "CVE-2025-40355",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40355"
},
{
"name": "CVE-2021-42771",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-42771"
},
{
"name": "CVE-2026-2391",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-2391"
},
{
"name": "CVE-2021-4095",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-4095"
},
{
"name": "CVE-2022-50240",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50240"
},
{
"name": "CVE-2025-40054",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40054"
},
{
"name": "CVE-2024-45015",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45015"
},
{
"name": "CVE-2025-68184",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68184"
},
{
"name": "CVE-2024-36357",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36357"
},
{
"name": "CVE-2025-71074",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71074"
},
{
"name": "CVE-2025-38673",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38673"
},
{
"name": "CVE-2025-40107",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40107"
},
{
"name": "CVE-2025-11234",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-11234"
},
{
"name": "CVE-2025-71083",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71083"
},
{
"name": "CVE-2026-23061",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23061"
},
{
"name": "CVE-2023-53447",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53447"
},
{
"name": "CVE-2024-46754",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46754"
},
{
"name": "CVE-2021-0161",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-0161"
},
{
"name": "CVE-2018-1121",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-1121"
},
{
"name": "CVE-2022-49547",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49547"
},
{
"name": "CVE-2025-66863",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-66863"
},
{
"name": "CVE-2025-0622",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-0622"
},
{
"name": "CVE-2023-0286",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-0286"
},
{
"name": "CVE-2024-26757",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26757"
},
{
"name": "CVE-2024-49899",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49899"
},
{
"name": "CVE-2022-49484",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49484"
},
{
"name": "CVE-2024-40900",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40900"
},
{
"name": "CVE-2024-46748",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46748"
},
{
"name": "CVE-2025-68813",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68813"
},
{
"name": "CVE-2024-50164",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50164"
},
{
"name": "CVE-2026-27137",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-27137"
},
{
"name": "CVE-2023-53248",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53248"
},
{
"name": "CVE-2024-56788",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56788"
},
{
"name": "CVE-2016-8660",
"url": "https://www.cve.org/CVERecord?id=CVE-2016-8660"
},
{
"name": "CVE-2024-26691",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26691"
},
{
"name": "CVE-2026-23047",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23047"
},
{
"name": "CVE-2025-22121",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22121"
},
{
"name": "CVE-2024-1975",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-1975"
},
{
"name": "CVE-2025-38215",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38215"
},
{
"name": "CVE-2025-7519",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-7519"
},
{
"name": "CVE-2023-53491",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53491"
},
{
"name": "CVE-2025-68365",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68365"
},
{
"name": "CVE-2024-57804",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57804"
},
{
"name": "CVE-2024-49908",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49908"
},
{
"name": "CVE-2025-68265",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68265"
},
{
"name": "CVE-2024-50048",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50048"
},
{
"name": "CVE-2026-28421",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-28421"
},
{
"name": "CVE-2026-23119",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23119"
},
{
"name": "CVE-2025-37943",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37943"
},
{
"name": "CVE-2025-21918",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21918"
},
{
"name": "CVE-2025-37745",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37745"
},
{
"name": "CVE-2025-71085",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71085"
},
{
"name": "CVE-2026-27171",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-27171"
},
{
"name": "CVE-2022-50811",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50811"
},
{
"name": "CVE-2025-13837",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-13837"
},
{
"name": "CVE-2023-4133",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-4133"
},
{
"name": "CVE-2024-50183",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50183"
},
{
"name": "CVE-2025-38734",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38734"
},
{
"name": "CVE-2023-53366",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53366"
},
{
"name": "CVE-2022-49910",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49910"
},
{
"name": "CVE-2024-27062",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27062"
},
{
"name": "CVE-2022-49203",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49203"
},
{
"name": "CVE-2024-40918",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40918"
},
{
"name": "CVE-2024-27032",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27032"
},
{
"name": "CVE-2022-50236",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50236"
},
{
"name": "CVE-2024-35932",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35932"
},
{
"name": "CVE-2024-35839",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35839"
},
{
"name": "CVE-2025-68344",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68344"
},
{
"name": "CVE-2026-23137",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23137"
},
{
"name": "CVE-2025-40347",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40347"
},
{
"name": "CVE-2025-71154",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71154"
},
{
"name": "CVE-2025-37882",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37882"
},
{
"name": "CVE-2024-35971",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35971"
},
{
"name": "CVE-2024-46762",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46762"
},
{
"name": "CVE-2023-34983",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-34983"
},
{
"name": "CVE-2024-35868",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35868"
},
{
"name": "CVE-2023-53323",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53323"
},
{
"name": "CVE-2026-3731",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-3731"
},
{
"name": "CVE-2025-40198",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40198"
},
{
"name": "CVE-2024-0760",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-0760"
},
{
"name": "CVE-2025-39942",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39942"
},
{
"name": "CVE-2025-68310",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68310"
},
{
"name": "CVE-2026-23222",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23222"
},
{
"name": "CVE-2025-68229",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68229"
},
{
"name": "CVE-2023-52857",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52857"
},
{
"name": "CVE-2024-42107",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42107"
},
{
"name": "CVE-2025-68257",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68257"
},
{
"name": "CVE-2025-39929",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39929"
},
{
"name": "CVE-2022-50304",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50304"
},
{
"name": "CVE-2026-23226",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23226"
},
{
"name": "CVE-2020-26146",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-26146"
},
{
"name": "CVE-2024-43844",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43844"
},
{
"name": "CVE-2023-52920",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52920"
},
{
"name": "CVE-2023-52590",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52590"
},
{
"name": "CVE-2025-71084",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71084"
},
{
"name": "CVE-2024-22025",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-22025"
},
{
"name": "CVE-2026-23049",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23049"
},
{
"name": "CVE-2025-68321",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68321"
},
{
"name": "CVE-2021-0072",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-0072"
},
{
"name": "CVE-2025-40190",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40190"
},
{
"name": "CVE-2025-69652",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-69652"
},
{
"name": "CVE-2025-21635",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21635"
},
{
"name": "CVE-2025-37924",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37924"
},
{
"name": "CVE-2022-40133",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-40133"
},
{
"name": "CVE-2020-26143",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-26143"
},
{
"name": "CVE-2025-21712",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21712"
},
{
"name": "CVE-2025-38353",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38353"
},
{
"name": "CVE-2025-36009",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-36009"
},
{
"name": "CVE-2019-0154",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-0154"
},
{
"name": "CVE-2024-57982",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57982"
},
{
"name": "CVE-2023-52761",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52761"
},
{
"name": "CVE-2022-49773",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49773"
},
{
"name": "CVE-2023-53609",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53609"
},
{
"name": "CVE-2023-53478",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53478"
},
{
"name": "CVE-2024-42117",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42117"
},
{
"name": "CVE-2025-23160",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23160"
},
{
"name": "CVE-2023-53682",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53682"
},
{
"name": "CVE-2026-23229",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23229"
},
{
"name": "CVE-2025-40311",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40311"
},
{
"name": "CVE-2025-54770",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-54770"
},
{
"name": "CVE-2026-3442",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-3442"
},
{
"name": "CVE-2024-58238",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58238"
},
{
"name": "CVE-2024-13176",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-13176"
},
{
"name": "CVE-2025-68814",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68814"
},
{
"name": "CVE-2025-22039",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22039"
},
{
"name": "CVE-2025-37842",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37842"
},
{
"name": "CVE-2025-39933",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39933"
},
{
"name": "CVE-2025-40237",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40237"
},
{
"name": "CVE-2022-49722",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49722"
},
{
"name": "CVE-2026-23745",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23745"
},
{
"name": "CVE-2025-68780",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68780"
},
{
"name": "CVE-2024-35945",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35945"
},
{
"name": "CVE-2025-39990",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39990"
},
{
"name": "CVE-2025-15467",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-15467"
},
{
"name": "CVE-2025-71081",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71081"
},
{
"name": "CVE-2023-53780",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53780"
},
{
"name": "CVE-2020-35501",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-35501"
},
{
"name": "CVE-2024-58251",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58251"
},
{
"name": "CVE-2025-38710",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38710"
},
{
"name": "CVE-2025-9820",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-9820"
},
{
"name": "CVE-2023-52624",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52624"
},
{
"name": "CVE-2024-56557",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56557"
},
{
"name": "CVE-2022-49699",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49699"
},
{
"name": "CVE-2022-50700",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50700"
},
{
"name": "CVE-2023-52632",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52632"
},
{
"name": "CVE-2024-46836",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46836"
},
{
"name": "CVE-2026-23101",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23101"
},
{
"name": "CVE-2026-23099",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23099"
},
{
"name": "CVE-2024-38556",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38556"
},
{
"name": "CVE-2025-1180",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-1180"
},
{
"name": "CVE-2025-38060",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38060"
},
{
"name": "CVE-2022-48929",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48929"
},
{
"name": "CVE-2025-55130",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-55130"
},
{
"name": "CVE-2025-36070",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-36070"
},
{
"name": "CVE-2024-46820",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46820"
},
{
"name": "CVE-2025-39770",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39770"
},
{
"name": "CVE-2025-38105",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38105"
},
{
"name": "CVE-2025-37744",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37744"
},
{
"name": "CVE-2025-38705",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38705"
},
{
"name": "CVE-2023-53198",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53198"
},
{
"name": "CVE-2023-53846",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53846"
},
{
"name": "CVE-2025-71121",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71121"
},
{
"name": "CVE-2024-35942",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35942"
},
{
"name": "CVE-2022-1247",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-1247"
},
{
"name": "CVE-2025-40333",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40333"
},
{
"name": "CVE-2022-50234",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50234"
},
{
"name": "CVE-2025-38082",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38082"
},
{
"name": "CVE-2025-37884",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37884"
},
{
"name": "CVE-2024-58054",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58054"
},
{
"name": "CVE-2024-49934",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49934"
},
{
"name": "CVE-2025-39750",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39750"
},
{
"name": "CVE-2025-38022",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38022"
},
{
"name": "CVE-2026-23066",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23066"
},
{
"name": "CVE-2025-38562",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38562"
},
{
"name": "CVE-2023-4969",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-4969"
},
{
"name": "CVE-2024-50098",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50098"
},
{
"name": "CVE-2024-35946",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35946"
},
{
"name": "CVE-2023-44487",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-44487"
},
{
"name": "CVE-2023-53789",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53789"
},
{
"name": "CVE-2022-49858",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49858"
},
{
"name": "CVE-2025-39692",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39692"
},
{
"name": "CVE-2024-35959",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35959"
},
{
"name": "CVE-2023-5363",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-5363"
},
{
"name": "CVE-2025-36428",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-36428"
},
{
"name": "CVE-2023-53520",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53520"
},
{
"name": "CVE-2026-23085",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23085"
},
{
"name": "CVE-2023-52737",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52737"
},
{
"name": "CVE-2025-40360",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40360"
},
{
"name": "CVE-2026-23209",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23209"
},
{
"name": "CVE-2025-71136",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71136"
},
{
"name": "CVE-2024-35803",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35803"
},
{
"name": "CVE-2025-22105",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22105"
},
{
"name": "CVE-2024-8612",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-8612"
},
{
"name": "CVE-2023-52586",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52586"
},
{
"name": "CVE-2025-40332",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40332"
},
{
"name": "CVE-2021-46195",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-46195"
},
{
"name": "CVE-2025-68354",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68354"
},
{
"name": "CVE-2025-68801",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68801"
},
{
"name": "CVE-2021-33110",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-33110"
},
{
"name": "CVE-2025-37834",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37834"
},
{
"name": "CVE-2025-21833",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21833"
},
{
"name": "CVE-2025-40082",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40082"
},
{
"name": "CVE-2019-19378",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-19378"
},
{
"name": "CVE-2026-23150",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23150"
},
{
"name": "CVE-2024-40972",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40972"
},
{
"name": "CVE-2025-61985",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-61985"
},
{
"name": "CVE-2025-71073",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71073"
},
{
"name": "CVE-2025-38426",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38426"
},
{
"name": "CVE-2025-38436",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38436"
},
{
"name": "CVE-2024-36911",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36911"
},
{
"name": "CVE-2025-55131",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-55131"
},
{
"name": "CVE-2025-40104",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40104"
},
{
"name": "CVE-2024-36917",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36917"
},
{
"name": "CVE-2025-38097",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38097"
},
{
"name": "CVE-2026-23236",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23236"
},
{
"name": "CVE-2023-53068",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53068"
},
{
"name": "CVE-2025-22090",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22090"
},
{
"name": "CVE-2025-61919",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-61919"
},
{
"name": "CVE-2021-31615",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-31615"
},
{
"name": "CVE-2024-1737",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-1737"
},
{
"name": "CVE-2025-40097",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40097"
},
{
"name": "CVE-2022-49932",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49932"
},
{
"name": "CVE-2022-25837",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-25837"
},
{
"name": "CVE-2025-68258",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68258"
},
{
"name": "CVE-2024-49939",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49939"
},
{
"name": "CVE-2025-38239",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38239"
},
{
"name": "CVE-2024-49905",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49905"
},
{
"name": "CVE-2023-52831",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52831"
},
{
"name": "CVE-2023-53221",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53221"
},
{
"name": "CVE-2024-26719",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26719"
},
{
"name": "CVE-2022-44034",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-44034"
},
{
"name": "CVE-2022-40897",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-40897"
},
{
"name": "CVE-2023-53072",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53072"
},
{
"name": "CVE-2023-2007",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-2007"
},
{
"name": "CVE-2022-37341",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-37341"
},
{
"name": "CVE-2025-69648",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-69648"
},
{
"name": "CVE-2023-0466",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-0466"
},
{
"name": "CVE-2024-50298",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50298"
},
{
"name": "CVE-2025-36424",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-36424"
},
{
"name": "CVE-2025-21915",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21915"
},
{
"name": "CVE-2025-38590",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38590"
},
{
"name": "CVE-2024-46843",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46843"
},
{
"name": "CVE-2025-21792",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21792"
},
{
"name": "CVE-2023-54016",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54016"
},
{
"name": "CVE-2025-36387",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-36387"
},
{
"name": "CVE-2025-38709",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38709"
},
{
"name": "CVE-2024-58018",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58018"
},
{
"name": "CVE-2023-4408",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-4408"
},
{
"name": "CVE-2025-71235",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71235"
},
{
"name": "CVE-2025-61771",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-61771"
},
{
"name": "CVE-2023-53602",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53602"
},
{
"name": "CVE-2023-2828",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-2828"
},
{
"name": "CVE-2023-54035",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54035"
},
{
"name": "CVE-2025-40322",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40322"
},
{
"name": "CVE-2023-53867",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53867"
},
{
"name": "CVE-2023-0465",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-0465"
},
{
"name": "CVE-2025-61770",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-61770"
},
{
"name": "CVE-2025-37926",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37926"
},
{
"name": "CVE-2024-46715",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46715"
},
{
"name": "CVE-2025-38038",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38038"
},
{
"name": "CVE-2024-46802",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46802"
},
{
"name": "CVE-2025-39859",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39859"
},
{
"name": "CVE-2025-40313",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40313"
},
{
"name": "CVE-2023-52582",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52582"
},
{
"name": "CVE-2023-33053",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-33053"
},
{
"name": "CVE-2025-1152",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-1152"
},
{
"name": "CVE-2026-24051",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-24051"
},
{
"name": "CVE-2025-38015",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38015"
},
{
"name": "CVE-2024-26742",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26742"
},
{
"name": "CVE-2025-38449",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38449"
},
{
"name": "CVE-2025-21714",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21714"
},
{
"name": "CVE-2025-38261",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38261"
},
{
"name": "CVE-2024-36918",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36918"
},
{
"name": "CVE-2025-37853",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37853"
},
{
"name": "CVE-2025-69644",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-69644"
},
{
"name": "CVE-2022-49303",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49303"
},
{
"name": "CVE-2025-38126",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38126"
},
{
"name": "CVE-2023-46809",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-46809"
},
{
"name": "CVE-2025-59465",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-59465"
},
{
"name": "CVE-2025-39763",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39763"
},
{
"name": "CVE-2025-21972",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21972"
},
{
"name": "CVE-2023-54088",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54088"
},
{
"name": "CVE-2024-42320",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42320"
},
{
"name": "CVE-2025-38679",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38679"
},
{
"name": "CVE-2025-40271",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40271"
},
{
"name": "CVE-2024-53234",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53234"
},
{
"name": "CVE-2025-11961",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-11961"
},
{
"name": "CVE-2025-39877",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39877"
},
{
"name": "CVE-2022-3114",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-3114"
},
{
"name": "CVE-2023-52916",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52916"
},
{
"name": "CVE-2025-38064",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38064"
},
{
"name": "CVE-2026-22991",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22991"
},
{
"name": "CVE-2024-35937",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35937"
},
{
"name": "CVE-2022-50628",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50628"
},
{
"name": "CVE-2024-56718",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56718"
},
{
"name": "CVE-2024-43824",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43824"
},
{
"name": "CVE-2025-39886",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39886"
},
{
"name": "CVE-2022-50350",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50350"
},
{
"name": "CVE-2025-21831",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21831"
},
{
"name": "CVE-2022-50721",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50721"
},
{
"name": "CVE-2022-50095",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50095"
},
{
"name": "CVE-2025-40073",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40073"
},
{
"name": "CVE-2024-26662",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26662"
},
{
"name": "CVE-2026-3196",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-3196"
},
{
"name": "CVE-2025-61662",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-61662"
},
{
"name": "CVE-2025-8291",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-8291"
},
{
"name": "CVE-2025-68308",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68308"
},
{
"name": "CVE-2024-50217",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50217"
},
{
"name": "CVE-2021-0168",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-0168"
},
{
"name": "CVE-2026-22795",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22795"
},
{
"name": "CVE-2022-50479",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50479"
},
{
"name": "CVE-2022-50583",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50583"
},
{
"name": "CVE-2025-37806",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37806"
},
{
"name": "CVE-2024-38554",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38554"
},
{
"name": "CVE-2025-68822",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68822"
},
{
"name": "CVE-2025-40242",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40242"
},
{
"name": "CVE-2023-0030",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-0030"
},
{
"name": "CVE-2024-42110",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42110"
},
{
"name": "CVE-2025-37822",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37822"
},
{
"name": "CVE-2025-61727",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-61727"
},
{
"name": "CVE-2025-39838",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39838"
},
{
"name": "CVE-2025-37820",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37820"
},
{
"name": "CVE-2024-53179",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53179"
},
{
"name": "CVE-2024-57945",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57945"
},
{
"name": "CVE-2023-54233",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54233"
},
{
"name": "CVE-2024-43899",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43899"
},
{
"name": "CVE-2025-21986",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21986"
},
{
"name": "CVE-2019-15213",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-15213"
},
{
"name": "CVE-2025-38234",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38234"
},
{
"name": "CVE-2022-49935",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49935"
},
{
"name": "CVE-2021-44532",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-44532"
},
{
"name": "CVE-2025-38011",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38011"
},
{
"name": "CVE-2022-49534",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49534"
},
{
"name": "CVE-2024-57974",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57974"
},
{
"name": "CVE-2024-50012",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50012"
},
{
"name": "CVE-2025-68190",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68190"
},
{
"name": "CVE-2023-53010",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53010"
},
{
"name": "CVE-2024-35956",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35956"
},
{
"name": "CVE-2024-57888",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57888"
},
{
"name": "CVE-2025-65637",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-65637"
},
{
"name": "CVE-2024-35908",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35908"
},
{
"name": "CVE-2023-54237",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54237"
},
{
"name": "CVE-2025-37878",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37878"
},
{
"name": "CVE-2023-53424",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53424"
},
{
"name": "CVE-2026-23207",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23207"
},
{
"name": "CVE-2025-40252",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40252"
},
{
"name": "CVE-2022-49134",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49134"
},
{
"name": "CVE-2025-21946",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21946"
},
{
"name": "CVE-2025-21838",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21838"
},
{
"name": "CVE-2022-49333",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49333"
},
{
"name": "CVE-2023-53791",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53791"
},
{
"name": "CVE-2025-27111",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-27111"
},
{
"name": "CVE-2024-49994",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49994"
},
{
"name": "CVE-2025-53859",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-53859"
},
{
"name": "CVE-2019-19814",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-19814"
},
{
"name": "CVE-2022-49136",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49136"
},
{
"name": "CVE-2025-68255",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68255"
},
{
"name": "CVE-2025-47910",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-47910"
},
{
"name": "CVE-2023-54081",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54081"
},
{
"name": "CVE-2024-36898",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36898"
},
{
"name": "CVE-2024-44962",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44962"
},
{
"name": "CVE-2025-68322",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68322"
},
{
"name": "CVE-2024-35931",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35931"
},
{
"name": "CVE-2025-38702",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38702"
},
{
"name": "CVE-2026-22980",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22980"
},
{
"name": "CVE-2026-23138",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23138"
},
{
"name": "CVE-2025-39927",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39927"
},
{
"name": "CVE-2026-1703",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-1703"
},
{
"name": "CVE-2023-26551",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-26551"
},
{
"name": "CVE-2024-46857",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46857"
},
{
"name": "CVE-2024-58013",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58013"
},
{
"name": "CVE-2024-53210",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53210"
},
{
"name": "CVE-2023-54185",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54185"
},
{
"name": "CVE-2022-49342",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49342"
},
{
"name": "CVE-2015-8553",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-8553"
},
{
"name": "CVE-2025-40277",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40277"
},
{
"name": "CVE-2025-38250",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38250"
},
{
"name": "CVE-2024-36966",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36966"
},
{
"name": "CVE-2023-53332",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53332"
},
{
"name": "CVE-2024-35924",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35924"
},
{
"name": "CVE-2024-58095",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58095"
},
{
"name": "CVE-2024-45010",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45010"
},
{
"name": "CVE-2022-49471",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49471"
},
{
"name": "CVE-2025-68174",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68174"
},
{
"name": "CVE-2022-48976",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48976"
},
{
"name": "CVE-2025-21751",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21751"
},
{
"name": "CVE-2023-53753",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53753"
},
{
"name": "CVE-2024-41074",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41074"
},
{
"name": "CVE-2026-23234",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23234"
},
{
"name": "CVE-2025-40272",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40272"
},
{
"name": "CVE-2024-50106",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50106"
},
{
"name": "CVE-2025-23162",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23162"
},
{
"name": "CVE-2026-23133",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23133"
},
{
"name": "CVE-2025-71093",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71093"
},
{
"name": "CVE-2025-46727",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-46727"
},
{
"name": "CVE-2017-13694",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-13694"
},
{
"name": "CVE-2025-71102",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71102"
},
{
"name": "CVE-2026-23212",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23212"
},
{
"name": "CVE-2013-7445",
"url": "https://www.cve.org/CVERecord?id=CVE-2013-7445"
},
{
"name": "CVE-2026-23170",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23170"
},
{
"name": "CVE-2023-52701",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52701"
},
{
"name": "CVE-2024-49906",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49906"
},
{
"name": "CVE-2024-26647",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26647"
},
{
"name": "CVE-2025-68759",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68759"
},
{
"name": "CVE-2024-47809",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47809"
},
{
"name": "CVE-2026-23204",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23204"
},
{
"name": "CVE-2022-49317",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49317"
},
{
"name": "CVE-2026-23019",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23019"
},
{
"name": "CVE-2018-12928",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-12928"
},
{
"name": "CVE-2025-71188",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71188"
},
{
"name": "CVE-2023-38552",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-38552"
},
{
"name": "CVE-2024-40989",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40989"
},
{
"name": "CVE-2024-56607",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56607"
},
{
"name": "CVE-2025-40345",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40345"
},
{
"name": "CVE-2026-27142",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-27142"
},
{
"name": "CVE-2024-49904",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49904"
},
{
"name": "CVE-2023-53671",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53671"
},
{
"name": "CVE-2025-40354",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40354"
},
{
"name": "CVE-2024-26938",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26938"
},
{
"name": "CVE-2026-28417",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-28417"
},
{
"name": "CVE-2025-37931",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37931"
},
{
"name": "CVE-2024-35999",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35999"
},
{
"name": "CVE-2023-29942",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-29942"
},
{
"name": "CVE-2026-23125",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23125"
},
{
"name": "CVE-2026-0966",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-0966"
},
{
"name": "CVE-2022-48633",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48633"
},
{
"name": "CVE-2022-3238",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-3238"
},
{
"name": "CVE-2024-38557",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38557"
},
{
"name": "CVE-2026-22185",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22185"
},
{
"name": "CVE-2023-53781",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53781"
},
{
"name": "CVE-2023-53584",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53584"
},
{
"name": "CVE-2024-57809",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57809"
},
{
"name": "CVE-2025-38057",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38057"
},
{
"name": "CVE-2025-68733",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68733"
},
{
"name": "CVE-2024-56719",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56719"
},
{
"name": "CVE-2022-50418",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50418"
},
{
"name": "CVE-2023-53438",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53438"
},
{
"name": "CVE-2025-47906",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-47906"
},
{
"name": "CVE-2023-53460",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53460"
},
{
"name": "CVE-2026-23214",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23214"
},
{
"name": "CVE-2024-52559",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-52559"
},
{
"name": "CVE-2025-68188",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68188"
},
{
"name": "CVE-2025-40269",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40269"
},
{
"name": "CVE-2024-56671",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56671"
},
{
"name": "CVE-2025-68335",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68335"
},
{
"name": "CVE-2025-71079",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71079"
},
{
"name": "CVE-2025-62626",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-62626"
},
{
"name": "CVE-2025-39940",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39940"
},
{
"name": "CVE-2023-52751",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52751"
},
{
"name": "CVE-2022-49562",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49562"
},
{
"name": "CVE-2025-37861",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37861"
},
{
"name": "CVE-2023-53483",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53483"
},
{
"name": "CVE-2023-53673",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53673"
},
{
"name": "CVE-2025-37938",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37938"
},
{
"name": "CVE-2025-37746",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37746"
},
{
"name": "CVE-2022-38076",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-38076"
},
{
"name": "CVE-2025-38368",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38368"
},
{
"name": "CVE-2026-23178",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23178"
},
{
"name": "CVE-2025-59375",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-59375"
},
{
"name": "CVE-2025-31133",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-31133"
},
{
"name": "CVE-2026-22997",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22997"
},
{
"name": "CVE-2024-56368",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56368"
},
{
"name": "CVE-2025-40075",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40075"
},
{
"name": "CVE-2022-49172",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49172"
},
{
"name": "CVE-2025-8194",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-8194"
},
{
"name": "CVE-2024-40979",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40979"
},
{
"name": "CVE-2025-39977",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39977"
},
{
"name": "CVE-2025-38331",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38331"
},
{
"name": "CVE-2026-23240",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23240"
},
{
"name": "CVE-2025-68330",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68330"
},
{
"name": "CVE-2026-23228",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23228"
},
{
"name": "CVE-2024-49945",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49945"
},
{
"name": "CVE-2022-44033",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-44033"
},
{
"name": "CVE-2024-56757",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56757"
},
{
"name": "CVE-2023-53662",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53662"
},
{
"name": "CVE-2025-38069",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38069"
},
{
"name": "CVE-2022-49750",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49750"
},
{
"name": "CVE-2023-53707",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53707"
},
{
"name": "CVE-2023-53115",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53115"
},
{
"name": "CVE-2025-71196",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71196"
},
{
"name": "CVE-2025-21645",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21645"
},
{
"name": "CVE-2023-54107",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54107"
},
{
"name": "CVE-2022-48646",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48646"
},
{
"name": "CVE-2024-43912",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43912"
},
{
"name": "CVE-2024-35808",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35808"
},
{
"name": "CVE-2024-58012",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58012"
},
{
"name": "CVE-2025-50181",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-50181"
},
{
"name": "CVE-2025-61663",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-61663"
},
{
"name": "CVE-2025-68772",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68772"
},
{
"name": "CVE-2024-49891",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49891"
},
{
"name": "CVE-2024-36948",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36948"
},
{
"name": "CVE-2022-48887",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48887"
},
{
"name": "CVE-2024-40977",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40977"
},
{
"name": "CVE-2024-26948",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26948"
},
{
"name": "CVE-2023-53370",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53370"
},
{
"name": "CVE-2024-53187",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53187"
},
{
"name": "CVE-2023-45929",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-45929"
},
{
"name": "CVE-2025-68343",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68343"
},
{
"name": "CVE-2025-66382",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-66382"
},
{
"name": "CVE-2024-57795",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57795"
},
{
"name": "CVE-2025-37855",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37855"
},
{
"name": "CVE-2025-21816",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21816"
},
{
"name": "CVE-2021-33115",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-33115"
},
{
"name": "CVE-2025-21780",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21780"
},
{
"name": "CVE-2020-26559",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-26559"
},
{
"name": "CVE-2024-12705",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-12705"
},
{
"name": "CVE-2025-69421",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-69421"
},
{
"name": "CVE-2020-26140",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-26140"
},
{
"name": "CVE-2024-39508",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39508"
},
{
"name": "CVE-2026-23191",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23191"
},
{
"name": "CVE-2026-32249",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-32249"
},
{
"name": "CVE-2025-37899",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37899"
},
{
"name": "CVE-2026-23078",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23078"
},
{
"name": "CVE-2025-40362",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40362"
},
{
"name": "CVE-2025-68201",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68201"
},
{
"name": "CVE-2024-43831",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43831"
},
{
"name": "CVE-2023-30630",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-30630"
},
{
"name": "CVE-2025-40289",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40289"
},
{
"name": "CVE-2026-23169",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23169"
},
{
"name": "CVE-2025-38330",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38330"
},
{
"name": "CVE-2025-58188",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-58188"
},
{
"name": "CVE-2017-13693",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-13693"
},
{
"name": "CVE-2025-68768",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68768"
},
{
"name": "CVE-2024-50284",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50284"
},
{
"name": "CVE-2022-49306",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49306"
},
{
"name": "CVE-2024-49898",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49898"
},
{
"name": "CVE-2025-36423",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-36423"
},
{
"name": "CVE-2022-49622",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49622"
},
{
"name": "CVE-2025-68785",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68785"
},
{
"name": "CVE-2024-50211",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50211"
},
{
"name": "CVE-2025-38507",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38507"
},
{
"name": "CVE-2022-50284",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50284"
},
{
"name": "CVE-2025-39989",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39989"
},
{
"name": "CVE-2023-6240",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-6240"
},
{
"name": "CVE-2025-38014",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38014"
},
{
"name": "CVE-2025-22028",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22028"
},
{
"name": "CVE-2024-41008",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41008"
},
{
"name": "CVE-2024-27035",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27035"
},
{
"name": "CVE-2023-53218",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53218"
},
{
"name": "CVE-2022-25836",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-25836"
},
{
"name": "CVE-2024-37354",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-37354"
},
{
"name": "CVE-2025-68808",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68808"
},
{
"name": "CVE-2025-4674",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-4674"
},
{
"name": "CVE-2025-29934",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-29934"
},
{
"name": "CVE-2024-27005",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27005"
},
{
"name": "CVE-2025-68223",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68223"
},
{
"name": "CVE-2022-49133",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49133"
},
{
"name": "CVE-2024-36951",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36951"
},
{
"name": "CVE-2025-68783",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68783"
},
{
"name": "CVE-2025-71147",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71147"
},
{
"name": "CVE-2025-38438",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38438"
},
{
"name": "CVE-2025-40032",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40032"
},
{
"name": "CVE-2023-26555",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-26555"
},
{
"name": "CVE-2023-1193",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-1193"
},
{
"name": "CVE-2025-71220",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71220"
},
{
"name": "CVE-2024-46806",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46806"
},
{
"name": "CVE-2022-50073",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50073"
},
{
"name": "CVE-2025-68724",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68724"
},
{
"name": "CVE-2025-5278",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-5278"
},
{
"name": "CVE-2026-23103",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23103"
},
{
"name": "CVE-2026-23074",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23074"
},
{
"name": "CVE-2025-68786",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68786"
},
{
"name": "CVE-2025-39732",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39732"
},
{
"name": "CVE-2022-50393",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50393"
},
{
"name": "CVE-2025-68779",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68779"
},
{
"name": "CVE-2024-56433",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56433"
},
{
"name": "CVE-2025-21819",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21819"
},
{
"name": "CVE-2025-48514",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-48514"
},
{
"name": "CVE-2024-41030",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41030"
},
{
"name": "CVE-2025-71199",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71199"
},
{
"name": "CVE-2024-47664",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47664"
},
{
"name": "CVE-2024-36915",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36915"
},
{
"name": "CVE-2026-25749",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-25749"
},
{
"name": "CVE-2024-49504",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49504"
},
{
"name": "CVE-2025-38118",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38118"
},
{
"name": "CVE-2023-0464",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-0464"
},
{
"name": "CVE-2023-53367",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53367"
},
{
"name": "CVE-2022-50500",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50500"
},
{
"name": "CVE-2019-14899",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-14899"
},
{
"name": "CVE-2022-29526",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-29526"
},
{
"name": "CVE-2024-53098",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53098"
},
{
"name": "CVE-2025-68797",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68797"
},
{
"name": "CVE-2024-49968",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49968"
},
{
"name": "CVE-2025-68358",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68358"
},
{
"name": "CVE-2025-40206",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40206"
},
{
"name": "CVE-2026-23180",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23180"
},
{
"name": "CVE-2021-0164",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-0164"
},
{
"name": "CVE-2026-26958",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-26958"
},
{
"name": "CVE-2024-46870",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46870"
},
{
"name": "CVE-2022-49178",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49178"
},
{
"name": "CVE-2024-22195",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-22195"
},
{
"name": "CVE-2023-23931",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-23931"
},
{
"name": "CVE-2024-49929",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49929"
},
{
"name": "CVE-2025-40257",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40257"
},
{
"name": "CVE-2023-53748",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53748"
},
{
"name": "CVE-2024-26740",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26740"
},
{
"name": "CVE-2022-49173",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49173"
},
{
"name": "CVE-2024-45781",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45781"
},
{
"name": "CVE-2025-71125",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71125"
},
{
"name": "CVE-2025-21947",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21947"
},
{
"name": "CVE-2024-53056",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53056"
},
{
"name": "CVE-2022-50551",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50551"
},
{
"name": "CVE-2026-26269",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-26269"
},
{
"name": "CVE-2024-43872",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43872"
},
{
"name": "CVE-2025-71108",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71108"
},
{
"name": "CVE-2022-49401",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49401"
},
{
"name": "CVE-2025-71069",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71069"
},
{
"name": "CVE-2025-68312",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68312"
},
{
"name": "CVE-2025-68284",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68284"
},
{
"name": "CVE-2025-68194",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68194"
},
{
"name": "CVE-2023-52939",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52939"
},
{
"name": "CVE-2024-14027",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-14027"
},
{
"name": "CVE-2025-38269",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38269"
},
{
"name": "CVE-2025-69649",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-69649"
},
{
"name": "CVE-2024-53175",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53175"
},
{
"name": "CVE-2025-21734",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21734"
},
{
"name": "CVE-2024-49859",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49859"
},
{
"name": "CVE-2025-40336",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40336"
},
{
"name": "CVE-2025-37945",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37945"
},
{
"name": "CVE-2025-71195",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71195"
},
{
"name": "CVE-2022-49766",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49766"
},
{
"name": "CVE-2025-6141",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-6141"
},
{
"name": "CVE-2025-22043",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22043"
},
{
"name": "CVE-2024-49569",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49569"
},
{
"name": "CVE-2025-61984",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-61984"
},
{
"name": "CVE-2023-52569",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52569"
},
{
"name": "CVE-2024-56609",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56609"
},
{
"name": "CVE-2022-49940",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49940"
},
{
"name": "CVE-2026-23083",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23083"
},
{
"name": "CVE-2025-38422",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38422"
},
{
"name": "CVE-2024-56611",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56611"
},
{
"name": "CVE-2025-21927",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21927"
},
{
"name": "CVE-2026-23088",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23088"
},
{
"name": "CVE-2020-25743",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-25743"
},
{
"name": "CVE-2022-50167",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50167"
},
{
"name": "CVE-2025-68183",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68183"
},
{
"name": "CVE-2026-27704",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-27704"
},
{
"name": "CVE-2022-48064",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48064"
},
{
"name": "CVE-2023-45896",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-45896"
},
{
"name": "CVE-2025-37903",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37903"
},
{
"name": "CVE-2025-68161",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68161"
},
{
"name": "CVE-2025-68774",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68774"
},
{
"name": "CVE-2024-49940",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49940"
},
{
"name": "CVE-2025-40263",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40263"
},
{
"name": "CVE-2021-3735",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-3735"
},
{
"name": "CVE-2025-40353",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40353"
},
{
"name": "CVE-2024-46861",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46861"
},
{
"name": "CVE-2025-40222",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40222"
},
{
"name": "CVE-2022-50634",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50634"
},
{
"name": "CVE-2025-52881",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-52881"
},
{
"name": "CVE-2025-54514",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-54514"
},
{
"name": "CVE-2025-71202",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71202"
},
{
"name": "CVE-2015-7837",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-7837"
},
{
"name": "CVE-2025-0677",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-0677"
},
{
"name": "CVE-2024-45780",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45780"
},
{
"name": "CVE-2024-46749",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46749"
},
{
"name": "CVE-2022-50492",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50492"
},
{
"name": "CVE-2024-49888",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49888"
},
{
"name": "CVE-2022-50406",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50406"
},
{
"name": "CVE-2023-26552",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-26552"
},
{
"name": "CVE-2024-49921",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49921"
},
{
"name": "CVE-2024-5535",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-5535"
},
{
"name": "CVE-2026-23108",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23108"
},
{
"name": "CVE-2025-71180",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71180"
},
{
"name": "CVE-2025-38232",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38232"
},
{
"name": "CVE-2025-68244",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68244"
},
{
"name": "CVE-2025-59691",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-59691"
},
{
"name": "CVE-2024-46830",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46830"
},
{
"name": "CVE-2023-52481",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52481"
},
{
"name": "CVE-2023-52888",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52888"
},
{
"name": "CVE-2025-22057",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22057"
},
{
"name": "CVE-2024-47666",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47666"
},
{
"name": "CVE-2025-22868",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22868"
},
{
"name": "CVE-2025-40278",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40278"
},
{
"name": "CVE-2023-0160",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-0160"
},
{
"name": "CVE-2024-50056",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50056"
},
{
"name": "CVE-2025-71194",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71194"
},
{
"name": "CVE-2026-1788",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-1788"
},
{
"name": "CVE-2023-53721",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53721"
},
{
"name": "CVE-2025-22113",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22113"
},
{
"name": "CVE-2025-40342",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40342"
},
{
"name": "CVE-2022-50256",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50256"
},
{
"name": "CVE-2024-42091",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42091"
},
{
"name": "CVE-2024-27983",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27983"
},
{
"name": "CVE-2025-37907",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37907"
},
{
"name": "CVE-2024-38625",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38625"
},
{
"name": "CVE-2025-23085",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23085"
},
{
"name": "CVE-2026-22796",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22796"
},
{
"name": "CVE-2023-4010",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-4010"
},
{
"name": "CVE-2025-38425",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38425"
},
{
"name": "CVE-2024-46727",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46727"
},
{
"name": "CVE-2023-54028",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54028"
},
{
"name": "CVE-2024-42129",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42129"
},
{
"name": "CVE-2023-54105",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54105"
},
{
"name": "CVE-2018-17977",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-17977"
},
{
"name": "CVE-2019-1010204",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-1010204"
},
{
"name": "CVE-2023-53992",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53992"
},
{
"name": "CVE-2026-26960",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-26960"
},
{
"name": "CVE-2025-40210",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40210"
},
{
"name": "CVE-2022-50354",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50354"
},
{
"name": "CVE-2025-61724",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-61724"
},
{
"name": "CVE-2026-22999",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22999"
},
{
"name": "CVE-2025-21812",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21812"
},
{
"name": "CVE-2025-71082",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71082"
},
{
"name": "CVE-2025-12801",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-12801"
},
{
"name": "CVE-2024-58015",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58015"
},
{
"name": "CVE-2026-23068",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23068"
},
{
"name": "CVE-2024-41079",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41079"
},
{
"name": "CVE-2025-68765",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68765"
},
{
"name": "CVE-2026-23089",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23089"
},
{
"name": "CVE-2024-43823",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43823"
},
{
"name": "CVE-2023-52589",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52589"
},
{
"name": "CVE-2022-41848",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-41848"
},
{
"name": "CVE-2026-23216",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23216"
},
{
"name": "CVE-2023-53434",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53434"
},
{
"name": "CVE-2023-29935",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-29935"
},
{
"name": "CVE-2023-35061",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-35061"
},
{
"name": "CVE-2025-71132",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71132"
},
{
"name": "CVE-2025-71225",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71225"
},
{
"name": "CVE-2026-21636",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-21636"
},
{
"name": "CVE-2026-23239",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23239"
},
{
"name": "CVE-2021-0172",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-0172"
},
{
"name": "CVE-2024-47662",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47662"
},
{
"name": "CVE-2018-12930",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-12930"
},
{
"name": "CVE-2026-23071",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23071"
},
{
"name": "CVE-2024-49970",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49970"
},
{
"name": "CVE-2024-41067",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41067"
},
{
"name": "CVE-2024-26844",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26844"
},
{
"name": "CVE-2025-23141",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23141"
},
{
"name": "CVE-2026-23056",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23056"
},
{
"name": "CVE-2025-40193",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40193"
},
{
"name": "CVE-2023-32644",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-32644"
},
{
"name": "CVE-2025-71077",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71077"
},
{
"name": "CVE-2025-21908",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21908"
},
{
"name": "CVE-2024-46681",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46681"
},
{
"name": "CVE-2024-36927",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36927"
},
{
"name": "CVE-2025-61732",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-61732"
},
{
"name": "CVE-2025-61723",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-61723"
},
{
"name": "CVE-2025-9232",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-9232"
},
{
"name": "CVE-2025-40012",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40012"
},
{
"name": "CVE-2025-40279",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40279"
},
{
"name": "CVE-2026-0964",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-0964"
},
{
"name": "CVE-2025-68328",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68328"
},
{
"name": "CVE-2023-53178",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53178"
},
{
"name": "CVE-2024-47141",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47141"
},
{
"name": "CVE-2024-8354",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-8354"
},
{
"name": "CVE-2023-54323",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54323"
},
{
"name": "CVE-2025-37952",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37952"
},
{
"name": "CVE-2023-45803",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-45803"
},
{
"name": "CVE-2025-0689",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-0689"
},
{
"name": "CVE-2022-50316",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50316"
},
{
"name": "CVE-2023-31347",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-31347"
},
{
"name": "CVE-2025-40084",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40084"
},
{
"name": "CVE-2025-22111",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22111"
},
{
"name": "CVE-2023-53657",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53657"
},
{
"name": "CVE-2024-49915",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49915"
},
{
"name": "CVE-2026-23063",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23063"
},
{
"name": "CVE-2025-55132",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-55132"
},
{
"name": "CVE-2023-52732",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52732"
},
{
"name": "CVE-2022-49759",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49759"
},
{
"name": "CVE-2025-61795",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-61795"
},
{
"name": "CVE-2026-23073",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23073"
},
{
"name": "CVE-2022-49167",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49167"
},
{
"name": "CVE-2025-68311",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68311"
},
{
"name": "CVE-2026-27903",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-27903"
},
{
"name": "CVE-2023-54023",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54023"
},
{
"name": "CVE-2024-27056",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27056"
},
{
"name": "CVE-2023-31082",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-31082"
},
{
"name": "CVE-2024-41088",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41088"
},
{
"name": "CVE-2025-0690",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-0690"
},
{
"name": "CVE-2025-71114",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71114"
},
{
"name": "CVE-2023-53052",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53052"
},
{
"name": "CVE-2026-23058",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23058"
},
{
"name": "CVE-2022-49234",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49234"
},
{
"name": "CVE-2022-50163",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50163"
},
{
"name": "CVE-2024-36922",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36922"
},
{
"name": "CVE-2025-71067",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71067"
},
{
"name": "CVE-2024-49919",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49919"
},
{
"name": "CVE-2026-23238",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23238"
},
{
"name": "CVE-2025-71182",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71182"
},
{
"name": "CVE-2020-26556",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-26556"
},
{
"name": "CVE-2025-46394",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-46394"
},
{
"name": "CVE-2025-66471",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-66471"
},
{
"name": "CVE-2026-23038",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23038"
},
{
"name": "CVE-2025-40341",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40341"
},
{
"name": "CVE-2025-38409",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38409"
},
{
"name": "CVE-2021-3826",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-3826"
},
{
"name": "CVE-2024-26699",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26699"
},
{
"name": "CVE-2024-57876",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57876"
},
{
"name": "CVE-2024-58019",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58019"
},
{
"name": "CVE-2026-25679",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-25679"
},
{
"name": "CVE-2026-22990",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22990"
},
{
"name": "CVE-2025-14017",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-14017"
},
{
"name": "CVE-2022-50390",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50390"
},
{
"name": "CVE-2026-23000",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23000"
},
{
"name": "CVE-2026-21441",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-21441"
},
{
"name": "CVE-2024-45337",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45337"
},
{
"name": "CVE-2025-71186",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71186"
},
{
"name": "CVE-2024-53220",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53220"
},
{
"name": "CVE-2026-23176",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23176"
},
{
"name": "CVE-2023-53539",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53539"
},
{
"name": "CVE-2025-13836",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-13836"
},
{
"name": "CVE-2025-40338",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40338"
},
{
"name": "CVE-2025-68821",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68821"
},
{
"name": "CVE-2025-31648",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-31648"
},
{
"name": "CVE-2025-0678",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-0678"
},
{
"name": "CVE-2024-41075",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41075"
},
{
"name": "CVE-2026-23026",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23026"
},
{
"name": "CVE-2024-56674",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56674"
},
{
"name": "CVE-2024-27982",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27982"
},
{
"name": "CVE-2025-40195",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40195"
},
{
"name": "CVE-2024-31884",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-31884"
},
{
"name": "CVE-2025-21976",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21976"
},
{
"name": "CVE-2019-1563",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-1563"
},
{
"name": "CVE-2026-1002",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-1002"
},
{
"name": "CVE-2026-23128",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23128"
},
{
"name": "CVE-2024-57975",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57975"
},
{
"name": "CVE-2023-53574",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53574"
},
{
"name": "CVE-2022-50166",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50166"
},
{
"name": "CVE-2025-61725",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-61725"
},
{
"name": "CVE-2025-68325",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68325"
},
{
"name": "CVE-2025-71190",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71190"
},
{
"name": "CVE-2024-56738",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56738"
},
{
"name": "CVE-2022-50778",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50778"
},
{
"name": "CVE-2024-42067",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42067"
},
{
"name": "CVE-2022-49971",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49971"
},
{
"name": "CVE-2025-71089",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71089"
},
{
"name": "CVE-2025-21693",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21693"
},
{
"name": "CVE-2025-71203",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71203"
},
{
"name": "CVE-2024-56657",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56657"
},
{
"name": "CVE-2025-39789",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39789"
},
{
"name": "CVE-2022-49124",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49124"
},
{
"name": "CVE-2024-49901",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49901"
},
{
"name": "CVE-2023-52700",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52700"
},
{
"name": "CVE-2024-56583",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56583"
},
{
"name": "CVE-2022-50195",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50195"
},
{
"name": "CVE-2025-40358",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40358"
},
{
"name": "CVE-2024-40998",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40998"
},
{
"name": "CVE-2024-56712",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56712"
},
{
"name": "CVE-2025-68318",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68318"
},
{
"name": "CVE-2022-49980",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49980"
},
{
"name": "CVE-2023-52634",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52634"
},
{
"name": "CVE-2025-22104",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22104"
},
{
"name": "CVE-2022-2795",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-2795"
},
{
"name": "CVE-2025-62526",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-62526"
},
{
"name": "CVE-2024-49918",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49918"
},
{
"name": "CVE-2025-68296",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68296"
},
{
"name": "CVE-2023-53785",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53785"
},
{
"name": "CVE-2024-45776",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45776"
},
{
"name": "CVE-2022-50090",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50090"
},
{
"name": "CVE-2025-40340",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40340"
},
{
"name": "CVE-2025-68332",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68332"
},
{
"name": "CVE-2020-14356",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-14356"
},
{
"name": "CVE-2025-68745",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68745"
},
{
"name": "CVE-2023-54263",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54263"
},
{
"name": "CVE-2025-71104",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71104"
},
{
"name": "CVE-2026-22978",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22978"
},
{
"name": "CVE-2023-53764",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53764"
},
{
"name": "CVE-2024-53687",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53687"
},
{
"name": "CVE-2025-39901",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39901"
},
{
"name": "CVE-2025-40283",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40283"
},
{
"name": "CVE-2025-5918",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-5918"
},
{
"name": "CVE-2024-38628",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38628"
},
{
"name": "CVE-2025-40324",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40324"
},
{
"name": "CVE-2025-38672",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38672"
},
{
"name": "CVE-2023-54181",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54181"
},
{
"name": "CVE-2025-0684",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-0684"
},
{
"name": "CVE-2025-10158",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-10158"
},
{
"name": "CVE-2025-68378",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68378"
},
{
"name": "CVE-2024-47794",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47794"
},
{
"name": "CVE-2026-23146",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23146"
},
{
"name": "CVE-2025-38272",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38272"
},
{
"name": "CVE-2024-10524",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-10524"
},
{
"name": "CVE-2025-40146",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40146"
},
{
"name": "CVE-2025-38359",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38359"
},
{
"name": "CVE-2019-20794",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-20794"
},
{
"name": "CVE-2023-53849",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53849"
},
{
"name": "CVE-2022-4543",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-4543"
},
{
"name": "CVE-2025-21899",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21899"
},
{
"name": "CVE-2024-35195",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35195"
},
{
"name": "CVE-2025-38129",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38129"
},
{
"name": "CVE-2026-23037",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23037"
},
{
"name": "CVE-2023-53627",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53627"
},
{
"name": "CVE-2025-40250",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40250"
},
{
"name": "CVE-2025-38091",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38091"
},
{
"name": "CVE-2023-53510",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53510"
},
{
"name": "CVE-2025-40264",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40264"
},
{
"name": "CVE-2025-38334",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38334"
},
{
"name": "CVE-2023-53575",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53575"
},
{
"name": "CVE-2022-49516",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49516"
},
{
"name": "CVE-2025-40778",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40778"
},
{
"name": "CVE-2025-38728",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38728"
},
{
"name": "CVE-2022-3523",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-3523"
},
{
"name": "CVE-2026-26157",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-26157"
},
{
"name": "CVE-2026-23001",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23001"
},
{
"name": "CVE-2023-38417",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-38417"
},
{
"name": "CVE-2025-68367",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68367"
},
{
"name": "CVE-2025-71224",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71224"
},
{
"name": "CVE-2025-22072",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22072"
},
{
"name": "CVE-2025-68820",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68820"
},
{
"name": "CVE-2021-45261",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-45261"
},
{
"name": "CVE-2025-40074",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40074"
},
{
"name": "CVE-2026-23193",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23193"
},
{
"name": "CVE-2025-40321",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40321"
},
{
"name": "CVE-2024-47736",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47736"
},
{
"name": "CVE-2023-53037",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53037"
},
{
"name": "CVE-2024-46842",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46842"
},
{
"name": "CVE-2025-71237",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71237"
},
{
"name": "CVE-2025-13462",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-13462"
},
{
"name": "CVE-2024-50112",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50112"
},
{
"name": "CVE-2025-69646",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-69646"
},
{
"name": "CVE-2023-54207",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54207"
},
{
"name": "CVE-2026-23215",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23215"
},
{
"name": "CVE-2024-28956",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-28956"
},
{
"name": "CVE-2025-68740",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68740"
},
{
"name": "CVE-2020-26142",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-26142"
},
{
"name": "CVE-2022-49955",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49955"
},
{
"name": "CVE-2023-53628",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53628"
},
{
"name": "CVE-2025-29943",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-29943"
},
{
"name": "CVE-2025-39978",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39978"
},
{
"name": "CVE-2023-31346",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-31346"
},
{
"name": "CVE-2024-9143",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-9143"
},
{
"name": "CVE-2025-40158",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40158"
},
{
"name": "CVE-2024-56201",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56201"
},
{
"name": "CVE-2025-38071",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38071"
},
{
"name": "CVE-2025-38140",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38140"
},
{
"name": "CVE-2022-50002",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50002"
},
{
"name": "CVE-2025-38621",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38621"
},
{
"name": "CVE-2025-68742",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68742"
},
{
"name": "CVE-2025-39908",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39908"
},
{
"name": "CVE-2026-24842",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-24842"
},
{
"name": "CVE-2024-49920",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49920"
},
{
"name": "CVE-2025-40282",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40282"
},
{
"name": "CVE-2026-23118",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23118"
},
{
"name": "CVE-2025-34034",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-34034"
},
{
"name": "CVE-2025-37984",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37984"
},
{
"name": "CVE-2025-59692",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-59692"
},
{
"name": "CVE-2022-50116",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50116"
},
{
"name": "CVE-2018-12931",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-12931"
},
{
"name": "CVE-2025-40168",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40168"
},
{
"name": "CVE-2025-37856",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37856"
},
{
"name": "CVE-2022-50224",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50224"
},
{
"name": "CVE-2025-22874",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22874"
},
{
"name": "CVE-2020-13791",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-13791"
},
{
"name": "CVE-2026-23950",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23950"
},
{
"name": "CVE-2024-49990",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49990"
},
{
"name": "CVE-2020-15802",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-15802"
},
{
"name": "CVE-2020-24240",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-24240"
},
{
"name": "CVE-2024-46718",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46718"
},
{
"name": "CVE-2025-68816",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68816"
},
{
"name": "CVE-2024-41045",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41045"
},
{
"name": "CVE-2023-53545",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53545"
},
{
"name": "CVE-2022-50552",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50552"
},
{
"name": "CVE-2021-0066",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-0066"
},
{
"name": "CVE-2025-38333",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38333"
},
{
"name": "CVE-2023-53376",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53376"
},
{
"name": "CVE-2023-53538",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53538"
},
{
"name": "CVE-2025-68192",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68192"
},
{
"name": "CVE-2024-5569",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-5569"
},
{
"name": "CVE-2025-68379",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68379"
},
{
"name": "CVE-2022-50357",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50357"
},
{
"name": "CVE-2024-57952",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57952"
},
{
"name": "CVE-2025-68256",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68256"
},
{
"name": "CVE-2025-68777",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68777"
},
{
"name": "CVE-2023-52671",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52671"
},
{
"name": "CVE-2022-50303",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50303"
},
{
"name": "CVE-2024-35870",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35870"
},
{
"name": "CVE-2025-68254",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68254"
},
{
"name": "CVE-2026-23221",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23221"
},
{
"name": "CVE-2025-38059",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38059"
},
{
"name": "CVE-2024-27014",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27014"
},
{
"name": "CVE-2024-36013",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36013"
},
{
"name": "CVE-2024-53176",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53176"
},
{
"name": "CVE-2025-37956",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37956"
},
{
"name": "CVE-2025-40196",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40196"
},
{
"name": "CVE-2024-49880",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49880"
},
{
"name": "CVE-2023-52676",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52676"
},
{
"name": "CVE-2025-38117",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38117"
},
{
"name": "CVE-2017-13165",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-13165"
},
{
"name": "CVE-2025-38556",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38556"
},
{
"name": "CVE-2025-68171",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68171"
},
{
"name": "CVE-2025-39932",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39932"
},
{
"name": "CVE-2024-47683",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47683"
},
{
"name": "CVE-2023-6237",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-6237"
},
{
"name": "CVE-2024-46811",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46811"
},
{
"name": "CVE-2025-21985",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21985"
},
{
"name": "CVE-2025-22109",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22109"
},
{
"name": "CVE-2025-38300",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38300"
},
{
"name": "CVE-2025-40040",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40040"
},
{
"name": "CVE-2023-53635",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53635"
},
{
"name": "CVE-2025-39810",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39810"
},
{
"name": "CVE-2026-22982",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22982"
},
{
"name": "CVE-2025-23132",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23132"
},
{
"name": "CVE-2024-47678",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47678"
},
{
"name": "CVE-2022-49531",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49531"
},
{
"name": "CVE-2022-49504",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49504"
},
{
"name": "CVE-2025-1376",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-1376"
},
{
"name": "CVE-2022-49810",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49810"
},
{
"name": "CVE-2025-47912",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-47912"
},
{
"name": "CVE-2025-71109",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71109"
},
{
"name": "CVE-2023-26586",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-26586"
},
{
"name": "CVE-2025-38373",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38373"
},
{
"name": "CVE-2025-66861",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-66861"
},
{
"name": "CVE-2025-40095",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40095"
},
{
"name": "CVE-2025-37957",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37957"
},
{
"name": "CVE-2025-38369",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38369"
},
{
"name": "CVE-2023-43804",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-43804"
},
{
"name": "CVE-2024-44950",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44950"
},
{
"name": "CVE-2025-39759",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39759"
},
{
"name": "CVE-2022-50332",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50332"
},
{
"name": "CVE-2023-53822",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53822"
},
{
"name": "CVE-2024-27408",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27408"
},
{
"name": "CVE-2025-71222",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71222"
},
{
"name": "CVE-2022-50461",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50461"
},
{
"name": "CVE-2025-21801",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21801"
},
{
"name": "CVE-2023-26554",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-26554"
},
{
"name": "CVE-2025-38486",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38486"
},
{
"name": "CVE-2021-26934",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-26934"
},
{
"name": "CVE-2023-53466",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53466"
},
{
"name": "CVE-2025-21629",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21629"
},
{
"name": "CVE-2025-71118",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71118"
},
{
"name": "CVE-2023-53168",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53168"
},
{
"name": "CVE-2022-49528",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49528"
},
{
"name": "CVE-2025-68160",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68160"
},
{
"name": "CVE-2022-45888",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-45888"
},
{
"name": "CVE-2022-49218",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49218"
},
{
"name": "CVE-2023-52749",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52749"
},
{
"name": "CVE-2025-39754",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39754"
},
{
"name": "CVE-2025-40286",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40286"
},
{
"name": "CVE-2022-49967",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49967"
},
{
"name": "CVE-2025-68327",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68327"
},
{
"name": "CVE-2024-2236",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-2236"
},
{
"name": "CVE-2022-49245",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49245"
},
{
"name": "CVE-2025-38098",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38098"
},
{
"name": "CVE-2023-52682",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52682"
},
{
"name": "CVE-2022-50871",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50871"
},
{
"name": "CVE-2025-71150",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71150"
},
{
"name": "CVE-2025-71229",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71229"
},
{
"name": "CVE-2026-23213",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23213"
},
{
"name": "CVE-2025-39958",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39958"
},
{
"name": "CVE-2018-8956",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-8956"
},
{
"name": "CVE-2025-40266",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40266"
},
{
"name": "CVE-2026-23091",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23091"
},
{
"name": "CVE-2025-68241",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68241"
},
{
"name": "CVE-2022-49420",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49420"
},
{
"name": "CVE-2022-40964",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-40964"
},
{
"name": "CVE-2025-69873",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-69873"
},
{
"name": "CVE-2026-3441",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-3441"
},
{
"name": "CVE-2024-36244",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36244"
},
{
"name": "CVE-2023-53149",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53149"
},
{
"name": "CVE-2026-23237",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23237"
},
{
"name": "CVE-2024-49987",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49987"
},
{
"name": "CVE-2025-60753",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-60753"
},
{
"name": "CVE-2022-50746",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50746"
},
{
"name": "CVE-2025-52565",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-52565"
},
{
"name": "CVE-2024-50034",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50034"
},
{
"name": "CVE-2025-38259",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38259"
},
{
"name": "CVE-2025-71192",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71192"
},
{
"name": "CVE-2023-53596",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53596"
},
{
"name": "CVE-2022-49943",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49943"
},
{
"name": "CVE-2022-50260",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50260"
},
{
"name": "CVE-2025-40135",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40135"
},
{
"name": "CVE-2025-67735",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-67735"
},
{
"name": "CVE-2026-23121",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23121"
},
{
"name": "CVE-2020-12319",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-12319"
},
{
"name": "CVE-2025-37951",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37951"
},
{
"name": "CVE-2023-50495",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-50495"
},
{
"name": "CVE-2024-49568",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49568"
},
{
"name": "CVE-2025-21750",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21750"
},
{
"name": "CVE-2024-36924",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36924"
},
{
"name": "CVE-2017-11164",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-11164"
},
{
"name": "CVE-2023-3397",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-3397"
},
{
"name": "CVE-2025-68734",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68734"
},
{
"name": "CVE-2024-26672",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26672"
},
{
"name": "CVE-2024-57924",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57924"
},
{
"name": "CVE-2025-37947",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37947"
},
{
"name": "CVE-2025-68776",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68776"
},
{
"name": "CVE-2025-61728",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-61728"
},
{
"name": "CVE-2025-71066",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71066"
},
{
"name": "CVE-2026-0965",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-0965"
},
{
"name": "CVE-2023-53806",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53806"
},
{
"name": "CVE-2025-21817",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21817"
},
{
"name": "CVE-2025-68972",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68972"
},
{
"name": "CVE-2025-68799",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68799"
},
{
"name": "CVE-2021-33139",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-33139"
},
{
"name": "CVE-2025-58186",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-58186"
},
{
"name": "CVE-2025-21825",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21825"
},
{
"name": "CVE-2025-38192",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38192"
},
{
"name": "CVE-2025-71236",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71236"
},
{
"name": "CVE-2025-68345",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68345"
},
{
"name": "CVE-2025-39800",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39800"
},
{
"name": "CVE-2024-50057",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50057"
},
{
"name": "CVE-2025-38343",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38343"
},
{
"name": "CVE-2025-71097",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71097"
},
{
"name": "CVE-2024-46808",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46808"
},
{
"name": "CVE-2026-26158",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-26158"
},
{
"name": "CVE-2025-38202",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38202"
},
{
"name": "CVE-2025-68288",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68288"
},
{
"name": "CVE-2025-38168",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38168"
},
{
"name": "CVE-2023-53547",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53547"
},
{
"name": "CVE-2019-20426",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-20426"
},
{
"name": "CVE-2025-71107",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71107"
},
{
"name": "CVE-2024-0727",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-0727"
},
{
"name": "CVE-2025-40310",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40310"
},
{
"name": "CVE-2026-29786",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-29786"
},
{
"name": "CVE-2025-58187",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-58187"
},
{
"name": "CVE-2025-40083",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40083"
},
{
"name": "CVE-2023-6129",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-6129"
},
{
"name": "CVE-2024-56584",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56584"
},
{
"name": "CVE-2026-23235",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23235"
},
{
"name": "CVE-2025-71111",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71111"
},
{
"name": "CVE-2022-4899",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-4899"
},
{
"name": "CVE-2025-71152",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71152"
},
{
"name": "CVE-2024-42139",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42139"
},
{
"name": "CVE-2024-56692",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56692"
},
{
"name": "CVE-2024-53196",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53196"
},
{
"name": "CVE-2025-38665",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38665"
},
{
"name": "CVE-2022-50212",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50212"
},
{
"name": "CVE-2026-23087",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23087"
},
{
"name": "CVE-2023-54259",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54259"
},
{
"name": "CVE-2025-68802",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68802"
},
{
"name": "CVE-2023-54067",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54067"
},
{
"name": "CVE-2025-1369",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-1369"
},
{
"name": "CVE-2022-3219",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-3219"
},
{
"name": "CVE-2025-68317",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68317"
},
{
"name": "CVE-2023-53231",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53231"
},
{
"name": "CVE-2025-71185",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71185"
},
{
"name": "CVE-2022-2961",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-2961"
},
{
"name": "CVE-2025-40331",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40331"
},
{
"name": "CVE-2025-4673",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-4673"
},
{
"name": "CVE-2022-49635",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49635"
},
{
"name": "CVE-2024-50017",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50017"
},
{
"name": "CVE-2026-23096",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23096"
},
{
"name": "CVE-2024-53241",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53241"
},
{
"name": "CVE-2025-14180",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-14180"
},
{
"name": "CVE-2026-23949",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23949"
},
{
"name": "CVE-2025-38704",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38704"
},
{
"name": "CVE-2023-34969",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-34969"
},
{
"name": "CVE-2021-33155",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-33155"
},
{
"name": "CVE-2025-68337",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68337"
},
{
"name": "CVE-2024-57899",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57899"
},
{
"name": "CVE-2024-49928",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49928"
},
{
"name": "CVE-2025-21885",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21885"
},
{
"name": "CVE-2024-50187",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50187"
},
{
"name": "CVE-2022-50851",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50851"
},
{
"name": "CVE-2025-36001",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-36001"
},
{
"name": "CVE-2022-50464",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50464"
},
{
"name": "CVE-2025-38674",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38674"
},
{
"name": "CVE-2025-40093",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40093"
},
{
"name": "CVE-2020-26560",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-26560"
},
{
"name": "CVE-2024-26714",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26714"
},
{
"name": "CVE-2024-45777",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45777"
},
{
"name": "CVE-2025-38040",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38040"
},
{
"name": "CVE-2024-40954",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40954"
},
{
"name": "CVE-2022-49965",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49965"
},
{
"name": "CVE-2025-54771",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-54771"
},
{
"name": "CVE-2024-0564",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-0564"
},
{
"name": "CVE-2025-39825",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39825"
},
{
"name": "CVE-2025-71131",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71131"
},
{
"name": "CVE-2022-49961",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49961"
},
{
"name": "CVE-2025-69651",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-69651"
},
{
"name": "CVE-2025-38552",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38552"
},
{
"name": "CVE-2025-40335",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40335"
},
{
"name": "CVE-2025-40149",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40149"
},
{
"name": "CVE-2024-58098",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58098"
},
{
"name": "CVE-2025-22871",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22871"
},
{
"name": "CVE-2022-28667",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-28667"
},
{
"name": "CVE-2023-53383",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53383"
},
{
"name": "CVE-2024-46717",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46717"
},
{
"name": "CVE-2024-25743",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-25743"
},
{
"name": "CVE-2022-50704",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50704"
},
{
"name": "CVE-2025-40164",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40164"
},
{
"name": "CVE-2023-54125",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54125"
},
{
"name": "CVE-2025-10911",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-10911"
},
{
"name": "CVE-2026-23164",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23164"
},
{
"name": "CVE-2024-41036",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41036"
},
{
"name": "CVE-2023-53751",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53751"
},
{
"name": "CVE-2025-0033",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-0033"
},
{
"name": "CVE-2023-53743",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53743"
},
{
"name": "CVE-2024-42319",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42319"
},
{
"name": "CVE-2025-37928",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37928"
},
{
"name": "CVE-2017-13716",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-13716"
},
{
"name": "CVE-2024-22018",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-22018"
},
{
"name": "CVE-2025-71116",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71116"
},
{
"name": "CVE-2022-40735",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-40735"
},
{
"name": "CVE-2024-36024",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36024"
},
{
"name": "CVE-2025-21723",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21723"
},
{
"name": "CVE-2023-54190",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54190"
},
{
"name": "CVE-2023-52879",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52879"
},
{
"name": "CVE-2025-68281",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68281"
},
{
"name": "CVE-2023-52837",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52837"
},
{
"name": "CVE-2025-38440",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38440"
},
{
"name": "CVE-2026-23124",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23124"
},
{
"name": "CVE-2023-52981",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52981"
},
{
"name": "CVE-2024-53224",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53224"
},
{
"name": "CVE-2024-49910",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49910"
},
{
"name": "CVE-2025-68362",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68362"
},
{
"name": "CVE-2023-53105",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53105"
},
{
"name": "CVE-2025-68236",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68236"
},
{
"name": "CVE-2024-39286",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39286"
},
{
"name": "CVE-2025-25184",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-25184"
},
{
"name": "CVE-2025-14524",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-14524"
},
{
"name": "CVE-2024-49855",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49855"
},
{
"name": "CVE-2024-47081",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47081"
},
{
"name": "CVE-2025-68333",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68333"
},
{
"name": "CVE-2024-47689",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47689"
},
{
"name": "CVE-2025-71160",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71160"
},
{
"name": "CVE-2025-71232",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71232"
},
{
"name": "CVE-2023-52625",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52625"
},
{
"name": "CVE-2023-53353",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53353"
},
{
"name": "CVE-2024-58096",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58096"
},
{
"name": "CVE-2025-38225",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38225"
},
{
"name": "CVE-2023-53401",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53401"
},
{
"name": "CVE-2025-22037",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22037"
},
{
"name": "CVE-2023-53702",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53702"
},
{
"name": "CVE-2025-68290",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68290"
},
{
"name": "CVE-2025-40280",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40280"
},
{
"name": "CVE-2024-26842",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26842"
},
{
"name": "CVE-2025-40099",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40099"
},
{
"name": "CVE-2023-54059",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54059"
},
{
"name": "CVE-2025-71162",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71162"
},
{
"name": "CVE-2021-0170",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-0170"
},
{
"name": "CVE-2019-10782",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-10782"
},
{
"name": "CVE-2024-40966",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40966"
},
{
"name": "CVE-2024-53133",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53133"
},
{
"name": "CVE-2026-23075",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23075"
},
{
"name": "CVE-2022-50571",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50571"
},
{
"name": "CVE-2021-31879",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-31879"
},
{
"name": "CVE-2026-23120",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23120"
},
{
"name": "CVE-2025-40180",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40180"
},
{
"name": "CVE-2022-49393",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49393"
},
{
"name": "CVE-2024-6119",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-6119"
},
{
"name": "CVE-2025-68803",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68803"
},
{
"name": "CVE-2026-22996",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22996"
},
{
"name": "CVE-2024-53091",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53091"
},
{
"name": "CVE-2025-39851",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39851"
},
{
"name": "CVE-2025-71204",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71204"
},
{
"name": "CVE-2025-68331",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68331"
},
{
"name": "CVE-2025-38244",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38244"
},
{
"name": "CVE-2022-29217",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-29217"
},
{
"name": "CVE-2024-26758",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26758"
},
{
"name": "CVE-2025-38080",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38080"
},
{
"name": "CVE-2023-32651",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-32651"
},
{
"name": "CVE-2025-37747",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37747"
},
{
"name": "CVE-2026-2297",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-2297"
},
{
"name": "CVE-2026-23105",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23105"
},
{
"name": "CVE-2023-53036",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53036"
},
{
"name": "CVE-2025-38615",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38615"
},
{
"name": "CVE-2025-58181",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-58181"
},
{
"name": "CVE-2025-71115",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71115"
},
{
"name": "CVE-2026-22976",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22976"
},
{
"name": "CVE-2022-50862",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50862"
},
{
"name": "CVE-2025-1118",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-1118"
},
{
"name": "CVE-2024-50166",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50166"
},
{
"name": "CVE-2024-35862",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35862"
},
{
"name": "CVE-2023-53355",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53355"
},
{
"name": "CVE-2022-25265",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-25265"
},
{
"name": "CVE-2026-0967",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-0967"
},
{
"name": "CVE-2026-23181",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23181"
},
{
"name": "CVE-2025-37944",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37944"
},
{
"name": "CVE-2023-53558",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53558"
},
{
"name": "CVE-2025-47914",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-47914"
},
{
"name": "CVE-2025-68214",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68214"
},
{
"name": "CVE-2025-38703",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38703"
},
{
"name": "CVE-2026-23141",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23141"
},
{
"name": "CVE-2026-22860",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22860"
},
{
"name": "CVE-2025-36365",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-36365"
},
{
"name": "CVE-2025-9403",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-9403"
},
{
"name": "CVE-2025-40247",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40247"
},
{
"name": "CVE-2023-1255",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-1255"
},
{
"name": "CVE-2024-56641",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56641"
},
{
"name": "CVE-2024-43842",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43842"
},
{
"name": "CVE-2025-0686",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-0686"
},
{
"name": "CVE-2025-21739",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21739"
},
{
"name": "CVE-2024-49992",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49992"
},
{
"name": "CVE-2025-68781",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68781"
},
{
"name": "CVE-2025-39753",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39753"
},
{
"name": "CVE-2025-69418",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-69418"
},
{
"name": "CVE-2026-23182",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23182"
},
{
"name": "CVE-2021-0173",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-0173"
},
{
"name": "CVE-2025-71112",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71112"
},
{
"name": "CVE-2023-54285",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54285"
},
{
"name": "CVE-2024-45778",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45778"
},
{
"name": "CVE-2026-23086",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23086"
},
{
"name": "CVE-2024-47661",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47661"
},
{
"name": "CVE-2026-28418",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-28418"
},
{
"name": "CVE-2023-54151",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54151"
},
{
"name": "CVE-2025-22022",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22022"
},
{
"name": "CVE-2025-66864",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-66864"
},
{
"name": "CVE-2024-46803",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46803"
},
{
"name": "CVE-2025-22869",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22869"
},
{
"name": "CVE-2025-59466",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-59466"
},
{
"name": "CVE-2025-40192",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40192"
},
{
"name": "CVE-2025-38544",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38544"
},
{
"name": "CVE-2025-39797",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39797"
},
{
"name": "CVE-2025-68818",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68818"
},
{
"name": "CVE-2022-36351",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-36351"
},
{
"name": "CVE-2023-52921",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52921"
},
{
"name": "CVE-2025-15468",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-15468"
},
{
"name": "CVE-2024-36478",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36478"
},
{
"name": "CVE-2024-43832",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43832"
},
{
"name": "CVE-2026-25639",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-25639"
},
{
"name": "CVE-2026-1299",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-1299"
},
{
"name": "CVE-2024-54683",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-54683"
},
{
"name": "CVE-2025-1150",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-1150"
},
{
"name": "CVE-2024-46720",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46720"
},
{
"name": "CVE-2024-26658",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26658"
},
{
"name": "CVE-2026-2243",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-2243"
},
{
"name": "CVE-2025-38198",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38198"
},
{
"name": "CVE-2025-58189",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-58189"
},
{
"name": "CVE-2022-36087",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-36087"
},
{
"name": "CVE-2024-38564",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38564"
},
{
"name": "CVE-2021-0174",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-0174"
},
{
"name": "CVE-2025-8746",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-8746"
},
{
"name": "CVE-2025-36442",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-36442"
},
{
"name": "CVE-2025-38006",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38006"
},
{
"name": "CVE-2025-40102",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40102"
},
{
"name": "CVE-2026-0968",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-0968"
},
{
"name": "CVE-2025-40170",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40170"
},
{
"name": "CVE-2025-38437",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38437"
},
{
"name": "CVE-2025-40160",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40160"
},
{
"name": "CVE-2023-7008",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-7008"
},
{
"name": "CVE-2024-45779",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45779"
},
{
"name": "CVE-2025-40284",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40284"
},
{
"name": "CVE-2025-38125",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38125"
},
{
"name": "CVE-2025-40077",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40077"
},
{
"name": "CVE-2024-57857",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57857"
},
{
"name": "CVE-2024-4603",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-4603"
},
{
"name": "CVE-2022-50213",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50213"
},
{
"name": "CVE-2024-46823",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46823"
},
{
"name": "CVE-2023-32642",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-32642"
},
{
"name": "CVE-2025-71227",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71227"
},
{
"name": "CVE-2025-61772",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-61772"
},
{
"name": "CVE-2024-46733",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46733"
},
{
"name": "CVE-2024-41014",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41014"
},
{
"name": "CVE-2022-50015",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50015"
},
{
"name": "CVE-2025-40071",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40071"
},
{
"name": "CVE-2024-7883",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-7883"
},
{
"name": "CVE-2024-50271",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50271"
},
{
"name": "CVE-2022-50772",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50772"
},
{
"name": "CVE-2024-56717",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56717"
},
{
"name": "CVE-2025-68366",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68366"
},
{
"name": "CVE-2024-56707",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56707"
},
{
"name": "CVE-2023-54234",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54234"
},
{
"name": "CVE-2022-45885",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-45885"
},
{
"name": "CVE-2022-49783",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49783"
},
{
"name": "CVE-2025-40305",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40305"
},
{
"name": "CVE-2016-2781",
"url": "https://www.cve.org/CVERecord?id=CVE-2016-2781"
},
{
"name": "CVE-2023-29383",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-29383"
},
{
"name": "CVE-2025-47153",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-47153"
},
{
"name": "CVE-2025-40080",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40080"
},
{
"name": "CVE-2024-53216",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53216"
},
{
"name": "CVE-2022-49539",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49539"
},
{
"name": "CVE-2024-36347",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36347"
},
{
"name": "CVE-2024-26869",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26869"
},
{
"name": "CVE-2025-22870",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22870"
},
{
"name": "CVE-2025-68815",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68815"
},
{
"name": "CVE-2021-20255",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-20255"
},
{
"name": "CVE-2022-48979",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48979"
},
{
"name": "CVE-2025-40307",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40307"
},
{
"name": "CVE-2025-71193",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71193"
},
{
"name": "CVE-2023-54180",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54180"
},
{
"name": "CVE-2026-23095",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23095"
},
{
"name": "CVE-2024-46848",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46848"
},
{
"name": "CVE-2025-68346",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68346"
},
{
"name": "CVE-2025-38081",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38081"
},
{
"name": "CVE-2024-36009",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36009"
},
{
"name": "CVE-2025-71163",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71163"
},
{
"name": "CVE-2024-36350",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36350"
},
{
"name": "CVE-2023-25951",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-25951"
},
{
"name": "CVE-2025-40211",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40211"
},
{
"name": "CVE-2023-53152",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53152"
},
{
"name": "CVE-2021-0308",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-0308"
},
{
"name": "CVE-2025-68315",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68315"
},
{
"name": "CVE-2024-50009",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50009"
},
{
"name": "CVE-2025-39850",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39850"
},
{
"name": "CVE-2022-1205",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-1205"
},
{
"name": "CVE-2023-45927",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-45927"
},
{
"name": "CVE-2020-25742",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-25742"
},
{
"name": "CVE-2022-0987",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-0987"
},
{
"name": "CVE-2025-71096",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71096"
},
{
"name": "CVE-2025-71095",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71095"
},
{
"name": "CVE-2025-40217",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40217"
},
{
"name": "CVE-2025-38199",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38199"
},
{
"name": "CVE-2025-39905",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39905"
},
{
"name": "CVE-2025-21944",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21944"
},
{
"name": "CVE-2022-50720",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50720"
},
{
"name": "CVE-2025-71105",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71105"
},
{
"name": "CVE-2023-50387",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-50387"
},
{
"name": "CVE-2022-49529",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49529"
},
{
"name": "CVE-2025-68266",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68266"
},
{
"name": "CVE-2024-27057",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27057"
},
{
"name": "CVE-2025-68771",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68771"
},
{
"name": "CVE-2025-39961",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39961"
},
{
"name": "CVE-2025-68363",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68363"
},
{
"name": "CVE-2024-54456",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-54456"
},
{
"name": "CVE-2024-26876",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26876"
},
{
"name": "CVE-2025-40248",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40248"
},
{
"name": "CVE-2023-52657",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52657"
},
{
"name": "CVE-2025-37876",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37876"
},
{
"name": "CVE-2024-58089",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58089"
},
{
"name": "CVE-2024-36331",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36331"
},
{
"name": "CVE-2026-27571",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-27571"
},
{
"name": "CVE-2025-39748",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39748"
},
{
"name": "CVE-2026-22984",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22984"
},
{
"name": "CVE-2026-27139",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-27139"
},
{
"name": "CVE-2022-49127",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49127"
},
{
"name": "CVE-2026-24733",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-24733"
},
{
"name": "CVE-2020-25741",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-25741"
},
{
"name": "CVE-2022-50748",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50748"
},
{
"name": "CVE-2023-53767",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53767"
},
{
"name": "CVE-2025-21667",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21667"
},
{
"name": "CVE-2025-9230",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-9230"
},
{
"name": "CVE-2023-49083",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-49083"
},
{
"name": "CVE-2025-21696",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21696"
},
{
"name": "CVE-2025-68303",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68303"
},
{
"name": "CVE-2025-21955",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21955"
},
{
"name": "CVE-2025-39863",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39863"
},
{
"name": "CVE-2025-40259",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40259"
},
{
"name": "CVE-2023-53180",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53180"
},
{
"name": "CVE-2026-28419",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-28419"
},
{
"name": "CVE-2025-8677",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-8677"
},
{
"name": "CVE-2025-38560",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38560"
},
{
"name": "CVE-2023-53385",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53385"
},
{
"name": "CVE-2026-23206",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23206"
},
{
"name": "CVE-2025-68757",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68757"
},
{
"name": "CVE-2024-46678",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46678"
},
{
"name": "CVE-2024-58097",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58097"
},
{
"name": "CVE-2023-53620",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53620"
},
{
"name": "CVE-2022-50539",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50539"
},
{
"name": "CVE-2025-71068",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71068"
},
{
"name": "CVE-2025-23130",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23130"
},
{
"name": "CVE-2022-49496",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49496"
},
{
"name": "CVE-2025-38349",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38349"
},
{
"name": "CVE-2024-56782",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56782"
},
{
"name": "CVE-2025-39957",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39957"
},
{
"name": "CVE-2025-1352",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-1352"
},
{
"name": "CVE-2023-53540",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53540"
},
{
"name": "CVE-2022-49552",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49552"
},
{
"name": "CVE-2024-4741",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-4741"
},
{
"name": "CVE-2023-53261",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53261"
},
{
"name": "CVE-2026-24049",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-24049"
},
{
"name": "CVE-2026-23033",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23033"
},
{
"name": "CVE-2025-39726",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39726"
},
{
"name": "CVE-2024-26759",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26759"
},
{
"name": "CVE-2025-48924",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-48924"
},
{
"name": "CVE-2025-39931",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39931"
},
{
"name": "CVE-2023-54187",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54187"
},
{
"name": "CVE-2026-22977",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22977"
},
{
"name": "CVE-2026-23145",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23145"
},
{
"name": "CVE-2022-44032",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-44032"
},
{
"name": "CVE-2024-57895",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57895"
},
{
"name": "CVE-2023-53240",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53240"
},
{
"name": "CVE-2025-13735",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-13735"
},
{
"name": "CVE-2023-53694",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53694"
},
{
"name": "CVE-2024-53195",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53195"
},
{
"name": "CVE-2024-35794",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35794"
},
{
"name": "CVE-2023-52829",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52829"
},
{
"name": "CVE-2026-23003",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23003"
},
{
"name": "CVE-2025-21891",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21891"
},
{
"name": "CVE-2025-38716",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38716"
},
{
"name": "CVE-2025-11187",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-11187"
},
{
"name": "CVE-2024-56660",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56660"
},
{
"name": "CVE-2026-23076",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23076"
},
{
"name": "CVE-2023-54145",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54145"
},
{
"name": "CVE-2025-38033",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38033"
},
{
"name": "CVE-2024-41023",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41023"
},
{
"name": "CVE-2024-47704",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47704"
},
{
"name": "CVE-2025-21672",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21672"
},
{
"name": "CVE-2024-35801",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35801"
},
{
"name": "CVE-2024-49978",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49978"
},
{
"name": "CVE-2024-36910",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36910"
},
{
"name": "CVE-2025-15079",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-15079"
},
{
"name": "CVE-2024-49870",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49870"
},
{
"name": "CVE-2025-36366",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-36366"
},
{
"name": "CVE-2024-42125",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42125"
},
{
"name": "CVE-2025-36123",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-36123"
},
{
"name": "CVE-2024-56737",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56737"
},
{
"name": "CVE-2025-68168",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68168"
},
{
"name": "CVE-2025-21821",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21821"
},
{
"name": "CVE-2025-68206",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68206"
},
{
"name": "CVE-2020-11935",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-11935"
},
{
"name": "CVE-2023-54247",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54247"
},
{
"name": "CVE-2025-68309",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68309"
},
{
"name": "CVE-2023-52905",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52905"
},
{
"name": "CVE-2024-57852",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57852"
},
{
"name": "CVE-2025-40003",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40003"
},
{
"name": "CVE-2025-22042",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22042"
},
{
"name": "CVE-2025-71158",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71158"
},
{
"name": "CVE-2022-49803",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49803"
},
{
"name": "CVE-2024-57898",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57898"
},
{
"name": "CVE-2020-35503",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-35503"
},
{
"name": "CVE-2024-49923",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49923"
},
{
"name": "CVE-2024-56639",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56639"
},
{
"name": "CVE-2025-68372",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68372"
},
{
"name": "CVE-2026-23171",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23171"
},
{
"name": "CVE-2024-3651",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-3651"
},
{
"name": "CVE-2023-53002",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53002"
},
{
"name": "CVE-2021-0183",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-0183"
},
{
"name": "CVE-2025-39884",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39884"
},
{
"name": "CVE-2025-39747",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39747"
},
{
"name": "CVE-2024-36914",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36914"
},
{
"name": "CVE-2026-26996",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-26996"
},
{
"name": "CVE-2024-35826",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35826"
},
{
"name": "CVE-2026-23112",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23112"
},
{
"name": "CVE-2022-49764",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49764"
},
{
"name": "CVE-2025-68121",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68121"
},
{
"name": "CVE-2025-21651",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21651"
},
{
"name": "CVE-2025-38092",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38092"
},
{
"name": "CVE-2025-22124",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22124"
},
{
"name": "CVE-2025-68313",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68313"
},
{
"name": "CVE-2024-58053",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58053"
},
{
"name": "CVE-2023-26553",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-26553"
},
{
"name": "CVE-2025-60876",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-60876"
},
{
"name": "CVE-2025-37776",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37776"
},
{
"name": "CVE-2021-23840",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-23840"
},
{
"name": "CVE-2024-58077",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58077"
},
{
"name": "CVE-2024-6519",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-6519"
},
{
"name": "CVE-2024-46729",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46729"
},
{
"name": "CVE-2023-53850",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53850"
},
{
"name": "CVE-2023-2975",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-2975"
},
{
"name": "CVE-2022-50266",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50266"
},
{
"name": "CVE-2024-53178",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53178"
},
{
"name": "CVE-2025-71137",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71137"
},
{
"name": "CVE-2026-23084",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23084"
},
{
"name": "CVE-2023-53093",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53093"
},
{
"name": "CVE-2025-11065",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-11065"
},
{
"name": "CVE-2026-23190",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23190"
},
{
"name": "CVE-2025-40123",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40123"
},
{
"name": "CVE-2026-22979",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22979"
},
{
"name": "CVE-2025-68301",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68301"
},
{
"name": "CVE-2024-49991",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49991"
},
{
"name": "CVE-2022-50009",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50009"
},
{
"name": "CVE-2022-26047",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-26047"
},
{
"name": "CVE-2024-53240",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53240"
},
{
"name": "CVE-2026-23011",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23011"
},
{
"name": "CVE-2024-36949",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36949"
},
{
"name": "CVE-2023-53816",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53816"
},
{
"name": "CVE-2025-37877",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37877"
},
{
"name": "CVE-2024-2193",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-2193"
},
{
"name": "CVE-2025-4382",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-4382"
},
{
"name": "CVE-2022-28693",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-28693"
},
{
"name": "CVE-2025-71161",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71161"
},
{
"name": "CVE-2025-39706",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39706"
},
{
"name": "CVE-2025-22038",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22038"
},
{
"name": "CVE-2025-68217",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68217"
},
{
"name": "CVE-2023-54242",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54242"
},
{
"name": "CVE-2025-68289",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68289"
},
{
"name": "CVE-2025-40363",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40363"
},
{
"name": "CVE-2024-41062",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41062"
},
{
"name": "CVE-2025-40253",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40253"
},
{
"name": "CVE-2022-48816",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48816"
},
{
"name": "CVE-2026-27141",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-27141"
},
{
"name": "CVE-2025-37800",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37800"
},
{
"name": "CVE-2025-61726",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-61726"
},
{
"name": "CVE-2022-50518",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50518"
},
{
"name": "CVE-2022-49829",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49829"
},
{
"name": "CVE-2025-64756",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-64756"
},
{
"name": "CVE-2025-21967",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21967"
},
{
"name": "CVE-2016-2568",
"url": "https://www.cve.org/CVERecord?id=CVE-2016-2568"
},
{
"name": "CVE-2020-13817",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-13817"
},
{
"name": "CVE-2025-68245",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68245"
},
{
"name": "CVE-2025-41254",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-41254"
},
{
"name": "CVE-2018-12929",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-12929"
},
{
"name": "CVE-2024-26853",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26853"
},
{
"name": "CVE-2024-53147",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53147"
},
{
"name": "CVE-2025-39952",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39952"
},
{
"name": "CVE-2025-40317",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40317"
},
{
"name": "CVE-2024-45783",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45783"
},
{
"name": "CVE-2026-23110",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23110"
},
{
"name": "CVE-2023-53410",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53410"
},
{
"name": "CVE-2023-53254",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53254"
},
{
"name": "CVE-2024-34064",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-34064"
},
{
"name": "CVE-2023-47210",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-47210"
},
{
"name": "CVE-2025-68809",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68809"
},
{
"name": "CVE-2025-53864",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-53864"
},
{
"name": "CVE-2024-36920",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36920"
},
{
"name": "CVE-2021-0165",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-0165"
},
{
"name": "CVE-2025-0624",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-0624"
},
{
"name": "CVE-2022-49177",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49177"
},
{
"name": "CVE-2025-38205",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38205"
},
{
"name": "CVE-2026-23100",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23100"
},
{
"name": "CVE-2025-59464",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-59464"
},
{
"name": "CVE-2024-58241",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58241"
},
{
"name": "CVE-2025-21863",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21863"
},
{
"name": "CVE-2025-71120",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71120"
},
{
"name": "CVE-2025-38166",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38166"
},
{
"name": "CVE-2022-49833",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49833"
},
{
"name": "CVE-2026-23060",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23060"
},
{
"name": "CVE-2025-38321",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38321"
},
{
"name": "CVE-2025-68282",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68282"
},
{
"name": "CVE-2025-39705",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39705"
},
{
"name": "CVE-2025-68817",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68817"
},
{
"name": "CVE-2024-36021",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36021"
},
{
"name": "CVE-2025-38045",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38045"
},
{
"name": "CVE-2024-46726",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46726"
},
{
"name": "CVE-2025-40025",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40025"
},
{
"name": "CVE-2024-53079",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53079"
},
{
"name": "CVE-2025-68787",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68787"
},
{
"name": "CVE-2025-1125",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-1125"
},
{
"name": "CVE-2023-53647",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53647"
},
{
"name": "CVE-2025-37954",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37954"
},
{
"name": "CVE-2025-23133",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23133"
},
{
"name": "CVE-2025-0012",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-0012"
},
{
"name": "CVE-2020-12313",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-12313"
},
{
"name": "CVE-2025-71233",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71233"
},
{
"name": "CVE-2025-68782",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68782"
},
{
"name": "CVE-2021-0166",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-0166"
},
{
"name": "CVE-2025-21945",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21945"
},
{
"name": "CVE-2022-3872",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-3872"
},
{
"name": "CVE-2025-39744",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39744"
},
{
"name": "CVE-2025-71197",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71197"
},
{
"name": "CVE-2025-68177",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68177"
},
{
"name": "CVE-2025-68758",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68758"
},
{
"name": "CVE-2024-49931",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49931"
},
{
"name": "CVE-2024-43866",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43866"
},
{
"name": "CVE-2024-37021",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-37021"
},
{
"name": "CVE-2024-47728",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47728"
},
{
"name": "CVE-2025-27610",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-27610"
},
{
"name": "CVE-2025-68191",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68191"
},
{
"name": "CVE-2026-23031",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23031"
},
{
"name": "CVE-2024-46730",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46730"
},
{
"name": "CVE-2025-71113",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71113"
},
{
"name": "CVE-2025-71127",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71127"
},
{
"name": "CVE-2025-37786",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37786"
},
{
"name": "CVE-2024-46728",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46728"
},
{
"name": "CVE-2023-53561",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53561"
},
{
"name": "CVE-2026-22998",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22998"
},
{
"name": "CVE-2023-54172",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54172"
},
{
"name": "CVE-2026-23050",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23050"
},
{
"name": "CVE-2024-58100",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58100"
},
{
"name": "CVE-2020-0256",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-0256"
},
{
"name": "CVE-2025-21673",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21673"
},
{
"name": "CVE-2024-26954",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26954"
},
{
"name": "CVE-2025-21634",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21634"
},
{
"name": "CVE-2024-57999",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57999"
},
{
"name": "CVE-2025-38047",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38047"
},
{
"name": "CVE-2024-47738",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47738"
},
{
"name": "CVE-2025-68340",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68340"
},
{
"name": "CVE-2024-41013",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41013"
},
{
"name": "CVE-2023-54320",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54320"
},
{
"name": "CVE-2024-43911",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43911"
},
{
"name": "CVE-2025-30204",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-30204"
},
{
"name": "CVE-2025-37959",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37959"
},
{
"name": "CVE-2017-0537",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-0537"
},
{
"name": "CVE-2025-38191",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38191"
},
{
"name": "CVE-2023-32681",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-32681"
},
{
"name": "CVE-2025-68219",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68219"
},
{
"name": "CVE-2022-50232",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50232"
},
{
"name": "CVE-2025-38062",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38062"
},
{
"name": "CVE-2025-38531",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38531"
},
{
"name": "CVE-2023-26112",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-26112"
},
{
"name": "CVE-2018-6952",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-6952"
},
{
"name": "CVE-2020-14304",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-14304"
},
{
"name": "CVE-2024-46834",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46834"
},
{
"name": "CVE-2025-40288",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40288"
},
{
"name": "CVE-2025-68239",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68239"
},
{
"name": "CVE-2025-40258",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40258"
},
{
"name": "CVE-2025-21894",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21894"
},
{
"name": "CVE-2025-40281",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40281"
},
{
"name": "CVE-2025-68185",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68185"
},
{
"name": "CVE-2025-40304",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40304"
},
{
"name": "CVE-2025-38503",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38503"
},
{
"name": "CVE-2025-40110",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40110"
},
{
"name": "CVE-2026-24001",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-24001"
},
{
"name": "CVE-2025-37807",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37807"
},
{
"name": "CVE-2025-38131",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38131"
},
{
"name": "CVE-2022-50016",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50016"
},
{
"name": "CVE-2025-29481",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-29481"
},
{
"name": "CVE-2024-53219",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53219"
},
{
"name": "CVE-2023-53009",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53009"
},
{
"name": "CVE-2025-40268",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40268"
},
{
"name": "CVE-2025-61661",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-61661"
},
{
"name": "CVE-2026-23111",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23111"
},
{
"name": "CVE-2024-25740",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-25740"
},
{
"name": "CVE-2024-50246",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50246"
},
{
"name": "CVE-2023-3446",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-3446"
},
{
"name": "CVE-2025-14178",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-14178"
},
{
"name": "CVE-2024-57950",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57950"
},
{
"name": "CVE-2025-21759",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21759"
},
{
"name": "CVE-2025-40325",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40325"
},
{
"name": "CVE-2024-2511",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-2511"
},
{
"name": "CVE-2024-42321",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42321"
},
{
"name": "CVE-2026-23113",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23113"
},
{
"name": "CVE-2021-0176",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-0176"
},
{
"name": "CVE-2025-1151",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-1151"
},
{
"name": "CVE-2022-48998",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48998"
},
{
"name": "CVE-2025-68798",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68798"
},
{
"name": "CVE-2024-42273",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42273"
},
{
"name": "CVE-2025-68336",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68336"
},
{
"name": "CVE-2023-53794",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53794"
},
{
"name": "CVE-2026-23157",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23157"
},
{
"name": "CVE-2025-40303",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40303"
},
{
"name": "CVE-2025-68178",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68178"
},
{
"name": "CVE-2022-49974",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49974"
},
{
"name": "CVE-2025-40337",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40337"
},
{
"name": "CVE-2019-20633",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-20633"
},
{
"name": "CVE-2025-38264",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38264"
},
{
"name": "CVE-2021-3714",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-3714"
},
{
"name": "CVE-2023-54071",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54071"
},
{
"name": "CVE-2024-56566",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56566"
},
{
"name": "CVE-2025-46392",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-46392"
},
{
"name": "CVE-2025-40036",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40036"
},
{
"name": "CVE-2024-57993",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57993"
},
{
"name": "CVE-2024-47745",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47745"
},
{
"name": "CVE-2025-39833",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39833"
},
{
"name": "CVE-2026-23097",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23097"
},
{
"name": "CVE-2025-37980",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37980"
},
{
"name": "CVE-2024-53190",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53190"
},
{
"name": "CVE-2025-40262",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40262"
},
{
"name": "CVE-2024-35784",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35784"
},
{
"name": "CVE-2024-56591",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56591"
},
{
"name": "CVE-2024-56544",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56544"
},
{
"name": "CVE-2024-56647",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56647"
},
{
"name": "CVE-2025-71198",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71198"
},
{
"name": "CVE-2025-21649",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21649"
},
{
"name": "CVE-2024-57976",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57976"
},
{
"name": "CVE-2025-68819",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68819"
},
{
"name": "CVE-2025-0685",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-0685"
},
{
"name": "CVE-2024-57893",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57893"
},
{
"name": "CVE-2026-23231",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23231"
},
{
"name": "CVE-2025-37879",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37879"
},
{
"name": "CVE-2022-50071",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50071"
},
{
"name": "CVE-2025-40261",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40261"
},
{
"name": "CVE-2024-56180",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56180"
},
{
"name": "CVE-2023-39333",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-39333"
},
{
"name": "CVE-2025-38643",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38643"
},
{
"name": "CVE-2021-3864",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-3864"
},
{
"name": "CVE-2025-39771",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39771"
},
{
"name": "CVE-2023-52591",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52591"
},
{
"name": "CVE-2024-26648",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26648"
},
{
"name": "CVE-2025-66862",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-66862"
},
{
"name": "CVE-2020-11868",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-11868"
},
{
"name": "CVE-2020-24352",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-24352"
},
{
"name": "CVE-2024-36000",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36000"
},
{
"name": "CVE-2026-23021",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23021"
},
{
"name": "CVE-2025-39819",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39819"
},
{
"name": "CVE-2022-49296",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49296"
},
{
"name": "CVE-2025-61780",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-61780"
},
{
"name": "CVE-2024-49914",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49914"
},
{
"name": "CVE-2025-38360",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38360"
},
{
"name": "CVE-2025-68732",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68732"
},
{
"name": "CVE-2025-39715",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39715"
},
{
"name": "CVE-2025-36407",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-36407"
},
{
"name": "CVE-2024-0217",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-0217"
},
{
"name": "CVE-2025-40323",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40323"
},
{
"name": "CVE-2025-21732",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21732"
},
{
"name": "CVE-2021-47658",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47658"
},
{
"name": "CVE-2025-68285",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68285"
},
{
"name": "CVE-2025-4575",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-4575"
},
{
"name": "CVE-2019-12067",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-12067"
},
{
"name": "CVE-2024-57843",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57843"
},
{
"name": "CVE-2025-38512",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38512"
},
{
"name": "CVE-2024-50135",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50135"
},
{
"name": "CVE-2024-49916",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49916"
},
{
"name": "CVE-2025-68119",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68119"
},
{
"name": "CVE-2024-49988",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49988"
},
{
"name": "CVE-2023-52648",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52648"
},
{
"name": "CVE-2024-49861",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49861"
},
{
"name": "CVE-2026-23093",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23093"
},
{
"name": "CVE-2024-49893",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49893"
},
{
"name": "CVE-2024-44963",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44963"
},
{
"name": "CVE-2023-53348",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53348"
},
{
"name": "CVE-2022-48766",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48766"
},
{
"name": "CVE-2019-15794",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-15794"
},
{
"name": "CVE-2024-49917",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49917"
},
{
"name": "CVE-2022-50467",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50467"
},
{
"name": "CVE-2025-37849",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37849"
},
{
"name": "CVE-2025-32441",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-32441"
},
{
"name": "CVE-2024-48875",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-48875"
},
{
"name": "CVE-2024-41935",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41935"
},
{
"name": "CVE-2025-38162",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38162"
},
{
"name": "CVE-2022-23491",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-23491"
},
{
"name": "CVE-2025-22873",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22873"
},
{
"name": "CVE-2023-5678",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-5678"
},
{
"name": "CVE-2025-71183",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71183"
},
{
"name": "CVE-2023-54047",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54047"
},
{
"name": "CVE-2023-53382",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53382"
},
{
"name": "CVE-2024-50060",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50060"
},
{
"name": "CVE-2025-39677",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39677"
},
{
"name": "CVE-2023-53651",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53651"
},
{
"name": "CVE-2025-21832",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21832"
},
{
"name": "CVE-2025-68371",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68371"
},
{
"name": "CVE-2022-50383",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50383"
},
{
"name": "CVE-2025-39707",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39707"
},
{
"name": "CVE-2025-40275",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40275"
},
{
"name": "CVE-2023-53387",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53387"
},
{
"name": "CVE-2026-31802",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31802"
},
{
"name": "CVE-2024-45774",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45774"
},
{
"name": "CVE-2023-54019",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54019"
},
{
"name": "CVE-2025-22053",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22053"
},
{
"name": "CVE-2025-13465",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-13465"
},
{
"name": "CVE-2025-61664",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-61664"
},
{
"name": "CVE-2025-68211",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68211"
},
{
"name": "CVE-2026-25702",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-25702"
},
{
"name": "CVE-2023-52452",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52452"
},
{
"name": "CVE-2023-42366",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-42366"
},
{
"name": "CVE-2022-50863",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50863"
},
{
"name": "CVE-2025-39829",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39829"
},
{
"name": "CVE-2024-35843",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35843"
},
{
"name": "CVE-2025-71091",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71091"
},
{
"name": "CVE-2025-39781",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39781"
},
{
"name": "CVE-2025-39762",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39762"
},
{
"name": "CVE-2024-40999",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40999"
},
{
"name": "CVE-2023-53292",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53292"
},
{
"name": "CVE-2023-52576",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52576"
},
{
"name": "CVE-2024-27002",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27002"
},
{
"name": "CVE-2025-0167",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-0167"
},
{
"name": "CVE-2024-57887",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57887"
},
{
"name": "CVE-2025-21730",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21730"
},
{
"name": "CVE-2024-35865",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35865"
},
{
"name": "CVE-2025-71184",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71184"
},
{
"name": "CVE-2023-52660",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52660"
},
{
"name": "CVE-2024-35995",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35995"
},
{
"name": "CVE-2025-69420",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-69420"
},
{
"name": "CVE-2023-53371",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53371"
},
{
"name": "CVE-2025-38659",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38659"
},
{
"name": "CVE-2025-68227",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68227"
},
{
"name": "CVE-2025-22041",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22041"
},
{
"name": "CVE-2025-40339",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40339"
},
{
"name": "CVE-2025-22127",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22127"
},
{
"name": "CVE-2025-47273",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-47273"
},
{
"name": "CVE-2024-27025",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27025"
},
{
"name": "CVE-2025-38020",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38020"
},
{
"name": "CVE-2024-27011",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27011"
},
{
"name": "CVE-2025-15224",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-15224"
},
{
"name": "CVE-2024-26605",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26605"
},
{
"name": "CVE-2026-27904",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-27904"
},
{
"name": "CVE-2024-38543",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38543"
},
{
"name": "CVE-2025-68263",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68263"
},
{
"name": "CVE-2023-53187",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53187"
},
{
"name": "CVE-2025-38689",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38689"
},
{
"name": "CVE-2025-68800",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68800"
},
{
"name": "CVE-2026-1225",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-1225"
},
{
"name": "CVE-2025-38275",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38275"
},
{
"name": "CVE-2025-68261",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68261"
},
{
"name": "CVE-2022-48744",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48744"
},
{
"name": "CVE-2025-38070",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38070"
},
{
"name": "CVE-2025-68755",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68755"
},
{
"name": "CVE-2025-62525",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-62525"
},
{
"name": "CVE-2025-71238",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71238"
},
{
"name": "CVE-2021-0175",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-0175"
},
{
"name": "CVE-2024-36012",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36012"
},
{
"name": "CVE-2022-48706",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48706"
},
{
"name": "CVE-2025-40334",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40334"
},
{
"name": "CVE-2025-68767",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68767"
},
{
"name": "CVE-2024-46716",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46716"
},
{
"name": "CVE-2012-4542",
"url": "https://www.cve.org/CVERecord?id=CVE-2012-4542"
},
{
"name": "CVE-2021-3773",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-3773"
},
{
"name": "CVE-2025-61729",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-61729"
},
{
"name": "CVE-2022-49267",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49267"
},
{
"name": "CVE-2024-56592",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56592"
},
{
"name": "CVE-2025-37854",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37854"
},
{
"name": "CVE-2025-38189",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38189"
},
{
"name": "CVE-2022-48628",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48628"
},
{
"name": "CVE-2024-6345",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-6345"
},
{
"name": "CVE-2024-50138",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50138"
},
{
"name": "CVE-2025-40319",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40319"
},
{
"name": "CVE-2021-44534",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-44534"
},
{
"name": "CVE-2025-14831",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-14831"
},
{
"name": "CVE-2024-56565",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56565"
},
{
"name": "CVE-2025-68193",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68193"
},
{
"name": "CVE-2025-68727",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68727"
},
{
"name": "CVE-2024-57872",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57872"
},
{
"name": "CVE-2023-28720",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-28720"
},
{
"name": "CVE-2024-53093",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53093"
},
{
"name": "CVE-2026-23080",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23080"
},
{
"name": "CVE-2024-46833",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46833"
},
{
"name": "CVE-2024-47703",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47703"
},
{
"name": "CVE-2023-53742",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53742"
},
{
"name": "CVE-2025-38361",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38361"
},
{
"name": "CVE-2025-38041",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38041"
},
{
"name": "CVE-2024-53177",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53177"
},
{
"name": "CVE-2024-56588",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56588"
},
{
"name": "CVE-2023-53452",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53452"
},
{
"name": "CVE-2023-54121",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54121"
},
{
"name": "CVE-2023-6610",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-6610"
},
{
"name": "CVE-2023-54261",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54261"
},
{
"name": "CVE-2022-50616",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50616"
},
{
"name": "CVE-2025-66418",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-66418"
},
{
"name": "CVE-2023-53544",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53544"
},
{
"name": "CVE-2025-68264",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68264"
},
{
"name": "CVE-2024-49911",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49911"
},
{
"name": "CVE-2026-23154",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23154"
},
{
"name": "CVE-2022-50708",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50708"
},
{
"name": "CVE-2026-3784",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-3784"
},
{
"name": "CVE-2025-68764",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68764"
},
{
"name": "CVE-2025-9301",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-9301"
},
{
"name": "CVE-2025-11226",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-11226"
}
],
"initial_release_date": "2026-03-20T00:00:00",
"last_revision_date": "2026-03-20T00:00:00",
"links": [],
"reference": "CERTFR-2026-AVI-0326",
"revisions": [
{
"description": "Version initiale",
"revision_date": "2026-03-20T00: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": "2026-03-19",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 37233",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/37233"
},
{
"published_at": "2026-03-19",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 37237",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/37237"
},
{
"published_at": "2026-03-19",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 37236",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/37236"
},
{
"published_at": "2026-03-19",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 37246",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/37246"
},
{
"published_at": "2026-03-19",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 37235",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/37235"
},
{
"published_at": "2026-03-19",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 37229",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/37229"
},
{
"published_at": "2026-03-19",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 37226",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/37226"
},
{
"published_at": "2026-03-19",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 37230",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/37230"
},
{
"published_at": "2026-03-19",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 37242",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/37242"
},
{
"published_at": "2026-03-19",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 37228",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/37228"
},
{
"published_at": "2026-03-19",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 37240",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/37240"
},
{
"published_at": "2026-03-19",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 37243",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/37243"
},
{
"published_at": "2026-03-19",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 37234",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/37234"
},
{
"published_at": "2026-03-19",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 37231",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/37231"
},
{
"published_at": "2026-03-19",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 37239",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/37239"
},
{
"published_at": "2026-03-19",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 37227",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/37227"
},
{
"published_at": "2026-03-19",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 37232",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/37232"
},
{
"published_at": "2026-03-19",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 37247",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/37247"
},
{
"published_at": "2026-03-19",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 37241",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/37241"
},
{
"published_at": "2026-03-19",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 37238",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/37238"
},
{
"published_at": "2026-03-19",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 37244",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/37244"
},
{
"published_at": "2026-03-19",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 37245",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/37245"
}
]
}
FKIE_CVE-2024-49929
Vulnerability from fkie_nvd - Published: 2024-10-21 18:15 - Updated: 2026-06-17 08:00| URL | Tags | ||
|---|---|---|---|
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/557a6cd847645e667f3b362560bd7e7c09aac284 | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/6dcadb2ed3b76623ab96e3e7fbeda1a374d01c28 | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/c0b4f5d94934c290479180868a32c15ba36a6d9e | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/cbc6fc9cfcde151ff5eadaefdc6155f99579384f | ||
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/cdbf51bfa4b0411820806777da36d93d49bc49a1 | Patch | |
| af854a3a-2127-422b-91ae-364da2661108 | https://lists.debian.org/debian-lts-announce/2025/03/msg00001.html |
| Vendor | Product | Version | |
|---|---|---|---|
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * |
{
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/net/wireless/intel/iwlwifi/mvm/tx.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "cbc6fc9cfcde151ff5eadaefdc6155f99579384f",
"status": "affected",
"version": "5b577a90fb3d86447ee86f8e0c6ddbd5da2ef8c9",
"versionType": "git"
},
{
"lessThan": "6dcadb2ed3b76623ab96e3e7fbeda1a374d01c28",
"status": "affected",
"version": "5b577a90fb3d86447ee86f8e0c6ddbd5da2ef8c9",
"versionType": "git"
},
{
"lessThan": "cdbf51bfa4b0411820806777da36d93d49bc49a1",
"status": "affected",
"version": "5b577a90fb3d86447ee86f8e0c6ddbd5da2ef8c9",
"versionType": "git"
},
{
"lessThan": "c0b4f5d94934c290479180868a32c15ba36a6d9e",
"status": "affected",
"version": "5b577a90fb3d86447ee86f8e0c6ddbd5da2ef8c9",
"versionType": "git"
},
{
"lessThan": "557a6cd847645e667f3b362560bd7e7c09aac284",
"status": "affected",
"version": "5b577a90fb3d86447ee86f8e0c6ddbd5da2ef8c9",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/net/wireless/intel/iwlwifi/mvm/tx.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "3.14"
},
{
"lessThan": "3.14",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.120",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.55",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.10.*",
"status": "unaffected",
"version": "6.10.14",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.11.*",
"status": "unaffected",
"version": "6.11.3",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.12",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"configurations": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "8B527B5F-BDDA-424E-932E-16FCAAB575E2",
"versionEndExcluding": "6.6.55",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "4C16BCE0-FFA0-4599-BE0A-1FD65101C021",
"versionEndExcluding": "6.10.14",
"versionStartIncluding": "6.7",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "54D9C704-D679-41A7-9C40-10A6B1E7FFE9",
"versionEndExcluding": "6.11.3",
"versionStartIncluding": "6.11",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: iwlwifi: mvm: avoid NULL pointer dereference\n\niwl_mvm_tx_skb_sta() and iwl_mvm_tx_mpdu() verify that the mvmvsta\npointer is not NULL.\nIt retrieves this pointer using iwl_mvm_sta_from_mac80211, which is\ndereferencing the ieee80211_sta pointer.\nIf sta is NULL, iwl_mvm_sta_from_mac80211 will dereference a NULL\npointer.\nFix this by checking the sta pointer before retrieving the mvmsta\nfrom it. If sta is not NULL, then mvmsta isn\u0027t either."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: iwlwifi: mvm: evitar la desreferencia del puntero NULL iwl_mvm_tx_skb_sta() e iwl_mvm_tx_mpdu() verifican que el puntero mvmvsta no sea NULL. Recupera este puntero utilizando iwl_mvm_sta_from_mac80211, que est\u00e1 desreferenciando el puntero ieee80211_sta. Si sta es NULL, iwl_mvm_sta_from_mac80211 desreferenciar\u00e1 un puntero NULL. Solucione esto comprobando el puntero sta antes de recuperar el mvmsta de \u00e9l. Si sta no es NULL, entonces mvmsta tampoco lo es."
}
],
"id": "CVE-2024-49929",
"lastModified": "2026-06-17T08:00:45.277",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 5.5,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 3.6,
"source": "nvd@nist.gov",
"type": "Primary"
}
],
"ssvcV203": [
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"ssvcData": {
"id": "CVE-2024-49929",
"options": [
{
"exploitation": "none"
},
{
"automatable": "no"
},
{
"technicalImpact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2024-10-22T13:39:18.933944Z",
"version": "2.0.3"
}
}
]
},
"published": "2024-10-21T18:15:14.907",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/557a6cd847645e667f3b362560bd7e7c09aac284"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/6dcadb2ed3b76623ab96e3e7fbeda1a374d01c28"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/c0b4f5d94934c290479180868a32c15ba36a6d9e"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/cbc6fc9cfcde151ff5eadaefdc6155f99579384f"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/cdbf51bfa4b0411820806777da36d93d49bc49a1"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00001.html"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Modified",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "CWE-476"
}
],
"source": "nvd@nist.gov",
"type": "Primary"
}
]
}
GHSA-74QF-4594-QX2M
Vulnerability from github – Published: 2024-10-21 18:30 – Updated: 2025-11-03 21:31In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlwifi: mvm: avoid NULL pointer dereference
iwl_mvm_tx_skb_sta() and iwl_mvm_tx_mpdu() verify that the mvmvsta pointer is not NULL. It retrieves this pointer using iwl_mvm_sta_from_mac80211, which is dereferencing the ieee80211_sta pointer. If sta is NULL, iwl_mvm_sta_from_mac80211 will dereference a NULL pointer. Fix this by checking the sta pointer before retrieving the mvmsta from it. If sta is not NULL, then mvmsta isn't either.
{
"affected": [],
"aliases": [
"CVE-2024-49929"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-10-21T18:15:14Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: iwlwifi: mvm: avoid NULL pointer dereference\n\niwl_mvm_tx_skb_sta() and iwl_mvm_tx_mpdu() verify that the mvmvsta\npointer is not NULL.\nIt retrieves this pointer using iwl_mvm_sta_from_mac80211, which is\ndereferencing the ieee80211_sta pointer.\nIf sta is NULL, iwl_mvm_sta_from_mac80211 will dereference a NULL\npointer.\nFix this by checking the sta pointer before retrieving the mvmsta\nfrom it. If sta is not NULL, then mvmsta isn\u0027t either.",
"id": "GHSA-74qf-4594-qx2m",
"modified": "2025-11-03T21:31:23Z",
"published": "2024-10-21T18:30:58Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49929"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/557a6cd847645e667f3b362560bd7e7c09aac284"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6dcadb2ed3b76623ab96e3e7fbeda1a374d01c28"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c0b4f5d94934c290479180868a32c15ba36a6d9e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cbc6fc9cfcde151ff5eadaefdc6155f99579384f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cdbf51bfa4b0411820806777da36d93d49bc49a1"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00001.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
MSRC_CVE-2024-49929
Vulnerability from csaf_microsoft - Published: 2024-10-01 07:00 - Updated: 2026-03-31 15:02OESA-2024-2491 (CVE-2022-48969)
Vulnerability from osv_openeuler – Published: 2024-11-29 11:07 – Updated: 2026-08-06 11:07 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved: xen-netfront: Fix NULL sring after live migration A NAPI is setup for each network sring to poll data to kernel The sring with source host is destroyed before live migration and new sring with target host is setup after live migration. The NAPI for the old sring is not deleted until setup new sring with target host after migration. With busy_poll/busy_read enabled, the NAPI can be polled before got deleted when resume VM. BUG: unable to handle kernel NULL pointer dereference at 0000000000000008 IP: xennet_poll+0xae/0xd20 PGD 0 P4D 0 Oops: 0000 [#1] SMP PTI Call Trace: finish_task_switch+0x71/0x230 timerqueue_del+0x1d/0x40 hrtimer_try_to_cancel+0xb5/0x110 xennet_alloc_rx_buffers+0x2a0/0x2a0 napi_busy_loop+0xdb/0x270 sock_poll+0x87/0x90 do_sys_poll+0x26f/0x580 tracing_map_insert+0x1d4/0x2f0 event_hist_trigger+0x14a/0x260 finish_task_switch+0x71/0x230 __schedule+0x256/0x890 recalc_sigpending+0x1b/0x50 xen_sched_clock+0x15/0x20 __rb_reserve_next+0x12d/0x140 ring_buffer_lock_reserve+0x123/0x3d0 event_triggers_call+0x87/0xb0 trace_event_buffer_commit+0x1c4/0x210 xen_clocksource_get_cycles+0x15/0x20 ktime_get_ts64+0x51/0xf0 SyS_ppoll+0x160/0x1a0 SyS_ppoll+0x160/0x1a0 do_syscall_64+0x73/0x130 entry_SYSCALL_64_after_hwframe+0x41/0xa6 ... RIP: xennet_poll+0xae/0xd20 RSP: ffffb4f041933900 CR2: 0000000000000008 ---[ end trace f8601785b354351c ]--- xen frontend should remove the NAPIs for the old srings before live migration as the bond srings are destroyed There is a tiny window between the srings are set to NULL and the NAPIs are disabled, It is safe as the NAPI threads are still frozen at that time(CVE-2022-48969)
In the Linux kernel, the following vulnerability has been resolved:
bonding: stop the device in bond_setup_by_slave()
Commit 9eed321cde22 ("net: lapbether: only support ethernet devices") has been able to keep syzbot away from net/lapb, until today.
In the following splat [1], the issue is that a lapbether device has been created on a bonding device without members. Then adding a non ARPHRD_ETHER member forced the bonding master to change its type.
The fix is to make sure we call dev_close() in bond_setup_by_slave() so that the potential linked lapbether devices (or any other devices having assumptions on the physical device) are removed.
A similar bug has been addressed in commit 40baec225765 ("bonding: fix panic on non-ARPHRD_ETHER enslave failure")
[1] skbuff: skb_under_panic: text:ffff800089508810 len:44 put:40 head:ffff0000c78e7c00 data:ffff0000c78e7bea tail:0x16 end:0x140 dev:bond0 kernel BUG at net/core/skbuff.c:192 ! Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP Modules linked in: CPU: 0 PID: 6007 Comm: syz-executor383 Not tainted 6.6.0-rc3-syzkaller-gbf6547d8715b #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/04/2023 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : skb_panic net/core/skbuff.c:188 [inline] pc : skb_under_panic+0x13c/0x140 net/core/skbuff.c:202 lr : skb_panic net/core/skbuff.c:188 [inline] lr : skb_under_panic+0x13c/0x140 net/core/skbuff.c:202 sp : ffff800096a06aa0 x29: ffff800096a06ab0 x28: ffff800096a06ba0 x27: dfff800000000000 x26: ffff0000ce9b9b50 x25: 0000000000000016 x24: ffff0000c78e7bea x23: ffff0000c78e7c00 x22: 000000000000002c x21: 0000000000000140 x20: 0000000000000028 x19: ffff800089508810 x18: ffff800096a06100 x17: 0000000000000000 x16: ffff80008a629a3c x15: 0000000000000001 x14: 1fffe00036837a32 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000201 x10: 0000000000000000 x9 : cb50b496c519aa00 x8 : cb50b496c519aa00 x7 : 0000000000000001 x6 : 0000000000000001 x5 : ffff800096a063b8 x4 : ffff80008e280f80 x3 : ffff8000805ad11c x2 : 0000000000000001 x1 : 0000000100000201 x0 : 0000000000000086 Call trace: skb_panic net/core/skbuff.c:188 [inline] skb_under_panic+0x13c/0x140 net/core/skbuff.c:202 skb_push+0xf0/0x108 net/core/skbuff.c:2446 ip6gre_header+0xbc/0x738 net/ipv6/ip6_gre.c:1384 dev_hard_header include/linux/netdevice.h:3136 [inline] lapbeth_data_transmit+0x1c4/0x298 drivers/net/wan/lapbether.c:257 lapb_data_transmit+0x8c/0xb0 net/lapb/lapb_iface.c:447 lapb_transmit_buffer+0x178/0x204 net/lapb/lapb_out.c:149 lapb_send_control+0x220/0x320 net/lapb/lapb_subr.c:251 __lapb_disconnect_request+0x9c/0x17c net/lapb/lapb_iface.c:326 lapb_device_event+0x288/0x4e0 net/lapb/lapb_iface.c:492 notifier_call_chain+0x1a4/0x510 kernel/notifier.c:93 raw_notifier_call_chain+0x3c/0x50 kernel/notifier.c:461 call_netdevice_notifiers_info net/core/dev.c:1970 [inline] call_netdevice_notifiers_extack net/core/dev.c:2008 [inline] call_netdevice_notifiers net/core/dev.c:2022 [inline] __dev_close_many+0x1b8/0x3c4 net/core/dev.c:1508 dev_close_many+0x1e0/0x470 net/core/dev.c:1559 dev_close+0x174/0x250 net/core/dev.c:1585 lapbeth_device_event+0x2e4/0x958 drivers/net/wan/lapbether.c:466 notifier_call_chain+0x1a4/0x510 kernel/notifier.c:93 raw_notifier_call_chain+0x3c/0x50 kernel/notifier.c:461 call_netdevice_notifiers_info net/core/dev.c:1970 [inline] call_netdevice_notifiers_extack net/core/dev.c:2008 [inline] call_netdevice_notifiers net/core/dev.c:2022 [inline] __dev_close_many+0x1b8/0x3c4 net/core/dev.c:1508 dev_close_many+0x1e0/0x470 net/core/dev.c:1559 dev_close+0x174/0x250 net/core/dev.c:1585 bond_enslave+0x2298/0x30cc drivers/net/bonding/bond_main.c:2332 bond_do_ioctl+0x268/0xc64 drivers/net/bonding/bond_main.c:4539 dev_ifsioc+0x754/0x9ac dev_ioctl+0x4d8/0xd34 net/core/dev_ioctl.c:786 sock_do_ioctl+0x1d4/0x2d0 net/socket.c:1217 sock_ioctl+0x4e8/0x834 net/socket.c:1322 vfs_ioctl fs/ioctl.c:51 [inline] __do_ ---truncated---(CVE-2023-52784)
In the Linux kernel, the following vulnerability has been resolved:
llc: verify mac len before reading mac header
LLC reads the mac header with eth_hdr without verifying that the skb has an Ethernet header.
Syzbot was able to enter llc_rcv on a tun device. Tun can insert packets without mac len and with user configurable skb->protocol (passing a tun_pi header when not configuring IFF_NO_PI).
BUG: KMSAN: uninit-value in llc_station_ac_send_test_r net/llc/llc_station.c:81 [inline]
BUG: KMSAN: uninit-value in llc_station_rcv+0x6fb/0x1290 net/llc/llc_station.c:111
llc_station_ac_send_test_r net/llc/llc_station.c:81 [inline]
llc_station_rcv+0x6fb/0x1290 net/llc/llc_station.c:111
llc_rcv+0xc5d/0x14a0 net/llc/llc_input.c:218
__netif_receive_skb_one_core net/core/dev.c:5523 [inline]
__netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5637
netif_receive_skb_internal net/core/dev.c:5723 [inline]
netif_receive_skb+0x58/0x660 net/core/dev.c:5782
tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555
tun_get_user+0x54c5/0x69c0 drivers/net/tun.c:2002
Add a mac_len test before all three eth_hdr(skb) calls under net/llc.
There are further uses in include/net/llc_pdu.h. All these are protected by a test skb->protocol == ETH_P_802_2. Which does not protect against this tun scenario.
But the mac_len test added in this patch in llc_fixup_skb will indirectly protect those too. That is called from llc_rcv before any other LLC code.
It is tempting to just add a blanket mac_len check in llc_rcv, but not sure whether that could break valid LLC paths that do not assume an Ethernet header. 802.2 LLC may be used on top of non-802.3 protocols in principle. The below referenced commit shows that used to, on top of Token Ring.
At least one of the three eth_hdr uses goes back to before the start of git history. But the one that syzbot exercises is introduced in this commit. That commit is old enough (2008), that effectively all stable kernels should receive this.(CVE-2023-52843)
In the Linux kernel, the following vulnerability has been resolved:
SUNRPC: Fix UAF in svc_tcp_listen_data_ready()
After the listener svc_sock is freed, and before invoking svc_tcp_accept() for the established child sock, there is a window that the newsock retaining a freed listener svc_sock in sk_user_data which cloning from parent. In the race window, if data is received on the newsock, we will observe use-after-free report in svc_tcp_listen_data_ready().
Reproduce by two tasks:
- while :; do rpc.nfsd 0 ; rpc.nfsd; done
- while :; do echo "" | ncat -4 127.0.0.1 2049 ; done
KASAN report:
================================================================== BUG: KASAN: slab-use-after-free in svc_tcp_listen_data_ready+0x1cf/0x1f0 [sunrpc] Read of size 8 at addr ffff888139d96228 by task nc/102553 CPU: 7 PID: 102553 Comm: nc Not tainted 6.3.0+ #18 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 Call Trace: <IRQ> dump_stack_lvl+0x33/0x50 print_address_description.constprop.0+0x27/0x310 print_report+0x3e/0x70 kasan_report+0xae/0xe0 svc_tcp_listen_data_ready+0x1cf/0x1f0 [sunrpc] tcp_data_queue+0x9f4/0x20e0 tcp_rcv_established+0x666/0x1f60 tcp_v4_do_rcv+0x51c/0x850 tcp_v4_rcv+0x23fc/0x2e80 ip_protocol_deliver_rcu+0x62/0x300 ip_local_deliver_finish+0x267/0x350 ip_local_deliver+0x18b/0x2d0 ip_rcv+0x2fb/0x370 __netif_receive_skb_one_core+0x166/0x1b0 process_backlog+0x24c/0x5e0 __napi_poll+0xa2/0x500 net_rx_action+0x854/0xc90 __do_softirq+0x1bb/0x5de do_softirq+0xcb/0x100 </IRQ> <TASK> ... </TASK>
Allocated by task 102371: kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30 __kasan_kmalloc+0x7b/0x90 svc_setup_socket+0x52/0x4f0 [sunrpc] svc_addsock+0x20d/0x400 [sunrpc] __write_ports_addfd+0x209/0x390 [nfsd] write_ports+0x239/0x2c0 [nfsd] nfsctl_transaction_write+0xac/0x110 [nfsd] vfs_write+0x1c3/0xae0 ksys_write+0xed/0x1c0 do_syscall_64+0x38/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdc
Freed by task 102551: kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30 kasan_save_free_info+0x2a/0x50 __kasan_slab_free+0x106/0x190 __kmem_cache_free+0x133/0x270 svc_xprt_free+0x1e2/0x350 [sunrpc] svc_xprt_destroy_all+0x25a/0x440 [sunrpc] nfsd_put+0x125/0x240 [nfsd] nfsd_svc+0x2cb/0x3c0 [nfsd] write_threads+0x1ac/0x2a0 [nfsd] nfsctl_transaction_write+0xac/0x110 [nfsd] vfs_write+0x1c3/0xae0 ksys_write+0xed/0x1c0 do_syscall_64+0x38/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdc
Fix the UAF by simply doing nothing in svc_tcp_listen_data_ready() if state != TCP_LISTEN, that will avoid dereferencing svsk for all child socket.(CVE-2023-52885)
In the Linux kernel, the following vulnerability has been resolved:
perf/aux: Fix AUX buffer serialization
Ole reported that event->mmap_mutex is strictly insufficient to serialize the AUX buffer, add a per RB mutex to fully serialize it.
Note that in the lock order comment the perf_event::mmap_mutex order was already wrong, that is, it nesting under mmap_lock is not new with this patch.(CVE-2024-46713)
In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix spin_unlock_irqrestore() called with IRQs enabled Fix missuse of spin_lock_irq()/spin_unlock_irq() when spin_lock_irqsave()/spin_lock_irqrestore() was hold. This was discovered through the lock debugging, and the corresponding log is as follows: raw_local_irq_restore() called with IRQs enabled WARNING: CPU: 96 PID: 2074 at kernel/locking/irqflag-debug.c:10 warn_bogus_irq_restore+0x30/0x40 ... Call trace: warn_bogus_irq_restore+0x30/0x40 _raw_spin_unlock_irqrestore+0x84/0xc8 add_qp_to_list+0x11c/0x148 [hns_roce_hw_v2] hns_roce_create_qp_common.constprop.0+0x240/0x780 [hns_roce_hw_v2] hns_roce_create_qp+0x98/0x160 [hns_roce_hw_v2] create_qp+0x138/0x258 ib_create_qp_kernel+0x50/0xe8 create_mad_qp+0xa8/0x128 ib_mad_port_open+0x218/0x448 ib_mad_init_device+0x70/0x1f8 add_client_context+0xfc/0x220 enable_device_and_get+0xd0/0x140 ib_register_device.part.0+0xf4/0x1c8 ib_register_device+0x34/0x50 hns_roce_register_device+0x174/0x3d0 [hns_roce_hw_v2] hns_roce_init+0xfc/0x2c0 [hns_roce_hw_v2] __hns_roce_hw_v2_init_instance+0x7c/0x1d0 [hns_roce_hw_v2] hns_roce_hw_v2_init_instance+0x9c/0x180 hns_roce_hw_v2
In the Linux kernel, the following vulnerability has been resolved: mm: call the security_mmap_file() LSM hook in remap_file_pages() The remap_file_pages syscall handler calls do_mmap() directly, which doesn't contain the LSM security check. And if the process has called personality(READ_IMPLIES_EXEC) before and remap_file_pages() is called for RW pages, this will actually result in remapping the pages to RWX, bypassing a W^X policy enforced by SELinux. So we should check prot by security_mmap_file LSM hook in the remap_file_pages syscall handler before do_mmap() is called. Otherwise, it potentially permits an attacker to bypass a W^X policy enforced by SELinux. The bypass is similar to CVE-2016-10044, which bypass the same thing via AIO and can be found in [1]. The PoC: $ cat > test.c int main(void) { size_t pagesz = sysconf(_SC_PAGE_SIZE); int mfd = syscall(SYS_memfd_create, "test", 0); const char *buf = mmap(NULL, 4 * pagesz, PROT_READ | PROT_WRITE, MAP_SHARED, mfd, 0); unsigned int old = syscall(SYS_personality, 0xffffffff); syscall(SYS_personality, READ_IMPLIES_EXEC | old); syscall(SYS_remap_file_pages, buf, pagesz, 0, 2, 0); syscall(SYS_personality, old); // show the RWX page exists even if W^X policy is enforced int fd = open("/proc/self/maps", O_RDONLY); unsigned char buf2[1024]; while (1) { int ret = read(fd, buf2, 1024); if (ret <= 0) break; write(1, buf2, ret); } close(fd); } $ gcc test.c -o test $ ./test | grep rwx 7f1836c34000-7f1836c35000 rwxs 00002000 00:01 2050 /memfd:test (deleted) PM: subject line tweaks
In the Linux kernel, the following vulnerability has been resolved: net: seeq: Fix use after free vulnerability in ether3 Driver Due to Race Condition In the ether3_probe function, a timer is initialized with a callback function ether3_ledoff, bound to &prev(dev)->timer. Once the timer is started, there is a risk of a race condition if the module or device is removed, triggering the ether3_remove function to perform cleanup. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | ether3_ledoff ether3_remove | free_netdev(dev); | put_devic | kfree(dev); | | ether3_outw(priv(dev)->regs.config2 |= CFG2_CTRLO, REG_CONFIG2); | // use dev Fix it by ensuring that the timer is canceled before proceeding with the cleanup in ether3_remove.(CVE-2024-47747)
In the Linux kernel, the following vulnerability has been resolved: RDMA/cxgb4: Added NULL check for lookup_atid The lookup_atid() function can return NULL if the ATID is invalid or does not exist in the identifier table, which could lead to dereferencing a null pointer without a check in the act_establish() and act_open_rpl() functions. Add a NULL check to prevent null pointer dereferencing. Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-47749)
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Initialize denominators' default to 1 [WHAT & HOW] Variables used as denominators and maybe not assigned to other values, should not be 0. Change their default to 1 so they are never 0. This fixes 10 DIVIDE_BY_ZERO issues reported by Coverity.(CVE-2024-49899)
In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: avoid NULL pointer dereference iwl_mvm_tx_skb_sta() and iwl_mvm_tx_mpdu() verify that the mvmvsta pointer is not NULL. It retrieves this pointer using iwl_mvm_sta_from_mac80211, which is dereferencing the ieee80211_sta pointer. If sta is NULL, iwl_mvm_sta_from_mac80211 will dereference a NULL pointer. Fix this by checking the sta pointer before retrieving the mvmsta from it. If sta is not NULL, then mvmsta isn't either.(CVE-2024-49929)
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: prevent nf_skb_duplicated corruption syzbot found that nf_dup_ipv4() or nf_dup_ipv6() could write per-cpu variable nf_skb_duplicated in an unsafe way [1]. Disabling preemption as hinted by the splat is not enough, we have to disable soft interrupts as well. [1] BUG: using __this_cpu_write() in preemptible [00000000] code: syz.4.282/6316 caller is nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87 CPU: 0 UID: 0 PID: 6316 Comm: syz.4.282 Not tainted 6.11.0-rc7-syzkaller-00104-g7052622fccb1 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 check_preemption_disabled+0x10e/0x120 lib/smp_processor_id.c:49 nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87 nft_dup_ipv4_eval+0x1db/0x300 net/ipv4/netfilter/nft_dup_ipv4.c:30 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x4ad/0x1da0 net/netfilter/nf_tables_core.c:288 nft_do_chain_ipv4+0x202/0x320 net/netfilter/nft_chain_filter.c:23 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626 nf_hook+0x2c4/0x450 include/linux/netfilter.h:269 NF_HOOK_COND include/linux/netfilter.h:302 [inline] ip_output+0x185/0x230 net/ipv4/ip_output.c:433 ip_local_out net/ipv4/ip_output.c:129 [inline] ip_send_skb+0x74/0x100 net/ipv4/ip_output.c:1495 udp_send_skb+0xacf/0x1650 net/ipv4/udp.c:981 udp_sendmsg+0x1c21/0x2a60 net/ipv4/udp.c:1269 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x1a6/0x270 net/socket.c:745 _syssendmsg+0x525/0x7d0 net/socket.c:2597 _sys_sendmsg net/socket.c:2651 [inline] __sys_sendmmsg+0x3b2/0x740 net/socket.c:2737 __do_sys_sendmmsg net/socket.c:2766 [inline] __se_sys_sendmmsg net/socket.c:2763 [inline] __x64_sys_sendmmsg+0xa0/0xb0 net/socket.c:2763 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f4ce4f7def9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f4ce5d4a038 EFLAGS: 00000246 ORIG_RAX: 0000000000000133 RAX: ffffffffffffffda RBX: 00007f4ce5135f80 RCX: 00007f4ce4f7def9 RDX: 0000000000000001 RSI: 0000000020005d40 RDI: 0000000000000006 RBP: 00007f4ce4ff0b76 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f4ce5135f80 R15: 00007ffd4cbc6d68 </TASK>(CVE-2024-49952)
In the Linux kernel, the following vulnerability has been resolved: netfilter: xtables: avoid NFPROTO_UNSPEC where needed syzbot managed to call xt_cluster match via ebtables: WARNING: CPU: 0 PID: 11 at net/netfilter/xt_cluster.c:72 xt_cluster_mt+0x196/0x780 [..] ebt_do_table+0x174b/0x2a40 Module registers to NFPROTO_UNSPEC, but it assumes ipv4/ipv6 packet processing. As this is only useful to restrict locally terminating TCP/UDP traffic, register this for ipv4 and ipv6 family only. Pablo points out that this is a general issue, direct users of the set/getsockopt interface can call into targets/matches that were only intended for use with ip(6)tables. Check all UNSPEC matches and targets for similar issues: - matches and targets are fine except if they assume skb_network_header() is valid -- this is only true when called from inet layer: ip(6) stack pulls the ip/ipv6 header into linear data area. - targets that return XT_CONTINUE or other xtables verdicts must be restricted too, they are incompatbile with the ebtables traverser, e.g. EBT_CONTINUE is a completely different value than XT_CONTINUE. Most matches/targets are changed to register for NFPROTO_IPV4/IPV6, as they are provided for use by ip(6)tables. The MARK target is also used by arptables, so register for NFPROTO_ARP too. While at it, bail out if connbytes fails to enable the corresponding conntrack family. This change passes the selftests in iptables.git.(CVE-2024-50038)
In the Linux kernel, the following vulnerability has been resolved: netfilter: br_netfilter: fix panic with metadata_dst skb Fix a kernel panic in the br_netfilter module when sending untagged traffic via a VxLAN device. This happens during the check for fragmentation in br_nf_dev_queue_xmit. It is dependent on: 1) the br_netfilter module being loaded; 2) net.bridge.bridge-nf-call-iptables set to 1; 3) a bridge with a VxLAN (single-vxlan-device) netdevice as a bridge port; 4) untagged frames with size higher than the VxLAN MTU forwarded/flooded When forwarding the untagged packet to the VxLAN bridge port, before the netfilter hooks are called, br_handle_egress_vlan_tunnel is called and changes the skb_dst to the tunnel dst. The tunnel_dst is a metadata type of dst, i.e., skb_valid_dst(skb) is false, and metadata->dst.dev is NULL. Then in the br_netfilter hooks, in br_nf_dev_queue_xmit, there's a check for frames that needs to be fragmented: frames with higher MTU than the VxLAN device end up calling br_nf_ip_fragment, which in turns call ip_skb_dst_mtu. The ip_dst_mtu tries to use the skb_dst(skb) as if it was a valid dst with valid dst->dev, thus the crash. This case was never supported in the first place, so drop the packet instead. PING 10.0.0.2 (10.0.0.2) from 0.0.0.0 h1-eth0: 2000(2028) bytes of data. [ 176.291791] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000110 [ 176.292101] Mem abort info: [ 176.292184] ESR = 0x0000000096000004 [ 176.292322] EC = 0x25: DABT (current EL), IL = 32 bits [ 176.292530] SET = 0, FnV = 0 [ 176.292709] EA = 0, S1PTW = 0 [ 176.292862] FSC = 0x04: level 0 translation fault [ 176.293013] Data abort info: [ 176.293104] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 176.293488] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 176.293787] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 176.293995] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000043ef5000 [ 176.294166] [0000000000000110] pgd=0000000000000000, p4d=0000000000000000 [ 176.294827] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 176.295252] Modules linked in: vxlan ip6_udp_tunnel udp_tunnel veth br_netfilter bridge stp llc ipv6 crct10dif_ce [ 176.295923] CPU: 0 PID: 188 Comm: ping Not tainted 6.8.0-rc3-g5b3fbd61b9d1 #2 [ 176.296314] Hardware name: linux,dummy-virt (DT) [ 176.296535] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 176.296808] pc : br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter] [ 176.297382] lr : br_nf_dev_queue_xmit+0x2ac/0x4ec [br_netfilter] [ 176.297636] sp : ffff800080003630 [ 176.297743] x29: ffff800080003630 x28: 0000000000000008 x27: ffff6828c49ad9f8 [ 176.298093] x26: ffff6828c49ad000 x25: 0000000000000000 x24: 00000000000003e8 [ 176.298430] x23: 0000000000000000 x22: ffff6828c4960b40 x21: ffff6828c3b16d28 [ 176.298652] x20: ffff6828c3167048 x19: ffff6828c3b16d00 x18: 0000000000000014 [ 176.298926] x17: ffffb0476322f000 x16: ffffb7e164023730 x15: 0000000095744632 [ 176.299296] x14: ffff6828c3f1c880 x13: 0000000000000002 x12: ffffb7e137926a70 [ 176.299574] x11: 0000000000000001 x10: ffff6828c3f1c898 x9 : 0000000000000000 [ 176.300049] x8 : ffff6828c49bf070 x7 : 0008460f18d5f20e x6 : f20e0100bebafeca [ 176.300302] x5 : ffff6828c7f918fe x4 : ffff6828c49bf070 x3 : 0000000000000000 [ 176.300586] x2 : 0000000000000000 x1 : ffff6828c3c7ad00 x0 : ffff6828c7f918f0 [ 176.300889] Call trace: [ 176.301123] br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter] [ 176.301411] br_nf_post_routing+0x2a8/0x3e4 [br_netfilter] [ 176.301703] nf_hook_slow+0x48/0x124 [ 176.302060] br_forward_finish+0xc8/0xe8 [bridge] [ 176.302371] br_nf_hook_thresh+0x124/0x134 [br_netfilter] [ 176.302605] br_nf_forward_finish+0x118/0x22c [br_netfilter] [ 176.302824] br_nf_forward_ip.part.0+0x264/0x290 [br_netfilter] [ 176.303136] br_nf_forward+0x2b8/0x4e0 [br_netfilter] [ 176.303359] nf_hook_slow+0x48/0x124 [ 176.303 ---truncated---(CVE-2024-50045)
In the Linux kernel, the following vulnerability has been resolved: RDMA/rtrs-srv: Avoid null pointer deref during path establishment For RTRS path establishment, RTRS client initiates and completes con_num of connections. After establishing all its connections, the information is exchanged between the client and server through the info_req message. During this exchange, it is essential that all connections have been established, and the state of the RTRS srv path is CONNECTED. So add these sanity checks, to make sure we detect and abort process in error scenarios to avoid null pointer deref.(CVE-2024-50062)
In the Linux kernel, the following vulnerability has been resolved: tty: n_gsm: Fix use-after-free in gsm_cleanup_mux BUG: KASAN: slab-use-after-free in gsm_cleanup_mux+0x77b/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] Read of size 8 at addr ffff88815fe99c00 by task poc/3379 CPU: 0 UID: 0 PID: 3379 Comm: poc Not tainted 6.11.0+ #56 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 Call Trace: <TASK> gsm_cleanup_mux+0x77b/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] __pfx_gsm_cleanup_mux+0x10/0x10 drivers/tty/n_gsm.c:3124 [n_gsm] __pfx_sched_clock_cpu+0x10/0x10 kernel/sched/clock.c:389 update_load_avg+0x1c1/0x27b0 kernel/sched/fair.c:4500 __pfx_min_vruntime_cb_rotate+0x10/0x10 kernel/sched/fair.c:846 __rb_insert_augmented+0x492/0xbf0 lib/rbtree.c:161 gsmld_ioctl+0x395/0x1450 drivers/tty/n_gsm.c:3408 [n_gsm] _raw_spin_lock_irqsave+0x92/0xf0 arch/x86/include/asm/atomic.h:107 __pfx_gsmld_ioctl+0x10/0x10 drivers/tty/n_gsm.c:3822 [n_gsm] ktime_get+0x5e/0x140 kernel/time/timekeeping.c:195 ldsem_down_read+0x94/0x4e0 arch/x86/include/asm/atomic64_64.h:79 __pfx_ldsem_down_read+0x10/0x10 drivers/tty/tty_ldsem.c:338 __pfx_do_vfs_ioctl+0x10/0x10 fs/ioctl.c:805 tty_ioctl+0x643/0x1100 drivers/tty/tty_io.c:2818 Allocated by task 65: gsm_data_alloc.constprop.0+0x27/0x190 drivers/tty/n_gsm.c:926 [n_gsm] gsm_send+0x2c/0x580 drivers/tty/n_gsm.c:819 [n_gsm] gsm1_receive+0x547/0xad0 drivers/tty/n_gsm.c:3038 [n_gsm] gsmld_receive_buf+0x176/0x280 drivers/tty/n_gsm.c:3609 [n_gsm] tty_ldisc_receive_buf+0x101/0x1e0 drivers/tty/tty_buffer.c:391 tty_port_default_receive_buf+0x61/0xa0 drivers/tty/tty_port.c:39 flush_to_ldisc+0x1b0/0x750 drivers/tty/tty_buffer.c:445 process_scheduled_works+0x2b0/0x10d0 kernel/workqueue.c:3229 worker_thread+0x3dc/0x950 kernel/workqueue.c:3391 kthread+0x2a3/0x370 kernel/kthread.c:389 ret_from_fork+0x2d/0x70 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:257 Freed by task 3367: kfree+0x126/0x420 mm/slub.c:4580 gsm_cleanup_mux+0x36c/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] gsmld_ioctl+0x395/0x1450 drivers/tty/n_gsm.c:3408 [n_gsm] tty_ioctl+0x643/0x1100 drivers/tty/tty_io.c:2818 [Analysis] gsm_msg on the tx_ctrl_list or tx_data_list of gsm_mux can be freed by multi threads through ioctl,which leads to the occurrence of uaf. Protect it by gsm tx lock.(CVE-2024-50073)
In the Linux kernel, the following vulnerability has been resolved: unicode: Don't special case ignorable code points We don't need to handle them separately. Instead, just let them decompose/casefold to themselves.(CVE-2024-50089)
In the Linux kernel, the following vulnerability has been resolved: udf: fix uninit-value use in udf_get_fileshortad Check for overflow when computing alen in udf_current_aext to mitigate later uninit-value use in udf_get_fileshortad KMSAN bug[1]. After applying the patch reproducer did not trigger any issue[2]. [1] https://syzkaller.appspot.com/bug?extid=8901c4560b7ab5c2f9df [2] https://syzkaller.appspot.com/x/log.txt?x=10242227980000(CVE-2024-50143)
(CVE-2024-50151)
In the Linux kernel, the following vulnerability has been resolved: ceph: remove the incorrect Fw reference check when dirtying pages When doing the direct-io reads it will also try to mark pages dirty, but for the read path it won't hold the Fw caps and there is case will it get the Fw reference.(CVE-2024-50179)
In the Linux kernel, the following vulnerability has been resolved: fbdev: sisfb: Fix strbuf array overflow The values of the variables xres and yres are placed in strbuf. These variables are obtained from strbuf1. The strbuf1 array contains digit characters and a space if the array contains non-digit characters. Then, when executing sprintf(strbuf, "%ux%ux8", xres, yres); more than 16 bytes will be written to strbuf. It is suggested to increase the size of the strbuf array to 24. Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-50180)
In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v4: Don't allow a VMOVP on a dying VPE Kunkun Jiang reported that there is a small window of opportunity for userspace to force a change of affinity for a VPE while the VPE has already been unmapped, but the corresponding doorbell interrupt still visible in /proc/irq/. Plug the race by checking the value of vmapp_count, which tracks whether the VPE is mapped ot not, and returning an error in this case. This involves making vmapp_count common to both GICv4.1 and its v4.0 ancestor.(CVE-2024-50192)
In the Linux kernel, the following vulnerability has been resolved: nilfs2: propagate directory read errors from nilfs_find_entry() Syzbot reported that a task hang occurs in vcs_open() during a fuzzing test for nilfs2. The root cause of this problem is that in nilfs_find_entry(), which searches for directory entries, ignores errors when loading a directory page/folio via nilfs_get_folio() fails. If the filesystem images is corrupted, and the i_size of the directory inode is large, and the directory page/folio is successfully read but fails the sanity check, for example when it is zero-filled, nilfs_check_folio() may continue to spit out error messages in bursts. Fix this issue by propagating the error to the callers when loading a page/folio fails in nilfs_find_entry(). The current interface of nilfs_find_entry() and its callers is outdated and cannot propagate error codes such as -EIO and -ENOMEM returned via nilfs_find_entry(), so fix it together.(CVE-2024-50202)
In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire-lib: Avoid division by zero in apply_constraint_to_size() The step variable is initialized to zero. It is changed in the loop, but if it's not changed it will remain zero. Add a variable check before the division. The observed behavior was introduced by commit 826b5de90c0b ("ALSA: firewire-lib: fix insufficient PCM rule for period/buffer size"), and it is difficult to show that any of the interval parameters will satisfy the snd_interval_test() condition with data from the amdtp_rate_table[] table. Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-50205)
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential deadlock with newly created symlinks Syzbot reported that page_symlink(), called by nilfs_symlink(), triggers memory reclamation involving the filesystem layer, which can result in circular lock dependencies among the reader/writer semaphore nilfs->ns_segctor_sem, s_writers percpu_rwsem (intwrite) and the fs_reclaim pseudo lock. This is because after commit 21fc61c73c39 ("don't put symlink bodies in pagecache into highmem"), the gfp flags of the page cache for symbolic links are overwritten to GFP_KERNEL via inode_nohighmem(). This is not a problem for symlinks read from the backing device, because the __GFP_FS flag is dropped after inode_nohighmem() is called. However, when a new symlink is created with nilfs_symlink(), the gfp flags remain overwritten to GFP_KERNEL. Then, memory allocation called from page_symlink() etc. triggers memory reclamation including the FS layer, which may call nilfs_evict_inode() or nilfs_dirty_inode(). And these can cause a deadlock if they are called while nilfs->ns_segctor_sem is held: Fix this issue by dropping the __GFP_FS flag from the page cache GFP flags of newly created symlinks in the same way that nilfs_new_inode() and __nilfs_read_inode() do, as a workaround until we adopt nofs allocation scope consistently or improve the locking constraints.(CVE-2024-50229)
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix kernel bug due to missing clearing of checked flag Syzbot reported that in directory operations after nilfs2 detects filesystem corruption and degrades to read-only, __block_write_begin_int(), which is called to prepare block writes, may fail the BUG_ON check for accesses exceeding the folio/page size, triggering a kernel bug. This was found to be because the "checked" flag of a page/folio was not cleared when it was discarded by nilfs2's own routine, which causes the sanity check of directory entries to be skipped when the directory page/folio is reloaded. So, fix that. This was necessary when the use of nilfs2's own page discard routine was applied to more than just metadata files.(CVE-2024-50230)
In the Linux kernel, the following vulnerability has been resolved: NFSD: Initialize struct nfsd4_copy earlier Ensure the refcount and async_copies fields are initialized early. cleanup_async_copy() will reference these fields if an error occurs in nfsd4_copy(). If they are not correctly initialized, at the very least, a refcount underflow occurs.(CVE-2024-50241)
In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Additional check in ni_clear() Checking of NTFS_FLAGS_LOG_REPLAYING added to prevent access to uninitialized bitmap during replay process.(CVE-2024-50244)
In the Linux kernel, the following vulnerability has been resolved: ntfs3: Add bounds checking to mi_enum_attr() Added bounds checking to make sure that every attr don't stray beyond valid memory region.(CVE-2024-50248)
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix out-of-bounds write in trie_get_next_key() trie_get_next_key() allocates a node stack with size trie->max_prefixlen, while it writes (trie->max_prefixlen + 1) nodes to the stack when it has full paths from the root to leaves. For example, consider a trie with max_prefixlen is 8, and the nodes with key 0x00/0, 0x00/1, 0x00/2, ... 0x00/8 inserted. Subsequent calls to trie_get_next_key with _key with .prefixlen = 8 make 9 nodes be written on the node stack with size 8.(CVE-2024-50262)
In the Linux kernel, the following vulnerability has been resolved: ocfs2: remove entry once instead of null-ptr-dereference in ocfs2_xa_remove() Syzkaller is able to provoke null-ptr-dereference in ocfs2_xa_remove(): [ 57.319872] (a.out,1161,7):ocfs2_xa_remove:2028 ERROR: status = -12 [ 57.320420] (a.out,1161,7):ocfs2_xa_cleanup_value_truncate:1999 ERROR: Partial truncate while removing xattr overlay.upper. Leaking 1 clusters and removing the entry [ 57.321727] BUG: kernel NULL pointer dereference, address: 0000000000000004 [...] [ 57.325727] RIP: 0010:ocfs2_xa_block_wipe_namevalue+0x2a/0xc0 [...] [ 57.331328] Call Trace: [ 57.331477] <TASK> [...] [ 57.333511] ? do_user_addr_fault+0x3e5/0x740 [ 57.333778] ? exc_page_fault+0x70/0x170 [ 57.334016] ? asm_exc_page_fault+0x2b/0x30 [ 57.334263] ? __pfx_ocfs2_xa_block_wipe_namevalue+0x10/0x10 [ 57.334596] ? ocfs2_xa_block_wipe_namevalue+0x2a/0xc0 [ 57.334913] ocfs2_xa_remove_entry+0x23/0xc0 [ 57.335164] ocfs2_xa_set+0x704/0xcf0 [ 57.335381] ? _raw_spin_unlock+0x1a/0x40 [ 57.335620] ? ocfs2_inode_cache_unlock+0x16/0x20 [ 57.335915] ? trace_preempt_on+0x1e/0x70 [ 57.336153] ? start_this_handle+0x16c/0x500 [ 57.336410] ? preempt_count_sub+0x50/0x80 [ 57.336656] ? _raw_read_unlock+0x20/0x40 [ 57.336906] ? start_this_handle+0x16c/0x500 [ 57.337162] ocfs2_xattr_block_set+0xa6/0x1e0 [ 57.337424] __ocfs2_xattr_set_handle+0x1fd/0x5d0 [ 57.337706] ? ocfs2_start_trans+0x13d/0x290 [ 57.337971] ocfs2_xattr_set+0xb13/0xfb0 [ 57.338207] ? dput+0x46/0x1c0 [ 57.338393] ocfs2_xattr_trusted_set+0x28/0x30 [ 57.338665] ? ocfs2_xattr_trusted_set+0x28/0x30 [ 57.338948] __vfs_removexattr+0x92/0xc0 [ 57.339182] __vfs_removexattr_locked+0xd5/0x190 [ 57.339456] ? preempt_count_sub+0x50/0x80 [ 57.339705] vfs_removexattr+0x5f/0x100 [...] Reproducer uses faultinject facility to fail ocfs2_xa_remove() -> ocfs2_xa_value_truncate() with -ENOMEM. In this case the comment mentions that we can return 0 if ocfs2_xa_cleanup_value_truncate() is going to wipe the entry anyway. But the following 'rc' check is wrong and execution flow do 'ocfs2_xa_remove_entry(loc);' twice: * 1st: in ocfs2_xa_cleanup_value_truncate(); * 2nd: returning back to ocfs2_xa_remove() instead of going to 'out'. Fix this by skipping the 2nd removal of the same entry and making syzkaller repro happy.(CVE-2024-50265)
In the Linux kernel, the following vulnerability has been resolved: usb: musb: sunxi: Fix accessing an released usb phy Commit 6ed05c68cbca ("usb: musb: sunxi: Explicitly release USB PHY on exit") will cause that usb phy @glue->xceiv is accessed after released. 1) register platform driver @sunxi_musb_driver // get the usb phy @glue->xceiv sunxi_musb_probe() -> devm_usb_get_phy(). 2) register and unregister platform driver @musb_driver musb_probe() -> sunxi_musb_init() use the phy here //the phy is released here musb_remove() -> sunxi_musb_exit() -> devm_usb_put_phy() 3) register @musb_driver again musb_probe() -> sunxi_musb_init() use the phy here but the phy has been released at 2). ... Fixed by reverting the commit, namely, removing devm_usb_put_phy() from sunxi_musb_exit().(CVE-2024-50269)
In the Linux kernel, the following vulnerability has been resolved: btrfs: reinitialize delayed ref list after deleting it from the list At insert_delayed_ref() if we need to update the action of an existing ref to BTRFS_DROP_DELAYED_REF, we delete the ref from its ref head's ref_add_list using list_del(), which leaves the ref's add_list member not reinitialized, as list_del() sets the next and prev members of the list to LIST_POISON1 and LIST_POISON2, respectively. If later we end up calling drop_delayed_ref() against the ref, which can happen during merging or when destroying delayed refs due to a transaction abort, we can trigger a crash since at drop_delayed_ref() we call list_empty() against the ref's add_list, which returns false since the list was not reinitialized after the list_del() and as a consequence we call list_del() again at drop_delayed_ref(). This results in an invalid list access since the next and prev members are set to poison pointers, resulting in a splat if CONFIG_LIST_HARDENED and CONFIG_DEBUG_LIST are set or invalid poison pointer dereferences otherwise. So fix this by deleting from the list with list_del_init() instead.(CVE-2024-50273)
In the Linux kernel, the following vulnerability has been resolved: media: av7110: fix a spectre vulnerability As warned by smatch: drivers/staging/media/av7110/av7110_ca.c:270 dvb_ca_ioctl() warn: potential spectre issue 'av7110->ci_slot' [w] (local cap) There is a spectre-related vulnerability at the code. Fix it.(CVE-2024-50289)
In the Linux kernel, the following vulnerability has been resolved: io_uring/rw: fix missing NOWAIT check for O_DIRECT start write When io_uring starts a write, it'll call kiocb_start_write() to bump the super block rwsem, preventing any freezes from happening while that write is in-flight. The freeze side will grab that rwsem for writing, excluding any new writers from happening and waiting for existing writes to finish. But io_uring unconditionally uses kiocb_start_write(), which will block if someone is currently attempting to freeze the mount point. This causes a deadlock where freeze is waiting for previous writes to complete, but the previous writes cannot complete, as the task that is supposed to complete them is blocked waiting on starting a new write. This results in the following stuck trace showing that dependency with the write blocked starting a new write: task:fio state:D stack:0 pid:886 tgid:886 ppid:876 Call trace: __switch_to+0x1d8/0x348 __schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpu_rwsem_wait+0x1e8/0x3f8 __percpu_down_read+0xe8/0x500 io_write+0xbb8/0xff8 io_issue_sqe+0x10c/0x1020 io_submit_sqes+0x614/0x2110 __arm64_sys_io_uring_enter+0x524/0x1038 invoke_syscall+0x74/0x268 el0_svc_common.constprop.0+0x160/0x238 do_el0_svc+0x44/0x60 el0_svc+0x44/0xb0 el0t_64_sync_handler+0x118/0x128 el0t_64_sync+0x168/0x170 INFO: task fsfreeze:7364 blocked for more than 15 seconds. Not tainted 6.12.0-rc5-00063-g76aaf945701c #7963 with the attempting freezer stuck trying to grab the rwsem: task:fsfreeze state:D stack:0 pid:7364 tgid:7364 ppid:995 Call trace: __switch_to+0x1d8/0x348 __schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpu_down_write+0x2b0/0x680 freeze_super+0x248/0x8a8 do_vfs_ioctl+0x149c/0x1b18 __arm64_sys_ioctl+0xd0/0x1a0 invoke_syscall+0x74/0x268 el0_svc_common.constprop.0+0x160/0x238 do_el0_svc+0x44/0x60 el0_svc+0x44/0xb0 el0t_64_sync_handler+0x118/0x128 el0t_64_sync+0x168/0x170 Fix this by having the io_uring side honor IOCB_NOWAIT, and only attempt a blocking grab of the super block rwsem if it isn't set. For normal issue where IOCB_NOWAIT would always be set, this returns -EAGAIN which will have io_uring core issue a blocking attempt of the write. That will in turn also get completions run, ensuring forward progress. Since freezing requires CAP_SYS_ADMIN in the first place, this isn't something that can be triggered by a regular user.(CVE-2024-53052)
In the Linux kernel, the following vulnerability has been resolved: media: s5p-jpeg: prevent buffer overflows The current logic allows word to be less than 2. If this happens, there will be buffer overflows, as reported by smatch. Add extra checks to prevent it. While here, remove an unused word = 0 assignment.(CVE-2024-53061)
In the Linux kernel, the following vulnerability has been resolved: nfs: Fix KMSAN warning in decode_getfattr_attrs() Fix the following KMSAN warning: CPU: 1 UID: 0 PID: 7651 Comm: cp Tainted: G B Tainted: [B]=BAD_PAGE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) ===================================================== ===================================================== BUG: KMSAN: uninit-value in decode_getfattr_attrs+0x2d6d/0x2f90 decode_getfattr_attrs+0x2d6d/0x2f90 decode_getfattr_generic+0x806/0xb00 nfs4_xdr_dec_getattr+0x1de/0x240 rpcauth_unwrap_resp_decode+0xab/0x100 rpcauth_unwrap_resp+0x95/0xc0 call_decode+0x4ff/0xb50 __rpc_execute+0x57b/0x19d0 rpc_execute+0x368/0x5e0 rpc_run_task+0xcfe/0xee0 nfs4_proc_getattr+0x5b5/0x990 __nfs_revalidate_inode+0x477/0xd00 nfs_access_get_cached+0x1021/0x1cc0 nfs_do_access+0x9f/0xae0 nfs_permission+0x1e4/0x8c0 inode_permission+0x356/0x6c0 link_path_walk+0x958/0x1330 path_lookupat+0xce/0x6b0 filename_lookup+0x23e/0x770 vfs_statx+0xe7/0x970 vfs_fstatat+0x1f2/0x2c0 __se_sys_newfstatat+0x67/0x880 __x64_sys_newfstatat+0xbd/0x120 x64_sys_call+0x1826/0x3cf0 do_syscall_64+0xd0/0x1b0 entry_SYSCALL_64_after_hwframe+0x77/0x7f The KMSAN warning is triggered in decode_getfattr_attrs(), when calling decode_attr_mdsthreshold(). It appears that fattr->mdsthreshold is not initialized. Fix the issue by initializing fattr->mdsthreshold to NULL in nfs_fattr_init().(CVE-2024-53066)
| URL | Type | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"kernel-5.10.0-136.103.0.184.oe2203sp1.aarch64.rpm",
"kernel-debuginfo-5.10.0-136.103.0.184.oe2203sp1.aarch64.rpm",
"kernel-debugsource-5.10.0-136.103.0.184.oe2203sp1.aarch64.rpm",
"kernel-devel-5.10.0-136.103.0.184.oe2203sp1.aarch64.rpm",
"kernel-headers-5.10.0-136.103.0.184.oe2203sp1.aarch64.rpm",
"kernel-source-5.10.0-136.103.0.184.oe2203sp1.aarch64.rpm",
"kernel-tools-5.10.0-136.103.0.184.oe2203sp1.aarch64.rpm",
"kernel-tools-debuginfo-5.10.0-136.103.0.184.oe2203sp1.aarch64.rpm",
"kernel-tools-devel-5.10.0-136.103.0.184.oe2203sp1.aarch64.rpm",
"perf-5.10.0-136.103.0.184.oe2203sp1.aarch64.rpm",
"perf-debuginfo-5.10.0-136.103.0.184.oe2203sp1.aarch64.rpm",
"python3-perf-5.10.0-136.103.0.184.oe2203sp1.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-136.103.0.184.oe2203sp1.aarch64.rpm"
],
"src": [
"kernel-5.10.0-136.103.0.184.oe2203sp1.src.rpm"
],
"x86_64": [
"kernel-5.10.0-136.103.0.184.oe2203sp1.x86_64.rpm",
"kernel-debuginfo-5.10.0-136.103.0.184.oe2203sp1.x86_64.rpm",
"kernel-debugsource-5.10.0-136.103.0.184.oe2203sp1.x86_64.rpm",
"kernel-devel-5.10.0-136.103.0.184.oe2203sp1.x86_64.rpm",
"kernel-headers-5.10.0-136.103.0.184.oe2203sp1.x86_64.rpm",
"kernel-source-5.10.0-136.103.0.184.oe2203sp1.x86_64.rpm",
"kernel-tools-5.10.0-136.103.0.184.oe2203sp1.x86_64.rpm",
"kernel-tools-debuginfo-5.10.0-136.103.0.184.oe2203sp1.x86_64.rpm",
"kernel-tools-devel-5.10.0-136.103.0.184.oe2203sp1.x86_64.rpm",
"perf-5.10.0-136.103.0.184.oe2203sp1.x86_64.rpm",
"perf-debuginfo-5.10.0-136.103.0.184.oe2203sp1.x86_64.rpm",
"python3-perf-5.10.0-136.103.0.184.oe2203sp1.x86_64.rpm",
"python3-perf-debuginfo-5.10.0-136.103.0.184.oe2203sp1.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:22.03-LTS-SP1",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP1"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.10.0-136.103.0.184.oe2203sp1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: xen-netfront: Fix NULL sring after live migration A NAPI is setup for each network sring to poll data to kernel The sring with source host is destroyed before live migration and new sring with target host is setup after live migration. The NAPI for the old sring is not deleted until setup new sring with target host after migration. With busy_poll/busy_read enabled, the NAPI can be polled before got deleted when resume VM. BUG: unable to handle kernel NULL pointer dereference at 0000000000000008 IP: xennet_poll+0xae/0xd20 PGD 0 P4D 0 Oops: 0000 [#1] SMP PTI Call Trace: finish_task_switch+0x71/0x230 timerqueue_del+0x1d/0x40 hrtimer_try_to_cancel+0xb5/0x110 xennet_alloc_rx_buffers+0x2a0/0x2a0 napi_busy_loop+0xdb/0x270 sock_poll+0x87/0x90 do_sys_poll+0x26f/0x580 tracing_map_insert+0x1d4/0x2f0 event_hist_trigger+0x14a/0x260 finish_task_switch+0x71/0x230 __schedule+0x256/0x890 recalc_sigpending+0x1b/0x50 xen_sched_clock+0x15/0x20 __rb_reserve_next+0x12d/0x140 ring_buffer_lock_reserve+0x123/0x3d0 event_triggers_call+0x87/0xb0 trace_event_buffer_commit+0x1c4/0x210 xen_clocksource_get_cycles+0x15/0x20 ktime_get_ts64+0x51/0xf0 SyS_ppoll+0x160/0x1a0 SyS_ppoll+0x160/0x1a0 do_syscall_64+0x73/0x130 entry_SYSCALL_64_after_hwframe+0x41/0xa6 ... RIP: xennet_poll+0xae/0xd20 RSP: ffffb4f041933900 CR2: 0000000000000008 ---[ end trace f8601785b354351c ]--- xen frontend should remove the NAPIs for the old srings before live migration as the bond srings are destroyed There is a tiny window between the srings are set to NULL and the NAPIs are disabled, It is safe as the NAPI threads are still frozen at that time(CVE-2022-48969)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbonding: stop the device in bond_setup_by_slave()\r\n\r\nCommit 9eed321cde22 (\u0026quot;net: lapbether: only support ethernet devices\u0026quot;)\nhas been able to keep syzbot away from net/lapb, until today.\r\n\r\nIn the following splat [1], the issue is that a lapbether device has\nbeen created on a bonding device without members. Then adding a non\nARPHRD_ETHER member forced the bonding master to change its type.\r\n\r\nThe fix is to make sure we call dev_close() in bond_setup_by_slave()\nso that the potential linked lapbether devices (or any other devices\nhaving assumptions on the physical device) are removed.\r\n\r\nA similar bug has been addressed in commit 40baec225765\n(\u0026quot;bonding: fix panic on non-ARPHRD_ETHER enslave failure\u0026quot;)\r\n\r\n[1]\nskbuff: skb_under_panic: text:ffff800089508810 len:44 put:40 head:ffff0000c78e7c00 data:ffff0000c78e7bea tail:0x16 end:0x140 dev:bond0\nkernel BUG at net/core/skbuff.c:192 !\nInternal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP\nModules linked in:\nCPU: 0 PID: 6007 Comm: syz-executor383 Not tainted 6.6.0-rc3-syzkaller-gbf6547d8715b #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/04/2023\npstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : skb_panic net/core/skbuff.c:188 [inline]\npc : skb_under_panic+0x13c/0x140 net/core/skbuff.c:202\nlr : skb_panic net/core/skbuff.c:188 [inline]\nlr : skb_under_panic+0x13c/0x140 net/core/skbuff.c:202\nsp : ffff800096a06aa0\nx29: ffff800096a06ab0 x28: ffff800096a06ba0 x27: dfff800000000000\nx26: ffff0000ce9b9b50 x25: 0000000000000016 x24: ffff0000c78e7bea\nx23: ffff0000c78e7c00 x22: 000000000000002c x21: 0000000000000140\nx20: 0000000000000028 x19: ffff800089508810 x18: ffff800096a06100\nx17: 0000000000000000 x16: ffff80008a629a3c x15: 0000000000000001\nx14: 1fffe00036837a32 x13: 0000000000000000 x12: 0000000000000000\nx11: 0000000000000201 x10: 0000000000000000 x9 : cb50b496c519aa00\nx8 : cb50b496c519aa00 x7 : 0000000000000001 x6 : 0000000000000001\nx5 : ffff800096a063b8 x4 : ffff80008e280f80 x3 : ffff8000805ad11c\nx2 : 0000000000000001 x1 : 0000000100000201 x0 : 0000000000000086\nCall trace:\nskb_panic net/core/skbuff.c:188 [inline]\nskb_under_panic+0x13c/0x140 net/core/skbuff.c:202\nskb_push+0xf0/0x108 net/core/skbuff.c:2446\nip6gre_header+0xbc/0x738 net/ipv6/ip6_gre.c:1384\ndev_hard_header include/linux/netdevice.h:3136 [inline]\nlapbeth_data_transmit+0x1c4/0x298 drivers/net/wan/lapbether.c:257\nlapb_data_transmit+0x8c/0xb0 net/lapb/lapb_iface.c:447\nlapb_transmit_buffer+0x178/0x204 net/lapb/lapb_out.c:149\nlapb_send_control+0x220/0x320 net/lapb/lapb_subr.c:251\n__lapb_disconnect_request+0x9c/0x17c net/lapb/lapb_iface.c:326\nlapb_device_event+0x288/0x4e0 net/lapb/lapb_iface.c:492\nnotifier_call_chain+0x1a4/0x510 kernel/notifier.c:93\nraw_notifier_call_chain+0x3c/0x50 kernel/notifier.c:461\ncall_netdevice_notifiers_info net/core/dev.c:1970 [inline]\ncall_netdevice_notifiers_extack net/core/dev.c:2008 [inline]\ncall_netdevice_notifiers net/core/dev.c:2022 [inline]\n__dev_close_many+0x1b8/0x3c4 net/core/dev.c:1508\ndev_close_many+0x1e0/0x470 net/core/dev.c:1559\ndev_close+0x174/0x250 net/core/dev.c:1585\nlapbeth_device_event+0x2e4/0x958 drivers/net/wan/lapbether.c:466\nnotifier_call_chain+0x1a4/0x510 kernel/notifier.c:93\nraw_notifier_call_chain+0x3c/0x50 kernel/notifier.c:461\ncall_netdevice_notifiers_info net/core/dev.c:1970 [inline]\ncall_netdevice_notifiers_extack net/core/dev.c:2008 [inline]\ncall_netdevice_notifiers net/core/dev.c:2022 [inline]\n__dev_close_many+0x1b8/0x3c4 net/core/dev.c:1508\ndev_close_many+0x1e0/0x470 net/core/dev.c:1559\ndev_close+0x174/0x250 net/core/dev.c:1585\nbond_enslave+0x2298/0x30cc drivers/net/bonding/bond_main.c:2332\nbond_do_ioctl+0x268/0xc64 drivers/net/bonding/bond_main.c:4539\ndev_ifsioc+0x754/0x9ac\ndev_ioctl+0x4d8/0xd34 net/core/dev_ioctl.c:786\nsock_do_ioctl+0x1d4/0x2d0 net/socket.c:1217\nsock_ioctl+0x4e8/0x834 net/socket.c:1322\nvfs_ioctl fs/ioctl.c:51 [inline]\n__do_\n---truncated---(CVE-2023-52784)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nllc: verify mac len before reading mac header\r\n\r\nLLC reads the mac header with eth_hdr without verifying that the skb\nhas an Ethernet header.\r\n\r\nSyzbot was able to enter llc_rcv on a tun device. Tun can insert\npackets without mac len and with user configurable skb-\u0026gt;protocol\n(passing a tun_pi header when not configuring IFF_NO_PI).\r\n\r\n BUG: KMSAN: uninit-value in llc_station_ac_send_test_r net/llc/llc_station.c:81 [inline]\n BUG: KMSAN: uninit-value in llc_station_rcv+0x6fb/0x1290 net/llc/llc_station.c:111\n llc_station_ac_send_test_r net/llc/llc_station.c:81 [inline]\n llc_station_rcv+0x6fb/0x1290 net/llc/llc_station.c:111\n llc_rcv+0xc5d/0x14a0 net/llc/llc_input.c:218\n __netif_receive_skb_one_core net/core/dev.c:5523 [inline]\n __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5637\n netif_receive_skb_internal net/core/dev.c:5723 [inline]\n netif_receive_skb+0x58/0x660 net/core/dev.c:5782\n tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555\n tun_get_user+0x54c5/0x69c0 drivers/net/tun.c:2002\r\n\r\nAdd a mac_len test before all three eth_hdr(skb) calls under net/llc.\r\n\r\nThere are further uses in include/net/llc_pdu.h. All these are\nprotected by a test skb-\u0026gt;protocol == ETH_P_802_2. Which does not\nprotect against this tun scenario.\r\n\r\nBut the mac_len test added in this patch in llc_fixup_skb will\nindirectly protect those too. That is called from llc_rcv before any\nother LLC code.\r\n\r\nIt is tempting to just add a blanket mac_len check in llc_rcv, but\nnot sure whether that could break valid LLC paths that do not assume\nan Ethernet header. 802.2 LLC may be used on top of non-802.3\nprotocols in principle. The below referenced commit shows that used\nto, on top of Token Ring.\r\n\r\nAt least one of the three eth_hdr uses goes back to before the start\nof git history. But the one that syzbot exercises is introduced in\nthis commit. That commit is old enough (2008), that effectively all\nstable kernels should receive this.(CVE-2023-52843)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nSUNRPC: Fix UAF in svc_tcp_listen_data_ready()\r\n\r\nAfter the listener svc_sock is freed, and before invoking svc_tcp_accept()\nfor the established child sock, there is a window that the newsock\nretaining a freed listener svc_sock in sk_user_data which cloning from\nparent. In the race window, if data is received on the newsock, we will\nobserve use-after-free report in svc_tcp_listen_data_ready().\r\n\r\nReproduce by two tasks:\r\n\r\n1. while :; do rpc.nfsd 0 ; rpc.nfsd; done\n2. while :; do echo \u0026quot;\u0026quot; | ncat -4 127.0.0.1 2049 ; done\r\n\r\nKASAN report:\r\n\r\n ==================================================================\n BUG: KASAN: slab-use-after-free in svc_tcp_listen_data_ready+0x1cf/0x1f0 [sunrpc]\n Read of size 8 at addr ffff888139d96228 by task nc/102553\n CPU: 7 PID: 102553 Comm: nc Not tainted 6.3.0+ #18\n Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020\n Call Trace:\n \u0026lt;IRQ\u0026gt;\n dump_stack_lvl+0x33/0x50\n print_address_description.constprop.0+0x27/0x310\n print_report+0x3e/0x70\n kasan_report+0xae/0xe0\n svc_tcp_listen_data_ready+0x1cf/0x1f0 [sunrpc]\n tcp_data_queue+0x9f4/0x20e0\n tcp_rcv_established+0x666/0x1f60\n tcp_v4_do_rcv+0x51c/0x850\n tcp_v4_rcv+0x23fc/0x2e80\n ip_protocol_deliver_rcu+0x62/0x300\n ip_local_deliver_finish+0x267/0x350\n ip_local_deliver+0x18b/0x2d0\n ip_rcv+0x2fb/0x370\n __netif_receive_skb_one_core+0x166/0x1b0\n process_backlog+0x24c/0x5e0\n __napi_poll+0xa2/0x500\n net_rx_action+0x854/0xc90\n __do_softirq+0x1bb/0x5de\n do_softirq+0xcb/0x100\n \u0026lt;/IRQ\u0026gt;\n \u0026lt;TASK\u0026gt;\n ...\n \u0026lt;/TASK\u0026gt;\r\n\r\n Allocated by task 102371:\n kasan_save_stack+0x1e/0x40\n kasan_set_track+0x21/0x30\n __kasan_kmalloc+0x7b/0x90\n svc_setup_socket+0x52/0x4f0 [sunrpc]\n svc_addsock+0x20d/0x400 [sunrpc]\n __write_ports_addfd+0x209/0x390 [nfsd]\n write_ports+0x239/0x2c0 [nfsd]\n nfsctl_transaction_write+0xac/0x110 [nfsd]\n vfs_write+0x1c3/0xae0\n ksys_write+0xed/0x1c0\n do_syscall_64+0x38/0x90\n entry_SYSCALL_64_after_hwframe+0x72/0xdc\r\n\r\n Freed by task 102551:\n kasan_save_stack+0x1e/0x40\n kasan_set_track+0x21/0x30\n kasan_save_free_info+0x2a/0x50\n __kasan_slab_free+0x106/0x190\n __kmem_cache_free+0x133/0x270\n svc_xprt_free+0x1e2/0x350 [sunrpc]\n svc_xprt_destroy_all+0x25a/0x440 [sunrpc]\n nfsd_put+0x125/0x240 [nfsd]\n nfsd_svc+0x2cb/0x3c0 [nfsd]\n write_threads+0x1ac/0x2a0 [nfsd]\n nfsctl_transaction_write+0xac/0x110 [nfsd]\n vfs_write+0x1c3/0xae0\n ksys_write+0xed/0x1c0\n do_syscall_64+0x38/0x90\n entry_SYSCALL_64_after_hwframe+0x72/0xdc\r\n\r\nFix the UAF by simply doing nothing in svc_tcp_listen_data_ready()\nif state != TCP_LISTEN, that will avoid dereferencing svsk for all\nchild socket.(CVE-2023-52885)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nperf/aux: Fix AUX buffer serialization\r\n\r\nOle reported that event-\u0026gt;mmap_mutex is strictly insufficient to\nserialize the AUX buffer, add a per RB mutex to fully serialize it.\r\n\r\nNote that in the lock order comment the perf_event::mmap_mutex order\nwas already wrong, that is, it nesting under mmap_lock is not new with\nthis patch.(CVE-2024-46713)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix spin_unlock_irqrestore() called with IRQs enabled Fix missuse of spin_lock_irq()/spin_unlock_irq() when spin_lock_irqsave()/spin_lock_irqrestore() was hold. This was discovered through the lock debugging, and the corresponding log is as follows: raw_local_irq_restore() called with IRQs enabled WARNING: CPU: 96 PID: 2074 at kernel/locking/irqflag-debug.c:10 warn_bogus_irq_restore+0x30/0x40 ... Call trace: warn_bogus_irq_restore+0x30/0x40 _raw_spin_unlock_irqrestore+0x84/0xc8 add_qp_to_list+0x11c/0x148 [hns_roce_hw_v2] hns_roce_create_qp_common.constprop.0+0x240/0x780 [hns_roce_hw_v2] hns_roce_create_qp+0x98/0x160 [hns_roce_hw_v2] create_qp+0x138/0x258 ib_create_qp_kernel+0x50/0xe8 create_mad_qp+0xa8/0x128 ib_mad_port_open+0x218/0x448 ib_mad_init_device+0x70/0x1f8 add_client_context+0xfc/0x220 enable_device_and_get+0xd0/0x140 ib_register_device.part.0+0xf4/0x1c8 ib_register_device+0x34/0x50 hns_roce_register_device+0x174/0x3d0 [hns_roce_hw_v2] hns_roce_init+0xfc/0x2c0 [hns_roce_hw_v2] __hns_roce_hw_v2_init_instance+0x7c/0x1d0 [hns_roce_hw_v2] hns_roce_hw_v2_init_instance+0x9c/0x180 [hns_roce_hw_v2](CVE-2024-47735)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: mm: call the security_mmap_file() LSM hook in remap_file_pages() The remap_file_pages syscall handler calls do_mmap() directly, which doesn\u0026apos;t contain the LSM security check. And if the process has called personality(READ_IMPLIES_EXEC) before and remap_file_pages() is called for RW pages, this will actually result in remapping the pages to RWX, bypassing a W^X policy enforced by SELinux. So we should check prot by security_mmap_file LSM hook in the remap_file_pages syscall handler before do_mmap() is called. Otherwise, it potentially permits an attacker to bypass a W^X policy enforced by SELinux. The bypass is similar to CVE-2016-10044, which bypass the same thing via AIO and can be found in [1]. The PoC: $ cat \u0026gt; test.c int main(void) { size_t pagesz = sysconf(_SC_PAGE_SIZE); int mfd = syscall(SYS_memfd_create, \u0026quot;test\u0026quot;, 0); const char *buf = mmap(NULL, 4 * pagesz, PROT_READ | PROT_WRITE, MAP_SHARED, mfd, 0); unsigned int old = syscall(SYS_personality, 0xffffffff); syscall(SYS_personality, READ_IMPLIES_EXEC | old); syscall(SYS_remap_file_pages, buf, pagesz, 0, 2, 0); syscall(SYS_personality, old); // show the RWX page exists even if W^X policy is enforced int fd = open(\u0026quot;/proc/self/maps\u0026quot;, O_RDONLY); unsigned char buf2[1024]; while (1) { int ret = read(fd, buf2, 1024); if (ret \u0026lt;= 0) break; write(1, buf2, ret); } close(fd); } $ gcc test.c -o test $ ./test | grep rwx 7f1836c34000-7f1836c35000 rwxs 00002000 00:01 2050 /memfd:test (deleted) [PM: subject line tweaks](CVE-2024-47745)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: net: seeq: Fix use after free vulnerability in ether3 Driver Due to Race Condition In the ether3_probe function, a timer is initialized with a callback function ether3_ledoff, bound to \u0026amp;prev(dev)-\u0026gt;timer. Once the timer is started, there is a risk of a race condition if the module or device is removed, triggering the ether3_remove function to perform cleanup. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | ether3_ledoff ether3_remove | free_netdev(dev); | put_devic | kfree(dev); | | ether3_outw(priv(dev)-\u0026gt;regs.config2 |= CFG2_CTRLO, REG_CONFIG2); | // use dev Fix it by ensuring that the timer is canceled before proceeding with the cleanup in ether3_remove.(CVE-2024-47747)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: RDMA/cxgb4: Added NULL check for lookup_atid The lookup_atid() function can return NULL if the ATID is invalid or does not exist in the identifier table, which could lead to dereferencing a null pointer without a check in the `act_establish()` and `act_open_rpl()` functions. Add a NULL check to prevent null pointer dereferencing. Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-47749)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Initialize denominators\u0026apos; default to 1 [WHAT \u0026amp; HOW] Variables used as denominators and maybe not assigned to other values, should not be 0. Change their default to 1 so they are never 0. This fixes 10 DIVIDE_BY_ZERO issues reported by Coverity.(CVE-2024-49899)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: avoid NULL pointer dereference iwl_mvm_tx_skb_sta() and iwl_mvm_tx_mpdu() verify that the mvmvsta pointer is not NULL. It retrieves this pointer using iwl_mvm_sta_from_mac80211, which is dereferencing the ieee80211_sta pointer. If sta is NULL, iwl_mvm_sta_from_mac80211 will dereference a NULL pointer. Fix this by checking the sta pointer before retrieving the mvmsta from it. If sta is not NULL, then mvmsta isn\u0026apos;t either.(CVE-2024-49929)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: prevent nf_skb_duplicated corruption syzbot found that nf_dup_ipv4() or nf_dup_ipv6() could write per-cpu variable nf_skb_duplicated in an unsafe way [1]. Disabling preemption as hinted by the splat is not enough, we have to disable soft interrupts as well. [1] BUG: using __this_cpu_write() in preemptible [00000000] code: syz.4.282/6316 caller is nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87 CPU: 0 UID: 0 PID: 6316 Comm: syz.4.282 Not tainted 6.11.0-rc7-syzkaller-00104-g7052622fccb1 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Call Trace: \u0026lt;TASK\u0026gt; __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 check_preemption_disabled+0x10e/0x120 lib/smp_processor_id.c:49 nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87 nft_dup_ipv4_eval+0x1db/0x300 net/ipv4/netfilter/nft_dup_ipv4.c:30 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x4ad/0x1da0 net/netfilter/nf_tables_core.c:288 nft_do_chain_ipv4+0x202/0x320 net/netfilter/nft_chain_filter.c:23 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626 nf_hook+0x2c4/0x450 include/linux/netfilter.h:269 NF_HOOK_COND include/linux/netfilter.h:302 [inline] ip_output+0x185/0x230 net/ipv4/ip_output.c:433 ip_local_out net/ipv4/ip_output.c:129 [inline] ip_send_skb+0x74/0x100 net/ipv4/ip_output.c:1495 udp_send_skb+0xacf/0x1650 net/ipv4/udp.c:981 udp_sendmsg+0x1c21/0x2a60 net/ipv4/udp.c:1269 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x1a6/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2597 ___sys_sendmsg net/socket.c:2651 [inline] __sys_sendmmsg+0x3b2/0x740 net/socket.c:2737 __do_sys_sendmmsg net/socket.c:2766 [inline] __se_sys_sendmmsg net/socket.c:2763 [inline] __x64_sys_sendmmsg+0xa0/0xb0 net/socket.c:2763 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f4ce4f7def9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f4ce5d4a038 EFLAGS: 00000246 ORIG_RAX: 0000000000000133 RAX: ffffffffffffffda RBX: 00007f4ce5135f80 RCX: 00007f4ce4f7def9 RDX: 0000000000000001 RSI: 0000000020005d40 RDI: 0000000000000006 RBP: 00007f4ce4ff0b76 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f4ce5135f80 R15: 00007ffd4cbc6d68 \u0026lt;/TASK\u0026gt;(CVE-2024-49952)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: netfilter: xtables: avoid NFPROTO_UNSPEC where needed syzbot managed to call xt_cluster match via ebtables: WARNING: CPU: 0 PID: 11 at net/netfilter/xt_cluster.c:72 xt_cluster_mt+0x196/0x780 [..] ebt_do_table+0x174b/0x2a40 Module registers to NFPROTO_UNSPEC, but it assumes ipv4/ipv6 packet processing. As this is only useful to restrict locally terminating TCP/UDP traffic, register this for ipv4 and ipv6 family only. Pablo points out that this is a general issue, direct users of the set/getsockopt interface can call into targets/matches that were only intended for use with ip(6)tables. Check all UNSPEC matches and targets for similar issues: - matches and targets are fine except if they assume skb_network_header() is valid -- this is only true when called from inet layer: ip(6) stack pulls the ip/ipv6 header into linear data area. - targets that return XT_CONTINUE or other xtables verdicts must be restricted too, they are incompatbile with the ebtables traverser, e.g. EBT_CONTINUE is a completely different value than XT_CONTINUE. Most matches/targets are changed to register for NFPROTO_IPV4/IPV6, as they are provided for use by ip(6)tables. The MARK target is also used by arptables, so register for NFPROTO_ARP too. While at it, bail out if connbytes fails to enable the corresponding conntrack family. This change passes the selftests in iptables.git.(CVE-2024-50038)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: netfilter: br_netfilter: fix panic with metadata_dst skb Fix a kernel panic in the br_netfilter module when sending untagged traffic via a VxLAN device. This happens during the check for fragmentation in br_nf_dev_queue_xmit. It is dependent on: 1) the br_netfilter module being loaded; 2) net.bridge.bridge-nf-call-iptables set to 1; 3) a bridge with a VxLAN (single-vxlan-device) netdevice as a bridge port; 4) untagged frames with size higher than the VxLAN MTU forwarded/flooded When forwarding the untagged packet to the VxLAN bridge port, before the netfilter hooks are called, br_handle_egress_vlan_tunnel is called and changes the skb_dst to the tunnel dst. The tunnel_dst is a metadata type of dst, i.e., skb_valid_dst(skb) is false, and metadata-\u0026gt;dst.dev is NULL. Then in the br_netfilter hooks, in br_nf_dev_queue_xmit, there\u0026apos;s a check for frames that needs to be fragmented: frames with higher MTU than the VxLAN device end up calling br_nf_ip_fragment, which in turns call ip_skb_dst_mtu. The ip_dst_mtu tries to use the skb_dst(skb) as if it was a valid dst with valid dst-\u0026gt;dev, thus the crash. This case was never supported in the first place, so drop the packet instead. PING 10.0.0.2 (10.0.0.2) from 0.0.0.0 h1-eth0: 2000(2028) bytes of data. [ 176.291791] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000110 [ 176.292101] Mem abort info: [ 176.292184] ESR = 0x0000000096000004 [ 176.292322] EC = 0x25: DABT (current EL), IL = 32 bits [ 176.292530] SET = 0, FnV = 0 [ 176.292709] EA = 0, S1PTW = 0 [ 176.292862] FSC = 0x04: level 0 translation fault [ 176.293013] Data abort info: [ 176.293104] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 176.293488] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 176.293787] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 176.293995] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000043ef5000 [ 176.294166] [0000000000000110] pgd=0000000000000000, p4d=0000000000000000 [ 176.294827] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 176.295252] Modules linked in: vxlan ip6_udp_tunnel udp_tunnel veth br_netfilter bridge stp llc ipv6 crct10dif_ce [ 176.295923] CPU: 0 PID: 188 Comm: ping Not tainted 6.8.0-rc3-g5b3fbd61b9d1 #2 [ 176.296314] Hardware name: linux,dummy-virt (DT) [ 176.296535] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 176.296808] pc : br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter] [ 176.297382] lr : br_nf_dev_queue_xmit+0x2ac/0x4ec [br_netfilter] [ 176.297636] sp : ffff800080003630 [ 176.297743] x29: ffff800080003630 x28: 0000000000000008 x27: ffff6828c49ad9f8 [ 176.298093] x26: ffff6828c49ad000 x25: 0000000000000000 x24: 00000000000003e8 [ 176.298430] x23: 0000000000000000 x22: ffff6828c4960b40 x21: ffff6828c3b16d28 [ 176.298652] x20: ffff6828c3167048 x19: ffff6828c3b16d00 x18: 0000000000000014 [ 176.298926] x17: ffffb0476322f000 x16: ffffb7e164023730 x15: 0000000095744632 [ 176.299296] x14: ffff6828c3f1c880 x13: 0000000000000002 x12: ffffb7e137926a70 [ 176.299574] x11: 0000000000000001 x10: ffff6828c3f1c898 x9 : 0000000000000000 [ 176.300049] x8 : ffff6828c49bf070 x7 : 0008460f18d5f20e x6 : f20e0100bebafeca [ 176.300302] x5 : ffff6828c7f918fe x4 : ffff6828c49bf070 x3 : 0000000000000000 [ 176.300586] x2 : 0000000000000000 x1 : ffff6828c3c7ad00 x0 : ffff6828c7f918f0 [ 176.300889] Call trace: [ 176.301123] br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter] [ 176.301411] br_nf_post_routing+0x2a8/0x3e4 [br_netfilter] [ 176.301703] nf_hook_slow+0x48/0x124 [ 176.302060] br_forward_finish+0xc8/0xe8 [bridge] [ 176.302371] br_nf_hook_thresh+0x124/0x134 [br_netfilter] [ 176.302605] br_nf_forward_finish+0x118/0x22c [br_netfilter] [ 176.302824] br_nf_forward_ip.part.0+0x264/0x290 [br_netfilter] [ 176.303136] br_nf_forward+0x2b8/0x4e0 [br_netfilter] [ 176.303359] nf_hook_slow+0x48/0x124 [ 176.303 ---truncated---(CVE-2024-50045)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: RDMA/rtrs-srv: Avoid null pointer deref during path establishment For RTRS path establishment, RTRS client initiates and completes con_num of connections. After establishing all its connections, the information is exchanged between the client and server through the info_req message. During this exchange, it is essential that all connections have been established, and the state of the RTRS srv path is CONNECTED. So add these sanity checks, to make sure we detect and abort process in error scenarios to avoid null pointer deref.(CVE-2024-50062)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: tty: n_gsm: Fix use-after-free in gsm_cleanup_mux BUG: KASAN: slab-use-after-free in gsm_cleanup_mux+0x77b/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] Read of size 8 at addr ffff88815fe99c00 by task poc/3379 CPU: 0 UID: 0 PID: 3379 Comm: poc Not tainted 6.11.0+ #56 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 Call Trace: \u0026lt;TASK\u0026gt; gsm_cleanup_mux+0x77b/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] __pfx_gsm_cleanup_mux+0x10/0x10 drivers/tty/n_gsm.c:3124 [n_gsm] __pfx_sched_clock_cpu+0x10/0x10 kernel/sched/clock.c:389 update_load_avg+0x1c1/0x27b0 kernel/sched/fair.c:4500 __pfx_min_vruntime_cb_rotate+0x10/0x10 kernel/sched/fair.c:846 __rb_insert_augmented+0x492/0xbf0 lib/rbtree.c:161 gsmld_ioctl+0x395/0x1450 drivers/tty/n_gsm.c:3408 [n_gsm] _raw_spin_lock_irqsave+0x92/0xf0 arch/x86/include/asm/atomic.h:107 __pfx_gsmld_ioctl+0x10/0x10 drivers/tty/n_gsm.c:3822 [n_gsm] ktime_get+0x5e/0x140 kernel/time/timekeeping.c:195 ldsem_down_read+0x94/0x4e0 arch/x86/include/asm/atomic64_64.h:79 __pfx_ldsem_down_read+0x10/0x10 drivers/tty/tty_ldsem.c:338 __pfx_do_vfs_ioctl+0x10/0x10 fs/ioctl.c:805 tty_ioctl+0x643/0x1100 drivers/tty/tty_io.c:2818 Allocated by task 65: gsm_data_alloc.constprop.0+0x27/0x190 drivers/tty/n_gsm.c:926 [n_gsm] gsm_send+0x2c/0x580 drivers/tty/n_gsm.c:819 [n_gsm] gsm1_receive+0x547/0xad0 drivers/tty/n_gsm.c:3038 [n_gsm] gsmld_receive_buf+0x176/0x280 drivers/tty/n_gsm.c:3609 [n_gsm] tty_ldisc_receive_buf+0x101/0x1e0 drivers/tty/tty_buffer.c:391 tty_port_default_receive_buf+0x61/0xa0 drivers/tty/tty_port.c:39 flush_to_ldisc+0x1b0/0x750 drivers/tty/tty_buffer.c:445 process_scheduled_works+0x2b0/0x10d0 kernel/workqueue.c:3229 worker_thread+0x3dc/0x950 kernel/workqueue.c:3391 kthread+0x2a3/0x370 kernel/kthread.c:389 ret_from_fork+0x2d/0x70 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:257 Freed by task 3367: kfree+0x126/0x420 mm/slub.c:4580 gsm_cleanup_mux+0x36c/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] gsmld_ioctl+0x395/0x1450 drivers/tty/n_gsm.c:3408 [n_gsm] tty_ioctl+0x643/0x1100 drivers/tty/tty_io.c:2818 [Analysis] gsm_msg on the tx_ctrl_list or tx_data_list of gsm_mux can be freed by multi threads through ioctl,which leads to the occurrence of uaf. Protect it by gsm tx lock.(CVE-2024-50073)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: unicode: Don\u0026apos;t special case ignorable code points We don\u0026apos;t need to handle them separately. Instead, just let them decompose/casefold to themselves.(CVE-2024-50089)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: udf: fix uninit-value use in udf_get_fileshortad Check for overflow when computing alen in udf_current_aext to mitigate later uninit-value use in udf_get_fileshortad KMSAN bug[1]. After applying the patch reproducer did not trigger any issue[2]. [1] https://syzkaller.appspot.com/bug?extid=8901c4560b7ab5c2f9df [2] https://syzkaller.appspot.com/x/log.txt?x=10242227980000(CVE-2024-50143)\r\n\r\n(CVE-2024-50151)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: ceph: remove the incorrect Fw reference check when dirtying pages When doing the direct-io reads it will also try to mark pages dirty, but for the read path it won\u0026apos;t hold the Fw caps and there is case will it get the Fw reference.(CVE-2024-50179)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: fbdev: sisfb: Fix strbuf array overflow The values of the variables xres and yres are placed in strbuf. These variables are obtained from strbuf1. The strbuf1 array contains digit characters and a space if the array contains non-digit characters. Then, when executing sprintf(strbuf, \u0026quot;%ux%ux8\u0026quot;, xres, yres); more than 16 bytes will be written to strbuf. It is suggested to increase the size of the strbuf array to 24. Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-50180)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v4: Don\u0026apos;t allow a VMOVP on a dying VPE Kunkun Jiang reported that there is a small window of opportunity for userspace to force a change of affinity for a VPE while the VPE has already been unmapped, but the corresponding doorbell interrupt still visible in /proc/irq/. Plug the race by checking the value of vmapp_count, which tracks whether the VPE is mapped ot not, and returning an error in this case. This involves making vmapp_count common to both GICv4.1 and its v4.0 ancestor.(CVE-2024-50192)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: nilfs2: propagate directory read errors from nilfs_find_entry() Syzbot reported that a task hang occurs in vcs_open() during a fuzzing test for nilfs2. The root cause of this problem is that in nilfs_find_entry(), which searches for directory entries, ignores errors when loading a directory page/folio via nilfs_get_folio() fails. If the filesystem images is corrupted, and the i_size of the directory inode is large, and the directory page/folio is successfully read but fails the sanity check, for example when it is zero-filled, nilfs_check_folio() may continue to spit out error messages in bursts. Fix this issue by propagating the error to the callers when loading a page/folio fails in nilfs_find_entry(). The current interface of nilfs_find_entry() and its callers is outdated and cannot propagate error codes such as -EIO and -ENOMEM returned via nilfs_find_entry(), so fix it together.(CVE-2024-50202)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: ALSA: firewire-lib: Avoid division by zero in apply_constraint_to_size() The step variable is initialized to zero. It is changed in the loop, but if it\u0026apos;s not changed it will remain zero. Add a variable check before the division. The observed behavior was introduced by commit 826b5de90c0b (\u0026quot;ALSA: firewire-lib: fix insufficient PCM rule for period/buffer size\u0026quot;), and it is difficult to show that any of the interval parameters will satisfy the snd_interval_test() condition with data from the amdtp_rate_table[] table. Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-50205)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential deadlock with newly created symlinks Syzbot reported that page_symlink(), called by nilfs_symlink(), triggers memory reclamation involving the filesystem layer, which can result in circular lock dependencies among the reader/writer semaphore nilfs-\u0026gt;ns_segctor_sem, s_writers percpu_rwsem (intwrite) and the fs_reclaim pseudo lock. This is because after commit 21fc61c73c39 (\u0026quot;don\u0026apos;t put symlink bodies in pagecache into highmem\u0026quot;), the gfp flags of the page cache for symbolic links are overwritten to GFP_KERNEL via inode_nohighmem(). This is not a problem for symlinks read from the backing device, because the __GFP_FS flag is dropped after inode_nohighmem() is called. However, when a new symlink is created with nilfs_symlink(), the gfp flags remain overwritten to GFP_KERNEL. Then, memory allocation called from page_symlink() etc. triggers memory reclamation including the FS layer, which may call nilfs_evict_inode() or nilfs_dirty_inode(). And these can cause a deadlock if they are called while nilfs-\u0026gt;ns_segctor_sem is held: Fix this issue by dropping the __GFP_FS flag from the page cache GFP flags of newly created symlinks in the same way that nilfs_new_inode() and __nilfs_read_inode() do, as a workaround until we adopt nofs allocation scope consistently or improve the locking constraints.(CVE-2024-50229)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: nilfs2: fix kernel bug due to missing clearing of checked flag Syzbot reported that in directory operations after nilfs2 detects filesystem corruption and degrades to read-only, __block_write_begin_int(), which is called to prepare block writes, may fail the BUG_ON check for accesses exceeding the folio/page size, triggering a kernel bug. This was found to be because the \u0026quot;checked\u0026quot; flag of a page/folio was not cleared when it was discarded by nilfs2\u0026apos;s own routine, which causes the sanity check of directory entries to be skipped when the directory page/folio is reloaded. So, fix that. This was necessary when the use of nilfs2\u0026apos;s own page discard routine was applied to more than just metadata files.(CVE-2024-50230)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: NFSD: Initialize struct nfsd4_copy earlier Ensure the refcount and async_copies fields are initialized early. cleanup_async_copy() will reference these fields if an error occurs in nfsd4_copy(). If they are not correctly initialized, at the very least, a refcount underflow occurs.(CVE-2024-50241)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Additional check in ni_clear() Checking of NTFS_FLAGS_LOG_REPLAYING added to prevent access to uninitialized bitmap during replay process.(CVE-2024-50244)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: ntfs3: Add bounds checking to mi_enum_attr() Added bounds checking to make sure that every attr don\u0026apos;t stray beyond valid memory region.(CVE-2024-50248)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: bpf: Fix out-of-bounds write in trie_get_next_key() trie_get_next_key() allocates a node stack with size trie-\u0026gt;max_prefixlen, while it writes (trie-\u0026gt;max_prefixlen + 1) nodes to the stack when it has full paths from the root to leaves. For example, consider a trie with max_prefixlen is 8, and the nodes with key 0x00/0, 0x00/1, 0x00/2, ... 0x00/8 inserted. Subsequent calls to trie_get_next_key with _key with .prefixlen = 8 make 9 nodes be written on the node stack with size 8.(CVE-2024-50262)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: ocfs2: remove entry once instead of null-ptr-dereference in ocfs2_xa_remove() Syzkaller is able to provoke null-ptr-dereference in ocfs2_xa_remove(): [ 57.319872] (a.out,1161,7):ocfs2_xa_remove:2028 ERROR: status = -12 [ 57.320420] (a.out,1161,7):ocfs2_xa_cleanup_value_truncate:1999 ERROR: Partial truncate while removing xattr overlay.upper. Leaking 1 clusters and removing the entry [ 57.321727] BUG: kernel NULL pointer dereference, address: 0000000000000004 [...] [ 57.325727] RIP: 0010:ocfs2_xa_block_wipe_namevalue+0x2a/0xc0 [...] [ 57.331328] Call Trace: [ 57.331477] \u0026lt;TASK\u0026gt; [...] [ 57.333511] ? do_user_addr_fault+0x3e5/0x740 [ 57.333778] ? exc_page_fault+0x70/0x170 [ 57.334016] ? asm_exc_page_fault+0x2b/0x30 [ 57.334263] ? __pfx_ocfs2_xa_block_wipe_namevalue+0x10/0x10 [ 57.334596] ? ocfs2_xa_block_wipe_namevalue+0x2a/0xc0 [ 57.334913] ocfs2_xa_remove_entry+0x23/0xc0 [ 57.335164] ocfs2_xa_set+0x704/0xcf0 [ 57.335381] ? _raw_spin_unlock+0x1a/0x40 [ 57.335620] ? ocfs2_inode_cache_unlock+0x16/0x20 [ 57.335915] ? trace_preempt_on+0x1e/0x70 [ 57.336153] ? start_this_handle+0x16c/0x500 [ 57.336410] ? preempt_count_sub+0x50/0x80 [ 57.336656] ? _raw_read_unlock+0x20/0x40 [ 57.336906] ? start_this_handle+0x16c/0x500 [ 57.337162] ocfs2_xattr_block_set+0xa6/0x1e0 [ 57.337424] __ocfs2_xattr_set_handle+0x1fd/0x5d0 [ 57.337706] ? ocfs2_start_trans+0x13d/0x290 [ 57.337971] ocfs2_xattr_set+0xb13/0xfb0 [ 57.338207] ? dput+0x46/0x1c0 [ 57.338393] ocfs2_xattr_trusted_set+0x28/0x30 [ 57.338665] ? ocfs2_xattr_trusted_set+0x28/0x30 [ 57.338948] __vfs_removexattr+0x92/0xc0 [ 57.339182] __vfs_removexattr_locked+0xd5/0x190 [ 57.339456] ? preempt_count_sub+0x50/0x80 [ 57.339705] vfs_removexattr+0x5f/0x100 [...] Reproducer uses faultinject facility to fail ocfs2_xa_remove() -\u0026gt; ocfs2_xa_value_truncate() with -ENOMEM. In this case the comment mentions that we can return 0 if ocfs2_xa_cleanup_value_truncate() is going to wipe the entry anyway. But the following \u0026apos;rc\u0026apos; check is wrong and execution flow do \u0026apos;ocfs2_xa_remove_entry(loc);\u0026apos; twice: * 1st: in ocfs2_xa_cleanup_value_truncate(); * 2nd: returning back to ocfs2_xa_remove() instead of going to \u0026apos;out\u0026apos;. Fix this by skipping the 2nd removal of the same entry and making syzkaller repro happy.(CVE-2024-50265)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: usb: musb: sunxi: Fix accessing an released usb phy Commit 6ed05c68cbca (\u0026quot;usb: musb: sunxi: Explicitly release USB PHY on exit\u0026quot;) will cause that usb phy @glue-\u0026gt;xceiv is accessed after released. 1) register platform driver @sunxi_musb_driver // get the usb phy @glue-\u0026gt;xceiv sunxi_musb_probe() -\u0026gt; devm_usb_get_phy(). 2) register and unregister platform driver @musb_driver musb_probe() -\u0026gt; sunxi_musb_init() use the phy here //the phy is released here musb_remove() -\u0026gt; sunxi_musb_exit() -\u0026gt; devm_usb_put_phy() 3) register @musb_driver again musb_probe() -\u0026gt; sunxi_musb_init() use the phy here but the phy has been released at 2). ... Fixed by reverting the commit, namely, removing devm_usb_put_phy() from sunxi_musb_exit().(CVE-2024-50269)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: btrfs: reinitialize delayed ref list after deleting it from the list At insert_delayed_ref() if we need to update the action of an existing ref to BTRFS_DROP_DELAYED_REF, we delete the ref from its ref head\u0026apos;s ref_add_list using list_del(), which leaves the ref\u0026apos;s add_list member not reinitialized, as list_del() sets the next and prev members of the list to LIST_POISON1 and LIST_POISON2, respectively. If later we end up calling drop_delayed_ref() against the ref, which can happen during merging or when destroying delayed refs due to a transaction abort, we can trigger a crash since at drop_delayed_ref() we call list_empty() against the ref\u0026apos;s add_list, which returns false since the list was not reinitialized after the list_del() and as a consequence we call list_del() again at drop_delayed_ref(). This results in an invalid list access since the next and prev members are set to poison pointers, resulting in a splat if CONFIG_LIST_HARDENED and CONFIG_DEBUG_LIST are set or invalid poison pointer dereferences otherwise. So fix this by deleting from the list with list_del_init() instead.(CVE-2024-50273)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: media: av7110: fix a spectre vulnerability As warned by smatch: drivers/staging/media/av7110/av7110_ca.c:270 dvb_ca_ioctl() warn: potential spectre issue \u0026apos;av7110-\u0026gt;ci_slot\u0026apos; [w] (local cap) There is a spectre-related vulnerability at the code. Fix it.(CVE-2024-50289)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: io_uring/rw: fix missing NOWAIT check for O_DIRECT start write When io_uring starts a write, it\u0026apos;ll call kiocb_start_write() to bump the super block rwsem, preventing any freezes from happening while that write is in-flight. The freeze side will grab that rwsem for writing, excluding any new writers from happening and waiting for existing writes to finish. But io_uring unconditionally uses kiocb_start_write(), which will block if someone is currently attempting to freeze the mount point. This causes a deadlock where freeze is waiting for previous writes to complete, but the previous writes cannot complete, as the task that is supposed to complete them is blocked waiting on starting a new write. This results in the following stuck trace showing that dependency with the write blocked starting a new write: task:fio state:D stack:0 pid:886 tgid:886 ppid:876 Call trace: __switch_to+0x1d8/0x348 __schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpu_rwsem_wait+0x1e8/0x3f8 __percpu_down_read+0xe8/0x500 io_write+0xbb8/0xff8 io_issue_sqe+0x10c/0x1020 io_submit_sqes+0x614/0x2110 __arm64_sys_io_uring_enter+0x524/0x1038 invoke_syscall+0x74/0x268 el0_svc_common.constprop.0+0x160/0x238 do_el0_svc+0x44/0x60 el0_svc+0x44/0xb0 el0t_64_sync_handler+0x118/0x128 el0t_64_sync+0x168/0x170 INFO: task fsfreeze:7364 blocked for more than 15 seconds. Not tainted 6.12.0-rc5-00063-g76aaf945701c #7963 with the attempting freezer stuck trying to grab the rwsem: task:fsfreeze state:D stack:0 pid:7364 tgid:7364 ppid:995 Call trace: __switch_to+0x1d8/0x348 __schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpu_down_write+0x2b0/0x680 freeze_super+0x248/0x8a8 do_vfs_ioctl+0x149c/0x1b18 __arm64_sys_ioctl+0xd0/0x1a0 invoke_syscall+0x74/0x268 el0_svc_common.constprop.0+0x160/0x238 do_el0_svc+0x44/0x60 el0_svc+0x44/0xb0 el0t_64_sync_handler+0x118/0x128 el0t_64_sync+0x168/0x170 Fix this by having the io_uring side honor IOCB_NOWAIT, and only attempt a blocking grab of the super block rwsem if it isn\u0026apos;t set. For normal issue where IOCB_NOWAIT would always be set, this returns -EAGAIN which will have io_uring core issue a blocking attempt of the write. That will in turn also get completions run, ensuring forward progress. Since freezing requires CAP_SYS_ADMIN in the first place, this isn\u0026apos;t something that can be triggered by a regular user.(CVE-2024-53052)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: media: s5p-jpeg: prevent buffer overflows The current logic allows word to be less than 2. If this happens, there will be buffer overflows, as reported by smatch. Add extra checks to prevent it. While here, remove an unused word = 0 assignment.(CVE-2024-53061)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: nfs: Fix KMSAN warning in decode_getfattr_attrs() Fix the following KMSAN warning: CPU: 1 UID: 0 PID: 7651 Comm: cp Tainted: G B Tainted: [B]=BAD_PAGE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) ===================================================== ===================================================== BUG: KMSAN: uninit-value in decode_getfattr_attrs+0x2d6d/0x2f90 decode_getfattr_attrs+0x2d6d/0x2f90 decode_getfattr_generic+0x806/0xb00 nfs4_xdr_dec_getattr+0x1de/0x240 rpcauth_unwrap_resp_decode+0xab/0x100 rpcauth_unwrap_resp+0x95/0xc0 call_decode+0x4ff/0xb50 __rpc_execute+0x57b/0x19d0 rpc_execute+0x368/0x5e0 rpc_run_task+0xcfe/0xee0 nfs4_proc_getattr+0x5b5/0x990 __nfs_revalidate_inode+0x477/0xd00 nfs_access_get_cached+0x1021/0x1cc0 nfs_do_access+0x9f/0xae0 nfs_permission+0x1e4/0x8c0 inode_permission+0x356/0x6c0 link_path_walk+0x958/0x1330 path_lookupat+0xce/0x6b0 filename_lookup+0x23e/0x770 vfs_statx+0xe7/0x970 vfs_fstatat+0x1f2/0x2c0 __se_sys_newfstatat+0x67/0x880 __x64_sys_newfstatat+0xbd/0x120 x64_sys_call+0x1826/0x3cf0 do_syscall_64+0xd0/0x1b0 entry_SYSCALL_64_after_hwframe+0x77/0x7f The KMSAN warning is triggered in decode_getfattr_attrs(), when calling decode_attr_mdsthreshold(). It appears that fattr-\u0026gt;mdsthreshold is not initialized. Fix the issue by initializing fattr-\u0026gt;mdsthreshold to NULL in nfs_fattr_init().(CVE-2024-53066)",
"id": "OESA-2024-2491",
"modified": "2026-08-06T11:07:58Z",
"published": "2024-11-29T11:07:58Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2491"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48969"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52784"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52843"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52885"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46713"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47735"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47745"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47747"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47749"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49899"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49929"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49952"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50038"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50045"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50062"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50073"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50089"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50143"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50151"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50179"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50180"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50192"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50202"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50205"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50229"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50230"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50241"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50244"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50248"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50262"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50265"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50269"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50273"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50289"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53052"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53061"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53066"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2022-48969",
"CVE-2023-52784",
"CVE-2023-52843",
"CVE-2023-52885",
"CVE-2024-46713",
"CVE-2024-47735",
"CVE-2024-47745",
"CVE-2024-47747",
"CVE-2024-47749",
"CVE-2024-49899",
"CVE-2024-49929",
"CVE-2024-49952",
"CVE-2024-50038",
"CVE-2024-50045",
"CVE-2024-50062",
"CVE-2024-50073",
"CVE-2024-50089",
"CVE-2024-50143",
"CVE-2024-50151",
"CVE-2024-50179",
"CVE-2024-50180",
"CVE-2024-50192",
"CVE-2024-50202",
"CVE-2024-50205",
"CVE-2024-50229",
"CVE-2024-50230",
"CVE-2024-50241",
"CVE-2024-50244",
"CVE-2024-50248",
"CVE-2024-50262",
"CVE-2024-50265",
"CVE-2024-50269",
"CVE-2024-50273",
"CVE-2024-50289",
"CVE-2024-53052",
"CVE-2024-53061",
"CVE-2024-53066"
]
}
OESA-2024-2493 (CVE-2024-43817)
Vulnerability from osv_openeuler – Published: 2024-11-29 11:07 – Updated: 2026-08-06 11:07 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
net: missing check virtio
Two missing check in virtio_net_hdr_to_skb() allowed syzbot to crash kernels again
-
After the skb_segment function the buffer may become non-linear (nr_frags != 0), but since the SKBTX_SHARED_FRAG flag is not set anywhere the __skb_linearize function will not be executed, then the buffer will remain non-linear. Then the condition (offset >= skb_headlen(skb)) becomes true, which causes WARN_ON_ONCE in skb_checksum_help.
-
The struct sk_buff and struct virtio_net_hdr members must be mathematically related. (gso_size) must be greater than (needed) otherwise WARN_ON_ONCE. (remainder) must be greater than (needed) otherwise WARN_ON_ONCE. (remainder) may be 0 if division is without remainder.
offset+2 (4191) > skb_headlen() (1116) WARNING: CPU: 1 PID: 5084 at net/core/dev.c:3303 skb_checksum_help+0x5e2/0x740 net/core/dev.c:3303 Modules linked in: CPU: 1 PID: 5084 Comm: syz-executor336 Not tainted 6.7.0-rc3-syzkaller-00014-gdf60cee26a2e #0 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 11/10/2023 RIP: 0010:skb_checksum_help+0x5e2/0x740 net/core/dev.c:3303 Code: 89 e8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 52 01 00 00 44 89 e2 2b 53 74 4c 89 ee 48 c7 c7 40 57 e9 8b e8 af 8f dd f8 90 <0f> 0b 90 90 e9 87 fe ff ff e8 40 0f 6e f9 e9 4b fa ff ff 48 89 ef RSP: 0018:ffffc90003a9f338 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff888025125780 RCX: ffffffff814db209 RDX: ffff888015393b80 RSI: ffffffff814db216 RDI: 0000000000000001 RBP: ffff8880251257f4 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000001 R12: 000000000000045c R13: 000000000000105f R14: ffff8880251257f0 R15: 000000000000105d FS: 0000555555c24380(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000002000f000 CR3: 0000000023151000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ip_do_fragment+0xa1b/0x18b0 net/ipv4/ip_output.c:777 ip_fragment.constprop.0+0x161/0x230 net/ipv4/ip_output.c:584 ip_finish_output_gso net/ipv4/ip_output.c:286 [inline] __ip_finish_output net/ipv4/ip_output.c:308 [inline] __ip_finish_output+0x49c/0x650 net/ipv4/ip_output.c:295 ip_finish_output+0x31/0x310 net/ipv4/ip_output.c:323 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip_output+0x13b/0x2a0 net/ipv4/ip_output.c:433 dst_output include/net/dst.h:451 [inline] ip_local_out+0xaf/0x1a0 net/ipv4/ip_output.c:129 iptunnel_xmit+0x5b4/0x9b0 net/ipv4/ip_tunnel_core.c:82 ipip6_tunnel_xmit net/ipv6/sit.c:1034 [inline] sit_tunnel_xmit+0xed2/0x28f0 net/ipv6/sit.c:1076 __netdev_start_xmit include/linux/netdevice.h:4940 [inline] netdev_start_xmit include/linux/netdevice.h:4954 [inline] xmit_one net/core/dev.c:3545 [inline] dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3561 __dev_queue_xmit+0x7c1/0x3d60 net/core/dev.c:4346 dev_queue_xmit include/linux/netdevice.h:3134 [inline] packet_xmit+0x257/0x380 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3087 [inline] packet_sendmsg+0x24ca/0x5240 net/packet/af_packet.c:3119 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0xd5/0x180 net/socket.c:745 __sys_sendto+0x255/0x340 net/socket.c:2190 __do_sys_sendto net/socket.c:2202 [inline] __se_sys_sendto net/socket.c:2198 [inline] __x64_sys_sendto+0xe0/0x1b0 net/socket.c:2198 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x40/0x110 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x63/0x6b
Found by Linux Verification Center (linuxtesting.org) with Syzkaller(CVE-2024-43817)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: flowtable: initialise extack before use
Fix missing initialisation of extack in flow offload.(CVE-2024-45018)
In the Linux kernel, the following vulnerability has been resolved:
perf/aux: Fix AUX buffer serialization
Ole reported that event->mmap_mutex is strictly insufficient to serialize the AUX buffer, add a per RB mutex to fully serialize it.
Note that in the lock order comment the perf_event::mmap_mutex order was already wrong, that is, it nesting under mmap_lock is not new with this patch.(CVE-2024-46713)
In the Linux kernel, the following vulnerability has been resolved: mm: call the security_mmap_file() LSM hook in remap_file_pages() The remap_file_pages syscall handler calls do_mmap() directly, which doesn't contain the LSM security check. And if the process has called personality(READ_IMPLIES_EXEC) before and remap_file_pages() is called for RW pages, this will actually result in remapping the pages to RWX, bypassing a W^X policy enforced by SELinux. So we should check prot by security_mmap_file LSM hook in the remap_file_pages syscall handler before do_mmap() is called. Otherwise, it potentially permits an attacker to bypass a W^X policy enforced by SELinux. The bypass is similar to CVE-2016-10044, which bypass the same thing via AIO and can be found in [1]. The PoC: $ cat > test.c int main(void) { size_t pagesz = sysconf(_SC_PAGE_SIZE); int mfd = syscall(SYS_memfd_create, "test", 0); const char *buf = mmap(NULL, 4 * pagesz, PROT_READ | PROT_WRITE, MAP_SHARED, mfd, 0); unsigned int old = syscall(SYS_personality, 0xffffffff); syscall(SYS_personality, READ_IMPLIES_EXEC | old); syscall(SYS_remap_file_pages, buf, pagesz, 0, 2, 0); syscall(SYS_personality, old); // show the RWX page exists even if W^X policy is enforced int fd = open("/proc/self/maps", O_RDONLY); unsigned char buf2[1024]; while (1) { int ret = read(fd, buf2, 1024); if (ret <= 0) break; write(1, buf2, ret); } close(fd); } $ gcc test.c -o test $ ./test | grep rwx 7f1836c34000-7f1836c35000 rwxs 00002000 00:01 2050 /memfd:test (deleted) PM: subject line tweaks
In the Linux kernel, the following vulnerability has been resolved: net: seeq: Fix use after free vulnerability in ether3 Driver Due to Race Condition In the ether3_probe function, a timer is initialized with a callback function ether3_ledoff, bound to &prev(dev)->timer. Once the timer is started, there is a risk of a race condition if the module or device is removed, triggering the ether3_remove function to perform cleanup. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | ether3_ledoff ether3_remove | free_netdev(dev); | put_devic | kfree(dev); | | ether3_outw(priv(dev)->regs.config2 |= CFG2_CTRLO, REG_CONFIG2); | // use dev Fix it by ensuring that the timer is canceled before proceeding with the cleanup in ether3_remove.(CVE-2024-47747)
In the Linux kernel, the following vulnerability has been resolved: RDMA/cxgb4: Added NULL check for lookup_atid The lookup_atid() function can return NULL if the ATID is invalid or does not exist in the identifier table, which could lead to dereferencing a null pointer without a check in the act_establish() and act_open_rpl() functions. Add a NULL check to prevent null pointer dereferencing. Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-47749)
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Initialize denominators' default to 1 [WHAT & HOW] Variables used as denominators and maybe not assigned to other values, should not be 0. Change their default to 1 so they are never 0. This fixes 10 DIVIDE_BY_ZERO issues reported by Coverity.(CVE-2024-49899)
In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: avoid NULL pointer dereference iwl_mvm_tx_skb_sta() and iwl_mvm_tx_mpdu() verify that the mvmvsta pointer is not NULL. It retrieves this pointer using iwl_mvm_sta_from_mac80211, which is dereferencing the ieee80211_sta pointer. If sta is NULL, iwl_mvm_sta_from_mac80211 will dereference a NULL pointer. Fix this by checking the sta pointer before retrieving the mvmsta from it. If sta is not NULL, then mvmsta isn't either.(CVE-2024-49929)
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: prevent nf_skb_duplicated corruption syzbot found that nf_dup_ipv4() or nf_dup_ipv6() could write per-cpu variable nf_skb_duplicated in an unsafe way [1]. Disabling preemption as hinted by the splat is not enough, we have to disable soft interrupts as well. [1] BUG: using __this_cpu_write() in preemptible [00000000] code: syz.4.282/6316 caller is nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87 CPU: 0 UID: 0 PID: 6316 Comm: syz.4.282 Not tainted 6.11.0-rc7-syzkaller-00104-g7052622fccb1 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 check_preemption_disabled+0x10e/0x120 lib/smp_processor_id.c:49 nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87 nft_dup_ipv4_eval+0x1db/0x300 net/ipv4/netfilter/nft_dup_ipv4.c:30 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x4ad/0x1da0 net/netfilter/nf_tables_core.c:288 nft_do_chain_ipv4+0x202/0x320 net/netfilter/nft_chain_filter.c:23 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626 nf_hook+0x2c4/0x450 include/linux/netfilter.h:269 NF_HOOK_COND include/linux/netfilter.h:302 [inline] ip_output+0x185/0x230 net/ipv4/ip_output.c:433 ip_local_out net/ipv4/ip_output.c:129 [inline] ip_send_skb+0x74/0x100 net/ipv4/ip_output.c:1495 udp_send_skb+0xacf/0x1650 net/ipv4/udp.c:981 udp_sendmsg+0x1c21/0x2a60 net/ipv4/udp.c:1269 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x1a6/0x270 net/socket.c:745 _syssendmsg+0x525/0x7d0 net/socket.c:2597 _sys_sendmsg net/socket.c:2651 [inline] __sys_sendmmsg+0x3b2/0x740 net/socket.c:2737 __do_sys_sendmmsg net/socket.c:2766 [inline] __se_sys_sendmmsg net/socket.c:2763 [inline] __x64_sys_sendmmsg+0xa0/0xb0 net/socket.c:2763 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f4ce4f7def9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f4ce5d4a038 EFLAGS: 00000246 ORIG_RAX: 0000000000000133 RAX: ffffffffffffffda RBX: 00007f4ce5135f80 RCX: 00007f4ce4f7def9 RDX: 0000000000000001 RSI: 0000000020005d40 RDI: 0000000000000006 RBP: 00007f4ce4ff0b76 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f4ce5135f80 R15: 00007ffd4cbc6d68 </TASK>(CVE-2024-49952)
In the Linux kernel, the following vulnerability has been resolved: netfilter: br_netfilter: fix panic with metadata_dst skb Fix a kernel panic in the br_netfilter module when sending untagged traffic via a VxLAN device. This happens during the check for fragmentation in br_nf_dev_queue_xmit. It is dependent on: 1) the br_netfilter module being loaded; 2) net.bridge.bridge-nf-call-iptables set to 1; 3) a bridge with a VxLAN (single-vxlan-device) netdevice as a bridge port; 4) untagged frames with size higher than the VxLAN MTU forwarded/flooded When forwarding the untagged packet to the VxLAN bridge port, before the netfilter hooks are called, br_handle_egress_vlan_tunnel is called and changes the skb_dst to the tunnel dst. The tunnel_dst is a metadata type of dst, i.e., skb_valid_dst(skb) is false, and metadata->dst.dev is NULL. Then in the br_netfilter hooks, in br_nf_dev_queue_xmit, there's a check for frames that needs to be fragmented: frames with higher MTU than the VxLAN device end up calling br_nf_ip_fragment, which in turns call ip_skb_dst_mtu. The ip_dst_mtu tries to use the skb_dst(skb) as if it was a valid dst with valid dst->dev, thus the crash. This case was never supported in the first place, so drop the packet instead. PING 10.0.0.2 (10.0.0.2) from 0.0.0.0 h1-eth0: 2000(2028) bytes of data. [ 176.291791] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000110 [ 176.292101] Mem abort info: [ 176.292184] ESR = 0x0000000096000004 [ 176.292322] EC = 0x25: DABT (current EL), IL = 32 bits [ 176.292530] SET = 0, FnV = 0 [ 176.292709] EA = 0, S1PTW = 0 [ 176.292862] FSC = 0x04: level 0 translation fault [ 176.293013] Data abort info: [ 176.293104] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 176.293488] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 176.293787] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 176.293995] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000043ef5000 [ 176.294166] [0000000000000110] pgd=0000000000000000, p4d=0000000000000000 [ 176.294827] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 176.295252] Modules linked in: vxlan ip6_udp_tunnel udp_tunnel veth br_netfilter bridge stp llc ipv6 crct10dif_ce [ 176.295923] CPU: 0 PID: 188 Comm: ping Not tainted 6.8.0-rc3-g5b3fbd61b9d1 #2 [ 176.296314] Hardware name: linux,dummy-virt (DT) [ 176.296535] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 176.296808] pc : br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter] [ 176.297382] lr : br_nf_dev_queue_xmit+0x2ac/0x4ec [br_netfilter] [ 176.297636] sp : ffff800080003630 [ 176.297743] x29: ffff800080003630 x28: 0000000000000008 x27: ffff6828c49ad9f8 [ 176.298093] x26: ffff6828c49ad000 x25: 0000000000000000 x24: 00000000000003e8 [ 176.298430] x23: 0000000000000000 x22: ffff6828c4960b40 x21: ffff6828c3b16d28 [ 176.298652] x20: ffff6828c3167048 x19: ffff6828c3b16d00 x18: 0000000000000014 [ 176.298926] x17: ffffb0476322f000 x16: ffffb7e164023730 x15: 0000000095744632 [ 176.299296] x14: ffff6828c3f1c880 x13: 0000000000000002 x12: ffffb7e137926a70 [ 176.299574] x11: 0000000000000001 x10: ffff6828c3f1c898 x9 : 0000000000000000 [ 176.300049] x8 : ffff6828c49bf070 x7 : 0008460f18d5f20e x6 : f20e0100bebafeca [ 176.300302] x5 : ffff6828c7f918fe x4 : ffff6828c49bf070 x3 : 0000000000000000 [ 176.300586] x2 : 0000000000000000 x1 : ffff6828c3c7ad00 x0 : ffff6828c7f918f0 [ 176.300889] Call trace: [ 176.301123] br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter] [ 176.301411] br_nf_post_routing+0x2a8/0x3e4 [br_netfilter] [ 176.301703] nf_hook_slow+0x48/0x124 [ 176.302060] br_forward_finish+0xc8/0xe8 [bridge] [ 176.302371] br_nf_hook_thresh+0x124/0x134 [br_netfilter] [ 176.302605] br_nf_forward_finish+0x118/0x22c [br_netfilter] [ 176.302824] br_nf_forward_ip.part.0+0x264/0x290 [br_netfilter] [ 176.303136] br_nf_forward+0x2b8/0x4e0 [br_netfilter] [ 176.303359] nf_hook_slow+0x48/0x124 [ 176.303 ---truncated---(CVE-2024-50045)
In the Linux kernel, the following vulnerability has been resolved: RDMA/rtrs-srv: Avoid null pointer deref during path establishment For RTRS path establishment, RTRS client initiates and completes con_num of connections. After establishing all its connections, the information is exchanged between the client and server through the info_req message. During this exchange, it is essential that all connections have been established, and the state of the RTRS srv path is CONNECTED. So add these sanity checks, to make sure we detect and abort process in error scenarios to avoid null pointer deref.(CVE-2024-50062)
In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: fix UaF read in mptcp_pm_nl_rm_addr_or_subflow Syzkaller reported this splat: ================================================================== BUG: KASAN: slab-use-after-free in mptcp_pm_nl_rm_addr_or_subflow+0xb44/0xcc0 net/mptcp/pm_netlink.c:881 Read of size 4 at addr ffff8880569ac858 by task syz.1.2799/14662 CPU: 0 UID: 0 PID: 14662 Comm: syz.1.2799 Not tainted 6.12.0-rc2-syzkaller-00307-g36c254515dc6 #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc3/0x620 mm/kasan/report.c:488 kasan_report+0xd9/0x110 mm/kasan/report.c:601 mptcp_pm_nl_rm_addr_or_subflow+0xb44/0xcc0 net/mptcp/pm_netlink.c:881 mptcp_pm_nl_rm_subflow_received net/mptcp/pm_netlink.c:914 [inline] mptcp_nl_remove_id_zero_address+0x305/0x4a0 net/mptcp/pm_netlink.c:1572 mptcp_pm_nl_del_addr_doit+0x5c9/0x770 net/mptcp/pm_netlink.c:1603 genl_family_rcv_msg_doit+0x202/0x2f0 net/netlink/genetlink.c:1115 genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0x565/0x800 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x165/0x410 net/netlink/af_netlink.c:2551 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1331 [inline] netlink_unicast+0x53c/0x7f0 net/netlink/af_netlink.c:1357 netlink_sendmsg+0x8b8/0xd70 net/netlink/af_netlink.c:1901 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg net/socket.c:744 [inline] _syssendmsg+0x9ae/0xb40 net/socket.c:2607 _sys_sendmsg+0x135/0x1e0 net/socket.c:2661 __sys_sendmsg+0x117/0x1f0 net/socket.c:2690 do_syscall_32_irqs_on arch/x86/entry/common.c:165 [inline] __do_fast_syscall_32+0x73/0x120 arch/x86/entry/common.c:386 do_fast_syscall_32+0x32/0x80 arch/x86/entry/common.c:411 entry_SYSENTER_compat_after_hwframe+0x84/0x8e RIP: 0023:0xf7fe4579 Code: b8 01 10 06 03 74 b4 01 10 07 03 74 b0 01 10 08 03 74 d8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90 90 90 8d b4 26 00 00 00 00 8d b4 26 00 00 00 00 RSP: 002b:00000000f574556c EFLAGS: 00000296 ORIG_RAX: 0000000000000172 RAX: ffffffffffffffda RBX: 000000000000000b RCX: 0000000020000140 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000296 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 </TASK> Allocated by task 5387: kasan_save_stack+0x33/0x60 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:394 kmalloc_noprof include/linux/slab.h:878 [inline] kzalloc_noprof include/linux/slab.h:1014 [inline] subflow_create_ctx+0x87/0x2a0 net/mptcp/subflow.c:1803 subflow_ulp_init+0xc3/0x4d0 net/mptcp/subflow.c:1956 __tcp_set_ulp net/ipv4/tcp_ulp.c:146 [inline] tcp_set_ulp+0x326/0x7f0 net/ipv4/tcp_ulp.c:167 mptcp_subflow_create_socket+0x4ae/0x10a0 net/mptcp/subflow.c:1764 __mptcp_subflow_connect+0x3cc/0x1490 net/mptcp/subflow.c:1592 mptcp_pm_create_subflow_or_signal_addr+0xbda/0x23a0 net/mptcp/pm_netlink.c:642 mptcp_pm_nl_fully_established net/mptcp/pm_netlink.c:650 [inline] mptcp_pm_nl_work+0x3a1/0x4f0 net/mptcp/pm_netlink.c:943 mptcp_worker+0x15a/0x1240 net/mptcp/protocol.c:2777 process_one_work+0x958/0x1b30 kernel/workqueue.c:3229 process_scheduled_works kernel/workqueue.c:3310 [inline] worker_thread+0x6c8/0xf00 kernel/workqueue.c:3391 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/ke ---truncated---(CVE-2024-50085)
In the Linux kernel, the following vulnerability has been resolved: unicode: Don't special case ignorable code points We don't need to handle them separately. Instead, just let them decompose/casefold to themselves.(CVE-2024-50089)
In the Linux kernel, the following vulnerability has been resolved: ACPI: PRM: Find EFI_MEMORY_RUNTIME block for PRM handler and context PRMT needs to find the correct type of block to translate the PA-VA mapping for EFI runtime services. The issue arises because the PRMT is finding a block of type EFI_CONVENTIONAL_MEMORY, which is not appropriate for runtime services as described in Section 2.2.2 (Runtime Services) of the UEFI Specification [1]. Since the PRM handler is a type of runtime service, this causes an exception when the PRM handler is called. [Firmware Bug]: Unable to handle paging request in EFI runtime service WARNING: CPU: 22 PID: 4330 at drivers/firmware/efi/runtime-wrappers.c:341 __efi_queue_work+0x11c/0x170 Call trace: Let PRMT find a block with EFI_MEMORY_RUNTIME for PRM handler and PRM context. If no suitable block is found, a warning message will be printed, but the procedure continues to manage the next PRM handler. However, if the PRM handler is actually called without proper allocation, it would result in a failure during error handling. By using the correct memory types for runtime services, ensure that the PRM handler and the context are properly mapped in the virtual address space during runtime, preventing the paging request error. The issue is really that only memory that has been remapped for runtime by the firmware can be used by the PRM handler, and so the region needs to have the EFI_MEMORY_RUNTIME attribute. rjw: Subject and changelog edits
In the Linux kernel, the following vulnerability has been resolved: udf: fix uninit-value use in udf_get_fileshortad Check for overflow when computing alen in udf_current_aext to mitigate later uninit-value use in udf_get_fileshortad KMSAN bug[1]. After applying the patch reproducer did not trigger any issue[2]. [1] https://syzkaller.appspot.com/bug?extid=8901c4560b7ab5c2f9df [2] https://syzkaller.appspot.com/x/log.txt?x=10242227980000(CVE-2024-50143)
In the Linux kernel, the following vulnerability has been resolved: ceph: remove the incorrect Fw reference check when dirtying pages When doing the direct-io reads it will also try to mark pages dirty, but for the read path it won't hold the Fw caps and there is case will it get the Fw reference.(CVE-2024-50179)
In the Linux kernel, the following vulnerability has been resolved: fbdev: sisfb: Fix strbuf array overflow The values of the variables xres and yres are placed in strbuf. These variables are obtained from strbuf1. The strbuf1 array contains digit characters and a space if the array contains non-digit characters. Then, when executing sprintf(strbuf, "%ux%ux8", xres, yres); more than 16 bytes will be written to strbuf. It is suggested to increase the size of the strbuf array to 24. Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-50180)
In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v4: Don't allow a VMOVP on a dying VPE Kunkun Jiang reported that there is a small window of opportunity for userspace to force a change of affinity for a VPE while the VPE has already been unmapped, but the corresponding doorbell interrupt still visible in /proc/irq/. Plug the race by checking the value of vmapp_count, which tracks whether the VPE is mapped ot not, and returning an error in this case. This involves making vmapp_count common to both GICv4.1 and its v4.0 ancestor.(CVE-2024-50192)
In the Linux kernel, the following vulnerability has been resolved: posix-clock: Fix missing timespec64 check in pc_clock_settime() As Andrew pointed out, it will make sense that the PTP core checked timespec64 struct's tv_sec and tv_nsec range before calling ptp->info->settime64(). As the man manual of clock_settime() said, if tp.tv_sec is negative or tp.tv_nsec is outside the range [0..999,999,999], it should return EINVAL, which include dynamic clocks which handles PTP clock, and the condition is consistent with timespec64_valid(). As Thomas suggested, timespec64_valid() only check the timespec is valid, but not ensure that the time is in a valid range, so check it ahead using timespec64_valid_strict() in pc_clock_settime() and return -EINVAL if not valid. There are some drivers that use tp->tv_sec and tp->tv_nsec directly to write registers without validity checks and assume that the higher layer has checked it, which is dangerous and will benefit from this, such as hclge_ptp_settime(), igb_ptp_settime_i210(), _rcar_gen4_ptp_settime(), and some drivers can remove the checks of itself.(CVE-2024-50195)
In the Linux kernel, the following vulnerability has been resolved: nilfs2: propagate directory read errors from nilfs_find_entry() Syzbot reported that a task hang occurs in vcs_open() during a fuzzing test for nilfs2. The root cause of this problem is that in nilfs_find_entry(), which searches for directory entries, ignores errors when loading a directory page/folio via nilfs_get_folio() fails. If the filesystem images is corrupted, and the i_size of the directory inode is large, and the directory page/folio is successfully read but fails the sanity check, for example when it is zero-filled, nilfs_check_folio() may continue to spit out error messages in bursts. Fix this issue by propagating the error to the callers when loading a page/folio fails in nilfs_find_entry(). The current interface of nilfs_find_entry() and its callers is outdated and cannot propagate error codes such as -EIO and -ENOMEM returned via nilfs_find_entry(), so fix it together.(CVE-2024-50202)
In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire-lib: Avoid division by zero in apply_constraint_to_size() The step variable is initialized to zero. It is changed in the loop, but if it's not changed it will remain zero. Add a variable check before the division. The observed behavior was introduced by commit 826b5de90c0b ("ALSA: firewire-lib: fix insufficient PCM rule for period/buffer size"), and it is difficult to show that any of the interval parameters will satisfy the snd_interval_test() condition with data from the amdtp_rate_table[] table. Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-50205)
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential deadlock with newly created symlinks Syzbot reported that page_symlink(), called by nilfs_symlink(), triggers memory reclamation involving the filesystem layer, which can result in circular lock dependencies among the reader/writer semaphore nilfs->ns_segctor_sem, s_writers percpu_rwsem (intwrite) and the fs_reclaim pseudo lock. This is because after commit 21fc61c73c39 ("don't put symlink bodies in pagecache into highmem"), the gfp flags of the page cache for symbolic links are overwritten to GFP_KERNEL via inode_nohighmem(). This is not a problem for symlinks read from the backing device, because the __GFP_FS flag is dropped after inode_nohighmem() is called. However, when a new symlink is created with nilfs_symlink(), the gfp flags remain overwritten to GFP_KERNEL. Then, memory allocation called from page_symlink() etc. triggers memory reclamation including the FS layer, which may call nilfs_evict_inode() or nilfs_dirty_inode(). And these can cause a deadlock if they are called while nilfs->ns_segctor_sem is held: Fix this issue by dropping the __GFP_FS flag from the page cache GFP flags of newly created symlinks in the same way that nilfs_new_inode() and __nilfs_read_inode() do, as a workaround until we adopt nofs allocation scope consistently or improve the locking constraints.(CVE-2024-50229)
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix kernel bug due to missing clearing of checked flag Syzbot reported that in directory operations after nilfs2 detects filesystem corruption and degrades to read-only, __block_write_begin_int(), which is called to prepare block writes, may fail the BUG_ON check for accesses exceeding the folio/page size, triggering a kernel bug. This was found to be because the "checked" flag of a page/folio was not cleared when it was discarded by nilfs2's own routine, which causes the sanity check of directory entries to be skipped when the directory page/folio is reloaded. So, fix that. This was necessary when the use of nilfs2's own page discard routine was applied to more than just metadata files.(CVE-2024-50230)
In the Linux kernel, the following vulnerability has been resolved: NFSD: Initialize struct nfsd4_copy earlier Ensure the refcount and async_copies fields are initialized early. cleanup_async_copy() will reference these fields if an error occurs in nfsd4_copy(). If they are not correctly initialized, at the very least, a refcount underflow occurs.(CVE-2024-50241)
In the Linux kernel, the following vulnerability has been resolved: ntfs3: Add bounds checking to mi_enum_attr() Added bounds checking to make sure that every attr don't stray beyond valid memory region.(CVE-2024-50248)
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix out-of-bounds write in trie_get_next_key() trie_get_next_key() allocates a node stack with size trie->max_prefixlen, while it writes (trie->max_prefixlen + 1) nodes to the stack when it has full paths from the root to leaves. For example, consider a trie with max_prefixlen is 8, and the nodes with key 0x00/0, 0x00/1, 0x00/2, ... 0x00/8 inserted. Subsequent calls to trie_get_next_key with _key with .prefixlen = 8 make 9 nodes be written on the node stack with size 8.(CVE-2024-50262)
In the Linux kernel, the following vulnerability has been resolved: ocfs2: remove entry once instead of null-ptr-dereference in ocfs2_xa_remove() Syzkaller is able to provoke null-ptr-dereference in ocfs2_xa_remove(): [ 57.319872] (a.out,1161,7):ocfs2_xa_remove:2028 ERROR: status = -12 [ 57.320420] (a.out,1161,7):ocfs2_xa_cleanup_value_truncate:1999 ERROR: Partial truncate while removing xattr overlay.upper. Leaking 1 clusters and removing the entry [ 57.321727] BUG: kernel NULL pointer dereference, address: 0000000000000004 [...] [ 57.325727] RIP: 0010:ocfs2_xa_block_wipe_namevalue+0x2a/0xc0 [...] [ 57.331328] Call Trace: [ 57.331477] <TASK> [...] [ 57.333511] ? do_user_addr_fault+0x3e5/0x740 [ 57.333778] ? exc_page_fault+0x70/0x170 [ 57.334016] ? asm_exc_page_fault+0x2b/0x30 [ 57.334263] ? __pfx_ocfs2_xa_block_wipe_namevalue+0x10/0x10 [ 57.334596] ? ocfs2_xa_block_wipe_namevalue+0x2a/0xc0 [ 57.334913] ocfs2_xa_remove_entry+0x23/0xc0 [ 57.335164] ocfs2_xa_set+0x704/0xcf0 [ 57.335381] ? _raw_spin_unlock+0x1a/0x40 [ 57.335620] ? ocfs2_inode_cache_unlock+0x16/0x20 [ 57.335915] ? trace_preempt_on+0x1e/0x70 [ 57.336153] ? start_this_handle+0x16c/0x500 [ 57.336410] ? preempt_count_sub+0x50/0x80 [ 57.336656] ? _raw_read_unlock+0x20/0x40 [ 57.336906] ? start_this_handle+0x16c/0x500 [ 57.337162] ocfs2_xattr_block_set+0xa6/0x1e0 [ 57.337424] __ocfs2_xattr_set_handle+0x1fd/0x5d0 [ 57.337706] ? ocfs2_start_trans+0x13d/0x290 [ 57.337971] ocfs2_xattr_set+0xb13/0xfb0 [ 57.338207] ? dput+0x46/0x1c0 [ 57.338393] ocfs2_xattr_trusted_set+0x28/0x30 [ 57.338665] ? ocfs2_xattr_trusted_set+0x28/0x30 [ 57.338948] __vfs_removexattr+0x92/0xc0 [ 57.339182] __vfs_removexattr_locked+0xd5/0x190 [ 57.339456] ? preempt_count_sub+0x50/0x80 [ 57.339705] vfs_removexattr+0x5f/0x100 [...] Reproducer uses faultinject facility to fail ocfs2_xa_remove() -> ocfs2_xa_value_truncate() with -ENOMEM. In this case the comment mentions that we can return 0 if ocfs2_xa_cleanup_value_truncate() is going to wipe the entry anyway. But the following 'rc' check is wrong and execution flow do 'ocfs2_xa_remove_entry(loc);' twice: * 1st: in ocfs2_xa_cleanup_value_truncate(); * 2nd: returning back to ocfs2_xa_remove() instead of going to 'out'. Fix this by skipping the 2nd removal of the same entry and making syzkaller repro happy.(CVE-2024-50265)
In the Linux kernel, the following vulnerability has been resolved: usb: musb: sunxi: Fix accessing an released usb phy Commit 6ed05c68cbca ("usb: musb: sunxi: Explicitly release USB PHY on exit") will cause that usb phy @glue->xceiv is accessed after released. 1) register platform driver @sunxi_musb_driver // get the usb phy @glue->xceiv sunxi_musb_probe() -> devm_usb_get_phy(). 2) register and unregister platform driver @musb_driver musb_probe() -> sunxi_musb_init() use the phy here //the phy is released here musb_remove() -> sunxi_musb_exit() -> devm_usb_put_phy() 3) register @musb_driver again musb_probe() -> sunxi_musb_init() use the phy here but the phy has been released at 2). ... Fixed by reverting the commit, namely, removing devm_usb_put_phy() from sunxi_musb_exit().(CVE-2024-50269)
In the Linux kernel, the following vulnerability has been resolved: btrfs: reinitialize delayed ref list after deleting it from the list At insert_delayed_ref() if we need to update the action of an existing ref to BTRFS_DROP_DELAYED_REF, we delete the ref from its ref head's ref_add_list using list_del(), which leaves the ref's add_list member not reinitialized, as list_del() sets the next and prev members of the list to LIST_POISON1 and LIST_POISON2, respectively. If later we end up calling drop_delayed_ref() against the ref, which can happen during merging or when destroying delayed refs due to a transaction abort, we can trigger a crash since at drop_delayed_ref() we call list_empty() against the ref's add_list, which returns false since the list was not reinitialized after the list_del() and as a consequence we call list_del() again at drop_delayed_ref(). This results in an invalid list access since the next and prev members are set to poison pointers, resulting in a splat if CONFIG_LIST_HARDENED and CONFIG_DEBUG_LIST are set or invalid poison pointer dereferences otherwise. So fix this by deleting from the list with list_del_init() instead.(CVE-2024-50273)
In the Linux kernel, the following vulnerability has been resolved: media: av7110: fix a spectre vulnerability As warned by smatch: drivers/staging/media/av7110/av7110_ca.c:270 dvb_ca_ioctl() warn: potential spectre issue 'av7110->ci_slot' [w] (local cap) There is a spectre-related vulnerability at the code. Fix it.(CVE-2024-50289)
In the Linux kernel, the following vulnerability has been resolved: security/keys: fix slab-out-of-bounds in key_task_permission KASAN reports an out of bounds read: BUG: KASAN: slab-out-of-bounds in __kuid_val include/linux/uidgid.h:36 BUG: KASAN: slab-out-of-bounds in uid_eq include/linux/uidgid.h:63 [inline] BUG: KASAN: slab-out-of-bounds in key_task_permission+0x394/0x410 security/keys/permission.c:54 Read of size 4 at addr ffff88813c3ab618 by task stress-ng/4362 CPU: 2 PID: 4362 Comm: stress-ng Not tainted 5.10.0-14930-gafbffd6c3ede #15 Call Trace: __dump_stack lib/dump_stack.c:82 [inline] dump_stack+0x107/0x167 lib/dump_stack.c:123 print_address_description.constprop.0+0x19/0x170 mm/kasan/report.c:400 __kasan_report.cold+0x6c/0x84 mm/kasan/report.c:560 kasan_report+0x3a/0x50 mm/kasan/report.c:585 __kuid_val include/linux/uidgid.h:36 [inline] uid_eq include/linux/uidgid.h:63 [inline] key_task_permission+0x394/0x410 security/keys/permission.c:54 search_nested_keyrings+0x90e/0xe90 security/keys/keyring.c:793 This issue was also reported by syzbot. It can be reproduced by following these steps(more details [1]): 1. Obtain more than 32 inputs that have similar hashes, which ends with the pattern '0xxxxxxxe6'. 2. Reboot and add the keys obtained in step 1. The reproducer demonstrates how this issue happened: 1. In the search_nested_keyrings function, when it iterates through the slots in a node(below tag ascend_to_node), if the slot pointer is meta and node->back_pointer != NULL(it means a root), it will proceed to descend_to_node. However, there is an exception. If node is the root, and one of the slots points to a shortcut, it will be treated as a keyring. 2. Whether the ptr is keyring decided by keyring_ptr_is_keyring function. However, KEYRING_PTR_SUBTYPE is 0x2UL, the same as ASSOC_ARRAY_PTR_SUBTYPE_MASK. 3. When 32 keys with the similar hashes are added to the tree, the ROOT has keys with hashes that are not similar (e.g. slot 0) and it splits NODE A without using a shortcut. When NODE A is filled with keys that all hashes are xxe6, the keys are similar, NODE A will split with a shortcut. Finally, it forms the tree as shown below, where slot 6 points to a shortcut. NODE A +------>+---+ ROOT | | 0 | xxe6 +---+ | +---+ xxxx | 0 | shortcut : : xxe6 +---+ | +---+ xxe6 : : | | | xxe6 +---+ | +---+ | 6 |---+ : : xxe6 +---+ +---+ xxe6 : : | f | xxe6 +---+ +---+ xxe6 | f | +---+ 4. As mentioned above, If a slot(slot 6) of the root points to a shortcut, it may be mistakenly transferred to a key*, leading to a read out-of-bounds read. To fix this issue, one should jump to descend_to_node if the ptr is a shortcut, regardless of whether the node is root or not. [1] https://lore.kernel.org/linux-kernel/1cfa878e-8c7b-4570-8606-21daf5e13ce7@huaweicloud.com/ jarkko: tweaked the commit message a bit to have an appropriate closes tag.
In the Linux kernel, the following vulnerability has been resolved: io_uring/rw: fix missing NOWAIT check for O_DIRECT start write When io_uring starts a write, it'll call kiocb_start_write() to bump the super block rwsem, preventing any freezes from happening while that write is in-flight. The freeze side will grab that rwsem for writing, excluding any new writers from happening and waiting for existing writes to finish. But io_uring unconditionally uses kiocb_start_write(), which will block if someone is currently attempting to freeze the mount point. This causes a deadlock where freeze is waiting for previous writes to complete, but the previous writes cannot complete, as the task that is supposed to complete them is blocked waiting on starting a new write. This results in the following stuck trace showing that dependency with the write blocked starting a new write: task:fio state:D stack:0 pid:886 tgid:886 ppid:876 Call trace: __switch_to+0x1d8/0x348 __schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpu_rwsem_wait+0x1e8/0x3f8 __percpu_down_read+0xe8/0x500 io_write+0xbb8/0xff8 io_issue_sqe+0x10c/0x1020 io_submit_sqes+0x614/0x2110 __arm64_sys_io_uring_enter+0x524/0x1038 invoke_syscall+0x74/0x268 el0_svc_common.constprop.0+0x160/0x238 do_el0_svc+0x44/0x60 el0_svc+0x44/0xb0 el0t_64_sync_handler+0x118/0x128 el0t_64_sync+0x168/0x170 INFO: task fsfreeze:7364 blocked for more than 15 seconds. Not tainted 6.12.0-rc5-00063-g76aaf945701c #7963 with the attempting freezer stuck trying to grab the rwsem: task:fsfreeze state:D stack:0 pid:7364 tgid:7364 ppid:995 Call trace: __switch_to+0x1d8/0x348 __schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpu_down_write+0x2b0/0x680 freeze_super+0x248/0x8a8 do_vfs_ioctl+0x149c/0x1b18 __arm64_sys_ioctl+0xd0/0x1a0 invoke_syscall+0x74/0x268 el0_svc_common.constprop.0+0x160/0x238 do_el0_svc+0x44/0x60 el0_svc+0x44/0xb0 el0t_64_sync_handler+0x118/0x128 el0t_64_sync+0x168/0x170 Fix this by having the io_uring side honor IOCB_NOWAIT, and only attempt a blocking grab of the super block rwsem if it isn't set. For normal issue where IOCB_NOWAIT would always be set, this returns -EAGAIN which will have io_uring core issue a blocking attempt of the write. That will in turn also get completions run, ensuring forward progress. Since freezing requires CAP_SYS_ADMIN in the first place, this isn't something that can be triggered by a regular user.(CVE-2024-53052)
In the Linux kernel, the following vulnerability has been resolved: media: s5p-jpeg: prevent buffer overflows The current logic allows word to be less than 2. If this happens, there will be buffer overflows, as reported by smatch. Add extra checks to prevent it. While here, remove an unused word = 0 assignment.(CVE-2024-53061)
In the Linux kernel, the following vulnerability has been resolved: nfs: Fix KMSAN warning in decode_getfattr_attrs() Fix the following KMSAN warning: CPU: 1 UID: 0 PID: 7651 Comm: cp Tainted: G B Tainted: [B]=BAD_PAGE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) ===================================================== ===================================================== BUG: KMSAN: uninit-value in decode_getfattr_attrs+0x2d6d/0x2f90 decode_getfattr_attrs+0x2d6d/0x2f90 decode_getfattr_generic+0x806/0xb00 nfs4_xdr_dec_getattr+0x1de/0x240 rpcauth_unwrap_resp_decode+0xab/0x100 rpcauth_unwrap_resp+0x95/0xc0 call_decode+0x4ff/0xb50 __rpc_execute+0x57b/0x19d0 rpc_execute+0x368/0x5e0 rpc_run_task+0xcfe/0xee0 nfs4_proc_getattr+0x5b5/0x990 __nfs_revalidate_inode+0x477/0xd00 nfs_access_get_cached+0x1021/0x1cc0 nfs_do_access+0x9f/0xae0 nfs_permission+0x1e4/0x8c0 inode_permission+0x356/0x6c0 link_path_walk+0x958/0x1330 path_lookupat+0xce/0x6b0 filename_lookup+0x23e/0x770 vfs_statx+0xe7/0x970 vfs_fstatat+0x1f2/0x2c0 __se_sys_newfstatat+0x67/0x880 __x64_sys_newfstatat+0xbd/0x120 x64_sys_call+0x1826/0x3cf0 do_syscall_64+0xd0/0x1b0 entry_SYSCALL_64_after_hwframe+0x77/0x7f The KMSAN warning is triggered in decode_getfattr_attrs(), when calling decode_attr_mdsthreshold(). It appears that fattr->mdsthreshold is not initialized. Fix the issue by initializing fattr->mdsthreshold to NULL in nfs_fattr_init().(CVE-2024-53066)
| URL | Type | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-5.10.0-238.0.0.137.oe2203sp4.aarch64.rpm",
"bpftool-debuginfo-5.10.0-238.0.0.137.oe2203sp4.aarch64.rpm",
"kernel-5.10.0-238.0.0.137.oe2203sp4.aarch64.rpm",
"kernel-debuginfo-5.10.0-238.0.0.137.oe2203sp4.aarch64.rpm",
"kernel-debugsource-5.10.0-238.0.0.137.oe2203sp4.aarch64.rpm",
"kernel-devel-5.10.0-238.0.0.137.oe2203sp4.aarch64.rpm",
"kernel-headers-5.10.0-238.0.0.137.oe2203sp4.aarch64.rpm",
"kernel-source-5.10.0-238.0.0.137.oe2203sp4.aarch64.rpm",
"kernel-tools-5.10.0-238.0.0.137.oe2203sp4.aarch64.rpm",
"kernel-tools-debuginfo-5.10.0-238.0.0.137.oe2203sp4.aarch64.rpm",
"kernel-tools-devel-5.10.0-238.0.0.137.oe2203sp4.aarch64.rpm",
"perf-5.10.0-238.0.0.137.oe2203sp4.aarch64.rpm",
"perf-debuginfo-5.10.0-238.0.0.137.oe2203sp4.aarch64.rpm",
"python3-perf-5.10.0-238.0.0.137.oe2203sp4.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-238.0.0.137.oe2203sp4.aarch64.rpm"
],
"src": [
"kernel-5.10.0-238.0.0.137.oe2203sp4.src.rpm"
],
"x86_64": [
"bpftool-5.10.0-238.0.0.137.oe2203sp4.x86_64.rpm",
"bpftool-debuginfo-5.10.0-238.0.0.137.oe2203sp4.x86_64.rpm",
"kernel-5.10.0-238.0.0.137.oe2203sp4.x86_64.rpm",
"kernel-debuginfo-5.10.0-238.0.0.137.oe2203sp4.x86_64.rpm",
"kernel-debugsource-5.10.0-238.0.0.137.oe2203sp4.x86_64.rpm",
"kernel-devel-5.10.0-238.0.0.137.oe2203sp4.x86_64.rpm",
"kernel-headers-5.10.0-238.0.0.137.oe2203sp4.x86_64.rpm",
"kernel-source-5.10.0-238.0.0.137.oe2203sp4.x86_64.rpm",
"kernel-tools-5.10.0-238.0.0.137.oe2203sp4.x86_64.rpm",
"kernel-tools-debuginfo-5.10.0-238.0.0.137.oe2203sp4.x86_64.rpm",
"kernel-tools-devel-5.10.0-238.0.0.137.oe2203sp4.x86_64.rpm",
"perf-5.10.0-238.0.0.137.oe2203sp4.x86_64.rpm",
"perf-debuginfo-5.10.0-238.0.0.137.oe2203sp4.x86_64.rpm",
"python3-perf-5.10.0-238.0.0.137.oe2203sp4.x86_64.rpm",
"python3-perf-debuginfo-5.10.0-238.0.0.137.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-238.0.0.137.oe2203sp4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: missing check virtio\r\n\r\nTwo missing check in virtio_net_hdr_to_skb() allowed syzbot\nto crash kernels again\r\n\r\n1. After the skb_segment function the buffer may become non-linear\n(nr_frags != 0), but since the SKBTX_SHARED_FRAG flag is not set anywhere\nthe __skb_linearize function will not be executed, then the buffer will\nremain non-linear. Then the condition (offset \u0026gt;= skb_headlen(skb))\nbecomes true, which causes WARN_ON_ONCE in skb_checksum_help.\r\n\r\n2. The struct sk_buff and struct virtio_net_hdr members must be\nmathematically related.\n(gso_size) must be greater than (needed) otherwise WARN_ON_ONCE.\n(remainder) must be greater than (needed) otherwise WARN_ON_ONCE.\n(remainder) may be 0 if division is without remainder.\r\n\r\noffset+2 (4191) \u0026gt; skb_headlen() (1116)\nWARNING: CPU: 1 PID: 5084 at net/core/dev.c:3303 skb_checksum_help+0x5e2/0x740 net/core/dev.c:3303\nModules linked in:\nCPU: 1 PID: 5084 Comm: syz-executor336 Not tainted 6.7.0-rc3-syzkaller-00014-gdf60cee26a2e #0\nHardware name: Google Compute Engine/Google Compute Engine, BIOS Google 11/10/2023\nRIP: 0010:skb_checksum_help+0x5e2/0x740 net/core/dev.c:3303\nCode: 89 e8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 52 01 00 00 44 89 e2 2b 53 74 4c 89 ee 48 c7 c7 40 57 e9 8b e8 af 8f dd f8 90 \u0026lt;0f\u0026gt; 0b 90 90 e9 87 fe ff ff e8 40 0f 6e f9 e9 4b fa ff ff 48 89 ef\nRSP: 0018:ffffc90003a9f338 EFLAGS: 00010286\nRAX: 0000000000000000 RBX: ffff888025125780 RCX: ffffffff814db209\nRDX: ffff888015393b80 RSI: ffffffff814db216 RDI: 0000000000000001\nRBP: ffff8880251257f4 R08: 0000000000000001 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000001 R12: 000000000000045c\nR13: 000000000000105f R14: ffff8880251257f0 R15: 000000000000105d\nFS: 0000555555c24380(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 000000002000f000 CR3: 0000000023151000 CR4: 00000000003506f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ip_do_fragment+0xa1b/0x18b0 net/ipv4/ip_output.c:777\n ip_fragment.constprop.0+0x161/0x230 net/ipv4/ip_output.c:584\n ip_finish_output_gso net/ipv4/ip_output.c:286 [inline]\n __ip_finish_output net/ipv4/ip_output.c:308 [inline]\n __ip_finish_output+0x49c/0x650 net/ipv4/ip_output.c:295\n ip_finish_output+0x31/0x310 net/ipv4/ip_output.c:323\n NF_HOOK_COND include/linux/netfilter.h:303 [inline]\n ip_output+0x13b/0x2a0 net/ipv4/ip_output.c:433\n dst_output include/net/dst.h:451 [inline]\n ip_local_out+0xaf/0x1a0 net/ipv4/ip_output.c:129\n iptunnel_xmit+0x5b4/0x9b0 net/ipv4/ip_tunnel_core.c:82\n ipip6_tunnel_xmit net/ipv6/sit.c:1034 [inline]\n sit_tunnel_xmit+0xed2/0x28f0 net/ipv6/sit.c:1076\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:3545 [inline]\n dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3561\n __dev_queue_xmit+0x7c1/0x3d60 net/core/dev.c:4346\n dev_queue_xmit include/linux/netdevice.h:3134 [inline]\n packet_xmit+0x257/0x380 net/packet/af_packet.c:276\n packet_snd net/packet/af_packet.c:3087 [inline]\n packet_sendmsg+0x24ca/0x5240 net/packet/af_packet.c:3119\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg+0xd5/0x180 net/socket.c:745\n __sys_sendto+0x255/0x340 net/socket.c:2190\n __do_sys_sendto net/socket.c:2202 [inline]\n __se_sys_sendto net/socket.c:2198 [inline]\n __x64_sys_sendto+0xe0/0x1b0 net/socket.c:2198\n do_syscall_x64 arch/x86/entry/common.c:51 [inline]\n do_syscall_64+0x40/0x110 arch/x86/entry/common.c:82\n entry_SYSCALL_64_after_hwframe+0x63/0x6b\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with Syzkaller(CVE-2024-43817)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: flowtable: initialise extack before use\r\n\r\nFix missing initialisation of extack in flow offload.(CVE-2024-45018)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nperf/aux: Fix AUX buffer serialization\r\n\r\nOle reported that event-\u0026gt;mmap_mutex is strictly insufficient to\nserialize the AUX buffer, add a per RB mutex to fully serialize it.\r\n\r\nNote that in the lock order comment the perf_event::mmap_mutex order\nwas already wrong, that is, it nesting under mmap_lock is not new with\nthis patch.(CVE-2024-46713)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: mm: call the security_mmap_file() LSM hook in remap_file_pages() The remap_file_pages syscall handler calls do_mmap() directly, which doesn\u0026apos;t contain the LSM security check. And if the process has called personality(READ_IMPLIES_EXEC) before and remap_file_pages() is called for RW pages, this will actually result in remapping the pages to RWX, bypassing a W^X policy enforced by SELinux. So we should check prot by security_mmap_file LSM hook in the remap_file_pages syscall handler before do_mmap() is called. Otherwise, it potentially permits an attacker to bypass a W^X policy enforced by SELinux. The bypass is similar to CVE-2016-10044, which bypass the same thing via AIO and can be found in [1]. The PoC: $ cat \u0026gt; test.c int main(void) { size_t pagesz = sysconf(_SC_PAGE_SIZE); int mfd = syscall(SYS_memfd_create, \u0026quot;test\u0026quot;, 0); const char *buf = mmap(NULL, 4 * pagesz, PROT_READ | PROT_WRITE, MAP_SHARED, mfd, 0); unsigned int old = syscall(SYS_personality, 0xffffffff); syscall(SYS_personality, READ_IMPLIES_EXEC | old); syscall(SYS_remap_file_pages, buf, pagesz, 0, 2, 0); syscall(SYS_personality, old); // show the RWX page exists even if W^X policy is enforced int fd = open(\u0026quot;/proc/self/maps\u0026quot;, O_RDONLY); unsigned char buf2[1024]; while (1) { int ret = read(fd, buf2, 1024); if (ret \u0026lt;= 0) break; write(1, buf2, ret); } close(fd); } $ gcc test.c -o test $ ./test | grep rwx 7f1836c34000-7f1836c35000 rwxs 00002000 00:01 2050 /memfd:test (deleted) [PM: subject line tweaks](CVE-2024-47745)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: net: seeq: Fix use after free vulnerability in ether3 Driver Due to Race Condition In the ether3_probe function, a timer is initialized with a callback function ether3_ledoff, bound to \u0026amp;prev(dev)-\u0026gt;timer. Once the timer is started, there is a risk of a race condition if the module or device is removed, triggering the ether3_remove function to perform cleanup. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | ether3_ledoff ether3_remove | free_netdev(dev); | put_devic | kfree(dev); | | ether3_outw(priv(dev)-\u0026gt;regs.config2 |= CFG2_CTRLO, REG_CONFIG2); | // use dev Fix it by ensuring that the timer is canceled before proceeding with the cleanup in ether3_remove.(CVE-2024-47747)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: RDMA/cxgb4: Added NULL check for lookup_atid The lookup_atid() function can return NULL if the ATID is invalid or does not exist in the identifier table, which could lead to dereferencing a null pointer without a check in the `act_establish()` and `act_open_rpl()` functions. Add a NULL check to prevent null pointer dereferencing. Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-47749)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Initialize denominators\u0026apos; default to 1 [WHAT \u0026amp; HOW] Variables used as denominators and maybe not assigned to other values, should not be 0. Change their default to 1 so they are never 0. This fixes 10 DIVIDE_BY_ZERO issues reported by Coverity.(CVE-2024-49899)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: avoid NULL pointer dereference iwl_mvm_tx_skb_sta() and iwl_mvm_tx_mpdu() verify that the mvmvsta pointer is not NULL. It retrieves this pointer using iwl_mvm_sta_from_mac80211, which is dereferencing the ieee80211_sta pointer. If sta is NULL, iwl_mvm_sta_from_mac80211 will dereference a NULL pointer. Fix this by checking the sta pointer before retrieving the mvmsta from it. If sta is not NULL, then mvmsta isn\u0026apos;t either.(CVE-2024-49929)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: prevent nf_skb_duplicated corruption syzbot found that nf_dup_ipv4() or nf_dup_ipv6() could write per-cpu variable nf_skb_duplicated in an unsafe way [1]. Disabling preemption as hinted by the splat is not enough, we have to disable soft interrupts as well. [1] BUG: using __this_cpu_write() in preemptible [00000000] code: syz.4.282/6316 caller is nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87 CPU: 0 UID: 0 PID: 6316 Comm: syz.4.282 Not tainted 6.11.0-rc7-syzkaller-00104-g7052622fccb1 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Call Trace: \u0026lt;TASK\u0026gt; __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 check_preemption_disabled+0x10e/0x120 lib/smp_processor_id.c:49 nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87 nft_dup_ipv4_eval+0x1db/0x300 net/ipv4/netfilter/nft_dup_ipv4.c:30 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x4ad/0x1da0 net/netfilter/nf_tables_core.c:288 nft_do_chain_ipv4+0x202/0x320 net/netfilter/nft_chain_filter.c:23 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626 nf_hook+0x2c4/0x450 include/linux/netfilter.h:269 NF_HOOK_COND include/linux/netfilter.h:302 [inline] ip_output+0x185/0x230 net/ipv4/ip_output.c:433 ip_local_out net/ipv4/ip_output.c:129 [inline] ip_send_skb+0x74/0x100 net/ipv4/ip_output.c:1495 udp_send_skb+0xacf/0x1650 net/ipv4/udp.c:981 udp_sendmsg+0x1c21/0x2a60 net/ipv4/udp.c:1269 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x1a6/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2597 ___sys_sendmsg net/socket.c:2651 [inline] __sys_sendmmsg+0x3b2/0x740 net/socket.c:2737 __do_sys_sendmmsg net/socket.c:2766 [inline] __se_sys_sendmmsg net/socket.c:2763 [inline] __x64_sys_sendmmsg+0xa0/0xb0 net/socket.c:2763 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f4ce4f7def9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f4ce5d4a038 EFLAGS: 00000246 ORIG_RAX: 0000000000000133 RAX: ffffffffffffffda RBX: 00007f4ce5135f80 RCX: 00007f4ce4f7def9 RDX: 0000000000000001 RSI: 0000000020005d40 RDI: 0000000000000006 RBP: 00007f4ce4ff0b76 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f4ce5135f80 R15: 00007ffd4cbc6d68 \u0026lt;/TASK\u0026gt;(CVE-2024-49952)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: netfilter: br_netfilter: fix panic with metadata_dst skb Fix a kernel panic in the br_netfilter module when sending untagged traffic via a VxLAN device. This happens during the check for fragmentation in br_nf_dev_queue_xmit. It is dependent on: 1) the br_netfilter module being loaded; 2) net.bridge.bridge-nf-call-iptables set to 1; 3) a bridge with a VxLAN (single-vxlan-device) netdevice as a bridge port; 4) untagged frames with size higher than the VxLAN MTU forwarded/flooded When forwarding the untagged packet to the VxLAN bridge port, before the netfilter hooks are called, br_handle_egress_vlan_tunnel is called and changes the skb_dst to the tunnel dst. The tunnel_dst is a metadata type of dst, i.e., skb_valid_dst(skb) is false, and metadata-\u0026gt;dst.dev is NULL. Then in the br_netfilter hooks, in br_nf_dev_queue_xmit, there\u0026apos;s a check for frames that needs to be fragmented: frames with higher MTU than the VxLAN device end up calling br_nf_ip_fragment, which in turns call ip_skb_dst_mtu. The ip_dst_mtu tries to use the skb_dst(skb) as if it was a valid dst with valid dst-\u0026gt;dev, thus the crash. This case was never supported in the first place, so drop the packet instead. PING 10.0.0.2 (10.0.0.2) from 0.0.0.0 h1-eth0: 2000(2028) bytes of data. [ 176.291791] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000110 [ 176.292101] Mem abort info: [ 176.292184] ESR = 0x0000000096000004 [ 176.292322] EC = 0x25: DABT (current EL), IL = 32 bits [ 176.292530] SET = 0, FnV = 0 [ 176.292709] EA = 0, S1PTW = 0 [ 176.292862] FSC = 0x04: level 0 translation fault [ 176.293013] Data abort info: [ 176.293104] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 176.293488] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 176.293787] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 176.293995] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000043ef5000 [ 176.294166] [0000000000000110] pgd=0000000000000000, p4d=0000000000000000 [ 176.294827] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 176.295252] Modules linked in: vxlan ip6_udp_tunnel udp_tunnel veth br_netfilter bridge stp llc ipv6 crct10dif_ce [ 176.295923] CPU: 0 PID: 188 Comm: ping Not tainted 6.8.0-rc3-g5b3fbd61b9d1 #2 [ 176.296314] Hardware name: linux,dummy-virt (DT) [ 176.296535] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 176.296808] pc : br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter] [ 176.297382] lr : br_nf_dev_queue_xmit+0x2ac/0x4ec [br_netfilter] [ 176.297636] sp : ffff800080003630 [ 176.297743] x29: ffff800080003630 x28: 0000000000000008 x27: ffff6828c49ad9f8 [ 176.298093] x26: ffff6828c49ad000 x25: 0000000000000000 x24: 00000000000003e8 [ 176.298430] x23: 0000000000000000 x22: ffff6828c4960b40 x21: ffff6828c3b16d28 [ 176.298652] x20: ffff6828c3167048 x19: ffff6828c3b16d00 x18: 0000000000000014 [ 176.298926] x17: ffffb0476322f000 x16: ffffb7e164023730 x15: 0000000095744632 [ 176.299296] x14: ffff6828c3f1c880 x13: 0000000000000002 x12: ffffb7e137926a70 [ 176.299574] x11: 0000000000000001 x10: ffff6828c3f1c898 x9 : 0000000000000000 [ 176.300049] x8 : ffff6828c49bf070 x7 : 0008460f18d5f20e x6 : f20e0100bebafeca [ 176.300302] x5 : ffff6828c7f918fe x4 : ffff6828c49bf070 x3 : 0000000000000000 [ 176.300586] x2 : 0000000000000000 x1 : ffff6828c3c7ad00 x0 : ffff6828c7f918f0 [ 176.300889] Call trace: [ 176.301123] br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter] [ 176.301411] br_nf_post_routing+0x2a8/0x3e4 [br_netfilter] [ 176.301703] nf_hook_slow+0x48/0x124 [ 176.302060] br_forward_finish+0xc8/0xe8 [bridge] [ 176.302371] br_nf_hook_thresh+0x124/0x134 [br_netfilter] [ 176.302605] br_nf_forward_finish+0x118/0x22c [br_netfilter] [ 176.302824] br_nf_forward_ip.part.0+0x264/0x290 [br_netfilter] [ 176.303136] br_nf_forward+0x2b8/0x4e0 [br_netfilter] [ 176.303359] nf_hook_slow+0x48/0x124 [ 176.303 ---truncated---(CVE-2024-50045)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: RDMA/rtrs-srv: Avoid null pointer deref during path establishment For RTRS path establishment, RTRS client initiates and completes con_num of connections. After establishing all its connections, the information is exchanged between the client and server through the info_req message. During this exchange, it is essential that all connections have been established, and the state of the RTRS srv path is CONNECTED. So add these sanity checks, to make sure we detect and abort process in error scenarios to avoid null pointer deref.(CVE-2024-50062)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: mptcp: pm: fix UaF read in mptcp_pm_nl_rm_addr_or_subflow Syzkaller reported this splat: ================================================================== BUG: KASAN: slab-use-after-free in mptcp_pm_nl_rm_addr_or_subflow+0xb44/0xcc0 net/mptcp/pm_netlink.c:881 Read of size 4 at addr ffff8880569ac858 by task syz.1.2799/14662 CPU: 0 UID: 0 PID: 14662 Comm: syz.1.2799 Not tainted 6.12.0-rc2-syzkaller-00307-g36c254515dc6 #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Call Trace: \u0026lt;TASK\u0026gt; __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc3/0x620 mm/kasan/report.c:488 kasan_report+0xd9/0x110 mm/kasan/report.c:601 mptcp_pm_nl_rm_addr_or_subflow+0xb44/0xcc0 net/mptcp/pm_netlink.c:881 mptcp_pm_nl_rm_subflow_received net/mptcp/pm_netlink.c:914 [inline] mptcp_nl_remove_id_zero_address+0x305/0x4a0 net/mptcp/pm_netlink.c:1572 mptcp_pm_nl_del_addr_doit+0x5c9/0x770 net/mptcp/pm_netlink.c:1603 genl_family_rcv_msg_doit+0x202/0x2f0 net/netlink/genetlink.c:1115 genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0x565/0x800 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x165/0x410 net/netlink/af_netlink.c:2551 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1331 [inline] netlink_unicast+0x53c/0x7f0 net/netlink/af_netlink.c:1357 netlink_sendmsg+0x8b8/0xd70 net/netlink/af_netlink.c:1901 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg net/socket.c:744 [inline] ____sys_sendmsg+0x9ae/0xb40 net/socket.c:2607 ___sys_sendmsg+0x135/0x1e0 net/socket.c:2661 __sys_sendmsg+0x117/0x1f0 net/socket.c:2690 do_syscall_32_irqs_on arch/x86/entry/common.c:165 [inline] __do_fast_syscall_32+0x73/0x120 arch/x86/entry/common.c:386 do_fast_syscall_32+0x32/0x80 arch/x86/entry/common.c:411 entry_SYSENTER_compat_after_hwframe+0x84/0x8e RIP: 0023:0xf7fe4579 Code: b8 01 10 06 03 74 b4 01 10 07 03 74 b0 01 10 08 03 74 d8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 51 52 55 89 e5 0f 34 cd 80 \u0026lt;5d\u0026gt; 5a 59 c3 90 90 90 90 8d b4 26 00 00 00 00 8d b4 26 00 00 00 00 RSP: 002b:00000000f574556c EFLAGS: 00000296 ORIG_RAX: 0000000000000172 RAX: ffffffffffffffda RBX: 000000000000000b RCX: 0000000020000140 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000296 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 \u0026lt;/TASK\u0026gt; Allocated by task 5387: kasan_save_stack+0x33/0x60 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:394 kmalloc_noprof include/linux/slab.h:878 [inline] kzalloc_noprof include/linux/slab.h:1014 [inline] subflow_create_ctx+0x87/0x2a0 net/mptcp/subflow.c:1803 subflow_ulp_init+0xc3/0x4d0 net/mptcp/subflow.c:1956 __tcp_set_ulp net/ipv4/tcp_ulp.c:146 [inline] tcp_set_ulp+0x326/0x7f0 net/ipv4/tcp_ulp.c:167 mptcp_subflow_create_socket+0x4ae/0x10a0 net/mptcp/subflow.c:1764 __mptcp_subflow_connect+0x3cc/0x1490 net/mptcp/subflow.c:1592 mptcp_pm_create_subflow_or_signal_addr+0xbda/0x23a0 net/mptcp/pm_netlink.c:642 mptcp_pm_nl_fully_established net/mptcp/pm_netlink.c:650 [inline] mptcp_pm_nl_work+0x3a1/0x4f0 net/mptcp/pm_netlink.c:943 mptcp_worker+0x15a/0x1240 net/mptcp/protocol.c:2777 process_one_work+0x958/0x1b30 kernel/workqueue.c:3229 process_scheduled_works kernel/workqueue.c:3310 [inline] worker_thread+0x6c8/0xf00 kernel/workqueue.c:3391 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/ke ---truncated---(CVE-2024-50085)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: unicode: Don\u0026apos;t special case ignorable code points We don\u0026apos;t need to handle them separately. Instead, just let them decompose/casefold to themselves.(CVE-2024-50089)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: ACPI: PRM: Find EFI_MEMORY_RUNTIME block for PRM handler and context PRMT needs to find the correct type of block to translate the PA-VA mapping for EFI runtime services. The issue arises because the PRMT is finding a block of type EFI_CONVENTIONAL_MEMORY, which is not appropriate for runtime services as described in Section 2.2.2 (Runtime Services) of the UEFI Specification [1]. Since the PRM handler is a type of runtime service, this causes an exception when the PRM handler is called. [Firmware Bug]: Unable to handle paging request in EFI runtime service WARNING: CPU: 22 PID: 4330 at drivers/firmware/efi/runtime-wrappers.c:341 __efi_queue_work+0x11c/0x170 Call trace: Let PRMT find a block with EFI_MEMORY_RUNTIME for PRM handler and PRM context. If no suitable block is found, a warning message will be printed, but the procedure continues to manage the next PRM handler. However, if the PRM handler is actually called without proper allocation, it would result in a failure during error handling. By using the correct memory types for runtime services, ensure that the PRM handler and the context are properly mapped in the virtual address space during runtime, preventing the paging request error. The issue is really that only memory that has been remapped for runtime by the firmware can be used by the PRM handler, and so the region needs to have the EFI_MEMORY_RUNTIME attribute. [ rjw: Subject and changelog edits ](CVE-2024-50141)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: udf: fix uninit-value use in udf_get_fileshortad Check for overflow when computing alen in udf_current_aext to mitigate later uninit-value use in udf_get_fileshortad KMSAN bug[1]. After applying the patch reproducer did not trigger any issue[2]. [1] https://syzkaller.appspot.com/bug?extid=8901c4560b7ab5c2f9df [2] https://syzkaller.appspot.com/x/log.txt?x=10242227980000(CVE-2024-50143)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: ceph: remove the incorrect Fw reference check when dirtying pages When doing the direct-io reads it will also try to mark pages dirty, but for the read path it won\u0026apos;t hold the Fw caps and there is case will it get the Fw reference.(CVE-2024-50179)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: fbdev: sisfb: Fix strbuf array overflow The values of the variables xres and yres are placed in strbuf. These variables are obtained from strbuf1. The strbuf1 array contains digit characters and a space if the array contains non-digit characters. Then, when executing sprintf(strbuf, \u0026quot;%ux%ux8\u0026quot;, xres, yres); more than 16 bytes will be written to strbuf. It is suggested to increase the size of the strbuf array to 24. Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-50180)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v4: Don\u0026apos;t allow a VMOVP on a dying VPE Kunkun Jiang reported that there is a small window of opportunity for userspace to force a change of affinity for a VPE while the VPE has already been unmapped, but the corresponding doorbell interrupt still visible in /proc/irq/. Plug the race by checking the value of vmapp_count, which tracks whether the VPE is mapped ot not, and returning an error in this case. This involves making vmapp_count common to both GICv4.1 and its v4.0 ancestor.(CVE-2024-50192)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: posix-clock: Fix missing timespec64 check in pc_clock_settime() As Andrew pointed out, it will make sense that the PTP core checked timespec64 struct\u0026apos;s tv_sec and tv_nsec range before calling ptp-\u0026gt;info-\u0026gt;settime64(). As the man manual of clock_settime() said, if tp.tv_sec is negative or tp.tv_nsec is outside the range [0..999,999,999], it should return EINVAL, which include dynamic clocks which handles PTP clock, and the condition is consistent with timespec64_valid(). As Thomas suggested, timespec64_valid() only check the timespec is valid, but not ensure that the time is in a valid range, so check it ahead using timespec64_valid_strict() in pc_clock_settime() and return -EINVAL if not valid. There are some drivers that use tp-\u0026gt;tv_sec and tp-\u0026gt;tv_nsec directly to write registers without validity checks and assume that the higher layer has checked it, which is dangerous and will benefit from this, such as hclge_ptp_settime(), igb_ptp_settime_i210(), _rcar_gen4_ptp_settime(), and some drivers can remove the checks of itself.(CVE-2024-50195)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: nilfs2: propagate directory read errors from nilfs_find_entry() Syzbot reported that a task hang occurs in vcs_open() during a fuzzing test for nilfs2. The root cause of this problem is that in nilfs_find_entry(), which searches for directory entries, ignores errors when loading a directory page/folio via nilfs_get_folio() fails. If the filesystem images is corrupted, and the i_size of the directory inode is large, and the directory page/folio is successfully read but fails the sanity check, for example when it is zero-filled, nilfs_check_folio() may continue to spit out error messages in bursts. Fix this issue by propagating the error to the callers when loading a page/folio fails in nilfs_find_entry(). The current interface of nilfs_find_entry() and its callers is outdated and cannot propagate error codes such as -EIO and -ENOMEM returned via nilfs_find_entry(), so fix it together.(CVE-2024-50202)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: ALSA: firewire-lib: Avoid division by zero in apply_constraint_to_size() The step variable is initialized to zero. It is changed in the loop, but if it\u0026apos;s not changed it will remain zero. Add a variable check before the division. The observed behavior was introduced by commit 826b5de90c0b (\u0026quot;ALSA: firewire-lib: fix insufficient PCM rule for period/buffer size\u0026quot;), and it is difficult to show that any of the interval parameters will satisfy the snd_interval_test() condition with data from the amdtp_rate_table[] table. Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-50205)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential deadlock with newly created symlinks Syzbot reported that page_symlink(), called by nilfs_symlink(), triggers memory reclamation involving the filesystem layer, which can result in circular lock dependencies among the reader/writer semaphore nilfs-\u0026gt;ns_segctor_sem, s_writers percpu_rwsem (intwrite) and the fs_reclaim pseudo lock. This is because after commit 21fc61c73c39 (\u0026quot;don\u0026apos;t put symlink bodies in pagecache into highmem\u0026quot;), the gfp flags of the page cache for symbolic links are overwritten to GFP_KERNEL via inode_nohighmem(). This is not a problem for symlinks read from the backing device, because the __GFP_FS flag is dropped after inode_nohighmem() is called. However, when a new symlink is created with nilfs_symlink(), the gfp flags remain overwritten to GFP_KERNEL. Then, memory allocation called from page_symlink() etc. triggers memory reclamation including the FS layer, which may call nilfs_evict_inode() or nilfs_dirty_inode(). And these can cause a deadlock if they are called while nilfs-\u0026gt;ns_segctor_sem is held: Fix this issue by dropping the __GFP_FS flag from the page cache GFP flags of newly created symlinks in the same way that nilfs_new_inode() and __nilfs_read_inode() do, as a workaround until we adopt nofs allocation scope consistently or improve the locking constraints.(CVE-2024-50229)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: nilfs2: fix kernel bug due to missing clearing of checked flag Syzbot reported that in directory operations after nilfs2 detects filesystem corruption and degrades to read-only, __block_write_begin_int(), which is called to prepare block writes, may fail the BUG_ON check for accesses exceeding the folio/page size, triggering a kernel bug. This was found to be because the \u0026quot;checked\u0026quot; flag of a page/folio was not cleared when it was discarded by nilfs2\u0026apos;s own routine, which causes the sanity check of directory entries to be skipped when the directory page/folio is reloaded. So, fix that. This was necessary when the use of nilfs2\u0026apos;s own page discard routine was applied to more than just metadata files.(CVE-2024-50230)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: NFSD: Initialize struct nfsd4_copy earlier Ensure the refcount and async_copies fields are initialized early. cleanup_async_copy() will reference these fields if an error occurs in nfsd4_copy(). If they are not correctly initialized, at the very least, a refcount underflow occurs.(CVE-2024-50241)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: ntfs3: Add bounds checking to mi_enum_attr() Added bounds checking to make sure that every attr don\u0026apos;t stray beyond valid memory region.(CVE-2024-50248)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: bpf: Fix out-of-bounds write in trie_get_next_key() trie_get_next_key() allocates a node stack with size trie-\u0026gt;max_prefixlen, while it writes (trie-\u0026gt;max_prefixlen + 1) nodes to the stack when it has full paths from the root to leaves. For example, consider a trie with max_prefixlen is 8, and the nodes with key 0x00/0, 0x00/1, 0x00/2, ... 0x00/8 inserted. Subsequent calls to trie_get_next_key with _key with .prefixlen = 8 make 9 nodes be written on the node stack with size 8.(CVE-2024-50262)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: ocfs2: remove entry once instead of null-ptr-dereference in ocfs2_xa_remove() Syzkaller is able to provoke null-ptr-dereference in ocfs2_xa_remove(): [ 57.319872] (a.out,1161,7):ocfs2_xa_remove:2028 ERROR: status = -12 [ 57.320420] (a.out,1161,7):ocfs2_xa_cleanup_value_truncate:1999 ERROR: Partial truncate while removing xattr overlay.upper. Leaking 1 clusters and removing the entry [ 57.321727] BUG: kernel NULL pointer dereference, address: 0000000000000004 [...] [ 57.325727] RIP: 0010:ocfs2_xa_block_wipe_namevalue+0x2a/0xc0 [...] [ 57.331328] Call Trace: [ 57.331477] \u0026lt;TASK\u0026gt; [...] [ 57.333511] ? do_user_addr_fault+0x3e5/0x740 [ 57.333778] ? exc_page_fault+0x70/0x170 [ 57.334016] ? asm_exc_page_fault+0x2b/0x30 [ 57.334263] ? __pfx_ocfs2_xa_block_wipe_namevalue+0x10/0x10 [ 57.334596] ? ocfs2_xa_block_wipe_namevalue+0x2a/0xc0 [ 57.334913] ocfs2_xa_remove_entry+0x23/0xc0 [ 57.335164] ocfs2_xa_set+0x704/0xcf0 [ 57.335381] ? _raw_spin_unlock+0x1a/0x40 [ 57.335620] ? ocfs2_inode_cache_unlock+0x16/0x20 [ 57.335915] ? trace_preempt_on+0x1e/0x70 [ 57.336153] ? start_this_handle+0x16c/0x500 [ 57.336410] ? preempt_count_sub+0x50/0x80 [ 57.336656] ? _raw_read_unlock+0x20/0x40 [ 57.336906] ? start_this_handle+0x16c/0x500 [ 57.337162] ocfs2_xattr_block_set+0xa6/0x1e0 [ 57.337424] __ocfs2_xattr_set_handle+0x1fd/0x5d0 [ 57.337706] ? ocfs2_start_trans+0x13d/0x290 [ 57.337971] ocfs2_xattr_set+0xb13/0xfb0 [ 57.338207] ? dput+0x46/0x1c0 [ 57.338393] ocfs2_xattr_trusted_set+0x28/0x30 [ 57.338665] ? ocfs2_xattr_trusted_set+0x28/0x30 [ 57.338948] __vfs_removexattr+0x92/0xc0 [ 57.339182] __vfs_removexattr_locked+0xd5/0x190 [ 57.339456] ? preempt_count_sub+0x50/0x80 [ 57.339705] vfs_removexattr+0x5f/0x100 [...] Reproducer uses faultinject facility to fail ocfs2_xa_remove() -\u0026gt; ocfs2_xa_value_truncate() with -ENOMEM. In this case the comment mentions that we can return 0 if ocfs2_xa_cleanup_value_truncate() is going to wipe the entry anyway. But the following \u0026apos;rc\u0026apos; check is wrong and execution flow do \u0026apos;ocfs2_xa_remove_entry(loc);\u0026apos; twice: * 1st: in ocfs2_xa_cleanup_value_truncate(); * 2nd: returning back to ocfs2_xa_remove() instead of going to \u0026apos;out\u0026apos;. Fix this by skipping the 2nd removal of the same entry and making syzkaller repro happy.(CVE-2024-50265)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: usb: musb: sunxi: Fix accessing an released usb phy Commit 6ed05c68cbca (\u0026quot;usb: musb: sunxi: Explicitly release USB PHY on exit\u0026quot;) will cause that usb phy @glue-\u0026gt;xceiv is accessed after released. 1) register platform driver @sunxi_musb_driver // get the usb phy @glue-\u0026gt;xceiv sunxi_musb_probe() -\u0026gt; devm_usb_get_phy(). 2) register and unregister platform driver @musb_driver musb_probe() -\u0026gt; sunxi_musb_init() use the phy here //the phy is released here musb_remove() -\u0026gt; sunxi_musb_exit() -\u0026gt; devm_usb_put_phy() 3) register @musb_driver again musb_probe() -\u0026gt; sunxi_musb_init() use the phy here but the phy has been released at 2). ... Fixed by reverting the commit, namely, removing devm_usb_put_phy() from sunxi_musb_exit().(CVE-2024-50269)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: btrfs: reinitialize delayed ref list after deleting it from the list At insert_delayed_ref() if we need to update the action of an existing ref to BTRFS_DROP_DELAYED_REF, we delete the ref from its ref head\u0026apos;s ref_add_list using list_del(), which leaves the ref\u0026apos;s add_list member not reinitialized, as list_del() sets the next and prev members of the list to LIST_POISON1 and LIST_POISON2, respectively. If later we end up calling drop_delayed_ref() against the ref, which can happen during merging or when destroying delayed refs due to a transaction abort, we can trigger a crash since at drop_delayed_ref() we call list_empty() against the ref\u0026apos;s add_list, which returns false since the list was not reinitialized after the list_del() and as a consequence we call list_del() again at drop_delayed_ref(). This results in an invalid list access since the next and prev members are set to poison pointers, resulting in a splat if CONFIG_LIST_HARDENED and CONFIG_DEBUG_LIST are set or invalid poison pointer dereferences otherwise. So fix this by deleting from the list with list_del_init() instead.(CVE-2024-50273)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: media: av7110: fix a spectre vulnerability As warned by smatch: drivers/staging/media/av7110/av7110_ca.c:270 dvb_ca_ioctl() warn: potential spectre issue \u0026apos;av7110-\u0026gt;ci_slot\u0026apos; [w] (local cap) There is a spectre-related vulnerability at the code. Fix it.(CVE-2024-50289)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: security/keys: fix slab-out-of-bounds in key_task_permission KASAN reports an out of bounds read: BUG: KASAN: slab-out-of-bounds in __kuid_val include/linux/uidgid.h:36 BUG: KASAN: slab-out-of-bounds in uid_eq include/linux/uidgid.h:63 [inline] BUG: KASAN: slab-out-of-bounds in key_task_permission+0x394/0x410 security/keys/permission.c:54 Read of size 4 at addr ffff88813c3ab618 by task stress-ng/4362 CPU: 2 PID: 4362 Comm: stress-ng Not tainted 5.10.0-14930-gafbffd6c3ede #15 Call Trace: __dump_stack lib/dump_stack.c:82 [inline] dump_stack+0x107/0x167 lib/dump_stack.c:123 print_address_description.constprop.0+0x19/0x170 mm/kasan/report.c:400 __kasan_report.cold+0x6c/0x84 mm/kasan/report.c:560 kasan_report+0x3a/0x50 mm/kasan/report.c:585 __kuid_val include/linux/uidgid.h:36 [inline] uid_eq include/linux/uidgid.h:63 [inline] key_task_permission+0x394/0x410 security/keys/permission.c:54 search_nested_keyrings+0x90e/0xe90 security/keys/keyring.c:793 This issue was also reported by syzbot. It can be reproduced by following these steps(more details [1]): 1. Obtain more than 32 inputs that have similar hashes, which ends with the pattern \u0026apos;0xxxxxxxe6\u0026apos;. 2. Reboot and add the keys obtained in step 1. The reproducer demonstrates how this issue happened: 1. In the search_nested_keyrings function, when it iterates through the slots in a node(below tag ascend_to_node), if the slot pointer is meta and node-\u0026gt;back_pointer != NULL(it means a root), it will proceed to descend_to_node. However, there is an exception. If node is the root, and one of the slots points to a shortcut, it will be treated as a keyring. 2. Whether the ptr is keyring decided by keyring_ptr_is_keyring function. However, KEYRING_PTR_SUBTYPE is 0x2UL, the same as ASSOC_ARRAY_PTR_SUBTYPE_MASK. 3. When 32 keys with the similar hashes are added to the tree, the ROOT has keys with hashes that are not similar (e.g. slot 0) and it splits NODE A without using a shortcut. When NODE A is filled with keys that all hashes are xxe6, the keys are similar, NODE A will split with a shortcut. Finally, it forms the tree as shown below, where slot 6 points to a shortcut. NODE A +------\u0026gt;+---+ ROOT | | 0 | xxe6 +---+ | +---+ xxxx | 0 | shortcut : : xxe6 +---+ | +---+ xxe6 : : | | | xxe6 +---+ | +---+ | 6 |---+ : : xxe6 +---+ +---+ xxe6 : : | f | xxe6 +---+ +---+ xxe6 | f | +---+ 4. As mentioned above, If a slot(slot 6) of the root points to a shortcut, it may be mistakenly transferred to a key*, leading to a read out-of-bounds read. To fix this issue, one should jump to descend_to_node if the ptr is a shortcut, regardless of whether the node is root or not. [1] https://lore.kernel.org/linux-kernel/1cfa878e-8c7b-4570-8606-21daf5e13ce7@huaweicloud.com/ [jarkko: tweaked the commit message a bit to have an appropriate closes tag.](CVE-2024-50301)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: io_uring/rw: fix missing NOWAIT check for O_DIRECT start write When io_uring starts a write, it\u0026apos;ll call kiocb_start_write() to bump the super block rwsem, preventing any freezes from happening while that write is in-flight. The freeze side will grab that rwsem for writing, excluding any new writers from happening and waiting for existing writes to finish. But io_uring unconditionally uses kiocb_start_write(), which will block if someone is currently attempting to freeze the mount point. This causes a deadlock where freeze is waiting for previous writes to complete, but the previous writes cannot complete, as the task that is supposed to complete them is blocked waiting on starting a new write. This results in the following stuck trace showing that dependency with the write blocked starting a new write: task:fio state:D stack:0 pid:886 tgid:886 ppid:876 Call trace: __switch_to+0x1d8/0x348 __schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpu_rwsem_wait+0x1e8/0x3f8 __percpu_down_read+0xe8/0x500 io_write+0xbb8/0xff8 io_issue_sqe+0x10c/0x1020 io_submit_sqes+0x614/0x2110 __arm64_sys_io_uring_enter+0x524/0x1038 invoke_syscall+0x74/0x268 el0_svc_common.constprop.0+0x160/0x238 do_el0_svc+0x44/0x60 el0_svc+0x44/0xb0 el0t_64_sync_handler+0x118/0x128 el0t_64_sync+0x168/0x170 INFO: task fsfreeze:7364 blocked for more than 15 seconds. Not tainted 6.12.0-rc5-00063-g76aaf945701c #7963 with the attempting freezer stuck trying to grab the rwsem: task:fsfreeze state:D stack:0 pid:7364 tgid:7364 ppid:995 Call trace: __switch_to+0x1d8/0x348 __schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpu_down_write+0x2b0/0x680 freeze_super+0x248/0x8a8 do_vfs_ioctl+0x149c/0x1b18 __arm64_sys_ioctl+0xd0/0x1a0 invoke_syscall+0x74/0x268 el0_svc_common.constprop.0+0x160/0x238 do_el0_svc+0x44/0x60 el0_svc+0x44/0xb0 el0t_64_sync_handler+0x118/0x128 el0t_64_sync+0x168/0x170 Fix this by having the io_uring side honor IOCB_NOWAIT, and only attempt a blocking grab of the super block rwsem if it isn\u0026apos;t set. For normal issue where IOCB_NOWAIT would always be set, this returns -EAGAIN which will have io_uring core issue a blocking attempt of the write. That will in turn also get completions run, ensuring forward progress. Since freezing requires CAP_SYS_ADMIN in the first place, this isn\u0026apos;t something that can be triggered by a regular user.(CVE-2024-53052)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: media: s5p-jpeg: prevent buffer overflows The current logic allows word to be less than 2. If this happens, there will be buffer overflows, as reported by smatch. Add extra checks to prevent it. While here, remove an unused word = 0 assignment.(CVE-2024-53061)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: nfs: Fix KMSAN warning in decode_getfattr_attrs() Fix the following KMSAN warning: CPU: 1 UID: 0 PID: 7651 Comm: cp Tainted: G B Tainted: [B]=BAD_PAGE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) ===================================================== ===================================================== BUG: KMSAN: uninit-value in decode_getfattr_attrs+0x2d6d/0x2f90 decode_getfattr_attrs+0x2d6d/0x2f90 decode_getfattr_generic+0x806/0xb00 nfs4_xdr_dec_getattr+0x1de/0x240 rpcauth_unwrap_resp_decode+0xab/0x100 rpcauth_unwrap_resp+0x95/0xc0 call_decode+0x4ff/0xb50 __rpc_execute+0x57b/0x19d0 rpc_execute+0x368/0x5e0 rpc_run_task+0xcfe/0xee0 nfs4_proc_getattr+0x5b5/0x990 __nfs_revalidate_inode+0x477/0xd00 nfs_access_get_cached+0x1021/0x1cc0 nfs_do_access+0x9f/0xae0 nfs_permission+0x1e4/0x8c0 inode_permission+0x356/0x6c0 link_path_walk+0x958/0x1330 path_lookupat+0xce/0x6b0 filename_lookup+0x23e/0x770 vfs_statx+0xe7/0x970 vfs_fstatat+0x1f2/0x2c0 __se_sys_newfstatat+0x67/0x880 __x64_sys_newfstatat+0xbd/0x120 x64_sys_call+0x1826/0x3cf0 do_syscall_64+0xd0/0x1b0 entry_SYSCALL_64_after_hwframe+0x77/0x7f The KMSAN warning is triggered in decode_getfattr_attrs(), when calling decode_attr_mdsthreshold(). It appears that fattr-\u0026gt;mdsthreshold is not initialized. Fix the issue by initializing fattr-\u0026gt;mdsthreshold to NULL in nfs_fattr_init().(CVE-2024-53066)",
"id": "OESA-2024-2493",
"modified": "2026-08-06T11:07:58Z",
"published": "2024-11-29T11:07:58Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2493"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43817"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45018"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46713"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47745"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47747"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47749"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49899"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49929"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49952"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50045"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50062"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50085"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50089"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50141"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50143"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50179"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50180"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50192"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50195"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50202"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50205"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50229"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50230"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50241"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50248"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50262"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50265"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50269"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50273"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50289"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50301"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53052"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53061"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53066"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2024-43817",
"CVE-2024-45018",
"CVE-2024-46713",
"CVE-2024-47745",
"CVE-2024-47747",
"CVE-2024-47749",
"CVE-2024-49899",
"CVE-2024-49929",
"CVE-2024-49952",
"CVE-2024-50045",
"CVE-2024-50062",
"CVE-2024-50085",
"CVE-2024-50089",
"CVE-2024-50141",
"CVE-2024-50143",
"CVE-2024-50179",
"CVE-2024-50180",
"CVE-2024-50192",
"CVE-2024-50195",
"CVE-2024-50202",
"CVE-2024-50205",
"CVE-2024-50229",
"CVE-2024-50230",
"CVE-2024-50241",
"CVE-2024-50248",
"CVE-2024-50262",
"CVE-2024-50265",
"CVE-2024-50269",
"CVE-2024-50273",
"CVE-2024-50289",
"CVE-2024-50301",
"CVE-2024-53052",
"CVE-2024-53061",
"CVE-2024-53066"
]
}
OESA-2024-2494 (CVE-2023-52784)
Vulnerability from osv_openeuler – Published: 2024-11-29 11:07 – Updated: 2026-08-06 11:07 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
bonding: stop the device in bond_setup_by_slave()
Commit 9eed321cde22 ("net: lapbether: only support ethernet devices") has been able to keep syzbot away from net/lapb, until today.
In the following splat [1], the issue is that a lapbether device has been created on a bonding device without members. Then adding a non ARPHRD_ETHER member forced the bonding master to change its type.
The fix is to make sure we call dev_close() in bond_setup_by_slave() so that the potential linked lapbether devices (or any other devices having assumptions on the physical device) are removed.
A similar bug has been addressed in commit 40baec225765 ("bonding: fix panic on non-ARPHRD_ETHER enslave failure")
[1] skbuff: skb_under_panic: text:ffff800089508810 len:44 put:40 head:ffff0000c78e7c00 data:ffff0000c78e7bea tail:0x16 end:0x140 dev:bond0 kernel BUG at net/core/skbuff.c:192 ! Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP Modules linked in: CPU: 0 PID: 6007 Comm: syz-executor383 Not tainted 6.6.0-rc3-syzkaller-gbf6547d8715b #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/04/2023 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : skb_panic net/core/skbuff.c:188 [inline] pc : skb_under_panic+0x13c/0x140 net/core/skbuff.c:202 lr : skb_panic net/core/skbuff.c:188 [inline] lr : skb_under_panic+0x13c/0x140 net/core/skbuff.c:202 sp : ffff800096a06aa0 x29: ffff800096a06ab0 x28: ffff800096a06ba0 x27: dfff800000000000 x26: ffff0000ce9b9b50 x25: 0000000000000016 x24: ffff0000c78e7bea x23: ffff0000c78e7c00 x22: 000000000000002c x21: 0000000000000140 x20: 0000000000000028 x19: ffff800089508810 x18: ffff800096a06100 x17: 0000000000000000 x16: ffff80008a629a3c x15: 0000000000000001 x14: 1fffe00036837a32 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000201 x10: 0000000000000000 x9 : cb50b496c519aa00 x8 : cb50b496c519aa00 x7 : 0000000000000001 x6 : 0000000000000001 x5 : ffff800096a063b8 x4 : ffff80008e280f80 x3 : ffff8000805ad11c x2 : 0000000000000001 x1 : 0000000100000201 x0 : 0000000000000086 Call trace: skb_panic net/core/skbuff.c:188 [inline] skb_under_panic+0x13c/0x140 net/core/skbuff.c:202 skb_push+0xf0/0x108 net/core/skbuff.c:2446 ip6gre_header+0xbc/0x738 net/ipv6/ip6_gre.c:1384 dev_hard_header include/linux/netdevice.h:3136 [inline] lapbeth_data_transmit+0x1c4/0x298 drivers/net/wan/lapbether.c:257 lapb_data_transmit+0x8c/0xb0 net/lapb/lapb_iface.c:447 lapb_transmit_buffer+0x178/0x204 net/lapb/lapb_out.c:149 lapb_send_control+0x220/0x320 net/lapb/lapb_subr.c:251 __lapb_disconnect_request+0x9c/0x17c net/lapb/lapb_iface.c:326 lapb_device_event+0x288/0x4e0 net/lapb/lapb_iface.c:492 notifier_call_chain+0x1a4/0x510 kernel/notifier.c:93 raw_notifier_call_chain+0x3c/0x50 kernel/notifier.c:461 call_netdevice_notifiers_info net/core/dev.c:1970 [inline] call_netdevice_notifiers_extack net/core/dev.c:2008 [inline] call_netdevice_notifiers net/core/dev.c:2022 [inline] __dev_close_many+0x1b8/0x3c4 net/core/dev.c:1508 dev_close_many+0x1e0/0x470 net/core/dev.c:1559 dev_close+0x174/0x250 net/core/dev.c:1585 lapbeth_device_event+0x2e4/0x958 drivers/net/wan/lapbether.c:466 notifier_call_chain+0x1a4/0x510 kernel/notifier.c:93 raw_notifier_call_chain+0x3c/0x50 kernel/notifier.c:461 call_netdevice_notifiers_info net/core/dev.c:1970 [inline] call_netdevice_notifiers_extack net/core/dev.c:2008 [inline] call_netdevice_notifiers net/core/dev.c:2022 [inline] __dev_close_many+0x1b8/0x3c4 net/core/dev.c:1508 dev_close_many+0x1e0/0x470 net/core/dev.c:1559 dev_close+0x174/0x250 net/core/dev.c:1585 bond_enslave+0x2298/0x30cc drivers/net/bonding/bond_main.c:2332 bond_do_ioctl+0x268/0xc64 drivers/net/bonding/bond_main.c:4539 dev_ifsioc+0x754/0x9ac dev_ioctl+0x4d8/0xd34 net/core/dev_ioctl.c:786 sock_do_ioctl+0x1d4/0x2d0 net/socket.c:1217 sock_ioctl+0x4e8/0x834 net/socket.c:1322 vfs_ioctl fs/ioctl.c:51 [inline] __do_ ---truncated---(CVE-2023-52784)
In the Linux kernel, the following vulnerability has been resolved:
net: missing check virtio
Two missing check in virtio_net_hdr_to_skb() allowed syzbot to crash kernels again
-
After the skb_segment function the buffer may become non-linear (nr_frags != 0), but since the SKBTX_SHARED_FRAG flag is not set anywhere the __skb_linearize function will not be executed, then the buffer will remain non-linear. Then the condition (offset >= skb_headlen(skb)) becomes true, which causes WARN_ON_ONCE in skb_checksum_help.
-
The struct sk_buff and struct virtio_net_hdr members must be mathematically related. (gso_size) must be greater than (needed) otherwise WARN_ON_ONCE. (remainder) must be greater than (needed) otherwise WARN_ON_ONCE. (remainder) may be 0 if division is without remainder.
offset+2 (4191) > skb_headlen() (1116) WARNING: CPU: 1 PID: 5084 at net/core/dev.c:3303 skb_checksum_help+0x5e2/0x740 net/core/dev.c:3303 Modules linked in: CPU: 1 PID: 5084 Comm: syz-executor336 Not tainted 6.7.0-rc3-syzkaller-00014-gdf60cee26a2e #0 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 11/10/2023 RIP: 0010:skb_checksum_help+0x5e2/0x740 net/core/dev.c:3303 Code: 89 e8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 52 01 00 00 44 89 e2 2b 53 74 4c 89 ee 48 c7 c7 40 57 e9 8b e8 af 8f dd f8 90 <0f> 0b 90 90 e9 87 fe ff ff e8 40 0f 6e f9 e9 4b fa ff ff 48 89 ef RSP: 0018:ffffc90003a9f338 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff888025125780 RCX: ffffffff814db209 RDX: ffff888015393b80 RSI: ffffffff814db216 RDI: 0000000000000001 RBP: ffff8880251257f4 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000001 R12: 000000000000045c R13: 000000000000105f R14: ffff8880251257f0 R15: 000000000000105d FS: 0000555555c24380(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000002000f000 CR3: 0000000023151000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ip_do_fragment+0xa1b/0x18b0 net/ipv4/ip_output.c:777 ip_fragment.constprop.0+0x161/0x230 net/ipv4/ip_output.c:584 ip_finish_output_gso net/ipv4/ip_output.c:286 [inline] __ip_finish_output net/ipv4/ip_output.c:308 [inline] __ip_finish_output+0x49c/0x650 net/ipv4/ip_output.c:295 ip_finish_output+0x31/0x310 net/ipv4/ip_output.c:323 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip_output+0x13b/0x2a0 net/ipv4/ip_output.c:433 dst_output include/net/dst.h:451 [inline] ip_local_out+0xaf/0x1a0 net/ipv4/ip_output.c:129 iptunnel_xmit+0x5b4/0x9b0 net/ipv4/ip_tunnel_core.c:82 ipip6_tunnel_xmit net/ipv6/sit.c:1034 [inline] sit_tunnel_xmit+0xed2/0x28f0 net/ipv6/sit.c:1076 __netdev_start_xmit include/linux/netdevice.h:4940 [inline] netdev_start_xmit include/linux/netdevice.h:4954 [inline] xmit_one net/core/dev.c:3545 [inline] dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3561 __dev_queue_xmit+0x7c1/0x3d60 net/core/dev.c:4346 dev_queue_xmit include/linux/netdevice.h:3134 [inline] packet_xmit+0x257/0x380 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3087 [inline] packet_sendmsg+0x24ca/0x5240 net/packet/af_packet.c:3119 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0xd5/0x180 net/socket.c:745 __sys_sendto+0x255/0x340 net/socket.c:2190 __do_sys_sendto net/socket.c:2202 [inline] __se_sys_sendto net/socket.c:2198 [inline] __x64_sys_sendto+0xe0/0x1b0 net/socket.c:2198 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x40/0x110 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x63/0x6b
Found by Linux Verification Center (linuxtesting.org) with Syzkaller(CVE-2024-43817)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: flowtable: initialise extack before use
Fix missing initialisation of extack in flow offload.(CVE-2024-45018)
In the Linux kernel, the following vulnerability has been resolved:
perf/aux: Fix AUX buffer serialization
Ole reported that event->mmap_mutex is strictly insufficient to serialize the AUX buffer, add a per RB mutex to fully serialize it.
Note that in the lock order comment the perf_event::mmap_mutex order was already wrong, that is, it nesting under mmap_lock is not new with this patch.(CVE-2024-46713)
In the Linux kernel, the following vulnerability has been resolved: mm: call the security_mmap_file() LSM hook in remap_file_pages() The remap_file_pages syscall handler calls do_mmap() directly, which doesn't contain the LSM security check. And if the process has called personality(READ_IMPLIES_EXEC) before and remap_file_pages() is called for RW pages, this will actually result in remapping the pages to RWX, bypassing a W^X policy enforced by SELinux. So we should check prot by security_mmap_file LSM hook in the remap_file_pages syscall handler before do_mmap() is called. Otherwise, it potentially permits an attacker to bypass a W^X policy enforced by SELinux. The bypass is similar to CVE-2016-10044, which bypass the same thing via AIO and can be found in [1]. The PoC: $ cat > test.c int main(void) { size_t pagesz = sysconf(_SC_PAGE_SIZE); int mfd = syscall(SYS_memfd_create, "test", 0); const char *buf = mmap(NULL, 4 * pagesz, PROT_READ | PROT_WRITE, MAP_SHARED, mfd, 0); unsigned int old = syscall(SYS_personality, 0xffffffff); syscall(SYS_personality, READ_IMPLIES_EXEC | old); syscall(SYS_remap_file_pages, buf, pagesz, 0, 2, 0); syscall(SYS_personality, old); // show the RWX page exists even if W^X policy is enforced int fd = open("/proc/self/maps", O_RDONLY); unsigned char buf2[1024]; while (1) { int ret = read(fd, buf2, 1024); if (ret <= 0) break; write(1, buf2, ret); } close(fd); } $ gcc test.c -o test $ ./test | grep rwx 7f1836c34000-7f1836c35000 rwxs 00002000 00:01 2050 /memfd:test (deleted) PM: subject line tweaks
In the Linux kernel, the following vulnerability has been resolved: net: seeq: Fix use after free vulnerability in ether3 Driver Due to Race Condition In the ether3_probe function, a timer is initialized with a callback function ether3_ledoff, bound to &prev(dev)->timer. Once the timer is started, there is a risk of a race condition if the module or device is removed, triggering the ether3_remove function to perform cleanup. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | ether3_ledoff ether3_remove | free_netdev(dev); | put_devic | kfree(dev); | | ether3_outw(priv(dev)->regs.config2 |= CFG2_CTRLO, REG_CONFIG2); | // use dev Fix it by ensuring that the timer is canceled before proceeding with the cleanup in ether3_remove.(CVE-2024-47747)
In the Linux kernel, the following vulnerability has been resolved: RDMA/cxgb4: Added NULL check for lookup_atid The lookup_atid() function can return NULL if the ATID is invalid or does not exist in the identifier table, which could lead to dereferencing a null pointer without a check in the act_establish() and act_open_rpl() functions. Add a NULL check to prevent null pointer dereferencing. Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-47749)
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Initialize denominators' default to 1 [WHAT & HOW] Variables used as denominators and maybe not assigned to other values, should not be 0. Change their default to 1 so they are never 0. This fixes 10 DIVIDE_BY_ZERO issues reported by Coverity.(CVE-2024-49899)
In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: avoid NULL pointer dereference iwl_mvm_tx_skb_sta() and iwl_mvm_tx_mpdu() verify that the mvmvsta pointer is not NULL. It retrieves this pointer using iwl_mvm_sta_from_mac80211, which is dereferencing the ieee80211_sta pointer. If sta is NULL, iwl_mvm_sta_from_mac80211 will dereference a NULL pointer. Fix this by checking the sta pointer before retrieving the mvmsta from it. If sta is not NULL, then mvmsta isn't either.(CVE-2024-49929)
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: prevent nf_skb_duplicated corruption syzbot found that nf_dup_ipv4() or nf_dup_ipv6() could write per-cpu variable nf_skb_duplicated in an unsafe way [1]. Disabling preemption as hinted by the splat is not enough, we have to disable soft interrupts as well. [1] BUG: using __this_cpu_write() in preemptible [00000000] code: syz.4.282/6316 caller is nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87 CPU: 0 UID: 0 PID: 6316 Comm: syz.4.282 Not tainted 6.11.0-rc7-syzkaller-00104-g7052622fccb1 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 check_preemption_disabled+0x10e/0x120 lib/smp_processor_id.c:49 nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87 nft_dup_ipv4_eval+0x1db/0x300 net/ipv4/netfilter/nft_dup_ipv4.c:30 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x4ad/0x1da0 net/netfilter/nf_tables_core.c:288 nft_do_chain_ipv4+0x202/0x320 net/netfilter/nft_chain_filter.c:23 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626 nf_hook+0x2c4/0x450 include/linux/netfilter.h:269 NF_HOOK_COND include/linux/netfilter.h:302 [inline] ip_output+0x185/0x230 net/ipv4/ip_output.c:433 ip_local_out net/ipv4/ip_output.c:129 [inline] ip_send_skb+0x74/0x100 net/ipv4/ip_output.c:1495 udp_send_skb+0xacf/0x1650 net/ipv4/udp.c:981 udp_sendmsg+0x1c21/0x2a60 net/ipv4/udp.c:1269 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x1a6/0x270 net/socket.c:745 _syssendmsg+0x525/0x7d0 net/socket.c:2597 _sys_sendmsg net/socket.c:2651 [inline] __sys_sendmmsg+0x3b2/0x740 net/socket.c:2737 __do_sys_sendmmsg net/socket.c:2766 [inline] __se_sys_sendmmsg net/socket.c:2763 [inline] __x64_sys_sendmmsg+0xa0/0xb0 net/socket.c:2763 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f4ce4f7def9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f4ce5d4a038 EFLAGS: 00000246 ORIG_RAX: 0000000000000133 RAX: ffffffffffffffda RBX: 00007f4ce5135f80 RCX: 00007f4ce4f7def9 RDX: 0000000000000001 RSI: 0000000020005d40 RDI: 0000000000000006 RBP: 00007f4ce4ff0b76 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f4ce5135f80 R15: 00007ffd4cbc6d68 </TASK>(CVE-2024-49952)
In the Linux kernel, the following vulnerability has been resolved: netfilter: br_netfilter: fix panic with metadata_dst skb Fix a kernel panic in the br_netfilter module when sending untagged traffic via a VxLAN device. This happens during the check for fragmentation in br_nf_dev_queue_xmit. It is dependent on: 1) the br_netfilter module being loaded; 2) net.bridge.bridge-nf-call-iptables set to 1; 3) a bridge with a VxLAN (single-vxlan-device) netdevice as a bridge port; 4) untagged frames with size higher than the VxLAN MTU forwarded/flooded When forwarding the untagged packet to the VxLAN bridge port, before the netfilter hooks are called, br_handle_egress_vlan_tunnel is called and changes the skb_dst to the tunnel dst. The tunnel_dst is a metadata type of dst, i.e., skb_valid_dst(skb) is false, and metadata->dst.dev is NULL. Then in the br_netfilter hooks, in br_nf_dev_queue_xmit, there's a check for frames that needs to be fragmented: frames with higher MTU than the VxLAN device end up calling br_nf_ip_fragment, which in turns call ip_skb_dst_mtu. The ip_dst_mtu tries to use the skb_dst(skb) as if it was a valid dst with valid dst->dev, thus the crash. This case was never supported in the first place, so drop the packet instead. PING 10.0.0.2 (10.0.0.2) from 0.0.0.0 h1-eth0: 2000(2028) bytes of data. [ 176.291791] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000110 [ 176.292101] Mem abort info: [ 176.292184] ESR = 0x0000000096000004 [ 176.292322] EC = 0x25: DABT (current EL), IL = 32 bits [ 176.292530] SET = 0, FnV = 0 [ 176.292709] EA = 0, S1PTW = 0 [ 176.292862] FSC = 0x04: level 0 translation fault [ 176.293013] Data abort info: [ 176.293104] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 176.293488] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 176.293787] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 176.293995] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000043ef5000 [ 176.294166] [0000000000000110] pgd=0000000000000000, p4d=0000000000000000 [ 176.294827] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 176.295252] Modules linked in: vxlan ip6_udp_tunnel udp_tunnel veth br_netfilter bridge stp llc ipv6 crct10dif_ce [ 176.295923] CPU: 0 PID: 188 Comm: ping Not tainted 6.8.0-rc3-g5b3fbd61b9d1 #2 [ 176.296314] Hardware name: linux,dummy-virt (DT) [ 176.296535] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 176.296808] pc : br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter] [ 176.297382] lr : br_nf_dev_queue_xmit+0x2ac/0x4ec [br_netfilter] [ 176.297636] sp : ffff800080003630 [ 176.297743] x29: ffff800080003630 x28: 0000000000000008 x27: ffff6828c49ad9f8 [ 176.298093] x26: ffff6828c49ad000 x25: 0000000000000000 x24: 00000000000003e8 [ 176.298430] x23: 0000000000000000 x22: ffff6828c4960b40 x21: ffff6828c3b16d28 [ 176.298652] x20: ffff6828c3167048 x19: ffff6828c3b16d00 x18: 0000000000000014 [ 176.298926] x17: ffffb0476322f000 x16: ffffb7e164023730 x15: 0000000095744632 [ 176.299296] x14: ffff6828c3f1c880 x13: 0000000000000002 x12: ffffb7e137926a70 [ 176.299574] x11: 0000000000000001 x10: ffff6828c3f1c898 x9 : 0000000000000000 [ 176.300049] x8 : ffff6828c49bf070 x7 : 0008460f18d5f20e x6 : f20e0100bebafeca [ 176.300302] x5 : ffff6828c7f918fe x4 : ffff6828c49bf070 x3 : 0000000000000000 [ 176.300586] x2 : 0000000000000000 x1 : ffff6828c3c7ad00 x0 : ffff6828c7f918f0 [ 176.300889] Call trace: [ 176.301123] br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter] [ 176.301411] br_nf_post_routing+0x2a8/0x3e4 [br_netfilter] [ 176.301703] nf_hook_slow+0x48/0x124 [ 176.302060] br_forward_finish+0xc8/0xe8 [bridge] [ 176.302371] br_nf_hook_thresh+0x124/0x134 [br_netfilter] [ 176.302605] br_nf_forward_finish+0x118/0x22c [br_netfilter] [ 176.302824] br_nf_forward_ip.part.0+0x264/0x290 [br_netfilter] [ 176.303136] br_nf_forward+0x2b8/0x4e0 [br_netfilter] [ 176.303359] nf_hook_slow+0x48/0x124 [ 176.303 ---truncated---(CVE-2024-50045)
In the Linux kernel, the following vulnerability has been resolved: RDMA/rtrs-srv: Avoid null pointer deref during path establishment For RTRS path establishment, RTRS client initiates and completes con_num of connections. After establishing all its connections, the information is exchanged between the client and server through the info_req message. During this exchange, it is essential that all connections have been established, and the state of the RTRS srv path is CONNECTED. So add these sanity checks, to make sure we detect and abort process in error scenarios to avoid null pointer deref.(CVE-2024-50062)
In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: fix UaF read in mptcp_pm_nl_rm_addr_or_subflow Syzkaller reported this splat: ================================================================== BUG: KASAN: slab-use-after-free in mptcp_pm_nl_rm_addr_or_subflow+0xb44/0xcc0 net/mptcp/pm_netlink.c:881 Read of size 4 at addr ffff8880569ac858 by task syz.1.2799/14662 CPU: 0 UID: 0 PID: 14662 Comm: syz.1.2799 Not tainted 6.12.0-rc2-syzkaller-00307-g36c254515dc6 #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc3/0x620 mm/kasan/report.c:488 kasan_report+0xd9/0x110 mm/kasan/report.c:601 mptcp_pm_nl_rm_addr_or_subflow+0xb44/0xcc0 net/mptcp/pm_netlink.c:881 mptcp_pm_nl_rm_subflow_received net/mptcp/pm_netlink.c:914 [inline] mptcp_nl_remove_id_zero_address+0x305/0x4a0 net/mptcp/pm_netlink.c:1572 mptcp_pm_nl_del_addr_doit+0x5c9/0x770 net/mptcp/pm_netlink.c:1603 genl_family_rcv_msg_doit+0x202/0x2f0 net/netlink/genetlink.c:1115 genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0x565/0x800 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x165/0x410 net/netlink/af_netlink.c:2551 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1331 [inline] netlink_unicast+0x53c/0x7f0 net/netlink/af_netlink.c:1357 netlink_sendmsg+0x8b8/0xd70 net/netlink/af_netlink.c:1901 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg net/socket.c:744 [inline] _syssendmsg+0x9ae/0xb40 net/socket.c:2607 _sys_sendmsg+0x135/0x1e0 net/socket.c:2661 __sys_sendmsg+0x117/0x1f0 net/socket.c:2690 do_syscall_32_irqs_on arch/x86/entry/common.c:165 [inline] __do_fast_syscall_32+0x73/0x120 arch/x86/entry/common.c:386 do_fast_syscall_32+0x32/0x80 arch/x86/entry/common.c:411 entry_SYSENTER_compat_after_hwframe+0x84/0x8e RIP: 0023:0xf7fe4579 Code: b8 01 10 06 03 74 b4 01 10 07 03 74 b0 01 10 08 03 74 d8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90 90 90 8d b4 26 00 00 00 00 8d b4 26 00 00 00 00 RSP: 002b:00000000f574556c EFLAGS: 00000296 ORIG_RAX: 0000000000000172 RAX: ffffffffffffffda RBX: 000000000000000b RCX: 0000000020000140 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000296 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 </TASK> Allocated by task 5387: kasan_save_stack+0x33/0x60 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:394 kmalloc_noprof include/linux/slab.h:878 [inline] kzalloc_noprof include/linux/slab.h:1014 [inline] subflow_create_ctx+0x87/0x2a0 net/mptcp/subflow.c:1803 subflow_ulp_init+0xc3/0x4d0 net/mptcp/subflow.c:1956 __tcp_set_ulp net/ipv4/tcp_ulp.c:146 [inline] tcp_set_ulp+0x326/0x7f0 net/ipv4/tcp_ulp.c:167 mptcp_subflow_create_socket+0x4ae/0x10a0 net/mptcp/subflow.c:1764 __mptcp_subflow_connect+0x3cc/0x1490 net/mptcp/subflow.c:1592 mptcp_pm_create_subflow_or_signal_addr+0xbda/0x23a0 net/mptcp/pm_netlink.c:642 mptcp_pm_nl_fully_established net/mptcp/pm_netlink.c:650 [inline] mptcp_pm_nl_work+0x3a1/0x4f0 net/mptcp/pm_netlink.c:943 mptcp_worker+0x15a/0x1240 net/mptcp/protocol.c:2777 process_one_work+0x958/0x1b30 kernel/workqueue.c:3229 process_scheduled_works kernel/workqueue.c:3310 [inline] worker_thread+0x6c8/0xf00 kernel/workqueue.c:3391 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/ke ---truncated---(CVE-2024-50085)
In the Linux kernel, the following vulnerability has been resolved: unicode: Don't special case ignorable code points We don't need to handle them separately. Instead, just let them decompose/casefold to themselves.(CVE-2024-50089)
In the Linux kernel, the following vulnerability has been resolved: ACPI: PRM: Find EFI_MEMORY_RUNTIME block for PRM handler and context PRMT needs to find the correct type of block to translate the PA-VA mapping for EFI runtime services. The issue arises because the PRMT is finding a block of type EFI_CONVENTIONAL_MEMORY, which is not appropriate for runtime services as described in Section 2.2.2 (Runtime Services) of the UEFI Specification [1]. Since the PRM handler is a type of runtime service, this causes an exception when the PRM handler is called. [Firmware Bug]: Unable to handle paging request in EFI runtime service WARNING: CPU: 22 PID: 4330 at drivers/firmware/efi/runtime-wrappers.c:341 __efi_queue_work+0x11c/0x170 Call trace: Let PRMT find a block with EFI_MEMORY_RUNTIME for PRM handler and PRM context. If no suitable block is found, a warning message will be printed, but the procedure continues to manage the next PRM handler. However, if the PRM handler is actually called without proper allocation, it would result in a failure during error handling. By using the correct memory types for runtime services, ensure that the PRM handler and the context are properly mapped in the virtual address space during runtime, preventing the paging request error. The issue is really that only memory that has been remapped for runtime by the firmware can be used by the PRM handler, and so the region needs to have the EFI_MEMORY_RUNTIME attribute. rjw: Subject and changelog edits
In the Linux kernel, the following vulnerability has been resolved: udf: fix uninit-value use in udf_get_fileshortad Check for overflow when computing alen in udf_current_aext to mitigate later uninit-value use in udf_get_fileshortad KMSAN bug[1]. After applying the patch reproducer did not trigger any issue[2]. [1] https://syzkaller.appspot.com/bug?extid=8901c4560b7ab5c2f9df [2] https://syzkaller.appspot.com/x/log.txt?x=10242227980000(CVE-2024-50143)
In the Linux kernel, the following vulnerability has been resolved: ceph: remove the incorrect Fw reference check when dirtying pages When doing the direct-io reads it will also try to mark pages dirty, but for the read path it won't hold the Fw caps and there is case will it get the Fw reference.(CVE-2024-50179)
In the Linux kernel, the following vulnerability has been resolved: fbdev: sisfb: Fix strbuf array overflow The values of the variables xres and yres are placed in strbuf. These variables are obtained from strbuf1. The strbuf1 array contains digit characters and a space if the array contains non-digit characters. Then, when executing sprintf(strbuf, "%ux%ux8", xres, yres); more than 16 bytes will be written to strbuf. It is suggested to increase the size of the strbuf array to 24. Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-50180)
In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v4: Don't allow a VMOVP on a dying VPE Kunkun Jiang reported that there is a small window of opportunity for userspace to force a change of affinity for a VPE while the VPE has already been unmapped, but the corresponding doorbell interrupt still visible in /proc/irq/. Plug the race by checking the value of vmapp_count, which tracks whether the VPE is mapped ot not, and returning an error in this case. This involves making vmapp_count common to both GICv4.1 and its v4.0 ancestor.(CVE-2024-50192)
In the Linux kernel, the following vulnerability has been resolved: posix-clock: Fix missing timespec64 check in pc_clock_settime() As Andrew pointed out, it will make sense that the PTP core checked timespec64 struct's tv_sec and tv_nsec range before calling ptp->info->settime64(). As the man manual of clock_settime() said, if tp.tv_sec is negative or tp.tv_nsec is outside the range [0..999,999,999], it should return EINVAL, which include dynamic clocks which handles PTP clock, and the condition is consistent with timespec64_valid(). As Thomas suggested, timespec64_valid() only check the timespec is valid, but not ensure that the time is in a valid range, so check it ahead using timespec64_valid_strict() in pc_clock_settime() and return -EINVAL if not valid. There are some drivers that use tp->tv_sec and tp->tv_nsec directly to write registers without validity checks and assume that the higher layer has checked it, which is dangerous and will benefit from this, such as hclge_ptp_settime(), igb_ptp_settime_i210(), _rcar_gen4_ptp_settime(), and some drivers can remove the checks of itself.(CVE-2024-50195)
In the Linux kernel, the following vulnerability has been resolved: nilfs2: propagate directory read errors from nilfs_find_entry() Syzbot reported that a task hang occurs in vcs_open() during a fuzzing test for nilfs2. The root cause of this problem is that in nilfs_find_entry(), which searches for directory entries, ignores errors when loading a directory page/folio via nilfs_get_folio() fails. If the filesystem images is corrupted, and the i_size of the directory inode is large, and the directory page/folio is successfully read but fails the sanity check, for example when it is zero-filled, nilfs_check_folio() may continue to spit out error messages in bursts. Fix this issue by propagating the error to the callers when loading a page/folio fails in nilfs_find_entry(). The current interface of nilfs_find_entry() and its callers is outdated and cannot propagate error codes such as -EIO and -ENOMEM returned via nilfs_find_entry(), so fix it together.(CVE-2024-50202)
In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire-lib: Avoid division by zero in apply_constraint_to_size() The step variable is initialized to zero. It is changed in the loop, but if it's not changed it will remain zero. Add a variable check before the division. The observed behavior was introduced by commit 826b5de90c0b ("ALSA: firewire-lib: fix insufficient PCM rule for period/buffer size"), and it is difficult to show that any of the interval parameters will satisfy the snd_interval_test() condition with data from the amdtp_rate_table[] table. Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-50205)
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential deadlock with newly created symlinks Syzbot reported that page_symlink(), called by nilfs_symlink(), triggers memory reclamation involving the filesystem layer, which can result in circular lock dependencies among the reader/writer semaphore nilfs->ns_segctor_sem, s_writers percpu_rwsem (intwrite) and the fs_reclaim pseudo lock. This is because after commit 21fc61c73c39 ("don't put symlink bodies in pagecache into highmem"), the gfp flags of the page cache for symbolic links are overwritten to GFP_KERNEL via inode_nohighmem(). This is not a problem for symlinks read from the backing device, because the __GFP_FS flag is dropped after inode_nohighmem() is called. However, when a new symlink is created with nilfs_symlink(), the gfp flags remain overwritten to GFP_KERNEL. Then, memory allocation called from page_symlink() etc. triggers memory reclamation including the FS layer, which may call nilfs_evict_inode() or nilfs_dirty_inode(). And these can cause a deadlock if they are called while nilfs->ns_segctor_sem is held: Fix this issue by dropping the __GFP_FS flag from the page cache GFP flags of newly created symlinks in the same way that nilfs_new_inode() and __nilfs_read_inode() do, as a workaround until we adopt nofs allocation scope consistently or improve the locking constraints.(CVE-2024-50229)
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix kernel bug due to missing clearing of checked flag Syzbot reported that in directory operations after nilfs2 detects filesystem corruption and degrades to read-only, __block_write_begin_int(), which is called to prepare block writes, may fail the BUG_ON check for accesses exceeding the folio/page size, triggering a kernel bug. This was found to be because the "checked" flag of a page/folio was not cleared when it was discarded by nilfs2's own routine, which causes the sanity check of directory entries to be skipped when the directory page/folio is reloaded. So, fix that. This was necessary when the use of nilfs2's own page discard routine was applied to more than just metadata files.(CVE-2024-50230)
In the Linux kernel, the following vulnerability has been resolved: NFSD: Initialize struct nfsd4_copy earlier Ensure the refcount and async_copies fields are initialized early. cleanup_async_copy() will reference these fields if an error occurs in nfsd4_copy(). If they are not correctly initialized, at the very least, a refcount underflow occurs.(CVE-2024-50241)
In the Linux kernel, the following vulnerability has been resolved: ntfs3: Add bounds checking to mi_enum_attr() Added bounds checking to make sure that every attr don't stray beyond valid memory region.(CVE-2024-50248)
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix out-of-bounds write in trie_get_next_key() trie_get_next_key() allocates a node stack with size trie->max_prefixlen, while it writes (trie->max_prefixlen + 1) nodes to the stack when it has full paths from the root to leaves. For example, consider a trie with max_prefixlen is 8, and the nodes with key 0x00/0, 0x00/1, 0x00/2, ... 0x00/8 inserted. Subsequent calls to trie_get_next_key with _key with .prefixlen = 8 make 9 nodes be written on the node stack with size 8.(CVE-2024-50262)
In the Linux kernel, the following vulnerability has been resolved: ocfs2: remove entry once instead of null-ptr-dereference in ocfs2_xa_remove() Syzkaller is able to provoke null-ptr-dereference in ocfs2_xa_remove(): [ 57.319872] (a.out,1161,7):ocfs2_xa_remove:2028 ERROR: status = -12 [ 57.320420] (a.out,1161,7):ocfs2_xa_cleanup_value_truncate:1999 ERROR: Partial truncate while removing xattr overlay.upper. Leaking 1 clusters and removing the entry [ 57.321727] BUG: kernel NULL pointer dereference, address: 0000000000000004 [...] [ 57.325727] RIP: 0010:ocfs2_xa_block_wipe_namevalue+0x2a/0xc0 [...] [ 57.331328] Call Trace: [ 57.331477] <TASK> [...] [ 57.333511] ? do_user_addr_fault+0x3e5/0x740 [ 57.333778] ? exc_page_fault+0x70/0x170 [ 57.334016] ? asm_exc_page_fault+0x2b/0x30 [ 57.334263] ? __pfx_ocfs2_xa_block_wipe_namevalue+0x10/0x10 [ 57.334596] ? ocfs2_xa_block_wipe_namevalue+0x2a/0xc0 [ 57.334913] ocfs2_xa_remove_entry+0x23/0xc0 [ 57.335164] ocfs2_xa_set+0x704/0xcf0 [ 57.335381] ? _raw_spin_unlock+0x1a/0x40 [ 57.335620] ? ocfs2_inode_cache_unlock+0x16/0x20 [ 57.335915] ? trace_preempt_on+0x1e/0x70 [ 57.336153] ? start_this_handle+0x16c/0x500 [ 57.336410] ? preempt_count_sub+0x50/0x80 [ 57.336656] ? _raw_read_unlock+0x20/0x40 [ 57.336906] ? start_this_handle+0x16c/0x500 [ 57.337162] ocfs2_xattr_block_set+0xa6/0x1e0 [ 57.337424] __ocfs2_xattr_set_handle+0x1fd/0x5d0 [ 57.337706] ? ocfs2_start_trans+0x13d/0x290 [ 57.337971] ocfs2_xattr_set+0xb13/0xfb0 [ 57.338207] ? dput+0x46/0x1c0 [ 57.338393] ocfs2_xattr_trusted_set+0x28/0x30 [ 57.338665] ? ocfs2_xattr_trusted_set+0x28/0x30 [ 57.338948] __vfs_removexattr+0x92/0xc0 [ 57.339182] __vfs_removexattr_locked+0xd5/0x190 [ 57.339456] ? preempt_count_sub+0x50/0x80 [ 57.339705] vfs_removexattr+0x5f/0x100 [...] Reproducer uses faultinject facility to fail ocfs2_xa_remove() -> ocfs2_xa_value_truncate() with -ENOMEM. In this case the comment mentions that we can return 0 if ocfs2_xa_cleanup_value_truncate() is going to wipe the entry anyway. But the following 'rc' check is wrong and execution flow do 'ocfs2_xa_remove_entry(loc);' twice: * 1st: in ocfs2_xa_cleanup_value_truncate(); * 2nd: returning back to ocfs2_xa_remove() instead of going to 'out'. Fix this by skipping the 2nd removal of the same entry and making syzkaller repro happy.(CVE-2024-50265)
In the Linux kernel, the following vulnerability has been resolved: usb: musb: sunxi: Fix accessing an released usb phy Commit 6ed05c68cbca ("usb: musb: sunxi: Explicitly release USB PHY on exit") will cause that usb phy @glue->xceiv is accessed after released. 1) register platform driver @sunxi_musb_driver // get the usb phy @glue->xceiv sunxi_musb_probe() -> devm_usb_get_phy(). 2) register and unregister platform driver @musb_driver musb_probe() -> sunxi_musb_init() use the phy here //the phy is released here musb_remove() -> sunxi_musb_exit() -> devm_usb_put_phy() 3) register @musb_driver again musb_probe() -> sunxi_musb_init() use the phy here but the phy has been released at 2). ... Fixed by reverting the commit, namely, removing devm_usb_put_phy() from sunxi_musb_exit().(CVE-2024-50269)
In the Linux kernel, the following vulnerability has been resolved: btrfs: reinitialize delayed ref list after deleting it from the list At insert_delayed_ref() if we need to update the action of an existing ref to BTRFS_DROP_DELAYED_REF, we delete the ref from its ref head's ref_add_list using list_del(), which leaves the ref's add_list member not reinitialized, as list_del() sets the next and prev members of the list to LIST_POISON1 and LIST_POISON2, respectively. If later we end up calling drop_delayed_ref() against the ref, which can happen during merging or when destroying delayed refs due to a transaction abort, we can trigger a crash since at drop_delayed_ref() we call list_empty() against the ref's add_list, which returns false since the list was not reinitialized after the list_del() and as a consequence we call list_del() again at drop_delayed_ref(). This results in an invalid list access since the next and prev members are set to poison pointers, resulting in a splat if CONFIG_LIST_HARDENED and CONFIG_DEBUG_LIST are set or invalid poison pointer dereferences otherwise. So fix this by deleting from the list with list_del_init() instead.(CVE-2024-50273)
In the Linux kernel, the following vulnerability has been resolved: media: av7110: fix a spectre vulnerability As warned by smatch: drivers/staging/media/av7110/av7110_ca.c:270 dvb_ca_ioctl() warn: potential spectre issue 'av7110->ci_slot' [w] (local cap) There is a spectre-related vulnerability at the code. Fix it.(CVE-2024-50289)
In the Linux kernel, the following vulnerability has been resolved: security/keys: fix slab-out-of-bounds in key_task_permission KASAN reports an out of bounds read: BUG: KASAN: slab-out-of-bounds in __kuid_val include/linux/uidgid.h:36 BUG: KASAN: slab-out-of-bounds in uid_eq include/linux/uidgid.h:63 [inline] BUG: KASAN: slab-out-of-bounds in key_task_permission+0x394/0x410 security/keys/permission.c:54 Read of size 4 at addr ffff88813c3ab618 by task stress-ng/4362 CPU: 2 PID: 4362 Comm: stress-ng Not tainted 5.10.0-14930-gafbffd6c3ede #15 Call Trace: __dump_stack lib/dump_stack.c:82 [inline] dump_stack+0x107/0x167 lib/dump_stack.c:123 print_address_description.constprop.0+0x19/0x170 mm/kasan/report.c:400 __kasan_report.cold+0x6c/0x84 mm/kasan/report.c:560 kasan_report+0x3a/0x50 mm/kasan/report.c:585 __kuid_val include/linux/uidgid.h:36 [inline] uid_eq include/linux/uidgid.h:63 [inline] key_task_permission+0x394/0x410 security/keys/permission.c:54 search_nested_keyrings+0x90e/0xe90 security/keys/keyring.c:793 This issue was also reported by syzbot. It can be reproduced by following these steps(more details [1]): 1. Obtain more than 32 inputs that have similar hashes, which ends with the pattern '0xxxxxxxe6'. 2. Reboot and add the keys obtained in step 1. The reproducer demonstrates how this issue happened: 1. In the search_nested_keyrings function, when it iterates through the slots in a node(below tag ascend_to_node), if the slot pointer is meta and node->back_pointer != NULL(it means a root), it will proceed to descend_to_node. However, there is an exception. If node is the root, and one of the slots points to a shortcut, it will be treated as a keyring. 2. Whether the ptr is keyring decided by keyring_ptr_is_keyring function. However, KEYRING_PTR_SUBTYPE is 0x2UL, the same as ASSOC_ARRAY_PTR_SUBTYPE_MASK. 3. When 32 keys with the similar hashes are added to the tree, the ROOT has keys with hashes that are not similar (e.g. slot 0) and it splits NODE A without using a shortcut. When NODE A is filled with keys that all hashes are xxe6, the keys are similar, NODE A will split with a shortcut. Finally, it forms the tree as shown below, where slot 6 points to a shortcut. NODE A +------>+---+ ROOT | | 0 | xxe6 +---+ | +---+ xxxx | 0 | shortcut : : xxe6 +---+ | +---+ xxe6 : : | | | xxe6 +---+ | +---+ | 6 |---+ : : xxe6 +---+ +---+ xxe6 : : | f | xxe6 +---+ +---+ xxe6 | f | +---+ 4. As mentioned above, If a slot(slot 6) of the root points to a shortcut, it may be mistakenly transferred to a key*, leading to a read out-of-bounds read. To fix this issue, one should jump to descend_to_node if the ptr is a shortcut, regardless of whether the node is root or not. [1] https://lore.kernel.org/linux-kernel/1cfa878e-8c7b-4570-8606-21daf5e13ce7@huaweicloud.com/ jarkko: tweaked the commit message a bit to have an appropriate closes tag.
In the Linux kernel, the following vulnerability has been resolved: io_uring/rw: fix missing NOWAIT check for O_DIRECT start write When io_uring starts a write, it'll call kiocb_start_write() to bump the super block rwsem, preventing any freezes from happening while that write is in-flight. The freeze side will grab that rwsem for writing, excluding any new writers from happening and waiting for existing writes to finish. But io_uring unconditionally uses kiocb_start_write(), which will block if someone is currently attempting to freeze the mount point. This causes a deadlock where freeze is waiting for previous writes to complete, but the previous writes cannot complete, as the task that is supposed to complete them is blocked waiting on starting a new write. This results in the following stuck trace showing that dependency with the write blocked starting a new write: task:fio state:D stack:0 pid:886 tgid:886 ppid:876 Call trace: __switch_to+0x1d8/0x348 __schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpu_rwsem_wait+0x1e8/0x3f8 __percpu_down_read+0xe8/0x500 io_write+0xbb8/0xff8 io_issue_sqe+0x10c/0x1020 io_submit_sqes+0x614/0x2110 __arm64_sys_io_uring_enter+0x524/0x1038 invoke_syscall+0x74/0x268 el0_svc_common.constprop.0+0x160/0x238 do_el0_svc+0x44/0x60 el0_svc+0x44/0xb0 el0t_64_sync_handler+0x118/0x128 el0t_64_sync+0x168/0x170 INFO: task fsfreeze:7364 blocked for more than 15 seconds. Not tainted 6.12.0-rc5-00063-g76aaf945701c #7963 with the attempting freezer stuck trying to grab the rwsem: task:fsfreeze state:D stack:0 pid:7364 tgid:7364 ppid:995 Call trace: __switch_to+0x1d8/0x348 __schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpu_down_write+0x2b0/0x680 freeze_super+0x248/0x8a8 do_vfs_ioctl+0x149c/0x1b18 __arm64_sys_ioctl+0xd0/0x1a0 invoke_syscall+0x74/0x268 el0_svc_common.constprop.0+0x160/0x238 do_el0_svc+0x44/0x60 el0_svc+0x44/0xb0 el0t_64_sync_handler+0x118/0x128 el0t_64_sync+0x168/0x170 Fix this by having the io_uring side honor IOCB_NOWAIT, and only attempt a blocking grab of the super block rwsem if it isn't set. For normal issue where IOCB_NOWAIT would always be set, this returns -EAGAIN which will have io_uring core issue a blocking attempt of the write. That will in turn also get completions run, ensuring forward progress. Since freezing requires CAP_SYS_ADMIN in the first place, this isn't something that can be triggered by a regular user.(CVE-2024-53052)
In the Linux kernel, the following vulnerability has been resolved: media: s5p-jpeg: prevent buffer overflows The current logic allows word to be less than 2. If this happens, there will be buffer overflows, as reported by smatch. Add extra checks to prevent it. While here, remove an unused word = 0 assignment.(CVE-2024-53061)
In the Linux kernel, the following vulnerability has been resolved: nfs: Fix KMSAN warning in decode_getfattr_attrs() Fix the following KMSAN warning: CPU: 1 UID: 0 PID: 7651 Comm: cp Tainted: G B Tainted: [B]=BAD_PAGE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) ===================================================== ===================================================== BUG: KMSAN: uninit-value in decode_getfattr_attrs+0x2d6d/0x2f90 decode_getfattr_attrs+0x2d6d/0x2f90 decode_getfattr_generic+0x806/0xb00 nfs4_xdr_dec_getattr+0x1de/0x240 rpcauth_unwrap_resp_decode+0xab/0x100 rpcauth_unwrap_resp+0x95/0xc0 call_decode+0x4ff/0xb50 __rpc_execute+0x57b/0x19d0 rpc_execute+0x368/0x5e0 rpc_run_task+0xcfe/0xee0 nfs4_proc_getattr+0x5b5/0x990 __nfs_revalidate_inode+0x477/0xd00 nfs_access_get_cached+0x1021/0x1cc0 nfs_do_access+0x9f/0xae0 nfs_permission+0x1e4/0x8c0 inode_permission+0x356/0x6c0 link_path_walk+0x958/0x1330 path_lookupat+0xce/0x6b0 filename_lookup+0x23e/0x770 vfs_statx+0xe7/0x970 vfs_fstatat+0x1f2/0x2c0 __se_sys_newfstatat+0x67/0x880 __x64_sys_newfstatat+0xbd/0x120 x64_sys_call+0x1826/0x3cf0 do_syscall_64+0xd0/0x1b0 entry_SYSCALL_64_after_hwframe+0x77/0x7f The KMSAN warning is triggered in decode_getfattr_attrs(), when calling decode_attr_mdsthreshold(). It appears that fattr->mdsthreshold is not initialized. Fix the issue by initializing fattr->mdsthreshold to NULL in nfs_fattr_init().(CVE-2024-53066)
| URL | Type | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"kernel-5.10.0-238.0.0.140.oe2203sp3.aarch64.rpm",
"kernel-debuginfo-5.10.0-238.0.0.140.oe2203sp3.aarch64.rpm",
"kernel-debugsource-5.10.0-238.0.0.140.oe2203sp3.aarch64.rpm",
"kernel-devel-5.10.0-238.0.0.140.oe2203sp3.aarch64.rpm",
"kernel-headers-5.10.0-238.0.0.140.oe2203sp3.aarch64.rpm",
"kernel-source-5.10.0-238.0.0.140.oe2203sp3.aarch64.rpm",
"kernel-tools-5.10.0-238.0.0.140.oe2203sp3.aarch64.rpm",
"kernel-tools-debuginfo-5.10.0-238.0.0.140.oe2203sp3.aarch64.rpm",
"kernel-tools-devel-5.10.0-238.0.0.140.oe2203sp3.aarch64.rpm",
"perf-5.10.0-238.0.0.140.oe2203sp3.aarch64.rpm",
"perf-debuginfo-5.10.0-238.0.0.140.oe2203sp3.aarch64.rpm",
"python3-perf-5.10.0-238.0.0.140.oe2203sp3.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-238.0.0.140.oe2203sp3.aarch64.rpm"
],
"src": [
"kernel-5.10.0-238.0.0.140.oe2203sp3.src.rpm"
],
"x86_64": [
"kernel-5.10.0-238.0.0.140.oe2203sp3.x86_64.rpm",
"kernel-debuginfo-5.10.0-238.0.0.140.oe2203sp3.x86_64.rpm",
"kernel-debugsource-5.10.0-238.0.0.140.oe2203sp3.x86_64.rpm",
"kernel-devel-5.10.0-238.0.0.140.oe2203sp3.x86_64.rpm",
"kernel-headers-5.10.0-238.0.0.140.oe2203sp3.x86_64.rpm",
"kernel-source-5.10.0-238.0.0.140.oe2203sp3.x86_64.rpm",
"kernel-tools-5.10.0-238.0.0.140.oe2203sp3.x86_64.rpm",
"kernel-tools-debuginfo-5.10.0-238.0.0.140.oe2203sp3.x86_64.rpm",
"kernel-tools-devel-5.10.0-238.0.0.140.oe2203sp3.x86_64.rpm",
"perf-5.10.0-238.0.0.140.oe2203sp3.x86_64.rpm",
"perf-debuginfo-5.10.0-238.0.0.140.oe2203sp3.x86_64.rpm",
"python3-perf-5.10.0-238.0.0.140.oe2203sp3.x86_64.rpm",
"python3-perf-debuginfo-5.10.0-238.0.0.140.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-238.0.0.140.oe2203sp3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbonding: stop the device in bond_setup_by_slave()\r\n\r\nCommit 9eed321cde22 (\u0026quot;net: lapbether: only support ethernet devices\u0026quot;)\nhas been able to keep syzbot away from net/lapb, until today.\r\n\r\nIn the following splat [1], the issue is that a lapbether device has\nbeen created on a bonding device without members. Then adding a non\nARPHRD_ETHER member forced the bonding master to change its type.\r\n\r\nThe fix is to make sure we call dev_close() in bond_setup_by_slave()\nso that the potential linked lapbether devices (or any other devices\nhaving assumptions on the physical device) are removed.\r\n\r\nA similar bug has been addressed in commit 40baec225765\n(\u0026quot;bonding: fix panic on non-ARPHRD_ETHER enslave failure\u0026quot;)\r\n\r\n[1]\nskbuff: skb_under_panic: text:ffff800089508810 len:44 put:40 head:ffff0000c78e7c00 data:ffff0000c78e7bea tail:0x16 end:0x140 dev:bond0\nkernel BUG at net/core/skbuff.c:192 !\nInternal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP\nModules linked in:\nCPU: 0 PID: 6007 Comm: syz-executor383 Not tainted 6.6.0-rc3-syzkaller-gbf6547d8715b #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/04/2023\npstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : skb_panic net/core/skbuff.c:188 [inline]\npc : skb_under_panic+0x13c/0x140 net/core/skbuff.c:202\nlr : skb_panic net/core/skbuff.c:188 [inline]\nlr : skb_under_panic+0x13c/0x140 net/core/skbuff.c:202\nsp : ffff800096a06aa0\nx29: ffff800096a06ab0 x28: ffff800096a06ba0 x27: dfff800000000000\nx26: ffff0000ce9b9b50 x25: 0000000000000016 x24: ffff0000c78e7bea\nx23: ffff0000c78e7c00 x22: 000000000000002c x21: 0000000000000140\nx20: 0000000000000028 x19: ffff800089508810 x18: ffff800096a06100\nx17: 0000000000000000 x16: ffff80008a629a3c x15: 0000000000000001\nx14: 1fffe00036837a32 x13: 0000000000000000 x12: 0000000000000000\nx11: 0000000000000201 x10: 0000000000000000 x9 : cb50b496c519aa00\nx8 : cb50b496c519aa00 x7 : 0000000000000001 x6 : 0000000000000001\nx5 : ffff800096a063b8 x4 : ffff80008e280f80 x3 : ffff8000805ad11c\nx2 : 0000000000000001 x1 : 0000000100000201 x0 : 0000000000000086\nCall trace:\nskb_panic net/core/skbuff.c:188 [inline]\nskb_under_panic+0x13c/0x140 net/core/skbuff.c:202\nskb_push+0xf0/0x108 net/core/skbuff.c:2446\nip6gre_header+0xbc/0x738 net/ipv6/ip6_gre.c:1384\ndev_hard_header include/linux/netdevice.h:3136 [inline]\nlapbeth_data_transmit+0x1c4/0x298 drivers/net/wan/lapbether.c:257\nlapb_data_transmit+0x8c/0xb0 net/lapb/lapb_iface.c:447\nlapb_transmit_buffer+0x178/0x204 net/lapb/lapb_out.c:149\nlapb_send_control+0x220/0x320 net/lapb/lapb_subr.c:251\n__lapb_disconnect_request+0x9c/0x17c net/lapb/lapb_iface.c:326\nlapb_device_event+0x288/0x4e0 net/lapb/lapb_iface.c:492\nnotifier_call_chain+0x1a4/0x510 kernel/notifier.c:93\nraw_notifier_call_chain+0x3c/0x50 kernel/notifier.c:461\ncall_netdevice_notifiers_info net/core/dev.c:1970 [inline]\ncall_netdevice_notifiers_extack net/core/dev.c:2008 [inline]\ncall_netdevice_notifiers net/core/dev.c:2022 [inline]\n__dev_close_many+0x1b8/0x3c4 net/core/dev.c:1508\ndev_close_many+0x1e0/0x470 net/core/dev.c:1559\ndev_close+0x174/0x250 net/core/dev.c:1585\nlapbeth_device_event+0x2e4/0x958 drivers/net/wan/lapbether.c:466\nnotifier_call_chain+0x1a4/0x510 kernel/notifier.c:93\nraw_notifier_call_chain+0x3c/0x50 kernel/notifier.c:461\ncall_netdevice_notifiers_info net/core/dev.c:1970 [inline]\ncall_netdevice_notifiers_extack net/core/dev.c:2008 [inline]\ncall_netdevice_notifiers net/core/dev.c:2022 [inline]\n__dev_close_many+0x1b8/0x3c4 net/core/dev.c:1508\ndev_close_many+0x1e0/0x470 net/core/dev.c:1559\ndev_close+0x174/0x250 net/core/dev.c:1585\nbond_enslave+0x2298/0x30cc drivers/net/bonding/bond_main.c:2332\nbond_do_ioctl+0x268/0xc64 drivers/net/bonding/bond_main.c:4539\ndev_ifsioc+0x754/0x9ac\ndev_ioctl+0x4d8/0xd34 net/core/dev_ioctl.c:786\nsock_do_ioctl+0x1d4/0x2d0 net/socket.c:1217\nsock_ioctl+0x4e8/0x834 net/socket.c:1322\nvfs_ioctl fs/ioctl.c:51 [inline]\n__do_\n---truncated---(CVE-2023-52784)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: missing check virtio\r\n\r\nTwo missing check in virtio_net_hdr_to_skb() allowed syzbot\nto crash kernels again\r\n\r\n1. After the skb_segment function the buffer may become non-linear\n(nr_frags != 0), but since the SKBTX_SHARED_FRAG flag is not set anywhere\nthe __skb_linearize function will not be executed, then the buffer will\nremain non-linear. Then the condition (offset \u0026gt;= skb_headlen(skb))\nbecomes true, which causes WARN_ON_ONCE in skb_checksum_help.\r\n\r\n2. The struct sk_buff and struct virtio_net_hdr members must be\nmathematically related.\n(gso_size) must be greater than (needed) otherwise WARN_ON_ONCE.\n(remainder) must be greater than (needed) otherwise WARN_ON_ONCE.\n(remainder) may be 0 if division is without remainder.\r\n\r\noffset+2 (4191) \u0026gt; skb_headlen() (1116)\nWARNING: CPU: 1 PID: 5084 at net/core/dev.c:3303 skb_checksum_help+0x5e2/0x740 net/core/dev.c:3303\nModules linked in:\nCPU: 1 PID: 5084 Comm: syz-executor336 Not tainted 6.7.0-rc3-syzkaller-00014-gdf60cee26a2e #0\nHardware name: Google Compute Engine/Google Compute Engine, BIOS Google 11/10/2023\nRIP: 0010:skb_checksum_help+0x5e2/0x740 net/core/dev.c:3303\nCode: 89 e8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 52 01 00 00 44 89 e2 2b 53 74 4c 89 ee 48 c7 c7 40 57 e9 8b e8 af 8f dd f8 90 \u0026lt;0f\u0026gt; 0b 90 90 e9 87 fe ff ff e8 40 0f 6e f9 e9 4b fa ff ff 48 89 ef\nRSP: 0018:ffffc90003a9f338 EFLAGS: 00010286\nRAX: 0000000000000000 RBX: ffff888025125780 RCX: ffffffff814db209\nRDX: ffff888015393b80 RSI: ffffffff814db216 RDI: 0000000000000001\nRBP: ffff8880251257f4 R08: 0000000000000001 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000001 R12: 000000000000045c\nR13: 000000000000105f R14: ffff8880251257f0 R15: 000000000000105d\nFS: 0000555555c24380(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 000000002000f000 CR3: 0000000023151000 CR4: 00000000003506f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ip_do_fragment+0xa1b/0x18b0 net/ipv4/ip_output.c:777\n ip_fragment.constprop.0+0x161/0x230 net/ipv4/ip_output.c:584\n ip_finish_output_gso net/ipv4/ip_output.c:286 [inline]\n __ip_finish_output net/ipv4/ip_output.c:308 [inline]\n __ip_finish_output+0x49c/0x650 net/ipv4/ip_output.c:295\n ip_finish_output+0x31/0x310 net/ipv4/ip_output.c:323\n NF_HOOK_COND include/linux/netfilter.h:303 [inline]\n ip_output+0x13b/0x2a0 net/ipv4/ip_output.c:433\n dst_output include/net/dst.h:451 [inline]\n ip_local_out+0xaf/0x1a0 net/ipv4/ip_output.c:129\n iptunnel_xmit+0x5b4/0x9b0 net/ipv4/ip_tunnel_core.c:82\n ipip6_tunnel_xmit net/ipv6/sit.c:1034 [inline]\n sit_tunnel_xmit+0xed2/0x28f0 net/ipv6/sit.c:1076\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:3545 [inline]\n dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3561\n __dev_queue_xmit+0x7c1/0x3d60 net/core/dev.c:4346\n dev_queue_xmit include/linux/netdevice.h:3134 [inline]\n packet_xmit+0x257/0x380 net/packet/af_packet.c:276\n packet_snd net/packet/af_packet.c:3087 [inline]\n packet_sendmsg+0x24ca/0x5240 net/packet/af_packet.c:3119\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg+0xd5/0x180 net/socket.c:745\n __sys_sendto+0x255/0x340 net/socket.c:2190\n __do_sys_sendto net/socket.c:2202 [inline]\n __se_sys_sendto net/socket.c:2198 [inline]\n __x64_sys_sendto+0xe0/0x1b0 net/socket.c:2198\n do_syscall_x64 arch/x86/entry/common.c:51 [inline]\n do_syscall_64+0x40/0x110 arch/x86/entry/common.c:82\n entry_SYSCALL_64_after_hwframe+0x63/0x6b\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with Syzkaller(CVE-2024-43817)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: flowtable: initialise extack before use\r\n\r\nFix missing initialisation of extack in flow offload.(CVE-2024-45018)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nperf/aux: Fix AUX buffer serialization\r\n\r\nOle reported that event-\u0026gt;mmap_mutex is strictly insufficient to\nserialize the AUX buffer, add a per RB mutex to fully serialize it.\r\n\r\nNote that in the lock order comment the perf_event::mmap_mutex order\nwas already wrong, that is, it nesting under mmap_lock is not new with\nthis patch.(CVE-2024-46713)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: mm: call the security_mmap_file() LSM hook in remap_file_pages() The remap_file_pages syscall handler calls do_mmap() directly, which doesn\u0026apos;t contain the LSM security check. And if the process has called personality(READ_IMPLIES_EXEC) before and remap_file_pages() is called for RW pages, this will actually result in remapping the pages to RWX, bypassing a W^X policy enforced by SELinux. So we should check prot by security_mmap_file LSM hook in the remap_file_pages syscall handler before do_mmap() is called. Otherwise, it potentially permits an attacker to bypass a W^X policy enforced by SELinux. The bypass is similar to CVE-2016-10044, which bypass the same thing via AIO and can be found in [1]. The PoC: $ cat \u0026gt; test.c int main(void) { size_t pagesz = sysconf(_SC_PAGE_SIZE); int mfd = syscall(SYS_memfd_create, \u0026quot;test\u0026quot;, 0); const char *buf = mmap(NULL, 4 * pagesz, PROT_READ | PROT_WRITE, MAP_SHARED, mfd, 0); unsigned int old = syscall(SYS_personality, 0xffffffff); syscall(SYS_personality, READ_IMPLIES_EXEC | old); syscall(SYS_remap_file_pages, buf, pagesz, 0, 2, 0); syscall(SYS_personality, old); // show the RWX page exists even if W^X policy is enforced int fd = open(\u0026quot;/proc/self/maps\u0026quot;, O_RDONLY); unsigned char buf2[1024]; while (1) { int ret = read(fd, buf2, 1024); if (ret \u0026lt;= 0) break; write(1, buf2, ret); } close(fd); } $ gcc test.c -o test $ ./test | grep rwx 7f1836c34000-7f1836c35000 rwxs 00002000 00:01 2050 /memfd:test (deleted) [PM: subject line tweaks](CVE-2024-47745)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: net: seeq: Fix use after free vulnerability in ether3 Driver Due to Race Condition In the ether3_probe function, a timer is initialized with a callback function ether3_ledoff, bound to \u0026amp;prev(dev)-\u0026gt;timer. Once the timer is started, there is a risk of a race condition if the module or device is removed, triggering the ether3_remove function to perform cleanup. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | ether3_ledoff ether3_remove | free_netdev(dev); | put_devic | kfree(dev); | | ether3_outw(priv(dev)-\u0026gt;regs.config2 |= CFG2_CTRLO, REG_CONFIG2); | // use dev Fix it by ensuring that the timer is canceled before proceeding with the cleanup in ether3_remove.(CVE-2024-47747)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: RDMA/cxgb4: Added NULL check for lookup_atid The lookup_atid() function can return NULL if the ATID is invalid or does not exist in the identifier table, which could lead to dereferencing a null pointer without a check in the `act_establish()` and `act_open_rpl()` functions. Add a NULL check to prevent null pointer dereferencing. Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-47749)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Initialize denominators\u0026apos; default to 1 [WHAT \u0026amp; HOW] Variables used as denominators and maybe not assigned to other values, should not be 0. Change their default to 1 so they are never 0. This fixes 10 DIVIDE_BY_ZERO issues reported by Coverity.(CVE-2024-49899)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: avoid NULL pointer dereference iwl_mvm_tx_skb_sta() and iwl_mvm_tx_mpdu() verify that the mvmvsta pointer is not NULL. It retrieves this pointer using iwl_mvm_sta_from_mac80211, which is dereferencing the ieee80211_sta pointer. If sta is NULL, iwl_mvm_sta_from_mac80211 will dereference a NULL pointer. Fix this by checking the sta pointer before retrieving the mvmsta from it. If sta is not NULL, then mvmsta isn\u0026apos;t either.(CVE-2024-49929)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: prevent nf_skb_duplicated corruption syzbot found that nf_dup_ipv4() or nf_dup_ipv6() could write per-cpu variable nf_skb_duplicated in an unsafe way [1]. Disabling preemption as hinted by the splat is not enough, we have to disable soft interrupts as well. [1] BUG: using __this_cpu_write() in preemptible [00000000] code: syz.4.282/6316 caller is nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87 CPU: 0 UID: 0 PID: 6316 Comm: syz.4.282 Not tainted 6.11.0-rc7-syzkaller-00104-g7052622fccb1 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Call Trace: \u0026lt;TASK\u0026gt; __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 check_preemption_disabled+0x10e/0x120 lib/smp_processor_id.c:49 nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87 nft_dup_ipv4_eval+0x1db/0x300 net/ipv4/netfilter/nft_dup_ipv4.c:30 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x4ad/0x1da0 net/netfilter/nf_tables_core.c:288 nft_do_chain_ipv4+0x202/0x320 net/netfilter/nft_chain_filter.c:23 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626 nf_hook+0x2c4/0x450 include/linux/netfilter.h:269 NF_HOOK_COND include/linux/netfilter.h:302 [inline] ip_output+0x185/0x230 net/ipv4/ip_output.c:433 ip_local_out net/ipv4/ip_output.c:129 [inline] ip_send_skb+0x74/0x100 net/ipv4/ip_output.c:1495 udp_send_skb+0xacf/0x1650 net/ipv4/udp.c:981 udp_sendmsg+0x1c21/0x2a60 net/ipv4/udp.c:1269 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x1a6/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2597 ___sys_sendmsg net/socket.c:2651 [inline] __sys_sendmmsg+0x3b2/0x740 net/socket.c:2737 __do_sys_sendmmsg net/socket.c:2766 [inline] __se_sys_sendmmsg net/socket.c:2763 [inline] __x64_sys_sendmmsg+0xa0/0xb0 net/socket.c:2763 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f4ce4f7def9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f4ce5d4a038 EFLAGS: 00000246 ORIG_RAX: 0000000000000133 RAX: ffffffffffffffda RBX: 00007f4ce5135f80 RCX: 00007f4ce4f7def9 RDX: 0000000000000001 RSI: 0000000020005d40 RDI: 0000000000000006 RBP: 00007f4ce4ff0b76 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f4ce5135f80 R15: 00007ffd4cbc6d68 \u0026lt;/TASK\u0026gt;(CVE-2024-49952)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: netfilter: br_netfilter: fix panic with metadata_dst skb Fix a kernel panic in the br_netfilter module when sending untagged traffic via a VxLAN device. This happens during the check for fragmentation in br_nf_dev_queue_xmit. It is dependent on: 1) the br_netfilter module being loaded; 2) net.bridge.bridge-nf-call-iptables set to 1; 3) a bridge with a VxLAN (single-vxlan-device) netdevice as a bridge port; 4) untagged frames with size higher than the VxLAN MTU forwarded/flooded When forwarding the untagged packet to the VxLAN bridge port, before the netfilter hooks are called, br_handle_egress_vlan_tunnel is called and changes the skb_dst to the tunnel dst. The tunnel_dst is a metadata type of dst, i.e., skb_valid_dst(skb) is false, and metadata-\u0026gt;dst.dev is NULL. Then in the br_netfilter hooks, in br_nf_dev_queue_xmit, there\u0026apos;s a check for frames that needs to be fragmented: frames with higher MTU than the VxLAN device end up calling br_nf_ip_fragment, which in turns call ip_skb_dst_mtu. The ip_dst_mtu tries to use the skb_dst(skb) as if it was a valid dst with valid dst-\u0026gt;dev, thus the crash. This case was never supported in the first place, so drop the packet instead. PING 10.0.0.2 (10.0.0.2) from 0.0.0.0 h1-eth0: 2000(2028) bytes of data. [ 176.291791] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000110 [ 176.292101] Mem abort info: [ 176.292184] ESR = 0x0000000096000004 [ 176.292322] EC = 0x25: DABT (current EL), IL = 32 bits [ 176.292530] SET = 0, FnV = 0 [ 176.292709] EA = 0, S1PTW = 0 [ 176.292862] FSC = 0x04: level 0 translation fault [ 176.293013] Data abort info: [ 176.293104] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 176.293488] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 176.293787] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 176.293995] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000043ef5000 [ 176.294166] [0000000000000110] pgd=0000000000000000, p4d=0000000000000000 [ 176.294827] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 176.295252] Modules linked in: vxlan ip6_udp_tunnel udp_tunnel veth br_netfilter bridge stp llc ipv6 crct10dif_ce [ 176.295923] CPU: 0 PID: 188 Comm: ping Not tainted 6.8.0-rc3-g5b3fbd61b9d1 #2 [ 176.296314] Hardware name: linux,dummy-virt (DT) [ 176.296535] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 176.296808] pc : br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter] [ 176.297382] lr : br_nf_dev_queue_xmit+0x2ac/0x4ec [br_netfilter] [ 176.297636] sp : ffff800080003630 [ 176.297743] x29: ffff800080003630 x28: 0000000000000008 x27: ffff6828c49ad9f8 [ 176.298093] x26: ffff6828c49ad000 x25: 0000000000000000 x24: 00000000000003e8 [ 176.298430] x23: 0000000000000000 x22: ffff6828c4960b40 x21: ffff6828c3b16d28 [ 176.298652] x20: ffff6828c3167048 x19: ffff6828c3b16d00 x18: 0000000000000014 [ 176.298926] x17: ffffb0476322f000 x16: ffffb7e164023730 x15: 0000000095744632 [ 176.299296] x14: ffff6828c3f1c880 x13: 0000000000000002 x12: ffffb7e137926a70 [ 176.299574] x11: 0000000000000001 x10: ffff6828c3f1c898 x9 : 0000000000000000 [ 176.300049] x8 : ffff6828c49bf070 x7 : 0008460f18d5f20e x6 : f20e0100bebafeca [ 176.300302] x5 : ffff6828c7f918fe x4 : ffff6828c49bf070 x3 : 0000000000000000 [ 176.300586] x2 : 0000000000000000 x1 : ffff6828c3c7ad00 x0 : ffff6828c7f918f0 [ 176.300889] Call trace: [ 176.301123] br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter] [ 176.301411] br_nf_post_routing+0x2a8/0x3e4 [br_netfilter] [ 176.301703] nf_hook_slow+0x48/0x124 [ 176.302060] br_forward_finish+0xc8/0xe8 [bridge] [ 176.302371] br_nf_hook_thresh+0x124/0x134 [br_netfilter] [ 176.302605] br_nf_forward_finish+0x118/0x22c [br_netfilter] [ 176.302824] br_nf_forward_ip.part.0+0x264/0x290 [br_netfilter] [ 176.303136] br_nf_forward+0x2b8/0x4e0 [br_netfilter] [ 176.303359] nf_hook_slow+0x48/0x124 [ 176.303 ---truncated---(CVE-2024-50045)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: RDMA/rtrs-srv: Avoid null pointer deref during path establishment For RTRS path establishment, RTRS client initiates and completes con_num of connections. After establishing all its connections, the information is exchanged between the client and server through the info_req message. During this exchange, it is essential that all connections have been established, and the state of the RTRS srv path is CONNECTED. So add these sanity checks, to make sure we detect and abort process in error scenarios to avoid null pointer deref.(CVE-2024-50062)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: mptcp: pm: fix UaF read in mptcp_pm_nl_rm_addr_or_subflow Syzkaller reported this splat: ================================================================== BUG: KASAN: slab-use-after-free in mptcp_pm_nl_rm_addr_or_subflow+0xb44/0xcc0 net/mptcp/pm_netlink.c:881 Read of size 4 at addr ffff8880569ac858 by task syz.1.2799/14662 CPU: 0 UID: 0 PID: 14662 Comm: syz.1.2799 Not tainted 6.12.0-rc2-syzkaller-00307-g36c254515dc6 #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Call Trace: \u0026lt;TASK\u0026gt; __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc3/0x620 mm/kasan/report.c:488 kasan_report+0xd9/0x110 mm/kasan/report.c:601 mptcp_pm_nl_rm_addr_or_subflow+0xb44/0xcc0 net/mptcp/pm_netlink.c:881 mptcp_pm_nl_rm_subflow_received net/mptcp/pm_netlink.c:914 [inline] mptcp_nl_remove_id_zero_address+0x305/0x4a0 net/mptcp/pm_netlink.c:1572 mptcp_pm_nl_del_addr_doit+0x5c9/0x770 net/mptcp/pm_netlink.c:1603 genl_family_rcv_msg_doit+0x202/0x2f0 net/netlink/genetlink.c:1115 genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0x565/0x800 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x165/0x410 net/netlink/af_netlink.c:2551 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1331 [inline] netlink_unicast+0x53c/0x7f0 net/netlink/af_netlink.c:1357 netlink_sendmsg+0x8b8/0xd70 net/netlink/af_netlink.c:1901 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg net/socket.c:744 [inline] ____sys_sendmsg+0x9ae/0xb40 net/socket.c:2607 ___sys_sendmsg+0x135/0x1e0 net/socket.c:2661 __sys_sendmsg+0x117/0x1f0 net/socket.c:2690 do_syscall_32_irqs_on arch/x86/entry/common.c:165 [inline] __do_fast_syscall_32+0x73/0x120 arch/x86/entry/common.c:386 do_fast_syscall_32+0x32/0x80 arch/x86/entry/common.c:411 entry_SYSENTER_compat_after_hwframe+0x84/0x8e RIP: 0023:0xf7fe4579 Code: b8 01 10 06 03 74 b4 01 10 07 03 74 b0 01 10 08 03 74 d8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 51 52 55 89 e5 0f 34 cd 80 \u0026lt;5d\u0026gt; 5a 59 c3 90 90 90 90 8d b4 26 00 00 00 00 8d b4 26 00 00 00 00 RSP: 002b:00000000f574556c EFLAGS: 00000296 ORIG_RAX: 0000000000000172 RAX: ffffffffffffffda RBX: 000000000000000b RCX: 0000000020000140 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000296 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 \u0026lt;/TASK\u0026gt; Allocated by task 5387: kasan_save_stack+0x33/0x60 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:394 kmalloc_noprof include/linux/slab.h:878 [inline] kzalloc_noprof include/linux/slab.h:1014 [inline] subflow_create_ctx+0x87/0x2a0 net/mptcp/subflow.c:1803 subflow_ulp_init+0xc3/0x4d0 net/mptcp/subflow.c:1956 __tcp_set_ulp net/ipv4/tcp_ulp.c:146 [inline] tcp_set_ulp+0x326/0x7f0 net/ipv4/tcp_ulp.c:167 mptcp_subflow_create_socket+0x4ae/0x10a0 net/mptcp/subflow.c:1764 __mptcp_subflow_connect+0x3cc/0x1490 net/mptcp/subflow.c:1592 mptcp_pm_create_subflow_or_signal_addr+0xbda/0x23a0 net/mptcp/pm_netlink.c:642 mptcp_pm_nl_fully_established net/mptcp/pm_netlink.c:650 [inline] mptcp_pm_nl_work+0x3a1/0x4f0 net/mptcp/pm_netlink.c:943 mptcp_worker+0x15a/0x1240 net/mptcp/protocol.c:2777 process_one_work+0x958/0x1b30 kernel/workqueue.c:3229 process_scheduled_works kernel/workqueue.c:3310 [inline] worker_thread+0x6c8/0xf00 kernel/workqueue.c:3391 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/ke ---truncated---(CVE-2024-50085)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: unicode: Don\u0026apos;t special case ignorable code points We don\u0026apos;t need to handle them separately. Instead, just let them decompose/casefold to themselves.(CVE-2024-50089)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: ACPI: PRM: Find EFI_MEMORY_RUNTIME block for PRM handler and context PRMT needs to find the correct type of block to translate the PA-VA mapping for EFI runtime services. The issue arises because the PRMT is finding a block of type EFI_CONVENTIONAL_MEMORY, which is not appropriate for runtime services as described in Section 2.2.2 (Runtime Services) of the UEFI Specification [1]. Since the PRM handler is a type of runtime service, this causes an exception when the PRM handler is called. [Firmware Bug]: Unable to handle paging request in EFI runtime service WARNING: CPU: 22 PID: 4330 at drivers/firmware/efi/runtime-wrappers.c:341 __efi_queue_work+0x11c/0x170 Call trace: Let PRMT find a block with EFI_MEMORY_RUNTIME for PRM handler and PRM context. If no suitable block is found, a warning message will be printed, but the procedure continues to manage the next PRM handler. However, if the PRM handler is actually called without proper allocation, it would result in a failure during error handling. By using the correct memory types for runtime services, ensure that the PRM handler and the context are properly mapped in the virtual address space during runtime, preventing the paging request error. The issue is really that only memory that has been remapped for runtime by the firmware can be used by the PRM handler, and so the region needs to have the EFI_MEMORY_RUNTIME attribute. [ rjw: Subject and changelog edits ](CVE-2024-50141)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: udf: fix uninit-value use in udf_get_fileshortad Check for overflow when computing alen in udf_current_aext to mitigate later uninit-value use in udf_get_fileshortad KMSAN bug[1]. After applying the patch reproducer did not trigger any issue[2]. [1] https://syzkaller.appspot.com/bug?extid=8901c4560b7ab5c2f9df [2] https://syzkaller.appspot.com/x/log.txt?x=10242227980000(CVE-2024-50143)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: ceph: remove the incorrect Fw reference check when dirtying pages When doing the direct-io reads it will also try to mark pages dirty, but for the read path it won\u0026apos;t hold the Fw caps and there is case will it get the Fw reference.(CVE-2024-50179)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: fbdev: sisfb: Fix strbuf array overflow The values of the variables xres and yres are placed in strbuf. These variables are obtained from strbuf1. The strbuf1 array contains digit characters and a space if the array contains non-digit characters. Then, when executing sprintf(strbuf, \u0026quot;%ux%ux8\u0026quot;, xres, yres); more than 16 bytes will be written to strbuf. It is suggested to increase the size of the strbuf array to 24. Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-50180)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v4: Don\u0026apos;t allow a VMOVP on a dying VPE Kunkun Jiang reported that there is a small window of opportunity for userspace to force a change of affinity for a VPE while the VPE has already been unmapped, but the corresponding doorbell interrupt still visible in /proc/irq/. Plug the race by checking the value of vmapp_count, which tracks whether the VPE is mapped ot not, and returning an error in this case. This involves making vmapp_count common to both GICv4.1 and its v4.0 ancestor.(CVE-2024-50192)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: posix-clock: Fix missing timespec64 check in pc_clock_settime() As Andrew pointed out, it will make sense that the PTP core checked timespec64 struct\u0026apos;s tv_sec and tv_nsec range before calling ptp-\u0026gt;info-\u0026gt;settime64(). As the man manual of clock_settime() said, if tp.tv_sec is negative or tp.tv_nsec is outside the range [0..999,999,999], it should return EINVAL, which include dynamic clocks which handles PTP clock, and the condition is consistent with timespec64_valid(). As Thomas suggested, timespec64_valid() only check the timespec is valid, but not ensure that the time is in a valid range, so check it ahead using timespec64_valid_strict() in pc_clock_settime() and return -EINVAL if not valid. There are some drivers that use tp-\u0026gt;tv_sec and tp-\u0026gt;tv_nsec directly to write registers without validity checks and assume that the higher layer has checked it, which is dangerous and will benefit from this, such as hclge_ptp_settime(), igb_ptp_settime_i210(), _rcar_gen4_ptp_settime(), and some drivers can remove the checks of itself.(CVE-2024-50195)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: nilfs2: propagate directory read errors from nilfs_find_entry() Syzbot reported that a task hang occurs in vcs_open() during a fuzzing test for nilfs2. The root cause of this problem is that in nilfs_find_entry(), which searches for directory entries, ignores errors when loading a directory page/folio via nilfs_get_folio() fails. If the filesystem images is corrupted, and the i_size of the directory inode is large, and the directory page/folio is successfully read but fails the sanity check, for example when it is zero-filled, nilfs_check_folio() may continue to spit out error messages in bursts. Fix this issue by propagating the error to the callers when loading a page/folio fails in nilfs_find_entry(). The current interface of nilfs_find_entry() and its callers is outdated and cannot propagate error codes such as -EIO and -ENOMEM returned via nilfs_find_entry(), so fix it together.(CVE-2024-50202)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: ALSA: firewire-lib: Avoid division by zero in apply_constraint_to_size() The step variable is initialized to zero. It is changed in the loop, but if it\u0026apos;s not changed it will remain zero. Add a variable check before the division. The observed behavior was introduced by commit 826b5de90c0b (\u0026quot;ALSA: firewire-lib: fix insufficient PCM rule for period/buffer size\u0026quot;), and it is difficult to show that any of the interval parameters will satisfy the snd_interval_test() condition with data from the amdtp_rate_table[] table. Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-50205)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential deadlock with newly created symlinks Syzbot reported that page_symlink(), called by nilfs_symlink(), triggers memory reclamation involving the filesystem layer, which can result in circular lock dependencies among the reader/writer semaphore nilfs-\u0026gt;ns_segctor_sem, s_writers percpu_rwsem (intwrite) and the fs_reclaim pseudo lock. This is because after commit 21fc61c73c39 (\u0026quot;don\u0026apos;t put symlink bodies in pagecache into highmem\u0026quot;), the gfp flags of the page cache for symbolic links are overwritten to GFP_KERNEL via inode_nohighmem(). This is not a problem for symlinks read from the backing device, because the __GFP_FS flag is dropped after inode_nohighmem() is called. However, when a new symlink is created with nilfs_symlink(), the gfp flags remain overwritten to GFP_KERNEL. Then, memory allocation called from page_symlink() etc. triggers memory reclamation including the FS layer, which may call nilfs_evict_inode() or nilfs_dirty_inode(). And these can cause a deadlock if they are called while nilfs-\u0026gt;ns_segctor_sem is held: Fix this issue by dropping the __GFP_FS flag from the page cache GFP flags of newly created symlinks in the same way that nilfs_new_inode() and __nilfs_read_inode() do, as a workaround until we adopt nofs allocation scope consistently or improve the locking constraints.(CVE-2024-50229)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: nilfs2: fix kernel bug due to missing clearing of checked flag Syzbot reported that in directory operations after nilfs2 detects filesystem corruption and degrades to read-only, __block_write_begin_int(), which is called to prepare block writes, may fail the BUG_ON check for accesses exceeding the folio/page size, triggering a kernel bug. This was found to be because the \u0026quot;checked\u0026quot; flag of a page/folio was not cleared when it was discarded by nilfs2\u0026apos;s own routine, which causes the sanity check of directory entries to be skipped when the directory page/folio is reloaded. So, fix that. This was necessary when the use of nilfs2\u0026apos;s own page discard routine was applied to more than just metadata files.(CVE-2024-50230)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: NFSD: Initialize struct nfsd4_copy earlier Ensure the refcount and async_copies fields are initialized early. cleanup_async_copy() will reference these fields if an error occurs in nfsd4_copy(). If they are not correctly initialized, at the very least, a refcount underflow occurs.(CVE-2024-50241)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: ntfs3: Add bounds checking to mi_enum_attr() Added bounds checking to make sure that every attr don\u0026apos;t stray beyond valid memory region.(CVE-2024-50248)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: bpf: Fix out-of-bounds write in trie_get_next_key() trie_get_next_key() allocates a node stack with size trie-\u0026gt;max_prefixlen, while it writes (trie-\u0026gt;max_prefixlen + 1) nodes to the stack when it has full paths from the root to leaves. For example, consider a trie with max_prefixlen is 8, and the nodes with key 0x00/0, 0x00/1, 0x00/2, ... 0x00/8 inserted. Subsequent calls to trie_get_next_key with _key with .prefixlen = 8 make 9 nodes be written on the node stack with size 8.(CVE-2024-50262)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: ocfs2: remove entry once instead of null-ptr-dereference in ocfs2_xa_remove() Syzkaller is able to provoke null-ptr-dereference in ocfs2_xa_remove(): [ 57.319872] (a.out,1161,7):ocfs2_xa_remove:2028 ERROR: status = -12 [ 57.320420] (a.out,1161,7):ocfs2_xa_cleanup_value_truncate:1999 ERROR: Partial truncate while removing xattr overlay.upper. Leaking 1 clusters and removing the entry [ 57.321727] BUG: kernel NULL pointer dereference, address: 0000000000000004 [...] [ 57.325727] RIP: 0010:ocfs2_xa_block_wipe_namevalue+0x2a/0xc0 [...] [ 57.331328] Call Trace: [ 57.331477] \u0026lt;TASK\u0026gt; [...] [ 57.333511] ? do_user_addr_fault+0x3e5/0x740 [ 57.333778] ? exc_page_fault+0x70/0x170 [ 57.334016] ? asm_exc_page_fault+0x2b/0x30 [ 57.334263] ? __pfx_ocfs2_xa_block_wipe_namevalue+0x10/0x10 [ 57.334596] ? ocfs2_xa_block_wipe_namevalue+0x2a/0xc0 [ 57.334913] ocfs2_xa_remove_entry+0x23/0xc0 [ 57.335164] ocfs2_xa_set+0x704/0xcf0 [ 57.335381] ? _raw_spin_unlock+0x1a/0x40 [ 57.335620] ? ocfs2_inode_cache_unlock+0x16/0x20 [ 57.335915] ? trace_preempt_on+0x1e/0x70 [ 57.336153] ? start_this_handle+0x16c/0x500 [ 57.336410] ? preempt_count_sub+0x50/0x80 [ 57.336656] ? _raw_read_unlock+0x20/0x40 [ 57.336906] ? start_this_handle+0x16c/0x500 [ 57.337162] ocfs2_xattr_block_set+0xa6/0x1e0 [ 57.337424] __ocfs2_xattr_set_handle+0x1fd/0x5d0 [ 57.337706] ? ocfs2_start_trans+0x13d/0x290 [ 57.337971] ocfs2_xattr_set+0xb13/0xfb0 [ 57.338207] ? dput+0x46/0x1c0 [ 57.338393] ocfs2_xattr_trusted_set+0x28/0x30 [ 57.338665] ? ocfs2_xattr_trusted_set+0x28/0x30 [ 57.338948] __vfs_removexattr+0x92/0xc0 [ 57.339182] __vfs_removexattr_locked+0xd5/0x190 [ 57.339456] ? preempt_count_sub+0x50/0x80 [ 57.339705] vfs_removexattr+0x5f/0x100 [...] Reproducer uses faultinject facility to fail ocfs2_xa_remove() -\u0026gt; ocfs2_xa_value_truncate() with -ENOMEM. In this case the comment mentions that we can return 0 if ocfs2_xa_cleanup_value_truncate() is going to wipe the entry anyway. But the following \u0026apos;rc\u0026apos; check is wrong and execution flow do \u0026apos;ocfs2_xa_remove_entry(loc);\u0026apos; twice: * 1st: in ocfs2_xa_cleanup_value_truncate(); * 2nd: returning back to ocfs2_xa_remove() instead of going to \u0026apos;out\u0026apos;. Fix this by skipping the 2nd removal of the same entry and making syzkaller repro happy.(CVE-2024-50265)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: usb: musb: sunxi: Fix accessing an released usb phy Commit 6ed05c68cbca (\u0026quot;usb: musb: sunxi: Explicitly release USB PHY on exit\u0026quot;) will cause that usb phy @glue-\u0026gt;xceiv is accessed after released. 1) register platform driver @sunxi_musb_driver // get the usb phy @glue-\u0026gt;xceiv sunxi_musb_probe() -\u0026gt; devm_usb_get_phy(). 2) register and unregister platform driver @musb_driver musb_probe() -\u0026gt; sunxi_musb_init() use the phy here //the phy is released here musb_remove() -\u0026gt; sunxi_musb_exit() -\u0026gt; devm_usb_put_phy() 3) register @musb_driver again musb_probe() -\u0026gt; sunxi_musb_init() use the phy here but the phy has been released at 2). ... Fixed by reverting the commit, namely, removing devm_usb_put_phy() from sunxi_musb_exit().(CVE-2024-50269)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: btrfs: reinitialize delayed ref list after deleting it from the list At insert_delayed_ref() if we need to update the action of an existing ref to BTRFS_DROP_DELAYED_REF, we delete the ref from its ref head\u0026apos;s ref_add_list using list_del(), which leaves the ref\u0026apos;s add_list member not reinitialized, as list_del() sets the next and prev members of the list to LIST_POISON1 and LIST_POISON2, respectively. If later we end up calling drop_delayed_ref() against the ref, which can happen during merging or when destroying delayed refs due to a transaction abort, we can trigger a crash since at drop_delayed_ref() we call list_empty() against the ref\u0026apos;s add_list, which returns false since the list was not reinitialized after the list_del() and as a consequence we call list_del() again at drop_delayed_ref(). This results in an invalid list access since the next and prev members are set to poison pointers, resulting in a splat if CONFIG_LIST_HARDENED and CONFIG_DEBUG_LIST are set or invalid poison pointer dereferences otherwise. So fix this by deleting from the list with list_del_init() instead.(CVE-2024-50273)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: media: av7110: fix a spectre vulnerability As warned by smatch: drivers/staging/media/av7110/av7110_ca.c:270 dvb_ca_ioctl() warn: potential spectre issue \u0026apos;av7110-\u0026gt;ci_slot\u0026apos; [w] (local cap) There is a spectre-related vulnerability at the code. Fix it.(CVE-2024-50289)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: security/keys: fix slab-out-of-bounds in key_task_permission KASAN reports an out of bounds read: BUG: KASAN: slab-out-of-bounds in __kuid_val include/linux/uidgid.h:36 BUG: KASAN: slab-out-of-bounds in uid_eq include/linux/uidgid.h:63 [inline] BUG: KASAN: slab-out-of-bounds in key_task_permission+0x394/0x410 security/keys/permission.c:54 Read of size 4 at addr ffff88813c3ab618 by task stress-ng/4362 CPU: 2 PID: 4362 Comm: stress-ng Not tainted 5.10.0-14930-gafbffd6c3ede #15 Call Trace: __dump_stack lib/dump_stack.c:82 [inline] dump_stack+0x107/0x167 lib/dump_stack.c:123 print_address_description.constprop.0+0x19/0x170 mm/kasan/report.c:400 __kasan_report.cold+0x6c/0x84 mm/kasan/report.c:560 kasan_report+0x3a/0x50 mm/kasan/report.c:585 __kuid_val include/linux/uidgid.h:36 [inline] uid_eq include/linux/uidgid.h:63 [inline] key_task_permission+0x394/0x410 security/keys/permission.c:54 search_nested_keyrings+0x90e/0xe90 security/keys/keyring.c:793 This issue was also reported by syzbot. It can be reproduced by following these steps(more details [1]): 1. Obtain more than 32 inputs that have similar hashes, which ends with the pattern \u0026apos;0xxxxxxxe6\u0026apos;. 2. Reboot and add the keys obtained in step 1. The reproducer demonstrates how this issue happened: 1. In the search_nested_keyrings function, when it iterates through the slots in a node(below tag ascend_to_node), if the slot pointer is meta and node-\u0026gt;back_pointer != NULL(it means a root), it will proceed to descend_to_node. However, there is an exception. If node is the root, and one of the slots points to a shortcut, it will be treated as a keyring. 2. Whether the ptr is keyring decided by keyring_ptr_is_keyring function. However, KEYRING_PTR_SUBTYPE is 0x2UL, the same as ASSOC_ARRAY_PTR_SUBTYPE_MASK. 3. When 32 keys with the similar hashes are added to the tree, the ROOT has keys with hashes that are not similar (e.g. slot 0) and it splits NODE A without using a shortcut. When NODE A is filled with keys that all hashes are xxe6, the keys are similar, NODE A will split with a shortcut. Finally, it forms the tree as shown below, where slot 6 points to a shortcut. NODE A +------\u0026gt;+---+ ROOT | | 0 | xxe6 +---+ | +---+ xxxx | 0 | shortcut : : xxe6 +---+ | +---+ xxe6 : : | | | xxe6 +---+ | +---+ | 6 |---+ : : xxe6 +---+ +---+ xxe6 : : | f | xxe6 +---+ +---+ xxe6 | f | +---+ 4. As mentioned above, If a slot(slot 6) of the root points to a shortcut, it may be mistakenly transferred to a key*, leading to a read out-of-bounds read. To fix this issue, one should jump to descend_to_node if the ptr is a shortcut, regardless of whether the node is root or not. [1] https://lore.kernel.org/linux-kernel/1cfa878e-8c7b-4570-8606-21daf5e13ce7@huaweicloud.com/ [jarkko: tweaked the commit message a bit to have an appropriate closes tag.](CVE-2024-50301)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: io_uring/rw: fix missing NOWAIT check for O_DIRECT start write When io_uring starts a write, it\u0026apos;ll call kiocb_start_write() to bump the super block rwsem, preventing any freezes from happening while that write is in-flight. The freeze side will grab that rwsem for writing, excluding any new writers from happening and waiting for existing writes to finish. But io_uring unconditionally uses kiocb_start_write(), which will block if someone is currently attempting to freeze the mount point. This causes a deadlock where freeze is waiting for previous writes to complete, but the previous writes cannot complete, as the task that is supposed to complete them is blocked waiting on starting a new write. This results in the following stuck trace showing that dependency with the write blocked starting a new write: task:fio state:D stack:0 pid:886 tgid:886 ppid:876 Call trace: __switch_to+0x1d8/0x348 __schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpu_rwsem_wait+0x1e8/0x3f8 __percpu_down_read+0xe8/0x500 io_write+0xbb8/0xff8 io_issue_sqe+0x10c/0x1020 io_submit_sqes+0x614/0x2110 __arm64_sys_io_uring_enter+0x524/0x1038 invoke_syscall+0x74/0x268 el0_svc_common.constprop.0+0x160/0x238 do_el0_svc+0x44/0x60 el0_svc+0x44/0xb0 el0t_64_sync_handler+0x118/0x128 el0t_64_sync+0x168/0x170 INFO: task fsfreeze:7364 blocked for more than 15 seconds. Not tainted 6.12.0-rc5-00063-g76aaf945701c #7963 with the attempting freezer stuck trying to grab the rwsem: task:fsfreeze state:D stack:0 pid:7364 tgid:7364 ppid:995 Call trace: __switch_to+0x1d8/0x348 __schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpu_down_write+0x2b0/0x680 freeze_super+0x248/0x8a8 do_vfs_ioctl+0x149c/0x1b18 __arm64_sys_ioctl+0xd0/0x1a0 invoke_syscall+0x74/0x268 el0_svc_common.constprop.0+0x160/0x238 do_el0_svc+0x44/0x60 el0_svc+0x44/0xb0 el0t_64_sync_handler+0x118/0x128 el0t_64_sync+0x168/0x170 Fix this by having the io_uring side honor IOCB_NOWAIT, and only attempt a blocking grab of the super block rwsem if it isn\u0026apos;t set. For normal issue where IOCB_NOWAIT would always be set, this returns -EAGAIN which will have io_uring core issue a blocking attempt of the write. That will in turn also get completions run, ensuring forward progress. Since freezing requires CAP_SYS_ADMIN in the first place, this isn\u0026apos;t something that can be triggered by a regular user.(CVE-2024-53052)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: media: s5p-jpeg: prevent buffer overflows The current logic allows word to be less than 2. If this happens, there will be buffer overflows, as reported by smatch. Add extra checks to prevent it. While here, remove an unused word = 0 assignment.(CVE-2024-53061)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: nfs: Fix KMSAN warning in decode_getfattr_attrs() Fix the following KMSAN warning: CPU: 1 UID: 0 PID: 7651 Comm: cp Tainted: G B Tainted: [B]=BAD_PAGE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) ===================================================== ===================================================== BUG: KMSAN: uninit-value in decode_getfattr_attrs+0x2d6d/0x2f90 decode_getfattr_attrs+0x2d6d/0x2f90 decode_getfattr_generic+0x806/0xb00 nfs4_xdr_dec_getattr+0x1de/0x240 rpcauth_unwrap_resp_decode+0xab/0x100 rpcauth_unwrap_resp+0x95/0xc0 call_decode+0x4ff/0xb50 __rpc_execute+0x57b/0x19d0 rpc_execute+0x368/0x5e0 rpc_run_task+0xcfe/0xee0 nfs4_proc_getattr+0x5b5/0x990 __nfs_revalidate_inode+0x477/0xd00 nfs_access_get_cached+0x1021/0x1cc0 nfs_do_access+0x9f/0xae0 nfs_permission+0x1e4/0x8c0 inode_permission+0x356/0x6c0 link_path_walk+0x958/0x1330 path_lookupat+0xce/0x6b0 filename_lookup+0x23e/0x770 vfs_statx+0xe7/0x970 vfs_fstatat+0x1f2/0x2c0 __se_sys_newfstatat+0x67/0x880 __x64_sys_newfstatat+0xbd/0x120 x64_sys_call+0x1826/0x3cf0 do_syscall_64+0xd0/0x1b0 entry_SYSCALL_64_after_hwframe+0x77/0x7f The KMSAN warning is triggered in decode_getfattr_attrs(), when calling decode_attr_mdsthreshold(). It appears that fattr-\u0026gt;mdsthreshold is not initialized. Fix the issue by initializing fattr-\u0026gt;mdsthreshold to NULL in nfs_fattr_init().(CVE-2024-53066)",
"id": "OESA-2024-2494",
"modified": "2026-08-06T11:07:58Z",
"published": "2024-11-29T11:07:58Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2494"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52784"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43817"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45018"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46713"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47745"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47747"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47749"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49899"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49929"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49952"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50045"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50062"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50085"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50089"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50141"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50143"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50179"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50180"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50192"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50195"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50202"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50205"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50229"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50230"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50241"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50248"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50262"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50265"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50269"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50273"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50289"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50301"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53052"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53061"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53066"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2023-52784",
"CVE-2024-43817",
"CVE-2024-45018",
"CVE-2024-46713",
"CVE-2024-47745",
"CVE-2024-47747",
"CVE-2024-47749",
"CVE-2024-49899",
"CVE-2024-49929",
"CVE-2024-49952",
"CVE-2024-50045",
"CVE-2024-50062",
"CVE-2024-50085",
"CVE-2024-50089",
"CVE-2024-50141",
"CVE-2024-50143",
"CVE-2024-50179",
"CVE-2024-50180",
"CVE-2024-50192",
"CVE-2024-50195",
"CVE-2024-50202",
"CVE-2024-50205",
"CVE-2024-50229",
"CVE-2024-50230",
"CVE-2024-50241",
"CVE-2024-50248",
"CVE-2024-50262",
"CVE-2024-50265",
"CVE-2024-50269",
"CVE-2024-50273",
"CVE-2024-50289",
"CVE-2024-50301",
"CVE-2024-53052",
"CVE-2024-53061",
"CVE-2024-53066"
]
}
OESA-2024-2522 (CVE-2024-39483)
Vulnerability from osv_openeuler – Published: 2024-12-06 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:
KVM: SVM: WARN on vNMI + NMI window iff NMIs are outright masked
When requesting an NMI window, WARN on vNMI support being enabled if and only if NMIs are actually masked, i.e. if the vCPU is already handling an NMI. KVM's ABI for NMIs that arrive simultanesouly (from KVM's point of view) is to inject one NMI and pend the other. When using vNMI, KVM pends the second NMI simply by setting V_NMI_PENDING, and lets the CPU do the rest (hardware automatically sets V_NMI_BLOCKING when an NMI is injected).
However, if KVM can't immediately inject an NMI, e.g. because the vCPU is in an STI shadow or is running with GIF=0, then KVM will request an NMI window and trigger the WARN (but still function correctly).
Whether or not the GIF=0 case makes sense is debatable, as the intent of KVM's behavior is to provide functionality that is as close to real hardware as possible. E.g. if two NMIs are sent in quick succession, the probability of both NMIs arriving in an STI shadow is infinitesimally low on real hardware, but significantly larger in a virtual environment, e.g. if the vCPU is preempted in the STI shadow. For GIF=0, the argument isn't as clear cut, because the window where two NMIs can collide is much larger in bare metal (though still small).
That said, KVM should not have divergent behavior for the GIF=0 case based on whether or not vNMI support is enabled. And KVM has allowed simultaneous NMIs with GIF=0 for over a decade, since commit 7460fb4a3400 ("KVM: Fix simultaneous NMIs"). I.e. KVM's GIF=0 handling shouldn't be modified without a really good reason to do so, and if KVM's behavior were to be modified, it should be done irrespective of vNMI support.(CVE-2024-39483)
In the Linux kernel, the following vulnerability has been resolved:
serial: sc16is7xx: fix invalid FIFO access with special register set
When enabling access to the special register set, Receiver time-out and RHR interrupts can happen. In this case, the IRQ handler will try to read from the FIFO thru the RHR register at address 0x00, but address 0x00 is mapped to DLL register, resulting in erroneous FIFO reading.
Call graph example: sc16is7xx_startup(): entry sc16is7xx_ms_proc(): entry sc16is7xx_set_termios(): entry sc16is7xx_set_baud(): DLH/DLL = $009C --> access special register set sc16is7xx_port_irq() entry --> IIR is 0x0C sc16is7xx_handle_rx() entry sc16is7xx_fifo_read(): --> unable to access FIFO (RHR) because it is mapped to DLL (LCR=LCR_CONF_MODE_A) sc16is7xx_set_baud(): exit --> Restore access to general register set
Fix the problem by claiming the efr_lock mutex when accessing the Special register set.(CVE-2024-44950)
In the Linux kernel, the following vulnerability has been resolved:
s390/dasd: fix error recovery leading to data corruption on ESE devices
Extent Space Efficient (ESE) or thin provisioned volumes need to be formatted on demand during usual IO processing.
The dasd_ese_needs_format function checks for error codes that signal the non existence of a proper track format.
The check for incorrect length is to imprecise since other error cases leading to transport of insufficient data also have this flag set. This might lead to data corruption in certain error cases for example during a storage server warmstart.
Fix by removing the check for incorrect length and replacing by explicitly checking for invalid track format in transport mode.
Also remove the check for file protected since this is not a valid ESE handling case.(CVE-2024-45026)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Add missing NULL pointer check within dpcd_extend_address_range
[Why & How] ASSERT if return NULL from kcalloc.(CVE-2024-46808)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Check link_index before accessing dc->links[]
[WHY & HOW] dc->links[] has max size of MAX_LINKS and NULL is return when trying to access with out-of-bound index.
This fixes 3 OVERRUN and 1 RESOURCE_LEAK issues reported by Coverity.(CVE-2024-46813)
In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlwifi: mvm: use IWL_FW_CHECK for link ID check
The lookup function iwl_mvm_rcu_fw_link_id_to_link_conf() is normally called with input from the firmware, so it should use IWL_FW_CHECK() instead of WARN_ON().(CVE-2024-46825)
In the Linux kernel, the following vulnerability has been resolved: scsi: sd: Fix off-by-one error in sd_read_block_characteristics() Ff the device returns page 0xb1 with length 8 (happens with qemu v2.x, for example), sd_read_block_characteristics() may attempt an out-of-bounds memory access when accessing the zoned field at offset 8.(CVE-2024-47682)
In the Linux kernel, the following vulnerability has been resolved: block, bfq: fix possible UAF for bfqq->bic with merge chain 1) initial state, three tasks: Process 1 Process 2 Process 3 (BIC1) (BIC2) (BIC3) | Λ | Λ | Λ | | | | | | V | V | V | bfqq1 bfqq2 bfqq3 process ref: 1 1 1 2) bfqq1 merged to bfqq2: Process 1 Process 2 Process 3 (BIC1) (BIC2) (BIC3) | | | Λ --------------| | | V V | bfqq1--------->bfqq2 bfqq3 process ref: 0 2 1 3) bfqq2 merged to bfqq3: Process 1 Process 2 Process 3 (BIC1) (BIC2) (BIC3) here -> Λ | | --------------\ -------------| V V bfqq1--------->bfqq2---------->bfqq3 process ref: 0 1 3 In this case, IO from Process 1 will get bfqq2 from BIC1 first, and then get bfqq3 through merge chain, and finially handle IO by bfqq3. Howerver, current code will think bfqq2 is owned by BIC1, like initial state, and set bfqq2->bic to BIC1. bfq_insert_request -> by Process 1 bfqq = bfq_init_rq(rq) bfqq = bfq_get_bfqq_handle_split bfqq = bic_to_bfqq -> get bfqq2 from BIC1 bfqq->ref++ rq->elv.priv[0] = bic rq->elv.priv[1] = bfqq if (bfqq_process_refs(bfqq) == 1) bfqq->bic = bic -> record BIC1 to bfqq2 __bfq_insert_request new_bfqq = bfq_setup_cooperator -> get bfqq3 from bfqq2->new_bfqq bfqq_request_freed(bfqq) new_bfqq->ref++ rq->elv.priv[1] = new_bfqq -> handle IO by bfqq3 Fix the problem by checking bfqq is from merge chain fist. And this might fix a following problem reported by our syzkaller(unreproducible): ================================================================== BUG: KASAN: slab-use-after-free in bfq_do_early_stable_merge block/bfq-iosched.c:5692 [inline] BUG: KASAN: slab-use-after-free in bfq_do_or_sched_stable_merge block/bfq-iosched.c:5805 [inline] BUG: KASAN: slab-use-after-free in bfq_get_queue+0x25b0/0x2610 block/bfq-iosched.c:5889 Write of size 1 at addr ffff888123839eb8 by task kworker/0:1H/18595 CPU: 0 PID: 18595 Comm: kworker/0:1H Tainted: G L 6.6.0-07439-gba2303cacfda #6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 Workqueue: kblockd blk_mq_requeue_work Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x91/0xf0 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:364 [inline] print_report+0x10d/0x610 mm/kasan/report.c:475 kasan_report+0x8e/0xc0 mm/kasan/report.c:588 bfq_do_early_stable_merge block/bfq-iosched.c:5692 [inline] bfq_do_or_sched_stable_merge block/bfq-iosched.c:5805 [inline] bfq_get_queue+0x25b0/0x2610 block/bfq-iosched.c:5889 bfq_get_bfqq_handle_split+0x169/0x5d0 block/bfq-iosched.c:6757 bfq_init_rq block/bfq-iosched.c:6876 [inline] bfq_insert_request block/bfq-iosched.c:6254 [inline] bfq_insert_requests+0x1112/0x5cf0 block/bfq-iosched.c:6304 blk_mq_insert_request+0x290/0x8d0 block/blk-mq.c:2593 blk_mq_requeue_work+0x6bc/0xa70 block/blk-mq.c:1502 process_one_work kernel/workqueue.c:2627 [inline] process_scheduled_works+0x432/0x13f0 kernel/workqueue.c:2700 worker_thread+0x6f2/0x1160 kernel/workqueue.c:2781 kthread+0x33c/0x440 kernel/kthread.c:388 ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:305 </TASK> Allocated by task 20776: kasan_save_stack+0x20/0x40 mm/kasan/common.c:45 kasan_set_track+0x25/0x30 mm/kasan/common.c:52 __kasan_slab_alloc+0x87/0x90 mm/kasan/common.c:328 kasan_slab_alloc include/linux/kasan.h:188 [inline] slab_post_alloc_hook mm/slab.h:763 [inline] slab_alloc_node mm/slub.c:3458 [inline] kmem_cache_alloc_node+0x1a4/0x6f0 mm/slub.c:3503 ioc_create_icq block/blk-ioc.c:370 [inline] ---truncated---(CVE-2024-47706)
In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: use hweight16 to get correct tx antenna The chainmask is u16 so using hweight8 cannot get correct tx_ant. Without this patch, the tx_ant of band 2 would be -1 and lead to the following issue: BUG: KASAN: stack-out-of-bounds in mt7996_mcu_add_sta+0x12e0/0x16e0 mt7996e
In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: fix oops on non-dbdc mt7986 mt7915_band_config() sets band_idx = 1 on the main phy for mt7986 with MT7975_ONE_ADIE or MT7976_ONE_ADIE. Commit 0335c034e726 ("wifi: mt76: fix race condition related to checking tx queue fill status") introduced a dereference of the phys array indirectly indexed by band_idx via wcid->phy_idx in mt76_wcid_cleanup(). This caused the following Oops on affected mt7986 devices: Unable to handle kernel read from unreadable memory at virtual address 0000000000000024 Mem abort info: ESR = 0x0000000096000005 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x05: level 1 translation fault Data abort info: ISV = 0, ISS = 0x00000005 CM = 0, WnR = 0 user pgtable: 4k pages, 39-bit VAs, pgdp=0000000042545000 [0000000000000024] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 Internal error: Oops: 0000000096000005 [#1] SMP Modules linked in: ... mt7915e mt76_connac_lib mt76 mac80211 cfg80211 ... CPU: 2 PID: 1631 Comm: hostapd Not tainted 5.15.150 #0 Hardware name: ZyXEL EX5700 (Telenor) (DT) pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : mt76_wcid_cleanup+0x84/0x22c [mt76] lr : mt76_wcid_cleanup+0x64/0x22c [mt76] sp : ffffffc00a803700 x29: ffffffc00a803700 x28: ffffff80008f7300 x27: ffffff80003f3c00 x26: ffffff80000a7880 x25: ffffffc008c26e00 x24: 0000000000000001 x23: ffffffc000a68114 x22: 0000000000000000 x21: ffffff8004172cc8 x20: ffffffc00a803748 x19: ffffff8004152020 x18: 0000000000000000 x17: 00000000000017c0 x16: ffffffc008ef5000 x15: 0000000000000be0 x14: ffffff8004172e28 x13: ffffff8004172e28 x12: 0000000000000000 x11: 0000000000000000 x10: ffffff8004172e30 x9 : ffffff8004172e28 x8 : 0000000000000000 x7 : ffffff8004156020 x6 : 0000000000000000 x5 : 0000000000000031 x4 : 0000000000000000 x3 : 0000000000000001 x2 : 0000000000000000 x1 : ffffff80008f7300 x0 : 0000000000000024 Call trace: mt76_wcid_cleanup+0x84/0x22c [mt76] __mt76_sta_remove+0x70/0xbc [mt76] mt76_sta_state+0x8c/0x1a4 [mt76] mt7915_eeprom_get_power_delta+0x11e4/0x23a0 [mt7915e] drv_sta_state+0x144/0x274 [mac80211] sta_info_move_state+0x1cc/0x2a4 [mac80211] sta_set_sinfo+0xaf8/0xc24 [mac80211] sta_info_destroy_addr_bss+0x4c/0x6c [mac80211] ieee80211_color_change_finish+0x1c08/0x1e70 [mac80211] cfg80211_check_station_change+0x1360/0x4710 [cfg80211] genl_family_rcv_msg_doit+0xb4/0x110 genl_rcv_msg+0xd0/0x1bc netlink_rcv_skb+0x58/0x120 genl_rcv+0x34/0x50 netlink_unicast+0x1f0/0x2ec netlink_sendmsg+0x198/0x3d0 _syssendmsg+0x1b0/0x210 _sys_sendmsg+0x80/0xf0 __sys_sendmsg+0x44/0xa0 __arm64_sys_sendmsg+0x20/0x30 invoke_syscall.constprop.0+0x4c/0xe0 do_el0_svc+0x40/0xd0 el0_svc+0x14/0x4c el0t_64_sync_handler+0x100/0x110 el0t_64_sync+0x15c/0x160 Code: d2800002 910092c0 52800023 f9800011 (885f7c01) ---[ end trace 7e42dd9a39ed2281 ]--- Fix by using mt76_dev_phy() which will map band_idx to the correct phy for all hardware combinations.(CVE-2024-47715)
In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: always wait for both firmware loading attempts In 'rtw_wait_firmware_completion()', always wait for both (regular and wowlan) firmware loading attempts. Otherwise if 'rtw_usb_intf_init()' has failed in 'rtw_usb_probe()', 'rtw_usb_disconnect()' may issue 'ieee80211_free_hw()' when one of 'rtw_load_firmware_cb()' (usually the wowlan one) is still in progress, causing UAF detected by KASAN.(CVE-2024-47718)
In the Linux kernel, the following vulnerability has been resolved: bonding: Fix unnecessary warnings and logs from bond_xdp_get_xmit_slave() syzbot reported a WARNING in bond_xdp_get_xmit_slave. To reproduce this[1], one bond device (bond1) has xdpdrv, which increases bpf_master_redirect_enabled_key. Another bond device (bond0) which is unsupported by XDP but its slave (veth3) has xdpgeneric that returns XDP_TX. This triggers WARN_ON_ONCE() from the xdp_master_redirect(). To reduce unnecessary warnings and improve log management, we need to delete the WARN_ON_ONCE() and add ratelimit to the netdev_err(). [1] Steps to reproduce: # Needs tx_xdp with return XDP_TX; ip l add veth0 type veth peer veth1 ip l add veth3 type veth peer veth4 ip l add bond0 type bond mode 6 # BOND_MODE_ALB, unsupported by XDP ip l add bond1 type bond # BOND_MODE_ROUNDROBIN by default ip l set veth0 master bond1 ip l set bond1 up # Increases bpf_master_redirect_enabled_key ip l set dev bond1 xdpdrv object tx_xdp.o section xdp_tx ip l set veth3 master bond0 ip l set bond0 up ip l set veth4 up # Triggers WARN_ON_ONCE() from the xdp_master_redirect() ip l set veth3 xdpgeneric object tx_xdp.o section xdp_tx(CVE-2024-47734)
In the Linux kernel, the following vulnerability has been resolved: f2fs: Require FMODE_WRITE for atomic write ioctls The F2FS ioctls for starting and committing atomic writes check for inode_owner_or_capable(), but this does not give LSMs like SELinux or Landlock an opportunity to deny the write access - if the caller's FSUID matches the inode's UID, inode_owner_or_capable() immediately returns true. There are scenarios where LSMs want to deny a process the ability to write particular files, even files that the FSUID of the process owns; but this can currently partially be bypassed using atomic write ioctls in two ways: - F2FS_IOC_START_ATOMIC_REPLACE + F2FS_IOC_COMMIT_ATOMIC_WRITE can truncate an inode to size 0 - F2FS_IOC_START_ATOMIC_WRITE + F2FS_IOC_ABORT_ATOMIC_WRITE can revert changes another process concurrently made to a file Fix it by requiring FMODE_WRITE for these operations, just like for F2FS_IOC_MOVE_RANGE. Since any legitimate caller should only be using these ioctls when intending to write into the file, that seems unlikely to break anything.(CVE-2024-47740)
In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix Use-After-Free of rsv_qp on HIP08 Currently rsv_qp is freed before ib_unregister_device() is called on HIP08. During the time interval, users can still dereg MR and rsv_qp will be used in this process, leading to a UAF. Move the release of rsv_qp after calling ib_unregister_device() to fix it.(CVE-2024-47750)
In the Linux kernel, the following vulnerability has been resolved: media: mediatek: vcodec: Fix H264 multi stateless decoder smatch warning Fix a smatch static checker warning on vdec_h264_req_multi_if.c. Which leads to a kernel crash when fb is NULL.(CVE-2024-47754)
In the Linux kernel, the following vulnerability has been resolved: tpm: Clean up TPM space after command failure tpm_dev_transmit prepares the TPM space before attempting command transmission. However if the command fails no rollback of this preparation is done. This can result in transient handles being leaked if the device is subsequently closed with no further commands performed. Fix this by flushing the space in the event of command transmission failure.(CVE-2024-49851)
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix helper writes to read-only maps Lonial found an issue that despite user- and BPF-side frozen BPF map (like in case of .rodata), it was still possible to write into it from a BPF program side through specific helpers having ARG_PTR_TO_{LONG,INT} as arguments. In check_func_arg() when the argument is as mentioned, the meta->raw_mode is never set. Later, check_helper_mem_access(), under the case of PTR_TO_MAP_VALUE as register base type, it assumes BPF_READ for the subsequent call to check_map_access_type() and given the BPF map is read-only it succeeds. The helpers really need to be annotated as ARG_PTR_TO_{LONG,INT} | MEM_UNINIT when results are written into them as opposed to read out of them. The latter indicates that it's okay to pass a pointer to uninitialized memory as the memory is written to anyway. However, ARG_PTR_TO_{LONG,INT} is a special case of ARG_PTR_TO_FIXED_SIZE_MEM just with additional alignment requirement. So it is better to just get rid of the ARG_PTR_TO_{LONG,INT} special cases altogether and reuse the fixed size memory types. For this, add MEM_ALIGNED to additionally ensure alignment given these helpers write directly into the args via <ptr> = val. The .arg_size has been initialized reflecting the actual sizeof(<ptr>). MEM_ALIGNED can only be used in combination with MEM_FIXED_SIZE annotated argument types, since in !MEM_FIXED_SIZE cases the verifier does not know the buffer size a priori and therefore cannot blindly write <ptr> = val.(CVE-2024-49861)
In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: ensure the fw_info is not null before using it This resolves the dereference null return value warning reported by Coverity.(CVE-2024-49890)
In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Validate hdwq pointers before dereferencing in reset/errata paths When the HBA is undergoing a reset or is handling an errata event, NULL ptr dereference crashes may occur in routines such as lpfc_sli_flush_io_rings(), lpfc_dev_loss_tmo_callbk(), or lpfc_abort_handler(). Add NULL ptr checks before dereferencing hdwq pointers that may have been freed due to operations colliding with a reset or errata event handler.(CVE-2024-49891)
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointers before using dc->clk_mgr [WHY & HOW] dc->clk_mgr is null checked previously in the same function, indicating it might be null. Passing "dc" to "dc->hwss.apply_idle_power_optimizations", which dereferences null "dc->clk_mgr". (The function pointer resolves to "dcn35_apply_idle_power_optimizations".) This fixes 1 FORWARD_NULL issue reported by Coverity.(CVE-2024-49907)
In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: avoid NULL pointer dereference iwl_mvm_tx_skb_sta() and iwl_mvm_tx_mpdu() verify that the mvmvsta pointer is not NULL. It retrieves this pointer using iwl_mvm_sta_from_mac80211, which is dereferencing the ieee80211_sta pointer. If sta is NULL, iwl_mvm_sta_from_mac80211 will dereference a NULL pointer. Fix this by checking the sta pointer before retrieving the mvmsta from it. If sta is not NULL, then mvmsta isn't either.(CVE-2024-49929)
In the Linux kernel, the following vulnerability has been resolved: aoe: fix the potential use-after-free problem in more places For fixing CVE-2023-6270, f98364e92662 ("aoe: fix the potential use-after-free problem in aoecmd_cfg_pkts") makes tx() calling dev_put() instead of doing in aoecmd_cfg_pkts(). It avoids that the tx() runs into use-after-free. Then Nicolai Stange found more places in aoe have potential use-after-free problem with tx(). e.g. revalidate(), aoecmd_ata_rw(), resend(), probe() and aoecmd_cfg_rsp(). Those functions also use aoenet_xmit() to push packet to tx queue. So they should also use dev_hold() to increase the refcnt of skb->dev. On the other hand, moving dev_put() to tx() causes that the refcnt of skb->dev be reduced to a negative value, because corresponding dev_hold() are not called in revalidate(), aoecmd_ata_rw(), resend(), probe(), and aoecmd_cfg_rsp(). This patch fixed this issue.(CVE-2024-49982)
In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix error path in multi-packet WQE transmit Remove the erroneous unmap in case no DMA mapping was established The multi-packet WQE transmit code attempts to obtain a DMA mapping for the skb. This could fail, e.g. under memory pressure, when the IOMMU driver just can't allocate more memory for page tables. While the code tries to handle this in the path below the err_unmap label it erroneously unmaps one entry from the sq's FIFO list of active mappings. Since the current map attempt failed this unmap is removing some random DMA mapping that might still be required. If the PCI function now presents that IOVA, the IOMMU may assumes a rogue DMA access and e.g. on s390 puts the PCI function in error state. The erroneous behavior was seen in a stress-test environment that created memory pressure.(CVE-2024-50001)
In the Linux kernel, the following vulnerability has been resolved: exec: don't WARN for racy path_noexec check Both i_mode and noexec checks wrapped in WARN_ON stem from an artifact of the previous implementation. They used to legitimately check for the condition, but that got moved up in two commits: 633fb6ac3980 ("exec: move S_ISREG() check earlier") 0fd338b2d2cd ("exec: move path_noexec() check earlier") Instead of being removed said checks are WARN_ON'ed instead, which has some debug value. However, the spurious path_noexec check is racy, resulting in unwarranted warnings should someone race with setting the noexec flag. One can note there is more to perm-checking whether execve is allowed and none of the conditions are guaranteed to still hold after they were tested for. Additionally this does not validate whether the code path did any perm checking to begin with -- it will pass if the inode happens to be regular. Keep the redundant path_noexec() check even though it's mindless nonsense checking for guarantee that isn't given so drop the WARN. Reword the commentary and do small tidy ups while here. brauner: keep redundant path_noexec() check
In the Linux kernel, the following vulnerability has been resolved: net: phy: Remove LED entry from LEDs list on unregister Commit c938ab4da0eb ("net: phy: Manual remove LEDs to ensure correct ordering") correctly fixed a problem with using devm_ but missed removing the LED entry from the LEDs list. This cause kernel panic on specific scenario where the port for the PHY is torn down and up and the kmod for the PHY is removed. On setting the port down the first time, the assosiacted LEDs are correctly unregistered. The associated kmod for the PHY is now removed. The kmod is now added again and the port is now put up, the associated LED are registered again. On putting the port down again for the second time after these step, the LED list now have 4 elements. With the first 2 already unregistered previously and the 2 new one registered again. This cause a kernel panic as the first 2 element should have been removed. Fix this by correctly removing the element when LED is unregistered.(CVE-2024-50023)
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: FIX possible deadlock in rfcomm_sk_state_change rfcomm_sk_state_change attempts to use sock_lock so it must never be called with it locked but rfcomm_sock_ioctl always attempt to lock it causing the following trace: ====================================================== WARNING: possible circular locking dependency detected 6.8.0-syzkaller-08951-gfe46a7dd189e #0 Not tainted ------------------------------------------------------ syz-executor386/5093 is trying to acquire lock: ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1671 [inline] ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: rfcomm_sk_state_change+0x5b/0x310 net/bluetooth/rfcomm/sock.c:73 but task is already holding lock: ffff88807badfd28 (&d->lock){+.+.}-{3:3}, at: __rfcomm_dlc_close+0x226/0x6a0 net/bluetooth/rfcomm/core.c:491(CVE-2024-50044)
In the Linux kernel, the following vulnerability has been resolved: fbcon: Fix a NULL pointer dereference issue in fbcon_putcs syzbot has found a NULL pointer dereference bug in fbcon. Here is the simplified C reproducer: struct param { uint8_t type; struct tiocl_selection ts; }; int main() { struct fb_con2fbmap con2fb; struct param param; int fd = open("/dev/fb1", 0, 0); con2fb.console = 0x19; con2fb.framebuffer = 0; ioctl(fd, FBIOPUT_CON2FBMAP, &con2fb); param.type = 2; param.ts.xs = 0; param.ts.ys = 0; param.ts.xe = 0; param.ts.ye = 0; param.ts.sel_mode = 0; int fd1 = open("/dev/tty1", O_RDWR, 0); ioctl(fd1, TIOCLINUX, ¶m); con2fb.console = 1; con2fb.framebuffer = 0; ioctl(fd, FBIOPUT_CON2FBMAP, &con2fb); return 0; } After calling ioctl(fd1, TIOCLINUX, ¶m), the subsequent ioctl(fd, FBIOPUT_CON2FBMAP, &con2fb) causes the kernel to follow a different execution path: set_con2fb_map -> con2fb_init_display -> fbcon_set_disp -> redraw_screen -> hide_cursor -> clear_selection -> highlight -> invert_screen -> do_update_region -> fbcon_putcs -> ops->putcs Since ops->putcs is a NULL pointer, this leads to a kernel panic. To prevent this, we need to call set_blitting_type() within set_con2fb_map() to properly initialize ops->putcs.(CVE-2024-50048)
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Call iso_exit() on module unload If iso_init() has been called, iso_exit() must be called on module unload. Without that, the struct proto that iso_init() registered with proto_register() becomes invalid, which could cause unpredictable problems later. In my case, with CONFIG_LIST_HARDENED and CONFIG_BUG_ON_DATA_CORRUPTION enabled, loading the module again usually triggers this BUG(): list_add corruption. next->prev should be prev (ffffffffb5355fd0), but was 0000000000000068. (next=ffffffffc0a010d0). ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:29! Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 4159 Comm: modprobe Not tainted 6.10.11-4+bt2-ao-desktop #1 RIP: 0010:__list_add_valid_or_report+0x61/0xa0 ... __list_add_valid_or_report+0x61/0xa0 proto_register+0x299/0x320 hci_sock_init+0x16/0xc0 [bluetooth] bt_init+0x68/0xd0 [bluetooth] __pfx_bt_init+0x10/0x10 [bluetooth] do_one_initcall+0x80/0x2f0 do_init_module+0x8b/0x230 __do_sys_init_module+0x15f/0x190 do_syscall_64+0x68/0x110 ...(CVE-2024-50078)
In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix user-after-free from session log off There is racy issue between smb2 session log off and smb2 session setup. It will cause user-after-free from session log off. This add session_lock when setting SMB2_SESSION_EXPIRED and referece count to session struct not to free session while it is being used.(CVE-2024-50086)
In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Fix incorrect pci_for_each_dma_alias() for non-PCI devices Previously, the domain_context_clear() function incorrectly called pci_for_each_dma_alias() to set up context entries for non-PCI devices. This could lead to kernel hangs or other unexpected behavior. Add a check to only call pci_for_each_dma_alias() for PCI devices. For non-PCI devices, domain_context_clear_one() is called directly.(CVE-2024-50101)
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Disable PSR-SU on Parade 08-01 TCON too Stuart Hayhurst has found that both at bootup and fullscreen VA-API video is leading to black screens for around 1 second and kernel WARNING [1] traces when calling dmub_psr_enable() with Parade 08-01 TCON. These symptoms all go away with PSR-SU disabled for this TCON, so disable it for now while DMUB traces [2] from the failure can be analyzed and the failure state properly root caused. (cherry picked from commit afb634a6823d8d9db23c5fb04f79c5549349628b)(CVE-2024-50108)
In the Linux kernel, the following vulnerability has been resolved: net: sched: use RCU read-side critical section in taprio_dump() Fix possible use-after-free in 'taprio_dump()' by adding RCU read-side critical section there. Never seen on x86 but found on a KASAN-enabled arm64 system when investigating https://syzkaller.appspot.com/bug?extid=b65e0af58423fc8a73aa: [T15862] BUG: KASAN: slab-use-after-free in taprio_dump+0xa0c/0xbb0 [T15862] Read of size 4 at addr ffff0000d4bb88f8 by task repro/15862 [T15862] [T15862] CPU: 0 UID: 0 PID: 15862 Comm: repro Not tainted 6.11.0-rc1-00293-gdefaf1a2113a-dirty #2 [T15862] Hardware name: QEMU QEMU Virtual Machine, BIOS edk2-20240524-5.fc40 05/24/2024 [T15862] Call trace: [T15862] dump_backtrace+0x20c/0x220 [T15862] show_stack+0x2c/0x40 [T15862] dump_stack_lvl+0xf8/0x174 [T15862] print_report+0x170/0x4d8 [T15862] kasan_report+0xb8/0x1d4 [T15862] __asan_report_load4_noabort+0x20/0x2c [T15862] taprio_dump+0xa0c/0xbb0 [T15862] tc_fill_qdisc+0x540/0x1020 [T15862] qdisc_notify.isra.0+0x330/0x3a0 [T15862] tc_modify_qdisc+0x7b8/0x1838 [T15862] rtnetlink_rcv_msg+0x3c8/0xc20 [T15862] netlink_rcv_skb+0x1f8/0x3d4 [T15862] rtnetlink_rcv+0x28/0x40 [T15862] netlink_unicast+0x51c/0x790 [T15862] netlink_sendmsg+0x79c/0xc20 [T15862] __sock_sendmsg+0xe0/0x1a0 [T15862] _syssendmsg+0x6c0/0x840 [T15862] _sys_sendmsg+0x1ac/0x1f0 [T15862] __sys_sendmsg+0x110/0x1d0 [T15862] __arm64_sys_sendmsg+0x74/0xb0 [T15862] invoke_syscall+0x88/0x2e0 [T15862] el0_svc_common.constprop.0+0xe4/0x2a0 [T15862] do_el0_svc+0x44/0x60 [T15862] el0_svc+0x50/0x184 [T15862] el0t_64_sync_handler+0x120/0x12c [T15862] el0t_64_sync+0x190/0x194 [T15862] [T15862] Allocated by task 15857: [T15862] kasan_save_stack+0x3c/0x70 [T15862] kasan_save_track+0x20/0x3c [T15862] kasan_save_alloc_info+0x40/0x60 [T15862] __kasan_kmalloc+0xd4/0xe0 [T15862] __kmalloc_cache_noprof+0x194/0x334 [T15862] taprio_change+0x45c/0x2fe0 [T15862] tc_modify_qdisc+0x6a8/0x1838 [T15862] rtnetlink_rcv_msg+0x3c8/0xc20 [T15862] netlink_rcv_skb+0x1f8/0x3d4 [T15862] rtnetlink_rcv+0x28/0x40 [T15862] netlink_unicast+0x51c/0x790 [T15862] netlink_sendmsg+0x79c/0xc20 [T15862] __sock_sendmsg+0xe0/0x1a0 [T15862] _syssendmsg+0x6c0/0x840 [T15862] _sys_sendmsg+0x1ac/0x1f0 [T15862] __sys_sendmsg+0x110/0x1d0 [T15862] __arm64_sys_sendmsg+0x74/0xb0 [T15862] invoke_syscall+0x88/0x2e0 [T15862] el0_svc_common.constprop.0+0xe4/0x2a0 [T15862] do_el0_svc+0x44/0x60 [T15862] el0_svc+0x50/0x184 [T15862] el0t_64_sync_handler+0x120/0x12c [T15862] el0t_64_sync+0x190/0x194 [T15862] [T15862] Freed by task 6192: [T15862] kasan_save_stack+0x3c/0x70 [T15862] kasan_save_track+0x20/0x3c [T15862] kasan_save_free_info+0x4c/0x80 [T15862] poison_slab_object+0x110/0x160 [T15862] __kasan_slab_free+0x3c/0x74 [T15862] kfree+0x134/0x3c0 [T15862] taprio_free_sched_cb+0x18c/0x220 [T15862] rcu_core+0x920/0x1b7c [T15862] rcu_core_si+0x10/0x1c [T15862] handle_softirqs+0x2e8/0xd64 [T15862] __do_softirq+0x14/0x20(CVE-2024-50126)
In the Linux kernel, the following vulnerability has been resolved: net: sched: fix use-after-free in taprio_change() In 'taprio_change()', 'admin' pointer may become dangling due to sched switch / removal caused by 'advance_sched()', and critical section protected by 'q->current_entry_lock' is too small to prevent from such a scenario (which causes use-after-free detected by KASAN). Fix this by prefer 'rcu_replace_pointer()' over 'rcu_assign_pointer()' to update 'admin' immediately before an attempt to schedule freeing.(CVE-2024-50127)
In the Linux kernel, the following vulnerability has been resolved: net: wwan: fix global oob in wwan_rtnl_policy The variable wwan_rtnl_link_ops assign a bigger maxtype which leads to a global out-of-bounds read when parsing the netlink attributes. Exactly same bug cause as the oob fixed in commit b33fb5b801c6 ("net: qualcomm: rmnet: fix global oob in rmnet_policy"). ================================================================== BUG: KASAN: global-out-of-bounds in validate_nla lib/nlattr.c:388 [inline] BUG: KASAN: global-out-of-bounds in __nla_validate_parse+0x19d7/0x29a0 lib/nlattr.c:603 Read of size 1 at addr ffffffff8b09cb60 by task syz.1.66276/323862 CPU: 0 PID: 323862 Comm: syz.1.66276 Not tainted 6.1.70 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x177/0x231 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:284 [inline] print_report+0x14f/0x750 mm/kasan/report.c:395 kasan_report+0x139/0x170 mm/kasan/report.c:495 validate_nla lib/nlattr.c:388 [inline] __nla_validate_parse+0x19d7/0x29a0 lib/nlattr.c:603 __nla_parse+0x3c/0x50 lib/nlattr.c:700 nla_parse_nested_deprecated include/net/netlink.h:1269 [inline] __rtnl_newlink net/core/rtnetlink.c:3514 [inline] rtnl_newlink+0x7bc/0x1fd0 net/core/rtnetlink.c:3623 rtnetlink_rcv_msg+0x794/0xef0 net/core/rtnetlink.c:6122 netlink_rcv_skb+0x1de/0x420 net/netlink/af_netlink.c:2508 netlink_unicast_kernel net/netlink/af_netlink.c:1326 [inline] netlink_unicast+0x74b/0x8c0 net/netlink/af_netlink.c:1352 netlink_sendmsg+0x882/0xb90 net/netlink/af_netlink.c:1874 sock_sendmsg_nosec net/socket.c:716 [inline] __sock_sendmsg net/socket.c:728 [inline] _syssendmsg+0x5cc/0x8f0 net/socket.c:2499 _sys_sendmsg+0x21c/0x290 net/socket.c:2553 __sys_sendmsg net/socket.c:2582 [inline] __do_sys_sendmsg net/socket.c:2591 [inline] __se_sys_sendmsg+0x19e/0x270 net/socket.c:2589 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x45/0x90 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f67b19a24ad RSP: 002b:00007f67b17febb8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f67b1b45f80 RCX: 00007f67b19a24ad RDX: 0000000000000000 RSI: 0000000020005e40 RDI: 0000000000000004 RBP: 00007f67b1a1e01d R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007ffd2513764f R14: 00007ffd251376e0 R15: 00007f67b17fed40 </TASK> The buggy address belongs to the variable: wwan_rtnl_policy+0x20/0x40 The buggy address belongs to the physical page: page:ffffea00002c2700 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0xb09c flags: 0xfff00000001000(reserved|node=0|zone=1|lastcpupid=0x7ff) raw: 00fff00000001000 ffffea00002c2708 ffffea00002c2708 0000000000000000 raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected page_owner info is not present (never set?) Memory state around the buggy address: ffffffff8b09ca00: 05 f9 f9 f9 05 f9 f9 f9 00 01 f9 f9 00 01 f9 f9 ffffffff8b09ca80: 00 00 00 05 f9 f9 f9 f9 00 00 03 f9 f9 f9 f9 f9 >ffffffff8b09cb00: 00 00 00 00 05 f9 f9 f9 00 00 00 00 f9 f9 f9 f9 ^ ffffffff8b09cb80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ================================================================== According to the comment of nla_parse_nested_deprecated, use correct size IFLA_WWAN_MAX here to fix this issue.(CVE-2024-50128)
In the Linux kernel, the following vulnerability has been resolved: netfilter: bpf: must hold reference on net namespace BUG: KASAN: slab-use-after-free in __nf_unregister_net_hook+0x640/0x6b0 Read of size 8 at addr ffff8880106fe400 by task repro/72= bpf_nf_link_release+0xda/0x1e0 bpf_link_free+0x139/0x2d0 bpf_link_release+0x68/0x80 __fput+0x414/0xb60 Eric says: It seems that bpf was able to defer the __nf_unregister_net_hook() after exit()/close() time. Perhaps a netns reference is missing, because the netns has been dismantled/freed already. bpf_nf_link_attach() does : link->net = net; But I do not see a reference being taken on net. Add such a reference and release it after hook unreg. Note that I was unable to get syzbot reproducer to work, so I do not know if this resolves this splat.(CVE-2024-50130)
In the Linux kernel, the following vulnerability has been resolved: nvme-pci: fix race condition between reset and nvme_dev_disable() nvme_dev_disable() modifies the dev->online_queues field, therefore nvme_pci_update_nr_queues() should avoid racing against it, otherwise we could end up passing invalid values to blk_mq_update_nr_hw_queues(). WARNING: CPU: 39 PID: 61303 at drivers/pci/msi/api.c:347 pci_irq_get_affinity+0x187/0x210 Workqueue: nvme-reset-wq nvme_reset_work [nvme] RIP: 0010:pci_irq_get_affinity+0x187/0x210 Call Trace: <TASK> ? blk_mq_pci_map_queues+0x87/0x3c0 ? pci_irq_get_affinity+0x187/0x210 blk_mq_pci_map_queues+0x87/0x3c0 nvme_pci_map_queues+0x189/0x460 [nvme] blk_mq_update_nr_hw_queues+0x2a/0x40 nvme_reset_work+0x1be/0x2a0 [nvme] Fix the bug by locking the shutdown_lock mutex before using dev->online_queues. Give up if nvme_dev_disable() is running or if it has been executed already.(CVE-2024-50135)
In the Linux kernel, the following vulnerability has been resolved: reset: starfive: jh71x0: Fix accessing the empty member on JH7110 SoC data->asserted will be NULL on JH7110 SoC since commit 82327b127d41 ("reset: starfive: Add StarFive JH7110 reset driver") was added. Add the judgment condition to avoid errors when calling reset_control_status on JH7110 SoC.(CVE-2024-50137)
In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Fix shift-out-of-bounds bug Fix a shift-out-of-bounds bug reported by UBSAN when running VM with MTE enabled host kernel. UBSAN: shift-out-of-bounds in arch/arm64/kvm/sys_regs.c:1988:14 shift exponent 33 is too large for 32-bit type 'int' CPU: 26 UID: 0 PID: 7629 Comm: qemu-kvm Not tainted 6.12.0-rc2 #34 Hardware name: IEI NF5280R7/Mitchell MB, BIOS 00.00. 2024-10-12 09:28:54 10/14/2024 Call trace: dump_backtrace+0xa0/0x128 show_stack+0x20/0x38 dump_stack_lvl+0x74/0x90 dump_stack+0x18/0x28 __ubsan_handle_shift_out_of_bounds+0xf8/0x1e0 reset_clidr+0x10c/0x1c8 kvm_reset_sys_regs+0x50/0x1c8 kvm_reset_vcpu+0xec/0x2b0 __kvm_vcpu_set_target+0x84/0x158 kvm_vcpu_set_target+0x138/0x168 kvm_arch_vcpu_ioctl_vcpu_init+0x40/0x2b0 kvm_arch_vcpu_ioctl+0x28c/0x4b8 kvm_vcpu_ioctl+0x4bc/0x7a8 __arm64_sys_ioctl+0xb4/0x100 invoke_syscall+0x70/0x100 el0_svc_common.constprop.0+0x48/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x3c/0x158 el0t_64_sync_handler+0x120/0x130 el0t_64_sync+0x194/0x198(CVE-2024-50139)
In the Linux kernel, the following vulnerability has been resolved: usb: typec: altmode should keep reference to parent The altmode device release refers to its parent device, but without keeping a reference to it. When registering the altmode, get a reference to the parent and put it in the release function. Before this fix, when using CONFIG_DEBUG_KOBJECT_RELEASE, we see issues like this: [ 43.572860] kobject: 'port0.0' (ffff8880057ba008): kobject_release, parent 0000000000000000 (delayed 3000) [ 43.573532] kobject: 'port0.1' (ffff8880057bd008): kobject_release, parent 0000000000000000 (delayed 1000) [ 43.574407] kobject: 'port0' (ffff8880057b9008): kobject_release, parent 0000000000000000 (delayed 3000) [ 43.575059] kobject: 'port1.0' (ffff8880057ca008): kobject_release, parent 0000000000000000 (delayed 4000) [ 43.575908] kobject: 'port1.1' (ffff8880057c9008): kobject_release, parent 0000000000000000 (delayed 4000) [ 43.576908] kobject: 'typec' (ffff8880062dbc00): kobject_release, parent 0000000000000000 (delayed 4000) [ 43.577769] kobject: 'port1' (ffff8880057bf008): kobject_release, parent 0000000000000000 (delayed 3000) [ 46.612867] ================================================================== [ 46.613402] BUG: KASAN: slab-use-after-free in typec_altmode_release+0x38/0x129 [ 46.614003] Read of size 8 at addr ffff8880057b9118 by task kworker/2:1/48 [ 46.614538] [ 46.614668] CPU: 2 UID: 0 PID: 48 Comm: kworker/2:1 Not tainted 6.12.0-rc1-00138-gedbae730ad31 #535 [ 46.615391] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 [ 46.616042] Workqueue: events kobject_delayed_cleanup [ 46.616446] Call Trace: [ 46.616648] <TASK> [ 46.616820] dump_stack_lvl+0x5b/0x7c [ 46.617112] ? typec_altmode_release+0x38/0x129 [ 46.617470] print_report+0x14c/0x49e [ 46.617769] ? rcu_read_unlock_sched+0x56/0x69 [ 46.618117] ? __virt_addr_valid+0x19a/0x1ab [ 46.618456] ? kmem_cache_debug_flags+0xc/0x1d [ 46.618807] ? typec_altmode_release+0x38/0x129 [ 46.619161] kasan_report+0x8d/0xb4 [ 46.619447] ? typec_altmode_release+0x38/0x129 [ 46.619809] ? process_scheduled_works+0x3cb/0x85f [ 46.620185] typec_altmode_release+0x38/0x129 [ 46.620537] ? process_scheduled_works+0x3cb/0x85f [ 46.620907] device_release+0xaf/0xf2 [ 46.621206] kobject_delayed_cleanup+0x13b/0x17a [ 46.621584] process_scheduled_works+0x4f6/0x85f [ 46.621955] ? __pfx_process_scheduled_works+0x10/0x10 [ 46.622353] ? hlock_class+0x31/0x9a [ 46.622647] ? lock_acquired+0x361/0x3c3 [ 46.622956] ? move_linked_works+0x46/0x7d [ 46.623277] worker_thread+0x1ce/0x291 [ 46.623582] ? __kthread_parkme+0xc8/0xdf [ 46.623900] ? __pfx_worker_thread+0x10/0x10 [ 46.624236] kthread+0x17e/0x190 [ 46.624501] ? kthread+0xfb/0x190 [ 46.624756] ? __pfx_kthread+0x10/0x10 [ 46.625015] ret_from_fork+0x20/0x40 [ 46.625268] ? __pfx_kthread+0x10/0x10 [ 46.625532] ret_from_fork_asm+0x1a/0x30 [ 46.625805] </TASK> [ 46.625953] [ 46.626056] Allocated by task 678: [ 46.626287] kasan_save_stack+0x24/0x44 [ 46.626555] kasan_save_track+0x14/0x2d [ 46.626811] __kasan_kmalloc+0x3f/0x4d [ 46.627049] __kmalloc_noprof+0x1bf/0x1f0 [ 46.627362] typec_register_port+0x23/0x491 [ 46.627698] cros_typec_probe+0x634/0xbb6 [ 46.628026] platform_probe+0x47/0x8c [ 46.628311] really_probe+0x20a/0x47d [ 46.628605] device_driver_attach+0x39/0x72 [ 46.628940] bind_store+0x87/0xd7 [ 46.629213] kernfs_fop_write_iter+0x1aa/0x218 [ 46.629574] vfs_write+0x1d6/0x29b [ 46.629856] ksys_write+0xcd/0x13b [ 46.630128] do_syscall_64+0xd4/0x139 [ 46.630420] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 46.630820] [ 46.630946] Freed by task 48: [ 46.631182] kasan_save_stack+0x24/0x44 [ 46.631493] kasan_save_track+0x14/0x2d [ 46.631799] kasan_save_free_info+0x3f/0x4d [ 46.632144] __kasan_slab_free+0x37/0x45 [ 46.632474] ---truncated---(CVE-2024-50150)
In the Linux kernel, the following vulnerability has been resolved: netdevsim: use cond_resched() in nsim_dev_trap_report_work() I am still seeing many syzbot reports hinting that syzbot might fool nsim_dev_trap_report_work() with hundreds of ports [1] Lets use cond_resched(), and system_unbound_wq instead of implicit system_wq. [1] INFO: task syz-executor:20633 blocked for more than 143 seconds. Not tainted 6.12.0-rc2-syzkaller-00205-g1d227fcc7222 #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:syz-executor state:D stack:25856 pid:20633 tgid:20633 ppid:1 flags:0x00004006 ... NMI backtrace for cpu 1 CPU: 1 UID: 0 PID: 16760 Comm: kworker/1:0 Not tainted 6.12.0-rc2-syzkaller-00205-g1d227fcc7222 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Workqueue: events nsim_dev_trap_report_work RIP: 0010:__sanitizer_cov_trace_pc+0x0/0x70 kernel/kcov.c:210 Code: 89 fb e8 23 00 00 00 48 8b 3d 04 fb 9c 0c 48 89 de 5b e9 c3 c7 5d 00 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 <f3> 0f 1e fa 48 8b 04 24 65 48 8b 0c 25 c0 d7 03 00 65 8b 15 60 f0 RSP: 0018:ffffc90000a187e8 EFLAGS: 00000246 RAX: 0000000000000100 RBX: ffffc90000a188e0 RCX: ffff888027d3bc00 RDX: ffff888027d3bc00 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffff88804a2e6000 R08: ffffffff8a4bc495 R09: ffffffff89da3577 R10: 0000000000000004 R11: ffffffff8a4bc2b0 R12: dffffc0000000000 R13: ffff88806573b503 R14: dffffc0000000000 R15: ffff8880663cca00 FS: 0000000000000000(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fc90a747f98 CR3: 000000000e734000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 000000000000002b DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Call Trace: <NMI> </NMI> <TASK> __local_bh_enable_ip+0x1bb/0x200 kernel/softirq.c:382 spin_unlock_bh include/linux/spinlock.h:396 [inline] nsim_dev_trap_report drivers/net/netdevsim/dev.c:820 [inline] nsim_dev_trap_report_work+0x75d/0xaa0 drivers/net/netdevsim/dev.c:850 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa63/0x1850 kernel/workqueue.c:3310 worker_thread+0x870/0xd30 kernel/workqueue.c:3391 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-50155)
In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Fix out of bound check Driver exports pacing stats only on GenP5 and P7 adapters. But while parsing the pacing stats, driver has a check for "rdev->dbr_pacing". This caused a trace when KASAN is enabled. BUG: KASAN: slab-out-of-bounds in bnxt_re_get_hw_stats+0x2b6a/0x2e00 [bnxt_re] Write of size 8 at addr ffff8885942a6340 by task modprobe/4809(CVE-2024-50158)
In the Linux kernel, the following vulnerability has been resolved: bpf: Make sure internal and UAPI bpf_redirect flags don't overlap The bpf_redirect_info is shared between the SKB and XDP redirect paths, and the two paths use the same numeric flag values in the ri->flags field (specifically, BPF_F_BROADCAST == BPF_F_NEXTHOP). This means that if skb bpf_redirect_neigh() is used with a non-NULL params argument and, subsequently, an XDP redirect is performed using the same bpf_redirect_info struct, the XDP path will get confused and end up crashing, which syzbot managed to trigger. With the stack-allocated bpf_redirect_info, the structure is no longer shared between the SKB and XDP paths, so the crash doesn't happen anymore. However, different code paths using identically-numbered flag values in the same struct field still seems like a bit of a mess, so this patch cleans that up by moving the flag definitions together and redefining the three flags in BPF_F_REDIRECT_INTERNAL to not overlap with the flags used for XDP. It also adds a BUILD_BUG_ON() check to make sure the overlap is not re-introduced by mistake.(CVE-2024-50163)
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix overloading of MEM_UNINIT's meaning Lonial reported an issue in the BPF verifier where check_mem_size_reg() has the following code: if (!tnum_is_const(reg->var_off)) / For unprivileged variable accesses, disable raw * mode so that the program is required to * initialize all the memory that the helper could * just partially fill up. / meta = NULL; This means that writes are not checked when the register containing the size of the passed buffer has not a fixed size. Through this bug, a BPF program can write to a map which is marked as read-only, for example, .rodata global maps. The problem is that MEM_UNINIT's initial meaning that "the passed buffer to the BPF helper does not need to be initialized" which was added back in commit 435faee1aae9 ("bpf, verifier: add ARG_PTR_TO_RAW_STACK type") got overloaded over time with "the passed buffer is being written to". The problem however is that checks such as the above which were added later via 06c1c049721a ("bpf: allow helpers access to variable memory") set meta to NULL in order force the user to always initialize the passed buffer to the helper. Due to the current double meaning of MEM_UNINIT, this bypasses verifier write checks to the memory (not boundary checks though) and only assumes the latter memory is read instead. Fix this by reverting MEM_UNINIT back to its original meaning, and having MEM_WRITE as an annotation to BPF helpers in order to then trigger the BPF verifier checks for writing to memory. Some notes: check_arg_pair_ok() ensures that for ARG_CONST_SIZE{,_OR_ZERO} we can access fn->arg_type[arg - 1] since it must contain a preceding ARG_PTR_TO_MEM. For check_mem_reg() the meta argument can be removed altogether since we do check both BPF_READ and BPF_WRITE. Same for the equivalent check_kfunc_mem_size_reg().(CVE-2024-50164)
In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Stop the active perfmon before being destroyed Upon closing the file descriptor, the active performance monitor is not stopped. Although all perfmons are destroyed in vc4_perfmon_close_file(), the active performance monitor's pointer (vc4->active_perfmon) is still retained. If we open a new file descriptor and submit a few jobs with performance monitors, the driver will attempt to stop the active performance monitor using the stale pointer in vc4->active_perfmon. However, this pointer is no longer valid because the previous process has already terminated, and all performance monitors associated with it have been destroyed and freed. To fix this, when the active performance monitor belongs to a given process, explicitly stop it before destroying and freeing it.(CVE-2024-50187)
In the Linux kernel, the following vulnerability has been resolved: net: phy: dp83869: fix memory corruption when enabling fiber When configuring the fiber port, the DP83869 PHY driver incorrectly calls linkmode_set_bit() with a bit mask (1 << 10) rather than a bit number (10). This corrupts some other memory location -- in case of arm64 the priv pointer in the same structure. Since the advertising flags are updated from supported at the end of the function the incorrect line isn't needed at all and can be removed.(CVE-2024-50188)
In the Linux kernel, the following vulnerability has been resolved: pinctrl: ocelot: fix system hang on level based interrupts The current implementation only calls chained_irq_enter() and chained_irq_exit() if it detects pending interrupts. for (i = 0; i < info->stride; i++) { uregmap_read(info->map, id_reg + 4 * i, &reg); if (!reg) continue; chained_irq_enter(parent_chip, desc); However, in case of GPIO pin configured in level mode and the parent controller configured in edge mode, GPIO interrupt might be lowered by the hardware. In the result, if the interrupt is short enough, the parent interrupt is still pending while the GPIO interrupt is cleared; chained_irq_enter() never gets called and the system hangs trying to service the parent interrupt. Moving chained_irq_enter() and chained_irq_exit() outside the for loop ensures that they are called even when GPIO interrupt is lowered by the hardware. The similar code with chained_irq_enter() / chained_irq_exit() functions wrapping interrupt checking loop may be found in many other drivers: grep -r -A 10 chained_irq_enter drivers/pinctrl(CVE-2024-50196)
In the Linux kernel, the following vulnerability has been resolved: drm/radeon: Fix encoder->possible_clones Include the encoder itself in its possible_clones bitmask. In the past nothing validated that drivers were populating possible_clones correctly, but that changed in commit 74d2aacbe840 ("drm: Validate encoder->possible_clones"). Looks like radeon never got the memo and is still not following the rules 100% correctly. This results in some warnings during driver initialization: Bogus possible_clones: [ENCODER:46:TV-46] possible_clones=0x4 (full encoder mask=0x7) WARNING: CPU: 0 PID: 170 at drivers/gpu/drm/drm_mode_config.c:615 drm_mode_config_validate+0x113/0x39c ... (cherry picked from commit 3b6e7d40649c0d75572039aff9d0911864c689db)(CVE-2024-50201)
In the Linux kernel, the following vulnerability has been resolved: udf: refactor inode_bmap() to handle error Refactor inode_bmap() to handle error since udf_next_aext() can return error now. On situations like ftruncate, udf_extend_file() can now detect errors and bail out early without resorting to checking for particular offsets and assuming internal behavior of these functions.(CVE-2024-50211)
In the Linux kernel, the following vulnerability has been resolved: ocfs2: pass u64 to ocfs2_truncate_inline maybe overflow Syzbot reported a kernel BUG in ocfs2_truncate_inline. There are two reasons for this: first, the parameter value passed is greater than ocfs2_max_inline_data_with_xattr, second, the start and end parameters of ocfs2_truncate_inline are "unsigned int". So, we need to add a sanity check for byte_start and byte_len right before ocfs2_truncate_inline() in ocfs2_remove_inode_range(), if they are greater than ocfs2_max_inline_data_with_xattr return -EINVAL.(CVE-2024-50218)
In the Linux kernel, the following vulnerability has been resolved: iov_iter: fix copy_page_from_iter_atomic() if KMAP_LOCAL_FORCE_MAP generic/077 on x86_32 CONFIG_DEBUG_KMAP_LOCAL_FORCE_MAP=y with highmem, on huge=always tmpfs, issues a warning and then hangs (interruptibly): WARNING: CPU: 5 PID: 3517 at mm/highmem.c:622 kunmap_local_indexed+0x62/0xc9 CPU: 5 UID: 0 PID: 3517 Comm: cp Not tainted 6.12.0-rc4 #2 ... copy_page_from_iter_atomic+0xa6/0x5ec generic_perform_write+0xf6/0x1b4 shmem_file_write_iter+0x54/0x67 Fix copy_page_from_iter_atomic() by limiting it in that case (include/linux/skbuff.h skb_frag_must_loop() does similar). But going forward, perhaps CONFIG_DEBUG_KMAP_LOCAL_FORCE_MAP is too surprising, has outlived its usefulness, and should just be removed?(CVE-2024-50222)
In the Linux kernel, the following vulnerability has been resolved: cxl/port: Fix use-after-free, permit out-of-order decoder shutdown In support of investigating an initialization failure report [1], cxl_test was updated to register mock memory-devices after the mock root-port/bus device had been registered. That led to cxl_test crashing with a use-after-free bug with the following signature: cxl_port_attach_region: cxl region3: cxl_host_bridge.0:port3 decoder3.0 add: mem0:decoder7.0 @ 0 next: cxl_switch_uport.0 nr_eps: 1 nr_targets: 1 cxl_port_attach_region: cxl region3: cxl_host_bridge.0:port3 decoder3.0 add: mem4:decoder14.0 @ 1 next: cxl_switch_uport.0 nr_eps: 2 nr_targets: 1 cxl_port_setup_targets: cxl region3: cxl_switch_uport.0:port6 target[0] = cxl_switch_dport.0 for mem0:decoder7.0 @ 0 1) cxl_port_setup_targets: cxl region3: cxl_switch_uport.0:port6 target[1] = cxl_switch_dport.4 for mem4:decoder14.0 @ 1 [..] cxld_unregister: cxl decoder14.0: cxl_region_decode_reset: cxl_region region3: mock_decoder_reset: cxl_port port3: decoder3.0 reset 2) mock_decoder_reset: cxl_port port3: decoder3.0: out of order reset, expected decoder3.1 cxl_endpoint_decoder_release: cxl decoder14.0: [..] cxld_unregister: cxl decoder7.0: 3) cxl_region_decode_reset: cxl_region region3: Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6bc3: 0000 [#1] PREEMPT SMP PTI [..] RIP: 0010:to_cxl_port+0x8/0x60 [cxl_core] [..] Call Trace: <TASK> cxl_region_decode_reset+0x69/0x190 [cxl_core] cxl_region_detach+0xe8/0x210 [cxl_core] cxl_decoder_kill_region+0x27/0x40 [cxl_core] cxld_unregister+0x5d/0x60 [cxl_core] At 1) a region has been established with 2 endpoint decoders (7.0 and 14.0). Those endpoints share a common switch-decoder in the topology (3.0). At teardown, 2), decoder14.0 is the first to be removed and hits the "out of order reset case" in the switch decoder. The effect though is that region3 cleanup is aborted leaving it in-tact and referencing decoder14.0. At 3) the second attempt to teardown region3 trips over the stale decoder14.0 object which has long since been deleted. The fix here is to recognize that the CXL specification places no mandate on in-order shutdown of switch-decoders, the driver enforces in-order allocation, and hardware enforces in-order commit. So, rather than fail and leave objects dangling, always remove them. In support of making cxl_region_decode_reset() always succeed, cxl_region_invalidate_memregion() failures are turned into warnings. Crashing the kernel is ok there since system integrity is at risk if caches cannot be managed around physical address mutation events like CXL region destruction. A new device_for_each_child_reverse_from() is added to cleanup port->commit_end after all dependent decoders have been disabled. In other words if decoders are allocated 0->1->2 and disabled 1->2->0 then port->commit_end only decrements from 2 after 2 has been disabled, and it decrements all the way to zero since 1 was disabled previously.(CVE-2024-50226)
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential deadlock with newly created symlinks Syzbot reported that page_symlink(), called by nilfs_symlink(), triggers memory reclamation involving the filesystem layer, which can result in circular lock dependencies among the reader/writer semaphore nilfs->ns_segctor_sem, s_writers percpu_rwsem (intwrite) and the fs_reclaim pseudo lock. This is because after commit 21fc61c73c39 ("don't put symlink bodies in pagecache into highmem"), the gfp flags of the page cache for symbolic links are overwritten to GFP_KERNEL via inode_nohighmem(). This is not a problem for symlinks read from the backing device, because the __GFP_FS flag is dropped after inode_nohighmem() is called. However, when a new symlink is created with nilfs_symlink(), the gfp flags remain overwritten to GFP_KERNEL. Then, memory allocation called from page_symlink() etc. triggers memory reclamation including the FS layer, which may call nilfs_evict_inode() or nilfs_dirty_inode(). And these can cause a deadlock if they are called while nilfs->ns_segctor_sem is held: Fix this issue by dropping the __GFP_FS flag from the page cache GFP flags of newly created symlinks in the same way that nilfs_new_inode() and __nilfs_read_inode() do, as a workaround until we adopt nofs allocation scope consistently or improve the locking constraints.(CVE-2024-50229)
In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: clear wdev->cqm_config pointer on free When we free wdev->cqm_config when unregistering, we also need to clear out the pointer since the same wdev/netdev may get re-registered in another network namespace, then destroyed later, running this code again, which results in a double-free.(CVE-2024-50235)
In the Linux kernel, the following vulnerability has been resolved: netdevsim: Add trailing zero to terminate the string in nsim_nexthop_bucket_activity_write() This was found by a static analyzer. We should not forget the trailing zero after copy_from_user() if we will further do some string operations, sscanf() in this case. Adding a trailing zero will ensure that the function performs properly.(CVE-2024-50259)
In the Linux kernel, the following vulnerability has been resolved: macsec: Fix use-after-free while sending the offloading packet KASAN reports the following UAF. The metadata_dst, which is used to store the SCI value for macsec offload, is already freed by metadata_dst_free() in macsec_free_netdev(), while driver still use it for sending the packet. To fix this issue, dst_release() is used instead to release metadata_dst. So it is not freed instantly in macsec_free_netdev() if still referenced by skb. BUG: KASAN: slab-use-after-free in mlx5e_xmit+0x1e8f/0x4190 [mlx5_core] Read of size 2 at addr ffff88813e42e038 by task kworker/7:2/714 [...] Workqueue: mld mld_ifc_work Call Trace: <TASK> dump_stack_lvl+0x51/0x60 print_report+0xc1/0x600 kasan_report+0xab/0xe0 mlx5e_xmit+0x1e8f/0x4190 [mlx5_core] dev_hard_start_xmit+0x120/0x530 sch_direct_xmit+0x149/0x11e0 __qdisc_run+0x3ad/0x1730 __dev_queue_xmit+0x1196/0x2ed0 vlan_dev_hard_start_xmit+0x32e/0x510 [8021q] dev_hard_start_xmit+0x120/0x530 __dev_queue_xmit+0x14a7/0x2ed0 macsec_start_xmit+0x13e9/0x2340 dev_hard_start_xmit+0x120/0x530 __dev_queue_xmit+0x14a7/0x2ed0 ip6_finish_output2+0x923/0x1a70 ip6_finish_output+0x2d7/0x970 ip6_output+0x1ce/0x3a0 NF_HOOK.constprop.0+0x15f/0x190 mld_sendpack+0x59a/0xbd0 mld_ifc_work+0x48a/0xa80 process_one_work+0x5aa/0xe50 worker_thread+0x79c/0x1290 kthread+0x28f/0x350 ret_from_fork+0x2d/0x70 ret_from_fork_asm+0x11/0x20 </TASK> Allocated by task 3922: kasan_save_stack+0x20/0x40 kasan_save_track+0x10/0x30 __kasan_kmalloc+0x77/0x90 __kmalloc_noprof+0x188/0x400 metadata_dst_alloc+0x1f/0x4e0 macsec_newlink+0x914/0x1410 __rtnl_newlink+0xe08/0x15b0 rtnl_newlink+0x5f/0x90 rtnetlink_rcv_msg+0x667/0xa80 netlink_rcv_skb+0x12c/0x360 netlink_unicast+0x551/0x770 netlink_sendmsg+0x72d/0xbd0 __sock_sendmsg+0xc5/0x190 _syssendmsg+0x52e/0x6a0 _sys_sendmsg+0xeb/0x170 __sys_sendmsg+0xb5/0x140 do_syscall_64+0x4c/0x100 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Freed by task 4011: kasan_save_stack+0x20/0x40 kasan_save_track+0x10/0x30 kasan_save_free_info+0x37/0x50 poison_slab_object+0x10c/0x190 __kasan_slab_free+0x11/0x30 kfree+0xe0/0x290 macsec_free_netdev+0x3f/0x140 netdev_run_todo+0x450/0xc70 rtnetlink_rcv_msg+0x66f/0xa80 netlink_rcv_skb+0x12c/0x360 netlink_unicast+0x551/0x770 netlink_sendmsg+0x72d/0xbd0 __sock_sendmsg+0xc5/0x190 _syssendmsg+0x52e/0x6a0 _sys_sendmsg+0xeb/0x170 __sys_sendmsg+0xb5/0x140 do_syscall_64+0x4c/0x100 entry_SYSCALL_64_after_hwframe+0x4b/0x53(CVE-2024-50261)
In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: Initialization of the dangling pointer occurring in vsk->trans During loopback communication, a dangling pointer can be created in vsk->trans, potentially leading to a Use-After-Free condition. This issue is resolved by initializing vsk->trans to NULL.(CVE-2024-50264)
In the Linux kernel, the following vulnerability has been resolved: dm cache: fix potential out-of-bounds access on the first resume Out-of-bounds access occurs if the fast device is expanded unexpectedly before the first-time resume of the cache table. This happens because expanding the fast device requires reloading the cache table for cache_create to allocate new in-core data structures that fit the new size, and the check in cache_preresume is not performed during the first resume, leading to the issue. Reproduce steps: 1. prepare component devices: dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" dmsetup create cdata --table "0 65536 linear /dev/sdc 8192" dmsetup create corig --table "0 524288 linear /dev/sdc 262144" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct 2. load a cache table of 512 cache blocks, and deliberately expand the fast device before resuming the cache, making the in-core data structures inadequate. dmsetup create cache --notable dmsetup reload cache --table "0 524288 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0" dmsetup reload cdata --table "0 131072 linear /dev/sdc 8192" dmsetup resume cdata dmsetup resume cache 3. suspend the cache to write out the in-core dirty bitset and hint array, leading to out-of-bounds access to the dirty bitset at offset 0x40: dmsetup suspend cache KASAN reports: BUG: KASAN: vmalloc-out-of-bounds in is_dirty_callback+0x2b/0x80 Read of size 8 at addr ffffc90000085040 by task dmsetup/90 (...snip...) The buggy address belongs to the virtual mapping at [ffffc90000085000, ffffc90000087000) created by: cache_ctr+0x176a/0x35f0 (...snip...) Memory state around the buggy address: ffffc90000084f00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90000084f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 >ffffc90000085000: 00 00 00 00 00 00 00 00 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc90000085080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90000085100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 Fix by checking the size change on the first resume.(CVE-2024-50278)
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: add missing size check in amdgpu_debugfs_gprwave_read() Avoid a possible buffer overflow if size is larger than 4K. (cherry picked from commit f5d873f5825b40d886d03bd2aede91d4cf002434)(CVE-2024-50282)
In the Linux kernel, the following vulnerability has been resolved: ksmbd: check outstanding simultaneous SMB operations If Client send simultaneous SMB operations to ksmbd, It exhausts too much memory through the "ksmbd_work_cache”. It will cause OOM issue. ksmbd has a credit mechanism but it can't handle this problem. This patch add the check if it exceeds max credits to prevent this problem by assuming that one smb request consumes at least one credit.(CVE-2024-50285)
In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix slab-use-after-free in ksmbd_smb2_session_create There is a race condition between ksmbd_smb2_session_create and ksmbd_expire_session. This patch add missing sessions_table_lock while adding/deleting session from global session table.(CVE-2024-50286)
In the Linux kernel, the following vulnerability has been resolved: regulator: rtq2208: Fix uninitialized use of regulator_config Fix rtq2208 driver uninitialized use to cause kernel error.(CVE-2024-50300)
In the Linux kernel, the following vulnerability has been resolved: ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_init_flow() There are code paths from which the function is called without holding the RCU read lock, resulting in a suspicious RCU usage warning [1]. Fix by using l3mdev_master_upper_ifindex_by_index() which will acquire the RCU read lock before calling l3mdev_master_upper_ifindex_by_index_rcu(). [1] WARNING: suspicious RCU usage 6.12.0-rc3-custom-gac8f72681cf2 #141 Not tainted ----------------------------- net/core/dev.c:876 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by ip/361: #0: ffffffff86fc7cb0 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x377/0xf60 stack backtrace: CPU: 3 UID: 0 PID: 361 Comm: ip Not tainted 6.12.0-rc3-custom-gac8f72681cf2 #141 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: <TASK> dump_stack_lvl+0xba/0x110 lockdep_rcu_suspicious.cold+0x4f/0xd6 dev_get_by_index_rcu+0x1d3/0x210 l3mdev_master_upper_ifindex_by_index_rcu+0x2b/0xf0 ip_tunnel_bind_dev+0x72f/0xa00 ip_tunnel_newlink+0x368/0x7a0 ipgre_newlink+0x14c/0x170 __rtnl_newlink+0x1173/0x19c0 rtnl_newlink+0x6c/0xa0 rtnetlink_rcv_msg+0x3cc/0xf60 netlink_rcv_skb+0x171/0x450 netlink_unicast+0x539/0x7f0 netlink_sendmsg+0x8c1/0xd80 _syssendmsg+0x8f9/0xc20 _sys_sendmsg+0x197/0x1e0 __sys_sendmsg+0x122/0x1f0 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2024-53042)
In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: Fix response handling in iwl_mvm_send_recovery_cmd() 1. The size of the response packet is not validated. 2. The response buffer is not freed. Resolve these issues by switching to iwl_mvm_send_cmd_status(), which handles both size validation and frees the buffer.(CVE-2024-53059)
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: prevent NULL pointer dereference if ATIF is not supported acpi_evaluate_object() may return AE_NOT_FOUND (failure), which would result in dereferencing buffer.pointer (obj) while being NULL. Although this case may be unrealistic for the current code, it is still better to protect against possible bugs. Bail out also when status is AE_NOT_FOUND. This fixes 1 FORWARD_NULL issue reported by Coverity Report: CID 1600951: Null pointer dereferences (FORWARD_NULL) (cherry picked from commit 91c9e221fe2553edf2db71627d8453f083de87a1)(CVE-2024-53060)
In the Linux kernel, the following vulnerability has been resolved: NFSD: Never decrement pending_async_copies on error The error flow in nfsd4_copy() calls cleanup_async_copy(), which already decrements nn->pending_async_copies.(CVE-2024-53073)
In the Linux kernel, the following vulnerability has been resolved: afs: Fix lock recursion afs_wake_up_async_call() can incur lock recursion. The problem is that it is called from AF_RXRPC whilst holding the ->notify_lock, but it tries to take a ref on the afs_call struct in order to pass it to a work queue - but if the afs_call is already queued, we then have an extraneous ref that must be put... calling afs_put_call() may call back down into AF_RXRPC through rxrpc_kernel_shutdown_call(), however, which might try taking the ->notify_lock again. This case isn't very common, however, so defer it to a workqueue. The oops looks something like: BUG: spinlock recursion on CPU#0, krxrpcio/7001/1646 lock: 0xffff888141399b30, .magic: dead4ead, .owner: krxrpcio/7001/1646, .owner_cpu: 0 CPU: 0 UID: 0 PID: 1646 Comm: krxrpcio/7001 Not tainted 6.12.0-rc2-build3+ #4351 Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014 Call Trace: <TASK> dump_stack_lvl+0x47/0x70 do_raw_spin_lock+0x3c/0x90 rxrpc_kernel_shutdown_call+0x83/0xb0 afs_put_call+0xd7/0x180 rxrpc_notify_socket+0xa0/0x190 rxrpc_input_split_jumbo+0x198/0x1d0 rxrpc_input_data+0x14b/0x1e0 ? rxrpc_input_call_packet+0xc2/0x1f0 rxrpc_input_call_event+0xad/0x6b0 rxrpc_input_packet_on_conn+0x1e1/0x210 rxrpc_input_packet+0x3f2/0x4d0 rxrpc_io_thread+0x243/0x410 ? __pfx_rxrpc_io_thread+0x10/0x10 kthread+0xcf/0xe0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x24/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK>(CVE-2024-53090)
| URL | Type | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-6.6.0-61.0.0.60.oe2403.aarch64.rpm",
"bpftool-debuginfo-6.6.0-61.0.0.60.oe2403.aarch64.rpm",
"kernel-6.6.0-61.0.0.60.oe2403.aarch64.rpm",
"kernel-debuginfo-6.6.0-61.0.0.60.oe2403.aarch64.rpm",
"kernel-debugsource-6.6.0-61.0.0.60.oe2403.aarch64.rpm",
"kernel-devel-6.6.0-61.0.0.60.oe2403.aarch64.rpm",
"kernel-headers-6.6.0-61.0.0.60.oe2403.aarch64.rpm",
"kernel-source-6.6.0-61.0.0.60.oe2403.aarch64.rpm",
"kernel-tools-6.6.0-61.0.0.60.oe2403.aarch64.rpm",
"kernel-tools-debuginfo-6.6.0-61.0.0.60.oe2403.aarch64.rpm",
"kernel-tools-devel-6.6.0-61.0.0.60.oe2403.aarch64.rpm",
"perf-6.6.0-61.0.0.60.oe2403.aarch64.rpm",
"perf-debuginfo-6.6.0-61.0.0.60.oe2403.aarch64.rpm",
"python3-perf-6.6.0-61.0.0.60.oe2403.aarch64.rpm",
"python3-perf-debuginfo-6.6.0-61.0.0.60.oe2403.aarch64.rpm"
],
"src": [
"kernel-6.6.0-61.0.0.60.oe2403.src.rpm"
],
"x86_64": [
"bpftool-6.6.0-61.0.0.60.oe2403.x86_64.rpm",
"bpftool-debuginfo-6.6.0-61.0.0.60.oe2403.x86_64.rpm",
"kernel-6.6.0-61.0.0.60.oe2403.x86_64.rpm",
"kernel-debuginfo-6.6.0-61.0.0.60.oe2403.x86_64.rpm",
"kernel-debugsource-6.6.0-61.0.0.60.oe2403.x86_64.rpm",
"kernel-devel-6.6.0-61.0.0.60.oe2403.x86_64.rpm",
"kernel-headers-6.6.0-61.0.0.60.oe2403.x86_64.rpm",
"kernel-source-6.6.0-61.0.0.60.oe2403.x86_64.rpm",
"kernel-tools-6.6.0-61.0.0.60.oe2403.x86_64.rpm",
"kernel-tools-debuginfo-6.6.0-61.0.0.60.oe2403.x86_64.rpm",
"kernel-tools-devel-6.6.0-61.0.0.60.oe2403.x86_64.rpm",
"perf-6.6.0-61.0.0.60.oe2403.x86_64.rpm",
"perf-debuginfo-6.6.0-61.0.0.60.oe2403.x86_64.rpm",
"python3-perf-6.6.0-61.0.0.60.oe2403.x86_64.rpm",
"python3-perf-debuginfo-6.6.0-61.0.0.60.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-61.0.0.60.oe2403"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nKVM: SVM: WARN on vNMI + NMI window iff NMIs are outright masked\r\n\r\nWhen requesting an NMI window, WARN on vNMI support being enabled if and\nonly if NMIs are actually masked, i.e. if the vCPU is already handling an\nNMI. KVM\u0026apos;s ABI for NMIs that arrive simultanesouly (from KVM\u0026apos;s point of\nview) is to inject one NMI and pend the other. When using vNMI, KVM pends\nthe second NMI simply by setting V_NMI_PENDING, and lets the CPU do the\nrest (hardware automatically sets V_NMI_BLOCKING when an NMI is injected).\r\n\r\nHowever, if KVM can\u0026apos;t immediately inject an NMI, e.g. because the vCPU is\nin an STI shadow or is running with GIF=0, then KVM will request an NMI\nwindow and trigger the WARN (but still function correctly).\r\n\r\nWhether or not the GIF=0 case makes sense is debatable, as the intent of\nKVM\u0026apos;s behavior is to provide functionality that is as close to real\nhardware as possible. E.g. if two NMIs are sent in quick succession, the\nprobability of both NMIs arriving in an STI shadow is infinitesimally low\non real hardware, but significantly larger in a virtual environment, e.g.\nif the vCPU is preempted in the STI shadow. For GIF=0, the argument isn\u0026apos;t\nas clear cut, because the window where two NMIs can collide is much larger\nin bare metal (though still small).\r\n\r\nThat said, KVM should not have divergent behavior for the GIF=0 case based\non whether or not vNMI support is enabled. And KVM has allowed\nsimultaneous NMIs with GIF=0 for over a decade, since commit 7460fb4a3400\n(\u0026quot;KVM: Fix simultaneous NMIs\u0026quot;). I.e. KVM\u0026apos;s GIF=0 handling shouldn\u0026apos;t be\nmodified without a *really* good reason to do so, and if KVM\u0026apos;s behavior\nwere to be modified, it should be done irrespective of vNMI support.(CVE-2024-39483)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nserial: sc16is7xx: fix invalid FIFO access with special register set\r\n\r\nWhen enabling access to the special register set, Receiver time-out and\nRHR interrupts can happen. In this case, the IRQ handler will try to read\nfrom the FIFO thru the RHR register at address 0x00, but address 0x00 is\nmapped to DLL register, resulting in erroneous FIFO reading.\r\n\r\nCall graph example:\n sc16is7xx_startup(): entry\n sc16is7xx_ms_proc(): entry\n sc16is7xx_set_termios(): entry\n sc16is7xx_set_baud(): DLH/DLL = $009C --\u0026gt; access special register set\n sc16is7xx_port_irq() entry --\u0026gt; IIR is 0x0C\n sc16is7xx_handle_rx() entry\n sc16is7xx_fifo_read(): --\u0026gt; unable to access FIFO (RHR) because it is\n mapped to DLL (LCR=LCR_CONF_MODE_A)\n sc16is7xx_set_baud(): exit --\u0026gt; Restore access to general register set\r\n\r\nFix the problem by claiming the efr_lock mutex when accessing the Special\nregister set.(CVE-2024-44950)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ns390/dasd: fix error recovery leading to data corruption on ESE devices\r\n\r\nExtent Space Efficient (ESE) or thin provisioned volumes need to be\nformatted on demand during usual IO processing.\r\n\r\nThe dasd_ese_needs_format function checks for error codes that signal\nthe non existence of a proper track format.\r\n\r\nThe check for incorrect length is to imprecise since other error cases\nleading to transport of insufficient data also have this flag set.\nThis might lead to data corruption in certain error cases for example\nduring a storage server warmstart.\r\n\r\nFix by removing the check for incorrect length and replacing by\nexplicitly checking for invalid track format in transport mode.\r\n\r\nAlso remove the check for file protected since this is not a valid\nESE handling case.(CVE-2024-45026)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Add missing NULL pointer check within dpcd_extend_address_range\r\n\r\n[Why \u0026amp; How]\nASSERT if return NULL from kcalloc.(CVE-2024-46808)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Check link_index before accessing dc-\u0026gt;links[]\r\n\r\n[WHY \u0026amp; HOW]\ndc-\u0026gt;links[] has max size of MAX_LINKS and NULL is return when trying to\naccess with out-of-bound index.\r\n\r\nThis fixes 3 OVERRUN and 1 RESOURCE_LEAK issues reported by Coverity.(CVE-2024-46813)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: iwlwifi: mvm: use IWL_FW_CHECK for link ID check\r\n\r\nThe lookup function iwl_mvm_rcu_fw_link_id_to_link_conf() is\nnormally called with input from the firmware, so it should use\nIWL_FW_CHECK() instead of WARN_ON().(CVE-2024-46825)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: scsi: sd: Fix off-by-one error in sd_read_block_characteristics() Ff the device returns page 0xb1 with length 8 (happens with qemu v2.x, for example), sd_read_block_characteristics() may attempt an out-of-bounds memory access when accessing the zoned field at offset 8.(CVE-2024-47682)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: block, bfq: fix possible UAF for bfqq-\u0026gt;bic with merge chain 1) initial state, three tasks: Process 1 Process 2 Process 3 (BIC1) (BIC2) (BIC3) | \u039b | \u039b | \u039b | | | | | | V | V | V | bfqq1 bfqq2 bfqq3 process ref: 1 1 1 2) bfqq1 merged to bfqq2: Process 1 Process 2 Process 3 (BIC1) (BIC2) (BIC3) | | | \u039b \\--------------\\| | | V V | bfqq1---------\u0026gt;bfqq2 bfqq3 process ref: 0 2 1 3) bfqq2 merged to bfqq3: Process 1 Process 2 Process 3 (BIC1) (BIC2) (BIC3) here -\u0026gt; \u039b | | \\--------------\\ \\-------------\\| V V bfqq1---------\u0026gt;bfqq2----------\u0026gt;bfqq3 process ref: 0 1 3 In this case, IO from Process 1 will get bfqq2 from BIC1 first, and then get bfqq3 through merge chain, and finially handle IO by bfqq3. Howerver, current code will think bfqq2 is owned by BIC1, like initial state, and set bfqq2-\u0026gt;bic to BIC1. bfq_insert_request -\u0026gt; by Process 1 bfqq = bfq_init_rq(rq) bfqq = bfq_get_bfqq_handle_split bfqq = bic_to_bfqq -\u0026gt; get bfqq2 from BIC1 bfqq-\u0026gt;ref++ rq-\u0026gt;elv.priv[0] = bic rq-\u0026gt;elv.priv[1] = bfqq if (bfqq_process_refs(bfqq) == 1) bfqq-\u0026gt;bic = bic -\u0026gt; record BIC1 to bfqq2 __bfq_insert_request new_bfqq = bfq_setup_cooperator -\u0026gt; get bfqq3 from bfqq2-\u0026gt;new_bfqq bfqq_request_freed(bfqq) new_bfqq-\u0026gt;ref++ rq-\u0026gt;elv.priv[1] = new_bfqq -\u0026gt; handle IO by bfqq3 Fix the problem by checking bfqq is from merge chain fist. And this might fix a following problem reported by our syzkaller(unreproducible): ================================================================== BUG: KASAN: slab-use-after-free in bfq_do_early_stable_merge block/bfq-iosched.c:5692 [inline] BUG: KASAN: slab-use-after-free in bfq_do_or_sched_stable_merge block/bfq-iosched.c:5805 [inline] BUG: KASAN: slab-use-after-free in bfq_get_queue+0x25b0/0x2610 block/bfq-iosched.c:5889 Write of size 1 at addr ffff888123839eb8 by task kworker/0:1H/18595 CPU: 0 PID: 18595 Comm: kworker/0:1H Tainted: G L 6.6.0-07439-gba2303cacfda #6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 Workqueue: kblockd blk_mq_requeue_work Call Trace: \u0026lt;TASK\u0026gt; __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x91/0xf0 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:364 [inline] print_report+0x10d/0x610 mm/kasan/report.c:475 kasan_report+0x8e/0xc0 mm/kasan/report.c:588 bfq_do_early_stable_merge block/bfq-iosched.c:5692 [inline] bfq_do_or_sched_stable_merge block/bfq-iosched.c:5805 [inline] bfq_get_queue+0x25b0/0x2610 block/bfq-iosched.c:5889 bfq_get_bfqq_handle_split+0x169/0x5d0 block/bfq-iosched.c:6757 bfq_init_rq block/bfq-iosched.c:6876 [inline] bfq_insert_request block/bfq-iosched.c:6254 [inline] bfq_insert_requests+0x1112/0x5cf0 block/bfq-iosched.c:6304 blk_mq_insert_request+0x290/0x8d0 block/blk-mq.c:2593 blk_mq_requeue_work+0x6bc/0xa70 block/blk-mq.c:1502 process_one_work kernel/workqueue.c:2627 [inline] process_scheduled_works+0x432/0x13f0 kernel/workqueue.c:2700 worker_thread+0x6f2/0x1160 kernel/workqueue.c:2781 kthread+0x33c/0x440 kernel/kthread.c:388 ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:305 \u0026lt;/TASK\u0026gt; Allocated by task 20776: kasan_save_stack+0x20/0x40 mm/kasan/common.c:45 kasan_set_track+0x25/0x30 mm/kasan/common.c:52 __kasan_slab_alloc+0x87/0x90 mm/kasan/common.c:328 kasan_slab_alloc include/linux/kasan.h:188 [inline] slab_post_alloc_hook mm/slab.h:763 [inline] slab_alloc_node mm/slub.c:3458 [inline] kmem_cache_alloc_node+0x1a4/0x6f0 mm/slub.c:3503 ioc_create_icq block/blk-ioc.c:370 [inline] ---truncated---(CVE-2024-47706)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: use hweight16 to get correct tx antenna The chainmask is u16 so using hweight8 cannot get correct tx_ant. Without this patch, the tx_ant of band 2 would be -1 and lead to the following issue: BUG: KASAN: stack-out-of-bounds in mt7996_mcu_add_sta+0x12e0/0x16e0 [mt7996e](CVE-2024-47714)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: fix oops on non-dbdc mt7986 mt7915_band_config() sets band_idx = 1 on the main phy for mt7986 with MT7975_ONE_ADIE or MT7976_ONE_ADIE. Commit 0335c034e726 (\u0026quot;wifi: mt76: fix race condition related to checking tx queue fill status\u0026quot;) introduced a dereference of the phys array indirectly indexed by band_idx via wcid-\u0026gt;phy_idx in mt76_wcid_cleanup(). This caused the following Oops on affected mt7986 devices: Unable to handle kernel read from unreadable memory at virtual address 0000000000000024 Mem abort info: ESR = 0x0000000096000005 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x05: level 1 translation fault Data abort info: ISV = 0, ISS = 0x00000005 CM = 0, WnR = 0 user pgtable: 4k pages, 39-bit VAs, pgdp=0000000042545000 [0000000000000024] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 Internal error: Oops: 0000000096000005 [#1] SMP Modules linked in: ... mt7915e mt76_connac_lib mt76 mac80211 cfg80211 ... CPU: 2 PID: 1631 Comm: hostapd Not tainted 5.15.150 #0 Hardware name: ZyXEL EX5700 (Telenor) (DT) pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : mt76_wcid_cleanup+0x84/0x22c [mt76] lr : mt76_wcid_cleanup+0x64/0x22c [mt76] sp : ffffffc00a803700 x29: ffffffc00a803700 x28: ffffff80008f7300 x27: ffffff80003f3c00 x26: ffffff80000a7880 x25: ffffffc008c26e00 x24: 0000000000000001 x23: ffffffc000a68114 x22: 0000000000000000 x21: ffffff8004172cc8 x20: ffffffc00a803748 x19: ffffff8004152020 x18: 0000000000000000 x17: 00000000000017c0 x16: ffffffc008ef5000 x15: 0000000000000be0 x14: ffffff8004172e28 x13: ffffff8004172e28 x12: 0000000000000000 x11: 0000000000000000 x10: ffffff8004172e30 x9 : ffffff8004172e28 x8 : 0000000000000000 x7 : ffffff8004156020 x6 : 0000000000000000 x5 : 0000000000000031 x4 : 0000000000000000 x3 : 0000000000000001 x2 : 0000000000000000 x1 : ffffff80008f7300 x0 : 0000000000000024 Call trace: mt76_wcid_cleanup+0x84/0x22c [mt76] __mt76_sta_remove+0x70/0xbc [mt76] mt76_sta_state+0x8c/0x1a4 [mt76] mt7915_eeprom_get_power_delta+0x11e4/0x23a0 [mt7915e] drv_sta_state+0x144/0x274 [mac80211] sta_info_move_state+0x1cc/0x2a4 [mac80211] sta_set_sinfo+0xaf8/0xc24 [mac80211] sta_info_destroy_addr_bss+0x4c/0x6c [mac80211] ieee80211_color_change_finish+0x1c08/0x1e70 [mac80211] cfg80211_check_station_change+0x1360/0x4710 [cfg80211] genl_family_rcv_msg_doit+0xb4/0x110 genl_rcv_msg+0xd0/0x1bc netlink_rcv_skb+0x58/0x120 genl_rcv+0x34/0x50 netlink_unicast+0x1f0/0x2ec netlink_sendmsg+0x198/0x3d0 ____sys_sendmsg+0x1b0/0x210 ___sys_sendmsg+0x80/0xf0 __sys_sendmsg+0x44/0xa0 __arm64_sys_sendmsg+0x20/0x30 invoke_syscall.constprop.0+0x4c/0xe0 do_el0_svc+0x40/0xd0 el0_svc+0x14/0x4c el0t_64_sync_handler+0x100/0x110 el0t_64_sync+0x15c/0x160 Code: d2800002 910092c0 52800023 f9800011 (885f7c01) ---[ end trace 7e42dd9a39ed2281 ]--- Fix by using mt76_dev_phy() which will map band_idx to the correct phy for all hardware combinations.(CVE-2024-47715)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: always wait for both firmware loading attempts In \u0026apos;rtw_wait_firmware_completion()\u0026apos;, always wait for both (regular and wowlan) firmware loading attempts. Otherwise if \u0026apos;rtw_usb_intf_init()\u0026apos; has failed in \u0026apos;rtw_usb_probe()\u0026apos;, \u0026apos;rtw_usb_disconnect()\u0026apos; may issue \u0026apos;ieee80211_free_hw()\u0026apos; when one of \u0026apos;rtw_load_firmware_cb()\u0026apos; (usually the wowlan one) is still in progress, causing UAF detected by KASAN.(CVE-2024-47718)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: bonding: Fix unnecessary warnings and logs from bond_xdp_get_xmit_slave() syzbot reported a WARNING in bond_xdp_get_xmit_slave. To reproduce this[1], one bond device (bond1) has xdpdrv, which increases bpf_master_redirect_enabled_key. Another bond device (bond0) which is unsupported by XDP but its slave (veth3) has xdpgeneric that returns XDP_TX. This triggers WARN_ON_ONCE() from the xdp_master_redirect(). To reduce unnecessary warnings and improve log management, we need to delete the WARN_ON_ONCE() and add ratelimit to the netdev_err(). [1] Steps to reproduce: # Needs tx_xdp with return XDP_TX; ip l add veth0 type veth peer veth1 ip l add veth3 type veth peer veth4 ip l add bond0 type bond mode 6 # BOND_MODE_ALB, unsupported by XDP ip l add bond1 type bond # BOND_MODE_ROUNDROBIN by default ip l set veth0 master bond1 ip l set bond1 up # Increases bpf_master_redirect_enabled_key ip l set dev bond1 xdpdrv object tx_xdp.o section xdp_tx ip l set veth3 master bond0 ip l set bond0 up ip l set veth4 up # Triggers WARN_ON_ONCE() from the xdp_master_redirect() ip l set veth3 xdpgeneric object tx_xdp.o section xdp_tx(CVE-2024-47734)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: f2fs: Require FMODE_WRITE for atomic write ioctls The F2FS ioctls for starting and committing atomic writes check for inode_owner_or_capable(), but this does not give LSMs like SELinux or Landlock an opportunity to deny the write access - if the caller\u0026apos;s FSUID matches the inode\u0026apos;s UID, inode_owner_or_capable() immediately returns true. There are scenarios where LSMs want to deny a process the ability to write particular files, even files that the FSUID of the process owns; but this can currently partially be bypassed using atomic write ioctls in two ways: - F2FS_IOC_START_ATOMIC_REPLACE + F2FS_IOC_COMMIT_ATOMIC_WRITE can truncate an inode to size 0 - F2FS_IOC_START_ATOMIC_WRITE + F2FS_IOC_ABORT_ATOMIC_WRITE can revert changes another process concurrently made to a file Fix it by requiring FMODE_WRITE for these operations, just like for F2FS_IOC_MOVE_RANGE. Since any legitimate caller should only be using these ioctls when intending to write into the file, that seems unlikely to break anything.(CVE-2024-47740)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix Use-After-Free of rsv_qp on HIP08 Currently rsv_qp is freed before ib_unregister_device() is called on HIP08. During the time interval, users can still dereg MR and rsv_qp will be used in this process, leading to a UAF. Move the release of rsv_qp after calling ib_unregister_device() to fix it.(CVE-2024-47750)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: media: mediatek: vcodec: Fix H264 multi stateless decoder smatch warning Fix a smatch static checker warning on vdec_h264_req_multi_if.c. Which leads to a kernel crash when fb is NULL.(CVE-2024-47754)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: tpm: Clean up TPM space after command failure tpm_dev_transmit prepares the TPM space before attempting command transmission. However if the command fails no rollback of this preparation is done. This can result in transient handles being leaked if the device is subsequently closed with no further commands performed. Fix this by flushing the space in the event of command transmission failure.(CVE-2024-49851)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: bpf: Fix helper writes to read-only maps Lonial found an issue that despite user- and BPF-side frozen BPF map (like in case of .rodata), it was still possible to write into it from a BPF program side through specific helpers having ARG_PTR_TO_{LONG,INT} as arguments. In check_func_arg() when the argument is as mentioned, the meta-\u0026gt;raw_mode is never set. Later, check_helper_mem_access(), under the case of PTR_TO_MAP_VALUE as register base type, it assumes BPF_READ for the subsequent call to check_map_access_type() and given the BPF map is read-only it succeeds. The helpers really need to be annotated as ARG_PTR_TO_{LONG,INT} | MEM_UNINIT when results are written into them as opposed to read out of them. The latter indicates that it\u0026apos;s okay to pass a pointer to uninitialized memory as the memory is written to anyway. However, ARG_PTR_TO_{LONG,INT} is a special case of ARG_PTR_TO_FIXED_SIZE_MEM just with additional alignment requirement. So it is better to just get rid of the ARG_PTR_TO_{LONG,INT} special cases altogether and reuse the fixed size memory types. For this, add MEM_ALIGNED to additionally ensure alignment given these helpers write directly into the args via *\u0026lt;ptr\u0026gt; = val. The .arg*_size has been initialized reflecting the actual sizeof(*\u0026lt;ptr\u0026gt;). MEM_ALIGNED can only be used in combination with MEM_FIXED_SIZE annotated argument types, since in !MEM_FIXED_SIZE cases the verifier does not know the buffer size a priori and therefore cannot blindly write *\u0026lt;ptr\u0026gt; = val.(CVE-2024-49861)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: ensure the fw_info is not null before using it This resolves the dereference null return value warning reported by Coverity.(CVE-2024-49890)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Validate hdwq pointers before dereferencing in reset/errata paths When the HBA is undergoing a reset or is handling an errata event, NULL ptr dereference crashes may occur in routines such as lpfc_sli_flush_io_rings(), lpfc_dev_loss_tmo_callbk(), or lpfc_abort_handler(). Add NULL ptr checks before dereferencing hdwq pointers that may have been freed due to operations colliding with a reset or errata event handler.(CVE-2024-49891)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointers before using dc-\u0026gt;clk_mgr [WHY \u0026amp; HOW] dc-\u0026gt;clk_mgr is null checked previously in the same function, indicating it might be null. Passing \u0026quot;dc\u0026quot; to \u0026quot;dc-\u0026gt;hwss.apply_idle_power_optimizations\u0026quot;, which dereferences null \u0026quot;dc-\u0026gt;clk_mgr\u0026quot;. (The function pointer resolves to \u0026quot;dcn35_apply_idle_power_optimizations\u0026quot;.) This fixes 1 FORWARD_NULL issue reported by Coverity.(CVE-2024-49907)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: avoid NULL pointer dereference iwl_mvm_tx_skb_sta() and iwl_mvm_tx_mpdu() verify that the mvmvsta pointer is not NULL. It retrieves this pointer using iwl_mvm_sta_from_mac80211, which is dereferencing the ieee80211_sta pointer. If sta is NULL, iwl_mvm_sta_from_mac80211 will dereference a NULL pointer. Fix this by checking the sta pointer before retrieving the mvmsta from it. If sta is not NULL, then mvmsta isn\u0026apos;t either.(CVE-2024-49929)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: aoe: fix the potential use-after-free problem in more places For fixing CVE-2023-6270, f98364e92662 (\u0026quot;aoe: fix the potential use-after-free problem in aoecmd_cfg_pkts\u0026quot;) makes tx() calling dev_put() instead of doing in aoecmd_cfg_pkts(). It avoids that the tx() runs into use-after-free. Then Nicolai Stange found more places in aoe have potential use-after-free problem with tx(). e.g. revalidate(), aoecmd_ata_rw(), resend(), probe() and aoecmd_cfg_rsp(). Those functions also use aoenet_xmit() to push packet to tx queue. So they should also use dev_hold() to increase the refcnt of skb-\u0026gt;dev. On the other hand, moving dev_put() to tx() causes that the refcnt of skb-\u0026gt;dev be reduced to a negative value, because corresponding dev_hold() are not called in revalidate(), aoecmd_ata_rw(), resend(), probe(), and aoecmd_cfg_rsp(). This patch fixed this issue.(CVE-2024-49982)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix error path in multi-packet WQE transmit Remove the erroneous unmap in case no DMA mapping was established The multi-packet WQE transmit code attempts to obtain a DMA mapping for the skb. This could fail, e.g. under memory pressure, when the IOMMU driver just can\u0026apos;t allocate more memory for page tables. While the code tries to handle this in the path below the err_unmap label it erroneously unmaps one entry from the sq\u0026apos;s FIFO list of active mappings. Since the current map attempt failed this unmap is removing some random DMA mapping that might still be required. If the PCI function now presents that IOVA, the IOMMU may assumes a rogue DMA access and e.g. on s390 puts the PCI function in error state. The erroneous behavior was seen in a stress-test environment that created memory pressure.(CVE-2024-50001)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: exec: don\u0026apos;t WARN for racy path_noexec check Both i_mode and noexec checks wrapped in WARN_ON stem from an artifact of the previous implementation. They used to legitimately check for the condition, but that got moved up in two commits: 633fb6ac3980 (\u0026quot;exec: move S_ISREG() check earlier\u0026quot;) 0fd338b2d2cd (\u0026quot;exec: move path_noexec() check earlier\u0026quot;) Instead of being removed said checks are WARN_ON\u0026apos;ed instead, which has some debug value. However, the spurious path_noexec check is racy, resulting in unwarranted warnings should someone race with setting the noexec flag. One can note there is more to perm-checking whether execve is allowed and none of the conditions are guaranteed to still hold after they were tested for. Additionally this does not validate whether the code path did any perm checking to begin with -- it will pass if the inode happens to be regular. Keep the redundant path_noexec() check even though it\u0026apos;s mindless nonsense checking for guarantee that isn\u0026apos;t given so drop the WARN. Reword the commentary and do small tidy ups while here. [brauner: keep redundant path_noexec() check](CVE-2024-50010)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: net: phy: Remove LED entry from LEDs list on unregister Commit c938ab4da0eb (\u0026quot;net: phy: Manual remove LEDs to ensure correct ordering\u0026quot;) correctly fixed a problem with using devm_ but missed removing the LED entry from the LEDs list. This cause kernel panic on specific scenario where the port for the PHY is torn down and up and the kmod for the PHY is removed. On setting the port down the first time, the assosiacted LEDs are correctly unregistered. The associated kmod for the PHY is now removed. The kmod is now added again and the port is now put up, the associated LED are registered again. On putting the port down again for the second time after these step, the LED list now have 4 elements. With the first 2 already unregistered previously and the 2 new one registered again. This cause a kernel panic as the first 2 element should have been removed. Fix this by correctly removing the element when LED is unregistered.(CVE-2024-50023)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: FIX possible deadlock in rfcomm_sk_state_change rfcomm_sk_state_change attempts to use sock_lock so it must never be called with it locked but rfcomm_sock_ioctl always attempt to lock it causing the following trace: ====================================================== WARNING: possible circular locking dependency detected 6.8.0-syzkaller-08951-gfe46a7dd189e #0 Not tainted ------------------------------------------------------ syz-executor386/5093 is trying to acquire lock: ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1671 [inline] ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: rfcomm_sk_state_change+0x5b/0x310 net/bluetooth/rfcomm/sock.c:73 but task is already holding lock: ffff88807badfd28 (\u0026amp;d-\u0026gt;lock){+.+.}-{3:3}, at: __rfcomm_dlc_close+0x226/0x6a0 net/bluetooth/rfcomm/core.c:491(CVE-2024-50044)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: fbcon: Fix a NULL pointer dereference issue in fbcon_putcs syzbot has found a NULL pointer dereference bug in fbcon. Here is the simplified C reproducer: struct param { uint8_t type; struct tiocl_selection ts; }; int main() { struct fb_con2fbmap con2fb; struct param param; int fd = open(\u0026quot;/dev/fb1\u0026quot;, 0, 0); con2fb.console = 0x19; con2fb.framebuffer = 0; ioctl(fd, FBIOPUT_CON2FBMAP, \u0026amp;con2fb); param.type = 2; param.ts.xs = 0; param.ts.ys = 0; param.ts.xe = 0; param.ts.ye = 0; param.ts.sel_mode = 0; int fd1 = open(\u0026quot;/dev/tty1\u0026quot;, O_RDWR, 0); ioctl(fd1, TIOCLINUX, \u0026amp;param); con2fb.console = 1; con2fb.framebuffer = 0; ioctl(fd, FBIOPUT_CON2FBMAP, \u0026amp;con2fb); return 0; } After calling ioctl(fd1, TIOCLINUX, \u0026amp;param), the subsequent ioctl(fd, FBIOPUT_CON2FBMAP, \u0026amp;con2fb) causes the kernel to follow a different execution path: set_con2fb_map -\u0026gt; con2fb_init_display -\u0026gt; fbcon_set_disp -\u0026gt; redraw_screen -\u0026gt; hide_cursor -\u0026gt; clear_selection -\u0026gt; highlight -\u0026gt; invert_screen -\u0026gt; do_update_region -\u0026gt; fbcon_putcs -\u0026gt; ops-\u0026gt;putcs Since ops-\u0026gt;putcs is a NULL pointer, this leads to a kernel panic. To prevent this, we need to call set_blitting_type() within set_con2fb_map() to properly initialize ops-\u0026gt;putcs.(CVE-2024-50048)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: Bluetooth: Call iso_exit() on module unload If iso_init() has been called, iso_exit() must be called on module unload. Without that, the struct proto that iso_init() registered with proto_register() becomes invalid, which could cause unpredictable problems later. In my case, with CONFIG_LIST_HARDENED and CONFIG_BUG_ON_DATA_CORRUPTION enabled, loading the module again usually triggers this BUG(): list_add corruption. next-\u0026gt;prev should be prev (ffffffffb5355fd0), but was 0000000000000068. (next=ffffffffc0a010d0). ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:29! Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 4159 Comm: modprobe Not tainted 6.10.11-4+bt2-ao-desktop #1 RIP: 0010:__list_add_valid_or_report+0x61/0xa0 ... __list_add_valid_or_report+0x61/0xa0 proto_register+0x299/0x320 hci_sock_init+0x16/0xc0 [bluetooth] bt_init+0x68/0xd0 [bluetooth] __pfx_bt_init+0x10/0x10 [bluetooth] do_one_initcall+0x80/0x2f0 do_init_module+0x8b/0x230 __do_sys_init_module+0x15f/0x190 do_syscall_64+0x68/0x110 ...(CVE-2024-50078)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: ksmbd: fix user-after-free from session log off There is racy issue between smb2 session log off and smb2 session setup. It will cause user-after-free from session log off. This add session_lock when setting SMB2_SESSION_EXPIRED and referece count to session struct not to free session while it is being used.(CVE-2024-50086)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Fix incorrect pci_for_each_dma_alias() for non-PCI devices Previously, the domain_context_clear() function incorrectly called pci_for_each_dma_alias() to set up context entries for non-PCI devices. This could lead to kernel hangs or other unexpected behavior. Add a check to only call pci_for_each_dma_alias() for PCI devices. For non-PCI devices, domain_context_clear_one() is called directly.(CVE-2024-50101)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Disable PSR-SU on Parade 08-01 TCON too Stuart Hayhurst has found that both at bootup and fullscreen VA-API video is leading to black screens for around 1 second and kernel WARNING [1] traces when calling dmub_psr_enable() with Parade 08-01 TCON. These symptoms all go away with PSR-SU disabled for this TCON, so disable it for now while DMUB traces [2] from the failure can be analyzed and the failure state properly root caused. (cherry picked from commit afb634a6823d8d9db23c5fb04f79c5549349628b)(CVE-2024-50108)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: net: sched: use RCU read-side critical section in taprio_dump() Fix possible use-after-free in \u0026apos;taprio_dump()\u0026apos; by adding RCU read-side critical section there. Never seen on x86 but found on a KASAN-enabled arm64 system when investigating https://syzkaller.appspot.com/bug?extid=b65e0af58423fc8a73aa: [T15862] BUG: KASAN: slab-use-after-free in taprio_dump+0xa0c/0xbb0 [T15862] Read of size 4 at addr ffff0000d4bb88f8 by task repro/15862 [T15862] [T15862] CPU: 0 UID: 0 PID: 15862 Comm: repro Not tainted 6.11.0-rc1-00293-gdefaf1a2113a-dirty #2 [T15862] Hardware name: QEMU QEMU Virtual Machine, BIOS edk2-20240524-5.fc40 05/24/2024 [T15862] Call trace: [T15862] dump_backtrace+0x20c/0x220 [T15862] show_stack+0x2c/0x40 [T15862] dump_stack_lvl+0xf8/0x174 [T15862] print_report+0x170/0x4d8 [T15862] kasan_report+0xb8/0x1d4 [T15862] __asan_report_load4_noabort+0x20/0x2c [T15862] taprio_dump+0xa0c/0xbb0 [T15862] tc_fill_qdisc+0x540/0x1020 [T15862] qdisc_notify.isra.0+0x330/0x3a0 [T15862] tc_modify_qdisc+0x7b8/0x1838 [T15862] rtnetlink_rcv_msg+0x3c8/0xc20 [T15862] netlink_rcv_skb+0x1f8/0x3d4 [T15862] rtnetlink_rcv+0x28/0x40 [T15862] netlink_unicast+0x51c/0x790 [T15862] netlink_sendmsg+0x79c/0xc20 [T15862] __sock_sendmsg+0xe0/0x1a0 [T15862] ____sys_sendmsg+0x6c0/0x840 [T15862] ___sys_sendmsg+0x1ac/0x1f0 [T15862] __sys_sendmsg+0x110/0x1d0 [T15862] __arm64_sys_sendmsg+0x74/0xb0 [T15862] invoke_syscall+0x88/0x2e0 [T15862] el0_svc_common.constprop.0+0xe4/0x2a0 [T15862] do_el0_svc+0x44/0x60 [T15862] el0_svc+0x50/0x184 [T15862] el0t_64_sync_handler+0x120/0x12c [T15862] el0t_64_sync+0x190/0x194 [T15862] [T15862] Allocated by task 15857: [T15862] kasan_save_stack+0x3c/0x70 [T15862] kasan_save_track+0x20/0x3c [T15862] kasan_save_alloc_info+0x40/0x60 [T15862] __kasan_kmalloc+0xd4/0xe0 [T15862] __kmalloc_cache_noprof+0x194/0x334 [T15862] taprio_change+0x45c/0x2fe0 [T15862] tc_modify_qdisc+0x6a8/0x1838 [T15862] rtnetlink_rcv_msg+0x3c8/0xc20 [T15862] netlink_rcv_skb+0x1f8/0x3d4 [T15862] rtnetlink_rcv+0x28/0x40 [T15862] netlink_unicast+0x51c/0x790 [T15862] netlink_sendmsg+0x79c/0xc20 [T15862] __sock_sendmsg+0xe0/0x1a0 [T15862] ____sys_sendmsg+0x6c0/0x840 [T15862] ___sys_sendmsg+0x1ac/0x1f0 [T15862] __sys_sendmsg+0x110/0x1d0 [T15862] __arm64_sys_sendmsg+0x74/0xb0 [T15862] invoke_syscall+0x88/0x2e0 [T15862] el0_svc_common.constprop.0+0xe4/0x2a0 [T15862] do_el0_svc+0x44/0x60 [T15862] el0_svc+0x50/0x184 [T15862] el0t_64_sync_handler+0x120/0x12c [T15862] el0t_64_sync+0x190/0x194 [T15862] [T15862] Freed by task 6192: [T15862] kasan_save_stack+0x3c/0x70 [T15862] kasan_save_track+0x20/0x3c [T15862] kasan_save_free_info+0x4c/0x80 [T15862] poison_slab_object+0x110/0x160 [T15862] __kasan_slab_free+0x3c/0x74 [T15862] kfree+0x134/0x3c0 [T15862] taprio_free_sched_cb+0x18c/0x220 [T15862] rcu_core+0x920/0x1b7c [T15862] rcu_core_si+0x10/0x1c [T15862] handle_softirqs+0x2e8/0xd64 [T15862] __do_softirq+0x14/0x20(CVE-2024-50126)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: net: sched: fix use-after-free in taprio_change() In \u0026apos;taprio_change()\u0026apos;, \u0026apos;admin\u0026apos; pointer may become dangling due to sched switch / removal caused by \u0026apos;advance_sched()\u0026apos;, and critical section protected by \u0026apos;q-\u0026gt;current_entry_lock\u0026apos; is too small to prevent from such a scenario (which causes use-after-free detected by KASAN). Fix this by prefer \u0026apos;rcu_replace_pointer()\u0026apos; over \u0026apos;rcu_assign_pointer()\u0026apos; to update \u0026apos;admin\u0026apos; immediately before an attempt to schedule freeing.(CVE-2024-50127)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: net: wwan: fix global oob in wwan_rtnl_policy The variable wwan_rtnl_link_ops assign a *bigger* maxtype which leads to a global out-of-bounds read when parsing the netlink attributes. Exactly same bug cause as the oob fixed in commit b33fb5b801c6 (\u0026quot;net: qualcomm: rmnet: fix global oob in rmnet_policy\u0026quot;). ================================================================== BUG: KASAN: global-out-of-bounds in validate_nla lib/nlattr.c:388 [inline] BUG: KASAN: global-out-of-bounds in __nla_validate_parse+0x19d7/0x29a0 lib/nlattr.c:603 Read of size 1 at addr ffffffff8b09cb60 by task syz.1.66276/323862 CPU: 0 PID: 323862 Comm: syz.1.66276 Not tainted 6.1.70 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Call Trace: \u0026lt;TASK\u0026gt; __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x177/0x231 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:284 [inline] print_report+0x14f/0x750 mm/kasan/report.c:395 kasan_report+0x139/0x170 mm/kasan/report.c:495 validate_nla lib/nlattr.c:388 [inline] __nla_validate_parse+0x19d7/0x29a0 lib/nlattr.c:603 __nla_parse+0x3c/0x50 lib/nlattr.c:700 nla_parse_nested_deprecated include/net/netlink.h:1269 [inline] __rtnl_newlink net/core/rtnetlink.c:3514 [inline] rtnl_newlink+0x7bc/0x1fd0 net/core/rtnetlink.c:3623 rtnetlink_rcv_msg+0x794/0xef0 net/core/rtnetlink.c:6122 netlink_rcv_skb+0x1de/0x420 net/netlink/af_netlink.c:2508 netlink_unicast_kernel net/netlink/af_netlink.c:1326 [inline] netlink_unicast+0x74b/0x8c0 net/netlink/af_netlink.c:1352 netlink_sendmsg+0x882/0xb90 net/netlink/af_netlink.c:1874 sock_sendmsg_nosec net/socket.c:716 [inline] __sock_sendmsg net/socket.c:728 [inline] ____sys_sendmsg+0x5cc/0x8f0 net/socket.c:2499 ___sys_sendmsg+0x21c/0x290 net/socket.c:2553 __sys_sendmsg net/socket.c:2582 [inline] __do_sys_sendmsg net/socket.c:2591 [inline] __se_sys_sendmsg+0x19e/0x270 net/socket.c:2589 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x45/0x90 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f67b19a24ad RSP: 002b:00007f67b17febb8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f67b1b45f80 RCX: 00007f67b19a24ad RDX: 0000000000000000 RSI: 0000000020005e40 RDI: 0000000000000004 RBP: 00007f67b1a1e01d R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007ffd2513764f R14: 00007ffd251376e0 R15: 00007f67b17fed40 \u0026lt;/TASK\u0026gt; The buggy address belongs to the variable: wwan_rtnl_policy+0x20/0x40 The buggy address belongs to the physical page: page:ffffea00002c2700 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0xb09c flags: 0xfff00000001000(reserved|node=0|zone=1|lastcpupid=0x7ff) raw: 00fff00000001000 ffffea00002c2708 ffffea00002c2708 0000000000000000 raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected page_owner info is not present (never set?) Memory state around the buggy address: ffffffff8b09ca00: 05 f9 f9 f9 05 f9 f9 f9 00 01 f9 f9 00 01 f9 f9 ffffffff8b09ca80: 00 00 00 05 f9 f9 f9 f9 00 00 03 f9 f9 f9 f9 f9 \u0026gt;ffffffff8b09cb00: 00 00 00 00 05 f9 f9 f9 00 00 00 00 f9 f9 f9 f9 ^ ffffffff8b09cb80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ================================================================== According to the comment of `nla_parse_nested_deprecated`, use correct size `IFLA_WWAN_MAX` here to fix this issue.(CVE-2024-50128)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: netfilter: bpf: must hold reference on net namespace BUG: KASAN: slab-use-after-free in __nf_unregister_net_hook+0x640/0x6b0 Read of size 8 at addr ffff8880106fe400 by task repro/72= bpf_nf_link_release+0xda/0x1e0 bpf_link_free+0x139/0x2d0 bpf_link_release+0x68/0x80 __fput+0x414/0xb60 Eric says: It seems that bpf was able to defer the __nf_unregister_net_hook() after exit()/close() time. Perhaps a netns reference is missing, because the netns has been dismantled/freed already. bpf_nf_link_attach() does : link-\u0026gt;net = net; But I do not see a reference being taken on net. Add such a reference and release it after hook unreg. Note that I was unable to get syzbot reproducer to work, so I do not know if this resolves this splat.(CVE-2024-50130)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: nvme-pci: fix race condition between reset and nvme_dev_disable() nvme_dev_disable() modifies the dev-\u0026gt;online_queues field, therefore nvme_pci_update_nr_queues() should avoid racing against it, otherwise we could end up passing invalid values to blk_mq_update_nr_hw_queues(). WARNING: CPU: 39 PID: 61303 at drivers/pci/msi/api.c:347 pci_irq_get_affinity+0x187/0x210 Workqueue: nvme-reset-wq nvme_reset_work [nvme] RIP: 0010:pci_irq_get_affinity+0x187/0x210 Call Trace: \u0026lt;TASK\u0026gt; ? blk_mq_pci_map_queues+0x87/0x3c0 ? pci_irq_get_affinity+0x187/0x210 blk_mq_pci_map_queues+0x87/0x3c0 nvme_pci_map_queues+0x189/0x460 [nvme] blk_mq_update_nr_hw_queues+0x2a/0x40 nvme_reset_work+0x1be/0x2a0 [nvme] Fix the bug by locking the shutdown_lock mutex before using dev-\u0026gt;online_queues. Give up if nvme_dev_disable() is running or if it has been executed already.(CVE-2024-50135)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: reset: starfive: jh71x0: Fix accessing the empty member on JH7110 SoC data-\u0026gt;asserted will be NULL on JH7110 SoC since commit 82327b127d41 (\u0026quot;reset: starfive: Add StarFive JH7110 reset driver\u0026quot;) was added. Add the judgment condition to avoid errors when calling reset_control_status on JH7110 SoC.(CVE-2024-50137)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Fix shift-out-of-bounds bug Fix a shift-out-of-bounds bug reported by UBSAN when running VM with MTE enabled host kernel. UBSAN: shift-out-of-bounds in arch/arm64/kvm/sys_regs.c:1988:14 shift exponent 33 is too large for 32-bit type \u0026apos;int\u0026apos; CPU: 26 UID: 0 PID: 7629 Comm: qemu-kvm Not tainted 6.12.0-rc2 #34 Hardware name: IEI NF5280R7/Mitchell MB, BIOS 00.00. 2024-10-12 09:28:54 10/14/2024 Call trace: dump_backtrace+0xa0/0x128 show_stack+0x20/0x38 dump_stack_lvl+0x74/0x90 dump_stack+0x18/0x28 __ubsan_handle_shift_out_of_bounds+0xf8/0x1e0 reset_clidr+0x10c/0x1c8 kvm_reset_sys_regs+0x50/0x1c8 kvm_reset_vcpu+0xec/0x2b0 __kvm_vcpu_set_target+0x84/0x158 kvm_vcpu_set_target+0x138/0x168 kvm_arch_vcpu_ioctl_vcpu_init+0x40/0x2b0 kvm_arch_vcpu_ioctl+0x28c/0x4b8 kvm_vcpu_ioctl+0x4bc/0x7a8 __arm64_sys_ioctl+0xb4/0x100 invoke_syscall+0x70/0x100 el0_svc_common.constprop.0+0x48/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x3c/0x158 el0t_64_sync_handler+0x120/0x130 el0t_64_sync+0x194/0x198(CVE-2024-50139)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: usb: typec: altmode should keep reference to parent The altmode device release refers to its parent device, but without keeping a reference to it. When registering the altmode, get a reference to the parent and put it in the release function. Before this fix, when using CONFIG_DEBUG_KOBJECT_RELEASE, we see issues like this: [ 43.572860] kobject: \u0026apos;port0.0\u0026apos; (ffff8880057ba008): kobject_release, parent 0000000000000000 (delayed 3000) [ 43.573532] kobject: \u0026apos;port0.1\u0026apos; (ffff8880057bd008): kobject_release, parent 0000000000000000 (delayed 1000) [ 43.574407] kobject: \u0026apos;port0\u0026apos; (ffff8880057b9008): kobject_release, parent 0000000000000000 (delayed 3000) [ 43.575059] kobject: \u0026apos;port1.0\u0026apos; (ffff8880057ca008): kobject_release, parent 0000000000000000 (delayed 4000) [ 43.575908] kobject: \u0026apos;port1.1\u0026apos; (ffff8880057c9008): kobject_release, parent 0000000000000000 (delayed 4000) [ 43.576908] kobject: \u0026apos;typec\u0026apos; (ffff8880062dbc00): kobject_release, parent 0000000000000000 (delayed 4000) [ 43.577769] kobject: \u0026apos;port1\u0026apos; (ffff8880057bf008): kobject_release, parent 0000000000000000 (delayed 3000) [ 46.612867] ================================================================== [ 46.613402] BUG: KASAN: slab-use-after-free in typec_altmode_release+0x38/0x129 [ 46.614003] Read of size 8 at addr ffff8880057b9118 by task kworker/2:1/48 [ 46.614538] [ 46.614668] CPU: 2 UID: 0 PID: 48 Comm: kworker/2:1 Not tainted 6.12.0-rc1-00138-gedbae730ad31 #535 [ 46.615391] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 [ 46.616042] Workqueue: events kobject_delayed_cleanup [ 46.616446] Call Trace: [ 46.616648] \u0026lt;TASK\u0026gt; [ 46.616820] dump_stack_lvl+0x5b/0x7c [ 46.617112] ? typec_altmode_release+0x38/0x129 [ 46.617470] print_report+0x14c/0x49e [ 46.617769] ? rcu_read_unlock_sched+0x56/0x69 [ 46.618117] ? __virt_addr_valid+0x19a/0x1ab [ 46.618456] ? kmem_cache_debug_flags+0xc/0x1d [ 46.618807] ? typec_altmode_release+0x38/0x129 [ 46.619161] kasan_report+0x8d/0xb4 [ 46.619447] ? typec_altmode_release+0x38/0x129 [ 46.619809] ? process_scheduled_works+0x3cb/0x85f [ 46.620185] typec_altmode_release+0x38/0x129 [ 46.620537] ? process_scheduled_works+0x3cb/0x85f [ 46.620907] device_release+0xaf/0xf2 [ 46.621206] kobject_delayed_cleanup+0x13b/0x17a [ 46.621584] process_scheduled_works+0x4f6/0x85f [ 46.621955] ? __pfx_process_scheduled_works+0x10/0x10 [ 46.622353] ? hlock_class+0x31/0x9a [ 46.622647] ? lock_acquired+0x361/0x3c3 [ 46.622956] ? move_linked_works+0x46/0x7d [ 46.623277] worker_thread+0x1ce/0x291 [ 46.623582] ? __kthread_parkme+0xc8/0xdf [ 46.623900] ? __pfx_worker_thread+0x10/0x10 [ 46.624236] kthread+0x17e/0x190 [ 46.624501] ? kthread+0xfb/0x190 [ 46.624756] ? __pfx_kthread+0x10/0x10 [ 46.625015] ret_from_fork+0x20/0x40 [ 46.625268] ? __pfx_kthread+0x10/0x10 [ 46.625532] ret_from_fork_asm+0x1a/0x30 [ 46.625805] \u0026lt;/TASK\u0026gt; [ 46.625953] [ 46.626056] Allocated by task 678: [ 46.626287] kasan_save_stack+0x24/0x44 [ 46.626555] kasan_save_track+0x14/0x2d [ 46.626811] __kasan_kmalloc+0x3f/0x4d [ 46.627049] __kmalloc_noprof+0x1bf/0x1f0 [ 46.627362] typec_register_port+0x23/0x491 [ 46.627698] cros_typec_probe+0x634/0xbb6 [ 46.628026] platform_probe+0x47/0x8c [ 46.628311] really_probe+0x20a/0x47d [ 46.628605] device_driver_attach+0x39/0x72 [ 46.628940] bind_store+0x87/0xd7 [ 46.629213] kernfs_fop_write_iter+0x1aa/0x218 [ 46.629574] vfs_write+0x1d6/0x29b [ 46.629856] ksys_write+0xcd/0x13b [ 46.630128] do_syscall_64+0xd4/0x139 [ 46.630420] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 46.630820] [ 46.630946] Freed by task 48: [ 46.631182] kasan_save_stack+0x24/0x44 [ 46.631493] kasan_save_track+0x14/0x2d [ 46.631799] kasan_save_free_info+0x3f/0x4d [ 46.632144] __kasan_slab_free+0x37/0x45 [ 46.632474] ---truncated---(CVE-2024-50150)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: netdevsim: use cond_resched() in nsim_dev_trap_report_work() I am still seeing many syzbot reports hinting that syzbot might fool nsim_dev_trap_report_work() with hundreds of ports [1] Lets use cond_resched(), and system_unbound_wq instead of implicit system_wq. [1] INFO: task syz-executor:20633 blocked for more than 143 seconds. Not tainted 6.12.0-rc2-syzkaller-00205-g1d227fcc7222 #0 \u0026quot;echo 0 \u0026gt; /proc/sys/kernel/hung_task_timeout_secs\u0026quot; disables this message. task:syz-executor state:D stack:25856 pid:20633 tgid:20633 ppid:1 flags:0x00004006 ... NMI backtrace for cpu 1 CPU: 1 UID: 0 PID: 16760 Comm: kworker/1:0 Not tainted 6.12.0-rc2-syzkaller-00205-g1d227fcc7222 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Workqueue: events nsim_dev_trap_report_work RIP: 0010:__sanitizer_cov_trace_pc+0x0/0x70 kernel/kcov.c:210 Code: 89 fb e8 23 00 00 00 48 8b 3d 04 fb 9c 0c 48 89 de 5b e9 c3 c7 5d 00 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 \u0026lt;f3\u0026gt; 0f 1e fa 48 8b 04 24 65 48 8b 0c 25 c0 d7 03 00 65 8b 15 60 f0 RSP: 0018:ffffc90000a187e8 EFLAGS: 00000246 RAX: 0000000000000100 RBX: ffffc90000a188e0 RCX: ffff888027d3bc00 RDX: ffff888027d3bc00 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffff88804a2e6000 R08: ffffffff8a4bc495 R09: ffffffff89da3577 R10: 0000000000000004 R11: ffffffff8a4bc2b0 R12: dffffc0000000000 R13: ffff88806573b503 R14: dffffc0000000000 R15: ffff8880663cca00 FS: 0000000000000000(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fc90a747f98 CR3: 000000000e734000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 000000000000002b DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Call Trace: \u0026lt;NMI\u0026gt; \u0026lt;/NMI\u0026gt; \u0026lt;TASK\u0026gt; __local_bh_enable_ip+0x1bb/0x200 kernel/softirq.c:382 spin_unlock_bh include/linux/spinlock.h:396 [inline] nsim_dev_trap_report drivers/net/netdevsim/dev.c:820 [inline] nsim_dev_trap_report_work+0x75d/0xaa0 drivers/net/netdevsim/dev.c:850 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa63/0x1850 kernel/workqueue.c:3310 worker_thread+0x870/0xd30 kernel/workqueue.c:3391 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 \u0026lt;/TASK\u0026gt;(CVE-2024-50155)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Fix out of bound check Driver exports pacing stats only on GenP5 and P7 adapters. But while parsing the pacing stats, driver has a check for \u0026quot;rdev-\u0026gt;dbr_pacing\u0026quot;. This caused a trace when KASAN is enabled. BUG: KASAN: slab-out-of-bounds in bnxt_re_get_hw_stats+0x2b6a/0x2e00 [bnxt_re] Write of size 8 at addr ffff8885942a6340 by task modprobe/4809(CVE-2024-50158)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: bpf: Make sure internal and UAPI bpf_redirect flags don\u0026apos;t overlap The bpf_redirect_info is shared between the SKB and XDP redirect paths, and the two paths use the same numeric flag values in the ri-\u0026gt;flags field (specifically, BPF_F_BROADCAST == BPF_F_NEXTHOP). This means that if skb bpf_redirect_neigh() is used with a non-NULL params argument and, subsequently, an XDP redirect is performed using the same bpf_redirect_info struct, the XDP path will get confused and end up crashing, which syzbot managed to trigger. With the stack-allocated bpf_redirect_info, the structure is no longer shared between the SKB and XDP paths, so the crash doesn\u0026apos;t happen anymore. However, different code paths using identically-numbered flag values in the same struct field still seems like a bit of a mess, so this patch cleans that up by moving the flag definitions together and redefining the three flags in BPF_F_REDIRECT_INTERNAL to not overlap with the flags used for XDP. It also adds a BUILD_BUG_ON() check to make sure the overlap is not re-introduced by mistake.(CVE-2024-50163)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: bpf: Fix overloading of MEM_UNINIT\u0026apos;s meaning Lonial reported an issue in the BPF verifier where check_mem_size_reg() has the following code: if (!tnum_is_const(reg-\u0026gt;var_off)) /* For unprivileged variable accesses, disable raw * mode so that the program is required to * initialize all the memory that the helper could * just partially fill up. */ meta = NULL; This means that writes are not checked when the register containing the size of the passed buffer has not a fixed size. Through this bug, a BPF program can write to a map which is marked as read-only, for example, .rodata global maps. The problem is that MEM_UNINIT\u0026apos;s initial meaning that \u0026quot;the passed buffer to the BPF helper does not need to be initialized\u0026quot; which was added back in commit 435faee1aae9 (\u0026quot;bpf, verifier: add ARG_PTR_TO_RAW_STACK type\u0026quot;) got overloaded over time with \u0026quot;the passed buffer is being written to\u0026quot;. The problem however is that checks such as the above which were added later via 06c1c049721a (\u0026quot;bpf: allow helpers access to variable memory\u0026quot;) set meta to NULL in order force the user to always initialize the passed buffer to the helper. Due to the current double meaning of MEM_UNINIT, this bypasses verifier write checks to the memory (not boundary checks though) and only assumes the latter memory is read instead. Fix this by reverting MEM_UNINIT back to its original meaning, and having MEM_WRITE as an annotation to BPF helpers in order to then trigger the BPF verifier checks for writing to memory. Some notes: check_arg_pair_ok() ensures that for ARG_CONST_SIZE{,_OR_ZERO} we can access fn-\u0026gt;arg_type[arg - 1] since it must contain a preceding ARG_PTR_TO_MEM. For check_mem_reg() the meta argument can be removed altogether since we do check both BPF_READ and BPF_WRITE. Same for the equivalent check_kfunc_mem_size_reg().(CVE-2024-50164)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: drm/vc4: Stop the active perfmon before being destroyed Upon closing the file descriptor, the active performance monitor is not stopped. Although all perfmons are destroyed in `vc4_perfmon_close_file()`, the active performance monitor\u0026apos;s pointer (`vc4-\u0026gt;active_perfmon`) is still retained. If we open a new file descriptor and submit a few jobs with performance monitors, the driver will attempt to stop the active performance monitor using the stale pointer in `vc4-\u0026gt;active_perfmon`. However, this pointer is no longer valid because the previous process has already terminated, and all performance monitors associated with it have been destroyed and freed. To fix this, when the active performance monitor belongs to a given process, explicitly stop it before destroying and freeing it.(CVE-2024-50187)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: net: phy: dp83869: fix memory corruption when enabling fiber When configuring the fiber port, the DP83869 PHY driver incorrectly calls linkmode_set_bit() with a bit mask (1 \u0026lt;\u0026lt; 10) rather than a bit number (10). This corrupts some other memory location -- in case of arm64 the priv pointer in the same structure. Since the advertising flags are updated from supported at the end of the function the incorrect line isn\u0026apos;t needed at all and can be removed.(CVE-2024-50188)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: pinctrl: ocelot: fix system hang on level based interrupts The current implementation only calls chained_irq_enter() and chained_irq_exit() if it detects pending interrupts. ``` for (i = 0; i \u0026lt; info-\u0026gt;stride; i++) { uregmap_read(info-\u0026gt;map, id_reg + 4 * i, \u0026amp;reg); if (!reg) continue; chained_irq_enter(parent_chip, desc); ``` However, in case of GPIO pin configured in level mode and the parent controller configured in edge mode, GPIO interrupt might be lowered by the hardware. In the result, if the interrupt is short enough, the parent interrupt is still pending while the GPIO interrupt is cleared; chained_irq_enter() never gets called and the system hangs trying to service the parent interrupt. Moving chained_irq_enter() and chained_irq_exit() outside the for loop ensures that they are called even when GPIO interrupt is lowered by the hardware. The similar code with chained_irq_enter() / chained_irq_exit() functions wrapping interrupt checking loop may be found in many other drivers: ``` grep -r -A 10 chained_irq_enter drivers/pinctrl ```(CVE-2024-50196)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: drm/radeon: Fix encoder-\u0026gt;possible_clones Include the encoder itself in its possible_clones bitmask. In the past nothing validated that drivers were populating possible_clones correctly, but that changed in commit 74d2aacbe840 (\u0026quot;drm: Validate encoder-\u0026gt;possible_clones\u0026quot;). Looks like radeon never got the memo and is still not following the rules 100% correctly. This results in some warnings during driver initialization: Bogus possible_clones: [ENCODER:46:TV-46] possible_clones=0x4 (full encoder mask=0x7) WARNING: CPU: 0 PID: 170 at drivers/gpu/drm/drm_mode_config.c:615 drm_mode_config_validate+0x113/0x39c ... (cherry picked from commit 3b6e7d40649c0d75572039aff9d0911864c689db)(CVE-2024-50201)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: udf: refactor inode_bmap() to handle error Refactor inode_bmap() to handle error since udf_next_aext() can return error now. On situations like ftruncate, udf_extend_file() can now detect errors and bail out early without resorting to checking for particular offsets and assuming internal behavior of these functions.(CVE-2024-50211)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: ocfs2: pass u64 to ocfs2_truncate_inline maybe overflow Syzbot reported a kernel BUG in ocfs2_truncate_inline. There are two reasons for this: first, the parameter value passed is greater than ocfs2_max_inline_data_with_xattr, second, the start and end parameters of ocfs2_truncate_inline are \u0026quot;unsigned int\u0026quot;. So, we need to add a sanity check for byte_start and byte_len right before ocfs2_truncate_inline() in ocfs2_remove_inode_range(), if they are greater than ocfs2_max_inline_data_with_xattr return -EINVAL.(CVE-2024-50218)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: iov_iter: fix copy_page_from_iter_atomic() if KMAP_LOCAL_FORCE_MAP generic/077 on x86_32 CONFIG_DEBUG_KMAP_LOCAL_FORCE_MAP=y with highmem, on huge=always tmpfs, issues a warning and then hangs (interruptibly): WARNING: CPU: 5 PID: 3517 at mm/highmem.c:622 kunmap_local_indexed+0x62/0xc9 CPU: 5 UID: 0 PID: 3517 Comm: cp Not tainted 6.12.0-rc4 #2 ... copy_page_from_iter_atomic+0xa6/0x5ec generic_perform_write+0xf6/0x1b4 shmem_file_write_iter+0x54/0x67 Fix copy_page_from_iter_atomic() by limiting it in that case (include/linux/skbuff.h skb_frag_must_loop() does similar). But going forward, perhaps CONFIG_DEBUG_KMAP_LOCAL_FORCE_MAP is too surprising, has outlived its usefulness, and should just be removed?(CVE-2024-50222)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: cxl/port: Fix use-after-free, permit out-of-order decoder shutdown In support of investigating an initialization failure report [1], cxl_test was updated to register mock memory-devices after the mock root-port/bus device had been registered. That led to cxl_test crashing with a use-after-free bug with the following signature: cxl_port_attach_region: cxl region3: cxl_host_bridge.0:port3 decoder3.0 add: mem0:decoder7.0 @ 0 next: cxl_switch_uport.0 nr_eps: 1 nr_targets: 1 cxl_port_attach_region: cxl region3: cxl_host_bridge.0:port3 decoder3.0 add: mem4:decoder14.0 @ 1 next: cxl_switch_uport.0 nr_eps: 2 nr_targets: 1 cxl_port_setup_targets: cxl region3: cxl_switch_uport.0:port6 target[0] = cxl_switch_dport.0 for mem0:decoder7.0 @ 0 1) cxl_port_setup_targets: cxl region3: cxl_switch_uport.0:port6 target[1] = cxl_switch_dport.4 for mem4:decoder14.0 @ 1 [..] cxld_unregister: cxl decoder14.0: cxl_region_decode_reset: cxl_region region3: mock_decoder_reset: cxl_port port3: decoder3.0 reset 2) mock_decoder_reset: cxl_port port3: decoder3.0: out of order reset, expected decoder3.1 cxl_endpoint_decoder_release: cxl decoder14.0: [..] cxld_unregister: cxl decoder7.0: 3) cxl_region_decode_reset: cxl_region region3: Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6bc3: 0000 [#1] PREEMPT SMP PTI [..] RIP: 0010:to_cxl_port+0x8/0x60 [cxl_core] [..] Call Trace: \u0026lt;TASK\u0026gt; cxl_region_decode_reset+0x69/0x190 [cxl_core] cxl_region_detach+0xe8/0x210 [cxl_core] cxl_decoder_kill_region+0x27/0x40 [cxl_core] cxld_unregister+0x5d/0x60 [cxl_core] At 1) a region has been established with 2 endpoint decoders (7.0 and 14.0). Those endpoints share a common switch-decoder in the topology (3.0). At teardown, 2), decoder14.0 is the first to be removed and hits the \u0026quot;out of order reset case\u0026quot; in the switch decoder. The effect though is that region3 cleanup is aborted leaving it in-tact and referencing decoder14.0. At 3) the second attempt to teardown region3 trips over the stale decoder14.0 object which has long since been deleted. The fix here is to recognize that the CXL specification places no mandate on in-order shutdown of switch-decoders, the driver enforces in-order allocation, and hardware enforces in-order commit. So, rather than fail and leave objects dangling, always remove them. In support of making cxl_region_decode_reset() always succeed, cxl_region_invalidate_memregion() failures are turned into warnings. Crashing the kernel is ok there since system integrity is at risk if caches cannot be managed around physical address mutation events like CXL region destruction. A new device_for_each_child_reverse_from() is added to cleanup port-\u0026gt;commit_end after all dependent decoders have been disabled. In other words if decoders are allocated 0-\u0026gt;1-\u0026gt;2 and disabled 1-\u0026gt;2-\u0026gt;0 then port-\u0026gt;commit_end only decrements from 2 after 2 has been disabled, and it decrements all the way to zero since 1 was disabled previously.(CVE-2024-50226)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential deadlock with newly created symlinks Syzbot reported that page_symlink(), called by nilfs_symlink(), triggers memory reclamation involving the filesystem layer, which can result in circular lock dependencies among the reader/writer semaphore nilfs-\u0026gt;ns_segctor_sem, s_writers percpu_rwsem (intwrite) and the fs_reclaim pseudo lock. This is because after commit 21fc61c73c39 (\u0026quot;don\u0026apos;t put symlink bodies in pagecache into highmem\u0026quot;), the gfp flags of the page cache for symbolic links are overwritten to GFP_KERNEL via inode_nohighmem(). This is not a problem for symlinks read from the backing device, because the __GFP_FS flag is dropped after inode_nohighmem() is called. However, when a new symlink is created with nilfs_symlink(), the gfp flags remain overwritten to GFP_KERNEL. Then, memory allocation called from page_symlink() etc. triggers memory reclamation including the FS layer, which may call nilfs_evict_inode() or nilfs_dirty_inode(). And these can cause a deadlock if they are called while nilfs-\u0026gt;ns_segctor_sem is held: Fix this issue by dropping the __GFP_FS flag from the page cache GFP flags of newly created symlinks in the same way that nilfs_new_inode() and __nilfs_read_inode() do, as a workaround until we adopt nofs allocation scope consistently or improve the locking constraints.(CVE-2024-50229)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: clear wdev-\u0026gt;cqm_config pointer on free When we free wdev-\u0026gt;cqm_config when unregistering, we also need to clear out the pointer since the same wdev/netdev may get re-registered in another network namespace, then destroyed later, running this code again, which results in a double-free.(CVE-2024-50235)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: netdevsim: Add trailing zero to terminate the string in nsim_nexthop_bucket_activity_write() This was found by a static analyzer. We should not forget the trailing zero after copy_from_user() if we will further do some string operations, sscanf() in this case. Adding a trailing zero will ensure that the function performs properly.(CVE-2024-50259)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: macsec: Fix use-after-free while sending the offloading packet KASAN reports the following UAF. The metadata_dst, which is used to store the SCI value for macsec offload, is already freed by metadata_dst_free() in macsec_free_netdev(), while driver still use it for sending the packet. To fix this issue, dst_release() is used instead to release metadata_dst. So it is not freed instantly in macsec_free_netdev() if still referenced by skb. BUG: KASAN: slab-use-after-free in mlx5e_xmit+0x1e8f/0x4190 [mlx5_core] Read of size 2 at addr ffff88813e42e038 by task kworker/7:2/714 [...] Workqueue: mld mld_ifc_work Call Trace: \u0026lt;TASK\u0026gt; dump_stack_lvl+0x51/0x60 print_report+0xc1/0x600 kasan_report+0xab/0xe0 mlx5e_xmit+0x1e8f/0x4190 [mlx5_core] dev_hard_start_xmit+0x120/0x530 sch_direct_xmit+0x149/0x11e0 __qdisc_run+0x3ad/0x1730 __dev_queue_xmit+0x1196/0x2ed0 vlan_dev_hard_start_xmit+0x32e/0x510 [8021q] dev_hard_start_xmit+0x120/0x530 __dev_queue_xmit+0x14a7/0x2ed0 macsec_start_xmit+0x13e9/0x2340 dev_hard_start_xmit+0x120/0x530 __dev_queue_xmit+0x14a7/0x2ed0 ip6_finish_output2+0x923/0x1a70 ip6_finish_output+0x2d7/0x970 ip6_output+0x1ce/0x3a0 NF_HOOK.constprop.0+0x15f/0x190 mld_sendpack+0x59a/0xbd0 mld_ifc_work+0x48a/0xa80 process_one_work+0x5aa/0xe50 worker_thread+0x79c/0x1290 kthread+0x28f/0x350 ret_from_fork+0x2d/0x70 ret_from_fork_asm+0x11/0x20 \u0026lt;/TASK\u0026gt; Allocated by task 3922: kasan_save_stack+0x20/0x40 kasan_save_track+0x10/0x30 __kasan_kmalloc+0x77/0x90 __kmalloc_noprof+0x188/0x400 metadata_dst_alloc+0x1f/0x4e0 macsec_newlink+0x914/0x1410 __rtnl_newlink+0xe08/0x15b0 rtnl_newlink+0x5f/0x90 rtnetlink_rcv_msg+0x667/0xa80 netlink_rcv_skb+0x12c/0x360 netlink_unicast+0x551/0x770 netlink_sendmsg+0x72d/0xbd0 __sock_sendmsg+0xc5/0x190 ____sys_sendmsg+0x52e/0x6a0 ___sys_sendmsg+0xeb/0x170 __sys_sendmsg+0xb5/0x140 do_syscall_64+0x4c/0x100 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Freed by task 4011: kasan_save_stack+0x20/0x40 kasan_save_track+0x10/0x30 kasan_save_free_info+0x37/0x50 poison_slab_object+0x10c/0x190 __kasan_slab_free+0x11/0x30 kfree+0xe0/0x290 macsec_free_netdev+0x3f/0x140 netdev_run_todo+0x450/0xc70 rtnetlink_rcv_msg+0x66f/0xa80 netlink_rcv_skb+0x12c/0x360 netlink_unicast+0x551/0x770 netlink_sendmsg+0x72d/0xbd0 __sock_sendmsg+0xc5/0x190 ____sys_sendmsg+0x52e/0x6a0 ___sys_sendmsg+0xeb/0x170 __sys_sendmsg+0xb5/0x140 do_syscall_64+0x4c/0x100 entry_SYSCALL_64_after_hwframe+0x4b/0x53(CVE-2024-50261)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: vsock/virtio: Initialization of the dangling pointer occurring in vsk-\u0026gt;trans During loopback communication, a dangling pointer can be created in vsk-\u0026gt;trans, potentially leading to a Use-After-Free condition. This issue is resolved by initializing vsk-\u0026gt;trans to NULL.(CVE-2024-50264)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: dm cache: fix potential out-of-bounds access on the first resume Out-of-bounds access occurs if the fast device is expanded unexpectedly before the first-time resume of the cache table. This happens because expanding the fast device requires reloading the cache table for cache_create to allocate new in-core data structures that fit the new size, and the check in cache_preresume is not performed during the first resume, leading to the issue. Reproduce steps: 1. prepare component devices: dmsetup create cmeta --table \u0026quot;0 8192 linear /dev/sdc 0\u0026quot; dmsetup create cdata --table \u0026quot;0 65536 linear /dev/sdc 8192\u0026quot; dmsetup create corig --table \u0026quot;0 524288 linear /dev/sdc 262144\u0026quot; dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct 2. load a cache table of 512 cache blocks, and deliberately expand the fast device before resuming the cache, making the in-core data structures inadequate. dmsetup create cache --notable dmsetup reload cache --table \u0026quot;0 524288 cache /dev/mapper/cmeta \\ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\u0026quot; dmsetup reload cdata --table \u0026quot;0 131072 linear /dev/sdc 8192\u0026quot; dmsetup resume cdata dmsetup resume cache 3. suspend the cache to write out the in-core dirty bitset and hint array, leading to out-of-bounds access to the dirty bitset at offset 0x40: dmsetup suspend cache KASAN reports: BUG: KASAN: vmalloc-out-of-bounds in is_dirty_callback+0x2b/0x80 Read of size 8 at addr ffffc90000085040 by task dmsetup/90 (...snip...) The buggy address belongs to the virtual mapping at [ffffc90000085000, ffffc90000087000) created by: cache_ctr+0x176a/0x35f0 (...snip...) Memory state around the buggy address: ffffc90000084f00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90000084f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 \u0026gt;ffffc90000085000: 00 00 00 00 00 00 00 00 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc90000085080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90000085100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 Fix by checking the size change on the first resume.(CVE-2024-50278)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: add missing size check in amdgpu_debugfs_gprwave_read() Avoid a possible buffer overflow if size is larger than 4K. (cherry picked from commit f5d873f5825b40d886d03bd2aede91d4cf002434)(CVE-2024-50282)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: ksmbd: check outstanding simultaneous SMB operations If Client send simultaneous SMB operations to ksmbd, It exhausts too much memory through the \u0026quot;ksmbd_work_cache\u201d. It will cause OOM issue. ksmbd has a credit mechanism but it can\u0026apos;t handle this problem. This patch add the check if it exceeds max credits to prevent this problem by assuming that one smb request consumes at least one credit.(CVE-2024-50285)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: ksmbd: fix slab-use-after-free in ksmbd_smb2_session_create There is a race condition between ksmbd_smb2_session_create and ksmbd_expire_session. This patch add missing sessions_table_lock while adding/deleting session from global session table.(CVE-2024-50286)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: regulator: rtq2208: Fix uninitialized use of regulator_config Fix rtq2208 driver uninitialized use to cause kernel error.(CVE-2024-50300)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_init_flow() There are code paths from which the function is called without holding the RCU read lock, resulting in a suspicious RCU usage warning [1]. Fix by using l3mdev_master_upper_ifindex_by_index() which will acquire the RCU read lock before calling l3mdev_master_upper_ifindex_by_index_rcu(). [1] WARNING: suspicious RCU usage 6.12.0-rc3-custom-gac8f72681cf2 #141 Not tainted ----------------------------- net/core/dev.c:876 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by ip/361: #0: ffffffff86fc7cb0 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x377/0xf60 stack backtrace: CPU: 3 UID: 0 PID: 361 Comm: ip Not tainted 6.12.0-rc3-custom-gac8f72681cf2 #141 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: \u0026lt;TASK\u0026gt; dump_stack_lvl+0xba/0x110 lockdep_rcu_suspicious.cold+0x4f/0xd6 dev_get_by_index_rcu+0x1d3/0x210 l3mdev_master_upper_ifindex_by_index_rcu+0x2b/0xf0 ip_tunnel_bind_dev+0x72f/0xa00 ip_tunnel_newlink+0x368/0x7a0 ipgre_newlink+0x14c/0x170 __rtnl_newlink+0x1173/0x19c0 rtnl_newlink+0x6c/0xa0 rtnetlink_rcv_msg+0x3cc/0xf60 netlink_rcv_skb+0x171/0x450 netlink_unicast+0x539/0x7f0 netlink_sendmsg+0x8c1/0xd80 ____sys_sendmsg+0x8f9/0xc20 ___sys_sendmsg+0x197/0x1e0 __sys_sendmsg+0x122/0x1f0 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2024-53042)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: Fix response handling in iwl_mvm_send_recovery_cmd() 1. The size of the response packet is not validated. 2. The response buffer is not freed. Resolve these issues by switching to iwl_mvm_send_cmd_status(), which handles both size validation and frees the buffer.(CVE-2024-53059)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: prevent NULL pointer dereference if ATIF is not supported acpi_evaluate_object() may return AE_NOT_FOUND (failure), which would result in dereferencing buffer.pointer (obj) while being NULL. Although this case may be unrealistic for the current code, it is still better to protect against possible bugs. Bail out also when status is AE_NOT_FOUND. This fixes 1 FORWARD_NULL issue reported by Coverity Report: CID 1600951: Null pointer dereferences (FORWARD_NULL) (cherry picked from commit 91c9e221fe2553edf2db71627d8453f083de87a1)(CVE-2024-53060)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: NFSD: Never decrement pending_async_copies on error The error flow in nfsd4_copy() calls cleanup_async_copy(), which already decrements nn-\u0026gt;pending_async_copies.(CVE-2024-53073)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: afs: Fix lock recursion afs_wake_up_async_call() can incur lock recursion. The problem is that it is called from AF_RXRPC whilst holding the -\u0026gt;notify_lock, but it tries to take a ref on the afs_call struct in order to pass it to a work queue - but if the afs_call is already queued, we then have an extraneous ref that must be put... calling afs_put_call() may call back down into AF_RXRPC through rxrpc_kernel_shutdown_call(), however, which might try taking the -\u0026gt;notify_lock again. This case isn\u0026apos;t very common, however, so defer it to a workqueue. The oops looks something like: BUG: spinlock recursion on CPU#0, krxrpcio/7001/1646 lock: 0xffff888141399b30, .magic: dead4ead, .owner: krxrpcio/7001/1646, .owner_cpu: 0 CPU: 0 UID: 0 PID: 1646 Comm: krxrpcio/7001 Not tainted 6.12.0-rc2-build3+ #4351 Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014 Call Trace: \u0026lt;TASK\u0026gt; dump_stack_lvl+0x47/0x70 do_raw_spin_lock+0x3c/0x90 rxrpc_kernel_shutdown_call+0x83/0xb0 afs_put_call+0xd7/0x180 rxrpc_notify_socket+0xa0/0x190 rxrpc_input_split_jumbo+0x198/0x1d0 rxrpc_input_data+0x14b/0x1e0 ? rxrpc_input_call_packet+0xc2/0x1f0 rxrpc_input_call_event+0xad/0x6b0 rxrpc_input_packet_on_conn+0x1e1/0x210 rxrpc_input_packet+0x3f2/0x4d0 rxrpc_io_thread+0x243/0x410 ? __pfx_rxrpc_io_thread+0x10/0x10 kthread+0xcf/0xe0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x24/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 \u0026lt;/TASK\u0026gt;(CVE-2024-53090)",
"id": "OESA-2024-2522",
"modified": "2026-08-06T11:08:00Z",
"published": "2024-12-06T11:08:00Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2522"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39483"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44950"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45026"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46808"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46813"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46825"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47682"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47706"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47714"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47715"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47718"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47734"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47740"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47750"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47754"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49851"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49861"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49890"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49891"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49907"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49929"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49982"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50001"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50010"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50023"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50044"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50048"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50078"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50086"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50101"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50108"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50126"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50127"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50128"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50130"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50135"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50137"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50139"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50150"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50155"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50158"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50163"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50164"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50187"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50188"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50196"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50201"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50211"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50218"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50222"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50226"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50229"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50235"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50259"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50261"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50264"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50278"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50282"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50285"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50286"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50300"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53042"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53059"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53060"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53073"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53090"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2024-39483",
"CVE-2024-44950",
"CVE-2024-45026",
"CVE-2024-46808",
"CVE-2024-46813",
"CVE-2024-46825",
"CVE-2024-47682",
"CVE-2024-47706",
"CVE-2024-47714",
"CVE-2024-47715",
"CVE-2024-47718",
"CVE-2024-47734",
"CVE-2024-47740",
"CVE-2024-47750",
"CVE-2024-47754",
"CVE-2024-49851",
"CVE-2024-49861",
"CVE-2024-49890",
"CVE-2024-49891",
"CVE-2024-49907",
"CVE-2024-49929",
"CVE-2024-49982",
"CVE-2024-50001",
"CVE-2024-50010",
"CVE-2024-50023",
"CVE-2024-50044",
"CVE-2024-50048",
"CVE-2024-50078",
"CVE-2024-50086",
"CVE-2024-50101",
"CVE-2024-50108",
"CVE-2024-50126",
"CVE-2024-50127",
"CVE-2024-50128",
"CVE-2024-50130",
"CVE-2024-50135",
"CVE-2024-50137",
"CVE-2024-50139",
"CVE-2024-50150",
"CVE-2024-50155",
"CVE-2024-50158",
"CVE-2024-50163",
"CVE-2024-50164",
"CVE-2024-50187",
"CVE-2024-50188",
"CVE-2024-50196",
"CVE-2024-50201",
"CVE-2024-50211",
"CVE-2024-50218",
"CVE-2024-50222",
"CVE-2024-50226",
"CVE-2024-50229",
"CVE-2024-50235",
"CVE-2024-50259",
"CVE-2024-50261",
"CVE-2024-50264",
"CVE-2024-50278",
"CVE-2024-50282",
"CVE-2024-50285",
"CVE-2024-50286",
"CVE-2024-50300",
"CVE-2024-53042",
"CVE-2024-53059",
"CVE-2024-53060",
"CVE-2024-53073",
"CVE-2024-53090"
]
}
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.