Action not permitted
Modal body text goes here.
Modal Title
Modal Body
CVE-2023-52868 (GCVE-0-2023-52868)
Vulnerability from cvelistv5 – Published: 2024-05-21 15:31 – Updated: 2026-05-11 19:34| Vendor | Product | Version | CPE status | |
|---|---|---|---|---|
| Linux | Linux |
Affected:
203d3d4aa482339b4816f131f713e1b8ee37f6dd , < b55f0a9f865be75ca1019aad331f3225f7b50ce8
(git)
Affected: 203d3d4aa482339b4816f131f713e1b8ee37f6dd , < 6ad1bf47fbe5750c4d5d8e41337665e193e2c521 (git) Affected: 203d3d4aa482339b4816f131f713e1b8ee37f6dd , < 3091ab943dfc7b2578599b0fe203350286fab5bb (git) Affected: 203d3d4aa482339b4816f131f713e1b8ee37f6dd , < 3f795fb35c2d8a637efe76b4518216c9319b998c (git) Affected: 203d3d4aa482339b4816f131f713e1b8ee37f6dd , < 3a8f4e58e1ee707b4f46a1000b40b86ea3dd509c (git) Affected: 203d3d4aa482339b4816f131f713e1b8ee37f6dd , < 77ff34a56b695e228e6daf30ee30be747973d6e8 (git) Affected: 203d3d4aa482339b4816f131f713e1b8ee37f6dd , < 0f6b3be28c4d62ef6498133959c72266629bea97 (git) Affected: 203d3d4aa482339b4816f131f713e1b8ee37f6dd , < edbd6bbe40ac524a8f2273ffacc53edf14f3c686 (git) Affected: 203d3d4aa482339b4816f131f713e1b8ee37f6dd , < c99626092efca3061b387043d4a7399bf75fbdd5 (git) |
guessed | |
| Linux | Linux |
Affected:
2.6.25
Unaffected: 0 , < 2.6.25 (semver) Unaffected: 4.14.330 , ≤ 4.14.* (semver) Unaffected: 4.19.299 , ≤ 4.19.* (semver) Unaffected: 5.4.261 , ≤ 5.4.* (semver) Unaffected: 5.10.201 , ≤ 5.10.* (semver) Unaffected: 5.15.139 , ≤ 5.15.* (semver) Unaffected: 6.1.63 , ≤ 6.1.* (semver) Unaffected: 6.5.12 , ≤ 6.5.* (semver) Unaffected: 6.6.2 , ≤ 6.6.* (semver) Unaffected: 6.7 , ≤ * (original_commit_for_fix) |
guessed |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2023-52868",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2024-05-24T19:32:21.368633Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2024-06-04T17:24:15.357Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
},
{
"providerMetadata": {
"dateUpdated": "2024-08-02T23:11:36.044Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/b55f0a9f865be75ca1019aad331f3225f7b50ce8"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/6ad1bf47fbe5750c4d5d8e41337665e193e2c521"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/3091ab943dfc7b2578599b0fe203350286fab5bb"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/3f795fb35c2d8a637efe76b4518216c9319b998c"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/3a8f4e58e1ee707b4f46a1000b40b86ea3dd509c"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/77ff34a56b695e228e6daf30ee30be747973d6e8"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/0f6b3be28c4d62ef6498133959c72266629bea97"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/edbd6bbe40ac524a8f2273ffacc53edf14f3c686"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/c99626092efca3061b387043d4a7399bf75fbdd5"
}
],
"title": "CVE Program Container"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/thermal/thermal_core.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "b55f0a9f865be75ca1019aad331f3225f7b50ce8",
"status": "affected",
"version": "203d3d4aa482339b4816f131f713e1b8ee37f6dd",
"versionType": "git"
},
{
"lessThan": "6ad1bf47fbe5750c4d5d8e41337665e193e2c521",
"status": "affected",
"version": "203d3d4aa482339b4816f131f713e1b8ee37f6dd",
"versionType": "git"
},
{
"lessThan": "3091ab943dfc7b2578599b0fe203350286fab5bb",
"status": "affected",
"version": "203d3d4aa482339b4816f131f713e1b8ee37f6dd",
"versionType": "git"
},
{
"lessThan": "3f795fb35c2d8a637efe76b4518216c9319b998c",
"status": "affected",
"version": "203d3d4aa482339b4816f131f713e1b8ee37f6dd",
"versionType": "git"
},
{
"lessThan": "3a8f4e58e1ee707b4f46a1000b40b86ea3dd509c",
"status": "affected",
"version": "203d3d4aa482339b4816f131f713e1b8ee37f6dd",
"versionType": "git"
},
{
"lessThan": "77ff34a56b695e228e6daf30ee30be747973d6e8",
"status": "affected",
"version": "203d3d4aa482339b4816f131f713e1b8ee37f6dd",
"versionType": "git"
},
{
"lessThan": "0f6b3be28c4d62ef6498133959c72266629bea97",
"status": "affected",
"version": "203d3d4aa482339b4816f131f713e1b8ee37f6dd",
"versionType": "git"
},
{
"lessThan": "edbd6bbe40ac524a8f2273ffacc53edf14f3c686",
"status": "affected",
"version": "203d3d4aa482339b4816f131f713e1b8ee37f6dd",
"versionType": "git"
},
{
"lessThan": "c99626092efca3061b387043d4a7399bf75fbdd5",
"status": "affected",
"version": "203d3d4aa482339b4816f131f713e1b8ee37f6dd",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/thermal/thermal_core.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "2.6.25"
},
{
"lessThan": "2.6.25",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "4.14.*",
"status": "unaffected",
"version": "4.14.330",
"versionType": "semver"
},
{
"lessThanOrEqual": "4.19.*",
"status": "unaffected",
"version": "4.19.299",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.261",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.201",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.139",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.63",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.5.*",
"status": "unaffected",
"version": "6.5.12",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.2",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.7",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "4.14.330",
"versionStartIncluding": "2.6.25",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "4.19.299",
"versionStartIncluding": "2.6.25",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.4.261",
"versionStartIncluding": "2.6.25",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.10.201",
"versionStartIncluding": "2.6.25",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.15.139",
"versionStartIncluding": "2.6.25",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.1.63",
"versionStartIncluding": "2.6.25",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.5.12",
"versionStartIncluding": "2.6.25",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6.2",
"versionStartIncluding": "2.6.25",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.7",
"versionStartIncluding": "2.6.25",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nthermal: core: prevent potential string overflow\n\nThe dev-\u003eid value comes from ida_alloc() so it\u0027s a number between zero\nand INT_MAX. If it\u0027s too high then these sprintf()s will overflow."
}
],
"providerMetadata": {
"dateUpdated": "2026-05-11T19:34:34.837Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/b55f0a9f865be75ca1019aad331f3225f7b50ce8"
},
{
"url": "https://git.kernel.org/stable/c/6ad1bf47fbe5750c4d5d8e41337665e193e2c521"
},
{
"url": "https://git.kernel.org/stable/c/3091ab943dfc7b2578599b0fe203350286fab5bb"
},
{
"url": "https://git.kernel.org/stable/c/3f795fb35c2d8a637efe76b4518216c9319b998c"
},
{
"url": "https://git.kernel.org/stable/c/3a8f4e58e1ee707b4f46a1000b40b86ea3dd509c"
},
{
"url": "https://git.kernel.org/stable/c/77ff34a56b695e228e6daf30ee30be747973d6e8"
},
{
"url": "https://git.kernel.org/stable/c/0f6b3be28c4d62ef6498133959c72266629bea97"
},
{
"url": "https://git.kernel.org/stable/c/edbd6bbe40ac524a8f2273ffacc53edf14f3c686"
},
{
"url": "https://git.kernel.org/stable/c/c99626092efca3061b387043d4a7399bf75fbdd5"
}
],
"title": "thermal: core: prevent potential string overflow",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2023-52868",
"datePublished": "2024-05-21T15:31:58.530Z",
"dateReserved": "2024-05-21T15:19:24.263Z",
"dateUpdated": "2026-05-11T19:34:34.837Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"epss": {
"cve": "CVE-2023-52868",
"date": "2026-09-30",
"epss": "0.00236",
"percentile": "0.1324"
},
"fkie_nvd": {
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nthermal: core: prevent potential string overflow\n\nThe dev-\u003eid value comes from ida_alloc() so it\u0027s a number between zero\nand INT_MAX. If it\u0027s too high then these sprintf()s will overflow."
},
{
"lang": "es",
"value": " En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: t\u00e9rmica: n\u00facleo: evita un posible desbordamiento de cadenas. El valor dev-\u0026gt;id proviene de ida_alloc(), por lo que es un n\u00famero entre cero e INT_MAX. Si es demasiado alto, estos sprintf()s se desbordar\u00e1n."
}
],
"id": "CVE-2023-52868",
"lastModified": "2024-11-21T08:40:45.563",
"published": "2024-05-21T16:15:23.673",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/0f6b3be28c4d62ef6498133959c72266629bea97"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/3091ab943dfc7b2578599b0fe203350286fab5bb"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/3a8f4e58e1ee707b4f46a1000b40b86ea3dd509c"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/3f795fb35c2d8a637efe76b4518216c9319b998c"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/6ad1bf47fbe5750c4d5d8e41337665e193e2c521"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/77ff34a56b695e228e6daf30ee30be747973d6e8"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/b55f0a9f865be75ca1019aad331f3225f7b50ce8"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/c99626092efca3061b387043d4a7399bf75fbdd5"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/edbd6bbe40ac524a8f2273ffacc53edf14f3c686"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"url": "https://git.kernel.org/stable/c/0f6b3be28c4d62ef6498133959c72266629bea97"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"url": "https://git.kernel.org/stable/c/3091ab943dfc7b2578599b0fe203350286fab5bb"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"url": "https://git.kernel.org/stable/c/3a8f4e58e1ee707b4f46a1000b40b86ea3dd509c"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"url": "https://git.kernel.org/stable/c/3f795fb35c2d8a637efe76b4518216c9319b998c"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"url": "https://git.kernel.org/stable/c/6ad1bf47fbe5750c4d5d8e41337665e193e2c521"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"url": "https://git.kernel.org/stable/c/77ff34a56b695e228e6daf30ee30be747973d6e8"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"url": "https://git.kernel.org/stable/c/b55f0a9f865be75ca1019aad331f3225f7b50ce8"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"url": "https://git.kernel.org/stable/c/c99626092efca3061b387043d4a7399bf75fbdd5"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"url": "https://git.kernel.org/stable/c/edbd6bbe40ac524a8f2273ffacc53edf14f3c686"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Awaiting Analysis"
},
"nvd": {
"cve": {
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/thermal/thermal_core.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "b55f0a9f865be75ca1019aad331f3225f7b50ce8",
"status": "affected",
"version": "203d3d4aa482339b4816f131f713e1b8ee37f6dd",
"versionType": "git"
},
{
"lessThan": "6ad1bf47fbe5750c4d5d8e41337665e193e2c521",
"status": "affected",
"version": "203d3d4aa482339b4816f131f713e1b8ee37f6dd",
"versionType": "git"
},
{
"lessThan": "3091ab943dfc7b2578599b0fe203350286fab5bb",
"status": "affected",
"version": "203d3d4aa482339b4816f131f713e1b8ee37f6dd",
"versionType": "git"
},
{
"lessThan": "3f795fb35c2d8a637efe76b4518216c9319b998c",
"status": "affected",
"version": "203d3d4aa482339b4816f131f713e1b8ee37f6dd",
"versionType": "git"
},
{
"lessThan": "3a8f4e58e1ee707b4f46a1000b40b86ea3dd509c",
"status": "affected",
"version": "203d3d4aa482339b4816f131f713e1b8ee37f6dd",
"versionType": "git"
},
{
"lessThan": "77ff34a56b695e228e6daf30ee30be747973d6e8",
"status": "affected",
"version": "203d3d4aa482339b4816f131f713e1b8ee37f6dd",
"versionType": "git"
},
{
"lessThan": "0f6b3be28c4d62ef6498133959c72266629bea97",
"status": "affected",
"version": "203d3d4aa482339b4816f131f713e1b8ee37f6dd",
"versionType": "git"
},
{
"lessThan": "edbd6bbe40ac524a8f2273ffacc53edf14f3c686",
"status": "affected",
"version": "203d3d4aa482339b4816f131f713e1b8ee37f6dd",
"versionType": "git"
},
{
"lessThan": "c99626092efca3061b387043d4a7399bf75fbdd5",
"status": "affected",
"version": "203d3d4aa482339b4816f131f713e1b8ee37f6dd",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/thermal/thermal_core.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "2.6.25"
},
{
"lessThan": "2.6.25",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "4.14.*",
"status": "unaffected",
"version": "4.14.330",
"versionType": "semver"
},
{
"lessThanOrEqual": "4.19.*",
"status": "unaffected",
"version": "4.19.299",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.261",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.201",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.139",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.63",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.5.*",
"status": "unaffected",
"version": "6.5.12",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.2",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.7",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"configurations": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "D1A3B79F-7F06-4FD1-A81B-5143491DB306",
"versionEndExcluding": "4.14.330",
"versionStartIncluding": "2.6.25",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "F51D1457-86F8-4A6C-A7B9-323058B3C5E8",
"versionEndExcluding": "4.19.299",
"versionStartIncluding": "4.15",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "286E50BB-5A21-49BA-A6E5-526C72ADFE34",
"versionEndExcluding": "5.4.261",
"versionStartIncluding": "4.20",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "AF1ADC4E-CCC4-498A-876F-5136DDD36C1D",
"versionEndExcluding": "5.10.201",
"versionStartIncluding": "5.5",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "81424D14-B38F-47B3-A1B8-BC3B60BB96EA",
"versionEndExcluding": "5.15.139",
"versionStartIncluding": "5.11",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "80E1EA7E-2788-466C-9FFB-34AFA1B052F0",
"versionEndExcluding": "6.1.63",
"versionStartIncluding": "5.16",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "825F64D9-E99F-49AA-8A7B-EF7C2965C5B2",
"versionEndExcluding": "6.5.12",
"versionStartIncluding": "6.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "4CBFF885-A4D3-4F21-B6FD-4D770034C048",
"versionEndExcluding": "6.6.2",
"versionStartIncluding": "6.6",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nthermal: core: prevent potential string overflow\n\nThe dev-\u003eid value comes from ida_alloc() so it\u0027s a number between zero\nand INT_MAX. If it\u0027s too high then these sprintf()s will overflow."
},
{
"lang": "es",
"value": " En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: t\u00e9rmica: n\u00facleo: evita un posible desbordamiento de cadenas. El valor dev-\u0026gt;id proviene de ida_alloc(), por lo que es un n\u00famero entre cero e INT_MAX. Si es demasiado alto, estos sprintf()s se desbordar\u00e1n."
}
],
"id": "CVE-2023-52868",
"lastModified": "2026-06-17T06:43:46.650",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 7.8,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 5.9,
"source": "nvd@nist.gov",
"type": "Primary"
}
],
"ssvcV203": [
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"ssvcData": {
"id": "CVE-2023-52868",
"options": [
{
"exploitation": "none"
},
{
"automatable": "no"
},
{
"technicalImpact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2024-05-24T19:32:21.368633Z",
"version": "2.0.3"
}
}
]
},
"published": "2024-05-21T16:15:23.673",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/0f6b3be28c4d62ef6498133959c72266629bea97"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/3091ab943dfc7b2578599b0fe203350286fab5bb"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/3a8f4e58e1ee707b4f46a1000b40b86ea3dd509c"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/3f795fb35c2d8a637efe76b4518216c9319b998c"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/6ad1bf47fbe5750c4d5d8e41337665e193e2c521"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/77ff34a56b695e228e6daf30ee30be747973d6e8"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/b55f0a9f865be75ca1019aad331f3225f7b50ce8"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/c99626092efca3061b387043d4a7399bf75fbdd5"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/edbd6bbe40ac524a8f2273ffacc53edf14f3c686"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/0f6b3be28c4d62ef6498133959c72266629bea97"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/3091ab943dfc7b2578599b0fe203350286fab5bb"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/3a8f4e58e1ee707b4f46a1000b40b86ea3dd509c"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/3f795fb35c2d8a637efe76b4518216c9319b998c"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/6ad1bf47fbe5750c4d5d8e41337665e193e2c521"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/77ff34a56b695e228e6daf30ee30be747973d6e8"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/b55f0a9f865be75ca1019aad331f3225f7b50ce8"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/c99626092efca3061b387043d4a7399bf75fbdd5"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/edbd6bbe40ac524a8f2273ffacc53edf14f3c686"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Analyzed",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "CWE-787"
}
],
"source": "nvd@nist.gov",
"type": "Primary"
}
]
}
},
"redhat_vex": {
"aggregate_severity": "Low",
"current_release_date": "2025-11-21T10:49:21+00:00",
"cve": "CVE-2023-52868",
"id": "CVE-2023-52868",
"initial_release_date": "2023-01-01T00:00:00+00:00",
"product_status:known_not_affected": "198",
"source": "Red Hat CSAF VEX",
"status": "final",
"title": "kernel: thermal: core: prevent potential string overflow",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2023/cve-2023-52868.json",
"version": "3"
},
"suse_vex": {
"aggregate_severity": "moderate",
"current_release_date": "2026-09-03T16:49:50Z",
"cve": "CVE-2023-52868",
"id": "CVE-2023-52868",
"initial_release_date": "2024-05-23T02:56:35Z",
"product_status:known_affected": "518",
"product_status:known_not_affected": "61",
"product_status:recommended": "842",
"source": "SUSE CSAF VEX",
"status": "interim",
"title": "SUSE CVE CVE-2023-52868",
"url": "https://ftp.suse.com/pub/projects/security/csaf-vex/cve-2023-52868.json",
"version": "105"
},
"vulnrichment": {
"containers": {
"adp": [
{
"providerMetadata": {
"dateUpdated": "2024-08-02T23:11:36.044Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/b55f0a9f865be75ca1019aad331f3225f7b50ce8"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/6ad1bf47fbe5750c4d5d8e41337665e193e2c521"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/3091ab943dfc7b2578599b0fe203350286fab5bb"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/3f795fb35c2d8a637efe76b4518216c9319b998c"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/3a8f4e58e1ee707b4f46a1000b40b86ea3dd509c"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/77ff34a56b695e228e6daf30ee30be747973d6e8"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/0f6b3be28c4d62ef6498133959c72266629bea97"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/edbd6bbe40ac524a8f2273ffacc53edf14f3c686"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/c99626092efca3061b387043d4a7399bf75fbdd5"
}
],
"title": "CVE Program Container"
},
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2023-52868",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2024-05-24T19:32:21.368633Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2024-05-24T19:32:24.873Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/thermal/thermal_core.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "b55f0a9f865b",
"status": "affected",
"version": "203d3d4aa482",
"versionType": "git"
},
{
"lessThan": "6ad1bf47fbe5",
"status": "affected",
"version": "203d3d4aa482",
"versionType": "git"
},
{
"lessThan": "3091ab943dfc",
"status": "affected",
"version": "203d3d4aa482",
"versionType": "git"
},
{
"lessThan": "3f795fb35c2d",
"status": "affected",
"version": "203d3d4aa482",
"versionType": "git"
},
{
"lessThan": "3a8f4e58e1ee",
"status": "affected",
"version": "203d3d4aa482",
"versionType": "git"
},
{
"lessThan": "77ff34a56b69",
"status": "affected",
"version": "203d3d4aa482",
"versionType": "git"
},
{
"lessThan": "0f6b3be28c4d",
"status": "affected",
"version": "203d3d4aa482",
"versionType": "git"
},
{
"lessThan": "edbd6bbe40ac",
"status": "affected",
"version": "203d3d4aa482",
"versionType": "git"
},
{
"lessThan": "c99626092efc",
"status": "affected",
"version": "203d3d4aa482",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/thermal/thermal_core.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "2.6.25"
},
{
"lessThan": "2.6.25",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "4.14.*",
"status": "unaffected",
"version": "4.14.330",
"versionType": "semver"
},
{
"lessThanOrEqual": "4.19.*",
"status": "unaffected",
"version": "4.19.299",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.261",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.201",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.139",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.63",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.5.*",
"status": "unaffected",
"version": "6.5.12",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.2",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.7",
"versionType": "original_commit_for_fix"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nthermal: core: prevent potential string overflow\n\nThe dev-\u003eid value comes from ida_alloc() so it\u0027s a number between zero\nand INT_MAX. If it\u0027s too high then these sprintf()s will overflow."
}
],
"providerMetadata": {
"dateUpdated": "2024-11-04T14:54:13.301Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/b55f0a9f865be75ca1019aad331f3225f7b50ce8"
},
{
"url": "https://git.kernel.org/stable/c/6ad1bf47fbe5750c4d5d8e41337665e193e2c521"
},
{
"url": "https://git.kernel.org/stable/c/3091ab943dfc7b2578599b0fe203350286fab5bb"
},
{
"url": "https://git.kernel.org/stable/c/3f795fb35c2d8a637efe76b4518216c9319b998c"
},
{
"url": "https://git.kernel.org/stable/c/3a8f4e58e1ee707b4f46a1000b40b86ea3dd509c"
},
{
"url": "https://git.kernel.org/stable/c/77ff34a56b695e228e6daf30ee30be747973d6e8"
},
{
"url": "https://git.kernel.org/stable/c/0f6b3be28c4d62ef6498133959c72266629bea97"
},
{
"url": "https://git.kernel.org/stable/c/edbd6bbe40ac524a8f2273ffacc53edf14f3c686"
},
{
"url": "https://git.kernel.org/stable/c/c99626092efca3061b387043d4a7399bf75fbdd5"
}
],
"title": "thermal: core: prevent potential string overflow",
"x_generator": {
"engine": "bippy-9e1c9544281a"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2023-52868",
"datePublished": "2024-05-21T15:31:58.530Z",
"dateReserved": "2024-05-21T15:19:24.263Z",
"dateUpdated": "2024-11-04T14:54:13.301Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.1"
}
}
}
OESA-2024-1678 (CVE-2021-47269)
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:
usb: dwc3: ep0: fix NULL pointer exception
There is no validation of the index from dwc3_wIndex_to_dep() and we might be referring a non-existing ep and trigger a NULL pointer exception. In certain configurations we might use fewer eps and the index might wrongly indicate a larger ep index than existing.
By adding this validation from the patch we can actually report a wrong index back to the caller.
In our usecase we are using a composite device on an older kernel, but upstream might use this fix also. Unfortunately, I cannot describe the hardware for others to reproduce the issue as it is a proprietary implementation.
[ 82.958261] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a4 [ 82.966891] Mem abort info: [ 82.969663] ESR = 0x96000006 [ 82.972703] Exception class = DABT (current EL), IL = 32 bits [ 82.978603] SET = 0, FnV = 0 [ 82.981642] EA = 0, S1PTW = 0 [ 82.984765] Data abort info: [ 82.987631] ISV = 0, ISS = 0x00000006 [ 82.991449] CM = 0, WnR = 0 [ 82.994409] user pgtable: 4k pages, 39-bit VAs, pgdp = 00000000c6210ccc [ 83.000999] [00000000000000a4] pgd=0000000053aa5003, pud=0000000053aa5003, pmd=0000000000000000 [ 83.009685] Internal error: Oops: 96000006 [#1] PREEMPT SMP [ 83.026433] Process irq/62-dwc3 (pid: 303, stack limit = 0x000000003985154c) [ 83.033470] CPU: 0 PID: 303 Comm: irq/62-dwc3 Not tainted 4.19.124 #1 [ 83.044836] pstate: 60000085 (nZCv daIf -PAN -UAO) [ 83.049628] pc : dwc3_ep0_handle_feature+0x414/0x43c [ 83.054558] lr : dwc3_ep0_interrupt+0x3b4/0xc94
...
[ 83.141788] Call trace: [ 83.144227] dwc3_ep0_handle_feature+0x414/0x43c [ 83.148823] dwc3_ep0_interrupt+0x3b4/0xc94 [ 83.181546] ---[ end trace aac6b5267d84c32f ]---(CVE-2021-47269)
In the Linux kernel, the following vulnerability has been resolved:
isdn: mISDN: netjet: Fix crash in nj_probe:
'nj_setup' in netjet.c might fail with -EIO and in this case 'card->irq' is initialized and is bigger than zero. A subsequent call to 'nj_release' will free the irq that has not been requested.
Fix this bug by deleting the previous assignment to 'card->irq' and just keep the assignment before 'request_irq'.
The KASAN's log reveals it:
[ 3.354615 ] WARNING: CPU: 0 PID: 1 at kernel/irq/manage.c:1826 free_irq+0x100/0x480 [ 3.355112 ] Modules linked in: [ 3.355310 ] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.13.0-rc1-00144-g25a1298726e #13 [ 3.355816 ] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014 [ 3.356552 ] RIP: 0010:free_irq+0x100/0x480 [ 3.356820 ] Code: 6e 08 74 6f 4d 89 f4 e8 5e ac 09 00 4d 8b 74 24 18 4d 85 f6 75 e3 e8 4f ac 09 00 8b 75 c8 48 c7 c7 78 c1 2e 85 e8 e0 cf f5 ff <0f> 0b 48 8b 75 c0 4c 89 ff e8 72 33 0b 03 48 8b 43 40 4c 8b a0 80 [ 3.358012 ] RSP: 0000:ffffc90000017b48 EFLAGS: 00010082 [ 3.358357 ] RAX: 0000000000000000 RBX: ffff888104dc8000 RCX: 0000000000000000 [ 3.358814 ] RDX: ffff8881003c8000 RSI: ffffffff8124a9e6 RDI: 00000000ffffffff [ 3.359272 ] RBP: ffffc90000017b88 R08: 0000000000000000 R09: 0000000000000000 [ 3.359732 ] R10: ffffc900000179f0 R11: 0000000000001d04 R12: 0000000000000000 [ 3.360195 ] R13: ffff888107dc6000 R14: ffff888107dc6928 R15: ffff888104dc80a8 [ 3.360652 ] FS: 0000000000000000(0000) GS:ffff88817bc00000(0000) knlGS:0000000000000000 [ 3.361170 ] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 3.361538 ] CR2: 0000000000000000 CR3: 000000000582e000 CR4: 00000000000006f0 [ 3.362003 ] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 3.362175 ] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 3.362175 ] Call Trace: [ 3.362175 ] nj_release+0x51/0x1e0 [ 3.362175 ] nj_probe+0x450/0x950 [ 3.362175 ] ? pci_device_remove+0x110/0x110 [ 3.362175 ] local_pci_probe+0x45/0xa0 [ 3.362175 ] pci_device_probe+0x12b/0x1d0 [ 3.362175 ] really_probe+0x2a9/0x610 [ 3.362175 ] driver_probe_device+0x90/0x1d0 [ 3.362175 ] ? mutex_lock_nested+0x1b/0x20 [ 3.362175 ] device_driver_attach+0x68/0x70 [ 3.362175 ] __driver_attach+0x124/0x1b0 [ 3.362175 ] ? device_driver_attach+0x70/0x70 [ 3.362175 ] bus_for_each_dev+0xbb/0x110 [ 3.362175 ] ? rdinit_setup+0x45/0x45 [ 3.362175 ] driver_attach+0x27/0x30 [ 3.362175 ] bus_add_driver+0x1eb/0x2a0 [ 3.362175 ] driver_register+0xa9/0x180 [ 3.362175 ] __pci_register_driver+0x82/0x90 [ 3.362175 ] ? w6692_init+0x38/0x38 [ 3.362175 ] nj_init+0x36/0x38 [ 3.362175 ] do_one_initcall+0x7f/0x3d0 [ 3.362175 ] ? rdinit_setup+0x45/0x45 [ 3.362175 ] ? rcu_read_lock_sched_held+0x4f/0x80 [ 3.362175 ] kernel_init_freeable+0x2aa/0x301 [ 3.362175 ] ? rest_init+0x2c0/0x2c0 [ 3.362175 ] kernel_init+0x18/0x190 [ 3.362175 ] ? rest_init+0x2c0/0x2c0 [ 3.362175 ] ? rest_init+0x2c0/0x2c0 [ 3.362175 ] ret_from_fork+0x1f/0x30 [ 3.362175 ] Kernel panic - not syncing: panic_on_warn set ... [ 3.362175 ] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.13.0-rc1-00144-g25a1298726e #13 [ 3.362175 ] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014 [ 3.362175 ] Call Trace: [ 3.362175 ] dump_stack+0xba/0xf5 [ 3.362175 ] ? free_irq+0x100/0x480 [ 3.362175 ] panic+0x15a/0x3f2 [ 3.362175 ] ? __warn+0xf2/0x150 [ 3.362175 ] ? free_irq+0x100/0x480 [ 3.362175 ] __warn+0x108/0x150 [ 3.362175 ] ? free_irq+0x100/0x480 [ 3.362175 ] report_bug+0x119/0x1c0 [ 3.362175 ] handle_bug+0x3b/0x80 [ 3.362175 ] exc_invalid_op+0x18/0x70 [ 3.362175 ] asm_exc_invalid_op+0x12/0x20 [ 3.362175 ] RIP: 0010:free_irq+0x100 ---truncated---(CVE-2021-47284)
In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to avoid racing on fsync_entry_slab by multi filesystem instances
As syzbot reported, there is an use-after-free issue during f2fs recovery:
Use-after-free write at 0xffff88823bc16040 (in kfence-#10): kmem_cache_destroy+0x1f/0x120 mm/slab_common.c:486 f2fs_recover_fsync_data+0x75b0/0x8380 fs/f2fs/recovery.c:869 f2fs_fill_super+0x9393/0xa420 fs/f2fs/super.c:3945 mount_bdev+0x26c/0x3a0 fs/super.c:1367 legacy_get_tree+0xea/0x180 fs/fs_context.c:592 vfs_get_tree+0x86/0x270 fs/super.c:1497 do_new_mount fs/namespace.c:2905 [inline] path_mount+0x196f/0x2be0 fs/namespace.c:3235 do_mount fs/namespace.c:3248 [inline] __do_sys_mount fs/namespace.c:3456 [inline] __se_sys_mount+0x2f9/0x3b0 fs/namespace.c:3433 do_syscall_64+0x3f/0xb0 arch/x86/entry/common.c:47 entry_SYSCALL_64_after_hwframe+0x44/0xae
The root cause is multi f2fs filesystem instances can race on accessing global fsync_entry_slab pointer, result in use-after-free issue of slab cache, fixes to init/destroy this slab cache only once during module init/destroy procedure to avoid this issue.(CVE-2021-47335)
In the Linux kernel, the following vulnerability has been resolved:
hwmon: (mlxreg-fan) Return non-zero value when fan current state is enforced from sysfs
Fan speed minimum can be enforced from sysfs. For example, setting current fan speed to 20 is used to enforce fan speed to be at 100% speed, 19 - to be not below 90% speed, etcetera. This feature provides ability to limit fan speed according to some system wise considerations, like absence of some replaceable units or high system ambient temperature.
Request for changing fan minimum speed is configuration request and can be set only through 'sysfs' write procedure. In this situation value of argument 'state' is above nominal fan speed maximum.
Return non-zero code in this case to avoid thermal_cooling_device_stats_update() call, because in this case statistics update violates thermal statistics table range. The issues is observed in case kernel is configured with option CONFIG_THERMAL_STATISTICS.
Here is the trace from KASAN: [ 159.506659] BUG: KASAN: slab-out-of-bounds in thermal_cooling_device_stats_update+0x7d/0xb0 [ 159.516016] Read of size 4 at addr ffff888116163840 by task hw-management.s/7444 [ 159.545625] Call Trace: [ 159.548366] dump_stack+0x92/0xc1 [ 159.552084] ? thermal_cooling_device_stats_update+0x7d/0xb0 [ 159.635869] thermal_zone_device_update+0x345/0x780 [ 159.688711] thermal_zone_device_set_mode+0x7d/0xc0 [ 159.694174] mlxsw_thermal_modules_init+0x48f/0x590 [mlxsw_core] [ 159.700972] ? mlxsw_thermal_set_cur_state+0x5a0/0x5a0 [mlxsw_core] [ 159.731827] mlxsw_thermal_init+0x763/0x880 [mlxsw_core] [ 160.070233] RIP: 0033:0x7fd995909970 [ 160.074239] Code: 73 01 c3 48 8b 0d 28 d5 2b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d 99 2d 2c 00 00 75 10 b8 01 00 00 00 0f 05 <48> 3d 01 f0 ff .. [ 160.095242] RSP: 002b:00007fff54f5d938 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ 160.103722] RAX: ffffffffffffffda RBX: 0000000000000013 RCX: 00007fd995909970 [ 160.111710] RDX: 0000000000000013 RSI: 0000000001906008 RDI: 0000000000000001 [ 160.119699] RBP: 0000000001906008 R08: 00007fd995bc9760 R09: 00007fd996210700 [ 160.127687] R10: 0000000000000073 R11: 0000000000000246 R12: 0000000000000013 [ 160.135673] R13: 0000000000000001 R14: 00007fd995bc8600 R15: 0000000000000013 [ 160.143671] [ 160.145338] Allocated by task 2924: [ 160.149242] kasan_save_stack+0x19/0x40 [ 160.153541] __kasan_kmalloc+0x7f/0xa0 [ 160.157743] __kmalloc+0x1a2/0x2b0 [ 160.161552] thermal_cooling_device_setup_sysfs+0xf9/0x1a0 [ 160.167687] __thermal_cooling_device_register+0x1b5/0x500 [ 160.173833] devm_thermal_of_cooling_device_register+0x60/0xa0 [ 160.180356] mlxreg_fan_probe+0x474/0x5e0 [mlxreg_fan] [ 160.248140] [ 160.249807] The buggy address belongs to the object at ffff888116163400 [ 160.249807] which belongs to the cache kmalloc-1k of size 1024 [ 160.263814] The buggy address is located 64 bytes to the right of [ 160.263814] 1024-byte region [ffff888116163400, ffff888116163800) [ 160.277536] The buggy address belongs to the page: [ 160.282898] page:0000000012275840 refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888116167000 pfn:0x116160 [ 160.294872] head:0000000012275840 order:3 compound_mapcount:0 compound_pincount:0 [ 160.303251] flags: 0x200000000010200(slab|head|node=0|zone=2) [ 160.309694] raw: 0200000000010200 ffffea00046f7208 ffffea0004928208 ffff88810004dbc0 [ 160.318367] raw: ffff888116167000 00000000000a0006 00000001ffffffff 0000000000000000 [ 160.327033] page dumped because: kasan: bad access detected [ 160.333270] [ 160.334937] Memory state around the buggy address: [ 160.356469] >ffff888116163800: fc ..(CVE-2021-47393)
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:
scsi: qla2xxx: Fix a memory leak in an error path of qla2x00_process_els()
Commit 8c0eb596baa5 ("[SCSI] qla2xxx: Fix a memory leak in an error path of qla2x00_process_els()"), intended to change:
bsg_job->request->msgcode == FC_BSG_HST_ELS_NOLOGIN
bsg_job->request->msgcode != FC_BSG_RPT_ELS
but changed it to:
bsg_job->request->msgcode == FC_BSG_RPT_ELS
instead.
Change the == to a != to avoid leaking the fcport structure or freeing unallocated memory.(CVE-2021-47473)
In the Linux kernel, the following vulnerability has been resolved:
nvmem: Fix shift-out-of-bound (UBSAN) with byte size cells
If a cell has 'nbits' equal to a multiple of BITS_PER_BYTE the logic
*p &= GENMASK((cell->nbits%BITS_PER_BYTE) - 1, 0);
will become undefined behavior because nbits modulo BITS_PER_BYTE is 0, and we subtract one from that making a large number that is then shifted more than the number of bits that fit into an unsigned long.
UBSAN reports this problem:
UBSAN: shift-out-of-bounds in drivers/nvmem/core.c:1386:8 shift exponent 64 is too large for 64-bit type 'unsigned long' CPU: 6 PID: 7 Comm: kworker/u16:0 Not tainted 5.15.0-rc3+ #9 Hardware name: Google Lazor (rev3+) with KB Backlight (DT) Workqueue: events_unbound deferred_probe_work_func Call trace: dump_backtrace+0x0/0x170 show_stack+0x24/0x30 dump_stack_lvl+0x64/0x7c dump_stack+0x18/0x38 ubsan_epilogue+0x10/0x54 __ubsan_handle_shift_out_of_bounds+0x180/0x194 __nvmem_cell_read+0x1ec/0x21c nvmem_cell_read+0x58/0x94 nvmem_cell_read_variable_common+0x4c/0xb0 nvmem_cell_read_variable_le_u32+0x40/0x100 a6xx_gpu_init+0x170/0x2f4 adreno_bind+0x174/0x284 component_bind_all+0xf0/0x264 msm_drm_bind+0x1d8/0x7a0 try_to_bring_up_master+0x164/0x1ac __component_add+0xbc/0x13c component_add+0x20/0x2c dp_display_probe+0x340/0x384 platform_probe+0xc0/0x100 really_probe+0x110/0x304 __driver_probe_device+0xb8/0x120 driver_probe_device+0x4c/0xfc __device_attach_driver+0xb0/0x128 bus_for_each_drv+0x90/0xdc __device_attach+0xc8/0x174 device_initial_probe+0x20/0x2c bus_probe_device+0x40/0xa4 deferred_probe_work_func+0x7c/0xb8 process_one_work+0x128/0x21c process_scheduled_works+0x40/0x54 worker_thread+0x1ec/0x2a8 kthread+0x138/0x158 ret_from_fork+0x10/0x20
Fix it by making sure there are any bits to mask out.(CVE-2021-47497)
In the Linux kernel, the following vulnerability has been resolved:
scsi: mpt3sas: Fix use-after-free warning
Fix the following use-after-free warning which is observed during controller reset:
refcount_t: underflow; use-after-free. WARNING: CPU: 23 PID: 5399 at lib/refcount.c:28 refcount_warn_saturate+0xa6/0xf0(CVE-2022-48695)
In the Linux kernel, the following vulnerability has been resolved:
nvmet: fix a use-after-free
Fix the following use-after-free complaint triggered by blktests nvme/004:
BUG: KASAN: user-memory-access in blk_mq_complete_request_remote+0xac/0x350 Read of size 4 at addr 0000607bd1835943 by task kworker/13:1/460 Workqueue: nvmet-wq nvme_loop_execute_work [nvme_loop] Call Trace: show_stack+0x52/0x58 dump_stack_lvl+0x49/0x5e print_report.cold+0x36/0x1e2 kasan_report+0xb9/0xf0 __asan_load4+0x6b/0x80 blk_mq_complete_request_remote+0xac/0x350 nvme_loop_queue_response+0x1df/0x275 [nvme_loop] __nvmet_req_complete+0x132/0x4f0 [nvmet] nvmet_req_complete+0x15/0x40 [nvmet] nvmet_execute_io_connect+0x18a/0x1f0 [nvmet] nvme_loop_execute_work+0x20/0x30 [nvme_loop] process_one_work+0x56e/0xa70 worker_thread+0x2d1/0x640 kthread+0x183/0x1c0 ret_from_fork+0x1f/0x30(CVE-2022-48697)
In the Linux kernel, the following vulnerability has been resolved:
ALSA: emu10k1: Fix out of bounds access in snd_emu10k1_pcm_channel_alloc()
The voice allocator sometimes begins allocating from near the end of the array and then wraps around, however snd_emu10k1_pcm_channel_alloc() accesses the newly allocated voices as if it never wrapped around.
This results in out of bounds access if the first voice has a high enough index so that first_voice + requested_voice_count > NUM_G (64). The more voices are requested, the more likely it is for this to occur.
This was initially discovered using PipeWire, however it can be reproduced by calling aplay multiple times with 16 channels: aplay -r 48000 -D plughw:CARD=Live,DEV=3 -c 16 /dev/zero
UBSAN: array-index-out-of-bounds in sound/pci/emu10k1/emupcm.c:127:40 index 65 is out of range for type 'snd_emu10k1_voice [64]' CPU: 1 PID: 31977 Comm: aplay Tainted: G W IOE 6.0.0-rc2-emu10k1+ #7 Hardware name: ASUSTEK COMPUTER INC P5W DH Deluxe/P5W DH Deluxe, BIOS 3002 07/22/2010 Call Trace: <TASK> dump_stack_lvl+0x49/0x63 dump_stack+0x10/0x16 ubsan_epilogue+0x9/0x3f __ubsan_handle_out_of_bounds.cold+0x44/0x49 snd_emu10k1_playback_hw_params+0x3bc/0x420 [snd_emu10k1] snd_pcm_hw_params+0x29f/0x600 [snd_pcm] snd_pcm_common_ioctl+0x188/0x1410 [snd_pcm] ? exit_to_user_mode_prepare+0x35/0x170 ? do_syscall_64+0x69/0x90 ? syscall_exit_to_user_mode+0x26/0x50 ? do_syscall_64+0x69/0x90 ? exit_to_user_mode_prepare+0x35/0x170 snd_pcm_ioctl+0x27/0x40 [snd_pcm] __x64_sys_ioctl+0x95/0xd0 do_syscall_64+0x5c/0x90 ? do_syscall_64+0x69/0x90 ? do_syscall_64+0x69/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd(CVE-2022-48702)
In the Linux kernel, the following vulnerability has been resolved:
drm/radeon: add a force flush to delay work when radeon
Although radeon card fence and wait for gpu to finish processing current batch rings, there is still a corner case that radeon lockup work queue may not be fully flushed, and meanwhile the radeon_suspend_kms() function has called pci_set_power_state() to put device in D3hot state. Per PCI spec rev 4.0 on 5.3.1.4.1 D3hot State. > Configuration and Message requests are the only TLPs accepted by a Function in > the D3hot state. All other received Requests must be handled as Unsupported Requests, > and all received Completions may optionally be handled as Unexpected Completions. This issue will happen in following logs: Unable to handle kernel paging request at virtual address 00008800e0008010 CPU 0 kworker/0:3(131): Oops 0 pc = [<ffffffff811bea5c>] ra = [<ffffffff81240844>] ps = 0000 Tainted: G W pc is at si_gpu_check_soft_reset+0x3c/0x240 ra is at si_dma_is_lockup+0x34/0xd0 v0 = 0000000000000000 t0 = fff08800e0008010 t1 = 0000000000010000 t2 = 0000000000008010 t3 = fff00007e3c00000 t4 = fff00007e3c00258 t5 = 000000000000ffff t6 = 0000000000000001 t7 = fff00007ef078000 s0 = fff00007e3c016e8 s1 = fff00007e3c00000 s2 = fff00007e3c00018 s3 = fff00007e3c00000 s4 = fff00007fff59d80 s5 = 0000000000000000 s6 = fff00007ef07bd98 a0 = fff00007e3c00000 a1 = fff00007e3c016e8 a2 = 0000000000000008 a3 = 0000000000000001 a4 = 8f5c28f5c28f5c29 a5 = ffffffff810f4338 t8 = 0000000000000275 t9 = ffffffff809b66f8 t10 = ff6769c5d964b800 t11= 000000000000b886 pv = ffffffff811bea20 at = 0000000000000000 gp = ffffffff81d89690 sp = 00000000aa814126 Disabling lock debugging due to kernel taint Trace: [<ffffffff81240844>] si_dma_is_lockup+0x34/0xd0 [<ffffffff81119610>] radeon_fence_check_lockup+0xd0/0x290 [<ffffffff80977010>] process_one_work+0x280/0x550 [<ffffffff80977350>] worker_thread+0x70/0x7c0 [<ffffffff80977410>] worker_thread+0x130/0x7c0 [<ffffffff80982040>] kthread+0x200/0x210 [<ffffffff809772e0>] worker_thread+0x0/0x7c0 [<ffffffff80981f8c>] kthread+0x14c/0x210 [<ffffffff80911658>] ret_from_kernel_thread+0x18/0x20 [<ffffffff80981e40>] kthread+0x0/0x210 Code: ad3e0008 43f0074a ad7e0018 ad9e0020 8c3001e8 40230101 <88210000> 4821ed21 So force lockup work queue flush to fix this problem.(CVE-2022-48704)
In the Linux kernel, the following vulnerability has been resolved:
drm/radeon: fix a possible null pointer dereference
In radeon_fp_native_mode(), the return value of drm_mode_duplicate() is assigned to mode, which will lead to a NULL pointer dereference on failure of drm_mode_duplicate(). Add a check to avoid npd.
The failure status of drm_cvt_mode() on the other path is checked too.(CVE-2022-48710)
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:
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:
pstore: ram_core: fix possible overflow in persistent_ram_init_ecc()
In persistent_ram_init_ecc(), on 64-bit arches DIV_ROUND_UP() will return 64-bit value since persistent_ram_zone::buffer_size has type size_t which is derived from the 64-bit unsigned long, while the ecc_blocks variable this value gets assigned to has (always 32-bit) int type. Even if that value fits into int type, an overflow is still possible when calculating the size_t typed ecc_total variable further below since there's no cast to any 64-bit type before multiplication. Declaring the ecc_blocks variable as size_t should fix this mess...
Found by Linux Verification Center (linuxtesting.org) with the SVACE static analysis tool.(CVE-2023-52685)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/pm: fix a double-free in si_dpm_init
When the allocation of adev->pm.dpm.dyn_state.vddc_dependency_on_dispclk.entries fails, amdgpu_free_extended_power_table is called to free some fields of adev. However, when the control flow returns to si_dpm_sw_init, it goes to label dpm_failed and calls si_dpm_fini, which calls amdgpu_free_extended_power_table again and free those fields again. Thus a double-free is triggered.(CVE-2023-52691)
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:
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: 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:
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:
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:
nilfs2: fix failure to detect DAT corruption in btree and direct mappings
Patch series "nilfs2: fix kernel bug at submit_bh_wbc()".
This resolves a kernel BUG reported by syzbot. Since there are two flaws involved, I've made each one a separate patch.
The first patch alone resolves the syzbot-reported bug, but I think both fixes should be sent to stable, so I've tagged them as such.
This patch (of 2):
Syzbot has reported a kernel bug in submit_bh_wbc() when writing file data to a nilfs2 file system whose metadata is corrupted.
There are two flaws involved in this issue.
The first flaw is that when nilfs_get_block() locates a data block using btree or direct mapping, if the disk address translation routine nilfs_dat_translate() fails with internal code -ENOENT due to DAT metadata corruption, it can be passed back to nilfs_get_block(). This causes nilfs_get_block() to misidentify an existing block as non-existent, causing both data block lookup and insertion to fail inconsistently.
The second flaw is that nilfs_get_block() returns a successful status in this inconsistent state. This causes the caller __block_write_begin_int() or others to request a read even though the buffer is not mapped, resulting in a BUG_ON check for the BH_Mapped flag in submit_bh_wbc() failing.
This fixes the first issue by changing the return value to code -EINVAL when a conversion using DAT fails with code -ENOENT, avoiding the conflicting condition that leads to the kernel bug described above. Here, code -EINVAL indicates that metadata corruption was detected during the block lookup, which will be properly handled as a file system error and converted to -EIO when passing through the nilfs2 bmap layer.(CVE-2024-26956)
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:
mm: swap: fix race between free_swap_and_cache() and swapoff()
There was previously a theoretical window where swapoff() could run and teardown a swap_info_struct while a call to free_swap_and_cache() was running in another thread. This could cause, amongst other bad possibilities, swap_page_trans_huge_swapped() (called by free_swap_and_cache()) to access the freed memory for swap_map.
This is a theoretical problem and I haven't been able to provoke it from a test case. But there has been agreement based on code review that this is possible (see link below).
Fix it by using get_swap_device()/put_swap_device(), which will stall swapoff(). There was an extra check in _swap_info_get() to confirm that the swap entry was not free. This isn't present in get_swap_device() because it doesn't make sense in general due to the race between getting the reference and swapoff. So I've added an equivalent check directly in free_swap_and_cache().
Details of how to provoke one possible issue (thanks to David Hildenbrand for deriving this):
--8<-----
__swap_entry_free() might be the last user and result in "count == SWAP_HAS_CACHE".
swapoff->try_to_unuse() will stop as soon as soon as si->inuse_pages==0.
So the question is: could someone reclaim the folio and turn si->inuse_pages==0, before we completed swap_page_trans_huge_swapped().
Imagine the following: 2 MiB folio in the swapcache. Only 2 subpages are still references by swap entries.
Process 1 still references subpage 0 via swap entry. Process 2 still references subpage 1 via swap entry.
Process 1 quits. Calls free_swap_and_cache(). -> count == SWAP_HAS_CACHE [then, preempted in the hypervisor etc.]
Process 2 quits. Calls free_swap_and_cache(). -> count == SWAP_HAS_CACHE
Process 2 goes ahead, passes swap_page_trans_huge_swapped(), and calls __try_to_reclaim_swap().
__try_to_reclaim_swap()->folio_free_swap()->delete_from_swap_cache()-> put_swap_folio()->free_swap_slot()->swapcache_free_entries()-> swap_entry_free()->swap_range_free()-> ... WRITE_ONCE(si->inuse_pages, si->inuse_pages - nr_entries);
What stops swapoff to succeed after process 2 reclaimed the swap cache but before process1 finished its call to swap_page_trans_huge_swapped()?
--8<-----(CVE-2024-26960)
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:
clk: qcom: mmcc-apq8084: 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-26966)
In the Linux kernel, the following vulnerability has been resolved:
clk: qcom: gcc-ipq8074: 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-26969)
In the Linux kernel, the following vulnerability has been resolved:
crypto: qat - resolve race condition during AER recovery
During the PCI AER system's error recovery process, the kernel driver may encounter a race condition with freeing the reset_data structure's memory. If the device restart will take more than 10 seconds the function scheduling that restart will exit due to a timeout, and the reset_data structure will be freed. However, this data structure is used for completion notification after the restart is completed, which leads to a UAF bug.
This results in a KFENCE bug notice.
BUG: KFENCE: use-after-free read in adf_device_reset_worker+0x38/0xa0 [intel_qat] Use-after-free read at 0x00000000bc56fddf (in kfence-#142): adf_device_reset_worker+0x38/0xa0 [intel_qat] process_one_work+0x173/0x340
To resolve this race condition, the memory associated to the container of the work_struct is freed on the worker if the timeout expired, otherwise on the function that schedules the worker. The timeout detection can be done by checking if the caller is still waiting for completion or not by using completion_done() function.(CVE-2024-26974)
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:
nilfs2: fix OOB in nilfs_set_de_type
The size of the nilfs_type_by_mode array in the fs/nilfs2/dir.c file is defined as "S_IFMT >> S_SHIFT", but the nilfs_set_de_type() function, which uses this array, specifies the index to read from the array in the same way as "(mode & S_IFMT) >> S_SHIFT".
static void nilfs_set_de_type(struct nilfs_dir_entry de, struct inode inode) { umode_t mode = inode->i_mode;
de->file_type = nilfs_type_by_mode[(mode & S_IFMT)>>S_SHIFT]; // oob
}
However, when the index is determined this way, an out-of-bounds (OOB) error occurs by referring to an index that is 1 larger than the array size when the condition "mode & S_IFMT == S_IFMT" is satisfied. Therefore, a patch to resize the nilfs_type_by_mode array should be applied to prevent OOB errors.(CVE-2024-26981)
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:
usb: gadget: f_ncm: Fix UAF ncm object at re-bind after usb ep transport error
When ncm function is working and then stop usb0 interface for link down, eth_stop() is called. At this piont, accidentally if usb transport error should happen in usb_ep_enable(), 'in_ep' and/or 'out_ep' may not be enabled.
After that, ncm_disable() is called to disable for ncm unbind but gether_disconnect() is never called since 'in_ep' is not enabled.
As the result, ncm object is released in ncm unbind but 'dev->port_usb' associated to 'ncm->port' is not NULL.
And when ncm bind again to recover netdev, ncm object is reallocated but usb0 interface is already associated to previous released ncm object.
Therefore, once usb0 interface is up and eth_start_xmit() is called, released ncm object is dereferrenced and it might cause use-after-free memory.
[function unlink via configfs] usb0: eth_stop dev->port_usb=ffffff9b179c3200 --> error happens in usb_ep_enable(). NCM: ncm_disable: ncm=ffffff9b179c3200 --> no gether_disconnect() since ncm->port.in_ep->enabled is false. NCM: ncm_unbind: ncm unbind ncm=ffffff9b179c3200 NCM: ncm_free: ncm free ncm=ffffff9b179c3200 <-- released ncm
[function link via configfs] NCM: ncm_alloc: ncm alloc ncm=ffffff9ac4f8a000 NCM: ncm_bind: ncm bind ncm=ffffff9ac4f8a000 NCM: ncm_set_alt: ncm=ffffff9ac4f8a000 alt=0 usb0: eth_open dev->port_usb=ffffff9b179c3200 <-- previous released ncm usb0: eth_start dev->port_usb=ffffff9b179c3200 <-- eth_start_xmit() --> dev->wrap() Unable to handle kernel paging request at virtual address dead00000000014f
This patch addresses the issue by checking if 'ncm->netdev' is not NULL at ncm_disable() to call gether_disconnect() to deassociate 'dev->port_usb'. It's more reasonable to check 'ncm->netdev' to call gether_connect/disconnect rather than check 'ncm->port.in_ep->enabled' since it might not be enabled but the gether connection might be established.(CVE-2024-26996)
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:
comedi: vmk80xx: fix incomplete endpoint checking
While vmk80xx does have endpoint checking implemented, some things can fall through the cracks. Depending on the hardware model, URBs can have either bulk or interrupt type, and current version of vmk80xx_find_usb_endpoints() function does not take that fully into account. While this warning does not seem to be too harmful, at the very least it will crash systems with 'panic_on_warn' set on them.
Fix the issue found by Syzkaller [1] by somewhat simplifying the endpoint checking process with usb_find_common_endpoints() and ensuring that only expected endpoint types are present.
This patch has not been tested on real hardware.
[1] Syzkaller report: usb 1-1: BOGUS urb xfer, pipe 1 != type 3 WARNING: CPU: 0 PID: 781 at drivers/usb/core/urb.c:504 usb_submit_urb+0xc4e/0x18c0 drivers/usb/core/urb.c:503 ... Call Trace: <TASK> usb_start_wait_urb+0x113/0x520 drivers/usb/core/message.c:59 vmk80xx_reset_device drivers/comedi/drivers/vmk80xx.c:227 [inline] vmk80xx_auto_attach+0xa1c/0x1a40 drivers/comedi/drivers/vmk80xx.c:818 comedi_auto_config+0x238/0x380 drivers/comedi/drivers.c:1067 usb_probe_interface+0x5cd/0xb00 drivers/usb/core/driver.c:399 ...
Similar issue also found by Syzkaller:(CVE-2024-27001)
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:
spi: spi-mt65xx: Fix NULL pointer access in interrupt handler
The TX buffer in spi_transfer can be a NULL pointer, so the interrupt handler may end up writing to the invalid memory and cause crashes.
Add a check to trans->tx_buf before using it.(CVE-2024-27028)
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:
nfp: flower: handle acti_netdevs allocation failure
The kmalloc_array() in nfp_fl_lag_do_work() will return null, if the physical memory has run out. As a result, if we dereference the acti_netdevs, the null pointer dereference bugs will happen.
This patch adds a check to judge whether allocation failure occurs. If it happens, the delayed work will be rescheduled and try again.(CVE-2024-27046)
In the Linux kernel, the following vulnerability has been resolved:
cpufreq: brcmstb-avs-cpufreq: add check for cpufreq_cpu_get's return value
cpufreq_cpu_get may return NULL. To avoid NULL-dereference check it and return 0 in case of error.
Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-27051)
In the Linux kernel, the following vulnerability has been resolved:
s390/dasd: fix double module refcount decrement
Once the discipline is associated with the device, deleting the device takes care of decrementing the module's refcount. Doing it manually on this error path causes refcount to artificially decrease on each error while it should just stay the same.(CVE-2024-27054)
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:
nouveau: lock the client object tree.
It appears the client object tree has no locking unless I've missed something else. Fix races around adding/removing client objects, mostly vram bar mappings.
4562.099306] general protection fault, probably for non-canonical address 0x6677ed422bceb80c: 0000 [#1] PREEMPT SMP PTI [ 4562.099314] CPU: 2 PID: 23171 Comm: deqp-vk Not tainted 6.8.0-rc6+ #27 [ 4562.099324] Hardware name: Gigabyte Technology Co., Ltd. Z390 I AORUS PRO WIFI/Z390 I AORUS PRO WIFI-CF, BIOS F8 11/05/2021 [ 4562.099330] RIP: 0010:nvkm_object_search+0x1d/0x70 [nouveau] [ 4562.099503] Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 0f 1f 44 00 00 48 89 f8 48 85 f6 74 39 48 8b 87 a0 00 00 00 48 85 c0 74 12 <48> 8b 48 f8 48 39 ce 73 15 48 8b 40 10 48 85 c0 75 ee 48 c7 c0 fe [ 4562.099506] RSP: 0000:ffffa94cc420bbf8 EFLAGS: 00010206 [ 4562.099512] RAX: 6677ed422bceb814 RBX: ffff98108791f400 RCX: ffff9810f26b8f58 [ 4562.099517] RDX: 0000000000000000 RSI: ffff9810f26b9158 RDI: ffff98108791f400 [ 4562.099519] RBP: ffff9810f26b9158 R08: 0000000000000000 R09: 0000000000000000 [ 4562.099521] R10: ffffa94cc420bc48 R11: 0000000000000001 R12: ffff9810f02a7cc0 [ 4562.099526] R13: 0000000000000000 R14: 00000000000000ff R15: 0000000000000007 [ 4562.099528] FS: 00007f629c5017c0(0000) GS:ffff98142c700000(0000) knlGS:0000000000000000 [ 4562.099534] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 4562.099536] CR2: 00007f629a882000 CR3: 000000017019e004 CR4: 00000000003706f0 [ 4562.099541] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 4562.099542] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 4562.099544] Call Trace: [ 4562.099555] <TASK> [ 4562.099573] ? die_addr+0x36/0x90 [ 4562.099583] ? exc_general_protection+0x246/0x4a0 [ 4562.099593] ? asm_exc_general_protection+0x26/0x30 [ 4562.099600] ? nvkm_object_search+0x1d/0x70 [nouveau] [ 4562.099730] nvkm_ioctl+0xa1/0x250 [nouveau] [ 4562.099861] nvif_object_map_handle+0xc8/0x180 [nouveau] [ 4562.099986] nouveau_ttm_io_mem_reserve+0x122/0x270 [nouveau] [ 4562.100156] ? dma_resv_test_signaled+0x26/0xb0 [ 4562.100163] ttm_bo_vm_fault_reserved+0x97/0x3c0 [ttm] [ 4562.100182] ? __mutex_unlock_slowpath+0x2a/0x270 [ 4562.100189] nouveau_ttm_fault+0x69/0xb0 [nouveau] [ 4562.100356] __do_fault+0x32/0x150 [ 4562.100362] do_fault+0x7c/0x560 [ 4562.100369] __handle_mm_fault+0x800/0xc10 [ 4562.100382] handle_mm_fault+0x17c/0x3e0 [ 4562.100388] do_user_addr_fault+0x208/0x860 [ 4562.100395] exc_page_fault+0x7f/0x200 [ 4562.100402] asm_exc_page_fault+0x26/0x30 [ 4562.100412] RIP: 0033:0x9b9870 [ 4562.100419] Code: 85 a8 f7 ff ff 8b 8d 80 f7 ff ff 89 08 e9 18 f2 ff ff 0f 1f 84 00 00 00 00 00 44 89 32 e9 90 fa ff ff 0f 1f 84 00 00 00 00 00 <44> 89 32 e9 f8 f1 ff ff 0f 1f 84 00 00 00 00 00 66 44 89 32 e9 e7 [ 4562.100422] RSP: 002b:00007fff9ba2dc70 EFLAGS: 00010246 [ 4562.100426] RAX: 0000000000000004 RBX: 000000000dd65e10 RCX: 000000fff0000000 [ 4562.100428] RDX: 00007f629a882000 RSI: 00007f629a882000 RDI: 0000000000000066 [ 4562.100432] RBP: 00007fff9ba2e570 R08: 0000000000000000 R09: 0000000123ddf000 [ 4562.100434] R10: 0000000000000001 R11: 0000000000000246 R12: 000000007fffffff [ 4562.100436] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 4562.100446] </TASK> [ 4562.100448] Modules linked in: nf_conntrack_netbios_ns nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables libcrc32c nfnetlink cmac bnep sunrpc iwlmvm intel_rapl_msr intel_rapl_common snd_sof_pci_intel_cnl x86_pkg_temp_thermal intel_powerclamp snd_sof_intel_hda_common mac80211 coretemp snd_soc_acpi_intel_match kvm_intel snd_soc_acpi snd_soc_hdac_hda snd_sof_pci snd_sof_xtensa_dsp snd_sof_intel_hda_mlink ---truncated---(CVE-2024-27062)
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:
media: v4l2-mem2mem: fix a memleak in v4l2_m2m_register_entity
The entity->name (i.e. name) is allocated in v4l2_m2m_register_entity but isn't freed in its following error-handling paths. This patch adds such deallocation to prevent memleak of entity->name.(CVE-2024-27077)
In the Linux kernel, the following vulnerability has been resolved:
media: v4l2-tpg: fix some memleaks in tpg_alloc
In tpg_alloc, resources should be deallocated in each and every error-handling paths, since they are allocated in for statements. Otherwise there would be memleaks because tpg_free is called only when tpg_alloc return 0.(CVE-2024-27078)
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:
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:
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:
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:
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:
btrfs: fix information leak in btrfs_ioctl_logical_to_ino()
Syzbot reported the following information leak for in btrfs_ioctl_logical_to_ino():
BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline] BUG: KMSAN: kernel-infoleak in _copy_to_user+0xbc/0x110 lib/usercopy.c:40 instrument_copy_to_user include/linux/instrumented.h:114 [inline] _copy_to_user+0xbc/0x110 lib/usercopy.c:40 copy_to_user include/linux/uaccess.h:191 [inline] btrfs_ioctl_logical_to_ino+0x440/0x750 fs/btrfs/ioctl.c:3499 btrfs_ioctl+0x714/0x1260 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:904 [inline] __se_sys_ioctl+0x261/0x450 fs/ioctl.c:890 __x64_sys_ioctl+0x96/0xe0 fs/ioctl.c:890 x64_sys_call+0x1883/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:17 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Uninit was created at: __kmalloc_large_node+0x231/0x370 mm/slub.c:3921 __do_kmalloc_node mm/slub.c:3954 [inline] __kmalloc_node+0xb07/0x1060 mm/slub.c:3973 kmalloc_node include/linux/slab.h:648 [inline] kvmalloc_node+0xc0/0x2d0 mm/util.c:634 kvmalloc include/linux/slab.h:766 [inline] init_data_container+0x49/0x1e0 fs/btrfs/backref.c:2779 btrfs_ioctl_logical_to_ino+0x17c/0x750 fs/btrfs/ioctl.c:3480 btrfs_ioctl+0x714/0x1260 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:904 [inline] __se_sys_ioctl+0x261/0x450 fs/ioctl.c:890 __x64_sys_ioctl+0x96/0xe0 fs/ioctl.c:890 x64_sys_call+0x1883/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:17 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Bytes 40-65535 of 65536 are uninitialized Memory access of size 65536 starts at ffff888045a40000
This happens, because we're copying a 'struct btrfs_data_container' back to user-space. This btrfs_data_container is allocated in 'init_data_container()' via kvmalloc(), which does not zero-fill the memory.
Fix this by using kvzalloc() which zeroes out the memory on allocation.(CVE-2024-35849)
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: 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:
drm/client: Fully protect modes[] with dev->mode_config.mutex
The modes[] array contains pointers to modes on the connectors' mode lists, which are protected by dev->mode_config.mutex. Thus we need to extend modes[] the same protection or by the time we use it the elements may already be pointing to freed/reused memory.(CVE-2024-35950)
In the Linux kernel, the following vulnerability has been resolved:
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)
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"kernel-tools-debuginfo-4.19.90-2405.5.0.0278.oe2003sp4.aarch64.rpm",
"perf-debuginfo-4.19.90-2405.5.0.0278.oe2003sp4.aarch64.rpm",
"perf-4.19.90-2405.5.0.0278.oe2003sp4.aarch64.rpm",
"kernel-tools-4.19.90-2405.5.0.0278.oe2003sp4.aarch64.rpm",
"python3-perf-4.19.90-2405.5.0.0278.oe2003sp4.aarch64.rpm",
"kernel-debugsource-4.19.90-2405.5.0.0278.oe2003sp4.aarch64.rpm",
"kernel-4.19.90-2405.5.0.0278.oe2003sp4.aarch64.rpm",
"bpftool-debuginfo-4.19.90-2405.5.0.0278.oe2003sp4.aarch64.rpm",
"python3-perf-debuginfo-4.19.90-2405.5.0.0278.oe2003sp4.aarch64.rpm",
"kernel-source-4.19.90-2405.5.0.0278.oe2003sp4.aarch64.rpm",
"kernel-devel-4.19.90-2405.5.0.0278.oe2003sp4.aarch64.rpm",
"kernel-tools-devel-4.19.90-2405.5.0.0278.oe2003sp4.aarch64.rpm",
"python2-perf-debuginfo-4.19.90-2405.5.0.0278.oe2003sp4.aarch64.rpm",
"python2-perf-4.19.90-2405.5.0.0278.oe2003sp4.aarch64.rpm",
"bpftool-4.19.90-2405.5.0.0278.oe2003sp4.aarch64.rpm",
"kernel-debuginfo-4.19.90-2405.5.0.0278.oe2003sp4.aarch64.rpm"
],
"src": [
"kernel-4.19.90-2405.5.0.0278.oe2003sp4.src.rpm"
],
"x86_64": [
"python2-perf-4.19.90-2405.5.0.0278.oe2003sp4.x86_64.rpm",
"kernel-debugsource-4.19.90-2405.5.0.0278.oe2003sp4.x86_64.rpm",
"kernel-devel-4.19.90-2405.5.0.0278.oe2003sp4.x86_64.rpm",
"bpftool-4.19.90-2405.5.0.0278.oe2003sp4.x86_64.rpm",
"kernel-tools-devel-4.19.90-2405.5.0.0278.oe2003sp4.x86_64.rpm",
"python3-perf-debuginfo-4.19.90-2405.5.0.0278.oe2003sp4.x86_64.rpm",
"perf-debuginfo-4.19.90-2405.5.0.0278.oe2003sp4.x86_64.rpm",
"kernel-tools-debuginfo-4.19.90-2405.5.0.0278.oe2003sp4.x86_64.rpm",
"kernel-source-4.19.90-2405.5.0.0278.oe2003sp4.x86_64.rpm",
"kernel-4.19.90-2405.5.0.0278.oe2003sp4.x86_64.rpm",
"kernel-tools-4.19.90-2405.5.0.0278.oe2003sp4.x86_64.rpm",
"kernel-debuginfo-4.19.90-2405.5.0.0278.oe2003sp4.x86_64.rpm",
"perf-4.19.90-2405.5.0.0278.oe2003sp4.x86_64.rpm",
"python3-perf-4.19.90-2405.5.0.0278.oe2003sp4.x86_64.rpm",
"bpftool-debuginfo-4.19.90-2405.5.0.0278.oe2003sp4.x86_64.rpm",
"python2-perf-debuginfo-4.19.90-2405.5.0.0278.oe2003sp4.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:20.03-LTS-SP4",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-20.03-LTS-SP4"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.19.90-2405.5.0.0278.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\nusb: dwc3: ep0: fix NULL pointer exception\r\n\r\nThere is no validation of the index from dwc3_wIndex_to_dep() and we might\nbe referring a non-existing ep and trigger a NULL pointer exception. In\ncertain configurations we might use fewer eps and the index might wrongly\nindicate a larger ep index than existing.\r\n\r\nBy adding this validation from the patch we can actually report a wrong\nindex back to the caller.\r\n\r\nIn our usecase we are using a composite device on an older kernel, but\nupstream might use this fix also. Unfortunately, I cannot describe the\nhardware for others to reproduce the issue as it is a proprietary\nimplementation.\r\n\r\n[ 82.958261] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a4\n[ 82.966891] Mem abort info:\n[ 82.969663] ESR = 0x96000006\n[ 82.972703] Exception class = DABT (current EL), IL = 32 bits\n[ 82.978603] SET = 0, FnV = 0\n[ 82.981642] EA = 0, S1PTW = 0\n[ 82.984765] Data abort info:\n[ 82.987631] ISV = 0, ISS = 0x00000006\n[ 82.991449] CM = 0, WnR = 0\n[ 82.994409] user pgtable: 4k pages, 39-bit VAs, pgdp = 00000000c6210ccc\n[ 83.000999] [00000000000000a4] pgd=0000000053aa5003, pud=0000000053aa5003, pmd=0000000000000000\n[ 83.009685] Internal error: Oops: 96000006 [#1] PREEMPT SMP\n[ 83.026433] Process irq/62-dwc3 (pid: 303, stack limit = 0x000000003985154c)\n[ 83.033470] CPU: 0 PID: 303 Comm: irq/62-dwc3 Not tainted 4.19.124 #1\n[ 83.044836] pstate: 60000085 (nZCv daIf -PAN -UAO)\n[ 83.049628] pc : dwc3_ep0_handle_feature+0x414/0x43c\n[ 83.054558] lr : dwc3_ep0_interrupt+0x3b4/0xc94\r\n\r\n...\r\n\r\n[ 83.141788] Call trace:\n[ 83.144227] dwc3_ep0_handle_feature+0x414/0x43c\n[ 83.148823] dwc3_ep0_interrupt+0x3b4/0xc94\n[ 83.181546] ---[ end trace aac6b5267d84c32f ]---(CVE-2021-47269)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nisdn: mISDN: netjet: Fix crash in nj_probe:\r\n\r\n\u0026apos;nj_setup\u0026apos; in netjet.c might fail with -EIO and in this case\n\u0026apos;card-\u0026gt;irq\u0026apos; is initialized and is bigger than zero. A subsequent call to\n\u0026apos;nj_release\u0026apos; will free the irq that has not been requested.\r\n\r\nFix this bug by deleting the previous assignment to \u0026apos;card-\u0026gt;irq\u0026apos; and just\nkeep the assignment before \u0026apos;request_irq\u0026apos;.\r\n\r\nThe KASAN\u0026apos;s log reveals it:\r\n\r\n[ 3.354615 ] WARNING: CPU: 0 PID: 1 at kernel/irq/manage.c:1826\nfree_irq+0x100/0x480\n[ 3.355112 ] Modules linked in:\n[ 3.355310 ] CPU: 0 PID: 1 Comm: swapper/0 Not tainted\n5.13.0-rc1-00144-g25a1298726e #13\n[ 3.355816 ] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS\nrel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014\n[ 3.356552 ] RIP: 0010:free_irq+0x100/0x480\n[ 3.356820 ] Code: 6e 08 74 6f 4d 89 f4 e8 5e ac 09 00 4d 8b 74 24 18\n4d 85 f6 75 e3 e8 4f ac 09 00 8b 75 c8 48 c7 c7 78 c1 2e 85 e8 e0 cf f5\nff \u0026lt;0f\u0026gt; 0b 48 8b 75 c0 4c 89 ff e8 72 33 0b 03 48 8b 43 40 4c 8b a0 80\n[ 3.358012 ] RSP: 0000:ffffc90000017b48 EFLAGS: 00010082\n[ 3.358357 ] RAX: 0000000000000000 RBX: ffff888104dc8000 RCX:\n0000000000000000\n[ 3.358814 ] RDX: ffff8881003c8000 RSI: ffffffff8124a9e6 RDI:\n00000000ffffffff\n[ 3.359272 ] RBP: ffffc90000017b88 R08: 0000000000000000 R09:\n0000000000000000\n[ 3.359732 ] R10: ffffc900000179f0 R11: 0000000000001d04 R12:\n0000000000000000\n[ 3.360195 ] R13: ffff888107dc6000 R14: ffff888107dc6928 R15:\nffff888104dc80a8\n[ 3.360652 ] FS: 0000000000000000(0000) GS:ffff88817bc00000(0000)\nknlGS:0000000000000000\n[ 3.361170 ] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 3.361538 ] CR2: 0000000000000000 CR3: 000000000582e000 CR4:\n00000000000006f0\n[ 3.362003 ] DR0: 0000000000000000 DR1: 0000000000000000 DR2:\n0000000000000000\n[ 3.362175 ] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:\n0000000000000400\n[ 3.362175 ] Call Trace:\n[ 3.362175 ] nj_release+0x51/0x1e0\n[ 3.362175 ] nj_probe+0x450/0x950\n[ 3.362175 ] ? pci_device_remove+0x110/0x110\n[ 3.362175 ] local_pci_probe+0x45/0xa0\n[ 3.362175 ] pci_device_probe+0x12b/0x1d0\n[ 3.362175 ] really_probe+0x2a9/0x610\n[ 3.362175 ] driver_probe_device+0x90/0x1d0\n[ 3.362175 ] ? mutex_lock_nested+0x1b/0x20\n[ 3.362175 ] device_driver_attach+0x68/0x70\n[ 3.362175 ] __driver_attach+0x124/0x1b0\n[ 3.362175 ] ? device_driver_attach+0x70/0x70\n[ 3.362175 ] bus_for_each_dev+0xbb/0x110\n[ 3.362175 ] ? rdinit_setup+0x45/0x45\n[ 3.362175 ] driver_attach+0x27/0x30\n[ 3.362175 ] bus_add_driver+0x1eb/0x2a0\n[ 3.362175 ] driver_register+0xa9/0x180\n[ 3.362175 ] __pci_register_driver+0x82/0x90\n[ 3.362175 ] ? w6692_init+0x38/0x38\n[ 3.362175 ] nj_init+0x36/0x38\n[ 3.362175 ] do_one_initcall+0x7f/0x3d0\n[ 3.362175 ] ? rdinit_setup+0x45/0x45\n[ 3.362175 ] ? rcu_read_lock_sched_held+0x4f/0x80\n[ 3.362175 ] kernel_init_freeable+0x2aa/0x301\n[ 3.362175 ] ? rest_init+0x2c0/0x2c0\n[ 3.362175 ] kernel_init+0x18/0x190\n[ 3.362175 ] ? rest_init+0x2c0/0x2c0\n[ 3.362175 ] ? rest_init+0x2c0/0x2c0\n[ 3.362175 ] ret_from_fork+0x1f/0x30\n[ 3.362175 ] Kernel panic - not syncing: panic_on_warn set ...\n[ 3.362175 ] CPU: 0 PID: 1 Comm: swapper/0 Not tainted\n5.13.0-rc1-00144-g25a1298726e #13\n[ 3.362175 ] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS\nrel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014\n[ 3.362175 ] Call Trace:\n[ 3.362175 ] dump_stack+0xba/0xf5\n[ 3.362175 ] ? free_irq+0x100/0x480\n[ 3.362175 ] panic+0x15a/0x3f2\n[ 3.362175 ] ? __warn+0xf2/0x150\n[ 3.362175 ] ? free_irq+0x100/0x480\n[ 3.362175 ] __warn+0x108/0x150\n[ 3.362175 ] ? free_irq+0x100/0x480\n[ 3.362175 ] report_bug+0x119/0x1c0\n[ 3.362175 ] handle_bug+0x3b/0x80\n[ 3.362175 ] exc_invalid_op+0x18/0x70\n[ 3.362175 ] asm_exc_invalid_op+0x12/0x20\n[ 3.362175 ] RIP: 0010:free_irq+0x100\n---truncated---(CVE-2021-47284)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nf2fs: fix to avoid racing on fsync_entry_slab by multi filesystem instances\r\n\r\nAs syzbot reported, there is an use-after-free issue during f2fs recovery:\r\n\r\nUse-after-free write at 0xffff88823bc16040 (in kfence-#10):\n kmem_cache_destroy+0x1f/0x120 mm/slab_common.c:486\n f2fs_recover_fsync_data+0x75b0/0x8380 fs/f2fs/recovery.c:869\n f2fs_fill_super+0x9393/0xa420 fs/f2fs/super.c:3945\n mount_bdev+0x26c/0x3a0 fs/super.c:1367\n legacy_get_tree+0xea/0x180 fs/fs_context.c:592\n vfs_get_tree+0x86/0x270 fs/super.c:1497\n do_new_mount fs/namespace.c:2905 [inline]\n path_mount+0x196f/0x2be0 fs/namespace.c:3235\n do_mount fs/namespace.c:3248 [inline]\n __do_sys_mount fs/namespace.c:3456 [inline]\n __se_sys_mount+0x2f9/0x3b0 fs/namespace.c:3433\n do_syscall_64+0x3f/0xb0 arch/x86/entry/common.c:47\n entry_SYSCALL_64_after_hwframe+0x44/0xae\r\n\r\nThe root cause is multi f2fs filesystem instances can race on accessing\nglobal fsync_entry_slab pointer, result in use-after-free issue of slab\ncache, fixes to init/destroy this slab cache only once during module\ninit/destroy procedure to avoid this issue.(CVE-2021-47335)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nhwmon: (mlxreg-fan) Return non-zero value when fan current state is enforced from sysfs\r\n\r\nFan speed minimum can be enforced from sysfs. For example, setting\ncurrent fan speed to 20 is used to enforce fan speed to be at 100%\nspeed, 19 - to be not below 90% speed, etcetera. This feature provides\nability to limit fan speed according to some system wise\nconsiderations, like absence of some replaceable units or high system\nambient temperature.\r\n\r\nRequest for changing fan minimum speed is configuration request and can\nbe set only through \u0026apos;sysfs\u0026apos; write procedure. In this situation value of\nargument \u0026apos;state\u0026apos; is above nominal fan speed maximum.\r\n\r\nReturn non-zero code in this case to avoid\nthermal_cooling_device_stats_update() call, because in this case\nstatistics update violates thermal statistics table range.\nThe issues is observed in case kernel is configured with option\nCONFIG_THERMAL_STATISTICS.\r\n\r\nHere is the trace from KASAN:\n[ 159.506659] BUG: KASAN: slab-out-of-bounds in thermal_cooling_device_stats_update+0x7d/0xb0\n[ 159.516016] Read of size 4 at addr ffff888116163840 by task hw-management.s/7444\n[ 159.545625] Call Trace:\n[ 159.548366] dump_stack+0x92/0xc1\n[ 159.552084] ? thermal_cooling_device_stats_update+0x7d/0xb0\n[ 159.635869] thermal_zone_device_update+0x345/0x780\n[ 159.688711] thermal_zone_device_set_mode+0x7d/0xc0\n[ 159.694174] mlxsw_thermal_modules_init+0x48f/0x590 [mlxsw_core]\n[ 159.700972] ? mlxsw_thermal_set_cur_state+0x5a0/0x5a0 [mlxsw_core]\n[ 159.731827] mlxsw_thermal_init+0x763/0x880 [mlxsw_core]\n[ 160.070233] RIP: 0033:0x7fd995909970\n[ 160.074239] Code: 73 01 c3 48 8b 0d 28 d5 2b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d 99 2d 2c 00 00 75 10 b8 01 00 00 00 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ..\n[ 160.095242] RSP: 002b:00007fff54f5d938 EFLAGS: 00000246 ORIG_RAX: 0000000000000001\n[ 160.103722] RAX: ffffffffffffffda RBX: 0000000000000013 RCX: 00007fd995909970\n[ 160.111710] RDX: 0000000000000013 RSI: 0000000001906008 RDI: 0000000000000001\n[ 160.119699] RBP: 0000000001906008 R08: 00007fd995bc9760 R09: 00007fd996210700\n[ 160.127687] R10: 0000000000000073 R11: 0000000000000246 R12: 0000000000000013\n[ 160.135673] R13: 0000000000000001 R14: 00007fd995bc8600 R15: 0000000000000013\n[ 160.143671]\n[ 160.145338] Allocated by task 2924:\n[ 160.149242] kasan_save_stack+0x19/0x40\n[ 160.153541] __kasan_kmalloc+0x7f/0xa0\n[ 160.157743] __kmalloc+0x1a2/0x2b0\n[ 160.161552] thermal_cooling_device_setup_sysfs+0xf9/0x1a0\n[ 160.167687] __thermal_cooling_device_register+0x1b5/0x500\n[ 160.173833] devm_thermal_of_cooling_device_register+0x60/0xa0\n[ 160.180356] mlxreg_fan_probe+0x474/0x5e0 [mlxreg_fan]\n[ 160.248140]\n[ 160.249807] The buggy address belongs to the object at ffff888116163400\n[ 160.249807] which belongs to the cache kmalloc-1k of size 1024\n[ 160.263814] The buggy address is located 64 bytes to the right of\n[ 160.263814] 1024-byte region [ffff888116163400, ffff888116163800)\n[ 160.277536] The buggy address belongs to the page:\n[ 160.282898] page:0000000012275840 refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888116167000 pfn:0x116160\n[ 160.294872] head:0000000012275840 order:3 compound_mapcount:0 compound_pincount:0\n[ 160.303251] flags: 0x200000000010200(slab|head|node=0|zone=2)\n[ 160.309694] raw: 0200000000010200 ffffea00046f7208 ffffea0004928208 ffff88810004dbc0\n[ 160.318367] raw: ffff888116167000 00000000000a0006 00000001ffffffff 0000000000000000\n[ 160.327033] page dumped because: kasan: bad access detected\n[ 160.333270]\n[ 160.334937] Memory state around the buggy address:\n[ 160.356469] \u0026gt;ffff888116163800: fc ..(CVE-2021-47393)\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\nscsi: qla2xxx: Fix a memory leak in an error path of qla2x00_process_els()\r\n\r\nCommit 8c0eb596baa5 (\u0026quot;[SCSI] qla2xxx: Fix a memory leak in an error path of\nqla2x00_process_els()\u0026quot;), intended to change:\r\n\r\n bsg_job-\u0026gt;request-\u0026gt;msgcode == FC_BSG_HST_ELS_NOLOGIN\r\n\r\n\n bsg_job-\u0026gt;request-\u0026gt;msgcode != FC_BSG_RPT_ELS\r\n\r\nbut changed it to:\r\n\r\n bsg_job-\u0026gt;request-\u0026gt;msgcode == FC_BSG_RPT_ELS\r\n\r\ninstead.\r\n\r\nChange the == to a != to avoid leaking the fcport structure or freeing\nunallocated memory.(CVE-2021-47473)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnvmem: Fix shift-out-of-bound (UBSAN) with byte size cells\r\n\r\nIf a cell has \u0026apos;nbits\u0026apos; equal to a multiple of BITS_PER_BYTE the logic\r\n\r\n *p \u0026amp;= GENMASK((cell-\u0026gt;nbits%BITS_PER_BYTE) - 1, 0);\r\n\r\nwill become undefined behavior because nbits modulo BITS_PER_BYTE is 0, and we\nsubtract one from that making a large number that is then shifted more than the\nnumber of bits that fit into an unsigned long.\r\n\r\nUBSAN reports this problem:\r\n\r\n UBSAN: shift-out-of-bounds in drivers/nvmem/core.c:1386:8\n shift exponent 64 is too large for 64-bit type \u0026apos;unsigned long\u0026apos;\n CPU: 6 PID: 7 Comm: kworker/u16:0 Not tainted 5.15.0-rc3+ #9\n Hardware name: Google Lazor (rev3+) with KB Backlight (DT)\n Workqueue: events_unbound deferred_probe_work_func\n Call trace:\n dump_backtrace+0x0/0x170\n show_stack+0x24/0x30\n dump_stack_lvl+0x64/0x7c\n dump_stack+0x18/0x38\n ubsan_epilogue+0x10/0x54\n __ubsan_handle_shift_out_of_bounds+0x180/0x194\n __nvmem_cell_read+0x1ec/0x21c\n nvmem_cell_read+0x58/0x94\n nvmem_cell_read_variable_common+0x4c/0xb0\n nvmem_cell_read_variable_le_u32+0x40/0x100\n a6xx_gpu_init+0x170/0x2f4\n adreno_bind+0x174/0x284\n component_bind_all+0xf0/0x264\n msm_drm_bind+0x1d8/0x7a0\n try_to_bring_up_master+0x164/0x1ac\n __component_add+0xbc/0x13c\n component_add+0x20/0x2c\n dp_display_probe+0x340/0x384\n platform_probe+0xc0/0x100\n really_probe+0x110/0x304\n __driver_probe_device+0xb8/0x120\n driver_probe_device+0x4c/0xfc\n __device_attach_driver+0xb0/0x128\n bus_for_each_drv+0x90/0xdc\n __device_attach+0xc8/0x174\n device_initial_probe+0x20/0x2c\n bus_probe_device+0x40/0xa4\n deferred_probe_work_func+0x7c/0xb8\n process_one_work+0x128/0x21c\n process_scheduled_works+0x40/0x54\n worker_thread+0x1ec/0x2a8\n kthread+0x138/0x158\n ret_from_fork+0x10/0x20\r\n\r\nFix it by making sure there are any bits to mask out.(CVE-2021-47497)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: mpt3sas: Fix use-after-free warning\r\n\r\nFix the following use-after-free warning which is observed during\ncontroller reset:\r\n\r\nrefcount_t: underflow; use-after-free.\nWARNING: CPU: 23 PID: 5399 at lib/refcount.c:28 refcount_warn_saturate+0xa6/0xf0(CVE-2022-48695)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnvmet: fix a use-after-free\r\n\r\nFix the following use-after-free complaint triggered by blktests nvme/004:\r\n\r\nBUG: KASAN: user-memory-access in blk_mq_complete_request_remote+0xac/0x350\nRead of size 4 at addr 0000607bd1835943 by task kworker/13:1/460\nWorkqueue: nvmet-wq nvme_loop_execute_work [nvme_loop]\nCall Trace:\n show_stack+0x52/0x58\n dump_stack_lvl+0x49/0x5e\n print_report.cold+0x36/0x1e2\n kasan_report+0xb9/0xf0\n __asan_load4+0x6b/0x80\n blk_mq_complete_request_remote+0xac/0x350\n nvme_loop_queue_response+0x1df/0x275 [nvme_loop]\n __nvmet_req_complete+0x132/0x4f0 [nvmet]\n nvmet_req_complete+0x15/0x40 [nvmet]\n nvmet_execute_io_connect+0x18a/0x1f0 [nvmet]\n nvme_loop_execute_work+0x20/0x30 [nvme_loop]\n process_one_work+0x56e/0xa70\n worker_thread+0x2d1/0x640\n kthread+0x183/0x1c0\n ret_from_fork+0x1f/0x30(CVE-2022-48697)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nALSA: emu10k1: Fix out of bounds access in snd_emu10k1_pcm_channel_alloc()\r\n\r\nThe voice allocator sometimes begins allocating from near the end of the\narray and then wraps around, however snd_emu10k1_pcm_channel_alloc()\naccesses the newly allocated voices as if it never wrapped around.\r\n\r\nThis results in out of bounds access if the first voice has a high enough\nindex so that first_voice + requested_voice_count \u0026gt; NUM_G (64).\nThe more voices are requested, the more likely it is for this to occur.\r\n\r\nThis was initially discovered using PipeWire, however it can be reproduced\nby calling aplay multiple times with 16 channels:\naplay -r 48000 -D plughw:CARD=Live,DEV=3 -c 16 /dev/zero\r\n\r\nUBSAN: array-index-out-of-bounds in sound/pci/emu10k1/emupcm.c:127:40\nindex 65 is out of range for type \u0026apos;snd_emu10k1_voice [64]\u0026apos;\nCPU: 1 PID: 31977 Comm: aplay Tainted: G W IOE 6.0.0-rc2-emu10k1+ #7\nHardware name: ASUSTEK COMPUTER INC P5W DH Deluxe/P5W DH Deluxe, BIOS 3002 07/22/2010\nCall Trace:\n\u0026lt;TASK\u0026gt;\ndump_stack_lvl+0x49/0x63\ndump_stack+0x10/0x16\nubsan_epilogue+0x9/0x3f\n__ubsan_handle_out_of_bounds.cold+0x44/0x49\nsnd_emu10k1_playback_hw_params+0x3bc/0x420 [snd_emu10k1]\nsnd_pcm_hw_params+0x29f/0x600 [snd_pcm]\nsnd_pcm_common_ioctl+0x188/0x1410 [snd_pcm]\n? exit_to_user_mode_prepare+0x35/0x170\n? do_syscall_64+0x69/0x90\n? syscall_exit_to_user_mode+0x26/0x50\n? do_syscall_64+0x69/0x90\n? exit_to_user_mode_prepare+0x35/0x170\nsnd_pcm_ioctl+0x27/0x40 [snd_pcm]\n__x64_sys_ioctl+0x95/0xd0\ndo_syscall_64+0x5c/0x90\n? do_syscall_64+0x69/0x90\n? do_syscall_64+0x69/0x90\nentry_SYSCALL_64_after_hwframe+0x63/0xcd(CVE-2022-48702)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/radeon: add a force flush to delay work when radeon\r\n\r\nAlthough radeon card fence and wait for gpu to finish processing current batch rings,\nthere is still a corner case that radeon lockup work queue may not be fully flushed,\nand meanwhile the radeon_suspend_kms() function has called pci_set_power_state() to\nput device in D3hot state.\nPer PCI spec rev 4.0 on 5.3.1.4.1 D3hot State.\n\u0026gt; Configuration and Message requests are the only TLPs accepted by a Function in\n\u0026gt; the D3hot state. All other received Requests must be handled as Unsupported Requests,\n\u0026gt; and all received Completions may optionally be handled as Unexpected Completions.\nThis issue will happen in following logs:\nUnable to handle kernel paging request at virtual address 00008800e0008010\nCPU 0 kworker/0:3(131): Oops 0\npc = [\u0026lt;ffffffff811bea5c\u0026gt;] ra = [\u0026lt;ffffffff81240844\u0026gt;] ps = 0000 Tainted: G W\npc is at si_gpu_check_soft_reset+0x3c/0x240\nra is at si_dma_is_lockup+0x34/0xd0\nv0 = 0000000000000000 t0 = fff08800e0008010 t1 = 0000000000010000\nt2 = 0000000000008010 t3 = fff00007e3c00000 t4 = fff00007e3c00258\nt5 = 000000000000ffff t6 = 0000000000000001 t7 = fff00007ef078000\ns0 = fff00007e3c016e8 s1 = fff00007e3c00000 s2 = fff00007e3c00018\ns3 = fff00007e3c00000 s4 = fff00007fff59d80 s5 = 0000000000000000\ns6 = fff00007ef07bd98\na0 = fff00007e3c00000 a1 = fff00007e3c016e8 a2 = 0000000000000008\na3 = 0000000000000001 a4 = 8f5c28f5c28f5c29 a5 = ffffffff810f4338\nt8 = 0000000000000275 t9 = ffffffff809b66f8 t10 = ff6769c5d964b800\nt11= 000000000000b886 pv = ffffffff811bea20 at = 0000000000000000\ngp = ffffffff81d89690 sp = 00000000aa814126\nDisabling lock debugging due to kernel taint\nTrace:\n[\u0026lt;ffffffff81240844\u0026gt;] si_dma_is_lockup+0x34/0xd0\n[\u0026lt;ffffffff81119610\u0026gt;] radeon_fence_check_lockup+0xd0/0x290\n[\u0026lt;ffffffff80977010\u0026gt;] process_one_work+0x280/0x550\n[\u0026lt;ffffffff80977350\u0026gt;] worker_thread+0x70/0x7c0\n[\u0026lt;ffffffff80977410\u0026gt;] worker_thread+0x130/0x7c0\n[\u0026lt;ffffffff80982040\u0026gt;] kthread+0x200/0x210\n[\u0026lt;ffffffff809772e0\u0026gt;] worker_thread+0x0/0x7c0\n[\u0026lt;ffffffff80981f8c\u0026gt;] kthread+0x14c/0x210\n[\u0026lt;ffffffff80911658\u0026gt;] ret_from_kernel_thread+0x18/0x20\n[\u0026lt;ffffffff80981e40\u0026gt;] kthread+0x0/0x210\n Code: ad3e0008 43f0074a ad7e0018 ad9e0020 8c3001e8 40230101\n \u0026lt;88210000\u0026gt; 4821ed21\nSo force lockup work queue flush to fix this problem.(CVE-2022-48704)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/radeon: fix a possible null pointer dereference\r\n\r\nIn radeon_fp_native_mode(), the return value of drm_mode_duplicate()\nis assigned to mode, which will lead to a NULL pointer dereference\non failure of drm_mode_duplicate(). Add a check to avoid npd.\r\n\r\nThe failure status of drm_cvt_mode() on the other path is checked too.(CVE-2022-48710)\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\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\npstore: ram_core: fix possible overflow in persistent_ram_init_ecc()\r\n\r\nIn persistent_ram_init_ecc(), on 64-bit arches DIV_ROUND_UP() will return\n64-bit value since persistent_ram_zone::buffer_size has type size_t which\nis derived from the 64-bit *unsigned long*, while the ecc_blocks variable\nthis value gets assigned to has (always 32-bit) *int* type. Even if that\nvalue fits into *int* type, an overflow is still possible when calculating\nthe size_t typed ecc_total variable further below since there\u0026apos;s no cast to\nany 64-bit type before multiplication. Declaring the ecc_blocks variable\nas *size_t* should fix this mess...\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with the SVACE static\nanalysis tool.(CVE-2023-52685)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/pm: fix a double-free in si_dpm_init\r\n\r\nWhen the allocation of\nadev-\u0026gt;pm.dpm.dyn_state.vddc_dependency_on_dispclk.entries fails,\namdgpu_free_extended_power_table is called to free some fields of adev.\nHowever, when the control flow returns to si_dpm_sw_init, it goes to\nlabel dpm_failed and calls si_dpm_fini, which calls\namdgpu_free_extended_power_table again and free those fields again. Thus\na double-free is triggered.(CVE-2023-52691)\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\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: 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\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\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\nnilfs2: fix failure to detect DAT corruption in btree and direct mappings\r\n\r\nPatch series \u0026quot;nilfs2: fix kernel bug at submit_bh_wbc()\u0026quot;.\r\n\r\nThis resolves a kernel BUG reported by syzbot. Since there are two\nflaws involved, I\u0026apos;ve made each one a separate patch.\r\n\r\nThe first patch alone resolves the syzbot-reported bug, but I think\nboth fixes should be sent to stable, so I\u0026apos;ve tagged them as such.\r\n\r\n\nThis patch (of 2):\r\n\r\nSyzbot has reported a kernel bug in submit_bh_wbc() when writing file data\nto a nilfs2 file system whose metadata is corrupted.\r\n\r\nThere are two flaws involved in this issue.\r\n\r\nThe first flaw is that when nilfs_get_block() locates a data block using\nbtree or direct mapping, if the disk address translation routine\nnilfs_dat_translate() fails with internal code -ENOENT due to DAT metadata\ncorruption, it can be passed back to nilfs_get_block(). This causes\nnilfs_get_block() to misidentify an existing block as non-existent,\ncausing both data block lookup and insertion to fail inconsistently.\r\n\r\nThe second flaw is that nilfs_get_block() returns a successful status in\nthis inconsistent state. This causes the caller __block_write_begin_int()\nor others to request a read even though the buffer is not mapped,\nresulting in a BUG_ON check for the BH_Mapped flag in submit_bh_wbc()\nfailing.\r\n\r\nThis fixes the first issue by changing the return value to code -EINVAL\nwhen a conversion using DAT fails with code -ENOENT, avoiding the\nconflicting condition that leads to the kernel bug described above. Here,\ncode -EINVAL indicates that metadata corruption was detected during the\nblock lookup, which will be properly handled as a file system error and\nconverted to -EIO when passing through the nilfs2 bmap layer.(CVE-2024-26956)\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\nmm: swap: fix race between free_swap_and_cache() and swapoff()\r\n\r\nThere was previously a theoretical window where swapoff() could run and\nteardown a swap_info_struct while a call to free_swap_and_cache() was\nrunning in another thread. This could cause, amongst other bad\npossibilities, swap_page_trans_huge_swapped() (called by\nfree_swap_and_cache()) to access the freed memory for swap_map.\r\n\r\nThis is a theoretical problem and I haven\u0026apos;t been able to provoke it from a\ntest case. But there has been agreement based on code review that this is\npossible (see link below).\r\n\r\nFix it by using get_swap_device()/put_swap_device(), which will stall\nswapoff(). There was an extra check in _swap_info_get() to confirm that\nthe swap entry was not free. This isn\u0026apos;t present in get_swap_device()\nbecause it doesn\u0026apos;t make sense in general due to the race between getting\nthe reference and swapoff. So I\u0026apos;ve added an equivalent check directly in\nfree_swap_and_cache().\r\n\r\nDetails of how to provoke one possible issue (thanks to David Hildenbrand\nfor deriving this):\r\n\r\n--8\u0026lt;-----\r\n\r\n__swap_entry_free() might be the last user and result in\n\u0026quot;count == SWAP_HAS_CACHE\u0026quot;.\r\n\r\nswapoff-\u0026gt;try_to_unuse() will stop as soon as soon as si-\u0026gt;inuse_pages==0.\r\n\r\nSo the question is: could someone reclaim the folio and turn\nsi-\u0026gt;inuse_pages==0, before we completed swap_page_trans_huge_swapped().\r\n\r\nImagine the following: 2 MiB folio in the swapcache. Only 2 subpages are\nstill references by swap entries.\r\n\r\nProcess 1 still references subpage 0 via swap entry.\nProcess 2 still references subpage 1 via swap entry.\r\n\r\nProcess 1 quits. Calls free_swap_and_cache().\n-\u0026gt; count == SWAP_HAS_CACHE\n[then, preempted in the hypervisor etc.]\r\n\r\nProcess 2 quits. Calls free_swap_and_cache().\n-\u0026gt; count == SWAP_HAS_CACHE\r\n\r\nProcess 2 goes ahead, passes swap_page_trans_huge_swapped(), and calls\n__try_to_reclaim_swap().\r\n\r\n__try_to_reclaim_swap()-\u0026gt;folio_free_swap()-\u0026gt;delete_from_swap_cache()-\u0026gt;\nput_swap_folio()-\u0026gt;free_swap_slot()-\u0026gt;swapcache_free_entries()-\u0026gt;\nswap_entry_free()-\u0026gt;swap_range_free()-\u0026gt;\n...\nWRITE_ONCE(si-\u0026gt;inuse_pages, si-\u0026gt;inuse_pages - nr_entries);\r\n\r\nWhat stops swapoff to succeed after process 2 reclaimed the swap cache\nbut before process1 finished its call to swap_page_trans_huge_swapped()?\r\n\r\n--8\u0026lt;-----(CVE-2024-26960)\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\nclk: qcom: mmcc-apq8084: 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-26966)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nclk: qcom: gcc-ipq8074: 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-26969)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncrypto: qat - resolve race condition during AER recovery\r\n\r\nDuring the PCI AER system\u0026apos;s error recovery process, the kernel driver\nmay encounter a race condition with freeing the reset_data structure\u0026apos;s\nmemory. If the device restart will take more than 10 seconds the function\nscheduling that restart will exit due to a timeout, and the reset_data\nstructure will be freed. However, this data structure is used for\ncompletion notification after the restart is completed, which leads\nto a UAF bug.\r\n\r\nThis results in a KFENCE bug notice.\r\n\r\n BUG: KFENCE: use-after-free read in adf_device_reset_worker+0x38/0xa0 [intel_qat]\n Use-after-free read at 0x00000000bc56fddf (in kfence-#142):\n adf_device_reset_worker+0x38/0xa0 [intel_qat]\n process_one_work+0x173/0x340\r\n\r\nTo resolve this race condition, the memory associated to the container\nof the work_struct is freed on the worker if the timeout expired,\notherwise on the function that schedules the worker.\nThe timeout detection can be done by checking if the caller is\nstill waiting for completion or not by using completion_done() function.(CVE-2024-26974)\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\nnilfs2: fix OOB in nilfs_set_de_type\r\n\r\nThe size of the nilfs_type_by_mode array in the fs/nilfs2/dir.c file is\ndefined as \u0026quot;S_IFMT \u0026gt;\u0026gt; S_SHIFT\u0026quot;, but the nilfs_set_de_type() function,\nwhich uses this array, specifies the index to read from the array in the\nsame way as \u0026quot;(mode \u0026amp; S_IFMT) \u0026gt;\u0026gt; S_SHIFT\u0026quot;.\r\n\r\nstatic void nilfs_set_de_type(struct nilfs_dir_entry *de, struct inode\n *inode)\n{\n\tumode_t mode = inode-\u0026gt;i_mode;\r\n\r\n\tde-\u0026gt;file_type = nilfs_type_by_mode[(mode \u0026amp; S_IFMT)\u0026gt;\u0026gt;S_SHIFT]; // oob\n}\r\n\r\nHowever, when the index is determined this way, an out-of-bounds (OOB)\nerror occurs by referring to an index that is 1 larger than the array size\nwhen the condition \u0026quot;mode \u0026amp; S_IFMT == S_IFMT\u0026quot; is satisfied. Therefore, a\npatch to resize the nilfs_type_by_mode array should be applied to prevent\nOOB errors.(CVE-2024-26981)\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\nusb: gadget: f_ncm: Fix UAF ncm object at re-bind after usb ep transport error\r\n\r\nWhen ncm function is working and then stop usb0 interface for link down,\neth_stop() is called. At this piont, accidentally if usb transport error\nshould happen in usb_ep_enable(), \u0026apos;in_ep\u0026apos; and/or \u0026apos;out_ep\u0026apos; may not be enabled.\r\n\r\nAfter that, ncm_disable() is called to disable for ncm unbind\nbut gether_disconnect() is never called since \u0026apos;in_ep\u0026apos; is not enabled.\r\n\r\nAs the result, ncm object is released in ncm unbind\nbut \u0026apos;dev-\u0026gt;port_usb\u0026apos; associated to \u0026apos;ncm-\u0026gt;port\u0026apos; is not NULL.\r\n\r\nAnd when ncm bind again to recover netdev, ncm object is reallocated\nbut usb0 interface is already associated to previous released ncm object.\r\n\r\nTherefore, once usb0 interface is up and eth_start_xmit() is called,\nreleased ncm object is dereferrenced and it might cause use-after-free memory.\r\n\r\n[function unlink via configfs]\n usb0: eth_stop dev-\u0026gt;port_usb=ffffff9b179c3200\n --\u0026gt; error happens in usb_ep_enable().\n NCM: ncm_disable: ncm=ffffff9b179c3200\n --\u0026gt; no gether_disconnect() since ncm-\u0026gt;port.in_ep-\u0026gt;enabled is false.\n NCM: ncm_unbind: ncm unbind ncm=ffffff9b179c3200\n NCM: ncm_free: ncm free ncm=ffffff9b179c3200 \u0026lt;-- released ncm\r\n\r\n[function link via configfs]\n NCM: ncm_alloc: ncm alloc ncm=ffffff9ac4f8a000\n NCM: ncm_bind: ncm bind ncm=ffffff9ac4f8a000\n NCM: ncm_set_alt: ncm=ffffff9ac4f8a000 alt=0\n usb0: eth_open dev-\u0026gt;port_usb=ffffff9b179c3200 \u0026lt;-- previous released ncm\n usb0: eth_start dev-\u0026gt;port_usb=ffffff9b179c3200 \u0026lt;--\n eth_start_xmit()\n --\u0026gt; dev-\u0026gt;wrap()\n Unable to handle kernel paging request at virtual address dead00000000014f\r\n\r\nThis patch addresses the issue by checking if \u0026apos;ncm-\u0026gt;netdev\u0026apos; is not NULL at\nncm_disable() to call gether_disconnect() to deassociate \u0026apos;dev-\u0026gt;port_usb\u0026apos;.\nIt\u0026apos;s more reasonable to check \u0026apos;ncm-\u0026gt;netdev\u0026apos; to call gether_connect/disconnect\nrather than check \u0026apos;ncm-\u0026gt;port.in_ep-\u0026gt;enabled\u0026apos; since it might not be enabled\nbut the gether connection might be established.(CVE-2024-26996)\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\ncomedi: vmk80xx: fix incomplete endpoint checking\r\n\r\nWhile vmk80xx does have endpoint checking implemented, some things\ncan fall through the cracks. Depending on the hardware model,\nURBs can have either bulk or interrupt type, and current version\nof vmk80xx_find_usb_endpoints() function does not take that fully\ninto account. While this warning does not seem to be too harmful,\nat the very least it will crash systems with \u0026apos;panic_on_warn\u0026apos; set on\nthem.\r\n\r\nFix the issue found by Syzkaller [1] by somewhat simplifying the\nendpoint checking process with usb_find_common_endpoints() and\nensuring that only expected endpoint types are present.\r\n\r\nThis patch has not been tested on real hardware.\r\n\r\n[1] Syzkaller report:\nusb 1-1: BOGUS urb xfer, pipe 1 != type 3\nWARNING: CPU: 0 PID: 781 at drivers/usb/core/urb.c:504 usb_submit_urb+0xc4e/0x18c0 drivers/usb/core/urb.c:503\n...\nCall Trace:\n \u0026lt;TASK\u0026gt;\n usb_start_wait_urb+0x113/0x520 drivers/usb/core/message.c:59\n vmk80xx_reset_device drivers/comedi/drivers/vmk80xx.c:227 [inline]\n vmk80xx_auto_attach+0xa1c/0x1a40 drivers/comedi/drivers/vmk80xx.c:818\n comedi_auto_config+0x238/0x380 drivers/comedi/drivers.c:1067\n usb_probe_interface+0x5cd/0xb00 drivers/usb/core/driver.c:399\n...\r\n\r\nSimilar issue also found by Syzkaller:(CVE-2024-27001)\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\nspi: spi-mt65xx: Fix NULL pointer access in interrupt handler\r\n\r\nThe TX buffer in spi_transfer can be a NULL pointer, so the interrupt\nhandler may end up writing to the invalid memory and cause crashes.\r\n\r\nAdd a check to trans-\u0026gt;tx_buf before using it.(CVE-2024-27028)\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\nnfp: flower: handle acti_netdevs allocation failure\r\n\r\nThe kmalloc_array() in nfp_fl_lag_do_work() will return null, if\nthe physical memory has run out. As a result, if we dereference\nthe acti_netdevs, the null pointer dereference bugs will happen.\r\n\r\nThis patch adds a check to judge whether allocation failure occurs.\nIf it happens, the delayed work will be rescheduled and try again.(CVE-2024-27046)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncpufreq: brcmstb-avs-cpufreq: add check for cpufreq_cpu_get\u0026apos;s return value\r\n\r\ncpufreq_cpu_get may return NULL. To avoid NULL-dereference check it\nand return 0 in case of error.\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-27051)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ns390/dasd: fix double module refcount decrement\r\n\r\nOnce the discipline is associated with the device, deleting the device\ntakes care of decrementing the module\u0026apos;s refcount. Doing it manually on\nthis error path causes refcount to artificially decrease on each error\nwhile it should just stay the same.(CVE-2024-27054)\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\nnouveau: lock the client object tree.\r\n\r\nIt appears the client object tree has no locking unless I\u0026apos;ve missed\nsomething else. Fix races around adding/removing client objects,\nmostly vram bar mappings.\r\n\r\n 4562.099306] general protection fault, probably for non-canonical address 0x6677ed422bceb80c: 0000 [#1] PREEMPT SMP PTI\n[ 4562.099314] CPU: 2 PID: 23171 Comm: deqp-vk Not tainted 6.8.0-rc6+ #27\n[ 4562.099324] Hardware name: Gigabyte Technology Co., Ltd. Z390 I AORUS PRO WIFI/Z390 I AORUS PRO WIFI-CF, BIOS F8 11/05/2021\n[ 4562.099330] RIP: 0010:nvkm_object_search+0x1d/0x70 [nouveau]\n[ 4562.099503] Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 0f 1f 44 00 00 48 89 f8 48 85 f6 74 39 48 8b 87 a0 00 00 00 48 85 c0 74 12 \u0026lt;48\u0026gt; 8b 48 f8 48 39 ce 73 15 48 8b 40 10 48 85 c0 75 ee 48 c7 c0 fe\n[ 4562.099506] RSP: 0000:ffffa94cc420bbf8 EFLAGS: 00010206\n[ 4562.099512] RAX: 6677ed422bceb814 RBX: ffff98108791f400 RCX: ffff9810f26b8f58\n[ 4562.099517] RDX: 0000000000000000 RSI: ffff9810f26b9158 RDI: ffff98108791f400\n[ 4562.099519] RBP: ffff9810f26b9158 R08: 0000000000000000 R09: 0000000000000000\n[ 4562.099521] R10: ffffa94cc420bc48 R11: 0000000000000001 R12: ffff9810f02a7cc0\n[ 4562.099526] R13: 0000000000000000 R14: 00000000000000ff R15: 0000000000000007\n[ 4562.099528] FS: 00007f629c5017c0(0000) GS:ffff98142c700000(0000) knlGS:0000000000000000\n[ 4562.099534] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 4562.099536] CR2: 00007f629a882000 CR3: 000000017019e004 CR4: 00000000003706f0\n[ 4562.099541] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[ 4562.099542] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[ 4562.099544] Call Trace:\n[ 4562.099555] \u0026lt;TASK\u0026gt;\n[ 4562.099573] ? die_addr+0x36/0x90\n[ 4562.099583] ? exc_general_protection+0x246/0x4a0\n[ 4562.099593] ? asm_exc_general_protection+0x26/0x30\n[ 4562.099600] ? nvkm_object_search+0x1d/0x70 [nouveau]\n[ 4562.099730] nvkm_ioctl+0xa1/0x250 [nouveau]\n[ 4562.099861] nvif_object_map_handle+0xc8/0x180 [nouveau]\n[ 4562.099986] nouveau_ttm_io_mem_reserve+0x122/0x270 [nouveau]\n[ 4562.100156] ? dma_resv_test_signaled+0x26/0xb0\n[ 4562.100163] ttm_bo_vm_fault_reserved+0x97/0x3c0 [ttm]\n[ 4562.100182] ? __mutex_unlock_slowpath+0x2a/0x270\n[ 4562.100189] nouveau_ttm_fault+0x69/0xb0 [nouveau]\n[ 4562.100356] __do_fault+0x32/0x150\n[ 4562.100362] do_fault+0x7c/0x560\n[ 4562.100369] __handle_mm_fault+0x800/0xc10\n[ 4562.100382] handle_mm_fault+0x17c/0x3e0\n[ 4562.100388] do_user_addr_fault+0x208/0x860\n[ 4562.100395] exc_page_fault+0x7f/0x200\n[ 4562.100402] asm_exc_page_fault+0x26/0x30\n[ 4562.100412] RIP: 0033:0x9b9870\n[ 4562.100419] Code: 85 a8 f7 ff ff 8b 8d 80 f7 ff ff 89 08 e9 18 f2 ff ff 0f 1f 84 00 00 00 00 00 44 89 32 e9 90 fa ff ff 0f 1f 84 00 00 00 00 00 \u0026lt;44\u0026gt; 89 32 e9 f8 f1 ff ff 0f 1f 84 00 00 00 00 00 66 44 89 32 e9 e7\n[ 4562.100422] RSP: 002b:00007fff9ba2dc70 EFLAGS: 00010246\n[ 4562.100426] RAX: 0000000000000004 RBX: 000000000dd65e10 RCX: 000000fff0000000\n[ 4562.100428] RDX: 00007f629a882000 RSI: 00007f629a882000 RDI: 0000000000000066\n[ 4562.100432] RBP: 00007fff9ba2e570 R08: 0000000000000000 R09: 0000000123ddf000\n[ 4562.100434] R10: 0000000000000001 R11: 0000000000000246 R12: 000000007fffffff\n[ 4562.100436] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000\n[ 4562.100446] \u0026lt;/TASK\u0026gt;\n[ 4562.100448] Modules linked in: nf_conntrack_netbios_ns nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables libcrc32c nfnetlink cmac bnep sunrpc iwlmvm intel_rapl_msr intel_rapl_common snd_sof_pci_intel_cnl x86_pkg_temp_thermal intel_powerclamp snd_sof_intel_hda_common mac80211 coretemp snd_soc_acpi_intel_match kvm_intel snd_soc_acpi snd_soc_hdac_hda snd_sof_pci snd_sof_xtensa_dsp snd_sof_intel_hda_mlink \n---truncated---(CVE-2024-27062)\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\nmedia: v4l2-mem2mem: fix a memleak in v4l2_m2m_register_entity\r\n\r\nThe entity-\u0026gt;name (i.e. name) is allocated in v4l2_m2m_register_entity\nbut isn\u0026apos;t freed in its following error-handling paths. This patch\nadds such deallocation to prevent memleak of entity-\u0026gt;name.(CVE-2024-27077)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: v4l2-tpg: fix some memleaks in tpg_alloc\r\n\r\nIn tpg_alloc, resources should be deallocated in each and every\nerror-handling paths, since they are allocated in for statements.\nOtherwise there would be memleaks because tpg_free is called only when\ntpg_alloc return 0.(CVE-2024-27078)\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\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\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:\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\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\nbtrfs: fix information leak in btrfs_ioctl_logical_to_ino()\r\n\r\nSyzbot reported the following information leak for in\nbtrfs_ioctl_logical_to_ino():\r\n\r\n BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline]\n BUG: KMSAN: kernel-infoleak in _copy_to_user+0xbc/0x110 lib/usercopy.c:40\n instrument_copy_to_user include/linux/instrumented.h:114 [inline]\n _copy_to_user+0xbc/0x110 lib/usercopy.c:40\n copy_to_user include/linux/uaccess.h:191 [inline]\n btrfs_ioctl_logical_to_ino+0x440/0x750 fs/btrfs/ioctl.c:3499\n btrfs_ioctl+0x714/0x1260\n vfs_ioctl fs/ioctl.c:51 [inline]\n __do_sys_ioctl fs/ioctl.c:904 [inline]\n __se_sys_ioctl+0x261/0x450 fs/ioctl.c:890\n __x64_sys_ioctl+0x96/0xe0 fs/ioctl.c:890\n x64_sys_call+0x1883/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:17\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\r\n\r\n Uninit was created at:\n __kmalloc_large_node+0x231/0x370 mm/slub.c:3921\n __do_kmalloc_node mm/slub.c:3954 [inline]\n __kmalloc_node+0xb07/0x1060 mm/slub.c:3973\n kmalloc_node include/linux/slab.h:648 [inline]\n kvmalloc_node+0xc0/0x2d0 mm/util.c:634\n kvmalloc include/linux/slab.h:766 [inline]\n init_data_container+0x49/0x1e0 fs/btrfs/backref.c:2779\n btrfs_ioctl_logical_to_ino+0x17c/0x750 fs/btrfs/ioctl.c:3480\n btrfs_ioctl+0x714/0x1260\n vfs_ioctl fs/ioctl.c:51 [inline]\n __do_sys_ioctl fs/ioctl.c:904 [inline]\n __se_sys_ioctl+0x261/0x450 fs/ioctl.c:890\n __x64_sys_ioctl+0x96/0xe0 fs/ioctl.c:890\n x64_sys_call+0x1883/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:17\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\r\n\r\n Bytes 40-65535 of 65536 are uninitialized\n Memory access of size 65536 starts at ffff888045a40000\r\n\r\nThis happens, because we\u0026apos;re copying a \u0026apos;struct btrfs_data_container\u0026apos; back\nto user-space. This btrfs_data_container is allocated in\n\u0026apos;init_data_container()\u0026apos; via kvmalloc(), which does not zero-fill the\nmemory.\r\n\r\nFix this by using kvzalloc() which zeroes out the memory on allocation.(CVE-2024-35849)\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: 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\ndrm/client: Fully protect modes[] with dev-\u0026gt;mode_config.mutex\r\n\r\nThe modes[] array contains pointers to modes on the connectors\u0026apos;\nmode lists, which are protected by dev-\u0026gt;mode_config.mutex.\nThus we need to extend modes[] the same protection or by the\ntime we use it the elements may already be pointing to\nfreed/reused memory.(CVE-2024-35950)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\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)",
"id": "OESA-2024-1678",
"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-1678"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47269"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47284"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47335"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47393"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47455"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47473"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47497"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48695"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48697"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48702"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48704"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48710"
},
{
"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-52683"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52685"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52691"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52698"
},
{
"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-52847"
},
{
"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-2024-26955"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26956"
},
{
"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-26960"
},
{
"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-26966"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26969"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26974"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26976"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26981"
},
{
"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-26996"
},
{
"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-27001"
},
{
"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-27028"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27037"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27046"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27051"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27054"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27059"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27062"
},
{
"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-27077"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27078"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27388"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27403"
},
{
"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-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-35835"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35849"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35886"
},
{
"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-35950"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35976"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35997"
}
],
"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-47269",
"CVE-2021-47284",
"CVE-2021-47335",
"CVE-2021-47393",
"CVE-2021-47455",
"CVE-2021-47473",
"CVE-2021-47497",
"CVE-2022-48695",
"CVE-2022-48697",
"CVE-2022-48702",
"CVE-2022-48704",
"CVE-2022-48710",
"CVE-2023-52650",
"CVE-2023-52652",
"CVE-2023-52653",
"CVE-2023-52656",
"CVE-2023-52683",
"CVE-2023-52685",
"CVE-2023-52691",
"CVE-2023-52698",
"CVE-2023-52817",
"CVE-2023-52818",
"CVE-2023-52835",
"CVE-2023-52840",
"CVE-2023-52847",
"CVE-2023-52867",
"CVE-2023-52868",
"CVE-2024-26955",
"CVE-2024-26956",
"CVE-2024-26957",
"CVE-2024-26958",
"CVE-2024-26960",
"CVE-2024-26961",
"CVE-2024-26965",
"CVE-2024-26966",
"CVE-2024-26969",
"CVE-2024-26974",
"CVE-2024-26976",
"CVE-2024-26981",
"CVE-2024-26982",
"CVE-2024-26993",
"CVE-2024-26994",
"CVE-2024-26996",
"CVE-2024-26999",
"CVE-2024-27000",
"CVE-2024-27001",
"CVE-2024-27008",
"CVE-2024-27010",
"CVE-2024-27011",
"CVE-2024-27024",
"CVE-2024-27028",
"CVE-2024-27037",
"CVE-2024-27046",
"CVE-2024-27051",
"CVE-2024-27054",
"CVE-2024-27059",
"CVE-2024-27062",
"CVE-2024-27072",
"CVE-2024-27073",
"CVE-2024-27075",
"CVE-2024-27077",
"CVE-2024-27078",
"CVE-2024-27388",
"CVE-2024-27403",
"CVE-2024-27419",
"CVE-2024-27426",
"CVE-2024-27427",
"CVE-2024-27428",
"CVE-2024-35805",
"CVE-2024-35806",
"CVE-2024-35815",
"CVE-2024-35835",
"CVE-2024-35849",
"CVE-2024-35886",
"CVE-2024-35898",
"CVE-2024-35922",
"CVE-2024-35930",
"CVE-2024-35936",
"CVE-2024-35950",
"CVE-2024-35976",
"CVE-2024-35997"
]
}
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-2123 (CVE-2022-48887)
Vulnerability from osv_openeuler – Published: 2024-09-14 11:07 – Updated: 2026-08-06 11:07 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
drm/vmwgfx: Remove rcu locks from user resources
User resource lookups used rcu to avoid two extra atomics. Unfortunately the rcu paths were buggy and it was easy to make the driver crash by submitting command buffers from two different threads. Because the lookups never show up in performance profiles replace them with a regular spin lock which fixes the races in accesses to those shared resources.
Fixes kernel oops'es in IGT's vmwgfx execution_buffer stress test and seen crashes with apps using shared resources.(CVE-2022-48887)
In the Linux kernel, the following vulnerability has been resolved:
btrfs: do not start relocation until in progress drops are done
We hit a bug with a recovering relocation on mount for one of our file systems in production. I reproduced this locally by injecting errors into snapshot delete with balance running at the same time. This presented as an error while looking up an extent item
WARNING: CPU: 5 PID: 1501 at fs/btrfs/extent-tree.c:866 lookup_inline_extent_backref+0x647/0x680 CPU: 5 PID: 1501 Comm: btrfs-balance Not tainted 5.16.0-rc8+ #8 RIP: 0010:lookup_inline_extent_backref+0x647/0x680 RSP: 0018:ffffae0a023ab960 EFLAGS: 00010202 RAX: 0000000000000001 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 000000000000000c RDI: 0000000000000000 RBP: ffff943fd2a39b60 R08: 0000000000000000 R09: 0000000000000001 R10: 0001434088152de0 R11: 0000000000000000 R12: 0000000001d05000 R13: ffff943fd2a39b60 R14: ffff943fdb96f2a0 R15: ffff9442fc923000 FS: 0000000000000000(0000) GS:ffff944e9eb40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f1157b1fca8 CR3: 000000010f092000 CR4: 0000000000350ee0 Call Trace: <TASK> insert_inline_extent_backref+0x46/0xd0 __btrfs_inc_extent_ref.isra.0+0x5f/0x200 ? btrfs_merge_delayed_refs+0x164/0x190 __btrfs_run_delayed_refs+0x561/0xfa0 ? btrfs_search_slot+0x7b4/0xb30 ? btrfs_update_root+0x1a9/0x2c0 btrfs_run_delayed_refs+0x73/0x1f0 ? btrfs_update_root+0x1a9/0x2c0 btrfs_commit_transaction+0x50/0xa50 ? btrfs_update_reloc_root+0x122/0x220 prepare_to_merge+0x29f/0x320 relocate_block_group+0x2b8/0x550 btrfs_relocate_block_group+0x1a6/0x350 btrfs_relocate_chunk+0x27/0xe0 btrfs_balance+0x777/0xe60 balance_kthread+0x35/0x50 ? btrfs_balance+0xe60/0xe60 kthread+0x16b/0x190 ? set_kthread_struct+0x40/0x40 ret_from_fork+0x22/0x30 </TASK>
Normally snapshot deletion and relocation are excluded from running at the same time by the fs_info->cleaner_mutex. However if we had a pending balance waiting to get the ->cleaner_mutex, and a snapshot deletion was running, and then the box crashed, we would come up in a state where we have a half deleted snapshot.
Again, in the normal case the snapshot deletion needs to complete before relocation can start, but in this case relocation could very well start before the snapshot deletion completes, as we simply add the root to the dead roots list and wait for the next time the cleaner runs to clean up the snapshot.
Fix this by setting a bit on the fs_info if we have any DEAD_ROOT's that had a pending drop_progress key. If they do then we know we were in the middle of the drop operation and set a flag on the fs_info. Then balance can wait until this flag is cleared to start up again.
If there are DEAD_ROOT's that don't have a drop_progress set then we're safe to start balance right away as we'll be properly protected by the cleaner_mutex.(CVE-2022-48901)
In the Linux kernel, the following vulnerability has been resolved:
btrfs: do not WARN_ON() if we have PageError set
Whenever we do any extent buffer operations we call assert_eb_page_uptodate() to complain loudly if we're operating on an non-uptodate page. Our overnight tests caught this warning earlier this week
WARNING: CPU: 1 PID: 553508 at fs/btrfs/extent_io.c:6849 assert_eb_page_uptodate+0x3f/0x50 CPU: 1 PID: 553508 Comm: kworker/u4:13 Tainted: G W 5.17.0-rc3+ #564 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014 Workqueue: btrfs-cache btrfs_work_helper RIP: 0010:assert_eb_page_uptodate+0x3f/0x50 RSP: 0018:ffffa961440a7c68 EFLAGS: 00010246 RAX: 0017ffffc0002112 RBX: ffffe6e74453f9c0 RCX: 0000000000001000 RDX: ffffe6e74467c887 RSI: ffffe6e74453f9c0 RDI: ffff8d4c5efc2fc0 RBP: 0000000000000d56 R08: ffff8d4d4a224000 R09: 0000000000000000 R10: 00015817fa9d1ef0 R11: 000000000000000c R12: 00000000000007b1 R13: ffff8d4c5efc2fc0 R14: 0000000001500000 R15: 0000000001cb1000 FS: 0000000000000000(0000) GS:ffff8d4dbbd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ff31d3448d8 CR3: 0000000118be8004 CR4: 0000000000370ee0 Call Trace:
extent_buffer_test_bit+0x3f/0x70 free_space_test_bit+0xa6/0xc0 load_free_space_tree+0x1f6/0x470 caching_thread+0x454/0x630 ? rcu_read_lock_sched_held+0x12/0x60 ? rcu_read_lock_sched_held+0x12/0x60 ? rcu_read_lock_sched_held+0x12/0x60 ? lock_release+0x1f0/0x2d0 btrfs_work_helper+0xf2/0x3e0 ? lock_release+0x1f0/0x2d0 ? finish_task_switch.isra.0+0xf9/0x3a0 process_one_work+0x26d/0x580 ? process_one_work+0x580/0x580 worker_thread+0x55/0x3b0 ? process_one_work+0x580/0x580 kthread+0xf0/0x120 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30
This was partially fixed by c2e39305299f01 ("btrfs: clear extent buffer uptodate when we fail to write it"), however all that fix did was keep us from finding extent buffers after a failed writeout. It didn't keep us from continuing to use a buffer that we already had found.
In this case we're searching the commit root to cache the block group, so we can start committing the transaction and switch the commit root and then start writing. After the switch we can look up an extent buffer that hasn't been written yet and start processing that block group. Then we fail to write that block out and clear Uptodate on the page, and then we start spewing these errors.
Normally we're protected by the tree lock to a certain degree here. If we read a block we have that block read locked, and we block the writer from locking the block before we submit it for the write. However this isn't necessarily fool proof because the read could happen before we do the submit_bio and after we locked and unlocked the extent buffer.
Also in this particular case we have path->skip_locking set, so that won't save us here. We'll simply get a block that was valid when we read it, but became invalid while we were using it.
What we really want is to catch the case where we've "read" a block but it's not marked Uptodate. On read we ClearPageError(), so if we're !Uptodate and !Error we know we didn't do the right thing for reading the page.
Fix this by checking !Uptodate && !Error, this way we will not complain if our buffer gets invalidated while we're using it, and we'll maintain the spirit of the check which is to make sure we have a fully in-cache block while we're messing with it.(CVE-2022-48902)
ntfs3 in the Linux kernel through 6.8.0 allows a physically proximate attacker to read kernel memory by mounting a filesystem (e.g., if a Linux distribution is configured to allow unprivileged mounts of removable media) and then leveraging local access to trigger an out-of-bounds read. A length value can be larger than the amount of memory allocated. NOTE: the supplier's perspective is that there is no vulnerability when an attack requires an attacker-modified filesystem image.(CVE-2023-45896)
In the Linux kernel, the following vulnerability has been resolved:
powerpc/pseries/memhp: Fix access beyond end of drmem array
dlpar_memory_remove_by_index() may access beyond the bounds of the drmem lmb array when the LMB lookup fails to match an entry with the given DRC index. When the search fails, the cursor is left pointing to &drmem_info->lmbs[drmem_info->n_lmbs], which is one element past the last valid entry in the array. The debug message at the end of the function then dereferences this pointer:
pr_debug("Failed to hot-remove memory at %llx\n",
lmb->base_addr);
This was found by inspection and confirmed with KASAN:
pseries-hotplug-mem: Attempting to hot-remove LMB, drc index 1234 ================================================================== BUG: KASAN: slab-out-of-bounds in dlpar_memory+0x298/0x1658 Read of size 8 at addr c000000364e97fd0 by task bash/949
dump_stack_lvl+0xa4/0xfc (unreliable) print_report+0x214/0x63c kasan_report+0x140/0x2e0 __asan_load8+0xa8/0xe0 dlpar_memory+0x298/0x1658 handle_dlpar_errorlog+0x130/0x1d0 dlpar_store+0x18c/0x3e0 kobj_attr_store+0x68/0xa0 sysfs_kf_write+0xc4/0x110 kernfs_fop_write_iter+0x26c/0x390 vfs_write+0x2d4/0x4e0 ksys_write+0xac/0x1a0 system_call_exception+0x268/0x530 system_call_vectored_common+0x15c/0x2ec
Allocated by task 1: kasan_save_stack+0x48/0x80 kasan_set_track+0x34/0x50 kasan_save_alloc_info+0x34/0x50 __kasan_kmalloc+0xd0/0x120 __kmalloc+0x8c/0x320 kmalloc_array.constprop.0+0x48/0x5c drmem_init+0x2a0/0x41c do_one_initcall+0xe0/0x5c0 kernel_init_freeable+0x4ec/0x5a0 kernel_init+0x30/0x1e0 ret_from_kernel_user_thread+0x14/0x1c
The buggy address belongs to the object at c000000364e80000 which belongs to the cache kmalloc-128k of size 131072 The buggy address is located 0 bytes to the right of allocated 98256-byte region [c000000364e80000, c000000364e97fd0)
================================================================== pseries-hotplug-mem: Failed to hot-remove memory at 0
Log failed lookups with a separate message and dereference the cursor only when it points to a valid entry.(CVE-2023-52451)
In the Linux kernel, the following vulnerability has been resolved:
serial: sc16is7xx: convert from raw to noinc regmap functions for FIFO
The SC16IS7XX IC supports a burst mode to access the FIFOs where the initial register address is sent ($00), followed by all the FIFO data without having to resend the register address each time. In this mode, the IC doesn't increment the register address for each R/W byte.
The regmap_raw_read() and regmap_raw_write() are functions which can perform IO over multiple registers. They are currently used to read/write from/to the FIFO, and although they operate correctly in this burst mode on the SPI bus, they would corrupt the regmap cache if it was not disabled manually. The reason is that when the R/W size is more than 1 byte, these functions assume that the register address is incremented and handle the cache accordingly.
Convert FIFO R/W functions to use the regmap noinc versions in order to remove the manual cache control which was a workaround when using the raw versions. FIFO registers are properly declared as volatile so cache will not be used/updated for FIFO accesses.(CVE-2023-52488)
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:
nfc: pn533: Wait for out_urb's completion in pn533_usb_send_frame()
Fix a use-after-free that occurs in hcd when in_urb sent from pn533_usb_send_frame() is completed earlier than out_urb. Its callback frees the skb data in pn533_send_async_complete() that is used as a transfer buffer of out_urb. Wait before sending in_urb until the callback of out_urb is called. To modify the callback of out_urb alone, separate the complete function of out_urb and ack_urb.
Found by a modified version of syzkaller.
BUG: KASAN: use-after-free in dummy_timer Call Trace: memcpy (mm/kasan/shadow.c:65) dummy_perform_transfer (drivers/usb/gadget/udc/dummy_hcd.c:1352) transfer (drivers/usb/gadget/udc/dummy_hcd.c:1453) dummy_timer (drivers/usb/gadget/udc/dummy_hcd.c:1972) arch_static_branch (arch/x86/include/asm/jump_label.h:27) static_key_false (include/linux/jump_label.h:207) timer_expire_exit (include/trace/events/timer.h:127) call_timer_fn (kernel/time/timer.c:1475) expire_timers (kernel/time/timer.c:1519) __run_timers (kernel/time/timer.c:1790) run_timer_softirq (kernel/time/timer.c:1803)(CVE-2023-52907)
In the Linux kernel, the following vulnerability has been resolved:
drm/i915/gem: Fix Virtual Memory mapping boundaries calculation
Calculating the size of the mapped area as the lesser value between the requested size and the actual size does not consider the partial mapping offset. This can cause page fault access.
Fix the calculation of the starting and ending addresses, the total size is now deduced from the difference between the end and start addresses.
Additionally, the calculations have been rewritten in a clearer and more understandable form.
[Joonas: Add Requires: tag] Requires: 60a2066c5005 ("drm/i915/gem: Adjust vma offset for framebuffer mmap offset") (cherry picked from commit 97b6784753da06d9d40232328efc5c5367e53417)(CVE-2024-42259)
In the Linux kernel, the following vulnerability has been resolved:
riscv/mm: Add handling for VM_FAULT_SIGSEGV in mm_fault_error()
Handle VM_FAULT_SIGSEGV in the page fault path so that we correctly kill the process and we don't BUG() the kernel.(CVE-2024-42267)
In the Linux kernel, the following vulnerability has been resolved:
nvme-pci: add missing condition check for existence of mapped data
nvme_map_data() is called when request has physical segments, hence the nvme_unmap_data() should have same condition to avoid dereference.(CVE-2024-42276)
In the Linux kernel, the following vulnerability has been resolved:
hfs: fix to initialize fields of hfs_inode_info after hfs_alloc_inode()
Syzbot reports uninitialized value access issue as below:
loop0: detected capacity change from 0 to 64
BUG: KMSAN: uninit-value in hfs_revalidate_dentry+0x307/0x3f0 fs/hfs/sysdep.c:30 hfs_revalidate_dentry+0x307/0x3f0 fs/hfs/sysdep.c:30 d_revalidate fs/namei.c:862 [inline] lookup_fast+0x89e/0x8e0 fs/namei.c:1649 walk_component fs/namei.c:2001 [inline] link_path_walk+0x817/0x1480 fs/namei.c:2332 path_lookupat+0xd9/0x6f0 fs/namei.c:2485 filename_lookup+0x22e/0x740 fs/namei.c:2515 user_path_at_empty+0x8b/0x390 fs/namei.c:2924 user_path_at include/linux/namei.h:57 [inline] do_mount fs/namespace.c:3689 [inline] __do_sys_mount fs/namespace.c:3898 [inline] __se_sys_mount+0x66b/0x810 fs/namespace.c:3875 __x64_sys_mount+0xe4/0x140 fs/namespace.c:3875 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b
BUG: KMSAN: uninit-value in hfs_ext_read_extent fs/hfs/extent.c:196 [inline] BUG: KMSAN: uninit-value in hfs_get_block+0x92d/0x1620 fs/hfs/extent.c:366 hfs_ext_read_extent fs/hfs/extent.c:196 [inline] hfs_get_block+0x92d/0x1620 fs/hfs/extent.c:366 block_read_full_folio+0x4ff/0x11b0 fs/buffer.c:2271 hfs_read_folio+0x55/0x60 fs/hfs/inode.c:39 filemap_read_folio+0x148/0x4f0 mm/filemap.c:2426 do_read_cache_folio+0x7c8/0xd90 mm/filemap.c:3553 do_read_cache_page mm/filemap.c:3595 [inline] read_cache_page+0xfb/0x2f0 mm/filemap.c:3604 read_mapping_page include/linux/pagemap.h:755 [inline] hfs_btree_open+0x928/0x1ae0 fs/hfs/btree.c:78 hfs_mdb_get+0x260c/0x3000 fs/hfs/mdb.c:204 hfs_fill_super+0x1fb1/0x2790 fs/hfs/super.c:406 mount_bdev+0x628/0x920 fs/super.c:1359 hfs_mount+0xcd/0xe0 fs/hfs/super.c:456 legacy_get_tree+0x167/0x2e0 fs/fs_context.c:610 vfs_get_tree+0xdc/0x5d0 fs/super.c:1489 do_new_mount+0x7a9/0x16f0 fs/namespace.c:3145 path_mount+0xf98/0x26a0 fs/namespace.c:3475 do_mount fs/namespace.c:3488 [inline] __do_sys_mount fs/namespace.c:3697 [inline] __se_sys_mount+0x919/0x9e0 fs/namespace.c:3674 __ia32_sys_mount+0x15b/0x1b0 fs/namespace.c:3674 do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline] __do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common.c:178 do_fast_syscall_32+0x37/0x80 arch/x86/entry/common.c:203 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/common.c:246 entry_SYSENTER_compat_after_hwframe+0x70/0x82
Uninit was created at: __alloc_pages+0x9a6/0xe00 mm/page_alloc.c:4590 __alloc_pages_node include/linux/gfp.h:238 [inline] alloc_pages_node include/linux/gfp.h:261 [inline] alloc_slab_page mm/slub.c:2190 [inline] allocate_slab mm/slub.c:2354 [inline] new_slab+0x2d7/0x1400 mm/slub.c:2407 slaballoc+0x16b5/0x3970 mm/slub.c:3540 slab_alloc mm/slub.c:3625 [inline] __slab_alloc_node mm/slub.c:3678 [inline] slab_alloc_node mm/slub.c:3850 [inline] kmem_cache_alloc_lru+0x64d/0xb30 mm/slub.c:3879 alloc_inode_sb include/linux/fs.h:3018 [inline] hfs_alloc_inode+0x5a/0xc0 fs/hfs/super.c:165 alloc_inode+0x83/0x440 fs/inode.c:260 new_inode_pseudo fs/inode.c:1005 [inline] new_inode+0x38/0x4f0 fs/inode.c:1031 hfs_new_inode+0x61/0x1010 fs/hfs/inode.c:186 hfs_mkdir+0x54/0x250 fs/hfs/dir.c:228 vfs_mkdir+0x49a/0x700 fs/namei.c:4126 do_mkdirat+0x529/0x810 fs/namei.c:4149 __do_sys_mkdirat fs/namei.c:4164 [inline] __se_sys_mkdirat fs/namei.c:4162 [inline] __x64_sys_mkdirat+0xc8/0x120 fs/namei.c:4162 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b
It missed to initialize .tz_secondswest, .cached_start and .cached_blocks fields in struct hfs_inode_info after hfs_alloc_inode(), fix it.(CVE-2024-42311)
In the Linux kernel, the following vulnerability has been resolved:
soc: qcom: pdr: protect locator_addr with the main mutex
If the service locator server is restarted fast enough, the PDR can rewrite locator_addr fields concurrently. Protect them by placing modification of those fields under the main pdr->lock.(CVE-2024-43849)
In the Linux kernel, the following vulnerability has been resolved:
dma: fix call order in dmam_free_coherent
dmam_free_coherent() frees a DMA allocation, which makes the freed vaddr available for reuse, then calls devres_destroy() to remove and free the data structure used to track the DMA allocation. Between the two calls, it is possible for a concurrent task to make an allocation with the same vaddr and add it to the devres list.
If this happens, there will be two entries in the devres list with the same vaddr and devres_destroy() can free the wrong entry, triggering the WARN_ON() in dmam_match.
Fix by destroying the devres entry before freeing the DMA allocation.
kokonut //net/encryption http://sponge2/b9145fe6-0f72-4325-ac2f-a84d81075b03(CVE-2024-43856)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix null pointer deref in dcn20_resource.c
Fixes a hang thats triggered when MPV is run on a DCN401 dGPU:
mpv --hwdec=vaapi --vo=gpu --hwdec-codecs=all
and then enabling fullscreen playback (double click on the video)
The following calltrace will be seen:
[ 181.843989] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 181.843997] #PF: supervisor instruction fetch in kernel mode [ 181.844003] #PF: error_code(0x0010) - not-present page [ 181.844009] PGD 0 P4D 0 [ 181.844020] Oops: 0010 [#1] PREEMPT SMP NOPTI [ 181.844028] CPU: 6 PID: 1892 Comm: gnome-shell Tainted: G W OE 6.5.0-41-generic #41~22.04.2-Ubuntu [ 181.844038] Hardware name: System manufacturer System Product Name/CROSSHAIR VI HERO, BIOS 6302 10/23/2018 [ 181.844044] RIP: 0010:0x0 [ 181.844079] Code: Unable to access opcode bytes at 0xffffffffffffffd6. [ 181.844084] RSP: 0018:ffffb593c2b8f7b0 EFLAGS: 00010246 [ 181.844093] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000004 [ 181.844099] RDX: ffffb593c2b8f804 RSI: ffffb593c2b8f7e0 RDI: ffff9e3c8e758400 [ 181.844105] RBP: ffffb593c2b8f7b8 R08: ffffb593c2b8f9c8 R09: ffffb593c2b8f96c [ 181.844110] R10: 0000000000000000 R11: 0000000000000000 R12: ffffb593c2b8f9c8 [ 181.844115] R13: 0000000000000001 R14: ffff9e3c88000000 R15: 0000000000000005 [ 181.844121] FS: 00007c6e323bb5c0(0000) GS:ffff9e3f85f80000(0000) knlGS:0000000000000000 [ 181.844128] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 181.844134] CR2: ffffffffffffffd6 CR3: 0000000140fbe000 CR4: 00000000003506e0 [ 181.844141] Call Trace: [ 181.844146] <TASK> [ 181.844153] ? show_regs+0x6d/0x80 [ 181.844167] ? __die+0x24/0x80 [ 181.844179] ? page_fault_oops+0x99/0x1b0 [ 181.844192] ? do_user_addr_fault+0x31d/0x6b0 [ 181.844204] ? exc_page_fault+0x83/0x1b0 [ 181.844216] ? asm_exc_page_fault+0x27/0x30 [ 181.844237] dcn20_get_dcc_compression_cap+0x23/0x30 [amdgpu] [ 181.845115] amdgpu_dm_plane_validate_dcc.constprop.0+0xe5/0x180 [amdgpu] [ 181.845985] amdgpu_dm_plane_fill_plane_buffer_attributes+0x300/0x580 [amdgpu] [ 181.846848] fill_dc_plane_info_and_addr+0x258/0x350 [amdgpu] [ 181.847734] fill_dc_plane_attributes+0x162/0x350 [amdgpu] [ 181.848748] dm_update_plane_state.constprop.0+0x4e3/0x6b0 [amdgpu] [ 181.849791] ? dm_update_plane_state.constprop.0+0x4e3/0x6b0 [amdgpu] [ 181.850840] amdgpu_dm_atomic_check+0xdfe/0x1760 amdgpu
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Add null checker before passing variables
Checks null pointer before passing variables to functions.
This fixes 3 NULL_RETURNS issues reported by Coverity.(CVE-2024-43902)
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu/pm: Fix the null pointer dereference in apply_state_adjust_rules
Check the pointer value to fix potential null pointer dereference(CVE-2024-43907)
In the Linux kernel, the following vulnerability has been resolved:
md/raid5: avoid BUG_ON() while continue reshape after reassembling
Currently, mdadm support --revert-reshape to abort the reshape while reassembling, as the test 07revert-grow. However, following BUG_ON() can be triggerred by the test:
kernel BUG at drivers/md/raid5.c:6278! invalid opcode: 0000 [#1] PREEMPT SMP PTI irq event stamp: 158985 CPU: 6 PID: 891 Comm: md0_reshape Not tainted 6.9.0-03335-g7592a0b0049a #94 RIP: 0010:reshape_request+0x3f1/0xe60 Call Trace: <TASK> raid5_sync_request+0x43d/0x550 md_do_sync+0xb7a/0x2110 md_thread+0x294/0x2b0 kthread+0x147/0x1c0 ret_from_fork+0x59/0x70 ret_from_fork_asm+0x1a/0x30 </TASK>
Root cause is that --revert-reshape update the raid_disks from 5 to 4, while reshape position is still set, and after reassembling the array, reshape position will be read from super block, then during reshape the checking of 'writepos' that is caculated by old reshape position will fail.
Fix this panic the easy way first, by converting the BUG_ON() to WARN_ON(), and stop the reshape if checkings fail.
Noted that mdadm must fix --revert-shape as well, and probably md/raid should enhance metadata validation as well, however this means reassemble will fail and there must be user tools to fix the wrong metadata.(CVE-2024-43914)
In the Linux kernel, the following vulnerability has been resolved:
sctp: Fix null-ptr-deref in reuseport_add_sock().
syzbot reported a null-ptr-deref while accessing sk2->sk_reuseport_cb in reuseport_add_sock(). [0]
The repro first creates a listener with SO_REUSEPORT. Then, it creates another listener on the same port and concurrently closes the first listener.
The second listen() calls reuseport_add_sock() with the first listener as sk2, where sk2->sk_reuseport_cb is not expected to be cleared concurrently, but the close() does clear it by reuseport_detach_sock().
The problem is SCTP does not properly synchronise reuseport_alloc(), reuseport_add_sock(), and reuseport_detach_sock().
The caller of reuseport_alloc() and reuseport_{add,detach}_sock() must provide synchronisation for sockets that are classified into the same reuseport group.
Otherwise, such sockets form multiple identical reuseport groups, and all groups except one would be silently dead.
- Two sockets call listen() concurrently
- No socket in the same group found in sctp_ep_hashtable[]
- Two sockets call reuseport_alloc() and form two reuseport groups
- Only one group hit first in __sctp_rcv_lookup_endpoint() receives incoming packets
Also, the reported null-ptr-deref could occur.
TCP/UDP guarantees that would not happen by holding the hash bucket lock.
Let's apply the locking strategy to __sctp_hash_endpoint() and __sctp_unhash_endpoint().
[0]: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] CPU: 1 UID: 0 PID: 10230 Comm: syz-executor119 Not tainted 6.10.0-syzkaller-12585-g301927d2d2eb #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024 RIP: 0010:reuseport_add_sock+0x27e/0x5e0 net/core/sock_reuseport.c:350 Code: 00 0f b7 5d 00 bf 01 00 00 00 89 de e8 1b a4 ff f7 83 fb 01 0f 85 a3 01 00 00 e8 6d a0 ff f7 49 8d 7e 12 48 89 f8 48 c1 e8 03 <42> 0f b6 04 28 84 c0 0f 85 4b 02 00 00 41 0f b7 5e 12 49 8d 7e 14 RSP: 0018:ffffc9000b947c98 EFLAGS: 00010202 RAX: 0000000000000002 RBX: ffff8880252ddf98 RCX: ffff888079478000 RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000012 RBP: 0000000000000001 R08: ffffffff8993e18d R09: 1ffffffff1fef385 R10: dffffc0000000000 R11: fffffbfff1fef386 R12: ffff8880252ddac0 R13: dffffc0000000000 R14: 0000000000000000 R15: 0000000000000000 FS: 00007f24e45b96c0(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffcced5f7b8 CR3: 00000000241be000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __sctp_hash_endpoint net/sctp/input.c:762 [inline] sctp_hash_endpoint+0x52a/0x600 net/sctp/input.c:790 sctp_listen_start net/sctp/socket.c:8570 [inline] sctp_inet_listen+0x767/0xa20 net/sctp/socket.c:8625 __sys_listen_socket net/socket.c:1883 [inline] __sys_listen+0x1b7/0x230 net/socket.c:1894 __do_sys_listen net/socket.c:1902 [inline] __se_sys_listen net/socket.c:1900 [inline] __x64_sys_listen+0x5a/0x70 net/socket.c:1900 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f24e46039b9 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 91 1a 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:00007f24e45b9228 EFLAGS: 00000246 ORIG_RAX: 0000000000000032 RAX: ffffffffffffffda RBX: 00007f24e468e428 RCX: 00007f24e46039b9 RDX: 00007f24e46039b9 RSI: 0000000000000003 RDI: 0000000000000004 RBP: 00007f24e468e420 R08: 00007f24e45b96c0 R09: 00007f24e45b96c0 R10: 00007f24e45b96c0 R11: 0000000000000246 R12: 00007f24e468e42c R13: ---truncated---(CVE-2024-44935)
In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to do sanity check on F2FS_INLINE_DATA flag in inode during GC
syzbot reports a f2fs bug as below:
------------[ cut here ]------------ kernel BUG at fs/f2fs/inline.c:258! CPU: 1 PID: 34 Comm: kworker/u8:2 Not tainted 6.9.0-rc6-syzkaller-00012-g9e4bc4bcae01 #0 RIP: 0010:f2fs_write_inline_data+0x781/0x790 fs/f2fs/inline.c:258 Call Trace: f2fs_write_single_data_page+0xb65/0x1d60 fs/f2fs/data.c:2834 f2fs_write_cache_pages fs/f2fs/data.c:3133 [inline] __f2fs_write_data_pages fs/f2fs/data.c:3288 [inline] f2fs_write_data_pages+0x1efe/0x3a90 fs/f2fs/data.c:3315 do_writepages+0x35b/0x870 mm/page-writeback.c:2612 __writeback_single_inode+0x165/0x10b0 fs/fs-writeback.c:1650 writeback_sb_inodes+0x905/0x1260 fs/fs-writeback.c:1941 wb_writeback+0x457/0xce0 fs/fs-writeback.c:2117 wb_do_writeback fs/fs-writeback.c:2264 [inline] wb_workfn+0x410/0x1090 fs/fs-writeback.c:2304 process_one_work kernel/workqueue.c:3254 [inline] process_scheduled_works+0xa12/0x17c0 kernel/workqueue.c:3335 worker_thread+0x86d/0xd70 kernel/workqueue.c:3416 kthread+0x2f2/0x390 kernel/kthread.c:388 ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
The root cause is: inline_data inode can be fuzzed, so that there may be valid blkaddr in its direct node, once f2fs triggers background GC to migrate the block, it will hit f2fs_bug_on() during dirty page writeback.
Let's add sanity check on F2FS_INLINE_DATA flag in inode during GC, so that, it can forbid migrating inline_data inode's data block for fixing.(CVE-2024-44942)
In the Linux kernel, the following vulnerability has been resolved:
fuse: Initialize beyond-EOF page contents before setting uptodate
fuse_notify_store(), unlike fuse_do_readpage(), does not enable page zeroing (because it can be used to change partial page contents).
So fuse_notify_store() must be more careful to fully initialize page contents (including parts of the page that are beyond end-of-file) before marking the page uptodate.
The current code can leave beyond-EOF page contents uninitialized, which makes these uninitialized page contents visible to userspace via mmap().
This is an information leak, but only affects systems which do not enable init-on-alloc (via CONFIG_INIT_ON_ALLOC_DEFAULT_ON=y or the corresponding kernel command line parameter).(CVE-2024-44947)
In the Linux kernel, the following vulnerability has been resolved:
net: dsa: bcm_sf2: Fix a possible memory leak in bcm_sf2_mdio_register()
bcm_sf2_mdio_register() calls of_phy_find_device() and then phy_device_remove() in a loop to remove existing PHY devices. of_phy_find_device() eventually calls bus_find_device(), which calls get_device() on the returned struct device * to increment the refcount. The current implementation does not decrement the refcount, which causes memory leak.
This commit adds the missing phy_device_free() call to decrement the refcount via put_device() to balance the refcount.(CVE-2024-44971)
| URL | Type | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"kernel-5.10.0-136.93.0.174.oe2203sp1.aarch64.rpm",
"kernel-debuginfo-5.10.0-136.93.0.174.oe2203sp1.aarch64.rpm",
"kernel-debugsource-5.10.0-136.93.0.174.oe2203sp1.aarch64.rpm",
"kernel-devel-5.10.0-136.93.0.174.oe2203sp1.aarch64.rpm",
"kernel-headers-5.10.0-136.93.0.174.oe2203sp1.aarch64.rpm",
"kernel-source-5.10.0-136.93.0.174.oe2203sp1.aarch64.rpm",
"kernel-tools-5.10.0-136.93.0.174.oe2203sp1.aarch64.rpm",
"kernel-tools-debuginfo-5.10.0-136.93.0.174.oe2203sp1.aarch64.rpm",
"kernel-tools-devel-5.10.0-136.93.0.174.oe2203sp1.aarch64.rpm",
"perf-5.10.0-136.93.0.174.oe2203sp1.aarch64.rpm",
"perf-debuginfo-5.10.0-136.93.0.174.oe2203sp1.aarch64.rpm",
"python3-perf-5.10.0-136.93.0.174.oe2203sp1.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-136.93.0.174.oe2203sp1.aarch64.rpm"
],
"src": [
"kernel-5.10.0-136.93.0.174.oe2203sp1.src.rpm"
],
"x86_64": [
"kernel-5.10.0-136.93.0.174.oe2203sp1.x86_64.rpm",
"kernel-debuginfo-5.10.0-136.93.0.174.oe2203sp1.x86_64.rpm",
"kernel-debugsource-5.10.0-136.93.0.174.oe2203sp1.x86_64.rpm",
"kernel-devel-5.10.0-136.93.0.174.oe2203sp1.x86_64.rpm",
"kernel-headers-5.10.0-136.93.0.174.oe2203sp1.x86_64.rpm",
"kernel-source-5.10.0-136.93.0.174.oe2203sp1.x86_64.rpm",
"kernel-tools-5.10.0-136.93.0.174.oe2203sp1.x86_64.rpm",
"kernel-tools-debuginfo-5.10.0-136.93.0.174.oe2203sp1.x86_64.rpm",
"kernel-tools-devel-5.10.0-136.93.0.174.oe2203sp1.x86_64.rpm",
"perf-5.10.0-136.93.0.174.oe2203sp1.x86_64.rpm",
"perf-debuginfo-5.10.0-136.93.0.174.oe2203sp1.x86_64.rpm",
"python3-perf-5.10.0-136.93.0.174.oe2203sp1.x86_64.rpm",
"python3-perf-debuginfo-5.10.0-136.93.0.174.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.93.0.174.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/vmwgfx: Remove rcu locks from user resources\r\n\r\nUser resource lookups used rcu to avoid two extra atomics. Unfortunately\nthe rcu paths were buggy and it was easy to make the driver crash by\nsubmitting command buffers from two different threads. Because the\nlookups never show up in performance profiles replace them with a\nregular spin lock which fixes the races in accesses to those shared\nresources.\r\n\r\nFixes kernel oops\u0026apos;es in IGT\u0026apos;s vmwgfx execution_buffer stress test and\nseen crashes with apps using shared resources.(CVE-2022-48887)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: do not start relocation until in progress drops are done\r\n\r\nWe hit a bug with a recovering relocation on mount for one of our file\nsystems in production. I reproduced this locally by injecting errors\ninto snapshot delete with balance running at the same time. This\npresented as an error while looking up an extent item\r\n\r\n WARNING: CPU: 5 PID: 1501 at fs/btrfs/extent-tree.c:866 lookup_inline_extent_backref+0x647/0x680\n CPU: 5 PID: 1501 Comm: btrfs-balance Not tainted 5.16.0-rc8+ #8\n RIP: 0010:lookup_inline_extent_backref+0x647/0x680\n RSP: 0018:ffffae0a023ab960 EFLAGS: 00010202\n RAX: 0000000000000001 RBX: 0000000000000000 RCX: 0000000000000000\n RDX: 0000000000000000 RSI: 000000000000000c RDI: 0000000000000000\n RBP: ffff943fd2a39b60 R08: 0000000000000000 R09: 0000000000000001\n R10: 0001434088152de0 R11: 0000000000000000 R12: 0000000001d05000\n R13: ffff943fd2a39b60 R14: ffff943fdb96f2a0 R15: ffff9442fc923000\n FS: 0000000000000000(0000) GS:ffff944e9eb40000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00007f1157b1fca8 CR3: 000000010f092000 CR4: 0000000000350ee0\n Call Trace:\n \u0026lt;TASK\u0026gt;\n insert_inline_extent_backref+0x46/0xd0\n __btrfs_inc_extent_ref.isra.0+0x5f/0x200\n ? btrfs_merge_delayed_refs+0x164/0x190\n __btrfs_run_delayed_refs+0x561/0xfa0\n ? btrfs_search_slot+0x7b4/0xb30\n ? btrfs_update_root+0x1a9/0x2c0\n btrfs_run_delayed_refs+0x73/0x1f0\n ? btrfs_update_root+0x1a9/0x2c0\n btrfs_commit_transaction+0x50/0xa50\n ? btrfs_update_reloc_root+0x122/0x220\n prepare_to_merge+0x29f/0x320\n relocate_block_group+0x2b8/0x550\n btrfs_relocate_block_group+0x1a6/0x350\n btrfs_relocate_chunk+0x27/0xe0\n btrfs_balance+0x777/0xe60\n balance_kthread+0x35/0x50\n ? btrfs_balance+0xe60/0xe60\n kthread+0x16b/0x190\n ? set_kthread_struct+0x40/0x40\n ret_from_fork+0x22/0x30\n \u0026lt;/TASK\u0026gt;\r\n\r\nNormally snapshot deletion and relocation are excluded from running at\nthe same time by the fs_info-\u0026gt;cleaner_mutex. However if we had a\npending balance waiting to get the -\u0026gt;cleaner_mutex, and a snapshot\ndeletion was running, and then the box crashed, we would come up in a\nstate where we have a half deleted snapshot.\r\n\r\nAgain, in the normal case the snapshot deletion needs to complete before\nrelocation can start, but in this case relocation could very well start\nbefore the snapshot deletion completes, as we simply add the root to the\ndead roots list and wait for the next time the cleaner runs to clean up\nthe snapshot.\r\n\r\nFix this by setting a bit on the fs_info if we have any DEAD_ROOT\u0026apos;s that\nhad a pending drop_progress key. If they do then we know we were in the\nmiddle of the drop operation and set a flag on the fs_info. Then\nbalance can wait until this flag is cleared to start up again.\r\n\r\nIf there are DEAD_ROOT\u0026apos;s that don\u0026apos;t have a drop_progress set then we\u0026apos;re\nsafe to start balance right away as we\u0026apos;ll be properly protected by the\ncleaner_mutex.(CVE-2022-48901)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: do not WARN_ON() if we have PageError set\r\n\r\nWhenever we do any extent buffer operations we call\nassert_eb_page_uptodate() to complain loudly if we\u0026apos;re operating on an\nnon-uptodate page. Our overnight tests caught this warning earlier this\nweek\r\n\r\n WARNING: CPU: 1 PID: 553508 at fs/btrfs/extent_io.c:6849 assert_eb_page_uptodate+0x3f/0x50\n CPU: 1 PID: 553508 Comm: kworker/u4:13 Tainted: G W 5.17.0-rc3+ #564\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014\n Workqueue: btrfs-cache btrfs_work_helper\n RIP: 0010:assert_eb_page_uptodate+0x3f/0x50\n RSP: 0018:ffffa961440a7c68 EFLAGS: 00010246\n RAX: 0017ffffc0002112 RBX: ffffe6e74453f9c0 RCX: 0000000000001000\n RDX: ffffe6e74467c887 RSI: ffffe6e74453f9c0 RDI: ffff8d4c5efc2fc0\n RBP: 0000000000000d56 R08: ffff8d4d4a224000 R09: 0000000000000000\n R10: 00015817fa9d1ef0 R11: 000000000000000c R12: 00000000000007b1\n R13: ffff8d4c5efc2fc0 R14: 0000000001500000 R15: 0000000001cb1000\n FS: 0000000000000000(0000) GS:ffff8d4dbbd00000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00007ff31d3448d8 CR3: 0000000118be8004 CR4: 0000000000370ee0\n Call Trace:\r\n\r\n extent_buffer_test_bit+0x3f/0x70\n free_space_test_bit+0xa6/0xc0\n load_free_space_tree+0x1f6/0x470\n caching_thread+0x454/0x630\n ? rcu_read_lock_sched_held+0x12/0x60\n ? rcu_read_lock_sched_held+0x12/0x60\n ? rcu_read_lock_sched_held+0x12/0x60\n ? lock_release+0x1f0/0x2d0\n btrfs_work_helper+0xf2/0x3e0\n ? lock_release+0x1f0/0x2d0\n ? finish_task_switch.isra.0+0xf9/0x3a0\n process_one_work+0x26d/0x580\n ? process_one_work+0x580/0x580\n worker_thread+0x55/0x3b0\n ? process_one_work+0x580/0x580\n kthread+0xf0/0x120\n ? kthread_complete_and_exit+0x20/0x20\n ret_from_fork+0x1f/0x30\r\n\r\nThis was partially fixed by c2e39305299f01 (\u0026quot;btrfs: clear extent buffer\nuptodate when we fail to write it\u0026quot;), however all that fix did was keep\nus from finding extent buffers after a failed writeout. It didn\u0026apos;t keep\nus from continuing to use a buffer that we already had found.\r\n\r\nIn this case we\u0026apos;re searching the commit root to cache the block group,\nso we can start committing the transaction and switch the commit root\nand then start writing. After the switch we can look up an extent\nbuffer that hasn\u0026apos;t been written yet and start processing that block\ngroup. Then we fail to write that block out and clear Uptodate on the\npage, and then we start spewing these errors.\r\n\r\nNormally we\u0026apos;re protected by the tree lock to a certain degree here. If\nwe read a block we have that block read locked, and we block the writer\nfrom locking the block before we submit it for the write. However this\nisn\u0026apos;t necessarily fool proof because the read could happen before we do\nthe submit_bio and after we locked and unlocked the extent buffer.\r\n\r\nAlso in this particular case we have path-\u0026gt;skip_locking set, so that\nwon\u0026apos;t save us here. We\u0026apos;ll simply get a block that was valid when we\nread it, but became invalid while we were using it.\r\n\r\nWhat we really want is to catch the case where we\u0026apos;ve \u0026quot;read\u0026quot; a block but\nit\u0026apos;s not marked Uptodate. On read we ClearPageError(), so if we\u0026apos;re\n!Uptodate and !Error we know we didn\u0026apos;t do the right thing for reading\nthe page.\r\n\r\nFix this by checking !Uptodate \u0026amp;\u0026amp; !Error, this way we will not complain\nif our buffer gets invalidated while we\u0026apos;re using it, and we\u0026apos;ll maintain\nthe spirit of the check which is to make sure we have a fully in-cache\nblock while we\u0026apos;re messing with it.(CVE-2022-48902)\r\n\r\nntfs3 in the Linux kernel through 6.8.0 allows a physically proximate attacker to read kernel memory by mounting a filesystem (e.g., if a Linux distribution is configured to allow unprivileged mounts of removable media) and then leveraging local access to trigger an out-of-bounds read. A length value can be larger than the amount of memory allocated. NOTE: the supplier\u0026apos;s perspective is that there is no vulnerability when an attack requires an attacker-modified filesystem image.(CVE-2023-45896)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npowerpc/pseries/memhp: Fix access beyond end of drmem array\r\n\r\ndlpar_memory_remove_by_index() may access beyond the bounds of the\ndrmem lmb array when the LMB lookup fails to match an entry with the\ngiven DRC index. When the search fails, the cursor is left pointing to\n\u0026amp;drmem_info-\u0026gt;lmbs[drmem_info-\u0026gt;n_lmbs], which is one element past the\nlast valid entry in the array. The debug message at the end of the\nfunction then dereferences this pointer:\r\n\r\n pr_debug(\u0026quot;Failed to hot-remove memory at %llx\\n\u0026quot;,\n lmb-\u0026gt;base_addr);\r\n\r\nThis was found by inspection and confirmed with KASAN:\r\n\r\n pseries-hotplug-mem: Attempting to hot-remove LMB, drc index 1234\n ==================================================================\n BUG: KASAN: slab-out-of-bounds in dlpar_memory+0x298/0x1658\n Read of size 8 at addr c000000364e97fd0 by task bash/949\r\n\r\n dump_stack_lvl+0xa4/0xfc (unreliable)\n print_report+0x214/0x63c\n kasan_report+0x140/0x2e0\n __asan_load8+0xa8/0xe0\n dlpar_memory+0x298/0x1658\n handle_dlpar_errorlog+0x130/0x1d0\n dlpar_store+0x18c/0x3e0\n kobj_attr_store+0x68/0xa0\n sysfs_kf_write+0xc4/0x110\n kernfs_fop_write_iter+0x26c/0x390\n vfs_write+0x2d4/0x4e0\n ksys_write+0xac/0x1a0\n system_call_exception+0x268/0x530\n system_call_vectored_common+0x15c/0x2ec\r\n\r\n Allocated by task 1:\n kasan_save_stack+0x48/0x80\n kasan_set_track+0x34/0x50\n kasan_save_alloc_info+0x34/0x50\n __kasan_kmalloc+0xd0/0x120\n __kmalloc+0x8c/0x320\n kmalloc_array.constprop.0+0x48/0x5c\n drmem_init+0x2a0/0x41c\n do_one_initcall+0xe0/0x5c0\n kernel_init_freeable+0x4ec/0x5a0\n kernel_init+0x30/0x1e0\n ret_from_kernel_user_thread+0x14/0x1c\r\n\r\n The buggy address belongs to the object at c000000364e80000\n which belongs to the cache kmalloc-128k of size 131072\n The buggy address is located 0 bytes to the right of\n allocated 98256-byte region [c000000364e80000, c000000364e97fd0)\r\n\r\n ==================================================================\n pseries-hotplug-mem: Failed to hot-remove memory at 0\r\n\r\nLog failed lookups with a separate message and dereference the\ncursor only when it points to a valid entry.(CVE-2023-52451)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nserial: sc16is7xx: convert from _raw_ to _noinc_ regmap functions for FIFO\r\n\r\nThe SC16IS7XX IC supports a burst mode to access the FIFOs where the\ninitial register address is sent ($00), followed by all the FIFO data\nwithout having to resend the register address each time. In this mode, the\nIC doesn\u0026apos;t increment the register address for each R/W byte.\r\n\r\nThe regmap_raw_read() and regmap_raw_write() are functions which can\nperform IO over multiple registers. They are currently used to read/write\nfrom/to the FIFO, and although they operate correctly in this burst mode on\nthe SPI bus, they would corrupt the regmap cache if it was not disabled\nmanually. The reason is that when the R/W size is more than 1 byte, these\nfunctions assume that the register address is incremented and handle the\ncache accordingly.\r\n\r\nConvert FIFO R/W functions to use the regmap _noinc_ versions in order to\nremove the manual cache control which was a workaround when using the\n_raw_ versions. FIFO registers are properly declared as volatile so\ncache will not be used/updated for FIFO accesses.(CVE-2023-52488)\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\nnfc: pn533: Wait for out_urb\u0026apos;s completion in pn533_usb_send_frame()\r\n\r\nFix a use-after-free that occurs in hcd when in_urb sent from\npn533_usb_send_frame() is completed earlier than out_urb. Its callback\nfrees the skb data in pn533_send_async_complete() that is used as a\ntransfer buffer of out_urb. Wait before sending in_urb until the\ncallback of out_urb is called. To modify the callback of out_urb alone,\nseparate the complete function of out_urb and ack_urb.\r\n\r\nFound by a modified version of syzkaller.\r\n\r\nBUG: KASAN: use-after-free in dummy_timer\nCall Trace:\n memcpy (mm/kasan/shadow.c:65)\n dummy_perform_transfer (drivers/usb/gadget/udc/dummy_hcd.c:1352)\n transfer (drivers/usb/gadget/udc/dummy_hcd.c:1453)\n dummy_timer (drivers/usb/gadget/udc/dummy_hcd.c:1972)\n arch_static_branch (arch/x86/include/asm/jump_label.h:27)\n static_key_false (include/linux/jump_label.h:207)\n timer_expire_exit (include/trace/events/timer.h:127)\n call_timer_fn (kernel/time/timer.c:1475)\n expire_timers (kernel/time/timer.c:1519)\n __run_timers (kernel/time/timer.c:1790)\n run_timer_softirq (kernel/time/timer.c:1803)(CVE-2023-52907)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/i915/gem: Fix Virtual Memory mapping boundaries calculation\r\n\r\nCalculating the size of the mapped area as the lesser value\nbetween the requested size and the actual size does not consider\nthe partial mapping offset. This can cause page fault access.\r\n\r\nFix the calculation of the starting and ending addresses, the\ntotal size is now deduced from the difference between the end and\nstart addresses.\r\n\r\nAdditionally, the calculations have been rewritten in a clearer\nand more understandable form.\r\n\r\n[Joonas: Add Requires: tag]\nRequires: 60a2066c5005 (\u0026quot;drm/i915/gem: Adjust vma offset for framebuffer mmap offset\u0026quot;)\n(cherry picked from commit 97b6784753da06d9d40232328efc5c5367e53417)(CVE-2024-42259)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nriscv/mm: Add handling for VM_FAULT_SIGSEGV in mm_fault_error()\r\n\r\nHandle VM_FAULT_SIGSEGV in the page fault path so that we correctly\nkill the process and we don\u0026apos;t BUG() the kernel.(CVE-2024-42267)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnvme-pci: add missing condition check for existence of mapped data\r\n\r\nnvme_map_data() is called when request has physical segments, hence\nthe nvme_unmap_data() should have same condition to avoid dereference.(CVE-2024-42276)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nhfs: fix to initialize fields of hfs_inode_info after hfs_alloc_inode()\r\n\r\nSyzbot reports uninitialized value access issue as below:\r\n\r\nloop0: detected capacity change from 0 to 64\n=====================================================\nBUG: KMSAN: uninit-value in hfs_revalidate_dentry+0x307/0x3f0 fs/hfs/sysdep.c:30\n hfs_revalidate_dentry+0x307/0x3f0 fs/hfs/sysdep.c:30\n d_revalidate fs/namei.c:862 [inline]\n lookup_fast+0x89e/0x8e0 fs/namei.c:1649\n walk_component fs/namei.c:2001 [inline]\n link_path_walk+0x817/0x1480 fs/namei.c:2332\n path_lookupat+0xd9/0x6f0 fs/namei.c:2485\n filename_lookup+0x22e/0x740 fs/namei.c:2515\n user_path_at_empty+0x8b/0x390 fs/namei.c:2924\n user_path_at include/linux/namei.h:57 [inline]\n do_mount fs/namespace.c:3689 [inline]\n __do_sys_mount fs/namespace.c:3898 [inline]\n __se_sys_mount+0x66b/0x810 fs/namespace.c:3875\n __x64_sys_mount+0xe4/0x140 fs/namespace.c:3875\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x63/0x6b\r\n\r\nBUG: KMSAN: uninit-value in hfs_ext_read_extent fs/hfs/extent.c:196 [inline]\nBUG: KMSAN: uninit-value in hfs_get_block+0x92d/0x1620 fs/hfs/extent.c:366\n hfs_ext_read_extent fs/hfs/extent.c:196 [inline]\n hfs_get_block+0x92d/0x1620 fs/hfs/extent.c:366\n block_read_full_folio+0x4ff/0x11b0 fs/buffer.c:2271\n hfs_read_folio+0x55/0x60 fs/hfs/inode.c:39\n filemap_read_folio+0x148/0x4f0 mm/filemap.c:2426\n do_read_cache_folio+0x7c8/0xd90 mm/filemap.c:3553\n do_read_cache_page mm/filemap.c:3595 [inline]\n read_cache_page+0xfb/0x2f0 mm/filemap.c:3604\n read_mapping_page include/linux/pagemap.h:755 [inline]\n hfs_btree_open+0x928/0x1ae0 fs/hfs/btree.c:78\n hfs_mdb_get+0x260c/0x3000 fs/hfs/mdb.c:204\n hfs_fill_super+0x1fb1/0x2790 fs/hfs/super.c:406\n mount_bdev+0x628/0x920 fs/super.c:1359\n hfs_mount+0xcd/0xe0 fs/hfs/super.c:456\n legacy_get_tree+0x167/0x2e0 fs/fs_context.c:610\n vfs_get_tree+0xdc/0x5d0 fs/super.c:1489\n do_new_mount+0x7a9/0x16f0 fs/namespace.c:3145\n path_mount+0xf98/0x26a0 fs/namespace.c:3475\n do_mount fs/namespace.c:3488 [inline]\n __do_sys_mount fs/namespace.c:3697 [inline]\n __se_sys_mount+0x919/0x9e0 fs/namespace.c:3674\n __ia32_sys_mount+0x15b/0x1b0 fs/namespace.c:3674\n do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline]\n __do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common.c:178\n do_fast_syscall_32+0x37/0x80 arch/x86/entry/common.c:203\n do_SYSENTER_32+0x1f/0x30 arch/x86/entry/common.c:246\n entry_SYSENTER_compat_after_hwframe+0x70/0x82\r\n\r\nUninit was created at:\n __alloc_pages+0x9a6/0xe00 mm/page_alloc.c:4590\n __alloc_pages_node include/linux/gfp.h:238 [inline]\n alloc_pages_node include/linux/gfp.h:261 [inline]\n alloc_slab_page mm/slub.c:2190 [inline]\n allocate_slab mm/slub.c:2354 [inline]\n new_slab+0x2d7/0x1400 mm/slub.c:2407\n ___slab_alloc+0x16b5/0x3970 mm/slub.c:3540\n __slab_alloc mm/slub.c:3625 [inline]\n __slab_alloc_node mm/slub.c:3678 [inline]\n slab_alloc_node mm/slub.c:3850 [inline]\n kmem_cache_alloc_lru+0x64d/0xb30 mm/slub.c:3879\n alloc_inode_sb include/linux/fs.h:3018 [inline]\n hfs_alloc_inode+0x5a/0xc0 fs/hfs/super.c:165\n alloc_inode+0x83/0x440 fs/inode.c:260\n new_inode_pseudo fs/inode.c:1005 [inline]\n new_inode+0x38/0x4f0 fs/inode.c:1031\n hfs_new_inode+0x61/0x1010 fs/hfs/inode.c:186\n hfs_mkdir+0x54/0x250 fs/hfs/dir.c:228\n vfs_mkdir+0x49a/0x700 fs/namei.c:4126\n do_mkdirat+0x529/0x810 fs/namei.c:4149\n __do_sys_mkdirat fs/namei.c:4164 [inline]\n __se_sys_mkdirat fs/namei.c:4162 [inline]\n __x64_sys_mkdirat+0xc8/0x120 fs/namei.c:4162\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x63/0x6b\r\n\r\nIt missed to initialize .tz_secondswest, .cached_start and .cached_blocks\nfields in struct hfs_inode_info after hfs_alloc_inode(), fix it.(CVE-2024-42311)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsoc: qcom: pdr: protect locator_addr with the main mutex\r\n\r\nIf the service locator server is restarted fast enough, the PDR can\nrewrite locator_addr fields concurrently. Protect them by placing\nmodification of those fields under the main pdr-\u0026gt;lock.(CVE-2024-43849)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndma: fix call order in dmam_free_coherent\r\n\r\ndmam_free_coherent() frees a DMA allocation, which makes the\nfreed vaddr available for reuse, then calls devres_destroy()\nto remove and free the data structure used to track the DMA\nallocation. Between the two calls, it is possible for a\nconcurrent task to make an allocation with the same vaddr\nand add it to the devres list.\r\n\r\nIf this happens, there will be two entries in the devres list\nwith the same vaddr and devres_destroy() can free the wrong\nentry, triggering the WARN_ON() in dmam_match.\r\n\r\nFix by destroying the devres entry before freeing the DMA\nallocation.\r\n\r\n kokonut //net/encryption\n http://sponge2/b9145fe6-0f72-4325-ac2f-a84d81075b03(CVE-2024-43856)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Fix null pointer deref in dcn20_resource.c\r\n\r\nFixes a hang thats triggered when MPV is run on a DCN401 dGPU:\r\n\r\nmpv --hwdec=vaapi --vo=gpu --hwdec-codecs=all\r\n\r\nand then enabling fullscreen playback (double click on the video)\r\n\r\nThe following calltrace will be seen:\r\n\r\n[ 181.843989] BUG: kernel NULL pointer dereference, address: 0000000000000000\n[ 181.843997] #PF: supervisor instruction fetch in kernel mode\n[ 181.844003] #PF: error_code(0x0010) - not-present page\n[ 181.844009] PGD 0 P4D 0\n[ 181.844020] Oops: 0010 [#1] PREEMPT SMP NOPTI\n[ 181.844028] CPU: 6 PID: 1892 Comm: gnome-shell Tainted: G W OE 6.5.0-41-generic #41~22.04.2-Ubuntu\n[ 181.844038] Hardware name: System manufacturer System Product Name/CROSSHAIR VI HERO, BIOS 6302 10/23/2018\n[ 181.844044] RIP: 0010:0x0\n[ 181.844079] Code: Unable to access opcode bytes at 0xffffffffffffffd6.\n[ 181.844084] RSP: 0018:ffffb593c2b8f7b0 EFLAGS: 00010246\n[ 181.844093] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000004\n[ 181.844099] RDX: ffffb593c2b8f804 RSI: ffffb593c2b8f7e0 RDI: ffff9e3c8e758400\n[ 181.844105] RBP: ffffb593c2b8f7b8 R08: ffffb593c2b8f9c8 R09: ffffb593c2b8f96c\n[ 181.844110] R10: 0000000000000000 R11: 0000000000000000 R12: ffffb593c2b8f9c8\n[ 181.844115] R13: 0000000000000001 R14: ffff9e3c88000000 R15: 0000000000000005\n[ 181.844121] FS: 00007c6e323bb5c0(0000) GS:ffff9e3f85f80000(0000) knlGS:0000000000000000\n[ 181.844128] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 181.844134] CR2: ffffffffffffffd6 CR3: 0000000140fbe000 CR4: 00000000003506e0\n[ 181.844141] Call Trace:\n[ 181.844146] \u0026lt;TASK\u0026gt;\n[ 181.844153] ? show_regs+0x6d/0x80\n[ 181.844167] ? __die+0x24/0x80\n[ 181.844179] ? page_fault_oops+0x99/0x1b0\n[ 181.844192] ? do_user_addr_fault+0x31d/0x6b0\n[ 181.844204] ? exc_page_fault+0x83/0x1b0\n[ 181.844216] ? asm_exc_page_fault+0x27/0x30\n[ 181.844237] dcn20_get_dcc_compression_cap+0x23/0x30 [amdgpu]\n[ 181.845115] amdgpu_dm_plane_validate_dcc.constprop.0+0xe5/0x180 [amdgpu]\n[ 181.845985] amdgpu_dm_plane_fill_plane_buffer_attributes+0x300/0x580 [amdgpu]\n[ 181.846848] fill_dc_plane_info_and_addr+0x258/0x350 [amdgpu]\n[ 181.847734] fill_dc_plane_attributes+0x162/0x350 [amdgpu]\n[ 181.848748] dm_update_plane_state.constprop.0+0x4e3/0x6b0 [amdgpu]\n[ 181.849791] ? dm_update_plane_state.constprop.0+0x4e3/0x6b0 [amdgpu]\n[ 181.850840] amdgpu_dm_atomic_check+0xdfe/0x1760 [amdgpu](CVE-2024-43899)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Add null checker before passing variables\r\n\r\nChecks null pointer before passing variables to functions.\r\n\r\nThis fixes 3 NULL_RETURNS issues reported by Coverity.(CVE-2024-43902)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu/pm: Fix the null pointer dereference in apply_state_adjust_rules\r\n\r\nCheck the pointer value to fix potential null pointer\ndereference(CVE-2024-43907)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmd/raid5: avoid BUG_ON() while continue reshape after reassembling\r\n\r\nCurrently, mdadm support --revert-reshape to abort the reshape while\nreassembling, as the test 07revert-grow. However, following BUG_ON()\ncan be triggerred by the test:\r\n\r\nkernel BUG at drivers/md/raid5.c:6278!\ninvalid opcode: 0000 [#1] PREEMPT SMP PTI\nirq event stamp: 158985\nCPU: 6 PID: 891 Comm: md0_reshape Not tainted 6.9.0-03335-g7592a0b0049a #94\nRIP: 0010:reshape_request+0x3f1/0xe60\nCall Trace:\n \u0026lt;TASK\u0026gt;\n raid5_sync_request+0x43d/0x550\n md_do_sync+0xb7a/0x2110\n md_thread+0x294/0x2b0\n kthread+0x147/0x1c0\n ret_from_fork+0x59/0x70\n ret_from_fork_asm+0x1a/0x30\n \u0026lt;/TASK\u0026gt;\r\n\r\nRoot cause is that --revert-reshape update the raid_disks from 5 to 4,\nwhile reshape position is still set, and after reassembling the array,\nreshape position will be read from super block, then during reshape the\nchecking of \u0026apos;writepos\u0026apos; that is caculated by old reshape position will\nfail.\r\n\r\nFix this panic the easy way first, by converting the BUG_ON() to\nWARN_ON(), and stop the reshape if checkings fail.\r\n\r\nNoted that mdadm must fix --revert-shape as well, and probably md/raid\nshould enhance metadata validation as well, however this means\nreassemble will fail and there must be user tools to fix the wrong\nmetadata.(CVE-2024-43914)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsctp: Fix null-ptr-deref in reuseport_add_sock().\r\n\r\nsyzbot reported a null-ptr-deref while accessing sk2-\u0026gt;sk_reuseport_cb in\nreuseport_add_sock(). [0]\r\n\r\nThe repro first creates a listener with SO_REUSEPORT. Then, it creates\nanother listener on the same port and concurrently closes the first\nlistener.\r\n\r\nThe second listen() calls reuseport_add_sock() with the first listener as\nsk2, where sk2-\u0026gt;sk_reuseport_cb is not expected to be cleared concurrently,\nbut the close() does clear it by reuseport_detach_sock().\r\n\r\nThe problem is SCTP does not properly synchronise reuseport_alloc(),\nreuseport_add_sock(), and reuseport_detach_sock().\r\n\r\nThe caller of reuseport_alloc() and reuseport_{add,detach}_sock() must\nprovide synchronisation for sockets that are classified into the same\nreuseport group.\r\n\r\nOtherwise, such sockets form multiple identical reuseport groups, and\nall groups except one would be silently dead.\r\n\r\n 1. Two sockets call listen() concurrently\n 2. No socket in the same group found in sctp_ep_hashtable[]\n 3. Two sockets call reuseport_alloc() and form two reuseport groups\n 4. Only one group hit first in __sctp_rcv_lookup_endpoint() receives\n incoming packets\r\n\r\nAlso, the reported null-ptr-deref could occur.\r\n\r\nTCP/UDP guarantees that would not happen by holding the hash bucket lock.\r\n\r\nLet\u0026apos;s apply the locking strategy to __sctp_hash_endpoint() and\n__sctp_unhash_endpoint().\r\n\r\n[0]:\nOops: general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN PTI\nKASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]\nCPU: 1 UID: 0 PID: 10230 Comm: syz-executor119 Not tainted 6.10.0-syzkaller-12585-g301927d2d2eb #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024\nRIP: 0010:reuseport_add_sock+0x27e/0x5e0 net/core/sock_reuseport.c:350\nCode: 00 0f b7 5d 00 bf 01 00 00 00 89 de e8 1b a4 ff f7 83 fb 01 0f 85 a3 01 00 00 e8 6d a0 ff f7 49 8d 7e 12 48 89 f8 48 c1 e8 03 \u0026lt;42\u0026gt; 0f b6 04 28 84 c0 0f 85 4b 02 00 00 41 0f b7 5e 12 49 8d 7e 14\nRSP: 0018:ffffc9000b947c98 EFLAGS: 00010202\nRAX: 0000000000000002 RBX: ffff8880252ddf98 RCX: ffff888079478000\nRDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000012\nRBP: 0000000000000001 R08: ffffffff8993e18d R09: 1ffffffff1fef385\nR10: dffffc0000000000 R11: fffffbfff1fef386 R12: ffff8880252ddac0\nR13: dffffc0000000000 R14: 0000000000000000 R15: 0000000000000000\nFS: 00007f24e45b96c0(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007ffcced5f7b8 CR3: 00000000241be000 CR4: 00000000003506f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __sctp_hash_endpoint net/sctp/input.c:762 [inline]\n sctp_hash_endpoint+0x52a/0x600 net/sctp/input.c:790\n sctp_listen_start net/sctp/socket.c:8570 [inline]\n sctp_inet_listen+0x767/0xa20 net/sctp/socket.c:8625\n __sys_listen_socket net/socket.c:1883 [inline]\n __sys_listen+0x1b7/0x230 net/socket.c:1894\n __do_sys_listen net/socket.c:1902 [inline]\n __se_sys_listen net/socket.c:1900 [inline]\n __x64_sys_listen+0x5a/0x70 net/socket.c:1900\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7f24e46039b9\nCode: 28 00 00 00 75 05 48 83 c4 28 c3 e8 91 1a 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:00007f24e45b9228 EFLAGS: 00000246 ORIG_RAX: 0000000000000032\nRAX: ffffffffffffffda RBX: 00007f24e468e428 RCX: 00007f24e46039b9\nRDX: 00007f24e46039b9 RSI: 0000000000000003 RDI: 0000000000000004\nRBP: 00007f24e468e420 R08: 00007f24e45b96c0 R09: 00007f24e45b96c0\nR10: 00007f24e45b96c0 R11: 0000000000000246 R12: 00007f24e468e42c\nR13:\n---truncated---(CVE-2024-44935)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nf2fs: fix to do sanity check on F2FS_INLINE_DATA flag in inode during GC\r\n\r\nsyzbot reports a f2fs bug as below:\r\n\r\n------------[ cut here ]------------\nkernel BUG at fs/f2fs/inline.c:258!\nCPU: 1 PID: 34 Comm: kworker/u8:2 Not tainted 6.9.0-rc6-syzkaller-00012-g9e4bc4bcae01 #0\nRIP: 0010:f2fs_write_inline_data+0x781/0x790 fs/f2fs/inline.c:258\nCall Trace:\n f2fs_write_single_data_page+0xb65/0x1d60 fs/f2fs/data.c:2834\n f2fs_write_cache_pages fs/f2fs/data.c:3133 [inline]\n __f2fs_write_data_pages fs/f2fs/data.c:3288 [inline]\n f2fs_write_data_pages+0x1efe/0x3a90 fs/f2fs/data.c:3315\n do_writepages+0x35b/0x870 mm/page-writeback.c:2612\n __writeback_single_inode+0x165/0x10b0 fs/fs-writeback.c:1650\n writeback_sb_inodes+0x905/0x1260 fs/fs-writeback.c:1941\n wb_writeback+0x457/0xce0 fs/fs-writeback.c:2117\n wb_do_writeback fs/fs-writeback.c:2264 [inline]\n wb_workfn+0x410/0x1090 fs/fs-writeback.c:2304\n process_one_work kernel/workqueue.c:3254 [inline]\n process_scheduled_works+0xa12/0x17c0 kernel/workqueue.c:3335\n worker_thread+0x86d/0xd70 kernel/workqueue.c:3416\n kthread+0x2f2/0x390 kernel/kthread.c:388\n ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244\r\n\r\nThe root cause is: inline_data inode can be fuzzed, so that there may\nbe valid blkaddr in its direct node, once f2fs triggers background GC\nto migrate the block, it will hit f2fs_bug_on() during dirty page\nwriteback.\r\n\r\nLet\u0026apos;s add sanity check on F2FS_INLINE_DATA flag in inode during GC,\nso that, it can forbid migrating inline_data inode\u0026apos;s data block for\nfixing.(CVE-2024-44942)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfuse: Initialize beyond-EOF page contents before setting uptodate\r\n\r\nfuse_notify_store(), unlike fuse_do_readpage(), does not enable page\nzeroing (because it can be used to change partial page contents).\r\n\r\nSo fuse_notify_store() must be more careful to fully initialize page\ncontents (including parts of the page that are beyond end-of-file)\nbefore marking the page uptodate.\r\n\r\nThe current code can leave beyond-EOF page contents uninitialized, which\nmakes these uninitialized page contents visible to userspace via mmap().\r\n\r\nThis is an information leak, but only affects systems which do not\nenable init-on-alloc (via CONFIG_INIT_ON_ALLOC_DEFAULT_ON=y or the\ncorresponding kernel command line parameter).(CVE-2024-44947)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: dsa: bcm_sf2: Fix a possible memory leak in bcm_sf2_mdio_register()\r\n\r\nbcm_sf2_mdio_register() calls of_phy_find_device() and then\nphy_device_remove() in a loop to remove existing PHY devices.\nof_phy_find_device() eventually calls bus_find_device(), which calls\nget_device() on the returned struct device * to increment the refcount.\nThe current implementation does not decrement the refcount, which causes\nmemory leak.\r\n\r\nThis commit adds the missing phy_device_free() call to decrement the\nrefcount via put_device() to balance the refcount.(CVE-2024-44971)",
"id": "OESA-2024-2123",
"modified": "2026-08-06T11:07:35Z",
"published": "2024-09-14T11:07:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2123"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48887"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48901"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48902"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-45896"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52451"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52488"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52868"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52907"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42259"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42267"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42276"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42311"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43849"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43856"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43899"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43902"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43907"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43914"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44935"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44942"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44947"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44971"
}
],
"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-2022-48887",
"CVE-2022-48901",
"CVE-2022-48902",
"CVE-2023-45896",
"CVE-2023-52451",
"CVE-2023-52488",
"CVE-2023-52868",
"CVE-2023-52907",
"CVE-2024-42259",
"CVE-2024-42267",
"CVE-2024-42276",
"CVE-2024-42311",
"CVE-2024-43849",
"CVE-2024-43856",
"CVE-2024-43899",
"CVE-2024-43902",
"CVE-2024-43907",
"CVE-2024-43914",
"CVE-2024-44935",
"CVE-2024-44942",
"CVE-2024-44947",
"CVE-2024-44971"
]
}
SSA-613116
Vulnerability from csaf_siemens - Published: 2025-08-12 00:00 - Updated: 2026-02-24 00:00SUSE-SU-2024:2008-1
Vulnerability from csaf_suse - Published: 2024-06-12 11:33 - Updated: 2026-09-20 15:53SUSE-SU-2024:2011-1
Vulnerability from csaf_suse - Published: 2024-06-12 16:39 - Updated: 2026-09-20 15:53SUSE-SU-2024:2019-1
Vulnerability from csaf_suse - Published: 2024-06-13 10:40 - Updated: 2026-09-20 15:53SUSE-SU-2024:2189-1
Vulnerability from csaf_suse - Published: 2024-06-25 06:34 - Updated: 2024-06-25 06:34SUSE-SU-2024:2190-1
Vulnerability from csaf_suse - Published: 2024-06-25 08:50 - Updated: 2026-09-20 15:55SUSE-SU-2024:2571-1
Vulnerability from csaf_suse - Published: 2024-07-22 10:34 - Updated: 2026-09-20 16:00Sightings
| 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.