Action not permitted
Modal body text goes here.
Modal Title
Modal Body
CVE-2021-47211 (GCVE-0-2021-47211)
Vulnerability from cvelistv5 – Published: 2024-04-10 19:01 – Updated: 2026-06-19 11:57| Vendor | Product | Version | CPE status | |
|---|---|---|---|---|
| Linux | Linux |
Affected:
1dc669fed61a4ec4270a89e5fb3535802cc45668 , < 3455984b16eeb6914caf8b59498ef24fcc1f0a78
(git)
Affected: 1dc669fed61a4ec4270a89e5fb3535802cc45668 , < 58fa50de595f152900594c28ec9915c169643739 (git) Affected: 1dc669fed61a4ec4270a89e5fb3535802cc45668 , < b97053df0f04747c3c1e021ecbe99db675342954 (git) |
guessed | |
| Linux | Linux |
Affected:
3.10
Unaffected: 0 , < 3.10 (semver) Unaffected: 5.10.259 , ≤ 5.10.* (semver) Unaffected: 5.15.5 , ≤ 5.15.* (semver) Unaffected: 5.16 , ≤ * (original_commit_for_fix) |
guessed |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2021-47211",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2024-06-21T16:04:02.891188Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2024-06-21T16:04:10.989Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
},
{
"providerMetadata": {
"dateUpdated": "2024-08-04T05:32:07.365Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/58fa50de595f152900594c28ec9915c169643739"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/b97053df0f04747c3c1e021ecbe99db675342954"
}
],
"title": "CVE Program Container"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"sound/usb/clock.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "3455984b16eeb6914caf8b59498ef24fcc1f0a78",
"status": "affected",
"version": "1dc669fed61a4ec4270a89e5fb3535802cc45668",
"versionType": "git"
},
{
"lessThan": "58fa50de595f152900594c28ec9915c169643739",
"status": "affected",
"version": "1dc669fed61a4ec4270a89e5fb3535802cc45668",
"versionType": "git"
},
{
"lessThan": "b97053df0f04747c3c1e021ecbe99db675342954",
"status": "affected",
"version": "1dc669fed61a4ec4270a89e5fb3535802cc45668",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"sound/usb/clock.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "3.10"
},
{
"lessThan": "3.10",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.259",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.5",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "5.16",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.10.259",
"versionStartIncluding": "3.10",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.15.5",
"versionStartIncluding": "3.10",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.16",
"versionStartIncluding": "3.10",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nALSA: usb-audio: fix null pointer dereference on pointer cs_desc\n\nThe pointer cs_desc return from snd_usb_find_clock_source could\nbe null, so there is a potential null pointer dereference issue.\nFix this by adding a null check before dereference."
}
],
"providerMetadata": {
"dateUpdated": "2026-06-19T11:57:06.060Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/3455984b16eeb6914caf8b59498ef24fcc1f0a78"
},
{
"url": "https://git.kernel.org/stable/c/58fa50de595f152900594c28ec9915c169643739"
},
{
"url": "https://git.kernel.org/stable/c/b97053df0f04747c3c1e021ecbe99db675342954"
}
],
"title": "ALSA: usb-audio: fix null pointer dereference on pointer cs_desc",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2021-47211",
"datePublished": "2024-04-10T19:01:52.636Z",
"dateReserved": "2024-04-10T18:59:19.526Z",
"dateUpdated": "2026-06-19T11:57:06.060Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"epss": {
"cve": "CVE-2021-47211",
"date": "2026-09-27",
"epss": "0.00241",
"percentile": "0.13649"
},
"fkie_nvd": {
"configurations": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "B2845F69-264B-45BD-B7E7-D12B24338382",
"versionEndExcluding": "5.15.5",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nALSA: usb-audio: fix null pointer dereference on pointer cs_desc\n\nThe pointer cs_desc return from snd_usb_find_clock_source could\nbe null, so there is a potential null pointer dereference issue.\nFix this by adding a null check before dereference."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: usb-audio: se corrige la desreferencia de puntero nulo en el puntero cs_desc El puntero cs_desc devuelto por snd_usb_find_clock_source podr\u00eda ser nulo, por lo que existe un posible problema de desreferencia de puntero nulo. Solucione esto agregando una comprobaci\u00f3n de nulo antes de la desreferencia."
}
],
"id": "CVE-2021-47211",
"lastModified": "2025-01-14T14:43:27.637",
"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"
}
]
},
"published": "2024-04-10T19:15:48.547",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/58fa50de595f152900594c28ec9915c169643739"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/b97053df0f04747c3c1e021ecbe99db675342954"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/58fa50de595f152900594c28ec9915c169643739"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/b97053df0f04747c3c1e021ecbe99db675342954"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Analyzed",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "CWE-476"
}
],
"source": "nvd@nist.gov",
"type": "Primary"
}
]
},
"nvd": {
"cve": {
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"sound/usb/clock.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "3455984b16eeb6914caf8b59498ef24fcc1f0a78",
"status": "affected",
"version": "1dc669fed61a4ec4270a89e5fb3535802cc45668",
"versionType": "git"
},
{
"lessThan": "58fa50de595f152900594c28ec9915c169643739",
"status": "affected",
"version": "1dc669fed61a4ec4270a89e5fb3535802cc45668",
"versionType": "git"
},
{
"lessThan": "b97053df0f04747c3c1e021ecbe99db675342954",
"status": "affected",
"version": "1dc669fed61a4ec4270a89e5fb3535802cc45668",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"sound/usb/clock.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "3.10"
},
{
"lessThan": "3.10",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.259",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.5",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "5.16",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"configurations": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "B2845F69-264B-45BD-B7E7-D12B24338382",
"versionEndExcluding": "5.15.5",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nALSA: usb-audio: fix null pointer dereference on pointer cs_desc\n\nThe pointer cs_desc return from snd_usb_find_clock_source could\nbe null, so there is a potential null pointer dereference issue.\nFix this by adding a null check before dereference."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: usb-audio: se corrige la desreferencia de puntero nulo en el puntero cs_desc El puntero cs_desc devuelto por snd_usb_find_clock_source podr\u00eda ser nulo, por lo que existe un posible problema de desreferencia de puntero nulo. Solucione esto agregando una comprobaci\u00f3n de nulo antes de la desreferencia."
}
],
"id": "CVE-2021-47211",
"lastModified": "2026-06-19T13:16:18.337",
"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-2021-47211",
"options": [
{
"exploitation": "none"
},
{
"automatable": "no"
},
{
"technicalImpact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2024-06-21T16:04:02.891188Z",
"version": "2.0.3"
}
}
]
},
"published": "2024-04-10T19:15:48.547",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/3455984b16eeb6914caf8b59498ef24fcc1f0a78"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/58fa50de595f152900594c28ec9915c169643739"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/b97053df0f04747c3c1e021ecbe99db675342954"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/58fa50de595f152900594c28ec9915c169643739"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/b97053df0f04747c3c1e021ecbe99db675342954"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Modified",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "CWE-476"
}
],
"source": "nvd@nist.gov",
"type": "Primary"
}
]
}
},
"redhat_vex": {
"aggregate_severity": "Low",
"current_release_date": "2025-11-21T14:03:01+00:00",
"cve": "CVE-2021-47211",
"id": "CVE-2021-47211",
"initial_release_date": "2021-01-01T00:00:00+00:00",
"product_status:known_affected": "90",
"product_status:known_not_affected": "108",
"source": "Red Hat CSAF VEX",
"status": "final",
"title": "kernel: ALSA: usb-audio: fix null pointer dereference on pointer cs_desc",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2021/cve-2021-47211.json",
"version": "3"
},
"suse_vex": {
"aggregate_severity": "moderate",
"current_release_date": "2026-09-18T01:08:22Z",
"cve": "CVE-2021-47211",
"id": "CVE-2021-47211",
"initial_release_date": "2024-04-17T02:29:21Z",
"product_status:known_affected": "470",
"product_status:known_not_affected": "74",
"product_status:recommended": "546",
"source": "SUSE CSAF VEX",
"status": "interim",
"title": "SUSE CVE CVE-2021-47211",
"url": "https://ftp.suse.com/pub/projects/security/csaf-vex/cve-2021-47211.json",
"version": "54"
},
"vulnrichment": {
"containers": {
"adp": [
{
"providerMetadata": {
"dateUpdated": "2024-08-04T05:32:07.365Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/58fa50de595f152900594c28ec9915c169643739"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/b97053df0f04747c3c1e021ecbe99db675342954"
}
],
"title": "CVE Program Container"
},
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2021-47211",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2024-06-21T16:04:02.891188Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2024-06-21T16:04:07.465Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"sound/usb/clock.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "3455984b16eeb6914caf8b59498ef24fcc1f0a78",
"status": "affected",
"version": "1dc669fed61a4ec4270a89e5fb3535802cc45668",
"versionType": "git"
},
{
"lessThan": "58fa50de595f152900594c28ec9915c169643739",
"status": "affected",
"version": "1dc669fed61a4ec4270a89e5fb3535802cc45668",
"versionType": "git"
},
{
"lessThan": "b97053df0f04747c3c1e021ecbe99db675342954",
"status": "affected",
"version": "1dc669fed61a4ec4270a89e5fb3535802cc45668",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"sound/usb/clock.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "3.10"
},
{
"lessThan": "3.10",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.259",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.5",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "5.16",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.10.259",
"versionStartIncluding": "3.10",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.15.5",
"versionStartIncluding": "3.10",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.16",
"versionStartIncluding": "3.10",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nALSA: usb-audio: fix null pointer dereference on pointer cs_desc\n\nThe pointer cs_desc return from snd_usb_find_clock_source could\nbe null, so there is a potential null pointer dereference issue.\nFix this by adding a null check before dereference."
}
],
"providerMetadata": {
"dateUpdated": "2026-06-19T11:57:06.060Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/3455984b16eeb6914caf8b59498ef24fcc1f0a78"
},
{
"url": "https://git.kernel.org/stable/c/58fa50de595f152900594c28ec9915c169643739"
},
{
"url": "https://git.kernel.org/stable/c/b97053df0f04747c3c1e021ecbe99db675342954"
}
],
"title": "ALSA: usb-audio: fix null pointer dereference on pointer cs_desc",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2021-47211",
"datePublished": "2024-04-10T19:01:52.636Z",
"dateReserved": "2024-04-10T18:59:19.526Z",
"dateUpdated": "2026-06-19T11:57:06.060Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
}
}
CERTFR-2025-AVI-0605
Vulnerability from certfr_avis - Published: - Updated:
De multiples vulnérabilités ont été découvertes dans le noyau Linux d'Ubuntu. Certaines d'entre elles permettent à un attaquant de provoquer une atteinte à la confidentialité des données, un contournement de la politique de sécurité et un déni de service.
Solutions
Se référer au bulletin de sécurité de l'éditeur pour l'obtention des correctifs (cf. section Documentation).
| Title | Publication Time | Tags | |||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||
{
"$ref": "https://www.cert.ssi.gouv.fr/openapi.json",
"affected_systems": [
{
"description": "Ubuntu 20.04 ESM",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 24.04 LTS",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 25.04",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 18.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-2024-57981",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57981"
},
{
"name": "CVE-2023-52664",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52664"
},
{
"name": "CVE-2024-58010",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58010"
},
{
"name": "CVE-2024-57973",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57973"
},
{
"name": "CVE-2024-50055",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50055"
},
{
"name": "CVE-2024-58069",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58069"
},
{
"name": "CVE-2025-21871",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21871"
},
{
"name": "CVE-2025-21731",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21731"
},
{
"name": "CVE-2024-58009",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58009"
},
{
"name": "CVE-2023-53034",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53034"
},
{
"name": "CVE-2025-21823",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21823"
},
{
"name": "CVE-2025-21763",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21763"
},
{
"name": "CVE-2025-21922",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21922"
},
{
"name": "CVE-2025-22021",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22021"
},
{
"name": "CVE-2024-57980",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57980"
},
{
"name": "CVE-2024-46787",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46787"
},
{
"name": "CVE-2023-52927",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52927"
},
{
"name": "CVE-2024-58058",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58058"
},
{
"name": "CVE-2024-50047",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50047"
},
{
"name": "CVE-2025-39735",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39735"
},
{
"name": "CVE-2025-21904",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21904"
},
{
"name": "CVE-2025-37798",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37798"
},
{
"name": "CVE-2025-22004",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22004"
},
{
"name": "CVE-2025-21735",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21735"
},
{
"name": "CVE-2025-21647",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21647"
},
{
"name": "CVE-2024-58063",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58063"
},
{
"name": "CVE-2025-21948",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21948"
},
{
"name": "CVE-2025-21753",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21753"
},
{
"name": "CVE-2025-21993",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21993"
},
{
"name": "CVE-2025-37937",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37937"
},
{
"name": "CVE-2025-21715",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21715"
},
{
"name": "CVE-2025-21781",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21781"
},
{
"name": "CVE-2025-38637",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38637"
},
{
"name": "CVE-2025-21772",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21772"
},
{
"name": "CVE-2025-21914",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21914"
},
{
"name": "CVE-2024-58007",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58007"
},
{
"name": "CVE-2025-21728",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21728"
},
{
"name": "CVE-2024-58090",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58090"
},
{
"name": "CVE-2022-49636",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49636"
},
{
"name": "CVE-2025-22035",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22035"
},
{
"name": "CVE-2025-21764",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21764"
},
{
"name": "CVE-2024-58093",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58093"
},
{
"name": "CVE-2024-58085",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58085"
},
{
"name": "CVE-2025-21704",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21704"
},
{
"name": "CVE-2025-21909",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21909"
},
{
"name": "CVE-2021-47211",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47211"
},
{
"name": "CVE-2025-21959",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21959"
},
{
"name": "CVE-2024-58017",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58017"
},
{
"name": "CVE-2024-56599",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56599"
},
{
"name": "CVE-2025-21910",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21910"
},
{
"name": "CVE-2025-21791",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21791"
},
{
"name": "CVE-2023-52741",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52741"
},
{
"name": "CVE-2025-21814",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21814"
},
{
"name": "CVE-2025-21996",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21996"
},
{
"name": "CVE-2025-21787",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21787"
},
{
"name": "CVE-2025-23136",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23136"
},
{
"name": "CVE-2025-21776",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21776"
},
{
"name": "CVE-2025-21917",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21917"
},
{
"name": "CVE-2025-21957",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21957"
},
{
"name": "CVE-2025-21736",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21736"
},
{
"name": "CVE-2025-21708",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21708"
},
{
"name": "CVE-2025-21992",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21992"
},
{
"name": "CVE-2024-53051",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53051"
},
{
"name": "CVE-2025-21760",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21760"
},
{
"name": "CVE-2025-22018",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22018"
},
{
"name": "CVE-2025-21916",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21916"
},
{
"name": "CVE-2025-21925",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21925"
},
{
"name": "CVE-2025-21785",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21785"
},
{
"name": "CVE-2025-21898",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21898"
},
{
"name": "CVE-2024-58051",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58051"
},
{
"name": "CVE-2025-21848",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21848"
},
{
"name": "CVE-2025-22005",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22005"
},
{
"name": "CVE-2025-21935",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21935"
},
{
"name": "CVE-2025-22045",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22045"
},
{
"name": "CVE-2025-21866",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21866"
},
{
"name": "CVE-2025-21862",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21862"
},
{
"name": "CVE-2025-21719",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21719"
},
{
"name": "CVE-2025-21718",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21718"
},
{
"name": "CVE-2024-57979",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57979"
},
{
"name": "CVE-2024-58071",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58071"
},
{
"name": "CVE-2025-21971",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21971"
},
{
"name": "CVE-2025-21806",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21806"
},
{
"name": "CVE-2024-57977",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57977"
},
{
"name": "CVE-2025-21928",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21928"
},
{
"name": "CVE-2024-56551",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56551"
},
{
"name": "CVE-2025-22007",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22007"
},
{
"name": "CVE-2025-21934",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21934"
},
{
"name": "CVE-2025-38000",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38000"
},
{
"name": "CVE-2025-22071",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22071"
},
{
"name": "CVE-2025-21762",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21762"
},
{
"name": "CVE-2025-21859",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21859"
},
{
"name": "CVE-2025-21956",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21956"
},
{
"name": "CVE-2025-21761",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21761"
},
{
"name": "CVE-2025-37932",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37932"
},
{
"name": "CVE-2025-37890",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37890"
},
{
"name": "CVE-2025-22020",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22020"
},
{
"name": "CVE-2024-58020",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58020"
},
{
"name": "CVE-2025-21721",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21721"
},
{
"name": "CVE-2025-21877",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21877"
},
{
"name": "CVE-2025-21846",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21846"
},
{
"name": "CVE-2021-47191",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47191"
},
{
"name": "CVE-2025-21765",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21765"
},
{
"name": "CVE-2025-21782",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21782"
},
{
"name": "CVE-2025-22063",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22063"
},
{
"name": "CVE-2025-21926",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21926"
},
{
"name": "CVE-2025-21865",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21865"
},
{
"name": "CVE-2024-58002",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58002"
},
{
"name": "CVE-2025-38001",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38001"
},
{
"name": "CVE-2024-26996",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26996"
},
{
"name": "CVE-2024-58052",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58052"
},
{
"name": "CVE-2025-21905",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21905"
},
{
"name": "CVE-2025-21920",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21920"
},
{
"name": "CVE-2024-58001",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58001"
},
{
"name": "CVE-2024-53168",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53168"
},
{
"name": "CVE-2025-21858",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21858"
},
{
"name": "CVE-2024-26689",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26689"
},
{
"name": "CVE-2025-37997",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37997"
},
{
"name": "CVE-2025-2312",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-2312"
},
{
"name": "CVE-2025-21749",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21749"
},
{
"name": "CVE-2024-58072",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58072"
},
{
"name": "CVE-2025-21722",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21722"
},
{
"name": "CVE-2024-26982",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26982"
},
{
"name": "CVE-2025-22054",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22054"
},
{
"name": "CVE-2024-58083",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58083"
},
{
"name": "CVE-2024-58055",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58055"
},
{
"name": "CVE-2025-21991",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21991"
},
{
"name": "CVE-2025-22086",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22086"
},
{
"name": "CVE-2025-22073",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22073"
},
{
"name": "CVE-2024-58014",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58014"
},
{
"name": "CVE-2025-22079",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22079"
},
{
"name": "CVE-2025-21744",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21744"
},
{
"name": "CVE-2024-57986",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57986"
},
{
"name": "CVE-2025-21835",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21835"
},
{
"name": "CVE-2025-21811",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21811"
}
],
"links": [],
"reference": "CERTFR-2025-AVI-0605",
"revisions": [
{
"description": "Version initiale",
"revision_date": "2025-07-18T00:00:00.000000"
}
],
"risks": [
{
"description": "Non sp\u00e9cifi\u00e9 par l\u0027\u00e9diteur"
},
{
"description": "D\u00e9ni de service"
},
{
"description": "Contournement de la politique de s\u00e9curit\u00e9"
},
{
"description": "Atteinte \u00e0 la confidentialit\u00e9 des donn\u00e9es"
}
],
"summary": "De multiples vuln\u00e9rabilit\u00e9s ont \u00e9t\u00e9 d\u00e9couvertes dans le noyau Linux d\u0027Ubuntu. Certaines d\u0027entre elles permettent \u00e0 un attaquant de provoquer une atteinte \u00e0 la confidentialit\u00e9 des donn\u00e9es, un contournement de la politique de s\u00e9curit\u00e9 et un d\u00e9ni de service.",
"title": "Multiples vuln\u00e9rabilit\u00e9s dans le noyau Linux d\u0027Ubuntu",
"vendor_advisories": [
{
"published_at": "2025-07-15",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7610-3",
"url": "https://ubuntu.com/security/notices/USN-7610-3"
},
{
"published_at": "2025-07-11",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7608-6",
"url": "https://ubuntu.com/security/notices/USN-7608-6"
},
{
"published_at": "2025-07-16",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7640-1",
"url": "https://ubuntu.com/security/notices/USN-7640-1"
},
{
"published_at": "2025-07-17",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7611-3",
"url": "https://ubuntu.com/security/notices/USN-7611-3"
},
{
"published_at": "2025-07-16",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7585-7",
"url": "https://ubuntu.com/security/notices/USN-7585-7"
}
]
}
CERTFR-2026-AVI-0862
Vulnerability from certfr_avis - Published: 2026-07-10 - Updated: 2026-07-10
De multiples vulnérabilités ont été découvertes dans le noyau Linux de Debian LTS. Certaines d'entre 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 bookworm versions ant\u00e9rieures \u00e0 6.1.176",
"product": {
"name": "Debian",
"vendor": {
"name": "Debian",
"scada": false
}
}
},
{
"description": "Debian bullseye versions ant\u00e9rieures \u00e0 5.10.259",
"product": {
"name": "Debian",
"vendor": {
"name": "Debian",
"scada": false
}
}
},
{
"description": "Debian bullseye versions ant\u00e9rieures \u00e0 6.6.1.176.95-1",
"product": {
"name": "Debian",
"vendor": {
"name": "Debian",
"scada": false
}
}
},
{
"description": "Debian trixie versions ant\u00e9rieures \u00e0 6.12.95-1",
"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-2026-31623",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31623"
},
{
"name": "CVE-2026-45842",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45842"
},
{
"name": "CVE-2023-54129",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54129"
},
{
"name": "CVE-2025-22026",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22026"
},
{
"name": "CVE-2026-53349",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53349"
},
{
"name": "CVE-2026-43113",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43113"
},
{
"name": "CVE-2025-39997",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39997"
},
{
"name": "CVE-2026-46119",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46119"
},
{
"name": "CVE-2026-52934",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52934"
},
{
"name": "CVE-2026-53179",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53179"
},
{
"name": "CVE-2026-46184",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46184"
},
{
"name": "CVE-2026-53049",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53049"
},
{
"name": "CVE-2025-22107",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22107"
},
{
"name": "CVE-2026-31619",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31619"
},
{
"name": "CVE-2026-31618",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31618"
},
{
"name": "CVE-2026-52955",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52955"
},
{
"name": "CVE-2026-53350",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53350"
},
{
"name": "CVE-2022-50493",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50493"
},
{
"name": "CVE-2026-52957",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52957"
},
{
"name": "CVE-2026-52925",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52925"
},
{
"name": "CVE-2026-46307",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46307"
},
{
"name": "CVE-2026-52929",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52929"
},
{
"name": "CVE-2026-52968",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52968"
},
{
"name": "CVE-2026-53061",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53061"
},
{
"name": "CVE-2026-53002",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53002"
},
{
"name": "CVE-2026-53287",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53287"
},
{
"name": "CVE-2026-46124",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46124"
},
{
"name": "CVE-2026-31578",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31578"
},
{
"name": "CVE-2026-53274",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53274"
},
{
"name": "CVE-2026-46082",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46082"
},
{
"name": "CVE-2026-43421",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43421"
},
{
"name": "CVE-2026-53128",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53128"
},
{
"name": "CVE-2026-53320",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53320"
},
{
"name": "CVE-2026-52947",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52947"
},
{
"name": "CVE-2026-53218",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53218"
},
{
"name": "CVE-2024-53221",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53221"
},
{
"name": "CVE-2026-53041",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53041"
},
{
"name": "CVE-2026-53066",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53066"
},
{
"name": "CVE-2026-31696",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31696"
},
{
"name": "CVE-2026-31704",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31704"
},
{
"name": "CVE-2026-31685",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31685"
},
{
"name": "CVE-2026-53161",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53161"
},
{
"name": "CVE-2026-52970",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52970"
},
{
"name": "CVE-2026-52958",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52958"
},
{
"name": "CVE-2026-46319",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46319"
},
{
"name": "CVE-2026-43492",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43492"
},
{
"name": "CVE-2026-31656",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31656"
},
{
"name": "CVE-2023-53421",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53421"
},
{
"name": "CVE-2026-52999",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52999"
},
{
"name": "CVE-2026-46065",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46065"
},
{
"name": "CVE-2026-46227",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46227"
},
{
"name": "CVE-2023-54271",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54271"
},
{
"name": "CVE-2026-53040",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53040"
},
{
"name": "CVE-2026-46185",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46185"
},
{
"name": "CVE-2026-46064",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46064"
},
{
"name": "CVE-2026-31698",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31698"
},
{
"name": "CVE-2026-31664",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31664"
},
{
"name": "CVE-2026-46112",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46112"
},
{
"name": "CVE-2026-46196",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46196"
},
{
"name": "CVE-2026-31597",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31597"
},
{
"name": "CVE-2026-52989",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52989"
},
{
"name": "CVE-2026-53291",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53291"
},
{
"name": "CVE-2026-43064",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43064"
},
{
"name": "CVE-2026-52924",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52924"
},
{
"name": "CVE-2026-53227",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53227"
},
{
"name": "CVE-2026-23468",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23468"
},
{
"name": "CVE-2026-46280",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46280"
},
{
"name": "CVE-2026-53239",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53239"
},
{
"name": "CVE-2026-31586",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31586"
},
{
"name": "CVE-2026-53181",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53181"
},
{
"name": "CVE-2026-46233",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46233"
},
{
"name": "CVE-2026-52918",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52918"
},
{
"name": "CVE-2025-23131",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23131"
},
{
"name": "CVE-2026-52963",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52963"
},
{
"name": "CVE-2026-46303",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46303"
},
{
"name": "CVE-2026-31613",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31613"
},
{
"name": "CVE-2026-53331",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53331"
},
{
"name": "CVE-2024-27012",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27012"
},
{
"name": "CVE-2026-52993",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52993"
},
{
"name": "CVE-2026-46080",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46080"
},
{
"name": "CVE-2026-46231",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46231"
},
{
"name": "CVE-2026-43010",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43010"
},
{
"name": "CVE-2026-45835",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45835"
},
{
"name": "CVE-2026-52943",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52943"
},
{
"name": "CVE-2026-31581",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31581"
},
{
"name": "CVE-2026-31617",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31617"
},
{
"name": "CVE-2026-45996",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45996"
},
{
"name": "CVE-2026-46019",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46019"
},
{
"name": "CVE-2026-43052",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43052"
},
{
"name": "CVE-2026-43496",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43496"
},
{
"name": "CVE-2026-52915",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52915"
},
{
"name": "CVE-2026-53163",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53163"
},
{
"name": "CVE-2026-46173",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46173"
},
{
"name": "CVE-2026-46195",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46195"
},
{
"name": "CVE-2026-46214",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46214"
},
{
"name": "CVE-2026-53146",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53146"
},
{
"name": "CVE-2026-53354",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53354"
},
{
"name": "CVE-2026-31711",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31711"
},
{
"name": "CVE-2026-31611",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31611"
},
{
"name": "CVE-2025-40347",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40347"
},
{
"name": "CVE-2025-39929",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39929"
},
{
"name": "CVE-2026-46027",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46027"
},
{
"name": "CVE-2026-53309",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53309"
},
{
"name": "CVE-2026-46320",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46320"
},
{
"name": "CVE-2023-53989",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53989"
},
{
"name": "CVE-2026-31599",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31599"
},
{
"name": "CVE-2026-46040",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46040"
},
{
"name": "CVE-2026-46236",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46236"
},
{
"name": "CVE-2026-52913",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52913"
},
{
"name": "CVE-2026-46113",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46113"
},
{
"name": "CVE-2025-38710",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38710"
},
{
"name": "CVE-2026-23099",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23099"
},
{
"name": "CVE-2026-43058",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43058"
},
{
"name": "CVE-2026-46137",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46137"
},
{
"name": "CVE-2026-53071",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53071"
},
{
"name": "CVE-2026-52941",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52941"
},
{
"name": "CVE-2026-45841",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45841"
},
{
"name": "CVE-2026-46072",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46072"
},
{
"name": "CVE-2026-53150",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53150"
},
{
"name": "CVE-2026-53327",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53327"
},
{
"name": "CVE-2026-52939",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52939"
},
{
"name": "CVE-2026-23066",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23066"
},
{
"name": "CVE-2026-53147",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53147"
},
{
"name": "CVE-2026-46159",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46159"
},
{
"name": "CVE-2026-52942",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52942"
},
{
"name": "CVE-2026-46190",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46190"
},
{
"name": "CVE-2026-46331",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46331"
},
{
"name": "CVE-2026-46252",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46252"
},
{
"name": "CVE-2025-22105",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22105"
},
{
"name": "CVE-2026-52935",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52935"
},
{
"name": "CVE-2026-53183",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53183"
},
{
"name": "CVE-2026-31583",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31583"
},
{
"name": "CVE-2026-53064",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53064"
},
{
"name": "CVE-2026-31605",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31605"
},
{
"name": "CVE-2026-52995",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52995"
},
{
"name": "CVE-2026-46209",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46209"
},
{
"name": "CVE-2026-52931",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52931"
},
{
"name": "CVE-2026-46031",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46031"
},
{
"name": "CVE-2026-53047",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53047"
},
{
"name": "CVE-2026-53296",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53296"
},
{
"name": "CVE-2026-31732",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31732"
},
{
"name": "CVE-2025-38584",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38584"
},
{
"name": "CVE-2023-54322",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54322"
},
{
"name": "CVE-2026-31681",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31681"
},
{
"name": "CVE-2026-31598",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31598"
},
{
"name": "CVE-2026-46186",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46186"
},
{
"name": "CVE-2026-53101",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53101"
},
{
"name": "CVE-2026-52919",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52919"
},
{
"name": "CVE-2026-46169",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46169"
},
{
"name": "CVE-2026-53006",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53006"
},
{
"name": "CVE-2026-31622",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31622"
},
{
"name": "CVE-2026-43079",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43079"
},
{
"name": "CVE-2026-46002",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46002"
},
{
"name": "CVE-2026-31595",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31595"
},
{
"name": "CVE-2026-46101",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46101"
},
{
"name": "CVE-2026-46099",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46099"
},
{
"name": "CVE-2026-46091",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46091"
},
{
"name": "CVE-2026-43103",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43103"
},
{
"name": "CVE-2026-31642",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31642"
},
{
"name": "CVE-2026-46024",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46024"
},
{
"name": "CVE-2026-23399",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23399"
},
{
"name": "CVE-2026-43350",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43350"
},
{
"name": "CVE-2026-31701",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31701"
},
{
"name": "CVE-2026-53339",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53339"
},
{
"name": "CVE-2026-53266",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53266"
},
{
"name": "CVE-2026-53149",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53149"
},
{
"name": "CVE-2026-46037",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46037"
},
{
"name": "CVE-2026-46116",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46116"
},
{
"name": "CVE-2026-53048",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53048"
},
{
"name": "CVE-2026-43117",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43117"
},
{
"name": "CVE-2026-53176",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53176"
},
{
"name": "CVE-2026-46083",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46083"
},
{
"name": "CVE-2026-46151",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46151"
},
{
"name": "CVE-2026-43493",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43493"
},
{
"name": "CVE-2021-47211",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47211"
},
{
"name": "CVE-2025-38250",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38250"
},
{
"name": "CVE-2026-46220",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46220"
},
{
"name": "CVE-2026-52975",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52975"
},
{
"name": "CVE-2026-31588",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31588"
},
{
"name": "CVE-2026-46127",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46127"
},
{
"name": "CVE-2026-53046",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53046"
},
{
"name": "CVE-2026-53050",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53050"
},
{
"name": "CVE-2026-43080",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43080"
},
{
"name": "CVE-2026-46146",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46146"
},
{
"name": "CVE-2026-45836",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45836"
},
{
"name": "CVE-2026-46178",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46178"
},
{
"name": "CVE-2026-45846",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45846"
},
{
"name": "CVE-2026-43499",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43499"
},
{
"name": "CVE-2026-43495",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43495"
},
{
"name": "CVE-2026-53021",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53021"
},
{
"name": "CVE-2022-49135",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49135"
},
{
"name": "CVE-2026-46133",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46133"
},
{
"name": "CVE-2026-46005",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46005"
},
{
"name": "CVE-2026-31697",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31697"
},
{
"name": "CVE-2026-46069",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46069"
},
{
"name": "CVE-2026-43216",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43216"
},
{
"name": "CVE-2026-31616",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31616"
},
{
"name": "CVE-2026-46122",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46122"
},
{
"name": "CVE-2026-53131",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53131"
},
{
"name": "CVE-2026-46022",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46022"
},
{
"name": "CVE-2026-46323",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46323"
},
{
"name": "CVE-2026-31615",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31615"
},
{
"name": "CVE-2026-46103",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46103"
},
{
"name": "CVE-2026-53219",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53219"
},
{
"name": "CVE-2026-31449",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31449"
},
{
"name": "CVE-2026-46043",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46043"
},
{
"name": "CVE-2026-46120",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46120"
},
{
"name": "CVE-2026-46198",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46198"
},
{
"name": "CVE-2026-43104",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43104"
},
{
"name": "CVE-2026-52954",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52954"
},
{
"name": "CVE-2026-53249",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53249"
},
{
"name": "CVE-2026-53329",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53329"
},
{
"name": "CVE-2025-68201",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68201"
},
{
"name": "CVE-2026-46189",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46189"
},
{
"name": "CVE-2026-53139",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53139"
},
{
"name": "CVE-2026-53217",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53217"
},
{
"name": "CVE-2026-46296",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46296"
},
{
"name": "CVE-2026-53130",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53130"
},
{
"name": "CVE-2026-46128",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46128"
},
{
"name": "CVE-2026-53070",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53070"
},
{
"name": "CVE-2026-52984",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52984"
},
{
"name": "CVE-2026-53088",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53088"
},
{
"name": "CVE-2026-31594",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31594"
},
{
"name": "CVE-2022-50073",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50073"
},
{
"name": "CVE-2026-31580",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31580"
},
{
"name": "CVE-2026-43099",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43099"
},
{
"name": "CVE-2026-46242",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46242"
},
{
"name": "CVE-2026-53065",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53065"
},
{
"name": "CVE-2025-38627",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38627"
},
{
"name": "CVE-2026-46197",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46197"
},
{
"name": "CVE-2026-53361",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53361"
},
{
"name": "CVE-2026-46301",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46301"
},
{
"name": "CVE-2026-52914",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52914"
},
{
"name": "CVE-2026-52916",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52916"
},
{
"name": "CVE-2026-45999",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45999"
},
{
"name": "CVE-2026-53236",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53236"
},
{
"name": "CVE-2026-53225",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53225"
},
{
"name": "CVE-2026-53034",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53034"
},
{
"name": "CVE-2026-53294",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53294"
},
{
"name": "CVE-2026-31705",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31705"
},
{
"name": "CVE-2026-53111",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53111"
},
{
"name": "CVE-2026-53362",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53362"
},
{
"name": "CVE-2026-31684",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31684"
},
{
"name": "CVE-2026-53168",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53168"
},
{
"name": "CVE-2026-52922",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52922"
},
{
"name": "CVE-2026-46180",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46180"
},
{
"name": "CVE-2026-46038",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46038"
},
{
"name": "CVE-2026-31625",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31625"
},
{
"name": "CVE-2026-53209",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53209"
},
{
"name": "CVE-2026-52992",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52992"
},
{
"name": "CVE-2026-53112",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53112"
},
{
"name": "CVE-2026-46206",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46206"
},
{
"name": "CVE-2026-53086",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53086"
},
{
"name": "CVE-2026-53157",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53157"
},
{
"name": "CVE-2025-10263",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-10263"
},
{
"name": "CVE-2026-53135",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53135"
},
{
"name": "CVE-2026-46234",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46234"
},
{
"name": "CVE-2026-46109",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46109"
},
{
"name": "CVE-2026-46062",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46062"
},
{
"name": "CVE-2026-53279",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53279"
},
{
"name": "CVE-2026-46276",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46276"
},
{
"name": "CVE-2026-52981",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52981"
},
{
"name": "CVE-2026-46108",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46108"
},
{
"name": "CVE-2026-53167",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53167"
},
{
"name": "CVE-2026-52927",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52927"
},
{
"name": "CVE-2026-53060",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53060"
},
{
"name": "CVE-2026-53096",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53096"
},
{
"name": "CVE-2026-46321",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46321"
},
{
"name": "CVE-2026-31699",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31699"
},
{
"name": "CVE-2026-46049",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46049"
},
{
"name": "CVE-2026-46285",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46285"
},
{
"name": "CVE-2026-53035",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53035"
},
{
"name": "CVE-2026-53186",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53186"
},
{
"name": "CVE-2024-36922",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36922"
},
{
"name": "CVE-2026-53182",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53182"
},
{
"name": "CVE-2026-45997",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45997"
},
{
"name": "CVE-2026-53177",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53177"
},
{
"name": "CVE-2026-53208",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53208"
},
{
"name": "CVE-2026-53255",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53255"
},
{
"name": "CVE-2026-46070",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46070"
},
{
"name": "CVE-2026-53207",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53207"
},
{
"name": "CVE-2026-46150",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46150"
},
{
"name": "CVE-2026-53314",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53314"
},
{
"name": "CVE-2026-46090",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46090"
},
{
"name": "CVE-2026-45840",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45840"
},
{
"name": "CVE-2026-46044",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46044"
},
{
"name": "CVE-2026-53160",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53160"
},
{
"name": "CVE-2026-23255",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23255"
},
{
"name": "CVE-2026-53245",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53245"
},
{
"name": "CVE-2026-53195",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53195"
},
{
"name": "CVE-2026-53043",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53043"
},
{
"name": "CVE-2026-43075",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43075"
},
{
"name": "CVE-2026-46172",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46172"
},
{
"name": "CVE-2026-31627",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31627"
},
{
"name": "CVE-2024-56657",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56657"
},
{
"name": "CVE-2026-46161",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46161"
},
{
"name": "CVE-2026-46026",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46026"
},
{
"name": "CVE-2025-37864",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37864"
},
{
"name": "CVE-2026-23444",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23444"
},
{
"name": "CVE-2026-53148",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53148"
},
{
"name": "CVE-2022-49183",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49183"
},
{
"name": "CVE-2026-53189",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53189"
},
{
"name": "CVE-2026-45844",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45844"
},
{
"name": "CVE-2026-52985",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52985"
},
{
"name": "CVE-2026-46110",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46110"
},
{
"name": "CVE-2026-52946",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52946"
},
{
"name": "CVE-2026-43501",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43501"
},
{
"name": "CVE-2026-53059",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53059"
},
{
"name": "CVE-2026-53133",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53133"
},
{
"name": "CVE-2026-43093",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43093"
},
{
"name": "CVE-2025-38129",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38129"
},
{
"name": "CVE-2026-31626",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31626"
},
{
"name": "CVE-2026-53263",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53263"
},
{
"name": "CVE-2026-31634",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31634"
},
{
"name": "CVE-2026-46018",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46018"
},
{
"name": "CVE-2026-53012",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53012"
},
{
"name": "CVE-2026-46179",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46179"
},
{
"name": "CVE-2026-45991",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45991"
},
{
"name": "CVE-2026-53356",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53356"
},
{
"name": "CVE-2026-43076",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43076"
},
{
"name": "CVE-2026-46291",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46291"
},
{
"name": "CVE-2026-53069",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53069"
},
{
"name": "CVE-2026-53228",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53228"
},
{
"name": "CVE-2026-53073",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53073"
},
{
"name": "CVE-2022-50552",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50552"
},
{
"name": "CVE-2026-31712",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31712"
},
{
"name": "CVE-2026-46046",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46046"
},
{
"name": "CVE-2026-31686",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31686"
},
{
"name": "CVE-2026-46294",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46294"
},
{
"name": "CVE-2026-46125",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46125"
},
{
"name": "CVE-2026-53194",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53194"
},
{
"name": "CVE-2026-43094",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43094"
},
{
"name": "CVE-2026-53242",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53242"
},
{
"name": "CVE-2026-53341",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53341"
},
{
"name": "CVE-2026-52910",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52910"
},
{
"name": "CVE-2026-46075",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46075"
},
{
"name": "CVE-2026-46167",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46167"
},
{
"name": "CVE-2026-31607",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31607"
},
{
"name": "CVE-2026-53212",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53212"
},
{
"name": "CVE-2026-53137",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53137"
},
{
"name": "CVE-2026-46054",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46054"
},
{
"name": "CVE-2026-45930",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45930"
},
{
"name": "CVE-2026-46191",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46191"
},
{
"name": "CVE-2023-53596",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53596"
},
{
"name": "CVE-2026-53337",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53337"
},
{
"name": "CVE-2026-31716",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31716"
},
{
"name": "CVE-2026-53199",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53199"
},
{
"name": "CVE-2026-43085",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43085"
},
{
"name": "CVE-2026-31637",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31637"
},
{
"name": "CVE-2026-31612",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31612"
},
{
"name": "CVE-2026-31590",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31590"
},
{
"name": "CVE-2026-53289",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53289"
},
{
"name": "CVE-2026-53304",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53304"
},
{
"name": "CVE-2026-43111",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43111"
},
{
"name": "CVE-2026-53268",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53268"
},
{
"name": "CVE-2026-53223",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53223"
},
{
"name": "CVE-2026-53159",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53159"
},
{
"name": "CVE-2026-31419",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31419"
},
{
"name": "CVE-2026-53039",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53039"
},
{
"name": "CVE-2026-53080",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53080"
},
{
"name": "CVE-2026-53004",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53004"
},
{
"name": "CVE-2026-52912",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52912"
},
{
"name": "CVE-2026-46129",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46129"
},
{
"name": "CVE-2025-40164",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40164"
},
{
"name": "CVE-2023-54125",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54125"
},
{
"name": "CVE-2026-46292",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46292"
},
{
"name": "CVE-2026-46006",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46006"
},
{
"name": "CVE-2026-53221",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53221"
},
{
"name": "CVE-2026-31715",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31715"
},
{
"name": "CVE-2026-52998",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52998"
},
{
"name": "CVE-2026-53011",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53011"
},
{
"name": "CVE-2026-31488",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31488"
},
{
"name": "CVE-2026-53275",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53275"
},
{
"name": "CVE-2022-49158",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49158"
},
{
"name": "CVE-2026-52920",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52920"
},
{
"name": "CVE-2026-31532",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31532"
},
{
"name": "CVE-2026-53001",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53001"
},
{
"name": "CVE-2026-52911",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52911"
},
{
"name": "CVE-2026-53295",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53295"
},
{
"name": "CVE-2026-53269",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53269"
},
{
"name": "CVE-2026-45843",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45843"
},
{
"name": "CVE-2026-43355",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43355"
},
{
"name": "CVE-2026-46015",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46015"
},
{
"name": "CVE-2026-46136",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46136"
},
{
"name": "CVE-2026-53357",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53357"
},
{
"name": "CVE-2026-53052",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53052"
},
{
"name": "CVE-2026-53136",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53136"
},
{
"name": "CVE-2026-53215",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53215"
},
{
"name": "CVE-2026-46056",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46056"
},
{
"name": "CVE-2026-46230",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46230"
},
{
"name": "CVE-2026-53216",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53216"
},
{
"name": "CVE-2025-21739",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21739"
},
{
"name": "CVE-2026-31709",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31709"
},
{
"name": "CVE-2026-53253",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53253"
},
{
"name": "CVE-2026-31489",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31489"
},
{
"name": "CVE-2026-53003",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53003"
},
{
"name": "CVE-2026-52948",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52948"
},
{
"name": "CVE-2026-46004",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46004"
},
{
"name": "CVE-2026-46086",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46086"
},
{
"name": "CVE-2026-53252",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53252"
},
{
"name": "CVE-2026-53355",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53355"
},
{
"name": "CVE-2026-46314",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46314"
},
{
"name": "CVE-2026-46149",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46149"
},
{
"name": "CVE-2026-46208",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46208"
},
{
"name": "CVE-2026-53134",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53134"
},
{
"name": "CVE-2026-46205",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46205"
},
{
"name": "CVE-2023-53133",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53133"
},
{
"name": "CVE-2026-53359",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53359"
},
{
"name": "CVE-2026-53016",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53016"
},
{
"name": "CVE-2026-46218",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46218"
},
{
"name": "CVE-2026-52986",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52986"
},
{
"name": "CVE-2026-53077",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53077"
},
{
"name": "CVE-2026-46132",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46132"
},
{
"name": "CVE-2026-46160",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46160"
},
{
"name": "CVE-2026-46177",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46177"
},
{
"name": "CVE-2026-43110",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43110"
},
{
"name": "CVE-2026-46079",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46079"
},
{
"name": "CVE-2026-53256",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53256"
},
{
"name": "CVE-2025-68315",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68315"
},
{
"name": "CVE-2026-53306",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53306"
},
{
"name": "CVE-2026-23389",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23389"
},
{
"name": "CVE-2022-50472",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50472"
},
{
"name": "CVE-2026-43071",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43071"
},
{
"name": "CVE-2026-43303",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43303"
},
{
"name": "CVE-2026-53045",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53045"
},
{
"name": "CVE-2026-43098",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43098"
},
{
"name": "CVE-2026-46306",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46306"
},
{
"name": "CVE-2026-43089",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43089"
},
{
"name": "CVE-2026-53033",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53033"
},
{
"name": "CVE-2026-46021",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46021"
},
{
"name": "CVE-2026-31596",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31596"
},
{
"name": "CVE-2026-31676",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31676"
},
{
"name": "CVE-2026-43112",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43112"
},
{
"name": "CVE-2026-23442",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23442"
},
{
"name": "CVE-2026-31603",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31603"
},
{
"name": "CVE-2026-46107",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46107"
},
{
"name": "CVE-2026-46047",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46047"
},
{
"name": "CVE-2026-46273",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46273"
},
{
"name": "CVE-2026-43502",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43502"
},
{
"name": "CVE-2026-53270",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53270"
},
{
"name": "CVE-2022-48703",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48703"
},
{
"name": "CVE-2026-23310",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23310"
},
{
"name": "CVE-2026-53198",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53198"
},
{
"name": "CVE-2026-53056",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53056"
},
{
"name": "CVE-2026-45994",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45994"
},
{
"name": "CVE-2025-68823",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68823"
},
{
"name": "CVE-2026-31577",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31577"
},
{
"name": "CVE-2026-52909",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52909"
},
{
"name": "CVE-2026-46163",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46163"
},
{
"name": "CVE-2026-31576",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31576"
},
{
"name": "CVE-2026-46164",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46164"
},
{
"name": "CVE-2026-46235",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46235"
},
{
"name": "CVE-2026-45838",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45838"
},
{
"name": "CVE-2026-53264",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53264"
},
{
"name": "CVE-2026-53023",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53023"
},
{
"name": "CVE-2026-53142",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53142"
},
{
"name": "CVE-2026-43497",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43497"
},
{
"name": "CVE-2026-53063",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53063"
},
{
"name": "CVE-2026-46077",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46077"
},
{
"name": "CVE-2026-53273",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53273"
},
{
"name": "CVE-2026-53184",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53184"
},
{
"name": "CVE-2026-52962",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52962"
},
{
"name": "CVE-2026-53093",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53093"
},
{
"name": "CVE-2026-43114",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43114"
},
{
"name": "CVE-2026-31702",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31702"
},
{
"name": "CVE-2026-46187",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46187"
},
{
"name": "CVE-2026-43281",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43281"
},
{
"name": "CVE-2026-31587",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31587"
},
{
"name": "CVE-2026-46168",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46168"
},
{
"name": "CVE-2026-53075",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53075"
},
{
"name": "CVE-2026-45986",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45986"
},
{
"name": "CVE-2026-53325",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53325"
},
{
"name": "CVE-2026-45987",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45987"
},
{
"name": "CVE-2026-31708",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31708"
},
{
"name": "CVE-2026-46299",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46299"
},
{
"name": "CVE-2026-53303",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53303"
},
{
"name": "CVE-2025-21863",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21863"
},
{
"name": "CVE-2021-47188",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47188"
},
{
"name": "CVE-2026-31657",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31657"
},
{
"name": "CVE-2026-31624",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31624"
},
{
"name": "CVE-2026-46050",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46050"
},
{
"name": "CVE-2026-46003",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46003"
},
{
"name": "CVE-2026-46009",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46009"
},
{
"name": "CVE-2026-31585",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31585"
},
{
"name": "CVE-2026-53352",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53352"
},
{
"name": "CVE-2026-53151",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53151"
},
{
"name": "CVE-2026-53254",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53254"
},
{
"name": "CVE-2026-53037",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53037"
},
{
"name": "CVE-2026-53238",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53238"
},
{
"name": "CVE-2026-53072",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53072"
},
{
"name": "CVE-2025-68340",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68340"
},
{
"name": "CVE-2026-52921",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52921"
},
{
"name": "CVE-2026-46023",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46023"
},
{
"name": "CVE-2026-53068",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53068"
},
{
"name": "CVE-2026-52967",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52967"
},
{
"name": "CVE-2026-46304",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46304"
},
{
"name": "CVE-2026-53213",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53213"
},
{
"name": "CVE-2026-52930",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52930"
},
{
"name": "CVE-2026-46275",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46275"
},
{
"name": "CVE-2026-46193",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46193"
},
{
"name": "CVE-2026-52974",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52974"
},
{
"name": "CVE-2026-46033",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46033"
},
{
"name": "CVE-2026-46143",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46143"
},
{
"name": "CVE-2026-52923",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52923"
},
{
"name": "CVE-2026-31500",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31500"
},
{
"name": "CVE-2026-46212",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46212"
},
{
"name": "CVE-2026-45850",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45850"
},
{
"name": "CVE-2026-45834",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45834"
},
{
"name": "CVE-2026-31700",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31700"
},
{
"name": "CVE-2026-31630",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31630"
},
{
"name": "CVE-2026-52933",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52933"
},
{
"name": "CVE-2026-46199",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46199"
},
{
"name": "CVE-2026-43105",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43105"
},
{
"name": "CVE-2026-43116",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43116"
},
{
"name": "CVE-2026-53196",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53196"
},
{
"name": "CVE-2026-46123",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46123"
},
{
"name": "CVE-2026-52969",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52969"
},
{
"name": "CVE-2026-46098",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46098"
},
{
"name": "CVE-2026-53062",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53062"
},
{
"name": "CVE-2024-43902",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43902"
},
{
"name": "CVE-2026-43072",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43072"
},
{
"name": "CVE-2023-53292",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53292"
},
{
"name": "CVE-2026-46165",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46165"
},
{
"name": "CVE-2026-46052",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46052"
},
{
"name": "CVE-2026-46053",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46053"
},
{
"name": "CVE-2026-31407",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31407"
},
{
"name": "CVE-2026-53343",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53343"
},
{
"name": "CVE-2026-53082",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53082"
},
{
"name": "CVE-2026-52926",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52926"
},
{
"name": "CVE-2026-31602",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31602"
},
{
"name": "CVE-2022-49822",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49822"
},
{
"name": "CVE-2026-46238",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46238"
},
{
"name": "CVE-2026-46051",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46051"
},
{
"name": "CVE-2026-52977",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52977"
},
{
"name": "CVE-2026-52917",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52917"
},
{
"name": "CVE-2026-52972",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52972"
},
{
"name": "CVE-2026-53074",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53074"
},
{
"name": "CVE-2026-46322",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46322"
},
{
"name": "CVE-2026-53036",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53036"
},
{
"name": "CVE-2026-45839",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45839"
},
{
"name": "CVE-2026-46088",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46088"
},
{
"name": "CVE-2026-52982",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52982"
},
{
"name": "CVE-2026-31629",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31629"
},
{
"name": "CVE-2026-46102",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46102"
},
{
"name": "CVE-2026-43219",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43219"
},
{
"name": "CVE-2026-53022",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53022"
},
{
"name": "CVE-2026-46078",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46078"
},
{
"name": "CVE-2026-46058",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46058"
},
{
"name": "CVE-2026-43494",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43494"
},
{
"name": "CVE-2026-31673",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31673"
}
],
"initial_release_date": "2026-07-10T00:00:00",
"last_revision_date": "2026-07-10T00:00:00",
"links": [],
"reference": "CERTFR-2026-AVI-0862",
"revisions": [
{
"description": "Version initiale",
"revision_date": "2026-07-10T00: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. Certaines d\u0027entre 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": "2026-07-03",
"title": "Bulletin de s\u00e9curit\u00e9 Debian LTS msg00006",
"url": "https://lists.debian.org/debian-lts-announce/2026/07/msg00006.html"
},
{
"published_at": "2026-07-05",
"title": "Bulletin de s\u00e9curit\u00e9 Debian msg00292",
"url": "https://lists.debian.org/debian-security-announce/2026/msg00292.html"
},
{
"published_at": "2026-07-05",
"title": "Bulletin de s\u00e9curit\u00e9 Debian LTS msg00012",
"url": "https://lists.debian.org/debian-lts-announce/2026/07/msg00012.html"
},
{
"published_at": "2026-07-03",
"title": "Bulletin de s\u00e9curit\u00e9 Debian LTS msg00005",
"url": "https://lists.debian.org/debian-lts-announce/2026/07/msg00005.html"
}
]
}
FKIE_CVE-2021-47211
Vulnerability from fkie_nvd - Published: 2024-04-10 19:15 - Updated: 2026-06-19 13:16| Vendor | Product | Version | |
|---|---|---|---|
| linux | linux_kernel | * |
{
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"sound/usb/clock.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "3455984b16eeb6914caf8b59498ef24fcc1f0a78",
"status": "affected",
"version": "1dc669fed61a4ec4270a89e5fb3535802cc45668",
"versionType": "git"
},
{
"lessThan": "58fa50de595f152900594c28ec9915c169643739",
"status": "affected",
"version": "1dc669fed61a4ec4270a89e5fb3535802cc45668",
"versionType": "git"
},
{
"lessThan": "b97053df0f04747c3c1e021ecbe99db675342954",
"status": "affected",
"version": "1dc669fed61a4ec4270a89e5fb3535802cc45668",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"sound/usb/clock.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "3.10"
},
{
"lessThan": "3.10",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.259",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.5",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "5.16",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"configurations": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "B2845F69-264B-45BD-B7E7-D12B24338382",
"versionEndExcluding": "5.15.5",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nALSA: usb-audio: fix null pointer dereference on pointer cs_desc\n\nThe pointer cs_desc return from snd_usb_find_clock_source could\nbe null, so there is a potential null pointer dereference issue.\nFix this by adding a null check before dereference."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: usb-audio: se corrige la desreferencia de puntero nulo en el puntero cs_desc El puntero cs_desc devuelto por snd_usb_find_clock_source podr\u00eda ser nulo, por lo que existe un posible problema de desreferencia de puntero nulo. Solucione esto agregando una comprobaci\u00f3n de nulo antes de la desreferencia."
}
],
"id": "CVE-2021-47211",
"lastModified": "2026-06-19T13:16:18.337",
"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-2021-47211",
"options": [
{
"exploitation": "none"
},
{
"automatable": "no"
},
{
"technicalImpact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2024-06-21T16:04:02.891188Z",
"version": "2.0.3"
}
}
]
},
"published": "2024-04-10T19:15:48.547",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/3455984b16eeb6914caf8b59498ef24fcc1f0a78"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/58fa50de595f152900594c28ec9915c169643739"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/b97053df0f04747c3c1e021ecbe99db675342954"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/58fa50de595f152900594c28ec9915c169643739"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/b97053df0f04747c3c1e021ecbe99db675342954"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Modified",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "CWE-476"
}
],
"source": "nvd@nist.gov",
"type": "Primary"
}
]
}
GHSA-RV79-7M3P-HX2P
Vulnerability from github – Published: 2024-04-10 21:30 – Updated: 2026-06-19 15:33In the Linux kernel, the following vulnerability has been resolved:
ALSA: usb-audio: fix null pointer dereference on pointer cs_desc
The pointer cs_desc return from snd_usb_find_clock_source could be null, so there is a potential null pointer dereference issue. Fix this by adding a null check before dereference.
{
"affected": [],
"aliases": [
"CVE-2021-47211"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-10T19:15:48Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nALSA: usb-audio: fix null pointer dereference on pointer cs_desc\n\nThe pointer cs_desc return from snd_usb_find_clock_source could\nbe null, so there is a potential null pointer dereference issue.\nFix this by adding a null check before dereference.",
"id": "GHSA-rv79-7m3p-hx2p",
"modified": "2026-06-19T15:33:07Z",
"published": "2024-04-10T21:30:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47211"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3455984b16eeb6914caf8b59498ef24fcc1f0a78"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/58fa50de595f152900594c28ec9915c169643739"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b97053df0f04747c3c1e021ecbe99db675342954"
}
],
"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"
}
]
}
GSD-2021-47211
Vulnerability from gsd - Updated: 2024-04-11 05:05{
"gsd": {
"metadata": {
"exploitCode": "unknown",
"remediation": "unknown",
"reportConfidence": "confirmed",
"type": "vulnerability"
},
"osvSchema": {
"aliases": [
"CVE-2021-47211"
],
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nALSA: usb-audio: fix null pointer dereference on pointer cs_desc\n\nThe pointer cs_desc return from snd_usb_find_clock_source could\nbe null, so there is a potential null pointer dereference issue.\nFix this by adding a null check before dereference.",
"id": "GSD-2021-47211",
"modified": "2024-04-11T05:05:09.705806Z",
"schema_version": "1.4.0"
}
},
"namespaces": {
"cve.org": {
"CVE_data_meta": {
"ASSIGNER": "cve@kernel.org",
"ID": "CVE-2021-47211",
"STATE": "PUBLIC"
},
"affects": {
"vendor": {
"vendor_data": [
{
"product": {
"product_data": [
{
"product_name": "Linux",
"version": {
"version_data": [
{
"version_affected": "\u003c",
"version_name": "1da177e4c3f4",
"version_value": "58fa50de595f"
},
{
"version_value": "not down converted",
"x_cve_json_5_version_data": {
"defaultStatus": "affected",
"versions": [
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.5",
"versionType": "custom"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "5.16",
"versionType": "original_commit_for_fix"
}
]
}
}
]
}
}
]
},
"vendor_name": "Linux"
}
]
}
},
"data_format": "MITRE",
"data_type": "CVE",
"data_version": "4.0",
"description": {
"description_data": [
{
"lang": "eng",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nALSA: usb-audio: fix null pointer dereference on pointer cs_desc\n\nThe pointer cs_desc return from snd_usb_find_clock_source could\nbe null, so there is a potential null pointer dereference issue.\nFix this by adding a null check before dereference."
}
]
},
"generator": {
"engine": "bippy-d175d3acf727"
},
"problemtype": {
"problemtype_data": [
{
"description": [
{
"lang": "eng",
"value": "n/a"
}
]
}
]
},
"references": {
"reference_data": [
{
"name": "https://git.kernel.org/stable/c/58fa50de595f152900594c28ec9915c169643739",
"refsource": "MISC",
"url": "https://git.kernel.org/stable/c/58fa50de595f152900594c28ec9915c169643739"
},
{
"name": "https://git.kernel.org/stable/c/b97053df0f04747c3c1e021ecbe99db675342954",
"refsource": "MISC",
"url": "https://git.kernel.org/stable/c/b97053df0f04747c3c1e021ecbe99db675342954"
}
]
}
},
"nvd.nist.gov": {
"cve": {
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nALSA: usb-audio: fix null pointer dereference on pointer cs_desc\n\nThe pointer cs_desc return from snd_usb_find_clock_source could\nbe null, so there is a potential null pointer dereference issue.\nFix this by adding a null check before dereference."
}
],
"id": "CVE-2021-47211",
"lastModified": "2024-04-10T19:49:51.183",
"metrics": {},
"published": "2024-04-10T19:15:48.547",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/58fa50de595f152900594c28ec9915c169643739"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/b97053df0f04747c3c1e021ecbe99db675342954"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Awaiting Analysis"
}
}
}
}
OESA-2024-1566 (CVE-2021-47182)
Vulnerability from osv_openeuler – Published: 2024-05-11 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:
scsi: core: Fix scsi_mode_sense() buffer length handling
Several problems exist with scsi_mode_sense() buffer length handling:
1) The allocation length field of the MODE SENSE(10) command is 16-bits, occupying bytes 7 and 8 of the CDB. With this command, access to mode pages larger than 255 bytes is thus possible. However, the CDB allocation length field is set by assigning len to byte 8 only, thus truncating buffer length larger than 255.
2) If scsi_mode_sense() is called with len smaller than 8 with sdev->use_10_for_ms set, or smaller than 4 otherwise, the buffer length is increased to 8 and 4 respectively, and the buffer is zero filled with these increased values, thus corrupting the memory following the buffer.
Fix these 2 problems by using put_unaligned_be16() to set the allocation length field of MODE SENSE(10) CDB and by returning an error when len is too small.
Furthermore, if len is larger than 255B, always try MODE SENSE(10) first, even if the device driver did not set sdev->use_10_for_ms. In case of invalid opcode error for MODE SENSE(10), access to mode pages larger than 255 bytes are not retried using MODE SENSE(6). To avoid buffer length overflows for the MODE_SENSE(10) case, check that len is smaller than 65535 bytes.
While at it, also fix the folowing:
-
Use get_unaligned_be16() to retrieve the mode data length and block descriptor length fields of the mode sense reply header instead of using an open coded calculation.
-
Fix the kdoc dbd argument explanation: the DBD bit stands for Disable Block Descriptor, which is the opposite of what the dbd argument description was.(CVE-2021-47182)
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: CT, Fix multiple allocations and memleak of mod acts
CT clear action offload adds additional mod hdr actions to the flow's original mod actions in order to clear the registers which hold ct_state. When such flow also includes encap action, a neigh update event can cause the driver to unoffload the flow and then reoffload it.
Each time this happens, the ct clear handling adds that same set of mod hdr actions to reset ct_state until the max of mod hdr actions is reached.
Also the driver never releases the allocated mod hdr actions and causing a memleak.
Fix above two issues by moving CT clear mod acts allocation into the parsing actions phase and only use it when offloading the rule. The release of mod acts will be done in the normal flow_put().
backtrace: [<000000007316e2f3>] krealloc+0x83/0xd0 [<00000000ef157de1>] mlx5e_mod_hdr_alloc+0x147/0x300 [mlx5_core] [<00000000970ce4ae>] mlx5e_tc_match_to_reg_set_and_get_id+0xd7/0x240 [mlx5_core] [<0000000067c5fa17>] mlx5e_tc_match_to_reg_set+0xa/0x20 [mlx5_core] [<00000000d032eb98>] mlx5_tc_ct_entry_set_registers.isra.0+0x36/0xc0 [mlx5_core] [<00000000fd23b869>] mlx5_tc_ct_flow_offload+0x272/0x1f10 [mlx5_core] [<000000004fc24acc>] mlx5e_tc_offload_fdb_rules.part.0+0x150/0x620 [mlx5_core] [<00000000dc741c17>] mlx5e_tc_encap_flows_add+0x489/0x690 [mlx5_core] [<00000000e92e49d7>] mlx5e_rep_update_flows+0x6e4/0x9b0 [mlx5_core] [<00000000f60f5602>] mlx5e_rep_neigh_update+0x39a/0x5d0 mlx5_core
In the Linux kernel, the following vulnerability has been resolved:
ALSA: usb-audio: fix null pointer dereference on pointer cs_desc
The pointer cs_desc return from snd_usb_find_clock_source could be null, so there is a potential null pointer dereference issue. Fix this by adding a null check before dereference.(CVE-2021-47211)
In the Linux kernel, the following vulnerability has been resolved:
binder: fix race between mmput() and do_exit()
Task A calls binder_update_page_range() to allocate and insert pages on a remote address space from Task B. For this, Task A pins the remote mm via mmget_not_zero() first. This can race with Task B do_exit() and the final mmput() refcount decrement will come from Task A.
Task A | Task B ------------------+------------------ mmget_not_zero() | | do_exit() | exit_mm() | mmput() mmput() | exit_mmap() | remove_vma() | fput() |
In this case, the work of ____fput() from Task B is queued up in Task A as TWA_RESUME. So in theory, Task A returns to userspace and the cleanup work gets executed. However, Task A instead sleep, waiting for a reply from Task B that never comes (it's dead).
This means the binder_deferred_release() is blocked until an unrelated binder event forces Task A to go back to userspace. All the associated death notifications will also be delayed until then.
In order to fix this use mmput_async() that will schedule the work in the corresponding mm->async_put_work WQ instead of Task A.(CVE-2023-52609)
In the Linux kernel, the following vulnerability has been resolved:
net/sched: act_ct: fix skb leak and crash on ooo frags
act_ct adds skb->users before defragmentation. If frags arrive in order, the last frag's reference is reset in:
inet_frag_reasm_prepare skb_morph
which is not straightforward.
However when frags arrive out of order, nobody unref the last frag, and all frags are leaked. The situation is even worse, as initiating packet capture can lead to a crash[0] when skb has been cloned and shared at the same time.
Fix the issue by removing skb_get() before defragmentation. act_ct returns TC_ACT_CONSUMED when defrag failed or in progress.
[0]: [ 843.804823] ------------[ cut here ]------------ [ 843.809659] kernel BUG at net/core/skbuff.c:2091! [ 843.814516] invalid opcode: 0000 [#1] PREEMPT SMP [ 843.819296] CPU: 7 PID: 0 Comm: swapper/7 Kdump: loaded Tainted: G S 6.7.0-rc3 #2 [ 843.824107] Hardware name: XFUSION 1288H V6/BC13MBSBD, BIOS 1.29 11/25/2022 [ 843.828953] RIP: 0010:pskb_expand_head+0x2ac/0x300 [ 843.833805] Code: 8b 70 28 48 85 f6 74 82 48 83 c6 08 bf 01 00 00 00 e8 38 bd ff ff 8b 83 c0 00 00 00 48 03 83 c8 00 00 00 e9 62 ff ff ff 0f 0b <0f> 0b e8 8d d0 ff ff e9 b3 fd ff ff 81 7c 24 14 40 01 00 00 4c 89 [ 843.843698] RSP: 0018:ffffc9000cce07c0 EFLAGS: 00010202 [ 843.848524] RAX: 0000000000000002 RBX: ffff88811a211d00 RCX: 0000000000000820 [ 843.853299] RDX: 0000000000000640 RSI: 0000000000000000 RDI: ffff88811a211d00 [ 843.857974] RBP: ffff888127d39518 R08: 00000000bee97314 R09: 0000000000000000 [ 843.862584] R10: 0000000000000000 R11: ffff8881109f0000 R12: 0000000000000880 [ 843.867147] R13: ffff888127d39580 R14: 0000000000000640 R15: ffff888170f7b900 [ 843.871680] FS: 0000000000000000(0000) GS:ffff889ffffc0000(0000) knlGS:0000000000000000 [ 843.876242] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 843.880778] CR2: 00007fa42affcfb8 CR3: 000000011433a002 CR4: 0000000000770ef0 [ 843.885336] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 843.889809] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 843.894229] PKRU: 55555554 [ 843.898539] Call Trace: [ 843.902772] <IRQ> [ 843.906922] ? __die_body+0x1e/0x60 [ 843.911032] ? die+0x3c/0x60 [ 843.915037] ? do_trap+0xe2/0x110 [ 843.918911] ? pskb_expand_head+0x2ac/0x300 [ 843.922687] ? do_error_trap+0x65/0x80 [ 843.926342] ? pskb_expand_head+0x2ac/0x300 [ 843.929905] ? exc_invalid_op+0x50/0x60 [ 843.933398] ? pskb_expand_head+0x2ac/0x300 [ 843.936835] ? asm_exc_invalid_op+0x1a/0x20 [ 843.940226] ? pskb_expand_head+0x2ac/0x300 [ 843.943580] inet_frag_reasm_prepare+0xd1/0x240 [ 843.946904] ip_defrag+0x5d4/0x870 [ 843.950132] nf_ct_handle_fragments+0xec/0x130 [nf_conntrack] [ 843.953334] tcf_ct_act+0x252/0xd90 [act_ct] [ 843.956473] ? tcf_mirred_act+0x516/0x5a0 [act_mirred] [ 843.959657] tcf_action_exec+0xa1/0x160 [ 843.962823] fl_classify+0x1db/0x1f0 [cls_flower] [ 843.966010] ? skb_clone+0x53/0xc0 [ 843.969173] tcf_classify+0x24d/0x420 [ 843.972333] tc_run+0x8f/0xf0 [ 843.975465] __netif_receive_skb_core+0x67a/0x1080 [ 843.978634] ? dev_gro_receive+0x249/0x730 [ 843.981759] __netif_receive_skb_list_core+0x12d/0x260 [ 843.984869] netif_receive_skb_list_internal+0x1cb/0x2f0 [ 843.987957] ? mlx5e_handle_rx_cqe_mpwrq_rep+0xfa/0x1a0 [mlx5_core] [ 843.991170] napi_complete_done+0x72/0x1a0 [ 843.994305] mlx5e_napi_poll+0x28c/0x6d0 [mlx5_core] [ 843.997501] __napi_poll+0x25/0x1b0 [ 844.000627] net_rx_action+0x256/0x330 [ 844.003705] __do_softirq+0xb3/0x29b [ 844.006718] irq_exit_rcu+0x9e/0xc0 [ 844.009672] common_interrupt+0x86/0xa0 [ 844.012537] </IRQ> [ 844.015285] <TASK> [ 844.017937] asm_common_interrupt+0x26/0x40 [ 844.020591] RIP: 0010:acpi_safe_halt+0x1b/0x20 [ 844.023247] Code: ff 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 65 48 8b 04 25 00 18 03 00 48 8b 00 a8 08 75 0c 66 90 0f 00 2d 81 d0 44 00 fb ---truncated---(CVE-2023-52610)
In the Linux kernel, the following vulnerability has been resolved:
crypto: lib/mpi - Fix unexpected pointer access in mpi_ec_init
When the mpi_ec_ctx structure is initialized, some fields are not cleared, causing a crash when referencing the field when the structure was released. Initially, this issue was ignored because memory for mpi_ec_ctx is allocated with the __GFP_ZERO flag. For example, this error will be triggered when calculating the Za value for SM2 separately.(CVE-2023-52616)
In the Linux kernel, the following vulnerability has been resolved:
block/rnbd-srv: Check for unlikely string overflow
Since "dev_search_path" can technically be as large as PATH_MAX, there was a risk of truncation when copying it and a second string into "full_path" since it was also PATH_MAX sized. The W=1 builds were reporting this warning:
drivers/block/rnbd/rnbd-srv.c: In function 'process_msg_open.isra': drivers/block/rnbd/rnbd-srv.c:616:51: warning: '%s' directive output may be truncated writing up to 254 bytes into a region of size between 0 and 4095 [-Wformat-truncation=] 616 | snprintf(full_path, PATH_MAX, "%s/%s", | ^~ In function 'rnbd_srv_get_full_path', inlined from 'process_msg_open.isra' at drivers/block/rnbd/rnbd-srv.c:721:14: drivers/block/rnbd/rnbd-srv.c:616:17: note: 'snprintf' output between 2 and 4351 bytes into a destination of size 4096 616 | snprintf(full_path, PATH_MAX, "%s/%s", | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 617 | dev_search_path, dev_name); | ~~~~~~~~~~~~~~~~~~~~~~~~~~
To fix this, unconditionally check for truncation (as was already done for the case where "%SESSNAME%" was present).(CVE-2023-52618)
In the Linux kernel, the following vulnerability has been resolved:
llc: Drop support for ETH_P_TR_802_2.
syzbot reported an uninit-value bug below. [0]
llc supports ETH_P_802_2 (0x0004) and used to support ETH_P_TR_802_2 (0x0011), and syzbot abused the latter to trigger the bug.
write$tun(r0, &(0x7f0000000040)={@val={0x0, 0x11}, @val, @mpls={[], @llc={@snap={0xaa, 0x1, ')', "90e5dd"}}}}, 0x16)
llc_conn_handler() initialises local variables {saddr,daddr}.mac based on skb in llc_pdu_decode_sa()/llc_pdu_decode_da() and passes them to __llc_lookup().
However, the initialisation is done only when skb->protocol is htons(ETH_P_802_2), otherwise, __llc_lookup_established() and __llc_lookup_listener() will read garbage.
The missing initialisation existed prior to commit 211ed865108e ("net: delete all instances of special processing for token ring").
It removed the part to kick out the token ring stuff but forgot to close the door allowing ETH_P_TR_802_2 packets to sneak into llc_rcv().
Let's remove llc_tr_packet_type and complete the deprecation.
[0]: BUG: KMSAN: uninit-value in __llc_lookup_established+0xe9d/0xf90 __llc_lookup_established+0xe9d/0xf90 __llc_lookup net/llc/llc_conn.c:611 [inline] llc_conn_handler+0x4bd/0x1360 net/llc/llc_conn.c:791 llc_rcv+0xfbb/0x14a0 net/llc/llc_input.c:206 __netif_receive_skb_one_core net/core/dev.c:5527 [inline] __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5641 netif_receive_skb_internal net/core/dev.c:5727 [inline] netif_receive_skb+0x58/0x660 net/core/dev.c:5786 tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555 tun_get_user+0x53af/0x66d0 drivers/net/tun.c:2002 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048 call_write_iter include/linux/fs.h:2020 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x8ef/0x1490 fs/read_write.c:584 ksys_write+0x20f/0x4c0 fs/read_write.c:637 __do_sys_write fs/read_write.c:649 [inline] __se_sys_write fs/read_write.c:646 [inline] __x64_sys_write+0x93/0xd0 fs/read_write.c:646 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x44/0x110 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x63/0x6b
Local variable daddr created at: llc_conn_handler+0x53/0x1360 net/llc/llc_conn.c:783 llc_rcv+0xfbb/0x14a0 net/llc/llc_input.c:206
CPU: 1 PID: 5004 Comm: syz-executor994 Not tainted 6.6.0-syzkaller-14500-g1c41041124bd #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/09/2023(CVE-2024-26635)
In the Linux kernel, the following vulnerability has been resolved:
llc: make llc_ui_sendmsg() more robust against bonding changes
syzbot was able to trick llc_ui_sendmsg(), allocating an skb with no headroom, but subsequently trying to push 14 bytes of Ethernet header [1]
Like some others, llc_ui_sendmsg() releases the socket lock before calling sock_alloc_send_skb(). Then it acquires it again, but does not redo all the sanity checks that were performed.
This fix:
- Uses LL_RESERVED_SPACE() to reserve space.
- Check all conditions again after socket lock is held again.
- Do not account Ethernet header for mtu limitation.
[1]
skbuff: skb_under_panic: text:ffff800088baa334 len:1514 put:14 head:ffff0000c9c37000 data:ffff0000c9c36ff2 tail:0x5dc end:0x6c0 dev:bond0
kernel BUG at net/core/skbuff.c:193 ! Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP Modules linked in: CPU: 0 PID: 6875 Comm: syz-executor.0 Not tainted 6.7.0-rc8-syzkaller-00101-g0802e17d9aca-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : skb_panic net/core/skbuff.c:189 [inline] pc : skb_under_panic+0x13c/0x140 net/core/skbuff.c:203 lr : skb_panic net/core/skbuff.c:189 [inline] lr : skb_under_panic+0x13c/0x140 net/core/skbuff.c:203 sp : ffff800096f97000 x29: ffff800096f97010 x28: ffff80008cc8d668 x27: dfff800000000000 x26: ffff0000cb970c90 x25: 00000000000005dc x24: ffff0000c9c36ff2 x23: ffff0000c9c37000 x22: 00000000000005ea x21: 00000000000006c0 x20: 000000000000000e x19: ffff800088baa334 x18: 1fffe000368261ce x17: ffff80008e4ed000 x16: ffff80008a8310f8 x15: 0000000000000001 x14: 1ffff00012df2d58 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000001 x10: 0000000000ff0100 x9 : e28a51f1087e8400 x8 : e28a51f1087e8400 x7 : ffff80008028f8d0 x6 : 0000000000000000 x5 : 0000000000000001 x4 : 0000000000000001 x3 : ffff800082b78714 x2 : 0000000000000001 x1 : 0000000100000000 x0 : 0000000000000089 Call trace: skb_panic net/core/skbuff.c:189 [inline] skb_under_panic+0x13c/0x140 net/core/skbuff.c:203 skb_push+0xf0/0x108 net/core/skbuff.c:2451 eth_header+0x44/0x1f8 net/ethernet/eth.c:83 dev_hard_header include/linux/netdevice.h:3188 [inline] llc_mac_hdr_init+0x110/0x17c net/llc/llc_output.c:33 llc_sap_action_send_xid_c+0x170/0x344 net/llc/llc_s_ac.c:85 llc_exec_sap_trans_actions net/llc/llc_sap.c:153 [inline] llc_sap_next_state net/llc/llc_sap.c:182 [inline] llc_sap_state_process+0x1ec/0x774 net/llc/llc_sap.c:209 llc_build_and_send_xid_pkt+0x12c/0x1c0 net/llc/llc_sap.c:270 llc_ui_sendmsg+0x7bc/0xb1c net/llc/af_llc.c:997 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] sock_sendmsg+0x194/0x274 net/socket.c:767 splice_to_socket+0x7cc/0xd58 fs/splice.c:881 do_splice_from fs/splice.c:933 [inline] direct_splice_actor+0xe4/0x1c0 fs/splice.c:1142 splice_direct_to_actor+0x2a0/0x7e4 fs/splice.c:1088 do_splice_direct+0x20c/0x348 fs/splice.c:1194 do_sendfile+0x4bc/0xc70 fs/read_write.c:1254 __do_sys_sendfile64 fs/read_write.c:1322 [inline] __se_sys_sendfile64 fs/read_write.c:1308 [inline] __arm64_sys_sendfile64+0x160/0x3b4 fs/read_write.c:1308 __invoke_syscall arch/arm64/kernel/syscall.c:37 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:51 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:136 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:155 el0_svc+0x54/0x158 arch/arm64/kernel/entry-common.c:678 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:696 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:595 Code: aa1803e6 aa1903e7 a90023f5 94792f6a (d4210000)(CVE-2024-26636)
In the Linux kernel, the following vulnerability has been resolved:
tcp: add sanity checks to rx zerocopy
TCP rx zerocopy intent is to map pages initially allocated from NIC drivers, not pages owned by a fs.
This patch adds to can_map_frag() these additional checks:
- Page must not be a compound one.
- page->mapping must be NULL.
This fixes the panic reported by ZhangPeng.
syzbot was able to loopback packets built with sendfile(), mapping pages owned by an ext4 file to TCP rx zerocopy.
r3 = socket$inet_tcp(0x2, 0x1, 0x0) mmap(&(0x7f0000ff9000/0x4000)=nil, 0x4000, 0x0, 0x12, r3, 0x0) r4 = socket$inet_tcp(0x2, 0x1, 0x0) bind$inet(r4, &(0x7f0000000000)={0x2, 0x4e24, @multicast1}, 0x10) connect$inet(r4, &(0x7f00000006c0)={0x2, 0x4e24, @empty}, 0x10) r5 = openat$dir(0xffffffffffffff9c, &(0x7f00000000c0)='./file0\x00', 0x181e42, 0x0) fallocate(r5, 0x0, 0x0, 0x85b8) sendfile(r4, r5, 0x0, 0x8ba0) getsockopt$inet_tcp_TCP_ZEROCOPY_RECEIVE(r4, 0x6, 0x23, &(0x7f00000001c0)={&(0x7f0000ffb000/0x3000)=nil, 0x3000, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, &(0x7f0000000440)=0x40) r6 = openat$dir(0xffffffffffffff9c, &(0x7f00000000c0)='./file0\x00', 0x181e42, 0x0)(CVE-2024-26640)
In the Linux kernel, the following vulnerability has been resolved:
ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv()
syzbot found __ip6_tnl_rcv() could access unitiliazed data [1].
Call pskb_inet_may_pull() to fix this, and initialize ipv6h variable after this call as it can change skb->head.
[1] BUG: KMSAN: uninit-value in __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline] BUG: KMSAN: uninit-value in INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline] BUG: KMSAN: uninit-value in IP6_ECN_decapsulate+0x7df/0x1e50 include/net/inet_ecn.h:321 __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline] INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline] IP6_ECN_decapsulate+0x7df/0x1e50 include/net/inet_ecn.h:321 ip6ip6_dscp_ecn_decapsulate+0x178/0x1b0 net/ipv6/ip6_tunnel.c:727 __ip6_tnl_rcv+0xd4e/0x1590 net/ipv6/ip6_tunnel.c:845 ip6_tnl_rcv+0xce/0x100 net/ipv6/ip6_tunnel.c:888 gre_rcv+0x143f/0x1870 ip6_protocol_deliver_rcu+0xda6/0x2a60 net/ipv6/ip6_input.c:438 ip6_input_finish net/ipv6/ip6_input.c:483 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] ip6_input+0x15d/0x430 net/ipv6/ip6_input.c:492 ip6_mc_input+0xa7e/0xc80 net/ipv6/ip6_input.c:586 dst_input include/net/dst.h:461 [inline] ip6_rcv_finish+0x5db/0x870 net/ipv6/ip6_input.c:79 NF_HOOK include/linux/netfilter.h:314 [inline] ipv6_rcv+0xda/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core net/core/dev.c:5532 [inline] __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5646 netif_receive_skb_internal net/core/dev.c:5732 [inline] netif_receive_skb+0x58/0x660 net/core/dev.c:5791 tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555 tun_get_user+0x53af/0x66d0 drivers/net/tun.c:2002 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048 call_write_iter include/linux/fs.h:2084 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0x786/0x1200 fs/read_write.c:590 ksys_write+0x20f/0x4c0 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __x64_sys_write+0x93/0xd0 fs/read_write.c:652 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b
Uninit was created at: slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768 slab_alloc_node mm/slub.c:3478 [inline] kmem_cache_alloc_node+0x5e9/0xb10 mm/slub.c:3523 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560 __alloc_skb+0x318/0x740 net/core/skbuff.c:651 alloc_skb include/linux/skbuff.h:1286 [inline] alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6334 sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2787 tun_alloc_skb drivers/net/tun.c:1531 [inline] tun_get_user+0x1e8a/0x66d0 drivers/net/tun.c:1846 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048 call_write_iter include/linux/fs.h:2084 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0x786/0x1200 fs/read_write.c:590 ksys_write+0x20f/0x4c0 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __x64_sys_write+0x93/0xd0 fs/read_write.c:652 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b
CPU: 0 PID: 5034 Comm: syz-executor331 Not tainted 6.7.0-syzkaller-00562-g9f8413c4a66f #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023(CVE-2024-26641)
In the Linux kernel, the following vulnerability has been resolved:
l2tp: pass correct message length to ip6_append_data
l2tp_ip6_sendmsg needs to avoid accounting for the transport header twice when splicing more data into an already partially-occupied skbuff.
To manage this, we check whether the skbuff contains data using skb_queue_empty when deciding how much data to append using ip6_append_data.
However, the code which performed the calculation was incorrect:
ulen = len + skb_queue_empty(&sk->sk_write_queue) ? transhdrlen : 0;
...due to C operator precedence, this ends up setting ulen to transhdrlen for messages with a non-zero length, which results in corrupted packets on the wire.
Add parentheses to correct the calculation in line with the original intent.(CVE-2024-26752)
In the Linux kernel, the following vulnerability has been resolved:
IB/hfi1: Fix sdma.h tx->num_descs off-by-one error
Unfortunately the commit fd8958efe877 introduced another error
causing the descs array to overflow. This reults in further crashes
easily reproducible by sendmsg system call.
[ 1080.836473] general protection fault, probably for non-canonical address 0x400300015528b00a: 0000 [#1] PREEMPT SMP PTI [ 1080.869326] RIP: 0010:hfi1_ipoib_build_ib_tx_headers.constprop.0+0xe1/0x2b0 [hfi1] -- [ 1080.974535] Call Trace: [ 1080.976990] <TASK> [ 1081.021929] hfi1_ipoib_send_dma_common+0x7a/0x2e0 [hfi1] [ 1081.027364] hfi1_ipoib_send_dma_list+0x62/0x270 [hfi1] [ 1081.032633] hfi1_ipoib_send+0x112/0x300 [hfi1] [ 1081.042001] ipoib_start_xmit+0x2a9/0x2d0 [ib_ipoib] [ 1081.046978] dev_hard_start_xmit+0xc4/0x210 -- [ 1081.148347] __sys_sendmsg+0x59/0xa0
crash> ipoib_txreq 0xffff9cfeba229f00 struct ipoib_txreq { txreq = { list = { next = 0xffff9cfeba229f00, prev = 0xffff9cfeba229f00 }, descp = 0xffff9cfeba229f40, coalesce_buf = 0x0, wait = 0xffff9cfea4e69a48, complete = 0xffffffffc0fe0760 <hfi1_ipoib_sdma_complete>, packet_len = 0x46d, tlen = 0x0, num_desc = 0x0, desc_limit = 0x6, next_descq_idx = 0x45c, coalesce_idx = 0x0, flags = 0x0, descs = {{ qw = {0x8024000120dffb00, 0x4} # SDMA_DESC0_FIRST_DESC_FLAG (bit 63) }, { qw = { 0x3800014231b108, 0x4} }, { qw = { 0x310000e4ee0fcf0, 0x8} }, { qw = { 0x3000012e9f8000, 0x8} }, { qw = { 0x59000dfb9d0000, 0x8} }, { qw = { 0x78000e02e40000, 0x8} }} }, sdma_hdr = 0x400300015528b000, <<< invalid pointer in the tx request structure sdma_status = 0x0, SDMA_DESC0_LAST_DESC_FLAG (bit 62) complete = 0x0, priv = 0x0, txq = 0xffff9cfea4e69880, skb = 0xffff9d099809f400 }
If an SDMA send consists of exactly 6 descriptors and requires dword padding (in the 7th descriptor), the sdma_txreq descriptor array is not properly expanded and the packet will overflow into the container structure. This results in a panic when the send completion runs. The exact panic varies depending on what elements of the container structure get corrupted. The fix is to use the correct expression in _pad_sdma_tx_descs() to test the need to expand the descriptor array.
With this patch the crashes are no longer reproducible and the machine is stable.(CVE-2024-26766)
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"kernel-source-5.10.0-198.0.0.111.oe2203sp3.aarch64.rpm",
"kernel-debugsource-5.10.0-198.0.0.111.oe2203sp3.aarch64.rpm",
"kernel-tools-devel-5.10.0-198.0.0.111.oe2203sp3.aarch64.rpm",
"perf-debuginfo-5.10.0-198.0.0.111.oe2203sp3.aarch64.rpm",
"python3-perf-5.10.0-198.0.0.111.oe2203sp3.aarch64.rpm",
"kernel-debuginfo-5.10.0-198.0.0.111.oe2203sp3.aarch64.rpm",
"kernel-devel-5.10.0-198.0.0.111.oe2203sp3.aarch64.rpm",
"kernel-headers-5.10.0-198.0.0.111.oe2203sp3.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-198.0.0.111.oe2203sp3.aarch64.rpm",
"kernel-5.10.0-198.0.0.111.oe2203sp3.aarch64.rpm",
"kernel-tools-debuginfo-5.10.0-198.0.0.111.oe2203sp3.aarch64.rpm",
"perf-5.10.0-198.0.0.111.oe2203sp3.aarch64.rpm",
"kernel-tools-5.10.0-198.0.0.111.oe2203sp3.aarch64.rpm"
],
"src": [
"kernel-5.10.0-198.0.0.111.oe2203sp3.src.rpm"
],
"x86_64": [
"kernel-debugsource-5.10.0-198.0.0.111.oe2203sp3.x86_64.rpm",
"kernel-devel-5.10.0-198.0.0.111.oe2203sp3.x86_64.rpm",
"perf-debuginfo-5.10.0-198.0.0.111.oe2203sp3.x86_64.rpm",
"kernel-headers-5.10.0-198.0.0.111.oe2203sp3.x86_64.rpm",
"kernel-5.10.0-198.0.0.111.oe2203sp3.x86_64.rpm",
"kernel-tools-5.10.0-198.0.0.111.oe2203sp3.x86_64.rpm",
"kernel-tools-debuginfo-5.10.0-198.0.0.111.oe2203sp3.x86_64.rpm",
"perf-5.10.0-198.0.0.111.oe2203sp3.x86_64.rpm",
"python3-perf-debuginfo-5.10.0-198.0.0.111.oe2203sp3.x86_64.rpm",
"kernel-source-5.10.0-198.0.0.111.oe2203sp3.x86_64.rpm",
"python3-perf-5.10.0-198.0.0.111.oe2203sp3.x86_64.rpm",
"kernel-tools-devel-5.10.0-198.0.0.111.oe2203sp3.x86_64.rpm",
"kernel-debuginfo-5.10.0-198.0.0.111.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-198.0.0.111.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\nscsi: core: Fix scsi_mode_sense() buffer length handling\r\n\r\nSeveral problems exist with scsi_mode_sense() buffer length handling:\r\n\r\n 1) The allocation length field of the MODE SENSE(10) command is 16-bits,\n occupying bytes 7 and 8 of the CDB. With this command, access to mode\n pages larger than 255 bytes is thus possible. However, the CDB\n allocation length field is set by assigning len to byte 8 only, thus\n truncating buffer length larger than 255.\r\n\r\n 2) If scsi_mode_sense() is called with len smaller than 8 with\n sdev-\u0026gt;use_10_for_ms set, or smaller than 4 otherwise, the buffer length\n is increased to 8 and 4 respectively, and the buffer is zero filled\n with these increased values, thus corrupting the memory following the\n buffer.\r\n\r\nFix these 2 problems by using put_unaligned_be16() to set the allocation\nlength field of MODE SENSE(10) CDB and by returning an error when len is\ntoo small.\r\n\r\nFurthermore, if len is larger than 255B, always try MODE SENSE(10) first,\neven if the device driver did not set sdev-\u0026gt;use_10_for_ms. In case of\ninvalid opcode error for MODE SENSE(10), access to mode pages larger than\n255 bytes are not retried using MODE SENSE(6). To avoid buffer length\noverflows for the MODE_SENSE(10) case, check that len is smaller than 65535\nbytes.\r\n\r\nWhile at it, also fix the folowing:\r\n\r\n * Use get_unaligned_be16() to retrieve the mode data length and block\n descriptor length fields of the mode sense reply header instead of using\n an open coded calculation.\r\n\r\n * Fix the kdoc dbd argument explanation: the DBD bit stands for Disable\n Block Descriptor, which is the opposite of what the dbd argument\n description was.(CVE-2021-47182)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/mlx5e: CT, Fix multiple allocations and memleak of mod acts\r\n\r\nCT clear action offload adds additional mod hdr actions to the\nflow\u0026apos;s original mod actions in order to clear the registers which\nhold ct_state.\nWhen such flow also includes encap action, a neigh update event\ncan cause the driver to unoffload the flow and then reoffload it.\r\n\r\nEach time this happens, the ct clear handling adds that same set\nof mod hdr actions to reset ct_state until the max of mod hdr\nactions is reached.\r\n\r\nAlso the driver never releases the allocated mod hdr actions and\ncausing a memleak.\r\n\r\nFix above two issues by moving CT clear mod acts allocation\ninto the parsing actions phase and only use it when offloading the rule.\nThe release of mod acts will be done in the normal flow_put().\r\n\r\n backtrace:\n [\u0026lt;000000007316e2f3\u0026gt;] krealloc+0x83/0xd0\n [\u0026lt;00000000ef157de1\u0026gt;] mlx5e_mod_hdr_alloc+0x147/0x300 [mlx5_core]\n [\u0026lt;00000000970ce4ae\u0026gt;] mlx5e_tc_match_to_reg_set_and_get_id+0xd7/0x240 [mlx5_core]\n [\u0026lt;0000000067c5fa17\u0026gt;] mlx5e_tc_match_to_reg_set+0xa/0x20 [mlx5_core]\n [\u0026lt;00000000d032eb98\u0026gt;] mlx5_tc_ct_entry_set_registers.isra.0+0x36/0xc0 [mlx5_core]\n [\u0026lt;00000000fd23b869\u0026gt;] mlx5_tc_ct_flow_offload+0x272/0x1f10 [mlx5_core]\n [\u0026lt;000000004fc24acc\u0026gt;] mlx5e_tc_offload_fdb_rules.part.0+0x150/0x620 [mlx5_core]\n [\u0026lt;00000000dc741c17\u0026gt;] mlx5e_tc_encap_flows_add+0x489/0x690 [mlx5_core]\n [\u0026lt;00000000e92e49d7\u0026gt;] mlx5e_rep_update_flows+0x6e4/0x9b0 [mlx5_core]\n [\u0026lt;00000000f60f5602\u0026gt;] mlx5e_rep_neigh_update+0x39a/0x5d0 [mlx5_core](CVE-2021-47199)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nALSA: usb-audio: fix null pointer dereference on pointer cs_desc\r\n\r\nThe pointer cs_desc return from snd_usb_find_clock_source could\nbe null, so there is a potential null pointer dereference issue.\nFix this by adding a null check before dereference.(CVE-2021-47211)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbinder: fix race between mmput() and do_exit()\r\n\r\nTask A calls binder_update_page_range() to allocate and insert pages on\na remote address space from Task B. For this, Task A pins the remote mm\nvia mmget_not_zero() first. This can race with Task B do_exit() and the\nfinal mmput() refcount decrement will come from Task A.\r\n\r\n Task A | Task B\n ------------------+------------------\n mmget_not_zero() |\n | do_exit()\n | exit_mm()\n | mmput()\n mmput() |\n exit_mmap() |\n remove_vma() |\n fput() |\r\n\r\nIn this case, the work of ____fput() from Task B is queued up in Task A\nas TWA_RESUME. So in theory, Task A returns to userspace and the cleanup\nwork gets executed. However, Task A instead sleep, waiting for a reply\nfrom Task B that never comes (it\u0026apos;s dead).\r\n\r\nThis means the binder_deferred_release() is blocked until an unrelated\nbinder event forces Task A to go back to userspace. All the associated\ndeath notifications will also be delayed until then.\r\n\r\nIn order to fix this use mmput_async() that will schedule the work in\nthe corresponding mm-\u0026gt;async_put_work WQ instead of Task A.(CVE-2023-52609)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/sched: act_ct: fix skb leak and crash on ooo frags\r\n\r\nact_ct adds skb-\u0026gt;users before defragmentation. If frags arrive in order,\nthe last frag\u0026apos;s reference is reset in:\r\n\r\n inet_frag_reasm_prepare\n skb_morph\r\n\r\nwhich is not straightforward.\r\n\r\nHowever when frags arrive out of order, nobody unref the last frag, and\nall frags are leaked. The situation is even worse, as initiating packet\ncapture can lead to a crash[0] when skb has been cloned and shared at the\nsame time.\r\n\r\nFix the issue by removing skb_get() before defragmentation. act_ct\nreturns TC_ACT_CONSUMED when defrag failed or in progress.\r\n\r\n[0]:\n[ 843.804823] ------------[ cut here ]------------\n[ 843.809659] kernel BUG at net/core/skbuff.c:2091!\n[ 843.814516] invalid opcode: 0000 [#1] PREEMPT SMP\n[ 843.819296] CPU: 7 PID: 0 Comm: swapper/7 Kdump: loaded Tainted: G S 6.7.0-rc3 #2\n[ 843.824107] Hardware name: XFUSION 1288H V6/BC13MBSBD, BIOS 1.29 11/25/2022\n[ 843.828953] RIP: 0010:pskb_expand_head+0x2ac/0x300\n[ 843.833805] Code: 8b 70 28 48 85 f6 74 82 48 83 c6 08 bf 01 00 00 00 e8 38 bd ff ff 8b 83 c0 00 00 00 48 03 83 c8 00 00 00 e9 62 ff ff ff 0f 0b \u0026lt;0f\u0026gt; 0b e8 8d d0 ff ff e9 b3 fd ff ff 81 7c 24 14 40 01 00 00 4c 89\n[ 843.843698] RSP: 0018:ffffc9000cce07c0 EFLAGS: 00010202\n[ 843.848524] RAX: 0000000000000002 RBX: ffff88811a211d00 RCX: 0000000000000820\n[ 843.853299] RDX: 0000000000000640 RSI: 0000000000000000 RDI: ffff88811a211d00\n[ 843.857974] RBP: ffff888127d39518 R08: 00000000bee97314 R09: 0000000000000000\n[ 843.862584] R10: 0000000000000000 R11: ffff8881109f0000 R12: 0000000000000880\n[ 843.867147] R13: ffff888127d39580 R14: 0000000000000640 R15: ffff888170f7b900\n[ 843.871680] FS: 0000000000000000(0000) GS:ffff889ffffc0000(0000) knlGS:0000000000000000\n[ 843.876242] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 843.880778] CR2: 00007fa42affcfb8 CR3: 000000011433a002 CR4: 0000000000770ef0\n[ 843.885336] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[ 843.889809] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[ 843.894229] PKRU: 55555554\n[ 843.898539] Call Trace:\n[ 843.902772] \u0026lt;IRQ\u0026gt;\n[ 843.906922] ? __die_body+0x1e/0x60\n[ 843.911032] ? die+0x3c/0x60\n[ 843.915037] ? do_trap+0xe2/0x110\n[ 843.918911] ? pskb_expand_head+0x2ac/0x300\n[ 843.922687] ? do_error_trap+0x65/0x80\n[ 843.926342] ? pskb_expand_head+0x2ac/0x300\n[ 843.929905] ? exc_invalid_op+0x50/0x60\n[ 843.933398] ? pskb_expand_head+0x2ac/0x300\n[ 843.936835] ? asm_exc_invalid_op+0x1a/0x20\n[ 843.940226] ? pskb_expand_head+0x2ac/0x300\n[ 843.943580] inet_frag_reasm_prepare+0xd1/0x240\n[ 843.946904] ip_defrag+0x5d4/0x870\n[ 843.950132] nf_ct_handle_fragments+0xec/0x130 [nf_conntrack]\n[ 843.953334] tcf_ct_act+0x252/0xd90 [act_ct]\n[ 843.956473] ? tcf_mirred_act+0x516/0x5a0 [act_mirred]\n[ 843.959657] tcf_action_exec+0xa1/0x160\n[ 843.962823] fl_classify+0x1db/0x1f0 [cls_flower]\n[ 843.966010] ? skb_clone+0x53/0xc0\n[ 843.969173] tcf_classify+0x24d/0x420\n[ 843.972333] tc_run+0x8f/0xf0\n[ 843.975465] __netif_receive_skb_core+0x67a/0x1080\n[ 843.978634] ? dev_gro_receive+0x249/0x730\n[ 843.981759] __netif_receive_skb_list_core+0x12d/0x260\n[ 843.984869] netif_receive_skb_list_internal+0x1cb/0x2f0\n[ 843.987957] ? mlx5e_handle_rx_cqe_mpwrq_rep+0xfa/0x1a0 [mlx5_core]\n[ 843.991170] napi_complete_done+0x72/0x1a0\n[ 843.994305] mlx5e_napi_poll+0x28c/0x6d0 [mlx5_core]\n[ 843.997501] __napi_poll+0x25/0x1b0\n[ 844.000627] net_rx_action+0x256/0x330\n[ 844.003705] __do_softirq+0xb3/0x29b\n[ 844.006718] irq_exit_rcu+0x9e/0xc0\n[ 844.009672] common_interrupt+0x86/0xa0\n[ 844.012537] \u0026lt;/IRQ\u0026gt;\n[ 844.015285] \u0026lt;TASK\u0026gt;\n[ 844.017937] asm_common_interrupt+0x26/0x40\n[ 844.020591] RIP: 0010:acpi_safe_halt+0x1b/0x20\n[ 844.023247] Code: ff 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 65 48 8b 04 25 00 18 03 00 48 8b 00 a8 08 75 0c 66 90 0f 00 2d 81 d0 44 00 fb\n---truncated---(CVE-2023-52610)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncrypto: lib/mpi - Fix unexpected pointer access in mpi_ec_init\r\n\r\nWhen the mpi_ec_ctx structure is initialized, some fields are not\ncleared, causing a crash when referencing the field when the\nstructure was released. Initially, this issue was ignored because\nmemory for mpi_ec_ctx is allocated with the __GFP_ZERO flag.\nFor example, this error will be triggered when calculating the\nZa value for SM2 separately.(CVE-2023-52616)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nblock/rnbd-srv: Check for unlikely string overflow\r\n\r\nSince \u0026quot;dev_search_path\u0026quot; can technically be as large as PATH_MAX,\nthere was a risk of truncation when copying it and a second string\ninto \u0026quot;full_path\u0026quot; since it was also PATH_MAX sized. The W=1 builds were\nreporting this warning:\r\n\r\ndrivers/block/rnbd/rnbd-srv.c: In function \u0026apos;process_msg_open.isra\u0026apos;:\ndrivers/block/rnbd/rnbd-srv.c:616:51: warning: \u0026apos;%s\u0026apos; directive output may be truncated writing up to 254 bytes into a region of size between 0 and 4095 [-Wformat-truncation=]\n 616 | snprintf(full_path, PATH_MAX, \u0026quot;%s/%s\u0026quot;,\n | ^~\nIn function \u0026apos;rnbd_srv_get_full_path\u0026apos;,\n inlined from \u0026apos;process_msg_open.isra\u0026apos; at drivers/block/rnbd/rnbd-srv.c:721:14: drivers/block/rnbd/rnbd-srv.c:616:17: note: \u0026apos;snprintf\u0026apos; output between 2 and 4351 bytes into a destination of size 4096\n 616 | snprintf(full_path, PATH_MAX, \u0026quot;%s/%s\u0026quot;,\n | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n 617 | dev_search_path, dev_name);\n | ~~~~~~~~~~~~~~~~~~~~~~~~~~\r\n\r\nTo fix this, unconditionally check for truncation (as was already done\nfor the case where \u0026quot;%SESSNAME%\u0026quot; was present).(CVE-2023-52618)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nllc: Drop support for ETH_P_TR_802_2.\r\n\r\nsyzbot reported an uninit-value bug below. [0]\r\n\r\nllc supports ETH_P_802_2 (0x0004) and used to support ETH_P_TR_802_2\n(0x0011), and syzbot abused the latter to trigger the bug.\r\n\r\n write$tun(r0, \u0026amp;(0x7f0000000040)={@val={0x0, 0x11}, @val, @mpls={[], @llc={@snap={0xaa, 0x1, \u0026apos;)\u0026apos;, \u0026quot;90e5dd\u0026quot;}}}}, 0x16)\r\n\r\nllc_conn_handler() initialises local variables {saddr,daddr}.mac\nbased on skb in llc_pdu_decode_sa()/llc_pdu_decode_da() and passes\nthem to __llc_lookup().\r\n\r\nHowever, the initialisation is done only when skb-\u0026gt;protocol is\nhtons(ETH_P_802_2), otherwise, __llc_lookup_established() and\n__llc_lookup_listener() will read garbage.\r\n\r\nThe missing initialisation existed prior to commit 211ed865108e\n(\u0026quot;net: delete all instances of special processing for token ring\u0026quot;).\r\n\r\nIt removed the part to kick out the token ring stuff but forgot to\nclose the door allowing ETH_P_TR_802_2 packets to sneak into llc_rcv().\r\n\r\nLet\u0026apos;s remove llc_tr_packet_type and complete the deprecation.\r\n\r\n[0]:\nBUG: KMSAN: uninit-value in __llc_lookup_established+0xe9d/0xf90\n __llc_lookup_established+0xe9d/0xf90\n __llc_lookup net/llc/llc_conn.c:611 [inline]\n llc_conn_handler+0x4bd/0x1360 net/llc/llc_conn.c:791\n llc_rcv+0xfbb/0x14a0 net/llc/llc_input.c:206\n __netif_receive_skb_one_core net/core/dev.c:5527 [inline]\n __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5641\n netif_receive_skb_internal net/core/dev.c:5727 [inline]\n netif_receive_skb+0x58/0x660 net/core/dev.c:5786\n tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555\n tun_get_user+0x53af/0x66d0 drivers/net/tun.c:2002\n tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048\n call_write_iter include/linux/fs.h:2020 [inline]\n new_sync_write fs/read_write.c:491 [inline]\n vfs_write+0x8ef/0x1490 fs/read_write.c:584\n ksys_write+0x20f/0x4c0 fs/read_write.c:637\n __do_sys_write fs/read_write.c:649 [inline]\n __se_sys_write fs/read_write.c:646 [inline]\n __x64_sys_write+0x93/0xd0 fs/read_write.c:646\n do_syscall_x64 arch/x86/entry/common.c:51 [inline]\n do_syscall_64+0x44/0x110 arch/x86/entry/common.c:82\n entry_SYSCALL_64_after_hwframe+0x63/0x6b\r\n\r\nLocal variable daddr created at:\n llc_conn_handler+0x53/0x1360 net/llc/llc_conn.c:783\n llc_rcv+0xfbb/0x14a0 net/llc/llc_input.c:206\r\n\r\nCPU: 1 PID: 5004 Comm: syz-executor994 Not tainted 6.6.0-syzkaller-14500-g1c41041124bd #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/09/2023(CVE-2024-26635)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nllc: make llc_ui_sendmsg() more robust against bonding changes\r\n\r\nsyzbot was able to trick llc_ui_sendmsg(), allocating an skb with no\nheadroom, but subsequently trying to push 14 bytes of Ethernet header [1]\r\n\r\nLike some others, llc_ui_sendmsg() releases the socket lock before\ncalling sock_alloc_send_skb().\nThen it acquires it again, but does not redo all the sanity checks\nthat were performed.\r\n\r\nThis fix:\r\n\r\n- Uses LL_RESERVED_SPACE() to reserve space.\n- Check all conditions again after socket lock is held again.\n- Do not account Ethernet header for mtu limitation.\r\n\r\n[1]\r\n\r\nskbuff: skb_under_panic: text:ffff800088baa334 len:1514 put:14 head:ffff0000c9c37000 data:ffff0000c9c36ff2 tail:0x5dc end:0x6c0 dev:bond0\r\n\r\n kernel BUG at net/core/skbuff.c:193 !\nInternal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP\nModules linked in:\nCPU: 0 PID: 6875 Comm: syz-executor.0 Not tainted 6.7.0-rc8-syzkaller-00101-g0802e17d9aca-dirty #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023\npstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : skb_panic net/core/skbuff.c:189 [inline]\n pc : skb_under_panic+0x13c/0x140 net/core/skbuff.c:203\n lr : skb_panic net/core/skbuff.c:189 [inline]\n lr : skb_under_panic+0x13c/0x140 net/core/skbuff.c:203\nsp : ffff800096f97000\nx29: ffff800096f97010 x28: ffff80008cc8d668 x27: dfff800000000000\nx26: ffff0000cb970c90 x25: 00000000000005dc x24: ffff0000c9c36ff2\nx23: ffff0000c9c37000 x22: 00000000000005ea x21: 00000000000006c0\nx20: 000000000000000e x19: ffff800088baa334 x18: 1fffe000368261ce\nx17: ffff80008e4ed000 x16: ffff80008a8310f8 x15: 0000000000000001\nx14: 1ffff00012df2d58 x13: 0000000000000000 x12: 0000000000000000\nx11: 0000000000000001 x10: 0000000000ff0100 x9 : e28a51f1087e8400\nx8 : e28a51f1087e8400 x7 : ffff80008028f8d0 x6 : 0000000000000000\nx5 : 0000000000000001 x4 : 0000000000000001 x3 : ffff800082b78714\nx2 : 0000000000000001 x1 : 0000000100000000 x0 : 0000000000000089\nCall trace:\n skb_panic net/core/skbuff.c:189 [inline]\n skb_under_panic+0x13c/0x140 net/core/skbuff.c:203\n skb_push+0xf0/0x108 net/core/skbuff.c:2451\n eth_header+0x44/0x1f8 net/ethernet/eth.c:83\n dev_hard_header include/linux/netdevice.h:3188 [inline]\n llc_mac_hdr_init+0x110/0x17c net/llc/llc_output.c:33\n llc_sap_action_send_xid_c+0x170/0x344 net/llc/llc_s_ac.c:85\n llc_exec_sap_trans_actions net/llc/llc_sap.c:153 [inline]\n llc_sap_next_state net/llc/llc_sap.c:182 [inline]\n llc_sap_state_process+0x1ec/0x774 net/llc/llc_sap.c:209\n llc_build_and_send_xid_pkt+0x12c/0x1c0 net/llc/llc_sap.c:270\n llc_ui_sendmsg+0x7bc/0xb1c net/llc/af_llc.c:997\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg net/socket.c:745 [inline]\n sock_sendmsg+0x194/0x274 net/socket.c:767\n splice_to_socket+0x7cc/0xd58 fs/splice.c:881\n do_splice_from fs/splice.c:933 [inline]\n direct_splice_actor+0xe4/0x1c0 fs/splice.c:1142\n splice_direct_to_actor+0x2a0/0x7e4 fs/splice.c:1088\n do_splice_direct+0x20c/0x348 fs/splice.c:1194\n do_sendfile+0x4bc/0xc70 fs/read_write.c:1254\n __do_sys_sendfile64 fs/read_write.c:1322 [inline]\n __se_sys_sendfile64 fs/read_write.c:1308 [inline]\n __arm64_sys_sendfile64+0x160/0x3b4 fs/read_write.c:1308\n __invoke_syscall arch/arm64/kernel/syscall.c:37 [inline]\n invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:51\n el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:136\n do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:155\n el0_svc+0x54/0x158 arch/arm64/kernel/entry-common.c:678\n el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:696\n el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:595\nCode: aa1803e6 aa1903e7 a90023f5 94792f6a (d4210000)(CVE-2024-26636)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntcp: add sanity checks to rx zerocopy\r\n\r\nTCP rx zerocopy intent is to map pages initially allocated\nfrom NIC drivers, not pages owned by a fs.\r\n\r\nThis patch adds to can_map_frag() these additional checks:\r\n\r\n- Page must not be a compound one.\n- page-\u0026gt;mapping must be NULL.\r\n\r\nThis fixes the panic reported by ZhangPeng.\r\n\r\nsyzbot was able to loopback packets built with sendfile(),\nmapping pages owned by an ext4 file to TCP rx zerocopy.\r\n\r\nr3 = socket$inet_tcp(0x2, 0x1, 0x0)\nmmap(\u0026amp;(0x7f0000ff9000/0x4000)=nil, 0x4000, 0x0, 0x12, r3, 0x0)\nr4 = socket$inet_tcp(0x2, 0x1, 0x0)\nbind$inet(r4, \u0026amp;(0x7f0000000000)={0x2, 0x4e24, @multicast1}, 0x10)\nconnect$inet(r4, \u0026amp;(0x7f00000006c0)={0x2, 0x4e24, @empty}, 0x10)\nr5 = openat$dir(0xffffffffffffff9c, \u0026amp;(0x7f00000000c0)=\u0026apos;./file0\\x00\u0026apos;,\n 0x181e42, 0x0)\nfallocate(r5, 0x0, 0x0, 0x85b8)\nsendfile(r4, r5, 0x0, 0x8ba0)\ngetsockopt$inet_tcp_TCP_ZEROCOPY_RECEIVE(r4, 0x6, 0x23,\n \u0026amp;(0x7f00000001c0)={\u0026amp;(0x7f0000ffb000/0x3000)=nil, 0x3000, 0x0, 0x0, 0x0,\n 0x0, 0x0, 0x0, 0x0}, \u0026amp;(0x7f0000000440)=0x40)\nr6 = openat$dir(0xffffffffffffff9c, \u0026amp;(0x7f00000000c0)=\u0026apos;./file0\\x00\u0026apos;,\n 0x181e42, 0x0)(CVE-2024-26640)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv()\r\n\r\nsyzbot found __ip6_tnl_rcv() could access unitiliazed data [1].\r\n\r\nCall pskb_inet_may_pull() to fix this, and initialize ipv6h\nvariable after this call as it can change skb-\u0026gt;head.\r\n\r\n[1]\n BUG: KMSAN: uninit-value in __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline]\n BUG: KMSAN: uninit-value in INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline]\n BUG: KMSAN: uninit-value in IP6_ECN_decapsulate+0x7df/0x1e50 include/net/inet_ecn.h:321\n __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline]\n INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline]\n IP6_ECN_decapsulate+0x7df/0x1e50 include/net/inet_ecn.h:321\n ip6ip6_dscp_ecn_decapsulate+0x178/0x1b0 net/ipv6/ip6_tunnel.c:727\n __ip6_tnl_rcv+0xd4e/0x1590 net/ipv6/ip6_tunnel.c:845\n ip6_tnl_rcv+0xce/0x100 net/ipv6/ip6_tunnel.c:888\n gre_rcv+0x143f/0x1870\n ip6_protocol_deliver_rcu+0xda6/0x2a60 net/ipv6/ip6_input.c:438\n ip6_input_finish net/ipv6/ip6_input.c:483 [inline]\n NF_HOOK include/linux/netfilter.h:314 [inline]\n ip6_input+0x15d/0x430 net/ipv6/ip6_input.c:492\n ip6_mc_input+0xa7e/0xc80 net/ipv6/ip6_input.c:586\n dst_input include/net/dst.h:461 [inline]\n ip6_rcv_finish+0x5db/0x870 net/ipv6/ip6_input.c:79\n NF_HOOK include/linux/netfilter.h:314 [inline]\n ipv6_rcv+0xda/0x390 net/ipv6/ip6_input.c:310\n __netif_receive_skb_one_core net/core/dev.c:5532 [inline]\n __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5646\n netif_receive_skb_internal net/core/dev.c:5732 [inline]\n netif_receive_skb+0x58/0x660 net/core/dev.c:5791\n tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555\n tun_get_user+0x53af/0x66d0 drivers/net/tun.c:2002\n tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048\n call_write_iter include/linux/fs.h:2084 [inline]\n new_sync_write fs/read_write.c:497 [inline]\n vfs_write+0x786/0x1200 fs/read_write.c:590\n ksys_write+0x20f/0x4c0 fs/read_write.c:643\n __do_sys_write fs/read_write.c:655 [inline]\n __se_sys_write fs/read_write.c:652 [inline]\n __x64_sys_write+0x93/0xd0 fs/read_write.c:652\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0x6d/0x140 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+0x129/0xa70 mm/slab.h:768\n slab_alloc_node mm/slub.c:3478 [inline]\n kmem_cache_alloc_node+0x5e9/0xb10 mm/slub.c:3523\n kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560\n __alloc_skb+0x318/0x740 net/core/skbuff.c:651\n alloc_skb include/linux/skbuff.h:1286 [inline]\n alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6334\n sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2787\n tun_alloc_skb drivers/net/tun.c:1531 [inline]\n tun_get_user+0x1e8a/0x66d0 drivers/net/tun.c:1846\n tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048\n call_write_iter include/linux/fs.h:2084 [inline]\n new_sync_write fs/read_write.c:497 [inline]\n vfs_write+0x786/0x1200 fs/read_write.c:590\n ksys_write+0x20f/0x4c0 fs/read_write.c:643\n __do_sys_write fs/read_write.c:655 [inline]\n __se_sys_write fs/read_write.c:652 [inline]\n __x64_sys_write+0x93/0xd0 fs/read_write.c:652\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x63/0x6b\r\n\r\nCPU: 0 PID: 5034 Comm: syz-executor331 Not tainted 6.7.0-syzkaller-00562-g9f8413c4a66f #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023(CVE-2024-26641)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nl2tp: pass correct message length to ip6_append_data\r\n\r\nl2tp_ip6_sendmsg needs to avoid accounting for the transport header\ntwice when splicing more data into an already partially-occupied skbuff.\r\n\r\nTo manage this, we check whether the skbuff contains data using\nskb_queue_empty when deciding how much data to append using\nip6_append_data.\r\n\r\nHowever, the code which performed the calculation was incorrect:\r\n\r\n ulen = len + skb_queue_empty(\u0026amp;sk-\u0026gt;sk_write_queue) ? transhdrlen : 0;\r\n\r\n...due to C operator precedence, this ends up setting ulen to\ntranshdrlen for messages with a non-zero length, which results in\ncorrupted packets on the wire.\r\n\r\nAdd parentheses to correct the calculation in line with the original\nintent.(CVE-2024-26752)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nIB/hfi1: Fix sdma.h tx-\u0026gt;num_descs off-by-one error\r\n\r\nUnfortunately the commit `fd8958efe877` introduced another error\ncausing the `descs` array to overflow. This reults in further crashes\neasily reproducible by `sendmsg` system call.\r\n\r\n[ 1080.836473] general protection fault, probably for non-canonical address 0x400300015528b00a: 0000 [#1] PREEMPT SMP PTI\n[ 1080.869326] RIP: 0010:hfi1_ipoib_build_ib_tx_headers.constprop.0+0xe1/0x2b0 [hfi1]\n--\n[ 1080.974535] Call Trace:\n[ 1080.976990] \u0026lt;TASK\u0026gt;\n[ 1081.021929] hfi1_ipoib_send_dma_common+0x7a/0x2e0 [hfi1]\n[ 1081.027364] hfi1_ipoib_send_dma_list+0x62/0x270 [hfi1]\n[ 1081.032633] hfi1_ipoib_send+0x112/0x300 [hfi1]\n[ 1081.042001] ipoib_start_xmit+0x2a9/0x2d0 [ib_ipoib]\n[ 1081.046978] dev_hard_start_xmit+0xc4/0x210\n--\n[ 1081.148347] __sys_sendmsg+0x59/0xa0\r\n\r\ncrash\u0026gt; ipoib_txreq 0xffff9cfeba229f00\nstruct ipoib_txreq {\n txreq = {\n list = {\n next = 0xffff9cfeba229f00,\n prev = 0xffff9cfeba229f00\n },\n descp = 0xffff9cfeba229f40,\n coalesce_buf = 0x0,\n wait = 0xffff9cfea4e69a48,\n complete = 0xffffffffc0fe0760 \u0026lt;hfi1_ipoib_sdma_complete\u0026gt;,\n packet_len = 0x46d,\n tlen = 0x0,\n num_desc = 0x0,\n desc_limit = 0x6,\n next_descq_idx = 0x45c,\n coalesce_idx = 0x0,\n flags = 0x0,\n descs = {{\n qw = {0x8024000120dffb00, 0x4} # SDMA_DESC0_FIRST_DESC_FLAG (bit 63)\n }, {\n qw = { 0x3800014231b108, 0x4}\n }, {\n qw = { 0x310000e4ee0fcf0, 0x8}\n }, {\n qw = { 0x3000012e9f8000, 0x8}\n }, {\n qw = { 0x59000dfb9d0000, 0x8}\n }, {\n qw = { 0x78000e02e40000, 0x8}\n }}\n },\n sdma_hdr = 0x400300015528b000, \u0026lt;\u0026lt;\u0026lt; invalid pointer in the tx request structure\n sdma_status = 0x0, SDMA_DESC0_LAST_DESC_FLAG (bit 62)\n complete = 0x0,\n priv = 0x0,\n txq = 0xffff9cfea4e69880,\n skb = 0xffff9d099809f400\n}\r\n\r\nIf an SDMA send consists of exactly 6 descriptors and requires dword\npadding (in the 7th descriptor), the sdma_txreq descriptor array is not\nproperly expanded and the packet will overflow into the container\nstructure. This results in a panic when the send completion runs. The\nexact panic varies depending on what elements of the container structure\nget corrupted. The fix is to use the correct expression in\n_pad_sdma_tx_descs() to test the need to expand the descriptor array.\r\n\r\nWith this patch the crashes are no longer reproducible and the machine is\nstable.(CVE-2024-26766)",
"id": "OESA-2024-1566",
"modified": "2026-08-06T11:07:01Z",
"published": "2024-05-11T11:07:01Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1566"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47182"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47199"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47211"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52609"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52610"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52616"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52618"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26635"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26636"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26640"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26641"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26752"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26766"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2021-47182",
"CVE-2021-47199",
"CVE-2021-47211",
"CVE-2023-52609",
"CVE-2023-52610",
"CVE-2023-52616",
"CVE-2023-52618",
"CVE-2024-26635",
"CVE-2024-26636",
"CVE-2024-26640",
"CVE-2024-26641",
"CVE-2024-26752",
"CVE-2024-26766"
]
}
OESA-2024-1567 (CVE-2021-46929)
Vulnerability from osv_openeuler – Published: 2024-05-11 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:
sctp: use call_rcu to free endpoint
This patch is to delay the endpoint free by calling call_rcu() to fix another use-after-free issue in sctp_sock_dump():
BUG: KASAN: use-after-free in __lock_acquire+0x36d9/0x4c20 Call Trace: __lock_acquire+0x36d9/0x4c20 kernel/locking/lockdep.c:3218 lock_acquire+0x1ed/0x520 kernel/locking/lockdep.c:3844 __raw_spin_lock_bh include/linux/spinlock_api_smp.h:135 [inline] _raw_spin_lock_bh+0x31/0x40 kernel/locking/spinlock.c:168 spin_lock_bh include/linux/spinlock.h:334 [inline] __lock_sock+0x203/0x350 net/core/sock.c:2253 lock_sock_nested+0xfe/0x120 net/core/sock.c:2774 lock_sock include/net/sock.h:1492 [inline] sctp_sock_dump+0x122/0xb20 net/sctp/diag.c:324 sctp_for_each_transport+0x2b5/0x370 net/sctp/socket.c:5091 sctp_diag_dump+0x3ac/0x660 net/sctp/diag.c:527 __inet_diag_dump+0xa8/0x140 net/ipv4/inet_diag.c:1049 inet_diag_dump+0x9b/0x110 net/ipv4/inet_diag.c:1065 netlink_dump+0x606/0x1080 net/netlink/af_netlink.c:2244 __netlink_dump_start+0x59a/0x7c0 net/netlink/af_netlink.c:2352 netlink_dump_start include/linux/netlink.h:216 [inline] inet_diag_handler_cmd+0x2ce/0x3f0 net/ipv4/inet_diag.c:1170 __sock_diag_cmd net/core/sock_diag.c:232 [inline] sock_diag_rcv_msg+0x31d/0x410 net/core/sock_diag.c:263 netlink_rcv_skb+0x172/0x440 net/netlink/af_netlink.c:2477 sock_diag_rcv+0x2a/0x40 net/core/sock_diag.c:274
This issue occurs when asoc is peeled off and the old sk is freed after getting it by asoc->base.sk and before calling lock_sock(sk).
To prevent the sk free, as a holder of the sk, ep should be alive when calling lock_sock(). This patch uses call_rcu() and moves sock_put and ep free into sctp_endpoint_destroy_rcu(), so that it's safe to try to hold the ep under rcu_read_lock in sctp_transport_traverse_process().
If sctp_endpoint_hold() returns true, it means this ep is still alive and we have held it and can continue to dump it; If it returns false, it means this ep is dead and can be freed after rcu_read_unlock, and we should skip it.
In sctp_sock_dump(), after locking the sk, if this ep is different from tsp->asoc->ep, it means during this dumping, this asoc was peeled off before calling lock_sock(), and the sk should be skipped; If this ep is the same with tsp->asoc->ep, it means no peeloff happens on this asoc, and due to lock_sock, no peeloff will happen either until release_sock.
Note that delaying endpoint free won't delay the port release, as the port release happens in sctp_endpoint_destroy() before calling call_rcu(). Also, freeing endpoint by call_rcu() makes it safe to access the sk by asoc->base.sk in sctp_assocs_seq_show() and sctp_rcv().
Thanks Jones to bring this issue up.
v1->v2: - improve the changelog. - add kfree(ep) into sctp_endpoint_destroy_rcu(), as Jakub noticed.(CVE-2021-46929)
In the Linux kernel, the following vulnerability has been resolved:
net: fix use-after-free in tw_timer_handler
A real world panic issue was found as follow in Linux 5.4.
BUG: unable to handle page fault for address: ffffde49a863de28
PGD 7e6fe62067 P4D 7e6fe62067 PUD 7e6fe63067 PMD f51e064067 PTE 0
RIP: 0010:tw_timer_handler+0x20/0x40
Call Trace:
<IRQ>
call_timer_fn+0x2b/0x120
run_timer_softirq+0x1ef/0x450
__do_softirq+0x10d/0x2b8
irq_exit+0xc7/0xd0
smp_apic_timer_interrupt+0x68/0x120
apic_timer_interrupt+0xf/0x20
This issue was also reported since 2017 in the thread [1], unfortunately, the issue was still can be reproduced after fixing DCCP.
The ipv4_mib_exit_net is called before tcp_sk_exit_batch when a net namespace is destroyed since tcp_sk_ops is registered befrore ipv4_mib_ops, which means tcp_sk_ops is in the front of ipv4_mib_ops in the list of pernet_list. There will be a use-after-free on net->mib.net_statistics in tw_timer_handler after ipv4_mib_exit_net if there are some inflight time-wait timers.
This bug is not introduced by commit f2bf415cfed7 ("mib: add net to NET_ADD_STATS_BH") since the net_statistics is a global variable instead of dynamic allocation and freeing. Actually, commit 61a7e26028b9 ("mib: put net statistics on struct net") introduces the bug since it put net statistics on struct net and free it when net namespace is destroyed.
Moving init_ipv4_mibs() to the front of tcp_init() to fix this bug and replace pr_crit() with panic() since continuing is meaningless when init_ipv4_mibs() fails.
[1] https://groups.google.com/g/syzkaller/c/p1tn-_Kc6l4/m/smuL_FMAAgAJ?pli=1(CVE-2021-46936)
In the Linux kernel, the following vulnerability has been resolved:
ACPI: custom_method: fix potential use-after-free issue
In cm_write(), buf is always freed when reaching the end of the function. If the requested count is less than table.length, the allocated buffer will be freed but subsequent calls to cm_write() will still try to access it.
Remove the unconditional kfree(buf) at the end of the function and set the buf to NULL in the -EINVAL error path to match the rest of function.(CVE-2021-46966)
In the Linux kernel, the following vulnerability has been resolved:
tun: avoid double free in tun_free_netdev
Avoid double free in tun_free_netdev() by moving the dev->tstats and tun->security allocs to a new ndo_init routine (tun_net_init()) that will be called by register_netdevice(). ndo_init is paired with the desctructor (tun_free_netdev()), so if there's an error in register_netdevice() the destructor will handle the frees.
BUG: KASAN: double-free or invalid-free in selinux_tun_dev_free_security+0x1a/0x20 security/selinux/hooks.c:5605
CPU: 0 PID: 25750 Comm: syz-executor416 Not tainted 5.16.0-rc2-syzk #1 Hardware name: Red Hat KVM, BIOS Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x89/0xb5 lib/dump_stack.c:106 print_address_description.constprop.9+0x28/0x160 mm/kasan/report.c:247 kasan_report_invalid_free+0x55/0x80 mm/kasan/report.c:372 _kasanslab_free mm/kasan/common.c:346 [inline] kasan_slab_free+0x107/0x120 mm/kasan/common.c:374 kasan_slab_free include/linux/kasan.h:235 [inline] slab_free_hook mm/slub.c:1723 [inline] slab_free_freelist_hook mm/slub.c:1749 [inline] slab_free mm/slub.c:3513 [inline] kfree+0xac/0x2d0 mm/slub.c:4561 selinux_tun_dev_free_security+0x1a/0x20 security/selinux/hooks.c:5605 security_tun_dev_free_security+0x4f/0x90 security/security.c:2342 tun_free_netdev+0xe6/0x150 drivers/net/tun.c:2215 netdev_run_todo+0x4df/0x840 net/core/dev.c:10627 rtnl_unlock+0x13/0x20 net/core/rtnetlink.c:112 __tun_chr_ioctl+0x80c/0x2870 drivers/net/tun.c:3302 tun_chr_ioctl+0x2f/0x40 drivers/net/tun.c:3311 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:874 [inline] __se_sys_ioctl fs/ioctl.c:860 [inline] __x64_sys_ioctl+0x19d/0x220 fs/ioctl.c:860 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3a/0x80 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae(CVE-2021-47082)
In the Linux kernel, the following vulnerability has been resolved:
io_uring: fix ltout double free on completion race
Always remove linked timeout on io_link_timeout_fn() from the master request link list, otherwise we may get use-after-free when first io_link_timeout_fn() puts linked timeout in the fail path, and then will be found and put on master's free.(CVE-2021-47123)
In the Linux kernel, the following vulnerability has been resolved:
scsi: core: Fix scsi_mode_sense() buffer length handling
Several problems exist with scsi_mode_sense() buffer length handling:
1) The allocation length field of the MODE SENSE(10) command is 16-bits, occupying bytes 7 and 8 of the CDB. With this command, access to mode pages larger than 255 bytes is thus possible. However, the CDB allocation length field is set by assigning len to byte 8 only, thus truncating buffer length larger than 255.
2) If scsi_mode_sense() is called with len smaller than 8 with sdev->use_10_for_ms set, or smaller than 4 otherwise, the buffer length is increased to 8 and 4 respectively, and the buffer is zero filled with these increased values, thus corrupting the memory following the buffer.
Fix these 2 problems by using put_unaligned_be16() to set the allocation length field of MODE SENSE(10) CDB and by returning an error when len is too small.
Furthermore, if len is larger than 255B, always try MODE SENSE(10) first, even if the device driver did not set sdev->use_10_for_ms. In case of invalid opcode error for MODE SENSE(10), access to mode pages larger than 255 bytes are not retried using MODE SENSE(6). To avoid buffer length overflows for the MODE_SENSE(10) case, check that len is smaller than 65535 bytes.
While at it, also fix the folowing:
-
Use get_unaligned_be16() to retrieve the mode data length and block descriptor length fields of the mode sense reply header instead of using an open coded calculation.
-
Fix the kdoc dbd argument explanation: the DBD bit stands for Disable Block Descriptor, which is the opposite of what the dbd argument description was.(CVE-2021-47182)
In the Linux kernel, the following vulnerability has been resolved:
tty: tty_buffer: Fix the softlockup issue in flush_to_ldisc
When running ltp testcase(ltp/testcases/kernel/pty/pty04.c) with arm64, there is a soft lockup, which look like this one:
Workqueue: events_unbound flush_to_ldisc Call trace: dump_backtrace+0x0/0x1ec show_stack+0x24/0x30 dump_stack+0xd0/0x128 panic+0x15c/0x374 watchdog_timer_fn+0x2b8/0x304 __run_hrtimer+0x88/0x2c0 __hrtimer_run_queues+0xa4/0x120 hrtimer_interrupt+0xfc/0x270 arch_timer_handler_phys+0x40/0x50 handle_percpu_devid_irq+0x94/0x220 __handle_domain_irq+0x88/0xf0 gic_handle_irq+0x84/0xfc el1_irq+0xc8/0x180 slip_unesc+0x80/0x214 [slip] tty_ldisc_receive_buf+0x64/0x80 tty_port_default_receive_buf+0x50/0x90 flush_to_ldisc+0xbc/0x110 process_one_work+0x1d4/0x4b0 worker_thread+0x180/0x430 kthread+0x11c/0x120
In the testcase pty04, The first process call the write syscall to send data to the pty master. At the same time, the workqueue will do the flush_to_ldisc to pop data in a loop until there is no more data left. When the sender and workqueue running in different core, the sender sends data fastly in full time which will result in workqueue doing work in loop for a long time and occuring softlockup in flush_to_ldisc with kernel configured without preempt. So I add need_resched check and cond_resched in the flush_to_ldisc loop to avoid it.(CVE-2021-47185)
In the Linux kernel, the following vulnerability has been resolved:
iavf: free q_vectors before queues in iavf_disable_vf
iavf_free_queues() clears adapter->num_active_queues, which iavf_free_q_vectors() relies on, so swap the order of these two function calls in iavf_disable_vf(). This resolves a panic encountered when the interface is disabled and then later brought up again after PF communication is restored.(CVE-2021-47201)
In the Linux kernel, the following vulnerability has been resolved:
scsi: lpfc: Fix list_add() corruption in lpfc_drain_txq()
When parsing the txq list in lpfc_drain_txq(), the driver attempts to pass the requests to the adapter. If such an attempt fails, a local "fail_msg" string is set and a log message output. The job is then added to a completions list for cancellation.
Processing of any further jobs from the txq list continues, but since "fail_msg" remains set, jobs are added to the completions list regardless of whether a wqe was passed to the adapter. If successfully added to txcmplq, jobs are added to both lists resulting in list corruption.
Fix by clearing the fail_msg string after adding a job to the completions list. This stops the subsequent jobs from being added to the completions list unless they had an appropriate failure.(CVE-2021-47203)
In the Linux kernel, the following vulnerability has been resolved:
ALSA: usb-audio: fix null pointer dereference on pointer cs_desc
The pointer cs_desc return from snd_usb_find_clock_source could be null, so there is a potential null pointer dereference issue. Fix this by adding a null check before dereference.(CVE-2021-47211)
In the Linux kernel, the following vulnerability has been resolved:
scsi: advansys: Fix kernel pointer leak
Pointers should be printed with %p or %px rather than cast to 'unsigned long' and printed with %lx.
Change %lx to %p to print the hashed pointer.(CVE-2021-47216)
In the Linux kernel, the following vulnerability has been resolved:
x86/hyperv: Fix NULL deref in set_hv_tscchange_cb() if Hyper-V setup fails
Check for a valid hv_vp_index array prior to derefencing hv_vp_index when setting Hyper-V's TSC change callback. If Hyper-V setup failed in hyperv_init(), the kernel will still report that it's running under Hyper-V, but will have silently disabled nearly all functionality.
BUG: kernel NULL pointer dereference, address: 0000000000000010 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] SMP CPU: 4 PID: 1 Comm: swapper/0 Not tainted 5.15.0-rc2+ #75 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:set_hv_tscchange_cb+0x15/0xa0 Code: <8b> 04 82 8b 15 12 17 85 01 48 c1 e0 20 48 0d ee 00 01 00 f6 c6 08 ... Call Trace: kvm_arch_init+0x17c/0x280 kvm_init+0x31/0x330 vmx_init+0xba/0x13a do_one_initcall+0x41/0x1c0 kernel_init_freeable+0x1f2/0x23b kernel_init+0x16/0x120 ret_from_fork+0x22/0x30(CVE-2021-47217)
In the Linux kernel, the following vulnerability has been resolved:
usb: hub: Guard against accesses to uninitialized BOS descriptors
Many functions in drivers/usb/core/hub.c and drivers/usb/core/hub.h access fields inside udev->bos without checking if it was allocated and initialized. If usb_get_bos_descriptor() fails for whatever reason, udev->bos will be NULL and those accesses will result in a crash:
BUG: kernel NULL pointer dereference, address: 0000000000000018 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 5 PID: 17818 Comm: kworker/5:1 Tainted: G W 5.15.108-18910-gab0e1cb584e1 #1 <HASH:1f9e 1> Hardware name: Google Kindred/Kindred, BIOS Google_Kindred.12672.413.0 02/03/2021 Workqueue: usb_hub_wq hub_event RIP: 0010:hub_port_reset+0x193/0x788 Code: 89 f7 e8 20 f7 15 00 48 8b 43 08 80 b8 96 03 00 00 03 75 36 0f b7 88 92 03 00 00 81 f9 10 03 00 00 72 27 48 8b 80 a8 03 00 00 <48> 83 78 18 00 74 19 48 89 df 48 8b 75 b0 ba 02 00 00 00 4c 89 e9 RSP: 0018:ffffab740c53fcf8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffffa1bc5f678000 RCX: 0000000000000310 RDX: fffffffffffffdff RSI: 0000000000000286 RDI: ffffa1be9655b840 RBP: ffffab740c53fd70 R08: 00001b7d5edaa20c R09: ffffffffb005e060 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000 R13: ffffab740c53fd3e R14: 0000000000000032 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffffa1be96540000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000018 CR3: 000000022e80c005 CR4: 00000000003706e0 Call Trace: hub_event+0x73f/0x156e ? hub_activate+0x5b7/0x68f process_one_work+0x1a2/0x487 worker_thread+0x11a/0x288 kthread+0x13a/0x152 ? process_one_work+0x487/0x487 ? kthread_associate_blkcg+0x70/0x70 ret_from_fork+0x1f/0x30
Fall back to a default behavior if the BOS descriptor isn't accessible and skip all the functionalities that depend on it: LPM support checks, Super Speed capabilitiy checks, U1/U2 states setup.(CVE-2023-52477)
In the Linux kernel, the following vulnerability has been resolved:
binder: fix race between mmput() and do_exit()
Task A calls binder_update_page_range() to allocate and insert pages on a remote address space from Task B. For this, Task A pins the remote mm via mmget_not_zero() first. This can race with Task B do_exit() and the final mmput() refcount decrement will come from Task A.
Task A | Task B ------------------+------------------ mmget_not_zero() | | do_exit() | exit_mm() | mmput() mmput() | exit_mmap() | remove_vma() | fput() |
In this case, the work of ____fput() from Task B is queued up in Task A as TWA_RESUME. So in theory, Task A returns to userspace and the cleanup work gets executed. However, Task A instead sleep, waiting for a reply from Task B that never comes (it's dead).
This means the binder_deferred_release() is blocked until an unrelated binder event forces Task A to go back to userspace. All the associated death notifications will also be delayed until then.
In order to fix this use mmput_async() that will schedule the work in the corresponding mm->async_put_work WQ instead of Task A.(CVE-2023-52609)
In the Linux kernel, the following vulnerability has been resolved:
crypto: scomp - fix req->dst buffer overflow
The req->dst buffer size should be checked before copying from the scomp_scratch->dst to avoid req->dst buffer overflow problem.(CVE-2023-52612)
In the Linux kernel, the following vulnerability has been resolved:
llc: Drop support for ETH_P_TR_802_2.
syzbot reported an uninit-value bug below. [0]
llc supports ETH_P_802_2 (0x0004) and used to support ETH_P_TR_802_2 (0x0011), and syzbot abused the latter to trigger the bug.
write$tun(r0, &(0x7f0000000040)={@val={0x0, 0x11}, @val, @mpls={[], @llc={@snap={0xaa, 0x1, ')', "90e5dd"}}}}, 0x16)
llc_conn_handler() initialises local variables {saddr,daddr}.mac based on skb in llc_pdu_decode_sa()/llc_pdu_decode_da() and passes them to __llc_lookup().
However, the initialisation is done only when skb->protocol is htons(ETH_P_802_2), otherwise, __llc_lookup_established() and __llc_lookup_listener() will read garbage.
The missing initialisation existed prior to commit 211ed865108e ("net: delete all instances of special processing for token ring").
It removed the part to kick out the token ring stuff but forgot to close the door allowing ETH_P_TR_802_2 packets to sneak into llc_rcv().
Let's remove llc_tr_packet_type and complete the deprecation.
[0]: BUG: KMSAN: uninit-value in __llc_lookup_established+0xe9d/0xf90 __llc_lookup_established+0xe9d/0xf90 __llc_lookup net/llc/llc_conn.c:611 [inline] llc_conn_handler+0x4bd/0x1360 net/llc/llc_conn.c:791 llc_rcv+0xfbb/0x14a0 net/llc/llc_input.c:206 __netif_receive_skb_one_core net/core/dev.c:5527 [inline] __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5641 netif_receive_skb_internal net/core/dev.c:5727 [inline] netif_receive_skb+0x58/0x660 net/core/dev.c:5786 tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555 tun_get_user+0x53af/0x66d0 drivers/net/tun.c:2002 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048 call_write_iter include/linux/fs.h:2020 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x8ef/0x1490 fs/read_write.c:584 ksys_write+0x20f/0x4c0 fs/read_write.c:637 __do_sys_write fs/read_write.c:649 [inline] __se_sys_write fs/read_write.c:646 [inline] __x64_sys_write+0x93/0xd0 fs/read_write.c:646 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x44/0x110 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x63/0x6b
Local variable daddr created at: llc_conn_handler+0x53/0x1360 net/llc/llc_conn.c:783 llc_rcv+0xfbb/0x14a0 net/llc/llc_input.c:206
CPU: 1 PID: 5004 Comm: syz-executor994 Not tainted 6.6.0-syzkaller-14500-g1c41041124bd #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/09/2023(CVE-2024-26635)
In the Linux kernel, the following vulnerability has been resolved:
llc: make llc_ui_sendmsg() more robust against bonding changes
syzbot was able to trick llc_ui_sendmsg(), allocating an skb with no headroom, but subsequently trying to push 14 bytes of Ethernet header [1]
Like some others, llc_ui_sendmsg() releases the socket lock before calling sock_alloc_send_skb(). Then it acquires it again, but does not redo all the sanity checks that were performed.
This fix:
- Uses LL_RESERVED_SPACE() to reserve space.
- Check all conditions again after socket lock is held again.
- Do not account Ethernet header for mtu limitation.
[1]
skbuff: skb_under_panic: text:ffff800088baa334 len:1514 put:14 head:ffff0000c9c37000 data:ffff0000c9c36ff2 tail:0x5dc end:0x6c0 dev:bond0
kernel BUG at net/core/skbuff.c:193 ! Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP Modules linked in: CPU: 0 PID: 6875 Comm: syz-executor.0 Not tainted 6.7.0-rc8-syzkaller-00101-g0802e17d9aca-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : skb_panic net/core/skbuff.c:189 [inline] pc : skb_under_panic+0x13c/0x140 net/core/skbuff.c:203 lr : skb_panic net/core/skbuff.c:189 [inline] lr : skb_under_panic+0x13c/0x140 net/core/skbuff.c:203 sp : ffff800096f97000 x29: ffff800096f97010 x28: ffff80008cc8d668 x27: dfff800000000000 x26: ffff0000cb970c90 x25: 00000000000005dc x24: ffff0000c9c36ff2 x23: ffff0000c9c37000 x22: 00000000000005ea x21: 00000000000006c0 x20: 000000000000000e x19: ffff800088baa334 x18: 1fffe000368261ce x17: ffff80008e4ed000 x16: ffff80008a8310f8 x15: 0000000000000001 x14: 1ffff00012df2d58 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000001 x10: 0000000000ff0100 x9 : e28a51f1087e8400 x8 : e28a51f1087e8400 x7 : ffff80008028f8d0 x6 : 0000000000000000 x5 : 0000000000000001 x4 : 0000000000000001 x3 : ffff800082b78714 x2 : 0000000000000001 x1 : 0000000100000000 x0 : 0000000000000089 Call trace: skb_panic net/core/skbuff.c:189 [inline] skb_under_panic+0x13c/0x140 net/core/skbuff.c:203 skb_push+0xf0/0x108 net/core/skbuff.c:2451 eth_header+0x44/0x1f8 net/ethernet/eth.c:83 dev_hard_header include/linux/netdevice.h:3188 [inline] llc_mac_hdr_init+0x110/0x17c net/llc/llc_output.c:33 llc_sap_action_send_xid_c+0x170/0x344 net/llc/llc_s_ac.c:85 llc_exec_sap_trans_actions net/llc/llc_sap.c:153 [inline] llc_sap_next_state net/llc/llc_sap.c:182 [inline] llc_sap_state_process+0x1ec/0x774 net/llc/llc_sap.c:209 llc_build_and_send_xid_pkt+0x12c/0x1c0 net/llc/llc_sap.c:270 llc_ui_sendmsg+0x7bc/0xb1c net/llc/af_llc.c:997 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] sock_sendmsg+0x194/0x274 net/socket.c:767 splice_to_socket+0x7cc/0xd58 fs/splice.c:881 do_splice_from fs/splice.c:933 [inline] direct_splice_actor+0xe4/0x1c0 fs/splice.c:1142 splice_direct_to_actor+0x2a0/0x7e4 fs/splice.c:1088 do_splice_direct+0x20c/0x348 fs/splice.c:1194 do_sendfile+0x4bc/0xc70 fs/read_write.c:1254 __do_sys_sendfile64 fs/read_write.c:1322 [inline] __se_sys_sendfile64 fs/read_write.c:1308 [inline] __arm64_sys_sendfile64+0x160/0x3b4 fs/read_write.c:1308 __invoke_syscall arch/arm64/kernel/syscall.c:37 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:51 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:136 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:155 el0_svc+0x54/0x158 arch/arm64/kernel/entry-common.c:678 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:696 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:595 Code: aa1803e6 aa1903e7 a90023f5 94792f6a (d4210000)(CVE-2024-26636)
In the Linux kernel, the following vulnerability has been resolved:
tcp: add sanity checks to rx zerocopy
TCP rx zerocopy intent is to map pages initially allocated from NIC drivers, not pages owned by a fs.
This patch adds to can_map_frag() these additional checks:
- Page must not be a compound one.
- page->mapping must be NULL.
This fixes the panic reported by ZhangPeng.
syzbot was able to loopback packets built with sendfile(), mapping pages owned by an ext4 file to TCP rx zerocopy.
r3 = socket$inet_tcp(0x2, 0x1, 0x0) mmap(&(0x7f0000ff9000/0x4000)=nil, 0x4000, 0x0, 0x12, r3, 0x0) r4 = socket$inet_tcp(0x2, 0x1, 0x0) bind$inet(r4, &(0x7f0000000000)={0x2, 0x4e24, @multicast1}, 0x10) connect$inet(r4, &(0x7f00000006c0)={0x2, 0x4e24, @empty}, 0x10) r5 = openat$dir(0xffffffffffffff9c, &(0x7f00000000c0)='./file0\x00', 0x181e42, 0x0) fallocate(r5, 0x0, 0x0, 0x85b8) sendfile(r4, r5, 0x0, 0x8ba0) getsockopt$inet_tcp_TCP_ZEROCOPY_RECEIVE(r4, 0x6, 0x23, &(0x7f00000001c0)={&(0x7f0000ffb000/0x3000)=nil, 0x3000, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, &(0x7f0000000440)=0x40) r6 = openat$dir(0xffffffffffffff9c, &(0x7f00000000c0)='./file0\x00', 0x181e42, 0x0)(CVE-2024-26640)
In the Linux kernel, the following vulnerability has been resolved:
ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv()
syzbot found __ip6_tnl_rcv() could access unitiliazed data [1].
Call pskb_inet_may_pull() to fix this, and initialize ipv6h variable after this call as it can change skb->head.
[1] BUG: KMSAN: uninit-value in __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline] BUG: KMSAN: uninit-value in INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline] BUG: KMSAN: uninit-value in IP6_ECN_decapsulate+0x7df/0x1e50 include/net/inet_ecn.h:321 __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline] INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline] IP6_ECN_decapsulate+0x7df/0x1e50 include/net/inet_ecn.h:321 ip6ip6_dscp_ecn_decapsulate+0x178/0x1b0 net/ipv6/ip6_tunnel.c:727 __ip6_tnl_rcv+0xd4e/0x1590 net/ipv6/ip6_tunnel.c:845 ip6_tnl_rcv+0xce/0x100 net/ipv6/ip6_tunnel.c:888 gre_rcv+0x143f/0x1870 ip6_protocol_deliver_rcu+0xda6/0x2a60 net/ipv6/ip6_input.c:438 ip6_input_finish net/ipv6/ip6_input.c:483 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] ip6_input+0x15d/0x430 net/ipv6/ip6_input.c:492 ip6_mc_input+0xa7e/0xc80 net/ipv6/ip6_input.c:586 dst_input include/net/dst.h:461 [inline] ip6_rcv_finish+0x5db/0x870 net/ipv6/ip6_input.c:79 NF_HOOK include/linux/netfilter.h:314 [inline] ipv6_rcv+0xda/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core net/core/dev.c:5532 [inline] __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5646 netif_receive_skb_internal net/core/dev.c:5732 [inline] netif_receive_skb+0x58/0x660 net/core/dev.c:5791 tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555 tun_get_user+0x53af/0x66d0 drivers/net/tun.c:2002 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048 call_write_iter include/linux/fs.h:2084 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0x786/0x1200 fs/read_write.c:590 ksys_write+0x20f/0x4c0 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __x64_sys_write+0x93/0xd0 fs/read_write.c:652 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b
Uninit was created at: slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768 slab_alloc_node mm/slub.c:3478 [inline] kmem_cache_alloc_node+0x5e9/0xb10 mm/slub.c:3523 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560 __alloc_skb+0x318/0x740 net/core/skbuff.c:651 alloc_skb include/linux/skbuff.h:1286 [inline] alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6334 sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2787 tun_alloc_skb drivers/net/tun.c:1531 [inline] tun_get_user+0x1e8a/0x66d0 drivers/net/tun.c:1846 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048 call_write_iter include/linux/fs.h:2084 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0x786/0x1200 fs/read_write.c:590 ksys_write+0x20f/0x4c0 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __x64_sys_write+0x93/0xd0 fs/read_write.c:652 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b
CPU: 0 PID: 5034 Comm: syz-executor331 Not tainted 6.7.0-syzkaller-00562-g9f8413c4a66f #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023(CVE-2024-26641)
In the Linux kernel, the following vulnerability has been resolved:
l2tp: pass correct message length to ip6_append_data
l2tp_ip6_sendmsg needs to avoid accounting for the transport header twice when splicing more data into an already partially-occupied skbuff.
To manage this, we check whether the skbuff contains data using skb_queue_empty when deciding how much data to append using ip6_append_data.
However, the code which performed the calculation was incorrect:
ulen = len + skb_queue_empty(&sk->sk_write_queue) ? transhdrlen : 0;
...due to C operator precedence, this ends up setting ulen to transhdrlen for messages with a non-zero length, which results in corrupted packets on the wire.
Add parentheses to correct the calculation in line with the original intent.(CVE-2024-26752)
| URL | Type | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"python2-perf-debuginfo-4.19.90-2405.1.0.0248.oe1.aarch64.rpm",
"kernel-debugsource-4.19.90-2405.1.0.0248.oe1.aarch64.rpm",
"python3-perf-4.19.90-2405.1.0.0248.oe1.aarch64.rpm",
"kernel-source-4.19.90-2405.1.0.0248.oe1.aarch64.rpm",
"kernel-tools-debuginfo-4.19.90-2405.1.0.0248.oe1.aarch64.rpm",
"bpftool-debuginfo-4.19.90-2405.1.0.0248.oe1.aarch64.rpm",
"python2-perf-4.19.90-2405.1.0.0248.oe1.aarch64.rpm",
"kernel-debuginfo-4.19.90-2405.1.0.0248.oe1.aarch64.rpm",
"kernel-tools-devel-4.19.90-2405.1.0.0248.oe1.aarch64.rpm",
"kernel-tools-4.19.90-2405.1.0.0248.oe1.aarch64.rpm",
"perf-debuginfo-4.19.90-2405.1.0.0248.oe1.aarch64.rpm",
"python3-perf-debuginfo-4.19.90-2405.1.0.0248.oe1.aarch64.rpm",
"kernel-devel-4.19.90-2405.1.0.0248.oe1.aarch64.rpm",
"bpftool-4.19.90-2405.1.0.0248.oe1.aarch64.rpm",
"perf-4.19.90-2405.1.0.0248.oe1.aarch64.rpm",
"kernel-4.19.90-2405.1.0.0248.oe1.aarch64.rpm"
],
"src": [
"kernel-4.19.90-2405.1.0.0248.oe1.src.rpm"
],
"x86_64": [
"kernel-debuginfo-4.19.90-2405.1.0.0248.oe1.x86_64.rpm",
"kernel-tools-debuginfo-4.19.90-2405.1.0.0248.oe1.x86_64.rpm",
"python2-perf-4.19.90-2405.1.0.0248.oe1.x86_64.rpm",
"kernel-tools-4.19.90-2405.1.0.0248.oe1.x86_64.rpm",
"python3-perf-debuginfo-4.19.90-2405.1.0.0248.oe1.x86_64.rpm",
"python3-perf-4.19.90-2405.1.0.0248.oe1.x86_64.rpm",
"kernel-source-4.19.90-2405.1.0.0248.oe1.x86_64.rpm",
"perf-debuginfo-4.19.90-2405.1.0.0248.oe1.x86_64.rpm",
"kernel-4.19.90-2405.1.0.0248.oe1.x86_64.rpm",
"python2-perf-debuginfo-4.19.90-2405.1.0.0248.oe1.x86_64.rpm",
"kernel-debugsource-4.19.90-2405.1.0.0248.oe1.x86_64.rpm",
"kernel-devel-4.19.90-2405.1.0.0248.oe1.x86_64.rpm",
"kernel-tools-devel-4.19.90-2405.1.0.0248.oe1.x86_64.rpm",
"bpftool-debuginfo-4.19.90-2405.1.0.0248.oe1.x86_64.rpm",
"perf-4.19.90-2405.1.0.0248.oe1.x86_64.rpm",
"bpftool-4.19.90-2405.1.0.0248.oe1.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:20.03-LTS-SP1",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-20.03-LTS-SP1"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.19.90-2405.1.0.0248.oe1"
}
],
"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\nsctp: use call_rcu to free endpoint\r\n\r\nThis patch is to delay the endpoint free by calling call_rcu() to fix\nanother use-after-free issue in sctp_sock_dump():\r\n\r\n BUG: KASAN: use-after-free in __lock_acquire+0x36d9/0x4c20\n Call Trace:\n __lock_acquire+0x36d9/0x4c20 kernel/locking/lockdep.c:3218\n lock_acquire+0x1ed/0x520 kernel/locking/lockdep.c:3844\n __raw_spin_lock_bh include/linux/spinlock_api_smp.h:135 [inline]\n _raw_spin_lock_bh+0x31/0x40 kernel/locking/spinlock.c:168\n spin_lock_bh include/linux/spinlock.h:334 [inline]\n __lock_sock+0x203/0x350 net/core/sock.c:2253\n lock_sock_nested+0xfe/0x120 net/core/sock.c:2774\n lock_sock include/net/sock.h:1492 [inline]\n sctp_sock_dump+0x122/0xb20 net/sctp/diag.c:324\n sctp_for_each_transport+0x2b5/0x370 net/sctp/socket.c:5091\n sctp_diag_dump+0x3ac/0x660 net/sctp/diag.c:527\n __inet_diag_dump+0xa8/0x140 net/ipv4/inet_diag.c:1049\n inet_diag_dump+0x9b/0x110 net/ipv4/inet_diag.c:1065\n netlink_dump+0x606/0x1080 net/netlink/af_netlink.c:2244\n __netlink_dump_start+0x59a/0x7c0 net/netlink/af_netlink.c:2352\n netlink_dump_start include/linux/netlink.h:216 [inline]\n inet_diag_handler_cmd+0x2ce/0x3f0 net/ipv4/inet_diag.c:1170\n __sock_diag_cmd net/core/sock_diag.c:232 [inline]\n sock_diag_rcv_msg+0x31d/0x410 net/core/sock_diag.c:263\n netlink_rcv_skb+0x172/0x440 net/netlink/af_netlink.c:2477\n sock_diag_rcv+0x2a/0x40 net/core/sock_diag.c:274\r\n\r\nThis issue occurs when asoc is peeled off and the old sk is freed after\ngetting it by asoc-\u0026gt;base.sk and before calling lock_sock(sk).\r\n\r\nTo prevent the sk free, as a holder of the sk, ep should be alive when\ncalling lock_sock(). This patch uses call_rcu() and moves sock_put and\nep free into sctp_endpoint_destroy_rcu(), so that it\u0026apos;s safe to try to\nhold the ep under rcu_read_lock in sctp_transport_traverse_process().\r\n\r\nIf sctp_endpoint_hold() returns true, it means this ep is still alive\nand we have held it and can continue to dump it; If it returns false,\nit means this ep is dead and can be freed after rcu_read_unlock, and\nwe should skip it.\r\n\r\nIn sctp_sock_dump(), after locking the sk, if this ep is different from\ntsp-\u0026gt;asoc-\u0026gt;ep, it means during this dumping, this asoc was peeled off\nbefore calling lock_sock(), and the sk should be skipped; If this ep is\nthe same with tsp-\u0026gt;asoc-\u0026gt;ep, it means no peeloff happens on this asoc,\nand due to lock_sock, no peeloff will happen either until release_sock.\r\n\r\nNote that delaying endpoint free won\u0026apos;t delay the port release, as the\nport release happens in sctp_endpoint_destroy() before calling call_rcu().\nAlso, freeing endpoint by call_rcu() makes it safe to access the sk by\nasoc-\u0026gt;base.sk in sctp_assocs_seq_show() and sctp_rcv().\r\n\r\nThanks Jones to bring this issue up.\r\n\r\nv1-\u0026gt;v2:\n - improve the changelog.\n - add kfree(ep) into sctp_endpoint_destroy_rcu(), as Jakub noticed.(CVE-2021-46929)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: fix use-after-free in tw_timer_handler\r\n\r\nA real world panic issue was found as follow in Linux 5.4.\r\n\r\n BUG: unable to handle page fault for address: ffffde49a863de28\n PGD 7e6fe62067 P4D 7e6fe62067 PUD 7e6fe63067 PMD f51e064067 PTE 0\n RIP: 0010:tw_timer_handler+0x20/0x40\n Call Trace:\n \u0026lt;IRQ\u0026gt;\n call_timer_fn+0x2b/0x120\n run_timer_softirq+0x1ef/0x450\n __do_softirq+0x10d/0x2b8\n irq_exit+0xc7/0xd0\n smp_apic_timer_interrupt+0x68/0x120\n apic_timer_interrupt+0xf/0x20\r\n\r\nThis issue was also reported since 2017 in the thread [1],\nunfortunately, the issue was still can be reproduced after fixing\nDCCP.\r\n\r\nThe ipv4_mib_exit_net is called before tcp_sk_exit_batch when a net\nnamespace is destroyed since tcp_sk_ops is registered befrore\nipv4_mib_ops, which means tcp_sk_ops is in the front of ipv4_mib_ops\nin the list of pernet_list. There will be a use-after-free on\nnet-\u0026gt;mib.net_statistics in tw_timer_handler after ipv4_mib_exit_net\nif there are some inflight time-wait timers.\r\n\r\nThis bug is not introduced by commit f2bf415cfed7 (\u0026quot;mib: add net to\nNET_ADD_STATS_BH\u0026quot;) since the net_statistics is a global variable\ninstead of dynamic allocation and freeing. Actually, commit\n61a7e26028b9 (\u0026quot;mib: put net statistics on struct net\u0026quot;) introduces\nthe bug since it put net statistics on struct net and free it when\nnet namespace is destroyed.\r\n\r\nMoving init_ipv4_mibs() to the front of tcp_init() to fix this bug\nand replace pr_crit() with panic() since continuing is meaningless\nwhen init_ipv4_mibs() fails.\r\n\r\n[1] https://groups.google.com/g/syzkaller/c/p1tn-_Kc6l4/m/smuL_FMAAgAJ?pli=1(CVE-2021-46936)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nACPI: custom_method: fix potential use-after-free issue\r\n\r\nIn cm_write(), buf is always freed when reaching the end of the\nfunction. If the requested count is less than table.length, the\nallocated buffer will be freed but subsequent calls to cm_write() will\nstill try to access it.\r\n\r\nRemove the unconditional kfree(buf) at the end of the function and\nset the buf to NULL in the -EINVAL error path to match the rest of\nfunction.(CVE-2021-46966)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntun: avoid double free in tun_free_netdev\r\n\r\nAvoid double free in tun_free_netdev() by moving the\ndev-\u0026gt;tstats and tun-\u0026gt;security allocs to a new ndo_init routine\n(tun_net_init()) that will be called by register_netdevice().\nndo_init is paired with the desctructor (tun_free_netdev()),\nso if there\u0026apos;s an error in register_netdevice() the destructor\nwill handle the frees.\r\n\r\nBUG: KASAN: double-free or invalid-free in selinux_tun_dev_free_security+0x1a/0x20 security/selinux/hooks.c:5605\r\n\r\nCPU: 0 PID: 25750 Comm: syz-executor416 Not tainted 5.16.0-rc2-syzk #1\nHardware name: Red Hat KVM, BIOS\nCall Trace:\n\u0026lt;TASK\u0026gt;\n__dump_stack lib/dump_stack.c:88 [inline]\ndump_stack_lvl+0x89/0xb5 lib/dump_stack.c:106\nprint_address_description.constprop.9+0x28/0x160 mm/kasan/report.c:247\nkasan_report_invalid_free+0x55/0x80 mm/kasan/report.c:372\n____kasan_slab_free mm/kasan/common.c:346 [inline]\n__kasan_slab_free+0x107/0x120 mm/kasan/common.c:374\nkasan_slab_free include/linux/kasan.h:235 [inline]\nslab_free_hook mm/slub.c:1723 [inline]\nslab_free_freelist_hook mm/slub.c:1749 [inline]\nslab_free mm/slub.c:3513 [inline]\nkfree+0xac/0x2d0 mm/slub.c:4561\nselinux_tun_dev_free_security+0x1a/0x20 security/selinux/hooks.c:5605\nsecurity_tun_dev_free_security+0x4f/0x90 security/security.c:2342\ntun_free_netdev+0xe6/0x150 drivers/net/tun.c:2215\nnetdev_run_todo+0x4df/0x840 net/core/dev.c:10627\nrtnl_unlock+0x13/0x20 net/core/rtnetlink.c:112\n__tun_chr_ioctl+0x80c/0x2870 drivers/net/tun.c:3302\ntun_chr_ioctl+0x2f/0x40 drivers/net/tun.c:3311\nvfs_ioctl fs/ioctl.c:51 [inline]\n__do_sys_ioctl fs/ioctl.c:874 [inline]\n__se_sys_ioctl fs/ioctl.c:860 [inline]\n__x64_sys_ioctl+0x19d/0x220 fs/ioctl.c:860\ndo_syscall_x64 arch/x86/entry/common.c:50 [inline]\ndo_syscall_64+0x3a/0x80 arch/x86/entry/common.c:80\nentry_SYSCALL_64_after_hwframe+0x44/0xae(CVE-2021-47082)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nio_uring: fix ltout double free on completion race\r\n\r\nAlways remove linked timeout on io_link_timeout_fn() from the master\nrequest link list, otherwise we may get use-after-free when first\nio_link_timeout_fn() puts linked timeout in the fail path, and then\nwill be found and put on master\u0026apos;s free.(CVE-2021-47123)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: core: Fix scsi_mode_sense() buffer length handling\r\n\r\nSeveral problems exist with scsi_mode_sense() buffer length handling:\r\n\r\n 1) The allocation length field of the MODE SENSE(10) command is 16-bits,\n occupying bytes 7 and 8 of the CDB. With this command, access to mode\n pages larger than 255 bytes is thus possible. However, the CDB\n allocation length field is set by assigning len to byte 8 only, thus\n truncating buffer length larger than 255.\r\n\r\n 2) If scsi_mode_sense() is called with len smaller than 8 with\n sdev-\u0026gt;use_10_for_ms set, or smaller than 4 otherwise, the buffer length\n is increased to 8 and 4 respectively, and the buffer is zero filled\n with these increased values, thus corrupting the memory following the\n buffer.\r\n\r\nFix these 2 problems by using put_unaligned_be16() to set the allocation\nlength field of MODE SENSE(10) CDB and by returning an error when len is\ntoo small.\r\n\r\nFurthermore, if len is larger than 255B, always try MODE SENSE(10) first,\neven if the device driver did not set sdev-\u0026gt;use_10_for_ms. In case of\ninvalid opcode error for MODE SENSE(10), access to mode pages larger than\n255 bytes are not retried using MODE SENSE(6). To avoid buffer length\noverflows for the MODE_SENSE(10) case, check that len is smaller than 65535\nbytes.\r\n\r\nWhile at it, also fix the folowing:\r\n\r\n * Use get_unaligned_be16() to retrieve the mode data length and block\n descriptor length fields of the mode sense reply header instead of using\n an open coded calculation.\r\n\r\n * Fix the kdoc dbd argument explanation: the DBD bit stands for Disable\n Block Descriptor, which is the opposite of what the dbd argument\n description was.(CVE-2021-47182)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntty: tty_buffer: Fix the softlockup issue in flush_to_ldisc\r\n\r\nWhen running ltp testcase(ltp/testcases/kernel/pty/pty04.c) with arm64, there is a soft lockup,\nwhich look like this one:\r\n\r\n Workqueue: events_unbound flush_to_ldisc\n Call trace:\n dump_backtrace+0x0/0x1ec\n show_stack+0x24/0x30\n dump_stack+0xd0/0x128\n panic+0x15c/0x374\n watchdog_timer_fn+0x2b8/0x304\n __run_hrtimer+0x88/0x2c0\n __hrtimer_run_queues+0xa4/0x120\n hrtimer_interrupt+0xfc/0x270\n arch_timer_handler_phys+0x40/0x50\n handle_percpu_devid_irq+0x94/0x220\n __handle_domain_irq+0x88/0xf0\n gic_handle_irq+0x84/0xfc\n el1_irq+0xc8/0x180\n slip_unesc+0x80/0x214 [slip]\n tty_ldisc_receive_buf+0x64/0x80\n tty_port_default_receive_buf+0x50/0x90\n flush_to_ldisc+0xbc/0x110\n process_one_work+0x1d4/0x4b0\n worker_thread+0x180/0x430\n kthread+0x11c/0x120\r\n\r\nIn the testcase pty04, The first process call the write syscall to send\ndata to the pty master. At the same time, the workqueue will do the\nflush_to_ldisc to pop data in a loop until there is no more data left.\nWhen the sender and workqueue running in different core, the sender sends\ndata fastly in full time which will result in workqueue doing work in loop\nfor a long time and occuring softlockup in flush_to_ldisc with kernel\nconfigured without preempt. So I add need_resched check and cond_resched\nin the flush_to_ldisc loop to avoid it.(CVE-2021-47185)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\niavf: free q_vectors before queues in iavf_disable_vf\r\n\r\niavf_free_queues() clears adapter-\u0026gt;num_active_queues, which\niavf_free_q_vectors() relies on, so swap the order of these two function\ncalls in iavf_disable_vf(). This resolves a panic encountered when the\ninterface is disabled and then later brought up again after PF\ncommunication is restored.(CVE-2021-47201)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: lpfc: Fix list_add() corruption in lpfc_drain_txq()\r\n\r\nWhen parsing the txq list in lpfc_drain_txq(), the driver attempts to pass\nthe requests to the adapter. If such an attempt fails, a local \u0026quot;fail_msg\u0026quot;\nstring is set and a log message output. The job is then added to a\ncompletions list for cancellation.\r\n\r\nProcessing of any further jobs from the txq list continues, but since\n\u0026quot;fail_msg\u0026quot; remains set, jobs are added to the completions list regardless\nof whether a wqe was passed to the adapter. If successfully added to\ntxcmplq, jobs are added to both lists resulting in list corruption.\r\n\r\nFix by clearing the fail_msg string after adding a job to the completions\nlist. This stops the subsequent jobs from being added to the completions\nlist unless they had an appropriate failure.(CVE-2021-47203)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nALSA: usb-audio: fix null pointer dereference on pointer cs_desc\r\n\r\nThe pointer cs_desc return from snd_usb_find_clock_source could\nbe null, so there is a potential null pointer dereference issue.\nFix this by adding a null check before dereference.(CVE-2021-47211)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: advansys: Fix kernel pointer leak\r\n\r\nPointers should be printed with %p or %px rather than cast to \u0026apos;unsigned\nlong\u0026apos; and printed with %lx.\r\n\r\nChange %lx to %p to print the hashed pointer.(CVE-2021-47216)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nx86/hyperv: Fix NULL deref in set_hv_tscchange_cb() if Hyper-V setup fails\r\n\r\nCheck for a valid hv_vp_index array prior to derefencing hv_vp_index when\nsetting Hyper-V\u0026apos;s TSC change callback. If Hyper-V setup failed in\nhyperv_init(), the kernel will still report that it\u0026apos;s running under\nHyper-V, but will have silently disabled nearly all functionality.\r\n\r\n BUG: kernel NULL pointer dereference, address: 0000000000000010\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\n PGD 0 P4D 0\n Oops: 0000 [#1] SMP\n CPU: 4 PID: 1 Comm: swapper/0 Not tainted 5.15.0-rc2+ #75\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015\n RIP: 0010:set_hv_tscchange_cb+0x15/0xa0\n Code: \u0026lt;8b\u0026gt; 04 82 8b 15 12 17 85 01 48 c1 e0 20 48 0d ee 00 01 00 f6 c6 08\n ...\n Call Trace:\n kvm_arch_init+0x17c/0x280\n kvm_init+0x31/0x330\n vmx_init+0xba/0x13a\n do_one_initcall+0x41/0x1c0\n kernel_init_freeable+0x1f2/0x23b\n kernel_init+0x16/0x120\n ret_from_fork+0x22/0x30(CVE-2021-47217)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: hub: Guard against accesses to uninitialized BOS descriptors\r\n\r\nMany functions in drivers/usb/core/hub.c and drivers/usb/core/hub.h\naccess fields inside udev-\u0026gt;bos without checking if it was allocated and\ninitialized. If usb_get_bos_descriptor() fails for whatever\nreason, udev-\u0026gt;bos will be NULL and those accesses will result in a\ncrash:\r\n\r\nBUG: kernel NULL pointer dereference, address: 0000000000000018\nPGD 0 P4D 0\nOops: 0000 [#1] PREEMPT SMP NOPTI\nCPU: 5 PID: 17818 Comm: kworker/5:1 Tainted: G W 5.15.108-18910-gab0e1cb584e1 #1 \u0026lt;HASH:1f9e 1\u0026gt;\nHardware name: Google Kindred/Kindred, BIOS Google_Kindred.12672.413.0 02/03/2021\nWorkqueue: usb_hub_wq hub_event\nRIP: 0010:hub_port_reset+0x193/0x788\nCode: 89 f7 e8 20 f7 15 00 48 8b 43 08 80 b8 96 03 00 00 03 75 36 0f b7 88 92 03 00 00 81 f9 10 03 00 00 72 27 48 8b 80 a8 03 00 00 \u0026lt;48\u0026gt; 83 78 18 00 74 19 48 89 df 48 8b 75 b0 ba 02 00 00 00 4c 89 e9\nRSP: 0018:ffffab740c53fcf8 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: ffffa1bc5f678000 RCX: 0000000000000310\nRDX: fffffffffffffdff RSI: 0000000000000286 RDI: ffffa1be9655b840\nRBP: ffffab740c53fd70 R08: 00001b7d5edaa20c R09: ffffffffb005e060\nR10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000\nR13: ffffab740c53fd3e R14: 0000000000000032 R15: 0000000000000000\nFS: 0000000000000000(0000) GS:ffffa1be96540000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000018 CR3: 000000022e80c005 CR4: 00000000003706e0\nCall Trace:\nhub_event+0x73f/0x156e\n? hub_activate+0x5b7/0x68f\nprocess_one_work+0x1a2/0x487\nworker_thread+0x11a/0x288\nkthread+0x13a/0x152\n? process_one_work+0x487/0x487\n? kthread_associate_blkcg+0x70/0x70\nret_from_fork+0x1f/0x30\r\n\r\nFall back to a default behavior if the BOS descriptor isn\u0026apos;t accessible\nand skip all the functionalities that depend on it: LPM support checks,\nSuper Speed capabilitiy checks, U1/U2 states setup.(CVE-2023-52477)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbinder: fix race between mmput() and do_exit()\r\n\r\nTask A calls binder_update_page_range() to allocate and insert pages on\na remote address space from Task B. For this, Task A pins the remote mm\nvia mmget_not_zero() first. This can race with Task B do_exit() and the\nfinal mmput() refcount decrement will come from Task A.\r\n\r\n Task A | Task B\n ------------------+------------------\n mmget_not_zero() |\n | do_exit()\n | exit_mm()\n | mmput()\n mmput() |\n exit_mmap() |\n remove_vma() |\n fput() |\r\n\r\nIn this case, the work of ____fput() from Task B is queued up in Task A\nas TWA_RESUME. So in theory, Task A returns to userspace and the cleanup\nwork gets executed. However, Task A instead sleep, waiting for a reply\nfrom Task B that never comes (it\u0026apos;s dead).\r\n\r\nThis means the binder_deferred_release() is blocked until an unrelated\nbinder event forces Task A to go back to userspace. All the associated\ndeath notifications will also be delayed until then.\r\n\r\nIn order to fix this use mmput_async() that will schedule the work in\nthe corresponding mm-\u0026gt;async_put_work WQ instead of Task A.(CVE-2023-52609)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncrypto: scomp - fix req-\u0026gt;dst buffer overflow\r\n\r\nThe req-\u0026gt;dst buffer size should be checked before copying from the\nscomp_scratch-\u0026gt;dst to avoid req-\u0026gt;dst buffer overflow problem.(CVE-2023-52612)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nllc: Drop support for ETH_P_TR_802_2.\r\n\r\nsyzbot reported an uninit-value bug below. [0]\r\n\r\nllc supports ETH_P_802_2 (0x0004) and used to support ETH_P_TR_802_2\n(0x0011), and syzbot abused the latter to trigger the bug.\r\n\r\n write$tun(r0, \u0026amp;(0x7f0000000040)={@val={0x0, 0x11}, @val, @mpls={[], @llc={@snap={0xaa, 0x1, \u0026apos;)\u0026apos;, \u0026quot;90e5dd\u0026quot;}}}}, 0x16)\r\n\r\nllc_conn_handler() initialises local variables {saddr,daddr}.mac\nbased on skb in llc_pdu_decode_sa()/llc_pdu_decode_da() and passes\nthem to __llc_lookup().\r\n\r\nHowever, the initialisation is done only when skb-\u0026gt;protocol is\nhtons(ETH_P_802_2), otherwise, __llc_lookup_established() and\n__llc_lookup_listener() will read garbage.\r\n\r\nThe missing initialisation existed prior to commit 211ed865108e\n(\u0026quot;net: delete all instances of special processing for token ring\u0026quot;).\r\n\r\nIt removed the part to kick out the token ring stuff but forgot to\nclose the door allowing ETH_P_TR_802_2 packets to sneak into llc_rcv().\r\n\r\nLet\u0026apos;s remove llc_tr_packet_type and complete the deprecation.\r\n\r\n[0]:\nBUG: KMSAN: uninit-value in __llc_lookup_established+0xe9d/0xf90\n __llc_lookup_established+0xe9d/0xf90\n __llc_lookup net/llc/llc_conn.c:611 [inline]\n llc_conn_handler+0x4bd/0x1360 net/llc/llc_conn.c:791\n llc_rcv+0xfbb/0x14a0 net/llc/llc_input.c:206\n __netif_receive_skb_one_core net/core/dev.c:5527 [inline]\n __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5641\n netif_receive_skb_internal net/core/dev.c:5727 [inline]\n netif_receive_skb+0x58/0x660 net/core/dev.c:5786\n tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555\n tun_get_user+0x53af/0x66d0 drivers/net/tun.c:2002\n tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048\n call_write_iter include/linux/fs.h:2020 [inline]\n new_sync_write fs/read_write.c:491 [inline]\n vfs_write+0x8ef/0x1490 fs/read_write.c:584\n ksys_write+0x20f/0x4c0 fs/read_write.c:637\n __do_sys_write fs/read_write.c:649 [inline]\n __se_sys_write fs/read_write.c:646 [inline]\n __x64_sys_write+0x93/0xd0 fs/read_write.c:646\n do_syscall_x64 arch/x86/entry/common.c:51 [inline]\n do_syscall_64+0x44/0x110 arch/x86/entry/common.c:82\n entry_SYSCALL_64_after_hwframe+0x63/0x6b\r\n\r\nLocal variable daddr created at:\n llc_conn_handler+0x53/0x1360 net/llc/llc_conn.c:783\n llc_rcv+0xfbb/0x14a0 net/llc/llc_input.c:206\r\n\r\nCPU: 1 PID: 5004 Comm: syz-executor994 Not tainted 6.6.0-syzkaller-14500-g1c41041124bd #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/09/2023(CVE-2024-26635)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nllc: make llc_ui_sendmsg() more robust against bonding changes\r\n\r\nsyzbot was able to trick llc_ui_sendmsg(), allocating an skb with no\nheadroom, but subsequently trying to push 14 bytes of Ethernet header [1]\r\n\r\nLike some others, llc_ui_sendmsg() releases the socket lock before\ncalling sock_alloc_send_skb().\nThen it acquires it again, but does not redo all the sanity checks\nthat were performed.\r\n\r\nThis fix:\r\n\r\n- Uses LL_RESERVED_SPACE() to reserve space.\n- Check all conditions again after socket lock is held again.\n- Do not account Ethernet header for mtu limitation.\r\n\r\n[1]\r\n\r\nskbuff: skb_under_panic: text:ffff800088baa334 len:1514 put:14 head:ffff0000c9c37000 data:ffff0000c9c36ff2 tail:0x5dc end:0x6c0 dev:bond0\r\n\r\n kernel BUG at net/core/skbuff.c:193 !\nInternal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP\nModules linked in:\nCPU: 0 PID: 6875 Comm: syz-executor.0 Not tainted 6.7.0-rc8-syzkaller-00101-g0802e17d9aca-dirty #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023\npstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : skb_panic net/core/skbuff.c:189 [inline]\n pc : skb_under_panic+0x13c/0x140 net/core/skbuff.c:203\n lr : skb_panic net/core/skbuff.c:189 [inline]\n lr : skb_under_panic+0x13c/0x140 net/core/skbuff.c:203\nsp : ffff800096f97000\nx29: ffff800096f97010 x28: ffff80008cc8d668 x27: dfff800000000000\nx26: ffff0000cb970c90 x25: 00000000000005dc x24: ffff0000c9c36ff2\nx23: ffff0000c9c37000 x22: 00000000000005ea x21: 00000000000006c0\nx20: 000000000000000e x19: ffff800088baa334 x18: 1fffe000368261ce\nx17: ffff80008e4ed000 x16: ffff80008a8310f8 x15: 0000000000000001\nx14: 1ffff00012df2d58 x13: 0000000000000000 x12: 0000000000000000\nx11: 0000000000000001 x10: 0000000000ff0100 x9 : e28a51f1087e8400\nx8 : e28a51f1087e8400 x7 : ffff80008028f8d0 x6 : 0000000000000000\nx5 : 0000000000000001 x4 : 0000000000000001 x3 : ffff800082b78714\nx2 : 0000000000000001 x1 : 0000000100000000 x0 : 0000000000000089\nCall trace:\n skb_panic net/core/skbuff.c:189 [inline]\n skb_under_panic+0x13c/0x140 net/core/skbuff.c:203\n skb_push+0xf0/0x108 net/core/skbuff.c:2451\n eth_header+0x44/0x1f8 net/ethernet/eth.c:83\n dev_hard_header include/linux/netdevice.h:3188 [inline]\n llc_mac_hdr_init+0x110/0x17c net/llc/llc_output.c:33\n llc_sap_action_send_xid_c+0x170/0x344 net/llc/llc_s_ac.c:85\n llc_exec_sap_trans_actions net/llc/llc_sap.c:153 [inline]\n llc_sap_next_state net/llc/llc_sap.c:182 [inline]\n llc_sap_state_process+0x1ec/0x774 net/llc/llc_sap.c:209\n llc_build_and_send_xid_pkt+0x12c/0x1c0 net/llc/llc_sap.c:270\n llc_ui_sendmsg+0x7bc/0xb1c net/llc/af_llc.c:997\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg net/socket.c:745 [inline]\n sock_sendmsg+0x194/0x274 net/socket.c:767\n splice_to_socket+0x7cc/0xd58 fs/splice.c:881\n do_splice_from fs/splice.c:933 [inline]\n direct_splice_actor+0xe4/0x1c0 fs/splice.c:1142\n splice_direct_to_actor+0x2a0/0x7e4 fs/splice.c:1088\n do_splice_direct+0x20c/0x348 fs/splice.c:1194\n do_sendfile+0x4bc/0xc70 fs/read_write.c:1254\n __do_sys_sendfile64 fs/read_write.c:1322 [inline]\n __se_sys_sendfile64 fs/read_write.c:1308 [inline]\n __arm64_sys_sendfile64+0x160/0x3b4 fs/read_write.c:1308\n __invoke_syscall arch/arm64/kernel/syscall.c:37 [inline]\n invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:51\n el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:136\n do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:155\n el0_svc+0x54/0x158 arch/arm64/kernel/entry-common.c:678\n el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:696\n el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:595\nCode: aa1803e6 aa1903e7 a90023f5 94792f6a (d4210000)(CVE-2024-26636)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntcp: add sanity checks to rx zerocopy\r\n\r\nTCP rx zerocopy intent is to map pages initially allocated\nfrom NIC drivers, not pages owned by a fs.\r\n\r\nThis patch adds to can_map_frag() these additional checks:\r\n\r\n- Page must not be a compound one.\n- page-\u0026gt;mapping must be NULL.\r\n\r\nThis fixes the panic reported by ZhangPeng.\r\n\r\nsyzbot was able to loopback packets built with sendfile(),\nmapping pages owned by an ext4 file to TCP rx zerocopy.\r\n\r\nr3 = socket$inet_tcp(0x2, 0x1, 0x0)\nmmap(\u0026amp;(0x7f0000ff9000/0x4000)=nil, 0x4000, 0x0, 0x12, r3, 0x0)\nr4 = socket$inet_tcp(0x2, 0x1, 0x0)\nbind$inet(r4, \u0026amp;(0x7f0000000000)={0x2, 0x4e24, @multicast1}, 0x10)\nconnect$inet(r4, \u0026amp;(0x7f00000006c0)={0x2, 0x4e24, @empty}, 0x10)\nr5 = openat$dir(0xffffffffffffff9c, \u0026amp;(0x7f00000000c0)=\u0026apos;./file0\\x00\u0026apos;,\n 0x181e42, 0x0)\nfallocate(r5, 0x0, 0x0, 0x85b8)\nsendfile(r4, r5, 0x0, 0x8ba0)\ngetsockopt$inet_tcp_TCP_ZEROCOPY_RECEIVE(r4, 0x6, 0x23,\n \u0026amp;(0x7f00000001c0)={\u0026amp;(0x7f0000ffb000/0x3000)=nil, 0x3000, 0x0, 0x0, 0x0,\n 0x0, 0x0, 0x0, 0x0}, \u0026amp;(0x7f0000000440)=0x40)\nr6 = openat$dir(0xffffffffffffff9c, \u0026amp;(0x7f00000000c0)=\u0026apos;./file0\\x00\u0026apos;,\n 0x181e42, 0x0)(CVE-2024-26640)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv()\r\n\r\nsyzbot found __ip6_tnl_rcv() could access unitiliazed data [1].\r\n\r\nCall pskb_inet_may_pull() to fix this, and initialize ipv6h\nvariable after this call as it can change skb-\u0026gt;head.\r\n\r\n[1]\n BUG: KMSAN: uninit-value in __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline]\n BUG: KMSAN: uninit-value in INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline]\n BUG: KMSAN: uninit-value in IP6_ECN_decapsulate+0x7df/0x1e50 include/net/inet_ecn.h:321\n __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline]\n INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline]\n IP6_ECN_decapsulate+0x7df/0x1e50 include/net/inet_ecn.h:321\n ip6ip6_dscp_ecn_decapsulate+0x178/0x1b0 net/ipv6/ip6_tunnel.c:727\n __ip6_tnl_rcv+0xd4e/0x1590 net/ipv6/ip6_tunnel.c:845\n ip6_tnl_rcv+0xce/0x100 net/ipv6/ip6_tunnel.c:888\n gre_rcv+0x143f/0x1870\n ip6_protocol_deliver_rcu+0xda6/0x2a60 net/ipv6/ip6_input.c:438\n ip6_input_finish net/ipv6/ip6_input.c:483 [inline]\n NF_HOOK include/linux/netfilter.h:314 [inline]\n ip6_input+0x15d/0x430 net/ipv6/ip6_input.c:492\n ip6_mc_input+0xa7e/0xc80 net/ipv6/ip6_input.c:586\n dst_input include/net/dst.h:461 [inline]\n ip6_rcv_finish+0x5db/0x870 net/ipv6/ip6_input.c:79\n NF_HOOK include/linux/netfilter.h:314 [inline]\n ipv6_rcv+0xda/0x390 net/ipv6/ip6_input.c:310\n __netif_receive_skb_one_core net/core/dev.c:5532 [inline]\n __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5646\n netif_receive_skb_internal net/core/dev.c:5732 [inline]\n netif_receive_skb+0x58/0x660 net/core/dev.c:5791\n tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555\n tun_get_user+0x53af/0x66d0 drivers/net/tun.c:2002\n tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048\n call_write_iter include/linux/fs.h:2084 [inline]\n new_sync_write fs/read_write.c:497 [inline]\n vfs_write+0x786/0x1200 fs/read_write.c:590\n ksys_write+0x20f/0x4c0 fs/read_write.c:643\n __do_sys_write fs/read_write.c:655 [inline]\n __se_sys_write fs/read_write.c:652 [inline]\n __x64_sys_write+0x93/0xd0 fs/read_write.c:652\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0x6d/0x140 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+0x129/0xa70 mm/slab.h:768\n slab_alloc_node mm/slub.c:3478 [inline]\n kmem_cache_alloc_node+0x5e9/0xb10 mm/slub.c:3523\n kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560\n __alloc_skb+0x318/0x740 net/core/skbuff.c:651\n alloc_skb include/linux/skbuff.h:1286 [inline]\n alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6334\n sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2787\n tun_alloc_skb drivers/net/tun.c:1531 [inline]\n tun_get_user+0x1e8a/0x66d0 drivers/net/tun.c:1846\n tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048\n call_write_iter include/linux/fs.h:2084 [inline]\n new_sync_write fs/read_write.c:497 [inline]\n vfs_write+0x786/0x1200 fs/read_write.c:590\n ksys_write+0x20f/0x4c0 fs/read_write.c:643\n __do_sys_write fs/read_write.c:655 [inline]\n __se_sys_write fs/read_write.c:652 [inline]\n __x64_sys_write+0x93/0xd0 fs/read_write.c:652\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x63/0x6b\r\n\r\nCPU: 0 PID: 5034 Comm: syz-executor331 Not tainted 6.7.0-syzkaller-00562-g9f8413c4a66f #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023(CVE-2024-26641)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nl2tp: pass correct message length to ip6_append_data\r\n\r\nl2tp_ip6_sendmsg needs to avoid accounting for the transport header\ntwice when splicing more data into an already partially-occupied skbuff.\r\n\r\nTo manage this, we check whether the skbuff contains data using\nskb_queue_empty when deciding how much data to append using\nip6_append_data.\r\n\r\nHowever, the code which performed the calculation was incorrect:\r\n\r\n ulen = len + skb_queue_empty(\u0026amp;sk-\u0026gt;sk_write_queue) ? transhdrlen : 0;\r\n\r\n...due to C operator precedence, this ends up setting ulen to\ntranshdrlen for messages with a non-zero length, which results in\ncorrupted packets on the wire.\r\n\r\nAdd parentheses to correct the calculation in line with the original\nintent.(CVE-2024-26752)",
"id": "OESA-2024-1567",
"modified": "2026-08-06T11:07:01Z",
"published": "2024-05-11T11:07:01Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1567"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-46929"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-46936"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-46966"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47082"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47123"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47182"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47185"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47201"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47203"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47211"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47216"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47217"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52477"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52609"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52612"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26635"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26636"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26640"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26641"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26752"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2021-46929",
"CVE-2021-46936",
"CVE-2021-46966",
"CVE-2021-47082",
"CVE-2021-47123",
"CVE-2021-47182",
"CVE-2021-47185",
"CVE-2021-47201",
"CVE-2021-47203",
"CVE-2021-47211",
"CVE-2021-47216",
"CVE-2021-47217",
"CVE-2023-52477",
"CVE-2023-52609",
"CVE-2023-52612",
"CVE-2024-26635",
"CVE-2024-26636",
"CVE-2024-26640",
"CVE-2024-26641",
"CVE-2024-26752"
]
}
OESA-2024-1568 (CVE-2021-47182)
Vulnerability from osv_openeuler – Published: 2024-05-11 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:
scsi: core: Fix scsi_mode_sense() buffer length handling
Several problems exist with scsi_mode_sense() buffer length handling:
1) The allocation length field of the MODE SENSE(10) command is 16-bits, occupying bytes 7 and 8 of the CDB. With this command, access to mode pages larger than 255 bytes is thus possible. However, the CDB allocation length field is set by assigning len to byte 8 only, thus truncating buffer length larger than 255.
2) If scsi_mode_sense() is called with len smaller than 8 with sdev->use_10_for_ms set, or smaller than 4 otherwise, the buffer length is increased to 8 and 4 respectively, and the buffer is zero filled with these increased values, thus corrupting the memory following the buffer.
Fix these 2 problems by using put_unaligned_be16() to set the allocation length field of MODE SENSE(10) CDB and by returning an error when len is too small.
Furthermore, if len is larger than 255B, always try MODE SENSE(10) first, even if the device driver did not set sdev->use_10_for_ms. In case of invalid opcode error for MODE SENSE(10), access to mode pages larger than 255 bytes are not retried using MODE SENSE(6). To avoid buffer length overflows for the MODE_SENSE(10) case, check that len is smaller than 65535 bytes.
While at it, also fix the folowing:
-
Use get_unaligned_be16() to retrieve the mode data length and block descriptor length fields of the mode sense reply header instead of using an open coded calculation.
-
Fix the kdoc dbd argument explanation: the DBD bit stands for Disable Block Descriptor, which is the opposite of what the dbd argument description was.(CVE-2021-47182)
In the Linux kernel, the following vulnerability has been resolved:
iavf: free q_vectors before queues in iavf_disable_vf
iavf_free_queues() clears adapter->num_active_queues, which iavf_free_q_vectors() relies on, so swap the order of these two function calls in iavf_disable_vf(). This resolves a panic encountered when the interface is disabled and then later brought up again after PF communication is restored.(CVE-2021-47201)
In the Linux kernel, the following vulnerability has been resolved:
scsi: lpfc: Fix list_add() corruption in lpfc_drain_txq()
When parsing the txq list in lpfc_drain_txq(), the driver attempts to pass the requests to the adapter. If such an attempt fails, a local "fail_msg" string is set and a log message output. The job is then added to a completions list for cancellation.
Processing of any further jobs from the txq list continues, but since "fail_msg" remains set, jobs are added to the completions list regardless of whether a wqe was passed to the adapter. If successfully added to txcmplq, jobs are added to both lists resulting in list corruption.
Fix by clearing the fail_msg string after adding a job to the completions list. This stops the subsequent jobs from being added to the completions list unless they had an appropriate failure.(CVE-2021-47203)
In the Linux kernel, the following vulnerability has been resolved:
ALSA: usb-audio: fix null pointer dereference on pointer cs_desc
The pointer cs_desc return from snd_usb_find_clock_source could be null, so there is a potential null pointer dereference issue. Fix this by adding a null check before dereference.(CVE-2021-47211)
In the Linux kernel, the following vulnerability has been resolved:
scsi: advansys: Fix kernel pointer leak
Pointers should be printed with %p or %px rather than cast to 'unsigned long' and printed with %lx.
Change %lx to %p to print the hashed pointer.(CVE-2021-47216)
In the Linux kernel, the following vulnerability has been resolved:
x86/hyperv: Fix NULL deref in set_hv_tscchange_cb() if Hyper-V setup fails
Check for a valid hv_vp_index array prior to derefencing hv_vp_index when setting Hyper-V's TSC change callback. If Hyper-V setup failed in hyperv_init(), the kernel will still report that it's running under Hyper-V, but will have silently disabled nearly all functionality.
BUG: kernel NULL pointer dereference, address: 0000000000000010 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] SMP CPU: 4 PID: 1 Comm: swapper/0 Not tainted 5.15.0-rc2+ #75 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:set_hv_tscchange_cb+0x15/0xa0 Code: <8b> 04 82 8b 15 12 17 85 01 48 c1 e0 20 48 0d ee 00 01 00 f6 c6 08 ... Call Trace: kvm_arch_init+0x17c/0x280 kvm_init+0x31/0x330 vmx_init+0xba/0x13a do_one_initcall+0x41/0x1c0 kernel_init_freeable+0x1f2/0x23b kernel_init+0x16/0x120 ret_from_fork+0x22/0x30(CVE-2021-47217)
In the Linux kernel, the following vulnerability has been resolved:
usb: hub: Guard against accesses to uninitialized BOS descriptors
Many functions in drivers/usb/core/hub.c and drivers/usb/core/hub.h access fields inside udev->bos without checking if it was allocated and initialized. If usb_get_bos_descriptor() fails for whatever reason, udev->bos will be NULL and those accesses will result in a crash:
BUG: kernel NULL pointer dereference, address: 0000000000000018 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 5 PID: 17818 Comm: kworker/5:1 Tainted: G W 5.15.108-18910-gab0e1cb584e1 #1 <HASH:1f9e 1> Hardware name: Google Kindred/Kindred, BIOS Google_Kindred.12672.413.0 02/03/2021 Workqueue: usb_hub_wq hub_event RIP: 0010:hub_port_reset+0x193/0x788 Code: 89 f7 e8 20 f7 15 00 48 8b 43 08 80 b8 96 03 00 00 03 75 36 0f b7 88 92 03 00 00 81 f9 10 03 00 00 72 27 48 8b 80 a8 03 00 00 <48> 83 78 18 00 74 19 48 89 df 48 8b 75 b0 ba 02 00 00 00 4c 89 e9 RSP: 0018:ffffab740c53fcf8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffffa1bc5f678000 RCX: 0000000000000310 RDX: fffffffffffffdff RSI: 0000000000000286 RDI: ffffa1be9655b840 RBP: ffffab740c53fd70 R08: 00001b7d5edaa20c R09: ffffffffb005e060 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000 R13: ffffab740c53fd3e R14: 0000000000000032 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffffa1be96540000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000018 CR3: 000000022e80c005 CR4: 00000000003706e0 Call Trace: hub_event+0x73f/0x156e ? hub_activate+0x5b7/0x68f process_one_work+0x1a2/0x487 worker_thread+0x11a/0x288 kthread+0x13a/0x152 ? process_one_work+0x487/0x487 ? kthread_associate_blkcg+0x70/0x70 ret_from_fork+0x1f/0x30
Fall back to a default behavior if the BOS descriptor isn't accessible and skip all the functionalities that depend on it: LPM support checks, Super Speed capabilitiy checks, U1/U2 states setup.(CVE-2023-52477)
In the Linux kernel, the following vulnerability has been resolved:
binder: fix race between mmput() and do_exit()
Task A calls binder_update_page_range() to allocate and insert pages on a remote address space from Task B. For this, Task A pins the remote mm via mmget_not_zero() first. This can race with Task B do_exit() and the final mmput() refcount decrement will come from Task A.
Task A | Task B ------------------+------------------ mmget_not_zero() | | do_exit() | exit_mm() | mmput() mmput() | exit_mmap() | remove_vma() | fput() |
In this case, the work of ____fput() from Task B is queued up in Task A as TWA_RESUME. So in theory, Task A returns to userspace and the cleanup work gets executed. However, Task A instead sleep, waiting for a reply from Task B that never comes (it's dead).
This means the binder_deferred_release() is blocked until an unrelated binder event forces Task A to go back to userspace. All the associated death notifications will also be delayed until then.
In order to fix this use mmput_async() that will schedule the work in the corresponding mm->async_put_work WQ instead of Task A.(CVE-2023-52609)
In the Linux kernel, the following vulnerability has been resolved:
llc: Drop support for ETH_P_TR_802_2.
syzbot reported an uninit-value bug below. [0]
llc supports ETH_P_802_2 (0x0004) and used to support ETH_P_TR_802_2 (0x0011), and syzbot abused the latter to trigger the bug.
write$tun(r0, &(0x7f0000000040)={@val={0x0, 0x11}, @val, @mpls={[], @llc={@snap={0xaa, 0x1, ')', "90e5dd"}}}}, 0x16)
llc_conn_handler() initialises local variables {saddr,daddr}.mac based on skb in llc_pdu_decode_sa()/llc_pdu_decode_da() and passes them to __llc_lookup().
However, the initialisation is done only when skb->protocol is htons(ETH_P_802_2), otherwise, __llc_lookup_established() and __llc_lookup_listener() will read garbage.
The missing initialisation existed prior to commit 211ed865108e ("net: delete all instances of special processing for token ring").
It removed the part to kick out the token ring stuff but forgot to close the door allowing ETH_P_TR_802_2 packets to sneak into llc_rcv().
Let's remove llc_tr_packet_type and complete the deprecation.
[0]: BUG: KMSAN: uninit-value in __llc_lookup_established+0xe9d/0xf90 __llc_lookup_established+0xe9d/0xf90 __llc_lookup net/llc/llc_conn.c:611 [inline] llc_conn_handler+0x4bd/0x1360 net/llc/llc_conn.c:791 llc_rcv+0xfbb/0x14a0 net/llc/llc_input.c:206 __netif_receive_skb_one_core net/core/dev.c:5527 [inline] __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5641 netif_receive_skb_internal net/core/dev.c:5727 [inline] netif_receive_skb+0x58/0x660 net/core/dev.c:5786 tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555 tun_get_user+0x53af/0x66d0 drivers/net/tun.c:2002 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048 call_write_iter include/linux/fs.h:2020 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x8ef/0x1490 fs/read_write.c:584 ksys_write+0x20f/0x4c0 fs/read_write.c:637 __do_sys_write fs/read_write.c:649 [inline] __se_sys_write fs/read_write.c:646 [inline] __x64_sys_write+0x93/0xd0 fs/read_write.c:646 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x44/0x110 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x63/0x6b
Local variable daddr created at: llc_conn_handler+0x53/0x1360 net/llc/llc_conn.c:783 llc_rcv+0xfbb/0x14a0 net/llc/llc_input.c:206
CPU: 1 PID: 5004 Comm: syz-executor994 Not tainted 6.6.0-syzkaller-14500-g1c41041124bd #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/09/2023(CVE-2024-26635)
In the Linux kernel, the following vulnerability has been resolved:
llc: make llc_ui_sendmsg() more robust against bonding changes
syzbot was able to trick llc_ui_sendmsg(), allocating an skb with no headroom, but subsequently trying to push 14 bytes of Ethernet header [1]
Like some others, llc_ui_sendmsg() releases the socket lock before calling sock_alloc_send_skb(). Then it acquires it again, but does not redo all the sanity checks that were performed.
This fix:
- Uses LL_RESERVED_SPACE() to reserve space.
- Check all conditions again after socket lock is held again.
- Do not account Ethernet header for mtu limitation.
[1]
skbuff: skb_under_panic: text:ffff800088baa334 len:1514 put:14 head:ffff0000c9c37000 data:ffff0000c9c36ff2 tail:0x5dc end:0x6c0 dev:bond0
kernel BUG at net/core/skbuff.c:193 ! Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP Modules linked in: CPU: 0 PID: 6875 Comm: syz-executor.0 Not tainted 6.7.0-rc8-syzkaller-00101-g0802e17d9aca-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : skb_panic net/core/skbuff.c:189 [inline] pc : skb_under_panic+0x13c/0x140 net/core/skbuff.c:203 lr : skb_panic net/core/skbuff.c:189 [inline] lr : skb_under_panic+0x13c/0x140 net/core/skbuff.c:203 sp : ffff800096f97000 x29: ffff800096f97010 x28: ffff80008cc8d668 x27: dfff800000000000 x26: ffff0000cb970c90 x25: 00000000000005dc x24: ffff0000c9c36ff2 x23: ffff0000c9c37000 x22: 00000000000005ea x21: 00000000000006c0 x20: 000000000000000e x19: ffff800088baa334 x18: 1fffe000368261ce x17: ffff80008e4ed000 x16: ffff80008a8310f8 x15: 0000000000000001 x14: 1ffff00012df2d58 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000001 x10: 0000000000ff0100 x9 : e28a51f1087e8400 x8 : e28a51f1087e8400 x7 : ffff80008028f8d0 x6 : 0000000000000000 x5 : 0000000000000001 x4 : 0000000000000001 x3 : ffff800082b78714 x2 : 0000000000000001 x1 : 0000000100000000 x0 : 0000000000000089 Call trace: skb_panic net/core/skbuff.c:189 [inline] skb_under_panic+0x13c/0x140 net/core/skbuff.c:203 skb_push+0xf0/0x108 net/core/skbuff.c:2451 eth_header+0x44/0x1f8 net/ethernet/eth.c:83 dev_hard_header include/linux/netdevice.h:3188 [inline] llc_mac_hdr_init+0x110/0x17c net/llc/llc_output.c:33 llc_sap_action_send_xid_c+0x170/0x344 net/llc/llc_s_ac.c:85 llc_exec_sap_trans_actions net/llc/llc_sap.c:153 [inline] llc_sap_next_state net/llc/llc_sap.c:182 [inline] llc_sap_state_process+0x1ec/0x774 net/llc/llc_sap.c:209 llc_build_and_send_xid_pkt+0x12c/0x1c0 net/llc/llc_sap.c:270 llc_ui_sendmsg+0x7bc/0xb1c net/llc/af_llc.c:997 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] sock_sendmsg+0x194/0x274 net/socket.c:767 splice_to_socket+0x7cc/0xd58 fs/splice.c:881 do_splice_from fs/splice.c:933 [inline] direct_splice_actor+0xe4/0x1c0 fs/splice.c:1142 splice_direct_to_actor+0x2a0/0x7e4 fs/splice.c:1088 do_splice_direct+0x20c/0x348 fs/splice.c:1194 do_sendfile+0x4bc/0xc70 fs/read_write.c:1254 __do_sys_sendfile64 fs/read_write.c:1322 [inline] __se_sys_sendfile64 fs/read_write.c:1308 [inline] __arm64_sys_sendfile64+0x160/0x3b4 fs/read_write.c:1308 __invoke_syscall arch/arm64/kernel/syscall.c:37 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:51 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:136 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:155 el0_svc+0x54/0x158 arch/arm64/kernel/entry-common.c:678 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:696 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:595 Code: aa1803e6 aa1903e7 a90023f5 94792f6a (d4210000)(CVE-2024-26636)
In the Linux kernel, the following vulnerability has been resolved:
tcp: add sanity checks to rx zerocopy
TCP rx zerocopy intent is to map pages initially allocated from NIC drivers, not pages owned by a fs.
This patch adds to can_map_frag() these additional checks:
- Page must not be a compound one.
- page->mapping must be NULL.
This fixes the panic reported by ZhangPeng.
syzbot was able to loopback packets built with sendfile(), mapping pages owned by an ext4 file to TCP rx zerocopy.
r3 = socket$inet_tcp(0x2, 0x1, 0x0) mmap(&(0x7f0000ff9000/0x4000)=nil, 0x4000, 0x0, 0x12, r3, 0x0) r4 = socket$inet_tcp(0x2, 0x1, 0x0) bind$inet(r4, &(0x7f0000000000)={0x2, 0x4e24, @multicast1}, 0x10) connect$inet(r4, &(0x7f00000006c0)={0x2, 0x4e24, @empty}, 0x10) r5 = openat$dir(0xffffffffffffff9c, &(0x7f00000000c0)='./file0\x00', 0x181e42, 0x0) fallocate(r5, 0x0, 0x0, 0x85b8) sendfile(r4, r5, 0x0, 0x8ba0) getsockopt$inet_tcp_TCP_ZEROCOPY_RECEIVE(r4, 0x6, 0x23, &(0x7f00000001c0)={&(0x7f0000ffb000/0x3000)=nil, 0x3000, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, &(0x7f0000000440)=0x40) r6 = openat$dir(0xffffffffffffff9c, &(0x7f00000000c0)='./file0\x00', 0x181e42, 0x0)(CVE-2024-26640)
In the Linux kernel, the following vulnerability has been resolved:
ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv()
syzbot found __ip6_tnl_rcv() could access unitiliazed data [1].
Call pskb_inet_may_pull() to fix this, and initialize ipv6h variable after this call as it can change skb->head.
[1] BUG: KMSAN: uninit-value in __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline] BUG: KMSAN: uninit-value in INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline] BUG: KMSAN: uninit-value in IP6_ECN_decapsulate+0x7df/0x1e50 include/net/inet_ecn.h:321 __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline] INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline] IP6_ECN_decapsulate+0x7df/0x1e50 include/net/inet_ecn.h:321 ip6ip6_dscp_ecn_decapsulate+0x178/0x1b0 net/ipv6/ip6_tunnel.c:727 __ip6_tnl_rcv+0xd4e/0x1590 net/ipv6/ip6_tunnel.c:845 ip6_tnl_rcv+0xce/0x100 net/ipv6/ip6_tunnel.c:888 gre_rcv+0x143f/0x1870 ip6_protocol_deliver_rcu+0xda6/0x2a60 net/ipv6/ip6_input.c:438 ip6_input_finish net/ipv6/ip6_input.c:483 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] ip6_input+0x15d/0x430 net/ipv6/ip6_input.c:492 ip6_mc_input+0xa7e/0xc80 net/ipv6/ip6_input.c:586 dst_input include/net/dst.h:461 [inline] ip6_rcv_finish+0x5db/0x870 net/ipv6/ip6_input.c:79 NF_HOOK include/linux/netfilter.h:314 [inline] ipv6_rcv+0xda/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core net/core/dev.c:5532 [inline] __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5646 netif_receive_skb_internal net/core/dev.c:5732 [inline] netif_receive_skb+0x58/0x660 net/core/dev.c:5791 tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555 tun_get_user+0x53af/0x66d0 drivers/net/tun.c:2002 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048 call_write_iter include/linux/fs.h:2084 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0x786/0x1200 fs/read_write.c:590 ksys_write+0x20f/0x4c0 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __x64_sys_write+0x93/0xd0 fs/read_write.c:652 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b
Uninit was created at: slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768 slab_alloc_node mm/slub.c:3478 [inline] kmem_cache_alloc_node+0x5e9/0xb10 mm/slub.c:3523 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560 __alloc_skb+0x318/0x740 net/core/skbuff.c:651 alloc_skb include/linux/skbuff.h:1286 [inline] alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6334 sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2787 tun_alloc_skb drivers/net/tun.c:1531 [inline] tun_get_user+0x1e8a/0x66d0 drivers/net/tun.c:1846 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048 call_write_iter include/linux/fs.h:2084 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0x786/0x1200 fs/read_write.c:590 ksys_write+0x20f/0x4c0 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __x64_sys_write+0x93/0xd0 fs/read_write.c:652 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b
CPU: 0 PID: 5034 Comm: syz-executor331 Not tainted 6.7.0-syzkaller-00562-g9f8413c4a66f #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023(CVE-2024-26641)
| URL | Type | ||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"python2-perf-debuginfo-4.19.90-2405.1.0.0275.oe2003sp4.aarch64.rpm",
"kernel-tools-4.19.90-2405.1.0.0275.oe2003sp4.aarch64.rpm",
"kernel-debuginfo-4.19.90-2405.1.0.0275.oe2003sp4.aarch64.rpm",
"kernel-source-4.19.90-2405.1.0.0275.oe2003sp4.aarch64.rpm",
"perf-debuginfo-4.19.90-2405.1.0.0275.oe2003sp4.aarch64.rpm",
"kernel-devel-4.19.90-2405.1.0.0275.oe2003sp4.aarch64.rpm",
"bpftool-debuginfo-4.19.90-2405.1.0.0275.oe2003sp4.aarch64.rpm",
"kernel-4.19.90-2405.1.0.0275.oe2003sp4.aarch64.rpm",
"python3-perf-4.19.90-2405.1.0.0275.oe2003sp4.aarch64.rpm",
"bpftool-4.19.90-2405.1.0.0275.oe2003sp4.aarch64.rpm",
"python3-perf-debuginfo-4.19.90-2405.1.0.0275.oe2003sp4.aarch64.rpm",
"perf-4.19.90-2405.1.0.0275.oe2003sp4.aarch64.rpm",
"kernel-tools-devel-4.19.90-2405.1.0.0275.oe2003sp4.aarch64.rpm",
"kernel-tools-debuginfo-4.19.90-2405.1.0.0275.oe2003sp4.aarch64.rpm",
"kernel-debugsource-4.19.90-2405.1.0.0275.oe2003sp4.aarch64.rpm",
"python2-perf-4.19.90-2405.1.0.0275.oe2003sp4.aarch64.rpm"
],
"src": [
"kernel-4.19.90-2405.1.0.0275.oe2003sp4.src.rpm"
],
"x86_64": [
"kernel-tools-debuginfo-4.19.90-2405.1.0.0275.oe2003sp4.x86_64.rpm",
"kernel-debuginfo-4.19.90-2405.1.0.0275.oe2003sp4.x86_64.rpm",
"kernel-devel-4.19.90-2405.1.0.0275.oe2003sp4.x86_64.rpm",
"kernel-tools-4.19.90-2405.1.0.0275.oe2003sp4.x86_64.rpm",
"python2-perf-4.19.90-2405.1.0.0275.oe2003sp4.x86_64.rpm",
"bpftool-4.19.90-2405.1.0.0275.oe2003sp4.x86_64.rpm",
"perf-debuginfo-4.19.90-2405.1.0.0275.oe2003sp4.x86_64.rpm",
"python3-perf-4.19.90-2405.1.0.0275.oe2003sp4.x86_64.rpm",
"python3-perf-debuginfo-4.19.90-2405.1.0.0275.oe2003sp4.x86_64.rpm",
"python2-perf-debuginfo-4.19.90-2405.1.0.0275.oe2003sp4.x86_64.rpm",
"perf-4.19.90-2405.1.0.0275.oe2003sp4.x86_64.rpm",
"kernel-tools-devel-4.19.90-2405.1.0.0275.oe2003sp4.x86_64.rpm",
"bpftool-debuginfo-4.19.90-2405.1.0.0275.oe2003sp4.x86_64.rpm",
"kernel-debugsource-4.19.90-2405.1.0.0275.oe2003sp4.x86_64.rpm",
"kernel-source-4.19.90-2405.1.0.0275.oe2003sp4.x86_64.rpm",
"kernel-4.19.90-2405.1.0.0275.oe2003sp4.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:20.03-LTS-SP4",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-20.03-LTS-SP4"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.19.90-2405.1.0.0275.oe2003sp4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "Medium"
},
"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\nscsi: core: Fix scsi_mode_sense() buffer length handling\r\n\r\nSeveral problems exist with scsi_mode_sense() buffer length handling:\r\n\r\n 1) The allocation length field of the MODE SENSE(10) command is 16-bits,\n occupying bytes 7 and 8 of the CDB. With this command, access to mode\n pages larger than 255 bytes is thus possible. However, the CDB\n allocation length field is set by assigning len to byte 8 only, thus\n truncating buffer length larger than 255.\r\n\r\n 2) If scsi_mode_sense() is called with len smaller than 8 with\n sdev-\u0026gt;use_10_for_ms set, or smaller than 4 otherwise, the buffer length\n is increased to 8 and 4 respectively, and the buffer is zero filled\n with these increased values, thus corrupting the memory following the\n buffer.\r\n\r\nFix these 2 problems by using put_unaligned_be16() to set the allocation\nlength field of MODE SENSE(10) CDB and by returning an error when len is\ntoo small.\r\n\r\nFurthermore, if len is larger than 255B, always try MODE SENSE(10) first,\neven if the device driver did not set sdev-\u0026gt;use_10_for_ms. In case of\ninvalid opcode error for MODE SENSE(10), access to mode pages larger than\n255 bytes are not retried using MODE SENSE(6). To avoid buffer length\noverflows for the MODE_SENSE(10) case, check that len is smaller than 65535\nbytes.\r\n\r\nWhile at it, also fix the folowing:\r\n\r\n * Use get_unaligned_be16() to retrieve the mode data length and block\n descriptor length fields of the mode sense reply header instead of using\n an open coded calculation.\r\n\r\n * Fix the kdoc dbd argument explanation: the DBD bit stands for Disable\n Block Descriptor, which is the opposite of what the dbd argument\n description was.(CVE-2021-47182)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\niavf: free q_vectors before queues in iavf_disable_vf\r\n\r\niavf_free_queues() clears adapter-\u0026gt;num_active_queues, which\niavf_free_q_vectors() relies on, so swap the order of these two function\ncalls in iavf_disable_vf(). This resolves a panic encountered when the\ninterface is disabled and then later brought up again after PF\ncommunication is restored.(CVE-2021-47201)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: lpfc: Fix list_add() corruption in lpfc_drain_txq()\r\n\r\nWhen parsing the txq list in lpfc_drain_txq(), the driver attempts to pass\nthe requests to the adapter. If such an attempt fails, a local \u0026quot;fail_msg\u0026quot;\nstring is set and a log message output. The job is then added to a\ncompletions list for cancellation.\r\n\r\nProcessing of any further jobs from the txq list continues, but since\n\u0026quot;fail_msg\u0026quot; remains set, jobs are added to the completions list regardless\nof whether a wqe was passed to the adapter. If successfully added to\ntxcmplq, jobs are added to both lists resulting in list corruption.\r\n\r\nFix by clearing the fail_msg string after adding a job to the completions\nlist. This stops the subsequent jobs from being added to the completions\nlist unless they had an appropriate failure.(CVE-2021-47203)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nALSA: usb-audio: fix null pointer dereference on pointer cs_desc\r\n\r\nThe pointer cs_desc return from snd_usb_find_clock_source could\nbe null, so there is a potential null pointer dereference issue.\nFix this by adding a null check before dereference.(CVE-2021-47211)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: advansys: Fix kernel pointer leak\r\n\r\nPointers should be printed with %p or %px rather than cast to \u0026apos;unsigned\nlong\u0026apos; and printed with %lx.\r\n\r\nChange %lx to %p to print the hashed pointer.(CVE-2021-47216)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nx86/hyperv: Fix NULL deref in set_hv_tscchange_cb() if Hyper-V setup fails\r\n\r\nCheck for a valid hv_vp_index array prior to derefencing hv_vp_index when\nsetting Hyper-V\u0026apos;s TSC change callback. If Hyper-V setup failed in\nhyperv_init(), the kernel will still report that it\u0026apos;s running under\nHyper-V, but will have silently disabled nearly all functionality.\r\n\r\n BUG: kernel NULL pointer dereference, address: 0000000000000010\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\n PGD 0 P4D 0\n Oops: 0000 [#1] SMP\n CPU: 4 PID: 1 Comm: swapper/0 Not tainted 5.15.0-rc2+ #75\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015\n RIP: 0010:set_hv_tscchange_cb+0x15/0xa0\n Code: \u0026lt;8b\u0026gt; 04 82 8b 15 12 17 85 01 48 c1 e0 20 48 0d ee 00 01 00 f6 c6 08\n ...\n Call Trace:\n kvm_arch_init+0x17c/0x280\n kvm_init+0x31/0x330\n vmx_init+0xba/0x13a\n do_one_initcall+0x41/0x1c0\n kernel_init_freeable+0x1f2/0x23b\n kernel_init+0x16/0x120\n ret_from_fork+0x22/0x30(CVE-2021-47217)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: hub: Guard against accesses to uninitialized BOS descriptors\r\n\r\nMany functions in drivers/usb/core/hub.c and drivers/usb/core/hub.h\naccess fields inside udev-\u0026gt;bos without checking if it was allocated and\ninitialized. If usb_get_bos_descriptor() fails for whatever\nreason, udev-\u0026gt;bos will be NULL and those accesses will result in a\ncrash:\r\n\r\nBUG: kernel NULL pointer dereference, address: 0000000000000018\nPGD 0 P4D 0\nOops: 0000 [#1] PREEMPT SMP NOPTI\nCPU: 5 PID: 17818 Comm: kworker/5:1 Tainted: G W 5.15.108-18910-gab0e1cb584e1 #1 \u0026lt;HASH:1f9e 1\u0026gt;\nHardware name: Google Kindred/Kindred, BIOS Google_Kindred.12672.413.0 02/03/2021\nWorkqueue: usb_hub_wq hub_event\nRIP: 0010:hub_port_reset+0x193/0x788\nCode: 89 f7 e8 20 f7 15 00 48 8b 43 08 80 b8 96 03 00 00 03 75 36 0f b7 88 92 03 00 00 81 f9 10 03 00 00 72 27 48 8b 80 a8 03 00 00 \u0026lt;48\u0026gt; 83 78 18 00 74 19 48 89 df 48 8b 75 b0 ba 02 00 00 00 4c 89 e9\nRSP: 0018:ffffab740c53fcf8 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: ffffa1bc5f678000 RCX: 0000000000000310\nRDX: fffffffffffffdff RSI: 0000000000000286 RDI: ffffa1be9655b840\nRBP: ffffab740c53fd70 R08: 00001b7d5edaa20c R09: ffffffffb005e060\nR10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000\nR13: ffffab740c53fd3e R14: 0000000000000032 R15: 0000000000000000\nFS: 0000000000000000(0000) GS:ffffa1be96540000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000018 CR3: 000000022e80c005 CR4: 00000000003706e0\nCall Trace:\nhub_event+0x73f/0x156e\n? hub_activate+0x5b7/0x68f\nprocess_one_work+0x1a2/0x487\nworker_thread+0x11a/0x288\nkthread+0x13a/0x152\n? process_one_work+0x487/0x487\n? kthread_associate_blkcg+0x70/0x70\nret_from_fork+0x1f/0x30\r\n\r\nFall back to a default behavior if the BOS descriptor isn\u0026apos;t accessible\nand skip all the functionalities that depend on it: LPM support checks,\nSuper Speed capabilitiy checks, U1/U2 states setup.(CVE-2023-52477)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbinder: fix race between mmput() and do_exit()\r\n\r\nTask A calls binder_update_page_range() to allocate and insert pages on\na remote address space from Task B. For this, Task A pins the remote mm\nvia mmget_not_zero() first. This can race with Task B do_exit() and the\nfinal mmput() refcount decrement will come from Task A.\r\n\r\n Task A | Task B\n ------------------+------------------\n mmget_not_zero() |\n | do_exit()\n | exit_mm()\n | mmput()\n mmput() |\n exit_mmap() |\n remove_vma() |\n fput() |\r\n\r\nIn this case, the work of ____fput() from Task B is queued up in Task A\nas TWA_RESUME. So in theory, Task A returns to userspace and the cleanup\nwork gets executed. However, Task A instead sleep, waiting for a reply\nfrom Task B that never comes (it\u0026apos;s dead).\r\n\r\nThis means the binder_deferred_release() is blocked until an unrelated\nbinder event forces Task A to go back to userspace. All the associated\ndeath notifications will also be delayed until then.\r\n\r\nIn order to fix this use mmput_async() that will schedule the work in\nthe corresponding mm-\u0026gt;async_put_work WQ instead of Task A.(CVE-2023-52609)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nllc: Drop support for ETH_P_TR_802_2.\r\n\r\nsyzbot reported an uninit-value bug below. [0]\r\n\r\nllc supports ETH_P_802_2 (0x0004) and used to support ETH_P_TR_802_2\n(0x0011), and syzbot abused the latter to trigger the bug.\r\n\r\n write$tun(r0, \u0026amp;(0x7f0000000040)={@val={0x0, 0x11}, @val, @mpls={[], @llc={@snap={0xaa, 0x1, \u0026apos;)\u0026apos;, \u0026quot;90e5dd\u0026quot;}}}}, 0x16)\r\n\r\nllc_conn_handler() initialises local variables {saddr,daddr}.mac\nbased on skb in llc_pdu_decode_sa()/llc_pdu_decode_da() and passes\nthem to __llc_lookup().\r\n\r\nHowever, the initialisation is done only when skb-\u0026gt;protocol is\nhtons(ETH_P_802_2), otherwise, __llc_lookup_established() and\n__llc_lookup_listener() will read garbage.\r\n\r\nThe missing initialisation existed prior to commit 211ed865108e\n(\u0026quot;net: delete all instances of special processing for token ring\u0026quot;).\r\n\r\nIt removed the part to kick out the token ring stuff but forgot to\nclose the door allowing ETH_P_TR_802_2 packets to sneak into llc_rcv().\r\n\r\nLet\u0026apos;s remove llc_tr_packet_type and complete the deprecation.\r\n\r\n[0]:\nBUG: KMSAN: uninit-value in __llc_lookup_established+0xe9d/0xf90\n __llc_lookup_established+0xe9d/0xf90\n __llc_lookup net/llc/llc_conn.c:611 [inline]\n llc_conn_handler+0x4bd/0x1360 net/llc/llc_conn.c:791\n llc_rcv+0xfbb/0x14a0 net/llc/llc_input.c:206\n __netif_receive_skb_one_core net/core/dev.c:5527 [inline]\n __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5641\n netif_receive_skb_internal net/core/dev.c:5727 [inline]\n netif_receive_skb+0x58/0x660 net/core/dev.c:5786\n tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555\n tun_get_user+0x53af/0x66d0 drivers/net/tun.c:2002\n tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048\n call_write_iter include/linux/fs.h:2020 [inline]\n new_sync_write fs/read_write.c:491 [inline]\n vfs_write+0x8ef/0x1490 fs/read_write.c:584\n ksys_write+0x20f/0x4c0 fs/read_write.c:637\n __do_sys_write fs/read_write.c:649 [inline]\n __se_sys_write fs/read_write.c:646 [inline]\n __x64_sys_write+0x93/0xd0 fs/read_write.c:646\n do_syscall_x64 arch/x86/entry/common.c:51 [inline]\n do_syscall_64+0x44/0x110 arch/x86/entry/common.c:82\n entry_SYSCALL_64_after_hwframe+0x63/0x6b\r\n\r\nLocal variable daddr created at:\n llc_conn_handler+0x53/0x1360 net/llc/llc_conn.c:783\n llc_rcv+0xfbb/0x14a0 net/llc/llc_input.c:206\r\n\r\nCPU: 1 PID: 5004 Comm: syz-executor994 Not tainted 6.6.0-syzkaller-14500-g1c41041124bd #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/09/2023(CVE-2024-26635)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nllc: make llc_ui_sendmsg() more robust against bonding changes\r\n\r\nsyzbot was able to trick llc_ui_sendmsg(), allocating an skb with no\nheadroom, but subsequently trying to push 14 bytes of Ethernet header [1]\r\n\r\nLike some others, llc_ui_sendmsg() releases the socket lock before\ncalling sock_alloc_send_skb().\nThen it acquires it again, but does not redo all the sanity checks\nthat were performed.\r\n\r\nThis fix:\r\n\r\n- Uses LL_RESERVED_SPACE() to reserve space.\n- Check all conditions again after socket lock is held again.\n- Do not account Ethernet header for mtu limitation.\r\n\r\n[1]\r\n\r\nskbuff: skb_under_panic: text:ffff800088baa334 len:1514 put:14 head:ffff0000c9c37000 data:ffff0000c9c36ff2 tail:0x5dc end:0x6c0 dev:bond0\r\n\r\n kernel BUG at net/core/skbuff.c:193 !\nInternal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP\nModules linked in:\nCPU: 0 PID: 6875 Comm: syz-executor.0 Not tainted 6.7.0-rc8-syzkaller-00101-g0802e17d9aca-dirty #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023\npstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : skb_panic net/core/skbuff.c:189 [inline]\n pc : skb_under_panic+0x13c/0x140 net/core/skbuff.c:203\n lr : skb_panic net/core/skbuff.c:189 [inline]\n lr : skb_under_panic+0x13c/0x140 net/core/skbuff.c:203\nsp : ffff800096f97000\nx29: ffff800096f97010 x28: ffff80008cc8d668 x27: dfff800000000000\nx26: ffff0000cb970c90 x25: 00000000000005dc x24: ffff0000c9c36ff2\nx23: ffff0000c9c37000 x22: 00000000000005ea x21: 00000000000006c0\nx20: 000000000000000e x19: ffff800088baa334 x18: 1fffe000368261ce\nx17: ffff80008e4ed000 x16: ffff80008a8310f8 x15: 0000000000000001\nx14: 1ffff00012df2d58 x13: 0000000000000000 x12: 0000000000000000\nx11: 0000000000000001 x10: 0000000000ff0100 x9 : e28a51f1087e8400\nx8 : e28a51f1087e8400 x7 : ffff80008028f8d0 x6 : 0000000000000000\nx5 : 0000000000000001 x4 : 0000000000000001 x3 : ffff800082b78714\nx2 : 0000000000000001 x1 : 0000000100000000 x0 : 0000000000000089\nCall trace:\n skb_panic net/core/skbuff.c:189 [inline]\n skb_under_panic+0x13c/0x140 net/core/skbuff.c:203\n skb_push+0xf0/0x108 net/core/skbuff.c:2451\n eth_header+0x44/0x1f8 net/ethernet/eth.c:83\n dev_hard_header include/linux/netdevice.h:3188 [inline]\n llc_mac_hdr_init+0x110/0x17c net/llc/llc_output.c:33\n llc_sap_action_send_xid_c+0x170/0x344 net/llc/llc_s_ac.c:85\n llc_exec_sap_trans_actions net/llc/llc_sap.c:153 [inline]\n llc_sap_next_state net/llc/llc_sap.c:182 [inline]\n llc_sap_state_process+0x1ec/0x774 net/llc/llc_sap.c:209\n llc_build_and_send_xid_pkt+0x12c/0x1c0 net/llc/llc_sap.c:270\n llc_ui_sendmsg+0x7bc/0xb1c net/llc/af_llc.c:997\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg net/socket.c:745 [inline]\n sock_sendmsg+0x194/0x274 net/socket.c:767\n splice_to_socket+0x7cc/0xd58 fs/splice.c:881\n do_splice_from fs/splice.c:933 [inline]\n direct_splice_actor+0xe4/0x1c0 fs/splice.c:1142\n splice_direct_to_actor+0x2a0/0x7e4 fs/splice.c:1088\n do_splice_direct+0x20c/0x348 fs/splice.c:1194\n do_sendfile+0x4bc/0xc70 fs/read_write.c:1254\n __do_sys_sendfile64 fs/read_write.c:1322 [inline]\n __se_sys_sendfile64 fs/read_write.c:1308 [inline]\n __arm64_sys_sendfile64+0x160/0x3b4 fs/read_write.c:1308\n __invoke_syscall arch/arm64/kernel/syscall.c:37 [inline]\n invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:51\n el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:136\n do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:155\n el0_svc+0x54/0x158 arch/arm64/kernel/entry-common.c:678\n el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:696\n el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:595\nCode: aa1803e6 aa1903e7 a90023f5 94792f6a (d4210000)(CVE-2024-26636)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntcp: add sanity checks to rx zerocopy\r\n\r\nTCP rx zerocopy intent is to map pages initially allocated\nfrom NIC drivers, not pages owned by a fs.\r\n\r\nThis patch adds to can_map_frag() these additional checks:\r\n\r\n- Page must not be a compound one.\n- page-\u0026gt;mapping must be NULL.\r\n\r\nThis fixes the panic reported by ZhangPeng.\r\n\r\nsyzbot was able to loopback packets built with sendfile(),\nmapping pages owned by an ext4 file to TCP rx zerocopy.\r\n\r\nr3 = socket$inet_tcp(0x2, 0x1, 0x0)\nmmap(\u0026amp;(0x7f0000ff9000/0x4000)=nil, 0x4000, 0x0, 0x12, r3, 0x0)\nr4 = socket$inet_tcp(0x2, 0x1, 0x0)\nbind$inet(r4, \u0026amp;(0x7f0000000000)={0x2, 0x4e24, @multicast1}, 0x10)\nconnect$inet(r4, \u0026amp;(0x7f00000006c0)={0x2, 0x4e24, @empty}, 0x10)\nr5 = openat$dir(0xffffffffffffff9c, \u0026amp;(0x7f00000000c0)=\u0026apos;./file0\\x00\u0026apos;,\n 0x181e42, 0x0)\nfallocate(r5, 0x0, 0x0, 0x85b8)\nsendfile(r4, r5, 0x0, 0x8ba0)\ngetsockopt$inet_tcp_TCP_ZEROCOPY_RECEIVE(r4, 0x6, 0x23,\n \u0026amp;(0x7f00000001c0)={\u0026amp;(0x7f0000ffb000/0x3000)=nil, 0x3000, 0x0, 0x0, 0x0,\n 0x0, 0x0, 0x0, 0x0}, \u0026amp;(0x7f0000000440)=0x40)\nr6 = openat$dir(0xffffffffffffff9c, \u0026amp;(0x7f00000000c0)=\u0026apos;./file0\\x00\u0026apos;,\n 0x181e42, 0x0)(CVE-2024-26640)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv()\r\n\r\nsyzbot found __ip6_tnl_rcv() could access unitiliazed data [1].\r\n\r\nCall pskb_inet_may_pull() to fix this, and initialize ipv6h\nvariable after this call as it can change skb-\u0026gt;head.\r\n\r\n[1]\n BUG: KMSAN: uninit-value in __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline]\n BUG: KMSAN: uninit-value in INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline]\n BUG: KMSAN: uninit-value in IP6_ECN_decapsulate+0x7df/0x1e50 include/net/inet_ecn.h:321\n __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline]\n INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline]\n IP6_ECN_decapsulate+0x7df/0x1e50 include/net/inet_ecn.h:321\n ip6ip6_dscp_ecn_decapsulate+0x178/0x1b0 net/ipv6/ip6_tunnel.c:727\n __ip6_tnl_rcv+0xd4e/0x1590 net/ipv6/ip6_tunnel.c:845\n ip6_tnl_rcv+0xce/0x100 net/ipv6/ip6_tunnel.c:888\n gre_rcv+0x143f/0x1870\n ip6_protocol_deliver_rcu+0xda6/0x2a60 net/ipv6/ip6_input.c:438\n ip6_input_finish net/ipv6/ip6_input.c:483 [inline]\n NF_HOOK include/linux/netfilter.h:314 [inline]\n ip6_input+0x15d/0x430 net/ipv6/ip6_input.c:492\n ip6_mc_input+0xa7e/0xc80 net/ipv6/ip6_input.c:586\n dst_input include/net/dst.h:461 [inline]\n ip6_rcv_finish+0x5db/0x870 net/ipv6/ip6_input.c:79\n NF_HOOK include/linux/netfilter.h:314 [inline]\n ipv6_rcv+0xda/0x390 net/ipv6/ip6_input.c:310\n __netif_receive_skb_one_core net/core/dev.c:5532 [inline]\n __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5646\n netif_receive_skb_internal net/core/dev.c:5732 [inline]\n netif_receive_skb+0x58/0x660 net/core/dev.c:5791\n tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555\n tun_get_user+0x53af/0x66d0 drivers/net/tun.c:2002\n tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048\n call_write_iter include/linux/fs.h:2084 [inline]\n new_sync_write fs/read_write.c:497 [inline]\n vfs_write+0x786/0x1200 fs/read_write.c:590\n ksys_write+0x20f/0x4c0 fs/read_write.c:643\n __do_sys_write fs/read_write.c:655 [inline]\n __se_sys_write fs/read_write.c:652 [inline]\n __x64_sys_write+0x93/0xd0 fs/read_write.c:652\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0x6d/0x140 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+0x129/0xa70 mm/slab.h:768\n slab_alloc_node mm/slub.c:3478 [inline]\n kmem_cache_alloc_node+0x5e9/0xb10 mm/slub.c:3523\n kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560\n __alloc_skb+0x318/0x740 net/core/skbuff.c:651\n alloc_skb include/linux/skbuff.h:1286 [inline]\n alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6334\n sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2787\n tun_alloc_skb drivers/net/tun.c:1531 [inline]\n tun_get_user+0x1e8a/0x66d0 drivers/net/tun.c:1846\n tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048\n call_write_iter include/linux/fs.h:2084 [inline]\n new_sync_write fs/read_write.c:497 [inline]\n vfs_write+0x786/0x1200 fs/read_write.c:590\n ksys_write+0x20f/0x4c0 fs/read_write.c:643\n __do_sys_write fs/read_write.c:655 [inline]\n __se_sys_write fs/read_write.c:652 [inline]\n __x64_sys_write+0x93/0xd0 fs/read_write.c:652\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x63/0x6b\r\n\r\nCPU: 0 PID: 5034 Comm: syz-executor331 Not tainted 6.7.0-syzkaller-00562-g9f8413c4a66f #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023(CVE-2024-26641)",
"id": "OESA-2024-1568",
"modified": "2026-08-06T11:07:01Z",
"published": "2024-05-11T11:07:01Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1568"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47182"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47201"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47203"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47211"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47216"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47217"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52477"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52609"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26635"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26636"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26640"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26641"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2021-47182",
"CVE-2021-47201",
"CVE-2021-47203",
"CVE-2021-47211",
"CVE-2021-47216",
"CVE-2021-47217",
"CVE-2023-52477",
"CVE-2023-52609",
"CVE-2024-26635",
"CVE-2024-26636",
"CVE-2024-26640",
"CVE-2024-26641"
]
}
OESA-2024-1569 (CVE-2021-47082)
Vulnerability from osv_openeuler – Published: 2024-05-11 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:
tun: avoid double free in tun_free_netdev
Avoid double free in tun_free_netdev() by moving the dev->tstats and tun->security allocs to a new ndo_init routine (tun_net_init()) that will be called by register_netdevice(). ndo_init is paired with the desctructor (tun_free_netdev()), so if there's an error in register_netdevice() the destructor will handle the frees.
BUG: KASAN: double-free or invalid-free in selinux_tun_dev_free_security+0x1a/0x20 security/selinux/hooks.c:5605
CPU: 0 PID: 25750 Comm: syz-executor416 Not tainted 5.16.0-rc2-syzk #1 Hardware name: Red Hat KVM, BIOS Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x89/0xb5 lib/dump_stack.c:106 print_address_description.constprop.9+0x28/0x160 mm/kasan/report.c:247 kasan_report_invalid_free+0x55/0x80 mm/kasan/report.c:372 _kasanslab_free mm/kasan/common.c:346 [inline] kasan_slab_free+0x107/0x120 mm/kasan/common.c:374 kasan_slab_free include/linux/kasan.h:235 [inline] slab_free_hook mm/slub.c:1723 [inline] slab_free_freelist_hook mm/slub.c:1749 [inline] slab_free mm/slub.c:3513 [inline] kfree+0xac/0x2d0 mm/slub.c:4561 selinux_tun_dev_free_security+0x1a/0x20 security/selinux/hooks.c:5605 security_tun_dev_free_security+0x4f/0x90 security/security.c:2342 tun_free_netdev+0xe6/0x150 drivers/net/tun.c:2215 netdev_run_todo+0x4df/0x840 net/core/dev.c:10627 rtnl_unlock+0x13/0x20 net/core/rtnetlink.c:112 __tun_chr_ioctl+0x80c/0x2870 drivers/net/tun.c:3302 tun_chr_ioctl+0x2f/0x40 drivers/net/tun.c:3311 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:874 [inline] __se_sys_ioctl fs/ioctl.c:860 [inline] __x64_sys_ioctl+0x19d/0x220 fs/ioctl.c:860 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3a/0x80 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae(CVE-2021-47082)
In the Linux kernel, the following vulnerability has been resolved:
scsi: core: Fix scsi_mode_sense() buffer length handling
Several problems exist with scsi_mode_sense() buffer length handling:
1) The allocation length field of the MODE SENSE(10) command is 16-bits, occupying bytes 7 and 8 of the CDB. With this command, access to mode pages larger than 255 bytes is thus possible. However, the CDB allocation length field is set by assigning len to byte 8 only, thus truncating buffer length larger than 255.
2) If scsi_mode_sense() is called with len smaller than 8 with sdev->use_10_for_ms set, or smaller than 4 otherwise, the buffer length is increased to 8 and 4 respectively, and the buffer is zero filled with these increased values, thus corrupting the memory following the buffer.
Fix these 2 problems by using put_unaligned_be16() to set the allocation length field of MODE SENSE(10) CDB and by returning an error when len is too small.
Furthermore, if len is larger than 255B, always try MODE SENSE(10) first, even if the device driver did not set sdev->use_10_for_ms. In case of invalid opcode error for MODE SENSE(10), access to mode pages larger than 255 bytes are not retried using MODE SENSE(6). To avoid buffer length overflows for the MODE_SENSE(10) case, check that len is smaller than 65535 bytes.
While at it, also fix the folowing:
-
Use get_unaligned_be16() to retrieve the mode data length and block descriptor length fields of the mode sense reply header instead of using an open coded calculation.
-
Fix the kdoc dbd argument explanation: the DBD bit stands for Disable Block Descriptor, which is the opposite of what the dbd argument description was.(CVE-2021-47182)
In the Linux kernel, the following vulnerability has been resolved:
ALSA: usb-audio: fix null pointer dereference on pointer cs_desc
The pointer cs_desc return from snd_usb_find_clock_source could be null, so there is a potential null pointer dereference issue. Fix this by adding a null check before dereference.(CVE-2021-47211)
In the Linux kernel, the following vulnerability has been resolved:
usb: hub: Guard against accesses to uninitialized BOS descriptors
Many functions in drivers/usb/core/hub.c and drivers/usb/core/hub.h access fields inside udev->bos without checking if it was allocated and initialized. If usb_get_bos_descriptor() fails for whatever reason, udev->bos will be NULL and those accesses will result in a crash:
BUG: kernel NULL pointer dereference, address: 0000000000000018 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 5 PID: 17818 Comm: kworker/5:1 Tainted: G W 5.15.108-18910-gab0e1cb584e1 #1 <HASH:1f9e 1> Hardware name: Google Kindred/Kindred, BIOS Google_Kindred.12672.413.0 02/03/2021 Workqueue: usb_hub_wq hub_event RIP: 0010:hub_port_reset+0x193/0x788 Code: 89 f7 e8 20 f7 15 00 48 8b 43 08 80 b8 96 03 00 00 03 75 36 0f b7 88 92 03 00 00 81 f9 10 03 00 00 72 27 48 8b 80 a8 03 00 00 <48> 83 78 18 00 74 19 48 89 df 48 8b 75 b0 ba 02 00 00 00 4c 89 e9 RSP: 0018:ffffab740c53fcf8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffffa1bc5f678000 RCX: 0000000000000310 RDX: fffffffffffffdff RSI: 0000000000000286 RDI: ffffa1be9655b840 RBP: ffffab740c53fd70 R08: 00001b7d5edaa20c R09: ffffffffb005e060 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000 R13: ffffab740c53fd3e R14: 0000000000000032 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffffa1be96540000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000018 CR3: 000000022e80c005 CR4: 00000000003706e0 Call Trace: hub_event+0x73f/0x156e ? hub_activate+0x5b7/0x68f process_one_work+0x1a2/0x487 worker_thread+0x11a/0x288 kthread+0x13a/0x152 ? process_one_work+0x487/0x487 ? kthread_associate_blkcg+0x70/0x70 ret_from_fork+0x1f/0x30
Fall back to a default behavior if the BOS descriptor isn't accessible and skip all the functionalities that depend on it: LPM support checks, Super Speed capabilitiy checks, U1/U2 states setup.(CVE-2023-52477)
In the Linux kernel, the following vulnerability has been resolved:
l2tp: pass correct message length to ip6_append_data
l2tp_ip6_sendmsg needs to avoid accounting for the transport header twice when splicing more data into an already partially-occupied skbuff.
To manage this, we check whether the skbuff contains data using skb_queue_empty when deciding how much data to append using ip6_append_data.
However, the code which performed the calculation was incorrect:
ulen = len + skb_queue_empty(&sk->sk_write_queue) ? transhdrlen : 0;
...due to C operator precedence, this ends up setting ulen to transhdrlen for messages with a non-zero length, which results in corrupted packets on the wire.
Add parentheses to correct the calculation in line with the original intent.(CVE-2024-26752)
| URL | Type | |||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"kernel-tools-devel-5.10.0-60.136.0.163.oe2203.aarch64.rpm",
"kernel-debugsource-5.10.0-60.136.0.163.oe2203.aarch64.rpm",
"kernel-devel-5.10.0-60.136.0.163.oe2203.aarch64.rpm",
"bpftool-5.10.0-60.136.0.163.oe2203.aarch64.rpm",
"kernel-debuginfo-5.10.0-60.136.0.163.oe2203.aarch64.rpm",
"kernel-source-5.10.0-60.136.0.163.oe2203.aarch64.rpm",
"kernel-tools-5.10.0-60.136.0.163.oe2203.aarch64.rpm",
"kernel-headers-5.10.0-60.136.0.163.oe2203.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-60.136.0.163.oe2203.aarch64.rpm",
"kernel-5.10.0-60.136.0.163.oe2203.aarch64.rpm",
"kernel-tools-debuginfo-5.10.0-60.136.0.163.oe2203.aarch64.rpm",
"bpftool-debuginfo-5.10.0-60.136.0.163.oe2203.aarch64.rpm",
"python3-perf-5.10.0-60.136.0.163.oe2203.aarch64.rpm",
"perf-5.10.0-60.136.0.163.oe2203.aarch64.rpm",
"perf-debuginfo-5.10.0-60.136.0.163.oe2203.aarch64.rpm"
],
"src": [
"kernel-5.10.0-60.136.0.163.oe2203.src.rpm"
],
"x86_64": [
"kernel-headers-5.10.0-60.136.0.163.oe2203.x86_64.rpm",
"kernel-tools-debuginfo-5.10.0-60.136.0.163.oe2203.x86_64.rpm",
"kernel-devel-5.10.0-60.136.0.163.oe2203.x86_64.rpm",
"kernel-tools-5.10.0-60.136.0.163.oe2203.x86_64.rpm",
"bpftool-debuginfo-5.10.0-60.136.0.163.oe2203.x86_64.rpm",
"perf-debuginfo-5.10.0-60.136.0.163.oe2203.x86_64.rpm",
"kernel-tools-devel-5.10.0-60.136.0.163.oe2203.x86_64.rpm",
"kernel-debugsource-5.10.0-60.136.0.163.oe2203.x86_64.rpm",
"kernel-source-5.10.0-60.136.0.163.oe2203.x86_64.rpm",
"kernel-debuginfo-5.10.0-60.136.0.163.oe2203.x86_64.rpm",
"python3-perf-debuginfo-5.10.0-60.136.0.163.oe2203.x86_64.rpm",
"python3-perf-5.10.0-60.136.0.163.oe2203.x86_64.rpm",
"kernel-5.10.0-60.136.0.163.oe2203.x86_64.rpm",
"bpftool-5.10.0-60.136.0.163.oe2203.x86_64.rpm",
"perf-5.10.0-60.136.0.163.oe2203.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:22.03-LTS",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.10.0-60.136.0.163.oe2203"
}
],
"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\ntun: avoid double free in tun_free_netdev\r\n\r\nAvoid double free in tun_free_netdev() by moving the\ndev-\u0026gt;tstats and tun-\u0026gt;security allocs to a new ndo_init routine\n(tun_net_init()) that will be called by register_netdevice().\nndo_init is paired with the desctructor (tun_free_netdev()),\nso if there\u0026apos;s an error in register_netdevice() the destructor\nwill handle the frees.\r\n\r\nBUG: KASAN: double-free or invalid-free in selinux_tun_dev_free_security+0x1a/0x20 security/selinux/hooks.c:5605\r\n\r\nCPU: 0 PID: 25750 Comm: syz-executor416 Not tainted 5.16.0-rc2-syzk #1\nHardware name: Red Hat KVM, BIOS\nCall Trace:\n\u0026lt;TASK\u0026gt;\n__dump_stack lib/dump_stack.c:88 [inline]\ndump_stack_lvl+0x89/0xb5 lib/dump_stack.c:106\nprint_address_description.constprop.9+0x28/0x160 mm/kasan/report.c:247\nkasan_report_invalid_free+0x55/0x80 mm/kasan/report.c:372\n____kasan_slab_free mm/kasan/common.c:346 [inline]\n__kasan_slab_free+0x107/0x120 mm/kasan/common.c:374\nkasan_slab_free include/linux/kasan.h:235 [inline]\nslab_free_hook mm/slub.c:1723 [inline]\nslab_free_freelist_hook mm/slub.c:1749 [inline]\nslab_free mm/slub.c:3513 [inline]\nkfree+0xac/0x2d0 mm/slub.c:4561\nselinux_tun_dev_free_security+0x1a/0x20 security/selinux/hooks.c:5605\nsecurity_tun_dev_free_security+0x4f/0x90 security/security.c:2342\ntun_free_netdev+0xe6/0x150 drivers/net/tun.c:2215\nnetdev_run_todo+0x4df/0x840 net/core/dev.c:10627\nrtnl_unlock+0x13/0x20 net/core/rtnetlink.c:112\n__tun_chr_ioctl+0x80c/0x2870 drivers/net/tun.c:3302\ntun_chr_ioctl+0x2f/0x40 drivers/net/tun.c:3311\nvfs_ioctl fs/ioctl.c:51 [inline]\n__do_sys_ioctl fs/ioctl.c:874 [inline]\n__se_sys_ioctl fs/ioctl.c:860 [inline]\n__x64_sys_ioctl+0x19d/0x220 fs/ioctl.c:860\ndo_syscall_x64 arch/x86/entry/common.c:50 [inline]\ndo_syscall_64+0x3a/0x80 arch/x86/entry/common.c:80\nentry_SYSCALL_64_after_hwframe+0x44/0xae(CVE-2021-47082)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: core: Fix scsi_mode_sense() buffer length handling\r\n\r\nSeveral problems exist with scsi_mode_sense() buffer length handling:\r\n\r\n 1) The allocation length field of the MODE SENSE(10) command is 16-bits,\n occupying bytes 7 and 8 of the CDB. With this command, access to mode\n pages larger than 255 bytes is thus possible. However, the CDB\n allocation length field is set by assigning len to byte 8 only, thus\n truncating buffer length larger than 255.\r\n\r\n 2) If scsi_mode_sense() is called with len smaller than 8 with\n sdev-\u0026gt;use_10_for_ms set, or smaller than 4 otherwise, the buffer length\n is increased to 8 and 4 respectively, and the buffer is zero filled\n with these increased values, thus corrupting the memory following the\n buffer.\r\n\r\nFix these 2 problems by using put_unaligned_be16() to set the allocation\nlength field of MODE SENSE(10) CDB and by returning an error when len is\ntoo small.\r\n\r\nFurthermore, if len is larger than 255B, always try MODE SENSE(10) first,\neven if the device driver did not set sdev-\u0026gt;use_10_for_ms. In case of\ninvalid opcode error for MODE SENSE(10), access to mode pages larger than\n255 bytes are not retried using MODE SENSE(6). To avoid buffer length\noverflows for the MODE_SENSE(10) case, check that len is smaller than 65535\nbytes.\r\n\r\nWhile at it, also fix the folowing:\r\n\r\n * Use get_unaligned_be16() to retrieve the mode data length and block\n descriptor length fields of the mode sense reply header instead of using\n an open coded calculation.\r\n\r\n * Fix the kdoc dbd argument explanation: the DBD bit stands for Disable\n Block Descriptor, which is the opposite of what the dbd argument\n description was.(CVE-2021-47182)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nALSA: usb-audio: fix null pointer dereference on pointer cs_desc\r\n\r\nThe pointer cs_desc return from snd_usb_find_clock_source could\nbe null, so there is a potential null pointer dereference issue.\nFix this by adding a null check before dereference.(CVE-2021-47211)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: hub: Guard against accesses to uninitialized BOS descriptors\r\n\r\nMany functions in drivers/usb/core/hub.c and drivers/usb/core/hub.h\naccess fields inside udev-\u0026gt;bos without checking if it was allocated and\ninitialized. If usb_get_bos_descriptor() fails for whatever\nreason, udev-\u0026gt;bos will be NULL and those accesses will result in a\ncrash:\r\n\r\nBUG: kernel NULL pointer dereference, address: 0000000000000018\nPGD 0 P4D 0\nOops: 0000 [#1] PREEMPT SMP NOPTI\nCPU: 5 PID: 17818 Comm: kworker/5:1 Tainted: G W 5.15.108-18910-gab0e1cb584e1 #1 \u0026lt;HASH:1f9e 1\u0026gt;\nHardware name: Google Kindred/Kindred, BIOS Google_Kindred.12672.413.0 02/03/2021\nWorkqueue: usb_hub_wq hub_event\nRIP: 0010:hub_port_reset+0x193/0x788\nCode: 89 f7 e8 20 f7 15 00 48 8b 43 08 80 b8 96 03 00 00 03 75 36 0f b7 88 92 03 00 00 81 f9 10 03 00 00 72 27 48 8b 80 a8 03 00 00 \u0026lt;48\u0026gt; 83 78 18 00 74 19 48 89 df 48 8b 75 b0 ba 02 00 00 00 4c 89 e9\nRSP: 0018:ffffab740c53fcf8 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: ffffa1bc5f678000 RCX: 0000000000000310\nRDX: fffffffffffffdff RSI: 0000000000000286 RDI: ffffa1be9655b840\nRBP: ffffab740c53fd70 R08: 00001b7d5edaa20c R09: ffffffffb005e060\nR10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000\nR13: ffffab740c53fd3e R14: 0000000000000032 R15: 0000000000000000\nFS: 0000000000000000(0000) GS:ffffa1be96540000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000018 CR3: 000000022e80c005 CR4: 00000000003706e0\nCall Trace:\nhub_event+0x73f/0x156e\n? hub_activate+0x5b7/0x68f\nprocess_one_work+0x1a2/0x487\nworker_thread+0x11a/0x288\nkthread+0x13a/0x152\n? process_one_work+0x487/0x487\n? kthread_associate_blkcg+0x70/0x70\nret_from_fork+0x1f/0x30\r\n\r\nFall back to a default behavior if the BOS descriptor isn\u0026apos;t accessible\nand skip all the functionalities that depend on it: LPM support checks,\nSuper Speed capabilitiy checks, U1/U2 states setup.(CVE-2023-52477)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nl2tp: pass correct message length to ip6_append_data\r\n\r\nl2tp_ip6_sendmsg needs to avoid accounting for the transport header\ntwice when splicing more data into an already partially-occupied skbuff.\r\n\r\nTo manage this, we check whether the skbuff contains data using\nskb_queue_empty when deciding how much data to append using\nip6_append_data.\r\n\r\nHowever, the code which performed the calculation was incorrect:\r\n\r\n ulen = len + skb_queue_empty(\u0026amp;sk-\u0026gt;sk_write_queue) ? transhdrlen : 0;\r\n\r\n...due to C operator precedence, this ends up setting ulen to\ntranshdrlen for messages with a non-zero length, which results in\ncorrupted packets on the wire.\r\n\r\nAdd parentheses to correct the calculation in line with the original\nintent.(CVE-2024-26752)",
"id": "OESA-2024-1569",
"modified": "2026-08-06T11:07:01Z",
"published": "2024-05-11T11:07:01Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1569"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47082"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47182"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47211"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52477"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26752"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2021-47082",
"CVE-2021-47182",
"CVE-2021-47211",
"CVE-2023-52477",
"CVE-2024-26752"
]
}
OESA-2024-1570 (CVE-2021-47182)
Vulnerability from osv_openeuler – Published: 2024-05-11 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:
scsi: core: Fix scsi_mode_sense() buffer length handling
Several problems exist with scsi_mode_sense() buffer length handling:
1) The allocation length field of the MODE SENSE(10) command is 16-bits, occupying bytes 7 and 8 of the CDB. With this command, access to mode pages larger than 255 bytes is thus possible. However, the CDB allocation length field is set by assigning len to byte 8 only, thus truncating buffer length larger than 255.
2) If scsi_mode_sense() is called with len smaller than 8 with sdev->use_10_for_ms set, or smaller than 4 otherwise, the buffer length is increased to 8 and 4 respectively, and the buffer is zero filled with these increased values, thus corrupting the memory following the buffer.
Fix these 2 problems by using put_unaligned_be16() to set the allocation length field of MODE SENSE(10) CDB and by returning an error when len is too small.
Furthermore, if len is larger than 255B, always try MODE SENSE(10) first, even if the device driver did not set sdev->use_10_for_ms. In case of invalid opcode error for MODE SENSE(10), access to mode pages larger than 255 bytes are not retried using MODE SENSE(6). To avoid buffer length overflows for the MODE_SENSE(10) case, check that len is smaller than 65535 bytes.
While at it, also fix the folowing:
-
Use get_unaligned_be16() to retrieve the mode data length and block descriptor length fields of the mode sense reply header instead of using an open coded calculation.
-
Fix the kdoc dbd argument explanation: the DBD bit stands for Disable Block Descriptor, which is the opposite of what the dbd argument description was.(CVE-2021-47182)
In the Linux kernel, the following vulnerability has been resolved:
ALSA: usb-audio: fix null pointer dereference on pointer cs_desc
The pointer cs_desc return from snd_usb_find_clock_source could be null, so there is a potential null pointer dereference issue. Fix this by adding a null check before dereference.(CVE-2021-47211)
In the Linux kernel, the following vulnerability has been resolved:
l2tp: pass correct message length to ip6_append_data
l2tp_ip6_sendmsg needs to avoid accounting for the transport header twice when splicing more data into an already partially-occupied skbuff.
To manage this, we check whether the skbuff contains data using skb_queue_empty when deciding how much data to append using ip6_append_data.
However, the code which performed the calculation was incorrect:
ulen = len + skb_queue_empty(&sk->sk_write_queue) ? transhdrlen : 0;
...due to C operator precedence, this ends up setting ulen to transhdrlen for messages with a non-zero length, which results in corrupted packets on the wire.
Add parentheses to correct the calculation in line with the original intent.(CVE-2024-26752)
| URL | Type | |
|---|---|---|
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"perf-5.10.0-136.74.0.154.oe2203sp1.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-136.74.0.154.oe2203sp1.aarch64.rpm",
"kernel-debuginfo-5.10.0-136.74.0.154.oe2203sp1.aarch64.rpm",
"kernel-tools-5.10.0-136.74.0.154.oe2203sp1.aarch64.rpm",
"perf-debuginfo-5.10.0-136.74.0.154.oe2203sp1.aarch64.rpm",
"kernel-5.10.0-136.74.0.154.oe2203sp1.aarch64.rpm",
"kernel-source-5.10.0-136.74.0.154.oe2203sp1.aarch64.rpm",
"kernel-devel-5.10.0-136.74.0.154.oe2203sp1.aarch64.rpm",
"kernel-headers-5.10.0-136.74.0.154.oe2203sp1.aarch64.rpm",
"kernel-debugsource-5.10.0-136.74.0.154.oe2203sp1.aarch64.rpm",
"python3-perf-5.10.0-136.74.0.154.oe2203sp1.aarch64.rpm",
"kernel-tools-devel-5.10.0-136.74.0.154.oe2203sp1.aarch64.rpm",
"kernel-tools-debuginfo-5.10.0-136.74.0.154.oe2203sp1.aarch64.rpm"
],
"src": [
"kernel-5.10.0-136.74.0.154.oe2203sp1.src.rpm"
],
"x86_64": [
"kernel-debugsource-5.10.0-136.74.0.154.oe2203sp1.x86_64.rpm",
"kernel-tools-devel-5.10.0-136.74.0.154.oe2203sp1.x86_64.rpm",
"python3-perf-debuginfo-5.10.0-136.74.0.154.oe2203sp1.x86_64.rpm",
"perf-5.10.0-136.74.0.154.oe2203sp1.x86_64.rpm",
"kernel-devel-5.10.0-136.74.0.154.oe2203sp1.x86_64.rpm",
"perf-debuginfo-5.10.0-136.74.0.154.oe2203sp1.x86_64.rpm",
"kernel-tools-5.10.0-136.74.0.154.oe2203sp1.x86_64.rpm",
"kernel-5.10.0-136.74.0.154.oe2203sp1.x86_64.rpm",
"kernel-source-5.10.0-136.74.0.154.oe2203sp1.x86_64.rpm",
"python3-perf-5.10.0-136.74.0.154.oe2203sp1.x86_64.rpm",
"kernel-debuginfo-5.10.0-136.74.0.154.oe2203sp1.x86_64.rpm",
"kernel-headers-5.10.0-136.74.0.154.oe2203sp1.x86_64.rpm",
"kernel-tools-debuginfo-5.10.0-136.74.0.154.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.74.0.154.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\nscsi: core: Fix scsi_mode_sense() buffer length handling\r\n\r\nSeveral problems exist with scsi_mode_sense() buffer length handling:\r\n\r\n 1) The allocation length field of the MODE SENSE(10) command is 16-bits,\n occupying bytes 7 and 8 of the CDB. With this command, access to mode\n pages larger than 255 bytes is thus possible. However, the CDB\n allocation length field is set by assigning len to byte 8 only, thus\n truncating buffer length larger than 255.\r\n\r\n 2) If scsi_mode_sense() is called with len smaller than 8 with\n sdev-\u0026gt;use_10_for_ms set, or smaller than 4 otherwise, the buffer length\n is increased to 8 and 4 respectively, and the buffer is zero filled\n with these increased values, thus corrupting the memory following the\n buffer.\r\n\r\nFix these 2 problems by using put_unaligned_be16() to set the allocation\nlength field of MODE SENSE(10) CDB and by returning an error when len is\ntoo small.\r\n\r\nFurthermore, if len is larger than 255B, always try MODE SENSE(10) first,\neven if the device driver did not set sdev-\u0026gt;use_10_for_ms. In case of\ninvalid opcode error for MODE SENSE(10), access to mode pages larger than\n255 bytes are not retried using MODE SENSE(6). To avoid buffer length\noverflows for the MODE_SENSE(10) case, check that len is smaller than 65535\nbytes.\r\n\r\nWhile at it, also fix the folowing:\r\n\r\n * Use get_unaligned_be16() to retrieve the mode data length and block\n descriptor length fields of the mode sense reply header instead of using\n an open coded calculation.\r\n\r\n * Fix the kdoc dbd argument explanation: the DBD bit stands for Disable\n Block Descriptor, which is the opposite of what the dbd argument\n description was.(CVE-2021-47182)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nALSA: usb-audio: fix null pointer dereference on pointer cs_desc\r\n\r\nThe pointer cs_desc return from snd_usb_find_clock_source could\nbe null, so there is a potential null pointer dereference issue.\nFix this by adding a null check before dereference.(CVE-2021-47211)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nl2tp: pass correct message length to ip6_append_data\r\n\r\nl2tp_ip6_sendmsg needs to avoid accounting for the transport header\ntwice when splicing more data into an already partially-occupied skbuff.\r\n\r\nTo manage this, we check whether the skbuff contains data using\nskb_queue_empty when deciding how much data to append using\nip6_append_data.\r\n\r\nHowever, the code which performed the calculation was incorrect:\r\n\r\n ulen = len + skb_queue_empty(\u0026amp;sk-\u0026gt;sk_write_queue) ? transhdrlen : 0;\r\n\r\n...due to C operator precedence, this ends up setting ulen to\ntranshdrlen for messages with a non-zero length, which results in\ncorrupted packets on the wire.\r\n\r\nAdd parentheses to correct the calculation in line with the original\nintent.(CVE-2024-26752)",
"id": "OESA-2024-1570",
"modified": "2026-08-06T11:07:01Z",
"published": "2024-05-11T11:07:01Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1570"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47182"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47211"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26752"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2021-47182",
"CVE-2021-47211",
"CVE-2024-26752"
]
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.