Action not permitted
Modal body text goes here.
Modal Title
Modal Body
CVE-2024-42127 (GCVE-0-2024-42127)
Vulnerability from cvelistv5 – Published: 2024-07-30 07:46 – Updated: 2026-05-11 20:27| Vendor | Product | Version | CPE status | |
|---|---|---|---|---|
| Linux | Linux |
Affected:
a1d2a6339961efc078208dc3b2f006e9e9a8e119 , < 0d60c43df59ef01c08dc7b0c45495178f9d05a13
(git)
Affected: a1d2a6339961efc078208dc3b2f006e9e9a8e119 , < 25d0d9b83d855cbc5d5aa5ae3cd79d55ea0c84a8 (git) Affected: a1d2a6339961efc078208dc3b2f006e9e9a8e119 , < 17fe8b75aaf0bb1bdc31368963446b421c22d0af (git) Affected: a1d2a6339961efc078208dc3b2f006e9e9a8e119 , < 0a487e977cb8897ae4c51ecd34bbaa2b005266c9 (git) Affected: a1d2a6339961efc078208dc3b2f006e9e9a8e119 , < 04d531b9a1875846d4f89953b469ad463aa7a770 (git) Affected: a1d2a6339961efc078208dc3b2f006e9e9a8e119 , < b5daf9217a50636a969bc1965f827878aeb09ffe (git) Affected: a1d2a6339961efc078208dc3b2f006e9e9a8e119 , < a6683c690bbfd1f371510cb051e8fa49507f3f5e (git) |
guessed | |
| Linux | Linux |
Affected:
5.2
Unaffected: 0 , < 5.2 (semver) Unaffected: 5.4.280 , ≤ 5.4.* (semver) Unaffected: 5.10.222 , ≤ 5.10.* (semver) Unaffected: 5.15.163 , ≤ 5.15.* (semver) Unaffected: 6.1.98 , ≤ 6.1.* (semver) Unaffected: 6.6.39 , ≤ 6.6.* (semver) Unaffected: 6.9.9 , ≤ 6.9.* (semver) Unaffected: 6.10 , ≤ * (original_commit_for_fix) |
guessed |
{
"containers": {
"adp": [
{
"providerMetadata": {
"dateUpdated": "2025-11-03T22:01:59.030Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/0d60c43df59ef01c08dc7b0c45495178f9d05a13"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/25d0d9b83d855cbc5d5aa5ae3cd79d55ea0c84a8"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/17fe8b75aaf0bb1bdc31368963446b421c22d0af"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/0a487e977cb8897ae4c51ecd34bbaa2b005266c9"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/04d531b9a1875846d4f89953b469ad463aa7a770"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/b5daf9217a50636a969bc1965f827878aeb09ffe"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/a6683c690bbfd1f371510cb051e8fa49507f3f5e"
},
{
"url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
}
],
"title": "CVE Program Container"
},
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2024-42127",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2024-09-10T16:16:38.392074Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2024-09-11T17:33:04.418Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/gpu/drm/lima/lima_gp.c",
"drivers/gpu/drm/lima/lima_mmu.c",
"drivers/gpu/drm/lima/lima_pp.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "0d60c43df59ef01c08dc7b0c45495178f9d05a13",
"status": "affected",
"version": "a1d2a6339961efc078208dc3b2f006e9e9a8e119",
"versionType": "git"
},
{
"lessThan": "25d0d9b83d855cbc5d5aa5ae3cd79d55ea0c84a8",
"status": "affected",
"version": "a1d2a6339961efc078208dc3b2f006e9e9a8e119",
"versionType": "git"
},
{
"lessThan": "17fe8b75aaf0bb1bdc31368963446b421c22d0af",
"status": "affected",
"version": "a1d2a6339961efc078208dc3b2f006e9e9a8e119",
"versionType": "git"
},
{
"lessThan": "0a487e977cb8897ae4c51ecd34bbaa2b005266c9",
"status": "affected",
"version": "a1d2a6339961efc078208dc3b2f006e9e9a8e119",
"versionType": "git"
},
{
"lessThan": "04d531b9a1875846d4f89953b469ad463aa7a770",
"status": "affected",
"version": "a1d2a6339961efc078208dc3b2f006e9e9a8e119",
"versionType": "git"
},
{
"lessThan": "b5daf9217a50636a969bc1965f827878aeb09ffe",
"status": "affected",
"version": "a1d2a6339961efc078208dc3b2f006e9e9a8e119",
"versionType": "git"
},
{
"lessThan": "a6683c690bbfd1f371510cb051e8fa49507f3f5e",
"status": "affected",
"version": "a1d2a6339961efc078208dc3b2f006e9e9a8e119",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/gpu/drm/lima/lima_gp.c",
"drivers/gpu/drm/lima/lima_mmu.c",
"drivers/gpu/drm/lima/lima_pp.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "5.2"
},
{
"lessThan": "5.2",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.280",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.222",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.163",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.98",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.39",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.9.*",
"status": "unaffected",
"version": "6.9.9",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.10",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.4.280",
"versionStartIncluding": "5.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.10.222",
"versionStartIncluding": "5.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.15.163",
"versionStartIncluding": "5.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.1.98",
"versionStartIncluding": "5.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6.39",
"versionStartIncluding": "5.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.9.9",
"versionStartIncluding": "5.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.10",
"versionStartIncluding": "5.2",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/lima: fix shared irq handling on driver remove\n\nlima uses a shared interrupt, so the interrupt handlers must be prepared\nto be called at any time. At driver removal time, the clocks are\ndisabled early and the interrupts stay registered until the very end of\nthe remove process due to the devm usage.\nThis is potentially a bug as the interrupts access device registers\nwhich assumes clocks are enabled. A crash can be triggered by removing\nthe driver in a kernel with CONFIG_DEBUG_SHIRQ enabled.\nThis patch frees the interrupts at each lima device finishing callback\nso that the handlers are already unregistered by the time we fully\ndisable clocks."
}
],
"providerMetadata": {
"dateUpdated": "2026-05-11T20:27:30.970Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/0d60c43df59ef01c08dc7b0c45495178f9d05a13"
},
{
"url": "https://git.kernel.org/stable/c/25d0d9b83d855cbc5d5aa5ae3cd79d55ea0c84a8"
},
{
"url": "https://git.kernel.org/stable/c/17fe8b75aaf0bb1bdc31368963446b421c22d0af"
},
{
"url": "https://git.kernel.org/stable/c/0a487e977cb8897ae4c51ecd34bbaa2b005266c9"
},
{
"url": "https://git.kernel.org/stable/c/04d531b9a1875846d4f89953b469ad463aa7a770"
},
{
"url": "https://git.kernel.org/stable/c/b5daf9217a50636a969bc1965f827878aeb09ffe"
},
{
"url": "https://git.kernel.org/stable/c/a6683c690bbfd1f371510cb051e8fa49507f3f5e"
}
],
"title": "drm/lima: fix shared irq handling on driver remove",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2024-42127",
"datePublished": "2024-07-30T07:46:24.070Z",
"dateReserved": "2024-07-29T15:50:41.184Z",
"dateUpdated": "2026-05-11T20:27:30.970Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"epss": {
"cve": "CVE-2024-42127",
"date": "2026-10-31",
"epss": "0.00239",
"percentile": "0.15092"
},
"nvd": {
"cve": {
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/gpu/drm/lima/lima_gp.c",
"drivers/gpu/drm/lima/lima_mmu.c",
"drivers/gpu/drm/lima/lima_pp.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "0d60c43df59ef01c08dc7b0c45495178f9d05a13",
"status": "affected",
"version": "a1d2a6339961efc078208dc3b2f006e9e9a8e119",
"versionType": "git"
},
{
"lessThan": "25d0d9b83d855cbc5d5aa5ae3cd79d55ea0c84a8",
"status": "affected",
"version": "a1d2a6339961efc078208dc3b2f006e9e9a8e119",
"versionType": "git"
},
{
"lessThan": "17fe8b75aaf0bb1bdc31368963446b421c22d0af",
"status": "affected",
"version": "a1d2a6339961efc078208dc3b2f006e9e9a8e119",
"versionType": "git"
},
{
"lessThan": "0a487e977cb8897ae4c51ecd34bbaa2b005266c9",
"status": "affected",
"version": "a1d2a6339961efc078208dc3b2f006e9e9a8e119",
"versionType": "git"
},
{
"lessThan": "04d531b9a1875846d4f89953b469ad463aa7a770",
"status": "affected",
"version": "a1d2a6339961efc078208dc3b2f006e9e9a8e119",
"versionType": "git"
},
{
"lessThan": "b5daf9217a50636a969bc1965f827878aeb09ffe",
"status": "affected",
"version": "a1d2a6339961efc078208dc3b2f006e9e9a8e119",
"versionType": "git"
},
{
"lessThan": "a6683c690bbfd1f371510cb051e8fa49507f3f5e",
"status": "affected",
"version": "a1d2a6339961efc078208dc3b2f006e9e9a8e119",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/gpu/drm/lima/lima_gp.c",
"drivers/gpu/drm/lima/lima_mmu.c",
"drivers/gpu/drm/lima/lima_pp.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "5.2"
},
{
"lessThan": "5.2",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.280",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.222",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.163",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.98",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.39",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.9.*",
"status": "unaffected",
"version": "6.9.9",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.10",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"configurations": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "41869EAB-4316-41AD-B24B-7C8855E56D62",
"versionEndExcluding": "5.4.280",
"versionStartIncluding": "5.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "00696AC5-EE29-437F-97F9-C4D66608B327",
"versionEndExcluding": "5.10.222",
"versionStartIncluding": "5.5",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "A97DEB09-4927-40F8-B5C6-F5BD5EAE0CFD",
"versionEndExcluding": "5.15.163",
"versionStartIncluding": "5.11",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "E09E92A5-27EF-40E4-926A-B1CDC8270551",
"versionEndExcluding": "6.1.98",
"versionStartIncluding": "5.16",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "29E894E4-668F-4DB0-81F7-4FB5F698E970",
"versionEndExcluding": "6.6.39",
"versionStartIncluding": "6.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "ADCC1407-0CB3-4C8F-B4C5-07F682CD7085",
"versionEndExcluding": "6.9.9",
"versionStartIncluding": "6.7",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/lima: fix shared irq handling on driver remove\n\nlima uses a shared interrupt, so the interrupt handlers must be prepared\nto be called at any time. At driver removal time, the clocks are\ndisabled early and the interrupts stay registered until the very end of\nthe remove process due to the devm usage.\nThis is potentially a bug as the interrupts access device registers\nwhich assumes clocks are enabled. A crash can be triggered by removing\nthe driver in a kernel with CONFIG_DEBUG_SHIRQ enabled.\nThis patch frees the interrupts at each lima device finishing callback\nso that the handlers are already unregistered by the time we fully\ndisable clocks."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/lima: arregla el manejo de irq compartido en el controlador elimina lima usa una interrupci\u00f3n compartida, por lo que los controladores de interrupciones deben estar preparados para ser llamados en cualquier momento. En el momento de la eliminaci\u00f3n del controlador, los relojes se desactivan antes de tiempo y las interrupciones permanecen registradas hasta el final del proceso de eliminaci\u00f3n debido al uso del devm. Esto es potencialmente un error ya que las interrupciones acceden a los registros del dispositivo, lo que supone que los relojes est\u00e1n habilitados. Se puede provocar un bloqueo eliminando el controlador en un kernel con CONFIG_DEBUG_SHIRQ habilitado. Este parche libera las interrupciones en cada dispositivo Lima que finaliza la devoluci\u00f3n de llamada para que los controladores ya est\u00e9n dados de baja cuando deshabilitemos completamente los relojes."
}
],
"id": "CVE-2024-42127",
"lastModified": "2026-06-17T07:48:53.480",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 5.5,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 3.6,
"source": "nvd@nist.gov",
"type": "Primary"
}
],
"ssvcV203": [
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"ssvcData": {
"id": "CVE-2024-42127",
"options": [
{
"exploitation": "none"
},
{
"automatable": "no"
},
{
"technicalImpact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2024-09-10T16:16:38.392074Z",
"version": "2.0.3"
}
}
]
},
"published": "2024-07-30T08:15:04.820",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/04d531b9a1875846d4f89953b469ad463aa7a770"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/0a487e977cb8897ae4c51ecd34bbaa2b005266c9"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/0d60c43df59ef01c08dc7b0c45495178f9d05a13"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/17fe8b75aaf0bb1bdc31368963446b421c22d0af"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/25d0d9b83d855cbc5d5aa5ae3cd79d55ea0c84a8"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/a6683c690bbfd1f371510cb051e8fa49507f3f5e"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/b5daf9217a50636a969bc1965f827878aeb09ffe"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/04d531b9a1875846d4f89953b469ad463aa7a770"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/0a487e977cb8897ae4c51ecd34bbaa2b005266c9"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/0d60c43df59ef01c08dc7b0c45495178f9d05a13"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/17fe8b75aaf0bb1bdc31368963446b421c22d0af"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/25d0d9b83d855cbc5d5aa5ae3cd79d55ea0c84a8"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/a6683c690bbfd1f371510cb051e8fa49507f3f5e"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/b5daf9217a50636a969bc1965f827878aeb09ffe"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
}
],
"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": "2025-11-21T10:44:34+00:00",
"cve": "CVE-2024-42127",
"id": "CVE-2024-42127",
"initial_release_date": "2024-07-30T00:00:00+00:00",
"product_status:known_not_affected": "198",
"source": "Red Hat CSAF VEX",
"status": "final",
"title": "kernel: drm/lima: fix shared irq handling on driver remove",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2024/cve-2024-42127.json",
"version": "3"
},
"vulnrichment": {
"containers": {
"adp": [
{
"providerMetadata": {
"dateUpdated": "2025-11-03T22:01:59.030Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/0d60c43df59ef01c08dc7b0c45495178f9d05a13"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/25d0d9b83d855cbc5d5aa5ae3cd79d55ea0c84a8"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/17fe8b75aaf0bb1bdc31368963446b421c22d0af"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/0a487e977cb8897ae4c51ecd34bbaa2b005266c9"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/04d531b9a1875846d4f89953b469ad463aa7a770"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/b5daf9217a50636a969bc1965f827878aeb09ffe"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/a6683c690bbfd1f371510cb051e8fa49507f3f5e"
},
{
"url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
}
],
"title": "CVE Program Container"
},
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2024-42127",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2024-09-10T16:16:38.392074Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2024-09-11T12:42:14.383Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/gpu/drm/lima/lima_gp.c",
"drivers/gpu/drm/lima/lima_mmu.c",
"drivers/gpu/drm/lima/lima_pp.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "0d60c43df59ef01c08dc7b0c45495178f9d05a13",
"status": "affected",
"version": "a1d2a6339961efc078208dc3b2f006e9e9a8e119",
"versionType": "git"
},
{
"lessThan": "25d0d9b83d855cbc5d5aa5ae3cd79d55ea0c84a8",
"status": "affected",
"version": "a1d2a6339961efc078208dc3b2f006e9e9a8e119",
"versionType": "git"
},
{
"lessThan": "17fe8b75aaf0bb1bdc31368963446b421c22d0af",
"status": "affected",
"version": "a1d2a6339961efc078208dc3b2f006e9e9a8e119",
"versionType": "git"
},
{
"lessThan": "0a487e977cb8897ae4c51ecd34bbaa2b005266c9",
"status": "affected",
"version": "a1d2a6339961efc078208dc3b2f006e9e9a8e119",
"versionType": "git"
},
{
"lessThan": "04d531b9a1875846d4f89953b469ad463aa7a770",
"status": "affected",
"version": "a1d2a6339961efc078208dc3b2f006e9e9a8e119",
"versionType": "git"
},
{
"lessThan": "b5daf9217a50636a969bc1965f827878aeb09ffe",
"status": "affected",
"version": "a1d2a6339961efc078208dc3b2f006e9e9a8e119",
"versionType": "git"
},
{
"lessThan": "a6683c690bbfd1f371510cb051e8fa49507f3f5e",
"status": "affected",
"version": "a1d2a6339961efc078208dc3b2f006e9e9a8e119",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/gpu/drm/lima/lima_gp.c",
"drivers/gpu/drm/lima/lima_mmu.c",
"drivers/gpu/drm/lima/lima_pp.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "5.2"
},
{
"lessThan": "5.2",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.280",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.222",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.163",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.98",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.39",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.9.*",
"status": "unaffected",
"version": "6.9.9",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.10",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.4.280",
"versionStartIncluding": "5.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.10.222",
"versionStartIncluding": "5.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.15.163",
"versionStartIncluding": "5.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.1.98",
"versionStartIncluding": "5.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6.39",
"versionStartIncluding": "5.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.9.9",
"versionStartIncluding": "5.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.10",
"versionStartIncluding": "5.2",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/lima: fix shared irq handling on driver remove\n\nlima uses a shared interrupt, so the interrupt handlers must be prepared\nto be called at any time. At driver removal time, the clocks are\ndisabled early and the interrupts stay registered until the very end of\nthe remove process due to the devm usage.\nThis is potentially a bug as the interrupts access device registers\nwhich assumes clocks are enabled. A crash can be triggered by removing\nthe driver in a kernel with CONFIG_DEBUG_SHIRQ enabled.\nThis patch frees the interrupts at each lima device finishing callback\nso that the handlers are already unregistered by the time we fully\ndisable clocks."
}
],
"providerMetadata": {
"dateUpdated": "2025-07-28T11:16:37.126Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/0d60c43df59ef01c08dc7b0c45495178f9d05a13"
},
{
"url": "https://git.kernel.org/stable/c/25d0d9b83d855cbc5d5aa5ae3cd79d55ea0c84a8"
},
{
"url": "https://git.kernel.org/stable/c/17fe8b75aaf0bb1bdc31368963446b421c22d0af"
},
{
"url": "https://git.kernel.org/stable/c/0a487e977cb8897ae4c51ecd34bbaa2b005266c9"
},
{
"url": "https://git.kernel.org/stable/c/04d531b9a1875846d4f89953b469ad463aa7a770"
},
{
"url": "https://git.kernel.org/stable/c/b5daf9217a50636a969bc1965f827878aeb09ffe"
},
{
"url": "https://git.kernel.org/stable/c/a6683c690bbfd1f371510cb051e8fa49507f3f5e"
}
],
"title": "drm/lima: fix shared irq handling on driver remove",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2024-42127",
"datePublished": "2024-07-30T07:46:24.070Z",
"dateReserved": "2024-07-29T15:50:41.184Z",
"dateUpdated": "2025-11-03T22:01:59.030Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
}
}
CERTFR-2024-AVI-0997
Vulnerability from certfr_avis - Published: 2024-11-18 - Updated: 2024-11-18
De multiples vulnérabilités ont été découvertes dans le noyau Linux d'Ubuntu. Certaines d'entre elles permettent à un attaquant de provoquer une exécution de code arbitraire à distance, une élévation de privilèges et 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).
| Title | Publication Time | Tags | |||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||
{
"$ref": "https://www.cert.ssi.gouv.fr/openapi.json",
"affected_systems": [
{
"description": "Ubuntu 16.04 ESM",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 24.04 LTS",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 18.04 ESM",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 20.04 LTS",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 24.10",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 14.04 ESM",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 22.04 LTS",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
}
],
"affected_systems_content": "",
"content": "## Solutions\n\nSe r\u00e9f\u00e9rer au bulletin de s\u00e9curit\u00e9 de l\u0027\u00e9diteur pour l\u0027obtention des correctifs (cf. section Documentation).",
"cves": [
{
"name": "CVE-2020-13765",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-13765"
},
{
"name": "CVE-2020-1983",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-1983"
},
{
"name": "CVE-2020-7039",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-7039"
},
{
"name": "CVE-2019-20382",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-20382"
},
{
"name": "CVE-2022-36402",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-36402"
},
{
"name": "CVE-2024-25744",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-25744"
},
{
"name": "CVE-2023-52531",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52531"
},
{
"name": "CVE-2024-26607",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26607"
},
{
"name": "CVE-2023-52528",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52528"
},
{
"name": "CVE-2024-26800",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26800"
},
{
"name": "CVE-2024-26810",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26810"
},
{
"name": "CVE-2024-26640",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26640"
},
{
"name": "CVE-2024-26812",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26812"
},
{
"name": "CVE-2024-26641",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26641"
},
{
"name": "CVE-2024-27051",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27051"
},
{
"name": "CVE-2024-26885",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26885"
},
{
"name": "CVE-2023-52614",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52614"
},
{
"name": "CVE-2024-26891",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26891"
},
{
"name": "CVE-2024-26668",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26668"
},
{
"name": "CVE-2024-26669",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26669"
},
{
"name": "CVE-2021-47212",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47212"
},
{
"name": "CVE-2024-26893",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26893"
},
{
"name": "CVE-2024-35848",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35848"
},
{
"name": "CVE-2024-27436",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27436"
},
{
"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-38630",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38630"
},
{
"name": "CVE-2024-26661",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26661"
},
{
"name": "CVE-2024-25741",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-25741"
},
{
"name": "CVE-2024-39487",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39487"
},
{
"name": "CVE-2024-39494",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39494"
},
{
"name": "CVE-2024-40915",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40915"
},
{
"name": "CVE-2024-40929",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40929"
},
{
"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-38577",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38577"
},
{
"name": "CVE-2024-41011",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41011"
},
{
"name": "CVE-2024-39472",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39472"
},
{
"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-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-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-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-42230",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42230"
},
{
"name": "CVE-2022-48666",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48666"
},
{
"name": "CVE-2024-36484",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36484"
},
{
"name": "CVE-2024-41007",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41007"
},
{
"name": "CVE-2024-41020",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41020"
},
{
"name": "CVE-2024-41022",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41022"
},
{
"name": "CVE-2024-41034",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41034"
},
{
"name": "CVE-2024-41035",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41035"
},
{
"name": "CVE-2024-41046",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41046"
},
{
"name": "CVE-2024-41049",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41049"
},
{
"name": "CVE-2024-41055",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41055"
},
{
"name": "CVE-2024-41065",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41065"
},
{
"name": "CVE-2024-41068",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41068"
},
{
"name": "CVE-2024-41077",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41077"
},
{
"name": "CVE-2024-42101",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42101"
},
{
"name": "CVE-2024-42102",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42102"
},
{
"name": "CVE-2024-42104",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42104"
},
{
"name": "CVE-2024-42106",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42106"
},
{
"name": "CVE-2024-42115",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42115"
},
{
"name": "CVE-2024-42121",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42121"
},
{
"name": "CVE-2024-42127",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42127"
},
{
"name": "CVE-2024-42131",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42131"
},
{
"name": "CVE-2024-42137",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42137"
},
{
"name": "CVE-2024-42152",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42152"
},
{
"name": "CVE-2024-42153",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42153"
},
{
"name": "CVE-2024-42157",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42157"
},
{
"name": "CVE-2024-42229",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42229"
},
{
"name": "CVE-2024-42232",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42232"
},
{
"name": "CVE-2024-42236",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42236"
},
{
"name": "CVE-2024-42244",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42244"
},
{
"name": "CVE-2024-42247",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42247"
},
{
"name": "CVE-2024-42110",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42110"
},
{
"name": "CVE-2024-41073",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41073"
},
{
"name": "CVE-2024-41096",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41096"
},
{
"name": "CVE-2024-42082",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42082"
},
{
"name": "CVE-2023-52887",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52887"
},
{
"name": "CVE-2024-41027",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41027"
},
{
"name": "CVE-2024-41047",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41047"
},
{
"name": "CVE-2024-41092",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41092"
},
{
"name": "CVE-2024-41093",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41093"
},
{
"name": "CVE-2024-41097",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41097"
},
{
"name": "CVE-2024-42068",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42068"
},
{
"name": "CVE-2024-42076",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42076"
},
{
"name": "CVE-2024-42077",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42077"
},
{
"name": "CVE-2024-42080",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42080"
},
{
"name": "CVE-2024-42084",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42084"
},
{
"name": "CVE-2024-42085",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42085"
},
{
"name": "CVE-2024-42086",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42086"
},
{
"name": "CVE-2024-42087",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42087"
},
{
"name": "CVE-2024-42089",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42089"
},
{
"name": "CVE-2024-42090",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42090"
},
{
"name": "CVE-2024-42092",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42092"
},
{
"name": "CVE-2024-42094",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42094"
},
{
"name": "CVE-2024-42095",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42095"
},
{
"name": "CVE-2024-42097",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42097"
},
{
"name": "CVE-2024-42098",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42098"
},
{
"name": "CVE-2024-42109",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42109"
},
{
"name": "CVE-2024-42130",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42130"
},
{
"name": "CVE-2024-42140",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42140"
},
{
"name": "CVE-2024-42225",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42225"
},
{
"name": "CVE-2024-42240",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42240"
},
{
"name": "CVE-2024-42270",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42270"
},
{
"name": "CVE-2023-52889",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52889"
},
{
"name": "CVE-2024-39486",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39486"
},
{
"name": "CVE-2024-41010",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41010"
},
{
"name": "CVE-2024-41025",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41025"
},
{
"name": "CVE-2024-41028",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41028"
},
{
"name": "CVE-2024-41032",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41032"
},
{
"name": "CVE-2024-41036",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41036"
},
{
"name": "CVE-2024-41037",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41037"
},
{
"name": "CVE-2024-41038",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41038"
},
{
"name": "CVE-2024-41039",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41039"
},
{
"name": "CVE-2024-41042",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41042"
},
{
"name": "CVE-2024-41045",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41045"
},
{
"name": "CVE-2024-41050",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41050"
},
{
"name": "CVE-2024-41051",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41051"
},
{
"name": "CVE-2024-41056",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41056"
},
{
"name": "CVE-2024-41061",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41061"
},
{
"name": "CVE-2024-41062",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41062"
},
{
"name": "CVE-2024-41074",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41074"
},
{
"name": "CVE-2024-41075",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41075"
},
{
"name": "CVE-2024-41079",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41079"
},
{
"name": "CVE-2024-41080",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41080"
},
{
"name": "CVE-2024-41084",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41084"
},
{
"name": "CVE-2024-41088",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41088"
},
{
"name": "CVE-2024-41094",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41094"
},
{
"name": "CVE-2024-41098",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41098"
},
{
"name": "CVE-2024-42064",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42064"
},
{
"name": "CVE-2024-42069",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42069"
},
{
"name": "CVE-2024-42073",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42073"
},
{
"name": "CVE-2024-42074",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42074"
},
{
"name": "CVE-2024-42113",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42113"
},
{
"name": "CVE-2024-42114",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42114"
},
{
"name": "CVE-2024-42117",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42117"
},
{
"name": "CVE-2024-42126",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42126"
},
{
"name": "CVE-2024-42132",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42132"
},
{
"name": "CVE-2024-42133",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42133"
},
{
"name": "CVE-2024-42136",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42136"
},
{
"name": "CVE-2024-42138",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42138"
},
{
"name": "CVE-2024-42141",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42141"
},
{
"name": "CVE-2024-42142",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42142"
},
{
"name": "CVE-2024-42144",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42144"
},
{
"name": "CVE-2024-42147",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42147"
},
{
"name": "CVE-2024-42155",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42155"
},
{
"name": "CVE-2024-42156",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42156"
},
{
"name": "CVE-2024-42158",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42158"
},
{
"name": "CVE-2024-42227",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42227"
},
{
"name": "CVE-2024-42237",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42237"
},
{
"name": "CVE-2024-42238",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42238"
},
{
"name": "CVE-2024-42239",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42239"
},
{
"name": "CVE-2024-42241",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42241"
},
{
"name": "CVE-2024-42245",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42245"
},
{
"name": "CVE-2024-42246",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42246"
},
{
"name": "CVE-2024-42250",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42250"
},
{
"name": "CVE-2024-42253",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42253"
},
{
"name": "CVE-2024-42259",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42259"
},
{
"name": "CVE-2024-42269",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42269"
},
{
"name": "CVE-2024-42271",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42271"
},
{
"name": "CVE-2024-42274",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42274"
},
{
"name": "CVE-2024-42276",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42276"
},
{
"name": "CVE-2024-42277",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42277"
},
{
"name": "CVE-2024-42280",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42280"
},
{
"name": "CVE-2024-42281",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42281"
},
{
"name": "CVE-2024-42283",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42283"
},
{
"name": "CVE-2024-42284",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42284"
},
{
"name": "CVE-2024-42285",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42285"
},
{
"name": "CVE-2024-42286",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42286"
},
{
"name": "CVE-2024-42287",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42287"
},
{
"name": "CVE-2024-42288",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42288"
},
{
"name": "CVE-2024-42289",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42289"
},
{
"name": "CVE-2024-42290",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42290"
},
{
"name": "CVE-2024-42292",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42292"
},
{
"name": "CVE-2024-42295",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42295"
},
{
"name": "CVE-2024-42301",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42301"
},
{
"name": "CVE-2024-42302",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42302"
},
{
"name": "CVE-2024-42309",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42309"
},
{
"name": "CVE-2024-42310",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42310"
},
{
"name": "CVE-2024-42311",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42311"
},
{
"name": "CVE-2024-42312",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42312"
},
{
"name": "CVE-2024-42313",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42313"
},
{
"name": "CVE-2024-42318",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42318"
},
{
"name": "CVE-2024-43817",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43817"
},
{
"name": "CVE-2024-43829",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43829"
},
{
"name": "CVE-2024-43830",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43830"
},
{
"name": "CVE-2024-43834",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43834"
},
{
"name": "CVE-2024-43839",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43839"
},
{
"name": "CVE-2024-43841",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43841"
},
{
"name": "CVE-2024-43846",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43846"
},
{
"name": "CVE-2024-43849",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43849"
},
{
"name": "CVE-2024-43853",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43853"
},
{
"name": "CVE-2024-43854",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43854"
},
{
"name": "CVE-2024-43855",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43855"
},
{
"name": "CVE-2024-43856",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43856"
},
{
"name": "CVE-2024-43858",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43858"
},
{
"name": "CVE-2024-43860",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43860"
},
{
"name": "CVE-2024-43861",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43861"
},
{
"name": "CVE-2024-43863",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43863"
},
{
"name": "CVE-2024-43867",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43867"
},
{
"name": "CVE-2024-43871",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43871"
},
{
"name": "CVE-2024-43873",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43873"
},
{
"name": "CVE-2024-43875",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43875"
},
{
"name": "CVE-2024-43879",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43879"
},
{
"name": "CVE-2024-43880",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43880"
},
{
"name": "CVE-2024-43882",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43882"
},
{
"name": "CVE-2024-43883",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43883"
},
{
"name": "CVE-2024-43884",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43884"
},
{
"name": "CVE-2024-43889",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43889"
},
{
"name": "CVE-2024-43892",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43892"
},
{
"name": "CVE-2024-43893",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43893"
},
{
"name": "CVE-2024-43894",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43894"
},
{
"name": "CVE-2024-43902",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43902"
},
{
"name": "CVE-2024-43905",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43905"
},
{
"name": "CVE-2024-43907",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43907"
},
{
"name": "CVE-2024-43908",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43908"
},
{
"name": "CVE-2024-43909",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43909"
},
{
"name": "CVE-2024-44947",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44947"
},
{
"name": "CVE-2024-41023",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41023"
},
{
"name": "CVE-2024-41031",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41031"
},
{
"name": "CVE-2024-42243",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42243"
},
{
"name": "CVE-2024-45003",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45003"
},
{
"name": "CVE-2024-43835",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43835"
},
{
"name": "CVE-2024-44940",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44940"
},
{
"name": "CVE-2024-44946",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44946"
},
{
"name": "CVE-2024-44974",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44974"
},
{
"name": "CVE-2024-44982",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44982"
},
{
"name": "CVE-2024-44983",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44983"
},
{
"name": "CVE-2024-44985",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44985"
},
{
"name": "CVE-2024-44986",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44986"
},
{
"name": "CVE-2024-44987",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44987"
},
{
"name": "CVE-2024-44988",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44988"
},
{
"name": "CVE-2024-44989",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44989"
},
{
"name": "CVE-2024-44990",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44990"
},
{
"name": "CVE-2024-44995",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44995"
},
{
"name": "CVE-2024-44998",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44998"
},
{
"name": "CVE-2024-44999",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44999"
},
{
"name": "CVE-2024-45006",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45006"
},
{
"name": "CVE-2024-45007",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45007"
},
{
"name": "CVE-2024-45008",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45008"
},
{
"name": "CVE-2024-45009",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45009"
},
{
"name": "CVE-2024-45011",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45011"
},
{
"name": "CVE-2024-45016",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45016"
},
{
"name": "CVE-2024-45018",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45018"
},
{
"name": "CVE-2024-45021",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45021"
},
{
"name": "CVE-2024-45025",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45025"
},
{
"name": "CVE-2024-45026",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45026"
},
{
"name": "CVE-2024-45028",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45028"
},
{
"name": "CVE-2024-46673",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46673"
},
{
"name": "CVE-2024-46675",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46675"
},
{
"name": "CVE-2024-46676",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46676"
},
{
"name": "CVE-2024-46677",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46677"
},
{
"name": "CVE-2024-46679",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46679"
},
{
"name": "CVE-2024-46685",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46685"
},
{
"name": "CVE-2024-46689",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46689"
},
{
"name": "CVE-2024-46702",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46702"
},
{
"name": "CVE-2024-46707",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46707"
},
{
"name": "CVE-2024-46713",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46713"
},
{
"name": "CVE-2024-46714",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46714"
},
{
"name": "CVE-2024-46719",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46719"
},
{
"name": "CVE-2024-46721",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46721"
},
{
"name": "CVE-2024-46722",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46722"
},
{
"name": "CVE-2024-46723",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46723"
},
{
"name": "CVE-2024-46724",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46724"
},
{
"name": "CVE-2024-46725",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46725"
},
{
"name": "CVE-2024-46731",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46731"
},
{
"name": "CVE-2024-46732",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46732"
},
{
"name": "CVE-2024-46737",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46737"
},
{
"name": "CVE-2024-46738",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46738"
},
{
"name": "CVE-2024-46739",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46739"
},
{
"name": "CVE-2024-46740",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46740"
},
{
"name": "CVE-2024-46743",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46743"
},
{
"name": "CVE-2024-46744",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46744"
},
{
"name": "CVE-2024-46745",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46745"
},
{
"name": "CVE-2024-46746",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46746"
},
{
"name": "CVE-2024-46747",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46747"
},
{
"name": "CVE-2024-46750",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46750"
},
{
"name": "CVE-2024-46752",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46752"
},
{
"name": "CVE-2024-46755",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46755"
},
{
"name": "CVE-2024-46756",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46756"
},
{
"name": "CVE-2024-46757",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46757"
},
{
"name": "CVE-2024-46758",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46758"
},
{
"name": "CVE-2024-46759",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46759"
},
{
"name": "CVE-2024-46761",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46761"
},
{
"name": "CVE-2024-46763",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46763"
},
{
"name": "CVE-2024-46771",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46771"
},
{
"name": "CVE-2024-46777",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46777"
},
{
"name": "CVE-2024-46780",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46780"
},
{
"name": "CVE-2024-46781",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46781"
},
{
"name": "CVE-2024-46782",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46782"
},
{
"name": "CVE-2024-46783",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46783"
},
{
"name": "CVE-2024-46791",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46791"
},
{
"name": "CVE-2024-46795",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46795"
},
{
"name": "CVE-2024-46798",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46798"
},
{
"name": "CVE-2024-46800",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46800"
},
{
"name": "CVE-2024-46804",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46804"
},
{
"name": "CVE-2024-46805",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46805"
},
{
"name": "CVE-2024-46807",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46807"
},
{
"name": "CVE-2024-46810",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46810"
},
{
"name": "CVE-2024-46814",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46814"
},
{
"name": "CVE-2024-46815",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46815"
},
{
"name": "CVE-2024-46817",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46817"
},
{
"name": "CVE-2024-46818",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46818"
},
{
"name": "CVE-2024-46819",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46819"
},
{
"name": "CVE-2024-46822",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46822"
},
{
"name": "CVE-2024-46828",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46828"
},
{
"name": "CVE-2024-46829",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46829"
},
{
"name": "CVE-2024-46832",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46832"
},
{
"name": "CVE-2024-46840",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46840"
},
{
"name": "CVE-2024-46844",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46844"
},
{
"name": "CVE-2024-42272",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42272"
},
{
"name": "CVE-2024-42297",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42297"
},
{
"name": "CVE-2024-41082",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41082"
},
{
"name": "CVE-2024-42252",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42252"
},
{
"name": "CVE-2024-42265",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42265"
},
{
"name": "CVE-2024-42304",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42304"
},
{
"name": "CVE-2024-42305",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42305"
},
{
"name": "CVE-2024-42306",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42306"
},
{
"name": "CVE-2024-43828",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43828"
},
{
"name": "CVE-2024-43870",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43870"
},
{
"name": "CVE-2024-43890",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43890"
},
{
"name": "CVE-2024-43914",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43914"
},
{
"name": "CVE-2024-44935",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44935"
},
{
"name": "CVE-2024-44944",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44944"
},
{
"name": "CVE-2024-44948",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44948"
},
{
"name": "CVE-2024-44952",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44952"
},
{
"name": "CVE-2024-44954",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44954"
},
{
"name": "CVE-2024-44960",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44960"
},
{
"name": "CVE-2024-44965",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44965"
},
{
"name": "CVE-2024-44969",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44969"
},
{
"name": "CVE-2024-44971",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44971"
},
{
"name": "CVE-2024-47668",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47668"
},
{
"name": "CVE-2023-52888",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52888"
},
{
"name": "CVE-2023-52918",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52918"
},
{
"name": "CVE-2024-41018",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41018"
},
{
"name": "CVE-2024-41019",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41019"
},
{
"name": "CVE-2024-41021",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41021"
},
{
"name": "CVE-2024-41029",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41029"
},
{
"name": "CVE-2024-41030",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41030"
},
{
"name": "CVE-2024-41033",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41033"
},
{
"name": "CVE-2024-41052",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41052"
},
{
"name": "CVE-2024-41053",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41053"
},
{
"name": "CVE-2024-41054",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41054"
},
{
"name": "CVE-2024-41067",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41067"
},
{
"name": "CVE-2024-41083",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41083"
},
{
"name": "CVE-2024-41085",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41085"
},
{
"name": "CVE-2024-41086",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41086"
},
{
"name": "CVE-2024-42063",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42063"
},
{
"name": "CVE-2024-42065",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42065"
},
{
"name": "CVE-2024-42066",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42066"
},
{
"name": "CVE-2024-42067",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42067"
},
{
"name": "CVE-2024-42088",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42088"
},
{
"name": "CVE-2024-42091",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42091"
},
{
"name": "CVE-2024-42100",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42100"
},
{
"name": "CVE-2024-42103",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42103"
},
{
"name": "CVE-2024-42108",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42108"
},
{
"name": "CVE-2024-42111",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42111"
},
{
"name": "CVE-2024-42112",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42112"
},
{
"name": "CVE-2024-42118",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42118"
},
{
"name": "CVE-2024-42128",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42128"
},
{
"name": "CVE-2024-42129",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42129"
},
{
"name": "CVE-2024-42135",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42135"
},
{
"name": "CVE-2024-42146",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42146"
},
{
"name": "CVE-2024-42149",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42149"
},
{
"name": "CVE-2024-42150",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42150"
},
{
"name": "CVE-2024-42151",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42151"
},
{
"name": "CVE-2024-42231",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42231"
},
{
"name": "CVE-2024-42234",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42234"
},
{
"name": "CVE-2024-42235",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42235"
},
{
"name": "CVE-2024-42248",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42248"
},
{
"name": "CVE-2024-42251",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42251"
},
{
"name": "CVE-2024-47659",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47659"
},
{
"name": "CVE-2024-47663",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47663"
},
{
"name": "CVE-2024-47667",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47667"
},
{
"name": "CVE-2024-47669",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47669"
},
{
"name": "CVE-2020-8608",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-8608"
},
{
"name": "CVE-2021-3592",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-3592"
},
{
"name": "CVE-2021-3594",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-3594"
},
{
"name": "CVE-2023-3019",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-3019"
},
{
"name": "CVE-2024-42267",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42267"
},
{
"name": "CVE-2024-42296",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42296"
},
{
"name": "CVE-2024-42299",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42299"
},
{
"name": "CVE-2024-43869",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43869"
},
{
"name": "CVE-2024-44934",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44934"
},
{
"name": "CVE-2024-44958",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44958"
},
{
"name": "CVE-2024-44966",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44966"
},
{
"name": "CVE-2024-4693",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-4693"
},
{
"name": "CVE-2024-47660",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47660"
},
{
"name": "CVE-2024-47665",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47665"
},
{
"name": "CVE-2024-7730",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-7730"
}
],
"initial_release_date": "2024-11-18T00:00:00",
"last_revision_date": "2024-11-18T00:00:00",
"links": [],
"reference": "CERTFR-2024-AVI-0997",
"revisions": [
{
"description": "Version initiale",
"revision_date": "2024-11-18T00: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 le noyau Linux d\u0027Ubuntu. Certaines d\u0027entre elles permettent \u00e0 un attaquant de provoquer une ex\u00e9cution de code arbitraire \u00e0 distance, une \u00e9l\u00e9vation de privil\u00e8ges et un d\u00e9ni de service \u00e0 distance.",
"title": "Multiples vuln\u00e9rabilit\u00e9s dans le noyau Linux d\u0027Ubuntu",
"vendor_advisories": [
{
"published_at": "2024-11-14",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7089-5",
"url": "https://ubuntu.com/security/notices/USN-7089-5"
},
{
"published_at": "2024-11-11",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7100-1",
"url": "https://ubuntu.com/security/notices/USN-7100-1"
},
{
"published_at": "2024-11-14",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7110-1",
"url": "https://ubuntu.com/security/notices/USN-7110-1"
},
{
"published_at": "2024-11-15",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7089-6",
"url": "https://ubuntu.com/security/notices/USN-7089-6"
},
{
"published_at": "2024-11-12",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7100-2",
"url": "https://ubuntu.com/security/notices/USN-7100-2"
},
{
"published_at": "2024-11-13",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7089-4",
"url": "https://ubuntu.com/security/notices/USN-7089-4"
},
{
"published_at": "2024-11-14",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7088-5",
"url": "https://ubuntu.com/security/notices/USN-7088-5"
},
{
"published_at": "2024-11-14",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7071-2",
"url": "https://ubuntu.com/security/notices/USN-7071-2"
},
{
"published_at": "2024-11-08",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7094-1",
"url": "https://ubuntu.com/security/notices/USN-7094-1"
}
]
}
CERTFR-2024-AVI-1013
Vulnerability from certfr_avis - Published: 2024-11-22 - Updated: 2024-11-22
De multiples vulnérabilités ont été découvertes dans le noyau Linux d'Ubuntu. Certaines d'entre elles permettent à un attaquant de provoquer une exécution de code arbitraire, une é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| Title | Publication Time | Tags | |||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||
{
"$ref": "https://www.cert.ssi.gouv.fr/openapi.json",
"affected_systems": [
{
"description": "Ubuntu 16.04 ESM",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 24.04 LTS",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 18.04 ESM",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 20.04 LTS",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 14.04 ESM",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 22.04 LTS",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
}
],
"affected_systems_content": 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-2022-36402",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-36402"
},
{
"name": "CVE-2023-6610",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-6610"
},
{
"name": "CVE-2024-25744",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-25744"
},
{
"name": "CVE-2023-52599",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52599"
},
{
"name": "CVE-2023-52531",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52531"
},
{
"name": "CVE-2023-52502",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52502"
},
{
"name": "CVE-2024-26607",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26607"
},
{
"name": "CVE-2024-26633",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26633"
},
{
"name": "CVE-2023-52434",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52434"
},
{
"name": "CVE-2023-52612",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52612"
},
{
"name": "CVE-2023-52639",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52639"
},
{
"name": "CVE-2024-26800",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26800"
},
{
"name": "CVE-2024-26787",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26787"
},
{
"name": "CVE-2024-26675",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26675"
},
{
"name": "CVE-2024-26640",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26640"
},
{
"name": "CVE-2024-26641",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26641"
},
{
"name": "CVE-2023-52572",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52572"
},
{
"name": "CVE-2023-52578",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52578"
},
{
"name": "CVE-2024-26960",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26960"
},
{
"name": "CVE-2024-27051",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27051"
},
{
"name": "CVE-2024-26885",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26885"
},
{
"name": "CVE-2024-26636",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26636"
},
{
"name": "CVE-2023-52614",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52614"
},
{
"name": "CVE-2024-26891",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26891"
},
{
"name": "CVE-2024-26668",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26668"
},
{
"name": "CVE-2024-26669",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26669"
},
{
"name": "CVE-2021-47212",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47212"
},
{
"name": "CVE-2024-26893",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26893"
},
{
"name": "CVE-2021-47188",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47188"
},
{
"name": "CVE-2024-35848",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35848"
},
{
"name": "CVE-2024-36953",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36953"
},
{
"name": "CVE-2023-52757",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52757"
},
{
"name": "CVE-2024-35877",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35877"
},
{
"name": "CVE-2024-36020",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36020"
},
{
"name": "CVE-2024-38560",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38560"
},
{
"name": "CVE-2024-38596",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38596"
},
{
"name": "CVE-2024-38637",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38637"
},
{
"name": "CVE-2024-27397",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27397"
},
{
"name": "CVE-2022-48733",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48733"
},
{
"name": "CVE-2024-38630",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38630"
},
{
"name": "CVE-2024-26661",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26661"
},
{
"name": "CVE-2024-26677",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26677"
},
{
"name": "CVE-2024-27012",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27012"
},
{
"name": "CVE-2024-25741",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-25741"
},
{
"name": "CVE-2024-39487",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39487"
},
{
"name": "CVE-2024-39494",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39494"
},
{
"name": "CVE-2024-40915",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40915"
},
{
"name": "CVE-2024-40929",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40929"
},
{
"name": "CVE-2024-38570",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38570"
},
{
"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-38538",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38538"
},
{
"name": "CVE-2024-38577",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38577"
},
{
"name": "CVE-2024-41011",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41011"
},
{
"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-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-2022-48791",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48791"
},
{
"name": "CVE-2022-48863",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48863"
},
{
"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-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-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-42230",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42230"
},
{
"name": "CVE-2022-48666",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48666"
},
{
"name": "CVE-2024-36484",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36484"
},
{
"name": "CVE-2024-41007",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41007"
},
{
"name": "CVE-2024-41020",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41020"
},
{
"name": "CVE-2024-41022",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41022"
},
{
"name": "CVE-2024-41034",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41034"
},
{
"name": "CVE-2024-41035",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41035"
},
{
"name": "CVE-2024-41046",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41046"
},
{
"name": "CVE-2024-41049",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41049"
},
{
"name": "CVE-2024-41055",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41055"
},
{
"name": "CVE-2024-41065",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41065"
},
{
"name": "CVE-2024-41068",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41068"
},
{
"name": "CVE-2024-41077",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41077"
},
{
"name": "CVE-2024-42101",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42101"
},
{
"name": "CVE-2024-42102",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42102"
},
{
"name": "CVE-2024-42104",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42104"
},
{
"name": "CVE-2024-42106",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42106"
},
{
"name": "CVE-2024-42115",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42115"
},
{
"name": "CVE-2024-42121",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42121"
},
{
"name": "CVE-2024-42127",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42127"
},
{
"name": "CVE-2024-42131",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42131"
},
{
"name": "CVE-2024-42137",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42137"
},
{
"name": "CVE-2024-42152",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42152"
},
{
"name": "CVE-2024-42153",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42153"
},
{
"name": "CVE-2024-42157",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42157"
},
{
"name": "CVE-2024-42229",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42229"
},
{
"name": "CVE-2024-42232",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42232"
},
{
"name": "CVE-2024-42236",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42236"
},
{
"name": "CVE-2024-42244",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42244"
},
{
"name": "CVE-2024-42247",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42247"
},
{
"name": "CVE-2024-42110",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42110"
},
{
"name": "CVE-2024-41073",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41073"
},
{
"name": "CVE-2024-41096",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41096"
},
{
"name": "CVE-2024-42082",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42082"
},
{
"name": "CVE-2023-52887",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52887"
},
{
"name": "CVE-2024-41027",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41027"
},
{
"name": "CVE-2024-41047",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41047"
},
{
"name": "CVE-2024-41092",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41092"
},
{
"name": "CVE-2024-41093",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41093"
},
{
"name": "CVE-2024-41097",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41097"
},
{
"name": "CVE-2024-42068",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42068"
},
{
"name": "CVE-2024-42076",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42076"
},
{
"name": "CVE-2024-42077",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42077"
},
{
"name": "CVE-2024-42080",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42080"
},
{
"name": "CVE-2024-42084",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42084"
},
{
"name": "CVE-2024-42085",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42085"
},
{
"name": "CVE-2024-42086",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42086"
},
{
"name": "CVE-2024-42087",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42087"
},
{
"name": "CVE-2024-42089",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42089"
},
{
"name": "CVE-2024-42090",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42090"
},
{
"name": "CVE-2024-42092",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42092"
},
{
"name": "CVE-2024-42094",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42094"
},
{
"name": "CVE-2024-42095",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42095"
},
{
"name": "CVE-2024-42097",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42097"
},
{
"name": "CVE-2024-42098",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42098"
},
{
"name": "CVE-2024-42109",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42109"
},
{
"name": "CVE-2024-42130",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42130"
},
{
"name": "CVE-2024-42140",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42140"
},
{
"name": "CVE-2024-42225",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42225"
},
{
"name": "CVE-2024-42240",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42240"
},
{
"name": "CVE-2022-48938",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48938"
},
{
"name": "CVE-2022-48943",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48943"
},
{
"name": "CVE-2023-52889",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52889"
},
{
"name": "CVE-2024-39486",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39486"
},
{
"name": "CVE-2024-41010",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41010"
},
{
"name": "CVE-2024-41025",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41025"
},
{
"name": "CVE-2024-41028",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41028"
},
{
"name": "CVE-2024-41032",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41032"
},
{
"name": "CVE-2024-41036",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41036"
},
{
"name": "CVE-2024-41037",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41037"
},
{
"name": "CVE-2024-41038",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41038"
},
{
"name": "CVE-2024-41039",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41039"
},
{
"name": "CVE-2024-41042",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41042"
},
{
"name": "CVE-2024-41045",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41045"
},
{
"name": "CVE-2024-41050",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41050"
},
{
"name": "CVE-2024-41051",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41051"
},
{
"name": "CVE-2024-41056",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41056"
},
{
"name": "CVE-2024-41061",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41061"
},
{
"name": "CVE-2024-41062",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41062"
},
{
"name": "CVE-2024-41074",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41074"
},
{
"name": "CVE-2024-41075",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41075"
},
{
"name": "CVE-2024-41079",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41079"
},
{
"name": "CVE-2024-41080",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41080"
},
{
"name": "CVE-2024-41084",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41084"
},
{
"name": "CVE-2024-41088",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41088"
},
{
"name": "CVE-2024-41094",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41094"
},
{
"name": "CVE-2024-41098",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41098"
},
{
"name": "CVE-2024-42064",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42064"
},
{
"name": "CVE-2024-42069",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42069"
},
{
"name": "CVE-2024-42073",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42073"
},
{
"name": "CVE-2024-42074",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42074"
},
{
"name": "CVE-2024-42113",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42113"
},
{
"name": "CVE-2024-42114",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42114"
},
{
"name": "CVE-2024-42117",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42117"
},
{
"name": "CVE-2024-42126",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42126"
},
{
"name": "CVE-2024-42132",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42132"
},
{
"name": "CVE-2024-42133",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42133"
},
{
"name": "CVE-2024-42136",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42136"
},
{
"name": "CVE-2024-42138",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42138"
},
{
"name": "CVE-2024-42141",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42141"
},
{
"name": "CVE-2024-42142",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42142"
},
{
"name": "CVE-2024-42144",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42144"
},
{
"name": "CVE-2024-42147",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42147"
},
{
"name": "CVE-2024-42155",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42155"
},
{
"name": "CVE-2024-42156",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42156"
},
{
"name": "CVE-2024-42158",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42158"
},
{
"name": "CVE-2024-42227",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42227"
},
{
"name": "CVE-2024-42228",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42228"
},
{
"name": "CVE-2024-42237",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42237"
},
{
"name": "CVE-2024-42238",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42238"
},
{
"name": "CVE-2024-42239",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42239"
},
{
"name": "CVE-2024-42241",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42241"
},
{
"name": "CVE-2024-42245",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42245"
},
{
"name": "CVE-2024-42246",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42246"
},
{
"name": "CVE-2024-42250",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42250"
},
{
"name": "CVE-2024-42253",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42253"
},
{
"name": "CVE-2024-42259",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42259"
},
{
"name": "CVE-2024-42269",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42269"
},
{
"name": "CVE-2024-42271",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42271"
},
{
"name": "CVE-2024-42274",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42274"
},
{
"name": "CVE-2024-42276",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42276"
},
{
"name": "CVE-2024-42277",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42277"
},
{
"name": "CVE-2024-42280",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42280"
},
{
"name": "CVE-2024-42281",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42281"
},
{
"name": "CVE-2024-42283",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42283"
},
{
"name": "CVE-2024-42284",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42284"
},
{
"name": "CVE-2024-42285",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42285"
},
{
"name": "CVE-2024-42286",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42286"
},
{
"name": "CVE-2024-42287",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42287"
},
{
"name": "CVE-2024-42288",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42288"
},
{
"name": "CVE-2024-42289",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42289"
},
{
"name": "CVE-2024-42290",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42290"
},
{
"name": "CVE-2024-42292",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42292"
},
{
"name": "CVE-2024-42295",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42295"
},
{
"name": "CVE-2024-42301",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42301"
},
{
"name": "CVE-2024-42302",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42302"
},
{
"name": "CVE-2024-42309",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42309"
},
{
"name": "CVE-2024-42310",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42310"
},
{
"name": "CVE-2024-42311",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42311"
},
{
"name": "CVE-2024-42312",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42312"
},
{
"name": "CVE-2024-42313",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42313"
},
{
"name": "CVE-2024-42318",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42318"
},
{
"name": "CVE-2024-43817",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43817"
},
{
"name": "CVE-2024-43829",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43829"
},
{
"name": "CVE-2024-43830",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43830"
},
{
"name": "CVE-2024-43834",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43834"
},
{
"name": "CVE-2024-43839",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43839"
},
{
"name": "CVE-2024-43841",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43841"
},
{
"name": "CVE-2024-43846",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43846"
},
{
"name": "CVE-2024-43849",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43849"
},
{
"name": "CVE-2024-43853",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43853"
},
{
"name": "CVE-2024-43854",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43854"
},
{
"name": "CVE-2024-43855",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43855"
},
{
"name": "CVE-2024-43856",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43856"
},
{
"name": "CVE-2024-43858",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43858"
},
{
"name": "CVE-2024-43860",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43860"
},
{
"name": "CVE-2024-43861",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43861"
},
{
"name": "CVE-2024-43863",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43863"
},
{
"name": "CVE-2024-43867",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43867"
},
{
"name": "CVE-2024-43871",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43871"
},
{
"name": "CVE-2024-43873",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43873"
},
{
"name": "CVE-2024-43875",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43875"
},
{
"name": "CVE-2024-43879",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43879"
},
{
"name": "CVE-2024-43880",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43880"
},
{
"name": "CVE-2024-43882",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43882"
},
{
"name": "CVE-2024-43883",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43883"
},
{
"name": "CVE-2024-43884",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43884"
},
{
"name": "CVE-2024-43889",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43889"
},
{
"name": "CVE-2024-43892",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43892"
},
{
"name": "CVE-2024-43893",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43893"
},
{
"name": "CVE-2024-43894",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43894"
},
{
"name": "CVE-2024-43902",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43902"
},
{
"name": "CVE-2024-43905",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43905"
},
{
"name": "CVE-2024-43907",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43907"
},
{
"name": "CVE-2024-43908",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43908"
},
{
"name": "CVE-2024-43909",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43909"
},
{
"name": "CVE-2024-44947",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44947"
},
{
"name": "CVE-2024-41023",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41023"
},
{
"name": "CVE-2024-41031",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41031"
},
{
"name": "CVE-2024-42243",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42243"
},
{
"name": "CVE-2024-42160",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42160"
},
{
"name": "CVE-2024-45003",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45003"
},
{
"name": "CVE-2024-43835",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43835"
},
{
"name": "CVE-2024-44946",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44946"
},
{
"name": "CVE-2024-44974",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44974"
},
{
"name": "CVE-2024-44982",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44982"
},
{
"name": "CVE-2024-44983",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44983"
},
{
"name": "CVE-2024-44985",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44985"
},
{
"name": "CVE-2024-44986",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44986"
},
{
"name": "CVE-2024-44987",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44987"
},
{
"name": "CVE-2024-44988",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44988"
},
{
"name": "CVE-2024-44989",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44989"
},
{
"name": "CVE-2024-44990",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44990"
},
{
"name": "CVE-2024-44995",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44995"
},
{
"name": "CVE-2024-44998",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44998"
},
{
"name": "CVE-2024-44999",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44999"
},
{
"name": "CVE-2024-45006",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45006"
},
{
"name": "CVE-2024-45007",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45007"
},
{
"name": "CVE-2024-45008",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45008"
},
{
"name": "CVE-2024-45009",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45009"
},
{
"name": "CVE-2024-45011",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45011"
},
{
"name": "CVE-2024-45016",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45016"
},
{
"name": "CVE-2024-45018",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45018"
},
{
"name": "CVE-2024-45021",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45021"
},
{
"name": "CVE-2024-45025",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45025"
},
{
"name": "CVE-2024-45026",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45026"
},
{
"name": "CVE-2024-45028",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45028"
},
{
"name": "CVE-2024-46673",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46673"
},
{
"name": "CVE-2024-46675",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46675"
},
{
"name": "CVE-2024-46676",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46676"
},
{
"name": "CVE-2024-46677",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46677"
},
{
"name": "CVE-2024-46679",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46679"
},
{
"name": "CVE-2024-46685",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46685"
},
{
"name": "CVE-2024-46689",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46689"
},
{
"name": "CVE-2024-46702",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46702"
},
{
"name": "CVE-2024-46707",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46707"
},
{
"name": "CVE-2024-46713",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46713"
},
{
"name": "CVE-2024-46714",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46714"
},
{
"name": "CVE-2024-46719",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46719"
},
{
"name": "CVE-2024-46721",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46721"
},
{
"name": "CVE-2024-46722",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46722"
},
{
"name": "CVE-2024-46723",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46723"
},
{
"name": "CVE-2024-46724",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46724"
},
{
"name": "CVE-2024-46725",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46725"
},
{
"name": "CVE-2024-46731",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46731"
},
{
"name": "CVE-2024-46732",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46732"
},
{
"name": "CVE-2024-46737",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46737"
},
{
"name": "CVE-2024-46738",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46738"
},
{
"name": "CVE-2024-46739",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46739"
},
{
"name": "CVE-2024-46740",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46740"
},
{
"name": "CVE-2024-46743",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46743"
},
{
"name": "CVE-2024-46744",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46744"
},
{
"name": "CVE-2024-46745",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46745"
},
{
"name": "CVE-2024-46746",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46746"
},
{
"name": "CVE-2024-46747",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46747"
},
{
"name": "CVE-2024-46750",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46750"
},
{
"name": "CVE-2024-46752",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46752"
},
{
"name": "CVE-2024-46755",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46755"
},
{
"name": "CVE-2024-46756",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46756"
},
{
"name": "CVE-2024-46757",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46757"
},
{
"name": "CVE-2024-46758",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46758"
},
{
"name": "CVE-2024-46759",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46759"
},
{
"name": "CVE-2024-46761",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46761"
},
{
"name": "CVE-2024-46763",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46763"
},
{
"name": "CVE-2024-46771",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46771"
},
{
"name": "CVE-2024-46777",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46777"
},
{
"name": "CVE-2024-46780",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46780"
},
{
"name": "CVE-2024-46781",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46781"
},
{
"name": "CVE-2024-46782",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46782"
},
{
"name": "CVE-2024-46783",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46783"
},
{
"name": "CVE-2024-46791",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46791"
},
{
"name": "CVE-2024-46795",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46795"
},
{
"name": "CVE-2024-46798",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46798"
},
{
"name": "CVE-2024-46800",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46800"
},
{
"name": "CVE-2024-46804",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46804"
},
{
"name": "CVE-2024-46805",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46805"
},
{
"name": "CVE-2024-46807",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46807"
},
{
"name": "CVE-2024-46810",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46810"
},
{
"name": "CVE-2024-46814",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46814"
},
{
"name": "CVE-2024-46815",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46815"
},
{
"name": "CVE-2024-46817",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46817"
},
{
"name": "CVE-2024-46818",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46818"
},
{
"name": "CVE-2024-46819",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46819"
},
{
"name": "CVE-2024-46822",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46822"
},
{
"name": "CVE-2024-46828",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46828"
},
{
"name": "CVE-2024-46829",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46829"
},
{
"name": "CVE-2024-46832",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46832"
},
{
"name": "CVE-2024-46840",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46840"
},
{
"name": "CVE-2024-46844",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46844"
},
{
"name": "CVE-2024-42272",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42272"
},
{
"name": "CVE-2024-42297",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42297"
},
{
"name": "CVE-2024-41082",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41082"
},
{
"name": "CVE-2024-42252",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42252"
},
{
"name": "CVE-2024-42265",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42265"
},
{
"name": "CVE-2024-42304",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42304"
},
{
"name": "CVE-2024-42305",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42305"
},
{
"name": "CVE-2024-42306",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42306"
},
{
"name": "CVE-2024-43828",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43828"
},
{
"name": "CVE-2024-43870",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43870"
},
{
"name": "CVE-2024-43890",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43890"
},
{
"name": "CVE-2024-43914",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43914"
},
{
"name": "CVE-2024-44935",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44935"
},
{
"name": "CVE-2024-44944",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44944"
},
{
"name": "CVE-2024-44948",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44948"
},
{
"name": "CVE-2024-44954",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44954"
},
{
"name": "CVE-2024-44960",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44960"
},
{
"name": "CVE-2024-44965",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44965"
},
{
"name": "CVE-2024-44969",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44969"
},
{
"name": "CVE-2024-44971",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44971"
},
{
"name": "CVE-2024-47668",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47668"
},
{
"name": "CVE-2023-52888",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52888"
},
{
"name": "CVE-2023-52918",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52918"
},
{
"name": "CVE-2024-41018",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41018"
},
{
"name": "CVE-2024-41019",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41019"
},
{
"name": "CVE-2024-41021",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41021"
},
{
"name": "CVE-2024-41029",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41029"
},
{
"name": "CVE-2024-41030",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41030"
},
{
"name": "CVE-2024-41033",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41033"
},
{
"name": "CVE-2024-41052",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41052"
},
{
"name": "CVE-2024-41053",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41053"
},
{
"name": "CVE-2024-41054",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41054"
},
{
"name": "CVE-2024-41067",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41067"
},
{
"name": "CVE-2024-41083",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41083"
},
{
"name": "CVE-2024-41085",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41085"
},
{
"name": "CVE-2024-41086",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41086"
},
{
"name": "CVE-2024-42063",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42063"
},
{
"name": "CVE-2024-42065",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42065"
},
{
"name": "CVE-2024-42066",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42066"
},
{
"name": "CVE-2024-42067",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42067"
},
{
"name": "CVE-2024-42088",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42088"
},
{
"name": "CVE-2024-42091",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42091"
},
{
"name": "CVE-2024-42100",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42100"
},
{
"name": "CVE-2024-42103",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42103"
},
{
"name": "CVE-2024-42108",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42108"
},
{
"name": "CVE-2024-42111",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42111"
},
{
"name": "CVE-2024-42112",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42112"
},
{
"name": "CVE-2024-42118",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42118"
},
{
"name": "CVE-2024-42128",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42128"
},
{
"name": "CVE-2024-42129",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42129"
},
{
"name": "CVE-2024-42135",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42135"
},
{
"name": "CVE-2024-42146",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42146"
},
{
"name": "CVE-2024-42149",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42149"
},
{
"name": "CVE-2024-42150",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42150"
},
{
"name": "CVE-2024-42151",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42151"
},
{
"name": "CVE-2024-42231",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42231"
},
{
"name": "CVE-2024-42234",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42234"
},
{
"name": "CVE-2024-42235",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42235"
},
{
"name": "CVE-2024-42248",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42248"
},
{
"name": "CVE-2024-42251",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42251"
},
{
"name": "CVE-2024-47659",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47659"
},
{
"name": "CVE-2024-47663",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47663"
},
{
"name": "CVE-2024-47667",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47667"
},
{
"name": "CVE-2024-47669",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47669"
},
{
"name": "CVE-2024-42267",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42267"
},
{
"name": "CVE-2024-42296",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42296"
},
{
"name": "CVE-2024-42299",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42299"
},
{
"name": "CVE-2024-43869",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43869"
},
{
"name": "CVE-2024-44934",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44934"
},
{
"name": "CVE-2024-44958",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44958"
},
{
"name": "CVE-2024-44966",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44966"
},
{
"name": "CVE-2024-47660",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47660"
},
{
"name": "CVE-2024-47665",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47665"
},
{
"name": "CVE-2024-44942",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44942"
}
],
"initial_release_date": "2024-11-22T00:00:00",
"last_revision_date": "2024-11-22T00:00:00",
"links": [],
"reference": "CERTFR-2024-AVI-1013",
"revisions": [
{
"description": "Version initiale",
"revision_date": "2024-11-22T00: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 d\u0027Ubuntu. 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 d\u0027Ubuntu",
"vendor_advisories": [
{
"published_at": "2024-11-20",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7123-1",
"url": "https://ubuntu.com/security/notices/USN-7123-1"
},
{
"published_at": "2024-11-20",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7121-2",
"url": "https://ubuntu.com/security/notices/USN-7121-2"
},
{
"published_at": "2024-11-21",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7120-3",
"url": "https://ubuntu.com/security/notices/USN-7120-3"
},
{
"published_at": "2024-11-19",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7119-1",
"url": "https://ubuntu.com/security/notices/USN-7119-1"
},
{
"published_at": "2024-11-19",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7089-7",
"url": "https://ubuntu.com/security/notices/USN-7089-7"
},
{
"published_at": "2024-11-20",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7120-2",
"url": "https://ubuntu.com/security/notices/USN-7120-2"
},
{
"published_at": "2024-11-19",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7121-1",
"url": "https://ubuntu.com/security/notices/USN-7121-1"
},
{
"published_at": "2024-11-19",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7120-1",
"url": "https://ubuntu.com/security/notices/USN-7120-1"
},
{
"published_at": "2024-11-19",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7122-1",
"url": "https://ubuntu.com/security/notices/USN-7122-1"
}
]
}
CERTFR-2024-AVI-1080
Vulnerability from certfr_avis - Published: 2024-12-13 - Updated: 2024-12-13
De multiples vulnérabilités ont été découvertes dans le noyau Linux d'Ubuntu. Elles permettent à un attaquant de provoquer un problème de sécurité non spécifié par l'éditeur.
Solutions
Se référer au bulletin de sécurité de l'éditeur pour l'obtention des correctifs (cf. section Documentation).
None| Title | Publication Time | Tags | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||
{
"$ref": "https://www.cert.ssi.gouv.fr/openapi.json",
"affected_systems": [
{
"description": "Ubuntu 16.04 ESM",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 24.04 LTS",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 18.04 ESM",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 20.04 LTS",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 14.04 ESM",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 22.04 LTS",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
}
],
"affected_systems_content": 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-2022-24448",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-24448"
},
{
"name": "CVE-2024-25744",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-25744"
},
{
"name": "CVE-2023-52599",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52599"
},
{
"name": "CVE-2021-47076",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47076"
},
{
"name": "CVE-2023-52531",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52531"
},
{
"name": "CVE-2023-52502",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52502"
},
{
"name": "CVE-2024-26607",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26607"
},
{
"name": "CVE-2024-26633",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26633"
},
{
"name": "CVE-2023-52639",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52639"
},
{
"name": "CVE-2023-52497",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52497"
},
{
"name": "CVE-2024-26800",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26800"
},
{
"name": "CVE-2024-26675",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26675"
},
{
"name": "CVE-2023-52488",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52488"
},
{
"name": "CVE-2021-47055",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47055"
},
{
"name": "CVE-2023-52578",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52578"
},
{
"name": "CVE-2023-52498",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52498"
},
{
"name": "CVE-2024-26636",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26636"
},
{
"name": "CVE-2023-52614",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52614"
},
{
"name": "CVE-2024-27022",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27022"
},
{
"name": "CVE-2024-26668",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26668"
},
{
"name": "CVE-2024-26669",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26669"
},
{
"name": "CVE-2024-26893",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26893"
},
{
"name": "CVE-2024-36953",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36953"
},
{
"name": "CVE-2021-47501",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47501"
},
{
"name": "CVE-2024-35877",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35877"
},
{
"name": "CVE-2024-35904",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35904"
},
{
"name": "CVE-2024-35951",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35951"
},
{
"name": "CVE-2024-36938",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36938"
},
{
"name": "CVE-2024-38560",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38560"
},
{
"name": "CVE-2024-27397",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27397"
},
{
"name": "CVE-2024-26947",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26947"
},
{
"name": "CVE-2022-48733",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48733"
},
{
"name": "CVE-2024-26661",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26661"
},
{
"name": "CVE-2024-25741",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-25741"
},
{
"name": "CVE-2024-39487",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39487"
},
{
"name": "CVE-2024-40915",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40915"
},
{
"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-36968",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36968"
},
{
"name": "CVE-2024-38538",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38538"
},
{
"name": "CVE-2024-38577",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38577"
},
{
"name": "CVE-2024-41011",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41011"
},
{
"name": "CVE-2024-39472",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39472"
},
{
"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-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-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-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"
},
{
"name": "CVE-2022-48666",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48666"
},
{
"name": "CVE-2024-36484",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36484"
},
{
"name": "CVE-2024-41007",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41007"
},
{
"name": "CVE-2024-41020",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41020"
},
{
"name": "CVE-2024-41022",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41022"
},
{
"name": "CVE-2024-41034",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41034"
},
{
"name": "CVE-2024-41035",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41035"
},
{
"name": "CVE-2024-41046",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41046"
},
{
"name": "CVE-2024-41049",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41049"
},
{
"name": "CVE-2024-41055",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41055"
},
{
"name": "CVE-2024-41065",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41065"
},
{
"name": "CVE-2024-41068",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41068"
},
{
"name": "CVE-2024-41077",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41077"
},
{
"name": "CVE-2024-42101",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42101"
},
{
"name": "CVE-2024-42102",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42102"
},
{
"name": "CVE-2024-42104",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42104"
},
{
"name": "CVE-2024-42106",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42106"
},
{
"name": "CVE-2024-42115",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42115"
},
{
"name": "CVE-2024-42121",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42121"
},
{
"name": "CVE-2024-42127",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42127"
},
{
"name": "CVE-2024-42131",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42131"
},
{
"name": "CVE-2024-42137",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42137"
},
{
"name": "CVE-2024-42152",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42152"
},
{
"name": "CVE-2024-42153",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42153"
},
{
"name": "CVE-2024-42154",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42154"
},
{
"name": "CVE-2024-42157",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42157"
},
{
"name": "CVE-2024-42229",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42229"
},
{
"name": "CVE-2024-42232",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42232"
},
{
"name": "CVE-2024-42236",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42236"
},
{
"name": "CVE-2024-42244",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42244"
},
{
"name": "CVE-2024-42247",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42247"
},
{
"name": "CVE-2024-42110",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42110"
},
{
"name": "CVE-2024-41073",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41073"
},
{
"name": "CVE-2024-41096",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41096"
},
{
"name": "CVE-2024-42082",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42082"
},
{
"name": "CVE-2023-52887",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52887"
},
{
"name": "CVE-2024-41027",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41027"
},
{
"name": "CVE-2024-41047",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41047"
},
{
"name": "CVE-2024-41092",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41092"
},
{
"name": "CVE-2024-41093",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41093"
},
{
"name": "CVE-2024-41097",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41097"
},
{
"name": "CVE-2024-42068",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42068"
},
{
"name": "CVE-2024-42076",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42076"
},
{
"name": "CVE-2024-42077",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42077"
},
{
"name": "CVE-2024-42080",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42080"
},
{
"name": "CVE-2024-42084",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42084"
},
{
"name": "CVE-2024-42085",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42085"
},
{
"name": "CVE-2024-42086",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42086"
},
{
"name": "CVE-2024-42087",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42087"
},
{
"name": "CVE-2024-42089",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42089"
},
{
"name": "CVE-2024-42090",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42090"
},
{
"name": "CVE-2024-42092",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42092"
},
{
"name": "CVE-2024-42094",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42094"
},
{
"name": "CVE-2024-42095",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42095"
},
{
"name": "CVE-2024-42097",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42097"
},
{
"name": "CVE-2024-42098",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42098"
},
{
"name": "CVE-2024-42109",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42109"
},
{
"name": "CVE-2024-42130",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42130"
},
{
"name": "CVE-2024-42140",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42140"
},
{
"name": "CVE-2024-42225",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42225"
},
{
"name": "CVE-2024-42240",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42240"
},
{
"name": "CVE-2024-42270",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42270"
},
{
"name": "CVE-2022-48938",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48938"
},
{
"name": "CVE-2022-48943",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48943"
},
{
"name": "CVE-2023-52889",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52889"
},
{
"name": "CVE-2024-39486",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39486"
},
{
"name": "CVE-2024-41010",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41010"
},
{
"name": "CVE-2024-41025",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41025"
},
{
"name": "CVE-2024-41028",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41028"
},
{
"name": "CVE-2024-41032",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41032"
},
{
"name": "CVE-2024-41036",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41036"
},
{
"name": "CVE-2024-41037",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41037"
},
{
"name": "CVE-2024-41038",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41038"
},
{
"name": "CVE-2024-41039",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41039"
},
{
"name": "CVE-2024-41042",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41042"
},
{
"name": "CVE-2024-41045",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41045"
},
{
"name": "CVE-2024-41050",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41050"
},
{
"name": "CVE-2024-41051",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41051"
},
{
"name": "CVE-2024-41056",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41056"
},
{
"name": "CVE-2024-41061",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41061"
},
{
"name": "CVE-2024-41062",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41062"
},
{
"name": "CVE-2024-41074",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41074"
},
{
"name": "CVE-2024-41075",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41075"
},
{
"name": "CVE-2024-41079",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41079"
},
{
"name": "CVE-2024-41080",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41080"
},
{
"name": "CVE-2024-41084",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41084"
},
{
"name": "CVE-2024-41088",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41088"
},
{
"name": "CVE-2024-41094",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41094"
},
{
"name": "CVE-2024-41098",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41098"
},
{
"name": "CVE-2024-42064",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42064"
},
{
"name": "CVE-2024-42069",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42069"
},
{
"name": "CVE-2024-42073",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42073"
},
{
"name": "CVE-2024-42074",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42074"
},
{
"name": "CVE-2024-42113",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42113"
},
{
"name": "CVE-2024-42114",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42114"
},
{
"name": "CVE-2024-42117",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42117"
},
{
"name": "CVE-2024-42126",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42126"
},
{
"name": "CVE-2024-42132",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42132"
},
{
"name": "CVE-2024-42133",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42133"
},
{
"name": "CVE-2024-42136",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42136"
},
{
"name": "CVE-2024-42138",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42138"
},
{
"name": "CVE-2024-42141",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42141"
},
{
"name": "CVE-2024-42142",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42142"
},
{
"name": "CVE-2024-42144",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42144"
},
{
"name": "CVE-2024-42147",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42147"
},
{
"name": "CVE-2024-42155",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42155"
},
{
"name": "CVE-2024-42156",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42156"
},
{
"name": "CVE-2024-42158",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42158"
},
{
"name": "CVE-2024-42159",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42159"
},
{
"name": "CVE-2024-42227",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42227"
},
{
"name": "CVE-2024-42228",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42228"
},
{
"name": "CVE-2024-42237",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42237"
},
{
"name": "CVE-2024-42238",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42238"
},
{
"name": "CVE-2024-42239",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42239"
},
{
"name": "CVE-2024-42241",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42241"
},
{
"name": "CVE-2024-42245",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42245"
},
{
"name": "CVE-2024-42246",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42246"
},
{
"name": "CVE-2024-42250",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42250"
},
{
"name": "CVE-2024-42253",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42253"
},
{
"name": "CVE-2024-42259",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42259"
},
{
"name": "CVE-2024-42268",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42268"
},
{
"name": "CVE-2024-42269",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42269"
},
{
"name": "CVE-2024-42271",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42271"
},
{
"name": "CVE-2024-42274",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42274"
},
{
"name": "CVE-2024-42276",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42276"
},
{
"name": "CVE-2024-42277",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42277"
},
{
"name": "CVE-2024-42278",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42278"
},
{
"name": "CVE-2024-42279",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42279"
},
{
"name": "CVE-2024-42280",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42280"
},
{
"name": "CVE-2024-42281",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42281"
},
{
"name": "CVE-2024-42283",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42283"
},
{
"name": "CVE-2024-42284",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42284"
},
{
"name": "CVE-2024-42285",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42285"
},
{
"name": "CVE-2024-42286",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42286"
},
{
"name": "CVE-2024-42287",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42287"
},
{
"name": "CVE-2024-42288",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42288"
},
{
"name": "CVE-2024-42289",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42289"
},
{
"name": "CVE-2024-42290",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42290"
},
{
"name": "CVE-2024-42291",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42291"
},
{
"name": "CVE-2024-42292",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42292"
},
{
"name": "CVE-2024-42295",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42295"
},
{
"name": "CVE-2024-42298",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42298"
},
{
"name": "CVE-2024-42301",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42301"
},
{
"name": "CVE-2024-42302",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42302"
},
{
"name": "CVE-2024-42303",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42303"
},
{
"name": "CVE-2024-42309",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42309"
},
{
"name": "CVE-2024-42310",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42310"
},
{
"name": "CVE-2024-42311",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42311"
},
{
"name": "CVE-2024-42312",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42312"
},
{
"name": "CVE-2024-42313",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42313"
},
{
"name": "CVE-2024-42314",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42314"
},
{
"name": "CVE-2024-42315",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42315"
},
{
"name": "CVE-2024-42316",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42316"
},
{
"name": "CVE-2024-42318",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42318"
},
{
"name": "CVE-2024-42319",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42319"
},
{
"name": "CVE-2024-42320",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42320"
},
{
"name": "CVE-2024-42322",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42322"
},
{
"name": "CVE-2024-43817",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43817"
},
{
"name": "CVE-2024-43818",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43818"
},
{
"name": "CVE-2024-43819",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43819"
},
{
"name": "CVE-2024-43821",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43821"
},
{
"name": "CVE-2024-43823",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43823"
},
{
"name": "CVE-2024-43824",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43824"
},
{
"name": "CVE-2024-43825",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43825"
},
{
"name": "CVE-2024-43826",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43826"
},
{
"name": "CVE-2024-43829",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43829"
},
{
"name": "CVE-2024-43830",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43830"
},
{
"name": "CVE-2024-43831",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43831"
},
{
"name": "CVE-2024-43833",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43833"
},
{
"name": "CVE-2024-43834",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43834"
},
{
"name": "CVE-2024-43837",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43837"
},
{
"name": "CVE-2024-43839",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43839"
},
{
"name": "CVE-2024-43840",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43840"
},
{
"name": "CVE-2024-43841",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43841"
},
{
"name": "CVE-2024-43842",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43842"
},
{
"name": "CVE-2024-43846",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43846"
},
{
"name": "CVE-2024-43847",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43847"
},
{
"name": "CVE-2024-43849",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43849"
},
{
"name": "CVE-2024-43850",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43850"
},
{
"name": "CVE-2024-43853",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43853"
},
{
"name": "CVE-2024-43854",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43854"
},
{
"name": "CVE-2024-43855",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43855"
},
{
"name": "CVE-2024-43856",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43856"
},
{
"name": "CVE-2024-43858",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43858"
},
{
"name": "CVE-2024-43860",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43860"
},
{
"name": "CVE-2024-43861",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43861"
},
{
"name": "CVE-2024-43863",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43863"
},
{
"name": "CVE-2024-43864",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43864"
},
{
"name": "CVE-2024-43866",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43866"
},
{
"name": "CVE-2024-43867",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43867"
},
{
"name": "CVE-2024-43871",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43871"
},
{
"name": "CVE-2024-43873",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43873"
},
{
"name": "CVE-2024-43875",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43875"
},
{
"name": "CVE-2024-43876",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43876"
},
{
"name": "CVE-2024-43877",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43877"
},
{
"name": "CVE-2024-43879",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43879"
},
{
"name": "CVE-2024-43880",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43880"
},
{
"name": "CVE-2024-43881",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43881"
},
{
"name": "CVE-2024-43882",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43882"
},
{
"name": "CVE-2024-43883",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43883"
},
{
"name": "CVE-2024-43884",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43884"
},
{
"name": "CVE-2024-43889",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43889"
},
{
"name": "CVE-2024-43892",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43892"
},
{
"name": "CVE-2024-43893",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43893"
},
{
"name": "CVE-2024-43894",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43894"
},
{
"name": "CVE-2024-43895",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43895"
},
{
"name": "CVE-2024-43899",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43899"
},
{
"name": "CVE-2024-43900",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43900"
},
{
"name": "CVE-2024-43902",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43902"
},
{
"name": "CVE-2024-43904",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43904"
},
{
"name": "CVE-2024-43905",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43905"
},
{
"name": "CVE-2024-43906",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43906"
},
{
"name": "CVE-2024-43907",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43907"
},
{
"name": "CVE-2024-43908",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43908"
},
{
"name": "CVE-2024-43909",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43909"
},
{
"name": "CVE-2024-43911",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43911"
},
{
"name": "CVE-2024-43912",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43912"
},
{
"name": "CVE-2024-44931",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44931"
},
{
"name": "CVE-2024-44938",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44938"
},
{
"name": "CVE-2024-44939",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44939"
},
{
"name": "CVE-2024-44947",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44947"
},
{
"name": "CVE-2024-41023",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41023"
},
{
"name": "CVE-2024-41031",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41031"
},
{
"name": "CVE-2024-42243",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42243"
},
{
"name": "CVE-2024-42160",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42160"
},
{
"name": "CVE-2024-45003",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45003"
},
{
"name": "CVE-2024-43835",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43835"
},
{
"name": "CVE-2024-43859",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43859"
},
{
"name": "CVE-2024-44940",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44940"
},
{
"name": "CVE-2024-44946",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44946"
},
{
"name": "CVE-2024-44974",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44974"
},
{
"name": "CVE-2024-44977",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44977"
},
{
"name": "CVE-2024-44982",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44982"
},
{
"name": "CVE-2024-44983",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44983"
},
{
"name": "CVE-2024-44985",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44985"
},
{
"name": "CVE-2024-44986",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44986"
},
{
"name": "CVE-2024-44987",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44987"
},
{
"name": "CVE-2024-44988",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44988"
},
{
"name": "CVE-2024-44989",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44989"
},
{
"name": "CVE-2024-44990",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44990"
},
{
"name": "CVE-2024-44991",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44991"
},
{
"name": "CVE-2024-44995",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44995"
},
{
"name": "CVE-2024-44998",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44998"
},
{
"name": "CVE-2024-44999",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44999"
},
{
"name": "CVE-2024-45000",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45000"
},
{
"name": "CVE-2024-45002",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45002"
},
{
"name": "CVE-2024-45006",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45006"
},
{
"name": "CVE-2024-45007",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45007"
},
{
"name": "CVE-2024-45008",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45008"
},
{
"name": "CVE-2024-45009",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45009"
},
{
"name": "CVE-2024-45010",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45010"
},
{
"name": "CVE-2024-45011",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45011"
},
{
"name": "CVE-2024-45016",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45016"
},
{
"name": "CVE-2024-45018",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45018"
},
{
"name": "CVE-2024-45019",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45019"
},
{
"name": "CVE-2024-45021",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45021"
},
{
"name": "CVE-2024-45022",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45022"
},
{
"name": "CVE-2024-45025",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45025"
},
{
"name": "CVE-2024-45026",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45026"
},
{
"name": "CVE-2024-45028",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45028"
},
{
"name": "CVE-2024-45029",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45029"
},
{
"name": "CVE-2024-46673",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46673"
},
{
"name": "CVE-2024-46675",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46675"
},
{
"name": "CVE-2024-46676",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46676"
},
{
"name": "CVE-2024-46677",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46677"
},
{
"name": "CVE-2024-46679",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46679"
},
{
"name": "CVE-2024-46685",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46685"
},
{
"name": "CVE-2024-46686",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46686"
},
{
"name": "CVE-2024-46689",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46689"
},
{
"name": "CVE-2024-46694",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46694"
},
{
"name": "CVE-2024-46702",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46702"
},
{
"name": "CVE-2024-46707",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46707"
},
{
"name": "CVE-2024-46711",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46711"
},
{
"name": "CVE-2024-46713",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46713"
},
{
"name": "CVE-2024-46714",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46714"
},
{
"name": "CVE-2024-46715",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46715"
},
{
"name": "CVE-2024-46716",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46716"
},
{
"name": "CVE-2024-46717",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46717"
},
{
"name": "CVE-2024-46719",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46719"
},
{
"name": "CVE-2024-46720",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46720"
},
{
"name": "CVE-2024-46721",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46721"
},
{
"name": "CVE-2024-46722",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46722"
},
{
"name": "CVE-2024-46723",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46723"
},
{
"name": "CVE-2024-46724",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46724"
},
{
"name": "CVE-2024-46725",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46725"
},
{
"name": "CVE-2024-46726",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46726"
},
{
"name": "CVE-2024-46731",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46731"
},
{
"name": "CVE-2024-46732",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46732"
},
{
"name": "CVE-2024-46735",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46735"
},
{
"name": "CVE-2024-46737",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46737"
},
{
"name": "CVE-2024-46738",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46738"
},
{
"name": "CVE-2024-46739",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46739"
},
{
"name": "CVE-2024-46740",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46740"
},
{
"name": "CVE-2024-46743",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46743"
},
{
"name": "CVE-2024-46744",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46744"
},
{
"name": "CVE-2024-46745",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46745"
},
{
"name": "CVE-2024-46746",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46746"
},
{
"name": "CVE-2024-46747",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46747"
},
{
"name": "CVE-2024-46750",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46750"
},
{
"name": "CVE-2024-46752",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46752"
},
{
"name": "CVE-2024-46755",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46755"
},
{
"name": "CVE-2024-46756",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46756"
},
{
"name": "CVE-2024-46757",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46757"
},
{
"name": "CVE-2024-46758",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46758"
},
{
"name": "CVE-2024-46759",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46759"
},
{
"name": "CVE-2024-46761",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46761"
},
{
"name": "CVE-2024-46763",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46763"
},
{
"name": "CVE-2024-46770",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46770"
},
{
"name": "CVE-2024-46771",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46771"
},
{
"name": "CVE-2024-46773",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46773"
},
{
"name": "CVE-2024-46777",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46777"
},
{
"name": "CVE-2024-46780",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46780"
},
{
"name": "CVE-2024-46781",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46781"
},
{
"name": "CVE-2024-46782",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46782"
},
{
"name": "CVE-2024-46783",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46783"
},
{
"name": "CVE-2024-46784",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46784"
},
{
"name": "CVE-2024-46791",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46791"
},
{
"name": "CVE-2024-46794",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46794"
},
{
"name": "CVE-2024-46795",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46795"
},
{
"name": "CVE-2024-46798",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46798"
},
{
"name": "CVE-2024-46800",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46800"
},
{
"name": "CVE-2024-46802",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46802"
},
{
"name": "CVE-2024-46804",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46804"
},
{
"name": "CVE-2024-46805",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46805"
},
{
"name": "CVE-2024-46807",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46807"
},
{
"name": "CVE-2024-46810",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46810"
},
{
"name": "CVE-2024-46812",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46812"
},
{
"name": "CVE-2024-46814",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46814"
},
{
"name": "CVE-2024-46815",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46815"
},
{
"name": "CVE-2024-46817",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46817"
},
{
"name": "CVE-2024-46818",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46818"
},
{
"name": "CVE-2024-46819",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46819"
},
{
"name": "CVE-2024-46821",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46821"
},
{
"name": "CVE-2024-46822",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46822"
},
{
"name": "CVE-2024-46826",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46826"
},
{
"name": "CVE-2024-46828",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46828"
},
{
"name": "CVE-2024-46829",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46829"
},
{
"name": "CVE-2024-46830",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46830"
},
{
"name": "CVE-2024-46832",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46832"
},
{
"name": "CVE-2024-46835",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46835"
},
{
"name": "CVE-2024-46836",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46836"
},
{
"name": "CVE-2024-46840",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46840"
},
{
"name": "CVE-2024-46844",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46844"
},
{
"name": "CVE-2024-46846",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46846"
},
{
"name": "CVE-2024-46848",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46848"
},
{
"name": "CVE-2024-46849",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46849"
},
{
"name": "CVE-2024-46852",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46852"
},
{
"name": "CVE-2024-46853",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46853"
},
{
"name": "CVE-2024-46854",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46854"
},
{
"name": "CVE-2024-46855",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46855"
},
{
"name": "CVE-2024-46857",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46857"
},
{
"name": "CVE-2024-46858",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46858"
},
{
"name": "CVE-2024-46859",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46859"
},
{
"name": "CVE-2024-42272",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42272"
},
{
"name": "CVE-2024-42297",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42297"
},
{
"name": "CVE-2024-41082",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41082"
},
{
"name": "CVE-2024-42252",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42252"
},
{
"name": "CVE-2024-42265",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42265"
},
{
"name": "CVE-2024-42294",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42294"
},
{
"name": "CVE-2024-42304",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42304"
},
{
"name": "CVE-2024-42305",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42305"
},
{
"name": "CVE-2024-42306",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42306"
},
{
"name": "CVE-2024-43828",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43828"
},
{
"name": "CVE-2024-43832",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43832"
},
{
"name": "CVE-2024-43845",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43845"
},
{
"name": "CVE-2024-43870",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43870"
},
{
"name": "CVE-2024-43886",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43886"
},
{
"name": "CVE-2024-43890",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43890"
},
{
"name": "CVE-2024-43914",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43914"
},
{
"name": "CVE-2024-44935",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44935"
},
{
"name": "CVE-2024-44944",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44944"
},
{
"name": "CVE-2024-44948",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44948"
},
{
"name": "CVE-2024-44950",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44950"
},
{
"name": "CVE-2024-44954",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44954"
},
{
"name": "CVE-2024-44960",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44960"
},
{
"name": "CVE-2024-44961",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44961"
},
{
"name": "CVE-2024-44962",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44962"
},
{
"name": "CVE-2024-44965",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44965"
},
{
"name": "CVE-2024-44967",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44967"
},
{
"name": "CVE-2024-44969",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44969"
},
{
"name": "CVE-2024-44970",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44970"
},
{
"name": "CVE-2024-44971",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44971"
},
{
"name": "CVE-2024-44972",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44972"
},
{
"name": "CVE-2024-44984",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44984"
},
{
"name": "CVE-2024-45001",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45001"
},
{
"name": "CVE-2024-45005",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45005"
},
{
"name": "CVE-2024-45012",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45012"
},
{
"name": "CVE-2024-45013",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45013"
},
{
"name": "CVE-2024-45015",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45015"
},
{
"name": "CVE-2024-45017",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45017"
},
{
"name": "CVE-2024-45020",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45020"
},
{
"name": "CVE-2024-45030",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45030"
},
{
"name": "CVE-2024-46672",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46672"
},
{
"name": "CVE-2024-46678",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46678"
},
{
"name": "CVE-2024-46687",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46687"
},
{
"name": "CVE-2024-46691",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46691"
},
{
"name": "CVE-2024-46692",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46692"
},
{
"name": "CVE-2024-46693",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46693"
},
{
"name": "CVE-2024-46695",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46695"
},
{
"name": "CVE-2024-46706",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46706"
},
{
"name": "CVE-2024-46709",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46709"
},
{
"name": "CVE-2024-46710",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46710"
},
{
"name": "CVE-2024-46727",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46727"
},
{
"name": "CVE-2024-46728",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46728"
},
{
"name": "CVE-2024-46729",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46729"
},
{
"name": "CVE-2024-46730",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46730"
},
{
"name": "CVE-2024-46741",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46741"
},
{
"name": "CVE-2024-46749",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46749"
},
{
"name": "CVE-2024-46751",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46751"
},
{
"name": "CVE-2024-46753",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46753"
},
{
"name": "CVE-2024-46760",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46760"
},
{
"name": "CVE-2024-46767",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46767"
},
{
"name": "CVE-2024-46772",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46772"
},
{
"name": "CVE-2024-46774",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46774"
},
{
"name": "CVE-2024-46775",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46775"
},
{
"name": "CVE-2024-46776",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46776"
},
{
"name": "CVE-2024-46778",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46778"
},
{
"name": "CVE-2024-46786",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46786"
},
{
"name": "CVE-2024-46787",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46787"
},
{
"name": "CVE-2024-46797",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46797"
},
{
"name": "CVE-2024-47668",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47668"
},
{
"name": "CVE-2023-52888",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52888"
},
{
"name": "CVE-2023-52918",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52918"
},
{
"name": "CVE-2024-41018",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41018"
},
{
"name": "CVE-2024-41019",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41019"
},
{
"name": "CVE-2024-41021",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41021"
},
{
"name": "CVE-2024-41029",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41029"
},
{
"name": "CVE-2024-41030",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41030"
},
{
"name": "CVE-2024-41033",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41033"
},
{
"name": "CVE-2024-41052",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41052"
},
{
"name": "CVE-2024-41053",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41053"
},
{
"name": "CVE-2024-41054",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41054"
},
{
"name": "CVE-2024-41067",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41067"
},
{
"name": "CVE-2024-41083",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41083"
},
{
"name": "CVE-2024-41085",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41085"
},
{
"name": "CVE-2024-41086",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41086"
},
{
"name": "CVE-2024-42063",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42063"
},
{
"name": "CVE-2024-42065",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42065"
},
{
"name": "CVE-2024-42066",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42066"
},
{
"name": "CVE-2024-42067",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42067"
},
{
"name": "CVE-2024-42088",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42088"
},
{
"name": "CVE-2024-42091",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42091"
},
{
"name": "CVE-2024-42100",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42100"
},
{
"name": "CVE-2024-42103",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42103"
},
{
"name": "CVE-2024-42108",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42108"
},
{
"name": "CVE-2024-42111",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42111"
},
{
"name": "CVE-2024-42112",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42112"
},
{
"name": "CVE-2024-42118",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42118"
},
{
"name": "CVE-2024-42128",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42128"
},
{
"name": "CVE-2024-42129",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42129"
},
{
"name": "CVE-2024-42135",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42135"
},
{
"name": "CVE-2024-42146",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42146"
},
{
"name": "CVE-2024-42149",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42149"
},
{
"name": "CVE-2024-42150",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42150"
},
{
"name": "CVE-2024-42151",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42151"
},
{
"name": "CVE-2024-42231",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42231"
},
{
"name": "CVE-2024-42234",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42234"
},
{
"name": "CVE-2024-42235",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42235"
},
{
"name": "CVE-2024-42248",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42248"
},
{
"name": "CVE-2024-42251",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42251"
},
{
"name": "CVE-2024-47659",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47659"
},
{
"name": "CVE-2024-47663",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47663"
},
{
"name": "CVE-2024-47667",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47667"
},
{
"name": "CVE-2024-47669",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47669"
},
{
"name": "CVE-2024-42258",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42258"
},
{
"name": "CVE-2024-43857",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43857"
},
{
"name": "CVE-2024-46754",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46754"
},
{
"name": "CVE-2024-46766",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46766"
},
{
"name": "CVE-2024-46803",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46803"
},
{
"name": "CVE-2024-46806",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46806"
},
{
"name": "CVE-2024-46809",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46809"
},
{
"name": "CVE-2024-46811",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46811"
},
{
"name": "CVE-2024-46813",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46813"
},
{
"name": "CVE-2024-46816",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46816"
},
{
"name": "CVE-2024-46825",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46825"
},
{
"name": "CVE-2024-46827",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46827"
},
{
"name": "CVE-2024-46831",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46831"
},
{
"name": "CVE-2024-46834",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46834"
},
{
"name": "CVE-2024-46841",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46841"
},
{
"name": "CVE-2024-46842",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46842"
},
{
"name": "CVE-2024-46843",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46843"
},
{
"name": "CVE-2024-46851",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46851"
},
{
"name": "CVE-2024-46860",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46860"
},
{
"name": "CVE-2024-46861",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46861"
},
{
"name": "CVE-2024-46864",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46864"
},
{
"name": "CVE-2024-46870",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46870"
},
{
"name": "CVE-2024-46871",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46871"
},
{
"name": "CVE-2024-47658",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47658"
},
{
"name": "CVE-2024-47661",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47661"
},
{
"name": "CVE-2024-42267",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42267"
},
{
"name": "CVE-2024-42296",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42296"
},
{
"name": "CVE-2024-42299",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42299"
},
{
"name": "CVE-2024-43869",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43869"
},
{
"name": "CVE-2024-44934",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44934"
},
{
"name": "CVE-2024-44958",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44958"
},
{
"name": "CVE-2024-44966",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44966"
},
{
"name": "CVE-2024-47660",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47660"
},
{
"name": "CVE-2024-47665",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47665"
},
{
"name": "CVE-2024-47662",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47662"
},
{
"name": "CVE-2024-47664",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47664"
},
{
"name": "CVE-2024-47674",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47674"
},
{
"name": "CVE-2024-46824",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46824"
},
{
"name": "CVE-2024-44942",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44942"
},
{
"name": "CVE-2024-43868",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43868"
},
{
"name": "CVE-2024-42260",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42260"
},
{
"name": "CVE-2024-42261",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42261"
},
{
"name": "CVE-2024-42262",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42262"
},
{
"name": "CVE-2024-42263",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42263"
},
{
"name": "CVE-2024-42264",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42264"
},
{
"name": "CVE-2024-42273",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42273"
},
{
"name": "CVE-2024-42307",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42307"
},
{
"name": "CVE-2024-42317",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42317"
},
{
"name": "CVE-2024-42321",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42321"
},
{
"name": "CVE-2024-43820",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43820"
},
{
"name": "CVE-2024-43827",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43827"
},
{
"name": "CVE-2024-43843",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43843"
},
{
"name": "CVE-2024-43852",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43852"
},
{
"name": "CVE-2024-43887",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43887"
},
{
"name": "CVE-2024-43888",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43888"
},
{
"name": "CVE-2024-43891",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43891"
},
{
"name": "CVE-2024-43910",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43910"
},
{
"name": "CVE-2024-43913",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43913"
},
{
"name": "CVE-2024-44937",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44937"
},
{
"name": "CVE-2024-44941",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44941"
},
{
"name": "CVE-2024-44943",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44943"
},
{
"name": "CVE-2024-44953",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44953"
},
{
"name": "CVE-2024-44956",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44956"
},
{
"name": "CVE-2024-44957",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44957"
},
{
"name": "CVE-2024-44959",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44959"
},
{
"name": "CVE-2024-44963",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44963"
},
{
"name": "CVE-2024-44973",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44973"
},
{
"name": "CVE-2024-44975",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44975"
},
{
"name": "CVE-2024-44978",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44978"
},
{
"name": "CVE-2024-44979",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44979"
},
{
"name": "CVE-2024-44980",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44980"
},
{
"name": "CVE-2024-44993",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44993"
},
{
"name": "CVE-2024-44996",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44996"
},
{
"name": "CVE-2024-45027",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45027"
},
{
"name": "CVE-2024-46680",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46680"
},
{
"name": "CVE-2024-46681",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46681"
},
{
"name": "CVE-2024-46683",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46683"
},
{
"name": "CVE-2024-46697",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46697"
},
{
"name": "CVE-2024-46698",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46698"
},
{
"name": "CVE-2024-46701",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46701"
},
{
"name": "CVE-2024-46703",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46703"
},
{
"name": "CVE-2024-46705",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46705"
},
{
"name": "CVE-2024-46708",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46708"
},
{
"name": "CVE-2024-46718",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46718"
},
{
"name": "CVE-2024-46733",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46733"
},
{
"name": "CVE-2024-46762",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46762"
},
{
"name": "CVE-2024-46765",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46765"
},
{
"name": "CVE-2024-46768",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46768"
},
{
"name": "CVE-2024-46779",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46779"
},
{
"name": "CVE-2024-46785",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46785"
},
{
"name": "CVE-2024-46788",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46788"
},
{
"name": "CVE-2024-46792",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46792"
},
{
"name": "CVE-2024-46793",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46793"
},
{
"name": "CVE-2024-46808",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46808"
},
{
"name": "CVE-2024-46823",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46823"
},
{
"name": "CVE-2024-46838",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46838"
},
{
"name": "CVE-2024-46845",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46845"
},
{
"name": "CVE-2024-46847",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46847"
},
{
"name": "CVE-2024-46850",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46850"
},
{
"name": "CVE-2024-46866",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46866"
},
{
"name": "CVE-2024-46867",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46867"
},
{
"name": "CVE-2024-46868",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46868"
},
{
"name": "CVE-2024-47666",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47666"
},
{
"name": "CVE-2024-47683",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47683"
},
{
"name": "CVE-2024-49984",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49984"
}
],
"initial_release_date": "2024-12-13T00:00:00",
"last_revision_date": "2024-12-13T00:00:00",
"links": [],
"reference": "CERTFR-2024-AVI-1080",
"revisions": [
{
"description": "Version initiale",
"revision_date": "2024-12-13T00:00:00.000000"
}
],
"risks": [
{
"description": "Non sp\u00e9cifi\u00e9 par l\u0027\u00e9diteur"
}
],
"summary": "De multiples vuln\u00e9rabilit\u00e9s ont \u00e9t\u00e9 d\u00e9couvertes dans le noyau Linux d\u0027Ubuntu. Elles permettent \u00e0 un attaquant de provoquer un probl\u00e8me de s\u00e9curit\u00e9 non sp\u00e9cifi\u00e9 par l\u0027\u00e9diteur.",
"title": "Multiples vuln\u00e9rabilit\u00e9s dans le noyau Linux d\u0027Ubuntu",
"vendor_advisories": [
{
"published_at": "2024-12-09",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7144-1",
"url": "https://ubuntu.com/security/notices/USN-7144-1"
},
{
"published_at": "2024-12-12",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7159-1",
"url": "https://ubuntu.com/security/notices/USN-7159-1"
},
{
"published_at": "2024-12-12",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7155-1",
"url": "https://ubuntu.com/security/notices/USN-7155-1"
},
{
"published_at": "2024-12-12",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7154-1",
"url": "https://ubuntu.com/security/notices/USN-7154-1"
},
{
"published_at": "2024-12-10",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7148-1",
"url": "https://ubuntu.com/security/notices/USN-7148-1"
},
{
"published_at": "2024-12-12",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7156-1",
"url": "https://ubuntu.com/security/notices/USN-7156-1"
}
]
}
CERTFR-2025-AVI-0002
Vulnerability from certfr_avis - Published: 2025-01-03 - Updated: 2025-01-06
De multiples vulnérabilités ont été découvertes dans le noyau Linux de Debian LTS. Elles permettent à un attaquant de provoquer une élévation de privilèges, une atteinte à la confidentialité des données 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).
| Title | Publication Time | Tags | |||
|---|---|---|---|---|---|
|
|||||
{
"$ref": "https://www.cert.ssi.gouv.fr/openapi.json",
"affected_systems": [
{
"description": "Debian LTS bullseye versions ant\u00e9rieures \u00e0 6.1.119-1~deb11u1",
"product": {
"name": "Debian",
"vendor": {
"name": "Debian",
"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-2022-45888",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-45888"
},
{
"name": "CVE-2023-31083",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-31083"
},
{
"name": "CVE-2024-27072",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27072"
},
{
"name": "CVE-2024-35943",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35943"
},
{
"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-35966",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35966"
},
{
"name": "CVE-2024-35937",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35937"
},
{
"name": "CVE-2024-36894",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36894"
},
{
"name": "CVE-2024-27397",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27397"
},
{
"name": "CVE-2024-26952",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26952"
},
{
"name": "CVE-2024-26954",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26954"
},
{
"name": "CVE-2024-36478",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36478"
},
{
"name": "CVE-2024-36915",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36915"
},
{
"name": "CVE-2024-36923",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36923"
},
{
"name": "CVE-2024-36978",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36978"
},
{
"name": "CVE-2024-37078",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-37078"
},
{
"name": "CVE-2024-38540",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38540"
},
{
"name": "CVE-2024-38553",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38553"
},
{
"name": "CVE-2024-38619",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38619"
},
{
"name": "CVE-2024-39469",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39469"
},
{
"name": "CVE-2024-27017",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27017"
},
{
"name": "CVE-2023-52760",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52760"
},
{
"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-39298",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39298"
},
{
"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-39484",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39484"
},
{
"name": "CVE-2024-39487",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39487"
},
{
"name": "CVE-2024-39494",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39494"
},
{
"name": "CVE-2024-39495",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39495"
},
{
"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-39503",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39503"
},
{
"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-39510",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39510"
},
{
"name": "CVE-2024-40899",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40899"
},
{
"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-40905",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40905"
},
{
"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-40910",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40910"
},
{
"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-40913",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40913"
},
{
"name": "CVE-2024-40914",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40914"
},
{
"name": "CVE-2024-40915",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40915"
},
{
"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-40920",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40920"
},
{
"name": "CVE-2024-40921",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40921"
},
{
"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-40938",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40938"
},
{
"name": "CVE-2024-40939",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40939"
},
{
"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-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-40957",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40957"
},
{
"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-40963",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40963"
},
{
"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-40968",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40968"
},
{
"name": "CVE-2024-40970",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40970"
},
{
"name": "CVE-2024-40971",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40971"
},
{
"name": "CVE-2024-40974",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40974"
},
{
"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-40980",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40980"
},
{
"name": "CVE-2024-40981",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40981"
},
{
"name": "CVE-2024-40983",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40983"
},
{
"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-40993",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40993"
},
{
"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-40996",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40996"
},
{
"name": "CVE-2024-41000",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41000"
},
{
"name": "CVE-2024-41001",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41001"
},
{
"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-41005",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41005"
},
{
"name": "CVE-2024-41006",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41006"
},
{
"name": "CVE-2023-52812",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52812"
},
{
"name": "CVE-2024-36914",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36914"
},
{
"name": "CVE-2024-39472",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39472"
},
{
"name": "CVE-2024-40972",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40972"
},
{
"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-2024-39497",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39497"
},
{
"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-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-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"
},
{
"name": "CVE-2024-41007",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41007"
},
{
"name": "CVE-2024-41020",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41020"
},
{
"name": "CVE-2024-41022",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41022"
},
{
"name": "CVE-2024-41034",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41034"
},
{
"name": "CVE-2024-41035",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41035"
},
{
"name": "CVE-2024-41046",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41046"
},
{
"name": "CVE-2024-41049",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41049"
},
{
"name": "CVE-2024-41055",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41055"
},
{
"name": "CVE-2024-41065",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41065"
},
{
"name": "CVE-2024-41068",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41068"
},
{
"name": "CVE-2024-41077",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41077"
},
{
"name": "CVE-2024-42101",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42101"
},
{
"name": "CVE-2024-42102",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42102"
},
{
"name": "CVE-2024-42104",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42104"
},
{
"name": "CVE-2024-42106",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42106"
},
{
"name": "CVE-2024-42115",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42115"
},
{
"name": "CVE-2024-42121",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42121"
},
{
"name": "CVE-2024-42127",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42127"
},
{
"name": "CVE-2024-42131",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42131"
},
{
"name": "CVE-2024-42137",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42137"
},
{
"name": "CVE-2024-42148",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42148"
},
{
"name": "CVE-2024-42152",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42152"
},
{
"name": "CVE-2024-42153",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42153"
},
{
"name": "CVE-2024-42154",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42154"
},
{
"name": "CVE-2024-42157",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42157"
},
{
"name": "CVE-2024-42229",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42229"
},
{
"name": "CVE-2024-42232",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42232"
},
{
"name": "CVE-2024-42236",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42236"
},
{
"name": "CVE-2024-42244",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42244"
},
{
"name": "CVE-2024-42247",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42247"
},
{
"name": "CVE-2024-42110",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42110"
},
{
"name": "CVE-2024-41073",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41073"
},
{
"name": "CVE-2024-41096",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41096"
},
{
"name": "CVE-2024-42082",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42082"
},
{
"name": "CVE-2023-52887",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52887"
},
{
"name": "CVE-2024-36244",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36244"
},
{
"name": "CVE-2024-38632",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38632"
},
{
"name": "CVE-2024-41027",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41027"
},
{
"name": "CVE-2024-41047",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41047"
},
{
"name": "CVE-2024-41092",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41092"
},
{
"name": "CVE-2024-41093",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41093"
},
{
"name": "CVE-2024-41097",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41097"
},
{
"name": "CVE-2024-42068",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42068"
},
{
"name": "CVE-2024-42076",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42076"
},
{
"name": "CVE-2024-42077",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42077"
},
{
"name": "CVE-2024-42080",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42080"
},
{
"name": "CVE-2024-42084",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42084"
},
{
"name": "CVE-2024-42085",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42085"
},
{
"name": "CVE-2024-42086",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42086"
},
{
"name": "CVE-2024-42087",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42087"
},
{
"name": "CVE-2024-42089",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42089"
},
{
"name": "CVE-2024-42090",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42090"
},
{
"name": "CVE-2024-42092",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42092"
},
{
"name": "CVE-2024-42094",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42094"
},
{
"name": "CVE-2024-42095",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42095"
},
{
"name": "CVE-2024-42097",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42097"
},
{
"name": "CVE-2024-42098",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42098"
},
{
"name": "CVE-2024-42109",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42109"
},
{
"name": "CVE-2024-42130",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42130"
},
{
"name": "CVE-2024-42140",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42140"
},
{
"name": "CVE-2024-42225",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42225"
},
{
"name": "CVE-2024-42240",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42240"
},
{
"name": "CVE-2024-42270",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42270"
},
{
"name": "CVE-2023-52889",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52889"
},
{
"name": "CVE-2024-41028",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41028"
},
{
"name": "CVE-2024-41036",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41036"
},
{
"name": "CVE-2024-41038",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41038"
},
{
"name": "CVE-2024-41039",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41039"
},
{
"name": "CVE-2024-41042",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41042"
},
{
"name": "CVE-2024-41050",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41050"
},
{
"name": "CVE-2024-41051",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41051"
},
{
"name": "CVE-2024-41056",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41056"
},
{
"name": "CVE-2024-41062",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41062"
},
{
"name": "CVE-2024-41074",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41074"
},
{
"name": "CVE-2024-41075",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41075"
},
{
"name": "CVE-2024-41079",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41079"
},
{
"name": "CVE-2024-41080",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41080"
},
{
"name": "CVE-2024-41088",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41088"
},
{
"name": "CVE-2024-41098",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41098"
},
{
"name": "CVE-2024-42073",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42073"
},
{
"name": "CVE-2024-42114",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42114"
},
{
"name": "CVE-2024-42126",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42126"
},
{
"name": "CVE-2024-42136",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42136"
},
{
"name": "CVE-2024-42138",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42138"
},
{
"name": "CVE-2024-42142",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42142"
},
{
"name": "CVE-2024-42147",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42147"
},
{
"name": "CVE-2024-42159",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42159"
},
{
"name": "CVE-2024-42228",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42228"
},
{
"name": "CVE-2024-42237",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42237"
},
{
"name": "CVE-2024-42238",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42238"
},
{
"name": "CVE-2024-42245",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42245"
},
{
"name": "CVE-2024-42246",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42246"
},
{
"name": "CVE-2024-42250",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42250"
},
{
"name": "CVE-2024-42253",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42253"
},
{
"name": "CVE-2024-42259",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42259"
},
{
"name": "CVE-2024-42268",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42268"
},
{
"name": "CVE-2024-42269",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42269"
},
{
"name": "CVE-2024-42271",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42271"
},
{
"name": "CVE-2024-42274",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42274"
},
{
"name": "CVE-2024-42276",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42276"
},
{
"name": "CVE-2024-42277",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42277"
},
{
"name": "CVE-2024-42280",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42280"
},
{
"name": "CVE-2024-42281",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42281"
},
{
"name": "CVE-2024-42283",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42283"
},
{
"name": "CVE-2024-42284",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42284"
},
{
"name": "CVE-2024-42285",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42285"
},
{
"name": "CVE-2024-42286",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42286"
},
{
"name": "CVE-2024-42287",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42287"
},
{
"name": "CVE-2024-42288",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42288"
},
{
"name": "CVE-2024-42289",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42289"
},
{
"name": "CVE-2024-42290",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42290"
},
{
"name": "CVE-2024-42291",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42291"
},
{
"name": "CVE-2024-42292",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42292"
},
{
"name": "CVE-2024-42295",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42295"
},
{
"name": "CVE-2024-42301",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42301"
},
{
"name": "CVE-2024-42302",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42302"
},
{
"name": "CVE-2024-42309",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42309"
},
{
"name": "CVE-2024-42310",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42310"
},
{
"name": "CVE-2024-42311",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42311"
},
{
"name": "CVE-2024-42312",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42312"
},
{
"name": "CVE-2024-42313",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42313"
},
{
"name": "CVE-2024-42314",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42314"
},
{
"name": "CVE-2024-42316",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42316"
},
{
"name": "CVE-2024-42318",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42318"
},
{
"name": "CVE-2024-42320",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42320"
},
{
"name": "CVE-2024-42322",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42322"
},
{
"name": "CVE-2024-43817",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43817"
},
{
"name": "CVE-2024-43818",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43818"
},
{
"name": "CVE-2024-43823",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43823"
},
{
"name": "CVE-2024-43829",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43829"
},
{
"name": "CVE-2024-43830",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43830"
},
{
"name": "CVE-2024-43833",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43833"
},
{
"name": "CVE-2024-43834",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43834"
},
{
"name": "CVE-2024-43837",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43837"
},
{
"name": "CVE-2024-43839",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43839"
},
{
"name": "CVE-2024-43841",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43841"
},
{
"name": "CVE-2024-43842",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43842"
},
{
"name": "CVE-2024-43846",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43846"
},
{
"name": "CVE-2024-43849",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43849"
},
{
"name": "CVE-2024-43851",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43851"
},
{
"name": "CVE-2024-43853",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43853"
},
{
"name": "CVE-2024-43854",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43854"
},
{
"name": "CVE-2024-43855",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43855"
},
{
"name": "CVE-2024-43856",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43856"
},
{
"name": "CVE-2024-43858",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43858"
},
{
"name": "CVE-2024-43860",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43860"
},
{
"name": "CVE-2024-43861",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43861"
},
{
"name": "CVE-2024-43863",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43863"
},
{
"name": "CVE-2024-43866",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43866"
},
{
"name": "CVE-2024-43867",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43867"
},
{
"name": "CVE-2024-43871",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43871"
},
{
"name": "CVE-2024-43873",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43873"
},
{
"name": "CVE-2024-43875",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43875"
},
{
"name": "CVE-2024-43876",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43876"
},
{
"name": "CVE-2024-43877",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43877"
},
{
"name": "CVE-2024-43879",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43879"
},
{
"name": "CVE-2024-43880",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43880"
},
{
"name": "CVE-2024-43882",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43882"
},
{
"name": "CVE-2024-43883",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43883"
},
{
"name": "CVE-2024-43884",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43884"
},
{
"name": "CVE-2024-43889",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43889"
},
{
"name": "CVE-2024-43892",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43892"
},
{
"name": "CVE-2024-43893",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43893"
},
{
"name": "CVE-2024-43894",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43894"
},
{
"name": "CVE-2024-43895",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43895"
},
{
"name": "CVE-2024-43897",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43897"
},
{
"name": "CVE-2024-43900",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43900"
},
{
"name": "CVE-2024-43902",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43902"
},
{
"name": "CVE-2024-43904",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43904"
},
{
"name": "CVE-2024-43905",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43905"
},
{
"name": "CVE-2024-43907",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43907"
},
{
"name": "CVE-2024-43908",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43908"
},
{
"name": "CVE-2024-43909",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43909"
},
{
"name": "CVE-2024-43911",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43911"
},
{
"name": "CVE-2024-43912",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43912"
},
{
"name": "CVE-2024-44931",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44931"
},
{
"name": "CVE-2024-44938",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44938"
},
{
"name": "CVE-2024-44939",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44939"
},
{
"name": "CVE-2024-44947",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44947"
},
{
"name": "CVE-2024-42160",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42160"
},
{
"name": "CVE-2024-45003",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45003"
},
{
"name": "CVE-2024-43835",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43835"
},
{
"name": "CVE-2024-43859",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43859"
},
{
"name": "CVE-2024-44940",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44940"
},
{
"name": "CVE-2024-44946",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44946"
},
{
"name": "CVE-2024-44974",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44974"
},
{
"name": "CVE-2024-44977",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44977"
},
{
"name": "CVE-2024-44982",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44982"
},
{
"name": "CVE-2024-44983",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44983"
},
{
"name": "CVE-2024-44985",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44985"
},
{
"name": "CVE-2024-44986",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44986"
},
{
"name": "CVE-2024-44987",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44987"
},
{
"name": "CVE-2024-44988",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44988"
},
{
"name": "CVE-2024-44989",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44989"
},
{
"name": "CVE-2024-44990",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44990"
},
{
"name": "CVE-2024-44991",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44991"
},
{
"name": "CVE-2024-44995",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44995"
},
{
"name": "CVE-2024-44998",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44998"
},
{
"name": "CVE-2024-44999",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44999"
},
{
"name": "CVE-2024-45000",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45000"
},
{
"name": "CVE-2024-45002",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45002"
},
{
"name": "CVE-2024-45006",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45006"
},
{
"name": "CVE-2024-45007",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45007"
},
{
"name": "CVE-2024-45008",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45008"
},
{
"name": "CVE-2024-45009",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45009"
},
{
"name": "CVE-2024-45010",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45010"
},
{
"name": "CVE-2024-45011",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45011"
},
{
"name": "CVE-2024-45016",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45016"
},
{
"name": "CVE-2024-45018",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45018"
},
{
"name": "CVE-2024-45019",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45019"
},
{
"name": "CVE-2024-45021",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45021"
},
{
"name": "CVE-2024-45022",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45022"
},
{
"name": "CVE-2024-45025",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45025"
},
{
"name": "CVE-2024-45026",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45026"
},
{
"name": "CVE-2024-45028",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45028"
},
{
"name": "CVE-2024-45029",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45029"
},
{
"name": "CVE-2024-46673",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46673"
},
{
"name": "CVE-2024-46674",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46674"
},
{
"name": "CVE-2024-46675",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46675"
},
{
"name": "CVE-2024-46676",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46676"
},
{
"name": "CVE-2024-46677",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46677"
},
{
"name": "CVE-2024-46679",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46679"
},
{
"name": "CVE-2024-46685",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46685"
},
{
"name": "CVE-2024-46686",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46686"
},
{
"name": "CVE-2024-46689",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46689"
},
{
"name": "CVE-2024-46694",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46694"
},
{
"name": "CVE-2024-46702",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46702"
},
{
"name": "CVE-2024-46707",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46707"
},
{
"name": "CVE-2024-46711",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46711"
},
{
"name": "CVE-2024-46713",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46713"
},
{
"name": "CVE-2024-46714",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46714"
},
{
"name": "CVE-2024-46715",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46715"
},
{
"name": "CVE-2024-46716",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46716"
},
{
"name": "CVE-2024-46717",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46717"
},
{
"name": "CVE-2024-46719",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46719"
},
{
"name": "CVE-2024-46720",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46720"
},
{
"name": "CVE-2024-46721",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46721"
},
{
"name": "CVE-2024-46722",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46722"
},
{
"name": "CVE-2024-46723",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46723"
},
{
"name": "CVE-2024-46724",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46724"
},
{
"name": "CVE-2024-46725",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46725"
},
{
"name": "CVE-2024-46726",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46726"
},
{
"name": "CVE-2024-46731",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46731"
},
{
"name": "CVE-2024-46732",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46732"
},
{
"name": "CVE-2024-46734",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46734"
},
{
"name": "CVE-2024-46735",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46735"
},
{
"name": "CVE-2024-46737",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46737"
},
{
"name": "CVE-2024-46738",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46738"
},
{
"name": "CVE-2024-46739",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46739"
},
{
"name": "CVE-2024-46740",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46740"
},
{
"name": "CVE-2024-46743",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46743"
},
{
"name": "CVE-2024-46744",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46744"
},
{
"name": "CVE-2024-46745",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46745"
},
{
"name": "CVE-2024-46746",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46746"
},
{
"name": "CVE-2024-46747",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46747"
},
{
"name": "CVE-2024-46750",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46750"
},
{
"name": "CVE-2024-46752",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46752"
},
{
"name": "CVE-2024-46755",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46755"
},
{
"name": "CVE-2024-46756",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46756"
},
{
"name": "CVE-2024-46757",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46757"
},
{
"name": "CVE-2024-46758",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46758"
},
{
"name": "CVE-2024-46759",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46759"
},
{
"name": "CVE-2024-46761",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46761"
},
{
"name": "CVE-2024-46763",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46763"
},
{
"name": "CVE-2024-46770",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46770"
},
{
"name": "CVE-2024-46771",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46771"
},
{
"name": "CVE-2024-46773",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46773"
},
{
"name": "CVE-2024-46777",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46777"
},
{
"name": "CVE-2024-46780",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46780"
},
{
"name": "CVE-2024-46781",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46781"
},
{
"name": "CVE-2024-46782",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46782"
},
{
"name": "CVE-2024-46783",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46783"
},
{
"name": "CVE-2024-46784",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46784"
},
{
"name": "CVE-2024-46791",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46791"
},
{
"name": "CVE-2024-46794",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46794"
},
{
"name": "CVE-2024-46795",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46795"
},
{
"name": "CVE-2024-46798",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46798"
},
{
"name": "CVE-2024-46800",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46800"
},
{
"name": "CVE-2024-46802",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46802"
},
{
"name": "CVE-2024-46804",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46804"
},
{
"name": "CVE-2024-46805",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46805"
},
{
"name": "CVE-2024-46807",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46807"
},
{
"name": "CVE-2024-46810",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46810"
},
{
"name": "CVE-2024-46812",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46812"
},
{
"name": "CVE-2024-46814",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46814"
},
{
"name": "CVE-2024-46815",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46815"
},
{
"name": "CVE-2024-46817",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46817"
},
{
"name": "CVE-2024-46818",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46818"
},
{
"name": "CVE-2024-46819",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46819"
},
{
"name": "CVE-2024-46821",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46821"
},
{
"name": "CVE-2024-46822",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46822"
},
{
"name": "CVE-2024-46826",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46826"
},
{
"name": "CVE-2024-46828",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46828"
},
{
"name": "CVE-2024-46829",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46829"
},
{
"name": "CVE-2024-46830",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46830"
},
{
"name": "CVE-2024-46832",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46832"
},
{
"name": "CVE-2024-46835",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46835"
},
{
"name": "CVE-2024-46836",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46836"
},
{
"name": "CVE-2024-46840",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46840"
},
{
"name": "CVE-2024-46844",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46844"
},
{
"name": "CVE-2024-46846",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46846"
},
{
"name": "CVE-2024-46848",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46848"
},
{
"name": "CVE-2024-46849",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46849"
},
{
"name": "CVE-2024-46852",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46852"
},
{
"name": "CVE-2024-46853",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46853"
},
{
"name": "CVE-2024-46854",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46854"
},
{
"name": "CVE-2024-46855",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46855"
},
{
"name": "CVE-2024-46857",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46857"
},
{
"name": "CVE-2024-46858",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46858"
},
{
"name": "CVE-2024-46859",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46859"
},
{
"name": "CVE-2024-46865",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46865"
},
{
"name": "CVE-2024-42272",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42272"
},
{
"name": "CVE-2024-42297",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42297"
},
{
"name": "CVE-2024-44968",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44968"
},
{
"name": "CVE-2024-42265",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42265"
},
{
"name": "CVE-2024-42304",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42304"
},
{
"name": "CVE-2024-42305",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42305"
},
{
"name": "CVE-2024-42306",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42306"
},
{
"name": "CVE-2024-43828",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43828"
},
{
"name": "CVE-2024-43832",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43832"
},
{
"name": "CVE-2024-43870",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43870"
},
{
"name": "CVE-2024-43890",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43890"
},
{
"name": "CVE-2024-43914",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43914"
},
{
"name": "CVE-2024-44935",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44935"
},
{
"name": "CVE-2024-44944",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44944"
},
{
"name": "CVE-2024-44948",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44948"
},
{
"name": "CVE-2024-44954",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44954"
},
{
"name": "CVE-2024-44960",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44960"
},
{
"name": "CVE-2024-44965",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44965"
},
{
"name": "CVE-2024-44967",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44967"
},
{
"name": "CVE-2024-44969",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44969"
},
{
"name": "CVE-2024-44970",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44970"
},
{
"name": "CVE-2024-44971",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44971"
},
{
"name": "CVE-2024-46695",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46695"
},
{
"name": "CVE-2024-46710",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46710"
},
{
"name": "CVE-2024-47668",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47668"
},
{
"name": "CVE-2023-52918",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52918"
},
{
"name": "CVE-2024-41019",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41019"
},
{
"name": "CVE-2024-41030",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41030"
},
{
"name": "CVE-2024-42063",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42063"
},
{
"name": "CVE-2024-42103",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42103"
},
{
"name": "CVE-2024-47659",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47659"
},
{
"name": "CVE-2024-47663",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47663"
},
{
"name": "CVE-2024-47667",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47667"
},
{
"name": "CVE-2024-47669",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47669"
},
{
"name": "CVE-2024-42258",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42258"
},
{
"name": "CVE-2023-52917",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52917"
},
{
"name": "CVE-2024-46871",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46871"
},
{
"name": "CVE-2024-42267",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42267"
},
{
"name": "CVE-2024-42296",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42296"
},
{
"name": "CVE-2024-42299",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42299"
},
{
"name": "CVE-2024-43869",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43869"
},
{
"name": "CVE-2024-44934",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44934"
},
{
"name": "CVE-2024-44958",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44958"
},
{
"name": "CVE-2024-44966",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44966"
},
{
"name": "CVE-2024-47660",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47660"
},
{
"name": "CVE-2024-47665",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47665"
},
{
"name": "CVE-2024-47670",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47670"
},
{
"name": "CVE-2024-47671",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47671"
},
{
"name": "CVE-2024-47672",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47672"
},
{
"name": "CVE-2024-47673",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47673"
},
{
"name": "CVE-2024-47674",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47674"
},
{
"name": "CVE-2024-47682",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47682"
},
{
"name": "CVE-2024-47684",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47684"
},
{
"name": "CVE-2024-47685",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47685"
},
{
"name": "CVE-2024-47686",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47686"
},
{
"name": "CVE-2024-47692",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47692"
},
{
"name": "CVE-2024-47693",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47693"
},
{
"name": "CVE-2024-47695",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47695"
},
{
"name": "CVE-2024-47696",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47696"
},
{
"name": "CVE-2024-47697",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47697"
},
{
"name": "CVE-2024-47698",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47698"
},
{
"name": "CVE-2024-47699",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47699"
},
{
"name": "CVE-2024-47705",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47705"
},
{
"name": "CVE-2024-47706",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47706"
},
{
"name": "CVE-2024-47707",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47707"
},
{
"name": "CVE-2024-47709",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47709"
},
{
"name": "CVE-2024-47710",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47710"
},
{
"name": "CVE-2024-47712",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47712"
},
{
"name": "CVE-2024-47713",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47713"
},
{
"name": "CVE-2024-47718",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47718"
},
{
"name": "CVE-2024-47720",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47720"
},
{
"name": "CVE-2024-47723",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47723"
},
{
"name": "CVE-2024-47727",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47727"
},
{
"name": "CVE-2024-47728",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47728"
},
{
"name": "CVE-2024-47730",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47730"
},
{
"name": "CVE-2024-47731",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47731"
},
{
"name": "CVE-2024-47735",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47735"
},
{
"name": "CVE-2024-47737",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47737"
},
{
"name": "CVE-2024-47738",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47738"
},
{
"name": "CVE-2024-47739",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47739"
},
{
"name": "CVE-2024-47742",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47742"
},
{
"name": "CVE-2024-47743",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47743"
},
{
"name": "CVE-2024-47747",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47747"
},
{
"name": "CVE-2024-47748",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47748"
},
{
"name": "CVE-2024-47749",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47749"
},
{
"name": "CVE-2024-47750",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47750"
},
{
"name": "CVE-2024-47751",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47751"
},
{
"name": "CVE-2024-47756",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47756"
},
{
"name": "CVE-2024-47757",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47757"
},
{
"name": "CVE-2024-49850",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49850"
},
{
"name": "CVE-2024-49851",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49851"
},
{
"name": "CVE-2024-49852",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49852"
},
{
"name": "CVE-2024-49853",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49853"
},
{
"name": "CVE-2024-49855",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49855"
},
{
"name": "CVE-2024-49858",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49858"
},
{
"name": "CVE-2024-49860",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49860"
},
{
"name": "CVE-2024-49863",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49863"
},
{
"name": "CVE-2024-49866",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49866"
},
{
"name": "CVE-2024-49867",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49867"
},
{
"name": "CVE-2024-49870",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49870"
},
{
"name": "CVE-2024-49871",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49871"
},
{
"name": "CVE-2024-49875",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49875"
},
{
"name": "CVE-2024-49877",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49877"
},
{
"name": "CVE-2024-49878",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49878"
},
{
"name": "CVE-2024-49879",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49879"
},
{
"name": "CVE-2024-49881",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49881"
},
{
"name": "CVE-2024-49882",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49882"
},
{
"name": "CVE-2024-49883",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49883"
},
{
"name": "CVE-2024-49886",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49886"
},
{
"name": "CVE-2024-49890",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49890"
},
{
"name": "CVE-2024-49892",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49892"
},
{
"name": "CVE-2024-49894",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49894"
},
{
"name": "CVE-2024-49895",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49895"
},
{
"name": "CVE-2024-49896",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49896"
},
{
"name": "CVE-2024-49900",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49900"
},
{
"name": "CVE-2024-49902",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49902"
},
{
"name": "CVE-2024-49903",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49903"
},
{
"name": "CVE-2024-49907",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49907"
},
{
"name": "CVE-2024-49912",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49912"
},
{
"name": "CVE-2024-49913",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49913"
},
{
"name": "CVE-2024-49930",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49930"
},
{
"name": "CVE-2024-49933",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49933"
},
{
"name": "CVE-2024-49935",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49935"
},
{
"name": "CVE-2024-49936",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49936"
},
{
"name": "CVE-2024-49937",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49937"
},
{
"name": "CVE-2024-49938",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49938"
},
{
"name": "CVE-2024-49946",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49946"
},
{
"name": "CVE-2024-49949",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49949"
},
{
"name": "CVE-2024-49950",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49950"
},
{
"name": "CVE-2024-49954",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49954"
},
{
"name": "CVE-2024-49955",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49955"
},
{
"name": "CVE-2024-49957",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49957"
},
{
"name": "CVE-2024-49958",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49958"
},
{
"name": "CVE-2024-49959",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49959"
},
{
"name": "CVE-2024-49960",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49960"
},
{
"name": "CVE-2024-49961",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49961"
},
{
"name": "CVE-2024-49962",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49962"
},
{
"name": "CVE-2024-49963",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49963"
},
{
"name": "CVE-2024-49965",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49965"
},
{
"name": "CVE-2024-49966",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49966"
},
{
"name": "CVE-2024-49967",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49967"
},
{
"name": "CVE-2024-49969",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49969"
},
{
"name": "CVE-2024-49973",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49973"
},
{
"name": "CVE-2024-49974",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49974"
},
{
"name": "CVE-2024-49975",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49975"
},
{
"name": "CVE-2024-49981",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49981"
},
{
"name": "CVE-2024-49982",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49982"
},
{
"name": "CVE-2024-49985",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49985"
},
{
"name": "CVE-2024-49986",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49986"
},
{
"name": "CVE-2024-49991",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49991"
},
{
"name": "CVE-2024-49995",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49995"
},
{
"name": "CVE-2024-50000",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50000"
},
{
"name": "CVE-2024-50001",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50001"
},
{
"name": "CVE-2024-50002",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50002"
},
{
"name": "CVE-2024-50006",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50006"
},
{
"name": "CVE-2024-50007",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50007"
},
{
"name": "CVE-2024-50008",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50008"
},
{
"name": "CVE-2024-50013",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50013"
},
{
"name": "CVE-2024-50015",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50015"
},
{
"name": "CVE-2024-50019",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50019"
},
{
"name": "CVE-2024-50022",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50022"
},
{
"name": "CVE-2024-50024",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50024"
},
{
"name": "CVE-2024-50031",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50031"
},
{
"name": "CVE-2024-50033",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50033"
},
{
"name": "CVE-2024-50035",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50035"
},
{
"name": "CVE-2024-50040",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50040"
},
{
"name": "CVE-2024-50041",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50041"
},
{
"name": "CVE-2024-50044",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50044"
},
{
"name": "CVE-2024-50045",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50045"
},
{
"name": "CVE-2024-50046",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50046"
},
{
"name": "CVE-2024-50048",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50048"
},
{
"name": "CVE-2024-50049",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50049"
},
{
"name": "CVE-2024-50058",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50058"
},
{
"name": "CVE-2024-50059",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50059"
},
{
"name": "CVE-2024-50060",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50060"
},
{
"name": "CVE-2024-50062",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50062"
},
{
"name": "CVE-2024-50069",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50069"
},
{
"name": "CVE-2024-50073",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50073"
},
{
"name": "CVE-2024-50074",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50074"
},
{
"name": "CVE-2024-50077",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50077"
},
{
"name": "CVE-2024-50078",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50078"
},
{
"name": "CVE-2024-43868",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43868"
},
{
"name": "CVE-2024-44949",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44949"
},
{
"name": "CVE-2024-50012",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50012"
},
{
"name": "CVE-2024-50036",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50036"
},
{
"name": "CVE-2024-50067",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50067"
},
{
"name": "CVE-2024-50072",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50072"
},
{
"name": "CVE-2024-50126",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50126"
},
{
"name": "CVE-2024-50215",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50215"
},
{
"name": "CVE-2024-50218",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50218"
},
{
"name": "CVE-2024-50229",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50229"
},
{
"name": "CVE-2024-50230",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50230"
},
{
"name": "CVE-2024-50232",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50232"
},
{
"name": "CVE-2024-50233",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50233"
},
{
"name": "CVE-2024-50234",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50234"
},
{
"name": "CVE-2024-50235",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50235"
},
{
"name": "CVE-2024-50236",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50236"
},
{
"name": "CVE-2024-50237",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50237"
},
{
"name": "CVE-2024-50242",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50242"
},
{
"name": "CVE-2024-50243",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50243"
},
{
"name": "CVE-2024-50244",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50244"
},
{
"name": "CVE-2024-50245",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50245"
},
{
"name": "CVE-2024-50247",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50247"
},
{
"name": "CVE-2024-50249",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50249"
},
{
"name": "CVE-2024-50250",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50250"
},
{
"name": "CVE-2024-50251",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50251"
},
{
"name": "CVE-2024-50252",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50252"
},
{
"name": "CVE-2024-50255",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50255"
},
{
"name": "CVE-2024-50256",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50256"
},
{
"name": "CVE-2024-50257",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50257"
},
{
"name": "CVE-2024-50259",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50259"
},
{
"name": "CVE-2024-50261",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50261"
},
{
"name": "CVE-2024-50262",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50262"
},
{
"name": "CVE-2024-50264",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50264"
},
{
"name": "CVE-2024-50265",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50265"
},
{
"name": "CVE-2024-50267",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50267"
},
{
"name": "CVE-2024-50268",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50268"
},
{
"name": "CVE-2024-50269",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50269"
},
{
"name": "CVE-2024-50271",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50271"
},
{
"name": "CVE-2024-50272",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50272"
},
{
"name": "CVE-2024-50273",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50273"
},
{
"name": "CVE-2024-50276",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50276"
},
{
"name": "CVE-2024-50278",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50278"
},
{
"name": "CVE-2024-50279",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50279"
},
{
"name": "CVE-2024-50280",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50280"
},
{
"name": "CVE-2024-50282",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50282"
},
{
"name": "CVE-2024-50283",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50283"
},
{
"name": "CVE-2024-50284",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50284"
},
{
"name": "CVE-2024-50286",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50286"
},
{
"name": "CVE-2024-50287",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50287"
},
{
"name": "CVE-2024-50290",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50290"
},
{
"name": "CVE-2024-50292",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50292"
},
{
"name": "CVE-2024-50295",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50295"
},
{
"name": "CVE-2024-50296",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50296"
},
{
"name": "CVE-2024-50299",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50299"
},
{
"name": "CVE-2024-50301",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50301"
},
{
"name": "CVE-2024-50302",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50302"
},
{
"name": "CVE-2024-53042",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53042"
},
{
"name": "CVE-2024-53043",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53043"
},
{
"name": "CVE-2024-53052",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53052"
},
{
"name": "CVE-2024-53055",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53055"
},
{
"name": "CVE-2024-53057",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53057"
},
{
"name": "CVE-2024-53058",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53058"
},
{
"name": "CVE-2024-53059",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53059"
},
{
"name": "CVE-2024-53060",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53060"
},
{
"name": "CVE-2024-53061",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53061"
},
{
"name": "CVE-2024-53063",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53063"
},
{
"name": "CVE-2024-53066",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53066"
},
{
"name": "CVE-2024-53070",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53070"
},
{
"name": "CVE-2024-53072",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53072"
},
{
"name": "CVE-2024-53081",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53081"
},
{
"name": "CVE-2024-53082",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53082"
},
{
"name": "CVE-2024-53088",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53088"
},
{
"name": "CVE-2024-53093",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53093"
},
{
"name": "CVE-2024-50208",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50208"
},
{
"name": "CVE-2024-50082",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50082"
},
{
"name": "CVE-2024-50099",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50099"
},
{
"name": "CVE-2024-50110",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50110"
},
{
"name": "CVE-2024-50142",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50142"
},
{
"name": "CVE-2024-50192",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50192"
},
{
"name": "CVE-2024-42273",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42273"
},
{
"name": "CVE-2024-42307",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42307"
},
{
"name": "CVE-2024-42321",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42321"
},
{
"name": "CVE-2024-47683",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47683"
},
{
"name": "CVE-2024-47679",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47679"
},
{
"name": "CVE-2024-47690",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47690"
},
{
"name": "CVE-2024-47701",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47701"
},
{
"name": "CVE-2024-47734",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47734"
},
{
"name": "CVE-2024-47740",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47740"
},
{
"name": "CVE-2024-49856",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49856"
},
{
"name": "CVE-2024-49868",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49868"
},
{
"name": "CVE-2024-49884",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49884"
},
{
"name": "CVE-2024-49889",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49889"
},
{
"name": "CVE-2024-49905",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49905"
},
{
"name": "CVE-2024-49924",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49924"
},
{
"name": "CVE-2024-49927",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49927"
},
{
"name": "CVE-2024-49944",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49944"
},
{
"name": "CVE-2024-49948",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49948"
},
{
"name": "CVE-2024-49952",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49952"
},
{
"name": "CVE-2024-49977",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49977"
},
{
"name": "CVE-2024-49983",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49983"
},
{
"name": "CVE-2024-49997",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49997"
},
{
"name": "CVE-2024-50003",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50003"
},
{
"name": "CVE-2024-50038",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50038"
},
{
"name": "CVE-2024-50039",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50039"
},
{
"name": "CVE-2024-50093",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50093"
},
{
"name": "CVE-2024-50095",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50095"
},
{
"name": "CVE-2024-50096",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50096"
},
{
"name": "CVE-2024-50179",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50179"
},
{
"name": "CVE-2024-50180",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50180"
},
{
"name": "CVE-2024-50181",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50181"
},
{
"name": "CVE-2024-50184",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50184"
},
{
"name": "CVE-2024-50186",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50186"
},
{
"name": "CVE-2024-50188",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50188"
},
{
"name": "CVE-2024-50189",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50189"
},
{
"name": "CVE-2024-50191",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50191"
},
{
"name": "CVE-2024-50026",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50026"
},
{
"name": "CVE-2024-50087",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50087"
},
{
"name": "CVE-2024-50088",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50088"
},
{
"name": "CVE-2024-50098",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50098"
},
{
"name": "CVE-2024-50101",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50101"
},
{
"name": "CVE-2024-50103",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50103"
},
{
"name": "CVE-2024-50108",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50108"
},
{
"name": "CVE-2024-50115",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50115"
},
{
"name": "CVE-2024-50116",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50116"
},
{
"name": "CVE-2024-50117",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50117"
},
{
"name": "CVE-2024-50124",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50124"
},
{
"name": "CVE-2024-50125",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50125"
},
{
"name": "CVE-2024-50127",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50127"
},
{
"name": "CVE-2024-50128",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50128"
},
{
"name": "CVE-2024-50131",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50131"
},
{
"name": "CVE-2024-50134",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50134"
},
{
"name": "CVE-2024-50136",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50136"
},
{
"name": "CVE-2024-50138",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50138"
},
{
"name": "CVE-2024-50141",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50141"
},
{
"name": "CVE-2024-50145",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50145"
},
{
"name": "CVE-2024-50147",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50147"
},
{
"name": "CVE-2024-50148",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50148"
},
{
"name": "CVE-2024-50150",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50150"
},
{
"name": "CVE-2024-50153",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50153"
},
{
"name": "CVE-2024-50154",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50154"
},
{
"name": "CVE-2024-50155",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50155"
},
{
"name": "CVE-2024-50156",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50156"
},
{
"name": "CVE-2024-50160",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50160"
},
{
"name": "CVE-2024-50167",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50167"
},
{
"name": "CVE-2024-50171",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50171"
},
{
"name": "CVE-2024-50176",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50176"
},
{
"name": "CVE-2024-50182",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50182"
},
{
"name": "CVE-2024-50183",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50183"
},
{
"name": "CVE-2024-50187",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50187"
},
{
"name": "CVE-2024-50194",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50194"
},
{
"name": "CVE-2024-50195",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50195"
},
{
"name": "CVE-2024-50196",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50196"
},
{
"name": "CVE-2024-50198",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50198"
},
{
"name": "CVE-2024-50200",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50200"
},
{
"name": "CVE-2024-50201",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50201"
},
{
"name": "CVE-2024-50205",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50205"
},
{
"name": "CVE-2024-50209",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50209"
},
{
"name": "CVE-2024-50210",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50210"
},
{
"name": "CVE-2024-53096",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53096"
},
{
"name": "CVE-2024-53100",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53100"
},
{
"name": "CVE-2024-53101",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53101"
},
{
"name": "CVE-2024-53104",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53104"
},
{
"name": "CVE-2024-53106",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53106"
},
{
"name": "CVE-2024-53110",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53110"
},
{
"name": "CVE-2024-53112",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53112"
},
{
"name": "CVE-2024-53121",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53121"
},
{
"name": "CVE-2024-53138",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53138"
},
{
"name": "CVE-2023-45896",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-45896"
},
{
"name": "CVE-2024-47678",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47678"
},
{
"name": "CVE-2024-49854",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49854"
},
{
"name": "CVE-2024-49859",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49859"
},
{
"name": "CVE-2024-49978",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49978"
},
{
"name": "CVE-2024-49992",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49992"
},
{
"name": "CVE-2024-50010",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50010"
},
{
"name": "CVE-2024-50083",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50083"
},
{
"name": "CVE-2024-50085",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50085"
},
{
"name": "CVE-2024-50086",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50086"
},
{
"name": "CVE-2024-50133",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50133"
},
{
"name": "CVE-2024-50143",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50143"
},
{
"name": "CVE-2024-50151",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50151"
},
{
"name": "CVE-2024-50162",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50162"
},
{
"name": "CVE-2024-50163",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50163"
},
{
"name": "CVE-2024-50168",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50168"
},
{
"name": "CVE-2024-50185",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50185"
},
{
"name": "CVE-2024-50193",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50193"
},
{
"name": "CVE-2024-50199",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50199"
},
{
"name": "CVE-2024-50202",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50202"
},
{
"name": "CVE-2024-53097",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53097"
},
{
"name": "CVE-2024-53103",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53103"
},
{
"name": "CVE-2024-53113",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53113"
},
{
"name": "CVE-2024-53119",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53119"
},
{
"name": "CVE-2024-53120",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53120"
},
{
"name": "CVE-2024-53122",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53122"
},
{
"name": "CVE-2024-53123",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53123"
},
{
"name": "CVE-2024-53127",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53127"
},
{
"name": "CVE-2024-53129",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53129"
},
{
"name": "CVE-2024-53130",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53130"
},
{
"name": "CVE-2024-53131",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53131"
},
{
"name": "CVE-2024-53135",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53135"
},
{
"name": "CVE-2024-53136",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53136"
},
{
"name": "CVE-2024-53140",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53140"
},
{
"name": "CVE-2024-53144",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53144"
},
{
"name": "CVE-2024-8805",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-8805"
}
],
"initial_release_date": "2025-01-03T00:00:00",
"last_revision_date": "2025-01-06T00:00:00",
"links": [],
"reference": "CERTFR-2025-AVI-0002",
"revisions": [
{
"description": "Version initiale",
"revision_date": "2025-01-03T00:00:00.000000"
},
{
"description": "Changement r\u00e9f\u00e9rence ",
"revision_date": "2025-01-06T00:00:00.000000"
}
],
"risks": [
{
"description": "Non sp\u00e9cifi\u00e9 par l\u0027\u00e9diteur"
},
{
"description": "D\u00e9ni de service"
},
{
"description": "Atteinte \u00e0 la confidentialit\u00e9 des donn\u00e9es"
},
{
"description": "\u00c9l\u00e9vation de privil\u00e8ges"
}
],
"summary": "De multiples vuln\u00e9rabilit\u00e9s ont \u00e9t\u00e9 d\u00e9couvertes dans le noyau Linux de Debian LTS. Elles permettent \u00e0 un attaquant de provoquer une \u00e9l\u00e9vation de privil\u00e8ges, une atteinte \u00e0 la confidentialit\u00e9 des donn\u00e9es et un d\u00e9ni de service.",
"title": "Multiples vuln\u00e9rabilit\u00e9s dans le noyau Linux de Debian LTS",
"vendor_advisories": [
{
"published_at": "2025-01-05",
"title": "Bulletin de s\u00e9curit\u00e9 Debian LTS DLA-4008-1",
"url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
}
]
}
FKIE_CVE-2024-42127
Vulnerability from fkie_nvd - Published: 2024-07-30 08:15 - Updated: 2026-06-17 07:48| 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/gpu/drm/lima/lima_gp.c",
"drivers/gpu/drm/lima/lima_mmu.c",
"drivers/gpu/drm/lima/lima_pp.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "0d60c43df59ef01c08dc7b0c45495178f9d05a13",
"status": "affected",
"version": "a1d2a6339961efc078208dc3b2f006e9e9a8e119",
"versionType": "git"
},
{
"lessThan": "25d0d9b83d855cbc5d5aa5ae3cd79d55ea0c84a8",
"status": "affected",
"version": "a1d2a6339961efc078208dc3b2f006e9e9a8e119",
"versionType": "git"
},
{
"lessThan": "17fe8b75aaf0bb1bdc31368963446b421c22d0af",
"status": "affected",
"version": "a1d2a6339961efc078208dc3b2f006e9e9a8e119",
"versionType": "git"
},
{
"lessThan": "0a487e977cb8897ae4c51ecd34bbaa2b005266c9",
"status": "affected",
"version": "a1d2a6339961efc078208dc3b2f006e9e9a8e119",
"versionType": "git"
},
{
"lessThan": "04d531b9a1875846d4f89953b469ad463aa7a770",
"status": "affected",
"version": "a1d2a6339961efc078208dc3b2f006e9e9a8e119",
"versionType": "git"
},
{
"lessThan": "b5daf9217a50636a969bc1965f827878aeb09ffe",
"status": "affected",
"version": "a1d2a6339961efc078208dc3b2f006e9e9a8e119",
"versionType": "git"
},
{
"lessThan": "a6683c690bbfd1f371510cb051e8fa49507f3f5e",
"status": "affected",
"version": "a1d2a6339961efc078208dc3b2f006e9e9a8e119",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/gpu/drm/lima/lima_gp.c",
"drivers/gpu/drm/lima/lima_mmu.c",
"drivers/gpu/drm/lima/lima_pp.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "5.2"
},
{
"lessThan": "5.2",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.280",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.222",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.163",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.98",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.39",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.9.*",
"status": "unaffected",
"version": "6.9.9",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.10",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"configurations": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "41869EAB-4316-41AD-B24B-7C8855E56D62",
"versionEndExcluding": "5.4.280",
"versionStartIncluding": "5.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "00696AC5-EE29-437F-97F9-C4D66608B327",
"versionEndExcluding": "5.10.222",
"versionStartIncluding": "5.5",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "A97DEB09-4927-40F8-B5C6-F5BD5EAE0CFD",
"versionEndExcluding": "5.15.163",
"versionStartIncluding": "5.11",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "E09E92A5-27EF-40E4-926A-B1CDC8270551",
"versionEndExcluding": "6.1.98",
"versionStartIncluding": "5.16",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "29E894E4-668F-4DB0-81F7-4FB5F698E970",
"versionEndExcluding": "6.6.39",
"versionStartIncluding": "6.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "ADCC1407-0CB3-4C8F-B4C5-07F682CD7085",
"versionEndExcluding": "6.9.9",
"versionStartIncluding": "6.7",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/lima: fix shared irq handling on driver remove\n\nlima uses a shared interrupt, so the interrupt handlers must be prepared\nto be called at any time. At driver removal time, the clocks are\ndisabled early and the interrupts stay registered until the very end of\nthe remove process due to the devm usage.\nThis is potentially a bug as the interrupts access device registers\nwhich assumes clocks are enabled. A crash can be triggered by removing\nthe driver in a kernel with CONFIG_DEBUG_SHIRQ enabled.\nThis patch frees the interrupts at each lima device finishing callback\nso that the handlers are already unregistered by the time we fully\ndisable clocks."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/lima: arregla el manejo de irq compartido en el controlador elimina lima usa una interrupci\u00f3n compartida, por lo que los controladores de interrupciones deben estar preparados para ser llamados en cualquier momento. En el momento de la eliminaci\u00f3n del controlador, los relojes se desactivan antes de tiempo y las interrupciones permanecen registradas hasta el final del proceso de eliminaci\u00f3n debido al uso del devm. Esto es potencialmente un error ya que las interrupciones acceden a los registros del dispositivo, lo que supone que los relojes est\u00e1n habilitados. Se puede provocar un bloqueo eliminando el controlador en un kernel con CONFIG_DEBUG_SHIRQ habilitado. Este parche libera las interrupciones en cada dispositivo Lima que finaliza la devoluci\u00f3n de llamada para que los controladores ya est\u00e9n dados de baja cuando deshabilitemos completamente los relojes."
}
],
"id": "CVE-2024-42127",
"lastModified": "2026-06-17T07:48:53.480",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 5.5,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 3.6,
"source": "nvd@nist.gov",
"type": "Primary"
}
],
"ssvcV203": [
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"ssvcData": {
"id": "CVE-2024-42127",
"options": [
{
"exploitation": "none"
},
{
"automatable": "no"
},
{
"technicalImpact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2024-09-10T16:16:38.392074Z",
"version": "2.0.3"
}
}
]
},
"published": "2024-07-30T08:15:04.820",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/04d531b9a1875846d4f89953b469ad463aa7a770"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/0a487e977cb8897ae4c51ecd34bbaa2b005266c9"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/0d60c43df59ef01c08dc7b0c45495178f9d05a13"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/17fe8b75aaf0bb1bdc31368963446b421c22d0af"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/25d0d9b83d855cbc5d5aa5ae3cd79d55ea0c84a8"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/a6683c690bbfd1f371510cb051e8fa49507f3f5e"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/b5daf9217a50636a969bc1965f827878aeb09ffe"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/04d531b9a1875846d4f89953b469ad463aa7a770"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/0a487e977cb8897ae4c51ecd34bbaa2b005266c9"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/0d60c43df59ef01c08dc7b0c45495178f9d05a13"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/17fe8b75aaf0bb1bdc31368963446b421c22d0af"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/25d0d9b83d855cbc5d5aa5ae3cd79d55ea0c84a8"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/a6683c690bbfd1f371510cb051e8fa49507f3f5e"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/b5daf9217a50636a969bc1965f827878aeb09ffe"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Modified",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "NVD-CWE-noinfo"
}
],
"source": "nvd@nist.gov",
"type": "Primary"
}
]
}
GHSA-RP69-CHRC-4849
Vulnerability from github – Published: 2024-07-30 09:32 – Updated: 2025-11-04 00:31In the Linux kernel, the following vulnerability has been resolved:
drm/lima: fix shared irq handling on driver remove
lima uses a shared interrupt, so the interrupt handlers must be prepared to be called at any time. At driver removal time, the clocks are disabled early and the interrupts stay registered until the very end of the remove process due to the devm usage. This is potentially a bug as the interrupts access device registers which assumes clocks are enabled. A crash can be triggered by removing the driver in a kernel with CONFIG_DEBUG_SHIRQ enabled. This patch frees the interrupts at each lima device finishing callback so that the handlers are already unregistered by the time we fully disable clocks.
{
"affected": [],
"aliases": [
"CVE-2024-42127"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-30T08:15:04Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/lima: fix shared irq handling on driver remove\n\nlima uses a shared interrupt, so the interrupt handlers must be prepared\nto be called at any time. At driver removal time, the clocks are\ndisabled early and the interrupts stay registered until the very end of\nthe remove process due to the devm usage.\nThis is potentially a bug as the interrupts access device registers\nwhich assumes clocks are enabled. A crash can be triggered by removing\nthe driver in a kernel with CONFIG_DEBUG_SHIRQ enabled.\nThis patch frees the interrupts at each lima device finishing callback\nso that the handlers are already unregistered by the time we fully\ndisable clocks.",
"id": "GHSA-rp69-chrc-4849",
"modified": "2025-11-04T00:31:06Z",
"published": "2024-07-30T09:32:01Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42127"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/04d531b9a1875846d4f89953b469ad463aa7a770"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0a487e977cb8897ae4c51ecd34bbaa2b005266c9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0d60c43df59ef01c08dc7b0c45495178f9d05a13"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/17fe8b75aaf0bb1bdc31368963446b421c22d0af"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/25d0d9b83d855cbc5d5aa5ae3cd79d55ea0c84a8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a6683c690bbfd1f371510cb051e8fa49507f3f5e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b5daf9217a50636a969bc1965f827878aeb09ffe"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
OESA-2024-2028 (CVE-2024-33621)
Vulnerability from osv_openeuler – Published: 2024-08-23 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:
ipvlan: Dont Use skb->sk in ipvlan_process_v{4,6}_outbound
Raw packet from PF_PACKET socket ontop of an IPv6-backed ipvlan device will hit WARN_ON_ONCE() in sk_mc_loop() through sch_direct_xmit() path.
WARNING: CPU: 2 PID: 0 at net/core/sock.c:775 sk_mc_loop+0x2d/0x70 Modules linked in: sch_netem ipvlan rfkill cirrus drm_shmem_helper sg drm_kms_helper CPU: 2 PID: 0 Comm: swapper/2 Kdump: loaded Not tainted 6.9.0+ #279 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:sk_mc_loop+0x2d/0x70 Code: fa 0f 1f 44 00 00 65 0f b7 15 f7 96 a3 4f 31 c0 66 85 d2 75 26 48 85 ff 74 1c RSP: 0018:ffffa9584015cd78 EFLAGS: 00010212 RAX: 0000000000000011 RBX: ffff91e585793e00 RCX: 0000000002c6a001 RDX: 0000000000000000 RSI: 0000000000000040 RDI: ffff91e589c0f000 RBP: ffff91e5855bd100 R08: 0000000000000000 R09: 3d00545216f43d00 R10: ffff91e584fdcc50 R11: 00000060dd8616f4 R12: ffff91e58132d000 R13: ffff91e584fdcc68 R14: ffff91e5869ce800 R15: ffff91e589c0f000 FS: 0000000000000000(0000) GS:ffff91e898100000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f788f7c44c0 CR3: 0000000008e1a000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <IRQ> ? __warn (kernel/panic.c:693) ? sk_mc_loop (net/core/sock.c:760) ? report_bug (lib/bug.c:201 lib/bug.c:219) ? handle_bug (arch/x86/kernel/traps.c:239) ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminator 1)) ? asm_exc_invalid_op (./arch/x86/include/asm/idtentry.h:621) ? sk_mc_loop (net/core/sock.c:760) ip6_finish_output2 (net/ipv6/ip6_output.c:83 (discriminator 1)) ? nf_hook_slow (net/netfilter/core.c:626) ip6_finish_output (net/ipv6/ip6_output.c:222) ? __pfx_ip6_finish_output (net/ipv6/ip6_output.c:215) ipvlan_xmit_mode_l3 (drivers/net/ipvlan/ipvlan_core.c:602) ipvlan ipvlan_start_xmit (drivers/net/ipvlan/ipvlan_main.c:226) ipvlan dev_hard_start_xmit (net/core/dev.c:3594) sch_direct_xmit (net/sched/sch_generic.c:343) __qdisc_run (net/sched/sch_generic.c:416) net_tx_action (net/core/dev.c:5286) handle_softirqs (kernel/softirq.c:555) __irq_exit_rcu (kernel/softirq.c:589) sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1043)
The warning triggers as this: packet_sendmsg packet_snd //skb->sk is packet sk __dev_queue_xmit __dev_xmit_skb //q->enqueue is not NULL __qdisc_run sch_direct_xmit dev_hard_start_xmit ipvlan_start_xmit ipvlan_xmit_mode_l3 //l3 mode ipvlan_process_outbound //vepa flag ipvlan_process_v6_outbound ip6_local_out __ip6_finish_output ip6_finish_output2 //multicast packet sk_mc_loop //sk->sk_family is AF_PACKET
Call ip{6}_local_out() with NULL sk in ipvlan as other tunnels to fix this.(CVE-2024-33621)
In the Linux kernel, the following vulnerability has been resolved:
dma-mapping: benchmark: fix node id validation
While validating node ids in map_benchmark_ioctl(), node_possible() may be provided with invalid argument outside of [0,MAX_NUMNODES-1] range leading to:
BUG: KASAN: wild-memory-access in map_benchmark_ioctl (kernel/dma/map_benchmark.c:214) Read of size 8 at addr 1fffffff8ccb6398 by task dma_map_benchma/971 CPU: 7 PID: 971 Comm: dma_map_benchma Not tainted 6.9.0-rc6 #37 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) Call Trace: <TASK> dump_stack_lvl (lib/dump_stack.c:117) kasan_report (mm/kasan/report.c:603) kasan_check_range (mm/kasan/generic.c:189) variable_test_bit (arch/x86/include/asm/bitops.h:227) [inline] arch_test_bit (arch/x86/include/asm/bitops.h:239) [inline] _test_bit at (include/asm-generic/bitops/instrumented-non-atomic.h:142) [inline] node_state (include/linux/nodemask.h:423) [inline] map_benchmark_ioctl (kernel/dma/map_benchmark.c:214) full_proxy_unlocked_ioctl (fs/debugfs/file.c:333) __x64_sys_ioctl (fs/ioctl.c:890) do_syscall_64 (arch/x86/entry/common.c:83) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
Compare node ids with sane bounds first. NUMA_NO_NODE is considered a special valid case meaning that benchmarking kthreads won't be bound to a cpuset of a given node.
Found by Linux Verification Center (linuxtesting.org).(CVE-2024-34777)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/rxe: Fix seg fault in rxe_comp_queue_pkt
In rxe_comp_queue_pkt() an incoming response packet skb is enqueued to the resp_pkts queue and then a decision is made whether to run the completer task inline or schedule it. Finally the skb is dereferenced to bump a 'hw' performance counter. This is wrong because if the completer task is already running in a separate thread it may have already processed the skb and freed it which can cause a seg fault. This has been observed infrequently in testing at high scale.
This patch fixes this by changing the order of enqueuing the packet until after the counter is accessed.(CVE-2024-38544)
In the Linux kernel, the following vulnerability has been resolved:
wifi: ar5523: enable proper endpoint verification
Syzkaller reports [1] hitting a warning about an endpoint in use not having an expected type to it.
Fix the issue by checking for the existence of all proper endpoints with their according types intact.
Sadly, this patch has not been tested on real hardware.
[1] Syzkaller report: ------------[ cut here ]------------ usb 1-1: BOGUS urb xfer, pipe 3 != type 1 WARNING: CPU: 0 PID: 3643 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504 ... Call Trace: <TASK> ar5523_cmd+0x41b/0x780 drivers/net/wireless/ath/ar5523/ar5523.c:275 ar5523_cmd_read drivers/net/wireless/ath/ar5523/ar5523.c:302 [inline] ar5523_host_available drivers/net/wireless/ath/ar5523/ar5523.c:1376 [inline] ar5523_probe+0x14b0/0x1d10 drivers/net/wireless/ath/ar5523/ar5523.c:1655 usb_probe_interface+0x30f/0x7f0 drivers/usb/core/driver.c:396 call_driver_probe drivers/base/dd.c:560 [inline] really_probe+0x249/0xb90 drivers/base/dd.c:639 __driver_probe_device+0x1df/0x4d0 drivers/base/dd.c:778 driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:808 __device_attach_driver+0x1d4/0x2e0 drivers/base/dd.c:936 bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:427 __device_attach+0x1e4/0x530 drivers/base/dd.c:1008 bus_probe_device+0x1e8/0x2a0 drivers/base/bus.c:487 device_add+0xbd9/0x1e90 drivers/base/core.c:3517 usb_set_configuration+0x101d/0x1900 drivers/usb/core/message.c:2170 usb_generic_driver_probe+0xbe/0x100 drivers/usb/core/generic.c:238 usb_probe_device+0xd8/0x2c0 drivers/usb/core/driver.c:293 call_driver_probe drivers/base/dd.c:560 [inline] really_probe+0x249/0xb90 drivers/base/dd.c:639 __driver_probe_device+0x1df/0x4d0 drivers/base/dd.c:778 driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:808 __device_attach_driver+0x1d4/0x2e0 drivers/base/dd.c:936 bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:427 __device_attach+0x1e4/0x530 drivers/base/dd.c:1008 bus_probe_device+0x1e8/0x2a0 drivers/base/bus.c:487 device_add+0xbd9/0x1e90 drivers/base/core.c:3517 usb_new_device.cold+0x685/0x10ad drivers/usb/core/hub.c:2573 hub_port_connect drivers/usb/core/hub.c:5353 [inline] hub_port_connect_change drivers/usb/core/hub.c:5497 [inline] port_event drivers/usb/core/hub.c:5653 [inline] hub_event+0x26cb/0x45d0 drivers/usb/core/hub.c:5735 process_one_work+0x9bf/0x1710 kernel/workqueue.c:2289 worker_thread+0x669/0x1090 kernel/workqueue.c:2436 kthread+0x2e8/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306 </TASK>(CVE-2024-38565)
In the Linux kernel, the following vulnerability has been resolved:
eth: sungem: remove .ndo_poll_controller to avoid deadlocks
Erhard reports netpoll warnings from sungem:
netpoll_send_skb_on_dev(): eth0 enabled interrupts in poll (gem_start_xmit+0x0/0x398) WARNING: CPU: 1 PID: 1 at net/core/netpoll.c:370 netpoll_send_skb+0x1fc/0x20c
gem_poll_controller() disables interrupts, which may sleep. We can't sleep in netpoll, it has interrupts disabled completely. Strangely, gem_poll_controller() doesn't even poll the completions, and instead acts as if an interrupt has fired so it just schedules NAPI and exits. None of this has been necessary for years, since netpoll invokes NAPI directly.(CVE-2024-38597)
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix mb_cache_entry's e_refcnt leak in ext4_xattr_block_cache_find()
Syzbot reports a warning as follows:
============================================ WARNING: CPU: 0 PID: 5075 at fs/mbcache.c:419 mb_cache_destroy+0x224/0x290 Modules linked in: CPU: 0 PID: 5075 Comm: syz-executor199 Not tainted 6.9.0-rc6-gb947cc5bf6d7 RIP: 0010:mb_cache_destroy+0x224/0x290 fs/mbcache.c:419 Call Trace: <TASK> ext4_put_super+0x6d4/0xcd0 fs/ext4/super.c:1375 generic_shutdown_super+0x136/0x2d0 fs/super.c:641 kill_block_super+0x44/0x90 fs/super.c:1675 ext4_kill_sb+0x68/0xa0 fs/ext4/super.c:7327 [...] ============================================
This is because when finding an entry in ext4_xattr_block_cache_find(), if ext4_sb_bread() returns -ENOMEM, the ce's e_refcnt, which has already grown in the __entry_find(), won't be put away, and eventually trigger the above issue in mb_cache_destroy() due to reference count leakage.
So call mb_cache_entry_put() on the -ENOMEM error branch as a quick fix.(CVE-2024-39276)
In the Linux kernel, the following vulnerability has been resolved:
md/raid5: fix deadlock that raid5d() wait for itself to clear MD_SB_CHANGE_PENDING
Xiao reported that lvm2 test lvconvert-raid-takeover.sh can hang with small possibility, the root cause is exactly the same as commit bed9e27baf52 ("Revert "md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d"")
However, Dan reported another hang after that, and junxiao investigated the problem and found out that this is caused by plugged bio can't issue from raid5d().
Current implementation in raid5d() has a weird dependence:
1) md_check_recovery() from raid5d() must hold 'reconfig_mutex' to clear MD_SB_CHANGE_PENDING; 2) raid5d() handles IO in a deadloop, until all IO are issued; 3) IO from raid5d() must wait for MD_SB_CHANGE_PENDING to be cleared;
This behaviour is introduce before v2.6, and for consequence, if other context hold 'reconfig_mutex', and md_check_recovery() can't update super_block, then raid5d() will waste one cpu 100% by the deadloop, until 'reconfig_mutex' is released.
Refer to the implementation from raid1 and raid10, fix this problem by skipping issue IO if MD_SB_CHANGE_PENDING is still set after md_check_recovery(), daemon thread will be woken up when 'reconfig_mutex' is released. Meanwhile, the hang problem will be fixed as well.(CVE-2024-39476)
In the Linux kernel, the following vulnerability has been resolved:
jfs: xattr: fix buffer overflow for invalid xattr
When an xattr size is not what is expected, it is printed out to the kernel log in hex format as a form of debugging. But when that xattr size is bigger than the expected size, printing it out can cause an access off the end of the buffer.
Fix this all up by properly restricting the size of the debug hex dump in the kernel log.(CVE-2024-40902)
In the Linux kernel, the following vulnerability has been resolved:
iommu: Return right value in iommu_sva_bind_device()
iommu_sva_bind_device() should return either a sva bond handle or an ERR_PTR value in error cases. Existing drivers (idxd and uacce) only check the return value with IS_ERR(). This could potentially lead to a kernel NULL pointer dereference issue if the function returns NULL instead of an error pointer.
In reality, this doesn't cause any problems because iommu_sva_bind_device() only returns NULL when the kernel is not configured with CONFIG_IOMMU_SVA. In this case, iommu_dev_enable_feature(dev, IOMMU_DEV_FEAT_SVA) will return an error, and the device drivers won't call iommu_sva_bind_device() at all.(CVE-2024-40945)
In the Linux kernel, the following vulnerability has been resolved:
tty: add the option to have a tty reject a new ldisc
... and use it to limit the virtual terminals to just N_TTY. They are kind of special, and in particular, the "con_write()" routine violates the "writes cannot sleep" rule that some ldiscs rely on.
This avoids the
BUG: sleeping function called from invalid context at kernel/printk/printk.c:2659
when N_GSM has been attached to a virtual console, and gsmld_write() calls con_write() while holding a spinlock, and con_write() then tries to get the console lock.(CVE-2024-40966)
In the Linux kernel, the following vulnerability has been resolved:
can: mcp251xfd: fix infinite loop when xmit fails
When the mcp251xfd_start_xmit() function fails, the driver stops processing messages, and the interrupt routine does not return, running indefinitely even after killing the running application.
Error messages: [ 441.298819] mcp251xfd spi2.0 can0: ERROR in mcp251xfd_start_xmit: -16 [ 441.306498] mcp251xfd spi2.0 can0: Transmit Event FIFO buffer not empty. (seq=0x000017c7, tef_tail=0x000017cf, tef_head=0x000017d0, tx_head=0x000017d3). ... and repeat forever.
The issue can be triggered when multiple devices share the same SPI interface. And there is concurrent access to the bus.
The problem occurs because tx_ring->head increments even if mcp251xfd_start_xmit() fails. Consequently, the driver skips one TX package while still expecting a response in mcp251xfd_handle_tefif_one().
Resolve the issue by starting a workqueue to write the tx obj synchronously if err = -EBUSY. In case of another error, decrement tx_ring->head, remove skb from the echo stack, and drop the message.
mkl: use more imperative wording in patch description
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: fully validate NFT_DATA_VALUE on store to data registers
register store validation for NFT_DATA_VALUE is conditional, however, the datatype is always either NFT_DATA_VALUE or NFT_DATA_VERDICT. This only requires a new helper function to infer the register type from the set datatype so this conditional check can be removed. Otherwise, pointer to chain object can be leaked through the registers.(CVE-2024-42070)
In the Linux kernel, the following vulnerability has been resolved:
drm/lima: fix shared irq handling on driver remove
lima uses a shared interrupt, so the interrupt handlers must be prepared to be called at any time. At driver removal time, the clocks are disabled early and the interrupts stay registered until the very end of the remove process due to the devm usage. This is potentially a bug as the interrupts access device registers which assumes clocks are enabled. A crash can be triggered by removing the driver in a kernel with CONFIG_DEBUG_SHIRQ enabled. This patch frees the interrupts at each lima device finishing callback so that the handlers are already unregistered by the time we fully disable clocks.(CVE-2024-42127)
In the Linux kernel, the following vulnerability has been resolved:
mm: avoid overflows in dirty throttling logic
The dirty throttling logic is interspersed with assumptions that dirty limits in PAGE_SIZE units fit into 32-bit (so that various multiplications fit into 64-bits). If limits end up being larger, we will hit overflows, possible divisions by 0 etc. Fix these problems by never allowing so large dirty limits as they have dubious practical value anyway. For dirty_bytes / dirty_background_bytes interfaces we can just refuse to set so large limits. For dirty_ratio / dirty_background_ratio it isn't so simple as the dirty limit is computed from the amount of available memory which can change due to memory hotplug etc. So when converting dirty limits from ratios to numbers of pages, we just don't allow the result to exceed UINT_MAX.
This is root-only triggerable problem which occurs when the operator sets dirty limits to >16 TB.(CVE-2024-42131)
In the Linux kernel, the following vulnerability has been resolved:
libceph: fix race between delayed_work() and ceph_monc_stop()
The way the delayed work is handled in ceph_monc_stop() is prone to races with mon_fault() and possibly also finish_hunting(). Both of these can requeue the delayed work which wouldn't be canceled by any of the following code in case that happens after cancel_delayed_work_sync() runs -- __close_session() doesn't mess with the delayed work in order to avoid interfering with the hunting interval logic. This part was missed in commit b5d91704f53e ("libceph: behave in mon_fault() if cur_mon < 0") and use-after-free can still ensue on monc and objects that hang off of it, with monc->auth and monc->monmap being particularly susceptible to quickly being reused.
To fix this:
- clear monc->cur_mon and monc->hunting as part of closing the session in ceph_monc_stop()
- bail from delayed_work() if monc->cur_mon is cleared, similar to how it's done in mon_fault() and finish_hunting() (based on monc->hunting)
- call cancel_delayed_work_sync() after the session is closed(CVE-2024-42232)
In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: configfs: Prevent OOB read/write in usb_string_copy()
Userspace provided string 's' could trivially have the length zero. Left
unchecked this will firstly result in an OOB read in the form
if (str[0 - 1] == '\n') followed closely by an OOB write in the formstr[0 - 1] = '\0'`.
There is already a validating check to catch strings that are too long. Let's supply an additional check for invalid strings that are too short.(CVE-2024-42236)
In the Linux kernel, the following vulnerability has been resolved:
ext4: make sure the first directory block is not a hole
The syzbot constructs a directory that has no dirblock but is non-inline, i.e. the first directory block is a hole. And no errors are reported when creating files in this directory in the following flow.
ext4_mknod
...
ext4_add_entry
// Read block 0
ext4_read_dirblock(dir, block, DIRENT)
bh = ext4_bread(NULL, inode, block, 0)
if (!bh && (type == INDEX || type == DIRENT_HTREE))
// The first directory block is a hole
// But type == DIRENT, so no error is reported.
After that, we get a directory block without '.' and '..' but with a valid dentry. This may cause some code that relies on dot or dotdot (such as make_indexed_dir()) to crash.
Therefore when ext4_read_dirblock() finds that the first directory block is a hole report that the filesystem is corrupted and return an error to avoid loading corrupted data from disk causing something bad.(CVE-2024-42304)
In the Linux kernel, the following vulnerability has been resolved:
drm/gma500: fix null pointer dereference in cdv_intel_lvds_get_modes
In cdv_intel_lvds_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-2024-42310)
In the Linux kernel, the following vulnerability has been resolved:
bna: adjust 'name' buf size of bna_tcb and bna_ccb structures
To have enough space to write all possible sprintf() args. Currently 'name' size is 16, but the first '%s' specifier may already need at least 16 characters, since 'bnad->netdev->name' is used there.
For '%d' specifiers, assume that they require: * 1 char for 'tx_id + tx_info->tcb[i]->id' sum, BNAD_MAX_TXQ_PER_TX is 8 * 2 chars for 'rx_id + rx_info->rx_ctrl[i].ccb->id', BNAD_MAX_RXP_PER_RX is 16
And replace sprintf with snprintf.
Detected using the static analysis tool - Svace.(CVE-2024-43839)
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-5.10.0-224.0.0.123.oe2203sp4.aarch64.rpm",
"bpftool-debuginfo-5.10.0-224.0.0.123.oe2203sp4.aarch64.rpm",
"kernel-5.10.0-224.0.0.123.oe2203sp4.aarch64.rpm",
"kernel-debuginfo-5.10.0-224.0.0.123.oe2203sp4.aarch64.rpm",
"kernel-debugsource-5.10.0-224.0.0.123.oe2203sp4.aarch64.rpm",
"kernel-devel-5.10.0-224.0.0.123.oe2203sp4.aarch64.rpm",
"kernel-headers-5.10.0-224.0.0.123.oe2203sp4.aarch64.rpm",
"kernel-source-5.10.0-224.0.0.123.oe2203sp4.aarch64.rpm",
"kernel-tools-5.10.0-224.0.0.123.oe2203sp4.aarch64.rpm",
"kernel-tools-debuginfo-5.10.0-224.0.0.123.oe2203sp4.aarch64.rpm",
"kernel-tools-devel-5.10.0-224.0.0.123.oe2203sp4.aarch64.rpm",
"perf-5.10.0-224.0.0.123.oe2203sp4.aarch64.rpm",
"perf-debuginfo-5.10.0-224.0.0.123.oe2203sp4.aarch64.rpm",
"python3-perf-5.10.0-224.0.0.123.oe2203sp4.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-224.0.0.123.oe2203sp4.aarch64.rpm"
],
"src": [
"kernel-5.10.0-224.0.0.123.oe2203sp4.src.rpm"
],
"x86_64": [
"bpftool-5.10.0-224.0.0.123.oe2203sp4.x86_64.rpm",
"bpftool-debuginfo-5.10.0-224.0.0.123.oe2203sp4.x86_64.rpm",
"kernel-5.10.0-224.0.0.123.oe2203sp4.x86_64.rpm",
"kernel-debuginfo-5.10.0-224.0.0.123.oe2203sp4.x86_64.rpm",
"kernel-debugsource-5.10.0-224.0.0.123.oe2203sp4.x86_64.rpm",
"kernel-devel-5.10.0-224.0.0.123.oe2203sp4.x86_64.rpm",
"kernel-headers-5.10.0-224.0.0.123.oe2203sp4.x86_64.rpm",
"kernel-source-5.10.0-224.0.0.123.oe2203sp4.x86_64.rpm",
"kernel-tools-5.10.0-224.0.0.123.oe2203sp4.x86_64.rpm",
"kernel-tools-debuginfo-5.10.0-224.0.0.123.oe2203sp4.x86_64.rpm",
"kernel-tools-devel-5.10.0-224.0.0.123.oe2203sp4.x86_64.rpm",
"perf-5.10.0-224.0.0.123.oe2203sp4.x86_64.rpm",
"perf-debuginfo-5.10.0-224.0.0.123.oe2203sp4.x86_64.rpm",
"python3-perf-5.10.0-224.0.0.123.oe2203sp4.x86_64.rpm",
"python3-perf-debuginfo-5.10.0-224.0.0.123.oe2203sp4.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:22.03-LTS-SP4",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP4"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.10.0-224.0.0.123.oe2203sp4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nipvlan: Dont Use skb-\u0026gt;sk in ipvlan_process_v{4,6}_outbound\r\n\r\nRaw packet from PF_PACKET socket ontop of an IPv6-backed ipvlan device will\nhit WARN_ON_ONCE() in sk_mc_loop() through sch_direct_xmit() path.\r\n\r\nWARNING: CPU: 2 PID: 0 at net/core/sock.c:775 sk_mc_loop+0x2d/0x70\nModules linked in: sch_netem ipvlan rfkill cirrus drm_shmem_helper sg drm_kms_helper\nCPU: 2 PID: 0 Comm: swapper/2 Kdump: loaded Not tainted 6.9.0+ #279\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014\nRIP: 0010:sk_mc_loop+0x2d/0x70\nCode: fa 0f 1f 44 00 00 65 0f b7 15 f7 96 a3 4f 31 c0 66 85 d2 75 26 48 85 ff 74 1c\nRSP: 0018:ffffa9584015cd78 EFLAGS: 00010212\nRAX: 0000000000000011 RBX: ffff91e585793e00 RCX: 0000000002c6a001\nRDX: 0000000000000000 RSI: 0000000000000040 RDI: ffff91e589c0f000\nRBP: ffff91e5855bd100 R08: 0000000000000000 R09: 3d00545216f43d00\nR10: ffff91e584fdcc50 R11: 00000060dd8616f4 R12: ffff91e58132d000\nR13: ffff91e584fdcc68 R14: ffff91e5869ce800 R15: ffff91e589c0f000\nFS: 0000000000000000(0000) GS:ffff91e898100000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f788f7c44c0 CR3: 0000000008e1a000 CR4: 00000000000006f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n\u0026lt;IRQ\u0026gt;\n ? __warn (kernel/panic.c:693)\n ? sk_mc_loop (net/core/sock.c:760)\n ? report_bug (lib/bug.c:201 lib/bug.c:219)\n ? handle_bug (arch/x86/kernel/traps.c:239)\n ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminator 1))\n ? asm_exc_invalid_op (./arch/x86/include/asm/idtentry.h:621)\n ? sk_mc_loop (net/core/sock.c:760)\n ip6_finish_output2 (net/ipv6/ip6_output.c:83 (discriminator 1))\n ? nf_hook_slow (net/netfilter/core.c:626)\n ip6_finish_output (net/ipv6/ip6_output.c:222)\n ? __pfx_ip6_finish_output (net/ipv6/ip6_output.c:215)\n ipvlan_xmit_mode_l3 (drivers/net/ipvlan/ipvlan_core.c:602) ipvlan\n ipvlan_start_xmit (drivers/net/ipvlan/ipvlan_main.c:226) ipvlan\n dev_hard_start_xmit (net/core/dev.c:3594)\n sch_direct_xmit (net/sched/sch_generic.c:343)\n __qdisc_run (net/sched/sch_generic.c:416)\n net_tx_action (net/core/dev.c:5286)\n handle_softirqs (kernel/softirq.c:555)\n __irq_exit_rcu (kernel/softirq.c:589)\n sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1043)\r\n\r\nThe warning triggers as this:\npacket_sendmsg\n packet_snd //skb-\u0026gt;sk is packet sk\n __dev_queue_xmit\n __dev_xmit_skb //q-\u0026gt;enqueue is not NULL\n __qdisc_run\n sch_direct_xmit\n dev_hard_start_xmit\n ipvlan_start_xmit\n ipvlan_xmit_mode_l3 //l3 mode\n ipvlan_process_outbound //vepa flag\n ipvlan_process_v6_outbound\n ip6_local_out\n __ip6_finish_output\n ip6_finish_output2 //multicast packet\n sk_mc_loop //sk-\u0026gt;sk_family is AF_PACKET\r\n\r\nCall ip{6}_local_out() with NULL sk in ipvlan as other tunnels to fix this.(CVE-2024-33621)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndma-mapping: benchmark: fix node id validation\r\n\r\nWhile validating node ids in map_benchmark_ioctl(), node_possible() may\nbe provided with invalid argument outside of [0,MAX_NUMNODES-1] range\nleading to:\r\n\r\nBUG: KASAN: wild-memory-access in map_benchmark_ioctl (kernel/dma/map_benchmark.c:214)\nRead of size 8 at addr 1fffffff8ccb6398 by task dma_map_benchma/971\nCPU: 7 PID: 971 Comm: dma_map_benchma Not tainted 6.9.0-rc6 #37\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996)\nCall Trace:\n \u0026lt;TASK\u0026gt;\ndump_stack_lvl (lib/dump_stack.c:117)\nkasan_report (mm/kasan/report.c:603)\nkasan_check_range (mm/kasan/generic.c:189)\nvariable_test_bit (arch/x86/include/asm/bitops.h:227) [inline]\narch_test_bit (arch/x86/include/asm/bitops.h:239) [inline]\n_test_bit at (include/asm-generic/bitops/instrumented-non-atomic.h:142) [inline]\nnode_state (include/linux/nodemask.h:423) [inline]\nmap_benchmark_ioctl (kernel/dma/map_benchmark.c:214)\nfull_proxy_unlocked_ioctl (fs/debugfs/file.c:333)\n__x64_sys_ioctl (fs/ioctl.c:890)\ndo_syscall_64 (arch/x86/entry/common.c:83)\nentry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)\r\n\r\nCompare node ids with sane bounds first. NUMA_NO_NODE is considered a\nspecial valid case meaning that benchmarking kthreads won\u0026apos;t be bound to a\ncpuset of a given node.\r\n\r\nFound by Linux Verification Center (linuxtesting.org).(CVE-2024-34777)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nRDMA/rxe: Fix seg fault in rxe_comp_queue_pkt\r\n\r\nIn rxe_comp_queue_pkt() an incoming response packet skb is enqueued to the\nresp_pkts queue and then a decision is made whether to run the completer\ntask inline or schedule it. Finally the skb is dereferenced to bump a \u0026apos;hw\u0026apos;\nperformance counter. This is wrong because if the completer task is\nalready running in a separate thread it may have already processed the skb\nand freed it which can cause a seg fault. This has been observed\ninfrequently in testing at high scale.\r\n\r\nThis patch fixes this by changing the order of enqueuing the packet until\nafter the counter is accessed.(CVE-2024-38544)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: ar5523: enable proper endpoint verification\r\n\r\nSyzkaller reports [1] hitting a warning about an endpoint in use\nnot having an expected type to it.\r\n\r\nFix the issue by checking for the existence of all proper\nendpoints with their according types intact.\r\n\r\nSadly, this patch has not been tested on real hardware.\r\n\r\n[1] Syzkaller report:\n------------[ cut here ]------------\nusb 1-1: BOGUS urb xfer, pipe 3 != type 1\nWARNING: CPU: 0 PID: 3643 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504\n...\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ar5523_cmd+0x41b/0x780 drivers/net/wireless/ath/ar5523/ar5523.c:275\n ar5523_cmd_read drivers/net/wireless/ath/ar5523/ar5523.c:302 [inline]\n ar5523_host_available drivers/net/wireless/ath/ar5523/ar5523.c:1376 [inline]\n ar5523_probe+0x14b0/0x1d10 drivers/net/wireless/ath/ar5523/ar5523.c:1655\n usb_probe_interface+0x30f/0x7f0 drivers/usb/core/driver.c:396\n call_driver_probe drivers/base/dd.c:560 [inline]\n really_probe+0x249/0xb90 drivers/base/dd.c:639\n __driver_probe_device+0x1df/0x4d0 drivers/base/dd.c:778\n driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:808\n __device_attach_driver+0x1d4/0x2e0 drivers/base/dd.c:936\n bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:427\n __device_attach+0x1e4/0x530 drivers/base/dd.c:1008\n bus_probe_device+0x1e8/0x2a0 drivers/base/bus.c:487\n device_add+0xbd9/0x1e90 drivers/base/core.c:3517\n usb_set_configuration+0x101d/0x1900 drivers/usb/core/message.c:2170\n usb_generic_driver_probe+0xbe/0x100 drivers/usb/core/generic.c:238\n usb_probe_device+0xd8/0x2c0 drivers/usb/core/driver.c:293\n call_driver_probe drivers/base/dd.c:560 [inline]\n really_probe+0x249/0xb90 drivers/base/dd.c:639\n __driver_probe_device+0x1df/0x4d0 drivers/base/dd.c:778\n driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:808\n __device_attach_driver+0x1d4/0x2e0 drivers/base/dd.c:936\n bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:427\n __device_attach+0x1e4/0x530 drivers/base/dd.c:1008\n bus_probe_device+0x1e8/0x2a0 drivers/base/bus.c:487\n device_add+0xbd9/0x1e90 drivers/base/core.c:3517\n usb_new_device.cold+0x685/0x10ad drivers/usb/core/hub.c:2573\n hub_port_connect drivers/usb/core/hub.c:5353 [inline]\n hub_port_connect_change drivers/usb/core/hub.c:5497 [inline]\n port_event drivers/usb/core/hub.c:5653 [inline]\n hub_event+0x26cb/0x45d0 drivers/usb/core/hub.c:5735\n process_one_work+0x9bf/0x1710 kernel/workqueue.c:2289\n worker_thread+0x669/0x1090 kernel/workqueue.c:2436\n kthread+0x2e8/0x3a0 kernel/kthread.c:376\n ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306\n \u0026lt;/TASK\u0026gt;(CVE-2024-38565)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\neth: sungem: remove .ndo_poll_controller to avoid deadlocks\r\n\r\nErhard reports netpoll warnings from sungem:\r\n\r\n netpoll_send_skb_on_dev(): eth0 enabled interrupts in poll (gem_start_xmit+0x0/0x398)\n WARNING: CPU: 1 PID: 1 at net/core/netpoll.c:370 netpoll_send_skb+0x1fc/0x20c\r\n\r\ngem_poll_controller() disables interrupts, which may sleep.\nWe can\u0026apos;t sleep in netpoll, it has interrupts disabled completely.\nStrangely, gem_poll_controller() doesn\u0026apos;t even poll the completions,\nand instead acts as if an interrupt has fired so it just schedules\nNAPI and exits. None of this has been necessary for years, since\nnetpoll invokes NAPI directly.(CVE-2024-38597)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\next4: fix mb_cache_entry\u0026apos;s e_refcnt leak in ext4_xattr_block_cache_find()\r\n\r\nSyzbot reports a warning as follows:\r\n\r\n============================================\nWARNING: CPU: 0 PID: 5075 at fs/mbcache.c:419 mb_cache_destroy+0x224/0x290\nModules linked in:\nCPU: 0 PID: 5075 Comm: syz-executor199 Not tainted 6.9.0-rc6-gb947cc5bf6d7\nRIP: 0010:mb_cache_destroy+0x224/0x290 fs/mbcache.c:419\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ext4_put_super+0x6d4/0xcd0 fs/ext4/super.c:1375\n generic_shutdown_super+0x136/0x2d0 fs/super.c:641\n kill_block_super+0x44/0x90 fs/super.c:1675\n ext4_kill_sb+0x68/0xa0 fs/ext4/super.c:7327\n[...]\n============================================\r\n\r\nThis is because when finding an entry in ext4_xattr_block_cache_find(), if\next4_sb_bread() returns -ENOMEM, the ce\u0026apos;s e_refcnt, which has already grown\nin the __entry_find(), won\u0026apos;t be put away, and eventually trigger the above\nissue in mb_cache_destroy() due to reference count leakage.\r\n\r\nSo call mb_cache_entry_put() on the -ENOMEM error branch as a quick fix.(CVE-2024-39276)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmd/raid5: fix deadlock that raid5d() wait for itself to clear MD_SB_CHANGE_PENDING\r\n\r\nXiao reported that lvm2 test lvconvert-raid-takeover.sh can hang with\nsmall possibility, the root cause is exactly the same as commit\nbed9e27baf52 (\u0026quot;Revert \u0026quot;md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d\u0026quot;\u0026quot;)\r\n\r\nHowever, Dan reported another hang after that, and junxiao investigated\nthe problem and found out that this is caused by plugged bio can\u0026apos;t issue\nfrom raid5d().\r\n\r\nCurrent implementation in raid5d() has a weird dependence:\r\n\r\n1) md_check_recovery() from raid5d() must hold \u0026apos;reconfig_mutex\u0026apos; to clear\n MD_SB_CHANGE_PENDING;\n2) raid5d() handles IO in a deadloop, until all IO are issued;\n3) IO from raid5d() must wait for MD_SB_CHANGE_PENDING to be cleared;\r\n\r\nThis behaviour is introduce before v2.6, and for consequence, if other\ncontext hold \u0026apos;reconfig_mutex\u0026apos;, and md_check_recovery() can\u0026apos;t update\nsuper_block, then raid5d() will waste one cpu 100% by the deadloop, until\n\u0026apos;reconfig_mutex\u0026apos; is released.\r\n\r\nRefer to the implementation from raid1 and raid10, fix this problem by\nskipping issue IO if MD_SB_CHANGE_PENDING is still set after\nmd_check_recovery(), daemon thread will be woken up when \u0026apos;reconfig_mutex\u0026apos;\nis released. Meanwhile, the hang problem will be fixed as well.(CVE-2024-39476)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\njfs: xattr: fix buffer overflow for invalid xattr\r\n\r\nWhen an xattr size is not what is expected, it is printed out to the\nkernel log in hex format as a form of debugging. But when that xattr\nsize is bigger than the expected size, printing it out can cause an\naccess off the end of the buffer.\r\n\r\nFix this all up by properly restricting the size of the debug hex dump\nin the kernel log.(CVE-2024-40902)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\niommu: Return right value in iommu_sva_bind_device()\r\n\r\niommu_sva_bind_device() should return either a sva bond handle or an\nERR_PTR value in error cases. Existing drivers (idxd and uacce) only\ncheck the return value with IS_ERR(). This could potentially lead to\na kernel NULL pointer dereference issue if the function returns NULL\ninstead of an error pointer.\r\n\r\nIn reality, this doesn\u0026apos;t cause any problems because iommu_sva_bind_device()\nonly returns NULL when the kernel is not configured with CONFIG_IOMMU_SVA.\nIn this case, iommu_dev_enable_feature(dev, IOMMU_DEV_FEAT_SVA) will\nreturn an error, and the device drivers won\u0026apos;t call iommu_sva_bind_device()\nat all.(CVE-2024-40945)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntty: add the option to have a tty reject a new ldisc\r\n\r\n... and use it to limit the virtual terminals to just N_TTY. They are\nkind of special, and in particular, the \u0026quot;con_write()\u0026quot; routine violates\nthe \u0026quot;writes cannot sleep\u0026quot; rule that some ldiscs rely on.\r\n\r\nThis avoids the\r\n\r\n BUG: sleeping function called from invalid context at kernel/printk/printk.c:2659\r\n\r\nwhen N_GSM has been attached to a virtual console, and gsmld_write()\ncalls con_write() while holding a spinlock, and con_write() then tries\nto get the console lock.(CVE-2024-40966)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncan: mcp251xfd: fix infinite loop when xmit fails\r\n\r\nWhen the mcp251xfd_start_xmit() function fails, the driver stops\nprocessing messages, and the interrupt routine does not return,\nrunning indefinitely even after killing the running application.\r\n\r\nError messages:\n[ 441.298819] mcp251xfd spi2.0 can0: ERROR in mcp251xfd_start_xmit: -16\n[ 441.306498] mcp251xfd spi2.0 can0: Transmit Event FIFO buffer not empty. (seq=0x000017c7, tef_tail=0x000017cf, tef_head=0x000017d0, tx_head=0x000017d3).\n... and repeat forever.\r\n\r\nThe issue can be triggered when multiple devices share the same SPI\ninterface. And there is concurrent access to the bus.\r\n\r\nThe problem occurs because tx_ring-\u0026gt;head increments even if\nmcp251xfd_start_xmit() fails. Consequently, the driver skips one TX\npackage while still expecting a response in\nmcp251xfd_handle_tefif_one().\r\n\r\nResolve the issue by starting a workqueue to write the tx obj\nsynchronously if err = -EBUSY. In case of another error, decrement\ntx_ring-\u0026gt;head, remove skb from the echo stack, and drop the message.\r\n\r\n[mkl: use more imperative wording in patch description](CVE-2024-41088)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nf_tables: fully validate NFT_DATA_VALUE on store to data registers\r\n\r\nregister store validation for NFT_DATA_VALUE is conditional, however,\nthe datatype is always either NFT_DATA_VALUE or NFT_DATA_VERDICT. This\nonly requires a new helper function to infer the register type from the\nset datatype so this conditional check can be removed. Otherwise,\npointer to chain object can be leaked through the registers.(CVE-2024-42070)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/lima: fix shared irq handling on driver remove\r\n\r\nlima uses a shared interrupt, so the interrupt handlers must be prepared\nto be called at any time. At driver removal time, the clocks are\ndisabled early and the interrupts stay registered until the very end of\nthe remove process due to the devm usage.\nThis is potentially a bug as the interrupts access device registers\nwhich assumes clocks are enabled. A crash can be triggered by removing\nthe driver in a kernel with CONFIG_DEBUG_SHIRQ enabled.\nThis patch frees the interrupts at each lima device finishing callback\nso that the handlers are already unregistered by the time we fully\ndisable clocks.(CVE-2024-42127)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmm: avoid overflows in dirty throttling logic\r\n\r\nThe dirty throttling logic is interspersed with assumptions that dirty\nlimits in PAGE_SIZE units fit into 32-bit (so that various multiplications\nfit into 64-bits). If limits end up being larger, we will hit overflows,\npossible divisions by 0 etc. Fix these problems by never allowing so\nlarge dirty limits as they have dubious practical value anyway. For\ndirty_bytes / dirty_background_bytes interfaces we can just refuse to set\nso large limits. For dirty_ratio / dirty_background_ratio it isn\u0026apos;t so\nsimple as the dirty limit is computed from the amount of available memory\nwhich can change due to memory hotplug etc. So when converting dirty\nlimits from ratios to numbers of pages, we just don\u0026apos;t allow the result to\nexceed UINT_MAX.\r\n\r\nThis is root-only triggerable problem which occurs when the operator\nsets dirty limits to \u0026gt;16 TB.(CVE-2024-42131)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nlibceph: fix race between delayed_work() and ceph_monc_stop()\r\n\r\nThe way the delayed work is handled in ceph_monc_stop() is prone to\nraces with mon_fault() and possibly also finish_hunting(). Both of\nthese can requeue the delayed work which wouldn\u0026apos;t be canceled by any of\nthe following code in case that happens after cancel_delayed_work_sync()\nruns -- __close_session() doesn\u0026apos;t mess with the delayed work in order\nto avoid interfering with the hunting interval logic. This part was\nmissed in commit b5d91704f53e (\u0026quot;libceph: behave in mon_fault() if\ncur_mon \u0026lt; 0\u0026quot;) and use-after-free can still ensue on monc and objects\nthat hang off of it, with monc-\u0026gt;auth and monc-\u0026gt;monmap being\nparticularly susceptible to quickly being reused.\r\n\r\nTo fix this:\r\n\r\n- clear monc-\u0026gt;cur_mon and monc-\u0026gt;hunting as part of closing the session\n in ceph_monc_stop()\n- bail from delayed_work() if monc-\u0026gt;cur_mon is cleared, similar to how\n it\u0026apos;s done in mon_fault() and finish_hunting() (based on monc-\u0026gt;hunting)\n- call cancel_delayed_work_sync() after the session is closed(CVE-2024-42232)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: gadget: configfs: Prevent OOB read/write in usb_string_copy()\r\n\r\nUserspace provided string \u0026apos;s\u0026apos; could trivially have the length zero. Left\nunchecked this will firstly result in an OOB read in the form\n`if (str[0 - 1] == \u0026apos;\\n\u0026apos;) followed closely by an OOB write in the form\n`str[0 - 1] = \u0026apos;\\0\u0026apos;`.\r\n\r\nThere is already a validating check to catch strings that are too long.\nLet\u0026apos;s supply an additional check for invalid strings that are too short.(CVE-2024-42236)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\next4: make sure the first directory block is not a hole\r\n\r\nThe syzbot constructs a directory that has no dirblock but is non-inline,\ni.e. the first directory block is a hole. And no errors are reported when\ncreating files in this directory in the following flow.\r\n\r\n ext4_mknod\n ...\n ext4_add_entry\n // Read block 0\n ext4_read_dirblock(dir, block, DIRENT)\n bh = ext4_bread(NULL, inode, block, 0)\n if (!bh \u0026amp;\u0026amp; (type == INDEX || type == DIRENT_HTREE))\n // The first directory block is a hole\n // But type == DIRENT, so no error is reported.\r\n\r\nAfter that, we get a directory block without \u0026apos;.\u0026apos; and \u0026apos;..\u0026apos; but with a valid\ndentry. This may cause some code that relies on dot or dotdot (such as\nmake_indexed_dir()) to crash.\r\n\r\nTherefore when ext4_read_dirblock() finds that the first directory block\nis a hole report that the filesystem is corrupted and return an error to\navoid loading corrupted data from disk causing something bad.(CVE-2024-42304)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/gma500: fix null pointer dereference in cdv_intel_lvds_get_modes\r\n\r\nIn cdv_intel_lvds_get_modes(), the return value of drm_mode_duplicate()\nis assigned to mode, which will lead to a NULL pointer dereference on\nfailure of drm_mode_duplicate(). Add a check to avoid npd.(CVE-2024-42310)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbna: adjust \u0026apos;name\u0026apos; buf size of bna_tcb and bna_ccb structures\r\n\r\nTo have enough space to write all possible sprintf() args. Currently\n\u0026apos;name\u0026apos; size is 16, but the first \u0026apos;%s\u0026apos; specifier may already need at\nleast 16 characters, since \u0026apos;bnad-\u0026gt;netdev-\u0026gt;name\u0026apos; is used there.\r\n\r\nFor \u0026apos;%d\u0026apos; specifiers, assume that they require:\n * 1 char for \u0026apos;tx_id + tx_info-\u0026gt;tcb[i]-\u0026gt;id\u0026apos; sum, BNAD_MAX_TXQ_PER_TX is 8\n * 2 chars for \u0026apos;rx_id + rx_info-\u0026gt;rx_ctrl[i].ccb-\u0026gt;id\u0026apos;, BNAD_MAX_RXP_PER_RX\n is 16\r\n\r\nAnd replace sprintf with snprintf.\r\n\r\nDetected using the static analysis tool - Svace.(CVE-2024-43839)",
"id": "OESA-2024-2028",
"modified": "2026-08-06T11:07:30Z",
"published": "2024-08-23T11:07:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2028"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-33621"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-34777"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38544"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38565"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38597"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39276"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39476"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40902"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40945"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40966"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41088"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42070"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42127"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42131"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42232"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42236"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42304"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42310"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43839"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2024-33621",
"CVE-2024-34777",
"CVE-2024-38544",
"CVE-2024-38565",
"CVE-2024-38597",
"CVE-2024-39276",
"CVE-2024-39476",
"CVE-2024-40902",
"CVE-2024-40945",
"CVE-2024-40966",
"CVE-2024-41088",
"CVE-2024-42070",
"CVE-2024-42127",
"CVE-2024-42131",
"CVE-2024-42232",
"CVE-2024-42236",
"CVE-2024-42304",
"CVE-2024-42310",
"CVE-2024-43839"
]
}
OESA-2024-2029 (CVE-2024-26586)
Vulnerability from osv_openeuler – Published: 2024-08-23 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:
mlxsw: spectrum_acl_tcam: Fix stack corruption
When tc filters are first added to a net device, the corresponding local port gets bound to an ACL group in the device. The group contains a list of ACLs. In turn, each ACL points to a different TCAM region where the filters are stored. During forwarding, the ACLs are sequentially evaluated until a match is found.
One reason to place filters in different regions is when they are added with decreasing priorities and in an alternating order so that two consecutive filters can never fit in the same region because of their key usage.
In Spectrum-2 and newer ASICs the firmware started to report that the maximum number of ACLs in a group is more than 16, but the layout of the register that configures ACL groups (PAGT) was not updated to account for that. It is therefore possible to hit stack corruption [1] in the rare case where more than 16 ACLs in a group are required.
Fix by limiting the maximum ACL group size to the minimum between what the firmware reports and the maximum ACLs that fit in the PAGT register.
Add a test case to make sure the machine does not crash when this condition is hit.
[1] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: mlxsw_sp_acl_tcam_group_update+0x116/0x120 [...] dump_stack_lvl+0x36/0x50 panic+0x305/0x330 __stack_chk_fail+0x15/0x20 mlxsw_sp_acl_tcam_group_update+0x116/0x120 mlxsw_sp_acl_tcam_group_region_attach+0x69/0x110 mlxsw_sp_acl_tcam_vchunk_get+0x492/0xa20 mlxsw_sp_acl_tcam_ventry_add+0x25/0xe0 mlxsw_sp_acl_rule_add+0x47/0x240 mlxsw_sp_flower_replace+0x1a9/0x1d0 tc_setup_cb_add+0xdc/0x1c0 fl_hw_replace_filter+0x146/0x1f0 fl_change+0xc17/0x1360 tc_new_tfilter+0x472/0xb90 rtnetlink_rcv_msg+0x313/0x3b0 netlink_rcv_skb+0x58/0x100 netlink_unicast+0x244/0x390 netlink_sendmsg+0x1e4/0x440 ____sys_sendmsg+0x164/0x260 ___sys_sendmsg+0x9a/0xe0 __sys_sendmsg+0x7a/0xc0 do_syscall_64+0x40/0xe0 entry_SYSCALL_64_after_hwframe+0x63/0x6b(CVE-2024-26586)
In the Linux kernel, the following vulnerability has been resolved:
KVM: arm64: vgic-its: Avoid potential UAF in LPI translation cache
There is a potential UAF scenario in the case of an LPI translation cache hit racing with an operation that invalidates the cache, such as a DISCARD ITS command. The root of the problem is that vgic_its_check_cache() does not elevate the refcount on the vgic_irq before dropping the lock that serializes refcount changes.
Have vgic_its_check_cache() raise the refcount on the returned vgic_irq and add the corresponding decrement after queueing the interrupt.(CVE-2024-26598)
In the Linux kernel, the following vulnerability has been resolved:
sched/membarrier: reduce the ability to hammer on sys_membarrier
On some systems, sys_membarrier can be very expensive, causing overall slowdowns for everything. So put a lock on the path in order to serialize the accesses to prevent the ability for this to be called at too high of a frequency and saturate the machine.(CVE-2024-26602)
In the Linux kernel, the following vulnerability has been resolved:
tun: limit printing rate when illegal packet received by tun dev
vhost_worker will call tun call backs to receive packets. If too many illegal packets arrives, tun_do_read will keep dumping packet contents. When console is enabled, it will costs much more cpu time to dump packet and soft lockup will be detected.
net_ratelimit mechanism can be used to limit the dumping rate.
PID: 33036 TASK: ffff949da6f20000 CPU: 23 COMMAND: "vhost-32980" #0 [fffffe00003fce50] crash_nmi_callback at ffffffff89249253 #1 [fffffe00003fce58] nmi_handle at ffffffff89225fa3 #2 [fffffe00003fceb0] default_do_nmi at ffffffff8922642e #3 [fffffe00003fced0] do_nmi at ffffffff8922660d #4 [fffffe00003fcef0] end_repeat_nmi at ffffffff89c01663 [exception RIP: io_serial_in+20] RIP: ffffffff89792594 RSP: ffffa655314979e8 RFLAGS: 00000002 RAX: ffffffff89792500 RBX: ffffffff8af428a0 RCX: 0000000000000000 RDX: 00000000000003fd RSI: 0000000000000005 RDI: ffffffff8af428a0 RBP: 0000000000002710 R8: 0000000000000004 R9: 000000000000000f R10: 0000000000000000 R11: ffffffff8acbf64f R12: 0000000000000020 R13: ffffffff8acbf698 R14: 0000000000000058 R15: 0000000000000000 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #5 [ffffa655314979e8] io_serial_in at ffffffff89792594 #6 [ffffa655314979e8] wait_for_xmitr at ffffffff89793470 #7 [ffffa65531497a08] serial8250_console_putchar at ffffffff897934f6 #8 [ffffa65531497a20] uart_console_write at ffffffff8978b605 #9 [ffffa65531497a48] serial8250_console_write at ffffffff89796558 #10 [ffffa65531497ac8] console_unlock at ffffffff89316124 #11 [ffffa65531497b10] vprintk_emit at ffffffff89317c07 #12 [ffffa65531497b68] printk at ffffffff89318306 #13 [ffffa65531497bc8] print_hex_dump at ffffffff89650765 #14 [ffffa65531497ca8] tun_do_read at ffffffffc0b06c27 [tun] #15 [ffffa65531497d38] tun_recvmsg at ffffffffc0b06e34 [tun] #16 [ffffa65531497d68] handle_rx at ffffffffc0c5d682 [vhost_net] #17 [ffffa65531497ed0] vhost_worker at ffffffffc0c644dc [vhost] #18 [ffffa65531497f10] kthread at ffffffff892d2e72 #19 [ffffa65531497f50] ret_from_fork at ffffffff89c0022f(CVE-2024-27013)
In the Linux kernel, the following vulnerability has been resolved:
i40e: fix vf may be used uninitialized in this function warning
To fix the regression introduced by commit 52424f974bc5, which causes servers hang in very hard to reproduce conditions with resets races. Using two sources for the information is the root cause. In this function before the fix bumping v didn't mean bumping vf pointer. But the code used this variables interchangeably, so stale vf could point to different/not intended vf.
Remove redundant "v" variable and iterate via single VF pointer across whole function instead to guarantee VF pointer validity.(CVE-2024-36020)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: qca: add missing firmware sanity checks
Add the missing sanity checks when parsing the firmware files before downloading them to avoid accessing and corrupting memory beyond the vmalloced buffer.(CVE-2024-36880)
In the Linux kernel, the following vulnerability has been resolved:
net: hns3: fix kernel crash when devlink reload during initialization
The devlink reload process will access the hardware resources, but the register operation is done before the hardware is initialized. So, processing the devlink reload during initialization may lead to kernel crash.
This patch fixes this by registering the devlink after hardware initialization.(CVE-2024-36900)
In the Linux kernel, the following vulnerability has been resolved:
tcp: Use refcount_inc_not_zero() in tcp_twsk_unique().
Anderson Nascimento reported a use-after-free splat in tcp_twsk_unique() with nice analysis.
Since commit ec94c2696f0b ("tcp/dccp: avoid one atomic operation for timewait hashdance"), inet_twsk_hashdance() sets TIME-WAIT socket's sk_refcnt after putting it into ehash and releasing the bucket lock.
Thus, there is a small race window where other threads could try to reuse the port during connect() and call sock_hold() in tcp_twsk_unique() for the TIME-WAIT socket with zero refcnt.
If that happens, the refcnt taken by tcp_twsk_unique() is overwritten and sock_put() will cause underflow, triggering a real use-after-free somewhere else.
To avoid the use-after-free, we need to use refcount_inc_not_zero() in tcp_twsk_unique() and give up on reusing the port if it returns false.
[0]: refcount_t: addition on 0; use-after-free. WARNING: CPU: 0 PID: 1039313 at lib/refcount.c:25 refcount_warn_saturate+0xe5/0x110 CPU: 0 PID: 1039313 Comm: trigger Not tainted 6.8.6-200.fc39.x86_64 #1 Hardware name: VMware, Inc. VMware20,1/440BX Desktop Reference Platform, BIOS VMW201.00V.21805430.B64.2305221830 05/22/2023 RIP: 0010:refcount_warn_saturate+0xe5/0x110 Code: 42 8e ff 0f 0b c3 cc cc cc cc 80 3d aa 13 ea 01 00 0f 85 5e ff ff ff 48 c7 c7 f8 8e b7 82 c6 05 96 13 ea 01 01 e8 7b 42 8e ff <0f> 0b c3 cc cc cc cc 48 c7 c7 50 8f b7 82 c6 05 7a 13 ea 01 01 e8 RSP: 0018:ffffc90006b43b60 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff888009bb3ef0 RCX: 0000000000000027 RDX: ffff88807be218c8 RSI: 0000000000000001 RDI: ffff88807be218c0 RBP: 0000000000069d70 R08: 0000000000000000 R09: ffffc90006b439f0 R10: ffffc90006b439e8 R11: 0000000000000003 R12: ffff8880029ede84 R13: 0000000000004e20 R14: ffffffff84356dc0 R15: ffff888009bb3ef0 FS: 00007f62c10926c0(0000) GS:ffff88807be00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020ccb000 CR3: 000000004628c005 CR4: 0000000000f70ef0 PKRU: 55555554 Call Trace: <TASK> ? refcount_warn_saturate+0xe5/0x110 ? __warn+0x81/0x130 ? refcount_warn_saturate+0xe5/0x110 ? report_bug+0x171/0x1a0 ? refcount_warn_saturate+0xe5/0x110 ? handle_bug+0x3c/0x80 ? exc_invalid_op+0x17/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? refcount_warn_saturate+0xe5/0x110 tcp_twsk_unique+0x186/0x190 __inet_check_established+0x176/0x2d0 __inet_hash_connect+0x74/0x7d0 ? __pfx___inet_check_established+0x10/0x10 tcp_v4_connect+0x278/0x530 __inet_stream_connect+0x10f/0x3d0 inet_stream_connect+0x3a/0x60 __sys_connect+0xa8/0xd0 __x64_sys_connect+0x18/0x20 do_syscall_64+0x83/0x170 entry_SYSCALL_64_after_hwframe+0x78/0x80 RIP: 0033:0x7f62c11a885d Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 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 8b 0d a3 45 0c 00 f7 d8 64 89 01 48 RSP: 002b:00007f62c1091e58 EFLAGS: 00000296 ORIG_RAX: 000000000000002a RAX: ffffffffffffffda RBX: 0000000020ccb004 RCX: 00007f62c11a885d RDX: 0000000000000010 RSI: 0000000020ccb000 RDI: 0000000000000003 RBP: 00007f62c1091e90 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000296 R12: 00007f62c10926c0 R13: ffffffffffffff88 R14: 0000000000000000 R15: 00007ffe237885b0 </TASK>(CVE-2024-36904)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Skip on writeback when it's not applicable
[WHY] dynamic memory safety error detector (KASAN) catches and generates error messages "BUG: KASAN: slab-out-of-bounds" as writeback connector does not support certain features which are not initialized.
[HOW] Skip them when connector type is DRM_MODE_CONNECTOR_WRITEBACK.(CVE-2024-36914)
In the Linux kernel, the following vulnerability has been resolved:
nsh: Restore skb->{protocol,data,mac_header} for outer header in nsh_gso_segment().
syzbot triggered various splats (see [0] and links) by a crafted GSO packet of VIRTIO_NET_HDR_GSO_UDP layering the following protocols:
ETH_P_8021AD + ETH_P_NSH + ETH_P_IPV6 + IPPROTO_UDP
NSH can encapsulate IPv4, IPv6, Ethernet, NSH, and MPLS. As the inner protocol can be Ethernet, NSH GSO handler, nsh_gso_segment(), calls skb_mac_gso_segment() to invoke inner protocol GSO handlers.
nsh_gso_segment() does the following for the original skb before calling skb_mac_gso_segment()
- reset skb->network_header
- save the original skb->{mac_heaeder,mac_len} in a local variable
- pull the NSH header
- resets skb->mac_header
- set up skb->mac_len and skb->protocol for the inner protocol.
and does the following for the segmented skb
- set ntohs(ETH_P_NSH) to skb->protocol
- push the NSH header
- restore skb->mac_header
- set skb->mac_header + mac_len to skb->network_header
- restore skb->mac_len
There are two problems in 6-7 and 8-9.
(a) After 6 & 7, skb->data points to the NSH header, so the outer header (ETH_P_8021AD in this case) is stripped when skb is sent out of netdev.
Also, if NSH is encapsulated by NSH + Ethernet (so NSH-Ethernet-NSH), skb_pull() in the first nsh_gso_segment() will make skb->data point to the middle of the outer NSH or Ethernet header because the Ethernet header is not pulled by the second nsh_gso_segment().
(b) While restoring skb->{mac_header,network_header} in 8 & 9, nsh_gso_segment() does not assume that the data in the linear buffer is shifted.
However, udp6_ufo_fragment() could shift the data and change skb->mac_header accordingly as demonstrated by syzbot.
If this happens, even the restored skb->mac_header points to the middle of the outer header.
It seems nsh_gso_segment() has never worked with outer headers so far.
At the end of nsh_gso_segment(), the outer header must be restored for the segmented skb, instead of the NSH header.
To do that, let's calculate the outer header position relatively from the inner header and set skb->{data,mac_header,protocol} properly.
[0]: BUG: KMSAN: uninit-value in ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:524 [inline] BUG: KMSAN: uninit-value in ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline] BUG: KMSAN: uninit-value in ipvlan_queue_xmit+0xf44/0x16b0 drivers/net/ipvlan/ipvlan_core.c:668 ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:524 [inline] ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline] ipvlan_queue_xmit+0xf44/0x16b0 drivers/net/ipvlan/ipvlan_core.c:668 ipvlan_start_xmit+0x5c/0x1a0 drivers/net/ipvlan/ipvlan_main.c:222 __netdev_start_xmit include/linux/netdevice.h:4989 [inline] netdev_start_xmit include/linux/netdevice.h:5003 [inline] xmit_one net/core/dev.c:3547 [inline] dev_hard_start_xmit+0x244/0xa10 net/core/dev.c:3563 __dev_queue_xmit+0x33ed/0x51c0 net/core/dev.c:4351 dev_queue_xmit include/linux/netdevice.h:3171 [inline] packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3081 [inline] packet_sendmsg+0x8aef/0x9f10 net/packet/af_packet.c:3113 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x735/0xa10 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b
Uninit was created at: slab_post_alloc_hook mm/slub.c:3819 [inline] slab_alloc_node mm/slub.c:3860 [inline] __do_kmalloc_node mm/slub.c:3980 [inline] __kmalloc_node_track_caller+0x705/0x1000 mm/slub.c:4001 kmalloc_reserve+0x249/0x4a0 net/core/skbuff.c:582 __ ---truncated---(CVE-2024-36933)
In the Linux kernel, the following vulnerability has been resolved:
bpf, skmsg: Fix NULL pointer dereference in sk_psock_skb_ingress_enqueue
Fix NULL pointer data-races in sk_psock_skb_ingress_enqueue() which syzbot reported [1].
[1] BUG: KCSAN: data-race in sk_psock_drop / sk_psock_skb_ingress_enqueue
write to 0xffff88814b3278b8 of 8 bytes by task 10724 on cpu 1: sk_psock_stop_verdict net/core/skmsg.c:1257 [inline] sk_psock_drop+0x13e/0x1f0 net/core/skmsg.c:843 sk_psock_put include/linux/skmsg.h:459 [inline] sock_map_close+0x1a7/0x260 net/core/sock_map.c:1648 unix_release+0x4b/0x80 net/unix/af_unix.c:1048 __sock_release net/socket.c:659 [inline] sock_close+0x68/0x150 net/socket.c:1421 __fput+0x2c1/0x660 fs/file_table.c:422 __fput_sync+0x44/0x60 fs/file_table.c:507 __do_sys_close fs/open.c:1556 [inline] __se_sys_close+0x101/0x1b0 fs/open.c:1541 __x64_sys_close+0x1f/0x30 fs/open.c:1541 do_syscall_64+0xd3/0x1d0 entry_SYSCALL_64_after_hwframe+0x6d/0x75
read to 0xffff88814b3278b8 of 8 bytes by task 10713 on cpu 0: sk_psock_data_ready include/linux/skmsg.h:464 [inline] sk_psock_skb_ingress_enqueue+0x32d/0x390 net/core/skmsg.c:555 sk_psock_skb_ingress_self+0x185/0x1e0 net/core/skmsg.c:606 sk_psock_verdict_apply net/core/skmsg.c:1008 [inline] sk_psock_verdict_recv+0x3e4/0x4a0 net/core/skmsg.c:1202 unix_read_skb net/unix/af_unix.c:2546 [inline] unix_stream_read_skb+0x9e/0xf0 net/unix/af_unix.c:2682 sk_psock_verdict_data_ready+0x77/0x220 net/core/skmsg.c:1223 unix_stream_sendmsg+0x527/0x860 net/unix/af_unix.c:2339 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x140/0x180 net/socket.c:745 ____sys_sendmsg+0x312/0x410 net/socket.c:2584 ___sys_sendmsg net/socket.c:2638 [inline] __sys_sendmsg+0x1e9/0x280 net/socket.c:2667 __do_sys_sendmsg net/socket.c:2676 [inline] __se_sys_sendmsg net/socket.c:2674 [inline] __x64_sys_sendmsg+0x46/0x50 net/socket.c:2674 do_syscall_64+0xd3/0x1d0 entry_SYSCALL_64_after_hwframe+0x6d/0x75
value changed: 0xffffffff83d7feb0 -> 0x0000000000000000
Reported by Kernel Concurrency Sanitizer on: CPU: 0 PID: 10713 Comm: syz-executor.4 Tainted: G W 6.8.0-syzkaller-08951-gfe46a7dd189e #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024
Prior to this, commit 4cd12c6065df ("bpf, sockmap: Fix NULL pointer dereference in sk_psock_verdict_data_ready()") fixed one NULL pointer similarly due to no protection of saved_data_ready. Here is another different caller causing the same issue because of the same reason. So we should protect it with sk_callback_lock read lock because the writer side in the sk_psock_drop() uses "write_lock_bh(&sk->sk_callback_lock);".
To avoid errors that could happen in future, I move those two pairs of lock into the sk_psock_data_ready(), which is suggested by John Fastabend.(CVE-2024-36938)
In the Linux kernel, the following vulnerability has been resolved:
pinctrl: devicetree: fix refcount leak in pinctrl_dt_to_map()
If we fail to allocate propname buffer, we need to drop the reference count we just took. Because the pinctrl_dt_free_maps() includes the droping operation, here we call it directly.(CVE-2024-36959)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/rxe: Fix seg fault in rxe_comp_queue_pkt
In rxe_comp_queue_pkt() an incoming response packet skb is enqueued to the resp_pkts queue and then a decision is made whether to run the completer task inline or schedule it. Finally the skb is dereferenced to bump a 'hw' performance counter. This is wrong because if the completer task is already running in a separate thread it may have already processed the skb and freed it which can cause a seg fault. This has been observed infrequently in testing at high scale.
This patch fixes this by changing the order of enqueuing the packet until after the counter is accessed.(CVE-2024-38544)
In the Linux kernel, the following vulnerability has been resolved:
wifi: ar5523: enable proper endpoint verification
Syzkaller reports [1] hitting a warning about an endpoint in use not having an expected type to it.
Fix the issue by checking for the existence of all proper endpoints with their according types intact.
Sadly, this patch has not been tested on real hardware.
[1] Syzkaller report: ------------[ cut here ]------------ usb 1-1: BOGUS urb xfer, pipe 3 != type 1 WARNING: CPU: 0 PID: 3643 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504 ... Call Trace: <TASK> ar5523_cmd+0x41b/0x780 drivers/net/wireless/ath/ar5523/ar5523.c:275 ar5523_cmd_read drivers/net/wireless/ath/ar5523/ar5523.c:302 [inline] ar5523_host_available drivers/net/wireless/ath/ar5523/ar5523.c:1376 [inline] ar5523_probe+0x14b0/0x1d10 drivers/net/wireless/ath/ar5523/ar5523.c:1655 usb_probe_interface+0x30f/0x7f0 drivers/usb/core/driver.c:396 call_driver_probe drivers/base/dd.c:560 [inline] really_probe+0x249/0xb90 drivers/base/dd.c:639 __driver_probe_device+0x1df/0x4d0 drivers/base/dd.c:778 driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:808 __device_attach_driver+0x1d4/0x2e0 drivers/base/dd.c:936 bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:427 __device_attach+0x1e4/0x530 drivers/base/dd.c:1008 bus_probe_device+0x1e8/0x2a0 drivers/base/bus.c:487 device_add+0xbd9/0x1e90 drivers/base/core.c:3517 usb_set_configuration+0x101d/0x1900 drivers/usb/core/message.c:2170 usb_generic_driver_probe+0xbe/0x100 drivers/usb/core/generic.c:238 usb_probe_device+0xd8/0x2c0 drivers/usb/core/driver.c:293 call_driver_probe drivers/base/dd.c:560 [inline] really_probe+0x249/0xb90 drivers/base/dd.c:639 __driver_probe_device+0x1df/0x4d0 drivers/base/dd.c:778 driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:808 __device_attach_driver+0x1d4/0x2e0 drivers/base/dd.c:936 bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:427 __device_attach+0x1e4/0x530 drivers/base/dd.c:1008 bus_probe_device+0x1e8/0x2a0 drivers/base/bus.c:487 device_add+0xbd9/0x1e90 drivers/base/core.c:3517 usb_new_device.cold+0x685/0x10ad drivers/usb/core/hub.c:2573 hub_port_connect drivers/usb/core/hub.c:5353 [inline] hub_port_connect_change drivers/usb/core/hub.c:5497 [inline] port_event drivers/usb/core/hub.c:5653 [inline] hub_event+0x26cb/0x45d0 drivers/usb/core/hub.c:5735 process_one_work+0x9bf/0x1710 kernel/workqueue.c:2289 worker_thread+0x669/0x1090 kernel/workqueue.c:2436 kthread+0x2e8/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306 </TASK>(CVE-2024-38565)
In the Linux kernel, the following vulnerability has been resolved:
eth: sungem: remove .ndo_poll_controller to avoid deadlocks
Erhard reports netpoll warnings from sungem:
netpoll_send_skb_on_dev(): eth0 enabled interrupts in poll (gem_start_xmit+0x0/0x398) WARNING: CPU: 1 PID: 1 at net/core/netpoll.c:370 netpoll_send_skb+0x1fc/0x20c
gem_poll_controller() disables interrupts, which may sleep. We can't sleep in netpoll, it has interrupts disabled completely. Strangely, gem_poll_controller() doesn't even poll the completions, and instead acts as if an interrupt has fired so it just schedules NAPI and exits. None of this has been necessary for years, since netpoll invokes NAPI directly.(CVE-2024-38597)
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix mb_cache_entry's e_refcnt leak in ext4_xattr_block_cache_find()
Syzbot reports a warning as follows:
============================================ WARNING: CPU: 0 PID: 5075 at fs/mbcache.c:419 mb_cache_destroy+0x224/0x290 Modules linked in: CPU: 0 PID: 5075 Comm: syz-executor199 Not tainted 6.9.0-rc6-gb947cc5bf6d7 RIP: 0010:mb_cache_destroy+0x224/0x290 fs/mbcache.c:419 Call Trace: <TASK> ext4_put_super+0x6d4/0xcd0 fs/ext4/super.c:1375 generic_shutdown_super+0x136/0x2d0 fs/super.c:641 kill_block_super+0x44/0x90 fs/super.c:1675 ext4_kill_sb+0x68/0xa0 fs/ext4/super.c:7327 [...] ============================================
This is because when finding an entry in ext4_xattr_block_cache_find(), if ext4_sb_bread() returns -ENOMEM, the ce's e_refcnt, which has already grown in the __entry_find(), won't be put away, and eventually trigger the above issue in mb_cache_destroy() due to reference count leakage.
So call mb_cache_entry_put() on the -ENOMEM error branch as a quick fix.(CVE-2024-39276)
In the Linux kernel, the following vulnerability has been resolved:
jfs: xattr: fix buffer overflow for invalid xattr
When an xattr size is not what is expected, it is printed out to the kernel log in hex format as a form of debugging. But when that xattr size is bigger than the expected size, printing it out can cause an access off the end of the buffer.
Fix this all up by properly restricting the size of the debug hex dump in the kernel log.(CVE-2024-40902)
In the Linux kernel, the following vulnerability has been resolved:
tty: add the option to have a tty reject a new ldisc
... and use it to limit the virtual terminals to just N_TTY. They are kind of special, and in particular, the "con_write()" routine violates the "writes cannot sleep" rule that some ldiscs rely on.
This avoids the
BUG: sleeping function called from invalid context at kernel/printk/printk.c:2659
when N_GSM has been attached to a virtual console, and gsmld_write() calls con_write() while holding a spinlock, and con_write() then tries to get the console lock.(CVE-2024-40966)
In the Linux kernel, the following vulnerability has been resolved:
can: mcp251xfd: fix infinite loop when xmit fails
When the mcp251xfd_start_xmit() function fails, the driver stops processing messages, and the interrupt routine does not return, running indefinitely even after killing the running application.
Error messages: [ 441.298819] mcp251xfd spi2.0 can0: ERROR in mcp251xfd_start_xmit: -16 [ 441.306498] mcp251xfd spi2.0 can0: Transmit Event FIFO buffer not empty. (seq=0x000017c7, tef_tail=0x000017cf, tef_head=0x000017d0, tx_head=0x000017d3). ... and repeat forever.
The issue can be triggered when multiple devices share the same SPI interface. And there is concurrent access to the bus.
The problem occurs because tx_ring->head increments even if mcp251xfd_start_xmit() fails. Consequently, the driver skips one TX package while still expecting a response in mcp251xfd_handle_tefif_one().
Resolve the issue by starting a workqueue to write the tx obj synchronously if err = -EBUSY. In case of another error, decrement tx_ring->head, remove skb from the echo stack, and drop the message.
mkl: use more imperative wording in patch description
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: fully validate NFT_DATA_VALUE on store to data registers
register store validation for NFT_DATA_VALUE is conditional, however, the datatype is always either NFT_DATA_VALUE or NFT_DATA_VERDICT. This only requires a new helper function to infer the register type from the set datatype so this conditional check can be removed. Otherwise, pointer to chain object can be leaked through the registers.(CVE-2024-42070)
In the Linux kernel, the following vulnerability has been resolved:
drm/lima: fix shared irq handling on driver remove
lima uses a shared interrupt, so the interrupt handlers must be prepared to be called at any time. At driver removal time, the clocks are disabled early and the interrupts stay registered until the very end of the remove process due to the devm usage. This is potentially a bug as the interrupts access device registers which assumes clocks are enabled. A crash can be triggered by removing the driver in a kernel with CONFIG_DEBUG_SHIRQ enabled. This patch frees the interrupts at each lima device finishing callback so that the handlers are already unregistered by the time we fully disable clocks.(CVE-2024-42127)
In the Linux kernel, the following vulnerability has been resolved:
mm: avoid overflows in dirty throttling logic
The dirty throttling logic is interspersed with assumptions that dirty limits in PAGE_SIZE units fit into 32-bit (so that various multiplications fit into 64-bits). If limits end up being larger, we will hit overflows, possible divisions by 0 etc. Fix these problems by never allowing so large dirty limits as they have dubious practical value anyway. For dirty_bytes / dirty_background_bytes interfaces we can just refuse to set so large limits. For dirty_ratio / dirty_background_ratio it isn't so simple as the dirty limit is computed from the amount of available memory which can change due to memory hotplug etc. So when converting dirty limits from ratios to numbers of pages, we just don't allow the result to exceed UINT_MAX.
This is root-only triggerable problem which occurs when the operator sets dirty limits to >16 TB.(CVE-2024-42131)
In the Linux kernel, the following vulnerability has been resolved:
libceph: fix race between delayed_work() and ceph_monc_stop()
The way the delayed work is handled in ceph_monc_stop() is prone to races with mon_fault() and possibly also finish_hunting(). Both of these can requeue the delayed work which wouldn't be canceled by any of the following code in case that happens after cancel_delayed_work_sync() runs -- __close_session() doesn't mess with the delayed work in order to avoid interfering with the hunting interval logic. This part was missed in commit b5d91704f53e ("libceph: behave in mon_fault() if cur_mon < 0") and use-after-free can still ensue on monc and objects that hang off of it, with monc->auth and monc->monmap being particularly susceptible to quickly being reused.
To fix this:
- clear monc->cur_mon and monc->hunting as part of closing the session in ceph_monc_stop()
- bail from delayed_work() if monc->cur_mon is cleared, similar to how it's done in mon_fault() and finish_hunting() (based on monc->hunting)
- call cancel_delayed_work_sync() after the session is closed(CVE-2024-42232)
In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: configfs: Prevent OOB read/write in usb_string_copy()
Userspace provided string 's' could trivially have the length zero. Left
unchecked this will firstly result in an OOB read in the form
if (str[0 - 1] == '\n') followed closely by an OOB write in the formstr[0 - 1] = '\0'`.
There is already a validating check to catch strings that are too long. Let's supply an additional check for invalid strings that are too short.(CVE-2024-42236)
In the Linux kernel, the following vulnerability has been resolved:
ext4: make sure the first directory block is not a hole
The syzbot constructs a directory that has no dirblock but is non-inline, i.e. the first directory block is a hole. And no errors are reported when creating files in this directory in the following flow.
ext4_mknod
...
ext4_add_entry
// Read block 0
ext4_read_dirblock(dir, block, DIRENT)
bh = ext4_bread(NULL, inode, block, 0)
if (!bh && (type == INDEX || type == DIRENT_HTREE))
// The first directory block is a hole
// But type == DIRENT, so no error is reported.
After that, we get a directory block without '.' and '..' but with a valid dentry. This may cause some code that relies on dot or dotdot (such as make_indexed_dir()) to crash.
Therefore when ext4_read_dirblock() finds that the first directory block is a hole report that the filesystem is corrupted and return an error to avoid loading corrupted data from disk causing something bad.(CVE-2024-42304)
In the Linux kernel, the following vulnerability has been resolved:
drm/gma500: fix null pointer dereference in cdv_intel_lvds_get_modes
In cdv_intel_lvds_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-2024-42310)
In the Linux kernel, the following vulnerability has been resolved:
bna: adjust 'name' buf size of bna_tcb and bna_ccb structures
To have enough space to write all possible sprintf() args. Currently 'name' size is 16, but the first '%s' specifier may already need at least 16 characters, since 'bnad->netdev->name' is used there.
For '%d' specifiers, assume that they require: * 1 char for 'tx_id + tx_info->tcb[i]->id' sum, BNAD_MAX_TXQ_PER_TX is 8 * 2 chars for 'rx_id + rx_info->rx_ctrl[i].ccb->id', BNAD_MAX_RXP_PER_RX is 16
And replace sprintf with snprintf.
Detected using the static analysis tool - Svace.(CVE-2024-43839)
| URL | Type | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"kernel-5.10.0-224.0.0.127.oe2203sp3.aarch64.rpm",
"kernel-debuginfo-5.10.0-224.0.0.127.oe2203sp3.aarch64.rpm",
"kernel-debugsource-5.10.0-224.0.0.127.oe2203sp3.aarch64.rpm",
"kernel-devel-5.10.0-224.0.0.127.oe2203sp3.aarch64.rpm",
"kernel-headers-5.10.0-224.0.0.127.oe2203sp3.aarch64.rpm",
"kernel-source-5.10.0-224.0.0.127.oe2203sp3.aarch64.rpm",
"kernel-tools-5.10.0-224.0.0.127.oe2203sp3.aarch64.rpm",
"kernel-tools-debuginfo-5.10.0-224.0.0.127.oe2203sp3.aarch64.rpm",
"kernel-tools-devel-5.10.0-224.0.0.127.oe2203sp3.aarch64.rpm",
"perf-5.10.0-224.0.0.127.oe2203sp3.aarch64.rpm",
"perf-debuginfo-5.10.0-224.0.0.127.oe2203sp3.aarch64.rpm",
"python3-perf-5.10.0-224.0.0.127.oe2203sp3.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-224.0.0.127.oe2203sp3.aarch64.rpm"
],
"src": [
"kernel-5.10.0-224.0.0.127.oe2203sp3.src.rpm"
],
"x86_64": [
"kernel-5.10.0-224.0.0.127.oe2203sp3.x86_64.rpm",
"kernel-debuginfo-5.10.0-224.0.0.127.oe2203sp3.x86_64.rpm",
"kernel-debugsource-5.10.0-224.0.0.127.oe2203sp3.x86_64.rpm",
"kernel-devel-5.10.0-224.0.0.127.oe2203sp3.x86_64.rpm",
"kernel-headers-5.10.0-224.0.0.127.oe2203sp3.x86_64.rpm",
"kernel-source-5.10.0-224.0.0.127.oe2203sp3.x86_64.rpm",
"kernel-tools-5.10.0-224.0.0.127.oe2203sp3.x86_64.rpm",
"kernel-tools-debuginfo-5.10.0-224.0.0.127.oe2203sp3.x86_64.rpm",
"kernel-tools-devel-5.10.0-224.0.0.127.oe2203sp3.x86_64.rpm",
"perf-5.10.0-224.0.0.127.oe2203sp3.x86_64.rpm",
"perf-debuginfo-5.10.0-224.0.0.127.oe2203sp3.x86_64.rpm",
"python3-perf-5.10.0-224.0.0.127.oe2203sp3.x86_64.rpm",
"python3-perf-debuginfo-5.10.0-224.0.0.127.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-224.0.0.127.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\nmlxsw: spectrum_acl_tcam: Fix stack corruption\r\n\r\nWhen tc filters are first added to a net device, the corresponding local\nport gets bound to an ACL group in the device. The group contains a list\nof ACLs. In turn, each ACL points to a different TCAM region where the\nfilters are stored. During forwarding, the ACLs are sequentially\nevaluated until a match is found.\r\n\r\nOne reason to place filters in different regions is when they are added\nwith decreasing priorities and in an alternating order so that two\nconsecutive filters can never fit in the same region because of their\nkey usage.\r\n\r\nIn Spectrum-2 and newer ASICs the firmware started to report that the\nmaximum number of ACLs in a group is more than 16, but the layout of the\nregister that configures ACL groups (PAGT) was not updated to account\nfor that. It is therefore possible to hit stack corruption [1] in the\nrare case where more than 16 ACLs in a group are required.\r\n\r\nFix by limiting the maximum ACL group size to the minimum between what\nthe firmware reports and the maximum ACLs that fit in the PAGT register.\r\n\r\nAdd a test case to make sure the machine does not crash when this\ncondition is hit.\r\n\r\n[1]\nKernel panic - not syncing: stack-protector: Kernel stack is corrupted in: mlxsw_sp_acl_tcam_group_update+0x116/0x120\n[...]\n dump_stack_lvl+0x36/0x50\n panic+0x305/0x330\n __stack_chk_fail+0x15/0x20\n mlxsw_sp_acl_tcam_group_update+0x116/0x120\n mlxsw_sp_acl_tcam_group_region_attach+0x69/0x110\n mlxsw_sp_acl_tcam_vchunk_get+0x492/0xa20\n mlxsw_sp_acl_tcam_ventry_add+0x25/0xe0\n mlxsw_sp_acl_rule_add+0x47/0x240\n mlxsw_sp_flower_replace+0x1a9/0x1d0\n tc_setup_cb_add+0xdc/0x1c0\n fl_hw_replace_filter+0x146/0x1f0\n fl_change+0xc17/0x1360\n tc_new_tfilter+0x472/0xb90\n rtnetlink_rcv_msg+0x313/0x3b0\n netlink_rcv_skb+0x58/0x100\n netlink_unicast+0x244/0x390\n netlink_sendmsg+0x1e4/0x440\n ____sys_sendmsg+0x164/0x260\n ___sys_sendmsg+0x9a/0xe0\n __sys_sendmsg+0x7a/0xc0\n do_syscall_64+0x40/0xe0\n entry_SYSCALL_64_after_hwframe+0x63/0x6b(CVE-2024-26586)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nKVM: arm64: vgic-its: Avoid potential UAF in LPI translation cache\r\n\r\nThere is a potential UAF scenario in the case of an LPI translation\ncache hit racing with an operation that invalidates the cache, such\nas a DISCARD ITS command. The root of the problem is that\nvgic_its_check_cache() does not elevate the refcount on the vgic_irq\nbefore dropping the lock that serializes refcount changes.\r\n\r\nHave vgic_its_check_cache() raise the refcount on the returned vgic_irq\nand add the corresponding decrement after queueing the interrupt.(CVE-2024-26598)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsched/membarrier: reduce the ability to hammer on sys_membarrier\r\n\r\nOn some systems, sys_membarrier can be very expensive, causing overall\nslowdowns for everything. So put a lock on the path in order to\nserialize the accesses to prevent the ability for this to be called at\ntoo high of a frequency and saturate the machine.(CVE-2024-26602)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntun: limit printing rate when illegal packet received by tun dev\r\n\r\nvhost_worker will call tun call backs to receive packets. If too many\nillegal packets arrives, tun_do_read will keep dumping packet contents.\nWhen console is enabled, it will costs much more cpu time to dump\npacket and soft lockup will be detected.\r\n\r\nnet_ratelimit mechanism can be used to limit the dumping rate.\r\n\r\nPID: 33036 TASK: ffff949da6f20000 CPU: 23 COMMAND: \u0026quot;vhost-32980\u0026quot;\n #0 [fffffe00003fce50] crash_nmi_callback at ffffffff89249253\n #1 [fffffe00003fce58] nmi_handle at ffffffff89225fa3\n #2 [fffffe00003fceb0] default_do_nmi at ffffffff8922642e\n #3 [fffffe00003fced0] do_nmi at ffffffff8922660d\n #4 [fffffe00003fcef0] end_repeat_nmi at ffffffff89c01663\n [exception RIP: io_serial_in+20]\n RIP: ffffffff89792594 RSP: ffffa655314979e8 RFLAGS: 00000002\n RAX: ffffffff89792500 RBX: ffffffff8af428a0 RCX: 0000000000000000\n RDX: 00000000000003fd RSI: 0000000000000005 RDI: ffffffff8af428a0\n RBP: 0000000000002710 R8: 0000000000000004 R9: 000000000000000f\n R10: 0000000000000000 R11: ffffffff8acbf64f R12: 0000000000000020\n R13: ffffffff8acbf698 R14: 0000000000000058 R15: 0000000000000000\n ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018\n #5 [ffffa655314979e8] io_serial_in at ffffffff89792594\n #6 [ffffa655314979e8] wait_for_xmitr at ffffffff89793470\n #7 [ffffa65531497a08] serial8250_console_putchar at ffffffff897934f6\n #8 [ffffa65531497a20] uart_console_write at ffffffff8978b605\n #9 [ffffa65531497a48] serial8250_console_write at ffffffff89796558\n #10 [ffffa65531497ac8] console_unlock at ffffffff89316124\n #11 [ffffa65531497b10] vprintk_emit at ffffffff89317c07\n #12 [ffffa65531497b68] printk at ffffffff89318306\n #13 [ffffa65531497bc8] print_hex_dump at ffffffff89650765\n #14 [ffffa65531497ca8] tun_do_read at ffffffffc0b06c27 [tun]\n #15 [ffffa65531497d38] tun_recvmsg at ffffffffc0b06e34 [tun]\n #16 [ffffa65531497d68] handle_rx at ffffffffc0c5d682 [vhost_net]\n #17 [ffffa65531497ed0] vhost_worker at ffffffffc0c644dc [vhost]\n #18 [ffffa65531497f10] kthread at ffffffff892d2e72\n #19 [ffffa65531497f50] ret_from_fork at ffffffff89c0022f(CVE-2024-27013)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ni40e: fix vf may be used uninitialized in this function warning\r\n\r\nTo fix the regression introduced by commit 52424f974bc5, which causes\nservers hang in very hard to reproduce conditions with resets races.\nUsing two sources for the information is the root cause.\nIn this function before the fix bumping v didn\u0026apos;t mean bumping vf\npointer. But the code used this variables interchangeably, so stale vf\ncould point to different/not intended vf.\r\n\r\nRemove redundant \u0026quot;v\u0026quot; variable and iterate via single VF pointer across\nwhole function instead to guarantee VF pointer validity.(CVE-2024-36020)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nBluetooth: qca: add missing firmware sanity checks\r\n\r\nAdd the missing sanity checks when parsing the firmware files before\ndownloading them to avoid accessing and corrupting memory beyond the\nvmalloced buffer.(CVE-2024-36880)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: hns3: fix kernel crash when devlink reload during initialization\r\n\r\nThe devlink reload process will access the hardware resources,\nbut the register operation is done before the hardware is initialized.\nSo, processing the devlink reload during initialization may lead to kernel\ncrash.\r\n\r\nThis patch fixes this by registering the devlink after\nhardware initialization.(CVE-2024-36900)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntcp: Use refcount_inc_not_zero() in tcp_twsk_unique().\r\n\r\nAnderson Nascimento reported a use-after-free splat in tcp_twsk_unique()\nwith nice analysis.\r\n\r\nSince commit ec94c2696f0b (\u0026quot;tcp/dccp: avoid one atomic operation for\ntimewait hashdance\u0026quot;), inet_twsk_hashdance() sets TIME-WAIT socket\u0026apos;s\nsk_refcnt after putting it into ehash and releasing the bucket lock.\r\n\r\nThus, there is a small race window where other threads could try to\nreuse the port during connect() and call sock_hold() in tcp_twsk_unique()\nfor the TIME-WAIT socket with zero refcnt.\r\n\r\nIf that happens, the refcnt taken by tcp_twsk_unique() is overwritten\nand sock_put() will cause underflow, triggering a real use-after-free\nsomewhere else.\r\n\r\nTo avoid the use-after-free, we need to use refcount_inc_not_zero() in\ntcp_twsk_unique() and give up on reusing the port if it returns false.\r\n\r\n[0]:\nrefcount_t: addition on 0; use-after-free.\nWARNING: CPU: 0 PID: 1039313 at lib/refcount.c:25 refcount_warn_saturate+0xe5/0x110\nCPU: 0 PID: 1039313 Comm: trigger Not tainted 6.8.6-200.fc39.x86_64 #1\nHardware name: VMware, Inc. VMware20,1/440BX Desktop Reference Platform, BIOS VMW201.00V.21805430.B64.2305221830 05/22/2023\nRIP: 0010:refcount_warn_saturate+0xe5/0x110\nCode: 42 8e ff 0f 0b c3 cc cc cc cc 80 3d aa 13 ea 01 00 0f 85 5e ff ff ff 48 c7 c7 f8 8e b7 82 c6 05 96 13 ea 01 01 e8 7b 42 8e ff \u0026lt;0f\u0026gt; 0b c3 cc cc cc cc 48 c7 c7 50 8f b7 82 c6 05 7a 13 ea 01 01 e8\nRSP: 0018:ffffc90006b43b60 EFLAGS: 00010282\nRAX: 0000000000000000 RBX: ffff888009bb3ef0 RCX: 0000000000000027\nRDX: ffff88807be218c8 RSI: 0000000000000001 RDI: ffff88807be218c0\nRBP: 0000000000069d70 R08: 0000000000000000 R09: ffffc90006b439f0\nR10: ffffc90006b439e8 R11: 0000000000000003 R12: ffff8880029ede84\nR13: 0000000000004e20 R14: ffffffff84356dc0 R15: ffff888009bb3ef0\nFS: 00007f62c10926c0(0000) GS:ffff88807be00000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000020ccb000 CR3: 000000004628c005 CR4: 0000000000f70ef0\nPKRU: 55555554\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? refcount_warn_saturate+0xe5/0x110\n ? __warn+0x81/0x130\n ? refcount_warn_saturate+0xe5/0x110\n ? report_bug+0x171/0x1a0\n ? refcount_warn_saturate+0xe5/0x110\n ? handle_bug+0x3c/0x80\n ? exc_invalid_op+0x17/0x70\n ? asm_exc_invalid_op+0x1a/0x20\n ? refcount_warn_saturate+0xe5/0x110\n tcp_twsk_unique+0x186/0x190\n __inet_check_established+0x176/0x2d0\n __inet_hash_connect+0x74/0x7d0\n ? __pfx___inet_check_established+0x10/0x10\n tcp_v4_connect+0x278/0x530\n __inet_stream_connect+0x10f/0x3d0\n inet_stream_connect+0x3a/0x60\n __sys_connect+0xa8/0xd0\n __x64_sys_connect+0x18/0x20\n do_syscall_64+0x83/0x170\n entry_SYSCALL_64_after_hwframe+0x78/0x80\nRIP: 0033:0x7f62c11a885d\nCode: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 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 8b 0d a3 45 0c 00 f7 d8 64 89 01 48\nRSP: 002b:00007f62c1091e58 EFLAGS: 00000296 ORIG_RAX: 000000000000002a\nRAX: ffffffffffffffda RBX: 0000000020ccb004 RCX: 00007f62c11a885d\nRDX: 0000000000000010 RSI: 0000000020ccb000 RDI: 0000000000000003\nRBP: 00007f62c1091e90 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000296 R12: 00007f62c10926c0\nR13: ffffffffffffff88 R14: 0000000000000000 R15: 00007ffe237885b0\n \u0026lt;/TASK\u0026gt;(CVE-2024-36904)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Skip on writeback when it\u0026apos;s not applicable\r\n\r\n[WHY]\ndynamic memory safety error detector (KASAN) catches and generates error\nmessages \u0026quot;BUG: KASAN: slab-out-of-bounds\u0026quot; as writeback connector does not\nsupport certain features which are not initialized.\r\n\r\n[HOW]\nSkip them when connector type is DRM_MODE_CONNECTOR_WRITEBACK.(CVE-2024-36914)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnsh: Restore skb-\u0026gt;{protocol,data,mac_header} for outer header in nsh_gso_segment().\r\n\r\nsyzbot triggered various splats (see [0] and links) by a crafted GSO\npacket of VIRTIO_NET_HDR_GSO_UDP layering the following protocols:\r\n\r\n ETH_P_8021AD + ETH_P_NSH + ETH_P_IPV6 + IPPROTO_UDP\r\n\r\nNSH can encapsulate IPv4, IPv6, Ethernet, NSH, and MPLS. As the inner\nprotocol can be Ethernet, NSH GSO handler, nsh_gso_segment(), calls\nskb_mac_gso_segment() to invoke inner protocol GSO handlers.\r\n\r\nnsh_gso_segment() does the following for the original skb before\ncalling skb_mac_gso_segment()\r\n\r\n 1. reset skb-\u0026gt;network_header\n 2. save the original skb-\u0026gt;{mac_heaeder,mac_len} in a local variable\n 3. pull the NSH header\n 4. resets skb-\u0026gt;mac_header\n 5. set up skb-\u0026gt;mac_len and skb-\u0026gt;protocol for the inner protocol.\r\n\r\nand does the following for the segmented skb\r\n\r\n 6. set ntohs(ETH_P_NSH) to skb-\u0026gt;protocol\n 7. push the NSH header\n 8. restore skb-\u0026gt;mac_header\n 9. set skb-\u0026gt;mac_header + mac_len to skb-\u0026gt;network_header\n 10. restore skb-\u0026gt;mac_len\r\n\r\nThere are two problems in 6-7 and 8-9.\r\n\r\n (a)\n After 6 \u0026amp; 7, skb-\u0026gt;data points to the NSH header, so the outer header\n (ETH_P_8021AD in this case) is stripped when skb is sent out of netdev.\r\n\r\n Also, if NSH is encapsulated by NSH + Ethernet (so NSH-Ethernet-NSH),\n skb_pull() in the first nsh_gso_segment() will make skb-\u0026gt;data point\n to the middle of the outer NSH or Ethernet header because the Ethernet\n header is not pulled by the second nsh_gso_segment().\r\n\r\n (b)\n While restoring skb-\u0026gt;{mac_header,network_header} in 8 \u0026amp; 9,\n nsh_gso_segment() does not assume that the data in the linear\n buffer is shifted.\r\n\r\n However, udp6_ufo_fragment() could shift the data and change\n skb-\u0026gt;mac_header accordingly as demonstrated by syzbot.\r\n\r\n If this happens, even the restored skb-\u0026gt;mac_header points to\n the middle of the outer header.\r\n\r\nIt seems nsh_gso_segment() has never worked with outer headers so far.\r\n\r\nAt the end of nsh_gso_segment(), the outer header must be restored for\nthe segmented skb, instead of the NSH header.\r\n\r\nTo do that, let\u0026apos;s calculate the outer header position relatively from\nthe inner header and set skb-\u0026gt;{data,mac_header,protocol} properly.\r\n\r\n[0]:\nBUG: KMSAN: uninit-value in ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:524 [inline]\nBUG: KMSAN: uninit-value in ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline]\nBUG: KMSAN: uninit-value in ipvlan_queue_xmit+0xf44/0x16b0 drivers/net/ipvlan/ipvlan_core.c:668\n ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:524 [inline]\n ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline]\n ipvlan_queue_xmit+0xf44/0x16b0 drivers/net/ipvlan/ipvlan_core.c:668\n ipvlan_start_xmit+0x5c/0x1a0 drivers/net/ipvlan/ipvlan_main.c:222\n __netdev_start_xmit include/linux/netdevice.h:4989 [inline]\n netdev_start_xmit include/linux/netdevice.h:5003 [inline]\n xmit_one net/core/dev.c:3547 [inline]\n dev_hard_start_xmit+0x244/0xa10 net/core/dev.c:3563\n __dev_queue_xmit+0x33ed/0x51c0 net/core/dev.c:4351\n dev_queue_xmit include/linux/netdevice.h:3171 [inline]\n packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276\n packet_snd net/packet/af_packet.c:3081 [inline]\n packet_sendmsg+0x8aef/0x9f10 net/packet/af_packet.c:3113\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg net/socket.c:745 [inline]\n __sys_sendto+0x735/0xa10 net/socket.c:2191\n __do_sys_sendto net/socket.c:2203 [inline]\n __se_sys_sendto net/socket.c:2199 [inline]\n __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x63/0x6b\r\n\r\nUninit was created at:\n slab_post_alloc_hook mm/slub.c:3819 [inline]\n slab_alloc_node mm/slub.c:3860 [inline]\n __do_kmalloc_node mm/slub.c:3980 [inline]\n __kmalloc_node_track_caller+0x705/0x1000 mm/slub.c:4001\n kmalloc_reserve+0x249/0x4a0 net/core/skbuff.c:582\n __\n---truncated---(CVE-2024-36933)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbpf, skmsg: Fix NULL pointer dereference in sk_psock_skb_ingress_enqueue\r\n\r\nFix NULL pointer data-races in sk_psock_skb_ingress_enqueue() which\nsyzbot reported [1].\r\n\r\n[1]\nBUG: KCSAN: data-race in sk_psock_drop / sk_psock_skb_ingress_enqueue\r\n\r\nwrite to 0xffff88814b3278b8 of 8 bytes by task 10724 on cpu 1:\n sk_psock_stop_verdict net/core/skmsg.c:1257 [inline]\n sk_psock_drop+0x13e/0x1f0 net/core/skmsg.c:843\n sk_psock_put include/linux/skmsg.h:459 [inline]\n sock_map_close+0x1a7/0x260 net/core/sock_map.c:1648\n unix_release+0x4b/0x80 net/unix/af_unix.c:1048\n __sock_release net/socket.c:659 [inline]\n sock_close+0x68/0x150 net/socket.c:1421\n __fput+0x2c1/0x660 fs/file_table.c:422\n __fput_sync+0x44/0x60 fs/file_table.c:507\n __do_sys_close fs/open.c:1556 [inline]\n __se_sys_close+0x101/0x1b0 fs/open.c:1541\n __x64_sys_close+0x1f/0x30 fs/open.c:1541\n do_syscall_64+0xd3/0x1d0\n entry_SYSCALL_64_after_hwframe+0x6d/0x75\r\n\r\nread to 0xffff88814b3278b8 of 8 bytes by task 10713 on cpu 0:\n sk_psock_data_ready include/linux/skmsg.h:464 [inline]\n sk_psock_skb_ingress_enqueue+0x32d/0x390 net/core/skmsg.c:555\n sk_psock_skb_ingress_self+0x185/0x1e0 net/core/skmsg.c:606\n sk_psock_verdict_apply net/core/skmsg.c:1008 [inline]\n sk_psock_verdict_recv+0x3e4/0x4a0 net/core/skmsg.c:1202\n unix_read_skb net/unix/af_unix.c:2546 [inline]\n unix_stream_read_skb+0x9e/0xf0 net/unix/af_unix.c:2682\n sk_psock_verdict_data_ready+0x77/0x220 net/core/skmsg.c:1223\n unix_stream_sendmsg+0x527/0x860 net/unix/af_unix.c:2339\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg+0x140/0x180 net/socket.c:745\n ____sys_sendmsg+0x312/0x410 net/socket.c:2584\n ___sys_sendmsg net/socket.c:2638 [inline]\n __sys_sendmsg+0x1e9/0x280 net/socket.c:2667\n __do_sys_sendmsg net/socket.c:2676 [inline]\n __se_sys_sendmsg net/socket.c:2674 [inline]\n __x64_sys_sendmsg+0x46/0x50 net/socket.c:2674\n do_syscall_64+0xd3/0x1d0\n entry_SYSCALL_64_after_hwframe+0x6d/0x75\r\n\r\nvalue changed: 0xffffffff83d7feb0 -\u0026gt; 0x0000000000000000\r\n\r\nReported by Kernel Concurrency Sanitizer on:\nCPU: 0 PID: 10713 Comm: syz-executor.4 Tainted: G W 6.8.0-syzkaller-08951-gfe46a7dd189e #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024\r\n\r\nPrior to this, commit 4cd12c6065df (\u0026quot;bpf, sockmap: Fix NULL pointer\ndereference in sk_psock_verdict_data_ready()\u0026quot;) fixed one NULL pointer\nsimilarly due to no protection of saved_data_ready. Here is another\ndifferent caller causing the same issue because of the same reason. So\nwe should protect it with sk_callback_lock read lock because the writer\nside in the sk_psock_drop() uses \u0026quot;write_lock_bh(\u0026amp;sk-\u0026gt;sk_callback_lock);\u0026quot;.\r\n\r\nTo avoid errors that could happen in future, I move those two pairs of\nlock into the sk_psock_data_ready(), which is suggested by John Fastabend.(CVE-2024-36938)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npinctrl: devicetree: fix refcount leak in pinctrl_dt_to_map()\r\n\r\nIf we fail to allocate propname buffer, we need to drop the reference\ncount we just took. Because the pinctrl_dt_free_maps() includes the\ndroping operation, here we call it directly.(CVE-2024-36959)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nRDMA/rxe: Fix seg fault in rxe_comp_queue_pkt\r\n\r\nIn rxe_comp_queue_pkt() an incoming response packet skb is enqueued to the\nresp_pkts queue and then a decision is made whether to run the completer\ntask inline or schedule it. Finally the skb is dereferenced to bump a \u0026apos;hw\u0026apos;\nperformance counter. This is wrong because if the completer task is\nalready running in a separate thread it may have already processed the skb\nand freed it which can cause a seg fault. This has been observed\ninfrequently in testing at high scale.\r\n\r\nThis patch fixes this by changing the order of enqueuing the packet until\nafter the counter is accessed.(CVE-2024-38544)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: ar5523: enable proper endpoint verification\r\n\r\nSyzkaller reports [1] hitting a warning about an endpoint in use\nnot having an expected type to it.\r\n\r\nFix the issue by checking for the existence of all proper\nendpoints with their according types intact.\r\n\r\nSadly, this patch has not been tested on real hardware.\r\n\r\n[1] Syzkaller report:\n------------[ cut here ]------------\nusb 1-1: BOGUS urb xfer, pipe 3 != type 1\nWARNING: CPU: 0 PID: 3643 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504\n...\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ar5523_cmd+0x41b/0x780 drivers/net/wireless/ath/ar5523/ar5523.c:275\n ar5523_cmd_read drivers/net/wireless/ath/ar5523/ar5523.c:302 [inline]\n ar5523_host_available drivers/net/wireless/ath/ar5523/ar5523.c:1376 [inline]\n ar5523_probe+0x14b0/0x1d10 drivers/net/wireless/ath/ar5523/ar5523.c:1655\n usb_probe_interface+0x30f/0x7f0 drivers/usb/core/driver.c:396\n call_driver_probe drivers/base/dd.c:560 [inline]\n really_probe+0x249/0xb90 drivers/base/dd.c:639\n __driver_probe_device+0x1df/0x4d0 drivers/base/dd.c:778\n driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:808\n __device_attach_driver+0x1d4/0x2e0 drivers/base/dd.c:936\n bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:427\n __device_attach+0x1e4/0x530 drivers/base/dd.c:1008\n bus_probe_device+0x1e8/0x2a0 drivers/base/bus.c:487\n device_add+0xbd9/0x1e90 drivers/base/core.c:3517\n usb_set_configuration+0x101d/0x1900 drivers/usb/core/message.c:2170\n usb_generic_driver_probe+0xbe/0x100 drivers/usb/core/generic.c:238\n usb_probe_device+0xd8/0x2c0 drivers/usb/core/driver.c:293\n call_driver_probe drivers/base/dd.c:560 [inline]\n really_probe+0x249/0xb90 drivers/base/dd.c:639\n __driver_probe_device+0x1df/0x4d0 drivers/base/dd.c:778\n driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:808\n __device_attach_driver+0x1d4/0x2e0 drivers/base/dd.c:936\n bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:427\n __device_attach+0x1e4/0x530 drivers/base/dd.c:1008\n bus_probe_device+0x1e8/0x2a0 drivers/base/bus.c:487\n device_add+0xbd9/0x1e90 drivers/base/core.c:3517\n usb_new_device.cold+0x685/0x10ad drivers/usb/core/hub.c:2573\n hub_port_connect drivers/usb/core/hub.c:5353 [inline]\n hub_port_connect_change drivers/usb/core/hub.c:5497 [inline]\n port_event drivers/usb/core/hub.c:5653 [inline]\n hub_event+0x26cb/0x45d0 drivers/usb/core/hub.c:5735\n process_one_work+0x9bf/0x1710 kernel/workqueue.c:2289\n worker_thread+0x669/0x1090 kernel/workqueue.c:2436\n kthread+0x2e8/0x3a0 kernel/kthread.c:376\n ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306\n \u0026lt;/TASK\u0026gt;(CVE-2024-38565)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\neth: sungem: remove .ndo_poll_controller to avoid deadlocks\r\n\r\nErhard reports netpoll warnings from sungem:\r\n\r\n netpoll_send_skb_on_dev(): eth0 enabled interrupts in poll (gem_start_xmit+0x0/0x398)\n WARNING: CPU: 1 PID: 1 at net/core/netpoll.c:370 netpoll_send_skb+0x1fc/0x20c\r\n\r\ngem_poll_controller() disables interrupts, which may sleep.\nWe can\u0026apos;t sleep in netpoll, it has interrupts disabled completely.\nStrangely, gem_poll_controller() doesn\u0026apos;t even poll the completions,\nand instead acts as if an interrupt has fired so it just schedules\nNAPI and exits. None of this has been necessary for years, since\nnetpoll invokes NAPI directly.(CVE-2024-38597)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\next4: fix mb_cache_entry\u0026apos;s e_refcnt leak in ext4_xattr_block_cache_find()\r\n\r\nSyzbot reports a warning as follows:\r\n\r\n============================================\nWARNING: CPU: 0 PID: 5075 at fs/mbcache.c:419 mb_cache_destroy+0x224/0x290\nModules linked in:\nCPU: 0 PID: 5075 Comm: syz-executor199 Not tainted 6.9.0-rc6-gb947cc5bf6d7\nRIP: 0010:mb_cache_destroy+0x224/0x290 fs/mbcache.c:419\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ext4_put_super+0x6d4/0xcd0 fs/ext4/super.c:1375\n generic_shutdown_super+0x136/0x2d0 fs/super.c:641\n kill_block_super+0x44/0x90 fs/super.c:1675\n ext4_kill_sb+0x68/0xa0 fs/ext4/super.c:7327\n[...]\n============================================\r\n\r\nThis is because when finding an entry in ext4_xattr_block_cache_find(), if\next4_sb_bread() returns -ENOMEM, the ce\u0026apos;s e_refcnt, which has already grown\nin the __entry_find(), won\u0026apos;t be put away, and eventually trigger the above\nissue in mb_cache_destroy() due to reference count leakage.\r\n\r\nSo call mb_cache_entry_put() on the -ENOMEM error branch as a quick fix.(CVE-2024-39276)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\njfs: xattr: fix buffer overflow for invalid xattr\r\n\r\nWhen an xattr size is not what is expected, it is printed out to the\nkernel log in hex format as a form of debugging. But when that xattr\nsize is bigger than the expected size, printing it out can cause an\naccess off the end of the buffer.\r\n\r\nFix this all up by properly restricting the size of the debug hex dump\nin the kernel log.(CVE-2024-40902)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntty: add the option to have a tty reject a new ldisc\r\n\r\n... and use it to limit the virtual terminals to just N_TTY. They are\nkind of special, and in particular, the \u0026quot;con_write()\u0026quot; routine violates\nthe \u0026quot;writes cannot sleep\u0026quot; rule that some ldiscs rely on.\r\n\r\nThis avoids the\r\n\r\n BUG: sleeping function called from invalid context at kernel/printk/printk.c:2659\r\n\r\nwhen N_GSM has been attached to a virtual console, and gsmld_write()\ncalls con_write() while holding a spinlock, and con_write() then tries\nto get the console lock.(CVE-2024-40966)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncan: mcp251xfd: fix infinite loop when xmit fails\r\n\r\nWhen the mcp251xfd_start_xmit() function fails, the driver stops\nprocessing messages, and the interrupt routine does not return,\nrunning indefinitely even after killing the running application.\r\n\r\nError messages:\n[ 441.298819] mcp251xfd spi2.0 can0: ERROR in mcp251xfd_start_xmit: -16\n[ 441.306498] mcp251xfd spi2.0 can0: Transmit Event FIFO buffer not empty. (seq=0x000017c7, tef_tail=0x000017cf, tef_head=0x000017d0, tx_head=0x000017d3).\n... and repeat forever.\r\n\r\nThe issue can be triggered when multiple devices share the same SPI\ninterface. And there is concurrent access to the bus.\r\n\r\nThe problem occurs because tx_ring-\u0026gt;head increments even if\nmcp251xfd_start_xmit() fails. Consequently, the driver skips one TX\npackage while still expecting a response in\nmcp251xfd_handle_tefif_one().\r\n\r\nResolve the issue by starting a workqueue to write the tx obj\nsynchronously if err = -EBUSY. In case of another error, decrement\ntx_ring-\u0026gt;head, remove skb from the echo stack, and drop the message.\r\n\r\n[mkl: use more imperative wording in patch description](CVE-2024-41088)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nf_tables: fully validate NFT_DATA_VALUE on store to data registers\r\n\r\nregister store validation for NFT_DATA_VALUE is conditional, however,\nthe datatype is always either NFT_DATA_VALUE or NFT_DATA_VERDICT. This\nonly requires a new helper function to infer the register type from the\nset datatype so this conditional check can be removed. Otherwise,\npointer to chain object can be leaked through the registers.(CVE-2024-42070)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/lima: fix shared irq handling on driver remove\r\n\r\nlima uses a shared interrupt, so the interrupt handlers must be prepared\nto be called at any time. At driver removal time, the clocks are\ndisabled early and the interrupts stay registered until the very end of\nthe remove process due to the devm usage.\nThis is potentially a bug as the interrupts access device registers\nwhich assumes clocks are enabled. A crash can be triggered by removing\nthe driver in a kernel with CONFIG_DEBUG_SHIRQ enabled.\nThis patch frees the interrupts at each lima device finishing callback\nso that the handlers are already unregistered by the time we fully\ndisable clocks.(CVE-2024-42127)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmm: avoid overflows in dirty throttling logic\r\n\r\nThe dirty throttling logic is interspersed with assumptions that dirty\nlimits in PAGE_SIZE units fit into 32-bit (so that various multiplications\nfit into 64-bits). If limits end up being larger, we will hit overflows,\npossible divisions by 0 etc. Fix these problems by never allowing so\nlarge dirty limits as they have dubious practical value anyway. For\ndirty_bytes / dirty_background_bytes interfaces we can just refuse to set\nso large limits. For dirty_ratio / dirty_background_ratio it isn\u0026apos;t so\nsimple as the dirty limit is computed from the amount of available memory\nwhich can change due to memory hotplug etc. So when converting dirty\nlimits from ratios to numbers of pages, we just don\u0026apos;t allow the result to\nexceed UINT_MAX.\r\n\r\nThis is root-only triggerable problem which occurs when the operator\nsets dirty limits to \u0026gt;16 TB.(CVE-2024-42131)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nlibceph: fix race between delayed_work() and ceph_monc_stop()\r\n\r\nThe way the delayed work is handled in ceph_monc_stop() is prone to\nraces with mon_fault() and possibly also finish_hunting(). Both of\nthese can requeue the delayed work which wouldn\u0026apos;t be canceled by any of\nthe following code in case that happens after cancel_delayed_work_sync()\nruns -- __close_session() doesn\u0026apos;t mess with the delayed work in order\nto avoid interfering with the hunting interval logic. This part was\nmissed in commit b5d91704f53e (\u0026quot;libceph: behave in mon_fault() if\ncur_mon \u0026lt; 0\u0026quot;) and use-after-free can still ensue on monc and objects\nthat hang off of it, with monc-\u0026gt;auth and monc-\u0026gt;monmap being\nparticularly susceptible to quickly being reused.\r\n\r\nTo fix this:\r\n\r\n- clear monc-\u0026gt;cur_mon and monc-\u0026gt;hunting as part of closing the session\n in ceph_monc_stop()\n- bail from delayed_work() if monc-\u0026gt;cur_mon is cleared, similar to how\n it\u0026apos;s done in mon_fault() and finish_hunting() (based on monc-\u0026gt;hunting)\n- call cancel_delayed_work_sync() after the session is closed(CVE-2024-42232)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: gadget: configfs: Prevent OOB read/write in usb_string_copy()\r\n\r\nUserspace provided string \u0026apos;s\u0026apos; could trivially have the length zero. Left\nunchecked this will firstly result in an OOB read in the form\n`if (str[0 - 1] == \u0026apos;\\n\u0026apos;) followed closely by an OOB write in the form\n`str[0 - 1] = \u0026apos;\\0\u0026apos;`.\r\n\r\nThere is already a validating check to catch strings that are too long.\nLet\u0026apos;s supply an additional check for invalid strings that are too short.(CVE-2024-42236)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\next4: make sure the first directory block is not a hole\r\n\r\nThe syzbot constructs a directory that has no dirblock but is non-inline,\ni.e. the first directory block is a hole. And no errors are reported when\ncreating files in this directory in the following flow.\r\n\r\n ext4_mknod\n ...\n ext4_add_entry\n // Read block 0\n ext4_read_dirblock(dir, block, DIRENT)\n bh = ext4_bread(NULL, inode, block, 0)\n if (!bh \u0026amp;\u0026amp; (type == INDEX || type == DIRENT_HTREE))\n // The first directory block is a hole\n // But type == DIRENT, so no error is reported.\r\n\r\nAfter that, we get a directory block without \u0026apos;.\u0026apos; and \u0026apos;..\u0026apos; but with a valid\ndentry. This may cause some code that relies on dot or dotdot (such as\nmake_indexed_dir()) to crash.\r\n\r\nTherefore when ext4_read_dirblock() finds that the first directory block\nis a hole report that the filesystem is corrupted and return an error to\navoid loading corrupted data from disk causing something bad.(CVE-2024-42304)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/gma500: fix null pointer dereference in cdv_intel_lvds_get_modes\r\n\r\nIn cdv_intel_lvds_get_modes(), the return value of drm_mode_duplicate()\nis assigned to mode, which will lead to a NULL pointer dereference on\nfailure of drm_mode_duplicate(). Add a check to avoid npd.(CVE-2024-42310)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbna: adjust \u0026apos;name\u0026apos; buf size of bna_tcb and bna_ccb structures\r\n\r\nTo have enough space to write all possible sprintf() args. Currently\n\u0026apos;name\u0026apos; size is 16, but the first \u0026apos;%s\u0026apos; specifier may already need at\nleast 16 characters, since \u0026apos;bnad-\u0026gt;netdev-\u0026gt;name\u0026apos; is used there.\r\n\r\nFor \u0026apos;%d\u0026apos; specifiers, assume that they require:\n * 1 char for \u0026apos;tx_id + tx_info-\u0026gt;tcb[i]-\u0026gt;id\u0026apos; sum, BNAD_MAX_TXQ_PER_TX is 8\n * 2 chars for \u0026apos;rx_id + rx_info-\u0026gt;rx_ctrl[i].ccb-\u0026gt;id\u0026apos;, BNAD_MAX_RXP_PER_RX\n is 16\r\n\r\nAnd replace sprintf with snprintf.\r\n\r\nDetected using the static analysis tool - Svace.(CVE-2024-43839)",
"id": "OESA-2024-2029",
"modified": "2026-08-06T11:07:30Z",
"published": "2024-08-23T11:07:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2029"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26586"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26598"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26602"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27013"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36020"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36880"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36900"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36904"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36914"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36933"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36938"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36959"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38544"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38565"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38597"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39276"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40902"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40966"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41088"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42070"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42127"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42131"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42232"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42236"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42304"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42310"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43839"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2024-26586",
"CVE-2024-26598",
"CVE-2024-26602",
"CVE-2024-27013",
"CVE-2024-36020",
"CVE-2024-36880",
"CVE-2024-36900",
"CVE-2024-36904",
"CVE-2024-36914",
"CVE-2024-36933",
"CVE-2024-36938",
"CVE-2024-36959",
"CVE-2024-38544",
"CVE-2024-38565",
"CVE-2024-38597",
"CVE-2024-39276",
"CVE-2024-40902",
"CVE-2024-40966",
"CVE-2024-41088",
"CVE-2024-42070",
"CVE-2024-42127",
"CVE-2024-42131",
"CVE-2024-42232",
"CVE-2024-42236",
"CVE-2024-42304",
"CVE-2024-42310",
"CVE-2024-43839"
]
}
OESA-2024-2031 (CVE-2024-26586)
Vulnerability from osv_openeuler – Published: 2024-08-23 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:
mlxsw: spectrum_acl_tcam: Fix stack corruption
When tc filters are first added to a net device, the corresponding local port gets bound to an ACL group in the device. The group contains a list of ACLs. In turn, each ACL points to a different TCAM region where the filters are stored. During forwarding, the ACLs are sequentially evaluated until a match is found.
One reason to place filters in different regions is when they are added with decreasing priorities and in an alternating order so that two consecutive filters can never fit in the same region because of their key usage.
In Spectrum-2 and newer ASICs the firmware started to report that the maximum number of ACLs in a group is more than 16, but the layout of the register that configures ACL groups (PAGT) was not updated to account for that. It is therefore possible to hit stack corruption [1] in the rare case where more than 16 ACLs in a group are required.
Fix by limiting the maximum ACL group size to the minimum between what the firmware reports and the maximum ACLs that fit in the PAGT register.
Add a test case to make sure the machine does not crash when this condition is hit.
[1] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: mlxsw_sp_acl_tcam_group_update+0x116/0x120 [...] dump_stack_lvl+0x36/0x50 panic+0x305/0x330 __stack_chk_fail+0x15/0x20 mlxsw_sp_acl_tcam_group_update+0x116/0x120 mlxsw_sp_acl_tcam_group_region_attach+0x69/0x110 mlxsw_sp_acl_tcam_vchunk_get+0x492/0xa20 mlxsw_sp_acl_tcam_ventry_add+0x25/0xe0 mlxsw_sp_acl_rule_add+0x47/0x240 mlxsw_sp_flower_replace+0x1a9/0x1d0 tc_setup_cb_add+0xdc/0x1c0 fl_hw_replace_filter+0x146/0x1f0 fl_change+0xc17/0x1360 tc_new_tfilter+0x472/0xb90 rtnetlink_rcv_msg+0x313/0x3b0 netlink_rcv_skb+0x58/0x100 netlink_unicast+0x244/0x390 netlink_sendmsg+0x1e4/0x440 ____sys_sendmsg+0x164/0x260 ___sys_sendmsg+0x9a/0xe0 __sys_sendmsg+0x7a/0xc0 do_syscall_64+0x40/0xe0 entry_SYSCALL_64_after_hwframe+0x63/0x6b(CVE-2024-26586)
In the Linux kernel, the following vulnerability has been resolved:
KVM: arm64: vgic-its: Avoid potential UAF in LPI translation cache
There is a potential UAF scenario in the case of an LPI translation cache hit racing with an operation that invalidates the cache, such as a DISCARD ITS command. The root of the problem is that vgic_its_check_cache() does not elevate the refcount on the vgic_irq before dropping the lock that serializes refcount changes.
Have vgic_its_check_cache() raise the refcount on the returned vgic_irq and add the corresponding decrement after queueing the interrupt.(CVE-2024-26598)
In the Linux kernel, the following vulnerability has been resolved:
net: relax socket state check at accept time.
Christoph reported the following splat:
WARNING: CPU: 1 PID: 772 at net/ipv4/af_inet.c:761 __inet_accept+0x1f4/0x4a0 Modules linked in: CPU: 1 PID: 772 Comm: syz-executor510 Not tainted 6.9.0-rc7-g7da7119fe22b #56 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014 RIP: 0010:__inet_accept+0x1f4/0x4a0 net/ipv4/af_inet.c:759 Code: 04 38 84 c0 0f 85 87 00 00 00 41 c7 04 24 03 00 00 00 48 83 c4 10 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 ec b7 da fd <0f> 0b e9 7f fe ff ff e8 e0 b7 da fd 0f 0b e9 fe fe ff ff 89 d9 80 RSP: 0018:ffffc90000c2fc58 EFLAGS: 00010293 RAX: ffffffff836bdd14 RBX: 0000000000000000 RCX: ffff888104668000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: dffffc0000000000 R08: ffffffff836bdb89 R09: fffff52000185f64 R10: dffffc0000000000 R11: fffff52000185f64 R12: dffffc0000000000 R13: 1ffff92000185f98 R14: ffff88810754d880 R15: ffff8881007b7800 FS: 000000001c772880(0000) GS:ffff88811b280000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fb9fcf2e178 CR3: 00000001045d2002 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> inet_accept+0x138/0x1d0 net/ipv4/af_inet.c:786 do_accept+0x435/0x620 net/socket.c:1929 __sys_accept4_file net/socket.c:1969 [inline] __sys_accept4+0x9b/0x110 net/socket.c:1999 __do_sys_accept net/socket.c:2016 [inline] __se_sys_accept net/socket.c:2013 [inline] __x64_sys_accept+0x7d/0x90 net/socket.c:2013 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x58/0x100 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x4315f9 Code: fd ff 48 81 c4 80 00 00 00 e9 f1 fe ff ff 0f 1f 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 0f 83 ab b4 fd ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:00007ffdb26d9c78 EFLAGS: 00000246 ORIG_RAX: 000000000000002b RAX: ffffffffffffffda RBX: 0000000000400300 RCX: 00000000004315f9 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000004 RBP: 00000000006e1018 R08: 0000000000400300 R09: 0000000000400300 R10: 0000000000400300 R11: 0000000000000246 R12: 0000000000000000 R13: 000000000040cdf0 R14: 000000000040ce80 R15: 0000000000000055 </TASK>
The reproducer invokes shutdown() before entering the listener status. After commit 94062790aedb ("tcp: defer shutdown(SEND_SHUTDOWN) for TCP_SYN_RECV sockets"), the above causes the child to reach the accept syscall in FIN_WAIT1 status.
Eric noted we can relax the existing assertion in __inet_accept()(CVE-2024-36484)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: qca: add missing firmware sanity checks
Add the missing sanity checks when parsing the firmware files before downloading them to avoid accessing and corrupting memory beyond the vmalloced buffer.(CVE-2024-36880)
In the Linux kernel, the following vulnerability has been resolved:
net: hns3: fix kernel crash when devlink reload during initialization
The devlink reload process will access the hardware resources, but the register operation is done before the hardware is initialized. So, processing the devlink reload during initialization may lead to kernel crash.
This patch fixes this by registering the devlink after hardware initialization.(CVE-2024-36900)
In the Linux kernel, the following vulnerability has been resolved:
tcp: Use refcount_inc_not_zero() in tcp_twsk_unique().
Anderson Nascimento reported a use-after-free splat in tcp_twsk_unique() with nice analysis.
Since commit ec94c2696f0b ("tcp/dccp: avoid one atomic operation for timewait hashdance"), inet_twsk_hashdance() sets TIME-WAIT socket's sk_refcnt after putting it into ehash and releasing the bucket lock.
Thus, there is a small race window where other threads could try to reuse the port during connect() and call sock_hold() in tcp_twsk_unique() for the TIME-WAIT socket with zero refcnt.
If that happens, the refcnt taken by tcp_twsk_unique() is overwritten and sock_put() will cause underflow, triggering a real use-after-free somewhere else.
To avoid the use-after-free, we need to use refcount_inc_not_zero() in tcp_twsk_unique() and give up on reusing the port if it returns false.
[0]: refcount_t: addition on 0; use-after-free. WARNING: CPU: 0 PID: 1039313 at lib/refcount.c:25 refcount_warn_saturate+0xe5/0x110 CPU: 0 PID: 1039313 Comm: trigger Not tainted 6.8.6-200.fc39.x86_64 #1 Hardware name: VMware, Inc. VMware20,1/440BX Desktop Reference Platform, BIOS VMW201.00V.21805430.B64.2305221830 05/22/2023 RIP: 0010:refcount_warn_saturate+0xe5/0x110 Code: 42 8e ff 0f 0b c3 cc cc cc cc 80 3d aa 13 ea 01 00 0f 85 5e ff ff ff 48 c7 c7 f8 8e b7 82 c6 05 96 13 ea 01 01 e8 7b 42 8e ff <0f> 0b c3 cc cc cc cc 48 c7 c7 50 8f b7 82 c6 05 7a 13 ea 01 01 e8 RSP: 0018:ffffc90006b43b60 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff888009bb3ef0 RCX: 0000000000000027 RDX: ffff88807be218c8 RSI: 0000000000000001 RDI: ffff88807be218c0 RBP: 0000000000069d70 R08: 0000000000000000 R09: ffffc90006b439f0 R10: ffffc90006b439e8 R11: 0000000000000003 R12: ffff8880029ede84 R13: 0000000000004e20 R14: ffffffff84356dc0 R15: ffff888009bb3ef0 FS: 00007f62c10926c0(0000) GS:ffff88807be00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020ccb000 CR3: 000000004628c005 CR4: 0000000000f70ef0 PKRU: 55555554 Call Trace: <TASK> ? refcount_warn_saturate+0xe5/0x110 ? __warn+0x81/0x130 ? refcount_warn_saturate+0xe5/0x110 ? report_bug+0x171/0x1a0 ? refcount_warn_saturate+0xe5/0x110 ? handle_bug+0x3c/0x80 ? exc_invalid_op+0x17/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? refcount_warn_saturate+0xe5/0x110 tcp_twsk_unique+0x186/0x190 __inet_check_established+0x176/0x2d0 __inet_hash_connect+0x74/0x7d0 ? __pfx___inet_check_established+0x10/0x10 tcp_v4_connect+0x278/0x530 __inet_stream_connect+0x10f/0x3d0 inet_stream_connect+0x3a/0x60 __sys_connect+0xa8/0xd0 __x64_sys_connect+0x18/0x20 do_syscall_64+0x83/0x170 entry_SYSCALL_64_after_hwframe+0x78/0x80 RIP: 0033:0x7f62c11a885d Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 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 8b 0d a3 45 0c 00 f7 d8 64 89 01 48 RSP: 002b:00007f62c1091e58 EFLAGS: 00000296 ORIG_RAX: 000000000000002a RAX: ffffffffffffffda RBX: 0000000020ccb004 RCX: 00007f62c11a885d RDX: 0000000000000010 RSI: 0000000020ccb000 RDI: 0000000000000003 RBP: 00007f62c1091e90 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000296 R12: 00007f62c10926c0 R13: ffffffffffffff88 R14: 0000000000000000 R15: 00007ffe237885b0 </TASK>(CVE-2024-36904)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Skip on writeback when it's not applicable
[WHY] dynamic memory safety error detector (KASAN) catches and generates error messages "BUG: KASAN: slab-out-of-bounds" as writeback connector does not support certain features which are not initialized.
[HOW] Skip them when connector type is DRM_MODE_CONNECTOR_WRITEBACK.(CVE-2024-36914)
In the Linux kernel, the following vulnerability has been resolved:
nsh: Restore skb->{protocol,data,mac_header} for outer header in nsh_gso_segment().
syzbot triggered various splats (see [0] and links) by a crafted GSO packet of VIRTIO_NET_HDR_GSO_UDP layering the following protocols:
ETH_P_8021AD + ETH_P_NSH + ETH_P_IPV6 + IPPROTO_UDP
NSH can encapsulate IPv4, IPv6, Ethernet, NSH, and MPLS. As the inner protocol can be Ethernet, NSH GSO handler, nsh_gso_segment(), calls skb_mac_gso_segment() to invoke inner protocol GSO handlers.
nsh_gso_segment() does the following for the original skb before calling skb_mac_gso_segment()
- reset skb->network_header
- save the original skb->{mac_heaeder,mac_len} in a local variable
- pull the NSH header
- resets skb->mac_header
- set up skb->mac_len and skb->protocol for the inner protocol.
and does the following for the segmented skb
- set ntohs(ETH_P_NSH) to skb->protocol
- push the NSH header
- restore skb->mac_header
- set skb->mac_header + mac_len to skb->network_header
- restore skb->mac_len
There are two problems in 6-7 and 8-9.
(a) After 6 & 7, skb->data points to the NSH header, so the outer header (ETH_P_8021AD in this case) is stripped when skb is sent out of netdev.
Also, if NSH is encapsulated by NSH + Ethernet (so NSH-Ethernet-NSH), skb_pull() in the first nsh_gso_segment() will make skb->data point to the middle of the outer NSH or Ethernet header because the Ethernet header is not pulled by the second nsh_gso_segment().
(b) While restoring skb->{mac_header,network_header} in 8 & 9, nsh_gso_segment() does not assume that the data in the linear buffer is shifted.
However, udp6_ufo_fragment() could shift the data and change skb->mac_header accordingly as demonstrated by syzbot.
If this happens, even the restored skb->mac_header points to the middle of the outer header.
It seems nsh_gso_segment() has never worked with outer headers so far.
At the end of nsh_gso_segment(), the outer header must be restored for the segmented skb, instead of the NSH header.
To do that, let's calculate the outer header position relatively from the inner header and set skb->{data,mac_header,protocol} properly.
[0]: BUG: KMSAN: uninit-value in ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:524 [inline] BUG: KMSAN: uninit-value in ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline] BUG: KMSAN: uninit-value in ipvlan_queue_xmit+0xf44/0x16b0 drivers/net/ipvlan/ipvlan_core.c:668 ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:524 [inline] ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline] ipvlan_queue_xmit+0xf44/0x16b0 drivers/net/ipvlan/ipvlan_core.c:668 ipvlan_start_xmit+0x5c/0x1a0 drivers/net/ipvlan/ipvlan_main.c:222 __netdev_start_xmit include/linux/netdevice.h:4989 [inline] netdev_start_xmit include/linux/netdevice.h:5003 [inline] xmit_one net/core/dev.c:3547 [inline] dev_hard_start_xmit+0x244/0xa10 net/core/dev.c:3563 __dev_queue_xmit+0x33ed/0x51c0 net/core/dev.c:4351 dev_queue_xmit include/linux/netdevice.h:3171 [inline] packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3081 [inline] packet_sendmsg+0x8aef/0x9f10 net/packet/af_packet.c:3113 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x735/0xa10 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b
Uninit was created at: slab_post_alloc_hook mm/slub.c:3819 [inline] slab_alloc_node mm/slub.c:3860 [inline] __do_kmalloc_node mm/slub.c:3980 [inline] __kmalloc_node_track_caller+0x705/0x1000 mm/slub.c:4001 kmalloc_reserve+0x249/0x4a0 net/core/skbuff.c:582 __ ---truncated---(CVE-2024-36933)
In the Linux kernel, the following vulnerability has been resolved:
bpf, skmsg: Fix NULL pointer dereference in sk_psock_skb_ingress_enqueue
Fix NULL pointer data-races in sk_psock_skb_ingress_enqueue() which syzbot reported [1].
[1] BUG: KCSAN: data-race in sk_psock_drop / sk_psock_skb_ingress_enqueue
write to 0xffff88814b3278b8 of 8 bytes by task 10724 on cpu 1: sk_psock_stop_verdict net/core/skmsg.c:1257 [inline] sk_psock_drop+0x13e/0x1f0 net/core/skmsg.c:843 sk_psock_put include/linux/skmsg.h:459 [inline] sock_map_close+0x1a7/0x260 net/core/sock_map.c:1648 unix_release+0x4b/0x80 net/unix/af_unix.c:1048 __sock_release net/socket.c:659 [inline] sock_close+0x68/0x150 net/socket.c:1421 __fput+0x2c1/0x660 fs/file_table.c:422 __fput_sync+0x44/0x60 fs/file_table.c:507 __do_sys_close fs/open.c:1556 [inline] __se_sys_close+0x101/0x1b0 fs/open.c:1541 __x64_sys_close+0x1f/0x30 fs/open.c:1541 do_syscall_64+0xd3/0x1d0 entry_SYSCALL_64_after_hwframe+0x6d/0x75
read to 0xffff88814b3278b8 of 8 bytes by task 10713 on cpu 0: sk_psock_data_ready include/linux/skmsg.h:464 [inline] sk_psock_skb_ingress_enqueue+0x32d/0x390 net/core/skmsg.c:555 sk_psock_skb_ingress_self+0x185/0x1e0 net/core/skmsg.c:606 sk_psock_verdict_apply net/core/skmsg.c:1008 [inline] sk_psock_verdict_recv+0x3e4/0x4a0 net/core/skmsg.c:1202 unix_read_skb net/unix/af_unix.c:2546 [inline] unix_stream_read_skb+0x9e/0xf0 net/unix/af_unix.c:2682 sk_psock_verdict_data_ready+0x77/0x220 net/core/skmsg.c:1223 unix_stream_sendmsg+0x527/0x860 net/unix/af_unix.c:2339 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x140/0x180 net/socket.c:745 ____sys_sendmsg+0x312/0x410 net/socket.c:2584 ___sys_sendmsg net/socket.c:2638 [inline] __sys_sendmsg+0x1e9/0x280 net/socket.c:2667 __do_sys_sendmsg net/socket.c:2676 [inline] __se_sys_sendmsg net/socket.c:2674 [inline] __x64_sys_sendmsg+0x46/0x50 net/socket.c:2674 do_syscall_64+0xd3/0x1d0 entry_SYSCALL_64_after_hwframe+0x6d/0x75
value changed: 0xffffffff83d7feb0 -> 0x0000000000000000
Reported by Kernel Concurrency Sanitizer on: CPU: 0 PID: 10713 Comm: syz-executor.4 Tainted: G W 6.8.0-syzkaller-08951-gfe46a7dd189e #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024
Prior to this, commit 4cd12c6065df ("bpf, sockmap: Fix NULL pointer dereference in sk_psock_verdict_data_ready()") fixed one NULL pointer similarly due to no protection of saved_data_ready. Here is another different caller causing the same issue because of the same reason. So we should protect it with sk_callback_lock read lock because the writer side in the sk_psock_drop() uses "write_lock_bh(&sk->sk_callback_lock);".
To avoid errors that could happen in future, I move those two pairs of lock into the sk_psock_data_ready(), which is suggested by John Fastabend.(CVE-2024-36938)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/rxe: Fix seg fault in rxe_comp_queue_pkt
In rxe_comp_queue_pkt() an incoming response packet skb is enqueued to the resp_pkts queue and then a decision is made whether to run the completer task inline or schedule it. Finally the skb is dereferenced to bump a 'hw' performance counter. This is wrong because if the completer task is already running in a separate thread it may have already processed the skb and freed it which can cause a seg fault. This has been observed infrequently in testing at high scale.
This patch fixes this by changing the order of enqueuing the packet until after the counter is accessed.(CVE-2024-38544)
In the Linux kernel, the following vulnerability has been resolved:
eth: sungem: remove .ndo_poll_controller to avoid deadlocks
Erhard reports netpoll warnings from sungem:
netpoll_send_skb_on_dev(): eth0 enabled interrupts in poll (gem_start_xmit+0x0/0x398) WARNING: CPU: 1 PID: 1 at net/core/netpoll.c:370 netpoll_send_skb+0x1fc/0x20c
gem_poll_controller() disables interrupts, which may sleep. We can't sleep in netpoll, it has interrupts disabled completely. Strangely, gem_poll_controller() doesn't even poll the completions, and instead acts as if an interrupt has fired so it just schedules NAPI and exits. None of this has been necessary for years, since netpoll invokes NAPI directly.(CVE-2024-38597)
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix mb_cache_entry's e_refcnt leak in ext4_xattr_block_cache_find()
Syzbot reports a warning as follows:
============================================ WARNING: CPU: 0 PID: 5075 at fs/mbcache.c:419 mb_cache_destroy+0x224/0x290 Modules linked in: CPU: 0 PID: 5075 Comm: syz-executor199 Not tainted 6.9.0-rc6-gb947cc5bf6d7 RIP: 0010:mb_cache_destroy+0x224/0x290 fs/mbcache.c:419 Call Trace: <TASK> ext4_put_super+0x6d4/0xcd0 fs/ext4/super.c:1375 generic_shutdown_super+0x136/0x2d0 fs/super.c:641 kill_block_super+0x44/0x90 fs/super.c:1675 ext4_kill_sb+0x68/0xa0 fs/ext4/super.c:7327 [...] ============================================
This is because when finding an entry in ext4_xattr_block_cache_find(), if ext4_sb_bread() returns -ENOMEM, the ce's e_refcnt, which has already grown in the __entry_find(), won't be put away, and eventually trigger the above issue in mb_cache_destroy() due to reference count leakage.
So call mb_cache_entry_put() on the -ENOMEM error branch as a quick fix.(CVE-2024-39276)
In the Linux kernel, the following vulnerability has been resolved:
jfs: xattr: fix buffer overflow for invalid xattr
When an xattr size is not what is expected, it is printed out to the kernel log in hex format as a form of debugging. But when that xattr size is bigger than the expected size, printing it out can cause an access off the end of the buffer.
Fix this all up by properly restricting the size of the debug hex dump in the kernel log.(CVE-2024-40902)
In the Linux kernel, the following vulnerability has been resolved:
tty: add the option to have a tty reject a new ldisc
... and use it to limit the virtual terminals to just N_TTY. They are kind of special, and in particular, the "con_write()" routine violates the "writes cannot sleep" rule that some ldiscs rely on.
This avoids the
BUG: sleeping function called from invalid context at kernel/printk/printk.c:2659
when N_GSM has been attached to a virtual console, and gsmld_write() calls con_write() while holding a spinlock, and con_write() then tries to get the console lock.(CVE-2024-40966)
In the Linux kernel, the following vulnerability has been resolved:
ibmvnic: Add tx check to prevent skb leak
Below is a summary of how the driver stores a reference to an skb during transmit: tx_buff[free_map[consumer_index]]->skb = new_skb; free_map[consumer_index] = IBMVNIC_INVALID_MAP; consumer_index ++; Where variable data looks like this: free_map == [4, IBMVNIC_INVALID_MAP, IBMVNIC_INVALID_MAP, 0, 3] consumer_index^ tx_buff == [skb=null, skb=<ptr>, skb=<ptr>, skb=null, skb=null]
The driver has checks to ensure that free_map[consumer_index] pointed to a valid index but there was no check to ensure that this index pointed to an unused/null skb address. So, if, by some chance, our free_map and tx_buff lists become out of sync then we were previously risking an skb memory leak. This could then cause tcp congestion control to stop sending packets, eventually leading to ETIMEDOUT.
Therefore, add a conditional to ensure that the skb address is null. If not then warn the user (because this is still a bug that should be patched) and free the old pointer to prevent memleak/tcp problems.(CVE-2024-41066)
In the Linux kernel, the following vulnerability has been resolved:
nvme: avoid double free special payload
If a discard request needs to be retried, and that retry may fail before a new special payload is added, a double free will result. Clear the RQF_SPECIAL_LOAD when the request is cleaned.(CVE-2024-41073)
In the Linux kernel, the following vulnerability has been resolved:
ata: libata-core: Fix double free on error
If e.g. the ata_port_alloc() call in ata_host_alloc() fails, we will jump to the err_out label, which will call devres_release_group(). devres_release_group() will trigger a call to ata_host_release(). ata_host_release() calls kfree(host), so executing the kfree(host) in ata_host_alloc() will lead to a double free:
kernel BUG at mm/slub.c:553! Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 11 PID: 599 Comm: (udev-worker) Not tainted 6.10.0-rc5 #47 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:kfree+0x2cf/0x2f0 Code: 5d 41 5e 41 5f 5d e9 80 d6 ff ff 4d 89 f1 41 b8 01 00 00 00 48 89 d9 48 89 da RSP: 0018:ffffc90000f377f0 EFLAGS: 00010246 RAX: ffff888112b1f2c0 RBX: ffff888112b1f2c0 RCX: ffff888112b1f320 RDX: 000000000000400b RSI: ffffffffc02c9de5 RDI: ffff888112b1f2c0 RBP: ffffc90000f37830 R08: 0000000000000000 R09: 0000000000000000 R10: ffffc90000f37610 R11: 617461203a736b6e R12: ffffea00044ac780 R13: ffff888100046400 R14: ffffffffc02c9de5 R15: 0000000000000006 FS: 00007f2f1cabe980(0000) GS:ffff88813b380000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f2f1c3acf75 CR3: 0000000111724000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: <TASK> ? __die_body.cold+0x19/0x27 ? die+0x2e/0x50 ? do_trap+0xca/0x110 ? do_error_trap+0x6a/0x90 ? kfree+0x2cf/0x2f0 ? exc_invalid_op+0x50/0x70 ? kfree+0x2cf/0x2f0 ? asm_exc_invalid_op+0x1a/0x20 ? ata_host_alloc+0xf5/0x120 [libata] ? ata_host_alloc+0xf5/0x120 [libata] ? kfree+0x2cf/0x2f0 ata_host_alloc+0xf5/0x120 [libata] ata_host_alloc_pinfo+0x14/0xa0 [libata] ahci_init_one+0x6c9/0xd20 [ahci]
Ensure that we will not call kfree(host) twice, by performing the kfree() only if the devres_open_group() call failed.(CVE-2024-41087)
In the Linux kernel, the following vulnerability has been resolved:
can: mcp251xfd: fix infinite loop when xmit fails
When the mcp251xfd_start_xmit() function fails, the driver stops processing messages, and the interrupt routine does not return, running indefinitely even after killing the running application.
Error messages: [ 441.298819] mcp251xfd spi2.0 can0: ERROR in mcp251xfd_start_xmit: -16 [ 441.306498] mcp251xfd spi2.0 can0: Transmit Event FIFO buffer not empty. (seq=0x000017c7, tef_tail=0x000017cf, tef_head=0x000017d0, tx_head=0x000017d3). ... and repeat forever.
The issue can be triggered when multiple devices share the same SPI interface. And there is concurrent access to the bus.
The problem occurs because tx_ring->head increments even if mcp251xfd_start_xmit() fails. Consequently, the driver skips one TX package while still expecting a response in mcp251xfd_handle_tefif_one().
Resolve the issue by starting a workqueue to write the tx obj synchronously if err = -EBUSY. In case of another error, decrement tx_ring->head, remove skb from the echo stack, and drop the message.
mkl: use more imperative wording in patch description
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: fully validate NFT_DATA_VALUE on store to data registers
register store validation for NFT_DATA_VALUE is conditional, however, the datatype is always either NFT_DATA_VALUE or NFT_DATA_VERDICT. This only requires a new helper function to infer the register type from the set datatype so this conditional check can be removed. Otherwise, pointer to chain object can be leaked through the registers.(CVE-2024-42070)
In the Linux kernel, the following vulnerability has been resolved:
powerpc: Avoid nmi_enter/nmi_exit in real mode interrupt.
nmi_enter()/nmi_exit() touches per cpu variables which can lead to kernel crash when invoked during real mode interrupt handling (e.g. early HMI/MCE interrupt handler) if percpu allocation comes from vmalloc area.
Early HMI/MCE handlers are called through DEFINE_INTERRUPT_HANDLER_NMI() wrapper which invokes nmi_enter/nmi_exit calls. We don't see any issue when percpu allocation is from the embedded first chunk. However with CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK enabled there are chances where percpu allocation can come from the vmalloc area.
With kernel command line "percpu_alloc=page" we can force percpu allocation to come from vmalloc area and can see kernel crash in machine_check_early:
[ 1.215714] NIP [c000000000e49eb4] rcu_nmi_enter+0x24/0x110 [ 1.215717] LR [c0000000000461a0] machine_check_early+0xf0/0x2c0 [ 1.215719] --- interrupt: 200 [ 1.215720] [c000000fffd73180] [0000000000000000] 0x0 (unreliable) [ 1.215722] [c000000fffd731b0] [0000000000000000] 0x0 [ 1.215724] [c000000fffd73210] [c000000000008364] machine_check_early_common+0x134/0x1f8
Fix this by avoiding use of nmi_enter()/nmi_exit() in real mode if percpu first chunk is not embedded.(CVE-2024-42126)
In the Linux kernel, the following vulnerability has been resolved:
drm/lima: fix shared irq handling on driver remove
lima uses a shared interrupt, so the interrupt handlers must be prepared to be called at any time. At driver removal time, the clocks are disabled early and the interrupts stay registered until the very end of the remove process due to the devm usage. This is potentially a bug as the interrupts access device registers which assumes clocks are enabled. A crash can be triggered by removing the driver in a kernel with CONFIG_DEBUG_SHIRQ enabled. This patch frees the interrupts at each lima device finishing callback so that the handlers are already unregistered by the time we fully disable clocks.(CVE-2024-42127)
In the Linux kernel, the following vulnerability has been resolved:
mm: avoid overflows in dirty throttling logic
The dirty throttling logic is interspersed with assumptions that dirty limits in PAGE_SIZE units fit into 32-bit (so that various multiplications fit into 64-bits). If limits end up being larger, we will hit overflows, possible divisions by 0 etc. Fix these problems by never allowing so large dirty limits as they have dubious practical value anyway. For dirty_bytes / dirty_background_bytes interfaces we can just refuse to set so large limits. For dirty_ratio / dirty_background_ratio it isn't so simple as the dirty limit is computed from the amount of available memory which can change due to memory hotplug etc. So when converting dirty limits from ratios to numbers of pages, we just don't allow the result to exceed UINT_MAX.
This is root-only triggerable problem which occurs when the operator sets dirty limits to >16 TB.(CVE-2024-42131)
In the Linux kernel, the following vulnerability has been resolved:
libceph: fix race between delayed_work() and ceph_monc_stop()
The way the delayed work is handled in ceph_monc_stop() is prone to races with mon_fault() and possibly also finish_hunting(). Both of these can requeue the delayed work which wouldn't be canceled by any of the following code in case that happens after cancel_delayed_work_sync() runs -- __close_session() doesn't mess with the delayed work in order to avoid interfering with the hunting interval logic. This part was missed in commit b5d91704f53e ("libceph: behave in mon_fault() if cur_mon < 0") and use-after-free can still ensue on monc and objects that hang off of it, with monc->auth and monc->monmap being particularly susceptible to quickly being reused.
To fix this:
- clear monc->cur_mon and monc->hunting as part of closing the session in ceph_monc_stop()
- bail from delayed_work() if monc->cur_mon is cleared, similar to how it's done in mon_fault() and finish_hunting() (based on monc->hunting)
- call cancel_delayed_work_sync() after the session is closed(CVE-2024-42232)
In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: configfs: Prevent OOB read/write in usb_string_copy()
Userspace provided string 's' could trivially have the length zero. Left
unchecked this will firstly result in an OOB read in the form
if (str[0 - 1] == '\n') followed closely by an OOB write in the formstr[0 - 1] = '\0'`.
There is already a validating check to catch strings that are too long. Let's supply an additional check for invalid strings that are too short.(CVE-2024-42236)
In the Linux kernel, the following vulnerability has been resolved:
ext4: make sure the first directory block is not a hole
The syzbot constructs a directory that has no dirblock but is non-inline, i.e. the first directory block is a hole. And no errors are reported when creating files in this directory in the following flow.
ext4_mknod
...
ext4_add_entry
// Read block 0
ext4_read_dirblock(dir, block, DIRENT)
bh = ext4_bread(NULL, inode, block, 0)
if (!bh && (type == INDEX || type == DIRENT_HTREE))
// The first directory block is a hole
// But type == DIRENT, so no error is reported.
After that, we get a directory block without '.' and '..' but with a valid dentry. This may cause some code that relies on dot or dotdot (such as make_indexed_dir()) to crash.
Therefore when ext4_read_dirblock() finds that the first directory block is a hole report that the filesystem is corrupted and return an error to avoid loading corrupted data from disk causing something bad.(CVE-2024-42304)
In the Linux kernel, the following vulnerability has been resolved:
drm/gma500: fix null pointer dereference in cdv_intel_lvds_get_modes
In cdv_intel_lvds_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-2024-42310)
In the Linux kernel, the following vulnerability has been resolved:
bna: adjust 'name' buf size of bna_tcb and bna_ccb structures
To have enough space to write all possible sprintf() args. Currently 'name' size is 16, but the first '%s' specifier may already need at least 16 characters, since 'bnad->netdev->name' is used there.
For '%d' specifiers, assume that they require: * 1 char for 'tx_id + tx_info->tcb[i]->id' sum, BNAD_MAX_TXQ_PER_TX is 8 * 2 chars for 'rx_id + rx_info->rx_ctrl[i].ccb->id', BNAD_MAX_RXP_PER_RX is 16
And replace sprintf with snprintf.
Detected using the static analysis tool - Svace.(CVE-2024-43839)
| URL | Type | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"kernel-5.10.0-136.90.0.171.oe2203sp1.aarch64.rpm",
"kernel-debuginfo-5.10.0-136.90.0.171.oe2203sp1.aarch64.rpm",
"kernel-debugsource-5.10.0-136.90.0.171.oe2203sp1.aarch64.rpm",
"kernel-devel-5.10.0-136.90.0.171.oe2203sp1.aarch64.rpm",
"kernel-headers-5.10.0-136.90.0.171.oe2203sp1.aarch64.rpm",
"kernel-source-5.10.0-136.90.0.171.oe2203sp1.aarch64.rpm",
"kernel-tools-5.10.0-136.90.0.171.oe2203sp1.aarch64.rpm",
"kernel-tools-debuginfo-5.10.0-136.90.0.171.oe2203sp1.aarch64.rpm",
"kernel-tools-devel-5.10.0-136.90.0.171.oe2203sp1.aarch64.rpm",
"perf-5.10.0-136.90.0.171.oe2203sp1.aarch64.rpm",
"perf-debuginfo-5.10.0-136.90.0.171.oe2203sp1.aarch64.rpm",
"python3-perf-5.10.0-136.90.0.171.oe2203sp1.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-136.90.0.171.oe2203sp1.aarch64.rpm"
],
"src": [
"kernel-5.10.0-136.90.0.171.oe2203sp1.src.rpm"
],
"x86_64": [
"kernel-5.10.0-136.90.0.171.oe2203sp1.x86_64.rpm",
"kernel-debuginfo-5.10.0-136.90.0.171.oe2203sp1.x86_64.rpm",
"kernel-debugsource-5.10.0-136.90.0.171.oe2203sp1.x86_64.rpm",
"kernel-devel-5.10.0-136.90.0.171.oe2203sp1.x86_64.rpm",
"kernel-headers-5.10.0-136.90.0.171.oe2203sp1.x86_64.rpm",
"kernel-source-5.10.0-136.90.0.171.oe2203sp1.x86_64.rpm",
"kernel-tools-5.10.0-136.90.0.171.oe2203sp1.x86_64.rpm",
"kernel-tools-debuginfo-5.10.0-136.90.0.171.oe2203sp1.x86_64.rpm",
"kernel-tools-devel-5.10.0-136.90.0.171.oe2203sp1.x86_64.rpm",
"perf-5.10.0-136.90.0.171.oe2203sp1.x86_64.rpm",
"perf-debuginfo-5.10.0-136.90.0.171.oe2203sp1.x86_64.rpm",
"python3-perf-5.10.0-136.90.0.171.oe2203sp1.x86_64.rpm",
"python3-perf-debuginfo-5.10.0-136.90.0.171.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.90.0.171.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\nmlxsw: spectrum_acl_tcam: Fix stack corruption\r\n\r\nWhen tc filters are first added to a net device, the corresponding local\nport gets bound to an ACL group in the device. The group contains a list\nof ACLs. In turn, each ACL points to a different TCAM region where the\nfilters are stored. During forwarding, the ACLs are sequentially\nevaluated until a match is found.\r\n\r\nOne reason to place filters in different regions is when they are added\nwith decreasing priorities and in an alternating order so that two\nconsecutive filters can never fit in the same region because of their\nkey usage.\r\n\r\nIn Spectrum-2 and newer ASICs the firmware started to report that the\nmaximum number of ACLs in a group is more than 16, but the layout of the\nregister that configures ACL groups (PAGT) was not updated to account\nfor that. It is therefore possible to hit stack corruption [1] in the\nrare case where more than 16 ACLs in a group are required.\r\n\r\nFix by limiting the maximum ACL group size to the minimum between what\nthe firmware reports and the maximum ACLs that fit in the PAGT register.\r\n\r\nAdd a test case to make sure the machine does not crash when this\ncondition is hit.\r\n\r\n[1]\nKernel panic - not syncing: stack-protector: Kernel stack is corrupted in: mlxsw_sp_acl_tcam_group_update+0x116/0x120\n[...]\n dump_stack_lvl+0x36/0x50\n panic+0x305/0x330\n __stack_chk_fail+0x15/0x20\n mlxsw_sp_acl_tcam_group_update+0x116/0x120\n mlxsw_sp_acl_tcam_group_region_attach+0x69/0x110\n mlxsw_sp_acl_tcam_vchunk_get+0x492/0xa20\n mlxsw_sp_acl_tcam_ventry_add+0x25/0xe0\n mlxsw_sp_acl_rule_add+0x47/0x240\n mlxsw_sp_flower_replace+0x1a9/0x1d0\n tc_setup_cb_add+0xdc/0x1c0\n fl_hw_replace_filter+0x146/0x1f0\n fl_change+0xc17/0x1360\n tc_new_tfilter+0x472/0xb90\n rtnetlink_rcv_msg+0x313/0x3b0\n netlink_rcv_skb+0x58/0x100\n netlink_unicast+0x244/0x390\n netlink_sendmsg+0x1e4/0x440\n ____sys_sendmsg+0x164/0x260\n ___sys_sendmsg+0x9a/0xe0\n __sys_sendmsg+0x7a/0xc0\n do_syscall_64+0x40/0xe0\n entry_SYSCALL_64_after_hwframe+0x63/0x6b(CVE-2024-26586)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nKVM: arm64: vgic-its: Avoid potential UAF in LPI translation cache\r\n\r\nThere is a potential UAF scenario in the case of an LPI translation\ncache hit racing with an operation that invalidates the cache, such\nas a DISCARD ITS command. The root of the problem is that\nvgic_its_check_cache() does not elevate the refcount on the vgic_irq\nbefore dropping the lock that serializes refcount changes.\r\n\r\nHave vgic_its_check_cache() raise the refcount on the returned vgic_irq\nand add the corresponding decrement after queueing the interrupt.(CVE-2024-26598)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: relax socket state check at accept time.\r\n\r\nChristoph reported the following splat:\r\n\r\nWARNING: CPU: 1 PID: 772 at net/ipv4/af_inet.c:761 __inet_accept+0x1f4/0x4a0\nModules linked in:\nCPU: 1 PID: 772 Comm: syz-executor510 Not tainted 6.9.0-rc7-g7da7119fe22b #56\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014\nRIP: 0010:__inet_accept+0x1f4/0x4a0 net/ipv4/af_inet.c:759\nCode: 04 38 84 c0 0f 85 87 00 00 00 41 c7 04 24 03 00 00 00 48 83 c4 10 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 ec b7 da fd \u0026lt;0f\u0026gt; 0b e9 7f fe ff ff e8 e0 b7 da fd 0f 0b e9 fe fe ff ff 89 d9 80\nRSP: 0018:ffffc90000c2fc58 EFLAGS: 00010293\nRAX: ffffffff836bdd14 RBX: 0000000000000000 RCX: ffff888104668000\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000\nRBP: dffffc0000000000 R08: ffffffff836bdb89 R09: fffff52000185f64\nR10: dffffc0000000000 R11: fffff52000185f64 R12: dffffc0000000000\nR13: 1ffff92000185f98 R14: ffff88810754d880 R15: ffff8881007b7800\nFS: 000000001c772880(0000) GS:ffff88811b280000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007fb9fcf2e178 CR3: 00000001045d2002 CR4: 0000000000770ef0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nPKRU: 55555554\nCall Trace:\n \u0026lt;TASK\u0026gt;\n inet_accept+0x138/0x1d0 net/ipv4/af_inet.c:786\n do_accept+0x435/0x620 net/socket.c:1929\n __sys_accept4_file net/socket.c:1969 [inline]\n __sys_accept4+0x9b/0x110 net/socket.c:1999\n __do_sys_accept net/socket.c:2016 [inline]\n __se_sys_accept net/socket.c:2013 [inline]\n __x64_sys_accept+0x7d/0x90 net/socket.c:2013\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0x58/0x100 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\nRIP: 0033:0x4315f9\nCode: fd ff 48 81 c4 80 00 00 00 e9 f1 fe ff ff 0f 1f 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 0f 83 ab b4 fd ff c3 66 2e 0f 1f 84 00 00 00 00\nRSP: 002b:00007ffdb26d9c78 EFLAGS: 00000246 ORIG_RAX: 000000000000002b\nRAX: ffffffffffffffda RBX: 0000000000400300 RCX: 00000000004315f9\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000004\nRBP: 00000000006e1018 R08: 0000000000400300 R09: 0000000000400300\nR10: 0000000000400300 R11: 0000000000000246 R12: 0000000000000000\nR13: 000000000040cdf0 R14: 000000000040ce80 R15: 0000000000000055\n \u0026lt;/TASK\u0026gt;\r\n\r\nThe reproducer invokes shutdown() before entering the listener status.\nAfter commit 94062790aedb (\u0026quot;tcp: defer shutdown(SEND_SHUTDOWN) for\nTCP_SYN_RECV sockets\u0026quot;), the above causes the child to reach the accept\nsyscall in FIN_WAIT1 status.\r\n\r\nEric noted we can relax the existing assertion in __inet_accept()(CVE-2024-36484)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nBluetooth: qca: add missing firmware sanity checks\r\n\r\nAdd the missing sanity checks when parsing the firmware files before\ndownloading them to avoid accessing and corrupting memory beyond the\nvmalloced buffer.(CVE-2024-36880)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: hns3: fix kernel crash when devlink reload during initialization\r\n\r\nThe devlink reload process will access the hardware resources,\nbut the register operation is done before the hardware is initialized.\nSo, processing the devlink reload during initialization may lead to kernel\ncrash.\r\n\r\nThis patch fixes this by registering the devlink after\nhardware initialization.(CVE-2024-36900)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntcp: Use refcount_inc_not_zero() in tcp_twsk_unique().\r\n\r\nAnderson Nascimento reported a use-after-free splat in tcp_twsk_unique()\nwith nice analysis.\r\n\r\nSince commit ec94c2696f0b (\u0026quot;tcp/dccp: avoid one atomic operation for\ntimewait hashdance\u0026quot;), inet_twsk_hashdance() sets TIME-WAIT socket\u0026apos;s\nsk_refcnt after putting it into ehash and releasing the bucket lock.\r\n\r\nThus, there is a small race window where other threads could try to\nreuse the port during connect() and call sock_hold() in tcp_twsk_unique()\nfor the TIME-WAIT socket with zero refcnt.\r\n\r\nIf that happens, the refcnt taken by tcp_twsk_unique() is overwritten\nand sock_put() will cause underflow, triggering a real use-after-free\nsomewhere else.\r\n\r\nTo avoid the use-after-free, we need to use refcount_inc_not_zero() in\ntcp_twsk_unique() and give up on reusing the port if it returns false.\r\n\r\n[0]:\nrefcount_t: addition on 0; use-after-free.\nWARNING: CPU: 0 PID: 1039313 at lib/refcount.c:25 refcount_warn_saturate+0xe5/0x110\nCPU: 0 PID: 1039313 Comm: trigger Not tainted 6.8.6-200.fc39.x86_64 #1\nHardware name: VMware, Inc. VMware20,1/440BX Desktop Reference Platform, BIOS VMW201.00V.21805430.B64.2305221830 05/22/2023\nRIP: 0010:refcount_warn_saturate+0xe5/0x110\nCode: 42 8e ff 0f 0b c3 cc cc cc cc 80 3d aa 13 ea 01 00 0f 85 5e ff ff ff 48 c7 c7 f8 8e b7 82 c6 05 96 13 ea 01 01 e8 7b 42 8e ff \u0026lt;0f\u0026gt; 0b c3 cc cc cc cc 48 c7 c7 50 8f b7 82 c6 05 7a 13 ea 01 01 e8\nRSP: 0018:ffffc90006b43b60 EFLAGS: 00010282\nRAX: 0000000000000000 RBX: ffff888009bb3ef0 RCX: 0000000000000027\nRDX: ffff88807be218c8 RSI: 0000000000000001 RDI: ffff88807be218c0\nRBP: 0000000000069d70 R08: 0000000000000000 R09: ffffc90006b439f0\nR10: ffffc90006b439e8 R11: 0000000000000003 R12: ffff8880029ede84\nR13: 0000000000004e20 R14: ffffffff84356dc0 R15: ffff888009bb3ef0\nFS: 00007f62c10926c0(0000) GS:ffff88807be00000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000020ccb000 CR3: 000000004628c005 CR4: 0000000000f70ef0\nPKRU: 55555554\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? refcount_warn_saturate+0xe5/0x110\n ? __warn+0x81/0x130\n ? refcount_warn_saturate+0xe5/0x110\n ? report_bug+0x171/0x1a0\n ? refcount_warn_saturate+0xe5/0x110\n ? handle_bug+0x3c/0x80\n ? exc_invalid_op+0x17/0x70\n ? asm_exc_invalid_op+0x1a/0x20\n ? refcount_warn_saturate+0xe5/0x110\n tcp_twsk_unique+0x186/0x190\n __inet_check_established+0x176/0x2d0\n __inet_hash_connect+0x74/0x7d0\n ? __pfx___inet_check_established+0x10/0x10\n tcp_v4_connect+0x278/0x530\n __inet_stream_connect+0x10f/0x3d0\n inet_stream_connect+0x3a/0x60\n __sys_connect+0xa8/0xd0\n __x64_sys_connect+0x18/0x20\n do_syscall_64+0x83/0x170\n entry_SYSCALL_64_after_hwframe+0x78/0x80\nRIP: 0033:0x7f62c11a885d\nCode: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 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 8b 0d a3 45 0c 00 f7 d8 64 89 01 48\nRSP: 002b:00007f62c1091e58 EFLAGS: 00000296 ORIG_RAX: 000000000000002a\nRAX: ffffffffffffffda RBX: 0000000020ccb004 RCX: 00007f62c11a885d\nRDX: 0000000000000010 RSI: 0000000020ccb000 RDI: 0000000000000003\nRBP: 00007f62c1091e90 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000296 R12: 00007f62c10926c0\nR13: ffffffffffffff88 R14: 0000000000000000 R15: 00007ffe237885b0\n \u0026lt;/TASK\u0026gt;(CVE-2024-36904)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Skip on writeback when it\u0026apos;s not applicable\r\n\r\n[WHY]\ndynamic memory safety error detector (KASAN) catches and generates error\nmessages \u0026quot;BUG: KASAN: slab-out-of-bounds\u0026quot; as writeback connector does not\nsupport certain features which are not initialized.\r\n\r\n[HOW]\nSkip them when connector type is DRM_MODE_CONNECTOR_WRITEBACK.(CVE-2024-36914)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnsh: Restore skb-\u0026gt;{protocol,data,mac_header} for outer header in nsh_gso_segment().\r\n\r\nsyzbot triggered various splats (see [0] and links) by a crafted GSO\npacket of VIRTIO_NET_HDR_GSO_UDP layering the following protocols:\r\n\r\n ETH_P_8021AD + ETH_P_NSH + ETH_P_IPV6 + IPPROTO_UDP\r\n\r\nNSH can encapsulate IPv4, IPv6, Ethernet, NSH, and MPLS. As the inner\nprotocol can be Ethernet, NSH GSO handler, nsh_gso_segment(), calls\nskb_mac_gso_segment() to invoke inner protocol GSO handlers.\r\n\r\nnsh_gso_segment() does the following for the original skb before\ncalling skb_mac_gso_segment()\r\n\r\n 1. reset skb-\u0026gt;network_header\n 2. save the original skb-\u0026gt;{mac_heaeder,mac_len} in a local variable\n 3. pull the NSH header\n 4. resets skb-\u0026gt;mac_header\n 5. set up skb-\u0026gt;mac_len and skb-\u0026gt;protocol for the inner protocol.\r\n\r\nand does the following for the segmented skb\r\n\r\n 6. set ntohs(ETH_P_NSH) to skb-\u0026gt;protocol\n 7. push the NSH header\n 8. restore skb-\u0026gt;mac_header\n 9. set skb-\u0026gt;mac_header + mac_len to skb-\u0026gt;network_header\n 10. restore skb-\u0026gt;mac_len\r\n\r\nThere are two problems in 6-7 and 8-9.\r\n\r\n (a)\n After 6 \u0026amp; 7, skb-\u0026gt;data points to the NSH header, so the outer header\n (ETH_P_8021AD in this case) is stripped when skb is sent out of netdev.\r\n\r\n Also, if NSH is encapsulated by NSH + Ethernet (so NSH-Ethernet-NSH),\n skb_pull() in the first nsh_gso_segment() will make skb-\u0026gt;data point\n to the middle of the outer NSH or Ethernet header because the Ethernet\n header is not pulled by the second nsh_gso_segment().\r\n\r\n (b)\n While restoring skb-\u0026gt;{mac_header,network_header} in 8 \u0026amp; 9,\n nsh_gso_segment() does not assume that the data in the linear\n buffer is shifted.\r\n\r\n However, udp6_ufo_fragment() could shift the data and change\n skb-\u0026gt;mac_header accordingly as demonstrated by syzbot.\r\n\r\n If this happens, even the restored skb-\u0026gt;mac_header points to\n the middle of the outer header.\r\n\r\nIt seems nsh_gso_segment() has never worked with outer headers so far.\r\n\r\nAt the end of nsh_gso_segment(), the outer header must be restored for\nthe segmented skb, instead of the NSH header.\r\n\r\nTo do that, let\u0026apos;s calculate the outer header position relatively from\nthe inner header and set skb-\u0026gt;{data,mac_header,protocol} properly.\r\n\r\n[0]:\nBUG: KMSAN: uninit-value in ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:524 [inline]\nBUG: KMSAN: uninit-value in ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline]\nBUG: KMSAN: uninit-value in ipvlan_queue_xmit+0xf44/0x16b0 drivers/net/ipvlan/ipvlan_core.c:668\n ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:524 [inline]\n ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline]\n ipvlan_queue_xmit+0xf44/0x16b0 drivers/net/ipvlan/ipvlan_core.c:668\n ipvlan_start_xmit+0x5c/0x1a0 drivers/net/ipvlan/ipvlan_main.c:222\n __netdev_start_xmit include/linux/netdevice.h:4989 [inline]\n netdev_start_xmit include/linux/netdevice.h:5003 [inline]\n xmit_one net/core/dev.c:3547 [inline]\n dev_hard_start_xmit+0x244/0xa10 net/core/dev.c:3563\n __dev_queue_xmit+0x33ed/0x51c0 net/core/dev.c:4351\n dev_queue_xmit include/linux/netdevice.h:3171 [inline]\n packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276\n packet_snd net/packet/af_packet.c:3081 [inline]\n packet_sendmsg+0x8aef/0x9f10 net/packet/af_packet.c:3113\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg net/socket.c:745 [inline]\n __sys_sendto+0x735/0xa10 net/socket.c:2191\n __do_sys_sendto net/socket.c:2203 [inline]\n __se_sys_sendto net/socket.c:2199 [inline]\n __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x63/0x6b\r\n\r\nUninit was created at:\n slab_post_alloc_hook mm/slub.c:3819 [inline]\n slab_alloc_node mm/slub.c:3860 [inline]\n __do_kmalloc_node mm/slub.c:3980 [inline]\n __kmalloc_node_track_caller+0x705/0x1000 mm/slub.c:4001\n kmalloc_reserve+0x249/0x4a0 net/core/skbuff.c:582\n __\n---truncated---(CVE-2024-36933)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbpf, skmsg: Fix NULL pointer dereference in sk_psock_skb_ingress_enqueue\r\n\r\nFix NULL pointer data-races in sk_psock_skb_ingress_enqueue() which\nsyzbot reported [1].\r\n\r\n[1]\nBUG: KCSAN: data-race in sk_psock_drop / sk_psock_skb_ingress_enqueue\r\n\r\nwrite to 0xffff88814b3278b8 of 8 bytes by task 10724 on cpu 1:\n sk_psock_stop_verdict net/core/skmsg.c:1257 [inline]\n sk_psock_drop+0x13e/0x1f0 net/core/skmsg.c:843\n sk_psock_put include/linux/skmsg.h:459 [inline]\n sock_map_close+0x1a7/0x260 net/core/sock_map.c:1648\n unix_release+0x4b/0x80 net/unix/af_unix.c:1048\n __sock_release net/socket.c:659 [inline]\n sock_close+0x68/0x150 net/socket.c:1421\n __fput+0x2c1/0x660 fs/file_table.c:422\n __fput_sync+0x44/0x60 fs/file_table.c:507\n __do_sys_close fs/open.c:1556 [inline]\n __se_sys_close+0x101/0x1b0 fs/open.c:1541\n __x64_sys_close+0x1f/0x30 fs/open.c:1541\n do_syscall_64+0xd3/0x1d0\n entry_SYSCALL_64_after_hwframe+0x6d/0x75\r\n\r\nread to 0xffff88814b3278b8 of 8 bytes by task 10713 on cpu 0:\n sk_psock_data_ready include/linux/skmsg.h:464 [inline]\n sk_psock_skb_ingress_enqueue+0x32d/0x390 net/core/skmsg.c:555\n sk_psock_skb_ingress_self+0x185/0x1e0 net/core/skmsg.c:606\n sk_psock_verdict_apply net/core/skmsg.c:1008 [inline]\n sk_psock_verdict_recv+0x3e4/0x4a0 net/core/skmsg.c:1202\n unix_read_skb net/unix/af_unix.c:2546 [inline]\n unix_stream_read_skb+0x9e/0xf0 net/unix/af_unix.c:2682\n sk_psock_verdict_data_ready+0x77/0x220 net/core/skmsg.c:1223\n unix_stream_sendmsg+0x527/0x860 net/unix/af_unix.c:2339\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg+0x140/0x180 net/socket.c:745\n ____sys_sendmsg+0x312/0x410 net/socket.c:2584\n ___sys_sendmsg net/socket.c:2638 [inline]\n __sys_sendmsg+0x1e9/0x280 net/socket.c:2667\n __do_sys_sendmsg net/socket.c:2676 [inline]\n __se_sys_sendmsg net/socket.c:2674 [inline]\n __x64_sys_sendmsg+0x46/0x50 net/socket.c:2674\n do_syscall_64+0xd3/0x1d0\n entry_SYSCALL_64_after_hwframe+0x6d/0x75\r\n\r\nvalue changed: 0xffffffff83d7feb0 -\u0026gt; 0x0000000000000000\r\n\r\nReported by Kernel Concurrency Sanitizer on:\nCPU: 0 PID: 10713 Comm: syz-executor.4 Tainted: G W 6.8.0-syzkaller-08951-gfe46a7dd189e #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024\r\n\r\nPrior to this, commit 4cd12c6065df (\u0026quot;bpf, sockmap: Fix NULL pointer\ndereference in sk_psock_verdict_data_ready()\u0026quot;) fixed one NULL pointer\nsimilarly due to no protection of saved_data_ready. Here is another\ndifferent caller causing the same issue because of the same reason. So\nwe should protect it with sk_callback_lock read lock because the writer\nside in the sk_psock_drop() uses \u0026quot;write_lock_bh(\u0026amp;sk-\u0026gt;sk_callback_lock);\u0026quot;.\r\n\r\nTo avoid errors that could happen in future, I move those two pairs of\nlock into the sk_psock_data_ready(), which is suggested by John Fastabend.(CVE-2024-36938)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nRDMA/rxe: Fix seg fault in rxe_comp_queue_pkt\r\n\r\nIn rxe_comp_queue_pkt() an incoming response packet skb is enqueued to the\nresp_pkts queue and then a decision is made whether to run the completer\ntask inline or schedule it. Finally the skb is dereferenced to bump a \u0026apos;hw\u0026apos;\nperformance counter. This is wrong because if the completer task is\nalready running in a separate thread it may have already processed the skb\nand freed it which can cause a seg fault. This has been observed\ninfrequently in testing at high scale.\r\n\r\nThis patch fixes this by changing the order of enqueuing the packet until\nafter the counter is accessed.(CVE-2024-38544)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\neth: sungem: remove .ndo_poll_controller to avoid deadlocks\r\n\r\nErhard reports netpoll warnings from sungem:\r\n\r\n netpoll_send_skb_on_dev(): eth0 enabled interrupts in poll (gem_start_xmit+0x0/0x398)\n WARNING: CPU: 1 PID: 1 at net/core/netpoll.c:370 netpoll_send_skb+0x1fc/0x20c\r\n\r\ngem_poll_controller() disables interrupts, which may sleep.\nWe can\u0026apos;t sleep in netpoll, it has interrupts disabled completely.\nStrangely, gem_poll_controller() doesn\u0026apos;t even poll the completions,\nand instead acts as if an interrupt has fired so it just schedules\nNAPI and exits. None of this has been necessary for years, since\nnetpoll invokes NAPI directly.(CVE-2024-38597)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\next4: fix mb_cache_entry\u0026apos;s e_refcnt leak in ext4_xattr_block_cache_find()\r\n\r\nSyzbot reports a warning as follows:\r\n\r\n============================================\nWARNING: CPU: 0 PID: 5075 at fs/mbcache.c:419 mb_cache_destroy+0x224/0x290\nModules linked in:\nCPU: 0 PID: 5075 Comm: syz-executor199 Not tainted 6.9.0-rc6-gb947cc5bf6d7\nRIP: 0010:mb_cache_destroy+0x224/0x290 fs/mbcache.c:419\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ext4_put_super+0x6d4/0xcd0 fs/ext4/super.c:1375\n generic_shutdown_super+0x136/0x2d0 fs/super.c:641\n kill_block_super+0x44/0x90 fs/super.c:1675\n ext4_kill_sb+0x68/0xa0 fs/ext4/super.c:7327\n[...]\n============================================\r\n\r\nThis is because when finding an entry in ext4_xattr_block_cache_find(), if\next4_sb_bread() returns -ENOMEM, the ce\u0026apos;s e_refcnt, which has already grown\nin the __entry_find(), won\u0026apos;t be put away, and eventually trigger the above\nissue in mb_cache_destroy() due to reference count leakage.\r\n\r\nSo call mb_cache_entry_put() on the -ENOMEM error branch as a quick fix.(CVE-2024-39276)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\njfs: xattr: fix buffer overflow for invalid xattr\r\n\r\nWhen an xattr size is not what is expected, it is printed out to the\nkernel log in hex format as a form of debugging. But when that xattr\nsize is bigger than the expected size, printing it out can cause an\naccess off the end of the buffer.\r\n\r\nFix this all up by properly restricting the size of the debug hex dump\nin the kernel log.(CVE-2024-40902)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntty: add the option to have a tty reject a new ldisc\r\n\r\n... and use it to limit the virtual terminals to just N_TTY. They are\nkind of special, and in particular, the \u0026quot;con_write()\u0026quot; routine violates\nthe \u0026quot;writes cannot sleep\u0026quot; rule that some ldiscs rely on.\r\n\r\nThis avoids the\r\n\r\n BUG: sleeping function called from invalid context at kernel/printk/printk.c:2659\r\n\r\nwhen N_GSM has been attached to a virtual console, and gsmld_write()\ncalls con_write() while holding a spinlock, and con_write() then tries\nto get the console lock.(CVE-2024-40966)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nibmvnic: Add tx check to prevent skb leak\r\n\r\nBelow is a summary of how the driver stores a reference to an skb during\ntransmit:\n tx_buff[free_map[consumer_index]]-\u0026gt;skb = new_skb;\n free_map[consumer_index] = IBMVNIC_INVALID_MAP;\n consumer_index ++;\nWhere variable data looks like this:\n free_map == [4, IBMVNIC_INVALID_MAP, IBMVNIC_INVALID_MAP, 0, 3]\n \tconsumer_index^\n tx_buff == [skb=null, skb=\u0026lt;ptr\u0026gt;, skb=\u0026lt;ptr\u0026gt;, skb=null, skb=null]\r\n\r\nThe driver has checks to ensure that free_map[consumer_index] pointed to\na valid index but there was no check to ensure that this index pointed\nto an unused/null skb address. So, if, by some chance, our free_map and\ntx_buff lists become out of sync then we were previously risking an\nskb memory leak. This could then cause tcp congestion control to stop\nsending packets, eventually leading to ETIMEDOUT.\r\n\r\nTherefore, add a conditional to ensure that the skb address is null. If\nnot then warn the user (because this is still a bug that should be\npatched) and free the old pointer to prevent memleak/tcp problems.(CVE-2024-41066)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnvme: avoid double free special payload\r\n\r\nIf a discard request needs to be retried, and that retry may fail before\na new special payload is added, a double free will result. Clear the\nRQF_SPECIAL_LOAD when the request is cleaned.(CVE-2024-41073)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nata: libata-core: Fix double free on error\r\n\r\nIf e.g. the ata_port_alloc() call in ata_host_alloc() fails, we will jump\nto the err_out label, which will call devres_release_group().\ndevres_release_group() will trigger a call to ata_host_release().\nata_host_release() calls kfree(host), so executing the kfree(host) in\nata_host_alloc() will lead to a double free:\r\n\r\nkernel BUG at mm/slub.c:553!\nOops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI\nCPU: 11 PID: 599 Comm: (udev-worker) Not tainted 6.10.0-rc5 #47\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014\nRIP: 0010:kfree+0x2cf/0x2f0\nCode: 5d 41 5e 41 5f 5d e9 80 d6 ff ff 4d 89 f1 41 b8 01 00 00 00 48 89 d9 48 89 da\nRSP: 0018:ffffc90000f377f0 EFLAGS: 00010246\nRAX: ffff888112b1f2c0 RBX: ffff888112b1f2c0 RCX: ffff888112b1f320\nRDX: 000000000000400b RSI: ffffffffc02c9de5 RDI: ffff888112b1f2c0\nRBP: ffffc90000f37830 R08: 0000000000000000 R09: 0000000000000000\nR10: ffffc90000f37610 R11: 617461203a736b6e R12: ffffea00044ac780\nR13: ffff888100046400 R14: ffffffffc02c9de5 R15: 0000000000000006\nFS: 00007f2f1cabe980(0000) GS:ffff88813b380000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f2f1c3acf75 CR3: 0000000111724000 CR4: 0000000000750ef0\nPKRU: 55555554\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? __die_body.cold+0x19/0x27\n ? die+0x2e/0x50\n ? do_trap+0xca/0x110\n ? do_error_trap+0x6a/0x90\n ? kfree+0x2cf/0x2f0\n ? exc_invalid_op+0x50/0x70\n ? kfree+0x2cf/0x2f0\n ? asm_exc_invalid_op+0x1a/0x20\n ? ata_host_alloc+0xf5/0x120 [libata]\n ? ata_host_alloc+0xf5/0x120 [libata]\n ? kfree+0x2cf/0x2f0\n ata_host_alloc+0xf5/0x120 [libata]\n ata_host_alloc_pinfo+0x14/0xa0 [libata]\n ahci_init_one+0x6c9/0xd20 [ahci]\r\n\r\nEnsure that we will not call kfree(host) twice, by performing the kfree()\nonly if the devres_open_group() call failed.(CVE-2024-41087)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncan: mcp251xfd: fix infinite loop when xmit fails\r\n\r\nWhen the mcp251xfd_start_xmit() function fails, the driver stops\nprocessing messages, and the interrupt routine does not return,\nrunning indefinitely even after killing the running application.\r\n\r\nError messages:\n[ 441.298819] mcp251xfd spi2.0 can0: ERROR in mcp251xfd_start_xmit: -16\n[ 441.306498] mcp251xfd spi2.0 can0: Transmit Event FIFO buffer not empty. (seq=0x000017c7, tef_tail=0x000017cf, tef_head=0x000017d0, tx_head=0x000017d3).\n... and repeat forever.\r\n\r\nThe issue can be triggered when multiple devices share the same SPI\ninterface. And there is concurrent access to the bus.\r\n\r\nThe problem occurs because tx_ring-\u0026gt;head increments even if\nmcp251xfd_start_xmit() fails. Consequently, the driver skips one TX\npackage while still expecting a response in\nmcp251xfd_handle_tefif_one().\r\n\r\nResolve the issue by starting a workqueue to write the tx obj\nsynchronously if err = -EBUSY. In case of another error, decrement\ntx_ring-\u0026gt;head, remove skb from the echo stack, and drop the message.\r\n\r\n[mkl: use more imperative wording in patch description](CVE-2024-41088)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nf_tables: fully validate NFT_DATA_VALUE on store to data registers\r\n\r\nregister store validation for NFT_DATA_VALUE is conditional, however,\nthe datatype is always either NFT_DATA_VALUE or NFT_DATA_VERDICT. This\nonly requires a new helper function to infer the register type from the\nset datatype so this conditional check can be removed. Otherwise,\npointer to chain object can be leaked through the registers.(CVE-2024-42070)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npowerpc: Avoid nmi_enter/nmi_exit in real mode interrupt.\r\n\r\nnmi_enter()/nmi_exit() touches per cpu variables which can lead to kernel\ncrash when invoked during real mode interrupt handling (e.g. early HMI/MCE\ninterrupt handler) if percpu allocation comes from vmalloc area.\r\n\r\nEarly HMI/MCE handlers are called through DEFINE_INTERRUPT_HANDLER_NMI()\nwrapper which invokes nmi_enter/nmi_exit calls. We don\u0026apos;t see any issue when\npercpu allocation is from the embedded first chunk. However with\nCONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK enabled there are chances where percpu\nallocation can come from the vmalloc area.\r\n\r\nWith kernel command line \u0026quot;percpu_alloc=page\u0026quot; we can force percpu allocation\nto come from vmalloc area and can see kernel crash in machine_check_early:\r\n\r\n[ 1.215714] NIP [c000000000e49eb4] rcu_nmi_enter+0x24/0x110\n[ 1.215717] LR [c0000000000461a0] machine_check_early+0xf0/0x2c0\n[ 1.215719] --- interrupt: 200\n[ 1.215720] [c000000fffd73180] [0000000000000000] 0x0 (unreliable)\n[ 1.215722] [c000000fffd731b0] [0000000000000000] 0x0\n[ 1.215724] [c000000fffd73210] [c000000000008364] machine_check_early_common+0x134/0x1f8\r\n\r\nFix this by avoiding use of nmi_enter()/nmi_exit() in real mode if percpu\nfirst chunk is not embedded.(CVE-2024-42126)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/lima: fix shared irq handling on driver remove\r\n\r\nlima uses a shared interrupt, so the interrupt handlers must be prepared\nto be called at any time. At driver removal time, the clocks are\ndisabled early and the interrupts stay registered until the very end of\nthe remove process due to the devm usage.\nThis is potentially a bug as the interrupts access device registers\nwhich assumes clocks are enabled. A crash can be triggered by removing\nthe driver in a kernel with CONFIG_DEBUG_SHIRQ enabled.\nThis patch frees the interrupts at each lima device finishing callback\nso that the handlers are already unregistered by the time we fully\ndisable clocks.(CVE-2024-42127)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmm: avoid overflows in dirty throttling logic\r\n\r\nThe dirty throttling logic is interspersed with assumptions that dirty\nlimits in PAGE_SIZE units fit into 32-bit (so that various multiplications\nfit into 64-bits). If limits end up being larger, we will hit overflows,\npossible divisions by 0 etc. Fix these problems by never allowing so\nlarge dirty limits as they have dubious practical value anyway. For\ndirty_bytes / dirty_background_bytes interfaces we can just refuse to set\nso large limits. For dirty_ratio / dirty_background_ratio it isn\u0026apos;t so\nsimple as the dirty limit is computed from the amount of available memory\nwhich can change due to memory hotplug etc. So when converting dirty\nlimits from ratios to numbers of pages, we just don\u0026apos;t allow the result to\nexceed UINT_MAX.\r\n\r\nThis is root-only triggerable problem which occurs when the operator\nsets dirty limits to \u0026gt;16 TB.(CVE-2024-42131)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nlibceph: fix race between delayed_work() and ceph_monc_stop()\r\n\r\nThe way the delayed work is handled in ceph_monc_stop() is prone to\nraces with mon_fault() and possibly also finish_hunting(). Both of\nthese can requeue the delayed work which wouldn\u0026apos;t be canceled by any of\nthe following code in case that happens after cancel_delayed_work_sync()\nruns -- __close_session() doesn\u0026apos;t mess with the delayed work in order\nto avoid interfering with the hunting interval logic. This part was\nmissed in commit b5d91704f53e (\u0026quot;libceph: behave in mon_fault() if\ncur_mon \u0026lt; 0\u0026quot;) and use-after-free can still ensue on monc and objects\nthat hang off of it, with monc-\u0026gt;auth and monc-\u0026gt;monmap being\nparticularly susceptible to quickly being reused.\r\n\r\nTo fix this:\r\n\r\n- clear monc-\u0026gt;cur_mon and monc-\u0026gt;hunting as part of closing the session\n in ceph_monc_stop()\n- bail from delayed_work() if monc-\u0026gt;cur_mon is cleared, similar to how\n it\u0026apos;s done in mon_fault() and finish_hunting() (based on monc-\u0026gt;hunting)\n- call cancel_delayed_work_sync() after the session is closed(CVE-2024-42232)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: gadget: configfs: Prevent OOB read/write in usb_string_copy()\r\n\r\nUserspace provided string \u0026apos;s\u0026apos; could trivially have the length zero. Left\nunchecked this will firstly result in an OOB read in the form\n`if (str[0 - 1] == \u0026apos;\\n\u0026apos;) followed closely by an OOB write in the form\n`str[0 - 1] = \u0026apos;\\0\u0026apos;`.\r\n\r\nThere is already a validating check to catch strings that are too long.\nLet\u0026apos;s supply an additional check for invalid strings that are too short.(CVE-2024-42236)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\next4: make sure the first directory block is not a hole\r\n\r\nThe syzbot constructs a directory that has no dirblock but is non-inline,\ni.e. the first directory block is a hole. And no errors are reported when\ncreating files in this directory in the following flow.\r\n\r\n ext4_mknod\n ...\n ext4_add_entry\n // Read block 0\n ext4_read_dirblock(dir, block, DIRENT)\n bh = ext4_bread(NULL, inode, block, 0)\n if (!bh \u0026amp;\u0026amp; (type == INDEX || type == DIRENT_HTREE))\n // The first directory block is a hole\n // But type == DIRENT, so no error is reported.\r\n\r\nAfter that, we get a directory block without \u0026apos;.\u0026apos; and \u0026apos;..\u0026apos; but with a valid\ndentry. This may cause some code that relies on dot or dotdot (such as\nmake_indexed_dir()) to crash.\r\n\r\nTherefore when ext4_read_dirblock() finds that the first directory block\nis a hole report that the filesystem is corrupted and return an error to\navoid loading corrupted data from disk causing something bad.(CVE-2024-42304)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/gma500: fix null pointer dereference in cdv_intel_lvds_get_modes\r\n\r\nIn cdv_intel_lvds_get_modes(), the return value of drm_mode_duplicate()\nis assigned to mode, which will lead to a NULL pointer dereference on\nfailure of drm_mode_duplicate(). Add a check to avoid npd.(CVE-2024-42310)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbna: adjust \u0026apos;name\u0026apos; buf size of bna_tcb and bna_ccb structures\r\n\r\nTo have enough space to write all possible sprintf() args. Currently\n\u0026apos;name\u0026apos; size is 16, but the first \u0026apos;%s\u0026apos; specifier may already need at\nleast 16 characters, since \u0026apos;bnad-\u0026gt;netdev-\u0026gt;name\u0026apos; is used there.\r\n\r\nFor \u0026apos;%d\u0026apos; specifiers, assume that they require:\n * 1 char for \u0026apos;tx_id + tx_info-\u0026gt;tcb[i]-\u0026gt;id\u0026apos; sum, BNAD_MAX_TXQ_PER_TX is 8\n * 2 chars for \u0026apos;rx_id + rx_info-\u0026gt;rx_ctrl[i].ccb-\u0026gt;id\u0026apos;, BNAD_MAX_RXP_PER_RX\n is 16\r\n\r\nAnd replace sprintf with snprintf.\r\n\r\nDetected using the static analysis tool - Svace.(CVE-2024-43839)",
"id": "OESA-2024-2031",
"modified": "2026-08-06T11:07:30Z",
"published": "2024-08-23T11:07:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2031"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26586"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26598"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36484"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36880"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36900"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36904"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36914"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36933"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36938"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38544"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38597"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39276"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40902"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40966"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41066"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41073"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41087"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41088"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42070"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42126"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42127"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42131"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42232"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42236"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42304"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42310"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43839"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2024-26586",
"CVE-2024-26598",
"CVE-2024-36484",
"CVE-2024-36880",
"CVE-2024-36900",
"CVE-2024-36904",
"CVE-2024-36914",
"CVE-2024-36933",
"CVE-2024-36938",
"CVE-2024-38544",
"CVE-2024-38597",
"CVE-2024-39276",
"CVE-2024-40902",
"CVE-2024-40966",
"CVE-2024-41066",
"CVE-2024-41073",
"CVE-2024-41087",
"CVE-2024-41088",
"CVE-2024-42070",
"CVE-2024-42126",
"CVE-2024-42127",
"CVE-2024-42131",
"CVE-2024-42232",
"CVE-2024-42236",
"CVE-2024-42304",
"CVE-2024-42310",
"CVE-2024-43839"
]
}
OESA-2025-1729 (CVE-2024-38385)
Vulnerability from osv_openeuler – Published: 2025-07-04 11:08 – Updated: 2026-08-06 11:08 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:genirq/irqdesc: Prevent use-after-free in irq_find_at_or_after()irq_find_at_or_after() dereferences the interrupt descriptor which isreturned by mt_find() while neither holding sparse_irq_lock nor RCU readlock, which means the descriptor can be freed between mt_find() and thedereference: CPU0 CPU1 desc = mt_find() delayed_free_desc(desc) irq_desc_get_irq(desc)The use-after-free is reported by KASAN: Call trace: irq_get_next_irq+0x58/0x84 show_stat+0x638/0x824 seq_read_iter+0x158/0x4ec proc_reg_read_iter+0x94/0x12c vfs_read+0x1e0/0x2c8 Freed by task 4471: slab_free_freelist_hook+0x174/0x1e0 __kmem_cache_free+0xa4/0x1dc kfree+0x64/0x128 irq_kobj_release+0x28/0x3c kobject_put+0xcc/0x1e0 delayed_free_desc+0x14/0x2c rcu_do_batch+0x214/0x720Guard the access with a RCU read lock section.(CVE-2024-38385)
In the Linux kernel, the following vulnerability has been resolved:
drm/lima: fix shared irq handling on driver remove
lima uses a shared interrupt, so the interrupt handlers must be prepared to be called at any time. At driver removal time, the clocks are disabled early and the interrupts stay registered until the very end of the remove process due to the devm usage. This is potentially a bug as the interrupts access device registers which assumes clocks are enabled. A crash can be triggered by removing the driver in a kernel with CONFIG_DEBUG_SHIRQ enabled. This patch frees the interrupts at each lima device finishing callback so that the handlers are already unregistered by the time we fully disable clocks.(CVE-2024-42127)
In the Linux kernel, the following vulnerability has been resolved:mm: avoid overflows in dirty throttling logicThe dirty throttling logic is interspersed with assumptions that dirtylimits in PAGE_SIZE units fit into 32-bit (so that various multiplicationsfit into 64-bits). If limits end up being larger, we will hit overflows,possible divisions by 0 etc. Fix these problems by never allowing solarge dirty limits as they have dubious practical value anyway. Fordirty_bytes / dirty_background_bytes interfaces we can just refuse to setso large limits. For dirty_ratio / dirty_background_ratio it isn t sosimple as the dirty limit is computed from the amount of available memorywhich can change due to memory hotplug etc. So when converting dirtylimits from ratios to numbers of pages, we just don t allow the result toexceed UINT_MAX.This is root-only triggerable problem which occurs when the operatorsets dirty limits to >16 TB.(CVE-2024-42131)
In the Linux kernel, the following vulnerability has been resolved:
drm/msm/dpu: move dpu_encoder's connector assignment to atomic_enable()
For cases where the crtc's connectors_changed was set without enable/active getting toggled , there is an atomic_enable() call followed by an atomic_disable() but without an atomic_mode_set().
This results in a NULL ptr access for the dpu_encoder_get_drm_fmt() call in the atomic_enable() as the dpu_encoder's connector was cleared in the atomic_disable() but not re-assigned as there was no atomic_mode_set() call.
Fix the NULL ptr access by moving the assignment for atomic_enable() and also use drm_atomic_get_new_connector_for_encoder() to get the connector from the atomic_state.
Patchwork: https://patchwork.freedesktop.org/patch/606729/(CVE-2024-45015)
In the Linux kernel, the following vulnerability has been resolved:
crypto: iaa - Fix potential use after free bug
The free_device_compression_mode(iaa_device, device_mode) function frees "device_mode" but it iss passed to iaa_compression_modes[i]->free() a few lines later resulting in a use after free.
The good news is that, so far as I can tell, nothing implements the ->free() function and the use after free happens in dead code. But, with this fix, when something does implement it, we'll be ready. :)(CVE-2024-47732)
In the Linux kernel, the following vulnerability has been resolved:
btrfs: flush delalloc workers queue before stopping cleaner kthread during unmount
During the unmount path, at close_ctree(), we first stop the cleaner kthread, using kthread_stop() which frees the associated task_struct, and then stop and destroy all the work queues. However after we stopped the cleaner we may still have a worker from the delalloc_workers queue running inode.c:submit_compressed_extents(), which calls btrfs_add_delayed_iput(), which in turn tries to wake up the cleaner kthread - which was already destroyed before, resulting in a use-after-free on the task_struct.
Syzbot reported this with the following stack traces:
BUG: KASAN: slab-use-after-free in __lock_acquire+0x78/0x2100 kernel/locking/lockdep.c:5089 Read of size 8 at addr ffff8880259d2818 by task kworker/u8:3/52
CPU: 1 UID: 0 PID: 52 Comm: kworker/u8:3 Not tainted 6.13.0-rc1-syzkaller-00002-gcdd30ebb1b9f #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Workqueue: btrfs-delalloc btrfs_work_helper Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x169/0x550 mm/kasan/report.c:489 kasan_report+0x143/0x180 mm/kasan/report.c:602 __lock_acquire+0x78/0x2100 kernel/locking/lockdep.c:5089 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5849 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0xd5/0x120 kernel/locking/spinlock.c:162 class_raw_spinlock_irqsave_constructor include/linux/spinlock.h:551 [inline] try_to_wake_up+0xc2/0x1470 kernel/sched/core.c:4205 submit_compressed_extents+0xdf/0x16e0 fs/btrfs/inode.c:1615 run_ordered_work fs/btrfs/async-thread.c:288 [inline] btrfs_work_helper+0x96f/0xc40 fs/btrfs/async-thread.c:324 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3310 worker_thread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 </TASK>
Allocated by task 2: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:319 [inline] __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:345 kasan_slab_alloc include/linux/kasan.h:250 [inline] slab_post_alloc_hook mm/slub.c:4104 [inline] slab_alloc_node mm/slub.c:4153 [inline] kmem_cache_alloc_node_noprof+0x1d9/0x380 mm/slub.c:4205 alloc_task_struct_node kernel/fork.c:180 [inline] dup_task_struct+0x57/0x8c0 kernel/fork.c:1113 copy_process+0x5d1/0x3d50 kernel/fork.c:2225 kernel_clone+0x223/0x870 kernel/fork.c:2807 kernel_thread+0x1bc/0x240 kernel/fork.c:2869 create_kthread kernel/kthread.c:412 [inline] kthreadd+0x60d/0x810 kernel/kthread.c:767 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
Freed by task 24: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:582 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2338 [inline] slab_free mm/slub.c:4598 [inline] kmem_cache_free+0x195/0x410 mm/slub.c:4700 put_task_struct include/linux/sched/task.h:144 [inline] delayed_put_task_struct+0x125/0x300 kernel/exit.c:227 rcu_do_batch kernel/rcu/tree.c:2567 [inline] rcu_core+0xaaa/0x17a0 kernel/rcu/tree.c:2823 handle_softirqs+0x2d4/0x9b0 kernel/softirq.c:554 run_ksoftirqd+0xca/0x130 kernel/softirq.c:943
---truncated---(CVE-2024-57896)
In the Linux kernel, the following vulnerability has been resolved:
tomoyo: don't emit warning in tomoyo_write_control()
syzbot is reporting too large allocation warning at tomoyo_write_control(), for one can write a very very long line without new line character. To fix this warning, I use __GFP_NOWARN rather than checking for KMALLOC_MAX_SIZE, for practically a valid line should be always shorter than 32KB where the "too small to fail" memory-allocation rule applies.
One might try to write a valid line that is longer than 32KB, but such request will likely fail with -ENOMEM. Therefore, I feel that separately returning -EINVAL when a line is longer than KMALLOC_MAX_SIZE is redundant. There is no need to distinguish over-32KB and over-KMALLOC_MAX_SIZE.(CVE-2024-58085)
In the Linux kernel, the following vulnerability has been resolved:
sockmap, vsock: For connectible sockets allow only connected
sockmap expects all vsocks to have a transport assigned, which is expressed in vsock_proto::psock_update_sk_prot(). However, there is an edge case where an unconnected (connectible) socket may lose its previously assigned transport. This is handled with a NULL check in the vsock/BPF recv path.
Another design detail is that listening vsocks are not supposed to have any transport assigned at all. Which implies they are not supported by the sockmap. But this is complicated by the fact that a socket, before switching to TCP_LISTEN, may have had some transport assigned during a failed connect() attempt. Hence, we may end up with a listening vsock in a sockmap, which blows up quickly:
KASAN: null-ptr-deref in range [0x0000000000000120-0x0000000000000127] CPU: 7 UID: 0 PID: 56 Comm: kworker/7:0 Not tainted 6.14.0-rc1+ Workqueue: vsock-loopback vsock_loopback_work RIP: 0010:vsock_read_skb+0x4b/0x90 Call Trace: sk_psock_verdict_data_ready+0xa4/0x2e0 virtio_transport_recv_pkt+0x1ca8/0x2acc vsock_loopback_work+0x27d/0x3f0 process_one_work+0x846/0x1420 worker_thread+0x5b3/0xf80 kthread+0x35a/0x700 ret_from_fork+0x2d/0x70 ret_from_fork_asm+0x1a/0x30
For connectible sockets, instead of relying solely on the state of vsk->transport, tell sockmap to only allow those representing established connections. This aligns with the behaviour for AF_INET and AF_UNIX.(CVE-2025-21854)
In the Linux kernel, the following vulnerability has been resolved:
mm/migrate_device: don't add folio to be freed to LRU in migrate_device_finalize()
If migration succeeded, we called folio_migrate_flags()->mem_cgroup_migrate() to migrate the memcg from the old to the new folio. This will set memcg_data of the old folio to 0.
Similarly, if migration failed, memcg_data of the dst folio is left unset.
If we call folio_putback_lru() on such folios (memcg_data == 0), we will add the folio to be freed to the LRU, making memcg code unhappy. Running the hmm selftests:
# ./hmm-tests ... # RUN hmm.hmm_device_private.migrate ... [ 102.078007][T14893] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x7ff27d200 pfn:0x13cc00 [ 102.079974][T14893] anon flags: 0x17ff00000020018(uptodate|dirty|swapbacked|node=0|zone=2|lastcpupid=0x7ff) [ 102.082037][T14893] raw: 017ff00000020018 dead000000000100 dead000000000122 ffff8881353896c9 [ 102.083687][T14893] raw: 00000007ff27d200 0000000000000000 00000001ffffffff 0000000000000000 [ 102.085331][T14893] page dumped because: VM_WARN_ON_ONCE_FOLIO(!memcg && !mem_cgroup_disabled()) [ 102.087230][T14893] ------------[ cut here ]------------ [ 102.088279][T14893] WARNING: CPU: 0 PID: 14893 at ./include/linux/memcontrol.h:726 folio_lruvec_lock_irqsave+0x10e/0x170 [ 102.090478][T14893] Modules linked in: [ 102.091244][T14893] CPU: 0 UID: 0 PID: 14893 Comm: hmm-tests Not tainted 6.13.0-09623-g6c216bc522fd #151 [ 102.093089][T14893] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 [ 102.094848][T14893] RIP: 0010:folio_lruvec_lock_irqsave+0x10e/0x170 [ 102.096104][T14893] Code: ... [ 102.099908][T14893] RSP: 0018:ffffc900236c37b0 EFLAGS: 00010293 [ 102.101152][T14893] RAX: 0000000000000000 RBX: ffffea0004f30000 RCX: ffffffff8183f426 [ 102.102684][T14893] RDX: ffff8881063cb880 RSI: ffffffff81b8117f RDI: ffff8881063cb880 [ 102.104227][T14893] RBP: 0000000000000000 R08: 0000000000000005 R09: 0000000000000000 [ 102.105757][T14893] R10: 0000000000000001 R11: 0000000000000002 R12: ffffc900236c37d8 [ 102.107296][T14893] R13: ffff888277a2bcb0 R14: 000000000000001f R15: 0000000000000000 [ 102.108830][T14893] FS: 00007ff27dbdd740(0000) GS:ffff888277a00000(0000) knlGS:0000000000000000 [ 102.110643][T14893] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 102.111924][T14893] CR2: 00007ff27d400000 CR3: 000000010866e000 CR4: 0000000000750ef0 [ 102.113478][T14893] PKRU: 55555554 [ 102.114172][T14893] Call Trace: [ 102.114805][T14893] <TASK> [ 102.115397][T14893] ? folio_lruvec_lock_irqsave+0x10e/0x170 [ 102.116547][T14893] ? __warn.cold+0x110/0x210 [ 102.117461][T14893] ? folio_lruvec_lock_irqsave+0x10e/0x170 [ 102.118667][T14893] ? report_bug+0x1b9/0x320 [ 102.119571][T14893] ? handle_bug+0x54/0x90 [ 102.120494][T14893] ? exc_invalid_op+0x17/0x50 [ 102.121433][T14893] ? asm_exc_invalid_op+0x1a/0x20 [ 102.122435][T14893] ? __wake_up_klogd.part.0+0x76/0xd0 [ 102.123506][T14893] ? dump_page+0x4f/0x60 [ 102.124352][T14893] ? folio_lruvec_lock_irqsave+0x10e/0x170 [ 102.125500][T14893] folio_batch_move_lru+0xd4/0x200 [ 102.126577][T14893] ? __pfx_lru_add+0x10/0x10 [ 102.127505][T14893] __folio_batch_add_and_move+0x391/0x720 [ 102.128633][T14893] ? __pfx_lru_add+0x10/0x10 [ 102.129550][T14893] folio_putback_lru+0x16/0x80 [ 102.130564][T14893] migrate_device_finalize+0x9b/0x530 [ 102.131640][T14893] dmirror_migrate_to_device.constprop.0+0x7c5/0xad0 [ 102.133047][T14893] dmirror_fops_unlocked_ioctl+0x89b/0xc80
Likely, nothing else goes wrong: putting the last folio reference will remove the folio from the LRU again. So besides memcg complaining, adding the folio to be freed to the LRU is just an unnecessary step.
The new flow resembles what we have in migrate_folio_move(): add the dst to the lru, rem ---truncated---(CVE-2025-21861)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix bug on trap in smb2_lock
If lock count is greater than 1, flags could be old value. It should be checked with flags of smb_lock, not flags. It will cause bug-on trap from locks_free_lock in error handling routine.(CVE-2025-21944)
In the Linux kernel, the following vulnerability has been resolved:
drm/radeon: fix uninitialized size issue in radeon_vce_cs_parse()
On the off chance that command stream passed from userspace via ioctl() call to radeon_vce_cs_parse() is weirdly crafted and first command to execute is to encode (case 0x03000001), the function in question will attempt to call radeon_vce_cs_reloc() with size argument that has not been properly initialized. Specifically, 'size' will point to 'tmp' variable before the latter had a chance to be assigned any value.
Play it safe and init 'tmp' with 0, thus ensuring that radeon_vce_cs_reloc() will catch an early error in cases like these.
Found by Linux Verification Center (linuxtesting.org) with static analysis tool SVACE.
(cherry picked from commit 2d52de55f9ee7aaee0e09ac443f77855989c6b68)(CVE-2025-21996)
In the Linux kernel, the following vulnerability has been resolved:
tpm: do not start chip while suspended
Checking TPM_CHIP_FLAG_SUSPENDED after the call to tpm_find_get_ops() can lead to a spurious tpm_chip_start() call:
[35985.503771] i2c i2c-1: Transfer while suspended [35985.503796] WARNING: CPU: 0 PID: 74 at drivers/i2c/i2c-core.h:56 __i2c_transfer+0xbe/0x810 [35985.503802] Modules linked in: [35985.503808] CPU: 0 UID: 0 PID: 74 Comm: hwrng Tainted: G W 6.13.0-next-20250203-00005-gfa0cb5642941 #19 9c3d7f78192f2d38e32010ac9c90fdc71109ef6f [35985.503814] Tainted: [W]=WARN [35985.503817] Hardware name: Google Morphius/Morphius, BIOS Google_Morphius.13434.858.0 10/26/2023 [35985.503819] RIP: 0010:__i2c_transfer+0xbe/0x810 [35985.503825] Code: 30 01 00 00 4c 89 f7 e8 40 fe d8 ff 48 8b 93 80 01 00 00 48 85 d2 75 03 49 8b 16 48 c7 c7 0a fb 7c a7 48 89 c6 e8 32 ad b0 fe <0f> 0b b8 94 ff ff ff e9 33 04 00 00 be 02 00 00 00 83 fd 02 0f 5 [35985.503828] RSP: 0018:ffffa106c0333d30 EFLAGS: 00010246 [35985.503833] RAX: 074ba64aa20f7000 RBX: ffff8aa4c1167120 RCX: 0000000000000000 [35985.503836] RDX: 0000000000000000 RSI: ffffffffa77ab0e4 RDI: 0000000000000001 [35985.503838] RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000 [35985.503841] R10: 0000000000000004 R11: 00000001000313d5 R12: ffff8aa4c10f1820 [35985.503843] R13: ffff8aa4c0e243c0 R14: ffff8aa4c1167250 R15: ffff8aa4c1167120 [35985.503846] FS: 0000000000000000(0000) GS:ffff8aa4eae00000(0000) knlGS:0000000000000000 [35985.503849] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [35985.503852] CR2: 00007fab0aaf1000 CR3: 0000000105328000 CR4: 00000000003506f0 [35985.503855] Call Trace: [35985.503859] <TASK> [35985.503863] ? __warn+0xd4/0x260 [35985.503868] ? __i2c_transfer+0xbe/0x810 [35985.503874] ? report_bug+0xf3/0x210 [35985.503882] ? handle_bug+0x63/0xb0 [35985.503887] ? exc_invalid_op+0x16/0x50 [35985.503892] ? asm_exc_invalid_op+0x16/0x20 [35985.503904] ? __i2c_transfer+0xbe/0x810 [35985.503913] tpm_cr50_i2c_transfer_message+0x24/0xf0 [35985.503920] tpm_cr50_i2c_read+0x8e/0x120 [35985.503928] tpm_cr50_request_locality+0x75/0x170 [35985.503935] tpm_chip_start+0x116/0x160 [35985.503942] tpm_try_get_ops+0x57/0x90 [35985.503948] tpm_find_get_ops+0x26/0xd0 [35985.503955] tpm_get_random+0x2d/0x80
Don't move forward with tpm_chip_start() inside tpm_try_get_ops(), unless TPM_CHIP_FLAG_SUSPENDED is not set. tpm_find_get_ops() will return NULL in such a failure case.(CVE-2025-23149)
In the Linux kernel, the following vulnerability has been resolved:
KVM: arm64: Tear down vGIC on failed vCPU creation
If kvm_arch_vcpu_create() fails to share the vCPU page with the hypervisor, we propagate the error back to the ioctl but leave the vGIC vCPU data initialised. Note only does this leak the corresponding memory when the vCPU is destroyed but it can also lead to use-after-free if the redistributor device handling tries to walk into the vCPU.
Add the missing cleanup to kvm_arch_vcpu_create(), ensuring that the vGIC vCPU structures are destroyed on error.(CVE-2025-37849)
In the Linux kernel, the following vulnerability has been resolved:
drm/nouveau: Fix WARN_ON in nouveau_fence_context_kill()
Nouveau is mostly designed in a way that it's expected that fences only ever get signaled through nouveau_fence_signal(). However, in at least one other place, nouveau_fence_done(), can signal fences, too. If that happens (race) a signaled fence remains in the pending list for a while, until it gets removed by nouveau_fence_update().
Should nouveau_fence_context_kill() run in the meantime, this would be a bug because the function would attempt to set an error code on an already signaled fence.
Have nouveau_fence_context_kill() check for a fence being signaled.(CVE-2025-37930)
In the Linux kernel, the following vulnerability has been resolved:
objtool, media: dib8000: Prevent divide-by-zero in dib8000_set_dds()
If dib8000_set_dds()'s call to dib8000_read32() returns zero, the result is a divide-by-zero. Prevent that from happening.
Fixes the following warning with an UBSAN kernel:
drivers/media/dvb-frontends/dib8000.o: warning: objtool: dib8000_tune() falls through to next function dib8096p_cfg_DibRx()(CVE-2025-37937)
In the Linux kernel, the following vulnerability has been resolved:
arm64: bpf: Add BHB mitigation to the epilogue for cBPF programs
A malicious BPF program may manipulate the branch history to influence what the hardware speculates will happen next.
On exit from a BPF program, emit the BHB mititgation sequence.
This is only applied for 'classic' cBPF programs that are loaded by seccomp.(CVE-2025-37948)
In the Linux kernel, the following vulnerability has been resolved:
arm64: bpf: Only mitigate cBPF programs loaded by unprivileged users
Support for eBPF programs loaded by unprivileged users is typically disabled. This means only cBPF programs need to be mitigated for BHB.
In addition, only mitigate cBPF programs that were loaded by an unprivileged user. Privileged users can also load the same program via eBPF, making the mitigation pointless.(CVE-2025-37963)
In the Linux kernel, the following vulnerability has been resolved:
HID: uclogic: Add NULL check in uclogic_input_configured()
devm_kasprintf() returns NULL when memory allocation fails. Currently, uclogic_input_configured() does not check for this case, which results in a NULL pointer dereference.
Add NULL check after devm_kasprintf() to prevent this issue.(CVE-2025-38007)
In the Linux kernel, the following vulnerability has been resolved:
padata: do not leak refcount in reorder_work
A recent patch that addressed a UAF introduced a reference count leak: the parallel_data refcount is incremented unconditionally, regardless of the return value of queue_work(). If the work item is already queued, the incremented refcount is never decremented.
Fix this by checking the return value of queue_work() and decrementing the refcount when necessary.
Resolves:
Unreferenced object 0xffff9d9f421e3d80 (size 192): comm "cryptomgr_probe", pid 157, jiffies 4294694003 hex dump (first 32 bytes): 80 8b cf 41 9f 9d ff ff b8 97 e0 89 ff ff ff ff ...A............ d0 97 e0 89 ff ff ff ff 19 00 00 00 1f 88 23 00 ..............#. backtrace (crc 838fb36): __kmalloc_cache_noprof+0x284/0x320 padata_alloc_pd+0x20/0x1e0 padata_alloc_shell+0x3b/0xa0 0xffffffffc040a54d cryptomgr_probe+0x43/0xc0 kthread+0xf6/0x1f0 ret_from_fork+0x2f/0x50 ret_from_fork_asm+0x1a/0x30(CVE-2025-38031)
In the Linux kernel, the following vulnerability has been resolved:
btrfs: correct the order of prelim_ref arguments in btrfs__prelim_ref
btrfs_prelim_ref() calls the old and new reference variables in the incorrect order. This causes a NULL pointer dereference because oldref is passed as NULL to trace_btrfs_prelim_ref_insert().
Note, trace_btrfs_prelim_ref_insert() is being called with newref as oldref (and oldref as NULL) on purpose in order to print out the values of newref.
To reproduce: echo 1 > /sys/kernel/debug/tracing/events/btrfs/btrfs_prelim_ref_insert/enable
Perform some writeback operations.
Backtrace: BUG: kernel NULL pointer dereference, address: 0000000000000018 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 115949067 P4D 115949067 PUD 11594a067 PMD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 1 UID: 0 PID: 1188 Comm: fsstress Not tainted 6.15.0-rc2-tester+ #47 PREEMPT(voluntary) 7ca2cef72d5e9c600f0c7718adb6462de8149622 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-2-gc13ff2cd-prebuilt.qemu.org 04/01/2014 RIP: 0010:trace_event_raw_event_btrfs__prelim_ref+0x72/0x130 Code: e8 43 81 9f ff 48 85 c0 74 78 4d 85 e4 0f 84 8f 00 00 00 49 8b 94 24 c0 06 00 00 48 8b 0a 48 89 48 08 48 8b 52 08 48 89 50 10 <49> 8b 55 18 48 89 50 18 49 8b 55 20 48 89 50 20 41 0f b6 55 28 88 RSP: 0018:ffffce44820077a0 EFLAGS: 00010286 RAX: ffff8c6b403f9014 RBX: ffff8c6b55825730 RCX: 304994edf9cf506b RDX: d8b11eb7f0fdb699 RSI: ffff8c6b403f9010 RDI: ffff8c6b403f9010 RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000010 R10: 00000000ffffffff R11: 0000000000000000 R12: ffff8c6b4e8fb000 R13: 0000000000000000 R14: ffffce44820077a8 R15: ffff8c6b4abd1540 FS: 00007f4dc6813740(0000) GS:ffff8c6c1d378000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000018 CR3: 000000010eb42000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: <TASK> prelim_ref_insert+0x1c1/0x270 find_parent_nodes+0x12a6/0x1ee0 ? __entry_text_end+0x101f06/0x101f09 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 btrfs_is_data_extent_shared+0x167/0x640 ? fiemap_process_hole+0xd0/0x2c0 extent_fiemap+0xa5c/0xbc0 ? __entry_text_end+0x101f05/0x101f09 btrfs_fiemap+0x7e/0xd0 do_vfs_ioctl+0x425/0x9d0 __x64_sys_ioctl+0x75/0xc0(CVE-2025-38034)
In the Linux kernel, the following vulnerability has been resolved:
bpf: copy_verifier_state() should copy 'loop_entry' field
The bpf_verifier_state.loop_entry state should be copied by copy_verifier_state(). Otherwise, .loop_entry values from unrelated states would poison env->cur_state.
Additionally, env->stack should not contain any states with .loop_entry != NULL. The states in env->stack are yet to be verified, while .loop_entry is set for states that reached an equivalent state. This means that env->cur_state->loop_entry should always be NULL after pop_stack().
See the selftest in the next commit for an example of the program that is not safe yet is accepted by verifier w/o this fix.
This change has some verification performance impact for selftests:
File Program Insns (A) Insns (B) Insns (DIFF) States (A) States (B) States (DIFF)
arena_htab.bpf.o arena_htab_llvm 717 426 -291 (-40.59%) 57 37 -20 (-35.09%) arena_htab_asm.bpf.o arena_htab_asm 597 445 -152 (-25.46%) 47 37 -10 (-21.28%) arena_list.bpf.o arena_list_del 309 279 -30 (-9.71%) 23 14 -9 (-39.13%) iters.bpf.o iter_subprog_check_stacksafe 155 141 -14 (-9.03%) 15 14 -1 (-6.67%) iters.bpf.o iter_subprog_iters 1094 1003 -91 (-8.32%) 88 83 -5 (-5.68%) iters.bpf.o loop_state_deps2 479 725 +246 (+51.36%) 46 63 +17 (+36.96%) kmem_cache_iter.bpf.o open_coded_iter 63 59 -4 (-6.35%) 7 6 -1 (-14.29%) verifier_bits_iter.bpf.o max_words 92 84 -8 (-8.70%) 8 7 -1 (-12.50%) verifier_iterating_callbacks.bpf.o cond_break2 113 107 -6 (-5.31%) 12 12 +0 (+0.00%)
And significant negative impact for sched_ext:
File Program Insns (A) Insns (B) Insns (DIFF) States (A) States (B) States (DIFF)
bpf.bpf.o lavd_init 7039 14723 +7684 (+109.16%) 490 1139 +649 (+132.45%)
bpf.bpf.o layered_dispatch 11485 10548 -937 (-8.16%) 848 762 -86 (-10.14%)
bpf.bpf.o layered_dump 7422 1000001 +992579 (+13373.47%) 681 31178 +30497 (+4478.27%)
bpf.bpf.o layered_enqueue 16854 71127 +54273 (+322.02%) 1611 6450 +4839 (+300.37%)
bpf.bpf.o p2dq_dispatch 665 791 +126 (+18.95%) 68 78 +10 (+14.71%)
bpf.bpf.o p2dq_init 2343 2980 +637 (+27.19%) 201 237 +36 (+17.91%)
bpf.bpf.o refresh_layer_cpumasks 16487 674760 +658273 (+3992.68%) 1770 65370 +63600 (+3593.22%)
bpf.bpf.o rusty_select_cpu 1937 40872 +38935 (+2010.07%) 177 3210 +3033 (+1713.56%)
scx_central.bpf.o central_dispatch 636 2687 +2051 (+322.48%) 63 227 +164 (+260.32%)
scx_nest.bpf.o nest_init 636 815 +179 (+28.14%) 60 73 +13 (+21.67%)
scx_qmap.bpf.o qmap_dispatch
---truncated---(CVE-2025-38060)
In the Linux kernel, the following vulnerability has been resolved:
orangefs: Do not truncate file size
'len' is used to store the result of i_size_read(), so making 'len' a size_t results in truncation to 4GiB on 32-bit systems.(CVE-2025-38065)
In the Linux kernel, the following vulnerability has been resolved:
vhost-scsi: protect vq->log_used with vq->mutex
The vhost-scsi completion path may access vq->log_base when vq->log_used is already set to false.
vhost-thread QEMU-thread
vhost_scsi_complete_cmd_work() -> vhost_add_used() -> vhost_add_used_n() if (unlikely(vq->log_used)) QEMU disables vq->log_used via VHOST_SET_VRING_ADDR. mutex_lock(&vq->mutex); vq->log_used = false now! mutex_unlock(&vq->mutex);
QEMU gfree(vq->log_base)
log_used()
-> log_write(vq->log_base)
Assuming the VMM is QEMU. The vq->log_base is from QEMU userpace and can be reclaimed via gfree(). As a result, this causes invalid memory writes to QEMU userspace.
The control queue path has the same issue.(CVE-2025-38074)
In the Linux kernel, the following vulnerability has been resolved:
ALSA: pcm: Fix race of buffer access at PCM OSS layer
The PCM OSS layer tries to clear the buffer with the silence data at initialization (or reconfiguration) of a stream with the explicit call of snd_pcm_format_set_silence() with runtime->dma_area. But this may lead to a UAF because the accessed runtime->dma_area might be freed concurrently, as it's performed outside the PCM ops.
For avoiding it, move the code into the PCM core and perform it inside the buffer access lock, so that it won't be changed during the operation.(CVE-2025-38078)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Increase block_sequence array size
[Why] It's possible to generate more than 50 steps in hwss_build_fast_sequence, for example with a 6-pipe asic where all pipes are in one MPC chain. This overflows the block_sequence buffer and corrupts block_sequence_steps, causing a crash.
[How] Expand block_sequence to 100 items. A naive upper bound on the possible number of steps for a 6-pipe asic, ignoring the potential for steps to be mutually exclusive, is 91 with current code, therefore 100 is sufficient.(CVE-2025-38080)
In the Linux kernel, the following vulnerability has been resolved:
remoteproc: core: Clear table_sz when rproc_shutdown
There is case as below could trigger kernel dump: Use U-Boot to start remote processor(rproc) with resource table published to a fixed address by rproc. After Kernel boots up, stop the rproc, load a new firmware which doesn't have resource table ,and start rproc.
When starting rproc with a firmware not have resource table,
memcpy(loaded_table, rproc->cached_table, rproc->table_sz) will
trigger dump, because rproc->cache_table is set to NULL during the last
stop operation, but rproc->table_sz is still valid.
This issue is found on i.MX8MP and i.MX9.
Dump as below: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=000000010af63000 [0000000000000000] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP Modules linked in: CPU: 2 UID: 0 PID: 1060 Comm: sh Not tainted 6.14.0-rc7-next-20250317-dirty #38 Hardware name: NXP i.MX8MPlus EVK board (DT) pstate: a0000005 (NzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __pi_memcpy_generic+0x110/0x22c lr : rproc_start+0x88/0x1e0 Call trace: __pi_memcpy_generic+0x110/0x22c (P) rproc_boot+0x198/0x57c state_store+0x40/0x104 dev_attr_store+0x18/0x2c sysfs_kf_write+0x7c/0x94 kernfs_fop_write_iter+0x120/0x1cc vfs_write+0x240/0x378 ksys_write+0x70/0x108 __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x10c el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x30/0xcc el0t_64_sync_handler+0x10c/0x138 el0t_64_sync+0x198/0x19c
Clear rproc->table_sz to address the issue.(CVE-2025-38152)
In the Linux kernel, the following vulnerability has been resolved:
jfs: fix slab-out-of-bounds read in ea_get()
During the "size_check" label in ea_get(), the code checks if the extended attribute list (xattr) size matches ea_size. If not, it logs "ea_get: invalid extended attribute" and calls print_hex_dump().
Here, EALIST_SIZE(ea_buf->xattr) returns 4110417968, which exceeds INT_MAX (2,147,483,647). Then ea_size is clamped:
int size = clamp_t(int, ea_size, 0, EALIST_SIZE(ea_buf->xattr));
Although clamp_t aims to bound ea_size between 0 and 4110417968, the upper limit is treated as an int, causing an overflow above 2^31 - 1. This leads "size" to wrap around and become negative (-184549328).
The "size" is then passed to print_hex_dump() (called "len" in print_hex_dump()), it is passed as type size_t (an unsigned type), this is then stored inside a variable called "int remaining", which is then assigned to "int linelen" which is then passed to hex_dump_to_buffer(). In print_hex_dump() the for loop, iterates through 0 to len-1, where len is 18446744073525002176, calling hex_dump_to_buffer() on each iteration:
for (i = 0; i < len; i += rowsize) {
linelen = min(remaining, rowsize);
remaining -= rowsize;
hex_dump_to_buffer(ptr + i, linelen, rowsize, groupsize,
linebuf, sizeof(linebuf), ascii);
...
}
The expected stopping condition (i < len) is effectively broken since len is corrupted and very large. This eventually leads to the "ptr+i" being passed to hex_dump_to_buffer() to get closer to the end of the actual bounds of "ptr", eventually an out of bounds access is done in hex_dump_to_buffer() in the following for loop:
for (j = 0; j < len; j++) {
if (linebuflen < lx + 2)
goto overflow2;
ch = ptr[j];
...
}
To fix this we should validate "EALIST_SIZE(ea_buf->xattr)" before it is utilised.(CVE-2025-39735)
In the Linux kernel, the following vulnerability has been resolved:
objtool, spi: amd: Fix out-of-bounds stack access in amd_set_spi_freq()
If speed_hz < AMD_SPI_MIN_HZ, amd_set_spi_freq() iterates over the entire amd_spi_freq array without breaking out early, causing 'i' to go beyond the array bounds.
Fix that by stopping the loop when it gets to the last entry, so the low speed_hz value gets clamped up to AMD_SPI_MIN_HZ.
Fixes the following warning with an UBSAN kernel:
drivers/spi/spi-amd.o: error: objtool: amd_set_spi_freq() falls through to next function amd_spi_set_opcode()(CVE-2025-40014)
In the Linux kernel, the following vulnerability has been resolved:
io_uring: fix io_req_prep_async with provided buffers
io_req_prep_async() can import provided buffers, commit the ring state by giving up on that before, it'll be reimported later if needed.(CVE-2025-40364)
| URL | Type | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-6.6.0-99.0.0.91.oe2403.aarch64.rpm",
"bpftool-debuginfo-6.6.0-99.0.0.91.oe2403.aarch64.rpm",
"kernel-6.6.0-99.0.0.91.oe2403.aarch64.rpm",
"kernel-debuginfo-6.6.0-99.0.0.91.oe2403.aarch64.rpm",
"kernel-debugsource-6.6.0-99.0.0.91.oe2403.aarch64.rpm",
"kernel-devel-6.6.0-99.0.0.91.oe2403.aarch64.rpm",
"kernel-headers-6.6.0-99.0.0.91.oe2403.aarch64.rpm",
"kernel-source-6.6.0-99.0.0.91.oe2403.aarch64.rpm",
"kernel-tools-6.6.0-99.0.0.91.oe2403.aarch64.rpm",
"kernel-tools-debuginfo-6.6.0-99.0.0.91.oe2403.aarch64.rpm",
"kernel-tools-devel-6.6.0-99.0.0.91.oe2403.aarch64.rpm",
"perf-6.6.0-99.0.0.91.oe2403.aarch64.rpm",
"perf-debuginfo-6.6.0-99.0.0.91.oe2403.aarch64.rpm",
"python3-perf-6.6.0-99.0.0.91.oe2403.aarch64.rpm",
"python3-perf-debuginfo-6.6.0-99.0.0.91.oe2403.aarch64.rpm"
],
"src": [
"kernel-6.6.0-99.0.0.91.oe2403.src.rpm"
],
"x86_64": [
"bpftool-6.6.0-99.0.0.91.oe2403.x86_64.rpm",
"bpftool-debuginfo-6.6.0-99.0.0.91.oe2403.x86_64.rpm",
"kernel-6.6.0-99.0.0.91.oe2403.x86_64.rpm",
"kernel-debuginfo-6.6.0-99.0.0.91.oe2403.x86_64.rpm",
"kernel-debugsource-6.6.0-99.0.0.91.oe2403.x86_64.rpm",
"kernel-devel-6.6.0-99.0.0.91.oe2403.x86_64.rpm",
"kernel-headers-6.6.0-99.0.0.91.oe2403.x86_64.rpm",
"kernel-source-6.6.0-99.0.0.91.oe2403.x86_64.rpm",
"kernel-tools-6.6.0-99.0.0.91.oe2403.x86_64.rpm",
"kernel-tools-debuginfo-6.6.0-99.0.0.91.oe2403.x86_64.rpm",
"kernel-tools-devel-6.6.0-99.0.0.91.oe2403.x86_64.rpm",
"perf-6.6.0-99.0.0.91.oe2403.x86_64.rpm",
"perf-debuginfo-6.6.0-99.0.0.91.oe2403.x86_64.rpm",
"python3-perf-6.6.0-99.0.0.91.oe2403.x86_64.rpm",
"python3-perf-debuginfo-6.6.0-99.0.0.91.oe2403.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:24.03-LTS",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.6.0-99.0.0.91.oe2403"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:genirq/irqdesc: Prevent use-after-free in irq_find_at_or_after()irq_find_at_or_after() dereferences the interrupt descriptor which isreturned by mt_find() while neither holding sparse_irq_lock nor RCU readlock, which means the descriptor can be freed between mt_find() and thedereference: CPU0 CPU1 desc = mt_find() delayed_free_desc(desc) irq_desc_get_irq(desc)The use-after-free is reported by KASAN: Call trace: irq_get_next_irq+0x58/0x84 show_stat+0x638/0x824 seq_read_iter+0x158/0x4ec proc_reg_read_iter+0x94/0x12c vfs_read+0x1e0/0x2c8 Freed by task 4471: slab_free_freelist_hook+0x174/0x1e0 __kmem_cache_free+0xa4/0x1dc kfree+0x64/0x128 irq_kobj_release+0x28/0x3c kobject_put+0xcc/0x1e0 delayed_free_desc+0x14/0x2c rcu_do_batch+0x214/0x720Guard the access with a RCU read lock section.(CVE-2024-38385)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/lima: fix shared irq handling on driver remove\n\nlima uses a shared interrupt, so the interrupt handlers must be prepared\nto be called at any time. At driver removal time, the clocks are\ndisabled early and the interrupts stay registered until the very end of\nthe remove process due to the devm usage.\nThis is potentially a bug as the interrupts access device registers\nwhich assumes clocks are enabled. A crash can be triggered by removing\nthe driver in a kernel with CONFIG_DEBUG_SHIRQ enabled.\nThis patch frees the interrupts at each lima device finishing callback\nso that the handlers are already unregistered by the time we fully\ndisable clocks.(CVE-2024-42127)\n\nIn the Linux kernel, the following vulnerability has been resolved:mm: avoid overflows in dirty throttling logicThe dirty throttling logic is interspersed with assumptions that dirtylimits in PAGE_SIZE units fit into 32-bit (so that various multiplicationsfit into 64-bits). If limits end up being larger, we will hit overflows,possible divisions by 0 etc. Fix these problems by never allowing solarge dirty limits as they have dubious practical value anyway. Fordirty_bytes / dirty_background_bytes interfaces we can just refuse to setso large limits. For dirty_ratio / dirty_background_ratio it isn t sosimple as the dirty limit is computed from the amount of available memorywhich can change due to memory hotplug etc. So when converting dirtylimits from ratios to numbers of pages, we just don t allow the result toexceed UINT_MAX.This is root-only triggerable problem which occurs when the operatorsets dirty limits to \u0026gt;16 TB.(CVE-2024-42131)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/msm/dpu: move dpu_encoder\u0026apos;s connector assignment to atomic_enable()\n\nFor cases where the crtc\u0026apos;s connectors_changed was set without enable/active\ngetting toggled , there is an atomic_enable() call followed by an\natomic_disable() but without an atomic_mode_set().\n\nThis results in a NULL ptr access for the dpu_encoder_get_drm_fmt() call in\nthe atomic_enable() as the dpu_encoder\u0026apos;s connector was cleared in the\natomic_disable() but not re-assigned as there was no atomic_mode_set() call.\n\nFix the NULL ptr access by moving the assignment for atomic_enable() and also\nuse drm_atomic_get_new_connector_for_encoder() to get the connector from\nthe atomic_state.\n\nPatchwork: https://patchwork.freedesktop.org/patch/606729/(CVE-2024-45015)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: iaa - Fix potential use after free bug\n\nThe free_device_compression_mode(iaa_device, device_mode) function frees\n\u0026quot;device_mode\u0026quot; but it iss passed to iaa_compression_modes[i]-\u0026gt;free() a few\nlines later resulting in a use after free.\n\nThe good news is that, so far as I can tell, nothing implements the\n-\u0026gt;free() function and the use after free happens in dead code. But, with\nthis fix, when something does implement it, we\u0026apos;ll be ready. :)(CVE-2024-47732)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: flush delalloc workers queue before stopping cleaner kthread during unmount\n\nDuring the unmount path, at close_ctree(), we first stop the cleaner\nkthread, using kthread_stop() which frees the associated task_struct, and\nthen stop and destroy all the work queues. However after we stopped the\ncleaner we may still have a worker from the delalloc_workers queue running\ninode.c:submit_compressed_extents(), which calls btrfs_add_delayed_iput(),\nwhich in turn tries to wake up the cleaner kthread - which was already\ndestroyed before, resulting in a use-after-free on the task_struct.\n\nSyzbot reported this with the following stack traces:\n\n BUG: KASAN: slab-use-after-free in __lock_acquire+0x78/0x2100 kernel/locking/lockdep.c:5089\n Read of size 8 at addr ffff8880259d2818 by task kworker/u8:3/52\n\n CPU: 1 UID: 0 PID: 52 Comm: kworker/u8:3 Not tainted 6.13.0-rc1-syzkaller-00002-gcdd30ebb1b9f #0\n Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024\n Workqueue: btrfs-delalloc btrfs_work_helper\n Call Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:378 [inline]\n print_report+0x169/0x550 mm/kasan/report.c:489\n kasan_report+0x143/0x180 mm/kasan/report.c:602\n __lock_acquire+0x78/0x2100 kernel/locking/lockdep.c:5089\n lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5849\n __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]\n _raw_spin_lock_irqsave+0xd5/0x120 kernel/locking/spinlock.c:162\n class_raw_spinlock_irqsave_constructor include/linux/spinlock.h:551 [inline]\n try_to_wake_up+0xc2/0x1470 kernel/sched/core.c:4205\n submit_compressed_extents+0xdf/0x16e0 fs/btrfs/inode.c:1615\n run_ordered_work fs/btrfs/async-thread.c:288 [inline]\n btrfs_work_helper+0x96f/0xc40 fs/btrfs/async-thread.c:324\n process_one_work kernel/workqueue.c:3229 [inline]\n process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3310\n worker_thread+0x870/0xd30 kernel/workqueue.c:3391\n kthread+0x2f0/0x390 kernel/kthread.c:389\n ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244\n \u0026lt;/TASK\u0026gt;\n\n Allocated by task 2:\n kasan_save_stack mm/kasan/common.c:47 [inline]\n kasan_save_track+0x3f/0x80 mm/kasan/common.c:68\n unpoison_slab_object mm/kasan/common.c:319 [inline]\n __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:345\n kasan_slab_alloc include/linux/kasan.h:250 [inline]\n slab_post_alloc_hook mm/slub.c:4104 [inline]\n slab_alloc_node mm/slub.c:4153 [inline]\n kmem_cache_alloc_node_noprof+0x1d9/0x380 mm/slub.c:4205\n alloc_task_struct_node kernel/fork.c:180 [inline]\n dup_task_struct+0x57/0x8c0 kernel/fork.c:1113\n copy_process+0x5d1/0x3d50 kernel/fork.c:2225\n kernel_clone+0x223/0x870 kernel/fork.c:2807\n kernel_thread+0x1bc/0x240 kernel/fork.c:2869\n create_kthread kernel/kthread.c:412 [inline]\n kthreadd+0x60d/0x810 kernel/kthread.c:767\n ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244\n\n Freed by task 24:\n kasan_save_stack mm/kasan/common.c:47 [inline]\n kasan_save_track+0x3f/0x80 mm/kasan/common.c:68\n kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:582\n poison_slab_object mm/kasan/common.c:247 [inline]\n __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264\n kasan_slab_free include/linux/kasan.h:233 [inline]\n slab_free_hook mm/slub.c:2338 [inline]\n slab_free mm/slub.c:4598 [inline]\n kmem_cache_free+0x195/0x410 mm/slub.c:4700\n put_task_struct include/linux/sched/task.h:144 [inline]\n delayed_put_task_struct+0x125/0x300 kernel/exit.c:227\n rcu_do_batch kernel/rcu/tree.c:2567 [inline]\n rcu_core+0xaaa/0x17a0 kernel/rcu/tree.c:2823\n handle_softirqs+0x2d4/0x9b0 kernel/softirq.c:554\n run_ksoftirqd+0xca/0x130 kernel/softirq.c:943\n \n---truncated---(CVE-2024-57896)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntomoyo: don\u0026apos;t emit warning in tomoyo_write_control()\n\nsyzbot is reporting too large allocation warning at tomoyo_write_control(),\nfor one can write a very very long line without new line character. To fix\nthis warning, I use __GFP_NOWARN rather than checking for KMALLOC_MAX_SIZE,\nfor practically a valid line should be always shorter than 32KB where the\n\u0026quot;too small to fail\u0026quot; memory-allocation rule applies.\n\nOne might try to write a valid line that is longer than 32KB, but such\nrequest will likely fail with -ENOMEM. Therefore, I feel that separately\nreturning -EINVAL when a line is longer than KMALLOC_MAX_SIZE is redundant.\nThere is no need to distinguish over-32KB and over-KMALLOC_MAX_SIZE.(CVE-2024-58085)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsockmap, vsock: For connectible sockets allow only connected\n\nsockmap expects all vsocks to have a transport assigned, which is expressed\nin vsock_proto::psock_update_sk_prot(). However, there is an edge case\nwhere an unconnected (connectible) socket may lose its previously assigned\ntransport. This is handled with a NULL check in the vsock/BPF recv path.\n\nAnother design detail is that listening vsocks are not supposed to have any\ntransport assigned at all. Which implies they are not supported by the\nsockmap. But this is complicated by the fact that a socket, before\nswitching to TCP_LISTEN, may have had some transport assigned during a\nfailed connect() attempt. Hence, we may end up with a listening vsock in a\nsockmap, which blows up quickly:\n\nKASAN: null-ptr-deref in range [0x0000000000000120-0x0000000000000127]\nCPU: 7 UID: 0 PID: 56 Comm: kworker/7:0 Not tainted 6.14.0-rc1+\nWorkqueue: vsock-loopback vsock_loopback_work\nRIP: 0010:vsock_read_skb+0x4b/0x90\nCall Trace:\n sk_psock_verdict_data_ready+0xa4/0x2e0\n virtio_transport_recv_pkt+0x1ca8/0x2acc\n vsock_loopback_work+0x27d/0x3f0\n process_one_work+0x846/0x1420\n worker_thread+0x5b3/0xf80\n kthread+0x35a/0x700\n ret_from_fork+0x2d/0x70\n ret_from_fork_asm+0x1a/0x30\n\nFor connectible sockets, instead of relying solely on the state of\nvsk-\u0026gt;transport, tell sockmap to only allow those representing established\nconnections. This aligns with the behaviour for AF_INET and AF_UNIX.(CVE-2025-21854)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/migrate_device: don\u0026apos;t add folio to be freed to LRU in migrate_device_finalize()\n\nIf migration succeeded, we called\nfolio_migrate_flags()-\u0026gt;mem_cgroup_migrate() to migrate the memcg from the\nold to the new folio. This will set memcg_data of the old folio to 0.\n\nSimilarly, if migration failed, memcg_data of the dst folio is left unset.\n\nIf we call folio_putback_lru() on such folios (memcg_data == 0), we will\nadd the folio to be freed to the LRU, making memcg code unhappy. Running\nthe hmm selftests:\n\n # ./hmm-tests\n ...\n # RUN hmm.hmm_device_private.migrate ...\n [ 102.078007][T14893] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x7ff27d200 pfn:0x13cc00\n [ 102.079974][T14893] anon flags: 0x17ff00000020018(uptodate|dirty|swapbacked|node=0|zone=2|lastcpupid=0x7ff)\n [ 102.082037][T14893] raw: 017ff00000020018 dead000000000100 dead000000000122 ffff8881353896c9\n [ 102.083687][T14893] raw: 00000007ff27d200 0000000000000000 00000001ffffffff 0000000000000000\n [ 102.085331][T14893] page dumped because: VM_WARN_ON_ONCE_FOLIO(!memcg \u0026amp;\u0026amp; !mem_cgroup_disabled())\n [ 102.087230][T14893] ------------[ cut here ]------------\n [ 102.088279][T14893] WARNING: CPU: 0 PID: 14893 at ./include/linux/memcontrol.h:726 folio_lruvec_lock_irqsave+0x10e/0x170\n [ 102.090478][T14893] Modules linked in:\n [ 102.091244][T14893] CPU: 0 UID: 0 PID: 14893 Comm: hmm-tests Not tainted 6.13.0-09623-g6c216bc522fd #151\n [ 102.093089][T14893] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014\n [ 102.094848][T14893] RIP: 0010:folio_lruvec_lock_irqsave+0x10e/0x170\n [ 102.096104][T14893] Code: ...\n [ 102.099908][T14893] RSP: 0018:ffffc900236c37b0 EFLAGS: 00010293\n [ 102.101152][T14893] RAX: 0000000000000000 RBX: ffffea0004f30000 RCX: ffffffff8183f426\n [ 102.102684][T14893] RDX: ffff8881063cb880 RSI: ffffffff81b8117f RDI: ffff8881063cb880\n [ 102.104227][T14893] RBP: 0000000000000000 R08: 0000000000000005 R09: 0000000000000000\n [ 102.105757][T14893] R10: 0000000000000001 R11: 0000000000000002 R12: ffffc900236c37d8\n [ 102.107296][T14893] R13: ffff888277a2bcb0 R14: 000000000000001f R15: 0000000000000000\n [ 102.108830][T14893] FS: 00007ff27dbdd740(0000) GS:ffff888277a00000(0000) knlGS:0000000000000000\n [ 102.110643][T14893] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n [ 102.111924][T14893] CR2: 00007ff27d400000 CR3: 000000010866e000 CR4: 0000000000750ef0\n [ 102.113478][T14893] PKRU: 55555554\n [ 102.114172][T14893] Call Trace:\n [ 102.114805][T14893] \u0026lt;TASK\u0026gt;\n [ 102.115397][T14893] ? folio_lruvec_lock_irqsave+0x10e/0x170\n [ 102.116547][T14893] ? __warn.cold+0x110/0x210\n [ 102.117461][T14893] ? folio_lruvec_lock_irqsave+0x10e/0x170\n [ 102.118667][T14893] ? report_bug+0x1b9/0x320\n [ 102.119571][T14893] ? handle_bug+0x54/0x90\n [ 102.120494][T14893] ? exc_invalid_op+0x17/0x50\n [ 102.121433][T14893] ? asm_exc_invalid_op+0x1a/0x20\n [ 102.122435][T14893] ? __wake_up_klogd.part.0+0x76/0xd0\n [ 102.123506][T14893] ? dump_page+0x4f/0x60\n [ 102.124352][T14893] ? folio_lruvec_lock_irqsave+0x10e/0x170\n [ 102.125500][T14893] folio_batch_move_lru+0xd4/0x200\n [ 102.126577][T14893] ? __pfx_lru_add+0x10/0x10\n [ 102.127505][T14893] __folio_batch_add_and_move+0x391/0x720\n [ 102.128633][T14893] ? __pfx_lru_add+0x10/0x10\n [ 102.129550][T14893] folio_putback_lru+0x16/0x80\n [ 102.130564][T14893] migrate_device_finalize+0x9b/0x530\n [ 102.131640][T14893] dmirror_migrate_to_device.constprop.0+0x7c5/0xad0\n [ 102.133047][T14893] dmirror_fops_unlocked_ioctl+0x89b/0xc80\n\nLikely, nothing else goes wrong: putting the last folio reference will\nremove the folio from the LRU again. So besides memcg complaining, adding\nthe folio to be freed to the LRU is just an unnecessary step.\n\nThe new flow resembles what we have in migrate_folio_move(): add the dst\nto the lru, rem\n---truncated---(CVE-2025-21861)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix bug on trap in smb2_lock\n\nIf lock count is greater than 1, flags could be old value.\nIt should be checked with flags of smb_lock, not flags.\nIt will cause bug-on trap from locks_free_lock in error handling\nroutine.(CVE-2025-21944)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/radeon: fix uninitialized size issue in radeon_vce_cs_parse()\n\nOn the off chance that command stream passed from userspace via\nioctl() call to radeon_vce_cs_parse() is weirdly crafted and\nfirst command to execute is to encode (case 0x03000001), the function\nin question will attempt to call radeon_vce_cs_reloc() with size\nargument that has not been properly initialized. Specifically, \u0026apos;size\u0026apos;\nwill point to \u0026apos;tmp\u0026apos; variable before the latter had a chance to be\nassigned any value.\n\nPlay it safe and init \u0026apos;tmp\u0026apos; with 0, thus ensuring that\nradeon_vce_cs_reloc() will catch an early error in cases like these.\n\nFound by Linux Verification Center (linuxtesting.org) with static\nanalysis tool SVACE.\n\n(cherry picked from commit 2d52de55f9ee7aaee0e09ac443f77855989c6b68)(CVE-2025-21996)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntpm: do not start chip while suspended\n\nChecking TPM_CHIP_FLAG_SUSPENDED after the call to tpm_find_get_ops() can\nlead to a spurious tpm_chip_start() call:\n\n[35985.503771] i2c i2c-1: Transfer while suspended\n[35985.503796] WARNING: CPU: 0 PID: 74 at drivers/i2c/i2c-core.h:56 __i2c_transfer+0xbe/0x810\n[35985.503802] Modules linked in:\n[35985.503808] CPU: 0 UID: 0 PID: 74 Comm: hwrng Tainted: G W 6.13.0-next-20250203-00005-gfa0cb5642941 #19 9c3d7f78192f2d38e32010ac9c90fdc71109ef6f\n[35985.503814] Tainted: [W]=WARN\n[35985.503817] Hardware name: Google Morphius/Morphius, BIOS Google_Morphius.13434.858.0 10/26/2023\n[35985.503819] RIP: 0010:__i2c_transfer+0xbe/0x810\n[35985.503825] Code: 30 01 00 00 4c 89 f7 e8 40 fe d8 ff 48 8b 93 80 01 00 00 48 85 d2 75 03 49 8b 16 48 c7 c7 0a fb 7c a7 48 89 c6 e8 32 ad b0 fe \u0026lt;0f\u0026gt; 0b b8 94 ff ff ff e9 33 04 00 00 be 02 00 00 00 83 fd 02 0f 5\n[35985.503828] RSP: 0018:ffffa106c0333d30 EFLAGS: 00010246\n[35985.503833] RAX: 074ba64aa20f7000 RBX: ffff8aa4c1167120 RCX: 0000000000000000\n[35985.503836] RDX: 0000000000000000 RSI: ffffffffa77ab0e4 RDI: 0000000000000001\n[35985.503838] RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000\n[35985.503841] R10: 0000000000000004 R11: 00000001000313d5 R12: ffff8aa4c10f1820\n[35985.503843] R13: ffff8aa4c0e243c0 R14: ffff8aa4c1167250 R15: ffff8aa4c1167120\n[35985.503846] FS: 0000000000000000(0000) GS:ffff8aa4eae00000(0000) knlGS:0000000000000000\n[35985.503849] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[35985.503852] CR2: 00007fab0aaf1000 CR3: 0000000105328000 CR4: 00000000003506f0\n[35985.503855] Call Trace:\n[35985.503859] \u0026lt;TASK\u0026gt;\n[35985.503863] ? __warn+0xd4/0x260\n[35985.503868] ? __i2c_transfer+0xbe/0x810\n[35985.503874] ? report_bug+0xf3/0x210\n[35985.503882] ? handle_bug+0x63/0xb0\n[35985.503887] ? exc_invalid_op+0x16/0x50\n[35985.503892] ? asm_exc_invalid_op+0x16/0x20\n[35985.503904] ? __i2c_transfer+0xbe/0x810\n[35985.503913] tpm_cr50_i2c_transfer_message+0x24/0xf0\n[35985.503920] tpm_cr50_i2c_read+0x8e/0x120\n[35985.503928] tpm_cr50_request_locality+0x75/0x170\n[35985.503935] tpm_chip_start+0x116/0x160\n[35985.503942] tpm_try_get_ops+0x57/0x90\n[35985.503948] tpm_find_get_ops+0x26/0xd0\n[35985.503955] tpm_get_random+0x2d/0x80\n\nDon\u0026apos;t move forward with tpm_chip_start() inside tpm_try_get_ops(), unless\nTPM_CHIP_FLAG_SUSPENDED is not set. tpm_find_get_ops() will return NULL in\nsuch a failure case.(CVE-2025-23149)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: arm64: Tear down vGIC on failed vCPU creation\n\nIf kvm_arch_vcpu_create() fails to share the vCPU page with the\nhypervisor, we propagate the error back to the ioctl but leave the\nvGIC vCPU data initialised. Note only does this leak the corresponding\nmemory when the vCPU is destroyed but it can also lead to use-after-free\nif the redistributor device handling tries to walk into the vCPU.\n\nAdd the missing cleanup to kvm_arch_vcpu_create(), ensuring that the\nvGIC vCPU structures are destroyed on error.(CVE-2025-37849)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/nouveau: Fix WARN_ON in nouveau_fence_context_kill()\n\nNouveau is mostly designed in a way that it\u0026apos;s expected that fences only\never get signaled through nouveau_fence_signal(). However, in at least\none other place, nouveau_fence_done(), can signal fences, too. If that\nhappens (race) a signaled fence remains in the pending list for a while,\nuntil it gets removed by nouveau_fence_update().\n\nShould nouveau_fence_context_kill() run in the meantime, this would be\na bug because the function would attempt to set an error code on an\nalready signaled fence.\n\nHave nouveau_fence_context_kill() check for a fence being signaled.(CVE-2025-37930)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nobjtool, media: dib8000: Prevent divide-by-zero in dib8000_set_dds()\n\nIf dib8000_set_dds()\u0026apos;s call to dib8000_read32() returns zero, the result\nis a divide-by-zero. Prevent that from happening.\n\nFixes the following warning with an UBSAN kernel:\n\n drivers/media/dvb-frontends/dib8000.o: warning: objtool: dib8000_tune() falls through to next function dib8096p_cfg_DibRx()(CVE-2025-37937)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\narm64: bpf: Add BHB mitigation to the epilogue for cBPF programs\n\nA malicious BPF program may manipulate the branch history to influence\nwhat the hardware speculates will happen next.\n\nOn exit from a BPF program, emit the BHB mititgation sequence.\n\nThis is only applied for \u0026apos;classic\u0026apos; cBPF programs that are loaded by\nseccomp.(CVE-2025-37948)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\narm64: bpf: Only mitigate cBPF programs loaded by unprivileged users\n\nSupport for eBPF programs loaded by unprivileged users is typically\ndisabled. This means only cBPF programs need to be mitigated for BHB.\n\nIn addition, only mitigate cBPF programs that were loaded by an\nunprivileged user. Privileged users can also load the same program\nvia eBPF, making the mitigation pointless.(CVE-2025-37963)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: uclogic: Add NULL check in uclogic_input_configured()\n\ndevm_kasprintf() returns NULL when memory allocation fails. Currently,\nuclogic_input_configured() does not check for this case, which results\nin a NULL pointer dereference.\n\nAdd NULL check after devm_kasprintf() to prevent this issue.(CVE-2025-38007)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npadata: do not leak refcount in reorder_work\n\nA recent patch that addressed a UAF introduced a reference count leak:\nthe parallel_data refcount is incremented unconditionally, regardless\nof the return value of queue_work(). If the work item is already queued,\nthe incremented refcount is never decremented.\n\nFix this by checking the return value of queue_work() and decrementing\nthe refcount when necessary.\n\nResolves:\n\nUnreferenced object 0xffff9d9f421e3d80 (size 192):\n comm \u0026quot;cryptomgr_probe\u0026quot;, pid 157, jiffies 4294694003\n hex dump (first 32 bytes):\n 80 8b cf 41 9f 9d ff ff b8 97 e0 89 ff ff ff ff ...A............\n d0 97 e0 89 ff ff ff ff 19 00 00 00 1f 88 23 00 ..............#.\n backtrace (crc 838fb36):\n __kmalloc_cache_noprof+0x284/0x320\n padata_alloc_pd+0x20/0x1e0\n padata_alloc_shell+0x3b/0xa0\n 0xffffffffc040a54d\n cryptomgr_probe+0x43/0xc0\n kthread+0xf6/0x1f0\n ret_from_fork+0x2f/0x50\n ret_from_fork_asm+0x1a/0x30(CVE-2025-38031)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: correct the order of prelim_ref arguments in btrfs__prelim_ref\n\nbtrfs_prelim_ref() calls the old and new reference variables in the\nincorrect order. This causes a NULL pointer dereference because oldref\nis passed as NULL to trace_btrfs_prelim_ref_insert().\n\nNote, trace_btrfs_prelim_ref_insert() is being called with newref as\noldref (and oldref as NULL) on purpose in order to print out\nthe values of newref.\n\nTo reproduce:\necho 1 \u0026gt; /sys/kernel/debug/tracing/events/btrfs/btrfs_prelim_ref_insert/enable\n\nPerform some writeback operations.\n\nBacktrace:\nBUG: kernel NULL pointer dereference, address: 0000000000000018\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\n PGD 115949067 P4D 115949067 PUD 11594a067 PMD 0\n Oops: Oops: 0000 [#1] SMP NOPTI\n CPU: 1 UID: 0 PID: 1188 Comm: fsstress Not tainted 6.15.0-rc2-tester+ #47 PREEMPT(voluntary) 7ca2cef72d5e9c600f0c7718adb6462de8149622\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-2-gc13ff2cd-prebuilt.qemu.org 04/01/2014\n RIP: 0010:trace_event_raw_event_btrfs__prelim_ref+0x72/0x130\n Code: e8 43 81 9f ff 48 85 c0 74 78 4d 85 e4 0f 84 8f 00 00 00 49 8b 94 24 c0 06 00 00 48 8b 0a 48 89 48 08 48 8b 52 08 48 89 50 10 \u0026lt;49\u0026gt; 8b 55 18 48 89 50 18 49 8b 55 20 48 89 50 20 41 0f b6 55 28 88\n RSP: 0018:ffffce44820077a0 EFLAGS: 00010286\n RAX: ffff8c6b403f9014 RBX: ffff8c6b55825730 RCX: 304994edf9cf506b\n RDX: d8b11eb7f0fdb699 RSI: ffff8c6b403f9010 RDI: ffff8c6b403f9010\n RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000010\n R10: 00000000ffffffff R11: 0000000000000000 R12: ffff8c6b4e8fb000\n R13: 0000000000000000 R14: ffffce44820077a8 R15: ffff8c6b4abd1540\n FS: 00007f4dc6813740(0000) GS:ffff8c6c1d378000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 0000000000000018 CR3: 000000010eb42000 CR4: 0000000000750ef0\n PKRU: 55555554\n Call Trace:\n \u0026lt;TASK\u0026gt;\n prelim_ref_insert+0x1c1/0x270\n find_parent_nodes+0x12a6/0x1ee0\n ? __entry_text_end+0x101f06/0x101f09\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? srso_alias_return_thunk+0x5/0xfbef5\n btrfs_is_data_extent_shared+0x167/0x640\n ? fiemap_process_hole+0xd0/0x2c0\n extent_fiemap+0xa5c/0xbc0\n ? __entry_text_end+0x101f05/0x101f09\n btrfs_fiemap+0x7e/0xd0\n do_vfs_ioctl+0x425/0x9d0\n __x64_sys_ioctl+0x75/0xc0(CVE-2025-38034)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: copy_verifier_state() should copy \u0026apos;loop_entry\u0026apos; field\n\nThe bpf_verifier_state.loop_entry state should be copied by\ncopy_verifier_state(). Otherwise, .loop_entry values from unrelated\nstates would poison env-\u0026gt;cur_state.\n\nAdditionally, env-\u0026gt;stack should not contain any states with\n.loop_entry != NULL. The states in env-\u0026gt;stack are yet to be verified,\nwhile .loop_entry is set for states that reached an equivalent state.\nThis means that env-\u0026gt;cur_state-\u0026gt;loop_entry should always be NULL after\npop_stack().\n\nSee the selftest in the next commit for an example of the program that\nis not safe yet is accepted by verifier w/o this fix.\n\nThis change has some verification performance impact for selftests:\n\nFile Program Insns (A) Insns (B) Insns (DIFF) States (A) States (B) States (DIFF)\n---------------------------------- ---------------------------- --------- --------- -------------- ---------- ---------- -------------\narena_htab.bpf.o arena_htab_llvm 717 426 -291 (-40.59%) 57 37 -20 (-35.09%)\narena_htab_asm.bpf.o arena_htab_asm 597 445 -152 (-25.46%) 47 37 -10 (-21.28%)\narena_list.bpf.o arena_list_del 309 279 -30 (-9.71%) 23 14 -9 (-39.13%)\niters.bpf.o iter_subprog_check_stacksafe 155 141 -14 (-9.03%) 15 14 -1 (-6.67%)\niters.bpf.o iter_subprog_iters 1094 1003 -91 (-8.32%) 88 83 -5 (-5.68%)\niters.bpf.o loop_state_deps2 479 725 +246 (+51.36%) 46 63 +17 (+36.96%)\nkmem_cache_iter.bpf.o open_coded_iter 63 59 -4 (-6.35%) 7 6 -1 (-14.29%)\nverifier_bits_iter.bpf.o max_words 92 84 -8 (-8.70%) 8 7 -1 (-12.50%)\nverifier_iterating_callbacks.bpf.o cond_break2 113 107 -6 (-5.31%) 12 12 +0 (+0.00%)\n\nAnd significant negative impact for sched_ext:\n\nFile Program Insns (A) Insns (B) Insns (DIFF) States (A) States (B) States (DIFF)\n----------------- ---------------------- --------- --------- -------------------- ---------- ---------- ------------------\nbpf.bpf.o lavd_init 7039 14723 +7684 (+109.16%) 490 1139 +649 (+132.45%)\nbpf.bpf.o layered_dispatch 11485 10548 -937 (-8.16%) 848 762 -86 (-10.14%)\nbpf.bpf.o layered_dump 7422 1000001 +992579 (+13373.47%) 681 31178 +30497 (+4478.27%)\nbpf.bpf.o layered_enqueue 16854 71127 +54273 (+322.02%) 1611 6450 +4839 (+300.37%)\nbpf.bpf.o p2dq_dispatch 665 791 +126 (+18.95%) 68 78 +10 (+14.71%)\nbpf.bpf.o p2dq_init 2343 2980 +637 (+27.19%) 201 237 +36 (+17.91%)\nbpf.bpf.o refresh_layer_cpumasks 16487 674760 +658273 (+3992.68%) 1770 65370 +63600 (+3593.22%)\nbpf.bpf.o rusty_select_cpu 1937 40872 +38935 (+2010.07%) 177 3210 +3033 (+1713.56%)\nscx_central.bpf.o central_dispatch 636 2687 +2051 (+322.48%) 63 227 +164 (+260.32%)\nscx_nest.bpf.o nest_init 636 815 +179 (+28.14%) 60 73 +13 (+21.67%)\nscx_qmap.bpf.o qmap_dispatch \n---truncated---(CVE-2025-38060)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\norangefs: Do not truncate file size\n\n\u0026apos;len\u0026apos; is used to store the result of i_size_read(), so making \u0026apos;len\u0026apos;\na size_t results in truncation to 4GiB on 32-bit systems.(CVE-2025-38065)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvhost-scsi: protect vq-\u0026gt;log_used with vq-\u0026gt;mutex\n\nThe vhost-scsi completion path may access vq-\u0026gt;log_base when vq-\u0026gt;log_used is\nalready set to false.\n\n vhost-thread QEMU-thread\n\nvhost_scsi_complete_cmd_work()\n-\u0026gt; vhost_add_used()\n -\u0026gt; vhost_add_used_n()\n if (unlikely(vq-\u0026gt;log_used))\n QEMU disables vq-\u0026gt;log_used\n via VHOST_SET_VRING_ADDR.\n mutex_lock(\u0026amp;vq-\u0026gt;mutex);\n vq-\u0026gt;log_used = false now!\n mutex_unlock(\u0026amp;vq-\u0026gt;mutex);\n\n\t\t\t\t QEMU gfree(vq-\u0026gt;log_base)\n log_used()\n -\u0026gt; log_write(vq-\u0026gt;log_base)\n\nAssuming the VMM is QEMU. The vq-\u0026gt;log_base is from QEMU userpace and can be\nreclaimed via gfree(). As a result, this causes invalid memory writes to\nQEMU userspace.\n\nThe control queue path has the same issue.(CVE-2025-38074)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nALSA: pcm: Fix race of buffer access at PCM OSS layer\n\nThe PCM OSS layer tries to clear the buffer with the silence data at\ninitialization (or reconfiguration) of a stream with the explicit call\nof snd_pcm_format_set_silence() with runtime-\u0026gt;dma_area. But this may\nlead to a UAF because the accessed runtime-\u0026gt;dma_area might be freed\nconcurrently, as it\u0026apos;s performed outside the PCM ops.\n\nFor avoiding it, move the code into the PCM core and perform it inside\nthe buffer access lock, so that it won\u0026apos;t be changed during the\noperation.(CVE-2025-38078)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Increase block_sequence array size\n\n[Why]\nIt\u0026apos;s possible to generate more than 50 steps in hwss_build_fast_sequence,\nfor example with a 6-pipe asic where all pipes are in one MPC chain. This\noverflows the block_sequence buffer and corrupts block_sequence_steps,\ncausing a crash.\n\n[How]\nExpand block_sequence to 100 items. A naive upper bound on the possible\nnumber of steps for a 6-pipe asic, ignoring the potential for steps to be\nmutually exclusive, is 91 with current code, therefore 100 is sufficient.(CVE-2025-38080)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nremoteproc: core: Clear table_sz when rproc_shutdown\n\nThere is case as below could trigger kernel dump:\nUse U-Boot to start remote processor(rproc) with resource table\npublished to a fixed address by rproc. After Kernel boots up,\nstop the rproc, load a new firmware which doesn\u0026apos;t have resource table\n,and start rproc.\n\nWhen starting rproc with a firmware not have resource table,\n`memcpy(loaded_table, rproc-\u0026gt;cached_table, rproc-\u0026gt;table_sz)` will\ntrigger dump, because rproc-\u0026gt;cache_table is set to NULL during the last\nstop operation, but rproc-\u0026gt;table_sz is still valid.\n\nThis issue is found on i.MX8MP and i.MX9.\n\nDump as below:\nUnable to handle kernel NULL pointer dereference at virtual address 0000000000000000\nMem abort info:\n ESR = 0x0000000096000004\n EC = 0x25: DABT (current EL), IL = 32 bits\n SET = 0, FnV = 0\n EA = 0, S1PTW = 0\n FSC = 0x04: level 0 translation fault\nData abort info:\n ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000\n CM = 0, WnR = 0, TnD = 0, TagAccess = 0\n GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\nuser pgtable: 4k pages, 48-bit VAs, pgdp=000000010af63000\n[0000000000000000] pgd=0000000000000000, p4d=0000000000000000\nInternal error: Oops: 0000000096000004 [#1] PREEMPT SMP\nModules linked in:\nCPU: 2 UID: 0 PID: 1060 Comm: sh Not tainted 6.14.0-rc7-next-20250317-dirty #38\nHardware name: NXP i.MX8MPlus EVK board (DT)\npstate: a0000005 (NzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : __pi_memcpy_generic+0x110/0x22c\nlr : rproc_start+0x88/0x1e0\nCall trace:\n __pi_memcpy_generic+0x110/0x22c (P)\n rproc_boot+0x198/0x57c\n state_store+0x40/0x104\n dev_attr_store+0x18/0x2c\n sysfs_kf_write+0x7c/0x94\n kernfs_fop_write_iter+0x120/0x1cc\n vfs_write+0x240/0x378\n ksys_write+0x70/0x108\n __arm64_sys_write+0x1c/0x28\n invoke_syscall+0x48/0x10c\n el0_svc_common.constprop.0+0xc0/0xe0\n do_el0_svc+0x1c/0x28\n el0_svc+0x30/0xcc\n el0t_64_sync_handler+0x10c/0x138\n el0t_64_sync+0x198/0x19c\n\nClear rproc-\u0026gt;table_sz to address the issue.(CVE-2025-38152)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\njfs: fix slab-out-of-bounds read in ea_get()\n\nDuring the \u0026quot;size_check\u0026quot; label in ea_get(), the code checks if the extended\nattribute list (xattr) size matches ea_size. If not, it logs\n\u0026quot;ea_get: invalid extended attribute\u0026quot; and calls print_hex_dump().\n\nHere, EALIST_SIZE(ea_buf-\u0026gt;xattr) returns 4110417968, which exceeds\nINT_MAX (2,147,483,647). Then ea_size is clamped:\n\n\tint size = clamp_t(int, ea_size, 0, EALIST_SIZE(ea_buf-\u0026gt;xattr));\n\nAlthough clamp_t aims to bound ea_size between 0 and 4110417968, the upper\nlimit is treated as an int, causing an overflow above 2^31 - 1. This leads\n\u0026quot;size\u0026quot; to wrap around and become negative (-184549328).\n\nThe \u0026quot;size\u0026quot; is then passed to print_hex_dump() (called \u0026quot;len\u0026quot; in\nprint_hex_dump()), it is passed as type size_t (an unsigned\ntype), this is then stored inside a variable called\n\u0026quot;int remaining\u0026quot;, which is then assigned to \u0026quot;int linelen\u0026quot; which\nis then passed to hex_dump_to_buffer(). In print_hex_dump()\nthe for loop, iterates through 0 to len-1, where len is\n18446744073525002176, calling hex_dump_to_buffer()\non each iteration:\n\n\tfor (i = 0; i \u0026lt; len; i += rowsize) {\n\t\tlinelen = min(remaining, rowsize);\n\t\tremaining -= rowsize;\n\n\t\thex_dump_to_buffer(ptr + i, linelen, rowsize, groupsize,\n\t\t\t\t linebuf, sizeof(linebuf), ascii);\n\n\t\t...\n\t}\n\nThe expected stopping condition (i \u0026lt; len) is effectively broken\nsince len is corrupted and very large. This eventually leads to\nthe \u0026quot;ptr+i\u0026quot; being passed to hex_dump_to_buffer() to get closer\nto the end of the actual bounds of \u0026quot;ptr\u0026quot;, eventually an out of\nbounds access is done in hex_dump_to_buffer() in the following\nfor loop:\n\n\tfor (j = 0; j \u0026lt; len; j++) {\n\t\t\tif (linebuflen \u0026lt; lx + 2)\n\t\t\t\tgoto overflow2;\n\t\t\tch = ptr[j];\n\t\t...\n\t}\n\nTo fix this we should validate \u0026quot;EALIST_SIZE(ea_buf-\u0026gt;xattr)\u0026quot;\nbefore it is utilised.(CVE-2025-39735)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nobjtool, spi: amd: Fix out-of-bounds stack access in amd_set_spi_freq()\n\nIf speed_hz \u0026lt; AMD_SPI_MIN_HZ, amd_set_spi_freq() iterates over the\nentire amd_spi_freq array without breaking out early, causing \u0026apos;i\u0026apos; to go\nbeyond the array bounds.\n\nFix that by stopping the loop when it gets to the last entry, so the low\nspeed_hz value gets clamped up to AMD_SPI_MIN_HZ.\n\nFixes the following warning with an UBSAN kernel:\n\n drivers/spi/spi-amd.o: error: objtool: amd_set_spi_freq() falls through to next function amd_spi_set_opcode()(CVE-2025-40014)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nio_uring: fix io_req_prep_async with provided buffers\n\nio_req_prep_async() can import provided buffers, commit the ring state\nby giving up on that before, it\u0026apos;ll be reimported later if needed.(CVE-2025-40364)",
"id": "OESA-2025-1729",
"modified": "2026-08-06T11:08:49Z",
"published": "2025-07-04T11:08:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1729"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38385"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42127"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42131"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45015"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47732"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57896"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58085"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21854"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21861"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21944"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21996"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23149"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37849"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37930"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37937"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37948"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37963"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38007"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38031"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38034"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38060"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38065"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38074"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38078"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38080"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38152"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39735"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40014"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40364"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2024-38385",
"CVE-2024-42127",
"CVE-2024-42131",
"CVE-2024-45015",
"CVE-2024-47732",
"CVE-2024-57896",
"CVE-2024-58085",
"CVE-2025-21854",
"CVE-2025-21861",
"CVE-2025-21944",
"CVE-2025-21996",
"CVE-2025-23149",
"CVE-2025-37849",
"CVE-2025-37930",
"CVE-2025-37937",
"CVE-2025-37948",
"CVE-2025-37963",
"CVE-2025-38007",
"CVE-2025-38031",
"CVE-2025-38034",
"CVE-2025-38060",
"CVE-2025-38065",
"CVE-2025-38074",
"CVE-2025-38078",
"CVE-2025-38080",
"CVE-2025-38152",
"CVE-2025-39735",
"CVE-2025-40014",
"CVE-2025-40364"
]
}
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
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.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
Loading timeline…
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.