Action not permitted
Modal body text goes here.
Modal Title
Modal Body
CVE-2024-26917 (GCVE-0-2024-26917)
Vulnerability from cvelistv5 – Published: 2024-04-17 15:59 – Updated: 2026-05-23 15:40| Vendor | Product | Version | CPE status | |
|---|---|---|---|---|
| Linux | Linux |
Affected:
264eae2f523d2aae38188facb4ece893023f25da , < 94a600226b6d0ef065ee84024b450b566c5a87d6
(git)
Affected: d2bf25674cea74b865d367d09be5dfe9aff5922a , < 2209fc6e3d7727d787dc6ef9baa1e9eae6b1295b (git) Affected: 9cce8ef7a6fa858bbcacd8679a5ca5a4fd3a6df3 , < 7d4e19f7ff644c5b79e8271df8ac2e549b436a5b (git) Affected: 076fb40cf27ab9232d8cce1f007e663e46705302 , < 5b8f473c4de95c056c1c767b1ad48c191544f6a5 (git) Affected: 5a5fb3b1754fa2b4db95f0151b4af0fb6f8918ec , < 6bb22ac1d11d7d20f91e7fd2e657a9e5f6db65e0 (git) Affected: 1a1975551943f681772720f639ff42fbaa746212 , < 2996c7e97ea7cf4c1838a1b1dbc0885934113783 (git) Affected: 1a1975551943f681772720f639ff42fbaa746212 , < 25675159040bffc7992d5163f3f33ba7d0142f21 (git) Affected: 1a1975551943f681772720f639ff42fbaa746212 , < 977fe773dcc7098d8eaf4ee6382cb51e13e784cb (git) Affected: 4ea46b479a00dd232f0dbc81fdc27f9330ecb3ad (git) Affected: 694ddc5bf35a5b6f9acb6e4724324c910a1237f1 (git) Affected: 6c5d7242bcf2154e9576e5eb2a98c6984ca5ea9a (git) Affected: 4.19.295 , < 4.19.307 (semver) Affected: 5.4.257 , < 5.4.269 (semver) Affected: 5.10.195 , < 5.10.210 (semver) Affected: 5.15.132 , < 5.15.149 (semver) Affected: 6.1.53 , < 6.1.79 (semver) Affected: 4.14.326 , < 4.15 (semver) Affected: 6.4.16 , < 6.5 (semver) Affected: 6.5.3 , < 6.6 (semver) |
guessed | |
| Linux | Linux |
Affected:
6.6
Unaffected: 0 , < 6.6 (semver) Unaffected: 4.19.307 , ≤ 4.19.* (semver) Unaffected: 5.4.269 , ≤ 5.4.* (semver) Unaffected: 5.10.210 , ≤ 5.10.* (semver) Unaffected: 5.15.149 , ≤ 5.15.* (semver) Unaffected: 6.1.79 , ≤ 6.1.* (semver) Unaffected: 6.6.18 , ≤ 6.6.* (semver) Unaffected: 6.7.6 , ≤ 6.7.* (semver) Unaffected: 6.8 , ≤ * (original_commit_for_fix) |
guessed |
{
"containers": {
"adp": [
{
"providerMetadata": {
"dateUpdated": "2024-08-02T00:21:05.463Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/94a600226b6d0ef065ee84024b450b566c5a87d6"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/2209fc6e3d7727d787dc6ef9baa1e9eae6b1295b"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/7d4e19f7ff644c5b79e8271df8ac2e549b436a5b"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/5b8f473c4de95c056c1c767b1ad48c191544f6a5"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/6bb22ac1d11d7d20f91e7fd2e657a9e5f6db65e0"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/2996c7e97ea7cf4c1838a1b1dbc0885934113783"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/25675159040bffc7992d5163f3f33ba7d0142f21"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/977fe773dcc7098d8eaf4ee6382cb51e13e784cb"
},
{
"tags": [
"x_transferred"
],
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"
},
{
"tags": [
"x_transferred"
],
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"
}
],
"title": "CVE Program Container"
},
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2024-26917",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2024-09-10T15:47:50.224233Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2024-09-11T17:32:51.098Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/scsi/fcoe/fcoe_ctlr.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "94a600226b6d0ef065ee84024b450b566c5a87d6",
"status": "affected",
"version": "264eae2f523d2aae38188facb4ece893023f25da",
"versionType": "git"
},
{
"lessThan": "2209fc6e3d7727d787dc6ef9baa1e9eae6b1295b",
"status": "affected",
"version": "d2bf25674cea74b865d367d09be5dfe9aff5922a",
"versionType": "git"
},
{
"lessThan": "7d4e19f7ff644c5b79e8271df8ac2e549b436a5b",
"status": "affected",
"version": "9cce8ef7a6fa858bbcacd8679a5ca5a4fd3a6df3",
"versionType": "git"
},
{
"lessThan": "5b8f473c4de95c056c1c767b1ad48c191544f6a5",
"status": "affected",
"version": "076fb40cf27ab9232d8cce1f007e663e46705302",
"versionType": "git"
},
{
"lessThan": "6bb22ac1d11d7d20f91e7fd2e657a9e5f6db65e0",
"status": "affected",
"version": "5a5fb3b1754fa2b4db95f0151b4af0fb6f8918ec",
"versionType": "git"
},
{
"lessThan": "2996c7e97ea7cf4c1838a1b1dbc0885934113783",
"status": "affected",
"version": "1a1975551943f681772720f639ff42fbaa746212",
"versionType": "git"
},
{
"lessThan": "25675159040bffc7992d5163f3f33ba7d0142f21",
"status": "affected",
"version": "1a1975551943f681772720f639ff42fbaa746212",
"versionType": "git"
},
{
"lessThan": "977fe773dcc7098d8eaf4ee6382cb51e13e784cb",
"status": "affected",
"version": "1a1975551943f681772720f639ff42fbaa746212",
"versionType": "git"
},
{
"status": "affected",
"version": "4ea46b479a00dd232f0dbc81fdc27f9330ecb3ad",
"versionType": "git"
},
{
"status": "affected",
"version": "694ddc5bf35a5b6f9acb6e4724324c910a1237f1",
"versionType": "git"
},
{
"status": "affected",
"version": "6c5d7242bcf2154e9576e5eb2a98c6984ca5ea9a",
"versionType": "git"
},
{
"lessThan": "4.19.307",
"status": "affected",
"version": "4.19.295",
"versionType": "semver"
},
{
"lessThan": "5.4.269",
"status": "affected",
"version": "5.4.257",
"versionType": "semver"
},
{
"lessThan": "5.10.210",
"status": "affected",
"version": "5.10.195",
"versionType": "semver"
},
{
"lessThan": "5.15.149",
"status": "affected",
"version": "5.15.132",
"versionType": "semver"
},
{
"lessThan": "6.1.79",
"status": "affected",
"version": "6.1.53",
"versionType": "semver"
},
{
"lessThan": "4.15",
"status": "affected",
"version": "4.14.326",
"versionType": "semver"
},
{
"lessThan": "6.5",
"status": "affected",
"version": "6.4.16",
"versionType": "semver"
},
{
"lessThan": "6.6",
"status": "affected",
"version": "6.5.3",
"versionType": "semver"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/scsi/fcoe/fcoe_ctlr.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "6.6"
},
{
"lessThan": "6.6",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "4.19.*",
"status": "unaffected",
"version": "4.19.307",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.269",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.210",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.149",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.79",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.18",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.7.*",
"status": "unaffected",
"version": "6.7.6",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.8",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "4.19.307",
"versionStartIncluding": "4.19.295",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.4.269",
"versionStartIncluding": "5.4.257",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.10.210",
"versionStartIncluding": "5.10.195",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.15.149",
"versionStartIncluding": "5.15.132",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.1.79",
"versionStartIncluding": "6.1.53",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6.18",
"versionStartIncluding": "6.6",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.7.6",
"versionStartIncluding": "6.6",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.8",
"versionStartIncluding": "6.6",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionStartIncluding": "4.14.326",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionStartIncluding": "6.4.16",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionStartIncluding": "6.5.3",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: Revert \"scsi: fcoe: Fix potential deadlock on \u0026fip-\u003ectlr_lock\"\n\nThis reverts commit 1a1975551943f681772720f639ff42fbaa746212.\n\nThis commit causes interrupts to be lost for FCoE devices, since it changed\nsping locks from \"bh\" to \"irqsave\".\n\nInstead, a work queue should be used, and will be addressed in a separate\ncommit."
}
],
"providerMetadata": {
"dateUpdated": "2026-05-23T15:40:03.694Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/94a600226b6d0ef065ee84024b450b566c5a87d6"
},
{
"url": "https://git.kernel.org/stable/c/2209fc6e3d7727d787dc6ef9baa1e9eae6b1295b"
},
{
"url": "https://git.kernel.org/stable/c/7d4e19f7ff644c5b79e8271df8ac2e549b436a5b"
},
{
"url": "https://git.kernel.org/stable/c/5b8f473c4de95c056c1c767b1ad48c191544f6a5"
},
{
"url": "https://git.kernel.org/stable/c/6bb22ac1d11d7d20f91e7fd2e657a9e5f6db65e0"
},
{
"url": "https://git.kernel.org/stable/c/2996c7e97ea7cf4c1838a1b1dbc0885934113783"
},
{
"url": "https://git.kernel.org/stable/c/25675159040bffc7992d5163f3f33ba7d0142f21"
},
{
"url": "https://git.kernel.org/stable/c/977fe773dcc7098d8eaf4ee6382cb51e13e784cb"
}
],
"title": "scsi: Revert \"scsi: fcoe: Fix potential deadlock on \u0026fip-\u003ectlr_lock\"",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2024-26917",
"datePublished": "2024-04-17T15:59:26.340Z",
"dateReserved": "2024-02-19T14:20:24.193Z",
"dateUpdated": "2026-05-23T15:40:03.694Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"epss": {
"cve": "CVE-2024-26917",
"date": "2026-09-29",
"epss": "0.00239",
"percentile": "0.13505"
},
"fkie_nvd": {
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: Revert \"scsi: fcoe: Fix potential deadlock on \u0026fip-\u003ectlr_lock\"\n\nThis reverts commit 1a1975551943f681772720f639ff42fbaa746212.\n\nThis commit causes interrupts to be lost for FCoE devices, since it changed\nsping locks from \"bh\" to \"irqsave\".\n\nInstead, a work queue should be used, and will be addressed in a separate\ncommit."
},
{
"lang": "es",
"value": "En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: scsi: Revertir \"scsi: fcoe: Reparar posible punto muerto en \u0026amp;fip-\u0026gt;ctlr_lock\" Esto revierte el commit 1a1975551943f681772720f639ff42fbaa746212. Este commit provoca que se pierdan las interrupciones para los dispositivos FCoE, ya que cambi\u00f3 los bloqueos de sping de \"bh\" a \"irqsave\". En su lugar, se debe utilizar una cola de trabajo, que se abordar\u00e1 en un commit separado."
}
],
"id": "CVE-2024-26917",
"lastModified": "2024-11-21T09:03:22.663",
"published": "2024-04-17T16:15:08.247",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/2209fc6e3d7727d787dc6ef9baa1e9eae6b1295b"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/25675159040bffc7992d5163f3f33ba7d0142f21"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/2996c7e97ea7cf4c1838a1b1dbc0885934113783"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/5b8f473c4de95c056c1c767b1ad48c191544f6a5"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/6bb22ac1d11d7d20f91e7fd2e657a9e5f6db65e0"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/7d4e19f7ff644c5b79e8271df8ac2e549b436a5b"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/94a600226b6d0ef065ee84024b450b566c5a87d6"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/977fe773dcc7098d8eaf4ee6382cb51e13e784cb"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"url": "https://git.kernel.org/stable/c/2209fc6e3d7727d787dc6ef9baa1e9eae6b1295b"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"url": "https://git.kernel.org/stable/c/25675159040bffc7992d5163f3f33ba7d0142f21"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"url": "https://git.kernel.org/stable/c/2996c7e97ea7cf4c1838a1b1dbc0885934113783"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"url": "https://git.kernel.org/stable/c/5b8f473c4de95c056c1c767b1ad48c191544f6a5"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"url": "https://git.kernel.org/stable/c/6bb22ac1d11d7d20f91e7fd2e657a9e5f6db65e0"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"url": "https://git.kernel.org/stable/c/7d4e19f7ff644c5b79e8271df8ac2e549b436a5b"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"url": "https://git.kernel.org/stable/c/94a600226b6d0ef065ee84024b450b566c5a87d6"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"url": "https://git.kernel.org/stable/c/977fe773dcc7098d8eaf4ee6382cb51e13e784cb"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Awaiting Analysis"
},
"nvd": {
"cve": {
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/scsi/fcoe/fcoe_ctlr.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "94a600226b6d0ef065ee84024b450b566c5a87d6",
"status": "affected",
"version": "264eae2f523d2aae38188facb4ece893023f25da",
"versionType": "git"
},
{
"lessThan": "2209fc6e3d7727d787dc6ef9baa1e9eae6b1295b",
"status": "affected",
"version": "d2bf25674cea74b865d367d09be5dfe9aff5922a",
"versionType": "git"
},
{
"lessThan": "7d4e19f7ff644c5b79e8271df8ac2e549b436a5b",
"status": "affected",
"version": "9cce8ef7a6fa858bbcacd8679a5ca5a4fd3a6df3",
"versionType": "git"
},
{
"lessThan": "5b8f473c4de95c056c1c767b1ad48c191544f6a5",
"status": "affected",
"version": "076fb40cf27ab9232d8cce1f007e663e46705302",
"versionType": "git"
},
{
"lessThan": "6bb22ac1d11d7d20f91e7fd2e657a9e5f6db65e0",
"status": "affected",
"version": "5a5fb3b1754fa2b4db95f0151b4af0fb6f8918ec",
"versionType": "git"
},
{
"lessThan": "2996c7e97ea7cf4c1838a1b1dbc0885934113783",
"status": "affected",
"version": "1a1975551943f681772720f639ff42fbaa746212",
"versionType": "git"
},
{
"lessThan": "25675159040bffc7992d5163f3f33ba7d0142f21",
"status": "affected",
"version": "1a1975551943f681772720f639ff42fbaa746212",
"versionType": "git"
},
{
"lessThan": "977fe773dcc7098d8eaf4ee6382cb51e13e784cb",
"status": "affected",
"version": "1a1975551943f681772720f639ff42fbaa746212",
"versionType": "git"
},
{
"status": "affected",
"version": "4ea46b479a00dd232f0dbc81fdc27f9330ecb3ad",
"versionType": "git"
},
{
"status": "affected",
"version": "694ddc5bf35a5b6f9acb6e4724324c910a1237f1",
"versionType": "git"
},
{
"status": "affected",
"version": "6c5d7242bcf2154e9576e5eb2a98c6984ca5ea9a",
"versionType": "git"
},
{
"lessThan": "4.19.307",
"status": "affected",
"version": "4.19.295",
"versionType": "semver"
},
{
"lessThan": "5.4.269",
"status": "affected",
"version": "5.4.257",
"versionType": "semver"
},
{
"lessThan": "5.10.210",
"status": "affected",
"version": "5.10.195",
"versionType": "semver"
},
{
"lessThan": "5.15.149",
"status": "affected",
"version": "5.15.132",
"versionType": "semver"
},
{
"lessThan": "6.1.79",
"status": "affected",
"version": "6.1.53",
"versionType": "semver"
},
{
"lessThan": "4.15",
"status": "affected",
"version": "4.14.326",
"versionType": "semver"
},
{
"lessThan": "6.5",
"status": "affected",
"version": "6.4.16",
"versionType": "semver"
},
{
"lessThan": "6.6",
"status": "affected",
"version": "6.5.3",
"versionType": "semver"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/scsi/fcoe/fcoe_ctlr.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "6.6"
},
{
"lessThan": "6.6",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "4.19.*",
"status": "unaffected",
"version": "4.19.307",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.269",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.210",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.149",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.79",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.18",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.7.*",
"status": "unaffected",
"version": "6.7.6",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.8",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"configurations": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "B7B3CDB0-0B42-463E-9E20-DD9CF990E40F",
"versionEndExcluding": "4.15",
"versionStartIncluding": "4.14.326",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "F6F52BF0-7A2F-423B-9280-8EFBC7B234B9",
"versionEndExcluding": "4.19.307",
"versionStartIncluding": "4.19.295",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "A670275E-A8A2-46B1-B18B-3218633C1FA8",
"versionEndExcluding": "5.4.269",
"versionStartIncluding": "5.4.257",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "202F35E5-FEC4-4A4C-953B-590C17E977E8",
"versionEndExcluding": "5.10.210",
"versionStartIncluding": "5.10.195",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "27538677-D1D6-43B6-8A7B-C69C5C098268",
"versionEndExcluding": "5.15.149",
"versionStartIncluding": "5.15.132",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "380879E6-C700-4766-8E8C-244A54409750",
"versionEndExcluding": "6.1.79",
"versionStartIncluding": "6.1.53",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "A5099559-2D15-42A5-A561-71B34FEFF36F",
"versionEndExcluding": "6.5",
"versionStartIncluding": "6.4.16",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "DAA49602-5E3F-4837-8384-4A57145682AC",
"versionEndExcluding": "6.6.18",
"versionStartIncluding": "6.5.3",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "C6D6A5C8-7308-42A9-8A72-ABF3DEA4BB82",
"versionEndExcluding": "6.7.6",
"versionStartIncluding": "6.7",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.8:rc1:*:*:*:*:*:*",
"matchCriteriaId": "B9F4EA73-0894-400F-A490-3A397AB7A517",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.8:rc2:*:*:*:*:*:*",
"matchCriteriaId": "056BD938-0A27-4569-B391-30578B309EE3",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.8:rc3:*:*:*:*:*:*",
"matchCriteriaId": "F02056A5-B362-4370-9FF8-6F0BD384D520",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.8:rc4:*:*:*:*:*:*",
"matchCriteriaId": "62075ACE-B2A0-4B16-829D-B3DA5AE5CC41",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
},
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:debian:debian_linux:10.0:*:*:*:*:*:*:*",
"matchCriteriaId": "07B237A9-69A3-4A9C-9DA0-4E06BD37AE73",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: Revert \"scsi: fcoe: Fix potential deadlock on \u0026fip-\u003ectlr_lock\"\n\nThis reverts commit 1a1975551943f681772720f639ff42fbaa746212.\n\nThis commit causes interrupts to be lost for FCoE devices, since it changed\nsping locks from \"bh\" to \"irqsave\".\n\nInstead, a work queue should be used, and will be addressed in a separate\ncommit."
},
{
"lang": "es",
"value": "En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: scsi: Revertir \"scsi: fcoe: Reparar posible punto muerto en \u0026amp;fip-\u0026gt;ctlr_lock\" Esto revierte el commit 1a1975551943f681772720f639ff42fbaa746212. Este commit provoca que se pierdan las interrupciones para los dispositivos FCoE, ya que cambi\u00f3 los bloqueos de sping de \"bh\" a \"irqsave\". En su lugar, se debe utilizar una cola de trabajo, que se abordar\u00e1 en un commit separado."
}
],
"id": "CVE-2024-26917",
"lastModified": "2026-06-17T07:18:41.047",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 5.5,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 3.6,
"source": "nvd@nist.gov",
"type": "Primary"
}
],
"ssvcV203": [
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"ssvcData": {
"id": "CVE-2024-26917",
"options": [
{
"exploitation": "none"
},
{
"automatable": "no"
},
{
"technicalImpact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2024-09-10T15:47:50.224233Z",
"version": "2.0.3"
}
}
]
},
"published": "2024-04-17T16:15:08.247",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/2209fc6e3d7727d787dc6ef9baa1e9eae6b1295b"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/25675159040bffc7992d5163f3f33ba7d0142f21"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/2996c7e97ea7cf4c1838a1b1dbc0885934113783"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/5b8f473c4de95c056c1c767b1ad48c191544f6a5"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/6bb22ac1d11d7d20f91e7fd2e657a9e5f6db65e0"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/7d4e19f7ff644c5b79e8271df8ac2e549b436a5b"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/94a600226b6d0ef065ee84024b450b566c5a87d6"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/977fe773dcc7098d8eaf4ee6382cb51e13e784cb"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/2209fc6e3d7727d787dc6ef9baa1e9eae6b1295b"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/25675159040bffc7992d5163f3f33ba7d0142f21"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/2996c7e97ea7cf4c1838a1b1dbc0885934113783"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/5b8f473c4de95c056c1c767b1ad48c191544f6a5"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/6bb22ac1d11d7d20f91e7fd2e657a9e5f6db65e0"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/7d4e19f7ff644c5b79e8271df8ac2e549b436a5b"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/94a600226b6d0ef065ee84024b450b566c5a87d6"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/977fe773dcc7098d8eaf4ee6382cb51e13e784cb"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Mailing List"
],
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Mailing List"
],
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Analyzed",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "NVD-CWE-noinfo"
}
],
"source": "nvd@nist.gov",
"type": "Primary"
}
]
}
},
"redhat_vex": {
"aggregate_severity": "Moderate",
"current_release_date": "2025-11-21T13:53:45+00:00",
"cve": "CVE-2024-26917",
"id": "CVE-2024-26917",
"initial_release_date": "2024-04-17T00:00:00+00:00",
"product_status:known_affected": "42",
"product_status:known_not_affected": "156",
"source": "Red Hat CSAF VEX",
"status": "final",
"title": "kernel: scsi: Revert \"scsi: fcoe: Fix potential deadlock on \u0026fip-\u003ectlr_lock\"",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2024/cve-2024-26917.json",
"version": "3"
},
"suse_vex": {
"aggregate_severity": "moderate",
"current_release_date": "2026-09-03T00:26:01Z",
"cve": "CVE-2024-26917",
"id": "CVE-2024-26917",
"initial_release_date": "2024-04-19T02:18:34Z",
"product_status:known_affected": "310",
"product_status:known_not_affected": "333",
"product_status:recommended": "520",
"source": "SUSE CSAF VEX",
"status": "interim",
"title": "SUSE CVE CVE-2024-26917",
"url": "https://ftp.suse.com/pub/projects/security/csaf-vex/cve-2024-26917.json",
"version": "61"
},
"vulnrichment": {
"containers": {
"adp": [
{
"providerMetadata": {
"dateUpdated": "2024-08-02T00:21:05.463Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/94a600226b6d0ef065ee84024b450b566c5a87d6"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/2209fc6e3d7727d787dc6ef9baa1e9eae6b1295b"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/7d4e19f7ff644c5b79e8271df8ac2e549b436a5b"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/5b8f473c4de95c056c1c767b1ad48c191544f6a5"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/6bb22ac1d11d7d20f91e7fd2e657a9e5f6db65e0"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/2996c7e97ea7cf4c1838a1b1dbc0885934113783"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/25675159040bffc7992d5163f3f33ba7d0142f21"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/977fe773dcc7098d8eaf4ee6382cb51e13e784cb"
},
{
"tags": [
"x_transferred"
],
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"
},
{
"tags": [
"x_transferred"
],
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"
}
],
"title": "CVE Program Container"
},
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2024-26917",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2024-09-10T15:47:50.224233Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2024-09-11T12:42:13.069Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/scsi/fcoe/fcoe_ctlr.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "94a600226b6d0ef065ee84024b450b566c5a87d6",
"status": "affected",
"version": "264eae2f523d2aae38188facb4ece893023f25da",
"versionType": "git"
},
{
"lessThan": "2209fc6e3d7727d787dc6ef9baa1e9eae6b1295b",
"status": "affected",
"version": "d2bf25674cea74b865d367d09be5dfe9aff5922a",
"versionType": "git"
},
{
"lessThan": "7d4e19f7ff644c5b79e8271df8ac2e549b436a5b",
"status": "affected",
"version": "9cce8ef7a6fa858bbcacd8679a5ca5a4fd3a6df3",
"versionType": "git"
},
{
"lessThan": "5b8f473c4de95c056c1c767b1ad48c191544f6a5",
"status": "affected",
"version": "076fb40cf27ab9232d8cce1f007e663e46705302",
"versionType": "git"
},
{
"lessThan": "6bb22ac1d11d7d20f91e7fd2e657a9e5f6db65e0",
"status": "affected",
"version": "5a5fb3b1754fa2b4db95f0151b4af0fb6f8918ec",
"versionType": "git"
},
{
"lessThan": "2996c7e97ea7cf4c1838a1b1dbc0885934113783",
"status": "affected",
"version": "1a1975551943f681772720f639ff42fbaa746212",
"versionType": "git"
},
{
"lessThan": "25675159040bffc7992d5163f3f33ba7d0142f21",
"status": "affected",
"version": "1a1975551943f681772720f639ff42fbaa746212",
"versionType": "git"
},
{
"lessThan": "977fe773dcc7098d8eaf4ee6382cb51e13e784cb",
"status": "affected",
"version": "1a1975551943f681772720f639ff42fbaa746212",
"versionType": "git"
},
{
"status": "affected",
"version": "4ea46b479a00dd232f0dbc81fdc27f9330ecb3ad",
"versionType": "git"
},
{
"status": "affected",
"version": "694ddc5bf35a5b6f9acb6e4724324c910a1237f1",
"versionType": "git"
},
{
"status": "affected",
"version": "6c5d7242bcf2154e9576e5eb2a98c6984ca5ea9a",
"versionType": "git"
},
{
"lessThan": "4.19.307",
"status": "affected",
"version": "4.19.295",
"versionType": "semver"
},
{
"lessThan": "5.4.269",
"status": "affected",
"version": "5.4.257",
"versionType": "semver"
},
{
"lessThan": "5.10.210",
"status": "affected",
"version": "5.10.195",
"versionType": "semver"
},
{
"lessThan": "5.15.149",
"status": "affected",
"version": "5.15.132",
"versionType": "semver"
},
{
"lessThan": "6.1.79",
"status": "affected",
"version": "6.1.53",
"versionType": "semver"
},
{
"lessThan": "4.15",
"status": "affected",
"version": "4.14.326",
"versionType": "semver"
},
{
"lessThan": "6.5",
"status": "affected",
"version": "6.4.16",
"versionType": "semver"
},
{
"lessThan": "6.6",
"status": "affected",
"version": "6.5.3",
"versionType": "semver"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/scsi/fcoe/fcoe_ctlr.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "6.6"
},
{
"lessThan": "6.6",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "4.19.*",
"status": "unaffected",
"version": "4.19.307",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.269",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.210",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.149",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.79",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.18",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.7.*",
"status": "unaffected",
"version": "6.7.6",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.8",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "4.19.307",
"versionStartIncluding": "4.19.295",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.4.269",
"versionStartIncluding": "5.4.257",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.10.210",
"versionStartIncluding": "5.10.195",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.15.149",
"versionStartIncluding": "5.15.132",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.1.79",
"versionStartIncluding": "6.1.53",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6.18",
"versionStartIncluding": "6.6",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.7.6",
"versionStartIncluding": "6.6",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.8",
"versionStartIncluding": "6.6",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionStartIncluding": "4.14.326",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionStartIncluding": "6.4.16",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionStartIncluding": "6.5.3",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: Revert \"scsi: fcoe: Fix potential deadlock on \u0026fip-\u003ectlr_lock\"\n\nThis reverts commit 1a1975551943f681772720f639ff42fbaa746212.\n\nThis commit causes interrupts to be lost for FCoE devices, since it changed\nsping locks from \"bh\" to \"irqsave\".\n\nInstead, a work queue should be used, and will be addressed in a separate\ncommit."
}
],
"providerMetadata": {
"dateUpdated": "2026-05-23T15:40:03.694Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/94a600226b6d0ef065ee84024b450b566c5a87d6"
},
{
"url": "https://git.kernel.org/stable/c/2209fc6e3d7727d787dc6ef9baa1e9eae6b1295b"
},
{
"url": "https://git.kernel.org/stable/c/7d4e19f7ff644c5b79e8271df8ac2e549b436a5b"
},
{
"url": "https://git.kernel.org/stable/c/5b8f473c4de95c056c1c767b1ad48c191544f6a5"
},
{
"url": "https://git.kernel.org/stable/c/6bb22ac1d11d7d20f91e7fd2e657a9e5f6db65e0"
},
{
"url": "https://git.kernel.org/stable/c/2996c7e97ea7cf4c1838a1b1dbc0885934113783"
},
{
"url": "https://git.kernel.org/stable/c/25675159040bffc7992d5163f3f33ba7d0142f21"
},
{
"url": "https://git.kernel.org/stable/c/977fe773dcc7098d8eaf4ee6382cb51e13e784cb"
}
],
"title": "scsi: Revert \"scsi: fcoe: Fix potential deadlock on \u0026fip-\u003ectlr_lock\"",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2024-26917",
"datePublished": "2024-04-17T15:59:26.340Z",
"dateReserved": "2024-02-19T14:20:24.193Z",
"dateUpdated": "2026-05-23T15:40:03.694Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
}
}
CERTFR-2024-AVI-0527
Vulnerability from certfr_avis - Published: - Updated:
De multiples vulnérabilités ont été découvertes dans le noyau Linux de Debian LTS. Elles permettent à un attaquant de provoquer une élévation de privilèges, une atteinte à la confidentialité des données et un déni de service.
Solutions
Se référer au bulletin de sécurité de l'éditeur pour l'obtention des correctifs (cf. section Documentation).
| Vendor | Product | Description | ||
|---|---|---|---|---|
| Debian | N/A | Debian LTS buster versions antérieures à 5.10.209-2~deb10u1 | ||
| Debian | N/A | Debian LTS buster versions antérieures à 5.10.218-1~deb10u1 | ||
| Debian | N/A | Debian LTS buster versions antérieures à 5.10.216-1~deb10u1 | ||
| Debian | N/A | Debian LTS buster versions antérieures à 4.19.316-1 |
| Title | Publication Time | Tags | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||
{
"$ref": "https://www.cert.ssi.gouv.fr/openapi.json",
"affected_systems": [
{
"description": "Debian LTS buster versions ant\u00e9rieures \u00e0 5.10.209-2~deb10u1",
"product": {
"name": "N/A",
"vendor": {
"name": "Debian",
"scada": false
}
}
},
{
"description": "Debian LTS buster versions ant\u00e9rieures \u00e0 5.10.218-1~deb10u1",
"product": {
"name": "N/A",
"vendor": {
"name": "Debian",
"scada": false
}
}
},
{
"description": "Debian LTS buster versions ant\u00e9rieures \u00e0 5.10.216-1~deb10u1",
"product": {
"name": "N/A",
"vendor": {
"name": "Debian",
"scada": false
}
}
},
{
"description": "Debian LTS buster versions ant\u00e9rieures \u00e0 4.19.316-1",
"product": {
"name": "N/A",
"vendor": {
"name": "Debian",
"scada": false
}
}
}
],
"affected_systems_content": "",
"content": "## Solutions\n\nSe r\u00e9f\u00e9rer au bulletin de s\u00e9curit\u00e9 de l\u0027\u00e9diteur pour l\u0027obtention des correctifs (cf. section Documentation).",
"cves": [
{
"name": "CVE-2022-38096",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-38096"
},
{
"name": "CVE-2023-0386",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-0386"
},
{
"name": "CVE-2023-39198",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-39198"
},
{
"name": "CVE-2023-6606",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-6606"
},
{
"name": "CVE-2023-51779",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-51779"
},
{
"name": "CVE-2023-46838",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-46838"
},
{
"name": "CVE-2023-6040",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-6040"
},
{
"name": "CVE-2023-6536",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-6536"
},
{
"name": "CVE-2023-6356",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-6356"
},
{
"name": "CVE-2023-6535",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-6535"
},
{
"name": "CVE-2024-0646",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-0646"
},
{
"name": "CVE-2024-0607",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-0607"
},
{
"name": "CVE-2024-0565",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-0565"
},
{
"name": "CVE-2023-6915",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-6915"
},
{
"name": "CVE-2024-0340",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-0340"
},
{
"name": "CVE-2023-47233",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-47233"
},
{
"name": "CVE-2024-24860",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-24860"
},
{
"name": "CVE-2024-1086",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-1086"
},
{
"name": "CVE-2023-28746",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-28746"
},
{
"name": "CVE-2023-52454",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52454"
},
{
"name": "CVE-2024-26600",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26600"
},
{
"name": "CVE-2023-52467",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52467"
},
{
"name": "CVE-2023-52451",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52451"
},
{
"name": "CVE-2023-52436",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52436"
},
{
"name": "CVE-2023-52445",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52445"
},
{
"name": "CVE-2023-52597",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52597"
},
{
"name": "CVE-2024-26598",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26598"
},
{
"name": "CVE-2023-52462",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52462"
},
{
"name": "CVE-2023-52443",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52443"
},
{
"name": "CVE-2023-52469",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52469"
},
{
"name": "CVE-2023-52598",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52598"
},
{
"name": "CVE-2023-52470",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52470"
},
{
"name": "CVE-2023-52601",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52601"
},
{
"name": "CVE-2023-52439",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52439"
},
{
"name": "CVE-2023-52438",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52438"
},
{
"name": "CVE-2023-52464",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52464"
},
{
"name": "CVE-2023-52600",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52600"
},
{
"name": "CVE-2023-52458",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52458"
},
{
"name": "CVE-2023-52602",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52602"
},
{
"name": "CVE-2024-26625",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26625"
},
{
"name": "CVE-2024-26627",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26627"
},
{
"name": "CVE-2023-52463",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52463"
},
{
"name": "CVE-2023-52447",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52447"
},
{
"name": "CVE-2023-52449",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52449"
},
{
"name": "CVE-2024-26581",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26581"
},
{
"name": "CVE-2023-52457",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52457"
},
{
"name": "CVE-2023-52606",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52606"
},
{
"name": "CVE-2023-52604",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52604"
},
{
"name": "CVE-2023-52587",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52587"
},
{
"name": "CVE-2023-52448",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52448"
},
{
"name": "CVE-2023-52599",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52599"
},
{
"name": "CVE-2023-52444",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52444"
},
{
"name": "CVE-2023-52583",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52583"
},
{
"name": "CVE-2023-52603",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52603"
},
{
"name": "CVE-2023-52456",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52456"
},
{
"name": "CVE-2023-52607",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52607"
},
{
"name": "CVE-2023-52594",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52594"
},
{
"name": "CVE-2024-26601",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26601"
},
{
"name": "CVE-2023-52595",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52595"
},
{
"name": "CVE-2024-23849",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-23849"
},
{
"name": "CVE-2024-26597",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26597"
},
{
"name": "CVE-2024-26602",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26602"
},
{
"name": "CVE-2023-52340",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52340"
},
{
"name": "CVE-2024-23850",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-23850"
},
{
"name": "CVE-2024-26622",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26622"
},
{
"name": "CVE-2024-23851",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-23851"
},
{
"name": "CVE-2024-1151",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-1151"
},
{
"name": "CVE-2023-6270",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-6270"
},
{
"name": "CVE-2024-26593",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26593"
},
{
"name": "CVE-2023-52429",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52429"
},
{
"name": "CVE-2023-52482",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52482"
},
{
"name": "CVE-2024-26586",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26586"
},
{
"name": "CVE-2022-48627",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48627"
},
{
"name": "CVE-2024-26633",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26633"
},
{
"name": "CVE-2023-52434",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52434"
},
{
"name": "CVE-2023-52609",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52609"
},
{
"name": "CVE-2023-52435",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52435"
},
{
"name": "CVE-2023-52612",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52612"
},
{
"name": "CVE-2024-26642",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26642"
},
{
"name": "CVE-2023-52617",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52617"
},
{
"name": "CVE-2024-26645",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26645"
},
{
"name": "CVE-2024-0841",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-0841"
},
{
"name": "CVE-2024-26695",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26695"
},
{
"name": "CVE-2024-26654",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26654"
},
{
"name": "CVE-2023-52615",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52615"
},
{
"name": "CVE-2024-26659",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26659"
},
{
"name": "CVE-2023-52486",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52486"
},
{
"name": "CVE-2023-52628",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52628"
},
{
"name": "CVE-2023-52493",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52493"
},
{
"name": "CVE-2024-26614",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26614"
},
{
"name": "CVE-2023-52637",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52637"
},
{
"name": "CVE-2023-52497",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52497"
},
{
"name": "CVE-2023-52492",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52492"
},
{
"name": "CVE-2024-25739",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-25739"
},
{
"name": "CVE-2024-22099",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-22099"
},
{
"name": "CVE-2024-26664",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26664"
},
{
"name": "CVE-2023-52623",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52623"
},
{
"name": "CVE-2023-52619",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52619"
},
{
"name": "CVE-2024-26651",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26651"
},
{
"name": "CVE-2023-7042",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-7042"
},
{
"name": "CVE-2024-26707",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26707"
},
{
"name": "CVE-2024-26754",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26754"
},
{
"name": "CVE-2024-26795",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26795"
},
{
"name": "CVE-2024-26697",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26697"
},
{
"name": "CVE-2024-26704",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26704"
},
{
"name": "CVE-2024-26720",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26720"
},
{
"name": "CVE-2023-52622",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52622"
},
{
"name": "CVE-2024-26689",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26689"
},
{
"name": "CVE-2024-26727",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26727"
},
{
"name": "CVE-2024-26671",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26671"
},
{
"name": "CVE-2024-26748",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26748"
},
{
"name": "CVE-2024-26776",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26776"
},
{
"name": "CVE-2024-26606",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26606"
},
{
"name": "CVE-2024-26702",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26702"
},
{
"name": "CVE-2024-26766",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26766"
},
{
"name": "CVE-2024-26814",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26814"
},
{
"name": "CVE-2024-26685",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26685"
},
{
"name": "CVE-2024-26771",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26771"
},
{
"name": "CVE-2024-26810",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26810"
},
{
"name": "CVE-2024-26801",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26801"
},
{
"name": "CVE-2024-26787",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26787"
},
{
"name": "CVE-2024-26781",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26781"
},
{
"name": "CVE-2024-26663",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26663"
},
{
"name": "CVE-2024-26675",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26675"
},
{
"name": "CVE-2024-26752",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26752"
},
{
"name": "CVE-2024-26743",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26743"
},
{
"name": "CVE-2024-26805",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26805"
},
{
"name": "CVE-2024-26773",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26773"
},
{
"name": "CVE-2023-52618",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52618"
},
{
"name": "CVE-2024-26712",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26712"
},
{
"name": "CVE-2024-26793",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26793"
},
{
"name": "CVE-2024-24858",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-24858"
},
{
"name": "CVE-2023-52616",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52616"
},
{
"name": "CVE-2024-26813",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26813"
},
{
"name": "CVE-2024-26764",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26764"
},
{
"name": "CVE-2024-27437",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27437"
},
{
"name": "CVE-2024-26735",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26735"
},
{
"name": "CVE-2024-26684",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26684"
},
{
"name": "CVE-2024-24857",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-24857"
},
{
"name": "CVE-2024-26679",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26679"
},
{
"name": "CVE-2024-26816",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26816"
},
{
"name": "CVE-2024-26749",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26749"
},
{
"name": "CVE-2024-26688",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26688"
},
{
"name": "CVE-2024-26744",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26744"
},
{
"name": "CVE-2024-26640",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26640"
},
{
"name": "CVE-2024-26763",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26763"
},
{
"name": "CVE-2024-26722",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26722"
},
{
"name": "CVE-2024-26777",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26777"
},
{
"name": "CVE-2024-26733",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26733"
},
{
"name": "CVE-2024-26779",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26779"
},
{
"name": "CVE-2023-52620",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52620"
},
{
"name": "CVE-2024-26772",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26772"
},
{
"name": "CVE-2024-26791",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26791"
},
{
"name": "CVE-2023-52635",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52635"
},
{
"name": "CVE-2024-26788",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26788"
},
{
"name": "CVE-2024-26812",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26812"
},
{
"name": "CVE-2024-26643",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26643"
},
{
"name": "CVE-2024-26804",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26804"
},
{
"name": "CVE-2024-26665",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26665"
},
{
"name": "CVE-2024-26747",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26747"
},
{
"name": "CVE-2024-26696",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26696"
},
{
"name": "CVE-2024-26698",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26698"
},
{
"name": "CVE-2024-26687",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26687"
},
{
"name": "CVE-2024-26778",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26778"
},
{
"name": "CVE-2024-26790",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26790"
},
{
"name": "CVE-2024-26809",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26809"
},
{
"name": "CVE-2024-26673",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26673"
},
{
"name": "CVE-2024-26753",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26753"
},
{
"name": "CVE-2024-26751",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26751"
},
{
"name": "CVE-2024-26736",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26736"
},
{
"name": "CVE-2024-26641",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26641"
},
{
"name": "CVE-2024-26782",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26782"
},
{
"name": "CVE-2024-26848",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26848"
},
{
"name": "CVE-2023-52488",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52488"
},
{
"name": "CVE-2023-52627",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52627"
},
{
"name": "CVE-2023-52489",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52489"
},
{
"name": "CVE-2024-26897",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26897"
},
{
"name": "CVE-2024-26870",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26870"
},
{
"name": "CVE-2024-27044",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27044"
},
{
"name": "CVE-2024-26839",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26839"
},
{
"name": "CVE-2024-26863",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26863"
},
{
"name": "CVE-2024-26966",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26966"
},
{
"name": "CVE-2024-27025",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27025"
},
{
"name": "CVE-2024-27047",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27047"
},
{
"name": "CVE-2024-26845",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26845"
},
{
"name": "CVE-2024-27028",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27028"
},
{
"name": "CVE-2024-26970",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26970"
},
{
"name": "CVE-2024-26861",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26861"
},
{
"name": "CVE-2024-26895",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26895"
},
{
"name": "CVE-2024-26961",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26961"
},
{
"name": "CVE-2024-26978",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26978"
},
{
"name": "CVE-2024-26917",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26917"
},
{
"name": "CVE-2024-27013",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27013"
},
{
"name": "CVE-2024-26840",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26840"
},
{
"name": "CVE-2023-52644",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52644"
},
{
"name": "CVE-2024-26910",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26910"
},
{
"name": "CVE-2024-26615",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26615"
},
{
"name": "CVE-2024-26931",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26931"
},
{
"name": "CVE-2024-26846",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26846"
},
{
"name": "CVE-2024-26958",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26958"
},
{
"name": "CVE-2024-27008",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27008"
},
{
"name": "CVE-2024-26610",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26610"
},
{
"name": "CVE-2024-26872",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26872"
},
{
"name": "CVE-2024-26875",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26875"
},
{
"name": "CVE-2024-26906",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26906"
},
{
"name": "CVE-2024-26843",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26843"
},
{
"name": "CVE-2024-26907",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26907"
},
{
"name": "CVE-2024-26925",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26925"
},
{
"name": "CVE-2024-26934",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26934"
},
{
"name": "CVE-2024-26957",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26957"
},
{
"name": "CVE-2024-26981",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26981"
},
{
"name": "CVE-2024-26889",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26889"
},
{
"name": "CVE-2024-27000",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27000"
},
{
"name": "CVE-2024-26833",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26833"
},
{
"name": "CVE-2024-26880",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26880"
},
{
"name": "CVE-2024-27388",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27388"
},
{
"name": "CVE-2024-26883",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26883"
},
{
"name": "CVE-2024-26644",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26644"
},
{
"name": "CVE-2024-26935",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26935"
},
{
"name": "CVE-2024-26974",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26974"
},
{
"name": "CVE-2024-26965",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26965"
},
{
"name": "CVE-2024-26882",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26882"
},
{
"name": "CVE-2024-26984",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26984"
},
{
"name": "CVE-2024-27020",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27020"
},
{
"name": "CVE-2024-26973",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26973"
},
{
"name": "CVE-2024-27059",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27059"
},
{
"name": "CVE-2024-26960",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26960"
},
{
"name": "CVE-2024-27043",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27043"
},
{
"name": "CVE-2024-26820",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26820"
},
{
"name": "CVE-2024-27038",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27038"
},
{
"name": "CVE-2024-27051",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27051"
},
{
"name": "CVE-2024-27073",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27073"
},
{
"name": "CVE-2024-26635",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26635"
},
{
"name": "CVE-2024-26950",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26950"
},
{
"name": "CVE-2024-26999",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26999"
},
{
"name": "CVE-2023-52498",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52498"
},
{
"name": "CVE-2024-26874",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26874"
},
{
"name": "CVE-2023-52491",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52491"
},
{
"name": "CVE-2024-26956",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26956"
},
{
"name": "CVE-2024-26924",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26924"
},
{
"name": "CVE-2024-24861",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-24861"
},
{
"name": "CVE-2024-27004",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27004"
},
{
"name": "CVE-2024-26955",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26955"
},
{
"name": "CVE-2024-27052",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27052"
},
{
"name": "CVE-2024-27074",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27074"
},
{
"name": "CVE-2023-52650",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52650"
},
{
"name": "CVE-2024-26808",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26808"
},
{
"name": "CVE-2024-26817",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26817"
},
{
"name": "CVE-2024-26857",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26857"
},
{
"name": "CVE-2024-27001",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27001"
},
{
"name": "CVE-2024-26885",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26885"
},
{
"name": "CVE-2024-26878",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26878"
},
{
"name": "CVE-2024-26894",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26894"
},
{
"name": "CVE-2024-26835",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26835"
},
{
"name": "CVE-2024-26976",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26976"
},
{
"name": "CVE-2024-26852",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26852"
},
{
"name": "CVE-2024-26859",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26859"
},
{
"name": "CVE-2024-26994",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26994"
},
{
"name": "CVE-2024-26636",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26636"
},
{
"name": "CVE-2024-26898",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26898"
},
{
"name": "CVE-2023-52642",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52642"
},
{
"name": "CVE-2024-26969",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26969"
},
{
"name": "CVE-2023-52614",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52614"
},
{
"name": "CVE-2024-26877",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26877"
},
{
"name": "CVE-2024-26937",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26937"
},
{
"name": "CVE-2024-27030",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27030"
},
{
"name": "CVE-2024-27065",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27065"
},
{
"name": "CVE-2024-26997",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26997"
},
{
"name": "CVE-2024-26922",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26922"
},
{
"name": "CVE-2024-26884",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26884"
},
{
"name": "CVE-2024-27076",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27076"
},
{
"name": "CVE-2024-26862",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26862"
},
{
"name": "CVE-2024-27077",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27077"
},
{
"name": "CVE-2024-27078",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27078"
},
{
"name": "CVE-2024-26825",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26825"
},
{
"name": "CVE-2024-26901",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26901"
},
{
"name": "CVE-2024-27046",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27046"
},
{
"name": "CVE-2024-26903",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26903"
},
{
"name": "CVE-2024-26993",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26993"
},
{
"name": "CVE-2024-27024",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27024"
},
{
"name": "CVE-2024-27053",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27053"
},
{
"name": "CVE-2024-27075",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27075"
},
{
"name": "CVE-2024-26891",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26891"
},
{
"name": "CVE-2024-26951",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26951"
},
{
"name": "CVE-2024-26855",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26855"
},
{
"name": "CVE-2024-27045",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27045"
},
{
"name": "CVE-2024-26923",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26923"
},
{
"name": "CVE-2024-26851",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26851"
},
{
"name": "CVE-2024-26926",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26926"
},
{
"name": "CVE-2024-26988",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26988"
},
{
"name": "CVE-2023-52585",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52585"
},
{
"name": "CVE-2022-48655",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48655"
},
{
"name": "CVE-2023-52882",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52882"
},
{
"name": "CVE-2024-26900",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26900"
},
{
"name": "CVE-2024-27398",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27398"
},
{
"name": "CVE-2024-27399",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27399"
},
{
"name": "CVE-2024-27401",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27401"
},
{
"name": "CVE-2024-35848",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35848"
},
{
"name": "CVE-2024-35947",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35947"
},
{
"name": "CVE-2024-36017",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36017"
},
{
"name": "CVE-2024-36031",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36031"
},
{
"name": "CVE-2024-36883",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36883"
},
{
"name": "CVE-2024-36886",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36886"
},
{
"name": "CVE-2024-36889",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36889"
},
{
"name": "CVE-2024-36902",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36902"
},
{
"name": "CVE-2024-36904",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36904"
},
{
"name": "CVE-2024-36905",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36905"
},
{
"name": "CVE-2024-36916",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36916"
},
{
"name": "CVE-2024-36919",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36919"
},
{
"name": "CVE-2024-36929",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36929"
},
{
"name": "CVE-2024-36933",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36933"
},
{
"name": "CVE-2024-36934",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36934"
},
{
"name": "CVE-2024-36939",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36939"
},
{
"name": "CVE-2024-36940",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36940"
},
{
"name": "CVE-2024-36941",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36941"
},
{
"name": "CVE-2024-36946",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36946"
},
{
"name": "CVE-2024-36950",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36950"
},
{
"name": "CVE-2024-36953",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36953"
},
{
"name": "CVE-2024-36954",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36954"
},
{
"name": "CVE-2024-36957",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36957"
},
{
"name": "CVE-2024-36959",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36959"
},
{
"name": "CVE-2023-52656",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52656"
},
{
"name": "CVE-2023-52669",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52669"
},
{
"name": "CVE-2023-52679",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52679"
},
{
"name": "CVE-2023-52683",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52683"
},
{
"name": "CVE-2023-52686",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52686"
},
{
"name": "CVE-2023-52690",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52690"
},
{
"name": "CVE-2023-52691",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52691"
},
{
"name": "CVE-2023-52693",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52693"
},
{
"name": "CVE-2023-52694",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52694"
},
{
"name": "CVE-2023-52696",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52696"
},
{
"name": "CVE-2023-52698",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52698"
},
{
"name": "CVE-2023-52699",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52699"
},
{
"name": "CVE-2023-52880",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52880"
},
{
"name": "CVE-2024-27395",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27395"
},
{
"name": "CVE-2024-27396",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27396"
},
{
"name": "CVE-2024-27405",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27405"
},
{
"name": "CVE-2024-27410",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27410"
},
{
"name": "CVE-2024-27412",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27412"
},
{
"name": "CVE-2024-27413",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27413"
},
{
"name": "CVE-2024-27416",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27416"
},
{
"name": "CVE-2024-27417",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27417"
},
{
"name": "CVE-2024-27419",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27419"
},
{
"name": "CVE-2024-27431",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27431"
},
{
"name": "CVE-2024-27436",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27436"
},
{
"name": "CVE-2024-35789",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35789"
},
{
"name": "CVE-2024-35791",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35791"
},
{
"name": "CVE-2024-35796",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35796"
},
{
"name": "CVE-2024-35806",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35806"
},
{
"name": "CVE-2024-35809",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35809"
},
{
"name": "CVE-2024-35811",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35811"
},
{
"name": "CVE-2024-35813",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35813"
},
{
"name": "CVE-2024-35815",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35815"
},
{
"name": "CVE-2024-35821",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35821"
},
{
"name": "CVE-2024-35822",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35822"
},
{
"name": "CVE-2024-35823",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35823"
},
{
"name": "CVE-2024-35825",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35825"
},
{
"name": "CVE-2024-35828",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35828"
},
{
"name": "CVE-2024-35829",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35829"
},
{
"name": "CVE-2024-35830",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35830"
},
{
"name": "CVE-2024-35833",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35833"
},
{
"name": "CVE-2024-35845",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35845"
},
{
"name": "CVE-2024-35847",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35847"
},
{
"name": "CVE-2024-35849",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35849"
},
{
"name": "CVE-2024-35852",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35852"
},
{
"name": "CVE-2024-35854",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35854"
},
{
"name": "CVE-2024-35877",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35877"
},
{
"name": "CVE-2024-35879",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35879"
},
{
"name": "CVE-2024-35895",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35895"
},
{
"name": "CVE-2024-35905",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35905"
},
{
"name": "CVE-2024-35915",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35915"
},
{
"name": "CVE-2024-35922",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35922"
},
{
"name": "CVE-2024-35930",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35930"
},
{
"name": "CVE-2024-35933",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35933"
},
{
"name": "CVE-2024-35935",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35935"
},
{
"name": "CVE-2024-35936",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35936"
},
{
"name": "CVE-2024-35940",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35940"
},
{
"name": "CVE-2024-35944",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35944"
},
{
"name": "CVE-2024-35950",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35950"
},
{
"name": "CVE-2024-35955",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35955"
},
{
"name": "CVE-2024-35967",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35967"
},
{
"name": "CVE-2024-35969",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35969"
},
{
"name": "CVE-2024-35973",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35973"
},
{
"name": "CVE-2024-35976",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35976"
},
{
"name": "CVE-2024-35978",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35978"
},
{
"name": "CVE-2024-35982",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35982"
},
{
"name": "CVE-2024-35984",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35984"
},
{
"name": "CVE-2024-35990",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35990"
},
{
"name": "CVE-2024-36006",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36006"
},
{
"name": "CVE-2024-36007",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36007"
},
{
"name": "CVE-2024-36014",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36014"
},
{
"name": "CVE-2024-36015",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36015"
},
{
"name": "CVE-2024-36016",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36016"
},
{
"name": "CVE-2023-52670",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52670"
},
{
"name": "CVE-2023-52675",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52675"
},
{
"name": "CVE-2024-35819",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35819"
},
{
"name": "CVE-2024-35835",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35835"
},
{
"name": "CVE-2024-35837",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35837"
},
{
"name": "CVE-2024-35958",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35958"
},
{
"name": "CVE-2024-35960",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35960"
},
{
"name": "CVE-2024-35997",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35997"
},
{
"name": "CVE-2024-36020",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36020"
},
{
"name": "CVE-2021-33630",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-33630"
},
{
"name": "CVE-2023-52672",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52672"
},
{
"name": "CVE-2024-27414",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27414"
},
{
"name": "CVE-2024-31076",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-31076"
},
{
"name": "CVE-2024-33621",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-33621"
},
{
"name": "CVE-2024-35785",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35785"
},
{
"name": "CVE-2024-35805",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35805"
},
{
"name": "CVE-2024-35807",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35807"
},
{
"name": "CVE-2024-35853",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35853"
},
{
"name": "CVE-2024-35855",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35855"
},
{
"name": "CVE-2024-35871",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35871"
},
{
"name": "CVE-2024-35884",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35884"
},
{
"name": "CVE-2024-35886",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35886"
},
{
"name": "CVE-2024-35888",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35888"
},
{
"name": "CVE-2024-35893",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35893"
},
{
"name": "CVE-2024-35896",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35896"
},
{
"name": "CVE-2024-35897",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35897"
},
{
"name": "CVE-2024-35898",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35898"
},
{
"name": "CVE-2024-35899",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35899"
},
{
"name": "CVE-2024-35900",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35900"
},
{
"name": "CVE-2024-35902",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35902"
},
{
"name": "CVE-2024-35910",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35910"
},
{
"name": "CVE-2024-35925",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35925"
},
{
"name": "CVE-2024-35934",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35934"
},
{
"name": "CVE-2024-35962",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35962"
},
{
"name": "CVE-2024-35983",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35983"
},
{
"name": "CVE-2024-35988",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35988"
},
{
"name": "CVE-2024-35996",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35996"
},
{
"name": "CVE-2024-36004",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36004"
},
{
"name": "CVE-2024-36005",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36005"
},
{
"name": "CVE-2024-36008",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36008"
},
{
"name": "CVE-2024-36286",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36286"
},
{
"name": "CVE-2024-36288",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36288"
},
{
"name": "CVE-2024-36960",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36960"
},
{
"name": "CVE-2024-36964",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36964"
},
{
"name": "CVE-2024-36971",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36971"
},
{
"name": "CVE-2024-37353",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-37353"
},
{
"name": "CVE-2024-37356",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-37356"
},
{
"name": "CVE-2024-38381",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38381"
},
{
"name": "CVE-2024-38549",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38549"
},
{
"name": "CVE-2024-38552",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38552"
},
{
"name": "CVE-2024-38558",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38558"
},
{
"name": "CVE-2024-38559",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38559"
},
{
"name": "CVE-2024-38560",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38560"
},
{
"name": "CVE-2024-38565",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38565"
},
{
"name": "CVE-2024-38567",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38567"
},
{
"name": "CVE-2024-38578",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38578"
},
{
"name": "CVE-2024-38579",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38579"
},
{
"name": "CVE-2024-38582",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38582"
},
{
"name": "CVE-2024-38583",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38583"
},
{
"name": "CVE-2024-38587",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38587"
},
{
"name": "CVE-2024-38589",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38589"
},
{
"name": "CVE-2024-38596",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38596"
},
{
"name": "CVE-2024-38598",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38598"
},
{
"name": "CVE-2024-38599",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38599"
},
{
"name": "CVE-2024-38601",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38601"
},
{
"name": "CVE-2024-38612",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38612"
},
{
"name": "CVE-2024-38618",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38618"
},
{
"name": "CVE-2024-38621",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38621"
},
{
"name": "CVE-2024-38627",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38627"
},
{
"name": "CVE-2024-38633",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38633"
},
{
"name": "CVE-2024-38634",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38634"
},
{
"name": "CVE-2024-38637",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38637"
},
{
"name": "CVE-2024-38659",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38659"
},
{
"name": "CVE-2024-38780",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38780"
},
{
"name": "CVE-2024-39292",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39292"
}
],
"links": [],
"reference": "CERTFR-2024-AVI-0527",
"revisions": [
{
"description": "Version initiale",
"revision_date": "2024-06-28T00:00:00.000000"
}
],
"risks": [
{
"description": "Non sp\u00e9cifi\u00e9 par l\u0027\u00e9diteur"
},
{
"description": "D\u00e9ni de service"
},
{
"description": "Atteinte \u00e0 la confidentialit\u00e9 des donn\u00e9es"
},
{
"description": "\u00c9l\u00e9vation de privil\u00e8ges"
}
],
"summary": "De multiples vuln\u00e9rabilit\u00e9s ont \u00e9t\u00e9 d\u00e9couvertes dans le noyau Linux de Debian LTS. Elles permettent \u00e0 un attaquant de provoquer une \u00e9l\u00e9vation de privil\u00e8ges, une atteinte \u00e0 la confidentialit\u00e9 des donn\u00e9es et un d\u00e9ni de service.",
"title": "Multiples vuln\u00e9rabilit\u00e9s dans le noyau Linux de Debian LTS",
"vendor_advisories": [
{
"published_at": "2024-06-25",
"title": "Bulletin de s\u00e9curit\u00e9 Debian LTS DLA-3840-1",
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"
},
{
"published_at": "2024-06-25",
"title": "Bulletin de s\u00e9curit\u00e9 Debian LTS DLA-3842-1",
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"
},
{
"published_at": "2024-06-25",
"title": "Bulletin de s\u00e9curit\u00e9 Debian LTS DLA-3843-1",
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html"
},
{
"published_at": "2024-06-25",
"title": "Bulletin de s\u00e9curit\u00e9 Debian LTS DLA-3841-1",
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html"
}
]
}
CERTFR-2024-AVI-0611
Vulnerability from certfr_avis - Published: - Updated:
De multiples vulnérabilités ont été découvertes dans le noyau Linux d'Ubuntu. Certaines d'entre elles permettent à un attaquant de provoquer une exécution de code arbitraire, une élévation de privilèges et un déni de service à distance.
Solutions
Se référer au bulletin de sécurité de l'éditeur pour l'obtention des correctifs (cf. section Documentation).
| Title | Publication Time | Tags | |||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||
{
"$ref": "https://www.cert.ssi.gouv.fr/openapi.json",
"affected_systems": [
{
"description": "Ubuntu 22.04 LTS",
"product": {
"name": "N/A",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 18.04 ESM",
"product": {
"name": "N/A",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 24.04 LTS",
"product": {
"name": "N/A",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 20.04 LTS",
"product": {
"name": "N/A",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 23.10",
"product": {
"name": "N/A",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
}
],
"affected_systems_content": "",
"content": "## Solutions\n\nSe r\u00e9f\u00e9rer au bulletin de s\u00e9curit\u00e9 de l\u0027\u00e9diteur pour l\u0027obtention des correctifs (cf. section Documentation).",
"cves": [
{
"name": "CVE-2022-38096",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-38096"
},
{
"name": "CVE-2024-26600",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26600"
},
{
"name": "CVE-2024-26601",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26601"
},
{
"name": "CVE-2024-26602",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26602"
},
{
"name": "CVE-2024-26603",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26603"
},
{
"name": "CVE-2024-1151",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-1151"
},
{
"name": "CVE-2023-6270",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-6270"
},
{
"name": "CVE-2024-26593",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26593"
},
{
"name": "CVE-2024-26586",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26586"
},
{
"name": "CVE-2022-48627",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48627"
},
{
"name": "CVE-2024-26642",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26642"
},
{
"name": "CVE-2024-26667",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26667"
},
{
"name": "CVE-2024-0841",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-0841"
},
{
"name": "CVE-2024-26695",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26695"
},
{
"name": "CVE-2024-26717",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26717"
},
{
"name": "CVE-2024-26654",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26654"
},
{
"name": "CVE-2024-26629",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26629"
},
{
"name": "CVE-2024-26659",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26659"
},
{
"name": "CVE-2023-52637",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52637"
},
{
"name": "CVE-2024-25739",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-25739"
},
{
"name": "CVE-2024-22099",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-22099"
},
{
"name": "CVE-2024-26664",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26664"
},
{
"name": "CVE-2024-26651",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26651"
},
{
"name": "CVE-2023-7042",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-7042"
},
{
"name": "CVE-2024-23307",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-23307"
},
{
"name": "CVE-2024-26707",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26707"
},
{
"name": "CVE-2024-26697",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26697"
},
{
"name": "CVE-2024-26720",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26720"
},
{
"name": "CVE-2024-26689",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26689"
},
{
"name": "CVE-2024-26748",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26748"
},
{
"name": "CVE-2023-52638",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52638"
},
{
"name": "CVE-2024-26811",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26811"
},
{
"name": "CVE-2024-26606",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26606"
},
{
"name": "CVE-2024-26718",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26718"
},
{
"name": "CVE-2024-26702",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26702"
},
{
"name": "CVE-2024-26814",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26814"
},
{
"name": "CVE-2024-26685",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26685"
},
{
"name": "CVE-2024-26710",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26710"
},
{
"name": "CVE-2024-26803",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26803"
},
{
"name": "CVE-2024-26810",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26810"
},
{
"name": "CVE-2024-26798",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26798"
},
{
"name": "CVE-2024-26663",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26663"
},
{
"name": "CVE-2024-26675",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26675"
},
{
"name": "CVE-2023-52631",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52631"
},
{
"name": "CVE-2024-26712",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26712"
},
{
"name": "CVE-2024-24858",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-24858"
},
{
"name": "CVE-2024-26813",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26813"
},
{
"name": "CVE-2024-27437",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27437"
},
{
"name": "CVE-2024-26735",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26735"
},
{
"name": "CVE-2024-26723",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26723"
},
{
"name": "CVE-2024-26684",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26684"
},
{
"name": "CVE-2024-24857",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-24857"
},
{
"name": "CVE-2024-26660",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26660"
},
{
"name": "CVE-2024-26789",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26789"
},
{
"name": "CVE-2024-26679",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26679"
},
{
"name": "CVE-2024-26816",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26816"
},
{
"name": "CVE-2024-26726",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26726"
},
{
"name": "CVE-2024-26676",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26676"
},
{
"name": "CVE-2024-26688",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26688"
},
{
"name": "CVE-2024-26802",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26802"
},
{
"name": "CVE-2024-26722",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26722"
},
{
"name": "CVE-2024-26681",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26681"
},
{
"name": "CVE-2024-26733",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26733"
},
{
"name": "CVE-2023-52620",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52620"
},
{
"name": "CVE-2024-26700",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26700"
},
{
"name": "CVE-2024-26812",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26812"
},
{
"name": "CVE-2024-26643",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26643"
},
{
"name": "CVE-2024-26665",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26665"
},
{
"name": "CVE-2024-26696",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26696"
},
{
"name": "CVE-2024-26698",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26698"
},
{
"name": "CVE-2024-26687",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26687"
},
{
"name": "CVE-2024-26790",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26790"
},
{
"name": "CVE-2024-26715",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26715"
},
{
"name": "CVE-2024-26714",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26714"
},
{
"name": "CVE-2024-26809",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26809"
},
{
"name": "CVE-2024-26792",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26792"
},
{
"name": "CVE-2024-26680",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26680"
},
{
"name": "CVE-2024-26736",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26736"
},
{
"name": "CVE-2024-26782",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26782"
},
{
"name": "CVE-2023-52488",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52488"
},
{
"name": "CVE-2024-27393",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27393"
},
{
"name": "CVE-2024-27044",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27044"
},
{
"name": "CVE-2024-26863",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26863"
},
{
"name": "CVE-2024-26966",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26966"
},
{
"name": "CVE-2024-27028",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27028"
},
{
"name": "CVE-2024-26980",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26980"
},
{
"name": "CVE-2024-26970",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26970"
},
{
"name": "CVE-2024-26961",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26961"
},
{
"name": "CVE-2024-26917",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26917"
},
{
"name": "CVE-2024-27013",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27013"
},
{
"name": "CVE-2024-26989",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26989"
},
{
"name": "CVE-2023-52644",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52644"
},
{
"name": "CVE-2024-26910",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26910"
},
{
"name": "CVE-2024-27009",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27009"
},
{
"name": "CVE-2024-26931",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26931"
},
{
"name": "CVE-2024-26958",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26958"
},
{
"name": "CVE-2024-27008",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27008"
},
{
"name": "CVE-2024-26875",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26875"
},
{
"name": "CVE-2024-26925",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26925"
},
{
"name": "CVE-2024-26934",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26934"
},
{
"name": "CVE-2024-26957",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26957"
},
{
"name": "CVE-2024-26981",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26981"
},
{
"name": "CVE-2024-26889",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26889"
},
{
"name": "CVE-2024-27000",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27000"
},
{
"name": "CVE-2024-26880",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26880"
},
{
"name": "CVE-2024-27388",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27388"
},
{
"name": "CVE-2024-27003",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27003"
},
{
"name": "CVE-2024-26883",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26883"
},
{
"name": "CVE-2024-26935",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26935"
},
{
"name": "CVE-2024-26974",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26974"
},
{
"name": "CVE-2024-26965",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26965"
},
{
"name": "CVE-2024-26882",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26882"
},
{
"name": "CVE-2024-26987",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26987"
},
{
"name": "CVE-2024-27015",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27015"
},
{
"name": "CVE-2024-26984",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26984"
},
{
"name": "CVE-2024-27020",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27020"
},
{
"name": "CVE-2024-26973",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26973"
},
{
"name": "CVE-2024-27059",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27059"
},
{
"name": "CVE-2024-26960",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26960"
},
{
"name": "CVE-2024-27043",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27043"
},
{
"name": "CVE-2024-26820",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26820"
},
{
"name": "CVE-2024-27038",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27038"
},
{
"name": "CVE-2024-26996",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26996"
},
{
"name": "CVE-2024-27073",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27073"
},
{
"name": "CVE-2024-26936",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26936"
},
{
"name": "CVE-2024-26950",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26950"
},
{
"name": "CVE-2024-26999",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26999"
},
{
"name": "CVE-2024-26874",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26874"
},
{
"name": "CVE-2024-26956",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26956"
},
{
"name": "CVE-2024-26924",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26924"
},
{
"name": "CVE-2024-24861",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-24861"
},
{
"name": "CVE-2024-27004",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27004"
},
{
"name": "CVE-2024-26955",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26955"
},
{
"name": "CVE-2024-27002",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27002"
},
{
"name": "CVE-2024-26920",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26920"
},
{
"name": "CVE-2024-27074",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27074"
},
{
"name": "CVE-2023-52650",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52650"
},
{
"name": "CVE-2024-27016",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27016"
},
{
"name": "CVE-2024-26817",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26817"
},
{
"name": "CVE-2024-26857",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26857"
},
{
"name": "CVE-2024-27001",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27001"
},
{
"name": "CVE-2024-26878",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26878"
},
{
"name": "CVE-2024-26894",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26894"
},
{
"name": "CVE-2024-26976",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26976"
},
{
"name": "CVE-2024-26983",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26983"
},
{
"name": "CVE-2024-26852",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26852"
},
{
"name": "CVE-2024-26859",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26859"
},
{
"name": "CVE-2024-26994",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26994"
},
{
"name": "CVE-2024-26898",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26898"
},
{
"name": "CVE-2023-52642",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52642"
},
{
"name": "CVE-2024-26969",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26969"
},
{
"name": "CVE-2024-26937",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26937"
},
{
"name": "CVE-2024-27030",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27030"
},
{
"name": "CVE-2024-27065",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27065"
},
{
"name": "CVE-2024-26997",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26997"
},
{
"name": "CVE-2024-26922",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26922"
},
{
"name": "CVE-2024-26884",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26884"
},
{
"name": "CVE-2024-27076",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27076"
},
{
"name": "CVE-2024-27014",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27014"
},
{
"name": "CVE-2024-26862",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26862"
},
{
"name": "CVE-2024-27077",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27077"
},
{
"name": "CVE-2024-27078",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27078"
},
{
"name": "CVE-2024-26825",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26825"
},
{
"name": "CVE-2024-26901",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26901"
},
{
"name": "CVE-2024-26992",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26992"
},
{
"name": "CVE-2024-27046",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27046"
},
{
"name": "CVE-2024-26903",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26903"
},
{
"name": "CVE-2024-26993",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26993"
},
{
"name": "CVE-2024-27024",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27024"
},
{
"name": "CVE-2024-27018",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27018"
},
{
"name": "CVE-2024-27053",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27053"
},
{
"name": "CVE-2024-27075",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27075"
},
{
"name": "CVE-2024-26951",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26951"
},
{
"name": "CVE-2024-26855",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26855"
},
{
"name": "CVE-2024-27019",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27019"
},
{
"name": "CVE-2024-26923",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26923"
},
{
"name": "CVE-2024-26851",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26851"
},
{
"name": "CVE-2024-26926",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26926"
},
{
"name": "CVE-2024-27022",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27022"
},
{
"name": "CVE-2024-26988",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26988"
},
{
"name": "CVE-2024-26826",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26826"
},
{
"name": "CVE-2024-26916",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26916"
},
{
"name": "CVE-2023-52643",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52643"
},
{
"name": "CVE-2024-26829",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26829"
},
{
"name": "CVE-2024-21823",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-21823"
},
{
"name": "CVE-2024-26982",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26982"
},
{
"name": "CVE-2024-26830",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26830"
},
{
"name": "CVE-2023-52645",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52645"
},
{
"name": "CVE-2024-26929",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26929"
},
{
"name": "CVE-2024-26828",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26828"
},
{
"name": "CVE-2024-26693",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26693"
},
{
"name": "CVE-2024-26694",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26694"
},
{
"name": "CVE-2024-26919",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26919"
},
{
"name": "CVE-2024-26964",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26964"
},
{
"name": "CVE-2024-36031",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36031"
},
{
"name": "CVE-2023-52656",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52656"
},
{
"name": "CVE-2023-52699",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52699"
},
{
"name": "CVE-2023-52880",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52880"
},
{
"name": "CVE-2024-26822",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26822"
},
{
"name": "CVE-2024-26838",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26838"
},
{
"name": "CVE-2024-26921",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26921"
},
{
"name": "CVE-2024-26928",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26928"
},
{
"name": "CVE-2024-26977",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26977"
},
{
"name": "CVE-2024-27395",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27395"
},
{
"name": "CVE-2024-27396",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27396"
},
{
"name": "CVE-2024-27416",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27416"
},
{
"name": "CVE-2024-27419",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27419"
},
{
"name": "CVE-2024-27436",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27436"
},
{
"name": "CVE-2024-35789",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35789"
},
{
"name": "CVE-2024-35791",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35791"
},
{
"name": "CVE-2024-35796",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35796"
},
{
"name": "CVE-2024-35804",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35804"
},
{
"name": "CVE-2024-35806",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35806"
},
{
"name": "CVE-2024-35809",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35809"
},
{
"name": "CVE-2024-35813",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35813"
},
{
"name": "CVE-2024-35815",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35815"
},
{
"name": "CVE-2024-35817",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35817"
},
{
"name": "CVE-2024-35821",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35821"
},
{
"name": "CVE-2024-35822",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35822"
},
{
"name": "CVE-2024-35823",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35823"
},
{
"name": "CVE-2024-35825",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35825"
},
{
"name": "CVE-2024-35828",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35828"
},
{
"name": "CVE-2024-35830",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35830"
},
{
"name": "CVE-2024-35833",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35833"
},
{
"name": "CVE-2024-35847",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35847"
},
{
"name": "CVE-2024-35849",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35849"
},
{
"name": "CVE-2024-35851",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35851"
},
{
"name": "CVE-2024-35852",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35852"
},
{
"name": "CVE-2024-35854",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35854"
},
{
"name": "CVE-2024-35860",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35860"
},
{
"name": "CVE-2024-35861",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35861"
},
{
"name": "CVE-2024-35862",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35862"
},
{
"name": "CVE-2024-35863",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35863"
},
{
"name": "CVE-2024-35864",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35864"
},
{
"name": "CVE-2024-35865",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35865"
},
{
"name": "CVE-2024-35866",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35866"
},
{
"name": "CVE-2024-35867",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35867"
},
{
"name": "CVE-2024-35868",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35868"
},
{
"name": "CVE-2024-35869",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35869"
},
{
"name": "CVE-2024-35870",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35870"
},
{
"name": "CVE-2024-35872",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35872"
},
{
"name": "CVE-2024-35875",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35875"
},
{
"name": "CVE-2024-35877",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35877"
},
{
"name": "CVE-2024-35878",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35878"
},
{
"name": "CVE-2024-35879",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35879"
},
{
"name": "CVE-2024-35885",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35885"
},
{
"name": "CVE-2024-35887",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35887"
},
{
"name": "CVE-2024-35895",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35895"
},
{
"name": "CVE-2024-35901",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35901"
},
{
"name": "CVE-2024-35904",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35904"
},
{
"name": "CVE-2024-35905",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35905"
},
{
"name": "CVE-2024-35907",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35907"
},
{
"name": "CVE-2024-35912",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35912"
},
{
"name": "CVE-2024-35914",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35914"
},
{
"name": "CVE-2024-35915",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35915"
},
{
"name": "CVE-2024-35922",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35922"
},
{
"name": "CVE-2024-35924",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35924"
},
{
"name": "CVE-2024-35930",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35930"
},
{
"name": "CVE-2024-35932",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35932"
},
{
"name": "CVE-2024-35933",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35933"
},
{
"name": "CVE-2024-35935",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35935"
},
{
"name": "CVE-2024-35936",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35936"
},
{
"name": "CVE-2024-35938",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35938"
},
{
"name": "CVE-2024-35939",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35939"
},
{
"name": "CVE-2024-35940",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35940"
},
{
"name": "CVE-2024-35943",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35943"
},
{
"name": "CVE-2024-35944",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35944"
},
{
"name": "CVE-2024-35950",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35950"
},
{
"name": "CVE-2024-35951",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35951"
},
{
"name": "CVE-2024-35952",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35952"
},
{
"name": "CVE-2024-35955",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35955"
},
{
"name": "CVE-2024-35959",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35959"
},
{
"name": "CVE-2024-35963",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35963"
},
{
"name": "CVE-2024-35964",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35964"
},
{
"name": "CVE-2024-35965",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35965"
},
{
"name": "CVE-2024-35966",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35966"
},
{
"name": "CVE-2024-35967",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35967"
},
{
"name": "CVE-2024-35969",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35969"
},
{
"name": "CVE-2024-35973",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35973"
},
{
"name": "CVE-2024-35976",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35976"
},
{
"name": "CVE-2024-35978",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35978"
},
{
"name": "CVE-2024-35982",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35982"
},
{
"name": "CVE-2024-35984",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35984"
},
{
"name": "CVE-2024-35989",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35989"
},
{
"name": "CVE-2024-35990",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35990"
},
{
"name": "CVE-2024-36006",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36006"
},
{
"name": "CVE-2024-36007",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36007"
},
{
"name": "CVE-2024-36026",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36026"
},
{
"name": "CVE-2024-36029",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36029"
},
{
"name": "CVE-2024-26674",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26674"
},
{
"name": "CVE-2024-26986",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26986"
},
{
"name": "CVE-2024-26990",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26990"
},
{
"name": "CVE-2024-26991",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26991"
},
{
"name": "CVE-2024-26995",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26995"
},
{
"name": "CVE-2024-35819",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35819"
},
{
"name": "CVE-2024-35883",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35883"
},
{
"name": "CVE-2024-35889",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35889"
},
{
"name": "CVE-2024-35891",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35891"
},
{
"name": "CVE-2024-35903",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35903"
},
{
"name": "CVE-2024-35909",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35909"
},
{
"name": "CVE-2024-35911",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35911"
},
{
"name": "CVE-2024-35916",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35916"
},
{
"name": "CVE-2024-35917",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35917"
},
{
"name": "CVE-2024-35921",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35921"
},
{
"name": "CVE-2024-35927",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35927"
},
{
"name": "CVE-2024-35931",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35931"
},
{
"name": "CVE-2024-35937",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35937"
},
{
"name": "CVE-2024-35945",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35945"
},
{
"name": "CVE-2024-35946",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35946"
},
{
"name": "CVE-2024-35953",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35953"
},
{
"name": "CVE-2024-35954",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35954"
},
{
"name": "CVE-2024-35956",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35956"
},
{
"name": "CVE-2024-35958",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35958"
},
{
"name": "CVE-2024-35960",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35960"
},
{
"name": "CVE-2024-35961",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35961"
},
{
"name": "CVE-2024-35971",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35971"
},
{
"name": "CVE-2024-35972",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35972"
},
{
"name": "CVE-2024-35974",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35974"
},
{
"name": "CVE-2024-35975",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35975"
},
{
"name": "CVE-2024-35977",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35977"
},
{
"name": "CVE-2024-35981",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35981"
},
{
"name": "CVE-2024-35997",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35997"
},
{
"name": "CVE-2024-36018",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36018"
},
{
"name": "CVE-2024-36019",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36019"
},
{
"name": "CVE-2024-36020",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36020"
},
{
"name": "CVE-2024-36021",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36021"
},
{
"name": "CVE-2024-36025",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36025"
},
{
"name": "CVE-2024-35785",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35785"
},
{
"name": "CVE-2024-35805",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35805"
},
{
"name": "CVE-2024-35807",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35807"
},
{
"name": "CVE-2024-35853",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35853"
},
{
"name": "CVE-2024-35855",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35855"
},
{
"name": "CVE-2024-35871",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35871"
},
{
"name": "CVE-2024-35884",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35884"
},
{
"name": "CVE-2024-35886",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35886"
},
{
"name": "CVE-2024-35888",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35888"
},
{
"name": "CVE-2024-35893",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35893"
},
{
"name": "CVE-2024-35896",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35896"
},
{
"name": "CVE-2024-35897",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35897"
},
{
"name": "CVE-2024-35898",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35898"
},
{
"name": "CVE-2024-35899",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35899"
},
{
"name": "CVE-2024-35900",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35900"
},
{
"name": "CVE-2024-35902",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35902"
},
{
"name": "CVE-2024-35910",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35910"
},
{
"name": "CVE-2024-35925",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35925"
},
{
"name": "CVE-2024-35934",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35934"
},
{
"name": "CVE-2024-35988",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35988"
},
{
"name": "CVE-2024-36004",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36004"
},
{
"name": "CVE-2024-36005",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36005"
},
{
"name": "CVE-2024-36008",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36008"
},
{
"name": "CVE-2024-26890",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26890"
},
{
"name": "CVE-2024-35890",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35890"
},
{
"name": "CVE-2024-35857",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35857"
},
{
"name": "CVE-2024-35979",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35979"
},
{
"name": "CVE-2024-24859",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-24859"
},
{
"name": "CVE-2024-26661",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26661"
},
{
"name": "CVE-2024-26662",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26662"
},
{
"name": "CVE-2024-26666",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26666"
},
{
"name": "CVE-2024-26677",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26677"
},
{
"name": "CVE-2024-26691",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26691"
},
{
"name": "CVE-2024-26703",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26703"
},
{
"name": "CVE-2024-26708",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26708"
},
{
"name": "CVE-2024-26711",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26711"
},
{
"name": "CVE-2024-26716",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26716"
},
{
"name": "CVE-2024-26719",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26719"
},
{
"name": "CVE-2024-26734",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26734"
},
{
"name": "CVE-2024-26818",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26818"
},
{
"name": "CVE-2024-26824",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26824"
},
{
"name": "CVE-2024-26831",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26831"
},
{
"name": "CVE-2024-26985",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26985"
},
{
"name": "CVE-2024-26998",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26998"
},
{
"name": "CVE-2024-27005",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27005"
},
{
"name": "CVE-2024-27006",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27006"
},
{
"name": "CVE-2024-27007",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27007"
},
{
"name": "CVE-2024-27010",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27010"
},
{
"name": "CVE-2024-27011",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27011"
},
{
"name": "CVE-2024-27012",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27012"
},
{
"name": "CVE-2024-27017",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27017"
},
{
"name": "CVE-2024-27021",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27021"
},
{
"name": "CVE-2024-35873",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35873"
},
{
"name": "CVE-2024-35880",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35880"
},
{
"name": "CVE-2024-35882",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35882"
},
{
"name": "CVE-2024-35892",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35892"
},
{
"name": "CVE-2024-35894",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35894"
},
{
"name": "CVE-2024-35908",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35908"
},
{
"name": "CVE-2024-35913",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35913"
},
{
"name": "CVE-2024-35918",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35918"
},
{
"name": "CVE-2024-35919",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35919"
},
{
"name": "CVE-2024-35920",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35920"
},
{
"name": "CVE-2024-35926",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35926"
},
{
"name": "CVE-2024-35929",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35929"
},
{
"name": "CVE-2024-35942",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35942"
},
{
"name": "CVE-2024-35957",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35957"
},
{
"name": "CVE-2024-35968",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35968"
},
{
"name": "CVE-2024-35970",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35970"
},
{
"name": "CVE-2024-35980",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35980"
},
{
"name": "CVE-2024-35985",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35985"
},
{
"name": "CVE-2024-36022",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36022"
},
{
"name": "CVE-2024-36023",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36023"
},
{
"name": "CVE-2024-36024",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36024"
},
{
"name": "CVE-2024-36027",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36027"
}
],
"links": [],
"reference": "CERTFR-2024-AVI-0611",
"revisions": [
{
"description": "Version initiale",
"revision_date": "2024-07-19T00:00:00.000000"
}
],
"risks": [
{
"description": "Ex\u00e9cution de code arbitraire"
},
{
"description": "\u00c9l\u00e9vation de privil\u00e8ges"
},
{
"description": "D\u00e9ni de service \u00e0 distance"
},
{
"description": "Atteinte \u00e0 la confidentialit\u00e9 des donn\u00e9es"
},
{
"description": "Atteinte \u00e0 l\u0027int\u00e9grit\u00e9 des donn\u00e9es"
},
{
"description": "Contournement de la politique de s\u00e9curit\u00e9"
},
{
"description": "Non sp\u00e9cifi\u00e9 par l\u0027\u00e9diteur"
}
],
"summary": "De multiples vuln\u00e9rabilit\u00e9s ont \u00e9t\u00e9 d\u00e9couvertes dans le noyau Linux d\u0027Ubuntu. Certaines d\u0027entre elles permettent \u00e0 un attaquant de provoquer une ex\u00e9cution de code arbitraire, une \u00e9l\u00e9vation de privil\u00e8ges et un d\u00e9ni de service \u00e0 distance.",
"title": "Multiples vuln\u00e9rabilit\u00e9s dans le noyau Linux d\u0027Ubuntu",
"vendor_advisories": [
{
"published_at": "2024-07-12",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-6896-1",
"url": "https://ubuntu.com/security/notices/USN-6896-1"
},
{
"published_at": "2024-07-15",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-6898-1",
"url": "https://ubuntu.com/security/notices/USN-6898-1"
},
{
"published_at": "2024-07-17",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-6898-2",
"url": "https://ubuntu.com/security/notices/USN-6898-2"
},
{
"published_at": "2024-07-16",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-6895-2",
"url": "https://ubuntu.com/security/notices/USN-6895-2"
},
{
"published_at": "2024-07-11",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-6893-1",
"url": "https://ubuntu.com/security/notices/USN-6893-1"
},
{
"published_at": "2024-07-16",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-6893-2",
"url": "https://ubuntu.com/security/notices/USN-6893-2"
},
{
"published_at": "2024-07-11",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-6864-3",
"url": "https://ubuntu.com/security/notices/USN-6864-3"
},
{
"published_at": "2024-07-17",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-6900-1",
"url": "https://ubuntu.com/security/notices/USN-6900-1"
},
{
"published_at": "2024-07-17",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-6896-3",
"url": "https://ubuntu.com/security/notices/USN-6896-3"
},
{
"published_at": "2024-07-16",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-6896-2",
"url": "https://ubuntu.com/security/notices/USN-6896-2"
},
{
"published_at": "2024-07-12",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-6895-1",
"url": "https://ubuntu.com/security/notices/USN-6895-1"
}
]
}
CERTFR-2024-AVI-0633
Vulnerability from certfr_avis - Published: - Updated:
De multiples vulnérabilités ont été découvertes dans le noyau Linux d'Ubuntu. Certaines d'entre elles permettent à un attaquant de provoquer une exécution de code arbitraire, une élévation de privilèges et une atteinte à la confidentialité des données.
Solutions
Se référer au bulletin de sécurité de l'éditeur pour l'obtention des correctifs (cf. section Documentation).
| Title | Publication Time | Tags | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||
{
"$ref": "https://www.cert.ssi.gouv.fr/openapi.json",
"affected_systems": [
{
"description": "Ubuntu 22.04 LTS",
"product": {
"name": "N/A",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 18.04 ESM",
"product": {
"name": "N/A",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 24.04 LTS",
"product": {
"name": "N/A",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 20.04 LTS",
"product": {
"name": "N/A",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
}
],
"affected_systems_content": "",
"content": "## Solutions\n\nSe r\u00e9f\u00e9rer au bulletin de s\u00e9curit\u00e9 de l\u0027\u00e9diteur pour l\u0027obtention des correctifs (cf. section Documentation).",
"cves": [
{
"name": "CVE-2022-38096",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-38096"
},
{
"name": "CVE-2024-26600",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26600"
},
{
"name": "CVE-2024-26601",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26601"
},
{
"name": "CVE-2024-26602",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26602"
},
{
"name": "CVE-2024-26603",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26603"
},
{
"name": "CVE-2024-1151",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-1151"
},
{
"name": "CVE-2023-6270",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-6270"
},
{
"name": "CVE-2024-26593",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26593"
},
{
"name": "CVE-2024-26586",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26586"
},
{
"name": "CVE-2022-48627",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48627"
},
{
"name": "CVE-2024-26642",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26642"
},
{
"name": "CVE-2024-26667",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26667"
},
{
"name": "CVE-2024-0841",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-0841"
},
{
"name": "CVE-2024-26695",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26695"
},
{
"name": "CVE-2024-26717",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26717"
},
{
"name": "CVE-2024-26654",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26654"
},
{
"name": "CVE-2024-26629",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26629"
},
{
"name": "CVE-2024-26659",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26659"
},
{
"name": "CVE-2023-52637",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52637"
},
{
"name": "CVE-2024-25739",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-25739"
},
{
"name": "CVE-2024-22099",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-22099"
},
{
"name": "CVE-2024-26664",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26664"
},
{
"name": "CVE-2024-26651",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26651"
},
{
"name": "CVE-2023-7042",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-7042"
},
{
"name": "CVE-2024-23307",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-23307"
},
{
"name": "CVE-2024-26707",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26707"
},
{
"name": "CVE-2024-26697",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26697"
},
{
"name": "CVE-2024-26720",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26720"
},
{
"name": "CVE-2024-26689",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26689"
},
{
"name": "CVE-2024-26748",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26748"
},
{
"name": "CVE-2023-52638",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52638"
},
{
"name": "CVE-2024-26811",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26811"
},
{
"name": "CVE-2024-26606",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26606"
},
{
"name": "CVE-2024-26718",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26718"
},
{
"name": "CVE-2024-26702",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26702"
},
{
"name": "CVE-2024-26814",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26814"
},
{
"name": "CVE-2024-26685",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26685"
},
{
"name": "CVE-2024-26710",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26710"
},
{
"name": "CVE-2024-26803",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26803"
},
{
"name": "CVE-2024-26810",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26810"
},
{
"name": "CVE-2024-26798",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26798"
},
{
"name": "CVE-2024-26663",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26663"
},
{
"name": "CVE-2024-26675",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26675"
},
{
"name": "CVE-2023-52631",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52631"
},
{
"name": "CVE-2024-26712",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26712"
},
{
"name": "CVE-2024-24858",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-24858"
},
{
"name": "CVE-2024-26813",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26813"
},
{
"name": "CVE-2024-27437",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27437"
},
{
"name": "CVE-2024-26735",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26735"
},
{
"name": "CVE-2024-26723",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26723"
},
{
"name": "CVE-2024-26684",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26684"
},
{
"name": "CVE-2024-24857",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-24857"
},
{
"name": "CVE-2024-26660",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26660"
},
{
"name": "CVE-2024-26789",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26789"
},
{
"name": "CVE-2024-26679",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26679"
},
{
"name": "CVE-2024-26816",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26816"
},
{
"name": "CVE-2024-26726",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26726"
},
{
"name": "CVE-2024-26676",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26676"
},
{
"name": "CVE-2024-26688",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26688"
},
{
"name": "CVE-2024-26802",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26802"
},
{
"name": "CVE-2024-26722",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26722"
},
{
"name": "CVE-2024-26681",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26681"
},
{
"name": "CVE-2024-26733",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26733"
},
{
"name": "CVE-2023-52620",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52620"
},
{
"name": "CVE-2024-26700",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26700"
},
{
"name": "CVE-2024-26812",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26812"
},
{
"name": "CVE-2024-26665",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26665"
},
{
"name": "CVE-2024-26696",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26696"
},
{
"name": "CVE-2024-26698",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26698"
},
{
"name": "CVE-2024-26687",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26687"
},
{
"name": "CVE-2024-26790",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26790"
},
{
"name": "CVE-2024-26715",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26715"
},
{
"name": "CVE-2024-26714",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26714"
},
{
"name": "CVE-2024-26792",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26792"
},
{
"name": "CVE-2024-26680",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26680"
},
{
"name": "CVE-2024-26736",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26736"
},
{
"name": "CVE-2024-26782",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26782"
},
{
"name": "CVE-2023-52488",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52488"
},
{
"name": "CVE-2024-27393",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27393"
},
{
"name": "CVE-2024-27044",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27044"
},
{
"name": "CVE-2024-26863",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26863"
},
{
"name": "CVE-2024-26966",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26966"
},
{
"name": "CVE-2024-27028",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27028"
},
{
"name": "CVE-2024-26980",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26980"
},
{
"name": "CVE-2024-26970",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26970"
},
{
"name": "CVE-2024-26961",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26961"
},
{
"name": "CVE-2024-26917",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26917"
},
{
"name": "CVE-2024-27013",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27013"
},
{
"name": "CVE-2024-26989",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26989"
},
{
"name": "CVE-2023-52644",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52644"
},
{
"name": "CVE-2024-26910",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26910"
},
{
"name": "CVE-2024-27009",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27009"
},
{
"name": "CVE-2024-26931",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26931"
},
{
"name": "CVE-2024-26958",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26958"
},
{
"name": "CVE-2024-27008",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27008"
},
{
"name": "CVE-2024-26875",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26875"
},
{
"name": "CVE-2024-26925",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26925"
},
{
"name": "CVE-2024-26934",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26934"
},
{
"name": "CVE-2024-26957",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26957"
},
{
"name": "CVE-2024-26981",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26981"
},
{
"name": "CVE-2024-26889",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26889"
},
{
"name": "CVE-2024-27000",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27000"
},
{
"name": "CVE-2024-26880",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26880"
},
{
"name": "CVE-2024-27388",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27388"
},
{
"name": "CVE-2024-27003",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27003"
},
{
"name": "CVE-2024-26883",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26883"
},
{
"name": "CVE-2024-26935",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26935"
},
{
"name": "CVE-2024-26974",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26974"
},
{
"name": "CVE-2024-26965",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26965"
},
{
"name": "CVE-2024-26882",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26882"
},
{
"name": "CVE-2024-26987",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26987"
},
{
"name": "CVE-2024-27015",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27015"
},
{
"name": "CVE-2024-26984",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26984"
},
{
"name": "CVE-2024-27020",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27020"
},
{
"name": "CVE-2024-26973",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26973"
},
{
"name": "CVE-2024-27059",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27059"
},
{
"name": "CVE-2024-26960",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26960"
},
{
"name": "CVE-2024-27043",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27043"
},
{
"name": "CVE-2024-26820",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26820"
},
{
"name": "CVE-2024-27038",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27038"
},
{
"name": "CVE-2024-26996",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26996"
},
{
"name": "CVE-2024-27073",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27073"
},
{
"name": "CVE-2024-26936",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26936"
},
{
"name": "CVE-2024-26950",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26950"
},
{
"name": "CVE-2024-26999",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26999"
},
{
"name": "CVE-2024-26874",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26874"
},
{
"name": "CVE-2024-26956",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26956"
},
{
"name": "CVE-2024-24861",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-24861"
},
{
"name": "CVE-2024-27004",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27004"
},
{
"name": "CVE-2024-26955",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26955"
},
{
"name": "CVE-2024-27002",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27002"
},
{
"name": "CVE-2024-26920",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26920"
},
{
"name": "CVE-2024-27074",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27074"
},
{
"name": "CVE-2023-52650",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52650"
},
{
"name": "CVE-2024-27016",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27016"
},
{
"name": "CVE-2024-26817",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26817"
},
{
"name": "CVE-2024-26857",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26857"
},
{
"name": "CVE-2024-27001",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27001"
},
{
"name": "CVE-2024-26878",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26878"
},
{
"name": "CVE-2024-26894",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26894"
},
{
"name": "CVE-2024-26976",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26976"
},
{
"name": "CVE-2024-26983",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26983"
},
{
"name": "CVE-2024-26852",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26852"
},
{
"name": "CVE-2024-26859",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26859"
},
{
"name": "CVE-2024-26994",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26994"
},
{
"name": "CVE-2024-26898",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26898"
},
{
"name": "CVE-2023-52642",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52642"
},
{
"name": "CVE-2024-26969",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26969"
},
{
"name": "CVE-2024-26937",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26937"
},
{
"name": "CVE-2024-27030",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27030"
},
{
"name": "CVE-2024-27065",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27065"
},
{
"name": "CVE-2024-26997",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26997"
},
{
"name": "CVE-2024-26922",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26922"
},
{
"name": "CVE-2024-26884",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26884"
},
{
"name": "CVE-2024-27076",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27076"
},
{
"name": "CVE-2024-27014",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27014"
},
{
"name": "CVE-2024-26862",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26862"
},
{
"name": "CVE-2024-27077",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27077"
},
{
"name": "CVE-2024-27078",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27078"
},
{
"name": "CVE-2024-26825",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26825"
},
{
"name": "CVE-2024-26901",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26901"
},
{
"name": "CVE-2024-26992",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26992"
},
{
"name": "CVE-2024-27046",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27046"
},
{
"name": "CVE-2024-26903",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26903"
},
{
"name": "CVE-2024-26993",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26993"
},
{
"name": "CVE-2024-27024",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27024"
},
{
"name": "CVE-2024-27018",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27018"
},
{
"name": "CVE-2024-27053",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27053"
},
{
"name": "CVE-2024-27075",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27075"
},
{
"name": "CVE-2024-26951",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26951"
},
{
"name": "CVE-2024-26855",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26855"
},
{
"name": "CVE-2024-27019",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27019"
},
{
"name": "CVE-2024-26923",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26923"
},
{
"name": "CVE-2024-26851",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26851"
},
{
"name": "CVE-2024-26926",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26926"
},
{
"name": "CVE-2024-27022",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27022"
},
{
"name": "CVE-2024-26988",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26988"
},
{
"name": "CVE-2024-26826",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26826"
},
{
"name": "CVE-2024-26916",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26916"
},
{
"name": "CVE-2023-52643",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52643"
},
{
"name": "CVE-2024-26829",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26829"
},
{
"name": "CVE-2024-26982",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26982"
},
{
"name": "CVE-2024-26830",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26830"
},
{
"name": "CVE-2023-52645",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52645"
},
{
"name": "CVE-2024-26929",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26929"
},
{
"name": "CVE-2024-26828",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26828"
},
{
"name": "CVE-2024-26693",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26693"
},
{
"name": "CVE-2024-26694",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26694"
},
{
"name": "CVE-2024-26919",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26919"
},
{
"name": "CVE-2024-26964",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26964"
},
{
"name": "CVE-2023-52656",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52656"
},
{
"name": "CVE-2023-52699",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52699"
},
{
"name": "CVE-2023-52880",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52880"
},
{
"name": "CVE-2024-26822",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26822"
},
{
"name": "CVE-2024-26838",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26838"
},
{
"name": "CVE-2024-26921",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26921"
},
{
"name": "CVE-2024-26928",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26928"
},
{
"name": "CVE-2024-26977",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26977"
},
{
"name": "CVE-2024-27395",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27395"
},
{
"name": "CVE-2024-27396",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27396"
},
{
"name": "CVE-2024-27416",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27416"
},
{
"name": "CVE-2024-27419",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27419"
},
{
"name": "CVE-2024-27436",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27436"
},
{
"name": "CVE-2024-35789",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35789"
},
{
"name": "CVE-2024-35791",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35791"
},
{
"name": "CVE-2024-35796",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35796"
},
{
"name": "CVE-2024-35804",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35804"
},
{
"name": "CVE-2024-35806",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35806"
},
{
"name": "CVE-2024-35809",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35809"
},
{
"name": "CVE-2024-35813",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35813"
},
{
"name": "CVE-2024-35815",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35815"
},
{
"name": "CVE-2024-35817",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35817"
},
{
"name": "CVE-2024-35821",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35821"
},
{
"name": "CVE-2024-35822",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35822"
},
{
"name": "CVE-2024-35823",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35823"
},
{
"name": "CVE-2024-35825",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35825"
},
{
"name": "CVE-2024-35828",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35828"
},
{
"name": "CVE-2024-35830",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35830"
},
{
"name": "CVE-2024-35833",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35833"
},
{
"name": "CVE-2024-35847",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35847"
},
{
"name": "CVE-2024-35849",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35849"
},
{
"name": "CVE-2024-35851",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35851"
},
{
"name": "CVE-2024-35852",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35852"
},
{
"name": "CVE-2024-35854",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35854"
},
{
"name": "CVE-2024-35860",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35860"
},
{
"name": "CVE-2024-35861",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35861"
},
{
"name": "CVE-2024-35862",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35862"
},
{
"name": "CVE-2024-35863",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35863"
},
{
"name": "CVE-2024-35864",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35864"
},
{
"name": "CVE-2024-35865",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35865"
},
{
"name": "CVE-2024-35866",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35866"
},
{
"name": "CVE-2024-35867",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35867"
},
{
"name": "CVE-2024-35868",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35868"
},
{
"name": "CVE-2024-35869",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35869"
},
{
"name": "CVE-2024-35870",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35870"
},
{
"name": "CVE-2024-35872",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35872"
},
{
"name": "CVE-2024-35875",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35875"
},
{
"name": "CVE-2024-35877",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35877"
},
{
"name": "CVE-2024-35878",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35878"
},
{
"name": "CVE-2024-35879",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35879"
},
{
"name": "CVE-2024-35885",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35885"
},
{
"name": "CVE-2024-35887",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35887"
},
{
"name": "CVE-2024-35895",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35895"
},
{
"name": "CVE-2024-35901",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35901"
},
{
"name": "CVE-2024-35904",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35904"
},
{
"name": "CVE-2024-35905",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35905"
},
{
"name": "CVE-2024-35907",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35907"
},
{
"name": "CVE-2024-35912",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35912"
},
{
"name": "CVE-2024-35914",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35914"
},
{
"name": "CVE-2024-35915",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35915"
},
{
"name": "CVE-2024-35922",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35922"
},
{
"name": "CVE-2024-35924",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35924"
},
{
"name": "CVE-2024-35930",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35930"
},
{
"name": "CVE-2024-35932",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35932"
},
{
"name": "CVE-2024-35933",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35933"
},
{
"name": "CVE-2024-35935",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35935"
},
{
"name": "CVE-2024-35936",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35936"
},
{
"name": "CVE-2024-35938",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35938"
},
{
"name": "CVE-2024-35939",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35939"
},
{
"name": "CVE-2024-35940",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35940"
},
{
"name": "CVE-2024-35943",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35943"
},
{
"name": "CVE-2024-35944",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35944"
},
{
"name": "CVE-2024-35950",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35950"
},
{
"name": "CVE-2024-35951",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35951"
},
{
"name": "CVE-2024-35952",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35952"
},
{
"name": "CVE-2024-35955",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35955"
},
{
"name": "CVE-2024-35959",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35959"
},
{
"name": "CVE-2024-35963",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35963"
},
{
"name": "CVE-2024-35964",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35964"
},
{
"name": "CVE-2024-35965",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35965"
},
{
"name": "CVE-2024-35966",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35966"
},
{
"name": "CVE-2024-35967",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35967"
},
{
"name": "CVE-2024-35969",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35969"
},
{
"name": "CVE-2024-35973",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35973"
},
{
"name": "CVE-2024-35976",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35976"
},
{
"name": "CVE-2024-35978",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35978"
},
{
"name": "CVE-2024-35982",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35982"
},
{
"name": "CVE-2024-35984",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35984"
},
{
"name": "CVE-2024-35989",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35989"
},
{
"name": "CVE-2024-35990",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35990"
},
{
"name": "CVE-2024-36006",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36006"
},
{
"name": "CVE-2024-36007",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36007"
},
{
"name": "CVE-2024-36026",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36026"
},
{
"name": "CVE-2024-36029",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36029"
},
{
"name": "CVE-2024-26674",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26674"
},
{
"name": "CVE-2024-26986",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26986"
},
{
"name": "CVE-2024-26990",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26990"
},
{
"name": "CVE-2024-26991",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26991"
},
{
"name": "CVE-2024-26995",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26995"
},
{
"name": "CVE-2024-35819",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35819"
},
{
"name": "CVE-2024-35883",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35883"
},
{
"name": "CVE-2024-35889",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35889"
},
{
"name": "CVE-2024-35891",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35891"
},
{
"name": "CVE-2024-35903",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35903"
},
{
"name": "CVE-2024-35909",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35909"
},
{
"name": "CVE-2024-35911",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35911"
},
{
"name": "CVE-2024-35916",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35916"
},
{
"name": "CVE-2024-35917",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35917"
},
{
"name": "CVE-2024-35921",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35921"
},
{
"name": "CVE-2024-35927",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35927"
},
{
"name": "CVE-2024-35931",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35931"
},
{
"name": "CVE-2024-35937",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35937"
},
{
"name": "CVE-2024-35945",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35945"
},
{
"name": "CVE-2024-35946",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35946"
},
{
"name": "CVE-2024-35953",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35953"
},
{
"name": "CVE-2024-35954",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35954"
},
{
"name": "CVE-2024-35956",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35956"
},
{
"name": "CVE-2024-35958",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35958"
},
{
"name": "CVE-2024-35960",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35960"
},
{
"name": "CVE-2024-35961",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35961"
},
{
"name": "CVE-2024-35971",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35971"
},
{
"name": "CVE-2024-35972",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35972"
},
{
"name": "CVE-2024-35974",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35974"
},
{
"name": "CVE-2024-35975",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35975"
},
{
"name": "CVE-2024-35977",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35977"
},
{
"name": "CVE-2024-35981",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35981"
},
{
"name": "CVE-2024-35997",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35997"
},
{
"name": "CVE-2024-36018",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36018"
},
{
"name": "CVE-2024-36019",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36019"
},
{
"name": "CVE-2024-36020",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36020"
},
{
"name": "CVE-2024-36021",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36021"
},
{
"name": "CVE-2024-36025",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36025"
},
{
"name": "CVE-2024-35785",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35785"
},
{
"name": "CVE-2024-35805",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35805"
},
{
"name": "CVE-2024-35807",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35807"
},
{
"name": "CVE-2024-35853",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35853"
},
{
"name": "CVE-2024-35855",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35855"
},
{
"name": "CVE-2024-35871",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35871"
},
{
"name": "CVE-2024-35884",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35884"
},
{
"name": "CVE-2024-35886",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35886"
},
{
"name": "CVE-2024-35888",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35888"
},
{
"name": "CVE-2024-35893",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35893"
},
{
"name": "CVE-2024-35896",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35896"
},
{
"name": "CVE-2024-35897",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35897"
},
{
"name": "CVE-2024-35898",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35898"
},
{
"name": "CVE-2024-35899",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35899"
},
{
"name": "CVE-2024-35900",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35900"
},
{
"name": "CVE-2024-35902",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35902"
},
{
"name": "CVE-2024-35910",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35910"
},
{
"name": "CVE-2024-35925",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35925"
},
{
"name": "CVE-2024-35934",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35934"
},
{
"name": "CVE-2024-35988",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35988"
},
{
"name": "CVE-2024-36004",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36004"
},
{
"name": "CVE-2024-36005",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36005"
},
{
"name": "CVE-2024-36008",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36008"
},
{
"name": "CVE-2024-26890",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26890"
},
{
"name": "CVE-2024-35890",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35890"
},
{
"name": "CVE-2024-35857",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35857"
},
{
"name": "CVE-2024-35979",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35979"
},
{
"name": "CVE-2024-24859",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-24859"
},
{
"name": "CVE-2024-26661",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26661"
},
{
"name": "CVE-2024-26662",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26662"
},
{
"name": "CVE-2024-26666",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26666"
},
{
"name": "CVE-2024-26677",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26677"
},
{
"name": "CVE-2024-26691",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26691"
},
{
"name": "CVE-2024-26703",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26703"
},
{
"name": "CVE-2024-26708",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26708"
},
{
"name": "CVE-2024-26711",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26711"
},
{
"name": "CVE-2024-26716",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26716"
},
{
"name": "CVE-2024-26719",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26719"
},
{
"name": "CVE-2024-26734",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26734"
},
{
"name": "CVE-2024-26818",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26818"
},
{
"name": "CVE-2024-26824",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26824"
},
{
"name": "CVE-2024-26831",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26831"
},
{
"name": "CVE-2024-26985",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26985"
},
{
"name": "CVE-2024-26998",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26998"
},
{
"name": "CVE-2024-27005",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27005"
},
{
"name": "CVE-2024-27006",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27006"
},
{
"name": "CVE-2024-27007",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27007"
},
{
"name": "CVE-2024-27010",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27010"
},
{
"name": "CVE-2024-27011",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27011"
},
{
"name": "CVE-2024-27012",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27012"
},
{
"name": "CVE-2024-27017",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27017"
},
{
"name": "CVE-2024-27021",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27021"
},
{
"name": "CVE-2024-35873",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35873"
},
{
"name": "CVE-2024-35880",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35880"
},
{
"name": "CVE-2024-35882",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35882"
},
{
"name": "CVE-2024-35892",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35892"
},
{
"name": "CVE-2024-35894",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35894"
},
{
"name": "CVE-2024-35908",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35908"
},
{
"name": "CVE-2024-35913",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35913"
},
{
"name": "CVE-2024-35918",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35918"
},
{
"name": "CVE-2024-35919",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35919"
},
{
"name": "CVE-2024-35920",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35920"
},
{
"name": "CVE-2024-35926",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35926"
},
{
"name": "CVE-2024-35929",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35929"
},
{
"name": "CVE-2024-35942",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35942"
},
{
"name": "CVE-2024-35957",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35957"
},
{
"name": "CVE-2024-35968",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35968"
},
{
"name": "CVE-2024-35970",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35970"
},
{
"name": "CVE-2024-35980",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35980"
},
{
"name": "CVE-2024-35985",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35985"
},
{
"name": "CVE-2024-36022",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36022"
},
{
"name": "CVE-2024-36023",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36023"
},
{
"name": "CVE-2024-36024",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36024"
},
{
"name": "CVE-2024-36027",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36027"
}
],
"links": [],
"reference": "CERTFR-2024-AVI-0633",
"revisions": [
{
"description": "Version initiale",
"revision_date": "2024-07-26T00:00:00.000000"
}
],
"risks": [
{
"description": "Atteinte \u00e0 l\u0027int\u00e9grit\u00e9 des donn\u00e9es"
},
{
"description": "Ex\u00e9cution de code arbitraire"
},
{
"description": "Non sp\u00e9cifi\u00e9 par l\u0027\u00e9diteur"
},
{
"description": "D\u00e9ni de service"
},
{
"description": "Contournement de la politique de s\u00e9curit\u00e9"
},
{
"description": "Atteinte \u00e0 la confidentialit\u00e9 des donn\u00e9es"
},
{
"description": "\u00c9l\u00e9vation de privil\u00e8ges"
}
],
"summary": "De multiples vuln\u00e9rabilit\u00e9s ont \u00e9t\u00e9 d\u00e9couvertes dans le noyau Linux d\u0027Ubuntu. Certaines d\u0027entre elles permettent \u00e0 un attaquant de provoquer une ex\u00e9cution de code arbitraire, une \u00e9l\u00e9vation de privil\u00e8ges et une atteinte \u00e0 la confidentialit\u00e9 des donn\u00e9es.",
"title": "Multiples vuln\u00e9rabilit\u00e9s dans le noyau Linux d\u0027Ubuntu",
"vendor_advisories": [
{
"published_at": "2024-07-19",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-6895-3",
"url": "https://ubuntu.com/security/notices/USN-6895-3"
},
{
"published_at": "2024-07-23",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-6898-4",
"url": "https://ubuntu.com/security/notices/USN-6898-4"
},
{
"published_at": "2024-07-19",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-6896-4",
"url": "https://ubuntu.com/security/notices/USN-6896-4"
},
{
"published_at": "2024-07-19",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-6898-3",
"url": "https://ubuntu.com/security/notices/USN-6898-3"
},
{
"published_at": "2024-07-23",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-6893-3",
"url": "https://ubuntu.com/security/notices/USN-6893-3"
},
{
"published_at": "2024-07-23",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-6896-5",
"url": "https://ubuntu.com/security/notices/USN-6896-5"
}
]
}
CERTFR-2024-AVI-0667
Vulnerability from certfr_avis - Published: - Updated:
De multiples vulnérabilités ont été découvertes dans le noyau Linux d'Ubuntu. Certaines d'entre elles permettent à un attaquant de provoquer une exécution de code arbitraire, une élévation de privilèges et un déni de service à distance.
Solutions
Se référer au bulletin de sécurité de l'éditeur pour l'obtention des correctifs (cf. section Documentation).
| Title | Publication Time | Tags | ||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||
{
"$ref": "https://www.cert.ssi.gouv.fr/openapi.json",
"affected_systems": [
{
"description": "Ubuntu 22.04 LTS",
"product": {
"name": "N/A",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 18.04 ESM",
"product": {
"name": "N/A",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 24.04 LTS",
"product": {
"name": "N/A",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 14.04 ESM",
"product": {
"name": "N/A",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 20.04 LTS",
"product": {
"name": "N/A",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
}
],
"affected_systems_content": "",
"content": "## Solutions\n\nSe r\u00e9f\u00e9rer au bulletin de s\u00e9curit\u00e9 de l\u0027\u00e9diteur pour l\u0027obtention des correctifs (cf. section Documentation).",
"cves": [
{
"name": "CVE-2023-46343",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-46343"
},
{
"name": "CVE-2024-25744",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-25744"
},
{
"name": "CVE-2024-26600",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26600"
},
{
"name": "CVE-2023-52436",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52436"
},
{
"name": "CVE-2023-52443",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52443"
},
{
"name": "CVE-2023-52469",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52469"
},
{
"name": "CVE-2023-52449",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52449"
},
{
"name": "CVE-2023-52444",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52444"
},
{
"name": "CVE-2024-26601",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26601"
},
{
"name": "CVE-2024-26602",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26602"
},
{
"name": "CVE-2024-26603",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26603"
},
{
"name": "CVE-2024-1151",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-1151"
},
{
"name": "CVE-2023-6270",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-6270"
},
{
"name": "CVE-2024-26593",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26593"
},
{
"name": "CVE-2024-26585",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26585"
},
{
"name": "CVE-2023-52434",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52434"
},
{
"name": "CVE-2023-52435",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52435"
},
{
"name": "CVE-2024-26642",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26642"
},
{
"name": "CVE-2024-26667",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26667"
},
{
"name": "CVE-2024-0841",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-0841"
},
{
"name": "CVE-2024-26695",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26695"
},
{
"name": "CVE-2024-26717",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26717"
},
{
"name": "CVE-2024-26659",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26659"
},
{
"name": "CVE-2023-52637",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52637"
},
{
"name": "CVE-2024-25739",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-25739"
},
{
"name": "CVE-2024-25742",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-25742"
},
{
"name": "CVE-2024-26664",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26664"
},
{
"name": "CVE-2024-23307",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-23307"
},
{
"name": "CVE-2024-26584",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26584"
},
{
"name": "CVE-2024-26707",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26707"
},
{
"name": "CVE-2024-26697",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26697"
},
{
"name": "CVE-2024-26720",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26720"
},
{
"name": "CVE-2024-26689",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26689"
},
{
"name": "CVE-2024-26748",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26748"
},
{
"name": "CVE-2023-52638",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52638"
},
{
"name": "CVE-2024-26606",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26606"
},
{
"name": "CVE-2024-26718",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26718"
},
{
"name": "CVE-2024-26702",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26702"
},
{
"name": "CVE-2024-26685",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26685"
},
{
"name": "CVE-2024-26583",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26583"
},
{
"name": "CVE-2024-26710",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26710"
},
{
"name": "CVE-2024-26803",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26803"
},
{
"name": "CVE-2024-26798",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26798"
},
{
"name": "CVE-2024-26663",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26663"
},
{
"name": "CVE-2024-26675",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26675"
},
{
"name": "CVE-2023-52631",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52631"
},
{
"name": "CVE-2024-26712",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26712"
},
{
"name": "CVE-2024-24858",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-24858"
},
{
"name": "CVE-2024-26735",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26735"
},
{
"name": "CVE-2024-26723",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26723"
},
{
"name": "CVE-2024-26684",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26684"
},
{
"name": "CVE-2024-24857",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-24857"
},
{
"name": "CVE-2024-26660",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26660"
},
{
"name": "CVE-2024-26789",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26789"
},
{
"name": "CVE-2024-26679",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26679"
},
{
"name": "CVE-2024-26726",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26726"
},
{
"name": "CVE-2024-26676",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26676"
},
{
"name": "CVE-2024-26688",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26688"
},
{
"name": "CVE-2024-26802",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26802"
},
{
"name": "CVE-2024-26722",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26722"
},
{
"name": "CVE-2024-26681",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26681"
},
{
"name": "CVE-2024-26733",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26733"
},
{
"name": "CVE-2023-52620",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52620"
},
{
"name": "CVE-2024-26700",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26700"
},
{
"name": "CVE-2024-26665",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26665"
},
{
"name": "CVE-2024-26696",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26696"
},
{
"name": "CVE-2024-26698",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26698"
},
{
"name": "CVE-2024-26790",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26790"
},
{
"name": "CVE-2024-26715",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26715"
},
{
"name": "CVE-2024-26714",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26714"
},
{
"name": "CVE-2024-26792",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26792"
},
{
"name": "CVE-2024-26680",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26680"
},
{
"name": "CVE-2024-26736",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26736"
},
{
"name": "CVE-2024-26782",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26782"
},
{
"name": "CVE-2024-26980",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26980"
},
{
"name": "CVE-2024-26917",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26917"
},
{
"name": "CVE-2024-27013",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27013"
},
{
"name": "CVE-2024-26840",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26840"
},
{
"name": "CVE-2024-26910",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26910"
},
{
"name": "CVE-2024-26907",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26907"
},
{
"name": "CVE-2024-26934",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26934"
},
{
"name": "CVE-2024-26889",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26889"
},
{
"name": "CVE-2024-26882",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26882"
},
{
"name": "CVE-2024-27020",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27020"
},
{
"name": "CVE-2024-26820",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26820"
},
{
"name": "CVE-2024-26936",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26936"
},
{
"name": "CVE-2024-24861",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-24861"
},
{
"name": "CVE-2024-26920",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26920"
},
{
"name": "CVE-2024-26857",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26857"
},
{
"name": "CVE-2024-26898",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26898"
},
{
"name": "CVE-2023-52642",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52642"
},
{
"name": "CVE-2024-26922",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26922"
},
{
"name": "CVE-2024-26884",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26884"
},
{
"name": "CVE-2024-26825",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26825"
},
{
"name": "CVE-2024-26901",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26901"
},
{
"name": "CVE-2024-27019",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27019"
},
{
"name": "CVE-2024-26923",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26923"
},
{
"name": "CVE-2024-26926",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26926"
},
{
"name": "CVE-2024-26826",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26826"
},
{
"name": "CVE-2024-26916",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26916"
},
{
"name": "CVE-2023-52643",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52643"
},
{
"name": "CVE-2024-26829",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26829"
},
{
"name": "CVE-2024-26830",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26830"
},
{
"name": "CVE-2023-52645",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52645"
},
{
"name": "CVE-2021-47131",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47131"
},
{
"name": "CVE-2023-52585",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52585"
},
{
"name": "CVE-2022-48655",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48655"
},
{
"name": "CVE-2024-26828",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26828"
},
{
"name": "CVE-2024-26693",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26693"
},
{
"name": "CVE-2024-26694",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26694"
},
{
"name": "CVE-2024-26919",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26919"
},
{
"name": "CVE-2023-52882",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52882"
},
{
"name": "CVE-2024-26900",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26900"
},
{
"name": "CVE-2024-27398",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27398"
},
{
"name": "CVE-2024-27399",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27399"
},
{
"name": "CVE-2024-27401",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27401"
},
{
"name": "CVE-2024-35848",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35848"
},
{
"name": "CVE-2024-35947",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35947"
},
{
"name": "CVE-2024-36017",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36017"
},
{
"name": "CVE-2024-36031",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36031"
},
{
"name": "CVE-2024-36883",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36883"
},
{
"name": "CVE-2024-36886",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36886"
},
{
"name": "CVE-2024-36889",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36889"
},
{
"name": "CVE-2024-36902",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36902"
},
{
"name": "CVE-2024-36904",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36904"
},
{
"name": "CVE-2024-36905",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36905"
},
{
"name": "CVE-2024-36916",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36916"
},
{
"name": "CVE-2024-36919",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36919"
},
{
"name": "CVE-2024-36929",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36929"
},
{
"name": "CVE-2024-36933",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36933"
},
{
"name": "CVE-2024-36934",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36934"
},
{
"name": "CVE-2024-36939",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36939"
},
{
"name": "CVE-2024-36940",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36940"
},
{
"name": "CVE-2024-36941",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36941"
},
{
"name": "CVE-2024-36946",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36946"
},
{
"name": "CVE-2024-36950",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36950"
},
{
"name": "CVE-2024-36953",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36953"
},
{
"name": "CVE-2024-36954",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36954"
},
{
"name": "CVE-2024-36957",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36957"
},
{
"name": "CVE-2024-36959",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36959"
},
{
"name": "CVE-2023-52880",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52880"
},
{
"name": "CVE-2024-26822",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26822"
},
{
"name": "CVE-2024-26838",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26838"
},
{
"name": "CVE-2024-27395",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27395"
},
{
"name": "CVE-2024-27396",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27396"
},
{
"name": "CVE-2024-27400",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27400"
},
{
"name": "CVE-2024-27416",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27416"
},
{
"name": "CVE-2024-35833",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35833"
},
{
"name": "CVE-2024-35847",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35847"
},
{
"name": "CVE-2024-35849",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35849"
},
{
"name": "CVE-2024-35851",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35851"
},
{
"name": "CVE-2024-35852",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35852"
},
{
"name": "CVE-2024-35854",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35854"
},
{
"name": "CVE-2024-35976",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35976"
},
{
"name": "CVE-2024-35978",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35978"
},
{
"name": "CVE-2024-35982",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35982"
},
{
"name": "CVE-2024-35984",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35984"
},
{
"name": "CVE-2024-35989",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35989"
},
{
"name": "CVE-2024-35990",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35990"
},
{
"name": "CVE-2024-35998",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35998"
},
{
"name": "CVE-2024-35999",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35999"
},
{
"name": "CVE-2024-36006",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36006"
},
{
"name": "CVE-2024-36007",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36007"
},
{
"name": "CVE-2024-36012",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36012"
},
{
"name": "CVE-2024-36014",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36014"
},
{
"name": "CVE-2024-36015",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36015"
},
{
"name": "CVE-2024-36016",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36016"
},
{
"name": "CVE-2024-36029",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36029"
},
{
"name": "CVE-2024-36032",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36032"
},
{
"name": "CVE-2024-36880",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36880"
},
{
"name": "CVE-2024-36893",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36893"
},
{
"name": "CVE-2024-36896",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36896"
},
{
"name": "CVE-2024-36897",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36897"
},
{
"name": "CVE-2024-36906",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36906"
},
{
"name": "CVE-2024-36918",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36918"
},
{
"name": "CVE-2024-36924",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36924"
},
{
"name": "CVE-2024-36926",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36926"
},
{
"name": "CVE-2024-36928",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36928"
},
{
"name": "CVE-2024-36931",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36931"
},
{
"name": "CVE-2024-36938",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36938"
},
{
"name": "CVE-2024-36944",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36944"
},
{
"name": "CVE-2024-36947",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36947"
},
{
"name": "CVE-2024-36952",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36952"
},
{
"name": "CVE-2024-36955",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36955"
},
{
"name": "CVE-2024-26674",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26674"
},
{
"name": "CVE-2024-35850",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35850"
},
{
"name": "CVE-2024-35986",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35986"
},
{
"name": "CVE-2024-35991",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35991"
},
{
"name": "CVE-2024-35992",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35992"
},
{
"name": "CVE-2024-35997",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35997"
},
{
"name": "CVE-2024-36002",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36002"
},
{
"name": "CVE-2024-36009",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36009"
},
{
"name": "CVE-2024-36011",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36011"
},
{
"name": "CVE-2024-36013",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36013"
},
{
"name": "CVE-2024-36030",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36030"
},
{
"name": "CVE-2024-36890",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36890"
},
{
"name": "CVE-2024-36891",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36891"
},
{
"name": "CVE-2024-36894",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36894"
},
{
"name": "CVE-2024-36895",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36895"
},
{
"name": "CVE-2024-36898",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36898"
},
{
"name": "CVE-2024-36921",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36921"
},
{
"name": "CVE-2024-36922",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36922"
},
{
"name": "CVE-2024-36930",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36930"
},
{
"name": "CVE-2024-36936",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36936"
},
{
"name": "CVE-2024-36949",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36949"
},
{
"name": "CVE-2024-36951",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36951"
},
{
"name": "CVE-2024-31076",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-31076"
},
{
"name": "CVE-2024-33621",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-33621"
},
{
"name": "CVE-2024-35853",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35853"
},
{
"name": "CVE-2024-35855",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35855"
},
{
"name": "CVE-2024-35983",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35983"
},
{
"name": "CVE-2024-35988",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35988"
},
{
"name": "CVE-2024-35996",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35996"
},
{
"name": "CVE-2024-36004",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36004"
},
{
"name": "CVE-2024-36005",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36005"
},
{
"name": "CVE-2024-36008",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36008"
},
{
"name": "CVE-2024-36286",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36286"
},
{
"name": "CVE-2024-36960",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36960"
},
{
"name": "CVE-2024-36964",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36964"
},
{
"name": "CVE-2024-36971",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36971"
},
{
"name": "CVE-2024-37353",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-37353"
},
{
"name": "CVE-2024-37356",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-37356"
},
{
"name": "CVE-2024-38381",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38381"
},
{
"name": "CVE-2024-38549",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38549"
},
{
"name": "CVE-2024-38552",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38552"
},
{
"name": "CVE-2024-38558",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38558"
},
{
"name": "CVE-2024-38559",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38559"
},
{
"name": "CVE-2024-38560",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38560"
},
{
"name": "CVE-2024-38565",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38565"
},
{
"name": "CVE-2024-38567",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38567"
},
{
"name": "CVE-2024-38578",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38578"
},
{
"name": "CVE-2024-38579",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38579"
},
{
"name": "CVE-2024-38582",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38582"
},
{
"name": "CVE-2024-38583",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38583"
},
{
"name": "CVE-2024-38587",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38587"
},
{
"name": "CVE-2024-38589",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38589"
},
{
"name": "CVE-2024-38596",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38596"
},
{
"name": "CVE-2024-38598",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38598"
},
{
"name": "CVE-2024-38599",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38599"
},
{
"name": "CVE-2024-38601",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38601"
},
{
"name": "CVE-2024-38612",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38612"
},
{
"name": "CVE-2024-38618",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38618"
},
{
"name": "CVE-2024-38621",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38621"
},
{
"name": "CVE-2024-38627",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38627"
},
{
"name": "CVE-2024-38633",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38633"
},
{
"name": "CVE-2024-38634",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38634"
},
{
"name": "CVE-2024-38637",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38637"
},
{
"name": "CVE-2024-38659",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38659"
},
{
"name": "CVE-2024-38780",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38780"
},
{
"name": "CVE-2024-39292",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39292"
},
{
"name": "CVE-2024-26886",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26886"
},
{
"name": "CVE-2024-26890",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26890"
},
{
"name": "CVE-2022-48772",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48772"
},
{
"name": "CVE-2023-52752",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52752"
},
{
"name": "CVE-2024-35857",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35857"
},
{
"name": "CVE-2024-36899",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36899"
},
{
"name": "CVE-2024-36900",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36900"
},
{
"name": "CVE-2024-36915",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36915"
},
{
"name": "CVE-2024-36917",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36917"
},
{
"name": "CVE-2024-36923",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36923"
},
{
"name": "CVE-2024-36937",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36937"
},
{
"name": "CVE-2024-36945",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36945"
},
{
"name": "CVE-2024-36965",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36965"
},
{
"name": "CVE-2024-36967",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36967"
},
{
"name": "CVE-2024-36969",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36969"
},
{
"name": "CVE-2024-36975",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36975"
},
{
"name": "CVE-2024-38540",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38540"
},
{
"name": "CVE-2024-38541",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38541"
},
{
"name": "CVE-2024-38544",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38544"
},
{
"name": "CVE-2024-38545",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38545"
},
{
"name": "CVE-2024-38546",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38546"
},
{
"name": "CVE-2024-38547",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38547"
},
{
"name": "CVE-2024-38548",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38548"
},
{
"name": "CVE-2024-38550",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38550"
},
{
"name": "CVE-2024-38553",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38553"
},
{
"name": "CVE-2024-38555",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38555"
},
{
"name": "CVE-2024-38556",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38556"
},
{
"name": "CVE-2024-38557",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38557"
},
{
"name": "CVE-2024-38564",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38564"
},
{
"name": "CVE-2024-38568",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38568"
},
{
"name": "CVE-2024-38571",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38571"
},
{
"name": "CVE-2024-38573",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38573"
},
{
"name": "CVE-2024-38580",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38580"
},
{
"name": "CVE-2024-38590",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38590"
},
{
"name": "CVE-2024-38591",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38591"
},
{
"name": "CVE-2024-38594",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38594"
},
{
"name": "CVE-2024-38597",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38597"
},
{
"name": "CVE-2024-38600",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38600"
},
{
"name": "CVE-2024-38603",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38603"
},
{
"name": "CVE-2024-38605",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38605"
},
{
"name": "CVE-2024-38616",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38616"
},
{
"name": "CVE-2024-38635",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38635"
},
{
"name": "CVE-2024-38661",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38661"
},
{
"name": "CVE-2024-39301",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39301"
},
{
"name": "CVE-2024-39471",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39471"
},
{
"name": "CVE-2024-38610",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38610"
},
{
"name": "CVE-2024-39475",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39475"
},
{
"name": "CVE-2024-24859",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-24859"
},
{
"name": "CVE-2024-26661",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26661"
},
{
"name": "CVE-2024-26662",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26662"
},
{
"name": "CVE-2024-26666",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26666"
},
{
"name": "CVE-2024-26677",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26677"
},
{
"name": "CVE-2024-26691",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26691"
},
{
"name": "CVE-2024-26703",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26703"
},
{
"name": "CVE-2024-26708",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26708"
},
{
"name": "CVE-2024-26711",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26711"
},
{
"name": "CVE-2024-26716",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26716"
},
{
"name": "CVE-2024-26719",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26719"
},
{
"name": "CVE-2024-26734",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26734"
},
{
"name": "CVE-2024-26818",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26818"
},
{
"name": "CVE-2024-26824",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26824"
},
{
"name": "CVE-2024-26831",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26831"
},
{
"name": "CVE-2024-36270",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36270"
},
{
"name": "CVE-2024-38543",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38543"
},
{
"name": "CVE-2024-38586",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38586"
},
{
"name": "CVE-2024-38593",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38593"
},
{
"name": "CVE-2024-38607",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38607"
},
{
"name": "CVE-2024-38613",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38613"
},
{
"name": "CVE-2024-38615",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38615"
},
{
"name": "CVE-2024-39276",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39276"
},
{
"name": "CVE-2024-39467",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39467"
},
{
"name": "CVE-2024-39480",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39480"
},
{
"name": "CVE-2024-39482",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39482"
},
{
"name": "CVE-2024-39488",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39488"
},
{
"name": "CVE-2024-39489",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39489"
},
{
"name": "CVE-2024-39493",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39493"
},
{
"name": "CVE-2024-36882",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36882"
},
{
"name": "CVE-2024-36887",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36887"
},
{
"name": "CVE-2024-36903",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36903"
},
{
"name": "CVE-2024-36935",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36935"
},
{
"name": "CVE-2024-36962",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36962"
},
{
"name": "CVE-2024-36977",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36977"
},
{
"name": "CVE-2024-38539",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38539"
},
{
"name": "CVE-2024-38551",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38551"
},
{
"name": "CVE-2024-38554",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38554"
},
{
"name": "CVE-2024-38562",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38562"
},
{
"name": "CVE-2024-38566",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38566"
},
{
"name": "CVE-2024-38569",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38569"
},
{
"name": "CVE-2024-38570",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38570"
},
{
"name": "CVE-2024-38572",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38572"
},
{
"name": "CVE-2024-38575",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38575"
},
{
"name": "CVE-2024-38588",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38588"
},
{
"name": "CVE-2024-38592",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38592"
},
{
"name": "CVE-2024-38595",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38595"
},
{
"name": "CVE-2024-38602",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38602"
},
{
"name": "CVE-2024-38611",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38611"
},
{
"name": "CVE-2024-38617",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38617"
},
{
"name": "CVE-2022-48674",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48674"
},
{
"name": "CVE-2024-27394",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27394"
},
{
"name": "CVE-2024-35846",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35846"
},
{
"name": "CVE-2024-35856",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35856"
},
{
"name": "CVE-2024-35858",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35858"
},
{
"name": "CVE-2024-35859",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35859"
},
{
"name": "CVE-2024-35949",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35949"
},
{
"name": "CVE-2024-35987",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35987"
},
{
"name": "CVE-2024-35993",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35993"
},
{
"name": "CVE-2024-35994",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35994"
},
{
"name": "CVE-2024-36000",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36000"
},
{
"name": "CVE-2024-36001",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36001"
},
{
"name": "CVE-2024-36003",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36003"
},
{
"name": "CVE-2024-36028",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36028"
},
{
"name": "CVE-2024-36033",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36033"
},
{
"name": "CVE-2024-36881",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36881"
},
{
"name": "CVE-2024-36884",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36884"
},
{
"name": "CVE-2024-36888",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36888"
},
{
"name": "CVE-2024-36892",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36892"
},
{
"name": "CVE-2024-36901",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36901"
},
{
"name": "CVE-2024-36908",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36908"
},
{
"name": "CVE-2024-36909",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36909"
},
{
"name": "CVE-2024-36910",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36910"
},
{
"name": "CVE-2024-36911",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36911"
},
{
"name": "CVE-2024-36912",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36912"
},
{
"name": "CVE-2024-36913",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36913"
},
{
"name": "CVE-2024-36914",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36914"
},
{
"name": "CVE-2024-36920",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36920"
},
{
"name": "CVE-2024-36925",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36925"
},
{
"name": "CVE-2024-36927",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36927"
},
{
"name": "CVE-2024-36932",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36932"
},
{
"name": "CVE-2024-36943",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36943"
},
{
"name": "CVE-2024-36948",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36948"
},
{
"name": "CVE-2024-36956",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36956"
},
{
"name": "CVE-2024-36958",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36958"
},
{
"name": "CVE-2024-36961",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36961"
},
{
"name": "CVE-2024-36963",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36963"
},
{
"name": "CVE-2024-36966",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36966"
},
{
"name": "CVE-2024-36968",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36968"
},
{
"name": "CVE-2024-36979",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36979"
},
{
"name": "CVE-2024-38538",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38538"
},
{
"name": "CVE-2024-38542",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38542"
},
{
"name": "CVE-2024-38561",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38561"
},
{
"name": "CVE-2024-38563",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38563"
},
{
"name": "CVE-2024-38574",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38574"
},
{
"name": "CVE-2024-38576",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38576"
},
{
"name": "CVE-2024-38577",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38577"
},
{
"name": "CVE-2024-38584",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38584"
},
{
"name": "CVE-2024-38585",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38585"
},
{
"name": "CVE-2024-38604",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38604"
},
{
"name": "CVE-2024-38606",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38606"
},
{
"name": "CVE-2024-38614",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38614"
},
{
"name": "CVE-2024-38620",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38620"
},
{
"name": "CVE-2024-41011",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41011"
},
{
"name": "CVE-2024-42134",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42134"
}
],
"links": [],
"reference": "CERTFR-2024-AVI-0667",
"revisions": [
{
"description": "Version initiale",
"revision_date": "2024-08-09T00:00:00.000000"
}
],
"risks": [
{
"description": "Ex\u00e9cution de code arbitraire"
},
{
"description": "\u00c9l\u00e9vation de privil\u00e8ges"
},
{
"description": "D\u00e9ni de service \u00e0 distance"
},
{
"description": "Atteinte \u00e0 la confidentialit\u00e9 des donn\u00e9es"
},
{
"description": "Atteinte \u00e0 l\u0027int\u00e9grit\u00e9 des donn\u00e9es"
},
{
"description": "Contournement de la politique de s\u00e9curit\u00e9"
},
{
"description": "Non sp\u00e9cifi\u00e9 par l\u0027\u00e9diteur"
}
],
"summary": "De multiples vuln\u00e9rabilit\u00e9s ont \u00e9t\u00e9 d\u00e9couvertes dans le noyau Linux d\u0027Ubuntu. Certaines d\u0027entre elles permettent \u00e0 un attaquant de provoquer une ex\u00e9cution de code arbitraire, une \u00e9l\u00e9vation de privil\u00e8ges et un d\u00e9ni de service \u00e0 distance.",
"title": "Multiples vuln\u00e9rabilit\u00e9s dans le noyau Linux d\u0027Ubuntu",
"vendor_advisories": [
{
"published_at": "2024-08-02",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-6895-4",
"url": "https://ubuntu.com/security/notices/USN-6895-4"
},
{
"published_at": "2024-08-08",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-6951-1",
"url": "https://ubuntu.com/security/notices/USN-6951-1"
},
{
"published_at": "2024-08-01",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-6926-2",
"url": "https://ubuntu.com/security/notices/USN-6926-2"
},
{
"published_at": "2024-08-09",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-6952-1",
"url": "https://ubuntu.com/security/notices/USN-6952-1"
},
{
"published_at": "2024-08-08",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-6949-1",
"url": "https://ubuntu.com/security/notices/USN-6949-1"
},
{
"published_at": "2024-08-01",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-6922-2",
"url": "https://ubuntu.com/security/notices/USN-6922-2"
},
{
"published_at": "2024-08-08",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-6950-1",
"url": "https://ubuntu.com/security/notices/USN-6950-1"
},
{
"published_at": "2024-08-09",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-6953-1",
"url": "https://ubuntu.com/security/notices/USN-6953-1"
}
]
}
FKIE_CVE-2024-26917
Vulnerability from fkie_nvd - Published: 2024-04-17 16:15 - Updated: 2026-06-17 07:18| Vendor | Product | Version | |
|---|---|---|---|
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | 6.8 | |
| linux | linux_kernel | 6.8 | |
| linux | linux_kernel | 6.8 | |
| linux | linux_kernel | 6.8 | |
| debian | debian_linux | 10.0 |
{
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/scsi/fcoe/fcoe_ctlr.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "94a600226b6d0ef065ee84024b450b566c5a87d6",
"status": "affected",
"version": "264eae2f523d2aae38188facb4ece893023f25da",
"versionType": "git"
},
{
"lessThan": "2209fc6e3d7727d787dc6ef9baa1e9eae6b1295b",
"status": "affected",
"version": "d2bf25674cea74b865d367d09be5dfe9aff5922a",
"versionType": "git"
},
{
"lessThan": "7d4e19f7ff644c5b79e8271df8ac2e549b436a5b",
"status": "affected",
"version": "9cce8ef7a6fa858bbcacd8679a5ca5a4fd3a6df3",
"versionType": "git"
},
{
"lessThan": "5b8f473c4de95c056c1c767b1ad48c191544f6a5",
"status": "affected",
"version": "076fb40cf27ab9232d8cce1f007e663e46705302",
"versionType": "git"
},
{
"lessThan": "6bb22ac1d11d7d20f91e7fd2e657a9e5f6db65e0",
"status": "affected",
"version": "5a5fb3b1754fa2b4db95f0151b4af0fb6f8918ec",
"versionType": "git"
},
{
"lessThan": "2996c7e97ea7cf4c1838a1b1dbc0885934113783",
"status": "affected",
"version": "1a1975551943f681772720f639ff42fbaa746212",
"versionType": "git"
},
{
"lessThan": "25675159040bffc7992d5163f3f33ba7d0142f21",
"status": "affected",
"version": "1a1975551943f681772720f639ff42fbaa746212",
"versionType": "git"
},
{
"lessThan": "977fe773dcc7098d8eaf4ee6382cb51e13e784cb",
"status": "affected",
"version": "1a1975551943f681772720f639ff42fbaa746212",
"versionType": "git"
},
{
"status": "affected",
"version": "4ea46b479a00dd232f0dbc81fdc27f9330ecb3ad",
"versionType": "git"
},
{
"status": "affected",
"version": "694ddc5bf35a5b6f9acb6e4724324c910a1237f1",
"versionType": "git"
},
{
"status": "affected",
"version": "6c5d7242bcf2154e9576e5eb2a98c6984ca5ea9a",
"versionType": "git"
},
{
"lessThan": "4.19.307",
"status": "affected",
"version": "4.19.295",
"versionType": "semver"
},
{
"lessThan": "5.4.269",
"status": "affected",
"version": "5.4.257",
"versionType": "semver"
},
{
"lessThan": "5.10.210",
"status": "affected",
"version": "5.10.195",
"versionType": "semver"
},
{
"lessThan": "5.15.149",
"status": "affected",
"version": "5.15.132",
"versionType": "semver"
},
{
"lessThan": "6.1.79",
"status": "affected",
"version": "6.1.53",
"versionType": "semver"
},
{
"lessThan": "4.15",
"status": "affected",
"version": "4.14.326",
"versionType": "semver"
},
{
"lessThan": "6.5",
"status": "affected",
"version": "6.4.16",
"versionType": "semver"
},
{
"lessThan": "6.6",
"status": "affected",
"version": "6.5.3",
"versionType": "semver"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/scsi/fcoe/fcoe_ctlr.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "6.6"
},
{
"lessThan": "6.6",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "4.19.*",
"status": "unaffected",
"version": "4.19.307",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.269",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.210",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.149",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.79",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.18",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.7.*",
"status": "unaffected",
"version": "6.7.6",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.8",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"configurations": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "B7B3CDB0-0B42-463E-9E20-DD9CF990E40F",
"versionEndExcluding": "4.15",
"versionStartIncluding": "4.14.326",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "F6F52BF0-7A2F-423B-9280-8EFBC7B234B9",
"versionEndExcluding": "4.19.307",
"versionStartIncluding": "4.19.295",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "A670275E-A8A2-46B1-B18B-3218633C1FA8",
"versionEndExcluding": "5.4.269",
"versionStartIncluding": "5.4.257",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "202F35E5-FEC4-4A4C-953B-590C17E977E8",
"versionEndExcluding": "5.10.210",
"versionStartIncluding": "5.10.195",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "27538677-D1D6-43B6-8A7B-C69C5C098268",
"versionEndExcluding": "5.15.149",
"versionStartIncluding": "5.15.132",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "380879E6-C700-4766-8E8C-244A54409750",
"versionEndExcluding": "6.1.79",
"versionStartIncluding": "6.1.53",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "A5099559-2D15-42A5-A561-71B34FEFF36F",
"versionEndExcluding": "6.5",
"versionStartIncluding": "6.4.16",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "DAA49602-5E3F-4837-8384-4A57145682AC",
"versionEndExcluding": "6.6.18",
"versionStartIncluding": "6.5.3",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "C6D6A5C8-7308-42A9-8A72-ABF3DEA4BB82",
"versionEndExcluding": "6.7.6",
"versionStartIncluding": "6.7",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.8:rc1:*:*:*:*:*:*",
"matchCriteriaId": "B9F4EA73-0894-400F-A490-3A397AB7A517",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.8:rc2:*:*:*:*:*:*",
"matchCriteriaId": "056BD938-0A27-4569-B391-30578B309EE3",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.8:rc3:*:*:*:*:*:*",
"matchCriteriaId": "F02056A5-B362-4370-9FF8-6F0BD384D520",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.8:rc4:*:*:*:*:*:*",
"matchCriteriaId": "62075ACE-B2A0-4B16-829D-B3DA5AE5CC41",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
},
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:debian:debian_linux:10.0:*:*:*:*:*:*:*",
"matchCriteriaId": "07B237A9-69A3-4A9C-9DA0-4E06BD37AE73",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: Revert \"scsi: fcoe: Fix potential deadlock on \u0026fip-\u003ectlr_lock\"\n\nThis reverts commit 1a1975551943f681772720f639ff42fbaa746212.\n\nThis commit causes interrupts to be lost for FCoE devices, since it changed\nsping locks from \"bh\" to \"irqsave\".\n\nInstead, a work queue should be used, and will be addressed in a separate\ncommit."
},
{
"lang": "es",
"value": "En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: scsi: Revertir \"scsi: fcoe: Reparar posible punto muerto en \u0026amp;fip-\u0026gt;ctlr_lock\" Esto revierte el commit 1a1975551943f681772720f639ff42fbaa746212. Este commit provoca que se pierdan las interrupciones para los dispositivos FCoE, ya que cambi\u00f3 los bloqueos de sping de \"bh\" a \"irqsave\". En su lugar, se debe utilizar una cola de trabajo, que se abordar\u00e1 en un commit separado."
}
],
"id": "CVE-2024-26917",
"lastModified": "2026-06-17T07:18:41.047",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 5.5,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 3.6,
"source": "nvd@nist.gov",
"type": "Primary"
}
],
"ssvcV203": [
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"ssvcData": {
"id": "CVE-2024-26917",
"options": [
{
"exploitation": "none"
},
{
"automatable": "no"
},
{
"technicalImpact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2024-09-10T15:47:50.224233Z",
"version": "2.0.3"
}
}
]
},
"published": "2024-04-17T16:15:08.247",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/2209fc6e3d7727d787dc6ef9baa1e9eae6b1295b"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/25675159040bffc7992d5163f3f33ba7d0142f21"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/2996c7e97ea7cf4c1838a1b1dbc0885934113783"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/5b8f473c4de95c056c1c767b1ad48c191544f6a5"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/6bb22ac1d11d7d20f91e7fd2e657a9e5f6db65e0"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/7d4e19f7ff644c5b79e8271df8ac2e549b436a5b"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/94a600226b6d0ef065ee84024b450b566c5a87d6"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/977fe773dcc7098d8eaf4ee6382cb51e13e784cb"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/2209fc6e3d7727d787dc6ef9baa1e9eae6b1295b"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/25675159040bffc7992d5163f3f33ba7d0142f21"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/2996c7e97ea7cf4c1838a1b1dbc0885934113783"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/5b8f473c4de95c056c1c767b1ad48c191544f6a5"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/6bb22ac1d11d7d20f91e7fd2e657a9e5f6db65e0"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/7d4e19f7ff644c5b79e8271df8ac2e549b436a5b"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/94a600226b6d0ef065ee84024b450b566c5a87d6"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/977fe773dcc7098d8eaf4ee6382cb51e13e784cb"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Mailing List"
],
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Mailing List"
],
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Analyzed",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "NVD-CWE-noinfo"
}
],
"source": "nvd@nist.gov",
"type": "Primary"
}
]
}
GHSA-M546-6CP3-J348
Vulnerability from github – Published: 2024-04-17 18:31 – Updated: 2025-02-03 18:30In the Linux kernel, the following vulnerability has been resolved:
scsi: Revert "scsi: fcoe: Fix potential deadlock on &fip->ctlr_lock"
This reverts commit 1a1975551943f681772720f639ff42fbaa746212.
This commit causes interrupts to be lost for FCoE devices, since it changed sping locks from "bh" to "irqsave".
Instead, a work queue should be used, and will be addressed in a separate commit.
{
"affected": [],
"aliases": [
"CVE-2024-26917"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-17T16:15:08Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: Revert \"scsi: fcoe: Fix potential deadlock on \u0026fip-\u003ectlr_lock\"\n\nThis reverts commit 1a1975551943f681772720f639ff42fbaa746212.\n\nThis commit causes interrupts to be lost for FCoE devices, since it changed\nsping locks from \"bh\" to \"irqsave\".\n\nInstead, a work queue should be used, and will be addressed in a separate\ncommit.",
"id": "GHSA-m546-6cp3-j348",
"modified": "2025-02-03T18:30:36Z",
"published": "2024-04-17T18:31:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26917"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2209fc6e3d7727d787dc6ef9baa1e9eae6b1295b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/25675159040bffc7992d5163f3f33ba7d0142f21"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2996c7e97ea7cf4c1838a1b1dbc0885934113783"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5b8f473c4de95c056c1c767b1ad48c191544f6a5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6bb22ac1d11d7d20f91e7fd2e657a9e5f6db65e0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7d4e19f7ff644c5b79e8271df8ac2e549b436a5b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/94a600226b6d0ef065ee84024b450b566c5a87d6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/977fe773dcc7098d8eaf4ee6382cb51e13e784cb"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GSD-2024-26917
Vulnerability from gsd - Updated: 2024-02-20 06:02{
"gsd": {
"metadata": {
"exploitCode": "unknown",
"remediation": "unknown",
"reportConfidence": "confirmed",
"type": "vulnerability"
},
"osvSchema": {
"aliases": [
"CVE-2024-26917"
],
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: Revert \"scsi: fcoe: Fix potential deadlock on \u0026fip-\u003ectlr_lock\"\n\nThis reverts commit 1a1975551943f681772720f639ff42fbaa746212.\n\nThis commit causes interrupts to be lost for FCoE devices, since it changed\nsping locks from \"bh\" to \"irqsave\".\n\nInstead, a work queue should be used, and will be addressed in a separate\ncommit.",
"id": "GSD-2024-26917",
"modified": "2024-02-20T06:02:29.313596Z",
"schema_version": "1.4.0"
}
},
"namespaces": {
"cve.org": {
"CVE_data_meta": {
"ASSIGNER": "cve@kernel.org",
"ID": "CVE-2024-26917",
"STATE": "PUBLIC"
},
"affects": {
"vendor": {
"vendor_data": [
{
"product": {
"product_data": [
{
"product_name": "Linux",
"version": {
"version_data": [
{
"version_affected": "\u003c",
"version_name": "264eae2f523d",
"version_value": "94a600226b6d"
},
{
"version_affected": "\u003c",
"version_name": "d2bf25674cea",
"version_value": "2209fc6e3d77"
},
{
"version_affected": "\u003c",
"version_name": "9cce8ef7a6fa",
"version_value": "7d4e19f7ff64"
},
{
"version_affected": "\u003c",
"version_name": "076fb40cf27a",
"version_value": "5b8f473c4de9"
},
{
"version_affected": "\u003c",
"version_name": "5a5fb3b1754f",
"version_value": "6bb22ac1d11d"
},
{
"version_affected": "\u003c",
"version_name": "1a1975551943",
"version_value": "2996c7e97ea7"
},
{
"version_value": "not down converted",
"x_cve_json_5_version_data": {
"defaultStatus": "affected",
"versions": [
{
"status": "affected",
"version": "6.6"
},
{
"lessThan": "6.6",
"status": "unaffected",
"version": "0",
"versionType": "custom"
},
{
"lessThanOrEqual": "4.19.*",
"status": "unaffected",
"version": "4.19.307",
"versionType": "custom"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.269",
"versionType": "custom"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.210",
"versionType": "custom"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.149",
"versionType": "custom"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.79",
"versionType": "custom"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.18",
"versionType": "custom"
},
{
"lessThanOrEqual": "6.7.*",
"status": "unaffected",
"version": "6.7.6",
"versionType": "custom"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.8",
"versionType": "original_commit_for_fix"
}
]
}
}
]
}
}
]
},
"vendor_name": "Linux"
}
]
}
},
"data_format": "MITRE",
"data_type": "CVE",
"data_version": "4.0",
"description": {
"description_data": [
{
"lang": "eng",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: Revert \"scsi: fcoe: Fix potential deadlock on \u0026fip-\u003ectlr_lock\"\n\nThis reverts commit 1a1975551943f681772720f639ff42fbaa746212.\n\nThis commit causes interrupts to be lost for FCoE devices, since it changed\nsping locks from \"bh\" to \"irqsave\".\n\nInstead, a work queue should be used, and will be addressed in a separate\ncommit."
}
]
},
"generator": {
"engine": "bippy-d175d3acf727"
},
"problemtype": {
"problemtype_data": [
{
"description": [
{
"lang": "eng",
"value": "n/a"
}
]
}
]
},
"references": {
"reference_data": [
{
"name": "https://git.kernel.org/stable/c/94a600226b6d0ef065ee84024b450b566c5a87d6",
"refsource": "MISC",
"url": "https://git.kernel.org/stable/c/94a600226b6d0ef065ee84024b450b566c5a87d6"
},
{
"name": "https://git.kernel.org/stable/c/2209fc6e3d7727d787dc6ef9baa1e9eae6b1295b",
"refsource": "MISC",
"url": "https://git.kernel.org/stable/c/2209fc6e3d7727d787dc6ef9baa1e9eae6b1295b"
},
{
"name": "https://git.kernel.org/stable/c/7d4e19f7ff644c5b79e8271df8ac2e549b436a5b",
"refsource": "MISC",
"url": "https://git.kernel.org/stable/c/7d4e19f7ff644c5b79e8271df8ac2e549b436a5b"
},
{
"name": "https://git.kernel.org/stable/c/5b8f473c4de95c056c1c767b1ad48c191544f6a5",
"refsource": "MISC",
"url": "https://git.kernel.org/stable/c/5b8f473c4de95c056c1c767b1ad48c191544f6a5"
},
{
"name": "https://git.kernel.org/stable/c/6bb22ac1d11d7d20f91e7fd2e657a9e5f6db65e0",
"refsource": "MISC",
"url": "https://git.kernel.org/stable/c/6bb22ac1d11d7d20f91e7fd2e657a9e5f6db65e0"
},
{
"name": "https://git.kernel.org/stable/c/2996c7e97ea7cf4c1838a1b1dbc0885934113783",
"refsource": "MISC",
"url": "https://git.kernel.org/stable/c/2996c7e97ea7cf4c1838a1b1dbc0885934113783"
},
{
"name": "https://git.kernel.org/stable/c/25675159040bffc7992d5163f3f33ba7d0142f21",
"refsource": "MISC",
"url": "https://git.kernel.org/stable/c/25675159040bffc7992d5163f3f33ba7d0142f21"
},
{
"name": "https://git.kernel.org/stable/c/977fe773dcc7098d8eaf4ee6382cb51e13e784cb",
"refsource": "MISC",
"url": "https://git.kernel.org/stable/c/977fe773dcc7098d8eaf4ee6382cb51e13e784cb"
}
]
}
},
"nvd.nist.gov": {
"cve": {
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: Revert \"scsi: fcoe: Fix potential deadlock on \u0026fip-\u003ectlr_lock\"\n\nThis reverts commit 1a1975551943f681772720f639ff42fbaa746212.\n\nThis commit causes interrupts to be lost for FCoE devices, since it changed\nsping locks from \"bh\" to \"irqsave\".\n\nInstead, a work queue should be used, and will be addressed in a separate\ncommit."
},
{
"lang": "es",
"value": "En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: scsi: Revertir \"scsi: fcoe: Reparar posible punto muerto en \u0026amp;fip-\u0026gt;ctlr_lock\" Esto revierte el commit 1a1975551943f681772720f639ff42fbaa746212. Este commit provoca que se pierdan las interrupciones para los dispositivos FCoE, ya que cambi\u00f3 los bloqueos de sping de \"bh\" a \"irqsave\". En su lugar, se debe utilizar una cola de trabajo, que se abordar\u00e1 en un commit separado."
}
],
"id": "CVE-2024-26917",
"lastModified": "2024-04-17T16:51:07.347",
"metrics": {},
"published": "2024-04-17T16:15:08.247",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/2209fc6e3d7727d787dc6ef9baa1e9eae6b1295b"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/25675159040bffc7992d5163f3f33ba7d0142f21"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/2996c7e97ea7cf4c1838a1b1dbc0885934113783"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/5b8f473c4de95c056c1c767b1ad48c191544f6a5"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/6bb22ac1d11d7d20f91e7fd2e657a9e5f6db65e0"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/7d4e19f7ff644c5b79e8271df8ac2e549b436a5b"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/94a600226b6d0ef065ee84024b450b566c5a87d6"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/977fe773dcc7098d8eaf4ee6382cb51e13e784cb"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Awaiting Analysis"
}
}
}
}
OESA-2024-1622 (CVE-2022-48655)
Vulnerability from osv_openeuler – Published: 2024-05-17 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:
firmware: arm_scmi: Harden accesses to the reset domains
Accessing reset domains descriptors by the index upon the SCMI drivers requests through the SCMI reset operations interface can potentially lead to out-of-bound violations if the SCMI driver misbehave.
Add an internal consistency check before any such domains descriptors accesses.(CVE-2022-48655)
In the Linux kernel, the following vulnerability has been resolved:
erofs: fix pcluster use-after-free on UP platforms
During stress testing with CONFIG_SMP disabled, KASAN reports as below:
================================================================== BUG: KASAN: use-after-free in __mutex_lock+0xe5/0xc30 Read of size 8 at addr ffff8881094223f8 by task stress/7789
CPU: 0 PID: 7789 Comm: stress Not tainted 6.0.0-rc1-00002-g0d53d2e882f9 #3 Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 Call Trace: <TASK> .. __mutex_lock+0xe5/0xc30 .. z_erofs_do_read_page+0x8ce/0x1560 .. z_erofs_readahead+0x31c/0x580 .. Freed by task 7787 kasan_save_stack+0x1e/0x40 kasan_set_track+0x20/0x30 kasan_set_free_info+0x20/0x40 __kasan_slab_free+0x10c/0x190 kmem_cache_free+0xed/0x380 rcu_core+0x3d5/0xc90 __do_softirq+0x12d/0x389
Last potentially related work creation: kasan_save_stack+0x1e/0x40 __kasan_record_aux_stack+0x97/0xb0 call_rcu+0x3d/0x3f0 erofs_shrink_workstation+0x11f/0x210 erofs_shrink_scan+0xdc/0x170 shrink_slab.constprop.0+0x296/0x530 drop_slab+0x1c/0x70 drop_caches_sysctl_handler+0x70/0x80 proc_sys_call_handler+0x20a/0x2f0 vfs_write+0x555/0x6c0 ksys_write+0xbe/0x160 do_syscall_64+0x3b/0x90
The root cause is that erofs_workgroup_unfreeze() doesn't reset to orig_val thus it causes a race that the pcluster reuses unexpectedly before freeing.
Since UP platforms are quite rare now, such path becomes unnecessary. Let's drop such specific-designed path directly instead.(CVE-2022-48674)
In the Linux kernel, the following vulnerability has been resolved:
usb: hub: Guard against accesses to uninitialized BOS descriptors
Many functions in drivers/usb/core/hub.c and drivers/usb/core/hub.h access fields inside udev->bos without checking if it was allocated and initialized. If usb_get_bos_descriptor() fails for whatever reason, udev->bos will be NULL and those accesses will result in a crash:
BUG: kernel NULL pointer dereference, address: 0000000000000018 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 5 PID: 17818 Comm: kworker/5:1 Tainted: G W 5.15.108-18910-gab0e1cb584e1 #1 <HASH:1f9e 1> Hardware name: Google Kindred/Kindred, BIOS Google_Kindred.12672.413.0 02/03/2021 Workqueue: usb_hub_wq hub_event RIP: 0010:hub_port_reset+0x193/0x788 Code: 89 f7 e8 20 f7 15 00 48 8b 43 08 80 b8 96 03 00 00 03 75 36 0f b7 88 92 03 00 00 81 f9 10 03 00 00 72 27 48 8b 80 a8 03 00 00 <48> 83 78 18 00 74 19 48 89 df 48 8b 75 b0 ba 02 00 00 00 4c 89 e9 RSP: 0018:ffffab740c53fcf8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffffa1bc5f678000 RCX: 0000000000000310 RDX: fffffffffffffdff RSI: 0000000000000286 RDI: ffffa1be9655b840 RBP: ffffab740c53fd70 R08: 00001b7d5edaa20c R09: ffffffffb005e060 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000 R13: ffffab740c53fd3e R14: 0000000000000032 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffffa1be96540000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000018 CR3: 000000022e80c005 CR4: 00000000003706e0 Call Trace: hub_event+0x73f/0x156e ? hub_activate+0x5b7/0x68f process_one_work+0x1a2/0x487 worker_thread+0x11a/0x288 kthread+0x13a/0x152 ? process_one_work+0x487/0x487 ? kthread_associate_blkcg+0x70/0x70 ret_from_fork+0x1f/0x30
Fall back to a default behavior if the BOS descriptor isn't accessible and skip all the functionalities that depend on it: LPM support checks, Super Speed capabilitiy checks, U1/U2 states setup.(CVE-2023-52477)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: disallow timeout for anonymous sets
Never used from userspace, disallow these parameters.(CVE-2023-52620)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nftables: exthdr: fix 4-byte stack OOB write
If priv->len is a multiple of 4, then dst[len / 4] can write past the destination array which leads to stack corruption.
This construct is necessary to clean the remainder of the register in case ->len is NOT a multiple of the register size, so make it conditional just like nft_payload.c does.
The bug was added in 4.1 cycle and then copied/inherited when tcp/sctp and ip option support was added.
Bug reported by Zero Day Initiative project (ZDI-CAN-21950, ZDI-CAN-21951, ZDI-CAN-21961).(CVE-2023-52628)
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Fix an NULL dereference bug
The issue here is when this is called from ntfs_load_attr_list(). The "size" comes from le32_to_cpu(attr->res.data_size) so it can't overflow on a 64bit systems but on 32bit systems the "+ 1023" can overflow and the result is zero. This means that the kmalloc will succeed by returning the ZERO_SIZE_PTR and then the memcpy() will crash with an Oops on the next line.(CVE-2023-52631)
In the Linux kernel, the following vulnerability has been resolved:
um: time-travel: fix time corruption
In 'basic' time-travel mode (without =inf-cpu or =ext), we still get timer interrupts. These can happen at arbitrary points in time, i.e. while in timer_read(), which pushes time forward just a little bit. Then, if we happen to get the interrupt after calculating the new time to push to, but before actually finishing that, the interrupt will set the time to a value that's incompatible with the forward, and we'll crash because time goes backwards when we do the forwarding.
Fix this by reading the time_travel_time, calculating the adjustment, and doing the adjustment all with interrupts disabled.(CVE-2023-52633)
In the Linux kernel, the following vulnerability has been resolved:
can: j1939: Fix UAF in j1939_sk_match_filter during setsockopt(SO_J1939_FILTER)
Lock jsk->sk to prevent UAF when setsockopt(..., SO_J1939_FILTER, ...) modifies jsk->filters while receiving packets.
Following trace was seen on affected system: ================================================================== BUG: KASAN: slab-use-after-free in j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939] Read of size 4 at addr ffff888012144014 by task j1939/350
CPU: 0 PID: 350 Comm: j1939 Tainted: G W OE 6.5.0-rc5 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Call Trace: print_report+0xd3/0x620 ? kasan_complete_mode_report_info+0x7d/0x200 ? j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939] kasan_report+0xc2/0x100 ? j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939] __asan_load4+0x84/0xb0 j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939] j1939_sk_recv+0x20b/0x320 [can_j1939] ? __kasan_check_write+0x18/0x20 ? __pfx_j1939_sk_recv+0x10/0x10 [can_j1939] ? j1939_simple_recv+0x69/0x280 [can_j1939] ? j1939_ac_recv+0x5e/0x310 [can_j1939] j1939_can_recv+0x43f/0x580 [can_j1939] ? __pfx_j1939_can_recv+0x10/0x10 [can_j1939] ? raw_rcv+0x42/0x3c0 [can_raw] ? __pfx_j1939_can_recv+0x10/0x10 [can_j1939] can_rcv_filter+0x11f/0x350 [can] can_receive+0x12f/0x190 [can] ? __pfx_can_rcv+0x10/0x10 [can] can_rcv+0xdd/0x130 [can] ? __pfx_can_rcv+0x10/0x10 [can] __netif_receive_skb_one_core+0x13d/0x150 ? __pfxnetifreceive_skb_one_core+0x10/0x10 ? kasan_check_write+0x18/0x20 ? _raw_spin_lock_irq+0x8c/0xe0 __netif_receive_skb+0x23/0xb0 process_backlog+0x107/0x260 __napi_poll+0x69/0x310 net_rx_action+0x2a1/0x580 ? __pfx_net_rx_action+0x10/0x10 ? __pfx__raw_spin_lock+0x10/0x10 ? handle_irq_event+0x7d/0xa0 __do_softirq+0xf3/0x3f8 do_softirq+0x53/0x80 </IRQ> <TASK> __local_bh_enable_ip+0x6e/0x70 netif_rx+0x16b/0x180 can_send+0x32b/0x520 [can] ? __pfx_can_send+0x10/0x10 [can] ? __check_object_size+0x299/0x410 raw_sendmsg+0x572/0x6d0 [can_raw] ? __pfx_raw_sendmsg+0x10/0x10 [can_raw] ? apparmor_socket_sendmsg+0x2f/0x40 ? __pfx_raw_sendmsg+0x10/0x10 [can_raw] sock_sendmsg+0xef/0x100 sock_write_iter+0x162/0x220 ? __pfx_sock_write_iter+0x10/0x10 ? __rtnl_unlock+0x47/0x80 ? security_file_permission+0x54/0x320 vfs_write+0x6ba/0x750 ? __pfx_vfs_write+0x10/0x10 ? __fget_light+0x1ca/0x1f0 ? __rcu_read_unlock+0x5b/0x280 ksys_write+0x143/0x170 ? __pfx_ksys_write+0x10/0x10 ? __kasan_check_read+0x15/0x20 ? fpregs_assert_state_consistent+0x62/0x70 __x64_sys_write+0x47/0x60 do_syscall_64+0x60/0x90 ? do_syscall_64+0x6d/0x90 ? irqentry_exit+0x3f/0x50 ? exc_page_fault+0x79/0xf0 entry_SYSCALL_64_after_hwframe+0x6e/0xd8
Allocated by task 348: kasan_save_stack+0x2a/0x50 kasan_set_track+0x29/0x40 kasan_save_alloc_info+0x1f/0x30 __kasan_kmalloc+0xb5/0xc0 __kmalloc_node_track_caller+0x67/0x160 j1939_sk_setsockopt+0x284/0x450 [can_j1939] __sys_setsockopt+0x15c/0x2f0 __x64_sys_setsockopt+0x6b/0x80 do_syscall_64+0x60/0x90 entry_SYSCALL_64_after_hwframe+0x6e/0xd8
Freed by task 349: kasan_save_stack+0x2a/0x50 kasan_set_track+0x29/0x40 kasan_save_free_info+0x2f/0x50 __kasan_slab_free+0x12e/0x1c0 __kmem_cache_free+0x1b9/0x380 kfree+0x7a/0x120 j1939_sk_setsockopt+0x3b2/0x450 [can_j1939] __sys_setsockopt+0x15c/0x2f0 __x64_sys_setsockopt+0x6b/0x80 do_syscall_64+0x60/0x90 entry_SYSCALL_64_after_hwframe+0x6e/0xd8(CVE-2023-52637)
In the Linux kernel, the following vulnerability has been resolved:
KVM: s390: vsie: fix race during shadow creation
Right now it is possible to see gmap->private being zero in kvm_s390_vsie_gmap_notifier resulting in a crash. This is due to the fact that we add gmap->private == kvm after creation:
static int acquire_gmap_shadow(struct kvm_vcpu vcpu, struct vsie_page vsie_page) { [...] gmap = gmap_shadow(vcpu->arch.gmap, asce, edat); if (IS_ERR(gmap)) return PTR_ERR(gmap); gmap->private = vcpu->kvm;
Let children inherit the private field of the parent.(CVE-2023-52639)
In the Linux kernel, the following vulnerability has been resolved:
media: rc: bpf attach/detach requires write permission
Note that bpf attach/detach also requires CAP_NET_ADMIN.(CVE-2023-52642)
In the Linux kernel, the following vulnerability has been resolved:
wifi: b43: Stop/wake correct queue in DMA Tx path when QoS is disabled
When QoS is disabled, the queue priority value will not map to the correct ieee80211 queue since there is only one queue. Stop/wake queue 0 when QoS is disabled to prevent trying to stop/wake a non-existent queue and failing to stop/wake the actual queue instantiated.
Log of issue before change (with kernel parameter qos=0): [ +5.112651] ------------[ cut here ]------------ [ +0.000005] WARNING: CPU: 7 PID: 25513 at net/mac80211/util.c:449 __ieee80211_wake_queue+0xd5/0x180 [mac80211] [ +0.000067] Modules linked in: b43(O) snd_seq_dummy snd_hrtimer snd_seq snd_seq_device nft_chain_nat xt_MASQUERADE nf_nat xfrm_user xfrm_algo xt_addrtype overlay ccm af_packet amdgpu snd_hda_codec_cirrus snd_hda_codec_generic ledtrig_audio drm_exec amdxcp gpu_sched xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip6t_rpfilter ipt_rpfilter xt_pkttype xt_LOG nf_log_syslog xt_tcpudp nft_compat nf_tables nfnetlink sch_fq_codel btusb uinput iTCO_wdt ctr btrtl intel_pmc_bxt i915 intel_rapl_msr mei_hdcp mei_pxp joydev at24 watchdog btintel atkbd libps2 serio radeon btbcm vivaldi_fmap btmtk intel_rapl_common snd_hda_codec_hdmi bluetooth uvcvideo nls_iso8859_1 applesmc nls_cp437 x86_pkg_temp_thermal snd_hda_intel intel_powerclamp vfat videobuf2_vmalloc coretemp fat snd_intel_dspcfg crc32_pclmul uvc polyval_clmulni snd_intel_sdw_acpi loop videobuf2_memops snd_hda_codec tun drm_suballoc_helper polyval_generic drm_ttm_helper drm_buddy tap ecdh_generic videobuf2_v4l2 gf128mul macvlan ttm ghash_clmulni_intel ecc tg3 [ +0.000044] videodev bridge snd_hda_core rapl crc16 drm_display_helper cec mousedev snd_hwdep evdev intel_cstate bcm5974 hid_appleir videobuf2_common stp mac_hid libphy snd_pcm drm_kms_helper acpi_als mei_me intel_uncore llc mc snd_timer intel_gtt industrialio_triggered_buffer apple_mfi_fastcharge i2c_i801 mei snd lpc_ich agpgart ptp i2c_smbus thunderbolt apple_gmux i2c_algo_bit kfifo_buf video industrialio soundcore pps_core wmi tiny_power_button sbs sbshc button ac cordic bcma mac80211 cfg80211 ssb rfkill libarc4 kvm_intel kvm drm irqbypass fuse backlight firmware_class efi_pstore configfs efivarfs dmi_sysfs ip_tables x_tables autofs4 dm_crypt cbc encrypted_keys trusted asn1_encoder tee tpm rng_core input_leds hid_apple led_class hid_generic usbhid hid sd_mod t10_pi crc64_rocksoft crc64 crc_t10dif crct10dif_generic ahci libahci libata uhci_hcd ehci_pci ehci_hcd crct10dif_pclmul crct10dif_common sha512_ssse3 sha512_generic sha256_ssse3 sha1_ssse3 aesni_intel usbcore scsi_mod libaes crypto_simd cryptd scsi_common [ +0.000055] usb_common rtc_cmos btrfs blake2b_generic libcrc32c crc32c_generic crc32c_intel xor raid6_pq dm_snapshot dm_bufio dm_mod dax [last unloaded: b43(O)] [ +0.000009] CPU: 7 PID: 25513 Comm: irq/17-b43 Tainted: G W O 6.6.7 #1-NixOS [ +0.000003] Hardware name: Apple Inc. MacBookPro8,3/Mac-942459F5819B171B, BIOS 87.0.0.0.0 06/13/2019 [ +0.000001] RIP: 0010:__ieee80211_wake_queue+0xd5/0x180 [mac80211] [ +0.000046] Code: 00 45 85 e4 0f 85 9b 00 00 00 48 8d bd 40 09 00 00 f0 48 0f ba ad 48 09 00 00 00 72 0f 5b 5d 41 5c 41 5d 41 5e e9 cb 6d 3c d0 <0f> 0b 5b 5d 41 5c 41 5d 41 5e c3 cc cc cc cc 48 8d b4 16 94 00 00 [ +0.000002] RSP: 0018:ffffc90003c77d60 EFLAGS: 00010097 [ +0.000001] RAX: 0000000000000001 RBX: 0000000000000002 RCX: 0000000000000000 [ +0.000001] RDX: 0000000000000000 RSI: 0000000000000002 RDI: ffff88820b924900 [ +0.000002] RBP: ffff88820b924900 R08: ffffc90003c77d90 R09: 000000000003bfd0 [ +0.000001] R10: ffff88820b924900 R11: ffffc90003c77c68 R12: 0000000000000000 [ +0.000001] R13: 0000000000000000 R14: ffffc90003c77d90 R15: ffffffffc0fa6f40 [ +0.000001] FS: 0000000000000000(0000) GS:ffff88846fb80000(0000) knlGS:0000000000000000 [ +0.000001] CS: 0010 DS: 0 ---truncated---(CVE-2023-52644)
A flaw was found in the ATA over Ethernet (AoE) driver in the Linux kernel. The aoecmd_cfg_pkts() function improperly updates the refcnt on struct net_device, and a use-after-free can be triggered by racing between the free on the struct and the access through the skbtxq global queue. This could lead to a denial of service condition or potential code execution.(CVE-2023-6270)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: disallow anonymous set with timeout flag
Anonymous sets are never used with timeout from userspace, reject this. Exception to this rule is NFT_SET_EVAL to ensure legacy meters still work.(CVE-2024-26642)
In the Linux kernel, the following vulnerability has been resolved:
tracing: Ensure visibility when inserting an element into tracing_map
Running the following two commands in parallel on a multi-processor AArch64 machine can sporadically produce an unexpected warning about duplicate histogram entries:
$ while true; do echo hist:key=id.syscall:val=hitcount > \ /sys/kernel/debug/tracing/events/raw_syscalls/sys_enter/trigger cat /sys/kernel/debug/tracing/events/raw_syscalls/sys_enter/hist sleep 0.001 done $ stress-ng --sysbadaddr $(nproc)
The warning looks as follows:
[ 2911.172474] ------------[ cut here ]------------ [ 2911.173111] Duplicates detected: 1 [ 2911.173574] WARNING: CPU: 2 PID: 12247 at kernel/trace/tracing_map.c:983 tracing_map_sort_entries+0x3e0/0x408 [ 2911.174702] Modules linked in: iscsi_ibft(E) iscsi_boot_sysfs(E) rfkill(E) af_packet(E) nls_iso8859_1(E) nls_cp437(E) vfat(E) fat(E) ena(E) tiny_power_button(E) qemu_fw_cfg(E) button(E) fuse(E) efi_pstore(E) ip_tables(E) x_tables(E) xfs(E) libcrc32c(E) aes_ce_blk(E) aes_ce_cipher(E) crct10dif_ce(E) polyval_ce(E) polyval_generic(E) ghash_ce(E) gf128mul(E) sm4_ce_gcm(E) sm4_ce_ccm(E) sm4_ce(E) sm4_ce_cipher(E) sm4(E) sm3_ce(E) sm3(E) sha3_ce(E) sha512_ce(E) sha512_arm64(E) sha2_ce(E) sha256_arm64(E) nvme(E) sha1_ce(E) nvme_core(E) nvme_auth(E) t10_pi(E) sg(E) scsi_mod(E) scsi_common(E) efivarfs(E) [ 2911.174738] Unloaded tainted modules: cppc_cpufreq(E):1 [ 2911.180985] CPU: 2 PID: 12247 Comm: cat Kdump: loaded Tainted: G E 6.7.0-default #2 1b58bbb22c97e4399dc09f92d309344f69c44a01 [ 2911.182398] Hardware name: Amazon EC2 c7g.8xlarge/, BIOS 1.0 11/1/2018 [ 2911.183208] pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 2911.184038] pc : tracing_map_sort_entries+0x3e0/0x408 [ 2911.184667] lr : tracing_map_sort_entries+0x3e0/0x408 [ 2911.185310] sp : ffff8000a1513900 [ 2911.185750] x29: ffff8000a1513900 x28: ffff0003f272fe80 x27: 0000000000000001 [ 2911.186600] x26: ffff0003f272fe80 x25: 0000000000000030 x24: 0000000000000008 [ 2911.187458] x23: ffff0003c5788000 x22: ffff0003c16710c8 x21: ffff80008017f180 [ 2911.188310] x20: ffff80008017f000 x19: ffff80008017f180 x18: ffffffffffffffff [ 2911.189160] x17: 0000000000000000 x16: 0000000000000000 x15: ffff8000a15134b8 [ 2911.190015] x14: 0000000000000000 x13: 205d373432323154 x12: 5b5d313131333731 [ 2911.190844] x11: 00000000fffeffff x10: 00000000fffeffff x9 : ffffd1b78274a13c [ 2911.191716] x8 : 000000000017ffe8 x7 : c0000000fffeffff x6 : 000000000057ffa8 [ 2911.192554] x5 : ffff0012f6c24ec0 x4 : 0000000000000000 x3 : ffff2e5b72b5d000 [ 2911.193404] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0003ff254480 [ 2911.194259] Call trace: [ 2911.194626] tracing_map_sort_entries+0x3e0/0x408 [ 2911.195220] hist_show+0x124/0x800 [ 2911.195692] seq_read_iter+0x1d4/0x4e8 [ 2911.196193] seq_read+0xe8/0x138 [ 2911.196638] vfs_read+0xc8/0x300 [ 2911.197078] ksys_read+0x70/0x108 [ 2911.197534] __arm64_sys_read+0x24/0x38 [ 2911.198046] invoke_syscall+0x78/0x108 [ 2911.198553] el0_svc_common.constprop.0+0xd0/0xf8 [ 2911.199157] do_el0_svc+0x28/0x40 [ 2911.199613] el0_svc+0x40/0x178 [ 2911.200048] el0t_64_sync_handler+0x13c/0x158 [ 2911.200621] el0t_64_sync+0x1a8/0x1b0 [ 2911.201115] ---[ end trace 0000000000000000 ]---
The problem appears to be caused by CPU reordering of writes issued from __tracing_map_insert().
The check for the presence of an element with a given key in this function is:
val = READ_ONCE(entry->val); if (val && keys_match(key, val->key, map->key_size)) ...
The write of a new entry is:
elt = get_free_elt(map); memcpy(elt->key, key, map->key_size); entry->val = elt;
The "memcpy(elt->key, key, map->key_size);" and "entry->val = elt;" stores may become visible in the reversed order on another CPU. This second CPU might then incorrectly determine that a new key doesn't match an already present val->key and subse ---truncated---(CVE-2024-26645)
In the Linux kernel, the following vulnerability has been resolved:
tunnels: fix out of bounds access when building IPv6 PMTU error
If the ICMPv6 error is built from a non-linear skb we get the following splat,
BUG: KASAN: slab-out-of-bounds in do_csum+0x220/0x240 Read of size 4 at addr ffff88811d402c80 by task netperf/820 CPU: 0 PID: 820 Comm: netperf Not tainted 6.8.0-rc1+ #543 ... kasan_report+0xd8/0x110 do_csum+0x220/0x240 csum_partial+0xc/0x20 skb_tunnel_check_pmtu+0xeb9/0x3280 vxlan_xmit_one+0x14c2/0x4080 vxlan_xmit+0xf61/0x5c00 dev_hard_start_xmit+0xfb/0x510 __dev_queue_xmit+0x7cd/0x32a0 br_dev_queue_push_xmit+0x39d/0x6a0
Use skb_checksum instead of csum_partial who cannot deal with non-linear SKBs.(CVE-2024-26665)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nft_limit: reject configurations that cause integer overflow
Reject bogus configs where internal token counter wraps around. This only occurs with very very large requests, such as 17gbyte/s.
Its better to reject this rather than having incorrect ratelimit.(CVE-2024-26668)
In the Linux kernel, the following vulnerability has been resolved:
net/sched: flower: Fix chain template offload
When a qdisc is deleted from a net device the stack instructs the underlying driver to remove its flow offload callback from the associated filter block using the 'FLOW_BLOCK_UNBIND' command. The stack then continues to replay the removal of the filters in the block for this driver by iterating over the chains in the block and invoking the 'reoffload' operation of the classifier being used. In turn, the classifier in its 'reoffload' operation prepares and emits a 'FLOW_CLS_DESTROY' command for each filter.
However, the stack does not do the same for chain templates and the underlying driver never receives a 'FLOW_CLS_TMPLT_DESTROY' command when a qdisc is deleted. This results in a memory leak [1] which can be reproduced using [2].
Fix by introducing a 'tmplt_reoffload' operation and have the stack invoke it with the appropriate arguments as part of the replay. Implement the operation in the sole classifier that supports chain templates (flower) by emitting the 'FLOW_CLS_TMPLT_{CREATE,DESTROY}' command based on whether a flow offload callback is being bound to a filter block or being unbound from one.
As far as I can tell, the issue happens since cited commit which reordered tcf_block_offload_unbind() before tcf_block_flush_all_chains() in __tcf_block_put(). The order cannot be reversed as the filter block is expected to be freed after flushing all the chains.
[1] unreferenced object 0xffff888107e28800 (size 2048): comm "tc", pid 1079, jiffies 4294958525 (age 3074.287s) hex dump (first 32 bytes): b1 a6 7c 11 81 88 ff ff e0 5b b3 10 81 88 ff ff ..|......[...... 01 00 00 00 00 00 00 00 e0 aa b0 84 ff ff ff ff ................ backtrace: [<ffffffff81c06a68>] __kmem_cache_alloc_node+0x1e8/0x320 [<ffffffff81ab374e>] __kmalloc+0x4e/0x90 [<ffffffff832aec6d>] mlxsw_sp_acl_ruleset_get+0x34d/0x7a0 [<ffffffff832bc195>] mlxsw_sp_flower_tmplt_create+0x145/0x180 [<ffffffff832b2e1a>] mlxsw_sp_flow_block_cb+0x1ea/0x280 [<ffffffff83a10613>] tc_setup_cb_call+0x183/0x340 [<ffffffff83a9f85a>] fl_tmplt_create+0x3da/0x4c0 [<ffffffff83a22435>] tc_ctl_chain+0xa15/0x1170 [<ffffffff838a863c>] rtnetlink_rcv_msg+0x3cc/0xed0 [<ffffffff83ac87f0>] netlink_rcv_skb+0x170/0x440 [<ffffffff83ac6270>] netlink_unicast+0x540/0x820 [<ffffffff83ac6e28>] netlink_sendmsg+0x8d8/0xda0 [<ffffffff83793def>] _syssendmsg+0x30f/0xa80 [<ffffffff8379d29a>] _sys_sendmsg+0x13a/0x1e0 [<ffffffff8379d50c>] __sys_sendmsg+0x11c/0x1f0 [<ffffffff843b9ce0>] do_syscall_64+0x40/0xe0 unreferenced object 0xffff88816d2c0400 (size 1024): comm "tc", pid 1079, jiffies 4294958525 (age 3074.287s) hex dump (first 32 bytes): 40 00 00 00 00 00 00 00 57 f6 38 be 00 00 00 00 @.......W.8..... 10 04 2c 6d 81 88 ff ff 10 04 2c 6d 81 88 ff ff ..,m......,m.... backtrace: [<ffffffff81c06a68>] __kmem_cache_alloc_node+0x1e8/0x320 [<ffffffff81ab36c1>] __kmalloc_node+0x51/0x90 [<ffffffff81a8ed96>] kvmalloc_node+0xa6/0x1f0 [<ffffffff82827d03>] bucket_table_alloc.isra.0+0x83/0x460 [<ffffffff82828d2b>] rhashtable_init+0x43b/0x7c0 [<ffffffff832aed48>] mlxsw_sp_acl_ruleset_get+0x428/0x7a0 [<ffffffff832bc195>] mlxsw_sp_flower_tmplt_create+0x145/0x180 [<ffffffff832b2e1a>] mlxsw_sp_flow_block_cb+0x1ea/0x280 [<ffffffff83a10613>] tc_setup_cb_call+0x183/0x340 [<ffffffff83a9f85a>] fl_tmplt_create+0x3da/0x4c0 [<ffffffff83a22435>] tc_ctl_chain+0xa15/0x1170 [<ffffffff838a863c>] rtnetlink_rcv_msg+0x3cc/0xed0 [<ffffffff83ac87f0>] netlink_rcv_skb+0x170/0x440 [<ffffffff83ac6270>] netlink_unicast+0x540/0x820 [<ffffffff83ac6e28>] netlink_sendmsg+0x8d8/0xda0 [<ffffffff83793def>] ____sys_sendmsg+0x30f/0xa80
[2] # tc qdisc add dev swp1 clsact # tc chain add dev swp1 ingress proto ip chain 1 flower dst_ip 0.0.0.0/32 # tc qdisc del dev ---truncated---(CVE-2024-26669)
In the Linux kernel, the following vulnerability has been resolved:
blk-mq: fix IO hang from sbitmap wakeup race
In blk_mq_mark_tag_wait(), __add_wait_queue() may be re-ordered with the following blk_mq_get_driver_tag() in case of getting driver tag failure.
Then in __sbitmap_queue_wake_up(), waitqueue_active() may not observe the added waiter in blk_mq_mark_tag_wait() and wake up nothing, meantime blk_mq_mark_tag_wait() can't get driver tag successfully.
This issue can be reproduced by running the following test in loop, and fio hang can be observed in < 30min when running it on my test VM in laptop.
modprobe -r scsi_debug
modprobe scsi_debug delay=0 dev_size_mb=4096 max_queue=1 host_max_queue=1 submit_queues=4
dev=`ls -d /sys/bus/pseudo/drivers/scsi_debug/adapter*/host*/target*/*/block/* | head -1 | xargs basename`
fio --filename=/dev/"$dev" --direct=1 --rw=randrw --bs=4k --iodepth=1 \
--runtime=100 --numjobs=40 --time_based --name=test \
--ioengine=libaio
Fix the issue by adding one explicit barrier in blk_mq_mark_tag_wait(), which is just fine in case of running out of tag.(CVE-2024-26671)
In the Linux kernel, the following vulnerability has been resolved:
inet: read sk->sk_family once in inet_recv_error()
inet_recv_error() is called without holding the socket lock.
IPv6 socket could mutate to IPv4 with IPV6_ADDRFORM socket option and trigger a KCSAN warning.(CVE-2024-26679)
In the Linux kernel, the following vulnerability has been resolved:
net: atlantic: Fix DMA mapping for PTP hwts ring
Function aq_ring_hwts_rx_alloc() maps extra AQ_CFG_RXDS_DEF bytes for PTP HWTS ring but then generic aq_ring_free() does not take this into account. Create and use a specific function to free HWTS ring to fix this issue.
Trace: [ 215.351607] ------------[ cut here ]------------ [ 215.351612] DMA-API: atlantic 0000:4b:00.0: device driver frees DMA memory with different size [device address=0x00000000fbdd0000] [map size=34816 bytes] [unmap size=32768 bytes] [ 215.351635] WARNING: CPU: 33 PID: 10759 at kernel/dma/debug.c:988 check_unmap+0xa6f/0x2360 ... [ 215.581176] Call Trace: [ 215.583632] <TASK> [ 215.585745] ? show_trace_log_lvl+0x1c4/0x2df [ 215.590114] ? show_trace_log_lvl+0x1c4/0x2df [ 215.594497] ? debug_dma_free_coherent+0x196/0x210 [ 215.599305] ? check_unmap+0xa6f/0x2360 [ 215.603147] ? __warn+0xca/0x1d0 [ 215.606391] ? check_unmap+0xa6f/0x2360 [ 215.610237] ? report_bug+0x1ef/0x370 [ 215.613921] ? handle_bug+0x3c/0x70 [ 215.617423] ? exc_invalid_op+0x14/0x50 [ 215.621269] ? asm_exc_invalid_op+0x16/0x20 [ 215.625480] ? check_unmap+0xa6f/0x2360 [ 215.629331] ? mark_lock.part.0+0xca/0xa40 [ 215.633445] debug_dma_free_coherent+0x196/0x210 [ 215.638079] ? __pfx_debug_dma_free_coherent+0x10/0x10 [ 215.643242] ? slab_free_freelist_hook+0x11d/0x1d0 [ 215.648060] dma_free_attrs+0x6d/0x130 [ 215.651834] aq_ring_free+0x193/0x290 [atlantic] [ 215.656487] aq_ptp_ring_free+0x67/0x110 [atlantic] ... [ 216.127540] ---[ end trace 6467e5964dd2640b ]--- [ 216.132160] DMA-API: Mapped at: [ 216.132162] debug_dma_alloc_coherent+0x66/0x2f0 [ 216.132165] dma_alloc_attrs+0xf5/0x1b0 [ 216.132168] aq_ring_hwts_rx_alloc+0x150/0x1f0 [atlantic] [ 216.132193] aq_ptp_ring_alloc+0x1bb/0x540 [atlantic] [ 216.132213] aq_nic_init+0x4a1/0x760 atlantic
In the Linux kernel, the following vulnerability has been resolved:
net: stmmac: xgmac: fix handling of DPP safety error for DMA channels
Commit 56e58d6c8a56 ("net: stmmac: Implement Safety Features in XGMAC core") checks and reports safety errors, but leaves the Data Path Parity Errors for each channel in DMA unhandled at all, lead to a storm of interrupt. Fix it by checking and clearing the DMA_DPP_Interrupt_Status register.(CVE-2024-26684)
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix potential bug in end_buffer_async_write
According to a syzbot report, end_buffer_async_write(), which handles the completion of block device writes, may detect abnormal condition of the buffer async_write flag and cause a BUG_ON failure when using nilfs2.
Nilfs2 itself does not use end_buffer_async_write(). But, the async_write flag is now used as a marker by commit 7f42ec394156 ("nilfs2: fix issue with race condition of competition between segments for dirty blocks") as a means of resolving double list insertion of dirty blocks in nilfs_lookup_dirty_data_buffers() and nilfs_lookup_node_buffers() and the resulting crash.
This modification is safe as long as it is used for file data and b-tree node blocks where the page caches are independent. However, it was irrelevant and redundant to also introduce async_write for segment summary and super root blocks that share buffers with the backing device. This led to the possibility that the BUG_ON check in end_buffer_async_write would fail as described above, if independent writebacks of the backing device occurred in parallel.
The use of async_write for segment summary buffers has already been removed in a previous change.
Fix this issue by removing the manipulation of the async_write flag for the remaining super root block buffer.(CVE-2024-26685)
In the Linux kernel, the following vulnerability has been resolved:
fs,hugetlb: fix NULL pointer dereference in hugetlbs_fill_super
When configuring a hugetlb filesystem via the fsconfig() syscall, there is a possible NULL dereference in hugetlbfs_fill_super() caused by assigning NULL to ctx->hstate in hugetlbfs_parse_param() when the requested pagesize is non valid.
E.g: Taking the following steps:
fd = fsopen("hugetlbfs", FSOPEN_CLOEXEC);
fsconfig(fd, FSCONFIG_SET_STRING, "pagesize", "1024", 0);
fsconfig(fd, FSCONFIG_CMD_CREATE, NULL, NULL, 0);
Given that the requested "pagesize" is invalid, ctxt->hstate will be replaced with NULL, losing its previous value, and we will print an error:
... ... case Opt_pagesize: ps = memparse(param->string, &rest); ctx->hstate = h; if (!ctx->hstate) { pr_err("Unsupported page size %lu MB\n", ps / SZ_1M); return -EINVAL; } return 0; ... ...
This is a problem because later on, we will dereference ctxt->hstate in hugetlbfs_fill_super()
... ... sb->s_blocksize = huge_page_size(ctx->hstate); ... ...
Causing below Oops.
Fix this by replacing cxt->hstate value only when then pagesize is known to be valid.
kernel: hugetlbfs: Unsupported page size 0 MB kernel: BUG: kernel NULL pointer dereference, address: 0000000000000028 kernel: #PF: supervisor read access in kernel mode kernel: #PF: error_code(0x0000) - not-present page kernel: PGD 800000010f66c067 P4D 800000010f66c067 PUD 1b22f8067 PMD 0 kernel: Oops: 0000 [#1] PREEMPT SMP PTI kernel: CPU: 4 PID: 5659 Comm: syscall Tainted: G E 6.8.0-rc2-default+ #22 5a47c3fef76212addcc6eb71344aabc35190ae8f kernel: Hardware name: Intel Corp. GROVEPORT/GROVEPORT, BIOS GVPRCRB1.86B.0016.D04.1705030402 05/03/2017 kernel: RIP: 0010:hugetlbfs_fill_super+0xb4/0x1a0 kernel: Code: 48 8b 3b e8 3e c6 ed ff 48 85 c0 48 89 45 20 0f 84 d6 00 00 00 48 b8 ff ff ff ff ff ff ff 7f 4c 89 e7 49 89 44 24 20 48 8b 03 <8b> 48 28 b8 00 10 00 00 48 d3 e0 49 89 44 24 18 48 8b 03 8b 40 28 kernel: RSP: 0018:ffffbe9960fcbd48 EFLAGS: 00010246 kernel: RAX: 0000000000000000 RBX: ffff9af5272ae780 RCX: 0000000000372004 kernel: RDX: ffffffffffffffff RSI: ffffffffffffffff RDI: ffff9af555e9b000 kernel: RBP: ffff9af52ee66b00 R08: 0000000000000040 R09: 0000000000370004 kernel: R10: ffffbe9960fcbd48 R11: 0000000000000040 R12: ffff9af555e9b000 kernel: R13: ffffffffa66b86c0 R14: ffff9af507d2f400 R15: ffff9af507d2f400 kernel: FS: 00007ffbc0ba4740(0000) GS:ffff9b0bd7000000(0000) knlGS:0000000000000000 kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 kernel: CR2: 0000000000000028 CR3: 00000001b1ee0000 CR4: 00000000001506f0 kernel: Call Trace: kernel: <TASK> kernel: ? __die_body+0x1a/0x60 kernel: ? page_fault_oops+0x16f/0x4a0 kernel: ? search_bpf_extables+0x65/0x70 kernel: ? fixup_exception+0x22/0x310 kernel: ? exc_page_fault+0x69/0x150 kernel: ? asm_exc_page_fault+0x22/0x30 kernel: ? __pfx_hugetlbfs_fill_super+0x10/0x10 kernel: ? hugetlbfs_fill_super+0xb4/0x1a0 kernel: ? hugetlbfs_fill_super+0x28/0x1a0 kernel: ? __pfx_hugetlbfs_fill_super+0x10/0x10 kernel: vfs_get_super+0x40/0xa0 kernel: ? __pfx_bpf_lsm_capable+0x10/0x10 kernel: vfs_get_tree+0x25/0xd0 kernel: vfs_cmd_create+0x64/0xe0 kernel: __x64_sys_fsconfig+0x395/0x410 kernel: do_syscall_64+0x80/0x160 kernel: ? syscall_exit_to_user_mode+0x82/0x240 kernel: ? do_syscall_64+0x8d/0x160 kernel: ? syscall_exit_to_user_mode+0x82/0x240 kernel: ? do_syscall_64+0x8d/0x160 kernel: ? exc_page_fault+0x69/0x150 kernel: entry_SYSCALL_64_after_hwframe+0x6e/0x76 kernel: RIP: 0033:0x7ffbc0cb87c9 kernel: Code: 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 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 8b 0d 97 96 0d 00 f7 d8 64 89 01 48 kernel: RSP: 002b:00007ffc29d2f388 EFLAGS: 00000206 ORIG_RAX: 00000000000001af kernel: RAX: fffffffffff ---truncated---(CVE-2024-26688)
In the Linux kernel, the following vulnerability has been resolved:
ceph: prevent use-after-free in encode_cap_msg()
In fs/ceph/caps.c, in encode_cap_msg(), "use after free" error was caught by KASAN at this line - 'ceph_buffer_get(arg->xattr_buf);'. This implies before the refcount could be increment here, it was freed.
In same file, in "handle_cap_grant()" refcount is decremented by this line - 'ceph_buffer_put(ci->i_xattrs.blob);'. It appears that a race occurred and resource was freed by the latter line before the former line could increment it.
encode_cap_msg() is called by __send_cap() and __send_cap() is called by ceph_check_caps() after calling __prep_cap(). __prep_cap() is where arg->xattr_buf is assigned to ci->i_xattrs.blob. This is the spot where the refcount must be increased to prevent "use after free" error.(CVE-2024-26689)
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix data corruption in dsync block recovery for small block sizes
The helper function nilfs_recovery_copy_block() of nilfs_recovery_dsync_blocks(), which recovers data from logs created by data sync writes during a mount after an unclean shutdown, incorrectly calculates the on-page offset when copying repair data to the file's page cache. In environments where the block size is smaller than the page size, this flaw can cause data corruption and leak uninitialized memory bytes during the recovery process.
Fix these issues by correcting this byte offset calculation on the page.(CVE-2024-26697)
In the Linux kernel, the following vulnerability has been resolved:
parisc: Fix random data corruption from exception handler
The current exception handler implementation, which assists when accessing user space memory, may exhibit random data corruption if the compiler decides to use a different register than the specified register %r29 (defined in ASM_EXCEPTIONTABLE_REG) for the error code. If the compiler choose another register, the fault handler will nevertheless store -EFAULT into %r29 and thus trash whatever this register is used for. Looking at the assembly I found that this happens sometimes in emulate_ldd().
To solve the issue, the easiest solution would be if it somehow is possible to tell the fault handler which register is used to hold the error code. Using %0 or %1 in the inline assembly is not posssible as it will show up as e.g. %r29 (with the "%r" prefix), which the GNU assembler can not convert to an integer.
This patch takes another, better and more flexible approach: We extend the __ex_table (which is out of the execution path) by one 32-word. In this word we tell the compiler to insert the assembler instruction "or %r0,%r0,%reg", where %reg references the register which the compiler choosed for the error return code. In case of an access failure, the fault handler finds the __ex_table entry and can examine the opcode. The used register is encoded in the lowest 5 bits, and the fault handler can then store -EFAULT into this register.
Since we extend the __ex_table to 3 words we can't use the BUILDTIME_TABLE_SORT config option any longer.(CVE-2024-26706)
In the Linux kernel, the following vulnerability has been resolved:
net: hsr: remove WARN_ONCE() in send_hsr_supervision_frame()
Syzkaller reported [1] hitting a warning after failing to allocate resources for skb in hsr_init_skb(). Since a WARN_ONCE() call will not help much in this case, it might be prudent to switch to netdev_warn_once(). At the very least it will suppress syzkaller reports such as [1].
Just in case, use netdev_warn_once() in send_prp_supervision_frame() for similar reasons.
[1] HSR: Could not send supervision frame WARNING: CPU: 1 PID: 85 at net/hsr/hsr_device.c:294 send_hsr_supervision_frame+0x60a/0x810 net/hsr/hsr_device.c:294 RIP: 0010:send_hsr_supervision_frame+0x60a/0x810 net/hsr/hsr_device.c:294 ... Call Trace: <IRQ> hsr_announce+0x114/0x370 net/hsr/hsr_device.c:382 call_timer_fn+0x193/0x590 kernel/time/timer.c:1700 expire_timers kernel/time/timer.c:1751 [inline] __run_timers+0x764/0xb20 kernel/time/timer.c:2022 run_timer_softirq+0x58/0xd0 kernel/time/timer.c:2035 __do_softirq+0x21a/0x8de kernel/softirq.c:553 invoke_softirq kernel/softirq.c:427 [inline] __irq_exit_rcu kernel/softirq.c:632 [inline] irq_exit_rcu+0xb7/0x120 kernel/softirq.c:644 sysvec_apic_timer_interrupt+0x95/0xb0 arch/x86/kernel/apic/apic.c:1076 </IRQ> <TASK> asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:649 ...
This issue is also found in older kernels (at least up to 5.10).(CVE-2024-26707)
In the Linux kernel, the following vulnerability has been resolved:
mm/writeback: fix possible divide-by-zero in wb_dirty_limits(), again
(struct dirty_throttle_control *)->thresh is an unsigned long, but is passed as the u32 divisor argument to div_u64(). On architectures where unsigned long is 64 bytes, the argument will be implicitly truncated.
Use div64_u64() instead of div_u64() so that the value used in the "is this a safe division" check is the same as the divisor.
Also, remove redundant cast of the numerator to u64, as that should happen implicitly.
This would be difficult to exploit in memcg domain, given the ratio-based arithmetic domain_drity_limits() uses, but is much easier in global writeback domain with a BDI_CAP_STRICTLIMIT-backing device, using e.g. vm.dirty_bytes=(1<<32)*PAGE_SIZE so that dtc->thresh == (1<<32)(CVE-2024-26720)
In the Linux kernel, the following vulnerability has been resolved:
btrfs: don't drop extent_map for free space inode on write error
While running the CI for an unrelated change I hit the following panic with generic/648 on btrfs_holes_spacecache.
assertion failed: block_start != EXTENT_MAP_HOLE, in fs/btrfs/extent_io.c:1385 ------------[ cut here ]------------ kernel BUG at fs/btrfs/extent_io.c:1385! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 2695096 Comm: fsstress Kdump: loaded Tainted: G W 6.8.0-rc2+ #1 RIP: 0010:__extent_writepage_io.constprop.0+0x4c1/0x5c0 Call Trace: <TASK> extent_write_cache_pages+0x2ac/0x8f0 extent_writepages+0x87/0x110 do_writepages+0xd5/0x1f0 filemap_fdatawrite_wbc+0x63/0x90 __filemap_fdatawrite_range+0x5c/0x80 btrfs_fdatawrite_range+0x1f/0x50 btrfs_write_out_cache+0x507/0x560 btrfs_write_dirty_block_groups+0x32a/0x420 commit_cowonly_roots+0x21b/0x290 btrfs_commit_transaction+0x813/0x1360 btrfs_sync_file+0x51a/0x640 __x64_sys_fdatasync+0x52/0x90 do_syscall_64+0x9c/0x190 entry_SYSCALL_64_after_hwframe+0x6e/0x76
This happens because we fail to write out the free space cache in one instance, come back around and attempt to write it again. However on the second pass through we go to call btrfs_get_extent() on the inode to get the extent mapping. Because this is a new block group, and with the free space inode we always search the commit root to avoid deadlocking with the tree, we find nothing and return a EXTENT_MAP_HOLE for the requested range.
This happens because the first time we try to write the space cache out we hit an error, and on an error we drop the extent mapping. This is normal for normal files, but the free space cache inode is special. We always expect the extent map to be correct. Thus the second time through we end up with a bogus extent map.
Since we're deprecating this feature, the most straightforward way to fix this is to simply skip dropping the extent map range for this failed range.
I shortened the test by using error injection to stress the area to make it easier to reproduce. With this patch in place we no longer panic with my error injection test.(CVE-2024-26726)
In the Linux kernel, the following vulnerability has been resolved:
arp: Prevent overflow in arp_req_get().
syzkaller reported an overflown write in arp_req_get(). [0]
When ioctl(SIOCGARP) is issued, arp_req_get() looks up an neighbour entry and copies neigh->ha to struct arpreq.arp_ha.sa_data.
The arp_ha here is struct sockaddr, not struct sockaddr_storage, so the sa_data buffer is just 14 bytes.
In the splat below, 2 bytes are overflown to the next int field, arp_flags. We initialise the field just after the memcpy(), so it's not a problem.
However, when dev->addr_len is greater than 22 (e.g. MAX_ADDR_LEN), arp_netmask is overwritten, which could be set as htonl(0xFFFFFFFFUL) in arp_ioctl() before calling arp_req_get().
To avoid the overflow, let's limit the max length of memcpy().
Note that commit b5f0de6df6dc ("net: dev: Convert sa_data to flexible array in struct sockaddr") just silenced syzkaller.
[0]: memcpy: detected field-spanning write (size 16) of single field "r->arp_ha.sa_data" at net/ipv4/arp.c:1128 (size 14) WARNING: CPU: 0 PID: 144638 at net/ipv4/arp.c:1128 arp_req_get+0x411/0x4a0 net/ipv4/arp.c:1128 Modules linked in: CPU: 0 PID: 144638 Comm: syz-executor.4 Not tainted 6.1.74 #31 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-debian-1.16.0-5 04/01/2014 RIP: 0010:arp_req_get+0x411/0x4a0 net/ipv4/arp.c:1128 Code: fd ff ff e8 41 42 de fb b9 0e 00 00 00 4c 89 fe 48 c7 c2 20 6d ab 87 48 c7 c7 80 6d ab 87 c6 05 25 af 72 04 01 e8 5f 8d ad fb <0f> 0b e9 6c fd ff ff e8 13 42 de fb be 03 00 00 00 4c 89 e7 e8 a6 RSP: 0018:ffffc900050b7998 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff88803a815000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff8641a44a RDI: 0000000000000001 RBP: ffffc900050b7a98 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 203a7970636d656d R12: ffff888039c54000 R13: 1ffff92000a16f37 R14: ffff88803a815084 R15: 0000000000000010 FS: 00007f172bf306c0(0000) GS:ffff88805aa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f172b3569f0 CR3: 0000000057f12005 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> arp_ioctl+0x33f/0x4b0 net/ipv4/arp.c:1261 inet_ioctl+0x314/0x3a0 net/ipv4/af_inet.c:981 sock_do_ioctl+0xdf/0x260 net/socket.c:1204 sock_ioctl+0x3ef/0x650 net/socket.c:1321 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl fs/ioctl.c:856 [inline] __x64_sys_ioctl+0x18e/0x220 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x37/0x90 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x64/0xce RIP: 0033:0x7f172b262b8d Code: 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f172bf300b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007f172b3abf80 RCX: 00007f172b262b8d RDX: 0000000020000000 RSI: 0000000000008954 RDI: 0000000000000003 RBP: 00007f172b2d3493 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 000000000000000b R14: 00007f172b3abf80 R15: 00007f172bf10000 </TASK>(CVE-2024-26733)
In the Linux kernel, the following vulnerability has been resolved:
devlink: fix possible use-after-free and memory leaks in devlink_init()
The pernet operations structure for the subsystem must be registered before registering the generic netlink family.
Make an unregister in case of unsuccessful registration.(CVE-2024-26734)
In the Linux kernel, the following vulnerability has been resolved:
ipv6: sr: fix possible use-after-free and null-ptr-deref
The pernet operations structure for the subsystem must be registered before registering the generic netlink family.(CVE-2024-26735)
In the Linux kernel, the following vulnerability has been resolved:
net/sched: act_mirred: don't override retval if we already lost the skb
If we're redirecting the skb, and haven't called tcf_mirred_forward(), yet, we need to tell the core to drop the skb by setting the retcode to SHOT. If we have called tcf_mirred_forward(), however, the skb is out of our hands and returning SHOT will lead to UaF.
Move the retval override to the error path which actually need it.(CVE-2024-26739)
In the Linux kernel, the following vulnerability has been resolved:
net/sched: act_mirred: use the backlog for mirred ingress
The test Davide added in commit ca22da2fbd69 ("act_mirred: use the backlog for nested calls to mirred ingress") hangs our testing VMs every 10 or so runs, with the familiar tcp_v4_rcv -> tcp_v4_rcv deadlock reported by lockdep.
The problem as previously described by Davide (see Link) is that if we reverse flow of traffic with the redirect (egress -> ingress) we may reach the same socket which generated the packet. And we may still be holding its socket lock. The common solution to such deadlocks is to put the packet in the Rx backlog, rather than run the Rx path inline. Do that for all egress -> ingress reversals, not just once we started to nest mirred calls.
In the past there was a concern that the backlog indirection will lead to loss of error reporting / less accurate stats. But the current workaround does not seem to address the issue.(CVE-2024-26740)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/qedr: Fix qedr_create_user_qp error flow
Avoid the following warning by making sure to free the allocated resources in case that qedr_init_user_queue() fail.
-----------[ cut here ]----------- WARNING: CPU: 0 PID: 143192 at drivers/infiniband/core/rdma_core.c:874 uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs] Modules linked in: tls target_core_user uio target_core_pscsi target_core_file target_core_iblock ib_srpt ib_srp scsi_transport_srp nfsd nfs_acl rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs 8021q garp mrp stp llc ext4 mbcache jbd2 opa_vnic ib_umad ib_ipoib sunrpc rdma_ucm ib_isert iscsi_target_mod target_core_mod ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_cm hfi1 intel_rapl_msr intel_rapl_common mgag200 qedr sb_edac drm_shmem_helper rdmavt x86_pkg_temp_thermal drm_kms_helper intel_powerclamp ib_uverbs coretemp i2c_algo_bit kvm_intel dell_wmi_descriptor ipmi_ssif sparse_keymap kvm ib_core rfkill syscopyarea sysfillrect video sysimgblt irqbypass ipmi_si ipmi_devintf fb_sys_fops rapl iTCO_wdt mxm_wmi iTCO_vendor_support intel_cstate pcspkr dcdbas intel_uncore ipmi_msghandler lpc_ich acpi_power_meter mei_me mei fuse drm xfs libcrc32c qede sd_mod ahci libahci t10_pi sg crct10dif_pclmul crc32_pclmul crc32c_intel qed libata tg3 ghash_clmulni_intel megaraid_sas crc8 wmi [last unloaded: ib_srpt] CPU: 0 PID: 143192 Comm: fi_rdm_tagged_p Kdump: loaded Not tainted 5.14.0-408.el9.x86_64 #1 Hardware name: Dell Inc. PowerEdge R430/03XKDV, BIOS 2.14.0 01/25/2022 RIP: 0010:uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs] Code: 5d 41 5c 41 5d 41 5e e9 0f 26 1b dd 48 89 df e8 67 6a ff ff 49 8b 86 10 01 00 00 48 85 c0 74 9c 4c 89 e7 e8 83 c0 cb dd eb 92 <0f> 0b eb be 0f 0b be 04 00 00 00 48 89 df e8 8e f5 ff ff e9 6d ff RSP: 0018:ffffb7c6cadfbc60 EFLAGS: 00010286 RAX: ffff8f0889ee3f60 RBX: ffff8f088c1a5200 RCX: 00000000802a0016 RDX: 00000000802a0017 RSI: 0000000000000001 RDI: ffff8f0880042600 RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000 R10: ffff8f11fffd5000 R11: 0000000000039000 R12: ffff8f0d5b36cd80 R13: ffff8f088c1a5250 R14: ffff8f1206d91000 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff8f11d7c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000147069200e20 CR3: 00000001c7210002 CR4: 00000000001706f0 Call Trace: <TASK> ? show_trace_log_lvl+0x1c4/0x2df ? show_trace_log_lvl+0x1c4/0x2df ? ib_uverbs_close+0x1f/0xb0 [ib_uverbs] ? uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs] ? __warn+0x81/0x110 ? uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs] ? report_bug+0x10a/0x140 ? handle_bug+0x3c/0x70 ? exc_invalid_op+0x14/0x70 ? asm_exc_invalid_op+0x16/0x20 ? uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs] ib_uverbs_close+0x1f/0xb0 [ib_uverbs] __fput+0x94/0x250 task_work_run+0x5c/0x90 do_exit+0x270/0x4a0 do_group_exit+0x2d/0x90 get_signal+0x87c/0x8c0 arch_do_signal_or_restart+0x25/0x100 ? ib_uverbs_ioctl+0xc2/0x110 [ib_uverbs] exit_to_user_mode_loop+0x9c/0x130 exit_to_user_mode_prepare+0xb6/0x100 syscall_exit_to_user_mode+0x12/0x40 do_syscall_64+0x69/0x90 ? syscall_exit_work+0x103/0x130 ? syscall_exit_to_user_mode+0x22/0x40 ? do_syscall_64+0x69/0x90 ? syscall_exit_work+0x103/0x130 ? syscall_exit_to_user_mode+0x22/0x40 ? do_syscall_64+0x69/0x90 ? do_syscall_64+0x69/0x90 ? common_interrupt+0x43/0xa0 entry_SYSCALL_64_after_hwframe+0x72/0xdc RIP: 0033:0x1470abe3ec6b Code: Unable to access opcode bytes at RIP 0x1470abe3ec41. RSP: 002b:00007fff13ce9108 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: fffffffffffffffc RBX: 00007fff13ce9218 RCX: 00001470abe3ec6b RDX: 00007fff13ce9200 RSI: 00000000c0181b01 RDI: 0000000000000004 RBP: 00007fff13ce91e0 R08: 0000558d9655da10 R09: 0000558d9655dd00 R10: 00007fff13ce95c0 R11: 0000000000000246 R12: 00007fff13ce9358 R13: 0000000000000013 R14: 0000558d9655db50 R15: 00007fff13ce9470 </TASK> --[ end trace 888a9b92e04c5c97 ]--(CVE-2024-26743)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/srpt: Support specifying the srpt_service_guid parameter
Make loading ib_srpt with this parameter set work. The current behavior is that setting that parameter while loading the ib_srpt kernel module triggers the following kernel crash:
BUG: kernel NULL pointer dereference, address: 0000000000000000 Call Trace: <TASK> parse_one+0x18c/0x1d0 parse_args+0xe1/0x230 load_module+0x8de/0xa60 init_module_from_file+0x8b/0xd0 idempotent_init_module+0x181/0x240 __x64_sys_finit_module+0x5a/0xb0 do_syscall_64+0x5f/0xe0 entry_SYSCALL_64_after_hwframe+0x6e/0x76(CVE-2024-26744)
In the Linux kernel, the following vulnerability has been resolved:
gtp: fix use-after-free and null-ptr-deref in gtp_genl_dump_pdp()
The gtp_net_ops pernet operations structure for the subsystem must be registered before registering the generic netlink family.
Syzkaller hit 'general protection fault in gtp_genl_dump_pdp' bug:
general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] CPU: 1 PID: 5826 Comm: gtp Not tainted 6.8.0-rc3-std-def-alt1 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-alt1 04/01/2014 RIP: 0010:gtp_genl_dump_pdp+0x1be/0x800 [gtp] Code: c6 89 c6 e8 64 e9 86 df 58 45 85 f6 0f 85 4e 04 00 00 e8 c5 ee 86 df 48 8b 54 24 18 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f 85 de 05 00 00 48 8b 44 24 18 4c 8b 30 4c 39 f0 74 RSP: 0018:ffff888014107220 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000002 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: ffff88800fcda588 R14: 0000000000000001 R15: 0000000000000000 FS: 00007f1be4eb05c0(0000) GS:ffff88806ce80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f1be4e766cf CR3: 000000000c33e000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: <TASK> ? show_regs+0x90/0xa0 ? die_addr+0x50/0xd0 ? exc_general_protection+0x148/0x220 ? asm_exc_general_protection+0x22/0x30 ? gtp_genl_dump_pdp+0x1be/0x800 [gtp] ? __alloc_skb+0x1dd/0x350 ? __pfxallocskb+0x10/0x10 genl_dumpit+0x11d/0x230 netlink_dump+0x5b9/0xce0 ? lockdep_hardirqs_on_prepare+0x253/0x430 ? pfx_netlink_dump+0x10/0x10 ? kasan_save_track+0x10/0x40 ? __kasan_kmalloc+0x9b/0xa0 ? genl_start+0x675/0x970 __netlink_dump_start+0x6fc/0x9f0 genl_family_rcv_msg_dumpit+0x1bb/0x2d0 ? __pfx_genl_family_rcv_msg_dumpit+0x10/0x10 ? genl_op_from_small+0x2a/0x440 ? cap_capable+0x1d0/0x240 ? __pfx_genl_start+0x10/0x10 ? __pfx_genl_dumpit+0x10/0x10 ? __pfx_genl_done+0x10/0x10 ? security_capable+0x9d/0xe0(CVE-2024-26754)
In the Linux kernel, the following vulnerability has been resolved:
dm-crypt: don't modify the data when using authenticated encryption
It was said that authenticated encryption could produce invalid tag when the data that is being encrypted is modified [1]. So, fix this problem by copying the data into the clone bio first and then encrypt them inside the clone bio.
This may reduce performance, but it is needed to prevent the user from corrupting the device by writing data with O_DIRECT and modifying them at the same time.
[1] https://lore.kernel.org/all/20240207004723.GA35324@sol.localdomain/T/(CVE-2024-26763)
In the Linux kernel, the following vulnerability has been resolved:
spi: hisi-sfc-v3xx: Return IRQ_NONE if no interrupts were detected
Return IRQ_NONE from the interrupt handler when no interrupt was detected. Because an empty interrupt will cause a null pointer error:
Unable to handle kernel NULL pointer dereference at virtual
address 0000000000000008 Call trace: complete+0x54/0x100 hisi_sfc_v3xx_isr+0x2c/0x40 [spi_hisi_sfc_v3xx] __handle_irq_event_percpu+0x64/0x1e0 handle_irq_event+0x7c/0x1cc(CVE-2024-26776)
In the Linux kernel, the following vulnerability has been resolved:
mptcp: fix double-free on socket dismantle
when MPTCP server accepts an incoming connection, it clones its listener socket. However, the pointer to 'inet_opt' for the new socket has the same value as the original one: as a consequence, on program exit it's possible to observe the following splat:
BUG: KASAN: double-free in inet_sock_destruct+0x54f/0x8b0 Free of addr ffff888485950880 by task swapper/25/0
CPU: 25 PID: 0 Comm: swapper/25 Kdump: loaded Not tainted 6.8.0-rc1+ #609 Hardware name: Supermicro SYS-6027R-72RF/X9DRH-7TF/7F/iTF/iF, BIOS 3.0 07/26/2013 Call Trace: <IRQ> dump_stack_lvl+0x32/0x50 print_report+0xca/0x620 kasan_report_invalid_free+0x64/0x90 __kasan_slab_free+0x1aa/0x1f0 kfree+0xed/0x2e0 inet_sock_destruct+0x54f/0x8b0 __sk_destruct+0x48/0x5b0 rcu_do_batch+0x34e/0xd90 rcu_core+0x559/0xac0 __do_softirq+0x183/0x5a4 irq_exit_rcu+0x12d/0x170 sysvec_apic_timer_interrupt+0x6b/0x80 </IRQ> <TASK> asm_sysvec_apic_timer_interrupt+0x16/0x20 RIP: 0010:cpuidle_enter_state+0x175/0x300 Code: 30 00 0f 84 1f 01 00 00 83 e8 01 83 f8 ff 75 e5 48 83 c4 18 44 89 e8 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc fb 45 85 ed <0f> 89 60 ff ff ff 48 c1 e5 06 48 c7 43 18 00 00 00 00 48 83 44 2b RSP: 0018:ffff888481cf7d90 EFLAGS: 00000202 RAX: 0000000000000000 RBX: ffff88887facddc8 RCX: 0000000000000000 RDX: 1ffff1110ff588b1 RSI: 0000000000000019 RDI: ffff88887fac4588 RBP: 0000000000000004 R08: 0000000000000002 R09: 0000000000043080 R10: 0009b02ea273363f R11: ffff88887fabf42b R12: ffffffff932592e0 R13: 0000000000000004 R14: 0000000000000000 R15: 00000022c880ec80 cpuidle_enter+0x4a/0xa0 do_idle+0x310/0x410 cpu_startup_entry+0x51/0x60 start_secondary+0x211/0x270 secondary_startup_64_no_verify+0x184/0x18b </TASK>
Allocated by task 6853: kasan_save_stack+0x1c/0x40 kasan_save_track+0x10/0x30 __kasan_kmalloc+0xa6/0xb0 __kmalloc+0x1eb/0x450 cipso_v4_sock_setattr+0x96/0x360 netlbl_sock_setattr+0x132/0x1f0 selinux_netlbl_socket_post_create+0x6c/0x110 selinux_socket_post_create+0x37b/0x7f0 security_socket_post_create+0x63/0xb0 __sock_create+0x305/0x450 __sys_socket_create.part.23+0xbd/0x130 __sys_socket+0x37/0xb0 __x64_sys_socket+0x6f/0xb0 do_syscall_64+0x83/0x160 entry_SYSCALL_64_after_hwframe+0x6e/0x76
Freed by task 6858: kasan_save_stack+0x1c/0x40 kasan_save_track+0x10/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x12c/0x1f0 kfree+0xed/0x2e0 inet_sock_destruct+0x54f/0x8b0 __sk_destruct+0x48/0x5b0 subflow_ulp_release+0x1f0/0x250 tcp_cleanup_ulp+0x6e/0x110 tcp_v4_destroy_sock+0x5a/0x3a0 inet_csk_destroy_sock+0x135/0x390 tcp_fin+0x416/0x5c0 tcp_data_queue+0x1bc8/0x4310 tcp_rcv_state_process+0x15a3/0x47b0 tcp_v4_do_rcv+0x2c1/0x990 tcp_v4_rcv+0x41fb/0x5ed0 ip_protocol_deliver_rcu+0x6d/0x9f0 ip_local_deliver_finish+0x278/0x360 ip_local_deliver+0x182/0x2c0 ip_rcv+0xb5/0x1c0 __netif_receive_skb_one_core+0x16e/0x1b0 process_backlog+0x1e3/0x650 __napi_poll+0xa6/0x500 net_rx_action+0x740/0xbb0 __do_softirq+0x183/0x5a4
The buggy address belongs to the object at ffff888485950880 which belongs to the cache kmalloc-64 of size 64 The buggy address is located 0 bytes inside of 64-byte region [ffff888485950880, ffff8884859508c0)
The buggy address belongs to the physical page: page:0000000056d1e95e refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888485950700 pfn:0x485950 flags: 0x57ffffc0000800(slab|node=1|zone=2|lastcpupid=0x1fffff) page_type: 0xffffffff() raw: 0057ffffc0000800 ffff88810004c640 ffffea00121b8ac0 dead000000000006 raw: ffff888485950700 0000000000200019 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected
Memory state around the buggy address: ffff888485950780: fa fb fb ---truncated---(CVE-2024-26782)
In the Linux kernel, the following vulnerability has been resolved:
mmc: mmci: stm32: fix DMA API overlapping mappings warning
Turning on CONFIG_DMA_API_DEBUG_SG results in the following warning:
DMA-API: mmci-pl18x 48220000.mmc: cacheline tracking EEXIST, overlapping mappings aren't supported WARNING: CPU: 1 PID: 51 at kernel/dma/debug.c:568 add_dma_entry+0x234/0x2f4 Modules linked in: CPU: 1 PID: 51 Comm: kworker/1:2 Not tainted 6.1.28 #1 Hardware name: STMicroelectronics STM32MP257F-EV1 Evaluation Board (DT) Workqueue: events_freezable mmc_rescan Call trace: add_dma_entry+0x234/0x2f4 debug_dma_map_sg+0x198/0x350 __dma_map_sg_attrs+0xa0/0x110 dma_map_sg_attrs+0x10/0x2c sdmmc_idma_prep_data+0x80/0xc0 mmci_prep_data+0x38/0x84 mmci_start_data+0x108/0x2dc mmci_request+0xe4/0x190 __mmc_start_request+0x68/0x140 mmc_start_request+0x94/0xc0 mmc_wait_for_req+0x70/0x100 mmc_send_tuning+0x108/0x1ac sdmmc_execute_tuning+0x14c/0x210 mmc_execute_tuning+0x48/0xec mmc_sd_init_uhs_card.part.0+0x208/0x464 mmc_sd_init_card+0x318/0x89c mmc_attach_sd+0xe4/0x180 mmc_rescan+0x244/0x320
DMA API debug brings to light leaking dma-mappings as dma_map_sg and dma_unmap_sg are not correctly balanced.
If an error occurs in mmci_cmd_irq function, only mmci_dma_error function is called and as this API is not managed on stm32 variant, dma_unmap_sg is never called in this error path.(CVE-2024-26787)
In the Linux kernel, the following vulnerability has been resolved:
btrfs: dev-replace: properly validate device names
There's a syzbot report that device name buffers passed to device replace are not properly checked for string termination which could lead to a read out of bounds in getname_kernel().
Add a helper that validates both source and target device name buffers. For devid as the source initialize the buffer to empty string in case something tries to read it later.
This was originally analyzed and fixed in a different way by Edward Adam Davis (see links).(CVE-2024-26791)
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix double free of anonymous device after snapshot creation failure
When creating a snapshot we may do a double free of an anonymous device in case there's an error committing the transaction. The second free may result in freeing an anonymous device number that was allocated by some other subsystem in the kernel or another btrfs filesystem.
The steps that lead to this:
1) At ioctl.c:create_snapshot() we allocate an anonymous device number and assign it to pending_snapshot->anon_dev;
2) Then we call btrfs_commit_transaction() and end up at transaction.c:create_pending_snapshot();
3) There we call btrfs_get_new_fs_root() and pass it the anonymous device number stored in pending_snapshot->anon_dev;
4) btrfs_get_new_fs_root() frees that anonymous device number because btrfs_lookup_fs_root() returned a root - someone else did a lookup of the new root already, which could some task doing backref walking;
5) After that some error happens in the transaction commit path, and at ioctl.c:create_snapshot() we jump to the 'fail' label, and after that we free again the same anonymous device number, which in the meanwhile may have been reallocated somewhere else, because pending_snapshot->anon_dev still has the same value as in step 1.
Recently syzbot ran into this and reported the following trace:
------------[ cut here ]------------ ida_free called for id=51 which is not allocated. WARNING: CPU: 1 PID: 31038 at lib/idr.c:525 ida_free+0x370/0x420 lib/idr.c:525 Modules linked in: CPU: 1 PID: 31038 Comm: syz-executor.2 Not tainted 6.8.0-rc4-syzkaller-00410-gc02197fc9076 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024 RIP: 0010:ida_free+0x370/0x420 lib/idr.c:525 Code: 10 42 80 3c 28 (...) RSP: 0018:ffffc90015a67300 EFLAGS: 00010246 RAX: be5130472f5dd000 RBX: 0000000000000033 RCX: 0000000000040000 RDX: ffffc90009a7a000 RSI: 000000000003ffff RDI: 0000000000040000 RBP: ffffc90015a673f0 R08: ffffffff81577992 R09: 1ffff92002b4cdb4 R10: dffffc0000000000 R11: fffff52002b4cdb5 R12: 0000000000000246 R13: dffffc0000000000 R14: ffffffff8e256b80 R15: 0000000000000246 FS: 00007fca3f4b46c0(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f167a17b978 CR3: 000000001ed26000 CR4: 0000000000350ef0 Call Trace: <TASK> btrfs_get_root_ref+0xa48/0xaf0 fs/btrfs/disk-io.c:1346 create_pending_snapshot+0xff2/0x2bc0 fs/btrfs/transaction.c:1837 create_pending_snapshots+0x195/0x1d0 fs/btrfs/transaction.c:1931 btrfs_commit_transaction+0xf1c/0x3740 fs/btrfs/transaction.c:2404 create_snapshot+0x507/0x880 fs/btrfs/ioctl.c:848 btrfs_mksubvol+0x5d0/0x750 fs/btrfs/ioctl.c:998 btrfs_mksnapshot+0xb5/0xf0 fs/btrfs/ioctl.c:1044 __btrfs_ioctl_snap_create+0x387/0x4b0 fs/btrfs/ioctl.c:1306 btrfs_ioctl_snap_create_v2+0x1ca/0x400 fs/btrfs/ioctl.c:1393 btrfs_ioctl+0xa74/0xd40 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:871 [inline] __se_sys_ioctl+0xfe/0x170 fs/ioctl.c:857 do_syscall_64+0xfb/0x240 entry_SYSCALL_64_after_hwframe+0x6f/0x77 RIP: 0033:0x7fca3e67dda9 Code: 28 00 00 00 (...) RSP: 002b:00007fca3f4b40c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007fca3e7abf80 RCX: 00007fca3e67dda9 RDX: 00000000200005c0 RSI: 0000000050009417 RDI: 0000000000000003 RBP: 00007fca3e6ca47a R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 000000000000000b R14: 00007fca3e7abf80 R15: 00007fff6bf95658 </TASK>
Where we get an explicit message where we attempt to free an anonymous device number that is not currently allocated. It happens in a different code path from the example below, at btrfs_get_root_ref(), so this change may not fix the case triggered by sy ---truncated---(CVE-2024-26792)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: Avoid potential use-after-free in hci_error_reset
While handling the HCI_EV_HARDWARE_ERROR event, if the underlying BT controller is not responding, the GPIO reset mechanism would free the hci_dev and lead to a use-after-free in hci_error_reset.
Here's the call trace observed on a ChromeOS device with Intel AX201: queue_work_on+0x3e/0x6c __hci_cmd_sync_sk+0x2ee/0x4c0 [bluetooth <HASH:3b4a6>] ? init_wait_entry+0x31/0x31 __hci_cmd_sync+0x16/0x20 [bluetooth <HASH:3b4a 6>] hci_error_reset+0x4f/0xa4 [bluetooth <HASH:3b4a 6>] process_one_work+0x1d8/0x33f worker_thread+0x21b/0x373 kthread+0x13a/0x152 ? pr_cont_work+0x54/0x54 ? kthread_blkcg+0x31/0x31 ret_from_fork+0x1f/0x30
This patch holds the reference count on the hci_dev while processing a HCI_EV_HARDWARE_ERROR event to avoid potential crash.(CVE-2024-26801)
In the Linux kernel, the following vulnerability has been resolved:
net: ip_tunnel: prevent perpetual headroom growth
syzkaller triggered following kasan splat: BUG: KASAN: use-after-free in __skb_flow_dissect+0x19d1/0x7a50 net/core/flow_dissector.c:1170 Read of size 1 at addr ffff88812fb4000e by task syz-executor183/5191 [..] kasan_report+0xda/0x110 mm/kasan/report.c:588 __skb_flow_dissect+0x19d1/0x7a50 net/core/flow_dissector.c:1170 skb_flow_dissect_flow_keys include/linux/skbuff.h:1514 [inline] skbget_hash net/core/flow_dissector.c:1791 [inline] skb_get_hash+0xc7/0x540 net/core/flow_dissector.c:1856 skb_get_hash include/linux/skbuff.h:1556 [inline] ip_tunnel_xmit+0x1855/0x33c0 net/ipv4/ip_tunnel.c:748 ipip_tunnel_xmit+0x3cc/0x4e0 net/ipv4/ipip.c:308 __netdev_start_xmit include/linux/netdevice.h:4940 [inline] netdev_start_xmit include/linux/netdevice.h:4954 [inline] xmit_one net/core/dev.c:3548 [inline] dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3564 __dev_queue_xmit+0x7c1/0x3d60 net/core/dev.c:4349 dev_queue_xmit include/linux/netdevice.h:3134 [inline] neigh_connected_output+0x42c/0x5d0 net/core/neighbour.c:1592 ... ip_finish_output2+0x833/0x2550 net/ipv4/ip_output.c:235 ip_finish_output+0x31/0x310 net/ipv4/ip_output.c:323 .. iptunnel_xmit+0x5b4/0x9b0 net/ipv4/ip_tunnel_core.c:82 ip_tunnel_xmit+0x1dbc/0x33c0 net/ipv4/ip_tunnel.c:831 ipgre_xmit+0x4a1/0x980 net/ipv4/ip_gre.c:665 __netdev_start_xmit include/linux/netdevice.h:4940 [inline] netdev_start_xmit include/linux/netdevice.h:4954 [inline] xmit_one net/core/dev.c:3548 [inline] dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3564 ...
The splat occurs because skb->data points past skb->head allocated area. This is because neigh layer does: __skb_pull(skb, skb_network_offset(skb));
... but skb_network_offset() returns a negative offset and __skb_pull() arg is unsigned. IOW, we skb->data gets "adjusted" by a huge value.
The negative value is returned because skb->head and skb->data distance is more than 64k and skb->network_header (u16) has wrapped around.
The bug is in the ip_tunnel infrastructure, which can cause dev->needed_headroom to increment ad infinitum.
The syzkaller reproducer consists of packets getting routed via a gre tunnel, and route of gre encapsulated packets pointing at another (ipip) tunnel. The ipip encapsulation finds gre0 as next output device.
This results in the following pattern:
1). First packet is to be sent out via gre0. Route lookup found an output device, ipip0.
2). ip_tunnel_xmit for gre0 bumps gre0->needed_headroom based on the future output device, rt.dev->needed_headroom (ipip0).
3). ip output / start_xmit moves skb on to ipip0. which runs the same code path again (xmit recursion).
4). Routing step for the post-gre0-encap packet finds gre0 as output device to use for ipip0 encapsulated packet.
tunl0->needed_headroom is then incremented based on the (already bumped) gre0 device headroom.
This repeats for every future packet:
gre0->needed_headroom gets inflated because previous packets' ipip0 step incremented rt->dev (gre0) headroom, and ipip0 incremented because gre0 needed_headroom was increased.
For each subsequent packet, gre/ipip0->needed_headroom grows until post-expand-head reallocations result in a skb->head/data distance of more than 64k.
Once that happens, skb->network_header (u16) wraps around when pskb_expand_head tries to make sure that skb_network_offset() is unchanged after the headroom expansion/reallocation.
After this skb_network_offset(skb) returns a different (and negative) result post headroom expansion.
The next trip to neigh layer (or anything else that would __skb_pull the network header) makes skb->data point to a memory location outside skb->head area.
v2: Cap the needed_headroom update to an arbitarily chosen upperlimit to prevent perpetual increase instead of dropping the headroom increment completely.(CVE-2024-26804)
In the Linux kernel, the following vulnerability has been resolved:
netlink: Fix kernel-infoleak-after-free in __skb_datagram_iter
syzbot reported the following uninit-value access issue [1]:
netlink_to_full_skb() creates a new skb and puts the skb->data
passed as a 1st arg of netlink_to_full_skb() onto new skb. The data
size is specified as len and passed to skb_put_data(). This len
is based on skb->end that is not data offset but buffer offset. The
skb->end contains data and tailroom. Since the tailroom is not
initialized when the new skb created, KMSAN detects uninitialized
memory area when copying the data.
This patch resolved this issue by correct the len from skb->end to
skb->len, which is the actual data offset.
BUG: KMSAN: kernel-infoleak-after-free in instrument_copy_to_user include/linux/instrumented.h:114 [inline] BUG: KMSAN: kernel-infoleak-after-free in copy_to_user_iter lib/iov_iter.c:24 [inline] BUG: KMSAN: kernel-infoleak-after-free in iterate_ubuf include/linux/iov_iter.h:29 [inline] BUG: KMSAN: kernel-infoleak-after-free in iterate_and_advance2 include/linux/iov_iter.h:245 [inline] BUG: KMSAN: kernel-infoleak-after-free in iterate_and_advance include/linux/iov_iter.h:271 [inline] BUG: KMSAN: kernel-infoleak-after-free in _copy_to_iter+0x364/0x2520 lib/iov_iter.c:186 instrument_copy_to_user include/linux/instrumented.h:114 [inline] copy_to_user_iter lib/iov_iter.c:24 [inline] iterate_ubuf include/linux/iov_iter.h:29 [inline] iterate_and_advance2 include/linux/iov_iter.h:245 [inline] iterate_and_advance include/linux/iov_iter.h:271 [inline] _copy_to_iter+0x364/0x2520 lib/iov_iter.c:186 copy_to_iter include/linux/uio.h:197 [inline] simple_copy_to_iter+0x68/0xa0 net/core/datagram.c:532 __skb_datagram_iter+0x123/0xdc0 net/core/datagram.c:420 skb_copy_datagram_iter+0x5c/0x200 net/core/datagram.c:546 skb_copy_datagram_msg include/linux/skbuff.h:3960 [inline] packet_recvmsg+0xd9c/0x2000 net/packet/af_packet.c:3482 sock_recvmsg_nosec net/socket.c:1044 [inline] sock_recvmsg net/socket.c:1066 [inline] sock_read_iter+0x467/0x580 net/socket.c:1136 call_read_iter include/linux/fs.h:2014 [inline] new_sync_read fs/read_write.c:389 [inline] vfs_read+0x8f6/0xe00 fs/read_write.c:470 ksys_read+0x20f/0x4c0 fs/read_write.c:613 __do_sys_read fs/read_write.c:623 [inline] __se_sys_read fs/read_write.c:621 [inline] __x64_sys_read+0x93/0xd0 fs/read_write.c:621 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b
Uninit was stored to memory at: skb_put_data include/linux/skbuff.h:2622 [inline] netlink_to_full_skb net/netlink/af_netlink.c:181 [inline] __netlink_deliver_tap_skb net/netlink/af_netlink.c:298 [inline] __netlink_deliver_tap+0x5be/0xc90 net/netlink/af_netlink.c:325 netlink_deliver_tap net/netlink/af_netlink.c:338 [inline] netlink_deliver_tap_kernel net/netlink/af_netlink.c:347 [inline] netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline] netlink_unicast+0x10f1/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:745 [inline] _syssendmsg+0x9c2/0xd60 net/socket.c:2584 _sys_sendmsg+0x28d/0x3c0 net/socket.c:2638 __sys_sendmsg net/socket.c:2667 [inline] __do_sys_sendmsg net/socket.c:2676 [inline] __se_sys_sendmsg net/socket.c:2674 [inline] __x64_sys_sendmsg+0x307/0x490 net/socket.c:2674 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b
Uninit was created at: free_pages_prepare mm/page_alloc.c:1087 [inline] free_unref_page_prepare+0xb0/0xa40 mm/page_alloc.c:2347 free_unref_page_list+0xeb/0x1100 mm/page_alloc.c:2533 release_pages+0x23d3/0x2410 mm/swap.c:1042 free_pages_and_swap_cache+0xd9/0xf0 mm/swap_state.c:316 tlb_batch_pages ---truncated---(CVE-2024-26805)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nft_chain_filter: handle NETDEV_UNREGISTER for inet/ingress basechain
Remove netdevice from inet/ingress basechain in case NETDEV_UNREGISTER event is reported, otherwise a stale reference to netdevice remains in the hook list.(CVE-2024-26808)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nft_set_pipapo: release elements in clone only from destroy path
Clone already always provides a current view of the lookup table, use it to destroy the set, otherwise it is possible to destroy elements twice.
This fix requires:
212ed75dc5fb ("netfilter: nf_tables: integrate pipapo into commit protocol")
which came after:
9827a0e6e23b ("netfilter: nft_set_pipapo: release elements in clone from abort path").(CVE-2024-26809)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: validate payload size in ipc response
If installing malicious ksmbd-tools, ksmbd.mountd can return invalid ipc response to ksmbd kernel server. ksmbd should validate payload size of ipc response from ksmbd.mountd to avoid memory overrun or slab-out-of-bounds. This patch validate 3 ipc response that has payload.(CVE-2024-26811)
In the Linux kernel, the following vulnerability has been resolved:
vfio/pci: Create persistent INTx handler
A vulnerability exists where the eventfd for INTx signaling can be deconfigured, which unregisters the IRQ handler but still allows eventfds to be signaled with a NULL context through the SET_IRQS ioctl or through unmask irqfd if the device interrupt is pending.
Ideally this could be solved with some additional locking; the igate mutex serializes the ioctl and config space accesses, and the interrupt handler is unregistered relative to the trigger, but the irqfd path runs asynchronous to those. The igate mutex cannot be acquired from the atomic context of the eventfd wake function. Disabling the irqfd relative to the eventfd registration is potentially incompatible with existing userspace.
As a result, the solution implemented here moves configuration of the INTx interrupt handler to track the lifetime of the INTx context object and irq_type configuration, rather than registration of a particular trigger eventfd. Synchronization is added between the ioctl path and eventfd_signal() wrapper such that the eventfd trigger can be dynamically updated relative to in-flight interrupts or irqfd callbacks.(CVE-2024-26812)
In the Linux kernel, the following vulnerability has been resolved:
vfio/fsl-mc: Block calling interrupt handler without trigger
The eventfd_ctx trigger pointer of the vfio_fsl_mc_irq object is initially NULL and may become NULL if the user sets the trigger eventfd to -1. The interrupt handler itself is guaranteed that trigger is always valid between request_irq() and free_irq(), but the loopback testing mechanisms to invoke the handler function need to test the trigger. The triggering and setting ioctl paths both make use of igate and are therefore mutually exclusive.
The vfio-fsl-mc driver does not make use of irqfds, nor does it support any sort of masking operations, therefore unlike vfio-pci and vfio-platform, the flow can remain essentially unchanged.(CVE-2024-26814)
In the Linux kernel, the following vulnerability has been resolved:
amdkfd: use calloc instead of kzalloc to avoid integer overflow
This uses calloc instead of doing the multiplication which might overflow.(CVE-2024-26817)
In the Linux kernel, the following vulnerability has been resolved:
cifs: fix underflow in parse_server_interfaces()
In this loop, we step through the buffer and after each item we check if the size_left is greater than the minimum size we need. However, the problem is that "bytes_left" is type ssize_t while sizeof() is type size_t. That means that because of type promotion, the comparison is done as an unsigned and if we have negative bytes left the loop continues instead of ending.(CVE-2024-26828)
In the Linux kernel, the following vulnerability has been resolved:
media: ir_toy: fix a memleak in irtoy_tx
When irtoy_command fails, buf should be freed since it is allocated by irtoy_tx, or there is a memleak.(CVE-2024-26829)
In the Linux kernel, the following vulnerability has been resolved:
IB/hfi1: Fix a memleak in init_credit_return
When dma_alloc_coherent fails to allocate dd->cr_base[i].va, init_credit_return should deallocate dd->cr_base and dd->cr_base[i] that allocated before. Or those resources would be never freed and a memleak is triggered.(CVE-2024-26839)
In the Linux kernel, the following vulnerability has been resolved:
cachefiles: fix memory leak in cachefiles_add_cache()
The following memory leak was reported after unbinding /dev/cachefiles:
================================================================== unreferenced object 0xffff9b674176e3c0 (size 192): comm "cachefilesd2", pid 680, jiffies 4294881224 hex dump (first 32 bytes): 01 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 00 00 00 00 ................ backtrace (crc ea38a44b): [<ffffffff8eb8a1a5>] kmem_cache_alloc+0x2d5/0x370 [<ffffffff8e917f86>] prepare_creds+0x26/0x2e0 [<ffffffffc002eeef>] cachefiles_determine_cache_security+0x1f/0x120 [<ffffffffc00243ec>] cachefiles_add_cache+0x13c/0x3a0 [<ffffffffc0025216>] cachefiles_daemon_write+0x146/0x1c0 [<ffffffff8ebc4a3b>] vfs_write+0xcb/0x520 [<ffffffff8ebc5069>] ksys_write+0x69/0xf0 [<ffffffff8f6d4662>] do_syscall_64+0x72/0x140 [<ffffffff8f8000aa>] entry_SYSCALL_64_after_hwframe+0x6e/0x76 ==================================================================
Put the reference count of cache_cred in cachefiles_daemon_unbind() to fix the problem. And also put cache_cred in cachefiles_add_cache() error branch to avoid memory leaks.(CVE-2024-26840)
In the Linux kernel, the following vulnerability has been resolved:
efi: runtime: Fix potential overflow of soft-reserved region size
md_size will have been narrowed if we have >= 4GB worth of pages in a soft-reserved region.(CVE-2024-26843)
In the Linux kernel, the following vulnerability has been resolved:
nvme-fc: do not wait in vain when unloading module
The module exit path has race between deleting all controllers and freeing 'left over IDs'. To prevent double free a synchronization between nvme_delete_ctrl and ida_destroy has been added by the initial commit.
There is some logic around trying to prevent from hanging forever in wait_for_completion, though it does not handling all cases. E.g. blktests is able to reproduce the situation where the module unload hangs forever.
If we completely rely on the cleanup code executed from the nvme_delete_ctrl path, all IDs will be freed eventually. This makes calling ida_destroy unnecessary. We only have to ensure that all nvme_delete_ctrl code has been executed before we leave nvme_fc_exit_module. This is done by flushing the nvme_delete_wq workqueue.
While at it, remove the unused nvme_fc_wq workqueue too.(CVE-2024-26846)
In the Linux kernel, the following vulnerability has been resolved:
net/ipv6: avoid possible UAF in ip6_route_mpath_notify()
syzbot found another use-after-free in ip6_route_mpath_notify() [1]
Commit f7225172f25a ("net/ipv6: prevent use after free in ip6_route_mpath_notify") was not able to fix the root cause.
We need to defer the fib6_info_release() calls after ip6_route_mpath_notify(), in the cleanup phase.
[1] BUG: KASAN: slab-use-after-free in rt6_fill_node+0x1460/0x1ac0 Read of size 4 at addr ffff88809a07fc64 by task syz-executor.2/23037
CPU: 0 PID: 23037 Comm: syz-executor.2 Not tainted 6.8.0-rc4-syzkaller-01035-gea7f3cfaa588 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1e7/0x2e0 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:377 [inline] print_report+0x167/0x540 mm/kasan/report.c:488 kasan_report+0x142/0x180 mm/kasan/report.c:601 rt6_fill_node+0x1460/0x1ac0 inet6_rt_notify+0x13b/0x290 net/ipv6/route.c:6184 ip6_route_mpath_notify net/ipv6/route.c:5198 [inline] ip6_route_multipath_add net/ipv6/route.c:5404 [inline] inet6_rtm_newroute+0x1d0f/0x2300 net/ipv6/route.c:5517 rtnetlink_rcv_msg+0x885/0x1040 net/core/rtnetlink.c:6597 netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2543 netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline] netlink_unicast+0x7ea/0x980 net/netlink/af_netlink.c:1367 netlink_sendmsg+0xa3b/0xd70 net/netlink/af_netlink.c:1908 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:745 _syssendmsg+0x525/0x7d0 net/socket.c:2584 _sys_sendmsg net/socket.c:2638 [inline] __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667 do_syscall_64+0xf9/0x240 entry_SYSCALL_64_after_hwframe+0x6f/0x77 RIP: 0033:0x7f73dd87dda9 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f73de6550c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f73dd9ac050 RCX: 00007f73dd87dda9 RDX: 0000000000000000 RSI: 0000000020000140 RDI: 0000000000000005 RBP: 00007f73dd8ca47a R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 000000000000006e R14: 00007f73dd9ac050 R15: 00007ffdbdeb7858 </TASK>
Allocated by task 23037: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:372 [inline] __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:389 kasan_kmalloc include/linux/kasan.h:211 [inline] __do_kmalloc_node mm/slub.c:3981 [inline] __kmalloc+0x22e/0x490 mm/slub.c:3994 kmalloc include/linux/slab.h:594 [inline] kzalloc include/linux/slab.h:711 [inline] fib6_info_alloc+0x2e/0xf0 net/ipv6/ip6_fib.c:155 ip6_route_info_create+0x445/0x12b0 net/ipv6/route.c:3758 ip6_route_multipath_add net/ipv6/route.c:5298 [inline] inet6_rtm_newroute+0x744/0x2300 net/ipv6/route.c:5517 rtnetlink_rcv_msg+0x885/0x1040 net/core/rtnetlink.c:6597 netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2543 netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline] netlink_unicast+0x7ea/0x980 net/netlink/af_netlink.c:1367 netlink_sendmsg+0xa3b/0xd70 net/netlink/af_netlink.c:1908 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:745 _syssendmsg+0x525/0x7d0 net/socket.c:2584 _sys_sendmsg net/socket.c:2638 [inline] __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667 do_syscall_64+0xf9/0x240 entry_SYSCALL_64_after_hwframe+0x6f/0x77
Freed by task 16: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x4e/0x60 mm/kasan/generic.c:640 poison_slab_object+0xa6/0xe0 m ---truncated---(CVE-2024-26852)
In the Linux kernel, the following vulnerability has been resolved:
net: ice: Fix potential NULL pointer dereference in ice_bridge_setlink()
The function ice_bridge_setlink() may encounter a NULL pointer dereference if nlmsg_find_attr() returns NULL and br_spec is dereferenced subsequently in nla_for_each_nested(). To address this issue, add a check to ensure that br_spec is not NULL before proceeding with the nested attribute iteration.(CVE-2024-26855)
In the Linux kernel, the following vulnerability has been resolved:
net/bnx2x: Prevent access to a freed page in page_pool
Fix race condition leading to system crash during EEH error handling
During EEH error recovery, the bnx2x driver's transmit timeout logic could cause a race condition when handling reset tasks. The bnx2x_tx_timeout() schedules reset tasks via bnx2x_sp_rtnl_task(), which ultimately leads to bnx2x_nic_unload(). In bnx2x_nic_unload() SGEs are freed using bnx2x_free_rx_sge_range(). However, this could overlap with the EEH driver's attempt to reset the device using bnx2x_io_slot_reset(), which also tries to free SGEs. This race condition can result in system crashes due to accessing freed memory locations in bnx2x_free_rx_sge()
799 static inline void bnx2x_free_rx_sge(struct bnx2x bp, 800 struct bnx2x_fastpath fp, u16 index) 801 { 802 struct sw_rx_page sw_buf = &fp->rx_page_ring[index]; 803 struct page page = sw_buf->page; .... where sw_buf was set to NULL after the call to dma_unmap_page() by the preceding thread.
EEH: Beginning: 'slot_reset'
PCI 0011:01:00.0#10000: EEH: Invoking bnx2x->slot_reset()
bnx2x: [bnx2x_io_slot_reset:14228(eth1)]IO slot reset initializing...
bnx2x 0011:01:00.0: enabling device (0140 -> 0142)
bnx2x: [bnx2x_io_slot_reset:14244(eth1)]IO slot reset --> driver unload
Kernel attempted to read user page (0) - exploit attempt? (uid: 0)
BUG: Kernel NULL pointer dereference on read at 0x00000000
Faulting instruction address: 0xc0080000025065fc
Oops: Kernel access of bad area, sig: 11 [#1]
.....
Call Trace:
[c000000003c67a20] [c00800000250658c] bnx2x_io_slot_reset+0x204/0x610 [bnx2x] (unreliable)
[c000000003c67af0] [c0000000000518a8] eeh_report_reset+0xb8/0xf0
[c000000003c67b60] [c000000000052130] eeh_pe_report+0x180/0x550
[c000000003c67c70] [c00000000005318c] eeh_handle_normal_event+0x84c/0xa60
[c000000003c67d50] [c000000000053a84] eeh_event_handler+0xf4/0x170
[c000000003c67da0] [c000000000194c58] kthread+0x1c8/0x1d0
[c000000003c67e10] [c00000000000cf64] ret_from_kernel_thread+0x5c/0x64
To solve this issue, we need to verify page pool allocations before freeing.(CVE-2024-26859)
In the Linux kernel, the following vulnerability has been resolved:
packet: annotate data-races around ignore_outgoing
ignore_outgoing is read locklessly from dev_queue_xmit_nit() and packet_getsockopt()
Add appropriate READ_ONCE()/WRITE_ONCE() annotations.
syzbot reported:
BUG: KCSAN: data-race in dev_queue_xmit_nit / packet_setsockopt
write to 0xffff888107804542 of 1 bytes by task 22618 on cpu 0: packet_setsockopt+0xd83/0xfd0 net/packet/af_packet.c:4003 do_sock_setsockopt net/socket.c:2311 [inline] __sys_setsockopt+0x1d8/0x250 net/socket.c:2334 __do_sys_setsockopt net/socket.c:2343 [inline] __se_sys_setsockopt net/socket.c:2340 [inline] __x64_sys_setsockopt+0x66/0x80 net/socket.c:2340 do_syscall_64+0xd3/0x1d0 entry_SYSCALL_64_after_hwframe+0x6d/0x75
read to 0xffff888107804542 of 1 bytes by task 27 on cpu 1: dev_queue_xmit_nit+0x82/0x620 net/core/dev.c:2248 xmit_one net/core/dev.c:3527 [inline] dev_hard_start_xmit+0xcc/0x3f0 net/core/dev.c:3547 __dev_queue_xmit+0xf24/0x1dd0 net/core/dev.c:4335 dev_queue_xmit include/linux/netdevice.h:3091 [inline] batadv_send_skb_packet+0x264/0x300 net/batman-adv/send.c:108 batadv_send_broadcast_skb+0x24/0x30 net/batman-adv/send.c:127 batadv_iv_ogm_send_to_if net/batman-adv/bat_iv_ogm.c:392 [inline] batadv_iv_ogm_emit net/batman-adv/bat_iv_ogm.c:420 [inline] batadv_iv_send_outstanding_bat_ogm_packet+0x3f0/0x4b0 net/batman-adv/bat_iv_ogm.c:1700 process_one_work kernel/workqueue.c:3254 [inline] process_scheduled_works+0x465/0x990 kernel/workqueue.c:3335 worker_thread+0x526/0x730 kernel/workqueue.c:3416 kthread+0x1d1/0x210 kernel/kthread.c:388 ret_from_fork+0x4b/0x60 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:243
value changed: 0x00 -> 0x01
Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 27 Comm: kworker/u8:1 Tainted: G W 6.8.0-syzkaller-08073-g480e035fc4c7 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024 Workqueue: bat_events batadv_iv_send_outstanding_bat_ogm_packet(CVE-2024-26862)
In the Linux kernel, the following vulnerability has been resolved:
hsr: Fix uninit-value access in hsr_get_node()
KMSAN reported the following uninit-value access issue [1]:
===================================================== BUG: KMSAN: uninit-value in hsr_get_node+0xa2e/0xa40 net/hsr/hsr_framereg.c:246 hsr_get_node+0xa2e/0xa40 net/hsr/hsr_framereg.c:246 fill_frame_info net/hsr/hsr_forward.c:577 [inline] hsr_forward_skb+0xe12/0x30e0 net/hsr/hsr_forward.c:615 hsr_dev_xmit+0x1a1/0x270 net/hsr/hsr_device.c:223 __netdev_start_xmit include/linux/netdevice.h:4940 [inline] netdev_start_xmit include/linux/netdevice.h:4954 [inline] xmit_one net/core/dev.c:3548 [inline] dev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3564 __dev_queue_xmit+0x33b8/0x5130 net/core/dev.c:4349 dev_queue_xmit include/linux/netdevice.h:3134 [inline] packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3087 [inline] packet_sendmsg+0x8b1d/0x9f30 net/packet/af_packet.c:3119 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x735/0xa10 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b
Uninit was created at: slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768 slab_alloc_node mm/slub.c:3478 [inline] kmem_cache_alloc_node+0x5e9/0xb10 mm/slub.c:3523 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560 __alloc_skb+0x318/0x740 net/core/skbuff.c:651 alloc_skb include/linux/skbuff.h:1286 [inline] alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6334 sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2787 packet_alloc_skb net/packet/af_packet.c:2936 [inline] packet_snd net/packet/af_packet.c:3030 [inline] packet_sendmsg+0x70e8/0x9f30 net/packet/af_packet.c:3119 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x735/0xa10 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b
CPU: 1 PID: 5033 Comm: syz-executor334 Not tainted 6.7.0-syzkaller-00562-g9f8413c4a66f #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023 =====================================================
If the packet type ID field in the Ethernet header is either ETH_P_PRP or ETH_P_HSR, but it is not followed by an HSR tag, hsr_get_skb_sequence_nr() reads an invalid value as a sequence number. This causes the above issue.
This patch fixes the issue by returning NULL if the Ethernet header is not followed by an HSR tag.(CVE-2024-26863)
In the Linux kernel, the following vulnerability has been resolved:
rds: tcp: Fix use-after-free of net in reqsk_timer_handler().
syzkaller reported a warning of netns tracker [0] followed by KASAN splat [1] and another ref tracker warning [1].
syzkaller could not find a repro, but in the log, the only suspicious sequence was as follows:
18:26:22 executing program 1: r0 = socket$inet6_mptcp(0xa, 0x1, 0x106) ... connect$inet6(r0, &(0x7f0000000080)={0xa, 0x4001, 0x0, @loopback}, 0x1c) (async)
The notable thing here is 0x4001 in connect(), which is RDS_TCP_PORT.
So, the scenario would be:
- unshare(CLONE_NEWNET) creates a per netns tcp listener in rds_tcp_listen_init().
- syz-executor connect()s to it and creates a reqsk.
- syz-executor exit()s immediately.
- netns is dismantled. [0]
- reqsk timer is fired, and UAF happens while freeing reqsk. [1]
- listener is freed after RCU grace period. [2]
Basically, reqsk assumes that the listener guarantees netns safety until all reqsk timers are expired by holding the listener's refcount. However, this was not the case for kernel sockets.
Commit 740ea3c4a0b2 ("tcp: Clean up kernel listener's reqsk in inet_twsk_purge()") fixed this issue only for per-netns ehash.
Let's apply the same fix for the global ehash.
[0]: ref_tracker: net notrefcnt@0000000065449cc3 has 1/1 users at sk_alloc (./include/net/net_namespace.h:337 net/core/sock.c:2146) inet6_create (net/ipv6/af_inet6.c:192 net/ipv6/af_inet6.c:119) __sock_create (net/socket.c:1572) rds_tcp_listen_init (net/rds/tcp_listen.c:279) rds_tcp_init_net (net/rds/tcp.c:577) ops_init (net/core/net_namespace.c:137) setup_net (net/core/net_namespace.c:340) copy_net_ns (net/core/net_namespace.c:497) create_new_namespaces (kernel/nsproxy.c:110) unshare_nsproxy_namespaces (kernel/nsproxy.c:228 (discriminator 4)) ksys_unshare (kernel/fork.c:3429) __x64_sys_unshare (kernel/fork.c:3496) do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:129) ... WARNING: CPU: 0 PID: 27 at lib/ref_tracker.c:179 ref_tracker_dir_exit (lib/ref_tracker.c:179)
[1]: BUG: KASAN: slab-use-after-free in inet_csk_reqsk_queue_drop (./include/net/inet_hashtables.h:180 net/ipv4/inet_connection_sock.c:952 net/ipv4/inet_connection_sock.c:966) Read of size 8 at addr ffff88801b370400 by task swapper/0/0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 Call Trace: <IRQ> dump_stack_lvl (lib/dump_stack.c:107 (discriminator 1)) print_report (mm/kasan/report.c:378 mm/kasan/report.c:488) kasan_report (mm/kasan/report.c:603) inet_csk_reqsk_queue_drop (./include/net/inet_hashtables.h:180 net/ipv4/inet_connection_sock.c:952 net/ipv4/inet_connection_sock.c:966) reqsk_timer_handler (net/ipv4/inet_connection_sock.c:979 net/ipv4/inet_connection_sock.c:1092) call_timer_fn (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:207 ./include/trace/events/timer.h:127 kernel/time/timer.c:1701) __run_timers.part.0 (kernel/time/timer.c:1752 kernel/time/timer.c:2038) run_timer_softirq (kernel/time/timer.c:2053) __do_softirq (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:207 ./include/trace/events/irq.h:142 kernel/softirq.c:554) irq_exit_rcu (kernel/softirq.c:427 kernel/softirq.c:632 kernel/softirq.c:644) sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1076 (discriminator 14)) </IRQ>
Allocated by task 258 on cpu 0 at 83.612050s: kasan_save_stack (mm/kasan/common.c:48) kasan_save_track (mm/kasan/common.c:68) __kasan_slab_alloc (mm/kasan/common.c:343) kmem_cache_alloc (mm/slub.c:3813 mm/slub.c:3860 mm/slub.c:3867) copy_net_ns (./include/linux/slab.h:701 net/core/net_namespace.c:421 net/core/net_namespace.c:480) create_new_namespaces (kernel/nsproxy.c:110) unshare_nsproxy_name ---truncated---(CVE-2024-26865)
In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to truncate meta inode pages forcely
Below race case can cause data corruption:
Thread A GC thread - gc_data_segment - ra_data_block - locked meta_inode page - f2fs_inplace_write_data - invalidate_mapping_pages : fail to invalidate meta_inode page due to lock failure or dirty|writeback status - f2fs_submit_page_bio : write last dirty data to old blkaddr - move_data_block - load old data from meta_inode page - f2fs_submit_page_write : write old data to new blkaddr
Because invalidate_mapping_pages() will skip invalidating page which has unclear status including locked, dirty, writeback and so on, so we need to use truncate_inode_pages_range() instead of invalidate_mapping_pages() to make sure meta_inode page will be dropped.(CVE-2024-26869)
In the Linux kernel, the following vulnerability has been resolved:
NFSv4.2: fix nfs4_listxattr kernel BUG at mm/usercopy.c:102
A call to listxattr() with a buffer size = 0 returns the actual size of the buffer needed for a subsequent call. When size > 0, nfs4_listxattr() does not return an error because either generic_listxattr() or nfs4_listxattr_nfs4_label() consumes exactly all the bytes then size is 0 when calling nfs4_listxattr_nfs4_user() which then triggers the following kernel BUG:
[ 99.403778] kernel BUG at mm/usercopy.c:102! [ 99.404063] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP [ 99.408463] CPU: 0 PID: 3310 Comm: python3 Not tainted 6.6.0-61.fc40.aarch64 #1 [ 99.415827] Call trace: [ 99.415985] usercopy_abort+0x70/0xa0 [ 99.416227] __check_heap_object+0x134/0x158 [ 99.416505] check_heap_object+0x150/0x188 [ 99.416696] __check_object_size.part.0+0x78/0x168 [ 99.416886] __check_object_size+0x28/0x40 [ 99.417078] listxattr+0x8c/0x120 [ 99.417252] path_listxattr+0x78/0xe0 [ 99.417476] __arm64_sys_listxattr+0x28/0x40 [ 99.417723] invoke_syscall+0x78/0x100 [ 99.417929] el0_svc_common.constprop.0+0x48/0xf0 [ 99.418186] do_el0_svc+0x24/0x38 [ 99.418376] el0_svc+0x3c/0x110 [ 99.418554] el0t_64_sync_handler+0x120/0x130 [ 99.418788] el0t_64_sync+0x194/0x198 [ 99.418994] Code: aa0003e3 d000a3e0 91310000 97f49bdb (d4210000)
Issue is reproduced when generic_listxattr() returns 'system.nfs4_acl', thus calling lisxattr() with size = 16 will trigger the bug.
Add check on nfs4_listxattr() to return ERANGE error when it is called with size > 0 and the return value is greater than size.(CVE-2024-26870)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/srpt: Do not register event handler until srpt device is fully setup
Upon rare occasions, KASAN reports a use-after-free Write in srpt_refresh_port().
This seems to be because an event handler is registered before the srpt device is fully setup and a race condition upon error may leave a partially setup event handler in place.
Instead, only register the event handler after srpt device initialization is complete.(CVE-2024-26872)
In the Linux kernel, the following vulnerability has been resolved:
media: pvrusb2: fix uaf in pvr2_context_set_notify
[Syzbot reported] BUG: KASAN: slab-use-after-free in pvr2_context_set_notify+0x2c4/0x310 drivers/media/usb/pvrusb2/pvrusb2-context.c:35 Read of size 4 at addr ffff888113aeb0d8 by task kworker/1:1/26
CPU: 1 PID: 26 Comm: kworker/1:1 Not tainted 6.8.0-rc1-syzkaller-00046-gf1a27f081c1f #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024 Workqueue: usb_hub_wq hub_event Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd9/0x1b0 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc4/0x620 mm/kasan/report.c:488 kasan_report+0xda/0x110 mm/kasan/report.c:601 pvr2_context_set_notify+0x2c4/0x310 drivers/media/usb/pvrusb2/pvrusb2-context.c:35 pvr2_context_notify drivers/media/usb/pvrusb2/pvrusb2-context.c:95 [inline] pvr2_context_disconnect+0x94/0xb0 drivers/media/usb/pvrusb2/pvrusb2-context.c:272
Freed by task 906: kasan_save_stack+0x33/0x50 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 kasan_save_free_info+0x3f/0x60 mm/kasan/generic.c:640 poison_slab_object mm/kasan/common.c:241 [inline] __kasan_slab_free+0x106/0x1b0 mm/kasan/common.c:257 kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2121 [inline] slab_free mm/slub.c:4299 [inline] kfree+0x105/0x340 mm/slub.c:4409 pvr2_context_check drivers/media/usb/pvrusb2/pvrusb2-context.c:137 [inline] pvr2_context_thread_func+0x69d/0x960 drivers/media/usb/pvrusb2/pvrusb2-context.c:158
[Analyze] Task A set disconnect_flag = !0, which resulted in Task B's condition being met and releasing mp, leading to this issue.
[Fix] Place the disconnect_flag assignment operation after all code in pvr2_context_disconnect() to avoid this issue.(CVE-2024-26875)
In the Linux kernel, the following vulnerability has been resolved:
quota: Fix potential NULL pointer dereference
Below race may cause NULL pointer dereference
P1 P2 dquot_free_inode quota_off drop_dquot_ref remove_dquot_ref dquots = i_dquot(inode) dquots = i_dquot(inode) srcu_read_lock dquots[cnt]) != NULL (1) dquots[type] = NULL (2) spin_lock(&dquots[cnt]->dq_dqb_lock) (3) ....
If dquot_free_inode(or other routines) checks inode's quota pointers (1) before quota_off sets it to NULL(2) and use it (3) after that, NULL pointer dereference will be triggered.
So let's fix it by using a temporary pointer to avoid this issue.(CVE-2024-26878)
In the Linux kernel, the following vulnerability has been resolved:
dm: call the resume method on internal suspend
There is this reported crash when experimenting with the lvm2 testsuite. The list corruption is caused by the fact that the postsuspend and resume methods were not paired correctly; there were two consecutive calls to the origin_postsuspend function. The second call attempts to remove the "hash_list" entry from a list, while it was already removed by the first call.
Fix __dm_internal_resume so that it calls the preresume and resume methods of the table's targets.
If a preresume method of some target fails, we are in a tricky situation. We can't return an error because dm_internal_resume isn't supposed to return errors. We can't return success, because then the "resume" and "postsuspend" methods would not be paired correctly. So, we set the DMF_SUSPENDED flag and we fake normal suspend - it may confuse userspace tools, but it won't cause a kernel crash.
------------[ cut here ]------------ kernel BUG at lib/list_debug.c:56! invalid opcode: 0000 [#1] PREEMPT SMP CPU: 1 PID: 8343 Comm: dmsetup Not tainted 6.8.0-rc6 #4 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 RIP: 0010:__list_del_entry_valid_or_report+0x77/0xc0 <snip> RSP: 0018:ffff8881b831bcc0 EFLAGS: 00010282 RAX: 000000000000004e RBX: ffff888143b6eb80 RCX: 0000000000000000 RDX: 0000000000000001 RSI: ffffffff819053d0 RDI: 00000000ffffffff RBP: ffff8881b83a3400 R08: 00000000fffeffff R09: 0000000000000058 R10: 0000000000000000 R11: ffffffff81a24080 R12: 0000000000000001 R13: ffff88814538e000 R14: ffff888143bc6dc0 R15: ffffffffa02e4bb0 FS: 00000000f7c0f780(0000) GS:ffff8893f0a40000(0000) knlGS:0000000000000000 CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033 CR2: 0000000057fb5000 CR3: 0000000143474000 CR4: 00000000000006b0 Call Trace: <TASK> ? die+0x2d/0x80 ? do_trap+0xeb/0xf0 ? __list_del_entry_valid_or_report+0x77/0xc0 ? do_error_trap+0x60/0x80 ? __list_del_entry_valid_or_report+0x77/0xc0 ? exc_invalid_op+0x49/0x60 ? __list_del_entry_valid_or_report+0x77/0xc0 ? asm_exc_invalid_op+0x16/0x20 ? table_deps+0x1b0/0x1b0 [dm_mod] ? __list_del_entry_valid_or_report+0x77/0xc0 origin_postsuspend+0x1a/0x50 [dm_snapshot] dm_table_postsuspend_targets+0x34/0x50 [dm_mod] dm_suspend+0xd8/0xf0 [dm_mod] dev_suspend+0x1f2/0x2f0 [dm_mod] ? table_deps+0x1b0/0x1b0 [dm_mod] ctl_ioctl+0x300/0x5f0 [dm_mod] dm_compat_ctl_ioctl+0x7/0x10 [dm_mod] __x64_compat_sys_ioctl+0x104/0x170 do_syscall_64+0x184/0x1b0 entry_SYSCALL_64_after_hwframe+0x46/0x4e RIP: 0033:0xf7e6aead <snip> ---[ end trace 0000000000000000 ]---(CVE-2024-26880)
In the Linux kernel, the following vulnerability has been resolved:
firmware: arm_scmi: Fix double free in SMC transport cleanup path
When the generic SCMI code tears down a channel, it calls the chan_free callback function, defined by each transport. Since multiple protocols might share the same transport_info member, chan_free() might want to clean up the same member multiple times within the given SCMI transport implementation. In this case, it is SMC transport. This will lead to a NULL pointer dereference at the second time:
| scmi_protocol scmi_dev.1: Enabled polling mode TX channel - prot_id:16
| arm-scmi firmware:scmi: SCMI Notifications - Core Enabled.
| arm-scmi firmware:scmi: unable to communicate with SCMI
| Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
| Mem abort info:
| ESR = 0x0000000096000004
| EC = 0x25: DABT (current EL), IL = 32 bits
| SET = 0, FnV = 0
| EA = 0, S1PTW = 0
| FSC = 0x04: level 0 translation fault
| Data abort info:
| ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
| CM = 0, WnR = 0, TnD = 0, TagAccess = 0
| GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
| user pgtable: 4k pages, 48-bit VAs, pgdp=0000000881ef8000
| [0000000000000000] pgd=0000000000000000, p4d=0000000000000000
| Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP
| Modules linked in:
| CPU: 4 PID: 1 Comm: swapper/0 Not tainted 6.7.0-rc2-00124-g455ef3d016c9-dirty #793
| Hardware name: FVP Base RevC (DT)
| pstate: 61400009 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
| pc : smc_chan_free+0x3c/0x6c
| lr : smc_chan_free+0x3c/0x6c
| Call trace:
| smc_chan_free+0x3c/0x6c
| idr_for_each+0x68/0xf8
| scmi_cleanup_channels.isra.0+0x2c/0x58
| scmi_probe+0x434/0x734
| platform_probe+0x68/0xd8
| really_probe+0x110/0x27c
| __driver_probe_device+0x78/0x12c
| driver_probe_device+0x3c/0x118
| __driver_attach+0x74/0x128
| bus_for_each_dev+0x78/0xe0
| driver_attach+0x24/0x30
| bus_add_driver+0xe4/0x1e8
| driver_register+0x60/0x128
| __platform_driver_register+0x28/0x34
| scmi_driver_init+0x84/0xc0
| do_one_initcall+0x78/0x33c
| kernel_init_freeable+0x2b8/0x51c
| kernel_init+0x24/0x130
| ret_from_fork+0x10/0x20
| Code: f0004701 910a0021 aa1403e5 97b91c70 (b9400280)
| ---[ end trace 0000000000000000 ]---
Simply check for the struct pointer being NULL before trying to access its members, to avoid this situation.
This was found when a transport doesn't really work (for instance no SMC service), the probe routines then tries to clean up, and triggers a crash.(CVE-2024-26893)
In the Linux kernel, the following vulnerability has been resolved:
wifi: wilc1000: prevent use-after-free on vif when cleaning up all interfaces
wilc_netdev_cleanup currently triggers a KASAN warning, which can be observed on interface registration error path, or simply by removing the module/unbinding device from driver:
echo spi0.1 > /sys/bus/spi/drivers/wilc1000_spi/unbind
================================================================== BUG: KASAN: slab-use-after-free in wilc_netdev_cleanup+0x508/0x5cc Read of size 4 at addr c54d1ce8 by task sh/86
CPU: 0 PID: 86 Comm: sh Not tainted 6.8.0-rc1+ #117 Hardware name: Atmel SAMA5 unwind_backtrace from show_stack+0x18/0x1c show_stack from dump_stack_lvl+0x34/0x58 dump_stack_lvl from print_report+0x154/0x500 print_report from kasan_report+0xac/0xd8 kasan_report from wilc_netdev_cleanup+0x508/0x5cc wilc_netdev_cleanup from wilc_bus_remove+0xc8/0xec wilc_bus_remove from spi_remove+0x8c/0xac spi_remove from device_release_driver_internal+0x434/0x5f8 device_release_driver_internal from unbind_store+0xbc/0x108 unbind_store from kernfs_fop_write_iter+0x398/0x584 kernfs_fop_write_iter from vfs_write+0x728/0xf88 vfs_write from ksys_write+0x110/0x1e4 ksys_write from ret_fast_syscall+0x0/0x1c
[...]
Allocated by task 1: kasan_save_track+0x30/0x5c __kasan_kmalloc+0x8c/0x94 __kmalloc_node+0x1cc/0x3e4 kvmalloc_node+0x48/0x180 alloc_netdev_mqs+0x68/0x11dc alloc_etherdev_mqs+0x28/0x34 wilc_netdev_ifc_init+0x34/0x8ec wilc_cfg80211_init+0x690/0x910 wilc_bus_probe+0xe0/0x4a0 spi_probe+0x158/0x1b0 really_probe+0x270/0xdf4 __driver_probe_device+0x1dc/0x580 driver_probe_device+0x60/0x140 __driver_attach+0x228/0x5d4 bus_for_each_dev+0x13c/0x1a8 bus_add_driver+0x2a0/0x608 driver_register+0x24c/0x578 do_one_initcall+0x180/0x310 kernel_init_freeable+0x424/0x484 kernel_init+0x20/0x148 ret_from_fork+0x14/0x28
Freed by task 86: kasan_save_track+0x30/0x5c kasan_save_free_info+0x38/0x58 __kasan_slab_free+0xe4/0x140 kfree+0xb0/0x238 device_release+0xc0/0x2a8 kobject_put+0x1d4/0x46c netdev_run_todo+0x8fc/0x11d0 wilc_netdev_cleanup+0x1e4/0x5cc wilc_bus_remove+0xc8/0xec spi_remove+0x8c/0xac device_release_driver_internal+0x434/0x5f8 unbind_store+0xbc/0x108 kernfs_fop_write_iter+0x398/0x584 vfs_write+0x728/0xf88 ksys_write+0x110/0x1e4 ret_fast_syscall+0x0/0x1c [...]
David Mosberger-Tan initial investigation [1] showed that this use-after-free is due to netdevice unregistration during vif list traversal. When unregistering a net device, since the needs_free_netdev has been set to true during registration, the netdevice object is also freed, and as a consequence, the corresponding vif object too, since it is attached to it as private netdevice data. The next occurrence of the loop then tries to access freed vif pointer to the list to move forward in the list.
Fix this use-after-free thanks to two mechanisms: - navigate in the list with list_for_each_entry_safe, which allows to safely modify the list as we go through each element. For each element, remove it from the list with list_del_rcu - make sure to wait for RCU grace period end after each vif removal to make sure it is safe to free the corresponding vif too (through unregister_netdev)
Since we are in a RCU "modifier" path (not a "reader" path), and because such path is expected not to be concurrent to any other modifier (we are using the vif_mutex lock), we do not need to use RCU list API, that's why we can benefit from list_for_each_entry_safe.
[1] https://lore.kernel.org/linux-wireless/ab077dbe58b1ea5de0a3b2ca21f275a07af967d2.camel@egauge.net/(CVE-2024-26895)
In the Linux kernel, the following vulnerability has been resolved:
wifi: wfx: fix memory leak when starting AP
Kmemleak reported this error:
unreferenced object 0xd73d1180 (size 184):
comm "wpa_supplicant", pid 1559, jiffies 13006305 (age 964.245s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 1e 00 01 00 00 00 00 00 ................
backtrace:
[<5ca11420>] kmem_cache_alloc+0x20c/0x5ac
[<127bdd74>] __alloc_skb+0x144/0x170
[<fb8a5e38>] __netdev_alloc_skb+0x50/0x180
[<0f9fa1d5>] __ieee80211_beacon_get+0x290/0x4d4 [mac80211]
[<7accd02d>] ieee80211_beacon_get_tim+0x54/0x18c [mac80211]
[<41e25cc3>] wfx_start_ap+0xc8/0x234 [wfx]
[<93a70356>] ieee80211_start_ap+0x404/0x6b4 [mac80211]
[<a4a661cd>] nl80211_start_ap+0x76c/0x9e0 [cfg80211]
[<47bd8b68>] genl_rcv_msg+0x198/0x378
[<453ef796>] netlink_rcv_skb+0xd0/0x130
[<6b7c977a>] genl_rcv+0x34/0x44
[<66b2d04d>] netlink_unicast+0x1b4/0x258
[<f965b9b6>] netlink_sendmsg+0x1e8/0x428
[<aadb8231>] ____sys_sendmsg+0x1e0/0x274
[<d2b5212d>] ___sys_sendmsg+0x80/0xb4
[<69954f45>] __sys_sendmsg+0x64/0xa8
unreferenced object 0xce087000 (size 1024):
comm "wpa_supplicant", pid 1559, jiffies 13006305 (age 964.246s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
10 00 07 40 00 00 00 00 00 00 00 00 00 00 00 00 ...@............
backtrace:
[<9a993714>] __kmalloc_track_caller+0x230/0x600
[<f83ea192>] kmalloc_reserve.constprop.0+0x30/0x74
[<a2c61343>] __alloc_skb+0xa0/0x170
[<fb8a5e38>] __netdev_alloc_skb+0x50/0x180
[<0f9fa1d5>] __ieee80211_beacon_get+0x290/0x4d4 [mac80211]
[<7accd02d>] ieee80211_beacon_get_tim+0x54/0x18c [mac80211]
[<41e25cc3>] wfx_start_ap+0xc8/0x234 [wfx]
[<93a70356>] ieee80211_start_ap+0x404/0x6b4 [mac80211]
[<a4a661cd>] nl80211_start_ap+0x76c/0x9e0 [cfg80211]
[<47bd8b68>] genl_rcv_msg+0x198/0x378
[<453ef796>] netlink_rcv_skb+0xd0/0x130
[<6b7c977a>] genl_rcv+0x34/0x44
[<66b2d04d>] netlink_unicast+0x1b4/0x258
[<f965b9b6>] netlink_sendmsg+0x1e8/0x428
[<aadb8231>] ____sys_sendmsg+0x1e0/0x274
[<d2b5212d>] ___sys_sendmsg+0x80/0xb4
However, since the kernel is build optimized, it seems the stack is not accurate. It appears the issue is related to wfx_set_mfp_ap(). The issue is obvious in this function: memory allocated by ieee80211_beacon_get() is never released. Fixing this leak makes kmemleak happy.(CVE-2024-26896)
In the Linux kernel, the following vulnerability has been resolved:
wifi: ath9k: delay all of ath9k_wmi_event_tasklet() until init is complete
The ath9k_wmi_event_tasklet() used in ath9k_htc assumes that all the data structures have been fully initialised by the time it runs. However, because of the order in which things are initialised, this is not guaranteed to be the case, because the device is exposed to the USB subsystem before the ath9k driver initialisation is completed.
We already committed a partial fix for this in commit: 8b3046abc99e ("ath9k_htc: fix NULL pointer dereference at ath9k_htc_tx_get_packet()")
However, that commit only aborted the WMI_TXSTATUS_EVENTID command in the event tasklet, pairing it with an "initialisation complete" bit in the TX struct. It seems syzbot managed to trigger the race for one of the other commands as well, so let's just move the existing synchronisation bit to cover the whole tasklet (setting it at the end of ath9k_htc_probe_device() instead of inside ath9k_tx_init()).(CVE-2024-26897)
In the Linux kernel, the following vulnerability has been resolved:
scsi: Revert "scsi: fcoe: Fix potential deadlock on &fip->ctlr_lock"
This reverts commit 1a1975551943f681772720f639ff42fbaa746212.
This commit causes interrupts to be lost for FCoE devices, since it changed sping locks from "bh" to "irqsave".
Instead, a work queue should be used, and will be addressed in a separate commit.(CVE-2024-26917)
In the Linux kernel, the following vulnerability has been resolved:
inet: inet_defrag: prevent sk release while still in use
ip_local_out() and other functions can pass skb->sk as function argument.
If the skb is a fragment and reassembly happens before such function call returns, the sk must not be released.
This affects skb fragments reassembled via netfilter or similar modules, e.g. openvswitch or ct_act.c, when run as part of tx pipeline.
Eric Dumazet made an initial analysis of this bug. Quoting Eric: Calling ip_defrag() in output path is also implying skb_orphan(), which is buggy because output path relies on sk not disappearing.
A relevant old patch about the issue was : 8282f27449bf ("inet: frag: Always orphan skbs inside ip_defrag()")
[..]
net/ipv4/ip_output.c depends on skb->sk being set, and probably to an inet socket, not an arbitrary one.
If we orphan the packet in ipvlan, then downstream things like FQ packet scheduler will not work properly.
We need to change ip_defrag() to only use skb_orphan() when really needed, ie whenever frag_list is going to be used.
Eric suggested to stash sk in fragment queue and made an initial patch. However there is a problem with this:
If skb is refragmented again right after, ip_do_fragment() will copy head->sk to the new fragments, and sets up destructor to sock_wfree. IOW, we have no choice but to fix up sk_wmem accouting to reflect the fully reassembled skb, else wmem will underflow.
This change moves the orphan down into the core, to last possible moment. As ip_defrag_offset is aliased with sk_buff->sk member, we must move the offset into the FRAG_CB, else skb->sk gets clobbered.
This allows to delay the orphaning long enough to learn if the skb has to be queued or if the skb is completing the reasm queue.
In the former case, things work as before, skb is orphaned. This is safe because skb gets queued/stolen and won't continue past reasm engine.
In the latter case, we will steal the skb->sk reference, reattach it to the head skb, and fix up wmem accouting when inet_frag inflates truesize.(CVE-2024-26921)
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: validate the parameters of bo mapping operations more clearly
Verify the parameters of amdgpu_vm_bo_(map/replace_map/clearing_mappings) in one common place.(CVE-2024-26922)
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"kernel-devel-5.10.0-199.0.0.112.oe2203sp3.aarch64.rpm",
"kernel-tools-5.10.0-199.0.0.112.oe2203sp3.aarch64.rpm",
"kernel-tools-devel-5.10.0-199.0.0.112.oe2203sp3.aarch64.rpm",
"perf-debuginfo-5.10.0-199.0.0.112.oe2203sp3.aarch64.rpm",
"kernel-5.10.0-199.0.0.112.oe2203sp3.aarch64.rpm",
"kernel-tools-debuginfo-5.10.0-199.0.0.112.oe2203sp3.aarch64.rpm",
"kernel-headers-5.10.0-199.0.0.112.oe2203sp3.aarch64.rpm",
"kernel-debugsource-5.10.0-199.0.0.112.oe2203sp3.aarch64.rpm",
"python3-perf-5.10.0-199.0.0.112.oe2203sp3.aarch64.rpm",
"kernel-source-5.10.0-199.0.0.112.oe2203sp3.aarch64.rpm",
"perf-5.10.0-199.0.0.112.oe2203sp3.aarch64.rpm",
"kernel-debuginfo-5.10.0-199.0.0.112.oe2203sp3.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-199.0.0.112.oe2203sp3.aarch64.rpm"
],
"src": [
"kernel-5.10.0-199.0.0.112.oe2203sp3.src.rpm"
],
"x86_64": [
"kernel-tools-debuginfo-5.10.0-199.0.0.112.oe2203sp3.x86_64.rpm",
"python3-perf-5.10.0-199.0.0.112.oe2203sp3.x86_64.rpm",
"python3-perf-debuginfo-5.10.0-199.0.0.112.oe2203sp3.x86_64.rpm",
"kernel-debugsource-5.10.0-199.0.0.112.oe2203sp3.x86_64.rpm",
"perf-5.10.0-199.0.0.112.oe2203sp3.x86_64.rpm",
"kernel-tools-5.10.0-199.0.0.112.oe2203sp3.x86_64.rpm",
"kernel-tools-devel-5.10.0-199.0.0.112.oe2203sp3.x86_64.rpm",
"kernel-source-5.10.0-199.0.0.112.oe2203sp3.x86_64.rpm",
"kernel-devel-5.10.0-199.0.0.112.oe2203sp3.x86_64.rpm",
"kernel-debuginfo-5.10.0-199.0.0.112.oe2203sp3.x86_64.rpm",
"kernel-headers-5.10.0-199.0.0.112.oe2203sp3.x86_64.rpm",
"perf-debuginfo-5.10.0-199.0.0.112.oe2203sp3.x86_64.rpm",
"kernel-5.10.0-199.0.0.112.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-199.0.0.112.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\nfirmware: arm_scmi: Harden accesses to the reset domains\r\n\r\nAccessing reset domains descriptors by the index upon the SCMI drivers\nrequests through the SCMI reset operations interface can potentially\nlead to out-of-bound violations if the SCMI driver misbehave.\r\n\r\nAdd an internal consistency check before any such domains descriptors\naccesses.(CVE-2022-48655)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nerofs: fix pcluster use-after-free on UP platforms\r\n\r\nDuring stress testing with CONFIG_SMP disabled, KASAN reports as below:\r\n\r\n==================================================================\nBUG: KASAN: use-after-free in __mutex_lock+0xe5/0xc30\nRead of size 8 at addr ffff8881094223f8 by task stress/7789\r\n\r\nCPU: 0 PID: 7789 Comm: stress Not tainted 6.0.0-rc1-00002-g0d53d2e882f9 #3\nHardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011\nCall Trace:\n \u0026lt;TASK\u0026gt;\n..\n __mutex_lock+0xe5/0xc30\n..\n z_erofs_do_read_page+0x8ce/0x1560\n..\n z_erofs_readahead+0x31c/0x580\n..\nFreed by task 7787\n kasan_save_stack+0x1e/0x40\n kasan_set_track+0x20/0x30\n kasan_set_free_info+0x20/0x40\n __kasan_slab_free+0x10c/0x190\n kmem_cache_free+0xed/0x380\n rcu_core+0x3d5/0xc90\n __do_softirq+0x12d/0x389\r\n\r\nLast potentially related work creation:\n kasan_save_stack+0x1e/0x40\n __kasan_record_aux_stack+0x97/0xb0\n call_rcu+0x3d/0x3f0\n erofs_shrink_workstation+0x11f/0x210\n erofs_shrink_scan+0xdc/0x170\n shrink_slab.constprop.0+0x296/0x530\n drop_slab+0x1c/0x70\n drop_caches_sysctl_handler+0x70/0x80\n proc_sys_call_handler+0x20a/0x2f0\n vfs_write+0x555/0x6c0\n ksys_write+0xbe/0x160\n do_syscall_64+0x3b/0x90\r\n\r\nThe root cause is that erofs_workgroup_unfreeze() doesn\u0026apos;t reset to\norig_val thus it causes a race that the pcluster reuses unexpectedly\nbefore freeing.\r\n\r\nSince UP platforms are quite rare now, such path becomes unnecessary.\nLet\u0026apos;s drop such specific-designed path directly instead.(CVE-2022-48674)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: hub: Guard against accesses to uninitialized BOS descriptors\r\n\r\nMany functions in drivers/usb/core/hub.c and drivers/usb/core/hub.h\naccess fields inside udev-\u0026gt;bos without checking if it was allocated and\ninitialized. If usb_get_bos_descriptor() fails for whatever\nreason, udev-\u0026gt;bos will be NULL and those accesses will result in a\ncrash:\r\n\r\nBUG: kernel NULL pointer dereference, address: 0000000000000018\nPGD 0 P4D 0\nOops: 0000 [#1] PREEMPT SMP NOPTI\nCPU: 5 PID: 17818 Comm: kworker/5:1 Tainted: G W 5.15.108-18910-gab0e1cb584e1 #1 \u0026lt;HASH:1f9e 1\u0026gt;\nHardware name: Google Kindred/Kindred, BIOS Google_Kindred.12672.413.0 02/03/2021\nWorkqueue: usb_hub_wq hub_event\nRIP: 0010:hub_port_reset+0x193/0x788\nCode: 89 f7 e8 20 f7 15 00 48 8b 43 08 80 b8 96 03 00 00 03 75 36 0f b7 88 92 03 00 00 81 f9 10 03 00 00 72 27 48 8b 80 a8 03 00 00 \u0026lt;48\u0026gt; 83 78 18 00 74 19 48 89 df 48 8b 75 b0 ba 02 00 00 00 4c 89 e9\nRSP: 0018:ffffab740c53fcf8 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: ffffa1bc5f678000 RCX: 0000000000000310\nRDX: fffffffffffffdff RSI: 0000000000000286 RDI: ffffa1be9655b840\nRBP: ffffab740c53fd70 R08: 00001b7d5edaa20c R09: ffffffffb005e060\nR10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000\nR13: ffffab740c53fd3e R14: 0000000000000032 R15: 0000000000000000\nFS: 0000000000000000(0000) GS:ffffa1be96540000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000018 CR3: 000000022e80c005 CR4: 00000000003706e0\nCall Trace:\nhub_event+0x73f/0x156e\n? hub_activate+0x5b7/0x68f\nprocess_one_work+0x1a2/0x487\nworker_thread+0x11a/0x288\nkthread+0x13a/0x152\n? process_one_work+0x487/0x487\n? kthread_associate_blkcg+0x70/0x70\nret_from_fork+0x1f/0x30\r\n\r\nFall back to a default behavior if the BOS descriptor isn\u0026apos;t accessible\nand skip all the functionalities that depend on it: LPM support checks,\nSuper Speed capabilitiy checks, U1/U2 states setup.(CVE-2023-52477)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nf_tables: disallow timeout for anonymous sets\r\n\r\nNever used from userspace, disallow these parameters.(CVE-2023-52620)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nftables: exthdr: fix 4-byte stack OOB write\r\n\r\nIf priv-\u0026gt;len is a multiple of 4, then dst[len / 4] can write past\nthe destination array which leads to stack corruption.\r\n\r\nThis construct is necessary to clean the remainder of the register\nin case -\u0026gt;len is NOT a multiple of the register size, so make it\nconditional just like nft_payload.c does.\r\n\r\nThe bug was added in 4.1 cycle and then copied/inherited when\ntcp/sctp and ip option support was added.\r\n\r\nBug reported by Zero Day Initiative project (ZDI-CAN-21950,\nZDI-CAN-21951, ZDI-CAN-21961).(CVE-2023-52628)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfs/ntfs3: Fix an NULL dereference bug\r\n\r\nThe issue here is when this is called from ntfs_load_attr_list(). The\n\u0026quot;size\u0026quot; comes from le32_to_cpu(attr-\u0026gt;res.data_size) so it can\u0026apos;t overflow\non a 64bit systems but on 32bit systems the \u0026quot;+ 1023\u0026quot; can overflow and\nthe result is zero. This means that the kmalloc will succeed by\nreturning the ZERO_SIZE_PTR and then the memcpy() will crash with an\nOops on the next line.(CVE-2023-52631)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\num: time-travel: fix time corruption\r\n\r\nIn \u0026apos;basic\u0026apos; time-travel mode (without =inf-cpu or =ext), we\nstill get timer interrupts. These can happen at arbitrary\npoints in time, i.e. while in timer_read(), which pushes\ntime forward just a little bit. Then, if we happen to get\nthe interrupt after calculating the new time to push to,\nbut before actually finishing that, the interrupt will set\nthe time to a value that\u0026apos;s incompatible with the forward,\nand we\u0026apos;ll crash because time goes backwards when we do the\nforwarding.\r\n\r\nFix this by reading the time_travel_time, calculating the\nadjustment, and doing the adjustment all with interrupts\ndisabled.(CVE-2023-52633)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncan: j1939: Fix UAF in j1939_sk_match_filter during setsockopt(SO_J1939_FILTER)\r\n\r\nLock jsk-\u0026gt;sk to prevent UAF when setsockopt(..., SO_J1939_FILTER, ...)\nmodifies jsk-\u0026gt;filters while receiving packets.\r\n\r\nFollowing trace was seen on affected system:\n ==================================================================\n BUG: KASAN: slab-use-after-free in j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939]\n Read of size 4 at addr ffff888012144014 by task j1939/350\r\n\r\n CPU: 0 PID: 350 Comm: j1939 Tainted: G W OE 6.5.0-rc5 #1\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014\n Call Trace:\n print_report+0xd3/0x620\n ? kasan_complete_mode_report_info+0x7d/0x200\n ? j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939]\n kasan_report+0xc2/0x100\n ? j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939]\n __asan_load4+0x84/0xb0\n j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939]\n j1939_sk_recv+0x20b/0x320 [can_j1939]\n ? __kasan_check_write+0x18/0x20\n ? __pfx_j1939_sk_recv+0x10/0x10 [can_j1939]\n ? j1939_simple_recv+0x69/0x280 [can_j1939]\n ? j1939_ac_recv+0x5e/0x310 [can_j1939]\n j1939_can_recv+0x43f/0x580 [can_j1939]\n ? __pfx_j1939_can_recv+0x10/0x10 [can_j1939]\n ? raw_rcv+0x42/0x3c0 [can_raw]\n ? __pfx_j1939_can_recv+0x10/0x10 [can_j1939]\n can_rcv_filter+0x11f/0x350 [can]\n can_receive+0x12f/0x190 [can]\n ? __pfx_can_rcv+0x10/0x10 [can]\n can_rcv+0xdd/0x130 [can]\n ? __pfx_can_rcv+0x10/0x10 [can]\n __netif_receive_skb_one_core+0x13d/0x150\n ? __pfx___netif_receive_skb_one_core+0x10/0x10\n ? __kasan_check_write+0x18/0x20\n ? _raw_spin_lock_irq+0x8c/0xe0\n __netif_receive_skb+0x23/0xb0\n process_backlog+0x107/0x260\n __napi_poll+0x69/0x310\n net_rx_action+0x2a1/0x580\n ? __pfx_net_rx_action+0x10/0x10\n ? __pfx__raw_spin_lock+0x10/0x10\n ? handle_irq_event+0x7d/0xa0\n __do_softirq+0xf3/0x3f8\n do_softirq+0x53/0x80\n \u0026lt;/IRQ\u0026gt;\n \u0026lt;TASK\u0026gt;\n __local_bh_enable_ip+0x6e/0x70\n netif_rx+0x16b/0x180\n can_send+0x32b/0x520 [can]\n ? __pfx_can_send+0x10/0x10 [can]\n ? __check_object_size+0x299/0x410\n raw_sendmsg+0x572/0x6d0 [can_raw]\n ? __pfx_raw_sendmsg+0x10/0x10 [can_raw]\n ? apparmor_socket_sendmsg+0x2f/0x40\n ? __pfx_raw_sendmsg+0x10/0x10 [can_raw]\n sock_sendmsg+0xef/0x100\n sock_write_iter+0x162/0x220\n ? __pfx_sock_write_iter+0x10/0x10\n ? __rtnl_unlock+0x47/0x80\n ? security_file_permission+0x54/0x320\n vfs_write+0x6ba/0x750\n ? __pfx_vfs_write+0x10/0x10\n ? __fget_light+0x1ca/0x1f0\n ? __rcu_read_unlock+0x5b/0x280\n ksys_write+0x143/0x170\n ? __pfx_ksys_write+0x10/0x10\n ? __kasan_check_read+0x15/0x20\n ? fpregs_assert_state_consistent+0x62/0x70\n __x64_sys_write+0x47/0x60\n do_syscall_64+0x60/0x90\n ? do_syscall_64+0x6d/0x90\n ? irqentry_exit+0x3f/0x50\n ? exc_page_fault+0x79/0xf0\n entry_SYSCALL_64_after_hwframe+0x6e/0xd8\r\n\r\n Allocated by task 348:\n kasan_save_stack+0x2a/0x50\n kasan_set_track+0x29/0x40\n kasan_save_alloc_info+0x1f/0x30\n __kasan_kmalloc+0xb5/0xc0\n __kmalloc_node_track_caller+0x67/0x160\n j1939_sk_setsockopt+0x284/0x450 [can_j1939]\n __sys_setsockopt+0x15c/0x2f0\n __x64_sys_setsockopt+0x6b/0x80\n do_syscall_64+0x60/0x90\n entry_SYSCALL_64_after_hwframe+0x6e/0xd8\r\n\r\n Freed by task 349:\n kasan_save_stack+0x2a/0x50\n kasan_set_track+0x29/0x40\n kasan_save_free_info+0x2f/0x50\n __kasan_slab_free+0x12e/0x1c0\n __kmem_cache_free+0x1b9/0x380\n kfree+0x7a/0x120\n j1939_sk_setsockopt+0x3b2/0x450 [can_j1939]\n __sys_setsockopt+0x15c/0x2f0\n __x64_sys_setsockopt+0x6b/0x80\n do_syscall_64+0x60/0x90\n entry_SYSCALL_64_after_hwframe+0x6e/0xd8(CVE-2023-52637)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nKVM: s390: vsie: fix race during shadow creation\r\n\r\nRight now it is possible to see gmap-\u0026gt;private being zero in\nkvm_s390_vsie_gmap_notifier resulting in a crash. This is due to the\nfact that we add gmap-\u0026gt;private == kvm after creation:\r\n\r\nstatic int acquire_gmap_shadow(struct kvm_vcpu *vcpu,\n struct vsie_page *vsie_page)\n{\n[...]\n gmap = gmap_shadow(vcpu-\u0026gt;arch.gmap, asce, edat);\n if (IS_ERR(gmap))\n return PTR_ERR(gmap);\n gmap-\u0026gt;private = vcpu-\u0026gt;kvm;\r\n\r\nLet children inherit the private field of the parent.(CVE-2023-52639)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: rc: bpf attach/detach requires write permission\r\n\r\nNote that bpf attach/detach also requires CAP_NET_ADMIN.(CVE-2023-52642)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: b43: Stop/wake correct queue in DMA Tx path when QoS is disabled\r\n\r\nWhen QoS is disabled, the queue priority value will not map to the correct\nieee80211 queue since there is only one queue. Stop/wake queue 0 when QoS\nis disabled to prevent trying to stop/wake a non-existent queue and failing\nto stop/wake the actual queue instantiated.\r\n\r\nLog of issue before change (with kernel parameter qos=0):\n [ +5.112651] ------------[ cut here ]------------\n [ +0.000005] WARNING: CPU: 7 PID: 25513 at net/mac80211/util.c:449 __ieee80211_wake_queue+0xd5/0x180 [mac80211]\n [ +0.000067] Modules linked in: b43(O) snd_seq_dummy snd_hrtimer snd_seq snd_seq_device nft_chain_nat xt_MASQUERADE nf_nat xfrm_user xfrm_algo xt_addrtype overlay ccm af_packet amdgpu snd_hda_codec_cirrus snd_hda_codec_generic ledtrig_audio drm_exec amdxcp gpu_sched xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip6t_rpfilter ipt_rpfilter xt_pkttype xt_LOG nf_log_syslog xt_tcpudp nft_compat nf_tables nfnetlink sch_fq_codel btusb uinput iTCO_wdt ctr btrtl intel_pmc_bxt i915 intel_rapl_msr mei_hdcp mei_pxp joydev at24 watchdog btintel atkbd libps2 serio radeon btbcm vivaldi_fmap btmtk intel_rapl_common snd_hda_codec_hdmi bluetooth uvcvideo nls_iso8859_1 applesmc nls_cp437 x86_pkg_temp_thermal snd_hda_intel intel_powerclamp vfat videobuf2_vmalloc coretemp fat snd_intel_dspcfg crc32_pclmul uvc polyval_clmulni snd_intel_sdw_acpi loop videobuf2_memops snd_hda_codec tun drm_suballoc_helper polyval_generic drm_ttm_helper drm_buddy tap ecdh_generic videobuf2_v4l2 gf128mul macvlan ttm ghash_clmulni_intel ecc tg3\n [ +0.000044] videodev bridge snd_hda_core rapl crc16 drm_display_helper cec mousedev snd_hwdep evdev intel_cstate bcm5974 hid_appleir videobuf2_common stp mac_hid libphy snd_pcm drm_kms_helper acpi_als mei_me intel_uncore llc mc snd_timer intel_gtt industrialio_triggered_buffer apple_mfi_fastcharge i2c_i801 mei snd lpc_ich agpgart ptp i2c_smbus thunderbolt apple_gmux i2c_algo_bit kfifo_buf video industrialio soundcore pps_core wmi tiny_power_button sbs sbshc button ac cordic bcma mac80211 cfg80211 ssb rfkill libarc4 kvm_intel kvm drm irqbypass fuse backlight firmware_class efi_pstore configfs efivarfs dmi_sysfs ip_tables x_tables autofs4 dm_crypt cbc encrypted_keys trusted asn1_encoder tee tpm rng_core input_leds hid_apple led_class hid_generic usbhid hid sd_mod t10_pi crc64_rocksoft crc64 crc_t10dif crct10dif_generic ahci libahci libata uhci_hcd ehci_pci ehci_hcd crct10dif_pclmul crct10dif_common sha512_ssse3 sha512_generic sha256_ssse3 sha1_ssse3 aesni_intel usbcore scsi_mod libaes crypto_simd cryptd scsi_common\n [ +0.000055] usb_common rtc_cmos btrfs blake2b_generic libcrc32c crc32c_generic crc32c_intel xor raid6_pq dm_snapshot dm_bufio dm_mod dax [last unloaded: b43(O)]\n [ +0.000009] CPU: 7 PID: 25513 Comm: irq/17-b43 Tainted: G W O 6.6.7 #1-NixOS\n [ +0.000003] Hardware name: Apple Inc. MacBookPro8,3/Mac-942459F5819B171B, BIOS 87.0.0.0.0 06/13/2019\n [ +0.000001] RIP: 0010:__ieee80211_wake_queue+0xd5/0x180 [mac80211]\n [ +0.000046] Code: 00 45 85 e4 0f 85 9b 00 00 00 48 8d bd 40 09 00 00 f0 48 0f ba ad 48 09 00 00 00 72 0f 5b 5d 41 5c 41 5d 41 5e e9 cb 6d 3c d0 \u0026lt;0f\u0026gt; 0b 5b 5d 41 5c 41 5d 41 5e c3 cc cc cc cc 48 8d b4 16 94 00 00\n [ +0.000002] RSP: 0018:ffffc90003c77d60 EFLAGS: 00010097\n [ +0.000001] RAX: 0000000000000001 RBX: 0000000000000002 RCX: 0000000000000000\n [ +0.000001] RDX: 0000000000000000 RSI: 0000000000000002 RDI: ffff88820b924900\n [ +0.000002] RBP: ffff88820b924900 R08: ffffc90003c77d90 R09: 000000000003bfd0\n [ +0.000001] R10: ffff88820b924900 R11: ffffc90003c77c68 R12: 0000000000000000\n [ +0.000001] R13: 0000000000000000 R14: ffffc90003c77d90 R15: ffffffffc0fa6f40\n [ +0.000001] FS: 0000000000000000(0000) GS:ffff88846fb80000(0000) knlGS:0000000000000000\n [ +0.000001] CS: 0010 DS: 0\n---truncated---(CVE-2023-52644)\r\n\r\nA flaw was found in the ATA over Ethernet (AoE) driver in the Linux kernel. The aoecmd_cfg_pkts() function improperly updates the refcnt on `struct net_device`, and a use-after-free can be triggered by racing between the free on the struct and the access through the `skbtxq` global queue. This could lead to a denial of service condition or potential code execution.(CVE-2023-6270)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nf_tables: disallow anonymous set with timeout flag\r\n\r\nAnonymous sets are never used with timeout from userspace, reject this.\nException to this rule is NFT_SET_EVAL to ensure legacy meters still work.(CVE-2024-26642)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntracing: Ensure visibility when inserting an element into tracing_map\r\n\r\nRunning the following two commands in parallel on a multi-processor\nAArch64 machine can sporadically produce an unexpected warning about\nduplicate histogram entries:\r\n\r\n $ while true; do\n echo hist:key=id.syscall:val=hitcount \u0026gt; \\\n /sys/kernel/debug/tracing/events/raw_syscalls/sys_enter/trigger\n cat /sys/kernel/debug/tracing/events/raw_syscalls/sys_enter/hist\n sleep 0.001\n done\n $ stress-ng --sysbadaddr $(nproc)\r\n\r\nThe warning looks as follows:\r\n\r\n[ 2911.172474] ------------[ cut here ]------------\n[ 2911.173111] Duplicates detected: 1\n[ 2911.173574] WARNING: CPU: 2 PID: 12247 at kernel/trace/tracing_map.c:983 tracing_map_sort_entries+0x3e0/0x408\n[ 2911.174702] Modules linked in: iscsi_ibft(E) iscsi_boot_sysfs(E) rfkill(E) af_packet(E) nls_iso8859_1(E) nls_cp437(E) vfat(E) fat(E) ena(E) tiny_power_button(E) qemu_fw_cfg(E) button(E) fuse(E) efi_pstore(E) ip_tables(E) x_tables(E) xfs(E) libcrc32c(E) aes_ce_blk(E) aes_ce_cipher(E) crct10dif_ce(E) polyval_ce(E) polyval_generic(E) ghash_ce(E) gf128mul(E) sm4_ce_gcm(E) sm4_ce_ccm(E) sm4_ce(E) sm4_ce_cipher(E) sm4(E) sm3_ce(E) sm3(E) sha3_ce(E) sha512_ce(E) sha512_arm64(E) sha2_ce(E) sha256_arm64(E) nvme(E) sha1_ce(E) nvme_core(E) nvme_auth(E) t10_pi(E) sg(E) scsi_mod(E) scsi_common(E) efivarfs(E)\n[ 2911.174738] Unloaded tainted modules: cppc_cpufreq(E):1\n[ 2911.180985] CPU: 2 PID: 12247 Comm: cat Kdump: loaded Tainted: G E 6.7.0-default #2 1b58bbb22c97e4399dc09f92d309344f69c44a01\n[ 2911.182398] Hardware name: Amazon EC2 c7g.8xlarge/, BIOS 1.0 11/1/2018\n[ 2911.183208] pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)\n[ 2911.184038] pc : tracing_map_sort_entries+0x3e0/0x408\n[ 2911.184667] lr : tracing_map_sort_entries+0x3e0/0x408\n[ 2911.185310] sp : ffff8000a1513900\n[ 2911.185750] x29: ffff8000a1513900 x28: ffff0003f272fe80 x27: 0000000000000001\n[ 2911.186600] x26: ffff0003f272fe80 x25: 0000000000000030 x24: 0000000000000008\n[ 2911.187458] x23: ffff0003c5788000 x22: ffff0003c16710c8 x21: ffff80008017f180\n[ 2911.188310] x20: ffff80008017f000 x19: ffff80008017f180 x18: ffffffffffffffff\n[ 2911.189160] x17: 0000000000000000 x16: 0000000000000000 x15: ffff8000a15134b8\n[ 2911.190015] x14: 0000000000000000 x13: 205d373432323154 x12: 5b5d313131333731\n[ 2911.190844] x11: 00000000fffeffff x10: 00000000fffeffff x9 : ffffd1b78274a13c\n[ 2911.191716] x8 : 000000000017ffe8 x7 : c0000000fffeffff x6 : 000000000057ffa8\n[ 2911.192554] x5 : ffff0012f6c24ec0 x4 : 0000000000000000 x3 : ffff2e5b72b5d000\n[ 2911.193404] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0003ff254480\n[ 2911.194259] Call trace:\n[ 2911.194626] tracing_map_sort_entries+0x3e0/0x408\n[ 2911.195220] hist_show+0x124/0x800\n[ 2911.195692] seq_read_iter+0x1d4/0x4e8\n[ 2911.196193] seq_read+0xe8/0x138\n[ 2911.196638] vfs_read+0xc8/0x300\n[ 2911.197078] ksys_read+0x70/0x108\n[ 2911.197534] __arm64_sys_read+0x24/0x38\n[ 2911.198046] invoke_syscall+0x78/0x108\n[ 2911.198553] el0_svc_common.constprop.0+0xd0/0xf8\n[ 2911.199157] do_el0_svc+0x28/0x40\n[ 2911.199613] el0_svc+0x40/0x178\n[ 2911.200048] el0t_64_sync_handler+0x13c/0x158\n[ 2911.200621] el0t_64_sync+0x1a8/0x1b0\n[ 2911.201115] ---[ end trace 0000000000000000 ]---\r\n\r\nThe problem appears to be caused by CPU reordering of writes issued from\n__tracing_map_insert().\r\n\r\nThe check for the presence of an element with a given key in this\nfunction is:\r\n\r\n val = READ_ONCE(entry-\u0026gt;val);\n if (val \u0026amp;\u0026amp; keys_match(key, val-\u0026gt;key, map-\u0026gt;key_size)) ...\r\n\r\nThe write of a new entry is:\r\n\r\n elt = get_free_elt(map);\n memcpy(elt-\u0026gt;key, key, map-\u0026gt;key_size);\n entry-\u0026gt;val = elt;\r\n\r\nThe \u0026quot;memcpy(elt-\u0026gt;key, key, map-\u0026gt;key_size);\u0026quot; and \u0026quot;entry-\u0026gt;val = elt;\u0026quot;\nstores may become visible in the reversed order on another CPU. This\nsecond CPU might then incorrectly determine that a new key doesn\u0026apos;t match\nan already present val-\u0026gt;key and subse\n---truncated---(CVE-2024-26645)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntunnels: fix out of bounds access when building IPv6 PMTU error\r\n\r\nIf the ICMPv6 error is built from a non-linear skb we get the following\nsplat,\r\n\r\n BUG: KASAN: slab-out-of-bounds in do_csum+0x220/0x240\n Read of size 4 at addr ffff88811d402c80 by task netperf/820\n CPU: 0 PID: 820 Comm: netperf Not tainted 6.8.0-rc1+ #543\n ...\n kasan_report+0xd8/0x110\n do_csum+0x220/0x240\n csum_partial+0xc/0x20\n skb_tunnel_check_pmtu+0xeb9/0x3280\n vxlan_xmit_one+0x14c2/0x4080\n vxlan_xmit+0xf61/0x5c00\n dev_hard_start_xmit+0xfb/0x510\n __dev_queue_xmit+0x7cd/0x32a0\n br_dev_queue_push_xmit+0x39d/0x6a0\r\n\r\nUse skb_checksum instead of csum_partial who cannot deal with non-linear\nSKBs.(CVE-2024-26665)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nft_limit: reject configurations that cause integer overflow\r\n\r\nReject bogus configs where internal token counter wraps around.\nThis only occurs with very very large requests, such as 17gbyte/s.\r\n\r\nIts better to reject this rather than having incorrect ratelimit.(CVE-2024-26668)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/sched: flower: Fix chain template offload\r\n\r\nWhen a qdisc is deleted from a net device the stack instructs the\nunderlying driver to remove its flow offload callback from the\nassociated filter block using the \u0026apos;FLOW_BLOCK_UNBIND\u0026apos; command. The stack\nthen continues to replay the removal of the filters in the block for\nthis driver by iterating over the chains in the block and invoking the\n\u0026apos;reoffload\u0026apos; operation of the classifier being used. In turn, the\nclassifier in its \u0026apos;reoffload\u0026apos; operation prepares and emits a\n\u0026apos;FLOW_CLS_DESTROY\u0026apos; command for each filter.\r\n\r\nHowever, the stack does not do the same for chain templates and the\nunderlying driver never receives a \u0026apos;FLOW_CLS_TMPLT_DESTROY\u0026apos; command when\na qdisc is deleted. This results in a memory leak [1] which can be\nreproduced using [2].\r\n\r\nFix by introducing a \u0026apos;tmplt_reoffload\u0026apos; operation and have the stack\ninvoke it with the appropriate arguments as part of the replay.\nImplement the operation in the sole classifier that supports chain\ntemplates (flower) by emitting the \u0026apos;FLOW_CLS_TMPLT_{CREATE,DESTROY}\u0026apos;\ncommand based on whether a flow offload callback is being bound to a\nfilter block or being unbound from one.\r\n\r\nAs far as I can tell, the issue happens since cited commit which\nreordered tcf_block_offload_unbind() before tcf_block_flush_all_chains()\nin __tcf_block_put(). The order cannot be reversed as the filter block\nis expected to be freed after flushing all the chains.\r\n\r\n[1]\nunreferenced object 0xffff888107e28800 (size 2048):\n comm \u0026quot;tc\u0026quot;, pid 1079, jiffies 4294958525 (age 3074.287s)\n hex dump (first 32 bytes):\n b1 a6 7c 11 81 88 ff ff e0 5b b3 10 81 88 ff ff ..|......[......\n 01 00 00 00 00 00 00 00 e0 aa b0 84 ff ff ff ff ................\n backtrace:\n [\u0026lt;ffffffff81c06a68\u0026gt;] __kmem_cache_alloc_node+0x1e8/0x320\n [\u0026lt;ffffffff81ab374e\u0026gt;] __kmalloc+0x4e/0x90\n [\u0026lt;ffffffff832aec6d\u0026gt;] mlxsw_sp_acl_ruleset_get+0x34d/0x7a0\n [\u0026lt;ffffffff832bc195\u0026gt;] mlxsw_sp_flower_tmplt_create+0x145/0x180\n [\u0026lt;ffffffff832b2e1a\u0026gt;] mlxsw_sp_flow_block_cb+0x1ea/0x280\n [\u0026lt;ffffffff83a10613\u0026gt;] tc_setup_cb_call+0x183/0x340\n [\u0026lt;ffffffff83a9f85a\u0026gt;] fl_tmplt_create+0x3da/0x4c0\n [\u0026lt;ffffffff83a22435\u0026gt;] tc_ctl_chain+0xa15/0x1170\n [\u0026lt;ffffffff838a863c\u0026gt;] rtnetlink_rcv_msg+0x3cc/0xed0\n [\u0026lt;ffffffff83ac87f0\u0026gt;] netlink_rcv_skb+0x170/0x440\n [\u0026lt;ffffffff83ac6270\u0026gt;] netlink_unicast+0x540/0x820\n [\u0026lt;ffffffff83ac6e28\u0026gt;] netlink_sendmsg+0x8d8/0xda0\n [\u0026lt;ffffffff83793def\u0026gt;] ____sys_sendmsg+0x30f/0xa80\n [\u0026lt;ffffffff8379d29a\u0026gt;] ___sys_sendmsg+0x13a/0x1e0\n [\u0026lt;ffffffff8379d50c\u0026gt;] __sys_sendmsg+0x11c/0x1f0\n [\u0026lt;ffffffff843b9ce0\u0026gt;] do_syscall_64+0x40/0xe0\nunreferenced object 0xffff88816d2c0400 (size 1024):\n comm \u0026quot;tc\u0026quot;, pid 1079, jiffies 4294958525 (age 3074.287s)\n hex dump (first 32 bytes):\n 40 00 00 00 00 00 00 00 57 f6 38 be 00 00 00 00 @.......W.8.....\n 10 04 2c 6d 81 88 ff ff 10 04 2c 6d 81 88 ff ff ..,m......,m....\n backtrace:\n [\u0026lt;ffffffff81c06a68\u0026gt;] __kmem_cache_alloc_node+0x1e8/0x320\n [\u0026lt;ffffffff81ab36c1\u0026gt;] __kmalloc_node+0x51/0x90\n [\u0026lt;ffffffff81a8ed96\u0026gt;] kvmalloc_node+0xa6/0x1f0\n [\u0026lt;ffffffff82827d03\u0026gt;] bucket_table_alloc.isra.0+0x83/0x460\n [\u0026lt;ffffffff82828d2b\u0026gt;] rhashtable_init+0x43b/0x7c0\n [\u0026lt;ffffffff832aed48\u0026gt;] mlxsw_sp_acl_ruleset_get+0x428/0x7a0\n [\u0026lt;ffffffff832bc195\u0026gt;] mlxsw_sp_flower_tmplt_create+0x145/0x180\n [\u0026lt;ffffffff832b2e1a\u0026gt;] mlxsw_sp_flow_block_cb+0x1ea/0x280\n [\u0026lt;ffffffff83a10613\u0026gt;] tc_setup_cb_call+0x183/0x340\n [\u0026lt;ffffffff83a9f85a\u0026gt;] fl_tmplt_create+0x3da/0x4c0\n [\u0026lt;ffffffff83a22435\u0026gt;] tc_ctl_chain+0xa15/0x1170\n [\u0026lt;ffffffff838a863c\u0026gt;] rtnetlink_rcv_msg+0x3cc/0xed0\n [\u0026lt;ffffffff83ac87f0\u0026gt;] netlink_rcv_skb+0x170/0x440\n [\u0026lt;ffffffff83ac6270\u0026gt;] netlink_unicast+0x540/0x820\n [\u0026lt;ffffffff83ac6e28\u0026gt;] netlink_sendmsg+0x8d8/0xda0\n [\u0026lt;ffffffff83793def\u0026gt;] ____sys_sendmsg+0x30f/0xa80\r\n\r\n[2]\n # tc qdisc add dev swp1 clsact\n # tc chain add dev swp1 ingress proto ip chain 1 flower dst_ip 0.0.0.0/32\n # tc qdisc del dev\n---truncated---(CVE-2024-26669)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nblk-mq: fix IO hang from sbitmap wakeup race\r\n\r\nIn blk_mq_mark_tag_wait(), __add_wait_queue() may be re-ordered\nwith the following blk_mq_get_driver_tag() in case of getting driver\ntag failure.\r\n\r\nThen in __sbitmap_queue_wake_up(), waitqueue_active() may not observe\nthe added waiter in blk_mq_mark_tag_wait() and wake up nothing, meantime\nblk_mq_mark_tag_wait() can\u0026apos;t get driver tag successfully.\r\n\r\nThis issue can be reproduced by running the following test in loop, and\nfio hang can be observed in \u0026lt; 30min when running it on my test VM\nin laptop.\r\n\r\n\tmodprobe -r scsi_debug\n\tmodprobe scsi_debug delay=0 dev_size_mb=4096 max_queue=1 host_max_queue=1 submit_queues=4\n\tdev=`ls -d /sys/bus/pseudo/drivers/scsi_debug/adapter*/host*/target*/*/block/* | head -1 | xargs basename`\n\tfio --filename=/dev/\u0026quot;$dev\u0026quot; --direct=1 --rw=randrw --bs=4k --iodepth=1 \\\n \t\t--runtime=100 --numjobs=40 --time_based --name=test \\\n \t--ioengine=libaio\r\n\r\nFix the issue by adding one explicit barrier in blk_mq_mark_tag_wait(), which\nis just fine in case of running out of tag.(CVE-2024-26671)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ninet: read sk-\u0026gt;sk_family once in inet_recv_error()\r\n\r\ninet_recv_error() is called without holding the socket lock.\r\n\r\nIPv6 socket could mutate to IPv4 with IPV6_ADDRFORM\nsocket option and trigger a KCSAN warning.(CVE-2024-26679)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: atlantic: Fix DMA mapping for PTP hwts ring\r\n\r\nFunction aq_ring_hwts_rx_alloc() maps extra AQ_CFG_RXDS_DEF bytes\nfor PTP HWTS ring but then generic aq_ring_free() does not take this\ninto account.\nCreate and use a specific function to free HWTS ring to fix this\nissue.\r\n\r\nTrace:\n[ 215.351607] ------------[ cut here ]------------\n[ 215.351612] DMA-API: atlantic 0000:4b:00.0: device driver frees DMA memory with different size [device address=0x00000000fbdd0000] [map size=34816 bytes] [unmap size=32768 bytes]\n[ 215.351635] WARNING: CPU: 33 PID: 10759 at kernel/dma/debug.c:988 check_unmap+0xa6f/0x2360\n...\n[ 215.581176] Call Trace:\n[ 215.583632] \u0026lt;TASK\u0026gt;\n[ 215.585745] ? show_trace_log_lvl+0x1c4/0x2df\n[ 215.590114] ? show_trace_log_lvl+0x1c4/0x2df\n[ 215.594497] ? debug_dma_free_coherent+0x196/0x210\n[ 215.599305] ? check_unmap+0xa6f/0x2360\n[ 215.603147] ? __warn+0xca/0x1d0\n[ 215.606391] ? check_unmap+0xa6f/0x2360\n[ 215.610237] ? report_bug+0x1ef/0x370\n[ 215.613921] ? handle_bug+0x3c/0x70\n[ 215.617423] ? exc_invalid_op+0x14/0x50\n[ 215.621269] ? asm_exc_invalid_op+0x16/0x20\n[ 215.625480] ? check_unmap+0xa6f/0x2360\n[ 215.629331] ? mark_lock.part.0+0xca/0xa40\n[ 215.633445] debug_dma_free_coherent+0x196/0x210\n[ 215.638079] ? __pfx_debug_dma_free_coherent+0x10/0x10\n[ 215.643242] ? slab_free_freelist_hook+0x11d/0x1d0\n[ 215.648060] dma_free_attrs+0x6d/0x130\n[ 215.651834] aq_ring_free+0x193/0x290 [atlantic]\n[ 215.656487] aq_ptp_ring_free+0x67/0x110 [atlantic]\n...\n[ 216.127540] ---[ end trace 6467e5964dd2640b ]---\n[ 216.132160] DMA-API: Mapped at:\n[ 216.132162] debug_dma_alloc_coherent+0x66/0x2f0\n[ 216.132165] dma_alloc_attrs+0xf5/0x1b0\n[ 216.132168] aq_ring_hwts_rx_alloc+0x150/0x1f0 [atlantic]\n[ 216.132193] aq_ptp_ring_alloc+0x1bb/0x540 [atlantic]\n[ 216.132213] aq_nic_init+0x4a1/0x760 [atlantic](CVE-2024-26680)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: stmmac: xgmac: fix handling of DPP safety error for DMA channels\r\n\r\nCommit 56e58d6c8a56 (\u0026quot;net: stmmac: Implement Safety Features in\nXGMAC core\u0026quot;) checks and reports safety errors, but leaves the\nData Path Parity Errors for each channel in DMA unhandled at all, lead to\na storm of interrupt.\nFix it by checking and clearing the DMA_DPP_Interrupt_Status register.(CVE-2024-26684)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: fix potential bug in end_buffer_async_write\r\n\r\nAccording to a syzbot report, end_buffer_async_write(), which handles the\ncompletion of block device writes, may detect abnormal condition of the\nbuffer async_write flag and cause a BUG_ON failure when using nilfs2.\r\n\r\nNilfs2 itself does not use end_buffer_async_write(). But, the async_write\nflag is now used as a marker by commit 7f42ec394156 (\u0026quot;nilfs2: fix issue\nwith race condition of competition between segments for dirty blocks\u0026quot;) as\na means of resolving double list insertion of dirty blocks in\nnilfs_lookup_dirty_data_buffers() and nilfs_lookup_node_buffers() and the\nresulting crash.\r\n\r\nThis modification is safe as long as it is used for file data and b-tree\nnode blocks where the page caches are independent. However, it was\nirrelevant and redundant to also introduce async_write for segment summary\nand super root blocks that share buffers with the backing device. This\nled to the possibility that the BUG_ON check in end_buffer_async_write\nwould fail as described above, if independent writebacks of the backing\ndevice occurred in parallel.\r\n\r\nThe use of async_write for segment summary buffers has already been\nremoved in a previous change.\r\n\r\nFix this issue by removing the manipulation of the async_write flag for\nthe remaining super root block buffer.(CVE-2024-26685)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfs,hugetlb: fix NULL pointer dereference in hugetlbs_fill_super\r\n\r\nWhen configuring a hugetlb filesystem via the fsconfig() syscall, there is\na possible NULL dereference in hugetlbfs_fill_super() caused by assigning\nNULL to ctx-\u0026gt;hstate in hugetlbfs_parse_param() when the requested pagesize\nis non valid.\r\n\r\nE.g: Taking the following steps:\r\n\r\n fd = fsopen(\u0026quot;hugetlbfs\u0026quot;, FSOPEN_CLOEXEC);\n fsconfig(fd, FSCONFIG_SET_STRING, \u0026quot;pagesize\u0026quot;, \u0026quot;1024\u0026quot;, 0);\n fsconfig(fd, FSCONFIG_CMD_CREATE, NULL, NULL, 0);\r\n\r\nGiven that the requested \u0026quot;pagesize\u0026quot; is invalid, ctxt-\u0026gt;hstate will be replaced\nwith NULL, losing its previous value, and we will print an error:\r\n\r\n ...\n ...\n case Opt_pagesize:\n ps = memparse(param-\u0026gt;string, \u0026amp;rest);\n ctx-\u0026gt;hstate = h;\n if (!ctx-\u0026gt;hstate) {\n pr_err(\u0026quot;Unsupported page size %lu MB\\n\u0026quot;, ps / SZ_1M);\n return -EINVAL;\n }\n return 0;\n ...\n ...\r\n\r\nThis is a problem because later on, we will dereference ctxt-\u0026gt;hstate in\nhugetlbfs_fill_super()\r\n\r\n ...\n ...\n sb-\u0026gt;s_blocksize = huge_page_size(ctx-\u0026gt;hstate);\n ...\n ...\r\n\r\nCausing below Oops.\r\n\r\nFix this by replacing cxt-\u0026gt;hstate value only when then pagesize is known\nto be valid.\r\n\r\n kernel: hugetlbfs: Unsupported page size 0 MB\n kernel: BUG: kernel NULL pointer dereference, address: 0000000000000028\n kernel: #PF: supervisor read access in kernel mode\n kernel: #PF: error_code(0x0000) - not-present page\n kernel: PGD 800000010f66c067 P4D 800000010f66c067 PUD 1b22f8067 PMD 0\n kernel: Oops: 0000 [#1] PREEMPT SMP PTI\n kernel: CPU: 4 PID: 5659 Comm: syscall Tainted: G E 6.8.0-rc2-default+ #22 5a47c3fef76212addcc6eb71344aabc35190ae8f\n kernel: Hardware name: Intel Corp. GROVEPORT/GROVEPORT, BIOS GVPRCRB1.86B.0016.D04.1705030402 05/03/2017\n kernel: RIP: 0010:hugetlbfs_fill_super+0xb4/0x1a0\n kernel: Code: 48 8b 3b e8 3e c6 ed ff 48 85 c0 48 89 45 20 0f 84 d6 00 00 00 48 b8 ff ff ff ff ff ff ff 7f 4c 89 e7 49 89 44 24 20 48 8b 03 \u0026lt;8b\u0026gt; 48 28 b8 00 10 00 00 48 d3 e0 49 89 44 24 18 48 8b 03 8b 40 28\n kernel: RSP: 0018:ffffbe9960fcbd48 EFLAGS: 00010246\n kernel: RAX: 0000000000000000 RBX: ffff9af5272ae780 RCX: 0000000000372004\n kernel: RDX: ffffffffffffffff RSI: ffffffffffffffff RDI: ffff9af555e9b000\n kernel: RBP: ffff9af52ee66b00 R08: 0000000000000040 R09: 0000000000370004\n kernel: R10: ffffbe9960fcbd48 R11: 0000000000000040 R12: ffff9af555e9b000\n kernel: R13: ffffffffa66b86c0 R14: ffff9af507d2f400 R15: ffff9af507d2f400\n kernel: FS: 00007ffbc0ba4740(0000) GS:ffff9b0bd7000000(0000) knlGS:0000000000000000\n kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n kernel: CR2: 0000000000000028 CR3: 00000001b1ee0000 CR4: 00000000001506f0\n kernel: Call Trace:\n kernel: \u0026lt;TASK\u0026gt;\n kernel: ? __die_body+0x1a/0x60\n kernel: ? page_fault_oops+0x16f/0x4a0\n kernel: ? search_bpf_extables+0x65/0x70\n kernel: ? fixup_exception+0x22/0x310\n kernel: ? exc_page_fault+0x69/0x150\n kernel: ? asm_exc_page_fault+0x22/0x30\n kernel: ? __pfx_hugetlbfs_fill_super+0x10/0x10\n kernel: ? hugetlbfs_fill_super+0xb4/0x1a0\n kernel: ? hugetlbfs_fill_super+0x28/0x1a0\n kernel: ? __pfx_hugetlbfs_fill_super+0x10/0x10\n kernel: vfs_get_super+0x40/0xa0\n kernel: ? __pfx_bpf_lsm_capable+0x10/0x10\n kernel: vfs_get_tree+0x25/0xd0\n kernel: vfs_cmd_create+0x64/0xe0\n kernel: __x64_sys_fsconfig+0x395/0x410\n kernel: do_syscall_64+0x80/0x160\n kernel: ? syscall_exit_to_user_mode+0x82/0x240\n kernel: ? do_syscall_64+0x8d/0x160\n kernel: ? syscall_exit_to_user_mode+0x82/0x240\n kernel: ? do_syscall_64+0x8d/0x160\n kernel: ? exc_page_fault+0x69/0x150\n kernel: entry_SYSCALL_64_after_hwframe+0x6e/0x76\n kernel: RIP: 0033:0x7ffbc0cb87c9\n kernel: Code: 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 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 8b 0d 97 96 0d 00 f7 d8 64 89 01 48\n kernel: RSP: 002b:00007ffc29d2f388 EFLAGS: 00000206 ORIG_RAX: 00000000000001af\n kernel: RAX: fffffffffff\n---truncated---(CVE-2024-26688)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nceph: prevent use-after-free in encode_cap_msg()\r\n\r\nIn fs/ceph/caps.c, in encode_cap_msg(), \u0026quot;use after free\u0026quot; error was\ncaught by KASAN at this line - \u0026apos;ceph_buffer_get(arg-\u0026gt;xattr_buf);\u0026apos;. This\nimplies before the refcount could be increment here, it was freed.\r\n\r\nIn same file, in \u0026quot;handle_cap_grant()\u0026quot; refcount is decremented by this\nline - \u0026apos;ceph_buffer_put(ci-\u0026gt;i_xattrs.blob);\u0026apos;. It appears that a race\noccurred and resource was freed by the latter line before the former\nline could increment it.\r\n\r\nencode_cap_msg() is called by __send_cap() and __send_cap() is called by\nceph_check_caps() after calling __prep_cap(). __prep_cap() is where\narg-\u0026gt;xattr_buf is assigned to ci-\u0026gt;i_xattrs.blob. This is the spot where\nthe refcount must be increased to prevent \u0026quot;use after free\u0026quot; error.(CVE-2024-26689)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: fix data corruption in dsync block recovery for small block sizes\r\n\r\nThe helper function nilfs_recovery_copy_block() of\nnilfs_recovery_dsync_blocks(), which recovers data from logs created by\ndata sync writes during a mount after an unclean shutdown, incorrectly\ncalculates the on-page offset when copying repair data to the file\u0026apos;s page\ncache. In environments where the block size is smaller than the page\nsize, this flaw can cause data corruption and leak uninitialized memory\nbytes during the recovery process.\r\n\r\nFix these issues by correcting this byte offset calculation on the page.(CVE-2024-26697)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nparisc: Fix random data corruption from exception handler\r\n\r\nThe current exception handler implementation, which assists when accessing\nuser space memory, may exhibit random data corruption if the compiler decides\nto use a different register than the specified register %r29 (defined in\nASM_EXCEPTIONTABLE_REG) for the error code. If the compiler choose another\nregister, the fault handler will nevertheless store -EFAULT into %r29 and thus\ntrash whatever this register is used for.\nLooking at the assembly I found that this happens sometimes in emulate_ldd().\r\n\r\nTo solve the issue, the easiest solution would be if it somehow is\npossible to tell the fault handler which register is used to hold the error\ncode. Using %0 or %1 in the inline assembly is not posssible as it will show\nup as e.g. %r29 (with the \u0026quot;%r\u0026quot; prefix), which the GNU assembler can not\nconvert to an integer.\r\n\r\nThis patch takes another, better and more flexible approach:\nWe extend the __ex_table (which is out of the execution path) by one 32-word.\nIn this word we tell the compiler to insert the assembler instruction\n\u0026quot;or %r0,%r0,%reg\u0026quot;, where %reg references the register which the compiler\nchoosed for the error return code.\nIn case of an access failure, the fault handler finds the __ex_table entry and\ncan examine the opcode. The used register is encoded in the lowest 5 bits, and\nthe fault handler can then store -EFAULT into this register.\r\n\r\nSince we extend the __ex_table to 3 words we can\u0026apos;t use the BUILDTIME_TABLE_SORT\nconfig option any longer.(CVE-2024-26706)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: hsr: remove WARN_ONCE() in send_hsr_supervision_frame()\r\n\r\nSyzkaller reported [1] hitting a warning after failing to allocate\nresources for skb in hsr_init_skb(). Since a WARN_ONCE() call will\nnot help much in this case, it might be prudent to switch to\nnetdev_warn_once(). At the very least it will suppress syzkaller\nreports such as [1].\r\n\r\nJust in case, use netdev_warn_once() in send_prp_supervision_frame()\nfor similar reasons.\r\n\r\n[1]\nHSR: Could not send supervision frame\nWARNING: CPU: 1 PID: 85 at net/hsr/hsr_device.c:294 send_hsr_supervision_frame+0x60a/0x810 net/hsr/hsr_device.c:294\nRIP: 0010:send_hsr_supervision_frame+0x60a/0x810 net/hsr/hsr_device.c:294\n...\nCall Trace:\n \u0026lt;IRQ\u0026gt;\n hsr_announce+0x114/0x370 net/hsr/hsr_device.c:382\n call_timer_fn+0x193/0x590 kernel/time/timer.c:1700\n expire_timers kernel/time/timer.c:1751 [inline]\n __run_timers+0x764/0xb20 kernel/time/timer.c:2022\n run_timer_softirq+0x58/0xd0 kernel/time/timer.c:2035\n __do_softirq+0x21a/0x8de kernel/softirq.c:553\n invoke_softirq kernel/softirq.c:427 [inline]\n __irq_exit_rcu kernel/softirq.c:632 [inline]\n irq_exit_rcu+0xb7/0x120 kernel/softirq.c:644\n sysvec_apic_timer_interrupt+0x95/0xb0 arch/x86/kernel/apic/apic.c:1076\n \u0026lt;/IRQ\u0026gt;\n \u0026lt;TASK\u0026gt;\n asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:649\n...\r\n\r\nThis issue is also found in older kernels (at least up to 5.10).(CVE-2024-26707)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmm/writeback: fix possible divide-by-zero in wb_dirty_limits(), again\r\n\r\n(struct dirty_throttle_control *)-\u0026gt;thresh is an unsigned long, but is\npassed as the u32 divisor argument to div_u64(). On architectures where\nunsigned long is 64 bytes, the argument will be implicitly truncated.\r\n\r\nUse div64_u64() instead of div_u64() so that the value used in the \u0026quot;is\nthis a safe division\u0026quot; check is the same as the divisor.\r\n\r\nAlso, remove redundant cast of the numerator to u64, as that should happen\nimplicitly.\r\n\r\nThis would be difficult to exploit in memcg domain, given the ratio-based\narithmetic domain_drity_limits() uses, but is much easier in global\nwriteback domain with a BDI_CAP_STRICTLIMIT-backing device, using e.g. \nvm.dirty_bytes=(1\u0026lt;\u0026lt;32)*PAGE_SIZE so that dtc-\u0026gt;thresh == (1\u0026lt;\u0026lt;32)(CVE-2024-26720)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: don\u0026apos;t drop extent_map for free space inode on write error\r\n\r\nWhile running the CI for an unrelated change I hit the following panic\nwith generic/648 on btrfs_holes_spacecache.\r\n\r\nassertion failed: block_start != EXTENT_MAP_HOLE, in fs/btrfs/extent_io.c:1385\n------------[ cut here ]------------\nkernel BUG at fs/btrfs/extent_io.c:1385!\ninvalid opcode: 0000 [#1] PREEMPT SMP NOPTI\nCPU: 1 PID: 2695096 Comm: fsstress Kdump: loaded Tainted: G W 6.8.0-rc2+ #1\nRIP: 0010:__extent_writepage_io.constprop.0+0x4c1/0x5c0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n extent_write_cache_pages+0x2ac/0x8f0\n extent_writepages+0x87/0x110\n do_writepages+0xd5/0x1f0\n filemap_fdatawrite_wbc+0x63/0x90\n __filemap_fdatawrite_range+0x5c/0x80\n btrfs_fdatawrite_range+0x1f/0x50\n btrfs_write_out_cache+0x507/0x560\n btrfs_write_dirty_block_groups+0x32a/0x420\n commit_cowonly_roots+0x21b/0x290\n btrfs_commit_transaction+0x813/0x1360\n btrfs_sync_file+0x51a/0x640\n __x64_sys_fdatasync+0x52/0x90\n do_syscall_64+0x9c/0x190\n entry_SYSCALL_64_after_hwframe+0x6e/0x76\r\n\r\nThis happens because we fail to write out the free space cache in one\ninstance, come back around and attempt to write it again. However on\nthe second pass through we go to call btrfs_get_extent() on the inode to\nget the extent mapping. Because this is a new block group, and with the\nfree space inode we always search the commit root to avoid deadlocking\nwith the tree, we find nothing and return a EXTENT_MAP_HOLE for the\nrequested range.\r\n\r\nThis happens because the first time we try to write the space cache out\nwe hit an error, and on an error we drop the extent mapping. This is\nnormal for normal files, but the free space cache inode is special. We\nalways expect the extent map to be correct. Thus the second time\nthrough we end up with a bogus extent map.\r\n\r\nSince we\u0026apos;re deprecating this feature, the most straightforward way to\nfix this is to simply skip dropping the extent map range for this failed\nrange.\r\n\r\nI shortened the test by using error injection to stress the area to make\nit easier to reproduce. With this patch in place we no longer panic\nwith my error injection test.(CVE-2024-26726)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\narp: Prevent overflow in arp_req_get().\r\n\r\nsyzkaller reported an overflown write in arp_req_get(). [0]\r\n\r\nWhen ioctl(SIOCGARP) is issued, arp_req_get() looks up an neighbour\nentry and copies neigh-\u0026gt;ha to struct arpreq.arp_ha.sa_data.\r\n\r\nThe arp_ha here is struct sockaddr, not struct sockaddr_storage, so\nthe sa_data buffer is just 14 bytes.\r\n\r\nIn the splat below, 2 bytes are overflown to the next int field,\narp_flags. We initialise the field just after the memcpy(), so it\u0026apos;s\nnot a problem.\r\n\r\nHowever, when dev-\u0026gt;addr_len is greater than 22 (e.g. MAX_ADDR_LEN),\narp_netmask is overwritten, which could be set as htonl(0xFFFFFFFFUL)\nin arp_ioctl() before calling arp_req_get().\r\n\r\nTo avoid the overflow, let\u0026apos;s limit the max length of memcpy().\r\n\r\nNote that commit b5f0de6df6dc (\u0026quot;net: dev: Convert sa_data to flexible\narray in struct sockaddr\u0026quot;) just silenced syzkaller.\r\n\r\n[0]:\nmemcpy: detected field-spanning write (size 16) of single field \u0026quot;r-\u0026gt;arp_ha.sa_data\u0026quot; at net/ipv4/arp.c:1128 (size 14)\nWARNING: CPU: 0 PID: 144638 at net/ipv4/arp.c:1128 arp_req_get+0x411/0x4a0 net/ipv4/arp.c:1128\nModules linked in:\nCPU: 0 PID: 144638 Comm: syz-executor.4 Not tainted 6.1.74 #31\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-debian-1.16.0-5 04/01/2014\nRIP: 0010:arp_req_get+0x411/0x4a0 net/ipv4/arp.c:1128\nCode: fd ff ff e8 41 42 de fb b9 0e 00 00 00 4c 89 fe 48 c7 c2 20 6d ab 87 48 c7 c7 80 6d ab 87 c6 05 25 af 72 04 01 e8 5f 8d ad fb \u0026lt;0f\u0026gt; 0b e9 6c fd ff ff e8 13 42 de fb be 03 00 00 00 4c 89 e7 e8 a6\nRSP: 0018:ffffc900050b7998 EFLAGS: 00010286\nRAX: 0000000000000000 RBX: ffff88803a815000 RCX: 0000000000000000\nRDX: 0000000000000000 RSI: ffffffff8641a44a RDI: 0000000000000001\nRBP: ffffc900050b7a98 R08: 0000000000000001 R09: 0000000000000000\nR10: 0000000000000000 R11: 203a7970636d656d R12: ffff888039c54000\nR13: 1ffff92000a16f37 R14: ffff88803a815084 R15: 0000000000000010\nFS: 00007f172bf306c0(0000) GS:ffff88805aa00000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f172b3569f0 CR3: 0000000057f12005 CR4: 0000000000770ef0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nPKRU: 55555554\nCall Trace:\n \u0026lt;TASK\u0026gt;\n arp_ioctl+0x33f/0x4b0 net/ipv4/arp.c:1261\n inet_ioctl+0x314/0x3a0 net/ipv4/af_inet.c:981\n sock_do_ioctl+0xdf/0x260 net/socket.c:1204\n sock_ioctl+0x3ef/0x650 net/socket.c:1321\n vfs_ioctl fs/ioctl.c:51 [inline]\n __do_sys_ioctl fs/ioctl.c:870 [inline]\n __se_sys_ioctl fs/ioctl.c:856 [inline]\n __x64_sys_ioctl+0x18e/0x220 fs/ioctl.c:856\n do_syscall_x64 arch/x86/entry/common.c:51 [inline]\n do_syscall_64+0x37/0x90 arch/x86/entry/common.c:81\n entry_SYSCALL_64_after_hwframe+0x64/0xce\nRIP: 0033:0x7f172b262b8d\nCode: 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007f172bf300b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010\nRAX: ffffffffffffffda RBX: 00007f172b3abf80 RCX: 00007f172b262b8d\nRDX: 0000000020000000 RSI: 0000000000008954 RDI: 0000000000000003\nRBP: 00007f172b2d3493 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000\nR13: 000000000000000b R14: 00007f172b3abf80 R15: 00007f172bf10000\n \u0026lt;/TASK\u0026gt;(CVE-2024-26733)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndevlink: fix possible use-after-free and memory leaks in devlink_init()\r\n\r\nThe pernet operations structure for the subsystem must be registered\nbefore registering the generic netlink family.\r\n\r\nMake an unregister in case of unsuccessful registration.(CVE-2024-26734)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nipv6: sr: fix possible use-after-free and null-ptr-deref\r\n\r\nThe pernet operations structure for the subsystem must be registered\nbefore registering the generic netlink family.(CVE-2024-26735)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/sched: act_mirred: don\u0026apos;t override retval if we already lost the skb\r\n\r\nIf we\u0026apos;re redirecting the skb, and haven\u0026apos;t called tcf_mirred_forward(),\nyet, we need to tell the core to drop the skb by setting the retcode\nto SHOT. If we have called tcf_mirred_forward(), however, the skb\nis out of our hands and returning SHOT will lead to UaF.\r\n\r\nMove the retval override to the error path which actually need it.(CVE-2024-26739)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/sched: act_mirred: use the backlog for mirred ingress\r\n\r\nThe test Davide added in commit ca22da2fbd69 (\u0026quot;act_mirred: use the backlog\nfor nested calls to mirred ingress\u0026quot;) hangs our testing VMs every 10 or so\nruns, with the familiar tcp_v4_rcv -\u0026gt; tcp_v4_rcv deadlock reported by\nlockdep.\r\n\r\nThe problem as previously described by Davide (see Link) is that\nif we reverse flow of traffic with the redirect (egress -\u0026gt; ingress)\nwe may reach the same socket which generated the packet. And we may\nstill be holding its socket lock. The common solution to such deadlocks\nis to put the packet in the Rx backlog, rather than run the Rx path\ninline. Do that for all egress -\u0026gt; ingress reversals, not just once\nwe started to nest mirred calls.\r\n\r\nIn the past there was a concern that the backlog indirection will\nlead to loss of error reporting / less accurate stats. But the current\nworkaround does not seem to address the issue.(CVE-2024-26740)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nRDMA/qedr: Fix qedr_create_user_qp error flow\r\n\r\nAvoid the following warning by making sure to free the allocated\nresources in case that qedr_init_user_queue() fail.\r\n\r\n-----------[ cut here ]-----------\nWARNING: CPU: 0 PID: 143192 at drivers/infiniband/core/rdma_core.c:874 uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]\nModules linked in: tls target_core_user uio target_core_pscsi target_core_file target_core_iblock ib_srpt ib_srp scsi_transport_srp nfsd nfs_acl rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs 8021q garp mrp stp llc ext4 mbcache jbd2 opa_vnic ib_umad ib_ipoib sunrpc rdma_ucm ib_isert iscsi_target_mod target_core_mod ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_cm hfi1 intel_rapl_msr intel_rapl_common mgag200 qedr sb_edac drm_shmem_helper rdmavt x86_pkg_temp_thermal drm_kms_helper intel_powerclamp ib_uverbs coretemp i2c_algo_bit kvm_intel dell_wmi_descriptor ipmi_ssif sparse_keymap kvm ib_core rfkill syscopyarea sysfillrect video sysimgblt irqbypass ipmi_si ipmi_devintf fb_sys_fops rapl iTCO_wdt mxm_wmi iTCO_vendor_support intel_cstate pcspkr dcdbas intel_uncore ipmi_msghandler lpc_ich acpi_power_meter mei_me mei fuse drm xfs libcrc32c qede sd_mod ahci libahci t10_pi sg crct10dif_pclmul crc32_pclmul crc32c_intel qed libata tg3\nghash_clmulni_intel megaraid_sas crc8 wmi [last unloaded: ib_srpt]\nCPU: 0 PID: 143192 Comm: fi_rdm_tagged_p Kdump: loaded Not tainted 5.14.0-408.el9.x86_64 #1\nHardware name: Dell Inc. PowerEdge R430/03XKDV, BIOS 2.14.0 01/25/2022\nRIP: 0010:uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]\nCode: 5d 41 5c 41 5d 41 5e e9 0f 26 1b dd 48 89 df e8 67 6a ff ff 49 8b 86 10 01 00 00 48 85 c0 74 9c 4c 89 e7 e8 83 c0 cb dd eb 92 \u0026lt;0f\u0026gt; 0b eb be 0f 0b be 04 00 00 00 48 89 df e8 8e f5 ff ff e9 6d ff\nRSP: 0018:ffffb7c6cadfbc60 EFLAGS: 00010286\nRAX: ffff8f0889ee3f60 RBX: ffff8f088c1a5200 RCX: 00000000802a0016\nRDX: 00000000802a0017 RSI: 0000000000000001 RDI: ffff8f0880042600\nRBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000\nR10: ffff8f11fffd5000 R11: 0000000000039000 R12: ffff8f0d5b36cd80\nR13: ffff8f088c1a5250 R14: ffff8f1206d91000 R15: 0000000000000000\nFS: 0000000000000000(0000) GS:ffff8f11d7c00000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000147069200e20 CR3: 00000001c7210002 CR4: 00000000001706f0\nCall Trace:\n\u0026lt;TASK\u0026gt;\n? show_trace_log_lvl+0x1c4/0x2df\n? show_trace_log_lvl+0x1c4/0x2df\n? ib_uverbs_close+0x1f/0xb0 [ib_uverbs]\n? uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]\n? __warn+0x81/0x110\n? uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]\n? report_bug+0x10a/0x140\n? handle_bug+0x3c/0x70\n? exc_invalid_op+0x14/0x70\n? asm_exc_invalid_op+0x16/0x20\n? uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]\nib_uverbs_close+0x1f/0xb0 [ib_uverbs]\n__fput+0x94/0x250\ntask_work_run+0x5c/0x90\ndo_exit+0x270/0x4a0\ndo_group_exit+0x2d/0x90\nget_signal+0x87c/0x8c0\narch_do_signal_or_restart+0x25/0x100\n? ib_uverbs_ioctl+0xc2/0x110 [ib_uverbs]\nexit_to_user_mode_loop+0x9c/0x130\nexit_to_user_mode_prepare+0xb6/0x100\nsyscall_exit_to_user_mode+0x12/0x40\ndo_syscall_64+0x69/0x90\n? syscall_exit_work+0x103/0x130\n? syscall_exit_to_user_mode+0x22/0x40\n? do_syscall_64+0x69/0x90\n? syscall_exit_work+0x103/0x130\n? syscall_exit_to_user_mode+0x22/0x40\n? do_syscall_64+0x69/0x90\n? do_syscall_64+0x69/0x90\n? common_interrupt+0x43/0xa0\nentry_SYSCALL_64_after_hwframe+0x72/0xdc\nRIP: 0033:0x1470abe3ec6b\nCode: Unable to access opcode bytes at RIP 0x1470abe3ec41.\nRSP: 002b:00007fff13ce9108 EFLAGS: 00000246 ORIG_RAX: 0000000000000010\nRAX: fffffffffffffffc RBX: 00007fff13ce9218 RCX: 00001470abe3ec6b\nRDX: 00007fff13ce9200 RSI: 00000000c0181b01 RDI: 0000000000000004\nRBP: 00007fff13ce91e0 R08: 0000558d9655da10 R09: 0000558d9655dd00\nR10: 00007fff13ce95c0 R11: 0000000000000246 R12: 00007fff13ce9358\nR13: 0000000000000013 R14: 0000558d9655db50 R15: 00007fff13ce9470\n\u0026lt;/TASK\u0026gt;\n--[ end trace 888a9b92e04c5c97 ]--(CVE-2024-26743)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nRDMA/srpt: Support specifying the srpt_service_guid parameter\r\n\r\nMake loading ib_srpt with this parameter set work. The current behavior is\nthat setting that parameter while loading the ib_srpt kernel module\ntriggers the following kernel crash:\r\n\r\nBUG: kernel NULL pointer dereference, address: 0000000000000000\nCall Trace:\n \u0026lt;TASK\u0026gt;\n parse_one+0x18c/0x1d0\n parse_args+0xe1/0x230\n load_module+0x8de/0xa60\n init_module_from_file+0x8b/0xd0\n idempotent_init_module+0x181/0x240\n __x64_sys_finit_module+0x5a/0xb0\n do_syscall_64+0x5f/0xe0\n entry_SYSCALL_64_after_hwframe+0x6e/0x76(CVE-2024-26744)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ngtp: fix use-after-free and null-ptr-deref in gtp_genl_dump_pdp()\r\n\r\nThe gtp_net_ops pernet operations structure for the subsystem must be\nregistered before registering the generic netlink family.\r\n\r\nSyzkaller hit \u0026apos;general protection fault in gtp_genl_dump_pdp\u0026apos; bug:\r\n\r\ngeneral protection fault, probably for non-canonical address\n0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN NOPTI\nKASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]\nCPU: 1 PID: 5826 Comm: gtp Not tainted 6.8.0-rc3-std-def-alt1 #1\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-alt1 04/01/2014\nRIP: 0010:gtp_genl_dump_pdp+0x1be/0x800 [gtp]\nCode: c6 89 c6 e8 64 e9 86 df 58 45 85 f6 0f 85 4e 04 00 00 e8 c5 ee 86\n df 48 8b 54 24 18 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 \u0026lt;80\u0026gt;\n 3c 02 00 0f 85 de 05 00 00 48 8b 44 24 18 4c 8b 30 4c 39 f0 74\nRSP: 0018:ffff888014107220 EFLAGS: 00010202\nRAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000\nRDX: 0000000000000002 RSI: 0000000000000000 RDI: 0000000000000000\nRBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000\nR13: ffff88800fcda588 R14: 0000000000000001 R15: 0000000000000000\nFS: 00007f1be4eb05c0(0000) GS:ffff88806ce80000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f1be4e766cf CR3: 000000000c33e000 CR4: 0000000000750ef0\nPKRU: 55555554\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? show_regs+0x90/0xa0\n ? die_addr+0x50/0xd0\n ? exc_general_protection+0x148/0x220\n ? asm_exc_general_protection+0x22/0x30\n ? gtp_genl_dump_pdp+0x1be/0x800 [gtp]\n ? __alloc_skb+0x1dd/0x350\n ? __pfx___alloc_skb+0x10/0x10\n genl_dumpit+0x11d/0x230\n netlink_dump+0x5b9/0xce0\n ? lockdep_hardirqs_on_prepare+0x253/0x430\n ? __pfx_netlink_dump+0x10/0x10\n ? kasan_save_track+0x10/0x40\n ? __kasan_kmalloc+0x9b/0xa0\n ? genl_start+0x675/0x970\n __netlink_dump_start+0x6fc/0x9f0\n genl_family_rcv_msg_dumpit+0x1bb/0x2d0\n ? __pfx_genl_family_rcv_msg_dumpit+0x10/0x10\n ? genl_op_from_small+0x2a/0x440\n ? cap_capable+0x1d0/0x240\n ? __pfx_genl_start+0x10/0x10\n ? __pfx_genl_dumpit+0x10/0x10\n ? __pfx_genl_done+0x10/0x10\n ? security_capable+0x9d/0xe0(CVE-2024-26754)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndm-crypt: don\u0026apos;t modify the data when using authenticated encryption\r\n\r\nIt was said that authenticated encryption could produce invalid tag when\nthe data that is being encrypted is modified [1]. So, fix this problem by\ncopying the data into the clone bio first and then encrypt them inside the\nclone bio.\r\n\r\nThis may reduce performance, but it is needed to prevent the user from\ncorrupting the device by writing data with O_DIRECT and modifying them at\nthe same time.\r\n\r\n[1] https://lore.kernel.org/all/20240207004723.GA35324@sol.localdomain/T/(CVE-2024-26763)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nspi: hisi-sfc-v3xx: Return IRQ_NONE if no interrupts were detected\r\n\r\nReturn IRQ_NONE from the interrupt handler when no interrupt was\ndetected. Because an empty interrupt will cause a null pointer error:\r\n\r\n Unable to handle kernel NULL pointer dereference at virtual\n address 0000000000000008\n Call trace:\n complete+0x54/0x100\n hisi_sfc_v3xx_isr+0x2c/0x40 [spi_hisi_sfc_v3xx]\n __handle_irq_event_percpu+0x64/0x1e0\n handle_irq_event+0x7c/0x1cc(CVE-2024-26776)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmptcp: fix double-free on socket dismantle\r\n\r\nwhen MPTCP server accepts an incoming connection, it clones its listener\nsocket. However, the pointer to \u0026apos;inet_opt\u0026apos; for the new socket has the same\nvalue as the original one: as a consequence, on program exit it\u0026apos;s possible\nto observe the following splat:\r\n\r\n BUG: KASAN: double-free in inet_sock_destruct+0x54f/0x8b0\n Free of addr ffff888485950880 by task swapper/25/0\r\n\r\n CPU: 25 PID: 0 Comm: swapper/25 Kdump: loaded Not tainted 6.8.0-rc1+ #609\n Hardware name: Supermicro SYS-6027R-72RF/X9DRH-7TF/7F/iTF/iF, BIOS 3.0 07/26/2013\n Call Trace:\n \u0026lt;IRQ\u0026gt;\n dump_stack_lvl+0x32/0x50\n print_report+0xca/0x620\n kasan_report_invalid_free+0x64/0x90\n __kasan_slab_free+0x1aa/0x1f0\n kfree+0xed/0x2e0\n inet_sock_destruct+0x54f/0x8b0\n __sk_destruct+0x48/0x5b0\n rcu_do_batch+0x34e/0xd90\n rcu_core+0x559/0xac0\n __do_softirq+0x183/0x5a4\n irq_exit_rcu+0x12d/0x170\n sysvec_apic_timer_interrupt+0x6b/0x80\n \u0026lt;/IRQ\u0026gt;\n \u0026lt;TASK\u0026gt;\n asm_sysvec_apic_timer_interrupt+0x16/0x20\n RIP: 0010:cpuidle_enter_state+0x175/0x300\n Code: 30 00 0f 84 1f 01 00 00 83 e8 01 83 f8 ff 75 e5 48 83 c4 18 44 89 e8 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc fb 45 85 ed \u0026lt;0f\u0026gt; 89 60 ff ff ff 48 c1 e5 06 48 c7 43 18 00 00 00 00 48 83 44 2b\n RSP: 0018:ffff888481cf7d90 EFLAGS: 00000202\n RAX: 0000000000000000 RBX: ffff88887facddc8 RCX: 0000000000000000\n RDX: 1ffff1110ff588b1 RSI: 0000000000000019 RDI: ffff88887fac4588\n RBP: 0000000000000004 R08: 0000000000000002 R09: 0000000000043080\n R10: 0009b02ea273363f R11: ffff88887fabf42b R12: ffffffff932592e0\n R13: 0000000000000004 R14: 0000000000000000 R15: 00000022c880ec80\n cpuidle_enter+0x4a/0xa0\n do_idle+0x310/0x410\n cpu_startup_entry+0x51/0x60\n start_secondary+0x211/0x270\n secondary_startup_64_no_verify+0x184/0x18b\n \u0026lt;/TASK\u0026gt;\r\n\r\n Allocated by task 6853:\n kasan_save_stack+0x1c/0x40\n kasan_save_track+0x10/0x30\n __kasan_kmalloc+0xa6/0xb0\n __kmalloc+0x1eb/0x450\n cipso_v4_sock_setattr+0x96/0x360\n netlbl_sock_setattr+0x132/0x1f0\n selinux_netlbl_socket_post_create+0x6c/0x110\n selinux_socket_post_create+0x37b/0x7f0\n security_socket_post_create+0x63/0xb0\n __sock_create+0x305/0x450\n __sys_socket_create.part.23+0xbd/0x130\n __sys_socket+0x37/0xb0\n __x64_sys_socket+0x6f/0xb0\n do_syscall_64+0x83/0x160\n entry_SYSCALL_64_after_hwframe+0x6e/0x76\r\n\r\n Freed by task 6858:\n kasan_save_stack+0x1c/0x40\n kasan_save_track+0x10/0x30\n kasan_save_free_info+0x3b/0x60\n __kasan_slab_free+0x12c/0x1f0\n kfree+0xed/0x2e0\n inet_sock_destruct+0x54f/0x8b0\n __sk_destruct+0x48/0x5b0\n subflow_ulp_release+0x1f0/0x250\n tcp_cleanup_ulp+0x6e/0x110\n tcp_v4_destroy_sock+0x5a/0x3a0\n inet_csk_destroy_sock+0x135/0x390\n tcp_fin+0x416/0x5c0\n tcp_data_queue+0x1bc8/0x4310\n tcp_rcv_state_process+0x15a3/0x47b0\n tcp_v4_do_rcv+0x2c1/0x990\n tcp_v4_rcv+0x41fb/0x5ed0\n ip_protocol_deliver_rcu+0x6d/0x9f0\n ip_local_deliver_finish+0x278/0x360\n ip_local_deliver+0x182/0x2c0\n ip_rcv+0xb5/0x1c0\n __netif_receive_skb_one_core+0x16e/0x1b0\n process_backlog+0x1e3/0x650\n __napi_poll+0xa6/0x500\n net_rx_action+0x740/0xbb0\n __do_softirq+0x183/0x5a4\r\n\r\n The buggy address belongs to the object at ffff888485950880\n which belongs to the cache kmalloc-64 of size 64\n The buggy address is located 0 bytes inside of\n 64-byte region [ffff888485950880, ffff8884859508c0)\r\n\r\n The buggy address belongs to the physical page:\n page:0000000056d1e95e refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888485950700 pfn:0x485950\n flags: 0x57ffffc0000800(slab|node=1|zone=2|lastcpupid=0x1fffff)\n page_type: 0xffffffff()\n raw: 0057ffffc0000800 ffff88810004c640 ffffea00121b8ac0 dead000000000006\n raw: ffff888485950700 0000000000200019 00000001ffffffff 0000000000000000\n page dumped because: kasan: bad access detected\r\n\r\n Memory state around the buggy address:\n ffff888485950780: fa fb fb\n---truncated---(CVE-2024-26782)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmmc: mmci: stm32: fix DMA API overlapping mappings warning\r\n\r\nTurning on CONFIG_DMA_API_DEBUG_SG results in the following warning:\r\n\r\nDMA-API: mmci-pl18x 48220000.mmc: cacheline tracking EEXIST,\noverlapping mappings aren\u0026apos;t supported\nWARNING: CPU: 1 PID: 51 at kernel/dma/debug.c:568\nadd_dma_entry+0x234/0x2f4\nModules linked in:\nCPU: 1 PID: 51 Comm: kworker/1:2 Not tainted 6.1.28 #1\nHardware name: STMicroelectronics STM32MP257F-EV1 Evaluation Board (DT)\nWorkqueue: events_freezable mmc_rescan\nCall trace:\nadd_dma_entry+0x234/0x2f4\ndebug_dma_map_sg+0x198/0x350\n__dma_map_sg_attrs+0xa0/0x110\ndma_map_sg_attrs+0x10/0x2c\nsdmmc_idma_prep_data+0x80/0xc0\nmmci_prep_data+0x38/0x84\nmmci_start_data+0x108/0x2dc\nmmci_request+0xe4/0x190\n__mmc_start_request+0x68/0x140\nmmc_start_request+0x94/0xc0\nmmc_wait_for_req+0x70/0x100\nmmc_send_tuning+0x108/0x1ac\nsdmmc_execute_tuning+0x14c/0x210\nmmc_execute_tuning+0x48/0xec\nmmc_sd_init_uhs_card.part.0+0x208/0x464\nmmc_sd_init_card+0x318/0x89c\nmmc_attach_sd+0xe4/0x180\nmmc_rescan+0x244/0x320\r\n\r\nDMA API debug brings to light leaking dma-mappings as dma_map_sg and\ndma_unmap_sg are not correctly balanced.\r\n\r\nIf an error occurs in mmci_cmd_irq function, only mmci_dma_error\nfunction is called and as this API is not managed on stm32 variant,\ndma_unmap_sg is never called in this error path.(CVE-2024-26787)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: dev-replace: properly validate device names\r\n\r\nThere\u0026apos;s a syzbot report that device name buffers passed to device\nreplace are not properly checked for string termination which could lead\nto a read out of bounds in getname_kernel().\r\n\r\nAdd a helper that validates both source and target device name buffers.\nFor devid as the source initialize the buffer to empty string in case\nsomething tries to read it later.\r\n\r\nThis was originally analyzed and fixed in a different way by Edward Adam\nDavis (see links).(CVE-2024-26791)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: fix double free of anonymous device after snapshot creation failure\r\n\r\nWhen creating a snapshot we may do a double free of an anonymous device\nin case there\u0026apos;s an error committing the transaction. The second free may\nresult in freeing an anonymous device number that was allocated by some\nother subsystem in the kernel or another btrfs filesystem.\r\n\r\nThe steps that lead to this:\r\n\r\n1) At ioctl.c:create_snapshot() we allocate an anonymous device number\n and assign it to pending_snapshot-\u0026gt;anon_dev;\r\n\r\n2) Then we call btrfs_commit_transaction() and end up at\n transaction.c:create_pending_snapshot();\r\n\r\n3) There we call btrfs_get_new_fs_root() and pass it the anonymous device\n number stored in pending_snapshot-\u0026gt;anon_dev;\r\n\r\n4) btrfs_get_new_fs_root() frees that anonymous device number because\n btrfs_lookup_fs_root() returned a root - someone else did a lookup\n of the new root already, which could some task doing backref walking;\r\n\r\n5) After that some error happens in the transaction commit path, and at\n ioctl.c:create_snapshot() we jump to the \u0026apos;fail\u0026apos; label, and after\n that we free again the same anonymous device number, which in the\n meanwhile may have been reallocated somewhere else, because\n pending_snapshot-\u0026gt;anon_dev still has the same value as in step 1.\r\n\r\nRecently syzbot ran into this and reported the following trace:\r\n\r\n ------------[ cut here ]------------\n ida_free called for id=51 which is not allocated.\n WARNING: CPU: 1 PID: 31038 at lib/idr.c:525 ida_free+0x370/0x420 lib/idr.c:525\n Modules linked in:\n CPU: 1 PID: 31038 Comm: syz-executor.2 Not tainted 6.8.0-rc4-syzkaller-00410-gc02197fc9076 #0\n Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024\n RIP: 0010:ida_free+0x370/0x420 lib/idr.c:525\n Code: 10 42 80 3c 28 (...)\n RSP: 0018:ffffc90015a67300 EFLAGS: 00010246\n RAX: be5130472f5dd000 RBX: 0000000000000033 RCX: 0000000000040000\n RDX: ffffc90009a7a000 RSI: 000000000003ffff RDI: 0000000000040000\n RBP: ffffc90015a673f0 R08: ffffffff81577992 R09: 1ffff92002b4cdb4\n R10: dffffc0000000000 R11: fffff52002b4cdb5 R12: 0000000000000246\n R13: dffffc0000000000 R14: ffffffff8e256b80 R15: 0000000000000246\n FS: 00007fca3f4b46c0(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00007f167a17b978 CR3: 000000001ed26000 CR4: 0000000000350ef0\n Call Trace:\n \u0026lt;TASK\u0026gt;\n btrfs_get_root_ref+0xa48/0xaf0 fs/btrfs/disk-io.c:1346\n create_pending_snapshot+0xff2/0x2bc0 fs/btrfs/transaction.c:1837\n create_pending_snapshots+0x195/0x1d0 fs/btrfs/transaction.c:1931\n btrfs_commit_transaction+0xf1c/0x3740 fs/btrfs/transaction.c:2404\n create_snapshot+0x507/0x880 fs/btrfs/ioctl.c:848\n btrfs_mksubvol+0x5d0/0x750 fs/btrfs/ioctl.c:998\n btrfs_mksnapshot+0xb5/0xf0 fs/btrfs/ioctl.c:1044\n __btrfs_ioctl_snap_create+0x387/0x4b0 fs/btrfs/ioctl.c:1306\n btrfs_ioctl_snap_create_v2+0x1ca/0x400 fs/btrfs/ioctl.c:1393\n btrfs_ioctl+0xa74/0xd40\n vfs_ioctl fs/ioctl.c:51 [inline]\n __do_sys_ioctl fs/ioctl.c:871 [inline]\n __se_sys_ioctl+0xfe/0x170 fs/ioctl.c:857\n do_syscall_64+0xfb/0x240\n entry_SYSCALL_64_after_hwframe+0x6f/0x77\n RIP: 0033:0x7fca3e67dda9\n Code: 28 00 00 00 (...)\n RSP: 002b:00007fca3f4b40c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010\n RAX: ffffffffffffffda RBX: 00007fca3e7abf80 RCX: 00007fca3e67dda9\n RDX: 00000000200005c0 RSI: 0000000050009417 RDI: 0000000000000003\n RBP: 00007fca3e6ca47a R08: 0000000000000000 R09: 0000000000000000\n R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000\n R13: 000000000000000b R14: 00007fca3e7abf80 R15: 00007fff6bf95658\n \u0026lt;/TASK\u0026gt;\r\n\r\nWhere we get an explicit message where we attempt to free an anonymous\ndevice number that is not currently allocated. It happens in a different\ncode path from the example below, at btrfs_get_root_ref(), so this change\nmay not fix the case triggered by sy\n---truncated---(CVE-2024-26792)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nBluetooth: Avoid potential use-after-free in hci_error_reset\r\n\r\nWhile handling the HCI_EV_HARDWARE_ERROR event, if the underlying\nBT controller is not responding, the GPIO reset mechanism would\nfree the hci_dev and lead to a use-after-free in hci_error_reset.\r\n\r\nHere\u0026apos;s the call trace observed on a ChromeOS device with Intel AX201:\n queue_work_on+0x3e/0x6c\n __hci_cmd_sync_sk+0x2ee/0x4c0 [bluetooth \u0026lt;HASH:3b4a6\u0026gt;]\n ? init_wait_entry+0x31/0x31\n __hci_cmd_sync+0x16/0x20 [bluetooth \u0026lt;HASH:3b4a 6\u0026gt;]\n hci_error_reset+0x4f/0xa4 [bluetooth \u0026lt;HASH:3b4a 6\u0026gt;]\n process_one_work+0x1d8/0x33f\n worker_thread+0x21b/0x373\n kthread+0x13a/0x152\n ? pr_cont_work+0x54/0x54\n ? kthread_blkcg+0x31/0x31\n ret_from_fork+0x1f/0x30\r\n\r\nThis patch holds the reference count on the hci_dev while processing\na HCI_EV_HARDWARE_ERROR event to avoid potential crash.(CVE-2024-26801)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: ip_tunnel: prevent perpetual headroom growth\r\n\r\nsyzkaller triggered following kasan splat:\nBUG: KASAN: use-after-free in __skb_flow_dissect+0x19d1/0x7a50 net/core/flow_dissector.c:1170\nRead of size 1 at addr ffff88812fb4000e by task syz-executor183/5191\n[..]\n kasan_report+0xda/0x110 mm/kasan/report.c:588\n __skb_flow_dissect+0x19d1/0x7a50 net/core/flow_dissector.c:1170\n skb_flow_dissect_flow_keys include/linux/skbuff.h:1514 [inline]\n ___skb_get_hash net/core/flow_dissector.c:1791 [inline]\n __skb_get_hash+0xc7/0x540 net/core/flow_dissector.c:1856\n skb_get_hash include/linux/skbuff.h:1556 [inline]\n ip_tunnel_xmit+0x1855/0x33c0 net/ipv4/ip_tunnel.c:748\n ipip_tunnel_xmit+0x3cc/0x4e0 net/ipv4/ipip.c:308\n __netdev_start_xmit include/linux/netdevice.h:4940 [inline]\n netdev_start_xmit include/linux/netdevice.h:4954 [inline]\n xmit_one net/core/dev.c:3548 [inline]\n dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3564\n __dev_queue_xmit+0x7c1/0x3d60 net/core/dev.c:4349\n dev_queue_xmit include/linux/netdevice.h:3134 [inline]\n neigh_connected_output+0x42c/0x5d0 net/core/neighbour.c:1592\n ...\n ip_finish_output2+0x833/0x2550 net/ipv4/ip_output.c:235\n ip_finish_output+0x31/0x310 net/ipv4/ip_output.c:323\n ..\n iptunnel_xmit+0x5b4/0x9b0 net/ipv4/ip_tunnel_core.c:82\n ip_tunnel_xmit+0x1dbc/0x33c0 net/ipv4/ip_tunnel.c:831\n ipgre_xmit+0x4a1/0x980 net/ipv4/ip_gre.c:665\n __netdev_start_xmit include/linux/netdevice.h:4940 [inline]\n netdev_start_xmit include/linux/netdevice.h:4954 [inline]\n xmit_one net/core/dev.c:3548 [inline]\n dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3564\n ...\r\n\r\nThe splat occurs because skb-\u0026gt;data points past skb-\u0026gt;head allocated area.\nThis is because neigh layer does:\n __skb_pull(skb, skb_network_offset(skb));\r\n\r\n... but skb_network_offset() returns a negative offset and __skb_pull()\narg is unsigned. IOW, we skb-\u0026gt;data gets \u0026quot;adjusted\u0026quot; by a huge value.\r\n\r\nThe negative value is returned because skb-\u0026gt;head and skb-\u0026gt;data distance is\nmore than 64k and skb-\u0026gt;network_header (u16) has wrapped around.\r\n\r\nThe bug is in the ip_tunnel infrastructure, which can cause\ndev-\u0026gt;needed_headroom to increment ad infinitum.\r\n\r\nThe syzkaller reproducer consists of packets getting routed via a gre\ntunnel, and route of gre encapsulated packets pointing at another (ipip)\ntunnel. The ipip encapsulation finds gre0 as next output device.\r\n\r\nThis results in the following pattern:\r\n\r\n1). First packet is to be sent out via gre0.\nRoute lookup found an output device, ipip0.\r\n\r\n2).\nip_tunnel_xmit for gre0 bumps gre0-\u0026gt;needed_headroom based on the future\noutput device, rt.dev-\u0026gt;needed_headroom (ipip0).\r\n\r\n3).\nip output / start_xmit moves skb on to ipip0. which runs the same\ncode path again (xmit recursion).\r\n\r\n4).\nRouting step for the post-gre0-encap packet finds gre0 as output device\nto use for ipip0 encapsulated packet.\r\n\r\ntunl0-\u0026gt;needed_headroom is then incremented based on the (already bumped)\ngre0 device headroom.\r\n\r\nThis repeats for every future packet:\r\n\r\ngre0-\u0026gt;needed_headroom gets inflated because previous packets\u0026apos; ipip0 step\nincremented rt-\u0026gt;dev (gre0) headroom, and ipip0 incremented because gre0\nneeded_headroom was increased.\r\n\r\nFor each subsequent packet, gre/ipip0-\u0026gt;needed_headroom grows until\npost-expand-head reallocations result in a skb-\u0026gt;head/data distance of\nmore than 64k.\r\n\r\nOnce that happens, skb-\u0026gt;network_header (u16) wraps around when\npskb_expand_head tries to make sure that skb_network_offset() is unchanged\nafter the headroom expansion/reallocation.\r\n\r\nAfter this skb_network_offset(skb) returns a different (and negative)\nresult post headroom expansion.\r\n\r\nThe next trip to neigh layer (or anything else that would __skb_pull the\nnetwork header) makes skb-\u0026gt;data point to a memory location outside\nskb-\u0026gt;head area.\r\n\r\nv2: Cap the needed_headroom update to an arbitarily chosen upperlimit to\nprevent perpetual increase instead of dropping the headroom increment\ncompletely.(CVE-2024-26804)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetlink: Fix kernel-infoleak-after-free in __skb_datagram_iter\r\n\r\nsyzbot reported the following uninit-value access issue [1]:\r\n\r\nnetlink_to_full_skb() creates a new `skb` and puts the `skb-\u0026gt;data`\npassed as a 1st arg of netlink_to_full_skb() onto new `skb`. The data\nsize is specified as `len` and passed to skb_put_data(). This `len`\nis based on `skb-\u0026gt;end` that is not data offset but buffer offset. The\n`skb-\u0026gt;end` contains data and tailroom. Since the tailroom is not\ninitialized when the new `skb` created, KMSAN detects uninitialized\nmemory area when copying the data.\r\n\r\nThis patch resolved this issue by correct the len from `skb-\u0026gt;end` to\n`skb-\u0026gt;len`, which is the actual data offset.\r\n\r\nBUG: KMSAN: kernel-infoleak-after-free in instrument_copy_to_user include/linux/instrumented.h:114 [inline]\nBUG: KMSAN: kernel-infoleak-after-free in copy_to_user_iter lib/iov_iter.c:24 [inline]\nBUG: KMSAN: kernel-infoleak-after-free in iterate_ubuf include/linux/iov_iter.h:29 [inline]\nBUG: KMSAN: kernel-infoleak-after-free in iterate_and_advance2 include/linux/iov_iter.h:245 [inline]\nBUG: KMSAN: kernel-infoleak-after-free in iterate_and_advance include/linux/iov_iter.h:271 [inline]\nBUG: KMSAN: kernel-infoleak-after-free in _copy_to_iter+0x364/0x2520 lib/iov_iter.c:186\n instrument_copy_to_user include/linux/instrumented.h:114 [inline]\n copy_to_user_iter lib/iov_iter.c:24 [inline]\n iterate_ubuf include/linux/iov_iter.h:29 [inline]\n iterate_and_advance2 include/linux/iov_iter.h:245 [inline]\n iterate_and_advance include/linux/iov_iter.h:271 [inline]\n _copy_to_iter+0x364/0x2520 lib/iov_iter.c:186\n copy_to_iter include/linux/uio.h:197 [inline]\n simple_copy_to_iter+0x68/0xa0 net/core/datagram.c:532\n __skb_datagram_iter+0x123/0xdc0 net/core/datagram.c:420\n skb_copy_datagram_iter+0x5c/0x200 net/core/datagram.c:546\n skb_copy_datagram_msg include/linux/skbuff.h:3960 [inline]\n packet_recvmsg+0xd9c/0x2000 net/packet/af_packet.c:3482\n sock_recvmsg_nosec net/socket.c:1044 [inline]\n sock_recvmsg net/socket.c:1066 [inline]\n sock_read_iter+0x467/0x580 net/socket.c:1136\n call_read_iter include/linux/fs.h:2014 [inline]\n new_sync_read fs/read_write.c:389 [inline]\n vfs_read+0x8f6/0xe00 fs/read_write.c:470\n ksys_read+0x20f/0x4c0 fs/read_write.c:613\n __do_sys_read fs/read_write.c:623 [inline]\n __se_sys_read fs/read_write.c:621 [inline]\n __x64_sys_read+0x93/0xd0 fs/read_write.c:621\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x63/0x6b\r\n\r\nUninit was stored to memory at:\n skb_put_data include/linux/skbuff.h:2622 [inline]\n netlink_to_full_skb net/netlink/af_netlink.c:181 [inline]\n __netlink_deliver_tap_skb net/netlink/af_netlink.c:298 [inline]\n __netlink_deliver_tap+0x5be/0xc90 net/netlink/af_netlink.c:325\n netlink_deliver_tap net/netlink/af_netlink.c:338 [inline]\n netlink_deliver_tap_kernel net/netlink/af_netlink.c:347 [inline]\n netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline]\n netlink_unicast+0x10f1/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:745 [inline]\n ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2584\n ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638\n __sys_sendmsg net/socket.c:2667 [inline]\n __do_sys_sendmsg net/socket.c:2676 [inline]\n __se_sys_sendmsg net/socket.c:2674 [inline]\n __x64_sys_sendmsg+0x307/0x490 net/socket.c:2674\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x63/0x6b\r\n\r\nUninit was created at:\n free_pages_prepare mm/page_alloc.c:1087 [inline]\n free_unref_page_prepare+0xb0/0xa40 mm/page_alloc.c:2347\n free_unref_page_list+0xeb/0x1100 mm/page_alloc.c:2533\n release_pages+0x23d3/0x2410 mm/swap.c:1042\n free_pages_and_swap_cache+0xd9/0xf0 mm/swap_state.c:316\n tlb_batch_pages\n---truncated---(CVE-2024-26805)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nft_chain_filter: handle NETDEV_UNREGISTER for inet/ingress basechain\r\n\r\nRemove netdevice from inet/ingress basechain in case NETDEV_UNREGISTER\nevent is reported, otherwise a stale reference to netdevice remains in\nthe hook list.(CVE-2024-26808)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nft_set_pipapo: release elements in clone only from destroy path\r\n\r\nClone already always provides a current view of the lookup table, use it\nto destroy the set, otherwise it is possible to destroy elements twice.\r\n\r\nThis fix requires:\r\n\r\n 212ed75dc5fb (\u0026quot;netfilter: nf_tables: integrate pipapo into commit protocol\u0026quot;)\r\n\r\nwhich came after:\r\n\r\n 9827a0e6e23b (\u0026quot;netfilter: nft_set_pipapo: release elements in clone from abort path\u0026quot;).(CVE-2024-26809)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nksmbd: validate payload size in ipc response\r\n\r\nIf installing malicious ksmbd-tools, ksmbd.mountd can return invalid ipc\nresponse to ksmbd kernel server. ksmbd should validate payload size of\nipc response from ksmbd.mountd to avoid memory overrun or\nslab-out-of-bounds. This patch validate 3 ipc response that has payload.(CVE-2024-26811)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nvfio/pci: Create persistent INTx handler\r\n\r\nA vulnerability exists where the eventfd for INTx signaling can be\ndeconfigured, which unregisters the IRQ handler but still allows\neventfds to be signaled with a NULL context through the SET_IRQS ioctl\nor through unmask irqfd if the device interrupt is pending.\r\n\r\nIdeally this could be solved with some additional locking; the igate\nmutex serializes the ioctl and config space accesses, and the interrupt\nhandler is unregistered relative to the trigger, but the irqfd path\nruns asynchronous to those. The igate mutex cannot be acquired from the\natomic context of the eventfd wake function. Disabling the irqfd\nrelative to the eventfd registration is potentially incompatible with\nexisting userspace.\r\n\r\nAs a result, the solution implemented here moves configuration of the\nINTx interrupt handler to track the lifetime of the INTx context object\nand irq_type configuration, rather than registration of a particular\ntrigger eventfd. Synchronization is added between the ioctl path and\neventfd_signal() wrapper such that the eventfd trigger can be\ndynamically updated relative to in-flight interrupts or irqfd callbacks.(CVE-2024-26812)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nvfio/fsl-mc: Block calling interrupt handler without trigger\r\n\r\nThe eventfd_ctx trigger pointer of the vfio_fsl_mc_irq object is\ninitially NULL and may become NULL if the user sets the trigger\neventfd to -1. The interrupt handler itself is guaranteed that\ntrigger is always valid between request_irq() and free_irq(), but\nthe loopback testing mechanisms to invoke the handler function\nneed to test the trigger. The triggering and setting ioctl paths\nboth make use of igate and are therefore mutually exclusive.\r\n\r\nThe vfio-fsl-mc driver does not make use of irqfds, nor does it\nsupport any sort of masking operations, therefore unlike vfio-pci\nand vfio-platform, the flow can remain essentially unchanged.(CVE-2024-26814)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\namdkfd: use calloc instead of kzalloc to avoid integer overflow\r\n\r\nThis uses calloc instead of doing the multiplication which might\noverflow.(CVE-2024-26817)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncifs: fix underflow in parse_server_interfaces()\r\n\r\nIn this loop, we step through the buffer and after each item we check\nif the size_left is greater than the minimum size we need. However,\nthe problem is that \u0026quot;bytes_left\u0026quot; is type ssize_t while sizeof() is type\nsize_t. That means that because of type promotion, the comparison is\ndone as an unsigned and if we have negative bytes left the loop\ncontinues instead of ending.(CVE-2024-26828)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: ir_toy: fix a memleak in irtoy_tx\r\n\r\nWhen irtoy_command fails, buf should be freed since it is allocated by\nirtoy_tx, or there is a memleak.(CVE-2024-26829)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nIB/hfi1: Fix a memleak in init_credit_return\r\n\r\nWhen dma_alloc_coherent fails to allocate dd-\u0026gt;cr_base[i].va,\ninit_credit_return should deallocate dd-\u0026gt;cr_base and\ndd-\u0026gt;cr_base[i] that allocated before. Or those resources\nwould be never freed and a memleak is triggered.(CVE-2024-26839)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncachefiles: fix memory leak in cachefiles_add_cache()\r\n\r\nThe following memory leak was reported after unbinding /dev/cachefiles:\r\n\r\n==================================================================\nunreferenced object 0xffff9b674176e3c0 (size 192):\n comm \u0026quot;cachefilesd2\u0026quot;, pid 680, jiffies 4294881224\n hex dump (first 32 bytes):\n 01 00 00 00 00 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 (crc ea38a44b):\n [\u0026lt;ffffffff8eb8a1a5\u0026gt;] kmem_cache_alloc+0x2d5/0x370\n [\u0026lt;ffffffff8e917f86\u0026gt;] prepare_creds+0x26/0x2e0\n [\u0026lt;ffffffffc002eeef\u0026gt;] cachefiles_determine_cache_security+0x1f/0x120\n [\u0026lt;ffffffffc00243ec\u0026gt;] cachefiles_add_cache+0x13c/0x3a0\n [\u0026lt;ffffffffc0025216\u0026gt;] cachefiles_daemon_write+0x146/0x1c0\n [\u0026lt;ffffffff8ebc4a3b\u0026gt;] vfs_write+0xcb/0x520\n [\u0026lt;ffffffff8ebc5069\u0026gt;] ksys_write+0x69/0xf0\n [\u0026lt;ffffffff8f6d4662\u0026gt;] do_syscall_64+0x72/0x140\n [\u0026lt;ffffffff8f8000aa\u0026gt;] entry_SYSCALL_64_after_hwframe+0x6e/0x76\n==================================================================\r\n\r\nPut the reference count of cache_cred in cachefiles_daemon_unbind() to\nfix the problem. And also put cache_cred in cachefiles_add_cache() error\nbranch to avoid memory leaks.(CVE-2024-26840)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nefi: runtime: Fix potential overflow of soft-reserved region size\r\n\r\nmd_size will have been narrowed if we have \u0026gt;= 4GB worth of pages in a\nsoft-reserved region.(CVE-2024-26843)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnvme-fc: do not wait in vain when unloading module\r\n\r\nThe module exit path has race between deleting all controllers and\nfreeing \u0026apos;left over IDs\u0026apos;. To prevent double free a synchronization\nbetween nvme_delete_ctrl and ida_destroy has been added by the initial\ncommit.\r\n\r\nThere is some logic around trying to prevent from hanging forever in\nwait_for_completion, though it does not handling all cases. E.g.\nblktests is able to reproduce the situation where the module unload\nhangs forever.\r\n\r\nIf we completely rely on the cleanup code executed from the\nnvme_delete_ctrl path, all IDs will be freed eventually. This makes\ncalling ida_destroy unnecessary. We only have to ensure that all\nnvme_delete_ctrl code has been executed before we leave\nnvme_fc_exit_module. This is done by flushing the nvme_delete_wq\nworkqueue.\r\n\r\nWhile at it, remove the unused nvme_fc_wq workqueue too.(CVE-2024-26846)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/ipv6: avoid possible UAF in ip6_route_mpath_notify()\r\n\r\nsyzbot found another use-after-free in ip6_route_mpath_notify() [1]\r\n\r\nCommit f7225172f25a (\u0026quot;net/ipv6: prevent use after free in\nip6_route_mpath_notify\u0026quot;) was not able to fix the root cause.\r\n\r\nWe need to defer the fib6_info_release() calls after\nip6_route_mpath_notify(), in the cleanup phase.\r\n\r\n[1]\nBUG: KASAN: slab-use-after-free in rt6_fill_node+0x1460/0x1ac0\nRead of size 4 at addr ffff88809a07fc64 by task syz-executor.2/23037\r\n\r\nCPU: 0 PID: 23037 Comm: syz-executor.2 Not tainted 6.8.0-rc4-syzkaller-01035-gea7f3cfaa588 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0x1e7/0x2e0 lib/dump_stack.c:106\n print_address_description mm/kasan/report.c:377 [inline]\n print_report+0x167/0x540 mm/kasan/report.c:488\n kasan_report+0x142/0x180 mm/kasan/report.c:601\n rt6_fill_node+0x1460/0x1ac0\n inet6_rt_notify+0x13b/0x290 net/ipv6/route.c:6184\n ip6_route_mpath_notify net/ipv6/route.c:5198 [inline]\n ip6_route_multipath_add net/ipv6/route.c:5404 [inline]\n inet6_rtm_newroute+0x1d0f/0x2300 net/ipv6/route.c:5517\n rtnetlink_rcv_msg+0x885/0x1040 net/core/rtnetlink.c:6597\n netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2543\n netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline]\n netlink_unicast+0x7ea/0x980 net/netlink/af_netlink.c:1367\n netlink_sendmsg+0xa3b/0xd70 net/netlink/af_netlink.c:1908\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg+0x221/0x270 net/socket.c:745\n ____sys_sendmsg+0x525/0x7d0 net/socket.c:2584\n ___sys_sendmsg net/socket.c:2638 [inline]\n __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667\n do_syscall_64+0xf9/0x240\n entry_SYSCALL_64_after_hwframe+0x6f/0x77\nRIP: 0033:0x7f73dd87dda9\nCode: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007f73de6550c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e\nRAX: ffffffffffffffda RBX: 00007f73dd9ac050 RCX: 00007f73dd87dda9\nRDX: 0000000000000000 RSI: 0000000020000140 RDI: 0000000000000005\nRBP: 00007f73dd8ca47a R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000\nR13: 000000000000006e R14: 00007f73dd9ac050 R15: 00007ffdbdeb7858\n \u0026lt;/TASK\u0026gt;\r\n\r\nAllocated by task 23037:\n kasan_save_stack mm/kasan/common.c:47 [inline]\n kasan_save_track+0x3f/0x80 mm/kasan/common.c:68\n poison_kmalloc_redzone mm/kasan/common.c:372 [inline]\n __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:389\n kasan_kmalloc include/linux/kasan.h:211 [inline]\n __do_kmalloc_node mm/slub.c:3981 [inline]\n __kmalloc+0x22e/0x490 mm/slub.c:3994\n kmalloc include/linux/slab.h:594 [inline]\n kzalloc include/linux/slab.h:711 [inline]\n fib6_info_alloc+0x2e/0xf0 net/ipv6/ip6_fib.c:155\n ip6_route_info_create+0x445/0x12b0 net/ipv6/route.c:3758\n ip6_route_multipath_add net/ipv6/route.c:5298 [inline]\n inet6_rtm_newroute+0x744/0x2300 net/ipv6/route.c:5517\n rtnetlink_rcv_msg+0x885/0x1040 net/core/rtnetlink.c:6597\n netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2543\n netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline]\n netlink_unicast+0x7ea/0x980 net/netlink/af_netlink.c:1367\n netlink_sendmsg+0xa3b/0xd70 net/netlink/af_netlink.c:1908\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg+0x221/0x270 net/socket.c:745\n ____sys_sendmsg+0x525/0x7d0 net/socket.c:2584\n ___sys_sendmsg net/socket.c:2638 [inline]\n __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667\n do_syscall_64+0xf9/0x240\n entry_SYSCALL_64_after_hwframe+0x6f/0x77\r\n\r\nFreed by task 16:\n kasan_save_stack mm/kasan/common.c:47 [inline]\n kasan_save_track+0x3f/0x80 mm/kasan/common.c:68\n kasan_save_free_info+0x4e/0x60 mm/kasan/generic.c:640\n poison_slab_object+0xa6/0xe0 m\n---truncated---(CVE-2024-26852)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: ice: Fix potential NULL pointer dereference in ice_bridge_setlink()\r\n\r\nThe function ice_bridge_setlink() may encounter a NULL pointer dereference\nif nlmsg_find_attr() returns NULL and br_spec is dereferenced subsequently\nin nla_for_each_nested(). To address this issue, add a check to ensure that\nbr_spec is not NULL before proceeding with the nested attribute iteration.(CVE-2024-26855)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/bnx2x: Prevent access to a freed page in page_pool\r\n\r\nFix race condition leading to system crash during EEH error handling\r\n\r\nDuring EEH error recovery, the bnx2x driver\u0026apos;s transmit timeout logic\ncould cause a race condition when handling reset tasks. The\nbnx2x_tx_timeout() schedules reset tasks via bnx2x_sp_rtnl_task(),\nwhich ultimately leads to bnx2x_nic_unload(). In bnx2x_nic_unload()\nSGEs are freed using bnx2x_free_rx_sge_range(). However, this could\noverlap with the EEH driver\u0026apos;s attempt to reset the device using\nbnx2x_io_slot_reset(), which also tries to free SGEs. This race\ncondition can result in system crashes due to accessing freed memory\nlocations in bnx2x_free_rx_sge()\r\n\r\n799 static inline void bnx2x_free_rx_sge(struct bnx2x *bp,\n800\t\t\t\tstruct bnx2x_fastpath *fp, u16 index)\n801 {\n802\tstruct sw_rx_page *sw_buf = \u0026amp;fp-\u0026gt;rx_page_ring[index];\n803 struct page *page = sw_buf-\u0026gt;page;\n....\nwhere sw_buf was set to NULL after the call to dma_unmap_page()\nby the preceding thread.\r\n\r\n EEH: Beginning: \u0026apos;slot_reset\u0026apos;\n PCI 0011:01:00.0#10000: EEH: Invoking bnx2x-\u0026gt;slot_reset()\n bnx2x: [bnx2x_io_slot_reset:14228(eth1)]IO slot reset initializing...\n bnx2x 0011:01:00.0: enabling device (0140 -\u0026gt; 0142)\n bnx2x: [bnx2x_io_slot_reset:14244(eth1)]IO slot reset --\u0026gt; driver unload\n Kernel attempted to read user page (0) - exploit attempt? (uid: 0)\n BUG: Kernel NULL pointer dereference on read at 0x00000000\n Faulting instruction address: 0xc0080000025065fc\n Oops: Kernel access of bad area, sig: 11 [#1]\n .....\n Call Trace:\n [c000000003c67a20] [c00800000250658c] bnx2x_io_slot_reset+0x204/0x610 [bnx2x] (unreliable)\n [c000000003c67af0] [c0000000000518a8] eeh_report_reset+0xb8/0xf0\n [c000000003c67b60] [c000000000052130] eeh_pe_report+0x180/0x550\n [c000000003c67c70] [c00000000005318c] eeh_handle_normal_event+0x84c/0xa60\n [c000000003c67d50] [c000000000053a84] eeh_event_handler+0xf4/0x170\n [c000000003c67da0] [c000000000194c58] kthread+0x1c8/0x1d0\n [c000000003c67e10] [c00000000000cf64] ret_from_kernel_thread+0x5c/0x64\r\n\r\nTo solve this issue, we need to verify page pool allocations before\nfreeing.(CVE-2024-26859)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npacket: annotate data-races around ignore_outgoing\r\n\r\nignore_outgoing is read locklessly from dev_queue_xmit_nit()\nand packet_getsockopt()\r\n\r\nAdd appropriate READ_ONCE()/WRITE_ONCE() annotations.\r\n\r\nsyzbot reported:\r\n\r\nBUG: KCSAN: data-race in dev_queue_xmit_nit / packet_setsockopt\r\n\r\nwrite to 0xffff888107804542 of 1 bytes by task 22618 on cpu 0:\n packet_setsockopt+0xd83/0xfd0 net/packet/af_packet.c:4003\n do_sock_setsockopt net/socket.c:2311 [inline]\n __sys_setsockopt+0x1d8/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+0x66/0x80 net/socket.c:2340\n do_syscall_64+0xd3/0x1d0\n entry_SYSCALL_64_after_hwframe+0x6d/0x75\r\n\r\nread to 0xffff888107804542 of 1 bytes by task 27 on cpu 1:\n dev_queue_xmit_nit+0x82/0x620 net/core/dev.c:2248\n xmit_one net/core/dev.c:3527 [inline]\n dev_hard_start_xmit+0xcc/0x3f0 net/core/dev.c:3547\n __dev_queue_xmit+0xf24/0x1dd0 net/core/dev.c:4335\n dev_queue_xmit include/linux/netdevice.h:3091 [inline]\n batadv_send_skb_packet+0x264/0x300 net/batman-adv/send.c:108\n batadv_send_broadcast_skb+0x24/0x30 net/batman-adv/send.c:127\n batadv_iv_ogm_send_to_if net/batman-adv/bat_iv_ogm.c:392 [inline]\n batadv_iv_ogm_emit net/batman-adv/bat_iv_ogm.c:420 [inline]\n batadv_iv_send_outstanding_bat_ogm_packet+0x3f0/0x4b0 net/batman-adv/bat_iv_ogm.c:1700\n process_one_work kernel/workqueue.c:3254 [inline]\n process_scheduled_works+0x465/0x990 kernel/workqueue.c:3335\n worker_thread+0x526/0x730 kernel/workqueue.c:3416\n kthread+0x1d1/0x210 kernel/kthread.c:388\n ret_from_fork+0x4b/0x60 arch/x86/kernel/process.c:147\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:243\r\n\r\nvalue changed: 0x00 -\u0026gt; 0x01\r\n\r\nReported by Kernel Concurrency Sanitizer on:\nCPU: 1 PID: 27 Comm: kworker/u8:1 Tainted: G W 6.8.0-syzkaller-08073-g480e035fc4c7 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024\nWorkqueue: bat_events batadv_iv_send_outstanding_bat_ogm_packet(CVE-2024-26862)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nhsr: Fix uninit-value access in hsr_get_node()\r\n\r\nKMSAN reported the following uninit-value access issue [1]:\r\n\r\n=====================================================\nBUG: KMSAN: uninit-value in hsr_get_node+0xa2e/0xa40 net/hsr/hsr_framereg.c:246\n hsr_get_node+0xa2e/0xa40 net/hsr/hsr_framereg.c:246\n fill_frame_info net/hsr/hsr_forward.c:577 [inline]\n hsr_forward_skb+0xe12/0x30e0 net/hsr/hsr_forward.c:615\n hsr_dev_xmit+0x1a1/0x270 net/hsr/hsr_device.c:223\n __netdev_start_xmit include/linux/netdevice.h:4940 [inline]\n netdev_start_xmit include/linux/netdevice.h:4954 [inline]\n xmit_one net/core/dev.c:3548 [inline]\n dev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3564\n __dev_queue_xmit+0x33b8/0x5130 net/core/dev.c:4349\n dev_queue_xmit include/linux/netdevice.h:3134 [inline]\n packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276\n packet_snd net/packet/af_packet.c:3087 [inline]\n packet_sendmsg+0x8b1d/0x9f30 net/packet/af_packet.c:3119\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg net/socket.c:745 [inline]\n __sys_sendto+0x735/0xa10 net/socket.c:2191\n __do_sys_sendto net/socket.c:2203 [inline]\n __se_sys_sendto net/socket.c:2199 [inline]\n __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x63/0x6b\r\n\r\nUninit was created at:\n slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768\n slab_alloc_node mm/slub.c:3478 [inline]\n kmem_cache_alloc_node+0x5e9/0xb10 mm/slub.c:3523\n kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560\n __alloc_skb+0x318/0x740 net/core/skbuff.c:651\n alloc_skb include/linux/skbuff.h:1286 [inline]\n alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6334\n sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2787\n packet_alloc_skb net/packet/af_packet.c:2936 [inline]\n packet_snd net/packet/af_packet.c:3030 [inline]\n packet_sendmsg+0x70e8/0x9f30 net/packet/af_packet.c:3119\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg net/socket.c:745 [inline]\n __sys_sendto+0x735/0xa10 net/socket.c:2191\n __do_sys_sendto net/socket.c:2203 [inline]\n __se_sys_sendto net/socket.c:2199 [inline]\n __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x63/0x6b\r\n\r\nCPU: 1 PID: 5033 Comm: syz-executor334 Not tainted 6.7.0-syzkaller-00562-g9f8413c4a66f #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023\n=====================================================\r\n\r\nIf the packet type ID field in the Ethernet header is either ETH_P_PRP or\nETH_P_HSR, but it is not followed by an HSR tag, hsr_get_skb_sequence_nr()\nreads an invalid value as a sequence number. This causes the above issue.\r\n\r\nThis patch fixes the issue by returning NULL if the Ethernet header is not\nfollowed by an HSR tag.(CVE-2024-26863)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nrds: tcp: Fix use-after-free of net in reqsk_timer_handler().\r\n\r\nsyzkaller reported a warning of netns tracker [0] followed by KASAN\nsplat [1] and another ref tracker warning [1].\r\n\r\nsyzkaller could not find a repro, but in the log, the only suspicious\nsequence was as follows:\r\n\r\n 18:26:22 executing program 1:\n r0 = socket$inet6_mptcp(0xa, 0x1, 0x106)\n ...\n connect$inet6(r0, \u0026amp;(0x7f0000000080)={0xa, 0x4001, 0x0, @loopback}, 0x1c) (async)\r\n\r\nThe notable thing here is 0x4001 in connect(), which is RDS_TCP_PORT.\r\n\r\nSo, the scenario would be:\r\n\r\n 1. unshare(CLONE_NEWNET) creates a per netns tcp listener in\n rds_tcp_listen_init().\n 2. syz-executor connect()s to it and creates a reqsk.\n 3. syz-executor exit()s immediately.\n 4. netns is dismantled. [0]\n 5. reqsk timer is fired, and UAF happens while freeing reqsk. [1]\n 6. listener is freed after RCU grace period. [2]\r\n\r\nBasically, reqsk assumes that the listener guarantees netns safety\nuntil all reqsk timers are expired by holding the listener\u0026apos;s refcount.\nHowever, this was not the case for kernel sockets.\r\n\r\nCommit 740ea3c4a0b2 (\u0026quot;tcp: Clean up kernel listener\u0026apos;s reqsk in\ninet_twsk_purge()\u0026quot;) fixed this issue only for per-netns ehash.\r\n\r\nLet\u0026apos;s apply the same fix for the global ehash.\r\n\r\n[0]:\nref_tracker: net notrefcnt@0000000065449cc3 has 1/1 users at\n sk_alloc (./include/net/net_namespace.h:337 net/core/sock.c:2146)\n inet6_create (net/ipv6/af_inet6.c:192 net/ipv6/af_inet6.c:119)\n __sock_create (net/socket.c:1572)\n rds_tcp_listen_init (net/rds/tcp_listen.c:279)\n rds_tcp_init_net (net/rds/tcp.c:577)\n ops_init (net/core/net_namespace.c:137)\n setup_net (net/core/net_namespace.c:340)\n copy_net_ns (net/core/net_namespace.c:497)\n create_new_namespaces (kernel/nsproxy.c:110)\n unshare_nsproxy_namespaces (kernel/nsproxy.c:228 (discriminator 4))\n ksys_unshare (kernel/fork.c:3429)\n __x64_sys_unshare (kernel/fork.c:3496)\n do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83)\n entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:129)\n...\nWARNING: CPU: 0 PID: 27 at lib/ref_tracker.c:179 ref_tracker_dir_exit (lib/ref_tracker.c:179)\r\n\r\n[1]:\nBUG: KASAN: slab-use-after-free in inet_csk_reqsk_queue_drop (./include/net/inet_hashtables.h:180 net/ipv4/inet_connection_sock.c:952 net/ipv4/inet_connection_sock.c:966)\nRead of size 8 at addr ffff88801b370400 by task swapper/0/0\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;IRQ\u0026gt;\n dump_stack_lvl (lib/dump_stack.c:107 (discriminator 1))\n print_report (mm/kasan/report.c:378 mm/kasan/report.c:488)\n kasan_report (mm/kasan/report.c:603)\n inet_csk_reqsk_queue_drop (./include/net/inet_hashtables.h:180 net/ipv4/inet_connection_sock.c:952 net/ipv4/inet_connection_sock.c:966)\n reqsk_timer_handler (net/ipv4/inet_connection_sock.c:979 net/ipv4/inet_connection_sock.c:1092)\n call_timer_fn (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:207 ./include/trace/events/timer.h:127 kernel/time/timer.c:1701)\n __run_timers.part.0 (kernel/time/timer.c:1752 kernel/time/timer.c:2038)\n run_timer_softirq (kernel/time/timer.c:2053)\n __do_softirq (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:207 ./include/trace/events/irq.h:142 kernel/softirq.c:554)\n irq_exit_rcu (kernel/softirq.c:427 kernel/softirq.c:632 kernel/softirq.c:644)\n sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1076 (discriminator 14))\n \u0026lt;/IRQ\u0026gt;\r\n\r\nAllocated by task 258 on cpu 0 at 83.612050s:\n kasan_save_stack (mm/kasan/common.c:48)\n kasan_save_track (mm/kasan/common.c:68)\n __kasan_slab_alloc (mm/kasan/common.c:343)\n kmem_cache_alloc (mm/slub.c:3813 mm/slub.c:3860 mm/slub.c:3867)\n copy_net_ns (./include/linux/slab.h:701 net/core/net_namespace.c:421 net/core/net_namespace.c:480)\n create_new_namespaces (kernel/nsproxy.c:110)\n unshare_nsproxy_name\n---truncated---(CVE-2024-26865)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nf2fs: fix to truncate meta inode pages forcely\r\n\r\nBelow race case can cause data corruption:\r\n\r\nThread A\t\t\t\tGC thread\n\t\t\t\t\t- gc_data_segment\n\t\t\t\t\t - ra_data_block\n\t\t\t\t\t - locked meta_inode page\n- f2fs_inplace_write_data\n - invalidate_mapping_pages\n : fail to invalidate meta_inode page\n due to lock failure or dirty|writeback\n status\n - f2fs_submit_page_bio\n : write last dirty data to old blkaddr\n\t\t\t\t\t - move_data_block\n\t\t\t\t\t - load old data from meta_inode page\n\t\t\t\t\t - f2fs_submit_page_write\n\t\t\t\t\t : write old data to new blkaddr\r\n\r\nBecause invalidate_mapping_pages() will skip invalidating page which\nhas unclear status including locked, dirty, writeback and so on, so\nwe need to use truncate_inode_pages_range() instead of\ninvalidate_mapping_pages() to make sure meta_inode page will be dropped.(CVE-2024-26869)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nNFSv4.2: fix nfs4_listxattr kernel BUG at mm/usercopy.c:102\r\n\r\nA call to listxattr() with a buffer size = 0 returns the actual\nsize of the buffer needed for a subsequent call. When size \u0026gt; 0,\nnfs4_listxattr() does not return an error because either\ngeneric_listxattr() or nfs4_listxattr_nfs4_label() consumes\nexactly all the bytes then size is 0 when calling\nnfs4_listxattr_nfs4_user() which then triggers the following\nkernel BUG:\r\n\r\n [ 99.403778] kernel BUG at mm/usercopy.c:102!\n [ 99.404063] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP\n [ 99.408463] CPU: 0 PID: 3310 Comm: python3 Not tainted 6.6.0-61.fc40.aarch64 #1\n [ 99.415827] Call trace:\n [ 99.415985] usercopy_abort+0x70/0xa0\n [ 99.416227] __check_heap_object+0x134/0x158\n [ 99.416505] check_heap_object+0x150/0x188\n [ 99.416696] __check_object_size.part.0+0x78/0x168\n [ 99.416886] __check_object_size+0x28/0x40\n [ 99.417078] listxattr+0x8c/0x120\n [ 99.417252] path_listxattr+0x78/0xe0\n [ 99.417476] __arm64_sys_listxattr+0x28/0x40\n [ 99.417723] invoke_syscall+0x78/0x100\n [ 99.417929] el0_svc_common.constprop.0+0x48/0xf0\n [ 99.418186] do_el0_svc+0x24/0x38\n [ 99.418376] el0_svc+0x3c/0x110\n [ 99.418554] el0t_64_sync_handler+0x120/0x130\n [ 99.418788] el0t_64_sync+0x194/0x198\n [ 99.418994] Code: aa0003e3 d000a3e0 91310000 97f49bdb (d4210000)\r\n\r\nIssue is reproduced when generic_listxattr() returns \u0026apos;system.nfs4_acl\u0026apos;,\nthus calling lisxattr() with size = 16 will trigger the bug.\r\n\r\nAdd check on nfs4_listxattr() to return ERANGE error when it is\ncalled with size \u0026gt; 0 and the return value is greater than size.(CVE-2024-26870)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nRDMA/srpt: Do not register event handler until srpt device is fully setup\r\n\r\nUpon rare occasions, KASAN reports a use-after-free Write\nin srpt_refresh_port().\r\n\r\nThis seems to be because an event handler is registered before the\nsrpt device is fully setup and a race condition upon error may leave a\npartially setup event handler in place.\r\n\r\nInstead, only register the event handler after srpt device initialization\nis complete.(CVE-2024-26872)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: pvrusb2: fix uaf in pvr2_context_set_notify\r\n\r\n[Syzbot reported]\nBUG: KASAN: slab-use-after-free in pvr2_context_set_notify+0x2c4/0x310 drivers/media/usb/pvrusb2/pvrusb2-context.c:35\nRead of size 4 at addr ffff888113aeb0d8 by task kworker/1:1/26\r\n\r\nCPU: 1 PID: 26 Comm: kworker/1:1 Not tainted 6.8.0-rc1-syzkaller-00046-gf1a27f081c1f #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024\nWorkqueue: usb_hub_wq hub_event\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0xd9/0x1b0 lib/dump_stack.c:106\n print_address_description mm/kasan/report.c:377 [inline]\n print_report+0xc4/0x620 mm/kasan/report.c:488\n kasan_report+0xda/0x110 mm/kasan/report.c:601\n pvr2_context_set_notify+0x2c4/0x310 drivers/media/usb/pvrusb2/pvrusb2-context.c:35\n pvr2_context_notify drivers/media/usb/pvrusb2/pvrusb2-context.c:95 [inline]\n pvr2_context_disconnect+0x94/0xb0 drivers/media/usb/pvrusb2/pvrusb2-context.c:272\r\n\r\nFreed by task 906:\nkasan_save_stack+0x33/0x50 mm/kasan/common.c:47\nkasan_save_track+0x14/0x30 mm/kasan/common.c:68\nkasan_save_free_info+0x3f/0x60 mm/kasan/generic.c:640\npoison_slab_object mm/kasan/common.c:241 [inline]\n__kasan_slab_free+0x106/0x1b0 mm/kasan/common.c:257\nkasan_slab_free include/linux/kasan.h:184 [inline]\nslab_free_hook mm/slub.c:2121 [inline]\nslab_free mm/slub.c:4299 [inline]\nkfree+0x105/0x340 mm/slub.c:4409\npvr2_context_check drivers/media/usb/pvrusb2/pvrusb2-context.c:137 [inline]\npvr2_context_thread_func+0x69d/0x960 drivers/media/usb/pvrusb2/pvrusb2-context.c:158\r\n\r\n[Analyze]\nTask A set disconnect_flag = !0, which resulted in Task B\u0026apos;s condition being met\nand releasing mp, leading to this issue.\r\n\r\n[Fix]\nPlace the disconnect_flag assignment operation after all code in pvr2_context_disconnect()\nto avoid this issue.(CVE-2024-26875)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nquota: Fix potential NULL pointer dereference\r\n\r\nBelow race may cause NULL pointer dereference\r\n\r\nP1\t\t\t\t\tP2\ndquot_free_inode\t\t\tquota_off\n\t\t\t\t\t drop_dquot_ref\n\t\t\t\t\t remove_dquot_ref\n\t\t\t\t\t dquots = i_dquot(inode)\n dquots = i_dquot(inode)\n srcu_read_lock\n dquots[cnt]) != NULL (1)\n\t\t\t\t\t dquots[type] = NULL (2)\n spin_lock(\u0026amp;dquots[cnt]-\u0026gt;dq_dqb_lock) (3)\n ....\r\n\r\nIf dquot_free_inode(or other routines) checks inode\u0026apos;s quota pointers (1)\nbefore quota_off sets it to NULL(2) and use it (3) after that, NULL pointer\ndereference will be triggered.\r\n\r\nSo let\u0026apos;s fix it by using a temporary pointer to avoid this issue.(CVE-2024-26878)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndm: call the resume method on internal suspend\r\n\r\nThere is this reported crash when experimenting with the lvm2 testsuite.\nThe list corruption is caused by the fact that the postsuspend and resume\nmethods were not paired correctly; there were two consecutive calls to the\norigin_postsuspend function. The second call attempts to remove the\n\u0026quot;hash_list\u0026quot; entry from a list, while it was already removed by the first\ncall.\r\n\r\nFix __dm_internal_resume so that it calls the preresume and resume\nmethods of the table\u0026apos;s targets.\r\n\r\nIf a preresume method of some target fails, we are in a tricky situation.\nWe can\u0026apos;t return an error because dm_internal_resume isn\u0026apos;t supposed to\nreturn errors. We can\u0026apos;t return success, because then the \u0026quot;resume\u0026quot; and\n\u0026quot;postsuspend\u0026quot; methods would not be paired correctly. So, we set the\nDMF_SUSPENDED flag and we fake normal suspend - it may confuse userspace\ntools, but it won\u0026apos;t cause a kernel crash.\r\n\r\n------------[ cut here ]------------\nkernel BUG at lib/list_debug.c:56!\ninvalid opcode: 0000 [#1] PREEMPT SMP\nCPU: 1 PID: 8343 Comm: dmsetup Not tainted 6.8.0-rc6 #4\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014\nRIP: 0010:__list_del_entry_valid_or_report+0x77/0xc0\n\u0026lt;snip\u0026gt;\nRSP: 0018:ffff8881b831bcc0 EFLAGS: 00010282\nRAX: 000000000000004e RBX: ffff888143b6eb80 RCX: 0000000000000000\nRDX: 0000000000000001 RSI: ffffffff819053d0 RDI: 00000000ffffffff\nRBP: ffff8881b83a3400 R08: 00000000fffeffff R09: 0000000000000058\nR10: 0000000000000000 R11: ffffffff81a24080 R12: 0000000000000001\nR13: ffff88814538e000 R14: ffff888143bc6dc0 R15: ffffffffa02e4bb0\nFS: 00000000f7c0f780(0000) GS:ffff8893f0a40000(0000) knlGS:0000000000000000\nCS: 0010 DS: 002b ES: 002b CR0: 0000000080050033\nCR2: 0000000057fb5000 CR3: 0000000143474000 CR4: 00000000000006b0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? die+0x2d/0x80\n ? do_trap+0xeb/0xf0\n ? __list_del_entry_valid_or_report+0x77/0xc0\n ? do_error_trap+0x60/0x80\n ? __list_del_entry_valid_or_report+0x77/0xc0\n ? exc_invalid_op+0x49/0x60\n ? __list_del_entry_valid_or_report+0x77/0xc0\n ? asm_exc_invalid_op+0x16/0x20\n ? table_deps+0x1b0/0x1b0 [dm_mod]\n ? __list_del_entry_valid_or_report+0x77/0xc0\n origin_postsuspend+0x1a/0x50 [dm_snapshot]\n dm_table_postsuspend_targets+0x34/0x50 [dm_mod]\n dm_suspend+0xd8/0xf0 [dm_mod]\n dev_suspend+0x1f2/0x2f0 [dm_mod]\n ? table_deps+0x1b0/0x1b0 [dm_mod]\n ctl_ioctl+0x300/0x5f0 [dm_mod]\n dm_compat_ctl_ioctl+0x7/0x10 [dm_mod]\n __x64_compat_sys_ioctl+0x104/0x170\n do_syscall_64+0x184/0x1b0\n entry_SYSCALL_64_after_hwframe+0x46/0x4e\nRIP: 0033:0xf7e6aead\n\u0026lt;snip\u0026gt;\n---[ end trace 0000000000000000 ]---(CVE-2024-26880)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfirmware: arm_scmi: Fix double free in SMC transport cleanup path\r\n\r\nWhen the generic SCMI code tears down a channel, it calls the chan_free\ncallback function, defined by each transport. Since multiple protocols\nmight share the same transport_info member, chan_free() might want to\nclean up the same member multiple times within the given SCMI transport\nimplementation. In this case, it is SMC transport. This will lead to a NULL\npointer dereference at the second time:\r\n\r\n | scmi_protocol scmi_dev.1: Enabled polling mode TX channel - prot_id:16\n | arm-scmi firmware:scmi: SCMI Notifications - Core Enabled.\n | arm-scmi firmware:scmi: unable to communicate with SCMI\n | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000\n | Mem abort info:\n | ESR = 0x0000000096000004\n | EC = 0x25: DABT (current EL), IL = 32 bits\n | SET = 0, FnV = 0\n | EA = 0, S1PTW = 0\n | FSC = 0x04: level 0 translation fault\n | Data abort info:\n | ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000\n | CM = 0, WnR = 0, TnD = 0, TagAccess = 0\n | GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\n | user pgtable: 4k pages, 48-bit VAs, pgdp=0000000881ef8000\n | [0000000000000000] pgd=0000000000000000, p4d=0000000000000000\n | Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP\n | Modules linked in:\n | CPU: 4 PID: 1 Comm: swapper/0 Not tainted 6.7.0-rc2-00124-g455ef3d016c9-dirty #793\n | Hardware name: FVP Base RevC (DT)\n | pstate: 61400009 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)\n | pc : smc_chan_free+0x3c/0x6c\n | lr : smc_chan_free+0x3c/0x6c\n | Call trace:\n | smc_chan_free+0x3c/0x6c\n | idr_for_each+0x68/0xf8\n | scmi_cleanup_channels.isra.0+0x2c/0x58\n | scmi_probe+0x434/0x734\n | platform_probe+0x68/0xd8\n | really_probe+0x110/0x27c\n | __driver_probe_device+0x78/0x12c\n | driver_probe_device+0x3c/0x118\n | __driver_attach+0x74/0x128\n | bus_for_each_dev+0x78/0xe0\n | driver_attach+0x24/0x30\n | bus_add_driver+0xe4/0x1e8\n | driver_register+0x60/0x128\n | __platform_driver_register+0x28/0x34\n | scmi_driver_init+0x84/0xc0\n | do_one_initcall+0x78/0x33c\n | kernel_init_freeable+0x2b8/0x51c\n | kernel_init+0x24/0x130\n | ret_from_fork+0x10/0x20\n | Code: f0004701 910a0021 aa1403e5 97b91c70 (b9400280)\n | ---[ end trace 0000000000000000 ]---\r\n\r\nSimply check for the struct pointer being NULL before trying to access\nits members, to avoid this situation.\r\n\r\nThis was found when a transport doesn\u0026apos;t really work (for instance no SMC\nservice), the probe routines then tries to clean up, and triggers a crash.(CVE-2024-26893)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: wilc1000: prevent use-after-free on vif when cleaning up all interfaces\r\n\r\nwilc_netdev_cleanup currently triggers a KASAN warning, which can be\nobserved on interface registration error path, or simply by\nremoving the module/unbinding device from driver:\r\n\r\necho spi0.1 \u0026gt; /sys/bus/spi/drivers/wilc1000_spi/unbind\r\n\r\n==================================================================\nBUG: KASAN: slab-use-after-free in wilc_netdev_cleanup+0x508/0x5cc\nRead of size 4 at addr c54d1ce8 by task sh/86\r\n\r\nCPU: 0 PID: 86 Comm: sh Not tainted 6.8.0-rc1+ #117\nHardware name: Atmel SAMA5\n unwind_backtrace from show_stack+0x18/0x1c\n show_stack from dump_stack_lvl+0x34/0x58\n dump_stack_lvl from print_report+0x154/0x500\n print_report from kasan_report+0xac/0xd8\n kasan_report from wilc_netdev_cleanup+0x508/0x5cc\n wilc_netdev_cleanup from wilc_bus_remove+0xc8/0xec\n wilc_bus_remove from spi_remove+0x8c/0xac\n spi_remove from device_release_driver_internal+0x434/0x5f8\n device_release_driver_internal from unbind_store+0xbc/0x108\n unbind_store from kernfs_fop_write_iter+0x398/0x584\n kernfs_fop_write_iter from vfs_write+0x728/0xf88\n vfs_write from ksys_write+0x110/0x1e4\n ksys_write from ret_fast_syscall+0x0/0x1c\r\n\r\n[...]\r\n\r\nAllocated by task 1:\n kasan_save_track+0x30/0x5c\n __kasan_kmalloc+0x8c/0x94\n __kmalloc_node+0x1cc/0x3e4\n kvmalloc_node+0x48/0x180\n alloc_netdev_mqs+0x68/0x11dc\n alloc_etherdev_mqs+0x28/0x34\n wilc_netdev_ifc_init+0x34/0x8ec\n wilc_cfg80211_init+0x690/0x910\n wilc_bus_probe+0xe0/0x4a0\n spi_probe+0x158/0x1b0\n really_probe+0x270/0xdf4\n __driver_probe_device+0x1dc/0x580\n driver_probe_device+0x60/0x140\n __driver_attach+0x228/0x5d4\n bus_for_each_dev+0x13c/0x1a8\n bus_add_driver+0x2a0/0x608\n driver_register+0x24c/0x578\n do_one_initcall+0x180/0x310\n kernel_init_freeable+0x424/0x484\n kernel_init+0x20/0x148\n ret_from_fork+0x14/0x28\r\n\r\nFreed by task 86:\n kasan_save_track+0x30/0x5c\n kasan_save_free_info+0x38/0x58\n __kasan_slab_free+0xe4/0x140\n kfree+0xb0/0x238\n device_release+0xc0/0x2a8\n kobject_put+0x1d4/0x46c\n netdev_run_todo+0x8fc/0x11d0\n wilc_netdev_cleanup+0x1e4/0x5cc\n wilc_bus_remove+0xc8/0xec\n spi_remove+0x8c/0xac\n device_release_driver_internal+0x434/0x5f8\n unbind_store+0xbc/0x108\n kernfs_fop_write_iter+0x398/0x584\n vfs_write+0x728/0xf88\n ksys_write+0x110/0x1e4\n ret_fast_syscall+0x0/0x1c\n [...]\r\n\r\nDavid Mosberger-Tan initial investigation [1] showed that this\nuse-after-free is due to netdevice unregistration during vif list\ntraversal. When unregistering a net device, since the needs_free_netdev has\nbeen set to true during registration, the netdevice object is also freed,\nand as a consequence, the corresponding vif object too, since it is\nattached to it as private netdevice data. The next occurrence of the loop\nthen tries to access freed vif pointer to the list to move forward in the\nlist.\r\n\r\nFix this use-after-free thanks to two mechanisms:\n- navigate in the list with list_for_each_entry_safe, which allows to\n safely modify the list as we go through each element. For each element,\n remove it from the list with list_del_rcu\n- make sure to wait for RCU grace period end after each vif removal to make\n sure it is safe to free the corresponding vif too (through\n unregister_netdev)\r\n\r\nSince we are in a RCU \u0026quot;modifier\u0026quot; path (not a \u0026quot;reader\u0026quot; path), and because\nsuch path is expected not to be concurrent to any other modifier (we are\nusing the vif_mutex lock), we do not need to use RCU list API, that\u0026apos;s why\nwe can benefit from list_for_each_entry_safe.\r\n\r\n[1] https://lore.kernel.org/linux-wireless/ab077dbe58b1ea5de0a3b2ca21f275a07af967d2.camel@egauge.net/(CVE-2024-26895)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: wfx: fix memory leak when starting AP\r\n\r\nKmemleak reported this error:\r\n\r\n unreferenced object 0xd73d1180 (size 184):\n comm \u0026quot;wpa_supplicant\u0026quot;, pid 1559, jiffies 13006305 (age 964.245s)\n hex dump (first 32 bytes):\n 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n 00 00 00 00 00 00 00 00 1e 00 01 00 00 00 00 00 ................\n backtrace:\n [\u0026lt;5ca11420\u0026gt;] kmem_cache_alloc+0x20c/0x5ac\n [\u0026lt;127bdd74\u0026gt;] __alloc_skb+0x144/0x170\n [\u0026lt;fb8a5e38\u0026gt;] __netdev_alloc_skb+0x50/0x180\n [\u0026lt;0f9fa1d5\u0026gt;] __ieee80211_beacon_get+0x290/0x4d4 [mac80211]\n [\u0026lt;7accd02d\u0026gt;] ieee80211_beacon_get_tim+0x54/0x18c [mac80211]\n [\u0026lt;41e25cc3\u0026gt;] wfx_start_ap+0xc8/0x234 [wfx]\n [\u0026lt;93a70356\u0026gt;] ieee80211_start_ap+0x404/0x6b4 [mac80211]\n [\u0026lt;a4a661cd\u0026gt;] nl80211_start_ap+0x76c/0x9e0 [cfg80211]\n [\u0026lt;47bd8b68\u0026gt;] genl_rcv_msg+0x198/0x378\n [\u0026lt;453ef796\u0026gt;] netlink_rcv_skb+0xd0/0x130\n [\u0026lt;6b7c977a\u0026gt;] genl_rcv+0x34/0x44\n [\u0026lt;66b2d04d\u0026gt;] netlink_unicast+0x1b4/0x258\n [\u0026lt;f965b9b6\u0026gt;] netlink_sendmsg+0x1e8/0x428\n [\u0026lt;aadb8231\u0026gt;] ____sys_sendmsg+0x1e0/0x274\n [\u0026lt;d2b5212d\u0026gt;] ___sys_sendmsg+0x80/0xb4\n [\u0026lt;69954f45\u0026gt;] __sys_sendmsg+0x64/0xa8\n unreferenced object 0xce087000 (size 1024):\n comm \u0026quot;wpa_supplicant\u0026quot;, pid 1559, jiffies 13006305 (age 964.246s)\n hex dump (first 32 bytes):\n 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n 10 00 07 40 00 00 00 00 00 00 00 00 00 00 00 00 ...@............\n backtrace:\n [\u0026lt;9a993714\u0026gt;] __kmalloc_track_caller+0x230/0x600\n [\u0026lt;f83ea192\u0026gt;] kmalloc_reserve.constprop.0+0x30/0x74\n [\u0026lt;a2c61343\u0026gt;] __alloc_skb+0xa0/0x170\n [\u0026lt;fb8a5e38\u0026gt;] __netdev_alloc_skb+0x50/0x180\n [\u0026lt;0f9fa1d5\u0026gt;] __ieee80211_beacon_get+0x290/0x4d4 [mac80211]\n [\u0026lt;7accd02d\u0026gt;] ieee80211_beacon_get_tim+0x54/0x18c [mac80211]\n [\u0026lt;41e25cc3\u0026gt;] wfx_start_ap+0xc8/0x234 [wfx]\n [\u0026lt;93a70356\u0026gt;] ieee80211_start_ap+0x404/0x6b4 [mac80211]\n [\u0026lt;a4a661cd\u0026gt;] nl80211_start_ap+0x76c/0x9e0 [cfg80211]\n [\u0026lt;47bd8b68\u0026gt;] genl_rcv_msg+0x198/0x378\n [\u0026lt;453ef796\u0026gt;] netlink_rcv_skb+0xd0/0x130\n [\u0026lt;6b7c977a\u0026gt;] genl_rcv+0x34/0x44\n [\u0026lt;66b2d04d\u0026gt;] netlink_unicast+0x1b4/0x258\n [\u0026lt;f965b9b6\u0026gt;] netlink_sendmsg+0x1e8/0x428\n [\u0026lt;aadb8231\u0026gt;] ____sys_sendmsg+0x1e0/0x274\n [\u0026lt;d2b5212d\u0026gt;] ___sys_sendmsg+0x80/0xb4\r\n\r\nHowever, since the kernel is build optimized, it seems the stack is not\naccurate. It appears the issue is related to wfx_set_mfp_ap(). The issue\nis obvious in this function: memory allocated by ieee80211_beacon_get()\nis never released. Fixing this leak makes kmemleak happy.(CVE-2024-26896)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: ath9k: delay all of ath9k_wmi_event_tasklet() until init is complete\r\n\r\nThe ath9k_wmi_event_tasklet() used in ath9k_htc assumes that all the data\nstructures have been fully initialised by the time it runs. However, because of\nthe order in which things are initialised, this is not guaranteed to be the\ncase, because the device is exposed to the USB subsystem before the ath9k driver\ninitialisation is completed.\r\n\r\nWe already committed a partial fix for this in commit:\n8b3046abc99e (\u0026quot;ath9k_htc: fix NULL pointer dereference at ath9k_htc_tx_get_packet()\u0026quot;)\r\n\r\nHowever, that commit only aborted the WMI_TXSTATUS_EVENTID command in the event\ntasklet, pairing it with an \u0026quot;initialisation complete\u0026quot; bit in the TX struct. It\nseems syzbot managed to trigger the race for one of the other commands as well,\nso let\u0026apos;s just move the existing synchronisation bit to cover the whole\ntasklet (setting it at the end of ath9k_htc_probe_device() instead of inside\nath9k_tx_init()).(CVE-2024-26897)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: Revert \u0026quot;scsi: fcoe: Fix potential deadlock on \u0026amp;fip-\u0026gt;ctlr_lock\u0026quot;\r\n\r\nThis reverts commit 1a1975551943f681772720f639ff42fbaa746212.\r\n\r\nThis commit causes interrupts to be lost for FCoE devices, since it changed\nsping locks from \u0026quot;bh\u0026quot; to \u0026quot;irqsave\u0026quot;.\r\n\r\nInstead, a work queue should be used, and will be addressed in a separate\ncommit.(CVE-2024-26917)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ninet: inet_defrag: prevent sk release while still in use\r\n\r\nip_local_out() and other functions can pass skb-\u0026gt;sk as function argument.\r\n\r\nIf the skb is a fragment and reassembly happens before such function call\nreturns, the sk must not be released.\r\n\r\nThis affects skb fragments reassembled via netfilter or similar\nmodules, e.g. openvswitch or ct_act.c, when run as part of tx pipeline.\r\n\r\nEric Dumazet made an initial analysis of this bug. Quoting Eric:\n Calling ip_defrag() in output path is also implying skb_orphan(),\n which is buggy because output path relies on sk not disappearing.\r\n\r\n A relevant old patch about the issue was :\n 8282f27449bf (\u0026quot;inet: frag: Always orphan skbs inside ip_defrag()\u0026quot;)\r\n\r\n [..]\r\n\r\n net/ipv4/ip_output.c depends on skb-\u0026gt;sk being set, and probably to an\n inet socket, not an arbitrary one.\r\n\r\n If we orphan the packet in ipvlan, then downstream things like FQ\n packet scheduler will not work properly.\r\n\r\n We need to change ip_defrag() to only use skb_orphan() when really\n needed, ie whenever frag_list is going to be used.\r\n\r\nEric suggested to stash sk in fragment queue and made an initial patch.\nHowever there is a problem with this:\r\n\r\nIf skb is refragmented again right after, ip_do_fragment() will copy\nhead-\u0026gt;sk to the new fragments, and sets up destructor to sock_wfree.\nIOW, we have no choice but to fix up sk_wmem accouting to reflect the\nfully reassembled skb, else wmem will underflow.\r\n\r\nThis change moves the orphan down into the core, to last possible moment.\nAs ip_defrag_offset is aliased with sk_buff-\u0026gt;sk member, we must move the\noffset into the FRAG_CB, else skb-\u0026gt;sk gets clobbered.\r\n\r\nThis allows to delay the orphaning long enough to learn if the skb has\nto be queued or if the skb is completing the reasm queue.\r\n\r\nIn the former case, things work as before, skb is orphaned. This is\nsafe because skb gets queued/stolen and won\u0026apos;t continue past reasm engine.\r\n\r\nIn the latter case, we will steal the skb-\u0026gt;sk reference, reattach it to\nthe head skb, and fix up wmem accouting when inet_frag inflates truesize.(CVE-2024-26921)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: validate the parameters of bo mapping operations more clearly\r\n\r\nVerify the parameters of\namdgpu_vm_bo_(map/replace_map/clearing_mappings) in one common place.(CVE-2024-26922)",
"id": "OESA-2024-1622",
"modified": "2026-08-06T11:07:04Z",
"published": "2024-05-17T11:07:04Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1622"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48655"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48674"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52477"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52620"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52628"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52631"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52633"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52637"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52639"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52642"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52644"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-6270"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26642"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26645"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26665"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26668"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26669"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26671"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26679"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26680"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26684"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26685"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26688"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26689"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26697"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26706"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26707"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26720"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26726"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26733"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26734"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26735"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26739"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26740"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26743"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26744"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26754"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26763"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26776"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26782"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26787"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26791"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26792"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26801"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26804"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26805"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26808"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26809"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26811"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26812"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26814"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26817"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26828"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26829"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26839"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26840"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26843"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26846"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26852"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26855"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26859"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26862"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26863"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26865"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26869"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26870"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26872"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26875"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26878"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26880"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26893"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26895"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26896"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26897"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26917"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26921"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26922"
}
],
"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-48655",
"CVE-2022-48674",
"CVE-2023-52477",
"CVE-2023-52620",
"CVE-2023-52628",
"CVE-2023-52631",
"CVE-2023-52633",
"CVE-2023-52637",
"CVE-2023-52639",
"CVE-2023-52642",
"CVE-2023-52644",
"CVE-2023-6270",
"CVE-2024-26642",
"CVE-2024-26645",
"CVE-2024-26665",
"CVE-2024-26668",
"CVE-2024-26669",
"CVE-2024-26671",
"CVE-2024-26679",
"CVE-2024-26680",
"CVE-2024-26684",
"CVE-2024-26685",
"CVE-2024-26688",
"CVE-2024-26689",
"CVE-2024-26697",
"CVE-2024-26706",
"CVE-2024-26707",
"CVE-2024-26720",
"CVE-2024-26726",
"CVE-2024-26733",
"CVE-2024-26734",
"CVE-2024-26735",
"CVE-2024-26739",
"CVE-2024-26740",
"CVE-2024-26743",
"CVE-2024-26744",
"CVE-2024-26754",
"CVE-2024-26763",
"CVE-2024-26776",
"CVE-2024-26782",
"CVE-2024-26787",
"CVE-2024-26791",
"CVE-2024-26792",
"CVE-2024-26801",
"CVE-2024-26804",
"CVE-2024-26805",
"CVE-2024-26808",
"CVE-2024-26809",
"CVE-2024-26811",
"CVE-2024-26812",
"CVE-2024-26814",
"CVE-2024-26817",
"CVE-2024-26828",
"CVE-2024-26829",
"CVE-2024-26839",
"CVE-2024-26840",
"CVE-2024-26843",
"CVE-2024-26846",
"CVE-2024-26852",
"CVE-2024-26855",
"CVE-2024-26859",
"CVE-2024-26862",
"CVE-2024-26863",
"CVE-2024-26865",
"CVE-2024-26869",
"CVE-2024-26870",
"CVE-2024-26872",
"CVE-2024-26875",
"CVE-2024-26878",
"CVE-2024-26880",
"CVE-2024-26893",
"CVE-2024-26895",
"CVE-2024-26896",
"CVE-2024-26897",
"CVE-2024-26917",
"CVE-2024-26921",
"CVE-2024-26922"
]
}
OESA-2024-2324 (CVE-2022-48916)
Vulnerability from osv_openeuler – Published: 2024-11-01 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:
iommu/vt-d: Fix double list_add when enabling VMD in scalable mode
When enabling VMD and IOMMU scalable mode, the following kernel panic call trace/kernel log is shown in Eagle Stream platform (Sapphire Rapids CPU) during booting:
pci 0000:59:00.5: Adding to iommu group 42 ... vmd 0000:59:00.5: PCI host bridge to bus 10000:80 pci 10000:80:01.0: [8086:352a] type 01 class 0x060400 pci 10000:80:01.0: reg 0x10: [mem 0x00000000-0x0001ffff 64bit] pci 10000:80:01.0: enabling Extended Tags pci 10000:80:01.0: PME# supported from D0 D3hot D3cold pci 10000:80:01.0: DMAR: Setup RID2PASID failed pci 10000:80:01.0: Failed to add to iommu group 42: -16 pci 10000:80:03.0: [8086:352b] type 01 class 0x060400 pci 10000:80:03.0: reg 0x10: [mem 0x00000000-0x0001ffff 64bit] pci 10000:80:03.0: enabling Extended Tags pci 10000:80:03.0: PME# supported from D0 D3hot D3cold ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:29! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 7 Comm: kworker/0:1 Not tainted 5.17.0-rc3+ #7 Hardware name: Lenovo ThinkSystem SR650V3/SB27A86647, BIOS ESE101Y-1.00 01/13/2022 Workqueue: events work_for_cpu_fn RIP: 0010:__list_add_valid.cold+0x26/0x3f Code: 9a 4a ab ff 4c 89 c1 48 c7 c7 40 0c d9 9e e8 b9 b1 fe ff 0f 0b 48 89 f2 4c 89 c1 48 89 fe 48 c7 c7 f0 0c d9 9e e8 a2 b1 fe ff <0f> 0b 48 89 d1 4c 89 c6 4c 89 ca 48 c7 c7 98 0c d9 9e e8 8b b1 fe RSP: 0000:ff5ad434865b3a40 EFLAGS: 00010246 RAX: 0000000000000058 RBX: ff4d61160b74b880 RCX: ff4d61255e1fffa8 RDX: 0000000000000000 RSI: 00000000fffeffff RDI: ffffffff9fd34f20 RBP: ff4d611d8e245c00 R08: 0000000000000000 R09: ff5ad434865b3888 R10: ff5ad434865b3880 R11: ff4d61257fdc6fe8 R12: ff4d61160b74b8a0 R13: ff4d61160b74b8a0 R14: ff4d611d8e245c10 R15: ff4d611d8001ba70 FS: 0000000000000000(0000) GS:ff4d611d5ea00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ff4d611fa1401000 CR3: 0000000aa0210001 CR4: 0000000000771ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> intel_pasid_alloc_table+0x9c/0x1d0 dmar_insert_one_dev_info+0x423/0x540 ? device_to_iommu+0x12d/0x2f0 intel_iommu_attach_device+0x116/0x290 __iommu_attach_device+0x1a/0x90 iommu_group_add_device+0x190/0x2c0 __iommu_probe_device+0x13e/0x250 iommu_probe_device+0x24/0x150 iommu_bus_notifier+0x69/0x90 blocking_notifier_call_chain+0x5a/0x80 device_add+0x3db/0x7b0 ? arch_memremap_can_ram_remap+0x19/0x50 ? memremap+0x75/0x140 pci_device_add+0x193/0x1d0 pci_scan_single_device+0xb9/0xf0 pci_scan_slot+0x4c/0x110 pci_scan_child_bus_extend+0x3a/0x290 vmd_enable_domain.constprop.0+0x63e/0x820 vmd_probe+0x163/0x190 local_pci_probe+0x42/0x80 work_for_cpu_fn+0x13/0x20 process_one_work+0x1e2/0x3b0 worker_thread+0x1c4/0x3a0 ? rescuer_thread+0x370/0x370 kthread+0xc7/0xf0 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30 </TASK> Modules linked in: ---[ end trace 0000000000000000 ]--- ... Kernel panic - not syncing: Fatal exception Kernel Offset: 0x1ca00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) ---[ end Kernel panic - not syncing: Fatal exception ]---
The following 'lspci' output shows devices '10000:80:*' are subdevices of the VMD device 0000:59:00.5:
$ lspci ... 0000:59:00.5 RAID bus controller: Intel Corporation Volume Management Device NVMe RAID Controller (rev 20) ... 10000:80:01.0 PCI bridge: Intel Corporation Device 352a (rev 03) 10000:80:03.0 PCI bridge: Intel Corporation Device 352b (rev 03) 10000:80:05.0 PCI bridge: Intel Corporation Device 352c (rev 03) 10000:80:07.0 PCI bridge: Intel Corporation Device 352d (rev 03) 10000:81:00.0 Non-Volatile memory controller: Intel Corporation NVMe Datacenter SSD [3DNAND, Beta Rock Controller] 10000:82:00 ---truncated---(CVE-2022-48916)
In the Linux kernel, the following vulnerability has been resolved: udf: Fix preallocation discarding at indirect extent boundary When preallocation extent is the first one in the extent block, the code would corrupt extent tree header instead. Fix the problem and use udf_delete_aext() for deleting extent to avoid some code duplication.(CVE-2022-48946)
In the Linux kernel, the following vulnerability has been resolved: PCI: mt7621: Add sentinel to quirks table Current driver is missing a sentinel in the struct soc_device_attribute array, which causes an oops when assessed by the soc_device_match(mt7621_pcie_quirks_match) call. This was only exposed once the CONFIG_SOC_MT7621 mt7621 soc_dev_attr was fixed to register the SOC as a device, in: commit 7c18b64bba3b ("mips: ralink: mt7621: do not use kzalloc too early") Fix it by adding the required sentinel.(CVE-2022-48952)
In the Linux kernel, the following vulnerability has been resolved: NFC: nci: Bounds check struct nfc_target arrays While running under CONFIG_FORTIFY_SOURCE=y, syzkaller reported: memcpy: detected field-spanning write (size 129) of single field "target->sensf_res" at net/nfc/nci/ntf.c:260 (size 18) This appears to be a legitimate lack of bounds checking in nci_add_new_protocol(). Add the missing checks.(CVE-2022-48967)
In the Linux kernel, the following vulnerability has been resolved: gpio: amd8111: Fix PCI device reference count leak for_each_pci_dev() is implemented by pci_get_device(). The comment of pci_get_device() says that it will increase the reference count for the returned pci_dev and also decrease the reference count for the input pci_dev @from if it is not NULL. If we break for_each_pci_dev() loop with pdev not NULL, we need to call pci_dev_put() to decrease the reference count. Add the missing pci_dev_put() after the 'out' label. Since pci_dev_put() can handle NULL input parameter, there is no problem for the 'Device not found' branch. For the normal path, add pci_dev_put() in amd_gpio_exit().(CVE-2022-48973)
In the Linux kernel, the following vulnerability has been resolved: can: af_can: fix NULL pointer dereference in can_rcv_filter Analogue to commit 8aa59e355949 ("can: af_can: fix NULL pointer dereference in can_rx_register()") we need to check for a missing initialization of ml_priv in the receive path of CAN frames. Since commit 4e096a18867a ("net: introduce CAN specific pointer in the struct net_device") the check for dev->type to be ARPHRD_CAN is not sufficient anymore since bonding or tun netdevices claim to be CAN devices but do not initialize ml_priv accordingly.(CVE-2022-48977)
In the Linux kernel, the following vulnerability has been resolved: mm/gup: fix gup_pud_range() for dax For dax pud, pud_huge() returns true on x86. So the function works as long as hugetlb is configured. However, dax doesn't depend on hugetlb. Commit 414fd080d125 ("mm/gup: fix gup_pmd_range() for dax") fixed devmap-backed huge PMDs, but missed devmap-backed huge PUDs. Fix this as well. This fixes the below kernel panic: general protection fault, probably for non-canonical address 0x69e7c000cc478: 0000 [#1] SMP < snip > Call Trace: <TASK> get_user_pages_fast+0x1f/0x40 iov_iter_get_pages+0xc6/0x3b0 ? mempool_alloc+0x5d/0x170 bio_iov_iter_get_pages+0x82/0x4e0 ? bvec_alloc+0x91/0xc0 ? bio_alloc_bioset+0x19a/0x2a0 blkdev_direct_IO+0x282/0x480 ? __io_complete_rw_common+0xc0/0xc0 ? filemap_range_has_page+0x82/0xc0 generic_file_direct_write+0x9d/0x1a0 ? inode_update_time+0x24/0x30 __generic_file_write_iter+0xbd/0x1e0 blkdev_write_iter+0xb4/0x150 ? io_import_iovec+0x8d/0x340 io_write+0xf9/0x300 io_issue_sqe+0x3c3/0x1d30 ? sysvec_reschedule_ipi+0x6c/0x80 __io_queue_sqe+0x33/0x240 ? fget+0x76/0xa0 io_submit_sqes+0xe6a/0x18d0 ? __fget_light+0xd1/0x100 __x64_sys_io_uring_enter+0x199/0x880 ? __context_tracking_enter+0x1f/0x70 ? irqentry_exit_to_user_mode+0x24/0x30 ? irqentry_exit+0x1d/0x30 ? __context_tracking_exit+0xe/0x70 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x61/0xcb RIP: 0033:0x7fc97c11a7be < snip > </TASK> ---[ end trace 48b2e0e67debcaeb ]--- RIP: 0010:internal_get_user_pages_fast+0x340/0x990 < snip > Kernel panic - not syncing: Fatal exception Kernel Offset: disabled(CVE-2022-48986)
In the Linux kernel, the following vulnerability has been resolved: memcg: fix possible use-after-free in memcg_write_event_control() memcg_write_event_control() accesses the dentry->d_name of the specified control fd to route the write call. As a cgroup interface file can't be renamed, it's safe to access d_name as long as the specified file is a regular cgroup file. Also, as these cgroup interface files can't be removed before the directory, it's safe to access the parent too. Prior to 347c4a874710 ("memcg: remove cgroup_event->cft"), there was a call to __file_cft() which verified that the specified file is a regular cgroupfs file before further accesses. The cftype pointer returned from __file_cft() was no longer necessary and the commit inadvertently dropped the file type check with it allowing any file to slip through. With the invarients broken, the d_name and parent accesses can now race against renames and removals of arbitrary files and cause use-after-free's. Fix the bug by resurrecting the file type check in __file_cft(). Now that cgroupfs is implemented through kernfs, checking the file operations needs to go through a layer of indirection. Instead, let's check the superblock and dentry type.(CVE-2022-48988)
In the Linux kernel, the following vulnerability has been resolved: mm/khugepaged: invoke MMU notifiers in shmem/file collapse paths Any codepath that zaps page table entries must invoke MMU notifiers to ensure that secondary MMUs (like KVM) don't keep accessing pages which aren't mapped anymore. Secondary MMUs don't hold their own references to pages that are mirrored over, so failing to notify them can lead to page use-after-free. I'm marking this as addressing an issue introduced in commit f3f0e1d2150b ("khugepaged: add support of collapse for tmpfs/shmem pages"), but most of the security impact of this only came in commit 27e1f8273113 ("khugepaged: enable collapse pmd for pte-mapped THP"), which actually omitted flushes for the removal of present PTEs, not just for the removal of empty page tables.(CVE-2022-48991)
In the Linux kernel, the following vulnerability has been resolved: ALSA: seq: Fix function prototype mismatch in snd_seq_expand_var_event With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG), indirect call targets are validated against the expected function pointer prototype to make sure the call target is valid to help mitigate ROP attacks. If they are not identical, there is a failure at run time, which manifests as either a kernel panic or thread getting killed. seq_copy_in_user() and seq_copy_in_kernel() did not have prototypes matching snd_seq_dump_func_t. Adjust this and remove the casts. There are not resulting binary output differences. This was found as a result of Clang's new -Wcast-function-type-strict flag, which is more sensitive than the simpler -Wcast-function-type, which only checks for type width mismatches.(CVE-2022-48994)
In the Linux kernel, the following vulnerability has been resolved: tracing: Free buffers when a used dynamic event is removed(CVE-2022-49006)
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix NULL pointer dereference in nilfs_palloc_commit_free_entry() Syzbot reported a null-ptr-deref bug: NILFS (loop0): segctord starting. Construction interval = 5 seconds, CP frequency < 30 seconds general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] CPU: 1 PID: 3603 Comm: segctord Not tainted 6.1.0-rc2-syzkaller-00105-gb229b6ca5abb #0 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 10/11/2022 RIP: 0010:nilfs_palloc_commit_free_entry+0xe5/0x6b0 fs/nilfs2/alloc.c:608 Code: 00 00 00 00 fc ff df 80 3c 02 00 0f 85 cd 05 00 00 48 b8 00 00 00 00 00 fc ff df 4c 8b 73 08 49 8d 7e 10 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 26 05 00 00 49 8b 46 10 be a6 00 00 00 48 c7 c7 RSP: 0018:ffffc90003dff830 EFLAGS: 00010212 RAX: dffffc0000000000 RBX: ffff88802594e218 RCX: 000000000000000d RDX: 0000000000000002 RSI: 0000000000002000 RDI: 0000000000000010 RBP: ffff888071880222 R08: 0000000000000005 R09: 000000000000003f R10: 000000000000000d R11: 0000000000000000 R12: ffff888071880158 R13: ffff88802594e220 R14: 0000000000000000 R15: 0000000000000004 FS: 0000000000000000(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fb1c08316a8 CR3: 0000000018560000 CR4: 0000000000350ee0 Call Trace: <TASK> nilfs_dat_commit_free fs/nilfs2/dat.c:114 [inline] nilfs_dat_commit_end+0x464/0x5f0 fs/nilfs2/dat.c:193 nilfs_dat_commit_update+0x26/0x40 fs/nilfs2/dat.c:236 nilfs_btree_commit_update_v+0x87/0x4a0 fs/nilfs2/btree.c:1940 nilfs_btree_commit_propagate_v fs/nilfs2/btree.c:2016 [inline] nilfs_btree_propagate_v fs/nilfs2/btree.c:2046 [inline] nilfs_btree_propagate+0xa00/0xd60 fs/nilfs2/btree.c:2088 nilfs_bmap_propagate+0x73/0x170 fs/nilfs2/bmap.c:337 nilfs_collect_file_data+0x45/0xd0 fs/nilfs2/segment.c:568 nilfs_segctor_apply_buffers+0x14a/0x470 fs/nilfs2/segment.c:1018 nilfs_segctor_scan_file+0x3f4/0x6f0 fs/nilfs2/segment.c:1067 nilfs_segctor_collect_blocks fs/nilfs2/segment.c:1197 [inline] nilfs_segctor_collect fs/nilfs2/segment.c:1503 [inline] nilfs_segctor_do_construct+0x12fc/0x6af0 fs/nilfs2/segment.c:2045 nilfs_segctor_construct+0x8e3/0xb30 fs/nilfs2/segment.c:2379 nilfs_segctor_thread_construct fs/nilfs2/segment.c:2487 [inline] nilfs_segctor_thread+0x3c3/0xf30 fs/nilfs2/segment.c:2570 kthread+0x2e4/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306 </TASK> ... If DAT metadata file is corrupted on disk, there is a case where req->pr_desc_bh is NULL and blocknr is 0 at nilfs_dat_commit_end() during a b-tree operation that cascadingly updates ancestor nodes of the b-tree, because nilfs_dat_commit_alloc() for a lower level block can initialize the blocknr on the same DAT entry between nilfs_dat_prepare_end() and nilfs_dat_commit_end(). If this happens, nilfs_dat_commit_end() calls nilfs_dat_commit_free() without valid buffer heads in req->pr_desc_bh and req->pr_bitmap_bh, and causes the NULL pointer dereference above in nilfs_palloc_commit_free_entry() function, which leads to a crash. Fix this by adding a NULL check on req->pr_desc_bh and req->pr_bitmap_bh before nilfs_palloc_commit_free_entry() in nilfs_dat_commit_free(). This also calls nilfs_error() in that case to notify that there is a fatal flaw in the filesystem metadata and prevent further operations.(CVE-2022-49007)
In the Linux kernel, the following vulnerability has been resolved: net: ethernet: nixge: fix NULL dereference In function nixge_hw_dma_bd_release() dereference of NULL pointer priv->rx_bd_v is possible for the case of its allocation failure in nixge_hw_dma_bd_init(). Move for() loop with priv->rx_bd_v dereference under the check for its validity. Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2022-49019)
In the Linux kernel, the following vulnerability has been resolved: hwmon: (ibmpex) Fix possible UAF when ibmpex_register_bmc() fails Smatch report warning as follows: drivers/hwmon/ibmpex.c:509 ibmpex_register_bmc() warn: '&data->list' not removed from list If ibmpex_find_sensors() fails in ibmpex_register_bmc(), data will be freed, but data->list will not be removed from driver_data.bmc_data, then list traversal may cause UAF. Fix by removeing it from driver_data.bmc_data before free().(CVE-2022-49029)
In the Linux kernel, the following vulnerability has been resolved: libbpf: Handle size overflow for ringbuf mmap The maximum size of ringbuf is 2GB on x86-64 host, so 2 * max_entries will overflow u32 when mapping producer page and data pages. Only casting max_entries to size_t is not enough, because for 32-bits application on 64-bits kernel the size of read-only mmap region also could overflow size_t. So fixing it by casting the size of read-only mmap region into a __u64 and checking whether or not there will be overflow during mmap.(CVE-2022-49030)
In the Linux kernel, the following vulnerability has been resolved: btrfs: qgroup: fix sleep from invalid context bug in btrfs_qgroup_inherit() Syzkaller reported BUG as follows: BUG: sleeping function called from invalid context at include/linux/sched/mm.h:274 Call Trace: <TASK> dump_stack_lvl+0xcd/0x134 __might_resched.cold+0x222/0x26b kmem_cache_alloc+0x2e7/0x3c0 update_qgroup_limit_item+0xe1/0x390 btrfs_qgroup_inherit+0x147b/0x1ee0 create_subvol+0x4eb/0x1710 btrfs_mksubvol+0xfe5/0x13f0 __btrfs_ioctl_snap_create+0x2b0/0x430 btrfs_ioctl_snap_create_v2+0x25a/0x520 btrfs_ioctl+0x2a1c/0x5ce0 __x64_sys_ioctl+0x193/0x200 do_syscall_64+0x35/0x80 Fix this by calling qgroup_dirty() on @dstqgroup, and update limit item in btrfs_run_qgroups() later outside of the spinlock context.(CVE-2022-49033)
In the Linux kernel, the following vulnerability has been resolved:
media: imon: fix access to invalid resource for the second interface
imon driver probes two USB interfaces, and at the probe of the second interface, the driver assumes blindly that the first interface got bound with the same imon driver. It's usually true, but it's still possible that the first interface is bound with another driver via a malformed descriptor. Then it may lead to a memory corruption, as spotted by syzkaller; imon driver accesses the data from drvdata as struct imon_context object although it's a completely different one that was assigned by another driver.
This patch adds a sanity check -- whether the first interface is really bound with the imon driver or not -- for avoiding the problem above at the probe time.(CVE-2023-52754)
In the Linux kernel, the following vulnerability has been resolved:
usb: dwc2: fix possible NULL pointer dereference caused by driver concurrency
In _dwc2_hcd_urb_enqueue(), "urb->hcpriv = NULL" is executed without holding the lock "hsotg->lock". In _dwc2_hcd_urb_dequeue():
spin_lock_irqsave(&hsotg->lock, flags);
...
if (!urb->hcpriv) {
dev_dbg(hsotg->dev, "## urb->hcpriv is NULL ##\n");
goto out;
}
rc = dwc2_hcd_urb_dequeue(hsotg, urb->hcpriv); // Use urb->hcpriv
...
out: spin_unlock_irqrestore(&hsotg->lock, flags);
When _dwc2_hcd_urb_enqueue() and _dwc2_hcd_urb_dequeue() are concurrently executed, the NULL check of "urb->hcpriv" can be executed before "urb->hcpriv = NULL". After urb->hcpriv is NULL, it can be used in the function call to dwc2_hcd_urb_dequeue(), which can cause a NULL pointer dereference.
This possible bug is found by an experimental static analysis tool developed by myself. This tool analyzes the locking APIs to extract function pairs that can be concurrently executed, and then analyzes the instructions in the paired functions to identify possible concurrency bugs including data races and atomicity violations. The above possible bug is reported, when my tool analyzes the source code of Linux 6.5.
To fix this possible bug, "urb->hcpriv = NULL" should be executed with holding the lock "hsotg->lock". After using this patch, my tool never reports the possible bug, with the kernelconfiguration allyesconfig for x86_64. Because I have no associated hardware, I cannot test the patch in runtime testing, and just verify it according to the code logic.(CVE-2023-52855)
In the Linux kernel, the following vulnerability has been resolved: ntb: intel: Fix the NULL vs IS_ERR() bug for debugfs_create_dir() The debugfs_create_dir() function returns error pointers. It never returns NULL. So use IS_ERR() to check it.(CVE-2023-52917)
In the Linux kernel, the following vulnerability has been resolved: media: pci: cx23885: check cx23885_vdev_init() return cx23885_vdev_init() can return a NULL pointer, but that pointer is used in the next line without a check. Add a NULL pointer check and go to the error unwind if it is NULL.(CVE-2023-52918)
In the Linux kernel, the following vulnerability has been resolved: nfc: nci: fix possible NULL pointer dereference in send_acknowledge() Handle memory allocation failure from nci_skb_alloc() (calling alloc_skb()) to avoid possible NULL pointer dereference.(CVE-2023-52919)
In the Linux kernel, the following vulnerability has been resolved:
scsi: Revert "scsi: fcoe: Fix potential deadlock on &fip->ctlr_lock"
This reverts commit 1a1975551943f681772720f639ff42fbaa746212.
This commit causes interrupts to be lost for FCoE devices, since it changed sping locks from "bh" to "irqsave".
Instead, a work queue should be used, and will be addressed in a separate commit.(CVE-2024-26917)
In the Linux kernel, the following vulnerability has been resolved:
of: module: prevent NULL pointer dereference in vsnprintf()
In of_modalias(), we can get passed the str and len parameters which would cause a kernel oops in vsnprintf() since it only allows passing a NULL ptr when the length is also 0. Also, we need to filter out the negative values of the len parameter as these will result in a really huge buffer since snprintf() takes size_t parameter while ours is ssize_t...
Found by Linux Verification Center (linuxtesting.org) with the Svace static analysis tool.(CVE-2024-35878)
In the Linux kernel, the following vulnerability has been resolved:
dma: xilinx_dpdma: Fix locking
There are several places where either chan->lock or chan->vchan.lock was not held. Add appropriate locking. This fixes lockdep warnings like
[ 31.077578] ------------[ cut here ]------------ [ 31.077831] WARNING: CPU: 2 PID: 40 at drivers/dma/xilinx/xilinx_dpdma.c:834 xilinx_dpdma_chan_queue_transfer+0x274/0x5e0 [ 31.077953] Modules linked in: [ 31.078019] CPU: 2 PID: 40 Comm: kworker/u12:1 Not tainted 6.6.20+ #98 [ 31.078102] Hardware name: xlnx,zynqmp (DT) [ 31.078169] Workqueue: events_unbound deferred_probe_work_func [ 31.078272] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 31.078377] pc : xilinx_dpdma_chan_queue_transfer+0x274/0x5e0 [ 31.078473] lr : xilinx_dpdma_chan_queue_transfer+0x270/0x5e0 [ 31.078550] sp : ffffffc083bb2e10 [ 31.078590] x29: ffffffc083bb2e10 x28: 0000000000000000 x27: ffffff880165a168 [ 31.078754] x26: ffffff880164e920 x25: ffffff880164eab8 x24: ffffff880164d480 [ 31.078920] x23: ffffff880165a148 x22: ffffff880164e988 x21: 0000000000000000 [ 31.079132] x20: ffffffc082aa3000 x19: ffffff880164e880 x18: 0000000000000000 [ 31.079295] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 31.079453] x14: 0000000000000000 x13: ffffff8802263dc0 x12: 0000000000000001 [ 31.079613] x11: 0001ffc083bb2e34 x10: 0001ff880164e98f x9 : 0001ffc082aa3def [ 31.079824] x8 : 0001ffc082aa3dec x7 : 0000000000000000 x6 : 0000000000000516 [ 31.079982] x5 : ffffffc7f8d43000 x4 : ffffff88003c9c40 x3 : ffffffffffffffff [ 31.080147] x2 : ffffffc7f8d43000 x1 : 00000000000000c0 x0 : 0000000000000000 [ 31.080307] Call trace: [ 31.080340] xilinx_dpdma_chan_queue_transfer+0x274/0x5e0 [ 31.080518] xilinx_dpdma_issue_pending+0x11c/0x120 [ 31.080595] zynqmp_disp_layer_update+0x180/0x3ac [ 31.080712] zynqmp_dpsub_plane_atomic_update+0x11c/0x21c [ 31.080825] drm_atomic_helper_commit_planes+0x20c/0x684 [ 31.080951] drm_atomic_helper_commit_tail+0x5c/0xb0 [ 31.081139] commit_tail+0x234/0x294 [ 31.081246] drm_atomic_helper_commit+0x1f8/0x210 [ 31.081363] drm_atomic_commit+0x100/0x140 [ 31.081477] drm_client_modeset_commit_atomic+0x318/0x384 [ 31.081634] drm_client_modeset_commit_locked+0x8c/0x24c [ 31.081725] drm_client_modeset_commit+0x34/0x5c [ 31.081812] __drm_fb_helper_restore_fbdev_mode_unlocked+0x104/0x168 [ 31.081899] drm_fb_helper_set_par+0x50/0x70 [ 31.081971] fbcon_init+0x538/0xc48 [ 31.082047] visual_init+0x16c/0x23c [ 31.082207] do_bind_con_driver.isra.0+0x2d0/0x634 [ 31.082320] do_take_over_console+0x24c/0x33c [ 31.082429] do_fbcon_takeover+0xbc/0x1b0 [ 31.082503] fbcon_fb_registered+0x2d0/0x34c [ 31.082663] register_framebuffer+0x27c/0x38c [ 31.082767] __drm_fb_helper_initial_config_and_unlock+0x5c0/0x91c [ 31.082939] drm_fb_helper_initial_config+0x50/0x74 [ 31.083012] drm_fbdev_dma_client_hotplug+0xb8/0x108 [ 31.083115] drm_client_register+0xa0/0xf4 [ 31.083195] drm_fbdev_dma_setup+0xb0/0x1cc [ 31.083293] zynqmp_dpsub_drm_init+0x45c/0x4e0 [ 31.083431] zynqmp_dpsub_probe+0x444/0x5e0 [ 31.083616] platform_probe+0x8c/0x13c [ 31.083713] really_probe+0x258/0x59c [ 31.083793] __driver_probe_device+0xc4/0x224 [ 31.083878] driver_probe_device+0x70/0x1c0 [ 31.083961] __device_attach_driver+0x108/0x1e0 [ 31.084052] bus_for_each_drv+0x9c/0x100 [ 31.084125] __device_attach+0x100/0x298 [ 31.084207] device_initial_probe+0x14/0x20 [ 31.084292] bus_probe_device+0xd8/0xdc [ 31.084368] deferred_probe_work_func+0x11c/0x180 [ 31.084451] process_one_work+0x3ac/0x988 [ 31.084643] worker_thread+0x398/0x694 [ 31.084752] kthread+0x1bc/0x1c0 [ 31.084848] ret_from_fork+0x10/0x20 [ 31.084932] irq event stamp: 64549 [ 31.084970] hardirqs last enabled at (64548): [<ffffffc081adf35c>] _raw_spin_unlock_irqrestore+0x80/0x90 [ 31.085157] ---truncated---(CVE-2024-35990)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nfnetlink_queue: acquire rcu_read_lock() in instance_destroy_rcu()
syzbot reported that nf_reinject() could be called without rcu_read_lock() :
WARNING: suspicious RCU usage 6.9.0-rc7-syzkaller-02060-g5c1672705a1a #0 Not tainted
net/netfilter/nfnetlink_queue.c:263 suspicious rcu_dereference_check() usage!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 1 2 locks held by syz-executor.4/13427: #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_lock_acquire include/linux/rcupdate.h:329 [inline] #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_do_batch kernel/rcu/tree.c:2190 [inline] #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_core+0xa86/0x1830 kernel/rcu/tree.c:2471 #1: ffff88801ca92958 (&inst->lock){+.-.}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline] #1: ffff88801ca92958 (&inst->lock){+.-.}-{2:2}, at: nfqnl_flush net/netfilter/nfnetlink_queue.c:405 [inline] #1: ffff88801ca92958 (&inst->lock){+.-.}-{2:2}, at: instance_destroy_rcu+0x30/0x220 net/netfilter/nfnetlink_queue.c:172
stack backtrace: CPU: 0 PID: 13427 Comm: syz-executor.4 Not tainted 6.9.0-rc7-syzkaller-02060-g5c1672705a1a #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024 Call Trace: <IRQ> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 lockdep_rcu_suspicious+0x221/0x340 kernel/locking/lockdep.c:6712 nf_reinject net/netfilter/nfnetlink_queue.c:323 [inline] nfqnl_reinject+0x6ec/0x1120 net/netfilter/nfnetlink_queue.c:397 nfqnl_flush net/netfilter/nfnetlink_queue.c:410 [inline] instance_destroy_rcu+0x1ae/0x220 net/netfilter/nfnetlink_queue.c:172 rcu_do_batch kernel/rcu/tree.c:2196 [inline] rcu_core+0xafd/0x1830 kernel/rcu/tree.c:2471 handle_softirqs+0x2d6/0x990 kernel/softirq.c:554 __do_softirq kernel/softirq.c:588 [inline] invoke_softirq kernel/softirq.c:428 [inline] __irq_exit_rcu+0xf4/0x1c0 kernel/softirq.c:637 irq_exit_rcu+0x9/0x30 kernel/softirq.c:649 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1043 [inline] sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1043 </IRQ> <TASK>(CVE-2024-36286)
In the Linux kernel, the following vulnerability has been resolved:
soundwire: cadence: fix invalid PDI offset
For some reason, we add an offset to the PDI, presumably to skip the PDI0 and PDI1 which are reserved for BPT.
This code is however completely wrong and leads to an out-of-bounds access. We were just lucky so far since we used only a couple of PDIs and remained within the PDI array bounds.
A Fixes: tag is not provided since there are no known platforms where the out-of-bounds would be accessed, and the initial code had problems as well.
A follow-up patch completely removes this useless offset.(CVE-2024-38635)
In the Linux kernel, the following vulnerability has been resolved:
riscv: prevent pt_regs corruption for secondary idle threads
Top of the kernel thread stack should be reserved for pt_regs. However this is not the case for the idle threads of the secondary boot harts. Their stacks overlap with their pt_regs, so both may get corrupted.
Similar issue has been fixed for the primary hart, see c7cdd96eca28 ("riscv: prevent stack corruption by reserving task_pt_regs(p) early"). However that fix was not propagated to the secondary harts. The problem has been noticed in some CPU hotplug tests with V enabled. The function smp_callin stored several registers on stack, corrupting top of pt_regs structure including status field. As a result, kernel attempted to save or restore inexistent V context.(CVE-2024-38667)
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: add bounds checking to ocfs2_check_dir_entry()
This adds sanity checks for ocfs2_dir_entry to make sure all members of ocfs2_dir_entry don't stray beyond valid memory region.(CVE-2024-41015)
In the Linux kernel, the following vulnerability has been resolved:
nvmet: fix a possible leak when destroy a ctrl during qp establishment
In nvmet_sq_destroy we capture sq->ctrl early and if it is non-NULL we know that a ctrl was allocated (in the admin connect request handler) and we need to release pending AERs, clear ctrl->sqs and sq->ctrl (for nvme-loop primarily), and drop the final reference on the ctrl.
However, a small window is possible where nvmet_sq_destroy starts (as a result of the client giving up and disconnecting) concurrently with the nvme admin connect cmd (which may be in an early stage). But before kill_and_confirm of sq->ref (i.e. the admin connect managed to get an sq live reference). In this case, sq->ctrl was allocated however after it was captured in a local variable in nvmet_sq_destroy. This prevented the final reference drop on the ctrl.
Solve this by re-capturing the sq->ctrl after all inflight request has completed, where for sure sq->ctrl reference is final, and move forward based on that.
This issue was observed in an environment with many hosts connecting multiple ctrls simoutanuosly, creating a delay in allocating a ctrl leading up to this race window.(CVE-2024-42152)
In the Linux kernel, the following vulnerability has been resolved:
dev/parport: fix the array out-of-bounds risk
Fixed array out-of-bounds issues caused by sprintf by replacing it with snprintf for safer data copying, ensuring the destination buffer is not overflowed.
Below is the stack trace I encountered during the actual issue:
[ 66.575408s] [pid:5118,cpu4,QThread,4]Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: do_hardware_base_addr+0xcc/0xd0 [parport] [ 66.575408s] [pid:5118,cpu4,QThread,5]CPU: 4 PID: 5118 Comm: QThread Tainted: G S W O 5.10.97-arm64-desktop #7100.57021.2 [ 66.575439s] [pid:5118,cpu4,QThread,6]TGID: 5087 Comm: EFileApp [ 66.575439s] [pid:5118,cpu4,QThread,7]Hardware name: HUAWEI HUAWEI QingYun PGUX-W515x-B081/SP1PANGUXM, BIOS 1.00.07 04/29/2024 [ 66.575439s] [pid:5118,cpu4,QThread,8]Call trace: [ 66.575469s] [pid:5118,cpu4,QThread,9] dump_backtrace+0x0/0x1c0 [ 66.575469s] [pid:5118,cpu4,QThread,0] show_stack+0x14/0x20 [ 66.575469s] [pid:5118,cpu4,QThread,1] dump_stack+0xd4/0x10c [ 66.575500s] [pid:5118,cpu4,QThread,2] panic+0x1d8/0x3bc [ 66.575500s] [pid:5118,cpu4,QThread,3] __stack_chk_fail+0x2c/0x38 [ 66.575500s] [pid:5118,cpu4,QThread,4] do_hardware_base_addr+0xcc/0xd0 parport
In the Linux kernel, the following vulnerability has been resolved:
wifi: virt_wifi: avoid reporting connection success with wrong SSID
When user issues a connection with a different SSID than the one virt_wifi has advertised, the __cfg80211_connect_result() will trigger the warning: WARN_ON(bss_not_found).
The issue is because the connection code in virt_wifi does not check the SSID from user space (it only checks the BSSID), and virt_wifi will call cfg80211_connect_result() with WLAN_STATUS_SUCCESS even if the SSID is different from the one virt_wifi has advertised. Eventually cfg80211 won't be able to find the cfg80211_bss and generate the warning.
Fixed it by checking the SSID (from user space) in the connection code.(CVE-2024-43841)
In the Linux kernel, the following vulnerability has been resolved:
jfs: Fix array-index-out-of-bounds in diFree(CVE-2024-43858)
In the Linux kernel, the following vulnerability has been resolved:
drm/nouveau: prime: fix refcount underflow
Calling nouveau_bo_ref() on a nouveau_bo without initializing it (and hence the backing ttm_bo) leads to a refcount underflow.
Instead of calling nouveau_bo_ref() in the unwind path of drm_gem_object_init(), clean things up manually.
(cherry picked from commit 1b93f3e89d03cfc576636e195466a0d728ad8de5)(CVE-2024-43867)
In the Linux kernel, the following vulnerability has been resolved:
devres: Fix memory leakage caused by driver API devm_free_percpu()
It will cause memory leakage when use driver API devm_free_percpu() to free memory allocated by devm_alloc_percpu(), fixed by using devres_release() instead of devres_destroy() within devm_free_percpu().(CVE-2024-43871)
In the Linux kernel, the following vulnerability has been resolved:
drm/client: fix null pointer dereference in drm_client_modeset_probe
In drm_client_modeset_probe(), the return value of drm_mode_duplicate() is assigned to modeset->mode, which will lead to a possible NULL pointer dereference on failure of drm_mode_duplicate(). Add a check to avoid npd.(CVE-2024-43894)
In the Linux kernel, the following vulnerability has been resolved:
usb: dwc3: core: Prevent USB core invalid event buffer address access
This commit addresses an issue where the USB core could access an invalid event buffer address during runtime suspend, potentially causing SMMU faults and other memory issues in Exynos platforms. The problem arises from the following sequence. 1. In dwc3_gadget_suspend, there is a chance of a timeout when moving the USB core to the halt state after clearing the run/stop bit by software. 2. In dwc3_core_exit, the event buffer is cleared regardless of the USB core's status, which may lead to an SMMU faults and other memory issues. if the USB core tries to access the event buffer address.
To prevent this hardware quirk on Exynos platforms, this commit ensures that the event buffer address is not cleared by software when the USB core is active during runtime suspend by checking its status before clearing the buffer address.(CVE-2024-46675)
In the Linux kernel, the following vulnerability has been resolved:
soc: qcom: cmd-db: Map shared memory as WC, not WB
Linux does not write into cmd-db region. This region of memory is write protected by XPU. XPU may sometime falsely detect clean cache eviction as "write" into the write protected region leading to secure interrupt which causes an endless loop somewhere in Trust Zone.
The only reason it is working right now is because Qualcomm Hypervisor maps the same region as Non-Cacheable memory in Stage 2 translation tables. The issue manifests if we want to use another hypervisor (like Xen or KVM), which does not know anything about those specific mappings.
Changing the mapping of cmd-db memory from MEMREMAP_WB to MEMREMAP_WT/WC removes dependency on correct mappings in Stage 2 tables. This patch fixes the issue by updating the mapping to MEMREMAP_WC.
I tested this on SA8155P with Xen.(CVE-2024-46689)
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: fix mc_data out-of-bounds read warning
Clear warning that read mc_data[i-1] may out-of-bounds.(CVE-2024-46722)
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Fix out-of-bounds read of df_v1_7_channel_number
Check the fb_channel_number range to avoid the array out-of-bounds read error(CVE-2024-46724)
In the Linux kernel, the following vulnerability has been resolved:
hwmon: (nct6775-core) Fix underflows seen when writing limit attributes
DIV_ROUND_CLOSEST() after kstrtol() results in an underflow if a large negative number such as -9223372036854775808 is provided by the user. Fix it by reordering clamp_val() and DIV_ROUND_CLOSEST() operations.(CVE-2024-46757)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: added NULL check at start of dc_validate_stream
[Why] prevent invalid memory access
[How] check if dc and stream are NULL(CVE-2024-46802)
In the Linux kernel, the following vulnerability has been resolved:
KVM: x86: Acquire kvm->srcu when handling KVM_SET_VCPU_EVENTS
Grab kvm->srcu when processing KVM_SET_VCPU_EVENTS, as KVM will forcibly leave nested VMX/SVM if SMM mode is being toggled, and leaving nested VMX reads guest memory.
Note, kvm_vcpu_ioctl_x86_set_vcpu_events() can also be called from KVM_RUN via sync_regs(), which already holds SRCU. I.e. trying to precisely use kvm_vcpu_srcu_read_lock() around the problematic SMM code would cause problems. Acquiring SRCU isn't all that expensive, so for simplicity, grab it unconditionally for KVM_SET_VCPU_EVENTS.
============================= WARNING: suspicious RCU usage 6.10.0-rc7-332d2c1d713e-next-vm #552 Not tainted
include/linux/kvm_host.h:1027 suspicious rcu_dereference_check() usage!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 1 1 lock held by repro/1071: #0: ffff88811e424430 (&vcpu->mutex){+.+.}-{3:3}, at: kvm_vcpu_ioctl+0x7d/0x970 [kvm]
stack backtrace: CPU: 15 PID: 1071 Comm: repro Not tainted 6.10.0-rc7-332d2c1d713e-next-vm #552 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: <TASK> dump_stack_lvl+0x7f/0x90 lockdep_rcu_suspicious+0x13f/0x1a0 kvm_vcpu_gfn_to_memslot+0x168/0x190 [kvm] kvm_vcpu_read_guest+0x3e/0x90 [kvm] nested_vmx_load_msr+0x6b/0x1d0 [kvm_intel] load_vmcs12_host_state+0x432/0xb40 [kvm_intel] vmx_leave_nested+0x30/0x40 [kvm_intel] kvm_vcpu_ioctl_x86_set_vcpu_events+0x15d/0x2b0 [kvm] kvm_arch_vcpu_ioctl+0x1107/0x1750 [kvm] ? mark_held_locks+0x49/0x70 ? kvm_vcpu_ioctl+0x7d/0x970 [kvm] ? kvm_vcpu_ioctl+0x497/0x970 [kvm] kvm_vcpu_ioctl+0x497/0x970 [kvm] ? lock_acquire+0xba/0x2d0 ? find_held_lock+0x2b/0x80 ? do_user_addr_fault+0x40c/0x6f0 ? lock_release+0xb7/0x270 __x64_sys_ioctl+0x82/0xb0 do_syscall_64+0x6c/0x170 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7ff11eb1b539 </TASK>(CVE-2024-46830)
In the Linux kernel, the following vulnerability has been resolved:
spi: nxp-fspi: fix the KASAN report out-of-bounds bug
Change the memcpy length to fix the out-of-bounds issue when writing the data that is not 4 byte aligned to TX FIFO.
To reproduce the issue, write 3 bytes data to NOR chip.
dd if=3b of=/dev/mtd0 [ 36.926103] ================================================================== [ 36.933409] BUG: KASAN: slab-out-of-bounds in nxp_fspi_exec_op+0x26ec/0x2838 [ 36.940514] Read of size 4 at addr ffff00081037c2a0 by task dd/455 [ 36.946721] [ 36.948235] CPU: 3 UID: 0 PID: 455 Comm: dd Not tainted 6.11.0-rc5-gc7b0e37c8434 #1070 [ 36.956185] Hardware name: Freescale i.MX8QM MEK (DT) [ 36.961260] Call trace: [ 36.963723] dump_backtrace+0x90/0xe8 [ 36.967414] show_stack+0x18/0x24 [ 36.970749] dump_stack_lvl+0x78/0x90 [ 36.974451] print_report+0x114/0x5cc [ 36.978151] kasan_report+0xa4/0xf0 [ 36.981670] __asan_report_load_n_noabort+0x1c/0x28 [ 36.986587] nxp_fspi_exec_op+0x26ec/0x2838 [ 36.990800] spi_mem_exec_op+0x8ec/0xd30 [ 36.994762] spi_mem_no_dirmap_read+0x190/0x1e0 [ 36.999323] spi_mem_dirmap_write+0x238/0x32c [ 37.003710] spi_nor_write_data+0x220/0x374 [ 37.007932] spi_nor_write+0x110/0x2e8 [ 37.011711] mtd_write_oob_std+0x154/0x1f0 [ 37.015838] mtd_write_oob+0x104/0x1d0 [ 37.019617] mtd_write+0xb8/0x12c [ 37.022953] mtdchar_write+0x224/0x47c [ 37.026732] vfs_write+0x1e4/0x8c8 [ 37.030163] ksys_write+0xec/0x1d0 [ 37.033586] __arm64_sys_write+0x6c/0x9c [ 37.037539] invoke_syscall+0x6c/0x258 [ 37.041327] el0_svc_common.constprop.0+0x160/0x22c [ 37.046244] do_el0_svc+0x44/0x5c [ 37.049589] el0_svc+0x38/0x78 [ 37.052681] el0t_64_sync_handler+0x13c/0x158 [ 37.057077] el0t_64_sync+0x190/0x194 [ 37.060775] [ 37.062274] Allocated by task 455: [ 37.065701] kasan_save_stack+0x2c/0x54 [ 37.069570] kasan_save_track+0x20/0x3c [ 37.073438] kasan_save_alloc_info+0x40/0x54 [ 37.077736] __kasan_kmalloc+0xa0/0xb8 [ 37.081515] __kmalloc_noprof+0x158/0x2f8 [ 37.085563] mtd_kmalloc_up_to+0x120/0x154 [ 37.089690] mtdchar_write+0x130/0x47c [ 37.093469] vfs_write+0x1e4/0x8c8 [ 37.096901] ksys_write+0xec/0x1d0 [ 37.100332] __arm64_sys_write+0x6c/0x9c [ 37.104287] invoke_syscall+0x6c/0x258 [ 37.108064] el0_svc_common.constprop.0+0x160/0x22c [ 37.112972] do_el0_svc+0x44/0x5c [ 37.116319] el0_svc+0x38/0x78 [ 37.119401] el0t_64_sync_handler+0x13c/0x158 [ 37.123788] el0t_64_sync+0x190/0x194 [ 37.127474] [ 37.128977] The buggy address belongs to the object at ffff00081037c2a0 [ 37.128977] which belongs to the cache kmalloc-8 of size 8 [ 37.141177] The buggy address is located 0 bytes inside of [ 37.141177] allocated 3-byte region [ffff00081037c2a0, ffff00081037c2a3) [ 37.153465] [ 37.154971] The buggy address belongs to the physical page: [ 37.160559] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x89037c [ 37.168596] flags: 0xbfffe0000000000(node=0|zone=2|lastcpupid=0x1ffff) [ 37.175149] page_type: 0xfdffffff(slab) [ 37.179021] raw: 0bfffe0000000000 ffff000800002500 dead000000000122 0000000000000000 [ 37.186788] raw: 0000000000000000 0000000080800080 00000001fdffffff 0000000000000000 [ 37.194553] page dumped because: kasan: bad access detected [ 37.200144] [ 37.201647] Memory state around the buggy address: [ 37.206460] ffff00081037c180: fa fc fc fc fa fc fc fc fa fc fc fc fa fc fc fc [ 37.213701] ffff00081037c200: fa fc fc fc 05 fc fc fc 03 fc fc fc 02 fc fc fc [ 37.220946] >ffff00081037c280: 06 fc fc fc 03 fc fc fc fc fc fc fc fc fc fc fc [ 37.228186] ^ [ 37.232473] ffff00081037c300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 37.239718] ffff00081037c380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 37.246962] ============================================================== ---truncated---(CVE-2024-46853)
In the Linux kernel, the following vulnerability has been resolved:
PCI: keystone: Add workaround for Errata #i2037 (AM65x SR 1.0)
Errata #i2037 in AM65x/DRA80xM Processors Silicon Revision 1.0 (SPRZ452D_July 2018_Revised December 2019 [1]) mentions when an inbound PCIe TLP spans more than two internal AXI 128-byte bursts, the bus may corrupt the packet payload and the corrupt data may cause associated applications or the processor to hang.
The workaround for Errata #i2037 is to limit the maximum read request size and maximum payload size to 128 bytes. Add workaround for Errata #i2037 here.
The errata and workaround is applicable only to AM65x SR 1.0 and later versions of the silicon will have this fixed.
[1] -> https://www.ti.com/lit/er/sprz452i/sprz452i.pdf(CVE-2024-47667)
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix state management in error path of log writing function
After commit a694291a6211 ("nilfs2: separate wait function from nilfs_segctor_write") was applied, the log writing function nilfs_segctor_do_construct() was able to issue I/O requests continuously even if user data blocks were split into multiple logs across segments, but two potential flaws were introduced in its error handling.
First, if nilfs_segctor_begin_construction() fails while creating the second or subsequent logs, the log writing function returns without calling nilfs_segctor_abort_construction(), so the writeback flag set on pages/folios will remain uncleared. This causes page cache operations to hang waiting for the writeback flag. For example, truncate_inode_pages_final(), which is called via nilfs_evict_inode() when an inode is evicted from memory, will hang.
Second, the NILFS_I_COLLECTED flag set on normal inodes remain uncleared. As a result, if the next log write involves checkpoint creation, that's fine, but if a partial log write is performed that does not, inodes with NILFS_I_COLLECTED set are erroneously removed from the "sc_dirty_files" list, and their data and b-tree blocks may not be written to the device, corrupting the block mapping.
Fix these issues by uniformly calling nilfs_segctor_abort_construction() on failure of each step in the loop in nilfs_segctor_do_construct(), having it clean up logs and segment usages according to progress, and correcting the conditions for calling nilfs_redirty_inodes() to ensure that the NILFS_I_COLLECTED flag is cleared.(CVE-2024-47669)
In the Linux kernel, the following vulnerability has been resolved: tcp: check skb is non-NULL in tcp_rto_delta_us() We have some machines running stock Ubuntu 20.04.6 which is their 5.4.0-174-generic kernel that are running ceph and recently hit a null ptr dereference in tcp_rearm_rto(). Initially hitting it from the TLP path, but then later we also saw it getting hit from the RACK case as well. Here are examples of the oops messages we saw in each of those cases: Jul 26 15:05:02 rx [11061395.780353] BUG: kernel NULL pointer dereference, address: 0000000000000020 Jul 26 15:05:02 rx [11061395.787572] #PF: supervisor read access in kernel mode Jul 26 15:05:02 rx [11061395.792971] #PF: error_code(0x0000) - not-present page Jul 26 15:05:02 rx [11061395.798362] PGD 0 P4D 0 Jul 26 15:05:02 rx [11061395.801164] Oops: 0000 [#1] SMP NOPTI Jul 26 15:05:02 rx [11061395.805091] CPU: 0 PID: 9180 Comm: msgr-worker-1 Tainted: G W 5.4.0-174-generic #193-Ubuntu Jul 26 15:05:02 rx [11061395.814996] Hardware name: Supermicro SMC 2x26 os-gen8 64C NVME-Y 256G/H12SSW-NTR, BIOS 2.5.V1.2U.NVMe.UEFI 05/09/2023 Jul 26 15:05:02 rx [11061395.825952] RIP: 0010:tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.830656] Code: 87 ca 04 00 00 00 5b 41 5c 41 5d 5d c3 c3 49 8b bc 24 40 06 00 00 eb 8d 48 bb cf f7 53 e3 a5 9b c4 20 4c 89 ef e8 0c fe 0e 00 <48> 8b 78 20 48 c1 ef 03 48 89 f8 41 8b bc 24 80 04 00 00 48 f7 e3 Jul 26 15:05:02 rx [11061395.849665] RSP: 0018:ffffb75d40003e08 EFLAGS: 00010246 Jul 26 15:05:02 rx [11061395.855149] RAX: 0000000000000000 RBX: 20c49ba5e353f7cf RCX: 0000000000000000 Jul 26 15:05:02 rx [11061395.862542] RDX: 0000000062177c30 RSI: 000000000000231c RDI: ffff9874ad283a60 Jul 26 15:05:02 rx [11061395.869933] RBP: ffffb75d40003e20 R08: 0000000000000000 R09: ffff987605e20aa8 Jul 26 15:05:02 rx [11061395.877318] R10: ffffb75d40003f00 R11: ffffb75d4460f740 R12: ffff9874ad283900 Jul 26 15:05:02 rx [11061395.884710] R13: ffff9874ad283a60 R14: ffff9874ad283980 R15: ffff9874ad283d30 Jul 26 15:05:02 rx [11061395.892095] FS: 00007f1ef4a2e700(0000) GS:ffff987605e00000(0000) knlGS:0000000000000000 Jul 26 15:05:02 rx [11061395.900438] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Jul 26 15:05:02 rx [11061395.906435] CR2: 0000000000000020 CR3: 0000003e450ba003 CR4: 0000000000760ef0 Jul 26 15:05:02 rx [11061395.913822] PKRU: 55555554 Jul 26 15:05:02 rx [11061395.916786] Call Trace: Jul 26 15:05:02 rx [11061395.919488] Jul 26 15:05:02 rx [11061395.921765] ? show_regs.cold+0x1a/0x1f Jul 26 15:05:02 rx [11061395.925859] ? __die+0x90/0xd9 Jul 26 15:05:02 rx [11061395.929169] ? no_context+0x196/0x380 Jul 26 15:05:02 rx [11061395.933088] ? ip6_protocol_deliver_rcu+0x4e0/0x4e0 Jul 26 15:05:02 rx [11061395.938216] ? ip6_sublist_rcv_finish+0x3d/0x50 Jul 26 15:05:02 rx [11061395.943000] ? __bad_area_nosemaphore+0x50/0x1a0 Jul 26 15:05:02 rx [11061395.947873] ? bad_area_nosemaphore+0x16/0x20 Jul 26 15:05:02 rx [11061395.952486] ? do_user_addr_fault+0x267/0x450 Jul 26 15:05:02 rx [11061395.957104] ? ipv6_list_rcv+0x112/0x140 Jul 26 15:05:02 rx [11061395.961279] ? __do_page_fault+0x58/0x90 Jul 26 15:05:02 rx [11061395.965458] ? do_page_fault+0x2c/0xe0 Jul 26 15:05:02 rx [11061395.969465] ? page_fault+0x34/0x40 Jul 26 15:05:02 rx [11061395.973217] ? tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.977313] ? tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.981408] tcp_send_loss_probe+0x10b/0x220 Jul 26 15:05:02 rx [11061395.985937] tcp_write_timer_handler+0x1b4/0x240 Jul 26 15:05:02 rx [11061395.990809] tcp_write_timer+0x9e/0xe0 Jul 26 15:05:02 rx [11061395.994814] ? tcp_write_timer_handler+0x240/0x240 Jul 26 15:05:02 rx [11061395.999866] call_timer_fn+0x32/0x130 Jul 26 15:05:02 rx [11061396.003782] __run_timers.part.0+0x180/0x280 Jul 26 15:05:02 rx [11061396.008309] ? recalibrate_cpu_khz+0x10/0x10 Jul 26 15:05:02 rx [11061396.012841] ? native_x2apic_icr_write+0x30/0x30 Jul 26 15:05:02 rx [11061396.017718] ? lapic_next_even ---truncated---(CVE-2024-47684)
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_reject_ipv6: fix nf_reject_ip6_tcphdr_put() syzbot reported that nf_reject_ip6_tcphdr_put() was possibly sending garbage on the four reserved tcp bits (th->res1) Use skb_put_zero() to clear the whole TCP header, as done in nf_reject_ip_tcphdr_put() BUG: KMSAN: uninit-value in nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255 nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255 nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344 nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core net/core/dev.c:5661 [inline] __netif_receive_skb+0x1da/0xa00 net/core/dev.c:5775 process_backlog+0x4ad/0xa50 net/core/dev.c:6108 __napi_poll+0xe7/0x980 net/core/dev.c:6772 napi_poll net/core/dev.c:6841 [inline] net_rx_action+0xa5a/0x19b0 net/core/dev.c:6963 handle_softirqs+0x1ce/0x800 kernel/softirq.c:554 __do_softirq+0x14/0x1a kernel/softirq.c:588 do_softirq+0x9a/0x100 kernel/softirq.c:455 __local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:382 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:908 [inline] __dev_queue_xmit+0x2692/0x5610 net/core/dev.c:4450 dev_queue_xmit include/linux/netdevice.h:3105 [inline] neigh_resolve_output+0x9ca/0xae0 net/core/neighbour.c:1565 neigh_output include/net/neighbour.h:542 [inline] ip6_finish_output2+0x2347/0x2ba0 net/ipv6/ip6_output.c:141 __ip6_finish_output net/ipv6/ip6_output.c:215 [inline] ip6_finish_output+0xbb8/0x14b0 net/ipv6/ip6_output.c:226 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip6_output+0x356/0x620 net/ipv6/ip6_output.c:247 dst_output include/net/dst.h:450 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] ip6_xmit+0x1ba6/0x25d0 net/ipv6/ip6_output.c:366 inet6_csk_xmit+0x442/0x530 net/ipv6/inet6_connection_sock.c:135 __tcp_transmit_skb+0x3b07/0x4880 net/ipv4/tcp_output.c:1466 tcp_transmit_skb net/ipv4/tcp_output.c:1484 [inline] tcp_connect+0x35b6/0x7130 net/ipv4/tcp_output.c:4143 tcp_v6_connect+0x1bcc/0x1e40 net/ipv6/tcp_ipv6.c:333 __inet_stream_connect+0x2ef/0x1730 net/ipv4/af_inet.c:679 inet_stream_connect+0x6a/0xd0 net/ipv4/af_inet.c:750 __sys_connect_file net/socket.c:2061 [inline] __sys_connect+0x606/0x690 net/socket.c:2078 __do_sys_connect net/socket.c:2088 [inline] __se_sys_connect net/socket.c:2085 [inline] __x64_sys_connect+0x91/0xe0 net/socket.c:2085 x64_sys_call+0x27a5/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:43 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit was stored to memory at: nf_reject_ip6_tcphdr_put+0x60c/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:249 nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344 nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core ---truncated---(CVE-2024-47685)
In the Linux kernel, the following vulnerability has been resolved: RDMA/rtrs-clt: Reset cid to con_num - 1 to stay in bounds In the function init_conns(), after the create_con() and create_cm() for loop if something fails. In the cleanup for loop after the destroy tag, we access out of bound memory because cid is set to clt_path->s.con_num. This commits resets the cid to clt_path->s.con_num - 1, to stay in bounds in the cleanup loop later.(CVE-2024-47695)
In the Linux kernel, the following vulnerability has been resolved: drivers: media: dvb-frontends/rtl2832: fix an out-of-bounds write error Ensure index in rtl2832_pid_filter does not exceed 31 to prevent out-of-bounds access. dev->filters is a 32-bit value, so set_bit and clear_bit functions should only operate on indices from 0 to 31. If index is 32, it will attempt to access a non-existent 33rd bit, leading to out-of-bounds access. Change the boundary check from index > 32 to index >= 32 to resolve this issue. hverkuil: added fixes tag, rtl2830_pid_filter -> rtl2832_pid_filter in logmsg
In the Linux kernel, the following vulnerability has been resolved: can: bcm: Clear bo->bcm_proc_read after remove_proc_entry(). syzbot reported a warning in bcm_release(). [0] The blamed change fixed another warning that is triggered when connect() is issued again for a socket whose connect()ed device has been unregistered. However, if the socket is just close()d without the 2nd connect(), the remaining bo->bcm_proc_read triggers unnecessary remove_proc_entry() in bcm_release(). Let's clear bo->bcm_proc_read after remove_proc_entry() in bcm_notify(). [0] name '4986' WARNING: CPU: 0 PID: 5234 at fs/proc/generic.c:711 remove_proc_entry+0x2e7/0x5d0 fs/proc/generic.c:711 Modules linked in: CPU: 0 UID: 0 PID: 5234 Comm: syz-executor606 Not tainted 6.11.0-rc5-syzkaller-00178-g5517ae241919 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:remove_proc_entry+0x2e7/0x5d0 fs/proc/generic.c:711 Code: ff eb 05 e8 cb 1e 5e ff 48 8b 5c 24 10 48 c7 c7 e0 f7 aa 8e e8 2a 38 8e 09 90 48 c7 c7 60 3a 1b 8c 48 89 de e8 da 42 20 ff 90 <0f> 0b 90 90 48 8b 44 24 18 48 c7 44 24 40 0e 36 e0 45 49 c7 04 07 RSP: 0018:ffffc9000345fa20 EFLAGS: 00010246 RAX: 2a2d0aee2eb64600 RBX: ffff888032f1f548 RCX: ffff888029431e00 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffc9000345fb08 R08: ffffffff8155b2f2 R09: 1ffff1101710519a R10: dffffc0000000000 R11: ffffed101710519b R12: ffff888011d38640 R13: 0000000000000004 R14: 0000000000000000 R15: dffffc0000000000 FS: 0000000000000000(0000) GS:ffff8880b8800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fcfb52722f0 CR3: 000000000e734000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> bcm_release+0x250/0x880 net/can/bcm.c:1578 __sock_release net/socket.c:659 [inline] sock_close+0xbc/0x240 net/socket.c:1421 __fput+0x24a/0x8a0 fs/file_table.c:422 task_work_run+0x24f/0x310 kernel/task_work.c:228 exit_task_work include/linux/task_work.h:40 [inline] do_exit+0xa2f/0x27f0 kernel/exit.c:882 do_group_exit+0x207/0x2c0 kernel/exit.c:1031 __do_sys_exit_group kernel/exit.c:1042 [inline] __se_sys_exit_group kernel/exit.c:1040 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1040 x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232 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:0x7fcfb51ee969 Code: Unable to access opcode bytes at 0x7fcfb51ee93f. RSP: 002b:00007ffce0109ca8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007fcfb51ee969 RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000001 RBP: 00007fcfb526f3b0 R08: ffffffffffffffb8 R09: 0000555500000000 R10: 0000555500000000 R11: 0000000000000246 R12: 00007fcfb526f3b0 R13: 0000000000000000 R14: 00007fcfb5271ee0 R15: 00007fcfb51bf160 </TASK>(CVE-2024-47709)
In the Linux kernel, the following vulnerability has been resolved: sock_map: Add a cond_resched() in sock_hash_free() Several syzbot soft lockup reports all have in common sock_hash_free() If a map with a large number of buckets is destroyed, we need to yield the cpu when needed.(CVE-2024-47710)
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for set_output_gamma in dcn30_set_output_transfer_func This commit adds a null check for the set_output_gamma function pointer in the dcn30_set_output_transfer_func function. Previously, set_output_gamma was being checked for nullity at line 386, but then it was being dereferenced without any nullity check at line 401. This could potentially lead to a null pointer dereference error if set_output_gamma is indeed null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a nullity check for set_output_gamma before the call to set_output_gamma at line 401. If set_output_gamma is null, we log an error message and do not call the function. This fix prevents a potential null pointer dereference error. drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:401 dcn30_set_output_transfer_func() error: we previously assumed 'mpc->funcs->set_output_gamma' could be null (see line 386) drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c 373 bool dcn30_set_output_transfer_func(struct dc dc, 374 struct pipe_ctx pipe_ctx, 375 const struct dc_stream_state stream) 376 { 377 int mpcc_id = pipe_ctx->plane_res.hubp->inst; 378 struct mpc mpc = pipe_ctx->stream_res.opp->ctx->dc->res_pool->mpc; 379 const struct pwl_params params = NULL; 380 bool ret = false; 381 382 / program OGAM or 3DLUT only for the top pipe/ 383 if (pipe_ctx->top_pipe == NULL) { 384 /program rmu shaper and 3dlut in MPC/ 385 ret = dcn30_set_mpc_shaper_3dlut(pipe_ctx, stream); 386 if (ret == false && mpc->funcs->set_output_gamma) { ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ If this is NULL 387 if (stream->out_transfer_func.type == TF_TYPE_HWPWL) 388 params = &stream->out_transfer_func.pwl; 389 else if (pipe_ctx->stream->out_transfer_func.type == 390 TF_TYPE_DISTRIBUTED_POINTS && 391 cm3_helper_translate_curve_to_hw_format( 392 &stream->out_transfer_func, 393 &mpc->blender_params, false)) 394 params = &mpc->blender_params; 395 / there are no ROM LUTs in OUTGAM */ 396 if (stream->out_transfer_func.type == TF_TYPE_PREDEFINED) 397 BREAK_TO_DEBUGGER(); 398 } 399 } 400 --> 401 mpc->funcs->set_output_gamma(mpc, mpcc_id, params); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Then it will crash 402 return ret; 403 }(CVE-2024-47720)
In the Linux kernel, the following vulnerability has been resolved: nfsd: call cache_put if xdr_reserve_space returns NULL If not enough buffer space available, but idmap_lookup has triggered lookup_fn which calls cache_get and returns successfully. Then we missed to call cache_put here which pairs with cache_get. Reviwed-by: Jeff Layton <jlayton@kernel.org>(CVE-2024-47737)
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential oob read in nilfs_btree_check_delete() The function nilfs_btree_check_delete(), which checks whether degeneration to direct mapping occurs before deleting a b-tree entry, causes memory access outside the block buffer when retrieving the maximum key if the root node has no entries. This does not usually happen because b-tree mappings with 0 child nodes are never created by mkfs.nilfs2 or nilfs2 itself. However, it can happen if the b-tree root node read from a device is configured that way, so fix this potential issue by adding a check for that case.(CVE-2024-47757)
In the Linux kernel, the following vulnerability has been resolved: tracing/timerlat: Fix a race during cpuhp processing There is another found exception that the "timerlat/1" thread was scheduled on CPU0, and lead to timer corruption finally: ODEBUG: init active (active state 0) object: ffff888237c2e108 object type: hrtimer hint: timerlat_irq+0x0/0x220 WARNING: CPU: 0 PID: 426 at lib/debugobjects.c:518 debug_print_object+0x7d/0xb0 Modules linked in: CPU: 0 UID: 0 PID: 426 Comm: timerlat/1 Not tainted 6.11.0-rc7+ #45 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:debug_print_object+0x7d/0xb0 ... Call Trace: <TASK> ? __warn+0x7c/0x110 ? debug_print_object+0x7d/0xb0 ? report_bug+0xf1/0x1d0 ? prb_read_valid+0x17/0x20 ? handle_bug+0x3f/0x70 ? exc_invalid_op+0x13/0x60 ? asm_exc_invalid_op+0x16/0x20 ? debug_print_object+0x7d/0xb0 ? debug_print_object+0x7d/0xb0 ? __pfx_timerlat_irq+0x10/0x10 __debug_object_init+0x110/0x150 hrtimer_init+0x1d/0x60 timerlat_main+0xab/0x2d0 ? __pfx_timerlat_main+0x10/0x10 kthread+0xb7/0xe0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> After tracing the scheduling event, it was discovered that the migration of the "timerlat/1" thread was performed during thread creation. Further analysis confirmed that it is because the CPU online processing for osnoise is implemented through workers, which is asynchronous with the offline processing. When the worker was scheduled to create a thread, the CPU may has already been removed from the cpu_online_mask during the offline process, resulting in the inability to select the right CPU: T1 | T2 [CPUHP_ONLINE] | cpu_device_down() osnoise_hotplug_workfn() | | cpus_write_lock() | takedown_cpu(1) | cpus_write_unlock() [CPUHP_OFFLINE] | cpus_read_lock() | start_kthread(1) | cpus_read_unlock() | To fix this, skip online processing if the CPU is already offline.(CVE-2024-49866)
In the Linux kernel, the following vulnerability has been resolved: btrfs: wait for fixup workers before stopping cleaner kthread during umount During unmount, at close_ctree(), we have the following steps in this order: 1) Park the cleaner kthread - this doesn't destroy the kthread, it basically halts its execution (wake ups against it work but do nothing); 2) We stop the cleaner kthread - this results in freeing the respective struct task_struct; 3) We call btrfs_stop_all_workers() which waits for any jobs running in all the work queues and then free the work queues. Syzbot reported a case where a fixup worker resulted in a crash when doing a delayed iput on its inode while attempting to wake up the cleaner at btrfs_add_delayed_iput(), because the task_struct of the cleaner kthread was already freed. This can happen during unmount because we don't wait for any fixup workers still running before we call kthread_stop() against the cleaner kthread, which stops and free all its resources. Fix this by waiting for any fixup workers at close_ctree() before we call kthread_stop() against the cleaner and run pending delayed iputs. The stack traces reported by syzbot were the following: BUG: KASAN: slab-use-after-free in __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065 Read of size 8 at addr ffff8880272a8a18 by task kworker/u8:3/52 CPU: 1 UID: 0 PID: 52 Comm: kworker/u8:3 Not tainted 6.12.0-rc1-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Workqueue: btrfs-fixup btrfs_work_helper Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0xd5/0x120 kernel/locking/spinlock.c:162 class_raw_spinlock_irqsave_constructor include/linux/spinlock.h:551 [inline] try_to_wake_up+0xb0/0x1480 kernel/sched/core.c:4154 btrfs_writepage_fixup_worker+0xc16/0xdf0 fs/btrfs/inode.c:2842 btrfs_work_helper+0x390/0xc50 fs/btrfs/async-thread.c:314 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa63/0x1850 kernel/workqueue.c:3310 worker_thread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 </TASK> Allocated by task 2: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:319 [inline] __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:345 kasan_slab_alloc include/linux/kasan.h:247 [inline] slab_post_alloc_hook mm/slub.c:4086 [inline] slab_alloc_node mm/slub.c:4135 [inline] kmem_cache_alloc_node_noprof+0x16b/0x320 mm/slub.c:4187 alloc_task_struct_node kernel/fork.c:180 [inline] dup_task_struct+0x57/0x8c0 kernel/fork.c:1107 copy_process+0x5d1/0x3d50 kernel/fork.c:2206 kernel_clone+0x223/0x880 kernel/fork.c:2787 kernel_thread+0x1bc/0x240 kernel/fork.c:2849 create_kthread kernel/kthread.c:412 [inline] kthreadd+0x60d/0x810 kernel/kthread.c:765 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Freed by task 61: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:230 [inline] slab_free_h ---truncated---(CVE-2024-49867)
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix a NULL pointer dereference when failed to start a new trasacntion [BUG] Syzbot reported a NULL pointer dereference with the following crash: FAULT_INJECTION: forcing a failure. start_transaction+0x830/0x1670 fs/btrfs/transaction.c:676 prepare_to_relocate+0x31f/0x4c0 fs/btrfs/relocation.c:3642 relocate_block_group+0x169/0xd20 fs/btrfs/relocation.c:3678 ... BTRFS info (device loop0): balance: ended with status: -12 Oops: general protection fault, probably for non-canonical address 0xdffffc00000000cc: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000660-0x0000000000000667] RIP: 0010:btrfs_update_reloc_root+0x362/0xa80 fs/btrfs/relocation.c:926 Call Trace: <TASK> commit_fs_roots+0x2ee/0x720 fs/btrfs/transaction.c:1496 btrfs_commit_transaction+0xfaf/0x3740 fs/btrfs/transaction.c:2430 del_balance_item fs/btrfs/volumes.c:3678 [inline] reset_balance_state+0x25e/0x3c0 fs/btrfs/volumes.c:3742 btrfs_balance+0xead/0x10c0 fs/btrfs/volumes.c:4574 btrfs_ioctl_balance+0x493/0x7c0 fs/btrfs/ioctl.c:3673 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893 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 [CAUSE] The allocation failure happens at the start_transaction() inside prepare_to_relocate(), and during the error handling we call unset_reloc_control(), which makes fs_info->balance_ctl to be NULL. Then we continue the error path cleanup in btrfs_balance() by calling reset_balance_state() which will call del_balance_item() to fully delete the balance item in the root tree. However during the small window between set_reloc_contrl() and unset_reloc_control(), we can have a subvolume tree update and created a reloc_root for that subvolume. Then we go into the final btrfs_commit_transaction() of del_balance_item(), and into btrfs_update_reloc_root() inside commit_fs_roots(). That function checks if fs_info->reloc_ctl is in the merge_reloc_tree stage, but since fs_info->reloc_ctl is NULL, it results a NULL pointer dereference. [FIX] Just add extra check on fs_info->reloc_ctl inside btrfs_update_reloc_root(), before checking fs_info->reloc_ctl->merge_reloc_tree. That DEAD_RELOC_TREE handling is to prevent further modification to the reloc tree during merge stage, but since there is no reloc_ctl at all, we do not need to bother that.(CVE-2024-49868)
In the Linux kernel, the following vulnerability has been resolved: nfsd: map the EBADMSG to nfserr_io to avoid warning Ext4 will throw -EBADMSG through ext4_readdir when a checksum error occurs, resulting in the following WARNING. Fix it by mapping EBADMSG to nfserr_io. nfsd_buffered_readdir iterate_dir // -EBADMSG -74 ext4_readdir // .iterate_shared ext4_dx_readdir ext4_htree_fill_tree htree_dirblock_to_tree ext4_read_dirblock __ext4_read_dirblock ext4_dirblock_csum_verify warn_no_space_for_csum __warn_no_space_for_csum return ERR_PTR(-EFSBADCRC) // -EBADMSG -74 nfserrno // WARNING [ 161.115610] ------------[ cut here ]------------ [ 161.116465] nfsd: non-standard errno: -74 [ 161.117315] WARNING: CPU: 1 PID: 780 at fs/nfsd/nfsproc.c:878 nfserrno+0x9d/0xd0 [ 161.118596] Modules linked in: [ 161.119243] CPU: 1 PID: 780 Comm: nfsd Not tainted 5.10.0-00014-g79679361fd5d #138 [ 161.120684] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qe mu.org 04/01/2014 [ 161.123601] RIP: 0010:nfserrno+0x9d/0xd0 [ 161.124676] Code: 0f 87 da 30 dd 00 83 e3 01 b8 00 00 00 05 75 d7 44 89 ee 48 c7 c7 c0 57 24 98 89 44 24 04 c6 05 ce 2b 61 03 01 e8 99 20 d8 00 <0f> 0b 8b 44 24 04 eb b5 4c 89 e6 48 c7 c7 a0 6d a4 99 e8 cc 15 33 [ 161.127797] RSP: 0018:ffffc90000e2f9c0 EFLAGS: 00010286 [ 161.128794] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 161.130089] RDX: 1ffff1103ee16f6d RSI: 0000000000000008 RDI: fffff520001c5f2a [ 161.131379] RBP: 0000000000000022 R08: 0000000000000001 R09: ffff8881f70c1827 [ 161.132664] R10: ffffed103ee18304 R11: 0000000000000001 R12: 0000000000000021 [ 161.133949] R13: 00000000ffffffb6 R14: ffff8881317c0000 R15: ffffc90000e2fbd8 [ 161.135244] FS: 0000000000000000(0000) GS:ffff8881f7080000(0000) knlGS:0000000000000000 [ 161.136695] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 161.137761] CR2: 00007fcaad70b348 CR3: 0000000144256006 CR4: 0000000000770ee0 [ 161.139041] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 161.140291] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 161.141519] PKRU: 55555554 [ 161.142076] Call Trace: [ 161.142575] ? __warn+0x9b/0x140 [ 161.143229] ? nfserrno+0x9d/0xd0 [ 161.143872] ? report_bug+0x125/0x150 [ 161.144595] ? handle_bug+0x41/0x90 [ 161.145284] ? exc_invalid_op+0x14/0x70 [ 161.146009] ? asm_exc_invalid_op+0x12/0x20 [ 161.146816] ? nfserrno+0x9d/0xd0 [ 161.147487] nfsd_buffered_readdir+0x28b/0x2b0 [ 161.148333] ? nfsd4_encode_dirent_fattr+0x380/0x380 [ 161.149258] ? nfsd_buffered_filldir+0xf0/0xf0 [ 161.150093] ? wait_for_concurrent_writes+0x170/0x170 [ 161.151004] ? generic_file_llseek_size+0x48/0x160 [ 161.151895] nfsd_readdir+0x132/0x190 [ 161.152606] ? nfsd4_encode_dirent_fattr+0x380/0x380 [ 161.153516] ? nfsd_unlink+0x380/0x380 [ 161.154256] ? override_creds+0x45/0x60 [ 161.155006] nfsd4_encode_readdir+0x21a/0x3d0 [ 161.155850] ? nfsd4_encode_readlink+0x210/0x210 [ 161.156731] ? write_bytes_to_xdr_buf+0x97/0xe0 [ 161.157598] ? __write_bytes_to_xdr_buf+0xd0/0xd0 [ 161.158494] ? lock_downgrade+0x90/0x90 [ 161.159232] ? nfs4svc_decode_voidarg+0x10/0x10 [ 161.160092] nfsd4_encode_operation+0x15a/0x440 [ 161.160959] nfsd4_proc_compound+0x718/0xe90 [ 161.161818] nfsd_dispatch+0x18e/0x2c0 [ 161.162586] svc_process_common+0x786/0xc50 [ 161.163403] ? nfsd_svc+0x380/0x380 [ 161.164137] ? svc_printk+0x160/0x160 [ 161.164846] ? svc_xprt_do_enqueue.part.0+0x365/0x380 [ 161.165808] ? nfsd_svc+0x380/0x380 [ 161.166523] ? rcu_is_watching+0x23/0x40 [ 161.167309] svc_process+0x1a5/0x200 [ 161.168019] nfsd+0x1f5/0x380 [ 161.168663] ? nfsd_shutdown_threads+0x260/0x260 [ 161.169554] kthread+0x1c4/0x210 [ 161.170224] ? kthread_insert_work_sanity_check+0x80/0x80 [ 161.171246] ret_from_fork+0x1f/0x30(CVE-2024-49875)
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in degamma hardware format translation Fixes index out of bounds issue in cm_helper_translate_curve_to_degamma_hw_format function. The issue could occur when the index 'i' exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure 'i' is within bounds before accessing the transfer function points. If 'i' is out of bounds the function returns false to indicate an error. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:594 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:595 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:596 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max(CVE-2024-49894)
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in DCN30 degamma hardware format translation This commit addresses a potential index out of bounds issue in the cm3_helper_translate_curve_to_degamma_hw_format function in the DCN30 color management module. The issue could occur when the index 'i' exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure 'i' is within bounds before accessing the transfer function points. If 'i' is out of bounds, the function returns false to indicate an error. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:338 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:339 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:340 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max(CVE-2024-49895)
In the Linux kernel, the following vulnerability has been resolved: jfs: Fix uninit-value access of new_ea in ea_buffer syzbot reports that lzo1x_1_do_compress is using uninit-value: ===================================================== BUG: KMSAN: uninit-value in lzo1x_1_do_compress+0x19f9/0x2510 lib/lzo/lzo1x_compress.c:178 ... Uninit was stored to memory at: ea_put fs/jfs/xattr.c:639 [inline] ... Local variable ea_buf created at: __jfs_setxattr+0x5d/0x1ae0 fs/jfs/xattr.c:662 __jfs_xattr_set+0xe6/0x1f0 fs/jfs/xattr.c:934 ===================================================== The reason is ea_buf->new_ea is not initialized properly. Fix this by using memset to empty its content at the beginning in ea_get().(CVE-2024-49900)
In the Linux kernel, the following vulnerability has been resolved: jfs: check if leafidx greater than num leaves per dmap tree syzbot report a out of bounds in dbSplit, it because dmt_leafidx greater than num leaves per dmap tree, add a checking for dmt_leafidx in dbFindLeaf. Shaggy: Modified sanity check to apply to control pages as well as leaf pages.(CVE-2024-49902)
In the Linux kernel, the following vulnerability has been resolved: jfs: Fix uaf in dbFreeBits [syzbot reported] ================================================================== BUG: KASAN: slab-use-after-free in __mutex_lock_common kernel/locking/mutex.c:587 [inline] BUG: KASAN: slab-use-after-free in __mutex_lock+0xfe/0xd70 kernel/locking/mutex.c:752 Read of size 8 at addr ffff8880229254b0 by task syz-executor357/5216 CPU: 0 UID: 0 PID: 5216 Comm: syz-executor357 Not tainted 6.11.0-rc3-syzkaller-00156-gd7a5aa4b3c00 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 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 __mutex_lock_common kernel/locking/mutex.c:587 [inline] __mutex_lock+0xfe/0xd70 kernel/locking/mutex.c:752 dbFreeBits+0x7ea/0xd90 fs/jfs/jfs_dmap.c:2390 dbFreeDmap fs/jfs/jfs_dmap.c:2089 [inline] dbFree+0x35b/0x680 fs/jfs/jfs_dmap.c:409 dbDiscardAG+0x8a9/0xa20 fs/jfs/jfs_dmap.c:1650 jfs_ioc_trim+0x433/0x670 fs/jfs/jfs_discard.c:100 jfs_ioctl+0x2d0/0x3e0 fs/jfs/ioctl.c:131 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 Freed by task 5218: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579 poison_slab_object+0xe0/0x150 mm/kasan/common.c:240 __kasan_slab_free+0x37/0x60 mm/kasan/common.c:256 kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2252 [inline] slab_free mm/slub.c:4473 [inline] kfree+0x149/0x360 mm/slub.c:4594 dbUnmount+0x11d/0x190 fs/jfs/jfs_dmap.c:278 jfs_mount_rw+0x4ac/0x6a0 fs/jfs/jfs_mount.c:247 jfs_remount+0x3d1/0x6b0 fs/jfs/super.c:454 reconfigure_super+0x445/0x880 fs/super.c:1083 vfs_cmd_reconfigure fs/fsopen.c:263 [inline] vfs_fsconfig_locked fs/fsopen.c:292 [inline] __do_sys_fsconfig fs/fsopen.c:473 [inline] __se_sys_fsconfig+0xb6e/0xf80 fs/fsopen.c:345 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 [Analysis] There are two paths (dbUnmount and jfs_ioc_trim) that generate race condition when accessing bmap, which leads to the occurrence of uaf. Use the lock s_umount to synchronize them, in order to avoid uaf caused by race condition.(CVE-2024-49903)
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for function pointer in dcn20_set_output_transfer_func This commit adds a null check for the set_output_gamma function pointer in the dcn20_set_output_transfer_func function. Previously, set_output_gamma was being checked for null at line 1030, but then it was being dereferenced without any null check at line 1048. This could potentially lead to a null pointer dereference error if set_output_gamma is null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a null check for set_output_gamma before the call to set_output_gamma at line 1048.(CVE-2024-49911)
In the Linux kernel, the following vulnerability has been resolved: x86/ioapic: Handle allocation failures gracefully Breno observed panics when using failslab under certain conditions during runtime: can not alloc irq_pin_list (-1,0,20) Kernel panic - not syncing: IO-APIC: failed to add irq-pin. Can not proceed panic+0x4e9/0x590 mp_irqdomain_alloc+0x9ab/0xa80 irq_domain_alloc_irqs_locked+0x25d/0x8d0 __irq_domain_alloc_irqs+0x80/0x110 mp_map_pin_to_irq+0x645/0x890 acpi_register_gsi_ioapic+0xe6/0x150 hpet_open+0x313/0x480 That's a pointless panic which is a leftover of the historic IO/APIC code which panic'ed during early boot when the interrupt allocation failed. The only place which might justify panic is the PIT/HPET timer_check() code which tries to figure out whether the timer interrupt is delivered through the IO/APIC. But that code does not require to handle interrupt allocation failures. If the interrupt cannot be allocated then timer delivery fails and it either panics due to that or falls back to legacy mode. Cure this by removing the panic wrapper around __add_pin_to_irq_node() and making mp_irqdomain_alloc() aware of the failure condition and handle it as any other failure in this function gracefully.(CVE-2024-49927)
In the Linux kernel, the following vulnerability has been resolved: jbd2: stop waiting for space when jbd2_cleanup_journal_tail() returns error In __jbd2_log_wait_for_space(), we might call jbd2_cleanup_journal_tail() to recover some journal space. But if an error occurs while executing jbd2_cleanup_journal_tail() (e.g., an EIO), we don't stop waiting for free space right away, we try other branches, and if j_committing_transaction is NULL (i.e., the tid is 0), we will get the following complain: ============================================ JBD2: I/O error when updating journal superblock for sdd-8. __jbd2_log_wait_for_space: needed 256 blocks and only had 217 space available __jbd2_log_wait_for_space: no way to get more journal space in sdd-8 ------------[ cut here ]------------ WARNING: CPU: 2 PID: 139804 at fs/jbd2/checkpoint.c:109 __jbd2_log_wait_for_space+0x251/0x2e0 Modules linked in: CPU: 2 PID: 139804 Comm: kworker/u8:3 Not tainted 6.6.0+ #1 RIP: 0010:__jbd2_log_wait_for_space+0x251/0x2e0 Call Trace: <TASK> add_transaction_credits+0x5d1/0x5e0 start_this_handle+0x1ef/0x6a0 jbd2__journal_start+0x18b/0x340 ext4_dirty_inode+0x5d/0xb0 __mark_inode_dirty+0xe4/0x5d0 generic_update_time+0x60/0x70 [...] ============================================ So only if jbd2_cleanup_journal_tail() returns 1, i.e., there is nothing to clean up at the moment, continue to try to reclaim free space in other ways. Note that this fix relies on commit 6f6a6fda2945 ("jbd2: fix ocfs2 corrupt when updating journal superblock fails") to make jbd2_cleanup_journal_tail return the correct error code.(CVE-2024-49959)
In the Linux kernel, the following vulnerability has been resolved: ocfs2: cancel dqi_sync_work before freeing oinfo ocfs2_global_read_info() will initialize and schedule dqi_sync_work at the end, if error occurs after successfully reading global quota, it will trigger the following warning with CONFIG_DEBUG_OBJECTS_* enabled: ODEBUG: free active (active state 0) object: 00000000d8b0ce28 object type: timer_list hint: qsync_work_fn+0x0/0x16c This reports that there is an active delayed work when freeing oinfo in error handling, so cancel dqi_sync_work first. BTW, return status instead of -1 when .read_file_info fails.(CVE-2024-49966)
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in DCN30 color transformation This commit addresses a potential index out of bounds issue in the cm3_helper_translate_curve_to_hw_format function in the DCN30 color management module. The issue could occur when the index 'i' exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure 'i' is within bounds before accessing the transfer function points. If 'i' is out of bounds, the function returns false to indicate an error. drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:180 cm3_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:181 cm3_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:182 cm3_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max(CVE-2024-49969)
In the Linux kernel, the following vulnerability has been resolved: NFSD: Limit the number of concurrent async COPY operations Nothing appears to limit the number of concurrent async COPY operations that clients can start. In addition, AFAICT each async COPY can copy an unlimited number of 4MB chunks, so can run for a long time. Thus IMO async COPY can become a DoS vector. Add a restriction mechanism that bounds the number of concurrent background COPY operations. Start simple and try to be fair -- this patch implements a per-namespace limit. An async COPY request that occurs while this limit is exceeded gets NFS4ERR_DELAY. The requesting client can choose to send the request again after a delay or fall back to a traditional read/write style copy. If there is need to make the mechanism more sophisticated, we can visit that in future patches.(CVE-2024-49974)
In the Linux kernel, the following vulnerability has been resolved: i2c: stm32f7: Do not prepare/unprepare clock during runtime suspend/resume In case there is any sort of clock controller attached to this I2C bus controller, for example Versaclock or even an AIC32x4 I2C codec, then an I2C transfer triggered from the clock controller clk_ops .prepare callback may trigger a deadlock on drivers/clk/clk.c prepare_lock mutex. This is because the clock controller first grabs the prepare_lock mutex and then performs the prepare operation, including its I2C access. The I2C access resumes this I2C bus controller via .runtime_resume callback, which calls clk_prepare_enable(), which attempts to grab the prepare_lock mutex again and deadlocks. Since the clock are already prepared since probe() and unprepared in remove(), use simple clk_enable()/clk_disable() calls to enable and disable the clock on runtime suspend and resume, to avoid hitting the prepare_lock mutex.(CVE-2024-49985)
In the Linux kernel, the following vulnerability has been resolved: ALSA: asihpi: Fix potential OOB array access ASIHPI driver stores some values in the static array upon a response from the driver, and its index depends on the firmware. We shouldn't trust it blindly. This patch adds a sanity check of the array index to fit in the array size.(CVE-2024-50007)
In the Linux kernel, the following vulnerability has been resolved: scsi: fnic: Move flush_work initialization out of if block After commit 379a58caa199 ("scsi: fnic: Move fnic_fnic_flush_tx() to a work queue"), it can happen that a work item is sent to an uninitialized work queue. This may has the effect that the item being queued is never actually queued, and any further actions depending on it will not proceed. The following warning is observed while the fnic driver is loaded: kernel: WARNING: CPU: 11 PID: 0 at ../kernel/workqueue.c:1524 __queue_work+0x373/0x410 kernel: <IRQ> kernel: queue_work_on+0x3a/0x50 kernel: fnic_wq_copy_cmpl_handler+0x54a/0x730 [fnic 62fbff0c42e7fb825c60a55cde2fb91facb2ed24] kernel: fnic_isr_msix_wq_copy+0x2d/0x60 [fnic 62fbff0c42e7fb825c60a55cde2fb91facb2ed24] kernel: __handle_irq_event_percpu+0x36/0x1a0 kernel: handle_irq_event_percpu+0x30/0x70 kernel: handle_irq_event+0x34/0x60 kernel: handle_edge_irq+0x7e/0x1a0 kernel: __common_interrupt+0x3b/0xb0 kernel: common_interrupt+0x58/0xa0 kernel: </IRQ> It has been observed that this may break the rediscovery of Fibre Channel devices after a temporary fabric failure. This patch fixes it by moving the work queue initialization out of an if block in fnic_probe().(CVE-2024-50025)
In the Linux kernel, the following vulnerability has been resolved: net: do not delay dst_entries_add() in dst_release() dst_entries_add() uses per-cpu data that might be freed at netns dismantle from ip6_route_net_exit() calling dst_entries_destroy() Before ip6_route_net_exit() can be called, we release all the dsts associated with this netns, via calls to dst_release(), which waits an rcu grace period before calling dst_destroy() dst_entries_add() use in dst_destroy() is racy, because dst_entries_destroy() could have been called already. Decrementing the number of dsts must happen sooner. Notes: 1) in CONFIG_XFRM case, dst_destroy() can call dst_release_immediate(child), this might also cause UAF if the child does not have DST_NOCOUNT set. IPSEC maintainers might take a look and see how to address this. 2) There is also discussion about removing this count of dst, which might happen in future kernels.(CVE-2024-50036)
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointer before dereferencing se [WHAT & HOW] se is null checked previously in the same function, indicating it might be null; therefore, it must be checked when used again. This fixes 1 FORWARD_NULL issue reported by Coverity.(CVE-2024-50049)
| URL | Type | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"kernel-5.10.0-136.99.0.180.oe2203sp1.aarch64.rpm",
"kernel-debuginfo-5.10.0-136.99.0.180.oe2203sp1.aarch64.rpm",
"kernel-debugsource-5.10.0-136.99.0.180.oe2203sp1.aarch64.rpm",
"kernel-devel-5.10.0-136.99.0.180.oe2203sp1.aarch64.rpm",
"kernel-headers-5.10.0-136.99.0.180.oe2203sp1.aarch64.rpm",
"kernel-source-5.10.0-136.99.0.180.oe2203sp1.aarch64.rpm",
"kernel-tools-5.10.0-136.99.0.180.oe2203sp1.aarch64.rpm",
"kernel-tools-debuginfo-5.10.0-136.99.0.180.oe2203sp1.aarch64.rpm",
"kernel-tools-devel-5.10.0-136.99.0.180.oe2203sp1.aarch64.rpm",
"perf-5.10.0-136.99.0.180.oe2203sp1.aarch64.rpm",
"perf-debuginfo-5.10.0-136.99.0.180.oe2203sp1.aarch64.rpm",
"python3-perf-5.10.0-136.99.0.180.oe2203sp1.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-136.99.0.180.oe2203sp1.aarch64.rpm"
],
"src": [
"kernel-5.10.0-136.99.0.180.oe2203sp1.src.rpm"
],
"x86_64": [
"kernel-5.10.0-136.99.0.180.oe2203sp1.x86_64.rpm",
"kernel-debuginfo-5.10.0-136.99.0.180.oe2203sp1.x86_64.rpm",
"kernel-debugsource-5.10.0-136.99.0.180.oe2203sp1.x86_64.rpm",
"kernel-devel-5.10.0-136.99.0.180.oe2203sp1.x86_64.rpm",
"kernel-headers-5.10.0-136.99.0.180.oe2203sp1.x86_64.rpm",
"kernel-source-5.10.0-136.99.0.180.oe2203sp1.x86_64.rpm",
"kernel-tools-5.10.0-136.99.0.180.oe2203sp1.x86_64.rpm",
"kernel-tools-debuginfo-5.10.0-136.99.0.180.oe2203sp1.x86_64.rpm",
"kernel-tools-devel-5.10.0-136.99.0.180.oe2203sp1.x86_64.rpm",
"perf-5.10.0-136.99.0.180.oe2203sp1.x86_64.rpm",
"perf-debuginfo-5.10.0-136.99.0.180.oe2203sp1.x86_64.rpm",
"python3-perf-5.10.0-136.99.0.180.oe2203sp1.x86_64.rpm",
"python3-perf-debuginfo-5.10.0-136.99.0.180.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.99.0.180.oe2203sp1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "Critical"
},
"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\niommu/vt-d: Fix double list_add when enabling VMD in scalable mode\r\n\r\nWhen enabling VMD and IOMMU scalable mode, the following kernel panic\ncall trace/kernel log is shown in Eagle Stream platform (Sapphire Rapids\nCPU) during booting:\r\n\r\npci 0000:59:00.5: Adding to iommu group 42\n...\nvmd 0000:59:00.5: PCI host bridge to bus 10000:80\npci 10000:80:01.0: [8086:352a] type 01 class 0x060400\npci 10000:80:01.0: reg 0x10: [mem 0x00000000-0x0001ffff 64bit]\npci 10000:80:01.0: enabling Extended Tags\npci 10000:80:01.0: PME# supported from D0 D3hot D3cold\npci 10000:80:01.0: DMAR: Setup RID2PASID failed\npci 10000:80:01.0: Failed to add to iommu group 42: -16\npci 10000:80:03.0: [8086:352b] type 01 class 0x060400\npci 10000:80:03.0: reg 0x10: [mem 0x00000000-0x0001ffff 64bit]\npci 10000:80:03.0: enabling Extended Tags\npci 10000:80:03.0: PME# supported from D0 D3hot D3cold\n------------[ cut here ]------------\nkernel BUG at lib/list_debug.c:29!\ninvalid opcode: 0000 [#1] PREEMPT SMP NOPTI\nCPU: 0 PID: 7 Comm: kworker/0:1 Not tainted 5.17.0-rc3+ #7\nHardware name: Lenovo ThinkSystem SR650V3/SB27A86647, BIOS ESE101Y-1.00 01/13/2022\nWorkqueue: events work_for_cpu_fn\nRIP: 0010:__list_add_valid.cold+0x26/0x3f\nCode: 9a 4a ab ff 4c 89 c1 48 c7 c7 40 0c d9 9e e8 b9 b1 fe ff 0f\n 0b 48 89 f2 4c 89 c1 48 89 fe 48 c7 c7 f0 0c d9 9e e8 a2 b1\n fe ff \u0026lt;0f\u0026gt; 0b 48 89 d1 4c 89 c6 4c 89 ca 48 c7 c7 98 0c d9\n 9e e8 8b b1 fe\nRSP: 0000:ff5ad434865b3a40 EFLAGS: 00010246\nRAX: 0000000000000058 RBX: ff4d61160b74b880 RCX: ff4d61255e1fffa8\nRDX: 0000000000000000 RSI: 00000000fffeffff RDI: ffffffff9fd34f20\nRBP: ff4d611d8e245c00 R08: 0000000000000000 R09: ff5ad434865b3888\nR10: ff5ad434865b3880 R11: ff4d61257fdc6fe8 R12: ff4d61160b74b8a0\nR13: ff4d61160b74b8a0 R14: ff4d611d8e245c10 R15: ff4d611d8001ba70\nFS: 0000000000000000(0000) GS:ff4d611d5ea00000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: ff4d611fa1401000 CR3: 0000000aa0210001 CR4: 0000000000771ef0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400\nPKRU: 55555554\nCall Trace:\n \u0026lt;TASK\u0026gt;\n intel_pasid_alloc_table+0x9c/0x1d0\n dmar_insert_one_dev_info+0x423/0x540\n ? device_to_iommu+0x12d/0x2f0\n intel_iommu_attach_device+0x116/0x290\n __iommu_attach_device+0x1a/0x90\n iommu_group_add_device+0x190/0x2c0\n __iommu_probe_device+0x13e/0x250\n iommu_probe_device+0x24/0x150\n iommu_bus_notifier+0x69/0x90\n blocking_notifier_call_chain+0x5a/0x80\n device_add+0x3db/0x7b0\n ? arch_memremap_can_ram_remap+0x19/0x50\n ? memremap+0x75/0x140\n pci_device_add+0x193/0x1d0\n pci_scan_single_device+0xb9/0xf0\n pci_scan_slot+0x4c/0x110\n pci_scan_child_bus_extend+0x3a/0x290\n vmd_enable_domain.constprop.0+0x63e/0x820\n vmd_probe+0x163/0x190\n local_pci_probe+0x42/0x80\n work_for_cpu_fn+0x13/0x20\n process_one_work+0x1e2/0x3b0\n worker_thread+0x1c4/0x3a0\n ? rescuer_thread+0x370/0x370\n kthread+0xc7/0xf0\n ? kthread_complete_and_exit+0x20/0x20\n ret_from_fork+0x1f/0x30\n \u0026lt;/TASK\u0026gt;\nModules linked in:\n---[ end trace 0000000000000000 ]---\n...\nKernel panic - not syncing: Fatal exception\nKernel Offset: 0x1ca00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)\n---[ end Kernel panic - not syncing: Fatal exception ]---\r\n\r\nThe following \u0026apos;lspci\u0026apos; output shows devices \u0026apos;10000:80:*\u0026apos; are subdevices of\nthe VMD device 0000:59:00.5:\r\n\r\n $ lspci\n ...\n 0000:59:00.5 RAID bus controller: Intel Corporation Volume Management Device NVMe RAID Controller (rev 20)\n ...\n 10000:80:01.0 PCI bridge: Intel Corporation Device 352a (rev 03)\n 10000:80:03.0 PCI bridge: Intel Corporation Device 352b (rev 03)\n 10000:80:05.0 PCI bridge: Intel Corporation Device 352c (rev 03)\n 10000:80:07.0 PCI bridge: Intel Corporation Device 352d (rev 03)\n 10000:81:00.0 Non-Volatile memory controller: Intel Corporation NVMe Datacenter SSD [3DNAND, Beta Rock Controller]\n 10000:82:00\n---truncated---(CVE-2022-48916)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: udf: Fix preallocation discarding at indirect extent boundary When preallocation extent is the first one in the extent block, the code would corrupt extent tree header instead. Fix the problem and use udf_delete_aext() for deleting extent to avoid some code duplication.(CVE-2022-48946)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: PCI: mt7621: Add sentinel to quirks table Current driver is missing a sentinel in the struct soc_device_attribute array, which causes an oops when assessed by the soc_device_match(mt7621_pcie_quirks_match) call. This was only exposed once the CONFIG_SOC_MT7621 mt7621 soc_dev_attr was fixed to register the SOC as a device, in: commit 7c18b64bba3b (\u0026quot;mips: ralink: mt7621: do not use kzalloc too early\u0026quot;) Fix it by adding the required sentinel.(CVE-2022-48952)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: NFC: nci: Bounds check struct nfc_target arrays While running under CONFIG_FORTIFY_SOURCE=y, syzkaller reported: memcpy: detected field-spanning write (size 129) of single field \u0026quot;target-\u0026gt;sensf_res\u0026quot; at net/nfc/nci/ntf.c:260 (size 18) This appears to be a legitimate lack of bounds checking in nci_add_new_protocol(). Add the missing checks.(CVE-2022-48967)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: gpio: amd8111: Fix PCI device reference count leak for_each_pci_dev() is implemented by pci_get_device(). The comment of pci_get_device() says that it will increase the reference count for the returned pci_dev and also decrease the reference count for the input pci_dev @from if it is not NULL. If we break for_each_pci_dev() loop with pdev not NULL, we need to call pci_dev_put() to decrease the reference count. Add the missing pci_dev_put() after the \u0026apos;out\u0026apos; label. Since pci_dev_put() can handle NULL input parameter, there is no problem for the \u0026apos;Device not found\u0026apos; branch. For the normal path, add pci_dev_put() in amd_gpio_exit().(CVE-2022-48973)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: can: af_can: fix NULL pointer dereference in can_rcv_filter Analogue to commit 8aa59e355949 (\u0026quot;can: af_can: fix NULL pointer dereference in can_rx_register()\u0026quot;) we need to check for a missing initialization of ml_priv in the receive path of CAN frames. Since commit 4e096a18867a (\u0026quot;net: introduce CAN specific pointer in the struct net_device\u0026quot;) the check for dev-\u0026gt;type to be ARPHRD_CAN is not sufficient anymore since bonding or tun netdevices claim to be CAN devices but do not initialize ml_priv accordingly.(CVE-2022-48977)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: mm/gup: fix gup_pud_range() for dax For dax pud, pud_huge() returns true on x86. So the function works as long as hugetlb is configured. However, dax doesn\u0026apos;t depend on hugetlb. Commit 414fd080d125 (\u0026quot;mm/gup: fix gup_pmd_range() for dax\u0026quot;) fixed devmap-backed huge PMDs, but missed devmap-backed huge PUDs. Fix this as well. This fixes the below kernel panic: general protection fault, probably for non-canonical address 0x69e7c000cc478: 0000 [#1] SMP \u0026lt; snip \u0026gt; Call Trace: \u0026lt;TASK\u0026gt; get_user_pages_fast+0x1f/0x40 iov_iter_get_pages+0xc6/0x3b0 ? mempool_alloc+0x5d/0x170 bio_iov_iter_get_pages+0x82/0x4e0 ? bvec_alloc+0x91/0xc0 ? bio_alloc_bioset+0x19a/0x2a0 blkdev_direct_IO+0x282/0x480 ? __io_complete_rw_common+0xc0/0xc0 ? filemap_range_has_page+0x82/0xc0 generic_file_direct_write+0x9d/0x1a0 ? inode_update_time+0x24/0x30 __generic_file_write_iter+0xbd/0x1e0 blkdev_write_iter+0xb4/0x150 ? io_import_iovec+0x8d/0x340 io_write+0xf9/0x300 io_issue_sqe+0x3c3/0x1d30 ? sysvec_reschedule_ipi+0x6c/0x80 __io_queue_sqe+0x33/0x240 ? fget+0x76/0xa0 io_submit_sqes+0xe6a/0x18d0 ? __fget_light+0xd1/0x100 __x64_sys_io_uring_enter+0x199/0x880 ? __context_tracking_enter+0x1f/0x70 ? irqentry_exit_to_user_mode+0x24/0x30 ? irqentry_exit+0x1d/0x30 ? __context_tracking_exit+0xe/0x70 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x61/0xcb RIP: 0033:0x7fc97c11a7be \u0026lt; snip \u0026gt; \u0026lt;/TASK\u0026gt; ---[ end trace 48b2e0e67debcaeb ]--- RIP: 0010:internal_get_user_pages_fast+0x340/0x990 \u0026lt; snip \u0026gt; Kernel panic - not syncing: Fatal exception Kernel Offset: disabled(CVE-2022-48986)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: memcg: fix possible use-after-free in memcg_write_event_control() memcg_write_event_control() accesses the dentry-\u0026gt;d_name of the specified control fd to route the write call. As a cgroup interface file can\u0026apos;t be renamed, it\u0026apos;s safe to access d_name as long as the specified file is a regular cgroup file. Also, as these cgroup interface files can\u0026apos;t be removed before the directory, it\u0026apos;s safe to access the parent too. Prior to 347c4a874710 (\u0026quot;memcg: remove cgroup_event-\u0026gt;cft\u0026quot;), there was a call to __file_cft() which verified that the specified file is a regular cgroupfs file before further accesses. The cftype pointer returned from __file_cft() was no longer necessary and the commit inadvertently dropped the file type check with it allowing any file to slip through. With the invarients broken, the d_name and parent accesses can now race against renames and removals of arbitrary files and cause use-after-free\u0026apos;s. Fix the bug by resurrecting the file type check in __file_cft(). Now that cgroupfs is implemented through kernfs, checking the file operations needs to go through a layer of indirection. Instead, let\u0026apos;s check the superblock and dentry type.(CVE-2022-48988)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: mm/khugepaged: invoke MMU notifiers in shmem/file collapse paths Any codepath that zaps page table entries must invoke MMU notifiers to ensure that secondary MMUs (like KVM) don\u0026apos;t keep accessing pages which aren\u0026apos;t mapped anymore. Secondary MMUs don\u0026apos;t hold their own references to pages that are mirrored over, so failing to notify them can lead to page use-after-free. I\u0026apos;m marking this as addressing an issue introduced in commit f3f0e1d2150b (\u0026quot;khugepaged: add support of collapse for tmpfs/shmem pages\u0026quot;), but most of the security impact of this only came in commit 27e1f8273113 (\u0026quot;khugepaged: enable collapse pmd for pte-mapped THP\u0026quot;), which actually omitted flushes for the removal of present PTEs, not just for the removal of empty page tables.(CVE-2022-48991)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: ALSA: seq: Fix function prototype mismatch in snd_seq_expand_var_event With clang\u0026apos;s kernel control flow integrity (kCFI, CONFIG_CFI_CLANG), indirect call targets are validated against the expected function pointer prototype to make sure the call target is valid to help mitigate ROP attacks. If they are not identical, there is a failure at run time, which manifests as either a kernel panic or thread getting killed. seq_copy_in_user() and seq_copy_in_kernel() did not have prototypes matching snd_seq_dump_func_t. Adjust this and remove the casts. There are not resulting binary output differences. This was found as a result of Clang\u0026apos;s new -Wcast-function-type-strict flag, which is more sensitive than the simpler -Wcast-function-type, which only checks for type width mismatches.(CVE-2022-48994)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: tracing: Free buffers when a used dynamic event is removed(CVE-2022-49006)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: nilfs2: fix NULL pointer dereference in nilfs_palloc_commit_free_entry() Syzbot reported a null-ptr-deref bug: NILFS (loop0): segctord starting. Construction interval = 5 seconds, CP frequency \u0026lt; 30 seconds general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] CPU: 1 PID: 3603 Comm: segctord Not tainted 6.1.0-rc2-syzkaller-00105-gb229b6ca5abb #0 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 10/11/2022 RIP: 0010:nilfs_palloc_commit_free_entry+0xe5/0x6b0 fs/nilfs2/alloc.c:608 Code: 00 00 00 00 fc ff df 80 3c 02 00 0f 85 cd 05 00 00 48 b8 00 00 00 00 00 fc ff df 4c 8b 73 08 49 8d 7e 10 48 89 fa 48 c1 ea 03 \u0026lt;80\u0026gt; 3c 02 00 0f 85 26 05 00 00 49 8b 46 10 be a6 00 00 00 48 c7 c7 RSP: 0018:ffffc90003dff830 EFLAGS: 00010212 RAX: dffffc0000000000 RBX: ffff88802594e218 RCX: 000000000000000d RDX: 0000000000000002 RSI: 0000000000002000 RDI: 0000000000000010 RBP: ffff888071880222 R08: 0000000000000005 R09: 000000000000003f R10: 000000000000000d R11: 0000000000000000 R12: ffff888071880158 R13: ffff88802594e220 R14: 0000000000000000 R15: 0000000000000004 FS: 0000000000000000(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fb1c08316a8 CR3: 0000000018560000 CR4: 0000000000350ee0 Call Trace: \u0026lt;TASK\u0026gt; nilfs_dat_commit_free fs/nilfs2/dat.c:114 [inline] nilfs_dat_commit_end+0x464/0x5f0 fs/nilfs2/dat.c:193 nilfs_dat_commit_update+0x26/0x40 fs/nilfs2/dat.c:236 nilfs_btree_commit_update_v+0x87/0x4a0 fs/nilfs2/btree.c:1940 nilfs_btree_commit_propagate_v fs/nilfs2/btree.c:2016 [inline] nilfs_btree_propagate_v fs/nilfs2/btree.c:2046 [inline] nilfs_btree_propagate+0xa00/0xd60 fs/nilfs2/btree.c:2088 nilfs_bmap_propagate+0x73/0x170 fs/nilfs2/bmap.c:337 nilfs_collect_file_data+0x45/0xd0 fs/nilfs2/segment.c:568 nilfs_segctor_apply_buffers+0x14a/0x470 fs/nilfs2/segment.c:1018 nilfs_segctor_scan_file+0x3f4/0x6f0 fs/nilfs2/segment.c:1067 nilfs_segctor_collect_blocks fs/nilfs2/segment.c:1197 [inline] nilfs_segctor_collect fs/nilfs2/segment.c:1503 [inline] nilfs_segctor_do_construct+0x12fc/0x6af0 fs/nilfs2/segment.c:2045 nilfs_segctor_construct+0x8e3/0xb30 fs/nilfs2/segment.c:2379 nilfs_segctor_thread_construct fs/nilfs2/segment.c:2487 [inline] nilfs_segctor_thread+0x3c3/0xf30 fs/nilfs2/segment.c:2570 kthread+0x2e4/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306 \u0026lt;/TASK\u0026gt; ... If DAT metadata file is corrupted on disk, there is a case where req-\u0026gt;pr_desc_bh is NULL and blocknr is 0 at nilfs_dat_commit_end() during a b-tree operation that cascadingly updates ancestor nodes of the b-tree, because nilfs_dat_commit_alloc() for a lower level block can initialize the blocknr on the same DAT entry between nilfs_dat_prepare_end() and nilfs_dat_commit_end(). If this happens, nilfs_dat_commit_end() calls nilfs_dat_commit_free() without valid buffer heads in req-\u0026gt;pr_desc_bh and req-\u0026gt;pr_bitmap_bh, and causes the NULL pointer dereference above in nilfs_palloc_commit_free_entry() function, which leads to a crash. Fix this by adding a NULL check on req-\u0026gt;pr_desc_bh and req-\u0026gt;pr_bitmap_bh before nilfs_palloc_commit_free_entry() in nilfs_dat_commit_free(). This also calls nilfs_error() in that case to notify that there is a fatal flaw in the filesystem metadata and prevent further operations.(CVE-2022-49007)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: net: ethernet: nixge: fix NULL dereference In function nixge_hw_dma_bd_release() dereference of NULL pointer priv-\u0026gt;rx_bd_v is possible for the case of its allocation failure in nixge_hw_dma_bd_init(). Move for() loop with priv-\u0026gt;rx_bd_v dereference under the check for its validity. Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2022-49019)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: hwmon: (ibmpex) Fix possible UAF when ibmpex_register_bmc() fails Smatch report warning as follows: drivers/hwmon/ibmpex.c:509 ibmpex_register_bmc() warn: \u0026apos;\u0026amp;data-\u0026gt;list\u0026apos; not removed from list If ibmpex_find_sensors() fails in ibmpex_register_bmc(), data will be freed, but data-\u0026gt;list will not be removed from driver_data.bmc_data, then list traversal may cause UAF. Fix by removeing it from driver_data.bmc_data before free().(CVE-2022-49029)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: libbpf: Handle size overflow for ringbuf mmap The maximum size of ringbuf is 2GB on x86-64 host, so 2 * max_entries will overflow u32 when mapping producer page and data pages. Only casting max_entries to size_t is not enough, because for 32-bits application on 64-bits kernel the size of read-only mmap region also could overflow size_t. So fixing it by casting the size of read-only mmap region into a __u64 and checking whether or not there will be overflow during mmap.(CVE-2022-49030)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: btrfs: qgroup: fix sleep from invalid context bug in btrfs_qgroup_inherit() Syzkaller reported BUG as follows: BUG: sleeping function called from invalid context at include/linux/sched/mm.h:274 Call Trace: \u0026lt;TASK\u0026gt; dump_stack_lvl+0xcd/0x134 __might_resched.cold+0x222/0x26b kmem_cache_alloc+0x2e7/0x3c0 update_qgroup_limit_item+0xe1/0x390 btrfs_qgroup_inherit+0x147b/0x1ee0 create_subvol+0x4eb/0x1710 btrfs_mksubvol+0xfe5/0x13f0 __btrfs_ioctl_snap_create+0x2b0/0x430 btrfs_ioctl_snap_create_v2+0x25a/0x520 btrfs_ioctl+0x2a1c/0x5ce0 __x64_sys_ioctl+0x193/0x200 do_syscall_64+0x35/0x80 Fix this by calling qgroup_dirty() on @dstqgroup, and update limit item in btrfs_run_qgroups() later outside of the spinlock context.(CVE-2022-49033)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: imon: fix access to invalid resource for the second interface\r\n\r\nimon driver probes two USB interfaces, and at the probe of the second\ninterface, the driver assumes blindly that the first interface got\nbound with the same imon driver. It\u0026apos;s usually true, but it\u0026apos;s still\npossible that the first interface is bound with another driver via a\nmalformed descriptor. Then it may lead to a memory corruption, as\nspotted by syzkaller; imon driver accesses the data from drvdata as\nstruct imon_context object although it\u0026apos;s a completely different one\nthat was assigned by another driver.\r\n\r\nThis patch adds a sanity check -- whether the first interface is\nreally bound with the imon driver or not -- for avoiding the problem\nabove at the probe time.(CVE-2023-52754)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: dwc2: fix possible NULL pointer dereference caused by driver concurrency\r\n\r\nIn _dwc2_hcd_urb_enqueue(), \u0026quot;urb-\u0026gt;hcpriv = NULL\u0026quot; is executed without\nholding the lock \u0026quot;hsotg-\u0026gt;lock\u0026quot;. In _dwc2_hcd_urb_dequeue():\r\n\r\n spin_lock_irqsave(\u0026amp;hsotg-\u0026gt;lock, flags);\n ...\n\tif (!urb-\u0026gt;hcpriv) {\n\t\tdev_dbg(hsotg-\u0026gt;dev, \u0026quot;## urb-\u0026gt;hcpriv is NULL ##\\n\u0026quot;);\n\t\tgoto out;\n\t}\n rc = dwc2_hcd_urb_dequeue(hsotg, urb-\u0026gt;hcpriv); // Use urb-\u0026gt;hcpriv\n ...\nout:\n spin_unlock_irqrestore(\u0026amp;hsotg-\u0026gt;lock, flags);\r\n\r\nWhen _dwc2_hcd_urb_enqueue() and _dwc2_hcd_urb_dequeue() are\nconcurrently executed, the NULL check of \u0026quot;urb-\u0026gt;hcpriv\u0026quot; can be executed\nbefore \u0026quot;urb-\u0026gt;hcpriv = NULL\u0026quot;. After urb-\u0026gt;hcpriv is NULL, it can be used\nin the function call to dwc2_hcd_urb_dequeue(), which can cause a NULL\npointer dereference.\r\n\r\nThis possible bug is found by an experimental static analysis tool\ndeveloped by myself. This tool analyzes the locking APIs to extract\nfunction pairs that can be concurrently executed, and then analyzes the\ninstructions in the paired functions to identify possible concurrency\nbugs including data races and atomicity violations. The above possible\nbug is reported, when my tool analyzes the source code of Linux 6.5.\r\n\r\nTo fix this possible bug, \u0026quot;urb-\u0026gt;hcpriv = NULL\u0026quot; should be executed with\nholding the lock \u0026quot;hsotg-\u0026gt;lock\u0026quot;. After using this patch, my tool never\nreports the possible bug, with the kernelconfiguration allyesconfig for\nx86_64. Because I have no associated hardware, I cannot test the patch\nin runtime testing, and just verify it according to the code logic.(CVE-2023-52855)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: ntb: intel: Fix the NULL vs IS_ERR() bug for debugfs_create_dir() The debugfs_create_dir() function returns error pointers. It never returns NULL. So use IS_ERR() to check it.(CVE-2023-52917)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: media: pci: cx23885: check cx23885_vdev_init() return cx23885_vdev_init() can return a NULL pointer, but that pointer is used in the next line without a check. Add a NULL pointer check and go to the error unwind if it is NULL.(CVE-2023-52918)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: nfc: nci: fix possible NULL pointer dereference in send_acknowledge() Handle memory allocation failure from nci_skb_alloc() (calling alloc_skb()) to avoid possible NULL pointer dereference.(CVE-2023-52919)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: Revert \u0026quot;scsi: fcoe: Fix potential deadlock on \u0026amp;fip-\u0026gt;ctlr_lock\u0026quot;\r\n\r\nThis reverts commit 1a1975551943f681772720f639ff42fbaa746212.\r\n\r\nThis commit causes interrupts to be lost for FCoE devices, since it changed\nsping locks from \u0026quot;bh\u0026quot; to \u0026quot;irqsave\u0026quot;.\r\n\r\nInstead, a work queue should be used, and will be addressed in a separate\ncommit.(CVE-2024-26917)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nof: module: prevent NULL pointer dereference in vsnprintf()\r\n\r\nIn of_modalias(), we can get passed the str and len parameters which would\ncause a kernel oops in vsnprintf() since it only allows passing a NULL ptr\nwhen the length is also 0. Also, we need to filter out the negative values\nof the len parameter as these will result in a really huge buffer since\nsnprintf() takes size_t parameter while ours is ssize_t...\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with the Svace static\nanalysis tool.(CVE-2024-35878)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndma: xilinx_dpdma: Fix locking\r\n\r\nThere are several places where either chan-\u0026gt;lock or chan-\u0026gt;vchan.lock was\nnot held. Add appropriate locking. This fixes lockdep warnings like\r\n\r\n[ 31.077578] ------------[ cut here ]------------\n[ 31.077831] WARNING: CPU: 2 PID: 40 at drivers/dma/xilinx/xilinx_dpdma.c:834 xilinx_dpdma_chan_queue_transfer+0x274/0x5e0\n[ 31.077953] Modules linked in:\n[ 31.078019] CPU: 2 PID: 40 Comm: kworker/u12:1 Not tainted 6.6.20+ #98\n[ 31.078102] Hardware name: xlnx,zynqmp (DT)\n[ 31.078169] Workqueue: events_unbound deferred_probe_work_func\n[ 31.078272] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[ 31.078377] pc : xilinx_dpdma_chan_queue_transfer+0x274/0x5e0\n[ 31.078473] lr : xilinx_dpdma_chan_queue_transfer+0x270/0x5e0\n[ 31.078550] sp : ffffffc083bb2e10\n[ 31.078590] x29: ffffffc083bb2e10 x28: 0000000000000000 x27: ffffff880165a168\n[ 31.078754] x26: ffffff880164e920 x25: ffffff880164eab8 x24: ffffff880164d480\n[ 31.078920] x23: ffffff880165a148 x22: ffffff880164e988 x21: 0000000000000000\n[ 31.079132] x20: ffffffc082aa3000 x19: ffffff880164e880 x18: 0000000000000000\n[ 31.079295] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000\n[ 31.079453] x14: 0000000000000000 x13: ffffff8802263dc0 x12: 0000000000000001\n[ 31.079613] x11: 0001ffc083bb2e34 x10: 0001ff880164e98f x9 : 0001ffc082aa3def\n[ 31.079824] x8 : 0001ffc082aa3dec x7 : 0000000000000000 x6 : 0000000000000516\n[ 31.079982] x5 : ffffffc7f8d43000 x4 : ffffff88003c9c40 x3 : ffffffffffffffff\n[ 31.080147] x2 : ffffffc7f8d43000 x1 : 00000000000000c0 x0 : 0000000000000000\n[ 31.080307] Call trace:\n[ 31.080340] xilinx_dpdma_chan_queue_transfer+0x274/0x5e0\n[ 31.080518] xilinx_dpdma_issue_pending+0x11c/0x120\n[ 31.080595] zynqmp_disp_layer_update+0x180/0x3ac\n[ 31.080712] zynqmp_dpsub_plane_atomic_update+0x11c/0x21c\n[ 31.080825] drm_atomic_helper_commit_planes+0x20c/0x684\n[ 31.080951] drm_atomic_helper_commit_tail+0x5c/0xb0\n[ 31.081139] commit_tail+0x234/0x294\n[ 31.081246] drm_atomic_helper_commit+0x1f8/0x210\n[ 31.081363] drm_atomic_commit+0x100/0x140\n[ 31.081477] drm_client_modeset_commit_atomic+0x318/0x384\n[ 31.081634] drm_client_modeset_commit_locked+0x8c/0x24c\n[ 31.081725] drm_client_modeset_commit+0x34/0x5c\n[ 31.081812] __drm_fb_helper_restore_fbdev_mode_unlocked+0x104/0x168\n[ 31.081899] drm_fb_helper_set_par+0x50/0x70\n[ 31.081971] fbcon_init+0x538/0xc48\n[ 31.082047] visual_init+0x16c/0x23c\n[ 31.082207] do_bind_con_driver.isra.0+0x2d0/0x634\n[ 31.082320] do_take_over_console+0x24c/0x33c\n[ 31.082429] do_fbcon_takeover+0xbc/0x1b0\n[ 31.082503] fbcon_fb_registered+0x2d0/0x34c\n[ 31.082663] register_framebuffer+0x27c/0x38c\n[ 31.082767] __drm_fb_helper_initial_config_and_unlock+0x5c0/0x91c\n[ 31.082939] drm_fb_helper_initial_config+0x50/0x74\n[ 31.083012] drm_fbdev_dma_client_hotplug+0xb8/0x108\n[ 31.083115] drm_client_register+0xa0/0xf4\n[ 31.083195] drm_fbdev_dma_setup+0xb0/0x1cc\n[ 31.083293] zynqmp_dpsub_drm_init+0x45c/0x4e0\n[ 31.083431] zynqmp_dpsub_probe+0x444/0x5e0\n[ 31.083616] platform_probe+0x8c/0x13c\n[ 31.083713] really_probe+0x258/0x59c\n[ 31.083793] __driver_probe_device+0xc4/0x224\n[ 31.083878] driver_probe_device+0x70/0x1c0\n[ 31.083961] __device_attach_driver+0x108/0x1e0\n[ 31.084052] bus_for_each_drv+0x9c/0x100\n[ 31.084125] __device_attach+0x100/0x298\n[ 31.084207] device_initial_probe+0x14/0x20\n[ 31.084292] bus_probe_device+0xd8/0xdc\n[ 31.084368] deferred_probe_work_func+0x11c/0x180\n[ 31.084451] process_one_work+0x3ac/0x988\n[ 31.084643] worker_thread+0x398/0x694\n[ 31.084752] kthread+0x1bc/0x1c0\n[ 31.084848] ret_from_fork+0x10/0x20\n[ 31.084932] irq event stamp: 64549\n[ 31.084970] hardirqs last enabled at (64548): [\u0026lt;ffffffc081adf35c\u0026gt;] _raw_spin_unlock_irqrestore+0x80/0x90\n[ 31.085157]\n---truncated---(CVE-2024-35990)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nfnetlink_queue: acquire rcu_read_lock() in instance_destroy_rcu()\r\n\r\nsyzbot reported that nf_reinject() could be called without rcu_read_lock() :\r\n\r\nWARNING: suspicious RCU usage\n6.9.0-rc7-syzkaller-02060-g5c1672705a1a #0 Not tainted\r\n\r\nnet/netfilter/nfnetlink_queue.c:263 suspicious rcu_dereference_check() usage!\r\n\r\nother info that might help us debug this:\r\n\r\nrcu_scheduler_active = 2, debug_locks = 1\n2 locks held by syz-executor.4/13427:\n #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_lock_acquire include/linux/rcupdate.h:329 [inline]\n #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_do_batch kernel/rcu/tree.c:2190 [inline]\n #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_core+0xa86/0x1830 kernel/rcu/tree.c:2471\n #1: ffff88801ca92958 (\u0026amp;inst-\u0026gt;lock){+.-.}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline]\n #1: ffff88801ca92958 (\u0026amp;inst-\u0026gt;lock){+.-.}-{2:2}, at: nfqnl_flush net/netfilter/nfnetlink_queue.c:405 [inline]\n #1: ffff88801ca92958 (\u0026amp;inst-\u0026gt;lock){+.-.}-{2:2}, at: instance_destroy_rcu+0x30/0x220 net/netfilter/nfnetlink_queue.c:172\r\n\r\nstack backtrace:\nCPU: 0 PID: 13427 Comm: syz-executor.4 Not tainted 6.9.0-rc7-syzkaller-02060-g5c1672705a1a #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024\nCall Trace:\n \u0026lt;IRQ\u0026gt;\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114\n lockdep_rcu_suspicious+0x221/0x340 kernel/locking/lockdep.c:6712\n nf_reinject net/netfilter/nfnetlink_queue.c:323 [inline]\n nfqnl_reinject+0x6ec/0x1120 net/netfilter/nfnetlink_queue.c:397\n nfqnl_flush net/netfilter/nfnetlink_queue.c:410 [inline]\n instance_destroy_rcu+0x1ae/0x220 net/netfilter/nfnetlink_queue.c:172\n rcu_do_batch kernel/rcu/tree.c:2196 [inline]\n rcu_core+0xafd/0x1830 kernel/rcu/tree.c:2471\n handle_softirqs+0x2d6/0x990 kernel/softirq.c:554\n __do_softirq kernel/softirq.c:588 [inline]\n invoke_softirq kernel/softirq.c:428 [inline]\n __irq_exit_rcu+0xf4/0x1c0 kernel/softirq.c:637\n irq_exit_rcu+0x9/0x30 kernel/softirq.c:649\n instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1043 [inline]\n sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1043\n \u0026lt;/IRQ\u0026gt;\n \u0026lt;TASK\u0026gt;(CVE-2024-36286)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsoundwire: cadence: fix invalid PDI offset\r\n\r\nFor some reason, we add an offset to the PDI, presumably to skip the\nPDI0 and PDI1 which are reserved for BPT.\r\n\r\nThis code is however completely wrong and leads to an out-of-bounds\naccess. We were just lucky so far since we used only a couple of PDIs\nand remained within the PDI array bounds.\r\n\r\nA Fixes: tag is not provided since there are no known platforms where\nthe out-of-bounds would be accessed, and the initial code had problems\nas well.\r\n\r\nA follow-up patch completely removes this useless offset.(CVE-2024-38635)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nriscv: prevent pt_regs corruption for secondary idle threads\r\n\r\nTop of the kernel thread stack should be reserved for pt_regs. However\nthis is not the case for the idle threads of the secondary boot harts.\nTheir stacks overlap with their pt_regs, so both may get corrupted.\r\n\r\nSimilar issue has been fixed for the primary hart, see c7cdd96eca28\n(\u0026quot;riscv: prevent stack corruption by reserving task_pt_regs(p) early\u0026quot;).\nHowever that fix was not propagated to the secondary harts. The problem\nhas been noticed in some CPU hotplug tests with V enabled. The function\nsmp_callin stored several registers on stack, corrupting top of pt_regs\nstructure including status field. As a result, kernel attempted to save\nor restore inexistent V context.(CVE-2024-38667)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nocfs2: add bounds checking to ocfs2_check_dir_entry()\r\n\r\nThis adds sanity checks for ocfs2_dir_entry to make sure all members of\nocfs2_dir_entry don\u0026apos;t stray beyond valid memory region.(CVE-2024-41015)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnvmet: fix a possible leak when destroy a ctrl during qp establishment\r\n\r\nIn nvmet_sq_destroy we capture sq-\u0026gt;ctrl early and if it is non-NULL we\nknow that a ctrl was allocated (in the admin connect request handler)\nand we need to release pending AERs, clear ctrl-\u0026gt;sqs and sq-\u0026gt;ctrl\n(for nvme-loop primarily), and drop the final reference on the ctrl.\r\n\r\nHowever, a small window is possible where nvmet_sq_destroy starts (as\na result of the client giving up and disconnecting) concurrently with\nthe nvme admin connect cmd (which may be in an early stage). But *before*\nkill_and_confirm of sq-\u0026gt;ref (i.e. the admin connect managed to get an sq\nlive reference). In this case, sq-\u0026gt;ctrl was allocated however after it was\ncaptured in a local variable in nvmet_sq_destroy.\nThis prevented the final reference drop on the ctrl.\r\n\r\nSolve this by re-capturing the sq-\u0026gt;ctrl after all inflight request has\ncompleted, where for sure sq-\u0026gt;ctrl reference is final, and move forward\nbased on that.\r\n\r\nThis issue was observed in an environment with many hosts connecting\nmultiple ctrls simoutanuosly, creating a delay in allocating a ctrl\nleading up to this race window.(CVE-2024-42152)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndev/parport: fix the array out-of-bounds risk\r\n\r\nFixed array out-of-bounds issues caused by sprintf\nby replacing it with snprintf for safer data copying,\nensuring the destination buffer is not overflowed.\r\n\r\nBelow is the stack trace I encountered during the actual issue:\r\n\r\n[ 66.575408s] [pid:5118,cpu4,QThread,4]Kernel panic - not syncing: stack-protector:\nKernel stack is corrupted in: do_hardware_base_addr+0xcc/0xd0 [parport]\n[ 66.575408s] [pid:5118,cpu4,QThread,5]CPU: 4 PID: 5118 Comm:\nQThread Tainted: G S W O 5.10.97-arm64-desktop #7100.57021.2\n[ 66.575439s] [pid:5118,cpu4,QThread,6]TGID: 5087 Comm: EFileApp\n[ 66.575439s] [pid:5118,cpu4,QThread,7]Hardware name: HUAWEI HUAWEI QingYun\nPGUX-W515x-B081/SP1PANGUXM, BIOS 1.00.07 04/29/2024\n[ 66.575439s] [pid:5118,cpu4,QThread,8]Call trace:\n[ 66.575469s] [pid:5118,cpu4,QThread,9] dump_backtrace+0x0/0x1c0\n[ 66.575469s] [pid:5118,cpu4,QThread,0] show_stack+0x14/0x20\n[ 66.575469s] [pid:5118,cpu4,QThread,1] dump_stack+0xd4/0x10c\n[ 66.575500s] [pid:5118,cpu4,QThread,2] panic+0x1d8/0x3bc\n[ 66.575500s] [pid:5118,cpu4,QThread,3] __stack_chk_fail+0x2c/0x38\n[ 66.575500s] [pid:5118,cpu4,QThread,4] do_hardware_base_addr+0xcc/0xd0 [parport](CVE-2024-42301)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: virt_wifi: avoid reporting connection success with wrong SSID\r\n\r\nWhen user issues a connection with a different SSID than the one\nvirt_wifi has advertised, the __cfg80211_connect_result() will\ntrigger the warning: WARN_ON(bss_not_found).\r\n\r\nThe issue is because the connection code in virt_wifi does not\ncheck the SSID from user space (it only checks the BSSID), and\nvirt_wifi will call cfg80211_connect_result() with WLAN_STATUS_SUCCESS\neven if the SSID is different from the one virt_wifi has advertised.\nEventually cfg80211 won\u0026apos;t be able to find the cfg80211_bss and generate\nthe warning.\r\n\r\nFixed it by checking the SSID (from user space) in the connection code.(CVE-2024-43841)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\njfs: Fix array-index-out-of-bounds in diFree(CVE-2024-43858)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/nouveau: prime: fix refcount underflow\r\n\r\nCalling nouveau_bo_ref() on a nouveau_bo without initializing it (and\nhence the backing ttm_bo) leads to a refcount underflow.\r\n\r\nInstead of calling nouveau_bo_ref() in the unwind path of\ndrm_gem_object_init(), clean things up manually.\r\n\r\n(cherry picked from commit 1b93f3e89d03cfc576636e195466a0d728ad8de5)(CVE-2024-43867)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndevres: Fix memory leakage caused by driver API devm_free_percpu()\r\n\r\nIt will cause memory leakage when use driver API devm_free_percpu()\nto free memory allocated by devm_alloc_percpu(), fixed by using\ndevres_release() instead of devres_destroy() within devm_free_percpu().(CVE-2024-43871)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/client: fix null pointer dereference in drm_client_modeset_probe\r\n\r\nIn drm_client_modeset_probe(), the return value of drm_mode_duplicate() is\nassigned to modeset-\u0026gt;mode, which will lead to a possible NULL pointer\ndereference on failure of drm_mode_duplicate(). Add a check to avoid npd.(CVE-2024-43894)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: dwc3: core: Prevent USB core invalid event buffer address access\r\n\r\nThis commit addresses an issue where the USB core could access an\ninvalid event buffer address during runtime suspend, potentially causing\nSMMU faults and other memory issues in Exynos platforms. The problem\narises from the following sequence.\n 1. In dwc3_gadget_suspend, there is a chance of a timeout when\n moving the USB core to the halt state after clearing the\n run/stop bit by software.\n 2. In dwc3_core_exit, the event buffer is cleared regardless of\n the USB core\u0026apos;s status, which may lead to an SMMU faults and\n other memory issues. if the USB core tries to access the event\n buffer address.\r\n\r\nTo prevent this hardware quirk on Exynos platforms, this commit ensures\nthat the event buffer address is not cleared by software when the USB\ncore is active during runtime suspend by checking its status before\nclearing the buffer address.(CVE-2024-46675)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsoc: qcom: cmd-db: Map shared memory as WC, not WB\r\n\r\nLinux does not write into cmd-db region. This region of memory is write\nprotected by XPU. XPU may sometime falsely detect clean cache eviction\nas \u0026quot;write\u0026quot; into the write protected region leading to secure interrupt\nwhich causes an endless loop somewhere in Trust Zone.\r\n\r\nThe only reason it is working right now is because Qualcomm Hypervisor\nmaps the same region as Non-Cacheable memory in Stage 2 translation\ntables. The issue manifests if we want to use another hypervisor (like\nXen or KVM), which does not know anything about those specific mappings.\r\n\r\nChanging the mapping of cmd-db memory from MEMREMAP_WB to MEMREMAP_WT/WC\nremoves dependency on correct mappings in Stage 2 tables. This patch\nfixes the issue by updating the mapping to MEMREMAP_WC.\r\n\r\nI tested this on SA8155P with Xen.(CVE-2024-46689)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: fix mc_data out-of-bounds read warning\r\n\r\nClear warning that read mc_data[i-1] may out-of-bounds.(CVE-2024-46722)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: Fix out-of-bounds read of df_v1_7_channel_number\r\n\r\nCheck the fb_channel_number range to avoid the array out-of-bounds\nread error(CVE-2024-46724)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nhwmon: (nct6775-core) Fix underflows seen when writing limit attributes\r\n\r\nDIV_ROUND_CLOSEST() after kstrtol() results in an underflow if a large\nnegative number such as -9223372036854775808 is provided by the user.\nFix it by reordering clamp_val() and DIV_ROUND_CLOSEST() operations.(CVE-2024-46757)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: added NULL check at start of dc_validate_stream\r\n\r\n[Why]\nprevent invalid memory access\r\n\r\n[How]\ncheck if dc and stream are NULL(CVE-2024-46802)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nKVM: x86: Acquire kvm-\u0026gt;srcu when handling KVM_SET_VCPU_EVENTS\r\n\r\nGrab kvm-\u0026gt;srcu when processing KVM_SET_VCPU_EVENTS, as KVM will forcibly\nleave nested VMX/SVM if SMM mode is being toggled, and leaving nested VMX\nreads guest memory.\r\n\r\nNote, kvm_vcpu_ioctl_x86_set_vcpu_events() can also be called from KVM_RUN\nvia sync_regs(), which already holds SRCU. I.e. trying to precisely use\nkvm_vcpu_srcu_read_lock() around the problematic SMM code would cause\nproblems. Acquiring SRCU isn\u0026apos;t all that expensive, so for simplicity,\ngrab it unconditionally for KVM_SET_VCPU_EVENTS.\r\n\r\n =============================\n WARNING: suspicious RCU usage\n 6.10.0-rc7-332d2c1d713e-next-vm #552 Not tainted\n -----------------------------\n include/linux/kvm_host.h:1027 suspicious rcu_dereference_check() usage!\r\n\r\n other info that might help us debug this:\r\n\r\n rcu_scheduler_active = 2, debug_locks = 1\n 1 lock held by repro/1071:\n #0: ffff88811e424430 (\u0026amp;vcpu-\u0026gt;mutex){+.+.}-{3:3}, at: kvm_vcpu_ioctl+0x7d/0x970 [kvm]\r\n\r\n stack backtrace:\n CPU: 15 PID: 1071 Comm: repro Not tainted 6.10.0-rc7-332d2c1d713e-next-vm #552\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015\n Call Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x7f/0x90\n lockdep_rcu_suspicious+0x13f/0x1a0\n kvm_vcpu_gfn_to_memslot+0x168/0x190 [kvm]\n kvm_vcpu_read_guest+0x3e/0x90 [kvm]\n nested_vmx_load_msr+0x6b/0x1d0 [kvm_intel]\n load_vmcs12_host_state+0x432/0xb40 [kvm_intel]\n vmx_leave_nested+0x30/0x40 [kvm_intel]\n kvm_vcpu_ioctl_x86_set_vcpu_events+0x15d/0x2b0 [kvm]\n kvm_arch_vcpu_ioctl+0x1107/0x1750 [kvm]\n ? mark_held_locks+0x49/0x70\n ? kvm_vcpu_ioctl+0x7d/0x970 [kvm]\n ? kvm_vcpu_ioctl+0x497/0x970 [kvm]\n kvm_vcpu_ioctl+0x497/0x970 [kvm]\n ? lock_acquire+0xba/0x2d0\n ? find_held_lock+0x2b/0x80\n ? do_user_addr_fault+0x40c/0x6f0\n ? lock_release+0xb7/0x270\n __x64_sys_ioctl+0x82/0xb0\n do_syscall_64+0x6c/0x170\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n RIP: 0033:0x7ff11eb1b539\n \u0026lt;/TASK\u0026gt;(CVE-2024-46830)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nspi: nxp-fspi: fix the KASAN report out-of-bounds bug\r\n\r\nChange the memcpy length to fix the out-of-bounds issue when writing the\ndata that is not 4 byte aligned to TX FIFO.\r\n\r\nTo reproduce the issue, write 3 bytes data to NOR chip.\r\n\r\ndd if=3b of=/dev/mtd0\n[ 36.926103] ==================================================================\n[ 36.933409] BUG: KASAN: slab-out-of-bounds in nxp_fspi_exec_op+0x26ec/0x2838\n[ 36.940514] Read of size 4 at addr ffff00081037c2a0 by task dd/455\n[ 36.946721]\n[ 36.948235] CPU: 3 UID: 0 PID: 455 Comm: dd Not tainted 6.11.0-rc5-gc7b0e37c8434 #1070\n[ 36.956185] Hardware name: Freescale i.MX8QM MEK (DT)\n[ 36.961260] Call trace:\n[ 36.963723] dump_backtrace+0x90/0xe8\n[ 36.967414] show_stack+0x18/0x24\n[ 36.970749] dump_stack_lvl+0x78/0x90\n[ 36.974451] print_report+0x114/0x5cc\n[ 36.978151] kasan_report+0xa4/0xf0\n[ 36.981670] __asan_report_load_n_noabort+0x1c/0x28\n[ 36.986587] nxp_fspi_exec_op+0x26ec/0x2838\n[ 36.990800] spi_mem_exec_op+0x8ec/0xd30\n[ 36.994762] spi_mem_no_dirmap_read+0x190/0x1e0\n[ 36.999323] spi_mem_dirmap_write+0x238/0x32c\n[ 37.003710] spi_nor_write_data+0x220/0x374\n[ 37.007932] spi_nor_write+0x110/0x2e8\n[ 37.011711] mtd_write_oob_std+0x154/0x1f0\n[ 37.015838] mtd_write_oob+0x104/0x1d0\n[ 37.019617] mtd_write+0xb8/0x12c\n[ 37.022953] mtdchar_write+0x224/0x47c\n[ 37.026732] vfs_write+0x1e4/0x8c8\n[ 37.030163] ksys_write+0xec/0x1d0\n[ 37.033586] __arm64_sys_write+0x6c/0x9c\n[ 37.037539] invoke_syscall+0x6c/0x258\n[ 37.041327] el0_svc_common.constprop.0+0x160/0x22c\n[ 37.046244] do_el0_svc+0x44/0x5c\n[ 37.049589] el0_svc+0x38/0x78\n[ 37.052681] el0t_64_sync_handler+0x13c/0x158\n[ 37.057077] el0t_64_sync+0x190/0x194\n[ 37.060775]\n[ 37.062274] Allocated by task 455:\n[ 37.065701] kasan_save_stack+0x2c/0x54\n[ 37.069570] kasan_save_track+0x20/0x3c\n[ 37.073438] kasan_save_alloc_info+0x40/0x54\n[ 37.077736] __kasan_kmalloc+0xa0/0xb8\n[ 37.081515] __kmalloc_noprof+0x158/0x2f8\n[ 37.085563] mtd_kmalloc_up_to+0x120/0x154\n[ 37.089690] mtdchar_write+0x130/0x47c\n[ 37.093469] vfs_write+0x1e4/0x8c8\n[ 37.096901] ksys_write+0xec/0x1d0\n[ 37.100332] __arm64_sys_write+0x6c/0x9c\n[ 37.104287] invoke_syscall+0x6c/0x258\n[ 37.108064] el0_svc_common.constprop.0+0x160/0x22c\n[ 37.112972] do_el0_svc+0x44/0x5c\n[ 37.116319] el0_svc+0x38/0x78\n[ 37.119401] el0t_64_sync_handler+0x13c/0x158\n[ 37.123788] el0t_64_sync+0x190/0x194\n[ 37.127474]\n[ 37.128977] The buggy address belongs to the object at ffff00081037c2a0\n[ 37.128977] which belongs to the cache kmalloc-8 of size 8\n[ 37.141177] The buggy address is located 0 bytes inside of\n[ 37.141177] allocated 3-byte region [ffff00081037c2a0, ffff00081037c2a3)\n[ 37.153465]\n[ 37.154971] The buggy address belongs to the physical page:\n[ 37.160559] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x89037c\n[ 37.168596] flags: 0xbfffe0000000000(node=0|zone=2|lastcpupid=0x1ffff)\n[ 37.175149] page_type: 0xfdffffff(slab)\n[ 37.179021] raw: 0bfffe0000000000 ffff000800002500 dead000000000122 0000000000000000\n[ 37.186788] raw: 0000000000000000 0000000080800080 00000001fdffffff 0000000000000000\n[ 37.194553] page dumped because: kasan: bad access detected\n[ 37.200144]\n[ 37.201647] Memory state around the buggy address:\n[ 37.206460] ffff00081037c180: fa fc fc fc fa fc fc fc fa fc fc fc fa fc fc fc\n[ 37.213701] ffff00081037c200: fa fc fc fc 05 fc fc fc 03 fc fc fc 02 fc fc fc\n[ 37.220946] \u0026gt;ffff00081037c280: 06 fc fc fc 03 fc fc fc fc fc fc fc fc fc fc fc\n[ 37.228186] ^\n[ 37.232473] ffff00081037c300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc\n[ 37.239718] ffff00081037c380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc\n[ 37.246962] ==============================================================\n---truncated---(CVE-2024-46853)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nPCI: keystone: Add workaround for Errata #i2037 (AM65x SR 1.0)\r\n\r\nErrata #i2037 in AM65x/DRA80xM Processors Silicon Revision 1.0\n(SPRZ452D_July 2018_Revised December 2019 [1]) mentions when an\ninbound PCIe TLP spans more than two internal AXI 128-byte bursts,\nthe bus may corrupt the packet payload and the corrupt data may\ncause associated applications or the processor to hang.\r\n\r\nThe workaround for Errata #i2037 is to limit the maximum read\nrequest size and maximum payload size to 128 bytes. Add workaround\nfor Errata #i2037 here.\r\n\r\nThe errata and workaround is applicable only to AM65x SR 1.0 and\nlater versions of the silicon will have this fixed.\r\n\r\n[1] -\u0026gt; https://www.ti.com/lit/er/sprz452i/sprz452i.pdf(CVE-2024-47667)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: fix state management in error path of log writing function\r\n\r\nAfter commit a694291a6211 (\u0026quot;nilfs2: separate wait function from\nnilfs_segctor_write\u0026quot;) was applied, the log writing function\nnilfs_segctor_do_construct() was able to issue I/O requests continuously\neven if user data blocks were split into multiple logs across segments,\nbut two potential flaws were introduced in its error handling.\r\n\r\nFirst, if nilfs_segctor_begin_construction() fails while creating the\nsecond or subsequent logs, the log writing function returns without\ncalling nilfs_segctor_abort_construction(), so the writeback flag set on\npages/folios will remain uncleared. This causes page cache operations to\nhang waiting for the writeback flag. For example,\ntruncate_inode_pages_final(), which is called via nilfs_evict_inode() when\nan inode is evicted from memory, will hang.\r\n\r\nSecond, the NILFS_I_COLLECTED flag set on normal inodes remain uncleared. \nAs a result, if the next log write involves checkpoint creation, that\u0026apos;s\nfine, but if a partial log write is performed that does not, inodes with\nNILFS_I_COLLECTED set are erroneously removed from the \u0026quot;sc_dirty_files\u0026quot;\nlist, and their data and b-tree blocks may not be written to the device,\ncorrupting the block mapping.\r\n\r\nFix these issues by uniformly calling nilfs_segctor_abort_construction()\non failure of each step in the loop in nilfs_segctor_do_construct(),\nhaving it clean up logs and segment usages according to progress, and\ncorrecting the conditions for calling nilfs_redirty_inodes() to ensure\nthat the NILFS_I_COLLECTED flag is cleared.(CVE-2024-47669)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: tcp: check skb is non-NULL in tcp_rto_delta_us() We have some machines running stock Ubuntu 20.04.6 which is their 5.4.0-174-generic kernel that are running ceph and recently hit a null ptr dereference in tcp_rearm_rto(). Initially hitting it from the TLP path, but then later we also saw it getting hit from the RACK case as well. Here are examples of the oops messages we saw in each of those cases: Jul 26 15:05:02 rx [11061395.780353] BUG: kernel NULL pointer dereference, address: 0000000000000020 Jul 26 15:05:02 rx [11061395.787572] #PF: supervisor read access in kernel mode Jul 26 15:05:02 rx [11061395.792971] #PF: error_code(0x0000) - not-present page Jul 26 15:05:02 rx [11061395.798362] PGD 0 P4D 0 Jul 26 15:05:02 rx [11061395.801164] Oops: 0000 [#1] SMP NOPTI Jul 26 15:05:02 rx [11061395.805091] CPU: 0 PID: 9180 Comm: msgr-worker-1 Tainted: G W 5.4.0-174-generic #193-Ubuntu Jul 26 15:05:02 rx [11061395.814996] Hardware name: Supermicro SMC 2x26 os-gen8 64C NVME-Y 256G/H12SSW-NTR, BIOS 2.5.V1.2U.NVMe.UEFI 05/09/2023 Jul 26 15:05:02 rx [11061395.825952] RIP: 0010:tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.830656] Code: 87 ca 04 00 00 00 5b 41 5c 41 5d 5d c3 c3 49 8b bc 24 40 06 00 00 eb 8d 48 bb cf f7 53 e3 a5 9b c4 20 4c 89 ef e8 0c fe 0e 00 \u0026lt;48\u0026gt; 8b 78 20 48 c1 ef 03 48 89 f8 41 8b bc 24 80 04 00 00 48 f7 e3 Jul 26 15:05:02 rx [11061395.849665] RSP: 0018:ffffb75d40003e08 EFLAGS: 00010246 Jul 26 15:05:02 rx [11061395.855149] RAX: 0000000000000000 RBX: 20c49ba5e353f7cf RCX: 0000000000000000 Jul 26 15:05:02 rx [11061395.862542] RDX: 0000000062177c30 RSI: 000000000000231c RDI: ffff9874ad283a60 Jul 26 15:05:02 rx [11061395.869933] RBP: ffffb75d40003e20 R08: 0000000000000000 R09: ffff987605e20aa8 Jul 26 15:05:02 rx [11061395.877318] R10: ffffb75d40003f00 R11: ffffb75d4460f740 R12: ffff9874ad283900 Jul 26 15:05:02 rx [11061395.884710] R13: ffff9874ad283a60 R14: ffff9874ad283980 R15: ffff9874ad283d30 Jul 26 15:05:02 rx [11061395.892095] FS: 00007f1ef4a2e700(0000) GS:ffff987605e00000(0000) knlGS:0000000000000000 Jul 26 15:05:02 rx [11061395.900438] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Jul 26 15:05:02 rx [11061395.906435] CR2: 0000000000000020 CR3: 0000003e450ba003 CR4: 0000000000760ef0 Jul 26 15:05:02 rx [11061395.913822] PKRU: 55555554 Jul 26 15:05:02 rx [11061395.916786] Call Trace: Jul 26 15:05:02 rx [11061395.919488] Jul 26 15:05:02 rx [11061395.921765] ? show_regs.cold+0x1a/0x1f Jul 26 15:05:02 rx [11061395.925859] ? __die+0x90/0xd9 Jul 26 15:05:02 rx [11061395.929169] ? no_context+0x196/0x380 Jul 26 15:05:02 rx [11061395.933088] ? ip6_protocol_deliver_rcu+0x4e0/0x4e0 Jul 26 15:05:02 rx [11061395.938216] ? ip6_sublist_rcv_finish+0x3d/0x50 Jul 26 15:05:02 rx [11061395.943000] ? __bad_area_nosemaphore+0x50/0x1a0 Jul 26 15:05:02 rx [11061395.947873] ? bad_area_nosemaphore+0x16/0x20 Jul 26 15:05:02 rx [11061395.952486] ? do_user_addr_fault+0x267/0x450 Jul 26 15:05:02 rx [11061395.957104] ? ipv6_list_rcv+0x112/0x140 Jul 26 15:05:02 rx [11061395.961279] ? __do_page_fault+0x58/0x90 Jul 26 15:05:02 rx [11061395.965458] ? do_page_fault+0x2c/0xe0 Jul 26 15:05:02 rx [11061395.969465] ? page_fault+0x34/0x40 Jul 26 15:05:02 rx [11061395.973217] ? tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.977313] ? tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.981408] tcp_send_loss_probe+0x10b/0x220 Jul 26 15:05:02 rx [11061395.985937] tcp_write_timer_handler+0x1b4/0x240 Jul 26 15:05:02 rx [11061395.990809] tcp_write_timer+0x9e/0xe0 Jul 26 15:05:02 rx [11061395.994814] ? tcp_write_timer_handler+0x240/0x240 Jul 26 15:05:02 rx [11061395.999866] call_timer_fn+0x32/0x130 Jul 26 15:05:02 rx [11061396.003782] __run_timers.part.0+0x180/0x280 Jul 26 15:05:02 rx [11061396.008309] ? recalibrate_cpu_khz+0x10/0x10 Jul 26 15:05:02 rx [11061396.012841] ? native_x2apic_icr_write+0x30/0x30 Jul 26 15:05:02 rx [11061396.017718] ? lapic_next_even ---truncated---(CVE-2024-47684)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: netfilter: nf_reject_ipv6: fix nf_reject_ip6_tcphdr_put() syzbot reported that nf_reject_ip6_tcphdr_put() was possibly sending garbage on the four reserved tcp bits (th-\u0026gt;res1) Use skb_put_zero() to clear the whole TCP header, as done in nf_reject_ip_tcphdr_put() BUG: KMSAN: uninit-value in nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255 nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255 nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344 nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core net/core/dev.c:5661 [inline] __netif_receive_skb+0x1da/0xa00 net/core/dev.c:5775 process_backlog+0x4ad/0xa50 net/core/dev.c:6108 __napi_poll+0xe7/0x980 net/core/dev.c:6772 napi_poll net/core/dev.c:6841 [inline] net_rx_action+0xa5a/0x19b0 net/core/dev.c:6963 handle_softirqs+0x1ce/0x800 kernel/softirq.c:554 __do_softirq+0x14/0x1a kernel/softirq.c:588 do_softirq+0x9a/0x100 kernel/softirq.c:455 __local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:382 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:908 [inline] __dev_queue_xmit+0x2692/0x5610 net/core/dev.c:4450 dev_queue_xmit include/linux/netdevice.h:3105 [inline] neigh_resolve_output+0x9ca/0xae0 net/core/neighbour.c:1565 neigh_output include/net/neighbour.h:542 [inline] ip6_finish_output2+0x2347/0x2ba0 net/ipv6/ip6_output.c:141 __ip6_finish_output net/ipv6/ip6_output.c:215 [inline] ip6_finish_output+0xbb8/0x14b0 net/ipv6/ip6_output.c:226 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip6_output+0x356/0x620 net/ipv6/ip6_output.c:247 dst_output include/net/dst.h:450 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] ip6_xmit+0x1ba6/0x25d0 net/ipv6/ip6_output.c:366 inet6_csk_xmit+0x442/0x530 net/ipv6/inet6_connection_sock.c:135 __tcp_transmit_skb+0x3b07/0x4880 net/ipv4/tcp_output.c:1466 tcp_transmit_skb net/ipv4/tcp_output.c:1484 [inline] tcp_connect+0x35b6/0x7130 net/ipv4/tcp_output.c:4143 tcp_v6_connect+0x1bcc/0x1e40 net/ipv6/tcp_ipv6.c:333 __inet_stream_connect+0x2ef/0x1730 net/ipv4/af_inet.c:679 inet_stream_connect+0x6a/0xd0 net/ipv4/af_inet.c:750 __sys_connect_file net/socket.c:2061 [inline] __sys_connect+0x606/0x690 net/socket.c:2078 __do_sys_connect net/socket.c:2088 [inline] __se_sys_connect net/socket.c:2085 [inline] __x64_sys_connect+0x91/0xe0 net/socket.c:2085 x64_sys_call+0x27a5/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:43 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit was stored to memory at: nf_reject_ip6_tcphdr_put+0x60c/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:249 nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344 nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core ---truncated---(CVE-2024-47685)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: RDMA/rtrs-clt: Reset cid to con_num - 1 to stay in bounds In the function init_conns(), after the create_con() and create_cm() for loop if something fails. In the cleanup for loop after the destroy tag, we access out of bound memory because cid is set to clt_path-\u0026gt;s.con_num. This commits resets the cid to clt_path-\u0026gt;s.con_num - 1, to stay in bounds in the cleanup loop later.(CVE-2024-47695)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: drivers: media: dvb-frontends/rtl2832: fix an out-of-bounds write error Ensure index in rtl2832_pid_filter does not exceed 31 to prevent out-of-bounds access. dev-\u0026gt;filters is a 32-bit value, so set_bit and clear_bit functions should only operate on indices from 0 to 31. If index is 32, it will attempt to access a non-existent 33rd bit, leading to out-of-bounds access. Change the boundary check from index \u0026gt; 32 to index \u0026gt;= 32 to resolve this issue. [hverkuil: added fixes tag, rtl2830_pid_filter -\u0026gt; rtl2832_pid_filter in logmsg](CVE-2024-47698)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: can: bcm: Clear bo-\u0026gt;bcm_proc_read after remove_proc_entry(). syzbot reported a warning in bcm_release(). [0] The blamed change fixed another warning that is triggered when connect() is issued again for a socket whose connect()ed device has been unregistered. However, if the socket is just close()d without the 2nd connect(), the remaining bo-\u0026gt;bcm_proc_read triggers unnecessary remove_proc_entry() in bcm_release(). Let\u0026apos;s clear bo-\u0026gt;bcm_proc_read after remove_proc_entry() in bcm_notify(). [0] name \u0026apos;4986\u0026apos; WARNING: CPU: 0 PID: 5234 at fs/proc/generic.c:711 remove_proc_entry+0x2e7/0x5d0 fs/proc/generic.c:711 Modules linked in: CPU: 0 UID: 0 PID: 5234 Comm: syz-executor606 Not tainted 6.11.0-rc5-syzkaller-00178-g5517ae241919 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:remove_proc_entry+0x2e7/0x5d0 fs/proc/generic.c:711 Code: ff eb 05 e8 cb 1e 5e ff 48 8b 5c 24 10 48 c7 c7 e0 f7 aa 8e e8 2a 38 8e 09 90 48 c7 c7 60 3a 1b 8c 48 89 de e8 da 42 20 ff 90 \u0026lt;0f\u0026gt; 0b 90 90 48 8b 44 24 18 48 c7 44 24 40 0e 36 e0 45 49 c7 04 07 RSP: 0018:ffffc9000345fa20 EFLAGS: 00010246 RAX: 2a2d0aee2eb64600 RBX: ffff888032f1f548 RCX: ffff888029431e00 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffc9000345fb08 R08: ffffffff8155b2f2 R09: 1ffff1101710519a R10: dffffc0000000000 R11: ffffed101710519b R12: ffff888011d38640 R13: 0000000000000004 R14: 0000000000000000 R15: dffffc0000000000 FS: 0000000000000000(0000) GS:ffff8880b8800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fcfb52722f0 CR3: 000000000e734000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: \u0026lt;TASK\u0026gt; bcm_release+0x250/0x880 net/can/bcm.c:1578 __sock_release net/socket.c:659 [inline] sock_close+0xbc/0x240 net/socket.c:1421 __fput+0x24a/0x8a0 fs/file_table.c:422 task_work_run+0x24f/0x310 kernel/task_work.c:228 exit_task_work include/linux/task_work.h:40 [inline] do_exit+0xa2f/0x27f0 kernel/exit.c:882 do_group_exit+0x207/0x2c0 kernel/exit.c:1031 __do_sys_exit_group kernel/exit.c:1042 [inline] __se_sys_exit_group kernel/exit.c:1040 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1040 x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232 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:0x7fcfb51ee969 Code: Unable to access opcode bytes at 0x7fcfb51ee93f. RSP: 002b:00007ffce0109ca8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007fcfb51ee969 RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000001 RBP: 00007fcfb526f3b0 R08: ffffffffffffffb8 R09: 0000555500000000 R10: 0000555500000000 R11: 0000000000000246 R12: 00007fcfb526f3b0 R13: 0000000000000000 R14: 00007fcfb5271ee0 R15: 00007fcfb51bf160 \u0026lt;/TASK\u0026gt;(CVE-2024-47709)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: sock_map: Add a cond_resched() in sock_hash_free() Several syzbot soft lockup reports all have in common sock_hash_free() If a map with a large number of buckets is destroyed, we need to yield the cpu when needed.(CVE-2024-47710)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for set_output_gamma in dcn30_set_output_transfer_func This commit adds a null check for the set_output_gamma function pointer in the dcn30_set_output_transfer_func function. Previously, set_output_gamma was being checked for nullity at line 386, but then it was being dereferenced without any nullity check at line 401. This could potentially lead to a null pointer dereference error if set_output_gamma is indeed null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a nullity check for set_output_gamma before the call to set_output_gamma at line 401. If set_output_gamma is null, we log an error message and do not call the function. This fix prevents a potential null pointer dereference error. drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:401 dcn30_set_output_transfer_func() error: we previously assumed \u0026apos;mpc-\u0026gt;funcs-\u0026gt;set_output_gamma\u0026apos; could be null (see line 386) drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c 373 bool dcn30_set_output_transfer_func(struct dc *dc, 374 struct pipe_ctx *pipe_ctx, 375 const struct dc_stream_state *stream) 376 { 377 int mpcc_id = pipe_ctx-\u0026gt;plane_res.hubp-\u0026gt;inst; 378 struct mpc *mpc = pipe_ctx-\u0026gt;stream_res.opp-\u0026gt;ctx-\u0026gt;dc-\u0026gt;res_pool-\u0026gt;mpc; 379 const struct pwl_params *params = NULL; 380 bool ret = false; 381 382 /* program OGAM or 3DLUT only for the top pipe*/ 383 if (pipe_ctx-\u0026gt;top_pipe == NULL) { 384 /*program rmu shaper and 3dlut in MPC*/ 385 ret = dcn30_set_mpc_shaper_3dlut(pipe_ctx, stream); 386 if (ret == false \u0026amp;\u0026amp; mpc-\u0026gt;funcs-\u0026gt;set_output_gamma) { ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ If this is NULL 387 if (stream-\u0026gt;out_transfer_func.type == TF_TYPE_HWPWL) 388 params = \u0026amp;stream-\u0026gt;out_transfer_func.pwl; 389 else if (pipe_ctx-\u0026gt;stream-\u0026gt;out_transfer_func.type == 390 TF_TYPE_DISTRIBUTED_POINTS \u0026amp;\u0026amp; 391 cm3_helper_translate_curve_to_hw_format( 392 \u0026amp;stream-\u0026gt;out_transfer_func, 393 \u0026amp;mpc-\u0026gt;blender_params, false)) 394 params = \u0026amp;mpc-\u0026gt;blender_params; 395 /* there are no ROM LUTs in OUTGAM */ 396 if (stream-\u0026gt;out_transfer_func.type == TF_TYPE_PREDEFINED) 397 BREAK_TO_DEBUGGER(); 398 } 399 } 400 --\u0026gt; 401 mpc-\u0026gt;funcs-\u0026gt;set_output_gamma(mpc, mpcc_id, params); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Then it will crash 402 return ret; 403 }(CVE-2024-47720)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: nfsd: call cache_put if xdr_reserve_space returns NULL If not enough buffer space available, but idmap_lookup has triggered lookup_fn which calls cache_get and returns successfully. Then we missed to call cache_put here which pairs with cache_get. Reviwed-by: Jeff Layton \u0026lt;jlayton@kernel.org\u0026gt;(CVE-2024-47737)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential oob read in nilfs_btree_check_delete() The function nilfs_btree_check_delete(), which checks whether degeneration to direct mapping occurs before deleting a b-tree entry, causes memory access outside the block buffer when retrieving the maximum key if the root node has no entries. This does not usually happen because b-tree mappings with 0 child nodes are never created by mkfs.nilfs2 or nilfs2 itself. However, it can happen if the b-tree root node read from a device is configured that way, so fix this potential issue by adding a check for that case.(CVE-2024-47757)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: tracing/timerlat: Fix a race during cpuhp processing There is another found exception that the \u0026quot;timerlat/1\u0026quot; thread was scheduled on CPU0, and lead to timer corruption finally: ``` ODEBUG: init active (active state 0) object: ffff888237c2e108 object type: hrtimer hint: timerlat_irq+0x0/0x220 WARNING: CPU: 0 PID: 426 at lib/debugobjects.c:518 debug_print_object+0x7d/0xb0 Modules linked in: CPU: 0 UID: 0 PID: 426 Comm: timerlat/1 Not tainted 6.11.0-rc7+ #45 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:debug_print_object+0x7d/0xb0 ... Call Trace: \u0026lt;TASK\u0026gt; ? __warn+0x7c/0x110 ? debug_print_object+0x7d/0xb0 ? report_bug+0xf1/0x1d0 ? prb_read_valid+0x17/0x20 ? handle_bug+0x3f/0x70 ? exc_invalid_op+0x13/0x60 ? asm_exc_invalid_op+0x16/0x20 ? debug_print_object+0x7d/0xb0 ? debug_print_object+0x7d/0xb0 ? __pfx_timerlat_irq+0x10/0x10 __debug_object_init+0x110/0x150 hrtimer_init+0x1d/0x60 timerlat_main+0xab/0x2d0 ? __pfx_timerlat_main+0x10/0x10 kthread+0xb7/0xe0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 \u0026lt;/TASK\u0026gt; ``` After tracing the scheduling event, it was discovered that the migration of the \u0026quot;timerlat/1\u0026quot; thread was performed during thread creation. Further analysis confirmed that it is because the CPU online processing for osnoise is implemented through workers, which is asynchronous with the offline processing. When the worker was scheduled to create a thread, the CPU may has already been removed from the cpu_online_mask during the offline process, resulting in the inability to select the right CPU: T1 | T2 [CPUHP_ONLINE] | cpu_device_down() osnoise_hotplug_workfn() | | cpus_write_lock() | takedown_cpu(1) | cpus_write_unlock() [CPUHP_OFFLINE] | cpus_read_lock() | start_kthread(1) | cpus_read_unlock() | To fix this, skip online processing if the CPU is already offline.(CVE-2024-49866)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: btrfs: wait for fixup workers before stopping cleaner kthread during umount During unmount, at close_ctree(), we have the following steps in this order: 1) Park the cleaner kthread - this doesn\u0026apos;t destroy the kthread, it basically halts its execution (wake ups against it work but do nothing); 2) We stop the cleaner kthread - this results in freeing the respective struct task_struct; 3) We call btrfs_stop_all_workers() which waits for any jobs running in all the work queues and then free the work queues. Syzbot reported a case where a fixup worker resulted in a crash when doing a delayed iput on its inode while attempting to wake up the cleaner at btrfs_add_delayed_iput(), because the task_struct of the cleaner kthread was already freed. This can happen during unmount because we don\u0026apos;t wait for any fixup workers still running before we call kthread_stop() against the cleaner kthread, which stops and free all its resources. Fix this by waiting for any fixup workers at close_ctree() before we call kthread_stop() against the cleaner and run pending delayed iputs. The stack traces reported by syzbot were the following: BUG: KASAN: slab-use-after-free in __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065 Read of size 8 at addr ffff8880272a8a18 by task kworker/u8:3/52 CPU: 1 UID: 0 PID: 52 Comm: kworker/u8:3 Not tainted 6.12.0-rc1-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Workqueue: btrfs-fixup btrfs_work_helper Call Trace: \u0026lt;TASK\u0026gt; __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0xd5/0x120 kernel/locking/spinlock.c:162 class_raw_spinlock_irqsave_constructor include/linux/spinlock.h:551 [inline] try_to_wake_up+0xb0/0x1480 kernel/sched/core.c:4154 btrfs_writepage_fixup_worker+0xc16/0xdf0 fs/btrfs/inode.c:2842 btrfs_work_helper+0x390/0xc50 fs/btrfs/async-thread.c:314 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa63/0x1850 kernel/workqueue.c:3310 worker_thread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 \u0026lt;/TASK\u0026gt; Allocated by task 2: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:319 [inline] __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:345 kasan_slab_alloc include/linux/kasan.h:247 [inline] slab_post_alloc_hook mm/slub.c:4086 [inline] slab_alloc_node mm/slub.c:4135 [inline] kmem_cache_alloc_node_noprof+0x16b/0x320 mm/slub.c:4187 alloc_task_struct_node kernel/fork.c:180 [inline] dup_task_struct+0x57/0x8c0 kernel/fork.c:1107 copy_process+0x5d1/0x3d50 kernel/fork.c:2206 kernel_clone+0x223/0x880 kernel/fork.c:2787 kernel_thread+0x1bc/0x240 kernel/fork.c:2849 create_kthread kernel/kthread.c:412 [inline] kthreadd+0x60d/0x810 kernel/kthread.c:765 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Freed by task 61: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:230 [inline] slab_free_h ---truncated---(CVE-2024-49867)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: btrfs: fix a NULL pointer dereference when failed to start a new trasacntion [BUG] Syzbot reported a NULL pointer dereference with the following crash: FAULT_INJECTION: forcing a failure. start_transaction+0x830/0x1670 fs/btrfs/transaction.c:676 prepare_to_relocate+0x31f/0x4c0 fs/btrfs/relocation.c:3642 relocate_block_group+0x169/0xd20 fs/btrfs/relocation.c:3678 ... BTRFS info (device loop0): balance: ended with status: -12 Oops: general protection fault, probably for non-canonical address 0xdffffc00000000cc: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000660-0x0000000000000667] RIP: 0010:btrfs_update_reloc_root+0x362/0xa80 fs/btrfs/relocation.c:926 Call Trace: \u0026lt;TASK\u0026gt; commit_fs_roots+0x2ee/0x720 fs/btrfs/transaction.c:1496 btrfs_commit_transaction+0xfaf/0x3740 fs/btrfs/transaction.c:2430 del_balance_item fs/btrfs/volumes.c:3678 [inline] reset_balance_state+0x25e/0x3c0 fs/btrfs/volumes.c:3742 btrfs_balance+0xead/0x10c0 fs/btrfs/volumes.c:4574 btrfs_ioctl_balance+0x493/0x7c0 fs/btrfs/ioctl.c:3673 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893 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 [CAUSE] The allocation failure happens at the start_transaction() inside prepare_to_relocate(), and during the error handling we call unset_reloc_control(), which makes fs_info-\u0026gt;balance_ctl to be NULL. Then we continue the error path cleanup in btrfs_balance() by calling reset_balance_state() which will call del_balance_item() to fully delete the balance item in the root tree. However during the small window between set_reloc_contrl() and unset_reloc_control(), we can have a subvolume tree update and created a reloc_root for that subvolume. Then we go into the final btrfs_commit_transaction() of del_balance_item(), and into btrfs_update_reloc_root() inside commit_fs_roots(). That function checks if fs_info-\u0026gt;reloc_ctl is in the merge_reloc_tree stage, but since fs_info-\u0026gt;reloc_ctl is NULL, it results a NULL pointer dereference. [FIX] Just add extra check on fs_info-\u0026gt;reloc_ctl inside btrfs_update_reloc_root(), before checking fs_info-\u0026gt;reloc_ctl-\u0026gt;merge_reloc_tree. That DEAD_RELOC_TREE handling is to prevent further modification to the reloc tree during merge stage, but since there is no reloc_ctl at all, we do not need to bother that.(CVE-2024-49868)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: nfsd: map the EBADMSG to nfserr_io to avoid warning Ext4 will throw -EBADMSG through ext4_readdir when a checksum error occurs, resulting in the following WARNING. Fix it by mapping EBADMSG to nfserr_io. nfsd_buffered_readdir iterate_dir // -EBADMSG -74 ext4_readdir // .iterate_shared ext4_dx_readdir ext4_htree_fill_tree htree_dirblock_to_tree ext4_read_dirblock __ext4_read_dirblock ext4_dirblock_csum_verify warn_no_space_for_csum __warn_no_space_for_csum return ERR_PTR(-EFSBADCRC) // -EBADMSG -74 nfserrno // WARNING [ 161.115610] ------------[ cut here ]------------ [ 161.116465] nfsd: non-standard errno: -74 [ 161.117315] WARNING: CPU: 1 PID: 780 at fs/nfsd/nfsproc.c:878 nfserrno+0x9d/0xd0 [ 161.118596] Modules linked in: [ 161.119243] CPU: 1 PID: 780 Comm: nfsd Not tainted 5.10.0-00014-g79679361fd5d #138 [ 161.120684] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qe mu.org 04/01/2014 [ 161.123601] RIP: 0010:nfserrno+0x9d/0xd0 [ 161.124676] Code: 0f 87 da 30 dd 00 83 e3 01 b8 00 00 00 05 75 d7 44 89 ee 48 c7 c7 c0 57 24 98 89 44 24 04 c6 05 ce 2b 61 03 01 e8 99 20 d8 00 \u0026lt;0f\u0026gt; 0b 8b 44 24 04 eb b5 4c 89 e6 48 c7 c7 a0 6d a4 99 e8 cc 15 33 [ 161.127797] RSP: 0018:ffffc90000e2f9c0 EFLAGS: 00010286 [ 161.128794] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 161.130089] RDX: 1ffff1103ee16f6d RSI: 0000000000000008 RDI: fffff520001c5f2a [ 161.131379] RBP: 0000000000000022 R08: 0000000000000001 R09: ffff8881f70c1827 [ 161.132664] R10: ffffed103ee18304 R11: 0000000000000001 R12: 0000000000000021 [ 161.133949] R13: 00000000ffffffb6 R14: ffff8881317c0000 R15: ffffc90000e2fbd8 [ 161.135244] FS: 0000000000000000(0000) GS:ffff8881f7080000(0000) knlGS:0000000000000000 [ 161.136695] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 161.137761] CR2: 00007fcaad70b348 CR3: 0000000144256006 CR4: 0000000000770ee0 [ 161.139041] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 161.140291] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 161.141519] PKRU: 55555554 [ 161.142076] Call Trace: [ 161.142575] ? __warn+0x9b/0x140 [ 161.143229] ? nfserrno+0x9d/0xd0 [ 161.143872] ? report_bug+0x125/0x150 [ 161.144595] ? handle_bug+0x41/0x90 [ 161.145284] ? exc_invalid_op+0x14/0x70 [ 161.146009] ? asm_exc_invalid_op+0x12/0x20 [ 161.146816] ? nfserrno+0x9d/0xd0 [ 161.147487] nfsd_buffered_readdir+0x28b/0x2b0 [ 161.148333] ? nfsd4_encode_dirent_fattr+0x380/0x380 [ 161.149258] ? nfsd_buffered_filldir+0xf0/0xf0 [ 161.150093] ? wait_for_concurrent_writes+0x170/0x170 [ 161.151004] ? generic_file_llseek_size+0x48/0x160 [ 161.151895] nfsd_readdir+0x132/0x190 [ 161.152606] ? nfsd4_encode_dirent_fattr+0x380/0x380 [ 161.153516] ? nfsd_unlink+0x380/0x380 [ 161.154256] ? override_creds+0x45/0x60 [ 161.155006] nfsd4_encode_readdir+0x21a/0x3d0 [ 161.155850] ? nfsd4_encode_readlink+0x210/0x210 [ 161.156731] ? write_bytes_to_xdr_buf+0x97/0xe0 [ 161.157598] ? __write_bytes_to_xdr_buf+0xd0/0xd0 [ 161.158494] ? lock_downgrade+0x90/0x90 [ 161.159232] ? nfs4svc_decode_voidarg+0x10/0x10 [ 161.160092] nfsd4_encode_operation+0x15a/0x440 [ 161.160959] nfsd4_proc_compound+0x718/0xe90 [ 161.161818] nfsd_dispatch+0x18e/0x2c0 [ 161.162586] svc_process_common+0x786/0xc50 [ 161.163403] ? nfsd_svc+0x380/0x380 [ 161.164137] ? svc_printk+0x160/0x160 [ 161.164846] ? svc_xprt_do_enqueue.part.0+0x365/0x380 [ 161.165808] ? nfsd_svc+0x380/0x380 [ 161.166523] ? rcu_is_watching+0x23/0x40 [ 161.167309] svc_process+0x1a5/0x200 [ 161.168019] nfsd+0x1f5/0x380 [ 161.168663] ? nfsd_shutdown_threads+0x260/0x260 [ 161.169554] kthread+0x1c4/0x210 [ 161.170224] ? kthread_insert_work_sanity_check+0x80/0x80 [ 161.171246] ret_from_fork+0x1f/0x30(CVE-2024-49875)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in degamma hardware format translation Fixes index out of bounds issue in `cm_helper_translate_curve_to_degamma_hw_format` function. The issue could occur when the index \u0026apos;i\u0026apos; exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure \u0026apos;i\u0026apos; is within bounds before accessing the transfer function points. If \u0026apos;i\u0026apos; is out of bounds the function returns false to indicate an error. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:594 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.red\u0026apos; 1025 \u0026lt;= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:595 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.green\u0026apos; 1025 \u0026lt;= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:596 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.blue\u0026apos; 1025 \u0026lt;= s32max(CVE-2024-49894)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in DCN30 degamma hardware format translation This commit addresses a potential index out of bounds issue in the `cm3_helper_translate_curve_to_degamma_hw_format` function in the DCN30 color management module. The issue could occur when the index \u0026apos;i\u0026apos; exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure \u0026apos;i\u0026apos; is within bounds before accessing the transfer function points. If \u0026apos;i\u0026apos; is out of bounds, the function returns false to indicate an error. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:338 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.red\u0026apos; 1025 \u0026lt;= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:339 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.green\u0026apos; 1025 \u0026lt;= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:340 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.blue\u0026apos; 1025 \u0026lt;= s32max(CVE-2024-49895)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: jfs: Fix uninit-value access of new_ea in ea_buffer syzbot reports that lzo1x_1_do_compress is using uninit-value: ===================================================== BUG: KMSAN: uninit-value in lzo1x_1_do_compress+0x19f9/0x2510 lib/lzo/lzo1x_compress.c:178 ... Uninit was stored to memory at: ea_put fs/jfs/xattr.c:639 [inline] ... Local variable ea_buf created at: __jfs_setxattr+0x5d/0x1ae0 fs/jfs/xattr.c:662 __jfs_xattr_set+0xe6/0x1f0 fs/jfs/xattr.c:934 ===================================================== The reason is ea_buf-\u0026gt;new_ea is not initialized properly. Fix this by using memset to empty its content at the beginning in ea_get().(CVE-2024-49900)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: jfs: check if leafidx greater than num leaves per dmap tree syzbot report a out of bounds in dbSplit, it because dmt_leafidx greater than num leaves per dmap tree, add a checking for dmt_leafidx in dbFindLeaf. Shaggy: Modified sanity check to apply to control pages as well as leaf pages.(CVE-2024-49902)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: jfs: Fix uaf in dbFreeBits [syzbot reported] ================================================================== BUG: KASAN: slab-use-after-free in __mutex_lock_common kernel/locking/mutex.c:587 [inline] BUG: KASAN: slab-use-after-free in __mutex_lock+0xfe/0xd70 kernel/locking/mutex.c:752 Read of size 8 at addr ffff8880229254b0 by task syz-executor357/5216 CPU: 0 UID: 0 PID: 5216 Comm: syz-executor357 Not tainted 6.11.0-rc3-syzkaller-00156-gd7a5aa4b3c00 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024 Call Trace: \u0026lt;TASK\u0026gt; __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 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 __mutex_lock_common kernel/locking/mutex.c:587 [inline] __mutex_lock+0xfe/0xd70 kernel/locking/mutex.c:752 dbFreeBits+0x7ea/0xd90 fs/jfs/jfs_dmap.c:2390 dbFreeDmap fs/jfs/jfs_dmap.c:2089 [inline] dbFree+0x35b/0x680 fs/jfs/jfs_dmap.c:409 dbDiscardAG+0x8a9/0xa20 fs/jfs/jfs_dmap.c:1650 jfs_ioc_trim+0x433/0x670 fs/jfs/jfs_discard.c:100 jfs_ioctl+0x2d0/0x3e0 fs/jfs/ioctl.c:131 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 Freed by task 5218: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579 poison_slab_object+0xe0/0x150 mm/kasan/common.c:240 __kasan_slab_free+0x37/0x60 mm/kasan/common.c:256 kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2252 [inline] slab_free mm/slub.c:4473 [inline] kfree+0x149/0x360 mm/slub.c:4594 dbUnmount+0x11d/0x190 fs/jfs/jfs_dmap.c:278 jfs_mount_rw+0x4ac/0x6a0 fs/jfs/jfs_mount.c:247 jfs_remount+0x3d1/0x6b0 fs/jfs/super.c:454 reconfigure_super+0x445/0x880 fs/super.c:1083 vfs_cmd_reconfigure fs/fsopen.c:263 [inline] vfs_fsconfig_locked fs/fsopen.c:292 [inline] __do_sys_fsconfig fs/fsopen.c:473 [inline] __se_sys_fsconfig+0xb6e/0xf80 fs/fsopen.c:345 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 [Analysis] There are two paths (dbUnmount and jfs_ioc_trim) that generate race condition when accessing bmap, which leads to the occurrence of uaf. Use the lock s_umount to synchronize them, in order to avoid uaf caused by race condition.(CVE-2024-49903)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for function pointer in dcn20_set_output_transfer_func This commit adds a null check for the set_output_gamma function pointer in the dcn20_set_output_transfer_func function. Previously, set_output_gamma was being checked for null at line 1030, but then it was being dereferenced without any null check at line 1048. This could potentially lead to a null pointer dereference error if set_output_gamma is null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a null check for set_output_gamma before the call to set_output_gamma at line 1048.(CVE-2024-49911)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: x86/ioapic: Handle allocation failures gracefully Breno observed panics when using failslab under certain conditions during runtime: can not alloc irq_pin_list (-1,0,20) Kernel panic - not syncing: IO-APIC: failed to add irq-pin. Can not proceed panic+0x4e9/0x590 mp_irqdomain_alloc+0x9ab/0xa80 irq_domain_alloc_irqs_locked+0x25d/0x8d0 __irq_domain_alloc_irqs+0x80/0x110 mp_map_pin_to_irq+0x645/0x890 acpi_register_gsi_ioapic+0xe6/0x150 hpet_open+0x313/0x480 That\u0026apos;s a pointless panic which is a leftover of the historic IO/APIC code which panic\u0026apos;ed during early boot when the interrupt allocation failed. The only place which might justify panic is the PIT/HPET timer_check() code which tries to figure out whether the timer interrupt is delivered through the IO/APIC. But that code does not require to handle interrupt allocation failures. If the interrupt cannot be allocated then timer delivery fails and it either panics due to that or falls back to legacy mode. Cure this by removing the panic wrapper around __add_pin_to_irq_node() and making mp_irqdomain_alloc() aware of the failure condition and handle it as any other failure in this function gracefully.(CVE-2024-49927)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: jbd2: stop waiting for space when jbd2_cleanup_journal_tail() returns error In __jbd2_log_wait_for_space(), we might call jbd2_cleanup_journal_tail() to recover some journal space. But if an error occurs while executing jbd2_cleanup_journal_tail() (e.g., an EIO), we don\u0026apos;t stop waiting for free space right away, we try other branches, and if j_committing_transaction is NULL (i.e., the tid is 0), we will get the following complain: ============================================ JBD2: I/O error when updating journal superblock for sdd-8. __jbd2_log_wait_for_space: needed 256 blocks and only had 217 space available __jbd2_log_wait_for_space: no way to get more journal space in sdd-8 ------------[ cut here ]------------ WARNING: CPU: 2 PID: 139804 at fs/jbd2/checkpoint.c:109 __jbd2_log_wait_for_space+0x251/0x2e0 Modules linked in: CPU: 2 PID: 139804 Comm: kworker/u8:3 Not tainted 6.6.0+ #1 RIP: 0010:__jbd2_log_wait_for_space+0x251/0x2e0 Call Trace: \u0026lt;TASK\u0026gt; add_transaction_credits+0x5d1/0x5e0 start_this_handle+0x1ef/0x6a0 jbd2__journal_start+0x18b/0x340 ext4_dirty_inode+0x5d/0xb0 __mark_inode_dirty+0xe4/0x5d0 generic_update_time+0x60/0x70 [...] ============================================ So only if jbd2_cleanup_journal_tail() returns 1, i.e., there is nothing to clean up at the moment, continue to try to reclaim free space in other ways. Note that this fix relies on commit 6f6a6fda2945 (\u0026quot;jbd2: fix ocfs2 corrupt when updating journal superblock fails\u0026quot;) to make jbd2_cleanup_journal_tail return the correct error code.(CVE-2024-49959)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: ocfs2: cancel dqi_sync_work before freeing oinfo ocfs2_global_read_info() will initialize and schedule dqi_sync_work at the end, if error occurs after successfully reading global quota, it will trigger the following warning with CONFIG_DEBUG_OBJECTS_* enabled: ODEBUG: free active (active state 0) object: 00000000d8b0ce28 object type: timer_list hint: qsync_work_fn+0x0/0x16c This reports that there is an active delayed work when freeing oinfo in error handling, so cancel dqi_sync_work first. BTW, return status instead of -1 when .read_file_info fails.(CVE-2024-49966)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in DCN30 color transformation This commit addresses a potential index out of bounds issue in the `cm3_helper_translate_curve_to_hw_format` function in the DCN30 color management module. The issue could occur when the index \u0026apos;i\u0026apos; exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure \u0026apos;i\u0026apos; is within bounds before accessing the transfer function points. If \u0026apos;i\u0026apos; is out of bounds, the function returns false to indicate an error. drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:180 cm3_helper_translate_curve_to_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.red\u0026apos; 1025 \u0026lt;= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:181 cm3_helper_translate_curve_to_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.green\u0026apos; 1025 \u0026lt;= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:182 cm3_helper_translate_curve_to_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.blue\u0026apos; 1025 \u0026lt;= s32max(CVE-2024-49969)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: NFSD: Limit the number of concurrent async COPY operations Nothing appears to limit the number of concurrent async COPY operations that clients can start. In addition, AFAICT each async COPY can copy an unlimited number of 4MB chunks, so can run for a long time. Thus IMO async COPY can become a DoS vector. Add a restriction mechanism that bounds the number of concurrent background COPY operations. Start simple and try to be fair -- this patch implements a per-namespace limit. An async COPY request that occurs while this limit is exceeded gets NFS4ERR_DELAY. The requesting client can choose to send the request again after a delay or fall back to a traditional read/write style copy. If there is need to make the mechanism more sophisticated, we can visit that in future patches.(CVE-2024-49974)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: i2c: stm32f7: Do not prepare/unprepare clock during runtime suspend/resume In case there is any sort of clock controller attached to this I2C bus controller, for example Versaclock or even an AIC32x4 I2C codec, then an I2C transfer triggered from the clock controller clk_ops .prepare callback may trigger a deadlock on drivers/clk/clk.c prepare_lock mutex. This is because the clock controller first grabs the prepare_lock mutex and then performs the prepare operation, including its I2C access. The I2C access resumes this I2C bus controller via .runtime_resume callback, which calls clk_prepare_enable(), which attempts to grab the prepare_lock mutex again and deadlocks. Since the clock are already prepared since probe() and unprepared in remove(), use simple clk_enable()/clk_disable() calls to enable and disable the clock on runtime suspend and resume, to avoid hitting the prepare_lock mutex.(CVE-2024-49985)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: ALSA: asihpi: Fix potential OOB array access ASIHPI driver stores some values in the static array upon a response from the driver, and its index depends on the firmware. We shouldn\u0026apos;t trust it blindly. This patch adds a sanity check of the array index to fit in the array size.(CVE-2024-50007)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: scsi: fnic: Move flush_work initialization out of if block After commit 379a58caa199 (\u0026quot;scsi: fnic: Move fnic_fnic_flush_tx() to a work queue\u0026quot;), it can happen that a work item is sent to an uninitialized work queue. This may has the effect that the item being queued is never actually queued, and any further actions depending on it will not proceed. The following warning is observed while the fnic driver is loaded: kernel: WARNING: CPU: 11 PID: 0 at ../kernel/workqueue.c:1524 __queue_work+0x373/0x410 kernel: \u0026lt;IRQ\u0026gt; kernel: queue_work_on+0x3a/0x50 kernel: fnic_wq_copy_cmpl_handler+0x54a/0x730 [fnic 62fbff0c42e7fb825c60a55cde2fb91facb2ed24] kernel: fnic_isr_msix_wq_copy+0x2d/0x60 [fnic 62fbff0c42e7fb825c60a55cde2fb91facb2ed24] kernel: __handle_irq_event_percpu+0x36/0x1a0 kernel: handle_irq_event_percpu+0x30/0x70 kernel: handle_irq_event+0x34/0x60 kernel: handle_edge_irq+0x7e/0x1a0 kernel: __common_interrupt+0x3b/0xb0 kernel: common_interrupt+0x58/0xa0 kernel: \u0026lt;/IRQ\u0026gt; It has been observed that this may break the rediscovery of Fibre Channel devices after a temporary fabric failure. This patch fixes it by moving the work queue initialization out of an if block in fnic_probe().(CVE-2024-50025)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: net: do not delay dst_entries_add() in dst_release() dst_entries_add() uses per-cpu data that might be freed at netns dismantle from ip6_route_net_exit() calling dst_entries_destroy() Before ip6_route_net_exit() can be called, we release all the dsts associated with this netns, via calls to dst_release(), which waits an rcu grace period before calling dst_destroy() dst_entries_add() use in dst_destroy() is racy, because dst_entries_destroy() could have been called already. Decrementing the number of dsts must happen sooner. Notes: 1) in CONFIG_XFRM case, dst_destroy() can call dst_release_immediate(child), this might also cause UAF if the child does not have DST_NOCOUNT set. IPSEC maintainers might take a look and see how to address this. 2) There is also discussion about removing this count of dst, which might happen in future kernels.(CVE-2024-50036)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointer before dereferencing se [WHAT \u0026amp; HOW] se is null checked previously in the same function, indicating it might be null; therefore, it must be checked when used again. This fixes 1 FORWARD_NULL issue reported by Coverity.(CVE-2024-50049)",
"id": "OESA-2024-2324",
"modified": "2026-08-06T11:07:48Z",
"published": "2024-11-01T11:07:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2324"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48916"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48946"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48952"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48967"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48973"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48977"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48986"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48988"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48991"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48994"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49006"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49007"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49019"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49029"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49030"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49033"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52754"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52855"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52917"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52918"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52919"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26917"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35878"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35990"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36286"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38635"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38667"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41015"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42152"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42301"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43841"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43858"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43867"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43871"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43894"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46675"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46689"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46722"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46724"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46757"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46802"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46830"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46853"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47667"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47669"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47684"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47685"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47695"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47698"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47709"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47710"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47720"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47737"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47757"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49866"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49867"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49868"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49875"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49894"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49895"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49900"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49902"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49903"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49911"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49927"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49959"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49966"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49969"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49974"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49985"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50007"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50025"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50036"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50049"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2022-48916",
"CVE-2022-48946",
"CVE-2022-48952",
"CVE-2022-48967",
"CVE-2022-48973",
"CVE-2022-48977",
"CVE-2022-48986",
"CVE-2022-48988",
"CVE-2022-48991",
"CVE-2022-48994",
"CVE-2022-49006",
"CVE-2022-49007",
"CVE-2022-49019",
"CVE-2022-49029",
"CVE-2022-49030",
"CVE-2022-49033",
"CVE-2023-52754",
"CVE-2023-52855",
"CVE-2023-52917",
"CVE-2023-52918",
"CVE-2023-52919",
"CVE-2024-26917",
"CVE-2024-35878",
"CVE-2024-35990",
"CVE-2024-36286",
"CVE-2024-38635",
"CVE-2024-38667",
"CVE-2024-41015",
"CVE-2024-42152",
"CVE-2024-42301",
"CVE-2024-43841",
"CVE-2024-43858",
"CVE-2024-43867",
"CVE-2024-43871",
"CVE-2024-43894",
"CVE-2024-46675",
"CVE-2024-46689",
"CVE-2024-46722",
"CVE-2024-46724",
"CVE-2024-46757",
"CVE-2024-46802",
"CVE-2024-46830",
"CVE-2024-46853",
"CVE-2024-47667",
"CVE-2024-47669",
"CVE-2024-47684",
"CVE-2024-47685",
"CVE-2024-47695",
"CVE-2024-47698",
"CVE-2024-47709",
"CVE-2024-47710",
"CVE-2024-47720",
"CVE-2024-47737",
"CVE-2024-47757",
"CVE-2024-49866",
"CVE-2024-49867",
"CVE-2024-49868",
"CVE-2024-49875",
"CVE-2024-49894",
"CVE-2024-49895",
"CVE-2024-49900",
"CVE-2024-49902",
"CVE-2024-49903",
"CVE-2024-49911",
"CVE-2024-49927",
"CVE-2024-49959",
"CVE-2024-49966",
"CVE-2024-49969",
"CVE-2024-49974",
"CVE-2024-49985",
"CVE-2024-50007",
"CVE-2024-50025",
"CVE-2024-50036",
"CVE-2024-50049"
]
}
SUSE-SU-2024:1644-1
Vulnerability from csaf_suse - Published: 2024-05-14 14:29 - Updated: 2026-09-20 15:49Sightings
| 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.