Action not permitted
Modal body text goes here.
Modal Title
Modal Body
CVE-2024-35947 (GCVE-0-2024-35947)
Vulnerability from cvelistv5 – Published: 2024-05-19 11:14 – Updated: 2026-05-11 20:14| Vendor | Product | Version | CPE status | |
|---|---|---|---|---|
| Linux | Linux |
Affected:
9898abb3d23311fa227a7f46bf4e40fd2954057f , < 3c718bddddca9cbef177ac475b94c5c91147fb38
(git)
Affected: 9898abb3d23311fa227a7f46bf4e40fd2954057f , < 343081c21e56bd6690d342e2f5ae8c00183bf081 (git) Affected: 9898abb3d23311fa227a7f46bf4e40fd2954057f , < 41d8ac238ab1cab01a8c71798d61903304f4e79b (git) Affected: 9898abb3d23311fa227a7f46bf4e40fd2954057f , < ba3c118cff7bcb0fe6aa84ae1f9080d50e31c561 (git) Affected: 9898abb3d23311fa227a7f46bf4e40fd2954057f , < a66c869b17c4c4dcf81d273b02cb0efe88e127ab (git) Affected: 9898abb3d23311fa227a7f46bf4e40fd2954057f , < a69e1bdd777ce51061111dc419801e8a2fd241cc (git) Affected: 9898abb3d23311fa227a7f46bf4e40fd2954057f , < 529e1852785599160415e964ca322ee7add7aef0 (git) Affected: 9898abb3d23311fa227a7f46bf4e40fd2954057f , < 00e7d3bea2ce7dac7bee1cf501fb071fd0ea8f6c (git) |
guessed | |
| Linux | Linux |
Affected:
2.6.30
Unaffected: 0 , < 2.6.30 (semver) Unaffected: 4.19.314 , ≤ 4.19.* (semver) Unaffected: 5.4.276 , ≤ 5.4.* (semver) Unaffected: 5.10.217 , ≤ 5.10.* (semver) Unaffected: 5.15.159 , ≤ 5.15.* (semver) Unaffected: 6.1.91 , ≤ 6.1.* (semver) Unaffected: 6.6.31 , ≤ 6.6.* (semver) Unaffected: 6.8.10 , ≤ 6.8.* (semver) Unaffected: 6.9 , ≤ * (original_commit_for_fix) |
guessed |
{
"containers": {
"adp": [
{
"metrics": [
{
"cvssV3_1": {
"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"
}
},
{
"other": {
"content": {
"id": "CVE-2024-35947",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2025-01-16T21:11:33.420262Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"description": "CWE-noinfo Not enough information",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2025-01-16T21:12:02.447Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
},
{
"providerMetadata": {
"dateUpdated": "2024-08-02T03:21:48.979Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/3c718bddddca9cbef177ac475b94c5c91147fb38"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/343081c21e56bd6690d342e2f5ae8c00183bf081"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/41d8ac238ab1cab01a8c71798d61903304f4e79b"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/ba3c118cff7bcb0fe6aa84ae1f9080d50e31c561"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/a66c869b17c4c4dcf81d273b02cb0efe88e127ab"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/a69e1bdd777ce51061111dc419801e8a2fd241cc"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/529e1852785599160415e964ca322ee7add7aef0"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/00e7d3bea2ce7dac7bee1cf501fb071fd0ea8f6c"
},
{
"tags": [
"x_transferred"
],
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/OTB4HWU2PTVW5NEYHHLOCXDKG3PYA534/"
},
{
"tags": [
"x_transferred"
],
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"
},
{
"tags": [
"x_transferred"
],
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html"
}
],
"title": "CVE Program Container"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"lib/dynamic_debug.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "3c718bddddca9cbef177ac475b94c5c91147fb38",
"status": "affected",
"version": "9898abb3d23311fa227a7f46bf4e40fd2954057f",
"versionType": "git"
},
{
"lessThan": "343081c21e56bd6690d342e2f5ae8c00183bf081",
"status": "affected",
"version": "9898abb3d23311fa227a7f46bf4e40fd2954057f",
"versionType": "git"
},
{
"lessThan": "41d8ac238ab1cab01a8c71798d61903304f4e79b",
"status": "affected",
"version": "9898abb3d23311fa227a7f46bf4e40fd2954057f",
"versionType": "git"
},
{
"lessThan": "ba3c118cff7bcb0fe6aa84ae1f9080d50e31c561",
"status": "affected",
"version": "9898abb3d23311fa227a7f46bf4e40fd2954057f",
"versionType": "git"
},
{
"lessThan": "a66c869b17c4c4dcf81d273b02cb0efe88e127ab",
"status": "affected",
"version": "9898abb3d23311fa227a7f46bf4e40fd2954057f",
"versionType": "git"
},
{
"lessThan": "a69e1bdd777ce51061111dc419801e8a2fd241cc",
"status": "affected",
"version": "9898abb3d23311fa227a7f46bf4e40fd2954057f",
"versionType": "git"
},
{
"lessThan": "529e1852785599160415e964ca322ee7add7aef0",
"status": "affected",
"version": "9898abb3d23311fa227a7f46bf4e40fd2954057f",
"versionType": "git"
},
{
"lessThan": "00e7d3bea2ce7dac7bee1cf501fb071fd0ea8f6c",
"status": "affected",
"version": "9898abb3d23311fa227a7f46bf4e40fd2954057f",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"lib/dynamic_debug.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "2.6.30"
},
{
"lessThan": "2.6.30",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "4.19.*",
"status": "unaffected",
"version": "4.19.314",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.276",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.217",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.159",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.91",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.31",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.8.*",
"status": "unaffected",
"version": "6.8.10",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.9",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "4.19.314",
"versionStartIncluding": "2.6.30",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.4.276",
"versionStartIncluding": "2.6.30",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.10.217",
"versionStartIncluding": "2.6.30",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.15.159",
"versionStartIncluding": "2.6.30",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.1.91",
"versionStartIncluding": "2.6.30",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6.31",
"versionStartIncluding": "2.6.30",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.8.10",
"versionStartIncluding": "2.6.30",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.9",
"versionStartIncluding": "2.6.30",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndyndbg: fix old BUG_ON in \u003econtrol parser\n\nFix a BUG_ON from 2009. Even if it looks \"unreachable\" (I didn\u0027t\nreally look), lets make sure by removing it, doing pr_err and return\n-EINVAL instead."
}
],
"providerMetadata": {
"dateUpdated": "2026-05-11T20:14:16.465Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/3c718bddddca9cbef177ac475b94c5c91147fb38"
},
{
"url": "https://git.kernel.org/stable/c/343081c21e56bd6690d342e2f5ae8c00183bf081"
},
{
"url": "https://git.kernel.org/stable/c/41d8ac238ab1cab01a8c71798d61903304f4e79b"
},
{
"url": "https://git.kernel.org/stable/c/ba3c118cff7bcb0fe6aa84ae1f9080d50e31c561"
},
{
"url": "https://git.kernel.org/stable/c/a66c869b17c4c4dcf81d273b02cb0efe88e127ab"
},
{
"url": "https://git.kernel.org/stable/c/a69e1bdd777ce51061111dc419801e8a2fd241cc"
},
{
"url": "https://git.kernel.org/stable/c/529e1852785599160415e964ca322ee7add7aef0"
},
{
"url": "https://git.kernel.org/stable/c/00e7d3bea2ce7dac7bee1cf501fb071fd0ea8f6c"
}
],
"title": "dyndbg: fix old BUG_ON in \u003econtrol parser",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2024-35947",
"datePublished": "2024-05-19T11:14:49.924Z",
"dateReserved": "2024-05-17T13:50:33.133Z",
"dateUpdated": "2026-05-11T20:14:16.465Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"epss": {
"cve": "CVE-2024-35947",
"date": "2026-09-19",
"epss": "0.00267",
"percentile": "0.19098"
},
"fkie_nvd": {
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndyndbg: fix old BUG_ON in \u003econtrol parser\n\nFix a BUG_ON from 2009. Even if it looks \"unreachable\" (I didn\u0027t\nreally look), lets make sure by removing it, doing pr_err and return\n-EINVAL instead."
},
{
"lang": "es",
"value": " En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dyndbg: corrige el antiguo BUG_ON en \u0026gt;control parser. Corrige un BUG_ON de 2009. Incluso si parece \"unreachable\" (realmente no lo mir\u00e9), asegur\u00e9monos elimin\u00e1ndolo. haciendo pr_err y devuelve -EINVAL en su lugar."
}
],
"id": "CVE-2024-35947",
"lastModified": "2024-11-21T09:21:15.943",
"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": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"type": "Secondary"
}
]
},
"published": "2024-05-19T12:15:08.220",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/00e7d3bea2ce7dac7bee1cf501fb071fd0ea8f6c"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/343081c21e56bd6690d342e2f5ae8c00183bf081"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/3c718bddddca9cbef177ac475b94c5c91147fb38"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/41d8ac238ab1cab01a8c71798d61903304f4e79b"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/529e1852785599160415e964ca322ee7add7aef0"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/a66c869b17c4c4dcf81d273b02cb0efe88e127ab"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/a69e1bdd777ce51061111dc419801e8a2fd241cc"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/ba3c118cff7bcb0fe6aa84ae1f9080d50e31c561"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"url": "https://git.kernel.org/stable/c/00e7d3bea2ce7dac7bee1cf501fb071fd0ea8f6c"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"url": "https://git.kernel.org/stable/c/343081c21e56bd6690d342e2f5ae8c00183bf081"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"url": "https://git.kernel.org/stable/c/3c718bddddca9cbef177ac475b94c5c91147fb38"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"url": "https://git.kernel.org/stable/c/41d8ac238ab1cab01a8c71798d61903304f4e79b"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"url": "https://git.kernel.org/stable/c/529e1852785599160415e964ca322ee7add7aef0"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"url": "https://git.kernel.org/stable/c/a66c869b17c4c4dcf81d273b02cb0efe88e127ab"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"url": "https://git.kernel.org/stable/c/a69e1bdd777ce51061111dc419801e8a2fd241cc"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"url": "https://git.kernel.org/stable/c/ba3c118cff7bcb0fe6aa84ae1f9080d50e31c561"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/OTB4HWU2PTVW5NEYHHLOCXDKG3PYA534/"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Awaiting Analysis"
},
"nvd": {
"cve": {
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"lib/dynamic_debug.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "3c718bddddca9cbef177ac475b94c5c91147fb38",
"status": "affected",
"version": "9898abb3d23311fa227a7f46bf4e40fd2954057f",
"versionType": "git"
},
{
"lessThan": "343081c21e56bd6690d342e2f5ae8c00183bf081",
"status": "affected",
"version": "9898abb3d23311fa227a7f46bf4e40fd2954057f",
"versionType": "git"
},
{
"lessThan": "41d8ac238ab1cab01a8c71798d61903304f4e79b",
"status": "affected",
"version": "9898abb3d23311fa227a7f46bf4e40fd2954057f",
"versionType": "git"
},
{
"lessThan": "ba3c118cff7bcb0fe6aa84ae1f9080d50e31c561",
"status": "affected",
"version": "9898abb3d23311fa227a7f46bf4e40fd2954057f",
"versionType": "git"
},
{
"lessThan": "a66c869b17c4c4dcf81d273b02cb0efe88e127ab",
"status": "affected",
"version": "9898abb3d23311fa227a7f46bf4e40fd2954057f",
"versionType": "git"
},
{
"lessThan": "a69e1bdd777ce51061111dc419801e8a2fd241cc",
"status": "affected",
"version": "9898abb3d23311fa227a7f46bf4e40fd2954057f",
"versionType": "git"
},
{
"lessThan": "529e1852785599160415e964ca322ee7add7aef0",
"status": "affected",
"version": "9898abb3d23311fa227a7f46bf4e40fd2954057f",
"versionType": "git"
},
{
"lessThan": "00e7d3bea2ce7dac7bee1cf501fb071fd0ea8f6c",
"status": "affected",
"version": "9898abb3d23311fa227a7f46bf4e40fd2954057f",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"lib/dynamic_debug.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "2.6.30"
},
{
"lessThan": "2.6.30",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "4.19.*",
"status": "unaffected",
"version": "4.19.314",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.276",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.217",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.159",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.91",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.31",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.8.*",
"status": "unaffected",
"version": "6.8.10",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.9",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"configurations": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "1350A539-B5DC-4612-9B61-E5516FD777D5",
"versionEndExcluding": "4.19.314",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "126C6EEC-8874-4233-AE09-634924FCDDF4",
"versionEndExcluding": "5.4.276",
"versionStartIncluding": "4.20",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "AC67C71C-2044-40BA-B590-61E562F69F89",
"versionEndExcluding": "5.10.217",
"versionStartIncluding": "5.5",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "F16678CD-F7C6-4BF6-ABA8-E7600857197B",
"versionEndExcluding": "5.15.159",
"versionStartIncluding": "5.11",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "4F8C886C-75AA-469B-A6A9-12BF1A29C0D5",
"versionEndExcluding": "6.1.91",
"versionStartIncluding": "5.16",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "CDDB1F69-36AC-41C1-9192-E7CCEF5FFC00",
"versionEndExcluding": "6.6.31",
"versionStartIncluding": "6.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "30BC02BF-0FD8-4E1D-9BB7-5E7DF7CC8C80",
"versionEndExcluding": "6.8..10",
"versionStartIncluding": "6.7",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.9:rc1:*:*:*:*:*:*",
"matchCriteriaId": "22BEDD49-2C6D-402D-9DBF-6646F6ECD10B",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.9:rc2:*:*:*:*:*:*",
"matchCriteriaId": "DF73CB2A-DFFD-46FB-9BFE-AA394F27EA37",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.9:rc3:*:*:*:*:*:*",
"matchCriteriaId": "52048DDA-FC5A-4363-95A0-A6357B4D7F8C",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.9:rc4:*:*:*:*:*:*",
"matchCriteriaId": "A06B2CCF-3F43-4FA9-8773-C83C3F5764B2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.9:rc5:*:*:*:*:*:*",
"matchCriteriaId": "F850DCEC-E08B-4317-A33B-D2DCF39F601B",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.9:rc6:*:*:*:*:*:*",
"matchCriteriaId": "91326417-E981-482E-A5A3-28BC1327521B",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
},
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:debian:debian_linux:10.0:*:*:*:*:*:*:*",
"matchCriteriaId": "07B237A9-69A3-4A9C-9DA0-4E06BD37AE73",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
},
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:fedoraproject:fedora:40:*:*:*:*:*:*:*",
"matchCriteriaId": "CA277A6C-83EC-4536-9125-97B84C4FAF59",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndyndbg: fix old BUG_ON in \u003econtrol parser\n\nFix a BUG_ON from 2009. Even if it looks \"unreachable\" (I didn\u0027t\nreally look), lets make sure by removing it, doing pr_err and return\n-EINVAL instead."
},
{
"lang": "es",
"value": " En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dyndbg: corrige el antiguo BUG_ON en \u0026gt;control parser. Corrige un BUG_ON de 2009. Incluso si parece \"unreachable\" (realmente no lo mir\u00e9), asegur\u00e9monos elimin\u00e1ndolo. haciendo pr_err y devuelve -EINVAL en su lugar."
}
],
"id": "CVE-2024-35947",
"lastModified": "2026-06-17T07:35:46.993",
"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": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"type": "Secondary"
}
],
"ssvcV203": [
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"ssvcData": {
"id": "CVE-2024-35947",
"options": [
{
"exploitation": "none"
},
{
"automatable": "no"
},
{
"technicalImpact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2025-01-16T21:11:33.420262Z",
"version": "2.0.3"
}
}
]
},
"published": "2024-05-19T12:15:08.220",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/00e7d3bea2ce7dac7bee1cf501fb071fd0ea8f6c"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/343081c21e56bd6690d342e2f5ae8c00183bf081"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/3c718bddddca9cbef177ac475b94c5c91147fb38"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/41d8ac238ab1cab01a8c71798d61903304f4e79b"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/529e1852785599160415e964ca322ee7add7aef0"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/a66c869b17c4c4dcf81d273b02cb0efe88e127ab"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/a69e1bdd777ce51061111dc419801e8a2fd241cc"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/ba3c118cff7bcb0fe6aa84ae1f9080d50e31c561"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/00e7d3bea2ce7dac7bee1cf501fb071fd0ea8f6c"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/343081c21e56bd6690d342e2f5ae8c00183bf081"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/3c718bddddca9cbef177ac475b94c5c91147fb38"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/41d8ac238ab1cab01a8c71798d61903304f4e79b"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/529e1852785599160415e964ca322ee7add7aef0"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/a66c869b17c4c4dcf81d273b02cb0efe88e127ab"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/a69e1bdd777ce51061111dc419801e8a2fd241cc"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/ba3c118cff7bcb0fe6aa84ae1f9080d50e31c561"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Mailing List",
"Third Party Advisory"
],
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Mailing List",
"Third Party Advisory"
],
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Mailing List",
"Third Party Advisory"
],
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/OTB4HWU2PTVW5NEYHHLOCXDKG3PYA534/"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Analyzed",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "NVD-CWE-noinfo"
}
],
"source": "nvd@nist.gov",
"type": "Primary"
}
]
}
},
"redhat_vex": {
"aggregate_severity": "Low",
"current_release_date": "2026-06-28T07:54:01+00:00",
"cve": "CVE-2024-35947",
"id": "CVE-2024-35947",
"initial_release_date": "2024-05-19T00:00:00+00:00",
"product_status:fixed": "709",
"product_status:known_affected": "64",
"product_status:known_not_affected": "8",
"source": "Red Hat CSAF VEX",
"status": "final",
"title": "kernel: dyndbg: fix old BUG_ON in \u0026gt;control parser",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2024/cve-2024-35947.json",
"version": "3"
},
"suse_vex": {
"aggregate_severity": "moderate",
"current_release_date": "2026-09-19T02:32:52Z",
"cve": "CVE-2024-35947",
"id": "CVE-2024-35947",
"initial_release_date": "2024-05-21T01:58:58Z",
"product_status:known_affected": "475",
"product_status:known_not_affected": "6",
"product_status:recommended": "774",
"source": "SUSE CSAF VEX",
"status": "interim",
"title": "SUSE CVE CVE-2024-35947",
"url": "https://ftp.suse.com/pub/projects/security/csaf-vex/cve-2024-35947.json",
"version": "121"
},
"vulnrichment": {
"containers": {
"adp": [
{
"providerMetadata": {
"dateUpdated": "2024-08-02T03:21:48.979Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/3c718bddddca9cbef177ac475b94c5c91147fb38"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/343081c21e56bd6690d342e2f5ae8c00183bf081"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/41d8ac238ab1cab01a8c71798d61903304f4e79b"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/ba3c118cff7bcb0fe6aa84ae1f9080d50e31c561"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/a66c869b17c4c4dcf81d273b02cb0efe88e127ab"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/a69e1bdd777ce51061111dc419801e8a2fd241cc"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/529e1852785599160415e964ca322ee7add7aef0"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/00e7d3bea2ce7dac7bee1cf501fb071fd0ea8f6c"
},
{
"tags": [
"x_transferred"
],
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/OTB4HWU2PTVW5NEYHHLOCXDKG3PYA534/"
},
{
"tags": [
"x_transferred"
],
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"
},
{
"tags": [
"x_transferred"
],
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html"
}
],
"title": "CVE Program Container"
},
{
"metrics": [
{
"cvssV3_1": {
"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"
}
},
{
"other": {
"content": {
"id": "CVE-2024-35947",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2025-01-16T21:11:33.420262Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"description": "CWE-noinfo Not enough information",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2024-06-18T16:50:46.969Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"lib/dynamic_debug.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "3c718bddddca9cbef177ac475b94c5c91147fb38",
"status": "affected",
"version": "9898abb3d23311fa227a7f46bf4e40fd2954057f",
"versionType": "git"
},
{
"lessThan": "343081c21e56bd6690d342e2f5ae8c00183bf081",
"status": "affected",
"version": "9898abb3d23311fa227a7f46bf4e40fd2954057f",
"versionType": "git"
},
{
"lessThan": "41d8ac238ab1cab01a8c71798d61903304f4e79b",
"status": "affected",
"version": "9898abb3d23311fa227a7f46bf4e40fd2954057f",
"versionType": "git"
},
{
"lessThan": "ba3c118cff7bcb0fe6aa84ae1f9080d50e31c561",
"status": "affected",
"version": "9898abb3d23311fa227a7f46bf4e40fd2954057f",
"versionType": "git"
},
{
"lessThan": "a66c869b17c4c4dcf81d273b02cb0efe88e127ab",
"status": "affected",
"version": "9898abb3d23311fa227a7f46bf4e40fd2954057f",
"versionType": "git"
},
{
"lessThan": "a69e1bdd777ce51061111dc419801e8a2fd241cc",
"status": "affected",
"version": "9898abb3d23311fa227a7f46bf4e40fd2954057f",
"versionType": "git"
},
{
"lessThan": "529e1852785599160415e964ca322ee7add7aef0",
"status": "affected",
"version": "9898abb3d23311fa227a7f46bf4e40fd2954057f",
"versionType": "git"
},
{
"lessThan": "00e7d3bea2ce7dac7bee1cf501fb071fd0ea8f6c",
"status": "affected",
"version": "9898abb3d23311fa227a7f46bf4e40fd2954057f",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"lib/dynamic_debug.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "2.6.30"
},
{
"lessThan": "2.6.30",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "4.19.*",
"status": "unaffected",
"version": "4.19.314",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.276",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.217",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.159",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.91",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.31",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.8.*",
"status": "unaffected",
"version": "6.8.10",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.9",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "4.19.314",
"versionStartIncluding": "2.6.30",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.4.276",
"versionStartIncluding": "2.6.30",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.10.217",
"versionStartIncluding": "2.6.30",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.15.159",
"versionStartIncluding": "2.6.30",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.1.91",
"versionStartIncluding": "2.6.30",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6.31",
"versionStartIncluding": "2.6.30",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.8.10",
"versionStartIncluding": "2.6.30",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.9",
"versionStartIncluding": "2.6.30",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndyndbg: fix old BUG_ON in \u003econtrol parser\n\nFix a BUG_ON from 2009. Even if it looks \"unreachable\" (I didn\u0027t\nreally look), lets make sure by removing it, doing pr_err and return\n-EINVAL instead."
}
],
"providerMetadata": {
"dateUpdated": "2026-05-11T20:14:16.465Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/3c718bddddca9cbef177ac475b94c5c91147fb38"
},
{
"url": "https://git.kernel.org/stable/c/343081c21e56bd6690d342e2f5ae8c00183bf081"
},
{
"url": "https://git.kernel.org/stable/c/41d8ac238ab1cab01a8c71798d61903304f4e79b"
},
{
"url": "https://git.kernel.org/stable/c/ba3c118cff7bcb0fe6aa84ae1f9080d50e31c561"
},
{
"url": "https://git.kernel.org/stable/c/a66c869b17c4c4dcf81d273b02cb0efe88e127ab"
},
{
"url": "https://git.kernel.org/stable/c/a69e1bdd777ce51061111dc419801e8a2fd241cc"
},
{
"url": "https://git.kernel.org/stable/c/529e1852785599160415e964ca322ee7add7aef0"
},
{
"url": "https://git.kernel.org/stable/c/00e7d3bea2ce7dac7bee1cf501fb071fd0ea8f6c"
}
],
"title": "dyndbg: fix old BUG_ON in \u003econtrol parser",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2024-35947",
"datePublished": "2024-05-19T11:14:49.924Z",
"dateReserved": "2024-05-17T13:50:33.133Z",
"dateUpdated": "2026-05-11T20:14:16.465Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
}
}
CERTFR-2026-AVI-1165
Vulnerability from certfr_avis - Published: 2026-09-11 - Updated: 2026-09-11
De multiples vulnérabilités ont été découvertes dans les produits IBM. Certaines d'entre elles permettent à un attaquant de provoquer une exécution de code arbitraire à distance, une élévation de privilèges et un déni de service à distance.
Solutions
Se référer au bulletin de sécurité de l'éditeur pour l'obtention des correctifs (cf. section Documentation).
| Vendor | Product | Description | ||
|---|---|---|---|---|
| IBM | Db2 | Db2 Common Container sans le correctif de sécurité 1159cn3 | ||
| IBM | Informix Dynamic Server | Informix Dynamic Server versions 15.0.x antérieures à 15.0.1.14 | ||
| IBM | QRadar Hub | QRadar Hub versions antérieures à 3.9.1 | ||
| IBM | WebSphere Application Server | WebSphere Application Server Liberty versions antérieures à 26.0.0.10 (disponibilité prévue pour le quatrième trimestre 2026) | ||
| IBM | Informix Dynamic Server | Informix Dynamic Server versions 12.10 antérieures à InformixHQ 3.3.1 | ||
| IBM | Informix Dynamic Server | Informix Dynamic Server versions 14.10.x antérieures à 14.10.xC14 | ||
| IBM | Db2 | Db2 versions V11.5.x sans le correctif de sécurité DT495924, DT474170, DT495462, DT470425 et DT501356 | ||
| IBM | Sterling Partner Engagement Manager Essentials Edition | Sterling Partner Engagement Manager Essentials Edition versions 6.2.4.x antérieures à 6.2.4.5 | ||
| IBM | Db2 | Db2 Bridge versions antérieures à 1.1.5.2 | ||
| IBM | Db2 | Db2 Warehouse on Cloud Pak for Data versions antérieures à v5.4 patch 6 | ||
| IBM | Sterling Partner Engagement Manager Standard Edition | Sterling Partner Engagement Manager Standard Edition versions 6.2.4.x antérieures à 6.2.4.5 | ||
| IBM | Db2 | Db2 Developer Extension versions 1.1.x antérieures à 1.1.2 | ||
| IBM | Sterling Partner Engagement Manager Essentials Edition | Sterling Partner Engagement Manager Essentials Edition versions 6.3.0.x antérieures à 6.3.0.3 | ||
| IBM | Db2 | Db2 on Cloud Pak for Data versions antérieures à v5.4 patch 6 | ||
| IBM | Db2 | Db2 versions V12.1 sans le correctif de sécurité DT495924, DT495462 et DT474170 |
| Title | Publication Time | Tags | ||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||||||||||||||||||||
{
"$ref": "https://www.cert.ssi.gouv.fr/openapi.json",
"affected_systems": [
{
"description": "Db2 Common Container sans le correctif de s\u00e9curit\u00e9 1159cn3",
"product": {
"name": "Db2",
"vendor": {
"name": "IBM",
"scada": false
}
}
},
{
"description": "Informix Dynamic Server versions 15.0.x ant\u00e9rieures \u00e0 15.0.1.14",
"product": {
"name": "Informix Dynamic Server",
"vendor": {
"name": "IBM",
"scada": false
}
}
},
{
"description": "QRadar Hub versions ant\u00e9rieures \u00e0 3.9.1",
"product": {
"name": "QRadar Hub",
"vendor": {
"name": "IBM",
"scada": false
}
}
},
{
"description": "WebSphere Application Server Liberty versions ant\u00e9rieures \u00e0 26.0.0.10 (disponibilit\u00e9 pr\u00e9vue pour le quatri\u00e8me trimestre 2026)",
"product": {
"name": "WebSphere Application Server",
"vendor": {
"name": "IBM",
"scada": false
}
}
},
{
"description": "Informix Dynamic Server versions 12.10 ant\u00e9rieures \u00e0 InformixHQ 3.3.1",
"product": {
"name": "Informix Dynamic Server",
"vendor": {
"name": "IBM",
"scada": false
}
}
},
{
"description": "Informix Dynamic Server versions 14.10.x ant\u00e9rieures \u00e0 14.10.xC14",
"product": {
"name": "Informix Dynamic Server",
"vendor": {
"name": "IBM",
"scada": false
}
}
},
{
"description": "Db2 versions V11.5.x sans le correctif de s\u00e9curit\u00e9 DT495924, DT474170, DT495462, DT470425 et DT501356",
"product": {
"name": "Db2",
"vendor": {
"name": "IBM",
"scada": false
}
}
},
{
"description": "Sterling Partner Engagement Manager Essentials Edition versions 6.2.4.x ant\u00e9rieures \u00e0 6.2.4.5",
"product": {
"name": "Sterling Partner Engagement Manager Essentials Edition",
"vendor": {
"name": "IBM",
"scada": false
}
}
},
{
"description": "Db2 Bridge versions ant\u00e9rieures \u00e0 1.1.5.2",
"product": {
"name": "Db2",
"vendor": {
"name": "IBM",
"scada": false
}
}
},
{
"description": "Db2 Warehouse on Cloud Pak for Data versions ant\u00e9rieures \u00e0 v5.4 patch 6",
"product": {
"name": "Db2",
"vendor": {
"name": "IBM",
"scada": false
}
}
},
{
"description": "Sterling Partner Engagement Manager Standard Edition versions 6.2.4.x ant\u00e9rieures \u00e0 6.2.4.5",
"product": {
"name": "Sterling Partner Engagement Manager Standard Edition",
"vendor": {
"name": "IBM",
"scada": false
}
}
},
{
"description": "Db2 Developer Extension versions 1.1.x ant\u00e9rieures \u00e0 1.1.2",
"product": {
"name": "Db2",
"vendor": {
"name": "IBM",
"scada": false
}
}
},
{
"description": "Sterling Partner Engagement Manager Essentials Edition versions 6.3.0.x ant\u00e9rieures \u00e0 6.3.0.3",
"product": {
"name": "Sterling Partner Engagement Manager Essentials Edition",
"vendor": {
"name": "IBM",
"scada": false
}
}
},
{
"description": "Db2 on Cloud Pak for Data versions ant\u00e9rieures \u00e0 v5.4 patch 6",
"product": {
"name": "Db2",
"vendor": {
"name": "IBM",
"scada": false
}
}
},
{
"description": "Db2 versions V12.1 sans le correctif de s\u00e9curit\u00e9 DT495924, DT495462 et DT474170",
"product": {
"name": "Db2",
"vendor": {
"name": "IBM",
"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-75595",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-75595"
},
{
"name": "CVE-2026-49978",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-49978"
},
{
"name": "CVE-2024-40931",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40931"
},
{
"name": "CVE-2023-52471",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52471"
},
{
"name": "CVE-2026-5588",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-5588"
},
{
"name": "CVE-2021-33036",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-33036"
},
{
"name": "CVE-2021-44906",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-44906"
},
{
"name": "CVE-2026-54264",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-54264"
},
{
"name": "CVE-2024-50142",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50142"
},
{
"name": "CVE-2026-59651",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59651"
},
{
"name": "CVE-2026-45819",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45819"
},
{
"name": "CVE-2024-46826",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46826"
},
{
"name": "CVE-2024-42070",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42070"
},
{
"name": "CVE-2024-36889",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36889"
},
{
"name": "CVE-2023-52675",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52675"
},
{
"name": "CVE-2024-35810",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35810"
},
{
"name": "CVE-2026-50557",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-50557"
},
{
"name": "CVE-2024-41093",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41093"
},
{
"name": "CVE-2026-59295",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59295"
},
{
"name": "CVE-2023-52834",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52834"
},
{
"name": "CVE-2024-38627",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38627"
},
{
"name": "CVE-2023-43642",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-43642"
},
{
"name": "CVE-2021-21409",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-21409"
},
{
"name": "CVE-2023-52622",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52622"
},
{
"name": "CVE-2018-14042",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-14042"
},
{
"name": "CVE-2024-35939",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35939"
},
{
"name": "CVE-2025-2534",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-2534"
},
{
"name": "CVE-2024-38555",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38555"
},
{
"name": "CVE-2024-41009",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41009"
},
{
"name": "CVE-2026-41254",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41254"
},
{
"name": "CVE-2024-36921",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36921"
},
{
"name": "CVE-2024-36939",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36939"
},
{
"name": "CVE-2024-39503",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39503"
},
{
"name": "CVE-2024-26656",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26656"
},
{
"name": "CVE-2024-42246",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42246"
},
{
"name": "CVE-2024-26614",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26614"
},
{
"name": "CVE-2026-16480",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-16480"
},
{
"name": "CVE-2018-1334",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-1334"
},
{
"name": "CVE-2023-52762",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52762"
},
{
"name": "CVE-2024-26974",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26974"
},
{
"name": "CVE-2024-40988",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40988"
},
{
"name": "CVE-2026-32990",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-32990"
},
{
"name": "CVE-2024-26595",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26595"
},
{
"name": "CVE-2026-50645",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-50645"
},
{
"name": "CVE-2026-22610",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22610"
},
{
"name": "CVE-2024-42292",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42292"
},
{
"name": "CVE-2026-42041",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42041"
},
{
"name": "CVE-2014-125087",
"url": "https://www.cve.org/CVERecord?id=CVE-2014-125087"
},
{
"name": "CVE-2026-14686",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-14686"
},
{
"name": "CVE-2026-68763",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68763"
},
{
"name": "CVE-2023-1370",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-1370"
},
{
"name": "CVE-2026-45416",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45416"
},
{
"name": "CVE-2024-36904",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36904"
},
{
"name": "CVE-2023-52845",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52845"
},
{
"name": "CVE-2023-33201",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-33201"
},
{
"name": "CVE-2026-10050",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-10050"
},
{
"name": "CVE-2024-27010",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27010"
},
{
"name": "CVE-2024-42284",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42284"
},
{
"name": "CVE-2024-35912",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35912"
},
{
"name": "CVE-2021-47432",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47432"
},
{
"name": "CVE-2026-53666",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53666"
},
{
"name": "CVE-2024-25739",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-25739"
},
{
"name": "CVE-2026-59648",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59648"
},
{
"name": "CVE-2026-69153",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-69153"
},
{
"name": "CVE-2026-3621",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-3621"
},
{
"name": "CVE-2026-43515",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43515"
},
{
"name": "CVE-2026-42402",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42402"
},
{
"name": "CVE-2021-47304",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47304"
},
{
"name": "CVE-2024-35807",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35807"
},
{
"name": "CVE-2022-48632",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48632"
},
{
"name": "CVE-2026-43868",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43868"
},
{
"name": "CVE-2026-50560",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-50560"
},
{
"name": "CVE-2024-26586",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26586"
},
{
"name": "CVE-2024-41060",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41060"
},
{
"name": "CVE-2015-5237",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-5237"
},
{
"name": "CVE-2026-71290",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-71290"
},
{
"name": "CVE-2019-10099",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-10099"
},
{
"name": "CVE-2024-26585",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26585"
},
{
"name": "CVE-2026-41716",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41716"
},
{
"name": "CVE-2018-11760",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-11760"
},
{
"name": "CVE-2026-15328",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-15328"
},
{
"name": "CVE-2026-59645",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59645"
},
{
"name": "CVE-2022-45688",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-45688"
},
{
"name": "CVE-2024-26961",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26961"
},
{
"name": "CVE-2024-38608",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38608"
},
{
"name": "CVE-2024-23944",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-23944"
},
{
"name": "CVE-2022-33891",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-33891"
},
{
"name": "CVE-2024-50275",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50275"
},
{
"name": "CVE-2026-13006",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-13006"
},
{
"name": "CVE-2024-26638",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26638"
},
{
"name": "CVE-2018-8024",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-8024"
},
{
"name": "CVE-2021-47284",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47284"
},
{
"name": "CVE-2024-27397",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27397"
},
{
"name": "CVE-2024-49350",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49350"
},
{
"name": "CVE-2022-48619",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48619"
},
{
"name": "CVE-2024-46679",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46679"
},
{
"name": "CVE-2025-66412",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-66412"
},
{
"name": "CVE-2025-36131",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-36131"
},
{
"name": "CVE-2024-36945",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36945"
},
{
"name": "CVE-2023-52653",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52653"
},
{
"name": "CVE-2026-54514",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-54514"
},
{
"name": "CVE-2023-52756",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52756"
},
{
"name": "CVE-2024-40924",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40924"
},
{
"name": "CVE-2018-14040",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-14040"
},
{
"name": "CVE-2024-35854",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35854"
},
{
"name": "CVE-2024-28757",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-28757"
},
{
"name": "CVE-2026-77414",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-77414"
},
{
"name": "CVE-2020-11988",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-11988"
},
{
"name": "CVE-2021-46939",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-46939"
},
{
"name": "CVE-2025-56200",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-56200"
},
{
"name": "CVE-2024-37071",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-37071"
},
{
"name": "CVE-2026-77413",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-77413"
},
{
"name": "CVE-2023-52878",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52878"
},
{
"name": "CVE-2026-54399",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-54399"
},
{
"name": "CVE-2026-53668",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53668"
},
{
"name": "CVE-2024-41038",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41038"
},
{
"name": "CVE-2025-30065",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-30065"
},
{
"name": "CVE-2026-16243",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-16243"
},
{
"name": "CVE-2016-4055",
"url": "https://www.cve.org/CVERecord?id=CVE-2016-4055"
},
{
"name": "CVE-2026-9171",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-9171"
},
{
"name": "CVE-2026-67214",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-67214"
},
{
"name": "CVE-2024-37356",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-37356"
},
{
"name": "CVE-2022-48743",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48743"
},
{
"name": "CVE-2024-25638",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-25638"
},
{
"name": "CVE-2026-12185",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-12185"
},
{
"name": "CVE-2026-59921",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59921"
},
{
"name": "CVE-2024-47118",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47118"
},
{
"name": "CVE-2024-35824",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35824"
},
{
"name": "CVE-2026-47010",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47010"
},
{
"name": "CVE-2023-45853",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-45853"
},
{
"name": "CVE-2024-26704",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26704"
},
{
"name": "CVE-2024-35925",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35925"
},
{
"name": "CVE-2023-45288",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-45288"
},
{
"name": "CVE-2024-36886",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36886"
},
{
"name": "CVE-2024-26976",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26976"
},
{
"name": "CVE-2026-14685",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-14685"
},
{
"name": "CVE-2023-52803",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52803"
},
{
"name": "CVE-2023-45178",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-45178"
},
{
"name": "CVE-2026-54171",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-54171"
},
{
"name": "CVE-2024-21823",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-21823"
},
{
"name": "CVE-2022-31160",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-31160"
},
{
"name": "CVE-2021-47441",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47441"
},
{
"name": "CVE-2020-10683",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-10683"
},
{
"name": "CVE-2018-1273",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-1273"
},
{
"name": "CVE-2026-41239",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41239"
},
{
"name": "CVE-2024-26600",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26600"
},
{
"name": "CVE-2026-33814",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-33814"
},
{
"name": "CVE-2023-28746",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-28746"
},
{
"name": "CVE-2026-47891",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47891"
},
{
"name": "CVE-2023-52847",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52847"
},
{
"name": "CVE-2024-42114",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42114"
},
{
"name": "CVE-2020-26945",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-26945"
},
{
"name": "CVE-2023-52864",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52864"
},
{
"name": "CVE-2024-50302",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50302"
},
{
"name": "CVE-2026-68569",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68569"
},
{
"name": "CVE-2026-59084",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59084"
},
{
"name": "CVE-2026-65183",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-65183"
},
{
"name": "CVE-2024-35897",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35897"
},
{
"name": "CVE-2026-14257",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-14257"
},
{
"name": "CVE-2026-41901",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41901"
},
{
"name": "CVE-2026-73088",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-73088"
},
{
"name": "CVE-2023-52478",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52478"
},
{
"name": "CVE-2024-23945",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-23945"
},
{
"name": "CVE-2021-41182",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-41182"
},
{
"name": "CVE-2024-38596",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38596"
},
{
"name": "CVE-2022-25647",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-25647"
},
{
"name": "CVE-2026-9072",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-9072"
},
{
"name": "CVE-2022-26612",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-26612"
},
{
"name": "CVE-2024-36929",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36929"
},
{
"name": "CVE-2024-26802",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26802"
},
{
"name": "CVE-2026-18097",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-18097"
},
{
"name": "CVE-2024-40904",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40904"
},
{
"name": "CVE-2024-42084",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42084"
},
{
"name": "CVE-2021-47455",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47455"
},
{
"name": "CVE-2023-52492",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52492"
},
{
"name": "CVE-2022-36364",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-36364"
},
{
"name": "CVE-2026-73089",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-73089"
},
{
"name": "CVE-2023-34610",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-34610"
},
{
"name": "CVE-2026-47057",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47057"
},
{
"name": "CVE-2024-47561",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47561"
},
{
"name": "CVE-2023-52669",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52669"
},
{
"name": "CVE-2024-36883",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36883"
},
{
"name": "CVE-2024-31881",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-31881"
},
{
"name": "CVE-2019-11358",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-11358"
},
{
"name": "CVE-2026-69152",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-69152"
},
{
"name": "CVE-2024-26665",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26665"
},
{
"name": "CVE-2026-68525",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68525"
},
{
"name": "CVE-2024-27062",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27062"
},
{
"name": "CVE-2026-59901",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59901"
},
{
"name": "CVE-2024-40960",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40960"
},
{
"name": "CVE-2024-35839",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35839"
},
{
"name": "CVE-2024-26852",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26852"
},
{
"name": "CVE-2024-40997",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40997"
},
{
"name": "CVE-2024-27395",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27395"
},
{
"name": "CVE-2026-14525",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-14525"
},
{
"name": "CVE-2026-67313",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-67313"
},
{
"name": "CVE-2020-13955",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-13955"
},
{
"name": "CVE-2024-42154",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42154"
},
{
"name": "CVE-2024-42228",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42228"
},
{
"name": "CVE-2026-8858",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-8858"
},
{
"name": "CVE-2026-42580",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42580"
},
{
"name": "CVE-2021-47352",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47352"
},
{
"name": "CVE-2024-36004",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36004"
},
{
"name": "CVE-2026-41691",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41691"
},
{
"name": "CVE-2024-26921",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26921"
},
{
"name": "CVE-2024-43889",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43889"
},
{
"name": "CVE-2024-35952",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35952"
},
{
"name": "CVE-2024-26859",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26859"
},
{
"name": "CVE-2026-65637",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-65637"
},
{
"name": "CVE-2018-8009",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-8009"
},
{
"name": "CVE-2026-50163",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-50163"
},
{
"name": "CVE-2026-67315",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-67315"
},
{
"name": "CVE-2026-54516",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-54516"
},
{
"name": "CVE-2026-55223",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-55223"
},
{
"name": "CVE-2025-7962",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-7962"
},
{
"name": "CVE-2026-18499",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-18499"
},
{
"name": "CVE-2019-20444",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-20444"
},
{
"name": "CVE-2026-54515",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-54515"
},
{
"name": "CVE-2026-5516",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-5516"
},
{
"name": "CVE-2023-34462",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-34462"
},
{
"name": "CVE-2024-41007",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41007"
},
{
"name": "CVE-2026-41721",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41721"
},
{
"name": "CVE-2018-1313",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-1313"
},
{
"name": "CVE-2026-16221",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-16221"
},
{
"name": "CVE-2023-34454",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-34454"
},
{
"name": "CVE-2024-35814",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35814"
},
{
"name": "CVE-2022-46337",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-46337"
},
{
"name": "CVE-2026-6790",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-6790"
},
{
"name": "CVE-2026-65911",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-65911"
},
{
"name": "CVE-2023-52764",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52764"
},
{
"name": "CVE-2026-18401",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-18401"
},
{
"name": "CVE-2021-35516",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-35516"
},
{
"name": "CVE-2024-26698",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26698"
},
{
"name": "CVE-2024-26686",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26686"
},
{
"name": "CVE-2024-35946",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35946"
},
{
"name": "CVE-2023-44487",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-44487"
},
{
"name": "CVE-2024-29857",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-29857"
},
{
"name": "CVE-2024-35959",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35959"
},
{
"name": "CVE-2024-26645",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26645"
},
{
"name": "CVE-2026-66143",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-66143"
},
{
"name": "CVE-2024-36020",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36020"
},
{
"name": "CVE-2024-42240",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42240"
},
{
"name": "CVE-2026-66144",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-66144"
},
{
"name": "CVE-2024-35962",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35962"
},
{
"name": "CVE-2026-44494",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-44494"
},
{
"name": "CVE-2023-26049",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-26049"
},
{
"name": "CVE-2024-40972",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40972"
},
{
"name": "CVE-2026-42585",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42585"
},
{
"name": "CVE-2024-50192",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50192"
},
{
"name": "CVE-2024-26720",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26720"
},
{
"name": "CVE-2024-35855",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35855"
},
{
"name": "CVE-2024-36917",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36917"
},
{
"name": "CVE-2024-45018",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45018"
},
{
"name": "CVE-2026-12860",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-12860"
},
{
"name": "CVE-2026-10571",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-10571"
},
{
"name": "CVE-2024-34447",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-34447"
},
{
"name": "CVE-2026-65901",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-65901"
},
{
"name": "CVE-2026-11541",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-11541"
},
{
"name": "CVE-2014-3578",
"url": "https://www.cve.org/CVERecord?id=CVE-2014-3578"
},
{
"name": "CVE-2026-41635",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41635"
},
{
"name": "CVE-2024-43871",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43871"
},
{
"name": "CVE-2023-52784",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52784"
},
{
"name": "CVE-2022-40897",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-40897"
},
{
"name": "CVE-2024-31880",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-31880"
},
{
"name": "CVE-2024-29025",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-29025"
},
{
"name": "CVE-2024-43880",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43880"
},
{
"name": "CVE-2021-47461",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47461"
},
{
"name": "CVE-2026-11546",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-11546"
},
{
"name": "CVE-2026-42036",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42036"
},
{
"name": "CVE-2024-40959",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40959"
},
{
"name": "CVE-2026-64607",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64607"
},
{
"name": "CVE-2026-59652",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59652"
},
{
"name": "CVE-2024-27042",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27042"
},
{
"name": "CVE-2023-34453",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-34453"
},
{
"name": "CVE-2024-26669",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26669"
},
{
"name": "CVE-2024-26801",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26801"
},
{
"name": "CVE-2024-27043",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27043"
},
{
"name": "CVE-2024-41761",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41761"
},
{
"name": "CVE-2024-36007",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36007"
},
{
"name": "CVE-2026-65903",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-65903"
},
{
"name": "CVE-2021-47311",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47311"
},
{
"name": "CVE-2026-65900",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-65900"
},
{
"name": "CVE-2026-66010",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-66010"
},
{
"name": "CVE-2026-52746",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52746"
},
{
"name": "CVE-2024-28762",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-28762"
},
{
"name": "CVE-2023-3635",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-3635"
},
{
"name": "CVE-2026-43827",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43827"
},
{
"name": "CVE-2026-50184",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-50184"
},
{
"name": "CVE-2026-47885",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47885"
},
{
"name": "CVE-2026-50169",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-50169"
},
{
"name": "CVE-2021-47287",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47287"
},
{
"name": "CVE-2021-47338",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47338"
},
{
"name": "CVE-2024-26940",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26940"
},
{
"name": "CVE-2026-47065",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47065"
},
{
"name": "CVE-2026-55831",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-55831"
},
{
"name": "CVE-2024-35937",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35937"
},
{
"name": "CVE-2023-5072",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-5072"
},
{
"name": "CVE-2026-47841",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47841"
},
{
"name": "CVE-2021-23337",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-23337"
},
{
"name": "CVE-2024-36952",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36952"
},
{
"name": "CVE-2024-38581",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38581"
},
{
"name": "CVE-2026-41707",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41707"
},
{
"name": "CVE-2021-23369",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-23369"
},
{
"name": "CVE-2026-77415",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-77415"
},
{
"name": "CVE-2026-42403",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42403"
},
{
"name": "CVE-2024-41056",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41056"
},
{
"name": "CVE-2024-38586",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38586"
},
{
"name": "CVE-2024-26880",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26880"
},
{
"name": "CVE-2022-31777",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-31777"
},
{
"name": "CVE-2019-14893",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-14893"
},
{
"name": "CVE-2026-10534",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-10534"
},
{
"name": "CVE-2024-36025",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36025"
},
{
"name": "CVE-2026-59880",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59880"
},
{
"name": "CVE-2026-65432",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-65432"
},
{
"name": "CVE-2026-59894",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59894"
},
{
"name": "CVE-2019-0231",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-0231"
},
{
"name": "CVE-2023-50298",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-50298"
},
{
"name": "CVE-2026-15057",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-15057"
},
{
"name": "CVE-2026-41607",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41607"
},
{
"name": "CVE-2024-26308",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26308"
},
{
"name": "CVE-2025-1992",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-1992"
},
{
"name": "CVE-2026-44248",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-44248"
},
{
"name": "CVE-2018-20676",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-20676"
},
{
"name": "CVE-2024-26773",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26773"
},
{
"name": "CVE-2024-53197",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53197"
},
{
"name": "CVE-2024-36017",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36017"
},
{
"name": "CVE-2024-31141",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-31141"
},
{
"name": "CVE-2024-27434",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27434"
},
{
"name": "CVE-2025-13755",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-13755"
},
{
"name": "CVE-2025-62718",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-62718"
},
{
"name": "CVE-2025-36136",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-36136"
},
{
"name": "CVE-2024-35852",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35852"
},
{
"name": "CVE-2024-26931",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26931"
},
{
"name": "CVE-2021-47560",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47560"
},
{
"name": "CVE-2026-49458",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-49458"
},
{
"name": "CVE-2026-4800",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-4800"
},
{
"name": "CVE-2024-40974",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40974"
},
{
"name": "CVE-2026-42584",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42584"
},
{
"name": "CVE-2024-35924",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35924"
},
{
"name": "CVE-2026-4410",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-4410"
},
{
"name": "CVE-2024-36928",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36928"
},
{
"name": "CVE-2024-38558",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38558"
},
{
"name": "CVE-2026-44249",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-44249"
},
{
"name": "CVE-2023-52775",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52775"
},
{
"name": "CVE-2026-41284",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41284"
},
{
"name": "CVE-2025-36008",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-36008"
},
{
"name": "CVE-2026-59647",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59647"
},
{
"name": "CVE-2024-42124",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42124"
},
{
"name": "CVE-2024-36960",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36960"
},
{
"name": "CVE-2021-35517",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-35517"
},
{
"name": "CVE-2024-30172",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-30172"
},
{
"name": "CVE-2026-42577",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42577"
},
{
"name": "CVE-2026-58059",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-58059"
},
{
"name": "CVE-2026-48978",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-48978"
},
{
"name": "CVE-2021-47582",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47582"
},
{
"name": "CVE-2023-52781",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52781"
},
{
"name": "CVE-2021-47385",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47385"
},
{
"name": "CVE-2026-75596",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-75596"
},
{
"name": "CVE-2026-8484",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-8484"
},
{
"name": "CVE-2026-8763",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-8763"
},
{
"name": "CVE-2026-6051",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-6051"
},
{
"name": "CVE-2026-44598",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-44598"
},
{
"name": "CVE-2023-52486",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52486"
},
{
"name": "CVE-2024-40989",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40989"
},
{
"name": "CVE-2024-35845",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35845"
},
{
"name": "CVE-2025-14917",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-14917"
},
{
"name": "CVE-2023-52619",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52619"
},
{
"name": "CVE-2023-52796",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52796"
},
{
"name": "CVE-2024-36286",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36286"
},
{
"name": "CVE-2026-15325",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-15325"
},
{
"name": "CVE-2021-47073",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47073"
},
{
"name": "CVE-2026-69247",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-69247"
},
{
"name": "CVE-2026-49268",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-49268"
},
{
"name": "CVE-2024-36124",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36124"
},
{
"name": "CVE-2021-47579",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47579"
},
{
"name": "CVE-2026-33671",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-33671"
},
{
"name": "CVE-2026-14976",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-14976"
},
{
"name": "CVE-2026-5598",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-5598"
},
{
"name": "CVE-2025-68470",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68470"
},
{
"name": "CVE-2024-27017",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27017"
},
{
"name": "CVE-2026-65182",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-65182"
},
{
"name": "CVE-2018-11087",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-11087"
},
{
"name": "CVE-2026-42033",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42033"
},
{
"name": "CVE-2024-39502",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39502"
},
{
"name": "CVE-2026-42035",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42035"
},
{
"name": "CVE-2024-26804",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26804"
},
{
"name": "CVE-2026-18446",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-18446"
},
{
"name": "CVE-2026-44495",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-44495"
},
{
"name": "CVE-2024-27065",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27065"
},
{
"name": "CVE-2026-41695",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41695"
},
{
"name": "CVE-2024-23454",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-23454"
},
{
"name": "CVE-2024-27388",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27388"
},
{
"name": "CVE-2024-50082",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50082"
},
{
"name": "CVE-2026-22740",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22740"
},
{
"name": "CVE-2026-47890",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47890"
},
{
"name": "CVE-2023-52686",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52686"
},
{
"name": "CVE-2024-36005",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36005"
},
{
"name": "CVE-2022-3510",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-3510"
},
{
"name": "CVE-2026-59903",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59903"
},
{
"name": "CVE-2024-40977",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40977"
},
{
"name": "CVE-2022-3509",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-3509"
},
{
"name": "CVE-2026-14684",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-14684"
},
{
"name": "CVE-2024-36905",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36905"
},
{
"name": "CVE-2026-56746",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-56746"
},
{
"name": "CVE-2024-35893",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35893"
},
{
"name": "CVE-2024-40983",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40983"
},
{
"name": "CVE-2021-37137",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-37137"
},
{
"name": "CVE-2026-10842",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-10842"
},
{
"name": "CVE-2021-47236",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47236"
},
{
"name": "CVE-2023-51074",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-51074"
},
{
"name": "CVE-2024-53122",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53122"
},
{
"name": "CVE-2021-47373",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47373"
},
{
"name": "CVE-2026-9496",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-9496"
},
{
"name": "CVE-2026-34478",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-34478"
},
{
"name": "CVE-2026-42586",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42586"
},
{
"name": "CVE-2026-35091",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-35091"
},
{
"name": "CVE-2024-57807",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57807"
},
{
"name": "CVE-2025-30474",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-30474"
},
{
"name": "CVE-2024-41008",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41008"
},
{
"name": "CVE-2026-40984",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-40984"
},
{
"name": "CVE-2021-41973",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-41973"
},
{
"name": "CVE-2023-52683",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52683"
},
{
"name": "CVE-2023-52800",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52800"
},
{
"name": "CVE-2024-8184",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-8184"
},
{
"name": "CVE-2026-54428",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-54428"
},
{
"name": "CVE-2026-50162",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-50162"
},
{
"name": "CVE-2026-42043",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42043"
},
{
"name": "CVE-2024-26935",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26935"
},
{
"name": "CVE-2025-11143",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-11143"
},
{
"name": "CVE-2026-15055",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-15055"
},
{
"name": "CVE-2026-8646",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-8646"
},
{
"name": "CVE-2026-45822",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45822"
},
{
"name": "CVE-2025-36006",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-36006"
},
{
"name": "CVE-2026-40477",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-40477"
},
{
"name": "CVE-2023-35701",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-35701"
},
{
"name": "CVE-2024-26846",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26846"
},
{
"name": "CVE-2026-47834",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47834"
},
{
"name": "CVE-2026-34480",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-34480"
},
{
"name": "CVE-2026-14682",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-14682"
},
{
"name": "CVE-2024-35890",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35890"
},
{
"name": "CVE-2024-41041",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41041"
},
{
"name": "CVE-2018-20677",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-20677"
},
{
"name": "CVE-2024-42131",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42131"
},
{
"name": "CVE-2026-84305",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-84305"
},
{
"name": "CVE-2024-35944",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35944"
},
{
"name": "CVE-2026-73180",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-73180"
},
{
"name": "CVE-2024-42079",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42079"
},
{
"name": "CVE-2024-35898",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35898"
},
{
"name": "CVE-2026-59869",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59869"
},
{
"name": "CVE-2026-47887",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47887"
},
{
"name": "CVE-2024-27399",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27399"
},
{
"name": "CVE-2025-36186",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-36186"
},
{
"name": "CVE-2024-36270",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36270"
},
{
"name": "CVE-2026-62243",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-62243"
},
{
"name": "CVE-2023-22946",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-22946"
},
{
"name": "CVE-2026-65904",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-65904"
},
{
"name": "CVE-2026-58061",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-58061"
},
{
"name": "CVE-2025-12758",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-12758"
},
{
"name": "CVE-2026-40175",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-40175"
},
{
"name": "CVE-2023-52469",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52469"
},
{
"name": "CVE-2024-26740",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26740"
},
{
"name": "CVE-2026-69151",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-69151"
},
{
"name": "CVE-2024-35809",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35809"
},
{
"name": "CVE-2024-43854",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43854"
},
{
"name": "CVE-2024-50264",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50264"
},
{
"name": "CVE-2024-41005",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41005"
},
{
"name": "CVE-2024-44935",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44935"
},
{
"name": "CVE-2026-27970",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-27970"
},
{
"name": "CVE-2021-47468",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47468"
},
{
"name": "CVE-2023-52877",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52877"
},
{
"name": "CVE-2026-9320",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-9320"
},
{
"name": "CVE-2026-49459",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-49459"
},
{
"name": "CVE-2023-52809",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52809"
},
{
"name": "CVE-2021-36090",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-36090"
},
{
"name": "CVE-2021-27568",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-27568"
},
{
"name": "CVE-2026-6053",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-6053"
},
{
"name": "CVE-2024-41039",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41039"
},
{
"name": "CVE-2024-23953",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-23953"
},
{
"name": "CVE-2026-54265",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-54265"
},
{
"name": "CVE-2025-68161",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68161"
},
{
"name": "CVE-2023-52451",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52451"
},
{
"name": "CVE-2024-41097",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41097"
},
{
"name": "CVE-2021-38296",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-38296"
},
{
"name": "CVE-2025-21785",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21785"
},
{
"name": "CVE-2022-24823",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-24823"
},
{
"name": "CVE-2024-39472",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39472"
},
{
"name": "CVE-2024-35790",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35790"
},
{
"name": "CVE-2024-26649",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26649"
},
{
"name": "CVE-2026-56624",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-56624"
},
{
"name": "CVE-2023-34455",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-34455"
},
{
"name": "CVE-2021-41184",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-41184"
},
{
"name": "CVE-2024-33621",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-33621"
},
{
"name": "CVE-2024-36978",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36978"
},
{
"name": "CVE-2024-29131",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-29131"
},
{
"name": "CVE-2021-41183",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-41183"
},
{
"name": "CVE-2024-42225",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42225"
},
{
"name": "CVE-2024-29869",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-29869"
},
{
"name": "CVE-2026-41240",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41240"
},
{
"name": "CVE-2026-67317",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-67317"
},
{
"name": "CVE-2026-40478",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-40478"
},
{
"name": "CVE-2026-22748",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22748"
},
{
"name": "CVE-2025-33012",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-33012"
},
{
"name": "CVE-2024-41066",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41066"
},
{
"name": "CVE-2026-34479",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-34479"
},
{
"name": "CVE-2024-52804",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-52804"
},
{
"name": "CVE-2026-43828",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43828"
},
{
"name": "CVE-2026-42040",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42040"
},
{
"name": "CVE-2023-36478",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-36478"
},
{
"name": "CVE-2021-37136",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-37136"
},
{
"name": "CVE-2018-1330",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-1330"
},
{
"name": "CVE-2026-47027",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47027"
},
{
"name": "CVE-2024-35947",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35947"
},
{
"name": "CVE-2026-47058",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47058"
},
{
"name": "CVE-2024-36927",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36927"
},
{
"name": "CVE-2024-42244",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42244"
},
{
"name": "CVE-2022-48836",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48836"
},
{
"name": "CVE-2026-16441",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-16441"
},
{
"name": "CVE-2024-6763",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-6763"
},
{
"name": "CVE-2026-6052",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-6052"
},
{
"name": "CVE-2024-41012",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41012"
},
{
"name": "CVE-2024-53088",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53088"
},
{
"name": "CVE-2024-26826",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26826"
},
{
"name": "CVE-2026-14981",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-14981"
},
{
"name": "CVE-2026-58060",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-58060"
},
{
"name": "CVE-2024-26583",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26583"
},
{
"name": "CVE-2021-21295",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-21295"
},
{
"name": "CVE-2024-36922",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36922"
},
{
"name": "CVE-2026-42778",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42778"
},
{
"name": "CVE-2026-14683",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-14683"
},
{
"name": "CVE-2021-47527",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47527"
},
{
"name": "CVE-2024-35847",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35847"
},
{
"name": "CVE-2024-35896",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35896"
},
{
"name": "CVE-2024-40912",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40912"
},
{
"name": "CVE-2024-26733",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26733"
},
{
"name": "CVE-2026-14529",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-14529"
},
{
"name": "CVE-2019-0204",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-0204"
},
{
"name": "CVE-2024-26851",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26851"
},
{
"name": "CVE-2022-2047",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-2047"
},
{
"name": "CVE-2024-39487",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39487"
},
{
"name": "CVE-2018-11793",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-11793"
},
{
"name": "CVE-2026-22741",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22741"
},
{
"name": "CVE-2023-39410",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-39410"
},
{
"name": "CVE-2024-35888",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35888"
},
{
"name": "CVE-2024-25710",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-25710"
},
{
"name": "CVE-2026-12802",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-12802"
},
{
"name": "CVE-2024-26837",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26837"
},
{
"name": "CVE-2024-7254",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-7254"
},
{
"name": "CVE-2024-46695",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46695"
},
{
"name": "CVE-2022-48773",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48773"
},
{
"name": "CVE-2020-9492",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-9492"
},
{
"name": "CVE-2023-52798",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52798"
},
{
"name": "CVE-2024-31076",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-31076"
},
{
"name": "CVE-2026-40181",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-40181"
},
{
"name": "CVE-2023-52700",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52700"
},
{
"name": "CVE-2025-14923",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-14923"
},
{
"name": "CVE-2024-36901",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36901"
},
{
"name": "CVE-2026-10649",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-10649"
},
{
"name": "CVE-2026-50020",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-50020"
},
{
"name": "CVE-2024-40998",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40998"
},
{
"name": "CVE-2024-27013",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27013"
},
{
"name": "CVE-2024-29133",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-29133"
},
{
"name": "CVE-2024-41090",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41090"
},
{
"name": "CVE-2026-54512",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-54512"
},
{
"name": "CVE-2026-58063",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-58063"
},
{
"name": "CVE-2026-57819",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-57819"
},
{
"name": "CVE-2026-42578",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42578"
},
{
"name": "CVE-2021-47624",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47624"
},
{
"name": "CVE-2021-47495",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47495"
},
{
"name": "CVE-2024-35910",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35910"
},
{
"name": "CVE-2024-26675",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26675"
},
{
"name": "CVE-2022-48757",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48757"
},
{
"name": "CVE-2024-24857",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-24857"
},
{
"name": "CVE-2026-65899",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-65899"
},
{
"name": "CVE-2026-43514",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43514"
},
{
"name": "CVE-2026-45773",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45773"
},
{
"name": "CVE-2026-67319",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-67319"
},
{
"name": "CVE-2024-49949",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49949"
},
{
"name": "CVE-2026-10532",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-10532"
},
{
"name": "CVE-2023-52470",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52470"
},
{
"name": "CVE-2024-26906",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26906"
},
{
"name": "CVE-2022-24785",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-24785"
},
{
"name": "CVE-2025-2518",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-2518"
},
{
"name": "CVE-2024-36971",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36971"
},
{
"name": "CVE-2024-26840",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26840"
},
{
"name": "CVE-2023-46120",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-46120"
},
{
"name": "CVE-2024-50099",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50099"
},
{
"name": "CVE-2024-57979",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57979"
},
{
"name": "CVE-2024-52046",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-52046"
},
{
"name": "CVE-2021-43797",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-43797"
},
{
"name": "CVE-2026-70907",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-70907"
},
{
"name": "CVE-2026-48589",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-48589"
},
{
"name": "CVE-2024-26584",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26584"
},
{
"name": "CVE-2021-37404",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-37404"
},
{
"name": "CVE-2021-47386",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47386"
},
{
"name": "CVE-2023-52832",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52832"
},
{
"name": "CVE-2026-42404",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42404"
},
{
"name": "CVE-2024-41092",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41092"
},
{
"name": "CVE-2022-45787",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-45787"
},
{
"name": "CVE-2024-40995",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40995"
},
{
"name": "CVE-2018-1199",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-1199"
},
{
"name": "CVE-2024-14041",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-14041"
},
{
"name": "CVE-2021-47412",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47412"
},
{
"name": "CVE-2022-48754",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48754"
},
{
"name": "CVE-2026-41586",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41586"
},
{
"name": "CVE-2026-16192",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-16192"
},
{
"name": "CVE-2024-5569",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-5569"
},
{
"name": "CVE-2026-2950",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-2950"
},
{
"name": "CVE-2016-6811",
"url": "https://www.cve.org/CVERecord?id=CVE-2016-6811"
},
{
"name": "CVE-2023-52662",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52662"
},
{
"name": "CVE-2026-68945",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68945"
},
{
"name": "CVE-2024-42238",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42238"
},
{
"name": "CVE-2023-44981",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-44981"
},
{
"name": "CVE-2026-40895",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-40895"
},
{
"name": "CVE-2026-47063",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47063"
},
{
"name": "CVE-2025-1493",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-1493"
},
{
"name": "CVE-2026-12816",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-12816"
},
{
"name": "CVE-2021-47466",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47466"
},
{
"name": "CVE-2024-40929",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40929"
},
{
"name": "CVE-2024-43830",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43830"
},
{
"name": "CVE-2026-59083",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59083"
},
{
"name": "CVE-2025-27553",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-27553"
},
{
"name": "CVE-2024-47535",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47535"
},
{
"name": "CVE-2026-45772",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45772"
},
{
"name": "CVE-2023-52428",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52428"
},
{
"name": "CVE-2021-47289",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47289"
},
{
"name": "CVE-2023-52730",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52730"
},
{
"name": "CVE-2024-42090",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42090"
},
{
"name": "CVE-2026-41606",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41606"
},
{
"name": "CVE-2024-36941",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36941"
},
{
"name": "CVE-2026-59888",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59888"
},
{
"name": "CVE-2024-36896",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36896"
},
{
"name": "CVE-2026-10543",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-10543"
},
{
"name": "CVE-2023-6040",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-6040"
},
{
"name": "CVE-2026-13149",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-13149"
},
{
"name": "CVE-2024-26958",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26958"
},
{
"name": "CVE-2024-36902",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36902"
},
{
"name": "CVE-2026-47021",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47021"
},
{
"name": "CVE-2024-41042",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41042"
},
{
"name": "CVE-2024-6485",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-6485"
},
{
"name": "CVE-2026-47842",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47842"
},
{
"name": "CVE-2025-3050",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-3050"
},
{
"name": "CVE-2023-40167",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-40167"
},
{
"name": "CVE-2018-1274",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-1274"
},
{
"name": "CVE-2021-47383",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47383"
},
{
"name": "CVE-2026-59898",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59898"
},
{
"name": "CVE-2026-16440",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-16440"
},
{
"name": "CVE-2024-36924",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36924"
},
{
"name": "CVE-2026-64958",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64958"
},
{
"name": "CVE-2024-9823",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-9823"
},
{
"name": "CVE-2024-35835",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35835"
},
{
"name": "CVE-2024-38570",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38570"
},
{
"name": "CVE-2026-66422",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-66422"
},
{
"name": "CVE-2024-26939",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26939"
},
{
"name": "CVE-2021-22569",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-22569"
},
{
"name": "CVE-2024-26960",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26960"
},
{
"name": "CVE-2024-26735",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26735"
},
{
"name": "CVE-2024-36489",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36489"
},
{
"name": "CVE-2024-41762",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41762"
},
{
"name": "CVE-2024-40901",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40901"
},
{
"name": "CVE-2023-6378",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-6378"
},
{
"name": "CVE-2024-38575",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38575"
},
{
"name": "CVE-2021-47384",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47384"
},
{
"name": "CVE-2026-41006",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41006"
},
{
"name": "CVE-2026-41711",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41711"
},
{
"name": "CVE-2021-47321",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47321"
},
{
"name": "CVE-2026-45205",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45205"
},
{
"name": "CVE-2026-27830",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-27830"
},
{
"name": "CVE-2023-52679",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52679"
},
{
"name": "CVE-2024-39471",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39471"
},
{
"name": "CVE-2021-47018",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47018"
},
{
"name": "CVE-2026-44487",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-44487"
},
{
"name": "CVE-2026-13506",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-13506"
},
{
"name": "CVE-2024-26640",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26640"
},
{
"name": "CVE-2024-35899",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35899"
},
{
"name": "CVE-2023-52881",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52881"
},
{
"name": "CVE-2026-2482",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-2482"
},
{
"name": "CVE-2026-11897",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-11897"
},
{
"name": "CVE-2026-35092",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-35092"
},
{
"name": "CVE-2026-42038",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42038"
},
{
"name": "CVE-2026-49844",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-49844"
},
{
"name": "CVE-2024-36919",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36919"
},
{
"name": "CVE-2021-46972",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-46972"
},
{
"name": "CVE-2026-18096",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-18096"
},
{
"name": "CVE-2024-35823",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35823"
},
{
"name": "CVE-2022-34169",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-34169"
},
{
"name": "CVE-2026-2332",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-2332"
},
{
"name": "CVE-2026-1561",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-1561"
},
{
"name": "CVE-2024-26923",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26923"
},
{
"name": "CVE-2024-40954",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40954"
},
{
"name": "CVE-2024-35989",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35989"
},
{
"name": "CVE-2026-42039",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42039"
},
{
"name": "CVE-2026-59879",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59879"
},
{
"name": "CVE-2024-35877",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35877"
},
{
"name": "CVE-2026-46968",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46968"
},
{
"name": "CVE-2026-40972",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-40972"
},
{
"name": "CVE-2024-43892",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43892"
},
{
"name": "CVE-2026-50010",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-50010"
},
{
"name": "CVE-2024-27020",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27020"
},
{
"name": "CVE-2022-48760",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48760"
},
{
"name": "CVE-2024-42096",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42096"
},
{
"name": "CVE-2023-52658",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52658"
},
{
"name": "CVE-2024-26769",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26769"
},
{
"name": "CVE-2023-36479",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-36479"
},
{
"name": "CVE-2024-50256",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50256"
},
{
"name": "CVE-2026-59296",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59296"
},
{
"name": "CVE-2024-38619",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38619"
},
{
"name": "CVE-2024-38573",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38573"
},
{
"name": "CVE-2026-33672",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-33672"
},
{
"name": "CVE-2026-75838",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-75838"
},
{
"name": "CVE-2018-14041",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-14041"
},
{
"name": "CVE-2022-48804",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48804"
},
{
"name": "CVE-2026-40983",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-40983"
},
{
"name": "CVE-2024-24549",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-24549"
},
{
"name": "CVE-2026-42581",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42581"
},
{
"name": "CVE-2021-47408",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47408"
},
{
"name": "CVE-2024-39476",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39476"
},
{
"name": "CVE-2025-0915",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-0915"
},
{
"name": "CVE-2024-47668",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47668"
},
{
"name": "CVE-2023-29267",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-29267"
},
{
"name": "CVE-2024-35938",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35938"
},
{
"name": "CVE-2026-42779",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42779"
},
{
"name": "CVE-2021-47097",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47097"
},
{
"name": "CVE-2024-42322",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42322"
},
{
"name": "CVE-2026-43513",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43513"
},
{
"name": "CVE-2023-28370",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-28370"
},
{
"name": "CVE-2024-42094",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42094"
},
{
"name": "CVE-2026-54517",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-54517"
},
{
"name": "CVE-2024-27019",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27019"
},
{
"name": "CVE-2024-23848",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-23848"
},
{
"name": "CVE-2024-26843",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26843"
},
{
"name": "CVE-2022-48747",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48747"
},
{
"name": "CVE-2026-25639",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-25639"
},
{
"name": "CVE-2026-40973",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-40973"
},
{
"name": "CVE-2024-41040",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41040"
},
{
"name": "CVE-2020-11022",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-11022"
},
{
"name": "CVE-2024-38564",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38564"
},
{
"name": "CVE-2026-15064",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-15064"
},
{
"name": "CVE-2026-42044",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42044"
},
{
"name": "CVE-2024-36950",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36950"
},
{
"name": "CVE-2024-40927",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40927"
},
{
"name": "CVE-2021-31684",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-31684"
},
{
"name": "CVE-2025-25193",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-25193"
},
{
"name": "CVE-2023-52667",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52667"
},
{
"name": "CVE-2026-8620",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-8620"
},
{
"name": "CVE-2024-41014",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41014"
},
{
"name": "CVE-2026-65905",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-65905"
},
{
"name": "CVE-2026-16439",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-16439"
},
{
"name": "CVE-2025-14915",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-14915"
},
{
"name": "CVE-2026-56745",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-56745"
},
{
"name": "CVE-2018-16487",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-16487"
},
{
"name": "CVE-2026-8633",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-8633"
},
{
"name": "CVE-2022-31159",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-31159"
},
{
"name": "CVE-2026-11714",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-11714"
},
{
"name": "CVE-2016-10735",
"url": "https://www.cve.org/CVERecord?id=CVE-2016-10735"
},
{
"name": "CVE-2024-52903",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-52903"
},
{
"name": "CVE-2026-47838",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47838"
},
{
"name": "CVE-2021-42550",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-42550"
},
{
"name": "CVE-2017-18214",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-18214"
},
{
"name": "CVE-2025-22870",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22870"
},
{
"name": "CVE-2026-59642",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59642"
},
{
"name": "CVE-2024-40941",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40941"
},
{
"name": "CVE-2023-52703",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52703"
},
{
"name": "CVE-2024-40679",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40679"
},
{
"name": "CVE-2026-42034",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42034"
},
{
"name": "CVE-2026-47884",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47884"
},
{
"name": "CVE-2026-41417",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41417"
},
{
"name": "CVE-2026-61308",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-61308"
},
{
"name": "CVE-2025-23215",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23215"
},
{
"name": "CVE-2026-48043",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-48043"
},
{
"name": "CVE-2026-9322",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-9322"
},
{
"name": "CVE-2024-41055",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41055"
},
{
"name": "CVE-2026-87958",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-87958"
},
{
"name": "CVE-2026-22745",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22745"
},
{
"name": "CVE-2024-30171",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-30171"
},
{
"name": "CVE-2026-42587",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42587"
},
{
"name": "CVE-2026-54513",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-54513"
},
{
"name": "CVE-2024-38541",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38541"
},
{
"name": "CVE-2021-47491",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47491"
},
{
"name": "CVE-2024-40984",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40984"
},
{
"name": "CVE-2025-14914",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-14914"
},
{
"name": "CVE-2024-36016",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36016"
},
{
"name": "CVE-2023-52922",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52922"
},
{
"name": "CVE-2026-65927",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-65927"
},
{
"name": "CVE-2022-48866",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48866"
},
{
"name": "CVE-2026-9563",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-9563"
},
{
"name": "CVE-2023-52623",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52623"
},
{
"name": "CVE-2026-54518",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-54518"
},
{
"name": "CVE-2020-9480",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-9480"
},
{
"name": "CVE-2024-36114",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36114"
},
{
"name": "CVE-2026-47244",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47244"
},
{
"name": "CVE-2024-38540",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38540"
},
{
"name": "CVE-2026-13676",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-13676"
},
{
"name": "CVE-2024-26759",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26759"
},
{
"name": "CVE-2026-54297",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-54297"
},
{
"name": "CVE-2026-53434",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53434"
},
{
"name": "CVE-2011-4969",
"url": "https://www.cve.org/CVERecord?id=CVE-2011-4969"
},
{
"name": "CVE-2026-60589",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-60589"
},
{
"name": "CVE-2026-67312",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-67312"
},
{
"name": "CVE-2026-6938",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-6938"
},
{
"name": "CVE-2025-8916",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-8916"
},
{
"name": "CVE-2024-35884",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35884"
},
{
"name": "CVE-2024-41076",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41076"
},
{
"name": "CVE-2026-66142",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-66142"
},
{
"name": "CVE-2025-8885",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-8885"
},
{
"name": "CVE-2023-52464",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52464"
},
{
"name": "CVE-2024-39276",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39276"
},
{
"name": "CVE-2023-52813",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52813"
},
{
"name": "CVE-2026-10051",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-10051"
},
{
"name": "CVE-2026-53669",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53669"
},
{
"name": "CVE-2024-39506",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39506"
},
{
"name": "CVE-2026-41409",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41409"
},
{
"name": "CVE-2018-1259",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-1259"
},
{
"name": "CVE-2024-36940",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36940"
},
{
"name": "CVE-2023-52811",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52811"
},
{
"name": "CVE-2026-6322",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-6322"
},
{
"name": "CVE-2024-35838",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35838"
},
{
"name": "CVE-2026-8400",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-8400"
},
{
"name": "CVE-2026-45623",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45623"
},
{
"name": "CVE-2026-14980",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-14980"
},
{
"name": "CVE-2024-40978",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40978"
},
{
"name": "CVE-2023-24998",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-24998"
},
{
"name": "CVE-2024-26894",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26894"
},
{
"name": "CVE-2026-58062",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-58062"
},
{
"name": "CVE-2024-41023",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41023"
},
{
"name": "CVE-2024-53104",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53104"
},
{
"name": "CVE-2023-52615",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52615"
},
{
"name": "CVE-2024-35801",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35801"
},
{
"name": "CVE-2026-12143",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-12143"
},
{
"name": "CVE-2026-67318",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-67318"
},
{
"name": "CVE-2026-59893",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59893"
},
{
"name": "CVE-2024-35930",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35930"
},
{
"name": "CVE-2024-26660",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26660"
},
{
"name": "CVE-2024-36010",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36010"
},
{
"name": "CVE-2021-21290",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-21290"
},
{
"name": "CVE-2024-41035",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41035"
},
{
"name": "CVE-2023-52560",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52560"
},
{
"name": "CVE-2026-50151",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-50151"
},
{
"name": "CVE-2024-26878",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26878"
},
{
"name": "CVE-2024-35900",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35900"
},
{
"name": "CVE-2024-41065",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41065"
},
{
"name": "CVE-2026-44486",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-44486"
},
{
"name": "CVE-2024-38598",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38598"
},
{
"name": "CVE-2026-42264",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42264"
},
{
"name": "CVE-2026-12803",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-12803"
},
{
"name": "CVE-2021-47069",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47069"
},
{
"name": "CVE-2026-8384",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-8384"
},
{
"name": "CVE-2024-35960",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35960"
},
{
"name": "CVE-2023-2976",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-2976"
},
{
"name": "CVE-2026-59650",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59650"
},
{
"name": "CVE-2025-1000",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-1000"
},
{
"name": "CVE-2023-52840",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52840"
},
{
"name": "CVE-2021-47548",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47548"
},
{
"name": "CVE-2026-44496",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-44496"
},
{
"name": "CVE-2018-8023",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-8023"
},
{
"name": "CVE-2024-41091",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41091"
},
{
"name": "CVE-2024-26853",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26853"
},
{
"name": "CVE-2026-44492",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-44492"
},
{
"name": "CVE-2024-36920",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36920"
},
{
"name": "CVE-2021-47393",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47393"
},
{
"name": "CVE-2026-54225",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-54225"
},
{
"name": "CVE-2026-39865",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-39865"
},
{
"name": "CVE-2026-41238",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41238"
},
{
"name": "CVE-2026-47877",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47877"
},
{
"name": "CVE-2023-52522",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52522"
},
{
"name": "CVE-2026-43512",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43512"
},
{
"name": "CVE-2024-41044",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41044"
},
{
"name": "CVE-2024-40958",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40958"
},
{
"name": "CVE-2020-26555",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-26555"
},
{
"name": "CVE-2021-47497",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47497"
},
{
"name": "CVE-2024-26717",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26717"
},
{
"name": "CVE-2024-38559",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38559"
},
{
"name": "CVE-2021-22570",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-22570"
},
{
"name": "CVE-2026-47883",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47883"
},
{
"name": "CVE-2021-35515",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-35515"
},
{
"name": "CVE-2024-44990",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44990"
},
{
"name": "CVE-2026-41007",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41007"
},
{
"name": "CVE-2026-42037",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42037"
},
{
"name": "CVE-2022-40898",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-40898"
},
{
"name": "CVE-2024-42265",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42265"
},
{
"name": "CVE-2021-46984",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-46984"
},
{
"name": "CVE-2026-55760",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-55760"
},
{
"name": "CVE-2024-2201",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-2201"
},
{
"name": "CVE-2023-26048",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-26048"
},
{
"name": "CVE-2026-42498",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42498"
},
{
"name": "CVE-2026-42042",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42042"
},
{
"name": "CVE-2024-42152",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42152"
},
{
"name": "CVE-2026-9071",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-9071"
},
{
"name": "CVE-2017-7669",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-7669"
},
{
"name": "CVE-2026-67213",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-67213"
},
{
"name": "CVE-2023-52777",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52777"
},
{
"name": "CVE-2024-41013",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41013"
},
{
"name": "CVE-2026-55833",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-55833"
},
{
"name": "CVE-2024-35789",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35789"
},
{
"name": "CVE-2023-52835",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52835"
},
{
"name": "CVE-2024-45663",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45663"
},
{
"name": "CVE-2026-13586",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-13586"
},
{
"name": "CVE-2025-33134",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-33134"
},
{
"name": "CVE-2021-47101",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47101"
},
{
"name": "CVE-2024-26982",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26982"
},
{
"name": "CVE-2023-26112",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-26112"
},
{
"name": "CVE-2024-39499",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39499"
},
{
"name": "CVE-2026-9370",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-9370"
},
{
"name": "CVE-2021-47310",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47310"
},
{
"name": "CVE-2024-38579",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38579"
},
{
"name": "CVE-2023-52626",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52626"
},
{
"name": "CVE-2024-36979",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36979"
},
{
"name": "CVE-2024-36006",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36006"
},
{
"name": "CVE-2026-11806",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-11806"
},
{
"name": "CVE-2023-52476",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52476"
},
{
"name": "CVE-2024-42301",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42301"
},
{
"name": "CVE-2026-12590",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-12590"
},
{
"name": "CVE-2026-34477",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-34477"
},
{
"name": "CVE-2026-65902",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-65902"
},
{
"name": "CVE-2023-52463",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52463"
},
{
"name": "CVE-2024-26925",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26925"
},
{
"name": "CVE-2026-56819",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-56819"
},
{
"name": "CVE-2026-54284",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-54284"
},
{
"name": "CVE-2026-6321",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-6321"
},
{
"name": "CVE-2022-3171",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-3171"
},
{
"name": "CVE-2024-26870",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26870"
},
{
"name": "CVE-2024-35958",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35958"
},
{
"name": "CVE-2024-36954",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36954"
},
{
"name": "CVE-2021-47456",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47456"
},
{
"name": "CVE-2026-44490",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-44490"
},
{
"name": "CVE-2016-7103",
"url": "https://www.cve.org/CVERecord?id=CVE-2016-7103"
},
{
"name": "CVE-2015-9251",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-9251"
},
{
"name": "CVE-2026-59639",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59639"
},
{
"name": "CVE-2026-86093",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-86093"
},
{
"name": "CVE-2024-36933",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36933"
},
{
"name": "CVE-2026-10852",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-10852"
},
{
"name": "CVE-2024-41064",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41064"
},
{
"name": "CVE-2026-28338",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-28338"
},
{
"name": "CVE-2024-40911",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40911"
},
{
"name": "CVE-2010-5312",
"url": "https://www.cve.org/CVERecord?id=CVE-2010-5312"
},
{
"name": "CVE-2026-68494",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68494"
},
{
"name": "CVE-2024-26810",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26810"
},
{
"name": "CVE-2023-52530",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52530"
},
{
"name": "CVE-2024-26772",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26772"
},
{
"name": "CVE-2012-6708",
"url": "https://www.cve.org/CVERecord?id=CVE-2012-6708"
},
{
"name": "CVE-2024-36000",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36000"
},
{
"name": "CVE-2024-50110",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50110"
},
{
"name": "CVE-2021-47356",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47356"
},
{
"name": "CVE-2020-7656",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-7656"
},
{
"name": "CVE-2018-8013",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-8013"
},
{
"name": "CVE-2021-47609",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47609"
},
{
"name": "CVE-2026-29063",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-29063"
},
{
"name": "CVE-2026-60147",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-60147"
},
{
"name": "CVE-2026-47889",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47889"
},
{
"name": "CVE-2024-26855",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26855"
},
{
"name": "CVE-2019-16869",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-16869"
},
{
"name": "CVE-2023-52648",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52648"
},
{
"name": "CVE-2026-15280",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-15280"
},
{
"name": "CVE-2026-67316",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-67316"
},
{
"name": "CVE-2025-14813",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-14813"
},
{
"name": "CVE-2022-41881",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-41881"
},
{
"name": "CVE-2025-13465",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-13465"
},
{
"name": "CVE-2023-52791",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52791"
},
{
"name": "CVE-2024-38538",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38538"
},
{
"name": "CVE-2026-44488",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-44488"
},
{
"name": "CVE-2024-42237",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42237"
},
{
"name": "CVE-2021-47353",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47353"
},
{
"name": "CVE-2023-52707",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52707"
},
{
"name": "CVE-2026-59899",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59899"
},
{
"name": "CVE-2026-1718",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-1718"
},
{
"name": "CVE-2026-71491",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-71491"
},
{
"name": "CVE-2026-34481",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-34481"
},
{
"name": "CVE-2024-27025",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27025"
},
{
"name": "CVE-2024-27011",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27011"
},
{
"name": "CVE-2024-36953",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36953"
},
{
"name": "CVE-2024-26924",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26924"
},
{
"name": "CVE-2021-47257",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47257"
},
{
"name": "CVE-2026-38969",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-38969"
},
{
"name": "CVE-2026-19880",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-19880"
},
{
"name": "CVE-2024-46858",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46858"
},
{
"name": "CVE-2026-47059",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47059"
},
{
"name": "CVE-2022-25168",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-25168"
},
{
"name": "CVE-2026-41293",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41293"
},
{
"name": "CVE-2024-38615",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38615"
},
{
"name": "CVE-2024-44989",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44989"
},
{
"name": "CVE-2024-6345",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-6345"
},
{
"name": "CVE-2026-77310",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-77310"
},
{
"name": "CVE-2024-57699",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57699"
},
{
"name": "CVE-2023-52817",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52817"
},
{
"name": "CVE-2026-65898",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-65898"
},
{
"name": "CVE-2020-11023",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-11023"
},
{
"name": "CVE-2023-5090",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-5090"
},
{
"name": "CVE-2024-27410",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27410"
},
{
"name": "CVE-2021-46909",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-46909"
},
{
"name": "CVE-2019-8331",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-8331"
},
{
"name": "CVE-2024-35853",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35853"
},
{
"name": "CVE-2018-1000632",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-1000632"
},
{
"name": "CVE-2019-20445",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-20445"
},
{
"name": "CVE-2024-26907",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26907"
},
{
"name": "CVE-2024-40961",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40961"
},
{
"name": "CVE-2026-59889",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59889"
},
{
"name": "CVE-2025-36185",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-36185"
},
{
"name": "CVE-2025-11226",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-11226"
}
],
"initial_release_date": "2026-09-11T00:00:00",
"last_revision_date": "2026-09-11T00:00:00",
"links": [],
"reference": "CERTFR-2026-AVI-1165",
"revisions": [
{
"description": "Version initiale",
"revision_date": "2026-09-11T00:00:00.000000"
}
],
"risks": [
{
"description": "D\u00e9ni de service \u00e0 distance"
},
{
"description": "Injection de code indirecte \u00e0 distance (XSS)"
},
{
"description": "Injection de requ\u00eates ill\u00e9gitimes par rebond (CSRF)"
},
{
"description": "Ex\u00e9cution de code arbitraire \u00e0 distance"
},
{
"description": "Atteinte \u00e0 l\u0027int\u00e9grit\u00e9 des donn\u00e9es"
},
{
"description": "Non sp\u00e9cifi\u00e9 par l\u0027\u00e9diteur"
},
{
"description": "Falsification de requ\u00eates c\u00f4t\u00e9 serveur (SSRF)"
},
{
"description": "Contournement de la politique de s\u00e9curit\u00e9"
},
{
"description": "Atteinte \u00e0 la confidentialit\u00e9 des donn\u00e9es"
},
{
"description": "\u00c9l\u00e9vation de privil\u00e8ges"
}
],
"summary": "De multiples vuln\u00e9rabilit\u00e9s ont \u00e9t\u00e9 d\u00e9couvertes dans les produits IBM. Certaines d\u0027entre elles permettent \u00e0 un attaquant de provoquer une ex\u00e9cution de code arbitraire \u00e0 distance, une \u00e9l\u00e9vation de privil\u00e8ges et un d\u00e9ni de service \u00e0 distance.",
"title": "Multiples vuln\u00e9rabilit\u00e9s dans les produits IBM",
"vendor_advisories": [
{
"published_at": "2026-09-09",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7286777",
"url": "https://www.ibm.com/support/pages/node/7286777"
},
{
"published_at": "2026-09-09",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7286776",
"url": "https://www.ibm.com/support/pages/node/7286776"
},
{
"published_at": "2026-09-10",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7286990",
"url": "https://www.ibm.com/support/pages/node/7286990"
},
{
"published_at": "2026-09-10",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7286976",
"url": "https://www.ibm.com/support/pages/node/7286976"
},
{
"published_at": "2026-09-10",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7286993",
"url": "https://www.ibm.com/support/pages/node/7286993"
},
{
"published_at": "2026-09-09",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7286782",
"url": "https://www.ibm.com/support/pages/node/7286782"
},
{
"published_at": "2026-09-07",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7286515",
"url": "https://www.ibm.com/support/pages/node/7286515"
},
{
"published_at": "2026-09-10",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7286646",
"url": "https://www.ibm.com/support/pages/node/7286646"
},
{
"published_at": "2026-09-11",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7287136",
"url": "https://www.ibm.com/support/pages/node/7287136"
},
{
"published_at": "2026-09-10",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7286986",
"url": "https://www.ibm.com/support/pages/node/7286986"
},
{
"published_at": "2026-09-10",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7286982",
"url": "https://www.ibm.com/support/pages/node/7286982"
},
{
"published_at": "2026-09-09",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7286775",
"url": "https://www.ibm.com/support/pages/node/7286775"
},
{
"published_at": "2026-09-10",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7286987",
"url": "https://www.ibm.com/support/pages/node/7286987"
},
{
"published_at": "2026-09-09",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7286910",
"url": "https://www.ibm.com/support/pages/node/7286910"
},
{
"published_at": "2026-09-07",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7286516",
"url": "https://www.ibm.com/support/pages/node/7286516"
},
{
"published_at": "2026-09-09",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7286909",
"url": "https://www.ibm.com/support/pages/node/7286909"
}
]
}
FKIE_CVE-2024-35947
Vulnerability from fkie_nvd - Published: 2024-05-19 12:15 - Updated: 2026-06-17 07:35| Vendor | Product | Version | |
|---|---|---|---|
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | 6.9 | |
| linux | linux_kernel | 6.9 | |
| linux | linux_kernel | 6.9 | |
| linux | linux_kernel | 6.9 | |
| linux | linux_kernel | 6.9 | |
| linux | linux_kernel | 6.9 | |
| debian | debian_linux | 10.0 | |
| fedoraproject | fedora | 40 |
{
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"lib/dynamic_debug.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "3c718bddddca9cbef177ac475b94c5c91147fb38",
"status": "affected",
"version": "9898abb3d23311fa227a7f46bf4e40fd2954057f",
"versionType": "git"
},
{
"lessThan": "343081c21e56bd6690d342e2f5ae8c00183bf081",
"status": "affected",
"version": "9898abb3d23311fa227a7f46bf4e40fd2954057f",
"versionType": "git"
},
{
"lessThan": "41d8ac238ab1cab01a8c71798d61903304f4e79b",
"status": "affected",
"version": "9898abb3d23311fa227a7f46bf4e40fd2954057f",
"versionType": "git"
},
{
"lessThan": "ba3c118cff7bcb0fe6aa84ae1f9080d50e31c561",
"status": "affected",
"version": "9898abb3d23311fa227a7f46bf4e40fd2954057f",
"versionType": "git"
},
{
"lessThan": "a66c869b17c4c4dcf81d273b02cb0efe88e127ab",
"status": "affected",
"version": "9898abb3d23311fa227a7f46bf4e40fd2954057f",
"versionType": "git"
},
{
"lessThan": "a69e1bdd777ce51061111dc419801e8a2fd241cc",
"status": "affected",
"version": "9898abb3d23311fa227a7f46bf4e40fd2954057f",
"versionType": "git"
},
{
"lessThan": "529e1852785599160415e964ca322ee7add7aef0",
"status": "affected",
"version": "9898abb3d23311fa227a7f46bf4e40fd2954057f",
"versionType": "git"
},
{
"lessThan": "00e7d3bea2ce7dac7bee1cf501fb071fd0ea8f6c",
"status": "affected",
"version": "9898abb3d23311fa227a7f46bf4e40fd2954057f",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"lib/dynamic_debug.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "2.6.30"
},
{
"lessThan": "2.6.30",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "4.19.*",
"status": "unaffected",
"version": "4.19.314",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.276",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.217",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.159",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.91",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.31",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.8.*",
"status": "unaffected",
"version": "6.8.10",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.9",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"configurations": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "1350A539-B5DC-4612-9B61-E5516FD777D5",
"versionEndExcluding": "4.19.314",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "126C6EEC-8874-4233-AE09-634924FCDDF4",
"versionEndExcluding": "5.4.276",
"versionStartIncluding": "4.20",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "AC67C71C-2044-40BA-B590-61E562F69F89",
"versionEndExcluding": "5.10.217",
"versionStartIncluding": "5.5",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "F16678CD-F7C6-4BF6-ABA8-E7600857197B",
"versionEndExcluding": "5.15.159",
"versionStartIncluding": "5.11",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "4F8C886C-75AA-469B-A6A9-12BF1A29C0D5",
"versionEndExcluding": "6.1.91",
"versionStartIncluding": "5.16",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "CDDB1F69-36AC-41C1-9192-E7CCEF5FFC00",
"versionEndExcluding": "6.6.31",
"versionStartIncluding": "6.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "30BC02BF-0FD8-4E1D-9BB7-5E7DF7CC8C80",
"versionEndExcluding": "6.8..10",
"versionStartIncluding": "6.7",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.9:rc1:*:*:*:*:*:*",
"matchCriteriaId": "22BEDD49-2C6D-402D-9DBF-6646F6ECD10B",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.9:rc2:*:*:*:*:*:*",
"matchCriteriaId": "DF73CB2A-DFFD-46FB-9BFE-AA394F27EA37",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.9:rc3:*:*:*:*:*:*",
"matchCriteriaId": "52048DDA-FC5A-4363-95A0-A6357B4D7F8C",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.9:rc4:*:*:*:*:*:*",
"matchCriteriaId": "A06B2CCF-3F43-4FA9-8773-C83C3F5764B2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.9:rc5:*:*:*:*:*:*",
"matchCriteriaId": "F850DCEC-E08B-4317-A33B-D2DCF39F601B",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.9:rc6:*:*:*:*:*:*",
"matchCriteriaId": "91326417-E981-482E-A5A3-28BC1327521B",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
},
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:debian:debian_linux:10.0:*:*:*:*:*:*:*",
"matchCriteriaId": "07B237A9-69A3-4A9C-9DA0-4E06BD37AE73",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
},
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:fedoraproject:fedora:40:*:*:*:*:*:*:*",
"matchCriteriaId": "CA277A6C-83EC-4536-9125-97B84C4FAF59",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndyndbg: fix old BUG_ON in \u003econtrol parser\n\nFix a BUG_ON from 2009. Even if it looks \"unreachable\" (I didn\u0027t\nreally look), lets make sure by removing it, doing pr_err and return\n-EINVAL instead."
},
{
"lang": "es",
"value": " En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dyndbg: corrige el antiguo BUG_ON en \u0026gt;control parser. Corrige un BUG_ON de 2009. Incluso si parece \"unreachable\" (realmente no lo mir\u00e9), asegur\u00e9monos elimin\u00e1ndolo. haciendo pr_err y devuelve -EINVAL en su lugar."
}
],
"id": "CVE-2024-35947",
"lastModified": "2026-06-17T07:35:46.993",
"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": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"type": "Secondary"
}
],
"ssvcV203": [
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"ssvcData": {
"id": "CVE-2024-35947",
"options": [
{
"exploitation": "none"
},
{
"automatable": "no"
},
{
"technicalImpact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2025-01-16T21:11:33.420262Z",
"version": "2.0.3"
}
}
]
},
"published": "2024-05-19T12:15:08.220",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/00e7d3bea2ce7dac7bee1cf501fb071fd0ea8f6c"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/343081c21e56bd6690d342e2f5ae8c00183bf081"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/3c718bddddca9cbef177ac475b94c5c91147fb38"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/41d8ac238ab1cab01a8c71798d61903304f4e79b"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/529e1852785599160415e964ca322ee7add7aef0"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/a66c869b17c4c4dcf81d273b02cb0efe88e127ab"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/a69e1bdd777ce51061111dc419801e8a2fd241cc"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/ba3c118cff7bcb0fe6aa84ae1f9080d50e31c561"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/00e7d3bea2ce7dac7bee1cf501fb071fd0ea8f6c"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/343081c21e56bd6690d342e2f5ae8c00183bf081"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/3c718bddddca9cbef177ac475b94c5c91147fb38"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/41d8ac238ab1cab01a8c71798d61903304f4e79b"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/529e1852785599160415e964ca322ee7add7aef0"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/a66c869b17c4c4dcf81d273b02cb0efe88e127ab"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/a69e1bdd777ce51061111dc419801e8a2fd241cc"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/ba3c118cff7bcb0fe6aa84ae1f9080d50e31c561"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Mailing List",
"Third Party Advisory"
],
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Mailing List",
"Third Party Advisory"
],
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Mailing List",
"Third Party Advisory"
],
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/OTB4HWU2PTVW5NEYHHLOCXDKG3PYA534/"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Analyzed",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "NVD-CWE-noinfo"
}
],
"source": "nvd@nist.gov",
"type": "Primary"
}
]
}
GHSA-MQWF-3V63-P67R
Vulnerability from github – Published: 2024-05-19 12:30 – Updated: 2024-11-04 18:31In the Linux kernel, the following vulnerability has been resolved:
dyndbg: fix old BUG_ON in >control parser
Fix a BUG_ON from 2009. Even if it looks "unreachable" (I didn't really look), lets make sure by removing it, doing pr_err and return -EINVAL instead.
{
"affected": [],
"aliases": [
"CVE-2024-35947"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-19T12:15:08Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndyndbg: fix old BUG_ON in \u003econtrol parser\n\nFix a BUG_ON from 2009. Even if it looks \"unreachable\" (I didn\u0027t\nreally look), lets make sure by removing it, doing pr_err and return\n-EINVAL instead.",
"id": "GHSA-mqwf-3v63-p67r",
"modified": "2024-11-04T18:31:18Z",
"published": "2024-05-19T12:30:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35947"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/00e7d3bea2ce7dac7bee1cf501fb071fd0ea8f6c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/343081c21e56bd6690d342e2f5ae8c00183bf081"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3c718bddddca9cbef177ac475b94c5c91147fb38"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/41d8ac238ab1cab01a8c71798d61903304f4e79b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/529e1852785599160415e964ca322ee7add7aef0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a66c869b17c4c4dcf81d273b02cb0efe88e127ab"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a69e1bdd777ce51061111dc419801e8a2fd241cc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ba3c118cff7bcb0fe6aa84ae1f9080d50e31c561"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/OTB4HWU2PTVW5NEYHHLOCXDKG3PYA534"
}
],
"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"
}
]
}
ICSA-25-226-15
Vulnerability from csaf_cisa - Published: 2025-08-12 00:00 - Updated: 2026-02-25 07:00OESA-2024-1736 (CVE-2021-47229)
Vulnerability from osv_openeuler – Published: 2024-06-21 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:
PCI: aardvark: Fix kernel panic during PIO transfer
Trying to start a new PIO transfer by writing value 0 in PIO_START register when previous transfer has not yet completed (which is indicated by value 1 in PIO_START) causes an External Abort on CPU, which results in kernel panic:
SError Interrupt on CPU0, code 0xbf000002 -- SError
Kernel panic - not syncing: Asynchronous SError Interrupt
To prevent kernel panic, it is required to reject a new PIO transfer when previous one has not finished yet.
If previous PIO transfer is not finished yet, the kernel may issue a new PIO request only if the previous PIO transfer timed out.
In the past the root cause of this issue was incorrectly identified (as it often happens during link retraining or after link down event) and special hack was implemented in Trusted Firmware to catch all SError events in EL3, to ignore errors with code 0xbf000002 and not forwarding any other errors to kernel and instead throw panic from EL3 Trusted Firmware handler.
Links to discussion and patches about this issue: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/?id=3c7dcdac5c50 https://lore.kernel.org/linux-pci/20190316161243.29517-1-repk@triplefau.lt/ https://lore.kernel.org/linux-pci/971be151d24312cc533989a64bd454b4@www.loen.fr/ https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/1541
But the real cause was the fact that during link retraining or after link down event the PIO transfer may take longer time, up to the 1.44s until it times out. This increased probability that a new PIO transfer would be issued by kernel while previous one has not finished yet.
After applying this change into the kernel, it is possible to revert the mentioned TF-A hack and SError events do not have to be caught in TF-A EL3.(CVE-2021-47229)
In the Linux kernel, the following vulnerability has been resolved:
phy: phy-mtk-tphy: Fix some resource leaks in mtk_phy_init()
Use clk_disable_unprepare() in the error path of mtk_phy_init() to fix some resource leaks.(CVE-2021-47234)
In the Linux kernel, the following vulnerability has been resolved:
net: rds: fix memory leak in rds_recvmsg
Syzbot reported memory leak in rds. The problem was in unputted refcount in case of error.
int rds_recvmsg(struct socket sock, struct msghdr msg, size_t size, int msg_flags) { ...
if (!rds_next_incoming(rs, &inc)) {
...
}
After this "if" inc refcount incremented and
if (rds_cmsg_recv(inc, msg, rs)) {
ret = -EFAULT;
goto out;
}
... out: return ret; }
in case of rds_cmsg_recv() fail the refcount won't be decremented. And it's easy to see from ftrace log, that rds_inc_addref() don't have rds_inc_put() pair in rds_recvmsg() after rds_cmsg_recv()
1) | rds_recvmsg() { 1) 3.721 us | rds_inc_addref(); 1) 3.853 us | rds_message_inc_copy_to_user(); 1) + 10.395 us | rds_cmsg_recv(); 1) + 34.260 us | }(CVE-2021-47249)
In the Linux kernel, the following vulnerability has been resolved:
net: ieee802154: fix null deref in parse dev addr
Fix a logic error that could result in a null deref if the user sets the mode incorrectly for the given addr type.(CVE-2021-47257)
In the Linux kernel, the following vulnerability has been resolved:
usb: fix various gadget panics on 10gbps cabling
usb_assign_descriptors() is called with 5 parameters, the last 4 of which are the usb_descriptor_header for: full-speed (USB1.1 - 12Mbps [including USB1.0 low-speed @ 1.5Mbps), high-speed (USB2.0 - 480Mbps), super-speed (USB3.0 - 5Gbps), super-speed-plus (USB3.1 - 10Gbps).
The differences between full/high/super-speed descriptors are usually substantial (due to changes in the maximum usb block size from 64 to 512 to 1024 bytes and other differences in the specs), while the difference between 5 and 10Gbps descriptors may be as little as nothing (in many cases the same tuning is simply good enough).
However if a gadget driver calls usb_assign_descriptors() with a NULL descriptor for super-speed-plus and is then used on a max 10gbps configuration, the kernel will crash with a null pointer dereference, when a 10gbps capable device port + cable + host port combination shows up. (This wouldn't happen if the gadget max-speed was set to 5gbps, but it of course defaults to the maximum, and there's no real reason to artificially limit it)
The fix is to simply use the 5gbps descriptor as the 10gbps descriptor, if a 10gbps descriptor wasn't provided.
Obviously this won't fix the problem if the 5gbps descriptor is also NULL, but such cases can't be so trivially solved (and any such gadgets are unlikely to be used with USB3 ports any way).(CVE-2021-47267)
In the Linux kernel, the following vulnerability has been resolved:
ALSA: seq: Fix race of snd_seq_timer_open()
The timer instance per queue is exclusive, and snd_seq_timer_open() should have managed the concurrent accesses. It looks as if it's checking the already existing timer instance at the beginning, but it's not right, because there is no protection, hence any later concurrent call of snd_seq_timer_open() may override the timer instance easily. This may result in UAF, as the leftover timer instance can keep running while the queue itself gets closed, as spotted by syzkaller recently.
For avoiding the race, add a proper check at the assignment of tmr->timeri again, and return -EBUSY if it's been already registered.(CVE-2021-47281)
In the Linux kernel, the following vulnerability has been resolved:
igb: Fix use-after-free error during reset
Cleans the next descriptor to watch (next_to_watch) when cleaning the TX ring.
Failure to do so can cause invalid memory accesses. If igb_poll() runs while the controller is reset this can lead to the driver try to free a skb that was already freed.
(The crash is harder to reproduce with the igb driver, but the same potential problem exists as the code is identical to igc)(CVE-2021-47301)
In the Linux kernel, the following vulnerability has been resolved:
net: ti: fix UAF in tlan_remove_one
priv is netdev private data and it cannot be used after free_netdev() call. Using priv after free_netdev() can cause UAF bug. Fix it by moving free_netdev() at the end of the function.(CVE-2021-47310)
In the Linux kernel, the following vulnerability has been resolved:
watchdog: Fix possible use-after-free by calling del_timer_sync()
This driver's remove path calls del_timer(). However, that function does not wait until the timer handler finishes. This means that the timer handler may still be running after the driver's remove function has finished, which would result in a use-after-free.
Fix by calling del_timer_sync(), which makes sure the timer handler has finished, and unable to re-schedule itself.(CVE-2021-47321)
In the Linux kernel, the following vulnerability has been resolved:
misc/libmasm/module: Fix two use after free in ibmasm_init_one
In ibmasm_init_one, it calls ibmasm_init_remote_input_dev(). Inside ibmasm_init_remote_input_dev, mouse_dev and keybd_dev are allocated by input_allocate_device(), and assigned to sp->remote.mouse_dev and sp->remote.keybd_dev respectively.
In the err_free_devices error branch of ibmasm_init_one, mouse_dev and keybd_dev are freed by input_free_device(), and return error. Then the execution runs into error_send_message error branch of ibmasm_init_one, where ibmasm_free_remote_input_dev(sp) is called to unregister the freed sp->remote.mouse_dev and sp->remote.keybd_dev.
My patch add a "error_init_remote" label to handle the error of ibmasm_init_remote_input_dev(), to avoid the uaf bugs.(CVE-2021-47334)
In the Linux kernel, the following vulnerability has been resolved:
media: zr364xx: fix memory leak in zr364xx_start_readpipe
syzbot reported memory leak in zr364xx driver. The problem was in non-freed urb in case of usb_submit_urb() fail.
backtrace: [<ffffffff82baedf6>] kmalloc include/linux/slab.h:561 [inline] [<ffffffff82baedf6>] usb_alloc_urb+0x66/0xe0 drivers/usb/core/urb.c:74 [<ffffffff82f7cce8>] zr364xx_start_readpipe+0x78/0x130 drivers/media/usb/zr364xx/zr364xx.c:1022 [<ffffffff84251dfc>] zr364xx_board_init drivers/media/usb/zr364xx/zr364xx.c:1383 [inline] [<ffffffff84251dfc>] zr364xx_probe+0x6a3/0x851 drivers/media/usb/zr364xx/zr364xx.c:1516 [<ffffffff82bb6507>] usb_probe_interface+0x177/0x370 drivers/usb/core/driver.c:396 [<ffffffff826018a9>] really_probe+0x159/0x500 drivers/base/dd.c:576(CVE-2021-47344)
In the Linux kernel, the following vulnerability has been resolved:
drm/sched: Avoid data corruptions
Wait for all dependencies of a job to complete before killing it to avoid data corruptions.(CVE-2021-47354)
In the Linux kernel, the following vulnerability has been resolved:
net: macb: fix use after free on rmmod
plat_dev->dev->platform_data is released by platform_device_unregister(), use of pclk and hclk is a use-after-free. Since device unregister won't need a clk device we adjust the function call sequence to fix this issue.
[ 31.261225] BUG: KASAN: use-after-free in macb_remove+0x77/0xc6 [macb_pci] [ 31.275563] Freed by task 306: [ 30.276782] platform_device_release+0x25/0x80(CVE-2021-47372)
In the Linux kernel, the following vulnerability has been resolved:
i2c: acpi: fix resource leak in reconfiguration device addition
acpi_i2c_find_adapter_by_handle() calls bus_find_device() which takes a reference on the adapter which is never released which will result in a reference count leak and render the adapter unremovable. Make sure to put the adapter after creating the client in the same manner that we do for OF.
In the Linux kernel, the following vulnerability has been resolved:
net: encx24j600: check error in devm_regmap_init_encx24j600
devm_regmap_init may return error which caused by like out of memory, this will results in null pointer dereference later when reading or writing register:
general protection fault in encx24j600_spi_probe KASAN: null-ptr-deref in range [0x0000000000000090-0x0000000000000097] CPU: 0 PID: 286 Comm: spi-encx24j600- Not tainted 5.15.0-rc2-00142-g9978db750e31-dirty #11 9c53a778c1306b1b02359f3c2bbedc0222cba652 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:regcache_cache_bypass drivers/base/regmap/regcache.c:540 Code: 54 41 89 f4 55 53 48 89 fb 48 83 ec 08 e8 26 94 a8 fe 48 8d bb a0 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 4a 03 00 00 4c 8d ab b0 00 00 00 48 8b ab a0 00 RSP: 0018:ffffc900010476b8 EFLAGS: 00010207 RAX: dffffc0000000000 RBX: fffffffffffffff4 RCX: 0000000000000000 RDX: 0000000000000012 RSI: ffff888002de0000 RDI: 0000000000000094 RBP: ffff888013c9a000 R08: 0000000000000000 R09: fffffbfff3f9cc6a R10: ffffc900010476e8 R11: fffffbfff3f9cc69 R12: 0000000000000001 R13: 000000000000000a R14: ffff888013c9af54 R15: ffff888013c9ad08 FS: 00007ffa984ab580(0000) GS:ffff88801fe00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055a6384136c8 CR3: 000000003bbe6003 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: encx24j600_spi_probe drivers/net/ethernet/microchip/encx24j600.c:459 spi_probe drivers/spi/spi.c:397 really_probe drivers/base/dd.c:517 __driver_probe_device drivers/base/dd.c:751 driver_probe_device drivers/base/dd.c:782 __device_attach_driver drivers/base/dd.c:899 bus_for_each_drv drivers/base/bus.c:427 __device_attach drivers/base/dd.c:971 bus_probe_device drivers/base/bus.c:487 device_add drivers/base/core.c:3364 __spi_add_device drivers/spi/spi.c:599 spi_add_device drivers/spi/spi.c:641 spi_new_device drivers/spi/spi.c:717 new_device_store+0x18c/0x1f1 [spi_stub 4e02719357f1ff33f5a43d00630982840568e85e] dev_attr_store drivers/base/core.c:2074 sysfs_kf_write fs/sysfs/file.c:139 kernfs_fop_write_iter fs/kernfs/file.c:300 new_sync_write fs/read_write.c:508 (discriminator 4) vfs_write fs/read_write.c:594 ksys_write fs/read_write.c:648 do_syscall_64 arch/x86/entry/common.c:50 entry_SYSCALL_64_after_hwframe arch/x86/entry/entry_64.S:113
Add error check in devm_regmap_init_encx24j600 to avoid this situation.(CVE-2021-47440)
In the Linux kernel, the following vulnerability has been resolved:
can: peak_pci: peak_pci_remove(): fix UAF
When remove the module peek_pci, referencing 'chan' again after releasing 'dev' will cause UAF.
Fix this by releasing 'dev' later.
The following log reveals it:
[ 35.961814 ] BUG: KASAN: use-after-free in peak_pci_remove+0x16f/0x270 [peak_pci] [ 35.963414 ] Read of size 8 at addr ffff888136998ee8 by task modprobe/5537 [ 35.965513 ] Call Trace: [ 35.965718 ] dump_stack_lvl+0xa8/0xd1 [ 35.966028 ] print_address_description+0x87/0x3b0 [ 35.966420 ] kasan_report+0x172/0x1c0 [ 35.966725 ] ? peak_pci_remove+0x16f/0x270 [peak_pci] [ 35.967137 ] ? trace_irq_enable_rcuidle+0x10/0x170 [ 35.967529 ] ? peak_pci_remove+0x16f/0x270 [peak_pci] [ 35.967945 ] __asan_report_load8_noabort+0x14/0x20 [ 35.968346 ] peak_pci_remove+0x16f/0x270 [peak_pci] [ 35.968752 ] pci_device_remove+0xa9/0x250(CVE-2021-47456)
In the Linux kernel, the following vulnerability has been resolved:
isdn: mISDN: Fix sleeping function called from invalid context
The driver can call card->isac.release() function from an atomic context.
Fix this by calling this function after releasing the lock.
The following log reveals it:
[ 44.168226 ] BUG: sleeping function called from invalid context at kernel/workqueue.c:3018 [ 44.168941 ] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 5475, name: modprobe [ 44.169574 ] INFO: lockdep is turned off. [ 44.169899 ] irq event stamp: 0 [ 44.170160 ] hardirqs last enabled at (0): [<0000000000000000>] 0x0 [ 44.170627 ] hardirqs last disabled at (0): [<ffffffff814209ed>] copy_process+0x132d/0x3e00 [ 44.171240 ] softirqs last enabled at (0): [<ffffffff81420a1a>] copy_process+0x135a/0x3e00 [ 44.171852 ] softirqs last disabled at (0): [<0000000000000000>] 0x0 [ 44.172318 ] Preemption disabled at: [ 44.172320 ] [<ffffffffa009b0a9>] nj_release+0x69/0x500 [netjet] [ 44.174441 ] Call Trace: [ 44.174630 ] dump_stack_lvl+0xa8/0xd1 [ 44.174912 ] dump_stack+0x15/0x17 [ 44.175166 ] mightsleep+0x3a2/0x510 [ 44.175459 ] ? nj_release+0x69/0x500 [netjet] [ 44.175791 ] might_sleep+0x82/0xe0 [ 44.176063 ] ? start_flush_work+0x20/0x7b0 [ 44.176375 ] start_flush_work+0x33/0x7b0 [ 44.176672 ] ? trace_irq_enable_rcuidle+0x85/0x170 [ 44.177034 ] ? kasan_quarantine_put+0xaa/0x1f0 [ 44.177372 ] ? kasan_quarantine_put+0xaa/0x1f0 [ 44.177711 ] __flush_work+0x11a/0x1a0 [ 44.177991 ] ? flush_work+0x20/0x20 [ 44.178257 ] ? lock_release+0x13c/0x8f0 [ 44.178550 ] ? __kasan_check_write+0x14/0x20 [ 44.178872 ] ? do_raw_spin_lock+0x148/0x360 [ 44.179187 ] ? read_lock_is_recursive+0x20/0x20 [ 44.179530 ] ? __kasan_check_read+0x11/0x20 [ 44.179846 ] ? do_raw_spin_unlock+0x55/0x900 [ 44.180168 ] ? ____kasan_slab_free+0x116/0x140 [ 44.180505 ] ? _raw_spin_unlock_irqrestore+0x41/0x60 [ 44.180878 ] ? skb_queue_purge+0x1a3/0x1c0 [ 44.181189 ] ? kfree+0x13e/0x290 [ 44.181438 ] flush_work+0x17/0x20 [ 44.181695 ] mISDN_freedchannel+0xe8/0x100 [ 44.182006 ] isac_release+0x210/0x260 [mISDNipac] [ 44.182366 ] nj_release+0xf6/0x500 [netjet] [ 44.182685 ] nj_remove+0x48/0x70 [netjet] [ 44.182989 ] pci_device_remove+0xa9/0x250(CVE-2021-47468)
In the Linux kernel, the following vulnerability has been resolved:
comedi: vmk80xx: fix bulk-buffer overflow
The driver is using endpoint-sized buffers but must not assume that the tx and rx buffers are of equal size or a malicious device could overflow the slab-allocated receive buffer when doing bulk transfers.(CVE-2021-47474)
In the Linux kernel, the following vulnerability has been resolved:
net: batman-adv: fix error handling
Syzbot reported ODEBUG warning in batadv_nc_mesh_free(). The problem was in wrong error handling in batadv_mesh_init().
Before this patch batadv_mesh_init() was calling batadv_mesh_free() in case of any batadv_*_init() calls failure. This approach may work well, when there is some kind of indicator, which can tell which parts of batadv are initialized; but there isn't any.
All written above lead to cleaning up uninitialized fields. Even if we hide ODEBUG warning by initializing bat_priv->nc.work, syzbot was able to hit GPF in batadv_nc_purge_paths(), because hash pointer in still NULL. [1]
To fix these bugs we can unwind batadv_init() calls one by one. It is good approach for 2 reasons: 1) It fixes bugs on error handling path 2) It improves the performance, since we won't call unneeded batadv_free() functions.
So, this patch makes all batadv_init() clean up all allocated memory before returning with an error to no call correspoing batadv_free() and open-codes batadv_mesh_free() with proper order to avoid touching uninitialized fields.(CVE-2021-47482)
In the Linux kernel, the following vulnerability has been resolved:
regmap: Fix possible double-free in regcache_rbtree_exit()
In regcache_rbtree_insert_to_block(), when 'present' realloc failed, the 'blk' which is supposed to assign to 'rbnode->block' will be freed, so 'rbnode->block' points a freed memory, in the error handling path of regcache_rbtree_init(), 'rbnode->block' will be freed again in regcache_rbtree_exit(), KASAN will report double-free as follows:
BUG: KASAN: double-free or invalid-free in kfree+0xce/0x390 Call Trace: slab_free_freelist_hook+0x10d/0x240 kfree+0xce/0x390 regcache_rbtree_exit+0x15d/0x1a0 regcache_rbtree_init+0x224/0x2c0 regcache_init+0x88d/0x1310 __regmap_init+0x3151/0x4a80 __devm_regmap_init+0x7d/0x100 madera_spi_probe+0x10f/0x333 [madera_spi] spi_probe+0x183/0x210 really_probe+0x285/0xc30
To fix this, moving up the assignment of rbnode->block to immediately after the reallocation has succeeded so that the data structure stays valid even if the second reallocation fails.(CVE-2021-47483)
In the Linux kernel, the following vulnerability has been resolved:
IB/qib: Protect from buffer overflow in struct qib_user_sdma_pkt fields
Overflowing either addrlimit or bytes_togo can allow userspace to trigger a buffer overflow of kernel memory. Check for overflows in all the places doing math on user controlled buffers.(CVE-2021-47485)
In the Linux kernel, the following vulnerability has been resolved:
net/tls: Fix flipped sign in tls_err_abort() calls
sk->sk_err appears to expect a positive value, a convention that ktls doesn't always follow and that leads to memory corruption in other code. For instance,
[kworker]
tls_encrypt_done(..., err=<negative error from crypto request>)
tls_err_abort(.., err)
sk->sk_err = err;
[task]
splice_from_pipe_feed
...
tls_sw_do_sendpage
if (sk->sk_err) {
ret = -sk->sk_err; // ret is positive
splice_from_pipe_feed (continued)
ret = actor(...) // ret is still positive and interpreted as bytes
// written, resulting in underflow of buf->len and
// sd->len, leading to huge buf->offset and bogus
// addresses computed in later calls to actor()
Fix all tls_err_abort() callers to pass a negative error code consistently and centralize the error-prone sign flip there, throwing in a warning to catch future misuse and uninlining the function so it really does only warn once.(CVE-2021-47496)
In the Linux kernel, the following vulnerability has been resolved:
ALSA: pcm: oss: Limit the period size to 16MB
Set the practical limit to the period size (the fragment shift in OSS) instead of a full 31bit; a too large value could lead to the exhaust of memory as we allocate temporary buffers of the period size, too.
As of this patch, we set to 16MB limit, which should cover all use cases.(CVE-2021-47509)
In the Linux kernel, the following vulnerability has been resolved:
nfp: Fix memory leak in nfp_cpp_area_cache_add()
In line 800 (#1), nfp_cpp_area_alloc() allocates and initializes a CPP area structure. But in line 807 (#2), when the cache is allocated failed, this CPP area structure is not freed, which will result in memory leak.
We can fix it by freeing the CPP area when the cache is allocated failed (#2).
792 int nfp_cpp_area_cache_add(struct nfp_cpp cpp, size_t size) 793 { 794 struct nfp_cpp_area_cache cache; 795 struct nfp_cpp_area *area;
800 area = nfp_cpp_area_alloc(cpp, NFP_CPP_ID(7, NFP_CPP_ACTION_RW, 0), 801 0, size); // #1: allocates and initializes
802 if (!area) 803 return -ENOMEM;
805 cache = kzalloc(sizeof(*cache), GFP_KERNEL); 806 if (!cache) 807 return -ENOMEM; // #2: missing free
817 return 0; 818 }(CVE-2021-47516)
In the Linux kernel, the following vulnerability has been resolved:
staging: rtl8192e: Fix use after free in _rtl92e_pci_disconnect()
The free_rtllib() function frees the "dev" pointer so there is use after free on the next line. Re-arrange things to avoid that.(CVE-2021-47571)
In the Linux kernel, the following vulnerability has been resolved:
soc: brcmstb: pm-arm: Fix refcount leak and __iomem leak bugs
In brcmstb_pm_probe(), there are two kinds of leak bugs:
(1) we need to add of_node_put() when for_each__matching_node() breaks (2) we need to add iounmap() for each iomap in fail path(CVE-2022-48693)
In the Linux kernel, the following vulnerability has been resolved:
mmc: mmc_spi: fix error handling in mmc_spi_probe()
If mmc_add_host() fails, it doesn't need to call mmc_remove_host(), or it will cause null-ptr-deref, because of deleting a not added device in mmc_remove_host().
To fix this, goto label 'fail_glue_init', if mmc_add_host() fails, and change the label 'fail_add_host' to 'fail_gpiod_request'.(CVE-2023-52708)
In the Linux kernel, the following vulnerability has been resolved:
net: USB: Fix wrong-direction WARNING in plusb.c
The syzbot fuzzer detected a bug in the plusb network driver: A zero-length control-OUT transfer was treated as a read instead of a write. In modern kernels this error provokes a WARNING:
usb 1-1: BOGUS control dir, pipe 80000280 doesn't match bRequestType c0 WARNING: CPU: 0 PID: 4645 at drivers/usb/core/urb.c:411 usb_submit_urb+0x14a7/0x1880 drivers/usb/core/urb.c:411 Modules linked in: CPU: 1 PID: 4645 Comm: dhcpcd Not tainted 6.2.0-rc6-syzkaller-00050-g9f266ccaa2f5 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/12/2023 RIP: 0010:usb_submit_urb+0x14a7/0x1880 drivers/usb/core/urb.c:411 ... Call Trace: <TASK> usb_start_wait_urb+0x101/0x4b0 drivers/usb/core/message.c:58 usb_internal_control_msg drivers/usb/core/message.c:102 [inline] usb_control_msg+0x320/0x4a0 drivers/usb/core/message.c:153 __usbnet_read_cmd+0xb9/0x390 drivers/net/usb/usbnet.c:2010 usbnet_read_cmd+0x96/0xf0 drivers/net/usb/usbnet.c:2068 pl_vendor_req drivers/net/usb/plusb.c:60 [inline] pl_set_QuickLink_features drivers/net/usb/plusb.c:75 [inline] pl_reset+0x2f/0xf0 drivers/net/usb/plusb.c:85 usbnet_open+0xcc/0x5d0 drivers/net/usb/usbnet.c:889 __dev_open+0x297/0x4d0 net/core/dev.c:1417 __dev_change_flags+0x587/0x750 net/core/dev.c:8530 dev_change_flags+0x97/0x170 net/core/dev.c:8602 devinet_ioctl+0x15a2/0x1d70 net/ipv4/devinet.c:1147 inet_ioctl+0x33f/0x380 net/ipv4/af_inet.c:979 sock_do_ioctl+0xcc/0x230 net/socket.c:1169 sock_ioctl+0x1f8/0x680 net/socket.c:1286 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl fs/ioctl.c:856 [inline] __x64_sys_ioctl+0x197/0x210 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd
The fix is to call usbnet_write_cmd() instead of usbnet_read_cmd() and remove the USB_DIR_IN flag.(CVE-2023-52742)
In the Linux kernel, the following vulnerability has been resolved:
IB/hfi1: Restore allocated resources on failed copyout
Fix a resource leak if an error occurs.(CVE-2023-52747)
In the Linux kernel, the following vulnerability has been resolved:
media: gspca: cpia1: shift-out-of-bounds in set_flicker
Syzkaller reported the following issue: UBSAN: shift-out-of-bounds in drivers/media/usb/gspca/cpia1.c:1031:27 shift exponent 245 is too large for 32-bit type 'int'
When the value of the variable "sd->params.exposure.gain" exceeds the number of bits in an integer, a shift-out-of-bounds error is reported. It is triggered because the variable "currentexp" cannot be left-shifted by more than the number of bits in an integer. In order to avoid invalid range during left-shift, the conditional expression is added.(CVE-2023-52764)
In the Linux kernel, the following vulnerability has been resolved:
fs/jfs: Add check for negative db_l2nbperpage
l2nbperpage is log2(number of blks per page), and the minimum legal value should be 0, not negative.
In the case of l2nbperpage being negative, an error will occur when subsequently used as shift exponent.
Syzbot reported this bug:
UBSAN: shift-out-of-bounds in fs/jfs/jfs_dmap.c:799:12 shift exponent -16777216 is negative(CVE-2023-52810)
In the Linux kernel, the following vulnerability has been resolved:
locking/ww_mutex/test: Fix potential workqueue corruption
In some cases running with the test-ww_mutex code, I was seeing odd behavior where sometimes it seemed flush_workqueue was returning before all the work threads were finished.
Often this would cause strange crashes as the mutexes would be freed while they were being used.
Looking at the code, there is a lifetime problem as the controlling thread that spawns the work allocates the "struct stress" structures that are passed to the workqueue threads. Then when the workqueue threads are finished, they free the stress struct that was passed to them.
Unfortunately the workqueue work_struct node is in the stress struct. Which means the work_struct is freed before the work thread returns and while flush_workqueue is waiting.
It seems like a better idea to have the controlling thread both allocate and free the stress structures, so that we can be sure we don't corrupt the workqueue by freeing the structure prematurely.
So this patch reworks the test to do so, and with this change I no longer see the early flush_workqueue returns.(CVE-2023-52836)
In the Linux kernel, the following vulnerability has been resolved:
llc: verify mac len before reading mac header
LLC reads the mac header with eth_hdr without verifying that the skb has an Ethernet header.
Syzbot was able to enter llc_rcv on a tun device. Tun can insert packets without mac len and with user configurable skb->protocol (passing a tun_pi header when not configuring IFF_NO_PI).
BUG: KMSAN: uninit-value in llc_station_ac_send_test_r net/llc/llc_station.c:81 [inline]
BUG: KMSAN: uninit-value in llc_station_rcv+0x6fb/0x1290 net/llc/llc_station.c:111
llc_station_ac_send_test_r net/llc/llc_station.c:81 [inline]
llc_station_rcv+0x6fb/0x1290 net/llc/llc_station.c:111
llc_rcv+0xc5d/0x14a0 net/llc/llc_input.c:218
__netif_receive_skb_one_core net/core/dev.c:5523 [inline]
__netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5637
netif_receive_skb_internal net/core/dev.c:5723 [inline]
netif_receive_skb+0x58/0x660 net/core/dev.c:5782
tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555
tun_get_user+0x54c5/0x69c0 drivers/net/tun.c:2002
Add a mac_len test before all three eth_hdr(skb) calls under net/llc.
There are further uses in include/net/llc_pdu.h. All these are protected by a test skb->protocol == ETH_P_802_2. Which does not protect against this tun scenario.
But the mac_len test added in this patch in llc_fixup_skb will indirectly protect those too. That is called from llc_rcv before any other LLC code.
It is tempting to just add a blanket mac_len check in llc_rcv, but not sure whether that could break valid LLC paths that do not assume an Ethernet header. 802.2 LLC may be used on top of non-802.3 protocols in principle. The below referenced commit shows that used to, on top of Token Ring.
At least one of the three eth_hdr uses goes back to before the start of git history. But the one that syzbot exercises is introduced in this commit. That commit is old enough (2008), that effectively all stable kernels should receive this.(CVE-2023-52843)
In the Linux kernel, the following vulnerability has been resolved:
clk: mediatek: clk-mt2701: Add check for mtk_alloc_clk_data
Add the check for the return value of mtk_alloc_clk_data() in order to avoid NULL pointer dereference.(CVE-2023-52875)
In the Linux kernel, the following vulnerability has been resolved:
tty: n_gsm: require CAP_NET_ADMIN to attach N_GSM0710 ldisc
Any unprivileged user can attach N_GSM0710 ldisc, but it requires CAP_NET_ADMIN to create a GSM network anyway.
Require initial namespace CAP_NET_ADMIN to do that.(CVE-2023-52880)
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Prevent deadlock while disabling aRFS
When disabling aRFS under the priv->state_lock, any scheduled
aRFS works are canceled using the cancel_work_sync function,
which waits for the work to end if it has already started.
However, while waiting for the work handler, the handler will
try to acquire the state_lock which is already acquired.
The worker acquires the lock to delete the rules if the state is down, which is not the worker's responsibility since disabling aRFS deletes the rules.
Add an aRFS state variable, which indicates whether the aRFS is enabled and prevent adding rules when the aRFS is disabled.
Kernel log:
====================================================== WARNING: possible circular locking dependency detected 6.7.0-rc4_net_next_mlx5_5483eb2 #1 Tainted: G I
ethtool/386089 is trying to acquire lock: ffff88810f21ce68 ((work_completion)(&rule->arfs_work)){+.+.}-{0:0}, at: __flush_work+0x74/0x4e0
but task is already holding lock: ffff8884a1808cc0 (&priv->state_lock){+.+.}-{3:3}, at: mlx5e_ethtool_set_channels+0x53/0x200 [mlx5_core]
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&priv->state_lock){+.+.}-{3:3}: __mutex_lock+0x80/0xc90 arfs_handle_work+0x4b/0x3b0 [mlx5_core] process_one_work+0x1dc/0x4a0 worker_thread+0x1bf/0x3c0 kthread+0xd7/0x100 ret_from_fork+0x2d/0x50 ret_from_fork_asm+0x11/0x20
-> #0 ((work_completion)(&rule->arfs_work)){+.+.}-{0:0}: __lock_acquire+0x17b4/0x2c80 lock_acquire+0xd0/0x2b0 __flush_work+0x7a/0x4e0 __cancel_work_timer+0x131/0x1c0 arfs_del_rules+0x143/0x1e0 [mlx5_core] mlx5e_arfs_disable+0x1b/0x30 [mlx5_core] mlx5e_ethtool_set_channels+0xcb/0x200 [mlx5_core] ethnl_set_channels+0x28f/0x3b0 ethnl_default_set_doit+0xec/0x240 genl_family_rcv_msg_doit+0xd0/0x120 genl_rcv_msg+0x188/0x2c0 netlink_rcv_skb+0x54/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x1a1/0x270 netlink_sendmsg+0x214/0x460 __sock_sendmsg+0x38/0x60 __sys_sendto+0x113/0x170 __x64_sys_sendto+0x20/0x30 do_syscall_64+0x40/0xe0 entry_SYSCALL_64_after_hwframe+0x46/0x4e
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&priv->state_lock); lock((work_completion)(&rule->arfs_work)); lock(&priv->state_lock); lock((work_completion)(&rule->arfs_work));
*** DEADLOCK ***
3 locks held by ethtool/386089: #0: ffffffff82ea7210 (cb_lock){++++}-{3:3}, at: genl_rcv+0x15/0x40 #1: ffffffff82e94c88 (rtnl_mutex){+.+.}-{3:3}, at: ethnl_default_set_doit+0xd3/0x240 #2: ffff8884a1808cc0 (&priv->state_lock){+.+.}-{3:3}, at: mlx5e_ethtool_set_channels+0x53/0x200 [mlx5_core]
stack backtrace: CPU: 15 PID: 386089 Comm: ethtool Tainted: G I 6.7.0-rc4_net_next_mlx5_5483eb2 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x60/0xa0 check_noncircular+0x144/0x160 __lock_acquire+0x17b4/0x2c80 lock_acquire+0xd0/0x2b0 ? __flush_work+0x74/0x4e0 ? save_trace+0x3e/0x360 ? __flush_work+0x74/0x4e0 __flush_work+0x7a/0x4e0 ? __flush_work+0x74/0x4e0 ? __lock_acquire+0xa78/0x2c80 ? lock_acquire+0xd0/0x2b0 ? mark_held_locks+0x49/0x70 __cancel_work_timer+0x131/0x1c0 ? mark_held_locks+0x49/0x70 arfs_del_rules+0x143/0x1e0 [mlx5_core] mlx5e_arfs_disable+0x1b/0x30 [mlx5_core] mlx5e_ethtool_set_channels+0xcb/0x200 [mlx5_core] ethnl_set_channels+0x28f/0x3b0 ethnl_default_set_doit+0xec/0x240 genl_family_rcv_msg_doit+0xd0/0x120 genl_rcv_msg+0x188/0x2c0 ? ethn ---truncated---(CVE-2024-27014)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: Fix potential data-race in __nft_obj_type_get()
nft_unregister_obj() can concurrent with __nft_obj_type_get(), and there is not any protection when iterate over nf_tables_objects list in __nft_obj_type_get(). Therefore, there is potential data-race of nf_tables_objects list entry.
Use list_for_each_entry_rcu() to iterate over nf_tables_objects list in __nft_obj_type_get(), and use rcu_read_lock() in the caller nft_obj_type_get() to protect the entire type query process.(CVE-2024-27019)
In the Linux kernel, the following vulnerability has been resolved:
phonet/pep: fix racy skb_queue_empty() use
The receive queues are protected by their respective spin-lock, not the socket lock. This could lead to skb_peek() unexpectedly returning NULL or a pointer to an already dequeued socket buffer.(CVE-2024-27402)
In the Linux kernel, the following vulnerability has been resolved:
soc: fsl: qbman: Use raw spinlock for cgr_lock
smp_call_function always runs its callback in hard IRQ context, even on PREEMPT_RT, where spinlocks can sleep. So we need to use a raw spinlock for cgr_lock to ensure we aren't waiting on a sleeping task.
Although this bug has existed for a while, it was not apparent until commit ef2a8d5478b9 ("net: dpaa: Adjust queue depth on rate change") which invokes smp_call_function_single via qman_update_cgr_safe every time a link goes up or down.(CVE-2024-35819)
In the Linux kernel, the following vulnerability has been resolved:
ubifs: Set page uptodate in the correct place
Page cache reads are lockless, so setting the freshly allocated page uptodate before we've overwritten it with the data it's supposed to have in it will allow a simultaneous reader to see old data. Move the call to SetPageUptodate into ubifs_write_end(), which is after we copied the new data into the page.(CVE-2024-35821)
In the Linux kernel, the following vulnerability has been resolved:
wifi: libertas: fix some memleaks in lbs_allocate_cmd_buffer()
In the for statement of lbs_allocate_cmd_buffer(), if the allocation of cmdarray[i].cmdbuf fails, both cmdarray and cmdarray[i].cmdbuf needs to be freed. Otherwise, there will be memleaks in lbs_allocate_cmd_buffer().(CVE-2024-35828)
In the Linux kernel, the following vulnerability has been resolved:
tcp: properly terminate timers for kernel sockets
We had various syzbot reports about tcp timers firing after the corresponding netns has been dismantled.
Fortunately Josef Bacik could trigger the issue more often, and could test a patch I wrote two years ago.
When TCP sockets are closed, we call inet_csk_clear_xmit_timers() to 'stop' the timers.
inet_csk_clear_xmit_timers() can be called from any context, including when socket lock is held. This is the reason it uses sk_stop_timer(), aka del_timer(). This means that ongoing timers might finish much later.
For user sockets, this is fine because each running timer holds a reference on the socket, and the user socket holds a reference on the netns.
For kernel sockets, we risk that the netns is freed before timer can complete, because kernel sockets do not hold reference on the netns.
This patch adds inet_csk_clear_xmit_timers_sync() function that using sk_stop_timer_sync() to make sure all timers are terminated before the kernel socket is released. Modules using kernel sockets close them in their netns exit() handler.
Also add sock_not_owned_by_me() helper to get LOCKDEP support : inet_csk_clear_xmit_timers_sync() must not be called while socket lock is held.
It is very possible we can revert in the future commit 3a58f13a881e ("net: rds: acquire refcount on TCP sockets") which attempted to solve the issue in rds only. (net/smc/af_smc.c and net/mptcp/subflow.c have similar code)
We probably can remove the check_net() tests from tcp_out_of_resources() and __tcp_close() in the future.(CVE-2024-35910)
In the Linux kernel, the following vulnerability has been resolved:
btrfs: send: handle path ref underflow in header iterate_inode_ref()
Change BUG_ON to proper error handling if building the path buffer fails. The pointers are not printed so we don't accidentally leak kernel addresses.(CVE-2024-35935)
In the Linux kernel, the following vulnerability has been resolved:
wifi: cfg80211: check A-MSDU format more carefully
If it looks like there's another subframe in the A-MSDU but the header isn't fully there, we can end up reading data out of bounds, only to discard later. Make this a bit more careful and check if the subframe header can even be present.(CVE-2024-35937)
In the Linux kernel, the following vulnerability has been resolved:
dyndbg: fix old BUG_ON in >control parser
Fix a BUG_ON from 2009. Even if it looks "unreachable" (I didn't really look), lets make sure by removing it, doing pr_err and return -EINVAL instead.(CVE-2024-35947)
In the Linux kernel, the following vulnerability has been resolved:
batman-adv: Avoid infinite loop trying to resize local TT
If the MTU of one of an attached interface becomes too small to transmit the local translation table then it must be resized to fit inside all fragments (when enabled) or a single packet.
But if the MTU becomes too low to transmit even the header + the VLAN specific part then the resizing of the local TT will never succeed. This can for example happen when the usable space is 110 bytes and 11 VLANs are on top of batman-adv. In this case, at least 116 byte would be needed. There will just be an endless spam of
batman_adv: batadv0: Forced to purge local tt entries to fit new maximum fragment MTU (110)
in the log but the function will never finish. Problem here is that the timeout will be halved all the time and will then stagnate at 0 and therefore never be able to reduce the table even more.
There are other scenarios possible with a similar result. The number of BATADV_TT_CLIENT_NOPURGE entries in the local TT can for example be too high to fit inside a packet. Such a scenario can therefore happen also with only a single VLAN + 7 non-purgable addresses - requiring at least 120 bytes.
While this should be handled proactively when:
- interface with too low MTU is added
- VLAN is added
- non-purgeable local mac is added
- MTU of an attached interface is reduced
- fragmentation setting gets disabled (which most likely requires dropping attached interfaces)
not all of these scenarios can be prevented because batman-adv is only consuming events without the the possibility to prevent these actions (non-purgable MAC address added, MTU of an attached interface is reduced). It is therefore necessary to also make sure that the code is able to handle also the situations when there were already incompatible system configuration are present.(CVE-2024-35982)
In the Linux kernel, the following vulnerability has been resolved:
tty: n_gsm: fix possible out-of-bounds in gsm0_receive()
Assuming the following: - side A configures the n_gsm in basic option mode - side B sends the header of a basic option mode frame with data length 1 - side A switches to advanced option mode - side B sends 2 data bytes which exceeds gsm->len Reason: gsm->len is not used in advanced option mode. - side A switches to basic option mode - side B keeps sending until gsm0_receive() writes past gsm->buf Reason: Neither gsm->state nor gsm->len have been reset after reconfiguration.
Fix this by changing gsm->count to gsm->len comparison from equal to less than. Also add upper limit checks against the constant MAX_MRU in gsm0_receive() and gsm1_receive() to harden against memory corruption of gsm->len and gsm->mru.
All other checks remain as we still need to limit the data according to the user configuration and actual payload size.(CVE-2024-36016)
In the Linux kernel, the following vulnerability has been resolved:
tipc: fix UAF in error path
Sam Page (sam4k) working with Trend Micro Zero Day Initiative reported a UAF in the tipc_buf_append() error path:
BUG: KASAN: slab-use-after-free in kfree_skb_list_reason+0x47e/0x4c0 linux/net/core/skbuff.c:1183 Read of size 8 at addr ffff88804d2a7c80 by task poc/8034
CPU: 1 PID: 8034 Comm: poc Not tainted 6.8.2 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-debian-1.16.0-5 04/01/2014 Call Trace: <IRQ> __dump_stack linux/lib/dump_stack.c:88 dump_stack_lvl+0xd9/0x1b0 linux/lib/dump_stack.c:106 print_address_description linux/mm/kasan/report.c:377 print_report+0xc4/0x620 linux/mm/kasan/report.c:488 kasan_report+0xda/0x110 linux/mm/kasan/report.c:601 kfree_skb_list_reason+0x47e/0x4c0 linux/net/core/skbuff.c:1183 skb_release_data+0x5af/0x880 linux/net/core/skbuff.c:1026 skb_release_all linux/net/core/skbuff.c:1094 __kfree_skb linux/net/core/skbuff.c:1108 kfree_skb_reason+0x12d/0x210 linux/net/core/skbuff.c:1144 kfree_skb linux/./include/linux/skbuff.h:1244 tipc_buf_append+0x425/0xb50 linux/net/tipc/msg.c:186 tipc_link_input+0x224/0x7c0 linux/net/tipc/link.c:1324 tipc_link_rcv+0x76e/0x2d70 linux/net/tipc/link.c:1824 tipc_rcv+0x45f/0x10f0 linux/net/tipc/node.c:2159 tipc_udp_recv+0x73b/0x8f0 linux/net/tipc/udp_media.c:390 udp_queue_rcv_one_skb+0xad2/0x1850 linux/net/ipv4/udp.c:2108 udp_queue_rcv_skb+0x131/0xb00 linux/net/ipv4/udp.c:2186 udp_unicast_rcv_skb+0x165/0x3b0 linux/net/ipv4/udp.c:2346 __udp4_lib_rcv+0x2594/0x3400 linux/net/ipv4/udp.c:2422 ip_protocol_deliver_rcu+0x30c/0x4e0 linux/net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x2e4/0x520 linux/net/ipv4/ip_input.c:233 NF_HOOK linux/./include/linux/netfilter.h:314 NF_HOOK linux/./include/linux/netfilter.h:308 ip_local_deliver+0x18e/0x1f0 linux/net/ipv4/ip_input.c:254 dst_input linux/./include/net/dst.h:461 ip_rcv_finish linux/net/ipv4/ip_input.c:449 NF_HOOK linux/./include/linux/netfilter.h:314 NF_HOOK linux/./include/linux/netfilter.h:308 ip_rcv+0x2c5/0x5d0 linux/net/ipv4/ip_input.c:569 __netif_receive_skb_one_core+0x199/0x1e0 linux/net/core/dev.c:5534 __netif_receive_skb+0x1f/0x1c0 linux/net/core/dev.c:5648 process_backlog+0x101/0x6b0 linux/net/core/dev.c:5976 __napi_poll.constprop.0+0xba/0x550 linux/net/core/dev.c:6576 napi_poll linux/net/core/dev.c:6645 net_rx_action+0x95a/0xe90 linux/net/core/dev.c:6781 __do_softirq+0x21f/0x8e7 linux/kernel/softirq.c:553 do_softirq linux/kernel/softirq.c:454 do_softirq+0xb2/0xf0 linux/kernel/softirq.c:441 </IRQ> <TASK> __local_bh_enable_ip+0x100/0x120 linux/kernel/softirq.c:381 local_bh_enable linux/./include/linux/bottom_half.h:33 rcu_read_unlock_bh linux/./include/linux/rcupdate.h:851 __dev_queue_xmit+0x871/0x3ee0 linux/net/core/dev.c:4378 dev_queue_xmit linux/./include/linux/netdevice.h:3169 neigh_hh_output linux/./include/net/neighbour.h:526 neigh_output linux/./include/net/neighbour.h:540 ip_finish_output2+0x169f/0x2550 linux/net/ipv4/ip_output.c:235 __ip_finish_output linux/net/ipv4/ip_output.c:313 __ip_finish_output+0x49e/0x950 linux/net/ipv4/ip_output.c:295 ip_finish_output+0x31/0x310 linux/net/ipv4/ip_output.c:323 NF_HOOK_COND linux/./include/linux/netfilter.h:303 ip_output+0x13b/0x2a0 linux/net/ipv4/ip_output.c:433 dst_output linux/./include/net/dst.h:451 ip_local_out linux/net/ipv4/ip_output.c:129 ip_send_skb+0x3e5/0x560 linux/net/ipv4/ip_output.c:1492 udp_send_skb+0x73f/0x1530 linux/net/ipv4/udp.c:963 udp_sendmsg+0x1a36/0x2b40 linux/net/ipv4/udp.c:1250 inet_sendmsg+0x105/0x140 linux/net/ipv4/af_inet.c:850 sock_sendmsg_nosec linux/net/socket.c:730 __sock_sendmsg linux/net/socket.c:745 __sys_sendto+0x42c/0x4e0 linux/net/socket.c:2191 __do_sys_sendto linux/net/socket.c:2203 __se_sys_sendto linux/net/socket.c:2199 __x64_sys_sendto+0xe0/0x1c0 linux/net/socket.c:2199 do_syscall_x64 linux/arch/x86/entry/common.c:52 do_syscall_ ---truncated---(CVE-2024-36886)
In the Linux kernel, the following vulnerability has been resolved:
ipv6: prevent NULL dereference in ip6_output()
According to syzbot, there is a chance that ip6_dst_idev() returns NULL in ip6_output(). Most places in IPv6 stack deal with a NULL idev just fine, but not here.
syzbot reported:
general protection fault, probably for non-canonical address 0xdffffc00000000bc: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x00000000000005e0-0x00000000000005e7] CPU: 0 PID: 9775 Comm: syz-executor.4 Not tainted 6.9.0-rc5-syzkaller-00157-g6a30653b604a #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 RIP: 0010:ip6_output+0x231/0x3f0 net/ipv6/ip6_output.c:237 Code: 3c 1e 00 49 89 df 74 08 4c 89 ef e8 19 58 db f7 48 8b 44 24 20 49 89 45 00 49 89 c5 48 8d 9d e0 05 00 00 48 89 d8 48 c1 e8 03 <42> 0f b6 04 38 84 c0 4c 8b 74 24 28 0f 85 61 01 00 00 8b 1b 31 ff RSP: 0018:ffffc9000927f0d8 EFLAGS: 00010202 RAX: 00000000000000bc RBX: 00000000000005e0 RCX: 0000000000040000 RDX: ffffc900131f9000 RSI: 0000000000004f47 RDI: 0000000000004f48 RBP: 0000000000000000 R08: ffffffff8a1f0b9a R09: 1ffffffff1f51fad R10: dffffc0000000000 R11: fffffbfff1f51fae R12: ffff8880293ec8c0 R13: ffff88805d7fc000 R14: 1ffff1100527d91a R15: dffffc0000000000 FS: 00007f135c6856c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000080 CR3: 0000000064096000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> NF_HOOK include/linux/netfilter.h:314 [inline] ip6_xmit+0xefe/0x17f0 net/ipv6/ip6_output.c:358 sctp_v6_xmit+0x9f2/0x13f0 net/sctp/ipv6.c:248 sctp_packet_transmit+0x26ad/0x2ca0 net/sctp/output.c:653 sctp_packet_singleton+0x22c/0x320 net/sctp/outqueue.c:783 sctp_outq_flush_ctrl net/sctp/outqueue.c:914 [inline] sctp_outq_flush+0x6d5/0x3e20 net/sctp/outqueue.c:1212 sctp_side_effects net/sctp/sm_sideeffect.c:1198 [inline] sctp_do_sm+0x59cc/0x60c0 net/sctp/sm_sideeffect.c:1169 sctp_primitive_ASSOCIATE+0x95/0xc0 net/sctp/primitive.c:73 __sctp_connect+0x9cd/0xe30 net/sctp/socket.c:1234 sctp_connect net/sctp/socket.c:4819 [inline] sctp_inet_connect+0x149/0x1f0 net/sctp/socket.c:4834 __sys_connect_file net/socket.c:2048 [inline] __sys_connect+0x2df/0x310 net/socket.c:2065 __do_sys_connect net/socket.c:2075 [inline] __se_sys_connect net/socket.c:2072 [inline] __x64_sys_connect+0x7a/0x90 net/socket.c:2072 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2024-36901)
In the Linux kernel, the following vulnerability has been resolved:
tcp: defer shutdown(SEND_SHUTDOWN) for TCP_SYN_RECV sockets
TCP_SYN_RECV state is really special, it is only used by cross-syn connections, mostly used by fuzzers.
In the following crash [1], syzbot managed to trigger a divide by zero in tcp_rcv_space_adjust()
A socket makes the following state transitions, without ever calling tcp_init_transfer(), meaning tcp_init_buffer_space() is also not called.
TCP_CLOSE
connect() TCP_SYN_SENT TCP_SYN_RECV shutdown() -> tcp_shutdown(sk, SEND_SHUTDOWN) TCP_FIN_WAIT1
To fix this issue, change tcp_shutdown() to not perform a TCP_SYN_RECV -> TCP_FIN_WAIT1 transition, which makes no sense anyway.
When tcp_rcv_state_process() later changes socket state from TCP_SYN_RECV to TCP_ESTABLISH, then look at sk->sk_shutdown to finally enter TCP_FIN_WAIT1 state, and send a FIN packet from a sane socket state.
This means tcp_send_fin() can now be called from BH context, and must use GFP_ATOMIC allocations.
[1] divide error: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 1 PID: 5084 Comm: syz-executor358 Not tainted 6.9.0-rc6-syzkaller-00022-g98369dccd2f8 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 RIP: 0010:tcp_rcv_space_adjust+0x2df/0x890 net/ipv4/tcp_input.c:767 Code: e3 04 4c 01 eb 48 8b 44 24 38 0f b6 04 10 84 c0 49 89 d5 0f 85 a5 03 00 00 41 8b 8e c8 09 00 00 89 e8 29 c8 48 0f af c3 31 d2 <48> f7 f1 48 8d 1c 43 49 8d 96 76 08 00 00 48 89 d0 48 c1 e8 03 48 RSP: 0018:ffffc900031ef3f0 EFLAGS: 00010246 RAX: 0c677a10441f8f42 RBX: 000000004fb95e7e RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000027d4b11f R08: ffffffff89e535a4 R09: 1ffffffff25e6ab7 R10: dffffc0000000000 R11: ffffffff8135e920 R12: ffff88802a9f8d30 R13: dffffc0000000000 R14: ffff88802a9f8d00 R15: 1ffff1100553f2da FS: 00005555775c0380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f1155bf2304 CR3: 000000002b9f2000 CR4: 0000000000350ef0 Call Trace: <TASK> tcp_recvmsg_locked+0x106d/0x25a0 net/ipv4/tcp.c:2513 tcp_recvmsg+0x25d/0x920 net/ipv4/tcp.c:2578 inet6_recvmsg+0x16a/0x730 net/ipv6/af_inet6.c:680 sock_recvmsg_nosec net/socket.c:1046 [inline] sock_recvmsg+0x109/0x280 net/socket.c:1068 _sysrecvmsg+0x1db/0x470 net/socket.c:2803 _sys_recvmsg net/socket.c:2845 [inline] do_recvmmsg+0x474/0xae0 net/socket.c:2939 __sys_recvmmsg net/socket.c:3018 [inline] __do_sys_recvmmsg net/socket.c:3041 [inline] __se_sys_recvmmsg net/socket.c:3034 [inline] __x64_sys_recvmmsg+0x199/0x250 net/socket.c:3034 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7faeb6363db9 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 c1 17 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffcc1997168 EFLAGS: 00000246 ORIG_RAX: 000000000000012b RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007faeb6363db9 RDX: 0000000000000001 RSI: 0000000020000bc0 RDI: 0000000000000005 RBP: 0000000000000000 R08: 0000000000000000 R09: 000000000000001c R10: 0000000000000122 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000001(CVE-2024-36905)
In the Linux kernel, the following vulnerability has been resolved:
scsi: bnx2fc: Remove spin_lock_bh while releasing resources after upload
The session resources are used by FW and driver when session is offloaded, once session is uploaded these resources are not used. The lock is not required as these fields won't be used any longer. The offload and upload calls are sequential, hence lock is not required.
This will suppress following BUG_ON():
[ 449.843143] ------------[ cut here ]------------ [ 449.848302] kernel BUG at mm/vmalloc.c:2727! [ 449.853072] invalid opcode: 0000 [#1] PREEMPT SMP PTI [ 449.858712] CPU: 5 PID: 1996 Comm: kworker/u24:2 Not tainted 5.14.0-118.el9.x86_64 #1 Rebooting. [ 449.867454] Hardware name: Dell Inc. PowerEdge R730/0WCJNT, BIOS 2.3.4 11/08/2016 [ 449.876966] Workqueue: fc_rport_eq fc_rport_work [libfc] [ 449.882910] RIP: 0010:vunmap+0x2e/0x30 [ 449.887098] Code: 00 65 8b 05 14 a2 f0 4a a9 00 ff ff 00 75 1b 55 48 89 fd e8 34 36 79 00 48 85 ed 74 0b 48 89 ef 31 f6 5d e9 14 fc ff ff 5d c3 <0f> 0b 0f 1f 44 00 00 41 57 41 56 49 89 ce 41 55 49 89 fd 41 54 41 [ 449.908054] RSP: 0018:ffffb83d878b3d68 EFLAGS: 00010206 [ 449.913887] RAX: 0000000080000201 RBX: ffff8f4355133550 RCX: 000000000d400005 [ 449.921843] RDX: 0000000000000001 RSI: 0000000000001000 RDI: ffffb83da53f5000 [ 449.929808] RBP: ffff8f4ac6675800 R08: ffffb83d878b3d30 R09: 00000000000efbdf [ 449.937774] R10: 0000000000000003 R11: ffff8f434573e000 R12: 0000000000001000 [ 449.945736] R13: 0000000000001000 R14: ffffb83da53f5000 R15: ffff8f43d4ea3ae0 [ 449.953701] FS: 0000000000000000(0000) GS:ffff8f529fc80000(0000) knlGS:0000000000000000 [ 449.962732] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 449.969138] CR2: 00007f8cf993e150 CR3: 0000000efbe10003 CR4: 00000000003706e0 [ 449.977102] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 449.985065] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 449.993028] Call Trace: [ 449.995756] __iommu_dma_free+0x96/0x100 [ 450.000139] bnx2fc_free_session_resc+0x67/0x240 [bnx2fc] [ 450.006171] bnx2fc_upload_session+0xce/0x100 [bnx2fc] [ 450.011910] bnx2fc_rport_event_handler+0x9f/0x240 [bnx2fc] [ 450.018136] fc_rport_work+0x103/0x5b0 [libfc] [ 450.023103] process_one_work+0x1e8/0x3c0 [ 450.027581] worker_thread+0x50/0x3b0 [ 450.031669] ? rescuer_thread+0x370/0x370 [ 450.036143] kthread+0x149/0x170 [ 450.039744] ? set_kthread_struct+0x40/0x40 [ 450.044411] ret_from_fork+0x22/0x30 [ 450.048404] Modules linked in: vfat msdos fat xfs nfs_layout_nfsv41_files rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver dm_service_time qedf qed crc8 bnx2fc libfcoe libfc scsi_transport_fc intel_rapl_msr intel_rapl_common x86_pkg_temp_thermal intel_powerclamp dcdbas rapl intel_cstate intel_uncore mei_me pcspkr mei ipmi_ssif lpc_ich ipmi_si fuse zram ext4 mbcache jbd2 loop nfsv3 nfs_acl nfs lockd grace fscache netfs irdma ice sd_mod t10_pi sg ib_uverbs ib_core 8021q garp mrp stp llc mgag200 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt mxm_wmi fb_sys_fops cec crct10dif_pclmul ahci crc32_pclmul bnx2x drm ghash_clmulni_intel libahci rfkill i40e libata megaraid_sas mdio wmi sunrpc lrw dm_crypt dm_round_robin dm_multipath dm_snapshot dm_bufio dm_mirror dm_region_hash dm_log dm_zero dm_mod linear raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx raid6_pq libcrc32c crc32c_intel raid1 raid0 iscsi_ibft squashfs be2iscsi bnx2i cnic uio cxgb4i cxgb4 tls [ 450.048497] libcxgbi libcxgb qla4xxx iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi edd ipmi_devintf ipmi_msghandler [ 450.159753] ---[ end trace 712de2c57c64abc8 ]---(CVE-2024-36919)
In the Linux kernel, the following vulnerability has been resolved:
bna: ensure the copied buf is NUL terminated
Currently, we allocate a nbytes-sized kernel buffer and copy nbytes from userspace to that buffer. Later, we use sscanf on this buffer but we don't ensure that the string is terminated inside the buffer, this can lead to OOB read when using sscanf. Fix this issue by using memdup_user_nul instead of memdup_user.(CVE-2024-36934)
In the Linux kernel, the following vulnerability has been resolved:
scsi: lpfc: Move NPIV's transport unregistration to after resource clean up
There are cases after NPIV deletion where the fabric switch still believes the NPIV is logged into the fabric. This occurs when a vport is unregistered before the Remove All DA_ID CT and LOGO ELS are sent to the fabric.
Currently fc_remove_host(), which calls dev_loss_tmo for all D_IDs including the fabric D_ID, removes the last ndlp reference and frees the ndlp rport object. This sometimes causes the race condition where the final DA_ID and LOGO are skipped from being sent to the fabric switch.
Fix by moving the fc_remove_host() and scsi_remove_host() calls after DA_ID and LOGO are sent.(CVE-2024-36952)
In the Linux kernel, the following vulnerability has been resolved:
drm/vmwgfx: Fix invalid reads in fence signaled events
Correctly set the length of the drm_event to the size of the structure that's actually used.
The length of the drm_event was set to the parent structure instead of to the drm_vmw_event_fence which is supposed to be read. drm_read uses the length parameter to copy the event to the user space thus resuling in oob reads.(CVE-2024-36960)
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"python3-perf-4.19.90-2406.3.0.0282.oe2003sp4.aarch64.rpm",
"bpftool-4.19.90-2406.3.0.0282.oe2003sp4.aarch64.rpm",
"python2-perf-debuginfo-4.19.90-2406.3.0.0282.oe2003sp4.aarch64.rpm",
"kernel-tools-4.19.90-2406.3.0.0282.oe2003sp4.aarch64.rpm",
"kernel-4.19.90-2406.3.0.0282.oe2003sp4.aarch64.rpm",
"kernel-devel-4.19.90-2406.3.0.0282.oe2003sp4.aarch64.rpm",
"perf-4.19.90-2406.3.0.0282.oe2003sp4.aarch64.rpm",
"kernel-tools-devel-4.19.90-2406.3.0.0282.oe2003sp4.aarch64.rpm",
"perf-debuginfo-4.19.90-2406.3.0.0282.oe2003sp4.aarch64.rpm",
"python3-perf-debuginfo-4.19.90-2406.3.0.0282.oe2003sp4.aarch64.rpm",
"kernel-tools-debuginfo-4.19.90-2406.3.0.0282.oe2003sp4.aarch64.rpm",
"kernel-debugsource-4.19.90-2406.3.0.0282.oe2003sp4.aarch64.rpm",
"python2-perf-4.19.90-2406.3.0.0282.oe2003sp4.aarch64.rpm",
"kernel-source-4.19.90-2406.3.0.0282.oe2003sp4.aarch64.rpm",
"kernel-debuginfo-4.19.90-2406.3.0.0282.oe2003sp4.aarch64.rpm",
"bpftool-debuginfo-4.19.90-2406.3.0.0282.oe2003sp4.aarch64.rpm"
],
"src": [
"kernel-4.19.90-2406.3.0.0282.oe2003sp4.src.rpm"
],
"x86_64": [
"python3-perf-debuginfo-4.19.90-2406.3.0.0282.oe2003sp4.x86_64.rpm",
"kernel-tools-devel-4.19.90-2406.3.0.0282.oe2003sp4.x86_64.rpm",
"kernel-4.19.90-2406.3.0.0282.oe2003sp4.x86_64.rpm",
"kernel-debugsource-4.19.90-2406.3.0.0282.oe2003sp4.x86_64.rpm",
"kernel-tools-4.19.90-2406.3.0.0282.oe2003sp4.x86_64.rpm",
"perf-debuginfo-4.19.90-2406.3.0.0282.oe2003sp4.x86_64.rpm",
"perf-4.19.90-2406.3.0.0282.oe2003sp4.x86_64.rpm",
"bpftool-4.19.90-2406.3.0.0282.oe2003sp4.x86_64.rpm",
"kernel-devel-4.19.90-2406.3.0.0282.oe2003sp4.x86_64.rpm",
"python2-perf-4.19.90-2406.3.0.0282.oe2003sp4.x86_64.rpm",
"python2-perf-debuginfo-4.19.90-2406.3.0.0282.oe2003sp4.x86_64.rpm",
"python3-perf-4.19.90-2406.3.0.0282.oe2003sp4.x86_64.rpm",
"kernel-tools-debuginfo-4.19.90-2406.3.0.0282.oe2003sp4.x86_64.rpm",
"kernel-debuginfo-4.19.90-2406.3.0.0282.oe2003sp4.x86_64.rpm",
"kernel-source-4.19.90-2406.3.0.0282.oe2003sp4.x86_64.rpm",
"bpftool-debuginfo-4.19.90-2406.3.0.0282.oe2003sp4.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:20.03-LTS-SP4",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-20.03-LTS-SP4"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.19.90-2406.3.0.0282.oe2003sp4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nPCI: aardvark: Fix kernel panic during PIO transfer\r\n\r\nTrying to start a new PIO transfer by writing value 0 in PIO_START register\nwhen previous transfer has not yet completed (which is indicated by value 1\nin PIO_START) causes an External Abort on CPU, which results in kernel\npanic:\r\n\r\n SError Interrupt on CPU0, code 0xbf000002 -- SError\n Kernel panic - not syncing: Asynchronous SError Interrupt\r\n\r\nTo prevent kernel panic, it is required to reject a new PIO transfer when\nprevious one has not finished yet.\r\n\r\nIf previous PIO transfer is not finished yet, the kernel may issue a new\nPIO request only if the previous PIO transfer timed out.\r\n\r\nIn the past the root cause of this issue was incorrectly identified (as it\noften happens during link retraining or after link down event) and special\nhack was implemented in Trusted Firmware to catch all SError events in EL3,\nto ignore errors with code 0xbf000002 and not forwarding any other errors\nto kernel and instead throw panic from EL3 Trusted Firmware handler.\r\n\r\nLinks to discussion and patches about this issue:\nhttps://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/?id=3c7dcdac5c50\nhttps://lore.kernel.org/linux-pci/20190316161243.29517-1-repk@triplefau.lt/\nhttps://lore.kernel.org/linux-pci/971be151d24312cc533989a64bd454b4@www.loen.fr/\nhttps://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/1541\r\n\r\nBut the real cause was the fact that during link retraining or after link\ndown event the PIO transfer may take longer time, up to the 1.44s until it\ntimes out. This increased probability that a new PIO transfer would be\nissued by kernel while previous one has not finished yet.\r\n\r\nAfter applying this change into the kernel, it is possible to revert the\nmentioned TF-A hack and SError events do not have to be caught in TF-A EL3.(CVE-2021-47229)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nphy: phy-mtk-tphy: Fix some resource leaks in mtk_phy_init()\r\n\r\nUse clk_disable_unprepare() in the error path of mtk_phy_init() to fix\nsome resource leaks.(CVE-2021-47234)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: rds: fix memory leak in rds_recvmsg\r\n\r\nSyzbot reported memory leak in rds. The problem\nwas in unputted refcount in case of error.\r\n\r\nint rds_recvmsg(struct socket *sock, struct msghdr *msg, size_t size,\n\t\tint msg_flags)\n{\n...\r\n\r\n\tif (!rds_next_incoming(rs, \u0026amp;inc)) {\n\t\t...\n\t}\r\n\r\nAfter this \u0026quot;if\u0026quot; inc refcount incremented and\r\n\r\n\tif (rds_cmsg_recv(inc, msg, rs)) {\n\t\tret = -EFAULT;\n\t\tgoto out;\n\t}\n...\nout:\n\treturn ret;\n}\r\n\r\nin case of rds_cmsg_recv() fail the refcount won\u0026apos;t be\ndecremented. And it\u0026apos;s easy to see from ftrace log, that\nrds_inc_addref() don\u0026apos;t have rds_inc_put() pair in\nrds_recvmsg() after rds_cmsg_recv()\r\n\r\n 1) | rds_recvmsg() {\n 1) 3.721 us | rds_inc_addref();\n 1) 3.853 us | rds_message_inc_copy_to_user();\n 1) + 10.395 us | rds_cmsg_recv();\n 1) + 34.260 us | }(CVE-2021-47249)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: ieee802154: fix null deref in parse dev addr\r\n\r\nFix a logic error that could result in a null deref if the user sets\nthe mode incorrectly for the given addr type.(CVE-2021-47257)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: fix various gadget panics on 10gbps cabling\r\n\r\nusb_assign_descriptors() is called with 5 parameters,\nthe last 4 of which are the usb_descriptor_header for:\n full-speed (USB1.1 - 12Mbps [including USB1.0 low-speed @ 1.5Mbps),\n high-speed (USB2.0 - 480Mbps),\n super-speed (USB3.0 - 5Gbps),\n super-speed-plus (USB3.1 - 10Gbps).\r\n\r\nThe differences between full/high/super-speed descriptors are usually\nsubstantial (due to changes in the maximum usb block size from 64 to 512\nto 1024 bytes and other differences in the specs), while the difference\nbetween 5 and 10Gbps descriptors may be as little as nothing\n(in many cases the same tuning is simply good enough).\r\n\r\nHowever if a gadget driver calls usb_assign_descriptors() with\na NULL descriptor for super-speed-plus and is then used on a max 10gbps\nconfiguration, the kernel will crash with a null pointer dereference,\nwhen a 10gbps capable device port + cable + host port combination shows up.\n(This wouldn\u0026apos;t happen if the gadget max-speed was set to 5gbps, but\nit of course defaults to the maximum, and there\u0026apos;s no real reason to\nartificially limit it)\r\n\r\nThe fix is to simply use the 5gbps descriptor as the 10gbps descriptor,\nif a 10gbps descriptor wasn\u0026apos;t provided.\r\n\r\nObviously this won\u0026apos;t fix the problem if the 5gbps descriptor is also\nNULL, but such cases can\u0026apos;t be so trivially solved (and any such gadgets\nare unlikely to be used with USB3 ports any way).(CVE-2021-47267)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nALSA: seq: Fix race of snd_seq_timer_open()\r\n\r\nThe timer instance per queue is exclusive, and snd_seq_timer_open()\nshould have managed the concurrent accesses. It looks as if it\u0026apos;s\nchecking the already existing timer instance at the beginning, but\nit\u0026apos;s not right, because there is no protection, hence any later\nconcurrent call of snd_seq_timer_open() may override the timer\ninstance easily. This may result in UAF, as the leftover timer\ninstance can keep running while the queue itself gets closed, as\nspotted by syzkaller recently.\r\n\r\nFor avoiding the race, add a proper check at the assignment of\ntmr-\u0026gt;timeri again, and return -EBUSY if it\u0026apos;s been already registered.(CVE-2021-47281)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nigb: Fix use-after-free error during reset\r\n\r\nCleans the next descriptor to watch (next_to_watch) when cleaning the\nTX ring.\r\n\r\nFailure to do so can cause invalid memory accesses. If igb_poll() runs\nwhile the controller is reset this can lead to the driver try to free\na skb that was already freed.\r\n\r\n(The crash is harder to reproduce with the igb driver, but the same\npotential problem exists as the code is identical to igc)(CVE-2021-47301)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: ti: fix UAF in tlan_remove_one\r\n\r\npriv is netdev private data and it cannot be\nused after free_netdev() call. Using priv after free_netdev()\ncan cause UAF bug. Fix it by moving free_netdev() at the end of the\nfunction.(CVE-2021-47310)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwatchdog: Fix possible use-after-free by calling del_timer_sync()\r\n\r\nThis driver\u0026apos;s remove path calls del_timer(). However, that function\ndoes not wait until the timer handler finishes. This means that the\ntimer handler may still be running after the driver\u0026apos;s remove function\nhas finished, which would result in a use-after-free.\r\n\r\nFix by calling del_timer_sync(), which makes sure the timer handler\nhas finished, and unable to re-schedule itself.(CVE-2021-47321)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmisc/libmasm/module: Fix two use after free in ibmasm_init_one\r\n\r\nIn ibmasm_init_one, it calls ibmasm_init_remote_input_dev().\nInside ibmasm_init_remote_input_dev, mouse_dev and keybd_dev are\nallocated by input_allocate_device(), and assigned to\nsp-\u0026gt;remote.mouse_dev and sp-\u0026gt;remote.keybd_dev respectively.\r\n\r\nIn the err_free_devices error branch of ibmasm_init_one,\nmouse_dev and keybd_dev are freed by input_free_device(), and return\nerror. Then the execution runs into error_send_message error branch\nof ibmasm_init_one, where ibmasm_free_remote_input_dev(sp) is called\nto unregister the freed sp-\u0026gt;remote.mouse_dev and sp-\u0026gt;remote.keybd_dev.\r\n\r\nMy patch add a \u0026quot;error_init_remote\u0026quot; label to handle the error of\nibmasm_init_remote_input_dev(), to avoid the uaf bugs.(CVE-2021-47334)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: zr364xx: fix memory leak in zr364xx_start_readpipe\r\n\r\nsyzbot reported memory leak in zr364xx driver.\nThe problem was in non-freed urb in case of\nusb_submit_urb() fail.\r\n\r\nbacktrace:\n [\u0026lt;ffffffff82baedf6\u0026gt;] kmalloc include/linux/slab.h:561 [inline]\n [\u0026lt;ffffffff82baedf6\u0026gt;] usb_alloc_urb+0x66/0xe0 drivers/usb/core/urb.c:74\n [\u0026lt;ffffffff82f7cce8\u0026gt;] zr364xx_start_readpipe+0x78/0x130 drivers/media/usb/zr364xx/zr364xx.c:1022\n [\u0026lt;ffffffff84251dfc\u0026gt;] zr364xx_board_init drivers/media/usb/zr364xx/zr364xx.c:1383 [inline]\n [\u0026lt;ffffffff84251dfc\u0026gt;] zr364xx_probe+0x6a3/0x851 drivers/media/usb/zr364xx/zr364xx.c:1516\n [\u0026lt;ffffffff82bb6507\u0026gt;] usb_probe_interface+0x177/0x370 drivers/usb/core/driver.c:396\n [\u0026lt;ffffffff826018a9\u0026gt;] really_probe+0x159/0x500 drivers/base/dd.c:576(CVE-2021-47344)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/sched: Avoid data corruptions\r\n\r\nWait for all dependencies of a job to complete before\nkilling it to avoid data corruptions.(CVE-2021-47354)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: macb: fix use after free on rmmod\r\n\r\nplat_dev-\u0026gt;dev-\u0026gt;platform_data is released by platform_device_unregister(),\nuse of pclk and hclk is a use-after-free. Since device unregister won\u0026apos;t\nneed a clk device we adjust the function call sequence to fix this issue.\r\n\r\n[ 31.261225] BUG: KASAN: use-after-free in macb_remove+0x77/0xc6 [macb_pci]\n[ 31.275563] Freed by task 306:\n[ 30.276782] platform_device_release+0x25/0x80(CVE-2021-47372)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ni2c: acpi: fix resource leak in reconfiguration device addition\r\n\r\nacpi_i2c_find_adapter_by_handle() calls bus_find_device() which takes a\nreference on the adapter which is never released which will result in a\nreference count leak and render the adapter unremovable. Make sure to\nput the adapter after creating the client in the same manner that we do\nfor OF.\r\n\r\n[wsa: fixed title](CVE-2021-47425)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: encx24j600: check error in devm_regmap_init_encx24j600\r\n\r\ndevm_regmap_init may return error which caused by like out of memory,\nthis will results in null pointer dereference later when reading\nor writing register:\r\n\r\ngeneral protection fault in encx24j600_spi_probe\nKASAN: null-ptr-deref in range [0x0000000000000090-0x0000000000000097]\nCPU: 0 PID: 286 Comm: spi-encx24j600- Not tainted 5.15.0-rc2-00142-g9978db750e31-dirty #11 9c53a778c1306b1b02359f3c2bbedc0222cba652\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014\nRIP: 0010:regcache_cache_bypass drivers/base/regmap/regcache.c:540\nCode: 54 41 89 f4 55 53 48 89 fb 48 83 ec 08 e8 26 94 a8 fe 48 8d bb a0 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 \u0026lt;80\u0026gt; 3c 02 00 0f 85 4a 03 00 00 4c 8d ab b0 00 00 00 48 8b ab a0 00\nRSP: 0018:ffffc900010476b8 EFLAGS: 00010207\nRAX: dffffc0000000000 RBX: fffffffffffffff4 RCX: 0000000000000000\nRDX: 0000000000000012 RSI: ffff888002de0000 RDI: 0000000000000094\nRBP: ffff888013c9a000 R08: 0000000000000000 R09: fffffbfff3f9cc6a\nR10: ffffc900010476e8 R11: fffffbfff3f9cc69 R12: 0000000000000001\nR13: 000000000000000a R14: ffff888013c9af54 R15: ffff888013c9ad08\nFS: 00007ffa984ab580(0000) GS:ffff88801fe00000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 000055a6384136c8 CR3: 000000003bbe6003 CR4: 0000000000770ef0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nPKRU: 55555554\nCall Trace:\n encx24j600_spi_probe drivers/net/ethernet/microchip/encx24j600.c:459\n spi_probe drivers/spi/spi.c:397\n really_probe drivers/base/dd.c:517\n __driver_probe_device drivers/base/dd.c:751\n driver_probe_device drivers/base/dd.c:782\n __device_attach_driver drivers/base/dd.c:899\n bus_for_each_drv drivers/base/bus.c:427\n __device_attach drivers/base/dd.c:971\n bus_probe_device drivers/base/bus.c:487\n device_add drivers/base/core.c:3364\n __spi_add_device drivers/spi/spi.c:599\n spi_add_device drivers/spi/spi.c:641\n spi_new_device drivers/spi/spi.c:717\n new_device_store+0x18c/0x1f1 [spi_stub 4e02719357f1ff33f5a43d00630982840568e85e]\n dev_attr_store drivers/base/core.c:2074\n sysfs_kf_write fs/sysfs/file.c:139\n kernfs_fop_write_iter fs/kernfs/file.c:300\n new_sync_write fs/read_write.c:508 (discriminator 4)\n vfs_write fs/read_write.c:594\n ksys_write fs/read_write.c:648\n do_syscall_64 arch/x86/entry/common.c:50\n entry_SYSCALL_64_after_hwframe arch/x86/entry/entry_64.S:113\r\n\r\nAdd error check in devm_regmap_init_encx24j600 to avoid this situation.(CVE-2021-47440)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncan: peak_pci: peak_pci_remove(): fix UAF\r\n\r\nWhen remove the module peek_pci, referencing \u0026apos;chan\u0026apos; again after\nreleasing \u0026apos;dev\u0026apos; will cause UAF.\r\n\r\nFix this by releasing \u0026apos;dev\u0026apos; later.\r\n\r\nThe following log reveals it:\r\n\r\n[ 35.961814 ] BUG: KASAN: use-after-free in peak_pci_remove+0x16f/0x270 [peak_pci]\n[ 35.963414 ] Read of size 8 at addr ffff888136998ee8 by task modprobe/5537\n[ 35.965513 ] Call Trace:\n[ 35.965718 ] dump_stack_lvl+0xa8/0xd1\n[ 35.966028 ] print_address_description+0x87/0x3b0\n[ 35.966420 ] kasan_report+0x172/0x1c0\n[ 35.966725 ] ? peak_pci_remove+0x16f/0x270 [peak_pci]\n[ 35.967137 ] ? trace_irq_enable_rcuidle+0x10/0x170\n[ 35.967529 ] ? peak_pci_remove+0x16f/0x270 [peak_pci]\n[ 35.967945 ] __asan_report_load8_noabort+0x14/0x20\n[ 35.968346 ] peak_pci_remove+0x16f/0x270 [peak_pci]\n[ 35.968752 ] pci_device_remove+0xa9/0x250(CVE-2021-47456)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nisdn: mISDN: Fix sleeping function called from invalid context\r\n\r\nThe driver can call card-\u0026gt;isac.release() function from an atomic\ncontext.\r\n\r\nFix this by calling this function after releasing the lock.\r\n\r\nThe following log reveals it:\r\n\r\n[ 44.168226 ] BUG: sleeping function called from invalid context at kernel/workqueue.c:3018\n[ 44.168941 ] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 5475, name: modprobe\n[ 44.169574 ] INFO: lockdep is turned off.\n[ 44.169899 ] irq event stamp: 0\n[ 44.170160 ] hardirqs last enabled at (0): [\u0026lt;0000000000000000\u0026gt;] 0x0\n[ 44.170627 ] hardirqs last disabled at (0): [\u0026lt;ffffffff814209ed\u0026gt;] copy_process+0x132d/0x3e00\n[ 44.171240 ] softirqs last enabled at (0): [\u0026lt;ffffffff81420a1a\u0026gt;] copy_process+0x135a/0x3e00\n[ 44.171852 ] softirqs last disabled at (0): [\u0026lt;0000000000000000\u0026gt;] 0x0\n[ 44.172318 ] Preemption disabled at:\n[ 44.172320 ] [\u0026lt;ffffffffa009b0a9\u0026gt;] nj_release+0x69/0x500 [netjet]\n[ 44.174441 ] Call Trace:\n[ 44.174630 ] dump_stack_lvl+0xa8/0xd1\n[ 44.174912 ] dump_stack+0x15/0x17\n[ 44.175166 ] ___might_sleep+0x3a2/0x510\n[ 44.175459 ] ? nj_release+0x69/0x500 [netjet]\n[ 44.175791 ] __might_sleep+0x82/0xe0\n[ 44.176063 ] ? start_flush_work+0x20/0x7b0\n[ 44.176375 ] start_flush_work+0x33/0x7b0\n[ 44.176672 ] ? trace_irq_enable_rcuidle+0x85/0x170\n[ 44.177034 ] ? kasan_quarantine_put+0xaa/0x1f0\n[ 44.177372 ] ? kasan_quarantine_put+0xaa/0x1f0\n[ 44.177711 ] __flush_work+0x11a/0x1a0\n[ 44.177991 ] ? flush_work+0x20/0x20\n[ 44.178257 ] ? lock_release+0x13c/0x8f0\n[ 44.178550 ] ? __kasan_check_write+0x14/0x20\n[ 44.178872 ] ? do_raw_spin_lock+0x148/0x360\n[ 44.179187 ] ? read_lock_is_recursive+0x20/0x20\n[ 44.179530 ] ? __kasan_check_read+0x11/0x20\n[ 44.179846 ] ? do_raw_spin_unlock+0x55/0x900\n[ 44.180168 ] ? ____kasan_slab_free+0x116/0x140\n[ 44.180505 ] ? _raw_spin_unlock_irqrestore+0x41/0x60\n[ 44.180878 ] ? skb_queue_purge+0x1a3/0x1c0\n[ 44.181189 ] ? kfree+0x13e/0x290\n[ 44.181438 ] flush_work+0x17/0x20\n[ 44.181695 ] mISDN_freedchannel+0xe8/0x100\n[ 44.182006 ] isac_release+0x210/0x260 [mISDNipac]\n[ 44.182366 ] nj_release+0xf6/0x500 [netjet]\n[ 44.182685 ] nj_remove+0x48/0x70 [netjet]\n[ 44.182989 ] pci_device_remove+0xa9/0x250(CVE-2021-47468)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncomedi: vmk80xx: fix bulk-buffer overflow\r\n\r\nThe driver is using endpoint-sized buffers but must not assume that the\ntx and rx buffers are of equal size or a malicious device could overflow\nthe slab-allocated receive buffer when doing bulk transfers.(CVE-2021-47474)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: batman-adv: fix error handling\r\n\r\nSyzbot reported ODEBUG warning in batadv_nc_mesh_free(). The problem was\nin wrong error handling in batadv_mesh_init().\r\n\r\nBefore this patch batadv_mesh_init() was calling batadv_mesh_free() in case\nof any batadv_*_init() calls failure. This approach may work well, when\nthere is some kind of indicator, which can tell which parts of batadv are\ninitialized; but there isn\u0026apos;t any.\r\n\r\nAll written above lead to cleaning up uninitialized fields. Even if we hide\nODEBUG warning by initializing bat_priv-\u0026gt;nc.work, syzbot was able to hit\nGPF in batadv_nc_purge_paths(), because hash pointer in still NULL. [1]\r\n\r\nTo fix these bugs we can unwind batadv_*_init() calls one by one.\nIt is good approach for 2 reasons: 1) It fixes bugs on error handling\npath 2) It improves the performance, since we won\u0026apos;t call unneeded\nbatadv_*_free() functions.\r\n\r\nSo, this patch makes all batadv_*_init() clean up all allocated memory\nbefore returning with an error to no call correspoing batadv_*_free()\nand open-codes batadv_mesh_free() with proper order to avoid touching\nuninitialized fields.(CVE-2021-47482)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nregmap: Fix possible double-free in regcache_rbtree_exit()\r\n\r\nIn regcache_rbtree_insert_to_block(), when \u0026apos;present\u0026apos; realloc failed,\nthe \u0026apos;blk\u0026apos; which is supposed to assign to \u0026apos;rbnode-\u0026gt;block\u0026apos; will be freed,\nso \u0026apos;rbnode-\u0026gt;block\u0026apos; points a freed memory, in the error handling path of\nregcache_rbtree_init(), \u0026apos;rbnode-\u0026gt;block\u0026apos; will be freed again in\nregcache_rbtree_exit(), KASAN will report double-free as follows:\r\n\r\nBUG: KASAN: double-free or invalid-free in kfree+0xce/0x390\nCall Trace:\n slab_free_freelist_hook+0x10d/0x240\n kfree+0xce/0x390\n regcache_rbtree_exit+0x15d/0x1a0\n regcache_rbtree_init+0x224/0x2c0\n regcache_init+0x88d/0x1310\n __regmap_init+0x3151/0x4a80\n __devm_regmap_init+0x7d/0x100\n madera_spi_probe+0x10f/0x333 [madera_spi]\n spi_probe+0x183/0x210\n really_probe+0x285/0xc30\r\n\r\nTo fix this, moving up the assignment of rbnode-\u0026gt;block to immediately after\nthe reallocation has succeeded so that the data structure stays valid even\nif the second reallocation fails.(CVE-2021-47483)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nIB/qib: Protect from buffer overflow in struct qib_user_sdma_pkt fields\r\n\r\nOverflowing either addrlimit or bytes_togo can allow userspace to trigger\na buffer overflow of kernel memory. Check for overflows in all the places\ndoing math on user controlled buffers.(CVE-2021-47485)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/tls: Fix flipped sign in tls_err_abort() calls\r\n\r\nsk-\u0026gt;sk_err appears to expect a positive value, a convention that ktls\ndoesn\u0026apos;t always follow and that leads to memory corruption in other code.\nFor instance,\r\n\r\n [kworker]\n tls_encrypt_done(..., err=\u0026lt;negative error from crypto request\u0026gt;)\n tls_err_abort(.., err)\n sk-\u0026gt;sk_err = err;\r\n\r\n [task]\n splice_from_pipe_feed\n ...\n tls_sw_do_sendpage\n if (sk-\u0026gt;sk_err) {\n ret = -sk-\u0026gt;sk_err; // ret is positive\r\n\r\n splice_from_pipe_feed (continued)\n ret = actor(...) // ret is still positive and interpreted as bytes\n // written, resulting in underflow of buf-\u0026gt;len and\n // sd-\u0026gt;len, leading to huge buf-\u0026gt;offset and bogus\n // addresses computed in later calls to actor()\r\n\r\nFix all tls_err_abort() callers to pass a negative error code\nconsistently and centralize the error-prone sign flip there, throwing in\na warning to catch future misuse and uninlining the function so it\nreally does only warn once.(CVE-2021-47496)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nALSA: pcm: oss: Limit the period size to 16MB\r\n\r\nSet the practical limit to the period size (the fragment shift in OSS)\ninstead of a full 31bit; a too large value could lead to the exhaust\nof memory as we allocate temporary buffers of the period size, too.\r\n\r\nAs of this patch, we set to 16MB limit, which should cover all use\ncases.(CVE-2021-47509)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnfp: Fix memory leak in nfp_cpp_area_cache_add()\r\n\r\nIn line 800 (#1), nfp_cpp_area_alloc() allocates and initializes a\nCPP area structure. But in line 807 (#2), when the cache is allocated\nfailed, this CPP area structure is not freed, which will result in\nmemory leak.\r\n\r\nWe can fix it by freeing the CPP area when the cache is allocated\nfailed (#2).\r\n\r\n792 int nfp_cpp_area_cache_add(struct nfp_cpp *cpp, size_t size)\n793 {\n794 \tstruct nfp_cpp_area_cache *cache;\n795 \tstruct nfp_cpp_area *area;\r\n\r\n800\tarea = nfp_cpp_area_alloc(cpp, NFP_CPP_ID(7, NFP_CPP_ACTION_RW, 0),\n801 \t\t\t\t 0, size);\n\t// #1: allocates and initializes\r\n\r\n802 \tif (!area)\n803 \t\treturn -ENOMEM;\r\n\r\n805 \tcache = kzalloc(sizeof(*cache), GFP_KERNEL);\n806 \tif (!cache)\n807 \t\treturn -ENOMEM; // #2: missing free\r\n\r\n817\treturn 0;\n818 }(CVE-2021-47516)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nstaging: rtl8192e: Fix use after free in _rtl92e_pci_disconnect()\r\n\r\nThe free_rtllib() function frees the \u0026quot;dev\u0026quot; pointer so there is use\nafter free on the next line. Re-arrange things to avoid that.(CVE-2021-47571)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsoc: brcmstb: pm-arm: Fix refcount leak and __iomem leak bugs\r\n\r\nIn brcmstb_pm_probe(), there are two kinds of leak bugs:\r\n\r\n(1) we need to add of_node_put() when for_each__matching_node() breaks\n(2) we need to add iounmap() for each iomap in fail path(CVE-2022-48693)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmmc: mmc_spi: fix error handling in mmc_spi_probe()\r\n\r\nIf mmc_add_host() fails, it doesn\u0026apos;t need to call mmc_remove_host(),\nor it will cause null-ptr-deref, because of deleting a not added\ndevice in mmc_remove_host().\r\n\r\nTo fix this, goto label \u0026apos;fail_glue_init\u0026apos;, if mmc_add_host() fails,\nand change the label \u0026apos;fail_add_host\u0026apos; to \u0026apos;fail_gpiod_request\u0026apos;.(CVE-2023-52708)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: USB: Fix wrong-direction WARNING in plusb.c\r\n\r\nThe syzbot fuzzer detected a bug in the plusb network driver: A\nzero-length control-OUT transfer was treated as a read instead of a\nwrite. In modern kernels this error provokes a WARNING:\r\n\r\nusb 1-1: BOGUS control dir, pipe 80000280 doesn\u0026apos;t match bRequestType c0\nWARNING: CPU: 0 PID: 4645 at drivers/usb/core/urb.c:411\nusb_submit_urb+0x14a7/0x1880 drivers/usb/core/urb.c:411\nModules linked in:\nCPU: 1 PID: 4645 Comm: dhcpcd Not tainted\n6.2.0-rc6-syzkaller-00050-g9f266ccaa2f5 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google\n01/12/2023\nRIP: 0010:usb_submit_urb+0x14a7/0x1880 drivers/usb/core/urb.c:411\n...\nCall Trace:\n \u0026lt;TASK\u0026gt;\n usb_start_wait_urb+0x101/0x4b0 drivers/usb/core/message.c:58\n usb_internal_control_msg drivers/usb/core/message.c:102 [inline]\n usb_control_msg+0x320/0x4a0 drivers/usb/core/message.c:153\n __usbnet_read_cmd+0xb9/0x390 drivers/net/usb/usbnet.c:2010\n usbnet_read_cmd+0x96/0xf0 drivers/net/usb/usbnet.c:2068\n pl_vendor_req drivers/net/usb/plusb.c:60 [inline]\n pl_set_QuickLink_features drivers/net/usb/plusb.c:75 [inline]\n pl_reset+0x2f/0xf0 drivers/net/usb/plusb.c:85\n usbnet_open+0xcc/0x5d0 drivers/net/usb/usbnet.c:889\n __dev_open+0x297/0x4d0 net/core/dev.c:1417\n __dev_change_flags+0x587/0x750 net/core/dev.c:8530\n dev_change_flags+0x97/0x170 net/core/dev.c:8602\n devinet_ioctl+0x15a2/0x1d70 net/ipv4/devinet.c:1147\n inet_ioctl+0x33f/0x380 net/ipv4/af_inet.c:979\n sock_do_ioctl+0xcc/0x230 net/socket.c:1169\n sock_ioctl+0x1f8/0x680 net/socket.c:1286\n vfs_ioctl fs/ioctl.c:51 [inline]\n __do_sys_ioctl fs/ioctl.c:870 [inline]\n __se_sys_ioctl fs/ioctl.c:856 [inline]\n __x64_sys_ioctl+0x197/0x210 fs/ioctl.c:856\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\r\n\r\nThe fix is to call usbnet_write_cmd() instead of usbnet_read_cmd() and\nremove the USB_DIR_IN flag.(CVE-2023-52742)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nIB/hfi1: Restore allocated resources on failed copyout\r\n\r\nFix a resource leak if an error occurs.(CVE-2023-52747)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: gspca: cpia1: shift-out-of-bounds in set_flicker\r\n\r\nSyzkaller reported the following issue:\nUBSAN: shift-out-of-bounds in drivers/media/usb/gspca/cpia1.c:1031:27\nshift exponent 245 is too large for 32-bit type \u0026apos;int\u0026apos;\r\n\r\nWhen the value of the variable \u0026quot;sd-\u0026gt;params.exposure.gain\u0026quot; exceeds the\nnumber of bits in an integer, a shift-out-of-bounds error is reported. It\nis triggered because the variable \u0026quot;currentexp\u0026quot; cannot be left-shifted by\nmore than the number of bits in an integer. In order to avoid invalid\nrange during left-shift, the conditional expression is added.(CVE-2023-52764)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfs/jfs: Add check for negative db_l2nbperpage\r\n\r\nl2nbperpage is log2(number of blks per page), and the minimum legal\nvalue should be 0, not negative.\r\n\r\nIn the case of l2nbperpage being negative, an error will occur\nwhen subsequently used as shift exponent.\r\n\r\nSyzbot reported this bug:\r\n\r\nUBSAN: shift-out-of-bounds in fs/jfs/jfs_dmap.c:799:12\nshift exponent -16777216 is negative(CVE-2023-52810)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nlocking/ww_mutex/test: Fix potential workqueue corruption\r\n\r\nIn some cases running with the test-ww_mutex code, I was seeing\nodd behavior where sometimes it seemed flush_workqueue was\nreturning before all the work threads were finished.\r\n\r\nOften this would cause strange crashes as the mutexes would be\nfreed while they were being used.\r\n\r\nLooking at the code, there is a lifetime problem as the\ncontrolling thread that spawns the work allocates the\n\u0026quot;struct stress\u0026quot; structures that are passed to the workqueue\nthreads. Then when the workqueue threads are finished,\nthey free the stress struct that was passed to them.\r\n\r\nUnfortunately the workqueue work_struct node is in the stress\nstruct. Which means the work_struct is freed before the work\nthread returns and while flush_workqueue is waiting.\r\n\r\nIt seems like a better idea to have the controlling thread\nboth allocate and free the stress structures, so that we can\nbe sure we don\u0026apos;t corrupt the workqueue by freeing the structure\nprematurely.\r\n\r\nSo this patch reworks the test to do so, and with this change\nI no longer see the early flush_workqueue returns.(CVE-2023-52836)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nllc: verify mac len before reading mac header\r\n\r\nLLC reads the mac header with eth_hdr without verifying that the skb\nhas an Ethernet header.\r\n\r\nSyzbot was able to enter llc_rcv on a tun device. Tun can insert\npackets without mac len and with user configurable skb-\u0026gt;protocol\n(passing a tun_pi header when not configuring IFF_NO_PI).\r\n\r\n BUG: KMSAN: uninit-value in llc_station_ac_send_test_r net/llc/llc_station.c:81 [inline]\n BUG: KMSAN: uninit-value in llc_station_rcv+0x6fb/0x1290 net/llc/llc_station.c:111\n llc_station_ac_send_test_r net/llc/llc_station.c:81 [inline]\n llc_station_rcv+0x6fb/0x1290 net/llc/llc_station.c:111\n llc_rcv+0xc5d/0x14a0 net/llc/llc_input.c:218\n __netif_receive_skb_one_core net/core/dev.c:5523 [inline]\n __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5637\n netif_receive_skb_internal net/core/dev.c:5723 [inline]\n netif_receive_skb+0x58/0x660 net/core/dev.c:5782\n tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555\n tun_get_user+0x54c5/0x69c0 drivers/net/tun.c:2002\r\n\r\nAdd a mac_len test before all three eth_hdr(skb) calls under net/llc.\r\n\r\nThere are further uses in include/net/llc_pdu.h. All these are\nprotected by a test skb-\u0026gt;protocol == ETH_P_802_2. Which does not\nprotect against this tun scenario.\r\n\r\nBut the mac_len test added in this patch in llc_fixup_skb will\nindirectly protect those too. That is called from llc_rcv before any\nother LLC code.\r\n\r\nIt is tempting to just add a blanket mac_len check in llc_rcv, but\nnot sure whether that could break valid LLC paths that do not assume\nan Ethernet header. 802.2 LLC may be used on top of non-802.3\nprotocols in principle. The below referenced commit shows that used\nto, on top of Token Ring.\r\n\r\nAt least one of the three eth_hdr uses goes back to before the start\nof git history. But the one that syzbot exercises is introduced in\nthis commit. That commit is old enough (2008), that effectively all\nstable kernels should receive this.(CVE-2023-52843)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nclk: mediatek: clk-mt2701: Add check for mtk_alloc_clk_data\r\n\r\nAdd the check for the return value of mtk_alloc_clk_data() in order to\navoid NULL pointer dereference.(CVE-2023-52875)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntty: n_gsm: require CAP_NET_ADMIN to attach N_GSM0710 ldisc\r\n\r\nAny unprivileged user can attach N_GSM0710 ldisc, but it requires\nCAP_NET_ADMIN to create a GSM network anyway.\r\n\r\nRequire initial namespace CAP_NET_ADMIN to do that.(CVE-2023-52880)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/mlx5e: Prevent deadlock while disabling aRFS\r\n\r\nWhen disabling aRFS under the `priv-\u0026gt;state_lock`, any scheduled\naRFS works are canceled using the `cancel_work_sync` function,\nwhich waits for the work to end if it has already started.\nHowever, while waiting for the work handler, the handler will\ntry to acquire the `state_lock` which is already acquired.\r\n\r\nThe worker acquires the lock to delete the rules if the state\nis down, which is not the worker\u0026apos;s responsibility since\ndisabling aRFS deletes the rules.\r\n\r\nAdd an aRFS state variable, which indicates whether the aRFS is\nenabled and prevent adding rules when the aRFS is disabled.\r\n\r\nKernel log:\r\n\r\n======================================================\nWARNING: possible circular locking dependency detected\n6.7.0-rc4_net_next_mlx5_5483eb2 #1 Tainted: G I\n------------------------------------------------------\nethtool/386089 is trying to acquire lock:\nffff88810f21ce68 ((work_completion)(\u0026amp;rule-\u0026gt;arfs_work)){+.+.}-{0:0}, at: __flush_work+0x74/0x4e0\r\n\r\nbut task is already holding lock:\nffff8884a1808cc0 (\u0026amp;priv-\u0026gt;state_lock){+.+.}-{3:3}, at: mlx5e_ethtool_set_channels+0x53/0x200 [mlx5_core]\r\n\r\nwhich lock already depends on the new lock.\r\n\r\nthe existing dependency chain (in reverse order) is:\r\n\r\n-\u0026gt; #1 (\u0026amp;priv-\u0026gt;state_lock){+.+.}-{3:3}:\n __mutex_lock+0x80/0xc90\n arfs_handle_work+0x4b/0x3b0 [mlx5_core]\n process_one_work+0x1dc/0x4a0\n worker_thread+0x1bf/0x3c0\n kthread+0xd7/0x100\n ret_from_fork+0x2d/0x50\n ret_from_fork_asm+0x11/0x20\r\n\r\n-\u0026gt; #0 ((work_completion)(\u0026amp;rule-\u0026gt;arfs_work)){+.+.}-{0:0}:\n __lock_acquire+0x17b4/0x2c80\n lock_acquire+0xd0/0x2b0\n __flush_work+0x7a/0x4e0\n __cancel_work_timer+0x131/0x1c0\n arfs_del_rules+0x143/0x1e0 [mlx5_core]\n mlx5e_arfs_disable+0x1b/0x30 [mlx5_core]\n mlx5e_ethtool_set_channels+0xcb/0x200 [mlx5_core]\n ethnl_set_channels+0x28f/0x3b0\n ethnl_default_set_doit+0xec/0x240\n genl_family_rcv_msg_doit+0xd0/0x120\n genl_rcv_msg+0x188/0x2c0\n netlink_rcv_skb+0x54/0x100\n genl_rcv+0x24/0x40\n netlink_unicast+0x1a1/0x270\n netlink_sendmsg+0x214/0x460\n __sock_sendmsg+0x38/0x60\n __sys_sendto+0x113/0x170\n __x64_sys_sendto+0x20/0x30\n do_syscall_64+0x40/0xe0\n entry_SYSCALL_64_after_hwframe+0x46/0x4e\r\n\r\nother info that might help us debug this:\r\n\r\n Possible unsafe locking scenario:\r\n\r\n CPU0 CPU1\n ---- ----\n lock(\u0026amp;priv-\u0026gt;state_lock);\n lock((work_completion)(\u0026amp;rule-\u0026gt;arfs_work));\n lock(\u0026amp;priv-\u0026gt;state_lock);\n lock((work_completion)(\u0026amp;rule-\u0026gt;arfs_work));\r\n\r\n *** DEADLOCK ***\r\n\r\n3 locks held by ethtool/386089:\n #0: ffffffff82ea7210 (cb_lock){++++}-{3:3}, at: genl_rcv+0x15/0x40\n #1: ffffffff82e94c88 (rtnl_mutex){+.+.}-{3:3}, at: ethnl_default_set_doit+0xd3/0x240\n #2: ffff8884a1808cc0 (\u0026amp;priv-\u0026gt;state_lock){+.+.}-{3:3}, at: mlx5e_ethtool_set_channels+0x53/0x200 [mlx5_core]\r\n\r\nstack backtrace:\nCPU: 15 PID: 386089 Comm: ethtool Tainted: G I 6.7.0-rc4_net_next_mlx5_5483eb2 #1\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x60/0xa0\n check_noncircular+0x144/0x160\n __lock_acquire+0x17b4/0x2c80\n lock_acquire+0xd0/0x2b0\n ? __flush_work+0x74/0x4e0\n ? save_trace+0x3e/0x360\n ? __flush_work+0x74/0x4e0\n __flush_work+0x7a/0x4e0\n ? __flush_work+0x74/0x4e0\n ? __lock_acquire+0xa78/0x2c80\n ? lock_acquire+0xd0/0x2b0\n ? mark_held_locks+0x49/0x70\n __cancel_work_timer+0x131/0x1c0\n ? mark_held_locks+0x49/0x70\n arfs_del_rules+0x143/0x1e0 [mlx5_core]\n mlx5e_arfs_disable+0x1b/0x30 [mlx5_core]\n mlx5e_ethtool_set_channels+0xcb/0x200 [mlx5_core]\n ethnl_set_channels+0x28f/0x3b0\n ethnl_default_set_doit+0xec/0x240\n genl_family_rcv_msg_doit+0xd0/0x120\n genl_rcv_msg+0x188/0x2c0\n ? ethn\n---truncated---(CVE-2024-27014)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nf_tables: Fix potential data-race in __nft_obj_type_get()\r\n\r\nnft_unregister_obj() can concurrent with __nft_obj_type_get(),\nand there is not any protection when iterate over nf_tables_objects\nlist in __nft_obj_type_get(). Therefore, there is potential data-race\nof nf_tables_objects list entry.\r\n\r\nUse list_for_each_entry_rcu() to iterate over nf_tables_objects\nlist in __nft_obj_type_get(), and use rcu_read_lock() in the caller\nnft_obj_type_get() to protect the entire type query process.(CVE-2024-27019)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nphonet/pep: fix racy skb_queue_empty() use\r\n\r\nThe receive queues are protected by their respective spin-lock, not\nthe socket lock. This could lead to skb_peek() unexpectedly\nreturning NULL or a pointer to an already dequeued socket buffer.(CVE-2024-27402)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsoc: fsl: qbman: Use raw spinlock for cgr_lock\r\n\r\nsmp_call_function always runs its callback in hard IRQ context, even on\nPREEMPT_RT, where spinlocks can sleep. So we need to use a raw spinlock\nfor cgr_lock to ensure we aren\u0026apos;t waiting on a sleeping task.\r\n\r\nAlthough this bug has existed for a while, it was not apparent until\ncommit ef2a8d5478b9 (\u0026quot;net: dpaa: Adjust queue depth on rate change\u0026quot;)\nwhich invokes smp_call_function_single via qman_update_cgr_safe every\ntime a link goes up or down.(CVE-2024-35819)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nubifs: Set page uptodate in the correct place\r\n\r\nPage cache reads are lockless, so setting the freshly allocated page\nuptodate before we\u0026apos;ve overwritten it with the data it\u0026apos;s supposed to have\nin it will allow a simultaneous reader to see old data. Move the call\nto SetPageUptodate into ubifs_write_end(), which is after we copied the\nnew data into the page.(CVE-2024-35821)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: libertas: fix some memleaks in lbs_allocate_cmd_buffer()\r\n\r\nIn the for statement of lbs_allocate_cmd_buffer(), if the allocation of\ncmdarray[i].cmdbuf fails, both cmdarray and cmdarray[i].cmdbuf needs to\nbe freed. Otherwise, there will be memleaks in lbs_allocate_cmd_buffer().(CVE-2024-35828)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntcp: properly terminate timers for kernel sockets\r\n\r\nWe had various syzbot reports about tcp timers firing after\nthe corresponding netns has been dismantled.\r\n\r\nFortunately Josef Bacik could trigger the issue more often,\nand could test a patch I wrote two years ago.\r\n\r\nWhen TCP sockets are closed, we call inet_csk_clear_xmit_timers()\nto \u0026apos;stop\u0026apos; the timers.\r\n\r\ninet_csk_clear_xmit_timers() can be called from any context,\nincluding when socket lock is held.\nThis is the reason it uses sk_stop_timer(), aka del_timer().\nThis means that ongoing timers might finish much later.\r\n\r\nFor user sockets, this is fine because each running timer\nholds a reference on the socket, and the user socket holds\na reference on the netns.\r\n\r\nFor kernel sockets, we risk that the netns is freed before\ntimer can complete, because kernel sockets do not hold\nreference on the netns.\r\n\r\nThis patch adds inet_csk_clear_xmit_timers_sync() function\nthat using sk_stop_timer_sync() to make sure all timers\nare terminated before the kernel socket is released.\nModules using kernel sockets close them in their netns exit()\nhandler.\r\n\r\nAlso add sock_not_owned_by_me() helper to get LOCKDEP\nsupport : inet_csk_clear_xmit_timers_sync() must not be called\nwhile socket lock is held.\r\n\r\nIt is very possible we can revert in the future commit\n3a58f13a881e (\u0026quot;net: rds: acquire refcount on TCP sockets\u0026quot;)\nwhich attempted to solve the issue in rds only.\n(net/smc/af_smc.c and net/mptcp/subflow.c have similar code)\r\n\r\nWe probably can remove the check_net() tests from\ntcp_out_of_resources() and __tcp_close() in the future.(CVE-2024-35910)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: send: handle path ref underflow in header iterate_inode_ref()\r\n\r\nChange BUG_ON to proper error handling if building the path buffer\nfails. The pointers are not printed so we don\u0026apos;t accidentally leak kernel\naddresses.(CVE-2024-35935)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: cfg80211: check A-MSDU format more carefully\r\n\r\nIf it looks like there\u0026apos;s another subframe in the A-MSDU\nbut the header isn\u0026apos;t fully there, we can end up reading\ndata out of bounds, only to discard later. Make this a\nbit more careful and check if the subframe header can\neven be present.(CVE-2024-35937)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndyndbg: fix old BUG_ON in \u0026gt;control parser\r\n\r\nFix a BUG_ON from 2009. Even if it looks \u0026quot;unreachable\u0026quot; (I didn\u0026apos;t\nreally look), lets make sure by removing it, doing pr_err and return\n-EINVAL instead.(CVE-2024-35947)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbatman-adv: Avoid infinite loop trying to resize local TT\r\n\r\nIf the MTU of one of an attached interface becomes too small to transmit\nthe local translation table then it must be resized to fit inside all\nfragments (when enabled) or a single packet.\r\n\r\nBut if the MTU becomes too low to transmit even the header + the VLAN\nspecific part then the resizing of the local TT will never succeed. This\ncan for example happen when the usable space is 110 bytes and 11 VLANs are\non top of batman-adv. In this case, at least 116 byte would be needed.\nThere will just be an endless spam of\r\n\r\n batman_adv: batadv0: Forced to purge local tt entries to fit new maximum fragment MTU (110)\r\n\r\nin the log but the function will never finish. Problem here is that the\ntimeout will be halved all the time and will then stagnate at 0 and\ntherefore never be able to reduce the table even more.\r\n\r\nThere are other scenarios possible with a similar result. The number of\nBATADV_TT_CLIENT_NOPURGE entries in the local TT can for example be too\nhigh to fit inside a packet. Such a scenario can therefore happen also with\nonly a single VLAN + 7 non-purgable addresses - requiring at least 120\nbytes.\r\n\r\nWhile this should be handled proactively when:\r\n\r\n* interface with too low MTU is added\n* VLAN is added\n* non-purgeable local mac is added\n* MTU of an attached interface is reduced\n* fragmentation setting gets disabled (which most likely requires dropping\n attached interfaces)\r\n\r\nnot all of these scenarios can be prevented because batman-adv is only\nconsuming events without the the possibility to prevent these actions\n(non-purgable MAC address added, MTU of an attached interface is reduced).\nIt is therefore necessary to also make sure that the code is able to handle\nalso the situations when there were already incompatible system\nconfiguration are present.(CVE-2024-35982)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntty: n_gsm: fix possible out-of-bounds in gsm0_receive()\r\n\r\nAssuming the following:\n- side A configures the n_gsm in basic option mode\n- side B sends the header of a basic option mode frame with data length 1\n- side A switches to advanced option mode\n- side B sends 2 data bytes which exceeds gsm-\u0026gt;len\n Reason: gsm-\u0026gt;len is not used in advanced option mode.\n- side A switches to basic option mode\n- side B keeps sending until gsm0_receive() writes past gsm-\u0026gt;buf\n Reason: Neither gsm-\u0026gt;state nor gsm-\u0026gt;len have been reset after\n reconfiguration.\r\n\r\nFix this by changing gsm-\u0026gt;count to gsm-\u0026gt;len comparison from equal to less\nthan. Also add upper limit checks against the constant MAX_MRU in\ngsm0_receive() and gsm1_receive() to harden against memory corruption of\ngsm-\u0026gt;len and gsm-\u0026gt;mru.\r\n\r\nAll other checks remain as we still need to limit the data according to the\nuser configuration and actual payload size.(CVE-2024-36016)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntipc: fix UAF in error path\r\n\r\nSam Page (sam4k) working with Trend Micro Zero Day Initiative reported\na UAF in the tipc_buf_append() error path:\r\n\r\nBUG: KASAN: slab-use-after-free in kfree_skb_list_reason+0x47e/0x4c0\nlinux/net/core/skbuff.c:1183\nRead of size 8 at addr ffff88804d2a7c80 by task poc/8034\r\n\r\nCPU: 1 PID: 8034 Comm: poc Not tainted 6.8.2 #1\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS\n1.16.0-debian-1.16.0-5 04/01/2014\nCall Trace:\n \u0026lt;IRQ\u0026gt;\n __dump_stack linux/lib/dump_stack.c:88\n dump_stack_lvl+0xd9/0x1b0 linux/lib/dump_stack.c:106\n print_address_description linux/mm/kasan/report.c:377\n print_report+0xc4/0x620 linux/mm/kasan/report.c:488\n kasan_report+0xda/0x110 linux/mm/kasan/report.c:601\n kfree_skb_list_reason+0x47e/0x4c0 linux/net/core/skbuff.c:1183\n skb_release_data+0x5af/0x880 linux/net/core/skbuff.c:1026\n skb_release_all linux/net/core/skbuff.c:1094\n __kfree_skb linux/net/core/skbuff.c:1108\n kfree_skb_reason+0x12d/0x210 linux/net/core/skbuff.c:1144\n kfree_skb linux/./include/linux/skbuff.h:1244\n tipc_buf_append+0x425/0xb50 linux/net/tipc/msg.c:186\n tipc_link_input+0x224/0x7c0 linux/net/tipc/link.c:1324\n tipc_link_rcv+0x76e/0x2d70 linux/net/tipc/link.c:1824\n tipc_rcv+0x45f/0x10f0 linux/net/tipc/node.c:2159\n tipc_udp_recv+0x73b/0x8f0 linux/net/tipc/udp_media.c:390\n udp_queue_rcv_one_skb+0xad2/0x1850 linux/net/ipv4/udp.c:2108\n udp_queue_rcv_skb+0x131/0xb00 linux/net/ipv4/udp.c:2186\n udp_unicast_rcv_skb+0x165/0x3b0 linux/net/ipv4/udp.c:2346\n __udp4_lib_rcv+0x2594/0x3400 linux/net/ipv4/udp.c:2422\n ip_protocol_deliver_rcu+0x30c/0x4e0 linux/net/ipv4/ip_input.c:205\n ip_local_deliver_finish+0x2e4/0x520 linux/net/ipv4/ip_input.c:233\n NF_HOOK linux/./include/linux/netfilter.h:314\n NF_HOOK linux/./include/linux/netfilter.h:308\n ip_local_deliver+0x18e/0x1f0 linux/net/ipv4/ip_input.c:254\n dst_input linux/./include/net/dst.h:461\n ip_rcv_finish linux/net/ipv4/ip_input.c:449\n NF_HOOK linux/./include/linux/netfilter.h:314\n NF_HOOK linux/./include/linux/netfilter.h:308\n ip_rcv+0x2c5/0x5d0 linux/net/ipv4/ip_input.c:569\n __netif_receive_skb_one_core+0x199/0x1e0 linux/net/core/dev.c:5534\n __netif_receive_skb+0x1f/0x1c0 linux/net/core/dev.c:5648\n process_backlog+0x101/0x6b0 linux/net/core/dev.c:5976\n __napi_poll.constprop.0+0xba/0x550 linux/net/core/dev.c:6576\n napi_poll linux/net/core/dev.c:6645\n net_rx_action+0x95a/0xe90 linux/net/core/dev.c:6781\n __do_softirq+0x21f/0x8e7 linux/kernel/softirq.c:553\n do_softirq linux/kernel/softirq.c:454\n do_softirq+0xb2/0xf0 linux/kernel/softirq.c:441\n \u0026lt;/IRQ\u0026gt;\n \u0026lt;TASK\u0026gt;\n __local_bh_enable_ip+0x100/0x120 linux/kernel/softirq.c:381\n local_bh_enable linux/./include/linux/bottom_half.h:33\n rcu_read_unlock_bh linux/./include/linux/rcupdate.h:851\n __dev_queue_xmit+0x871/0x3ee0 linux/net/core/dev.c:4378\n dev_queue_xmit linux/./include/linux/netdevice.h:3169\n neigh_hh_output linux/./include/net/neighbour.h:526\n neigh_output linux/./include/net/neighbour.h:540\n ip_finish_output2+0x169f/0x2550 linux/net/ipv4/ip_output.c:235\n __ip_finish_output linux/net/ipv4/ip_output.c:313\n __ip_finish_output+0x49e/0x950 linux/net/ipv4/ip_output.c:295\n ip_finish_output+0x31/0x310 linux/net/ipv4/ip_output.c:323\n NF_HOOK_COND linux/./include/linux/netfilter.h:303\n ip_output+0x13b/0x2a0 linux/net/ipv4/ip_output.c:433\n dst_output linux/./include/net/dst.h:451\n ip_local_out linux/net/ipv4/ip_output.c:129\n ip_send_skb+0x3e5/0x560 linux/net/ipv4/ip_output.c:1492\n udp_send_skb+0x73f/0x1530 linux/net/ipv4/udp.c:963\n udp_sendmsg+0x1a36/0x2b40 linux/net/ipv4/udp.c:1250\n inet_sendmsg+0x105/0x140 linux/net/ipv4/af_inet.c:850\n sock_sendmsg_nosec linux/net/socket.c:730\n __sock_sendmsg linux/net/socket.c:745\n __sys_sendto+0x42c/0x4e0 linux/net/socket.c:2191\n __do_sys_sendto linux/net/socket.c:2203\n __se_sys_sendto linux/net/socket.c:2199\n __x64_sys_sendto+0xe0/0x1c0 linux/net/socket.c:2199\n do_syscall_x64 linux/arch/x86/entry/common.c:52\n do_syscall_\n---truncated---(CVE-2024-36886)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nipv6: prevent NULL dereference in ip6_output()\r\n\r\nAccording to syzbot, there is a chance that ip6_dst_idev()\nreturns NULL in ip6_output(). Most places in IPv6 stack\ndeal with a NULL idev just fine, but not here.\r\n\r\nsyzbot reported:\r\n\r\ngeneral protection fault, probably for non-canonical address 0xdffffc00000000bc: 0000 [#1] PREEMPT SMP KASAN PTI\nKASAN: null-ptr-deref in range [0x00000000000005e0-0x00000000000005e7]\nCPU: 0 PID: 9775 Comm: syz-executor.4 Not tainted 6.9.0-rc5-syzkaller-00157-g6a30653b604a #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024\n RIP: 0010:ip6_output+0x231/0x3f0 net/ipv6/ip6_output.c:237\nCode: 3c 1e 00 49 89 df 74 08 4c 89 ef e8 19 58 db f7 48 8b 44 24 20 49 89 45 00 49 89 c5 48 8d 9d e0 05 00 00 48 89 d8 48 c1 e8 03 \u0026lt;42\u0026gt; 0f b6 04 38 84 c0 4c 8b 74 24 28 0f 85 61 01 00 00 8b 1b 31 ff\nRSP: 0018:ffffc9000927f0d8 EFLAGS: 00010202\nRAX: 00000000000000bc RBX: 00000000000005e0 RCX: 0000000000040000\nRDX: ffffc900131f9000 RSI: 0000000000004f47 RDI: 0000000000004f48\nRBP: 0000000000000000 R08: ffffffff8a1f0b9a R09: 1ffffffff1f51fad\nR10: dffffc0000000000 R11: fffffbfff1f51fae R12: ffff8880293ec8c0\nR13: ffff88805d7fc000 R14: 1ffff1100527d91a R15: dffffc0000000000\nFS: 00007f135c6856c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000020000080 CR3: 0000000064096000 CR4: 00000000003506f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n NF_HOOK include/linux/netfilter.h:314 [inline]\n ip6_xmit+0xefe/0x17f0 net/ipv6/ip6_output.c:358\n sctp_v6_xmit+0x9f2/0x13f0 net/sctp/ipv6.c:248\n sctp_packet_transmit+0x26ad/0x2ca0 net/sctp/output.c:653\n sctp_packet_singleton+0x22c/0x320 net/sctp/outqueue.c:783\n sctp_outq_flush_ctrl net/sctp/outqueue.c:914 [inline]\n sctp_outq_flush+0x6d5/0x3e20 net/sctp/outqueue.c:1212\n sctp_side_effects net/sctp/sm_sideeffect.c:1198 [inline]\n sctp_do_sm+0x59cc/0x60c0 net/sctp/sm_sideeffect.c:1169\n sctp_primitive_ASSOCIATE+0x95/0xc0 net/sctp/primitive.c:73\n __sctp_connect+0x9cd/0xe30 net/sctp/socket.c:1234\n sctp_connect net/sctp/socket.c:4819 [inline]\n sctp_inet_connect+0x149/0x1f0 net/sctp/socket.c:4834\n __sys_connect_file net/socket.c:2048 [inline]\n __sys_connect+0x2df/0x310 net/socket.c:2065\n __do_sys_connect net/socket.c:2075 [inline]\n __se_sys_connect net/socket.c:2072 [inline]\n __x64_sys_connect+0x7a/0x90 net/socket.c:2072\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2024-36901)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntcp: defer shutdown(SEND_SHUTDOWN) for TCP_SYN_RECV sockets\r\n\r\nTCP_SYN_RECV state is really special, it is only used by\ncross-syn connections, mostly used by fuzzers.\r\n\r\nIn the following crash [1], syzbot managed to trigger a divide\nby zero in tcp_rcv_space_adjust()\r\n\r\nA socket makes the following state transitions,\nwithout ever calling tcp_init_transfer(),\nmeaning tcp_init_buffer_space() is also not called.\r\n\r\n TCP_CLOSE\nconnect()\n TCP_SYN_SENT\n TCP_SYN_RECV\nshutdown() -\u0026gt; tcp_shutdown(sk, SEND_SHUTDOWN)\n TCP_FIN_WAIT1\r\n\r\nTo fix this issue, change tcp_shutdown() to not\nperform a TCP_SYN_RECV -\u0026gt; TCP_FIN_WAIT1 transition,\nwhich makes no sense anyway.\r\n\r\nWhen tcp_rcv_state_process() later changes socket state\nfrom TCP_SYN_RECV to TCP_ESTABLISH, then look at\nsk-\u0026gt;sk_shutdown to finally enter TCP_FIN_WAIT1 state,\nand send a FIN packet from a sane socket state.\r\n\r\nThis means tcp_send_fin() can now be called from BH\ncontext, and must use GFP_ATOMIC allocations.\r\n\r\n[1]\ndivide error: 0000 [#1] PREEMPT SMP KASAN NOPTI\nCPU: 1 PID: 5084 Comm: syz-executor358 Not tainted 6.9.0-rc6-syzkaller-00022-g98369dccd2f8 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024\n RIP: 0010:tcp_rcv_space_adjust+0x2df/0x890 net/ipv4/tcp_input.c:767\nCode: e3 04 4c 01 eb 48 8b 44 24 38 0f b6 04 10 84 c0 49 89 d5 0f 85 a5 03 00 00 41 8b 8e c8 09 00 00 89 e8 29 c8 48 0f af c3 31 d2 \u0026lt;48\u0026gt; f7 f1 48 8d 1c 43 49 8d 96 76 08 00 00 48 89 d0 48 c1 e8 03 48\nRSP: 0018:ffffc900031ef3f0 EFLAGS: 00010246\nRAX: 0c677a10441f8f42 RBX: 000000004fb95e7e RCX: 0000000000000000\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000\nRBP: 0000000027d4b11f R08: ffffffff89e535a4 R09: 1ffffffff25e6ab7\nR10: dffffc0000000000 R11: ffffffff8135e920 R12: ffff88802a9f8d30\nR13: dffffc0000000000 R14: ffff88802a9f8d00 R15: 1ffff1100553f2da\nFS: 00005555775c0380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f1155bf2304 CR3: 000000002b9f2000 CR4: 0000000000350ef0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n tcp_recvmsg_locked+0x106d/0x25a0 net/ipv4/tcp.c:2513\n tcp_recvmsg+0x25d/0x920 net/ipv4/tcp.c:2578\n inet6_recvmsg+0x16a/0x730 net/ipv6/af_inet6.c:680\n sock_recvmsg_nosec net/socket.c:1046 [inline]\n sock_recvmsg+0x109/0x280 net/socket.c:1068\n ____sys_recvmsg+0x1db/0x470 net/socket.c:2803\n ___sys_recvmsg net/socket.c:2845 [inline]\n do_recvmmsg+0x474/0xae0 net/socket.c:2939\n __sys_recvmmsg net/socket.c:3018 [inline]\n __do_sys_recvmmsg net/socket.c:3041 [inline]\n __se_sys_recvmmsg net/socket.c:3034 [inline]\n __x64_sys_recvmmsg+0x199/0x250 net/socket.c:3034\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7faeb6363db9\nCode: 28 00 00 00 75 05 48 83 c4 28 c3 e8 c1 17 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007ffcc1997168 EFLAGS: 00000246 ORIG_RAX: 000000000000012b\nRAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007faeb6363db9\nRDX: 0000000000000001 RSI: 0000000020000bc0 RDI: 0000000000000005\nRBP: 0000000000000000 R08: 0000000000000000 R09: 000000000000001c\nR10: 0000000000000122 R11: 0000000000000246 R12: 0000000000000000\nR13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000001(CVE-2024-36905)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: bnx2fc: Remove spin_lock_bh while releasing resources after upload\r\n\r\nThe session resources are used by FW and driver when session is offloaded,\nonce session is uploaded these resources are not used. The lock is not\nrequired as these fields won\u0026apos;t be used any longer. The offload and upload\ncalls are sequential, hence lock is not required.\r\n\r\nThis will suppress following BUG_ON():\r\n\r\n[ 449.843143] ------------[ cut here ]------------\n[ 449.848302] kernel BUG at mm/vmalloc.c:2727!\n[ 449.853072] invalid opcode: 0000 [#1] PREEMPT SMP PTI\n[ 449.858712] CPU: 5 PID: 1996 Comm: kworker/u24:2 Not tainted 5.14.0-118.el9.x86_64 #1\nRebooting.\n[ 449.867454] Hardware name: Dell Inc. PowerEdge R730/0WCJNT, BIOS 2.3.4 11/08/2016\n[ 449.876966] Workqueue: fc_rport_eq fc_rport_work [libfc]\n[ 449.882910] RIP: 0010:vunmap+0x2e/0x30\n[ 449.887098] Code: 00 65 8b 05 14 a2 f0 4a a9 00 ff ff 00 75 1b 55 48 89 fd e8 34 36 79 00 48 85 ed 74 0b 48 89 ef 31 f6 5d e9 14 fc ff ff 5d c3 \u0026lt;0f\u0026gt; 0b 0f 1f 44 00 00 41 57 41 56 49 89 ce 41 55 49 89 fd 41 54 41\n[ 449.908054] RSP: 0018:ffffb83d878b3d68 EFLAGS: 00010206\n[ 449.913887] RAX: 0000000080000201 RBX: ffff8f4355133550 RCX: 000000000d400005\n[ 449.921843] RDX: 0000000000000001 RSI: 0000000000001000 RDI: ffffb83da53f5000\n[ 449.929808] RBP: ffff8f4ac6675800 R08: ffffb83d878b3d30 R09: 00000000000efbdf\n[ 449.937774] R10: 0000000000000003 R11: ffff8f434573e000 R12: 0000000000001000\n[ 449.945736] R13: 0000000000001000 R14: ffffb83da53f5000 R15: ffff8f43d4ea3ae0\n[ 449.953701] FS: 0000000000000000(0000) GS:ffff8f529fc80000(0000) knlGS:0000000000000000\n[ 449.962732] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 449.969138] CR2: 00007f8cf993e150 CR3: 0000000efbe10003 CR4: 00000000003706e0\n[ 449.977102] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[ 449.985065] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[ 449.993028] Call Trace:\n[ 449.995756] __iommu_dma_free+0x96/0x100\n[ 450.000139] bnx2fc_free_session_resc+0x67/0x240 [bnx2fc]\n[ 450.006171] bnx2fc_upload_session+0xce/0x100 [bnx2fc]\n[ 450.011910] bnx2fc_rport_event_handler+0x9f/0x240 [bnx2fc]\n[ 450.018136] fc_rport_work+0x103/0x5b0 [libfc]\n[ 450.023103] process_one_work+0x1e8/0x3c0\n[ 450.027581] worker_thread+0x50/0x3b0\n[ 450.031669] ? rescuer_thread+0x370/0x370\n[ 450.036143] kthread+0x149/0x170\n[ 450.039744] ? set_kthread_struct+0x40/0x40\n[ 450.044411] ret_from_fork+0x22/0x30\n[ 450.048404] Modules linked in: vfat msdos fat xfs nfs_layout_nfsv41_files rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver dm_service_time qedf qed crc8 bnx2fc libfcoe libfc scsi_transport_fc intel_rapl_msr intel_rapl_common x86_pkg_temp_thermal intel_powerclamp dcdbas rapl intel_cstate intel_uncore mei_me pcspkr mei ipmi_ssif lpc_ich ipmi_si fuse zram ext4 mbcache jbd2 loop nfsv3 nfs_acl nfs lockd grace fscache netfs irdma ice sd_mod t10_pi sg ib_uverbs ib_core 8021q garp mrp stp llc mgag200 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt mxm_wmi fb_sys_fops cec crct10dif_pclmul ahci crc32_pclmul bnx2x drm ghash_clmulni_intel libahci rfkill i40e libata megaraid_sas mdio wmi sunrpc lrw dm_crypt dm_round_robin dm_multipath dm_snapshot dm_bufio dm_mirror dm_region_hash dm_log dm_zero dm_mod linear raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx raid6_pq libcrc32c crc32c_intel raid1 raid0 iscsi_ibft squashfs be2iscsi bnx2i cnic uio cxgb4i cxgb4 tls\n[ 450.048497] libcxgbi libcxgb qla4xxx iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi edd ipmi_devintf ipmi_msghandler\n[ 450.159753] ---[ end trace 712de2c57c64abc8 ]---(CVE-2024-36919)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbna: ensure the copied buf is NUL terminated\r\n\r\nCurrently, we allocate a nbytes-sized kernel buffer and copy nbytes from\nuserspace to that buffer. Later, we use sscanf on this buffer but we don\u0026apos;t\nensure that the string is terminated inside the buffer, this can lead to\nOOB read when using sscanf. Fix this issue by using memdup_user_nul\ninstead of memdup_user.(CVE-2024-36934)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: lpfc: Move NPIV\u0026apos;s transport unregistration to after resource clean up\r\n\r\nThere are cases after NPIV deletion where the fabric switch still believes\nthe NPIV is logged into the fabric. This occurs when a vport is\nunregistered before the Remove All DA_ID CT and LOGO ELS are sent to the\nfabric.\r\n\r\nCurrently fc_remove_host(), which calls dev_loss_tmo for all D_IDs including\nthe fabric D_ID, removes the last ndlp reference and frees the ndlp rport\nobject. This sometimes causes the race condition where the final DA_ID and\nLOGO are skipped from being sent to the fabric switch.\r\n\r\nFix by moving the fc_remove_host() and scsi_remove_host() calls after DA_ID\nand LOGO are sent.(CVE-2024-36952)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/vmwgfx: Fix invalid reads in fence signaled events\r\n\r\nCorrectly set the length of the drm_event to the size of the structure\nthat\u0026apos;s actually used.\r\n\r\nThe length of the drm_event was set to the parent structure instead of\nto the drm_vmw_event_fence which is supposed to be read. drm_read\nuses the length parameter to copy the event to the user space thus\nresuling in oob reads.(CVE-2024-36960)",
"id": "OESA-2024-1736",
"modified": "2026-08-06T11:07:12Z",
"published": "2024-06-21T11:07:12Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1736"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47229"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47234"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47249"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47257"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47267"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47281"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47301"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47310"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47321"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47334"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47344"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47354"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47372"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47425"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47440"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47456"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47468"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47474"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47482"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47483"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47485"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47496"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47509"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47516"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47571"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48693"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52708"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52742"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52747"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52764"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52810"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52836"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52843"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52875"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52880"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27014"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27019"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27402"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35819"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35821"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35828"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35910"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35935"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35937"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35947"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35982"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36016"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36886"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36901"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36905"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36919"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36934"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36952"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36960"
}
],
"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-47229",
"CVE-2021-47234",
"CVE-2021-47249",
"CVE-2021-47257",
"CVE-2021-47267",
"CVE-2021-47281",
"CVE-2021-47301",
"CVE-2021-47310",
"CVE-2021-47321",
"CVE-2021-47334",
"CVE-2021-47344",
"CVE-2021-47354",
"CVE-2021-47372",
"CVE-2021-47425",
"CVE-2021-47440",
"CVE-2021-47456",
"CVE-2021-47468",
"CVE-2021-47474",
"CVE-2021-47482",
"CVE-2021-47483",
"CVE-2021-47485",
"CVE-2021-47496",
"CVE-2021-47509",
"CVE-2021-47516",
"CVE-2021-47571",
"CVE-2022-48693",
"CVE-2023-52708",
"CVE-2023-52742",
"CVE-2023-52747",
"CVE-2023-52764",
"CVE-2023-52810",
"CVE-2023-52836",
"CVE-2023-52843",
"CVE-2023-52875",
"CVE-2023-52880",
"CVE-2024-27014",
"CVE-2024-27019",
"CVE-2024-27402",
"CVE-2024-35819",
"CVE-2024-35821",
"CVE-2024-35828",
"CVE-2024-35910",
"CVE-2024-35935",
"CVE-2024-35937",
"CVE-2024-35947",
"CVE-2024-35982",
"CVE-2024-36016",
"CVE-2024-36886",
"CVE-2024-36901",
"CVE-2024-36905",
"CVE-2024-36919",
"CVE-2024-36934",
"CVE-2024-36952",
"CVE-2024-36960"
]
}
OESA-2024-1768 (CVE-2021-47381)
Vulnerability from osv_openeuler – Published: 2024-06-28 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:
ASoC: SOF: Fix DSP oops stack dump output contents
Fix @buf arg given to hex_dump_to_buffer() and stack address used in dump error output.(CVE-2021-47381)
In the Linux kernel, the following vulnerability has been resolved:
scsi: iscsi: Fix iscsi_task use after free
Commit d39df158518c ("scsi: iscsi: Have abort handler get ref to conn") added iscsi_get_conn()/iscsi_put_conn() calls during abort handling but then also changed the handling of the case where we detect an already completed task where we now end up doing a goto to the common put/cleanup code. This results in a iscsi_task use after free, because the common cleanup code will do a put on the iscsi_task.
This reverts the goto and moves the iscsi_get_conn() to after we've checked if the iscsi_task is valid.(CVE-2021-47427)
In the Linux kernel, the following vulnerability has been resolved:
spi: Fix deadlock when adding SPI controllers on SPI buses
Currently we have a global spi_add_lock which we take when adding new devices so that we can check that we're not trying to reuse a chip select that's already controlled. This means that if the SPI device is itself a SPI controller and triggers the instantiation of further SPI devices we trigger a deadlock as we try to register and instantiate those devices while in the process of doing so for the parent controller and hence already holding the global spi_add_lock. Since we only care about concurrency within a single SPI bus move the lock to be per controller, avoiding the deadlock.
This can be easily triggered in the case of spi-mux.(CVE-2021-47469)
(CVE-2023-39180)
In the Linux kernel, the following vulnerability has been resolved:
powerpc/powernv: Add a null pointer check in opal_powercap_init()
kasprintf() returns a pointer to dynamically allocated memory which can be NULL upon failure.(CVE-2023-52696)
In the Linux kernel, the following vulnerability has been resolved:
i2c: core: Run atomic i2c xfer when !preemptible
Since bae1d3a05a8b, i2c transfers are non-atomic if preemption is disabled. However, non-atomic i2c transfers require preemption (e.g. in wait_for_completion() while waiting for the DMA).
panic() calls preempt_disable_notrace() before calling emergency_restart(). Therefore, if an i2c device is used for the restart, the xfer should be atomic. This avoids warnings like:
[ 12.667612] WARNING: CPU: 1 PID: 1 at kernel/rcu/tree_plugin.h:318 rcu_note_context_switch+0x33c/0x6b0 [ 12.676926] Voluntary context switch within RCU read-side critical section! ... [ 12.742376] schedule_timeout from wait_for_completion_timeout+0x90/0x114 [ 12.749179] wait_for_completion_timeout from tegra_i2c_wait_completion+0x40/0x70 ... [ 12.994527] atomic_notifier_call_chain from machine_restart+0x34/0x58 [ 13.001050] machine_restart from panic+0x2a8/0x32c
Use !preemptible() instead, which is basically the same check as pre-v5.2.(CVE-2023-52791)
In the Linux kernel, the following vulnerability has been resolved:
hid: cp2112: Fix duplicate workqueue initialization
Previously the cp2112 driver called INIT_DELAYED_WORK within cp2112_gpio_irq_startup, resulting in duplicate initilizations of the workqueue on subsequent IRQ startups following an initial request. This resulted in a warning in set_work_data in workqueue.c, as well as a rare NULL dereference within process_one_work in workqueue.c.
Initialize the workqueue within _probe instead.(CVE-2023-52853)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix UAF issue in ksmbd_tcp_new_connection()
The race is between the handling of a new TCP connection and
its disconnection. It leads to UAF on struct tcp_transport in
ksmbd_tcp_new_connection() function.(CVE-2024-26592)
In the Linux kernel, the following vulnerability has been resolved:
net/ipv6: avoid possible UAF in ip6_route_mpath_notify()
syzbot found another use-after-free in ip6_route_mpath_notify() [1]
Commit f7225172f25a ("net/ipv6: prevent use after free in ip6_route_mpath_notify") was not able to fix the root cause.
We need to defer the fib6_info_release() calls after ip6_route_mpath_notify(), in the cleanup phase.
[1] BUG: KASAN: slab-use-after-free in rt6_fill_node+0x1460/0x1ac0 Read of size 4 at addr ffff88809a07fc64 by task syz-executor.2/23037
CPU: 0 PID: 23037 Comm: syz-executor.2 Not tainted 6.8.0-rc4-syzkaller-01035-gea7f3cfaa588 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1e7/0x2e0 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:377 [inline] print_report+0x167/0x540 mm/kasan/report.c:488 kasan_report+0x142/0x180 mm/kasan/report.c:601 rt6_fill_node+0x1460/0x1ac0 inet6_rt_notify+0x13b/0x290 net/ipv6/route.c:6184 ip6_route_mpath_notify net/ipv6/route.c:5198 [inline] ip6_route_multipath_add net/ipv6/route.c:5404 [inline] inet6_rtm_newroute+0x1d0f/0x2300 net/ipv6/route.c:5517 rtnetlink_rcv_msg+0x885/0x1040 net/core/rtnetlink.c:6597 netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2543 netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline] netlink_unicast+0x7ea/0x980 net/netlink/af_netlink.c:1367 netlink_sendmsg+0xa3b/0xd70 net/netlink/af_netlink.c:1908 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:745 _syssendmsg+0x525/0x7d0 net/socket.c:2584 _sys_sendmsg net/socket.c:2638 [inline] __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667 do_syscall_64+0xf9/0x240 entry_SYSCALL_64_after_hwframe+0x6f/0x77 RIP: 0033:0x7f73dd87dda9 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f73de6550c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f73dd9ac050 RCX: 00007f73dd87dda9 RDX: 0000000000000000 RSI: 0000000020000140 RDI: 0000000000000005 RBP: 00007f73dd8ca47a R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 000000000000006e R14: 00007f73dd9ac050 R15: 00007ffdbdeb7858 </TASK>
Allocated by task 23037: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:372 [inline] __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:389 kasan_kmalloc include/linux/kasan.h:211 [inline] __do_kmalloc_node mm/slub.c:3981 [inline] __kmalloc+0x22e/0x490 mm/slub.c:3994 kmalloc include/linux/slab.h:594 [inline] kzalloc include/linux/slab.h:711 [inline] fib6_info_alloc+0x2e/0xf0 net/ipv6/ip6_fib.c:155 ip6_route_info_create+0x445/0x12b0 net/ipv6/route.c:3758 ip6_route_multipath_add net/ipv6/route.c:5298 [inline] inet6_rtm_newroute+0x744/0x2300 net/ipv6/route.c:5517 rtnetlink_rcv_msg+0x885/0x1040 net/core/rtnetlink.c:6597 netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2543 netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline] netlink_unicast+0x7ea/0x980 net/netlink/af_netlink.c:1367 netlink_sendmsg+0xa3b/0xd70 net/netlink/af_netlink.c:1908 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:745 _syssendmsg+0x525/0x7d0 net/socket.c:2584 _sys_sendmsg net/socket.c:2638 [inline] __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667 do_syscall_64+0xf9/0x240 entry_SYSCALL_64_after_hwframe+0x6f/0x77
Freed by task 16: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x4e/0x60 mm/kasan/generic.c:640 poison_slab_object+0xa6/0xe0 m ---truncated---(CVE-2024-26852)
In the Linux kernel, the following vulnerability has been resolved:
inet: inet_defrag: prevent sk release while still in use
ip_local_out() and other functions can pass skb->sk as function argument.
If the skb is a fragment and reassembly happens before such function call returns, the sk must not be released.
This affects skb fragments reassembled via netfilter or similar modules, e.g. openvswitch or ct_act.c, when run as part of tx pipeline.
Eric Dumazet made an initial analysis of this bug. Quoting Eric: Calling ip_defrag() in output path is also implying skb_orphan(), which is buggy because output path relies on sk not disappearing.
A relevant old patch about the issue was : 8282f27449bf ("inet: frag: Always orphan skbs inside ip_defrag()")
[..]
net/ipv4/ip_output.c depends on skb->sk being set, and probably to an inet socket, not an arbitrary one.
If we orphan the packet in ipvlan, then downstream things like FQ packet scheduler will not work properly.
We need to change ip_defrag() to only use skb_orphan() when really needed, ie whenever frag_list is going to be used.
Eric suggested to stash sk in fragment queue and made an initial patch. However there is a problem with this:
If skb is refragmented again right after, ip_do_fragment() will copy head->sk to the new fragments, and sets up destructor to sock_wfree. IOW, we have no choice but to fix up sk_wmem accouting to reflect the fully reassembled skb, else wmem will underflow.
This change moves the orphan down into the core, to last possible moment. As ip_defrag_offset is aliased with sk_buff->sk member, we must move the offset into the FRAG_CB, else skb->sk gets clobbered.
This allows to delay the orphaning long enough to learn if the skb has to be queued or if the skb is completing the reasm queue.
In the former case, things work as before, skb is orphaned. This is safe because skb gets queued/stolen and won't continue past reasm engine.
In the latter case, we will steal the skb->sk reference, reattach it to the head skb, and fix up wmem accouting when inet_frag inflates truesize.(CVE-2024-26921)
In the Linux kernel, the following vulnerability has been resolved:
scsi: core: Fix unremoved procfs host directory regression
Commit fc663711b944 ("scsi: core: Remove the /proc/scsi/${proc_name} directory earlier") fixed a bug related to modules loading/unloading, by adding a call to scsi_proc_hostdir_rm() on scsi_remove_host(). But that led to a potential duplicate call to the hostdir_rm() routine, since it's also called from scsi_host_dev_release(). That triggered a regression report, which was then fixed by commit be03df3d4bfe ("scsi: core: Fix a procfs host directory removal regression"). The fix just dropped the hostdir_rm() call from dev_release().
But it happens that this proc directory is created on scsi_host_alloc(), and that function "pairs" with scsi_host_dev_release(), while scsi_remove_host() pairs with scsi_add_host(). In other words, it seems the reason for removing the proc directory on dev_release() was meant to cover cases in which a SCSI host structure was allocated, but the call to scsi_add_host() didn't happen. And that pattern happens to exist in some error paths, for example.
Syzkaller causes that by using USB raw gadget device, error'ing on usb-storage driver, at usb_stor_probe2(). By checking that path, we can see that the BadDevice label leads to a scsi_host_put() after a SCSI host allocation, but there's no call to scsi_add_host() in such path. That leads to messages like this in dmesg (and a leak of the SCSI host proc structure):
usb-storage 4-1:87.51: USB Mass Storage device detected proc_dir_entry 'scsi/usb-storage' already registered WARNING: CPU: 1 PID: 3519 at fs/proc/generic.c:377 proc_register+0x347/0x4e0 fs/proc/generic.c:376
The proper fix seems to still call scsi_proc_hostdir_rm() on dev_release(), but guard that with the state check for SHOST_CREATED; there is even a comment in scsi_host_dev_release() detailing that: such conditional is meant for cases where the SCSI host was allocated but there was no calls to {add,remove}_host(), like the usb-storage case.
This is what we propose here and with that, the error path of usb-storage does not trigger the warning anymore.(CVE-2024-26935)
In the Linux kernel, the following vulnerability has been resolved:
init/main.c: Fix potential static_command_line memory overflow
We allocate memory of size 'xlen + strlen(boot_command_line) + 1' for static_command_line, but the strings copied into static_command_line are extra_command_line and command_line, rather than extra_command_line and boot_command_line.
When strlen(command_line) > strlen(boot_command_line), static_command_line will overflow.
This patch just recovers strlen(command_line) which was miss-consolidated with strlen(boot_command_line) in the commit f5c7310ac73e ("init/main: add checks for the return value of memblock_alloc*()")(CVE-2024-26988)
In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to avoid potential panic during recovery
During recovery, if FAULT_BLOCK is on, it is possible that f2fs_reserve_new_block() will return -ENOSPC during recovery, then it may trigger panic.
Also, if fault injection rate is 1 and only FAULT_BLOCK fault type is on, it may encounter deadloop in loop of block reservation.
Let's change as below to fix these issues: - remove bug_on() to avoid panic. - limit the loop count of block reservation to avoid potential deadloop.(CVE-2024-27032)
In the Linux kernel, the following vulnerability has been resolved:
clk: Fix clk_core_get NULL dereference
It is possible for clk_core_get to dereference a NULL in the following sequence:
clk_core_get() of_clk_get_hw_from_clkspec() __of_clk_get_hw_from_provider() __clk_get_hw()
__clk_get_hw() can return NULL which is dereferenced by clk_core_get() at hw->core.
Prior to commit dde4eff47c82 ("clk: Look for parents with clkdev based clk_lookups") the check IS_ERR_OR_NULL() was performed which would have caught the NULL.
Reading the description of this function it talks about returning NULL but that cannot be so at the moment.
Update the function to check for hw before dereferencing it and return NULL if hw is NULL.(CVE-2024-27038)
In the Linux kernel, the following vulnerability has been resolved:
net: phy: fix phy_get_internal_delay accessing an empty array
The phy_get_internal_delay function could try to access to an empty array in the case that the driver is calling phy_get_internal_delay without defining delay_values and rx-internal-delay-ps or tx-internal-delay-ps is defined to 0 in the device-tree. This will lead to "unable to handle kernel NULL pointer dereference at virtual address 0". To avoid this kernel oops, the test should be delay >= 0. As there is already delay < 0 test just before, the test could only be size == 0.(CVE-2024-27047)
In the Linux kernel, the following vulnerability has been resolved:
wifi: rtl8xxxu: add cancel_work_sync() for c2hcmd_work
The workqueue might still be running, when the driver is stopped. To avoid a use-after-free, call cancel_work_sync() in rtl8xxxu_stop().(CVE-2024-27052)
In the Linux kernel, the following vulnerability has been resolved:
wifi: wilc1000: fix RCU usage in connect path
With lockdep enabled, calls to the connect function from cfg802.11 layer lead to the following warning:
============================= WARNING: suspicious RCU usage 6.7.0-rc1-wt+ #333 Not tainted
drivers/net/wireless/microchip/wilc1000/hif.c:386 suspicious rcu_dereference_check() usage! [...] stack backtrace: CPU: 0 PID: 100 Comm: wpa_supplicant Not tainted 6.7.0-rc1-wt+ #333 Hardware name: Atmel SAMA5 unwind_backtrace from show_stack+0x18/0x1c show_stack from dump_stack_lvl+0x34/0x48 dump_stack_lvl from wilc_parse_join_bss_param+0x7dc/0x7f4 wilc_parse_join_bss_param from connect+0x2c4/0x648 connect from cfg80211_connect+0x30c/0xb74 cfg80211_connect from nl80211_connect+0x860/0xa94 nl80211_connect from genl_rcv_msg+0x3fc/0x59c genl_rcv_msg from netlink_rcv_skb+0xd0/0x1f8 netlink_rcv_skb from genl_rcv+0x2c/0x3c genl_rcv from netlink_unicast+0x3b0/0x550 netlink_unicast from netlink_sendmsg+0x368/0x688 netlink_sendmsg from _syssendmsg+0x190/0x430 __sys_sendmsg from syssendmsg+0x110/0x158 _sys_sendmsg from sys_sendmsg+0xe8/0x150 sys_sendmsg from ret_fast_syscall+0x0/0x1c
This warning is emitted because in the connect path, when trying to parse target BSS parameters, we dereference a RCU pointer whithout being in RCU critical section. Fix RCU dereference usage by moving it to a RCU read critical section. To avoid wrapping the whole wilc_parse_join_bss_param under the critical section, just use the critical section to copy ies data(CVE-2024-27053)
In the Linux kernel, the following vulnerability has been resolved:
ipv6: fix potential "struct net" leak in inet6_rtm_getaddr()
It seems that if userspace provides a correct IFA_TARGET_NETNSID value but no IFA_ADDRESS and IFA_LOCAL attributes, inet6_rtm_getaddr() returns -EINVAL with an elevated "struct net" refcount.(CVE-2024-27417)
In the Linux kernel, the following vulnerability has been resolved:
genirq/cpuhotplug, x86/vector: Prevent vector leak during CPU offline
The absence of IRQD_MOVE_PCNTXT prevents immediate effectiveness of interrupt affinity reconfiguration via procfs. Instead, the change is deferred until the next instance of the interrupt being triggered on the original CPU.
When the interrupt next triggers on the original CPU, the new affinity is enforced within __irq_move_irq(). A vector is allocated from the new CPU, but the old vector on the original CPU remains and is not immediately reclaimed. Instead, apicd->move_in_progress is flagged, and the reclaiming process is delayed until the next trigger of the interrupt on the new CPU.
Upon the subsequent triggering of the interrupt on the new CPU, irq_complete_move() adds a task to the old CPU's vector_cleanup list if it remains online. Subsequently, the timer on the old CPU iterates over its vector_cleanup list, reclaiming old vectors.
However, a rare scenario arises if the old CPU is outgoing before the interrupt triggers again on the new CPU.
In that case irq_force_complete_move() is not invoked on the outgoing CPU to reclaim the old apicd->prev_vector because the interrupt isn't currently affine to the outgoing CPU, and irq_needs_fixup() returns false. Even though __vector_schedule_cleanup() is later called on the new CPU, it doesn't reclaim apicd->prev_vector; instead, it simply resets both apicd->move_in_progress and apicd->prev_vector to 0.
As a result, the vector remains unreclaimed in vector_matrix, leading to a CPU vector leak.
To address this issue, move the invocation of irq_force_complete_move() before the irq_needs_fixup() call to reclaim apicd->prev_vector, if the interrupt is currently or used to be affine to the outgoing CPU.
Additionally, reclaim the vector in __vector_schedule_cleanup() as well, following a warning message, although theoretically it should never see apicd->move_in_progress with apicd->prev_cpu pointing to an offline CPU.(CVE-2024-31076)
In the Linux kernel, the following vulnerability has been resolved:
wifi: brcmfmac: Fix use-after-free bug in brcmf_cfg80211_detach
This is the candidate patch of CVE-2023-47233 : https://nvd.nist.gov/vuln/detail/CVE-2023-47233
In brcm80211 driver,it starts with the following invoking chain to start init a timeout worker:
->brcmf_usb_probe ->brcmf_usb_probe_cb ->brcmf_attach ->brcmf_bus_started ->brcmf_cfg80211_attach ->wl_init_priv ->brcmf_init_escan ->INIT_WORK(&cfg->escan_timeout_work, brcmf_cfg80211_escan_timeout_worker);
If we disconnect the USB by hotplug, it will call brcmf_usb_disconnect to make cleanup. The invoking chain is :
brcmf_usb_disconnect ->brcmf_usb_disconnect_cb ->brcmf_detach ->brcmf_cfg80211_detach ->kfree(cfg);
While the timeout woker may still be running. This will cause a use-after-free bug on cfg in brcmf_cfg80211_escan_timeout_worker.
Fix it by deleting the timer and canceling the worker in brcmf_cfg80211_detach.
arend.vanspriel@broadcom.com: keep timer delete as is and cancel work just before free
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: amdgpu_ttm_gart_bind set gtt bound flag
Otherwise after the GTT bo is released, the GTT and gart space is freed but amdgpu_ttm_backend_unbind will not clear the gart page table entry and leave valid mapping entry pointing to the stale system page. Then if GPU access the gart address mistakely, it will read undefined value instead page fault, harder to debug and reproduce the real issue.(CVE-2024-35817)
In the Linux kernel, the following vulnerability has been resolved:
media: tc358743: register v4l2 async device only after successful setup
Ensure the device has been setup correctly before registering the v4l2 async device, thus allowing userspace to access.(CVE-2024-35830)
In the Linux kernel, the following vulnerability has been resolved:
dyndbg: fix old BUG_ON in >control parser
Fix a BUG_ON from 2009. Even if it looks "unreachable" (I didn't really look), lets make sure by removing it, doing pr_err and return -EINVAL instead.(CVE-2024-35947)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix division by zero in setup_dsc_config
When slice_height is 0, the division by slice_height in the calculation of the number of slices will cause a division by zero driver crash. This leaves the kernel in a state that requires a reboot. This patch adds a check to avoid the division by zero.
The stack trace below is for the 6.8.4 Kernel. I reproduced the issue on a Z16 Gen 2 Lenovo Thinkpad with a Apple Studio Display monitor connected via Thunderbolt. The amdgpu driver crashed with this exception when I rebooted the system with the monitor connected.
kernel: ? die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434 arch/x86/kernel/dumpstack.c:447) kernel: ? do_trap (arch/x86/kernel/traps.c:113 arch/x86/kernel/traps.c:154) kernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpu kernel: ? do_error_trap (./arch/x86/include/asm/traps.h:58 arch/x86/kernel/traps.c:175) kernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpu kernel: ? exc_divide_error (arch/x86/kernel/traps.c:194 (discriminator 2)) kernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpu kernel: ? asm_exc_divide_error (./arch/x86/include/asm/idtentry.h:548) kernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpu kernel: dc_dsc_compute_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1109) amdgpu
After applying this patch, the driver no longer crashes when the monitor is connected and the system is rebooted. I believe this is the same issue reported for 3113.(CVE-2024-36969)
In the Linux kernel, the following vulnerability has been resolved:
net: sched: sch_multiq: fix possible OOB write in multiq_tune()
q->bands will be assigned to qopt->bands to execute subsequent code logic after kmalloc. So the old q->bands should not be used in kmalloc. Otherwise, an out-of-bounds write will occur.(CVE-2024-36978)
In the Linux kernel, the following vulnerability has been resolved:
net: bridge: xmit: make sure we have at least eth header len bytes
syzbot triggered an uninit value[1] error in bridge device's xmit path by sending a short (less than ETH_HLEN bytes) skb. To fix it check if we can actually pull that amount instead of assuming.
Tested with dropwatch: drop at: br_dev_xmit+0xb93/0x12d0 [bridge] (0xffffffffc06739b3) origin: software timestamp: Mon May 13 11:31:53 2024 778214037 nsec protocol: 0x88a8 length: 2 original length: 2 drop reason: PKT_TOO_SMALL
[1] BUG: KMSAN: uninit-value in br_dev_xmit+0x61d/0x1cb0 net/bridge/br_device.c:65 br_dev_xmit+0x61d/0x1cb0 net/bridge/br_device.c:65 __netdev_start_xmit include/linux/netdevice.h:4903 [inline] netdev_start_xmit include/linux/netdevice.h:4917 [inline] xmit_one net/core/dev.c:3531 [inline] dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3547 __dev_queue_xmit+0x34db/0x5350 net/core/dev.c:4341 dev_queue_xmit include/linux/netdevice.h:3091 [inline] __bpf_tx_skb net/core/filter.c:2136 [inline] __bpf_redirect_common net/core/filter.c:2180 [inline] __bpf_redirect+0x14a6/0x1620 net/core/filter.c:2187 _bpfclone_redirect net/core/filter.c:2460 [inline] bpf_clone_redirect+0x328/0x470 net/core/filter.c:2432 _bpf_prog_run+0x13fe/0xe0f0 kernel/bpf/core.c:1997 __bpf_prog_run512+0xb5/0xe0 kernel/bpf/core.c:2238 bpf_dispatcher_nop_func include/linux/bpf.h:1234 [inline] __bpf_prog_run include/linux/filter.h:657 [inline] bpf_prog_run include/linux/filter.h:664 [inline] bpf_test_run+0x499/0xc30 net/bpf/test_run.c:425 bpf_prog_test_run_skb+0x14ea/0x1f20 net/bpf/test_run.c:1058 bpf_prog_test_run+0x6b7/0xad0 kernel/bpf/syscall.c:4269 __sys_bpf+0x6aa/0xd90 kernel/bpf/syscall.c:5678 __do_sys_bpf kernel/bpf/syscall.c:5767 [inline] __se_sys_bpf kernel/bpf/syscall.c:5765 [inline] __x64_sys_bpf+0xa0/0xe0 kernel/bpf/syscall.c:5765 x64_sys_call+0x96b/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:322 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2024-38538)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/hns: Fix UAF for cq async event
The refcount of CQ is not protected by locks. When CQ asynchronous events and CQ destruction are concurrent, CQ may have been released, which will cause UAF.
Use the xa_lock() to protect the CQ refcount.(CVE-2024-38545)
In the Linux kernel, the following vulnerability has been resolved:
drm/mediatek: Add 0 size check to mtk_drm_gem_obj
Add a check to mtk_drm_gem_init if we attempt to allocate a GEM object of 0 bytes. Currently, no such check exists and the kernel will panic if a userspace application attempts to allocate a 0x0 GBM buffer.
Tested by attempting to allocate a 0x0 GBM buffer on an MT8188 and verifying that we now return EINVAL.(CVE-2024-38549)
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: Discard command completions in internal error
Fix use after free when FW completion arrives while device is in internal error state. Avoid calling completion handler in this case, since the device will flush the command interface and trigger all completions manually.
Kernel log: ------------[ cut here ]------------ refcount_t: underflow; use-after-free. ... RIP: 0010:refcount_warn_saturate+0xd8/0xe0 ... Call Trace: <IRQ> ? __warn+0x79/0x120 ? refcount_warn_saturate+0xd8/0xe0 ? report_bug+0x17c/0x190 ? handle_bug+0x3c/0x60 ? exc_invalid_op+0x14/0x70 ? asm_exc_invalid_op+0x16/0x20 ? refcount_warn_saturate+0xd8/0xe0 cmd_ent_put+0x13b/0x160 [mlx5_core] mlx5_cmd_comp_handler+0x5f9/0x670 [mlx5_core] cmd_comp_notifier+0x1f/0x30 [mlx5_core] notifier_call_chain+0x35/0xb0 atomic_notifier_call_chain+0x16/0x20 mlx5_eq_async_int+0xf6/0x290 [mlx5_core] notifier_call_chain+0x35/0xb0 atomic_notifier_call_chain+0x16/0x20 irq_int_handler+0x19/0x30 [mlx5_core] __handle_irq_event_percpu+0x4b/0x160 handle_irq_event+0x2e/0x80 handle_edge_irq+0x98/0x230 __common_interrupt+0x3b/0xa0 common_interrupt+0x7b/0xa0 </IRQ> <TASK> asm_common_interrupt+0x22/0x40(CVE-2024-38555)
In the Linux kernel, the following vulnerability has been resolved:
drivers/perf: hisi_pcie: Fix out-of-bound access when valid event group
The perf tool allows users to create event groups through following cmd [1], but the driver does not check whether the array index is out of bounds when writing data to the event_group array. If the number of events in an event_group is greater than HISI_PCIE_MAX_COUNTERS, the memory write overflow of event_group array occurs.
Add array index check to fix the possible array out of bounds violation, and return directly when write new events are written to array bounds.
There are 9 different events in an event_group. [1] perf stat -e '{pmu/event1/, ... ,pmu/event9/}'(CVE-2024-38569)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/hns: Fix deadlock on SRQ async events.
xa_lock for SRQ table may be required in AEQ. Use xa_store_irq()/ xa_erase_irq() to avoid deadlock.(CVE-2024-38591)
In the Linux kernel, the following vulnerability has been resolved:
ring-buffer: Fix a race between readers and resize checks
The reader code in rb_get_reader_page() swaps a new reader page into the ring buffer by doing cmpxchg on old->list.prev->next to point it to the new page. Following that, if the operation is successful, old->list.next->prev gets updated too. This means the underlying doubly-linked list is temporarily inconsistent, page->prev->next or page->next->prev might not be equal back to page for some page in the ring buffer.
The resize operation in ring_buffer_resize() can be invoked in parallel. It calls rb_check_pages() which can detect the described inconsistency and stop further tracing:
[ 190.271762] ------------[ cut here ]------------ [ 190.271771] WARNING: CPU: 1 PID: 6186 at kernel/trace/ring_buffer.c:1467 rb_check_pages.isra.0+0x6a/0xa0 [ 190.271789] Modules linked in: [...] [ 190.271991] Unloaded tainted modules: intel_uncore_frequency(E):1 skx_edac(E):1 [ 190.272002] CPU: 1 PID: 6186 Comm: cmd.sh Kdump: loaded Tainted: G E 6.9.0-rc6-default #5 158d3e1e6d0b091c34c3b96bfd99a1c58306d79f [ 190.272011] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552c-rebuilt.opensuse.org 04/01/2014 [ 190.272015] RIP: 0010:rb_check_pages.isra.0+0x6a/0xa0 [ 190.272023] Code: [...] [ 190.272028] RSP: 0018:ffff9c37463abb70 EFLAGS: 00010206 [ 190.272034] RAX: ffff8eba04b6cb80 RBX: 0000000000000007 RCX: ffff8eba01f13d80 [ 190.272038] RDX: ffff8eba01f130c0 RSI: ffff8eba04b6cd00 RDI: ffff8eba0004c700 [ 190.272042] RBP: ffff8eba0004c700 R08: 0000000000010002 R09: 0000000000000000 [ 190.272045] R10: 00000000ffff7f52 R11: ffff8eba7f600000 R12: ffff8eba0004c720 [ 190.272049] R13: ffff8eba00223a00 R14: 0000000000000008 R15: ffff8eba067a8000 [ 190.272053] FS: 00007f1bd64752c0(0000) GS:ffff8eba7f680000(0000) knlGS:0000000000000000 [ 190.272057] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 190.272061] CR2: 00007f1bd6662590 CR3: 000000010291e001 CR4: 0000000000370ef0 [ 190.272070] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 190.272073] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 190.272077] Call Trace: [ 190.272098] <TASK> [ 190.272189] ring_buffer_resize+0x2ab/0x460 [ 190.272199] __tracing_resize_ring_buffer.part.0+0x23/0xa0 [ 190.272206] tracing_resize_ring_buffer+0x65/0x90 [ 190.272216] tracing_entries_write+0x74/0xc0 [ 190.272225] vfs_write+0xf5/0x420 [ 190.272248] ksys_write+0x67/0xe0 [ 190.272256] do_syscall_64+0x82/0x170 [ 190.272363] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 190.272373] RIP: 0033:0x7f1bd657d263 [ 190.272381] Code: [...] [ 190.272385] RSP: 002b:00007ffe72b643f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ 190.272391] RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007f1bd657d263 [ 190.272395] RDX: 0000000000000002 RSI: 0000555a6eb538e0 RDI: 0000000000000001 [ 190.272398] RBP: 0000555a6eb538e0 R08: 000000000000000a R09: 0000000000000000 [ 190.272401] R10: 0000555a6eb55190 R11: 0000000000000246 R12: 00007f1bd6662500 [ 190.272404] R13: 0000000000000002 R14: 00007f1bd6667c00 R15: 0000000000000002 [ 190.272412] </TASK> [ 190.272414] ---[ end trace 0000000000000000 ]---
Note that ring_buffer_resize() calls rb_check_pages() only if the parent trace_buffer has recording disabled. Recent commit d78ab792705c ("tracing: Stop current tracer when resizing buffer") causes that it is now always the case which makes it more likely to experience this issue.
The window to hit this race is nonetheless very small. To help reproducing it, one can add a delay loop in rb_get_reader_page():
ret = rb_head_page_replace(reader, cpu_buffer->reader_page); if (!ret) goto spin; for (unsigned i = 0; i < 1U << 26; i++) / inserted delay loop / asm volatile ("" : : : "memory"); rb_list_head(reader->list.next)->prev = &cpu_buffer->reader_page->list;
.. ---truncated---(CVE-2024-38601)
In the Linux kernel, the following vulnerability has been resolved:
serial: max3100: Lock port->lock when calling uart_handle_cts_change()
uart_handle_cts_change() has to be called with port lock taken, Since we run it in a separate work, the lock may not be taken at the time of running. Make sure that it's taken by explicitly doing that. Without it we got a splat:
WARNING: CPU: 0 PID: 10 at drivers/tty/serial/serial_core.c:3491 uart_handle_cts_change+0xa6/0xb0 ... Workqueue: max3100-0 max3100_work [max3100] RIP: 0010:uart_handle_cts_change+0xa6/0xb0 ... max3100_handlerx+0xc5/0x110 [max3100] max3100_work+0x12a/0x340 max3100
In the Linux kernel, the following vulnerability has been resolved:
bpf: Allow delete from sockmap/sockhash only if update is allowed
We have seen an influx of syzkaller reports where a BPF program attached to a tracepoint triggers a locking rule violation by performing a map_delete on a sockmap/sockhash.
We don't intend to support this artificial use scenario. Extend the existing verifier allowed-program-type check for updating sockmap/sockhash to also cover deleting from a map.
From now on only BPF programs which were previously allowed to update sockmap/sockhash can delete from these map types.(CVE-2024-38662)
| URL | Type | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"kernel-tools-debuginfo-5.10.0-136.82.0.163.oe2203sp1.aarch64.rpm",
"kernel-tools-devel-5.10.0-136.82.0.163.oe2203sp1.aarch64.rpm",
"kernel-debuginfo-5.10.0-136.82.0.163.oe2203sp1.aarch64.rpm",
"kernel-tools-5.10.0-136.82.0.163.oe2203sp1.aarch64.rpm",
"python3-perf-5.10.0-136.82.0.163.oe2203sp1.aarch64.rpm",
"kernel-debugsource-5.10.0-136.82.0.163.oe2203sp1.aarch64.rpm",
"kernel-source-5.10.0-136.82.0.163.oe2203sp1.aarch64.rpm",
"perf-debuginfo-5.10.0-136.82.0.163.oe2203sp1.aarch64.rpm",
"kernel-devel-5.10.0-136.82.0.163.oe2203sp1.aarch64.rpm",
"perf-5.10.0-136.82.0.163.oe2203sp1.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-136.82.0.163.oe2203sp1.aarch64.rpm",
"kernel-5.10.0-136.82.0.163.oe2203sp1.aarch64.rpm",
"kernel-headers-5.10.0-136.82.0.163.oe2203sp1.aarch64.rpm"
],
"src": [
"kernel-5.10.0-136.82.0.163.oe2203sp1.src.rpm"
],
"x86_64": [
"kernel-tools-5.10.0-136.82.0.163.oe2203sp1.x86_64.rpm",
"kernel-tools-debuginfo-5.10.0-136.82.0.163.oe2203sp1.x86_64.rpm",
"kernel-headers-5.10.0-136.82.0.163.oe2203sp1.x86_64.rpm",
"kernel-debugsource-5.10.0-136.82.0.163.oe2203sp1.x86_64.rpm",
"kernel-tools-devel-5.10.0-136.82.0.163.oe2203sp1.x86_64.rpm",
"perf-debuginfo-5.10.0-136.82.0.163.oe2203sp1.x86_64.rpm",
"python3-perf-debuginfo-5.10.0-136.82.0.163.oe2203sp1.x86_64.rpm",
"kernel-source-5.10.0-136.82.0.163.oe2203sp1.x86_64.rpm",
"python3-perf-5.10.0-136.82.0.163.oe2203sp1.x86_64.rpm",
"perf-5.10.0-136.82.0.163.oe2203sp1.x86_64.rpm",
"kernel-5.10.0-136.82.0.163.oe2203sp1.x86_64.rpm",
"kernel-devel-5.10.0-136.82.0.163.oe2203sp1.x86_64.rpm",
"kernel-debuginfo-5.10.0-136.82.0.163.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.82.0.163.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\nASoC: SOF: Fix DSP oops stack dump output contents\r\n\r\nFix @buf arg given to hex_dump_to_buffer() and stack address used\nin dump error output.(CVE-2021-47381)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: iscsi: Fix iscsi_task use after free\r\n\r\nCommit d39df158518c (\u0026quot;scsi: iscsi: Have abort handler get ref to conn\u0026quot;)\nadded iscsi_get_conn()/iscsi_put_conn() calls during abort handling but\nthen also changed the handling of the case where we detect an already\ncompleted task where we now end up doing a goto to the common put/cleanup\ncode. This results in a iscsi_task use after free, because the common\ncleanup code will do a put on the iscsi_task.\r\n\r\nThis reverts the goto and moves the iscsi_get_conn() to after we\u0026apos;ve checked\nif the iscsi_task is valid.(CVE-2021-47427)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nspi: Fix deadlock when adding SPI controllers on SPI buses\r\n\r\nCurrently we have a global spi_add_lock which we take when adding new\ndevices so that we can check that we\u0026apos;re not trying to reuse a chip\nselect that\u0026apos;s already controlled. This means that if the SPI device is\nitself a SPI controller and triggers the instantiation of further SPI\ndevices we trigger a deadlock as we try to register and instantiate\nthose devices while in the process of doing so for the parent controller\nand hence already holding the global spi_add_lock. Since we only care\nabout concurrency within a single SPI bus move the lock to be per\ncontroller, avoiding the deadlock.\r\n\r\nThis can be easily triggered in the case of spi-mux.(CVE-2021-47469)\r\n\r\n(CVE-2023-39180)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npowerpc/powernv: Add a null pointer check in opal_powercap_init()\r\n\r\nkasprintf() returns a pointer to dynamically allocated memory\nwhich can be NULL upon failure.(CVE-2023-52696)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ni2c: core: Run atomic i2c xfer when !preemptible\r\n\r\nSince bae1d3a05a8b, i2c transfers are non-atomic if preemption is\ndisabled. However, non-atomic i2c transfers require preemption (e.g. in\nwait_for_completion() while waiting for the DMA).\r\n\r\npanic() calls preempt_disable_notrace() before calling\nemergency_restart(). Therefore, if an i2c device is used for the\nrestart, the xfer should be atomic. This avoids warnings like:\r\n\r\n[ 12.667612] WARNING: CPU: 1 PID: 1 at kernel/rcu/tree_plugin.h:318 rcu_note_context_switch+0x33c/0x6b0\n[ 12.676926] Voluntary context switch within RCU read-side critical section!\n...\n[ 12.742376] schedule_timeout from wait_for_completion_timeout+0x90/0x114\n[ 12.749179] wait_for_completion_timeout from tegra_i2c_wait_completion+0x40/0x70\n...\n[ 12.994527] atomic_notifier_call_chain from machine_restart+0x34/0x58\n[ 13.001050] machine_restart from panic+0x2a8/0x32c\r\n\r\nUse !preemptible() instead, which is basically the same check as\npre-v5.2.(CVE-2023-52791)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nhid: cp2112: Fix duplicate workqueue initialization\r\n\r\nPreviously the cp2112 driver called INIT_DELAYED_WORK within\ncp2112_gpio_irq_startup, resulting in duplicate initilizations of the\nworkqueue on subsequent IRQ startups following an initial request. This\nresulted in a warning in set_work_data in workqueue.c, as well as a rare\nNULL dereference within process_one_work in workqueue.c.\r\n\r\nInitialize the workqueue within _probe instead.(CVE-2023-52853)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nksmbd: fix UAF issue in ksmbd_tcp_new_connection()\r\n\r\nThe race is between the handling of a new TCP connection and\nits disconnection. It leads to UAF on `struct tcp_transport` in\nksmbd_tcp_new_connection() function.(CVE-2024-26592)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/ipv6: avoid possible UAF in ip6_route_mpath_notify()\r\n\r\nsyzbot found another use-after-free in ip6_route_mpath_notify() [1]\r\n\r\nCommit f7225172f25a (\u0026quot;net/ipv6: prevent use after free in\nip6_route_mpath_notify\u0026quot;) was not able to fix the root cause.\r\n\r\nWe need to defer the fib6_info_release() calls after\nip6_route_mpath_notify(), in the cleanup phase.\r\n\r\n[1]\nBUG: KASAN: slab-use-after-free in rt6_fill_node+0x1460/0x1ac0\nRead of size 4 at addr ffff88809a07fc64 by task syz-executor.2/23037\r\n\r\nCPU: 0 PID: 23037 Comm: syz-executor.2 Not tainted 6.8.0-rc4-syzkaller-01035-gea7f3cfaa588 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0x1e7/0x2e0 lib/dump_stack.c:106\n print_address_description mm/kasan/report.c:377 [inline]\n print_report+0x167/0x540 mm/kasan/report.c:488\n kasan_report+0x142/0x180 mm/kasan/report.c:601\n rt6_fill_node+0x1460/0x1ac0\n inet6_rt_notify+0x13b/0x290 net/ipv6/route.c:6184\n ip6_route_mpath_notify net/ipv6/route.c:5198 [inline]\n ip6_route_multipath_add net/ipv6/route.c:5404 [inline]\n inet6_rtm_newroute+0x1d0f/0x2300 net/ipv6/route.c:5517\n rtnetlink_rcv_msg+0x885/0x1040 net/core/rtnetlink.c:6597\n netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2543\n netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline]\n netlink_unicast+0x7ea/0x980 net/netlink/af_netlink.c:1367\n netlink_sendmsg+0xa3b/0xd70 net/netlink/af_netlink.c:1908\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg+0x221/0x270 net/socket.c:745\n ____sys_sendmsg+0x525/0x7d0 net/socket.c:2584\n ___sys_sendmsg net/socket.c:2638 [inline]\n __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667\n do_syscall_64+0xf9/0x240\n entry_SYSCALL_64_after_hwframe+0x6f/0x77\nRIP: 0033:0x7f73dd87dda9\nCode: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007f73de6550c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e\nRAX: ffffffffffffffda RBX: 00007f73dd9ac050 RCX: 00007f73dd87dda9\nRDX: 0000000000000000 RSI: 0000000020000140 RDI: 0000000000000005\nRBP: 00007f73dd8ca47a R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000\nR13: 000000000000006e R14: 00007f73dd9ac050 R15: 00007ffdbdeb7858\n \u0026lt;/TASK\u0026gt;\r\n\r\nAllocated by task 23037:\n kasan_save_stack mm/kasan/common.c:47 [inline]\n kasan_save_track+0x3f/0x80 mm/kasan/common.c:68\n poison_kmalloc_redzone mm/kasan/common.c:372 [inline]\n __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:389\n kasan_kmalloc include/linux/kasan.h:211 [inline]\n __do_kmalloc_node mm/slub.c:3981 [inline]\n __kmalloc+0x22e/0x490 mm/slub.c:3994\n kmalloc include/linux/slab.h:594 [inline]\n kzalloc include/linux/slab.h:711 [inline]\n fib6_info_alloc+0x2e/0xf0 net/ipv6/ip6_fib.c:155\n ip6_route_info_create+0x445/0x12b0 net/ipv6/route.c:3758\n ip6_route_multipath_add net/ipv6/route.c:5298 [inline]\n inet6_rtm_newroute+0x744/0x2300 net/ipv6/route.c:5517\n rtnetlink_rcv_msg+0x885/0x1040 net/core/rtnetlink.c:6597\n netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2543\n netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline]\n netlink_unicast+0x7ea/0x980 net/netlink/af_netlink.c:1367\n netlink_sendmsg+0xa3b/0xd70 net/netlink/af_netlink.c:1908\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg+0x221/0x270 net/socket.c:745\n ____sys_sendmsg+0x525/0x7d0 net/socket.c:2584\n ___sys_sendmsg net/socket.c:2638 [inline]\n __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667\n do_syscall_64+0xf9/0x240\n entry_SYSCALL_64_after_hwframe+0x6f/0x77\r\n\r\nFreed by task 16:\n kasan_save_stack mm/kasan/common.c:47 [inline]\n kasan_save_track+0x3f/0x80 mm/kasan/common.c:68\n kasan_save_free_info+0x4e/0x60 mm/kasan/generic.c:640\n poison_slab_object+0xa6/0xe0 m\n---truncated---(CVE-2024-26852)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ninet: inet_defrag: prevent sk release while still in use\r\n\r\nip_local_out() and other functions can pass skb-\u0026gt;sk as function argument.\r\n\r\nIf the skb is a fragment and reassembly happens before such function call\nreturns, the sk must not be released.\r\n\r\nThis affects skb fragments reassembled via netfilter or similar\nmodules, e.g. openvswitch or ct_act.c, when run as part of tx pipeline.\r\n\r\nEric Dumazet made an initial analysis of this bug. Quoting Eric:\n Calling ip_defrag() in output path is also implying skb_orphan(),\n which is buggy because output path relies on sk not disappearing.\r\n\r\n A relevant old patch about the issue was :\n 8282f27449bf (\u0026quot;inet: frag: Always orphan skbs inside ip_defrag()\u0026quot;)\r\n\r\n [..]\r\n\r\n net/ipv4/ip_output.c depends on skb-\u0026gt;sk being set, and probably to an\n inet socket, not an arbitrary one.\r\n\r\n If we orphan the packet in ipvlan, then downstream things like FQ\n packet scheduler will not work properly.\r\n\r\n We need to change ip_defrag() to only use skb_orphan() when really\n needed, ie whenever frag_list is going to be used.\r\n\r\nEric suggested to stash sk in fragment queue and made an initial patch.\nHowever there is a problem with this:\r\n\r\nIf skb is refragmented again right after, ip_do_fragment() will copy\nhead-\u0026gt;sk to the new fragments, and sets up destructor to sock_wfree.\nIOW, we have no choice but to fix up sk_wmem accouting to reflect the\nfully reassembled skb, else wmem will underflow.\r\n\r\nThis change moves the orphan down into the core, to last possible moment.\nAs ip_defrag_offset is aliased with sk_buff-\u0026gt;sk member, we must move the\noffset into the FRAG_CB, else skb-\u0026gt;sk gets clobbered.\r\n\r\nThis allows to delay the orphaning long enough to learn if the skb has\nto be queued or if the skb is completing the reasm queue.\r\n\r\nIn the former case, things work as before, skb is orphaned. This is\nsafe because skb gets queued/stolen and won\u0026apos;t continue past reasm engine.\r\n\r\nIn the latter case, we will steal the skb-\u0026gt;sk reference, reattach it to\nthe head skb, and fix up wmem accouting when inet_frag inflates truesize.(CVE-2024-26921)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: core: Fix unremoved procfs host directory regression\r\n\r\nCommit fc663711b944 (\u0026quot;scsi: core: Remove the /proc/scsi/${proc_name}\ndirectory earlier\u0026quot;) fixed a bug related to modules loading/unloading, by\nadding a call to scsi_proc_hostdir_rm() on scsi_remove_host(). But that led\nto a potential duplicate call to the hostdir_rm() routine, since it\u0026apos;s also\ncalled from scsi_host_dev_release(). That triggered a regression report,\nwhich was then fixed by commit be03df3d4bfe (\u0026quot;scsi: core: Fix a procfs host\ndirectory removal regression\u0026quot;). The fix just dropped the hostdir_rm() call\nfrom dev_release().\r\n\r\nBut it happens that this proc directory is created on scsi_host_alloc(),\nand that function \u0026quot;pairs\u0026quot; with scsi_host_dev_release(), while\nscsi_remove_host() pairs with scsi_add_host(). In other words, it seems the\nreason for removing the proc directory on dev_release() was meant to cover\ncases in which a SCSI host structure was allocated, but the call to\nscsi_add_host() didn\u0026apos;t happen. And that pattern happens to exist in some\nerror paths, for example.\r\n\r\nSyzkaller causes that by using USB raw gadget device, error\u0026apos;ing on\nusb-storage driver, at usb_stor_probe2(). By checking that path, we can see\nthat the BadDevice label leads to a scsi_host_put() after a SCSI host\nallocation, but there\u0026apos;s no call to scsi_add_host() in such path. That leads\nto messages like this in dmesg (and a leak of the SCSI host proc\nstructure):\r\n\r\nusb-storage 4-1:87.51: USB Mass Storage device detected\nproc_dir_entry \u0026apos;scsi/usb-storage\u0026apos; already registered\nWARNING: CPU: 1 PID: 3519 at fs/proc/generic.c:377 proc_register+0x347/0x4e0 fs/proc/generic.c:376\r\n\r\nThe proper fix seems to still call scsi_proc_hostdir_rm() on dev_release(),\nbut guard that with the state check for SHOST_CREATED; there is even a\ncomment in scsi_host_dev_release() detailing that: such conditional is\nmeant for cases where the SCSI host was allocated but there was no calls to\n{add,remove}_host(), like the usb-storage case.\r\n\r\nThis is what we propose here and with that, the error path of usb-storage\ndoes not trigger the warning anymore.(CVE-2024-26935)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ninit/main.c: Fix potential static_command_line memory overflow\r\n\r\nWe allocate memory of size \u0026apos;xlen + strlen(boot_command_line) + 1\u0026apos; for\nstatic_command_line, but the strings copied into static_command_line are\nextra_command_line and command_line, rather than extra_command_line and\nboot_command_line.\r\n\r\nWhen strlen(command_line) \u0026gt; strlen(boot_command_line), static_command_line\nwill overflow.\r\n\r\nThis patch just recovers strlen(command_line) which was miss-consolidated\nwith strlen(boot_command_line) in the commit f5c7310ac73e (\u0026quot;init/main: add\nchecks for the return value of memblock_alloc*()\u0026quot;)(CVE-2024-26988)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nf2fs: fix to avoid potential panic during recovery\r\n\r\nDuring recovery, if FAULT_BLOCK is on, it is possible that\nf2fs_reserve_new_block() will return -ENOSPC during recovery,\nthen it may trigger panic.\r\n\r\nAlso, if fault injection rate is 1 and only FAULT_BLOCK fault\ntype is on, it may encounter deadloop in loop of block reservation.\r\n\r\nLet\u0026apos;s change as below to fix these issues:\n- remove bug_on() to avoid panic.\n- limit the loop count of block reservation to avoid potential\ndeadloop.(CVE-2024-27032)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nclk: Fix clk_core_get NULL dereference\r\n\r\nIt is possible for clk_core_get to dereference a NULL in the following\nsequence:\r\n\r\nclk_core_get()\n of_clk_get_hw_from_clkspec()\n __of_clk_get_hw_from_provider()\n __clk_get_hw()\r\n\r\n__clk_get_hw() can return NULL which is dereferenced by clk_core_get() at\nhw-\u0026gt;core.\r\n\r\nPrior to commit dde4eff47c82 (\u0026quot;clk: Look for parents with clkdev based\nclk_lookups\u0026quot;) the check IS_ERR_OR_NULL() was performed which would have\ncaught the NULL.\r\n\r\nReading the description of this function it talks about returning NULL but\nthat cannot be so at the moment.\r\n\r\nUpdate the function to check for hw before dereferencing it and return NULL\nif hw is NULL.(CVE-2024-27038)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: phy: fix phy_get_internal_delay accessing an empty array\r\n\r\nThe phy_get_internal_delay function could try to access to an empty\narray in the case that the driver is calling phy_get_internal_delay\nwithout defining delay_values and rx-internal-delay-ps or\ntx-internal-delay-ps is defined to 0 in the device-tree.\nThis will lead to \u0026quot;unable to handle kernel NULL pointer dereference at\nvirtual address 0\u0026quot;. To avoid this kernel oops, the test should be delay\n\u0026gt;= 0. As there is already delay \u0026lt; 0 test just before, the test could\nonly be size == 0.(CVE-2024-27047)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: rtl8xxxu: add cancel_work_sync() for c2hcmd_work\r\n\r\nThe workqueue might still be running, when the driver is stopped. To\navoid a use-after-free, call cancel_work_sync() in rtl8xxxu_stop().(CVE-2024-27052)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: wilc1000: fix RCU usage in connect path\r\n\r\nWith lockdep enabled, calls to the connect function from cfg802.11 layer\nlead to the following warning:\r\n\r\n=============================\nWARNING: suspicious RCU usage\n6.7.0-rc1-wt+ #333 Not tainted\n-----------------------------\ndrivers/net/wireless/microchip/wilc1000/hif.c:386\nsuspicious rcu_dereference_check() usage!\n[...]\nstack backtrace:\nCPU: 0 PID: 100 Comm: wpa_supplicant Not tainted 6.7.0-rc1-wt+ #333\nHardware name: Atmel SAMA5\n unwind_backtrace from show_stack+0x18/0x1c\n show_stack from dump_stack_lvl+0x34/0x48\n dump_stack_lvl from wilc_parse_join_bss_param+0x7dc/0x7f4\n wilc_parse_join_bss_param from connect+0x2c4/0x648\n connect from cfg80211_connect+0x30c/0xb74\n cfg80211_connect from nl80211_connect+0x860/0xa94\n nl80211_connect from genl_rcv_msg+0x3fc/0x59c\n genl_rcv_msg from netlink_rcv_skb+0xd0/0x1f8\n netlink_rcv_skb from genl_rcv+0x2c/0x3c\n genl_rcv from netlink_unicast+0x3b0/0x550\n netlink_unicast from netlink_sendmsg+0x368/0x688\n netlink_sendmsg from ____sys_sendmsg+0x190/0x430\n ____sys_sendmsg from ___sys_sendmsg+0x110/0x158\n ___sys_sendmsg from sys_sendmsg+0xe8/0x150\n sys_sendmsg from ret_fast_syscall+0x0/0x1c\r\n\r\nThis warning is emitted because in the connect path, when trying to parse\ntarget BSS parameters, we dereference a RCU pointer whithout being in RCU\ncritical section.\nFix RCU dereference usage by moving it to a RCU read critical section. To\navoid wrapping the whole wilc_parse_join_bss_param under the critical\nsection, just use the critical section to copy ies data(CVE-2024-27053)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nipv6: fix potential \u0026quot;struct net\u0026quot; leak in inet6_rtm_getaddr()\r\n\r\nIt seems that if userspace provides a correct IFA_TARGET_NETNSID value\nbut no IFA_ADDRESS and IFA_LOCAL attributes, inet6_rtm_getaddr()\nreturns -EINVAL with an elevated \u0026quot;struct net\u0026quot; refcount.(CVE-2024-27417)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ngenirq/cpuhotplug, x86/vector: Prevent vector leak during CPU offline\r\n\r\nThe absence of IRQD_MOVE_PCNTXT prevents immediate effectiveness of\ninterrupt affinity reconfiguration via procfs. Instead, the change is\ndeferred until the next instance of the interrupt being triggered on the\noriginal CPU.\r\n\r\nWhen the interrupt next triggers on the original CPU, the new affinity is\nenforced within __irq_move_irq(). A vector is allocated from the new CPU,\nbut the old vector on the original CPU remains and is not immediately\nreclaimed. Instead, apicd-\u0026gt;move_in_progress is flagged, and the reclaiming\nprocess is delayed until the next trigger of the interrupt on the new CPU.\r\n\r\nUpon the subsequent triggering of the interrupt on the new CPU,\nirq_complete_move() adds a task to the old CPU\u0026apos;s vector_cleanup list if it\nremains online. Subsequently, the timer on the old CPU iterates over its\nvector_cleanup list, reclaiming old vectors.\r\n\r\nHowever, a rare scenario arises if the old CPU is outgoing before the\ninterrupt triggers again on the new CPU.\r\n\r\nIn that case irq_force_complete_move() is not invoked on the outgoing CPU\nto reclaim the old apicd-\u0026gt;prev_vector because the interrupt isn\u0026apos;t currently\naffine to the outgoing CPU, and irq_needs_fixup() returns false. Even\nthough __vector_schedule_cleanup() is later called on the new CPU, it\ndoesn\u0026apos;t reclaim apicd-\u0026gt;prev_vector; instead, it simply resets both\napicd-\u0026gt;move_in_progress and apicd-\u0026gt;prev_vector to 0.\r\n\r\nAs a result, the vector remains unreclaimed in vector_matrix, leading to a\nCPU vector leak.\r\n\r\nTo address this issue, move the invocation of irq_force_complete_move()\nbefore the irq_needs_fixup() call to reclaim apicd-\u0026gt;prev_vector, if the\ninterrupt is currently or used to be affine to the outgoing CPU.\r\n\r\nAdditionally, reclaim the vector in __vector_schedule_cleanup() as well,\nfollowing a warning message, although theoretically it should never see\napicd-\u0026gt;move_in_progress with apicd-\u0026gt;prev_cpu pointing to an offline CPU.(CVE-2024-31076)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: brcmfmac: Fix use-after-free bug in brcmf_cfg80211_detach\r\n\r\nThis is the candidate patch of CVE-2023-47233 :\nhttps://nvd.nist.gov/vuln/detail/CVE-2023-47233\r\n\r\nIn brcm80211 driver,it starts with the following invoking chain\nto start init a timeout worker:\r\n\r\n-\u0026gt;brcmf_usb_probe\n -\u0026gt;brcmf_usb_probe_cb\n -\u0026gt;brcmf_attach\n -\u0026gt;brcmf_bus_started\n -\u0026gt;brcmf_cfg80211_attach\n -\u0026gt;wl_init_priv\n -\u0026gt;brcmf_init_escan\n -\u0026gt;INIT_WORK(\u0026amp;cfg-\u0026gt;escan_timeout_work,\n\t\t brcmf_cfg80211_escan_timeout_worker);\r\n\r\nIf we disconnect the USB by hotplug, it will call\nbrcmf_usb_disconnect to make cleanup. The invoking chain is :\r\n\r\nbrcmf_usb_disconnect\n -\u0026gt;brcmf_usb_disconnect_cb\n -\u0026gt;brcmf_detach\n -\u0026gt;brcmf_cfg80211_detach\n -\u0026gt;kfree(cfg);\r\n\r\nWhile the timeout woker may still be running. This will cause\na use-after-free bug on cfg in brcmf_cfg80211_escan_timeout_worker.\r\n\r\nFix it by deleting the timer and canceling the worker in\nbrcmf_cfg80211_detach.\r\n\r\n[arend.vanspriel@broadcom.com: keep timer delete as is and cancel work just before free](CVE-2024-35811)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: amdgpu_ttm_gart_bind set gtt bound flag\r\n\r\nOtherwise after the GTT bo is released, the GTT and gart space is freed\nbut amdgpu_ttm_backend_unbind will not clear the gart page table entry\nand leave valid mapping entry pointing to the stale system page. Then\nif GPU access the gart address mistakely, it will read undefined value\ninstead page fault, harder to debug and reproduce the real issue.(CVE-2024-35817)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: tc358743: register v4l2 async device only after successful setup\r\n\r\nEnsure the device has been setup correctly before registering the v4l2\nasync device, thus allowing userspace to access.(CVE-2024-35830)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndyndbg: fix old BUG_ON in \u0026gt;control parser\r\n\r\nFix a BUG_ON from 2009. Even if it looks \u0026quot;unreachable\u0026quot; (I didn\u0026apos;t\nreally look), lets make sure by removing it, doing pr_err and return\n-EINVAL instead.(CVE-2024-35947)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Fix division by zero in setup_dsc_config\r\n\r\nWhen slice_height is 0, the division by slice_height in the calculation\nof the number of slices will cause a division by zero driver crash. This\nleaves the kernel in a state that requires a reboot. This patch adds a\ncheck to avoid the division by zero.\r\n\r\nThe stack trace below is for the 6.8.4 Kernel. I reproduced the issue on\na Z16 Gen 2 Lenovo Thinkpad with a Apple Studio Display monitor\nconnected via Thunderbolt. The amdgpu driver crashed with this exception\nwhen I rebooted the system with the monitor connected.\r\n\r\nkernel: ? die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434 arch/x86/kernel/dumpstack.c:447)\nkernel: ? do_trap (arch/x86/kernel/traps.c:113 arch/x86/kernel/traps.c:154)\nkernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpu\nkernel: ? do_error_trap (./arch/x86/include/asm/traps.h:58 arch/x86/kernel/traps.c:175)\nkernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpu\nkernel: ? exc_divide_error (arch/x86/kernel/traps.c:194 (discriminator 2))\nkernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpu\nkernel: ? asm_exc_divide_error (./arch/x86/include/asm/idtentry.h:548)\nkernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpu\nkernel: dc_dsc_compute_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1109) amdgpu\r\n\r\nAfter applying this patch, the driver no longer crashes when the monitor\nis connected and the system is rebooted. I believe this is the same\nissue reported for 3113.(CVE-2024-36969)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: sched: sch_multiq: fix possible OOB write in multiq_tune()\r\n\r\nq-\u0026gt;bands will be assigned to qopt-\u0026gt;bands to execute subsequent code logic\nafter kmalloc. So the old q-\u0026gt;bands should not be used in kmalloc.\nOtherwise, an out-of-bounds write will occur.(CVE-2024-36978)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: bridge: xmit: make sure we have at least eth header len bytes\r\n\r\nsyzbot triggered an uninit value[1] error in bridge device\u0026apos;s xmit path\nby sending a short (less than ETH_HLEN bytes) skb. To fix it check if\nwe can actually pull that amount instead of assuming.\r\n\r\nTested with dropwatch:\n drop at: br_dev_xmit+0xb93/0x12d0 [bridge] (0xffffffffc06739b3)\n origin: software\n timestamp: Mon May 13 11:31:53 2024 778214037 nsec\n protocol: 0x88a8\n length: 2\n original length: 2\n drop reason: PKT_TOO_SMALL\r\n\r\n[1]\nBUG: KMSAN: uninit-value in br_dev_xmit+0x61d/0x1cb0 net/bridge/br_device.c:65\n br_dev_xmit+0x61d/0x1cb0 net/bridge/br_device.c:65\n __netdev_start_xmit include/linux/netdevice.h:4903 [inline]\n netdev_start_xmit include/linux/netdevice.h:4917 [inline]\n xmit_one net/core/dev.c:3531 [inline]\n dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3547\n __dev_queue_xmit+0x34db/0x5350 net/core/dev.c:4341\n dev_queue_xmit include/linux/netdevice.h:3091 [inline]\n __bpf_tx_skb net/core/filter.c:2136 [inline]\n __bpf_redirect_common net/core/filter.c:2180 [inline]\n __bpf_redirect+0x14a6/0x1620 net/core/filter.c:2187\n ____bpf_clone_redirect net/core/filter.c:2460 [inline]\n bpf_clone_redirect+0x328/0x470 net/core/filter.c:2432\n ___bpf_prog_run+0x13fe/0xe0f0 kernel/bpf/core.c:1997\n __bpf_prog_run512+0xb5/0xe0 kernel/bpf/core.c:2238\n bpf_dispatcher_nop_func include/linux/bpf.h:1234 [inline]\n __bpf_prog_run include/linux/filter.h:657 [inline]\n bpf_prog_run include/linux/filter.h:664 [inline]\n bpf_test_run+0x499/0xc30 net/bpf/test_run.c:425\n bpf_prog_test_run_skb+0x14ea/0x1f20 net/bpf/test_run.c:1058\n bpf_prog_test_run+0x6b7/0xad0 kernel/bpf/syscall.c:4269\n __sys_bpf+0x6aa/0xd90 kernel/bpf/syscall.c:5678\n __do_sys_bpf kernel/bpf/syscall.c:5767 [inline]\n __se_sys_bpf kernel/bpf/syscall.c:5765 [inline]\n __x64_sys_bpf+0xa0/0xe0 kernel/bpf/syscall.c:5765\n x64_sys_call+0x96b/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:322\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2024-38538)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nRDMA/hns: Fix UAF for cq async event\r\n\r\nThe refcount of CQ is not protected by locks. When CQ asynchronous\nevents and CQ destruction are concurrent, CQ may have been released,\nwhich will cause UAF.\r\n\r\nUse the xa_lock() to protect the CQ refcount.(CVE-2024-38545)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/mediatek: Add 0 size check to mtk_drm_gem_obj\r\n\r\nAdd a check to mtk_drm_gem_init if we attempt to allocate a GEM object\nof 0 bytes. Currently, no such check exists and the kernel will panic if\na userspace application attempts to allocate a 0x0 GBM buffer.\r\n\r\nTested by attempting to allocate a 0x0 GBM buffer on an MT8188 and\nverifying that we now return EINVAL.(CVE-2024-38549)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/mlx5: Discard command completions in internal error\r\n\r\nFix use after free when FW completion arrives while device is in\ninternal error state. Avoid calling completion handler in this case,\nsince the device will flush the command interface and trigger all\ncompletions manually.\r\n\r\nKernel log:\n------------[ cut here ]------------\nrefcount_t: underflow; use-after-free.\n...\nRIP: 0010:refcount_warn_saturate+0xd8/0xe0\n...\nCall Trace:\n\u0026lt;IRQ\u0026gt;\n? __warn+0x79/0x120\n? refcount_warn_saturate+0xd8/0xe0\n? report_bug+0x17c/0x190\n? handle_bug+0x3c/0x60\n? exc_invalid_op+0x14/0x70\n? asm_exc_invalid_op+0x16/0x20\n? refcount_warn_saturate+0xd8/0xe0\ncmd_ent_put+0x13b/0x160 [mlx5_core]\nmlx5_cmd_comp_handler+0x5f9/0x670 [mlx5_core]\ncmd_comp_notifier+0x1f/0x30 [mlx5_core]\nnotifier_call_chain+0x35/0xb0\natomic_notifier_call_chain+0x16/0x20\nmlx5_eq_async_int+0xf6/0x290 [mlx5_core]\nnotifier_call_chain+0x35/0xb0\natomic_notifier_call_chain+0x16/0x20\nirq_int_handler+0x19/0x30 [mlx5_core]\n__handle_irq_event_percpu+0x4b/0x160\nhandle_irq_event+0x2e/0x80\nhandle_edge_irq+0x98/0x230\n__common_interrupt+0x3b/0xa0\ncommon_interrupt+0x7b/0xa0\n\u0026lt;/IRQ\u0026gt;\n\u0026lt;TASK\u0026gt;\nasm_common_interrupt+0x22/0x40(CVE-2024-38555)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrivers/perf: hisi_pcie: Fix out-of-bound access when valid event group\r\n\r\nThe perf tool allows users to create event groups through following\ncmd [1], but the driver does not check whether the array index is out of\nbounds when writing data to the event_group array. If the number of events\nin an event_group is greater than HISI_PCIE_MAX_COUNTERS, the memory write\noverflow of event_group array occurs.\r\n\r\nAdd array index check to fix the possible array out of bounds violation,\nand return directly when write new events are written to array bounds.\r\n\r\nThere are 9 different events in an event_group.\n[1] perf stat -e \u0026apos;{pmu/event1/, ... ,pmu/event9/}\u0026apos;(CVE-2024-38569)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nRDMA/hns: Fix deadlock on SRQ async events.\r\n\r\nxa_lock for SRQ table may be required in AEQ. Use xa_store_irq()/\nxa_erase_irq() to avoid deadlock.(CVE-2024-38591)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nring-buffer: Fix a race between readers and resize checks\r\n\r\nThe reader code in rb_get_reader_page() swaps a new reader page into the\nring buffer by doing cmpxchg on old-\u0026gt;list.prev-\u0026gt;next to point it to the\nnew page. Following that, if the operation is successful,\nold-\u0026gt;list.next-\u0026gt;prev gets updated too. This means the underlying\ndoubly-linked list is temporarily inconsistent, page-\u0026gt;prev-\u0026gt;next or\npage-\u0026gt;next-\u0026gt;prev might not be equal back to page for some page in the\nring buffer.\r\n\r\nThe resize operation in ring_buffer_resize() can be invoked in parallel.\nIt calls rb_check_pages() which can detect the described inconsistency\nand stop further tracing:\r\n\r\n[ 190.271762] ------------[ cut here ]------------\n[ 190.271771] WARNING: CPU: 1 PID: 6186 at kernel/trace/ring_buffer.c:1467 rb_check_pages.isra.0+0x6a/0xa0\n[ 190.271789] Modules linked in: [...]\n[ 190.271991] Unloaded tainted modules: intel_uncore_frequency(E):1 skx_edac(E):1\n[ 190.272002] CPU: 1 PID: 6186 Comm: cmd.sh Kdump: loaded Tainted: G E 6.9.0-rc6-default #5 158d3e1e6d0b091c34c3b96bfd99a1c58306d79f\n[ 190.272011] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552c-rebuilt.opensuse.org 04/01/2014\n[ 190.272015] RIP: 0010:rb_check_pages.isra.0+0x6a/0xa0\n[ 190.272023] Code: [...]\n[ 190.272028] RSP: 0018:ffff9c37463abb70 EFLAGS: 00010206\n[ 190.272034] RAX: ffff8eba04b6cb80 RBX: 0000000000000007 RCX: ffff8eba01f13d80\n[ 190.272038] RDX: ffff8eba01f130c0 RSI: ffff8eba04b6cd00 RDI: ffff8eba0004c700\n[ 190.272042] RBP: ffff8eba0004c700 R08: 0000000000010002 R09: 0000000000000000\n[ 190.272045] R10: 00000000ffff7f52 R11: ffff8eba7f600000 R12: ffff8eba0004c720\n[ 190.272049] R13: ffff8eba00223a00 R14: 0000000000000008 R15: ffff8eba067a8000\n[ 190.272053] FS: 00007f1bd64752c0(0000) GS:ffff8eba7f680000(0000) knlGS:0000000000000000\n[ 190.272057] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 190.272061] CR2: 00007f1bd6662590 CR3: 000000010291e001 CR4: 0000000000370ef0\n[ 190.272070] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[ 190.272073] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[ 190.272077] Call Trace:\n[ 190.272098] \u0026lt;TASK\u0026gt;\n[ 190.272189] ring_buffer_resize+0x2ab/0x460\n[ 190.272199] __tracing_resize_ring_buffer.part.0+0x23/0xa0\n[ 190.272206] tracing_resize_ring_buffer+0x65/0x90\n[ 190.272216] tracing_entries_write+0x74/0xc0\n[ 190.272225] vfs_write+0xf5/0x420\n[ 190.272248] ksys_write+0x67/0xe0\n[ 190.272256] do_syscall_64+0x82/0x170\n[ 190.272363] entry_SYSCALL_64_after_hwframe+0x76/0x7e\n[ 190.272373] RIP: 0033:0x7f1bd657d263\n[ 190.272381] Code: [...]\n[ 190.272385] RSP: 002b:00007ffe72b643f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001\n[ 190.272391] RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007f1bd657d263\n[ 190.272395] RDX: 0000000000000002 RSI: 0000555a6eb538e0 RDI: 0000000000000001\n[ 190.272398] RBP: 0000555a6eb538e0 R08: 000000000000000a R09: 0000000000000000\n[ 190.272401] R10: 0000555a6eb55190 R11: 0000000000000246 R12: 00007f1bd6662500\n[ 190.272404] R13: 0000000000000002 R14: 00007f1bd6667c00 R15: 0000000000000002\n[ 190.272412] \u0026lt;/TASK\u0026gt;\n[ 190.272414] ---[ end trace 0000000000000000 ]---\r\n\r\nNote that ring_buffer_resize() calls rb_check_pages() only if the parent\ntrace_buffer has recording disabled. Recent commit d78ab792705c\n(\u0026quot;tracing: Stop current tracer when resizing buffer\u0026quot;) causes that it is\nnow always the case which makes it more likely to experience this issue.\r\n\r\nThe window to hit this race is nonetheless very small. To help\nreproducing it, one can add a delay loop in rb_get_reader_page():\r\n\r\n ret = rb_head_page_replace(reader, cpu_buffer-\u0026gt;reader_page);\n if (!ret)\n \tgoto spin;\n for (unsigned i = 0; i \u0026lt; 1U \u0026lt;\u0026lt; 26; i++) /* inserted delay loop */\n \t__asm__ __volatile__ (\u0026quot;\u0026quot; : : : \u0026quot;memory\u0026quot;);\n rb_list_head(reader-\u0026gt;list.next)-\u0026gt;prev = \u0026amp;cpu_buffer-\u0026gt;reader_page-\u0026gt;list;\r\n\r\n.. \n---truncated---(CVE-2024-38601)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nserial: max3100: Lock port-\u0026gt;lock when calling uart_handle_cts_change()\r\n\r\nuart_handle_cts_change() has to be called with port lock taken,\nSince we run it in a separate work, the lock may not be taken at\nthe time of running. Make sure that it\u0026apos;s taken by explicitly doing\nthat. Without it we got a splat:\r\n\r\n WARNING: CPU: 0 PID: 10 at drivers/tty/serial/serial_core.c:3491 uart_handle_cts_change+0xa6/0xb0\n ...\n Workqueue: max3100-0 max3100_work [max3100]\n RIP: 0010:uart_handle_cts_change+0xa6/0xb0\n ...\n max3100_handlerx+0xc5/0x110 [max3100]\n max3100_work+0x12a/0x340 [max3100](CVE-2024-38634)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbpf: Allow delete from sockmap/sockhash only if update is allowed\r\n\r\nWe have seen an influx of syzkaller reports where a BPF program attached to\na tracepoint triggers a locking rule violation by performing a map_delete\non a sockmap/sockhash.\r\n\r\nWe don\u0026apos;t intend to support this artificial use scenario. Extend the\nexisting verifier allowed-program-type check for updating sockmap/sockhash\nto also cover deleting from a map.\r\n\r\nFrom now on only BPF programs which were previously allowed to update\nsockmap/sockhash can delete from these map types.(CVE-2024-38662)",
"id": "OESA-2024-1768",
"modified": "2026-08-06T11:07:14Z",
"published": "2024-06-28T11:07:14Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1768"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47381"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47427"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47469"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-39180"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52696"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52791"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52853"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26592"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26852"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26921"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26935"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26988"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27032"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27038"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27047"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27052"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27053"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27417"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-31076"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35811"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35817"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35830"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35947"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36969"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36978"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38538"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38545"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38549"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38555"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38569"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38591"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38601"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38634"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38662"
}
],
"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-47381",
"CVE-2021-47427",
"CVE-2021-47469",
"CVE-2023-39180",
"CVE-2023-52696",
"CVE-2023-52791",
"CVE-2023-52853",
"CVE-2024-26592",
"CVE-2024-26852",
"CVE-2024-26921",
"CVE-2024-26935",
"CVE-2024-26988",
"CVE-2024-27032",
"CVE-2024-27038",
"CVE-2024-27047",
"CVE-2024-27052",
"CVE-2024-27053",
"CVE-2024-27417",
"CVE-2024-31076",
"CVE-2024-35811",
"CVE-2024-35817",
"CVE-2024-35830",
"CVE-2024-35947",
"CVE-2024-36969",
"CVE-2024-36978",
"CVE-2024-38538",
"CVE-2024-38545",
"CVE-2024-38549",
"CVE-2024-38555",
"CVE-2024-38569",
"CVE-2024-38591",
"CVE-2024-38601",
"CVE-2024-38634",
"CVE-2024-38662"
]
}
OESA-2024-1792 (CVE-2024-27405)
Vulnerability from osv_openeuler – Published: 2024-07-05 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:
usb: gadget: ncm: Avoid dropping datagrams of properly parsed NTBs
It is observed sometimes when tethering is used over NCM with Windows 11 as host, at some instances, the gadget_giveback has one byte appended at the end of a proper NTB. When the NTB is parsed, unwrap call looks for any leftover bytes in SKB provided by u_ether and if there are any pending bytes, it treats them as a separate NTB and parses it. But in case the second NTB (as per unwrap call) is faulty/corrupt, all the datagrams that were parsed properly in the first NTB and saved in rx_list are dropped.
Adding a few custom traces showed the following: [002] d..1 7828.532866: dwc3_gadget_giveback: ep1out: req 000000003868811a length 1025/16384 zsI ==> 0 [002] d..1 7828.532867: ncm_unwrap_ntb: K: ncm_unwrap_ntb toprocess: 1025 [002] d..1 7828.532867: ncm_unwrap_ntb: K: ncm_unwrap_ntb nth: 1751999342 [002] d..1 7828.532868: ncm_unwrap_ntb: K: ncm_unwrap_ntb seq: 0xce67 [002] d..1 7828.532868: ncm_unwrap_ntb: K: ncm_unwrap_ntb blk_len: 0x400 [002] d..1 7828.532868: ncm_unwrap_ntb: K: ncm_unwrap_ntb ndp_len: 0x10 [002] d..1 7828.532869: ncm_unwrap_ntb: K: Parsed NTB with 1 frames
In this case, the giveback is of 1025 bytes and block length is 1024. The rest 1 byte (which is 0x00) won't be parsed resulting in drop of all datagrams in rx_list.
Same is case with packets of size 2048: [002] d..1 7828.557948: dwc3_gadget_giveback: ep1out: req 0000000011dfd96e length 2049/16384 zsI ==> 0 [002] d..1 7828.557949: ncm_unwrap_ntb: K: ncm_unwrap_ntb nth: 1751999342 [002] d..1 7828.557950: ncm_unwrap_ntb: K: ncm_unwrap_ntb blk_len: 0x800
Lecroy shows one byte coming in extra confirming that the byte is coming in from PC:
Transfer 2959 - Bytes Transferred(1025) Timestamp((18.524 843 590) - Transaction 8391 - Data(1025 bytes) Timestamp(18.524 843 590) --- Packet 4063861 Data(1024 bytes) Duration(2.117us) Idle(14.700ns) Timestamp(18.524 843 590) --- Packet 4063863 Data(1 byte) Duration(66.160ns) Time(282.000ns) Timestamp(18.524 845 722)
According to Windows driver, no ZLP is needed if wBlockLength is non-zero, because the non-zero wBlockLength has already told the function side the size of transfer to be expected. However, there are in-market NCM devices that rely on ZLP as long as the wBlockLength is multiple of wMaxPacketSize. To deal with such devices, it pads an extra 0 at end so the transfer is no longer multiple of wMaxPacketSize.(CVE-2024-27405)
In the Linux kernel, the following vulnerability has been resolved:
ipv6: fix potential "struct net" leak in inet6_rtm_getaddr()
It seems that if userspace provides a correct IFA_TARGET_NETNSID value but no IFA_ADDRESS and IFA_LOCAL attributes, inet6_rtm_getaddr() returns -EINVAL with an elevated "struct net" refcount.(CVE-2024-27417)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: flush pending destroy work before exit_net release
Similar to 2c9f0293280e ("netfilter: nf_tables: flush pending destroy work before netlink notifier") to address a race between exit_net and the destroy workqueue.
The trace below shows an element to be released via destroy workqueue while exit_net path (triggered via module removal) has already released the set that is used in such transaction.
[ 1360.547789] BUG: KASAN: slab-use-after-free in nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables] [ 1360.547861] Read of size 8 at addr ffff888140500cc0 by task kworker/4:1/152465 [ 1360.547870] CPU: 4 PID: 152465 Comm: kworker/4:1 Not tainted 6.8.0+ #359 [ 1360.547882] Workqueue: events nf_tables_trans_destroy_work [nf_tables] [ 1360.547984] Call Trace: [ 1360.547991] <TASK> [ 1360.547998] dump_stack_lvl+0x53/0x70 [ 1360.548014] print_report+0xc4/0x610 [ 1360.548026] ? __virt_addr_valid+0xba/0x160 [ 1360.548040] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 1360.548054] ? nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables] [ 1360.548176] kasan_report+0xae/0xe0 [ 1360.548189] ? nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables] [ 1360.548312] nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables] [ 1360.548447] ? __pfx_nf_tables_trans_destroy_work+0x10/0x10 [nf_tables] [ 1360.548577] ? _raw_spin_unlock_irq+0x18/0x30 [ 1360.548591] process_one_work+0x2f1/0x670 [ 1360.548610] worker_thread+0x4d3/0x760 [ 1360.548627] ? __pfx_worker_thread+0x10/0x10 [ 1360.548640] kthread+0x16b/0x1b0 [ 1360.548653] ? __pfx_kthread+0x10/0x10 [ 1360.548665] ret_from_fork+0x2f/0x50 [ 1360.548679] ? __pfx_kthread+0x10/0x10 [ 1360.548690] ret_from_fork_asm+0x1a/0x30 [ 1360.548707] </TASK>
[ 1360.548719] Allocated by task 192061: [ 1360.548726] kasan_save_stack+0x20/0x40 [ 1360.548739] kasan_save_track+0x14/0x30 [ 1360.548750] __kasan_kmalloc+0x8f/0xa0 [ 1360.548760] __kmalloc_node+0x1f1/0x450 [ 1360.548771] nf_tables_newset+0x10c7/0x1b50 [nf_tables] [ 1360.548883] nfnetlink_rcv_batch+0xbc4/0xdc0 [nfnetlink] [ 1360.548909] nfnetlink_rcv+0x1a8/0x1e0 [nfnetlink] [ 1360.548927] netlink_unicast+0x367/0x4f0 [ 1360.548935] netlink_sendmsg+0x34b/0x610 [ 1360.548944] _syssendmsg+0x4d4/0x510 [ 1360.548953] _sys_sendmsg+0xc9/0x120 [ 1360.548961] __sys_sendmsg+0xbe/0x140 [ 1360.548971] do_syscall_64+0x55/0x120 [ 1360.548982] entry_SYSCALL_64_after_hwframe+0x55/0x5d
[ 1360.548994] Freed by task 192222: [ 1360.548999] kasan_save_stack+0x20/0x40 [ 1360.549009] kasan_save_track+0x14/0x30 [ 1360.549019] kasan_save_free_info+0x3b/0x60 [ 1360.549028] poison_slab_object+0x100/0x180 [ 1360.549036] __kasan_slab_free+0x14/0x30 [ 1360.549042] kfree+0xb6/0x260 [ 1360.549049] __nft_release_table+0x473/0x6a0 [nf_tables] [ 1360.549131] nf_tables_exit_net+0x170/0x240 [nf_tables] [ 1360.549221] ops_exit_list+0x50/0xa0 [ 1360.549229] free_exit_list+0x101/0x140 [ 1360.549236] unregister_pernet_operations+0x107/0x160 [ 1360.549245] unregister_pernet_subsys+0x1c/0x30 [ 1360.549254] nf_tables_module_exit+0x43/0x80 [nf_tables] [ 1360.549345] __do_sys_delete_module+0x253/0x370 [ 1360.549352] do_syscall_64+0x55/0x120 [ 1360.549360] entry_SYSCALL_64_after_hwframe+0x55/0x5d
(gdb) list *__nft_release_table+0x473 0x1e033 is in __nft_release_table (net/netfilter/nf_tables_api.c:11354). 11349 list_for_each_entry_safe(flowtable, nf, &table->flowtables, list) { 11350 list_del(&flowtable->list); 11351 nft_use_dec(&table->use); 11352 nf_tables_flowtable_destroy(flowtable); 11353 } 11354 list_for_each_entry_safe(set, ns, &table->sets, list) { 11355 list_del(&set->list); 11356 nft_use_dec(&table->use); 11357 if (set->flags & (NFT_SET_MAP | NFT_SET_OBJECT)) 11358 nft_map_deactivat ---truncated---(CVE-2024-35899)
In the Linux kernel, the following vulnerability has been resolved:
dyndbg: fix old BUG_ON in >control parser
Fix a BUG_ON from 2009. Even if it looks "unreachable" (I didn't really look), lets make sure by removing it, doing pr_err and return -EINVAL instead.(CVE-2024-35947)
In the Linux kernel, the following vulnerability has been resolved:
net/sched: taprio: always validate TCA_TAPRIO_ATTR_PRIOMAP
If one TCA_TAPRIO_ATTR_PRIOMAP attribute has been provided, taprio_parse_mqprio_opt() must validate it, or userspace can inject arbitrary data to the kernel, the second time taprio_change() is called.
First call (with valid attributes) sets dev->num_tc to a non zero value.
Second call (with arbitrary mqprio attributes) returns early from taprio_parse_mqprio_opt() and bad things can happen.(CVE-2024-36974)
In the Linux kernel, the following vulnerability has been resolved:
tcp: Fix shift-out-of-bounds in dctcp_update_alpha().
In dctcp_update_alpha(), we use a module parameter dctcp_shift_g as follows:
alpha -= min_not_zero(alpha, alpha >> dctcp_shift_g); ... delivered_ce <<= (10 - dctcp_shift_g);
It seems syzkaller started fuzzing module parameters and triggered shift-out-of-bounds [0] by setting 100 to dctcp_shift_g:
memcpy((void)0x20000080, "/sys/module/tcp_dctcp/parameters/dctcp_shift_g\000", 47); res = syscall(__NR_openat, /fd=/0xffffffffffffff9cul, /file=/0x20000080ul, /flags=/2ul, /mode=/0ul); memcpy((void)0x20000000, "100\000", 4); syscall(__NR_write, /fd=/r[0], /val=/0x20000000ul, /len=/4ul);
Let's limit the max value of dctcp_shift_g by param_set_uint_minmax().
With this patch:
# echo 10 > /sys/module/tcp_dctcp/parameters/dctcp_shift_g # cat /sys/module/tcp_dctcp/parameters/dctcp_shift_g 10 # echo 11 > /sys/module/tcp_dctcp/parameters/dctcp_shift_g -bash: echo: write error: Invalid argument
[0]: UBSAN: shift-out-of-bounds in net/ipv4/tcp_dctcp.c:143:12 shift exponent 100 is too large for 32-bit type 'u32' (aka 'unsigned int') CPU: 0 PID: 8083 Comm: syz-executor345 Not tainted 6.9.0-05151-g1b294a1f3561 #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x201/0x300 lib/dump_stack.c:114 ubsan_epilogue lib/ubsan.c:231 [inline] __ubsan_handle_shift_out_of_bounds+0x346/0x3a0 lib/ubsan.c:468 dctcp_update_alpha+0x540/0x570 net/ipv4/tcp_dctcp.c:143 tcp_in_ack_event net/ipv4/tcp_input.c:3802 [inline] tcp_ack+0x17b1/0x3bc0 net/ipv4/tcp_input.c:3948 tcp_rcv_state_process+0x57a/0x2290 net/ipv4/tcp_input.c:6711 tcp_v4_do_rcv+0x764/0xc40 net/ipv4/tcp_ipv4.c:1937 sk_backlog_rcv include/net/sock.h:1106 [inline] __release_sock+0x20f/0x350 net/core/sock.c:2983 release_sock+0x61/0x1f0 net/core/sock.c:3549 mptcp_subflow_shutdown+0x3d0/0x620 net/mptcp/protocol.c:2907 mptcp_check_send_data_fin+0x225/0x410 net/mptcp/protocol.c:2976 __mptcp_close+0x238/0xad0 net/mptcp/protocol.c:3072 mptcp_close+0x2a/0x1a0 net/mptcp/protocol.c:3127 inet_release+0x190/0x1f0 net/ipv4/af_inet.c:437 __sock_release net/socket.c:659 [inline] sock_close+0xc0/0x240 net/socket.c:1421 __fput+0x41b/0x890 fs/file_table.c:422 task_work_run+0x23b/0x300 kernel/task_work.c:180 exit_task_work include/linux/task_work.h:38 [inline] do_exit+0x9c8/0x2540 kernel/exit.c:878 do_group_exit+0x201/0x2b0 kernel/exit.c:1027 __do_sys_exit_group kernel/exit.c:1038 [inline] __se_sys_exit_group kernel/exit.c:1036 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1036 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xe4/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x67/0x6f RIP: 0033:0x7f6c2b5005b6 Code: Unable to access opcode bytes at 0x7f6c2b50058c. RSP: 002b:00007ffe883eb948 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 00007f6c2b5862f0 RCX: 00007f6c2b5005b6 RDX: 0000000000000001 RSI: 000000000000003c RDI: 0000000000000001 RBP: 0000000000000001 R08: 00000000000000e7 R09: ffffffffffffffc0 R10: 0000000000000006 R11: 0000000000000246 R12: 00007f6c2b5862f0 R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000001 </TASK>(CVE-2024-37356)
In the Linux kernel, the following vulnerability has been resolved:
net: bridge: xmit: make sure we have at least eth header len bytes
syzbot triggered an uninit value[1] error in bridge device's xmit path by sending a short (less than ETH_HLEN bytes) skb. To fix it check if we can actually pull that amount instead of assuming.
Tested with dropwatch: drop at: br_dev_xmit+0xb93/0x12d0 [bridge] (0xffffffffc06739b3) origin: software timestamp: Mon May 13 11:31:53 2024 778214037 nsec protocol: 0x88a8 length: 2 original length: 2 drop reason: PKT_TOO_SMALL
[1] BUG: KMSAN: uninit-value in br_dev_xmit+0x61d/0x1cb0 net/bridge/br_device.c:65 br_dev_xmit+0x61d/0x1cb0 net/bridge/br_device.c:65 __netdev_start_xmit include/linux/netdevice.h:4903 [inline] netdev_start_xmit include/linux/netdevice.h:4917 [inline] xmit_one net/core/dev.c:3531 [inline] dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3547 __dev_queue_xmit+0x34db/0x5350 net/core/dev.c:4341 dev_queue_xmit include/linux/netdevice.h:3091 [inline] __bpf_tx_skb net/core/filter.c:2136 [inline] __bpf_redirect_common net/core/filter.c:2180 [inline] __bpf_redirect+0x14a6/0x1620 net/core/filter.c:2187 _bpfclone_redirect net/core/filter.c:2460 [inline] bpf_clone_redirect+0x328/0x470 net/core/filter.c:2432 _bpf_prog_run+0x13fe/0xe0f0 kernel/bpf/core.c:1997 __bpf_prog_run512+0xb5/0xe0 kernel/bpf/core.c:2238 bpf_dispatcher_nop_func include/linux/bpf.h:1234 [inline] __bpf_prog_run include/linux/filter.h:657 [inline] bpf_prog_run include/linux/filter.h:664 [inline] bpf_test_run+0x499/0xc30 net/bpf/test_run.c:425 bpf_prog_test_run_skb+0x14ea/0x1f20 net/bpf/test_run.c:1058 bpf_prog_test_run+0x6b7/0xad0 kernel/bpf/syscall.c:4269 __sys_bpf+0x6aa/0xd90 kernel/bpf/syscall.c:5678 __do_sys_bpf kernel/bpf/syscall.c:5767 [inline] __se_sys_bpf kernel/bpf/syscall.c:5765 [inline] __x64_sys_bpf+0xa0/0xe0 kernel/bpf/syscall.c:5765 x64_sys_call+0x96b/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:322 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2024-38538)
In the Linux kernel, the following vulnerability has been resolved:
of: module: add buffer overflow check in of_modalias()
In of_modalias(), if the buffer happens to be too small even for the 1st snprintf() call, the len parameter will become negative and str parameter (if not NULL initially) will point beyond the buffer's end. Add the buffer overflow check after the 1st snprintf() call and fix such check after the strlen() call (accounting for the terminating NUL char).(CVE-2024-38541)
In the Linux kernel, the following vulnerability has been resolved:
drm/mediatek: Add 0 size check to mtk_drm_gem_obj
Add a check to mtk_drm_gem_init if we attempt to allocate a GEM object of 0 bytes. Currently, no such check exists and the kernel will panic if a userspace application attempts to allocate a 0x0 GBM buffer.
Tested by attempting to allocate a 0x0 GBM buffer on an MT8188 and verifying that we now return EINVAL.(CVE-2024-38549)
In the Linux kernel, the following vulnerability has been resolved:
net: fec: remove .ndo_poll_controller to avoid deadlocks
There is a deadlock issue found in sungem driver, please refer to the commit ac0a230f719b ("eth: sungem: remove .ndo_poll_controller to avoid deadlocks"). The root cause of the issue is that netpoll is in atomic context and disable_irq() is called by .ndo_poll_controller interface of sungem driver, however, disable_irq() might sleep. After analyzing the implementation of fec_poll_controller(), the fec driver should have the same issue. Due to the fec driver uses NAPI for TX completions, the .ndo_poll_controller is unnecessary to be implemented in the fec driver, so fec_poll_controller() can be safely removed.(CVE-2024-38553)
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: Discard command completions in internal error
Fix use after free when FW completion arrives while device is in internal error state. Avoid calling completion handler in this case, since the device will flush the command interface and trigger all completions manually.
Kernel log: ------------[ cut here ]------------ refcount_t: underflow; use-after-free. ... RIP: 0010:refcount_warn_saturate+0xd8/0xe0 ... Call Trace: <IRQ> ? __warn+0x79/0x120 ? refcount_warn_saturate+0xd8/0xe0 ? report_bug+0x17c/0x190 ? handle_bug+0x3c/0x60 ? exc_invalid_op+0x14/0x70 ? asm_exc_invalid_op+0x16/0x20 ? refcount_warn_saturate+0xd8/0xe0 cmd_ent_put+0x13b/0x160 [mlx5_core] mlx5_cmd_comp_handler+0x5f9/0x670 [mlx5_core] cmd_comp_notifier+0x1f/0x30 [mlx5_core] notifier_call_chain+0x35/0xb0 atomic_notifier_call_chain+0x16/0x20 mlx5_eq_async_int+0xf6/0x290 [mlx5_core] notifier_call_chain+0x35/0xb0 atomic_notifier_call_chain+0x16/0x20 irq_int_handler+0x19/0x30 [mlx5_core] __handle_irq_event_percpu+0x4b/0x160 handle_irq_event+0x2e/0x80 handle_edge_irq+0x98/0x230 __common_interrupt+0x3b/0xa0 common_interrupt+0x7b/0xa0 </IRQ> <TASK> asm_common_interrupt+0x22/0x40(CVE-2024-38555)
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: Add a timeout to acquire the command queue semaphore
Prevent forced completion handling on an entry that has not yet been assigned an index, causing an out of bounds access on idx = -22. Instead of waiting indefinitely for the sem, blocking flow now waits for index to be allocated or a sem acquisition timeout before beginning the timer for FW completion.
Kernel log example: mlx5_core 0000:06:00.0: wait_func_handle_exec_timeout:1128:(pid 185911): cmd[-22]: CREATE_UCTX(0xa04) No done completion(CVE-2024-38556)
In the Linux kernel, the following vulnerability has been resolved:
bpf: Add BPF_PROG_TYPE_CGROUP_SKB attach type enforcement in BPF_LINK_CREATE
bpf_prog_attach uses attach_type_to_prog_type to enforce proper attach type for BPF_PROG_TYPE_CGROUP_SKB. link_create uses bpf_prog_get and relies on bpf_prog_attach_check_attach_type to properly verify prog_type <> attach_type association.
Add missing attach_type enforcement for the link_create case. Otherwise, it's currently possible to attach cgroup_skb prog types to other cgroup hooks.(CVE-2024-38564)
In the Linux kernel, the following vulnerability has been resolved:
speakup: Fix sizeof() vs ARRAY_SIZE() bug
The "buf" pointer is an array of u16 values. This code should be using ARRAY_SIZE() (which is 256) instead of sizeof() (which is 512), otherwise it can the still got out of bounds.(CVE-2024-38587)
In the Linux kernel, the following vulnerability has been resolved:
jffs2: prevent xattr node from overflowing the eraseblock
Add a check to make sure that the requested xattr node size is no larger than the eraseblock minus the cleanmarker.
Unlike the usual inode nodes, the xattr nodes aren't split into parts and spread across multiple eraseblocks, which means that a xattr node must not occupy more than one eraseblock. If the requested xattr value is too large, the xattr node can spill onto the next eraseblock, overwriting the nodes and causing errors such as:
jffs2: argh. node added in wrong place at 0x0000b050(2) jffs2: nextblock 0x0000a000, expected at 0000b00c jffs2: error: (823) do_verify_xattr_datum: node CRC failed at 0x01e050, read=0xfc892c93, calc=0x000000 jffs2: notice: (823) jffs2_get_inode_nodes: Node header CRC failed at 0x01e00c. {848f,2fc4,0fef511f,59a3d171} jffs2: Node at 0x0000000c with length 0x00001044 would run over the end of the erase block jffs2: Perhaps the file system was created with the wrong erase size? jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000010: 0x1044 instead
This breaks the filesystem and can lead to KASAN crashes such as:
BUG: KASAN: slab-out-of-bounds in jffs2_sum_add_kvec+0x125e/0x15d0 Read of size 4 at addr ffff88802c31e914 by task repro/830 CPU: 0 PID: 830 Comm: repro Not tainted 6.9.0-rc3+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0xc6/0x120 print_report+0xc4/0x620 ? __virt_addr_valid+0x308/0x5b0 kasan_report+0xc1/0xf0 ? jffs2_sum_add_kvec+0x125e/0x15d0 ? jffs2_sum_add_kvec+0x125e/0x15d0 jffs2_sum_add_kvec+0x125e/0x15d0 jffs2_flash_direct_writev+0xa8/0xd0 jffs2_flash_writev+0x9c9/0xef0 ? __x64_sys_setxattr+0xc4/0x160 ? do_syscall_64+0x69/0x140 ? entry_SYSCALL_64_after_hwframe+0x76/0x7e [...]
Found by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2024-38599)
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Use 64 bit variable to avoid 32 bit overflow
For example, in the expression: vbo = 2 * vbo + skip(CVE-2024-38624)
In the Linux kernel, the following vulnerability has been resolved:
watchdog: cpu5wdt.c: Fix use-after-free bug caused by cpu5wdt_trigger
When the cpu5wdt module is removing, the origin code uses del_timer() to de-activate the timer. If the timer handler is running, del_timer() could not stop it and will return directly. If the port region is released by release_region() and then the timer handler cpu5wdt_trigger() calls outb() to write into the region that is released, the use-after-free bug will happen.
Change del_timer() to timer_shutdown_sync() in order that the timer handler could be finished before the port region is released.(CVE-2024-38630)
In the Linux kernel, the following vulnerability has been resolved:
s390/ap: Fix crash in AP internal function modify_bitmap()
A system crash like this
Failing address: 200000cb7df6f000 TEID: 200000cb7df6f403 Fault in home space mode while using kernel ASCE. AS:00000002d71bc007 R3:00000003fe5b8007 S:000000011a446000 P:000000015660c13d Oops: 0038 ilc:3 [#1] PREEMPT SMP Modules linked in: mlx5_ib ... CPU: 8 PID: 7556 Comm: bash Not tainted 6.9.0-rc7 #8 Hardware name: IBM 3931 A01 704 (LPAR) Krnl PSW : 0704e00180000000 0000014b75e7b606 (ap_parse_bitmap_str+0x10e/0x1f8) R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3 Krnl GPRS: 0000000000000001 ffffffffffffffc0 0000000000000001 00000048f96b75d3 000000cb00000100 ffffffffffffffff ffffffffffffffff 000000cb7df6fce0 000000cb7df6fce0 00000000ffffffff 000000000000002b 00000048ffffffff 000003ff9b2dbc80 200000cb7df6fcd8 0000014bffffffc0 000000cb7df6fbc8 Krnl Code: 0000014b75e7b5fc: a7840047 brc 8,0000014b75e7b68a 0000014b75e7b600: 18b2 lr %r11,%r2 #0000014b75e7b602: a7f4000a brc 15,0000014b75e7b616 >0000014b75e7b606: eb22d00000e6 laog %r2,%r2,0(%r13) 0000014b75e7b60c: a7680001 lhi %r6,1 0000014b75e7b610: 187b lr %r7,%r11 0000014b75e7b612: 84960021 brxh %r9,%r6,0000014b75e7b654 0000014b75e7b616: 18e9 lr %r14,%r9 Call Trace: [<0000014b75e7b606>] ap_parse_bitmap_str+0x10e/0x1f8 ([<0000014b75e7b5dc>] ap_parse_bitmap_str+0xe4/0x1f8) [<0000014b75e7b758>] apmask_store+0x68/0x140 [<0000014b75679196>] kernfs_fop_write_iter+0x14e/0x1e8 [<0000014b75598524>] vfs_write+0x1b4/0x448 [<0000014b7559894c>] ksys_write+0x74/0x100 [<0000014b7618a440>] __do_syscall+0x268/0x328 [<0000014b761a3558>] system_call+0x70/0x98 INFO: lockdep is turned off. Last Breaking-Event-Address: [<0000014b75e7b636>] ap_parse_bitmap_str+0x13e/0x1f8 Kernel panic - not syncing: Fatal exception: panic_on_oops
occured when /sys/bus/ap/a[pq]mask was updated with a relative mask value (like +0x10-0x12,+60,-90) with one of the numeric values exceeding INT_MAX.
The fix is simple: use unsigned long values for the internal variables. The correct checks are already in place in the function but a simple int for the internal variables was used with the possibility to overflow.(CVE-2024-38661)
In the Linux kernel, the following vulnerability has been resolved:
um: Add winch to winch_handlers before registering winch IRQ
Registering a winch IRQ is racy, an interrupt may occur before the winch is added to the winch_handlers list.
If that happens, register_winch_irq() adds to that list a winch that is scheduled to be (or has already been) freed, causing a panic later in winch_cleanup().
Avoid the race by adding the winch to the winch_handlers list before registering the IRQ, and rolling back if um_request_irq() fails.(CVE-2024-39292)
| URL | Type | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"kernel-5.10.0-217.0.0.120.oe2203sp3.aarch64.rpm",
"kernel-debuginfo-5.10.0-217.0.0.120.oe2203sp3.aarch64.rpm",
"kernel-debugsource-5.10.0-217.0.0.120.oe2203sp3.aarch64.rpm",
"kernel-devel-5.10.0-217.0.0.120.oe2203sp3.aarch64.rpm",
"kernel-headers-5.10.0-217.0.0.120.oe2203sp3.aarch64.rpm",
"kernel-source-5.10.0-217.0.0.120.oe2203sp3.aarch64.rpm",
"kernel-tools-5.10.0-217.0.0.120.oe2203sp3.aarch64.rpm",
"kernel-tools-debuginfo-5.10.0-217.0.0.120.oe2203sp3.aarch64.rpm",
"kernel-tools-devel-5.10.0-217.0.0.120.oe2203sp3.aarch64.rpm",
"perf-5.10.0-217.0.0.120.oe2203sp3.aarch64.rpm",
"perf-debuginfo-5.10.0-217.0.0.120.oe2203sp3.aarch64.rpm",
"python3-perf-5.10.0-217.0.0.120.oe2203sp3.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-217.0.0.120.oe2203sp3.aarch64.rpm"
],
"src": [
"kernel-5.10.0-217.0.0.120.oe2203sp3.src.rpm"
],
"x86_64": [
"kernel-5.10.0-217.0.0.120.oe2203sp3.x86_64.rpm",
"kernel-debuginfo-5.10.0-217.0.0.120.oe2203sp3.x86_64.rpm",
"kernel-debugsource-5.10.0-217.0.0.120.oe2203sp3.x86_64.rpm",
"kernel-devel-5.10.0-217.0.0.120.oe2203sp3.x86_64.rpm",
"kernel-headers-5.10.0-217.0.0.120.oe2203sp3.x86_64.rpm",
"kernel-source-5.10.0-217.0.0.120.oe2203sp3.x86_64.rpm",
"kernel-tools-5.10.0-217.0.0.120.oe2203sp3.x86_64.rpm",
"kernel-tools-debuginfo-5.10.0-217.0.0.120.oe2203sp3.x86_64.rpm",
"kernel-tools-devel-5.10.0-217.0.0.120.oe2203sp3.x86_64.rpm",
"perf-5.10.0-217.0.0.120.oe2203sp3.x86_64.rpm",
"perf-debuginfo-5.10.0-217.0.0.120.oe2203sp3.x86_64.rpm",
"python3-perf-5.10.0-217.0.0.120.oe2203sp3.x86_64.rpm",
"python3-perf-debuginfo-5.10.0-217.0.0.120.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-217.0.0.120.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\nusb: gadget: ncm: Avoid dropping datagrams of properly parsed NTBs\r\n\r\nIt is observed sometimes when tethering is used over NCM with Windows 11\nas host, at some instances, the gadget_giveback has one byte appended at\nthe end of a proper NTB. When the NTB is parsed, unwrap call looks for\nany leftover bytes in SKB provided by u_ether and if there are any pending\nbytes, it treats them as a separate NTB and parses it. But in case the\nsecond NTB (as per unwrap call) is faulty/corrupt, all the datagrams that\nwere parsed properly in the first NTB and saved in rx_list are dropped.\r\n\r\nAdding a few custom traces showed the following:\n[002] d..1 7828.532866: dwc3_gadget_giveback: ep1out:\nreq 000000003868811a length 1025/16384 zsI ==\u0026gt; 0\n[002] d..1 7828.532867: ncm_unwrap_ntb: K: ncm_unwrap_ntb toprocess: 1025\n[002] d..1 7828.532867: ncm_unwrap_ntb: K: ncm_unwrap_ntb nth: 1751999342\n[002] d..1 7828.532868: ncm_unwrap_ntb: K: ncm_unwrap_ntb seq: 0xce67\n[002] d..1 7828.532868: ncm_unwrap_ntb: K: ncm_unwrap_ntb blk_len: 0x400\n[002] d..1 7828.532868: ncm_unwrap_ntb: K: ncm_unwrap_ntb ndp_len: 0x10\n[002] d..1 7828.532869: ncm_unwrap_ntb: K: Parsed NTB with 1 frames\r\n\r\nIn this case, the giveback is of 1025 bytes and block length is 1024.\nThe rest 1 byte (which is 0x00) won\u0026apos;t be parsed resulting in drop of\nall datagrams in rx_list.\r\n\r\nSame is case with packets of size 2048:\n[002] d..1 7828.557948: dwc3_gadget_giveback: ep1out:\nreq 0000000011dfd96e length 2049/16384 zsI ==\u0026gt; 0\n[002] d..1 7828.557949: ncm_unwrap_ntb: K: ncm_unwrap_ntb nth: 1751999342\n[002] d..1 7828.557950: ncm_unwrap_ntb: K: ncm_unwrap_ntb blk_len: 0x800\r\n\r\nLecroy shows one byte coming in extra confirming that the byte is coming\nin from PC:\r\n\r\n Transfer 2959 - Bytes Transferred(1025) Timestamp((18.524 843 590)\n - Transaction 8391 - Data(1025 bytes) Timestamp(18.524 843 590)\n --- Packet 4063861\n Data(1024 bytes)\n Duration(2.117us) Idle(14.700ns) Timestamp(18.524 843 590)\n --- Packet 4063863\n Data(1 byte)\n Duration(66.160ns) Time(282.000ns) Timestamp(18.524 845 722)\r\n\r\nAccording to Windows driver, no ZLP is needed if wBlockLength is non-zero,\nbecause the non-zero wBlockLength has already told the function side the\nsize of transfer to be expected. However, there are in-market NCM devices\nthat rely on ZLP as long as the wBlockLength is multiple of wMaxPacketSize.\nTo deal with such devices, it pads an extra 0 at end so the transfer is no\nlonger multiple of wMaxPacketSize.(CVE-2024-27405)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nipv6: fix potential \u0026quot;struct net\u0026quot; leak in inet6_rtm_getaddr()\r\n\r\nIt seems that if userspace provides a correct IFA_TARGET_NETNSID value\nbut no IFA_ADDRESS and IFA_LOCAL attributes, inet6_rtm_getaddr()\nreturns -EINVAL with an elevated \u0026quot;struct net\u0026quot; refcount.(CVE-2024-27417)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nf_tables: flush pending destroy work before exit_net release\r\n\r\nSimilar to 2c9f0293280e (\u0026quot;netfilter: nf_tables: flush pending destroy\nwork before netlink notifier\u0026quot;) to address a race between exit_net and\nthe destroy workqueue.\r\n\r\nThe trace below shows an element to be released via destroy workqueue\nwhile exit_net path (triggered via module removal) has already released\nthe set that is used in such transaction.\r\n\r\n[ 1360.547789] BUG: KASAN: slab-use-after-free in nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables]\n[ 1360.547861] Read of size 8 at addr ffff888140500cc0 by task kworker/4:1/152465\n[ 1360.547870] CPU: 4 PID: 152465 Comm: kworker/4:1 Not tainted 6.8.0+ #359\n[ 1360.547882] Workqueue: events nf_tables_trans_destroy_work [nf_tables]\n[ 1360.547984] Call Trace:\n[ 1360.547991] \u0026lt;TASK\u0026gt;\n[ 1360.547998] dump_stack_lvl+0x53/0x70\n[ 1360.548014] print_report+0xc4/0x610\n[ 1360.548026] ? __virt_addr_valid+0xba/0x160\n[ 1360.548040] ? __pfx__raw_spin_lock_irqsave+0x10/0x10\n[ 1360.548054] ? nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables]\n[ 1360.548176] kasan_report+0xae/0xe0\n[ 1360.548189] ? nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables]\n[ 1360.548312] nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables]\n[ 1360.548447] ? __pfx_nf_tables_trans_destroy_work+0x10/0x10 [nf_tables]\n[ 1360.548577] ? _raw_spin_unlock_irq+0x18/0x30\n[ 1360.548591] process_one_work+0x2f1/0x670\n[ 1360.548610] worker_thread+0x4d3/0x760\n[ 1360.548627] ? __pfx_worker_thread+0x10/0x10\n[ 1360.548640] kthread+0x16b/0x1b0\n[ 1360.548653] ? __pfx_kthread+0x10/0x10\n[ 1360.548665] ret_from_fork+0x2f/0x50\n[ 1360.548679] ? __pfx_kthread+0x10/0x10\n[ 1360.548690] ret_from_fork_asm+0x1a/0x30\n[ 1360.548707] \u0026lt;/TASK\u0026gt;\r\n\r\n[ 1360.548719] Allocated by task 192061:\n[ 1360.548726] kasan_save_stack+0x20/0x40\n[ 1360.548739] kasan_save_track+0x14/0x30\n[ 1360.548750] __kasan_kmalloc+0x8f/0xa0\n[ 1360.548760] __kmalloc_node+0x1f1/0x450\n[ 1360.548771] nf_tables_newset+0x10c7/0x1b50 [nf_tables]\n[ 1360.548883] nfnetlink_rcv_batch+0xbc4/0xdc0 [nfnetlink]\n[ 1360.548909] nfnetlink_rcv+0x1a8/0x1e0 [nfnetlink]\n[ 1360.548927] netlink_unicast+0x367/0x4f0\n[ 1360.548935] netlink_sendmsg+0x34b/0x610\n[ 1360.548944] ____sys_sendmsg+0x4d4/0x510\n[ 1360.548953] ___sys_sendmsg+0xc9/0x120\n[ 1360.548961] __sys_sendmsg+0xbe/0x140\n[ 1360.548971] do_syscall_64+0x55/0x120\n[ 1360.548982] entry_SYSCALL_64_after_hwframe+0x55/0x5d\r\n\r\n[ 1360.548994] Freed by task 192222:\n[ 1360.548999] kasan_save_stack+0x20/0x40\n[ 1360.549009] kasan_save_track+0x14/0x30\n[ 1360.549019] kasan_save_free_info+0x3b/0x60\n[ 1360.549028] poison_slab_object+0x100/0x180\n[ 1360.549036] __kasan_slab_free+0x14/0x30\n[ 1360.549042] kfree+0xb6/0x260\n[ 1360.549049] __nft_release_table+0x473/0x6a0 [nf_tables]\n[ 1360.549131] nf_tables_exit_net+0x170/0x240 [nf_tables]\n[ 1360.549221] ops_exit_list+0x50/0xa0\n[ 1360.549229] free_exit_list+0x101/0x140\n[ 1360.549236] unregister_pernet_operations+0x107/0x160\n[ 1360.549245] unregister_pernet_subsys+0x1c/0x30\n[ 1360.549254] nf_tables_module_exit+0x43/0x80 [nf_tables]\n[ 1360.549345] __do_sys_delete_module+0x253/0x370\n[ 1360.549352] do_syscall_64+0x55/0x120\n[ 1360.549360] entry_SYSCALL_64_after_hwframe+0x55/0x5d\r\n\r\n(gdb) list *__nft_release_table+0x473\n0x1e033 is in __nft_release_table (net/netfilter/nf_tables_api.c:11354).\n11349 list_for_each_entry_safe(flowtable, nf, \u0026amp;table-\u0026gt;flowtables, list) {\n11350 list_del(\u0026amp;flowtable-\u0026gt;list);\n11351 nft_use_dec(\u0026amp;table-\u0026gt;use);\n11352 nf_tables_flowtable_destroy(flowtable);\n11353 }\n11354 list_for_each_entry_safe(set, ns, \u0026amp;table-\u0026gt;sets, list) {\n11355 list_del(\u0026amp;set-\u0026gt;list);\n11356 nft_use_dec(\u0026amp;table-\u0026gt;use);\n11357 if (set-\u0026gt;flags \u0026amp; (NFT_SET_MAP | NFT_SET_OBJECT))\n11358 nft_map_deactivat\n---truncated---(CVE-2024-35899)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndyndbg: fix old BUG_ON in \u0026gt;control parser\r\n\r\nFix a BUG_ON from 2009. Even if it looks \u0026quot;unreachable\u0026quot; (I didn\u0026apos;t\nreally look), lets make sure by removing it, doing pr_err and return\n-EINVAL instead.(CVE-2024-35947)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/sched: taprio: always validate TCA_TAPRIO_ATTR_PRIOMAP\r\n\r\nIf one TCA_TAPRIO_ATTR_PRIOMAP attribute has been provided,\ntaprio_parse_mqprio_opt() must validate it, or userspace\ncan inject arbitrary data to the kernel, the second time\ntaprio_change() is called.\r\n\r\nFirst call (with valid attributes) sets dev-\u0026gt;num_tc\nto a non zero value.\r\n\r\nSecond call (with arbitrary mqprio attributes)\nreturns early from taprio_parse_mqprio_opt()\nand bad things can happen.(CVE-2024-36974)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntcp: Fix shift-out-of-bounds in dctcp_update_alpha().\r\n\r\nIn dctcp_update_alpha(), we use a module parameter dctcp_shift_g\nas follows:\r\n\r\n alpha -= min_not_zero(alpha, alpha \u0026gt;\u0026gt; dctcp_shift_g);\n ...\n delivered_ce \u0026lt;\u0026lt;= (10 - dctcp_shift_g);\r\n\r\nIt seems syzkaller started fuzzing module parameters and triggered\nshift-out-of-bounds [0] by setting 100 to dctcp_shift_g:\r\n\r\n memcpy((void*)0x20000080,\n \u0026quot;/sys/module/tcp_dctcp/parameters/dctcp_shift_g\\000\u0026quot;, 47);\n res = syscall(__NR_openat, /*fd=*/0xffffffffffffff9cul, /*file=*/0x20000080ul,\n /*flags=*/2ul, /*mode=*/0ul);\n memcpy((void*)0x20000000, \u0026quot;100\\000\u0026quot;, 4);\n syscall(__NR_write, /*fd=*/r[0], /*val=*/0x20000000ul, /*len=*/4ul);\r\n\r\nLet\u0026apos;s limit the max value of dctcp_shift_g by param_set_uint_minmax().\r\n\r\nWith this patch:\r\n\r\n # echo 10 \u0026gt; /sys/module/tcp_dctcp/parameters/dctcp_shift_g\n # cat /sys/module/tcp_dctcp/parameters/dctcp_shift_g\n 10\n # echo 11 \u0026gt; /sys/module/tcp_dctcp/parameters/dctcp_shift_g\n -bash: echo: write error: Invalid argument\r\n\r\n[0]:\nUBSAN: shift-out-of-bounds in net/ipv4/tcp_dctcp.c:143:12\nshift exponent 100 is too large for 32-bit type \u0026apos;u32\u0026apos; (aka \u0026apos;unsigned int\u0026apos;)\nCPU: 0 PID: 8083 Comm: syz-executor345 Not tainted 6.9.0-05151-g1b294a1f3561 #2\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS\n1.13.0-1ubuntu1.1 04/01/2014\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0x201/0x300 lib/dump_stack.c:114\n ubsan_epilogue lib/ubsan.c:231 [inline]\n __ubsan_handle_shift_out_of_bounds+0x346/0x3a0 lib/ubsan.c:468\n dctcp_update_alpha+0x540/0x570 net/ipv4/tcp_dctcp.c:143\n tcp_in_ack_event net/ipv4/tcp_input.c:3802 [inline]\n tcp_ack+0x17b1/0x3bc0 net/ipv4/tcp_input.c:3948\n tcp_rcv_state_process+0x57a/0x2290 net/ipv4/tcp_input.c:6711\n tcp_v4_do_rcv+0x764/0xc40 net/ipv4/tcp_ipv4.c:1937\n sk_backlog_rcv include/net/sock.h:1106 [inline]\n __release_sock+0x20f/0x350 net/core/sock.c:2983\n release_sock+0x61/0x1f0 net/core/sock.c:3549\n mptcp_subflow_shutdown+0x3d0/0x620 net/mptcp/protocol.c:2907\n mptcp_check_send_data_fin+0x225/0x410 net/mptcp/protocol.c:2976\n __mptcp_close+0x238/0xad0 net/mptcp/protocol.c:3072\n mptcp_close+0x2a/0x1a0 net/mptcp/protocol.c:3127\n inet_release+0x190/0x1f0 net/ipv4/af_inet.c:437\n __sock_release net/socket.c:659 [inline]\n sock_close+0xc0/0x240 net/socket.c:1421\n __fput+0x41b/0x890 fs/file_table.c:422\n task_work_run+0x23b/0x300 kernel/task_work.c:180\n exit_task_work include/linux/task_work.h:38 [inline]\n do_exit+0x9c8/0x2540 kernel/exit.c:878\n do_group_exit+0x201/0x2b0 kernel/exit.c:1027\n __do_sys_exit_group kernel/exit.c:1038 [inline]\n __se_sys_exit_group kernel/exit.c:1036 [inline]\n __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1036\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xe4/0x240 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x67/0x6f\nRIP: 0033:0x7f6c2b5005b6\nCode: Unable to access opcode bytes at 0x7f6c2b50058c.\nRSP: 002b:00007ffe883eb948 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7\nRAX: ffffffffffffffda RBX: 00007f6c2b5862f0 RCX: 00007f6c2b5005b6\nRDX: 0000000000000001 RSI: 000000000000003c RDI: 0000000000000001\nRBP: 0000000000000001 R08: 00000000000000e7 R09: ffffffffffffffc0\nR10: 0000000000000006 R11: 0000000000000246 R12: 00007f6c2b5862f0\nR13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000001\n \u0026lt;/TASK\u0026gt;(CVE-2024-37356)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: bridge: xmit: make sure we have at least eth header len bytes\r\n\r\nsyzbot triggered an uninit value[1] error in bridge device\u0026apos;s xmit path\nby sending a short (less than ETH_HLEN bytes) skb. To fix it check if\nwe can actually pull that amount instead of assuming.\r\n\r\nTested with dropwatch:\n drop at: br_dev_xmit+0xb93/0x12d0 [bridge] (0xffffffffc06739b3)\n origin: software\n timestamp: Mon May 13 11:31:53 2024 778214037 nsec\n protocol: 0x88a8\n length: 2\n original length: 2\n drop reason: PKT_TOO_SMALL\r\n\r\n[1]\nBUG: KMSAN: uninit-value in br_dev_xmit+0x61d/0x1cb0 net/bridge/br_device.c:65\n br_dev_xmit+0x61d/0x1cb0 net/bridge/br_device.c:65\n __netdev_start_xmit include/linux/netdevice.h:4903 [inline]\n netdev_start_xmit include/linux/netdevice.h:4917 [inline]\n xmit_one net/core/dev.c:3531 [inline]\n dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3547\n __dev_queue_xmit+0x34db/0x5350 net/core/dev.c:4341\n dev_queue_xmit include/linux/netdevice.h:3091 [inline]\n __bpf_tx_skb net/core/filter.c:2136 [inline]\n __bpf_redirect_common net/core/filter.c:2180 [inline]\n __bpf_redirect+0x14a6/0x1620 net/core/filter.c:2187\n ____bpf_clone_redirect net/core/filter.c:2460 [inline]\n bpf_clone_redirect+0x328/0x470 net/core/filter.c:2432\n ___bpf_prog_run+0x13fe/0xe0f0 kernel/bpf/core.c:1997\n __bpf_prog_run512+0xb5/0xe0 kernel/bpf/core.c:2238\n bpf_dispatcher_nop_func include/linux/bpf.h:1234 [inline]\n __bpf_prog_run include/linux/filter.h:657 [inline]\n bpf_prog_run include/linux/filter.h:664 [inline]\n bpf_test_run+0x499/0xc30 net/bpf/test_run.c:425\n bpf_prog_test_run_skb+0x14ea/0x1f20 net/bpf/test_run.c:1058\n bpf_prog_test_run+0x6b7/0xad0 kernel/bpf/syscall.c:4269\n __sys_bpf+0x6aa/0xd90 kernel/bpf/syscall.c:5678\n __do_sys_bpf kernel/bpf/syscall.c:5767 [inline]\n __se_sys_bpf kernel/bpf/syscall.c:5765 [inline]\n __x64_sys_bpf+0xa0/0xe0 kernel/bpf/syscall.c:5765\n x64_sys_call+0x96b/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:322\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2024-38538)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nof: module: add buffer overflow check in of_modalias()\r\n\r\nIn of_modalias(), if the buffer happens to be too small even for the 1st\nsnprintf() call, the len parameter will become negative and str parameter\n(if not NULL initially) will point beyond the buffer\u0026apos;s end. Add the buffer\noverflow check after the 1st snprintf() call and fix such check after the\nstrlen() call (accounting for the terminating NUL char).(CVE-2024-38541)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/mediatek: Add 0 size check to mtk_drm_gem_obj\r\n\r\nAdd a check to mtk_drm_gem_init if we attempt to allocate a GEM object\nof 0 bytes. Currently, no such check exists and the kernel will panic if\na userspace application attempts to allocate a 0x0 GBM buffer.\r\n\r\nTested by attempting to allocate a 0x0 GBM buffer on an MT8188 and\nverifying that we now return EINVAL.(CVE-2024-38549)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: fec: remove .ndo_poll_controller to avoid deadlocks\r\n\r\nThere is a deadlock issue found in sungem driver, please refer to the\ncommit ac0a230f719b (\u0026quot;eth: sungem: remove .ndo_poll_controller to avoid\ndeadlocks\u0026quot;). The root cause of the issue is that netpoll is in atomic\ncontext and disable_irq() is called by .ndo_poll_controller interface\nof sungem driver, however, disable_irq() might sleep. After analyzing\nthe implementation of fec_poll_controller(), the fec driver should have\nthe same issue. Due to the fec driver uses NAPI for TX completions, the\n.ndo_poll_controller is unnecessary to be implemented in the fec driver,\nso fec_poll_controller() can be safely removed.(CVE-2024-38553)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/mlx5: Discard command completions in internal error\r\n\r\nFix use after free when FW completion arrives while device is in\ninternal error state. Avoid calling completion handler in this case,\nsince the device will flush the command interface and trigger all\ncompletions manually.\r\n\r\nKernel log:\n------------[ cut here ]------------\nrefcount_t: underflow; use-after-free.\n...\nRIP: 0010:refcount_warn_saturate+0xd8/0xe0\n...\nCall Trace:\n\u0026lt;IRQ\u0026gt;\n? __warn+0x79/0x120\n? refcount_warn_saturate+0xd8/0xe0\n? report_bug+0x17c/0x190\n? handle_bug+0x3c/0x60\n? exc_invalid_op+0x14/0x70\n? asm_exc_invalid_op+0x16/0x20\n? refcount_warn_saturate+0xd8/0xe0\ncmd_ent_put+0x13b/0x160 [mlx5_core]\nmlx5_cmd_comp_handler+0x5f9/0x670 [mlx5_core]\ncmd_comp_notifier+0x1f/0x30 [mlx5_core]\nnotifier_call_chain+0x35/0xb0\natomic_notifier_call_chain+0x16/0x20\nmlx5_eq_async_int+0xf6/0x290 [mlx5_core]\nnotifier_call_chain+0x35/0xb0\natomic_notifier_call_chain+0x16/0x20\nirq_int_handler+0x19/0x30 [mlx5_core]\n__handle_irq_event_percpu+0x4b/0x160\nhandle_irq_event+0x2e/0x80\nhandle_edge_irq+0x98/0x230\n__common_interrupt+0x3b/0xa0\ncommon_interrupt+0x7b/0xa0\n\u0026lt;/IRQ\u0026gt;\n\u0026lt;TASK\u0026gt;\nasm_common_interrupt+0x22/0x40(CVE-2024-38555)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/mlx5: Add a timeout to acquire the command queue semaphore\r\n\r\nPrevent forced completion handling on an entry that has not yet been\nassigned an index, causing an out of bounds access on idx = -22.\nInstead of waiting indefinitely for the sem, blocking flow now waits for\nindex to be allocated or a sem acquisition timeout before beginning the\ntimer for FW completion.\r\n\r\nKernel log example:\nmlx5_core 0000:06:00.0: wait_func_handle_exec_timeout:1128:(pid 185911): cmd[-22]: CREATE_UCTX(0xa04) No done completion(CVE-2024-38556)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbpf: Add BPF_PROG_TYPE_CGROUP_SKB attach type enforcement in BPF_LINK_CREATE\r\n\r\nbpf_prog_attach uses attach_type_to_prog_type to enforce proper\nattach type for BPF_PROG_TYPE_CGROUP_SKB. link_create uses\nbpf_prog_get and relies on bpf_prog_attach_check_attach_type\nto properly verify prog_type \u0026lt;\u0026gt; attach_type association.\r\n\r\nAdd missing attach_type enforcement for the link_create case.\nOtherwise, it\u0026apos;s currently possible to attach cgroup_skb prog\ntypes to other cgroup hooks.(CVE-2024-38564)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nspeakup: Fix sizeof() vs ARRAY_SIZE() bug\r\n\r\nThe \u0026quot;buf\u0026quot; pointer is an array of u16 values. This code should be\nusing ARRAY_SIZE() (which is 256) instead of sizeof() (which is 512),\notherwise it can the still got out of bounds.(CVE-2024-38587)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\njffs2: prevent xattr node from overflowing the eraseblock\r\n\r\nAdd a check to make sure that the requested xattr node size is no larger\nthan the eraseblock minus the cleanmarker.\r\n\r\nUnlike the usual inode nodes, the xattr nodes aren\u0026apos;t split into parts\nand spread across multiple eraseblocks, which means that a xattr node\nmust not occupy more than one eraseblock. If the requested xattr value is\ntoo large, the xattr node can spill onto the next eraseblock, overwriting\nthe nodes and causing errors such as:\r\n\r\njffs2: argh. node added in wrong place at 0x0000b050(2)\njffs2: nextblock 0x0000a000, expected at 0000b00c\njffs2: error: (823) do_verify_xattr_datum: node CRC failed at 0x01e050,\nread=0xfc892c93, calc=0x000000\njffs2: notice: (823) jffs2_get_inode_nodes: Node header CRC failed\nat 0x01e00c. {848f,2fc4,0fef511f,59a3d171}\njffs2: Node at 0x0000000c with length 0x00001044 would run over the\nend of the erase block\njffs2: Perhaps the file system was created with the wrong erase size?\njffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found\nat 0x00000010: 0x1044 instead\r\n\r\nThis breaks the filesystem and can lead to KASAN crashes such as:\r\n\r\nBUG: KASAN: slab-out-of-bounds in jffs2_sum_add_kvec+0x125e/0x15d0\nRead of size 4 at addr ffff88802c31e914 by task repro/830\nCPU: 0 PID: 830 Comm: repro Not tainted 6.9.0-rc3+ #1\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996),\nBIOS Arch Linux 1.16.3-1-1 04/01/2014\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0xc6/0x120\n print_report+0xc4/0x620\n ? __virt_addr_valid+0x308/0x5b0\n kasan_report+0xc1/0xf0\n ? jffs2_sum_add_kvec+0x125e/0x15d0\n ? jffs2_sum_add_kvec+0x125e/0x15d0\n jffs2_sum_add_kvec+0x125e/0x15d0\n jffs2_flash_direct_writev+0xa8/0xd0\n jffs2_flash_writev+0x9c9/0xef0\n ? __x64_sys_setxattr+0xc4/0x160\n ? do_syscall_64+0x69/0x140\n ? entry_SYSCALL_64_after_hwframe+0x76/0x7e\n [...]\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2024-38599)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfs/ntfs3: Use 64 bit variable to avoid 32 bit overflow\r\n\r\nFor example, in the expression:\n\tvbo = 2 * vbo + skip(CVE-2024-38624)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwatchdog: cpu5wdt.c: Fix use-after-free bug caused by cpu5wdt_trigger\r\n\r\nWhen the cpu5wdt module is removing, the origin code uses del_timer() to\nde-activate the timer. If the timer handler is running, del_timer() could\nnot stop it and will return directly. If the port region is released by\nrelease_region() and then the timer handler cpu5wdt_trigger() calls outb()\nto write into the region that is released, the use-after-free bug will\nhappen.\r\n\r\nChange del_timer() to timer_shutdown_sync() in order that the timer handler\ncould be finished before the port region is released.(CVE-2024-38630)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ns390/ap: Fix crash in AP internal function modify_bitmap()\r\n\r\nA system crash like this\r\n\r\n Failing address: 200000cb7df6f000 TEID: 200000cb7df6f403\n Fault in home space mode while using kernel ASCE.\n AS:00000002d71bc007 R3:00000003fe5b8007 S:000000011a446000 P:000000015660c13d\n Oops: 0038 ilc:3 [#1] PREEMPT SMP\n Modules linked in: mlx5_ib ...\n CPU: 8 PID: 7556 Comm: bash Not tainted 6.9.0-rc7 #8\n Hardware name: IBM 3931 A01 704 (LPAR)\n Krnl PSW : 0704e00180000000 0000014b75e7b606 (ap_parse_bitmap_str+0x10e/0x1f8)\n R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3\n Krnl GPRS: 0000000000000001 ffffffffffffffc0 0000000000000001 00000048f96b75d3\n 000000cb00000100 ffffffffffffffff ffffffffffffffff 000000cb7df6fce0\n 000000cb7df6fce0 00000000ffffffff 000000000000002b 00000048ffffffff\n 000003ff9b2dbc80 200000cb7df6fcd8 0000014bffffffc0 000000cb7df6fbc8\n Krnl Code: 0000014b75e7b5fc: a7840047 brc 8,0000014b75e7b68a\n 0000014b75e7b600: 18b2 lr %r11,%r2\n #0000014b75e7b602: a7f4000a brc 15,0000014b75e7b616\n \u0026gt;0000014b75e7b606: eb22d00000e6 laog %r2,%r2,0(%r13)\n 0000014b75e7b60c: a7680001 lhi %r6,1\n 0000014b75e7b610: 187b lr %r7,%r11\n 0000014b75e7b612: 84960021 brxh %r9,%r6,0000014b75e7b654\n 0000014b75e7b616: 18e9 lr %r14,%r9\n Call Trace:\n [\u0026lt;0000014b75e7b606\u0026gt;] ap_parse_bitmap_str+0x10e/0x1f8\n ([\u0026lt;0000014b75e7b5dc\u0026gt;] ap_parse_bitmap_str+0xe4/0x1f8)\n [\u0026lt;0000014b75e7b758\u0026gt;] apmask_store+0x68/0x140\n [\u0026lt;0000014b75679196\u0026gt;] kernfs_fop_write_iter+0x14e/0x1e8\n [\u0026lt;0000014b75598524\u0026gt;] vfs_write+0x1b4/0x448\n [\u0026lt;0000014b7559894c\u0026gt;] ksys_write+0x74/0x100\n [\u0026lt;0000014b7618a440\u0026gt;] __do_syscall+0x268/0x328\n [\u0026lt;0000014b761a3558\u0026gt;] system_call+0x70/0x98\n INFO: lockdep is turned off.\n Last Breaking-Event-Address:\n [\u0026lt;0000014b75e7b636\u0026gt;] ap_parse_bitmap_str+0x13e/0x1f8\n Kernel panic - not syncing: Fatal exception: panic_on_oops\r\n\r\noccured when /sys/bus/ap/a[pq]mask was updated with a relative mask value\n(like +0x10-0x12,+60,-90) with one of the numeric values exceeding INT_MAX.\r\n\r\nThe fix is simple: use unsigned long values for the internal variables. The\ncorrect checks are already in place in the function but a simple int for\nthe internal variables was used with the possibility to overflow.(CVE-2024-38661)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\num: Add winch to winch_handlers before registering winch IRQ\r\n\r\nRegistering a winch IRQ is racy, an interrupt may occur before the winch is\nadded to the winch_handlers list.\r\n\r\nIf that happens, register_winch_irq() adds to that list a winch that is\nscheduled to be (or has already been) freed, causing a panic later in\nwinch_cleanup().\r\n\r\nAvoid the race by adding the winch to the winch_handlers list before\nregistering the IRQ, and rolling back if um_request_irq() fails.(CVE-2024-39292)",
"id": "OESA-2024-1792",
"modified": "2026-08-06T11:07:15Z",
"published": "2024-07-05T11:07:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1792"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27405"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27417"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35899"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35947"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36974"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-37356"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38538"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38541"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38549"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38553"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38555"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38556"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38564"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38587"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38599"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38624"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38630"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38661"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39292"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2024-27405",
"CVE-2024-27417",
"CVE-2024-35899",
"CVE-2024-35947",
"CVE-2024-36974",
"CVE-2024-37356",
"CVE-2024-38538",
"CVE-2024-38541",
"CVE-2024-38549",
"CVE-2024-38553",
"CVE-2024-38555",
"CVE-2024-38556",
"CVE-2024-38564",
"CVE-2024-38587",
"CVE-2024-38599",
"CVE-2024-38624",
"CVE-2024-38630",
"CVE-2024-38661",
"CVE-2024-39292"
]
}
RHSA-2024:5101
Vulnerability from csaf_redhat - Published: 2024-08-08 04:53 - Updated: 2026-09-13 08:28In the Linux kernel, the following vulnerability has been resolved: dyndbg: fix old BUG_ON in >control parser The Linux kernel CVE team has assigned CVE-2024-35947 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051952-CVE-2024-35947-09bb@gregkh/T
RHSA-2024:5102
Vulnerability from csaf_redhat - Published: 2024-08-08 04:44 - Updated: 2026-09-13 08:28In the Linux kernel, the following vulnerability has been resolved: dyndbg: fix old BUG_ON in >control parser The Linux kernel CVE team has assigned CVE-2024-35947 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051952-CVE-2024-35947-09bb@gregkh/T
RHSA-2024:9315
Vulnerability from csaf_redhat - Published: 2024-11-12 09:11 - Updated: 2026-09-13 08:43In the Linux kernel, the following vulnerability has been resolved: dyndbg: fix old BUG_ON in >control parser The Linux kernel CVE team has assigned CVE-2024-35947 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051952-CVE-2024-35947-09bb@gregkh/T
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.