Action not permitted
Modal body text goes here.
Modal Title
Modal Body
CVE-2023-52871 (GCVE-0-2023-52871)
Vulnerability from cvelistv5 – Published: 2024-05-21 15:32 – Updated: 2026-08-05 09:11| Vendor | Product | Version | CPE status | |
|---|---|---|---|---|
| Linux | Linux |
Affected:
a3134fb09e0bc5bee76e13bf863173b86f21cf87 , < cc1a1dcb411fe224f48553cfdcdfe6e61395b69c
(git)
Affected: a3134fb09e0bc5bee76e13bf863173b86f21cf87 , < 5e5b85ea0f4bc484bfe4cc73ead51fa48d2366a0 (git) Affected: a3134fb09e0bc5bee76e13bf863173b86f21cf87 , < 995ee1e84e8db7fa5dcdde7dfe0bd7bb6f9bbb8c (git) Affected: a3134fb09e0bc5bee76e13bf863173b86f21cf87 , < f0ef883cae309bc5e8cdfcdbc1b4822732ce20a8 (git) Affected: a3134fb09e0bc5bee76e13bf863173b86f21cf87 , < 3565684309e54fa998ea27f37028d67cc3e1dff2 (git) Affected: a3134fb09e0bc5bee76e13bf863173b86f21cf87 , < 1143bfb9b055897975aeaea254da148e19524493 (git) Affected: a3134fb09e0bc5bee76e13bf863173b86f21cf87 , < f1a1bc8775b26345aba2be278118999e7f661d3d (git) |
guessed | |
| Linux | Linux |
Affected:
4.19
Unaffected: 0 , < 4.19 (semver) Unaffected: 5.4.261 , ≤ 5.4.* (semver) Unaffected: 5.10.201 , ≤ 5.10.* (semver) Unaffected: 5.15.139 , ≤ 5.15.* (semver) Unaffected: 6.1.63 , ≤ 6.1.* (semver) Unaffected: 6.5.12 , ≤ 6.5.* (semver) Unaffected: 6.6.2 , ≤ 6.6.* (semver) Unaffected: 6.7 , ≤ * (original_commit_for_fix) |
guessed |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2023-52871",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2024-05-21T18:17:57.620656Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2024-06-04T17:22:42.515Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
},
{
"providerMetadata": {
"dateUpdated": "2024-08-02T23:11:36.044Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/cc1a1dcb411fe224f48553cfdcdfe6e61395b69c"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/5e5b85ea0f4bc484bfe4cc73ead51fa48d2366a0"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/995ee1e84e8db7fa5dcdde7dfe0bd7bb6f9bbb8c"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/f0ef883cae309bc5e8cdfcdbc1b4822732ce20a8"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/3565684309e54fa998ea27f37028d67cc3e1dff2"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/1143bfb9b055897975aeaea254da148e19524493"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/f1a1bc8775b26345aba2be278118999e7f661d3d"
}
],
"title": "CVE Program Container"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/soc/qcom/llcc-qcom.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "cc1a1dcb411fe224f48553cfdcdfe6e61395b69c",
"status": "affected",
"version": "a3134fb09e0bc5bee76e13bf863173b86f21cf87",
"versionType": "git"
},
{
"lessThan": "5e5b85ea0f4bc484bfe4cc73ead51fa48d2366a0",
"status": "affected",
"version": "a3134fb09e0bc5bee76e13bf863173b86f21cf87",
"versionType": "git"
},
{
"lessThan": "995ee1e84e8db7fa5dcdde7dfe0bd7bb6f9bbb8c",
"status": "affected",
"version": "a3134fb09e0bc5bee76e13bf863173b86f21cf87",
"versionType": "git"
},
{
"lessThan": "f0ef883cae309bc5e8cdfcdbc1b4822732ce20a8",
"status": "affected",
"version": "a3134fb09e0bc5bee76e13bf863173b86f21cf87",
"versionType": "git"
},
{
"lessThan": "3565684309e54fa998ea27f37028d67cc3e1dff2",
"status": "affected",
"version": "a3134fb09e0bc5bee76e13bf863173b86f21cf87",
"versionType": "git"
},
{
"lessThan": "1143bfb9b055897975aeaea254da148e19524493",
"status": "affected",
"version": "a3134fb09e0bc5bee76e13bf863173b86f21cf87",
"versionType": "git"
},
{
"lessThan": "f1a1bc8775b26345aba2be278118999e7f661d3d",
"status": "affected",
"version": "a3134fb09e0bc5bee76e13bf863173b86f21cf87",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/soc/qcom/llcc-qcom.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "4.19"
},
{
"lessThan": "4.19",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.261",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.201",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.139",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.63",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.5.*",
"status": "unaffected",
"version": "6.5.12",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.2",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.7",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.4.261",
"versionStartIncluding": "4.19",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.10.201",
"versionStartIncluding": "4.19",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.15.139",
"versionStartIncluding": "4.19",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.1.63",
"versionStartIncluding": "4.19",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.5.12",
"versionStartIncluding": "4.19",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6.2",
"versionStartIncluding": "4.19",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.7",
"versionStartIncluding": "4.19",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nsoc: qcom: llcc: Handle a second device without data corruption\n\nUsually there is only one llcc device. But if there were a second, even\na failed probe call would modify the global drv_data pointer. So check\nif drv_data is valid before overwriting it."
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 7.1,
"baseSeverity": "HIGH",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H",
"version": "3.1"
},
"scenarios": [
{
"lang": "en",
"value": "AV:L - The vulnerable code is qcom_llcc_probe in the Qualcomm LLCC platform driver, reached only via device-tree platform device probe or local sysfs driver bind\u2014not via network packets or remote protocols.\nAC:L - Once a second matching LLCC platform device is instantiated, probe unconditionally overwrites the global drv_data pointer and the failure path sets ERR_PTR(-ENODEV), so corruption is deterministic with no race or luck required.\nPR:L - Exploitation requires local ability to cause a second matching platform device to probe (crafted DT/overlay or driver bind on Qualcomm platforms); this is scored as low privileges under the higher-severity rule rather than requiring fully privileged root-only admin.\nUI:N - No victim interaction is needed; the corruption occurs entirely during kernel probe of the second device and can fault when existing in-kernel clients use LLCC.\nS:U - Impact stays within the host kernel\u2019s security authority (driver state and system-cache configuration); there is no VM escape, IOMMU bypass, or other cross-authority boundary crossing.\nC:N - The bug overwrites a global driver pointer and can cause crashes or wrong MMIO programming, but it does not provide an information-disclosure or memory-read primitive.\nI:H - A second probe reliably corrupts the global drv_data used for all LLCC operations and can reprogram system-cache slice configuration registers, which is high-integrity impact as described in the fix (\u201cdata corruption\u201d).\nA:H - While the global points at a zeroed allocation mid-probe, clients such as a6xx_llc_activate call llcc_slice_activate and dereference NULL bcast_regmap/bitmap, causing a kernel oops/panic."
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-08-05T09:11:45.186Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/cc1a1dcb411fe224f48553cfdcdfe6e61395b69c"
},
{
"url": "https://git.kernel.org/stable/c/5e5b85ea0f4bc484bfe4cc73ead51fa48d2366a0"
},
{
"url": "https://git.kernel.org/stable/c/995ee1e84e8db7fa5dcdde7dfe0bd7bb6f9bbb8c"
},
{
"url": "https://git.kernel.org/stable/c/f0ef883cae309bc5e8cdfcdbc1b4822732ce20a8"
},
{
"url": "https://git.kernel.org/stable/c/3565684309e54fa998ea27f37028d67cc3e1dff2"
},
{
"url": "https://git.kernel.org/stable/c/1143bfb9b055897975aeaea254da148e19524493"
},
{
"url": "https://git.kernel.org/stable/c/f1a1bc8775b26345aba2be278118999e7f661d3d"
}
],
"title": "soc: qcom: llcc: Handle a second device without data corruption",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2023-52871",
"datePublished": "2024-05-21T15:32:00.922Z",
"dateReserved": "2024-05-21T15:19:24.263Z",
"dateUpdated": "2026-08-05T09:11:45.186Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"epss": {
"cve": "CVE-2023-52871",
"date": "2026-09-23",
"epss": "0.00225",
"percentile": "0.13468"
},
"fkie_nvd": {
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nsoc: qcom: llcc: Handle a second device without data corruption\n\nUsually there is only one llcc device. But if there were a second, even\na failed probe call would modify the global drv_data pointer. So check\nif drv_data is valid before overwriting it."
},
{
"lang": "es",
"value": " En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: soc: qcom: llcc: Manejar un segundo dispositivo sin corrupci\u00f3n de datos. Generalmente solo hay un dispositivo llcc. Pero si hubiera un segundo, incluso una llamada de sonda fallida modificar\u00eda el puntero global drv_data. As\u00ed que verifique si drv_data es v\u00e1lido antes de sobrescribirlo."
}
],
"id": "CVE-2023-52871",
"lastModified": "2024-11-21T08:40:46.057",
"published": "2024-05-21T16:15:23.907",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/1143bfb9b055897975aeaea254da148e19524493"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/3565684309e54fa998ea27f37028d67cc3e1dff2"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/5e5b85ea0f4bc484bfe4cc73ead51fa48d2366a0"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/995ee1e84e8db7fa5dcdde7dfe0bd7bb6f9bbb8c"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/cc1a1dcb411fe224f48553cfdcdfe6e61395b69c"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/f0ef883cae309bc5e8cdfcdbc1b4822732ce20a8"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/f1a1bc8775b26345aba2be278118999e7f661d3d"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"url": "https://git.kernel.org/stable/c/1143bfb9b055897975aeaea254da148e19524493"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"url": "https://git.kernel.org/stable/c/3565684309e54fa998ea27f37028d67cc3e1dff2"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"url": "https://git.kernel.org/stable/c/5e5b85ea0f4bc484bfe4cc73ead51fa48d2366a0"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"url": "https://git.kernel.org/stable/c/995ee1e84e8db7fa5dcdde7dfe0bd7bb6f9bbb8c"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"url": "https://git.kernel.org/stable/c/cc1a1dcb411fe224f48553cfdcdfe6e61395b69c"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"url": "https://git.kernel.org/stable/c/f0ef883cae309bc5e8cdfcdbc1b4822732ce20a8"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"url": "https://git.kernel.org/stable/c/f1a1bc8775b26345aba2be278118999e7f661d3d"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Awaiting Analysis"
},
"nvd": {
"cve": {
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/soc/qcom/llcc-qcom.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "cc1a1dcb411fe224f48553cfdcdfe6e61395b69c",
"status": "affected",
"version": "a3134fb09e0bc5bee76e13bf863173b86f21cf87",
"versionType": "git"
},
{
"lessThan": "5e5b85ea0f4bc484bfe4cc73ead51fa48d2366a0",
"status": "affected",
"version": "a3134fb09e0bc5bee76e13bf863173b86f21cf87",
"versionType": "git"
},
{
"lessThan": "995ee1e84e8db7fa5dcdde7dfe0bd7bb6f9bbb8c",
"status": "affected",
"version": "a3134fb09e0bc5bee76e13bf863173b86f21cf87",
"versionType": "git"
},
{
"lessThan": "f0ef883cae309bc5e8cdfcdbc1b4822732ce20a8",
"status": "affected",
"version": "a3134fb09e0bc5bee76e13bf863173b86f21cf87",
"versionType": "git"
},
{
"lessThan": "3565684309e54fa998ea27f37028d67cc3e1dff2",
"status": "affected",
"version": "a3134fb09e0bc5bee76e13bf863173b86f21cf87",
"versionType": "git"
},
{
"lessThan": "1143bfb9b055897975aeaea254da148e19524493",
"status": "affected",
"version": "a3134fb09e0bc5bee76e13bf863173b86f21cf87",
"versionType": "git"
},
{
"lessThan": "f1a1bc8775b26345aba2be278118999e7f661d3d",
"status": "affected",
"version": "a3134fb09e0bc5bee76e13bf863173b86f21cf87",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/soc/qcom/llcc-qcom.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "4.19"
},
{
"lessThan": "4.19",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.261",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.201",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.139",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.63",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.5.*",
"status": "unaffected",
"version": "6.5.12",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.2",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.7",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"configurations": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "CAB15840-253A-4FDD-A8EF-F67CC80DB8B1",
"versionEndExcluding": "5.4.261",
"versionStartIncluding": "4.19",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "AF1ADC4E-CCC4-498A-876F-5136DDD36C1D",
"versionEndExcluding": "5.10.201",
"versionStartIncluding": "5.5",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "81424D14-B38F-47B3-A1B8-BC3B60BB96EA",
"versionEndExcluding": "5.15.139",
"versionStartIncluding": "5.11",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "80E1EA7E-2788-466C-9FFB-34AFA1B052F0",
"versionEndExcluding": "6.1.63",
"versionStartIncluding": "5.16",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "825F64D9-E99F-49AA-8A7B-EF7C2965C5B2",
"versionEndExcluding": "6.5.12",
"versionStartIncluding": "6.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "4CBFF885-A4D3-4F21-B6FD-4D770034C048",
"versionEndExcluding": "6.6.2",
"versionStartIncluding": "6.6",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nsoc: qcom: llcc: Handle a second device without data corruption\n\nUsually there is only one llcc device. But if there were a second, even\na failed probe call would modify the global drv_data pointer. So check\nif drv_data is valid before overwriting it."
},
{
"lang": "es",
"value": " En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: soc: qcom: llcc: Manejar un segundo dispositivo sin corrupci\u00f3n de datos. Generalmente solo hay un dispositivo llcc. Pero si hubiera un segundo, incluso una llamada de sonda fallida modificar\u00eda el puntero global drv_data. As\u00ed que verifique si drv_data es v\u00e1lido antes de sobrescribirlo."
}
],
"id": "CVE-2023-52871",
"lastModified": "2026-08-04T10:18:46.700",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 7.1,
"baseSeverity": "HIGH",
"confidentialityImpact": "NONE",
"integrityImpact": "HIGH",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 5.2,
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"type": "Secondary"
},
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "NONE",
"baseScore": 5.5,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "NONE",
"integrityImpact": "HIGH",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
"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-2023-52871",
"options": [
{
"exploitation": "none"
},
{
"automatable": "no"
},
{
"technicalImpact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2024-05-21T18:17:57.620656Z",
"version": "2.0.3"
}
}
]
},
"published": "2024-05-21T16:15:23.907",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/1143bfb9b055897975aeaea254da148e19524493"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/3565684309e54fa998ea27f37028d67cc3e1dff2"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/5e5b85ea0f4bc484bfe4cc73ead51fa48d2366a0"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/995ee1e84e8db7fa5dcdde7dfe0bd7bb6f9bbb8c"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/cc1a1dcb411fe224f48553cfdcdfe6e61395b69c"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/f0ef883cae309bc5e8cdfcdbc1b4822732ce20a8"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/f1a1bc8775b26345aba2be278118999e7f661d3d"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/1143bfb9b055897975aeaea254da148e19524493"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/3565684309e54fa998ea27f37028d67cc3e1dff2"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/5e5b85ea0f4bc484bfe4cc73ead51fa48d2366a0"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/995ee1e84e8db7fa5dcdde7dfe0bd7bb6f9bbb8c"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/cc1a1dcb411fe224f48553cfdcdfe6e61395b69c"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/f0ef883cae309bc5e8cdfcdbc1b4822732ce20a8"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/f1a1bc8775b26345aba2be278118999e7f661d3d"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Modified",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "NVD-CWE-noinfo"
}
],
"source": "nvd@nist.gov",
"type": "Primary"
}
]
}
},
"redhat_vex": {
"aggregate_severity": "Low",
"current_release_date": "2026-08-04T22:56:21+00:00",
"cve": "CVE-2023-52871",
"id": "CVE-2023-52871",
"initial_release_date": "2023-01-01T00:00:00+00:00",
"product_status:known_not_affected": "198",
"source": "Red Hat CSAF VEX",
"status": "final",
"title": "kernel: soc: qcom: llcc: Handle a second device without data corruption",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2023/cve-2023-52871.json",
"version": "3"
},
"suse_vex": {
"aggregate_severity": "important",
"current_release_date": "2026-09-03T00:31:54Z",
"cve": "CVE-2023-52871",
"id": "CVE-2023-52871",
"initial_release_date": "2024-05-29T02:36:36Z",
"product_status:known_affected": "269",
"product_status:known_not_affected": "164",
"product_status:recommended": "940",
"source": "SUSE CSAF VEX",
"status": "interim",
"title": "SUSE CVE CVE-2023-52871",
"url": "https://ftp.suse.com/pub/projects/security/csaf-vex/cve-2023-52871.json",
"version": "85"
},
"vulnrichment": {
"containers": {
"adp": [
{
"providerMetadata": {
"dateUpdated": "2024-08-02T23:11:36.044Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/cc1a1dcb411fe224f48553cfdcdfe6e61395b69c"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/5e5b85ea0f4bc484bfe4cc73ead51fa48d2366a0"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/995ee1e84e8db7fa5dcdde7dfe0bd7bb6f9bbb8c"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/f0ef883cae309bc5e8cdfcdbc1b4822732ce20a8"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/3565684309e54fa998ea27f37028d67cc3e1dff2"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/1143bfb9b055897975aeaea254da148e19524493"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/f1a1bc8775b26345aba2be278118999e7f661d3d"
}
],
"title": "CVE Program Container"
},
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2023-52871",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2024-05-21T18:17:57.620656Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2024-05-23T19:01:25.396Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/soc/qcom/llcc-qcom.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "cc1a1dcb411fe224f48553cfdcdfe6e61395b69c",
"status": "affected",
"version": "a3134fb09e0bc5bee76e13bf863173b86f21cf87",
"versionType": "git"
},
{
"lessThan": "5e5b85ea0f4bc484bfe4cc73ead51fa48d2366a0",
"status": "affected",
"version": "a3134fb09e0bc5bee76e13bf863173b86f21cf87",
"versionType": "git"
},
{
"lessThan": "995ee1e84e8db7fa5dcdde7dfe0bd7bb6f9bbb8c",
"status": "affected",
"version": "a3134fb09e0bc5bee76e13bf863173b86f21cf87",
"versionType": "git"
},
{
"lessThan": "f0ef883cae309bc5e8cdfcdbc1b4822732ce20a8",
"status": "affected",
"version": "a3134fb09e0bc5bee76e13bf863173b86f21cf87",
"versionType": "git"
},
{
"lessThan": "3565684309e54fa998ea27f37028d67cc3e1dff2",
"status": "affected",
"version": "a3134fb09e0bc5bee76e13bf863173b86f21cf87",
"versionType": "git"
},
{
"lessThan": "1143bfb9b055897975aeaea254da148e19524493",
"status": "affected",
"version": "a3134fb09e0bc5bee76e13bf863173b86f21cf87",
"versionType": "git"
},
{
"lessThan": "f1a1bc8775b26345aba2be278118999e7f661d3d",
"status": "affected",
"version": "a3134fb09e0bc5bee76e13bf863173b86f21cf87",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/soc/qcom/llcc-qcom.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "4.19"
},
{
"lessThan": "4.19",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.261",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.201",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.139",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.63",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.5.*",
"status": "unaffected",
"version": "6.5.12",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.2",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.7",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.4.261",
"versionStartIncluding": "4.19",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.10.201",
"versionStartIncluding": "4.19",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.15.139",
"versionStartIncluding": "4.19",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.1.63",
"versionStartIncluding": "4.19",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.5.12",
"versionStartIncluding": "4.19",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6.2",
"versionStartIncluding": "4.19",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.7",
"versionStartIncluding": "4.19",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nsoc: qcom: llcc: Handle a second device without data corruption\n\nUsually there is only one llcc device. But if there were a second, even\na failed probe call would modify the global drv_data pointer. So check\nif drv_data is valid before overwriting it."
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 7.1,
"baseSeverity": "HIGH",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H",
"version": "3.1"
},
"scenarios": [
{
"lang": "en",
"value": "AV:L - The vulnerable code is qcom_llcc_probe in the Qualcomm LLCC platform driver, reached only via device-tree platform device probe or local sysfs driver bind\u2014not via network packets or remote protocols.\nAC:L - Once a second matching LLCC platform device is instantiated, probe unconditionally overwrites the global drv_data pointer and the failure path sets ERR_PTR(-ENODEV), so corruption is deterministic with no race or luck required.\nPR:L - Exploitation requires local ability to cause a second matching platform device to probe (crafted DT/overlay or driver bind on Qualcomm platforms); this is scored as low privileges under the higher-severity rule rather than requiring fully privileged root-only admin.\nUI:N - No victim interaction is needed; the corruption occurs entirely during kernel probe of the second device and can fault when existing in-kernel clients use LLCC.\nS:U - Impact stays within the host kernel\u2019s security authority (driver state and system-cache configuration); there is no VM escape, IOMMU bypass, or other cross-authority boundary crossing.\nC:N - The bug overwrites a global driver pointer and can cause crashes or wrong MMIO programming, but it does not provide an information-disclosure or memory-read primitive.\nI:H - A second probe reliably corrupts the global drv_data used for all LLCC operations and can reprogram system-cache slice configuration registers, which is high-integrity impact as described in the fix (\u201cdata corruption\u201d).\nA:H - While the global points at a zeroed allocation mid-probe, clients such as a6xx_llc_activate call llcc_slice_activate and dereference NULL bcast_regmap/bitmap, causing a kernel oops/panic."
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-08-05T09:11:45.186Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/cc1a1dcb411fe224f48553cfdcdfe6e61395b69c"
},
{
"url": "https://git.kernel.org/stable/c/5e5b85ea0f4bc484bfe4cc73ead51fa48d2366a0"
},
{
"url": "https://git.kernel.org/stable/c/995ee1e84e8db7fa5dcdde7dfe0bd7bb6f9bbb8c"
},
{
"url": "https://git.kernel.org/stable/c/f0ef883cae309bc5e8cdfcdbc1b4822732ce20a8"
},
{
"url": "https://git.kernel.org/stable/c/3565684309e54fa998ea27f37028d67cc3e1dff2"
},
{
"url": "https://git.kernel.org/stable/c/1143bfb9b055897975aeaea254da148e19524493"
},
{
"url": "https://git.kernel.org/stable/c/f1a1bc8775b26345aba2be278118999e7f661d3d"
}
],
"title": "soc: qcom: llcc: Handle a second device without data corruption",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2023-52871",
"datePublished": "2024-05-21T15:32:00.922Z",
"dateReserved": "2024-05-21T15:19:24.263Z",
"dateUpdated": "2026-08-05T09:11:45.186Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
}
}
CERTFR-2024-AVI-0632
Vulnerability from certfr_avis - Published: - Updated:
De multiples vulnérabilités ont été découvertes dans le noyau Linux de SUSE. Certaines d'entre elles permettent à un attaquant de provoquer une atteinte à la confidentialité des données, un contournement de la politique de sécurité et un déni de service.
Solutions
Se référer au bulletin de sécurité de l'éditeur pour l'obtention des correctifs (cf. section Documentation).
| Vendor | Product | Description | ||
|---|---|---|---|---|
| SUSE | N/A | SUSE Linux Enterprise Desktop 15 SP6 | ||
| SUSE | N/A | Basesystem Module 15-SP6 | ||
| SUSE | N/A | Public Cloud Module 15-SP6 | ||
| SUSE | N/A | SUSE Linux Enterprise Live Patching 15-SP6 | ||
| SUSE | N/A | Legacy Module 15-SP6 | ||
| SUSE | N/A | SUSE Linux Enterprise Real Time 15 SP6 | ||
| SUSE | N/A | openSUSE Leap 15.6 | ||
| SUSE | N/A | SUSE Linux Enterprise Workstation Extension 15 SP6 | ||
| SUSE | N/A | SUSE Linux Enterprise High Availability Extension 15 SP6 | ||
| SUSE | N/A | SUSE Linux Enterprise Server for SAP Applications 15 SP6 | ||
| SUSE | N/A | Development Tools Module 15-SP6 | ||
| SUSE | N/A | SUSE Linux Enterprise Server 15 SP6 |
| Title | Publication Time | Tags | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||
{
"$ref": "https://www.cert.ssi.gouv.fr/openapi.json",
"affected_systems": [
{
"description": "SUSE Linux Enterprise Desktop 15 SP6",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "Basesystem Module 15-SP6",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "Public Cloud Module 15-SP6",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Live Patching 15-SP6",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "Legacy Module 15-SP6",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Real Time 15 SP6",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "openSUSE Leap 15.6",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Workstation Extension 15 SP6",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise High Availability Extension 15 SP6",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server for SAP Applications 15 SP6",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "Development Tools Module 15-SP6",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server 15 SP6",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"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-26625",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26625"
},
{
"name": "CVE-2023-52622",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52622"
},
{
"name": "CVE-2024-26814",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26814"
},
{
"name": "CVE-2024-26750",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26750"
},
{
"name": "CVE-2024-26813",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26813"
},
{
"name": "CVE-2024-26676",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26676"
},
{
"name": "CVE-2024-26780",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26780"
},
{
"name": "CVE-2024-26845",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26845"
},
{
"name": "CVE-2024-26889",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26889"
},
{
"name": "CVE-2024-26920",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26920"
},
{
"name": "CVE-2023-38417",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-38417"
},
{
"name": "CVE-2023-47210",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-47210"
},
{
"name": "CVE-2024-35848",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35848"
},
{
"name": "CVE-2024-36017",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36017"
},
{
"name": "CVE-2024-36904",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36904"
},
{
"name": "CVE-2024-36916",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36916"
},
{
"name": "CVE-2024-36919",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36919"
},
{
"name": "CVE-2024-36934",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36934"
},
{
"name": "CVE-2024-36957",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36957"
},
{
"name": "CVE-2023-52656",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52656"
},
{
"name": "CVE-2023-52699",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52699"
},
{
"name": "CVE-2023-52753",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52753"
},
{
"name": "CVE-2023-52754",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52754"
},
{
"name": "CVE-2023-52757",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52757"
},
{
"name": "CVE-2023-52759",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52759"
},
{
"name": "CVE-2023-52763",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52763"
},
{
"name": "CVE-2023-52764",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52764"
},
{
"name": "CVE-2023-52766",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52766"
},
{
"name": "CVE-2023-52773",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52773"
},
{
"name": "CVE-2023-52774",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52774"
},
{
"name": "CVE-2023-52777",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52777"
},
{
"name": "CVE-2023-52781",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52781"
},
{
"name": "CVE-2023-52788",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52788"
},
{
"name": "CVE-2023-52789",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52789"
},
{
"name": "CVE-2023-52791",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52791"
},
{
"name": "CVE-2023-52795",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52795"
},
{
"name": "CVE-2023-52796",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52796"
},
{
"name": "CVE-2023-52798",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52798"
},
{
"name": "CVE-2023-52799",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52799"
},
{
"name": "CVE-2023-52800",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52800"
},
{
"name": "CVE-2023-52803",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52803"
},
{
"name": "CVE-2023-52804",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52804"
},
{
"name": "CVE-2023-52805",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52805"
},
{
"name": "CVE-2023-52806",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52806"
},
{
"name": "CVE-2023-52807",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52807"
},
{
"name": "CVE-2023-52808",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52808"
},
{
"name": "CVE-2023-52809",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52809"
},
{
"name": "CVE-2023-52810",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52810"
},
{
"name": "CVE-2023-52811",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52811"
},
{
"name": "CVE-2023-52814",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52814"
},
{
"name": "CVE-2023-52815",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52815"
},
{
"name": "CVE-2023-52816",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52816"
},
{
"name": "CVE-2023-52817",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52817"
},
{
"name": "CVE-2023-52818",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52818"
},
{
"name": "CVE-2023-52819",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52819"
},
{
"name": "CVE-2023-52821",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52821"
},
{
"name": "CVE-2023-52825",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52825"
},
{
"name": "CVE-2023-52826",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52826"
},
{
"name": "CVE-2023-52832",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52832"
},
{
"name": "CVE-2023-52833",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52833"
},
{
"name": "CVE-2023-52834",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52834"
},
{
"name": "CVE-2023-52838",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52838"
},
{
"name": "CVE-2023-52840",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52840"
},
{
"name": "CVE-2023-52841",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52841"
},
{
"name": "CVE-2023-52844",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52844"
},
{
"name": "CVE-2023-52847",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52847"
},
{
"name": "CVE-2023-52851",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52851"
},
{
"name": "CVE-2023-52853",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52853"
},
{
"name": "CVE-2023-52854",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52854"
},
{
"name": "CVE-2023-52855",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52855"
},
{
"name": "CVE-2023-52856",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52856"
},
{
"name": "CVE-2023-52858",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52858"
},
{
"name": "CVE-2023-52861",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52861"
},
{
"name": "CVE-2023-52864",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52864"
},
{
"name": "CVE-2023-52865",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52865"
},
{
"name": "CVE-2023-52867",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52867"
},
{
"name": "CVE-2023-52868",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52868"
},
{
"name": "CVE-2023-52870",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52870"
},
{
"name": "CVE-2023-52871",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52871"
},
{
"name": "CVE-2023-52872",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52872"
},
{
"name": "CVE-2023-52873",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52873"
},
{
"name": "CVE-2023-52875",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52875"
},
{
"name": "CVE-2023-52876",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52876"
},
{
"name": "CVE-2023-52877",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52877"
},
{
"name": "CVE-2023-52878",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52878"
},
{
"name": "CVE-2023-52880",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52880"
},
{
"name": "CVE-2024-0090",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-0090"
},
{
"name": "CVE-2024-0091",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-0091"
},
{
"name": "CVE-2024-0092",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-0092"
},
{
"name": "CVE-2024-26758",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26758"
},
{
"name": "CVE-2024-27419",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27419"
},
{
"name": "CVE-2024-35976",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35976"
},
{
"name": "CVE-2024-35998",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35998"
},
{
"name": "CVE-2024-36924",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36924"
},
{
"name": "CVE-2024-36926",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36926"
},
{
"name": "CVE-2024-36938",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36938"
},
{
"name": "CVE-2024-36952",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36952"
},
{
"name": "CVE-2023-52672",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52672"
},
{
"name": "CVE-2024-27414",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27414"
},
{
"name": "CVE-2024-35807",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35807"
},
{
"name": "CVE-2024-35884",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35884"
},
{
"name": "CVE-2024-35886",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35886"
},
{
"name": "CVE-2024-35896",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35896"
},
{
"name": "CVE-2024-35898",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35898"
},
{
"name": "CVE-2024-35900",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35900"
},
{
"name": "CVE-2024-35925",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35925"
},
{
"name": "CVE-2024-35962",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35962"
},
{
"name": "CVE-2024-36005",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36005"
},
{
"name": "CVE-2024-36008",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36008"
},
{
"name": "CVE-2024-36960",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36960"
},
{
"name": "CVE-2024-36964",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36964"
},
{
"name": "CVE-2024-36971",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36971"
},
{
"name": "CVE-2024-37353",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-37353"
},
{
"name": "CVE-2024-38381",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38381"
},
{
"name": "CVE-2024-38549",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38549"
},
{
"name": "CVE-2024-38552",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38552"
},
{
"name": "CVE-2024-38559",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38559"
},
{
"name": "CVE-2024-38560",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38560"
},
{
"name": "CVE-2024-38565",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38565"
},
{
"name": "CVE-2024-38567",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38567"
},
{
"name": "CVE-2024-38578",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38578"
},
{
"name": "CVE-2024-38579",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38579"
},
{
"name": "CVE-2024-38582",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38582"
},
{
"name": "CVE-2024-38583",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38583"
},
{
"name": "CVE-2024-38587",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38587"
},
{
"name": "CVE-2024-38599",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38599"
},
{
"name": "CVE-2024-38601",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38601"
},
{
"name": "CVE-2024-38618",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38618"
},
{
"name": "CVE-2024-38621",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38621"
},
{
"name": "CVE-2024-38627",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38627"
},
{
"name": "CVE-2024-38633",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38633"
},
{
"name": "CVE-2024-38634",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38634"
},
{
"name": "CVE-2024-38780",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38780"
},
{
"name": "CVE-2024-35827",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35827"
},
{
"name": "CVE-2024-35831",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35831"
},
{
"name": "CVE-2024-35843",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35843"
},
{
"name": "CVE-2023-52813",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52813"
},
{
"name": "CVE-2023-52835",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52835"
},
{
"name": "CVE-2023-52881",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52881"
},
{
"name": "CVE-2021-47432",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47432"
},
{
"name": "CVE-2022-48772",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48772"
},
{
"name": "CVE-2023-52735",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52735"
},
{
"name": "CVE-2023-52762",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52762"
},
{
"name": "CVE-2023-52784",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52784"
},
{
"name": "CVE-2023-52787",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52787"
},
{
"name": "CVE-2023-52837",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52837"
},
{
"name": "CVE-2023-52843",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52843"
},
{
"name": "CVE-2023-52845",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52845"
},
{
"name": "CVE-2023-52846",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52846"
},
{
"name": "CVE-2023-52869",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52869"
},
{
"name": "CVE-2023-52884",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52884"
},
{
"name": "CVE-2024-33619",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-33619"
},
{
"name": "CVE-2024-35247",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35247"
},
{
"name": "CVE-2024-35857",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35857"
},
{
"name": "CVE-2024-35979",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35979"
},
{
"name": "CVE-2024-36477",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36477"
},
{
"name": "CVE-2024-36478",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36478"
},
{
"name": "CVE-2024-36479",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36479"
},
{
"name": "CVE-2024-36899",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36899"
},
{
"name": "CVE-2024-36900",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36900"
},
{
"name": "CVE-2024-36915",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36915"
},
{
"name": "CVE-2024-36917",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36917"
},
{
"name": "CVE-2024-36923",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36923"
},
{
"name": "CVE-2024-36937",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36937"
},
{
"name": "CVE-2024-36945",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36945"
},
{
"name": "CVE-2024-36965",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36965"
},
{
"name": "CVE-2024-36967",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36967"
},
{
"name": "CVE-2024-36969",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36969"
},
{
"name": "CVE-2024-36975",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36975"
},
{
"name": "CVE-2024-36978",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36978"
},
{
"name": "CVE-2024-37021",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-37021"
},
{
"name": "CVE-2024-37078",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-37078"
},
{
"name": "CVE-2024-37354",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-37354"
},
{
"name": "CVE-2024-38388",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38388"
},
{
"name": "CVE-2024-38390",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38390"
},
{
"name": "CVE-2024-38540",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38540"
},
{
"name": "CVE-2024-38541",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38541"
},
{
"name": "CVE-2024-38544",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38544"
},
{
"name": "CVE-2024-38545",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38545"
},
{
"name": "CVE-2024-38546",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38546"
},
{
"name": "CVE-2024-38547",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38547"
},
{
"name": "CVE-2024-38548",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38548"
},
{
"name": "CVE-2024-38550",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38550"
},
{
"name": "CVE-2024-38553",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38553"
},
{
"name": "CVE-2024-38555",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38555"
},
{
"name": "CVE-2024-38556",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38556"
},
{
"name": "CVE-2024-38557",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38557"
},
{
"name": "CVE-2024-38564",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38564"
},
{
"name": "CVE-2024-38568",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38568"
},
{
"name": "CVE-2024-38571",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38571"
},
{
"name": "CVE-2024-38573",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38573"
},
{
"name": "CVE-2024-38580",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38580"
},
{
"name": "CVE-2024-38581",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38581"
},
{
"name": "CVE-2024-38590",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38590"
},
{
"name": "CVE-2024-38591",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38591"
},
{
"name": "CVE-2024-38594",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38594"
},
{
"name": "CVE-2024-38597",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38597"
},
{
"name": "CVE-2024-38600",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38600"
},
{
"name": "CVE-2024-38603",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38603"
},
{
"name": "CVE-2024-38605",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38605"
},
{
"name": "CVE-2024-38608",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38608"
},
{
"name": "CVE-2024-38616",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38616"
},
{
"name": "CVE-2024-38619",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38619"
},
{
"name": "CVE-2024-38630",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38630"
},
{
"name": "CVE-2024-38635",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38635"
},
{
"name": "CVE-2024-38661",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38661"
},
{
"name": "CVE-2024-39301",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39301"
},
{
"name": "CVE-2024-39469",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39469"
},
{
"name": "CVE-2024-39471",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39471"
},
{
"name": "CVE-2024-38610",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38610"
},
{
"name": "CVE-2024-35880",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35880"
},
{
"name": "CVE-2024-35892",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35892"
},
{
"name": "CVE-2024-35926",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35926"
},
{
"name": "CVE-2024-35957",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35957"
},
{
"name": "CVE-2024-35970",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35970"
},
{
"name": "CVE-2024-36024",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36024"
},
{
"name": "CVE-2024-38543",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38543"
},
{
"name": "CVE-2024-38663",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38663"
},
{
"name": "CVE-2024-36973",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36973"
},
{
"name": "CVE-2024-38615",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38615"
},
{
"name": "CVE-2024-39371",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39371"
},
{
"name": "CVE-2023-52749",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52749"
},
{
"name": "CVE-2023-52750",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52750"
},
{
"name": "CVE-2023-52765",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52765"
},
{
"name": "CVE-2023-52767",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52767"
},
{
"name": "CVE-2023-52768",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52768"
},
{
"name": "CVE-2023-52769",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52769"
},
{
"name": "CVE-2023-52776",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52776"
},
{
"name": "CVE-2023-52780",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52780"
},
{
"name": "CVE-2023-52782",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52782"
},
{
"name": "CVE-2023-52783",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52783"
},
{
"name": "CVE-2023-52786",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52786"
},
{
"name": "CVE-2023-52792",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52792"
},
{
"name": "CVE-2023-52794",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52794"
},
{
"name": "CVE-2023-52801",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52801"
},
{
"name": "CVE-2023-52812",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52812"
},
{
"name": "CVE-2023-52827",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52827"
},
{
"name": "CVE-2023-52829",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52829"
},
{
"name": "CVE-2023-52836",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52836"
},
{
"name": "CVE-2023-52842",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52842"
},
{
"name": "CVE-2023-52849",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52849"
},
{
"name": "CVE-2023-52850",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52850"
},
{
"name": "CVE-2023-52857",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52857"
},
{
"name": "CVE-2023-52862",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52862"
},
{
"name": "CVE-2023-52863",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52863"
},
{
"name": "CVE-2023-52866",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52866"
},
{
"name": "CVE-2023-52874",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52874"
},
{
"name": "CVE-2023-52879",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52879"
},
{
"name": "CVE-2023-52883",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52883"
},
{
"name": "CVE-2024-26482",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26482"
},
{
"name": "CVE-2024-26767",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26767"
},
{
"name": "CVE-2024-34777",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-34777"
},
{
"name": "CVE-2024-36010",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36010"
},
{
"name": "CVE-2024-36281",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36281"
},
{
"name": "CVE-2024-36882",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36882"
},
{
"name": "CVE-2024-36887",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36887"
},
{
"name": "CVE-2024-36903",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36903"
},
{
"name": "CVE-2024-36935",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36935"
},
{
"name": "CVE-2024-36962",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36962"
},
{
"name": "CVE-2024-36972",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36972"
},
{
"name": "CVE-2024-36977",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36977"
},
{
"name": "CVE-2024-38384",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38384"
},
{
"name": "CVE-2024-38385",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38385"
},
{
"name": "CVE-2024-38391",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38391"
},
{
"name": "CVE-2024-38539",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38539"
},
{
"name": "CVE-2024-38551",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38551"
},
{
"name": "CVE-2024-38554",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38554"
},
{
"name": "CVE-2024-38562",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38562"
},
{
"name": "CVE-2024-38566",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38566"
},
{
"name": "CVE-2024-38569",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38569"
},
{
"name": "CVE-2024-38570",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38570"
},
{
"name": "CVE-2024-38572",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38572"
},
{
"name": "CVE-2024-38575",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38575"
},
{
"name": "CVE-2024-38588",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38588"
},
{
"name": "CVE-2024-38592",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38592"
},
{
"name": "CVE-2024-38595",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38595"
},
{
"name": "CVE-2024-38602",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38602"
},
{
"name": "CVE-2024-38611",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38611"
},
{
"name": "CVE-2024-38617",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38617"
},
{
"name": "CVE-2024-38622",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38622"
},
{
"name": "CVE-2024-38628",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38628"
},
{
"name": "CVE-2024-38629",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38629"
},
{
"name": "CVE-2024-38636",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38636"
},
{
"name": "CVE-2024-38664",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38664"
},
{
"name": "CVE-2024-39277",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39277"
},
{
"name": "CVE-2024-39291",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39291"
},
{
"name": "CVE-2024-39296",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39296"
},
{
"name": "CVE-2024-39362",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39362"
},
{
"name": "CVE-2024-39463",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39463"
},
{
"name": "CVE-2024-39466",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39466"
}
],
"links": [],
"reference": "CERTFR-2024-AVI-0632",
"revisions": [
{
"description": "Version initiale",
"revision_date": "2024-07-26T00:00:00.000000"
}
],
"risks": [
{
"description": "D\u00e9ni de service \u00e0 distance"
},
{
"description": "Atteinte \u00e0 l\u0027int\u00e9grit\u00e9 des donn\u00e9es"
},
{
"description": "Ex\u00e9cution de code arbitraire"
},
{
"description": "Non sp\u00e9cifi\u00e9 par l\u0027\u00e9diteur"
},
{
"description": "Contournement de la politique de s\u00e9curit\u00e9"
},
{
"description": "Atteinte \u00e0 la confidentialit\u00e9 des donn\u00e9es"
},
{
"description": "\u00c9l\u00e9vation de privil\u00e8ges"
}
],
"summary": "De multiples vuln\u00e9rabilit\u00e9s ont \u00e9t\u00e9 d\u00e9couvertes dans le noyau Linux de SUSE. Certaines d\u0027entre elles permettent \u00e0 un attaquant de provoquer une atteinte \u00e0 la confidentialit\u00e9 des donn\u00e9es, un contournement de la politique de s\u00e9curit\u00e9 et un d\u00e9ni de service.",
"title": "Multiples vuln\u00e9rabilit\u00e9s dans le noyau Linux de SUSE",
"vendor_advisories": [
{
"published_at": "2024-07-22",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2024:2575-1",
"url": "https://www.suse.com/support/update/announcement/2024/suse-su-20242575-1"
},
{
"published_at": "2024-07-22",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2024:2585-1",
"url": "https://www.suse.com/support/update/announcement/2024/suse-su-20242585-1"
},
{
"published_at": "2024-07-22",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2024:2571-1",
"url": "https://www.suse.com/support/update/announcement/2024/suse-su-20242571-1"
}
]
}
CERTFR-2024-AVI-0693
Vulnerability from certfr_avis - Published: - Updated:
De multiples vulnérabilités ont été découvertes dans le noyau Linux de SUSE. Certaines d'entre elles permettent à un attaquant de provoquer une exécution de code arbitraire, 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).
None| Vendor | Product | Description | ||
|---|---|---|---|---|
| SUSE | N/A | Basesystem Module 15-SP5 | ||
| SUSE | N/A | Development Tools Module 15-SP5 | ||
| SUSE | N/A | Legacy Module 15-SP5 | ||
| SUSE | N/A | Public Cloud Module 15-SP6 | ||
| SUSE | N/A | SUSE Linux Enterprise Desktop 15 SP4 LTSS 15-SP4 | ||
| SUSE | N/A | SUSE Linux Enterprise Desktop 15 SP5 | ||
| SUSE | N/A | SUSE Linux Enterprise High Availability Extension 15 SP5 | ||
| SUSE | N/A | SUSE Linux Enterprise High Performance Computing 12 SP5 | ||
| SUSE | N/A | SUSE Linux Enterprise High Performance Computing 15 SP2 | ||
| SUSE | N/A | SUSE Linux Enterprise High Performance Computing 15 SP2 LTSS 15-SP2 | ||
| SUSE | N/A | SUSE Linux Enterprise High Performance Computing 15 SP4 | ||
| SUSE | N/A | SUSE Linux Enterprise High Performance Computing 15 SP5 | ||
| SUSE | N/A | SUSE Linux Enterprise High Performance Computing ESPOS 15 SP4 | ||
| SUSE | N/A | SUSE Linux Enterprise High Performance Computing LTSS 15 SP4 | ||
| SUSE | N/A | SUSE Linux Enterprise Live Patching 15-SP2 | ||
| SUSE | N/A | SUSE Linux Enterprise Live Patching 15-SP4 | ||
| SUSE | N/A | SUSE Linux Enterprise Live Patching 15-SP5 | ||
| SUSE | N/A | SUSE Linux Enterprise Live Patching 15-SP6 | ||
| SUSE | N/A | SUSE Linux Enterprise Micro 5.1 | ||
| SUSE | N/A | SUSE Linux Enterprise Micro 5.2 | ||
| SUSE | N/A | SUSE Linux Enterprise Micro 5.3 | ||
| SUSE | N/A | SUSE Linux Enterprise Micro 5.4 | ||
| SUSE | N/A | SUSE Linux Enterprise Micro 5.5 | ||
| SUSE | N/A | SUSE Linux Enterprise Micro for Rancher 5.2 | ||
| SUSE | N/A | SUSE Linux Enterprise Micro for Rancher 5.3 | ||
| SUSE | N/A | SUSE Linux Enterprise Micro for Rancher 5.4 | ||
| SUSE | N/A | SUSE Linux Enterprise Real Time 12 SP5 | ||
| SUSE | N/A | SUSE Linux Enterprise Real Time 15 SP4 | ||
| SUSE | N/A | SUSE Linux Enterprise Real Time 15 SP5 | ||
| SUSE | N/A | SUSE Linux Enterprise Real Time 15 SP6 | ||
| SUSE | N/A | SUSE Linux Enterprise Server 11 SP4 | ||
| SUSE | N/A | SUSE Linux Enterprise Server 11 SP4 LTSS EXTREME CORE 11-SP4 | ||
| SUSE | N/A | SUSE Linux Enterprise Server 12 SP5 | ||
| SUSE | N/A | SUSE Linux Enterprise Server 15 SP2 | ||
| SUSE | N/A | SUSE Linux Enterprise Server 15 SP2 Business Critical Linux 15-SP2 | ||
| SUSE | N/A | SUSE Linux Enterprise Server 15 SP2 LTSS 15-SP2 | ||
| SUSE | N/A | SUSE Linux Enterprise Server 15 SP4 | ||
| SUSE | N/A | SUSE Linux Enterprise Server 15 SP4 LTSS 15-SP4 | ||
| SUSE | N/A | SUSE Linux Enterprise Server 15 SP5 | ||
| SUSE | N/A | SUSE Linux Enterprise Server 15 SP6 | ||
| SUSE | N/A | SUSE Linux Enterprise Server for SAP Applications 12 SP5 | ||
| SUSE | N/A | SUSE Linux Enterprise Server for SAP Applications 15 SP2 | ||
| SUSE | N/A | SUSE Linux Enterprise Server for SAP Applications 15 SP4 | ||
| SUSE | N/A | SUSE Linux Enterprise Server for SAP Applications 15 SP5 | ||
| SUSE | N/A | SUSE Linux Enterprise Server for SAP Applications 15 SP6 | ||
| SUSE | N/A | SUSE Linux Enterprise Workstation Extension 15 SP5 | ||
| SUSE | N/A | SUSE Manager Proxy 4.1 | ||
| SUSE | N/A | SUSE Manager Proxy 4.3 | ||
| SUSE | N/A | SUSE Manager Retail Branch Server 4.1 | ||
| SUSE | N/A | SUSE Manager Retail Branch Server 4.3 | ||
| SUSE | N/A | SUSE Manager Server 4.1 | ||
| SUSE | N/A | SUSE Manager Server 4.3 | ||
| SUSE | N/A | SUSE Real Time Module 15-SP5 | ||
| SUSE | N/A | openSUSE Leap 15.4 | ||
| SUSE | N/A | openSUSE Leap 15.5 | ||
| SUSE | N/A | openSUSE Leap 15.6 | ||
| SUSE | N/A | openSUSE Leap Micro 5.5 | ||
| SUSE | N/A | SUSE Linux Enterprise High Availability Extension 15 SP2 | ||
| SUSE | N/A | SUSE Linux Enterprise High Availability Extension 15 SP4 |
| Title | Publication Time | Tags | ||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||||||||
{
"$ref": "https://www.cert.ssi.gouv.fr/openapi.json",
"affected_systems": [
{
"description": "Basesystem Module 15-SP5",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "Development Tools Module 15-SP5",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "Legacy Module 15-SP5",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "Public Cloud Module 15-SP6",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Desktop 15 SP4 LTSS 15-SP4",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Desktop 15 SP5",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise High Availability Extension 15 SP5",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise High Performance Computing 12 SP5",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise High Performance Computing 15 SP2",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise High Performance Computing 15 SP2 LTSS 15-SP2",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise High Performance Computing 15 SP4",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise High Performance Computing 15 SP5",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise High Performance Computing ESPOS 15 SP4",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise High Performance Computing LTSS 15 SP4",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Live Patching 15-SP2",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Live Patching 15-SP4",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Live Patching 15-SP5",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Live Patching 15-SP6",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Micro 5.1",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Micro 5.2",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Micro 5.3",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Micro 5.4",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Micro 5.5",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Micro for Rancher 5.2",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Micro for Rancher 5.3",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Micro for Rancher 5.4",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Real Time 12 SP5",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Real Time 15 SP4",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Real Time 15 SP5",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Real Time 15 SP6",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server 11 SP4",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server 11 SP4 LTSS EXTREME CORE 11-SP4",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server 12 SP5",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server 15 SP2",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server 15 SP2 Business Critical Linux 15-SP2",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server 15 SP2 LTSS 15-SP2",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server 15 SP4",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server 15 SP4 LTSS 15-SP4",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server 15 SP5",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server 15 SP6",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server for SAP Applications 12 SP5",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server for SAP Applications 15 SP2",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server for SAP Applications 15 SP4",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server for SAP Applications 15 SP5",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server for SAP Applications 15 SP6",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Workstation Extension 15 SP5",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Manager Proxy 4.1",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Manager Proxy 4.3",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Manager Retail Branch Server 4.1",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Manager Retail Branch Server 4.3",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Manager Server 4.1",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Manager Server 4.3",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Real Time Module 15-SP5",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "openSUSE Leap 15.4",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "openSUSE Leap 15.5",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "openSUSE Leap 15.6",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "openSUSE Leap Micro 5.5",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise High Availability Extension 15 SP2",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise High Availability Extension 15 SP4",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
}
],
"affected_systems_content": null,
"content": "## Solutions\n\nSe r\u00e9f\u00e9rer au bulletin de s\u00e9curit\u00e9 de l\u0027\u00e9diteur pour l\u0027obtention des correctifs (cf. section Documentation).",
"cves": [
{
"name": "CVE-2020-26558",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-26558"
},
{
"name": "CVE-2021-0129",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-0129"
},
{
"name": "CVE-2021-43389",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-43389"
},
{
"name": "CVE-2022-20368",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-20368"
},
{
"name": "CVE-2022-0854",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-0854"
},
{
"name": "CVE-2022-2964",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-2964"
},
{
"name": "CVE-2022-28748",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-28748"
},
{
"name": "CVE-2023-1582",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-1582"
},
{
"name": "CVE-2023-37453",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-37453"
},
{
"name": "CVE-2023-4244",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-4244"
},
{
"name": "CVE-2023-24023",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-24023"
},
{
"name": "CVE-2023-51780",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-51780"
},
{
"name": "CVE-2024-26625",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26625"
},
{
"name": "CVE-2023-52594",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52594"
},
{
"name": "CVE-2024-26585",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26585"
},
{
"name": "CVE-2024-26633",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26633"
},
{
"name": "CVE-2023-52435",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52435"
},
{
"name": "CVE-2023-52612",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52612"
},
{
"name": "CVE-2023-52591",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52591"
},
{
"name": "CVE-2023-52615",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52615"
},
{
"name": "CVE-2024-26659",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26659"
},
{
"name": "CVE-2023-52507",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52507"
},
{
"name": "CVE-2023-52623",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52623"
},
{
"name": "CVE-2023-52619",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52619"
},
{
"name": "CVE-2024-26584",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26584"
},
{
"name": "CVE-2024-26800",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26800"
},
{
"name": "CVE-2024-26720",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26720"
},
{
"name": "CVE-2023-52622",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52622"
},
{
"name": "CVE-2024-26814",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26814"
},
{
"name": "CVE-2024-26583",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26583"
},
{
"name": "CVE-2024-26663",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26663"
},
{
"name": "CVE-2024-26750",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26750"
},
{
"name": "CVE-2024-26813",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26813"
},
{
"name": "CVE-2024-27437",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27437"
},
{
"name": "CVE-2024-26735",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26735"
},
{
"name": "CVE-2024-26676",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26676"
},
{
"name": "CVE-2024-26802",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26802"
},
{
"name": "CVE-2024-26665",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26665"
},
{
"name": "CVE-2024-26780",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26780"
},
{
"name": "CVE-2024-26641",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26641"
},
{
"name": "CVE-2023-52580",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52580"
},
{
"name": "CVE-2024-26863",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26863"
},
{
"name": "CVE-2024-27025",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27025"
},
{
"name": "CVE-2024-26845",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26845"
},
{
"name": "CVE-2024-26961",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26961"
},
{
"name": "CVE-2024-26615",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26615"
},
{
"name": "CVE-2024-26889",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26889"
},
{
"name": "CVE-2024-26880",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26880"
},
{
"name": "CVE-2024-26644",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26644"
},
{
"name": "CVE-2024-26935",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26935"
},
{
"name": "CVE-2024-27015",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27015"
},
{
"name": "CVE-2024-27020",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27020"
},
{
"name": "CVE-2024-26973",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26973"
},
{
"name": "CVE-2024-26635",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26635"
},
{
"name": "CVE-2024-26924",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26924"
},
{
"name": "CVE-2024-26920",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26920"
},
{
"name": "CVE-2024-27016",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27016"
},
{
"name": "CVE-2024-26976",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26976"
},
{
"name": "CVE-2024-26636",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26636"
},
{
"name": "CVE-2024-27065",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27065"
},
{
"name": "CVE-2024-27019",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27019"
},
{
"name": "CVE-2024-26923",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26923"
},
{
"name": "CVE-2024-26826",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26826"
},
{
"name": "CVE-2024-26623",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26623"
},
{
"name": "CVE-2023-52472",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52472"
},
{
"name": "CVE-2023-38417",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-38417"
},
{
"name": "CVE-2023-47210",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-47210"
},
{
"name": "CVE-2021-47219",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47219"
},
{
"name": "CVE-2021-47197",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47197"
},
{
"name": "CVE-2024-26830",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26830"
},
{
"name": "CVE-2021-47201",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47201"
},
{
"name": "CVE-2021-47194",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47194"
},
{
"name": "CVE-2021-47191",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47191"
},
{
"name": "CVE-2023-52882",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52882"
},
{
"name": "CVE-2024-27398",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27398"
},
{
"name": "CVE-2024-35848",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35848"
},
{
"name": "CVE-2024-35947",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35947"
},
{
"name": "CVE-2024-36017",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36017"
},
{
"name": "CVE-2024-36889",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36889"
},
{
"name": "CVE-2024-36902",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36902"
},
{
"name": "CVE-2024-36904",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36904"
},
{
"name": "CVE-2024-36916",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36916"
},
{
"name": "CVE-2024-36919",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36919"
},
{
"name": "CVE-2024-36934",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36934"
},
{
"name": "CVE-2024-36939",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36939"
},
{
"name": "CVE-2024-36940",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36940"
},
{
"name": "CVE-2024-36941",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36941"
},
{
"name": "CVE-2024-36946",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36946"
},
{
"name": "CVE-2024-36950",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36950"
},
{
"name": "CVE-2024-36957",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36957"
},
{
"name": "CVE-2024-36959",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36959"
},
{
"name": "CVE-2021-47275",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47275"
},
{
"name": "CVE-2021-47388",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47388"
},
{
"name": "CVE-2021-47395",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47395"
},
{
"name": "CVE-2021-47399",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47399"
},
{
"name": "CVE-2021-47402",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47402"
},
{
"name": "CVE-2021-47403",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47403"
},
{
"name": "CVE-2021-47405",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47405"
},
{
"name": "CVE-2021-47438",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47438"
},
{
"name": "CVE-2021-47441",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47441"
},
{
"name": "CVE-2021-47468",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47468"
},
{
"name": "CVE-2021-47498",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47498"
},
{
"name": "CVE-2021-47501",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47501"
},
{
"name": "CVE-2021-47506",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47506"
},
{
"name": "CVE-2021-47516",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47516"
},
{
"name": "CVE-2021-47520",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47520"
},
{
"name": "CVE-2021-47534",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47534"
},
{
"name": "CVE-2021-47538",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47538"
},
{
"name": "CVE-2021-47542",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47542"
},
{
"name": "CVE-2021-47555",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47555"
},
{
"name": "CVE-2021-47559",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47559"
},
{
"name": "CVE-2023-52656",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52656"
},
{
"name": "CVE-2023-52669",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52669"
},
{
"name": "CVE-2023-52683",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52683"
},
{
"name": "CVE-2023-52686",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52686"
},
{
"name": "CVE-2023-52693",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52693"
},
{
"name": "CVE-2023-52699",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52699"
},
{
"name": "CVE-2023-52743",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52743"
},
{
"name": "CVE-2023-52753",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52753"
},
{
"name": "CVE-2023-52754",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52754"
},
{
"name": "CVE-2023-52757",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52757"
},
{
"name": "CVE-2023-52759",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52759"
},
{
"name": "CVE-2023-52763",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52763"
},
{
"name": "CVE-2023-52764",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52764"
},
{
"name": "CVE-2023-52766",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52766"
},
{
"name": "CVE-2023-52773",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52773"
},
{
"name": "CVE-2023-52774",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52774"
},
{
"name": "CVE-2023-52777",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52777"
},
{
"name": "CVE-2023-52781",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52781"
},
{
"name": "CVE-2023-52788",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52788"
},
{
"name": "CVE-2023-52789",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52789"
},
{
"name": "CVE-2023-52791",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52791"
},
{
"name": "CVE-2023-52795",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52795"
},
{
"name": "CVE-2023-52796",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52796"
},
{
"name": "CVE-2023-52798",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52798"
},
{
"name": "CVE-2023-52799",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52799"
},
{
"name": "CVE-2023-52800",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52800"
},
{
"name": "CVE-2023-52803",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52803"
},
{
"name": "CVE-2023-52804",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52804"
},
{
"name": "CVE-2023-52805",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52805"
},
{
"name": "CVE-2023-52806",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52806"
},
{
"name": "CVE-2023-52807",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52807"
},
{
"name": "CVE-2023-52808",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52808"
},
{
"name": "CVE-2023-52809",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52809"
},
{
"name": "CVE-2023-52810",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52810"
},
{
"name": "CVE-2023-52811",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52811"
},
{
"name": "CVE-2023-52814",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52814"
},
{
"name": "CVE-2023-52815",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52815"
},
{
"name": "CVE-2023-52816",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52816"
},
{
"name": "CVE-2023-52817",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52817"
},
{
"name": "CVE-2023-52818",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52818"
},
{
"name": "CVE-2023-52819",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52819"
},
{
"name": "CVE-2023-52821",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52821"
},
{
"name": "CVE-2023-52825",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52825"
},
{
"name": "CVE-2023-52826",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52826"
},
{
"name": "CVE-2023-52832",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52832"
},
{
"name": "CVE-2023-52833",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52833"
},
{
"name": "CVE-2023-52834",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52834"
},
{
"name": "CVE-2023-52838",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52838"
},
{
"name": "CVE-2023-52840",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52840"
},
{
"name": "CVE-2023-52841",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52841"
},
{
"name": "CVE-2023-52844",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52844"
},
{
"name": "CVE-2023-52847",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52847"
},
{
"name": "CVE-2023-52851",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52851"
},
{
"name": "CVE-2023-52853",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52853"
},
{
"name": "CVE-2023-52854",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52854"
},
{
"name": "CVE-2023-52855",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52855"
},
{
"name": "CVE-2023-52856",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52856"
},
{
"name": "CVE-2023-52858",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52858"
},
{
"name": "CVE-2023-52861",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52861"
},
{
"name": "CVE-2023-52864",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52864"
},
{
"name": "CVE-2023-52865",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52865"
},
{
"name": "CVE-2023-52867",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52867"
},
{
"name": "CVE-2023-52868",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52868"
},
{
"name": "CVE-2023-52870",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52870"
},
{
"name": "CVE-2023-52871",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52871"
},
{
"name": "CVE-2023-52872",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52872"
},
{
"name": "CVE-2023-52873",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52873"
},
{
"name": "CVE-2023-52875",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52875"
},
{
"name": "CVE-2023-52876",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52876"
},
{
"name": "CVE-2023-52877",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52877"
},
{
"name": "CVE-2023-52878",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52878"
},
{
"name": "CVE-2023-52880",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52880"
},
{
"name": "CVE-2024-26758",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26758"
},
{
"name": "CVE-2024-269355",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-269355"
},
{
"name": "CVE-2024-27419",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27419"
},
{
"name": "CVE-2024-35789",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35789"
},
{
"name": "CVE-2024-35806",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35806"
},
{
"name": "CVE-2024-35828",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35828"
},
{
"name": "CVE-2024-35854",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35854"
},
{
"name": "CVE-2024-35861",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35861"
},
{
"name": "CVE-2024-35862",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35862"
},
{
"name": "CVE-2024-35864",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35864"
},
{
"name": "CVE-2024-35869",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35869"
},
{
"name": "CVE-2024-35878",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35878"
},
{
"name": "CVE-2024-35887",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35887"
},
{
"name": "CVE-2024-35901",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35901"
},
{
"name": "CVE-2024-35905",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35905"
},
{
"name": "CVE-2024-35950",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35950"
},
{
"name": "CVE-2024-35966",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35966"
},
{
"name": "CVE-2024-35967",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35967"
},
{
"name": "CVE-2024-35976",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35976"
},
{
"name": "CVE-2024-35978",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35978"
},
{
"name": "CVE-2024-35998",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35998"
},
{
"name": "CVE-2024-36014",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36014"
},
{
"name": "CVE-2024-36924",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36924"
},
{
"name": "CVE-2024-36926",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36926"
},
{
"name": "CVE-2024-36938",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36938"
},
{
"name": "CVE-2024-36942",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36942"
},
{
"name": "CVE-2024-36944",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36944"
},
{
"name": "CVE-2024-36947",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36947"
},
{
"name": "CVE-2024-36952",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36952"
},
{
"name": "CVE-2024-36955",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36955"
},
{
"name": "CVE-2023-52667",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52667"
},
{
"name": "CVE-2023-52658",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52658"
},
{
"name": "CVE-2023-52670",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52670"
},
{
"name": "CVE-2023-52675",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52675"
},
{
"name": "CVE-2024-27432",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27432"
},
{
"name": "CVE-2024-35790",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35790"
},
{
"name": "CVE-2024-35814",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35814"
},
{
"name": "CVE-2024-35819",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35819"
},
{
"name": "CVE-2024-35835",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35835"
},
{
"name": "CVE-2024-35837",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35837"
},
{
"name": "CVE-2024-35889",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35889"
},
{
"name": "CVE-2024-35956",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35956"
},
{
"name": "CVE-2024-35958",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35958"
},
{
"name": "CVE-2024-35960",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35960"
},
{
"name": "CVE-2024-35961",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35961"
},
{
"name": "CVE-2024-35995",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35995"
},
{
"name": "CVE-2024-35997",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35997"
},
{
"name": "CVE-2024-36020",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36020"
},
{
"name": "CVE-2024-36021",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36021"
},
{
"name": "CVE-2024-36025",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36025"
},
{
"name": "CVE-2024-36890",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36890"
},
{
"name": "CVE-2024-36894",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36894"
},
{
"name": "CVE-2024-36922",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36922"
},
{
"name": "CVE-2024-36930",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36930"
},
{
"name": "CVE-2024-36949",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36949"
},
{
"name": "CVE-2024-36951",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36951"
},
{
"name": "CVE-2023-52672",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52672"
},
{
"name": "CVE-2024-27414",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27414"
},
{
"name": "CVE-2024-35805",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35805"
},
{
"name": "CVE-2024-35807",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35807"
},
{
"name": "CVE-2024-35853",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35853"
},
{
"name": "CVE-2024-35855",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35855"
},
{
"name": "CVE-2024-35884",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35884"
},
{
"name": "CVE-2024-35886",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35886"
},
{
"name": "CVE-2024-35893",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35893"
},
{
"name": "CVE-2024-35896",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35896"
},
{
"name": "CVE-2024-35898",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35898"
},
{
"name": "CVE-2024-35899",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35899"
},
{
"name": "CVE-2024-35900",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35900"
},
{
"name": "CVE-2024-35925",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35925"
},
{
"name": "CVE-2024-35934",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35934"
},
{
"name": "CVE-2024-35962",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35962"
},
{
"name": "CVE-2024-36004",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36004"
},
{
"name": "CVE-2024-36005",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36005"
},
{
"name": "CVE-2024-36008",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36008"
},
{
"name": "CVE-2024-36288",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36288"
},
{
"name": "CVE-2024-36960",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36960"
},
{
"name": "CVE-2024-36964",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36964"
},
{
"name": "CVE-2024-36971",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36971"
},
{
"name": "CVE-2024-37353",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-37353"
},
{
"name": "CVE-2024-38381",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38381"
},
{
"name": "CVE-2024-38549",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38549"
},
{
"name": "CVE-2024-38552",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38552"
},
{
"name": "CVE-2024-38558",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38558"
},
{
"name": "CVE-2024-38559",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38559"
},
{
"name": "CVE-2024-38560",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38560"
},
{
"name": "CVE-2024-38565",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38565"
},
{
"name": "CVE-2024-38567",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38567"
},
{
"name": "CVE-2024-38578",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38578"
},
{
"name": "CVE-2024-38579",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38579"
},
{
"name": "CVE-2024-38582",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38582"
},
{
"name": "CVE-2024-38583",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38583"
},
{
"name": "CVE-2024-38587",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38587"
},
{
"name": "CVE-2024-38598",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38598"
},
{
"name": "CVE-2024-38599",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38599"
},
{
"name": "CVE-2024-38601",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38601"
},
{
"name": "CVE-2024-38618",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38618"
},
{
"name": "CVE-2024-38621",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38621"
},
{
"name": "CVE-2024-38627",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38627"
},
{
"name": "CVE-2024-38633",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38633"
},
{
"name": "CVE-2024-38634",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38634"
},
{
"name": "CVE-2024-38659",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38659"
},
{
"name": "CVE-2024-38780",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38780"
},
{
"name": "CVE-2024-26944",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26944"
},
{
"name": "CVE-2024-27064",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27064"
},
{
"name": "CVE-2024-35827",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35827"
},
{
"name": "CVE-2024-35831",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35831"
},
{
"name": "CVE-2024-35843",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35843"
},
{
"name": "CVE-2023-52813",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52813"
},
{
"name": "CVE-2023-52835",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52835"
},
{
"name": "CVE-2023-52881",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52881"
},
{
"name": "CVE-2024-35890",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35890"
},
{
"name": "CVE-2021-4439",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-4439"
},
{
"name": "CVE-2021-47089",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47089"
},
{
"name": "CVE-2021-47103",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47103"
},
{
"name": "CVE-2021-47432",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47432"
},
{
"name": "CVE-2021-47515",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47515"
},
{
"name": "CVE-2021-47539",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47539"
},
{
"name": "CVE-2021-47566",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47566"
},
{
"name": "CVE-2021-47571",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47571"
},
{
"name": "CVE-2021-47572",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47572"
},
{
"name": "CVE-2021-47576",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47576"
},
{
"name": "CVE-2021-47577",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47577"
},
{
"name": "CVE-2021-47578",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47578"
},
{
"name": "CVE-2021-47580",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47580"
},
{
"name": "CVE-2021-47582",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47582"
},
{
"name": "CVE-2021-47583",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47583"
},
{
"name": "CVE-2021-47584",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47584"
},
{
"name": "CVE-2021-47585",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47585"
},
{
"name": "CVE-2021-47586",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47586"
},
{
"name": "CVE-2021-47587",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47587"
},
{
"name": "CVE-2021-47589",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47589"
},
{
"name": "CVE-2021-47592",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47592"
},
{
"name": "CVE-2021-47595",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47595"
},
{
"name": "CVE-2021-47596",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47596"
},
{
"name": "CVE-2021-47597",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47597"
},
{
"name": "CVE-2021-47600",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47600"
},
{
"name": "CVE-2021-47601",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47601"
},
{
"name": "CVE-2021-47602",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47602"
},
{
"name": "CVE-2021-47603",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47603"
},
{
"name": "CVE-2021-47604",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47604"
},
{
"name": "CVE-2021-47605",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47605"
},
{
"name": "CVE-2021-47607",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47607"
},
{
"name": "CVE-2021-47608",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47608"
},
{
"name": "CVE-2021-47609",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47609"
},
{
"name": "CVE-2021-47610",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47610"
},
{
"name": "CVE-2021-47611",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47611"
},
{
"name": "CVE-2021-47612",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47612"
},
{
"name": "CVE-2021-47614",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47614"
},
{
"name": "CVE-2021-47615",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47615"
},
{
"name": "CVE-2021-47616",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47616"
},
{
"name": "CVE-2021-47617",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47617"
},
{
"name": "CVE-2021-47618",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47618"
},
{
"name": "CVE-2021-47619",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47619"
},
{
"name": "CVE-2021-47620",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47620"
},
{
"name": "CVE-2022-48711",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48711"
},
{
"name": "CVE-2022-48712",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48712"
},
{
"name": "CVE-2022-48713",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48713"
},
{
"name": "CVE-2022-48714",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48714"
},
{
"name": "CVE-2022-48715",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48715"
},
{
"name": "CVE-2022-48716",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48716"
},
{
"name": "CVE-2022-48717",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48717"
},
{
"name": "CVE-2022-48718",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48718"
},
{
"name": "CVE-2022-48720",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48720"
},
{
"name": "CVE-2022-48721",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48721"
},
{
"name": "CVE-2022-48722",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48722"
},
{
"name": "CVE-2022-48723",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48723"
},
{
"name": "CVE-2022-48724",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48724"
},
{
"name": "CVE-2022-48725",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48725"
},
{
"name": "CVE-2022-48726",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48726"
},
{
"name": "CVE-2022-48727",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48727"
},
{
"name": "CVE-2022-48728",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48728"
},
{
"name": "CVE-2022-48729",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48729"
},
{
"name": "CVE-2022-48730",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48730"
},
{
"name": "CVE-2022-48732",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48732"
},
{
"name": "CVE-2022-48733",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48733"
},
{
"name": "CVE-2022-48734",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48734"
},
{
"name": "CVE-2022-48735",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48735"
},
{
"name": "CVE-2022-48736",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48736"
},
{
"name": "CVE-2022-48737",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48737"
},
{
"name": "CVE-2022-48738",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48738"
},
{
"name": "CVE-2022-48739",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48739"
},
{
"name": "CVE-2022-48740",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48740"
},
{
"name": "CVE-2022-48743",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48743"
},
{
"name": "CVE-2022-48744",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48744"
},
{
"name": "CVE-2022-48745",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48745"
},
{
"name": "CVE-2022-48746",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48746"
},
{
"name": "CVE-2022-48747",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48747"
},
{
"name": "CVE-2022-48748",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48748"
},
{
"name": "CVE-2022-48749",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48749"
},
{
"name": "CVE-2022-48751",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48751"
},
{
"name": "CVE-2022-48752",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48752"
},
{
"name": "CVE-2022-48753",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48753"
},
{
"name": "CVE-2022-48754",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48754"
},
{
"name": "CVE-2022-48755",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48755"
},
{
"name": "CVE-2022-48756",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48756"
},
{
"name": "CVE-2022-48758",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48758"
},
{
"name": "CVE-2022-48759",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48759"
},
{
"name": "CVE-2022-48760",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48760"
},
{
"name": "CVE-2022-48761",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48761"
},
{
"name": "CVE-2022-48763",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48763"
},
{
"name": "CVE-2022-48765",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48765"
},
{
"name": "CVE-2022-48766",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48766"
},
{
"name": "CVE-2022-48767",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48767"
},
{
"name": "CVE-2022-48768",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48768"
},
{
"name": "CVE-2022-48769",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48769"
},
{
"name": "CVE-2022-48770",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48770"
},
{
"name": "CVE-2022-48771",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48771"
},
{
"name": "CVE-2022-48772",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48772"
},
{
"name": "CVE-2023-52735",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52735"
},
{
"name": "CVE-2023-52737",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52737"
},
{
"name": "CVE-2023-52752",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52752"
},
{
"name": "CVE-2023-52762",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52762"
},
{
"name": "CVE-2023-52784",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52784"
},
{
"name": "CVE-2023-52787",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52787"
},
{
"name": "CVE-2023-52837",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52837"
},
{
"name": "CVE-2023-52843",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52843"
},
{
"name": "CVE-2023-52845",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52845"
},
{
"name": "CVE-2023-52846",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52846"
},
{
"name": "CVE-2023-52869",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52869"
},
{
"name": "CVE-2023-52884",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52884"
},
{
"name": "CVE-2024-26842",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26842"
},
{
"name": "CVE-2024-33619",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-33619"
},
{
"name": "CVE-2024-35247",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35247"
},
{
"name": "CVE-2024-35857",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35857"
},
{
"name": "CVE-2024-35979",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35979"
},
{
"name": "CVE-2024-36477",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36477"
},
{
"name": "CVE-2024-36478",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36478"
},
{
"name": "CVE-2024-36479",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36479"
},
{
"name": "CVE-2024-36592",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36592"
},
{
"name": "CVE-2024-36899",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36899"
},
{
"name": "CVE-2024-36900",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36900"
},
{
"name": "CVE-2024-36915",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36915"
},
{
"name": "CVE-2024-36917",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36917"
},
{
"name": "CVE-2024-36923",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36923"
},
{
"name": "CVE-2024-36937",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36937"
},
{
"name": "CVE-2024-36945",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36945"
},
{
"name": "CVE-2024-36965",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36965"
},
{
"name": "CVE-2024-36967",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36967"
},
{
"name": "CVE-2024-36969",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36969"
},
{
"name": "CVE-2024-36975",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36975"
},
{
"name": "CVE-2024-36978",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36978"
},
{
"name": "CVE-2024-37021",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-37021"
},
{
"name": "CVE-2024-37078",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-37078"
},
{
"name": "CVE-2024-37354",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-37354"
},
{
"name": "CVE-2024-38388",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38388"
},
{
"name": "CVE-2024-38390",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38390"
},
{
"name": "CVE-2024-38540",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38540"
},
{
"name": "CVE-2024-38541",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38541"
},
{
"name": "CVE-2024-38544",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38544"
},
{
"name": "CVE-2024-38545",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38545"
},
{
"name": "CVE-2024-38546",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38546"
},
{
"name": "CVE-2024-38547",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38547"
},
{
"name": "CVE-2024-38548",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38548"
},
{
"name": "CVE-2024-38550",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38550"
},
{
"name": "CVE-2024-38553",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38553"
},
{
"name": "CVE-2024-38555",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38555"
},
{
"name": "CVE-2024-38556",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38556"
},
{
"name": "CVE-2024-38557",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38557"
},
{
"name": "CVE-2024-38564",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38564"
},
{
"name": "CVE-2024-38568",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38568"
},
{
"name": "CVE-2024-38571",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38571"
},
{
"name": "CVE-2024-38573",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38573"
},
{
"name": "CVE-2024-38580",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38580"
},
{
"name": "CVE-2024-38581",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38581"
},
{
"name": "CVE-2024-38590",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38590"
},
{
"name": "CVE-2024-38591",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38591"
},
{
"name": "CVE-2024-38594",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38594"
},
{
"name": "CVE-2024-38597",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38597"
},
{
"name": "CVE-2024-38600",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38600"
},
{
"name": "CVE-2024-38603",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38603"
},
{
"name": "CVE-2024-38605",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38605"
},
{
"name": "CVE-2024-38608",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38608"
},
{
"name": "CVE-2024-38616",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38616"
},
{
"name": "CVE-2024-38619",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38619"
},
{
"name": "CVE-2024-38630",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38630"
},
{
"name": "CVE-2024-38635",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38635"
},
{
"name": "CVE-2024-38661",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38661"
},
{
"name": "CVE-2024-39301",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39301"
},
{
"name": "CVE-2024-39468",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39468"
},
{
"name": "CVE-2024-39469",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39469"
},
{
"name": "CVE-2024-39471",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39471"
},
{
"name": "CVE-2021-47145",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47145"
},
{
"name": "CVE-2021-47547",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47547"
},
{
"name": "CVE-2024-38610",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38610"
},
{
"name": "CVE-2024-39475",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39475"
},
{
"name": "CVE-2024-26661",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26661"
},
{
"name": "CVE-2024-26691",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26691"
},
{
"name": "CVE-2024-26734",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26734"
},
{
"name": "CVE-2024-27012",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27012"
},
{
"name": "CVE-2024-35880",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35880"
},
{
"name": "CVE-2024-35892",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35892"
},
{
"name": "CVE-2024-35908",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35908"
},
{
"name": "CVE-2024-35926",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35926"
},
{
"name": "CVE-2024-35942",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35942"
},
{
"name": "CVE-2024-35957",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35957"
},
{
"name": "CVE-2024-35970",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35970"
},
{
"name": "CVE-2024-36024",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36024"
},
{
"name": "CVE-2024-38543",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38543"
},
{
"name": "CVE-2024-38586",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38586"
},
{
"name": "CVE-2024-38663",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38663"
},
{
"name": "CVE-2024-25741",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-25741"
},
{
"name": "CVE-2024-36973",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36973"
},
{
"name": "CVE-2024-36974",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36974"
},
{
"name": "CVE-2024-38615",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38615"
},
{
"name": "CVE-2024-39276",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39276"
},
{
"name": "CVE-2024-39371",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39371"
},
{
"name": "CVE-2024-39474",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39474"
},
{
"name": "CVE-2024-39482",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39482"
},
{
"name": "CVE-2024-39487",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39487"
},
{
"name": "CVE-2024-39488",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39488"
},
{
"name": "CVE-2024-39493",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39493"
},
{
"name": "CVE-2024-39494",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39494"
},
{
"name": "CVE-2024-39496",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39496"
},
{
"name": "CVE-2024-39499",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39499"
},
{
"name": "CVE-2024-39500",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39500"
},
{
"name": "CVE-2024-39501",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39501"
},
{
"name": "CVE-2024-39502",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39502"
},
{
"name": "CVE-2024-39505",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39505"
},
{
"name": "CVE-2024-39506",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39506"
},
{
"name": "CVE-2024-39507",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39507"
},
{
"name": "CVE-2024-39509",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39509"
},
{
"name": "CVE-2024-40900",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40900"
},
{
"name": "CVE-2024-40901",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40901"
},
{
"name": "CVE-2024-40902",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40902"
},
{
"name": "CVE-2024-40903",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40903"
},
{
"name": "CVE-2024-40904",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40904"
},
{
"name": "CVE-2024-40906",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40906"
},
{
"name": "CVE-2024-40908",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40908"
},
{
"name": "CVE-2024-40911",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40911"
},
{
"name": "CVE-2024-40912",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40912"
},
{
"name": "CVE-2024-40916",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40916"
},
{
"name": "CVE-2024-40919",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40919"
},
{
"name": "CVE-2024-40924",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40924"
},
{
"name": "CVE-2024-40927",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40927"
},
{
"name": "CVE-2024-40929",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40929"
},
{
"name": "CVE-2024-40931",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40931"
},
{
"name": "CVE-2024-40932",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40932"
},
{
"name": "CVE-2024-40934",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40934"
},
{
"name": "CVE-2024-40935",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40935"
},
{
"name": "CVE-2024-40937",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40937"
},
{
"name": "CVE-2024-40940",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40940"
},
{
"name": "CVE-2024-40941",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40941"
},
{
"name": "CVE-2024-40942",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40942"
},
{
"name": "CVE-2024-40943",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40943"
},
{
"name": "CVE-2024-40945",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40945"
},
{
"name": "CVE-2024-40947",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40947"
},
{
"name": "CVE-2024-40948",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40948"
},
{
"name": "CVE-2024-40953",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40953"
},
{
"name": "CVE-2024-40954",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40954"
},
{
"name": "CVE-2024-40956",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40956"
},
{
"name": "CVE-2024-40958",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40958"
},
{
"name": "CVE-2024-40959",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40959"
},
{
"name": "CVE-2024-40960",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40960"
},
{
"name": "CVE-2024-40961",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40961"
},
{
"name": "CVE-2024-40966",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40966"
},
{
"name": "CVE-2024-40967",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40967"
},
{
"name": "CVE-2024-40970",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40970"
},
{
"name": "CVE-2024-40976",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40976"
},
{
"name": "CVE-2024-40977",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40977"
},
{
"name": "CVE-2024-40978",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40978"
},
{
"name": "CVE-2024-40981",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40981"
},
{
"name": "CVE-2024-40984",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40984"
},
{
"name": "CVE-2024-40987",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40987"
},
{
"name": "CVE-2024-40988",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40988"
},
{
"name": "CVE-2024-40989",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40989"
},
{
"name": "CVE-2024-40990",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40990"
},
{
"name": "CVE-2024-40994",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40994"
},
{
"name": "CVE-2024-40995",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40995"
},
{
"name": "CVE-2024-41002",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41002"
},
{
"name": "CVE-2024-41004",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41004"
},
{
"name": "CVE-2024-41006",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41006"
},
{
"name": "CVE-2023-52749",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52749"
},
{
"name": "CVE-2023-52750",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52750"
},
{
"name": "CVE-2023-52765",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52765"
},
{
"name": "CVE-2023-52767",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52767"
},
{
"name": "CVE-2023-52768",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52768"
},
{
"name": "CVE-2023-52769",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52769"
},
{
"name": "CVE-2023-52776",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52776"
},
{
"name": "CVE-2023-52780",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52780"
},
{
"name": "CVE-2023-52782",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52782"
},
{
"name": "CVE-2023-52783",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52783"
},
{
"name": "CVE-2023-52786",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52786"
},
{
"name": "CVE-2023-52792",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52792"
},
{
"name": "CVE-2023-52794",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52794"
},
{
"name": "CVE-2023-52801",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52801"
},
{
"name": "CVE-2023-52812",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52812"
},
{
"name": "CVE-2023-52827",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52827"
},
{
"name": "CVE-2023-52829",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52829"
},
{
"name": "CVE-2023-52836",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52836"
},
{
"name": "CVE-2023-52842",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52842"
},
{
"name": "CVE-2023-52849",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52849"
},
{
"name": "CVE-2023-52850",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52850"
},
{
"name": "CVE-2023-52857",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52857"
},
{
"name": "CVE-2023-52862",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52862"
},
{
"name": "CVE-2023-52863",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52863"
},
{
"name": "CVE-2023-52866",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52866"
},
{
"name": "CVE-2023-52874",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52874"
},
{
"name": "CVE-2023-52879",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52879"
},
{
"name": "CVE-2023-52883",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52883"
},
{
"name": "CVE-2024-26767",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26767"
},
{
"name": "CVE-2024-34777",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-34777"
},
{
"name": "CVE-2024-36010",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36010"
},
{
"name": "CVE-2024-36281",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36281"
},
{
"name": "CVE-2024-36882",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36882"
},
{
"name": "CVE-2024-36887",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36887"
},
{
"name": "CVE-2024-36903",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36903"
},
{
"name": "CVE-2024-36935",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36935"
},
{
"name": "CVE-2024-36962",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36962"
},
{
"name": "CVE-2024-36972",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36972"
},
{
"name": "CVE-2024-36977",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36977"
},
{
"name": "CVE-2024-38384",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38384"
},
{
"name": "CVE-2024-38385",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38385"
},
{
"name": "CVE-2024-38391",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38391"
},
{
"name": "CVE-2024-38539",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38539"
},
{
"name": "CVE-2024-38551",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38551"
},
{
"name": "CVE-2024-38554",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38554"
},
{
"name": "CVE-2024-38562",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38562"
},
{
"name": "CVE-2024-38566",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38566"
},
{
"name": "CVE-2024-38569",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38569"
},
{
"name": "CVE-2024-38570",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38570"
},
{
"name": "CVE-2024-38572",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38572"
},
{
"name": "CVE-2024-38575",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38575"
},
{
"name": "CVE-2024-38588",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38588"
},
{
"name": "CVE-2024-38592",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38592"
},
{
"name": "CVE-2024-38595",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38595"
},
{
"name": "CVE-2024-38602",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38602"
},
{
"name": "CVE-2024-38611",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38611"
},
{
"name": "CVE-2024-38617",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38617"
},
{
"name": "CVE-2024-38622",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38622"
},
{
"name": "CVE-2024-38628",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38628"
},
{
"name": "CVE-2024-38629",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38629"
},
{
"name": "CVE-2024-38636",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38636"
},
{
"name": "CVE-2024-38664",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38664"
},
{
"name": "CVE-2024-39277",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39277"
},
{
"name": "CVE-2024-39291",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39291"
},
{
"name": "CVE-2024-39296",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39296"
},
{
"name": "CVE-2024-39362",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39362"
},
{
"name": "CVE-2024-39463",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39463"
},
{
"name": "CVE-2024-39466",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39466"
},
{
"name": "CVE-2024-35949",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35949"
},
{
"name": "CVE-2024-36000",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36000"
},
{
"name": "CVE-2024-36003",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36003"
},
{
"name": "CVE-2024-36901",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36901"
},
{
"name": "CVE-2024-36909",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36909"
},
{
"name": "CVE-2024-36910",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36910"
},
{
"name": "CVE-2024-36911",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36911"
},
{
"name": "CVE-2024-36912",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36912"
},
{
"name": "CVE-2024-36913",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36913"
},
{
"name": "CVE-2024-36914",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36914"
},
{
"name": "CVE-2024-38604",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38604"
},
{
"name": "CVE-2024-41011",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41011"
},
{
"name": "CVE-2021-47624",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47624"
},
{
"name": "CVE-2023-52775",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52775"
},
{
"name": "CVE-2023-52885",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52885"
},
{
"name": "CVE-2024-39472",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39472"
},
{
"name": "CVE-2023-52751",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52751"
},
{
"name": "CVE-2024-26785",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26785"
},
{
"name": "CVE-2024-27402",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27402"
},
{
"name": "CVE-2024-27404",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27404"
},
{
"name": "CVE-2024-39473",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39473"
},
{
"name": "CVE-2024-39479",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39479"
},
{
"name": "CVE-2024-39481",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39481"
},
{
"name": "CVE-2024-39490",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39490"
},
{
"name": "CVE-2024-39498",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39498"
},
{
"name": "CVE-2024-39504",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39504"
},
{
"name": "CVE-2024-40923",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40923"
},
{
"name": "CVE-2024-40925",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40925"
},
{
"name": "CVE-2024-40928",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40928"
},
{
"name": "CVE-2024-40972",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40972"
},
{
"name": "CVE-2024-40975",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40975"
},
{
"name": "CVE-2024-40979",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40979"
},
{
"name": "CVE-2024-40998",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40998"
},
{
"name": "CVE-2024-40999",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40999"
},
{
"name": "CVE-2024-41013",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41013"
},
{
"name": "CVE-2024-41014",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41014"
},
{
"name": "CVE-2024-41017",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41017"
},
{
"name": "CVE-2024-41090",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41090"
},
{
"name": "CVE-2024-41091",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41091"
},
{
"name": "CVE-2016-20022",
"url": "https://www.cve.org/CVERecord?id=CVE-2016-20022"
},
{
"name": "CVE-2021-47086",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47086"
},
{
"name": "CVE-2021-47126",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47126"
},
{
"name": "CVE-2021-47186",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47186"
},
{
"name": "CVE-2021-47291",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47291"
},
{
"name": "CVE-2021-47295",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47295"
},
{
"name": "CVE-2021-47546",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47546"
},
{
"name": "CVE-2021-47588",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47588"
},
{
"name": "CVE-2021-47590",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47590"
},
{
"name": "CVE-2021-47591",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47591"
},
{
"name": "CVE-2021-47593",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47593"
},
{
"name": "CVE-2021-47598",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47598"
},
{
"name": "CVE-2021-47599",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47599"
},
{
"name": "CVE-2021-47606",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47606"
},
{
"name": "CVE-2021-47622",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47622"
},
{
"name": "CVE-2021-47623",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47623"
},
{
"name": "CVE-2022-48773",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48773"
},
{
"name": "CVE-2022-48774",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48774"
},
{
"name": "CVE-2022-48775",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48775"
},
{
"name": "CVE-2022-48776",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48776"
},
{
"name": "CVE-2022-48777",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48777"
},
{
"name": "CVE-2022-48778",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48778"
},
{
"name": "CVE-2022-48780",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48780"
},
{
"name": "CVE-2022-48783",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48783"
},
{
"name": "CVE-2022-48784",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48784"
},
{
"name": "CVE-2022-48785",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48785"
},
{
"name": "CVE-2022-48786",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48786"
},
{
"name": "CVE-2022-48787",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48787"
},
{
"name": "CVE-2022-48788",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48788"
},
{
"name": "CVE-2022-48789",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48789"
},
{
"name": "CVE-2022-48790",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48790"
},
{
"name": "CVE-2022-48791",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48791"
},
{
"name": "CVE-2022-48792",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48792"
},
{
"name": "CVE-2022-48793",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48793"
},
{
"name": "CVE-2022-48794",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48794"
},
{
"name": "CVE-2022-48796",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48796"
},
{
"name": "CVE-2022-48797",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48797"
},
{
"name": "CVE-2022-48798",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48798"
},
{
"name": "CVE-2022-48799",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48799"
},
{
"name": "CVE-2022-48800",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48800"
},
{
"name": "CVE-2022-48801",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48801"
},
{
"name": "CVE-2022-48802",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48802"
},
{
"name": "CVE-2022-48803",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48803"
},
{
"name": "CVE-2022-48804",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48804"
},
{
"name": "CVE-2022-48805",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48805"
},
{
"name": "CVE-2022-48806",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48806"
},
{
"name": "CVE-2022-48807",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48807"
},
{
"name": "CVE-2022-48809",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48809"
},
{
"name": "CVE-2022-48810",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48810"
},
{
"name": "CVE-2022-48811",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48811"
},
{
"name": "CVE-2022-48812",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48812"
},
{
"name": "CVE-2022-48813",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48813"
},
{
"name": "CVE-2022-48814",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48814"
},
{
"name": "CVE-2022-48815",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48815"
},
{
"name": "CVE-2022-48816",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48816"
},
{
"name": "CVE-2022-48817",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48817"
},
{
"name": "CVE-2022-48818",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48818"
},
{
"name": "CVE-2022-48820",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48820"
},
{
"name": "CVE-2022-48821",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48821"
},
{
"name": "CVE-2022-48822",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48822"
},
{
"name": "CVE-2022-48823",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48823"
},
{
"name": "CVE-2022-48824",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48824"
},
{
"name": "CVE-2022-48825",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48825"
},
{
"name": "CVE-2022-48826",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48826"
},
{
"name": "CVE-2022-48827",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48827"
},
{
"name": "CVE-2022-48828",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48828"
},
{
"name": "CVE-2022-48829",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48829"
},
{
"name": "CVE-2022-48830",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48830"
},
{
"name": "CVE-2022-48831",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48831"
},
{
"name": "CVE-2022-48834",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48834"
},
{
"name": "CVE-2022-48835",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48835"
},
{
"name": "CVE-2022-48836",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48836"
},
{
"name": "CVE-2022-48837",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48837"
},
{
"name": "CVE-2022-48838",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48838"
},
{
"name": "CVE-2022-48839",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48839"
},
{
"name": "CVE-2022-48840",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48840"
},
{
"name": "CVE-2022-48841",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48841"
},
{
"name": "CVE-2022-48842",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48842"
},
{
"name": "CVE-2022-48843",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48843"
},
{
"name": "CVE-2022-48844",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48844"
},
{
"name": "CVE-2022-48846",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48846"
},
{
"name": "CVE-2022-48847",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48847"
},
{
"name": "CVE-2022-48849",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48849"
},
{
"name": "CVE-2022-48850",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48850"
},
{
"name": "CVE-2022-48851",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48851"
},
{
"name": "CVE-2022-48852",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48852"
},
{
"name": "CVE-2022-48853",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48853"
},
{
"name": "CVE-2022-48855",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48855"
},
{
"name": "CVE-2022-48856",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48856"
},
{
"name": "CVE-2022-48857",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48857"
},
{
"name": "CVE-2022-48858",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48858"
},
{
"name": "CVE-2022-48859",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48859"
},
{
"name": "CVE-2022-48860",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48860"
},
{
"name": "CVE-2022-48861",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48861"
},
{
"name": "CVE-2022-48862",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48862"
},
{
"name": "CVE-2022-48863",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48863"
},
{
"name": "CVE-2022-48864",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48864"
},
{
"name": "CVE-2022-48866",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48866"
},
{
"name": "CVE-2023-31315",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-31315"
},
{
"name": "CVE-2023-52573",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52573"
},
{
"name": "CVE-2023-52886",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52886"
},
{
"name": "CVE-2024-39497",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39497"
},
{
"name": "CVE-2024-39508",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39508"
},
{
"name": "CVE-2024-40909",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40909"
},
{
"name": "CVE-2024-40982",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40982"
},
{
"name": "CVE-2024-41009",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41009"
},
{
"name": "CVE-2024-41012",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41012"
},
{
"name": "CVE-2024-41015",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41015"
},
{
"name": "CVE-2024-41016",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41016"
},
{
"name": "CVE-2024-41040",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41040"
},
{
"name": "CVE-2024-41041",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41041"
},
{
"name": "CVE-2024-41044",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41044"
},
{
"name": "CVE-2024-41048",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41048"
},
{
"name": "CVE-2024-41057",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41057"
},
{
"name": "CVE-2024-41058",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41058"
},
{
"name": "CVE-2024-41059",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41059"
},
{
"name": "CVE-2024-41060",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41060"
},
{
"name": "CVE-2024-41063",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41063"
},
{
"name": "CVE-2024-41064",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41064"
},
{
"name": "CVE-2024-41066",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41066"
},
{
"name": "CVE-2024-41069",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41069"
},
{
"name": "CVE-2024-41070",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41070"
},
{
"name": "CVE-2024-41071",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41071"
},
{
"name": "CVE-2024-41072",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41072"
},
{
"name": "CVE-2024-41076",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41076"
},
{
"name": "CVE-2024-41078",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41078"
},
{
"name": "CVE-2024-41081",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41081"
},
{
"name": "CVE-2024-41087",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41087"
},
{
"name": "CVE-2024-41089",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41089"
},
{
"name": "CVE-2024-41095",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41095"
},
{
"name": "CVE-2024-42070",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42070"
},
{
"name": "CVE-2024-42079",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42079"
},
{
"name": "CVE-2024-42093",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42093"
},
{
"name": "CVE-2024-42096",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42096"
},
{
"name": "CVE-2024-42105",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42105"
},
{
"name": "CVE-2024-42119",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42119"
},
{
"name": "CVE-2024-42120",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42120"
},
{
"name": "CVE-2024-42122",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42122"
},
{
"name": "CVE-2024-42124",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42124"
},
{
"name": "CVE-2024-42145",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42145"
},
{
"name": "CVE-2024-42161",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42161"
},
{
"name": "CVE-2024-42223",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42223"
},
{
"name": "CVE-2024-42224",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42224"
},
{
"name": "CVE-2024-42230",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42230"
}
],
"links": [],
"reference": "CERTFR-2024-AVI-0693",
"revisions": [
{
"description": "Version initiale",
"revision_date": "2024-08-16T00:00:00.000000"
}
],
"risks": [
{
"description": "Atteinte \u00e0 l\u0027int\u00e9grit\u00e9 des donn\u00e9es"
},
{
"description": "Ex\u00e9cution de code arbitraire"
},
{
"description": "Non sp\u00e9cifi\u00e9 par l\u0027\u00e9diteur"
},
{
"description": "D\u00e9ni de service"
},
{
"description": "Contournement de la politique de s\u00e9curit\u00e9"
},
{
"description": "Atteinte \u00e0 la confidentialit\u00e9 des donn\u00e9es"
},
{
"description": "\u00c9l\u00e9vation de privil\u00e8ges"
}
],
"summary": "De multiples vuln\u00e9rabilit\u00e9s ont \u00e9t\u00e9 d\u00e9couvertes dans le noyau Linux de SUSE. Certaines d\u0027entre elles permettent \u00e0 un attaquant de provoquer une ex\u00e9cution de code arbitraire, 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 de SUSE",
"vendor_advisories": [
{
"published_at": "2024-08-14",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2024:2911-1",
"url": "https://www.suse.com/support/update/announcement/2024/suse-su-20242911-1"
},
{
"published_at": "2024-08-13",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2024:2894-1",
"url": "https://www.suse.com/support/update/announcement/2024/suse-su-20242894-1"
},
{
"published_at": "2024-08-13",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2024:2892-1",
"url": "https://www.suse.com/support/update/announcement/2024/suse-su-20242892-1"
},
{
"published_at": "2024-08-15",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2024:2923-1",
"url": "https://www.suse.com/support/update/announcement/2024/suse-su-20242923-1"
},
{
"published_at": "2024-08-16",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2024:2939-1",
"url": "https://www.suse.com/support/update/announcement/2024/suse-su-20242939-1"
},
{
"published_at": "2024-08-15",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2024:2929-1",
"url": "https://www.suse.com/support/update/announcement/2024/suse-su-20242929-1"
},
{
"published_at": "2024-08-14",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2024:2902-1",
"url": "https://www.suse.com/support/update/announcement/2024/suse-su-20242902-1"
},
{
"published_at": "2024-08-13",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2024:2895-1",
"url": "https://www.suse.com/support/update/announcement/2024/suse-su-20242895-1"
},
{
"published_at": "2024-08-12",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2024:2874-1",
"url": "https://www.suse.com/support/update/announcement/2024/suse-su-20242874-1"
},
{
"published_at": "2024-08-13",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2024:2896-1",
"url": "https://www.suse.com/support/update/announcement/2024/suse-su-20242896-1"
},
{
"published_at": "2024-08-13",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2024:2893-1",
"url": "https://www.suse.com/support/update/announcement/2024/suse-su-20242893-1"
},
{
"published_at": "2024-08-14",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2024:2901-1",
"url": "https://www.suse.com/support/update/announcement/2024/suse-su-20242901-1"
}
]
}
CERTFR-2024-AVI-0717
Vulnerability from certfr_avis - Published: - Updated:
De multiples vulnérabilités ont été découvertes dans le noyau Linux de SUSE. Certaines d'entre elles permettent à un attaquant de provoquer une exécution de code arbitraire à distance, une élévation de privilèges et un déni de service à distance.
Solutions
Se référer au bulletin de sécurité de l'éditeur pour l'obtention des correctifs (cf. section Documentation).
| Vendor | Product | Description | ||
|---|---|---|---|---|
| SUSE | N/A | SUSE Enterprise Storage 7.1 | ||
| SUSE | N/A | SUSE Linux Enterprise High Availability Extension 15 SP3 | ||
| SUSE | N/A | Public Cloud Module 15-SP5 | ||
| SUSE | N/A | SUSE Linux Enterprise Desktop 15 SP4 LTSS 15-SP4 | ||
| SUSE | N/A | SUSE Linux Enterprise High Availability Extension 12 SP5 | ||
| SUSE | N/A | SUSE Linux Enterprise High Performance Computing 12 SP5 | ||
| SUSE | N/A | SUSE Linux Enterprise High Performance Computing 15 SP2 | ||
| SUSE | N/A | SUSE Linux Enterprise High Performance Computing 15 SP2 LTSS 15-SP2 | ||
| SUSE | N/A | SUSE Linux Enterprise High Performance Computing 15 SP3 | ||
| SUSE | N/A | SUSE Linux Enterprise High Performance Computing 15 SP4 | ||
| SUSE | N/A | SUSE Linux Enterprise High Performance Computing 15 SP5 | ||
| SUSE | N/A | SUSE Linux Enterprise High Performance Computing ESPOS 15 SP4 | ||
| SUSE | N/A | SUSE Linux Enterprise High Performance Computing LTSS 15 SP3 | ||
| SUSE | N/A | SUSE Linux Enterprise High Performance Computing LTSS 15 SP4 | ||
| SUSE | N/A | SUSE Linux Enterprise Live Patching 12-SP5 | ||
| SUSE | N/A | SUSE Linux Enterprise Live Patching 15-SP3 | ||
| SUSE | N/A | SUSE Linux Enterprise Live Patching 15-SP6 | ||
| SUSE | N/A | SUSE Linux Enterprise Micro 5.1 | ||
| SUSE | N/A | SUSE Linux Enterprise Micro 5.2 | ||
| SUSE | N/A | SUSE Linux Enterprise Micro 5.3 | ||
| SUSE | N/A | SUSE Linux Enterprise Micro 5.4 | ||
| SUSE | N/A | SUSE Linux Enterprise Micro for Rancher 5.2 | ||
| SUSE | N/A | SUSE Linux Enterprise Micro for Rancher 5.3 | ||
| SUSE | N/A | SUSE Linux Enterprise Micro for Rancher 5.4 | ||
| SUSE | N/A | SUSE Linux Enterprise Real Time 15 SP6 | ||
| SUSE | N/A | SUSE Linux Enterprise Server 12 SP5 | ||
| SUSE | N/A | SUSE Linux Enterprise Server 15 SP2 | ||
| SUSE | N/A | SUSE Linux Enterprise Server 15 SP2 LTSS 15-SP2 | ||
| SUSE | N/A | SUSE Linux Enterprise Server 15 SP3 | ||
| SUSE | N/A | SUSE Linux Enterprise Server 15 SP3 Business Critical Linux 15-SP3 | ||
| SUSE | N/A | SUSE Linux Enterprise Server 15 SP3 LTSS 15-SP3 | ||
| SUSE | N/A | SUSE Linux Enterprise Server 15 SP4 | ||
| SUSE | N/A | SUSE Linux Enterprise Server 15 SP4 LTSS 15-SP4 | ||
| SUSE | N/A | SUSE Linux Enterprise Server 15 SP5 | ||
| SUSE | N/A | SUSE Linux Enterprise Server 15 SP6 | ||
| SUSE | N/A | SUSE Linux Enterprise Server for SAP Applications 12 SP5 | ||
| SUSE | N/A | SUSE Linux Enterprise Server for SAP Applications 15 SP2 | ||
| SUSE | N/A | SUSE Linux Enterprise Server for SAP Applications 15 SP3 | ||
| SUSE | N/A | SUSE Linux Enterprise Server for SAP Applications 15 SP4 | ||
| SUSE | N/A | SUSE Linux Enterprise Server for SAP Applications 15 SP5 | ||
| SUSE | N/A | SUSE Linux Enterprise Server for SAP Applications 15 SP6 | ||
| SUSE | N/A | SUSE Linux Enterprise Software Development Kit 12 SP5 | ||
| SUSE | N/A | SUSE Linux Enterprise Workstation Extension 12 12-SP5 | ||
| SUSE | N/A | SUSE Manager Proxy 4.2 | ||
| SUSE | N/A | SUSE Manager Proxy 4.3 | ||
| SUSE | N/A | SUSE Manager Retail Branch Server 4.2 | ||
| SUSE | N/A | SUSE Manager Retail Branch Server 4.3 | ||
| SUSE | N/A | SUSE Manager Server 4.2 | ||
| SUSE | N/A | SUSE Manager Server 4.3 | ||
| SUSE | N/A | SUSE Real Time Module 15-SP6 | ||
| SUSE | N/A | openSUSE Leap 15.3 | ||
| SUSE | N/A | openSUSE Leap 15.4 | ||
| SUSE | N/A | openSUSE Leap 15.5 | ||
| SUSE | N/A | openSUSE Leap 15.6 |
| Title | Publication Time | Tags | |||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||
{
"$ref": "https://www.cert.ssi.gouv.fr/openapi.json",
"affected_systems": [
{
"description": "SUSE Enterprise Storage 7.1",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise High Availability Extension 15 SP3",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "Public Cloud Module 15-SP5",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Desktop 15 SP4 LTSS 15-SP4",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise High Availability Extension 12 SP5",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise High Performance Computing 12 SP5",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise High Performance Computing 15 SP2",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise High Performance Computing 15 SP2 LTSS 15-SP2",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise High Performance Computing 15 SP3",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise High Performance Computing 15 SP4",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise High Performance Computing 15 SP5",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise High Performance Computing ESPOS 15 SP4",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise High Performance Computing LTSS 15 SP3",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise High Performance Computing LTSS 15 SP4",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Live Patching 12-SP5",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Live Patching 15-SP3",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Live Patching 15-SP6",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Micro 5.1",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Micro 5.2",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Micro 5.3",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Micro 5.4",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Micro for Rancher 5.2",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Micro for Rancher 5.3",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Micro for Rancher 5.4",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Real Time 15 SP6",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server 12 SP5",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server 15 SP2",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server 15 SP2 LTSS 15-SP2",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server 15 SP3",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server 15 SP3 Business Critical Linux 15-SP3",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server 15 SP3 LTSS 15-SP3",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server 15 SP4",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server 15 SP4 LTSS 15-SP4",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server 15 SP5",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server 15 SP6",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server for SAP Applications 12 SP5",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server for SAP Applications 15 SP2",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server for SAP Applications 15 SP3",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server for SAP Applications 15 SP4",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server for SAP Applications 15 SP5",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server for SAP Applications 15 SP6",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Software Development Kit 12 SP5",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Workstation Extension 12 12-SP5",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Manager Proxy 4.2",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Manager Proxy 4.3",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Manager Retail Branch Server 4.2",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Manager Retail Branch Server 4.3",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Manager Server 4.2",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Manager Server 4.3",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Real Time Module 15-SP6",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "openSUSE Leap 15.3",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "openSUSE Leap 15.4",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "openSUSE Leap 15.5",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "openSUSE Leap 15.6",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"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-2020-26558",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-26558"
},
{
"name": "CVE-2021-0129",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-0129"
},
{
"name": "CVE-2022-20368",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-20368"
},
{
"name": "CVE-2022-2964",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-2964"
},
{
"name": "CVE-2022-28748",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-28748"
},
{
"name": "CVE-2023-1582",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-1582"
},
{
"name": "CVE-2023-37453",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-37453"
},
{
"name": "CVE-2023-0160",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-0160"
},
{
"name": "CVE-2023-51780",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-51780"
},
{
"name": "CVE-2023-52458",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52458"
},
{
"name": "CVE-2024-26625",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26625"
},
{
"name": "CVE-2023-52594",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52594"
},
{
"name": "CVE-2024-26601",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26601"
},
{
"name": "CVE-2024-26585",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26585"
},
{
"name": "CVE-2024-26633",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26633"
},
{
"name": "CVE-2023-52435",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52435"
},
{
"name": "CVE-2023-52612",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52612"
},
{
"name": "CVE-2023-52591",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52591"
},
{
"name": "CVE-2024-26642",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26642"
},
{
"name": "CVE-2024-26654",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26654"
},
{
"name": "CVE-2023-52615",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52615"
},
{
"name": "CVE-2024-26659",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26659"
},
{
"name": "CVE-2024-26614",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26614"
},
{
"name": "CVE-2024-25739",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-25739"
},
{
"name": "CVE-2024-22099",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-22099"
},
{
"name": "CVE-2023-52623",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52623"
},
{
"name": "CVE-2023-52619",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52619"
},
{
"name": "CVE-2023-7042",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-7042"
},
{
"name": "CVE-2024-26584",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26584"
},
{
"name": "CVE-2024-26800",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26800"
},
{
"name": "CVE-2024-26769",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26769"
},
{
"name": "CVE-2024-26775",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26775"
},
{
"name": "CVE-2024-26704",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26704"
},
{
"name": "CVE-2023-52622",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52622"
},
{
"name": "CVE-2024-26671",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26671"
},
{
"name": "CVE-2024-26814",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26814"
},
{
"name": "CVE-2024-26685",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26685"
},
{
"name": "CVE-2024-26583",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26583"
},
{
"name": "CVE-2024-26737",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26737"
},
{
"name": "CVE-2024-26663",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26663"
},
{
"name": "CVE-2024-26805",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26805"
},
{
"name": "CVE-2024-26773",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26773"
},
{
"name": "CVE-2023-52618",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52618"
},
{
"name": "CVE-2023-52631",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52631"
},
{
"name": "CVE-2024-26793",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26793"
},
{
"name": "CVE-2023-52616",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52616"
},
{
"name": "CVE-2024-26750",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26750"
},
{
"name": "CVE-2024-26813",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26813"
},
{
"name": "CVE-2024-26764",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26764"
},
{
"name": "CVE-2024-27437",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27437"
},
{
"name": "CVE-2024-26735",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26735"
},
{
"name": "CVE-2024-26684",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26684"
},
{
"name": "CVE-2024-26679",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26679"
},
{
"name": "CVE-2024-26816",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26816"
},
{
"name": "CVE-2024-26726",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26726"
},
{
"name": "CVE-2023-52640",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52640"
},
{
"name": "CVE-2024-26676",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26676"
},
{
"name": "CVE-2024-26802",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26802"
},
{
"name": "CVE-2024-26760",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26760"
},
{
"name": "CVE-2024-26733",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26733"
},
{
"name": "CVE-2024-26815",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26815"
},
{
"name": "CVE-2023-52641",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52641"
},
{
"name": "CVE-2024-26772",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26772"
},
{
"name": "CVE-2024-26791",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26791"
},
{
"name": "CVE-2023-52635",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52635"
},
{
"name": "CVE-2024-26774",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26774"
},
{
"name": "CVE-2024-26643",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26643"
},
{
"name": "CVE-2024-26665",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26665"
},
{
"name": "CVE-2024-26714",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26714"
},
{
"name": "CVE-2024-26761",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26761"
},
{
"name": "CVE-2024-26673",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26673"
},
{
"name": "CVE-2024-26780",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26780"
},
{
"name": "CVE-2024-26731",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26731"
},
{
"name": "CVE-2024-26742",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26742"
},
{
"name": "CVE-2024-26641",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26641"
},
{
"name": "CVE-2024-0639",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-0639"
},
{
"name": "CVE-2024-26807",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26807"
},
{
"name": "CVE-2023-52503",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52503"
},
{
"name": "CVE-2023-52580",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52580"
},
{
"name": "CVE-2024-27393",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27393"
},
{
"name": "CVE-2024-26870",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26870"
},
{
"name": "CVE-2024-26863",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26863"
},
{
"name": "CVE-2024-27025",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27025"
},
{
"name": "CVE-2024-26845",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26845"
},
{
"name": "CVE-2024-27028",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27028"
},
{
"name": "CVE-2024-26861",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26861"
},
{
"name": "CVE-2024-26961",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26961"
},
{
"name": "CVE-2024-26978",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26978"
},
{
"name": "CVE-2024-27013",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27013"
},
{
"name": "CVE-2024-26989",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26989"
},
{
"name": "CVE-2024-26615",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26615"
},
{
"name": "CVE-2024-26846",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26846"
},
{
"name": "CVE-2024-26958",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26958"
},
{
"name": "CVE-2024-27008",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27008"
},
{
"name": "CVE-2024-26906",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26906"
},
{
"name": "CVE-2024-26925",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26925"
},
{
"name": "CVE-2024-26934",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26934"
},
{
"name": "CVE-2024-26957",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26957"
},
{
"name": "CVE-2024-26981",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26981"
},
{
"name": "CVE-2024-26889",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26889"
},
{
"name": "CVE-2024-27000",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27000"
},
{
"name": "CVE-2024-27388",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27388"
},
{
"name": "CVE-2024-27003",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27003"
},
{
"name": "CVE-2024-26883",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26883"
},
{
"name": "CVE-2024-26935",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26935"
},
{
"name": "CVE-2024-26882",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26882"
},
{
"name": "CVE-2024-27015",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27015"
},
{
"name": "CVE-2024-26984",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26984"
},
{
"name": "CVE-2024-27020",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27020"
},
{
"name": "CVE-2024-26973",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26973"
},
{
"name": "CVE-2024-26960",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26960"
},
{
"name": "CVE-2024-26996",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26996"
},
{
"name": "CVE-2024-26635",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26635"
},
{
"name": "CVE-2024-26950",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26950"
},
{
"name": "CVE-2024-26999",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26999"
},
{
"name": "CVE-2024-26924",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26924"
},
{
"name": "CVE-2024-24861",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-24861"
},
{
"name": "CVE-2024-27004",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27004"
},
{
"name": "CVE-2024-27002",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27002"
},
{
"name": "CVE-2024-26920",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26920"
},
{
"name": "CVE-2024-27016",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27016"
},
{
"name": "CVE-2024-26857",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26857"
},
{
"name": "CVE-2024-27001",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27001"
},
{
"name": "CVE-2024-26885",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26885"
},
{
"name": "CVE-2024-26878",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26878"
},
{
"name": "CVE-2024-26976",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26976"
},
{
"name": "CVE-2024-26983",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26983"
},
{
"name": "CVE-2024-26994",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26994"
},
{
"name": "CVE-2024-26636",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26636"
},
{
"name": "CVE-2024-26937",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26937"
},
{
"name": "CVE-2024-27030",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27030"
},
{
"name": "CVE-2024-27065",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27065"
},
{
"name": "CVE-2024-26997",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26997"
},
{
"name": "CVE-2024-26922",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26922"
},
{
"name": "CVE-2024-26884",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26884"
},
{
"name": "CVE-2024-27014",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27014"
},
{
"name": "CVE-2024-26862",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26862"
},
{
"name": "CVE-2024-26901",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26901"
},
{
"name": "CVE-2024-26992",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26992"
},
{
"name": "CVE-2024-27046",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27046"
},
{
"name": "CVE-2024-26903",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26903"
},
{
"name": "CVE-2024-26993",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26993"
},
{
"name": "CVE-2024-26951",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26951"
},
{
"name": "CVE-2024-26855",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26855"
},
{
"name": "CVE-2024-27019",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27019"
},
{
"name": "CVE-2024-26923",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26923"
},
{
"name": "CVE-2024-27022",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27022"
},
{
"name": "CVE-2024-26988",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26988"
},
{
"name": "CVE-2024-26650",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26650"
},
{
"name": "CVE-2024-26638",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26638"
},
{
"name": "CVE-2024-26826",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26826"
},
{
"name": "CVE-2024-26623",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26623"
},
{
"name": "CVE-2024-26632",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26632"
},
{
"name": "CVE-2023-52472",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52472"
},
{
"name": "CVE-2023-38417",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-38417"
},
{
"name": "CVE-2023-47210",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-47210"
},
{
"name": "CVE-2024-21823",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-21823"
},
{
"name": "CVE-2024-27062",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27062"
},
{
"name": "CVE-2021-47219",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47219"
},
{
"name": "CVE-2024-26866",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26866"
},
{
"name": "CVE-2021-47197",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47197"
},
{
"name": "CVE-2024-26856",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26856"
},
{
"name": "CVE-2024-26881",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26881"
},
{
"name": "CVE-2023-52652",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52652"
},
{
"name": "CVE-2024-27389",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27389"
},
{
"name": "CVE-2024-26982",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26982"
},
{
"name": "CVE-2024-26972",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26972"
},
{
"name": "CVE-2024-26830",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26830"
},
{
"name": "CVE-2024-27056",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27056"
},
{
"name": "CVE-2023-52645",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52645"
},
{
"name": "CVE-2024-26836",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26836"
},
{
"name": "CVE-2024-26933",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26933"
},
{
"name": "CVE-2023-52653",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52653"
},
{
"name": "CVE-2024-26739",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26739"
},
{
"name": "CVE-2024-23848",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-23848"
},
{
"name": "CVE-2024-26783",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26783"
},
{
"name": "CVE-2024-26948",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26948"
},
{
"name": "CVE-2024-26853",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26853"
},
{
"name": "CVE-2021-47194",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47194"
},
{
"name": "CVE-2021-47191",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47191"
},
{
"name": "CVE-2024-26656",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26656"
},
{
"name": "CVE-2024-26964",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26964"
},
{
"name": "CVE-2023-52882",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52882"
},
{
"name": "CVE-2024-26900",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26900"
},
{
"name": "CVE-2024-27399",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27399"
},
{
"name": "CVE-2024-27401",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27401"
},
{
"name": "CVE-2024-35848",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35848"
},
{
"name": "CVE-2024-35947",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35947"
},
{
"name": "CVE-2024-36017",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36017"
},
{
"name": "CVE-2024-36889",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36889"
},
{
"name": "CVE-2024-36902",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36902"
},
{
"name": "CVE-2024-36904",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36904"
},
{
"name": "CVE-2024-36916",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36916"
},
{
"name": "CVE-2024-36919",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36919"
},
{
"name": "CVE-2024-36934",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36934"
},
{
"name": "CVE-2024-36939",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36939"
},
{
"name": "CVE-2024-36940",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36940"
},
{
"name": "CVE-2024-36941",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36941"
},
{
"name": "CVE-2024-36946",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36946"
},
{
"name": "CVE-2024-36950",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36950"
},
{
"name": "CVE-2024-36957",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36957"
},
{
"name": "CVE-2024-36959",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36959"
},
{
"name": "CVE-2021-47388",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47388"
},
{
"name": "CVE-2021-47395",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47395"
},
{
"name": "CVE-2021-47399",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47399"
},
{
"name": "CVE-2021-47402",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47402"
},
{
"name": "CVE-2021-47403",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47403"
},
{
"name": "CVE-2021-47405",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47405"
},
{
"name": "CVE-2021-47438",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47438"
},
{
"name": "CVE-2021-47441",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47441"
},
{
"name": "CVE-2021-47468",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47468"
},
{
"name": "CVE-2021-47501",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47501"
},
{
"name": "CVE-2021-47506",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47506"
},
{
"name": "CVE-2021-47516",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47516"
},
{
"name": "CVE-2021-47520",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47520"
},
{
"name": "CVE-2021-47542",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47542"
},
{
"name": "CVE-2021-47559",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47559"
},
{
"name": "CVE-2023-52656",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52656"
},
{
"name": "CVE-2023-52657",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52657"
},
{
"name": "CVE-2023-52659",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52659"
},
{
"name": "CVE-2023-52660",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52660"
},
{
"name": "CVE-2023-52661",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52661"
},
{
"name": "CVE-2023-52662",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52662"
},
{
"name": "CVE-2023-52664",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52664"
},
{
"name": "CVE-2023-52669",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52669"
},
{
"name": "CVE-2023-52671",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52671"
},
{
"name": "CVE-2023-52674",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52674"
},
{
"name": "CVE-2023-52676",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52676"
},
{
"name": "CVE-2023-52678",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52678"
},
{
"name": "CVE-2023-52679",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52679"
},
{
"name": "CVE-2023-52680",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52680"
},
{
"name": "CVE-2023-52683",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52683"
},
{
"name": "CVE-2023-52685",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52685"
},
{
"name": "CVE-2023-52686",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52686"
},
{
"name": "CVE-2023-52690",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52690"
},
{
"name": "CVE-2023-52691",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52691"
},
{
"name": "CVE-2023-52692",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52692"
},
{
"name": "CVE-2023-52693",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52693"
},
{
"name": "CVE-2023-52694",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52694"
},
{
"name": "CVE-2023-52696",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52696"
},
{
"name": "CVE-2023-52698",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52698"
},
{
"name": "CVE-2023-52699",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52699"
},
{
"name": "CVE-2023-52743",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52743"
},
{
"name": "CVE-2023-52753",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52753"
},
{
"name": "CVE-2023-52754",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52754"
},
{
"name": "CVE-2023-52757",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52757"
},
{
"name": "CVE-2023-52759",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52759"
},
{
"name": "CVE-2023-52763",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52763"
},
{
"name": "CVE-2023-52764",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52764"
},
{
"name": "CVE-2023-52766",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52766"
},
{
"name": "CVE-2023-52773",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52773"
},
{
"name": "CVE-2023-52774",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52774"
},
{
"name": "CVE-2023-52777",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52777"
},
{
"name": "CVE-2023-52781",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52781"
},
{
"name": "CVE-2023-52788",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52788"
},
{
"name": "CVE-2023-52789",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52789"
},
{
"name": "CVE-2023-52791",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52791"
},
{
"name": "CVE-2023-52795",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52795"
},
{
"name": "CVE-2023-52796",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52796"
},
{
"name": "CVE-2023-52798",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52798"
},
{
"name": "CVE-2023-52799",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52799"
},
{
"name": "CVE-2023-52800",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52800"
},
{
"name": "CVE-2023-52803",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52803"
},
{
"name": "CVE-2023-52804",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52804"
},
{
"name": "CVE-2023-52805",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52805"
},
{
"name": "CVE-2023-52806",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52806"
},
{
"name": "CVE-2023-52807",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52807"
},
{
"name": "CVE-2023-52808",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52808"
},
{
"name": "CVE-2023-52809",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52809"
},
{
"name": "CVE-2023-52810",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52810"
},
{
"name": "CVE-2023-52811",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52811"
},
{
"name": "CVE-2023-52814",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52814"
},
{
"name": "CVE-2023-52815",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52815"
},
{
"name": "CVE-2023-52816",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52816"
},
{
"name": "CVE-2023-52817",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52817"
},
{
"name": "CVE-2023-52818",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52818"
},
{
"name": "CVE-2023-52819",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52819"
},
{
"name": "CVE-2023-52821",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52821"
},
{
"name": "CVE-2023-52825",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52825"
},
{
"name": "CVE-2023-52826",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52826"
},
{
"name": "CVE-2023-52832",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52832"
},
{
"name": "CVE-2023-52833",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52833"
},
{
"name": "CVE-2023-52834",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52834"
},
{
"name": "CVE-2023-52838",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52838"
},
{
"name": "CVE-2023-52840",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52840"
},
{
"name": "CVE-2023-52841",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52841"
},
{
"name": "CVE-2023-52844",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52844"
},
{
"name": "CVE-2023-52847",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52847"
},
{
"name": "CVE-2023-52851",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52851"
},
{
"name": "CVE-2023-52853",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52853"
},
{
"name": "CVE-2023-52854",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52854"
},
{
"name": "CVE-2023-52855",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52855"
},
{
"name": "CVE-2023-52856",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52856"
},
{
"name": "CVE-2023-52858",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52858"
},
{
"name": "CVE-2023-52860",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52860"
},
{
"name": "CVE-2023-52861",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52861"
},
{
"name": "CVE-2023-52864",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52864"
},
{
"name": "CVE-2023-52865",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52865"
},
{
"name": "CVE-2023-52867",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52867"
},
{
"name": "CVE-2023-52868",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52868"
},
{
"name": "CVE-2023-52870",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52870"
},
{
"name": "CVE-2023-52871",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52871"
},
{
"name": "CVE-2023-52872",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52872"
},
{
"name": "CVE-2023-52873",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52873"
},
{
"name": "CVE-2023-52875",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52875"
},
{
"name": "CVE-2023-52876",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52876"
},
{
"name": "CVE-2023-52877",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52877"
},
{
"name": "CVE-2023-52878",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52878"
},
{
"name": "CVE-2023-52880",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52880"
},
{
"name": "CVE-2024-26758",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26758"
},
{
"name": "CVE-2024-26822",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26822"
},
{
"name": "CVE-2024-26921",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26921"
},
{
"name": "CVE-2024-26928",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26928"
},
{
"name": "CVE-2024-269355",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-269355"
},
{
"name": "CVE-2024-26938",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26938"
},
{
"name": "CVE-2024-26940",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26940"
},
{
"name": "CVE-2024-26943",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26943"
},
{
"name": "CVE-2024-27395",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27395"
},
{
"name": "CVE-2024-27396",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27396"
},
{
"name": "CVE-2024-27400",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27400"
},
{
"name": "CVE-2024-27405",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27405"
},
{
"name": "CVE-2024-27410",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27410"
},
{
"name": "CVE-2024-27412",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27412"
},
{
"name": "CVE-2024-27413",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27413"
},
{
"name": "CVE-2024-27416",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27416"
},
{
"name": "CVE-2024-27417",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27417"
},
{
"name": "CVE-2024-27419",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27419"
},
{
"name": "CVE-2024-27431",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27431"
},
{
"name": "CVE-2024-27435",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27435"
},
{
"name": "CVE-2024-27436",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27436"
},
{
"name": "CVE-2024-35789",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35789"
},
{
"name": "CVE-2024-35791",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35791"
},
{
"name": "CVE-2024-35796",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35796"
},
{
"name": "CVE-2024-35799",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35799"
},
{
"name": "CVE-2024-35801",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35801"
},
{
"name": "CVE-2024-35804",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35804"
},
{
"name": "CVE-2024-35806",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35806"
},
{
"name": "CVE-2024-35809",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35809"
},
{
"name": "CVE-2024-35811",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35811"
},
{
"name": "CVE-2024-35812",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35812"
},
{
"name": "CVE-2024-35813",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35813"
},
{
"name": "CVE-2024-35815",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35815"
},
{
"name": "CVE-2024-35817",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35817"
},
{
"name": "CVE-2024-35821",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35821"
},
{
"name": "CVE-2024-35822",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35822"
},
{
"name": "CVE-2024-35823",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35823"
},
{
"name": "CVE-2024-35825",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35825"
},
{
"name": "CVE-2024-35828",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35828"
},
{
"name": "CVE-2024-35829",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35829"
},
{
"name": "CVE-2024-35830",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35830"
},
{
"name": "CVE-2024-35833",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35833"
},
{
"name": "CVE-2024-35845",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35845"
},
{
"name": "CVE-2024-35847",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35847"
},
{
"name": "CVE-2024-35849",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35849"
},
{
"name": "CVE-2024-35851",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35851"
},
{
"name": "CVE-2024-35852",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35852"
},
{
"name": "CVE-2024-35854",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35854"
},
{
"name": "CVE-2024-35860",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35860"
},
{
"name": "CVE-2024-35861",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35861"
},
{
"name": "CVE-2024-35862",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35862"
},
{
"name": "CVE-2024-35863",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35863"
},
{
"name": "CVE-2024-35864",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35864"
},
{
"name": "CVE-2024-35865",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35865"
},
{
"name": "CVE-2024-35866",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35866"
},
{
"name": "CVE-2024-35867",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35867"
},
{
"name": "CVE-2024-35868",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35868"
},
{
"name": "CVE-2024-35872",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35872"
},
{
"name": "CVE-2024-35875",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35875"
},
{
"name": "CVE-2024-35877",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35877"
},
{
"name": "CVE-2024-35878",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35878"
},
{
"name": "CVE-2024-35879",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35879"
},
{
"name": "CVE-2024-35885",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35885"
},
{
"name": "CVE-2024-35887",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35887"
},
{
"name": "CVE-2024-35895",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35895"
},
{
"name": "CVE-2024-35901",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35901"
},
{
"name": "CVE-2024-35904",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35904"
},
{
"name": "CVE-2024-35905",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35905"
},
{
"name": "CVE-2024-35907",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35907"
},
{
"name": "CVE-2024-35912",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35912"
},
{
"name": "CVE-2024-35914",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35914"
},
{
"name": "CVE-2024-35915",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35915"
},
{
"name": "CVE-2024-35922",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35922"
},
{
"name": "CVE-2024-35924",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35924"
},
{
"name": "CVE-2024-35930",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35930"
},
{
"name": "CVE-2024-35932",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35932"
},
{
"name": "CVE-2024-35933",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35933"
},
{
"name": "CVE-2024-35935",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35935"
},
{
"name": "CVE-2024-35936",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35936"
},
{
"name": "CVE-2024-35938",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35938"
},
{
"name": "CVE-2024-35940",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35940"
},
{
"name": "CVE-2024-35943",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35943"
},
{
"name": "CVE-2024-35944",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35944"
},
{
"name": "CVE-2024-35950",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35950"
},
{
"name": "CVE-2024-35951",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35951"
},
{
"name": "CVE-2024-35952",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35952"
},
{
"name": "CVE-2024-35955",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35955"
},
{
"name": "CVE-2024-35959",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35959"
},
{
"name": "CVE-2024-35963",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35963"
},
{
"name": "CVE-2024-35964",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35964"
},
{
"name": "CVE-2024-35965",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35965"
},
{
"name": "CVE-2024-35966",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35966"
},
{
"name": "CVE-2024-35967",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35967"
},
{
"name": "CVE-2024-35969",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35969"
},
{
"name": "CVE-2024-35973",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35973"
},
{
"name": "CVE-2024-35976",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35976"
},
{
"name": "CVE-2024-35978",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35978"
},
{
"name": "CVE-2024-35982",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35982"
},
{
"name": "CVE-2024-35984",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35984"
},
{
"name": "CVE-2024-35989",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35989"
},
{
"name": "CVE-2024-35990",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35990"
},
{
"name": "CVE-2024-35998",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35998"
},
{
"name": "CVE-2024-35999",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35999"
},
{
"name": "CVE-2024-36006",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36006"
},
{
"name": "CVE-2024-36007",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36007"
},
{
"name": "CVE-2024-36012",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36012"
},
{
"name": "CVE-2024-36014",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36014"
},
{
"name": "CVE-2024-36015",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36015"
},
{
"name": "CVE-2024-36016",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36016"
},
{
"name": "CVE-2024-36026",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36026"
},
{
"name": "CVE-2024-36029",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36029"
},
{
"name": "CVE-2024-36032",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36032"
},
{
"name": "CVE-2024-36880",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36880"
},
{
"name": "CVE-2024-36893",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36893"
},
{
"name": "CVE-2024-36896",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36896"
},
{
"name": "CVE-2024-36897",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36897"
},
{
"name": "CVE-2024-36906",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36906"
},
{
"name": "CVE-2024-36918",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36918"
},
{
"name": "CVE-2024-36924",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36924"
},
{
"name": "CVE-2024-36926",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36926"
},
{
"name": "CVE-2024-36928",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36928"
},
{
"name": "CVE-2024-36931",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36931"
},
{
"name": "CVE-2024-36938",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36938"
},
{
"name": "CVE-2024-36942",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36942"
},
{
"name": "CVE-2024-36944",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36944"
},
{
"name": "CVE-2024-36947",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36947"
},
{
"name": "CVE-2024-36952",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36952"
},
{
"name": "CVE-2024-36955",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36955"
},
{
"name": "CVE-2023-52667",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52667"
},
{
"name": "CVE-2023-52658",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52658"
},
{
"name": "CVE-2023-52663",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52663"
},
{
"name": "CVE-2023-52670",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52670"
},
{
"name": "CVE-2023-52673",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52673"
},
{
"name": "CVE-2023-52675",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52675"
},
{
"name": "CVE-2023-52681",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52681"
},
{
"name": "CVE-2023-52687",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52687"
},
{
"name": "CVE-2023-52695",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52695"
},
{
"name": "CVE-2023-52697",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52697"
},
{
"name": "CVE-2023-52771",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52771"
},
{
"name": "CVE-2023-52772",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52772"
},
{
"name": "CVE-2023-6238",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-6238"
},
{
"name": "CVE-2024-26611",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26611"
},
{
"name": "CVE-2024-26652",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26652"
},
{
"name": "CVE-2024-26657",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26657"
},
{
"name": "CVE-2024-26674",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26674"
},
{
"name": "CVE-2024-26740",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26740"
},
{
"name": "CVE-2024-26756",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26756"
},
{
"name": "CVE-2024-26786",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26786"
},
{
"name": "CVE-2024-26794",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26794"
},
{
"name": "CVE-2024-26832",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26832"
},
{
"name": "CVE-2024-26844",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26844"
},
{
"name": "CVE-2024-26854",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26854"
},
{
"name": "CVE-2024-26858",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26858"
},
{
"name": "CVE-2024-26860",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26860"
},
{
"name": "CVE-2024-26868",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26868"
},
{
"name": "CVE-2024-26899",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26899"
},
{
"name": "CVE-2024-26909",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26909"
},
{
"name": "CVE-2024-26932",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26932"
},
{
"name": "CVE-2024-26945",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26945"
},
{
"name": "CVE-2024-26946",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26946"
},
{
"name": "CVE-2024-26949",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26949"
},
{
"name": "CVE-2024-26962",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26962"
},
{
"name": "CVE-2024-26963",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26963"
},
{
"name": "CVE-2024-26986",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26986"
},
{
"name": "CVE-2024-26990",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26990"
},
{
"name": "CVE-2024-26991",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26991"
},
{
"name": "CVE-2024-26995",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26995"
},
{
"name": "CVE-2024-27027",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27027"
},
{
"name": "CVE-2024-27031",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27031"
},
{
"name": "CVE-2024-27057",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27057"
},
{
"name": "CVE-2024-27067",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27067"
},
{
"name": "CVE-2024-27080",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27080"
},
{
"name": "CVE-2024-27408",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27408"
},
{
"name": "CVE-2024-27411",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27411"
},
{
"name": "CVE-2024-27418",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27418"
},
{
"name": "CVE-2024-27432",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27432"
},
{
"name": "CVE-2024-27434",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27434"
},
{
"name": "CVE-2024-35784",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35784"
},
{
"name": "CVE-2024-35786",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35786"
},
{
"name": "CVE-2024-35788",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35788"
},
{
"name": "CVE-2024-35790",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35790"
},
{
"name": "CVE-2024-35794",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35794"
},
{
"name": "CVE-2024-35795",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35795"
},
{
"name": "CVE-2024-35800",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35800"
},
{
"name": "CVE-2024-35803",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35803"
},
{
"name": "CVE-2024-35808",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35808"
},
{
"name": "CVE-2024-35810",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35810"
},
{
"name": "CVE-2024-35814",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35814"
},
{
"name": "CVE-2024-35819",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35819"
},
{
"name": "CVE-2024-35824",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35824"
},
{
"name": "CVE-2024-35834",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35834"
},
{
"name": "CVE-2024-35835",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35835"
},
{
"name": "CVE-2024-35836",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35836"
},
{
"name": "CVE-2024-35837",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35837"
},
{
"name": "CVE-2024-35838",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35838"
},
{
"name": "CVE-2024-35841",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35841"
},
{
"name": "CVE-2024-35842",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35842"
},
{
"name": "CVE-2024-35850",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35850"
},
{
"name": "CVE-2024-35883",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35883"
},
{
"name": "CVE-2024-35889",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35889"
},
{
"name": "CVE-2024-35891",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35891"
},
{
"name": "CVE-2024-35903",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35903"
},
{
"name": "CVE-2024-35909",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35909"
},
{
"name": "CVE-2024-35911",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35911"
},
{
"name": "CVE-2024-35916",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35916"
},
{
"name": "CVE-2024-35917",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35917"
},
{
"name": "CVE-2024-35921",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35921"
},
{
"name": "CVE-2024-35927",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35927"
},
{
"name": "CVE-2024-35928",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35928"
},
{
"name": "CVE-2024-35931",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35931"
},
{
"name": "CVE-2024-35937",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35937"
},
{
"name": "CVE-2024-35945",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35945"
},
{
"name": "CVE-2024-35946",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35946"
},
{
"name": "CVE-2024-35953",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35953"
},
{
"name": "CVE-2024-35954",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35954"
},
{
"name": "CVE-2024-35956",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35956"
},
{
"name": "CVE-2024-35958",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35958"
},
{
"name": "CVE-2024-35960",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35960"
},
{
"name": "CVE-2024-35961",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35961"
},
{
"name": "CVE-2024-35971",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35971"
},
{
"name": "CVE-2024-35972",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35972"
},
{
"name": "CVE-2024-35974",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35974"
},
{
"name": "CVE-2024-35975",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35975"
},
{
"name": "CVE-2024-35977",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35977"
},
{
"name": "CVE-2024-35981",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35981"
},
{
"name": "CVE-2024-35986",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35986"
},
{
"name": "CVE-2024-35991",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35991"
},
{
"name": "CVE-2024-35992",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35992"
},
{
"name": "CVE-2024-35995",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35995"
},
{
"name": "CVE-2024-35997",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35997"
},
{
"name": "CVE-2024-36002",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36002"
},
{
"name": "CVE-2024-36009",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36009"
},
{
"name": "CVE-2024-36011",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36011"
},
{
"name": "CVE-2024-36013",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36013"
},
{
"name": "CVE-2024-36018",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36018"
},
{
"name": "CVE-2024-36019",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36019"
},
{
"name": "CVE-2024-36020",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36020"
},
{
"name": "CVE-2024-36021",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36021"
},
{
"name": "CVE-2024-36025",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36025"
},
{
"name": "CVE-2024-36030",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36030"
},
{
"name": "CVE-2024-36885",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36885"
},
{
"name": "CVE-2024-36890",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36890"
},
{
"name": "CVE-2024-36891",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36891"
},
{
"name": "CVE-2024-36894",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36894"
},
{
"name": "CVE-2024-36895",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36895"
},
{
"name": "CVE-2024-36898",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36898"
},
{
"name": "CVE-2024-36921",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36921"
},
{
"name": "CVE-2024-36922",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36922"
},
{
"name": "CVE-2024-36930",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36930"
},
{
"name": "CVE-2024-36936",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36936"
},
{
"name": "CVE-2024-36949",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36949"
},
{
"name": "CVE-2024-36951",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36951"
},
{
"name": "CVE-2023-52672",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52672"
},
{
"name": "CVE-2024-27414",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27414"
},
{
"name": "CVE-2024-35805",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35805"
},
{
"name": "CVE-2024-35807",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35807"
},
{
"name": "CVE-2024-35853",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35853"
},
{
"name": "CVE-2024-35855",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35855"
},
{
"name": "CVE-2024-35884",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35884"
},
{
"name": "CVE-2024-35886",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35886"
},
{
"name": "CVE-2024-35893",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35893"
},
{
"name": "CVE-2024-35896",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35896"
},
{
"name": "CVE-2024-35898",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35898"
},
{
"name": "CVE-2024-35899",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35899"
},
{
"name": "CVE-2024-35900",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35900"
},
{
"name": "CVE-2024-35925",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35925"
},
{
"name": "CVE-2024-35934",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35934"
},
{
"name": "CVE-2024-35962",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35962"
},
{
"name": "CVE-2024-36004",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36004"
},
{
"name": "CVE-2024-36005",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36005"
},
{
"name": "CVE-2024-36008",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36008"
},
{
"name": "CVE-2024-36288",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36288"
},
{
"name": "CVE-2024-36960",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36960"
},
{
"name": "CVE-2024-36964",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36964"
},
{
"name": "CVE-2024-36971",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36971"
},
{
"name": "CVE-2024-37353",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-37353"
},
{
"name": "CVE-2024-38381",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38381"
},
{
"name": "CVE-2024-38549",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38549"
},
{
"name": "CVE-2024-38552",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38552"
},
{
"name": "CVE-2024-38558",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38558"
},
{
"name": "CVE-2024-38559",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38559"
},
{
"name": "CVE-2024-38560",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38560"
},
{
"name": "CVE-2024-38565",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38565"
},
{
"name": "CVE-2024-38567",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38567"
},
{
"name": "CVE-2024-38578",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38578"
},
{
"name": "CVE-2024-38579",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38579"
},
{
"name": "CVE-2024-38582",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38582"
},
{
"name": "CVE-2024-38583",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38583"
},
{
"name": "CVE-2024-38587",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38587"
},
{
"name": "CVE-2024-38598",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38598"
},
{
"name": "CVE-2024-38599",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38599"
},
{
"name": "CVE-2024-38601",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38601"
},
{
"name": "CVE-2024-38618",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38618"
},
{
"name": "CVE-2024-38621",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38621"
},
{
"name": "CVE-2024-38627",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38627"
},
{
"name": "CVE-2024-38633",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38633"
},
{
"name": "CVE-2024-38634",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38634"
},
{
"name": "CVE-2024-38659",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38659"
},
{
"name": "CVE-2024-38780",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38780"
},
{
"name": "CVE-2024-26944",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26944"
},
{
"name": "CVE-2024-27064",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27064"
},
{
"name": "CVE-2024-35827",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35827"
},
{
"name": "CVE-2024-35831",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35831"
},
{
"name": "CVE-2024-35843",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35843"
},
{
"name": "CVE-2023-52813",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52813"
},
{
"name": "CVE-2023-52835",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52835"
},
{
"name": "CVE-2023-52881",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52881"
},
{
"name": "CVE-2024-35890",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35890"
},
{
"name": "CVE-2021-47103",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47103"
},
{
"name": "CVE-2021-47432",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47432"
},
{
"name": "CVE-2021-47580",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47580"
},
{
"name": "CVE-2021-47582",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47582"
},
{
"name": "CVE-2021-47597",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47597"
},
{
"name": "CVE-2021-47600",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47600"
},
{
"name": "CVE-2021-47619",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47619"
},
{
"name": "CVE-2022-48713",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48713"
},
{
"name": "CVE-2022-48730",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48730"
},
{
"name": "CVE-2022-48732",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48732"
},
{
"name": "CVE-2022-48749",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48749"
},
{
"name": "CVE-2022-48756",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48756"
},
{
"name": "CVE-2022-48772",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48772"
},
{
"name": "CVE-2023-52735",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52735"
},
{
"name": "CVE-2023-52762",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52762"
},
{
"name": "CVE-2023-52784",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52784"
},
{
"name": "CVE-2023-52787",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52787"
},
{
"name": "CVE-2023-52837",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52837"
},
{
"name": "CVE-2023-52843",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52843"
},
{
"name": "CVE-2023-52845",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52845"
},
{
"name": "CVE-2023-52869",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52869"
},
{
"name": "CVE-2023-52884",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52884"
},
{
"name": "CVE-2024-26842",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26842"
},
{
"name": "CVE-2024-33619",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-33619"
},
{
"name": "CVE-2024-35247",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35247"
},
{
"name": "CVE-2024-35857",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35857"
},
{
"name": "CVE-2024-35979",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35979"
},
{
"name": "CVE-2024-36477",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36477"
},
{
"name": "CVE-2024-36478",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36478"
},
{
"name": "CVE-2024-36479",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36479"
},
{
"name": "CVE-2024-36592",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36592"
},
{
"name": "CVE-2024-36899",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36899"
},
{
"name": "CVE-2024-36900",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36900"
},
{
"name": "CVE-2024-36915",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36915"
},
{
"name": "CVE-2024-36917",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36917"
},
{
"name": "CVE-2024-36923",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36923"
},
{
"name": "CVE-2024-36937",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36937"
},
{
"name": "CVE-2024-36945",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36945"
},
{
"name": "CVE-2024-36965",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36965"
},
{
"name": "CVE-2024-36967",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36967"
},
{
"name": "CVE-2024-36969",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36969"
},
{
"name": "CVE-2024-36975",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36975"
},
{
"name": "CVE-2024-36978",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36978"
},
{
"name": "CVE-2024-37021",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-37021"
},
{
"name": "CVE-2024-37078",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-37078"
},
{
"name": "CVE-2024-37354",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-37354"
},
{
"name": "CVE-2024-38388",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38388"
},
{
"name": "CVE-2024-38390",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38390"
},
{
"name": "CVE-2024-38540",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38540"
},
{
"name": "CVE-2024-38541",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38541"
},
{
"name": "CVE-2024-38544",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38544"
},
{
"name": "CVE-2024-38546",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38546"
},
{
"name": "CVE-2024-38547",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38547"
},
{
"name": "CVE-2024-38548",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38548"
},
{
"name": "CVE-2024-38550",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38550"
},
{
"name": "CVE-2024-38553",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38553"
},
{
"name": "CVE-2024-38555",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38555"
},
{
"name": "CVE-2024-38556",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38556"
},
{
"name": "CVE-2024-38557",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38557"
},
{
"name": "CVE-2024-38564",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38564"
},
{
"name": "CVE-2024-38568",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38568"
},
{
"name": "CVE-2024-38571",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38571"
},
{
"name": "CVE-2024-38573",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38573"
},
{
"name": "CVE-2024-38580",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38580"
},
{
"name": "CVE-2024-38581",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38581"
},
{
"name": "CVE-2024-38590",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38590"
},
{
"name": "CVE-2024-38591",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38591"
},
{
"name": "CVE-2024-38594",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38594"
},
{
"name": "CVE-2024-38597",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38597"
},
{
"name": "CVE-2024-38600",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38600"
},
{
"name": "CVE-2024-38603",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38603"
},
{
"name": "CVE-2024-38605",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38605"
},
{
"name": "CVE-2024-38608",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38608"
},
{
"name": "CVE-2024-38616",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38616"
},
{
"name": "CVE-2024-38619",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38619"
},
{
"name": "CVE-2024-38630",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38630"
},
{
"name": "CVE-2024-38635",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38635"
},
{
"name": "CVE-2024-38661",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38661"
},
{
"name": "CVE-2024-39301",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39301"
},
{
"name": "CVE-2024-39468",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39468"
},
{
"name": "CVE-2024-39469",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39469"
},
{
"name": "CVE-2024-39471",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39471"
},
{
"name": "CVE-2021-47547",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47547"
},
{
"name": "CVE-2024-38610",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38610"
},
{
"name": "CVE-2024-39475",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39475"
},
{
"name": "CVE-2024-26661",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26661"
},
{
"name": "CVE-2024-26691",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26691"
},
{
"name": "CVE-2024-26734",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26734"
},
{
"name": "CVE-2024-27012",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27012"
},
{
"name": "CVE-2024-35880",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35880"
},
{
"name": "CVE-2024-35892",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35892"
},
{
"name": "CVE-2024-35908",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35908"
},
{
"name": "CVE-2024-35926",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35926"
},
{
"name": "CVE-2024-35942",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35942"
},
{
"name": "CVE-2024-35957",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35957"
},
{
"name": "CVE-2024-35970",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35970"
},
{
"name": "CVE-2024-36024",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36024"
},
{
"name": "CVE-2024-38543",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38543"
},
{
"name": "CVE-2024-38586",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38586"
},
{
"name": "CVE-2024-38663",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38663"
},
{
"name": "CVE-2024-25741",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-25741"
},
{
"name": "CVE-2024-36973",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36973"
},
{
"name": "CVE-2024-36974",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36974"
},
{
"name": "CVE-2024-38615",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38615"
},
{
"name": "CVE-2024-39276",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39276"
},
{
"name": "CVE-2024-39371",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39371"
},
{
"name": "CVE-2024-39474",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39474"
},
{
"name": "CVE-2024-39482",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39482"
},
{
"name": "CVE-2024-39487",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39487"
},
{
"name": "CVE-2024-39488",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39488"
},
{
"name": "CVE-2024-39493",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39493"
},
{
"name": "CVE-2024-39494",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39494"
},
{
"name": "CVE-2024-39496",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39496"
},
{
"name": "CVE-2024-39499",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39499"
},
{
"name": "CVE-2024-39500",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39500"
},
{
"name": "CVE-2024-39501",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39501"
},
{
"name": "CVE-2024-39502",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39502"
},
{
"name": "CVE-2024-39505",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39505"
},
{
"name": "CVE-2024-39506",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39506"
},
{
"name": "CVE-2024-39507",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39507"
},
{
"name": "CVE-2024-39509",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39509"
},
{
"name": "CVE-2024-40900",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40900"
},
{
"name": "CVE-2024-40901",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40901"
},
{
"name": "CVE-2024-40902",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40902"
},
{
"name": "CVE-2024-40903",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40903"
},
{
"name": "CVE-2024-40904",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40904"
},
{
"name": "CVE-2024-40906",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40906"
},
{
"name": "CVE-2024-40908",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40908"
},
{
"name": "CVE-2024-40911",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40911"
},
{
"name": "CVE-2024-40912",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40912"
},
{
"name": "CVE-2024-40916",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40916"
},
{
"name": "CVE-2024-40919",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40919"
},
{
"name": "CVE-2024-40924",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40924"
},
{
"name": "CVE-2024-40927",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40927"
},
{
"name": "CVE-2024-40929",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40929"
},
{
"name": "CVE-2024-40931",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40931"
},
{
"name": "CVE-2024-40932",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40932"
},
{
"name": "CVE-2024-40934",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40934"
},
{
"name": "CVE-2024-40935",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40935"
},
{
"name": "CVE-2024-40937",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40937"
},
{
"name": "CVE-2024-40940",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40940"
},
{
"name": "CVE-2024-40941",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40941"
},
{
"name": "CVE-2024-40942",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40942"
},
{
"name": "CVE-2024-40943",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40943"
},
{
"name": "CVE-2024-40945",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40945"
},
{
"name": "CVE-2024-40947",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40947"
},
{
"name": "CVE-2024-40948",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40948"
},
{
"name": "CVE-2024-40953",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40953"
},
{
"name": "CVE-2024-40954",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40954"
},
{
"name": "CVE-2024-40956",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40956"
},
{
"name": "CVE-2024-40958",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40958"
},
{
"name": "CVE-2024-40959",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40959"
},
{
"name": "CVE-2024-40960",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40960"
},
{
"name": "CVE-2024-40961",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40961"
},
{
"name": "CVE-2024-40966",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40966"
},
{
"name": "CVE-2024-40967",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40967"
},
{
"name": "CVE-2024-40970",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40970"
},
{
"name": "CVE-2024-40976",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40976"
},
{
"name": "CVE-2024-40977",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40977"
},
{
"name": "CVE-2024-40978",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40978"
},
{
"name": "CVE-2024-40981",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40981"
},
{
"name": "CVE-2024-40984",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40984"
},
{
"name": "CVE-2024-40987",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40987"
},
{
"name": "CVE-2024-40988",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40988"
},
{
"name": "CVE-2024-40989",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40989"
},
{
"name": "CVE-2024-40990",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40990"
},
{
"name": "CVE-2024-40994",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40994"
},
{
"name": "CVE-2024-40995",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40995"
},
{
"name": "CVE-2024-41002",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41002"
},
{
"name": "CVE-2024-41004",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41004"
},
{
"name": "CVE-2024-41006",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41006"
},
{
"name": "CVE-2023-52749",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52749"
},
{
"name": "CVE-2023-52750",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52750"
},
{
"name": "CVE-2023-52765",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52765"
},
{
"name": "CVE-2023-52767",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52767"
},
{
"name": "CVE-2023-52768",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52768"
},
{
"name": "CVE-2023-52769",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52769"
},
{
"name": "CVE-2023-52776",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52776"
},
{
"name": "CVE-2023-52780",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52780"
},
{
"name": "CVE-2023-52782",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52782"
},
{
"name": "CVE-2023-52783",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52783"
},
{
"name": "CVE-2023-52786",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52786"
},
{
"name": "CVE-2023-52792",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52792"
},
{
"name": "CVE-2023-52794",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52794"
},
{
"name": "CVE-2023-52801",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52801"
},
{
"name": "CVE-2023-52812",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52812"
},
{
"name": "CVE-2023-52827",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52827"
},
{
"name": "CVE-2023-52829",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52829"
},
{
"name": "CVE-2023-52836",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52836"
},
{
"name": "CVE-2023-52842",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52842"
},
{
"name": "CVE-2023-52849",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52849"
},
{
"name": "CVE-2023-52850",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52850"
},
{
"name": "CVE-2023-52857",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52857"
},
{
"name": "CVE-2023-52862",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52862"
},
{
"name": "CVE-2023-52863",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52863"
},
{
"name": "CVE-2023-52866",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52866"
},
{
"name": "CVE-2023-52874",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52874"
},
{
"name": "CVE-2023-52879",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52879"
},
{
"name": "CVE-2023-52883",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52883"
},
{
"name": "CVE-2024-26767",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26767"
},
{
"name": "CVE-2024-34777",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-34777"
},
{
"name": "CVE-2024-36010",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36010"
},
{
"name": "CVE-2024-36281",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36281"
},
{
"name": "CVE-2024-36882",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36882"
},
{
"name": "CVE-2024-36887",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36887"
},
{
"name": "CVE-2024-36903",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36903"
},
{
"name": "CVE-2024-36935",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36935"
},
{
"name": "CVE-2024-36962",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36962"
},
{
"name": "CVE-2024-36972",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36972"
},
{
"name": "CVE-2024-36977",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36977"
},
{
"name": "CVE-2024-38384",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38384"
},
{
"name": "CVE-2024-38385",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38385"
},
{
"name": "CVE-2024-38391",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38391"
},
{
"name": "CVE-2024-38539",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38539"
},
{
"name": "CVE-2024-38551",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38551"
},
{
"name": "CVE-2024-38554",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38554"
},
{
"name": "CVE-2024-38562",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38562"
},
{
"name": "CVE-2024-38566",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38566"
},
{
"name": "CVE-2024-38569",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38569"
},
{
"name": "CVE-2024-38570",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38570"
},
{
"name": "CVE-2024-38572",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38572"
},
{
"name": "CVE-2024-38575",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38575"
},
{
"name": "CVE-2024-38588",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38588"
},
{
"name": "CVE-2024-38592",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38592"
},
{
"name": "CVE-2024-38595",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38595"
},
{
"name": "CVE-2024-38602",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38602"
},
{
"name": "CVE-2024-38611",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38611"
},
{
"name": "CVE-2024-38617",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38617"
},
{
"name": "CVE-2024-38622",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38622"
},
{
"name": "CVE-2024-38628",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38628"
},
{
"name": "CVE-2024-38629",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38629"
},
{
"name": "CVE-2024-38636",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38636"
},
{
"name": "CVE-2024-38664",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38664"
},
{
"name": "CVE-2024-39277",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39277"
},
{
"name": "CVE-2024-39291",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39291"
},
{
"name": "CVE-2024-39296",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39296"
},
{
"name": "CVE-2024-39362",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39362"
},
{
"name": "CVE-2024-39463",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39463"
},
{
"name": "CVE-2024-39466",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39466"
},
{
"name": "CVE-2024-35949",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35949"
},
{
"name": "CVE-2024-36000",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36000"
},
{
"name": "CVE-2024-36003",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36003"
},
{
"name": "CVE-2024-36901",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36901"
},
{
"name": "CVE-2024-36909",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36909"
},
{
"name": "CVE-2024-36910",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36910"
},
{
"name": "CVE-2024-36911",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36911"
},
{
"name": "CVE-2024-36912",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36912"
},
{
"name": "CVE-2024-36913",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36913"
},
{
"name": "CVE-2024-36914",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36914"
},
{
"name": "CVE-2024-38604",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38604"
},
{
"name": "CVE-2024-41011",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41011"
},
{
"name": "CVE-2021-47624",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47624"
},
{
"name": "CVE-2023-52775",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52775"
},
{
"name": "CVE-2023-52885",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52885"
},
{
"name": "CVE-2024-39472",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39472"
},
{
"name": "CVE-2023-52751",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52751"
},
{
"name": "CVE-2024-26785",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26785"
},
{
"name": "CVE-2024-27402",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27402"
},
{
"name": "CVE-2024-27404",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27404"
},
{
"name": "CVE-2024-39473",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39473"
},
{
"name": "CVE-2024-39479",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39479"
},
{
"name": "CVE-2024-39481",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39481"
},
{
"name": "CVE-2024-39490",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39490"
},
{
"name": "CVE-2024-39498",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39498"
},
{
"name": "CVE-2024-39504",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39504"
},
{
"name": "CVE-2024-40923",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40923"
},
{
"name": "CVE-2024-40925",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40925"
},
{
"name": "CVE-2024-40928",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40928"
},
{
"name": "CVE-2024-40972",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40972"
},
{
"name": "CVE-2024-40975",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40975"
},
{
"name": "CVE-2024-40979",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40979"
},
{
"name": "CVE-2024-40998",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40998"
},
{
"name": "CVE-2024-40999",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40999"
},
{
"name": "CVE-2024-41013",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41013"
},
{
"name": "CVE-2024-41014",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41014"
},
{
"name": "CVE-2024-41017",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41017"
},
{
"name": "CVE-2024-41090",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41090"
},
{
"name": "CVE-2024-41091",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41091"
},
{
"name": "CVE-2021-47086",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47086"
},
{
"name": "CVE-2021-47126",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47126"
},
{
"name": "CVE-2021-47186",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47186"
},
{
"name": "CVE-2021-47291",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47291"
},
{
"name": "CVE-2021-47295",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47295"
},
{
"name": "CVE-2021-47546",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47546"
},
{
"name": "CVE-2021-47588",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47588"
},
{
"name": "CVE-2021-47590",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47590"
},
{
"name": "CVE-2021-47591",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47591"
},
{
"name": "CVE-2021-47593",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47593"
},
{
"name": "CVE-2021-47598",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47598"
},
{
"name": "CVE-2021-47599",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47599"
},
{
"name": "CVE-2021-47606",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47606"
},
{
"name": "CVE-2021-47622",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47622"
},
{
"name": "CVE-2021-47623",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47623"
},
{
"name": "CVE-2022-48773",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48773"
},
{
"name": "CVE-2022-48774",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48774"
},
{
"name": "CVE-2022-48775",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48775"
},
{
"name": "CVE-2022-48776",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48776"
},
{
"name": "CVE-2022-48777",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48777"
},
{
"name": "CVE-2022-48778",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48778"
},
{
"name": "CVE-2022-48780",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48780"
},
{
"name": "CVE-2022-48783",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48783"
},
{
"name": "CVE-2022-48784",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48784"
},
{
"name": "CVE-2022-48785",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48785"
},
{
"name": "CVE-2022-48786",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48786"
},
{
"name": "CVE-2022-48787",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48787"
},
{
"name": "CVE-2022-48788",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48788"
},
{
"name": "CVE-2022-48789",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48789"
},
{
"name": "CVE-2022-48790",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48790"
},
{
"name": "CVE-2022-48791",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48791"
},
{
"name": "CVE-2022-48792",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48792"
},
{
"name": "CVE-2022-48793",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48793"
},
{
"name": "CVE-2022-48794",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48794"
},
{
"name": "CVE-2022-48796",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48796"
},
{
"name": "CVE-2022-48797",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48797"
},
{
"name": "CVE-2022-48798",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48798"
},
{
"name": "CVE-2022-48799",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48799"
},
{
"name": "CVE-2022-48800",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48800"
},
{
"name": "CVE-2022-48801",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48801"
},
{
"name": "CVE-2022-48802",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48802"
},
{
"name": "CVE-2022-48803",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48803"
},
{
"name": "CVE-2022-48804",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48804"
},
{
"name": "CVE-2022-48805",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48805"
},
{
"name": "CVE-2022-48806",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48806"
},
{
"name": "CVE-2022-48807",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48807"
},
{
"name": "CVE-2022-48809",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48809"
},
{
"name": "CVE-2022-48810",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48810"
},
{
"name": "CVE-2022-48811",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48811"
},
{
"name": "CVE-2022-48812",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48812"
},
{
"name": "CVE-2022-48813",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48813"
},
{
"name": "CVE-2022-48814",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48814"
},
{
"name": "CVE-2022-48815",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48815"
},
{
"name": "CVE-2022-48816",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48816"
},
{
"name": "CVE-2022-48817",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48817"
},
{
"name": "CVE-2022-48818",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48818"
},
{
"name": "CVE-2022-48820",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48820"
},
{
"name": "CVE-2022-48821",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48821"
},
{
"name": "CVE-2022-48822",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48822"
},
{
"name": "CVE-2022-48823",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48823"
},
{
"name": "CVE-2022-48824",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48824"
},
{
"name": "CVE-2022-48825",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48825"
},
{
"name": "CVE-2022-48826",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48826"
},
{
"name": "CVE-2022-48827",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48827"
},
{
"name": "CVE-2022-48828",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48828"
},
{
"name": "CVE-2022-48829",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48829"
},
{
"name": "CVE-2022-48830",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48830"
},
{
"name": "CVE-2022-48831",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48831"
},
{
"name": "CVE-2022-48834",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48834"
},
{
"name": "CVE-2022-48835",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48835"
},
{
"name": "CVE-2022-48836",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48836"
},
{
"name": "CVE-2022-48837",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48837"
},
{
"name": "CVE-2022-48838",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48838"
},
{
"name": "CVE-2022-48839",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48839"
},
{
"name": "CVE-2022-48840",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48840"
},
{
"name": "CVE-2022-48841",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48841"
},
{
"name": "CVE-2022-48842",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48842"
},
{
"name": "CVE-2022-48843",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48843"
},
{
"name": "CVE-2022-48844",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48844"
},
{
"name": "CVE-2022-48846",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48846"
},
{
"name": "CVE-2022-48847",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48847"
},
{
"name": "CVE-2022-48849",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48849"
},
{
"name": "CVE-2022-48850",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48850"
},
{
"name": "CVE-2022-48851",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48851"
},
{
"name": "CVE-2022-48852",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48852"
},
{
"name": "CVE-2022-48853",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48853"
},
{
"name": "CVE-2022-48855",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48855"
},
{
"name": "CVE-2022-48856",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48856"
},
{
"name": "CVE-2022-48857",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48857"
},
{
"name": "CVE-2022-48858",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48858"
},
{
"name": "CVE-2022-48859",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48859"
},
{
"name": "CVE-2022-48860",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48860"
},
{
"name": "CVE-2022-48861",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48861"
},
{
"name": "CVE-2022-48862",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48862"
},
{
"name": "CVE-2022-48863",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48863"
},
{
"name": "CVE-2022-48864",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48864"
},
{
"name": "CVE-2022-48866",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48866"
},
{
"name": "CVE-2023-31315",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-31315"
},
{
"name": "CVE-2023-52573",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52573"
},
{
"name": "CVE-2023-52886",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52886"
},
{
"name": "CVE-2024-39497",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39497"
},
{
"name": "CVE-2024-39508",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39508"
},
{
"name": "CVE-2024-40909",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40909"
},
{
"name": "CVE-2024-40982",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40982"
},
{
"name": "CVE-2024-41009",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41009"
},
{
"name": "CVE-2024-41012",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41012"
},
{
"name": "CVE-2024-41015",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41015"
},
{
"name": "CVE-2024-41016",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41016"
},
{
"name": "CVE-2024-41040",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41040"
},
{
"name": "CVE-2024-41041",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41041"
},
{
"name": "CVE-2024-41044",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41044"
},
{
"name": "CVE-2024-41048",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41048"
},
{
"name": "CVE-2024-41057",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41057"
},
{
"name": "CVE-2024-41058",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41058"
},
{
"name": "CVE-2024-41059",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41059"
},
{
"name": "CVE-2024-41060",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41060"
},
{
"name": "CVE-2024-41063",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41063"
},
{
"name": "CVE-2024-41064",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41064"
},
{
"name": "CVE-2024-41066",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41066"
},
{
"name": "CVE-2024-41069",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41069"
},
{
"name": "CVE-2024-41070",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41070"
},
{
"name": "CVE-2024-41071",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41071"
},
{
"name": "CVE-2024-41072",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41072"
},
{
"name": "CVE-2024-41076",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41076"
},
{
"name": "CVE-2024-41078",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41078"
},
{
"name": "CVE-2024-41081",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41081"
},
{
"name": "CVE-2024-41087",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41087"
},
{
"name": "CVE-2024-41089",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41089"
},
{
"name": "CVE-2024-41095",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41095"
},
{
"name": "CVE-2024-42070",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42070"
},
{
"name": "CVE-2024-42079",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42079"
},
{
"name": "CVE-2024-42093",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42093"
},
{
"name": "CVE-2024-42096",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42096"
},
{
"name": "CVE-2024-42105",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42105"
},
{
"name": "CVE-2024-42119",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42119"
},
{
"name": "CVE-2024-42120",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42120"
},
{
"name": "CVE-2024-42122",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42122"
},
{
"name": "CVE-2024-42124",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42124"
},
{
"name": "CVE-2024-42145",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42145"
},
{
"name": "CVE-2024-42161",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42161"
},
{
"name": "CVE-2024-42223",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42223"
},
{
"name": "CVE-2024-42224",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42224"
},
{
"name": "CVE-2024-42230",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42230"
}
],
"links": [],
"reference": "CERTFR-2024-AVI-0717",
"revisions": [
{
"description": "Version initiale",
"revision_date": "2024-08-23T00:00:00.000000"
}
],
"risks": [
{
"description": "D\u00e9ni de service \u00e0 distance"
},
{
"description": "Ex\u00e9cution de code arbitraire \u00e0 distance"
},
{
"description": "Non sp\u00e9cifi\u00e9 par l\u0027\u00e9diteur"
},
{
"description": "Contournement de la politique de s\u00e9curit\u00e9"
},
{
"description": "Atteinte \u00e0 la confidentialit\u00e9 des donn\u00e9es"
},
{
"description": "\u00c9l\u00e9vation de privil\u00e8ges"
}
],
"summary": "De multiples vuln\u00e9rabilit\u00e9s ont \u00e9t\u00e9 d\u00e9couvertes dans le noyau Linux de SUSE. Certaines d\u0027entre elles permettent \u00e0 un attaquant de provoquer une ex\u00e9cution de code arbitraire \u00e0 distance, une \u00e9l\u00e9vation de privil\u00e8ges et un d\u00e9ni de service \u00e0 distance.",
"title": "Multiples vuln\u00e9rabilit\u00e9s dans le noyau Linux de SUSE",
"vendor_advisories": [
{
"published_at": "2024-08-20",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2024:2980-1",
"url": "https://www.suse.com/support/update/announcement/2024/suse-su-20242980-1"
},
{
"published_at": "2024-08-16",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2024:2940-1",
"url": "https://www.suse.com/support/update/announcement/2024/suse-su-20242940-1"
},
{
"published_at": "2024-08-16",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2024:2944-1",
"url": "https://www.suse.com/support/update/announcement/2024/suse-su-20242944-1"
},
{
"published_at": "2024-08-16",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2024:2943-1",
"url": "https://www.suse.com/support/update/announcement/2024/suse-su-20242943-1"
},
{
"published_at": "2024-08-16",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2024:2948-1",
"url": "https://www.suse.com/support/update/announcement/2024/suse-su-20242948-1"
},
{
"published_at": "2024-08-20",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2024:2973-1",
"url": "https://www.suse.com/support/update/announcement/2024/suse-su-20242973-1"
},
{
"published_at": "2024-08-16",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2024:2947-1",
"url": "https://www.suse.com/support/update/announcement/2024/suse-su-20242947-1"
}
]
}
CERTFR-2025-AVI-0677
Vulnerability from certfr_avis - Published: - Updated:
De multiples vulnérabilités ont été découvertes dans les produits Siemens. Certaines d'entre elles permettent à un attaquant de provoquer une exécution de code arbitraire à distance, une élévation de privilèges et un déni de service à distance.
Solutions
Se référer au bulletin de sécurité de l'éditeur pour l'obtention des correctifs (cf. section Documentation).
| Vendor | Product | Description | ||
|---|---|---|---|---|
| Siemens | N/A | SIMATIC PCS neo V6.0 versions antérieures à V6.0 SP1 | ||
| Siemens | N/A | SIMATIC WinCC V17, v18 et V20 toutes versions pour les vulnérabilités CVE-2024-54678 et CVE-2025-40759 | ||
| Siemens | N/A | SIMATIC Control Function Library (CFL) toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIPROTEC 5 versions antérieures à 10.0 | ||
| Siemens | N/A | SIMATIC MTP Integrator toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC ProSave V17 toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC WinCC Unified Line Coordination toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC WinCC TeleControl toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC WinCC OA V3.19 versions antérieures à V3.19 P020 | ||
| Siemens | N/A | SIMATIC WinCC flexible ES toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC S7-PLCSIM V17 toutes versions. L'éditeur indique que le produit ne bénéficiera pas de correctif de sécurité pour la vulnérabilité CVE-2024-54678. | ||
| Siemens | N/A | SIMATIC S7-Fail-safe Configuration Tool (S7-FCT) versions antérieures à 4.0.1 | ||
| Siemens | N/A | SIMATIC PCS neo V6.0 toutes versions pour la vulnérabilité CVE-2024-54678 | ||
| Siemens | N/A | SIMATIC eaSie Core Package (6DL5424-0AX00-0AV8) toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC MTP CREATOR V2.x et V3.x toutes versions. L'éditeur indique que le produit ne bénéficiera pas de correctif de sécurité pour la vulnérabilité CVE-2025-30033. | ||
| Siemens | N/A | SIMATIC WinCC OA V3.18 versions antérieures à V3.18 P032 | ||
| Siemens | N/A | TIA Portal Cloud V19 versions antérieures à 5.2.1.1 | ||
| Siemens | N/A | SIMATIC D7-SYS toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC BATCH V10.0 toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC ODK 1500S toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC Process Historian 2020 toutes versions. L'éditeur indique que le produit ne bénéficiera pas de correctif de sécurité pour les vulnérabilités CVE-2025-30033 et CVE-2025-47809 | ||
| Siemens | N/A | SIMATIC S7-1500 Software Controller V2 toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | TIA Portal Cloud Connector toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC WinCC Unified Sequence toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC S7-PLCSIM V17 toutes versions. L'éditeur indique que le produit ne bénéficiera pas de correctif de sécurité pour la vulnérabilité CVE-2025-40759. | ||
| Siemens | N/A | SIMATIC WinCC Runtime Advanced toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC Logon V2.0 toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC ProSave V19 versions antérieures à V19 Update 4 | ||
| Siemens | N/A | SIMATIC PDM Maintenance Station V5.0 toutes versions pour les vulnérabilités CVE-2025-30033 et CVE-2025-47809 | ||
| Siemens | N/A | SIMATIC Safety Matrix toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC Management Console toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SCALANCE XCM-/XRM-/XCH-/XRH-300 family versions antérieures à 3.2 | ||
| Siemens | N/A | SIMATIC BATCH V9.1 toutes versions. L'éditeur indique que le produit ne bénéficiera pas de correctif de sécurité pour la vulnérabilité CVE-2025-30033. | ||
| Siemens | N/A | SIMATIC Process Function Library (PFL) V4.0 toutes versions. L'éditeur indique que le produit ne bénéficiera pas de correctif de sécurité pour la vulnérabilité CVE-2025-30033. | ||
| Siemens | N/A | SIMATIC S7-1500 Software Controller V3 toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC STEP 7 CFC V20 toutes versions. L'éditeur indique que le produit ne bénéficiera pas de correctif de sécurité pour la vulnérabilité CVE-2025-30033. | ||
| Siemens | N/A | SIMATIC NET PC Software toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC Route Control V9.1 toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC Process Historian 2022 toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC WinCC OA V3.20 versions antérieures à V3.20 P008 | ||
| Siemens | N/A | SIMATIC RTLS Locating Manager versions antérieures à 3.3 | ||
| Siemens | N/A | Siprotec 4 7SA6, 7SD5 et 7SD610 versions antérieures à 4.78 | ||
| Siemens | N/A | SIMATIC Automation Tool toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | TIA Portal Cloud V18 toutes versions pour les vulnérabilités CVE-2024-54678 et CVE-2025-40759 | ||
| Siemens | N/A | SIMATIC PDM V9.2 et V9.3 toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC WinCC Runtime Professional toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC WinCC Visualization Architect (SiVArc) toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC eaSie Workflow Skills toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC STEP 7 CFC V19 toutes versions. L'éditeur indique que le produit ne bénéficiera pas de correctif de sécurité pour la vulnérabilité CVE-2025-30033. | ||
| Siemens | N/A | SIMATIC WinCC V19 versions antérieures à V19 Update 4 | ||
| Siemens | N/A | SIMATIC Management Agent toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC WinCC V7.5 et V8.0 toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC STEP 7 V5.7 toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC Automation Tool SDK Windows toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC Process Historian 2022 toutes versions pour la vulnérabilité CVE-2025-47809 | ||
| Siemens | N/A | SIMATIC S7-PLCSIM V20 versions antérieures à V20 Update 1 | ||
| Siemens | N/A | TIA Portal Cloud V17 toutes versions pour les vulnérabilités CVE-2024-54678 et CVE-2025-40759 | ||
| Siemens | N/A | SIMATIC Energy Suite toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC PCS 7 toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC Process Historian 2024 toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC STEP 7 V19 versions antérieures à V19 Update 4 | ||
| Siemens | N/A | TIA Portal Test Suite V17, v18, v19 et v20 toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC S7-PCT toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC Target toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC ProSave V18 toutes versions. L'éditeur indique que le produit ne bénéficiera pas de correctif de sécurité pour la vulnérabilité CVE-2025-30033. | ||
| Siemens | N/A | SIMATIC Logon V1.6 toutes versions. L'éditeur indique que le produit ne bénéficiera pas de correctif de sécurité pour la vulnérabilité CVE-2025-30033. | ||
| Siemens | N/A | SIMATIC STEP 7 V17 et V18 toutes versions pour les vulnérabilités CVE-2024-54678 et CVE-2025-40759 | ||
| Siemens | N/A | SIMATIC RTLS Locating Manager versions antérieures à 3.2 | ||
| Siemens | N/A | SIMATIC S7-PLCSIM Advanced versions antérieures à V7.0 Update 1 | ||
| Siemens | N/A | SIMATIC PCS neo V5.0 toutes versions pour la vulnérabilité CVE-2024-54678 | ||
| Siemens | N/A | SIMATIC STEP 7 V20 toutes versions pour les vulnérabilités CVE-2024-54678 et CVE-2025-40759 | ||
| Siemens | N/A | TIA Portal Cloud V20 toutes versions pour les vulnérabilités CVE-2024-54678 et CVE-2025-40759 | ||
| Siemens | N/A | Siprotec 4 toutes versions et tous modèles exceptés 7SA6, 7SD5, 7SD610 pour la vulnérabilité CVE-2024-52504. | ||
| Siemens | N/A | SIMATIC eaSie PCS 7 Skill Package (6DL5424-0BX00-0AV8) toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SCALANCE XC-300/XR-300/XC-400/XR-500WG/XR-500 versions antérieures à 3.2 | ||
| Siemens | N/A | SIMATIC S7-PLCSIM V17, V18 et V19 toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC WinCC Unified PC Runtime V18, V19 et V20 toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC PCS 7 Advanced Process Faceplates V9.1 toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC S7 F Systems V6.4 toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC Information Server toutes versions pour la vulnérabilité CVE-2025-47809 | ||
| Siemens | N/A | SIMATIC S7 F Systems V6.3 toutes versions. L'éditeur indique que le produit ne bénéficiera pas de correctif de sécurité pour la vulnérabilité CVE-2025-30033. | ||
| Siemens | N/A | SIMATIC ProSave V20 toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC PCS 7 Logic Matrix V9.1 toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | WinCC Panel Image Setup toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC PCS neo V4.1 et V5.0 toutes versions. L'éditeur indique que le produit ne bénéficiera pas de correctif de sécurité pour la vulnérabilité CVE-2024-54678. | ||
| Siemens | N/A | SIMATIC Route Control V10.0 toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC WinCC V8.1 versions antérieures à V8.1 Update 3 |
| Title | Publication Time | Tags | |||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||
{
"$ref": "https://www.cert.ssi.gouv.fr/openapi.json",
"affected_systems": [
{
"description": "SIMATIC PCS neo V6.0 versions ant\u00e9rieures \u00e0 V6.0 SP1",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC WinCC V17, v18 et V20 toutes versions pour les vuln\u00e9rabilit\u00e9s CVE-2024-54678 et CVE-2025-40759",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC Control Function Library (CFL) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIPROTEC 5 versions ant\u00e9rieures \u00e0 10.0",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC MTP Integrator toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC ProSave V17 toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC WinCC Unified Line Coordination toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC WinCC TeleControl toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC WinCC OA V3.19 versions ant\u00e9rieures \u00e0 V3.19 P020",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC WinCC flexible ES toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC S7-PLCSIM V17 toutes versions. L\u0027\u00e9diteur indique que le produit ne b\u00e9n\u00e9ficiera pas de correctif de s\u00e9curit\u00e9 pour la vuln\u00e9rabilit\u00e9 CVE-2024-54678.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC S7-Fail-safe Configuration Tool (S7-FCT) versions ant\u00e9rieures \u00e0 4.0.1",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC PCS neo V6.0 toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2024-54678",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC eaSie Core Package (6DL5424-0AX00-0AV8) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC MTP CREATOR V2.x et V3.x toutes versions. L\u0027\u00e9diteur indique que le produit ne b\u00e9n\u00e9ficiera pas de correctif de s\u00e9curit\u00e9 pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC WinCC OA V3.18 versions ant\u00e9rieures \u00e0 V3.18 P032",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "TIA Portal Cloud V19 versions ant\u00e9rieures \u00e0 5.2.1.1",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC D7-SYS toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC BATCH V10.0 toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC ODK 1500S toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC Process Historian 2020 toutes versions. L\u0027\u00e9diteur indique que le produit ne b\u00e9n\u00e9ficiera pas de correctif de s\u00e9curit\u00e9 pour les vuln\u00e9rabilit\u00e9s CVE-2025-30033 et CVE-2025-47809",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC S7-1500 Software Controller V2 toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "TIA Portal Cloud Connector toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC WinCC Unified Sequence toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC S7-PLCSIM V17 toutes versions. L\u0027\u00e9diteur indique que le produit ne b\u00e9n\u00e9ficiera pas de correctif de s\u00e9curit\u00e9 pour la vuln\u00e9rabilit\u00e9 CVE-2025-40759.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC WinCC Runtime Advanced toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC Logon V2.0 toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC ProSave V19 versions ant\u00e9rieures \u00e0 V19 Update 4",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC PDM Maintenance Station V5.0 toutes versions pour les vuln\u00e9rabilit\u00e9s CVE-2025-30033 et CVE-2025-47809",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC Safety Matrix toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC Management Console toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE XCM-/XRM-/XCH-/XRH-300 family versions ant\u00e9rieures \u00e0 3.2",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC BATCH V9.1 toutes versions. L\u0027\u00e9diteur indique que le produit ne b\u00e9n\u00e9ficiera pas de correctif de s\u00e9curit\u00e9 pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC Process Function Library (PFL) V4.0 toutes versions. L\u0027\u00e9diteur indique que le produit ne b\u00e9n\u00e9ficiera pas de correctif de s\u00e9curit\u00e9 pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC S7-1500 Software Controller V3 toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC STEP 7 CFC V20 toutes versions. L\u0027\u00e9diteur indique que le produit ne b\u00e9n\u00e9ficiera pas de correctif de s\u00e9curit\u00e9 pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC NET PC Software toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC Route Control V9.1 toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC Process Historian 2022 toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC WinCC OA V3.20 versions ant\u00e9rieures \u00e0 V3.20 P008",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC RTLS Locating Manager versions ant\u00e9rieures \u00e0 3.3",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "Siprotec 4 7SA6, 7SD5 et 7SD610 versions ant\u00e9rieures \u00e0 4.78",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC Automation Tool toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "TIA Portal Cloud V18 toutes versions pour les vuln\u00e9rabilit\u00e9s CVE-2024-54678 et CVE-2025-40759",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC PDM V9.2 et V9.3 toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC WinCC Runtime Professional toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC WinCC Visualization Architect (SiVArc) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC eaSie Workflow Skills toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC STEP 7 CFC V19 toutes versions. L\u0027\u00e9diteur indique que le produit ne b\u00e9n\u00e9ficiera pas de correctif de s\u00e9curit\u00e9 pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC WinCC V19 versions ant\u00e9rieures \u00e0 V19 Update 4",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC Management Agent toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC WinCC V7.5 et V8.0 toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC STEP 7 V5.7 toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC Automation Tool SDK Windows toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC Process Historian 2022 toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-47809",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC S7-PLCSIM V20 versions ant\u00e9rieures \u00e0 V20 Update 1",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "TIA Portal Cloud V17 toutes versions pour les vuln\u00e9rabilit\u00e9s CVE-2024-54678 et CVE-2025-40759",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC Energy Suite toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC PCS 7 toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC Process Historian 2024 toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC STEP 7 V19 versions ant\u00e9rieures \u00e0 V19 Update 4",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "TIA Portal Test Suite V17, v18, v19 et v20 toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC S7-PCT toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC Target toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC ProSave V18 toutes versions. L\u0027\u00e9diteur indique que le produit ne b\u00e9n\u00e9ficiera pas de correctif de s\u00e9curit\u00e9 pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC Logon V1.6 toutes versions. L\u0027\u00e9diteur indique que le produit ne b\u00e9n\u00e9ficiera pas de correctif de s\u00e9curit\u00e9 pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC STEP 7 V17 et V18 toutes versions pour les vuln\u00e9rabilit\u00e9s CVE-2024-54678 et CVE-2025-40759",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC RTLS Locating Manager versions ant\u00e9rieures \u00e0 3.2",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC S7-PLCSIM Advanced versions ant\u00e9rieures \u00e0 V7.0 Update 1",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC PCS neo V5.0 toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2024-54678",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC STEP 7 V20 toutes versions pour les vuln\u00e9rabilit\u00e9s CVE-2024-54678 et CVE-2025-40759",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "TIA Portal Cloud V20 toutes versions pour les vuln\u00e9rabilit\u00e9s CVE-2024-54678 et CVE-2025-40759",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "Siprotec 4 toutes versions et tous mod\u00e8les except\u00e9s 7SA6, 7SD5, 7SD610 pour la vuln\u00e9rabilit\u00e9 CVE-2024-52504. ",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC eaSie PCS 7 Skill Package (6DL5424-0BX00-0AV8) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE XC-300/XR-300/XC-400/XR-500WG/XR-500 versions ant\u00e9rieures \u00e0 3.2",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC S7-PLCSIM V17, V18 et V19 toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC WinCC Unified PC Runtime V18, V19 et V20 toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC PCS 7 Advanced Process Faceplates V9.1 toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC S7 F Systems V6.4 toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC Information Server toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-47809",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC S7 F Systems V6.3 toutes versions. L\u0027\u00e9diteur indique que le produit ne b\u00e9n\u00e9ficiera pas de correctif de s\u00e9curit\u00e9 pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC ProSave V20 toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC PCS 7 Logic Matrix V9.1 toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "WinCC Panel Image Setup toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC PCS neo V4.1 et V5.0 toutes versions. L\u0027\u00e9diteur indique que le produit ne b\u00e9n\u00e9ficiera pas de correctif de s\u00e9curit\u00e9 pour la vuln\u00e9rabilit\u00e9 CVE-2024-54678.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC Route Control V10.0 toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC WinCC V8.1 versions ant\u00e9rieures \u00e0 V8.1 Update 3",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
}
],
"affected_systems_content": "",
"content": "## Solutions\n\nSe r\u00e9f\u00e9rer au bulletin de s\u00e9curit\u00e9 de l\u0027\u00e9diteur pour l\u0027obtention des correctifs (cf. section Documentation).",
"cves": [
{
"name": "CVE-2023-35827",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-35827"
},
{
"name": "CVE-2024-40931",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40931"
},
{
"name": "CVE-2024-56596",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56596"
},
{
"name": "CVE-2024-43907",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43907"
},
{
"name": "CVE-2024-56645",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56645"
},
{
"name": "CVE-2024-56659",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56659"
},
{
"name": "CVE-2024-46755",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46755"
},
{
"name": "CVE-2024-47748",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47748"
},
{
"name": "CVE-2024-26825",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26825"
},
{
"name": "CVE-2024-49863",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49863"
},
{
"name": "CVE-2024-41022",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41022"
},
{
"name": "CVE-2024-49907",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49907"
},
{
"name": "CVE-2024-53061",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53061"
},
{
"name": "CVE-2024-53052",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53052"
},
{
"name": "CVE-2023-52477",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52477"
},
{
"name": "CVE-2024-53097",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53097"
},
{
"name": "CVE-2024-46713",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46713"
},
{
"name": "CVE-2023-52622",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52622"
},
{
"name": "CVE-2024-9681",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-9681"
},
{
"name": "CVE-2024-46844",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46844"
},
{
"name": "CVE-2024-43914",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43914"
},
{
"name": "CVE-2024-26696",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26696"
},
{
"name": "CVE-2024-56670",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56670"
},
{
"name": "CVE-2024-41009",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41009"
},
{
"name": "CVE-2024-47697",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47697"
},
{
"name": "CVE-2024-46815",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46815"
},
{
"name": "CVE-2024-39503",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39503"
},
{
"name": "CVE-2025-40759",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40759"
},
{
"name": "CVE-2022-48666",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48666"
},
{
"name": "CVE-2024-49890",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49890"
},
{
"name": "CVE-2024-50262",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50262"
},
{
"name": "CVE-2024-40988",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40988"
},
{
"name": "CVE-2024-50268",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50268"
},
{
"name": "CVE-2024-49903",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49903"
},
{
"name": "CVE-2024-49969",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49969"
},
{
"name": "CVE-2023-52804",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52804"
},
{
"name": "CVE-2024-41004",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41004"
},
{
"name": "CVE-2024-46676",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46676"
},
{
"name": "CVE-2024-41070",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41070"
},
{
"name": "CVE-2024-46740",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46740"
},
{
"name": "CVE-2023-52845",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52845"
},
{
"name": "CVE-2021-44879",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-44879"
},
{
"name": "CVE-2024-46798",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46798"
},
{
"name": "CVE-2024-50195",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50195"
},
{
"name": "CVE-2024-53172",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53172"
},
{
"name": "CVE-2024-46707",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46707"
},
{
"name": "CVE-2024-49967",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49967"
},
{
"name": "CVE-2024-41000",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41000"
},
{
"name": "CVE-2024-36974",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36974"
},
{
"name": "CVE-2023-52818",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52818"
},
{
"name": "CVE-2024-56606",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56606"
},
{
"name": "CVE-2023-52637",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52637"
},
{
"name": "CVE-2024-46747",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46747"
},
{
"name": "CVE-2024-49858",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49858"
},
{
"name": "CVE-2023-52873",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52873"
},
{
"name": "CVE-2024-49948",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49948"
},
{
"name": "CVE-2024-56594",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56594"
},
{
"name": "CVE-2024-26754",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26754"
},
{
"name": "CVE-2023-52858",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52858"
},
{
"name": "CVE-2024-46738",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46738"
},
{
"name": "CVE-2023-45863",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-45863"
},
{
"name": "CVE-2024-56756",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56756"
},
{
"name": "CVE-2024-52332",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-52332"
},
{
"name": "CVE-2024-46679",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46679"
},
{
"name": "CVE-2024-56724",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56724"
},
{
"name": "CVE-2024-53194",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53194"
},
{
"name": "CVE-2024-49878",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49878"
},
{
"name": "CVE-2023-51782",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-51782"
},
{
"name": "CVE-2024-46673",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46673"
},
{
"name": "CVE-2024-41034",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41034"
},
{
"name": "CVE-2024-56723",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56723"
},
{
"name": "CVE-2024-53226",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53226"
},
{
"name": "CVE-2024-49884",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49884"
},
{
"name": "CVE-2024-46724",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46724"
},
{
"name": "CVE-2024-56569",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56569"
},
{
"name": "CVE-2024-50074",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50074"
},
{
"name": "CVE-2024-26790",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26790"
},
{
"name": "CVE-2024-46791",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46791"
},
{
"name": "CVE-2024-50024",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50024"
},
{
"name": "CVE-2024-47684",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47684"
},
{
"name": "CVE-2024-49965",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49965"
},
{
"name": "CVE-2024-44969",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44969"
},
{
"name": "CVE-2024-56634",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56634"
},
{
"name": "CVE-2024-43098",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43098"
},
{
"name": "CVE-2024-42236",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42236"
},
{
"name": "CVE-2024-56548",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56548"
},
{
"name": "CVE-2024-39469",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39469"
},
{
"name": "CVE-2024-39509",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39509"
},
{
"name": "CVE-2024-50202",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50202"
},
{
"name": "CVE-2023-5178",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-5178"
},
{
"name": "CVE-2024-26845",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26845"
},
{
"name": "CVE-2024-26704",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26704"
},
{
"name": "CVE-2024-26671",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26671"
},
{
"name": "CVE-2024-46800",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46800"
},
{
"name": "CVE-2023-52810",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52810"
},
{
"name": "CVE-2024-46750",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46750"
},
{
"name": "CVE-2024-39484",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39484"
},
{
"name": "CVE-2024-53181",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53181"
},
{
"name": "CVE-2024-46722",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46722"
},
{
"name": "CVE-2024-26600",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26600"
},
{
"name": "CVE-2024-47701",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47701"
},
{
"name": "CVE-2024-40971",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40971"
},
{
"name": "CVE-2023-52847",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52847"
},
{
"name": "CVE-2024-39505",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39505"
},
{
"name": "CVE-2023-52864",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52864"
},
{
"name": "CVE-2024-0646",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-0646"
},
{
"name": "CVE-2024-50302",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50302"
},
{
"name": "CVE-2024-47713",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47713"
},
{
"name": "CVE-2024-49936",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49936"
},
{
"name": "CVE-2024-50267",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50267"
},
{
"name": "CVE-2024-56637",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56637"
},
{
"name": "CVE-2024-47663",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47663"
},
{
"name": "CVE-2024-40932",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40932"
},
{
"name": "CVE-2024-49881",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49881"
},
{
"name": "CVE-2023-52478",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52478"
},
{
"name": "CVE-2024-41006",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41006"
},
{
"name": "CVE-2023-46343",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-46343"
},
{
"name": "CVE-2024-46745",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46745"
},
{
"name": "CVE-2024-46819",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46819"
},
{
"name": "CVE-2024-49896",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49896"
},
{
"name": "CVE-2024-40904",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40904"
},
{
"name": "CVE-2024-42084",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42084"
},
{
"name": "CVE-2024-49959",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49959"
},
{
"name": "CVE-2024-49913",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49913"
},
{
"name": "CVE-2024-56691",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56691"
},
{
"name": "CVE-2024-46721",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46721"
},
{
"name": "CVE-2024-50045",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50045"
},
{
"name": "CVE-2024-26805",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26805"
},
{
"name": "CVE-2024-42153",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42153"
},
{
"name": "CVE-2024-46822",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46822"
},
{
"name": "CVE-2024-40960",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40960"
},
{
"name": "CVE-2024-49995",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49995"
},
{
"name": "CVE-2024-56643",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56643"
},
{
"name": "CVE-2025-40570",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40570"
},
{
"name": "CVE-2024-56661",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56661"
},
{
"name": "CVE-2024-49977",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49977"
},
{
"name": "CVE-2024-42154",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42154"
},
{
"name": "CVE-2024-49900",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49900"
},
{
"name": "CVE-2024-46685",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46685"
},
{
"name": "CVE-2024-47679",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47679"
},
{
"name": "CVE-2024-36484",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36484"
},
{
"name": "CVE-2024-43889",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43889"
},
{
"name": "CVE-2024-44998",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44998"
},
{
"name": "CVE-2024-46723",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46723"
},
{
"name": "CVE-2024-42229",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42229"
},
{
"name": "CVE-2024-26839",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26839"
},
{
"name": "CVE-2024-46828",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46828"
},
{
"name": "CVE-2024-50269",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50269"
},
{
"name": "CVE-2024-53150",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53150"
},
{
"name": "CVE-2024-47735",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47735"
},
{
"name": "CVE-2024-49952",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49952"
},
{
"name": "CVE-2024-49981",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49981"
},
{
"name": "CVE-2024-56595",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56595"
},
{
"name": "CVE-2024-42086",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42086"
},
{
"name": "CVE-2024-26581",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26581"
},
{
"name": "CVE-2022-48935",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48935"
},
{
"name": "CVE-2023-52433",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52433"
},
{
"name": "CVE-2024-41007",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41007"
},
{
"name": "CVE-2024-41095",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41095"
},
{
"name": "CVE-2024-56601",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56601"
},
{
"name": "CVE-2023-52600",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52600"
},
{
"name": "CVE-2024-53057",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53057"
},
{
"name": "CVE-2024-26910",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26910"
},
{
"name": "CVE-2024-50181",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50181"
},
{
"name": "CVE-2023-52507",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52507"
},
{
"name": "CVE-2024-56571",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56571"
},
{
"name": "CVE-2023-52764",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52764"
},
{
"name": "CVE-2023-52587",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52587"
},
{
"name": "CVE-2023-52887",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52887"
},
{
"name": "CVE-2024-46675",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46675"
},
{
"name": "CVE-2024-26645",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26645"
},
{
"name": "CVE-2024-26702",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26702"
},
{
"name": "CVE-2024-46783",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46783"
},
{
"name": "CVE-2023-51779",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-51779"
},
{
"name": "CVE-2024-42076",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42076"
},
{
"name": "CVE-2024-26673",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26673"
},
{
"name": "CVE-2024-49997",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49997"
},
{
"name": "CVE-2024-42092",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42092"
},
{
"name": "CVE-2024-26720",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26720"
},
{
"name": "CVE-2024-0584",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-0584"
},
{
"name": "CVE-2024-42093",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42093"
},
{
"name": "CVE-2024-42247",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42247"
},
{
"name": "CVE-2024-43871",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43871"
},
{
"name": "CVE-2024-53066",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53066"
},
{
"name": "CVE-2023-52784",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52784"
},
{
"name": "CVE-2024-43880",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43880"
},
{
"name": "CVE-2024-27413",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27413"
},
{
"name": "CVE-2024-56629",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56629"
},
{
"name": "CVE-2024-50304",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50304"
},
{
"name": "CVE-2024-40959",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40959"
},
{
"name": "CVE-2024-26615",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26615"
},
{
"name": "CVE-2023-52853",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52853"
},
{
"name": "CVE-2024-46689",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46689"
},
{
"name": "CVE-2024-50295",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50295"
},
{
"name": "CVE-2024-26801",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26801"
},
{
"name": "CVE-2024-50051",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50051"
},
{
"name": "CVE-2024-41078",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41078"
},
{
"name": "CVE-2024-53063",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53063"
},
{
"name": "CVE-2024-53171",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53171"
},
{
"name": "CVE-2024-56602",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56602"
},
{
"name": "CVE-2024-46781",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46781"
},
{
"name": "CVE-2024-56770",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56770"
},
{
"name": "CVE-2024-53157",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53157"
},
{
"name": "CVE-2025-30034",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-30034"
},
{
"name": "CVE-2024-46777",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46777"
},
{
"name": "CVE-2023-52340",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52340"
},
{
"name": "CVE-2024-50199",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50199"
},
{
"name": "CVE-2024-26779",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26779"
},
{
"name": "CVE-2024-40916",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40916"
},
{
"name": "CVE-2024-0193",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-0193"
},
{
"name": "CVE-2023-52604",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52604"
},
{
"name": "CVE-2024-50040",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50040"
},
{
"name": "CVE-2024-38586",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38586"
},
{
"name": "CVE-2024-56739",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56739"
},
{
"name": "CVE-2024-50292",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50292"
},
{
"name": "CVE-2024-53103",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53103"
},
{
"name": "CVE-2024-46714",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46714"
},
{
"name": "CVE-2024-40976",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40976"
},
{
"name": "CVE-2024-41081",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41081"
},
{
"name": "CVE-2025-40746",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40746"
},
{
"name": "CVE-2024-49983",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49983"
},
{
"name": "CVE-2023-52601",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52601"
},
{
"name": "CVE-2024-41072",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41072"
},
{
"name": "CVE-2024-44960",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44960"
},
{
"name": "CVE-2024-26773",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26773"
},
{
"name": "CVE-2024-26722",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26722"
},
{
"name": "CVE-2024-54678",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-54678"
},
{
"name": "CVE-2024-26598",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26598"
},
{
"name": "CVE-2024-53197",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53197"
},
{
"name": "CVE-2024-26679",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26679"
},
{
"name": "CVE-2024-39468",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39468"
},
{
"name": "CVE-2024-26763",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26763"
},
{
"name": "CVE-2024-49889",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49889"
},
{
"name": "CVE-2023-52435",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52435"
},
{
"name": "CVE-2024-40980",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40980"
},
{
"name": "CVE-2023-52654",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52654"
},
{
"name": "CVE-2024-36938",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36938"
},
{
"name": "CVE-2024-40974",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40974"
},
{
"name": "CVE-2023-52855",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52855"
},
{
"name": "CVE-2024-56779",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56779"
},
{
"name": "CVE-2024-26749",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26749"
},
{
"name": "CVE-2024-44971",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44971"
},
{
"name": "CVE-2023-52603",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52603"
},
{
"name": "CVE-2024-43894",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43894"
},
{
"name": "CVE-2023-52486",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52486"
},
{
"name": "CVE-2024-43867",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43867"
},
{
"name": "CVE-2023-52868",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52868"
},
{
"name": "CVE-2023-52619",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52619"
},
{
"name": "CVE-2023-52796",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52796"
},
{
"name": "CVE-2023-52475",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52475"
},
{
"name": "CVE-2024-50013",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50013"
},
{
"name": "CVE-2024-50185",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50185"
},
{
"name": "CVE-2024-53239",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53239"
},
{
"name": "CVE-2023-52617",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52617"
},
{
"name": "CVE-2024-49957",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49957"
},
{
"name": "CVE-2024-49962",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49962"
},
{
"name": "CVE-2024-46731",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46731"
},
{
"name": "CVE-2024-39502",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39502"
},
{
"name": "CVE-2024-46674",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46674"
},
{
"name": "CVE-2023-52836",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52836"
},
{
"name": "CVE-2024-26804",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26804"
},
{
"name": "CVE-2024-26593",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26593"
},
{
"name": "CVE-2024-26751",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26751"
},
{
"name": "CVE-2024-49958",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49958"
},
{
"name": "CVE-2024-50082",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50082"
},
{
"name": "CVE-2024-47723",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47723"
},
{
"name": "CVE-2024-49955",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49955"
},
{
"name": "CVE-2024-42087",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42087"
},
{
"name": "CVE-2024-44944",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44944"
},
{
"name": "CVE-2024-43893",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43893"
},
{
"name": "CVE-2024-50095",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50095"
},
{
"name": "CVE-2024-40983",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40983"
},
{
"name": "CVE-2024-50296",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50296"
},
{
"name": "CVE-2024-57874",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57874"
},
{
"name": "CVE-2024-53145",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53145"
},
{
"name": "CVE-2024-50006",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50006"
},
{
"name": "CVE-2022-49034",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49034"
},
{
"name": "CVE-2024-50049",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50049"
},
{
"name": "CVE-2024-27412",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27412"
},
{
"name": "CVE-2024-26636",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26636"
},
{
"name": "CVE-2024-56642",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56642"
},
{
"name": "CVE-2024-50007",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50007"
},
{
"name": "CVE-2024-56586",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56586"
},
{
"name": "CVE-2023-39198",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-39198"
},
{
"name": "CVE-2024-40963",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40963"
},
{
"name": "CVE-2025-40752",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40752"
},
{
"name": "CVE-2024-41041",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41041"
},
{
"name": "CVE-2024-50096",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50096"
},
{
"name": "CVE-2023-52789",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52789"
},
{
"name": "CVE-2024-49868",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49868"
},
{
"name": "CVE-2024-40947",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40947"
},
{
"name": "CVE-2024-53173",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53173"
},
{
"name": "CVE-2024-50237",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50237"
},
{
"name": "CVE-2023-52867",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52867"
},
{
"name": "CVE-2024-44995",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44995"
},
{
"name": "CVE-2024-46757",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46757"
},
{
"name": "CVE-2024-42232",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42232"
},
{
"name": "CVE-2024-47699",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47699"
},
{
"name": "CVE-2024-56581",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56581"
},
{
"name": "CVE-2024-46677",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46677"
},
{
"name": "CVE-2024-50059",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50059"
},
{
"name": "CVE-2024-50264",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50264"
},
{
"name": "CVE-2024-26606",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26606"
},
{
"name": "CVE-2024-35833",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35833"
},
{
"name": "CVE-2024-41005",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41005"
},
{
"name": "CVE-2024-43883",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43883"
},
{
"name": "CVE-2024-56623",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56623"
},
{
"name": "CVE-2024-26625",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26625"
},
{
"name": "CVE-2024-44935",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44935"
},
{
"name": "CVE-2024-44999",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44999"
},
{
"name": "CVE-2024-47712",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47712"
},
{
"name": "CVE-2024-56610",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56610"
},
{
"name": "CVE-2024-26748",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26748"
},
{
"name": "CVE-2023-52809",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52809"
},
{
"name": "CVE-2024-42223",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42223"
},
{
"name": "CVE-2024-49963",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49963"
},
{
"name": "CVE-2024-49971",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49971"
},
{
"name": "CVE-2024-56562",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56562"
},
{
"name": "CVE-2024-26635",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26635"
},
{
"name": "CVE-2023-52805",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52805"
},
{
"name": "CVE-2024-41097",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41097"
},
{
"name": "CVE-2024-49875",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49875"
},
{
"name": "CVE-2024-47739",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47739"
},
{
"name": "CVE-2024-47705",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47705"
},
{
"name": "CVE-2024-53161",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53161"
},
{
"name": "CVE-2023-52919",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52919"
},
{
"name": "CVE-2024-50035",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50035"
},
{
"name": "CVE-2024-56600",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56600"
},
{
"name": "CVE-2024-36978",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36978"
},
{
"name": "CVE-2024-44988",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44988"
},
{
"name": "CVE-2024-47660",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47660"
},
{
"name": "CVE-2024-56690",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56690"
},
{
"name": "CVE-2024-56597",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56597"
},
{
"name": "CVE-2024-40905",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40905"
},
{
"name": "CVE-2024-56574",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56574"
},
{
"name": "CVE-2024-47740",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47740"
},
{
"name": "CVE-2024-41063",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41063"
},
{
"name": "CVE-2024-41017",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41017"
},
{
"name": "CVE-2024-26697",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26697"
},
{
"name": "CVE-2024-42244",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42244"
},
{
"name": "CVE-2024-49924",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49924"
},
{
"name": "CVE-2024-46758",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46758"
},
{
"name": "CVE-2024-53217",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53217"
},
{
"name": "CVE-2024-53183",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53183"
},
{
"name": "CVE-2024-49938",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49938"
},
{
"name": "CVE-2024-41012",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41012"
},
{
"name": "CVE-2024-40902",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40902"
},
{
"name": "CVE-2024-47756",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47756"
},
{
"name": "CVE-2024-40934",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40934"
},
{
"name": "CVE-2024-47667",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47667"
},
{
"name": "CVE-2024-46756",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46756"
},
{
"name": "CVE-2024-56615",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56615"
},
{
"name": "CVE-2024-47737",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47737"
},
{
"name": "CVE-2024-46739",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46739"
},
{
"name": "CVE-2024-47669",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47669"
},
{
"name": "CVE-2024-56705",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56705"
},
{
"name": "CVE-2024-50290",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50290"
},
{
"name": "CVE-2024-50008",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50008"
},
{
"name": "CVE-2024-42082",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42082"
},
{
"name": "CVE-2024-26685",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26685"
},
{
"name": "CVE-2024-56704",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56704"
},
{
"name": "CVE-2024-45006",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45006"
},
{
"name": "CVE-2024-46725",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46725"
},
{
"name": "CVE-2024-46829",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46829"
},
{
"name": "CVE-2024-40912",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40912"
},
{
"name": "CVE-2023-52599",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52599"
},
{
"name": "CVE-2024-56589",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56589"
},
{
"name": "CVE-2024-50265",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50265"
},
{
"name": "CVE-2024-56636",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56636"
},
{
"name": "CVE-2024-41089",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41089"
},
{
"name": "CVE-2024-39487",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39487"
},
{
"name": "CVE-2024-56567",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56567"
},
{
"name": "CVE-2024-44954",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44954"
},
{
"name": "CVE-2024-43908",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43908"
},
{
"name": "CVE-2023-3567",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-3567"
},
{
"name": "CVE-2024-50033",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50033"
},
{
"name": "CVE-2024-43890",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43890"
},
{
"name": "CVE-2024-26688",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26688"
},
{
"name": "CVE-2023-52865",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52865"
},
{
"name": "CVE-2024-49901",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49901"
},
{
"name": "CVE-2024-36901",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36901"
},
{
"name": "CVE-2024-56688",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56688"
},
{
"name": "CVE-2024-41090",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41090"
},
{
"name": "CVE-2024-50180",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50180"
},
{
"name": "CVE-2024-26663",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26663"
},
{
"name": "CVE-2024-50282",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50282"
},
{
"name": "CVE-2024-50273",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50273"
},
{
"name": "CVE-2024-26675",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26675"
},
{
"name": "CVE-2024-56532",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56532"
},
{
"name": "CVE-2024-41077",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41077"
},
{
"name": "CVE-2024-47143",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47143"
},
{
"name": "CVE-2024-49949",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49949"
},
{
"name": "CVE-2023-52509",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52509"
},
{
"name": "CVE-2024-44952",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44952"
},
{
"name": "CVE-2023-52753",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52753"
},
{
"name": "CVE-2024-26840",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26840"
},
{
"name": "CVE-2024-50046",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50046"
},
{
"name": "CVE-2023-52583",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52583"
},
{
"name": "CVE-2024-50099",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50099"
},
{
"name": "CVE-2024-50193",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50193"
},
{
"name": "CVE-2024-46743",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46743"
},
{
"name": "CVE-2024-49944",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49944"
},
{
"name": "CVE-2023-52602",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52602"
},
{
"name": "CVE-2024-50198",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50198"
},
{
"name": "CVE-2023-52832",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52832"
},
{
"name": "CVE-2024-56746",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56746"
},
{
"name": "CVE-2024-47749",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47749"
},
{
"name": "CVE-2024-41092",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41092"
},
{
"name": "CVE-2024-49966",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49966"
},
{
"name": "CVE-2024-40995",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40995"
},
{
"name": "CVE-2024-41087",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41087"
},
{
"name": "CVE-2023-52819",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52819"
},
{
"name": "CVE-2023-52876",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52876"
},
{
"name": "CVE-2024-42095",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42095"
},
{
"name": "CVE-2024-49902",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49902"
},
{
"name": "CVE-2024-47757",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47757"
},
{
"name": "CVE-2025-30033",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-30033"
},
{
"name": "CVE-2024-27417",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27417"
},
{
"name": "CVE-2024-48881",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-48881"
},
{
"name": "CVE-2024-47692",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47692"
},
{
"name": "CVE-2024-46744",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46744"
},
{
"name": "CVE-2024-0841",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-0841"
},
{
"name": "CVE-2025-40753",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40753"
},
{
"name": "CVE-2024-50184",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50184"
},
{
"name": "CVE-2024-40929",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40929"
},
{
"name": "CVE-2024-39501",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39501"
},
{
"name": "CVE-2024-52504",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-52504"
},
{
"name": "CVE-2024-50287",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50287"
},
{
"name": "CVE-2024-56747",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56747"
},
{
"name": "CVE-2024-49851",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49851"
},
{
"name": "CVE-2023-6040",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-6040"
},
{
"name": "CVE-2023-52510",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52510"
},
{
"name": "CVE-2023-51781",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-51781"
},
{
"name": "CVE-2024-56603",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56603"
},
{
"name": "CVE-2024-53158",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53158"
},
{
"name": "CVE-2024-43882",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43882"
},
{
"name": "CVE-2024-41068",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41068"
},
{
"name": "CVE-2024-56644",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56644"
},
{
"name": "CVE-2024-46780",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46780"
},
{
"name": "CVE-2024-46817",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46817"
},
{
"name": "CVE-2024-42101",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42101"
},
{
"name": "CVE-2025-40751",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40751"
},
{
"name": "CVE-2024-50278",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50278"
},
{
"name": "CVE-2024-50201",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50201"
},
{
"name": "CVE-2024-35835",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35835"
},
{
"name": "CVE-2024-56701",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56701"
},
{
"name": "CVE-2024-42077",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42077"
},
{
"name": "CVE-2023-52670",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52670"
},
{
"name": "CVE-2024-40943",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40943"
},
{
"name": "CVE-2024-26735",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26735"
},
{
"name": "CVE-2024-49933",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49933"
},
{
"name": "CVE-2024-53184",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53184"
},
{
"name": "CVE-2024-47685",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47685"
},
{
"name": "CVE-2024-40901",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40901"
},
{
"name": "CVE-2022-48829",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48829"
},
{
"name": "CVE-2024-53174",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53174"
},
{
"name": "CVE-2024-49879",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49879"
},
{
"name": "CVE-2024-39495",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39495"
},
{
"name": "CVE-2024-50044",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50044"
},
{
"name": "CVE-2024-49894",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49894"
},
{
"name": "CVE-2024-56700",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56700"
},
{
"name": "CVE-2024-47718",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47718"
},
{
"name": "CVE-2024-49867",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49867"
},
{
"name": "CVE-2023-51780",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-51780"
},
{
"name": "CVE-2024-49985",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49985"
},
{
"name": "CVE-2024-50001",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50001"
},
{
"name": "CVE-2023-52881",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52881"
},
{
"name": "CVE-2024-49993",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49993"
},
{
"name": "CVE-2024-56728",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56728"
},
{
"name": "CVE-2024-43861",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43861"
},
{
"name": "CVE-2024-53241",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53241"
},
{
"name": "CVE-2023-52838",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52838"
},
{
"name": "CVE-2024-47710",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47710"
},
{
"name": "CVE-2024-46771",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46771"
},
{
"name": "CVE-2024-50083",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50083"
},
{
"name": "CVE-2023-52774",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52774"
},
{
"name": "CVE-2024-56531",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56531"
},
{
"name": "CVE-2024-49892",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49892"
},
{
"name": "CVE-2024-49930",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49930"
},
{
"name": "CVE-2024-53148",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53148"
},
{
"name": "CVE-2024-47698",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47698"
},
{
"name": "CVE-2023-52879",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52879"
},
{
"name": "CVE-2024-56681",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56681"
},
{
"name": "CVE-2024-26602",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26602"
},
{
"name": "CVE-2023-52799",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52799"
},
{
"name": "CVE-2024-38619",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38619"
},
{
"name": "CVE-2024-50039",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50039"
},
{
"name": "CVE-2024-50251",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50251"
},
{
"name": "CVE-2024-56754",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56754"
},
{
"name": "CVE-2024-49973",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49973"
},
{
"name": "CVE-2024-53214",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53214"
},
{
"name": "CVE-2024-39476",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39476"
},
{
"name": "CVE-2024-46804",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46804"
},
{
"name": "CVE-2024-56619",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56619"
},
{
"name": "CVE-2024-47668",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47668"
},
{
"name": "CVE-2024-49883",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49883"
},
{
"name": "CVE-2024-53165",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53165"
},
{
"name": "CVE-2024-50236",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50236"
},
{
"name": "CVE-2024-46840",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46840"
},
{
"name": "CVE-2022-48828",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48828"
},
{
"name": "CVE-2024-56568",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56568"
},
{
"name": "CVE-2024-46763",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46763"
},
{
"name": "CVE-2024-41059",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41059"
},
{
"name": "CVE-2024-42094",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42094"
},
{
"name": "CVE-2024-53146",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53146"
},
{
"name": "CVE-2024-46759",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46759"
},
{
"name": "CVE-2024-27416",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27416"
},
{
"name": "CVE-2023-52598",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52598"
},
{
"name": "CVE-2024-46737",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46737"
},
{
"name": "CVE-2024-41040",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41040"
},
{
"name": "CVE-2023-6606",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-6606"
},
{
"name": "CVE-2024-40987",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40987"
},
{
"name": "CVE-2024-56539",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56539"
},
{
"name": "CVE-2023-52806",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52806"
},
{
"name": "CVE-2024-56662",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56662"
},
{
"name": "CVE-2024-46814",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46814"
},
{
"name": "CVE-2024-56572",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56572"
},
{
"name": "CVE-2024-56570",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56570"
},
{
"name": "CVE-2024-26793",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26793"
},
{
"name": "CVE-2024-40945",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40945"
},
{
"name": "CVE-2024-46818",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46818"
},
{
"name": "CVE-2023-6932",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-6932"
},
{
"name": "CVE-2024-50602",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50602"
},
{
"name": "CVE-2024-40941",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40941"
},
{
"name": "CVE-2022-48827",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48827"
},
{
"name": "CVE-2023-52594",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52594"
},
{
"name": "CVE-2024-53198",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53198"
},
{
"name": "CVE-2024-44965",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44965"
},
{
"name": "CVE-2024-49860",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49860"
},
{
"name": "CVE-2024-45003",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45003"
},
{
"name": "CVE-2024-41055",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41055"
},
{
"name": "CVE-2023-52595",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52595"
},
{
"name": "CVE-2025-47809",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-47809"
},
{
"name": "CVE-2024-50234",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50234"
},
{
"name": "CVE-2024-56720",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56720"
},
{
"name": "CVE-2024-26752",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26752"
},
{
"name": "CVE-2024-41015",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41015"
},
{
"name": "CVE-2024-53155",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53155"
},
{
"name": "CVE-2024-40984",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40984"
},
{
"name": "CVE-2024-42224",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42224"
},
{
"name": "CVE-2024-50194",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50194"
},
{
"name": "CVE-2024-46832",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46832"
},
{
"name": "CVE-2023-52871",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52871"
},
{
"name": "CVE-2024-49895",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49895"
},
{
"name": "CVE-2024-56785",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56785"
},
{
"name": "CVE-2023-52623",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52623"
},
{
"name": "CVE-2024-26736",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26736"
},
{
"name": "CVE-2024-56587",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56587"
},
{
"name": "CVE-2024-45021",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45021"
},
{
"name": "CVE-2023-52655",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52655"
},
{
"name": "CVE-2024-49882",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49882"
},
{
"name": "CVE-2024-47659",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47659"
},
{
"name": "CVE-2024-42161",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42161"
},
{
"name": "CVE-2023-52813",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52813"
},
{
"name": "CVE-2024-56741",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56741"
},
{
"name": "CVE-2023-52504",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52504"
},
{
"name": "CVE-2024-39506",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39506"
},
{
"name": "CVE-2024-40990",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40990"
},
{
"name": "CVE-2024-40978",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40978"
},
{
"name": "CVE-2024-53104",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53104"
},
{
"name": "CVE-2023-52615",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52615"
},
{
"name": "CVE-2024-40968",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40968"
},
{
"name": "CVE-2024-45025",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45025"
},
{
"name": "CVE-2024-27414",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27414"
},
{
"name": "CVE-2024-56748",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56748"
},
{
"name": "CVE-2024-41035",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41035"
},
{
"name": "CVE-2024-56648",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56648"
},
{
"name": "CVE-2024-26777",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26777"
},
{
"name": "CVE-2024-41049",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41049"
},
{
"name": "CVE-2024-26764",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26764"
},
{
"name": "CVE-2024-42143",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42143"
},
{
"name": "CVE-2021-47316",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47316"
},
{
"name": "CVE-2024-56558",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56558"
},
{
"name": "CVE-2024-41065",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41065"
},
{
"name": "CVE-2024-43879",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43879"
},
{
"name": "CVE-2024-46761",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46761"
},
{
"name": "CVE-2023-52606",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52606"
},
{
"name": "CVE-2024-50301",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50301"
},
{
"name": "CVE-2024-26778",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26778"
},
{
"name": "CVE-2024-37078",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-37078"
},
{
"name": "CVE-2024-49975",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49975"
},
{
"name": "CVE-2024-53240",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53240"
},
{
"name": "CVE-2024-50179",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50179"
},
{
"name": "CVE-2024-53101",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53101"
},
{
"name": "CVE-2024-47696",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47696"
},
{
"name": "CVE-2023-52840",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52840"
},
{
"name": "CVE-2024-53156",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53156"
},
{
"name": "CVE-2023-52502",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52502"
},
{
"name": "CVE-2024-41091",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41091"
},
{
"name": "CVE-2024-42105",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42105"
},
{
"name": "CVE-2024-50015",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50015"
},
{
"name": "CVE-2023-52597",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52597"
},
{
"name": "CVE-2024-41044",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41044"
},
{
"name": "CVE-2024-40958",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40958"
},
{
"name": "CVE-2023-52581",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52581"
},
{
"name": "CVE-2024-45008",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45008"
},
{
"name": "CVE-2024-50188",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50188"
},
{
"name": "CVE-2024-56533",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56533"
},
{
"name": "CVE-2024-40981",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40981"
},
{
"name": "CVE-2023-52917",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52917"
},
{
"name": "CVE-2024-56598",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56598"
},
{
"name": "CVE-2024-1086",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-1086"
},
{
"name": "CVE-2024-53060",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53060"
},
{
"name": "CVE-2023-52875",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52875"
},
{
"name": "CVE-2024-44990",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44990"
},
{
"name": "CVE-2024-44987",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44987"
},
{
"name": "CVE-2024-56781",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56781"
},
{
"name": "CVE-2024-41046",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41046"
},
{
"name": "CVE-2024-50089",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50089"
},
{
"name": "CVE-2024-56630",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56630"
},
{
"name": "CVE-2024-42152",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42152"
},
{
"name": "CVE-2024-49982",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49982"
},
{
"name": "CVE-2023-52835",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52835"
},
{
"name": "CVE-2024-53059",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53059"
},
{
"name": "CVE-2024-50299",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50299"
},
{
"name": "CVE-2024-50218",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50218"
},
{
"name": "CVE-2024-42148",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42148"
},
{
"name": "CVE-2024-39482",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39482"
},
{
"name": "CVE-2024-39499",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39499"
},
{
"name": "CVE-2024-56633",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56633"
},
{
"name": "CVE-2024-56593",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56593"
},
{
"name": "CVE-2024-56605",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56605"
},
{
"name": "CVE-2024-53680",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53680"
},
{
"name": "CVE-2024-26835",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26835"
},
{
"name": "CVE-2024-26791",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26791"
},
{
"name": "CVE-2023-52843",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52843"
},
{
"name": "CVE-2024-50279",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50279"
},
{
"name": "CVE-2024-41064",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41064"
},
{
"name": "CVE-2024-36894",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36894"
},
{
"name": "CVE-2024-56698",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56698"
},
{
"name": "CVE-2024-47742",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47742"
},
{
"name": "CVE-2024-47709",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47709"
},
{
"name": "CVE-2024-41020",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41020"
},
{
"name": "CVE-2024-26772",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26772"
},
{
"name": "CVE-2024-46782",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46782"
},
{
"name": "CVE-2024-56780",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56780"
},
{
"name": "CVE-2024-47706",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47706"
},
{
"name": "CVE-2024-27405",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27405"
},
{
"name": "CVE-2024-46702",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46702"
},
{
"name": "CVE-2023-5717",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-5717"
},
{
"name": "CVE-2024-47747",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47747"
},
{
"name": "CVE-2024-40942",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40942"
},
{
"name": "CVE-2024-26766",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26766"
},
{
"name": "CVE-2023-5678",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-5678"
},
{
"name": "CVE-2024-26664",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26664"
},
{
"name": "CVE-2024-46719",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46719"
},
{
"name": "CVE-2024-49877",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49877"
},
{
"name": "CVE-2023-52791",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52791"
},
{
"name": "CVE-2024-44949",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44949"
},
{
"name": "CVE-2023-6121",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-6121"
},
{
"name": "CVE-2023-52607",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52607"
},
{
"name": "CVE-2024-56650",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56650"
},
{
"name": "CVE-2024-44989",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44989"
},
{
"name": "CVE-2024-26788",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26788"
},
{
"name": "CVE-2023-52817",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52817"
},
{
"name": "CVE-2024-27410",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27410"
},
{
"name": "CVE-2024-26684",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26684"
},
{
"name": "CVE-2024-53237",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53237"
},
{
"name": "CVE-2023-6931",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-6931"
},
{
"name": "CVE-2024-56576",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56576"
},
{
"name": "CVE-2024-42145",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42145"
},
{
"name": "CVE-2024-40961",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40961"
},
{
"name": "CVE-2024-53227",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53227"
}
],
"links": [],
"reference": "CERTFR-2025-AVI-0677",
"revisions": [
{
"description": "Version initiale",
"revision_date": "2025-08-12T00:00:00.000000"
}
],
"risks": [
{
"description": "D\u00e9ni de service \u00e0 distance"
},
{
"description": "Ex\u00e9cution de code arbitraire \u00e0 distance"
},
{
"description": "Atteinte \u00e0 l\u0027int\u00e9grit\u00e9 des donn\u00e9es"
},
{
"description": "Non sp\u00e9cifi\u00e9 par l\u0027\u00e9diteur"
},
{
"description": "Contournement de la politique de s\u00e9curit\u00e9"
},
{
"description": "Atteinte \u00e0 la confidentialit\u00e9 des donn\u00e9es"
},
{
"description": "\u00c9l\u00e9vation de privil\u00e8ges"
}
],
"summary": "De multiples vuln\u00e9rabilit\u00e9s ont \u00e9t\u00e9 d\u00e9couvertes dans les produits Siemens. Certaines d\u0027entre elles permettent \u00e0 un attaquant de provoquer une ex\u00e9cution de code arbitraire \u00e0 distance, une \u00e9l\u00e9vation de privil\u00e8ges et un d\u00e9ni de service \u00e0 distance.",
"title": "Multiples vuln\u00e9rabilit\u00e9s dans les produits Siemens",
"vendor_advisories": [
{
"published_at": "2025-08-12",
"title": "Bulletin de s\u00e9curit\u00e9 Siemens SSA-707630",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-707630.html"
},
{
"published_at": "2025-08-12",
"title": "Bulletin de s\u00e9curit\u00e9 Siemens SSA-331739",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-331739.html"
},
{
"published_at": "2025-08-12",
"title": "Bulletin de s\u00e9curit\u00e9 Siemens SSA-693808",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-693808.html"
},
{
"published_at": "2025-08-12",
"title": "Bulletin de s\u00e9curit\u00e9 Siemens SSA-613116",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-613116.html"
},
{
"published_at": "2025-08-12",
"title": "Bulletin de s\u00e9curit\u00e9 Siemens SSA-493396",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-493396.html"
},
{
"published_at": "2025-08-11",
"title": "Bulletin de s\u00e9curit\u00e9 Siemens ssa-400089",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-400089.html"
},
{
"published_at": "2025-08-12",
"title": "Bulletin de s\u00e9curit\u00e9 Siemens SSA-493787",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-493787.html"
},
{
"published_at": "2025-08-12",
"title": "Bulletin de s\u00e9curit\u00e9 Siemens SSA-894058",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-894058.html"
},
{
"published_at": "2025-08-12",
"title": "Bulletin de s\u00e9curit\u00e9 Siemens SSA-355557",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-355557.html"
},
{
"published_at": "2025-08-12",
"title": "Bulletin de s\u00e9curit\u00e9 Siemens SSA-529291",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-529291.html"
},
{
"published_at": "2025-08-12",
"title": "Bulletin de s\u00e9curit\u00e9 Siemens SSA-282044",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-282044.html"
}
]
}
FKIE_CVE-2023-52871
Vulnerability from fkie_nvd - Published: 2024-05-21 16:15 - Updated: 2026-08-04 10:185.5 (Medium) - CVSS:3.1/
| Vendor | Product | Version | |
|---|---|---|---|
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * |
{
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/soc/qcom/llcc-qcom.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "cc1a1dcb411fe224f48553cfdcdfe6e61395b69c",
"status": "affected",
"version": "a3134fb09e0bc5bee76e13bf863173b86f21cf87",
"versionType": "git"
},
{
"lessThan": "5e5b85ea0f4bc484bfe4cc73ead51fa48d2366a0",
"status": "affected",
"version": "a3134fb09e0bc5bee76e13bf863173b86f21cf87",
"versionType": "git"
},
{
"lessThan": "995ee1e84e8db7fa5dcdde7dfe0bd7bb6f9bbb8c",
"status": "affected",
"version": "a3134fb09e0bc5bee76e13bf863173b86f21cf87",
"versionType": "git"
},
{
"lessThan": "f0ef883cae309bc5e8cdfcdbc1b4822732ce20a8",
"status": "affected",
"version": "a3134fb09e0bc5bee76e13bf863173b86f21cf87",
"versionType": "git"
},
{
"lessThan": "3565684309e54fa998ea27f37028d67cc3e1dff2",
"status": "affected",
"version": "a3134fb09e0bc5bee76e13bf863173b86f21cf87",
"versionType": "git"
},
{
"lessThan": "1143bfb9b055897975aeaea254da148e19524493",
"status": "affected",
"version": "a3134fb09e0bc5bee76e13bf863173b86f21cf87",
"versionType": "git"
},
{
"lessThan": "f1a1bc8775b26345aba2be278118999e7f661d3d",
"status": "affected",
"version": "a3134fb09e0bc5bee76e13bf863173b86f21cf87",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/soc/qcom/llcc-qcom.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "4.19"
},
{
"lessThan": "4.19",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.261",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.201",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.139",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.63",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.5.*",
"status": "unaffected",
"version": "6.5.12",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.2",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.7",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"configurations": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "CAB15840-253A-4FDD-A8EF-F67CC80DB8B1",
"versionEndExcluding": "5.4.261",
"versionStartIncluding": "4.19",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "AF1ADC4E-CCC4-498A-876F-5136DDD36C1D",
"versionEndExcluding": "5.10.201",
"versionStartIncluding": "5.5",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "81424D14-B38F-47B3-A1B8-BC3B60BB96EA",
"versionEndExcluding": "5.15.139",
"versionStartIncluding": "5.11",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "80E1EA7E-2788-466C-9FFB-34AFA1B052F0",
"versionEndExcluding": "6.1.63",
"versionStartIncluding": "5.16",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "825F64D9-E99F-49AA-8A7B-EF7C2965C5B2",
"versionEndExcluding": "6.5.12",
"versionStartIncluding": "6.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "4CBFF885-A4D3-4F21-B6FD-4D770034C048",
"versionEndExcluding": "6.6.2",
"versionStartIncluding": "6.6",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nsoc: qcom: llcc: Handle a second device without data corruption\n\nUsually there is only one llcc device. But if there were a second, even\na failed probe call would modify the global drv_data pointer. So check\nif drv_data is valid before overwriting it."
},
{
"lang": "es",
"value": " En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: soc: qcom: llcc: Manejar un segundo dispositivo sin corrupci\u00f3n de datos. Generalmente solo hay un dispositivo llcc. Pero si hubiera un segundo, incluso una llamada de sonda fallida modificar\u00eda el puntero global drv_data. As\u00ed que verifique si drv_data es v\u00e1lido antes de sobrescribirlo."
}
],
"id": "CVE-2023-52871",
"lastModified": "2026-08-04T10:18:46.700",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 7.1,
"baseSeverity": "HIGH",
"confidentialityImpact": "NONE",
"integrityImpact": "HIGH",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 5.2,
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"type": "Secondary"
},
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "NONE",
"baseScore": 5.5,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "NONE",
"integrityImpact": "HIGH",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
"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-2023-52871",
"options": [
{
"exploitation": "none"
},
{
"automatable": "no"
},
{
"technicalImpact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2024-05-21T18:17:57.620656Z",
"version": "2.0.3"
}
}
]
},
"published": "2024-05-21T16:15:23.907",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/1143bfb9b055897975aeaea254da148e19524493"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/3565684309e54fa998ea27f37028d67cc3e1dff2"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/5e5b85ea0f4bc484bfe4cc73ead51fa48d2366a0"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/995ee1e84e8db7fa5dcdde7dfe0bd7bb6f9bbb8c"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/cc1a1dcb411fe224f48553cfdcdfe6e61395b69c"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/f0ef883cae309bc5e8cdfcdbc1b4822732ce20a8"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/f1a1bc8775b26345aba2be278118999e7f661d3d"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/1143bfb9b055897975aeaea254da148e19524493"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/3565684309e54fa998ea27f37028d67cc3e1dff2"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/5e5b85ea0f4bc484bfe4cc73ead51fa48d2366a0"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/995ee1e84e8db7fa5dcdde7dfe0bd7bb6f9bbb8c"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/cc1a1dcb411fe224f48553cfdcdfe6e61395b69c"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/f0ef883cae309bc5e8cdfcdbc1b4822732ce20a8"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/f1a1bc8775b26345aba2be278118999e7f661d3d"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Modified",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "NVD-CWE-noinfo"
}
],
"source": "nvd@nist.gov",
"type": "Primary"
}
]
}
GHSA-W492-G7J4-GR3W
Vulnerability from github – Published: 2024-05-21 18:31 – Updated: 2025-09-26 18:31In the Linux kernel, the following vulnerability has been resolved:
soc: qcom: llcc: Handle a second device without data corruption
Usually there is only one llcc device. But if there were a second, even a failed probe call would modify the global drv_data pointer. So check if drv_data is valid before overwriting it.
{
"affected": [],
"aliases": [
"CVE-2023-52871"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-21T16:15:23Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nsoc: qcom: llcc: Handle a second device without data corruption\n\nUsually there is only one llcc device. But if there were a second, even\na failed probe call would modify the global drv_data pointer. So check\nif drv_data is valid before overwriting it.",
"id": "GHSA-w492-g7j4-gr3w",
"modified": "2025-09-26T18:31:17Z",
"published": "2024-05-21T18:31:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52871"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1143bfb9b055897975aeaea254da148e19524493"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3565684309e54fa998ea27f37028d67cc3e1dff2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5e5b85ea0f4bc484bfe4cc73ead51fa48d2366a0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/995ee1e84e8db7fa5dcdde7dfe0bd7bb6f9bbb8c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cc1a1dcb411fe224f48553cfdcdfe6e61395b69c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f0ef883cae309bc5e8cdfcdbc1b4822732ce20a8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f1a1bc8775b26345aba2be278118999e7f661d3d"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
ICSA-25-226-15
Vulnerability from csaf_cisa - Published: 2025-08-12 00:00 - Updated: 2026-02-25 07:00OESA-2024-1693 (CVE-2021-47370)
Vulnerability from osv_openeuler – Published: 2024-06-07 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:
mptcp: ensure tx skbs always have the MPTCP ext
Due to signed/unsigned comparison, the expression:
info->size_goal - skb->len > 0
evaluates to true when the size goal is smaller than the skb size. That results in lack of tx cache refill, so that the skb allocated by the core TCP code lacks the required MPTCP skb extensions.
Due to the above, syzbot is able to trigger the following WARN_ON():
WARNING: CPU: 1 PID: 810 at net/mptcp/protocol.c:1366 mptcp_sendmsg_frag+0x1362/0x1bc0 net/mptcp/protocol.c:1366 Modules linked in: CPU: 1 PID: 810 Comm: syz-executor.4 Not tainted 5.14.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:mptcp_sendmsg_frag+0x1362/0x1bc0 net/mptcp/protocol.c:1366 Code: ff 4c 8b 74 24 50 48 8b 5c 24 58 e9 0f fb ff ff e8 13 44 8b f8 4c 89 e7 45 31 ed e8 98 57 2e fe e9 81 f4 ff ff e8 fe 43 8b f8 <0f> 0b 41 bd ea ff ff ff e9 6f f4 ff ff 4c 89 e7 e8 b9 8e d2 f8 e9 RSP: 0018:ffffc9000531f6a0 EFLAGS: 00010216 RAX: 000000000000697f RBX: 0000000000000000 RCX: ffffc90012107000 RDX: 0000000000040000 RSI: ffffffff88eac9e2 RDI: 0000000000000003 RBP: ffff888078b15780 R08: 0000000000000000 R09: 0000000000000000 R10: ffffffff88eac017 R11: 0000000000000000 R12: ffff88801de0a280 R13: 0000000000006b58 R14: ffff888066278280 R15: ffff88803c2fe9c0 FS: 00007fd9f866e700(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007faebcb2f718 CR3: 00000000267cb000 CR4: 00000000001506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: __mptcp_push_pending+0x1fb/0x6b0 net/mptcp/protocol.c:1547 mptcp_release_cb+0xfe/0x210 net/mptcp/protocol.c:3003 release_sock+0xb4/0x1b0 net/core/sock.c:3206 sk_stream_wait_memory+0x604/0xed0 net/core/stream.c:145 mptcp_sendmsg+0xc39/0x1bc0 net/mptcp/protocol.c:1749 inet6_sendmsg+0x99/0xe0 net/ipv6/af_inet6.c:643 sock_sendmsg_nosec net/socket.c:704 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:724 sock_write_iter+0x2a0/0x3e0 net/socket.c:1057 call_write_iter include/linux/fs.h:2163 [inline] new_sync_write+0x40b/0x640 fs/read_write.c:507 vfs_write+0x7cf/0xae0 fs/read_write.c:594 ksys_write+0x1ee/0x250 fs/read_write.c:647 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x4665f9 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 bc ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fd9f866e188 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 000000000056c038 RCX: 00000000004665f9 RDX: 00000000000e7b78 RSI: 0000000020000000 RDI: 0000000000000003 RBP: 00000000004bfcc4 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 000000000056c038 R13: 0000000000a9fb1f R14: 00007fd9f866e300 R15: 0000000000022000
Fix the issue rewriting the relevant expression to avoid sign-related problems - note: size_goal is always >= 0.
Additionally, ensure that the skb in the tx cache always carries the relevant extension.(CVE-2021-47370)
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Fix even more out of bound writes from debugfs
CVE-2021-42327 was fixed by:
commit f23750b5b3d98653b31d4469592935ef6364ad67 Author: Thelford Williams <tdwilliamsiv@gmail.com> Date: Wed Oct 13 16:04:13 2021 -0400
drm/amdgpu: fix out of bounds write
but amdgpu_dm_debugfs.c contains more of the same issue so fix the remaining ones.
v2: * Add missing fix in dp_max_bpc_write (Harry Wentland)(CVE-2021-47489)
In the Linux kernel, the following vulnerability has been resolved:
tcp: TX zerocopy should not sense pfmemalloc status
We got a recent syzbot report [1] showing a possible misuse of pfmemalloc page status in TCP zerocopy paths.
Indeed, for pages coming from user space or other layers, using page_is_pfmemalloc() is moot, and possibly could give false positives.
There has been attempts to make page_is_pfmemalloc() more robust, but not using it in the first place in this context is probably better, removing cpu cycles.
Note to stable teams :
You need to backport 84ce071e38a6 ("net: introduce __skb_fill_page_desc_noacc") as a prereq.
Race is more probable after commit c07aea3ef4d4 ("mm: add a signature in struct page") because page_is_pfmemalloc() is now using low order bit from page->lru.next, which can change more often than page->index.
Low order bit should never be set for lru.next (when used as an anchor in LRU list), so KCSAN report is mostly a false positive.
Backporting to older kernel versions seems not necessary.
[1] BUG: KCSAN: data-race in lru_add_fn / tcp_build_frag
write to 0xffffea0004a1d2c8 of 8 bytes by task 18600 on cpu 0: __list_add include/linux/list.h:73 [inline] list_add include/linux/list.h:88 [inline] lruvec_add_folio include/linux/mm_inline.h:105 [inline] lru_add_fn+0x440/0x520 mm/swap.c:228 folio_batch_move_lru+0x1e1/0x2a0 mm/swap.c:246 folio_batch_add_and_move mm/swap.c:263 [inline] folio_add_lru+0xf1/0x140 mm/swap.c:490 filemap_add_folio+0xf8/0x150 mm/filemap.c:948 __filemap_get_folio+0x510/0x6d0 mm/filemap.c:1981 pagecache_get_page+0x26/0x190 mm/folio-compat.c:104 grab_cache_page_write_begin+0x2a/0x30 mm/folio-compat.c:116 ext4_da_write_begin+0x2dd/0x5f0 fs/ext4/inode.c:2988 generic_perform_write+0x1d4/0x3f0 mm/filemap.c:3738 ext4_buffered_write_iter+0x235/0x3e0 fs/ext4/file.c:270 ext4_file_write_iter+0x2e3/0x1210 call_write_iter include/linux/fs.h:2187 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x468/0x760 fs/read_write.c:578 ksys_write+0xe8/0x1a0 fs/read_write.c:631 __do_sys_write fs/read_write.c:643 [inline] __se_sys_write fs/read_write.c:640 [inline] __x64_sys_write+0x3e/0x50 fs/read_write.c:640 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd
read to 0xffffea0004a1d2c8 of 8 bytes by task 18611 on cpu 1: page_is_pfmemalloc include/linux/mm.h:1740 [inline] __skb_fill_page_desc include/linux/skbuff.h:2422 [inline] skb_fill_page_desc include/linux/skbuff.h:2443 [inline] tcp_build_frag+0x613/0xb20 net/ipv4/tcp.c:1018 do_tcp_sendpages+0x3e8/0xaf0 net/ipv4/tcp.c:1075 tcp_sendpage_locked net/ipv4/tcp.c:1140 [inline] tcp_sendpage+0x89/0xb0 net/ipv4/tcp.c:1150 inet_sendpage+0x7f/0xc0 net/ipv4/af_inet.c:833 kernel_sendpage+0x184/0x300 net/socket.c:3561 sock_sendpage+0x5a/0x70 net/socket.c:1054 pipe_to_sendpage+0x128/0x160 fs/splice.c:361 splice_from_pipe_feed fs/splice.c:415 [inline] __splice_from_pipe+0x222/0x4d0 fs/splice.c:559 splice_from_pipe fs/splice.c:594 [inline] generic_splice_sendpage+0x89/0xc0 fs/splice.c:743 do_splice_from fs/splice.c:764 [inline] direct_splice_actor+0x80/0xa0 fs/splice.c:931 splice_direct_to_actor+0x305/0x620 fs/splice.c:886 do_splice_direct+0xfb/0x180 fs/splice.c:974 do_sendfile+0x3bf/0x910 fs/read_write.c:1249 __do_sys_sendfile64 fs/read_write.c:1317 [inline] __se_sys_sendfile64 fs/read_write.c:1303 [inline] __x64_sys_sendfile64+0x10c/0x150 fs/read_write.c:1303 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd
value changed: 0x0000000000000000 -> 0xffffea0004a1d288
Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 18611 Comm: syz-executor.4 Not tainted 6.0.0-rc2-syzkaller-00248-ge022620b5d05-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/22/2022(CVE-2022-48689)
In the Linux kernel, the following vulnerability has been resolved:
io_uring/af_unix: disable sending io_uring over sockets
File reference cycles have caused lots of problems for io_uring in the past, and it still doesn't work exactly right and races with unix_stream_read_generic(). The safest fix would be to completely disallow sending io_uring files via sockets via SCM_RIGHT, so there are no possible cycles invloving registered files and thus rendering SCM accounting on the io_uring side unnecessary.(CVE-2023-52654)
In the Linux kernel, the following vulnerability has been resolved:
usb: aqc111: check packet for fixup for true limit
If a device sends a packet that is inbetween 0 and sizeof(u64) the value passed to skb_trim() as length will wrap around ending up as some very large value.
The driver will then proceed to parse the header located at that position, which will either oops or process some random value.
The fix is to check against sizeof(u64) rather than 0, which the driver currently does. The issue exists since the introduction of the driver.(CVE-2023-52655)
In the Linux kernel, the following vulnerability has been resolved:
crypto: s390/aes - Fix buffer overread in CTR mode
When processing the last block, the s390 ctr code will always read a whole block, even if there isn't a whole block of data left. Fix this by using the actual length left and copy it into a buffer first for processing.(CVE-2023-52669)
In the Linux kernel, the following vulnerability has been resolved:
sysv: don't call sb_bread() with pointers_lock held
syzbot is reporting sleep in atomic context in SysV filesystem [1], for sb_bread() is called with rw_spinlock held.
A "write_lock(&pointers_lock) => read_lock(&pointers_lock) deadlock" bug and a "sb_bread() with write_lock(&pointers_lock)" bug were introduced by "Replace BKL for chain locking with sysvfs-private rwlock" in Linux 2.5.12.
Then, "[PATCH] err1-40: sysvfs locking fix" in Linux 2.6.8 fixed the former bug by moving pointers_lock lock to the callers, but instead introduced a "sb_bread() with read_lock(&pointers_lock)" bug (which made this problem easier to hit).
Al Viro suggested that why not to do like get_branch()/get_block()/ find_shared() in Minix filesystem does. And doing like that is almost a revert of "[PATCH] err1-40: sysvfs locking fix" except that get_branch() from with find_shared() is called without write_lock(&pointers_lock).(CVE-2023-52699)
In the Linux kernel, the following vulnerability has been resolved:
net/usb: kalmia: Don't pass act_len in usb_bulk_msg error path
syzbot reported that act_len in kalmia_send_init_packet() is uninitialized when passing it to the first usb_bulk_msg error path. Jiri Pirko noted that it's pointless to pass it in the error path, and that the value that would be printed in the second error path would be the value of act_len from the first call to usb_bulk_msg.[1]
With this in mind, let's just not pass act_len to the usb_bulk_msg error paths.
1: https://lore.kernel.org/lkml/Y9pY61y1nwTuzMOa@nanopsycho/(CVE-2023-52703)
In the Linux kernel, the following vulnerability has been resolved:
mmc: sdio: fix possible resource leaks in some error paths
If sdio_add_func() or sdio_init_func() fails, sdio_remove_func() can not release the resources, because the sdio function is not presented in these two cases, it won't call of_node_put() or put_device().
To fix these leaks, make sdio_func_present() only control whether device_del() needs to be called or not, then always call of_node_put() and put_device().
In error case in sdio_init_func(), the reference of 'card->dev' is not get, to avoid redundant put in sdio_free_func_cis(), move the get_device() to sdio_alloc_func() and put_device() to sdio_release_func(), it can keep the get/put function be balanced.
Without this patch, while doing fault inject test, it can get the following leak reports, after this fix, the leak is gone.
unreferenced object 0xffff888112514000 (size 2048): comm "kworker/3:2", pid 65, jiffies 4294741614 (age 124.774s) hex dump (first 32 bytes): 00 e0 6f 12 81 88 ff ff 60 58 8d 06 81 88 ff ff ..o.....`X...... 10 40 51 12 81 88 ff ff 10 40 51 12 81 88 ff ff .@Q......@Q..... backtrace: [<000000009e5931da>] kmalloc_trace+0x21/0x110 [<000000002f839ccb>] mmc_alloc_card+0x38/0xb0 [mmc_core] [<0000000004adcbf6>] mmc_sdio_init_card+0xde/0x170 [mmc_core] [<000000007538fea0>] mmc_attach_sdio+0xcb/0x1b0 [mmc_core] [<00000000d4fdeba7>] mmc_rescan+0x54a/0x640 [mmc_core]
unreferenced object 0xffff888112511000 (size 2048): comm "kworker/3:2", pid 65, jiffies 4294741623 (age 124.766s) hex dump (first 32 bytes): 00 40 51 12 81 88 ff ff e0 58 8d 06 81 88 ff ff .@Q......X...... 10 10 51 12 81 88 ff ff 10 10 51 12 81 88 ff ff ..Q.......Q..... backtrace: [<000000009e5931da>] kmalloc_trace+0x21/0x110 [<00000000fcbe706c>] sdio_alloc_func+0x35/0x100 [mmc_core] [<00000000c68f4b50>] mmc_attach_sdio.cold.18+0xb1/0x395 [mmc_core] [<00000000d4fdeba7>] mmc_rescan+0x54a/0x640 mmc_core
In the Linux kernel, the following vulnerability has been resolved:
bpf, sockmap: Don't let sock_map_{close,destroy,unhash} call itself
sock_map proto callbacks should never call themselves by design. Protect against bugs like [1] and break out of the recursive loop to avoid a stack overflow in favor of a resource leak.
[1] https://lore.kernel.org/all/00000000000073b14905ef2e7401@google.com/(CVE-2023-52735)
In the Linux kernel, the following vulnerability has been resolved:
ALSA: hda: Do not unset preset when cleaning up codec
Several functions that take part in codec's initialization and removal are re-used by ASoC codec drivers implementations. Drivers mimic the behavior of hda_codec_driver_probe/remove() found in sound/pci/hda/hda_bind.c with their component->probe/remove() instead.
One of the reasons for that is the expectation of snd_hda_codec_device_new() to receive a valid pointer to an instance of struct snd_card. This expectation can be met only once sound card components probing commences.
As ASoC sound card may be unbound without codec device being actually removed from the system, unsetting ->preset in snd_hda_codec_cleanup_for_unbind() interferes with module unload -> load scenario causing null-ptr-deref. Preset is assigned only once, during device/driver matching whereas ASoC codec driver's module reloading may occur several times throughout the lifetime of an audio stack.(CVE-2023-52736)
In the Linux kernel, the following vulnerability has been resolved:
arm64: Restrict CPU_BIG_ENDIAN to GNU as or LLVM IAS 15.x or newer
Prior to LLVM 15.0.0, LLVM's integrated assembler would incorrectly byte-swap NOP when compiling for big-endian, and the resulting series of bytes happened to match the encoding of FNMADD S21, S30, S0, S0.
This went unnoticed until commit:
34f66c4c4d5518c1 ("arm64: Use a positive cpucap for FP/SIMD")
Prior to that commit, the kernel would always enable the use of FPSIMD early in boot when __cpu_setup() initialized CPACR_EL1, and so usage of FNMADD within the kernel was not detected, but could result in the corruption of user or kernel FPSIMD state.
After that commit, the instructions happen to trap during boot prior to FPSIMD being detected and enabled, e.g.
| Unhandled 64-bit el1h sync exception on CPU0, ESR 0x000000001fe00000 -- ASIMD | CPU: 0 PID: 0 Comm: swapper Not tainted 6.6.0-rc3-00013-g34f66c4c4d55 #1 | Hardware name: linux,dummy-virt (DT) | pstate: 400000c9 (nZcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) | pc : __pi_strcmp+0x1c/0x150 | lr : populate_properties+0xe4/0x254 | sp : ffffd014173d3ad0 | x29: ffffd014173d3af0 x28: fffffbfffddffcb8 x27: 0000000000000000 | x26: 0000000000000058 x25: fffffbfffddfe054 x24: 0000000000000008 | x23: fffffbfffddfe000 x22: fffffbfffddfe000 x21: fffffbfffddfe044 | x20: ffffd014173d3b70 x19: 0000000000000001 x18: 0000000000000005 | x17: 0000000000000010 x16: 0000000000000000 x15: 00000000413e7000 | x14: 0000000000000000 x13: 0000000000001bcc x12: 0000000000000000 | x11: 00000000d00dfeed x10: ffffd414193f2cd0 x9 : 0000000000000000 | x8 : 0101010101010101 x7 : ffffffffffffffc0 x6 : 0000000000000000 | x5 : 0000000000000000 x4 : 0101010101010101 x3 : 000000000000002a | x2 : 0000000000000001 x1 : ffffd014171f2988 x0 : fffffbfffddffcb8 | Kernel panic - not syncing: Unhandled exception | CPU: 0 PID: 0 Comm: swapper Not tainted 6.6.0-rc3-00013-g34f66c4c4d55 #1 | Hardware name: linux,dummy-virt (DT) | Call trace: | dump_backtrace+0xec/0x108 | show_stack+0x18/0x2c | dump_stack_lvl+0x50/0x68 | dump_stack+0x18/0x24 | panic+0x13c/0x340 | el1t_64_irq_handler+0x0/0x1c | el1_abort+0x0/0x5c | el1h_64_sync+0x64/0x68 | __pi_strcmp+0x1c/0x150 | unflatten_dt_nodes+0x1e8/0x2d8 | __unflatten_device_tree+0x5c/0x15c | unflatten_device_tree+0x38/0x50 | setup_arch+0x164/0x1e0 | start_kernel+0x64/0x38c | __primary_switched+0xbc/0xc4
Restrict CONFIG_CPU_BIG_ENDIAN to a known good assembler, which is either GNU as or LLVM's IAS 15.0.0 and newer, which contains the linked commit.(CVE-2023-52750)
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix use-after-free bug in cifs_debug_data_proc_show()
Skip SMB sessions that are being teared down (e.g. @ses->ses_status == SES_EXITING) in cifs_debug_data_proc_show() to avoid use-after-free in @ses.
This fixes the following GPF when reading from /proc/fs/cifs/DebugData while mounting and umounting
[ 816.251274] general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6d81: 0000 [#1] PREEMPT SMP NOPTI ... [ 816.260138] Call Trace: [ 816.260329] <TASK> [ 816.260499] ? die_addr+0x36/0x90 [ 816.260762] ? exc_general_protection+0x1b3/0x410 [ 816.261126] ? asm_exc_general_protection+0x26/0x30 [ 816.261502] ? cifs_debug_tcon+0xbd/0x240 [cifs] [ 816.261878] ? cifs_debug_tcon+0xab/0x240 [cifs] [ 816.262249] cifs_debug_data_proc_show+0x516/0xdb0 [cifs] [ 816.262689] ? seq_read_iter+0x379/0x470 [ 816.262995] seq_read_iter+0x118/0x470 [ 816.263291] proc_reg_read_iter+0x53/0x90 [ 816.263596] ? srso_alias_return_thunk+0x5/0x7f [ 816.263945] vfs_read+0x201/0x350 [ 816.264211] ksys_read+0x75/0x100 [ 816.264472] do_syscall_64+0x3f/0x90 [ 816.264750] entry_SYSCALL_64_after_hwframe+0x6e/0xd8 [ 816.265135] RIP: 0033:0x7fd5e669d381(CVE-2023-52752)
In the Linux kernel, the following vulnerability has been resolved:
gfs2: ignore negated quota changes
When lots of quota changes are made, there may be cases in which an inode's quota information is increased and then decreased, such as when blocks are added to a file, then deleted from it. If the timing is right, function do_qc can add pending quota changes to a transaction, then later, another call to do_qc can negate those changes, resulting in a net gain of 0. The quota_change information is recorded in the qc buffer (and qd element of the inode as well). The buffer is added to the transaction by the first call to do_qc, but a subsequent call changes the value from non-zero back to zero. At that point it's too late to remove the buffer_head from the transaction. Later, when the quota sync code is called, the zero-change qd element is discovered and flagged as an assert warning. If the fs is mounted with errors=panic, the kernel will panic.
This is usually seen when files are truncated and the quota changes are negated by punch_hole/truncate which uses gfs2_quota_hold and gfs2_quota_unhold rather than block allocations that use gfs2_quota_lock and gfs2_quota_unlock which automatically do quota sync.
This patch solves the problem by adding a check to qd_check_sync such that net-zero quota changes already added to the transaction are no longer deemed necessary to be synced, and skipped.
In this case references are taken for the qd and the slot from do_qc so those need to be put. The normal sequence of events for a normal non-zero quota change is as follows:
gfs2_quota_change do_qc qd_hold slot_hold
Later, when the changes are to be synced:
gfs2_quota_sync qd_fish qd_check_sync gets qd ref via lockref_get_not_dead do_sync do_qc(QC_SYNC) qd_put lockref_put_or_lock qd_unlock qd_put lockref_put_or_lock
In the net-zero change case, we add a check to qd_check_sync so it puts the qd and slot references acquired in gfs2_quota_change and skip the unneeded sync.(CVE-2023-52759)
In the Linux kernel, the following vulnerability has been resolved:
s390/dasd: protect device queue against concurrent access
In dasd_profile_start() the amount of requests on the device queue are counted. The access to the device queue is unprotected against concurrent access. With a lot of parallel I/O, especially with alias devices enabled, the device queue can change while dasd_profile_start() is accessing the queue. In the worst case this leads to a kernel panic due to incorrect pointer accesses.
Fix this by taking the device lock before accessing the queue and counting the requests. Additionally the check for a valid profile data pointer can be done earlier to avoid unnecessary locking in a hot path.(CVE-2023-52774)
In the Linux kernel, the following vulnerability has been resolved:
tty: vcc: Add check for kstrdup() in vcc_probe()
Add check for the return value of kstrdup() and return the error, if it fails in order to avoid NULL pointer dereference.(CVE-2023-52789)
In the Linux kernel, the following vulnerability has been resolved:
vhost-vdpa: fix use after free in vhost_vdpa_probe()
The put_device() calls vhost_vdpa_release_dev() which calls ida_simple_remove() and frees "v". So this call to ida_simple_remove() is a use after free and a double free.(CVE-2023-52795)
In the Linux kernel, the following vulnerability has been resolved:
iio: adc: stm32-adc: harden against NULL pointer deref in stm32_adc_probe()
of_match_device() may fail and returns a NULL pointer.
In practice there is no known reasonable way to trigger this, but in case one is added in future, harden the code by adding the check(CVE-2023-52802)
In the Linux kernel, the following vulnerability has been resolved:
fs/jfs: Add validity check for db_maxag and db_agpref
Both db_maxag and db_agpref are used as the index of the db_agfree array, but there is currently no validity check for db_maxag and db_agpref, which can lead to errors.
The following is related bug reported by Syzbot:
UBSAN: array-index-out-of-bounds in fs/jfs/jfs_dmap.c:639:20 index 7936 is out of range for type 'atomic_t[128]'
Add checking that the values of db_maxag and db_agpref are valid indexes for the db_agfree array.(CVE-2023-52804)
In the Linux kernel, the following vulnerability has been resolved:
jfs: fix array-index-out-of-bounds in diAlloc
Currently there is not check against the agno of the iag while allocating new inodes to avoid fragmentation problem. Added the check which is required.(CVE-2023-52805)
In the Linux kernel, the following vulnerability has been resolved:
scsi: hisi_sas: Set debugfs_dir pointer to NULL after removing debugfs
If init debugfs failed during device registration due to memory allocation failure, debugfs_remove_recursive() is called, after which debugfs_dir is not set to NULL. debugfs_remove_recursive() will be called again during device removal. As a result, illegal pointer is accessed.
[ 1665.467244] hisi_sas_v3_hw 0000:b4:02.0: failed to init debugfs! ... [ 1669.836708] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a0 [ 1669.872669] pc : down_write+0x24/0x70 [ 1669.876315] lr : down_write+0x1c/0x70 [ 1669.879961] sp : ffff000036f53a30 [ 1669.883260] x29: ffff000036f53a30 x28: ffffa027c31549f8 [ 1669.888547] x27: ffffa027c3140000 x26: 0000000000000000 [ 1669.893834] x25: ffffa027bf37c270 x24: ffffa027bf37c270 [ 1669.899122] x23: ffff0000095406b8 x22: ffff0000095406a8 [ 1669.904408] x21: 0000000000000000 x20: ffffa027bf37c310 [ 1669.909695] x19: 00000000000000a0 x18: ffff8027dcd86f10 [ 1669.914982] x17: 0000000000000000 x16: 0000000000000000 [ 1669.920268] x15: 0000000000000000 x14: ffffa0274014f870 [ 1669.925555] x13: 0000000000000040 x12: 0000000000000228 [ 1669.930842] x11: 0000000000000020 x10: 0000000000000bb0 [ 1669.936129] x9 : ffff000036f537f0 x8 : ffff80273088ca10 [ 1669.941416] x7 : 000000000000001d x6 : 00000000ffffffff [ 1669.946702] x5 : ffff000008a36310 x4 : ffff80273088be00 [ 1669.951989] x3 : ffff000009513e90 x2 : 0000000000000000 [ 1669.957276] x1 : 00000000000000a0 x0 : ffffffff00000001 [ 1669.962563] Call trace: [ 1669.965000] down_write+0x24/0x70 [ 1669.968301] debugfs_remove_recursive+0x5c/0x1b0 [ 1669.972905] hisi_sas_debugfs_exit+0x24/0x30 [hisi_sas_main] [ 1669.978541] hisi_sas_v3_remove+0x130/0x150 [hisi_sas_v3_hw] [ 1669.984175] pci_device_remove+0x48/0xd8 [ 1669.988082] device_release_driver_internal+0x1b4/0x250 [ 1669.993282] device_release_driver+0x28/0x38 [ 1669.997534] pci_stop_bus_device+0x84/0xb8 [ 1670.001611] pci_stop_and_remove_bus_device_locked+0x24/0x40 [ 1670.007244] remove_store+0xfc/0x140 [ 1670.010802] dev_attr_store+0x44/0x60 [ 1670.014448] sysfs_kf_write+0x58/0x80 [ 1670.018095] kernfs_fop_write+0xe8/0x1f0 [ 1670.022000] __vfs_write+0x60/0x190 [ 1670.025472] vfs_write+0xac/0x1c0 [ 1670.028771] ksys_write+0x6c/0xd8 [ 1670.032071] __arm64_sys_write+0x24/0x30 [ 1670.035977] el0_svc_common+0x78/0x130 [ 1670.039710] el0_svc_handler+0x38/0x78 [ 1670.043442] el0_svc+0x8/0xc
To fix this, set debugfs_dir to NULL after debugfs_remove_recursive().(CVE-2023-52808)
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Fix potential null pointer derefernce
The amdgpu_ras_get_context may return NULL if device not support ras feature, so add check before using.(CVE-2023-52814)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd: Fix UBSAN array-index-out-of-bounds for SMU7
For pptable structs that use flexible array sizes, use flexible arrays.(CVE-2023-52818)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd: Fix UBSAN array-index-out-of-bounds for Polaris and Tonga
For pptable structs that use flexible array sizes, use flexible arrays.(CVE-2023-52819)
In the Linux kernel, the following vulnerability has been resolved:
drm/panel/panel-tpo-tpg110: fix a possible null pointer dereference
In tpg110_get_modes(), the return value of drm_mode_duplicate() is assigned to mode, which will lead to a NULL pointer dereference on failure of drm_mode_duplicate(). Add a check to avoid npd.(CVE-2023-52826)
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: don't return unset power in ieee80211_get_tx_power()
We can get a UBSAN warning if ieee80211_get_tx_power() returns the INT_MIN value mac80211 internally uses for "unset power level".
UBSAN: signed-integer-overflow in net/wireless/nl80211.c:3816:5 -2147483648 * 100 cannot be represented in type 'int' CPU: 0 PID: 20433 Comm: insmod Tainted: G WC OE Call Trace: dump_stack+0x74/0x92 ubsan_epilogue+0x9/0x50 handle_overflow+0x8d/0xd0 __ubsan_handle_mul_overflow+0xe/0x10 nl80211_send_iface+0x688/0x6b0 [cfg80211] [...] cfg80211_register_wdev+0x78/0xb0 [cfg80211] cfg80211_netdev_notifier_call+0x200/0x620 [cfg80211] [...] ieee80211_if_add+0x60e/0x8f0 [mac80211] ieee80211_register_hw+0xda5/0x1170 [mac80211]
In this case, simply return an error instead, to indicate that no data is available.(CVE-2023-52832)
In the Linux kernel, the following vulnerability has been resolved:
locking/ww_mutex/test: Fix potential workqueue corruption
In some cases running with the test-ww_mutex code, I was seeing odd behavior where sometimes it seemed flush_workqueue was returning before all the work threads were finished.
Often this would cause strange crashes as the mutexes would be freed while they were being used.
Looking at the code, there is a lifetime problem as the controlling thread that spawns the work allocates the "struct stress" structures that are passed to the workqueue threads. Then when the workqueue threads are finished, they free the stress struct that was passed to them.
Unfortunately the workqueue work_struct node is in the stress struct. Which means the work_struct is freed before the work thread returns and while flush_workqueue is waiting.
It seems like a better idea to have the controlling thread both allocate and free the stress structures, so that we can be sure we don't corrupt the workqueue by freeing the structure prematurely.
So this patch reworks the test to do so, and with this change I no longer see the early flush_workqueue returns.(CVE-2023-52836)
In the Linux kernel, the following vulnerability has been resolved:
tipc: Change nla_policy for bearer-related names to NLA_NUL_STRING
syzbot reported the following uninit-value access issue [1]:
===================================================== BUG: KMSAN: uninit-value in strlen lib/string.c:418 [inline] BUG: KMSAN: uninit-value in strstr+0xb8/0x2f0 lib/string.c:756 strlen lib/string.c:418 [inline] strstr+0xb8/0x2f0 lib/string.c:756 tipc_nl_node_reset_link_stats+0x3ea/0xb50 net/tipc/node.c:2595 genl_family_rcv_msg_doit net/netlink/genetlink.c:971 [inline] genl_family_rcv_msg net/netlink/genetlink.c:1051 [inline] genl_rcv_msg+0x11ec/0x1290 net/netlink/genetlink.c:1066 netlink_rcv_skb+0x371/0x650 net/netlink/af_netlink.c:2545 genl_rcv+0x40/0x60 net/netlink/genetlink.c:1075 netlink_unicast_kernel net/netlink/af_netlink.c:1342 [inline] netlink_unicast+0xf47/0x1250 net/netlink/af_netlink.c:1368 netlink_sendmsg+0x1238/0x13d0 net/netlink/af_netlink.c:1910 sock_sendmsg_nosec net/socket.c:730 [inline] sock_sendmsg net/socket.c:753 [inline] _syssendmsg+0x9c2/0xd60 net/socket.c:2541 _sys_sendmsg+0x28d/0x3c0 net/socket.c:2595 __sys_sendmsg net/socket.c:2624 [inline] __do_sys_sendmsg net/socket.c:2633 [inline] __se_sys_sendmsg net/socket.c:2631 [inline] __x64_sys_sendmsg+0x307/0x490 net/socket.c:2631 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd
Uninit was created at: slab_post_alloc_hook+0x12f/0xb70 mm/slab.h:767 slab_alloc_node mm/slub.c:3478 [inline] kmem_cache_alloc_node+0x577/0xa80 mm/slub.c:3523 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:559 __alloc_skb+0x318/0x740 net/core/skbuff.c:650 alloc_skb include/linux/skbuff.h:1286 [inline] netlink_alloc_large_skb net/netlink/af_netlink.c:1214 [inline] netlink_sendmsg+0xb34/0x13d0 net/netlink/af_netlink.c:1885 sock_sendmsg_nosec net/socket.c:730 [inline] sock_sendmsg net/socket.c:753 [inline] _syssendmsg+0x9c2/0xd60 net/socket.c:2541 _sys_sendmsg+0x28d/0x3c0 net/socket.c:2595 __sys_sendmsg net/socket.c:2624 [inline] __do_sys_sendmsg net/socket.c:2633 [inline] __se_sys_sendmsg net/socket.c:2631 [inline] __x64_sys_sendmsg+0x307/0x490 net/socket.c:2631 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd
TIPC bearer-related names including link names must be null-terminated strings. If a link name which is not null-terminated is passed through netlink, strstr() and similar functions can cause buffer overrun. This causes the above issue.
This patch changes the nla_policy for bearer-related names from NLA_STRING to NLA_NUL_STRING. This resolves the issue by ensuring that only null-terminated strings are accepted as bearer-related names.
syzbot reported similar uninit-value issue related to bearer names [2]. The root cause of this issue is that a non-null-terminated bearer name was passed. This patch also resolved this issue.(CVE-2023-52845)
In the Linux kernel, the following vulnerability has been resolved:
clk: mediatek: clk-mt7629: Add check for mtk_alloc_clk_data
Add the check for the return value of mtk_alloc_clk_data() in order to avoid NULL pointer dereference.(CVE-2023-52858)
In the Linux kernel, the following vulnerability has been resolved:
perf: hisi: Fix use-after-free when register pmu fails
When we fail to register the uncore pmu, the pmu context may not been allocated. The error handing will call cpuhp_state_remove_instance() to call uncore pmu offline callback, which migrate the pmu context. Since that's liable to lead to some kind of use-after-free.
Use cpuhp_state_remove_instance_nocalls() instead of cpuhp_state_remove_instance() so that the notifiers don't execute after the PMU device has been failed to register.(CVE-2023-52859)
In the Linux kernel, the following vulnerability has been resolved:
platform/x86: wmi: Fix opening of char device
Since commit fa1f68db6ca7 ("drivers: misc: pass miscdevice pointer via file private data"), the miscdevice stores a pointer to itself inside filp->private_data, which means that private_data will not be NULL when wmi_char_open() is called. This might cause memory corruption should wmi_char_open() be unable to find its driver, something which can happen when the associated WMI device is deleted in wmi_free_devices().
Fix the problem by using the miscdevice pointer to retrieve the WMI device data associated with a char device using container_of(). This also avoids wmi_char_open() picking a wrong WMI device bound to a driver with the same name as the original driver.(CVE-2023-52864)
In the Linux kernel, the following vulnerability has been resolved:
soc: qcom: llcc: Handle a second device without data corruption
Usually there is only one llcc device. But if there were a second, even a failed probe call would modify the global drv_data pointer. So check if drv_data is valid before overwriting it.(CVE-2023-52871)
In the Linux kernel, the following vulnerability has been resolved:
can: dev: can_put_echo_skb(): don't crash kernel if can_priv::echo_skb is accessed out of bounds
If the "struct can_priv::echoo_skb" is accessed out of bounds, this would cause a kernel crash. Instead, issue a meaningful warning message and return with an error.(CVE-2023-52878)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix memory leak in dm_sw_fini()
After destroying dmub_srv, the memory associated with it is not freed, causing a memory leak:
unreferenced object 0xffff896302b45800 (size 1024): comm "(udev-worker)", pid 222, jiffies 4294894636 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 6265fd77): [<ffffffff993495ed>] kmalloc_trace+0x29d/0x340 [<ffffffffc0ea4a94>] dm_dmub_sw_init+0xb4/0x450 [amdgpu] [<ffffffffc0ea4e55>] dm_sw_init+0x15/0x2b0 [amdgpu] [<ffffffffc0ba8557>] amdgpu_device_init+0x1417/0x24e0 [amdgpu] [<ffffffffc0bab285>] amdgpu_driver_load_kms+0x15/0x190 [amdgpu] [<ffffffffc0ba09c7>] amdgpu_pci_probe+0x187/0x4e0 [amdgpu] [<ffffffff9968fd1e>] local_pci_probe+0x3e/0x90 [<ffffffff996918a3>] pci_device_probe+0xc3/0x230 [<ffffffff99805872>] really_probe+0xe2/0x480 [<ffffffff99805c98>] __driver_probe_device+0x78/0x160 [<ffffffff99805daf>] driver_probe_device+0x1f/0x90 [<ffffffff9980601e>] __driver_attach+0xce/0x1c0 [<ffffffff99803170>] bus_for_each_dev+0x70/0xc0 [<ffffffff99804822>] bus_add_driver+0x112/0x210 [<ffffffff99807245>] driver_register+0x55/0x100 [<ffffffff990012d1>] do_one_initcall+0x41/0x300
Fix this by freeing dmub_srv after destroying it.(CVE-2024-26833)
In the Linux kernel, the following vulnerability has been resolved:
crypto: xilinx - call finalize with bh disabled
When calling crypto_finalize_request, BH should be disabled to avoid triggering the following calltrace:
------------[ cut here ]------------
WARNING: CPU: 2 PID: 74 at crypto/crypto_engine.c:58 crypto_finalize_request+0xa0/0x118
Modules linked in: cryptodev(O)
CPU: 2 PID: 74 Comm: firmware:zynqmp Tainted: G O 6.8.0-rc1-yocto-standard #323
Hardware name: ZynqMP ZCU102 Rev1.0 (DT)
pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : crypto_finalize_request+0xa0/0x118
lr : crypto_finalize_request+0x104/0x118
sp : ffffffc085353ce0
x29: ffffffc085353ce0 x28: 0000000000000000 x27: ffffff8808ea8688
x26: ffffffc081715038 x25: 0000000000000000 x24: ffffff880100db00
x23: ffffff880100da80 x22: 0000000000000000 x21: 0000000000000000
x20: ffffff8805b14000 x19: ffffff880100da80 x18: 0000000000010450
x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
x14: 0000000000000003 x13: 0000000000000000 x12: ffffff880100dad0
x11: 0000000000000000 x10: ffffffc0832dcd08 x9 : ffffffc0812416d8
x8 : 00000000000001f4 x7 : ffffffc0830d2830 x6 : 0000000000000001
x5 : ffffffc082091000 x4 : ffffffc082091658 x3 : 0000000000000000
x2 : ffffffc7f9653000 x1 : 0000000000000000 x0 : ffffff8802d20000
Call trace:
crypto_finalize_request+0xa0/0x118
crypto_finalize_aead_request+0x18/0x30
zynqmp_handle_aes_req+0xcc/0x388
crypto_pump_work+0x168/0x2d8
kthread_worker_fn+0xfc/0x3a0
kthread+0x118/0x138
ret_from_fork+0x10/0x20
irq event stamp: 40
hardirqs last enabled at (39): [<ffffffc0812416f8>] _raw_spin_unlock_irqrestore+0x70/0xb0
hardirqs last disabled at (40): [<ffffffc08122d208>] el1_dbg+0x28/0x90
softirqs last enabled at (36): [<ffffffc080017dec>] kernel_neon_begin+0x8c/0xf0
softirqs last disabled at (34): [<ffffffc080017dc0>] kernel_neon_begin+0x60/0xf0
---[ end trace 0000000000000000 ]---(CVE-2024-26877)
In the Linux kernel, the following vulnerability has been resolved:
USB: core: Fix deadlock in usb_deauthorize_interface()
Among the attribute file callback routines in drivers/usb/core/sysfs.c, the interface_authorized_store() function is the only one which acquires a device lock on an ancestor device: It calls usb_deauthorize_interface(), which locks the interface's parent USB device.
The will lead to deadlock if another process already owns that lock and tries to remove the interface, whether through a configuration change or because the device has been disconnected. As part of the removal procedure, device_del() waits for all ongoing sysfs attribute callbacks to complete. But usb_deauthorize_interface() can't complete until the device lock has been released, and the lock won't be released until the removal has finished.
The mechanism provided by sysfs to prevent this kind of deadlock is to use the sysfs_break_active_protection() function, which tells sysfs not to wait for the attribute callback.
Reported-and-tested by: Yue Sun <samsun1006219@gmail.com> Reported by: xingwei lee <xrivendell7@gmail.com>(CVE-2024-26934)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: Fix potential data-race in __nft_expr_type_get()
nft_unregister_expr() can concurrent with __nft_expr_type_get(), and there is not any protection when iterate over nf_tables_expressions list in __nft_expr_type_get(). Therefore, there is potential data-race of nf_tables_expressions list entry.
Use list_for_each_entry_rcu() to iterate over nf_tables_expressions list in __nft_expr_type_get(), and use rcu_read_lock() in the caller nft_expr_type_get() to protect the entire type query process.(CVE-2024-27020)
In the Linux kernel, the following vulnerability has been resolved:
firewire: nosy: ensure user_length is taken into account when fetching packet contents
Ensure that packet_buffer_get respects the user_length provided. If the length of the head packet exceeds the user_length, packet_buffer_get will now return 0 to signify to the user that no data were read and a larger buffer size is required. Helps prevent user space overflows.(CVE-2024-27401)
In the Linux kernel, the following vulnerability has been resolved:
efi/capsule-loader: fix incorrect allocation size
gcc-14 notices that the allocation with sizeof(void) on 32-bit architectures is not enough for a 64-bit phys_addr_t:
drivers/firmware/efi/capsule-loader.c: In function 'efi_capsule_open': drivers/firmware/efi/capsule-loader.c:295:24: error: allocation of insufficient size '4' for type 'phys_addr_t' {aka 'long long unsigned int'} with size '8' [-Werror=alloc-size] 295 | cap_info->phys = kzalloc(sizeof(void *), GFP_KERNEL); | ^
Use the correct type instead here.(CVE-2024-27413)
In the Linux kernel, the following vulnerability has been resolved:
usb: udc: remove warning when queue disabled ep
It is possible trigger below warning message from mass storage function,
WARNING: CPU: 6 PID: 3839 at drivers/usb/gadget/udc/core.c:294 usb_ep_queue+0x7c/0x104 pc : usb_ep_queue+0x7c/0x104 lr : fsg_main_thread+0x494/0x1b3c
Root cause is mass storage function try to queue request from main thread, but other thread may already disable ep when function disable.
As there is no function failure in the driver, in order to avoid effort to fix warning, change WARN_ON_ONCE() in usb_ep_queue() to pr_debug().(CVE-2024-35822)
In the Linux kernel, the following vulnerability has been resolved:
vt: fix unicode buffer corruption when deleting characters
This is the same issue that was fixed for the VGA text buffer in commit 39cdb68c64d8 ("vt: fix memory overlapping when deleting chars in the buffer"). The cure is also the same i.e. replace memcpy() with memmove() due to the overlaping buffers.(CVE-2024-35823)
In the Linux kernel, the following vulnerability has been resolved:
mptcp: use OPTION_MPTCP_MPJ_SYNACK in subflow_finish_connect()
subflow_finish_connect() uses four fields (backup, join_id, thmac, none) that may contain garbage unless OPTION_MPTCP_MPJ_SYNACK has been set in mptcp_parse_option()(CVE-2024-35840)
In the Linux kernel, the following vulnerability has been resolved:
x86/mm/pat: fix VM_PAT handling in COW mappings
PAT handling won't do the right thing in COW mappings: the first PTE (or, in fact, all PTEs) can be replaced during write faults to point at anon folios. Reliably recovering the correct PFN and cachemode using follow_phys() from PTEs will not work in COW mappings.
Using follow_phys(), we might just get the address+protection of the anon folio (which is very wrong), or fail on swap/nonswap entries, failing follow_phys() and triggering a WARN_ON_ONCE() in untrack_pfn() and track_pfn_copy(), not properly calling free_pfn_range().
In free_pfn_range(), we either wouldn't call memtype_free() or would call it with the wrong range, possibly leaking memory.
To fix that, let's update follow_phys() to refuse returning anon folios, and fallback to using the stored PFN inside vma->vm_pgoff for COW mappings if we run into that.
We will now properly handle untrack_pfn() with COW mappings, where we don't need the cachemode. We'll have to fail fork()->track_pfn_copy() if the first page was replaced by an anon folio, though: we'd have to store the cachemode in the VMA to make this work, likely growing the VMA size.
For now, lets keep it simple and let track_pfn_copy() just fail in that case: it would have failed in the past with swap/nonswap entries already, and it would have done the wrong thing with anon folios.
Simple reproducer to trigger the WARN_ON_ONCE() in untrack_pfn():
<--- C reproducer ---> #include <stdio.h> #include <sys/mman.h> #include <unistd.h> #include <liburing.h>
int main(void) { struct io_uring_params p = {}; int ring_fd; size_t size; char *map;
ring_fd = io_uring_setup(1, &p);
if (ring_fd < 0) {
perror("io_uring_setup");
return 1;
}
size = p.sq_off.array + p.sq_entries * sizeof(unsigned);
/* Map the submission queue ring MAP_PRIVATE */
map = mmap(0, size, PROT_READ | PROT_WRITE, MAP_PRIVATE,
ring_fd, IORING_OFF_SQ_RING);
if (map == MAP_FAILED) {
perror("mmap");
return 1;
}
/* We have at least one page. Let's COW it. */
*map = 0;
pause();
return 0;
} <--- C reproducer --->
On a system with 16 GiB RAM and swap configured: # ./iouring & # memhog 16G # killall iouring [ 301.552930] ------------[ cut here ]------------ [ 301.553285] WARNING: CPU: 7 PID: 1402 at arch/x86/mm/pat/memtype.c:1060 untrack_pfn+0xf4/0x100 [ 301.553989] Modules linked in: binfmt_misc nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_g [ 301.558232] CPU: 7 PID: 1402 Comm: iouring Not tainted 6.7.5-100.fc38.x86_64 #1 [ 301.558772] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebu4 [ 301.559569] RIP: 0010:untrack_pfn+0xf4/0x100 [ 301.559893] Code: 75 c4 eb cf 48 8b 43 10 8b a8 e8 00 00 00 3b 6b 28 74 b8 48 8b 7b 30 e8 ea 1a f7 000 [ 301.561189] RSP: 0018:ffffba2c0377fab8 EFLAGS: 00010282 [ 301.561590] RAX: 00000000ffffffea RBX: ffff9208c8ce9cc0 RCX: 000000010455e047 [ 301.562105] RDX: 07fffffff0eb1e0a RSI: 0000000000000000 RDI: ffff9208c391d200 [ 301.562628] RBP: 0000000000000000 R08: ffffba2c0377fab8 R09: 0000000000000000 [ 301.563145] R10: ffff9208d2292d50 R11: 0000000000000002 R12: 00007fea890e0000 [ 301.563669] R13: 0000000000000000 R14: ffffba2c0377fc08 R15: 0000000000000000 [ 301.564186] FS: 0000000000000000(0000) GS:ffff920c2fbc0000(0000) knlGS:0000000000000000 [ 301.564773] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 301.565197] CR2: 00007fea88ee8a20 CR3: 00000001033a8000 CR4: 0000000000750ef0 [ 301.565725] PKRU: 55555554 [ 301.565944] Call Trace: [ 301.566148] <TASK> [ 301.566325] ? untrack_pfn+0xf4/0x100 [ 301.566618] ? __warn+0x81/0x130 [ 301.566876] ? untrack_pfn+0xf4/0x100 [ 3 ---truncated---(CVE-2024-35877)
In the Linux kernel, the following vulnerability has been resolved:
dma-direct: Leak pages on dma_set_decrypted() failure
On TDX it is possible for the untrusted host to cause set_memory_encrypted() or set_memory_decrypted() to fail such that an error is returned and the resulting memory is shared. Callers need to take care to handle these errors to avoid returning decrypted (shared) memory to the page allocator, which could lead to functional or security issues.
DMA could free decrypted/shared pages if dma_set_decrypted() fails. This should be a rare case. Just leak the pages in this case instead of freeing them.(CVE-2024-35939)
In the Linux kernel, the following vulnerability has been resolved:
drm/client: Fully protect modes[] with dev->mode_config.mutex
The modes[] array contains pointers to modes on the connectors' mode lists, which are protected by dev->mode_config.mutex. Thus we need to extend modes[] the same protection or by the time we use it the elements may already be pointing to freed/reused memory.(CVE-2024-35950)
In the Linux kernel, the following vulnerability has been resolved:
btrfs: qgroup: fix qgroup prealloc rsv leak in subvolume operations
Create subvolume, create snapshot and delete subvolume all use btrfs_subvolume_reserve_metadata() to reserve metadata for the changes done to the parent subvolume's fs tree, which cannot be mediated in the normal way via start_transaction. When quota groups (squota or qgroups) are enabled, this reserves qgroup metadata of type PREALLOC. Once the operation is associated to a transaction, we convert PREALLOC to PERTRANS, which gets cleared in bulk at the end of the transaction.
However, the error paths of these three operations were not implementing this lifecycle correctly. They unconditionally converted the PREALLOC to PERTRANS in a generic cleanup step regardless of errors or whether the operation was fully associated to a transaction or not. This resulted in error paths occasionally converting this rsv to PERTRANS without calling record_root_in_trans successfully, which meant that unless that root got recorded in the transaction by some other thread, the end of the transaction would not free that root's PERTRANS, leaking it. Ultimately, this resulted in hitting a WARN in CONFIG_BTRFS_DEBUG builds at unmount for the leaked reservation.
The fix is to ensure that every qgroup PREALLOC reservation observes the following properties:
- any failure before record_root_in_trans is called successfully results in freeing the PREALLOC reservation.
- after record_root_in_trans, we convert to PERTRANS, and now the transaction owns freeing the reservation.
This patch enforces those properties on the three operations. Without it, generic/269 with squotas enabled at mkfs time would fail in ~5-10 runs on my system. With this patch, it ran successfully 1000 times in a row.(CVE-2024-35956)
In the Linux kernel, the following vulnerability has been resolved:
net: ena: Fix incorrect descriptor free behavior
ENA has two types of TX queues: - queues which only process TX packets arriving from the network stack - queues which only process TX packets forwarded to it by XDP_REDIRECT or XDP_TX instructions
The ena_free_tx_bufs() cycles through all descriptors in a TX queue and unmaps + frees every descriptor that hasn't been acknowledged yet by the device (uncompleted TX transactions). The function assumes that the processed TX queue is necessarily from the first category listed above and ends up using napi_consume_skb() for descriptors belonging to an XDP specific queue.
This patch solves a bug in which, in case of a VF reset, the descriptors aren't freed correctly, leading to crashes.(CVE-2024-35958)
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: Properly link new fs rules into the tree
Previously, add_rule_fg would only add newly created rules from the handle into the tree when they had a refcount of 1. On the other hand, create_flow_handle tries hard to find and reference already existing identical rules instead of creating new ones.
These two behaviors can result in a situation where create_flow_handle 1) creates a new rule and references it, then 2) in a subsequent step during the same handle creation references it again, resulting in a rule with a refcount of 2 that is not linked into the tree, will have a NULL parent and root and will result in a crash when the flow group is deleted because del_sw_hw_rule, invoked on rule deletion, assumes node->parent is != NULL.
This happened in the wild, due to another bug related to incorrect handling of duplicate pkt_reformat ids, which lead to the code in create_flow_handle incorrectly referencing a just-added rule in the same flow handle, resulting in the problem described above. Full details are at [1].
This patch changes add_rule_fg to add new rules without parents into the tree, properly initializing them and avoiding the crash. This makes it more consistent with how rules are added to an FTE in create_flow_handle.(CVE-2024-35960)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: Fix memory leak in hci_req_sync_complete()
In 'hci_req_sync_complete()', always free the previous sync request state before assigning reference to a new one.(CVE-2024-35978)
In the Linux kernel, the following vulnerability has been resolved:
i2c: smbus: fix NULL function pointer dereference
Baruch reported an OOPS when using the designware controller as target only. Target-only modes break the assumption of one transfer function always being available. Fix this by always checking the pointer in __i2c_transfer.
wsa: dropped the simplification in core-smbus to avoid theoretical regressions
In the Linux kernel, the following vulnerability has been resolved:
ACPI: CPPC: Use access_width over bit_width for system memory accesses
To align with ACPI 6.3+, since bit_width can be any 8-bit value, it cannot be depended on to be always on a clean 8b boundary. This was uncovered on the Cobalt 100 platform.
SError Interrupt on CPU26, code 0xbe000011 -- SError CPU: 26 PID: 1510 Comm: systemd-udevd Not tainted 5.15.2.1-13 #1 Hardware name: MICROSOFT CORPORATION, BIOS MICROSOFT CORPORATION pstate: 62400009 (nZCv daif +PAN -UAO +TCO -DIT -SSBS BTYPE=--) pc : cppc_get_perf_caps+0xec/0x410 lr : cppc_get_perf_caps+0xe8/0x410 sp : ffff8000155ab730 x29: ffff8000155ab730 x28: ffff0080139d0038 x27: ffff0080139d0078 x26: 0000000000000000 x25: ffff0080139d0058 x24: 00000000ffffffff x23: ffff0080139d0298 x22: ffff0080139d0278 x21: 0000000000000000 x20: ffff00802b251910 x19: ffff0080139d0000 x18: ffffffffffffffff x17: 0000000000000000 x16: ffffdc7e111bad04 x15: ffff00802b251008 x14: ffffffffffffffff x13: ffff013f1fd63300 x12: 0000000000000006 x11: ffffdc7e128f4420 x10: 0000000000000000 x9 : ffffdc7e111badec x8 : ffff00802b251980 x7 : 0000000000000000 x6 : ffff0080139d0028 x5 : 0000000000000000 x4 : ffff0080139d0018 x3 : 00000000ffffffff x2 : 0000000000000008 x1 : ffff8000155ab7a0 x0 : 0000000000000000 Kernel panic - not syncing: Asynchronous SError Interrupt CPU: 26 PID: 1510 Comm: systemd-udevd Not tainted 5.15.2.1-13 #1 Hardware name: MICROSOFT CORPORATION, BIOS MICROSOFT CORPORATION Call trace: dump_backtrace+0x0/0x1e0 show_stack+0x24/0x30 dump_stack_lvl+0x8c/0xb8 dump_stack+0x18/0x34 panic+0x16c/0x384 add_taint+0x0/0xc0 arm64_serror_panic+0x7c/0x90 arm64_is_fatal_ras_serror+0x34/0xa4 do_serror+0x50/0x6c el1h_64_error_handler+0x40/0x74 el1h_64_error+0x7c/0x80 cppc_get_perf_caps+0xec/0x410 cppc_cpufreq_cpu_init+0x74/0x400 [cppc_cpufreq] cpufreq_online+0x2dc/0xa30 cpufreq_add_dev+0xc0/0xd4 subsys_interface_register+0x134/0x14c cpufreq_register_driver+0x1b0/0x354 cppc_cpufreq_init+0x1a8/0x1000 [cppc_cpufreq] do_one_initcall+0x50/0x250 do_init_module+0x60/0x27c load_module+0x2300/0x2570 __do_sys_finit_module+0xa8/0x114 __arm64_sys_finit_module+0x2c/0x3c invoke_syscall+0x78/0x100 el0_svc_common.constprop.0+0x180/0x1a0 do_el0_svc+0x84/0xa0 el0_svc+0x2c/0xc0 el0t_64_sync_handler+0xa4/0x12c el0t_64_sync+0x1a4/0x1a8
Instead, use access_width to determine the size and use the offset and width to shift and mask the bits to read/write out. Make sure to add a check for system memory since pcc redefines the access_width to subspace id.
If access_width is not set, then fall back to using bit_width.
rjw: Subject and changelog edits, comment adjustments
In the Linux kernel, the following vulnerability has been resolved:
mm/hugetlb: fix missing hugetlb_lock for resv uncharge
There is a recent report on UFFDIO_COPY over hugetlb:
https://lore.kernel.org/all/000000000000ee06de0616177560@google.com/
350: lockdep_assert_held(&hugetlb_lock);
Should be an issue in hugetlb but triggered in an userfault context, where it goes into the unlikely path where two threads modifying the resv map together. Mike has a fix in that path for resv uncharge but it looks like the locking criteria was overlooked: hugetlb_cgroup_uncharge_folio_rsvd() will update the cgroup pointer, so it requires to be called with the lock held.(CVE-2024-36000)
In the Linux kernel, the following vulnerability has been resolved:
ppdev: Add an error check in register_device
In register_device, the return value of ida_simple_get is unchecked, in witch ida_simple_get will use an invalid index value.
To address this issue, index should be checked after ida_simple_get. When the index value is abnormal, a warning message should be printed, the port should be dropped, and the value should be recorded.(CVE-2024-36015)
In the Linux kernel, the following vulnerability has been resolved:
pinctrl: core: delete incorrect free in pinctrl_enable()
The "pctldev" struct is allocated in devm_pinctrl_register_and_init(). It's a devm_ managed pointer that is freed by devm_pinctrl_dev_release(), so freeing it in pinctrl_enable() will lead to a double free.
The devm_pinctrl_dev_release() function frees the pindescs and destroys the mutex as well.(CVE-2024-36940)
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"kernel-devel-5.10.0-136.78.0.158.oe2203sp1.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-136.78.0.158.oe2203sp1.aarch64.rpm",
"kernel-tools-debuginfo-5.10.0-136.78.0.158.oe2203sp1.aarch64.rpm",
"perf-5.10.0-136.78.0.158.oe2203sp1.aarch64.rpm",
"kernel-tools-devel-5.10.0-136.78.0.158.oe2203sp1.aarch64.rpm",
"python3-perf-5.10.0-136.78.0.158.oe2203sp1.aarch64.rpm",
"kernel-tools-5.10.0-136.78.0.158.oe2203sp1.aarch64.rpm",
"kernel-debuginfo-5.10.0-136.78.0.158.oe2203sp1.aarch64.rpm",
"kernel-5.10.0-136.78.0.158.oe2203sp1.aarch64.rpm",
"kernel-headers-5.10.0-136.78.0.158.oe2203sp1.aarch64.rpm",
"kernel-source-5.10.0-136.78.0.158.oe2203sp1.aarch64.rpm",
"kernel-debugsource-5.10.0-136.78.0.158.oe2203sp1.aarch64.rpm",
"perf-debuginfo-5.10.0-136.78.0.158.oe2203sp1.aarch64.rpm"
],
"src": [
"kernel-5.10.0-136.78.0.158.oe2203sp1.src.rpm"
],
"x86_64": [
"perf-5.10.0-136.78.0.158.oe2203sp1.x86_64.rpm",
"kernel-tools-devel-5.10.0-136.78.0.158.oe2203sp1.x86_64.rpm",
"kernel-tools-5.10.0-136.78.0.158.oe2203sp1.x86_64.rpm",
"kernel-headers-5.10.0-136.78.0.158.oe2203sp1.x86_64.rpm",
"kernel-source-5.10.0-136.78.0.158.oe2203sp1.x86_64.rpm",
"perf-debuginfo-5.10.0-136.78.0.158.oe2203sp1.x86_64.rpm",
"kernel-5.10.0-136.78.0.158.oe2203sp1.x86_64.rpm",
"kernel-tools-debuginfo-5.10.0-136.78.0.158.oe2203sp1.x86_64.rpm",
"kernel-debugsource-5.10.0-136.78.0.158.oe2203sp1.x86_64.rpm",
"kernel-devel-5.10.0-136.78.0.158.oe2203sp1.x86_64.rpm",
"python3-perf-debuginfo-5.10.0-136.78.0.158.oe2203sp1.x86_64.rpm",
"kernel-debuginfo-5.10.0-136.78.0.158.oe2203sp1.x86_64.rpm",
"python3-perf-5.10.0-136.78.0.158.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.78.0.158.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:\r\n\r\nmptcp: ensure tx skbs always have the MPTCP ext\r\n\r\nDue to signed/unsigned comparison, the expression:\r\n\r\n\tinfo-\u0026gt;size_goal - skb-\u0026gt;len \u0026gt; 0\r\n\r\nevaluates to true when the size goal is smaller than the\nskb size. That results in lack of tx cache refill, so that\nthe skb allocated by the core TCP code lacks the required\nMPTCP skb extensions.\r\n\r\nDue to the above, syzbot is able to trigger the following WARN_ON():\r\n\r\nWARNING: CPU: 1 PID: 810 at net/mptcp/protocol.c:1366 mptcp_sendmsg_frag+0x1362/0x1bc0 net/mptcp/protocol.c:1366\nModules linked in:\nCPU: 1 PID: 810 Comm: syz-executor.4 Not tainted 5.14.0-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011\nRIP: 0010:mptcp_sendmsg_frag+0x1362/0x1bc0 net/mptcp/protocol.c:1366\nCode: ff 4c 8b 74 24 50 48 8b 5c 24 58 e9 0f fb ff ff e8 13 44 8b f8 4c 89 e7 45 31 ed e8 98 57 2e fe e9 81 f4 ff ff e8 fe 43 8b f8 \u0026lt;0f\u0026gt; 0b 41 bd ea ff ff ff e9 6f f4 ff ff 4c 89 e7 e8 b9 8e d2 f8 e9\nRSP: 0018:ffffc9000531f6a0 EFLAGS: 00010216\nRAX: 000000000000697f RBX: 0000000000000000 RCX: ffffc90012107000\nRDX: 0000000000040000 RSI: ffffffff88eac9e2 RDI: 0000000000000003\nRBP: ffff888078b15780 R08: 0000000000000000 R09: 0000000000000000\nR10: ffffffff88eac017 R11: 0000000000000000 R12: ffff88801de0a280\nR13: 0000000000006b58 R14: ffff888066278280 R15: ffff88803c2fe9c0\nFS: 00007fd9f866e700(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007faebcb2f718 CR3: 00000000267cb000 CR4: 00000000001506e0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n __mptcp_push_pending+0x1fb/0x6b0 net/mptcp/protocol.c:1547\n mptcp_release_cb+0xfe/0x210 net/mptcp/protocol.c:3003\n release_sock+0xb4/0x1b0 net/core/sock.c:3206\n sk_stream_wait_memory+0x604/0xed0 net/core/stream.c:145\n mptcp_sendmsg+0xc39/0x1bc0 net/mptcp/protocol.c:1749\n inet6_sendmsg+0x99/0xe0 net/ipv6/af_inet6.c:643\n sock_sendmsg_nosec net/socket.c:704 [inline]\n sock_sendmsg+0xcf/0x120 net/socket.c:724\n sock_write_iter+0x2a0/0x3e0 net/socket.c:1057\n call_write_iter include/linux/fs.h:2163 [inline]\n new_sync_write+0x40b/0x640 fs/read_write.c:507\n vfs_write+0x7cf/0xae0 fs/read_write.c:594\n ksys_write+0x1ee/0x250 fs/read_write.c:647\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x44/0xae\nRIP: 0033:0x4665f9\nCode: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007fd9f866e188 EFLAGS: 00000246 ORIG_RAX: 0000000000000001\nRAX: ffffffffffffffda RBX: 000000000056c038 RCX: 00000000004665f9\nRDX: 00000000000e7b78 RSI: 0000000020000000 RDI: 0000000000000003\nRBP: 00000000004bfcc4 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000246 R12: 000000000056c038\nR13: 0000000000a9fb1f R14: 00007fd9f866e300 R15: 0000000000022000\r\n\r\nFix the issue rewriting the relevant expression to avoid\nsign-related problems - note: size_goal is always \u0026gt;= 0.\r\n\r\nAdditionally, ensure that the skb in the tx cache always carries\nthe relevant extension.(CVE-2021-47370)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: Fix even more out of bound writes from debugfs\r\n\r\nCVE-2021-42327 was fixed by:\r\n\r\ncommit f23750b5b3d98653b31d4469592935ef6364ad67\nAuthor: Thelford Williams \u0026lt;tdwilliamsiv@gmail.com\u0026gt;\nDate: Wed Oct 13 16:04:13 2021 -0400\r\n\r\n drm/amdgpu: fix out of bounds write\r\n\r\nbut amdgpu_dm_debugfs.c contains more of the same issue so fix the\nremaining ones.\r\n\r\nv2:\n\t* Add missing fix in dp_max_bpc_write (Harry Wentland)(CVE-2021-47489)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntcp: TX zerocopy should not sense pfmemalloc status\r\n\r\nWe got a recent syzbot report [1] showing a possible misuse\nof pfmemalloc page status in TCP zerocopy paths.\r\n\r\nIndeed, for pages coming from user space or other layers,\nusing page_is_pfmemalloc() is moot, and possibly could give\nfalse positives.\r\n\r\nThere has been attempts to make page_is_pfmemalloc() more robust,\nbut not using it in the first place in this context is probably better,\nremoving cpu cycles.\r\n\r\nNote to stable teams :\r\n\r\nYou need to backport 84ce071e38a6 (\u0026quot;net: introduce\n__skb_fill_page_desc_noacc\u0026quot;) as a prereq.\r\n\r\nRace is more probable after commit c07aea3ef4d4\n(\u0026quot;mm: add a signature in struct page\u0026quot;) because page_is_pfmemalloc()\nis now using low order bit from page-\u0026gt;lru.next, which can change\nmore often than page-\u0026gt;index.\r\n\r\nLow order bit should never be set for lru.next (when used as an anchor\nin LRU list), so KCSAN report is mostly a false positive.\r\n\r\nBackporting to older kernel versions seems not necessary.\r\n\r\n[1]\nBUG: KCSAN: data-race in lru_add_fn / tcp_build_frag\r\n\r\nwrite to 0xffffea0004a1d2c8 of 8 bytes by task 18600 on cpu 0:\n__list_add include/linux/list.h:73 [inline]\nlist_add include/linux/list.h:88 [inline]\nlruvec_add_folio include/linux/mm_inline.h:105 [inline]\nlru_add_fn+0x440/0x520 mm/swap.c:228\nfolio_batch_move_lru+0x1e1/0x2a0 mm/swap.c:246\nfolio_batch_add_and_move mm/swap.c:263 [inline]\nfolio_add_lru+0xf1/0x140 mm/swap.c:490\nfilemap_add_folio+0xf8/0x150 mm/filemap.c:948\n__filemap_get_folio+0x510/0x6d0 mm/filemap.c:1981\npagecache_get_page+0x26/0x190 mm/folio-compat.c:104\ngrab_cache_page_write_begin+0x2a/0x30 mm/folio-compat.c:116\next4_da_write_begin+0x2dd/0x5f0 fs/ext4/inode.c:2988\ngeneric_perform_write+0x1d4/0x3f0 mm/filemap.c:3738\next4_buffered_write_iter+0x235/0x3e0 fs/ext4/file.c:270\next4_file_write_iter+0x2e3/0x1210\ncall_write_iter include/linux/fs.h:2187 [inline]\nnew_sync_write fs/read_write.c:491 [inline]\nvfs_write+0x468/0x760 fs/read_write.c:578\nksys_write+0xe8/0x1a0 fs/read_write.c:631\n__do_sys_write fs/read_write.c:643 [inline]\n__se_sys_write fs/read_write.c:640 [inline]\n__x64_sys_write+0x3e/0x50 fs/read_write.c:640\ndo_syscall_x64 arch/x86/entry/common.c:50 [inline]\ndo_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80\nentry_SYSCALL_64_after_hwframe+0x63/0xcd\r\n\r\nread to 0xffffea0004a1d2c8 of 8 bytes by task 18611 on cpu 1:\npage_is_pfmemalloc include/linux/mm.h:1740 [inline]\n__skb_fill_page_desc include/linux/skbuff.h:2422 [inline]\nskb_fill_page_desc include/linux/skbuff.h:2443 [inline]\ntcp_build_frag+0x613/0xb20 net/ipv4/tcp.c:1018\ndo_tcp_sendpages+0x3e8/0xaf0 net/ipv4/tcp.c:1075\ntcp_sendpage_locked net/ipv4/tcp.c:1140 [inline]\ntcp_sendpage+0x89/0xb0 net/ipv4/tcp.c:1150\ninet_sendpage+0x7f/0xc0 net/ipv4/af_inet.c:833\nkernel_sendpage+0x184/0x300 net/socket.c:3561\nsock_sendpage+0x5a/0x70 net/socket.c:1054\npipe_to_sendpage+0x128/0x160 fs/splice.c:361\nsplice_from_pipe_feed fs/splice.c:415 [inline]\n__splice_from_pipe+0x222/0x4d0 fs/splice.c:559\nsplice_from_pipe fs/splice.c:594 [inline]\ngeneric_splice_sendpage+0x89/0xc0 fs/splice.c:743\ndo_splice_from fs/splice.c:764 [inline]\ndirect_splice_actor+0x80/0xa0 fs/splice.c:931\nsplice_direct_to_actor+0x305/0x620 fs/splice.c:886\ndo_splice_direct+0xfb/0x180 fs/splice.c:974\ndo_sendfile+0x3bf/0x910 fs/read_write.c:1249\n__do_sys_sendfile64 fs/read_write.c:1317 [inline]\n__se_sys_sendfile64 fs/read_write.c:1303 [inline]\n__x64_sys_sendfile64+0x10c/0x150 fs/read_write.c:1303\ndo_syscall_x64 arch/x86/entry/common.c:50 [inline]\ndo_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80\nentry_SYSCALL_64_after_hwframe+0x63/0xcd\r\n\r\nvalue changed: 0x0000000000000000 -\u0026gt; 0xffffea0004a1d288\r\n\r\nReported by Kernel Concurrency Sanitizer on:\nCPU: 1 PID: 18611 Comm: syz-executor.4 Not tainted 6.0.0-rc2-syzkaller-00248-ge022620b5d05-dirty #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/22/2022(CVE-2022-48689)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nio_uring/af_unix: disable sending io_uring over sockets\r\n\r\nFile reference cycles have caused lots of problems for io_uring\nin the past, and it still doesn\u0026apos;t work exactly right and races with\nunix_stream_read_generic(). The safest fix would be to completely\ndisallow sending io_uring files via sockets via SCM_RIGHT, so there\nare no possible cycles invloving registered files and thus rendering\nSCM accounting on the io_uring side unnecessary.(CVE-2023-52654)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: aqc111: check packet for fixup for true limit\r\n\r\nIf a device sends a packet that is inbetween 0\nand sizeof(u64) the value passed to skb_trim()\nas length will wrap around ending up as some very\nlarge value.\r\n\r\nThe driver will then proceed to parse the header\nlocated at that position, which will either oops or\nprocess some random value.\r\n\r\nThe fix is to check against sizeof(u64) rather than\n0, which the driver currently does. The issue exists\nsince the introduction of the driver.(CVE-2023-52655)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncrypto: s390/aes - Fix buffer overread in CTR mode\r\n\r\nWhen processing the last block, the s390 ctr code will always read\na whole block, even if there isn\u0026apos;t a whole block of data left. Fix\nthis by using the actual length left and copy it into a buffer first\nfor processing.(CVE-2023-52669)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsysv: don\u0026apos;t call sb_bread() with pointers_lock held\r\n\r\nsyzbot is reporting sleep in atomic context in SysV filesystem [1], for\nsb_bread() is called with rw_spinlock held.\r\n\r\nA \u0026quot;write_lock(\u0026amp;pointers_lock) =\u0026gt; read_lock(\u0026amp;pointers_lock) deadlock\u0026quot; bug\nand a \u0026quot;sb_bread() with write_lock(\u0026amp;pointers_lock)\u0026quot; bug were introduced by\n\u0026quot;Replace BKL for chain locking with sysvfs-private rwlock\u0026quot; in Linux 2.5.12.\r\n\r\nThen, \u0026quot;[PATCH] err1-40: sysvfs locking fix\u0026quot; in Linux 2.6.8 fixed the\nformer bug by moving pointers_lock lock to the callers, but instead\nintroduced a \u0026quot;sb_bread() with read_lock(\u0026amp;pointers_lock)\u0026quot; bug (which made\nthis problem easier to hit).\r\n\r\nAl Viro suggested that why not to do like get_branch()/get_block()/\nfind_shared() in Minix filesystem does. And doing like that is almost a\nrevert of \u0026quot;[PATCH] err1-40: sysvfs locking fix\u0026quot; except that get_branch()\n from with find_shared() is called without write_lock(\u0026amp;pointers_lock).(CVE-2023-52699)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/usb: kalmia: Don\u0026apos;t pass act_len in usb_bulk_msg error path\r\n\r\nsyzbot reported that act_len in kalmia_send_init_packet() is\nuninitialized when passing it to the first usb_bulk_msg error path. Jiri\nPirko noted that it\u0026apos;s pointless to pass it in the error path, and that\nthe value that would be printed in the second error path would be the\nvalue of act_len from the first call to usb_bulk_msg.[1]\r\n\r\nWith this in mind, let\u0026apos;s just not pass act_len to the usb_bulk_msg error\npaths.\r\n\r\n1: https://lore.kernel.org/lkml/Y9pY61y1nwTuzMOa@nanopsycho/(CVE-2023-52703)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmmc: sdio: fix possible resource leaks in some error paths\r\n\r\nIf sdio_add_func() or sdio_init_func() fails, sdio_remove_func() can\nnot release the resources, because the sdio function is not presented\nin these two cases, it won\u0026apos;t call of_node_put() or put_device().\r\n\r\nTo fix these leaks, make sdio_func_present() only control whether\ndevice_del() needs to be called or not, then always call of_node_put()\nand put_device().\r\n\r\nIn error case in sdio_init_func(), the reference of \u0026apos;card-\u0026gt;dev\u0026apos; is\nnot get, to avoid redundant put in sdio_free_func_cis(), move the\nget_device() to sdio_alloc_func() and put_device() to sdio_release_func(),\nit can keep the get/put function be balanced.\r\n\r\nWithout this patch, while doing fault inject test, it can get the\nfollowing leak reports, after this fix, the leak is gone.\r\n\r\nunreferenced object 0xffff888112514000 (size 2048):\n comm \u0026quot;kworker/3:2\u0026quot;, pid 65, jiffies 4294741614 (age 124.774s)\n hex dump (first 32 bytes):\n 00 e0 6f 12 81 88 ff ff 60 58 8d 06 81 88 ff ff ..o.....`X......\n 10 40 51 12 81 88 ff ff 10 40 51 12 81 88 ff ff .@Q......@Q.....\n backtrace:\n [\u0026lt;000000009e5931da\u0026gt;] kmalloc_trace+0x21/0x110\n [\u0026lt;000000002f839ccb\u0026gt;] mmc_alloc_card+0x38/0xb0 [mmc_core]\n [\u0026lt;0000000004adcbf6\u0026gt;] mmc_sdio_init_card+0xde/0x170 [mmc_core]\n [\u0026lt;000000007538fea0\u0026gt;] mmc_attach_sdio+0xcb/0x1b0 [mmc_core]\n [\u0026lt;00000000d4fdeba7\u0026gt;] mmc_rescan+0x54a/0x640 [mmc_core]\r\n\r\nunreferenced object 0xffff888112511000 (size 2048):\n comm \u0026quot;kworker/3:2\u0026quot;, pid 65, jiffies 4294741623 (age 124.766s)\n hex dump (first 32 bytes):\n 00 40 51 12 81 88 ff ff e0 58 8d 06 81 88 ff ff .@Q......X......\n 10 10 51 12 81 88 ff ff 10 10 51 12 81 88 ff ff ..Q.......Q.....\n backtrace:\n [\u0026lt;000000009e5931da\u0026gt;] kmalloc_trace+0x21/0x110\n [\u0026lt;00000000fcbe706c\u0026gt;] sdio_alloc_func+0x35/0x100 [mmc_core]\n [\u0026lt;00000000c68f4b50\u0026gt;] mmc_attach_sdio.cold.18+0xb1/0x395 [mmc_core]\n [\u0026lt;00000000d4fdeba7\u0026gt;] mmc_rescan+0x54a/0x640 [mmc_core](CVE-2023-52730)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbpf, sockmap: Don\u0026apos;t let sock_map_{close,destroy,unhash} call itself\r\n\r\nsock_map proto callbacks should never call themselves by design. Protect\nagainst bugs like [1] and break out of the recursive loop to avoid a stack\noverflow in favor of a resource leak.\r\n\r\n[1] https://lore.kernel.org/all/00000000000073b14905ef2e7401@google.com/(CVE-2023-52735)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nALSA: hda: Do not unset preset when cleaning up codec\r\n\r\nSeveral functions that take part in codec\u0026apos;s initialization and removal\nare re-used by ASoC codec drivers implementations. Drivers mimic the\nbehavior of hda_codec_driver_probe/remove() found in\nsound/pci/hda/hda_bind.c with their component-\u0026gt;probe/remove() instead.\r\n\r\nOne of the reasons for that is the expectation of\nsnd_hda_codec_device_new() to receive a valid pointer to an instance of\nstruct snd_card. This expectation can be met only once sound card\ncomponents probing commences.\r\n\r\nAs ASoC sound card may be unbound without codec device being actually\nremoved from the system, unsetting -\u0026gt;preset in\nsnd_hda_codec_cleanup_for_unbind() interferes with module unload -\u0026gt; load\nscenario causing null-ptr-deref. Preset is assigned only once, during\ndevice/driver matching whereas ASoC codec driver\u0026apos;s module reloading may\noccur several times throughout the lifetime of an audio stack.(CVE-2023-52736)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\narm64: Restrict CPU_BIG_ENDIAN to GNU as or LLVM IAS 15.x or newer\r\n\r\nPrior to LLVM 15.0.0, LLVM\u0026apos;s integrated assembler would incorrectly\nbyte-swap NOP when compiling for big-endian, and the resulting series of\nbytes happened to match the encoding of FNMADD S21, S30, S0, S0.\r\n\r\nThis went unnoticed until commit:\r\n\r\n 34f66c4c4d5518c1 (\u0026quot;arm64: Use a positive cpucap for FP/SIMD\u0026quot;)\r\n\r\nPrior to that commit, the kernel would always enable the use of FPSIMD\nearly in boot when __cpu_setup() initialized CPACR_EL1, and so usage of\nFNMADD within the kernel was not detected, but could result in the\ncorruption of user or kernel FPSIMD state.\r\n\r\nAfter that commit, the instructions happen to trap during boot prior to\nFPSIMD being detected and enabled, e.g.\r\n\r\n| Unhandled 64-bit el1h sync exception on CPU0, ESR 0x000000001fe00000 -- ASIMD\n| CPU: 0 PID: 0 Comm: swapper Not tainted 6.6.0-rc3-00013-g34f66c4c4d55 #1\n| Hardware name: linux,dummy-virt (DT)\n| pstate: 400000c9 (nZcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n| pc : __pi_strcmp+0x1c/0x150\n| lr : populate_properties+0xe4/0x254\n| sp : ffffd014173d3ad0\n| x29: ffffd014173d3af0 x28: fffffbfffddffcb8 x27: 0000000000000000\n| x26: 0000000000000058 x25: fffffbfffddfe054 x24: 0000000000000008\n| x23: fffffbfffddfe000 x22: fffffbfffddfe000 x21: fffffbfffddfe044\n| x20: ffffd014173d3b70 x19: 0000000000000001 x18: 0000000000000005\n| x17: 0000000000000010 x16: 0000000000000000 x15: 00000000413e7000\n| x14: 0000000000000000 x13: 0000000000001bcc x12: 0000000000000000\n| x11: 00000000d00dfeed x10: ffffd414193f2cd0 x9 : 0000000000000000\n| x8 : 0101010101010101 x7 : ffffffffffffffc0 x6 : 0000000000000000\n| x5 : 0000000000000000 x4 : 0101010101010101 x3 : 000000000000002a\n| x2 : 0000000000000001 x1 : ffffd014171f2988 x0 : fffffbfffddffcb8\n| Kernel panic - not syncing: Unhandled exception\n| CPU: 0 PID: 0 Comm: swapper Not tainted 6.6.0-rc3-00013-g34f66c4c4d55 #1\n| Hardware name: linux,dummy-virt (DT)\n| Call trace:\n| dump_backtrace+0xec/0x108\n| show_stack+0x18/0x2c\n| dump_stack_lvl+0x50/0x68\n| dump_stack+0x18/0x24\n| panic+0x13c/0x340\n| el1t_64_irq_handler+0x0/0x1c\n| el1_abort+0x0/0x5c\n| el1h_64_sync+0x64/0x68\n| __pi_strcmp+0x1c/0x150\n| unflatten_dt_nodes+0x1e8/0x2d8\n| __unflatten_device_tree+0x5c/0x15c\n| unflatten_device_tree+0x38/0x50\n| setup_arch+0x164/0x1e0\n| start_kernel+0x64/0x38c\n| __primary_switched+0xbc/0xc4\r\n\r\nRestrict CONFIG_CPU_BIG_ENDIAN to a known good assembler, which is\neither GNU as or LLVM\u0026apos;s IAS 15.0.0 and newer, which contains the linked\ncommit.(CVE-2023-52750)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsmb: client: fix use-after-free bug in cifs_debug_data_proc_show()\r\n\r\nSkip SMB sessions that are being teared down\n(e.g. @ses-\u0026gt;ses_status == SES_EXITING) in cifs_debug_data_proc_show()\nto avoid use-after-free in @ses.\r\n\r\nThis fixes the following GPF when reading from /proc/fs/cifs/DebugData\nwhile mounting and umounting\r\n\r\n [ 816.251274] general protection fault, probably for non-canonical\n address 0x6b6b6b6b6b6b6d81: 0000 [#1] PREEMPT SMP NOPTI\n ...\n [ 816.260138] Call Trace:\n [ 816.260329] \u0026lt;TASK\u0026gt;\n [ 816.260499] ? die_addr+0x36/0x90\n [ 816.260762] ? exc_general_protection+0x1b3/0x410\n [ 816.261126] ? asm_exc_general_protection+0x26/0x30\n [ 816.261502] ? cifs_debug_tcon+0xbd/0x240 [cifs]\n [ 816.261878] ? cifs_debug_tcon+0xab/0x240 [cifs]\n [ 816.262249] cifs_debug_data_proc_show+0x516/0xdb0 [cifs]\n [ 816.262689] ? seq_read_iter+0x379/0x470\n [ 816.262995] seq_read_iter+0x118/0x470\n [ 816.263291] proc_reg_read_iter+0x53/0x90\n [ 816.263596] ? srso_alias_return_thunk+0x5/0x7f\n [ 816.263945] vfs_read+0x201/0x350\n [ 816.264211] ksys_read+0x75/0x100\n [ 816.264472] do_syscall_64+0x3f/0x90\n [ 816.264750] entry_SYSCALL_64_after_hwframe+0x6e/0xd8\n [ 816.265135] RIP: 0033:0x7fd5e669d381(CVE-2023-52752)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ngfs2: ignore negated quota changes\r\n\r\nWhen lots of quota changes are made, there may be cases in which an\ninode\u0026apos;s quota information is increased and then decreased, such as when\nblocks are added to a file, then deleted from it. If the timing is\nright, function do_qc can add pending quota changes to a transaction,\nthen later, another call to do_qc can negate those changes, resulting\nin a net gain of 0. The quota_change information is recorded in the qc\nbuffer (and qd element of the inode as well). The buffer is added to the\ntransaction by the first call to do_qc, but a subsequent call changes\nthe value from non-zero back to zero. At that point it\u0026apos;s too late to\nremove the buffer_head from the transaction. Later, when the quota sync\ncode is called, the zero-change qd element is discovered and flagged as\nan assert warning. If the fs is mounted with errors=panic, the kernel\nwill panic.\r\n\r\nThis is usually seen when files are truncated and the quota changes are\nnegated by punch_hole/truncate which uses gfs2_quota_hold and\ngfs2_quota_unhold rather than block allocations that use gfs2_quota_lock\nand gfs2_quota_unlock which automatically do quota sync.\r\n\r\nThis patch solves the problem by adding a check to qd_check_sync such\nthat net-zero quota changes already added to the transaction are no\nlonger deemed necessary to be synced, and skipped.\r\n\r\nIn this case references are taken for the qd and the slot from do_qc\nso those need to be put. The normal sequence of events for a normal\nnon-zero quota change is as follows:\r\n\r\ngfs2_quota_change\n do_qc\n qd_hold\n slot_hold\r\n\r\nLater, when the changes are to be synced:\r\n\r\ngfs2_quota_sync\n qd_fish\n qd_check_sync\n gets qd ref via lockref_get_not_dead\n do_sync\n do_qc(QC_SYNC)\n qd_put\n\t lockref_put_or_lock\n qd_unlock\n qd_put\n lockref_put_or_lock\r\n\r\nIn the net-zero change case, we add a check to qd_check_sync so it puts\nthe qd and slot references acquired in gfs2_quota_change and skip the\nunneeded sync.(CVE-2023-52759)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ns390/dasd: protect device queue against concurrent access\r\n\r\nIn dasd_profile_start() the amount of requests on the device queue are\ncounted. The access to the device queue is unprotected against\nconcurrent access. With a lot of parallel I/O, especially with alias\ndevices enabled, the device queue can change while dasd_profile_start()\nis accessing the queue. In the worst case this leads to a kernel panic\ndue to incorrect pointer accesses.\r\n\r\nFix this by taking the device lock before accessing the queue and\ncounting the requests. Additionally the check for a valid profile data\npointer can be done earlier to avoid unnecessary locking in a hot path.(CVE-2023-52774)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntty: vcc: Add check for kstrdup() in vcc_probe()\r\n\r\nAdd check for the return value of kstrdup() and return the error, if it\nfails in order to avoid NULL pointer dereference.(CVE-2023-52789)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nvhost-vdpa: fix use after free in vhost_vdpa_probe()\r\n\r\nThe put_device() calls vhost_vdpa_release_dev() which calls\nida_simple_remove() and frees \u0026quot;v\u0026quot;. So this call to\nida_simple_remove() is a use after free and a double free.(CVE-2023-52795)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\niio: adc: stm32-adc: harden against NULL pointer deref in stm32_adc_probe()\r\n\r\nof_match_device() may fail and returns a NULL pointer.\r\n\r\nIn practice there is no known reasonable way to trigger this, but\nin case one is added in future, harden the code by adding the check(CVE-2023-52802)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfs/jfs: Add validity check for db_maxag and db_agpref\r\n\r\nBoth db_maxag and db_agpref are used as the index of the\ndb_agfree array, but there is currently no validity check for\ndb_maxag and db_agpref, which can lead to errors.\r\n\r\nThe following is related bug reported by Syzbot:\r\n\r\nUBSAN: array-index-out-of-bounds in fs/jfs/jfs_dmap.c:639:20\nindex 7936 is out of range for type \u0026apos;atomic_t[128]\u0026apos;\r\n\r\nAdd checking that the values of db_maxag and db_agpref are valid\nindexes for the db_agfree array.(CVE-2023-52804)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\njfs: fix array-index-out-of-bounds in diAlloc\r\n\r\nCurrently there is not check against the agno of the iag while\nallocating new inodes to avoid fragmentation problem. Added the check\nwhich is required.(CVE-2023-52805)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: hisi_sas: Set debugfs_dir pointer to NULL after removing debugfs\r\n\r\nIf init debugfs failed during device registration due to memory allocation\nfailure, debugfs_remove_recursive() is called, after which debugfs_dir is\nnot set to NULL. debugfs_remove_recursive() will be called again during\ndevice removal. As a result, illegal pointer is accessed.\r\n\r\n[ 1665.467244] hisi_sas_v3_hw 0000:b4:02.0: failed to init debugfs!\n...\n[ 1669.836708] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a0\n[ 1669.872669] pc : down_write+0x24/0x70\n[ 1669.876315] lr : down_write+0x1c/0x70\n[ 1669.879961] sp : ffff000036f53a30\n[ 1669.883260] x29: ffff000036f53a30 x28: ffffa027c31549f8\n[ 1669.888547] x27: ffffa027c3140000 x26: 0000000000000000\n[ 1669.893834] x25: ffffa027bf37c270 x24: ffffa027bf37c270\n[ 1669.899122] x23: ffff0000095406b8 x22: ffff0000095406a8\n[ 1669.904408] x21: 0000000000000000 x20: ffffa027bf37c310\n[ 1669.909695] x19: 00000000000000a0 x18: ffff8027dcd86f10\n[ 1669.914982] x17: 0000000000000000 x16: 0000000000000000\n[ 1669.920268] x15: 0000000000000000 x14: ffffa0274014f870\n[ 1669.925555] x13: 0000000000000040 x12: 0000000000000228\n[ 1669.930842] x11: 0000000000000020 x10: 0000000000000bb0\n[ 1669.936129] x9 : ffff000036f537f0 x8 : ffff80273088ca10\n[ 1669.941416] x7 : 000000000000001d x6 : 00000000ffffffff\n[ 1669.946702] x5 : ffff000008a36310 x4 : ffff80273088be00\n[ 1669.951989] x3 : ffff000009513e90 x2 : 0000000000000000\n[ 1669.957276] x1 : 00000000000000a0 x0 : ffffffff00000001\n[ 1669.962563] Call trace:\n[ 1669.965000] down_write+0x24/0x70\n[ 1669.968301] debugfs_remove_recursive+0x5c/0x1b0\n[ 1669.972905] hisi_sas_debugfs_exit+0x24/0x30 [hisi_sas_main]\n[ 1669.978541] hisi_sas_v3_remove+0x130/0x150 [hisi_sas_v3_hw]\n[ 1669.984175] pci_device_remove+0x48/0xd8\n[ 1669.988082] device_release_driver_internal+0x1b4/0x250\n[ 1669.993282] device_release_driver+0x28/0x38\n[ 1669.997534] pci_stop_bus_device+0x84/0xb8\n[ 1670.001611] pci_stop_and_remove_bus_device_locked+0x24/0x40\n[ 1670.007244] remove_store+0xfc/0x140\n[ 1670.010802] dev_attr_store+0x44/0x60\n[ 1670.014448] sysfs_kf_write+0x58/0x80\n[ 1670.018095] kernfs_fop_write+0xe8/0x1f0\n[ 1670.022000] __vfs_write+0x60/0x190\n[ 1670.025472] vfs_write+0xac/0x1c0\n[ 1670.028771] ksys_write+0x6c/0xd8\n[ 1670.032071] __arm64_sys_write+0x24/0x30\n[ 1670.035977] el0_svc_common+0x78/0x130\n[ 1670.039710] el0_svc_handler+0x38/0x78\n[ 1670.043442] el0_svc+0x8/0xc\r\n\r\nTo fix this, set debugfs_dir to NULL after debugfs_remove_recursive().(CVE-2023-52808)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: Fix potential null pointer derefernce\r\n\r\nThe amdgpu_ras_get_context may return NULL if device\nnot support ras feature, so add check before using.(CVE-2023-52814)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd: Fix UBSAN array-index-out-of-bounds for SMU7\r\n\r\nFor pptable structs that use flexible array sizes, use flexible arrays.(CVE-2023-52818)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd: Fix UBSAN array-index-out-of-bounds for Polaris and Tonga\r\n\r\nFor pptable structs that use flexible array sizes, use flexible arrays.(CVE-2023-52819)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/panel/panel-tpo-tpg110: fix a possible null pointer dereference\r\n\r\nIn tpg110_get_modes(), the return value of drm_mode_duplicate() is\nassigned to mode, which will lead to a NULL pointer dereference on\nfailure of drm_mode_duplicate(). Add a check to avoid npd.(CVE-2023-52826)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: mac80211: don\u0026apos;t return unset power in ieee80211_get_tx_power()\r\n\r\nWe can get a UBSAN warning if ieee80211_get_tx_power() returns the\nINT_MIN value mac80211 internally uses for \u0026quot;unset power level\u0026quot;.\r\n\r\n UBSAN: signed-integer-overflow in net/wireless/nl80211.c:3816:5\n -2147483648 * 100 cannot be represented in type \u0026apos;int\u0026apos;\n CPU: 0 PID: 20433 Comm: insmod Tainted: G WC OE\n Call Trace:\n dump_stack+0x74/0x92\n ubsan_epilogue+0x9/0x50\n handle_overflow+0x8d/0xd0\n __ubsan_handle_mul_overflow+0xe/0x10\n nl80211_send_iface+0x688/0x6b0 [cfg80211]\n [...]\n cfg80211_register_wdev+0x78/0xb0 [cfg80211]\n cfg80211_netdev_notifier_call+0x200/0x620 [cfg80211]\n [...]\n ieee80211_if_add+0x60e/0x8f0 [mac80211]\n ieee80211_register_hw+0xda5/0x1170 [mac80211]\r\n\r\nIn this case, simply return an error instead, to indicate\nthat no data is available.(CVE-2023-52832)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nlocking/ww_mutex/test: Fix potential workqueue corruption\r\n\r\nIn some cases running with the test-ww_mutex code, I was seeing\nodd behavior where sometimes it seemed flush_workqueue was\nreturning before all the work threads were finished.\r\n\r\nOften this would cause strange crashes as the mutexes would be\nfreed while they were being used.\r\n\r\nLooking at the code, there is a lifetime problem as the\ncontrolling thread that spawns the work allocates the\n\u0026quot;struct stress\u0026quot; structures that are passed to the workqueue\nthreads. Then when the workqueue threads are finished,\nthey free the stress struct that was passed to them.\r\n\r\nUnfortunately the workqueue work_struct node is in the stress\nstruct. Which means the work_struct is freed before the work\nthread returns and while flush_workqueue is waiting.\r\n\r\nIt seems like a better idea to have the controlling thread\nboth allocate and free the stress structures, so that we can\nbe sure we don\u0026apos;t corrupt the workqueue by freeing the structure\nprematurely.\r\n\r\nSo this patch reworks the test to do so, and with this change\nI no longer see the early flush_workqueue returns.(CVE-2023-52836)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntipc: Change nla_policy for bearer-related names to NLA_NUL_STRING\r\n\r\nsyzbot reported the following uninit-value access issue [1]:\r\n\r\n=====================================================\nBUG: KMSAN: uninit-value in strlen lib/string.c:418 [inline]\nBUG: KMSAN: uninit-value in strstr+0xb8/0x2f0 lib/string.c:756\n strlen lib/string.c:418 [inline]\n strstr+0xb8/0x2f0 lib/string.c:756\n tipc_nl_node_reset_link_stats+0x3ea/0xb50 net/tipc/node.c:2595\n genl_family_rcv_msg_doit net/netlink/genetlink.c:971 [inline]\n genl_family_rcv_msg net/netlink/genetlink.c:1051 [inline]\n genl_rcv_msg+0x11ec/0x1290 net/netlink/genetlink.c:1066\n netlink_rcv_skb+0x371/0x650 net/netlink/af_netlink.c:2545\n genl_rcv+0x40/0x60 net/netlink/genetlink.c:1075\n netlink_unicast_kernel net/netlink/af_netlink.c:1342 [inline]\n netlink_unicast+0xf47/0x1250 net/netlink/af_netlink.c:1368\n netlink_sendmsg+0x1238/0x13d0 net/netlink/af_netlink.c:1910\n sock_sendmsg_nosec net/socket.c:730 [inline]\n sock_sendmsg net/socket.c:753 [inline]\n ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2541\n ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2595\n __sys_sendmsg net/socket.c:2624 [inline]\n __do_sys_sendmsg net/socket.c:2633 [inline]\n __se_sys_sendmsg net/socket.c:2631 [inline]\n __x64_sys_sendmsg+0x307/0x490 net/socket.c:2631\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\r\n\r\nUninit was created at:\n slab_post_alloc_hook+0x12f/0xb70 mm/slab.h:767\n slab_alloc_node mm/slub.c:3478 [inline]\n kmem_cache_alloc_node+0x577/0xa80 mm/slub.c:3523\n kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:559\n __alloc_skb+0x318/0x740 net/core/skbuff.c:650\n alloc_skb include/linux/skbuff.h:1286 [inline]\n netlink_alloc_large_skb net/netlink/af_netlink.c:1214 [inline]\n netlink_sendmsg+0xb34/0x13d0 net/netlink/af_netlink.c:1885\n sock_sendmsg_nosec net/socket.c:730 [inline]\n sock_sendmsg net/socket.c:753 [inline]\n ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2541\n ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2595\n __sys_sendmsg net/socket.c:2624 [inline]\n __do_sys_sendmsg net/socket.c:2633 [inline]\n __se_sys_sendmsg net/socket.c:2631 [inline]\n __x64_sys_sendmsg+0x307/0x490 net/socket.c:2631\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\r\n\r\nTIPC bearer-related names including link names must be null-terminated\nstrings. If a link name which is not null-terminated is passed through\nnetlink, strstr() and similar functions can cause buffer overrun. This\ncauses the above issue.\r\n\r\nThis patch changes the nla_policy for bearer-related names from NLA_STRING\nto NLA_NUL_STRING. This resolves the issue by ensuring that only\nnull-terminated strings are accepted as bearer-related names.\r\n\r\nsyzbot reported similar uninit-value issue related to bearer names [2]. The\nroot cause of this issue is that a non-null-terminated bearer name was\npassed. This patch also resolved this issue.(CVE-2023-52845)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nclk: mediatek: clk-mt7629: Add check for mtk_alloc_clk_data\r\n\r\nAdd the check for the return value of mtk_alloc_clk_data() in order to\navoid NULL pointer dereference.(CVE-2023-52858)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nperf: hisi: Fix use-after-free when register pmu fails\r\n\r\nWhen we fail to register the uncore pmu, the pmu context may not been\nallocated. The error handing will call cpuhp_state_remove_instance()\nto call uncore pmu offline callback, which migrate the pmu context.\nSince that\u0026apos;s liable to lead to some kind of use-after-free.\r\n\r\nUse cpuhp_state_remove_instance_nocalls() instead of\ncpuhp_state_remove_instance() so that the notifiers don\u0026apos;t execute after\nthe PMU device has been failed to register.(CVE-2023-52859)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nplatform/x86: wmi: Fix opening of char device\r\n\r\nSince commit fa1f68db6ca7 (\u0026quot;drivers: misc: pass miscdevice pointer via\nfile private data\u0026quot;), the miscdevice stores a pointer to itself inside\nfilp-\u0026gt;private_data, which means that private_data will not be NULL when\nwmi_char_open() is called. This might cause memory corruption should\nwmi_char_open() be unable to find its driver, something which can\nhappen when the associated WMI device is deleted in wmi_free_devices().\r\n\r\nFix the problem by using the miscdevice pointer to retrieve the WMI\ndevice data associated with a char device using container_of(). This\nalso avoids wmi_char_open() picking a wrong WMI device bound to a\ndriver with the same name as the original driver.(CVE-2023-52864)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsoc: qcom: llcc: Handle a second device without data corruption\r\n\r\nUsually there is only one llcc device. But if there were a second, even\na failed probe call would modify the global drv_data pointer. So check\nif drv_data is valid before overwriting it.(CVE-2023-52871)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncan: dev: can_put_echo_skb(): don\u0026apos;t crash kernel if can_priv::echo_skb is accessed out of bounds\r\n\r\nIf the \u0026quot;struct can_priv::echoo_skb\u0026quot; is accessed out of bounds, this\nwould cause a kernel crash. Instead, issue a meaningful warning\nmessage and return with an error.(CVE-2023-52878)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Fix memory leak in dm_sw_fini()\r\n\r\nAfter destroying dmub_srv, the memory associated with it is\nnot freed, causing a memory leak:\r\n\r\nunreferenced object 0xffff896302b45800 (size 1024):\n comm \u0026quot;(udev-worker)\u0026quot;, pid 222, jiffies 4294894636\n hex dump (first 32 bytes):\n 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n backtrace (crc 6265fd77):\n [\u0026lt;ffffffff993495ed\u0026gt;] kmalloc_trace+0x29d/0x340\n [\u0026lt;ffffffffc0ea4a94\u0026gt;] dm_dmub_sw_init+0xb4/0x450 [amdgpu]\n [\u0026lt;ffffffffc0ea4e55\u0026gt;] dm_sw_init+0x15/0x2b0 [amdgpu]\n [\u0026lt;ffffffffc0ba8557\u0026gt;] amdgpu_device_init+0x1417/0x24e0 [amdgpu]\n [\u0026lt;ffffffffc0bab285\u0026gt;] amdgpu_driver_load_kms+0x15/0x190 [amdgpu]\n [\u0026lt;ffffffffc0ba09c7\u0026gt;] amdgpu_pci_probe+0x187/0x4e0 [amdgpu]\n [\u0026lt;ffffffff9968fd1e\u0026gt;] local_pci_probe+0x3e/0x90\n [\u0026lt;ffffffff996918a3\u0026gt;] pci_device_probe+0xc3/0x230\n [\u0026lt;ffffffff99805872\u0026gt;] really_probe+0xe2/0x480\n [\u0026lt;ffffffff99805c98\u0026gt;] __driver_probe_device+0x78/0x160\n [\u0026lt;ffffffff99805daf\u0026gt;] driver_probe_device+0x1f/0x90\n [\u0026lt;ffffffff9980601e\u0026gt;] __driver_attach+0xce/0x1c0\n [\u0026lt;ffffffff99803170\u0026gt;] bus_for_each_dev+0x70/0xc0\n [\u0026lt;ffffffff99804822\u0026gt;] bus_add_driver+0x112/0x210\n [\u0026lt;ffffffff99807245\u0026gt;] driver_register+0x55/0x100\n [\u0026lt;ffffffff990012d1\u0026gt;] do_one_initcall+0x41/0x300\r\n\r\nFix this by freeing dmub_srv after destroying it.(CVE-2024-26833)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncrypto: xilinx - call finalize with bh disabled\r\n\r\nWhen calling crypto_finalize_request, BH should be disabled to avoid\ntriggering the following calltrace:\r\n\r\n ------------[ cut here ]------------\n WARNING: CPU: 2 PID: 74 at crypto/crypto_engine.c:58 crypto_finalize_request+0xa0/0x118\n Modules linked in: cryptodev(O)\n CPU: 2 PID: 74 Comm: firmware:zynqmp Tainted: G O 6.8.0-rc1-yocto-standard #323\n Hardware name: ZynqMP ZCU102 Rev1.0 (DT)\n pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : crypto_finalize_request+0xa0/0x118\n lr : crypto_finalize_request+0x104/0x118\n sp : ffffffc085353ce0\n x29: ffffffc085353ce0 x28: 0000000000000000 x27: ffffff8808ea8688\n x26: ffffffc081715038 x25: 0000000000000000 x24: ffffff880100db00\n x23: ffffff880100da80 x22: 0000000000000000 x21: 0000000000000000\n x20: ffffff8805b14000 x19: ffffff880100da80 x18: 0000000000010450\n x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000\n x14: 0000000000000003 x13: 0000000000000000 x12: ffffff880100dad0\n x11: 0000000000000000 x10: ffffffc0832dcd08 x9 : ffffffc0812416d8\n x8 : 00000000000001f4 x7 : ffffffc0830d2830 x6 : 0000000000000001\n x5 : ffffffc082091000 x4 : ffffffc082091658 x3 : 0000000000000000\n x2 : ffffffc7f9653000 x1 : 0000000000000000 x0 : ffffff8802d20000\n Call trace:\n crypto_finalize_request+0xa0/0x118\n crypto_finalize_aead_request+0x18/0x30\n zynqmp_handle_aes_req+0xcc/0x388\n crypto_pump_work+0x168/0x2d8\n kthread_worker_fn+0xfc/0x3a0\n kthread+0x118/0x138\n ret_from_fork+0x10/0x20\n irq event stamp: 40\n hardirqs last enabled at (39): [\u0026lt;ffffffc0812416f8\u0026gt;] _raw_spin_unlock_irqrestore+0x70/0xb0\n hardirqs last disabled at (40): [\u0026lt;ffffffc08122d208\u0026gt;] el1_dbg+0x28/0x90\n softirqs last enabled at (36): [\u0026lt;ffffffc080017dec\u0026gt;] kernel_neon_begin+0x8c/0xf0\n softirqs last disabled at (34): [\u0026lt;ffffffc080017dc0\u0026gt;] kernel_neon_begin+0x60/0xf0\n ---[ end trace 0000000000000000 ]---(CVE-2024-26877)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nUSB: core: Fix deadlock in usb_deauthorize_interface()\r\n\r\nAmong the attribute file callback routines in\ndrivers/usb/core/sysfs.c, the interface_authorized_store() function is\nthe only one which acquires a device lock on an ancestor device: It\ncalls usb_deauthorize_interface(), which locks the interface\u0026apos;s parent\nUSB device.\r\n\r\nThe will lead to deadlock if another process already owns that lock\nand tries to remove the interface, whether through a configuration\nchange or because the device has been disconnected. As part of the\nremoval procedure, device_del() waits for all ongoing sysfs attribute\ncallbacks to complete. But usb_deauthorize_interface() can\u0026apos;t complete\nuntil the device lock has been released, and the lock won\u0026apos;t be\nreleased until the removal has finished.\r\n\r\nThe mechanism provided by sysfs to prevent this kind of deadlock is\nto use the sysfs_break_active_protection() function, which tells sysfs\nnot to wait for the attribute callback.\r\n\r\nReported-and-tested by: Yue Sun \u0026lt;samsun1006219@gmail.com\u0026gt;\nReported by: xingwei lee \u0026lt;xrivendell7@gmail.com\u0026gt;(CVE-2024-26934)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nf_tables: Fix potential data-race in __nft_expr_type_get()\r\n\r\nnft_unregister_expr() can concurrent with __nft_expr_type_get(),\nand there is not any protection when iterate over nf_tables_expressions\nlist in __nft_expr_type_get(). Therefore, there is potential data-race\nof nf_tables_expressions list entry.\r\n\r\nUse list_for_each_entry_rcu() to iterate over nf_tables_expressions\nlist in __nft_expr_type_get(), and use rcu_read_lock() in the caller\nnft_expr_type_get() to protect the entire type query process.(CVE-2024-27020)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfirewire: nosy: ensure user_length is taken into account when fetching packet contents\r\n\r\nEnsure that packet_buffer_get respects the user_length provided. If\nthe length of the head packet exceeds the user_length, packet_buffer_get\nwill now return 0 to signify to the user that no data were read\nand a larger buffer size is required. Helps prevent user space overflows.(CVE-2024-27401)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nefi/capsule-loader: fix incorrect allocation size\r\n\r\ngcc-14 notices that the allocation with sizeof(void) on 32-bit architectures\nis not enough for a 64-bit phys_addr_t:\r\n\r\ndrivers/firmware/efi/capsule-loader.c: In function \u0026apos;efi_capsule_open\u0026apos;:\ndrivers/firmware/efi/capsule-loader.c:295:24: error: allocation of insufficient size \u0026apos;4\u0026apos; for type \u0026apos;phys_addr_t\u0026apos; {aka \u0026apos;long long unsigned int\u0026apos;} with size \u0026apos;8\u0026apos; [-Werror=alloc-size]\n 295 | cap_info-\u0026gt;phys = kzalloc(sizeof(void *), GFP_KERNEL);\n | ^\r\n\r\nUse the correct type instead here.(CVE-2024-27413)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: udc: remove warning when queue disabled ep\r\n\r\nIt is possible trigger below warning message from mass storage function,\r\n\r\nWARNING: CPU: 6 PID: 3839 at drivers/usb/gadget/udc/core.c:294 usb_ep_queue+0x7c/0x104\npc : usb_ep_queue+0x7c/0x104\nlr : fsg_main_thread+0x494/0x1b3c\r\n\r\nRoot cause is mass storage function try to queue request from main thread,\nbut other thread may already disable ep when function disable.\r\n\r\nAs there is no function failure in the driver, in order to avoid effort\nto fix warning, change WARN_ON_ONCE() in usb_ep_queue() to pr_debug().(CVE-2024-35822)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nvt: fix unicode buffer corruption when deleting characters\r\n\r\nThis is the same issue that was fixed for the VGA text buffer in commit\n39cdb68c64d8 (\u0026quot;vt: fix memory overlapping when deleting chars in the\nbuffer\u0026quot;). The cure is also the same i.e. replace memcpy() with memmove()\ndue to the overlaping buffers.(CVE-2024-35823)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmptcp: use OPTION_MPTCP_MPJ_SYNACK in subflow_finish_connect()\r\n\r\nsubflow_finish_connect() uses four fields (backup, join_id, thmac, none)\nthat may contain garbage unless OPTION_MPTCP_MPJ_SYNACK has been set\nin mptcp_parse_option()(CVE-2024-35840)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nx86/mm/pat: fix VM_PAT handling in COW mappings\r\n\r\nPAT handling won\u0026apos;t do the right thing in COW mappings: the first PTE (or,\nin fact, all PTEs) can be replaced during write faults to point at anon\nfolios. Reliably recovering the correct PFN and cachemode using\nfollow_phys() from PTEs will not work in COW mappings.\r\n\r\nUsing follow_phys(), we might just get the address+protection of the anon\nfolio (which is very wrong), or fail on swap/nonswap entries, failing\nfollow_phys() and triggering a WARN_ON_ONCE() in untrack_pfn() and\ntrack_pfn_copy(), not properly calling free_pfn_range().\r\n\r\nIn free_pfn_range(), we either wouldn\u0026apos;t call memtype_free() or would call\nit with the wrong range, possibly leaking memory.\r\n\r\nTo fix that, let\u0026apos;s update follow_phys() to refuse returning anon folios,\nand fallback to using the stored PFN inside vma-\u0026gt;vm_pgoff for COW mappings\nif we run into that.\r\n\r\nWe will now properly handle untrack_pfn() with COW mappings, where we\ndon\u0026apos;t need the cachemode. We\u0026apos;ll have to fail fork()-\u0026gt;track_pfn_copy() if\nthe first page was replaced by an anon folio, though: we\u0026apos;d have to store\nthe cachemode in the VMA to make this work, likely growing the VMA size.\r\n\r\nFor now, lets keep it simple and let track_pfn_copy() just fail in that\ncase: it would have failed in the past with swap/nonswap entries already,\nand it would have done the wrong thing with anon folios.\r\n\r\nSimple reproducer to trigger the WARN_ON_ONCE() in untrack_pfn():\r\n\r\n\u0026lt;--- C reproducer ---\u0026gt;\n #include \u0026lt;stdio.h\u0026gt;\n #include \u0026lt;sys/mman.h\u0026gt;\n #include \u0026lt;unistd.h\u0026gt;\n #include \u0026lt;liburing.h\u0026gt;\r\n\r\n int main(void)\n {\n struct io_uring_params p = {};\n int ring_fd;\n size_t size;\n char *map;\r\n\r\n ring_fd = io_uring_setup(1, \u0026amp;p);\n if (ring_fd \u0026lt; 0) {\n perror(\u0026quot;io_uring_setup\u0026quot;);\n return 1;\n }\n size = p.sq_off.array + p.sq_entries * sizeof(unsigned);\r\n\r\n /* Map the submission queue ring MAP_PRIVATE */\n map = mmap(0, size, PROT_READ | PROT_WRITE, MAP_PRIVATE,\n ring_fd, IORING_OFF_SQ_RING);\n if (map == MAP_FAILED) {\n perror(\u0026quot;mmap\u0026quot;);\n return 1;\n }\r\n\r\n /* We have at least one page. Let\u0026apos;s COW it. */\n *map = 0;\n pause();\n return 0;\n }\n\u0026lt;--- C reproducer ---\u0026gt;\r\n\r\nOn a system with 16 GiB RAM and swap configured:\n # ./iouring \u0026amp;\n # memhog 16G\n # killall iouring\n[ 301.552930] ------------[ cut here ]------------\n[ 301.553285] WARNING: CPU: 7 PID: 1402 at arch/x86/mm/pat/memtype.c:1060 untrack_pfn+0xf4/0x100\n[ 301.553989] Modules linked in: binfmt_misc nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_g\n[ 301.558232] CPU: 7 PID: 1402 Comm: iouring Not tainted 6.7.5-100.fc38.x86_64 #1\n[ 301.558772] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebu4\n[ 301.559569] RIP: 0010:untrack_pfn+0xf4/0x100\n[ 301.559893] Code: 75 c4 eb cf 48 8b 43 10 8b a8 e8 00 00 00 3b 6b 28 74 b8 48 8b 7b 30 e8 ea 1a f7 000\n[ 301.561189] RSP: 0018:ffffba2c0377fab8 EFLAGS: 00010282\n[ 301.561590] RAX: 00000000ffffffea RBX: ffff9208c8ce9cc0 RCX: 000000010455e047\n[ 301.562105] RDX: 07fffffff0eb1e0a RSI: 0000000000000000 RDI: ffff9208c391d200\n[ 301.562628] RBP: 0000000000000000 R08: ffffba2c0377fab8 R09: 0000000000000000\n[ 301.563145] R10: ffff9208d2292d50 R11: 0000000000000002 R12: 00007fea890e0000\n[ 301.563669] R13: 0000000000000000 R14: ffffba2c0377fc08 R15: 0000000000000000\n[ 301.564186] FS: 0000000000000000(0000) GS:ffff920c2fbc0000(0000) knlGS:0000000000000000\n[ 301.564773] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 301.565197] CR2: 00007fea88ee8a20 CR3: 00000001033a8000 CR4: 0000000000750ef0\n[ 301.565725] PKRU: 55555554\n[ 301.565944] Call Trace:\n[ 301.566148] \u0026lt;TASK\u0026gt;\n[ 301.566325] ? untrack_pfn+0xf4/0x100\n[ 301.566618] ? __warn+0x81/0x130\n[ 301.566876] ? untrack_pfn+0xf4/0x100\n[ 3\n---truncated---(CVE-2024-35877)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndma-direct: Leak pages on dma_set_decrypted() failure\r\n\r\nOn TDX it is possible for the untrusted host to cause\nset_memory_encrypted() or set_memory_decrypted() to fail such that an\nerror is returned and the resulting memory is shared. Callers need to\ntake care to handle these errors to avoid returning decrypted (shared)\nmemory to the page allocator, which could lead to functional or security\nissues.\r\n\r\nDMA could free decrypted/shared pages if dma_set_decrypted() fails. This\nshould be a rare case. Just leak the pages in this case instead of\nfreeing them.(CVE-2024-35939)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/client: Fully protect modes[] with dev-\u0026gt;mode_config.mutex\r\n\r\nThe modes[] array contains pointers to modes on the connectors\u0026apos;\nmode lists, which are protected by dev-\u0026gt;mode_config.mutex.\nThus we need to extend modes[] the same protection or by the\ntime we use it the elements may already be pointing to\nfreed/reused memory.(CVE-2024-35950)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: qgroup: fix qgroup prealloc rsv leak in subvolume operations\r\n\r\nCreate subvolume, create snapshot and delete subvolume all use\nbtrfs_subvolume_reserve_metadata() to reserve metadata for the changes\ndone to the parent subvolume\u0026apos;s fs tree, which cannot be mediated in the\nnormal way via start_transaction. When quota groups (squota or qgroups)\nare enabled, this reserves qgroup metadata of type PREALLOC. Once the\noperation is associated to a transaction, we convert PREALLOC to\nPERTRANS, which gets cleared in bulk at the end of the transaction.\r\n\r\nHowever, the error paths of these three operations were not implementing\nthis lifecycle correctly. They unconditionally converted the PREALLOC to\nPERTRANS in a generic cleanup step regardless of errors or whether the\noperation was fully associated to a transaction or not. This resulted in\nerror paths occasionally converting this rsv to PERTRANS without calling\nrecord_root_in_trans successfully, which meant that unless that root got\nrecorded in the transaction by some other thread, the end of the\ntransaction would not free that root\u0026apos;s PERTRANS, leaking it. Ultimately,\nthis resulted in hitting a WARN in CONFIG_BTRFS_DEBUG builds at unmount\nfor the leaked reservation.\r\n\r\nThe fix is to ensure that every qgroup PREALLOC reservation observes the\nfollowing properties:\r\n\r\n1. any failure before record_root_in_trans is called successfully\n results in freeing the PREALLOC reservation.\n2. after record_root_in_trans, we convert to PERTRANS, and now the\n transaction owns freeing the reservation.\r\n\r\nThis patch enforces those properties on the three operations. Without\nit, generic/269 with squotas enabled at mkfs time would fail in ~5-10\nruns on my system. With this patch, it ran successfully 1000 times in a\nrow.(CVE-2024-35956)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: ena: Fix incorrect descriptor free behavior\r\n\r\nENA has two types of TX queues:\n- queues which only process TX packets arriving from the network stack\n- queues which only process TX packets forwarded to it by XDP_REDIRECT\n or XDP_TX instructions\r\n\r\nThe ena_free_tx_bufs() cycles through all descriptors in a TX queue\nand unmaps + frees every descriptor that hasn\u0026apos;t been acknowledged yet\nby the device (uncompleted TX transactions).\nThe function assumes that the processed TX queue is necessarily from\nthe first category listed above and ends up using napi_consume_skb()\nfor descriptors belonging to an XDP specific queue.\r\n\r\nThis patch solves a bug in which, in case of a VF reset, the\ndescriptors aren\u0026apos;t freed correctly, leading to crashes.(CVE-2024-35958)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/mlx5: Properly link new fs rules into the tree\r\n\r\nPreviously, add_rule_fg would only add newly created rules from the\nhandle into the tree when they had a refcount of 1. On the other hand,\ncreate_flow_handle tries hard to find and reference already existing\nidentical rules instead of creating new ones.\r\n\r\nThese two behaviors can result in a situation where create_flow_handle\n1) creates a new rule and references it, then\n2) in a subsequent step during the same handle creation references it\n again,\nresulting in a rule with a refcount of 2 that is not linked into the\ntree, will have a NULL parent and root and will result in a crash when\nthe flow group is deleted because del_sw_hw_rule, invoked on rule\ndeletion, assumes node-\u0026gt;parent is != NULL.\r\n\r\nThis happened in the wild, due to another bug related to incorrect\nhandling of duplicate pkt_reformat ids, which lead to the code in\ncreate_flow_handle incorrectly referencing a just-added rule in the same\nflow handle, resulting in the problem described above. Full details are\nat [1].\r\n\r\nThis patch changes add_rule_fg to add new rules without parents into\nthe tree, properly initializing them and avoiding the crash. This makes\nit more consistent with how rules are added to an FTE in\ncreate_flow_handle.(CVE-2024-35960)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nBluetooth: Fix memory leak in hci_req_sync_complete()\r\n\r\nIn \u0026apos;hci_req_sync_complete()\u0026apos;, always free the previous sync\nrequest state before assigning reference to a new one.(CVE-2024-35978)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ni2c: smbus: fix NULL function pointer dereference\r\n\r\nBaruch reported an OOPS when using the designware controller as target\nonly. Target-only modes break the assumption of one transfer function\nalways being available. Fix this by always checking the pointer in\n__i2c_transfer.\r\n\r\n[wsa: dropped the simplification in core-smbus to avoid theoretical regressions](CVE-2024-35984)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nACPI: CPPC: Use access_width over bit_width for system memory accesses\r\n\r\nTo align with ACPI 6.3+, since bit_width can be any 8-bit value, it\ncannot be depended on to be always on a clean 8b boundary. This was\nuncovered on the Cobalt 100 platform.\r\n\r\nSError Interrupt on CPU26, code 0xbe000011 -- SError\n CPU: 26 PID: 1510 Comm: systemd-udevd Not tainted 5.15.2.1-13 #1\n Hardware name: MICROSOFT CORPORATION, BIOS MICROSOFT CORPORATION\n pstate: 62400009 (nZCv daif +PAN -UAO +TCO -DIT -SSBS BTYPE=--)\n pc : cppc_get_perf_caps+0xec/0x410\n lr : cppc_get_perf_caps+0xe8/0x410\n sp : ffff8000155ab730\n x29: ffff8000155ab730 x28: ffff0080139d0038 x27: ffff0080139d0078\n x26: 0000000000000000 x25: ffff0080139d0058 x24: 00000000ffffffff\n x23: ffff0080139d0298 x22: ffff0080139d0278 x21: 0000000000000000\n x20: ffff00802b251910 x19: ffff0080139d0000 x18: ffffffffffffffff\n x17: 0000000000000000 x16: ffffdc7e111bad04 x15: ffff00802b251008\n x14: ffffffffffffffff x13: ffff013f1fd63300 x12: 0000000000000006\n x11: ffffdc7e128f4420 x10: 0000000000000000 x9 : ffffdc7e111badec\n x8 : ffff00802b251980 x7 : 0000000000000000 x6 : ffff0080139d0028\n x5 : 0000000000000000 x4 : ffff0080139d0018 x3 : 00000000ffffffff\n x2 : 0000000000000008 x1 : ffff8000155ab7a0 x0 : 0000000000000000\n Kernel panic - not syncing: Asynchronous SError Interrupt\n CPU: 26 PID: 1510 Comm: systemd-udevd Not tainted\n5.15.2.1-13 #1\n Hardware name: MICROSOFT CORPORATION, BIOS MICROSOFT CORPORATION\n Call trace:\n dump_backtrace+0x0/0x1e0\n show_stack+0x24/0x30\n dump_stack_lvl+0x8c/0xb8\n dump_stack+0x18/0x34\n panic+0x16c/0x384\n add_taint+0x0/0xc0\n arm64_serror_panic+0x7c/0x90\n arm64_is_fatal_ras_serror+0x34/0xa4\n do_serror+0x50/0x6c\n el1h_64_error_handler+0x40/0x74\n el1h_64_error+0x7c/0x80\n cppc_get_perf_caps+0xec/0x410\n cppc_cpufreq_cpu_init+0x74/0x400 [cppc_cpufreq]\n cpufreq_online+0x2dc/0xa30\n cpufreq_add_dev+0xc0/0xd4\n subsys_interface_register+0x134/0x14c\n cpufreq_register_driver+0x1b0/0x354\n cppc_cpufreq_init+0x1a8/0x1000 [cppc_cpufreq]\n do_one_initcall+0x50/0x250\n do_init_module+0x60/0x27c\n load_module+0x2300/0x2570\n __do_sys_finit_module+0xa8/0x114\n __arm64_sys_finit_module+0x2c/0x3c\n invoke_syscall+0x78/0x100\n el0_svc_common.constprop.0+0x180/0x1a0\n do_el0_svc+0x84/0xa0\n el0_svc+0x2c/0xc0\n el0t_64_sync_handler+0xa4/0x12c\n el0t_64_sync+0x1a4/0x1a8\r\n\r\nInstead, use access_width to determine the size and use the offset and\nwidth to shift and mask the bits to read/write out. Make sure to add a\ncheck for system memory since pcc redefines the access_width to\nsubspace id.\r\n\r\nIf access_width is not set, then fall back to using bit_width.\r\n\r\n[ rjw: Subject and changelog edits, comment adjustments ](CVE-2024-35995)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmm/hugetlb: fix missing hugetlb_lock for resv uncharge\r\n\r\nThere is a recent report on UFFDIO_COPY over hugetlb:\r\n\r\nhttps://lore.kernel.org/all/000000000000ee06de0616177560@google.com/\r\n\r\n350:\tlockdep_assert_held(\u0026amp;hugetlb_lock);\r\n\r\nShould be an issue in hugetlb but triggered in an userfault context, where\nit goes into the unlikely path where two threads modifying the resv map\ntogether. Mike has a fix in that path for resv uncharge but it looks like\nthe locking criteria was overlooked: hugetlb_cgroup_uncharge_folio_rsvd()\nwill update the cgroup pointer, so it requires to be called with the lock\nheld.(CVE-2024-36000)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nppdev: Add an error check in register_device\r\n\r\nIn register_device, the return value of ida_simple_get is unchecked,\nin witch ida_simple_get will use an invalid index value.\r\n\r\nTo address this issue, index should be checked after ida_simple_get. When\nthe index value is abnormal, a warning message should be printed, the port\nshould be dropped, and the value should be recorded.(CVE-2024-36015)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npinctrl: core: delete incorrect free in pinctrl_enable()\r\n\r\nThe \u0026quot;pctldev\u0026quot; struct is allocated in devm_pinctrl_register_and_init().\nIt\u0026apos;s a devm_ managed pointer that is freed by devm_pinctrl_dev_release(),\nso freeing it in pinctrl_enable() will lead to a double free.\r\n\r\nThe devm_pinctrl_dev_release() function frees the pindescs and destroys\nthe mutex as well.(CVE-2024-36940)",
"id": "OESA-2024-1693",
"modified": "2026-08-06T11:07:09Z",
"published": "2024-06-07T11:07:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1693"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47370"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47489"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48689"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52654"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52655"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52669"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52699"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52703"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52730"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52735"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52736"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52750"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52752"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52759"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52774"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52789"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52795"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52802"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52804"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52805"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52808"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52814"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52818"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52819"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52826"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52832"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52836"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52845"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52858"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52859"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52864"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52871"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52878"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26833"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26877"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26934"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27020"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27401"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27413"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35822"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35823"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35840"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35877"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35939"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35950"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35956"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35958"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35960"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35978"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35984"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35995"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36000"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36015"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36940"
}
],
"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-2021-47370",
"CVE-2021-47489",
"CVE-2022-48689",
"CVE-2023-52654",
"CVE-2023-52655",
"CVE-2023-52669",
"CVE-2023-52699",
"CVE-2023-52703",
"CVE-2023-52730",
"CVE-2023-52735",
"CVE-2023-52736",
"CVE-2023-52750",
"CVE-2023-52752",
"CVE-2023-52759",
"CVE-2023-52774",
"CVE-2023-52789",
"CVE-2023-52795",
"CVE-2023-52802",
"CVE-2023-52804",
"CVE-2023-52805",
"CVE-2023-52808",
"CVE-2023-52814",
"CVE-2023-52818",
"CVE-2023-52819",
"CVE-2023-52826",
"CVE-2023-52832",
"CVE-2023-52836",
"CVE-2023-52845",
"CVE-2023-52858",
"CVE-2023-52859",
"CVE-2023-52864",
"CVE-2023-52871",
"CVE-2023-52878",
"CVE-2024-26833",
"CVE-2024-26877",
"CVE-2024-26934",
"CVE-2024-27020",
"CVE-2024-27401",
"CVE-2024-27413",
"CVE-2024-35822",
"CVE-2024-35823",
"CVE-2024-35840",
"CVE-2024-35877",
"CVE-2024-35939",
"CVE-2024-35950",
"CVE-2024-35956",
"CVE-2024-35958",
"CVE-2024-35960",
"CVE-2024-35978",
"CVE-2024-35984",
"CVE-2024-35995",
"CVE-2024-36000",
"CVE-2024-36015",
"CVE-2024-36940"
]
}
OESA-2024-1694 (CVE-2021-47265)
Vulnerability from osv_openeuler – Published: 2024-06-07 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:
RDMA: Verify port when creating flow rule
Validate port value provided by the user and with that remove no longer needed validation by the driver. The missing check in the mlx5_ib driver could cause to the below oops.
Call trace: _create_flow_rule+0x2d4/0xf28 [mlx5_ib] mlx5_ib_create_flow+0x2d0/0x5b0 [mlx5_ib] ib_uverbs_ex_create_flow+0x4cc/0x624 [ib_uverbs] ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0xd4/0x150 [ib_uverbs] ib_uverbs_cmd_verbs.isra.7+0xb28/0xc50 [ib_uverbs] ib_uverbs_ioctl+0x158/0x1d0 [ib_uverbs] do_vfs_ioctl+0xd0/0xaf0 ksys_ioctl+0x84/0xb4 __arm64_sys_ioctl+0x28/0xc4 el0_svc_common.constprop.3+0xa4/0x254 el0_svc_handler+0x84/0xa0 el0_svc+0x10/0x26c Code: b9401260 f9615681 51000400 8b001c20 (f9403c1a)(CVE-2021-47265)
In the Linux kernel, the following vulnerability has been resolved:
mISDN: fix possible use-after-free in HFC_cleanup()
This module's remove path calls del_timer(). However, that function does not wait until the timer handler finishes. This means that the timer handler may still be running after the driver's remove function has finished, which would result in a use-after-free.
Fix by calling del_timer_sync(), which makes sure the timer handler has finished, and unable to re-schedule itself.(CVE-2021-47356)
In the Linux kernel, the following vulnerability has been resolved:
mptcp: ensure tx skbs always have the MPTCP ext
Due to signed/unsigned comparison, the expression:
info->size_goal - skb->len > 0
evaluates to true when the size goal is smaller than the skb size. That results in lack of tx cache refill, so that the skb allocated by the core TCP code lacks the required MPTCP skb extensions.
Due to the above, syzbot is able to trigger the following WARN_ON():
WARNING: CPU: 1 PID: 810 at net/mptcp/protocol.c:1366 mptcp_sendmsg_frag+0x1362/0x1bc0 net/mptcp/protocol.c:1366 Modules linked in: CPU: 1 PID: 810 Comm: syz-executor.4 Not tainted 5.14.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:mptcp_sendmsg_frag+0x1362/0x1bc0 net/mptcp/protocol.c:1366 Code: ff 4c 8b 74 24 50 48 8b 5c 24 58 e9 0f fb ff ff e8 13 44 8b f8 4c 89 e7 45 31 ed e8 98 57 2e fe e9 81 f4 ff ff e8 fe 43 8b f8 <0f> 0b 41 bd ea ff ff ff e9 6f f4 ff ff 4c 89 e7 e8 b9 8e d2 f8 e9 RSP: 0018:ffffc9000531f6a0 EFLAGS: 00010216 RAX: 000000000000697f RBX: 0000000000000000 RCX: ffffc90012107000 RDX: 0000000000040000 RSI: ffffffff88eac9e2 RDI: 0000000000000003 RBP: ffff888078b15780 R08: 0000000000000000 R09: 0000000000000000 R10: ffffffff88eac017 R11: 0000000000000000 R12: ffff88801de0a280 R13: 0000000000006b58 R14: ffff888066278280 R15: ffff88803c2fe9c0 FS: 00007fd9f866e700(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007faebcb2f718 CR3: 00000000267cb000 CR4: 00000000001506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: __mptcp_push_pending+0x1fb/0x6b0 net/mptcp/protocol.c:1547 mptcp_release_cb+0xfe/0x210 net/mptcp/protocol.c:3003 release_sock+0xb4/0x1b0 net/core/sock.c:3206 sk_stream_wait_memory+0x604/0xed0 net/core/stream.c:145 mptcp_sendmsg+0xc39/0x1bc0 net/mptcp/protocol.c:1749 inet6_sendmsg+0x99/0xe0 net/ipv6/af_inet6.c:643 sock_sendmsg_nosec net/socket.c:704 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:724 sock_write_iter+0x2a0/0x3e0 net/socket.c:1057 call_write_iter include/linux/fs.h:2163 [inline] new_sync_write+0x40b/0x640 fs/read_write.c:507 vfs_write+0x7cf/0xae0 fs/read_write.c:594 ksys_write+0x1ee/0x250 fs/read_write.c:647 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x4665f9 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 bc ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fd9f866e188 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 000000000056c038 RCX: 00000000004665f9 RDX: 00000000000e7b78 RSI: 0000000020000000 RDI: 0000000000000003 RBP: 00000000004bfcc4 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 000000000056c038 R13: 0000000000a9fb1f R14: 00007fd9f866e300 R15: 0000000000022000
Fix the issue rewriting the relevant expression to avoid sign-related problems - note: size_goal is always >= 0.
Additionally, ensure that the skb in the tx cache always carries the relevant extension.(CVE-2021-47370)
In the Linux kernel, the following vulnerability has been resolved:
scsi: iscsi: Fix iscsi_task use after free
Commit d39df158518c ("scsi: iscsi: Have abort handler get ref to conn") added iscsi_get_conn()/iscsi_put_conn() calls during abort handling but then also changed the handling of the case where we detect an already completed task where we now end up doing a goto to the common put/cleanup code. This results in a iscsi_task use after free, because the common cleanup code will do a put on the iscsi_task.
This reverts the goto and moves the iscsi_get_conn() to after we've checked if the iscsi_task is valid.(CVE-2021-47427)
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Fix even more out of bound writes from debugfs
CVE-2021-42327 was fixed by:
commit f23750b5b3d98653b31d4469592935ef6364ad67 Author: Thelford Williams <tdwilliamsiv@gmail.com> Date: Wed Oct 13 16:04:13 2021 -0400
drm/amdgpu: fix out of bounds write
but amdgpu_dm_debugfs.c contains more of the same issue so fix the remaining ones.
v2: * Add missing fix in dp_max_bpc_write (Harry Wentland)(CVE-2021-47489)
In the Linux kernel, the following vulnerability has been resolved:
tcp: TX zerocopy should not sense pfmemalloc status
We got a recent syzbot report [1] showing a possible misuse of pfmemalloc page status in TCP zerocopy paths.
Indeed, for pages coming from user space or other layers, using page_is_pfmemalloc() is moot, and possibly could give false positives.
There has been attempts to make page_is_pfmemalloc() more robust, but not using it in the first place in this context is probably better, removing cpu cycles.
Note to stable teams :
You need to backport 84ce071e38a6 ("net: introduce __skb_fill_page_desc_noacc") as a prereq.
Race is more probable after commit c07aea3ef4d4 ("mm: add a signature in struct page") because page_is_pfmemalloc() is now using low order bit from page->lru.next, which can change more often than page->index.
Low order bit should never be set for lru.next (when used as an anchor in LRU list), so KCSAN report is mostly a false positive.
Backporting to older kernel versions seems not necessary.
[1] BUG: KCSAN: data-race in lru_add_fn / tcp_build_frag
write to 0xffffea0004a1d2c8 of 8 bytes by task 18600 on cpu 0: __list_add include/linux/list.h:73 [inline] list_add include/linux/list.h:88 [inline] lruvec_add_folio include/linux/mm_inline.h:105 [inline] lru_add_fn+0x440/0x520 mm/swap.c:228 folio_batch_move_lru+0x1e1/0x2a0 mm/swap.c:246 folio_batch_add_and_move mm/swap.c:263 [inline] folio_add_lru+0xf1/0x140 mm/swap.c:490 filemap_add_folio+0xf8/0x150 mm/filemap.c:948 __filemap_get_folio+0x510/0x6d0 mm/filemap.c:1981 pagecache_get_page+0x26/0x190 mm/folio-compat.c:104 grab_cache_page_write_begin+0x2a/0x30 mm/folio-compat.c:116 ext4_da_write_begin+0x2dd/0x5f0 fs/ext4/inode.c:2988 generic_perform_write+0x1d4/0x3f0 mm/filemap.c:3738 ext4_buffered_write_iter+0x235/0x3e0 fs/ext4/file.c:270 ext4_file_write_iter+0x2e3/0x1210 call_write_iter include/linux/fs.h:2187 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x468/0x760 fs/read_write.c:578 ksys_write+0xe8/0x1a0 fs/read_write.c:631 __do_sys_write fs/read_write.c:643 [inline] __se_sys_write fs/read_write.c:640 [inline] __x64_sys_write+0x3e/0x50 fs/read_write.c:640 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd
read to 0xffffea0004a1d2c8 of 8 bytes by task 18611 on cpu 1: page_is_pfmemalloc include/linux/mm.h:1740 [inline] __skb_fill_page_desc include/linux/skbuff.h:2422 [inline] skb_fill_page_desc include/linux/skbuff.h:2443 [inline] tcp_build_frag+0x613/0xb20 net/ipv4/tcp.c:1018 do_tcp_sendpages+0x3e8/0xaf0 net/ipv4/tcp.c:1075 tcp_sendpage_locked net/ipv4/tcp.c:1140 [inline] tcp_sendpage+0x89/0xb0 net/ipv4/tcp.c:1150 inet_sendpage+0x7f/0xc0 net/ipv4/af_inet.c:833 kernel_sendpage+0x184/0x300 net/socket.c:3561 sock_sendpage+0x5a/0x70 net/socket.c:1054 pipe_to_sendpage+0x128/0x160 fs/splice.c:361 splice_from_pipe_feed fs/splice.c:415 [inline] __splice_from_pipe+0x222/0x4d0 fs/splice.c:559 splice_from_pipe fs/splice.c:594 [inline] generic_splice_sendpage+0x89/0xc0 fs/splice.c:743 do_splice_from fs/splice.c:764 [inline] direct_splice_actor+0x80/0xa0 fs/splice.c:931 splice_direct_to_actor+0x305/0x620 fs/splice.c:886 do_splice_direct+0xfb/0x180 fs/splice.c:974 do_sendfile+0x3bf/0x910 fs/read_write.c:1249 __do_sys_sendfile64 fs/read_write.c:1317 [inline] __se_sys_sendfile64 fs/read_write.c:1303 [inline] __x64_sys_sendfile64+0x10c/0x150 fs/read_write.c:1303 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd
value changed: 0x0000000000000000 -> 0xffffea0004a1d288
Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 18611 Comm: syz-executor.4 Not tainted 6.0.0-rc2-syzkaller-00248-ge022620b5d05-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/22/2022(CVE-2022-48689)
In the Linux kernel, the following vulnerability has been resolved:
io_uring/af_unix: disable sending io_uring over sockets
File reference cycles have caused lots of problems for io_uring in the past, and it still doesn't work exactly right and races with unix_stream_read_generic(). The safest fix would be to completely disallow sending io_uring files via sockets via SCM_RIGHT, so there are no possible cycles invloving registered files and thus rendering SCM accounting on the io_uring side unnecessary.(CVE-2023-52654)
In the Linux kernel, the following vulnerability has been resolved:
crypto: s390/aes - Fix buffer overread in CTR mode
When processing the last block, the s390 ctr code will always read a whole block, even if there isn't a whole block of data left. Fix this by using the actual length left and copy it into a buffer first for processing.(CVE-2023-52669)
In the Linux kernel, the following vulnerability has been resolved:
riscv: Check if the code to patch lies in the exit section
Otherwise we fall through to vmalloc_to_page() which panics since the address does not lie in the vmalloc region.(CVE-2023-52677)
In the Linux kernel, the following vulnerability has been resolved:
powerpc/powernv: Add a null pointer check in opal_powercap_init()
kasprintf() returns a pointer to dynamically allocated memory which can be NULL upon failure.(CVE-2023-52696)
In the Linux kernel, the following vulnerability has been resolved:
sysv: don't call sb_bread() with pointers_lock held
syzbot is reporting sleep in atomic context in SysV filesystem [1], for sb_bread() is called with rw_spinlock held.
A "write_lock(&pointers_lock) => read_lock(&pointers_lock) deadlock" bug and a "sb_bread() with write_lock(&pointers_lock)" bug were introduced by "Replace BKL for chain locking with sysvfs-private rwlock" in Linux 2.5.12.
Then, "[PATCH] err1-40: sysvfs locking fix" in Linux 2.6.8 fixed the former bug by moving pointers_lock lock to the callers, but instead introduced a "sb_bread() with read_lock(&pointers_lock)" bug (which made this problem easier to hit).
Al Viro suggested that why not to do like get_branch()/get_block()/ find_shared() in Minix filesystem does. And doing like that is almost a revert of "[PATCH] err1-40: sysvfs locking fix" except that get_branch() from with find_shared() is called without write_lock(&pointers_lock).(CVE-2023-52699)
In the Linux kernel, the following vulnerability has been resolved:
arm64: Restrict CPU_BIG_ENDIAN to GNU as or LLVM IAS 15.x or newer
Prior to LLVM 15.0.0, LLVM's integrated assembler would incorrectly byte-swap NOP when compiling for big-endian, and the resulting series of bytes happened to match the encoding of FNMADD S21, S30, S0, S0.
This went unnoticed until commit:
34f66c4c4d5518c1 ("arm64: Use a positive cpucap for FP/SIMD")
Prior to that commit, the kernel would always enable the use of FPSIMD early in boot when __cpu_setup() initialized CPACR_EL1, and so usage of FNMADD within the kernel was not detected, but could result in the corruption of user or kernel FPSIMD state.
After that commit, the instructions happen to trap during boot prior to FPSIMD being detected and enabled, e.g.
| Unhandled 64-bit el1h sync exception on CPU0, ESR 0x000000001fe00000 -- ASIMD | CPU: 0 PID: 0 Comm: swapper Not tainted 6.6.0-rc3-00013-g34f66c4c4d55 #1 | Hardware name: linux,dummy-virt (DT) | pstate: 400000c9 (nZcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) | pc : __pi_strcmp+0x1c/0x150 | lr : populate_properties+0xe4/0x254 | sp : ffffd014173d3ad0 | x29: ffffd014173d3af0 x28: fffffbfffddffcb8 x27: 0000000000000000 | x26: 0000000000000058 x25: fffffbfffddfe054 x24: 0000000000000008 | x23: fffffbfffddfe000 x22: fffffbfffddfe000 x21: fffffbfffddfe044 | x20: ffffd014173d3b70 x19: 0000000000000001 x18: 0000000000000005 | x17: 0000000000000010 x16: 0000000000000000 x15: 00000000413e7000 | x14: 0000000000000000 x13: 0000000000001bcc x12: 0000000000000000 | x11: 00000000d00dfeed x10: ffffd414193f2cd0 x9 : 0000000000000000 | x8 : 0101010101010101 x7 : ffffffffffffffc0 x6 : 0000000000000000 | x5 : 0000000000000000 x4 : 0101010101010101 x3 : 000000000000002a | x2 : 0000000000000001 x1 : ffffd014171f2988 x0 : fffffbfffddffcb8 | Kernel panic - not syncing: Unhandled exception | CPU: 0 PID: 0 Comm: swapper Not tainted 6.6.0-rc3-00013-g34f66c4c4d55 #1 | Hardware name: linux,dummy-virt (DT) | Call trace: | dump_backtrace+0xec/0x108 | show_stack+0x18/0x2c | dump_stack_lvl+0x50/0x68 | dump_stack+0x18/0x24 | panic+0x13c/0x340 | el1t_64_irq_handler+0x0/0x1c | el1_abort+0x0/0x5c | el1h_64_sync+0x64/0x68 | __pi_strcmp+0x1c/0x150 | unflatten_dt_nodes+0x1e8/0x2d8 | __unflatten_device_tree+0x5c/0x15c | unflatten_device_tree+0x38/0x50 | setup_arch+0x164/0x1e0 | start_kernel+0x64/0x38c | __primary_switched+0xbc/0xc4
Restrict CONFIG_CPU_BIG_ENDIAN to a known good assembler, which is either GNU as or LLVM's IAS 15.0.0 and newer, which contains the linked commit.(CVE-2023-52750)
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix use-after-free bug in cifs_debug_data_proc_show()
Skip SMB sessions that are being teared down (e.g. @ses->ses_status == SES_EXITING) in cifs_debug_data_proc_show() to avoid use-after-free in @ses.
This fixes the following GPF when reading from /proc/fs/cifs/DebugData while mounting and umounting
[ 816.251274] general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6d81: 0000 [#1] PREEMPT SMP NOPTI ... [ 816.260138] Call Trace: [ 816.260329] <TASK> [ 816.260499] ? die_addr+0x36/0x90 [ 816.260762] ? exc_general_protection+0x1b3/0x410 [ 816.261126] ? asm_exc_general_protection+0x26/0x30 [ 816.261502] ? cifs_debug_tcon+0xbd/0x240 [cifs] [ 816.261878] ? cifs_debug_tcon+0xab/0x240 [cifs] [ 816.262249] cifs_debug_data_proc_show+0x516/0xdb0 [cifs] [ 816.262689] ? seq_read_iter+0x379/0x470 [ 816.262995] seq_read_iter+0x118/0x470 [ 816.263291] proc_reg_read_iter+0x53/0x90 [ 816.263596] ? srso_alias_return_thunk+0x5/0x7f [ 816.263945] vfs_read+0x201/0x350 [ 816.264211] ksys_read+0x75/0x100 [ 816.264472] do_syscall_64+0x3f/0x90 [ 816.264750] entry_SYSCALL_64_after_hwframe+0x6e/0xd8 [ 816.265135] RIP: 0033:0x7fd5e669d381(CVE-2023-52752)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Avoid NULL dereference of timing generator
[Why & How] Check whether assigned timing generator is NULL or not before accessing its funcs to prevent NULL dereference.(CVE-2023-52753)
In the Linux kernel, the following vulnerability has been resolved:
pwm: Fix double shift bug
These enums are passed to set/test_bit(). The set/test_bit() functions take a bit number instead of a shifted value. Passing a shifted value is a double shift bug like doing BIT(BIT(1)). The double shift bug doesn't cause a problem here because we are only checking 0 and 1 but if the value was 5 or above then it can lead to a buffer overflow.(CVE-2023-52756)
In the Linux kernel, the following vulnerability has been resolved:
gfs2: ignore negated quota changes
When lots of quota changes are made, there may be cases in which an inode's quota information is increased and then decreased, such as when blocks are added to a file, then deleted from it. If the timing is right, function do_qc can add pending quota changes to a transaction, then later, another call to do_qc can negate those changes, resulting in a net gain of 0. The quota_change information is recorded in the qc buffer (and qd element of the inode as well). The buffer is added to the transaction by the first call to do_qc, but a subsequent call changes the value from non-zero back to zero. At that point it's too late to remove the buffer_head from the transaction. Later, when the quota sync code is called, the zero-change qd element is discovered and flagged as an assert warning. If the fs is mounted with errors=panic, the kernel will panic.
This is usually seen when files are truncated and the quota changes are negated by punch_hole/truncate which uses gfs2_quota_hold and gfs2_quota_unhold rather than block allocations that use gfs2_quota_lock and gfs2_quota_unlock which automatically do quota sync.
This patch solves the problem by adding a check to qd_check_sync such that net-zero quota changes already added to the transaction are no longer deemed necessary to be synced, and skipped.
In this case references are taken for the qd and the slot from do_qc so those need to be put. The normal sequence of events for a normal non-zero quota change is as follows:
gfs2_quota_change do_qc qd_hold slot_hold
Later, when the changes are to be synced:
gfs2_quota_sync qd_fish qd_check_sync gets qd ref via lockref_get_not_dead do_sync do_qc(QC_SYNC) qd_put lockref_put_or_lock qd_unlock qd_put lockref_put_or_lock
In the net-zero change case, we add a check to qd_check_sync so it puts the qd and slot references acquired in gfs2_quota_change and skip the unneeded sync.(CVE-2023-52759)
In the Linux kernel, the following vulnerability has been resolved:
s390/dasd: protect device queue against concurrent access
In dasd_profile_start() the amount of requests on the device queue are counted. The access to the device queue is unprotected against concurrent access. With a lot of parallel I/O, especially with alias devices enabled, the device queue can change while dasd_profile_start() is accessing the queue. In the worst case this leads to a kernel panic due to incorrect pointer accesses.
Fix this by taking the device lock before accessing the queue and counting the requests. Additionally the check for a valid profile data pointer can be done earlier to avoid unnecessary locking in a hot path.(CVE-2023-52774)
In the Linux kernel, the following vulnerability has been resolved:
tty: vcc: Add check for kstrdup() in vcc_probe()
Add check for the return value of kstrdup() and return the error, if it fails in order to avoid NULL pointer dereference.(CVE-2023-52789)
In the Linux kernel, the following vulnerability has been resolved:
vhost-vdpa: fix use after free in vhost_vdpa_probe()
The put_device() calls vhost_vdpa_release_dev() which calls ida_simple_remove() and frees "v". So this call to ida_simple_remove() is a use after free and a double free.(CVE-2023-52795)
In the Linux kernel, the following vulnerability has been resolved:
ipvlan: add ipvlan_route_v6_outbound() helper
Inspired by syzbot reports using a stack of multiple ipvlan devices.
Reduce stack size needed in ipvlan_process_v6_outbound() by moving the flowi6 struct used for the route lookup in an non inlined helper. ipvlan_route_v6_outbound() needs 120 bytes on the stack, immediately reclaimed.
Also make sure ipvlan_process_v4_outbound() is not inlined.
We might also have to lower MAX_NEST_DEV, because only syzbot uses setups with more than four stacked devices.
BUG: TASK stack guard page was hit at ffffc9000e803ff8 (stack is ffffc9000e804000..ffffc9000e808000) stack guard page: 0000 [#1] SMP KASAN CPU: 0 PID: 13442 Comm: syz-executor.4 Not tainted 6.1.52-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/09/2023 RIP: 0010:kasan_check_range+0x4/0x2a0 mm/kasan/generic.c:188 Code: 48 01 c6 48 89 c7 e8 db 4e c1 03 31 c0 5d c3 cc 0f 0b eb 02 0f 0b b8 ea ff ff ff 5d c3 cc 00 00 cc cc 00 00 cc cc 55 48 89 e5 <41> 57 41 56 41 55 41 54 53 b0 01 48 85 f6 0f 84 a4 01 00 00 48 89 RSP: 0018:ffffc9000e804000 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff817e5bf2 RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffffffff887c6568 RBP: ffffc9000e804000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: dffffc0000000001 R12: 1ffff92001d0080c R13: dffffc0000000000 R14: ffffffff87e6b100 R15: 0000000000000000 FS: 00007fd0c55826c0(0000) GS:ffff8881f6800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffc9000e803ff8 CR3: 0000000170ef7000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <#DF> </#DF> <TASK> [<ffffffff81f281d1>] __kasan_check_read+0x11/0x20 mm/kasan/shadow.c:31 [<ffffffff817e5bf2>] instrument_atomic_read include/linux/instrumented.h:72 [inline] [<ffffffff817e5bf2>] _test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline] [<ffffffff817e5bf2>] cpumask_test_cpu include/linux/cpumask.h:506 [inline] [<ffffffff817e5bf2>] cpu_online include/linux/cpumask.h:1092 [inline] [<ffffffff817e5bf2>] trace_lock_acquire include/trace/events/lock.h:24 [inline] [<ffffffff817e5bf2>] lock_acquire+0xe2/0x590 kernel/locking/lockdep.c:5632 [<ffffffff8563221e>] rcu_lock_acquire+0x2e/0x40 include/linux/rcupdate.h:306 [<ffffffff8561464d>] rcu_read_lock include/linux/rcupdate.h:747 [inline] [<ffffffff8561464d>] ip6_pol_route+0x15d/0x1440 net/ipv6/route.c:2221 [<ffffffff85618120>] ip6_pol_route_output+0x50/0x80 net/ipv6/route.c:2606 [<ffffffff856f65b5>] pol_lookup_func include/net/ip6_fib.h:584 [inline] [<ffffffff856f65b5>] fib6_rule_lookup+0x265/0x620 net/ipv6/fib6_rules.c:116 [<ffffffff85618009>] ip6_route_output_flags_noref+0x2d9/0x3a0 net/ipv6/route.c:2638 [<ffffffff8561821a>] ip6_route_output_flags+0xca/0x340 net/ipv6/route.c:2651 [<ffffffff838bd5a3>] ip6_route_output include/net/ip6_route.h:100 [inline] [<ffffffff838bd5a3>] ipvlan_process_v6_outbound drivers/net/ipvlan/ipvlan_core.c:473 [inline] [<ffffffff838bd5a3>] ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:529 [inline] [<ffffffff838bd5a3>] ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline] [<ffffffff838bd5a3>] ipvlan_queue_xmit+0xc33/0x1be0 drivers/net/ipvlan/ipvlan_core.c:677 [<ffffffff838c2909>] ipvlan_start_xmit+0x49/0x100 drivers/net/ipvlan/ipvlan_main.c:229 [<ffffffff84d03900>] netdev_start_xmit include/linux/netdevice.h:4966 [inline] [<ffffffff84d03900>] xmit_one net/core/dev.c:3644 [inline] [<ffffffff84d03900>] dev_hard_start_xmit+0x320/0x980 net/core/dev.c:3660 [<ffffffff84d080e2>] __dev_queue_xmit+0x16b2/0x3370 net/core/dev.c:4324 [<ffffffff855ce4cd>] dev_queue_xmit include/linux/netdevice.h:3067 [inline] [<ffffffff855ce4cd>] neigh_hh_output include/net/neighbour.h:529 [inline] [<f ---truncated---(CVE-2023-52796)
In the Linux kernel, the following vulnerability has been resolved:
wifi: ath11k: fix dfs radar event locking
The ath11k active pdevs are protected by RCU but the DFS radar event handling code calling ath11k_mac_get_ar_by_pdev_id() was not marked as a read-side critical section.
Mark the code in question as an RCU read-side critical section to avoid any potential use-after-free issues.
Compile tested only.(CVE-2023-52798)
In the Linux kernel, the following vulnerability has been resolved:
jfs: fix array-index-out-of-bounds in dbFindLeaf
Currently while searching for dmtree_t for sufficient free blocks there is an array out of bounds while getting element in tp->dm_stree. To add the required check for out of bound we first need to determine the type of dmtree. Thus added an extra parameter to dbFindLeaf so that the type of tree can be determined and the required check can be applied.(CVE-2023-52799)
In the Linux kernel, the following vulnerability has been resolved:
wifi: ath11k: fix htt pktlog locking
The ath11k active pdevs are protected by RCU but the htt pktlog handling code calling ath11k_mac_get_ar_by_pdev_id() was not marked as a read-side critical section.
Mark the code in question as an RCU read-side critical section to avoid any potential use-after-free issues.
Compile tested only.(CVE-2023-52800)
In the Linux kernel, the following vulnerability has been resolved:
iio: adc: stm32-adc: harden against NULL pointer deref in stm32_adc_probe()
of_match_device() may fail and returns a NULL pointer.
In practice there is no known reasonable way to trigger this, but in case one is added in future, harden the code by adding the check(CVE-2023-52802)
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Fix potential null pointer derefernce
The amdgpu_ras_get_context may return NULL if device not support ras feature, so add check before using.(CVE-2023-52814)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd: Fix UBSAN array-index-out-of-bounds for Polaris and Tonga
For pptable structs that use flexible array sizes, use flexible arrays.(CVE-2023-52819)
In the Linux kernel, the following vulnerability has been resolved:
drm/panel/panel-tpo-tpg110: fix a possible null pointer dereference
In tpg110_get_modes(), the return value of drm_mode_duplicate() is assigned to mode, which will lead to a NULL pointer dereference on failure of drm_mode_duplicate(). Add a check to avoid npd.(CVE-2023-52826)
In the Linux kernel, the following vulnerability has been resolved:
cpu/hotplug: Don't offline the last non-isolated CPU
If a system has isolated CPUs via the "isolcpus=" command line parameter, then an attempt to offline the last housekeeping CPU will result in a WARN_ON() when rebuilding the scheduler domains and a subsequent panic due to and unhandled empty CPU mas in partition_sched_domains_locked().
cpuset_hotplug_workfn() rebuild_sched_domains_locked() ndoms = generate_sched_domains(&doms, &attr); cpumask_and(doms[0], top_cpuset.effective_cpus, housekeeping_cpumask(HK_FLAG_DOMAIN));
Thus results in an empty CPU mask which triggers the warning and then the subsequent crash:
WARNING: CPU: 4 PID: 80 at kernel/sched/topology.c:2366 build_sched_domains+0x120c/0x1408 Call trace: build_sched_domains+0x120c/0x1408 partition_sched_domains_locked+0x234/0x880 rebuild_sched_domains_locked+0x37c/0x798 rebuild_sched_domains+0x30/0x58 cpuset_hotplug_workfn+0x2a8/0x930
Unable to handle kernel paging request at virtual address fffe80027ab37080 partition_sched_domains_locked+0x318/0x880 rebuild_sched_domains_locked+0x37c/0x798
Aside of the resulting crash, it does not make any sense to offline the last last housekeeping CPU.
Prevent this by masking out the non-housekeeping CPUs when selecting a target CPU for initiating the CPU unplug operation via the work queue.(CVE-2023-52831)
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: don't return unset power in ieee80211_get_tx_power()
We can get a UBSAN warning if ieee80211_get_tx_power() returns the INT_MIN value mac80211 internally uses for "unset power level".
UBSAN: signed-integer-overflow in net/wireless/nl80211.c:3816:5 -2147483648 * 100 cannot be represented in type 'int' CPU: 0 PID: 20433 Comm: insmod Tainted: G WC OE Call Trace: dump_stack+0x74/0x92 ubsan_epilogue+0x9/0x50 handle_overflow+0x8d/0xd0 __ubsan_handle_mul_overflow+0xe/0x10 nl80211_send_iface+0x688/0x6b0 [cfg80211] [...] cfg80211_register_wdev+0x78/0xb0 [cfg80211] cfg80211_netdev_notifier_call+0x200/0x620 [cfg80211] [...] ieee80211_if_add+0x60e/0x8f0 [mac80211] ieee80211_register_hw+0xda5/0x1170 [mac80211]
In this case, simply return an error instead, to indicate that no data is available.(CVE-2023-52832)
In the Linux kernel, the following vulnerability has been resolved:
locking/ww_mutex/test: Fix potential workqueue corruption
In some cases running with the test-ww_mutex code, I was seeing odd behavior where sometimes it seemed flush_workqueue was returning before all the work threads were finished.
Often this would cause strange crashes as the mutexes would be freed while they were being used.
Looking at the code, there is a lifetime problem as the controlling thread that spawns the work allocates the "struct stress" structures that are passed to the workqueue threads. Then when the workqueue threads are finished, they free the stress struct that was passed to them.
Unfortunately the workqueue work_struct node is in the stress struct. Which means the work_struct is freed before the work thread returns and while flush_workqueue is waiting.
It seems like a better idea to have the controlling thread both allocate and free the stress structures, so that we can be sure we don't corrupt the workqueue by freeing the structure prematurely.
So this patch reworks the test to do so, and with this change I no longer see the early flush_workqueue returns.(CVE-2023-52836)
In the Linux kernel, the following vulnerability has been resolved:
fbdev: imsttfb: fix a resource leak in probe
I've re-written the error handling but the bug is that if init_imstt() fails we need to call iounmap(par->cmap_regs).(CVE-2023-52838)
In the Linux kernel, the following vulnerability has been resolved:
platform/x86: wmi: Fix opening of char device
Since commit fa1f68db6ca7 ("drivers: misc: pass miscdevice pointer via file private data"), the miscdevice stores a pointer to itself inside filp->private_data, which means that private_data will not be NULL when wmi_char_open() is called. This might cause memory corruption should wmi_char_open() be unable to find its driver, something which can happen when the associated WMI device is deleted in wmi_free_devices().
Fix the problem by using the miscdevice pointer to retrieve the WMI device data associated with a char device using container_of(). This also avoids wmi_char_open() picking a wrong WMI device bound to a driver with the same name as the original driver.(CVE-2023-52864)
In the Linux kernel, the following vulnerability has been resolved:
clk: mediatek: clk-mt6797: Add check for mtk_alloc_clk_data
Add the check for the return value of mtk_alloc_clk_data() in order to avoid NULL pointer dereference.(CVE-2023-52865)
In the Linux kernel, the following vulnerability has been resolved:
soc: qcom: llcc: Handle a second device without data corruption
Usually there is only one llcc device. But if there were a second, even a failed probe call would modify the global drv_data pointer. So check if drv_data is valid before overwriting it.(CVE-2023-52871)
In the Linux kernel, the following vulnerability has been resolved:
clk: mediatek: clk-mt2701: Add check for mtk_alloc_clk_data
Add the check for the return value of mtk_alloc_clk_data() in order to avoid NULL pointer dereference.(CVE-2023-52875)
In the Linux kernel, the following vulnerability has been resolved:
can: dev: can_put_echo_skb(): don't crash kernel if can_priv::echo_skb is accessed out of bounds
If the "struct can_priv::echoo_skb" is accessed out of bounds, this would cause a kernel crash. Instead, issue a meaningful warning message and return with an error.(CVE-2023-52878)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix memory leak in dm_sw_fini()
After destroying dmub_srv, the memory associated with it is not freed, causing a memory leak:
unreferenced object 0xffff896302b45800 (size 1024): comm "(udev-worker)", pid 222, jiffies 4294894636 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 6265fd77): [<ffffffff993495ed>] kmalloc_trace+0x29d/0x340 [<ffffffffc0ea4a94>] dm_dmub_sw_init+0xb4/0x450 [amdgpu] [<ffffffffc0ea4e55>] dm_sw_init+0x15/0x2b0 [amdgpu] [<ffffffffc0ba8557>] amdgpu_device_init+0x1417/0x24e0 [amdgpu] [<ffffffffc0bab285>] amdgpu_driver_load_kms+0x15/0x190 [amdgpu] [<ffffffffc0ba09c7>] amdgpu_pci_probe+0x187/0x4e0 [amdgpu] [<ffffffff9968fd1e>] local_pci_probe+0x3e/0x90 [<ffffffff996918a3>] pci_device_probe+0xc3/0x230 [<ffffffff99805872>] really_probe+0xe2/0x480 [<ffffffff99805c98>] __driver_probe_device+0x78/0x160 [<ffffffff99805daf>] driver_probe_device+0x1f/0x90 [<ffffffff9980601e>] __driver_attach+0xce/0x1c0 [<ffffffff99803170>] bus_for_each_dev+0x70/0xc0 [<ffffffff99804822>] bus_add_driver+0x112/0x210 [<ffffffff99807245>] driver_register+0x55/0x100 [<ffffffff990012d1>] do_one_initcall+0x41/0x300
Fix this by freeing dmub_srv after destroying it.(CVE-2024-26833)
In the Linux kernel, the following vulnerability has been resolved:
crypto: xilinx - call finalize with bh disabled
When calling crypto_finalize_request, BH should be disabled to avoid triggering the following calltrace:
------------[ cut here ]------------
WARNING: CPU: 2 PID: 74 at crypto/crypto_engine.c:58 crypto_finalize_request+0xa0/0x118
Modules linked in: cryptodev(O)
CPU: 2 PID: 74 Comm: firmware:zynqmp Tainted: G O 6.8.0-rc1-yocto-standard #323
Hardware name: ZynqMP ZCU102 Rev1.0 (DT)
pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : crypto_finalize_request+0xa0/0x118
lr : crypto_finalize_request+0x104/0x118
sp : ffffffc085353ce0
x29: ffffffc085353ce0 x28: 0000000000000000 x27: ffffff8808ea8688
x26: ffffffc081715038 x25: 0000000000000000 x24: ffffff880100db00
x23: ffffff880100da80 x22: 0000000000000000 x21: 0000000000000000
x20: ffffff8805b14000 x19: ffffff880100da80 x18: 0000000000010450
x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
x14: 0000000000000003 x13: 0000000000000000 x12: ffffff880100dad0
x11: 0000000000000000 x10: ffffffc0832dcd08 x9 : ffffffc0812416d8
x8 : 00000000000001f4 x7 : ffffffc0830d2830 x6 : 0000000000000001
x5 : ffffffc082091000 x4 : ffffffc082091658 x3 : 0000000000000000
x2 : ffffffc7f9653000 x1 : 0000000000000000 x0 : ffffff8802d20000
Call trace:
crypto_finalize_request+0xa0/0x118
crypto_finalize_aead_request+0x18/0x30
zynqmp_handle_aes_req+0xcc/0x388
crypto_pump_work+0x168/0x2d8
kthread_worker_fn+0xfc/0x3a0
kthread+0x118/0x138
ret_from_fork+0x10/0x20
irq event stamp: 40
hardirqs last enabled at (39): [<ffffffc0812416f8>] _raw_spin_unlock_irqrestore+0x70/0xb0
hardirqs last disabled at (40): [<ffffffc08122d208>] el1_dbg+0x28/0x90
softirqs last enabled at (36): [<ffffffc080017dec>] kernel_neon_begin+0x8c/0xf0
softirqs last disabled at (34): [<ffffffc080017dc0>] kernel_neon_begin+0x60/0xf0
---[ end trace 0000000000000000 ]---(CVE-2024-26877)
In the Linux kernel, the following vulnerability has been resolved:
USB: core: Fix deadlock in usb_deauthorize_interface()
Among the attribute file callback routines in drivers/usb/core/sysfs.c, the interface_authorized_store() function is the only one which acquires a device lock on an ancestor device: It calls usb_deauthorize_interface(), which locks the interface's parent USB device.
The will lead to deadlock if another process already owns that lock and tries to remove the interface, whether through a configuration change or because the device has been disconnected. As part of the removal procedure, device_del() waits for all ongoing sysfs attribute callbacks to complete. But usb_deauthorize_interface() can't complete until the device lock has been released, and the lock won't be released until the removal has finished.
The mechanism provided by sysfs to prevent this kind of deadlock is to use the sysfs_break_active_protection() function, which tells sysfs not to wait for the attribute callback.
Reported-and-tested by: Yue Sun <samsun1006219@gmail.com> Reported by: xingwei lee <xrivendell7@gmail.com>(CVE-2024-26934)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: Fix potential data-race in __nft_expr_type_get()
nft_unregister_expr() can concurrent with __nft_expr_type_get(), and there is not any protection when iterate over nf_tables_expressions list in __nft_expr_type_get(). Therefore, there is potential data-race of nf_tables_expressions list entry.
Use list_for_each_entry_rcu() to iterate over nf_tables_expressions list in __nft_expr_type_get(), and use rcu_read_lock() in the caller nft_expr_type_get() to protect the entire type query process.(CVE-2024-27020)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: l2cap: fix null-ptr-deref in l2cap_chan_timeout
There is a race condition between l2cap_chan_timeout() and l2cap_chan_del(). When we use l2cap_chan_del() to delete the channel, the chan->conn will be set to null. But the conn could be dereferenced again in the mutex_lock() of l2cap_chan_timeout(). As a result the null pointer dereference bug will happen. The KASAN report triggered by POC is shown below:
[ 472.074580] ================================================================== [ 472.075284] BUG: KASAN: null-ptr-deref in mutex_lock+0x68/0xc0 [ 472.075308] Write of size 8 at addr 0000000000000158 by task kworker/0:0/7 [ 472.075308] [ 472.075308] CPU: 0 PID: 7 Comm: kworker/0:0 Not tainted 6.9.0-rc5-00356-g78c0094a146b #36 [ 472.075308] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu4 [ 472.075308] Workqueue: events l2cap_chan_timeout [ 472.075308] Call Trace: [ 472.075308] <TASK> [ 472.075308] dump_stack_lvl+0x137/0x1a0 [ 472.075308] print_report+0x101/0x250 [ 472.075308] ? __virt_addr_valid+0x77/0x160 [ 472.075308] ? mutex_lock+0x68/0xc0 [ 472.075308] kasan_report+0x139/0x170 [ 472.075308] ? mutex_lock+0x68/0xc0 [ 472.075308] kasan_check_range+0x2c3/0x2e0 [ 472.075308] mutex_lock+0x68/0xc0 [ 472.075308] l2cap_chan_timeout+0x181/0x300 [ 472.075308] process_one_work+0x5d2/0xe00 [ 472.075308] worker_thread+0xe1d/0x1660 [ 472.075308] ? pr_cont_work+0x5e0/0x5e0 [ 472.075308] kthread+0x2b7/0x350 [ 472.075308] ? pr_cont_work+0x5e0/0x5e0 [ 472.075308] ? kthread_blkcg+0xd0/0xd0 [ 472.075308] ret_from_fork+0x4d/0x80 [ 472.075308] ? kthread_blkcg+0xd0/0xd0 [ 472.075308] ret_from_fork_asm+0x11/0x20 [ 472.075308] </TASK> [ 472.075308] ================================================================== [ 472.094860] Disabling lock debugging due to kernel taint [ 472.096136] BUG: kernel NULL pointer dereference, address: 0000000000000158 [ 472.096136] #PF: supervisor write access in kernel mode [ 472.096136] #PF: error_code(0x0002) - not-present page [ 472.096136] PGD 0 P4D 0 [ 472.096136] Oops: 0002 [#1] PREEMPT SMP KASAN NOPTI [ 472.096136] CPU: 0 PID: 7 Comm: kworker/0:0 Tainted: G B 6.9.0-rc5-00356-g78c0094a146b #36 [ 472.096136] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu4 [ 472.096136] Workqueue: events l2cap_chan_timeout [ 472.096136] RIP: 0010:mutex_lock+0x88/0xc0 [ 472.096136] Code: be 08 00 00 00 e8 f8 23 1f fd 4c 89 f7 be 08 00 00 00 e8 eb 23 1f fd 42 80 3c 23 00 74 08 48 88 [ 472.096136] RSP: 0018:ffff88800744fc78 EFLAGS: 00000246 [ 472.096136] RAX: 0000000000000000 RBX: 1ffff11000e89f8f RCX: ffffffff8457c865 [ 472.096136] RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffff88800744fc78 [ 472.096136] RBP: 0000000000000158 R08: ffff88800744fc7f R09: 1ffff11000e89f8f [ 472.096136] R10: dffffc0000000000 R11: ffffed1000e89f90 R12: dffffc0000000000 [ 472.096136] R13: 0000000000000158 R14: ffff88800744fc78 R15: ffff888007405a00 [ 472.096136] FS: 0000000000000000(0000) GS:ffff88806d200000(0000) knlGS:0000000000000000 [ 472.096136] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 472.096136] CR2: 0000000000000158 CR3: 000000000da32000 CR4: 00000000000006f0 [ 472.096136] Call Trace: [ 472.096136] <TASK> [ 472.096136] ? __die_body+0x8d/0xe0 [ 472.096136] ? page_fault_oops+0x6b8/0x9a0 [ 472.096136] ? kernelmode_fixup_or_oops+0x20c/0x2a0 [ 472.096136] ? do_user_addr_fault+0x1027/0x1340 [ 472.096136] ? _printk+0x7a/0xa0 [ 472.096136] ? mutex_lock+0x68/0xc0 [ 472.096136] ? add_taint+0x42/0xd0 [ 472.096136] ? exc_page_fault+0x6a/0x1b0 [ 472.096136] ? asm_exc_page_fault+0x26/0x30 [ 472.096136] ? mutex_lock+0x75/0xc0 [ 472.096136] ? mutex_lock+0x88/0xc0 [ 472.096136] ? mutex_lock+0x75/0xc0 [ 472.096136] l2cap_chan_timeo ---truncated---(CVE-2024-27399)
In the Linux kernel, the following vulnerability has been resolved:
firewire: nosy: ensure user_length is taken into account when fetching packet contents
Ensure that packet_buffer_get respects the user_length provided. If the length of the head packet exceeds the user_length, packet_buffer_get will now return 0 to signify to the user that no data were read and a larger buffer size is required. Helps prevent user space overflows.(CVE-2024-27401)
In the Linux kernel, the following vulnerability has been resolved:
efi/capsule-loader: fix incorrect allocation size
gcc-14 notices that the allocation with sizeof(void) on 32-bit architectures is not enough for a 64-bit phys_addr_t:
drivers/firmware/efi/capsule-loader.c: In function 'efi_capsule_open': drivers/firmware/efi/capsule-loader.c:295:24: error: allocation of insufficient size '4' for type 'phys_addr_t' {aka 'long long unsigned int'} with size '8' [-Werror=alloc-size] 295 | cap_info->phys = kzalloc(sizeof(void *), GFP_KERNEL); | ^
Use the correct type instead here.(CVE-2024-27413)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: bridge: confirm multicast packets before passing them up the stack
conntrack nf_confirm logic cannot handle cloned skbs referencing the same nf_conn entry, which will happen for multicast (broadcast) frames on bridges.
Example: macvlan0 | br0 / \ ethX ethY
ethX (or Y) receives a L2 multicast or broadcast packet containing an IP packet, flow is not yet in conntrack table.
- skb passes through bridge and fake-ip (br_netfilter)Prerouting. -> skb->_nfct now references a unconfirmed entry
- skb is broad/mcast packet. bridge now passes clones out on each bridge interface.
- skb gets passed up the stack.
-
In macvlan case, macvlan driver retains clone(s) of the mcast skb and schedules a work queue to send them out on the lower devices.
The clone skb->_nfct is not a copy, it is the same entry as the original skb. The macvlan rx handler then returns RX_HANDLER_PASS. 5. Normal conntrack hooks (in NF_INET_LOCAL_IN) confirm the orig skb.
The Macvlan broadcast worker and normal confirm path will race.
This race will not happen if step 2 already confirmed a clone. In that case later steps perform skb_clone() with skb->_nfct already confirmed (in hash table). This works fine.
But such confirmation won't happen when eb/ip/nftables rules dropped the packets before they reached the nf_confirm step in postrouting.
Pablo points out that nf_conntrack_bridge doesn't allow use of stateful nat, so we can safely discard the nf_conn entry and let inet call conntrack again.
This doesn't work for bridge netfilter: skb could have a nat transformation. Also bridge nf prevents re-invocation of inet prerouting via 'sabotage_in' hook.
Work around this problem by explicit confirmation of the entry at LOCAL_IN time, before upper layer has a chance to clone the unconfirmed entry.
The downside is that this disables NAT and conntrack helpers.
Alternative fix would be to add locking to all code parts that deal with unconfirmed packets, but even if that could be done in a sane way this opens up other problems, for example:
-m physdev --physdev-out eth0 -j SNAT --snat-to 1.2.3.4 -m physdev --physdev-out eth1 -j SNAT --snat-to 1.2.3.5
For multicast case, only one of such conflicting mappings will be created, conntrack only handles 1:1 NAT mappings.
Users should set create a setup that explicitly marks such traffic NOTRACK (conntrack bypass) to avoid this, but we cannot auto-bypass them, ruleset might have accept rules for untracked traffic already, so user-visible behaviour would change.(CVE-2024-27415)
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: check/clear fast rx for non-4addr sta VLAN changes
When moving a station out of a VLAN and deleting the VLAN afterwards, the fast_rx entry still holds a pointer to the VLAN's netdev, which can cause use-after-free bugs. Fix this by immediately calling ieee80211_check_fast_rx after the VLAN change.(CVE-2024-35789)
In the Linux kernel, the following vulnerability has been resolved:
md/dm-raid: don't call md_reap_sync_thread() directly
Currently md_reap_sync_thread() is called from raid_message() directly without holding 'reconfig_mutex', this is definitely unsafe because md_reap_sync_thread() can change many fields that is protected by 'reconfig_mutex'.
However, hold 'reconfig_mutex' here is still problematic because this will cause deadlock, for example, commit 130443d60b1b ("md: refactor idle/frozen_sync_thread() to fix deadlock").
Fix this problem by using stop_sync_thread() to unregister sync_thread, like md/raid did.(CVE-2024-35808)
In the Linux kernel, the following vulnerability has been resolved:
usb: udc: remove warning when queue disabled ep
It is possible trigger below warning message from mass storage function,
WARNING: CPU: 6 PID: 3839 at drivers/usb/gadget/udc/core.c:294 usb_ep_queue+0x7c/0x104 pc : usb_ep_queue+0x7c/0x104 lr : fsg_main_thread+0x494/0x1b3c
Root cause is mass storage function try to queue request from main thread, but other thread may already disable ep when function disable.
As there is no function failure in the driver, in order to avoid effort to fix warning, change WARN_ON_ONCE() in usb_ep_queue() to pr_debug().(CVE-2024-35822)
In the Linux kernel, the following vulnerability has been resolved:
vt: fix unicode buffer corruption when deleting characters
This is the same issue that was fixed for the VGA text buffer in commit 39cdb68c64d8 ("vt: fix memory overlapping when deleting chars in the buffer"). The cure is also the same i.e. replace memcpy() with memmove() due to the overlaping buffers.(CVE-2024-35823)
In the Linux kernel, the following vulnerability has been resolved:
mptcp: use OPTION_MPTCP_MPJ_SYNACK in subflow_finish_connect()
subflow_finish_connect() uses four fields (backup, join_id, thmac, none) that may contain garbage unless OPTION_MPTCP_MPJ_SYNACK has been set in mptcp_parse_option()(CVE-2024-35840)
In the Linux kernel, the following vulnerability has been resolved:
mlxsw: spectrum_acl_tcam: Fix possible use-after-free during activity update
The rule activity update delayed work periodically traverses the list of configured rules and queries their activity from the device.
As part of this task it accesses the entry pointed by 'ventry->entry', but this entry can be changed concurrently by the rehash delayed work, leading to a use-after-free [1].
Fix by closing the race and perform the activity query under the 'vregion->lock' mutex.
[1] BUG: KASAN: slab-use-after-free in mlxsw_sp_acl_tcam_flower_rule_activity_get+0x121/0x140 Read of size 8 at addr ffff8881054ed808 by task kworker/0:18/181
CPU: 0 PID: 181 Comm: kworker/0:18 Not tainted 6.9.0-rc2-custom-00781-gd5ab772d32f7 #2 Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019 Workqueue: mlxsw_core mlxsw_sp_acl_rule_activity_update_work Call Trace: <TASK> dump_stack_lvl+0xc6/0x120 print_report+0xce/0x670 kasan_report+0xd7/0x110 mlxsw_sp_acl_tcam_flower_rule_activity_get+0x121/0x140 mlxsw_sp_acl_rule_activity_update_work+0x219/0x400 process_one_work+0x8eb/0x19b0 worker_thread+0x6c9/0xf70 kthread+0x2c9/0x3b0 ret_from_fork+0x4d/0x80 ret_from_fork_asm+0x1a/0x30 </TASK>
Allocated by task 1039: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0 __kmalloc+0x19c/0x360 mlxsw_sp_acl_tcam_entry_create+0x7b/0x1f0 mlxsw_sp_acl_tcam_vchunk_migrate_all+0x30d/0xb50 mlxsw_sp_acl_tcam_vregion_rehash_work+0x157/0x1300 process_one_work+0x8eb/0x19b0 worker_thread+0x6c9/0xf70 kthread+0x2c9/0x3b0 ret_from_fork+0x4d/0x80 ret_from_fork_asm+0x1a/0x30
Freed by task 1039: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 poison_slab_object+0x102/0x170 __kasan_slab_free+0x14/0x30 kfree+0xc1/0x290 mlxsw_sp_acl_tcam_vchunk_migrate_all+0x3d7/0xb50 mlxsw_sp_acl_tcam_vregion_rehash_work+0x157/0x1300 process_one_work+0x8eb/0x19b0 worker_thread+0x6c9/0xf70 kthread+0x2c9/0x3b0 ret_from_fork+0x4d/0x80 ret_from_fork_asm+0x1a/0x30(CVE-2024-35855)
In the Linux kernel, the following vulnerability has been resolved:
x86/mm/pat: fix VM_PAT handling in COW mappings
PAT handling won't do the right thing in COW mappings: the first PTE (or, in fact, all PTEs) can be replaced during write faults to point at anon folios. Reliably recovering the correct PFN and cachemode using follow_phys() from PTEs will not work in COW mappings.
Using follow_phys(), we might just get the address+protection of the anon folio (which is very wrong), or fail on swap/nonswap entries, failing follow_phys() and triggering a WARN_ON_ONCE() in untrack_pfn() and track_pfn_copy(), not properly calling free_pfn_range().
In free_pfn_range(), we either wouldn't call memtype_free() or would call it with the wrong range, possibly leaking memory.
To fix that, let's update follow_phys() to refuse returning anon folios, and fallback to using the stored PFN inside vma->vm_pgoff for COW mappings if we run into that.
We will now properly handle untrack_pfn() with COW mappings, where we don't need the cachemode. We'll have to fail fork()->track_pfn_copy() if the first page was replaced by an anon folio, though: we'd have to store the cachemode in the VMA to make this work, likely growing the VMA size.
For now, lets keep it simple and let track_pfn_copy() just fail in that case: it would have failed in the past with swap/nonswap entries already, and it would have done the wrong thing with anon folios.
Simple reproducer to trigger the WARN_ON_ONCE() in untrack_pfn():
<--- C reproducer ---> #include <stdio.h> #include <sys/mman.h> #include <unistd.h> #include <liburing.h>
int main(void) { struct io_uring_params p = {}; int ring_fd; size_t size; char *map;
ring_fd = io_uring_setup(1, &p);
if (ring_fd < 0) {
perror("io_uring_setup");
return 1;
}
size = p.sq_off.array + p.sq_entries * sizeof(unsigned);
/* Map the submission queue ring MAP_PRIVATE */
map = mmap(0, size, PROT_READ | PROT_WRITE, MAP_PRIVATE,
ring_fd, IORING_OFF_SQ_RING);
if (map == MAP_FAILED) {
perror("mmap");
return 1;
}
/* We have at least one page. Let's COW it. */
*map = 0;
pause();
return 0;
} <--- C reproducer --->
On a system with 16 GiB RAM and swap configured: # ./iouring & # memhog 16G # killall iouring [ 301.552930] ------------[ cut here ]------------ [ 301.553285] WARNING: CPU: 7 PID: 1402 at arch/x86/mm/pat/memtype.c:1060 untrack_pfn+0xf4/0x100 [ 301.553989] Modules linked in: binfmt_misc nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_g [ 301.558232] CPU: 7 PID: 1402 Comm: iouring Not tainted 6.7.5-100.fc38.x86_64 #1 [ 301.558772] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebu4 [ 301.559569] RIP: 0010:untrack_pfn+0xf4/0x100 [ 301.559893] Code: 75 c4 eb cf 48 8b 43 10 8b a8 e8 00 00 00 3b 6b 28 74 b8 48 8b 7b 30 e8 ea 1a f7 000 [ 301.561189] RSP: 0018:ffffba2c0377fab8 EFLAGS: 00010282 [ 301.561590] RAX: 00000000ffffffea RBX: ffff9208c8ce9cc0 RCX: 000000010455e047 [ 301.562105] RDX: 07fffffff0eb1e0a RSI: 0000000000000000 RDI: ffff9208c391d200 [ 301.562628] RBP: 0000000000000000 R08: ffffba2c0377fab8 R09: 0000000000000000 [ 301.563145] R10: ffff9208d2292d50 R11: 0000000000000002 R12: 00007fea890e0000 [ 301.563669] R13: 0000000000000000 R14: ffffba2c0377fc08 R15: 0000000000000000 [ 301.564186] FS: 0000000000000000(0000) GS:ffff920c2fbc0000(0000) knlGS:0000000000000000 [ 301.564773] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 301.565197] CR2: 00007fea88ee8a20 CR3: 00000001033a8000 CR4: 0000000000750ef0 [ 301.565725] PKRU: 55555554 [ 301.565944] Call Trace: [ 301.566148] <TASK> [ 301.566325] ? untrack_pfn+0xf4/0x100 [ 301.566618] ? __warn+0x81/0x130 [ 301.566876] ? untrack_pfn+0xf4/0x100 [ 3 ---truncated---(CVE-2024-35877)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: reject new basechain after table flag update
When dormant flag is toggled, hooks are disabled in the commit phase by iterating over current chains in table (existing and new).
The following configuration allows for an inconsistent state:
add table x add chain x y { type filter hook input priority 0; } add table x { flags dormant; } add chain x w { type filter hook input priority 1; }
which triggers the following warning when trying to unregister chain w which is already unregistered.
[ 127.322252] WARNING: CPU: 7 PID: 1211 at net/netfilter/core.c:50 1 __nf_unregister_net_hook+0x21a/0x260 [...] [ 127.322519] Call Trace: [ 127.322521] <TASK> [ 127.322524] ? __warn+0x9f/0x1a0 [ 127.322531] ? __nf_unregister_net_hook+0x21a/0x260 [ 127.322537] ? report_bug+0x1b1/0x1e0 [ 127.322545] ? handle_bug+0x3c/0x70 [ 127.322552] ? exc_invalid_op+0x17/0x40 [ 127.322556] ? asm_exc_invalid_op+0x1a/0x20 [ 127.322563] ? kasan_save_free_info+0x3b/0x60 [ 127.322570] ? __nf_unregister_net_hook+0x6a/0x260 [ 127.322577] ? __nf_unregister_net_hook+0x21a/0x260 [ 127.322583] ? __nf_unregister_net_hook+0x6a/0x260 [ 127.322590] ? __nf_tables_unregister_hook+0x8a/0xe0 [nf_tables] [ 127.322655] nft_table_disable+0x75/0xf0 [nf_tables] [ 127.322717] nf_tables_commit+0x2571/0x2620 nf_tables
In the Linux kernel, the following vulnerability has been resolved:
selinux: avoid dereference of garbage after mount failure
In case kern_mount() fails and returns an error pointer return in the error branch instead of continuing and dereferencing the error pointer.
While on it drop the never read static variable selinuxfs_mount.(CVE-2024-35904)
In the Linux kernel, the following vulnerability has been resolved:
block: prevent division by zero in blk_rq_stat_sum()
The expression dst->nr_samples + src->nr_samples may have zero value on overflow. It is necessary to add a check to avoid division by zero.
Found by Linux Verification Center (linuxtesting.org) with Svace.(CVE-2024-35925)
In the Linux kernel, the following vulnerability has been resolved:
dma-direct: Leak pages on dma_set_decrypted() failure
On TDX it is possible for the untrusted host to cause set_memory_encrypted() or set_memory_decrypted() to fail such that an error is returned and the resulting memory is shared. Callers need to take care to handle these errors to avoid returning decrypted (shared) memory to the page allocator, which could lead to functional or security issues.
DMA could free decrypted/shared pages if dma_set_decrypted() fails. This should be a rare case. Just leak the pages in this case instead of freeing them.(CVE-2024-35939)
In the Linux kernel, the following vulnerability has been resolved:
drm/client: Fully protect modes[] with dev->mode_config.mutex
The modes[] array contains pointers to modes on the connectors' mode lists, which are protected by dev->mode_config.mutex. Thus we need to extend modes[] the same protection or by the time we use it the elements may already be pointing to freed/reused memory.(CVE-2024-35950)
In the Linux kernel, the following vulnerability has been resolved:
btrfs: qgroup: fix qgroup prealloc rsv leak in subvolume operations
Create subvolume, create snapshot and delete subvolume all use btrfs_subvolume_reserve_metadata() to reserve metadata for the changes done to the parent subvolume's fs tree, which cannot be mediated in the normal way via start_transaction. When quota groups (squota or qgroups) are enabled, this reserves qgroup metadata of type PREALLOC. Once the operation is associated to a transaction, we convert PREALLOC to PERTRANS, which gets cleared in bulk at the end of the transaction.
However, the error paths of these three operations were not implementing this lifecycle correctly. They unconditionally converted the PREALLOC to PERTRANS in a generic cleanup step regardless of errors or whether the operation was fully associated to a transaction or not. This resulted in error paths occasionally converting this rsv to PERTRANS without calling record_root_in_trans successfully, which meant that unless that root got recorded in the transaction by some other thread, the end of the transaction would not free that root's PERTRANS, leaking it. Ultimately, this resulted in hitting a WARN in CONFIG_BTRFS_DEBUG builds at unmount for the leaked reservation.
The fix is to ensure that every qgroup PREALLOC reservation observes the following properties:
- any failure before record_root_in_trans is called successfully results in freeing the PREALLOC reservation.
- after record_root_in_trans, we convert to PERTRANS, and now the transaction owns freeing the reservation.
This patch enforces those properties on the three operations. Without it, generic/269 with squotas enabled at mkfs time would fail in ~5-10 runs on my system. With this patch, it ran successfully 1000 times in a row.(CVE-2024-35956)
In the Linux kernel, the following vulnerability has been resolved:
net: ena: Fix incorrect descriptor free behavior
ENA has two types of TX queues: - queues which only process TX packets arriving from the network stack - queues which only process TX packets forwarded to it by XDP_REDIRECT or XDP_TX instructions
The ena_free_tx_bufs() cycles through all descriptors in a TX queue and unmaps + frees every descriptor that hasn't been acknowledged yet by the device (uncompleted TX transactions). The function assumes that the processed TX queue is necessarily from the first category listed above and ends up using napi_consume_skb() for descriptors belonging to an XDP specific queue.
This patch solves a bug in which, in case of a VF reset, the descriptors aren't freed correctly, leading to crashes.(CVE-2024-35958)
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: Properly link new fs rules into the tree
Previously, add_rule_fg would only add newly created rules from the handle into the tree when they had a refcount of 1. On the other hand, create_flow_handle tries hard to find and reference already existing identical rules instead of creating new ones.
These two behaviors can result in a situation where create_flow_handle 1) creates a new rule and references it, then 2) in a subsequent step during the same handle creation references it again, resulting in a rule with a refcount of 2 that is not linked into the tree, will have a NULL parent and root and will result in a crash when the flow group is deleted because del_sw_hw_rule, invoked on rule deletion, assumes node->parent is != NULL.
This happened in the wild, due to another bug related to incorrect handling of duplicate pkt_reformat ids, which lead to the code in create_flow_handle incorrectly referencing a just-added rule in the same flow handle, resulting in the problem described above. Full details are at [1].
This patch changes add_rule_fg to add new rules without parents into the tree, properly initializing them and avoiding the crash. This makes it more consistent with how rules are added to an FTE in create_flow_handle.(CVE-2024-35960)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: Fix memory leak in hci_req_sync_complete()
In 'hci_req_sync_complete()', always free the previous sync request state before assigning reference to a new one.(CVE-2024-35978)
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: idxd: Fix oops during rmmod on single-CPU platforms
During the removal of the idxd driver, registered offline callback is invoked as part of the clean up process. However, on systems with only one CPU online, no valid target is available to migrate the perf context, resulting in a kernel oops:
BUG: unable to handle page fault for address: 000000000002a2b8
#PF: supervisor write access in kernel mode
#PF: error_code(0x0002) - not-present page
PGD 1470e1067 P4D 0
Oops: 0002 [#1] PREEMPT SMP NOPTI
CPU: 0 PID: 20 Comm: cpuhp/0 Not tainted 6.8.0-rc6-dsa+ #57
Hardware name: Intel Corporation AvenueCity/AvenueCity, BIOS BHSDCRB1.86B.2492.D03.2307181620 07/18/2023
RIP: 0010:mutex_lock+0x2e/0x50
...
Call Trace:
<TASK>
__die+0x24/0x70
page_fault_oops+0x82/0x160
do_user_addr_fault+0x65/0x6b0
__pfx___rdmsr_safe_on_cpu+0x10/0x10
exc_page_fault+0x7d/0x170
asm_exc_page_fault+0x26/0x30
mutex_lock+0x2e/0x50
mutex_lock+0x1e/0x50
perf_pmu_migrate_context+0x87/0x1f0
perf_event_cpu_offline+0x76/0x90 [idxd]
cpuhp_invoke_callback+0xa2/0x4f0
__pfx_perf_event_cpu_offline+0x10/0x10 [idxd]
cpuhp_thread_fun+0x98/0x150
smpboot_thread_fn+0x27/0x260
smpboot_thread_fn+0x1af/0x260
__pfx_smpboot_thread_fn+0x10/0x10
kthread+0x103/0x140
__pfx_kthread+0x10/0x10
ret_from_fork+0x31/0x50
__pfx_kthread+0x10/0x10
ret_from_fork_asm+0x1b/0x30
<TASK>
Fix the issue by preventing the migration of the perf context to an invalid target.(CVE-2024-35989)
In the Linux kernel, the following vulnerability has been resolved:
mm/hugetlb: fix missing hugetlb_lock for resv uncharge
There is a recent report on UFFDIO_COPY over hugetlb:
https://lore.kernel.org/all/000000000000ee06de0616177560@google.com/
350: lockdep_assert_held(&hugetlb_lock);
Should be an issue in hugetlb but triggered in an userfault context, where it goes into the unlikely path where two threads modifying the resv map together. Mike has a fix in that path for resv uncharge but it looks like the locking criteria was overlooked: hugetlb_cgroup_uncharge_folio_rsvd() will update the cgroup pointer, so it requires to be called with the lock held.(CVE-2024-36000)
In the Linux kernel, the following vulnerability has been resolved:
i40e: Do not use WQ_MEM_RECLAIM flag for workqueue
Issue reported by customer during SRIOV testing, call trace: When both i40e and the i40iw driver are loaded, a warning in check_flush_dependency is being triggered. This seems to be because of the i40e driver workqueue is allocated with the WQ_MEM_RECLAIM flag, and the i40iw one is not.
Similar error was encountered on ice too and it was fixed by removing the flag. Do the same for i40e too.
[Feb 9 09:08] ------------[ cut here ]------------ [ +0.000004] workqueue: WQ_MEM_RECLAIM i40e:i40e_service_task [i40e] is flushing !WQ_MEM_RECLAIM infiniband:0x0 [ +0.000060] WARNING: CPU: 0 PID: 937 at kernel/workqueue.c:2966 check_flush_dependency+0x10b/0x120 [ +0.000007] Modules linked in: snd_seq_dummy snd_hrtimer snd_seq snd_timer snd_seq_device snd soundcore nls_utf8 cifs cifs_arc4 nls_ucs2_utils rdma_cm iw_cm ib_cm cifs_md4 dns_resolver netfs qrtr rfkill sunrpc vfat fat intel_rapl_msr intel_rapl_common irdma intel_uncore_frequency intel_uncore_frequency_common ice ipmi_ssif isst_if_common skx_edac nfit libnvdimm x86_pkg_temp_thermal intel_powerclamp gnss coretemp ib_uverbs rapl intel_cstate ib_core iTCO_wdt iTCO_vendor_support acpi_ipmi mei_me ipmi_si intel_uncore ioatdma i2c_i801 joydev pcspkr mei ipmi_devintf lpc_ich intel_pch_thermal i2c_smbus ipmi_msghandler acpi_power_meter acpi_pad xfs libcrc32c ast sd_mod drm_shmem_helper t10_pi drm_kms_helper sg ixgbe drm i40e ahci crct10dif_pclmul libahci crc32_pclmul igb crc32c_intel libata ghash_clmulni_intel i2c_algo_bit mdio dca wmi dm_mirror dm_region_hash dm_log dm_mod fuse [ +0.000050] CPU: 0 PID: 937 Comm: kworker/0:3 Kdump: loaded Not tainted 6.8.0-rc2-Feb-net_dev-Qiueue-00279-gbd43c5687e05 #1 [ +0.000003] Hardware name: Intel Corporation S2600BPB/S2600BPB, BIOS SE5C620.86B.02.01.0013.121520200651 12/15/2020 [ +0.000001] Workqueue: i40e i40e_service_task [i40e] [ +0.000024] RIP: 0010:check_flush_dependency+0x10b/0x120 [ +0.000003] Code: ff 49 8b 54 24 18 48 8d 8b b0 00 00 00 49 89 e8 48 81 c6 b0 00 00 00 48 c7 c7 b0 97 fa 9f c6 05 8a cc 1f 02 01 e8 35 b3 fd ff <0f> 0b e9 10 ff ff ff 80 3d 78 cc 1f 02 00 75 94 e9 46 ff ff ff 90 [ +0.000002] RSP: 0018:ffffbd294976bcf8 EFLAGS: 00010282 [ +0.000002] RAX: 0000000000000000 RBX: ffff94d4c483c000 RCX: 0000000000000027 [ +0.000001] RDX: ffff94d47f620bc8 RSI: 0000000000000001 RDI: ffff94d47f620bc0 [ +0.000001] RBP: 0000000000000000 R08: 0000000000000000 R09: 00000000ffff7fff [ +0.000001] R10: ffffbd294976bb98 R11: ffffffffa0be65e8 R12: ffff94c5451ea180 [ +0.000001] R13: ffff94c5ab5e8000 R14: ffff94c5c20b6e05 R15: ffff94c5f1330ab0 [ +0.000001] FS: 0000000000000000(0000) GS:ffff94d47f600000(0000) knlGS:0000000000000000 [ +0.000002] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ +0.000001] CR2: 00007f9e6f1fca70 CR3: 0000000038e20004 CR4: 00000000007706f0 [ +0.000000] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ +0.000001] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ +0.000001] PKRU: 55555554 [ +0.000001] Call Trace: [ +0.000001] <TASK> [ +0.000002] ? __warn+0x80/0x130 [ +0.000003] ? check_flush_dependency+0x10b/0x120 [ +0.000002] ? report_bug+0x195/0x1a0 [ +0.000005] ? handle_bug+0x3c/0x70 [ +0.000003] ? exc_invalid_op+0x14/0x70 [ +0.000002] ? asm_exc_invalid_op+0x16/0x20 [ +0.000006] ? check_flush_dependency+0x10b/0x120 [ +0.000002] ? check_flush_dependency+0x10b/0x120 [ +0.000002] __flush_workqueue+0x126/0x3f0 [ +0.000015] ib_cache_cleanup_one+0x1c/0xe0 [ib_core] [ +0.000056] __ib_unregister_device+0x6a/0xb0 [ib_core] [ +0.000023] ib_unregister_device_and_put+0x34/0x50 [ib_core] [ +0.000020] i40iw_close+0x4b/0x90 [irdma] [ +0.000022] i40e_notify_client_of_netdev_close+0x54/0xc0 [i40e] [ +0.000035] i40e_service_task+0x126/0x190 [i40e] [ +0.000024] process_one_work+0x174/0x340 [ +0.000003] worker_th ---truncated---(CVE-2024-36004)
In the Linux kernel, the following vulnerability has been resolved:
mlxsw: spectrum_acl_tcam: Fix warning during rehash
As previously explained, the rehash delayed work migrates filters from one region to another. This is done by iterating over all chunks (all the filters with the same priority) in the region and in each chunk iterating over all the filters.
When the work runs out of credits it stores the current chunk and entry as markers in the per-work context so that it would know where to resume the migration from the next time the work is scheduled.
Upon error, the chunk marker is reset to NULL, but without resetting the entry markers despite being relative to it. This can result in migration being resumed from an entry that does not belong to the chunk being migrated. In turn, this will eventually lead to a chunk being iterated over as if it is an entry. Because of how the two structures happen to be defined, this does not lead to KASAN splats, but to warnings such as [1].
Fix by creating a helper that resets all the markers and call it from all the places the currently only reset the chunk marker. For good measures also call it when starting a completely new rehash. Add a warning to avoid future cases.
[1] WARNING: CPU: 7 PID: 1076 at drivers/net/ethernet/mellanox/mlxsw/core_acl_flex_keys.c:407 mlxsw_afk_encode+0x242/0x2f0 Modules linked in: CPU: 7 PID: 1076 Comm: kworker/7:24 Tainted: G W 6.9.0-rc3-custom-00880-g29e61d91b77b #29 Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019 Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work RIP: 0010:mlxsw_afk_encode+0x242/0x2f0 [...] Call Trace: <TASK> mlxsw_sp_acl_atcam_entry_add+0xd9/0x3c0 mlxsw_sp_acl_tcam_entry_create+0x5e/0xa0 mlxsw_sp_acl_tcam_vchunk_migrate_all+0x109/0x290 mlxsw_sp_acl_tcam_vregion_rehash_work+0x6c/0x470 process_one_work+0x151/0x370 worker_thread+0x2cb/0x3e0 kthread+0xd0/0x100 ret_from_fork+0x34/0x50 </TASK>(CVE-2024-36007)
In the Linux kernel, the following vulnerability has been resolved:
ppdev: Add an error check in register_device
In register_device, the return value of ida_simple_get is unchecked, in witch ida_simple_get will use an invalid index value.
To address this issue, index should be checked after ida_simple_get. When the index value is abnormal, a warning message should be printed, the port should be dropped, and the value should be recorded.(CVE-2024-36015)
In the Linux kernel, the following vulnerability has been resolved:
pinctrl: core: delete incorrect free in pinctrl_enable()
The "pctldev" struct is allocated in devm_pinctrl_register_and_init(). It's a devm_ managed pointer that is freed by devm_pinctrl_dev_release(), so freeing it in pinctrl_enable() will lead to a double free.
The devm_pinctrl_dev_release() function frees the pindescs and destroys the mutex as well.(CVE-2024-36940)
| URL | Type | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"perf-5.10.0-202.0.0.115.oe2203sp3.aarch64.rpm",
"kernel-devel-5.10.0-202.0.0.115.oe2203sp3.aarch64.rpm",
"perf-debuginfo-5.10.0-202.0.0.115.oe2203sp3.aarch64.rpm",
"kernel-tools-5.10.0-202.0.0.115.oe2203sp3.aarch64.rpm",
"kernel-headers-5.10.0-202.0.0.115.oe2203sp3.aarch64.rpm",
"kernel-source-5.10.0-202.0.0.115.oe2203sp3.aarch64.rpm",
"kernel-debuginfo-5.10.0-202.0.0.115.oe2203sp3.aarch64.rpm",
"kernel-debugsource-5.10.0-202.0.0.115.oe2203sp3.aarch64.rpm",
"python3-perf-5.10.0-202.0.0.115.oe2203sp3.aarch64.rpm",
"kernel-tools-debuginfo-5.10.0-202.0.0.115.oe2203sp3.aarch64.rpm",
"kernel-5.10.0-202.0.0.115.oe2203sp3.aarch64.rpm",
"kernel-tools-devel-5.10.0-202.0.0.115.oe2203sp3.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-202.0.0.115.oe2203sp3.aarch64.rpm"
],
"src": [
"kernel-5.10.0-202.0.0.115.oe2203sp3.src.rpm"
],
"x86_64": [
"kernel-headers-5.10.0-202.0.0.115.oe2203sp3.x86_64.rpm",
"perf-debuginfo-5.10.0-202.0.0.115.oe2203sp3.x86_64.rpm",
"perf-5.10.0-202.0.0.115.oe2203sp3.x86_64.rpm",
"kernel-tools-debuginfo-5.10.0-202.0.0.115.oe2203sp3.x86_64.rpm",
"python3-perf-5.10.0-202.0.0.115.oe2203sp3.x86_64.rpm",
"kernel-devel-5.10.0-202.0.0.115.oe2203sp3.x86_64.rpm",
"kernel-tools-devel-5.10.0-202.0.0.115.oe2203sp3.x86_64.rpm",
"python3-perf-debuginfo-5.10.0-202.0.0.115.oe2203sp3.x86_64.rpm",
"kernel-debugsource-5.10.0-202.0.0.115.oe2203sp3.x86_64.rpm",
"kernel-source-5.10.0-202.0.0.115.oe2203sp3.x86_64.rpm",
"kernel-tools-5.10.0-202.0.0.115.oe2203sp3.x86_64.rpm",
"kernel-5.10.0-202.0.0.115.oe2203sp3.x86_64.rpm",
"kernel-debuginfo-5.10.0-202.0.0.115.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-202.0.0.115.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\nRDMA: Verify port when creating flow rule\r\n\r\nValidate port value provided by the user and with that remove no longer\nneeded validation by the driver. The missing check in the mlx5_ib driver\ncould cause to the below oops.\r\n\r\nCall trace:\n _create_flow_rule+0x2d4/0xf28 [mlx5_ib]\n mlx5_ib_create_flow+0x2d0/0x5b0 [mlx5_ib]\n ib_uverbs_ex_create_flow+0x4cc/0x624 [ib_uverbs]\n ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0xd4/0x150 [ib_uverbs]\n ib_uverbs_cmd_verbs.isra.7+0xb28/0xc50 [ib_uverbs]\n ib_uverbs_ioctl+0x158/0x1d0 [ib_uverbs]\n do_vfs_ioctl+0xd0/0xaf0\n ksys_ioctl+0x84/0xb4\n __arm64_sys_ioctl+0x28/0xc4\n el0_svc_common.constprop.3+0xa4/0x254\n el0_svc_handler+0x84/0xa0\n el0_svc+0x10/0x26c\n Code: b9401260 f9615681 51000400 8b001c20 (f9403c1a)(CVE-2021-47265)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmISDN: fix possible use-after-free in HFC_cleanup()\r\n\r\nThis module\u0026apos;s remove path calls del_timer(). However, that function\ndoes not wait until the timer handler finishes. This means that the\ntimer handler may still be running after the driver\u0026apos;s remove function\nhas finished, which would result in a use-after-free.\r\n\r\nFix by calling del_timer_sync(), which makes sure the timer handler\nhas finished, and unable to re-schedule itself.(CVE-2021-47356)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmptcp: ensure tx skbs always have the MPTCP ext\r\n\r\nDue to signed/unsigned comparison, the expression:\r\n\r\n\tinfo-\u0026gt;size_goal - skb-\u0026gt;len \u0026gt; 0\r\n\r\nevaluates to true when the size goal is smaller than the\nskb size. That results in lack of tx cache refill, so that\nthe skb allocated by the core TCP code lacks the required\nMPTCP skb extensions.\r\n\r\nDue to the above, syzbot is able to trigger the following WARN_ON():\r\n\r\nWARNING: CPU: 1 PID: 810 at net/mptcp/protocol.c:1366 mptcp_sendmsg_frag+0x1362/0x1bc0 net/mptcp/protocol.c:1366\nModules linked in:\nCPU: 1 PID: 810 Comm: syz-executor.4 Not tainted 5.14.0-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011\nRIP: 0010:mptcp_sendmsg_frag+0x1362/0x1bc0 net/mptcp/protocol.c:1366\nCode: ff 4c 8b 74 24 50 48 8b 5c 24 58 e9 0f fb ff ff e8 13 44 8b f8 4c 89 e7 45 31 ed e8 98 57 2e fe e9 81 f4 ff ff e8 fe 43 8b f8 \u0026lt;0f\u0026gt; 0b 41 bd ea ff ff ff e9 6f f4 ff ff 4c 89 e7 e8 b9 8e d2 f8 e9\nRSP: 0018:ffffc9000531f6a0 EFLAGS: 00010216\nRAX: 000000000000697f RBX: 0000000000000000 RCX: ffffc90012107000\nRDX: 0000000000040000 RSI: ffffffff88eac9e2 RDI: 0000000000000003\nRBP: ffff888078b15780 R08: 0000000000000000 R09: 0000000000000000\nR10: ffffffff88eac017 R11: 0000000000000000 R12: ffff88801de0a280\nR13: 0000000000006b58 R14: ffff888066278280 R15: ffff88803c2fe9c0\nFS: 00007fd9f866e700(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007faebcb2f718 CR3: 00000000267cb000 CR4: 00000000001506e0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n __mptcp_push_pending+0x1fb/0x6b0 net/mptcp/protocol.c:1547\n mptcp_release_cb+0xfe/0x210 net/mptcp/protocol.c:3003\n release_sock+0xb4/0x1b0 net/core/sock.c:3206\n sk_stream_wait_memory+0x604/0xed0 net/core/stream.c:145\n mptcp_sendmsg+0xc39/0x1bc0 net/mptcp/protocol.c:1749\n inet6_sendmsg+0x99/0xe0 net/ipv6/af_inet6.c:643\n sock_sendmsg_nosec net/socket.c:704 [inline]\n sock_sendmsg+0xcf/0x120 net/socket.c:724\n sock_write_iter+0x2a0/0x3e0 net/socket.c:1057\n call_write_iter include/linux/fs.h:2163 [inline]\n new_sync_write+0x40b/0x640 fs/read_write.c:507\n vfs_write+0x7cf/0xae0 fs/read_write.c:594\n ksys_write+0x1ee/0x250 fs/read_write.c:647\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x44/0xae\nRIP: 0033:0x4665f9\nCode: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007fd9f866e188 EFLAGS: 00000246 ORIG_RAX: 0000000000000001\nRAX: ffffffffffffffda RBX: 000000000056c038 RCX: 00000000004665f9\nRDX: 00000000000e7b78 RSI: 0000000020000000 RDI: 0000000000000003\nRBP: 00000000004bfcc4 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000246 R12: 000000000056c038\nR13: 0000000000a9fb1f R14: 00007fd9f866e300 R15: 0000000000022000\r\n\r\nFix the issue rewriting the relevant expression to avoid\nsign-related problems - note: size_goal is always \u0026gt;= 0.\r\n\r\nAdditionally, ensure that the skb in the tx cache always carries\nthe relevant extension.(CVE-2021-47370)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: iscsi: Fix iscsi_task use after free\r\n\r\nCommit d39df158518c (\u0026quot;scsi: iscsi: Have abort handler get ref to conn\u0026quot;)\nadded iscsi_get_conn()/iscsi_put_conn() calls during abort handling but\nthen also changed the handling of the case where we detect an already\ncompleted task where we now end up doing a goto to the common put/cleanup\ncode. This results in a iscsi_task use after free, because the common\ncleanup code will do a put on the iscsi_task.\r\n\r\nThis reverts the goto and moves the iscsi_get_conn() to after we\u0026apos;ve checked\nif the iscsi_task is valid.(CVE-2021-47427)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: Fix even more out of bound writes from debugfs\r\n\r\nCVE-2021-42327 was fixed by:\r\n\r\ncommit f23750b5b3d98653b31d4469592935ef6364ad67\nAuthor: Thelford Williams \u0026lt;tdwilliamsiv@gmail.com\u0026gt;\nDate: Wed Oct 13 16:04:13 2021 -0400\r\n\r\n drm/amdgpu: fix out of bounds write\r\n\r\nbut amdgpu_dm_debugfs.c contains more of the same issue so fix the\nremaining ones.\r\n\r\nv2:\n\t* Add missing fix in dp_max_bpc_write (Harry Wentland)(CVE-2021-47489)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntcp: TX zerocopy should not sense pfmemalloc status\r\n\r\nWe got a recent syzbot report [1] showing a possible misuse\nof pfmemalloc page status in TCP zerocopy paths.\r\n\r\nIndeed, for pages coming from user space or other layers,\nusing page_is_pfmemalloc() is moot, and possibly could give\nfalse positives.\r\n\r\nThere has been attempts to make page_is_pfmemalloc() more robust,\nbut not using it in the first place in this context is probably better,\nremoving cpu cycles.\r\n\r\nNote to stable teams :\r\n\r\nYou need to backport 84ce071e38a6 (\u0026quot;net: introduce\n__skb_fill_page_desc_noacc\u0026quot;) as a prereq.\r\n\r\nRace is more probable after commit c07aea3ef4d4\n(\u0026quot;mm: add a signature in struct page\u0026quot;) because page_is_pfmemalloc()\nis now using low order bit from page-\u0026gt;lru.next, which can change\nmore often than page-\u0026gt;index.\r\n\r\nLow order bit should never be set for lru.next (when used as an anchor\nin LRU list), so KCSAN report is mostly a false positive.\r\n\r\nBackporting to older kernel versions seems not necessary.\r\n\r\n[1]\nBUG: KCSAN: data-race in lru_add_fn / tcp_build_frag\r\n\r\nwrite to 0xffffea0004a1d2c8 of 8 bytes by task 18600 on cpu 0:\n__list_add include/linux/list.h:73 [inline]\nlist_add include/linux/list.h:88 [inline]\nlruvec_add_folio include/linux/mm_inline.h:105 [inline]\nlru_add_fn+0x440/0x520 mm/swap.c:228\nfolio_batch_move_lru+0x1e1/0x2a0 mm/swap.c:246\nfolio_batch_add_and_move mm/swap.c:263 [inline]\nfolio_add_lru+0xf1/0x140 mm/swap.c:490\nfilemap_add_folio+0xf8/0x150 mm/filemap.c:948\n__filemap_get_folio+0x510/0x6d0 mm/filemap.c:1981\npagecache_get_page+0x26/0x190 mm/folio-compat.c:104\ngrab_cache_page_write_begin+0x2a/0x30 mm/folio-compat.c:116\next4_da_write_begin+0x2dd/0x5f0 fs/ext4/inode.c:2988\ngeneric_perform_write+0x1d4/0x3f0 mm/filemap.c:3738\next4_buffered_write_iter+0x235/0x3e0 fs/ext4/file.c:270\next4_file_write_iter+0x2e3/0x1210\ncall_write_iter include/linux/fs.h:2187 [inline]\nnew_sync_write fs/read_write.c:491 [inline]\nvfs_write+0x468/0x760 fs/read_write.c:578\nksys_write+0xe8/0x1a0 fs/read_write.c:631\n__do_sys_write fs/read_write.c:643 [inline]\n__se_sys_write fs/read_write.c:640 [inline]\n__x64_sys_write+0x3e/0x50 fs/read_write.c:640\ndo_syscall_x64 arch/x86/entry/common.c:50 [inline]\ndo_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80\nentry_SYSCALL_64_after_hwframe+0x63/0xcd\r\n\r\nread to 0xffffea0004a1d2c8 of 8 bytes by task 18611 on cpu 1:\npage_is_pfmemalloc include/linux/mm.h:1740 [inline]\n__skb_fill_page_desc include/linux/skbuff.h:2422 [inline]\nskb_fill_page_desc include/linux/skbuff.h:2443 [inline]\ntcp_build_frag+0x613/0xb20 net/ipv4/tcp.c:1018\ndo_tcp_sendpages+0x3e8/0xaf0 net/ipv4/tcp.c:1075\ntcp_sendpage_locked net/ipv4/tcp.c:1140 [inline]\ntcp_sendpage+0x89/0xb0 net/ipv4/tcp.c:1150\ninet_sendpage+0x7f/0xc0 net/ipv4/af_inet.c:833\nkernel_sendpage+0x184/0x300 net/socket.c:3561\nsock_sendpage+0x5a/0x70 net/socket.c:1054\npipe_to_sendpage+0x128/0x160 fs/splice.c:361\nsplice_from_pipe_feed fs/splice.c:415 [inline]\n__splice_from_pipe+0x222/0x4d0 fs/splice.c:559\nsplice_from_pipe fs/splice.c:594 [inline]\ngeneric_splice_sendpage+0x89/0xc0 fs/splice.c:743\ndo_splice_from fs/splice.c:764 [inline]\ndirect_splice_actor+0x80/0xa0 fs/splice.c:931\nsplice_direct_to_actor+0x305/0x620 fs/splice.c:886\ndo_splice_direct+0xfb/0x180 fs/splice.c:974\ndo_sendfile+0x3bf/0x910 fs/read_write.c:1249\n__do_sys_sendfile64 fs/read_write.c:1317 [inline]\n__se_sys_sendfile64 fs/read_write.c:1303 [inline]\n__x64_sys_sendfile64+0x10c/0x150 fs/read_write.c:1303\ndo_syscall_x64 arch/x86/entry/common.c:50 [inline]\ndo_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80\nentry_SYSCALL_64_after_hwframe+0x63/0xcd\r\n\r\nvalue changed: 0x0000000000000000 -\u0026gt; 0xffffea0004a1d288\r\n\r\nReported by Kernel Concurrency Sanitizer on:\nCPU: 1 PID: 18611 Comm: syz-executor.4 Not tainted 6.0.0-rc2-syzkaller-00248-ge022620b5d05-dirty #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/22/2022(CVE-2022-48689)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nio_uring/af_unix: disable sending io_uring over sockets\r\n\r\nFile reference cycles have caused lots of problems for io_uring\nin the past, and it still doesn\u0026apos;t work exactly right and races with\nunix_stream_read_generic(). The safest fix would be to completely\ndisallow sending io_uring files via sockets via SCM_RIGHT, so there\nare no possible cycles invloving registered files and thus rendering\nSCM accounting on the io_uring side unnecessary.(CVE-2023-52654)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncrypto: s390/aes - Fix buffer overread in CTR mode\r\n\r\nWhen processing the last block, the s390 ctr code will always read\na whole block, even if there isn\u0026apos;t a whole block of data left. Fix\nthis by using the actual length left and copy it into a buffer first\nfor processing.(CVE-2023-52669)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nriscv: Check if the code to patch lies in the exit section\r\n\r\nOtherwise we fall through to vmalloc_to_page() which panics since the\naddress does not lie in the vmalloc region.(CVE-2023-52677)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npowerpc/powernv: Add a null pointer check in opal_powercap_init()\r\n\r\nkasprintf() returns a pointer to dynamically allocated memory\nwhich can be NULL upon failure.(CVE-2023-52696)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsysv: don\u0026apos;t call sb_bread() with pointers_lock held\r\n\r\nsyzbot is reporting sleep in atomic context in SysV filesystem [1], for\nsb_bread() is called with rw_spinlock held.\r\n\r\nA \u0026quot;write_lock(\u0026amp;pointers_lock) =\u0026gt; read_lock(\u0026amp;pointers_lock) deadlock\u0026quot; bug\nand a \u0026quot;sb_bread() with write_lock(\u0026amp;pointers_lock)\u0026quot; bug were introduced by\n\u0026quot;Replace BKL for chain locking with sysvfs-private rwlock\u0026quot; in Linux 2.5.12.\r\n\r\nThen, \u0026quot;[PATCH] err1-40: sysvfs locking fix\u0026quot; in Linux 2.6.8 fixed the\nformer bug by moving pointers_lock lock to the callers, but instead\nintroduced a \u0026quot;sb_bread() with read_lock(\u0026amp;pointers_lock)\u0026quot; bug (which made\nthis problem easier to hit).\r\n\r\nAl Viro suggested that why not to do like get_branch()/get_block()/\nfind_shared() in Minix filesystem does. And doing like that is almost a\nrevert of \u0026quot;[PATCH] err1-40: sysvfs locking fix\u0026quot; except that get_branch()\n from with find_shared() is called without write_lock(\u0026amp;pointers_lock).(CVE-2023-52699)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\narm64: Restrict CPU_BIG_ENDIAN to GNU as or LLVM IAS 15.x or newer\r\n\r\nPrior to LLVM 15.0.0, LLVM\u0026apos;s integrated assembler would incorrectly\nbyte-swap NOP when compiling for big-endian, and the resulting series of\nbytes happened to match the encoding of FNMADD S21, S30, S0, S0.\r\n\r\nThis went unnoticed until commit:\r\n\r\n 34f66c4c4d5518c1 (\u0026quot;arm64: Use a positive cpucap for FP/SIMD\u0026quot;)\r\n\r\nPrior to that commit, the kernel would always enable the use of FPSIMD\nearly in boot when __cpu_setup() initialized CPACR_EL1, and so usage of\nFNMADD within the kernel was not detected, but could result in the\ncorruption of user or kernel FPSIMD state.\r\n\r\nAfter that commit, the instructions happen to trap during boot prior to\nFPSIMD being detected and enabled, e.g.\r\n\r\n| Unhandled 64-bit el1h sync exception on CPU0, ESR 0x000000001fe00000 -- ASIMD\n| CPU: 0 PID: 0 Comm: swapper Not tainted 6.6.0-rc3-00013-g34f66c4c4d55 #1\n| Hardware name: linux,dummy-virt (DT)\n| pstate: 400000c9 (nZcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n| pc : __pi_strcmp+0x1c/0x150\n| lr : populate_properties+0xe4/0x254\n| sp : ffffd014173d3ad0\n| x29: ffffd014173d3af0 x28: fffffbfffddffcb8 x27: 0000000000000000\n| x26: 0000000000000058 x25: fffffbfffddfe054 x24: 0000000000000008\n| x23: fffffbfffddfe000 x22: fffffbfffddfe000 x21: fffffbfffddfe044\n| x20: ffffd014173d3b70 x19: 0000000000000001 x18: 0000000000000005\n| x17: 0000000000000010 x16: 0000000000000000 x15: 00000000413e7000\n| x14: 0000000000000000 x13: 0000000000001bcc x12: 0000000000000000\n| x11: 00000000d00dfeed x10: ffffd414193f2cd0 x9 : 0000000000000000\n| x8 : 0101010101010101 x7 : ffffffffffffffc0 x6 : 0000000000000000\n| x5 : 0000000000000000 x4 : 0101010101010101 x3 : 000000000000002a\n| x2 : 0000000000000001 x1 : ffffd014171f2988 x0 : fffffbfffddffcb8\n| Kernel panic - not syncing: Unhandled exception\n| CPU: 0 PID: 0 Comm: swapper Not tainted 6.6.0-rc3-00013-g34f66c4c4d55 #1\n| Hardware name: linux,dummy-virt (DT)\n| Call trace:\n| dump_backtrace+0xec/0x108\n| show_stack+0x18/0x2c\n| dump_stack_lvl+0x50/0x68\n| dump_stack+0x18/0x24\n| panic+0x13c/0x340\n| el1t_64_irq_handler+0x0/0x1c\n| el1_abort+0x0/0x5c\n| el1h_64_sync+0x64/0x68\n| __pi_strcmp+0x1c/0x150\n| unflatten_dt_nodes+0x1e8/0x2d8\n| __unflatten_device_tree+0x5c/0x15c\n| unflatten_device_tree+0x38/0x50\n| setup_arch+0x164/0x1e0\n| start_kernel+0x64/0x38c\n| __primary_switched+0xbc/0xc4\r\n\r\nRestrict CONFIG_CPU_BIG_ENDIAN to a known good assembler, which is\neither GNU as or LLVM\u0026apos;s IAS 15.0.0 and newer, which contains the linked\ncommit.(CVE-2023-52750)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsmb: client: fix use-after-free bug in cifs_debug_data_proc_show()\r\n\r\nSkip SMB sessions that are being teared down\n(e.g. @ses-\u0026gt;ses_status == SES_EXITING) in cifs_debug_data_proc_show()\nto avoid use-after-free in @ses.\r\n\r\nThis fixes the following GPF when reading from /proc/fs/cifs/DebugData\nwhile mounting and umounting\r\n\r\n [ 816.251274] general protection fault, probably for non-canonical\n address 0x6b6b6b6b6b6b6d81: 0000 [#1] PREEMPT SMP NOPTI\n ...\n [ 816.260138] Call Trace:\n [ 816.260329] \u0026lt;TASK\u0026gt;\n [ 816.260499] ? die_addr+0x36/0x90\n [ 816.260762] ? exc_general_protection+0x1b3/0x410\n [ 816.261126] ? asm_exc_general_protection+0x26/0x30\n [ 816.261502] ? cifs_debug_tcon+0xbd/0x240 [cifs]\n [ 816.261878] ? cifs_debug_tcon+0xab/0x240 [cifs]\n [ 816.262249] cifs_debug_data_proc_show+0x516/0xdb0 [cifs]\n [ 816.262689] ? seq_read_iter+0x379/0x470\n [ 816.262995] seq_read_iter+0x118/0x470\n [ 816.263291] proc_reg_read_iter+0x53/0x90\n [ 816.263596] ? srso_alias_return_thunk+0x5/0x7f\n [ 816.263945] vfs_read+0x201/0x350\n [ 816.264211] ksys_read+0x75/0x100\n [ 816.264472] do_syscall_64+0x3f/0x90\n [ 816.264750] entry_SYSCALL_64_after_hwframe+0x6e/0xd8\n [ 816.265135] RIP: 0033:0x7fd5e669d381(CVE-2023-52752)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Avoid NULL dereference of timing generator\r\n\r\n[Why \u0026amp; How]\nCheck whether assigned timing generator is NULL or not before\naccessing its funcs to prevent NULL dereference.(CVE-2023-52753)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npwm: Fix double shift bug\r\n\r\nThese enums are passed to set/test_bit(). The set/test_bit() functions\ntake a bit number instead of a shifted value. Passing a shifted value\nis a double shift bug like doing BIT(BIT(1)). The double shift bug\ndoesn\u0026apos;t cause a problem here because we are only checking 0 and 1 but\nif the value was 5 or above then it can lead to a buffer overflow.(CVE-2023-52756)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ngfs2: ignore negated quota changes\r\n\r\nWhen lots of quota changes are made, there may be cases in which an\ninode\u0026apos;s quota information is increased and then decreased, such as when\nblocks are added to a file, then deleted from it. If the timing is\nright, function do_qc can add pending quota changes to a transaction,\nthen later, another call to do_qc can negate those changes, resulting\nin a net gain of 0. The quota_change information is recorded in the qc\nbuffer (and qd element of the inode as well). The buffer is added to the\ntransaction by the first call to do_qc, but a subsequent call changes\nthe value from non-zero back to zero. At that point it\u0026apos;s too late to\nremove the buffer_head from the transaction. Later, when the quota sync\ncode is called, the zero-change qd element is discovered and flagged as\nan assert warning. If the fs is mounted with errors=panic, the kernel\nwill panic.\r\n\r\nThis is usually seen when files are truncated and the quota changes are\nnegated by punch_hole/truncate which uses gfs2_quota_hold and\ngfs2_quota_unhold rather than block allocations that use gfs2_quota_lock\nand gfs2_quota_unlock which automatically do quota sync.\r\n\r\nThis patch solves the problem by adding a check to qd_check_sync such\nthat net-zero quota changes already added to the transaction are no\nlonger deemed necessary to be synced, and skipped.\r\n\r\nIn this case references are taken for the qd and the slot from do_qc\nso those need to be put. The normal sequence of events for a normal\nnon-zero quota change is as follows:\r\n\r\ngfs2_quota_change\n do_qc\n qd_hold\n slot_hold\r\n\r\nLater, when the changes are to be synced:\r\n\r\ngfs2_quota_sync\n qd_fish\n qd_check_sync\n gets qd ref via lockref_get_not_dead\n do_sync\n do_qc(QC_SYNC)\n qd_put\n\t lockref_put_or_lock\n qd_unlock\n qd_put\n lockref_put_or_lock\r\n\r\nIn the net-zero change case, we add a check to qd_check_sync so it puts\nthe qd and slot references acquired in gfs2_quota_change and skip the\nunneeded sync.(CVE-2023-52759)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ns390/dasd: protect device queue against concurrent access\r\n\r\nIn dasd_profile_start() the amount of requests on the device queue are\ncounted. The access to the device queue is unprotected against\nconcurrent access. With a lot of parallel I/O, especially with alias\ndevices enabled, the device queue can change while dasd_profile_start()\nis accessing the queue. In the worst case this leads to a kernel panic\ndue to incorrect pointer accesses.\r\n\r\nFix this by taking the device lock before accessing the queue and\ncounting the requests. Additionally the check for a valid profile data\npointer can be done earlier to avoid unnecessary locking in a hot path.(CVE-2023-52774)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntty: vcc: Add check for kstrdup() in vcc_probe()\r\n\r\nAdd check for the return value of kstrdup() and return the error, if it\nfails in order to avoid NULL pointer dereference.(CVE-2023-52789)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nvhost-vdpa: fix use after free in vhost_vdpa_probe()\r\n\r\nThe put_device() calls vhost_vdpa_release_dev() which calls\nida_simple_remove() and frees \u0026quot;v\u0026quot;. So this call to\nida_simple_remove() is a use after free and a double free.(CVE-2023-52795)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nipvlan: add ipvlan_route_v6_outbound() helper\r\n\r\nInspired by syzbot reports using a stack of multiple ipvlan devices.\r\n\r\nReduce stack size needed in ipvlan_process_v6_outbound() by moving\nthe flowi6 struct used for the route lookup in an non inlined\nhelper. ipvlan_route_v6_outbound() needs 120 bytes on the stack,\nimmediately reclaimed.\r\n\r\nAlso make sure ipvlan_process_v4_outbound() is not inlined.\r\n\r\nWe might also have to lower MAX_NEST_DEV, because only syzbot uses\nsetups with more than four stacked devices.\r\n\r\nBUG: TASK stack guard page was hit at ffffc9000e803ff8 (stack is ffffc9000e804000..ffffc9000e808000)\nstack guard page: 0000 [#1] SMP KASAN\nCPU: 0 PID: 13442 Comm: syz-executor.4 Not tainted 6.1.52-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/09/2023\nRIP: 0010:kasan_check_range+0x4/0x2a0 mm/kasan/generic.c:188\nCode: 48 01 c6 48 89 c7 e8 db 4e c1 03 31 c0 5d c3 cc 0f 0b eb 02 0f 0b b8 ea ff ff ff 5d c3 cc 00 00 cc cc 00 00 cc cc 55 48 89 e5 \u0026lt;41\u0026gt; 57 41 56 41 55 41 54 53 b0 01 48 85 f6 0f 84 a4 01 00 00 48 89\nRSP: 0018:ffffc9000e804000 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff817e5bf2\nRDX: 0000000000000000 RSI: 0000000000000008 RDI: ffffffff887c6568\nRBP: ffffc9000e804000 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: dffffc0000000001 R12: 1ffff92001d0080c\nR13: dffffc0000000000 R14: ffffffff87e6b100 R15: 0000000000000000\nFS: 00007fd0c55826c0(0000) GS:ffff8881f6800000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: ffffc9000e803ff8 CR3: 0000000170ef7000 CR4: 00000000003506f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n\u0026lt;#DF\u0026gt;\n\u0026lt;/#DF\u0026gt;\n\u0026lt;TASK\u0026gt;\n[\u0026lt;ffffffff81f281d1\u0026gt;] __kasan_check_read+0x11/0x20 mm/kasan/shadow.c:31\n[\u0026lt;ffffffff817e5bf2\u0026gt;] instrument_atomic_read include/linux/instrumented.h:72 [inline]\n[\u0026lt;ffffffff817e5bf2\u0026gt;] _test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline]\n[\u0026lt;ffffffff817e5bf2\u0026gt;] cpumask_test_cpu include/linux/cpumask.h:506 [inline]\n[\u0026lt;ffffffff817e5bf2\u0026gt;] cpu_online include/linux/cpumask.h:1092 [inline]\n[\u0026lt;ffffffff817e5bf2\u0026gt;] trace_lock_acquire include/trace/events/lock.h:24 [inline]\n[\u0026lt;ffffffff817e5bf2\u0026gt;] lock_acquire+0xe2/0x590 kernel/locking/lockdep.c:5632\n[\u0026lt;ffffffff8563221e\u0026gt;] rcu_lock_acquire+0x2e/0x40 include/linux/rcupdate.h:306\n[\u0026lt;ffffffff8561464d\u0026gt;] rcu_read_lock include/linux/rcupdate.h:747 [inline]\n[\u0026lt;ffffffff8561464d\u0026gt;] ip6_pol_route+0x15d/0x1440 net/ipv6/route.c:2221\n[\u0026lt;ffffffff85618120\u0026gt;] ip6_pol_route_output+0x50/0x80 net/ipv6/route.c:2606\n[\u0026lt;ffffffff856f65b5\u0026gt;] pol_lookup_func include/net/ip6_fib.h:584 [inline]\n[\u0026lt;ffffffff856f65b5\u0026gt;] fib6_rule_lookup+0x265/0x620 net/ipv6/fib6_rules.c:116\n[\u0026lt;ffffffff85618009\u0026gt;] ip6_route_output_flags_noref+0x2d9/0x3a0 net/ipv6/route.c:2638\n[\u0026lt;ffffffff8561821a\u0026gt;] ip6_route_output_flags+0xca/0x340 net/ipv6/route.c:2651\n[\u0026lt;ffffffff838bd5a3\u0026gt;] ip6_route_output include/net/ip6_route.h:100 [inline]\n[\u0026lt;ffffffff838bd5a3\u0026gt;] ipvlan_process_v6_outbound drivers/net/ipvlan/ipvlan_core.c:473 [inline]\n[\u0026lt;ffffffff838bd5a3\u0026gt;] ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:529 [inline]\n[\u0026lt;ffffffff838bd5a3\u0026gt;] ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline]\n[\u0026lt;ffffffff838bd5a3\u0026gt;] ipvlan_queue_xmit+0xc33/0x1be0 drivers/net/ipvlan/ipvlan_core.c:677\n[\u0026lt;ffffffff838c2909\u0026gt;] ipvlan_start_xmit+0x49/0x100 drivers/net/ipvlan/ipvlan_main.c:229\n[\u0026lt;ffffffff84d03900\u0026gt;] netdev_start_xmit include/linux/netdevice.h:4966 [inline]\n[\u0026lt;ffffffff84d03900\u0026gt;] xmit_one net/core/dev.c:3644 [inline]\n[\u0026lt;ffffffff84d03900\u0026gt;] dev_hard_start_xmit+0x320/0x980 net/core/dev.c:3660\n[\u0026lt;ffffffff84d080e2\u0026gt;] __dev_queue_xmit+0x16b2/0x3370 net/core/dev.c:4324\n[\u0026lt;ffffffff855ce4cd\u0026gt;] dev_queue_xmit include/linux/netdevice.h:3067 [inline]\n[\u0026lt;ffffffff855ce4cd\u0026gt;] neigh_hh_output include/net/neighbour.h:529 [inline]\n[\u0026lt;f\n---truncated---(CVE-2023-52796)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: ath11k: fix dfs radar event locking\r\n\r\nThe ath11k active pdevs are protected by RCU but the DFS radar event\nhandling code calling ath11k_mac_get_ar_by_pdev_id() was not marked as a\nread-side critical section.\r\n\r\nMark the code in question as an RCU read-side critical section to avoid\nany potential use-after-free issues.\r\n\r\nCompile tested only.(CVE-2023-52798)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\njfs: fix array-index-out-of-bounds in dbFindLeaf\r\n\r\nCurrently while searching for dmtree_t for sufficient free blocks there\nis an array out of bounds while getting element in tp-\u0026gt;dm_stree. To add\nthe required check for out of bound we first need to determine the type\nof dmtree. Thus added an extra parameter to dbFindLeaf so that the type\nof tree can be determined and the required check can be applied.(CVE-2023-52799)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: ath11k: fix htt pktlog locking\r\n\r\nThe ath11k active pdevs are protected by RCU but the htt pktlog handling\ncode calling ath11k_mac_get_ar_by_pdev_id() was not marked as a\nread-side critical section.\r\n\r\nMark the code in question as an RCU read-side critical section to avoid\nany potential use-after-free issues.\r\n\r\nCompile tested only.(CVE-2023-52800)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\niio: adc: stm32-adc: harden against NULL pointer deref in stm32_adc_probe()\r\n\r\nof_match_device() may fail and returns a NULL pointer.\r\n\r\nIn practice there is no known reasonable way to trigger this, but\nin case one is added in future, harden the code by adding the check(CVE-2023-52802)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: Fix potential null pointer derefernce\r\n\r\nThe amdgpu_ras_get_context may return NULL if device\nnot support ras feature, so add check before using.(CVE-2023-52814)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd: Fix UBSAN array-index-out-of-bounds for Polaris and Tonga\r\n\r\nFor pptable structs that use flexible array sizes, use flexible arrays.(CVE-2023-52819)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/panel/panel-tpo-tpg110: fix a possible null pointer dereference\r\n\r\nIn tpg110_get_modes(), the return value of drm_mode_duplicate() is\nassigned to mode, which will lead to a NULL pointer dereference on\nfailure of drm_mode_duplicate(). Add a check to avoid npd.(CVE-2023-52826)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncpu/hotplug: Don\u0026apos;t offline the last non-isolated CPU\r\n\r\nIf a system has isolated CPUs via the \u0026quot;isolcpus=\u0026quot; command line parameter,\nthen an attempt to offline the last housekeeping CPU will result in a\nWARN_ON() when rebuilding the scheduler domains and a subsequent panic due\nto and unhandled empty CPU mas in partition_sched_domains_locked().\r\n\r\ncpuset_hotplug_workfn()\n rebuild_sched_domains_locked()\n ndoms = generate_sched_domains(\u0026amp;doms, \u0026amp;attr);\n cpumask_and(doms[0], top_cpuset.effective_cpus, housekeeping_cpumask(HK_FLAG_DOMAIN));\r\n\r\nThus results in an empty CPU mask which triggers the warning and then the\nsubsequent crash:\r\n\r\nWARNING: CPU: 4 PID: 80 at kernel/sched/topology.c:2366 build_sched_domains+0x120c/0x1408\nCall trace:\n build_sched_domains+0x120c/0x1408\n partition_sched_domains_locked+0x234/0x880\n rebuild_sched_domains_locked+0x37c/0x798\n rebuild_sched_domains+0x30/0x58\n cpuset_hotplug_workfn+0x2a8/0x930\r\n\r\nUnable to handle kernel paging request at virtual address fffe80027ab37080\n partition_sched_domains_locked+0x318/0x880\n rebuild_sched_domains_locked+0x37c/0x798\r\n\r\nAside of the resulting crash, it does not make any sense to offline the last\nlast housekeeping CPU.\r\n\r\nPrevent this by masking out the non-housekeeping CPUs when selecting a\ntarget CPU for initiating the CPU unplug operation via the work queue.(CVE-2023-52831)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: mac80211: don\u0026apos;t return unset power in ieee80211_get_tx_power()\r\n\r\nWe can get a UBSAN warning if ieee80211_get_tx_power() returns the\nINT_MIN value mac80211 internally uses for \u0026quot;unset power level\u0026quot;.\r\n\r\n UBSAN: signed-integer-overflow in net/wireless/nl80211.c:3816:5\n -2147483648 * 100 cannot be represented in type \u0026apos;int\u0026apos;\n CPU: 0 PID: 20433 Comm: insmod Tainted: G WC OE\n Call Trace:\n dump_stack+0x74/0x92\n ubsan_epilogue+0x9/0x50\n handle_overflow+0x8d/0xd0\n __ubsan_handle_mul_overflow+0xe/0x10\n nl80211_send_iface+0x688/0x6b0 [cfg80211]\n [...]\n cfg80211_register_wdev+0x78/0xb0 [cfg80211]\n cfg80211_netdev_notifier_call+0x200/0x620 [cfg80211]\n [...]\n ieee80211_if_add+0x60e/0x8f0 [mac80211]\n ieee80211_register_hw+0xda5/0x1170 [mac80211]\r\n\r\nIn this case, simply return an error instead, to indicate\nthat no data is available.(CVE-2023-52832)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nlocking/ww_mutex/test: Fix potential workqueue corruption\r\n\r\nIn some cases running with the test-ww_mutex code, I was seeing\nodd behavior where sometimes it seemed flush_workqueue was\nreturning before all the work threads were finished.\r\n\r\nOften this would cause strange crashes as the mutexes would be\nfreed while they were being used.\r\n\r\nLooking at the code, there is a lifetime problem as the\ncontrolling thread that spawns the work allocates the\n\u0026quot;struct stress\u0026quot; structures that are passed to the workqueue\nthreads. Then when the workqueue threads are finished,\nthey free the stress struct that was passed to them.\r\n\r\nUnfortunately the workqueue work_struct node is in the stress\nstruct. Which means the work_struct is freed before the work\nthread returns and while flush_workqueue is waiting.\r\n\r\nIt seems like a better idea to have the controlling thread\nboth allocate and free the stress structures, so that we can\nbe sure we don\u0026apos;t corrupt the workqueue by freeing the structure\nprematurely.\r\n\r\nSo this patch reworks the test to do so, and with this change\nI no longer see the early flush_workqueue returns.(CVE-2023-52836)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfbdev: imsttfb: fix a resource leak in probe\r\n\r\nI\u0026apos;ve re-written the error handling but the bug is that if init_imstt()\nfails we need to call iounmap(par-\u0026gt;cmap_regs).(CVE-2023-52838)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nplatform/x86: wmi: Fix opening of char device\r\n\r\nSince commit fa1f68db6ca7 (\u0026quot;drivers: misc: pass miscdevice pointer via\nfile private data\u0026quot;), the miscdevice stores a pointer to itself inside\nfilp-\u0026gt;private_data, which means that private_data will not be NULL when\nwmi_char_open() is called. This might cause memory corruption should\nwmi_char_open() be unable to find its driver, something which can\nhappen when the associated WMI device is deleted in wmi_free_devices().\r\n\r\nFix the problem by using the miscdevice pointer to retrieve the WMI\ndevice data associated with a char device using container_of(). This\nalso avoids wmi_char_open() picking a wrong WMI device bound to a\ndriver with the same name as the original driver.(CVE-2023-52864)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nclk: mediatek: clk-mt6797: Add check for mtk_alloc_clk_data\r\n\r\nAdd the check for the return value of mtk_alloc_clk_data() in order to\navoid NULL pointer dereference.(CVE-2023-52865)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsoc: qcom: llcc: Handle a second device without data corruption\r\n\r\nUsually there is only one llcc device. But if there were a second, even\na failed probe call would modify the global drv_data pointer. So check\nif drv_data is valid before overwriting it.(CVE-2023-52871)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nclk: mediatek: clk-mt2701: Add check for mtk_alloc_clk_data\r\n\r\nAdd the check for the return value of mtk_alloc_clk_data() in order to\navoid NULL pointer dereference.(CVE-2023-52875)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncan: dev: can_put_echo_skb(): don\u0026apos;t crash kernel if can_priv::echo_skb is accessed out of bounds\r\n\r\nIf the \u0026quot;struct can_priv::echoo_skb\u0026quot; is accessed out of bounds, this\nwould cause a kernel crash. Instead, issue a meaningful warning\nmessage and return with an error.(CVE-2023-52878)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Fix memory leak in dm_sw_fini()\r\n\r\nAfter destroying dmub_srv, the memory associated with it is\nnot freed, causing a memory leak:\r\n\r\nunreferenced object 0xffff896302b45800 (size 1024):\n comm \u0026quot;(udev-worker)\u0026quot;, pid 222, jiffies 4294894636\n hex dump (first 32 bytes):\n 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n backtrace (crc 6265fd77):\n [\u0026lt;ffffffff993495ed\u0026gt;] kmalloc_trace+0x29d/0x340\n [\u0026lt;ffffffffc0ea4a94\u0026gt;] dm_dmub_sw_init+0xb4/0x450 [amdgpu]\n [\u0026lt;ffffffffc0ea4e55\u0026gt;] dm_sw_init+0x15/0x2b0 [amdgpu]\n [\u0026lt;ffffffffc0ba8557\u0026gt;] amdgpu_device_init+0x1417/0x24e0 [amdgpu]\n [\u0026lt;ffffffffc0bab285\u0026gt;] amdgpu_driver_load_kms+0x15/0x190 [amdgpu]\n [\u0026lt;ffffffffc0ba09c7\u0026gt;] amdgpu_pci_probe+0x187/0x4e0 [amdgpu]\n [\u0026lt;ffffffff9968fd1e\u0026gt;] local_pci_probe+0x3e/0x90\n [\u0026lt;ffffffff996918a3\u0026gt;] pci_device_probe+0xc3/0x230\n [\u0026lt;ffffffff99805872\u0026gt;] really_probe+0xe2/0x480\n [\u0026lt;ffffffff99805c98\u0026gt;] __driver_probe_device+0x78/0x160\n [\u0026lt;ffffffff99805daf\u0026gt;] driver_probe_device+0x1f/0x90\n [\u0026lt;ffffffff9980601e\u0026gt;] __driver_attach+0xce/0x1c0\n [\u0026lt;ffffffff99803170\u0026gt;] bus_for_each_dev+0x70/0xc0\n [\u0026lt;ffffffff99804822\u0026gt;] bus_add_driver+0x112/0x210\n [\u0026lt;ffffffff99807245\u0026gt;] driver_register+0x55/0x100\n [\u0026lt;ffffffff990012d1\u0026gt;] do_one_initcall+0x41/0x300\r\n\r\nFix this by freeing dmub_srv after destroying it.(CVE-2024-26833)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncrypto: xilinx - call finalize with bh disabled\r\n\r\nWhen calling crypto_finalize_request, BH should be disabled to avoid\ntriggering the following calltrace:\r\n\r\n ------------[ cut here ]------------\n WARNING: CPU: 2 PID: 74 at crypto/crypto_engine.c:58 crypto_finalize_request+0xa0/0x118\n Modules linked in: cryptodev(O)\n CPU: 2 PID: 74 Comm: firmware:zynqmp Tainted: G O 6.8.0-rc1-yocto-standard #323\n Hardware name: ZynqMP ZCU102 Rev1.0 (DT)\n pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : crypto_finalize_request+0xa0/0x118\n lr : crypto_finalize_request+0x104/0x118\n sp : ffffffc085353ce0\n x29: ffffffc085353ce0 x28: 0000000000000000 x27: ffffff8808ea8688\n x26: ffffffc081715038 x25: 0000000000000000 x24: ffffff880100db00\n x23: ffffff880100da80 x22: 0000000000000000 x21: 0000000000000000\n x20: ffffff8805b14000 x19: ffffff880100da80 x18: 0000000000010450\n x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000\n x14: 0000000000000003 x13: 0000000000000000 x12: ffffff880100dad0\n x11: 0000000000000000 x10: ffffffc0832dcd08 x9 : ffffffc0812416d8\n x8 : 00000000000001f4 x7 : ffffffc0830d2830 x6 : 0000000000000001\n x5 : ffffffc082091000 x4 : ffffffc082091658 x3 : 0000000000000000\n x2 : ffffffc7f9653000 x1 : 0000000000000000 x0 : ffffff8802d20000\n Call trace:\n crypto_finalize_request+0xa0/0x118\n crypto_finalize_aead_request+0x18/0x30\n zynqmp_handle_aes_req+0xcc/0x388\n crypto_pump_work+0x168/0x2d8\n kthread_worker_fn+0xfc/0x3a0\n kthread+0x118/0x138\n ret_from_fork+0x10/0x20\n irq event stamp: 40\n hardirqs last enabled at (39): [\u0026lt;ffffffc0812416f8\u0026gt;] _raw_spin_unlock_irqrestore+0x70/0xb0\n hardirqs last disabled at (40): [\u0026lt;ffffffc08122d208\u0026gt;] el1_dbg+0x28/0x90\n softirqs last enabled at (36): [\u0026lt;ffffffc080017dec\u0026gt;] kernel_neon_begin+0x8c/0xf0\n softirqs last disabled at (34): [\u0026lt;ffffffc080017dc0\u0026gt;] kernel_neon_begin+0x60/0xf0\n ---[ end trace 0000000000000000 ]---(CVE-2024-26877)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nUSB: core: Fix deadlock in usb_deauthorize_interface()\r\n\r\nAmong the attribute file callback routines in\ndrivers/usb/core/sysfs.c, the interface_authorized_store() function is\nthe only one which acquires a device lock on an ancestor device: It\ncalls usb_deauthorize_interface(), which locks the interface\u0026apos;s parent\nUSB device.\r\n\r\nThe will lead to deadlock if another process already owns that lock\nand tries to remove the interface, whether through a configuration\nchange or because the device has been disconnected. As part of the\nremoval procedure, device_del() waits for all ongoing sysfs attribute\ncallbacks to complete. But usb_deauthorize_interface() can\u0026apos;t complete\nuntil the device lock has been released, and the lock won\u0026apos;t be\nreleased until the removal has finished.\r\n\r\nThe mechanism provided by sysfs to prevent this kind of deadlock is\nto use the sysfs_break_active_protection() function, which tells sysfs\nnot to wait for the attribute callback.\r\n\r\nReported-and-tested by: Yue Sun \u0026lt;samsun1006219@gmail.com\u0026gt;\nReported by: xingwei lee \u0026lt;xrivendell7@gmail.com\u0026gt;(CVE-2024-26934)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nf_tables: Fix potential data-race in __nft_expr_type_get()\r\n\r\nnft_unregister_expr() can concurrent with __nft_expr_type_get(),\nand there is not any protection when iterate over nf_tables_expressions\nlist in __nft_expr_type_get(). Therefore, there is potential data-race\nof nf_tables_expressions list entry.\r\n\r\nUse list_for_each_entry_rcu() to iterate over nf_tables_expressions\nlist in __nft_expr_type_get(), and use rcu_read_lock() in the caller\nnft_expr_type_get() to protect the entire type query process.(CVE-2024-27020)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nBluetooth: l2cap: fix null-ptr-deref in l2cap_chan_timeout\r\n\r\nThere is a race condition between l2cap_chan_timeout() and\nl2cap_chan_del(). When we use l2cap_chan_del() to delete the\nchannel, the chan-\u0026gt;conn will be set to null. But the conn could\nbe dereferenced again in the mutex_lock() of l2cap_chan_timeout().\nAs a result the null pointer dereference bug will happen. The\nKASAN report triggered by POC is shown below:\r\n\r\n[ 472.074580] ==================================================================\n[ 472.075284] BUG: KASAN: null-ptr-deref in mutex_lock+0x68/0xc0\n[ 472.075308] Write of size 8 at addr 0000000000000158 by task kworker/0:0/7\n[ 472.075308]\n[ 472.075308] CPU: 0 PID: 7 Comm: kworker/0:0 Not tainted 6.9.0-rc5-00356-g78c0094a146b #36\n[ 472.075308] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu4\n[ 472.075308] Workqueue: events l2cap_chan_timeout\n[ 472.075308] Call Trace:\n[ 472.075308] \u0026lt;TASK\u0026gt;\n[ 472.075308] dump_stack_lvl+0x137/0x1a0\n[ 472.075308] print_report+0x101/0x250\n[ 472.075308] ? __virt_addr_valid+0x77/0x160\n[ 472.075308] ? mutex_lock+0x68/0xc0\n[ 472.075308] kasan_report+0x139/0x170\n[ 472.075308] ? mutex_lock+0x68/0xc0\n[ 472.075308] kasan_check_range+0x2c3/0x2e0\n[ 472.075308] mutex_lock+0x68/0xc0\n[ 472.075308] l2cap_chan_timeout+0x181/0x300\n[ 472.075308] process_one_work+0x5d2/0xe00\n[ 472.075308] worker_thread+0xe1d/0x1660\n[ 472.075308] ? pr_cont_work+0x5e0/0x5e0\n[ 472.075308] kthread+0x2b7/0x350\n[ 472.075308] ? pr_cont_work+0x5e0/0x5e0\n[ 472.075308] ? kthread_blkcg+0xd0/0xd0\n[ 472.075308] ret_from_fork+0x4d/0x80\n[ 472.075308] ? kthread_blkcg+0xd0/0xd0\n[ 472.075308] ret_from_fork_asm+0x11/0x20\n[ 472.075308] \u0026lt;/TASK\u0026gt;\n[ 472.075308] ==================================================================\n[ 472.094860] Disabling lock debugging due to kernel taint\n[ 472.096136] BUG: kernel NULL pointer dereference, address: 0000000000000158\n[ 472.096136] #PF: supervisor write access in kernel mode\n[ 472.096136] #PF: error_code(0x0002) - not-present page\n[ 472.096136] PGD 0 P4D 0\n[ 472.096136] Oops: 0002 [#1] PREEMPT SMP KASAN NOPTI\n[ 472.096136] CPU: 0 PID: 7 Comm: kworker/0:0 Tainted: G B 6.9.0-rc5-00356-g78c0094a146b #36\n[ 472.096136] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu4\n[ 472.096136] Workqueue: events l2cap_chan_timeout\n[ 472.096136] RIP: 0010:mutex_lock+0x88/0xc0\n[ 472.096136] Code: be 08 00 00 00 e8 f8 23 1f fd 4c 89 f7 be 08 00 00 00 e8 eb 23 1f fd 42 80 3c 23 00 74 08 48 88\n[ 472.096136] RSP: 0018:ffff88800744fc78 EFLAGS: 00000246\n[ 472.096136] RAX: 0000000000000000 RBX: 1ffff11000e89f8f RCX: ffffffff8457c865\n[ 472.096136] RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffff88800744fc78\n[ 472.096136] RBP: 0000000000000158 R08: ffff88800744fc7f R09: 1ffff11000e89f8f\n[ 472.096136] R10: dffffc0000000000 R11: ffffed1000e89f90 R12: dffffc0000000000\n[ 472.096136] R13: 0000000000000158 R14: ffff88800744fc78 R15: ffff888007405a00\n[ 472.096136] FS: 0000000000000000(0000) GS:ffff88806d200000(0000) knlGS:0000000000000000\n[ 472.096136] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 472.096136] CR2: 0000000000000158 CR3: 000000000da32000 CR4: 00000000000006f0\n[ 472.096136] Call Trace:\n[ 472.096136] \u0026lt;TASK\u0026gt;\n[ 472.096136] ? __die_body+0x8d/0xe0\n[ 472.096136] ? page_fault_oops+0x6b8/0x9a0\n[ 472.096136] ? kernelmode_fixup_or_oops+0x20c/0x2a0\n[ 472.096136] ? do_user_addr_fault+0x1027/0x1340\n[ 472.096136] ? _printk+0x7a/0xa0\n[ 472.096136] ? mutex_lock+0x68/0xc0\n[ 472.096136] ? add_taint+0x42/0xd0\n[ 472.096136] ? exc_page_fault+0x6a/0x1b0\n[ 472.096136] ? asm_exc_page_fault+0x26/0x30\n[ 472.096136] ? mutex_lock+0x75/0xc0\n[ 472.096136] ? mutex_lock+0x88/0xc0\n[ 472.096136] ? mutex_lock+0x75/0xc0\n[ 472.096136] l2cap_chan_timeo\n---truncated---(CVE-2024-27399)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfirewire: nosy: ensure user_length is taken into account when fetching packet contents\r\n\r\nEnsure that packet_buffer_get respects the user_length provided. If\nthe length of the head packet exceeds the user_length, packet_buffer_get\nwill now return 0 to signify to the user that no data were read\nand a larger buffer size is required. Helps prevent user space overflows.(CVE-2024-27401)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nefi/capsule-loader: fix incorrect allocation size\r\n\r\ngcc-14 notices that the allocation with sizeof(void) on 32-bit architectures\nis not enough for a 64-bit phys_addr_t:\r\n\r\ndrivers/firmware/efi/capsule-loader.c: In function \u0026apos;efi_capsule_open\u0026apos;:\ndrivers/firmware/efi/capsule-loader.c:295:24: error: allocation of insufficient size \u0026apos;4\u0026apos; for type \u0026apos;phys_addr_t\u0026apos; {aka \u0026apos;long long unsigned int\u0026apos;} with size \u0026apos;8\u0026apos; [-Werror=alloc-size]\n 295 | cap_info-\u0026gt;phys = kzalloc(sizeof(void *), GFP_KERNEL);\n | ^\r\n\r\nUse the correct type instead here.(CVE-2024-27413)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: bridge: confirm multicast packets before passing them up the stack\r\n\r\nconntrack nf_confirm logic cannot handle cloned skbs referencing\nthe same nf_conn entry, which will happen for multicast (broadcast)\nframes on bridges.\r\n\r\n Example:\n macvlan0\n |\n br0\n / \\\n ethX ethY\r\n\r\n ethX (or Y) receives a L2 multicast or broadcast packet containing\n an IP packet, flow is not yet in conntrack table.\r\n\r\n 1. skb passes through bridge and fake-ip (br_netfilter)Prerouting.\n -\u0026gt; skb-\u0026gt;_nfct now references a unconfirmed entry\n 2. skb is broad/mcast packet. bridge now passes clones out on each bridge\n interface.\n 3. skb gets passed up the stack.\n 4. In macvlan case, macvlan driver retains clone(s) of the mcast skb\n and schedules a work queue to send them out on the lower devices.\r\n\r\n The clone skb-\u0026gt;_nfct is not a copy, it is the same entry as the\n original skb. The macvlan rx handler then returns RX_HANDLER_PASS.\n 5. Normal conntrack hooks (in NF_INET_LOCAL_IN) confirm the orig skb.\r\n\r\nThe Macvlan broadcast worker and normal confirm path will race.\r\n\r\nThis race will not happen if step 2 already confirmed a clone. In that\ncase later steps perform skb_clone() with skb-\u0026gt;_nfct already confirmed (in\nhash table). This works fine.\r\n\r\nBut such confirmation won\u0026apos;t happen when eb/ip/nftables rules dropped the\npackets before they reached the nf_confirm step in postrouting.\r\n\r\nPablo points out that nf_conntrack_bridge doesn\u0026apos;t allow use of stateful\nnat, so we can safely discard the nf_conn entry and let inet call\nconntrack again.\r\n\r\nThis doesn\u0026apos;t work for bridge netfilter: skb could have a nat\ntransformation. Also bridge nf prevents re-invocation of inet prerouting\nvia \u0026apos;sabotage_in\u0026apos; hook.\r\n\r\nWork around this problem by explicit confirmation of the entry at LOCAL_IN\ntime, before upper layer has a chance to clone the unconfirmed entry.\r\n\r\nThe downside is that this disables NAT and conntrack helpers.\r\n\r\nAlternative fix would be to add locking to all code parts that deal with\nunconfirmed packets, but even if that could be done in a sane way this\nopens up other problems, for example:\r\n\r\n-m physdev --physdev-out eth0 -j SNAT --snat-to 1.2.3.4\n-m physdev --physdev-out eth1 -j SNAT --snat-to 1.2.3.5\r\n\r\nFor multicast case, only one of such conflicting mappings will be\ncreated, conntrack only handles 1:1 NAT mappings.\r\n\r\nUsers should set create a setup that explicitly marks such traffic\nNOTRACK (conntrack bypass) to avoid this, but we cannot auto-bypass\nthem, ruleset might have accept rules for untracked traffic already,\nso user-visible behaviour would change.(CVE-2024-27415)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: mac80211: check/clear fast rx for non-4addr sta VLAN changes\r\n\r\nWhen moving a station out of a VLAN and deleting the VLAN afterwards, the\nfast_rx entry still holds a pointer to the VLAN\u0026apos;s netdev, which can cause\nuse-after-free bugs. Fix this by immediately calling ieee80211_check_fast_rx\nafter the VLAN change.(CVE-2024-35789)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmd/dm-raid: don\u0026apos;t call md_reap_sync_thread() directly\r\n\r\nCurrently md_reap_sync_thread() is called from raid_message() directly\nwithout holding \u0026apos;reconfig_mutex\u0026apos;, this is definitely unsafe because\nmd_reap_sync_thread() can change many fields that is protected by\n\u0026apos;reconfig_mutex\u0026apos;.\r\n\r\nHowever, hold \u0026apos;reconfig_mutex\u0026apos; here is still problematic because this\nwill cause deadlock, for example, commit 130443d60b1b (\u0026quot;md: refactor\nidle/frozen_sync_thread() to fix deadlock\u0026quot;).\r\n\r\nFix this problem by using stop_sync_thread() to unregister sync_thread,\nlike md/raid did.(CVE-2024-35808)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: udc: remove warning when queue disabled ep\r\n\r\nIt is possible trigger below warning message from mass storage function,\r\n\r\nWARNING: CPU: 6 PID: 3839 at drivers/usb/gadget/udc/core.c:294 usb_ep_queue+0x7c/0x104\npc : usb_ep_queue+0x7c/0x104\nlr : fsg_main_thread+0x494/0x1b3c\r\n\r\nRoot cause is mass storage function try to queue request from main thread,\nbut other thread may already disable ep when function disable.\r\n\r\nAs there is no function failure in the driver, in order to avoid effort\nto fix warning, change WARN_ON_ONCE() in usb_ep_queue() to pr_debug().(CVE-2024-35822)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nvt: fix unicode buffer corruption when deleting characters\r\n\r\nThis is the same issue that was fixed for the VGA text buffer in commit\n39cdb68c64d8 (\u0026quot;vt: fix memory overlapping when deleting chars in the\nbuffer\u0026quot;). The cure is also the same i.e. replace memcpy() with memmove()\ndue to the overlaping buffers.(CVE-2024-35823)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmptcp: use OPTION_MPTCP_MPJ_SYNACK in subflow_finish_connect()\r\n\r\nsubflow_finish_connect() uses four fields (backup, join_id, thmac, none)\nthat may contain garbage unless OPTION_MPTCP_MPJ_SYNACK has been set\nin mptcp_parse_option()(CVE-2024-35840)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmlxsw: spectrum_acl_tcam: Fix possible use-after-free during activity update\r\n\r\nThe rule activity update delayed work periodically traverses the list of\nconfigured rules and queries their activity from the device.\r\n\r\nAs part of this task it accesses the entry pointed by \u0026apos;ventry-\u0026gt;entry\u0026apos;,\nbut this entry can be changed concurrently by the rehash delayed work,\nleading to a use-after-free [1].\r\n\r\nFix by closing the race and perform the activity query under the\n\u0026apos;vregion-\u0026gt;lock\u0026apos; mutex.\r\n\r\n[1]\nBUG: KASAN: slab-use-after-free in mlxsw_sp_acl_tcam_flower_rule_activity_get+0x121/0x140\nRead of size 8 at addr ffff8881054ed808 by task kworker/0:18/181\r\n\r\nCPU: 0 PID: 181 Comm: kworker/0:18 Not tainted 6.9.0-rc2-custom-00781-gd5ab772d32f7 #2\nHardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019\nWorkqueue: mlxsw_core mlxsw_sp_acl_rule_activity_update_work\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0xc6/0x120\n print_report+0xce/0x670\n kasan_report+0xd7/0x110\n mlxsw_sp_acl_tcam_flower_rule_activity_get+0x121/0x140\n mlxsw_sp_acl_rule_activity_update_work+0x219/0x400\n process_one_work+0x8eb/0x19b0\n worker_thread+0x6c9/0xf70\n kthread+0x2c9/0x3b0\n ret_from_fork+0x4d/0x80\n ret_from_fork_asm+0x1a/0x30\n \u0026lt;/TASK\u0026gt;\r\n\r\nAllocated by task 1039:\n kasan_save_stack+0x33/0x60\n kasan_save_track+0x14/0x30\n __kasan_kmalloc+0x8f/0xa0\n __kmalloc+0x19c/0x360\n mlxsw_sp_acl_tcam_entry_create+0x7b/0x1f0\n mlxsw_sp_acl_tcam_vchunk_migrate_all+0x30d/0xb50\n mlxsw_sp_acl_tcam_vregion_rehash_work+0x157/0x1300\n process_one_work+0x8eb/0x19b0\n worker_thread+0x6c9/0xf70\n kthread+0x2c9/0x3b0\n ret_from_fork+0x4d/0x80\n ret_from_fork_asm+0x1a/0x30\r\n\r\nFreed by task 1039:\n kasan_save_stack+0x33/0x60\n kasan_save_track+0x14/0x30\n kasan_save_free_info+0x3b/0x60\n poison_slab_object+0x102/0x170\n __kasan_slab_free+0x14/0x30\n kfree+0xc1/0x290\n mlxsw_sp_acl_tcam_vchunk_migrate_all+0x3d7/0xb50\n mlxsw_sp_acl_tcam_vregion_rehash_work+0x157/0x1300\n process_one_work+0x8eb/0x19b0\n worker_thread+0x6c9/0xf70\n kthread+0x2c9/0x3b0\n ret_from_fork+0x4d/0x80\n ret_from_fork_asm+0x1a/0x30(CVE-2024-35855)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nx86/mm/pat: fix VM_PAT handling in COW mappings\r\n\r\nPAT handling won\u0026apos;t do the right thing in COW mappings: the first PTE (or,\nin fact, all PTEs) can be replaced during write faults to point at anon\nfolios. Reliably recovering the correct PFN and cachemode using\nfollow_phys() from PTEs will not work in COW mappings.\r\n\r\nUsing follow_phys(), we might just get the address+protection of the anon\nfolio (which is very wrong), or fail on swap/nonswap entries, failing\nfollow_phys() and triggering a WARN_ON_ONCE() in untrack_pfn() and\ntrack_pfn_copy(), not properly calling free_pfn_range().\r\n\r\nIn free_pfn_range(), we either wouldn\u0026apos;t call memtype_free() or would call\nit with the wrong range, possibly leaking memory.\r\n\r\nTo fix that, let\u0026apos;s update follow_phys() to refuse returning anon folios,\nand fallback to using the stored PFN inside vma-\u0026gt;vm_pgoff for COW mappings\nif we run into that.\r\n\r\nWe will now properly handle untrack_pfn() with COW mappings, where we\ndon\u0026apos;t need the cachemode. We\u0026apos;ll have to fail fork()-\u0026gt;track_pfn_copy() if\nthe first page was replaced by an anon folio, though: we\u0026apos;d have to store\nthe cachemode in the VMA to make this work, likely growing the VMA size.\r\n\r\nFor now, lets keep it simple and let track_pfn_copy() just fail in that\ncase: it would have failed in the past with swap/nonswap entries already,\nand it would have done the wrong thing with anon folios.\r\n\r\nSimple reproducer to trigger the WARN_ON_ONCE() in untrack_pfn():\r\n\r\n\u0026lt;--- C reproducer ---\u0026gt;\n #include \u0026lt;stdio.h\u0026gt;\n #include \u0026lt;sys/mman.h\u0026gt;\n #include \u0026lt;unistd.h\u0026gt;\n #include \u0026lt;liburing.h\u0026gt;\r\n\r\n int main(void)\n {\n struct io_uring_params p = {};\n int ring_fd;\n size_t size;\n char *map;\r\n\r\n ring_fd = io_uring_setup(1, \u0026amp;p);\n if (ring_fd \u0026lt; 0) {\n perror(\u0026quot;io_uring_setup\u0026quot;);\n return 1;\n }\n size = p.sq_off.array + p.sq_entries * sizeof(unsigned);\r\n\r\n /* Map the submission queue ring MAP_PRIVATE */\n map = mmap(0, size, PROT_READ | PROT_WRITE, MAP_PRIVATE,\n ring_fd, IORING_OFF_SQ_RING);\n if (map == MAP_FAILED) {\n perror(\u0026quot;mmap\u0026quot;);\n return 1;\n }\r\n\r\n /* We have at least one page. Let\u0026apos;s COW it. */\n *map = 0;\n pause();\n return 0;\n }\n\u0026lt;--- C reproducer ---\u0026gt;\r\n\r\nOn a system with 16 GiB RAM and swap configured:\n # ./iouring \u0026amp;\n # memhog 16G\n # killall iouring\n[ 301.552930] ------------[ cut here ]------------\n[ 301.553285] WARNING: CPU: 7 PID: 1402 at arch/x86/mm/pat/memtype.c:1060 untrack_pfn+0xf4/0x100\n[ 301.553989] Modules linked in: binfmt_misc nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_g\n[ 301.558232] CPU: 7 PID: 1402 Comm: iouring Not tainted 6.7.5-100.fc38.x86_64 #1\n[ 301.558772] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebu4\n[ 301.559569] RIP: 0010:untrack_pfn+0xf4/0x100\n[ 301.559893] Code: 75 c4 eb cf 48 8b 43 10 8b a8 e8 00 00 00 3b 6b 28 74 b8 48 8b 7b 30 e8 ea 1a f7 000\n[ 301.561189] RSP: 0018:ffffba2c0377fab8 EFLAGS: 00010282\n[ 301.561590] RAX: 00000000ffffffea RBX: ffff9208c8ce9cc0 RCX: 000000010455e047\n[ 301.562105] RDX: 07fffffff0eb1e0a RSI: 0000000000000000 RDI: ffff9208c391d200\n[ 301.562628] RBP: 0000000000000000 R08: ffffba2c0377fab8 R09: 0000000000000000\n[ 301.563145] R10: ffff9208d2292d50 R11: 0000000000000002 R12: 00007fea890e0000\n[ 301.563669] R13: 0000000000000000 R14: ffffba2c0377fc08 R15: 0000000000000000\n[ 301.564186] FS: 0000000000000000(0000) GS:ffff920c2fbc0000(0000) knlGS:0000000000000000\n[ 301.564773] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 301.565197] CR2: 00007fea88ee8a20 CR3: 00000001033a8000 CR4: 0000000000750ef0\n[ 301.565725] PKRU: 55555554\n[ 301.565944] Call Trace:\n[ 301.566148] \u0026lt;TASK\u0026gt;\n[ 301.566325] ? untrack_pfn+0xf4/0x100\n[ 301.566618] ? __warn+0x81/0x130\n[ 301.566876] ? untrack_pfn+0xf4/0x100\n[ 3\n---truncated---(CVE-2024-35877)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nf_tables: reject new basechain after table flag update\r\n\r\nWhen dormant flag is toggled, hooks are disabled in the commit phase by\niterating over current chains in table (existing and new).\r\n\r\nThe following configuration allows for an inconsistent state:\r\n\r\n add table x\n add chain x y { type filter hook input priority 0; }\n add table x { flags dormant; }\n add chain x w { type filter hook input priority 1; }\r\n\r\nwhich triggers the following warning when trying to unregister chain w\nwhich is already unregistered.\r\n\r\n[ 127.322252] WARNING: CPU: 7 PID: 1211 at net/netfilter/core.c:50 1 __nf_unregister_net_hook+0x21a/0x260\n[...]\n[ 127.322519] Call Trace:\n[ 127.322521] \u0026lt;TASK\u0026gt;\n[ 127.322524] ? __warn+0x9f/0x1a0\n[ 127.322531] ? __nf_unregister_net_hook+0x21a/0x260\n[ 127.322537] ? report_bug+0x1b1/0x1e0\n[ 127.322545] ? handle_bug+0x3c/0x70\n[ 127.322552] ? exc_invalid_op+0x17/0x40\n[ 127.322556] ? asm_exc_invalid_op+0x1a/0x20\n[ 127.322563] ? kasan_save_free_info+0x3b/0x60\n[ 127.322570] ? __nf_unregister_net_hook+0x6a/0x260\n[ 127.322577] ? __nf_unregister_net_hook+0x21a/0x260\n[ 127.322583] ? __nf_unregister_net_hook+0x6a/0x260\n[ 127.322590] ? __nf_tables_unregister_hook+0x8a/0xe0 [nf_tables]\n[ 127.322655] nft_table_disable+0x75/0xf0 [nf_tables]\n[ 127.322717] nf_tables_commit+0x2571/0x2620 [nf_tables](CVE-2024-35900)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nselinux: avoid dereference of garbage after mount failure\r\n\r\nIn case kern_mount() fails and returns an error pointer return in the\nerror branch instead of continuing and dereferencing the error pointer.\r\n\r\nWhile on it drop the never read static variable selinuxfs_mount.(CVE-2024-35904)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nblock: prevent division by zero in blk_rq_stat_sum()\r\n\r\nThe expression dst-\u0026gt;nr_samples + src-\u0026gt;nr_samples may\nhave zero value on overflow. It is necessary to add\na check to avoid division by zero.\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with Svace.(CVE-2024-35925)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndma-direct: Leak pages on dma_set_decrypted() failure\r\n\r\nOn TDX it is possible for the untrusted host to cause\nset_memory_encrypted() or set_memory_decrypted() to fail such that an\nerror is returned and the resulting memory is shared. Callers need to\ntake care to handle these errors to avoid returning decrypted (shared)\nmemory to the page allocator, which could lead to functional or security\nissues.\r\n\r\nDMA could free decrypted/shared pages if dma_set_decrypted() fails. This\nshould be a rare case. Just leak the pages in this case instead of\nfreeing them.(CVE-2024-35939)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/client: Fully protect modes[] with dev-\u0026gt;mode_config.mutex\r\n\r\nThe modes[] array contains pointers to modes on the connectors\u0026apos;\nmode lists, which are protected by dev-\u0026gt;mode_config.mutex.\nThus we need to extend modes[] the same protection or by the\ntime we use it the elements may already be pointing to\nfreed/reused memory.(CVE-2024-35950)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: qgroup: fix qgroup prealloc rsv leak in subvolume operations\r\n\r\nCreate subvolume, create snapshot and delete subvolume all use\nbtrfs_subvolume_reserve_metadata() to reserve metadata for the changes\ndone to the parent subvolume\u0026apos;s fs tree, which cannot be mediated in the\nnormal way via start_transaction. When quota groups (squota or qgroups)\nare enabled, this reserves qgroup metadata of type PREALLOC. Once the\noperation is associated to a transaction, we convert PREALLOC to\nPERTRANS, which gets cleared in bulk at the end of the transaction.\r\n\r\nHowever, the error paths of these three operations were not implementing\nthis lifecycle correctly. They unconditionally converted the PREALLOC to\nPERTRANS in a generic cleanup step regardless of errors or whether the\noperation was fully associated to a transaction or not. This resulted in\nerror paths occasionally converting this rsv to PERTRANS without calling\nrecord_root_in_trans successfully, which meant that unless that root got\nrecorded in the transaction by some other thread, the end of the\ntransaction would not free that root\u0026apos;s PERTRANS, leaking it. Ultimately,\nthis resulted in hitting a WARN in CONFIG_BTRFS_DEBUG builds at unmount\nfor the leaked reservation.\r\n\r\nThe fix is to ensure that every qgroup PREALLOC reservation observes the\nfollowing properties:\r\n\r\n1. any failure before record_root_in_trans is called successfully\n results in freeing the PREALLOC reservation.\n2. after record_root_in_trans, we convert to PERTRANS, and now the\n transaction owns freeing the reservation.\r\n\r\nThis patch enforces those properties on the three operations. Without\nit, generic/269 with squotas enabled at mkfs time would fail in ~5-10\nruns on my system. With this patch, it ran successfully 1000 times in a\nrow.(CVE-2024-35956)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: ena: Fix incorrect descriptor free behavior\r\n\r\nENA has two types of TX queues:\n- queues which only process TX packets arriving from the network stack\n- queues which only process TX packets forwarded to it by XDP_REDIRECT\n or XDP_TX instructions\r\n\r\nThe ena_free_tx_bufs() cycles through all descriptors in a TX queue\nand unmaps + frees every descriptor that hasn\u0026apos;t been acknowledged yet\nby the device (uncompleted TX transactions).\nThe function assumes that the processed TX queue is necessarily from\nthe first category listed above and ends up using napi_consume_skb()\nfor descriptors belonging to an XDP specific queue.\r\n\r\nThis patch solves a bug in which, in case of a VF reset, the\ndescriptors aren\u0026apos;t freed correctly, leading to crashes.(CVE-2024-35958)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/mlx5: Properly link new fs rules into the tree\r\n\r\nPreviously, add_rule_fg would only add newly created rules from the\nhandle into the tree when they had a refcount of 1. On the other hand,\ncreate_flow_handle tries hard to find and reference already existing\nidentical rules instead of creating new ones.\r\n\r\nThese two behaviors can result in a situation where create_flow_handle\n1) creates a new rule and references it, then\n2) in a subsequent step during the same handle creation references it\n again,\nresulting in a rule with a refcount of 2 that is not linked into the\ntree, will have a NULL parent and root and will result in a crash when\nthe flow group is deleted because del_sw_hw_rule, invoked on rule\ndeletion, assumes node-\u0026gt;parent is != NULL.\r\n\r\nThis happened in the wild, due to another bug related to incorrect\nhandling of duplicate pkt_reformat ids, which lead to the code in\ncreate_flow_handle incorrectly referencing a just-added rule in the same\nflow handle, resulting in the problem described above. Full details are\nat [1].\r\n\r\nThis patch changes add_rule_fg to add new rules without parents into\nthe tree, properly initializing them and avoiding the crash. This makes\nit more consistent with how rules are added to an FTE in\ncreate_flow_handle.(CVE-2024-35960)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nBluetooth: Fix memory leak in hci_req_sync_complete()\r\n\r\nIn \u0026apos;hci_req_sync_complete()\u0026apos;, always free the previous sync\nrequest state before assigning reference to a new one.(CVE-2024-35978)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndmaengine: idxd: Fix oops during rmmod on single-CPU platforms\r\n\r\nDuring the removal of the idxd driver, registered offline callback is\ninvoked as part of the clean up process. However, on systems with only\none CPU online, no valid target is available to migrate the\nperf context, resulting in a kernel oops:\r\n\r\n BUG: unable to handle page fault for address: 000000000002a2b8\n #PF: supervisor write access in kernel mode\n #PF: error_code(0x0002) - not-present page\n PGD 1470e1067 P4D 0\n Oops: 0002 [#1] PREEMPT SMP NOPTI\n CPU: 0 PID: 20 Comm: cpuhp/0 Not tainted 6.8.0-rc6-dsa+ #57\n Hardware name: Intel Corporation AvenueCity/AvenueCity, BIOS BHSDCRB1.86B.2492.D03.2307181620 07/18/2023\n RIP: 0010:mutex_lock+0x2e/0x50\n ...\n Call Trace:\n \u0026lt;TASK\u0026gt;\n __die+0x24/0x70\n page_fault_oops+0x82/0x160\n do_user_addr_fault+0x65/0x6b0\n __pfx___rdmsr_safe_on_cpu+0x10/0x10\n exc_page_fault+0x7d/0x170\n asm_exc_page_fault+0x26/0x30\n mutex_lock+0x2e/0x50\n mutex_lock+0x1e/0x50\n perf_pmu_migrate_context+0x87/0x1f0\n perf_event_cpu_offline+0x76/0x90 [idxd]\n cpuhp_invoke_callback+0xa2/0x4f0\n __pfx_perf_event_cpu_offline+0x10/0x10 [idxd]\n cpuhp_thread_fun+0x98/0x150\n smpboot_thread_fn+0x27/0x260\n smpboot_thread_fn+0x1af/0x260\n __pfx_smpboot_thread_fn+0x10/0x10\n kthread+0x103/0x140\n __pfx_kthread+0x10/0x10\n ret_from_fork+0x31/0x50\n __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1b/0x30\n \u0026lt;TASK\u0026gt;\r\n\r\nFix the issue by preventing the migration of the perf context to an\ninvalid target.(CVE-2024-35989)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmm/hugetlb: fix missing hugetlb_lock for resv uncharge\r\n\r\nThere is a recent report on UFFDIO_COPY over hugetlb:\r\n\r\nhttps://lore.kernel.org/all/000000000000ee06de0616177560@google.com/\r\n\r\n350:\tlockdep_assert_held(\u0026amp;hugetlb_lock);\r\n\r\nShould be an issue in hugetlb but triggered in an userfault context, where\nit goes into the unlikely path where two threads modifying the resv map\ntogether. Mike has a fix in that path for resv uncharge but it looks like\nthe locking criteria was overlooked: hugetlb_cgroup_uncharge_folio_rsvd()\nwill update the cgroup pointer, so it requires to be called with the lock\nheld.(CVE-2024-36000)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ni40e: Do not use WQ_MEM_RECLAIM flag for workqueue\r\n\r\nIssue reported by customer during SRIOV testing, call trace:\nWhen both i40e and the i40iw driver are loaded, a warning\nin check_flush_dependency is being triggered. This seems\nto be because of the i40e driver workqueue is allocated with\nthe WQ_MEM_RECLAIM flag, and the i40iw one is not.\r\n\r\nSimilar error was encountered on ice too and it was fixed by\nremoving the flag. Do the same for i40e too.\r\n\r\n[Feb 9 09:08] ------------[ cut here ]------------\n[ +0.000004] workqueue: WQ_MEM_RECLAIM i40e:i40e_service_task [i40e] is\nflushing !WQ_MEM_RECLAIM infiniband:0x0\n[ +0.000060] WARNING: CPU: 0 PID: 937 at kernel/workqueue.c:2966\ncheck_flush_dependency+0x10b/0x120\n[ +0.000007] Modules linked in: snd_seq_dummy snd_hrtimer snd_seq\nsnd_timer snd_seq_device snd soundcore nls_utf8 cifs cifs_arc4\nnls_ucs2_utils rdma_cm iw_cm ib_cm cifs_md4 dns_resolver netfs qrtr\nrfkill sunrpc vfat fat intel_rapl_msr intel_rapl_common irdma\nintel_uncore_frequency intel_uncore_frequency_common ice ipmi_ssif\nisst_if_common skx_edac nfit libnvdimm x86_pkg_temp_thermal\nintel_powerclamp gnss coretemp ib_uverbs rapl intel_cstate ib_core\niTCO_wdt iTCO_vendor_support acpi_ipmi mei_me ipmi_si intel_uncore\nioatdma i2c_i801 joydev pcspkr mei ipmi_devintf lpc_ich\nintel_pch_thermal i2c_smbus ipmi_msghandler acpi_power_meter acpi_pad\nxfs libcrc32c ast sd_mod drm_shmem_helper t10_pi drm_kms_helper sg ixgbe\ndrm i40e ahci crct10dif_pclmul libahci crc32_pclmul igb crc32c_intel\nlibata ghash_clmulni_intel i2c_algo_bit mdio dca wmi dm_mirror\ndm_region_hash dm_log dm_mod fuse\n[ +0.000050] CPU: 0 PID: 937 Comm: kworker/0:3 Kdump: loaded Not\ntainted 6.8.0-rc2-Feb-net_dev-Qiueue-00279-gbd43c5687e05 #1\n[ +0.000003] Hardware name: Intel Corporation S2600BPB/S2600BPB, BIOS\nSE5C620.86B.02.01.0013.121520200651 12/15/2020\n[ +0.000001] Workqueue: i40e i40e_service_task [i40e]\n[ +0.000024] RIP: 0010:check_flush_dependency+0x10b/0x120\n[ +0.000003] Code: ff 49 8b 54 24 18 48 8d 8b b0 00 00 00 49 89 e8 48\n81 c6 b0 00 00 00 48 c7 c7 b0 97 fa 9f c6 05 8a cc 1f 02 01 e8 35 b3 fd\nff \u0026lt;0f\u0026gt; 0b e9 10 ff ff ff 80 3d 78 cc 1f 02 00 75 94 e9 46 ff ff ff 90\n[ +0.000002] RSP: 0018:ffffbd294976bcf8 EFLAGS: 00010282\n[ +0.000002] RAX: 0000000000000000 RBX: ffff94d4c483c000 RCX:\n0000000000000027\n[ +0.000001] RDX: ffff94d47f620bc8 RSI: 0000000000000001 RDI:\nffff94d47f620bc0\n[ +0.000001] RBP: 0000000000000000 R08: 0000000000000000 R09:\n00000000ffff7fff\n[ +0.000001] R10: ffffbd294976bb98 R11: ffffffffa0be65e8 R12:\nffff94c5451ea180\n[ +0.000001] R13: ffff94c5ab5e8000 R14: ffff94c5c20b6e05 R15:\nffff94c5f1330ab0\n[ +0.000001] FS: 0000000000000000(0000) GS:ffff94d47f600000(0000)\nknlGS:0000000000000000\n[ +0.000002] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ +0.000001] CR2: 00007f9e6f1fca70 CR3: 0000000038e20004 CR4:\n00000000007706f0\n[ +0.000000] DR0: 0000000000000000 DR1: 0000000000000000 DR2:\n0000000000000000\n[ +0.000001] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:\n0000000000000400\n[ +0.000001] PKRU: 55555554\n[ +0.000001] Call Trace:\n[ +0.000001] \u0026lt;TASK\u0026gt;\n[ +0.000002] ? __warn+0x80/0x130\n[ +0.000003] ? check_flush_dependency+0x10b/0x120\n[ +0.000002] ? report_bug+0x195/0x1a0\n[ +0.000005] ? handle_bug+0x3c/0x70\n[ +0.000003] ? exc_invalid_op+0x14/0x70\n[ +0.000002] ? asm_exc_invalid_op+0x16/0x20\n[ +0.000006] ? check_flush_dependency+0x10b/0x120\n[ +0.000002] ? check_flush_dependency+0x10b/0x120\n[ +0.000002] __flush_workqueue+0x126/0x3f0\n[ +0.000015] ib_cache_cleanup_one+0x1c/0xe0 [ib_core]\n[ +0.000056] __ib_unregister_device+0x6a/0xb0 [ib_core]\n[ +0.000023] ib_unregister_device_and_put+0x34/0x50 [ib_core]\n[ +0.000020] i40iw_close+0x4b/0x90 [irdma]\n[ +0.000022] i40e_notify_client_of_netdev_close+0x54/0xc0 [i40e]\n[ +0.000035] i40e_service_task+0x126/0x190 [i40e]\n[ +0.000024] process_one_work+0x174/0x340\n[ +0.000003] worker_th\n---truncated---(CVE-2024-36004)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmlxsw: spectrum_acl_tcam: Fix warning during rehash\r\n\r\nAs previously explained, the rehash delayed work migrates filters from\none region to another. This is done by iterating over all chunks (all\nthe filters with the same priority) in the region and in each chunk\niterating over all the filters.\r\n\r\nWhen the work runs out of credits it stores the current chunk and entry\nas markers in the per-work context so that it would know where to resume\nthe migration from the next time the work is scheduled.\r\n\r\nUpon error, the chunk marker is reset to NULL, but without resetting the\nentry markers despite being relative to it. This can result in migration\nbeing resumed from an entry that does not belong to the chunk being\nmigrated. In turn, this will eventually lead to a chunk being iterated\nover as if it is an entry. Because of how the two structures happen to\nbe defined, this does not lead to KASAN splats, but to warnings such as\n[1].\r\n\r\nFix by creating a helper that resets all the markers and call it from\nall the places the currently only reset the chunk marker. For good\nmeasures also call it when starting a completely new rehash. Add a\nwarning to avoid future cases.\r\n\r\n[1]\nWARNING: CPU: 7 PID: 1076 at drivers/net/ethernet/mellanox/mlxsw/core_acl_flex_keys.c:407 mlxsw_afk_encode+0x242/0x2f0\nModules linked in:\nCPU: 7 PID: 1076 Comm: kworker/7:24 Tainted: G W 6.9.0-rc3-custom-00880-g29e61d91b77b #29\nHardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019\nWorkqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work\nRIP: 0010:mlxsw_afk_encode+0x242/0x2f0\n[...]\nCall Trace:\n \u0026lt;TASK\u0026gt;\n mlxsw_sp_acl_atcam_entry_add+0xd9/0x3c0\n mlxsw_sp_acl_tcam_entry_create+0x5e/0xa0\n mlxsw_sp_acl_tcam_vchunk_migrate_all+0x109/0x290\n mlxsw_sp_acl_tcam_vregion_rehash_work+0x6c/0x470\n process_one_work+0x151/0x370\n worker_thread+0x2cb/0x3e0\n kthread+0xd0/0x100\n ret_from_fork+0x34/0x50\n \u0026lt;/TASK\u0026gt;(CVE-2024-36007)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nppdev: Add an error check in register_device\r\n\r\nIn register_device, the return value of ida_simple_get is unchecked,\nin witch ida_simple_get will use an invalid index value.\r\n\r\nTo address this issue, index should be checked after ida_simple_get. When\nthe index value is abnormal, a warning message should be printed, the port\nshould be dropped, and the value should be recorded.(CVE-2024-36015)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npinctrl: core: delete incorrect free in pinctrl_enable()\r\n\r\nThe \u0026quot;pctldev\u0026quot; struct is allocated in devm_pinctrl_register_and_init().\nIt\u0026apos;s a devm_ managed pointer that is freed by devm_pinctrl_dev_release(),\nso freeing it in pinctrl_enable() will lead to a double free.\r\n\r\nThe devm_pinctrl_dev_release() function frees the pindescs and destroys\nthe mutex as well.(CVE-2024-36940)",
"id": "OESA-2024-1694",
"modified": "2026-08-06T11:07:09Z",
"published": "2024-06-07T11:07:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1694"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47265"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47356"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47370"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47427"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47489"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48689"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52654"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52669"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52677"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52696"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52699"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52750"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52752"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52753"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52756"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52759"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52774"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52789"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52795"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52796"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52798"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52799"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52800"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52802"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52814"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52819"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52826"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52831"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52832"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52836"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52838"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52864"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52865"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52871"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52875"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52878"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26833"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26877"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26934"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27020"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27399"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27401"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27413"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27415"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35789"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35808"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35822"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35823"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35840"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35855"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35877"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35900"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35904"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35925"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35939"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35950"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35956"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35958"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35960"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35978"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35989"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36000"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36004"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36007"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36015"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36940"
}
],
"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-2021-47265",
"CVE-2021-47356",
"CVE-2021-47370",
"CVE-2021-47427",
"CVE-2021-47489",
"CVE-2022-48689",
"CVE-2023-52654",
"CVE-2023-52669",
"CVE-2023-52677",
"CVE-2023-52696",
"CVE-2023-52699",
"CVE-2023-52750",
"CVE-2023-52752",
"CVE-2023-52753",
"CVE-2023-52756",
"CVE-2023-52759",
"CVE-2023-52774",
"CVE-2023-52789",
"CVE-2023-52795",
"CVE-2023-52796",
"CVE-2023-52798",
"CVE-2023-52799",
"CVE-2023-52800",
"CVE-2023-52802",
"CVE-2023-52814",
"CVE-2023-52819",
"CVE-2023-52826",
"CVE-2023-52831",
"CVE-2023-52832",
"CVE-2023-52836",
"CVE-2023-52838",
"CVE-2023-52864",
"CVE-2023-52865",
"CVE-2023-52871",
"CVE-2023-52875",
"CVE-2023-52878",
"CVE-2024-26833",
"CVE-2024-26877",
"CVE-2024-26934",
"CVE-2024-27020",
"CVE-2024-27399",
"CVE-2024-27401",
"CVE-2024-27413",
"CVE-2024-27415",
"CVE-2024-35789",
"CVE-2024-35808",
"CVE-2024-35822",
"CVE-2024-35823",
"CVE-2024-35840",
"CVE-2024-35855",
"CVE-2024-35877",
"CVE-2024-35900",
"CVE-2024-35904",
"CVE-2024-35925",
"CVE-2024-35939",
"CVE-2024-35950",
"CVE-2024-35956",
"CVE-2024-35958",
"CVE-2024-35960",
"CVE-2024-35978",
"CVE-2024-35989",
"CVE-2024-36000",
"CVE-2024-36004",
"CVE-2024-36007",
"CVE-2024-36015",
"CVE-2024-36940"
]
}
OESA-2024-1705 (CVE-2021-47236)
Vulnerability from osv_openeuler – Published: 2024-06-14 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: cdc_eem: fix tx fixup skb leak
when usbnet transmit a skb, eem fixup it in eem_tx_fixup(), if skb_copy_expand() failed, it return NULL, usbnet_start_xmit() will have no chance to free original skb.
fix it by free orginal skb in eem_tx_fixup() first, then check skb clone status, if failed, return NULL to usbnet.(CVE-2021-47236)
In the Linux kernel, the following vulnerability has been resolved:
gfs2: Fix use-after-free in gfs2_glock_shrink_scan
The GLF_LRU flag is checked under lru_lock in gfs2_glock_remove_from_lru() to remove the glock from the lru list in __gfs2_glock_put().
On the shrink scan path, the same flag is cleared under lru_lock but because of cond_resched_lock(&lru_lock) in gfs2_dispose_glock_lru(), progress on the put side can be made without deleting the glock from the lru list.
Keep GLF_LRU across the race window opened by cond_resched_lock(&lru_lock) to ensure correct behavior on both sides - clear GLF_LRU after list_del under lru_lock.(CVE-2021-47254)
In the Linux kernel, the following vulnerability has been resolved:
netrom: Decrease sock refcount when sock timers expire
Commit 63346650c1a9 ("netrom: switch to sock timer API") switched to use sock timer API. It replaces mod_timer() by sk_reset_timer(), and del_timer() by sk_stop_timer().
Function sk_reset_timer() will increase the refcount of sock if it is called on an inactive timer, hence, in case the timer expires, we need to decrease the refcount ourselves in the handler, otherwise, the sock refcount will be unbalanced and the sock will never be freed.(CVE-2021-47294)
In the Linux kernel, the following vulnerability has been resolved:
memory: fsl_ifc: fix leak of IO mapping on probe failure
On probe error the driver should unmap the IO memory. Smatch reports:
drivers/memory/fsl_ifc.c:298 fsl_ifc_ctrl_probe() warn: 'fsl_ifc_ctrl_dev->gregs' not released on lines: 298.(CVE-2021-47315)
In the Linux kernel, the following vulnerability has been resolved:
watchdog: Fix possible use-after-free in wdt_startup()
This module's remove path calls del_timer(). However, that function does not wait until the timer handler finishes. This means that the timer handler may still be running after the driver's remove function has finished, which would result in a use-after-free.
Fix by calling del_timer_sync(), which makes sure the timer handler has finished, and unable to re-schedule itself.(CVE-2021-47324)
In the Linux kernel, the following vulnerability has been resolved:
scsi: megaraid_sas: Fix resource leak in case of probe failure
The driver doesn't clean up all the allocated resources properly when scsi_add_host(), megasas_start_aen() function fails during the PCI device probe.
Clean up all those resources.(CVE-2021-47329)
In the Linux kernel, the following vulnerability has been resolved:
ipack: ipoctal: fix module reference leak
A reference to the carrier module was taken on every open but was only released once when the final reference to the tty struct was dropped.
Fix this by taking the module reference and initialising the tty driver data when installing the tty.(CVE-2021-47403)
In the Linux kernel, the following vulnerability has been resolved:
usb: dwc2: check return value after calling platform_get_resource()
It will cause null-ptr-deref if platform_get_resource() returns NULL, we need check the return value.(CVE-2021-47409)
In the Linux kernel, the following vulnerability has been resolved:
i40e: Fix freeing of uninitialized misc IRQ vector
When VSI set up failed in i40e_probe() as part of PF switch set up driver was trying to free misc IRQ vectors in i40e_clear_interrupt_scheme and produced a kernel Oops:
Trying to free already-free IRQ 266 WARNING: CPU: 0 PID: 5 at kernel/irq/manage.c:1731 __free_irq+0x9a/0x300 Workqueue: events work_for_cpu_fn RIP: 0010:__free_irq+0x9a/0x300 Call Trace: ? synchronize_irq+0x3a/0xa0 free_irq+0x2e/0x60 i40e_clear_interrupt_scheme+0x53/0x190 [i40e] i40e_probe.part.108+0x134b/0x1a40 [i40e] ? kmem_cache_alloc+0x158/0x1c0 ? acpi_ut_update_ref_count.part.1+0x8e/0x345 ? acpi_ut_update_object_reference+0x15e/0x1e2 ? strstr+0x21/0x70 ? irq_get_irq_data+0xa/0x20 ? mp_check_pin_attr+0x13/0xc0 ? irq_get_irq_data+0xa/0x20 ? mp_map_pin_to_irq+0xd3/0x2f0 ? acpi_register_gsi_ioapic+0x93/0x170 ? pci_conf1_read+0xa4/0x100 ? pci_bus_read_config_word+0x49/0x70 ? do_pci_enable_device+0xcc/0x100 local_pci_probe+0x41/0x90 work_for_cpu_fn+0x16/0x20 process_one_work+0x1a7/0x360 worker_thread+0x1cf/0x390 ? create_worker+0x1a0/0x1a0 kthread+0x112/0x130 ? kthread_flush_work_fn+0x10/0x10 ret_from_fork+0x1f/0x40
The problem is that at that point misc IRQ vectors were not allocated yet and we get a call trace that driver is trying to free already free IRQ vectors.
Add a check in i40e_clear_interrupt_scheme for __I40E_MISC_IRQ_REQUESTED PF state before calling i40e_free_misc_vector. This state is set only if misc IRQ vectors were properly initialized.(CVE-2021-47424)
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: fix data corruption after conversion from inline format
Commit 6dbf7bb55598 ("fs: Don't invalidate page buffers in block_write_full_page()") uncovered a latent bug in ocfs2 conversion from inline inode format to a normal inode format.
The code in ocfs2_convert_inline_data_to_extents() attempts to zero out the whole cluster allocated for file data by grabbing, zeroing, and dirtying all pages covering this cluster. However these pages are beyond i_size, thus writeback code generally ignores these dirty pages and no blocks were ever actually zeroed on the disk.
This oversight was fixed by commit 693c241a5f6a ("ocfs2: No need to zero pages past i_size.") for standard ocfs2 write path, inline conversion path was apparently forgotten; the commit log also has a reasoning why the zeroing actually is not needed.
After commit 6dbf7bb55598, things became worse as writeback code stopped invalidating buffers on pages beyond i_size and thus these pages end up with clean PageDirty bit but with buffers attached to these pages being still dirty. So when a file is converted from inline format, then writeback triggers, and then the file is grown so that these pages become valid, the invalid dirtiness state is preserved, mark_buffer_dirty() does nothing on these pages (buffers are already dirty) but page is never written back because it is clean. So data written to these pages is lost once pages are reclaimed.
Simple reproducer for the problem is:
xfs_io -f -c "pwrite 0 2000" -c "pwrite 2000 2000" -c "fsync" \ -c "pwrite 4000 2000" ocfs2_file
After unmounting and mounting the fs again, you can observe that end of 'ocfs2_file' has lost its contents.
Fix the problem by not doing the pointless zeroing during conversion from inline format similarly as in the standard write path.
akpm@linux-foundation.org: fix whitespace, per Joseph
In the Linux kernel, the following vulnerability has been resolved:
comedi: ni_usb6501: fix NULL-deref in command paths
The driver uses endpoint-sized USB transfer buffers but had no sanity checks on the sizes. This can lead to zero-size-pointer dereferences or overflowed transfer buffers in ni6501_port_command() and ni6501_counter_command() if a (malicious) device has smaller max-packet sizes than expected (or when doing descriptor fuzz testing).
Add the missing sanity checks to probe().(CVE-2021-47476)
In the Linux kernel, the following vulnerability has been resolved:
isofs: Fix out of bound access for corrupted isofs image
When isofs image is suitably corrupted isofs_read_inode() can read data beyond the end of buffer. Sanity-check the directory entry length before using it.(CVE-2021-47478)
In the Linux kernel, the following vulnerability has been resolved:
staging: rtl8712: fix use-after-free in rtl8712_dl_fw
Syzbot reported use-after-free in rtl8712_dl_fw(). The problem was in race condition between r871xu_dev_remove() ->ndo_open() callback.
It's easy to see from crash log, that driver accesses released firmware in ->ndo_open() callback. It may happen, since driver was releasing firmware before unregistering netdev. Fix it by moving unregister_netdev() before cleaning up resources.
Call Trace: ... rtl871x_open_fw drivers/staging/rtl8712/hal_init.c:83 [inline] rtl8712_dl_fw+0xd95/0xe10 drivers/staging/rtl8712/hal_init.c:170 rtl8712_hal_init drivers/staging/rtl8712/hal_init.c:330 [inline] rtl871x_hal_init+0xae/0x180 drivers/staging/rtl8712/hal_init.c:394 netdev_open+0xe6/0x6c0 drivers/staging/rtl8712/os_intfs.c:380 __dev_open+0x2bc/0x4d0 net/core/dev.c:1484
Freed by task 1306: ... release_firmware+0x1b/0x30 drivers/base/firmware_loader/main.c:1053 r871xu_dev_remove+0xcc/0x2c0 drivers/staging/rtl8712/usb_intf.c:599 usb_unbind_interface+0x1d8/0x8d0 drivers/usb/core/driver.c:458(CVE-2021-47479)
In the Linux kernel, the following vulnerability has been resolved:
iio: accel: kxcjk-1013: Fix possible memory leak in probe and remove
When ACPI type is ACPI_SMO8500, the data->dready_trig will not be set, the memory allocated by iio_triggered_buffer_setup() will not be freed, and cause memory leak as follows:
unreferenced object 0xffff888009551400 (size 512): comm "i2c-SMO8500-125", pid 911, jiffies 4294911787 (age 83.852s) hex dump (first 32 bytes): 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 20 e2 e5 c0 ff ff ff ff ........ ....... backtrace: [<0000000041ce75ee>] kmem_cache_alloc_trace+0x16d/0x360 [<000000000aeb17b0>] iio_kfifo_allocate+0x41/0x130 [kfifo_buf] [<000000004b40c1f5>] iio_triggered_buffer_setup_ext+0x2c/0x210 [industrialio_triggered_buffer] [<000000004375b15f>] kxcjk1013_probe+0x10c3/0x1d81 [kxcjk_1013]
Fix it by remove data->dready_trig condition in probe and remove.(CVE-2021-47499)
In the Linux kernel, the following vulnerability has been resolved:
ALSA: pcm: oss: Fix negative period/buffer sizes
The period size calculation in OSS layer may receive a negative value as an error, but the code there assumes only the positive values and handle them with size_t. Due to that, a too big value may be passed to the lower layers.
This patch changes the code to handle with ssize_t and adds the proper error checks appropriately.(CVE-2021-47511)
In the Linux kernel, the following vulnerability has been resolved:
nfc: fix potential NULL pointer deref in nfc_genl_dump_ses_done
The done() netlink callback nfc_genl_dump_ses_done() should check if received argument is non-NULL, because its allocation could fail earlier in dumpit() (nfc_genl_dump_ses()).(CVE-2021-47518)
In the Linux kernel, the following vulnerability has been resolved:
rxrpc: Fix rxrpc_local leak in rxrpc_lookup_peer()
Need to call rxrpc_put_local() for peer candidate before kfree() as it holds a ref to rxrpc_local.
DH: v2: Changed to abstract the peer freeing code out into a function
In the Linux kernel, the following vulnerability has been resolved:
net/mlx4_en: Fix an use-after-free bug in mlx4_en_try_alloc_resources()
In mlx4_en_try_alloc_resources(), mlx4_en_copy_priv() is called and tmp->tx_cq will be freed on the error path of mlx4_en_copy_priv(). After that mlx4_en_alloc_resources() is called and there is a dereference of &tmp->tx_cq[t][i] in mlx4_en_alloc_resources(), which could lead to a use after free problem on failure of mlx4_en_copy_priv().
Fix this bug by adding a check of mlx4_en_copy_priv()
This bug was found by a static analyzer. The analysis employs differential checking to identify inconsistent security operations (e.g., checks or kfrees) between two code paths and confirms that the inconsistent operations are not recovered in the current function or the callers, so they constitute bugs.
Note that, as a bug found by static analysis, it can be a false positive or hard to trigger. Multiple researchers have cross-reviewed the bug.
Builds with CONFIG_MLX4_EN=m show no new warnings, and our static analyzer no longer warns about this code.(CVE-2021-47541)
In the Linux kernel, the following vulnerability has been resolved:
net: qlogic: qlcnic: Fix a NULL pointer dereference in qlcnic_83xx_add_rings()
In qlcnic_83xx_add_rings(), the indirect function of ahw->hw_ops->alloc_mbx_args will be called to allocate memory for cmd.req.arg, and there is a dereference of it in qlcnic_83xx_add_rings(), which could lead to a NULL pointer dereference on failure of the indirect function like qlcnic_83xx_alloc_mbx_args().
Fix this bug by adding a check of alloc_mbx_args(), this patch imitates the logic of mbx_cmd()'s failure handling.
This bug was found by a static analyzer. The analysis employs differential checking to identify inconsistent security operations (e.g., checks or kfrees) between two code paths and confirms that the inconsistent operations are not recovered in the current function or the callers, so they constitute bugs.
Note that, as a bug found by static analysis, it can be a false positive or hard to trigger. Multiple researchers have cross-reviewed the bug.
Builds with CONFIG_QLCNIC=m show no new warnings, and our static analyzer no longer warns about this code.(CVE-2021-47542)
Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2021-47543)
In the Linux kernel, the following vulnerability has been resolved:
tcp: fix page frag corruption on page fault
Steffen reported a TCP stream corruption for HTTP requests served by the apache web-server using a cifs mount-point and memory mapping the relevant file.
The root cause is quite similar to the one addressed by commit 20eb4f29b602 ("net: fix sk_page_frag() recursion from memory reclaim"). Here the nested access to the task page frag is caused by a page fault on the (mmapped) user-space memory buffer coming from the cifs file.
The page fault handler performs an smb transaction on a different socket, inside the same process context. Since sk->sk_allaction for such socket does not prevent the usage for the task_frag, the nested allocation modify "under the hood" the page frag in use by the outer sendmsg call, corrupting the stream.
The overall relevant stack trace looks like the following:
httpd 78268 [001] 3461630.850950: probe:tcp_sendmsg_locked: ffffffff91461d91 tcp_sendmsg_locked+0x1 ffffffff91462b57 tcp_sendmsg+0x27 ffffffff9139814e sock_sendmsg+0x3e ffffffffc06dfe1d smb_send_kvec+0x28 [...] ffffffffc06cfaf8 cifs_readpages+0x213 ffffffff90e83c4b read_pages+0x6b ffffffff90e83f31 __do_page_cache_readahead+0x1c1 ffffffff90e79e98 filemap_fault+0x788 ffffffff90eb0458 __do_fault+0x38 ffffffff90eb5280 do_fault+0x1a0 ffffffff90eb7c84 __handle_mm_fault+0x4d4 ffffffff90eb8093 handle_mm_fault+0xc3 ffffffff90c74f6d __do_page_fault+0x1ed ffffffff90c75277 do_page_fault+0x37 ffffffff9160111e page_fault+0x1e ffffffff9109e7b5 copyin+0x25 ffffffff9109eb40 _copy_from_iter_full+0xe0 ffffffff91462370 tcp_sendmsg_locked+0x5e0 ffffffff91462370 tcp_sendmsg_locked+0x5e0 ffffffff91462b57 tcp_sendmsg+0x27 ffffffff9139815c sock_sendmsg+0x4c ffffffff913981f7 sock_write_iter+0x97 ffffffff90f2cc56 do_iter_readv_writev+0x156 ffffffff90f2dff0 do_iter_write+0x80 ffffffff90f2e1c3 vfs_writev+0xa3 ffffffff90f2e27c do_writev+0x5c ffffffff90c042bb do_syscall_64+0x5b ffffffff916000ad entry_SYSCALL_64_after_hwframe+0x65
The cifs filesystem rightfully sets sk_allocations to GFP_NOFS, we can avoid the nesting using the sk page frag for allocation lacking the __GFP_FS flag. Do not define an additional mm-helper for that, as this is strictly tied to the sk page frag usage.
v1 -> v2: - use a stricted sk_page_frag() check instead of reordering the code (Eric)(CVE-2021-47544)
In the Linux kernel, the following vulnerability has been resolved:
net: tulip: de4x5: fix the problem that the array 'lp->phy[8]' may be out of bound
In line 5001, if all id in the array 'lp->phy[8]' is not 0, when the 'for' end, the 'k' is 8.
At this time, the array 'lp->phy[8]' may be out of bound.(CVE-2021-47547)
In the Linux kernel, the following vulnerability has been resolved:
powerpc/powernv: Add a null pointer check in opal_event_init()
kasprintf() returns a pointer to dynamically allocated memory which can be NULL upon failure.(CVE-2023-52686)
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix underflow in second superblock position calculations
Macro NILFS_SB2_OFFSET_BYTES, which computes the position of the second superblock, underflows when the argument device size is less than 4096 bytes. Therefore, when using this macro, it is necessary to check in advance that the device size is not less than a lower limit, or at least that underflow does not occur.
The current nilfs2 implementation lacks this check, causing out-of-bound block access when mounting devices smaller than 4096 bytes:
I/O error, dev loop0, sector 36028797018963960 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2 NILFS (loop0): unable to read secondary superblock (blocksize = 1024)
In addition, when trying to resize the filesystem to a size below 4096 bytes, this underflow occurs in nilfs_resize_fs(), passing a huge number of segments to nilfs_sufile_resize(), corrupting parameters such as the number of segments in superblocks. This causes excessive loop iterations in nilfs_sufile_resize() during a subsequent resize ioctl, causing semaphore ns_segctor_sem to block for a long time and hang the writer thread:
INFO: task segctord:5067 blocked for more than 143 seconds. Not tainted 6.2.0-rc8-syzkaller-00015-gf6feea56f66d #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:segctord state:D stack:23456 pid:5067 ppid:2 flags:0x00004000 Call Trace: <TASK> context_switch kernel/sched/core.c:5293 [inline] __schedule+0x1409/0x43f0 kernel/sched/core.c:6606 schedule+0xc3/0x190 kernel/sched/core.c:6682 rwsem_down_write_slowpath+0xfcf/0x14a0 kernel/locking/rwsem.c:1190 nilfs_transaction_lock+0x25c/0x4f0 fs/nilfs2/segment.c:357 nilfs_segctor_thread_construct fs/nilfs2/segment.c:2486 [inline] nilfs_segctor_thread+0x52f/0x1140 fs/nilfs2/segment.c:2570 kthread+0x270/0x300 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308 </TASK> ... Call Trace: <TASK> folio_mark_accessed+0x51c/0xf00 mm/swap.c:515 __nilfs_get_page_block fs/nilfs2/page.c:42 [inline] nilfs_grab_buffer+0x3d3/0x540 fs/nilfs2/page.c:61 nilfs_mdt_submit_block+0xd7/0x8f0 fs/nilfs2/mdt.c:121 nilfs_mdt_read_block+0xeb/0x430 fs/nilfs2/mdt.c:176 nilfs_mdt_get_block+0x12d/0xbb0 fs/nilfs2/mdt.c:251 nilfs_sufile_get_segment_usage_block fs/nilfs2/sufile.c:92 [inline] nilfs_sufile_truncate_range fs/nilfs2/sufile.c:679 [inline] nilfs_sufile_resize+0x7a3/0x12b0 fs/nilfs2/sufile.c:777 nilfs_resize_fs+0x20c/0xed0 fs/nilfs2/super.c:422 nilfs_ioctl_resize fs/nilfs2/ioctl.c:1033 [inline] nilfs_ioctl+0x137c/0x2440 fs/nilfs2/ioctl.c:1301 ...
This fixes these issues by inserting appropriate minimum device size checks or anti-underflow checks, depending on where the macro is used.(CVE-2023-52705)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Avoid NULL dereference of timing generator
[Why & How] Check whether assigned timing generator is NULL or not before accessing its funcs to prevent NULL dereference.(CVE-2023-52753)
In the Linux kernel, the following vulnerability has been resolved:
media: imon: fix access to invalid resource for the second interface
imon driver probes two USB interfaces, and at the probe of the second interface, the driver assumes blindly that the first interface got bound with the same imon driver. It's usually true, but it's still possible that the first interface is bound with another driver via a malformed descriptor. Then it may lead to a memory corruption, as spotted by syzkaller; imon driver accesses the data from drvdata as struct imon_context object although it's a completely different one that was assigned by another driver.
This patch adds a sanity check -- whether the first interface is really bound with the imon driver or not -- for avoiding the problem above at the probe time.(CVE-2023-52754)
Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2023-52756)
In the Linux kernel, the following vulnerability has been resolved:
s390/dasd: protect device queue against concurrent access
In dasd_profile_start() the amount of requests on the device queue are counted. The access to the device queue is unprotected against concurrent access. With a lot of parallel I/O, especially with alias devices enabled, the device queue can change while dasd_profile_start() is accessing the queue. In the worst case this leads to a kernel panic due to incorrect pointer accesses.
Fix this by taking the device lock before accessing the queue and counting the requests. Additionally the check for a valid profile data pointer can be done earlier to avoid unnecessary locking in a hot path.(CVE-2023-52774)
In the Linux kernel, the following vulnerability has been resolved:
SUNRPC: Fix RPC client cleaned up the freed pipefs dentries
RPC client pipefs dentries cleanup is in separated rpc_remove_pipedir() workqueue,which takes care about pipefs superblock locking. In some special scenarios, when kernel frees the pipefs sb of the current client and immediately alloctes a new pipefs sb, rpc_remove_pipedir function would misjudge the existence of pipefs sb which is not the one it used to hold. As a result, the rpc_remove_pipedir would clean the released freed pipefs dentries.
To fix this issue, rpc_remove_pipedir should check whether the current pipefs sb is consistent with the original pipefs sb.
This error can be catched by KASAN:
[ 250.497700] BUG: KASAN: slab-use-after-free in dget_parent+0x195/0x200 [ 250.498315] Read of size 4 at addr ffff88800a2ab804 by task kworker/0:18/106503 [ 250.500549] Workqueue: events rpc_free_client_work [ 250.501001] Call Trace: [ 250.502880] kasan_report+0xb6/0xf0 [ 250.503209] ? dget_parent+0x195/0x200 [ 250.503561] dget_parent+0x195/0x200 [ 250.503897] ? __pfx_rpc_clntdir_depopulate+0x10/0x10 [ 250.504384] rpc_rmdir_depopulate+0x1b/0x90 [ 250.504781] rpc_remove_client_dir+0xf5/0x150 [ 250.505195] rpc_free_client_work+0xe4/0x230 [ 250.505598] process_one_work+0x8ee/0x13b0 ... [ 22.039056] Allocated by task 244: [ 22.039390] kasan_save_stack+0x22/0x50 [ 22.039758] kasan_set_track+0x25/0x30 [ 22.040109] __kasan_slab_alloc+0x59/0x70 [ 22.040487] kmem_cache_alloc_lru+0xf0/0x240 [ 22.040889] __d_alloc+0x31/0x8e0 [ 22.041207] d_alloc+0x44/0x1f0 [ 22.041514] __rpc_lookup_create_exclusive+0x11c/0x140 [ 22.041987] rpc_mkdir_populate.constprop.0+0x5f/0x110 [ 22.042459] rpc_create_client_dir+0x34/0x150 [ 22.042874] rpc_setup_pipedir_sb+0x102/0x1c0 [ 22.043284] rpc_client_register+0x136/0x4e0 [ 22.043689] rpc_new_client+0x911/0x1020 [ 22.044057] rpc_create_xprt+0xcb/0x370 [ 22.044417] rpc_create+0x36b/0x6c0 ... [ 22.049524] Freed by task 0: [ 22.049803] kasan_save_stack+0x22/0x50 [ 22.050165] kasan_set_track+0x25/0x30 [ 22.050520] kasan_save_free_info+0x2b/0x50 [ 22.050921] __kasan_slab_free+0x10e/0x1a0 [ 22.051306] kmem_cache_free+0xa5/0x390 [ 22.051667] rcu_core+0x62c/0x1930 [ 22.051995] __do_softirq+0x165/0x52a [ 22.052347] [ 22.052503] Last potentially related work creation: [ 22.052952] kasan_save_stack+0x22/0x50 [ 22.053313] __kasan_record_aux_stack+0x8e/0xa0 [ 22.053739] __call_rcu_common.constprop.0+0x6b/0x8b0 [ 22.054209] dentry_free+0xb2/0x140 [ 22.054540] __dentry_kill+0x3be/0x540 [ 22.054900] shrink_dentry_list+0x199/0x510 [ 22.055293] shrink_dcache_parent+0x190/0x240 [ 22.055703] do_one_tree+0x11/0x40 [ 22.056028] shrink_dcache_for_umount+0x61/0x140 [ 22.056461] generic_shutdown_super+0x70/0x590 [ 22.056879] kill_anon_super+0x3a/0x60 [ 22.057234] rpc_kill_sb+0x121/0x200(CVE-2023-52803)
In the Linux kernel, the following vulnerability has been resolved:
platform/x86: wmi: Fix opening of char device
Since commit fa1f68db6ca7 ("drivers: misc: pass miscdevice pointer via file private data"), the miscdevice stores a pointer to itself inside filp->private_data, which means that private_data will not be NULL when wmi_char_open() is called. This might cause memory corruption should wmi_char_open() be unable to find its driver, something which can happen when the associated WMI device is deleted in wmi_free_devices().
Fix the problem by using the miscdevice pointer to retrieve the WMI device data associated with a char device using container_of(). This also avoids wmi_char_open() picking a wrong WMI device bound to a driver with the same name as the original driver.(CVE-2023-52864)
In the Linux kernel, the following vulnerability has been resolved:
clk: mediatek: clk-mt6797: Add check for mtk_alloc_clk_data
Add the check for the return value of mtk_alloc_clk_data() in order to avoid NULL pointer dereference.(CVE-2023-52865)
In the Linux kernel, the following vulnerability has been resolved:
soc: qcom: llcc: Handle a second device without data corruption
Usually there is only one llcc device. But if there were a second, even a failed probe call would modify the global drv_data pointer. So check if drv_data is valid before overwriting it.(CVE-2023-52871)
In the Linux kernel, the following vulnerability has been resolved:
efi/capsule-loader: fix incorrect allocation size
gcc-14 notices that the allocation with sizeof(void) on 32-bit architectures is not enough for a 64-bit phys_addr_t:
drivers/firmware/efi/capsule-loader.c: In function 'efi_capsule_open': drivers/firmware/efi/capsule-loader.c:295:24: error: allocation of insufficient size '4' for type 'phys_addr_t' {aka 'long long unsigned int'} with size '8' [-Werror=alloc-size] 295 | cap_info->phys = kzalloc(sizeof(void *), GFP_KERNEL); | ^
Use the correct type instead here.(CVE-2024-27413)
In the Linux kernel, the following vulnerability has been resolved:
PCI/PM: Drain runtime-idle callbacks before driver removal
A race condition between the .runtime_idle() callback and the .remove() callback in the rtsx_pcr PCI driver leads to a kernel crash due to an unhandled page fault [1].
The problem is that rtsx_pci_runtime_idle() is not expected to be running after pm_runtime_get_sync() has been called, but the latter doesn't really guarantee that. It only guarantees that the suspend and resume callbacks will not be running when it returns.
However, if a .runtime_idle() callback is already running when pm_runtime_get_sync() is called, the latter will notice that the runtime PM status of the device is RPM_ACTIVE and it will return right away without waiting for the former to complete. In fact, it cannot wait for .runtime_idle() to complete because it may be called from that callback (it arguably does not make much sense to do that, but it is not strictly prohibited).
Thus in general, whoever is providing a .runtime_idle() callback needs to protect it from running in parallel with whatever code runs after pm_runtime_get_sync(). [Note that .runtime_idle() will not start after pm_runtime_get_sync() has returned, but it may continue running then if it has started earlier.]
One way to address that race condition is to call pm_runtime_barrier() after pm_runtime_get_sync() (not before it, because a nonzero value of the runtime PM usage counter is necessary to prevent runtime PM callbacks from being invoked) to wait for the .runtime_idle() callback to complete should it be running at that point. A suitable place for doing that is in pci_device_remove() which calls pm_runtime_get_sync() before removing the driver, so it may as well call pm_runtime_barrier() subsequently, which will prevent the race in question from occurring, not just in the rtsx_pcr driver, but in any PCI drivers providing .runtime_idle() callbacks.(CVE-2024-35809)
In the Linux kernel, the following vulnerability has been resolved:
wifi: brcmfmac: Fix use-after-free bug in brcmf_cfg80211_detach
This is the candidate patch of CVE-2023-47233 : https://nvd.nist.gov/vuln/detail/CVE-2023-47233
In brcm80211 driver,it starts with the following invoking chain to start init a timeout worker:
->brcmf_usb_probe ->brcmf_usb_probe_cb ->brcmf_attach ->brcmf_bus_started ->brcmf_cfg80211_attach ->wl_init_priv ->brcmf_init_escan ->INIT_WORK(&cfg->escan_timeout_work, brcmf_cfg80211_escan_timeout_worker);
If we disconnect the USB by hotplug, it will call brcmf_usb_disconnect to make cleanup. The invoking chain is :
brcmf_usb_disconnect ->brcmf_usb_disconnect_cb ->brcmf_detach ->brcmf_cfg80211_detach ->kfree(cfg);
While the timeout woker may still be running. This will cause a use-after-free bug on cfg in brcmf_cfg80211_escan_timeout_worker.
Fix it by deleting the timer and canceling the worker in brcmf_cfg80211_detach.
arend.vanspriel@broadcom.com: keep timer delete as is and cancel work just before free
In the Linux kernel, the following vulnerability has been resolved:
erspan: make sure erspan_base_hdr is present in skb->head
syzbot reported a problem in ip6erspan_rcv() [1]
Issue is that ip6erspan_rcv() (and erspan_rcv()) no longer make sure erspan_base_hdr is present in skb linear part (skb->head) before getting @ver field from it.
Add the missing pskb_may_pull() calls.
v2: Reload iph pointer in erspan_rcv() after pskb_may_pull() because skb->head might have changed.
[1]
BUG: KMSAN: uninit-value in pskb_may_pull_reason include/linux/skbuff.h:2742 [inline] BUG: KMSAN: uninit-value in pskb_may_pull include/linux/skbuff.h:2756 [inline] BUG: KMSAN: uninit-value in ip6erspan_rcv net/ipv6/ip6_gre.c:541 [inline] BUG: KMSAN: uninit-value in gre_rcv+0x11f8/0x1930 net/ipv6/ip6_gre.c:610 pskb_may_pull_reason include/linux/skbuff.h:2742 [inline] pskb_may_pull include/linux/skbuff.h:2756 [inline] ip6erspan_rcv net/ipv6/ip6_gre.c:541 [inline] gre_rcv+0x11f8/0x1930 net/ipv6/ip6_gre.c:610 ip6_protocol_deliver_rcu+0x1d4c/0x2ca0 net/ipv6/ip6_input.c:438 ip6_input_finish net/ipv6/ip6_input.c:483 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] ip6_input+0x15d/0x430 net/ipv6/ip6_input.c:492 ip6_mc_input+0xa7e/0xc80 net/ipv6/ip6_input.c:586 dst_input include/net/dst.h:460 [inline] ip6_rcv_finish+0x955/0x970 net/ipv6/ip6_input.c:79 NF_HOOK include/linux/netfilter.h:314 [inline] ipv6_rcv+0xde/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core net/core/dev.c:5538 [inline] __netif_receive_skb+0x1da/0xa00 net/core/dev.c:5652 netif_receive_skb_internal net/core/dev.c:5738 [inline] netif_receive_skb+0x58/0x660 net/core/dev.c:5798 tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1549 tun_get_user+0x5566/0x69e0 drivers/net/tun.c:2002 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048 call_write_iter include/linux/fs.h:2108 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0xb63/0x1520 fs/read_write.c:590 ksys_write+0x20f/0x4c0 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __x64_sys_write+0x93/0xe0 fs/read_write.c:652 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75
Uninit was created at: slab_post_alloc_hook mm/slub.c:3804 [inline] slab_alloc_node mm/slub.c:3845 [inline] kmem_cache_alloc_node+0x613/0xc50 mm/slub.c:3888 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:577 __alloc_skb+0x35b/0x7a0 net/core/skbuff.c:668 alloc_skb include/linux/skbuff.h:1318 [inline] alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6504 sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2795 tun_alloc_skb drivers/net/tun.c:1525 [inline] tun_get_user+0x209a/0x69e0 drivers/net/tun.c:1846 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048 call_write_iter include/linux/fs.h:2108 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0xb63/0x1520 fs/read_write.c:590 ksys_write+0x20f/0x4c0 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __x64_sys_write+0x93/0xe0 fs/read_write.c:652 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75
CPU: 1 PID: 5045 Comm: syz-executor114 Not tainted 6.9.0-rc1-syzkaller-00021-g962490525cff #0(CVE-2024-35888)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: validate user input for expected length
I got multiple syzbot reports showing old bugs exposed by BPF after commit 20f2505fb436 ("bpf: Try to avoid kzalloc in cgroup/{s,g}etsockopt")
setsockopt() @optlen argument should be taken into account before copying data.
BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline] BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline] BUG: KASAN: slab-out-of-bounds in do_replace net/ipv4/netfilter/ip_tables.c:1111 [inline] BUG: KASAN: slab-out-of-bounds in do_ipt_set_ctl+0x902/0x3dd0 net/ipv4/netfilter/ip_tables.c:1627 Read of size 96 at addr ffff88802cd73da0 by task syz-executor.4/7238
CPU: 1 PID: 7238 Comm: syz-executor.4 Not tainted 6.9.0-rc2-next-20240403-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 kasan_check_range+0x282/0x290 mm/kasan/generic.c:189 __asan_memcpy+0x29/0x70 mm/kasan/shadow.c:105 copy_from_sockptr_offset include/linux/sockptr.h:49 [inline] copy_from_sockptr include/linux/sockptr.h:55 [inline] do_replace net/ipv4/netfilter/ip_tables.c:1111 [inline] do_ipt_set_ctl+0x902/0x3dd0 net/ipv4/netfilter/ip_tables.c:1627 nf_setsockopt+0x295/0x2c0 net/netfilter/nf_sockopt.c:101 do_sock_setsockopt+0x3af/0x720 net/socket.c:2311 __sys_setsockopt+0x1ae/0x250 net/socket.c:2334 __do_sys_setsockopt net/socket.c:2343 [inline] __se_sys_setsockopt net/socket.c:2340 [inline] __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340 do_syscall_64+0xfb/0x240 entry_SYSCALL_64_after_hwframe+0x72/0x7a RIP: 0033:0x7fd22067dde9 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fd21f9ff0c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000036 RAX: ffffffffffffffda RBX: 00007fd2207abf80 RCX: 00007fd22067dde9 RDX: 0000000000000040 RSI: 0000000000000000 RDI: 0000000000000003 RBP: 00007fd2206ca47a R08: 0000000000000001 R09: 0000000000000000 R10: 0000000020000880 R11: 0000000000000246 R12: 0000000000000000 R13: 000000000000000b R14: 00007fd2207abf80 R15: 00007ffd2d0170d8 </TASK>
Allocated by task 7238: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:370 [inline] __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:387 kasan_kmalloc include/linux/kasan.h:211 [inline] __do_kmalloc_node mm/slub.c:4069 [inline] __kmalloc_noprof+0x200/0x410 mm/slub.c:4082 kmalloc_noprof include/linux/slab.h:664 [inline] __cgroup_bpf_run_filter_setsockopt+0xd47/0x1050 kernel/bpf/cgroup.c:1869 do_sock_setsockopt+0x6b4/0x720 net/socket.c:2293 __sys_setsockopt+0x1ae/0x250 net/socket.c:2334 __do_sys_setsockopt net/socket.c:2343 [inline] __se_sys_setsockopt net/socket.c:2340 [inline] __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340 do_syscall_64+0xfb/0x240 entry_SYSCALL_64_after_hwframe+0x72/0x7a
The buggy address belongs to the object at ffff88802cd73da0 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes inside of allocated 1-byte region [ffff88802cd73da0, ffff88802cd73da1)
The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff88802cd73020 pfn:0x2cd73 flags: 0xfff80000000000(node=0|zone=1|lastcpupid=0xfff) page_type: 0xffffefff(slab) raw: 00fff80000000000 ffff888015041280 dead000000000100 dead000000000122 raw: ffff88802cd73020 000000008080007f 00000001ffffefff 00 ---truncated---(CVE-2024-35896)
In the Linux kernel, the following vulnerability has been resolved:
i2c: smbus: fix NULL function pointer dereference
Baruch reported an OOPS when using the designware controller as target only. Target-only modes break the assumption of one transfer function always being available. Fix this by always checking the pointer in __i2c_transfer.
wsa: dropped the simplification in core-smbus to avoid theoretical regressions
In the Linux kernel, the following vulnerability has been resolved:
rtnetlink: Correct nested IFLA_VF_VLAN_LIST attribute validation
Each attribute inside a nested IFLA_VF_VLAN_LIST is assumed to be a struct ifla_vf_vlan_info so the size of such attribute needs to be at least of sizeof(struct ifla_vf_vlan_info) which is 14 bytes. The current size validation in do_setvfinfo is against NLA_HDRLEN (4 bytes) which is less than sizeof(struct ifla_vf_vlan_info) so this validation is not enough and a too small attribute might be cast to a struct ifla_vf_vlan_info, this might result in an out of bands read access when accessing the saved (casted) entry in ivvl.(CVE-2024-36017)
In the Linux kernel, the following vulnerability has been resolved:
mmc: sdhci-msm: pervent access to suspended controller
Generic sdhci code registers LED device and uses host->runtime_suspended flag to protect access to it. The sdhci-msm driver doesn't set this flag, which causes a crash when LED is accessed while controller is runtime suspended. Fix this by setting the flag correctly.(CVE-2024-36029)
In the Linux kernel, the following vulnerability has been resolved:
net: fix out-of-bounds access in ops_init
net_alloc_generic is called by net_alloc, which is called without any locking. It reads max_gen_ptrs, which is changed under pernet_ops_rwsem. It is read twice, first to allocate an array, then to set s.len, which is later used to limit the bounds of the array access.
It is possible that the array is allocated and another thread is registering a new pernet ops, increments max_gen_ptrs, which is then used to set s.len with a larger than allocated length for the variable array.
Fix it by reading max_gen_ptrs only once in net_alloc_generic. If max_gen_ptrs is later incremented, it will be caught in net_assign_generic.(CVE-2024-36883)
In the Linux kernel, the following vulnerability has been resolved:
ipv6: fib6_rules: avoid possible NULL dereference in fib6_rule_action()
syzbot is able to trigger the following crash [1], caused by unsafe ip6_dst_idev() use.
Indeed ip6_dst_idev() can return NULL, and must always be checked.
[1]
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 0 PID: 31648 Comm: syz-executor.0 Not tainted 6.9.0-rc4-next-20240417-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 RIP: 0010:__fib6_rule_action net/ipv6/fib6_rules.c:237 [inline] RIP: 0010:fib6_rule_action+0x241/0x7b0 net/ipv6/fib6_rules.c:267 Code: 02 00 00 49 8d 9f d8 00 00 00 48 89 d8 48 c1 e8 03 42 80 3c 20 00 74 08 48 89 df e8 f9 32 bf f7 48 8b 1b 48 89 d8 48 c1 e8 03 <42> 80 3c 20 00 74 08 48 89 df e8 e0 32 bf f7 4c 8b 03 48 89 ef 4c RSP: 0018:ffffc9000fc1f2f0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 1a772f98c8186700 RDX: 0000000000000003 RSI: ffffffff8bcac4e0 RDI: ffffffff8c1f9760 RBP: ffff8880673fb980 R08: ffffffff8fac15ef R09: 1ffffffff1f582bd R10: dffffc0000000000 R11: fffffbfff1f582be R12: dffffc0000000000 R13: 0000000000000080 R14: ffff888076509000 R15: ffff88807a029a00 FS: 00007f55e82ca6c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b31d23000 CR3: 0000000022b66000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> fib_rules_lookup+0x62c/0xdb0 net/core/fib_rules.c:317 fib6_rule_lookup+0x1fd/0x790 net/ipv6/fib6_rules.c:108 ip6_route_output_flags_noref net/ipv6/route.c:2637 [inline] ip6_route_output_flags+0x38e/0x610 net/ipv6/route.c:2649 ip6_route_output include/net/ip6_route.h:93 [inline] ip6_dst_lookup_tail+0x189/0x11a0 net/ipv6/ip6_output.c:1120 ip6_dst_lookup_flow+0xb9/0x180 net/ipv6/ip6_output.c:1250 sctp_v6_get_dst+0x792/0x1e20 net/sctp/ipv6.c:326 sctp_transport_route+0x12c/0x2e0 net/sctp/transport.c:455 sctp_assoc_add_peer+0x614/0x15c0 net/sctp/associola.c:662 sctp_connect_new_asoc+0x31d/0x6c0 net/sctp/socket.c:1099 __sctp_connect+0x66d/0xe30 net/sctp/socket.c:1197 sctp_connect net/sctp/socket.c:4819 [inline] sctp_inet_connect+0x149/0x1f0 net/sctp/socket.c:4834 __sys_connect_file net/socket.c:2048 [inline] __sys_connect+0x2df/0x310 net/socket.c:2065 __do_sys_connect net/socket.c:2075 [inline] __se_sys_connect net/socket.c:2072 [inline] __x64_sys_connect+0x7a/0x90 net/socket.c:2072 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2024-36902)
In the Linux kernel, the following vulnerability has been resolved:
ipv6: Fix potential uninit-value access in __ip6_make_skb()
As it was done in commit fc1092f51567 ("ipv4: Fix uninit-value access in __ip_make_skb()") for IPv4, check FLOWI_FLAG_KNOWN_NH on fl6->flowi6_flags instead of testing HDRINCL on the socket to avoid a race condition which causes uninit-value access.(CVE-2024-36903)
In the Linux kernel, the following vulnerability has been resolved:
block: fix overflow in blk_ioctl_discard()
There is no check for overflow of 'start + len' in blk_ioctl_discard(). Hung task occurs if submit an discard ioctl with the following param: start = 0x80000000000ff000, len = 0x8000000000fff000; Add the overflow validation now.(CVE-2024-36917)
In the Linux kernel, the following vulnerability has been resolved:
scsi: lpfc: Release hbalock before calling lpfc_worker_wake_up()
lpfc_worker_wake_up() calls the lpfc_work_done() routine, which takes the hbalock. Thus, lpfc_worker_wake_up() should not be called while holding the hbalock to avoid potential deadlock.(CVE-2024-36924)
In the Linux kernel, the following vulnerability has been resolved:
tipc: fix a possible memleak in tipc_buf_append
__skb_linearize() doesn't free the skb when it fails, so move '*buf = NULL' after __skb_linearize(), so that the skb can be freed on the err path.(CVE-2024-36954)
In the Linux kernel, the following vulnerability has been resolved:
fs/9p: only translate RWX permissions for plain 9P2000
Garbage in plain 9P2000's perm bits is allowed through, which causes it to be able to set (among others) the suid bit. This was presumably not the intent since the unix extended bits are handled explicitly and conditionally on .u.(CVE-2024-36964)
| URL | Type | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"python2-perf-4.19.90-2406.2.0.0281.oe2003sp4.aarch64.rpm",
"kernel-tools-4.19.90-2406.2.0.0281.oe2003sp4.aarch64.rpm",
"bpftool-4.19.90-2406.2.0.0281.oe2003sp4.aarch64.rpm",
"kernel-devel-4.19.90-2406.2.0.0281.oe2003sp4.aarch64.rpm",
"kernel-tools-devel-4.19.90-2406.2.0.0281.oe2003sp4.aarch64.rpm",
"kernel-4.19.90-2406.2.0.0281.oe2003sp4.aarch64.rpm",
"perf-4.19.90-2406.2.0.0281.oe2003sp4.aarch64.rpm",
"kernel-debugsource-4.19.90-2406.2.0.0281.oe2003sp4.aarch64.rpm",
"kernel-source-4.19.90-2406.2.0.0281.oe2003sp4.aarch64.rpm",
"bpftool-debuginfo-4.19.90-2406.2.0.0281.oe2003sp4.aarch64.rpm",
"kernel-debuginfo-4.19.90-2406.2.0.0281.oe2003sp4.aarch64.rpm",
"python3-perf-debuginfo-4.19.90-2406.2.0.0281.oe2003sp4.aarch64.rpm",
"kernel-tools-debuginfo-4.19.90-2406.2.0.0281.oe2003sp4.aarch64.rpm",
"python3-perf-4.19.90-2406.2.0.0281.oe2003sp4.aarch64.rpm",
"python2-perf-debuginfo-4.19.90-2406.2.0.0281.oe2003sp4.aarch64.rpm",
"perf-debuginfo-4.19.90-2406.2.0.0281.oe2003sp4.aarch64.rpm"
],
"src": [
"kernel-4.19.90-2406.2.0.0281.oe2003sp4.src.rpm"
],
"x86_64": [
"bpftool-4.19.90-2406.2.0.0281.oe2003sp4.x86_64.rpm",
"kernel-4.19.90-2406.2.0.0281.oe2003sp4.x86_64.rpm",
"perf-4.19.90-2406.2.0.0281.oe2003sp4.x86_64.rpm",
"kernel-source-4.19.90-2406.2.0.0281.oe2003sp4.x86_64.rpm",
"python3-perf-debuginfo-4.19.90-2406.2.0.0281.oe2003sp4.x86_64.rpm",
"python2-perf-4.19.90-2406.2.0.0281.oe2003sp4.x86_64.rpm",
"kernel-tools-4.19.90-2406.2.0.0281.oe2003sp4.x86_64.rpm",
"kernel-debuginfo-4.19.90-2406.2.0.0281.oe2003sp4.x86_64.rpm",
"python3-perf-4.19.90-2406.2.0.0281.oe2003sp4.x86_64.rpm",
"kernel-devel-4.19.90-2406.2.0.0281.oe2003sp4.x86_64.rpm",
"kernel-tools-devel-4.19.90-2406.2.0.0281.oe2003sp4.x86_64.rpm",
"kernel-tools-debuginfo-4.19.90-2406.2.0.0281.oe2003sp4.x86_64.rpm",
"perf-debuginfo-4.19.90-2406.2.0.0281.oe2003sp4.x86_64.rpm",
"kernel-debugsource-4.19.90-2406.2.0.0281.oe2003sp4.x86_64.rpm",
"python2-perf-debuginfo-4.19.90-2406.2.0.0281.oe2003sp4.x86_64.rpm",
"bpftool-debuginfo-4.19.90-2406.2.0.0281.oe2003sp4.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:20.03-LTS-SP4",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-20.03-LTS-SP4"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.19.90-2406.2.0.0281.oe2003sp4"
}
],
"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: cdc_eem: fix tx fixup skb leak\r\n\r\nwhen usbnet transmit a skb, eem fixup it in eem_tx_fixup(),\nif skb_copy_expand() failed, it return NULL,\nusbnet_start_xmit() will have no chance to free original skb.\r\n\r\nfix it by free orginal skb in eem_tx_fixup() first,\nthen check skb clone status, if failed, return NULL to usbnet.(CVE-2021-47236)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ngfs2: Fix use-after-free in gfs2_glock_shrink_scan\r\n\r\nThe GLF_LRU flag is checked under lru_lock in gfs2_glock_remove_from_lru() to\nremove the glock from the lru list in __gfs2_glock_put().\r\n\r\nOn the shrink scan path, the same flag is cleared under lru_lock but because\nof cond_resched_lock(\u0026amp;lru_lock) in gfs2_dispose_glock_lru(), progress on the\nput side can be made without deleting the glock from the lru list.\r\n\r\nKeep GLF_LRU across the race window opened by cond_resched_lock(\u0026amp;lru_lock) to\nensure correct behavior on both sides - clear GLF_LRU after list_del under\nlru_lock.(CVE-2021-47254)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetrom: Decrease sock refcount when sock timers expire\r\n\r\nCommit 63346650c1a9 (\u0026quot;netrom: switch to sock timer API\u0026quot;) switched to use\nsock timer API. It replaces mod_timer() by sk_reset_timer(), and\ndel_timer() by sk_stop_timer().\r\n\r\nFunction sk_reset_timer() will increase the refcount of sock if it is\ncalled on an inactive timer, hence, in case the timer expires, we need to\ndecrease the refcount ourselves in the handler, otherwise, the sock\nrefcount will be unbalanced and the sock will never be freed.(CVE-2021-47294)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmemory: fsl_ifc: fix leak of IO mapping on probe failure\r\n\r\nOn probe error the driver should unmap the IO memory. Smatch reports:\r\n\r\n drivers/memory/fsl_ifc.c:298 fsl_ifc_ctrl_probe() warn: \u0026apos;fsl_ifc_ctrl_dev-\u0026gt;gregs\u0026apos; not released on lines: 298.(CVE-2021-47315)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwatchdog: Fix possible use-after-free in wdt_startup()\r\n\r\nThis module\u0026apos;s remove path calls del_timer(). However, that function\ndoes not wait until the timer handler finishes. This means that the\ntimer handler may still be running after the driver\u0026apos;s remove function\nhas finished, which would result in a use-after-free.\r\n\r\nFix by calling del_timer_sync(), which makes sure the timer handler\nhas finished, and unable to re-schedule itself.(CVE-2021-47324)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: megaraid_sas: Fix resource leak in case of probe failure\r\n\r\nThe driver doesn\u0026apos;t clean up all the allocated resources properly when\nscsi_add_host(), megasas_start_aen() function fails during the PCI device\nprobe.\r\n\r\nClean up all those resources.(CVE-2021-47329)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nipack: ipoctal: fix module reference leak\r\n\r\nA reference to the carrier module was taken on every open but was only\nreleased once when the final reference to the tty struct was dropped.\r\n\r\nFix this by taking the module reference and initialising the tty driver\ndata when installing the tty.(CVE-2021-47403)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: dwc2: check return value after calling platform_get_resource()\r\n\r\nIt will cause null-ptr-deref if platform_get_resource() returns NULL,\nwe need check the return value.(CVE-2021-47409)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ni40e: Fix freeing of uninitialized misc IRQ vector\r\n\r\nWhen VSI set up failed in i40e_probe() as part of PF switch set up\ndriver was trying to free misc IRQ vectors in\ni40e_clear_interrupt_scheme and produced a kernel Oops:\r\n\r\n Trying to free already-free IRQ 266\n WARNING: CPU: 0 PID: 5 at kernel/irq/manage.c:1731 __free_irq+0x9a/0x300\n Workqueue: events work_for_cpu_fn\n RIP: 0010:__free_irq+0x9a/0x300\n Call Trace:\n ? synchronize_irq+0x3a/0xa0\n free_irq+0x2e/0x60\n i40e_clear_interrupt_scheme+0x53/0x190 [i40e]\n i40e_probe.part.108+0x134b/0x1a40 [i40e]\n ? kmem_cache_alloc+0x158/0x1c0\n ? acpi_ut_update_ref_count.part.1+0x8e/0x345\n ? acpi_ut_update_object_reference+0x15e/0x1e2\n ? strstr+0x21/0x70\n ? irq_get_irq_data+0xa/0x20\n ? mp_check_pin_attr+0x13/0xc0\n ? irq_get_irq_data+0xa/0x20\n ? mp_map_pin_to_irq+0xd3/0x2f0\n ? acpi_register_gsi_ioapic+0x93/0x170\n ? pci_conf1_read+0xa4/0x100\n ? pci_bus_read_config_word+0x49/0x70\n ? do_pci_enable_device+0xcc/0x100\n local_pci_probe+0x41/0x90\n work_for_cpu_fn+0x16/0x20\n process_one_work+0x1a7/0x360\n worker_thread+0x1cf/0x390\n ? create_worker+0x1a0/0x1a0\n kthread+0x112/0x130\n ? kthread_flush_work_fn+0x10/0x10\n ret_from_fork+0x1f/0x40\r\n\r\nThe problem is that at that point misc IRQ vectors\nwere not allocated yet and we get a call trace\nthat driver is trying to free already free IRQ vectors.\r\n\r\nAdd a check in i40e_clear_interrupt_scheme for __I40E_MISC_IRQ_REQUESTED\nPF state before calling i40e_free_misc_vector. This state is set only if\nmisc IRQ vectors were properly initialized.(CVE-2021-47424)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nocfs2: fix data corruption after conversion from inline format\r\n\r\nCommit 6dbf7bb55598 (\u0026quot;fs: Don\u0026apos;t invalidate page buffers in\nblock_write_full_page()\u0026quot;) uncovered a latent bug in ocfs2 conversion\nfrom inline inode format to a normal inode format.\r\n\r\nThe code in ocfs2_convert_inline_data_to_extents() attempts to zero out\nthe whole cluster allocated for file data by grabbing, zeroing, and\ndirtying all pages covering this cluster. However these pages are\nbeyond i_size, thus writeback code generally ignores these dirty pages\nand no blocks were ever actually zeroed on the disk.\r\n\r\nThis oversight was fixed by commit 693c241a5f6a (\u0026quot;ocfs2: No need to zero\npages past i_size.\u0026quot;) for standard ocfs2 write path, inline conversion\npath was apparently forgotten; the commit log also has a reasoning why\nthe zeroing actually is not needed.\r\n\r\nAfter commit 6dbf7bb55598, things became worse as writeback code stopped\ninvalidating buffers on pages beyond i_size and thus these pages end up\nwith clean PageDirty bit but with buffers attached to these pages being\nstill dirty. So when a file is converted from inline format, then\nwriteback triggers, and then the file is grown so that these pages\nbecome valid, the invalid dirtiness state is preserved,\nmark_buffer_dirty() does nothing on these pages (buffers are already\ndirty) but page is never written back because it is clean. So data\nwritten to these pages is lost once pages are reclaimed.\r\n\r\nSimple reproducer for the problem is:\r\n\r\n xfs_io -f -c \u0026quot;pwrite 0 2000\u0026quot; -c \u0026quot;pwrite 2000 2000\u0026quot; -c \u0026quot;fsync\u0026quot; \\\n -c \u0026quot;pwrite 4000 2000\u0026quot; ocfs2_file\r\n\r\nAfter unmounting and mounting the fs again, you can observe that end of\n\u0026apos;ocfs2_file\u0026apos; has lost its contents.\r\n\r\nFix the problem by not doing the pointless zeroing during conversion\nfrom inline format similarly as in the standard write path.\r\n\r\n[akpm@linux-foundation.org: fix whitespace, per Joseph](CVE-2021-47460)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncomedi: ni_usb6501: fix NULL-deref in command paths\r\n\r\nThe driver uses endpoint-sized USB transfer buffers but had no sanity\nchecks on the sizes. This can lead to zero-size-pointer dereferences or\noverflowed transfer buffers in ni6501_port_command() and\nni6501_counter_command() if a (malicious) device has smaller max-packet\nsizes than expected (or when doing descriptor fuzz testing).\r\n\r\nAdd the missing sanity checks to probe().(CVE-2021-47476)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nisofs: Fix out of bound access for corrupted isofs image\r\n\r\nWhen isofs image is suitably corrupted isofs_read_inode() can read data\nbeyond the end of buffer. Sanity-check the directory entry length before\nusing it.(CVE-2021-47478)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nstaging: rtl8712: fix use-after-free in rtl8712_dl_fw\r\n\r\nSyzbot reported use-after-free in rtl8712_dl_fw(). The problem was in\nrace condition between r871xu_dev_remove() -\u0026gt;ndo_open() callback.\r\n\r\nIt\u0026apos;s easy to see from crash log, that driver accesses released firmware\nin -\u0026gt;ndo_open() callback. It may happen, since driver was releasing\nfirmware _before_ unregistering netdev. Fix it by moving\nunregister_netdev() before cleaning up resources.\r\n\r\nCall Trace:\n...\n rtl871x_open_fw drivers/staging/rtl8712/hal_init.c:83 [inline]\n rtl8712_dl_fw+0xd95/0xe10 drivers/staging/rtl8712/hal_init.c:170\n rtl8712_hal_init drivers/staging/rtl8712/hal_init.c:330 [inline]\n rtl871x_hal_init+0xae/0x180 drivers/staging/rtl8712/hal_init.c:394\n netdev_open+0xe6/0x6c0 drivers/staging/rtl8712/os_intfs.c:380\n __dev_open+0x2bc/0x4d0 net/core/dev.c:1484\r\n\r\nFreed by task 1306:\n...\n release_firmware+0x1b/0x30 drivers/base/firmware_loader/main.c:1053\n r871xu_dev_remove+0xcc/0x2c0 drivers/staging/rtl8712/usb_intf.c:599\n usb_unbind_interface+0x1d8/0x8d0 drivers/usb/core/driver.c:458(CVE-2021-47479)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\niio: accel: kxcjk-1013: Fix possible memory leak in probe and remove\r\n\r\nWhen ACPI type is ACPI_SMO8500, the data-\u0026gt;dready_trig will not be set, the\nmemory allocated by iio_triggered_buffer_setup() will not be freed, and cause\nmemory leak as follows:\r\n\r\nunreferenced object 0xffff888009551400 (size 512):\n comm \u0026quot;i2c-SMO8500-125\u0026quot;, pid 911, jiffies 4294911787 (age 83.852s)\n hex dump (first 32 bytes):\n 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n 00 00 00 00 00 00 00 00 20 e2 e5 c0 ff ff ff ff ........ .......\n backtrace:\n [\u0026lt;0000000041ce75ee\u0026gt;] kmem_cache_alloc_trace+0x16d/0x360\n [\u0026lt;000000000aeb17b0\u0026gt;] iio_kfifo_allocate+0x41/0x130 [kfifo_buf]\n [\u0026lt;000000004b40c1f5\u0026gt;] iio_triggered_buffer_setup_ext+0x2c/0x210 [industrialio_triggered_buffer]\n [\u0026lt;000000004375b15f\u0026gt;] kxcjk1013_probe+0x10c3/0x1d81 [kxcjk_1013]\r\n\r\nFix it by remove data-\u0026gt;dready_trig condition in probe and remove.(CVE-2021-47499)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nALSA: pcm: oss: Fix negative period/buffer sizes\r\n\r\nThe period size calculation in OSS layer may receive a negative value\nas an error, but the code there assumes only the positive values and\nhandle them with size_t. Due to that, a too big value may be passed\nto the lower layers.\r\n\r\nThis patch changes the code to handle with ssize_t and adds the proper\nerror checks appropriately.(CVE-2021-47511)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnfc: fix potential NULL pointer deref in nfc_genl_dump_ses_done\r\n\r\nThe done() netlink callback nfc_genl_dump_ses_done() should check if\nreceived argument is non-NULL, because its allocation could fail earlier\nin dumpit() (nfc_genl_dump_ses()).(CVE-2021-47518)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nrxrpc: Fix rxrpc_local leak in rxrpc_lookup_peer()\r\n\r\nNeed to call rxrpc_put_local() for peer candidate before kfree() as it\nholds a ref to rxrpc_local.\r\n\r\n[DH: v2: Changed to abstract the peer freeing code out into a function](CVE-2021-47538)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/mlx4_en: Fix an use-after-free bug in mlx4_en_try_alloc_resources()\r\n\r\nIn mlx4_en_try_alloc_resources(), mlx4_en_copy_priv() is called and\ntmp-\u0026gt;tx_cq will be freed on the error path of mlx4_en_copy_priv().\nAfter that mlx4_en_alloc_resources() is called and there is a dereference\nof \u0026amp;tmp-\u0026gt;tx_cq[t][i] in mlx4_en_alloc_resources(), which could lead to\na use after free problem on failure of mlx4_en_copy_priv().\r\n\r\nFix this bug by adding a check of mlx4_en_copy_priv()\r\n\r\nThis bug was found by a static analyzer. The analysis employs\ndifferential checking to identify inconsistent security operations\n(e.g., checks or kfrees) between two code paths and confirms that the\ninconsistent operations are not recovered in the current function or\nthe callers, so they constitute bugs.\r\n\r\nNote that, as a bug found by static analysis, it can be a false\npositive or hard to trigger. Multiple researchers have cross-reviewed\nthe bug.\r\n\r\nBuilds with CONFIG_MLX4_EN=m show no new warnings,\nand our static analyzer no longer warns about this code.(CVE-2021-47541)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: qlogic: qlcnic: Fix a NULL pointer dereference in qlcnic_83xx_add_rings()\r\n\r\nIn qlcnic_83xx_add_rings(), the indirect function of\nahw-\u0026gt;hw_ops-\u0026gt;alloc_mbx_args will be called to allocate memory for\ncmd.req.arg, and there is a dereference of it in qlcnic_83xx_add_rings(),\nwhich could lead to a NULL pointer dereference on failure of the\nindirect function like qlcnic_83xx_alloc_mbx_args().\r\n\r\nFix this bug by adding a check of alloc_mbx_args(), this patch\nimitates the logic of mbx_cmd()\u0026apos;s failure handling.\r\n\r\nThis bug was found by a static analyzer. The analysis employs\ndifferential checking to identify inconsistent security operations\n(e.g., checks or kfrees) between two code paths and confirms that the\ninconsistent operations are not recovered in the current function or\nthe callers, so they constitute bugs.\r\n\r\nNote that, as a bug found by static analysis, it can be a false\npositive or hard to trigger. Multiple researchers have cross-reviewed\nthe bug.\r\n\r\nBuilds with CONFIG_QLCNIC=m show no new warnings, and our\nstatic analyzer no longer warns about this code.(CVE-2021-47542)\r\n\r\nRejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2021-47543)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntcp: fix page frag corruption on page fault\r\n\r\nSteffen reported a TCP stream corruption for HTTP requests\nserved by the apache web-server using a cifs mount-point\nand memory mapping the relevant file.\r\n\r\nThe root cause is quite similar to the one addressed by\ncommit 20eb4f29b602 (\u0026quot;net: fix sk_page_frag() recursion from\nmemory reclaim\u0026quot;). Here the nested access to the task page frag\nis caused by a page fault on the (mmapped) user-space memory\nbuffer coming from the cifs file.\r\n\r\nThe page fault handler performs an smb transaction on a different\nsocket, inside the same process context. Since sk-\u0026gt;sk_allaction\nfor such socket does not prevent the usage for the task_frag,\nthe nested allocation modify \u0026quot;under the hood\u0026quot; the page frag\nin use by the outer sendmsg call, corrupting the stream.\r\n\r\nThe overall relevant stack trace looks like the following:\r\n\r\nhttpd 78268 [001] 3461630.850950: probe:tcp_sendmsg_locked:\n ffffffff91461d91 tcp_sendmsg_locked+0x1\n ffffffff91462b57 tcp_sendmsg+0x27\n ffffffff9139814e sock_sendmsg+0x3e\n ffffffffc06dfe1d smb_send_kvec+0x28\n [...]\n ffffffffc06cfaf8 cifs_readpages+0x213\n ffffffff90e83c4b read_pages+0x6b\n ffffffff90e83f31 __do_page_cache_readahead+0x1c1\n ffffffff90e79e98 filemap_fault+0x788\n ffffffff90eb0458 __do_fault+0x38\n ffffffff90eb5280 do_fault+0x1a0\n ffffffff90eb7c84 __handle_mm_fault+0x4d4\n ffffffff90eb8093 handle_mm_fault+0xc3\n ffffffff90c74f6d __do_page_fault+0x1ed\n ffffffff90c75277 do_page_fault+0x37\n ffffffff9160111e page_fault+0x1e\n ffffffff9109e7b5 copyin+0x25\n ffffffff9109eb40 _copy_from_iter_full+0xe0\n ffffffff91462370 tcp_sendmsg_locked+0x5e0\n ffffffff91462370 tcp_sendmsg_locked+0x5e0\n ffffffff91462b57 tcp_sendmsg+0x27\n ffffffff9139815c sock_sendmsg+0x4c\n ffffffff913981f7 sock_write_iter+0x97\n ffffffff90f2cc56 do_iter_readv_writev+0x156\n ffffffff90f2dff0 do_iter_write+0x80\n ffffffff90f2e1c3 vfs_writev+0xa3\n ffffffff90f2e27c do_writev+0x5c\n ffffffff90c042bb do_syscall_64+0x5b\n ffffffff916000ad entry_SYSCALL_64_after_hwframe+0x65\r\n\r\nThe cifs filesystem rightfully sets sk_allocations to GFP_NOFS,\nwe can avoid the nesting using the sk page frag for allocation\nlacking the __GFP_FS flag. Do not define an additional mm-helper\nfor that, as this is strictly tied to the sk page frag usage.\r\n\r\nv1 -\u0026gt; v2:\n - use a stricted sk_page_frag() check instead of reordering the\n code (Eric)(CVE-2021-47544)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: tulip: de4x5: fix the problem that the array \u0026apos;lp-\u0026gt;phy[8]\u0026apos; may be out of bound\r\n\r\nIn line 5001, if all id in the array \u0026apos;lp-\u0026gt;phy[8]\u0026apos; is not 0, when the\n\u0026apos;for\u0026apos; end, the \u0026apos;k\u0026apos; is 8.\r\n\r\nAt this time, the array \u0026apos;lp-\u0026gt;phy[8]\u0026apos; may be out of bound.(CVE-2021-47547)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npowerpc/powernv: Add a null pointer check in opal_event_init()\r\n\r\nkasprintf() returns a pointer to dynamically allocated memory\nwhich can be NULL upon failure.(CVE-2023-52686)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: fix underflow in second superblock position calculations\r\n\r\nMacro NILFS_SB2_OFFSET_BYTES, which computes the position of the second\nsuperblock, underflows when the argument device size is less than 4096\nbytes. Therefore, when using this macro, it is necessary to check in\nadvance that the device size is not less than a lower limit, or at least\nthat underflow does not occur.\r\n\r\nThe current nilfs2 implementation lacks this check, causing out-of-bound\nblock access when mounting devices smaller than 4096 bytes:\r\n\r\n I/O error, dev loop0, sector 36028797018963960 op 0x0:(READ) flags 0x0\n phys_seg 1 prio class 2\n NILFS (loop0): unable to read secondary superblock (blocksize = 1024)\r\n\r\nIn addition, when trying to resize the filesystem to a size below 4096\nbytes, this underflow occurs in nilfs_resize_fs(), passing a huge number\nof segments to nilfs_sufile_resize(), corrupting parameters such as the\nnumber of segments in superblocks. This causes excessive loop iterations\nin nilfs_sufile_resize() during a subsequent resize ioctl, causing\nsemaphore ns_segctor_sem to block for a long time and hang the writer\nthread:\r\n\r\n INFO: task segctord:5067 blocked for more than 143 seconds.\n Not tainted 6.2.0-rc8-syzkaller-00015-gf6feea56f66d #0\n \u0026quot;echo 0 \u0026gt; /proc/sys/kernel/hung_task_timeout_secs\u0026quot; disables this message.\n task:segctord state:D stack:23456 pid:5067 ppid:2\n flags:0x00004000\n Call Trace:\n \u0026lt;TASK\u0026gt;\n context_switch kernel/sched/core.c:5293 [inline]\n __schedule+0x1409/0x43f0 kernel/sched/core.c:6606\n schedule+0xc3/0x190 kernel/sched/core.c:6682\n rwsem_down_write_slowpath+0xfcf/0x14a0 kernel/locking/rwsem.c:1190\n nilfs_transaction_lock+0x25c/0x4f0 fs/nilfs2/segment.c:357\n nilfs_segctor_thread_construct fs/nilfs2/segment.c:2486 [inline]\n nilfs_segctor_thread+0x52f/0x1140 fs/nilfs2/segment.c:2570\n kthread+0x270/0x300 kernel/kthread.c:376\n ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308\n \u0026lt;/TASK\u0026gt;\n ...\n Call Trace:\n \u0026lt;TASK\u0026gt;\n folio_mark_accessed+0x51c/0xf00 mm/swap.c:515\n __nilfs_get_page_block fs/nilfs2/page.c:42 [inline]\n nilfs_grab_buffer+0x3d3/0x540 fs/nilfs2/page.c:61\n nilfs_mdt_submit_block+0xd7/0x8f0 fs/nilfs2/mdt.c:121\n nilfs_mdt_read_block+0xeb/0x430 fs/nilfs2/mdt.c:176\n nilfs_mdt_get_block+0x12d/0xbb0 fs/nilfs2/mdt.c:251\n nilfs_sufile_get_segment_usage_block fs/nilfs2/sufile.c:92 [inline]\n nilfs_sufile_truncate_range fs/nilfs2/sufile.c:679 [inline]\n nilfs_sufile_resize+0x7a3/0x12b0 fs/nilfs2/sufile.c:777\n nilfs_resize_fs+0x20c/0xed0 fs/nilfs2/super.c:422\n nilfs_ioctl_resize fs/nilfs2/ioctl.c:1033 [inline]\n nilfs_ioctl+0x137c/0x2440 fs/nilfs2/ioctl.c:1301\n ...\r\n\r\nThis fixes these issues by inserting appropriate minimum device size\nchecks or anti-underflow checks, depending on where the macro is used.(CVE-2023-52705)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Avoid NULL dereference of timing generator\r\n\r\n[Why \u0026amp; How]\nCheck whether assigned timing generator is NULL or not before\naccessing its funcs to prevent NULL dereference.(CVE-2023-52753)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: imon: fix access to invalid resource for the second interface\r\n\r\nimon driver probes two USB interfaces, and at the probe of the second\ninterface, the driver assumes blindly that the first interface got\nbound with the same imon driver. It\u0026apos;s usually true, but it\u0026apos;s still\npossible that the first interface is bound with another driver via a\nmalformed descriptor. Then it may lead to a memory corruption, as\nspotted by syzkaller; imon driver accesses the data from drvdata as\nstruct imon_context object although it\u0026apos;s a completely different one\nthat was assigned by another driver.\r\n\r\nThis patch adds a sanity check -- whether the first interface is\nreally bound with the imon driver or not -- for avoiding the problem\nabove at the probe time.(CVE-2023-52754)\r\n\r\nRejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2023-52756)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ns390/dasd: protect device queue against concurrent access\r\n\r\nIn dasd_profile_start() the amount of requests on the device queue are\ncounted. The access to the device queue is unprotected against\nconcurrent access. With a lot of parallel I/O, especially with alias\ndevices enabled, the device queue can change while dasd_profile_start()\nis accessing the queue. In the worst case this leads to a kernel panic\ndue to incorrect pointer accesses.\r\n\r\nFix this by taking the device lock before accessing the queue and\ncounting the requests. Additionally the check for a valid profile data\npointer can be done earlier to avoid unnecessary locking in a hot path.(CVE-2023-52774)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nSUNRPC: Fix RPC client cleaned up the freed pipefs dentries\r\n\r\nRPC client pipefs dentries cleanup is in separated rpc_remove_pipedir()\nworkqueue,which takes care about pipefs superblock locking.\nIn some special scenarios, when kernel frees the pipefs sb of the\ncurrent client and immediately alloctes a new pipefs sb,\nrpc_remove_pipedir function would misjudge the existence of pipefs\nsb which is not the one it used to hold. As a result,\nthe rpc_remove_pipedir would clean the released freed pipefs dentries.\r\n\r\nTo fix this issue, rpc_remove_pipedir should check whether the\ncurrent pipefs sb is consistent with the original pipefs sb.\r\n\r\nThis error can be catched by KASAN:\n=========================================================\n[ 250.497700] BUG: KASAN: slab-use-after-free in dget_parent+0x195/0x200\n[ 250.498315] Read of size 4 at addr ffff88800a2ab804 by task kworker/0:18/106503\n[ 250.500549] Workqueue: events rpc_free_client_work\n[ 250.501001] Call Trace:\n[ 250.502880] kasan_report+0xb6/0xf0\n[ 250.503209] ? dget_parent+0x195/0x200\n[ 250.503561] dget_parent+0x195/0x200\n[ 250.503897] ? __pfx_rpc_clntdir_depopulate+0x10/0x10\n[ 250.504384] rpc_rmdir_depopulate+0x1b/0x90\n[ 250.504781] rpc_remove_client_dir+0xf5/0x150\n[ 250.505195] rpc_free_client_work+0xe4/0x230\n[ 250.505598] process_one_work+0x8ee/0x13b0\n...\n[ 22.039056] Allocated by task 244:\n[ 22.039390] kasan_save_stack+0x22/0x50\n[ 22.039758] kasan_set_track+0x25/0x30\n[ 22.040109] __kasan_slab_alloc+0x59/0x70\n[ 22.040487] kmem_cache_alloc_lru+0xf0/0x240\n[ 22.040889] __d_alloc+0x31/0x8e0\n[ 22.041207] d_alloc+0x44/0x1f0\n[ 22.041514] __rpc_lookup_create_exclusive+0x11c/0x140\n[ 22.041987] rpc_mkdir_populate.constprop.0+0x5f/0x110\n[ 22.042459] rpc_create_client_dir+0x34/0x150\n[ 22.042874] rpc_setup_pipedir_sb+0x102/0x1c0\n[ 22.043284] rpc_client_register+0x136/0x4e0\n[ 22.043689] rpc_new_client+0x911/0x1020\n[ 22.044057] rpc_create_xprt+0xcb/0x370\n[ 22.044417] rpc_create+0x36b/0x6c0\n...\n[ 22.049524] Freed by task 0:\n[ 22.049803] kasan_save_stack+0x22/0x50\n[ 22.050165] kasan_set_track+0x25/0x30\n[ 22.050520] kasan_save_free_info+0x2b/0x50\n[ 22.050921] __kasan_slab_free+0x10e/0x1a0\n[ 22.051306] kmem_cache_free+0xa5/0x390\n[ 22.051667] rcu_core+0x62c/0x1930\n[ 22.051995] __do_softirq+0x165/0x52a\n[ 22.052347]\n[ 22.052503] Last potentially related work creation:\n[ 22.052952] kasan_save_stack+0x22/0x50\n[ 22.053313] __kasan_record_aux_stack+0x8e/0xa0\n[ 22.053739] __call_rcu_common.constprop.0+0x6b/0x8b0\n[ 22.054209] dentry_free+0xb2/0x140\n[ 22.054540] __dentry_kill+0x3be/0x540\n[ 22.054900] shrink_dentry_list+0x199/0x510\n[ 22.055293] shrink_dcache_parent+0x190/0x240\n[ 22.055703] do_one_tree+0x11/0x40\n[ 22.056028] shrink_dcache_for_umount+0x61/0x140\n[ 22.056461] generic_shutdown_super+0x70/0x590\n[ 22.056879] kill_anon_super+0x3a/0x60\n[ 22.057234] rpc_kill_sb+0x121/0x200(CVE-2023-52803)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nplatform/x86: wmi: Fix opening of char device\r\n\r\nSince commit fa1f68db6ca7 (\u0026quot;drivers: misc: pass miscdevice pointer via\nfile private data\u0026quot;), the miscdevice stores a pointer to itself inside\nfilp-\u0026gt;private_data, which means that private_data will not be NULL when\nwmi_char_open() is called. This might cause memory corruption should\nwmi_char_open() be unable to find its driver, something which can\nhappen when the associated WMI device is deleted in wmi_free_devices().\r\n\r\nFix the problem by using the miscdevice pointer to retrieve the WMI\ndevice data associated with a char device using container_of(). This\nalso avoids wmi_char_open() picking a wrong WMI device bound to a\ndriver with the same name as the original driver.(CVE-2023-52864)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nclk: mediatek: clk-mt6797: Add check for mtk_alloc_clk_data\r\n\r\nAdd the check for the return value of mtk_alloc_clk_data() in order to\navoid NULL pointer dereference.(CVE-2023-52865)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsoc: qcom: llcc: Handle a second device without data corruption\r\n\r\nUsually there is only one llcc device. But if there were a second, even\na failed probe call would modify the global drv_data pointer. So check\nif drv_data is valid before overwriting it.(CVE-2023-52871)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nefi/capsule-loader: fix incorrect allocation size\r\n\r\ngcc-14 notices that the allocation with sizeof(void) on 32-bit architectures\nis not enough for a 64-bit phys_addr_t:\r\n\r\ndrivers/firmware/efi/capsule-loader.c: In function \u0026apos;efi_capsule_open\u0026apos;:\ndrivers/firmware/efi/capsule-loader.c:295:24: error: allocation of insufficient size \u0026apos;4\u0026apos; for type \u0026apos;phys_addr_t\u0026apos; {aka \u0026apos;long long unsigned int\u0026apos;} with size \u0026apos;8\u0026apos; [-Werror=alloc-size]\n 295 | cap_info-\u0026gt;phys = kzalloc(sizeof(void *), GFP_KERNEL);\n | ^\r\n\r\nUse the correct type instead here.(CVE-2024-27413)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nPCI/PM: Drain runtime-idle callbacks before driver removal\r\n\r\nA race condition between the .runtime_idle() callback and the .remove()\ncallback in the rtsx_pcr PCI driver leads to a kernel crash due to an\nunhandled page fault [1].\r\n\r\nThe problem is that rtsx_pci_runtime_idle() is not expected to be running\nafter pm_runtime_get_sync() has been called, but the latter doesn\u0026apos;t really\nguarantee that. It only guarantees that the suspend and resume callbacks\nwill not be running when it returns.\r\n\r\nHowever, if a .runtime_idle() callback is already running when\npm_runtime_get_sync() is called, the latter will notice that the runtime PM\nstatus of the device is RPM_ACTIVE and it will return right away without\nwaiting for the former to complete. In fact, it cannot wait for\n.runtime_idle() to complete because it may be called from that callback (it\narguably does not make much sense to do that, but it is not strictly\nprohibited).\r\n\r\nThus in general, whoever is providing a .runtime_idle() callback needs\nto protect it from running in parallel with whatever code runs after\npm_runtime_get_sync(). [Note that .runtime_idle() will not start after\npm_runtime_get_sync() has returned, but it may continue running then if it\nhas started earlier.]\r\n\r\nOne way to address that race condition is to call pm_runtime_barrier()\nafter pm_runtime_get_sync() (not before it, because a nonzero value of the\nruntime PM usage counter is necessary to prevent runtime PM callbacks from\nbeing invoked) to wait for the .runtime_idle() callback to complete should\nit be running at that point. A suitable place for doing that is in\npci_device_remove() which calls pm_runtime_get_sync() before removing the\ndriver, so it may as well call pm_runtime_barrier() subsequently, which\nwill prevent the race in question from occurring, not just in the rtsx_pcr\ndriver, but in any PCI drivers providing .runtime_idle() callbacks.(CVE-2024-35809)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: brcmfmac: Fix use-after-free bug in brcmf_cfg80211_detach\r\n\r\nThis is the candidate patch of CVE-2023-47233 :\nhttps://nvd.nist.gov/vuln/detail/CVE-2023-47233\r\n\r\nIn brcm80211 driver,it starts with the following invoking chain\nto start init a timeout worker:\r\n\r\n-\u0026gt;brcmf_usb_probe\n -\u0026gt;brcmf_usb_probe_cb\n -\u0026gt;brcmf_attach\n -\u0026gt;brcmf_bus_started\n -\u0026gt;brcmf_cfg80211_attach\n -\u0026gt;wl_init_priv\n -\u0026gt;brcmf_init_escan\n -\u0026gt;INIT_WORK(\u0026amp;cfg-\u0026gt;escan_timeout_work,\n\t\t brcmf_cfg80211_escan_timeout_worker);\r\n\r\nIf we disconnect the USB by hotplug, it will call\nbrcmf_usb_disconnect to make cleanup. The invoking chain is :\r\n\r\nbrcmf_usb_disconnect\n -\u0026gt;brcmf_usb_disconnect_cb\n -\u0026gt;brcmf_detach\n -\u0026gt;brcmf_cfg80211_detach\n -\u0026gt;kfree(cfg);\r\n\r\nWhile the timeout woker may still be running. This will cause\na use-after-free bug on cfg in brcmf_cfg80211_escan_timeout_worker.\r\n\r\nFix it by deleting the timer and canceling the worker in\nbrcmf_cfg80211_detach.\r\n\r\n[arend.vanspriel@broadcom.com: keep timer delete as is and cancel work just before free](CVE-2024-35811)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nerspan: make sure erspan_base_hdr is present in skb-\u0026gt;head\r\n\r\nsyzbot reported a problem in ip6erspan_rcv() [1]\r\n\r\nIssue is that ip6erspan_rcv() (and erspan_rcv()) no longer make\nsure erspan_base_hdr is present in skb linear part (skb-\u0026gt;head)\nbefore getting @ver field from it.\r\n\r\nAdd the missing pskb_may_pull() calls.\r\n\r\nv2: Reload iph pointer in erspan_rcv() after pskb_may_pull()\n because skb-\u0026gt;head might have changed.\r\n\r\n[1]\r\n\r\n BUG: KMSAN: uninit-value in pskb_may_pull_reason include/linux/skbuff.h:2742 [inline]\n BUG: KMSAN: uninit-value in pskb_may_pull include/linux/skbuff.h:2756 [inline]\n BUG: KMSAN: uninit-value in ip6erspan_rcv net/ipv6/ip6_gre.c:541 [inline]\n BUG: KMSAN: uninit-value in gre_rcv+0x11f8/0x1930 net/ipv6/ip6_gre.c:610\n pskb_may_pull_reason include/linux/skbuff.h:2742 [inline]\n pskb_may_pull include/linux/skbuff.h:2756 [inline]\n ip6erspan_rcv net/ipv6/ip6_gre.c:541 [inline]\n gre_rcv+0x11f8/0x1930 net/ipv6/ip6_gre.c:610\n ip6_protocol_deliver_rcu+0x1d4c/0x2ca0 net/ipv6/ip6_input.c:438\n ip6_input_finish net/ipv6/ip6_input.c:483 [inline]\n NF_HOOK include/linux/netfilter.h:314 [inline]\n ip6_input+0x15d/0x430 net/ipv6/ip6_input.c:492\n ip6_mc_input+0xa7e/0xc80 net/ipv6/ip6_input.c:586\n dst_input include/net/dst.h:460 [inline]\n ip6_rcv_finish+0x955/0x970 net/ipv6/ip6_input.c:79\n NF_HOOK include/linux/netfilter.h:314 [inline]\n ipv6_rcv+0xde/0x390 net/ipv6/ip6_input.c:310\n __netif_receive_skb_one_core net/core/dev.c:5538 [inline]\n __netif_receive_skb+0x1da/0xa00 net/core/dev.c:5652\n netif_receive_skb_internal net/core/dev.c:5738 [inline]\n netif_receive_skb+0x58/0x660 net/core/dev.c:5798\n tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1549\n tun_get_user+0x5566/0x69e0 drivers/net/tun.c:2002\n tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048\n call_write_iter include/linux/fs.h:2108 [inline]\n new_sync_write fs/read_write.c:497 [inline]\n vfs_write+0xb63/0x1520 fs/read_write.c:590\n ksys_write+0x20f/0x4c0 fs/read_write.c:643\n __do_sys_write fs/read_write.c:655 [inline]\n __se_sys_write fs/read_write.c:652 [inline]\n __x64_sys_write+0x93/0xe0 fs/read_write.c:652\n do_syscall_64+0xd5/0x1f0\n entry_SYSCALL_64_after_hwframe+0x6d/0x75\r\n\r\nUninit was created at:\n slab_post_alloc_hook mm/slub.c:3804 [inline]\n slab_alloc_node mm/slub.c:3845 [inline]\n kmem_cache_alloc_node+0x613/0xc50 mm/slub.c:3888\n kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:577\n __alloc_skb+0x35b/0x7a0 net/core/skbuff.c:668\n alloc_skb include/linux/skbuff.h:1318 [inline]\n alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6504\n sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2795\n tun_alloc_skb drivers/net/tun.c:1525 [inline]\n tun_get_user+0x209a/0x69e0 drivers/net/tun.c:1846\n tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048\n call_write_iter include/linux/fs.h:2108 [inline]\n new_sync_write fs/read_write.c:497 [inline]\n vfs_write+0xb63/0x1520 fs/read_write.c:590\n ksys_write+0x20f/0x4c0 fs/read_write.c:643\n __do_sys_write fs/read_write.c:655 [inline]\n __se_sys_write fs/read_write.c:652 [inline]\n __x64_sys_write+0x93/0xe0 fs/read_write.c:652\n do_syscall_64+0xd5/0x1f0\n entry_SYSCALL_64_after_hwframe+0x6d/0x75\r\n\r\nCPU: 1 PID: 5045 Comm: syz-executor114 Not tainted 6.9.0-rc1-syzkaller-00021-g962490525cff #0(CVE-2024-35888)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: validate user input for expected length\r\n\r\nI got multiple syzbot reports showing old bugs exposed\nby BPF after commit 20f2505fb436 (\u0026quot;bpf: Try to avoid kzalloc\nin cgroup/{s,g}etsockopt\u0026quot;)\r\n\r\nsetsockopt() @optlen argument should be taken into account\nbefore copying data.\r\n\r\n BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline]\n BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline]\n BUG: KASAN: slab-out-of-bounds in do_replace net/ipv4/netfilter/ip_tables.c:1111 [inline]\n BUG: KASAN: slab-out-of-bounds in do_ipt_set_ctl+0x902/0x3dd0 net/ipv4/netfilter/ip_tables.c:1627\nRead of size 96 at addr ffff88802cd73da0 by task syz-executor.4/7238\r\n\r\nCPU: 1 PID: 7238 Comm: syz-executor.4 Not tainted 6.9.0-rc2-next-20240403-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114\n print_address_description mm/kasan/report.c:377 [inline]\n print_report+0x169/0x550 mm/kasan/report.c:488\n kasan_report+0x143/0x180 mm/kasan/report.c:601\n kasan_check_range+0x282/0x290 mm/kasan/generic.c:189\n __asan_memcpy+0x29/0x70 mm/kasan/shadow.c:105\n copy_from_sockptr_offset include/linux/sockptr.h:49 [inline]\n copy_from_sockptr include/linux/sockptr.h:55 [inline]\n do_replace net/ipv4/netfilter/ip_tables.c:1111 [inline]\n do_ipt_set_ctl+0x902/0x3dd0 net/ipv4/netfilter/ip_tables.c:1627\n nf_setsockopt+0x295/0x2c0 net/netfilter/nf_sockopt.c:101\n do_sock_setsockopt+0x3af/0x720 net/socket.c:2311\n __sys_setsockopt+0x1ae/0x250 net/socket.c:2334\n __do_sys_setsockopt net/socket.c:2343 [inline]\n __se_sys_setsockopt net/socket.c:2340 [inline]\n __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340\n do_syscall_64+0xfb/0x240\n entry_SYSCALL_64_after_hwframe+0x72/0x7a\nRIP: 0033:0x7fd22067dde9\nCode: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007fd21f9ff0c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000036\nRAX: ffffffffffffffda RBX: 00007fd2207abf80 RCX: 00007fd22067dde9\nRDX: 0000000000000040 RSI: 0000000000000000 RDI: 0000000000000003\nRBP: 00007fd2206ca47a R08: 0000000000000001 R09: 0000000000000000\nR10: 0000000020000880 R11: 0000000000000246 R12: 0000000000000000\nR13: 000000000000000b R14: 00007fd2207abf80 R15: 00007ffd2d0170d8\n \u0026lt;/TASK\u0026gt;\r\n\r\nAllocated by task 7238:\n kasan_save_stack mm/kasan/common.c:47 [inline]\n kasan_save_track+0x3f/0x80 mm/kasan/common.c:68\n poison_kmalloc_redzone mm/kasan/common.c:370 [inline]\n __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:387\n kasan_kmalloc include/linux/kasan.h:211 [inline]\n __do_kmalloc_node mm/slub.c:4069 [inline]\n __kmalloc_noprof+0x200/0x410 mm/slub.c:4082\n kmalloc_noprof include/linux/slab.h:664 [inline]\n __cgroup_bpf_run_filter_setsockopt+0xd47/0x1050 kernel/bpf/cgroup.c:1869\n do_sock_setsockopt+0x6b4/0x720 net/socket.c:2293\n __sys_setsockopt+0x1ae/0x250 net/socket.c:2334\n __do_sys_setsockopt net/socket.c:2343 [inline]\n __se_sys_setsockopt net/socket.c:2340 [inline]\n __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340\n do_syscall_64+0xfb/0x240\n entry_SYSCALL_64_after_hwframe+0x72/0x7a\r\n\r\nThe buggy address belongs to the object at ffff88802cd73da0\n which belongs to the cache kmalloc-8 of size 8\nThe buggy address is located 0 bytes inside of\n allocated 1-byte region [ffff88802cd73da0, ffff88802cd73da1)\r\n\r\nThe buggy address belongs to the physical page:\npage: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff88802cd73020 pfn:0x2cd73\nflags: 0xfff80000000000(node=0|zone=1|lastcpupid=0xfff)\npage_type: 0xffffefff(slab)\nraw: 00fff80000000000 ffff888015041280 dead000000000100 dead000000000122\nraw: ffff88802cd73020 000000008080007f 00000001ffffefff 00\n---truncated---(CVE-2024-35896)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ni2c: smbus: fix NULL function pointer dereference\r\n\r\nBaruch reported an OOPS when using the designware controller as target\nonly. Target-only modes break the assumption of one transfer function\nalways being available. Fix this by always checking the pointer in\n__i2c_transfer.\r\n\r\n[wsa: dropped the simplification in core-smbus to avoid theoretical regressions](CVE-2024-35984)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nrtnetlink: Correct nested IFLA_VF_VLAN_LIST attribute validation\r\n\r\nEach attribute inside a nested IFLA_VF_VLAN_LIST is assumed to be a\nstruct ifla_vf_vlan_info so the size of such attribute needs to be at least\nof sizeof(struct ifla_vf_vlan_info) which is 14 bytes.\nThe current size validation in do_setvfinfo is against NLA_HDRLEN (4 bytes)\nwhich is less than sizeof(struct ifla_vf_vlan_info) so this validation\nis not enough and a too small attribute might be cast to a\nstruct ifla_vf_vlan_info, this might result in an out of bands\nread access when accessing the saved (casted) entry in ivvl.(CVE-2024-36017)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmmc: sdhci-msm: pervent access to suspended controller\r\n\r\nGeneric sdhci code registers LED device and uses host-\u0026gt;runtime_suspended\nflag to protect access to it. The sdhci-msm driver doesn\u0026apos;t set this flag,\nwhich causes a crash when LED is accessed while controller is runtime\nsuspended. Fix this by setting the flag correctly.(CVE-2024-36029)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: fix out-of-bounds access in ops_init\r\n\r\nnet_alloc_generic is called by net_alloc, which is called without any\nlocking. It reads max_gen_ptrs, which is changed under pernet_ops_rwsem. It\nis read twice, first to allocate an array, then to set s.len, which is\nlater used to limit the bounds of the array access.\r\n\r\nIt is possible that the array is allocated and another thread is\nregistering a new pernet ops, increments max_gen_ptrs, which is then used\nto set s.len with a larger than allocated length for the variable array.\r\n\r\nFix it by reading max_gen_ptrs only once in net_alloc_generic. If\nmax_gen_ptrs is later incremented, it will be caught in net_assign_generic.(CVE-2024-36883)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nipv6: fib6_rules: avoid possible NULL dereference in fib6_rule_action()\r\n\r\nsyzbot is able to trigger the following crash [1],\ncaused by unsafe ip6_dst_idev() use.\r\n\r\nIndeed ip6_dst_idev() can return NULL, and must always be checked.\r\n\r\n[1]\r\n\r\nOops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI\nKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]\nCPU: 0 PID: 31648 Comm: syz-executor.0 Not tainted 6.9.0-rc4-next-20240417-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024\n RIP: 0010:__fib6_rule_action net/ipv6/fib6_rules.c:237 [inline]\n RIP: 0010:fib6_rule_action+0x241/0x7b0 net/ipv6/fib6_rules.c:267\nCode: 02 00 00 49 8d 9f d8 00 00 00 48 89 d8 48 c1 e8 03 42 80 3c 20 00 74 08 48 89 df e8 f9 32 bf f7 48 8b 1b 48 89 d8 48 c1 e8 03 \u0026lt;42\u0026gt; 80 3c 20 00 74 08 48 89 df e8 e0 32 bf f7 4c 8b 03 48 89 ef 4c\nRSP: 0018:ffffc9000fc1f2f0 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: 0000000000000000 RCX: 1a772f98c8186700\nRDX: 0000000000000003 RSI: ffffffff8bcac4e0 RDI: ffffffff8c1f9760\nRBP: ffff8880673fb980 R08: ffffffff8fac15ef R09: 1ffffffff1f582bd\nR10: dffffc0000000000 R11: fffffbfff1f582be R12: dffffc0000000000\nR13: 0000000000000080 R14: ffff888076509000 R15: ffff88807a029a00\nFS: 00007f55e82ca6c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000001b31d23000 CR3: 0000000022b66000 CR4: 00000000003506f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n fib_rules_lookup+0x62c/0xdb0 net/core/fib_rules.c:317\n fib6_rule_lookup+0x1fd/0x790 net/ipv6/fib6_rules.c:108\n ip6_route_output_flags_noref net/ipv6/route.c:2637 [inline]\n ip6_route_output_flags+0x38e/0x610 net/ipv6/route.c:2649\n ip6_route_output include/net/ip6_route.h:93 [inline]\n ip6_dst_lookup_tail+0x189/0x11a0 net/ipv6/ip6_output.c:1120\n ip6_dst_lookup_flow+0xb9/0x180 net/ipv6/ip6_output.c:1250\n sctp_v6_get_dst+0x792/0x1e20 net/sctp/ipv6.c:326\n sctp_transport_route+0x12c/0x2e0 net/sctp/transport.c:455\n sctp_assoc_add_peer+0x614/0x15c0 net/sctp/associola.c:662\n sctp_connect_new_asoc+0x31d/0x6c0 net/sctp/socket.c:1099\n __sctp_connect+0x66d/0xe30 net/sctp/socket.c:1197\n sctp_connect net/sctp/socket.c:4819 [inline]\n sctp_inet_connect+0x149/0x1f0 net/sctp/socket.c:4834\n __sys_connect_file net/socket.c:2048 [inline]\n __sys_connect+0x2df/0x310 net/socket.c:2065\n __do_sys_connect net/socket.c:2075 [inline]\n __se_sys_connect net/socket.c:2072 [inline]\n __x64_sys_connect+0x7a/0x90 net/socket.c:2072\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2024-36902)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nipv6: Fix potential uninit-value access in __ip6_make_skb()\r\n\r\nAs it was done in commit fc1092f51567 (\u0026quot;ipv4: Fix uninit-value access in\n__ip_make_skb()\u0026quot;) for IPv4, check FLOWI_FLAG_KNOWN_NH on fl6-\u0026gt;flowi6_flags\ninstead of testing HDRINCL on the socket to avoid a race condition which\ncauses uninit-value access.(CVE-2024-36903)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nblock: fix overflow in blk_ioctl_discard()\r\n\r\nThere is no check for overflow of \u0026apos;start + len\u0026apos; in blk_ioctl_discard().\nHung task occurs if submit an discard ioctl with the following param:\n start = 0x80000000000ff000, len = 0x8000000000fff000;\nAdd the overflow validation now.(CVE-2024-36917)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: lpfc: Release hbalock before calling lpfc_worker_wake_up()\r\n\r\nlpfc_worker_wake_up() calls the lpfc_work_done() routine, which takes the\nhbalock. Thus, lpfc_worker_wake_up() should not be called while holding the\nhbalock to avoid potential deadlock.(CVE-2024-36924)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntipc: fix a possible memleak in tipc_buf_append\r\n\r\n__skb_linearize() doesn\u0026apos;t free the skb when it fails, so move\n\u0026apos;*buf = NULL\u0026apos; after __skb_linearize(), so that the skb can be\nfreed on the err path.(CVE-2024-36954)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfs/9p: only translate RWX permissions for plain 9P2000\r\n\r\nGarbage in plain 9P2000\u0026apos;s perm bits is allowed through, which causes it\nto be able to set (among others) the suid bit. This was presumably not\nthe intent since the unix extended bits are handled explicitly and\nconditionally on .u.(CVE-2024-36964)",
"id": "OESA-2024-1705",
"modified": "2026-08-06T11:07:10Z",
"published": "2024-06-14T11:07:10Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1705"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47236"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47254"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47294"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47315"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47324"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47329"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47403"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47409"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47424"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47460"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47476"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47478"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47479"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47499"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47511"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47518"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47538"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47541"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47542"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47543"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47544"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47547"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52686"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52705"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52753"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52754"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52756"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52774"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52803"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52864"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52865"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52871"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27413"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35809"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35811"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35888"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35896"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35984"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36017"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36029"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36883"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36902"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36903"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36917"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36924"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36954"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36964"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2021-47236",
"CVE-2021-47254",
"CVE-2021-47294",
"CVE-2021-47315",
"CVE-2021-47324",
"CVE-2021-47329",
"CVE-2021-47403",
"CVE-2021-47409",
"CVE-2021-47424",
"CVE-2021-47460",
"CVE-2021-47476",
"CVE-2021-47478",
"CVE-2021-47479",
"CVE-2021-47499",
"CVE-2021-47511",
"CVE-2021-47518",
"CVE-2021-47538",
"CVE-2021-47541",
"CVE-2021-47542",
"CVE-2021-47543",
"CVE-2021-47544",
"CVE-2021-47547",
"CVE-2023-52686",
"CVE-2023-52705",
"CVE-2023-52753",
"CVE-2023-52754",
"CVE-2023-52756",
"CVE-2023-52774",
"CVE-2023-52803",
"CVE-2023-52864",
"CVE-2023-52865",
"CVE-2023-52871",
"CVE-2024-27413",
"CVE-2024-35809",
"CVE-2024-35811",
"CVE-2024-35888",
"CVE-2024-35896",
"CVE-2024-35984",
"CVE-2024-36017",
"CVE-2024-36029",
"CVE-2024-36883",
"CVE-2024-36902",
"CVE-2024-36903",
"CVE-2024-36917",
"CVE-2024-36924",
"CVE-2024-36954",
"CVE-2024-36964"
]
}
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.