Action not permitted
Modal body text goes here.
Modal Title
Modal Body
CVE-2023-52809 (GCVE-0-2023-52809)
Vulnerability from cvelistv5 – Published: 2024-05-21 15:31 – Updated: 2026-05-11 19:33| Vendor | Product | Version | CPE status | |
|---|---|---|---|---|
| Linux | Linux |
Affected:
42e9a92fe6a9095bd68a379aaec7ad2be0337f7a , < 930f0aaba4820d6362de4e6ed569eaf444f1ea4e
(git)
Affected: 42e9a92fe6a9095bd68a379aaec7ad2be0337f7a , < 77072ec41d6ab3718c3fc639bc149b8037caedfa (git) Affected: 42e9a92fe6a9095bd68a379aaec7ad2be0337f7a , < b549acf999824d4f751ca57965700372f2f3ad00 (git) Affected: 42e9a92fe6a9095bd68a379aaec7ad2be0337f7a , < bb83f79f90e92f46466adcfd4fd264a7ae0f0f01 (git) Affected: 42e9a92fe6a9095bd68a379aaec7ad2be0337f7a , < 56d78b5495ebecbb9395101f3be177cd0a52450b (git) Affected: 42e9a92fe6a9095bd68a379aaec7ad2be0337f7a , < 442fd24d7b6b29e4a9cd9225afba4142d5f522ba (git) Affected: 42e9a92fe6a9095bd68a379aaec7ad2be0337f7a , < f6fe7261b92b21109678747f36df9fdab1e30c34 (git) Affected: 42e9a92fe6a9095bd68a379aaec7ad2be0337f7a , < 6b9ecf4e1032e645873933e5b43cbb84cac19106 (git) Affected: 42e9a92fe6a9095bd68a379aaec7ad2be0337f7a , < 4df105f0ce9f6f30cda4e99f577150d23f0c9c5f (git) |
guessed | |
| Linux | Linux |
Affected:
2.6.29
Unaffected: 0 , < 2.6.29 (semver) Unaffected: 4.14.331 , ≤ 4.14.* (semver) Unaffected: 4.19.300 , ≤ 4.19.* (semver) Unaffected: 5.4.262 , ≤ 5.4.* (semver) Unaffected: 5.10.202 , ≤ 5.10.* (semver) Unaffected: 5.15.140 , ≤ 5.15.* (semver) Unaffected: 6.1.64 , ≤ 6.1.* (semver) Unaffected: 6.5.13 , ≤ 6.5.* (semver) Unaffected: 6.6.3 , ≤ 6.6.* (semver) Unaffected: 6.7 , ≤ * (original_commit_for_fix) |
guessed |
{
"containers": {
"adp": [
{
"providerMetadata": {
"dateUpdated": "2024-08-02T23:11:35.696Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/930f0aaba4820d6362de4e6ed569eaf444f1ea4e"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/77072ec41d6ab3718c3fc639bc149b8037caedfa"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/b549acf999824d4f751ca57965700372f2f3ad00"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/bb83f79f90e92f46466adcfd4fd264a7ae0f0f01"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/56d78b5495ebecbb9395101f3be177cd0a52450b"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/442fd24d7b6b29e4a9cd9225afba4142d5f522ba"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/f6fe7261b92b21109678747f36df9fdab1e30c34"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/6b9ecf4e1032e645873933e5b43cbb84cac19106"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/4df105f0ce9f6f30cda4e99f577150d23f0c9c5f"
}
],
"title": "CVE Program Container"
},
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2023-52809",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2024-09-10T15:36:44.046464Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2024-09-11T17:32:54.752Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/scsi/libfc/fc_lport.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "930f0aaba4820d6362de4e6ed569eaf444f1ea4e",
"status": "affected",
"version": "42e9a92fe6a9095bd68a379aaec7ad2be0337f7a",
"versionType": "git"
},
{
"lessThan": "77072ec41d6ab3718c3fc639bc149b8037caedfa",
"status": "affected",
"version": "42e9a92fe6a9095bd68a379aaec7ad2be0337f7a",
"versionType": "git"
},
{
"lessThan": "b549acf999824d4f751ca57965700372f2f3ad00",
"status": "affected",
"version": "42e9a92fe6a9095bd68a379aaec7ad2be0337f7a",
"versionType": "git"
},
{
"lessThan": "bb83f79f90e92f46466adcfd4fd264a7ae0f0f01",
"status": "affected",
"version": "42e9a92fe6a9095bd68a379aaec7ad2be0337f7a",
"versionType": "git"
},
{
"lessThan": "56d78b5495ebecbb9395101f3be177cd0a52450b",
"status": "affected",
"version": "42e9a92fe6a9095bd68a379aaec7ad2be0337f7a",
"versionType": "git"
},
{
"lessThan": "442fd24d7b6b29e4a9cd9225afba4142d5f522ba",
"status": "affected",
"version": "42e9a92fe6a9095bd68a379aaec7ad2be0337f7a",
"versionType": "git"
},
{
"lessThan": "f6fe7261b92b21109678747f36df9fdab1e30c34",
"status": "affected",
"version": "42e9a92fe6a9095bd68a379aaec7ad2be0337f7a",
"versionType": "git"
},
{
"lessThan": "6b9ecf4e1032e645873933e5b43cbb84cac19106",
"status": "affected",
"version": "42e9a92fe6a9095bd68a379aaec7ad2be0337f7a",
"versionType": "git"
},
{
"lessThan": "4df105f0ce9f6f30cda4e99f577150d23f0c9c5f",
"status": "affected",
"version": "42e9a92fe6a9095bd68a379aaec7ad2be0337f7a",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/scsi/libfc/fc_lport.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "2.6.29"
},
{
"lessThan": "2.6.29",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "4.14.*",
"status": "unaffected",
"version": "4.14.331",
"versionType": "semver"
},
{
"lessThanOrEqual": "4.19.*",
"status": "unaffected",
"version": "4.19.300",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.262",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.202",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.140",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.64",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.5.*",
"status": "unaffected",
"version": "6.5.13",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.3",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.7",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "4.14.331",
"versionStartIncluding": "2.6.29",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "4.19.300",
"versionStartIncluding": "2.6.29",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.4.262",
"versionStartIncluding": "2.6.29",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.10.202",
"versionStartIncluding": "2.6.29",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.15.140",
"versionStartIncluding": "2.6.29",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.1.64",
"versionStartIncluding": "2.6.29",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.5.13",
"versionStartIncluding": "2.6.29",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6.3",
"versionStartIncluding": "2.6.29",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.7",
"versionStartIncluding": "2.6.29",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: libfc: Fix potential NULL pointer dereference in fc_lport_ptp_setup()\n\nfc_lport_ptp_setup() did not check the return value of fc_rport_create()\nwhich can return NULL and would cause a NULL pointer dereference. Address\nthis issue by checking return value of fc_rport_create() and log error\nmessage on fc_rport_create() failed."
}
],
"providerMetadata": {
"dateUpdated": "2026-05-11T19:33:31.862Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/930f0aaba4820d6362de4e6ed569eaf444f1ea4e"
},
{
"url": "https://git.kernel.org/stable/c/77072ec41d6ab3718c3fc639bc149b8037caedfa"
},
{
"url": "https://git.kernel.org/stable/c/b549acf999824d4f751ca57965700372f2f3ad00"
},
{
"url": "https://git.kernel.org/stable/c/bb83f79f90e92f46466adcfd4fd264a7ae0f0f01"
},
{
"url": "https://git.kernel.org/stable/c/56d78b5495ebecbb9395101f3be177cd0a52450b"
},
{
"url": "https://git.kernel.org/stable/c/442fd24d7b6b29e4a9cd9225afba4142d5f522ba"
},
{
"url": "https://git.kernel.org/stable/c/f6fe7261b92b21109678747f36df9fdab1e30c34"
},
{
"url": "https://git.kernel.org/stable/c/6b9ecf4e1032e645873933e5b43cbb84cac19106"
},
{
"url": "https://git.kernel.org/stable/c/4df105f0ce9f6f30cda4e99f577150d23f0c9c5f"
}
],
"title": "scsi: libfc: Fix potential NULL pointer dereference in fc_lport_ptp_setup()",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2023-52809",
"datePublished": "2024-05-21T15:31:18.982Z",
"dateReserved": "2024-05-21T15:19:24.248Z",
"dateUpdated": "2026-05-11T19:33:31.862Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"epss": {
"cve": "CVE-2023-52809",
"date": "2026-09-19",
"epss": "0.00249",
"percentile": "0.16547"
},
"fkie_nvd": {
"configurations": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "6F120ED7-3012-4856-9F08-B433BC310335",
"versionEndExcluding": "4.14.331",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "C99DDB75-1CAC-40D0-A14D-67A2A55D6005",
"versionEndExcluding": "4.19.300",
"versionStartIncluding": "4.15",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "28B0AAED-45BA-4928-9A85-66A429B9F038",
"versionEndExcluding": "5.4.262",
"versionStartIncluding": "4.20",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "39D508B4-58C7-40C2-BE05-44E41110EB98",
"versionEndExcluding": "5.10.202",
"versionStartIncluding": "5.5",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "15D6C23C-78A3-40D2-B76B-4F1D9C2D95C0",
"versionEndExcluding": "5.15.140",
"versionStartIncluding": "5.11",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "8D7C884A-CAA2-4EA2-9FEB-5CE776D7B05F",
"versionEndExcluding": "6.1.64",
"versionStartIncluding": "5.16",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "674C4F82-C336-4B49-BF64-1DE422E889C4",
"versionEndExcluding": "6.5.13",
"versionStartIncluding": "6.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "B58252FA-A49C-411F-9B28-DC5FE44BC5A0",
"versionEndExcluding": "6.6.3",
"versionStartIncluding": "6.6",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: libfc: Fix potential NULL pointer dereference in fc_lport_ptp_setup()\n\nfc_lport_ptp_setup() did not check the return value of fc_rport_create()\nwhich can return NULL and would cause a NULL pointer dereference. Address\nthis issue by checking return value of fc_rport_create() and log error\nmessage on fc_rport_create() failed."
},
{
"lang": "es",
"value": " En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: scsi: libfc: corrigi\u00f3 la posible desreferencia del puntero NULL en fc_lport_ptp_setup() fc_lport_ptp_setup() no verific\u00f3 el valor de retorno de fc_rport_create() que puede devolver NULL y causar\u00eda una desreferencia del puntero NULL. Solucione este problema verificando el valor de retorno de fc_rport_create() y el mensaje de error de registro en fc_rport_create() fall\u00f3."
}
],
"id": "CVE-2023-52809",
"lastModified": "2024-11-21T08:40:38.040",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 5.5,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 3.6,
"source": "nvd@nist.gov",
"type": "Primary"
}
]
},
"published": "2024-05-21T16:15:19.197",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/442fd24d7b6b29e4a9cd9225afba4142d5f522ba"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/4df105f0ce9f6f30cda4e99f577150d23f0c9c5f"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/56d78b5495ebecbb9395101f3be177cd0a52450b"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/6b9ecf4e1032e645873933e5b43cbb84cac19106"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/77072ec41d6ab3718c3fc639bc149b8037caedfa"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/930f0aaba4820d6362de4e6ed569eaf444f1ea4e"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/b549acf999824d4f751ca57965700372f2f3ad00"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/bb83f79f90e92f46466adcfd4fd264a7ae0f0f01"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/f6fe7261b92b21109678747f36df9fdab1e30c34"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/442fd24d7b6b29e4a9cd9225afba4142d5f522ba"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/4df105f0ce9f6f30cda4e99f577150d23f0c9c5f"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/56d78b5495ebecbb9395101f3be177cd0a52450b"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/6b9ecf4e1032e645873933e5b43cbb84cac19106"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/77072ec41d6ab3718c3fc639bc149b8037caedfa"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/930f0aaba4820d6362de4e6ed569eaf444f1ea4e"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/b549acf999824d4f751ca57965700372f2f3ad00"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/bb83f79f90e92f46466adcfd4fd264a7ae0f0f01"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/f6fe7261b92b21109678747f36df9fdab1e30c34"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Modified",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "CWE-476"
}
],
"source": "nvd@nist.gov",
"type": "Primary"
}
]
},
"nvd": {
"cve": {
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/scsi/libfc/fc_lport.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "930f0aaba4820d6362de4e6ed569eaf444f1ea4e",
"status": "affected",
"version": "42e9a92fe6a9095bd68a379aaec7ad2be0337f7a",
"versionType": "git"
},
{
"lessThan": "77072ec41d6ab3718c3fc639bc149b8037caedfa",
"status": "affected",
"version": "42e9a92fe6a9095bd68a379aaec7ad2be0337f7a",
"versionType": "git"
},
{
"lessThan": "b549acf999824d4f751ca57965700372f2f3ad00",
"status": "affected",
"version": "42e9a92fe6a9095bd68a379aaec7ad2be0337f7a",
"versionType": "git"
},
{
"lessThan": "bb83f79f90e92f46466adcfd4fd264a7ae0f0f01",
"status": "affected",
"version": "42e9a92fe6a9095bd68a379aaec7ad2be0337f7a",
"versionType": "git"
},
{
"lessThan": "56d78b5495ebecbb9395101f3be177cd0a52450b",
"status": "affected",
"version": "42e9a92fe6a9095bd68a379aaec7ad2be0337f7a",
"versionType": "git"
},
{
"lessThan": "442fd24d7b6b29e4a9cd9225afba4142d5f522ba",
"status": "affected",
"version": "42e9a92fe6a9095bd68a379aaec7ad2be0337f7a",
"versionType": "git"
},
{
"lessThan": "f6fe7261b92b21109678747f36df9fdab1e30c34",
"status": "affected",
"version": "42e9a92fe6a9095bd68a379aaec7ad2be0337f7a",
"versionType": "git"
},
{
"lessThan": "6b9ecf4e1032e645873933e5b43cbb84cac19106",
"status": "affected",
"version": "42e9a92fe6a9095bd68a379aaec7ad2be0337f7a",
"versionType": "git"
},
{
"lessThan": "4df105f0ce9f6f30cda4e99f577150d23f0c9c5f",
"status": "affected",
"version": "42e9a92fe6a9095bd68a379aaec7ad2be0337f7a",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/scsi/libfc/fc_lport.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "2.6.29"
},
{
"lessThan": "2.6.29",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "4.14.*",
"status": "unaffected",
"version": "4.14.331",
"versionType": "semver"
},
{
"lessThanOrEqual": "4.19.*",
"status": "unaffected",
"version": "4.19.300",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.262",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.202",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.140",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.64",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.5.*",
"status": "unaffected",
"version": "6.5.13",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.3",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.7",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"configurations": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "6F120ED7-3012-4856-9F08-B433BC310335",
"versionEndExcluding": "4.14.331",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "C99DDB75-1CAC-40D0-A14D-67A2A55D6005",
"versionEndExcluding": "4.19.300",
"versionStartIncluding": "4.15",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "28B0AAED-45BA-4928-9A85-66A429B9F038",
"versionEndExcluding": "5.4.262",
"versionStartIncluding": "4.20",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "39D508B4-58C7-40C2-BE05-44E41110EB98",
"versionEndExcluding": "5.10.202",
"versionStartIncluding": "5.5",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "15D6C23C-78A3-40D2-B76B-4F1D9C2D95C0",
"versionEndExcluding": "5.15.140",
"versionStartIncluding": "5.11",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "8D7C884A-CAA2-4EA2-9FEB-5CE776D7B05F",
"versionEndExcluding": "6.1.64",
"versionStartIncluding": "5.16",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "674C4F82-C336-4B49-BF64-1DE422E889C4",
"versionEndExcluding": "6.5.13",
"versionStartIncluding": "6.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "B58252FA-A49C-411F-9B28-DC5FE44BC5A0",
"versionEndExcluding": "6.6.3",
"versionStartIncluding": "6.6",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: libfc: Fix potential NULL pointer dereference in fc_lport_ptp_setup()\n\nfc_lport_ptp_setup() did not check the return value of fc_rport_create()\nwhich can return NULL and would cause a NULL pointer dereference. Address\nthis issue by checking return value of fc_rport_create() and log error\nmessage on fc_rport_create() failed."
},
{
"lang": "es",
"value": " En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: scsi: libfc: corrigi\u00f3 la posible desreferencia del puntero NULL en fc_lport_ptp_setup() fc_lport_ptp_setup() no verific\u00f3 el valor de retorno de fc_rport_create() que puede devolver NULL y causar\u00eda una desreferencia del puntero NULL. Solucione este problema verificando el valor de retorno de fc_rport_create() y el mensaje de error de registro en fc_rport_create() fall\u00f3."
}
],
"id": "CVE-2023-52809",
"lastModified": "2026-06-17T06:43:37.970",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 5.5,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 3.6,
"source": "nvd@nist.gov",
"type": "Primary"
}
],
"ssvcV203": [
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"ssvcData": {
"id": "CVE-2023-52809",
"options": [
{
"exploitation": "none"
},
{
"automatable": "no"
},
{
"technicalImpact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2024-09-10T15:36:44.046464Z",
"version": "2.0.3"
}
}
]
},
"published": "2024-05-21T16:15:19.197",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/442fd24d7b6b29e4a9cd9225afba4142d5f522ba"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/4df105f0ce9f6f30cda4e99f577150d23f0c9c5f"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/56d78b5495ebecbb9395101f3be177cd0a52450b"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/6b9ecf4e1032e645873933e5b43cbb84cac19106"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/77072ec41d6ab3718c3fc639bc149b8037caedfa"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/930f0aaba4820d6362de4e6ed569eaf444f1ea4e"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/b549acf999824d4f751ca57965700372f2f3ad00"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/bb83f79f90e92f46466adcfd4fd264a7ae0f0f01"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/f6fe7261b92b21109678747f36df9fdab1e30c34"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/442fd24d7b6b29e4a9cd9225afba4142d5f522ba"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/4df105f0ce9f6f30cda4e99f577150d23f0c9c5f"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/56d78b5495ebecbb9395101f3be177cd0a52450b"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/6b9ecf4e1032e645873933e5b43cbb84cac19106"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/77072ec41d6ab3718c3fc639bc149b8037caedfa"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/930f0aaba4820d6362de4e6ed569eaf444f1ea4e"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/b549acf999824d4f751ca57965700372f2f3ad00"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/bb83f79f90e92f46466adcfd4fd264a7ae0f0f01"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/f6fe7261b92b21109678747f36df9fdab1e30c34"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Modified",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "CWE-476"
}
],
"source": "nvd@nist.gov",
"type": "Primary"
}
]
}
},
"redhat_vex": {
"aggregate_severity": "Low",
"current_release_date": "2026-03-03T21:28:40+00:00",
"cve": "CVE-2023-52809",
"id": "CVE-2023-52809",
"initial_release_date": "2023-01-01T00:00:00+00:00",
"product_status:fixed": "1493",
"product_status:known_affected": "80",
"product_status:known_not_affected": "67",
"source": "Red Hat CSAF VEX",
"status": "final",
"title": "kernel: scsi: libfc: Fix potential NULL pointer dereference in fc_lport_ptp_setup()",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2023/cve-2023-52809.json",
"version": "3"
},
"suse_vex": {
"aggregate_severity": "moderate",
"current_release_date": "2026-09-12T17:06:45Z",
"cve": "CVE-2023-52809",
"id": "CVE-2023-52809",
"initial_release_date": "2024-05-29T10:00:00Z",
"product_status:known_affected": "467",
"product_status:known_not_affected": "38",
"product_status:recommended": "799",
"source": "SUSE CSAF VEX",
"status": "interim",
"title": "SUSE CVE CVE-2023-52809",
"url": "https://ftp.suse.com/pub/projects/security/csaf-vex/cve-2023-52809.json",
"version": "116"
},
"vulnrichment": {
"containers": {
"adp": [
{
"providerMetadata": {
"dateUpdated": "2024-08-02T23:11:35.696Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/930f0aaba4820d6362de4e6ed569eaf444f1ea4e"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/77072ec41d6ab3718c3fc639bc149b8037caedfa"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/b549acf999824d4f751ca57965700372f2f3ad00"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/bb83f79f90e92f46466adcfd4fd264a7ae0f0f01"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/56d78b5495ebecbb9395101f3be177cd0a52450b"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/442fd24d7b6b29e4a9cd9225afba4142d5f522ba"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/f6fe7261b92b21109678747f36df9fdab1e30c34"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/6b9ecf4e1032e645873933e5b43cbb84cac19106"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/4df105f0ce9f6f30cda4e99f577150d23f0c9c5f"
}
],
"title": "CVE Program Container"
},
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2023-52809",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2024-09-10T15:36:44.046464Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2024-09-11T12:42:13.378Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/scsi/libfc/fc_lport.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "930f0aaba4820d6362de4e6ed569eaf444f1ea4e",
"status": "affected",
"version": "42e9a92fe6a9095bd68a379aaec7ad2be0337f7a",
"versionType": "git"
},
{
"lessThan": "77072ec41d6ab3718c3fc639bc149b8037caedfa",
"status": "affected",
"version": "42e9a92fe6a9095bd68a379aaec7ad2be0337f7a",
"versionType": "git"
},
{
"lessThan": "b549acf999824d4f751ca57965700372f2f3ad00",
"status": "affected",
"version": "42e9a92fe6a9095bd68a379aaec7ad2be0337f7a",
"versionType": "git"
},
{
"lessThan": "bb83f79f90e92f46466adcfd4fd264a7ae0f0f01",
"status": "affected",
"version": "42e9a92fe6a9095bd68a379aaec7ad2be0337f7a",
"versionType": "git"
},
{
"lessThan": "56d78b5495ebecbb9395101f3be177cd0a52450b",
"status": "affected",
"version": "42e9a92fe6a9095bd68a379aaec7ad2be0337f7a",
"versionType": "git"
},
{
"lessThan": "442fd24d7b6b29e4a9cd9225afba4142d5f522ba",
"status": "affected",
"version": "42e9a92fe6a9095bd68a379aaec7ad2be0337f7a",
"versionType": "git"
},
{
"lessThan": "f6fe7261b92b21109678747f36df9fdab1e30c34",
"status": "affected",
"version": "42e9a92fe6a9095bd68a379aaec7ad2be0337f7a",
"versionType": "git"
},
{
"lessThan": "6b9ecf4e1032e645873933e5b43cbb84cac19106",
"status": "affected",
"version": "42e9a92fe6a9095bd68a379aaec7ad2be0337f7a",
"versionType": "git"
},
{
"lessThan": "4df105f0ce9f6f30cda4e99f577150d23f0c9c5f",
"status": "affected",
"version": "42e9a92fe6a9095bd68a379aaec7ad2be0337f7a",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/scsi/libfc/fc_lport.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "2.6.29"
},
{
"lessThan": "2.6.29",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "4.14.*",
"status": "unaffected",
"version": "4.14.331",
"versionType": "semver"
},
{
"lessThanOrEqual": "4.19.*",
"status": "unaffected",
"version": "4.19.300",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.262",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.202",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.140",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.64",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.5.*",
"status": "unaffected",
"version": "6.5.13",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.3",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.7",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "4.14.331",
"versionStartIncluding": "2.6.29",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "4.19.300",
"versionStartIncluding": "2.6.29",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.4.262",
"versionStartIncluding": "2.6.29",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.10.202",
"versionStartIncluding": "2.6.29",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.15.140",
"versionStartIncluding": "2.6.29",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.1.64",
"versionStartIncluding": "2.6.29",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.5.13",
"versionStartIncluding": "2.6.29",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6.3",
"versionStartIncluding": "2.6.29",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.7",
"versionStartIncluding": "2.6.29",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: libfc: Fix potential NULL pointer dereference in fc_lport_ptp_setup()\n\nfc_lport_ptp_setup() did not check the return value of fc_rport_create()\nwhich can return NULL and would cause a NULL pointer dereference. Address\nthis issue by checking return value of fc_rport_create() and log error\nmessage on fc_rport_create() failed."
}
],
"providerMetadata": {
"dateUpdated": "2026-01-05T10:17:23.298Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/930f0aaba4820d6362de4e6ed569eaf444f1ea4e"
},
{
"url": "https://git.kernel.org/stable/c/77072ec41d6ab3718c3fc639bc149b8037caedfa"
},
{
"url": "https://git.kernel.org/stable/c/b549acf999824d4f751ca57965700372f2f3ad00"
},
{
"url": "https://git.kernel.org/stable/c/bb83f79f90e92f46466adcfd4fd264a7ae0f0f01"
},
{
"url": "https://git.kernel.org/stable/c/56d78b5495ebecbb9395101f3be177cd0a52450b"
},
{
"url": "https://git.kernel.org/stable/c/442fd24d7b6b29e4a9cd9225afba4142d5f522ba"
},
{
"url": "https://git.kernel.org/stable/c/f6fe7261b92b21109678747f36df9fdab1e30c34"
},
{
"url": "https://git.kernel.org/stable/c/6b9ecf4e1032e645873933e5b43cbb84cac19106"
},
{
"url": "https://git.kernel.org/stable/c/4df105f0ce9f6f30cda4e99f577150d23f0c9c5f"
}
],
"title": "scsi: libfc: Fix potential NULL pointer dereference in fc_lport_ptp_setup()",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2023-52809",
"datePublished": "2024-05-21T15:31:18.982Z",
"dateReserved": "2024-05-21T15:19:24.248Z",
"dateUpdated": "2026-01-05T10:17:23.298Z",
"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-2023-52809
Vulnerability from fkie_nvd - Published: 2024-05-21 16:15 - Updated: 2026-06-17 06:43| 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 | * |
{
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/scsi/libfc/fc_lport.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "930f0aaba4820d6362de4e6ed569eaf444f1ea4e",
"status": "affected",
"version": "42e9a92fe6a9095bd68a379aaec7ad2be0337f7a",
"versionType": "git"
},
{
"lessThan": "77072ec41d6ab3718c3fc639bc149b8037caedfa",
"status": "affected",
"version": "42e9a92fe6a9095bd68a379aaec7ad2be0337f7a",
"versionType": "git"
},
{
"lessThan": "b549acf999824d4f751ca57965700372f2f3ad00",
"status": "affected",
"version": "42e9a92fe6a9095bd68a379aaec7ad2be0337f7a",
"versionType": "git"
},
{
"lessThan": "bb83f79f90e92f46466adcfd4fd264a7ae0f0f01",
"status": "affected",
"version": "42e9a92fe6a9095bd68a379aaec7ad2be0337f7a",
"versionType": "git"
},
{
"lessThan": "56d78b5495ebecbb9395101f3be177cd0a52450b",
"status": "affected",
"version": "42e9a92fe6a9095bd68a379aaec7ad2be0337f7a",
"versionType": "git"
},
{
"lessThan": "442fd24d7b6b29e4a9cd9225afba4142d5f522ba",
"status": "affected",
"version": "42e9a92fe6a9095bd68a379aaec7ad2be0337f7a",
"versionType": "git"
},
{
"lessThan": "f6fe7261b92b21109678747f36df9fdab1e30c34",
"status": "affected",
"version": "42e9a92fe6a9095bd68a379aaec7ad2be0337f7a",
"versionType": "git"
},
{
"lessThan": "6b9ecf4e1032e645873933e5b43cbb84cac19106",
"status": "affected",
"version": "42e9a92fe6a9095bd68a379aaec7ad2be0337f7a",
"versionType": "git"
},
{
"lessThan": "4df105f0ce9f6f30cda4e99f577150d23f0c9c5f",
"status": "affected",
"version": "42e9a92fe6a9095bd68a379aaec7ad2be0337f7a",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/scsi/libfc/fc_lport.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "2.6.29"
},
{
"lessThan": "2.6.29",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "4.14.*",
"status": "unaffected",
"version": "4.14.331",
"versionType": "semver"
},
{
"lessThanOrEqual": "4.19.*",
"status": "unaffected",
"version": "4.19.300",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.262",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.202",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.140",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.64",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.5.*",
"status": "unaffected",
"version": "6.5.13",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.3",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.7",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"configurations": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "6F120ED7-3012-4856-9F08-B433BC310335",
"versionEndExcluding": "4.14.331",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "C99DDB75-1CAC-40D0-A14D-67A2A55D6005",
"versionEndExcluding": "4.19.300",
"versionStartIncluding": "4.15",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "28B0AAED-45BA-4928-9A85-66A429B9F038",
"versionEndExcluding": "5.4.262",
"versionStartIncluding": "4.20",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "39D508B4-58C7-40C2-BE05-44E41110EB98",
"versionEndExcluding": "5.10.202",
"versionStartIncluding": "5.5",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "15D6C23C-78A3-40D2-B76B-4F1D9C2D95C0",
"versionEndExcluding": "5.15.140",
"versionStartIncluding": "5.11",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "8D7C884A-CAA2-4EA2-9FEB-5CE776D7B05F",
"versionEndExcluding": "6.1.64",
"versionStartIncluding": "5.16",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "674C4F82-C336-4B49-BF64-1DE422E889C4",
"versionEndExcluding": "6.5.13",
"versionStartIncluding": "6.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "B58252FA-A49C-411F-9B28-DC5FE44BC5A0",
"versionEndExcluding": "6.6.3",
"versionStartIncluding": "6.6",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: libfc: Fix potential NULL pointer dereference in fc_lport_ptp_setup()\n\nfc_lport_ptp_setup() did not check the return value of fc_rport_create()\nwhich can return NULL and would cause a NULL pointer dereference. Address\nthis issue by checking return value of fc_rport_create() and log error\nmessage on fc_rport_create() failed."
},
{
"lang": "es",
"value": " En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: scsi: libfc: corrigi\u00f3 la posible desreferencia del puntero NULL en fc_lport_ptp_setup() fc_lport_ptp_setup() no verific\u00f3 el valor de retorno de fc_rport_create() que puede devolver NULL y causar\u00eda una desreferencia del puntero NULL. Solucione este problema verificando el valor de retorno de fc_rport_create() y el mensaje de error de registro en fc_rport_create() fall\u00f3."
}
],
"id": "CVE-2023-52809",
"lastModified": "2026-06-17T06:43:37.970",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 5.5,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 3.6,
"source": "nvd@nist.gov",
"type": "Primary"
}
],
"ssvcV203": [
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"ssvcData": {
"id": "CVE-2023-52809",
"options": [
{
"exploitation": "none"
},
{
"automatable": "no"
},
{
"technicalImpact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2024-09-10T15:36:44.046464Z",
"version": "2.0.3"
}
}
]
},
"published": "2024-05-21T16:15:19.197",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/442fd24d7b6b29e4a9cd9225afba4142d5f522ba"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/4df105f0ce9f6f30cda4e99f577150d23f0c9c5f"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/56d78b5495ebecbb9395101f3be177cd0a52450b"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/6b9ecf4e1032e645873933e5b43cbb84cac19106"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/77072ec41d6ab3718c3fc639bc149b8037caedfa"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/930f0aaba4820d6362de4e6ed569eaf444f1ea4e"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/b549acf999824d4f751ca57965700372f2f3ad00"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/bb83f79f90e92f46466adcfd4fd264a7ae0f0f01"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/f6fe7261b92b21109678747f36df9fdab1e30c34"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/442fd24d7b6b29e4a9cd9225afba4142d5f522ba"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/4df105f0ce9f6f30cda4e99f577150d23f0c9c5f"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/56d78b5495ebecbb9395101f3be177cd0a52450b"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/6b9ecf4e1032e645873933e5b43cbb84cac19106"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/77072ec41d6ab3718c3fc639bc149b8037caedfa"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/930f0aaba4820d6362de4e6ed569eaf444f1ea4e"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/b549acf999824d4f751ca57965700372f2f3ad00"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/bb83f79f90e92f46466adcfd4fd264a7ae0f0f01"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/f6fe7261b92b21109678747f36df9fdab1e30c34"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Modified",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "CWE-476"
}
],
"source": "nvd@nist.gov",
"type": "Primary"
}
]
}
GHSA-RGR4-WRX9-JM8Q
Vulnerability from github – Published: 2024-05-21 18:31 – Updated: 2024-06-03 18:55In the Linux kernel, the following vulnerability has been resolved:
scsi: libfc: Fix potential NULL pointer dereference in fc_lport_ptp_setup()
fc_lport_ptp_setup() did not check the return value of fc_rport_create() which can return NULL and would cause a NULL pointer dereference. Address this issue by checking return value of fc_rport_create() and log error message on fc_rport_create() failed.
{
"affected": [],
"aliases": [
"CVE-2023-52809"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-21T16:15:19Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: libfc: Fix potential NULL pointer dereference in fc_lport_ptp_setup()\n\nfc_lport_ptp_setup() did not check the return value of fc_rport_create()\nwhich can return NULL and would cause a NULL pointer dereference. Address\nthis issue by checking return value of fc_rport_create() and log error\nmessage on fc_rport_create() failed.",
"id": "GHSA-rgr4-wrx9-jm8q",
"modified": "2024-06-03T18:55:26Z",
"published": "2024-05-21T18:31:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52809"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/442fd24d7b6b29e4a9cd9225afba4142d5f522ba"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4df105f0ce9f6f30cda4e99f577150d23f0c9c5f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/56d78b5495ebecbb9395101f3be177cd0a52450b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6b9ecf4e1032e645873933e5b43cbb84cac19106"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/77072ec41d6ab3718c3fc639bc149b8037caedfa"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/930f0aaba4820d6362de4e6ed569eaf444f1ea4e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b549acf999824d4f751ca57965700372f2f3ad00"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bb83f79f90e92f46466adcfd4fd264a7ae0f0f01"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f6fe7261b92b21109678747f36df9fdab1e30c34"
}
],
"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-1680 (CVE-2021-47421)
Vulnerability from osv_openeuler – Published: 2024-05-31 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:
drm/amdgpu: handle the case of pci_channel_io_frozen only in amdgpu_pci_resume
In current code, when a PCI error state pci_channel_io_normal is detectd, it will report PCI_ERS_RESULT_CAN_RECOVER status to PCI driver, and PCI driver will continue the execution of PCI resume callback report_resume by pci_walk_bridge, and the callback will go into amdgpu_pci_resume finally, where write lock is releasd unconditionally without acquiring such lock first. In this case, a deadlock will happen when other threads start to acquire the read lock.
To fix this, add a member in amdgpu_device strucutre to cache pci_channel_state, and only continue the execution in amdgpu_pci_resume when it's pci_channel_io_frozen.(CVE-2021-47421)
In the Linux kernel, the following vulnerability has been resolved:
ptp: Fix possible memory leak in ptp_clock_register()
I got memory leak as follows when doing fault injection test:
unreferenced object 0xffff88800906c618 (size 8): comm "i2c-idt82p33931", pid 4421, jiffies 4294948083 (age 13.188s) hex dump (first 8 bytes): 70 74 70 30 00 00 00 00 ptp0.... backtrace: [<00000000312ed458>] __kmalloc_track_caller+0x19f/0x3a0 [<0000000079f6e2ff>] kvasprintf+0xb5/0x150 [<0000000026aae54f>] kvasprintf_const+0x60/0x190 [<00000000f323a5f7>] kobject_set_name_vargs+0x56/0x150 [<000000004e35abdd>] dev_set_name+0xc0/0x100 [<00000000f20cfe25>] ptp_clock_register+0x9f4/0xd30 [ptp] [<000000008bb9f0de>] idt82p33_probe.cold+0x8b6/0x1561 [ptp_idt82p33]
When posix_clock_register() returns an error, the name allocated in dev_set_name() will be leaked, the put_device() should be used to give up the device reference, then the name will be freed in kobject_cleanup() and other memory will be freed in ptp_clock_release().(CVE-2021-47455)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: ebtables: fix memory leak when blob is malformed
The bug fix was incomplete, it "replaced" crash with a memory leak. The old code had an assignment to "ret" embedded into the conditional, restore this.(CVE-2022-48641)
In the Linux kernel, the following vulnerability has been resolved:
pinctrl: single: fix potential NULL dereference
Added checking of pointer "function" in pcs_set_mux(). pinmux_generic_get_function() can return NULL and the pointer "function" was dereferenced without checking against NULL.
Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2022-48708)
In the Linux kernel, the following vulnerability has been resolved:
drm/tegra: dsi: Add missing check for of_find_device_by_node
Add check for the return value of of_find_device_by_node() and return the error if it fails in order to avoid NULL pointer dereference.(CVE-2023-52650)
In the Linux kernel, the following vulnerability has been resolved:
io_uring: drop any code related to SCM_RIGHTS
This is dead code after we dropped support for passing io_uring fds over SCM_RIGHTS, get rid of it.(CVE-2023-52656)
In the Linux kernel, the following vulnerability has been resolved:
net: atlantic: eliminate double free in error handling logic
Driver has a logic leak in ring data allocation/free, where aq_ring_free could be called multiple times on same ring, if system is under stress and got memory allocation error.
Ring pointer was used as an indicator of failure, but this is not correct since only ring data is allocated/deallocated. Ring itself is an array member.
Changing ring allocation functions to return error code directly. This simplifies error handling and eliminates aq_ring_free on higher layer.(CVE-2023-52664)
In the Linux kernel, the following vulnerability has been resolved:
ACPI: LPIT: Avoid u32 multiplication overflow
In lpit_update_residency() there is a possibility of overflow in multiplication, if tsc_khz is large enough (> UINT_MAX/1000).
Change multiplication to mul_u32_u32().
Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2023-52683)
In the Linux kernel, the following vulnerability has been resolved:
calipso: fix memory leak in netlbl_calipso_add_pass()
If IPv6 support is disabled at boot (ipv6.disable=1), the calipso_init() -> netlbl_calipso_ops_register() function isn't called, and the netlbl_calipso_ops_get() function always returns NULL. In this case, the netlbl_calipso_add_pass() function allocates memory for the doi_def variable but doesn't free it with the calipso_doi_free().
BUG: memory leak unreferenced object 0xffff888011d68180 (size 64): comm "syz-executor.1", pid 10746, jiffies 4295410986 (age 17.928s) hex dump (first 32 bytes): 00 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<...>] kmalloc include/linux/slab.h:552 [inline] [<...>] netlbl_calipso_add_pass net/netlabel/netlabel_calipso.c:76 [inline] [<...>] netlbl_calipso_add+0x22e/0x4f0 net/netlabel/netlabel_calipso.c:111 [<...>] genl_family_rcv_msg_doit+0x22f/0x330 net/netlink/genetlink.c:739 [<...>] genl_family_rcv_msg net/netlink/genetlink.c:783 [inline] [<...>] genl_rcv_msg+0x341/0x5a0 net/netlink/genetlink.c:800 [<...>] netlink_rcv_skb+0x14d/0x440 net/netlink/af_netlink.c:2515 [<...>] genl_rcv+0x29/0x40 net/netlink/genetlink.c:811 [<...>] netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline] [<...>] netlink_unicast+0x54b/0x800 net/netlink/af_netlink.c:1339 [<...>] netlink_sendmsg+0x90a/0xdf0 net/netlink/af_netlink.c:1934 [<...>] sock_sendmsg_nosec net/socket.c:651 [inline] [<...>] sock_sendmsg+0x157/0x190 net/socket.c:671 [<...>] _syssendmsg+0x712/0x870 net/socket.c:2342 [<...>] _sys_sendmsg+0xf8/0x170 net/socket.c:2396 [<...>] __sys_sendmsg+0xea/0x1b0 net/socket.c:2429 [<...>] do_syscall_64+0x30/0x40 arch/x86/entry/common.c:46 [<...>] entry_SYSCALL_64_after_hwframe+0x61/0xc6
Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with Syzkaller
PM: merged via the LSM tree at Jakub Kicinski request
In the Linux kernel, the following vulnerability has been resolved:
scsi: libfc: Fix potential NULL pointer dereference in fc_lport_ptp_setup()
fc_lport_ptp_setup() did not check the return value of fc_rport_create() which can return NULL and would cause a NULL pointer dereference. Address this issue by checking return value of fc_rport_create() and log error message on fc_rport_create() failed.(CVE-2023-52809)
In the Linux kernel, the following vulnerability has been resolved:
crypto: pcrypt - Fix hungtask for PADATA_RESET
We found a hungtask bug in test_aead_vec_cfg as follows:
INFO: task cryptomgr_test:391009 blocked for more than 120 seconds. "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Call trace: __switch_to+0x98/0xe0 __schedule+0x6c4/0xf40 schedule+0xd8/0x1b4 schedule_timeout+0x474/0x560 wait_for_common+0x368/0x4e0 wait_for_completion+0x20/0x30 wait_for_completion+0x20/0x30 test_aead_vec_cfg+0xab4/0xd50 test_aead+0x144/0x1f0 alg_test_aead+0xd8/0x1e0 alg_test+0x634/0x890 cryptomgr_test+0x40/0x70 kthread+0x1e0/0x220 ret_from_fork+0x10/0x18 Kernel panic - not syncing: hung_task: blocked tasks
For padata_do_parallel, when the return err is 0 or -EBUSY, it will call wait_for_completion(&wait->completion) in test_aead_vec_cfg. In normal case, aead_request_complete() will be called in pcrypt_aead_serial and the return err is 0 for padata_do_parallel. But, when pinst->flags is PADATA_RESET, the return err is -EBUSY for padata_do_parallel, and it won't call aead_request_complete(). Therefore, test_aead_vec_cfg will hung at wait_for_completion(&wait->completion), which will cause hungtask.
The problem comes as following: (padata_do_parallel) | rcu_read_lock_bh(); | err = -EINVAL; | (padata_replace) | pinst->flags |= PADATA_RESET; err = -EBUSY | if (pinst->flags & PADATA_RESET) | rcu_read_unlock_bh() | return err
In order to resolve the problem, we replace the return err -EBUSY with -EAGAIN, which means parallel_data is changing, and the caller should call it again.
v3: remove retry and just change the return err. v2: introduce padata_try_do_parallel() in pcrypt_aead_encrypt and pcrypt_aead_decrypt to solve the hungtask.(CVE-2023-52813)
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Fix a null pointer access when the smc_rreg pointer is NULL
In certain types of chips, such as VEGA20, reading the amdgpu_regs_smc file could result in an abnormal null pointer access when the smc_rreg pointer is NULL. Below are the steps to reproduce this issue and the corresponding exception log:
- Navigate to the directory: /sys/kernel/debug/dri/0
- Execute command: cat amdgpu_regs_smc
- Exception Log:: [4005007.702554] BUG: kernel NULL pointer dereference, address: 0000000000000000 [4005007.702562] #PF: supervisor instruction fetch in kernel mode [4005007.702567] #PF: error_code(0x0010) - not-present page [4005007.702570] PGD 0 P4D 0 [4005007.702576] Oops: 0010 [#1] SMP NOPTI [4005007.702581] CPU: 4 PID: 62563 Comm: cat Tainted: G OE 5.15.0-43-generic #46-Ubunt u [4005007.702590] RIP: 0010:0x0 [4005007.702598] Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6. [4005007.702600] RSP: 0018:ffffa82b46d27da0 EFLAGS: 00010206 [4005007.702605] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffa82b46d27e68 [4005007.702609] RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff9940656e0000 [4005007.702612] RBP: ffffa82b46d27dd8 R08: 0000000000000000 R09: ffff994060c07980 [4005007.702615] R10: 0000000000020000 R11: 0000000000000000 R12: 00007f5e06753000 [4005007.702618] R13: ffff9940656e0000 R14: ffffa82b46d27e68 R15: 00007f5e06753000 [4005007.702622] FS: 00007f5e0755b740(0000) GS:ffff99479d300000(0000) knlGS:0000000000000000 [4005007.702626] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [4005007.702629] CR2: ffffffffffffffd6 CR3: 00000003253fc000 CR4: 00000000003506e0 [4005007.702633] Call Trace: [4005007.702636] <TASK> [4005007.702640] amdgpu_debugfs_regs_smc_read+0xb0/0x120 [amdgpu] [4005007.703002] full_proxy_read+0x5c/0x80 [4005007.703011] vfs_read+0x9f/0x1a0 [4005007.703019] ksys_read+0x67/0xe0 [4005007.703023] __x64_sys_read+0x19/0x20 [4005007.703028] do_syscall_64+0x5c/0xc0 [4005007.703034] ? do_user_addr_fault+0x1e3/0x670 [4005007.703040] ? exit_to_user_mode_prepare+0x37/0xb0 [4005007.703047] ? irqentry_exit_to_user_mode+0x9/0x20 [4005007.703052] ? irqentry_exit+0x19/0x30 [4005007.703057] ? exc_page_fault+0x89/0x160 [4005007.703062] ? asm_exc_page_fault+0x8/0x30 [4005007.703068] entry_SYSCALL_64_after_hwframe+0x44/0xae [4005007.703075] RIP: 0033:0x7f5e07672992 [4005007.703079] Code: c0 e9 b2 fe ff ff 50 48 8d 3d fa b2 0c 00 e8 c5 1d 02 00 0f 1f 44 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 0f 05 <48> 3d 00 f0 ff ff 77 56 c3 0f 1f 44 00 00 48 83 e c 28 48 89 54 24 [4005007.703083] RSP: 002b:00007ffe03097898 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 [4005007.703088] RAX: ffffffffffffffda RBX: 0000000000020000 RCX: 00007f5e07672992 [4005007.703091] RDX: 0000000000020000 RSI: 00007f5e06753000 RDI: 0000000000000003 [4005007.703094] RBP: 00007f5e06753000 R08: 00007f5e06752010 R09: 00007f5e06752010 [4005007.703096] R10: 0000000000000022 R11: 0000000000000246 R12: 0000000000022000 [4005007.703099] R13: 0000000000000003 R14: 0000000000020000 R15: 0000000000020000 [4005007.703105] </TASK> [4005007.703107] Modules linked in: nf_tables libcrc32c nfnetlink algif_hash af_alg binfmt_misc nls_ iso8859_1 ipmi_ssif ast intel_rapl_msr intel_rapl_common drm_vram_helper drm_ttm_helper amd64_edac t tm edac_mce_amd kvm_amd ccp mac_hid k10temp kvm acpi_ipmi ipmi_si rapl sch_fq_codel ipmi_devintf ipm i_msghandler msr parport_pc ppdev lp parport mtd pstore_blk efi_pstore ramoops pstore_zone reed_solo mon ip_tables x_tables autofs4 ib_uverbs ib_core amdgpu(OE) amddrm_ttm_helper(OE) amdttm(OE) iommu_v 2 amd_sched(OE) amdkcl(OE) drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops cec rc_core drm igb ahci xhci_pci libahci i2c_piix4 i2c_algo_bit xhci_pci_renesas dca [4005007.703184] CR2: 0000000000000000 [4005007.703188] ---[ en ---truncated---(CVE-2023-52817)
In the Linux kernel, the following vulnerability has been resolved:
perf/core: Bail out early if the request AUX area is out of bound
When perf-record with a large AUX area, e.g 4GB, it fails with:
#perf record -C 0 -m ,4G -e arm_spe_0// -- sleep 1
failed to mmap with 12 (Cannot allocate memory)
and it reveals a WARNING with __alloc_pages():
------------[ cut here ]------------
WARNING: CPU: 44 PID: 17573 at mm/page_alloc.c:5568 __alloc_pages+0x1ec/0x248
Call trace:
__alloc_pages+0x1ec/0x248
__kmalloc_large_node+0xc0/0x1f8
__kmalloc_node+0x134/0x1e8
rb_alloc_aux+0xe0/0x298
perf_mmap+0x440/0x660
mmap_region+0x308/0x8a8
do_mmap+0x3c0/0x528
vm_mmap_pgoff+0xf4/0x1b8
ksys_mmap_pgoff+0x18c/0x218
__arm64_sys_mmap+0x38/0x58
invoke_syscall+0x50/0x128
el0_svc_common.constprop.0+0x58/0x188
do_el0_svc+0x34/0x50
el0_svc+0x34/0x108
el0t_64_sync_handler+0xb8/0xc0
el0t_64_sync+0x1a4/0x1a8
'rb->aux_pages' allocated by kcalloc() is a pointer array which is used to maintains AUX trace pages. The allocated page for this array is physically contiguous (and virtually contiguous) with an order of 0..MAX_ORDER. If the size of pointer array crosses the limitation set by MAX_ORDER, it reveals a WARNING.
So bail out early with -ENOMEM if the request AUX area is out of bound, e.g.:
#perf record -C 0 -m ,4G -e arm_spe_0// -- sleep 1
failed to mmap with 12 (Cannot allocate memory)(CVE-2023-52835)
In the Linux kernel, the following vulnerability has been resolved:
nbd: fix uaf in nbd_open
Commit 4af5f2e03013 ("nbd: use blk_mq_alloc_disk and blk_cleanup_disk") cleans up disk by blk_cleanup_disk() and it won't set disk->private_data as NULL as before. UAF may be triggered in nbd_open() if someone tries to open nbd device right after nbd_put() since nbd has been free in nbd_dev_remove().
Fix this by implementing ->free_disk and free private data in it.(CVE-2023-52837)
In the Linux kernel, the following vulnerability has been resolved:
Input: synaptics-rmi4 - fix use after free in rmi_unregister_function()
The put_device() calls rmi_release_function() which frees "fn" so the dereference on the next line "fn->num_of_irqs" is a use after free. Move the put_device() to the end to fix this.(CVE-2023-52840)
In the Linux kernel, the following vulnerability has been resolved:
media: vidtv: psi: Add check for kstrdup
Add check for the return value of kstrdup() and return the error if it fails in order to avoid NULL pointer dereference.(CVE-2023-52844)
In the Linux kernel, the following vulnerability has been resolved:
media: bttv: fix use after free error due to btv->timeout timer
There may be some a race condition between timer function bttv_irq_timeout and bttv_remove. The timer is setup in probe and there is no timer_delete operation in remove function. When it hit kfree btv, the function might still be invoked, which will cause use after free bug.
This bug is found by static analysis, it may be false positive.
Fix it by adding del_timer_sync invoking to the remove function.
cpu0 cpu1 bttv_probe ->timer_setup ->bttv_set_dma ->mod_timer; bttv_remove ->kfree(btv); ->bttv_irq_timeout ->USE btv(CVE-2023-52847)
In the Linux kernel, the following vulnerability has been resolved:
padata: Fix refcnt handling in padata_free_shell()
In a high-load arm64 environment, the pcrypt_aead01 test in LTP can lead to system UAF (Use-After-Free) issues. Due to the lengthy analysis of the pcrypt_aead01 function call, I'll describe the problem scenario using a simplified model:
Suppose there's a user of padata named user_function that adheres to
the padata requirement of calling padata_free_shell after serial()
has been invoked, as demonstrated in the following code:
struct request {
struct padata_priv padata;
struct completion *done;
};
void parallel(struct padata_priv *padata) {
do_something();
}
void serial(struct padata_priv *padata) {
struct request *request = container_of(padata,
struct request,
padata);
complete(request->done);
}
void user_function() {
DECLARE_COMPLETION(done)
padata->parallel = parallel;
padata->serial = serial;
padata_do_parallel();
wait_for_completion(&done);
padata_free_shell();
}
In the corresponding padata.c file, there's the following code:
static void padata_serial_worker(struct work_struct *serial_work) {
...
cnt = 0;
while (!list_empty(&local_list)) {
...
padata->serial(padata);
cnt++;
}
local_bh_enable();
if (refcount_sub_and_test(cnt, &pd->refcnt))
padata_free_pd(pd);
}
Because of the high system load and the accumulation of unexecuted
softirq at this moment, local_bh_enable() in padata takes longer
to execute than usual. Subsequently, when accessing pd->refcnt,
pd has already been released by padata_free_shell(), resulting
in a UAF issue with pd->refcnt.
The fix is straightforward: add refcount_dec_and_test before calling
padata_free_pd in padata_free_shell.(CVE-2023-52854)
In the Linux kernel, the following vulnerability has been resolved:
drivers/perf: hisi: use cpuhp_state_remove_instance_nocalls() for hisi_hns3_pmu uninit process
When tearing down a 'hisi_hns3' PMU, we mistakenly run the CPU hotplug callbacks after the device has been unregistered, leading to fireworks when we try to execute empty function callbacks within the driver:
| Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 | CPU: 0 PID: 15 Comm: cpuhp/0 Tainted: G W O 5.12.0-rc4+ #1 | Hardware name: , BIOS KpxxxFPGA 1P B600 V143 04/22/2021 | pstate: 80400009 (Nzcv daif +PAN -UAO -TCO BTYPE=--) | pc : perf_pmu_migrate_context+0x98/0x38c | lr : perf_pmu_migrate_context+0x94/0x38c | | Call trace: | perf_pmu_migrate_context+0x98/0x38c | hisi_hns3_pmu_offline_cpu+0x104/0x12c [hisi_hns3_pmu]
Use cpuhp_state_remove_instance_nocalls() instead of cpuhp_state_remove_instance() so that the notifiers don't execute after the PMU device has been unregistered.
In the Linux kernel, the following vulnerability has been resolved:
hwmon: (axi-fan-control) Fix possible NULL pointer dereference
axi_fan_control_irq_handler(), dependent on the private axi_fan_control_data structure, might be called before the hwmon device is registered. That will cause an "Unable to handle kernel NULL pointer dereference" error.(CVE-2023-52863)
In the Linux kernel, the following vulnerability has been resolved:
drm/radeon: possible buffer overflow
Buffer 'afmt_status' of size 6 could overflow, since index 'afmt_idx' is checked after access.(CVE-2023-52867)
In the Linux kernel, the following vulnerability has been resolved:
pstore/platform: Add check for kstrdup
Add check for the return value of kstrdup() and return the error if it fails in order to avoid NULL pointer dereference.(CVE-2023-52869)
In the Linux kernel, the following vulnerability has been resolved:
clk: mediatek: clk-mt7629-eth: 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-52876)
In the Linux kernel, the following vulnerability has been resolved:
tracing: Have trace_event_file have ref counters
The following can crash the kernel:
# cd /sys/kernel/tracing # echo 'p:sched schedule' > kprobe_events # exec 5>>events/kprobes/sched/enable # > kprobe_events # exec 5>&-
The above commands:
- Change directory to the tracefs directory
- Create a kprobe event (doesn't matter what one)
- Open bash file descriptor 5 on the enable file of the kprobe event
- Delete the kprobe event (removes the files too)
- Close the bash file descriptor 5
The above causes a crash!
BUG: kernel NULL pointer dereference, address: 0000000000000028 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 6 PID: 877 Comm: bash Not tainted 6.5.0-rc4-test-00008-g2c6b6b1029d4-dirty #186 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 RIP: 0010:tracing_release_file_tr+0xc/0x50
What happens here is that the kprobe event creates a trace_event_file "file" descriptor that represents the file in tracefs to the event. It maintains state of the event (is it enabled for the given instance?). Opening the "enable" file gets a reference to the event "file" descriptor via the open file descriptor. When the kprobe event is deleted, the file is also deleted from the tracefs system which also frees the event "file" descriptor.
But as the tracefs file is still opened by user space, it will not be totally removed until the final dput() is called on it. But this is not true with the event "file" descriptor that is already freed. If the user does a write to or simply closes the file descriptor it will reference the event "file" descriptor that was just freed, causing a use-after-free bug.
To solve this, add a ref count to the event "file" descriptor as well as a new flag called "FREED". The "file" will not be freed until the last reference is released. But the FREE flag will be set when the event is removed to prevent any more modifications to that event from happening, even if there's still a reference to the event "file" descriptor.(CVE-2023-52879)
In the Linux kernel, the following vulnerability has been resolved:
vfio/fsl-mc: Block calling interrupt handler without trigger
The eventfd_ctx trigger pointer of the vfio_fsl_mc_irq object is initially NULL and may become NULL if the user sets the trigger eventfd to -1. The interrupt handler itself is guaranteed that trigger is always valid between request_irq() and free_irq(), but the loopback testing mechanisms to invoke the handler function need to test the trigger. The triggering and setting ioctl paths both make use of igate and are therefore mutually exclusive.
The vfio-fsl-mc driver does not make use of irqfds, nor does it support any sort of masking operations, therefore unlike vfio-pci and vfio-platform, the flow can remain essentially unchanged.(CVE-2024-26814)
In the Linux kernel, the following vulnerability has been resolved:
af_unix: Fix garbage collector racing against connect()
Garbage collector does not take into account the risk of embryo getting enqueued during the garbage collection. If such embryo has a peer that carries SCM_RIGHTS, two consecutive passes of scan_children() may see a different set of children. Leading to an incorrectly elevated inflight count, and then a dangling pointer within the gc_inflight_list.
sockets are AF_UNIX/SOCK_STREAM S is an unconnected socket L is a listening in-flight socket bound to addr, not in fdtable V's fd will be passed via sendmsg(), gets inflight count bumped
connect(S, addr) sendmsg(S, [V]); close(V) __unix_gc() ---------------- ------------------------- -----------
NS = unix_create1() skb1 = sock_wmalloc(NS) L = unix_find_other(addr) unix_state_lock(L) unix_peer(S) = NS // V count=1 inflight=0
NS = unix_peer(S)
skb2 = sock_alloc()
skb_queue_tail(NS, skb2[V])
// V became in-flight
// V count=2 inflight=1
close(V)
// V count=1 inflight=1
// GC candidate condition met
for u in gc_inflight_list:
if (total_refs == inflight_refs)
add u to gc_candidates
// gc_candidates={L, V}
for u in gc_candidates:
scan_children(u, dec_inflight)
// embryo (skb1) was not
// reachable from L yet, so V's
// inflight remains unchanged
__skb_queue_tail(L, skb1) unix_state_unlock(L) for u in gc_candidates: if (u.inflight) scan_children(u, inc_inflight_move_tail)
// V count=1 inflight=2 (!)
If there is a GC-candidate listening socket, lock/unlock its state. This makes GC wait until the end of any ongoing connect() to that socket. After flipping the lock, a possibly SCM-laden embryo is already enqueued. And if there is another embryo coming, it can not possibly carry SCM_RIGHTS. At this point, unix_inflight() can not happen because unix_gc_lock is already taken. Inflight graph remains unaffected.(CVE-2024-26923)
In the Linux kernel, the following vulnerability has been resolved:
wireguard: netlink: access device through ctx instead of peer
The previous commit fixed a bug that led to a NULL peer->device being dereferenced. It's actually easier and faster performance-wise to instead get the device from ctx->wg. This semantically makes more sense too, since ctx->wg->peer_allowedips.seq is compared with ctx->allowedips_seq, basing them both in ctx. This also acts as a defence in depth provision against freed peers.(CVE-2024-26950)
In the Linux kernel, the following vulnerability has been resolved:
nfs: fix UAF in direct writes
In production we have been hitting the following warning consistently
------------[ cut here ]------------ refcount_t: underflow; use-after-free. WARNING: CPU: 17 PID: 1800359 at lib/refcount.c:28 refcount_warn_saturate+0x9c/0xe0 Workqueue: nfsiod nfs_direct_write_schedule_work [nfs] RIP: 0010:refcount_warn_saturate+0x9c/0xe0 PKRU: 55555554 Call Trace: <TASK> ? __warn+0x9f/0x130 ? refcount_warn_saturate+0x9c/0xe0 ? report_bug+0xcc/0x150 ? handle_bug+0x3d/0x70 ? exc_invalid_op+0x16/0x40 ? asm_exc_invalid_op+0x16/0x20 ? refcount_warn_saturate+0x9c/0xe0 nfs_direct_write_schedule_work+0x237/0x250 [nfs] process_one_work+0x12f/0x4a0 worker_thread+0x14e/0x3b0 ? ZSTD_getCParams_internal+0x220/0x220 kthread+0xdc/0x120 ? __btf_name_valid+0xa0/0xa0 ret_from_fork+0x1f/0x30
This is because we're completing the nfs_direct_request twice in a row.
The source of this is when we have our commit requests to submit, we process them and send them off, and then in the completion path for the commit requests we have
if (nfs_commit_end(cinfo.mds)) nfs_direct_write_complete(dreq);
However since we're submitting asynchronous requests we sometimes have one that completes before we submit the next one, so we end up calling complete on the nfs_direct_request twice.
The only other place we use nfs_generic_commit_list() is in __nfs_commit_inode, which wraps this call in a
nfs_commit_begin(); nfs_commit_end();
Which is a common pattern for this style of completion handling, one that is also repeated in the direct code with get_dreq()/put_dreq() calls around where we process events as well as in the completion paths.
Fix this by using the same pattern for the commit requests.
Before with my 200 node rocksdb stress running this warning would pop every 10ish minutes. With my patch the stress test has been running for several hours without popping.(CVE-2024-26958)
In the Linux kernel, the following vulnerability has been resolved:
mac802154: fix llsec key resources release in mac802154_llsec_key_del
mac802154_llsec_key_del() can free resources of a key directly without following the RCU rules for waiting before the end of a grace period. This may lead to use-after-free in case llsec_lookup_key() is traversing the list of keys in parallel with a key deletion:
refcount_t: addition on 0; use-after-free. WARNING: CPU: 4 PID: 16000 at lib/refcount.c:25 refcount_warn_saturate+0x162/0x2a0 Modules linked in: CPU: 4 PID: 16000 Comm: wpan-ping Not tainted 6.7.0 #19 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 RIP: 0010:refcount_warn_saturate+0x162/0x2a0 Call Trace: <TASK> llsec_lookup_key.isra.0+0x890/0x9e0 mac802154_llsec_encrypt+0x30c/0x9c0 ieee802154_subif_start_xmit+0x24/0x1e0 dev_hard_start_xmit+0x13e/0x690 sch_direct_xmit+0x2ae/0xbc0 __dev_queue_xmit+0x11dd/0x3c20 dgram_sendmsg+0x90b/0xd60 __sys_sendto+0x466/0x4c0 __x64_sys_sendto+0xe0/0x1c0 do_syscall_64+0x45/0xf0 entry_SYSCALL_64_after_hwframe+0x6e/0x76
Also, ieee802154_llsec_key_entry structures are not freed by mac802154_llsec_key_del():
unreferenced object 0xffff8880613b6980 (size 64): comm "iwpan", pid 2176, jiffies 4294761134 (age 60.475s) hex dump (first 32 bytes): 78 0d 8f 18 80 88 ff ff 22 01 00 00 00 00 ad de x......."....... 00 00 00 00 00 00 00 00 03 00 cd ab 00 00 00 00 ................ backtrace: [<ffffffff81dcfa62>] __kmem_cache_alloc_node+0x1e2/0x2d0 [<ffffffff81c43865>] kmalloc_trace+0x25/0xc0 [<ffffffff88968b09>] mac802154_llsec_key_add+0xac9/0xcf0 [<ffffffff8896e41a>] ieee802154_add_llsec_key+0x5a/0x80 [<ffffffff8892adc6>] nl802154_add_llsec_key+0x426/0x5b0 [<ffffffff86ff293e>] genl_family_rcv_msg_doit+0x1fe/0x2f0 [<ffffffff86ff46d1>] genl_rcv_msg+0x531/0x7d0 [<ffffffff86fee7a9>] netlink_rcv_skb+0x169/0x440 [<ffffffff86ff1d88>] genl_rcv+0x28/0x40 [<ffffffff86fec15c>] netlink_unicast+0x53c/0x820 [<ffffffff86fecd8b>] netlink_sendmsg+0x93b/0xe60 [<ffffffff86b91b35>] _syssendmsg+0xac5/0xca0 [<ffffffff86b9c3dd>] _sys_sendmsg+0x11d/0x1c0 [<ffffffff86b9c65a>] __sys_sendmsg+0xfa/0x1d0 [<ffffffff88eadbf5>] do_syscall_64+0x45/0xf0 [<ffffffff890000ea>] entry_SYSCALL_64_after_hwframe+0x6e/0x76
Handle the proper resource release in the RCU callback function mac802154_llsec_key_del_rcu().
Note that if llsec_lookup_key() finds a key, it gets a refcount via llsec_key_get() and locally copies key id from key_entry (which is a list element). So it's safe to call llsec_key_put() and free the list entry after the RCU grace period elapses.
Found by Linux Verification Center (linuxtesting.org).(CVE-2024-26961)
In the Linux kernel, the following vulnerability has been resolved:
clk: qcom: mmcc-msm8974: fix terminating of frequency table arrays
The frequency table arrays are supposed to be terminated with an empty element. Add such entry to the end of the arrays where it is missing in order to avoid possible out-of-bound access when the table is traversed by functions like qcom_find_freq() or qcom_find_freq_floor().
Only compile tested.(CVE-2024-26965)
In the Linux kernel, the following vulnerability has been resolved:
ubifs: ubifs_symlink: Fix memleak of inode->i_link in error path
For error handling path in ubifs_symlink(), inode will be marked as bad first, then iput() is invoked. If inode->i_link is initialized by fscrypt_encrypt_symlink() in encryption scenario, inode->i_link won't be freed by callchain ubifs_free_inode -> fscrypt_free_inode in error handling path, because make_bad_inode() has changed 'inode->i_mode' as 'S_IFREG'. Following kmemleak is easy to be reproduced by injecting error in ubifs_jnl_update() when doing symlink in encryption scenario: unreferenced object 0xffff888103da3d98 (size 8): comm "ln", pid 1692, jiffies 4294914701 (age 12.045s) backtrace: kmemdup+0x32/0x70 __fscrypt_encrypt_symlink+0xed/0x1c0 ubifs_symlink+0x210/0x300 [ubifs] vfs_symlink+0x216/0x360 do_symlinkat+0x11a/0x190 do_syscall_64+0x3b/0xe0 There are two ways fixing it: 1. Remove make_bad_inode() in error handling path. We can do that because ubifs_evict_inode() will do same processes for good symlink inode and bad symlink inode, for inode->i_nlink checking is before is_bad_inode(). 2. Free inode->i_link before marking inode bad. Method 2 is picked, it has less influence, personally, I think.(CVE-2024-26972)
In the Linux kernel, the following vulnerability has been resolved:
KVM: Always flush async #PF workqueue when vCPU is being destroyed
Always flush the per-vCPU async #PF workqueue when a vCPU is clearing its completion queue, e.g. when a VM and all its vCPUs is being destroyed. KVM must ensure that none of its workqueue callbacks is running when the last reference to the KVM module is put. Gifting a reference to the associated VM prevents the workqueue callback from dereferencing freed vCPU/VM memory, but does not prevent the KVM module from being unloaded before the callback completes.
Drop the misguided VM refcount gifting, as calling kvm_put_kvm() from async_pf_execute() if kvm_put_kvm() flushes the async #PF workqueue will result in deadlock. async_pf_execute() can't return until kvm_put_kvm() finishes, and kvm_put_kvm() can't return until async_pf_execute() finishes:
WARNING: CPU: 8 PID: 251 at virt/kvm/kvm_main.c:1435 kvm_put_kvm+0x2d/0x320 [kvm] Modules linked in: vhost_net vhost vhost_iotlb tap kvm_intel kvm irqbypass CPU: 8 PID: 251 Comm: kworker/8:1 Tainted: G W 6.6.0-rc1-e7af8d17224a-x86/gmem-vm #119 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Workqueue: events async_pf_execute [kvm] RIP: 0010:kvm_put_kvm+0x2d/0x320 [kvm] Call Trace: <TASK> async_pf_execute+0x198/0x260 [kvm] process_one_work+0x145/0x2d0 worker_thread+0x27e/0x3a0 kthread+0xba/0xe0 ret_from_fork+0x2d/0x50 ret_from_fork_asm+0x11/0x20 </TASK> ---[ end trace 0000000000000000 ]--- INFO: task kworker/8:1:251 blocked for more than 120 seconds. Tainted: G W 6.6.0-rc1-e7af8d17224a-x86/gmem-vm #119 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/8:1 state:D stack:0 pid:251 ppid:2 flags:0x00004000 Workqueue: events async_pf_execute [kvm] Call Trace: <TASK> __schedule+0x33f/0xa40 schedule+0x53/0xc0 schedule_timeout+0x12a/0x140 __wait_for_common+0x8d/0x1d0 __flush_work.isra.0+0x19f/0x2c0 kvm_clear_async_pf_completion_queue+0x129/0x190 [kvm] kvm_arch_destroy_vm+0x78/0x1b0 [kvm] kvm_put_kvm+0x1c1/0x320 [kvm] async_pf_execute+0x198/0x260 [kvm] process_one_work+0x145/0x2d0 worker_thread+0x27e/0x3a0 kthread+0xba/0xe0 ret_from_fork+0x2d/0x50 ret_from_fork_asm+0x11/0x20 </TASK>
If kvm_clear_async_pf_completion_queue() actually flushes the workqueue, then there's no need to gift async_pf_execute() a reference because all invocations of async_pf_execute() will be forced to complete before the vCPU and its VM are destroyed/freed. And that in turn fixes the module unloading bug as __fput() won't do module_put() on the last vCPU reference until the vCPU has been freed, e.g. if closing the vCPU file also puts the last reference to the KVM module.
Note that kvm_check_async_pf_completion() may also take the work item off the completion queue and so also needs to flush the work queue, as the work will not be seen by kvm_clear_async_pf_completion_queue(). Waiting on the workqueue could theoretically delay a vCPU due to waiting for the work to complete, but that's a very, very small chance, and likely a very small delay. kvm_arch_async_page_present_queued() unconditionally makes a new request, i.e. will effectively delay entering the guest, so the remaining work is really just:
trace_kvm_async_pf_completed(addr, cr2_or_gpa);
__kvm_vcpu_wake_up(vcpu);
mmput(mm);
and mmput() can't drop the last reference to the page tables if the vCPU is still alive, i.e. the vCPU won't get stuck tearing down page tables.
Add a helper to do the flushing, specifically to deal with "wakeup all" work items, as they aren't actually work items, i.e. are never placed in a workqueue. Trying to flush a bogus workqueue entry rightly makes __flush_work() complain (kudos to whoever added that sanity check).
Note, commit 5f6de5cbebee ("KVM: Prevent module exit until al ---truncated---(CVE-2024-26976)
In the Linux kernel, the following vulnerability has been resolved:
Squashfs: check the inode number is not the invalid value of zero
Syskiller has produced an out of bounds access in fill_meta_index().
That out of bounds access is ultimately caused because the inode has an inode number with the invalid value of zero, which was not checked.
The reason this causes the out of bounds access is due to following sequence of events:
-
Fill_meta_index() is called to allocate (via empty_meta_index()) and fill a metadata index. It however suffers a data read error and aborts, invalidating the newly returned empty metadata index. It does this by setting the inode number of the index to zero, which means unused (zero is not a valid inode number).
-
When fill_meta_index() is subsequently called again on another read operation, locate_meta_index() returns the previous index because it matches the inode number of 0. Because this index has been returned it is expected to have been filled, and because it hasn't been, an out of bounds access is performed.
This patch adds a sanity check which checks that the inode number is not zero when the inode is created and returns -EINVAL if it is.
[phillip@squashfs.org.uk: whitespace fix] Link: https://lkml.kernel.org/r/20240409204723.446925-1-phillip@squashfs.org.uk(CVE-2024-26982)
In the Linux kernel, the following vulnerability has been resolved:
fs: sysfs: Fix reference leak in sysfs_break_active_protection()
The sysfs_break_active_protection() routine has an obvious reference leak in its error path. If the call to kernfs_find_and_get() fails then kn will be NULL, so the companion sysfs_unbreak_active_protection() routine won't get called (and would only cause an access violation by trying to dereference kn->parent if it was called). As a result, the reference to kobj acquired at the start of the function will never be released.
Fix the leak by adding an explicit kobject_put() call when kn is NULL.(CVE-2024-26993)
In the Linux kernel, the following vulnerability has been resolved:
serial: mxs-auart: add spinlock around changing cts state
The uart_handle_cts_change() function in serial_core expects the caller to hold uport->lock. For example, I have seen the below kernel splat, when the Bluetooth driver is loaded on an i.MX28 board.
[ 85.119255] ------------[ cut here ]------------
[ 85.124413] WARNING: CPU: 0 PID: 27 at /drivers/tty/serial/serial_core.c:3453 uart_handle_cts_change+0xb4/0xec
[ 85.134694] Modules linked in: hci_uart bluetooth ecdh_generic ecc wlcore_sdio configfs
[ 85.143314] CPU: 0 PID: 27 Comm: kworker/u3:0 Not tainted 6.6.3-00021-gd62a2f068f92 #1
[ 85.151396] Hardware name: Freescale MXS (Device Tree)
[ 85.156679] Workqueue: hci0 hci_power_on [bluetooth]
(...)
[ 85.191765] uart_handle_cts_change from mxs_auart_irq_handle+0x380/0x3f4
[ 85.198787] mxs_auart_irq_handle from __handle_irq_event_percpu+0x88/0x210
(...)(CVE-2024-27000)
In the Linux kernel, the following vulnerability has been resolved:
drm: nv04: Fix out of bounds access
When Output Resource (dcb->or) value is assigned in fabricate_dcb_output(), there may be out of bounds access to dac_users array in case dcb->or is zero because ffs(dcb->or) is used as index there. The 'or' argument of fabricate_dcb_output() must be interpreted as a number of bit to set, not value.
Utilize macros from 'enum nouveau_or' in calls instead of hardcoding.
Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-27008)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix a potential buffer overflow in 'dp_dsc_clock_en_read()'
Tell snprintf() to store at most 10 bytes in the output buffer instead of 30.
Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_debugfs.c:1508 dp_dsc_clock_en_read() error: snprintf() is printing too much 30 vs 10(CVE-2024-27045)
In the Linux kernel, the following vulnerability has been resolved:
USB: usb-storage: Prevent divide-by-0 error in isd200_ata_command
The isd200 sub-driver in usb-storage uses the HEADS and SECTORS values in the ATA ID information to calculate cylinder and head values when creating a CDB for READ or WRITE commands. The calculation involves division and modulus operations, which will cause a crash if either of these values is 0. While this never happens with a genuine device, it could happen with a flawed or subversive emulation, as reported by the syzbot fuzzer.
Protect against this possibility by refusing to bind to the device if either the ATA_ID_HEADS or ATA_ID_SECTORS value in the device's ID information is 0. This requires isd200_Initialization() to return a negative error code when initialization fails; currently it always returns 0 (even when there is an error).(CVE-2024-27059)
In the Linux kernel, the following vulnerability has been resolved:
media: usbtv: Remove useless locks in usbtv_video_free()
Remove locks calls in usbtv_video_free() because are useless and may led to a deadlock as reported here: https://syzkaller.appspot.com/x/bisect.txt?x=166dc872180000 Also remove usbtv_stop() call since it will be called when unregistering the device.
Before 'c838530d230b' this issue would only be noticed if you disconnect while streaming and now it is noticeable even when disconnecting while not streaming.
hverkuil: fix minor spelling mistake in log message
In the Linux kernel, the following vulnerability has been resolved:
media: ttpci: fix two memleaks in budget_av_attach
When saa7146_register_device and saa7146_vv_init fails, budget_av_attach should free the resources it allocates, like the error-handling of ttpci_budget_init does. Besides, there are two fixme comment refers to such deallocations.(CVE-2024-27073)
In the Linux kernel, the following vulnerability has been resolved:
media: dvb-frontends: avoid stack overflow warnings with clang
A previous patch worked around a KASAN issue in stv0367, now a similar problem showed up with clang:
drivers/media/dvb-frontends/stv0367.c:1222:12: error: stack frame size (3624) exceeds limit (2048) in 'stv0367ter_set_frontend' [-Werror,-Wframe-larger-than] 1214 | static int stv0367ter_set_frontend(struct dvb_frontend *fe)
Rework the stv0367_writereg() function to be simpler and mark both register access functions as noinline_for_stack so the temporary i2c_msg structures do not get duplicated on the stack when KASAN_STACK is enabled.(CVE-2024-27075)
In the Linux kernel, the following vulnerability has been resolved:
pstore: inode: Only d_invalidate() is needed
Unloading a modular pstore backend with records in pstorefs would trigger the dput() double-drop warning:
WARNING: CPU: 0 PID: 2569 at fs/dcache.c:762 dput.part.0+0x3f3/0x410
Using the combo of d_drop()/dput() (as mentioned in Documentation/filesystems/vfs.rst) isn't the right approach here, and leads to the reference counting problem seen above. Use d_invalidate() and update the code to not bother checking for error codes that can never happen.
---(CVE-2024-27389)
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Fixed overflow check in mi_enum_attr()(CVE-2024-27407)
In the Linux kernel, the following vulnerability has been resolved:
netrom: Fix data-races around sysctl_net_busy_read
We need to protect the reader reading the sysctl value because the value can be changed concurrently.(CVE-2024-27419)
Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2024-27426)
Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2024-27427)
In the Linux kernel, the following vulnerability has been resolved:
KVM: SVM: Flush pages under kvm->lock to fix UAF in svm_register_enc_region()
Do the cache flush of converted pages in svm_register_enc_region() before dropping kvm->lock to fix use-after-free issues where region and/or its array of pages could be freed by a different task, e.g. if userspace has __unregister_enc_region_locked() already queued up for the region.
Note, the "obvious" alternative of using local variables doesn't fully resolve the bug, as region->pages is also dynamically allocated. I.e. the region structure itself would be fine, but region->pages could be freed.
Flushing multiple pages under kvm->lock is unfortunate, but the entire flow is a rare slow path, and the manual flush is only needed on CPUs that lack coherency for encrypted memory.(CVE-2024-35791)
In the Linux kernel, the following vulnerability has been resolved: x86/fpu: Keep xfd_state in sync with MSR_IA32_XFD Commit 672365477ae8 ("x86/fpu: Update XFD state where required") and commit 8bf26758ca96 ("x86/fpu: Add XFD state to fpstate") introduced a per CPU variable xfd_state to keep the MSR_IA32_XFD value cached, in order to avoid unnecessary writes to the MSR. On CPU hotplug MSR_IA32_XFD is reset to the init_fpstate.xfd, which wipes out any stale state. But the per CPU cached xfd value is not reset, which brings them out of sync. As a consequence a subsequent xfd_update_state() might fail to update the MSR which in turn can result in XRSTOR raising a #NM in kernel space, which crashes the kernel. To fix this, introduce xfd_set_state() to write xfd_state together with MSR_IA32_XFD, and use it in all places that set MSR_IA32_XFD.(CVE-2024-35801)
In the Linux kernel, the following vulnerability has been resolved:
dm snapshot: fix lockup in dm_exception_table_exit
There was reported lockup when we exit a snapshot with many exceptions. Fix this by adding "cond_resched" to the loop that frees the exceptions.(CVE-2024-35805)
In the Linux kernel, the following vulnerability has been resolved:
soc: fsl: qbman: Always disable interrupts when taking cgr_lock
smp_call_function_single disables IRQs when executing the callback. To prevent deadlocks, we must disable IRQs when taking cgr_lock elsewhere. This is already done by qman_update_cgr and qman_delete_cgr; fix the other lockers.(CVE-2024-35806)
In the Linux kernel, the following vulnerability has been resolved:
LoongArch: Define the __io_aw() hook as mmiowb()
Commit fb24ea52f78e0d595852e ("drivers: Remove explicit invocations of mmiowb()") remove all mmiowb() in drivers, but it says:
"NOTE: mmiowb() has only ever guaranteed ordering in conjunction with spin_unlock(). However, pairing each mmiowb() removal in this patch with the corresponding call to spin_unlock() is not at all trivial, so there is a small chance that this change may regress any drivers incorrectly relying on mmiowb() to order MMIO writes between CPUs using lock-free synchronisation."
The mmio in radeon_ring_commit() is protected by a mutex rather than a spinlock, but in the mutex fastpath it behaves similar to spinlock. We can add mmiowb() calls in the radeon driver but the maintainer says he doesn't like such a workaround, and radeon is not the only example of mutex protected mmio.
So we should extend the mmiowb tracking system from spinlock to mutex, and maybe other locking primitives. This is not easy and error prone, so we solve it in the architectural code, by simply defining the __io_aw() hook as mmiowb(). And we no longer need to override queued_spin_unlock() so use the generic definition.
Without this, we get such an error when run 'glxgears' on weak ordering architectures such as LoongArch:
radeon 0000:04:00.0: ring 0 stalled for more than 10324msec radeon 0000:04:00.0: ring 3 stalled for more than 10240msec radeon 0000:04:00.0: GPU lockup (current fence id 0x000000000001f412 last fence id 0x000000000001f414 on ring 3) radeon 0000:04:00.0: GPU lockup (current fence id 0x000000000000f940 last fence id 0x000000000000f941 on ring 0) radeon 0000:04:00.0: scheduling IB failed (-35). [drm:radeon_gem_va_ioctl [radeon]] ERROR Couldn't update BO_VA (-35) radeon 0000:04:00.0: scheduling IB failed (-35). [drm:radeon_gem_va_ioctl [radeon]] ERROR Couldn't update BO_VA (-35) radeon 0000:04:00.0: scheduling IB failed (-35). [drm:radeon_gem_va_ioctl [radeon]] ERROR Couldn't update BO_VA (-35) radeon 0000:04:00.0: scheduling IB failed (-35). [drm:radeon_gem_va_ioctl [radeon]] ERROR Couldn't update BO_VA (-35) radeon 0000:04:00.0: scheduling IB failed (-35). [drm:radeon_gem_va_ioctl [radeon]] ERROR Couldn't update BO_VA (-35) radeon 0000:04:00.0: scheduling IB failed (-35). [drm:radeon_gem_va_ioctl [radeon]] ERROR Couldn't update BO_VA (-35) radeon 0000:04:00.0: scheduling IB failed (-35). [drm:radeon_gem_va_ioctl [radeon]] ERROR Couldn't update BO_VA (-35)(CVE-2024-35818)
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: fix a double-free in arfs_create_groups
When in allocated by kvzalloc fails, arfs_create_groups will free
ft->g and return an error. However, arfs_create_table, the only caller of
arfs_create_groups, will hold this error and call to
mlx5e_destroy_flow_table, in which the ft->g will be freed again.(CVE-2024-35835)
In the Linux kernel, the following vulnerability has been resolved:
f2fs: compress: fix reserve_cblocks counting error when out of space
When a file only needs one direct_node, performing the following operations will cause the file to be unrepairable:
unisoc # ./f2fs_io compress test.apk unisoc #df -h | grep dm-48 /dev/block/dm-48 112G 112G 1.2M 100% /data
unisoc # ./f2fs_io release_cblocks test.apk 924 unisoc # df -h | grep dm-48 /dev/block/dm-48 112G 112G 4.8M 100% /data
unisoc # dd if=/dev/random of=file4 bs=1M count=3 3145728 bytes (3.0 M) copied, 0.025 s, 120 M/s unisoc # df -h | grep dm-48 /dev/block/dm-48 112G 112G 1.8M 100% /data
unisoc # ./f2fs_io reserve_cblocks test.apk F2FS_IOC_RESERVE_COMPRESS_BLOCKS failed: No space left on device
adb reboot unisoc # df -h | grep dm-48 /dev/block/dm-48 112G 112G 11M 100% /data unisoc # ./f2fs_io reserve_cblocks test.apk 0
This is because the file has only one direct_node. After returning to -ENOSPC, reserved_blocks += ret will not be executed. As a result, the reserved_blocks at this time is still 0, which is not the real number of reserved blocks. Therefore, fsck cannot be set to repair the file.
After this patch, the fsck flag will be set to fix this problem.
unisoc # df -h | grep dm-48 /dev/block/dm-48 112G 112G 1.8M 100% /data unisoc # ./f2fs_io reserve_cblocks test.apk F2FS_IOC_RESERVE_COMPRESS_BLOCKS failed: No space left on device
adb reboot then fsck will be executed unisoc # df -h | grep dm-48 /dev/block/dm-48 112G 112G 11M 100% /data unisoc # ./f2fs_io reserve_cblocks test.apk 924(CVE-2024-35844)
In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlwifi: dbg-tlv: ensure NUL termination
The iwl_fw_ini_debug_info_tlv is used as a string, so we must ensure the string is terminated correctly before using it.(CVE-2024-35845)
In the Linux kernel, the following vulnerability has been resolved:
eeprom: at24: fix memory corruption race condition
If the eeprom is not accessible, an nvmem device will be registered, the read will fail, and the device will be torn down. If another driver accesses the nvmem device after the teardown, it will reference invalid memory.
Move the failure point before registering the nvmem device.(CVE-2024-35848)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: Fix potential data-race in __nft_flowtable_type_get()
nft_unregister_flowtable_type() within nf_flow_inet_module_exit() can concurrent with __nft_flowtable_type_get() within nf_tables_newflowtable(). And thhere is not any protection when iterate over nf_tables_flowtables list in __nft_flowtable_type_get(). Therefore, there is pertential data-race of nf_tables_flowtables list entry.
Use list_for_each_entry_rcu() to iterate over nf_tables_flowtables list in __nft_flowtable_type_get(), and use rcu_read_lock() in the caller nft_flowtable_type_get() to protect the entire type query process.(CVE-2024-35898)
In the Linux kernel, the following vulnerability has been resolved:
fbmon: prevent division by zero in fb_videomode_from_videomode()
The expression htotal * vtotal can have a zero value on overflow. It is necessary to prevent division by zero like in fb_var_to_videomode().
Found by Linux Verification Center (linuxtesting.org) with Svace.(CVE-2024-35922)
In the Linux kernel, the following vulnerability has been resolved:
scsi: lpfc: Fix possible memory leak in lpfc_rcv_padisc()
The call to lpfc_sli4_resume_rpi() in lpfc_rcv_padisc() may return an unsuccessful status. In such cases, the elsiocb is not issued, the completion is not called, and thus the elsiocb resource is leaked.
Check return value after calling lpfc_sli4_resume_rpi() and conditionally release the elsiocb resource.(CVE-2024-35930)
In the Linux kernel, the following vulnerability has been resolved:
btrfs: handle chunk tree lookup error in btrfs_relocate_sys_chunks()
The unhandled case in btrfs_relocate_sys_chunks() loop is a corruption, as it could be caused only by two impossible conditions:
-
at first the search key is set up to look for a chunk tree item, with offset -1, this is an inexact search and the key->offset will contain the correct offset upon a successful search, a valid chunk tree item cannot have an offset -1
-
after first successful search, the found_key corresponds to a chunk item, the offset is decremented by 1 before the next loop, it's impossible to find a chunk item there due to alignment and size constraints(CVE-2024-35936)
In the Linux kernel, the following vulnerability has been resolved:
pstore/zone: Add a null pointer check to the psz_kmsg_read
kasprintf() returns a pointer to dynamically allocated memory which can be NULL upon failure. Ensure the allocation was successful by checking the pointer validity.(CVE-2024-35940)
In the Linux kernel, the following vulnerability has been resolved:
xsk: validate user input for XDP_{UMEM|COMPLETION}_FILL_RING
syzbot reported an illegal copy in xsk_setsockopt() [1]
Make sure to validate setsockopt() @optlen parameter.
[1]
BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline] BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline] BUG: KASAN: slab-out-of-bounds in xsk_setsockopt+0x909/0xa40 net/xdp/xsk.c:1420 Read of size 4 at addr ffff888028c6cde3 by task syz-executor.0/7549
CPU: 0 PID: 7549 Comm: syz-executor.0 Not tainted 6.8.0-syzkaller-08951-gfe46a7dd189e #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 copy_from_sockptr_offset include/linux/sockptr.h:49 [inline] copy_from_sockptr include/linux/sockptr.h:55 [inline] xsk_setsockopt+0x909/0xa40 net/xdp/xsk.c:1420 do_sock_setsockopt+0x3af/0x720 net/socket.c:2311 __sys_setsockopt+0x1ae/0x250 net/socket.c:2334 __do_sys_setsockopt net/socket.c:2343 [inline] __se_sys_setsockopt net/socket.c:2340 [inline] __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340 do_syscall_64+0xfb/0x240 entry_SYSCALL_64_after_hwframe+0x6d/0x75 RIP: 0033:0x7fb40587de69 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:00007fb40665a0c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000036 RAX: ffffffffffffffda RBX: 00007fb4059abf80 RCX: 00007fb40587de69 RDX: 0000000000000005 RSI: 000000000000011b RDI: 0000000000000006 RBP: 00007fb4058ca47a R08: 0000000000000002 R09: 0000000000000000 R10: 0000000020001980 R11: 0000000000000246 R12: 0000000000000000 R13: 000000000000000b R14: 00007fb4059abf80 R15: 00007fff57ee4d08 </TASK>
Allocated by task 7549: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:370 [inline] __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:387 kasan_kmalloc include/linux/kasan.h:211 [inline] __do_kmalloc_node mm/slub.c:3966 [inline] __kmalloc+0x233/0x4a0 mm/slub.c:3979 kmalloc include/linux/slab.h:632 [inline] __cgroup_bpf_run_filter_setsockopt+0xd2f/0x1040 kernel/bpf/cgroup.c:1869 do_sock_setsockopt+0x6b4/0x720 net/socket.c:2293 __sys_setsockopt+0x1ae/0x250 net/socket.c:2334 __do_sys_setsockopt net/socket.c:2343 [inline] __se_sys_setsockopt net/socket.c:2340 [inline] __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340 do_syscall_64+0xfb/0x240 entry_SYSCALL_64_after_hwframe+0x6d/0x75
The buggy address belongs to the object at ffff888028c6cde0 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 1 bytes to the right of allocated 2-byte region [ffff888028c6cde0, ffff888028c6cde2)
The buggy address belongs to the physical page: page:ffffea0000a31b00 refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888028c6c9c0 pfn:0x28c6c anon flags: 0xfff00000000800(slab|node=0|zone=1|lastcpupid=0x7ff) page_type: 0xffffffff() raw: 00fff00000000800 ffff888014c41280 0000000000000000 dead000000000001 raw: ffff888028c6c9c0 0000000080800057 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected page_owner tracks the page as allocated page last allocated via order 0, migratetype Unmovable, gfp_mask 0x112cc0(GFP_USER|__GFP_NOWARN|__GFP_NORETRY), pid 6648, tgid 6644 (syz-executor.0), ts 133906047828, free_ts 133859922223 set_page_owner include/linux/page_owner.h:31 [inline] post_alloc_hook+0x1ea/0x210 mm/page_alloc.c:1533 prep_new_page mm/page_alloc.c: ---truncated---(CVE-2024-35976)
In the Linux kernel, the following vulnerability has been resolved:
HID: i2c-hid: remove I2C_HID_READ_PENDING flag to prevent lock-up
The flag I2C_HID_READ_PENDING is used to serialize I2C operations. However, this is not necessary, because I2C core already has its own locking for that.
More importantly, this flag can cause a lock-up: if the flag is set in i2c_hid_xfer() and an interrupt happens, the interrupt handler (i2c_hid_irq) will check this flag and return immediately without doing anything, then the interrupt handler will be invoked again in an infinite loop.
Since interrupt handler is an RT task, it takes over the CPU and the flag-clearing task never gets scheduled, thus we have a lock-up.
Delete this unnecessary flag.(CVE-2024-35997)
In the Linux kernel, the following vulnerability has been resolved:
mlxsw: spectrum_acl_tcam: Fix incorrect list API usage
Both the function that migrates all the chunks within a region and the function that migrates all the entries within a chunk call list_first_entry() on the respective lists without checking that the lists are not empty. This is incorrect usage of the API, which leads to the following warning [1].
Fix by returning if the lists are empty as there is nothing to migrate in this case.
[1] WARNING: CPU: 0 PID: 6437 at drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c:1266 mlxsw_sp_acl_tcam_vchunk_migrate_all+0x1f1/0> Modules linked in: CPU: 0 PID: 6437 Comm: kworker/0:37 Not tainted 6.9.0-rc3-custom-00883-g94a65f079ef6 #39 Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019 Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work RIP: 0010:mlxsw_sp_acl_tcam_vchunk_migrate_all+0x1f1/0x2c0 [...] Call Trace: <TASK> mlxsw_sp_acl_tcam_vregion_rehash_work+0x6c/0x4a0 process_one_work+0x151/0x370 worker_thread+0x2cb/0x3e0 kthread+0xd0/0x100 ret_from_fork+0x34/0x50 ret_from_fork_asm+0x1a/0x30 </TASK>(CVE-2024-36006)
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"kernel-tools-debuginfo-5.10.0-136.77.0.157.oe2203sp1.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-136.77.0.157.oe2203sp1.aarch64.rpm",
"kernel-tools-devel-5.10.0-136.77.0.157.oe2203sp1.aarch64.rpm",
"perf-5.10.0-136.77.0.157.oe2203sp1.aarch64.rpm",
"kernel-headers-5.10.0-136.77.0.157.oe2203sp1.aarch64.rpm",
"kernel-5.10.0-136.77.0.157.oe2203sp1.aarch64.rpm",
"kernel-debuginfo-5.10.0-136.77.0.157.oe2203sp1.aarch64.rpm",
"kernel-devel-5.10.0-136.77.0.157.oe2203sp1.aarch64.rpm",
"python3-perf-5.10.0-136.77.0.157.oe2203sp1.aarch64.rpm",
"kernel-source-5.10.0-136.77.0.157.oe2203sp1.aarch64.rpm",
"perf-debuginfo-5.10.0-136.77.0.157.oe2203sp1.aarch64.rpm",
"kernel-debugsource-5.10.0-136.77.0.157.oe2203sp1.aarch64.rpm",
"kernel-tools-5.10.0-136.77.0.157.oe2203sp1.aarch64.rpm"
],
"src": [
"kernel-5.10.0-136.77.0.157.oe2203sp1.src.rpm"
],
"x86_64": [
"kernel-5.10.0-136.77.0.157.oe2203sp1.x86_64.rpm",
"kernel-source-5.10.0-136.77.0.157.oe2203sp1.x86_64.rpm",
"kernel-tools-5.10.0-136.77.0.157.oe2203sp1.x86_64.rpm",
"kernel-debuginfo-5.10.0-136.77.0.157.oe2203sp1.x86_64.rpm",
"kernel-headers-5.10.0-136.77.0.157.oe2203sp1.x86_64.rpm",
"perf-5.10.0-136.77.0.157.oe2203sp1.x86_64.rpm",
"python3-perf-debuginfo-5.10.0-136.77.0.157.oe2203sp1.x86_64.rpm",
"kernel-devel-5.10.0-136.77.0.157.oe2203sp1.x86_64.rpm",
"perf-debuginfo-5.10.0-136.77.0.157.oe2203sp1.x86_64.rpm",
"python3-perf-5.10.0-136.77.0.157.oe2203sp1.x86_64.rpm",
"kernel-tools-devel-5.10.0-136.77.0.157.oe2203sp1.x86_64.rpm",
"kernel-tools-debuginfo-5.10.0-136.77.0.157.oe2203sp1.x86_64.rpm",
"kernel-debugsource-5.10.0-136.77.0.157.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.77.0.157.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\ndrm/amdgpu: handle the case of pci_channel_io_frozen only in amdgpu_pci_resume\r\n\r\nIn current code, when a PCI error state pci_channel_io_normal is detectd,\nit will report PCI_ERS_RESULT_CAN_RECOVER status to PCI driver, and PCI\ndriver will continue the execution of PCI resume callback report_resume by\npci_walk_bridge, and the callback will go into amdgpu_pci_resume\nfinally, where write lock is releasd unconditionally without acquiring\nsuch lock first. In this case, a deadlock will happen when other threads\nstart to acquire the read lock.\r\n\r\nTo fix this, add a member in amdgpu_device strucutre to cache\npci_channel_state, and only continue the execution in amdgpu_pci_resume\nwhen it\u0026apos;s pci_channel_io_frozen.(CVE-2021-47421)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nptp: Fix possible memory leak in ptp_clock_register()\r\n\r\nI got memory leak as follows when doing fault injection test:\r\n\r\nunreferenced object 0xffff88800906c618 (size 8):\n comm \u0026quot;i2c-idt82p33931\u0026quot;, pid 4421, jiffies 4294948083 (age 13.188s)\n hex dump (first 8 bytes):\n 70 74 70 30 00 00 00 00 ptp0....\n backtrace:\n [\u0026lt;00000000312ed458\u0026gt;] __kmalloc_track_caller+0x19f/0x3a0\n [\u0026lt;0000000079f6e2ff\u0026gt;] kvasprintf+0xb5/0x150\n [\u0026lt;0000000026aae54f\u0026gt;] kvasprintf_const+0x60/0x190\n [\u0026lt;00000000f323a5f7\u0026gt;] kobject_set_name_vargs+0x56/0x150\n [\u0026lt;000000004e35abdd\u0026gt;] dev_set_name+0xc0/0x100\n [\u0026lt;00000000f20cfe25\u0026gt;] ptp_clock_register+0x9f4/0xd30 [ptp]\n [\u0026lt;000000008bb9f0de\u0026gt;] idt82p33_probe.cold+0x8b6/0x1561 [ptp_idt82p33]\r\n\r\nWhen posix_clock_register() returns an error, the name allocated\nin dev_set_name() will be leaked, the put_device() should be used\nto give up the device reference, then the name will be freed in\nkobject_cleanup() and other memory will be freed in ptp_clock_release().(CVE-2021-47455)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: ebtables: fix memory leak when blob is malformed\r\n\r\nThe bug fix was incomplete, it \u0026quot;replaced\u0026quot; crash with a memory leak.\nThe old code had an assignment to \u0026quot;ret\u0026quot; embedded into the conditional,\nrestore this.(CVE-2022-48641)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npinctrl: single: fix potential NULL dereference\r\n\r\nAdded checking of pointer \u0026quot;function\u0026quot; in pcs_set_mux().\npinmux_generic_get_function() can return NULL and the pointer\n\u0026quot;function\u0026quot; was dereferenced without checking against NULL.\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2022-48708)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/tegra: dsi: Add missing check for of_find_device_by_node\r\n\r\nAdd check for the return value of of_find_device_by_node() and return\nthe error if it fails in order to avoid NULL pointer dereference.(CVE-2023-52650)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nio_uring: drop any code related to SCM_RIGHTS\r\n\r\nThis is dead code after we dropped support for passing io_uring fds\nover SCM_RIGHTS, get rid of it.(CVE-2023-52656)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: atlantic: eliminate double free in error handling logic\r\n\r\nDriver has a logic leak in ring data allocation/free,\nwhere aq_ring_free could be called multiple times on same ring,\nif system is under stress and got memory allocation error.\r\n\r\nRing pointer was used as an indicator of failure, but this is\nnot correct since only ring data is allocated/deallocated.\nRing itself is an array member.\r\n\r\nChanging ring allocation functions to return error code directly.\nThis simplifies error handling and eliminates aq_ring_free\non higher layer.(CVE-2023-52664)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nACPI: LPIT: Avoid u32 multiplication overflow\r\n\r\nIn lpit_update_residency() there is a possibility of overflow\nin multiplication, if tsc_khz is large enough (\u0026gt; UINT_MAX/1000).\r\n\r\nChange multiplication to mul_u32_u32().\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2023-52683)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncalipso: fix memory leak in netlbl_calipso_add_pass()\r\n\r\nIf IPv6 support is disabled at boot (ipv6.disable=1),\nthe calipso_init() -\u0026gt; netlbl_calipso_ops_register() function isn\u0026apos;t called,\nand the netlbl_calipso_ops_get() function always returns NULL.\nIn this case, the netlbl_calipso_add_pass() function allocates memory\nfor the doi_def variable but doesn\u0026apos;t free it with the calipso_doi_free().\r\n\r\nBUG: memory leak\nunreferenced object 0xffff888011d68180 (size 64):\n comm \u0026quot;syz-executor.1\u0026quot;, pid 10746, jiffies 4295410986 (age 17.928s)\n hex dump (first 32 bytes):\n 00 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 ................\n 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n backtrace:\n [\u0026lt;...\u0026gt;] kmalloc include/linux/slab.h:552 [inline]\n [\u0026lt;...\u0026gt;] netlbl_calipso_add_pass net/netlabel/netlabel_calipso.c:76 [inline]\n [\u0026lt;...\u0026gt;] netlbl_calipso_add+0x22e/0x4f0 net/netlabel/netlabel_calipso.c:111\n [\u0026lt;...\u0026gt;] genl_family_rcv_msg_doit+0x22f/0x330 net/netlink/genetlink.c:739\n [\u0026lt;...\u0026gt;] genl_family_rcv_msg net/netlink/genetlink.c:783 [inline]\n [\u0026lt;...\u0026gt;] genl_rcv_msg+0x341/0x5a0 net/netlink/genetlink.c:800\n [\u0026lt;...\u0026gt;] netlink_rcv_skb+0x14d/0x440 net/netlink/af_netlink.c:2515\n [\u0026lt;...\u0026gt;] genl_rcv+0x29/0x40 net/netlink/genetlink.c:811\n [\u0026lt;...\u0026gt;] netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline]\n [\u0026lt;...\u0026gt;] netlink_unicast+0x54b/0x800 net/netlink/af_netlink.c:1339\n [\u0026lt;...\u0026gt;] netlink_sendmsg+0x90a/0xdf0 net/netlink/af_netlink.c:1934\n [\u0026lt;...\u0026gt;] sock_sendmsg_nosec net/socket.c:651 [inline]\n [\u0026lt;...\u0026gt;] sock_sendmsg+0x157/0x190 net/socket.c:671\n [\u0026lt;...\u0026gt;] ____sys_sendmsg+0x712/0x870 net/socket.c:2342\n [\u0026lt;...\u0026gt;] ___sys_sendmsg+0xf8/0x170 net/socket.c:2396\n [\u0026lt;...\u0026gt;] __sys_sendmsg+0xea/0x1b0 net/socket.c:2429\n [\u0026lt;...\u0026gt;] do_syscall_64+0x30/0x40 arch/x86/entry/common.c:46\n [\u0026lt;...\u0026gt;] entry_SYSCALL_64_after_hwframe+0x61/0xc6\r\n\r\nFound by InfoTeCS on behalf of Linux Verification Center\n(linuxtesting.org) with Syzkaller\r\n\r\n[PM: merged via the LSM tree at Jakub Kicinski request](CVE-2023-52698)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: libfc: Fix potential NULL pointer dereference in fc_lport_ptp_setup()\r\n\r\nfc_lport_ptp_setup() did not check the return value of fc_rport_create()\nwhich can return NULL and would cause a NULL pointer dereference. Address\nthis issue by checking return value of fc_rport_create() and log error\nmessage on fc_rport_create() failed.(CVE-2023-52809)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncrypto: pcrypt - Fix hungtask for PADATA_RESET\r\n\r\nWe found a hungtask bug in test_aead_vec_cfg as follows:\r\n\r\nINFO: task cryptomgr_test:391009 blocked for more than 120 seconds.\n\u0026quot;echo 0 \u0026gt; /proc/sys/kernel/hung_task_timeout_secs\u0026quot; disables this message.\nCall trace:\n __switch_to+0x98/0xe0\n __schedule+0x6c4/0xf40\n schedule+0xd8/0x1b4\n schedule_timeout+0x474/0x560\n wait_for_common+0x368/0x4e0\n wait_for_completion+0x20/0x30\n wait_for_completion+0x20/0x30\n test_aead_vec_cfg+0xab4/0xd50\n test_aead+0x144/0x1f0\n alg_test_aead+0xd8/0x1e0\n alg_test+0x634/0x890\n cryptomgr_test+0x40/0x70\n kthread+0x1e0/0x220\n ret_from_fork+0x10/0x18\n Kernel panic - not syncing: hung_task: blocked tasks\r\n\r\nFor padata_do_parallel, when the return err is 0 or -EBUSY, it will call\nwait_for_completion(\u0026amp;wait-\u0026gt;completion) in test_aead_vec_cfg. In normal\ncase, aead_request_complete() will be called in pcrypt_aead_serial and the\nreturn err is 0 for padata_do_parallel. But, when pinst-\u0026gt;flags is\nPADATA_RESET, the return err is -EBUSY for padata_do_parallel, and it\nwon\u0026apos;t call aead_request_complete(). Therefore, test_aead_vec_cfg will\nhung at wait_for_completion(\u0026amp;wait-\u0026gt;completion), which will cause\nhungtask.\r\n\r\nThe problem comes as following:\n(padata_do_parallel) |\n rcu_read_lock_bh(); |\n err = -EINVAL; | (padata_replace)\n | pinst-\u0026gt;flags |= PADATA_RESET;\n err = -EBUSY |\n if (pinst-\u0026gt;flags \u0026amp; PADATA_RESET) |\n rcu_read_unlock_bh() |\n return err\r\n\r\nIn order to resolve the problem, we replace the return err -EBUSY with\n-EAGAIN, which means parallel_data is changing, and the caller should call\nit again.\r\n\r\nv3:\nremove retry and just change the return err.\nv2:\nintroduce padata_try_do_parallel() in pcrypt_aead_encrypt and\npcrypt_aead_decrypt to solve the hungtask.(CVE-2023-52813)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: Fix a null pointer access when the smc_rreg pointer is NULL\r\n\r\nIn certain types of chips, such as VEGA20, reading the amdgpu_regs_smc file could result in an abnormal null pointer access when the smc_rreg pointer is NULL. Below are the steps to reproduce this issue and the corresponding exception log:\r\n\r\n1. Navigate to the directory: /sys/kernel/debug/dri/0\n2. Execute command: cat amdgpu_regs_smc\n3. Exception Log::\n[4005007.702554] BUG: kernel NULL pointer dereference, address: 0000000000000000\n[4005007.702562] #PF: supervisor instruction fetch in kernel mode\n[4005007.702567] #PF: error_code(0x0010) - not-present page\n[4005007.702570] PGD 0 P4D 0\n[4005007.702576] Oops: 0010 [#1] SMP NOPTI\n[4005007.702581] CPU: 4 PID: 62563 Comm: cat Tainted: G OE 5.15.0-43-generic #46-Ubunt u\n[4005007.702590] RIP: 0010:0x0\n[4005007.702598] Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6.\n[4005007.702600] RSP: 0018:ffffa82b46d27da0 EFLAGS: 00010206\n[4005007.702605] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffa82b46d27e68\n[4005007.702609] RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff9940656e0000\n[4005007.702612] RBP: ffffa82b46d27dd8 R08: 0000000000000000 R09: ffff994060c07980\n[4005007.702615] R10: 0000000000020000 R11: 0000000000000000 R12: 00007f5e06753000\n[4005007.702618] R13: ffff9940656e0000 R14: ffffa82b46d27e68 R15: 00007f5e06753000\n[4005007.702622] FS: 00007f5e0755b740(0000) GS:ffff99479d300000(0000) knlGS:0000000000000000\n[4005007.702626] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[4005007.702629] CR2: ffffffffffffffd6 CR3: 00000003253fc000 CR4: 00000000003506e0\n[4005007.702633] Call Trace:\n[4005007.702636] \u0026lt;TASK\u0026gt;\n[4005007.702640] amdgpu_debugfs_regs_smc_read+0xb0/0x120 [amdgpu]\n[4005007.703002] full_proxy_read+0x5c/0x80\n[4005007.703011] vfs_read+0x9f/0x1a0\n[4005007.703019] ksys_read+0x67/0xe0\n[4005007.703023] __x64_sys_read+0x19/0x20\n[4005007.703028] do_syscall_64+0x5c/0xc0\n[4005007.703034] ? do_user_addr_fault+0x1e3/0x670\n[4005007.703040] ? exit_to_user_mode_prepare+0x37/0xb0\n[4005007.703047] ? irqentry_exit_to_user_mode+0x9/0x20\n[4005007.703052] ? irqentry_exit+0x19/0x30\n[4005007.703057] ? exc_page_fault+0x89/0x160\n[4005007.703062] ? asm_exc_page_fault+0x8/0x30\n[4005007.703068] entry_SYSCALL_64_after_hwframe+0x44/0xae\n[4005007.703075] RIP: 0033:0x7f5e07672992\n[4005007.703079] Code: c0 e9 b2 fe ff ff 50 48 8d 3d fa b2 0c 00 e8 c5 1d 02 00 0f 1f 44 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 0f 05 \u0026lt;48\u0026gt; 3d 00 f0 ff ff 77 56 c3 0f 1f 44 00 00 48 83 e c 28 48 89 54 24\n[4005007.703083] RSP: 002b:00007ffe03097898 EFLAGS: 00000246 ORIG_RAX: 0000000000000000\n[4005007.703088] RAX: ffffffffffffffda RBX: 0000000000020000 RCX: 00007f5e07672992\n[4005007.703091] RDX: 0000000000020000 RSI: 00007f5e06753000 RDI: 0000000000000003\n[4005007.703094] RBP: 00007f5e06753000 R08: 00007f5e06752010 R09: 00007f5e06752010\n[4005007.703096] R10: 0000000000000022 R11: 0000000000000246 R12: 0000000000022000\n[4005007.703099] R13: 0000000000000003 R14: 0000000000020000 R15: 0000000000020000\n[4005007.703105] \u0026lt;/TASK\u0026gt;\n[4005007.703107] Modules linked in: nf_tables libcrc32c nfnetlink algif_hash af_alg binfmt_misc nls_ iso8859_1 ipmi_ssif ast intel_rapl_msr intel_rapl_common drm_vram_helper drm_ttm_helper amd64_edac t tm edac_mce_amd kvm_amd ccp mac_hid k10temp kvm acpi_ipmi ipmi_si rapl sch_fq_codel ipmi_devintf ipm i_msghandler msr parport_pc ppdev lp parport mtd pstore_blk efi_pstore ramoops pstore_zone reed_solo mon ip_tables x_tables autofs4 ib_uverbs ib_core amdgpu(OE) amddrm_ttm_helper(OE) amdttm(OE) iommu_v 2 amd_sched(OE) amdkcl(OE) drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops cec rc_core drm igb ahci xhci_pci libahci i2c_piix4 i2c_algo_bit xhci_pci_renesas dca\n[4005007.703184] CR2: 0000000000000000\n[4005007.703188] ---[ en\n---truncated---(CVE-2023-52817)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nperf/core: Bail out early if the request AUX area is out of bound\r\n\r\nWhen perf-record with a large AUX area, e.g 4GB, it fails with:\r\n\r\n #perf record -C 0 -m ,4G -e arm_spe_0// -- sleep 1\n failed to mmap with 12 (Cannot allocate memory)\r\n\r\nand it reveals a WARNING with __alloc_pages():\r\n\r\n\t------------[ cut here ]------------\n\tWARNING: CPU: 44 PID: 17573 at mm/page_alloc.c:5568 __alloc_pages+0x1ec/0x248\n\tCall trace:\n\t __alloc_pages+0x1ec/0x248\n\t __kmalloc_large_node+0xc0/0x1f8\n\t __kmalloc_node+0x134/0x1e8\n\t rb_alloc_aux+0xe0/0x298\n\t perf_mmap+0x440/0x660\n\t mmap_region+0x308/0x8a8\n\t do_mmap+0x3c0/0x528\n\t vm_mmap_pgoff+0xf4/0x1b8\n\t ksys_mmap_pgoff+0x18c/0x218\n\t __arm64_sys_mmap+0x38/0x58\n\t invoke_syscall+0x50/0x128\n\t el0_svc_common.constprop.0+0x58/0x188\n\t do_el0_svc+0x34/0x50\n\t el0_svc+0x34/0x108\n\t el0t_64_sync_handler+0xb8/0xc0\n\t el0t_64_sync+0x1a4/0x1a8\r\n\r\n\u0026apos;rb-\u0026gt;aux_pages\u0026apos; allocated by kcalloc() is a pointer array which is used to\nmaintains AUX trace pages. The allocated page for this array is physically\ncontiguous (and virtually contiguous) with an order of 0..MAX_ORDER. If the\nsize of pointer array crosses the limitation set by MAX_ORDER, it reveals a\nWARNING.\r\n\r\nSo bail out early with -ENOMEM if the request AUX area is out of bound,\ne.g.:\r\n\r\n #perf record -C 0 -m ,4G -e arm_spe_0// -- sleep 1\n failed to mmap with 12 (Cannot allocate memory)(CVE-2023-52835)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnbd: fix uaf in nbd_open\r\n\r\nCommit 4af5f2e03013 (\u0026quot;nbd: use blk_mq_alloc_disk and\nblk_cleanup_disk\u0026quot;) cleans up disk by blk_cleanup_disk() and it won\u0026apos;t set\ndisk-\u0026gt;private_data as NULL as before. UAF may be triggered in nbd_open()\nif someone tries to open nbd device right after nbd_put() since nbd has\nbeen free in nbd_dev_remove().\r\n\r\nFix this by implementing -\u0026gt;free_disk and free private data in it.(CVE-2023-52837)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nInput: synaptics-rmi4 - fix use after free in rmi_unregister_function()\r\n\r\nThe put_device() calls rmi_release_function() which frees \u0026quot;fn\u0026quot; so the\ndereference on the next line \u0026quot;fn-\u0026gt;num_of_irqs\u0026quot; is a use after free.\nMove the put_device() to the end to fix this.(CVE-2023-52840)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: vidtv: psi: Add check for kstrdup\r\n\r\nAdd check for the return value of kstrdup() and return the error\nif it fails in order to avoid NULL pointer dereference.(CVE-2023-52844)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: bttv: fix use after free error due to btv-\u0026gt;timeout timer\r\n\r\nThere may be some a race condition between timer function\nbttv_irq_timeout and bttv_remove. The timer is setup in\nprobe and there is no timer_delete operation in remove\nfunction. When it hit kfree btv, the function might still be\ninvoked, which will cause use after free bug.\r\n\r\nThis bug is found by static analysis, it may be false positive.\r\n\r\nFix it by adding del_timer_sync invoking to the remove function.\r\n\r\ncpu0 cpu1\n bttv_probe\n -\u0026gt;timer_setup\n -\u0026gt;bttv_set_dma\n -\u0026gt;mod_timer;\nbttv_remove\n -\u0026gt;kfree(btv);\n -\u0026gt;bttv_irq_timeout\n -\u0026gt;USE btv(CVE-2023-52847)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npadata: Fix refcnt handling in padata_free_shell()\r\n\r\nIn a high-load arm64 environment, the pcrypt_aead01 test in LTP can lead\nto system UAF (Use-After-Free) issues. Due to the lengthy analysis of\nthe pcrypt_aead01 function call, I\u0026apos;ll describe the problem scenario\nusing a simplified model:\r\n\r\nSuppose there\u0026apos;s a user of padata named `user_function` that adheres to\nthe padata requirement of calling `padata_free_shell` after `serial()`\nhas been invoked, as demonstrated in the following code:\r\n\r\n```c\nstruct request {\n struct padata_priv padata;\n struct completion *done;\n};\r\n\r\nvoid parallel(struct padata_priv *padata) {\n do_something();\n}\r\n\r\nvoid serial(struct padata_priv *padata) {\n struct request *request = container_of(padata,\n \t\t\t\tstruct request,\n\t\t\t\tpadata);\n complete(request-\u0026gt;done);\n}\r\n\r\nvoid user_function() {\n DECLARE_COMPLETION(done)\n padata-\u0026gt;parallel = parallel;\n padata-\u0026gt;serial = serial;\n padata_do_parallel();\n wait_for_completion(\u0026amp;done);\n padata_free_shell();\n}\n```\r\n\r\nIn the corresponding padata.c file, there\u0026apos;s the following code:\r\n\r\n```c\nstatic void padata_serial_worker(struct work_struct *serial_work) {\n ...\n cnt = 0;\r\n\r\n while (!list_empty(\u0026amp;local_list)) {\n ...\n padata-\u0026gt;serial(padata);\n cnt++;\n }\r\n\r\n local_bh_enable();\r\n\r\n if (refcount_sub_and_test(cnt, \u0026amp;pd-\u0026gt;refcnt))\n padata_free_pd(pd);\n}\n```\r\n\r\nBecause of the high system load and the accumulation of unexecuted\nsoftirq at this moment, `local_bh_enable()` in padata takes longer\nto execute than usual. Subsequently, when accessing `pd-\u0026gt;refcnt`,\n`pd` has already been released by `padata_free_shell()`, resulting\nin a UAF issue with `pd-\u0026gt;refcnt`.\r\n\r\nThe fix is straightforward: add `refcount_dec_and_test` before calling\n`padata_free_pd` in `padata_free_shell`.(CVE-2023-52854)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrivers/perf: hisi: use cpuhp_state_remove_instance_nocalls() for hisi_hns3_pmu uninit process\r\n\r\nWhen tearing down a \u0026apos;hisi_hns3\u0026apos; PMU, we mistakenly run the CPU hotplug\ncallbacks after the device has been unregistered, leading to fireworks\nwhen we try to execute empty function callbacks within the driver:\r\n\r\n | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000\n | CPU: 0 PID: 15 Comm: cpuhp/0 Tainted: G W O 5.12.0-rc4+ #1\n | Hardware name: , BIOS KpxxxFPGA 1P B600 V143 04/22/2021\n | pstate: 80400009 (Nzcv daif +PAN -UAO -TCO BTYPE=--)\n | pc : perf_pmu_migrate_context+0x98/0x38c\n | lr : perf_pmu_migrate_context+0x94/0x38c\n |\n | Call trace:\n | perf_pmu_migrate_context+0x98/0x38c\n | hisi_hns3_pmu_offline_cpu+0x104/0x12c [hisi_hns3_pmu]\r\n\r\nUse cpuhp_state_remove_instance_nocalls() instead of\ncpuhp_state_remove_instance() so that the notifiers don\u0026apos;t execute after\nthe PMU device has been unregistered.\r\n\r\n[will: Rewrote commit message](CVE-2023-52860)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nhwmon: (axi-fan-control) Fix possible NULL pointer dereference\r\n\r\naxi_fan_control_irq_handler(), dependent on the private\naxi_fan_control_data structure, might be called before the hwmon\ndevice is registered. That will cause an \u0026quot;Unable to handle kernel\nNULL pointer dereference\u0026quot; error.(CVE-2023-52863)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/radeon: possible buffer overflow\r\n\r\nBuffer \u0026apos;afmt_status\u0026apos; of size 6 could overflow, since index \u0026apos;afmt_idx\u0026apos; is\nchecked after access.(CVE-2023-52867)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npstore/platform: Add check for kstrdup\r\n\r\nAdd check for the return value of kstrdup() and return the error\nif it fails in order to avoid NULL pointer dereference.(CVE-2023-52869)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nclk: mediatek: clk-mt7629-eth: 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-52876)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntracing: Have trace_event_file have ref counters\r\n\r\nThe following can crash the kernel:\r\n\r\n # cd /sys/kernel/tracing\n # echo \u0026apos;p:sched schedule\u0026apos; \u0026gt; kprobe_events\n # exec 5\u0026gt;\u0026gt;events/kprobes/sched/enable\n # \u0026gt; kprobe_events\n # exec 5\u0026gt;\u0026amp;-\r\n\r\nThe above commands:\r\n\r\n 1. Change directory to the tracefs directory\n 2. Create a kprobe event (doesn\u0026apos;t matter what one)\n 3. Open bash file descriptor 5 on the enable file of the kprobe event\n 4. Delete the kprobe event (removes the files too)\n 5. Close the bash file descriptor 5\r\n\r\nThe above causes a crash!\r\n\r\n BUG: kernel NULL pointer dereference, address: 0000000000000028\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\n PGD 0 P4D 0\n Oops: 0000 [#1] PREEMPT SMP PTI\n CPU: 6 PID: 877 Comm: bash Not tainted 6.5.0-rc4-test-00008-g2c6b6b1029d4-dirty #186\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014\n RIP: 0010:tracing_release_file_tr+0xc/0x50\r\n\r\nWhat happens here is that the kprobe event creates a trace_event_file\n\u0026quot;file\u0026quot; descriptor that represents the file in tracefs to the event. It\nmaintains state of the event (is it enabled for the given instance?).\nOpening the \u0026quot;enable\u0026quot; file gets a reference to the event \u0026quot;file\u0026quot; descriptor\nvia the open file descriptor. When the kprobe event is deleted, the file is\nalso deleted from the tracefs system which also frees the event \u0026quot;file\u0026quot;\ndescriptor.\r\n\r\nBut as the tracefs file is still opened by user space, it will not be\ntotally removed until the final dput() is called on it. But this is not\ntrue with the event \u0026quot;file\u0026quot; descriptor that is already freed. If the user\ndoes a write to or simply closes the file descriptor it will reference the\nevent \u0026quot;file\u0026quot; descriptor that was just freed, causing a use-after-free bug.\r\n\r\nTo solve this, add a ref count to the event \u0026quot;file\u0026quot; descriptor as well as a\nnew flag called \u0026quot;FREED\u0026quot;. The \u0026quot;file\u0026quot; will not be freed until the last\nreference is released. But the FREE flag will be set when the event is\nremoved to prevent any more modifications to that event from happening,\neven if there\u0026apos;s still a reference to the event \u0026quot;file\u0026quot; descriptor.(CVE-2023-52879)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nvfio/fsl-mc: Block calling interrupt handler without trigger\r\n\r\nThe eventfd_ctx trigger pointer of the vfio_fsl_mc_irq object is\ninitially NULL and may become NULL if the user sets the trigger\neventfd to -1. The interrupt handler itself is guaranteed that\ntrigger is always valid between request_irq() and free_irq(), but\nthe loopback testing mechanisms to invoke the handler function\nneed to test the trigger. The triggering and setting ioctl paths\nboth make use of igate and are therefore mutually exclusive.\r\n\r\nThe vfio-fsl-mc driver does not make use of irqfds, nor does it\nsupport any sort of masking operations, therefore unlike vfio-pci\nand vfio-platform, the flow can remain essentially unchanged.(CVE-2024-26814)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\naf_unix: Fix garbage collector racing against connect()\r\n\r\nGarbage collector does not take into account the risk of embryo getting\nenqueued during the garbage collection. If such embryo has a peer that\ncarries SCM_RIGHTS, two consecutive passes of scan_children() may see a\ndifferent set of children. Leading to an incorrectly elevated inflight\ncount, and then a dangling pointer within the gc_inflight_list.\r\n\r\nsockets are AF_UNIX/SOCK_STREAM\nS is an unconnected socket\nL is a listening in-flight socket bound to addr, not in fdtable\nV\u0026apos;s fd will be passed via sendmsg(), gets inflight count bumped\r\n\r\nconnect(S, addr)\tsendmsg(S, [V]); close(V)\t__unix_gc()\n----------------\t-------------------------\t-----------\r\n\r\nNS = unix_create1()\nskb1 = sock_wmalloc(NS)\nL = unix_find_other(addr)\nunix_state_lock(L)\nunix_peer(S) = NS\n\t\t\t// V count=1 inflight=0\r\n\r\n \t\t\tNS = unix_peer(S)\n \t\t\tskb2 = sock_alloc()\n\t\t\tskb_queue_tail(NS, skb2[V])\r\n\r\n\t\t\t// V became in-flight\n\t\t\t// V count=2 inflight=1\r\n\r\n\t\t\tclose(V)\r\n\r\n\t\t\t// V count=1 inflight=1\n\t\t\t// GC candidate condition met\r\n\r\n\t\t\t\t\t\tfor u in gc_inflight_list:\n\t\t\t\t\t\t if (total_refs == inflight_refs)\n\t\t\t\t\t\t add u to gc_candidates\r\n\r\n\t\t\t\t\t\t// gc_candidates={L, V}\r\n\r\n\t\t\t\t\t\tfor u in gc_candidates:\n\t\t\t\t\t\t scan_children(u, dec_inflight)\r\n\r\n\t\t\t\t\t\t// embryo (skb1) was not\n\t\t\t\t\t\t// reachable from L yet, so V\u0026apos;s\n\t\t\t\t\t\t// inflight remains unchanged\n__skb_queue_tail(L, skb1)\nunix_state_unlock(L)\n\t\t\t\t\t\tfor u in gc_candidates:\n\t\t\t\t\t\t if (u.inflight)\n\t\t\t\t\t\t scan_children(u, inc_inflight_move_tail)\r\n\r\n\t\t\t\t\t\t// V count=1 inflight=2 (!)\r\n\r\nIf there is a GC-candidate listening socket, lock/unlock its state. This\nmakes GC wait until the end of any ongoing connect() to that socket. After\nflipping the lock, a possibly SCM-laden embryo is already enqueued. And if\nthere is another embryo coming, it can not possibly carry SCM_RIGHTS. At\nthis point, unix_inflight() can not happen because unix_gc_lock is already\ntaken. Inflight graph remains unaffected.(CVE-2024-26923)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwireguard: netlink: access device through ctx instead of peer\r\n\r\nThe previous commit fixed a bug that led to a NULL peer-\u0026gt;device being\ndereferenced. It\u0026apos;s actually easier and faster performance-wise to\ninstead get the device from ctx-\u0026gt;wg. This semantically makes more sense\ntoo, since ctx-\u0026gt;wg-\u0026gt;peer_allowedips.seq is compared with\nctx-\u0026gt;allowedips_seq, basing them both in ctx. This also acts as a\ndefence in depth provision against freed peers.(CVE-2024-26950)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnfs: fix UAF in direct writes\r\n\r\nIn production we have been hitting the following warning consistently\r\n\r\n------------[ cut here ]------------\nrefcount_t: underflow; use-after-free.\nWARNING: CPU: 17 PID: 1800359 at lib/refcount.c:28 refcount_warn_saturate+0x9c/0xe0\nWorkqueue: nfsiod nfs_direct_write_schedule_work [nfs]\nRIP: 0010:refcount_warn_saturate+0x9c/0xe0\nPKRU: 55555554\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? __warn+0x9f/0x130\n ? refcount_warn_saturate+0x9c/0xe0\n ? report_bug+0xcc/0x150\n ? handle_bug+0x3d/0x70\n ? exc_invalid_op+0x16/0x40\n ? asm_exc_invalid_op+0x16/0x20\n ? refcount_warn_saturate+0x9c/0xe0\n nfs_direct_write_schedule_work+0x237/0x250 [nfs]\n process_one_work+0x12f/0x4a0\n worker_thread+0x14e/0x3b0\n ? ZSTD_getCParams_internal+0x220/0x220\n kthread+0xdc/0x120\n ? __btf_name_valid+0xa0/0xa0\n ret_from_fork+0x1f/0x30\r\n\r\nThis is because we\u0026apos;re completing the nfs_direct_request twice in a row.\r\n\r\nThe source of this is when we have our commit requests to submit, we\nprocess them and send them off, and then in the completion path for the\ncommit requests we have\r\n\r\nif (nfs_commit_end(cinfo.mds))\n\tnfs_direct_write_complete(dreq);\r\n\r\nHowever since we\u0026apos;re submitting asynchronous requests we sometimes have\none that completes before we submit the next one, so we end up calling\ncomplete on the nfs_direct_request twice.\r\n\r\nThe only other place we use nfs_generic_commit_list() is in\n__nfs_commit_inode, which wraps this call in a\r\n\r\nnfs_commit_begin();\nnfs_commit_end();\r\n\r\nWhich is a common pattern for this style of completion handling, one\nthat is also repeated in the direct code with get_dreq()/put_dreq()\ncalls around where we process events as well as in the completion paths.\r\n\r\nFix this by using the same pattern for the commit requests.\r\n\r\nBefore with my 200 node rocksdb stress running this warning would pop\nevery 10ish minutes. With my patch the stress test has been running for\nseveral hours without popping.(CVE-2024-26958)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmac802154: fix llsec key resources release in mac802154_llsec_key_del\r\n\r\nmac802154_llsec_key_del() can free resources of a key directly without\nfollowing the RCU rules for waiting before the end of a grace period. This\nmay lead to use-after-free in case llsec_lookup_key() is traversing the\nlist of keys in parallel with a key deletion:\r\n\r\nrefcount_t: addition on 0; use-after-free.\nWARNING: CPU: 4 PID: 16000 at lib/refcount.c:25 refcount_warn_saturate+0x162/0x2a0\nModules linked in:\nCPU: 4 PID: 16000 Comm: wpan-ping Not tainted 6.7.0 #19\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014\nRIP: 0010:refcount_warn_saturate+0x162/0x2a0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n llsec_lookup_key.isra.0+0x890/0x9e0\n mac802154_llsec_encrypt+0x30c/0x9c0\n ieee802154_subif_start_xmit+0x24/0x1e0\n dev_hard_start_xmit+0x13e/0x690\n sch_direct_xmit+0x2ae/0xbc0\n __dev_queue_xmit+0x11dd/0x3c20\n dgram_sendmsg+0x90b/0xd60\n __sys_sendto+0x466/0x4c0\n __x64_sys_sendto+0xe0/0x1c0\n do_syscall_64+0x45/0xf0\n entry_SYSCALL_64_after_hwframe+0x6e/0x76\r\n\r\nAlso, ieee802154_llsec_key_entry structures are not freed by\nmac802154_llsec_key_del():\r\n\r\nunreferenced object 0xffff8880613b6980 (size 64):\n comm \u0026quot;iwpan\u0026quot;, pid 2176, jiffies 4294761134 (age 60.475s)\n hex dump (first 32 bytes):\n 78 0d 8f 18 80 88 ff ff 22 01 00 00 00 00 ad de x.......\u0026quot;.......\n 00 00 00 00 00 00 00 00 03 00 cd ab 00 00 00 00 ................\n backtrace:\n [\u0026lt;ffffffff81dcfa62\u0026gt;] __kmem_cache_alloc_node+0x1e2/0x2d0\n [\u0026lt;ffffffff81c43865\u0026gt;] kmalloc_trace+0x25/0xc0\n [\u0026lt;ffffffff88968b09\u0026gt;] mac802154_llsec_key_add+0xac9/0xcf0\n [\u0026lt;ffffffff8896e41a\u0026gt;] ieee802154_add_llsec_key+0x5a/0x80\n [\u0026lt;ffffffff8892adc6\u0026gt;] nl802154_add_llsec_key+0x426/0x5b0\n [\u0026lt;ffffffff86ff293e\u0026gt;] genl_family_rcv_msg_doit+0x1fe/0x2f0\n [\u0026lt;ffffffff86ff46d1\u0026gt;] genl_rcv_msg+0x531/0x7d0\n [\u0026lt;ffffffff86fee7a9\u0026gt;] netlink_rcv_skb+0x169/0x440\n [\u0026lt;ffffffff86ff1d88\u0026gt;] genl_rcv+0x28/0x40\n [\u0026lt;ffffffff86fec15c\u0026gt;] netlink_unicast+0x53c/0x820\n [\u0026lt;ffffffff86fecd8b\u0026gt;] netlink_sendmsg+0x93b/0xe60\n [\u0026lt;ffffffff86b91b35\u0026gt;] ____sys_sendmsg+0xac5/0xca0\n [\u0026lt;ffffffff86b9c3dd\u0026gt;] ___sys_sendmsg+0x11d/0x1c0\n [\u0026lt;ffffffff86b9c65a\u0026gt;] __sys_sendmsg+0xfa/0x1d0\n [\u0026lt;ffffffff88eadbf5\u0026gt;] do_syscall_64+0x45/0xf0\n [\u0026lt;ffffffff890000ea\u0026gt;] entry_SYSCALL_64_after_hwframe+0x6e/0x76\r\n\r\nHandle the proper resource release in the RCU callback function\nmac802154_llsec_key_del_rcu().\r\n\r\nNote that if llsec_lookup_key() finds a key, it gets a refcount via\nllsec_key_get() and locally copies key id from key_entry (which is a\nlist element). So it\u0026apos;s safe to call llsec_key_put() and free the list\nentry after the RCU grace period elapses.\r\n\r\nFound by Linux Verification Center (linuxtesting.org).(CVE-2024-26961)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nclk: qcom: mmcc-msm8974: fix terminating of frequency table arrays\r\n\r\nThe frequency table arrays are supposed to be terminated with an\nempty element. Add such entry to the end of the arrays where it\nis missing in order to avoid possible out-of-bound access when\nthe table is traversed by functions like qcom_find_freq() or\nqcom_find_freq_floor().\r\n\r\nOnly compile tested.(CVE-2024-26965)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nubifs: ubifs_symlink: Fix memleak of inode-\u0026gt;i_link in error path\r\n\r\nFor error handling path in ubifs_symlink(), inode will be marked as\nbad first, then iput() is invoked. If inode-\u0026gt;i_link is initialized by\nfscrypt_encrypt_symlink() in encryption scenario, inode-\u0026gt;i_link won\u0026apos;t\nbe freed by callchain ubifs_free_inode -\u0026gt; fscrypt_free_inode in error\nhandling path, because make_bad_inode() has changed \u0026apos;inode-\u0026gt;i_mode\u0026apos; as\n\u0026apos;S_IFREG\u0026apos;.\nFollowing kmemleak is easy to be reproduced by injecting error in\nubifs_jnl_update() when doing symlink in encryption scenario:\n unreferenced object 0xffff888103da3d98 (size 8):\n comm \u0026quot;ln\u0026quot;, pid 1692, jiffies 4294914701 (age 12.045s)\n backtrace:\n kmemdup+0x32/0x70\n __fscrypt_encrypt_symlink+0xed/0x1c0\n ubifs_symlink+0x210/0x300 [ubifs]\n vfs_symlink+0x216/0x360\n do_symlinkat+0x11a/0x190\n do_syscall_64+0x3b/0xe0\nThere are two ways fixing it:\n 1. Remove make_bad_inode() in error handling path. We can do that\n because ubifs_evict_inode() will do same processes for good\n symlink inode and bad symlink inode, for inode-\u0026gt;i_nlink checking\n is before is_bad_inode().\n 2. Free inode-\u0026gt;i_link before marking inode bad.\nMethod 2 is picked, it has less influence, personally, I think.(CVE-2024-26972)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nKVM: Always flush async #PF workqueue when vCPU is being destroyed\r\n\r\nAlways flush the per-vCPU async #PF workqueue when a vCPU is clearing its\ncompletion queue, e.g. when a VM and all its vCPUs is being destroyed.\nKVM must ensure that none of its workqueue callbacks is running when the\nlast reference to the KVM _module_ is put. Gifting a reference to the\nassociated VM prevents the workqueue callback from dereferencing freed\nvCPU/VM memory, but does not prevent the KVM module from being unloaded\nbefore the callback completes.\r\n\r\nDrop the misguided VM refcount gifting, as calling kvm_put_kvm() from\nasync_pf_execute() if kvm_put_kvm() flushes the async #PF workqueue will\nresult in deadlock. async_pf_execute() can\u0026apos;t return until kvm_put_kvm()\nfinishes, and kvm_put_kvm() can\u0026apos;t return until async_pf_execute() finishes:\r\n\r\n WARNING: CPU: 8 PID: 251 at virt/kvm/kvm_main.c:1435 kvm_put_kvm+0x2d/0x320 [kvm]\n Modules linked in: vhost_net vhost vhost_iotlb tap kvm_intel kvm irqbypass\n CPU: 8 PID: 251 Comm: kworker/8:1 Tainted: G W 6.6.0-rc1-e7af8d17224a-x86/gmem-vm #119\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015\n Workqueue: events async_pf_execute [kvm]\n RIP: 0010:kvm_put_kvm+0x2d/0x320 [kvm]\n Call Trace:\n \u0026lt;TASK\u0026gt;\n async_pf_execute+0x198/0x260 [kvm]\n process_one_work+0x145/0x2d0\n worker_thread+0x27e/0x3a0\n kthread+0xba/0xe0\n ret_from_fork+0x2d/0x50\n ret_from_fork_asm+0x11/0x20\n \u0026lt;/TASK\u0026gt;\n ---[ end trace 0000000000000000 ]---\n INFO: task kworker/8:1:251 blocked for more than 120 seconds.\n Tainted: G W 6.6.0-rc1-e7af8d17224a-x86/gmem-vm #119\n \u0026quot;echo 0 \u0026gt; /proc/sys/kernel/hung_task_timeout_secs\u0026quot; disables this message.\n task:kworker/8:1 state:D stack:0 pid:251 ppid:2 flags:0x00004000\n Workqueue: events async_pf_execute [kvm]\n Call Trace:\n \u0026lt;TASK\u0026gt;\n __schedule+0x33f/0xa40\n schedule+0x53/0xc0\n schedule_timeout+0x12a/0x140\n __wait_for_common+0x8d/0x1d0\n __flush_work.isra.0+0x19f/0x2c0\n kvm_clear_async_pf_completion_queue+0x129/0x190 [kvm]\n kvm_arch_destroy_vm+0x78/0x1b0 [kvm]\n kvm_put_kvm+0x1c1/0x320 [kvm]\n async_pf_execute+0x198/0x260 [kvm]\n process_one_work+0x145/0x2d0\n worker_thread+0x27e/0x3a0\n kthread+0xba/0xe0\n ret_from_fork+0x2d/0x50\n ret_from_fork_asm+0x11/0x20\n \u0026lt;/TASK\u0026gt;\r\n\r\nIf kvm_clear_async_pf_completion_queue() actually flushes the workqueue,\nthen there\u0026apos;s no need to gift async_pf_execute() a reference because all\ninvocations of async_pf_execute() will be forced to complete before the\nvCPU and its VM are destroyed/freed. And that in turn fixes the module\nunloading bug as __fput() won\u0026apos;t do module_put() on the last vCPU reference\nuntil the vCPU has been freed, e.g. if closing the vCPU file also puts the\nlast reference to the KVM module.\r\n\r\nNote that kvm_check_async_pf_completion() may also take the work item off\nthe completion queue and so also needs to flush the work queue, as the\nwork will not be seen by kvm_clear_async_pf_completion_queue(). Waiting\non the workqueue could theoretically delay a vCPU due to waiting for the\nwork to complete, but that\u0026apos;s a very, very small chance, and likely a very\nsmall delay. kvm_arch_async_page_present_queued() unconditionally makes a\nnew request, i.e. will effectively delay entering the guest, so the\nremaining work is really just:\r\n\r\n trace_kvm_async_pf_completed(addr, cr2_or_gpa);\r\n\r\n __kvm_vcpu_wake_up(vcpu);\r\n\r\n mmput(mm);\r\n\r\nand mmput() can\u0026apos;t drop the last reference to the page tables if the vCPU is\nstill alive, i.e. the vCPU won\u0026apos;t get stuck tearing down page tables.\r\n\r\nAdd a helper to do the flushing, specifically to deal with \u0026quot;wakeup all\u0026quot;\nwork items, as they aren\u0026apos;t actually work items, i.e. are never placed in a\nworkqueue. Trying to flush a bogus workqueue entry rightly makes\n__flush_work() complain (kudos to whoever added that sanity check).\r\n\r\nNote, commit 5f6de5cbebee (\u0026quot;KVM: Prevent module exit until al\n---truncated---(CVE-2024-26976)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nSquashfs: check the inode number is not the invalid value of zero\r\n\r\nSyskiller has produced an out of bounds access in fill_meta_index().\r\n\r\nThat out of bounds access is ultimately caused because the inode\nhas an inode number with the invalid value of zero, which was not checked.\r\n\r\nThe reason this causes the out of bounds access is due to following\nsequence of events:\r\n\r\n1. Fill_meta_index() is called to allocate (via empty_meta_index())\n and fill a metadata index. It however suffers a data read error\n and aborts, invalidating the newly returned empty metadata index.\n It does this by setting the inode number of the index to zero,\n which means unused (zero is not a valid inode number).\r\n\r\n2. When fill_meta_index() is subsequently called again on another\n read operation, locate_meta_index() returns the previous index\n because it matches the inode number of 0. Because this index\n has been returned it is expected to have been filled, and because\n it hasn\u0026apos;t been, an out of bounds access is performed.\r\n\r\nThis patch adds a sanity check which checks that the inode number\nis not zero when the inode is created and returns -EINVAL if it is.\r\n\r\n[phillip@squashfs.org.uk: whitespace fix]\n Link: https://lkml.kernel.org/r/20240409204723.446925-1-phillip@squashfs.org.uk(CVE-2024-26982)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfs: sysfs: Fix reference leak in sysfs_break_active_protection()\r\n\r\nThe sysfs_break_active_protection() routine has an obvious reference\nleak in its error path. If the call to kernfs_find_and_get() fails then\nkn will be NULL, so the companion sysfs_unbreak_active_protection()\nroutine won\u0026apos;t get called (and would only cause an access violation by\ntrying to dereference kn-\u0026gt;parent if it was called). As a result, the\nreference to kobj acquired at the start of the function will never be\nreleased.\r\n\r\nFix the leak by adding an explicit kobject_put() call when kn is NULL.(CVE-2024-26993)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nserial: mxs-auart: add spinlock around changing cts state\r\n\r\nThe uart_handle_cts_change() function in serial_core expects the caller\nto hold uport-\u0026gt;lock. For example, I have seen the below kernel splat,\nwhen the Bluetooth driver is loaded on an i.MX28 board.\r\n\r\n [ 85.119255] ------------[ cut here ]------------\n [ 85.124413] WARNING: CPU: 0 PID: 27 at /drivers/tty/serial/serial_core.c:3453 uart_handle_cts_change+0xb4/0xec\n [ 85.134694] Modules linked in: hci_uart bluetooth ecdh_generic ecc wlcore_sdio configfs\n [ 85.143314] CPU: 0 PID: 27 Comm: kworker/u3:0 Not tainted 6.6.3-00021-gd62a2f068f92 #1\n [ 85.151396] Hardware name: Freescale MXS (Device Tree)\n [ 85.156679] Workqueue: hci0 hci_power_on [bluetooth]\n (...)\n [ 85.191765] uart_handle_cts_change from mxs_auart_irq_handle+0x380/0x3f4\n [ 85.198787] mxs_auart_irq_handle from __handle_irq_event_percpu+0x88/0x210\n (...)(CVE-2024-27000)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm: nv04: Fix out of bounds access\r\n\r\nWhen Output Resource (dcb-\u0026gt;or) value is assigned in\nfabricate_dcb_output(), there may be out of bounds access to\ndac_users array in case dcb-\u0026gt;or is zero because ffs(dcb-\u0026gt;or) is\nused as index there.\nThe \u0026apos;or\u0026apos; argument of fabricate_dcb_output() must be interpreted as a\nnumber of bit to set, not value.\r\n\r\nUtilize macros from \u0026apos;enum nouveau_or\u0026apos; in calls instead of hardcoding.\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-27008)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Fix a potential buffer overflow in \u0026apos;dp_dsc_clock_en_read()\u0026apos;\r\n\r\nTell snprintf() to store at most 10 bytes in the output buffer\ninstead of 30.\r\n\r\nFixes the below:\ndrivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_debugfs.c:1508 dp_dsc_clock_en_read() error: snprintf() is printing too much 30 vs 10(CVE-2024-27045)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nUSB: usb-storage: Prevent divide-by-0 error in isd200_ata_command\r\n\r\nThe isd200 sub-driver in usb-storage uses the HEADS and SECTORS values\nin the ATA ID information to calculate cylinder and head values when\ncreating a CDB for READ or WRITE commands. The calculation involves\ndivision and modulus operations, which will cause a crash if either of\nthese values is 0. While this never happens with a genuine device, it\ncould happen with a flawed or subversive emulation, as reported by the\nsyzbot fuzzer.\r\n\r\nProtect against this possibility by refusing to bind to the device if\neither the ATA_ID_HEADS or ATA_ID_SECTORS value in the device\u0026apos;s ID\ninformation is 0. This requires isd200_Initialization() to return a\nnegative error code when initialization fails; currently it always\nreturns 0 (even when there is an error).(CVE-2024-27059)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: usbtv: Remove useless locks in usbtv_video_free()\r\n\r\nRemove locks calls in usbtv_video_free() because\nare useless and may led to a deadlock as reported here:\nhttps://syzkaller.appspot.com/x/bisect.txt?x=166dc872180000\nAlso remove usbtv_stop() call since it will be called when\nunregistering the device.\r\n\r\nBefore \u0026apos;c838530d230b\u0026apos; this issue would only be noticed if you\ndisconnect while streaming and now it is noticeable even when\ndisconnecting while not streaming.\r\n\r\n\n[hverkuil: fix minor spelling mistake in log message](CVE-2024-27072)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: ttpci: fix two memleaks in budget_av_attach\r\n\r\nWhen saa7146_register_device and saa7146_vv_init fails, budget_av_attach\nshould free the resources it allocates, like the error-handling of\nttpci_budget_init does. Besides, there are two fixme comment refers to\nsuch deallocations.(CVE-2024-27073)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: dvb-frontends: avoid stack overflow warnings with clang\r\n\r\nA previous patch worked around a KASAN issue in stv0367, now a similar\nproblem showed up with clang:\r\n\r\ndrivers/media/dvb-frontends/stv0367.c:1222:12: error: stack frame size (3624) exceeds limit (2048) in \u0026apos;stv0367ter_set_frontend\u0026apos; [-Werror,-Wframe-larger-than]\n 1214 | static int stv0367ter_set_frontend(struct dvb_frontend *fe)\r\n\r\nRework the stv0367_writereg() function to be simpler and mark both\nregister access functions as noinline_for_stack so the temporary\ni2c_msg structures do not get duplicated on the stack when KASAN_STACK\nis enabled.(CVE-2024-27075)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npstore: inode: Only d_invalidate() is needed\r\n\r\nUnloading a modular pstore backend with records in pstorefs would\ntrigger the dput() double-drop warning:\r\n\r\n WARNING: CPU: 0 PID: 2569 at fs/dcache.c:762 dput.part.0+0x3f3/0x410\r\n\r\nUsing the combo of d_drop()/dput() (as mentioned in\nDocumentation/filesystems/vfs.rst) isn\u0026apos;t the right approach here, and\nleads to the reference counting problem seen above. Use d_invalidate()\nand update the code to not bother checking for error codes that can\nnever happen.\r\n\r\n---(CVE-2024-27389)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfs/ntfs3: Fixed overflow check in mi_enum_attr()(CVE-2024-27407)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetrom: Fix data-races around sysctl_net_busy_read\r\n\r\nWe need to protect the reader reading the sysctl value because the\nvalue can be changed concurrently.(CVE-2024-27419)\r\n\r\nRejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2024-27426)\r\n\r\nRejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2024-27427)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nKVM: SVM: Flush pages under kvm-\u0026gt;lock to fix UAF in svm_register_enc_region()\r\n\r\nDo the cache flush of converted pages in svm_register_enc_region() before\ndropping kvm-\u0026gt;lock to fix use-after-free issues where region and/or its\narray of pages could be freed by a different task, e.g. if userspace has\n__unregister_enc_region_locked() already queued up for the region.\r\n\r\nNote, the \u0026quot;obvious\u0026quot; alternative of using local variables doesn\u0026apos;t fully\nresolve the bug, as region-\u0026gt;pages is also dynamically allocated. I.e. the\nregion structure itself would be fine, but region-\u0026gt;pages could be freed.\r\n\r\nFlushing multiple pages under kvm-\u0026gt;lock is unfortunate, but the entire\nflow is a rare slow path, and the manual flush is only needed on CPUs that\nlack coherency for encrypted memory.(CVE-2024-35791)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\nx86/fpu: Keep xfd_state in sync with MSR_IA32_XFD\nCommit 672365477ae8 (\u0026quot;x86/fpu: Update XFD state where required\u0026quot;) and\ncommit 8bf26758ca96 (\u0026quot;x86/fpu: Add XFD state to fpstate\u0026quot;) introduced a\nper CPU variable xfd_state to keep the MSR_IA32_XFD value cached, in\norder to avoid unnecessary writes to the MSR.\nOn CPU hotplug MSR_IA32_XFD is reset to the init_fpstate.xfd, which\nwipes out any stale state. But the per CPU cached xfd value is not\nreset, which brings them out of sync.\nAs a consequence a subsequent xfd_update_state() might fail to update\nthe MSR which in turn can result in XRSTOR raising a #NM in kernel\nspace, which crashes the kernel.\nTo fix this, introduce xfd_set_state() to write xfd_state together\nwith MSR_IA32_XFD, and use it in all places that set MSR_IA32_XFD.(CVE-2024-35801)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndm snapshot: fix lockup in dm_exception_table_exit\r\n\r\nThere was reported lockup when we exit a snapshot with many exceptions.\nFix this by adding \u0026quot;cond_resched\u0026quot; to the loop that frees the exceptions.(CVE-2024-35805)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsoc: fsl: qbman: Always disable interrupts when taking cgr_lock\r\n\r\nsmp_call_function_single disables IRQs when executing the callback. To\nprevent deadlocks, we must disable IRQs when taking cgr_lock elsewhere.\nThis is already done by qman_update_cgr and qman_delete_cgr; fix the\nother lockers.(CVE-2024-35806)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nLoongArch: Define the __io_aw() hook as mmiowb()\r\n\r\nCommit fb24ea52f78e0d595852e (\u0026quot;drivers: Remove explicit invocations of\nmmiowb()\u0026quot;) remove all mmiowb() in drivers, but it says:\r\n\r\n\u0026quot;NOTE: mmiowb() has only ever guaranteed ordering in conjunction with\nspin_unlock(). However, pairing each mmiowb() removal in this patch with\nthe corresponding call to spin_unlock() is not at all trivial, so there\nis a small chance that this change may regress any drivers incorrectly\nrelying on mmiowb() to order MMIO writes between CPUs using lock-free\nsynchronisation.\u0026quot;\r\n\r\nThe mmio in radeon_ring_commit() is protected by a mutex rather than a\nspinlock, but in the mutex fastpath it behaves similar to spinlock. We\ncan add mmiowb() calls in the radeon driver but the maintainer says he\ndoesn\u0026apos;t like such a workaround, and radeon is not the only example of\nmutex protected mmio.\r\n\r\nSo we should extend the mmiowb tracking system from spinlock to mutex,\nand maybe other locking primitives. This is not easy and error prone, so\nwe solve it in the architectural code, by simply defining the __io_aw()\nhook as mmiowb(). And we no longer need to override queued_spin_unlock()\nso use the generic definition.\r\n\r\nWithout this, we get such an error when run \u0026apos;glxgears\u0026apos; on weak ordering\narchitectures such as LoongArch:\r\n\r\nradeon 0000:04:00.0: ring 0 stalled for more than 10324msec\nradeon 0000:04:00.0: ring 3 stalled for more than 10240msec\nradeon 0000:04:00.0: GPU lockup (current fence id 0x000000000001f412 last fence id 0x000000000001f414 on ring 3)\nradeon 0000:04:00.0: GPU lockup (current fence id 0x000000000000f940 last fence id 0x000000000000f941 on ring 0)\nradeon 0000:04:00.0: scheduling IB failed (-35).\n[drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn\u0026apos;t update BO_VA (-35)\nradeon 0000:04:00.0: scheduling IB failed (-35).\n[drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn\u0026apos;t update BO_VA (-35)\nradeon 0000:04:00.0: scheduling IB failed (-35).\n[drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn\u0026apos;t update BO_VA (-35)\nradeon 0000:04:00.0: scheduling IB failed (-35).\n[drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn\u0026apos;t update BO_VA (-35)\nradeon 0000:04:00.0: scheduling IB failed (-35).\n[drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn\u0026apos;t update BO_VA (-35)\nradeon 0000:04:00.0: scheduling IB failed (-35).\n[drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn\u0026apos;t update BO_VA (-35)\nradeon 0000:04:00.0: scheduling IB failed (-35).\n[drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn\u0026apos;t update BO_VA (-35)(CVE-2024-35818)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/mlx5e: fix a double-free in arfs_create_groups\r\n\r\nWhen `in` allocated by kvzalloc fails, arfs_create_groups will free\nft-\u0026gt;g and return an error. However, arfs_create_table, the only caller of\narfs_create_groups, will hold this error and call to\nmlx5e_destroy_flow_table, in which the ft-\u0026gt;g will be freed again.(CVE-2024-35835)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nf2fs: compress: fix reserve_cblocks counting error when out of space\r\n\r\nWhen a file only needs one direct_node, performing the following\noperations will cause the file to be unrepairable:\r\n\r\nunisoc # ./f2fs_io compress test.apk\nunisoc #df -h | grep dm-48\n/dev/block/dm-48 112G 112G 1.2M 100% /data\r\n\r\nunisoc # ./f2fs_io release_cblocks test.apk\n924\nunisoc # df -h | grep dm-48\n/dev/block/dm-48 112G 112G 4.8M 100% /data\r\n\r\nunisoc # dd if=/dev/random of=file4 bs=1M count=3\n3145728 bytes (3.0 M) copied, 0.025 s, 120 M/s\nunisoc # df -h | grep dm-48\n/dev/block/dm-48 112G 112G 1.8M 100% /data\r\n\r\nunisoc # ./f2fs_io reserve_cblocks test.apk\nF2FS_IOC_RESERVE_COMPRESS_BLOCKS failed: No space left on device\r\n\r\nadb reboot\nunisoc # df -h | grep dm-48\n/dev/block/dm-48 112G 112G 11M 100% /data\nunisoc # ./f2fs_io reserve_cblocks test.apk\n0\r\n\r\nThis is because the file has only one direct_node. After returning\nto -ENOSPC, reserved_blocks += ret will not be executed. As a result,\nthe reserved_blocks at this time is still 0, which is not the real\nnumber of reserved blocks. Therefore, fsck cannot be set to repair\nthe file.\r\n\r\nAfter this patch, the fsck flag will be set to fix this problem.\r\n\r\nunisoc # df -h | grep dm-48\n/dev/block/dm-48 112G 112G 1.8M 100% /data\nunisoc # ./f2fs_io reserve_cblocks test.apk\nF2FS_IOC_RESERVE_COMPRESS_BLOCKS failed: No space left on device\r\n\r\nadb reboot then fsck will be executed\nunisoc # df -h | grep dm-48\n/dev/block/dm-48 112G 112G 11M 100% /data\nunisoc # ./f2fs_io reserve_cblocks test.apk\n924(CVE-2024-35844)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: iwlwifi: dbg-tlv: ensure NUL termination\r\n\r\nThe iwl_fw_ini_debug_info_tlv is used as a string, so we must\nensure the string is terminated correctly before using it.(CVE-2024-35845)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\neeprom: at24: fix memory corruption race condition\r\n\r\nIf the eeprom is not accessible, an nvmem device will be registered, the\nread will fail, and the device will be torn down. If another driver\naccesses the nvmem device after the teardown, it will reference\ninvalid memory.\r\n\r\nMove the failure point before registering the nvmem device.(CVE-2024-35848)\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_flowtable_type_get()\r\n\r\nnft_unregister_flowtable_type() within nf_flow_inet_module_exit() can\nconcurrent with __nft_flowtable_type_get() within nf_tables_newflowtable().\nAnd thhere is not any protection when iterate over nf_tables_flowtables\nlist in __nft_flowtable_type_get(). Therefore, there is pertential\ndata-race of nf_tables_flowtables list entry.\r\n\r\nUse list_for_each_entry_rcu() to iterate over nf_tables_flowtables list\nin __nft_flowtable_type_get(), and use rcu_read_lock() in the caller\nnft_flowtable_type_get() to protect the entire type query process.(CVE-2024-35898)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfbmon: prevent division by zero in fb_videomode_from_videomode()\r\n\r\nThe expression htotal * vtotal can have a zero value on\noverflow. It is necessary to prevent division by zero like in\nfb_var_to_videomode().\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with Svace.(CVE-2024-35922)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: lpfc: Fix possible memory leak in lpfc_rcv_padisc()\r\n\r\nThe call to lpfc_sli4_resume_rpi() in lpfc_rcv_padisc() may return an\nunsuccessful status. In such cases, the elsiocb is not issued, the\ncompletion is not called, and thus the elsiocb resource is leaked.\r\n\r\nCheck return value after calling lpfc_sli4_resume_rpi() and conditionally\nrelease the elsiocb resource.(CVE-2024-35930)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: handle chunk tree lookup error in btrfs_relocate_sys_chunks()\r\n\r\nThe unhandled case in btrfs_relocate_sys_chunks() loop is a corruption,\nas it could be caused only by two impossible conditions:\r\n\r\n- at first the search key is set up to look for a chunk tree item, with\n offset -1, this is an inexact search and the key-\u0026gt;offset will contain\n the correct offset upon a successful search, a valid chunk tree item\n cannot have an offset -1\r\n\r\n- after first successful search, the found_key corresponds to a chunk\n item, the offset is decremented by 1 before the next loop, it\u0026apos;s\n impossible to find a chunk item there due to alignment and size\n constraints(CVE-2024-35936)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npstore/zone: Add a null pointer check to the psz_kmsg_read\r\n\r\nkasprintf() returns a pointer to dynamically allocated memory\nwhich can be NULL upon failure. Ensure the allocation was successful\nby checking the pointer validity.(CVE-2024-35940)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nxsk: validate user input for XDP_{UMEM|COMPLETION}_FILL_RING\r\n\r\nsyzbot reported an illegal copy in xsk_setsockopt() [1]\r\n\r\nMake sure to validate setsockopt() @optlen parameter.\r\n\r\n[1]\r\n\r\n BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline]\n BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline]\n BUG: KASAN: slab-out-of-bounds in xsk_setsockopt+0x909/0xa40 net/xdp/xsk.c:1420\nRead of size 4 at addr ffff888028c6cde3 by task syz-executor.0/7549\r\n\r\nCPU: 0 PID: 7549 Comm: syz-executor.0 Not tainted 6.8.0-syzkaller-08951-gfe46a7dd189e #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114\n print_address_description mm/kasan/report.c:377 [inline]\n print_report+0x169/0x550 mm/kasan/report.c:488\n kasan_report+0x143/0x180 mm/kasan/report.c:601\n copy_from_sockptr_offset include/linux/sockptr.h:49 [inline]\n copy_from_sockptr include/linux/sockptr.h:55 [inline]\n xsk_setsockopt+0x909/0xa40 net/xdp/xsk.c:1420\n do_sock_setsockopt+0x3af/0x720 net/socket.c:2311\n __sys_setsockopt+0x1ae/0x250 net/socket.c:2334\n __do_sys_setsockopt net/socket.c:2343 [inline]\n __se_sys_setsockopt net/socket.c:2340 [inline]\n __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340\n do_syscall_64+0xfb/0x240\n entry_SYSCALL_64_after_hwframe+0x6d/0x75\nRIP: 0033:0x7fb40587de69\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:00007fb40665a0c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000036\nRAX: ffffffffffffffda RBX: 00007fb4059abf80 RCX: 00007fb40587de69\nRDX: 0000000000000005 RSI: 000000000000011b RDI: 0000000000000006\nRBP: 00007fb4058ca47a R08: 0000000000000002 R09: 0000000000000000\nR10: 0000000020001980 R11: 0000000000000246 R12: 0000000000000000\nR13: 000000000000000b R14: 00007fb4059abf80 R15: 00007fff57ee4d08\n \u0026lt;/TASK\u0026gt;\r\n\r\nAllocated by task 7549:\n kasan_save_stack mm/kasan/common.c:47 [inline]\n kasan_save_track+0x3f/0x80 mm/kasan/common.c:68\n poison_kmalloc_redzone mm/kasan/common.c:370 [inline]\n __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:387\n kasan_kmalloc include/linux/kasan.h:211 [inline]\n __do_kmalloc_node mm/slub.c:3966 [inline]\n __kmalloc+0x233/0x4a0 mm/slub.c:3979\n kmalloc include/linux/slab.h:632 [inline]\n __cgroup_bpf_run_filter_setsockopt+0xd2f/0x1040 kernel/bpf/cgroup.c:1869\n do_sock_setsockopt+0x6b4/0x720 net/socket.c:2293\n __sys_setsockopt+0x1ae/0x250 net/socket.c:2334\n __do_sys_setsockopt net/socket.c:2343 [inline]\n __se_sys_setsockopt net/socket.c:2340 [inline]\n __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340\n do_syscall_64+0xfb/0x240\n entry_SYSCALL_64_after_hwframe+0x6d/0x75\r\n\r\nThe buggy address belongs to the object at ffff888028c6cde0\n which belongs to the cache kmalloc-8 of size 8\nThe buggy address is located 1 bytes to the right of\n allocated 2-byte region [ffff888028c6cde0, ffff888028c6cde2)\r\n\r\nThe buggy address belongs to the physical page:\npage:ffffea0000a31b00 refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888028c6c9c0 pfn:0x28c6c\nanon flags: 0xfff00000000800(slab|node=0|zone=1|lastcpupid=0x7ff)\npage_type: 0xffffffff()\nraw: 00fff00000000800 ffff888014c41280 0000000000000000 dead000000000001\nraw: ffff888028c6c9c0 0000000080800057 00000001ffffffff 0000000000000000\npage dumped because: kasan: bad access detected\npage_owner tracks the page as allocated\npage last allocated via order 0, migratetype Unmovable, gfp_mask 0x112cc0(GFP_USER|__GFP_NOWARN|__GFP_NORETRY), pid 6648, tgid 6644 (syz-executor.0), ts 133906047828, free_ts 133859922223\n set_page_owner include/linux/page_owner.h:31 [inline]\n post_alloc_hook+0x1ea/0x210 mm/page_alloc.c:1533\n prep_new_page mm/page_alloc.c:\n---truncated---(CVE-2024-35976)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nHID: i2c-hid: remove I2C_HID_READ_PENDING flag to prevent lock-up\r\n\r\nThe flag I2C_HID_READ_PENDING is used to serialize I2C operations.\nHowever, this is not necessary, because I2C core already has its own\nlocking for that.\r\n\r\nMore importantly, this flag can cause a lock-up: if the flag is set in\ni2c_hid_xfer() and an interrupt happens, the interrupt handler\n(i2c_hid_irq) will check this flag and return immediately without doing\nanything, then the interrupt handler will be invoked again in an\ninfinite loop.\r\n\r\nSince interrupt handler is an RT task, it takes over the CPU and the\nflag-clearing task never gets scheduled, thus we have a lock-up.\r\n\r\nDelete this unnecessary flag.(CVE-2024-35997)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmlxsw: spectrum_acl_tcam: Fix incorrect list API usage\r\n\r\nBoth the function that migrates all the chunks within a region and the\nfunction that migrates all the entries within a chunk call\nlist_first_entry() on the respective lists without checking that the\nlists are not empty. This is incorrect usage of the API, which leads to\nthe following warning [1].\r\n\r\nFix by returning if the lists are empty as there is nothing to migrate\nin this case.\r\n\r\n[1]\nWARNING: CPU: 0 PID: 6437 at drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c:1266 mlxsw_sp_acl_tcam_vchunk_migrate_all+0x1f1/0\u0026gt;\nModules linked in:\nCPU: 0 PID: 6437 Comm: kworker/0:37 Not tainted 6.9.0-rc3-custom-00883-g94a65f079ef6 #39\nHardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019\nWorkqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work\nRIP: 0010:mlxsw_sp_acl_tcam_vchunk_migrate_all+0x1f1/0x2c0\n[...]\nCall Trace:\n \u0026lt;TASK\u0026gt;\n mlxsw_sp_acl_tcam_vregion_rehash_work+0x6c/0x4a0\n process_one_work+0x151/0x370\n worker_thread+0x2cb/0x3e0\n kthread+0xd0/0x100\n ret_from_fork+0x34/0x50\n ret_from_fork_asm+0x1a/0x30\n \u0026lt;/TASK\u0026gt;(CVE-2024-36006)",
"id": "OESA-2024-1680",
"modified": "2026-08-06T11:07:08Z",
"published": "2024-05-31T11:07:08Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1680"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47421"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47455"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48641"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48708"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52650"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52656"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52664"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52683"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52698"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52809"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52813"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52817"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52835"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52837"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52840"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52844"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52847"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52854"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52860"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52863"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52867"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52869"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52876"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52879"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26814"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26923"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26950"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26958"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26961"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26965"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26972"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26976"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26982"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26993"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27000"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27008"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27045"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27059"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27072"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27073"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27075"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27389"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27407"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27419"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27426"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27427"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35791"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35801"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35805"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35806"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35818"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35835"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35844"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35845"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35848"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35898"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35922"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35930"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35936"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35940"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35976"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35997"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36006"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2021-47421",
"CVE-2021-47455",
"CVE-2022-48641",
"CVE-2022-48708",
"CVE-2023-52650",
"CVE-2023-52656",
"CVE-2023-52664",
"CVE-2023-52683",
"CVE-2023-52698",
"CVE-2023-52809",
"CVE-2023-52813",
"CVE-2023-52817",
"CVE-2023-52835",
"CVE-2023-52837",
"CVE-2023-52840",
"CVE-2023-52844",
"CVE-2023-52847",
"CVE-2023-52854",
"CVE-2023-52860",
"CVE-2023-52863",
"CVE-2023-52867",
"CVE-2023-52869",
"CVE-2023-52876",
"CVE-2023-52879",
"CVE-2024-26814",
"CVE-2024-26923",
"CVE-2024-26950",
"CVE-2024-26958",
"CVE-2024-26961",
"CVE-2024-26965",
"CVE-2024-26972",
"CVE-2024-26976",
"CVE-2024-26982",
"CVE-2024-26993",
"CVE-2024-27000",
"CVE-2024-27008",
"CVE-2024-27045",
"CVE-2024-27059",
"CVE-2024-27072",
"CVE-2024-27073",
"CVE-2024-27075",
"CVE-2024-27389",
"CVE-2024-27407",
"CVE-2024-27419",
"CVE-2024-27426",
"CVE-2024-27427",
"CVE-2024-35791",
"CVE-2024-35801",
"CVE-2024-35805",
"CVE-2024-35806",
"CVE-2024-35818",
"CVE-2024-35835",
"CVE-2024-35844",
"CVE-2024-35845",
"CVE-2024-35848",
"CVE-2024-35898",
"CVE-2024-35922",
"CVE-2024-35930",
"CVE-2024-35936",
"CVE-2024-35940",
"CVE-2024-35976",
"CVE-2024-35997",
"CVE-2024-36006"
]
}
OESA-2024-1682 (CVE-2021-47421)
Vulnerability from osv_openeuler – Published: 2024-05-31 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:
drm/amdgpu: handle the case of pci_channel_io_frozen only in amdgpu_pci_resume
In current code, when a PCI error state pci_channel_io_normal is detectd, it will report PCI_ERS_RESULT_CAN_RECOVER status to PCI driver, and PCI driver will continue the execution of PCI resume callback report_resume by pci_walk_bridge, and the callback will go into amdgpu_pci_resume finally, where write lock is releasd unconditionally without acquiring such lock first. In this case, a deadlock will happen when other threads start to acquire the read lock.
To fix this, add a member in amdgpu_device strucutre to cache pci_channel_state, and only continue the execution in amdgpu_pci_resume when it's pci_channel_io_frozen.(CVE-2021-47421)
In the Linux kernel, the following vulnerability has been resolved:
ptp: Fix possible memory leak in ptp_clock_register()
I got memory leak as follows when doing fault injection test:
unreferenced object 0xffff88800906c618 (size 8): comm "i2c-idt82p33931", pid 4421, jiffies 4294948083 (age 13.188s) hex dump (first 8 bytes): 70 74 70 30 00 00 00 00 ptp0.... backtrace: [<00000000312ed458>] __kmalloc_track_caller+0x19f/0x3a0 [<0000000079f6e2ff>] kvasprintf+0xb5/0x150 [<0000000026aae54f>] kvasprintf_const+0x60/0x190 [<00000000f323a5f7>] kobject_set_name_vargs+0x56/0x150 [<000000004e35abdd>] dev_set_name+0xc0/0x100 [<00000000f20cfe25>] ptp_clock_register+0x9f4/0xd30 [ptp] [<000000008bb9f0de>] idt82p33_probe.cold+0x8b6/0x1561 [ptp_idt82p33]
When posix_clock_register() returns an error, the name allocated in dev_set_name() will be leaked, the put_device() should be used to give up the device reference, then the name will be freed in kobject_cleanup() and other memory will be freed in ptp_clock_release().(CVE-2021-47455)
In the Linux kernel, the following vulnerability has been resolved:
net: enetc: deny offload of tc-based TSN features on VF interfaces
TSN features on the ENETC (taprio, cbs, gate, police) are configured through a mix of command BD ring messages and port registers: enetc_port_rd(), enetc_port_wr().
Port registers are a region of the ENETC memory map which are only accessible from the PCIe Physical Function. They are not accessible from the Virtual Functions.
Moreover, attempting to access these registers crashes the kernel:
$ echo 1 > /sys/bus/pci/devices/0000\:00\:00.0/sriov_numvfs pci 0000:00:01.0: [1957:ef00] type 00 class 0x020001 fsl_enetc_vf 0000:00:01.0: Adding to iommu group 15 fsl_enetc_vf 0000:00:01.0: enabling device (0000 -> 0002) fsl_enetc_vf 0000:00:01.0 eno0vf0: renamed from eth0 $ tc qdisc replace dev eno0vf0 root taprio num_tc 8 map 0 1 2 3 4 5 6 7 \ queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 base-time 0 \ sched-entry S 0x7f 900000 sched-entry S 0x80 100000 flags 0x2 Unable to handle kernel paging request at virtual address ffff800009551a08 Internal error: Oops: 96000007 [#1] PREEMPT SMP pc : enetc_setup_tc_taprio+0x170/0x47c lr : enetc_setup_tc_taprio+0x16c/0x47c Call trace: enetc_setup_tc_taprio+0x170/0x47c enetc_setup_tc+0x38/0x2dc taprio_change+0x43c/0x970 taprio_init+0x188/0x1e0 qdisc_create+0x114/0x470 tc_modify_qdisc+0x1fc/0x6c0 rtnetlink_rcv_msg+0x12c/0x390
Split enetc_setup_tc() into separate functions for the PF and for the VF drivers. Also remove enetc_qos.o from being included into enetc-vf.ko, since it serves absolutely no purpose there.(CVE-2022-48645)
In the Linux kernel, the following vulnerability has been resolved:
drm/tegra: dsi: Add missing check for of_find_device_by_node
Add check for the return value of of_find_device_by_node() and return the error if it fails in order to avoid NULL pointer dereference.(CVE-2023-52650)
In the Linux kernel, the following vulnerability has been resolved:
NTB: fix possible name leak in ntb_register_device()
If device_register() fails in ntb_register_device(), the device name allocated by dev_set_name() should be freed. As per the comment in device_register(), callers should use put_device() to give up the reference in the error path. So fix this by calling put_device() in the error path so that the name can be freed in kobject_cleanup().
As a result of this, put_device() in the error path of ntb_register_device() is removed and the actual error is returned.
In the Linux kernel, the following vulnerability has been resolved:
SUNRPC: fix a memleak in gss_import_v2_context
The ctx->mech_used.data allocated by kmemdup is not freed in neither gss_import_v2_context nor it only caller gss_krb5_import_sec_context, which frees ctx on error.
Thus, this patch reform the last call of gss_import_v2_context to the gss_krb5_import_ctx_v2, preventing the memleak while keepping the return formation.(CVE-2023-52653)
In the Linux kernel, the following vulnerability has been resolved:
io_uring: drop any code related to SCM_RIGHTS
This is dead code after we dropped support for passing io_uring fds over SCM_RIGHTS, get rid of it.(CVE-2023-52656)
In the Linux kernel, the following vulnerability has been resolved:
net: atlantic: eliminate double free in error handling logic
Driver has a logic leak in ring data allocation/free, where aq_ring_free could be called multiple times on same ring, if system is under stress and got memory allocation error.
Ring pointer was used as an indicator of failure, but this is not correct since only ring data is allocated/deallocated. Ring itself is an array member.
Changing ring allocation functions to return error code directly. This simplifies error handling and eliminates aq_ring_free on higher layer.(CVE-2023-52664)
In the Linux kernel, the following vulnerability has been resolved:
ALSA: scarlett2: Add clamp() in scarlett2_mixer_ctl_put()
Ensure the value passed to scarlett2_mixer_ctl_put() is between 0 and SCARLETT2_MIXER_MAX_VALUE so we don't attempt to access outside scarlett2_mixer_values[].(CVE-2023-52674)
In the Linux kernel, the following vulnerability has been resolved:
ACPI: LPIT: Avoid u32 multiplication overflow
In lpit_update_residency() there is a possibility of overflow in multiplication, if tsc_khz is large enough (> UINT_MAX/1000).
Change multiplication to mul_u32_u32().
Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2023-52683)
In the Linux kernel, the following vulnerability has been resolved:
calipso: fix memory leak in netlbl_calipso_add_pass()
If IPv6 support is disabled at boot (ipv6.disable=1), the calipso_init() -> netlbl_calipso_ops_register() function isn't called, and the netlbl_calipso_ops_get() function always returns NULL. In this case, the netlbl_calipso_add_pass() function allocates memory for the doi_def variable but doesn't free it with the calipso_doi_free().
BUG: memory leak unreferenced object 0xffff888011d68180 (size 64): comm "syz-executor.1", pid 10746, jiffies 4295410986 (age 17.928s) hex dump (first 32 bytes): 00 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<...>] kmalloc include/linux/slab.h:552 [inline] [<...>] netlbl_calipso_add_pass net/netlabel/netlabel_calipso.c:76 [inline] [<...>] netlbl_calipso_add+0x22e/0x4f0 net/netlabel/netlabel_calipso.c:111 [<...>] genl_family_rcv_msg_doit+0x22f/0x330 net/netlink/genetlink.c:739 [<...>] genl_family_rcv_msg net/netlink/genetlink.c:783 [inline] [<...>] genl_rcv_msg+0x341/0x5a0 net/netlink/genetlink.c:800 [<...>] netlink_rcv_skb+0x14d/0x440 net/netlink/af_netlink.c:2515 [<...>] genl_rcv+0x29/0x40 net/netlink/genetlink.c:811 [<...>] netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline] [<...>] netlink_unicast+0x54b/0x800 net/netlink/af_netlink.c:1339 [<...>] netlink_sendmsg+0x90a/0xdf0 net/netlink/af_netlink.c:1934 [<...>] sock_sendmsg_nosec net/socket.c:651 [inline] [<...>] sock_sendmsg+0x157/0x190 net/socket.c:671 [<...>] _syssendmsg+0x712/0x870 net/socket.c:2342 [<...>] _sys_sendmsg+0xf8/0x170 net/socket.c:2396 [<...>] __sys_sendmsg+0xea/0x1b0 net/socket.c:2429 [<...>] do_syscall_64+0x30/0x40 arch/x86/entry/common.c:46 [<...>] entry_SYSCALL_64_after_hwframe+0x61/0xc6
Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with Syzkaller
PM: merged via the LSM tree at Jakub Kicinski request
In the Linux kernel, the following vulnerability has been resolved:
fs/jfs: Add validity check for db_maxag and db_agpref
Both db_maxag and db_agpref are used as the index of the db_agfree array, but there is currently no validity check for db_maxag and db_agpref, which can lead to errors.
The following is related bug reported by Syzbot:
UBSAN: array-index-out-of-bounds in fs/jfs/jfs_dmap.c:639:20 index 7936 is out of range for type 'atomic_t[128]'
Add checking that the values of db_maxag and db_agpref are valid indexes for the db_agfree array.(CVE-2023-52804)
In the Linux kernel, the following vulnerability has been resolved:
jfs: fix array-index-out-of-bounds in diAlloc
Currently there is not check against the agno of the iag while allocating new inodes to avoid fragmentation problem. Added the check which is required.(CVE-2023-52805)
In the Linux kernel, the following vulnerability has been resolved:
scsi: libfc: Fix potential NULL pointer dereference in fc_lport_ptp_setup()
fc_lport_ptp_setup() did not check the return value of fc_rport_create() which can return NULL and would cause a NULL pointer dereference. Address this issue by checking return value of fc_rport_create() and log error message on fc_rport_create() failed.(CVE-2023-52809)
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Fix a null pointer access when the smc_rreg pointer is NULL
In certain types of chips, such as VEGA20, reading the amdgpu_regs_smc file could result in an abnormal null pointer access when the smc_rreg pointer is NULL. Below are the steps to reproduce this issue and the corresponding exception log:
- Navigate to the directory: /sys/kernel/debug/dri/0
- Execute command: cat amdgpu_regs_smc
- Exception Log:: [4005007.702554] BUG: kernel NULL pointer dereference, address: 0000000000000000 [4005007.702562] #PF: supervisor instruction fetch in kernel mode [4005007.702567] #PF: error_code(0x0010) - not-present page [4005007.702570] PGD 0 P4D 0 [4005007.702576] Oops: 0010 [#1] SMP NOPTI [4005007.702581] CPU: 4 PID: 62563 Comm: cat Tainted: G OE 5.15.0-43-generic #46-Ubunt u [4005007.702590] RIP: 0010:0x0 [4005007.702598] Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6. [4005007.702600] RSP: 0018:ffffa82b46d27da0 EFLAGS: 00010206 [4005007.702605] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffa82b46d27e68 [4005007.702609] RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff9940656e0000 [4005007.702612] RBP: ffffa82b46d27dd8 R08: 0000000000000000 R09: ffff994060c07980 [4005007.702615] R10: 0000000000020000 R11: 0000000000000000 R12: 00007f5e06753000 [4005007.702618] R13: ffff9940656e0000 R14: ffffa82b46d27e68 R15: 00007f5e06753000 [4005007.702622] FS: 00007f5e0755b740(0000) GS:ffff99479d300000(0000) knlGS:0000000000000000 [4005007.702626] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [4005007.702629] CR2: ffffffffffffffd6 CR3: 00000003253fc000 CR4: 00000000003506e0 [4005007.702633] Call Trace: [4005007.702636] <TASK> [4005007.702640] amdgpu_debugfs_regs_smc_read+0xb0/0x120 [amdgpu] [4005007.703002] full_proxy_read+0x5c/0x80 [4005007.703011] vfs_read+0x9f/0x1a0 [4005007.703019] ksys_read+0x67/0xe0 [4005007.703023] __x64_sys_read+0x19/0x20 [4005007.703028] do_syscall_64+0x5c/0xc0 [4005007.703034] ? do_user_addr_fault+0x1e3/0x670 [4005007.703040] ? exit_to_user_mode_prepare+0x37/0xb0 [4005007.703047] ? irqentry_exit_to_user_mode+0x9/0x20 [4005007.703052] ? irqentry_exit+0x19/0x30 [4005007.703057] ? exc_page_fault+0x89/0x160 [4005007.703062] ? asm_exc_page_fault+0x8/0x30 [4005007.703068] entry_SYSCALL_64_after_hwframe+0x44/0xae [4005007.703075] RIP: 0033:0x7f5e07672992 [4005007.703079] Code: c0 e9 b2 fe ff ff 50 48 8d 3d fa b2 0c 00 e8 c5 1d 02 00 0f 1f 44 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 0f 05 <48> 3d 00 f0 ff ff 77 56 c3 0f 1f 44 00 00 48 83 e c 28 48 89 54 24 [4005007.703083] RSP: 002b:00007ffe03097898 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 [4005007.703088] RAX: ffffffffffffffda RBX: 0000000000020000 RCX: 00007f5e07672992 [4005007.703091] RDX: 0000000000020000 RSI: 00007f5e06753000 RDI: 0000000000000003 [4005007.703094] RBP: 00007f5e06753000 R08: 00007f5e06752010 R09: 00007f5e06752010 [4005007.703096] R10: 0000000000000022 R11: 0000000000000246 R12: 0000000000022000 [4005007.703099] R13: 0000000000000003 R14: 0000000000020000 R15: 0000000000020000 [4005007.703105] </TASK> [4005007.703107] Modules linked in: nf_tables libcrc32c nfnetlink algif_hash af_alg binfmt_misc nls_ iso8859_1 ipmi_ssif ast intel_rapl_msr intel_rapl_common drm_vram_helper drm_ttm_helper amd64_edac t tm edac_mce_amd kvm_amd ccp mac_hid k10temp kvm acpi_ipmi ipmi_si rapl sch_fq_codel ipmi_devintf ipm i_msghandler msr parport_pc ppdev lp parport mtd pstore_blk efi_pstore ramoops pstore_zone reed_solo mon ip_tables x_tables autofs4 ib_uverbs ib_core amdgpu(OE) amddrm_ttm_helper(OE) amdttm(OE) iommu_v 2 amd_sched(OE) amdkcl(OE) drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops cec rc_core drm igb ahci xhci_pci libahci i2c_piix4 i2c_algo_bit xhci_pci_renesas dca [4005007.703184] CR2: 0000000000000000 [4005007.703188] ---[ en ---truncated---(CVE-2023-52817)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd: Fix UBSAN array-index-out-of-bounds for SMU7
For pptable structs that use flexible array sizes, use flexible arrays.(CVE-2023-52818)
In the Linux kernel, the following vulnerability has been resolved:
perf/core: Bail out early if the request AUX area is out of bound
When perf-record with a large AUX area, e.g 4GB, it fails with:
#perf record -C 0 -m ,4G -e arm_spe_0// -- sleep 1
failed to mmap with 12 (Cannot allocate memory)
and it reveals a WARNING with __alloc_pages():
------------[ cut here ]------------
WARNING: CPU: 44 PID: 17573 at mm/page_alloc.c:5568 __alloc_pages+0x1ec/0x248
Call trace:
__alloc_pages+0x1ec/0x248
__kmalloc_large_node+0xc0/0x1f8
__kmalloc_node+0x134/0x1e8
rb_alloc_aux+0xe0/0x298
perf_mmap+0x440/0x660
mmap_region+0x308/0x8a8
do_mmap+0x3c0/0x528
vm_mmap_pgoff+0xf4/0x1b8
ksys_mmap_pgoff+0x18c/0x218
__arm64_sys_mmap+0x38/0x58
invoke_syscall+0x50/0x128
el0_svc_common.constprop.0+0x58/0x188
do_el0_svc+0x34/0x50
el0_svc+0x34/0x108
el0t_64_sync_handler+0xb8/0xc0
el0t_64_sync+0x1a4/0x1a8
'rb->aux_pages' allocated by kcalloc() is a pointer array which is used to maintains AUX trace pages. The allocated page for this array is physically contiguous (and virtually contiguous) with an order of 0..MAX_ORDER. If the size of pointer array crosses the limitation set by MAX_ORDER, it reveals a WARNING.
So bail out early with -ENOMEM if the request AUX area is out of bound, e.g.:
#perf record -C 0 -m ,4G -e arm_spe_0// -- sleep 1
failed to mmap with 12 (Cannot allocate memory)(CVE-2023-52835)
In the Linux kernel, the following vulnerability has been resolved:
Input: synaptics-rmi4 - fix use after free in rmi_unregister_function()
The put_device() calls rmi_release_function() which frees "fn" so the dereference on the next line "fn->num_of_irqs" is a use after free. Move the put_device() to the end to fix this.(CVE-2023-52840)
In the Linux kernel, the following vulnerability has been resolved:
media: vidtv: psi: Add check for kstrdup
Add check for the return value of kstrdup() and return the error if it fails in order to avoid NULL pointer dereference.(CVE-2023-52844)
In the Linux kernel, the following vulnerability has been resolved:
tipc: Change nla_policy for bearer-related names to NLA_NUL_STRING
syzbot reported the following uninit-value access issue [1]:
===================================================== BUG: KMSAN: uninit-value in strlen lib/string.c:418 [inline] BUG: KMSAN: uninit-value in strstr+0xb8/0x2f0 lib/string.c:756 strlen lib/string.c:418 [inline] strstr+0xb8/0x2f0 lib/string.c:756 tipc_nl_node_reset_link_stats+0x3ea/0xb50 net/tipc/node.c:2595 genl_family_rcv_msg_doit net/netlink/genetlink.c:971 [inline] genl_family_rcv_msg net/netlink/genetlink.c:1051 [inline] genl_rcv_msg+0x11ec/0x1290 net/netlink/genetlink.c:1066 netlink_rcv_skb+0x371/0x650 net/netlink/af_netlink.c:2545 genl_rcv+0x40/0x60 net/netlink/genetlink.c:1075 netlink_unicast_kernel net/netlink/af_netlink.c:1342 [inline] netlink_unicast+0xf47/0x1250 net/netlink/af_netlink.c:1368 netlink_sendmsg+0x1238/0x13d0 net/netlink/af_netlink.c:1910 sock_sendmsg_nosec net/socket.c:730 [inline] sock_sendmsg net/socket.c:753 [inline] _syssendmsg+0x9c2/0xd60 net/socket.c:2541 _sys_sendmsg+0x28d/0x3c0 net/socket.c:2595 __sys_sendmsg net/socket.c:2624 [inline] __do_sys_sendmsg net/socket.c:2633 [inline] __se_sys_sendmsg net/socket.c:2631 [inline] __x64_sys_sendmsg+0x307/0x490 net/socket.c:2631 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd
Uninit was created at: slab_post_alloc_hook+0x12f/0xb70 mm/slab.h:767 slab_alloc_node mm/slub.c:3478 [inline] kmem_cache_alloc_node+0x577/0xa80 mm/slub.c:3523 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:559 __alloc_skb+0x318/0x740 net/core/skbuff.c:650 alloc_skb include/linux/skbuff.h:1286 [inline] netlink_alloc_large_skb net/netlink/af_netlink.c:1214 [inline] netlink_sendmsg+0xb34/0x13d0 net/netlink/af_netlink.c:1885 sock_sendmsg_nosec net/socket.c:730 [inline] sock_sendmsg net/socket.c:753 [inline] _syssendmsg+0x9c2/0xd60 net/socket.c:2541 _sys_sendmsg+0x28d/0x3c0 net/socket.c:2595 __sys_sendmsg net/socket.c:2624 [inline] __do_sys_sendmsg net/socket.c:2633 [inline] __se_sys_sendmsg net/socket.c:2631 [inline] __x64_sys_sendmsg+0x307/0x490 net/socket.c:2631 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd
TIPC bearer-related names including link names must be null-terminated strings. If a link name which is not null-terminated is passed through netlink, strstr() and similar functions can cause buffer overrun. This causes the above issue.
This patch changes the nla_policy for bearer-related names from NLA_STRING to NLA_NUL_STRING. This resolves the issue by ensuring that only null-terminated strings are accepted as bearer-related names.
syzbot reported similar uninit-value issue related to bearer names [2]. The root cause of this issue is that a non-null-terminated bearer name was passed. This patch also resolved this issue.(CVE-2023-52845)
In the Linux kernel, the following vulnerability has been resolved:
hsr: Prevent use after free in prp_create_tagged_frame()
The prp_fill_rct() function can fail. In that situation, it frees the skb and returns NULL. Meanwhile on the success path, it returns the original skb. So it's straight forward to fix bug by using the returned value.(CVE-2023-52846)
In the Linux kernel, the following vulnerability has been resolved:
media: bttv: fix use after free error due to btv->timeout timer
There may be some a race condition between timer function bttv_irq_timeout and bttv_remove. The timer is setup in probe and there is no timer_delete operation in remove function. When it hit kfree btv, the function might still be invoked, which will cause use after free bug.
This bug is found by static analysis, it may be false positive.
Fix it by adding del_timer_sync invoking to the remove function.
cpu0 cpu1 bttv_probe ->timer_setup ->bttv_set_dma ->mod_timer; bttv_remove ->kfree(btv); ->bttv_irq_timeout ->USE btv(CVE-2023-52847)
In the Linux kernel, the following vulnerability has been resolved:
padata: Fix refcnt handling in padata_free_shell()
In a high-load arm64 environment, the pcrypt_aead01 test in LTP can lead to system UAF (Use-After-Free) issues. Due to the lengthy analysis of the pcrypt_aead01 function call, I'll describe the problem scenario using a simplified model:
Suppose there's a user of padata named user_function that adheres to
the padata requirement of calling padata_free_shell after serial()
has been invoked, as demonstrated in the following code:
struct request {
struct padata_priv padata;
struct completion *done;
};
void parallel(struct padata_priv *padata) {
do_something();
}
void serial(struct padata_priv *padata) {
struct request *request = container_of(padata,
struct request,
padata);
complete(request->done);
}
void user_function() {
DECLARE_COMPLETION(done)
padata->parallel = parallel;
padata->serial = serial;
padata_do_parallel();
wait_for_completion(&done);
padata_free_shell();
}
In the corresponding padata.c file, there's the following code:
static void padata_serial_worker(struct work_struct *serial_work) {
...
cnt = 0;
while (!list_empty(&local_list)) {
...
padata->serial(padata);
cnt++;
}
local_bh_enable();
if (refcount_sub_and_test(cnt, &pd->refcnt))
padata_free_pd(pd);
}
Because of the high system load and the accumulation of unexecuted
softirq at this moment, local_bh_enable() in padata takes longer
to execute than usual. Subsequently, when accessing pd->refcnt,
pd has already been released by padata_free_shell(), resulting
in a UAF issue with pd->refcnt.
The fix is straightforward: add refcount_dec_and_test before calling
padata_free_pd in padata_free_shell.(CVE-2023-52854)
In the Linux kernel, the following vulnerability has been resolved:
clk: mediatek: clk-mt7629: Add check for mtk_alloc_clk_data
Add the check for the return value of mtk_alloc_clk_data() in order to avoid NULL pointer dereference.(CVE-2023-52858)
In the Linux kernel, the following vulnerability has been resolved:
hwmon: (axi-fan-control) Fix possible NULL pointer dereference
axi_fan_control_irq_handler(), dependent on the private axi_fan_control_data structure, might be called before the hwmon device is registered. That will cause an "Unable to handle kernel NULL pointer dereference" error.(CVE-2023-52863)
In the Linux kernel, the following vulnerability has been resolved:
drm/radeon: possible buffer overflow
Buffer 'afmt_status' of size 6 could overflow, since index 'afmt_idx' is checked after access.(CVE-2023-52867)
In the Linux kernel, the following vulnerability has been resolved:
thermal: core: prevent potential string overflow
The dev->id value comes from ida_alloc() so it's a number between zero and INT_MAX. If it's too high then these sprintf()s will overflow.(CVE-2023-52868)
In the Linux kernel, the following vulnerability has been resolved:
pstore/platform: Add check for kstrdup
Add check for the return value of kstrdup() and return the error if it fails in order to avoid NULL pointer dereference.(CVE-2023-52869)
In the Linux kernel, the following vulnerability has been resolved:
clk: mediatek: clk-mt7629-eth: 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-52876)
In the Linux kernel, the following vulnerability has been resolved:
tracing: Have trace_event_file have ref counters
The following can crash the kernel:
# cd /sys/kernel/tracing # echo 'p:sched schedule' > kprobe_events # exec 5>>events/kprobes/sched/enable # > kprobe_events # exec 5>&-
The above commands:
- Change directory to the tracefs directory
- Create a kprobe event (doesn't matter what one)
- Open bash file descriptor 5 on the enable file of the kprobe event
- Delete the kprobe event (removes the files too)
- Close the bash file descriptor 5
The above causes a crash!
BUG: kernel NULL pointer dereference, address: 0000000000000028 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 6 PID: 877 Comm: bash Not tainted 6.5.0-rc4-test-00008-g2c6b6b1029d4-dirty #186 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 RIP: 0010:tracing_release_file_tr+0xc/0x50
What happens here is that the kprobe event creates a trace_event_file "file" descriptor that represents the file in tracefs to the event. It maintains state of the event (is it enabled for the given instance?). Opening the "enable" file gets a reference to the event "file" descriptor via the open file descriptor. When the kprobe event is deleted, the file is also deleted from the tracefs system which also frees the event "file" descriptor.
But as the tracefs file is still opened by user space, it will not be totally removed until the final dput() is called on it. But this is not true with the event "file" descriptor that is already freed. If the user does a write to or simply closes the file descriptor it will reference the event "file" descriptor that was just freed, causing a use-after-free bug.
To solve this, add a ref count to the event "file" descriptor as well as a new flag called "FREED". The "file" will not be freed until the last reference is released. But the FREE flag will be set when the event is removed to prevent any more modifications to that event from happening, even if there's still a reference to the event "file" descriptor.(CVE-2023-52879)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: mark set as dead when unbinding anonymous set with timeout
While the rhashtable set gc runs asynchronously, a race allows it to collect elements from anonymous sets with timeouts while it is being released from the commit path.
Mingi Cho originally reported this issue in a different path in 6.1.x with a pipapo set with low timeouts which is not possible upstream since 7395dfacfff6 ("netfilter: nf_tables: use timestamp to check for set element timeout").
Fix this by setting on the dead flag for anonymous sets to skip async gc in this case.
According to 08e4c8c5919f ("netfilter: nf_tables: mark newset as dead on transaction abort"), Florian plans to accelerate abort path by releasing objects via workqueue, therefore, this sets on the dead flag for abort path too.(CVE-2024-26643)
In the Linux kernel, the following vulnerability has been resolved:
wireguard: netlink: access device through ctx instead of peer
The previous commit fixed a bug that led to a NULL peer->device being dereferenced. It's actually easier and faster performance-wise to instead get the device from ctx->wg. This semantically makes more sense too, since ctx->wg->peer_allowedips.seq is compared with ctx->allowedips_seq, basing them both in ctx. This also acts as a defence in depth provision against freed peers.(CVE-2024-26950)
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: prevent kernel bug at submit_bh_wbc()
Fix a bug where nilfs_get_block() returns a successful status when searching and inserting the specified block both fail inconsistently. If this inconsistent behavior is not due to a previously fixed bug, then an unexpected race is occurring, so return a temporary error -EAGAIN instead.
This prevents callers such as __block_write_begin_int() from requesting a read into a buffer that is not mapped, which would cause the BUG_ON check for the BH_Mapped flag in submit_bh_wbc() to fail.(CVE-2024-26955)
In the Linux kernel, the following vulnerability has been resolved:
s390/zcrypt: fix reference counting on zcrypt card objects
Tests with hot-plugging crytpo cards on KVM guests with debug kernel build revealed an use after free for the load field of the struct zcrypt_card. The reason was an incorrect reference handling of the zcrypt card object which could lead to a free of the zcrypt card object while it was still in use.
This is an example of the slab message:
kernel: 0x00000000885a7512-0x00000000885a7513 @offset=1298. First byte 0x68 instead of 0x6b
kernel: Allocated in zcrypt_card_alloc+0x36/0x70 [zcrypt] age=18046 cpu=3 pid=43
kernel: kmalloc_trace+0x3f2/0x470
kernel: zcrypt_card_alloc+0x36/0x70 [zcrypt]
kernel: zcrypt_cex4_card_probe+0x26/0x380 [zcrypt_cex4]
kernel: ap_device_probe+0x15c/0x290
kernel: really_probe+0xd2/0x468
kernel: driver_probe_device+0x40/0xf0
kernel: __device_attach_driver+0xc0/0x140
kernel: bus_for_each_drv+0x8c/0xd0
kernel: __device_attach+0x114/0x198
kernel: bus_probe_device+0xb4/0xc8
kernel: device_add+0x4d2/0x6e0
kernel: ap_scan_adapter+0x3d0/0x7c0
kernel: ap_scan_bus+0x5a/0x3b0
kernel: ap_scan_bus_wq_callback+0x40/0x60
kernel: process_one_work+0x26e/0x620
kernel: worker_thread+0x21c/0x440
kernel: Freed in zcrypt_card_put+0x54/0x80 [zcrypt] age=9024 cpu=3 pid=43
kernel: kfree+0x37e/0x418
kernel: zcrypt_card_put+0x54/0x80 [zcrypt]
kernel: ap_device_remove+0x4c/0xe0
kernel: device_release_driver_internal+0x1c4/0x270
kernel: bus_remove_device+0x100/0x188
kernel: device_del+0x164/0x3c0
kernel: device_unregister+0x30/0x90
kernel: ap_scan_adapter+0xc8/0x7c0
kernel: ap_scan_bus+0x5a/0x3b0
kernel: ap_scan_bus_wq_callback+0x40/0x60
kernel: process_one_work+0x26e/0x620
kernel: worker_thread+0x21c/0x440
kernel: kthread+0x150/0x168
kernel: __ret_from_fork+0x3c/0x58
kernel: ret_from_fork+0xa/0x30
kernel: Slab 0x00000372022169c0 objects=20 used=18 fp=0x00000000885a7c88 flags=0x3ffff00000000a00(workingset|slab|node=0|zone=1|lastcpupid=0x1ffff)
kernel: Object 0x00000000885a74b8 @offset=1208 fp=0x00000000885a7c88
kernel: Redzone 00000000885a74b0: bb bb bb bb bb bb bb bb ........
kernel: Object 00000000885a74b8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
kernel: Object 00000000885a74c8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
kernel: Object 00000000885a74d8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
kernel: Object 00000000885a74e8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
kernel: Object 00000000885a74f8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
kernel: Object 00000000885a7508: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 68 4b 6b 6b 6b a5 kkkkkkkkkkhKkkk.
kernel: Redzone 00000000885a7518: bb bb bb bb bb bb bb bb ........
kernel: Padding 00000000885a756c: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZ
kernel: CPU: 0 PID: 387 Comm: systemd-udevd Not tainted 6.8.0-HF #2
kernel: Hardware name: IBM 3931 A01 704 (KVM/Linux)
kernel: Call Trace:
kernel: [<00000000ca5ab5b8>] dump_stack_lvl+0x90/0x120
kernel: [<00000000c99d78bc>] check_bytes_and_report+0x114/0x140
kernel: [<00000000c99d53cc>] check_object+0x334/0x3f8
kernel: [<00000000c99d820c>] alloc_debug_processing+0xc4/0x1f8
kernel: [<00000000c99d852e>] get_partial_node.part.0+0x1ee/0x3e0
kernel: [<00000000c99d94ec>] ___slab_alloc+0xaf4/0x13c8
kernel: [<00000000c99d9e38>] __slab_alloc.constprop.0+0x78/0xb8
kernel: [<00000000c99dc8dc>] __kmalloc+0x434/0x590
kernel: [<00000000c9b4c0ce>] ext4_htree_store_dirent+0x4e/0x1c0
kernel: [<00000000c9b908a2>] htree_dirblock_to_tree+0x17a/0x3f0
kernel:
---truncated---(CVE-2024-26957)
In the Linux kernel, the following vulnerability has been resolved:
nfs: fix UAF in direct writes
In production we have been hitting the following warning consistently
------------[ cut here ]------------ refcount_t: underflow; use-after-free. WARNING: CPU: 17 PID: 1800359 at lib/refcount.c:28 refcount_warn_saturate+0x9c/0xe0 Workqueue: nfsiod nfs_direct_write_schedule_work [nfs] RIP: 0010:refcount_warn_saturate+0x9c/0xe0 PKRU: 55555554 Call Trace: <TASK> ? __warn+0x9f/0x130 ? refcount_warn_saturate+0x9c/0xe0 ? report_bug+0xcc/0x150 ? handle_bug+0x3d/0x70 ? exc_invalid_op+0x16/0x40 ? asm_exc_invalid_op+0x16/0x20 ? refcount_warn_saturate+0x9c/0xe0 nfs_direct_write_schedule_work+0x237/0x250 [nfs] process_one_work+0x12f/0x4a0 worker_thread+0x14e/0x3b0 ? ZSTD_getCParams_internal+0x220/0x220 kthread+0xdc/0x120 ? __btf_name_valid+0xa0/0xa0 ret_from_fork+0x1f/0x30
This is because we're completing the nfs_direct_request twice in a row.
The source of this is when we have our commit requests to submit, we process them and send them off, and then in the completion path for the commit requests we have
if (nfs_commit_end(cinfo.mds)) nfs_direct_write_complete(dreq);
However since we're submitting asynchronous requests we sometimes have one that completes before we submit the next one, so we end up calling complete on the nfs_direct_request twice.
The only other place we use nfs_generic_commit_list() is in __nfs_commit_inode, which wraps this call in a
nfs_commit_begin(); nfs_commit_end();
Which is a common pattern for this style of completion handling, one that is also repeated in the direct code with get_dreq()/put_dreq() calls around where we process events as well as in the completion paths.
Fix this by using the same pattern for the commit requests.
Before with my 200 node rocksdb stress running this warning would pop every 10ish minutes. With my patch the stress test has been running for several hours without popping.(CVE-2024-26958)
In the Linux kernel, the following vulnerability has been resolved:
mac802154: fix llsec key resources release in mac802154_llsec_key_del
mac802154_llsec_key_del() can free resources of a key directly without following the RCU rules for waiting before the end of a grace period. This may lead to use-after-free in case llsec_lookup_key() is traversing the list of keys in parallel with a key deletion:
refcount_t: addition on 0; use-after-free. WARNING: CPU: 4 PID: 16000 at lib/refcount.c:25 refcount_warn_saturate+0x162/0x2a0 Modules linked in: CPU: 4 PID: 16000 Comm: wpan-ping Not tainted 6.7.0 #19 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 RIP: 0010:refcount_warn_saturate+0x162/0x2a0 Call Trace: <TASK> llsec_lookup_key.isra.0+0x890/0x9e0 mac802154_llsec_encrypt+0x30c/0x9c0 ieee802154_subif_start_xmit+0x24/0x1e0 dev_hard_start_xmit+0x13e/0x690 sch_direct_xmit+0x2ae/0xbc0 __dev_queue_xmit+0x11dd/0x3c20 dgram_sendmsg+0x90b/0xd60 __sys_sendto+0x466/0x4c0 __x64_sys_sendto+0xe0/0x1c0 do_syscall_64+0x45/0xf0 entry_SYSCALL_64_after_hwframe+0x6e/0x76
Also, ieee802154_llsec_key_entry structures are not freed by mac802154_llsec_key_del():
unreferenced object 0xffff8880613b6980 (size 64): comm "iwpan", pid 2176, jiffies 4294761134 (age 60.475s) hex dump (first 32 bytes): 78 0d 8f 18 80 88 ff ff 22 01 00 00 00 00 ad de x......."....... 00 00 00 00 00 00 00 00 03 00 cd ab 00 00 00 00 ................ backtrace: [<ffffffff81dcfa62>] __kmem_cache_alloc_node+0x1e2/0x2d0 [<ffffffff81c43865>] kmalloc_trace+0x25/0xc0 [<ffffffff88968b09>] mac802154_llsec_key_add+0xac9/0xcf0 [<ffffffff8896e41a>] ieee802154_add_llsec_key+0x5a/0x80 [<ffffffff8892adc6>] nl802154_add_llsec_key+0x426/0x5b0 [<ffffffff86ff293e>] genl_family_rcv_msg_doit+0x1fe/0x2f0 [<ffffffff86ff46d1>] genl_rcv_msg+0x531/0x7d0 [<ffffffff86fee7a9>] netlink_rcv_skb+0x169/0x440 [<ffffffff86ff1d88>] genl_rcv+0x28/0x40 [<ffffffff86fec15c>] netlink_unicast+0x53c/0x820 [<ffffffff86fecd8b>] netlink_sendmsg+0x93b/0xe60 [<ffffffff86b91b35>] _syssendmsg+0xac5/0xca0 [<ffffffff86b9c3dd>] _sys_sendmsg+0x11d/0x1c0 [<ffffffff86b9c65a>] __sys_sendmsg+0xfa/0x1d0 [<ffffffff88eadbf5>] do_syscall_64+0x45/0xf0 [<ffffffff890000ea>] entry_SYSCALL_64_after_hwframe+0x6e/0x76
Handle the proper resource release in the RCU callback function mac802154_llsec_key_del_rcu().
Note that if llsec_lookup_key() finds a key, it gets a refcount via llsec_key_get() and locally copies key id from key_entry (which is a list element). So it's safe to call llsec_key_put() and free the list entry after the RCU grace period elapses.
Found by Linux Verification Center (linuxtesting.org).(CVE-2024-26961)
In the Linux kernel, the following vulnerability has been resolved:
clk: qcom: mmcc-msm8974: fix terminating of frequency table arrays
The frequency table arrays are supposed to be terminated with an empty element. Add such entry to the end of the arrays where it is missing in order to avoid possible out-of-bound access when the table is traversed by functions like qcom_find_freq() or qcom_find_freq_floor().
Only compile tested.(CVE-2024-26965)
In the Linux kernel, the following vulnerability has been resolved:
ubifs: ubifs_symlink: Fix memleak of inode->i_link in error path
For error handling path in ubifs_symlink(), inode will be marked as bad first, then iput() is invoked. If inode->i_link is initialized by fscrypt_encrypt_symlink() in encryption scenario, inode->i_link won't be freed by callchain ubifs_free_inode -> fscrypt_free_inode in error handling path, because make_bad_inode() has changed 'inode->i_mode' as 'S_IFREG'. Following kmemleak is easy to be reproduced by injecting error in ubifs_jnl_update() when doing symlink in encryption scenario: unreferenced object 0xffff888103da3d98 (size 8): comm "ln", pid 1692, jiffies 4294914701 (age 12.045s) backtrace: kmemdup+0x32/0x70 __fscrypt_encrypt_symlink+0xed/0x1c0 ubifs_symlink+0x210/0x300 [ubifs] vfs_symlink+0x216/0x360 do_symlinkat+0x11a/0x190 do_syscall_64+0x3b/0xe0 There are two ways fixing it: 1. Remove make_bad_inode() in error handling path. We can do that because ubifs_evict_inode() will do same processes for good symlink inode and bad symlink inode, for inode->i_nlink checking is before is_bad_inode(). 2. Free inode->i_link before marking inode bad. Method 2 is picked, it has less influence, personally, I think.(CVE-2024-26972)
In the Linux kernel, the following vulnerability has been resolved:
KVM: Always flush async #PF workqueue when vCPU is being destroyed
Always flush the per-vCPU async #PF workqueue when a vCPU is clearing its completion queue, e.g. when a VM and all its vCPUs is being destroyed. KVM must ensure that none of its workqueue callbacks is running when the last reference to the KVM module is put. Gifting a reference to the associated VM prevents the workqueue callback from dereferencing freed vCPU/VM memory, but does not prevent the KVM module from being unloaded before the callback completes.
Drop the misguided VM refcount gifting, as calling kvm_put_kvm() from async_pf_execute() if kvm_put_kvm() flushes the async #PF workqueue will result in deadlock. async_pf_execute() can't return until kvm_put_kvm() finishes, and kvm_put_kvm() can't return until async_pf_execute() finishes:
WARNING: CPU: 8 PID: 251 at virt/kvm/kvm_main.c:1435 kvm_put_kvm+0x2d/0x320 [kvm] Modules linked in: vhost_net vhost vhost_iotlb tap kvm_intel kvm irqbypass CPU: 8 PID: 251 Comm: kworker/8:1 Tainted: G W 6.6.0-rc1-e7af8d17224a-x86/gmem-vm #119 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Workqueue: events async_pf_execute [kvm] RIP: 0010:kvm_put_kvm+0x2d/0x320 [kvm] Call Trace: <TASK> async_pf_execute+0x198/0x260 [kvm] process_one_work+0x145/0x2d0 worker_thread+0x27e/0x3a0 kthread+0xba/0xe0 ret_from_fork+0x2d/0x50 ret_from_fork_asm+0x11/0x20 </TASK> ---[ end trace 0000000000000000 ]--- INFO: task kworker/8:1:251 blocked for more than 120 seconds. Tainted: G W 6.6.0-rc1-e7af8d17224a-x86/gmem-vm #119 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/8:1 state:D stack:0 pid:251 ppid:2 flags:0x00004000 Workqueue: events async_pf_execute [kvm] Call Trace: <TASK> __schedule+0x33f/0xa40 schedule+0x53/0xc0 schedule_timeout+0x12a/0x140 __wait_for_common+0x8d/0x1d0 __flush_work.isra.0+0x19f/0x2c0 kvm_clear_async_pf_completion_queue+0x129/0x190 [kvm] kvm_arch_destroy_vm+0x78/0x1b0 [kvm] kvm_put_kvm+0x1c1/0x320 [kvm] async_pf_execute+0x198/0x260 [kvm] process_one_work+0x145/0x2d0 worker_thread+0x27e/0x3a0 kthread+0xba/0xe0 ret_from_fork+0x2d/0x50 ret_from_fork_asm+0x11/0x20 </TASK>
If kvm_clear_async_pf_completion_queue() actually flushes the workqueue, then there's no need to gift async_pf_execute() a reference because all invocations of async_pf_execute() will be forced to complete before the vCPU and its VM are destroyed/freed. And that in turn fixes the module unloading bug as __fput() won't do module_put() on the last vCPU reference until the vCPU has been freed, e.g. if closing the vCPU file also puts the last reference to the KVM module.
Note that kvm_check_async_pf_completion() may also take the work item off the completion queue and so also needs to flush the work queue, as the work will not be seen by kvm_clear_async_pf_completion_queue(). Waiting on the workqueue could theoretically delay a vCPU due to waiting for the work to complete, but that's a very, very small chance, and likely a very small delay. kvm_arch_async_page_present_queued() unconditionally makes a new request, i.e. will effectively delay entering the guest, so the remaining work is really just:
trace_kvm_async_pf_completed(addr, cr2_or_gpa);
__kvm_vcpu_wake_up(vcpu);
mmput(mm);
and mmput() can't drop the last reference to the page tables if the vCPU is still alive, i.e. the vCPU won't get stuck tearing down page tables.
Add a helper to do the flushing, specifically to deal with "wakeup all" work items, as they aren't actually work items, i.e. are never placed in a workqueue. Trying to flush a bogus workqueue entry rightly makes __flush_work() complain (kudos to whoever added that sanity check).
Note, commit 5f6de5cbebee ("KVM: Prevent module exit until al ---truncated---(CVE-2024-26976)
In the Linux kernel, the following vulnerability has been resolved:
Squashfs: check the inode number is not the invalid value of zero
Syskiller has produced an out of bounds access in fill_meta_index().
That out of bounds access is ultimately caused because the inode has an inode number with the invalid value of zero, which was not checked.
The reason this causes the out of bounds access is due to following sequence of events:
-
Fill_meta_index() is called to allocate (via empty_meta_index()) and fill a metadata index. It however suffers a data read error and aborts, invalidating the newly returned empty metadata index. It does this by setting the inode number of the index to zero, which means unused (zero is not a valid inode number).
-
When fill_meta_index() is subsequently called again on another read operation, locate_meta_index() returns the previous index because it matches the inode number of 0. Because this index has been returned it is expected to have been filled, and because it hasn't been, an out of bounds access is performed.
This patch adds a sanity check which checks that the inode number is not zero when the inode is created and returns -EINVAL if it is.
[phillip@squashfs.org.uk: whitespace fix] Link: https://lkml.kernel.org/r/20240409204723.446925-1-phillip@squashfs.org.uk(CVE-2024-26982)
In the Linux kernel, the following vulnerability has been resolved:
fs: sysfs: Fix reference leak in sysfs_break_active_protection()
The sysfs_break_active_protection() routine has an obvious reference leak in its error path. If the call to kernfs_find_and_get() fails then kn will be NULL, so the companion sysfs_unbreak_active_protection() routine won't get called (and would only cause an access violation by trying to dereference kn->parent if it was called). As a result, the reference to kobj acquired at the start of the function will never be released.
Fix the leak by adding an explicit kobject_put() call when kn is NULL.(CVE-2024-26993)
In the Linux kernel, the following vulnerability has been resolved:
speakup: Avoid crash on very long word
In case a console is set up really large and contains a really long word (> 256 characters), we have to stop before the length of the word buffer.(CVE-2024-26994)
In the Linux kernel, the following vulnerability has been resolved:
serial/pmac_zilog: Remove flawed mitigation for rx irq flood
The mitigation was intended to stop the irq completely. That may be better than a hard lock-up but it turns out that you get a crash anyway if you're using pmac_zilog as a serial console:
ttyPZ0: pmz: rx irq flood ! BUG: spinlock recursion on CPU#0, swapper/0
That's because the pr_err() call in pmz_receive_chars() results in pmz_console_write() attempting to lock a spinlock already locked in pmz_interrupt(). With CONFIG_DEBUG_SPINLOCK=y, this produces a fatal BUG splat. The spinlock in question is the one in struct uart_port.
Even when it's not fatal, the serial port rx function ceases to work. Also, the iteration limit doesn't play nicely with QEMU, as can be seen in the bug report linked below.
A web search for other reports of the error message "pmz: rx irq flood" didn't produce anything. So I don't think this code is needed any more. Remove it.(CVE-2024-26999)
In the Linux kernel, the following vulnerability has been resolved:
serial: mxs-auart: add spinlock around changing cts state
The uart_handle_cts_change() function in serial_core expects the caller to hold uport->lock. For example, I have seen the below kernel splat, when the Bluetooth driver is loaded on an i.MX28 board.
[ 85.119255] ------------[ cut here ]------------
[ 85.124413] WARNING: CPU: 0 PID: 27 at /drivers/tty/serial/serial_core.c:3453 uart_handle_cts_change+0xb4/0xec
[ 85.134694] Modules linked in: hci_uart bluetooth ecdh_generic ecc wlcore_sdio configfs
[ 85.143314] CPU: 0 PID: 27 Comm: kworker/u3:0 Not tainted 6.6.3-00021-gd62a2f068f92 #1
[ 85.151396] Hardware name: Freescale MXS (Device Tree)
[ 85.156679] Workqueue: hci0 hci_power_on [bluetooth]
(...)
[ 85.191765] uart_handle_cts_change from mxs_auart_irq_handle+0x380/0x3f4
[ 85.198787] mxs_auart_irq_handle from __handle_irq_event_percpu+0x88/0x210
(...)(CVE-2024-27000)
In the Linux kernel, the following vulnerability has been resolved:
drm: nv04: Fix out of bounds access
When Output Resource (dcb->or) value is assigned in fabricate_dcb_output(), there may be out of bounds access to dac_users array in case dcb->or is zero because ffs(dcb->or) is used as index there. The 'or' argument of fabricate_dcb_output() must be interpreted as a number of bit to set, not value.
Utilize macros from 'enum nouveau_or' in calls instead of hardcoding.
Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-27008)
In the Linux kernel, the following vulnerability has been resolved:
net/sched: Fix mirred deadlock on device recursion
When the mirred action is used on a classful egress qdisc and a packet is mirrored or redirected to self we hit a qdisc lock deadlock. See trace below.
[..... other info removed for brevity....] [ 82.890906] [ 82.890906] ============================================ [ 82.890906] WARNING: possible recursive locking detected [ 82.890906] 6.8.0-05205-g77fadd89fe2d-dirty #213 Tainted: G W [ 82.890906] -------------------------------------------- [ 82.890906] ping/418 is trying to acquire lock: [ 82.890906] ffff888006994110 (&sch->q.lock){+.-.}-{3:3}, at: __dev_queue_xmit+0x1778/0x3550 [ 82.890906] [ 82.890906] but task is already holding lock: [ 82.890906] ffff888006994110 (&sch->q.lock){+.-.}-{3:3}, at: __dev_queue_xmit+0x1778/0x3550 [ 82.890906] [ 82.890906] other info that might help us debug this: [ 82.890906] Possible unsafe locking scenario: [ 82.890906] [ 82.890906] CPU0 [ 82.890906] ---- [ 82.890906] lock(&sch->q.lock); [ 82.890906] lock(&sch->q.lock); [ 82.890906] [ 82.890906] *** DEADLOCK *** [ 82.890906] [..... other info removed for brevity....]
Example setup (eth0->eth0) to recreate tc qdisc add dev eth0 root handle 1: htb default 30 tc filter add dev eth0 handle 1: protocol ip prio 2 matchall \ action mirred egress redirect dev eth0
Another example(eth0->eth1->eth0) to recreate tc qdisc add dev eth0 root handle 1: htb default 30 tc filter add dev eth0 handle 1: protocol ip prio 2 matchall \ action mirred egress redirect dev eth1
tc qdisc add dev eth1 root handle 1: htb default 30 tc filter add dev eth1 handle 1: protocol ip prio 2 matchall \ action mirred egress redirect dev eth0
We fix this by adding an owner field (CPU id) to struct Qdisc set after root qdisc is entered. When the softirq enters it a second time, if the qdisc owner is the same CPU, the packet is dropped to break the loop.(CVE-2024-27010)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: fix memleak in map from abort path
The delete set command does not rely on the transaction object for element removal, therefore, a combination of delete element + delete set from the abort path could result in restoring twice the refcount of the mapping.
Check for inactive element in the next generation for the delete element command in the abort path, skip restoring state if next generation bit has been already cleared. This is similar to the activate logic using the set walk iterator.
[ 6170.286929] ------------[ cut here ]------------ [ 6170.286939] WARNING: CPU: 6 PID: 790302 at net/netfilter/nf_tables_api.c:2086 nf_tables_chain_destroy+0x1f7/0x220 [nf_tables] [ 6170.287071] Modules linked in: [...] [ 6170.287633] CPU: 6 PID: 790302 Comm: kworker/6:2 Not tainted 6.9.0-rc3+ #365 [ 6170.287768] RIP: 0010:nf_tables_chain_destroy+0x1f7/0x220 [nf_tables] [ 6170.287886] Code: df 48 8d 7d 58 e8 69 2e 3b df 48 8b 7d 58 e8 80 1b 37 df 48 8d 7d 68 e8 57 2e 3b df 48 8b 7d 68 e8 6e 1b 37 df 48 89 ef eb c4 <0f> 0b 48 83 c4 08 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 0f [ 6170.287895] RSP: 0018:ffff888134b8fd08 EFLAGS: 00010202 [ 6170.287904] RAX: 0000000000000001 RBX: ffff888125bffb28 RCX: dffffc0000000000 [ 6170.287912] RDX: 0000000000000003 RSI: ffffffffa20298ab RDI: ffff88811ebe4750 [ 6170.287919] RBP: ffff88811ebe4700 R08: ffff88838e812650 R09: fffffbfff0623a55 [ 6170.287926] R10: ffffffff8311d2af R11: 0000000000000001 R12: ffff888125bffb10 [ 6170.287933] R13: ffff888125bffb10 R14: dead000000000122 R15: dead000000000100 [ 6170.287940] FS: 0000000000000000(0000) GS:ffff888390b00000(0000) knlGS:0000000000000000 [ 6170.287948] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 6170.287955] CR2: 00007fd31fc00710 CR3: 0000000133f60004 CR4: 00000000001706f0 [ 6170.287962] Call Trace: [ 6170.287967] <TASK> [ 6170.287973] ? __warn+0x9f/0x1a0 [ 6170.287986] ? nf_tables_chain_destroy+0x1f7/0x220 [nf_tables] [ 6170.288092] ? report_bug+0x1b1/0x1e0 [ 6170.287986] ? nf_tables_chain_destroy+0x1f7/0x220 [nf_tables] [ 6170.288092] ? report_bug+0x1b1/0x1e0 [ 6170.288104] ? handle_bug+0x3c/0x70 [ 6170.288112] ? exc_invalid_op+0x17/0x40 [ 6170.288120] ? asm_exc_invalid_op+0x1a/0x20 [ 6170.288132] ? nf_tables_chain_destroy+0x2b/0x220 [nf_tables] [ 6170.288243] ? nf_tables_chain_destroy+0x1f7/0x220 [nf_tables] [ 6170.288366] ? nf_tables_chain_destroy+0x2b/0x220 [nf_tables] [ 6170.288483] nf_tables_trans_destroy_work+0x588/0x590 nf_tables
In the Linux kernel, the following vulnerability has been resolved:
net/rds: fix WARNING in rds_conn_connect_if_down
If connection isn't established yet, get_mr() will fail, trigger connection after get_mr().(CVE-2024-27024)
In the Linux kernel, the following vulnerability has been resolved:
f2fs: compress: fix to cover normal cluster write with cp_rwsem
When we overwrite compressed cluster w/ normal cluster, we should not unlock cp_rwsem during f2fs_write_raw_pages(), otherwise data will be corrupted if partial blocks were persisted before CP & SPOR, due to cluster metadata wasn't updated atomically.(CVE-2024-27034)
In the Linux kernel, the following vulnerability has been resolved:
f2fs: compress: fix to guarantee persisting compressed blocks by CP
If data block in compressed cluster is not persisted with metadata during checkpoint, after SPOR, the data may be corrupted, let's guarantee to write compressed page by checkpoint.(CVE-2024-27035)
In the Linux kernel, the following vulnerability has been resolved:
clk: zynq: Prevent null pointer dereference caused by kmalloc failure
The kmalloc() in zynq_clk_setup() will return null if the physical memory has run out. As a result, if we use snprintf() to write data to the null address, the null pointer dereference bug will happen.
This patch uses a stack variable to replace the kmalloc().(CVE-2024-27037)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix a potential buffer overflow in 'dp_dsc_clock_en_read()'
Tell snprintf() to store at most 10 bytes in the output buffer instead of 30.
Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_debugfs.c:1508 dp_dsc_clock_en_read() error: snprintf() is printing too much 30 vs 10(CVE-2024-27045)
In the Linux kernel, the following vulnerability has been resolved:
USB: usb-storage: Prevent divide-by-0 error in isd200_ata_command
The isd200 sub-driver in usb-storage uses the HEADS and SECTORS values in the ATA ID information to calculate cylinder and head values when creating a CDB for READ or WRITE commands. The calculation involves division and modulus operations, which will cause a crash if either of these values is 0. While this never happens with a genuine device, it could happen with a flawed or subversive emulation, as reported by the syzbot fuzzer.
Protect against this possibility by refusing to bind to the device if either the ATA_ID_HEADS or ATA_ID_SECTORS value in the device's ID information is 0. This requires isd200_Initialization() to return a negative error code when initialization fails; currently it always returns 0 (even when there is an error).(CVE-2024-27059)
In the Linux kernel, the following vulnerability has been resolved:
media: usbtv: Remove useless locks in usbtv_video_free()
Remove locks calls in usbtv_video_free() because are useless and may led to a deadlock as reported here: https://syzkaller.appspot.com/x/bisect.txt?x=166dc872180000 Also remove usbtv_stop() call since it will be called when unregistering the device.
Before 'c838530d230b' this issue would only be noticed if you disconnect while streaming and now it is noticeable even when disconnecting while not streaming.
hverkuil: fix minor spelling mistake in log message
In the Linux kernel, the following vulnerability has been resolved:
media: ttpci: fix two memleaks in budget_av_attach
When saa7146_register_device and saa7146_vv_init fails, budget_av_attach should free the resources it allocates, like the error-handling of ttpci_budget_init does. Besides, there are two fixme comment refers to such deallocations.(CVE-2024-27073)
In the Linux kernel, the following vulnerability has been resolved:
media: dvb-frontends: avoid stack overflow warnings with clang
A previous patch worked around a KASAN issue in stv0367, now a similar problem showed up with clang:
drivers/media/dvb-frontends/stv0367.c:1222:12: error: stack frame size (3624) exceeds limit (2048) in 'stv0367ter_set_frontend' [-Werror,-Wframe-larger-than] 1214 | static int stv0367ter_set_frontend(struct dvb_frontend *fe)
Rework the stv0367_writereg() function to be simpler and mark both register access functions as noinline_for_stack so the temporary i2c_msg structures do not get duplicated on the stack when KASAN_STACK is enabled.(CVE-2024-27075)
In the Linux kernel, the following vulnerability has been resolved:
SUNRPC: fix some memleaks in gssx_dec_option_array
The creds and oa->data need to be freed in the error-handling paths after their allocation. So this patch add these deallocations in the corresponding paths.(CVE-2024-27388)
In the Linux kernel, the following vulnerability has been resolved:
pstore: inode: Only d_invalidate() is needed
Unloading a modular pstore backend with records in pstorefs would trigger the dput() double-drop warning:
WARNING: CPU: 0 PID: 2569 at fs/dcache.c:762 dput.part.0+0x3f3/0x410
Using the combo of d_drop()/dput() (as mentioned in Documentation/filesystems/vfs.rst) isn't the right approach here, and leads to the reference counting problem seen above. Use d_invalidate() and update the code to not bother checking for error codes that can never happen.
---(CVE-2024-27389)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nft_flow_offload: reset dst in route object after setting up flow
dst is transferred to the flow object, route object does not own it anymore. Reset dst in route object, otherwise if flow_offload_add() fails, error path releases dst twice, leading to a refcount underflow.(CVE-2024-27403)
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Fixed overflow check in mi_enum_attr()(CVE-2024-27407)
In the Linux kernel, the following vulnerability has been resolved:
netrom: Fix data-races around sysctl_net_busy_read
We need to protect the reader reading the sysctl value because the value can be changed concurrently.(CVE-2024-27419)
Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2024-27426)
Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2024-27427)
Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2024-27428)
In the Linux kernel, the following vulnerability has been resolved: x86/fpu: Keep xfd_state in sync with MSR_IA32_XFD Commit 672365477ae8 ("x86/fpu: Update XFD state where required") and commit 8bf26758ca96 ("x86/fpu: Add XFD state to fpstate") introduced a per CPU variable xfd_state to keep the MSR_IA32_XFD value cached, in order to avoid unnecessary writes to the MSR. On CPU hotplug MSR_IA32_XFD is reset to the init_fpstate.xfd, which wipes out any stale state. But the per CPU cached xfd value is not reset, which brings them out of sync. As a consequence a subsequent xfd_update_state() might fail to update the MSR which in turn can result in XRSTOR raising a #NM in kernel space, which crashes the kernel. To fix this, introduce xfd_set_state() to write xfd_state together with MSR_IA32_XFD, and use it in all places that set MSR_IA32_XFD.(CVE-2024-35801)
In the Linux kernel, the following vulnerability has been resolved:
dm snapshot: fix lockup in dm_exception_table_exit
There was reported lockup when we exit a snapshot with many exceptions. Fix this by adding "cond_resched" to the loop that frees the exceptions.(CVE-2024-35805)
In the Linux kernel, the following vulnerability has been resolved:
soc: fsl: qbman: Always disable interrupts when taking cgr_lock
smp_call_function_single disables IRQs when executing the callback. To prevent deadlocks, we must disable IRQs when taking cgr_lock elsewhere. This is already done by qman_update_cgr and qman_delete_cgr; fix the other lockers.(CVE-2024-35806)
In the Linux kernel, the following vulnerability has been resolved:
fs/aio: Check IOCB_AIO_RW before the struct aio_kiocb conversion
The first kiocb_set_cancel_fn() argument may point at a struct kiocb that is not embedded inside struct aio_kiocb. With the current code, depending on the compiler, the req->ki_ctx read happens either before the IOCB_AIO_RW test or after that test. Move the req->ki_ctx read such that it is guaranteed that the IOCB_AIO_RW test happens first.(CVE-2024-35815)
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:
LoongArch: Define the __io_aw() hook as mmiowb()
Commit fb24ea52f78e0d595852e ("drivers: Remove explicit invocations of mmiowb()") remove all mmiowb() in drivers, but it says:
"NOTE: mmiowb() has only ever guaranteed ordering in conjunction with spin_unlock(). However, pairing each mmiowb() removal in this patch with the corresponding call to spin_unlock() is not at all trivial, so there is a small chance that this change may regress any drivers incorrectly relying on mmiowb() to order MMIO writes between CPUs using lock-free synchronisation."
The mmio in radeon_ring_commit() is protected by a mutex rather than a spinlock, but in the mutex fastpath it behaves similar to spinlock. We can add mmiowb() calls in the radeon driver but the maintainer says he doesn't like such a workaround, and radeon is not the only example of mutex protected mmio.
So we should extend the mmiowb tracking system from spinlock to mutex, and maybe other locking primitives. This is not easy and error prone, so we solve it in the architectural code, by simply defining the __io_aw() hook as mmiowb(). And we no longer need to override queued_spin_unlock() so use the generic definition.
Without this, we get such an error when run 'glxgears' on weak ordering architectures such as LoongArch:
radeon 0000:04:00.0: ring 0 stalled for more than 10324msec radeon 0000:04:00.0: ring 3 stalled for more than 10240msec radeon 0000:04:00.0: GPU lockup (current fence id 0x000000000001f412 last fence id 0x000000000001f414 on ring 3) radeon 0000:04:00.0: GPU lockup (current fence id 0x000000000000f940 last fence id 0x000000000000f941 on ring 0) radeon 0000:04:00.0: scheduling IB failed (-35). [drm:radeon_gem_va_ioctl [radeon]] ERROR Couldn't update BO_VA (-35) radeon 0000:04:00.0: scheduling IB failed (-35). [drm:radeon_gem_va_ioctl [radeon]] ERROR Couldn't update BO_VA (-35) radeon 0000:04:00.0: scheduling IB failed (-35). [drm:radeon_gem_va_ioctl [radeon]] ERROR Couldn't update BO_VA (-35) radeon 0000:04:00.0: scheduling IB failed (-35). [drm:radeon_gem_va_ioctl [radeon]] ERROR Couldn't update BO_VA (-35) radeon 0000:04:00.0: scheduling IB failed (-35). [drm:radeon_gem_va_ioctl [radeon]] ERROR Couldn't update BO_VA (-35) radeon 0000:04:00.0: scheduling IB failed (-35). [drm:radeon_gem_va_ioctl [radeon]] ERROR Couldn't update BO_VA (-35) radeon 0000:04:00.0: scheduling IB failed (-35). [drm:radeon_gem_va_ioctl [radeon]] ERROR Couldn't update BO_VA (-35)(CVE-2024-35818)
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: fix a double-free in arfs_create_groups
When in allocated by kvzalloc fails, arfs_create_groups will free
ft->g and return an error. However, arfs_create_table, the only caller of
arfs_create_groups, will hold this error and call to
mlx5e_destroy_flow_table, in which the ft->g will be freed again.(CVE-2024-35835)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: bridge: replace physindev with physinif in nf_bridge_info
An skb can be added to a neigh->arp_queue while waiting for an arp reply. Where original skb's skb->dev can be different to neigh's neigh->dev. For instance in case of bridging dnated skb from one veth to another, the skb would be added to a neigh->arp_queue of the bridge.
As skb->dev can be reset back to nf_bridge->physindev and used, and as there is no explicit mechanism that prevents this physindev from been freed under us (for instance neigh_flush_dev doesn't cleanup skbs from different device's neigh queue) we can crash on e.g. this stack:
arp_process neigh_update skb = __skb_dequeue(&neigh->arp_queue) neigh_resolve_output(..., skb) ... br_nf_dev_xmit br_nf_pre_routing_finish_bridge_slow skb->dev = nf_bridge->physindev br_handle_frame_finish
Let's use plain ifindex instead of net_device link. To peek into the original net_device we will use dev_get_by_index_rcu(). Thus either we get device and are safe to use it or we don't get it and drop skb.(CVE-2024-35839)
In the Linux kernel, the following vulnerability has been resolved:
f2fs: compress: fix reserve_cblocks counting error when out of space
When a file only needs one direct_node, performing the following operations will cause the file to be unrepairable:
unisoc # ./f2fs_io compress test.apk unisoc #df -h | grep dm-48 /dev/block/dm-48 112G 112G 1.2M 100% /data
unisoc # ./f2fs_io release_cblocks test.apk 924 unisoc # df -h | grep dm-48 /dev/block/dm-48 112G 112G 4.8M 100% /data
unisoc # dd if=/dev/random of=file4 bs=1M count=3 3145728 bytes (3.0 M) copied, 0.025 s, 120 M/s unisoc # df -h | grep dm-48 /dev/block/dm-48 112G 112G 1.8M 100% /data
unisoc # ./f2fs_io reserve_cblocks test.apk F2FS_IOC_RESERVE_COMPRESS_BLOCKS failed: No space left on device
adb reboot unisoc # df -h | grep dm-48 /dev/block/dm-48 112G 112G 11M 100% /data unisoc # ./f2fs_io reserve_cblocks test.apk 0
This is because the file has only one direct_node. After returning to -ENOSPC, reserved_blocks += ret will not be executed. As a result, the reserved_blocks at this time is still 0, which is not the real number of reserved blocks. Therefore, fsck cannot be set to repair the file.
After this patch, the fsck flag will be set to fix this problem.
unisoc # df -h | grep dm-48 /dev/block/dm-48 112G 112G 1.8M 100% /data unisoc # ./f2fs_io reserve_cblocks test.apk F2FS_IOC_RESERVE_COMPRESS_BLOCKS failed: No space left on device
adb reboot then fsck will be executed unisoc # df -h | grep dm-48 /dev/block/dm-48 112G 112G 11M 100% /data unisoc # ./f2fs_io reserve_cblocks test.apk 924(CVE-2024-35844)
In the Linux kernel, the following vulnerability has been resolved:
eeprom: at24: fix memory corruption race condition
If the eeprom is not accessible, an nvmem device will be registered, the read will fail, and the device will be torn down. If another driver accesses the nvmem device after the teardown, it will reference invalid memory.
Move the failure point before registering the nvmem device.(CVE-2024-35848)
In the Linux kernel, the following vulnerability has been resolved:
ipv6: Fix infinite recursion in fib6_dump_done().
syzkaller reported infinite recursive calls of fib6_dump_done() during netlink socket destruction. [1]
From the log, syzkaller sent an AF_UNSPEC RTM_GETROUTE message, and then the response was generated. The following recvmmsg() resumed the dump for IPv6, but the first call of inet6_dump_fib() failed at kzalloc() due to the fault injection. [0]
12:01:34 executing program 3: r0 = socket$nl_route(0x10, 0x3, 0x0) sendmsg$nl_route(r0, ... snip ...) recvmmsg(r0, ... snip ...) (fail_nth: 8)
Here, fib6_dump_done() was set to nlk_sk(sk)->cb.done, and the next call of inet6_dump_fib() set it to nlk_sk(sk)->cb.args[3]. syzkaller stopped receiving the response halfway through, and finally netlink_sock_destruct() called nlk_sk(sk)->cb.done().
fib6_dump_done() calls fib6_dump_end() and nlk_sk(sk)->cb.done() if it is still not NULL. fib6_dump_end() rewrites nlk_sk(sk)->cb.done() by nlk_sk(sk)->cb.args[3], but it has the same function, not NULL, calling itself recursively and hitting the stack guard page.
To avoid the issue, let's set the destructor after kzalloc().
[0]: FAULT_INJECTION: forcing a failure. name failslab, interval 1, probability 0, space 0, times 0 CPU: 1 PID: 432110 Comm: syz-executor.3 Not tainted 6.8.0-12821-g537c2e91d354-dirty #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> dump_stack_lvl (lib/dump_stack.c:117) should_fail_ex (lib/fault-inject.c:52 lib/fault-inject.c:153) should_failslab (mm/slub.c:3733) kmalloc_trace (mm/slub.c:3748 mm/slub.c:3827 mm/slub.c:3992) inet6_dump_fib (./include/linux/slab.h:628 ./include/linux/slab.h:749 net/ipv6/ip6_fib.c:662) rtnl_dump_all (net/core/rtnetlink.c:4029) netlink_dump (net/netlink/af_netlink.c:2269) netlink_recvmsg (net/netlink/af_netlink.c:1988) _sysrecvmsg (net/socket.c:1046 net/socket.c:2801) _sys_recvmsg (net/socket.c:2846) do_recvmmsg (net/socket.c:2943) __x64_sys_recvmmsg (net/socket.c:3041 net/socket.c:3034 net/socket.c:3034)
[1]: BUG: TASK stack guard page was hit at 00000000f2fa9af1 (stack is 00000000b7912430..000000009a436beb) stack guard page: 0000 [#1] PREEMPT SMP KASAN CPU: 1 PID: 223719 Comm: kworker/1:3 Not tainted 6.8.0-12821-g537c2e91d354-dirty #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 Workqueue: events netlink_sock_destruct_work RIP: 0010:fib6_dump_done (net/ipv6/ip6_fib.c:570) Code: 3c 24 e8 f3 e9 51 fd e9 28 fd ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 41 57 41 56 41 55 41 54 55 48 89 fd <53> 48 8d 5d 60 e8 b6 4d 07 fd 48 89 da 48 b8 00 00 00 00 00 fc ff RSP: 0018:ffffc9000d980000 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffffffff84405990 RCX: ffffffff844059d3 RDX: ffff8881028e0000 RSI: ffffffff84405ac2 RDI: ffff88810c02f358 RBP: ffff88810c02f358 R08: 0000000000000007 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000224 R12: 0000000000000000 R13: ffff888007c82c78 R14: ffff888007c82c68 R15: ffff888007c82c68 FS: 0000000000000000(0000) GS:ffff88811b100000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffc9000d97fff8 CR3: 0000000102309002 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace: <#DF> </#DF> <TASK> fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1)) fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1)) ... fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1)) fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1)) netlink_sock_destruct (net/netlink/af_netlink.c:401) __sk_destruct (net/core/sock.c:2177 (discriminator 2)) sk_destruct (net/core/sock.c:2224) __sk_free (net/core/sock.c:2235) sk_free (net/core/sock.c:2246) process_one_work (kernel/workqueue.c:3259) worker_thread (kernel/workqueue.c:3329 kernel/workqueue. ---truncated---(CVE-2024-35886)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: discard table flag update with pending basechain deletion
Hook unregistration is deferred to the commit phase, same occurs with hook updates triggered by the table dormant flag. When both commands are combined, this results in deleting a basechain while leaving its hook still registered in the core.(CVE-2024-35897)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: Fix potential data-race in __nft_flowtable_type_get()
nft_unregister_flowtable_type() within nf_flow_inet_module_exit() can concurrent with __nft_flowtable_type_get() within nf_tables_newflowtable(). And thhere is not any protection when iterate over nf_tables_flowtables list in __nft_flowtable_type_get(). Therefore, there is pertential data-race of nf_tables_flowtables list entry.
Use list_for_each_entry_rcu() to iterate over nf_tables_flowtables list in __nft_flowtable_type_get(), and use rcu_read_lock() in the caller nft_flowtable_type_get() to protect the entire type query process.(CVE-2024-35898)
In the Linux kernel, the following vulnerability has been resolved:
fbmon: prevent division by zero in fb_videomode_from_videomode()
The expression htotal * vtotal can have a zero value on overflow. It is necessary to prevent division by zero like in fb_var_to_videomode().
Found by Linux Verification Center (linuxtesting.org) with Svace.(CVE-2024-35922)
In the Linux kernel, the following vulnerability has been resolved:
scsi: lpfc: Fix possible memory leak in lpfc_rcv_padisc()
The call to lpfc_sli4_resume_rpi() in lpfc_rcv_padisc() may return an unsuccessful status. In such cases, the elsiocb is not issued, the completion is not called, and thus the elsiocb resource is leaked.
Check return value after calling lpfc_sli4_resume_rpi() and conditionally release the elsiocb resource.(CVE-2024-35930)
In the Linux kernel, the following vulnerability has been resolved:
btrfs: handle chunk tree lookup error in btrfs_relocate_sys_chunks()
The unhandled case in btrfs_relocate_sys_chunks() loop is a corruption, as it could be caused only by two impossible conditions:
-
at first the search key is set up to look for a chunk tree item, with offset -1, this is an inexact search and the key->offset will contain the correct offset upon a successful search, a valid chunk tree item cannot have an offset -1
-
after first successful search, the found_key corresponds to a chunk item, the offset is decremented by 1 before the next loop, it's impossible to find a chunk item there due to alignment and size constraints(CVE-2024-35936)
In the Linux kernel, the following vulnerability has been resolved:
pstore/zone: Add a null pointer check to the psz_kmsg_read
kasprintf() returns a pointer to dynamically allocated memory which can be NULL upon failure. Ensure the allocation was successful by checking the pointer validity.(CVE-2024-35940)
In the Linux kernel, the following vulnerability has been resolved:
xsk: validate user input for XDP_{UMEM|COMPLETION}_FILL_RING
syzbot reported an illegal copy in xsk_setsockopt() [1]
Make sure to validate setsockopt() @optlen parameter.
[1]
BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline] BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline] BUG: KASAN: slab-out-of-bounds in xsk_setsockopt+0x909/0xa40 net/xdp/xsk.c:1420 Read of size 4 at addr ffff888028c6cde3 by task syz-executor.0/7549
CPU: 0 PID: 7549 Comm: syz-executor.0 Not tainted 6.8.0-syzkaller-08951-gfe46a7dd189e #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 copy_from_sockptr_offset include/linux/sockptr.h:49 [inline] copy_from_sockptr include/linux/sockptr.h:55 [inline] xsk_setsockopt+0x909/0xa40 net/xdp/xsk.c:1420 do_sock_setsockopt+0x3af/0x720 net/socket.c:2311 __sys_setsockopt+0x1ae/0x250 net/socket.c:2334 __do_sys_setsockopt net/socket.c:2343 [inline] __se_sys_setsockopt net/socket.c:2340 [inline] __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340 do_syscall_64+0xfb/0x240 entry_SYSCALL_64_after_hwframe+0x6d/0x75 RIP: 0033:0x7fb40587de69 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:00007fb40665a0c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000036 RAX: ffffffffffffffda RBX: 00007fb4059abf80 RCX: 00007fb40587de69 RDX: 0000000000000005 RSI: 000000000000011b RDI: 0000000000000006 RBP: 00007fb4058ca47a R08: 0000000000000002 R09: 0000000000000000 R10: 0000000020001980 R11: 0000000000000246 R12: 0000000000000000 R13: 000000000000000b R14: 00007fb4059abf80 R15: 00007fff57ee4d08 </TASK>
Allocated by task 7549: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:370 [inline] __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:387 kasan_kmalloc include/linux/kasan.h:211 [inline] __do_kmalloc_node mm/slub.c:3966 [inline] __kmalloc+0x233/0x4a0 mm/slub.c:3979 kmalloc include/linux/slab.h:632 [inline] __cgroup_bpf_run_filter_setsockopt+0xd2f/0x1040 kernel/bpf/cgroup.c:1869 do_sock_setsockopt+0x6b4/0x720 net/socket.c:2293 __sys_setsockopt+0x1ae/0x250 net/socket.c:2334 __do_sys_setsockopt net/socket.c:2343 [inline] __se_sys_setsockopt net/socket.c:2340 [inline] __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340 do_syscall_64+0xfb/0x240 entry_SYSCALL_64_after_hwframe+0x6d/0x75
The buggy address belongs to the object at ffff888028c6cde0 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 1 bytes to the right of allocated 2-byte region [ffff888028c6cde0, ffff888028c6cde2)
The buggy address belongs to the physical page: page:ffffea0000a31b00 refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888028c6c9c0 pfn:0x28c6c anon flags: 0xfff00000000800(slab|node=0|zone=1|lastcpupid=0x7ff) page_type: 0xffffffff() raw: 00fff00000000800 ffff888014c41280 0000000000000000 dead000000000001 raw: ffff888028c6c9c0 0000000080800057 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected page_owner tracks the page as allocated page last allocated via order 0, migratetype Unmovable, gfp_mask 0x112cc0(GFP_USER|__GFP_NOWARN|__GFP_NORETRY), pid 6648, tgid 6644 (syz-executor.0), ts 133906047828, free_ts 133859922223 set_page_owner include/linux/page_owner.h:31 [inline] post_alloc_hook+0x1ea/0x210 mm/page_alloc.c:1533 prep_new_page mm/page_alloc.c: ---truncated---(CVE-2024-35976)
In the Linux kernel, the following vulnerability has been resolved:
ACPI: CPPC: Use access_width over bit_width for system memory accesses
To align with ACPI 6.3+, since bit_width can be any 8-bit value, it cannot be depended on to be always on a clean 8b boundary. This was uncovered on the Cobalt 100 platform.
SError Interrupt on CPU26, code 0xbe000011 -- SError CPU: 26 PID: 1510 Comm: systemd-udevd Not tainted 5.15.2.1-13 #1 Hardware name: MICROSOFT CORPORATION, BIOS MICROSOFT CORPORATION pstate: 62400009 (nZCv daif +PAN -UAO +TCO -DIT -SSBS BTYPE=--) pc : cppc_get_perf_caps+0xec/0x410 lr : cppc_get_perf_caps+0xe8/0x410 sp : ffff8000155ab730 x29: ffff8000155ab730 x28: ffff0080139d0038 x27: ffff0080139d0078 x26: 0000000000000000 x25: ffff0080139d0058 x24: 00000000ffffffff x23: ffff0080139d0298 x22: ffff0080139d0278 x21: 0000000000000000 x20: ffff00802b251910 x19: ffff0080139d0000 x18: ffffffffffffffff x17: 0000000000000000 x16: ffffdc7e111bad04 x15: ffff00802b251008 x14: ffffffffffffffff x13: ffff013f1fd63300 x12: 0000000000000006 x11: ffffdc7e128f4420 x10: 0000000000000000 x9 : ffffdc7e111badec x8 : ffff00802b251980 x7 : 0000000000000000 x6 : ffff0080139d0028 x5 : 0000000000000000 x4 : ffff0080139d0018 x3 : 00000000ffffffff x2 : 0000000000000008 x1 : ffff8000155ab7a0 x0 : 0000000000000000 Kernel panic - not syncing: Asynchronous SError Interrupt CPU: 26 PID: 1510 Comm: systemd-udevd Not tainted 5.15.2.1-13 #1 Hardware name: MICROSOFT CORPORATION, BIOS MICROSOFT CORPORATION Call trace: dump_backtrace+0x0/0x1e0 show_stack+0x24/0x30 dump_stack_lvl+0x8c/0xb8 dump_stack+0x18/0x34 panic+0x16c/0x384 add_taint+0x0/0xc0 arm64_serror_panic+0x7c/0x90 arm64_is_fatal_ras_serror+0x34/0xa4 do_serror+0x50/0x6c el1h_64_error_handler+0x40/0x74 el1h_64_error+0x7c/0x80 cppc_get_perf_caps+0xec/0x410 cppc_cpufreq_cpu_init+0x74/0x400 [cppc_cpufreq] cpufreq_online+0x2dc/0xa30 cpufreq_add_dev+0xc0/0xd4 subsys_interface_register+0x134/0x14c cpufreq_register_driver+0x1b0/0x354 cppc_cpufreq_init+0x1a8/0x1000 [cppc_cpufreq] do_one_initcall+0x50/0x250 do_init_module+0x60/0x27c load_module+0x2300/0x2570 __do_sys_finit_module+0xa8/0x114 __arm64_sys_finit_module+0x2c/0x3c invoke_syscall+0x78/0x100 el0_svc_common.constprop.0+0x180/0x1a0 do_el0_svc+0x84/0xa0 el0_svc+0x2c/0xc0 el0t_64_sync_handler+0xa4/0x12c el0t_64_sync+0x1a4/0x1a8
Instead, use access_width to determine the size and use the offset and width to shift and mask the bits to read/write out. Make sure to add a check for system memory since pcc redefines the access_width to subspace id.
If access_width is not set, then fall back to using bit_width.
rjw: Subject and changelog edits, comment adjustments
In the Linux kernel, the following vulnerability has been resolved:
HID: i2c-hid: remove I2C_HID_READ_PENDING flag to prevent lock-up
The flag I2C_HID_READ_PENDING is used to serialize I2C operations. However, this is not necessary, because I2C core already has its own locking for that.
More importantly, this flag can cause a lock-up: if the flag is set in i2c_hid_xfer() and an interrupt happens, the interrupt handler (i2c_hid_irq) will check this flag and return immediately without doing anything, then the interrupt handler will be invoked again in an infinite loop.
Since interrupt handler is an RT task, it takes over the CPU and the flag-clearing task never gets scheduled, thus we have a lock-up.
Delete this unnecessary flag.(CVE-2024-35997)
In the Linux kernel, the following vulnerability has been resolved:
mlxsw: spectrum_acl_tcam: Fix incorrect list API usage
Both the function that migrates all the chunks within a region and the function that migrates all the entries within a chunk call list_first_entry() on the respective lists without checking that the lists are not empty. This is incorrect usage of the API, which leads to the following warning [1].
Fix by returning if the lists are empty as there is nothing to migrate in this case.
[1] WARNING: CPU: 0 PID: 6437 at drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c:1266 mlxsw_sp_acl_tcam_vchunk_migrate_all+0x1f1/0> Modules linked in: CPU: 0 PID: 6437 Comm: kworker/0:37 Not tainted 6.9.0-rc3-custom-00883-g94a65f079ef6 #39 Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019 Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work RIP: 0010:mlxsw_sp_acl_tcam_vchunk_migrate_all+0x1f1/0x2c0 [...] Call Trace: <TASK> mlxsw_sp_acl_tcam_vregion_rehash_work+0x6c/0x4a0 process_one_work+0x151/0x370 worker_thread+0x2cb/0x3e0 kthread+0xd0/0x100 ret_from_fork+0x34/0x50 ret_from_fork_asm+0x1a/0x30 </TASK>(CVE-2024-36006)
In the Linux kernel, the following vulnerability has been resolved:
ipv4: check for NULL idev in ip_route_use_hint()
syzbot was able to trigger a NULL deref in fib_validate_source() in an old tree [1].
It appears the bug exists in latest trees.
All calls to __in_dev_get_rcu() must be checked for a NULL result.
[1] general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 2 PID: 3257 Comm: syz-executor.3 Not tainted 5.10.0-syzkaller #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:fib_validate_source+0xbf/0x15a0 net/ipv4/fib_frontend.c:425 Code: 18 f2 f2 f2 f2 42 c7 44 20 23 f3 f3 f3 f3 48 89 44 24 78 42 c6 44 20 27 f3 e8 5d 88 48 fc 4c 89 e8 48 c1 e8 03 48 89 44 24 18 <42> 80 3c 20 00 74 08 4c 89 ef e8 d2 15 98 fc 48 89 5c 24 10 41 bf RSP: 0018:ffffc900015fee40 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff88800f7a4000 RCX: ffff88800f4f90c0 RDX: 0000000000000000 RSI: 0000000004001eac RDI: ffff8880160c64c0 RBP: ffffc900015ff060 R08: 0000000000000000 R09: ffff88800f7a4000 R10: 0000000000000002 R11: ffff88800f4f90c0 R12: dffffc0000000000 R13: 0000000000000000 R14: 0000000000000000 R15: ffff88800f7a4000 FS: 00007f938acfe6c0(0000) GS:ffff888058c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f938acddd58 CR3: 000000001248e000 CR4: 0000000000352ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ip_route_use_hint+0x410/0x9b0 net/ipv4/route.c:2231 ip_rcv_finish_core+0x2c4/0x1a30 net/ipv4/ip_input.c:327 ip_list_rcv_finish net/ipv4/ip_input.c:612 [inline] ip_sublist_rcv+0x3ed/0xe50 net/ipv4/ip_input.c:638 ip_list_rcv+0x422/0x470 net/ipv4/ip_input.c:673 __netif_receive_skb_list_ptype net/core/dev.c:5572 [inline] __netif_receive_skb_list_core+0x6b1/0x890 net/core/dev.c:5620 __netif_receive_skb_list net/core/dev.c:5672 [inline] netif_receive_skb_list_internal+0x9f9/0xdc0 net/core/dev.c:5764 netif_receive_skb_list+0x55/0x3e0 net/core/dev.c:5816 xdp_recv_frames net/bpf/test_run.c:257 [inline] xdp_test_run_batch net/bpf/test_run.c:335 [inline] bpf_test_run_xdp_live+0x1818/0x1d00 net/bpf/test_run.c:363 bpf_prog_test_run_xdp+0x81f/0x1170 net/bpf/test_run.c:1376 bpf_prog_test_run+0x349/0x3c0 kernel/bpf/syscall.c:3736 __sys_bpf+0x45c/0x710 kernel/bpf/syscall.c:5115 __do_sys_bpf kernel/bpf/syscall.c:5201 [inline] __se_sys_bpf kernel/bpf/syscall.c:5199 [inline] __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:5199(CVE-2024-36008)
| URL | Type | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"perf-debuginfo-5.10.0-201.0.0.114.oe2203sp3.aarch64.rpm",
"python3-perf-5.10.0-201.0.0.114.oe2203sp3.aarch64.rpm",
"kernel-tools-devel-5.10.0-201.0.0.114.oe2203sp3.aarch64.rpm",
"kernel-devel-5.10.0-201.0.0.114.oe2203sp3.aarch64.rpm",
"kernel-debugsource-5.10.0-201.0.0.114.oe2203sp3.aarch64.rpm",
"kernel-source-5.10.0-201.0.0.114.oe2203sp3.aarch64.rpm",
"perf-5.10.0-201.0.0.114.oe2203sp3.aarch64.rpm",
"kernel-debuginfo-5.10.0-201.0.0.114.oe2203sp3.aarch64.rpm",
"kernel-tools-debuginfo-5.10.0-201.0.0.114.oe2203sp3.aarch64.rpm",
"kernel-5.10.0-201.0.0.114.oe2203sp3.aarch64.rpm",
"kernel-headers-5.10.0-201.0.0.114.oe2203sp3.aarch64.rpm",
"kernel-tools-5.10.0-201.0.0.114.oe2203sp3.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-201.0.0.114.oe2203sp3.aarch64.rpm"
],
"src": [
"kernel-5.10.0-201.0.0.114.oe2203sp3.src.rpm"
],
"x86_64": [
"kernel-devel-5.10.0-201.0.0.114.oe2203sp3.x86_64.rpm",
"kernel-tools-debuginfo-5.10.0-201.0.0.114.oe2203sp3.x86_64.rpm",
"kernel-source-5.10.0-201.0.0.114.oe2203sp3.x86_64.rpm",
"perf-debuginfo-5.10.0-201.0.0.114.oe2203sp3.x86_64.rpm",
"kernel-5.10.0-201.0.0.114.oe2203sp3.x86_64.rpm",
"perf-5.10.0-201.0.0.114.oe2203sp3.x86_64.rpm",
"kernel-debuginfo-5.10.0-201.0.0.114.oe2203sp3.x86_64.rpm",
"python3-perf-5.10.0-201.0.0.114.oe2203sp3.x86_64.rpm",
"kernel-headers-5.10.0-201.0.0.114.oe2203sp3.x86_64.rpm",
"python3-perf-debuginfo-5.10.0-201.0.0.114.oe2203sp3.x86_64.rpm",
"kernel-tools-5.10.0-201.0.0.114.oe2203sp3.x86_64.rpm",
"kernel-debugsource-5.10.0-201.0.0.114.oe2203sp3.x86_64.rpm",
"kernel-tools-devel-5.10.0-201.0.0.114.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-201.0.0.114.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\ndrm/amdgpu: handle the case of pci_channel_io_frozen only in amdgpu_pci_resume\r\n\r\nIn current code, when a PCI error state pci_channel_io_normal is detectd,\nit will report PCI_ERS_RESULT_CAN_RECOVER status to PCI driver, and PCI\ndriver will continue the execution of PCI resume callback report_resume by\npci_walk_bridge, and the callback will go into amdgpu_pci_resume\nfinally, where write lock is releasd unconditionally without acquiring\nsuch lock first. In this case, a deadlock will happen when other threads\nstart to acquire the read lock.\r\n\r\nTo fix this, add a member in amdgpu_device strucutre to cache\npci_channel_state, and only continue the execution in amdgpu_pci_resume\nwhen it\u0026apos;s pci_channel_io_frozen.(CVE-2021-47421)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nptp: Fix possible memory leak in ptp_clock_register()\r\n\r\nI got memory leak as follows when doing fault injection test:\r\n\r\nunreferenced object 0xffff88800906c618 (size 8):\n comm \u0026quot;i2c-idt82p33931\u0026quot;, pid 4421, jiffies 4294948083 (age 13.188s)\n hex dump (first 8 bytes):\n 70 74 70 30 00 00 00 00 ptp0....\n backtrace:\n [\u0026lt;00000000312ed458\u0026gt;] __kmalloc_track_caller+0x19f/0x3a0\n [\u0026lt;0000000079f6e2ff\u0026gt;] kvasprintf+0xb5/0x150\n [\u0026lt;0000000026aae54f\u0026gt;] kvasprintf_const+0x60/0x190\n [\u0026lt;00000000f323a5f7\u0026gt;] kobject_set_name_vargs+0x56/0x150\n [\u0026lt;000000004e35abdd\u0026gt;] dev_set_name+0xc0/0x100\n [\u0026lt;00000000f20cfe25\u0026gt;] ptp_clock_register+0x9f4/0xd30 [ptp]\n [\u0026lt;000000008bb9f0de\u0026gt;] idt82p33_probe.cold+0x8b6/0x1561 [ptp_idt82p33]\r\n\r\nWhen posix_clock_register() returns an error, the name allocated\nin dev_set_name() will be leaked, the put_device() should be used\nto give up the device reference, then the name will be freed in\nkobject_cleanup() and other memory will be freed in ptp_clock_release().(CVE-2021-47455)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: enetc: deny offload of tc-based TSN features on VF interfaces\r\n\r\nTSN features on the ENETC (taprio, cbs, gate, police) are configured\nthrough a mix of command BD ring messages and port registers:\nenetc_port_rd(), enetc_port_wr().\r\n\r\nPort registers are a region of the ENETC memory map which are only\naccessible from the PCIe Physical Function. They are not accessible from\nthe Virtual Functions.\r\n\r\nMoreover, attempting to access these registers crashes the kernel:\r\n\r\n$ echo 1 \u0026gt; /sys/bus/pci/devices/0000\\:00\\:00.0/sriov_numvfs\npci 0000:00:01.0: [1957:ef00] type 00 class 0x020001\nfsl_enetc_vf 0000:00:01.0: Adding to iommu group 15\nfsl_enetc_vf 0000:00:01.0: enabling device (0000 -\u0026gt; 0002)\nfsl_enetc_vf 0000:00:01.0 eno0vf0: renamed from eth0\n$ tc qdisc replace dev eno0vf0 root taprio num_tc 8 map 0 1 2 3 4 5 6 7 \\\n\tqueues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 base-time 0 \\\n\tsched-entry S 0x7f 900000 sched-entry S 0x80 100000 flags 0x2\nUnable to handle kernel paging request at virtual address ffff800009551a08\nInternal error: Oops: 96000007 [#1] PREEMPT SMP\npc : enetc_setup_tc_taprio+0x170/0x47c\nlr : enetc_setup_tc_taprio+0x16c/0x47c\nCall trace:\n enetc_setup_tc_taprio+0x170/0x47c\n enetc_setup_tc+0x38/0x2dc\n taprio_change+0x43c/0x970\n taprio_init+0x188/0x1e0\n qdisc_create+0x114/0x470\n tc_modify_qdisc+0x1fc/0x6c0\n rtnetlink_rcv_msg+0x12c/0x390\r\n\r\nSplit enetc_setup_tc() into separate functions for the PF and for the\nVF drivers. Also remove enetc_qos.o from being included into\nenetc-vf.ko, since it serves absolutely no purpose there.(CVE-2022-48645)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/tegra: dsi: Add missing check for of_find_device_by_node\r\n\r\nAdd check for the return value of of_find_device_by_node() and return\nthe error if it fails in order to avoid NULL pointer dereference.(CVE-2023-52650)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nNTB: fix possible name leak in ntb_register_device()\r\n\r\nIf device_register() fails in ntb_register_device(), the device name\nallocated by dev_set_name() should be freed. As per the comment in\ndevice_register(), callers should use put_device() to give up the\nreference in the error path. So fix this by calling put_device() in the\nerror path so that the name can be freed in kobject_cleanup().\r\n\r\nAs a result of this, put_device() in the error path of\nntb_register_device() is removed and the actual error is returned.\r\n\r\n[mani: reworded commit message](CVE-2023-52652)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nSUNRPC: fix a memleak in gss_import_v2_context\r\n\r\nThe ctx-\u0026gt;mech_used.data allocated by kmemdup is not freed in neither\ngss_import_v2_context nor it only caller gss_krb5_import_sec_context,\nwhich frees ctx on error.\r\n\r\nThus, this patch reform the last call of gss_import_v2_context to the\ngss_krb5_import_ctx_v2, preventing the memleak while keepping the return\nformation.(CVE-2023-52653)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nio_uring: drop any code related to SCM_RIGHTS\r\n\r\nThis is dead code after we dropped support for passing io_uring fds\nover SCM_RIGHTS, get rid of it.(CVE-2023-52656)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: atlantic: eliminate double free in error handling logic\r\n\r\nDriver has a logic leak in ring data allocation/free,\nwhere aq_ring_free could be called multiple times on same ring,\nif system is under stress and got memory allocation error.\r\n\r\nRing pointer was used as an indicator of failure, but this is\nnot correct since only ring data is allocated/deallocated.\nRing itself is an array member.\r\n\r\nChanging ring allocation functions to return error code directly.\nThis simplifies error handling and eliminates aq_ring_free\non higher layer.(CVE-2023-52664)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nALSA: scarlett2: Add clamp() in scarlett2_mixer_ctl_put()\r\n\r\nEnsure the value passed to scarlett2_mixer_ctl_put() is between 0 and\nSCARLETT2_MIXER_MAX_VALUE so we don\u0026apos;t attempt to access outside\nscarlett2_mixer_values[].(CVE-2023-52674)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nACPI: LPIT: Avoid u32 multiplication overflow\r\n\r\nIn lpit_update_residency() there is a possibility of overflow\nin multiplication, if tsc_khz is large enough (\u0026gt; UINT_MAX/1000).\r\n\r\nChange multiplication to mul_u32_u32().\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2023-52683)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncalipso: fix memory leak in netlbl_calipso_add_pass()\r\n\r\nIf IPv6 support is disabled at boot (ipv6.disable=1),\nthe calipso_init() -\u0026gt; netlbl_calipso_ops_register() function isn\u0026apos;t called,\nand the netlbl_calipso_ops_get() function always returns NULL.\nIn this case, the netlbl_calipso_add_pass() function allocates memory\nfor the doi_def variable but doesn\u0026apos;t free it with the calipso_doi_free().\r\n\r\nBUG: memory leak\nunreferenced object 0xffff888011d68180 (size 64):\n comm \u0026quot;syz-executor.1\u0026quot;, pid 10746, jiffies 4295410986 (age 17.928s)\n hex dump (first 32 bytes):\n 00 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 ................\n 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n backtrace:\n [\u0026lt;...\u0026gt;] kmalloc include/linux/slab.h:552 [inline]\n [\u0026lt;...\u0026gt;] netlbl_calipso_add_pass net/netlabel/netlabel_calipso.c:76 [inline]\n [\u0026lt;...\u0026gt;] netlbl_calipso_add+0x22e/0x4f0 net/netlabel/netlabel_calipso.c:111\n [\u0026lt;...\u0026gt;] genl_family_rcv_msg_doit+0x22f/0x330 net/netlink/genetlink.c:739\n [\u0026lt;...\u0026gt;] genl_family_rcv_msg net/netlink/genetlink.c:783 [inline]\n [\u0026lt;...\u0026gt;] genl_rcv_msg+0x341/0x5a0 net/netlink/genetlink.c:800\n [\u0026lt;...\u0026gt;] netlink_rcv_skb+0x14d/0x440 net/netlink/af_netlink.c:2515\n [\u0026lt;...\u0026gt;] genl_rcv+0x29/0x40 net/netlink/genetlink.c:811\n [\u0026lt;...\u0026gt;] netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline]\n [\u0026lt;...\u0026gt;] netlink_unicast+0x54b/0x800 net/netlink/af_netlink.c:1339\n [\u0026lt;...\u0026gt;] netlink_sendmsg+0x90a/0xdf0 net/netlink/af_netlink.c:1934\n [\u0026lt;...\u0026gt;] sock_sendmsg_nosec net/socket.c:651 [inline]\n [\u0026lt;...\u0026gt;] sock_sendmsg+0x157/0x190 net/socket.c:671\n [\u0026lt;...\u0026gt;] ____sys_sendmsg+0x712/0x870 net/socket.c:2342\n [\u0026lt;...\u0026gt;] ___sys_sendmsg+0xf8/0x170 net/socket.c:2396\n [\u0026lt;...\u0026gt;] __sys_sendmsg+0xea/0x1b0 net/socket.c:2429\n [\u0026lt;...\u0026gt;] do_syscall_64+0x30/0x40 arch/x86/entry/common.c:46\n [\u0026lt;...\u0026gt;] entry_SYSCALL_64_after_hwframe+0x61/0xc6\r\n\r\nFound by InfoTeCS on behalf of Linux Verification Center\n(linuxtesting.org) with Syzkaller\r\n\r\n[PM: merged via the LSM tree at Jakub Kicinski request](CVE-2023-52698)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfs/jfs: Add validity check for db_maxag and db_agpref\r\n\r\nBoth db_maxag and db_agpref are used as the index of the\ndb_agfree array, but there is currently no validity check for\ndb_maxag and db_agpref, which can lead to errors.\r\n\r\nThe following is related bug reported by Syzbot:\r\n\r\nUBSAN: array-index-out-of-bounds in fs/jfs/jfs_dmap.c:639:20\nindex 7936 is out of range for type \u0026apos;atomic_t[128]\u0026apos;\r\n\r\nAdd checking that the values of db_maxag and db_agpref are valid\nindexes for the db_agfree array.(CVE-2023-52804)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\njfs: fix array-index-out-of-bounds in diAlloc\r\n\r\nCurrently there is not check against the agno of the iag while\nallocating new inodes to avoid fragmentation problem. Added the check\nwhich is required.(CVE-2023-52805)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: libfc: Fix potential NULL pointer dereference in fc_lport_ptp_setup()\r\n\r\nfc_lport_ptp_setup() did not check the return value of fc_rport_create()\nwhich can return NULL and would cause a NULL pointer dereference. Address\nthis issue by checking return value of fc_rport_create() and log error\nmessage on fc_rport_create() failed.(CVE-2023-52809)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: Fix a null pointer access when the smc_rreg pointer is NULL\r\n\r\nIn certain types of chips, such as VEGA20, reading the amdgpu_regs_smc file could result in an abnormal null pointer access when the smc_rreg pointer is NULL. Below are the steps to reproduce this issue and the corresponding exception log:\r\n\r\n1. Navigate to the directory: /sys/kernel/debug/dri/0\n2. Execute command: cat amdgpu_regs_smc\n3. Exception Log::\n[4005007.702554] BUG: kernel NULL pointer dereference, address: 0000000000000000\n[4005007.702562] #PF: supervisor instruction fetch in kernel mode\n[4005007.702567] #PF: error_code(0x0010) - not-present page\n[4005007.702570] PGD 0 P4D 0\n[4005007.702576] Oops: 0010 [#1] SMP NOPTI\n[4005007.702581] CPU: 4 PID: 62563 Comm: cat Tainted: G OE 5.15.0-43-generic #46-Ubunt u\n[4005007.702590] RIP: 0010:0x0\n[4005007.702598] Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6.\n[4005007.702600] RSP: 0018:ffffa82b46d27da0 EFLAGS: 00010206\n[4005007.702605] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffa82b46d27e68\n[4005007.702609] RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff9940656e0000\n[4005007.702612] RBP: ffffa82b46d27dd8 R08: 0000000000000000 R09: ffff994060c07980\n[4005007.702615] R10: 0000000000020000 R11: 0000000000000000 R12: 00007f5e06753000\n[4005007.702618] R13: ffff9940656e0000 R14: ffffa82b46d27e68 R15: 00007f5e06753000\n[4005007.702622] FS: 00007f5e0755b740(0000) GS:ffff99479d300000(0000) knlGS:0000000000000000\n[4005007.702626] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[4005007.702629] CR2: ffffffffffffffd6 CR3: 00000003253fc000 CR4: 00000000003506e0\n[4005007.702633] Call Trace:\n[4005007.702636] \u0026lt;TASK\u0026gt;\n[4005007.702640] amdgpu_debugfs_regs_smc_read+0xb0/0x120 [amdgpu]\n[4005007.703002] full_proxy_read+0x5c/0x80\n[4005007.703011] vfs_read+0x9f/0x1a0\n[4005007.703019] ksys_read+0x67/0xe0\n[4005007.703023] __x64_sys_read+0x19/0x20\n[4005007.703028] do_syscall_64+0x5c/0xc0\n[4005007.703034] ? do_user_addr_fault+0x1e3/0x670\n[4005007.703040] ? exit_to_user_mode_prepare+0x37/0xb0\n[4005007.703047] ? irqentry_exit_to_user_mode+0x9/0x20\n[4005007.703052] ? irqentry_exit+0x19/0x30\n[4005007.703057] ? exc_page_fault+0x89/0x160\n[4005007.703062] ? asm_exc_page_fault+0x8/0x30\n[4005007.703068] entry_SYSCALL_64_after_hwframe+0x44/0xae\n[4005007.703075] RIP: 0033:0x7f5e07672992\n[4005007.703079] Code: c0 e9 b2 fe ff ff 50 48 8d 3d fa b2 0c 00 e8 c5 1d 02 00 0f 1f 44 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 0f 05 \u0026lt;48\u0026gt; 3d 00 f0 ff ff 77 56 c3 0f 1f 44 00 00 48 83 e c 28 48 89 54 24\n[4005007.703083] RSP: 002b:00007ffe03097898 EFLAGS: 00000246 ORIG_RAX: 0000000000000000\n[4005007.703088] RAX: ffffffffffffffda RBX: 0000000000020000 RCX: 00007f5e07672992\n[4005007.703091] RDX: 0000000000020000 RSI: 00007f5e06753000 RDI: 0000000000000003\n[4005007.703094] RBP: 00007f5e06753000 R08: 00007f5e06752010 R09: 00007f5e06752010\n[4005007.703096] R10: 0000000000000022 R11: 0000000000000246 R12: 0000000000022000\n[4005007.703099] R13: 0000000000000003 R14: 0000000000020000 R15: 0000000000020000\n[4005007.703105] \u0026lt;/TASK\u0026gt;\n[4005007.703107] Modules linked in: nf_tables libcrc32c nfnetlink algif_hash af_alg binfmt_misc nls_ iso8859_1 ipmi_ssif ast intel_rapl_msr intel_rapl_common drm_vram_helper drm_ttm_helper amd64_edac t tm edac_mce_amd kvm_amd ccp mac_hid k10temp kvm acpi_ipmi ipmi_si rapl sch_fq_codel ipmi_devintf ipm i_msghandler msr parport_pc ppdev lp parport mtd pstore_blk efi_pstore ramoops pstore_zone reed_solo mon ip_tables x_tables autofs4 ib_uverbs ib_core amdgpu(OE) amddrm_ttm_helper(OE) amdttm(OE) iommu_v 2 amd_sched(OE) amdkcl(OE) drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops cec rc_core drm igb ahci xhci_pci libahci i2c_piix4 i2c_algo_bit xhci_pci_renesas dca\n[4005007.703184] CR2: 0000000000000000\n[4005007.703188] ---[ en\n---truncated---(CVE-2023-52817)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd: Fix UBSAN array-index-out-of-bounds for SMU7\r\n\r\nFor pptable structs that use flexible array sizes, use flexible arrays.(CVE-2023-52818)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nperf/core: Bail out early if the request AUX area is out of bound\r\n\r\nWhen perf-record with a large AUX area, e.g 4GB, it fails with:\r\n\r\n #perf record -C 0 -m ,4G -e arm_spe_0// -- sleep 1\n failed to mmap with 12 (Cannot allocate memory)\r\n\r\nand it reveals a WARNING with __alloc_pages():\r\n\r\n\t------------[ cut here ]------------\n\tWARNING: CPU: 44 PID: 17573 at mm/page_alloc.c:5568 __alloc_pages+0x1ec/0x248\n\tCall trace:\n\t __alloc_pages+0x1ec/0x248\n\t __kmalloc_large_node+0xc0/0x1f8\n\t __kmalloc_node+0x134/0x1e8\n\t rb_alloc_aux+0xe0/0x298\n\t perf_mmap+0x440/0x660\n\t mmap_region+0x308/0x8a8\n\t do_mmap+0x3c0/0x528\n\t vm_mmap_pgoff+0xf4/0x1b8\n\t ksys_mmap_pgoff+0x18c/0x218\n\t __arm64_sys_mmap+0x38/0x58\n\t invoke_syscall+0x50/0x128\n\t el0_svc_common.constprop.0+0x58/0x188\n\t do_el0_svc+0x34/0x50\n\t el0_svc+0x34/0x108\n\t el0t_64_sync_handler+0xb8/0xc0\n\t el0t_64_sync+0x1a4/0x1a8\r\n\r\n\u0026apos;rb-\u0026gt;aux_pages\u0026apos; allocated by kcalloc() is a pointer array which is used to\nmaintains AUX trace pages. The allocated page for this array is physically\ncontiguous (and virtually contiguous) with an order of 0..MAX_ORDER. If the\nsize of pointer array crosses the limitation set by MAX_ORDER, it reveals a\nWARNING.\r\n\r\nSo bail out early with -ENOMEM if the request AUX area is out of bound,\ne.g.:\r\n\r\n #perf record -C 0 -m ,4G -e arm_spe_0// -- sleep 1\n failed to mmap with 12 (Cannot allocate memory)(CVE-2023-52835)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nInput: synaptics-rmi4 - fix use after free in rmi_unregister_function()\r\n\r\nThe put_device() calls rmi_release_function() which frees \u0026quot;fn\u0026quot; so the\ndereference on the next line \u0026quot;fn-\u0026gt;num_of_irqs\u0026quot; is a use after free.\nMove the put_device() to the end to fix this.(CVE-2023-52840)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: vidtv: psi: Add check for kstrdup\r\n\r\nAdd check for the return value of kstrdup() and return the error\nif it fails in order to avoid NULL pointer dereference.(CVE-2023-52844)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntipc: Change nla_policy for bearer-related names to NLA_NUL_STRING\r\n\r\nsyzbot reported the following uninit-value access issue [1]:\r\n\r\n=====================================================\nBUG: KMSAN: uninit-value in strlen lib/string.c:418 [inline]\nBUG: KMSAN: uninit-value in strstr+0xb8/0x2f0 lib/string.c:756\n strlen lib/string.c:418 [inline]\n strstr+0xb8/0x2f0 lib/string.c:756\n tipc_nl_node_reset_link_stats+0x3ea/0xb50 net/tipc/node.c:2595\n genl_family_rcv_msg_doit net/netlink/genetlink.c:971 [inline]\n genl_family_rcv_msg net/netlink/genetlink.c:1051 [inline]\n genl_rcv_msg+0x11ec/0x1290 net/netlink/genetlink.c:1066\n netlink_rcv_skb+0x371/0x650 net/netlink/af_netlink.c:2545\n genl_rcv+0x40/0x60 net/netlink/genetlink.c:1075\n netlink_unicast_kernel net/netlink/af_netlink.c:1342 [inline]\n netlink_unicast+0xf47/0x1250 net/netlink/af_netlink.c:1368\n netlink_sendmsg+0x1238/0x13d0 net/netlink/af_netlink.c:1910\n sock_sendmsg_nosec net/socket.c:730 [inline]\n sock_sendmsg net/socket.c:753 [inline]\n ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2541\n ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2595\n __sys_sendmsg net/socket.c:2624 [inline]\n __do_sys_sendmsg net/socket.c:2633 [inline]\n __se_sys_sendmsg net/socket.c:2631 [inline]\n __x64_sys_sendmsg+0x307/0x490 net/socket.c:2631\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\r\n\r\nUninit was created at:\n slab_post_alloc_hook+0x12f/0xb70 mm/slab.h:767\n slab_alloc_node mm/slub.c:3478 [inline]\n kmem_cache_alloc_node+0x577/0xa80 mm/slub.c:3523\n kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:559\n __alloc_skb+0x318/0x740 net/core/skbuff.c:650\n alloc_skb include/linux/skbuff.h:1286 [inline]\n netlink_alloc_large_skb net/netlink/af_netlink.c:1214 [inline]\n netlink_sendmsg+0xb34/0x13d0 net/netlink/af_netlink.c:1885\n sock_sendmsg_nosec net/socket.c:730 [inline]\n sock_sendmsg net/socket.c:753 [inline]\n ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2541\n ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2595\n __sys_sendmsg net/socket.c:2624 [inline]\n __do_sys_sendmsg net/socket.c:2633 [inline]\n __se_sys_sendmsg net/socket.c:2631 [inline]\n __x64_sys_sendmsg+0x307/0x490 net/socket.c:2631\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\r\n\r\nTIPC bearer-related names including link names must be null-terminated\nstrings. If a link name which is not null-terminated is passed through\nnetlink, strstr() and similar functions can cause buffer overrun. This\ncauses the above issue.\r\n\r\nThis patch changes the nla_policy for bearer-related names from NLA_STRING\nto NLA_NUL_STRING. This resolves the issue by ensuring that only\nnull-terminated strings are accepted as bearer-related names.\r\n\r\nsyzbot reported similar uninit-value issue related to bearer names [2]. The\nroot cause of this issue is that a non-null-terminated bearer name was\npassed. This patch also resolved this issue.(CVE-2023-52845)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nhsr: Prevent use after free in prp_create_tagged_frame()\r\n\r\nThe prp_fill_rct() function can fail. In that situation, it frees the\nskb and returns NULL. Meanwhile on the success path, it returns the\noriginal skb. So it\u0026apos;s straight forward to fix bug by using the returned\nvalue.(CVE-2023-52846)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: bttv: fix use after free error due to btv-\u0026gt;timeout timer\r\n\r\nThere may be some a race condition between timer function\nbttv_irq_timeout and bttv_remove. The timer is setup in\nprobe and there is no timer_delete operation in remove\nfunction. When it hit kfree btv, the function might still be\ninvoked, which will cause use after free bug.\r\n\r\nThis bug is found by static analysis, it may be false positive.\r\n\r\nFix it by adding del_timer_sync invoking to the remove function.\r\n\r\ncpu0 cpu1\n bttv_probe\n -\u0026gt;timer_setup\n -\u0026gt;bttv_set_dma\n -\u0026gt;mod_timer;\nbttv_remove\n -\u0026gt;kfree(btv);\n -\u0026gt;bttv_irq_timeout\n -\u0026gt;USE btv(CVE-2023-52847)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npadata: Fix refcnt handling in padata_free_shell()\r\n\r\nIn a high-load arm64 environment, the pcrypt_aead01 test in LTP can lead\nto system UAF (Use-After-Free) issues. Due to the lengthy analysis of\nthe pcrypt_aead01 function call, I\u0026apos;ll describe the problem scenario\nusing a simplified model:\r\n\r\nSuppose there\u0026apos;s a user of padata named `user_function` that adheres to\nthe padata requirement of calling `padata_free_shell` after `serial()`\nhas been invoked, as demonstrated in the following code:\r\n\r\n```c\nstruct request {\n struct padata_priv padata;\n struct completion *done;\n};\r\n\r\nvoid parallel(struct padata_priv *padata) {\n do_something();\n}\r\n\r\nvoid serial(struct padata_priv *padata) {\n struct request *request = container_of(padata,\n \t\t\t\tstruct request,\n\t\t\t\tpadata);\n complete(request-\u0026gt;done);\n}\r\n\r\nvoid user_function() {\n DECLARE_COMPLETION(done)\n padata-\u0026gt;parallel = parallel;\n padata-\u0026gt;serial = serial;\n padata_do_parallel();\n wait_for_completion(\u0026amp;done);\n padata_free_shell();\n}\n```\r\n\r\nIn the corresponding padata.c file, there\u0026apos;s the following code:\r\n\r\n```c\nstatic void padata_serial_worker(struct work_struct *serial_work) {\n ...\n cnt = 0;\r\n\r\n while (!list_empty(\u0026amp;local_list)) {\n ...\n padata-\u0026gt;serial(padata);\n cnt++;\n }\r\n\r\n local_bh_enable();\r\n\r\n if (refcount_sub_and_test(cnt, \u0026amp;pd-\u0026gt;refcnt))\n padata_free_pd(pd);\n}\n```\r\n\r\nBecause of the high system load and the accumulation of unexecuted\nsoftirq at this moment, `local_bh_enable()` in padata takes longer\nto execute than usual. Subsequently, when accessing `pd-\u0026gt;refcnt`,\n`pd` has already been released by `padata_free_shell()`, resulting\nin a UAF issue with `pd-\u0026gt;refcnt`.\r\n\r\nThe fix is straightforward: add `refcount_dec_and_test` before calling\n`padata_free_pd` in `padata_free_shell`.(CVE-2023-52854)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nclk: mediatek: clk-mt7629: Add check for mtk_alloc_clk_data\r\n\r\nAdd the check for the return value of mtk_alloc_clk_data() in order to\navoid NULL pointer dereference.(CVE-2023-52858)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nhwmon: (axi-fan-control) Fix possible NULL pointer dereference\r\n\r\naxi_fan_control_irq_handler(), dependent on the private\naxi_fan_control_data structure, might be called before the hwmon\ndevice is registered. That will cause an \u0026quot;Unable to handle kernel\nNULL pointer dereference\u0026quot; error.(CVE-2023-52863)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/radeon: possible buffer overflow\r\n\r\nBuffer \u0026apos;afmt_status\u0026apos; of size 6 could overflow, since index \u0026apos;afmt_idx\u0026apos; is\nchecked after access.(CVE-2023-52867)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nthermal: core: prevent potential string overflow\r\n\r\nThe dev-\u0026gt;id value comes from ida_alloc() so it\u0026apos;s a number between zero\nand INT_MAX. If it\u0026apos;s too high then these sprintf()s will overflow.(CVE-2023-52868)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npstore/platform: Add check for kstrdup\r\n\r\nAdd check for the return value of kstrdup() and return the error\nif it fails in order to avoid NULL pointer dereference.(CVE-2023-52869)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nclk: mediatek: clk-mt7629-eth: 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-52876)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntracing: Have trace_event_file have ref counters\r\n\r\nThe following can crash the kernel:\r\n\r\n # cd /sys/kernel/tracing\n # echo \u0026apos;p:sched schedule\u0026apos; \u0026gt; kprobe_events\n # exec 5\u0026gt;\u0026gt;events/kprobes/sched/enable\n # \u0026gt; kprobe_events\n # exec 5\u0026gt;\u0026amp;-\r\n\r\nThe above commands:\r\n\r\n 1. Change directory to the tracefs directory\n 2. Create a kprobe event (doesn\u0026apos;t matter what one)\n 3. Open bash file descriptor 5 on the enable file of the kprobe event\n 4. Delete the kprobe event (removes the files too)\n 5. Close the bash file descriptor 5\r\n\r\nThe above causes a crash!\r\n\r\n BUG: kernel NULL pointer dereference, address: 0000000000000028\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\n PGD 0 P4D 0\n Oops: 0000 [#1] PREEMPT SMP PTI\n CPU: 6 PID: 877 Comm: bash Not tainted 6.5.0-rc4-test-00008-g2c6b6b1029d4-dirty #186\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014\n RIP: 0010:tracing_release_file_tr+0xc/0x50\r\n\r\nWhat happens here is that the kprobe event creates a trace_event_file\n\u0026quot;file\u0026quot; descriptor that represents the file in tracefs to the event. It\nmaintains state of the event (is it enabled for the given instance?).\nOpening the \u0026quot;enable\u0026quot; file gets a reference to the event \u0026quot;file\u0026quot; descriptor\nvia the open file descriptor. When the kprobe event is deleted, the file is\nalso deleted from the tracefs system which also frees the event \u0026quot;file\u0026quot;\ndescriptor.\r\n\r\nBut as the tracefs file is still opened by user space, it will not be\ntotally removed until the final dput() is called on it. But this is not\ntrue with the event \u0026quot;file\u0026quot; descriptor that is already freed. If the user\ndoes a write to or simply closes the file descriptor it will reference the\nevent \u0026quot;file\u0026quot; descriptor that was just freed, causing a use-after-free bug.\r\n\r\nTo solve this, add a ref count to the event \u0026quot;file\u0026quot; descriptor as well as a\nnew flag called \u0026quot;FREED\u0026quot;. The \u0026quot;file\u0026quot; will not be freed until the last\nreference is released. But the FREE flag will be set when the event is\nremoved to prevent any more modifications to that event from happening,\neven if there\u0026apos;s still a reference to the event \u0026quot;file\u0026quot; descriptor.(CVE-2023-52879)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nf_tables: mark set as dead when unbinding anonymous set with timeout\r\n\r\nWhile the rhashtable set gc runs asynchronously, a race allows it to\ncollect elements from anonymous sets with timeouts while it is being\nreleased from the commit path.\r\n\r\nMingi Cho originally reported this issue in a different path in 6.1.x\nwith a pipapo set with low timeouts which is not possible upstream since\n7395dfacfff6 (\u0026quot;netfilter: nf_tables: use timestamp to check for set\nelement timeout\u0026quot;).\r\n\r\nFix this by setting on the dead flag for anonymous sets to skip async gc\nin this case.\r\n\r\nAccording to 08e4c8c5919f (\u0026quot;netfilter: nf_tables: mark newset as dead on\ntransaction abort\u0026quot;), Florian plans to accelerate abort path by releasing\nobjects via workqueue, therefore, this sets on the dead flag for abort\npath too.(CVE-2024-26643)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwireguard: netlink: access device through ctx instead of peer\r\n\r\nThe previous commit fixed a bug that led to a NULL peer-\u0026gt;device being\ndereferenced. It\u0026apos;s actually easier and faster performance-wise to\ninstead get the device from ctx-\u0026gt;wg. This semantically makes more sense\ntoo, since ctx-\u0026gt;wg-\u0026gt;peer_allowedips.seq is compared with\nctx-\u0026gt;allowedips_seq, basing them both in ctx. This also acts as a\ndefence in depth provision against freed peers.(CVE-2024-26950)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: prevent kernel bug at submit_bh_wbc()\r\n\r\nFix a bug where nilfs_get_block() returns a successful status when\nsearching and inserting the specified block both fail inconsistently. If\nthis inconsistent behavior is not due to a previously fixed bug, then an\nunexpected race is occurring, so return a temporary error -EAGAIN instead.\r\n\r\nThis prevents callers such as __block_write_begin_int() from requesting a\nread into a buffer that is not mapped, which would cause the BUG_ON check\nfor the BH_Mapped flag in submit_bh_wbc() to fail.(CVE-2024-26955)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ns390/zcrypt: fix reference counting on zcrypt card objects\r\n\r\nTests with hot-plugging crytpo cards on KVM guests with debug\nkernel build revealed an use after free for the load field of\nthe struct zcrypt_card. The reason was an incorrect reference\nhandling of the zcrypt card object which could lead to a free\nof the zcrypt card object while it was still in use.\r\n\r\nThis is an example of the slab message:\r\n\r\n kernel: 0x00000000885a7512-0x00000000885a7513 @offset=1298. First byte 0x68 instead of 0x6b\n kernel: Allocated in zcrypt_card_alloc+0x36/0x70 [zcrypt] age=18046 cpu=3 pid=43\n kernel: kmalloc_trace+0x3f2/0x470\n kernel: zcrypt_card_alloc+0x36/0x70 [zcrypt]\n kernel: zcrypt_cex4_card_probe+0x26/0x380 [zcrypt_cex4]\n kernel: ap_device_probe+0x15c/0x290\n kernel: really_probe+0xd2/0x468\n kernel: driver_probe_device+0x40/0xf0\n kernel: __device_attach_driver+0xc0/0x140\n kernel: bus_for_each_drv+0x8c/0xd0\n kernel: __device_attach+0x114/0x198\n kernel: bus_probe_device+0xb4/0xc8\n kernel: device_add+0x4d2/0x6e0\n kernel: ap_scan_adapter+0x3d0/0x7c0\n kernel: ap_scan_bus+0x5a/0x3b0\n kernel: ap_scan_bus_wq_callback+0x40/0x60\n kernel: process_one_work+0x26e/0x620\n kernel: worker_thread+0x21c/0x440\n kernel: Freed in zcrypt_card_put+0x54/0x80 [zcrypt] age=9024 cpu=3 pid=43\n kernel: kfree+0x37e/0x418\n kernel: zcrypt_card_put+0x54/0x80 [zcrypt]\n kernel: ap_device_remove+0x4c/0xe0\n kernel: device_release_driver_internal+0x1c4/0x270\n kernel: bus_remove_device+0x100/0x188\n kernel: device_del+0x164/0x3c0\n kernel: device_unregister+0x30/0x90\n kernel: ap_scan_adapter+0xc8/0x7c0\n kernel: ap_scan_bus+0x5a/0x3b0\n kernel: ap_scan_bus_wq_callback+0x40/0x60\n kernel: process_one_work+0x26e/0x620\n kernel: worker_thread+0x21c/0x440\n kernel: kthread+0x150/0x168\n kernel: __ret_from_fork+0x3c/0x58\n kernel: ret_from_fork+0xa/0x30\n kernel: Slab 0x00000372022169c0 objects=20 used=18 fp=0x00000000885a7c88 flags=0x3ffff00000000a00(workingset|slab|node=0|zone=1|lastcpupid=0x1ffff)\n kernel: Object 0x00000000885a74b8 @offset=1208 fp=0x00000000885a7c88\n kernel: Redzone 00000000885a74b0: bb bb bb bb bb bb bb bb ........\n kernel: Object 00000000885a74b8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk\n kernel: Object 00000000885a74c8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk\n kernel: Object 00000000885a74d8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk\n kernel: Object 00000000885a74e8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk\n kernel: Object 00000000885a74f8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk\n kernel: Object 00000000885a7508: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 68 4b 6b 6b 6b a5 kkkkkkkkkkhKkkk.\n kernel: Redzone 00000000885a7518: bb bb bb bb bb bb bb bb ........\n kernel: Padding 00000000885a756c: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZ\n kernel: CPU: 0 PID: 387 Comm: systemd-udevd Not tainted 6.8.0-HF #2\n kernel: Hardware name: IBM 3931 A01 704 (KVM/Linux)\n kernel: Call Trace:\n kernel: [\u0026lt;00000000ca5ab5b8\u0026gt;] dump_stack_lvl+0x90/0x120\n kernel: [\u0026lt;00000000c99d78bc\u0026gt;] check_bytes_and_report+0x114/0x140\n kernel: [\u0026lt;00000000c99d53cc\u0026gt;] check_object+0x334/0x3f8\n kernel: [\u0026lt;00000000c99d820c\u0026gt;] alloc_debug_processing+0xc4/0x1f8\n kernel: [\u0026lt;00000000c99d852e\u0026gt;] get_partial_node.part.0+0x1ee/0x3e0\n kernel: [\u0026lt;00000000c99d94ec\u0026gt;] ___slab_alloc+0xaf4/0x13c8\n kernel: [\u0026lt;00000000c99d9e38\u0026gt;] __slab_alloc.constprop.0+0x78/0xb8\n kernel: [\u0026lt;00000000c99dc8dc\u0026gt;] __kmalloc+0x434/0x590\n kernel: [\u0026lt;00000000c9b4c0ce\u0026gt;] ext4_htree_store_dirent+0x4e/0x1c0\n kernel: [\u0026lt;00000000c9b908a2\u0026gt;] htree_dirblock_to_tree+0x17a/0x3f0\n kernel: \n---truncated---(CVE-2024-26957)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnfs: fix UAF in direct writes\r\n\r\nIn production we have been hitting the following warning consistently\r\n\r\n------------[ cut here ]------------\nrefcount_t: underflow; use-after-free.\nWARNING: CPU: 17 PID: 1800359 at lib/refcount.c:28 refcount_warn_saturate+0x9c/0xe0\nWorkqueue: nfsiod nfs_direct_write_schedule_work [nfs]\nRIP: 0010:refcount_warn_saturate+0x9c/0xe0\nPKRU: 55555554\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? __warn+0x9f/0x130\n ? refcount_warn_saturate+0x9c/0xe0\n ? report_bug+0xcc/0x150\n ? handle_bug+0x3d/0x70\n ? exc_invalid_op+0x16/0x40\n ? asm_exc_invalid_op+0x16/0x20\n ? refcount_warn_saturate+0x9c/0xe0\n nfs_direct_write_schedule_work+0x237/0x250 [nfs]\n process_one_work+0x12f/0x4a0\n worker_thread+0x14e/0x3b0\n ? ZSTD_getCParams_internal+0x220/0x220\n kthread+0xdc/0x120\n ? __btf_name_valid+0xa0/0xa0\n ret_from_fork+0x1f/0x30\r\n\r\nThis is because we\u0026apos;re completing the nfs_direct_request twice in a row.\r\n\r\nThe source of this is when we have our commit requests to submit, we\nprocess them and send them off, and then in the completion path for the\ncommit requests we have\r\n\r\nif (nfs_commit_end(cinfo.mds))\n\tnfs_direct_write_complete(dreq);\r\n\r\nHowever since we\u0026apos;re submitting asynchronous requests we sometimes have\none that completes before we submit the next one, so we end up calling\ncomplete on the nfs_direct_request twice.\r\n\r\nThe only other place we use nfs_generic_commit_list() is in\n__nfs_commit_inode, which wraps this call in a\r\n\r\nnfs_commit_begin();\nnfs_commit_end();\r\n\r\nWhich is a common pattern for this style of completion handling, one\nthat is also repeated in the direct code with get_dreq()/put_dreq()\ncalls around where we process events as well as in the completion paths.\r\n\r\nFix this by using the same pattern for the commit requests.\r\n\r\nBefore with my 200 node rocksdb stress running this warning would pop\nevery 10ish minutes. With my patch the stress test has been running for\nseveral hours without popping.(CVE-2024-26958)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmac802154: fix llsec key resources release in mac802154_llsec_key_del\r\n\r\nmac802154_llsec_key_del() can free resources of a key directly without\nfollowing the RCU rules for waiting before the end of a grace period. This\nmay lead to use-after-free in case llsec_lookup_key() is traversing the\nlist of keys in parallel with a key deletion:\r\n\r\nrefcount_t: addition on 0; use-after-free.\nWARNING: CPU: 4 PID: 16000 at lib/refcount.c:25 refcount_warn_saturate+0x162/0x2a0\nModules linked in:\nCPU: 4 PID: 16000 Comm: wpan-ping Not tainted 6.7.0 #19\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014\nRIP: 0010:refcount_warn_saturate+0x162/0x2a0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n llsec_lookup_key.isra.0+0x890/0x9e0\n mac802154_llsec_encrypt+0x30c/0x9c0\n ieee802154_subif_start_xmit+0x24/0x1e0\n dev_hard_start_xmit+0x13e/0x690\n sch_direct_xmit+0x2ae/0xbc0\n __dev_queue_xmit+0x11dd/0x3c20\n dgram_sendmsg+0x90b/0xd60\n __sys_sendto+0x466/0x4c0\n __x64_sys_sendto+0xe0/0x1c0\n do_syscall_64+0x45/0xf0\n entry_SYSCALL_64_after_hwframe+0x6e/0x76\r\n\r\nAlso, ieee802154_llsec_key_entry structures are not freed by\nmac802154_llsec_key_del():\r\n\r\nunreferenced object 0xffff8880613b6980 (size 64):\n comm \u0026quot;iwpan\u0026quot;, pid 2176, jiffies 4294761134 (age 60.475s)\n hex dump (first 32 bytes):\n 78 0d 8f 18 80 88 ff ff 22 01 00 00 00 00 ad de x.......\u0026quot;.......\n 00 00 00 00 00 00 00 00 03 00 cd ab 00 00 00 00 ................\n backtrace:\n [\u0026lt;ffffffff81dcfa62\u0026gt;] __kmem_cache_alloc_node+0x1e2/0x2d0\n [\u0026lt;ffffffff81c43865\u0026gt;] kmalloc_trace+0x25/0xc0\n [\u0026lt;ffffffff88968b09\u0026gt;] mac802154_llsec_key_add+0xac9/0xcf0\n [\u0026lt;ffffffff8896e41a\u0026gt;] ieee802154_add_llsec_key+0x5a/0x80\n [\u0026lt;ffffffff8892adc6\u0026gt;] nl802154_add_llsec_key+0x426/0x5b0\n [\u0026lt;ffffffff86ff293e\u0026gt;] genl_family_rcv_msg_doit+0x1fe/0x2f0\n [\u0026lt;ffffffff86ff46d1\u0026gt;] genl_rcv_msg+0x531/0x7d0\n [\u0026lt;ffffffff86fee7a9\u0026gt;] netlink_rcv_skb+0x169/0x440\n [\u0026lt;ffffffff86ff1d88\u0026gt;] genl_rcv+0x28/0x40\n [\u0026lt;ffffffff86fec15c\u0026gt;] netlink_unicast+0x53c/0x820\n [\u0026lt;ffffffff86fecd8b\u0026gt;] netlink_sendmsg+0x93b/0xe60\n [\u0026lt;ffffffff86b91b35\u0026gt;] ____sys_sendmsg+0xac5/0xca0\n [\u0026lt;ffffffff86b9c3dd\u0026gt;] ___sys_sendmsg+0x11d/0x1c0\n [\u0026lt;ffffffff86b9c65a\u0026gt;] __sys_sendmsg+0xfa/0x1d0\n [\u0026lt;ffffffff88eadbf5\u0026gt;] do_syscall_64+0x45/0xf0\n [\u0026lt;ffffffff890000ea\u0026gt;] entry_SYSCALL_64_after_hwframe+0x6e/0x76\r\n\r\nHandle the proper resource release in the RCU callback function\nmac802154_llsec_key_del_rcu().\r\n\r\nNote that if llsec_lookup_key() finds a key, it gets a refcount via\nllsec_key_get() and locally copies key id from key_entry (which is a\nlist element). So it\u0026apos;s safe to call llsec_key_put() and free the list\nentry after the RCU grace period elapses.\r\n\r\nFound by Linux Verification Center (linuxtesting.org).(CVE-2024-26961)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nclk: qcom: mmcc-msm8974: fix terminating of frequency table arrays\r\n\r\nThe frequency table arrays are supposed to be terminated with an\nempty element. Add such entry to the end of the arrays where it\nis missing in order to avoid possible out-of-bound access when\nthe table is traversed by functions like qcom_find_freq() or\nqcom_find_freq_floor().\r\n\r\nOnly compile tested.(CVE-2024-26965)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nubifs: ubifs_symlink: Fix memleak of inode-\u0026gt;i_link in error path\r\n\r\nFor error handling path in ubifs_symlink(), inode will be marked as\nbad first, then iput() is invoked. If inode-\u0026gt;i_link is initialized by\nfscrypt_encrypt_symlink() in encryption scenario, inode-\u0026gt;i_link won\u0026apos;t\nbe freed by callchain ubifs_free_inode -\u0026gt; fscrypt_free_inode in error\nhandling path, because make_bad_inode() has changed \u0026apos;inode-\u0026gt;i_mode\u0026apos; as\n\u0026apos;S_IFREG\u0026apos;.\nFollowing kmemleak is easy to be reproduced by injecting error in\nubifs_jnl_update() when doing symlink in encryption scenario:\n unreferenced object 0xffff888103da3d98 (size 8):\n comm \u0026quot;ln\u0026quot;, pid 1692, jiffies 4294914701 (age 12.045s)\n backtrace:\n kmemdup+0x32/0x70\n __fscrypt_encrypt_symlink+0xed/0x1c0\n ubifs_symlink+0x210/0x300 [ubifs]\n vfs_symlink+0x216/0x360\n do_symlinkat+0x11a/0x190\n do_syscall_64+0x3b/0xe0\nThere are two ways fixing it:\n 1. Remove make_bad_inode() in error handling path. We can do that\n because ubifs_evict_inode() will do same processes for good\n symlink inode and bad symlink inode, for inode-\u0026gt;i_nlink checking\n is before is_bad_inode().\n 2. Free inode-\u0026gt;i_link before marking inode bad.\nMethod 2 is picked, it has less influence, personally, I think.(CVE-2024-26972)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nKVM: Always flush async #PF workqueue when vCPU is being destroyed\r\n\r\nAlways flush the per-vCPU async #PF workqueue when a vCPU is clearing its\ncompletion queue, e.g. when a VM and all its vCPUs is being destroyed.\nKVM must ensure that none of its workqueue callbacks is running when the\nlast reference to the KVM _module_ is put. Gifting a reference to the\nassociated VM prevents the workqueue callback from dereferencing freed\nvCPU/VM memory, but does not prevent the KVM module from being unloaded\nbefore the callback completes.\r\n\r\nDrop the misguided VM refcount gifting, as calling kvm_put_kvm() from\nasync_pf_execute() if kvm_put_kvm() flushes the async #PF workqueue will\nresult in deadlock. async_pf_execute() can\u0026apos;t return until kvm_put_kvm()\nfinishes, and kvm_put_kvm() can\u0026apos;t return until async_pf_execute() finishes:\r\n\r\n WARNING: CPU: 8 PID: 251 at virt/kvm/kvm_main.c:1435 kvm_put_kvm+0x2d/0x320 [kvm]\n Modules linked in: vhost_net vhost vhost_iotlb tap kvm_intel kvm irqbypass\n CPU: 8 PID: 251 Comm: kworker/8:1 Tainted: G W 6.6.0-rc1-e7af8d17224a-x86/gmem-vm #119\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015\n Workqueue: events async_pf_execute [kvm]\n RIP: 0010:kvm_put_kvm+0x2d/0x320 [kvm]\n Call Trace:\n \u0026lt;TASK\u0026gt;\n async_pf_execute+0x198/0x260 [kvm]\n process_one_work+0x145/0x2d0\n worker_thread+0x27e/0x3a0\n kthread+0xba/0xe0\n ret_from_fork+0x2d/0x50\n ret_from_fork_asm+0x11/0x20\n \u0026lt;/TASK\u0026gt;\n ---[ end trace 0000000000000000 ]---\n INFO: task kworker/8:1:251 blocked for more than 120 seconds.\n Tainted: G W 6.6.0-rc1-e7af8d17224a-x86/gmem-vm #119\n \u0026quot;echo 0 \u0026gt; /proc/sys/kernel/hung_task_timeout_secs\u0026quot; disables this message.\n task:kworker/8:1 state:D stack:0 pid:251 ppid:2 flags:0x00004000\n Workqueue: events async_pf_execute [kvm]\n Call Trace:\n \u0026lt;TASK\u0026gt;\n __schedule+0x33f/0xa40\n schedule+0x53/0xc0\n schedule_timeout+0x12a/0x140\n __wait_for_common+0x8d/0x1d0\n __flush_work.isra.0+0x19f/0x2c0\n kvm_clear_async_pf_completion_queue+0x129/0x190 [kvm]\n kvm_arch_destroy_vm+0x78/0x1b0 [kvm]\n kvm_put_kvm+0x1c1/0x320 [kvm]\n async_pf_execute+0x198/0x260 [kvm]\n process_one_work+0x145/0x2d0\n worker_thread+0x27e/0x3a0\n kthread+0xba/0xe0\n ret_from_fork+0x2d/0x50\n ret_from_fork_asm+0x11/0x20\n \u0026lt;/TASK\u0026gt;\r\n\r\nIf kvm_clear_async_pf_completion_queue() actually flushes the workqueue,\nthen there\u0026apos;s no need to gift async_pf_execute() a reference because all\ninvocations of async_pf_execute() will be forced to complete before the\nvCPU and its VM are destroyed/freed. And that in turn fixes the module\nunloading bug as __fput() won\u0026apos;t do module_put() on the last vCPU reference\nuntil the vCPU has been freed, e.g. if closing the vCPU file also puts the\nlast reference to the KVM module.\r\n\r\nNote that kvm_check_async_pf_completion() may also take the work item off\nthe completion queue and so also needs to flush the work queue, as the\nwork will not be seen by kvm_clear_async_pf_completion_queue(). Waiting\non the workqueue could theoretically delay a vCPU due to waiting for the\nwork to complete, but that\u0026apos;s a very, very small chance, and likely a very\nsmall delay. kvm_arch_async_page_present_queued() unconditionally makes a\nnew request, i.e. will effectively delay entering the guest, so the\nremaining work is really just:\r\n\r\n trace_kvm_async_pf_completed(addr, cr2_or_gpa);\r\n\r\n __kvm_vcpu_wake_up(vcpu);\r\n\r\n mmput(mm);\r\n\r\nand mmput() can\u0026apos;t drop the last reference to the page tables if the vCPU is\nstill alive, i.e. the vCPU won\u0026apos;t get stuck tearing down page tables.\r\n\r\nAdd a helper to do the flushing, specifically to deal with \u0026quot;wakeup all\u0026quot;\nwork items, as they aren\u0026apos;t actually work items, i.e. are never placed in a\nworkqueue. Trying to flush a bogus workqueue entry rightly makes\n__flush_work() complain (kudos to whoever added that sanity check).\r\n\r\nNote, commit 5f6de5cbebee (\u0026quot;KVM: Prevent module exit until al\n---truncated---(CVE-2024-26976)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nSquashfs: check the inode number is not the invalid value of zero\r\n\r\nSyskiller has produced an out of bounds access in fill_meta_index().\r\n\r\nThat out of bounds access is ultimately caused because the inode\nhas an inode number with the invalid value of zero, which was not checked.\r\n\r\nThe reason this causes the out of bounds access is due to following\nsequence of events:\r\n\r\n1. Fill_meta_index() is called to allocate (via empty_meta_index())\n and fill a metadata index. It however suffers a data read error\n and aborts, invalidating the newly returned empty metadata index.\n It does this by setting the inode number of the index to zero,\n which means unused (zero is not a valid inode number).\r\n\r\n2. When fill_meta_index() is subsequently called again on another\n read operation, locate_meta_index() returns the previous index\n because it matches the inode number of 0. Because this index\n has been returned it is expected to have been filled, and because\n it hasn\u0026apos;t been, an out of bounds access is performed.\r\n\r\nThis patch adds a sanity check which checks that the inode number\nis not zero when the inode is created and returns -EINVAL if it is.\r\n\r\n[phillip@squashfs.org.uk: whitespace fix]\n Link: https://lkml.kernel.org/r/20240409204723.446925-1-phillip@squashfs.org.uk(CVE-2024-26982)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfs: sysfs: Fix reference leak in sysfs_break_active_protection()\r\n\r\nThe sysfs_break_active_protection() routine has an obvious reference\nleak in its error path. If the call to kernfs_find_and_get() fails then\nkn will be NULL, so the companion sysfs_unbreak_active_protection()\nroutine won\u0026apos;t get called (and would only cause an access violation by\ntrying to dereference kn-\u0026gt;parent if it was called). As a result, the\nreference to kobj acquired at the start of the function will never be\nreleased.\r\n\r\nFix the leak by adding an explicit kobject_put() call when kn is NULL.(CVE-2024-26993)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nspeakup: Avoid crash on very long word\r\n\r\nIn case a console is set up really large and contains a really long word\n(\u0026gt; 256 characters), we have to stop before the length of the word buffer.(CVE-2024-26994)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nserial/pmac_zilog: Remove flawed mitigation for rx irq flood\r\n\r\nThe mitigation was intended to stop the irq completely. That may be\nbetter than a hard lock-up but it turns out that you get a crash anyway\nif you\u0026apos;re using pmac_zilog as a serial console:\r\n\r\nttyPZ0: pmz: rx irq flood !\nBUG: spinlock recursion on CPU#0, swapper/0\r\n\r\nThat\u0026apos;s because the pr_err() call in pmz_receive_chars() results in\npmz_console_write() attempting to lock a spinlock already locked in\npmz_interrupt(). With CONFIG_DEBUG_SPINLOCK=y, this produces a fatal\nBUG splat. The spinlock in question is the one in struct uart_port.\r\n\r\nEven when it\u0026apos;s not fatal, the serial port rx function ceases to work.\nAlso, the iteration limit doesn\u0026apos;t play nicely with QEMU, as can be\nseen in the bug report linked below.\r\n\r\nA web search for other reports of the error message \u0026quot;pmz: rx irq flood\u0026quot;\ndidn\u0026apos;t produce anything. So I don\u0026apos;t think this code is needed any more.\nRemove it.(CVE-2024-26999)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nserial: mxs-auart: add spinlock around changing cts state\r\n\r\nThe uart_handle_cts_change() function in serial_core expects the caller\nto hold uport-\u0026gt;lock. For example, I have seen the below kernel splat,\nwhen the Bluetooth driver is loaded on an i.MX28 board.\r\n\r\n [ 85.119255] ------------[ cut here ]------------\n [ 85.124413] WARNING: CPU: 0 PID: 27 at /drivers/tty/serial/serial_core.c:3453 uart_handle_cts_change+0xb4/0xec\n [ 85.134694] Modules linked in: hci_uart bluetooth ecdh_generic ecc wlcore_sdio configfs\n [ 85.143314] CPU: 0 PID: 27 Comm: kworker/u3:0 Not tainted 6.6.3-00021-gd62a2f068f92 #1\n [ 85.151396] Hardware name: Freescale MXS (Device Tree)\n [ 85.156679] Workqueue: hci0 hci_power_on [bluetooth]\n (...)\n [ 85.191765] uart_handle_cts_change from mxs_auart_irq_handle+0x380/0x3f4\n [ 85.198787] mxs_auart_irq_handle from __handle_irq_event_percpu+0x88/0x210\n (...)(CVE-2024-27000)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm: nv04: Fix out of bounds access\r\n\r\nWhen Output Resource (dcb-\u0026gt;or) value is assigned in\nfabricate_dcb_output(), there may be out of bounds access to\ndac_users array in case dcb-\u0026gt;or is zero because ffs(dcb-\u0026gt;or) is\nused as index there.\nThe \u0026apos;or\u0026apos; argument of fabricate_dcb_output() must be interpreted as a\nnumber of bit to set, not value.\r\n\r\nUtilize macros from \u0026apos;enum nouveau_or\u0026apos; in calls instead of hardcoding.\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-27008)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/sched: Fix mirred deadlock on device recursion\r\n\r\nWhen the mirred action is used on a classful egress qdisc and a packet is\nmirrored or redirected to self we hit a qdisc lock deadlock.\nSee trace below.\r\n\r\n[..... other info removed for brevity....]\n[ 82.890906]\n[ 82.890906] ============================================\n[ 82.890906] WARNING: possible recursive locking detected\n[ 82.890906] 6.8.0-05205-g77fadd89fe2d-dirty #213 Tainted: G W\n[ 82.890906] --------------------------------------------\n[ 82.890906] ping/418 is trying to acquire lock:\n[ 82.890906] ffff888006994110 (\u0026amp;sch-\u0026gt;q.lock){+.-.}-{3:3}, at:\n__dev_queue_xmit+0x1778/0x3550\n[ 82.890906]\n[ 82.890906] but task is already holding lock:\n[ 82.890906] ffff888006994110 (\u0026amp;sch-\u0026gt;q.lock){+.-.}-{3:3}, at:\n__dev_queue_xmit+0x1778/0x3550\n[ 82.890906]\n[ 82.890906] other info that might help us debug this:\n[ 82.890906] Possible unsafe locking scenario:\n[ 82.890906]\n[ 82.890906] CPU0\n[ 82.890906] ----\n[ 82.890906] lock(\u0026amp;sch-\u0026gt;q.lock);\n[ 82.890906] lock(\u0026amp;sch-\u0026gt;q.lock);\n[ 82.890906]\n[ 82.890906] *** DEADLOCK ***\n[ 82.890906]\n[..... other info removed for brevity....]\r\n\r\nExample setup (eth0-\u0026gt;eth0) to recreate\ntc qdisc add dev eth0 root handle 1: htb default 30\ntc filter add dev eth0 handle 1: protocol ip prio 2 matchall \\\n action mirred egress redirect dev eth0\r\n\r\nAnother example(eth0-\u0026gt;eth1-\u0026gt;eth0) to recreate\ntc qdisc add dev eth0 root handle 1: htb default 30\ntc filter add dev eth0 handle 1: protocol ip prio 2 matchall \\\n action mirred egress redirect dev eth1\r\n\r\ntc qdisc add dev eth1 root handle 1: htb default 30\ntc filter add dev eth1 handle 1: protocol ip prio 2 matchall \\\n action mirred egress redirect dev eth0\r\n\r\nWe fix this by adding an owner field (CPU id) to struct Qdisc set after\nroot qdisc is entered. When the softirq enters it a second time, if the\nqdisc owner is the same CPU, the packet is dropped to break the loop.(CVE-2024-27010)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nf_tables: fix memleak in map from abort path\r\n\r\nThe delete set command does not rely on the transaction object for\nelement removal, therefore, a combination of delete element + delete set\nfrom the abort path could result in restoring twice the refcount of the\nmapping.\r\n\r\nCheck for inactive element in the next generation for the delete element\ncommand in the abort path, skip restoring state if next generation bit\nhas been already cleared. This is similar to the activate logic using\nthe set walk iterator.\r\n\r\n[ 6170.286929] ------------[ cut here ]------------\n[ 6170.286939] WARNING: CPU: 6 PID: 790302 at net/netfilter/nf_tables_api.c:2086 nf_tables_chain_destroy+0x1f7/0x220 [nf_tables]\n[ 6170.287071] Modules linked in: [...]\n[ 6170.287633] CPU: 6 PID: 790302 Comm: kworker/6:2 Not tainted 6.9.0-rc3+ #365\n[ 6170.287768] RIP: 0010:nf_tables_chain_destroy+0x1f7/0x220 [nf_tables]\n[ 6170.287886] Code: df 48 8d 7d 58 e8 69 2e 3b df 48 8b 7d 58 e8 80 1b 37 df 48 8d 7d 68 e8 57 2e 3b df 48 8b 7d 68 e8 6e 1b 37 df 48 89 ef eb c4 \u0026lt;0f\u0026gt; 0b 48 83 c4 08 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 0f\n[ 6170.287895] RSP: 0018:ffff888134b8fd08 EFLAGS: 00010202\n[ 6170.287904] RAX: 0000000000000001 RBX: ffff888125bffb28 RCX: dffffc0000000000\n[ 6170.287912] RDX: 0000000000000003 RSI: ffffffffa20298ab RDI: ffff88811ebe4750\n[ 6170.287919] RBP: ffff88811ebe4700 R08: ffff88838e812650 R09: fffffbfff0623a55\n[ 6170.287926] R10: ffffffff8311d2af R11: 0000000000000001 R12: ffff888125bffb10\n[ 6170.287933] R13: ffff888125bffb10 R14: dead000000000122 R15: dead000000000100\n[ 6170.287940] FS: 0000000000000000(0000) GS:ffff888390b00000(0000) knlGS:0000000000000000\n[ 6170.287948] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 6170.287955] CR2: 00007fd31fc00710 CR3: 0000000133f60004 CR4: 00000000001706f0\n[ 6170.287962] Call Trace:\n[ 6170.287967] \u0026lt;TASK\u0026gt;\n[ 6170.287973] ? __warn+0x9f/0x1a0\n[ 6170.287986] ? nf_tables_chain_destroy+0x1f7/0x220 [nf_tables]\n[ 6170.288092] ? report_bug+0x1b1/0x1e0\n[ 6170.287986] ? nf_tables_chain_destroy+0x1f7/0x220 [nf_tables]\n[ 6170.288092] ? report_bug+0x1b1/0x1e0\n[ 6170.288104] ? handle_bug+0x3c/0x70\n[ 6170.288112] ? exc_invalid_op+0x17/0x40\n[ 6170.288120] ? asm_exc_invalid_op+0x1a/0x20\n[ 6170.288132] ? nf_tables_chain_destroy+0x2b/0x220 [nf_tables]\n[ 6170.288243] ? nf_tables_chain_destroy+0x1f7/0x220 [nf_tables]\n[ 6170.288366] ? nf_tables_chain_destroy+0x2b/0x220 [nf_tables]\n[ 6170.288483] nf_tables_trans_destroy_work+0x588/0x590 [nf_tables](CVE-2024-27011)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/rds: fix WARNING in rds_conn_connect_if_down\r\n\r\nIf connection isn\u0026apos;t established yet, get_mr() will fail, trigger connection after\nget_mr().(CVE-2024-27024)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nf2fs: compress: fix to cover normal cluster write with cp_rwsem\r\n\r\nWhen we overwrite compressed cluster w/ normal cluster, we should\nnot unlock cp_rwsem during f2fs_write_raw_pages(), otherwise data\nwill be corrupted if partial blocks were persisted before CP \u0026amp; SPOR,\ndue to cluster metadata wasn\u0026apos;t updated atomically.(CVE-2024-27034)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nf2fs: compress: fix to guarantee persisting compressed blocks by CP\r\n\r\nIf data block in compressed cluster is not persisted with metadata\nduring checkpoint, after SPOR, the data may be corrupted, let\u0026apos;s\nguarantee to write compressed page by checkpoint.(CVE-2024-27035)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nclk: zynq: Prevent null pointer dereference caused by kmalloc failure\r\n\r\nThe kmalloc() in zynq_clk_setup() will return null if the\nphysical memory has run out. As a result, if we use snprintf()\nto write data to the null address, the null pointer dereference\nbug will happen.\r\n\r\nThis patch uses a stack variable to replace the kmalloc().(CVE-2024-27037)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Fix a potential buffer overflow in \u0026apos;dp_dsc_clock_en_read()\u0026apos;\r\n\r\nTell snprintf() to store at most 10 bytes in the output buffer\ninstead of 30.\r\n\r\nFixes the below:\ndrivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_debugfs.c:1508 dp_dsc_clock_en_read() error: snprintf() is printing too much 30 vs 10(CVE-2024-27045)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nUSB: usb-storage: Prevent divide-by-0 error in isd200_ata_command\r\n\r\nThe isd200 sub-driver in usb-storage uses the HEADS and SECTORS values\nin the ATA ID information to calculate cylinder and head values when\ncreating a CDB for READ or WRITE commands. The calculation involves\ndivision and modulus operations, which will cause a crash if either of\nthese values is 0. While this never happens with a genuine device, it\ncould happen with a flawed or subversive emulation, as reported by the\nsyzbot fuzzer.\r\n\r\nProtect against this possibility by refusing to bind to the device if\neither the ATA_ID_HEADS or ATA_ID_SECTORS value in the device\u0026apos;s ID\ninformation is 0. This requires isd200_Initialization() to return a\nnegative error code when initialization fails; currently it always\nreturns 0 (even when there is an error).(CVE-2024-27059)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: usbtv: Remove useless locks in usbtv_video_free()\r\n\r\nRemove locks calls in usbtv_video_free() because\nare useless and may led to a deadlock as reported here:\nhttps://syzkaller.appspot.com/x/bisect.txt?x=166dc872180000\nAlso remove usbtv_stop() call since it will be called when\nunregistering the device.\r\n\r\nBefore \u0026apos;c838530d230b\u0026apos; this issue would only be noticed if you\ndisconnect while streaming and now it is noticeable even when\ndisconnecting while not streaming.\r\n\r\n\n[hverkuil: fix minor spelling mistake in log message](CVE-2024-27072)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: ttpci: fix two memleaks in budget_av_attach\r\n\r\nWhen saa7146_register_device and saa7146_vv_init fails, budget_av_attach\nshould free the resources it allocates, like the error-handling of\nttpci_budget_init does. Besides, there are two fixme comment refers to\nsuch deallocations.(CVE-2024-27073)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: dvb-frontends: avoid stack overflow warnings with clang\r\n\r\nA previous patch worked around a KASAN issue in stv0367, now a similar\nproblem showed up with clang:\r\n\r\ndrivers/media/dvb-frontends/stv0367.c:1222:12: error: stack frame size (3624) exceeds limit (2048) in \u0026apos;stv0367ter_set_frontend\u0026apos; [-Werror,-Wframe-larger-than]\n 1214 | static int stv0367ter_set_frontend(struct dvb_frontend *fe)\r\n\r\nRework the stv0367_writereg() function to be simpler and mark both\nregister access functions as noinline_for_stack so the temporary\ni2c_msg structures do not get duplicated on the stack when KASAN_STACK\nis enabled.(CVE-2024-27075)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nSUNRPC: fix some memleaks in gssx_dec_option_array\r\n\r\nThe creds and oa-\u0026gt;data need to be freed in the error-handling paths after\ntheir allocation. So this patch add these deallocations in the\ncorresponding paths.(CVE-2024-27388)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npstore: inode: Only d_invalidate() is needed\r\n\r\nUnloading a modular pstore backend with records in pstorefs would\ntrigger the dput() double-drop warning:\r\n\r\n WARNING: CPU: 0 PID: 2569 at fs/dcache.c:762 dput.part.0+0x3f3/0x410\r\n\r\nUsing the combo of d_drop()/dput() (as mentioned in\nDocumentation/filesystems/vfs.rst) isn\u0026apos;t the right approach here, and\nleads to the reference counting problem seen above. Use d_invalidate()\nand update the code to not bother checking for error codes that can\nnever happen.\r\n\r\n---(CVE-2024-27389)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nft_flow_offload: reset dst in route object after setting up flow\r\n\r\ndst is transferred to the flow object, route object does not own it\nanymore. Reset dst in route object, otherwise if flow_offload_add()\nfails, error path releases dst twice, leading to a refcount underflow.(CVE-2024-27403)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfs/ntfs3: Fixed overflow check in mi_enum_attr()(CVE-2024-27407)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetrom: Fix data-races around sysctl_net_busy_read\r\n\r\nWe need to protect the reader reading the sysctl value because the\nvalue can be changed concurrently.(CVE-2024-27419)\r\n\r\nRejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2024-27426)\r\n\r\nRejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2024-27427)\r\n\r\nRejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2024-27428)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\nx86/fpu: Keep xfd_state in sync with MSR_IA32_XFD\nCommit 672365477ae8 (\u0026quot;x86/fpu: Update XFD state where required\u0026quot;) and\ncommit 8bf26758ca96 (\u0026quot;x86/fpu: Add XFD state to fpstate\u0026quot;) introduced a\nper CPU variable xfd_state to keep the MSR_IA32_XFD value cached, in\norder to avoid unnecessary writes to the MSR.\nOn CPU hotplug MSR_IA32_XFD is reset to the init_fpstate.xfd, which\nwipes out any stale state. But the per CPU cached xfd value is not\nreset, which brings them out of sync.\nAs a consequence a subsequent xfd_update_state() might fail to update\nthe MSR which in turn can result in XRSTOR raising a #NM in kernel\nspace, which crashes the kernel.\nTo fix this, introduce xfd_set_state() to write xfd_state together\nwith MSR_IA32_XFD, and use it in all places that set MSR_IA32_XFD.(CVE-2024-35801)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndm snapshot: fix lockup in dm_exception_table_exit\r\n\r\nThere was reported lockup when we exit a snapshot with many exceptions.\nFix this by adding \u0026quot;cond_resched\u0026quot; to the loop that frees the exceptions.(CVE-2024-35805)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsoc: fsl: qbman: Always disable interrupts when taking cgr_lock\r\n\r\nsmp_call_function_single disables IRQs when executing the callback. To\nprevent deadlocks, we must disable IRQs when taking cgr_lock elsewhere.\nThis is already done by qman_update_cgr and qman_delete_cgr; fix the\nother lockers.(CVE-2024-35806)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfs/aio: Check IOCB_AIO_RW before the struct aio_kiocb conversion\r\n\r\nThe first kiocb_set_cancel_fn() argument may point at a struct kiocb\nthat is not embedded inside struct aio_kiocb. With the current code,\ndepending on the compiler, the req-\u0026gt;ki_ctx read happens either before\nthe IOCB_AIO_RW test or after that test. Move the req-\u0026gt;ki_ctx read such\nthat it is guaranteed that the IOCB_AIO_RW test happens first.(CVE-2024-35815)\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\nLoongArch: Define the __io_aw() hook as mmiowb()\r\n\r\nCommit fb24ea52f78e0d595852e (\u0026quot;drivers: Remove explicit invocations of\nmmiowb()\u0026quot;) remove all mmiowb() in drivers, but it says:\r\n\r\n\u0026quot;NOTE: mmiowb() has only ever guaranteed ordering in conjunction with\nspin_unlock(). However, pairing each mmiowb() removal in this patch with\nthe corresponding call to spin_unlock() is not at all trivial, so there\nis a small chance that this change may regress any drivers incorrectly\nrelying on mmiowb() to order MMIO writes between CPUs using lock-free\nsynchronisation.\u0026quot;\r\n\r\nThe mmio in radeon_ring_commit() is protected by a mutex rather than a\nspinlock, but in the mutex fastpath it behaves similar to spinlock. We\ncan add mmiowb() calls in the radeon driver but the maintainer says he\ndoesn\u0026apos;t like such a workaround, and radeon is not the only example of\nmutex protected mmio.\r\n\r\nSo we should extend the mmiowb tracking system from spinlock to mutex,\nand maybe other locking primitives. This is not easy and error prone, so\nwe solve it in the architectural code, by simply defining the __io_aw()\nhook as mmiowb(). And we no longer need to override queued_spin_unlock()\nso use the generic definition.\r\n\r\nWithout this, we get such an error when run \u0026apos;glxgears\u0026apos; on weak ordering\narchitectures such as LoongArch:\r\n\r\nradeon 0000:04:00.0: ring 0 stalled for more than 10324msec\nradeon 0000:04:00.0: ring 3 stalled for more than 10240msec\nradeon 0000:04:00.0: GPU lockup (current fence id 0x000000000001f412 last fence id 0x000000000001f414 on ring 3)\nradeon 0000:04:00.0: GPU lockup (current fence id 0x000000000000f940 last fence id 0x000000000000f941 on ring 0)\nradeon 0000:04:00.0: scheduling IB failed (-35).\n[drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn\u0026apos;t update BO_VA (-35)\nradeon 0000:04:00.0: scheduling IB failed (-35).\n[drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn\u0026apos;t update BO_VA (-35)\nradeon 0000:04:00.0: scheduling IB failed (-35).\n[drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn\u0026apos;t update BO_VA (-35)\nradeon 0000:04:00.0: scheduling IB failed (-35).\n[drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn\u0026apos;t update BO_VA (-35)\nradeon 0000:04:00.0: scheduling IB failed (-35).\n[drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn\u0026apos;t update BO_VA (-35)\nradeon 0000:04:00.0: scheduling IB failed (-35).\n[drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn\u0026apos;t update BO_VA (-35)\nradeon 0000:04:00.0: scheduling IB failed (-35).\n[drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn\u0026apos;t update BO_VA (-35)(CVE-2024-35818)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/mlx5e: fix a double-free in arfs_create_groups\r\n\r\nWhen `in` allocated by kvzalloc fails, arfs_create_groups will free\nft-\u0026gt;g and return an error. However, arfs_create_table, the only caller of\narfs_create_groups, will hold this error and call to\nmlx5e_destroy_flow_table, in which the ft-\u0026gt;g will be freed again.(CVE-2024-35835)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: bridge: replace physindev with physinif in nf_bridge_info\r\n\r\nAn skb can be added to a neigh-\u0026gt;arp_queue while waiting for an arp\nreply. Where original skb\u0026apos;s skb-\u0026gt;dev can be different to neigh\u0026apos;s\nneigh-\u0026gt;dev. For instance in case of bridging dnated skb from one veth to\nanother, the skb would be added to a neigh-\u0026gt;arp_queue of the bridge.\r\n\r\nAs skb-\u0026gt;dev can be reset back to nf_bridge-\u0026gt;physindev and used, and as\nthere is no explicit mechanism that prevents this physindev from been\nfreed under us (for instance neigh_flush_dev doesn\u0026apos;t cleanup skbs from\ndifferent device\u0026apos;s neigh queue) we can crash on e.g. this stack:\r\n\r\narp_process\n neigh_update\n skb = __skb_dequeue(\u0026amp;neigh-\u0026gt;arp_queue)\n neigh_resolve_output(..., skb)\n ...\n br_nf_dev_xmit\n br_nf_pre_routing_finish_bridge_slow\n skb-\u0026gt;dev = nf_bridge-\u0026gt;physindev\n br_handle_frame_finish\r\n\r\nLet\u0026apos;s use plain ifindex instead of net_device link. To peek into the\noriginal net_device we will use dev_get_by_index_rcu(). Thus either we\nget device and are safe to use it or we don\u0026apos;t get it and drop skb.(CVE-2024-35839)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nf2fs: compress: fix reserve_cblocks counting error when out of space\r\n\r\nWhen a file only needs one direct_node, performing the following\noperations will cause the file to be unrepairable:\r\n\r\nunisoc # ./f2fs_io compress test.apk\nunisoc #df -h | grep dm-48\n/dev/block/dm-48 112G 112G 1.2M 100% /data\r\n\r\nunisoc # ./f2fs_io release_cblocks test.apk\n924\nunisoc # df -h | grep dm-48\n/dev/block/dm-48 112G 112G 4.8M 100% /data\r\n\r\nunisoc # dd if=/dev/random of=file4 bs=1M count=3\n3145728 bytes (3.0 M) copied, 0.025 s, 120 M/s\nunisoc # df -h | grep dm-48\n/dev/block/dm-48 112G 112G 1.8M 100% /data\r\n\r\nunisoc # ./f2fs_io reserve_cblocks test.apk\nF2FS_IOC_RESERVE_COMPRESS_BLOCKS failed: No space left on device\r\n\r\nadb reboot\nunisoc # df -h | grep dm-48\n/dev/block/dm-48 112G 112G 11M 100% /data\nunisoc # ./f2fs_io reserve_cblocks test.apk\n0\r\n\r\nThis is because the file has only one direct_node. After returning\nto -ENOSPC, reserved_blocks += ret will not be executed. As a result,\nthe reserved_blocks at this time is still 0, which is not the real\nnumber of reserved blocks. Therefore, fsck cannot be set to repair\nthe file.\r\n\r\nAfter this patch, the fsck flag will be set to fix this problem.\r\n\r\nunisoc # df -h | grep dm-48\n/dev/block/dm-48 112G 112G 1.8M 100% /data\nunisoc # ./f2fs_io reserve_cblocks test.apk\nF2FS_IOC_RESERVE_COMPRESS_BLOCKS failed: No space left on device\r\n\r\nadb reboot then fsck will be executed\nunisoc # df -h | grep dm-48\n/dev/block/dm-48 112G 112G 11M 100% /data\nunisoc # ./f2fs_io reserve_cblocks test.apk\n924(CVE-2024-35844)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\neeprom: at24: fix memory corruption race condition\r\n\r\nIf the eeprom is not accessible, an nvmem device will be registered, the\nread will fail, and the device will be torn down. If another driver\naccesses the nvmem device after the teardown, it will reference\ninvalid memory.\r\n\r\nMove the failure point before registering the nvmem device.(CVE-2024-35848)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nipv6: Fix infinite recursion in fib6_dump_done().\r\n\r\nsyzkaller reported infinite recursive calls of fib6_dump_done() during\nnetlink socket destruction. [1]\r\n\r\nFrom the log, syzkaller sent an AF_UNSPEC RTM_GETROUTE message, and then\nthe response was generated. The following recvmmsg() resumed the dump\nfor IPv6, but the first call of inet6_dump_fib() failed at kzalloc() due\nto the fault injection. [0]\r\n\r\n 12:01:34 executing program 3:\n r0 = socket$nl_route(0x10, 0x3, 0x0)\n sendmsg$nl_route(r0, ... snip ...)\n recvmmsg(r0, ... snip ...) (fail_nth: 8)\r\n\r\nHere, fib6_dump_done() was set to nlk_sk(sk)-\u0026gt;cb.done, and the next call\nof inet6_dump_fib() set it to nlk_sk(sk)-\u0026gt;cb.args[3]. syzkaller stopped\nreceiving the response halfway through, and finally netlink_sock_destruct()\ncalled nlk_sk(sk)-\u0026gt;cb.done().\r\n\r\nfib6_dump_done() calls fib6_dump_end() and nlk_sk(sk)-\u0026gt;cb.done() if it\nis still not NULL. fib6_dump_end() rewrites nlk_sk(sk)-\u0026gt;cb.done() by\nnlk_sk(sk)-\u0026gt;cb.args[3], but it has the same function, not NULL, calling\nitself recursively and hitting the stack guard page.\r\n\r\nTo avoid the issue, let\u0026apos;s set the destructor after kzalloc().\r\n\r\n[0]:\nFAULT_INJECTION: forcing a failure.\nname failslab, interval 1, probability 0, space 0, times 0\nCPU: 1 PID: 432110 Comm: syz-executor.3 Not tainted 6.8.0-12821-g537c2e91d354-dirty #11\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl (lib/dump_stack.c:117)\n should_fail_ex (lib/fault-inject.c:52 lib/fault-inject.c:153)\n should_failslab (mm/slub.c:3733)\n kmalloc_trace (mm/slub.c:3748 mm/slub.c:3827 mm/slub.c:3992)\n inet6_dump_fib (./include/linux/slab.h:628 ./include/linux/slab.h:749 net/ipv6/ip6_fib.c:662)\n rtnl_dump_all (net/core/rtnetlink.c:4029)\n netlink_dump (net/netlink/af_netlink.c:2269)\n netlink_recvmsg (net/netlink/af_netlink.c:1988)\n ____sys_recvmsg (net/socket.c:1046 net/socket.c:2801)\n ___sys_recvmsg (net/socket.c:2846)\n do_recvmmsg (net/socket.c:2943)\n __x64_sys_recvmmsg (net/socket.c:3041 net/socket.c:3034 net/socket.c:3034)\r\n\r\n[1]:\nBUG: TASK stack guard page was hit at 00000000f2fa9af1 (stack is 00000000b7912430..000000009a436beb)\nstack guard page: 0000 [#1] PREEMPT SMP KASAN\nCPU: 1 PID: 223719 Comm: kworker/1:3 Not tainted 6.8.0-12821-g537c2e91d354-dirty #11\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014\nWorkqueue: events netlink_sock_destruct_work\nRIP: 0010:fib6_dump_done (net/ipv6/ip6_fib.c:570)\nCode: 3c 24 e8 f3 e9 51 fd e9 28 fd ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 41 57 41 56 41 55 41 54 55 48 89 fd \u0026lt;53\u0026gt; 48 8d 5d 60 e8 b6 4d 07 fd 48 89 da 48 b8 00 00 00 00 00 fc ff\nRSP: 0018:ffffc9000d980000 EFLAGS: 00010293\nRAX: 0000000000000000 RBX: ffffffff84405990 RCX: ffffffff844059d3\nRDX: ffff8881028e0000 RSI: ffffffff84405ac2 RDI: ffff88810c02f358\nRBP: ffff88810c02f358 R08: 0000000000000007 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000224 R12: 0000000000000000\nR13: ffff888007c82c78 R14: ffff888007c82c68 R15: ffff888007c82c68\nFS: 0000000000000000(0000) GS:ffff88811b100000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: ffffc9000d97fff8 CR3: 0000000102309002 CR4: 0000000000770ef0\nPKRU: 55555554\nCall Trace:\n \u0026lt;#DF\u0026gt;\n \u0026lt;/#DF\u0026gt;\n \u0026lt;TASK\u0026gt;\n fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1))\n fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1))\n ...\n fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1))\n fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1))\n netlink_sock_destruct (net/netlink/af_netlink.c:401)\n __sk_destruct (net/core/sock.c:2177 (discriminator 2))\n sk_destruct (net/core/sock.c:2224)\n __sk_free (net/core/sock.c:2235)\n sk_free (net/core/sock.c:2246)\n process_one_work (kernel/workqueue.c:3259)\n worker_thread (kernel/workqueue.c:3329 kernel/workqueue.\n---truncated---(CVE-2024-35886)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nf_tables: discard table flag update with pending basechain deletion\r\n\r\nHook unregistration is deferred to the commit phase, same occurs with\nhook updates triggered by the table dormant flag. When both commands are\ncombined, this results in deleting a basechain while leaving its hook\nstill registered in the core.(CVE-2024-35897)\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_flowtable_type_get()\r\n\r\nnft_unregister_flowtable_type() within nf_flow_inet_module_exit() can\nconcurrent with __nft_flowtable_type_get() within nf_tables_newflowtable().\nAnd thhere is not any protection when iterate over nf_tables_flowtables\nlist in __nft_flowtable_type_get(). Therefore, there is pertential\ndata-race of nf_tables_flowtables list entry.\r\n\r\nUse list_for_each_entry_rcu() to iterate over nf_tables_flowtables list\nin __nft_flowtable_type_get(), and use rcu_read_lock() in the caller\nnft_flowtable_type_get() to protect the entire type query process.(CVE-2024-35898)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfbmon: prevent division by zero in fb_videomode_from_videomode()\r\n\r\nThe expression htotal * vtotal can have a zero value on\noverflow. It is necessary to prevent division by zero like in\nfb_var_to_videomode().\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with Svace.(CVE-2024-35922)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: lpfc: Fix possible memory leak in lpfc_rcv_padisc()\r\n\r\nThe call to lpfc_sli4_resume_rpi() in lpfc_rcv_padisc() may return an\nunsuccessful status. In such cases, the elsiocb is not issued, the\ncompletion is not called, and thus the elsiocb resource is leaked.\r\n\r\nCheck return value after calling lpfc_sli4_resume_rpi() and conditionally\nrelease the elsiocb resource.(CVE-2024-35930)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: handle chunk tree lookup error in btrfs_relocate_sys_chunks()\r\n\r\nThe unhandled case in btrfs_relocate_sys_chunks() loop is a corruption,\nas it could be caused only by two impossible conditions:\r\n\r\n- at first the search key is set up to look for a chunk tree item, with\n offset -1, this is an inexact search and the key-\u0026gt;offset will contain\n the correct offset upon a successful search, a valid chunk tree item\n cannot have an offset -1\r\n\r\n- after first successful search, the found_key corresponds to a chunk\n item, the offset is decremented by 1 before the next loop, it\u0026apos;s\n impossible to find a chunk item there due to alignment and size\n constraints(CVE-2024-35936)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npstore/zone: Add a null pointer check to the psz_kmsg_read\r\n\r\nkasprintf() returns a pointer to dynamically allocated memory\nwhich can be NULL upon failure. Ensure the allocation was successful\nby checking the pointer validity.(CVE-2024-35940)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nxsk: validate user input for XDP_{UMEM|COMPLETION}_FILL_RING\r\n\r\nsyzbot reported an illegal copy in xsk_setsockopt() [1]\r\n\r\nMake sure to validate setsockopt() @optlen parameter.\r\n\r\n[1]\r\n\r\n BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline]\n BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline]\n BUG: KASAN: slab-out-of-bounds in xsk_setsockopt+0x909/0xa40 net/xdp/xsk.c:1420\nRead of size 4 at addr ffff888028c6cde3 by task syz-executor.0/7549\r\n\r\nCPU: 0 PID: 7549 Comm: syz-executor.0 Not tainted 6.8.0-syzkaller-08951-gfe46a7dd189e #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114\n print_address_description mm/kasan/report.c:377 [inline]\n print_report+0x169/0x550 mm/kasan/report.c:488\n kasan_report+0x143/0x180 mm/kasan/report.c:601\n copy_from_sockptr_offset include/linux/sockptr.h:49 [inline]\n copy_from_sockptr include/linux/sockptr.h:55 [inline]\n xsk_setsockopt+0x909/0xa40 net/xdp/xsk.c:1420\n do_sock_setsockopt+0x3af/0x720 net/socket.c:2311\n __sys_setsockopt+0x1ae/0x250 net/socket.c:2334\n __do_sys_setsockopt net/socket.c:2343 [inline]\n __se_sys_setsockopt net/socket.c:2340 [inline]\n __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340\n do_syscall_64+0xfb/0x240\n entry_SYSCALL_64_after_hwframe+0x6d/0x75\nRIP: 0033:0x7fb40587de69\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:00007fb40665a0c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000036\nRAX: ffffffffffffffda RBX: 00007fb4059abf80 RCX: 00007fb40587de69\nRDX: 0000000000000005 RSI: 000000000000011b RDI: 0000000000000006\nRBP: 00007fb4058ca47a R08: 0000000000000002 R09: 0000000000000000\nR10: 0000000020001980 R11: 0000000000000246 R12: 0000000000000000\nR13: 000000000000000b R14: 00007fb4059abf80 R15: 00007fff57ee4d08\n \u0026lt;/TASK\u0026gt;\r\n\r\nAllocated by task 7549:\n kasan_save_stack mm/kasan/common.c:47 [inline]\n kasan_save_track+0x3f/0x80 mm/kasan/common.c:68\n poison_kmalloc_redzone mm/kasan/common.c:370 [inline]\n __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:387\n kasan_kmalloc include/linux/kasan.h:211 [inline]\n __do_kmalloc_node mm/slub.c:3966 [inline]\n __kmalloc+0x233/0x4a0 mm/slub.c:3979\n kmalloc include/linux/slab.h:632 [inline]\n __cgroup_bpf_run_filter_setsockopt+0xd2f/0x1040 kernel/bpf/cgroup.c:1869\n do_sock_setsockopt+0x6b4/0x720 net/socket.c:2293\n __sys_setsockopt+0x1ae/0x250 net/socket.c:2334\n __do_sys_setsockopt net/socket.c:2343 [inline]\n __se_sys_setsockopt net/socket.c:2340 [inline]\n __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340\n do_syscall_64+0xfb/0x240\n entry_SYSCALL_64_after_hwframe+0x6d/0x75\r\n\r\nThe buggy address belongs to the object at ffff888028c6cde0\n which belongs to the cache kmalloc-8 of size 8\nThe buggy address is located 1 bytes to the right of\n allocated 2-byte region [ffff888028c6cde0, ffff888028c6cde2)\r\n\r\nThe buggy address belongs to the physical page:\npage:ffffea0000a31b00 refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888028c6c9c0 pfn:0x28c6c\nanon flags: 0xfff00000000800(slab|node=0|zone=1|lastcpupid=0x7ff)\npage_type: 0xffffffff()\nraw: 00fff00000000800 ffff888014c41280 0000000000000000 dead000000000001\nraw: ffff888028c6c9c0 0000000080800057 00000001ffffffff 0000000000000000\npage dumped because: kasan: bad access detected\npage_owner tracks the page as allocated\npage last allocated via order 0, migratetype Unmovable, gfp_mask 0x112cc0(GFP_USER|__GFP_NOWARN|__GFP_NORETRY), pid 6648, tgid 6644 (syz-executor.0), ts 133906047828, free_ts 133859922223\n set_page_owner include/linux/page_owner.h:31 [inline]\n post_alloc_hook+0x1ea/0x210 mm/page_alloc.c:1533\n prep_new_page mm/page_alloc.c:\n---truncated---(CVE-2024-35976)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nACPI: CPPC: Use access_width over bit_width for system memory accesses\r\n\r\nTo align with ACPI 6.3+, since bit_width can be any 8-bit value, it\ncannot be depended on to be always on a clean 8b boundary. This was\nuncovered on the Cobalt 100 platform.\r\n\r\nSError Interrupt on CPU26, code 0xbe000011 -- SError\n CPU: 26 PID: 1510 Comm: systemd-udevd Not tainted 5.15.2.1-13 #1\n Hardware name: MICROSOFT CORPORATION, BIOS MICROSOFT CORPORATION\n pstate: 62400009 (nZCv daif +PAN -UAO +TCO -DIT -SSBS BTYPE=--)\n pc : cppc_get_perf_caps+0xec/0x410\n lr : cppc_get_perf_caps+0xe8/0x410\n sp : ffff8000155ab730\n x29: ffff8000155ab730 x28: ffff0080139d0038 x27: ffff0080139d0078\n x26: 0000000000000000 x25: ffff0080139d0058 x24: 00000000ffffffff\n x23: ffff0080139d0298 x22: ffff0080139d0278 x21: 0000000000000000\n x20: ffff00802b251910 x19: ffff0080139d0000 x18: ffffffffffffffff\n x17: 0000000000000000 x16: ffffdc7e111bad04 x15: ffff00802b251008\n x14: ffffffffffffffff x13: ffff013f1fd63300 x12: 0000000000000006\n x11: ffffdc7e128f4420 x10: 0000000000000000 x9 : ffffdc7e111badec\n x8 : ffff00802b251980 x7 : 0000000000000000 x6 : ffff0080139d0028\n x5 : 0000000000000000 x4 : ffff0080139d0018 x3 : 00000000ffffffff\n x2 : 0000000000000008 x1 : ffff8000155ab7a0 x0 : 0000000000000000\n Kernel panic - not syncing: Asynchronous SError Interrupt\n CPU: 26 PID: 1510 Comm: systemd-udevd Not tainted\n5.15.2.1-13 #1\n Hardware name: MICROSOFT CORPORATION, BIOS MICROSOFT CORPORATION\n Call trace:\n dump_backtrace+0x0/0x1e0\n show_stack+0x24/0x30\n dump_stack_lvl+0x8c/0xb8\n dump_stack+0x18/0x34\n panic+0x16c/0x384\n add_taint+0x0/0xc0\n arm64_serror_panic+0x7c/0x90\n arm64_is_fatal_ras_serror+0x34/0xa4\n do_serror+0x50/0x6c\n el1h_64_error_handler+0x40/0x74\n el1h_64_error+0x7c/0x80\n cppc_get_perf_caps+0xec/0x410\n cppc_cpufreq_cpu_init+0x74/0x400 [cppc_cpufreq]\n cpufreq_online+0x2dc/0xa30\n cpufreq_add_dev+0xc0/0xd4\n subsys_interface_register+0x134/0x14c\n cpufreq_register_driver+0x1b0/0x354\n cppc_cpufreq_init+0x1a8/0x1000 [cppc_cpufreq]\n do_one_initcall+0x50/0x250\n do_init_module+0x60/0x27c\n load_module+0x2300/0x2570\n __do_sys_finit_module+0xa8/0x114\n __arm64_sys_finit_module+0x2c/0x3c\n invoke_syscall+0x78/0x100\n el0_svc_common.constprop.0+0x180/0x1a0\n do_el0_svc+0x84/0xa0\n el0_svc+0x2c/0xc0\n el0t_64_sync_handler+0xa4/0x12c\n el0t_64_sync+0x1a4/0x1a8\r\n\r\nInstead, use access_width to determine the size and use the offset and\nwidth to shift and mask the bits to read/write out. Make sure to add a\ncheck for system memory since pcc redefines the access_width to\nsubspace id.\r\n\r\nIf access_width is not set, then fall back to using bit_width.\r\n\r\n[ rjw: Subject and changelog edits, comment adjustments ](CVE-2024-35995)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nHID: i2c-hid: remove I2C_HID_READ_PENDING flag to prevent lock-up\r\n\r\nThe flag I2C_HID_READ_PENDING is used to serialize I2C operations.\nHowever, this is not necessary, because I2C core already has its own\nlocking for that.\r\n\r\nMore importantly, this flag can cause a lock-up: if the flag is set in\ni2c_hid_xfer() and an interrupt happens, the interrupt handler\n(i2c_hid_irq) will check this flag and return immediately without doing\nanything, then the interrupt handler will be invoked again in an\ninfinite loop.\r\n\r\nSince interrupt handler is an RT task, it takes over the CPU and the\nflag-clearing task never gets scheduled, thus we have a lock-up.\r\n\r\nDelete this unnecessary flag.(CVE-2024-35997)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmlxsw: spectrum_acl_tcam: Fix incorrect list API usage\r\n\r\nBoth the function that migrates all the chunks within a region and the\nfunction that migrates all the entries within a chunk call\nlist_first_entry() on the respective lists without checking that the\nlists are not empty. This is incorrect usage of the API, which leads to\nthe following warning [1].\r\n\r\nFix by returning if the lists are empty as there is nothing to migrate\nin this case.\r\n\r\n[1]\nWARNING: CPU: 0 PID: 6437 at drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c:1266 mlxsw_sp_acl_tcam_vchunk_migrate_all+0x1f1/0\u0026gt;\nModules linked in:\nCPU: 0 PID: 6437 Comm: kworker/0:37 Not tainted 6.9.0-rc3-custom-00883-g94a65f079ef6 #39\nHardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019\nWorkqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work\nRIP: 0010:mlxsw_sp_acl_tcam_vchunk_migrate_all+0x1f1/0x2c0\n[...]\nCall Trace:\n \u0026lt;TASK\u0026gt;\n mlxsw_sp_acl_tcam_vregion_rehash_work+0x6c/0x4a0\n process_one_work+0x151/0x370\n worker_thread+0x2cb/0x3e0\n kthread+0xd0/0x100\n ret_from_fork+0x34/0x50\n ret_from_fork_asm+0x1a/0x30\n \u0026lt;/TASK\u0026gt;(CVE-2024-36006)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nipv4: check for NULL idev in ip_route_use_hint()\r\n\r\nsyzbot was able to trigger a NULL deref in fib_validate_source()\nin an old tree [1].\r\n\r\nIt appears the bug exists in latest trees.\r\n\r\nAll calls to __in_dev_get_rcu() must be checked for a NULL result.\r\n\r\n[1]\ngeneral protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN\nKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]\nCPU: 2 PID: 3257 Comm: syz-executor.3 Not tainted 5.10.0-syzkaller #0\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014\n RIP: 0010:fib_validate_source+0xbf/0x15a0 net/ipv4/fib_frontend.c:425\nCode: 18 f2 f2 f2 f2 42 c7 44 20 23 f3 f3 f3 f3 48 89 44 24 78 42 c6 44 20 27 f3 e8 5d 88 48 fc 4c 89 e8 48 c1 e8 03 48 89 44 24 18 \u0026lt;42\u0026gt; 80 3c 20 00 74 08 4c 89 ef e8 d2 15 98 fc 48 89 5c 24 10 41 bf\nRSP: 0018:ffffc900015fee40 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: ffff88800f7a4000 RCX: ffff88800f4f90c0\nRDX: 0000000000000000 RSI: 0000000004001eac RDI: ffff8880160c64c0\nRBP: ffffc900015ff060 R08: 0000000000000000 R09: ffff88800f7a4000\nR10: 0000000000000002 R11: ffff88800f4f90c0 R12: dffffc0000000000\nR13: 0000000000000000 R14: 0000000000000000 R15: ffff88800f7a4000\nFS: 00007f938acfe6c0(0000) GS:ffff888058c00000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f938acddd58 CR3: 000000001248e000 CR4: 0000000000352ef0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n ip_route_use_hint+0x410/0x9b0 net/ipv4/route.c:2231\n ip_rcv_finish_core+0x2c4/0x1a30 net/ipv4/ip_input.c:327\n ip_list_rcv_finish net/ipv4/ip_input.c:612 [inline]\n ip_sublist_rcv+0x3ed/0xe50 net/ipv4/ip_input.c:638\n ip_list_rcv+0x422/0x470 net/ipv4/ip_input.c:673\n __netif_receive_skb_list_ptype net/core/dev.c:5572 [inline]\n __netif_receive_skb_list_core+0x6b1/0x890 net/core/dev.c:5620\n __netif_receive_skb_list net/core/dev.c:5672 [inline]\n netif_receive_skb_list_internal+0x9f9/0xdc0 net/core/dev.c:5764\n netif_receive_skb_list+0x55/0x3e0 net/core/dev.c:5816\n xdp_recv_frames net/bpf/test_run.c:257 [inline]\n xdp_test_run_batch net/bpf/test_run.c:335 [inline]\n bpf_test_run_xdp_live+0x1818/0x1d00 net/bpf/test_run.c:363\n bpf_prog_test_run_xdp+0x81f/0x1170 net/bpf/test_run.c:1376\n bpf_prog_test_run+0x349/0x3c0 kernel/bpf/syscall.c:3736\n __sys_bpf+0x45c/0x710 kernel/bpf/syscall.c:5115\n __do_sys_bpf kernel/bpf/syscall.c:5201 [inline]\n __se_sys_bpf kernel/bpf/syscall.c:5199 [inline]\n __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:5199(CVE-2024-36008)",
"id": "OESA-2024-1682",
"modified": "2026-08-06T11:07:08Z",
"published": "2024-05-31T11:07:08Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1682"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47421"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47455"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48645"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52650"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52652"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52653"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52656"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52664"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52674"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52683"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52698"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52804"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52805"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52809"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52817"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52818"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52835"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52840"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52844"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52845"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52846"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52847"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52854"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52858"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52863"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52867"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52868"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52869"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52876"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52879"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26643"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26950"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26955"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26957"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26958"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26961"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26965"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26972"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26976"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26982"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26993"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26994"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26999"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27000"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27008"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27010"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27011"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27024"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27034"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27035"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27037"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27045"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27059"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27072"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27073"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27075"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27388"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27389"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27403"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27407"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27419"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27426"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27427"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27428"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35801"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35805"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35806"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35815"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35817"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35818"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35835"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35839"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35844"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35848"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35886"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35897"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35898"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35922"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35930"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35936"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35940"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35976"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35995"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35997"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36006"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36008"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2021-47421",
"CVE-2021-47455",
"CVE-2022-48645",
"CVE-2023-52650",
"CVE-2023-52652",
"CVE-2023-52653",
"CVE-2023-52656",
"CVE-2023-52664",
"CVE-2023-52674",
"CVE-2023-52683",
"CVE-2023-52698",
"CVE-2023-52804",
"CVE-2023-52805",
"CVE-2023-52809",
"CVE-2023-52817",
"CVE-2023-52818",
"CVE-2023-52835",
"CVE-2023-52840",
"CVE-2023-52844",
"CVE-2023-52845",
"CVE-2023-52846",
"CVE-2023-52847",
"CVE-2023-52854",
"CVE-2023-52858",
"CVE-2023-52863",
"CVE-2023-52867",
"CVE-2023-52868",
"CVE-2023-52869",
"CVE-2023-52876",
"CVE-2023-52879",
"CVE-2024-26643",
"CVE-2024-26950",
"CVE-2024-26955",
"CVE-2024-26957",
"CVE-2024-26958",
"CVE-2024-26961",
"CVE-2024-26965",
"CVE-2024-26972",
"CVE-2024-26976",
"CVE-2024-26982",
"CVE-2024-26993",
"CVE-2024-26994",
"CVE-2024-26999",
"CVE-2024-27000",
"CVE-2024-27008",
"CVE-2024-27010",
"CVE-2024-27011",
"CVE-2024-27024",
"CVE-2024-27034",
"CVE-2024-27035",
"CVE-2024-27037",
"CVE-2024-27045",
"CVE-2024-27059",
"CVE-2024-27072",
"CVE-2024-27073",
"CVE-2024-27075",
"CVE-2024-27388",
"CVE-2024-27389",
"CVE-2024-27403",
"CVE-2024-27407",
"CVE-2024-27419",
"CVE-2024-27426",
"CVE-2024-27427",
"CVE-2024-27428",
"CVE-2024-35801",
"CVE-2024-35805",
"CVE-2024-35806",
"CVE-2024-35815",
"CVE-2024-35817",
"CVE-2024-35818",
"CVE-2024-35835",
"CVE-2024-35839",
"CVE-2024-35844",
"CVE-2024-35848",
"CVE-2024-35886",
"CVE-2024-35897",
"CVE-2024-35898",
"CVE-2024-35922",
"CVE-2024-35930",
"CVE-2024-35936",
"CVE-2024-35940",
"CVE-2024-35976",
"CVE-2024-35995",
"CVE-2024-35997",
"CVE-2024-36006",
"CVE-2024-36008"
]
}
OESA-2024-1692 (CVE-2021-47239)
Vulnerability from osv_openeuler – Published: 2024-06-07 11:07 – Updated: 2026-08-06 11:07 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
net: usb: fix possible use-after-free in smsc75xx_bind
The commit 46a8b29c6306 ("net: usb: fix memory leak in smsc75xx_bind") fails to clean up the work scheduled in smsc75xx_reset-> smsc75xx_set_multicast, which leads to use-after-free if the work is scheduled to start after the deallocation. In addition, this patch also removes a dangling pointer - dev->data[0].
This patch calls cancel_work_sync to cancel the scheduled work and set the dangling pointer to NULL.(CVE-2021-47239)
In the Linux kernel, the following vulnerability has been resolved:
RDMA: Verify port when creating flow rule
Validate port value provided by the user and with that remove no longer needed validation by the driver. The missing check in the mlx5_ib driver could cause to the below oops.
Call trace: _create_flow_rule+0x2d4/0xf28 [mlx5_ib] mlx5_ib_create_flow+0x2d0/0x5b0 [mlx5_ib] ib_uverbs_ex_create_flow+0x4cc/0x624 [ib_uverbs] ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0xd4/0x150 [ib_uverbs] ib_uverbs_cmd_verbs.isra.7+0xb28/0xc50 [ib_uverbs] ib_uverbs_ioctl+0x158/0x1d0 [ib_uverbs] do_vfs_ioctl+0xd0/0xaf0 ksys_ioctl+0x84/0xb4 __arm64_sys_ioctl+0x28/0xc4 el0_svc_common.constprop.3+0xa4/0x254 el0_svc_handler+0x84/0xa0 el0_svc+0x10/0x26c Code: b9401260 f9615681 51000400 8b001c20 (f9403c1a)(CVE-2021-47265)
In the Linux kernel, the following vulnerability has been resolved:
bcache: avoid oversized read request in cache missing code path
In the cache missing code path of cached device, if a proper location from the internal B+ tree is matched for a cache miss range, function cached_dev_cache_miss() will be called in cache_lookup_fn() in the following code block, [code block 1] 526 unsigned int sectors = KEY_INODE(k) == s->iop.inode 527 ? min_t(uint64_t, INT_MAX, 528 KEY_START(k) - bio->bi_iter.bi_sector) 529 : INT_MAX; 530 int ret = s->d->cache_miss(b, s, bio, sectors);
Here s->d->cache_miss() is the call backfunction pointer initialized as cached_dev_cache_miss(), the last parameter 'sectors' is an important hint to calculate the size of read request to backing device of the missing cache data.
Current calculation in above code block may generate oversized value of 'sectors', which consequently may trigger 2 different potential kernel panics by BUG() or BUG_ON() as listed below,
1) BUG_ON() inside bch_btree_insert_key(), [code block 2] 886 BUG_ON(b->ops->is_extents && !KEY_SIZE(k)); 2) BUG() inside biovec_slab(), [code block 3] 51 default: 52 BUG(); 53 return NULL;
All the above panics are original from cached_dev_cache_miss() by the oversized parameter 'sectors'.
Inside cached_dev_cache_miss(), parameter 'sectors' is used to calculate the size of data read from backing device for the cache missing. This size is stored in s->insert_bio_sectors by the following lines of code, [code block 4] 909 s->insert_bio_sectors = min(sectors, bio_sectors(bio) + reada);
Then the actual key inserting to the internal B+ tree is generated and stored in s->iop.replace_key by the following lines of code, [code block 5] 911 s->iop.replace_key = KEY(s->iop.inode, 912 bio->bi_iter.bi_sector + s->insert_bio_sectors, 913 s->insert_bio_sectors); The oversized parameter 'sectors' may trigger panic 1) by BUG_ON() from the above code block.
And the bio sending to backing device for the missing data is allocated with hint from s->insert_bio_sectors by the following lines of code, [code block 6] 926 cache_bio = bio_alloc_bioset(GFP_NOWAIT, 927 DIV_ROUND_UP(s->insert_bio_sectors, PAGE_SECTORS), 928 &dc->disk.bio_split); The oversized parameter 'sectors' may trigger panic 2) by BUG() from the agove code block.
Now let me explain how the panics happen with the oversized 'sectors'. In code block 5, replace_key is generated by macro KEY(). From the definition of macro KEY(), [code block 7] 71 #define KEY(inode, offset, size) \ 72 ((struct bkey) { \ 73 .high = (1ULL << 63) | ((__u64) (size) << 20) | (inode), \ 74 .low = (offset) \ 75 })
Here 'size' is 16bits width embedded in 64bits member 'high' of struct bkey. But in code block 1, if "KEY_START(k) - bio->bi_iter.bi_sector" is very probably to be larger than (1<<16) - 1, which makes the bkey size calculation in code block 5 is overflowed. In one bug report the value of parameter 'sectors' is 131072 (= 1 << 17), the overflowed 'sectors' results the overflowed s->insert_bio_sectors in code block 4, then makes size field of s->iop.replace_key to be 0 in code block 5. Then the 0- sized s->iop.replace_key is inserted into the internal B+ tree as cache missing check key (a special key to detect and avoid a racing between normal write request and cache missing read request) as, [code block 8] 915 ret = bch_btree_insert_check_key(b, &s->op, &s->iop.replace_key);
Then the 0-sized s->iop.replace_key as 3rd parameter triggers the bkey size check BUG_ON() in code block 2, and causes the kernel panic 1).
Another ke ---truncated---(CVE-2021-47275)
In the Linux kernel, the following vulnerability has been resolved:
kvm: avoid speculation-based attacks from out-of-range memslot accesses
KVM's mechanism for accessing guest memory translates a guest physical address (gpa) to a host virtual address using the right-shifted gpa (also known as gfn) and a struct kvm_memory_slot. The translation is performed in __gfn_to_hva_memslot using the following formula:
hva = slot->userspace_addr + (gfn - slot->base_gfn) * PAGE_SIZE
It is expected that gfn falls within the boundaries of the guest's physical memory. However, a guest can access invalid physical addresses in such a way that the gfn is invalid.
__gfn_to_hva_memslot is called from kvm_vcpu_gfn_to_hva_prot, which first retrieves a memslot through __gfn_to_memslot. While __gfn_to_memslot does check that the gfn falls within the boundaries of the guest's physical memory or not, a CPU can speculate the result of the check and continue execution speculatively using an illegal gfn. The speculation can result in calculating an out-of-bounds hva. If the resulting host virtual address is used to load another guest physical address, this is effectively a Spectre gadget consisting of two consecutive reads, the second of which is data dependent on the first.
Right now it's not clear if there are any cases in which this is exploitable. One interesting case was reported by the original author of this patch, and involves visiting guest page tables on x86. Right now these are not vulnerable because the hva read goes through get_user(), which contains an LFENCE speculation barrier. However, there are patches in progress for x86 uaccess.h to mask kernel addresses instead of using LFENCE; once these land, a guest could use speculation to read from the VMM's ring 3 address space. Other architectures such as ARM already use the address masking method, and would be susceptible to this same kind of data-dependent access gadgets. Therefore, this patch proactively protects from these attacks by masking out-of-bounds gfns in __gfn_to_hva_memslot, which blocks speculation of invalid hvas.
Sean Christopherson noted that this patch does not cover kvm_read_guest_offset_cached. This however is limited to a few bytes past the end of the cache, and therefore it is unlikely to be useful in the context of building a chain of data dependent accesses.(CVE-2021-47277)
In the Linux kernel, the following vulnerability has been resolved:
net: fix uninit-value in caif_seqpkt_sendmsg
When nr_segs equal to zero in iovec_from_user, the object msg->msg_iter.iov is uninit stack memory in caif_seqpkt_sendmsg which is defined in ___sys_sendmsg. So we cann't just judge msg->msg_iter.iov->base directlly. We can use nr_segs to judge msg in caif_seqpkt_sendmsg whether has data buffers.
===================================================== BUG: KMSAN: uninit-value in caif_seqpkt_sendmsg+0x693/0xf60 net/caif/caif_socket.c:542 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1c9/0x220 lib/dump_stack.c:118 kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:118 __msan_warning+0x58/0xa0 mm/kmsan/kmsan_instr.c:215 caif_seqpkt_sendmsg+0x693/0xf60 net/caif/caif_socket.c:542 sock_sendmsg_nosec net/socket.c:652 [inline] sock_sendmsg net/socket.c:672 [inline] _syssendmsg+0x12b6/0x1350 net/socket.c:2343 _sys_sendmsg net/socket.c:2397 [inline] __sys_sendmmsg+0x808/0xc90 net/socket.c:2480 __compat_sys_sendmmsg net/compat.c:656 inline
In the Linux kernel, the following vulnerability has been resolved:
memory: fsl_ifc: fix leak of private memory on probe failure
On probe error the driver should free the memory allocated for private structure. Fix this by using resource-managed allocation.(CVE-2021-47314)
In the Linux kernel, the following vulnerability has been resolved:
watchdog: sc520_wdt: Fix possible use-after-free in wdt_turnoff()
This module's remove path calls del_timer(). However, that function does not wait until the timer handler finishes. This means that the timer handler may still be running after the driver's remove function has finished, which would result in a use-after-free.
Fix by calling del_timer_sync(), which makes sure the timer handler has finished, and unable to re-schedule itself.(CVE-2021-47323)
In the Linux kernel, the following vulnerability has been resolved:
tty: serial: 8250: serial_cs: Fix a memory leak in error handling path
In the probe function, if the final 'serial_config()' fails, 'info' is leaking.
Add a resource handling path to free this memory.(CVE-2021-47330)
In the Linux kernel, the following vulnerability has been resolved:
powerpc/mm: Fix lockup on kernel exec fault
The powerpc kernel is not prepared to handle exec faults from kernel. Especially, the function is_exec_fault() will return 'false' when an exec fault is taken by kernel, because the check is based on reading current->thread.regs->trap which contains the trap from user.
For instance, when provoking a LKDTM EXEC_USERSPACE test, current->thread.regs->trap is set to SYSCALL trap (0xc00), and the fault taken by the kernel is not seen as an exec fault by set_access_flags_filter().
Commit d7df2443cd5f ("powerpc/mm: Fix spurious segfaults on radix with autonuma") made it clear and handled it properly. But later on commit d3ca587404b3 ("powerpc/mm: Fix reporting of kernel execute faults") removed that handling, introducing test based on error_code. And here is the problem, because on the 603 all upper bits of SRR1 get cleared when the TLB instruction miss handler bails out to ISI.
Until commit cbd7e6ca0210 ("powerpc/fault: Avoid heavy search_exception_tables() verification"), an exec fault from kernel at a userspace address was indirectly caught by the lack of entry for that address in the exception tables. But after that commit the kernel mainly relies on KUAP or on core mm handling to catch wrong user accesses. Here the access is not wrong, so mm handles it. It is a minor fault because PAGE_EXEC is not set, set_access_flags_filter() should set PAGE_EXEC and voila. But as is_exec_fault() returns false as explained in the beginning, set_access_flags_filter() bails out without setting PAGE_EXEC flag, which leads to a forever minor exec fault.
As the kernel is not prepared to handle such exec faults, the thing to do is to fire in bad_kernel_fault() for any exec fault taken by the kernel, as it was prior to commit d3ca587404b3.(CVE-2021-47350)
In the Linux kernel, the following vulnerability has been resolved:
udf: Fix NULL pointer dereference in udf_symlink function
In function udf_symlink, epos.bh is assigned with the value returned by udf_tgetblk. The function udf_tgetblk is defined in udf/misc.c and returns the value of sb_getblk function that could be NULL. Then, epos.bh is used without any check, causing a possible NULL pointer dereference when sb_getblk fails.
This fix adds a check to validate the value of epos.bh.(CVE-2021-47353)
In the Linux kernel, the following vulnerability has been resolved:
atm: nicstar: Fix possible use-after-free in nicstar_cleanup()
This module's remove path calls del_timer(). However, that function does not wait until the timer handler finishes. This means that the timer handler may still be running after the driver's remove function has finished, which would result in a use-after-free.
Fix by calling del_timer_sync(), which makes sure the timer handler has finished, and unable to re-schedule itself.(CVE-2021-47355)
In the Linux kernel, the following vulnerability has been resolved:
mISDN: fix possible use-after-free in HFC_cleanup()
This module's remove path calls del_timer(). However, that function does not wait until the timer handler finishes. This means that the timer handler may still be running after the driver's remove function has finished, which would result in a use-after-free.
Fix by calling del_timer_sync(), which makes sure the timer handler has finished, and unable to re-schedule itself.(CVE-2021-47356)
In the Linux kernel, the following vulnerability has been resolved:
atm: iphase: fix possible use-after-free in ia_module_exit()
This module's remove path calls del_timer(). However, that function does not wait until the timer handler finishes. This means that the timer handler may still be running after the driver's remove function has finished, which would result in a use-after-free.
Fix by calling del_timer_sync(), which makes sure the timer handler has finished, and unable to re-schedule itself.(CVE-2021-47357)
In the Linux kernel, the following vulnerability has been resolved:
mcb: fix error handling in mcb_alloc_bus()
There are two bugs: 1) If ida_simple_get() fails then this code calls put_device(carrier) but we haven't yet called get_device(carrier) and probably that leads to a use after free. 2) After device_initialize() then we need to use put_device() to release the bus. This will free the internal resources tied to the device and call mcb_free_bus() which will free the rest.(CVE-2021-47361)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/pm: Update intermediate power state for SI
Update the current state as boot state during dpm initialization. During the subsequent initialization, set_power_state gets called to transition to the final power state. set_power_state refers to values from the current state and without current state populated, it could result in NULL pointer dereference.
For ex: on platforms where PCI speed change is supported through ACPI ATCS method, the link speed of current state needs to be queried before deciding on changing to final power state's link speed. The logic to query ATCS-support was broken on certain platforms. The issue became visible when broken ATCS-support logic got fixed with commit f9b7f3703ff9 ("drm/amdgpu/acpi: make ATPX/ATCS structures global (v2)").
Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1698(CVE-2021-47362)
In the Linux kernel, the following vulnerability has been resolved:
mac80211: fix use-after-free in CCMP/GCMP RX
When PN checking is done in mac80211, for fragmentation we need to copy the PN to the RX struct so we can later use it to do a comparison, since commit bf30ca922a0c ("mac80211: check defrag PN against current frame").
Unfortunately, in that commit I used the 'hdr' variable without it being necessarily valid, so use-after-free could occur if it was necessary to reallocate (parts of) the frame.
Fix this by reloading the variable after the code that results in the reallocations, if any.
This fixes https://bugzilla.kernel.org/show_bug.cgi?id=214401.(CVE-2021-47388)
In the Linux kernel, the following vulnerability has been resolved:
mac80211: limit injected vht mcs/nss in ieee80211_parse_tx_radiotap
Limit max values for vht mcs and nss in ieee80211_parse_tx_radiotap routine in order to fix the following warning reported by syzbot:
WARNING: CPU: 0 PID: 10717 at include/net/mac80211.h:989 ieee80211_rate_set_vht include/net/mac80211.h:989 [inline] WARNING: CPU: 0 PID: 10717 at include/net/mac80211.h:989 ieee80211_parse_tx_radiotap+0x101e/0x12d0 net/mac80211/tx.c:2244 Modules linked in: CPU: 0 PID: 10717 Comm: syz-executor.5 Not tainted 5.14.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:ieee80211_rate_set_vht include/net/mac80211.h:989 [inline] RIP: 0010:ieee80211_parse_tx_radiotap+0x101e/0x12d0 net/mac80211/tx.c:2244 RSP: 0018:ffffc9000186f3e8 EFLAGS: 00010216 RAX: 0000000000000618 RBX: ffff88804ef76500 RCX: ffffc900143a5000 RDX: 0000000000040000 RSI: ffffffff888f478e RDI: 0000000000000003 RBP: 00000000ffffffff R08: 0000000000000000 R09: 0000000000000100 R10: ffffffff888f46f9 R11: 0000000000000000 R12: 00000000fffffff8 R13: ffff88804ef7653c R14: 0000000000000001 R15: 0000000000000004 FS: 00007fbf5718f700(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b2de23000 CR3: 000000006a671000 CR4: 00000000001506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600 Call Trace: ieee80211_monitor_select_queue+0xa6/0x250 net/mac80211/iface.c:740 netdev_core_pick_tx+0x169/0x2e0 net/core/dev.c:4089 __dev_queue_xmit+0x6f9/0x3710 net/core/dev.c:4165 __bpf_tx_skb net/core/filter.c:2114 [inline] __bpf_redirect_no_mac net/core/filter.c:2139 [inline] __bpf_redirect+0x5ba/0xd20 net/core/filter.c:2162 _bpfclone_redirect net/core/filter.c:2429 [inline] bpf_clone_redirect+0x2ae/0x420 net/core/filter.c:2401 bpf_prog_eeb6f53a69e5c6a2+0x59/0x234 bpf_dispatcher_nop_func include/linux/bpf.h:717 [inline] bpf_prog_run include/linux/filter.h:624 [inline] bpf_prog_run include/linux/filter.h:631 [inline] bpf_test_run+0x381/0xa30 net/bpf/test_run.c:119 bpf_prog_test_run_skb+0xb84/0x1ee0 net/bpf/test_run.c:663 bpf_prog_test_run kernel/bpf/syscall.c:3307 [inline] __sys_bpf+0x2137/0x5df0 kernel/bpf/syscall.c:4605 __do_sys_bpf kernel/bpf/syscall.c:4691 [inline] __se_sys_bpf kernel/bpf/syscall.c:4689 [inline] __x64_sys_bpf+0x75/0xb0 kernel/bpf/syscall.c:4689 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x4665f9(CVE-2021-47395)
In the Linux kernel, the following vulnerability has been resolved:
sctp: break out if skb_header_pointer returns NULL in sctp_rcv_ootb
We should always check if skb_header_pointer's return is NULL before using it, otherwise it may cause null-ptr-deref, as syzbot reported:
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:sctp_rcv_ootb net/sctp/input.c:705 [inline] RIP: 0010:sctp_rcv+0x1d84/0x3220 net/sctp/input.c:196 Call Trace: <IRQ> sctp6_rcv+0x38/0x60 net/sctp/ipv6.c:1109 ip6_protocol_deliver_rcu+0x2e9/0x1ca0 net/ipv6/ip6_input.c:422 ip6_input_finish+0x62/0x170 net/ipv6/ip6_input.c:463 NF_HOOK include/linux/netfilter.h:307 [inline] NF_HOOK include/linux/netfilter.h:301 [inline] ip6_input+0x9c/0xd0 net/ipv6/ip6_input.c:472 dst_input include/net/dst.h:460 [inline] ip6_rcv_finish net/ipv6/ip6_input.c:76 [inline] NF_HOOK include/linux/netfilter.h:307 [inline] NF_HOOK include/linux/netfilter.h:301 [inline] ipv6_rcv+0x28c/0x3c0 net/ipv6/ip6_input.c:297(CVE-2021-47397)
In the Linux kernel, the following vulnerability has been resolved:
ipack: ipoctal: fix stack information leak
The tty driver name is used also after registering the driver and must specifically not be allocated on the stack to avoid leaking information to user space (or triggering an oops).
Drivers should not try to encode topology information in the tty device name but this one snuck in through staging without anyone noticing and another driver has since copied this malpractice.
Fixing the ABI is a separate issue, but this at least plugs the security hole.(CVE-2021-47401)
In the Linux kernel, the following vulnerability has been resolved:
HID: betop: fix slab-out-of-bounds Write in betop_probe
Syzbot reported slab-out-of-bounds Write bug in hid-betopff driver. The problem is the driver assumes the device must have an input report but some malicious devices violate this assumption.
So this patch checks hid_device's input is non empty before it's been used.(CVE-2021-47404)
In the Linux kernel, the following vulnerability has been resolved:
HID: usbhid: free raw_report buffers in usbhid_stop
Free the unsent raw_report buffers when the device is removed.
Fixes a memory leak reported by syzbot at: https://syzkaller.appspot.com/bug?id=7b4fa7cb1a7c2d3342a2a8a6c53371c8c418ab47(CVE-2021-47405)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: conntrack: serialize hash resizes and cleanups
Syzbot was able to trigger the following warning [1]
No repro found by syzbot yet but I was able to trigger similar issue by having 2 scripts running in parallel, changing conntrack hash sizes, and:
for j in seq 1 1000 ; do unshare -n /bin/true >/dev/null ; done
It would take more than 5 minutes for net_namespace structures to be cleaned up.
This is because nf_ct_iterate_cleanup() has to restart everytime a resize happened.
By adding a mutex, we can serialize hash resizes and cleanups and also make get_next_corpse() faster by skipping over empty buckets.
Even without resizes in the picture, this patch considerably speeds up network namespace dismantles.
[1] INFO: task syz-executor.0:8312 can't die for more than 144 seconds. task:syz-executor.0 state:R running task stack:25672 pid: 8312 ppid: 6573 flags:0x00004006 Call Trace: context_switch kernel/sched/core.c:4955 [inline] __schedule+0x940/0x26f0 kernel/sched/core.c:6236 preempt_schedule_common+0x45/0xc0 kernel/sched/core.c:6408 preempt_schedule_thunk+0x16/0x18 arch/x86/entry/thunk_64.S:35 __local_bh_enable_ip+0x109/0x120 kernel/softirq.c:390 local_bh_enable include/linux/bottom_half.h:32 [inline] get_next_corpse net/netfilter/nf_conntrack_core.c:2252 [inline] nf_ct_iterate_cleanup+0x15a/0x450 net/netfilter/nf_conntrack_core.c:2275 nf_conntrack_cleanup_net_list+0x14c/0x4f0 net/netfilter/nf_conntrack_core.c:2469 ops_exit_list+0x10d/0x160 net/core/net_namespace.c:171 setup_net+0x639/0xa30 net/core/net_namespace.c:349 copy_net_ns+0x319/0x760 net/core/net_namespace.c:470 create_new_namespaces+0x3f6/0xb20 kernel/nsproxy.c:110 unshare_nsproxy_namespaces+0xc1/0x1f0 kernel/nsproxy.c:226 ksys_unshare+0x445/0x920 kernel/fork.c:3128 __do_sys_unshare kernel/fork.c:3202 [inline] __se_sys_unshare kernel/fork.c:3200 [inline] __x64_sys_unshare+0x2d/0x40 kernel/fork.c:3200 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f63da68e739 RSP: 002b:00007f63d7c05188 EFLAGS: 00000246 ORIG_RAX: 0000000000000110 RAX: ffffffffffffffda RBX: 00007f63da792f80 RCX: 00007f63da68e739 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000040000000 RBP: 00007f63da6e8cc4 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f63da792f80 R13: 00007fff50b75d3f R14: 00007f63d7c05300 R15: 0000000000022000
Showing all locks held in the system: 1 lock held by khungtaskd/27: #0: ffffffff8b980020 (rcu_read_lock){....}-{1:2}, at: debug_show_all_locks+0x53/0x260 kernel/locking/lockdep.c:6446 2 locks held by kworker/u4:2/153: #0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: arch_atomic64_set arch/x86/include/asm/atomic64_64.h:34 [inline] #0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: arch_atomic_long_set include/linux/atomic/atomic-long.h:41 [inline] #0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: atomic_long_set include/linux/atomic/atomic-instrumented.h:1198 [inline] #0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: set_work_data kernel/workqueue.c:634 [inline] #0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: set_work_pool_and_clear_pending kernel/workqueue.c:661 [inline] #0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: process_one_work+0x896/0x1690 kernel/workqueue.c:2268 #1: ffffc9000140fdb0 ((kfence_timer).work){+.+.}-{0:0}, at: process_one_work+0x8ca/0x1690 kernel/workqueue.c:2272 1 lock held by systemd-udevd/2970: 1 lock held by in:imklog/6258: #0: ffff88807f970ff0 (&f->f_pos_lock){+.+.}-{3:3}, at: __fdget_pos+0xe9/0x100 fs/file.c:990 3 locks held by kworker/1:6/8158: 1 lock held by syz-executor.0/8312: 2 locks held by kworker/u4:13/9320: 1 lock held by ---truncated---(CVE-2021-47408)
In the Linux kernel, the following vulnerability has been resolved:
drm/nouveau/debugfs: fix file release memory leak
When using single_open() for opening, single_release() should be called, otherwise the 'op' allocated in single_open() will be leaked.(CVE-2021-47423)
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:
net/mlx5e: Fix memory leak in mlx5_core_destroy_cq() error path
Prior to this patch in case mlx5_core_destroy_cq() failed it returns without completing all destroy operations and that leads to memory leak. Instead, complete the destroy flow before return error.
Also move mlx5_debug_cq_remove() to the beginning of mlx5_core_destroy_cq() to be symmetrical with mlx5_core_create_cq().
kmemleak complains on:
unreferenced object 0xc000000038625100 (size 64): comm "ethtool", pid 28301, jiffies 4298062946 (age 785.380s) hex dump (first 32 bytes): 60 01 48 94 00 00 00 c0 b8 05 34 c3 00 00 00 c0 `.H.......4..... 02 00 00 00 00 00 00 00 00 db 7d c1 00 00 00 c0 ..........}..... backtrace: [<000000009e8643cb>] add_res_tree+0xd0/0x270 [mlx5_core] [<00000000e7cb8e6c>] mlx5_debug_cq_add+0x5c/0xc0 [mlx5_core] [<000000002a12918f>] mlx5_core_create_cq+0x1d0/0x2d0 [mlx5_core] [<00000000cef0a696>] mlx5e_create_cq+0x210/0x3f0 [mlx5_core] [<000000009c642c26>] mlx5e_open_cq+0xb4/0x130 [mlx5_core] [<0000000058dfa578>] mlx5e_ptp_open+0x7f4/0xe10 [mlx5_core] [<0000000081839561>] mlx5e_open_channels+0x9cc/0x13e0 [mlx5_core] [<0000000009cf05d4>] mlx5e_switch_priv_channels+0xa4/0x230 [mlx5_core] [<0000000042bbedd8>] mlx5e_safe_switch_params+0x14c/0x300 [mlx5_core] [<0000000004bc9db8>] set_pflag_tx_port_ts+0x9c/0x160 [mlx5_core] [<00000000a0553443>] mlx5e_set_priv_flags+0xd0/0x1b0 [mlx5_core] [<00000000a8f3d84b>] ethnl_set_privflags+0x234/0x2d0 [<00000000fd27f27c>] genl_family_rcv_msg_doit+0x108/0x1d0 [<00000000f495e2bb>] genl_family_rcv_msg+0xe4/0x1f0 [<00000000646c5c2c>] genl_rcv_msg+0x78/0x120 [<00000000d53e384e>] netlink_rcv_skb+0x74/0x1a0(CVE-2021-47438)
In the Linux kernel, the following vulnerability has been resolved:
NFC: digital: fix possible memory leak in digital_in_send_sdd_req()
'skb' is allocated in digital_in_send_sdd_req(), but not free when digital_in_send_cmd() failed, which will cause memory leak. Fix it by freeing 'skb' if digital_in_send_cmd() return failed.(CVE-2021-47442)
In the Linux kernel, the following vulnerability has been resolved:
NFC: digital: fix possible memory leak in digital_tg_listen_mdaa()
'params' is allocated in digital_tg_listen_mdaa(), but not free when digital_send_cmd() failed, which will cause memory leak. Fix it by freeing 'params' if digital_send_cmd() return failed.(CVE-2021-47443)
In the Linux kernel, the following vulnerability has been resolved:
drm/msm: Fix null pointer dereference on pointer edp
The initialization of pointer dev dereferences pointer edp before edp is null checked, so there is a potential null pointer deference issue. Fix this by only dereferencing edp after edp has been null checked.
Addresses-Coverity: ("Dereference before null check")(CVE-2021-47445)
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: mount fails with buffer overflow in strlen
Starting with kernel 5.11 built with CONFIG_FORTIFY_SOURCE mouting an ocfs2 filesystem with either o2cb or pcmk cluster stack fails with the trace below. Problem seems to be that strings for cluster stack and cluster name are not guaranteed to be null terminated in the disk representation, while strlcpy assumes that the source string is always null terminated. This causes a read outside of the source string triggering the buffer overflow detection.
detected buffer overflow in strlen ------------[ cut here ]------------ kernel BUG at lib/string.c:1149! invalid opcode: 0000 [#1] SMP PTI CPU: 1 PID: 910 Comm: mount.ocfs2 Not tainted 5.14.0-1-amd64 #1 Debian 5.14.6-2 RIP: 0010:fortify_panic+0xf/0x11 ... Call Trace: ocfs2_initialize_super.isra.0.cold+0xc/0x18 [ocfs2] ocfs2_fill_super+0x359/0x19b0 [ocfs2] mount_bdev+0x185/0x1b0 legacy_get_tree+0x27/0x40 vfs_get_tree+0x25/0xb0 path_mount+0x454/0xa20 __x64_sys_mount+0x103/0x140 do_syscall_64+0x3b/0xc0 entry_SYSCALL_64_after_hwframe+0x44/0xae(CVE-2021-47458)
In the Linux kernel, the following vulnerability has been resolved:
can: j1939: j1939_netdev_start(): fix UAF for rx_kref of j1939_priv
It will trigger UAF for rx_kref of j1939_priv as following.
cpu0 cpu1
j1939_sk_bind(socket0, ndev0, ...) j1939_netdev_start j1939_sk_bind(socket1, ndev0, ...) j1939_netdev_start j1939_priv_set j1939_priv_get_by_ndev_locked j1939_jsk_add ..... j1939_netdev_stop kref_put_lock(&priv->rx_kref, ...) kref_get(&priv->rx_kref, ...) REFCOUNT_WARN("addition on 0;...")
==================================================== refcount_t: addition on 0; use-after-free. WARNING: CPU: 1 PID: 20874 at lib/refcount.c:25 refcount_warn_saturate+0x169/0x1e0 RIP: 0010:refcount_warn_saturate+0x169/0x1e0 Call Trace: j1939_netdev_start+0x68b/0x920 j1939_sk_bind+0x426/0xeb0 ? security_socket_bind+0x83/0xb0
The rx_kref's kref_get() and kref_put() should use j1939_netdev_lock to protect.(CVE-2021-47459)
In the Linux kernel, the following vulnerability has been resolved:
comedi: vmk80xx: fix transfer-buffer overflows
The driver uses endpoint-sized USB transfer buffers but up until recently had no sanity checks on the sizes.
Commit e1f13c879a7c ("staging: comedi: check validity of wMaxPacketSize of usb endpoints found") inadvertently fixed NULL-pointer dereferences when accessing the transfer buffers in case a malicious device has a zero wMaxPacketSize.
Make sure to allocate buffers large enough to handle also the other accesses that are done without a size check (e.g. byte 18 in vmk80xx_cnt_insn_read() for the VMK8061_MODEL) to avoid writing beyond the buffers, for example, when doing descriptor fuzzing.
The original driver was for a low-speed device with 8-byte buffers. Support was later added for a device that uses bulk transfers and is presumably a full-speed device with a maximum 64-byte wMaxPacketSize.(CVE-2021-47475)
In the Linux kernel, the following vulnerability has been resolved:
comedi: dt9812: fix DMA buffers on stack
USB transfer buffers are typically mapped for DMA and must not be allocated on the stack or transfers will fail.
Allocate proper transfer buffers in the various command helpers and return an error on short transfers instead of acting on random stack data.
Note that this also fixes a stack info leak on systems where DMA is not used as 32 bytes are always sent to the device regardless of how short the command is.(CVE-2021-47477)
In the Linux kernel, the following vulnerability has been resolved:
usbnet: sanity check for maxpacket
maxpacket of 0 makes no sense and oopses as we need to divide by it. Give up.
V2: fixed typo in log and stylistic issues(CVE-2021-47495)
In the Linux kernel, the following vulnerability has been resolved:
perf hist: Fix memory leak of a perf_hpp_fmt
perf_hpp__column_unregister() removes an entry from a list but doesn't free the memory causing a memory leak spotted by leak sanitizer.
Add the free while at the same time reducing the scope of the function to static.(CVE-2021-47545)
In the Linux kernel, the following vulnerability has been resolved:
ethernet: hisilicon: hns: hns_dsaf_misc: fix a possible array overflow in hns_dsaf_ge_srst_by_port()
The if statement: if (port >= DSAF_GE_NUM) return;
limits the value of port less than DSAF_GE_NUM (i.e., 8). However, if the value of port is 6 or 7, an array overflow could occur: port_rst_off = dsaf_dev->mac_cb[port]->port_rst_off;
because the length of dsaf_dev->mac_cb is DSAF_MAX_PORT_NUM (i.e., 6).
To fix this possible array overflow, we first check port and if it is greater than or equal to DSAF_MAX_PORT_NUM, the function returns.(CVE-2021-47548)
In the Linux kernel, the following vulnerability has been resolved:
sata_fsl: fix UAF in sata_fsl_port_stop when rmmod sata_fsl
When the rmmod sata_fsl.ko command is executed in the PPC64 GNU/Linux,
a bug is reported:
==================================================================
BUG: Unable to handle kernel data access on read at 0x80000800805b502c
Oops: Kernel access of bad area, sig: 11 [#1]
NIP [c0000000000388a4] .ioread32+0x4/0x20
LR [80000000000c6034] .sata_fsl_port_stop+0x44/0xe0 [sata_fsl]
Call Trace:
.free_irq+0x1c/0x4e0 (unreliable)
.ata_host_stop+0x74/0xd0 [libata]
.release_nodes+0x330/0x3f0
.device_release_driver_internal+0x178/0x2c0
.driver_detach+0x64/0xd0
.bus_remove_driver+0x70/0xf0
.driver_unregister+0x38/0x80
.platform_driver_unregister+0x14/0x30
.fsl_sata_driver_exit+0x18/0xa20 [sata_fsl]
.__se_sys_delete_module+0x1ec/0x2d0
.system_call_exception+0xfc/0x1f0
system_call_common+0xf8/0x200
==================================================================
The triggering of the BUG is shown in the following stack:
driver_detach device_release_driver_internal __device_release_driver drv->remove(dev) --> platform_drv_remove/platform_remove drv->remove(dev) --> sata_fsl_remove iounmap(host_priv->hcr_base); <---- unmap kfree(host_priv); <---- free devres_release_all release_nodes dr->node.release(dev, dr->data) --> ata_host_stop ap->ops->port_stop(ap) --> sata_fsl_port_stop ioread32(hcr_base + HCONTROL) <---- UAF host->ops->host_stop(host)
The iounmap(host_priv->hcr_base) and kfree(host_priv) functions should not be executed in drv->remove. These functions should be executed in host_stop after port_stop. Therefore, we move these functions to the new function sata_fsl_host_stop and bind the new function to host_stop.(CVE-2021-47549)
In the Linux kernel, the following vulnerability has been resolved:
net/smc: Fix NULL pointer dereferencing in smc_vlan_by_tcpsk()
Coverity reports a possible NULL dereferencing problem:
in smc_vlan_by_tcpsk(): 6. returned_null: netdev_lower_get_next returns NULL (checked 29 out of 30 times). 7. var_assigned: Assigning: ndev = NULL return value from netdev_lower_get_next. 1623 ndev = (struct net_device *)netdev_lower_get_next(ndev, &lower); CID 1468509 (#1 of 1): Dereference null return value (NULL_RETURNS) 8. dereference: Dereferencing a pointer that might be NULL ndev when calling is_vlan_dev. 1624 if (is_vlan_dev(ndev)) {
Remove the manual implementation and use netdev_walk_all_lower_dev() to iterate over the lower devices. While on it remove an obsolete function parameter comment.(CVE-2021-47559)
In the Linux kernel, the following vulnerability has been resolved:
pinctrl: single: fix potential NULL dereference
Added checking of pointer "function" in pcs_set_mux(). pinmux_generic_get_function() can return NULL and the pointer "function" was dereferenced without checking against NULL.
Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2022-48708)
In the Linux kernel, the following vulnerability has been resolved:
crypto: s390/aes - Fix buffer overread in CTR mode
When processing the last block, the s390 ctr code will always read a whole block, even if there isn't a whole block of data left. Fix this by using the actual length left and copy it into a buffer first for processing.(CVE-2023-52669)
In the Linux kernel, the following vulnerability has been resolved:
ACPI: video: check for error while searching for backlight device parent
If acpi_get_parent() called in acpi_video_dev_register_backlight() fails, for example, because acpi_ut_acquire_mutex() fails inside acpi_get_parent), this can lead to incorrect (uninitialized) acpi_parent handle being passed to acpi_get_pci_dev() for detecting the parent pci device.
Check acpi_get_parent() result and set parent device only in case of success.
Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2023-52693)
In the Linux kernel, the following vulnerability has been resolved:
sysv: don't call sb_bread() with pointers_lock held
syzbot is reporting sleep in atomic context in SysV filesystem [1], for sb_bread() is called with rw_spinlock held.
A "write_lock(&pointers_lock) => read_lock(&pointers_lock) deadlock" bug and a "sb_bread() with write_lock(&pointers_lock)" bug were introduced by "Replace BKL for chain locking with sysvfs-private rwlock" in Linux 2.5.12.
Then, "[PATCH] err1-40: sysvfs locking fix" in Linux 2.6.8 fixed the former bug by moving pointers_lock lock to the callers, but instead introduced a "sb_bread() with read_lock(&pointers_lock)" bug (which made this problem easier to hit).
Al Viro suggested that why not to do like get_branch()/get_block()/ find_shared() in Minix filesystem does. And doing like that is almost a revert of "[PATCH] err1-40: sysvfs locking fix" except that get_branch() from with find_shared() is called without write_lock(&pointers_lock).(CVE-2023-52699)
In the Linux kernel, the following vulnerability has been resolved:
net/usb: kalmia: Don't pass act_len in usb_bulk_msg error path
syzbot reported that act_len in kalmia_send_init_packet() is uninitialized when passing it to the first usb_bulk_msg error path. Jiri Pirko noted that it's pointless to pass it in the error path, and that the value that would be printed in the second error path would be the value of act_len from the first call to usb_bulk_msg.[1]
With this in mind, let's just not pass act_len to the usb_bulk_msg error paths.
1: https://lore.kernel.org/lkml/Y9pY61y1nwTuzMOa@nanopsycho/(CVE-2023-52703)
In the Linux kernel, the following vulnerability has been resolved:
arm64: Restrict CPU_BIG_ENDIAN to GNU as or LLVM IAS 15.x or newer
Prior to LLVM 15.0.0, LLVM's integrated assembler would incorrectly byte-swap NOP when compiling for big-endian, and the resulting series of bytes happened to match the encoding of FNMADD S21, S30, S0, S0.
This went unnoticed until commit:
34f66c4c4d5518c1 ("arm64: Use a positive cpucap for FP/SIMD")
Prior to that commit, the kernel would always enable the use of FPSIMD early in boot when __cpu_setup() initialized CPACR_EL1, and so usage of FNMADD within the kernel was not detected, but could result in the corruption of user or kernel FPSIMD state.
After that commit, the instructions happen to trap during boot prior to FPSIMD being detected and enabled, e.g.
| Unhandled 64-bit el1h sync exception on CPU0, ESR 0x000000001fe00000 -- ASIMD | CPU: 0 PID: 0 Comm: swapper Not tainted 6.6.0-rc3-00013-g34f66c4c4d55 #1 | Hardware name: linux,dummy-virt (DT) | pstate: 400000c9 (nZcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) | pc : __pi_strcmp+0x1c/0x150 | lr : populate_properties+0xe4/0x254 | sp : ffffd014173d3ad0 | x29: ffffd014173d3af0 x28: fffffbfffddffcb8 x27: 0000000000000000 | x26: 0000000000000058 x25: fffffbfffddfe054 x24: 0000000000000008 | x23: fffffbfffddfe000 x22: fffffbfffddfe000 x21: fffffbfffddfe044 | x20: ffffd014173d3b70 x19: 0000000000000001 x18: 0000000000000005 | x17: 0000000000000010 x16: 0000000000000000 x15: 00000000413e7000 | x14: 0000000000000000 x13: 0000000000001bcc x12: 0000000000000000 | x11: 00000000d00dfeed x10: ffffd414193f2cd0 x9 : 0000000000000000 | x8 : 0101010101010101 x7 : ffffffffffffffc0 x6 : 0000000000000000 | x5 : 0000000000000000 x4 : 0101010101010101 x3 : 000000000000002a | x2 : 0000000000000001 x1 : ffffd014171f2988 x0 : fffffbfffddffcb8 | Kernel panic - not syncing: Unhandled exception | CPU: 0 PID: 0 Comm: swapper Not tainted 6.6.0-rc3-00013-g34f66c4c4d55 #1 | Hardware name: linux,dummy-virt (DT) | Call trace: | dump_backtrace+0xec/0x108 | show_stack+0x18/0x2c | dump_stack_lvl+0x50/0x68 | dump_stack+0x18/0x24 | panic+0x13c/0x340 | el1t_64_irq_handler+0x0/0x1c | el1_abort+0x0/0x5c | el1h_64_sync+0x64/0x68 | __pi_strcmp+0x1c/0x150 | unflatten_dt_nodes+0x1e8/0x2d8 | __unflatten_device_tree+0x5c/0x15c | unflatten_device_tree+0x38/0x50 | setup_arch+0x164/0x1e0 | start_kernel+0x64/0x38c | __primary_switched+0xbc/0xc4
Restrict CONFIG_CPU_BIG_ENDIAN to a known good assembler, which is either GNU as or LLVM's IAS 15.0.0 and newer, which contains the linked commit.(CVE-2023-52750)
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix use-after-free bug in cifs_debug_data_proc_show()
Skip SMB sessions that are being teared down (e.g. @ses->ses_status == SES_EXITING) in cifs_debug_data_proc_show() to avoid use-after-free in @ses.
This fixes the following GPF when reading from /proc/fs/cifs/DebugData while mounting and umounting
[ 816.251274] general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6d81: 0000 [#1] PREEMPT SMP NOPTI ... [ 816.260138] Call Trace: [ 816.260329] <TASK> [ 816.260499] ? die_addr+0x36/0x90 [ 816.260762] ? exc_general_protection+0x1b3/0x410 [ 816.261126] ? asm_exc_general_protection+0x26/0x30 [ 816.261502] ? cifs_debug_tcon+0xbd/0x240 [cifs] [ 816.261878] ? cifs_debug_tcon+0xab/0x240 [cifs] [ 816.262249] cifs_debug_data_proc_show+0x516/0xdb0 [cifs] [ 816.262689] ? seq_read_iter+0x379/0x470 [ 816.262995] seq_read_iter+0x118/0x470 [ 816.263291] proc_reg_read_iter+0x53/0x90 [ 816.263596] ? srso_alias_return_thunk+0x5/0x7f [ 816.263945] vfs_read+0x201/0x350 [ 816.264211] ksys_read+0x75/0x100 [ 816.264472] do_syscall_64+0x3f/0x90 [ 816.264750] entry_SYSCALL_64_after_hwframe+0x6e/0xd8 [ 816.265135] RIP: 0033:0x7fd5e669d381(CVE-2023-52752)
In the Linux kernel, the following vulnerability has been resolved:
gfs2: ignore negated quota changes
When lots of quota changes are made, there may be cases in which an inode's quota information is increased and then decreased, such as when blocks are added to a file, then deleted from it. If the timing is right, function do_qc can add pending quota changes to a transaction, then later, another call to do_qc can negate those changes, resulting in a net gain of 0. The quota_change information is recorded in the qc buffer (and qd element of the inode as well). The buffer is added to the transaction by the first call to do_qc, but a subsequent call changes the value from non-zero back to zero. At that point it's too late to remove the buffer_head from the transaction. Later, when the quota sync code is called, the zero-change qd element is discovered and flagged as an assert warning. If the fs is mounted with errors=panic, the kernel will panic.
This is usually seen when files are truncated and the quota changes are negated by punch_hole/truncate which uses gfs2_quota_hold and gfs2_quota_unhold rather than block allocations that use gfs2_quota_lock and gfs2_quota_unlock which automatically do quota sync.
This patch solves the problem by adding a check to qd_check_sync such that net-zero quota changes already added to the transaction are no longer deemed necessary to be synced, and skipped.
In this case references are taken for the qd and the slot from do_qc so those need to be put. The normal sequence of events for a normal non-zero quota change is as follows:
gfs2_quota_change do_qc qd_hold slot_hold
Later, when the changes are to be synced:
gfs2_quota_sync qd_fish qd_check_sync gets qd ref via lockref_get_not_dead do_sync do_qc(QC_SYNC) qd_put lockref_put_or_lock qd_unlock qd_put lockref_put_or_lock
In the net-zero change case, we add a check to qd_check_sync so it puts the qd and slot references acquired in gfs2_quota_change and skip the unneeded sync.(CVE-2023-52759)
In the Linux kernel, the following vulnerability has been resolved:
tty: vcc: Add check for kstrdup() in vcc_probe()
Add check for the return value of kstrdup() and return the error, if it fails in order to avoid NULL pointer dereference.(CVE-2023-52789)
In the Linux kernel, the following vulnerability has been resolved:
ipvlan: add ipvlan_route_v6_outbound() helper
Inspired by syzbot reports using a stack of multiple ipvlan devices.
Reduce stack size needed in ipvlan_process_v6_outbound() by moving the flowi6 struct used for the route lookup in an non inlined helper. ipvlan_route_v6_outbound() needs 120 bytes on the stack, immediately reclaimed.
Also make sure ipvlan_process_v4_outbound() is not inlined.
We might also have to lower MAX_NEST_DEV, because only syzbot uses setups with more than four stacked devices.
BUG: TASK stack guard page was hit at ffffc9000e803ff8 (stack is ffffc9000e804000..ffffc9000e808000) stack guard page: 0000 [#1] SMP KASAN CPU: 0 PID: 13442 Comm: syz-executor.4 Not tainted 6.1.52-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/09/2023 RIP: 0010:kasan_check_range+0x4/0x2a0 mm/kasan/generic.c:188 Code: 48 01 c6 48 89 c7 e8 db 4e c1 03 31 c0 5d c3 cc 0f 0b eb 02 0f 0b b8 ea ff ff ff 5d c3 cc 00 00 cc cc 00 00 cc cc 55 48 89 e5 <41> 57 41 56 41 55 41 54 53 b0 01 48 85 f6 0f 84 a4 01 00 00 48 89 RSP: 0018:ffffc9000e804000 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff817e5bf2 RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffffffff887c6568 RBP: ffffc9000e804000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: dffffc0000000001 R12: 1ffff92001d0080c R13: dffffc0000000000 R14: ffffffff87e6b100 R15: 0000000000000000 FS: 00007fd0c55826c0(0000) GS:ffff8881f6800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffc9000e803ff8 CR3: 0000000170ef7000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <#DF> </#DF> <TASK> [<ffffffff81f281d1>] __kasan_check_read+0x11/0x20 mm/kasan/shadow.c:31 [<ffffffff817e5bf2>] instrument_atomic_read include/linux/instrumented.h:72 [inline] [<ffffffff817e5bf2>] _test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline] [<ffffffff817e5bf2>] cpumask_test_cpu include/linux/cpumask.h:506 [inline] [<ffffffff817e5bf2>] cpu_online include/linux/cpumask.h:1092 [inline] [<ffffffff817e5bf2>] trace_lock_acquire include/trace/events/lock.h:24 [inline] [<ffffffff817e5bf2>] lock_acquire+0xe2/0x590 kernel/locking/lockdep.c:5632 [<ffffffff8563221e>] rcu_lock_acquire+0x2e/0x40 include/linux/rcupdate.h:306 [<ffffffff8561464d>] rcu_read_lock include/linux/rcupdate.h:747 [inline] [<ffffffff8561464d>] ip6_pol_route+0x15d/0x1440 net/ipv6/route.c:2221 [<ffffffff85618120>] ip6_pol_route_output+0x50/0x80 net/ipv6/route.c:2606 [<ffffffff856f65b5>] pol_lookup_func include/net/ip6_fib.h:584 [inline] [<ffffffff856f65b5>] fib6_rule_lookup+0x265/0x620 net/ipv6/fib6_rules.c:116 [<ffffffff85618009>] ip6_route_output_flags_noref+0x2d9/0x3a0 net/ipv6/route.c:2638 [<ffffffff8561821a>] ip6_route_output_flags+0xca/0x340 net/ipv6/route.c:2651 [<ffffffff838bd5a3>] ip6_route_output include/net/ip6_route.h:100 [inline] [<ffffffff838bd5a3>] ipvlan_process_v6_outbound drivers/net/ipvlan/ipvlan_core.c:473 [inline] [<ffffffff838bd5a3>] ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:529 [inline] [<ffffffff838bd5a3>] ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline] [<ffffffff838bd5a3>] ipvlan_queue_xmit+0xc33/0x1be0 drivers/net/ipvlan/ipvlan_core.c:677 [<ffffffff838c2909>] ipvlan_start_xmit+0x49/0x100 drivers/net/ipvlan/ipvlan_main.c:229 [<ffffffff84d03900>] netdev_start_xmit include/linux/netdevice.h:4966 [inline] [<ffffffff84d03900>] xmit_one net/core/dev.c:3644 [inline] [<ffffffff84d03900>] dev_hard_start_xmit+0x320/0x980 net/core/dev.c:3660 [<ffffffff84d080e2>] __dev_queue_xmit+0x16b2/0x3370 net/core/dev.c:4324 [<ffffffff855ce4cd>] dev_queue_xmit include/linux/netdevice.h:3067 [inline] [<ffffffff855ce4cd>] neigh_hh_output include/net/neighbour.h:529 [inline] [<f ---truncated---(CVE-2023-52796)
In the Linux kernel, the following vulnerability has been resolved:
jfs: fix array-index-out-of-bounds in dbFindLeaf
Currently while searching for dmtree_t for sufficient free blocks there is an array out of bounds while getting element in tp->dm_stree. To add the required check for out of bound we first need to determine the type of dmtree. Thus added an extra parameter to dbFindLeaf so that the type of tree can be determined and the required check can be applied.(CVE-2023-52799)
In the Linux kernel, the following vulnerability has been resolved:
iio: adc: stm32-adc: harden against NULL pointer deref in stm32_adc_probe()
of_match_device() may fail and returns a NULL pointer.
In practice there is no known reasonable way to trigger this, but in case one is added in future, harden the code by adding the check(CVE-2023-52802)
In the Linux kernel, the following vulnerability has been resolved:
fs/jfs: Add validity check for db_maxag and db_agpref
Both db_maxag and db_agpref are used as the index of the db_agfree array, but there is currently no validity check for db_maxag and db_agpref, which can lead to errors.
The following is related bug reported by Syzbot:
UBSAN: array-index-out-of-bounds in fs/jfs/jfs_dmap.c:639:20 index 7936 is out of range for type 'atomic_t[128]'
Add checking that the values of db_maxag and db_agpref are valid indexes for the db_agfree array.(CVE-2023-52804)
In the Linux kernel, the following vulnerability has been resolved:
jfs: fix array-index-out-of-bounds in diAlloc
Currently there is not check against the agno of the iag while allocating new inodes to avoid fragmentation problem. Added the check which is required.(CVE-2023-52805)
In the Linux kernel, the following vulnerability has been resolved:
scsi: libfc: Fix potential NULL pointer dereference in fc_lport_ptp_setup()
fc_lport_ptp_setup() did not check the return value of fc_rport_create() which can return NULL and would cause a NULL pointer dereference. Address this issue by checking return value of fc_rport_create() and log error message on fc_rport_create() failed.(CVE-2023-52809)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd: Fix UBSAN array-index-out-of-bounds for Polaris and Tonga
For pptable structs that use flexible array sizes, use flexible arrays.(CVE-2023-52819)
In the Linux kernel, the following vulnerability has been resolved:
cpu/hotplug: Don't offline the last non-isolated CPU
If a system has isolated CPUs via the "isolcpus=" command line parameter, then an attempt to offline the last housekeeping CPU will result in a WARN_ON() when rebuilding the scheduler domains and a subsequent panic due to and unhandled empty CPU mas in partition_sched_domains_locked().
cpuset_hotplug_workfn() rebuild_sched_domains_locked() ndoms = generate_sched_domains(&doms, &attr); cpumask_and(doms[0], top_cpuset.effective_cpus, housekeeping_cpumask(HK_FLAG_DOMAIN));
Thus results in an empty CPU mask which triggers the warning and then the subsequent crash:
WARNING: CPU: 4 PID: 80 at kernel/sched/topology.c:2366 build_sched_domains+0x120c/0x1408 Call trace: build_sched_domains+0x120c/0x1408 partition_sched_domains_locked+0x234/0x880 rebuild_sched_domains_locked+0x37c/0x798 rebuild_sched_domains+0x30/0x58 cpuset_hotplug_workfn+0x2a8/0x930
Unable to handle kernel paging request at virtual address fffe80027ab37080 partition_sched_domains_locked+0x318/0x880 rebuild_sched_domains_locked+0x37c/0x798
Aside of the resulting crash, it does not make any sense to offline the last last housekeeping CPU.
Prevent this by masking out the non-housekeeping CPUs when selecting a target CPU for initiating the CPU unplug operation via the work queue.(CVE-2023-52831)
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: don't return unset power in ieee80211_get_tx_power()
We can get a UBSAN warning if ieee80211_get_tx_power() returns the INT_MIN value mac80211 internally uses for "unset power level".
UBSAN: signed-integer-overflow in net/wireless/nl80211.c:3816:5 -2147483648 * 100 cannot be represented in type 'int' CPU: 0 PID: 20433 Comm: insmod Tainted: G WC OE Call Trace: dump_stack+0x74/0x92 ubsan_epilogue+0x9/0x50 handle_overflow+0x8d/0xd0 __ubsan_handle_mul_overflow+0xe/0x10 nl80211_send_iface+0x688/0x6b0 [cfg80211] [...] cfg80211_register_wdev+0x78/0xb0 [cfg80211] cfg80211_netdev_notifier_call+0x200/0x620 [cfg80211] [...] ieee80211_if_add+0x60e/0x8f0 [mac80211] ieee80211_register_hw+0xda5/0x1170 [mac80211]
In this case, simply return an error instead, to indicate that no data is available.(CVE-2023-52832)
In the Linux kernel, the following vulnerability has been resolved:
tipc: Change nla_policy for bearer-related names to NLA_NUL_STRING
syzbot reported the following uninit-value access issue [1]:
===================================================== BUG: KMSAN: uninit-value in strlen lib/string.c:418 [inline] BUG: KMSAN: uninit-value in strstr+0xb8/0x2f0 lib/string.c:756 strlen lib/string.c:418 [inline] strstr+0xb8/0x2f0 lib/string.c:756 tipc_nl_node_reset_link_stats+0x3ea/0xb50 net/tipc/node.c:2595 genl_family_rcv_msg_doit net/netlink/genetlink.c:971 [inline] genl_family_rcv_msg net/netlink/genetlink.c:1051 [inline] genl_rcv_msg+0x11ec/0x1290 net/netlink/genetlink.c:1066 netlink_rcv_skb+0x371/0x650 net/netlink/af_netlink.c:2545 genl_rcv+0x40/0x60 net/netlink/genetlink.c:1075 netlink_unicast_kernel net/netlink/af_netlink.c:1342 [inline] netlink_unicast+0xf47/0x1250 net/netlink/af_netlink.c:1368 netlink_sendmsg+0x1238/0x13d0 net/netlink/af_netlink.c:1910 sock_sendmsg_nosec net/socket.c:730 [inline] sock_sendmsg net/socket.c:753 [inline] _syssendmsg+0x9c2/0xd60 net/socket.c:2541 _sys_sendmsg+0x28d/0x3c0 net/socket.c:2595 __sys_sendmsg net/socket.c:2624 [inline] __do_sys_sendmsg net/socket.c:2633 [inline] __se_sys_sendmsg net/socket.c:2631 [inline] __x64_sys_sendmsg+0x307/0x490 net/socket.c:2631 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd
Uninit was created at: slab_post_alloc_hook+0x12f/0xb70 mm/slab.h:767 slab_alloc_node mm/slub.c:3478 [inline] kmem_cache_alloc_node+0x577/0xa80 mm/slub.c:3523 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:559 __alloc_skb+0x318/0x740 net/core/skbuff.c:650 alloc_skb include/linux/skbuff.h:1286 [inline] netlink_alloc_large_skb net/netlink/af_netlink.c:1214 [inline] netlink_sendmsg+0xb34/0x13d0 net/netlink/af_netlink.c:1885 sock_sendmsg_nosec net/socket.c:730 [inline] sock_sendmsg net/socket.c:753 [inline] _syssendmsg+0x9c2/0xd60 net/socket.c:2541 _sys_sendmsg+0x28d/0x3c0 net/socket.c:2595 __sys_sendmsg net/socket.c:2624 [inline] __do_sys_sendmsg net/socket.c:2633 [inline] __se_sys_sendmsg net/socket.c:2631 [inline] __x64_sys_sendmsg+0x307/0x490 net/socket.c:2631 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd
TIPC bearer-related names including link names must be null-terminated strings. If a link name which is not null-terminated is passed through netlink, strstr() and similar functions can cause buffer overrun. This causes the above issue.
This patch changes the nla_policy for bearer-related names from NLA_STRING to NLA_NUL_STRING. This resolves the issue by ensuring that only null-terminated strings are accepted as bearer-related names.
syzbot reported similar uninit-value issue related to bearer names [2]. The root cause of this issue is that a non-null-terminated bearer name was passed. This patch also resolved this issue.(CVE-2023-52845)
In the Linux kernel, the following vulnerability has been resolved:
can: dev: can_put_echo_skb(): don't crash kernel if can_priv::echo_skb is accessed out of bounds
If the "struct can_priv::echoo_skb" is accessed out of bounds, this would cause a kernel crash. Instead, issue a meaningful warning message and return with an error.(CVE-2023-52878)
In the Linux kernel, the following vulnerability has been resolved:
USB: core: Fix deadlock in usb_deauthorize_interface()
Among the attribute file callback routines in drivers/usb/core/sysfs.c, the interface_authorized_store() function is the only one which acquires a device lock on an ancestor device: It calls usb_deauthorize_interface(), which locks the interface's parent USB device.
The will lead to deadlock if another process already owns that lock and tries to remove the interface, whether through a configuration change or because the device has been disconnected. As part of the removal procedure, device_del() waits for all ongoing sysfs attribute callbacks to complete. But usb_deauthorize_interface() can't complete until the device lock has been released, and the lock won't be released until the removal has finished.
The mechanism provided by sysfs to prevent this kind of deadlock is to use the sysfs_break_active_protection() function, which tells sysfs not to wait for the attribute callback.
Reported-and-tested by: Yue Sun <samsun1006219@gmail.com> Reported by: xingwei lee <xrivendell7@gmail.com>(CVE-2024-26934)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: Fix potential data-race in __nft_expr_type_get()
nft_unregister_expr() can concurrent with __nft_expr_type_get(), and there is not any protection when iterate over nf_tables_expressions list in __nft_expr_type_get(). Therefore, there is potential data-race of nf_tables_expressions list entry.
Use list_for_each_entry_rcu() to iterate over nf_tables_expressions list in __nft_expr_type_get(), and use rcu_read_lock() in the caller nft_expr_type_get() to protect the entire type query process.(CVE-2024-27020)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: l2cap: fix null-ptr-deref in l2cap_chan_timeout
There is a race condition between l2cap_chan_timeout() and l2cap_chan_del(). When we use l2cap_chan_del() to delete the channel, the chan->conn will be set to null. But the conn could be dereferenced again in the mutex_lock() of l2cap_chan_timeout(). As a result the null pointer dereference bug will happen. The KASAN report triggered by POC is shown below:
[ 472.074580] ================================================================== [ 472.075284] BUG: KASAN: null-ptr-deref in mutex_lock+0x68/0xc0 [ 472.075308] Write of size 8 at addr 0000000000000158 by task kworker/0:0/7 [ 472.075308] [ 472.075308] CPU: 0 PID: 7 Comm: kworker/0:0 Not tainted 6.9.0-rc5-00356-g78c0094a146b #36 [ 472.075308] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu4 [ 472.075308] Workqueue: events l2cap_chan_timeout [ 472.075308] Call Trace: [ 472.075308] <TASK> [ 472.075308] dump_stack_lvl+0x137/0x1a0 [ 472.075308] print_report+0x101/0x250 [ 472.075308] ? __virt_addr_valid+0x77/0x160 [ 472.075308] ? mutex_lock+0x68/0xc0 [ 472.075308] kasan_report+0x139/0x170 [ 472.075308] ? mutex_lock+0x68/0xc0 [ 472.075308] kasan_check_range+0x2c3/0x2e0 [ 472.075308] mutex_lock+0x68/0xc0 [ 472.075308] l2cap_chan_timeout+0x181/0x300 [ 472.075308] process_one_work+0x5d2/0xe00 [ 472.075308] worker_thread+0xe1d/0x1660 [ 472.075308] ? pr_cont_work+0x5e0/0x5e0 [ 472.075308] kthread+0x2b7/0x350 [ 472.075308] ? pr_cont_work+0x5e0/0x5e0 [ 472.075308] ? kthread_blkcg+0xd0/0xd0 [ 472.075308] ret_from_fork+0x4d/0x80 [ 472.075308] ? kthread_blkcg+0xd0/0xd0 [ 472.075308] ret_from_fork_asm+0x11/0x20 [ 472.075308] </TASK> [ 472.075308] ================================================================== [ 472.094860] Disabling lock debugging due to kernel taint [ 472.096136] BUG: kernel NULL pointer dereference, address: 0000000000000158 [ 472.096136] #PF: supervisor write access in kernel mode [ 472.096136] #PF: error_code(0x0002) - not-present page [ 472.096136] PGD 0 P4D 0 [ 472.096136] Oops: 0002 [#1] PREEMPT SMP KASAN NOPTI [ 472.096136] CPU: 0 PID: 7 Comm: kworker/0:0 Tainted: G B 6.9.0-rc5-00356-g78c0094a146b #36 [ 472.096136] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu4 [ 472.096136] Workqueue: events l2cap_chan_timeout [ 472.096136] RIP: 0010:mutex_lock+0x88/0xc0 [ 472.096136] Code: be 08 00 00 00 e8 f8 23 1f fd 4c 89 f7 be 08 00 00 00 e8 eb 23 1f fd 42 80 3c 23 00 74 08 48 88 [ 472.096136] RSP: 0018:ffff88800744fc78 EFLAGS: 00000246 [ 472.096136] RAX: 0000000000000000 RBX: 1ffff11000e89f8f RCX: ffffffff8457c865 [ 472.096136] RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffff88800744fc78 [ 472.096136] RBP: 0000000000000158 R08: ffff88800744fc7f R09: 1ffff11000e89f8f [ 472.096136] R10: dffffc0000000000 R11: ffffed1000e89f90 R12: dffffc0000000000 [ 472.096136] R13: 0000000000000158 R14: ffff88800744fc78 R15: ffff888007405a00 [ 472.096136] FS: 0000000000000000(0000) GS:ffff88806d200000(0000) knlGS:0000000000000000 [ 472.096136] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 472.096136] CR2: 0000000000000158 CR3: 000000000da32000 CR4: 00000000000006f0 [ 472.096136] Call Trace: [ 472.096136] <TASK> [ 472.096136] ? __die_body+0x8d/0xe0 [ 472.096136] ? page_fault_oops+0x6b8/0x9a0 [ 472.096136] ? kernelmode_fixup_or_oops+0x20c/0x2a0 [ 472.096136] ? do_user_addr_fault+0x1027/0x1340 [ 472.096136] ? _printk+0x7a/0xa0 [ 472.096136] ? mutex_lock+0x68/0xc0 [ 472.096136] ? add_taint+0x42/0xd0 [ 472.096136] ? exc_page_fault+0x6a/0x1b0 [ 472.096136] ? asm_exc_page_fault+0x26/0x30 [ 472.096136] ? mutex_lock+0x75/0xc0 [ 472.096136] ? mutex_lock+0x88/0xc0 [ 472.096136] ? mutex_lock+0x75/0xc0 [ 472.096136] l2cap_chan_timeo ---truncated---(CVE-2024-27399)
In the Linux kernel, the following vulnerability has been resolved:
firewire: nosy: ensure user_length is taken into account when fetching packet contents
Ensure that packet_buffer_get respects the user_length provided. If the length of the head packet exceeds the user_length, packet_buffer_get will now return 0 to signify to the user that no data were read and a larger buffer size is required. Helps prevent user space overflows.(CVE-2024-27401)
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: check/clear fast rx for non-4addr sta VLAN changes
When moving a station out of a VLAN and deleting the VLAN afterwards, the fast_rx entry still holds a pointer to the VLAN's netdev, which can cause use-after-free bugs. Fix this by immediately calling ieee80211_check_fast_rx after the VLAN change.(CVE-2024-35789)
In the Linux kernel, the following vulnerability has been resolved:
md/dm-raid: don't call md_reap_sync_thread() directly
Currently md_reap_sync_thread() is called from raid_message() directly without holding 'reconfig_mutex', this is definitely unsafe because md_reap_sync_thread() can change many fields that is protected by 'reconfig_mutex'.
However, hold 'reconfig_mutex' here is still problematic because this will cause deadlock, for example, commit 130443d60b1b ("md: refactor idle/frozen_sync_thread() to fix deadlock").
Fix this problem by using stop_sync_thread() to unregister sync_thread, like md/raid did.(CVE-2024-35808)
In the Linux kernel, the following vulnerability has been resolved:
usb: udc: remove warning when queue disabled ep
It is possible trigger below warning message from mass storage function,
WARNING: CPU: 6 PID: 3839 at drivers/usb/gadget/udc/core.c:294 usb_ep_queue+0x7c/0x104 pc : usb_ep_queue+0x7c/0x104 lr : fsg_main_thread+0x494/0x1b3c
Root cause is mass storage function try to queue request from main thread, but other thread may already disable ep when function disable.
As there is no function failure in the driver, in order to avoid effort to fix warning, change WARN_ON_ONCE() in usb_ep_queue() to pr_debug().(CVE-2024-35822)
In the Linux kernel, the following vulnerability has been resolved:
vt: fix unicode buffer corruption when deleting characters
This is the same issue that was fixed for the VGA text buffer in commit 39cdb68c64d8 ("vt: fix memory overlapping when deleting chars in the buffer"). The cure is also the same i.e. replace memcpy() with memmove() due to the overlaping buffers.(CVE-2024-35823)
In the Linux kernel, the following vulnerability has been resolved:
x86/mm/pat: fix VM_PAT handling in COW mappings
PAT handling won't do the right thing in COW mappings: the first PTE (or, in fact, all PTEs) can be replaced during write faults to point at anon folios. Reliably recovering the correct PFN and cachemode using follow_phys() from PTEs will not work in COW mappings.
Using follow_phys(), we might just get the address+protection of the anon folio (which is very wrong), or fail on swap/nonswap entries, failing follow_phys() and triggering a WARN_ON_ONCE() in untrack_pfn() and track_pfn_copy(), not properly calling free_pfn_range().
In free_pfn_range(), we either wouldn't call memtype_free() or would call it with the wrong range, possibly leaking memory.
To fix that, let's update follow_phys() to refuse returning anon folios, and fallback to using the stored PFN inside vma->vm_pgoff for COW mappings if we run into that.
We will now properly handle untrack_pfn() with COW mappings, where we don't need the cachemode. We'll have to fail fork()->track_pfn_copy() if the first page was replaced by an anon folio, though: we'd have to store the cachemode in the VMA to make this work, likely growing the VMA size.
For now, lets keep it simple and let track_pfn_copy() just fail in that case: it would have failed in the past with swap/nonswap entries already, and it would have done the wrong thing with anon folios.
Simple reproducer to trigger the WARN_ON_ONCE() in untrack_pfn():
<--- C reproducer ---> #include <stdio.h> #include <sys/mman.h> #include <unistd.h> #include <liburing.h>
int main(void) { struct io_uring_params p = {}; int ring_fd; size_t size; char *map;
ring_fd = io_uring_setup(1, &p);
if (ring_fd < 0) {
perror("io_uring_setup");
return 1;
}
size = p.sq_off.array + p.sq_entries * sizeof(unsigned);
/* Map the submission queue ring MAP_PRIVATE */
map = mmap(0, size, PROT_READ | PROT_WRITE, MAP_PRIVATE,
ring_fd, IORING_OFF_SQ_RING);
if (map == MAP_FAILED) {
perror("mmap");
return 1;
}
/* We have at least one page. Let's COW it. */
*map = 0;
pause();
return 0;
} <--- C reproducer --->
On a system with 16 GiB RAM and swap configured: # ./iouring & # memhog 16G # killall iouring [ 301.552930] ------------[ cut here ]------------ [ 301.553285] WARNING: CPU: 7 PID: 1402 at arch/x86/mm/pat/memtype.c:1060 untrack_pfn+0xf4/0x100 [ 301.553989] Modules linked in: binfmt_misc nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_g [ 301.558232] CPU: 7 PID: 1402 Comm: iouring Not tainted 6.7.5-100.fc38.x86_64 #1 [ 301.558772] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebu4 [ 301.559569] RIP: 0010:untrack_pfn+0xf4/0x100 [ 301.559893] Code: 75 c4 eb cf 48 8b 43 10 8b a8 e8 00 00 00 3b 6b 28 74 b8 48 8b 7b 30 e8 ea 1a f7 000 [ 301.561189] RSP: 0018:ffffba2c0377fab8 EFLAGS: 00010282 [ 301.561590] RAX: 00000000ffffffea RBX: ffff9208c8ce9cc0 RCX: 000000010455e047 [ 301.562105] RDX: 07fffffff0eb1e0a RSI: 0000000000000000 RDI: ffff9208c391d200 [ 301.562628] RBP: 0000000000000000 R08: ffffba2c0377fab8 R09: 0000000000000000 [ 301.563145] R10: ffff9208d2292d50 R11: 0000000000000002 R12: 00007fea890e0000 [ 301.563669] R13: 0000000000000000 R14: ffffba2c0377fc08 R15: 0000000000000000 [ 301.564186] FS: 0000000000000000(0000) GS:ffff920c2fbc0000(0000) knlGS:0000000000000000 [ 301.564773] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 301.565197] CR2: 00007fea88ee8a20 CR3: 00000001033a8000 CR4: 0000000000750ef0 [ 301.565725] PKRU: 55555554 [ 301.565944] Call Trace: [ 301.566148] <TASK> [ 301.566325] ? untrack_pfn+0xf4/0x100 [ 301.566618] ? __warn+0x81/0x130 [ 301.566876] ? untrack_pfn+0xf4/0x100 [ 3 ---truncated---(CVE-2024-35877)
In the Linux kernel, the following vulnerability has been resolved:
selinux: avoid dereference of garbage after mount failure
In case kern_mount() fails and returns an error pointer return in the error branch instead of continuing and dereferencing the error pointer.
While on it drop the never read static variable selinuxfs_mount.(CVE-2024-35904)
In the Linux kernel, the following vulnerability has been resolved:
block: prevent division by zero in blk_rq_stat_sum()
The expression dst->nr_samples + src->nr_samples may have zero value on overflow. It is necessary to add a check to avoid division by zero.
Found by Linux Verification Center (linuxtesting.org) with Svace.(CVE-2024-35925)
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: Properly link new fs rules into the tree
Previously, add_rule_fg would only add newly created rules from the handle into the tree when they had a refcount of 1. On the other hand, create_flow_handle tries hard to find and reference already existing identical rules instead of creating new ones.
These two behaviors can result in a situation where create_flow_handle 1) creates a new rule and references it, then 2) in a subsequent step during the same handle creation references it again, resulting in a rule with a refcount of 2 that is not linked into the tree, will have a NULL parent and root and will result in a crash when the flow group is deleted because del_sw_hw_rule, invoked on rule deletion, assumes node->parent is != NULL.
This happened in the wild, due to another bug related to incorrect handling of duplicate pkt_reformat ids, which lead to the code in create_flow_handle incorrectly referencing a just-added rule in the same flow handle, resulting in the problem described above. Full details are at [1].
This patch changes add_rule_fg to add new rules without parents into the tree, properly initializing them and avoiding the crash. This makes it more consistent with how rules are added to an FTE in create_flow_handle.(CVE-2024-35960)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: Fix memory leak in hci_req_sync_complete()
In 'hci_req_sync_complete()', always free the previous sync request state before assigning reference to a new one.(CVE-2024-35978)
In the Linux kernel, the following vulnerability has been resolved:
ACPI: CPPC: Use access_width over bit_width for system memory accesses
To align with ACPI 6.3+, since bit_width can be any 8-bit value, it cannot be depended on to be always on a clean 8b boundary. This was uncovered on the Cobalt 100 platform.
SError Interrupt on CPU26, code 0xbe000011 -- SError CPU: 26 PID: 1510 Comm: systemd-udevd Not tainted 5.15.2.1-13 #1 Hardware name: MICROSOFT CORPORATION, BIOS MICROSOFT CORPORATION pstate: 62400009 (nZCv daif +PAN -UAO +TCO -DIT -SSBS BTYPE=--) pc : cppc_get_perf_caps+0xec/0x410 lr : cppc_get_perf_caps+0xe8/0x410 sp : ffff8000155ab730 x29: ffff8000155ab730 x28: ffff0080139d0038 x27: ffff0080139d0078 x26: 0000000000000000 x25: ffff0080139d0058 x24: 00000000ffffffff x23: ffff0080139d0298 x22: ffff0080139d0278 x21: 0000000000000000 x20: ffff00802b251910 x19: ffff0080139d0000 x18: ffffffffffffffff x17: 0000000000000000 x16: ffffdc7e111bad04 x15: ffff00802b251008 x14: ffffffffffffffff x13: ffff013f1fd63300 x12: 0000000000000006 x11: ffffdc7e128f4420 x10: 0000000000000000 x9 : ffffdc7e111badec x8 : ffff00802b251980 x7 : 0000000000000000 x6 : ffff0080139d0028 x5 : 0000000000000000 x4 : ffff0080139d0018 x3 : 00000000ffffffff x2 : 0000000000000008 x1 : ffff8000155ab7a0 x0 : 0000000000000000 Kernel panic - not syncing: Asynchronous SError Interrupt CPU: 26 PID: 1510 Comm: systemd-udevd Not tainted 5.15.2.1-13 #1 Hardware name: MICROSOFT CORPORATION, BIOS MICROSOFT CORPORATION Call trace: dump_backtrace+0x0/0x1e0 show_stack+0x24/0x30 dump_stack_lvl+0x8c/0xb8 dump_stack+0x18/0x34 panic+0x16c/0x384 add_taint+0x0/0xc0 arm64_serror_panic+0x7c/0x90 arm64_is_fatal_ras_serror+0x34/0xa4 do_serror+0x50/0x6c el1h_64_error_handler+0x40/0x74 el1h_64_error+0x7c/0x80 cppc_get_perf_caps+0xec/0x410 cppc_cpufreq_cpu_init+0x74/0x400 [cppc_cpufreq] cpufreq_online+0x2dc/0xa30 cpufreq_add_dev+0xc0/0xd4 subsys_interface_register+0x134/0x14c cpufreq_register_driver+0x1b0/0x354 cppc_cpufreq_init+0x1a8/0x1000 [cppc_cpufreq] do_one_initcall+0x50/0x250 do_init_module+0x60/0x27c load_module+0x2300/0x2570 __do_sys_finit_module+0xa8/0x114 __arm64_sys_finit_module+0x2c/0x3c invoke_syscall+0x78/0x100 el0_svc_common.constprop.0+0x180/0x1a0 do_el0_svc+0x84/0xa0 el0_svc+0x2c/0xc0 el0t_64_sync_handler+0xa4/0x12c el0t_64_sync+0x1a4/0x1a8
Instead, use access_width to determine the size and use the offset and width to shift and mask the bits to read/write out. Make sure to add a check for system memory since pcc redefines the access_width to subspace id.
If access_width is not set, then fall back to using bit_width.
rjw: Subject and changelog edits, comment adjustments
In the Linux kernel, the following vulnerability has been resolved:
i40e: Do not use WQ_MEM_RECLAIM flag for workqueue
Issue reported by customer during SRIOV testing, call trace: When both i40e and the i40iw driver are loaded, a warning in check_flush_dependency is being triggered. This seems to be because of the i40e driver workqueue is allocated with the WQ_MEM_RECLAIM flag, and the i40iw one is not.
Similar error was encountered on ice too and it was fixed by removing the flag. Do the same for i40e too.
[Feb 9 09:08] ------------[ cut here ]------------ [ +0.000004] workqueue: WQ_MEM_RECLAIM i40e:i40e_service_task [i40e] is flushing !WQ_MEM_RECLAIM infiniband:0x0 [ +0.000060] WARNING: CPU: 0 PID: 937 at kernel/workqueue.c:2966 check_flush_dependency+0x10b/0x120 [ +0.000007] Modules linked in: snd_seq_dummy snd_hrtimer snd_seq snd_timer snd_seq_device snd soundcore nls_utf8 cifs cifs_arc4 nls_ucs2_utils rdma_cm iw_cm ib_cm cifs_md4 dns_resolver netfs qrtr rfkill sunrpc vfat fat intel_rapl_msr intel_rapl_common irdma intel_uncore_frequency intel_uncore_frequency_common ice ipmi_ssif isst_if_common skx_edac nfit libnvdimm x86_pkg_temp_thermal intel_powerclamp gnss coretemp ib_uverbs rapl intel_cstate ib_core iTCO_wdt iTCO_vendor_support acpi_ipmi mei_me ipmi_si intel_uncore ioatdma i2c_i801 joydev pcspkr mei ipmi_devintf lpc_ich intel_pch_thermal i2c_smbus ipmi_msghandler acpi_power_meter acpi_pad xfs libcrc32c ast sd_mod drm_shmem_helper t10_pi drm_kms_helper sg ixgbe drm i40e ahci crct10dif_pclmul libahci crc32_pclmul igb crc32c_intel libata ghash_clmulni_intel i2c_algo_bit mdio dca wmi dm_mirror dm_region_hash dm_log dm_mod fuse [ +0.000050] CPU: 0 PID: 937 Comm: kworker/0:3 Kdump: loaded Not tainted 6.8.0-rc2-Feb-net_dev-Qiueue-00279-gbd43c5687e05 #1 [ +0.000003] Hardware name: Intel Corporation S2600BPB/S2600BPB, BIOS SE5C620.86B.02.01.0013.121520200651 12/15/2020 [ +0.000001] Workqueue: i40e i40e_service_task [i40e] [ +0.000024] RIP: 0010:check_flush_dependency+0x10b/0x120 [ +0.000003] Code: ff 49 8b 54 24 18 48 8d 8b b0 00 00 00 49 89 e8 48 81 c6 b0 00 00 00 48 c7 c7 b0 97 fa 9f c6 05 8a cc 1f 02 01 e8 35 b3 fd ff <0f> 0b e9 10 ff ff ff 80 3d 78 cc 1f 02 00 75 94 e9 46 ff ff ff 90 [ +0.000002] RSP: 0018:ffffbd294976bcf8 EFLAGS: 00010282 [ +0.000002] RAX: 0000000000000000 RBX: ffff94d4c483c000 RCX: 0000000000000027 [ +0.000001] RDX: ffff94d47f620bc8 RSI: 0000000000000001 RDI: ffff94d47f620bc0 [ +0.000001] RBP: 0000000000000000 R08: 0000000000000000 R09: 00000000ffff7fff [ +0.000001] R10: ffffbd294976bb98 R11: ffffffffa0be65e8 R12: ffff94c5451ea180 [ +0.000001] R13: ffff94c5ab5e8000 R14: ffff94c5c20b6e05 R15: ffff94c5f1330ab0 [ +0.000001] FS: 0000000000000000(0000) GS:ffff94d47f600000(0000) knlGS:0000000000000000 [ +0.000002] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ +0.000001] CR2: 00007f9e6f1fca70 CR3: 0000000038e20004 CR4: 00000000007706f0 [ +0.000000] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ +0.000001] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ +0.000001] PKRU: 55555554 [ +0.000001] Call Trace: [ +0.000001] <TASK> [ +0.000002] ? __warn+0x80/0x130 [ +0.000003] ? check_flush_dependency+0x10b/0x120 [ +0.000002] ? report_bug+0x195/0x1a0 [ +0.000005] ? handle_bug+0x3c/0x70 [ +0.000003] ? exc_invalid_op+0x14/0x70 [ +0.000002] ? asm_exc_invalid_op+0x16/0x20 [ +0.000006] ? check_flush_dependency+0x10b/0x120 [ +0.000002] ? check_flush_dependency+0x10b/0x120 [ +0.000002] __flush_workqueue+0x126/0x3f0 [ +0.000015] ib_cache_cleanup_one+0x1c/0xe0 [ib_core] [ +0.000056] __ib_unregister_device+0x6a/0xb0 [ib_core] [ +0.000023] ib_unregister_device_and_put+0x34/0x50 [ib_core] [ +0.000020] i40iw_close+0x4b/0x90 [irdma] [ +0.000022] i40e_notify_client_of_netdev_close+0x54/0xc0 [i40e] [ +0.000035] i40e_service_task+0x126/0x190 [i40e] [ +0.000024] process_one_work+0x174/0x340 [ +0.000003] worker_th ---truncated---(CVE-2024-36004)
In the Linux kernel, the following vulnerability has been resolved:
ppdev: Add an error check in register_device
In register_device, the return value of ida_simple_get is unchecked, in witch ida_simple_get will use an invalid index value.
To address this issue, index should be checked after ida_simple_get. When the index value is abnormal, a warning message should be printed, the port should be dropped, and the value should be recorded.(CVE-2024-36015)
In the Linux kernel, the following vulnerability has been resolved:
pinctrl: core: delete incorrect free in pinctrl_enable()
The "pctldev" struct is allocated in devm_pinctrl_register_and_init(). It's a devm_ managed pointer that is freed by devm_pinctrl_dev_release(), so freeing it in pinctrl_enable() will lead to a double free.
The devm_pinctrl_dev_release() function frees the pindescs and destroys the mutex as well.(CVE-2024-36940)
| URL | Type | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"python2-perf-4.19.90-2406.1.0.0279.oe2003sp4.aarch64.rpm",
"kernel-tools-debuginfo-4.19.90-2406.1.0.0279.oe2003sp4.aarch64.rpm",
"python2-perf-debuginfo-4.19.90-2406.1.0.0279.oe2003sp4.aarch64.rpm",
"kernel-tools-4.19.90-2406.1.0.0279.oe2003sp4.aarch64.rpm",
"kernel-devel-4.19.90-2406.1.0.0279.oe2003sp4.aarch64.rpm",
"bpftool-4.19.90-2406.1.0.0279.oe2003sp4.aarch64.rpm",
"kernel-source-4.19.90-2406.1.0.0279.oe2003sp4.aarch64.rpm",
"python3-perf-4.19.90-2406.1.0.0279.oe2003sp4.aarch64.rpm",
"kernel-debugsource-4.19.90-2406.1.0.0279.oe2003sp4.aarch64.rpm",
"bpftool-debuginfo-4.19.90-2406.1.0.0279.oe2003sp4.aarch64.rpm",
"kernel-tools-devel-4.19.90-2406.1.0.0279.oe2003sp4.aarch64.rpm",
"perf-debuginfo-4.19.90-2406.1.0.0279.oe2003sp4.aarch64.rpm",
"kernel-4.19.90-2406.1.0.0279.oe2003sp4.aarch64.rpm",
"perf-4.19.90-2406.1.0.0279.oe2003sp4.aarch64.rpm",
"kernel-debuginfo-4.19.90-2406.1.0.0279.oe2003sp4.aarch64.rpm",
"python3-perf-debuginfo-4.19.90-2406.1.0.0279.oe2003sp4.aarch64.rpm"
],
"src": [
"kernel-4.19.90-2406.1.0.0279.oe2003sp4.src.rpm"
],
"x86_64": [
"python2-perf-4.19.90-2406.1.0.0279.oe2003sp4.x86_64.rpm",
"python2-perf-debuginfo-4.19.90-2406.1.0.0279.oe2003sp4.x86_64.rpm",
"kernel-4.19.90-2406.1.0.0279.oe2003sp4.x86_64.rpm",
"perf-debuginfo-4.19.90-2406.1.0.0279.oe2003sp4.x86_64.rpm",
"kernel-tools-debuginfo-4.19.90-2406.1.0.0279.oe2003sp4.x86_64.rpm",
"bpftool-debuginfo-4.19.90-2406.1.0.0279.oe2003sp4.x86_64.rpm",
"kernel-tools-4.19.90-2406.1.0.0279.oe2003sp4.x86_64.rpm",
"kernel-devel-4.19.90-2406.1.0.0279.oe2003sp4.x86_64.rpm",
"python3-perf-debuginfo-4.19.90-2406.1.0.0279.oe2003sp4.x86_64.rpm",
"bpftool-4.19.90-2406.1.0.0279.oe2003sp4.x86_64.rpm",
"python3-perf-4.19.90-2406.1.0.0279.oe2003sp4.x86_64.rpm",
"kernel-tools-devel-4.19.90-2406.1.0.0279.oe2003sp4.x86_64.rpm",
"perf-4.19.90-2406.1.0.0279.oe2003sp4.x86_64.rpm",
"kernel-source-4.19.90-2406.1.0.0279.oe2003sp4.x86_64.rpm",
"kernel-debugsource-4.19.90-2406.1.0.0279.oe2003sp4.x86_64.rpm",
"kernel-debuginfo-4.19.90-2406.1.0.0279.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.1.0.0279.oe2003sp4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: usb: fix possible use-after-free in smsc75xx_bind\r\n\r\nThe commit 46a8b29c6306 (\u0026quot;net: usb: fix memory leak in smsc75xx_bind\u0026quot;)\nfails to clean up the work scheduled in smsc75xx_reset-\u0026gt;\nsmsc75xx_set_multicast, which leads to use-after-free if the work is\nscheduled to start after the deallocation. In addition, this patch\nalso removes a dangling pointer - dev-\u0026gt;data[0].\r\n\r\nThis patch calls cancel_work_sync to cancel the scheduled work and set\nthe dangling pointer to NULL.(CVE-2021-47239)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nRDMA: Verify port when creating flow rule\r\n\r\nValidate port value provided by the user and with that remove no longer\nneeded validation by the driver. The missing check in the mlx5_ib driver\ncould cause to the below oops.\r\n\r\nCall trace:\n _create_flow_rule+0x2d4/0xf28 [mlx5_ib]\n mlx5_ib_create_flow+0x2d0/0x5b0 [mlx5_ib]\n ib_uverbs_ex_create_flow+0x4cc/0x624 [ib_uverbs]\n ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0xd4/0x150 [ib_uverbs]\n ib_uverbs_cmd_verbs.isra.7+0xb28/0xc50 [ib_uverbs]\n ib_uverbs_ioctl+0x158/0x1d0 [ib_uverbs]\n do_vfs_ioctl+0xd0/0xaf0\n ksys_ioctl+0x84/0xb4\n __arm64_sys_ioctl+0x28/0xc4\n el0_svc_common.constprop.3+0xa4/0x254\n el0_svc_handler+0x84/0xa0\n el0_svc+0x10/0x26c\n Code: b9401260 f9615681 51000400 8b001c20 (f9403c1a)(CVE-2021-47265)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbcache: avoid oversized read request in cache missing code path\r\n\r\nIn the cache missing code path of cached device, if a proper location\nfrom the internal B+ tree is matched for a cache miss range, function\ncached_dev_cache_miss() will be called in cache_lookup_fn() in the\nfollowing code block,\n[code block 1]\n 526 unsigned int sectors = KEY_INODE(k) == s-\u0026gt;iop.inode\n 527 ? min_t(uint64_t, INT_MAX,\n 528 KEY_START(k) - bio-\u0026gt;bi_iter.bi_sector)\n 529 : INT_MAX;\n 530 int ret = s-\u0026gt;d-\u0026gt;cache_miss(b, s, bio, sectors);\r\n\r\nHere s-\u0026gt;d-\u0026gt;cache_miss() is the call backfunction pointer initialized as\ncached_dev_cache_miss(), the last parameter \u0026apos;sectors\u0026apos; is an important\nhint to calculate the size of read request to backing device of the\nmissing cache data.\r\n\r\nCurrent calculation in above code block may generate oversized value of\n\u0026apos;sectors\u0026apos;, which consequently may trigger 2 different potential kernel\npanics by BUG() or BUG_ON() as listed below,\r\n\r\n1) BUG_ON() inside bch_btree_insert_key(),\n[code block 2]\n 886 BUG_ON(b-\u0026gt;ops-\u0026gt;is_extents \u0026amp;\u0026amp; !KEY_SIZE(k));\n2) BUG() inside biovec_slab(),\n[code block 3]\n 51 default:\n 52 BUG();\n 53 return NULL;\r\n\r\nAll the above panics are original from cached_dev_cache_miss() by the\noversized parameter \u0026apos;sectors\u0026apos;.\r\n\r\nInside cached_dev_cache_miss(), parameter \u0026apos;sectors\u0026apos; is used to calculate\nthe size of data read from backing device for the cache missing. This\nsize is stored in s-\u0026gt;insert_bio_sectors by the following lines of code,\n[code block 4]\n 909 s-\u0026gt;insert_bio_sectors = min(sectors, bio_sectors(bio) + reada);\r\n\r\nThen the actual key inserting to the internal B+ tree is generated and\nstored in s-\u0026gt;iop.replace_key by the following lines of code,\n[code block 5]\n 911 s-\u0026gt;iop.replace_key = KEY(s-\u0026gt;iop.inode,\n 912 bio-\u0026gt;bi_iter.bi_sector + s-\u0026gt;insert_bio_sectors,\n 913 s-\u0026gt;insert_bio_sectors);\nThe oversized parameter \u0026apos;sectors\u0026apos; may trigger panic 1) by BUG_ON() from\nthe above code block.\r\n\r\nAnd the bio sending to backing device for the missing data is allocated\nwith hint from s-\u0026gt;insert_bio_sectors by the following lines of code,\n[code block 6]\n 926 cache_bio = bio_alloc_bioset(GFP_NOWAIT,\n 927 DIV_ROUND_UP(s-\u0026gt;insert_bio_sectors, PAGE_SECTORS),\n 928 \u0026amp;dc-\u0026gt;disk.bio_split);\nThe oversized parameter \u0026apos;sectors\u0026apos; may trigger panic 2) by BUG() from the\nagove code block.\r\n\r\nNow let me explain how the panics happen with the oversized \u0026apos;sectors\u0026apos;.\nIn code block 5, replace_key is generated by macro KEY(). From the\ndefinition of macro KEY(),\n[code block 7]\n 71 #define KEY(inode, offset, size) \\\n 72 ((struct bkey) { \\\n 73 .high = (1ULL \u0026lt;\u0026lt; 63) | ((__u64) (size) \u0026lt;\u0026lt; 20) | (inode), \\\n 74 .low = (offset) \\\n 75 })\r\n\r\nHere \u0026apos;size\u0026apos; is 16bits width embedded in 64bits member \u0026apos;high\u0026apos; of struct\nbkey. But in code block 1, if \u0026quot;KEY_START(k) - bio-\u0026gt;bi_iter.bi_sector\u0026quot; is\nvery probably to be larger than (1\u0026lt;\u0026lt;16) - 1, which makes the bkey size\ncalculation in code block 5 is overflowed. In one bug report the value\nof parameter \u0026apos;sectors\u0026apos; is 131072 (= 1 \u0026lt;\u0026lt; 17), the overflowed \u0026apos;sectors\u0026apos;\nresults the overflowed s-\u0026gt;insert_bio_sectors in code block 4, then makes\nsize field of s-\u0026gt;iop.replace_key to be 0 in code block 5. Then the 0-\nsized s-\u0026gt;iop.replace_key is inserted into the internal B+ tree as cache\nmissing check key (a special key to detect and avoid a racing between\nnormal write request and cache missing read request) as,\n[code block 8]\n 915 ret = bch_btree_insert_check_key(b, \u0026amp;s-\u0026gt;op, \u0026amp;s-\u0026gt;iop.replace_key);\r\n\r\nThen the 0-sized s-\u0026gt;iop.replace_key as 3rd parameter triggers the bkey\nsize check BUG_ON() in code block 2, and causes the kernel panic 1).\r\n\r\nAnother ke\n---truncated---(CVE-2021-47275)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nkvm: avoid speculation-based attacks from out-of-range memslot accesses\r\n\r\nKVM\u0026apos;s mechanism for accessing guest memory translates a guest physical\naddress (gpa) to a host virtual address using the right-shifted gpa\n(also known as gfn) and a struct kvm_memory_slot. The translation is\nperformed in __gfn_to_hva_memslot using the following formula:\r\n\r\n hva = slot-\u0026gt;userspace_addr + (gfn - slot-\u0026gt;base_gfn) * PAGE_SIZE\r\n\r\nIt is expected that gfn falls within the boundaries of the guest\u0026apos;s\nphysical memory. However, a guest can access invalid physical addresses\nin such a way that the gfn is invalid.\r\n\r\n__gfn_to_hva_memslot is called from kvm_vcpu_gfn_to_hva_prot, which first\nretrieves a memslot through __gfn_to_memslot. While __gfn_to_memslot\ndoes check that the gfn falls within the boundaries of the guest\u0026apos;s\nphysical memory or not, a CPU can speculate the result of the check and\ncontinue execution speculatively using an illegal gfn. The speculation\ncan result in calculating an out-of-bounds hva. If the resulting host\nvirtual address is used to load another guest physical address, this\nis effectively a Spectre gadget consisting of two consecutive reads,\nthe second of which is data dependent on the first.\r\n\r\nRight now it\u0026apos;s not clear if there are any cases in which this is\nexploitable. One interesting case was reported by the original author\nof this patch, and involves visiting guest page tables on x86. Right\nnow these are not vulnerable because the hva read goes through get_user(),\nwhich contains an LFENCE speculation barrier. However, there are\npatches in progress for x86 uaccess.h to mask kernel addresses instead of\nusing LFENCE; once these land, a guest could use speculation to read\nfrom the VMM\u0026apos;s ring 3 address space. Other architectures such as ARM\nalready use the address masking method, and would be susceptible to\nthis same kind of data-dependent access gadgets. Therefore, this patch\nproactively protects from these attacks by masking out-of-bounds gfns\nin __gfn_to_hva_memslot, which blocks speculation of invalid hvas.\r\n\r\nSean Christopherson noted that this patch does not cover\nkvm_read_guest_offset_cached. This however is limited to a few bytes\npast the end of the cache, and therefore it is unlikely to be useful in\nthe context of building a chain of data dependent accesses.(CVE-2021-47277)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: fix uninit-value in caif_seqpkt_sendmsg\r\n\r\nWhen nr_segs equal to zero in iovec_from_user, the object\nmsg-\u0026gt;msg_iter.iov is uninit stack memory in caif_seqpkt_sendmsg\nwhich is defined in ___sys_sendmsg. So we cann\u0026apos;t just judge\nmsg-\u0026gt;msg_iter.iov-\u0026gt;base directlly. We can use nr_segs to judge\nmsg in caif_seqpkt_sendmsg whether has data buffers.\r\n\r\n=====================================================\nBUG: KMSAN: uninit-value in caif_seqpkt_sendmsg+0x693/0xf60 net/caif/caif_socket.c:542\nCall Trace:\n __dump_stack lib/dump_stack.c:77 [inline]\n dump_stack+0x1c9/0x220 lib/dump_stack.c:118\n kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:118\n __msan_warning+0x58/0xa0 mm/kmsan/kmsan_instr.c:215\n caif_seqpkt_sendmsg+0x693/0xf60 net/caif/caif_socket.c:542\n sock_sendmsg_nosec net/socket.c:652 [inline]\n sock_sendmsg net/socket.c:672 [inline]\n ____sys_sendmsg+0x12b6/0x1350 net/socket.c:2343\n ___sys_sendmsg net/socket.c:2397 [inline]\n __sys_sendmmsg+0x808/0xc90 net/socket.c:2480\n __compat_sys_sendmmsg net/compat.c:656 [inline](CVE-2021-47297)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmemory: fsl_ifc: fix leak of private memory on probe failure\r\n\r\nOn probe error the driver should free the memory allocated for private\nstructure. Fix this by using resource-managed allocation.(CVE-2021-47314)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwatchdog: sc520_wdt: Fix possible use-after-free in wdt_turnoff()\r\n\r\nThis module\u0026apos;s remove path calls del_timer(). However, that function\ndoes not wait until the timer handler finishes. This means that the\ntimer handler may still be running after the driver\u0026apos;s remove function\nhas finished, which would result in a use-after-free.\r\n\r\nFix by calling del_timer_sync(), which makes sure the timer handler\nhas finished, and unable to re-schedule itself.(CVE-2021-47323)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntty: serial: 8250: serial_cs: Fix a memory leak in error handling path\r\n\r\nIn the probe function, if the final \u0026apos;serial_config()\u0026apos; fails, \u0026apos;info\u0026apos; is\nleaking.\r\n\r\nAdd a resource handling path to free this memory.(CVE-2021-47330)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npowerpc/mm: Fix lockup on kernel exec fault\r\n\r\nThe powerpc kernel is not prepared to handle exec faults from kernel.\nEspecially, the function is_exec_fault() will return \u0026apos;false\u0026apos; when an\nexec fault is taken by kernel, because the check is based on reading\ncurrent-\u0026gt;thread.regs-\u0026gt;trap which contains the trap from user.\r\n\r\nFor instance, when provoking a LKDTM EXEC_USERSPACE test,\ncurrent-\u0026gt;thread.regs-\u0026gt;trap is set to SYSCALL trap (0xc00), and\nthe fault taken by the kernel is not seen as an exec fault by\nset_access_flags_filter().\r\n\r\nCommit d7df2443cd5f (\u0026quot;powerpc/mm: Fix spurious segfaults on radix\nwith autonuma\u0026quot;) made it clear and handled it properly. But later on\ncommit d3ca587404b3 (\u0026quot;powerpc/mm: Fix reporting of kernel execute\nfaults\u0026quot;) removed that handling, introducing test based on error_code.\nAnd here is the problem, because on the 603 all upper bits of SRR1\nget cleared when the TLB instruction miss handler bails out to ISI.\r\n\r\nUntil commit cbd7e6ca0210 (\u0026quot;powerpc/fault: Avoid heavy\nsearch_exception_tables() verification\u0026quot;), an exec fault from kernel\nat a userspace address was indirectly caught by the lack of entry for\nthat address in the exception tables. But after that commit the\nkernel mainly relies on KUAP or on core mm handling to catch wrong\nuser accesses. Here the access is not wrong, so mm handles it.\nIt is a minor fault because PAGE_EXEC is not set,\nset_access_flags_filter() should set PAGE_EXEC and voila.\nBut as is_exec_fault() returns false as explained in the beginning,\nset_access_flags_filter() bails out without setting PAGE_EXEC flag,\nwhich leads to a forever minor exec fault.\r\n\r\nAs the kernel is not prepared to handle such exec faults, the thing to\ndo is to fire in bad_kernel_fault() for any exec fault taken by the\nkernel, as it was prior to commit d3ca587404b3.(CVE-2021-47350)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nudf: Fix NULL pointer dereference in udf_symlink function\r\n\r\nIn function udf_symlink, epos.bh is assigned with the value returned\nby udf_tgetblk. The function udf_tgetblk is defined in udf/misc.c\nand returns the value of sb_getblk function that could be NULL.\nThen, epos.bh is used without any check, causing a possible\nNULL pointer dereference when sb_getblk fails.\r\n\r\nThis fix adds a check to validate the value of epos.bh.(CVE-2021-47353)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\natm: nicstar: Fix possible use-after-free in nicstar_cleanup()\r\n\r\nThis module\u0026apos;s remove path calls del_timer(). However, that function\ndoes not wait until the timer handler finishes. This means that the\ntimer handler may still be running after the driver\u0026apos;s remove function\nhas finished, which would result in a use-after-free.\r\n\r\nFix by calling del_timer_sync(), which makes sure the timer handler\nhas finished, and unable to re-schedule itself.(CVE-2021-47355)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmISDN: fix possible use-after-free in HFC_cleanup()\r\n\r\nThis module\u0026apos;s remove path calls del_timer(). However, that function\ndoes not wait until the timer handler finishes. This means that the\ntimer handler may still be running after the driver\u0026apos;s remove function\nhas finished, which would result in a use-after-free.\r\n\r\nFix by calling del_timer_sync(), which makes sure the timer handler\nhas finished, and unable to re-schedule itself.(CVE-2021-47356)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\natm: iphase: fix possible use-after-free in ia_module_exit()\r\n\r\nThis module\u0026apos;s remove path calls del_timer(). However, that function\ndoes not wait until the timer handler finishes. This means that the\ntimer handler may still be running after the driver\u0026apos;s remove function\nhas finished, which would result in a use-after-free.\r\n\r\nFix by calling del_timer_sync(), which makes sure the timer handler\nhas finished, and unable to re-schedule itself.(CVE-2021-47357)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmcb: fix error handling in mcb_alloc_bus()\r\n\r\nThere are two bugs:\n1) If ida_simple_get() fails then this code calls put_device(carrier)\n but we haven\u0026apos;t yet called get_device(carrier) and probably that\n leads to a use after free.\n2) After device_initialize() then we need to use put_device() to\n release the bus. This will free the internal resources tied to the\n device and call mcb_free_bus() which will free the rest.(CVE-2021-47361)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/pm: Update intermediate power state for SI\r\n\r\nUpdate the current state as boot state during dpm initialization.\nDuring the subsequent initialization, set_power_state gets called to\ntransition to the final power state. set_power_state refers to values\nfrom the current state and without current state populated, it could\nresult in NULL pointer dereference.\r\n\r\nFor ex: on platforms where PCI speed change is supported through ACPI\nATCS method, the link speed of current state needs to be queried before\ndeciding on changing to final power state\u0026apos;s link speed. The logic to query\nATCS-support was broken on certain platforms. The issue became visible\nwhen broken ATCS-support logic got fixed with commit\nf9b7f3703ff9 (\u0026quot;drm/amdgpu/acpi: make ATPX/ATCS structures global (v2)\u0026quot;).\r\n\r\nBug: https://gitlab.freedesktop.org/drm/amd/-/issues/1698(CVE-2021-47362)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmac80211: fix use-after-free in CCMP/GCMP RX\r\n\r\nWhen PN checking is done in mac80211, for fragmentation we need\nto copy the PN to the RX struct so we can later use it to do a\ncomparison, since commit bf30ca922a0c (\u0026quot;mac80211: check defrag\nPN against current frame\u0026quot;).\r\n\r\nUnfortunately, in that commit I used the \u0026apos;hdr\u0026apos; variable without\nit being necessarily valid, so use-after-free could occur if it\nwas necessary to reallocate (parts of) the frame.\r\n\r\nFix this by reloading the variable after the code that results\nin the reallocations, if any.\r\n\r\nThis fixes https://bugzilla.kernel.org/show_bug.cgi?id=214401.(CVE-2021-47388)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmac80211: limit injected vht mcs/nss in ieee80211_parse_tx_radiotap\r\n\r\nLimit max values for vht mcs and nss in ieee80211_parse_tx_radiotap\nroutine in order to fix the following warning reported by syzbot:\r\n\r\nWARNING: CPU: 0 PID: 10717 at include/net/mac80211.h:989 ieee80211_rate_set_vht include/net/mac80211.h:989 [inline]\nWARNING: CPU: 0 PID: 10717 at include/net/mac80211.h:989 ieee80211_parse_tx_radiotap+0x101e/0x12d0 net/mac80211/tx.c:2244\nModules linked in:\nCPU: 0 PID: 10717 Comm: syz-executor.5 Not tainted 5.14.0-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011\nRIP: 0010:ieee80211_rate_set_vht include/net/mac80211.h:989 [inline]\nRIP: 0010:ieee80211_parse_tx_radiotap+0x101e/0x12d0 net/mac80211/tx.c:2244\nRSP: 0018:ffffc9000186f3e8 EFLAGS: 00010216\nRAX: 0000000000000618 RBX: ffff88804ef76500 RCX: ffffc900143a5000\nRDX: 0000000000040000 RSI: ffffffff888f478e RDI: 0000000000000003\nRBP: 00000000ffffffff R08: 0000000000000000 R09: 0000000000000100\nR10: ffffffff888f46f9 R11: 0000000000000000 R12: 00000000fffffff8\nR13: ffff88804ef7653c R14: 0000000000000001 R15: 0000000000000004\nFS: 00007fbf5718f700(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000001b2de23000 CR3: 000000006a671000 CR4: 00000000001506f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600\nCall Trace:\n ieee80211_monitor_select_queue+0xa6/0x250 net/mac80211/iface.c:740\n netdev_core_pick_tx+0x169/0x2e0 net/core/dev.c:4089\n __dev_queue_xmit+0x6f9/0x3710 net/core/dev.c:4165\n __bpf_tx_skb net/core/filter.c:2114 [inline]\n __bpf_redirect_no_mac net/core/filter.c:2139 [inline]\n __bpf_redirect+0x5ba/0xd20 net/core/filter.c:2162\n ____bpf_clone_redirect net/core/filter.c:2429 [inline]\n bpf_clone_redirect+0x2ae/0x420 net/core/filter.c:2401\n bpf_prog_eeb6f53a69e5c6a2+0x59/0x234\n bpf_dispatcher_nop_func include/linux/bpf.h:717 [inline]\n __bpf_prog_run include/linux/filter.h:624 [inline]\n bpf_prog_run include/linux/filter.h:631 [inline]\n bpf_test_run+0x381/0xa30 net/bpf/test_run.c:119\n bpf_prog_test_run_skb+0xb84/0x1ee0 net/bpf/test_run.c:663\n bpf_prog_test_run kernel/bpf/syscall.c:3307 [inline]\n __sys_bpf+0x2137/0x5df0 kernel/bpf/syscall.c:4605\n __do_sys_bpf kernel/bpf/syscall.c:4691 [inline]\n __se_sys_bpf kernel/bpf/syscall.c:4689 [inline]\n __x64_sys_bpf+0x75/0xb0 kernel/bpf/syscall.c:4689\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x44/0xae\nRIP: 0033:0x4665f9(CVE-2021-47395)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsctp: break out if skb_header_pointer returns NULL in sctp_rcv_ootb\r\n\r\nWe should always check if skb_header_pointer\u0026apos;s return is NULL before\nusing it, otherwise it may cause null-ptr-deref, as syzbot reported:\r\n\r\n KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]\n RIP: 0010:sctp_rcv_ootb net/sctp/input.c:705 [inline]\n RIP: 0010:sctp_rcv+0x1d84/0x3220 net/sctp/input.c:196\n Call Trace:\n \u0026lt;IRQ\u0026gt;\n sctp6_rcv+0x38/0x60 net/sctp/ipv6.c:1109\n ip6_protocol_deliver_rcu+0x2e9/0x1ca0 net/ipv6/ip6_input.c:422\n ip6_input_finish+0x62/0x170 net/ipv6/ip6_input.c:463\n NF_HOOK include/linux/netfilter.h:307 [inline]\n NF_HOOK include/linux/netfilter.h:301 [inline]\n ip6_input+0x9c/0xd0 net/ipv6/ip6_input.c:472\n dst_input include/net/dst.h:460 [inline]\n ip6_rcv_finish net/ipv6/ip6_input.c:76 [inline]\n NF_HOOK include/linux/netfilter.h:307 [inline]\n NF_HOOK include/linux/netfilter.h:301 [inline]\n ipv6_rcv+0x28c/0x3c0 net/ipv6/ip6_input.c:297(CVE-2021-47397)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nipack: ipoctal: fix stack information leak\r\n\r\nThe tty driver name is used also after registering the driver and must\nspecifically not be allocated on the stack to avoid leaking information\nto user space (or triggering an oops).\r\n\r\nDrivers should not try to encode topology information in the tty device\nname but this one snuck in through staging without anyone noticing and\nanother driver has since copied this malpractice.\r\n\r\nFixing the ABI is a separate issue, but this at least plugs the security\nhole.(CVE-2021-47401)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nHID: betop: fix slab-out-of-bounds Write in betop_probe\r\n\r\nSyzbot reported slab-out-of-bounds Write bug in hid-betopff driver.\nThe problem is the driver assumes the device must have an input report but\nsome malicious devices violate this assumption.\r\n\r\nSo this patch checks hid_device\u0026apos;s input is non empty before it\u0026apos;s been used.(CVE-2021-47404)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nHID: usbhid: free raw_report buffers in usbhid_stop\r\n\r\nFree the unsent raw_report buffers when the device is removed.\r\n\r\nFixes a memory leak reported by syzbot at:\nhttps://syzkaller.appspot.com/bug?id=7b4fa7cb1a7c2d3342a2a8a6c53371c8c418ab47(CVE-2021-47405)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: conntrack: serialize hash resizes and cleanups\r\n\r\nSyzbot was able to trigger the following warning [1]\r\n\r\nNo repro found by syzbot yet but I was able to trigger similar issue\nby having 2 scripts running in parallel, changing conntrack hash sizes,\nand:\r\n\r\nfor j in `seq 1 1000` ; do unshare -n /bin/true \u0026gt;/dev/null ; done\r\n\r\nIt would take more than 5 minutes for net_namespace structures\nto be cleaned up.\r\n\r\nThis is because nf_ct_iterate_cleanup() has to restart everytime\na resize happened.\r\n\r\nBy adding a mutex, we can serialize hash resizes and cleanups\nand also make get_next_corpse() faster by skipping over empty\nbuckets.\r\n\r\nEven without resizes in the picture, this patch considerably\nspeeds up network namespace dismantles.\r\n\r\n[1]\nINFO: task syz-executor.0:8312 can\u0026apos;t die for more than 144 seconds.\ntask:syz-executor.0 state:R running task stack:25672 pid: 8312 ppid: 6573 flags:0x00004006\nCall Trace:\n context_switch kernel/sched/core.c:4955 [inline]\n __schedule+0x940/0x26f0 kernel/sched/core.c:6236\n preempt_schedule_common+0x45/0xc0 kernel/sched/core.c:6408\n preempt_schedule_thunk+0x16/0x18 arch/x86/entry/thunk_64.S:35\n __local_bh_enable_ip+0x109/0x120 kernel/softirq.c:390\n local_bh_enable include/linux/bottom_half.h:32 [inline]\n get_next_corpse net/netfilter/nf_conntrack_core.c:2252 [inline]\n nf_ct_iterate_cleanup+0x15a/0x450 net/netfilter/nf_conntrack_core.c:2275\n nf_conntrack_cleanup_net_list+0x14c/0x4f0 net/netfilter/nf_conntrack_core.c:2469\n ops_exit_list+0x10d/0x160 net/core/net_namespace.c:171\n setup_net+0x639/0xa30 net/core/net_namespace.c:349\n copy_net_ns+0x319/0x760 net/core/net_namespace.c:470\n create_new_namespaces+0x3f6/0xb20 kernel/nsproxy.c:110\n unshare_nsproxy_namespaces+0xc1/0x1f0 kernel/nsproxy.c:226\n ksys_unshare+0x445/0x920 kernel/fork.c:3128\n __do_sys_unshare kernel/fork.c:3202 [inline]\n __se_sys_unshare kernel/fork.c:3200 [inline]\n __x64_sys_unshare+0x2d/0x40 kernel/fork.c:3200\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x44/0xae\nRIP: 0033:0x7f63da68e739\nRSP: 002b:00007f63d7c05188 EFLAGS: 00000246 ORIG_RAX: 0000000000000110\nRAX: ffffffffffffffda RBX: 00007f63da792f80 RCX: 00007f63da68e739\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000040000000\nRBP: 00007f63da6e8cc4 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000246 R12: 00007f63da792f80\nR13: 00007fff50b75d3f R14: 00007f63d7c05300 R15: 0000000000022000\r\n\r\nShowing all locks held in the system:\n1 lock held by khungtaskd/27:\n #0: ffffffff8b980020 (rcu_read_lock){....}-{1:2}, at: debug_show_all_locks+0x53/0x260 kernel/locking/lockdep.c:6446\n2 locks held by kworker/u4:2/153:\n #0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: arch_atomic64_set arch/x86/include/asm/atomic64_64.h:34 [inline]\n #0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: arch_atomic_long_set include/linux/atomic/atomic-long.h:41 [inline]\n #0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: atomic_long_set include/linux/atomic/atomic-instrumented.h:1198 [inline]\n #0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: set_work_data kernel/workqueue.c:634 [inline]\n #0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: set_work_pool_and_clear_pending kernel/workqueue.c:661 [inline]\n #0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: process_one_work+0x896/0x1690 kernel/workqueue.c:2268\n #1: ffffc9000140fdb0 ((kfence_timer).work){+.+.}-{0:0}, at: process_one_work+0x8ca/0x1690 kernel/workqueue.c:2272\n1 lock held by systemd-udevd/2970:\n1 lock held by in:imklog/6258:\n #0: ffff88807f970ff0 (\u0026amp;f-\u0026gt;f_pos_lock){+.+.}-{3:3}, at: __fdget_pos+0xe9/0x100 fs/file.c:990\n3 locks held by kworker/1:6/8158:\n1 lock held by syz-executor.0/8312:\n2 locks held by kworker/u4:13/9320:\n1 lock held by\n---truncated---(CVE-2021-47408)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/nouveau/debugfs: fix file release memory leak\r\n\r\nWhen using single_open() for opening, single_release() should be\ncalled, otherwise the \u0026apos;op\u0026apos; allocated in single_open() will be leaked.(CVE-2021-47423)\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\nnet/mlx5e: Fix memory leak in mlx5_core_destroy_cq() error path\r\n\r\nPrior to this patch in case mlx5_core_destroy_cq() failed it returns\nwithout completing all destroy operations and that leads to memory leak.\nInstead, complete the destroy flow before return error.\r\n\r\nAlso move mlx5_debug_cq_remove() to the beginning of mlx5_core_destroy_cq()\nto be symmetrical with mlx5_core_create_cq().\r\n\r\nkmemleak complains on:\r\n\r\nunreferenced object 0xc000000038625100 (size 64):\n comm \u0026quot;ethtool\u0026quot;, pid 28301, jiffies 4298062946 (age 785.380s)\n hex dump (first 32 bytes):\n 60 01 48 94 00 00 00 c0 b8 05 34 c3 00 00 00 c0 `.H.......4.....\n 02 00 00 00 00 00 00 00 00 db 7d c1 00 00 00 c0 ..........}.....\n backtrace:\n [\u0026lt;000000009e8643cb\u0026gt;] add_res_tree+0xd0/0x270 [mlx5_core]\n [\u0026lt;00000000e7cb8e6c\u0026gt;] mlx5_debug_cq_add+0x5c/0xc0 [mlx5_core]\n [\u0026lt;000000002a12918f\u0026gt;] mlx5_core_create_cq+0x1d0/0x2d0 [mlx5_core]\n [\u0026lt;00000000cef0a696\u0026gt;] mlx5e_create_cq+0x210/0x3f0 [mlx5_core]\n [\u0026lt;000000009c642c26\u0026gt;] mlx5e_open_cq+0xb4/0x130 [mlx5_core]\n [\u0026lt;0000000058dfa578\u0026gt;] mlx5e_ptp_open+0x7f4/0xe10 [mlx5_core]\n [\u0026lt;0000000081839561\u0026gt;] mlx5e_open_channels+0x9cc/0x13e0 [mlx5_core]\n [\u0026lt;0000000009cf05d4\u0026gt;] mlx5e_switch_priv_channels+0xa4/0x230\n[mlx5_core]\n [\u0026lt;0000000042bbedd8\u0026gt;] mlx5e_safe_switch_params+0x14c/0x300\n[mlx5_core]\n [\u0026lt;0000000004bc9db8\u0026gt;] set_pflag_tx_port_ts+0x9c/0x160 [mlx5_core]\n [\u0026lt;00000000a0553443\u0026gt;] mlx5e_set_priv_flags+0xd0/0x1b0 [mlx5_core]\n [\u0026lt;00000000a8f3d84b\u0026gt;] ethnl_set_privflags+0x234/0x2d0\n [\u0026lt;00000000fd27f27c\u0026gt;] genl_family_rcv_msg_doit+0x108/0x1d0\n [\u0026lt;00000000f495e2bb\u0026gt;] genl_family_rcv_msg+0xe4/0x1f0\n [\u0026lt;00000000646c5c2c\u0026gt;] genl_rcv_msg+0x78/0x120\n [\u0026lt;00000000d53e384e\u0026gt;] netlink_rcv_skb+0x74/0x1a0(CVE-2021-47438)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nNFC: digital: fix possible memory leak in digital_in_send_sdd_req()\r\n\r\n\u0026apos;skb\u0026apos; is allocated in digital_in_send_sdd_req(), but not free when\ndigital_in_send_cmd() failed, which will cause memory leak. Fix it\nby freeing \u0026apos;skb\u0026apos; if digital_in_send_cmd() return failed.(CVE-2021-47442)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nNFC: digital: fix possible memory leak in digital_tg_listen_mdaa()\r\n\r\n\u0026apos;params\u0026apos; is allocated in digital_tg_listen_mdaa(), but not free when\ndigital_send_cmd() failed, which will cause memory leak. Fix it by\nfreeing \u0026apos;params\u0026apos; if digital_send_cmd() return failed.(CVE-2021-47443)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/msm: Fix null pointer dereference on pointer edp\r\n\r\nThe initialization of pointer dev dereferences pointer edp before\nedp is null checked, so there is a potential null pointer deference\nissue. Fix this by only dereferencing edp after edp has been null\nchecked.\r\n\r\nAddresses-Coverity: (\u0026quot;Dereference before null check\u0026quot;)(CVE-2021-47445)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nocfs2: mount fails with buffer overflow in strlen\r\n\r\nStarting with kernel 5.11 built with CONFIG_FORTIFY_SOURCE mouting an\nocfs2 filesystem with either o2cb or pcmk cluster stack fails with the\ntrace below. Problem seems to be that strings for cluster stack and\ncluster name are not guaranteed to be null terminated in the disk\nrepresentation, while strlcpy assumes that the source string is always\nnull terminated. This causes a read outside of the source string\ntriggering the buffer overflow detection.\r\n\r\n detected buffer overflow in strlen\n ------------[ cut here ]------------\n kernel BUG at lib/string.c:1149!\n invalid opcode: 0000 [#1] SMP PTI\n CPU: 1 PID: 910 Comm: mount.ocfs2 Not tainted 5.14.0-1-amd64 #1\n Debian 5.14.6-2\n RIP: 0010:fortify_panic+0xf/0x11\n ...\n Call Trace:\n ocfs2_initialize_super.isra.0.cold+0xc/0x18 [ocfs2]\n ocfs2_fill_super+0x359/0x19b0 [ocfs2]\n mount_bdev+0x185/0x1b0\n legacy_get_tree+0x27/0x40\n vfs_get_tree+0x25/0xb0\n path_mount+0x454/0xa20\n __x64_sys_mount+0x103/0x140\n do_syscall_64+0x3b/0xc0\n entry_SYSCALL_64_after_hwframe+0x44/0xae(CVE-2021-47458)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncan: j1939: j1939_netdev_start(): fix UAF for rx_kref of j1939_priv\r\n\r\nIt will trigger UAF for rx_kref of j1939_priv as following.\r\n\r\n cpu0 cpu1\nj1939_sk_bind(socket0, ndev0, ...)\nj1939_netdev_start\n j1939_sk_bind(socket1, ndev0, ...)\n j1939_netdev_start\nj1939_priv_set\n j1939_priv_get_by_ndev_locked\nj1939_jsk_add\n.....\nj1939_netdev_stop\nkref_put_lock(\u0026amp;priv-\u0026gt;rx_kref, ...)\n kref_get(\u0026amp;priv-\u0026gt;rx_kref, ...)\n REFCOUNT_WARN(\u0026quot;addition on 0;...\u0026quot;)\r\n\r\n====================================================\nrefcount_t: addition on 0; use-after-free.\nWARNING: CPU: 1 PID: 20874 at lib/refcount.c:25 refcount_warn_saturate+0x169/0x1e0\nRIP: 0010:refcount_warn_saturate+0x169/0x1e0\nCall Trace:\n j1939_netdev_start+0x68b/0x920\n j1939_sk_bind+0x426/0xeb0\n ? security_socket_bind+0x83/0xb0\r\n\r\nThe rx_kref\u0026apos;s kref_get() and kref_put() should use j1939_netdev_lock to\nprotect.(CVE-2021-47459)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncomedi: vmk80xx: fix transfer-buffer overflows\r\n\r\nThe driver uses endpoint-sized USB transfer buffers but up until\nrecently had no sanity checks on the sizes.\r\n\r\nCommit e1f13c879a7c (\u0026quot;staging: comedi: check validity of wMaxPacketSize\nof usb endpoints found\u0026quot;) inadvertently fixed NULL-pointer dereferences\nwhen accessing the transfer buffers in case a malicious device has a\nzero wMaxPacketSize.\r\n\r\nMake sure to allocate buffers large enough to handle also the other\naccesses that are done without a size check (e.g. byte 18 in\nvmk80xx_cnt_insn_read() for the VMK8061_MODEL) to avoid writing beyond\nthe buffers, for example, when doing descriptor fuzzing.\r\n\r\nThe original driver was for a low-speed device with 8-byte buffers.\nSupport was later added for a device that uses bulk transfers and is\npresumably a full-speed device with a maximum 64-byte wMaxPacketSize.(CVE-2021-47475)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncomedi: dt9812: fix DMA buffers on stack\r\n\r\nUSB transfer buffers are typically mapped for DMA and must not be\nallocated on the stack or transfers will fail.\r\n\r\nAllocate proper transfer buffers in the various command helpers and\nreturn an error on short transfers instead of acting on random stack\ndata.\r\n\r\nNote that this also fixes a stack info leak on systems where DMA is not\nused as 32 bytes are always sent to the device regardless of how short\nthe command is.(CVE-2021-47477)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusbnet: sanity check for maxpacket\r\n\r\nmaxpacket of 0 makes no sense and oopses as we need to divide\nby it. Give up.\r\n\r\nV2: fixed typo in log and stylistic issues(CVE-2021-47495)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nperf hist: Fix memory leak of a perf_hpp_fmt\r\n\r\nperf_hpp__column_unregister() removes an entry from a list but doesn\u0026apos;t\nfree the memory causing a memory leak spotted by leak sanitizer.\r\n\r\nAdd the free while at the same time reducing the scope of the function\nto static.(CVE-2021-47545)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nethernet: hisilicon: hns: hns_dsaf_misc: fix a possible array overflow in hns_dsaf_ge_srst_by_port()\r\n\r\nThe if statement:\n if (port \u0026gt;= DSAF_GE_NUM)\n return;\r\n\r\nlimits the value of port less than DSAF_GE_NUM (i.e., 8).\nHowever, if the value of port is 6 or 7, an array overflow could occur:\n port_rst_off = dsaf_dev-\u0026gt;mac_cb[port]-\u0026gt;port_rst_off;\r\n\r\nbecause the length of dsaf_dev-\u0026gt;mac_cb is DSAF_MAX_PORT_NUM (i.e., 6).\r\n\r\nTo fix this possible array overflow, we first check port and if it is\ngreater than or equal to DSAF_MAX_PORT_NUM, the function returns.(CVE-2021-47548)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsata_fsl: fix UAF in sata_fsl_port_stop when rmmod sata_fsl\r\n\r\nWhen the `rmmod sata_fsl.ko` command is executed in the PPC64 GNU/Linux,\na bug is reported:\n ==================================================================\n BUG: Unable to handle kernel data access on read at 0x80000800805b502c\n Oops: Kernel access of bad area, sig: 11 [#1]\n NIP [c0000000000388a4] .ioread32+0x4/0x20\n LR [80000000000c6034] .sata_fsl_port_stop+0x44/0xe0 [sata_fsl]\n Call Trace:\n .free_irq+0x1c/0x4e0 (unreliable)\n .ata_host_stop+0x74/0xd0 [libata]\n .release_nodes+0x330/0x3f0\n .device_release_driver_internal+0x178/0x2c0\n .driver_detach+0x64/0xd0\n .bus_remove_driver+0x70/0xf0\n .driver_unregister+0x38/0x80\n .platform_driver_unregister+0x14/0x30\n .fsl_sata_driver_exit+0x18/0xa20 [sata_fsl]\n .__se_sys_delete_module+0x1ec/0x2d0\n .system_call_exception+0xfc/0x1f0\n system_call_common+0xf8/0x200\n ==================================================================\r\n\r\nThe triggering of the BUG is shown in the following stack:\r\n\r\ndriver_detach\n device_release_driver_internal\n __device_release_driver\n drv-\u0026gt;remove(dev) --\u0026gt; platform_drv_remove/platform_remove\n drv-\u0026gt;remove(dev) --\u0026gt; sata_fsl_remove\n iounmap(host_priv-\u0026gt;hcr_base);\t\t\t\u0026lt;---- unmap\n kfree(host_priv); \u0026lt;---- free\n devres_release_all\n release_nodes\n dr-\u0026gt;node.release(dev, dr-\u0026gt;data) --\u0026gt; ata_host_stop\n ap-\u0026gt;ops-\u0026gt;port_stop(ap) --\u0026gt; sata_fsl_port_stop\n ioread32(hcr_base + HCONTROL) \u0026lt;---- UAF\n host-\u0026gt;ops-\u0026gt;host_stop(host)\r\n\r\nThe iounmap(host_priv-\u0026gt;hcr_base) and kfree(host_priv) functions should\nnot be executed in drv-\u0026gt;remove. These functions should be executed in\nhost_stop after port_stop. Therefore, we move these functions to the\nnew function sata_fsl_host_stop and bind the new function to host_stop.(CVE-2021-47549)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/smc: Fix NULL pointer dereferencing in smc_vlan_by_tcpsk()\r\n\r\nCoverity reports a possible NULL dereferencing problem:\r\n\r\nin smc_vlan_by_tcpsk():\n6. returned_null: netdev_lower_get_next returns NULL (checked 29 out of 30 times).\n7. var_assigned: Assigning: ndev = NULL return value from netdev_lower_get_next.\n1623 ndev = (struct net_device *)netdev_lower_get_next(ndev, \u0026amp;lower);\nCID 1468509 (#1 of 1): Dereference null return value (NULL_RETURNS)\n8. dereference: Dereferencing a pointer that might be NULL ndev when calling is_vlan_dev.\n1624 if (is_vlan_dev(ndev)) {\r\n\r\nRemove the manual implementation and use netdev_walk_all_lower_dev() to\niterate over the lower devices. While on it remove an obsolete function\nparameter comment.(CVE-2021-47559)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npinctrl: single: fix potential NULL dereference\r\n\r\nAdded checking of pointer \u0026quot;function\u0026quot; in pcs_set_mux().\npinmux_generic_get_function() can return NULL and the pointer\n\u0026quot;function\u0026quot; was dereferenced without checking against NULL.\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2022-48708)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncrypto: s390/aes - Fix buffer overread in CTR mode\r\n\r\nWhen processing the last block, the s390 ctr code will always read\na whole block, even if there isn\u0026apos;t a whole block of data left. Fix\nthis by using the actual length left and copy it into a buffer first\nfor processing.(CVE-2023-52669)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nACPI: video: check for error while searching for backlight device parent\r\n\r\nIf acpi_get_parent() called in acpi_video_dev_register_backlight()\nfails, for example, because acpi_ut_acquire_mutex() fails inside\nacpi_get_parent), this can lead to incorrect (uninitialized)\nacpi_parent handle being passed to acpi_get_pci_dev() for detecting\nthe parent pci device.\r\n\r\nCheck acpi_get_parent() result and set parent device only in case of success.\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2023-52693)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsysv: don\u0026apos;t call sb_bread() with pointers_lock held\r\n\r\nsyzbot is reporting sleep in atomic context in SysV filesystem [1], for\nsb_bread() is called with rw_spinlock held.\r\n\r\nA \u0026quot;write_lock(\u0026amp;pointers_lock) =\u0026gt; read_lock(\u0026amp;pointers_lock) deadlock\u0026quot; bug\nand a \u0026quot;sb_bread() with write_lock(\u0026amp;pointers_lock)\u0026quot; bug were introduced by\n\u0026quot;Replace BKL for chain locking with sysvfs-private rwlock\u0026quot; in Linux 2.5.12.\r\n\r\nThen, \u0026quot;[PATCH] err1-40: sysvfs locking fix\u0026quot; in Linux 2.6.8 fixed the\nformer bug by moving pointers_lock lock to the callers, but instead\nintroduced a \u0026quot;sb_bread() with read_lock(\u0026amp;pointers_lock)\u0026quot; bug (which made\nthis problem easier to hit).\r\n\r\nAl Viro suggested that why not to do like get_branch()/get_block()/\nfind_shared() in Minix filesystem does. And doing like that is almost a\nrevert of \u0026quot;[PATCH] err1-40: sysvfs locking fix\u0026quot; except that get_branch()\n from with find_shared() is called without write_lock(\u0026amp;pointers_lock).(CVE-2023-52699)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/usb: kalmia: Don\u0026apos;t pass act_len in usb_bulk_msg error path\r\n\r\nsyzbot reported that act_len in kalmia_send_init_packet() is\nuninitialized when passing it to the first usb_bulk_msg error path. Jiri\nPirko noted that it\u0026apos;s pointless to pass it in the error path, and that\nthe value that would be printed in the second error path would be the\nvalue of act_len from the first call to usb_bulk_msg.[1]\r\n\r\nWith this in mind, let\u0026apos;s just not pass act_len to the usb_bulk_msg error\npaths.\r\n\r\n1: https://lore.kernel.org/lkml/Y9pY61y1nwTuzMOa@nanopsycho/(CVE-2023-52703)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\narm64: Restrict CPU_BIG_ENDIAN to GNU as or LLVM IAS 15.x or newer\r\n\r\nPrior to LLVM 15.0.0, LLVM\u0026apos;s integrated assembler would incorrectly\nbyte-swap NOP when compiling for big-endian, and the resulting series of\nbytes happened to match the encoding of FNMADD S21, S30, S0, S0.\r\n\r\nThis went unnoticed until commit:\r\n\r\n 34f66c4c4d5518c1 (\u0026quot;arm64: Use a positive cpucap for FP/SIMD\u0026quot;)\r\n\r\nPrior to that commit, the kernel would always enable the use of FPSIMD\nearly in boot when __cpu_setup() initialized CPACR_EL1, and so usage of\nFNMADD within the kernel was not detected, but could result in the\ncorruption of user or kernel FPSIMD state.\r\n\r\nAfter that commit, the instructions happen to trap during boot prior to\nFPSIMD being detected and enabled, e.g.\r\n\r\n| Unhandled 64-bit el1h sync exception on CPU0, ESR 0x000000001fe00000 -- ASIMD\n| CPU: 0 PID: 0 Comm: swapper Not tainted 6.6.0-rc3-00013-g34f66c4c4d55 #1\n| Hardware name: linux,dummy-virt (DT)\n| pstate: 400000c9 (nZcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n| pc : __pi_strcmp+0x1c/0x150\n| lr : populate_properties+0xe4/0x254\n| sp : ffffd014173d3ad0\n| x29: ffffd014173d3af0 x28: fffffbfffddffcb8 x27: 0000000000000000\n| x26: 0000000000000058 x25: fffffbfffddfe054 x24: 0000000000000008\n| x23: fffffbfffddfe000 x22: fffffbfffddfe000 x21: fffffbfffddfe044\n| x20: ffffd014173d3b70 x19: 0000000000000001 x18: 0000000000000005\n| x17: 0000000000000010 x16: 0000000000000000 x15: 00000000413e7000\n| x14: 0000000000000000 x13: 0000000000001bcc x12: 0000000000000000\n| x11: 00000000d00dfeed x10: ffffd414193f2cd0 x9 : 0000000000000000\n| x8 : 0101010101010101 x7 : ffffffffffffffc0 x6 : 0000000000000000\n| x5 : 0000000000000000 x4 : 0101010101010101 x3 : 000000000000002a\n| x2 : 0000000000000001 x1 : ffffd014171f2988 x0 : fffffbfffddffcb8\n| Kernel panic - not syncing: Unhandled exception\n| CPU: 0 PID: 0 Comm: swapper Not tainted 6.6.0-rc3-00013-g34f66c4c4d55 #1\n| Hardware name: linux,dummy-virt (DT)\n| Call trace:\n| dump_backtrace+0xec/0x108\n| show_stack+0x18/0x2c\n| dump_stack_lvl+0x50/0x68\n| dump_stack+0x18/0x24\n| panic+0x13c/0x340\n| el1t_64_irq_handler+0x0/0x1c\n| el1_abort+0x0/0x5c\n| el1h_64_sync+0x64/0x68\n| __pi_strcmp+0x1c/0x150\n| unflatten_dt_nodes+0x1e8/0x2d8\n| __unflatten_device_tree+0x5c/0x15c\n| unflatten_device_tree+0x38/0x50\n| setup_arch+0x164/0x1e0\n| start_kernel+0x64/0x38c\n| __primary_switched+0xbc/0xc4\r\n\r\nRestrict CONFIG_CPU_BIG_ENDIAN to a known good assembler, which is\neither GNU as or LLVM\u0026apos;s IAS 15.0.0 and newer, which contains the linked\ncommit.(CVE-2023-52750)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsmb: client: fix use-after-free bug in cifs_debug_data_proc_show()\r\n\r\nSkip SMB sessions that are being teared down\n(e.g. @ses-\u0026gt;ses_status == SES_EXITING) in cifs_debug_data_proc_show()\nto avoid use-after-free in @ses.\r\n\r\nThis fixes the following GPF when reading from /proc/fs/cifs/DebugData\nwhile mounting and umounting\r\n\r\n [ 816.251274] general protection fault, probably for non-canonical\n address 0x6b6b6b6b6b6b6d81: 0000 [#1] PREEMPT SMP NOPTI\n ...\n [ 816.260138] Call Trace:\n [ 816.260329] \u0026lt;TASK\u0026gt;\n [ 816.260499] ? die_addr+0x36/0x90\n [ 816.260762] ? exc_general_protection+0x1b3/0x410\n [ 816.261126] ? asm_exc_general_protection+0x26/0x30\n [ 816.261502] ? cifs_debug_tcon+0xbd/0x240 [cifs]\n [ 816.261878] ? cifs_debug_tcon+0xab/0x240 [cifs]\n [ 816.262249] cifs_debug_data_proc_show+0x516/0xdb0 [cifs]\n [ 816.262689] ? seq_read_iter+0x379/0x470\n [ 816.262995] seq_read_iter+0x118/0x470\n [ 816.263291] proc_reg_read_iter+0x53/0x90\n [ 816.263596] ? srso_alias_return_thunk+0x5/0x7f\n [ 816.263945] vfs_read+0x201/0x350\n [ 816.264211] ksys_read+0x75/0x100\n [ 816.264472] do_syscall_64+0x3f/0x90\n [ 816.264750] entry_SYSCALL_64_after_hwframe+0x6e/0xd8\n [ 816.265135] RIP: 0033:0x7fd5e669d381(CVE-2023-52752)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ngfs2: ignore negated quota changes\r\n\r\nWhen lots of quota changes are made, there may be cases in which an\ninode\u0026apos;s quota information is increased and then decreased, such as when\nblocks are added to a file, then deleted from it. If the timing is\nright, function do_qc can add pending quota changes to a transaction,\nthen later, another call to do_qc can negate those changes, resulting\nin a net gain of 0. The quota_change information is recorded in the qc\nbuffer (and qd element of the inode as well). The buffer is added to the\ntransaction by the first call to do_qc, but a subsequent call changes\nthe value from non-zero back to zero. At that point it\u0026apos;s too late to\nremove the buffer_head from the transaction. Later, when the quota sync\ncode is called, the zero-change qd element is discovered and flagged as\nan assert warning. If the fs is mounted with errors=panic, the kernel\nwill panic.\r\n\r\nThis is usually seen when files are truncated and the quota changes are\nnegated by punch_hole/truncate which uses gfs2_quota_hold and\ngfs2_quota_unhold rather than block allocations that use gfs2_quota_lock\nand gfs2_quota_unlock which automatically do quota sync.\r\n\r\nThis patch solves the problem by adding a check to qd_check_sync such\nthat net-zero quota changes already added to the transaction are no\nlonger deemed necessary to be synced, and skipped.\r\n\r\nIn this case references are taken for the qd and the slot from do_qc\nso those need to be put. The normal sequence of events for a normal\nnon-zero quota change is as follows:\r\n\r\ngfs2_quota_change\n do_qc\n qd_hold\n slot_hold\r\n\r\nLater, when the changes are to be synced:\r\n\r\ngfs2_quota_sync\n qd_fish\n qd_check_sync\n gets qd ref via lockref_get_not_dead\n do_sync\n do_qc(QC_SYNC)\n qd_put\n\t lockref_put_or_lock\n qd_unlock\n qd_put\n lockref_put_or_lock\r\n\r\nIn the net-zero change case, we add a check to qd_check_sync so it puts\nthe qd and slot references acquired in gfs2_quota_change and skip the\nunneeded sync.(CVE-2023-52759)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntty: vcc: Add check for kstrdup() in vcc_probe()\r\n\r\nAdd check for the return value of kstrdup() and return the error, if it\nfails in order to avoid NULL pointer dereference.(CVE-2023-52789)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nipvlan: add ipvlan_route_v6_outbound() helper\r\n\r\nInspired by syzbot reports using a stack of multiple ipvlan devices.\r\n\r\nReduce stack size needed in ipvlan_process_v6_outbound() by moving\nthe flowi6 struct used for the route lookup in an non inlined\nhelper. ipvlan_route_v6_outbound() needs 120 bytes on the stack,\nimmediately reclaimed.\r\n\r\nAlso make sure ipvlan_process_v4_outbound() is not inlined.\r\n\r\nWe might also have to lower MAX_NEST_DEV, because only syzbot uses\nsetups with more than four stacked devices.\r\n\r\nBUG: TASK stack guard page was hit at ffffc9000e803ff8 (stack is ffffc9000e804000..ffffc9000e808000)\nstack guard page: 0000 [#1] SMP KASAN\nCPU: 0 PID: 13442 Comm: syz-executor.4 Not tainted 6.1.52-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/09/2023\nRIP: 0010:kasan_check_range+0x4/0x2a0 mm/kasan/generic.c:188\nCode: 48 01 c6 48 89 c7 e8 db 4e c1 03 31 c0 5d c3 cc 0f 0b eb 02 0f 0b b8 ea ff ff ff 5d c3 cc 00 00 cc cc 00 00 cc cc 55 48 89 e5 \u0026lt;41\u0026gt; 57 41 56 41 55 41 54 53 b0 01 48 85 f6 0f 84 a4 01 00 00 48 89\nRSP: 0018:ffffc9000e804000 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff817e5bf2\nRDX: 0000000000000000 RSI: 0000000000000008 RDI: ffffffff887c6568\nRBP: ffffc9000e804000 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: dffffc0000000001 R12: 1ffff92001d0080c\nR13: dffffc0000000000 R14: ffffffff87e6b100 R15: 0000000000000000\nFS: 00007fd0c55826c0(0000) GS:ffff8881f6800000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: ffffc9000e803ff8 CR3: 0000000170ef7000 CR4: 00000000003506f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n\u0026lt;#DF\u0026gt;\n\u0026lt;/#DF\u0026gt;\n\u0026lt;TASK\u0026gt;\n[\u0026lt;ffffffff81f281d1\u0026gt;] __kasan_check_read+0x11/0x20 mm/kasan/shadow.c:31\n[\u0026lt;ffffffff817e5bf2\u0026gt;] instrument_atomic_read include/linux/instrumented.h:72 [inline]\n[\u0026lt;ffffffff817e5bf2\u0026gt;] _test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline]\n[\u0026lt;ffffffff817e5bf2\u0026gt;] cpumask_test_cpu include/linux/cpumask.h:506 [inline]\n[\u0026lt;ffffffff817e5bf2\u0026gt;] cpu_online include/linux/cpumask.h:1092 [inline]\n[\u0026lt;ffffffff817e5bf2\u0026gt;] trace_lock_acquire include/trace/events/lock.h:24 [inline]\n[\u0026lt;ffffffff817e5bf2\u0026gt;] lock_acquire+0xe2/0x590 kernel/locking/lockdep.c:5632\n[\u0026lt;ffffffff8563221e\u0026gt;] rcu_lock_acquire+0x2e/0x40 include/linux/rcupdate.h:306\n[\u0026lt;ffffffff8561464d\u0026gt;] rcu_read_lock include/linux/rcupdate.h:747 [inline]\n[\u0026lt;ffffffff8561464d\u0026gt;] ip6_pol_route+0x15d/0x1440 net/ipv6/route.c:2221\n[\u0026lt;ffffffff85618120\u0026gt;] ip6_pol_route_output+0x50/0x80 net/ipv6/route.c:2606\n[\u0026lt;ffffffff856f65b5\u0026gt;] pol_lookup_func include/net/ip6_fib.h:584 [inline]\n[\u0026lt;ffffffff856f65b5\u0026gt;] fib6_rule_lookup+0x265/0x620 net/ipv6/fib6_rules.c:116\n[\u0026lt;ffffffff85618009\u0026gt;] ip6_route_output_flags_noref+0x2d9/0x3a0 net/ipv6/route.c:2638\n[\u0026lt;ffffffff8561821a\u0026gt;] ip6_route_output_flags+0xca/0x340 net/ipv6/route.c:2651\n[\u0026lt;ffffffff838bd5a3\u0026gt;] ip6_route_output include/net/ip6_route.h:100 [inline]\n[\u0026lt;ffffffff838bd5a3\u0026gt;] ipvlan_process_v6_outbound drivers/net/ipvlan/ipvlan_core.c:473 [inline]\n[\u0026lt;ffffffff838bd5a3\u0026gt;] ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:529 [inline]\n[\u0026lt;ffffffff838bd5a3\u0026gt;] ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline]\n[\u0026lt;ffffffff838bd5a3\u0026gt;] ipvlan_queue_xmit+0xc33/0x1be0 drivers/net/ipvlan/ipvlan_core.c:677\n[\u0026lt;ffffffff838c2909\u0026gt;] ipvlan_start_xmit+0x49/0x100 drivers/net/ipvlan/ipvlan_main.c:229\n[\u0026lt;ffffffff84d03900\u0026gt;] netdev_start_xmit include/linux/netdevice.h:4966 [inline]\n[\u0026lt;ffffffff84d03900\u0026gt;] xmit_one net/core/dev.c:3644 [inline]\n[\u0026lt;ffffffff84d03900\u0026gt;] dev_hard_start_xmit+0x320/0x980 net/core/dev.c:3660\n[\u0026lt;ffffffff84d080e2\u0026gt;] __dev_queue_xmit+0x16b2/0x3370 net/core/dev.c:4324\n[\u0026lt;ffffffff855ce4cd\u0026gt;] dev_queue_xmit include/linux/netdevice.h:3067 [inline]\n[\u0026lt;ffffffff855ce4cd\u0026gt;] neigh_hh_output include/net/neighbour.h:529 [inline]\n[\u0026lt;f\n---truncated---(CVE-2023-52796)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\njfs: fix array-index-out-of-bounds in dbFindLeaf\r\n\r\nCurrently while searching for dmtree_t for sufficient free blocks there\nis an array out of bounds while getting element in tp-\u0026gt;dm_stree. To add\nthe required check for out of bound we first need to determine the type\nof dmtree. Thus added an extra parameter to dbFindLeaf so that the type\nof tree can be determined and the required check can be applied.(CVE-2023-52799)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\niio: adc: stm32-adc: harden against NULL pointer deref in stm32_adc_probe()\r\n\r\nof_match_device() may fail and returns a NULL pointer.\r\n\r\nIn practice there is no known reasonable way to trigger this, but\nin case one is added in future, harden the code by adding the check(CVE-2023-52802)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfs/jfs: Add validity check for db_maxag and db_agpref\r\n\r\nBoth db_maxag and db_agpref are used as the index of the\ndb_agfree array, but there is currently no validity check for\ndb_maxag and db_agpref, which can lead to errors.\r\n\r\nThe following is related bug reported by Syzbot:\r\n\r\nUBSAN: array-index-out-of-bounds in fs/jfs/jfs_dmap.c:639:20\nindex 7936 is out of range for type \u0026apos;atomic_t[128]\u0026apos;\r\n\r\nAdd checking that the values of db_maxag and db_agpref are valid\nindexes for the db_agfree array.(CVE-2023-52804)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\njfs: fix array-index-out-of-bounds in diAlloc\r\n\r\nCurrently there is not check against the agno of the iag while\nallocating new inodes to avoid fragmentation problem. Added the check\nwhich is required.(CVE-2023-52805)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: libfc: Fix potential NULL pointer dereference in fc_lport_ptp_setup()\r\n\r\nfc_lport_ptp_setup() did not check the return value of fc_rport_create()\nwhich can return NULL and would cause a NULL pointer dereference. Address\nthis issue by checking return value of fc_rport_create() and log error\nmessage on fc_rport_create() failed.(CVE-2023-52809)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd: Fix UBSAN array-index-out-of-bounds for Polaris and Tonga\r\n\r\nFor pptable structs that use flexible array sizes, use flexible arrays.(CVE-2023-52819)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncpu/hotplug: Don\u0026apos;t offline the last non-isolated CPU\r\n\r\nIf a system has isolated CPUs via the \u0026quot;isolcpus=\u0026quot; command line parameter,\nthen an attempt to offline the last housekeeping CPU will result in a\nWARN_ON() when rebuilding the scheduler domains and a subsequent panic due\nto and unhandled empty CPU mas in partition_sched_domains_locked().\r\n\r\ncpuset_hotplug_workfn()\n rebuild_sched_domains_locked()\n ndoms = generate_sched_domains(\u0026amp;doms, \u0026amp;attr);\n cpumask_and(doms[0], top_cpuset.effective_cpus, housekeeping_cpumask(HK_FLAG_DOMAIN));\r\n\r\nThus results in an empty CPU mask which triggers the warning and then the\nsubsequent crash:\r\n\r\nWARNING: CPU: 4 PID: 80 at kernel/sched/topology.c:2366 build_sched_domains+0x120c/0x1408\nCall trace:\n build_sched_domains+0x120c/0x1408\n partition_sched_domains_locked+0x234/0x880\n rebuild_sched_domains_locked+0x37c/0x798\n rebuild_sched_domains+0x30/0x58\n cpuset_hotplug_workfn+0x2a8/0x930\r\n\r\nUnable to handle kernel paging request at virtual address fffe80027ab37080\n partition_sched_domains_locked+0x318/0x880\n rebuild_sched_domains_locked+0x37c/0x798\r\n\r\nAside of the resulting crash, it does not make any sense to offline the last\nlast housekeeping CPU.\r\n\r\nPrevent this by masking out the non-housekeeping CPUs when selecting a\ntarget CPU for initiating the CPU unplug operation via the work queue.(CVE-2023-52831)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: mac80211: don\u0026apos;t return unset power in ieee80211_get_tx_power()\r\n\r\nWe can get a UBSAN warning if ieee80211_get_tx_power() returns the\nINT_MIN value mac80211 internally uses for \u0026quot;unset power level\u0026quot;.\r\n\r\n UBSAN: signed-integer-overflow in net/wireless/nl80211.c:3816:5\n -2147483648 * 100 cannot be represented in type \u0026apos;int\u0026apos;\n CPU: 0 PID: 20433 Comm: insmod Tainted: G WC OE\n Call Trace:\n dump_stack+0x74/0x92\n ubsan_epilogue+0x9/0x50\n handle_overflow+0x8d/0xd0\n __ubsan_handle_mul_overflow+0xe/0x10\n nl80211_send_iface+0x688/0x6b0 [cfg80211]\n [...]\n cfg80211_register_wdev+0x78/0xb0 [cfg80211]\n cfg80211_netdev_notifier_call+0x200/0x620 [cfg80211]\n [...]\n ieee80211_if_add+0x60e/0x8f0 [mac80211]\n ieee80211_register_hw+0xda5/0x1170 [mac80211]\r\n\r\nIn this case, simply return an error instead, to indicate\nthat no data is available.(CVE-2023-52832)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntipc: Change nla_policy for bearer-related names to NLA_NUL_STRING\r\n\r\nsyzbot reported the following uninit-value access issue [1]:\r\n\r\n=====================================================\nBUG: KMSAN: uninit-value in strlen lib/string.c:418 [inline]\nBUG: KMSAN: uninit-value in strstr+0xb8/0x2f0 lib/string.c:756\n strlen lib/string.c:418 [inline]\n strstr+0xb8/0x2f0 lib/string.c:756\n tipc_nl_node_reset_link_stats+0x3ea/0xb50 net/tipc/node.c:2595\n genl_family_rcv_msg_doit net/netlink/genetlink.c:971 [inline]\n genl_family_rcv_msg net/netlink/genetlink.c:1051 [inline]\n genl_rcv_msg+0x11ec/0x1290 net/netlink/genetlink.c:1066\n netlink_rcv_skb+0x371/0x650 net/netlink/af_netlink.c:2545\n genl_rcv+0x40/0x60 net/netlink/genetlink.c:1075\n netlink_unicast_kernel net/netlink/af_netlink.c:1342 [inline]\n netlink_unicast+0xf47/0x1250 net/netlink/af_netlink.c:1368\n netlink_sendmsg+0x1238/0x13d0 net/netlink/af_netlink.c:1910\n sock_sendmsg_nosec net/socket.c:730 [inline]\n sock_sendmsg net/socket.c:753 [inline]\n ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2541\n ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2595\n __sys_sendmsg net/socket.c:2624 [inline]\n __do_sys_sendmsg net/socket.c:2633 [inline]\n __se_sys_sendmsg net/socket.c:2631 [inline]\n __x64_sys_sendmsg+0x307/0x490 net/socket.c:2631\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\r\n\r\nUninit was created at:\n slab_post_alloc_hook+0x12f/0xb70 mm/slab.h:767\n slab_alloc_node mm/slub.c:3478 [inline]\n kmem_cache_alloc_node+0x577/0xa80 mm/slub.c:3523\n kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:559\n __alloc_skb+0x318/0x740 net/core/skbuff.c:650\n alloc_skb include/linux/skbuff.h:1286 [inline]\n netlink_alloc_large_skb net/netlink/af_netlink.c:1214 [inline]\n netlink_sendmsg+0xb34/0x13d0 net/netlink/af_netlink.c:1885\n sock_sendmsg_nosec net/socket.c:730 [inline]\n sock_sendmsg net/socket.c:753 [inline]\n ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2541\n ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2595\n __sys_sendmsg net/socket.c:2624 [inline]\n __do_sys_sendmsg net/socket.c:2633 [inline]\n __se_sys_sendmsg net/socket.c:2631 [inline]\n __x64_sys_sendmsg+0x307/0x490 net/socket.c:2631\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\r\n\r\nTIPC bearer-related names including link names must be null-terminated\nstrings. If a link name which is not null-terminated is passed through\nnetlink, strstr() and similar functions can cause buffer overrun. This\ncauses the above issue.\r\n\r\nThis patch changes the nla_policy for bearer-related names from NLA_STRING\nto NLA_NUL_STRING. This resolves the issue by ensuring that only\nnull-terminated strings are accepted as bearer-related names.\r\n\r\nsyzbot reported similar uninit-value issue related to bearer names [2]. The\nroot cause of this issue is that a non-null-terminated bearer name was\npassed. This patch also resolved this issue.(CVE-2023-52845)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncan: dev: can_put_echo_skb(): don\u0026apos;t crash kernel if can_priv::echo_skb is accessed out of bounds\r\n\r\nIf the \u0026quot;struct can_priv::echoo_skb\u0026quot; is accessed out of bounds, this\nwould cause a kernel crash. Instead, issue a meaningful warning\nmessage and return with an error.(CVE-2023-52878)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nUSB: core: Fix deadlock in usb_deauthorize_interface()\r\n\r\nAmong the attribute file callback routines in\ndrivers/usb/core/sysfs.c, the interface_authorized_store() function is\nthe only one which acquires a device lock on an ancestor device: It\ncalls usb_deauthorize_interface(), which locks the interface\u0026apos;s parent\nUSB device.\r\n\r\nThe will lead to deadlock if another process already owns that lock\nand tries to remove the interface, whether through a configuration\nchange or because the device has been disconnected. As part of the\nremoval procedure, device_del() waits for all ongoing sysfs attribute\ncallbacks to complete. But usb_deauthorize_interface() can\u0026apos;t complete\nuntil the device lock has been released, and the lock won\u0026apos;t be\nreleased until the removal has finished.\r\n\r\nThe mechanism provided by sysfs to prevent this kind of deadlock is\nto use the sysfs_break_active_protection() function, which tells sysfs\nnot to wait for the attribute callback.\r\n\r\nReported-and-tested by: Yue Sun \u0026lt;samsun1006219@gmail.com\u0026gt;\nReported by: xingwei lee \u0026lt;xrivendell7@gmail.com\u0026gt;(CVE-2024-26934)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nf_tables: Fix potential data-race in __nft_expr_type_get()\r\n\r\nnft_unregister_expr() can concurrent with __nft_expr_type_get(),\nand there is not any protection when iterate over nf_tables_expressions\nlist in __nft_expr_type_get(). Therefore, there is potential data-race\nof nf_tables_expressions list entry.\r\n\r\nUse list_for_each_entry_rcu() to iterate over nf_tables_expressions\nlist in __nft_expr_type_get(), and use rcu_read_lock() in the caller\nnft_expr_type_get() to protect the entire type query process.(CVE-2024-27020)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nBluetooth: l2cap: fix null-ptr-deref in l2cap_chan_timeout\r\n\r\nThere is a race condition between l2cap_chan_timeout() and\nl2cap_chan_del(). When we use l2cap_chan_del() to delete the\nchannel, the chan-\u0026gt;conn will be set to null. But the conn could\nbe dereferenced again in the mutex_lock() of l2cap_chan_timeout().\nAs a result the null pointer dereference bug will happen. The\nKASAN report triggered by POC is shown below:\r\n\r\n[ 472.074580] ==================================================================\n[ 472.075284] BUG: KASAN: null-ptr-deref in mutex_lock+0x68/0xc0\n[ 472.075308] Write of size 8 at addr 0000000000000158 by task kworker/0:0/7\n[ 472.075308]\n[ 472.075308] CPU: 0 PID: 7 Comm: kworker/0:0 Not tainted 6.9.0-rc5-00356-g78c0094a146b #36\n[ 472.075308] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu4\n[ 472.075308] Workqueue: events l2cap_chan_timeout\n[ 472.075308] Call Trace:\n[ 472.075308] \u0026lt;TASK\u0026gt;\n[ 472.075308] dump_stack_lvl+0x137/0x1a0\n[ 472.075308] print_report+0x101/0x250\n[ 472.075308] ? __virt_addr_valid+0x77/0x160\n[ 472.075308] ? mutex_lock+0x68/0xc0\n[ 472.075308] kasan_report+0x139/0x170\n[ 472.075308] ? mutex_lock+0x68/0xc0\n[ 472.075308] kasan_check_range+0x2c3/0x2e0\n[ 472.075308] mutex_lock+0x68/0xc0\n[ 472.075308] l2cap_chan_timeout+0x181/0x300\n[ 472.075308] process_one_work+0x5d2/0xe00\n[ 472.075308] worker_thread+0xe1d/0x1660\n[ 472.075308] ? pr_cont_work+0x5e0/0x5e0\n[ 472.075308] kthread+0x2b7/0x350\n[ 472.075308] ? pr_cont_work+0x5e0/0x5e0\n[ 472.075308] ? kthread_blkcg+0xd0/0xd0\n[ 472.075308] ret_from_fork+0x4d/0x80\n[ 472.075308] ? kthread_blkcg+0xd0/0xd0\n[ 472.075308] ret_from_fork_asm+0x11/0x20\n[ 472.075308] \u0026lt;/TASK\u0026gt;\n[ 472.075308] ==================================================================\n[ 472.094860] Disabling lock debugging due to kernel taint\n[ 472.096136] BUG: kernel NULL pointer dereference, address: 0000000000000158\n[ 472.096136] #PF: supervisor write access in kernel mode\n[ 472.096136] #PF: error_code(0x0002) - not-present page\n[ 472.096136] PGD 0 P4D 0\n[ 472.096136] Oops: 0002 [#1] PREEMPT SMP KASAN NOPTI\n[ 472.096136] CPU: 0 PID: 7 Comm: kworker/0:0 Tainted: G B 6.9.0-rc5-00356-g78c0094a146b #36\n[ 472.096136] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu4\n[ 472.096136] Workqueue: events l2cap_chan_timeout\n[ 472.096136] RIP: 0010:mutex_lock+0x88/0xc0\n[ 472.096136] Code: be 08 00 00 00 e8 f8 23 1f fd 4c 89 f7 be 08 00 00 00 e8 eb 23 1f fd 42 80 3c 23 00 74 08 48 88\n[ 472.096136] RSP: 0018:ffff88800744fc78 EFLAGS: 00000246\n[ 472.096136] RAX: 0000000000000000 RBX: 1ffff11000e89f8f RCX: ffffffff8457c865\n[ 472.096136] RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffff88800744fc78\n[ 472.096136] RBP: 0000000000000158 R08: ffff88800744fc7f R09: 1ffff11000e89f8f\n[ 472.096136] R10: dffffc0000000000 R11: ffffed1000e89f90 R12: dffffc0000000000\n[ 472.096136] R13: 0000000000000158 R14: ffff88800744fc78 R15: ffff888007405a00\n[ 472.096136] FS: 0000000000000000(0000) GS:ffff88806d200000(0000) knlGS:0000000000000000\n[ 472.096136] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 472.096136] CR2: 0000000000000158 CR3: 000000000da32000 CR4: 00000000000006f0\n[ 472.096136] Call Trace:\n[ 472.096136] \u0026lt;TASK\u0026gt;\n[ 472.096136] ? __die_body+0x8d/0xe0\n[ 472.096136] ? page_fault_oops+0x6b8/0x9a0\n[ 472.096136] ? kernelmode_fixup_or_oops+0x20c/0x2a0\n[ 472.096136] ? do_user_addr_fault+0x1027/0x1340\n[ 472.096136] ? _printk+0x7a/0xa0\n[ 472.096136] ? mutex_lock+0x68/0xc0\n[ 472.096136] ? add_taint+0x42/0xd0\n[ 472.096136] ? exc_page_fault+0x6a/0x1b0\n[ 472.096136] ? asm_exc_page_fault+0x26/0x30\n[ 472.096136] ? mutex_lock+0x75/0xc0\n[ 472.096136] ? mutex_lock+0x88/0xc0\n[ 472.096136] ? mutex_lock+0x75/0xc0\n[ 472.096136] l2cap_chan_timeo\n---truncated---(CVE-2024-27399)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfirewire: nosy: ensure user_length is taken into account when fetching packet contents\r\n\r\nEnsure that packet_buffer_get respects the user_length provided. If\nthe length of the head packet exceeds the user_length, packet_buffer_get\nwill now return 0 to signify to the user that no data were read\nand a larger buffer size is required. Helps prevent user space overflows.(CVE-2024-27401)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: mac80211: check/clear fast rx for non-4addr sta VLAN changes\r\n\r\nWhen moving a station out of a VLAN and deleting the VLAN afterwards, the\nfast_rx entry still holds a pointer to the VLAN\u0026apos;s netdev, which can cause\nuse-after-free bugs. Fix this by immediately calling ieee80211_check_fast_rx\nafter the VLAN change.(CVE-2024-35789)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmd/dm-raid: don\u0026apos;t call md_reap_sync_thread() directly\r\n\r\nCurrently md_reap_sync_thread() is called from raid_message() directly\nwithout holding \u0026apos;reconfig_mutex\u0026apos;, this is definitely unsafe because\nmd_reap_sync_thread() can change many fields that is protected by\n\u0026apos;reconfig_mutex\u0026apos;.\r\n\r\nHowever, hold \u0026apos;reconfig_mutex\u0026apos; here is still problematic because this\nwill cause deadlock, for example, commit 130443d60b1b (\u0026quot;md: refactor\nidle/frozen_sync_thread() to fix deadlock\u0026quot;).\r\n\r\nFix this problem by using stop_sync_thread() to unregister sync_thread,\nlike md/raid did.(CVE-2024-35808)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: udc: remove warning when queue disabled ep\r\n\r\nIt is possible trigger below warning message from mass storage function,\r\n\r\nWARNING: CPU: 6 PID: 3839 at drivers/usb/gadget/udc/core.c:294 usb_ep_queue+0x7c/0x104\npc : usb_ep_queue+0x7c/0x104\nlr : fsg_main_thread+0x494/0x1b3c\r\n\r\nRoot cause is mass storage function try to queue request from main thread,\nbut other thread may already disable ep when function disable.\r\n\r\nAs there is no function failure in the driver, in order to avoid effort\nto fix warning, change WARN_ON_ONCE() in usb_ep_queue() to pr_debug().(CVE-2024-35822)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nvt: fix unicode buffer corruption when deleting characters\r\n\r\nThis is the same issue that was fixed for the VGA text buffer in commit\n39cdb68c64d8 (\u0026quot;vt: fix memory overlapping when deleting chars in the\nbuffer\u0026quot;). The cure is also the same i.e. replace memcpy() with memmove()\ndue to the overlaping buffers.(CVE-2024-35823)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nx86/mm/pat: fix VM_PAT handling in COW mappings\r\n\r\nPAT handling won\u0026apos;t do the right thing in COW mappings: the first PTE (or,\nin fact, all PTEs) can be replaced during write faults to point at anon\nfolios. Reliably recovering the correct PFN and cachemode using\nfollow_phys() from PTEs will not work in COW mappings.\r\n\r\nUsing follow_phys(), we might just get the address+protection of the anon\nfolio (which is very wrong), or fail on swap/nonswap entries, failing\nfollow_phys() and triggering a WARN_ON_ONCE() in untrack_pfn() and\ntrack_pfn_copy(), not properly calling free_pfn_range().\r\n\r\nIn free_pfn_range(), we either wouldn\u0026apos;t call memtype_free() or would call\nit with the wrong range, possibly leaking memory.\r\n\r\nTo fix that, let\u0026apos;s update follow_phys() to refuse returning anon folios,\nand fallback to using the stored PFN inside vma-\u0026gt;vm_pgoff for COW mappings\nif we run into that.\r\n\r\nWe will now properly handle untrack_pfn() with COW mappings, where we\ndon\u0026apos;t need the cachemode. We\u0026apos;ll have to fail fork()-\u0026gt;track_pfn_copy() if\nthe first page was replaced by an anon folio, though: we\u0026apos;d have to store\nthe cachemode in the VMA to make this work, likely growing the VMA size.\r\n\r\nFor now, lets keep it simple and let track_pfn_copy() just fail in that\ncase: it would have failed in the past with swap/nonswap entries already,\nand it would have done the wrong thing with anon folios.\r\n\r\nSimple reproducer to trigger the WARN_ON_ONCE() in untrack_pfn():\r\n\r\n\u0026lt;--- C reproducer ---\u0026gt;\n #include \u0026lt;stdio.h\u0026gt;\n #include \u0026lt;sys/mman.h\u0026gt;\n #include \u0026lt;unistd.h\u0026gt;\n #include \u0026lt;liburing.h\u0026gt;\r\n\r\n int main(void)\n {\n struct io_uring_params p = {};\n int ring_fd;\n size_t size;\n char *map;\r\n\r\n ring_fd = io_uring_setup(1, \u0026amp;p);\n if (ring_fd \u0026lt; 0) {\n perror(\u0026quot;io_uring_setup\u0026quot;);\n return 1;\n }\n size = p.sq_off.array + p.sq_entries * sizeof(unsigned);\r\n\r\n /* Map the submission queue ring MAP_PRIVATE */\n map = mmap(0, size, PROT_READ | PROT_WRITE, MAP_PRIVATE,\n ring_fd, IORING_OFF_SQ_RING);\n if (map == MAP_FAILED) {\n perror(\u0026quot;mmap\u0026quot;);\n return 1;\n }\r\n\r\n /* We have at least one page. Let\u0026apos;s COW it. */\n *map = 0;\n pause();\n return 0;\n }\n\u0026lt;--- C reproducer ---\u0026gt;\r\n\r\nOn a system with 16 GiB RAM and swap configured:\n # ./iouring \u0026amp;\n # memhog 16G\n # killall iouring\n[ 301.552930] ------------[ cut here ]------------\n[ 301.553285] WARNING: CPU: 7 PID: 1402 at arch/x86/mm/pat/memtype.c:1060 untrack_pfn+0xf4/0x100\n[ 301.553989] Modules linked in: binfmt_misc nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_g\n[ 301.558232] CPU: 7 PID: 1402 Comm: iouring Not tainted 6.7.5-100.fc38.x86_64 #1\n[ 301.558772] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebu4\n[ 301.559569] RIP: 0010:untrack_pfn+0xf4/0x100\n[ 301.559893] Code: 75 c4 eb cf 48 8b 43 10 8b a8 e8 00 00 00 3b 6b 28 74 b8 48 8b 7b 30 e8 ea 1a f7 000\n[ 301.561189] RSP: 0018:ffffba2c0377fab8 EFLAGS: 00010282\n[ 301.561590] RAX: 00000000ffffffea RBX: ffff9208c8ce9cc0 RCX: 000000010455e047\n[ 301.562105] RDX: 07fffffff0eb1e0a RSI: 0000000000000000 RDI: ffff9208c391d200\n[ 301.562628] RBP: 0000000000000000 R08: ffffba2c0377fab8 R09: 0000000000000000\n[ 301.563145] R10: ffff9208d2292d50 R11: 0000000000000002 R12: 00007fea890e0000\n[ 301.563669] R13: 0000000000000000 R14: ffffba2c0377fc08 R15: 0000000000000000\n[ 301.564186] FS: 0000000000000000(0000) GS:ffff920c2fbc0000(0000) knlGS:0000000000000000\n[ 301.564773] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 301.565197] CR2: 00007fea88ee8a20 CR3: 00000001033a8000 CR4: 0000000000750ef0\n[ 301.565725] PKRU: 55555554\n[ 301.565944] Call Trace:\n[ 301.566148] \u0026lt;TASK\u0026gt;\n[ 301.566325] ? untrack_pfn+0xf4/0x100\n[ 301.566618] ? __warn+0x81/0x130\n[ 301.566876] ? untrack_pfn+0xf4/0x100\n[ 3\n---truncated---(CVE-2024-35877)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nselinux: avoid dereference of garbage after mount failure\r\n\r\nIn case kern_mount() fails and returns an error pointer return in the\nerror branch instead of continuing and dereferencing the error pointer.\r\n\r\nWhile on it drop the never read static variable selinuxfs_mount.(CVE-2024-35904)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nblock: prevent division by zero in blk_rq_stat_sum()\r\n\r\nThe expression dst-\u0026gt;nr_samples + src-\u0026gt;nr_samples may\nhave zero value on overflow. It is necessary to add\na check to avoid division by zero.\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with Svace.(CVE-2024-35925)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/mlx5: Properly link new fs rules into the tree\r\n\r\nPreviously, add_rule_fg would only add newly created rules from the\nhandle into the tree when they had a refcount of 1. On the other hand,\ncreate_flow_handle tries hard to find and reference already existing\nidentical rules instead of creating new ones.\r\n\r\nThese two behaviors can result in a situation where create_flow_handle\n1) creates a new rule and references it, then\n2) in a subsequent step during the same handle creation references it\n again,\nresulting in a rule with a refcount of 2 that is not linked into the\ntree, will have a NULL parent and root and will result in a crash when\nthe flow group is deleted because del_sw_hw_rule, invoked on rule\ndeletion, assumes node-\u0026gt;parent is != NULL.\r\n\r\nThis happened in the wild, due to another bug related to incorrect\nhandling of duplicate pkt_reformat ids, which lead to the code in\ncreate_flow_handle incorrectly referencing a just-added rule in the same\nflow handle, resulting in the problem described above. Full details are\nat [1].\r\n\r\nThis patch changes add_rule_fg to add new rules without parents into\nthe tree, properly initializing them and avoiding the crash. This makes\nit more consistent with how rules are added to an FTE in\ncreate_flow_handle.(CVE-2024-35960)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nBluetooth: Fix memory leak in hci_req_sync_complete()\r\n\r\nIn \u0026apos;hci_req_sync_complete()\u0026apos;, always free the previous sync\nrequest state before assigning reference to a new one.(CVE-2024-35978)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nACPI: CPPC: Use access_width over bit_width for system memory accesses\r\n\r\nTo align with ACPI 6.3+, since bit_width can be any 8-bit value, it\ncannot be depended on to be always on a clean 8b boundary. This was\nuncovered on the Cobalt 100 platform.\r\n\r\nSError Interrupt on CPU26, code 0xbe000011 -- SError\n CPU: 26 PID: 1510 Comm: systemd-udevd Not tainted 5.15.2.1-13 #1\n Hardware name: MICROSOFT CORPORATION, BIOS MICROSOFT CORPORATION\n pstate: 62400009 (nZCv daif +PAN -UAO +TCO -DIT -SSBS BTYPE=--)\n pc : cppc_get_perf_caps+0xec/0x410\n lr : cppc_get_perf_caps+0xe8/0x410\n sp : ffff8000155ab730\n x29: ffff8000155ab730 x28: ffff0080139d0038 x27: ffff0080139d0078\n x26: 0000000000000000 x25: ffff0080139d0058 x24: 00000000ffffffff\n x23: ffff0080139d0298 x22: ffff0080139d0278 x21: 0000000000000000\n x20: ffff00802b251910 x19: ffff0080139d0000 x18: ffffffffffffffff\n x17: 0000000000000000 x16: ffffdc7e111bad04 x15: ffff00802b251008\n x14: ffffffffffffffff x13: ffff013f1fd63300 x12: 0000000000000006\n x11: ffffdc7e128f4420 x10: 0000000000000000 x9 : ffffdc7e111badec\n x8 : ffff00802b251980 x7 : 0000000000000000 x6 : ffff0080139d0028\n x5 : 0000000000000000 x4 : ffff0080139d0018 x3 : 00000000ffffffff\n x2 : 0000000000000008 x1 : ffff8000155ab7a0 x0 : 0000000000000000\n Kernel panic - not syncing: Asynchronous SError Interrupt\n CPU: 26 PID: 1510 Comm: systemd-udevd Not tainted\n5.15.2.1-13 #1\n Hardware name: MICROSOFT CORPORATION, BIOS MICROSOFT CORPORATION\n Call trace:\n dump_backtrace+0x0/0x1e0\n show_stack+0x24/0x30\n dump_stack_lvl+0x8c/0xb8\n dump_stack+0x18/0x34\n panic+0x16c/0x384\n add_taint+0x0/0xc0\n arm64_serror_panic+0x7c/0x90\n arm64_is_fatal_ras_serror+0x34/0xa4\n do_serror+0x50/0x6c\n el1h_64_error_handler+0x40/0x74\n el1h_64_error+0x7c/0x80\n cppc_get_perf_caps+0xec/0x410\n cppc_cpufreq_cpu_init+0x74/0x400 [cppc_cpufreq]\n cpufreq_online+0x2dc/0xa30\n cpufreq_add_dev+0xc0/0xd4\n subsys_interface_register+0x134/0x14c\n cpufreq_register_driver+0x1b0/0x354\n cppc_cpufreq_init+0x1a8/0x1000 [cppc_cpufreq]\n do_one_initcall+0x50/0x250\n do_init_module+0x60/0x27c\n load_module+0x2300/0x2570\n __do_sys_finit_module+0xa8/0x114\n __arm64_sys_finit_module+0x2c/0x3c\n invoke_syscall+0x78/0x100\n el0_svc_common.constprop.0+0x180/0x1a0\n do_el0_svc+0x84/0xa0\n el0_svc+0x2c/0xc0\n el0t_64_sync_handler+0xa4/0x12c\n el0t_64_sync+0x1a4/0x1a8\r\n\r\nInstead, use access_width to determine the size and use the offset and\nwidth to shift and mask the bits to read/write out. Make sure to add a\ncheck for system memory since pcc redefines the access_width to\nsubspace id.\r\n\r\nIf access_width is not set, then fall back to using bit_width.\r\n\r\n[ rjw: Subject and changelog edits, comment adjustments ](CVE-2024-35995)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ni40e: Do not use WQ_MEM_RECLAIM flag for workqueue\r\n\r\nIssue reported by customer during SRIOV testing, call trace:\nWhen both i40e and the i40iw driver are loaded, a warning\nin check_flush_dependency is being triggered. This seems\nto be because of the i40e driver workqueue is allocated with\nthe WQ_MEM_RECLAIM flag, and the i40iw one is not.\r\n\r\nSimilar error was encountered on ice too and it was fixed by\nremoving the flag. Do the same for i40e too.\r\n\r\n[Feb 9 09:08] ------------[ cut here ]------------\n[ +0.000004] workqueue: WQ_MEM_RECLAIM i40e:i40e_service_task [i40e] is\nflushing !WQ_MEM_RECLAIM infiniband:0x0\n[ +0.000060] WARNING: CPU: 0 PID: 937 at kernel/workqueue.c:2966\ncheck_flush_dependency+0x10b/0x120\n[ +0.000007] Modules linked in: snd_seq_dummy snd_hrtimer snd_seq\nsnd_timer snd_seq_device snd soundcore nls_utf8 cifs cifs_arc4\nnls_ucs2_utils rdma_cm iw_cm ib_cm cifs_md4 dns_resolver netfs qrtr\nrfkill sunrpc vfat fat intel_rapl_msr intel_rapl_common irdma\nintel_uncore_frequency intel_uncore_frequency_common ice ipmi_ssif\nisst_if_common skx_edac nfit libnvdimm x86_pkg_temp_thermal\nintel_powerclamp gnss coretemp ib_uverbs rapl intel_cstate ib_core\niTCO_wdt iTCO_vendor_support acpi_ipmi mei_me ipmi_si intel_uncore\nioatdma i2c_i801 joydev pcspkr mei ipmi_devintf lpc_ich\nintel_pch_thermal i2c_smbus ipmi_msghandler acpi_power_meter acpi_pad\nxfs libcrc32c ast sd_mod drm_shmem_helper t10_pi drm_kms_helper sg ixgbe\ndrm i40e ahci crct10dif_pclmul libahci crc32_pclmul igb crc32c_intel\nlibata ghash_clmulni_intel i2c_algo_bit mdio dca wmi dm_mirror\ndm_region_hash dm_log dm_mod fuse\n[ +0.000050] CPU: 0 PID: 937 Comm: kworker/0:3 Kdump: loaded Not\ntainted 6.8.0-rc2-Feb-net_dev-Qiueue-00279-gbd43c5687e05 #1\n[ +0.000003] Hardware name: Intel Corporation S2600BPB/S2600BPB, BIOS\nSE5C620.86B.02.01.0013.121520200651 12/15/2020\n[ +0.000001] Workqueue: i40e i40e_service_task [i40e]\n[ +0.000024] RIP: 0010:check_flush_dependency+0x10b/0x120\n[ +0.000003] Code: ff 49 8b 54 24 18 48 8d 8b b0 00 00 00 49 89 e8 48\n81 c6 b0 00 00 00 48 c7 c7 b0 97 fa 9f c6 05 8a cc 1f 02 01 e8 35 b3 fd\nff \u0026lt;0f\u0026gt; 0b e9 10 ff ff ff 80 3d 78 cc 1f 02 00 75 94 e9 46 ff ff ff 90\n[ +0.000002] RSP: 0018:ffffbd294976bcf8 EFLAGS: 00010282\n[ +0.000002] RAX: 0000000000000000 RBX: ffff94d4c483c000 RCX:\n0000000000000027\n[ +0.000001] RDX: ffff94d47f620bc8 RSI: 0000000000000001 RDI:\nffff94d47f620bc0\n[ +0.000001] RBP: 0000000000000000 R08: 0000000000000000 R09:\n00000000ffff7fff\n[ +0.000001] R10: ffffbd294976bb98 R11: ffffffffa0be65e8 R12:\nffff94c5451ea180\n[ +0.000001] R13: ffff94c5ab5e8000 R14: ffff94c5c20b6e05 R15:\nffff94c5f1330ab0\n[ +0.000001] FS: 0000000000000000(0000) GS:ffff94d47f600000(0000)\nknlGS:0000000000000000\n[ +0.000002] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ +0.000001] CR2: 00007f9e6f1fca70 CR3: 0000000038e20004 CR4:\n00000000007706f0\n[ +0.000000] DR0: 0000000000000000 DR1: 0000000000000000 DR2:\n0000000000000000\n[ +0.000001] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:\n0000000000000400\n[ +0.000001] PKRU: 55555554\n[ +0.000001] Call Trace:\n[ +0.000001] \u0026lt;TASK\u0026gt;\n[ +0.000002] ? __warn+0x80/0x130\n[ +0.000003] ? check_flush_dependency+0x10b/0x120\n[ +0.000002] ? report_bug+0x195/0x1a0\n[ +0.000005] ? handle_bug+0x3c/0x70\n[ +0.000003] ? exc_invalid_op+0x14/0x70\n[ +0.000002] ? asm_exc_invalid_op+0x16/0x20\n[ +0.000006] ? check_flush_dependency+0x10b/0x120\n[ +0.000002] ? check_flush_dependency+0x10b/0x120\n[ +0.000002] __flush_workqueue+0x126/0x3f0\n[ +0.000015] ib_cache_cleanup_one+0x1c/0xe0 [ib_core]\n[ +0.000056] __ib_unregister_device+0x6a/0xb0 [ib_core]\n[ +0.000023] ib_unregister_device_and_put+0x34/0x50 [ib_core]\n[ +0.000020] i40iw_close+0x4b/0x90 [irdma]\n[ +0.000022] i40e_notify_client_of_netdev_close+0x54/0xc0 [i40e]\n[ +0.000035] i40e_service_task+0x126/0x190 [i40e]\n[ +0.000024] process_one_work+0x174/0x340\n[ +0.000003] worker_th\n---truncated---(CVE-2024-36004)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nppdev: Add an error check in register_device\r\n\r\nIn register_device, the return value of ida_simple_get is unchecked,\nin witch ida_simple_get will use an invalid index value.\r\n\r\nTo address this issue, index should be checked after ida_simple_get. When\nthe index value is abnormal, a warning message should be printed, the port\nshould be dropped, and the value should be recorded.(CVE-2024-36015)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npinctrl: core: delete incorrect free in pinctrl_enable()\r\n\r\nThe \u0026quot;pctldev\u0026quot; struct is allocated in devm_pinctrl_register_and_init().\nIt\u0026apos;s a devm_ managed pointer that is freed by devm_pinctrl_dev_release(),\nso freeing it in pinctrl_enable() will lead to a double free.\r\n\r\nThe devm_pinctrl_dev_release() function frees the pindescs and destroys\nthe mutex as well.(CVE-2024-36940)",
"id": "OESA-2024-1692",
"modified": "2026-08-06T11:07:09Z",
"published": "2024-06-07T11:07:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1692"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47239"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47265"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47275"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47277"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47297"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47314"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47323"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47330"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47350"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47353"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47355"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47356"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47357"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47361"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47362"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47388"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47395"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47397"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47401"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47404"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47405"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47408"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47423"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47427"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47438"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47442"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47443"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47445"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47458"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47459"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47475"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47477"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47495"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47545"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47548"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47549"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47559"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48708"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52669"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52693"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52699"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52703"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52750"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52752"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52759"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52789"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52796"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52799"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52802"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52804"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52805"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52809"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52819"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52831"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52832"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52845"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52878"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26934"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27020"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27399"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27401"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35789"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35808"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35822"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35823"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35877"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35904"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35925"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35960"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35978"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35995"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36004"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36015"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36940"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2021-47239",
"CVE-2021-47265",
"CVE-2021-47275",
"CVE-2021-47277",
"CVE-2021-47297",
"CVE-2021-47314",
"CVE-2021-47323",
"CVE-2021-47330",
"CVE-2021-47350",
"CVE-2021-47353",
"CVE-2021-47355",
"CVE-2021-47356",
"CVE-2021-47357",
"CVE-2021-47361",
"CVE-2021-47362",
"CVE-2021-47388",
"CVE-2021-47395",
"CVE-2021-47397",
"CVE-2021-47401",
"CVE-2021-47404",
"CVE-2021-47405",
"CVE-2021-47408",
"CVE-2021-47423",
"CVE-2021-47427",
"CVE-2021-47438",
"CVE-2021-47442",
"CVE-2021-47443",
"CVE-2021-47445",
"CVE-2021-47458",
"CVE-2021-47459",
"CVE-2021-47475",
"CVE-2021-47477",
"CVE-2021-47495",
"CVE-2021-47545",
"CVE-2021-47548",
"CVE-2021-47549",
"CVE-2021-47559",
"CVE-2022-48708",
"CVE-2023-52669",
"CVE-2023-52693",
"CVE-2023-52699",
"CVE-2023-52703",
"CVE-2023-52750",
"CVE-2023-52752",
"CVE-2023-52759",
"CVE-2023-52789",
"CVE-2023-52796",
"CVE-2023-52799",
"CVE-2023-52802",
"CVE-2023-52804",
"CVE-2023-52805",
"CVE-2023-52809",
"CVE-2023-52819",
"CVE-2023-52831",
"CVE-2023-52832",
"CVE-2023-52845",
"CVE-2023-52878",
"CVE-2024-26934",
"CVE-2024-27020",
"CVE-2024-27399",
"CVE-2024-27401",
"CVE-2024-35789",
"CVE-2024-35808",
"CVE-2024-35822",
"CVE-2024-35823",
"CVE-2024-35877",
"CVE-2024-35904",
"CVE-2024-35925",
"CVE-2024-35960",
"CVE-2024-35978",
"CVE-2024-35995",
"CVE-2024-36004",
"CVE-2024-36015",
"CVE-2024-36940"
]
}
RHSA-2024:4928
Vulnerability from csaf_redhat - Published: 2024-07-31 00:54 - Updated: 2026-08-19 17:33In the Linux kernel, the following vulnerability has been resolved: scsi: libfc: Fix potential NULL pointer dereference in fc_lport_ptp_setup() fc_lport_ptp_setup() did not check the return value of fc_rport_create() which can return NULL and would cause a NULL pointer dereference. Address this issue by checking return value of fc_rport_create() and log error message on fc_rport_create() failed.
RHSA-2024:5066
Vulnerability from csaf_redhat - Published: 2024-08-07 09:43 - Updated: 2026-08-18 14:31In the Linux kernel, the following vulnerability has been resolved: scsi: libfc: Fix potential NULL pointer dereference in fc_lport_ptp_setup() fc_lport_ptp_setup() did not check the return value of fc_rport_create() which can return NULL and would cause a NULL pointer dereference. Address this issue by checking return value of fc_rport_create() and log error message on fc_rport_create() failed.
RHSA-2024:5067
Vulnerability from csaf_redhat - Published: 2024-08-07 00:14 - Updated: 2026-08-18 14:31In the Linux kernel, the following vulnerability has been resolved: scsi: libfc: Fix potential NULL pointer dereference in fc_lport_ptp_setup() fc_lport_ptp_setup() did not check the return value of fc_rport_create() which can return NULL and would cause a NULL pointer dereference. Address this issue by checking return value of fc_rport_create() and log error message on fc_rport_create() failed.
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.