Action not permitted
Modal body text goes here.
Modal Title
Modal Body
CVE-2024-42154 (GCVE-0-2024-42154)
Vulnerability from cvelistv5 – Published: 2024-07-30 07:46 – Updated: 2026-05-11 20:28| Vendor | Product | Version | CPE status | |
|---|---|---|---|---|
| Linux | Linux |
Affected:
3e7013ddf55af7bc191792b8aea0c2b94fb0fef5 , < 19d997b59fa1fd7a02e770ee0881c0652b9c32c9
(git)
Affected: 3e7013ddf55af7bc191792b8aea0c2b94fb0fef5 , < 2a2e79dbe2236a1289412d2044994f7ab419b44c (git) Affected: 3e7013ddf55af7bc191792b8aea0c2b94fb0fef5 , < cdffc358717e436bb67122bb82c1a2a26e050f98 (git) Affected: 3e7013ddf55af7bc191792b8aea0c2b94fb0fef5 , < ef7c428b425beeb52b894e16f1c4b629d6cebfb6 (git) Affected: 3e7013ddf55af7bc191792b8aea0c2b94fb0fef5 , < 31f03bb04146c1c6df6c03e9f45401f5f5a985d3 (git) Affected: 3e7013ddf55af7bc191792b8aea0c2b94fb0fef5 , < 8c2debdd170e395934ac0e039748576dfde14e99 (git) Affected: 3e7013ddf55af7bc191792b8aea0c2b94fb0fef5 , < 3d550dd5418729a6e77fe7721d27adea7152e321 (git) Affected: 3e7013ddf55af7bc191792b8aea0c2b94fb0fef5 , < 66be40e622e177316ae81717aa30057ba9e61dff (git) |
guessed | |
| Linux | Linux |
Affected:
3.14
Unaffected: 0 , < 3.14 (semver) Unaffected: 4.19.318 , ≤ 4.19.* (semver) Unaffected: 5.4.280 , ≤ 5.4.* (semver) Unaffected: 5.10.222 , ≤ 5.10.* (semver) Unaffected: 5.15.163 , ≤ 5.15.* (semver) Unaffected: 6.1.98 , ≤ 6.1.* (semver) Unaffected: 6.6.39 , ≤ 6.6.* (semver) Unaffected: 6.9.9 , ≤ 6.9.* (semver) Unaffected: 6.10 , ≤ * (original_commit_for_fix) |
guessed |
{
"containers": {
"adp": [
{
"providerMetadata": {
"dateUpdated": "2025-11-03T22:02:18.507Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/19d997b59fa1fd7a02e770ee0881c0652b9c32c9"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/2a2e79dbe2236a1289412d2044994f7ab419b44c"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/cdffc358717e436bb67122bb82c1a2a26e050f98"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/ef7c428b425beeb52b894e16f1c4b629d6cebfb6"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/31f03bb04146c1c6df6c03e9f45401f5f5a985d3"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/8c2debdd170e395934ac0e039748576dfde14e99"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/3d550dd5418729a6e77fe7721d27adea7152e321"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/66be40e622e177316ae81717aa30057ba9e61dff"
},
{
"url": "https://security.netapp.com/advisory/ntap-20240828-0010/"
},
{
"url": "http://www.openwall.com/lists/oss-security/2024/09/24/3"
},
{
"url": "http://www.openwall.com/lists/oss-security/2024/09/24/4"
},
{
"url": "http://www.openwall.com/lists/oss-security/2024/09/25/3"
},
{
"url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
}
],
"title": "CVE Program Container"
},
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2024-42154",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2024-09-10T16:15:15.159948Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2024-09-11T17:34:34.227Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"net/ipv4/tcp_metrics.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "19d997b59fa1fd7a02e770ee0881c0652b9c32c9",
"status": "affected",
"version": "3e7013ddf55af7bc191792b8aea0c2b94fb0fef5",
"versionType": "git"
},
{
"lessThan": "2a2e79dbe2236a1289412d2044994f7ab419b44c",
"status": "affected",
"version": "3e7013ddf55af7bc191792b8aea0c2b94fb0fef5",
"versionType": "git"
},
{
"lessThan": "cdffc358717e436bb67122bb82c1a2a26e050f98",
"status": "affected",
"version": "3e7013ddf55af7bc191792b8aea0c2b94fb0fef5",
"versionType": "git"
},
{
"lessThan": "ef7c428b425beeb52b894e16f1c4b629d6cebfb6",
"status": "affected",
"version": "3e7013ddf55af7bc191792b8aea0c2b94fb0fef5",
"versionType": "git"
},
{
"lessThan": "31f03bb04146c1c6df6c03e9f45401f5f5a985d3",
"status": "affected",
"version": "3e7013ddf55af7bc191792b8aea0c2b94fb0fef5",
"versionType": "git"
},
{
"lessThan": "8c2debdd170e395934ac0e039748576dfde14e99",
"status": "affected",
"version": "3e7013ddf55af7bc191792b8aea0c2b94fb0fef5",
"versionType": "git"
},
{
"lessThan": "3d550dd5418729a6e77fe7721d27adea7152e321",
"status": "affected",
"version": "3e7013ddf55af7bc191792b8aea0c2b94fb0fef5",
"versionType": "git"
},
{
"lessThan": "66be40e622e177316ae81717aa30057ba9e61dff",
"status": "affected",
"version": "3e7013ddf55af7bc191792b8aea0c2b94fb0fef5",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"net/ipv4/tcp_metrics.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "3.14"
},
{
"lessThan": "3.14",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "4.19.*",
"status": "unaffected",
"version": "4.19.318",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.280",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.222",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.163",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.98",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.39",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.9.*",
"status": "unaffected",
"version": "6.9.9",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.10",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "4.19.318",
"versionStartIncluding": "3.14",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.4.280",
"versionStartIncluding": "3.14",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.10.222",
"versionStartIncluding": "3.14",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.15.163",
"versionStartIncluding": "3.14",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.1.98",
"versionStartIncluding": "3.14",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6.39",
"versionStartIncluding": "3.14",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.9.9",
"versionStartIncluding": "3.14",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.10",
"versionStartIncluding": "3.14",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ntcp_metrics: validate source addr length\n\nI don\u0027t see anything checking that TCP_METRICS_ATTR_SADDR_IPV4\nis at least 4 bytes long, and the policy doesn\u0027t have an entry\nfor this attribute at all (neither does it for IPv6 but v6 is\nmanually validated)."
}
],
"providerMetadata": {
"dateUpdated": "2026-05-11T20:28:01.090Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/19d997b59fa1fd7a02e770ee0881c0652b9c32c9"
},
{
"url": "https://git.kernel.org/stable/c/2a2e79dbe2236a1289412d2044994f7ab419b44c"
},
{
"url": "https://git.kernel.org/stable/c/cdffc358717e436bb67122bb82c1a2a26e050f98"
},
{
"url": "https://git.kernel.org/stable/c/ef7c428b425beeb52b894e16f1c4b629d6cebfb6"
},
{
"url": "https://git.kernel.org/stable/c/31f03bb04146c1c6df6c03e9f45401f5f5a985d3"
},
{
"url": "https://git.kernel.org/stable/c/8c2debdd170e395934ac0e039748576dfde14e99"
},
{
"url": "https://git.kernel.org/stable/c/3d550dd5418729a6e77fe7721d27adea7152e321"
},
{
"url": "https://git.kernel.org/stable/c/66be40e622e177316ae81717aa30057ba9e61dff"
}
],
"title": "tcp_metrics: validate source addr length",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2024-42154",
"datePublished": "2024-07-30T07:46:51.456Z",
"dateReserved": "2024-07-29T15:50:41.194Z",
"dateUpdated": "2026-05-11T20:28:01.090Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"epss": {
"cve": "CVE-2024-42154",
"date": "2026-09-22",
"epss": "0.00258",
"percentile": "0.17764"
},
"microsoft_vex": {
"current_release_date": "2026-02-19T01:16:57.000Z",
"cve": "CVE-2024-42154",
"id": "msrc_CVE-2024-42154",
"initial_release_date": "2024-07-01T07:00:00.000Z",
"product_status:fixed": "5",
"product_status:known_affected": "5",
"source": "Microsoft CSAF VEX",
"status": "final",
"title": "tcp_metrics: validate source addr length",
"url": "https://msrc.microsoft.com/csaf/vex/2024/msrc_cve-2024-42154.json",
"version": "4"
},
"nvd": {
"cve": {
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"net/ipv4/tcp_metrics.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "19d997b59fa1fd7a02e770ee0881c0652b9c32c9",
"status": "affected",
"version": "3e7013ddf55af7bc191792b8aea0c2b94fb0fef5",
"versionType": "git"
},
{
"lessThan": "2a2e79dbe2236a1289412d2044994f7ab419b44c",
"status": "affected",
"version": "3e7013ddf55af7bc191792b8aea0c2b94fb0fef5",
"versionType": "git"
},
{
"lessThan": "cdffc358717e436bb67122bb82c1a2a26e050f98",
"status": "affected",
"version": "3e7013ddf55af7bc191792b8aea0c2b94fb0fef5",
"versionType": "git"
},
{
"lessThan": "ef7c428b425beeb52b894e16f1c4b629d6cebfb6",
"status": "affected",
"version": "3e7013ddf55af7bc191792b8aea0c2b94fb0fef5",
"versionType": "git"
},
{
"lessThan": "31f03bb04146c1c6df6c03e9f45401f5f5a985d3",
"status": "affected",
"version": "3e7013ddf55af7bc191792b8aea0c2b94fb0fef5",
"versionType": "git"
},
{
"lessThan": "8c2debdd170e395934ac0e039748576dfde14e99",
"status": "affected",
"version": "3e7013ddf55af7bc191792b8aea0c2b94fb0fef5",
"versionType": "git"
},
{
"lessThan": "3d550dd5418729a6e77fe7721d27adea7152e321",
"status": "affected",
"version": "3e7013ddf55af7bc191792b8aea0c2b94fb0fef5",
"versionType": "git"
},
{
"lessThan": "66be40e622e177316ae81717aa30057ba9e61dff",
"status": "affected",
"version": "3e7013ddf55af7bc191792b8aea0c2b94fb0fef5",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"net/ipv4/tcp_metrics.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "3.14"
},
{
"lessThan": "3.14",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "4.19.*",
"status": "unaffected",
"version": "4.19.318",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.280",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.222",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.163",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.98",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.39",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.9.*",
"status": "unaffected",
"version": "6.9.9",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.10",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"configurations": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "41501C3F-D08F-4EAC-A463-95CDEF6987D8",
"versionEndExcluding": "4.19.318",
"versionStartIncluding": "3.14",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "625DBFAB-C3D0-4309-A27F-12D6428FB38F",
"versionEndExcluding": "5.4.280",
"versionStartIncluding": "4.20",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "00696AC5-EE29-437F-97F9-C4D66608B327",
"versionEndExcluding": "5.10.222",
"versionStartIncluding": "5.5",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "A97DEB09-4927-40F8-B5C6-F5BD5EAE0CFD",
"versionEndExcluding": "5.15.163",
"versionStartIncluding": "5.11",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "E09E92A5-27EF-40E4-926A-B1CDC8270551",
"versionEndExcluding": "6.1.98",
"versionStartIncluding": "5.16",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "29E894E4-668F-4DB0-81F7-4FB5F698E970",
"versionEndExcluding": "6.6.39",
"versionStartIncluding": "6.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "ADCC1407-0CB3-4C8F-B4C5-07F682CD7085",
"versionEndExcluding": "6.9.9",
"versionStartIncluding": "6.7",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.10:rc1:*:*:*:*:*:*",
"matchCriteriaId": "2EBB4392-5FA6-4DA9-9772-8F9C750109FA",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.10:rc2:*:*:*:*:*:*",
"matchCriteriaId": "331C2F14-12C7-45D5-893D-8C52EE38EA10",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.10:rc3:*:*:*:*:*:*",
"matchCriteriaId": "3173713D-909A-4DD3-9DD4-1E171EB057EE",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.10:rc4:*:*:*:*:*:*",
"matchCriteriaId": "79F18AFA-40F7-43F0-BA30-7BDB65F918B9",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.10:rc5:*:*:*:*:*:*",
"matchCriteriaId": "BD973AA4-A789-49BD-8D57-B2846935D3C7",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.10:rc6:*:*:*:*:*:*",
"matchCriteriaId": "8F3E9E0C-AC3E-4967-AF80-6483E8AB0078",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ntcp_metrics: validate source addr length\n\nI don\u0027t see anything checking that TCP_METRICS_ATTR_SADDR_IPV4\nis at least 4 bytes long, and the policy doesn\u0027t have an entry\nfor this attribute at all (neither does it for IPv6 but v6 is\nmanually validated)."
},
{
"lang": "es",
"value": " En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tcp_metrics: validar la longitud de la direcci\u00f3n de origen. No veo nada comprobando que TCP_METRICS_ATTR_SADDR_IPV4 tenga al menos 4 bytes de longitud y la pol\u00edtica no tiene ninguna entrada para este atributo (tampoco lo hace para IPv6 pero v6 se valida manualmente)."
}
],
"id": "CVE-2024-42154",
"lastModified": "2026-06-17T07:48:56.670",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "NONE",
"baseScore": 4.4,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "LOW",
"integrityImpact": "LOW",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 2.5,
"source": "nvd@nist.gov",
"type": "Primary"
}
],
"ssvcV203": [
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"ssvcData": {
"id": "CVE-2024-42154",
"options": [
{
"exploitation": "none"
},
{
"automatable": "no"
},
{
"technicalImpact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2024-09-10T16:15:15.159948Z",
"version": "2.0.3"
}
}
]
},
"published": "2024-07-30T08:15:06.933",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Mailing List",
"Patch"
],
"url": "https://git.kernel.org/stable/c/19d997b59fa1fd7a02e770ee0881c0652b9c32c9"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Mailing List",
"Patch"
],
"url": "https://git.kernel.org/stable/c/2a2e79dbe2236a1289412d2044994f7ab419b44c"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Mailing List",
"Patch"
],
"url": "https://git.kernel.org/stable/c/31f03bb04146c1c6df6c03e9f45401f5f5a985d3"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Mailing List",
"Patch"
],
"url": "https://git.kernel.org/stable/c/3d550dd5418729a6e77fe7721d27adea7152e321"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Mailing List",
"Patch"
],
"url": "https://git.kernel.org/stable/c/66be40e622e177316ae81717aa30057ba9e61dff"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Mailing List",
"Patch"
],
"url": "https://git.kernel.org/stable/c/8c2debdd170e395934ac0e039748576dfde14e99"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Mailing List",
"Patch"
],
"url": "https://git.kernel.org/stable/c/cdffc358717e436bb67122bb82c1a2a26e050f98"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Mailing List",
"Patch"
],
"url": "https://git.kernel.org/stable/c/ef7c428b425beeb52b894e16f1c4b629d6cebfb6"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"url": "http://www.openwall.com/lists/oss-security/2024/09/24/3"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"url": "http://www.openwall.com/lists/oss-security/2024/09/24/4"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"url": "http://www.openwall.com/lists/oss-security/2024/09/25/3"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Mailing List",
"Patch"
],
"url": "https://git.kernel.org/stable/c/19d997b59fa1fd7a02e770ee0881c0652b9c32c9"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Mailing List",
"Patch"
],
"url": "https://git.kernel.org/stable/c/2a2e79dbe2236a1289412d2044994f7ab419b44c"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Mailing List",
"Patch"
],
"url": "https://git.kernel.org/stable/c/31f03bb04146c1c6df6c03e9f45401f5f5a985d3"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Mailing List",
"Patch"
],
"url": "https://git.kernel.org/stable/c/3d550dd5418729a6e77fe7721d27adea7152e321"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Mailing List",
"Patch"
],
"url": "https://git.kernel.org/stable/c/66be40e622e177316ae81717aa30057ba9e61dff"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Mailing List",
"Patch"
],
"url": "https://git.kernel.org/stable/c/8c2debdd170e395934ac0e039748576dfde14e99"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Mailing List",
"Patch"
],
"url": "https://git.kernel.org/stable/c/cdffc358717e436bb67122bb82c1a2a26e050f98"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Mailing List",
"Patch"
],
"url": "https://git.kernel.org/stable/c/ef7c428b425beeb52b894e16f1c4b629d6cebfb6"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"url": "https://security.netapp.com/advisory/ntap-20240828-0010/"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Modified",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "CWE-754"
}
],
"source": "nvd@nist.gov",
"type": "Primary"
}
]
}
},
"redhat_vex": {
"aggregate_severity": "Moderate",
"current_release_date": "2026-06-28T08:00:16+00:00",
"cve": "CVE-2024-42154",
"id": "CVE-2024-42154",
"initial_release_date": "2024-07-30T00:00:00+00:00",
"product_status:fixed": "1063",
"product_status:known_affected": "50",
"product_status:known_not_affected": "23",
"source": "Red Hat CSAF VEX",
"status": "final",
"title": "kernel: tcp_metrics: validate source addr length",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2024/cve-2024-42154.json",
"version": "3"
},
"vulnrichment": {
"containers": {
"adp": [
{
"providerMetadata": {
"dateUpdated": "2025-11-03T22:02:18.507Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/19d997b59fa1fd7a02e770ee0881c0652b9c32c9"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/2a2e79dbe2236a1289412d2044994f7ab419b44c"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/cdffc358717e436bb67122bb82c1a2a26e050f98"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/ef7c428b425beeb52b894e16f1c4b629d6cebfb6"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/31f03bb04146c1c6df6c03e9f45401f5f5a985d3"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/8c2debdd170e395934ac0e039748576dfde14e99"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/3d550dd5418729a6e77fe7721d27adea7152e321"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/66be40e622e177316ae81717aa30057ba9e61dff"
},
{
"url": "https://security.netapp.com/advisory/ntap-20240828-0010/"
},
{
"url": "http://www.openwall.com/lists/oss-security/2024/09/24/3"
},
{
"url": "http://www.openwall.com/lists/oss-security/2024/09/24/4"
},
{
"url": "http://www.openwall.com/lists/oss-security/2024/09/25/3"
},
{
"url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
}
],
"title": "CVE Program Container"
},
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2024-42154",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2024-09-10T16:15:15.159948Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2024-09-11T12:42:24.513Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"net/ipv4/tcp_metrics.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "19d997b59fa1fd7a02e770ee0881c0652b9c32c9",
"status": "affected",
"version": "3e7013ddf55af7bc191792b8aea0c2b94fb0fef5",
"versionType": "git"
},
{
"lessThan": "2a2e79dbe2236a1289412d2044994f7ab419b44c",
"status": "affected",
"version": "3e7013ddf55af7bc191792b8aea0c2b94fb0fef5",
"versionType": "git"
},
{
"lessThan": "cdffc358717e436bb67122bb82c1a2a26e050f98",
"status": "affected",
"version": "3e7013ddf55af7bc191792b8aea0c2b94fb0fef5",
"versionType": "git"
},
{
"lessThan": "ef7c428b425beeb52b894e16f1c4b629d6cebfb6",
"status": "affected",
"version": "3e7013ddf55af7bc191792b8aea0c2b94fb0fef5",
"versionType": "git"
},
{
"lessThan": "31f03bb04146c1c6df6c03e9f45401f5f5a985d3",
"status": "affected",
"version": "3e7013ddf55af7bc191792b8aea0c2b94fb0fef5",
"versionType": "git"
},
{
"lessThan": "8c2debdd170e395934ac0e039748576dfde14e99",
"status": "affected",
"version": "3e7013ddf55af7bc191792b8aea0c2b94fb0fef5",
"versionType": "git"
},
{
"lessThan": "3d550dd5418729a6e77fe7721d27adea7152e321",
"status": "affected",
"version": "3e7013ddf55af7bc191792b8aea0c2b94fb0fef5",
"versionType": "git"
},
{
"lessThan": "66be40e622e177316ae81717aa30057ba9e61dff",
"status": "affected",
"version": "3e7013ddf55af7bc191792b8aea0c2b94fb0fef5",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"net/ipv4/tcp_metrics.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "3.14"
},
{
"lessThan": "3.14",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "4.19.*",
"status": "unaffected",
"version": "4.19.318",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.280",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.222",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.163",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.98",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.39",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.9.*",
"status": "unaffected",
"version": "6.9.9",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.10",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "4.19.318",
"versionStartIncluding": "3.14",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.4.280",
"versionStartIncluding": "3.14",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.10.222",
"versionStartIncluding": "3.14",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.15.163",
"versionStartIncluding": "3.14",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.1.98",
"versionStartIncluding": "3.14",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6.39",
"versionStartIncluding": "3.14",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.9.9",
"versionStartIncluding": "3.14",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.10",
"versionStartIncluding": "3.14",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ntcp_metrics: validate source addr length\n\nI don\u0027t see anything checking that TCP_METRICS_ATTR_SADDR_IPV4\nis at least 4 bytes long, and the policy doesn\u0027t have an entry\nfor this attribute at all (neither does it for IPv6 but v6 is\nmanually validated)."
}
],
"providerMetadata": {
"dateUpdated": "2026-05-11T20:28:01.090Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/19d997b59fa1fd7a02e770ee0881c0652b9c32c9"
},
{
"url": "https://git.kernel.org/stable/c/2a2e79dbe2236a1289412d2044994f7ab419b44c"
},
{
"url": "https://git.kernel.org/stable/c/cdffc358717e436bb67122bb82c1a2a26e050f98"
},
{
"url": "https://git.kernel.org/stable/c/ef7c428b425beeb52b894e16f1c4b629d6cebfb6"
},
{
"url": "https://git.kernel.org/stable/c/31f03bb04146c1c6df6c03e9f45401f5f5a985d3"
},
{
"url": "https://git.kernel.org/stable/c/8c2debdd170e395934ac0e039748576dfde14e99"
},
{
"url": "https://git.kernel.org/stable/c/3d550dd5418729a6e77fe7721d27adea7152e321"
},
{
"url": "https://git.kernel.org/stable/c/66be40e622e177316ae81717aa30057ba9e61dff"
}
],
"title": "tcp_metrics: validate source addr length",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2024-42154",
"datePublished": "2024-07-30T07:46:51.456Z",
"dateReserved": "2024-07-29T15:50:41.194Z",
"dateUpdated": "2026-05-11T20:28:01.090Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
}
}
ICSA-25-072-03
Vulnerability from csaf_cisa - Published: 2025-03-11 00:00 - Updated: 2025-09-09 00:00ICSA-25-226-07
Vulnerability from csaf_cisa - Published: 2025-08-12 00:00 - Updated: 2026-02-25 07:00ICSA-25-226-15
Vulnerability from csaf_cisa - Published: 2025-08-12 00:00 - Updated: 2026-02-25 07:00MSRC_CVE-2024-42154
Vulnerability from csaf_microsoft - Published: 2024-07-01 07:00 - Updated: 2026-02-19 01:16NCSC-2025-0077
Vulnerability from csaf_ncscnl - Published: 2025-03-11 12:30 - Updated: 2025-03-11 12:30OESA-2024-1992 (CVE-2021-47582)
Vulnerability from osv_openeuler – Published: 2024-08-16 11:07 – Updated: 2026-08-06 11:07 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
USB: core: Make do_proc_control() and do_proc_bulk() killable
The USBDEVFS_CONTROL and USBDEVFS_BULK ioctls invoke usb_start_wait_urb(), which contains an uninterruptible wait with a user-specified timeout value. If timeout value is very large and the device being accessed does not respond in a reasonable amount of time, the kernel will complain about "Task X blocked for more than N seconds", as found in testing by syzbot:
INFO: task syz-executor.0:8700 blocked for more than 143 seconds. Not tainted 5.14.0-rc7-syzkaller #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:syz-executor.0 state:D stack:23192 pid: 8700 ppid: 8455 flags:0x00004004 Call Trace: context_switch kernel/sched/core.c:4681 [inline] __schedule+0xc07/0x11f0 kernel/sched/core.c:5938 schedule+0x14b/0x210 kernel/sched/core.c:6017 schedule_timeout+0x98/0x2f0 kernel/time/timer.c:1857 do_wait_for_common+0x2da/0x480 kernel/sched/completion.c:85 __wait_for_common kernel/sched/completion.c:106 [inline] wait_for_common kernel/sched/completion.c:117 [inline] wait_for_completion_timeout+0x46/0x60 kernel/sched/completion.c:157 usb_start_wait_urb+0x167/0x550 drivers/usb/core/message.c:63 do_proc_bulk+0x978/0x1080 drivers/usb/core/devio.c:1236 proc_bulk drivers/usb/core/devio.c:1273 [inline] usbdev_do_ioctl drivers/usb/core/devio.c:2547 [inline] usbdev_ioctl+0x3441/0x6b10 drivers/usb/core/devio.c:2713 ...
To fix this problem, this patch replaces usbfs's calls to usb_control_msg() and usb_bulk_msg() with special-purpose code that does essentially the same thing (as recommended in the comment for usb_start_wait_urb()), except that it always uses a killable wait and it uses GFP_KERNEL rather than GFP_NOIO.(CVE-2021-47582)
In the Linux kernel, the following vulnerability has been resolved:
NFSD: Fix the behavior of READ near OFFSET_MAX
Dan Aloni reports: > Due to commit 8cfb9015280d ("NFS: Always provide aligned buffers to > the RPC read layers") on the client, a read of 0xfff is aligned up > to server rsize of 0x1000. > > As a result, in a test where the server has a file of size > 0x7fffffffffffffff, and the client tries to read from the offset > 0x7ffffffffffff000, the read causes loff_t overflow in the server > and it returns an NFS code of EINVAL to the client. The client as > a result indefinitely retries the request.
The Linux NFS client does not handle NFS?ERR_INVAL, even though all NFS specifications permit servers to return that status code for a READ.
Instead of NFS?ERR_INVAL, have out-of-range READ requests succeed and return a short result. Set the EOF flag in the result to prevent the client from retrying the READ request. This behavior appears to be consistent with Solaris NFS servers.
Note that NFSv3 and NFSv4 use u64 offset values on the wire. These must be converted to loff_t internally before use -- an implicit type cast is not adequate for this purpose. Otherwise VFS checks against sb->s_maxbytes do not work properly.(CVE-2022-48827)
In the Linux kernel, the following vulnerability has been resolved:
media: mediatek: vcodec: Only free buffer VA that is not NULL
In the MediaTek vcodec driver, while mtk_vcodec_mem_free() is mostly called only when the buffer to free exists, there are some instances that didn't do the check and triggered warnings in practice.
We believe those checks were forgotten unintentionally. Add the checks back to fix the warnings.(CVE-2023-52888)
In the Linux kernel, the following vulnerability has been resolved:
HID: core: remove unnecessary WARN_ON() in implement()
Syzkaller hit a warning [1] in a call to implement() when trying to write a value into a field of smaller size in an output report.
Since implement() already has a warn message printed out with the help of hid_warn() and value in question gets trimmed with: ... value &= m; ... WARN_ON may be considered superfluous. Remove it to suppress future syzkaller triggers.
[1] WARNING: CPU: 0 PID: 5084 at drivers/hid/hid-core.c:1451 implement drivers/hid/hid-core.c:1451 [inline] WARNING: CPU: 0 PID: 5084 at drivers/hid/hid-core.c:1451 hid_output_report+0x548/0x760 drivers/hid/hid-core.c:1863 Modules linked in: CPU: 0 PID: 5084 Comm: syz-executor424 Not tainted 6.9.0-rc7-syzkaller-00183-gcf87f46fd34d #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024 RIP: 0010:implement drivers/hid/hid-core.c:1451 [inline] RIP: 0010:hid_output_report+0x548/0x760 drivers/hid/hid-core.c:1863 ... Call Trace: <TASK> __usbhid_submit_report drivers/hid/usbhid/hid-core.c:591 [inline] usbhid_submit_report+0x43d/0x9e0 drivers/hid/usbhid/hid-core.c:636 hiddev_ioctl+0x138b/0x1f00 drivers/hid/usbhid/hiddev.c:726 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:904 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:890 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f ...(CVE-2024-39509)
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: mesh: Fix leak of mesh_preq_queue objects
The hwmp code use objects of type mesh_preq_queue, added to a list in ieee80211_if_mesh, to keep track of mpath we need to resolve. If the mpath gets deleted, ex mesh interface is removed, the entries in that list will never get cleaned. Fix this by flushing all corresponding items of the preq_queue in mesh_path_flush_pending().
This should take care of KASAN reports like this:
unreferenced object 0xffff00000668d800 (size 128): comm "kworker/u8:4", pid 67, jiffies 4295419552 (age 1836.444s) hex dump (first 32 bytes): 00 1f 05 09 00 00 ff ff 00 d5 68 06 00 00 ff ff ..........h..... 8e 97 ea eb 3e b8 01 00 00 00 00 00 00 00 00 00 ....>........... backtrace: [<000000007302a0b6>] __kmem_cache_alloc_node+0x1e0/0x35c [<00000000049bd418>] kmalloc_trace+0x34/0x80 [<0000000000d792bb>] mesh_queue_preq+0x44/0x2a8 [<00000000c99c3696>] mesh_nexthop_resolve+0x198/0x19c [<00000000926bf598>] ieee80211_xmit+0x1d0/0x1f4 [<00000000fc8c2284>] __ieee80211_subif_start_xmit+0x30c/0x764 [<000000005926ee38>] ieee80211_subif_start_xmit+0x9c/0x7a4 [<000000004c86e916>] dev_hard_start_xmit+0x174/0x440 [<0000000023495647>] __dev_queue_xmit+0xe24/0x111c [<00000000cfe9ca78>] batadv_send_skb_packet+0x180/0x1e4 [<000000007bacc5d5>] batadv_v_elp_periodic_work+0x2f4/0x508 [<00000000adc3cd94>] process_one_work+0x4b8/0xa1c [<00000000b36425d1>] worker_thread+0x9c/0x634 [<0000000005852dd5>] kthread+0x1bc/0x1c4 [<000000005fccd770>] ret_from_fork+0x10/0x20 unreferenced object 0xffff000009051f00 (size 128): comm "kworker/u8:4", pid 67, jiffies 4295419553 (age 1836.440s) hex dump (first 32 bytes): 90 d6 92 0d 00 00 ff ff 00 d8 68 06 00 00 ff ff ..........h..... 36 27 92 e4 02 e0 01 00 00 58 79 06 00 00 ff ff 6'.......Xy..... backtrace: [<000000007302a0b6>] __kmem_cache_alloc_node+0x1e0/0x35c [<00000000049bd418>] kmalloc_trace+0x34/0x80 [<0000000000d792bb>] mesh_queue_preq+0x44/0x2a8 [<00000000c99c3696>] mesh_nexthop_resolve+0x198/0x19c [<00000000926bf598>] ieee80211_xmit+0x1d0/0x1f4 [<00000000fc8c2284>] __ieee80211_subif_start_xmit+0x30c/0x764 [<000000005926ee38>] ieee80211_subif_start_xmit+0x9c/0x7a4 [<000000004c86e916>] dev_hard_start_xmit+0x174/0x440 [<0000000023495647>] __dev_queue_xmit+0xe24/0x111c [<00000000cfe9ca78>] batadv_send_skb_packet+0x180/0x1e4 [<000000007bacc5d5>] batadv_v_elp_periodic_work+0x2f4/0x508 [<00000000adc3cd94>] process_one_work+0x4b8/0xa1c [<00000000b36425d1>] worker_thread+0x9c/0x634 [<0000000005852dd5>] kthread+0x1bc/0x1c4 [<000000005fccd770>] ret_from_fork+0x10/0x20(CVE-2024-40942)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/mlx5: Add check for srq max_sge attribute
max_sge attribute is passed by the user, and is inserted and used unchecked, so verify that the value doesn't exceed maximum allowed value before using it.(CVE-2024-40990)
In the Linux kernel, the following vulnerability has been resolved:
filelock: Remove locks reliably when fcntl/close race is detected
When fcntl_setlk() races with close(), it removes the created lock with do_lock_file_wait(). However, LSMs can allow the first do_lock_file_wait() that created the lock while denying the second do_lock_file_wait() that tries to remove the lock. Separately, posix_lock_file() could also fail to remove a lock due to GFP_KERNEL allocation failure (when splitting a range in the middle).
After the bug has been triggered, use-after-free reads will occur in lock_get_status() when userspace reads /proc/locks. This can likely be used to read arbitrary kernel memory, but can't corrupt kernel memory.
Fix it by calling locks_remove_posix() instead, which is designed to reliably get rid of POSIX locks associated with the given file and files_struct and is also used by filp_flush().(CVE-2024-41012)
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix kernel bug on rename operation of broken directory
Syzbot reported that in rename directory operation on broken directory on nilfs2, __block_write_begin_int() called to prepare block write may fail BUG_ON check for access exceeding the folio/page size.
This is because nilfs_dotdot(), which gets parent directory reference entry ("..") of the directory to be moved or renamed, does not check consistency enough, and may return location exceeding folio/page size for broken directories.
Fix this issue by checking required directory entries ("." and "..") in the first chunk of the directory in nilfs_dotdot().(CVE-2024-41034)
In the Linux kernel, the following vulnerability has been resolved:
USB: core: Fix duplicate endpoint bug by clearing reserved bits in the descriptor
Syzbot has identified a bug in usbcore (see the Closes: tag below) caused by our assumption that the reserved bits in an endpoint descriptor's bEndpointAddress field will always be 0. As a result of the bug, the endpoint_is_duplicate() routine in config.c (and possibly other routines as well) may believe that two descriptors are for distinct endpoints, even though they have the same direction and endpoint number. This can lead to confusion, including the bug identified by syzbot (two descriptors with matching endpoint numbers and directions, where one was interrupt and the other was bulk).
To fix the bug, we will clear the reserved bits in bEndpointAddress when we parse the descriptor. (Note that both the USB-2.0 and USB-3.1 specs say these bits are "Reserved, reset to zero".) This requires us to make a copy of the descriptor earlier in usb_parse_endpoint() and use the copy instead of the original when checking for duplicates.(CVE-2024-41035)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: prefer nft_chain_validate
nft_chain_validate already performs loop detection because a cycle will result in a call stack overflow (ctx->level >= NFT_JUMP_STACK_SIZE).
It also follows maps via ->validate callback in nft_lookup, so there appears no reason to iterate the maps again.
nf_tables_check_loops() and all its helper functions can be removed. This improves ruleset load time significantly, from 23s down to 12s.
This also fixes a crash bug. Old loop detection code can result in unbounded recursion:
BUG: TASK stack guard page was hit at .... Oops: stack guard page: 0000 [#1] PREEMPT SMP KASAN CPU: 4 PID: 1539 Comm: nft Not tainted 6.10.0-rc5+ #1 [..]
with a suitable ruleset during validation of register stores.
I can't see any actual reason to attempt to check for this from nft_validate_register_store(), at this point the transaction is still in progress, so we don't have a full picture of the rule graph.
For nf-next it might make sense to either remove it or make this depend on table->validate_state in case we could catch an error earlier (for improved error reporting to userspace).(CVE-2024-41042)
In the Linux kernel, the following vulnerability has been resolved:
net: ethernet: lantiq_etop: fix double free in detach
The number of the currently released descriptor is never incremented which results in the same skb being released multiple times.(CVE-2024-41046)
In the Linux kernel, the following vulnerability has been resolved:
powerpc/pseries: Whitelist dtl slub object for copying to userspace
Reading the dispatch trace log from /sys/kernel/debug/powerpc/dtl/cpu-* results in a BUG() when the config CONFIG_HARDENED_USERCOPY is enabled as shown below.
kernel BUG at mm/usercopy.c:102!
Oops: Exception in kernel mode, sig: 5 [#1]
LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries
Modules linked in: xfs libcrc32c dm_service_time sd_mod t10_pi sg ibmvfc
scsi_transport_fc ibmveth pseries_wdt dm_multipath dm_mirror dm_region_hash dm_log dm_mod fuse
CPU: 27 PID: 1815 Comm: python3 Not tainted 6.10.0-rc3 #85
Hardware name: IBM,9040-MRX POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1060.00 (NM1060_042) hv:phyp pSeries
NIP: c0000000005d23d4 LR: c0000000005d23d0 CTR: 00000000006ee6f8
REGS: c000000120c078c0 TRAP: 0700 Not tainted (6.10.0-rc3)
MSR: 8000000000029033 <SF,EE,ME,IR,DR,RI,LE> CR: 2828220f XER: 0000000e
CFAR: c0000000001fdc80 IRQMASK: 0
[ ... GPRs omitted ... ]
NIP [c0000000005d23d4] usercopy_abort+0x78/0xb0
LR [c0000000005d23d0] usercopy_abort+0x74/0xb0
Call Trace:
usercopy_abort+0x74/0xb0 (unreliable)
__check_heap_object+0xf8/0x120
check_heap_object+0x218/0x240
__check_object_size+0x84/0x1a4
dtl_file_read+0x17c/0x2c4
full_proxy_read+0x8c/0x110
vfs_read+0xdc/0x3a0
ksys_read+0x84/0x144
system_call_exception+0x124/0x330
system_call_vectored_common+0x15c/0x2ec
--- interrupt: 3000 at 0x7fff81f3ab34
Commit 6d07d1cd300f ("usercopy: Restrict non-usercopy caches to size 0") requires that only whitelisted areas in slab/slub objects can be copied to userspace when usercopy hardening is enabled using CONFIG_HARDENED_USERCOPY. Dtl contains hypervisor dispatch events which are expected to be read by privileged users. Hence mark this safe for user access. Specify useroffset=0 and usersize=DISPATCH_LOG_BYTES to whitelist the entire object.(CVE-2024-41065)
In the Linux kernel, the following vulnerability has been resolved:
btrfs: qgroup: fix quota root leak after quota disable failure
If during the quota disable we fail when cleaning the quota tree or when deleting the root from the root tree, we jump to the 'out' label without ever dropping the reference on the quota root, resulting in a leak of the root since fs_info->quota_root is no longer pointing to the root (we have set it to NULL just before those steps).
Fix this by always doing a btrfs_put_root() call under the 'out' label. This is a problem that exists since qgroups were first added in 2012 by commit bed92eae26cc ("Btrfs: qgroup implementation and prototypes"), but back then we missed a kfree on the quota root and free_extent_buffer() calls on its root and commit root nodes, since back then roots were not yet reference counted.(CVE-2024-41078)
In the Linux kernel, the following vulnerability has been resolved:
drm/i915/gt: Fix potential UAF by revoke of fence registers
CI has been sporadically reporting the following issue triggered by igt@i915_selftest@live@hangcheck on ADL-P and similar machines:
<6> [414.049203] i915: Running intel_hangcheck_live_selftests/igt_reset_evict_fence ... <6> [414.068804] i915 0000:00:02.0: [drm] GT0: GUC: submission enabled <6> [414.068812] i915 0000:00:02.0: [drm] GT0: GUC: SLPC enabled <3> [414.070354] Unable to pin Y-tiled fence; err:-4 <3> [414.071282] i915_vma_revoke_fence:301 GEM_BUG_ON(!i915_active_is_idle(&fence->active)) ... <4>[ 609.603992] ------------[ cut here ]------------ <2>[ 609.603995] kernel BUG at drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c:301! <4>[ 609.604003] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI <4>[ 609.604006] CPU: 0 PID: 268 Comm: kworker/u64:3 Tainted: G U W 6.9.0-CI_DRM_14785-g1ba62f8cea9c+ #1 <4>[ 609.604008] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023 <4>[ 609.604010] Workqueue: i915 __i915_gem_free_work [i915] <4>[ 609.604149] RIP: 0010:i915_vma_revoke_fence+0x187/0x1f0 [i915] ... <4>[ 609.604271] Call Trace: <4>[ 609.604273] <TASK> ... <4>[ 609.604716] __i915_vma_evict+0x2e9/0x550 [i915] <4>[ 609.604852] __i915_vma_unbind+0x7c/0x160 [i915] <4>[ 609.604977] force_unbind+0x24/0xa0 [i915] <4>[ 609.605098] i915_vma_destroy+0x2f/0xa0 [i915] <4>[ 609.605210] __i915_gem_object_pages_fini+0x51/0x2f0 [i915] <4>[ 609.605330] __i915_gem_free_objects.isra.0+0x6a/0xc0 [i915] <4>[ 609.605440] process_scheduled_works+0x351/0x690 ...
In the past, there were similar failures reported by CI from other IGT tests, observed on other platforms.
Before commit 63baf4f3d587 ("drm/i915/gt: Only wait for GPU activity before unbinding a GGTT fence"), i915_vma_revoke_fence() was waiting for idleness of vma->active via fence_update(). That commit introduced vma->fence->active in order for the fence_update() to be able to wait selectively on that one instead of vma->active since only idleness of fence registers was needed. But then, another commit 0d86ee35097a ("drm/i915/gt: Make fence revocation unequivocal") replaced the call to fence_update() in i915_vma_revoke_fence() with only fence_write(), and also added that GEM_BUG_ON(!i915_active_is_idle(&fence->active)) in front. No justification was provided on why we might then expect idleness of vma->fence->active without first waiting on it.
The issue can be potentially caused by a race among revocation of fence registers on one side and sequential execution of signal callbacks invoked on completion of a request that was using them on the other, still processed in parallel to revocation of those fence registers. Fix it by waiting for idleness of vma->fence->active in i915_vma_revoke_fence().
(cherry picked from commit 24bb052d3dd499c5956abad5f7d8e4fd07da7fb1)(CVE-2024-41092)
In the Linux kernel, the following vulnerability has been resolved:
drm/panel: ilitek-ili9881c: Fix warning with GPIO controllers that sleep
The ilitek-ili9881c controls the reset GPIO using the non-sleeping gpiod_set_value() function. This complains loudly when the GPIO controller needs to sleep. As the caller can sleep, use gpiod_set_value_cansleep() to fix the issue.(CVE-2024-42087)
In the Linux kernel, the following vulnerability has been resolved:
serial: 8250_omap: Implementation of Errata i2310
As per Errata i2310[0], Erroneous timeout can be triggered, if this Erroneous interrupt is not cleared then it may leads to storm of interrupts, therefore apply Errata i2310 solution.
[0] https://www.ti.com/lit/pdf/sprz536 page 23(CVE-2024-42095)
In the Linux kernel, the following vulnerability has been resolved:
x86: stop playing stack games in profile_pc()
The 'profile_pc()' function is used for timer-based profiling, which isn't really all that relevant any more to begin with, but it also ends up making assumptions based on the stack layout that aren't necessarily valid.
Basically, the code tries to account the time spent in spinlocks to the caller rather than the spinlock, and while I support that as a concept, it's not worth the code complexity or the KASAN warnings when no serious profiling is done using timers anyway these days.
And the code really does depend on stack layout that is only true in the simplest of cases. We've lost the comment at some point (I think when the 32-bit and 64-bit code was unified), but it used to say:
Assume the lock function has either no stack frame or a copy
of eflags from PUSHF.
which explains why it just blindly loads a word or two straight off the stack pointer and then takes a minimal look at the values to just check if they might be eflags or the return pc:
Eflags always has bits 22 and up cleared unlike kernel addresses
but that basic stack layout assumption assumes that there isn't any lock debugging etc going on that would complicate the code and cause a stack frame.
It causes KASAN unhappiness reported for years by syzkaller [1] and others [2].
With no real practical reason for this any more, just remove the code.
Just for historical interest, here's some background commits relating to this code from 2006:
0cb91a229364 ("i386: Account spinlocks to the caller during profiling for !FP kernels") 31679f38d886 ("Simplify profile_pc on x86-64")
and a code unification from 2009:
ef4512882dbe ("x86: time_32/64.c unify profile_pc")
but the basics of this thing actually goes back to before the git tree.(CVE-2024-42096)
In the Linux kernel, the following vulnerability has been resolved:
crypto: ecdh - explicitly zeroize private_key
private_key is overwritten with the key parameter passed in by the caller (if present), or alternatively a newly generated private key. However, it is possible that the caller provides a key (or the newly generated key) which is shorter than the previous key. In that scenario, some key material from the previous key would not be overwritten. The easiest solution is to explicitly zeroize the entire private_key array first.
Note that this patch slightly changes the behavior of this function: previously, if the ecc_gen_privkey failed, the old private_key would remain. Now, the private_key is always zeroized. This behavior is consistent with the case where params.key is set and ecc_is_key_valid fails.(CVE-2024-42098)
In the Linux kernel, the following vulnerability has been resolved:
Revert "mm/writeback: fix possible divide-by-zero in wb_dirty_limits(), again"
Patch series "mm: Avoid possible overflows in dirty throttling".
Dirty throttling logic assumes dirty limits in page units fit into 32-bits. This patch series makes sure this is true (see patch 2/2 for more details).
This patch (of 2):
This reverts commit 9319b647902cbd5cc884ac08a8a6d54ce111fc78.
The commit is broken in several ways. Firstly, the removed (u64) cast from the multiplication will introduce a multiplication overflow on 32-bit archs if wb_thresh * bg_thresh >= 1<<32 (which is actually common - the default settings with 4GB of RAM will trigger this). Secondly, the div64_u64() is unnecessarily expensive on 32-bit archs. We have div64_ul() in case we want to be safe & cheap. Thirdly, if dirty thresholds are larger than 1<<32 pages, then dirty balancing is going to blow up in many other spectacular ways anyway so trying to fix one possible overflow is just moot.(CVE-2024-42102)
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix inode number range checks
Patch series "nilfs2: fix potential issues related to reserved inodes".
This series fixes one use-after-free issue reported by syzbot, caused by nilfs2's internal inode being exposed in the namespace on a corrupted filesystem, and a couple of flaws that cause problems if the starting number of non-reserved inodes written in the on-disk super block is intentionally (or corruptly) changed from its default value.
This patch (of 3):
In the current implementation of nilfs2, "nilfs->ns_first_ino", which gives the first non-reserved inode number, is read from the superblock, but its lower limit is not checked.
As a result, if a number that overlaps with the inode number range of reserved inodes such as the root directory or metadata files is set in the super block parameter, the inode number test macros (NILFS_MDT_INODE and NILFS_VALID_INODE) will not function properly.
In addition, these test macros use left bit-shift calculations using with the inode number as the shift count via the BIT macro, but the result of a shift calculation that exceeds the bit width of an integer is undefined in the C specification, so if "ns_first_ino" is set to a large value other than the default value NILFS_USER_INO (=11), the macros may potentially malfunction depending on the environment.
Fix these issues by checking the lower bound of "nilfs->ns_first_ino" and by preventing bit shifts equal to or greater than the NILFS_USER_INO constant in the inode number test macros.
Also, change the type of "ns_first_ino" from signed integer to unsigned integer to avoid the need for type casting in comparisons such as the lower bound check introduced this time.(CVE-2024-42105)
In the Linux kernel, the following vulnerability has been resolved:
wifi: cfg80211: restrict NL80211_ATTR_TXQ_QUANTUM values
syzbot is able to trigger softlockups, setting NL80211_ATTR_TXQ_QUANTUM to 2^31.
We had a similar issue in sch_fq, fixed with commit d9e15a273306 ("pkt_sched: fq: do not accept silly TCA_FQ_QUANTUM")
watchdog: BUG: soft lockup - CPU#1 stuck for 26s! [kworker/1:0:24] Modules linked in: irq event stamp: 131135 hardirqs last enabled at (131134): [<ffff80008ae8778c>] __exit_to_kernel_mode arch/arm64/kernel/entry-common.c:85 [inline] hardirqs last enabled at (131134): [<ffff80008ae8778c>] exit_to_kernel_mode+0xdc/0x10c arch/arm64/kernel/entry-common.c:95 hardirqs last disabled at (131135): [<ffff80008ae85378>] __el1_irq arch/arm64/kernel/entry-common.c:533 [inline] hardirqs last disabled at (131135): [<ffff80008ae85378>] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551 softirqs last enabled at (125892): [<ffff80008907e82c>] neigh_hh_init net/core/neighbour.c:1538 [inline] softirqs last enabled at (125892): [<ffff80008907e82c>] neigh_resolve_output+0x268/0x658 net/core/neighbour.c:1553 softirqs last disabled at (125896): [<ffff80008904166c>] local_bh_disable+0x10/0x34 include/linux/bottom_half.h:19 CPU: 1 PID: 24 Comm: kworker/1:0 Not tainted 6.9.0-rc7-syzkaller-gfda5695d692c #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 Workqueue: mld mld_ifc_work pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __list_del include/linux/list.h:195 [inline] pc : __list_del_entry include/linux/list.h:218 [inline] pc : list_move_tail include/linux/list.h:310 [inline] pc : fq_tin_dequeue include/net/fq_impl.h:112 [inline] pc : ieee80211_tx_dequeue+0x6b8/0x3b4c net/mac80211/tx.c:3854 lr : __list_del_entry include/linux/list.h:218 [inline] lr : list_move_tail include/linux/list.h:310 [inline] lr : fq_tin_dequeue include/net/fq_impl.h:112 [inline] lr : ieee80211_tx_dequeue+0x67c/0x3b4c net/mac80211/tx.c:3854 sp : ffff800093d36700 x29: ffff800093d36a60 x28: ffff800093d36960 x27: dfff800000000000 x26: ffff0000d800ad50 x25: ffff0000d800abe0 x24: ffff0000d800abf0 x23: ffff0000e0032468 x22: ffff0000e00324d4 x21: ffff0000d800abf0 x20: ffff0000d800abf8 x19: ffff0000d800abf0 x18: ffff800093d363c0 x17: 000000000000d476 x16: ffff8000805519dc x15: ffff7000127a6cc8 x14: 1ffff000127a6cc8 x13: 0000000000000004 x12: ffffffffffffffff x11: ffff7000127a6cc8 x10: 0000000000ff0100 x9 : 0000000000000000 x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 x5 : ffff80009287aa08 x4 : 0000000000000008 x3 : ffff80008034c7fc x2 : ffff0000e0032468 x1 : 00000000da0e46b8 x0 : ffff0000e0032470 Call trace: __list_del include/linux/list.h:195 [inline] __list_del_entry include/linux/list.h:218 [inline] list_move_tail include/linux/list.h:310 [inline] fq_tin_dequeue include/net/fq_impl.h:112 [inline] ieee80211_tx_dequeue+0x6b8/0x3b4c net/mac80211/tx.c:3854 wake_tx_push_queue net/mac80211/util.c:294 [inline] ieee80211_handle_wake_tx_queue+0x118/0x274 net/mac80211/util.c:315 drv_wake_tx_queue net/mac80211/driver-ops.h:1350 [inline] schedule_and_wake_txq net/mac80211/driver-ops.h:1357 [inline] ieee80211_queue_skb+0x18e8/0x2244 net/mac80211/tx.c:1664 ieee80211_tx+0x260/0x400 net/mac80211/tx.c:1966 ieee80211_xmit+0x278/0x354 net/mac80211/tx.c:2062 __ieee80211_subif_start_xmit+0xab8/0x122c net/mac80211/tx.c:4338 ieee80211_subif_start_xmit+0xe0/0x438 net/mac80211/tx.c:4532 __netdev_start_xmit include/linux/netdevice.h:4903 [inline] netdev_start_xmit include/linux/netdevice.h:4917 [inline] xmit_one net/core/dev.c:3531 [inline] dev_hard_start_xmit+0x27c/0x938 net/core/dev.c:3547 __dev_queue_xmit+0x1678/0x33fc net/core/dev.c:4341 dev_queue_xmit include/linux/netdevice.h:3091 [inline] neigh_resolve_output+0x558/0x658 net/core/neighbour.c:1563 neigh_output include/net/neighbour.h:542 [inline] ip6_fini ---truncated---(CVE-2024-42114)
In the Linux kernel, the following vulnerability has been resolved:
leds: an30259a: Use devm_mutex_init() for mutex initialization
In this driver LEDs are registered using devm_led_classdev_register() so they are automatically unregistered after module's remove() is done. led_classdev_unregister() calls module's led_set_brightness() to turn off the LEDs and that callback uses mutex which was destroyed already in module's remove() so use devm API instead.(CVE-2024-42128)
In the Linux kernel, the following vulnerability has been resolved:
orangefs: fix out-of-bounds fsid access
Arnd Bergmann sent a patch to fsdevel, he says:
"orangefs_statfs() copies two consecutive fields of the superblock into the statfs structure, which triggers a warning from the string fortification helpers"
Jan Kara suggested an alternate way to do the patch to make it more readable.
I ran both ideas through xfstests and both seem fine. This patch is based on Jan Kara's suggestion.(CVE-2024-42143)
In the Linux kernel, the following vulnerability has been resolved:
bnx2x: Fix multiple UBSAN array-index-out-of-bounds
Fix UBSAN warnings that occur when using a system with 32 physical cpu cores or more, or when the user defines a number of Ethernet queues greater than or equal to FP_SB_MAX_E1x using the num_queues module parameter.
Currently there is a read/write out of bounds that occurs on the array "struct stats_query_entry query" present inside the "bnx2x_fw_stats_req" struct in "drivers/net/ethernet/broadcom/bnx2x/bnx2x.h". Looking at the definition of the "struct stats_query_entry query" array:
struct stats_query_entry query[FP_SB_MAX_E1x+ BNX2X_FIRST_QUEUE_QUERY_IDX];
FP_SB_MAX_E1x is defined as the maximum number of fast path interrupts and has a value of 16, while BNX2X_FIRST_QUEUE_QUERY_IDX has a value of 3 meaning the array has a total size of 19. Since accesses to "struct stats_query_entry query" are offset-ted by BNX2X_FIRST_QUEUE_QUERY_IDX, that means that the total number of Ethernet queues should not exceed FP_SB_MAX_E1x (16). However one of these queues is reserved for FCOE and thus the number of Ethernet queues should be set to [FP_SB_MAX_E1x -1] (15) if FCOE is enabled or [FP_SB_MAX_E1x] (16) if it is not.
This is also described in a comment in the source code in drivers/net/ethernet/broadcom/bnx2x/bnx2x.h just above the Macro definition of FP_SB_MAX_E1x. Below is the part of this explanation that it important for this patch
/ * The total number of L2 queues, MSIX vectors and HW contexts (CIDs) is * control by the number of fast-path status blocks supported by the * device (HW/FW). Each fast-path status block (FP-SB) aka non-default * status block represents an independent interrupts context that can * serve a regular L2 networking queue. However special L2 queues such * as the FCoE queue do not require a FP-SB and other components like * the CNIC may consume FP-SB reducing the number of possible L2 queues * * If the maximum number of FP-SB available is X then: * a. If CNIC is supported it consumes 1 FP-SB thus the max number of * regular L2 queues is Y=X-1 * b. In MF mode the actual number of L2 queues is Y= (X-1/MF_factor) * c. If the FCoE L2 queue is supported the actual number of L2 queues * is Y+1 * d. The number of irqs (MSIX vectors) is either Y+1 (one extra for * slow-path interrupts) or Y+2 if CNIC is supported (one additional * FP interrupt context for the CNIC). * e. The number of HW context (CID count) is always X or X+1 if FCoE * L2 queue is supported. The cid for the FCoE L2 queue is always X. /
However this driver also supports NICs that use the E2 controller which can handle more queues due to having more FP-SB represented by FP_SB_MAX_E2. Looking at the commits when the E2 support was added, it was originally using the E1x parameters: commit f2e0899f0f27 ("bnx2x: Add 57712 support"). Back then FP_SB_MAX_E2 was set to 16 the same as E1x. However the driver was later updated to take full advantage of the E2 instead of having it be limited to the capabilities of the E1x. But as far as we can tell, the array "stats_query_entry query" was still limited to using the FP-SB available to the E1x cards as part of an oversignt when the driver was updated to take full advantage of the E2, and now with the driver being aware of the greater queue size supported by E2 NICs, it causes the UBSAN warnings seen in the stack traces below.
This patch increases the size of the "stats_query_entry query" array by replacing FP_SB_MAX_E1x with FP_SB_MAX_E2 to be large enough to handle both types of NICs.
Stack traces:
UBSAN: array-index-out-of-bounds in drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.c:1529:11 index 20 is out of range for type 'stats_query_entry [19]' CPU: 12 PID: 858 Comm: systemd-network Not tainted 6.9.0-060900rc7-generic #202405052133 Hardware name: HP ProLiant DL360 Gen9/ProLiant DL360 ---truncated---(CVE-2024-42148)
In the Linux kernel, the following vulnerability has been resolved:
tcp_metrics: validate source addr length
I don't see anything checking that TCP_METRICS_ATTR_SADDR_IPV4 is at least 4 bytes long, and the policy doesn't have an entry for this attribute at all (neither does it for IPv6 but v6 is manually validated).(CVE-2024-42154)
In the Linux kernel, the following vulnerability has been resolved:
s390/pkey: Wipe copies of clear-key structures on failure
Wipe all sensitive data from stack for all IOCTLs, which convert a clear-key into a protected- or secure-key.(CVE-2024-42156)
In the Linux kernel, the following vulnerability has been resolved:
s390/pkey: Wipe sensitive data on failure
Wipe sensitive data from stack also if the copy_to_user() fails.(CVE-2024-42157)
In the Linux kernel, the following vulnerability has been resolved:
media: dvb-frontends: tda10048: Fix integer overflow
state->xtal_hz can be up to 16M, so it can overflow a 32 bit integer when multiplied by pll_mfactor.
Create a new 64 bit variable to hold the calculations.(CVE-2024-42223)
In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: replace skb_put with skb_put_zero
Avoid potentially reusing uninitialized data(CVE-2024-42225)
In the Linux kernel, the following vulnerability has been resolved:
crypto: aead,cipher - zeroize key buffer after use
I.G 9.7.B for FIPS 140-3 specifies that variables temporarily holding cryptographic information should be zeroized once they are no longer needed. Accomplish this by using kfree_sensitive for buffers that previously held the private key.(CVE-2024-42229)
In the Linux kernel, the following vulnerability has been resolved:
USB: serial: mos7840: fix crash on resume
Since commit c49cfa917025 ("USB: serial: use generic method if no alternative is provided in usb serial layer"), USB serial core calls the generic resume implementation when the driver has not provided one.
This can trigger a crash on resume with mos7840 since support for multiple read URBs was added back in 2011. Specifically, both port read URBs are now submitted on resume for open ports, but the context pointer of the second URB is left set to the core rather than mos7840 port structure.
Fix this by implementing dedicated suspend and resume functions for mos7840.
Tested with Delock 87414 USB 2.0 to 4x serial adapter.
In the Linux kernel, the following vulnerability has been resolved:
net, sunrpc: Remap EPERM in case of connection failure in xs_tcp_setup_socket
When using a BPF program on kernel_connect(), the call can return -EPERM. This causes xs_tcp_setup_socket() to loop forever, filling up the syslog and causing the kernel to potentially freeze up.
Neil suggested:
This will propagate -EPERM up into other layers which might not be ready to handle it. It might be safer to map EPERM to an error we would be more likely to expect from the network system - such as ECONNREFUSED or ENETDOWN.
ECONNREFUSED as error seems reasonable. For programs setting a different error can be out of reach (see handling in 4fbac77d2d09) in particular on kernels which do not have f10d05966196 ("bpf: Make BPF_PROG_RUN_ARRAY return -err instead of allow boolean"), thus given that it is better to simply remap for consistent behavior. UDP does handle EPERM in xs_udp_send_request().(CVE-2024-42246)
In the Linux kernel, the following vulnerability has been resolved:
wireguard: allowedips: avoid unaligned 64-bit memory accesses
On the parisc platform, the kernel issues kernel warnings because swap_endian() tries to load a 128-bit IPv6 address from an unaligned memory location:
Kernel: unaligned access to 0x55f4688c in wg_allowedips_insert_v6+0x2c/0x80 [wireguard] (iir 0xf3010df) Kernel: unaligned access to 0x55f46884 in wg_allowedips_insert_v6+0x38/0x80 [wireguard] (iir 0xf2010dc)
Avoid such unaligned memory accesses by instead using the get_unaligned_be64() helper macro.
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"kernel-5.10.0-136.89.0.170.oe2203sp1.aarch64.rpm",
"kernel-debuginfo-5.10.0-136.89.0.170.oe2203sp1.aarch64.rpm",
"kernel-debugsource-5.10.0-136.89.0.170.oe2203sp1.aarch64.rpm",
"kernel-devel-5.10.0-136.89.0.170.oe2203sp1.aarch64.rpm",
"kernel-headers-5.10.0-136.89.0.170.oe2203sp1.aarch64.rpm",
"kernel-source-5.10.0-136.89.0.170.oe2203sp1.aarch64.rpm",
"kernel-tools-5.10.0-136.89.0.170.oe2203sp1.aarch64.rpm",
"kernel-tools-debuginfo-5.10.0-136.89.0.170.oe2203sp1.aarch64.rpm",
"kernel-tools-devel-5.10.0-136.89.0.170.oe2203sp1.aarch64.rpm",
"perf-5.10.0-136.89.0.170.oe2203sp1.aarch64.rpm",
"perf-debuginfo-5.10.0-136.89.0.170.oe2203sp1.aarch64.rpm",
"python3-perf-5.10.0-136.89.0.170.oe2203sp1.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-136.89.0.170.oe2203sp1.aarch64.rpm"
],
"src": [
"kernel-5.10.0-136.89.0.170.oe2203sp1.src.rpm"
],
"x86_64": [
"kernel-5.10.0-136.89.0.170.oe2203sp1.x86_64.rpm",
"kernel-debuginfo-5.10.0-136.89.0.170.oe2203sp1.x86_64.rpm",
"kernel-debugsource-5.10.0-136.89.0.170.oe2203sp1.x86_64.rpm",
"kernel-devel-5.10.0-136.89.0.170.oe2203sp1.x86_64.rpm",
"kernel-headers-5.10.0-136.89.0.170.oe2203sp1.x86_64.rpm",
"kernel-source-5.10.0-136.89.0.170.oe2203sp1.x86_64.rpm",
"kernel-tools-5.10.0-136.89.0.170.oe2203sp1.x86_64.rpm",
"kernel-tools-debuginfo-5.10.0-136.89.0.170.oe2203sp1.x86_64.rpm",
"kernel-tools-devel-5.10.0-136.89.0.170.oe2203sp1.x86_64.rpm",
"perf-5.10.0-136.89.0.170.oe2203sp1.x86_64.rpm",
"perf-debuginfo-5.10.0-136.89.0.170.oe2203sp1.x86_64.rpm",
"python3-perf-5.10.0-136.89.0.170.oe2203sp1.x86_64.rpm",
"python3-perf-debuginfo-5.10.0-136.89.0.170.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.89.0.170.oe2203sp1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nUSB: core: Make do_proc_control() and do_proc_bulk() killable\r\n\r\nThe USBDEVFS_CONTROL and USBDEVFS_BULK ioctls invoke\nusb_start_wait_urb(), which contains an uninterruptible wait with a\nuser-specified timeout value. If timeout value is very large and the\ndevice being accessed does not respond in a reasonable amount of time,\nthe kernel will complain about \u0026quot;Task X blocked for more than N\nseconds\u0026quot;, as found in testing by syzbot:\r\n\r\nINFO: task syz-executor.0:8700 blocked for more than 143 seconds.\n Not tainted 5.14.0-rc7-syzkaller #0\n\u0026quot;echo 0 \u0026gt; /proc/sys/kernel/hung_task_timeout_secs\u0026quot; disables this message.\ntask:syz-executor.0 state:D stack:23192 pid: 8700 ppid: 8455 flags:0x00004004\nCall Trace:\n context_switch kernel/sched/core.c:4681 [inline]\n __schedule+0xc07/0x11f0 kernel/sched/core.c:5938\n schedule+0x14b/0x210 kernel/sched/core.c:6017\n schedule_timeout+0x98/0x2f0 kernel/time/timer.c:1857\n do_wait_for_common+0x2da/0x480 kernel/sched/completion.c:85\n __wait_for_common kernel/sched/completion.c:106 [inline]\n wait_for_common kernel/sched/completion.c:117 [inline]\n wait_for_completion_timeout+0x46/0x60 kernel/sched/completion.c:157\n usb_start_wait_urb+0x167/0x550 drivers/usb/core/message.c:63\n do_proc_bulk+0x978/0x1080 drivers/usb/core/devio.c:1236\n proc_bulk drivers/usb/core/devio.c:1273 [inline]\n usbdev_do_ioctl drivers/usb/core/devio.c:2547 [inline]\n usbdev_ioctl+0x3441/0x6b10 drivers/usb/core/devio.c:2713\n...\r\n\r\nTo fix this problem, this patch replaces usbfs\u0026apos;s calls to\nusb_control_msg() and usb_bulk_msg() with special-purpose code that\ndoes essentially the same thing (as recommended in the comment for\nusb_start_wait_urb()), except that it always uses a killable wait and\nit uses GFP_KERNEL rather than GFP_NOIO.(CVE-2021-47582)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nNFSD: Fix the behavior of READ near OFFSET_MAX\r\n\r\nDan Aloni reports:\n\u0026gt; Due to commit 8cfb9015280d (\u0026quot;NFS: Always provide aligned buffers to\n\u0026gt; the RPC read layers\u0026quot;) on the client, a read of 0xfff is aligned up\n\u0026gt; to server rsize of 0x1000.\n\u0026gt;\n\u0026gt; As a result, in a test where the server has a file of size\n\u0026gt; 0x7fffffffffffffff, and the client tries to read from the offset\n\u0026gt; 0x7ffffffffffff000, the read causes loff_t overflow in the server\n\u0026gt; and it returns an NFS code of EINVAL to the client. The client as\n\u0026gt; a result indefinitely retries the request.\r\n\r\nThe Linux NFS client does not handle NFS?ERR_INVAL, even though all\nNFS specifications permit servers to return that status code for a\nREAD.\r\n\r\nInstead of NFS?ERR_INVAL, have out-of-range READ requests succeed\nand return a short result. Set the EOF flag in the result to prevent\nthe client from retrying the READ request. This behavior appears to\nbe consistent with Solaris NFS servers.\r\n\r\nNote that NFSv3 and NFSv4 use u64 offset values on the wire. These\nmust be converted to loff_t internally before use -- an implicit\ntype cast is not adequate for this purpose. Otherwise VFS checks\nagainst sb-\u0026gt;s_maxbytes do not work properly.(CVE-2022-48827)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: mediatek: vcodec: Only free buffer VA that is not NULL\r\n\r\nIn the MediaTek vcodec driver, while mtk_vcodec_mem_free() is mostly\ncalled only when the buffer to free exists, there are some instances\nthat didn\u0026apos;t do the check and triggered warnings in practice.\r\n\r\nWe believe those checks were forgotten unintentionally. Add the checks\nback to fix the warnings.(CVE-2023-52888)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nHID: core: remove unnecessary WARN_ON() in implement()\r\n\r\nSyzkaller hit a warning [1] in a call to implement() when trying\nto write a value into a field of smaller size in an output report.\r\n\r\nSince implement() already has a warn message printed out with the\nhelp of hid_warn() and value in question gets trimmed with:\n\t...\n\tvalue \u0026amp;= m;\n\t...\nWARN_ON may be considered superfluous. Remove it to suppress future\nsyzkaller triggers.\r\n\r\n[1]\nWARNING: CPU: 0 PID: 5084 at drivers/hid/hid-core.c:1451 implement drivers/hid/hid-core.c:1451 [inline]\nWARNING: CPU: 0 PID: 5084 at drivers/hid/hid-core.c:1451 hid_output_report+0x548/0x760 drivers/hid/hid-core.c:1863\nModules linked in:\nCPU: 0 PID: 5084 Comm: syz-executor424 Not tainted 6.9.0-rc7-syzkaller-00183-gcf87f46fd34d #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024\nRIP: 0010:implement drivers/hid/hid-core.c:1451 [inline]\nRIP: 0010:hid_output_report+0x548/0x760 drivers/hid/hid-core.c:1863\n...\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __usbhid_submit_report drivers/hid/usbhid/hid-core.c:591 [inline]\n usbhid_submit_report+0x43d/0x9e0 drivers/hid/usbhid/hid-core.c:636\n hiddev_ioctl+0x138b/0x1f00 drivers/hid/usbhid/hiddev.c:726\n vfs_ioctl fs/ioctl.c:51 [inline]\n __do_sys_ioctl fs/ioctl.c:904 [inline]\n __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:890\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n...(CVE-2024-39509)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: mac80211: mesh: Fix leak of mesh_preq_queue objects\r\n\r\nThe hwmp code use objects of type mesh_preq_queue, added to a list in\nieee80211_if_mesh, to keep track of mpath we need to resolve. If the mpath\ngets deleted, ex mesh interface is removed, the entries in that list will\nnever get cleaned. Fix this by flushing all corresponding items of the\npreq_queue in mesh_path_flush_pending().\r\n\r\nThis should take care of KASAN reports like this:\r\n\r\nunreferenced object 0xffff00000668d800 (size 128):\n comm \u0026quot;kworker/u8:4\u0026quot;, pid 67, jiffies 4295419552 (age 1836.444s)\n hex dump (first 32 bytes):\n 00 1f 05 09 00 00 ff ff 00 d5 68 06 00 00 ff ff ..........h.....\n 8e 97 ea eb 3e b8 01 00 00 00 00 00 00 00 00 00 ....\u0026gt;...........\n backtrace:\n [\u0026lt;000000007302a0b6\u0026gt;] __kmem_cache_alloc_node+0x1e0/0x35c\n [\u0026lt;00000000049bd418\u0026gt;] kmalloc_trace+0x34/0x80\n [\u0026lt;0000000000d792bb\u0026gt;] mesh_queue_preq+0x44/0x2a8\n [\u0026lt;00000000c99c3696\u0026gt;] mesh_nexthop_resolve+0x198/0x19c\n [\u0026lt;00000000926bf598\u0026gt;] ieee80211_xmit+0x1d0/0x1f4\n [\u0026lt;00000000fc8c2284\u0026gt;] __ieee80211_subif_start_xmit+0x30c/0x764\n [\u0026lt;000000005926ee38\u0026gt;] ieee80211_subif_start_xmit+0x9c/0x7a4\n [\u0026lt;000000004c86e916\u0026gt;] dev_hard_start_xmit+0x174/0x440\n [\u0026lt;0000000023495647\u0026gt;] __dev_queue_xmit+0xe24/0x111c\n [\u0026lt;00000000cfe9ca78\u0026gt;] batadv_send_skb_packet+0x180/0x1e4\n [\u0026lt;000000007bacc5d5\u0026gt;] batadv_v_elp_periodic_work+0x2f4/0x508\n [\u0026lt;00000000adc3cd94\u0026gt;] process_one_work+0x4b8/0xa1c\n [\u0026lt;00000000b36425d1\u0026gt;] worker_thread+0x9c/0x634\n [\u0026lt;0000000005852dd5\u0026gt;] kthread+0x1bc/0x1c4\n [\u0026lt;000000005fccd770\u0026gt;] ret_from_fork+0x10/0x20\nunreferenced object 0xffff000009051f00 (size 128):\n comm \u0026quot;kworker/u8:4\u0026quot;, pid 67, jiffies 4295419553 (age 1836.440s)\n hex dump (first 32 bytes):\n 90 d6 92 0d 00 00 ff ff 00 d8 68 06 00 00 ff ff ..........h.....\n 36 27 92 e4 02 e0 01 00 00 58 79 06 00 00 ff ff 6\u0026apos;.......Xy.....\n backtrace:\n [\u0026lt;000000007302a0b6\u0026gt;] __kmem_cache_alloc_node+0x1e0/0x35c\n [\u0026lt;00000000049bd418\u0026gt;] kmalloc_trace+0x34/0x80\n [\u0026lt;0000000000d792bb\u0026gt;] mesh_queue_preq+0x44/0x2a8\n [\u0026lt;00000000c99c3696\u0026gt;] mesh_nexthop_resolve+0x198/0x19c\n [\u0026lt;00000000926bf598\u0026gt;] ieee80211_xmit+0x1d0/0x1f4\n [\u0026lt;00000000fc8c2284\u0026gt;] __ieee80211_subif_start_xmit+0x30c/0x764\n [\u0026lt;000000005926ee38\u0026gt;] ieee80211_subif_start_xmit+0x9c/0x7a4\n [\u0026lt;000000004c86e916\u0026gt;] dev_hard_start_xmit+0x174/0x440\n [\u0026lt;0000000023495647\u0026gt;] __dev_queue_xmit+0xe24/0x111c\n [\u0026lt;00000000cfe9ca78\u0026gt;] batadv_send_skb_packet+0x180/0x1e4\n [\u0026lt;000000007bacc5d5\u0026gt;] batadv_v_elp_periodic_work+0x2f4/0x508\n [\u0026lt;00000000adc3cd94\u0026gt;] process_one_work+0x4b8/0xa1c\n [\u0026lt;00000000b36425d1\u0026gt;] worker_thread+0x9c/0x634\n [\u0026lt;0000000005852dd5\u0026gt;] kthread+0x1bc/0x1c4\n [\u0026lt;000000005fccd770\u0026gt;] ret_from_fork+0x10/0x20(CVE-2024-40942)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nRDMA/mlx5: Add check for srq max_sge attribute\r\n\r\nmax_sge attribute is passed by the user, and is inserted and used\nunchecked, so verify that the value doesn\u0026apos;t exceed maximum allowed value\nbefore using it.(CVE-2024-40990)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfilelock: Remove locks reliably when fcntl/close race is detected\r\n\r\nWhen fcntl_setlk() races with close(), it removes the created lock with\ndo_lock_file_wait().\nHowever, LSMs can allow the first do_lock_file_wait() that created the lock\nwhile denying the second do_lock_file_wait() that tries to remove the lock.\nSeparately, posix_lock_file() could also fail to\nremove a lock due to GFP_KERNEL allocation failure (when splitting a range\nin the middle).\r\n\r\nAfter the bug has been triggered, use-after-free reads will occur in\nlock_get_status() when userspace reads /proc/locks. This can likely be used\nto read arbitrary kernel memory, but can\u0026apos;t corrupt kernel memory.\r\n\r\nFix it by calling locks_remove_posix() instead, which is designed to\nreliably get rid of POSIX locks associated with the given file and\nfiles_struct and is also used by filp_flush().(CVE-2024-41012)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: fix kernel bug on rename operation of broken directory\r\n\r\nSyzbot reported that in rename directory operation on broken directory on\nnilfs2, __block_write_begin_int() called to prepare block write may fail\nBUG_ON check for access exceeding the folio/page size.\r\n\r\nThis is because nilfs_dotdot(), which gets parent directory reference\nentry (\u0026quot;..\u0026quot;) of the directory to be moved or renamed, does not check\nconsistency enough, and may return location exceeding folio/page size for\nbroken directories.\r\n\r\nFix this issue by checking required directory entries (\u0026quot;.\u0026quot; and \u0026quot;..\u0026quot;) in\nthe first chunk of the directory in nilfs_dotdot().(CVE-2024-41034)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nUSB: core: Fix duplicate endpoint bug by clearing reserved bits in the descriptor\r\n\r\nSyzbot has identified a bug in usbcore (see the Closes: tag below)\ncaused by our assumption that the reserved bits in an endpoint\ndescriptor\u0026apos;s bEndpointAddress field will always be 0. As a result of\nthe bug, the endpoint_is_duplicate() routine in config.c (and possibly\nother routines as well) may believe that two descriptors are for\ndistinct endpoints, even though they have the same direction and\nendpoint number. This can lead to confusion, including the bug\nidentified by syzbot (two descriptors with matching endpoint numbers\nand directions, where one was interrupt and the other was bulk).\r\n\r\nTo fix the bug, we will clear the reserved bits in bEndpointAddress\nwhen we parse the descriptor. (Note that both the USB-2.0 and USB-3.1\nspecs say these bits are \u0026quot;Reserved, reset to zero\u0026quot;.) This requires us\nto make a copy of the descriptor earlier in usb_parse_endpoint() and\nuse the copy instead of the original when checking for duplicates.(CVE-2024-41035)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nf_tables: prefer nft_chain_validate\r\n\r\nnft_chain_validate already performs loop detection because a cycle will\nresult in a call stack overflow (ctx-\u0026gt;level \u0026gt;= NFT_JUMP_STACK_SIZE).\r\n\r\nIt also follows maps via -\u0026gt;validate callback in nft_lookup, so there\nappears no reason to iterate the maps again.\r\n\r\nnf_tables_check_loops() and all its helper functions can be removed.\nThis improves ruleset load time significantly, from 23s down to 12s.\r\n\r\nThis also fixes a crash bug. Old loop detection code can result in\nunbounded recursion:\r\n\r\nBUG: TASK stack guard page was hit at ....\nOops: stack guard page: 0000 [#1] PREEMPT SMP KASAN\nCPU: 4 PID: 1539 Comm: nft Not tainted 6.10.0-rc5+ #1\n[..]\r\n\r\nwith a suitable ruleset during validation of register stores.\r\n\r\nI can\u0026apos;t see any actual reason to attempt to check for this from\nnft_validate_register_store(), at this point the transaction is still in\nprogress, so we don\u0026apos;t have a full picture of the rule graph.\r\n\r\nFor nf-next it might make sense to either remove it or make this depend\non table-\u0026gt;validate_state in case we could catch an error earlier\n(for improved error reporting to userspace).(CVE-2024-41042)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: ethernet: lantiq_etop: fix double free in detach\r\n\r\nThe number of the currently released descriptor is never incremented\nwhich results in the same skb being released multiple times.(CVE-2024-41046)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npowerpc/pseries: Whitelist dtl slub object for copying to userspace\r\n\r\nReading the dispatch trace log from /sys/kernel/debug/powerpc/dtl/cpu-*\nresults in a BUG() when the config CONFIG_HARDENED_USERCOPY is enabled as\nshown below.\r\n\r\n kernel BUG at mm/usercopy.c:102!\n Oops: Exception in kernel mode, sig: 5 [#1]\n LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries\n Modules linked in: xfs libcrc32c dm_service_time sd_mod t10_pi sg ibmvfc\n scsi_transport_fc ibmveth pseries_wdt dm_multipath dm_mirror dm_region_hash dm_log dm_mod fuse\n CPU: 27 PID: 1815 Comm: python3 Not tainted 6.10.0-rc3 #85\n Hardware name: IBM,9040-MRX POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1060.00 (NM1060_042) hv:phyp pSeries\n NIP: c0000000005d23d4 LR: c0000000005d23d0 CTR: 00000000006ee6f8\n REGS: c000000120c078c0 TRAP: 0700 Not tainted (6.10.0-rc3)\n MSR: 8000000000029033 \u0026lt;SF,EE,ME,IR,DR,RI,LE\u0026gt; CR: 2828220f XER: 0000000e\n CFAR: c0000000001fdc80 IRQMASK: 0\n [ ... GPRs omitted ... ]\n NIP [c0000000005d23d4] usercopy_abort+0x78/0xb0\n LR [c0000000005d23d0] usercopy_abort+0x74/0xb0\n Call Trace:\n usercopy_abort+0x74/0xb0 (unreliable)\n __check_heap_object+0xf8/0x120\n check_heap_object+0x218/0x240\n __check_object_size+0x84/0x1a4\n dtl_file_read+0x17c/0x2c4\n full_proxy_read+0x8c/0x110\n vfs_read+0xdc/0x3a0\n ksys_read+0x84/0x144\n system_call_exception+0x124/0x330\n system_call_vectored_common+0x15c/0x2ec\n --- interrupt: 3000 at 0x7fff81f3ab34\r\n\r\nCommit 6d07d1cd300f (\u0026quot;usercopy: Restrict non-usercopy caches to size 0\u0026quot;)\nrequires that only whitelisted areas in slab/slub objects can be copied to\nuserspace when usercopy hardening is enabled using CONFIG_HARDENED_USERCOPY.\nDtl contains hypervisor dispatch events which are expected to be read by\nprivileged users. Hence mark this safe for user access.\nSpecify useroffset=0 and usersize=DISPATCH_LOG_BYTES to whitelist the\nentire object.(CVE-2024-41065)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: qgroup: fix quota root leak after quota disable failure\r\n\r\nIf during the quota disable we fail when cleaning the quota tree or when\ndeleting the root from the root tree, we jump to the \u0026apos;out\u0026apos; label without\never dropping the reference on the quota root, resulting in a leak of the\nroot since fs_info-\u0026gt;quota_root is no longer pointing to the root (we have\nset it to NULL just before those steps).\r\n\r\nFix this by always doing a btrfs_put_root() call under the \u0026apos;out\u0026apos; label.\nThis is a problem that exists since qgroups were first added in 2012 by\ncommit bed92eae26cc (\u0026quot;Btrfs: qgroup implementation and prototypes\u0026quot;), but\nback then we missed a kfree on the quota root and free_extent_buffer()\ncalls on its root and commit root nodes, since back then roots were not\nyet reference counted.(CVE-2024-41078)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/i915/gt: Fix potential UAF by revoke of fence registers\r\n\r\nCI has been sporadically reporting the following issue triggered by\nigt@i915_selftest@live@hangcheck on ADL-P and similar machines:\r\n\r\n\u0026lt;6\u0026gt; [414.049203] i915: Running intel_hangcheck_live_selftests/igt_reset_evict_fence\n...\n\u0026lt;6\u0026gt; [414.068804] i915 0000:00:02.0: [drm] GT0: GUC: submission enabled\n\u0026lt;6\u0026gt; [414.068812] i915 0000:00:02.0: [drm] GT0: GUC: SLPC enabled\n\u0026lt;3\u0026gt; [414.070354] Unable to pin Y-tiled fence; err:-4\n\u0026lt;3\u0026gt; [414.071282] i915_vma_revoke_fence:301 GEM_BUG_ON(!i915_active_is_idle(\u0026amp;fence-\u0026gt;active))\n...\n\u0026lt;4\u0026gt;[ 609.603992] ------------[ cut here ]------------\n\u0026lt;2\u0026gt;[ 609.603995] kernel BUG at drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c:301!\n\u0026lt;4\u0026gt;[ 609.604003] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI\n\u0026lt;4\u0026gt;[ 609.604006] CPU: 0 PID: 268 Comm: kworker/u64:3 Tainted: G U W 6.9.0-CI_DRM_14785-g1ba62f8cea9c+ #1\n\u0026lt;4\u0026gt;[ 609.604008] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023\n\u0026lt;4\u0026gt;[ 609.604010] Workqueue: i915 __i915_gem_free_work [i915]\n\u0026lt;4\u0026gt;[ 609.604149] RIP: 0010:i915_vma_revoke_fence+0x187/0x1f0 [i915]\n...\n\u0026lt;4\u0026gt;[ 609.604271] Call Trace:\n\u0026lt;4\u0026gt;[ 609.604273] \u0026lt;TASK\u0026gt;\n...\n\u0026lt;4\u0026gt;[ 609.604716] __i915_vma_evict+0x2e9/0x550 [i915]\n\u0026lt;4\u0026gt;[ 609.604852] __i915_vma_unbind+0x7c/0x160 [i915]\n\u0026lt;4\u0026gt;[ 609.604977] force_unbind+0x24/0xa0 [i915]\n\u0026lt;4\u0026gt;[ 609.605098] i915_vma_destroy+0x2f/0xa0 [i915]\n\u0026lt;4\u0026gt;[ 609.605210] __i915_gem_object_pages_fini+0x51/0x2f0 [i915]\n\u0026lt;4\u0026gt;[ 609.605330] __i915_gem_free_objects.isra.0+0x6a/0xc0 [i915]\n\u0026lt;4\u0026gt;[ 609.605440] process_scheduled_works+0x351/0x690\n...\r\n\r\nIn the past, there were similar failures reported by CI from other IGT\ntests, observed on other platforms.\r\n\r\nBefore commit 63baf4f3d587 (\u0026quot;drm/i915/gt: Only wait for GPU activity\nbefore unbinding a GGTT fence\u0026quot;), i915_vma_revoke_fence() was waiting for\nidleness of vma-\u0026gt;active via fence_update(). That commit introduced\nvma-\u0026gt;fence-\u0026gt;active in order for the fence_update() to be able to wait\nselectively on that one instead of vma-\u0026gt;active since only idleness of\nfence registers was needed. But then, another commit 0d86ee35097a\n(\u0026quot;drm/i915/gt: Make fence revocation unequivocal\u0026quot;) replaced the call to\nfence_update() in i915_vma_revoke_fence() with only fence_write(), and\nalso added that GEM_BUG_ON(!i915_active_is_idle(\u0026amp;fence-\u0026gt;active)) in front.\nNo justification was provided on why we might then expect idleness of\nvma-\u0026gt;fence-\u0026gt;active without first waiting on it.\r\n\r\nThe issue can be potentially caused by a race among revocation of fence\nregisters on one side and sequential execution of signal callbacks invoked\non completion of a request that was using them on the other, still\nprocessed in parallel to revocation of those fence registers. Fix it by\nwaiting for idleness of vma-\u0026gt;fence-\u0026gt;active in i915_vma_revoke_fence().\r\n\r\n(cherry picked from commit 24bb052d3dd499c5956abad5f7d8e4fd07da7fb1)(CVE-2024-41092)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/panel: ilitek-ili9881c: Fix warning with GPIO controllers that sleep\r\n\r\nThe ilitek-ili9881c controls the reset GPIO using the non-sleeping\ngpiod_set_value() function. This complains loudly when the GPIO\ncontroller needs to sleep. As the caller can sleep, use\ngpiod_set_value_cansleep() to fix the issue.(CVE-2024-42087)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nserial: 8250_omap: Implementation of Errata i2310\r\n\r\nAs per Errata i2310[0], Erroneous timeout can be triggered,\nif this Erroneous interrupt is not cleared then it may leads\nto storm of interrupts, therefore apply Errata i2310 solution.\r\n\r\n[0] https://www.ti.com/lit/pdf/sprz536 page 23(CVE-2024-42095)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nx86: stop playing stack games in profile_pc()\r\n\r\nThe \u0026apos;profile_pc()\u0026apos; function is used for timer-based profiling, which\nisn\u0026apos;t really all that relevant any more to begin with, but it also ends\nup making assumptions based on the stack layout that aren\u0026apos;t necessarily\nvalid.\r\n\r\nBasically, the code tries to account the time spent in spinlocks to the\ncaller rather than the spinlock, and while I support that as a concept,\nit\u0026apos;s not worth the code complexity or the KASAN warnings when no serious\nprofiling is done using timers anyway these days.\r\n\r\nAnd the code really does depend on stack layout that is only true in the\nsimplest of cases. We\u0026apos;ve lost the comment at some point (I think when\nthe 32-bit and 64-bit code was unified), but it used to say:\r\n\r\n\tAssume the lock function has either no stack frame or a copy\n\tof eflags from PUSHF.\r\n\r\nwhich explains why it just blindly loads a word or two straight off the\nstack pointer and then takes a minimal look at the values to just check\nif they might be eflags or the return pc:\r\n\r\n\tEflags always has bits 22 and up cleared unlike kernel addresses\r\n\r\nbut that basic stack layout assumption assumes that there isn\u0026apos;t any lock\ndebugging etc going on that would complicate the code and cause a stack\nframe.\r\n\r\nIt causes KASAN unhappiness reported for years by syzkaller [1] and\nothers [2].\r\n\r\nWith no real practical reason for this any more, just remove the code.\r\n\r\nJust for historical interest, here\u0026apos;s some background commits relating to\nthis code from 2006:\r\n\r\n 0cb91a229364 (\u0026quot;i386: Account spinlocks to the caller during profiling for !FP kernels\u0026quot;)\n 31679f38d886 (\u0026quot;Simplify profile_pc on x86-64\u0026quot;)\r\n\r\nand a code unification from 2009:\r\n\r\n ef4512882dbe (\u0026quot;x86: time_32/64.c unify profile_pc\u0026quot;)\r\n\r\nbut the basics of this thing actually goes back to before the git tree.(CVE-2024-42096)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncrypto: ecdh - explicitly zeroize private_key\r\n\r\nprivate_key is overwritten with the key parameter passed in by the\ncaller (if present), or alternatively a newly generated private key.\nHowever, it is possible that the caller provides a key (or the newly\ngenerated key) which is shorter than the previous key. In that\nscenario, some key material from the previous key would not be\noverwritten. The easiest solution is to explicitly zeroize the entire\nprivate_key array first.\r\n\r\nNote that this patch slightly changes the behavior of this function:\npreviously, if the ecc_gen_privkey failed, the old private_key would\nremain. Now, the private_key is always zeroized. This behavior is\nconsistent with the case where params.key is set and ecc_is_key_valid\nfails.(CVE-2024-42098)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nRevert \u0026quot;mm/writeback: fix possible divide-by-zero in wb_dirty_limits(), again\u0026quot;\r\n\r\nPatch series \u0026quot;mm: Avoid possible overflows in dirty throttling\u0026quot;.\r\n\r\nDirty throttling logic assumes dirty limits in page units fit into\n32-bits. This patch series makes sure this is true (see patch 2/2 for\nmore details).\r\n\r\n\nThis patch (of 2):\r\n\r\nThis reverts commit 9319b647902cbd5cc884ac08a8a6d54ce111fc78.\r\n\r\nThe commit is broken in several ways. Firstly, the removed (u64) cast\nfrom the multiplication will introduce a multiplication overflow on 32-bit\narchs if wb_thresh * bg_thresh \u0026gt;= 1\u0026lt;\u0026lt;32 (which is actually common - the\ndefault settings with 4GB of RAM will trigger this). Secondly, the\ndiv64_u64() is unnecessarily expensive on 32-bit archs. We have\ndiv64_ul() in case we want to be safe \u0026amp; cheap. Thirdly, if dirty\nthresholds are larger than 1\u0026lt;\u0026lt;32 pages, then dirty balancing is going to\nblow up in many other spectacular ways anyway so trying to fix one\npossible overflow is just moot.(CVE-2024-42102)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: fix inode number range checks\r\n\r\nPatch series \u0026quot;nilfs2: fix potential issues related to reserved inodes\u0026quot;.\r\n\r\nThis series fixes one use-after-free issue reported by syzbot, caused by\nnilfs2\u0026apos;s internal inode being exposed in the namespace on a corrupted\nfilesystem, and a couple of flaws that cause problems if the starting\nnumber of non-reserved inodes written in the on-disk super block is\nintentionally (or corruptly) changed from its default value. \r\n\r\n\nThis patch (of 3):\r\n\r\nIn the current implementation of nilfs2, \u0026quot;nilfs-\u0026gt;ns_first_ino\u0026quot;, which\ngives the first non-reserved inode number, is read from the superblock,\nbut its lower limit is not checked.\r\n\r\nAs a result, if a number that overlaps with the inode number range of\nreserved inodes such as the root directory or metadata files is set in the\nsuper block parameter, the inode number test macros (NILFS_MDT_INODE and\nNILFS_VALID_INODE) will not function properly.\r\n\r\nIn addition, these test macros use left bit-shift calculations using with\nthe inode number as the shift count via the BIT macro, but the result of a\nshift calculation that exceeds the bit width of an integer is undefined in\nthe C specification, so if \u0026quot;ns_first_ino\u0026quot; is set to a large value other\nthan the default value NILFS_USER_INO (=11), the macros may potentially\nmalfunction depending on the environment.\r\n\r\nFix these issues by checking the lower bound of \u0026quot;nilfs-\u0026gt;ns_first_ino\u0026quot; and\nby preventing bit shifts equal to or greater than the NILFS_USER_INO\nconstant in the inode number test macros.\r\n\r\nAlso, change the type of \u0026quot;ns_first_ino\u0026quot; from signed integer to unsigned\ninteger to avoid the need for type casting in comparisons such as the\nlower bound check introduced this time.(CVE-2024-42105)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: cfg80211: restrict NL80211_ATTR_TXQ_QUANTUM values\r\n\r\nsyzbot is able to trigger softlockups, setting NL80211_ATTR_TXQ_QUANTUM\nto 2^31.\r\n\r\nWe had a similar issue in sch_fq, fixed with commit\nd9e15a273306 (\u0026quot;pkt_sched: fq: do not accept silly TCA_FQ_QUANTUM\u0026quot;)\r\n\r\nwatchdog: BUG: soft lockup - CPU#1 stuck for 26s! [kworker/1:0:24]\nModules linked in:\nirq event stamp: 131135\n hardirqs last enabled at (131134): [\u0026lt;ffff80008ae8778c\u0026gt;] __exit_to_kernel_mode arch/arm64/kernel/entry-common.c:85 [inline]\n hardirqs last enabled at (131134): [\u0026lt;ffff80008ae8778c\u0026gt;] exit_to_kernel_mode+0xdc/0x10c arch/arm64/kernel/entry-common.c:95\n hardirqs last disabled at (131135): [\u0026lt;ffff80008ae85378\u0026gt;] __el1_irq arch/arm64/kernel/entry-common.c:533 [inline]\n hardirqs last disabled at (131135): [\u0026lt;ffff80008ae85378\u0026gt;] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551\n softirqs last enabled at (125892): [\u0026lt;ffff80008907e82c\u0026gt;] neigh_hh_init net/core/neighbour.c:1538 [inline]\n softirqs last enabled at (125892): [\u0026lt;ffff80008907e82c\u0026gt;] neigh_resolve_output+0x268/0x658 net/core/neighbour.c:1553\n softirqs last disabled at (125896): [\u0026lt;ffff80008904166c\u0026gt;] local_bh_disable+0x10/0x34 include/linux/bottom_half.h:19\nCPU: 1 PID: 24 Comm: kworker/1:0 Not tainted 6.9.0-rc7-syzkaller-gfda5695d692c #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024\nWorkqueue: mld mld_ifc_work\npstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : __list_del include/linux/list.h:195 [inline]\n pc : __list_del_entry include/linux/list.h:218 [inline]\n pc : list_move_tail include/linux/list.h:310 [inline]\n pc : fq_tin_dequeue include/net/fq_impl.h:112 [inline]\n pc : ieee80211_tx_dequeue+0x6b8/0x3b4c net/mac80211/tx.c:3854\n lr : __list_del_entry include/linux/list.h:218 [inline]\n lr : list_move_tail include/linux/list.h:310 [inline]\n lr : fq_tin_dequeue include/net/fq_impl.h:112 [inline]\n lr : ieee80211_tx_dequeue+0x67c/0x3b4c net/mac80211/tx.c:3854\nsp : ffff800093d36700\nx29: ffff800093d36a60 x28: ffff800093d36960 x27: dfff800000000000\nx26: ffff0000d800ad50 x25: ffff0000d800abe0 x24: ffff0000d800abf0\nx23: ffff0000e0032468 x22: ffff0000e00324d4 x21: ffff0000d800abf0\nx20: ffff0000d800abf8 x19: ffff0000d800abf0 x18: ffff800093d363c0\nx17: 000000000000d476 x16: ffff8000805519dc x15: ffff7000127a6cc8\nx14: 1ffff000127a6cc8 x13: 0000000000000004 x12: ffffffffffffffff\nx11: ffff7000127a6cc8 x10: 0000000000ff0100 x9 : 0000000000000000\nx8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000\nx5 : ffff80009287aa08 x4 : 0000000000000008 x3 : ffff80008034c7fc\nx2 : ffff0000e0032468 x1 : 00000000da0e46b8 x0 : ffff0000e0032470\nCall trace:\n __list_del include/linux/list.h:195 [inline]\n __list_del_entry include/linux/list.h:218 [inline]\n list_move_tail include/linux/list.h:310 [inline]\n fq_tin_dequeue include/net/fq_impl.h:112 [inline]\n ieee80211_tx_dequeue+0x6b8/0x3b4c net/mac80211/tx.c:3854\n wake_tx_push_queue net/mac80211/util.c:294 [inline]\n ieee80211_handle_wake_tx_queue+0x118/0x274 net/mac80211/util.c:315\n drv_wake_tx_queue net/mac80211/driver-ops.h:1350 [inline]\n schedule_and_wake_txq net/mac80211/driver-ops.h:1357 [inline]\n ieee80211_queue_skb+0x18e8/0x2244 net/mac80211/tx.c:1664\n ieee80211_tx+0x260/0x400 net/mac80211/tx.c:1966\n ieee80211_xmit+0x278/0x354 net/mac80211/tx.c:2062\n __ieee80211_subif_start_xmit+0xab8/0x122c net/mac80211/tx.c:4338\n ieee80211_subif_start_xmit+0xe0/0x438 net/mac80211/tx.c:4532\n __netdev_start_xmit include/linux/netdevice.h:4903 [inline]\n netdev_start_xmit include/linux/netdevice.h:4917 [inline]\n xmit_one net/core/dev.c:3531 [inline]\n dev_hard_start_xmit+0x27c/0x938 net/core/dev.c:3547\n __dev_queue_xmit+0x1678/0x33fc net/core/dev.c:4341\n dev_queue_xmit include/linux/netdevice.h:3091 [inline]\n neigh_resolve_output+0x558/0x658 net/core/neighbour.c:1563\n neigh_output include/net/neighbour.h:542 [inline]\n ip6_fini\n---truncated---(CVE-2024-42114)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nleds: an30259a: Use devm_mutex_init() for mutex initialization\r\n\r\nIn this driver LEDs are registered using devm_led_classdev_register()\nso they are automatically unregistered after module\u0026apos;s remove() is done.\nled_classdev_unregister() calls module\u0026apos;s led_set_brightness() to turn off\nthe LEDs and that callback uses mutex which was destroyed already\nin module\u0026apos;s remove() so use devm API instead.(CVE-2024-42128)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\norangefs: fix out-of-bounds fsid access\r\n\r\nArnd Bergmann sent a patch to fsdevel, he says:\r\n\r\n\u0026quot;orangefs_statfs() copies two consecutive fields of the superblock into\nthe statfs structure, which triggers a warning from the string fortification\nhelpers\u0026quot;\r\n\r\nJan Kara suggested an alternate way to do the patch to make it more readable.\r\n\r\nI ran both ideas through xfstests and both seem fine. This patch\nis based on Jan Kara\u0026apos;s suggestion.(CVE-2024-42143)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbnx2x: Fix multiple UBSAN array-index-out-of-bounds\r\n\r\nFix UBSAN warnings that occur when using a system with 32 physical\ncpu cores or more, or when the user defines a number of Ethernet\nqueues greater than or equal to FP_SB_MAX_E1x using the num_queues\nmodule parameter.\r\n\r\nCurrently there is a read/write out of bounds that occurs on the array\n\u0026quot;struct stats_query_entry query\u0026quot; present inside the \u0026quot;bnx2x_fw_stats_req\u0026quot;\nstruct in \u0026quot;drivers/net/ethernet/broadcom/bnx2x/bnx2x.h\u0026quot;.\nLooking at the definition of the \u0026quot;struct stats_query_entry query\u0026quot; array:\r\n\r\nstruct stats_query_entry query[FP_SB_MAX_E1x+\n BNX2X_FIRST_QUEUE_QUERY_IDX];\r\n\r\nFP_SB_MAX_E1x is defined as the maximum number of fast path interrupts and\nhas a value of 16, while BNX2X_FIRST_QUEUE_QUERY_IDX has a value of 3\nmeaning the array has a total size of 19.\nSince accesses to \u0026quot;struct stats_query_entry query\u0026quot; are offset-ted by\nBNX2X_FIRST_QUEUE_QUERY_IDX, that means that the total number of Ethernet\nqueues should not exceed FP_SB_MAX_E1x (16). However one of these queues\nis reserved for FCOE and thus the number of Ethernet queues should be set\nto [FP_SB_MAX_E1x -1] (15) if FCOE is enabled or [FP_SB_MAX_E1x] (16) if\nit is not.\r\n\r\nThis is also described in a comment in the source code in\ndrivers/net/ethernet/broadcom/bnx2x/bnx2x.h just above the Macro definition\nof FP_SB_MAX_E1x. Below is the part of this explanation that it important\nfor this patch\r\n\r\n/*\n * The total number of L2 queues, MSIX vectors and HW contexts (CIDs) is\n * control by the number of fast-path status blocks supported by the\n * device (HW/FW). Each fast-path status block (FP-SB) aka non-default\n * status block represents an independent interrupts context that can\n * serve a regular L2 networking queue. However special L2 queues such\n * as the FCoE queue do not require a FP-SB and other components like\n * the CNIC may consume FP-SB reducing the number of possible L2 queues\n *\n * If the maximum number of FP-SB available is X then:\n * a. If CNIC is supported it consumes 1 FP-SB thus the max number of\n * regular L2 queues is Y=X-1\n * b. In MF mode the actual number of L2 queues is Y= (X-1/MF_factor)\n * c. If the FCoE L2 queue is supported the actual number of L2 queues\n * is Y+1\n * d. The number of irqs (MSIX vectors) is either Y+1 (one extra for\n * slow-path interrupts) or Y+2 if CNIC is supported (one additional\n * FP interrupt context for the CNIC).\n * e. The number of HW context (CID count) is always X or X+1 if FCoE\n * L2 queue is supported. The cid for the FCoE L2 queue is always X.\n */\r\n\r\nHowever this driver also supports NICs that use the E2 controller which can\nhandle more queues due to having more FP-SB represented by FP_SB_MAX_E2.\nLooking at the commits when the E2 support was added, it was originally\nusing the E1x parameters: commit f2e0899f0f27 (\u0026quot;bnx2x: Add 57712 support\u0026quot;).\nBack then FP_SB_MAX_E2 was set to 16 the same as E1x. However the driver\nwas later updated to take full advantage of the E2 instead of having it be\nlimited to the capabilities of the E1x. But as far as we can tell, the\narray \u0026quot;stats_query_entry query\u0026quot; was still limited to using the FP-SB\navailable to the E1x cards as part of an oversignt when the driver was\nupdated to take full advantage of the E2, and now with the driver being\naware of the greater queue size supported by E2 NICs, it causes the UBSAN\nwarnings seen in the stack traces below.\r\n\r\nThis patch increases the size of the \u0026quot;stats_query_entry query\u0026quot; array by\nreplacing FP_SB_MAX_E1x with FP_SB_MAX_E2 to be large enough to handle\nboth types of NICs.\r\n\r\nStack traces:\r\n\r\nUBSAN: array-index-out-of-bounds in\n drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.c:1529:11\nindex 20 is out of range for type \u0026apos;stats_query_entry [19]\u0026apos;\nCPU: 12 PID: 858 Comm: systemd-network Not tainted 6.9.0-060900rc7-generic\n\t #202405052133\nHardware name: HP ProLiant DL360 Gen9/ProLiant DL360 \n---truncated---(CVE-2024-42148)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntcp_metrics: validate source addr length\r\n\r\nI don\u0026apos;t see anything checking that TCP_METRICS_ATTR_SADDR_IPV4\nis at least 4 bytes long, and the policy doesn\u0026apos;t have an entry\nfor this attribute at all (neither does it for IPv6 but v6 is\nmanually validated).(CVE-2024-42154)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ns390/pkey: Wipe copies of clear-key structures on failure\r\n\r\nWipe all sensitive data from stack for all IOCTLs, which convert a\nclear-key into a protected- or secure-key.(CVE-2024-42156)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ns390/pkey: Wipe sensitive data on failure\r\n\r\nWipe sensitive data from stack also if the copy_to_user() fails.(CVE-2024-42157)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: dvb-frontends: tda10048: Fix integer overflow\r\n\r\nstate-\u0026gt;xtal_hz can be up to 16M, so it can overflow a 32 bit integer\nwhen multiplied by pll_mfactor.\r\n\r\nCreate a new 64 bit variable to hold the calculations.(CVE-2024-42223)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: mt76: replace skb_put with skb_put_zero\r\n\r\nAvoid potentially reusing uninitialized data(CVE-2024-42225)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncrypto: aead,cipher - zeroize key buffer after use\r\n\r\nI.G 9.7.B for FIPS 140-3 specifies that variables temporarily holding\ncryptographic information should be zeroized once they are no longer\nneeded. Accomplish this by using kfree_sensitive for buffers that\npreviously held the private key.(CVE-2024-42229)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nUSB: serial: mos7840: fix crash on resume\r\n\r\nSince commit c49cfa917025 (\u0026quot;USB: serial: use generic method if no\nalternative is provided in usb serial layer\u0026quot;), USB serial core calls the\ngeneric resume implementation when the driver has not provided one.\r\n\r\nThis can trigger a crash on resume with mos7840 since support for\nmultiple read URBs was added back in 2011. Specifically, both port read\nURBs are now submitted on resume for open ports, but the context pointer\nof the second URB is left set to the core rather than mos7840 port\nstructure.\r\n\r\nFix this by implementing dedicated suspend and resume functions for\nmos7840.\r\n\r\nTested with Delock 87414 USB 2.0 to 4x serial adapter.\r\n\r\n[ johan: analyse crash and rewrite commit message; set busy flag on\n resume; drop bulk-in check; drop unnecessary usb_kill_urb() ](CVE-2024-42244)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet, sunrpc: Remap EPERM in case of connection failure in xs_tcp_setup_socket\r\n\r\nWhen using a BPF program on kernel_connect(), the call can return -EPERM. This\ncauses xs_tcp_setup_socket() to loop forever, filling up the syslog and causing\nthe kernel to potentially freeze up.\r\n\r\nNeil suggested:\r\n\r\n This will propagate -EPERM up into other layers which might not be ready\n to handle it. It might be safer to map EPERM to an error we would be more\n likely to expect from the network system - such as ECONNREFUSED or ENETDOWN.\r\n\r\nECONNREFUSED as error seems reasonable. For programs setting a different error\ncan be out of reach (see handling in 4fbac77d2d09) in particular on kernels\nwhich do not have f10d05966196 (\u0026quot;bpf: Make BPF_PROG_RUN_ARRAY return -err\ninstead of allow boolean\u0026quot;), thus given that it is better to simply remap for\nconsistent behavior. UDP does handle EPERM in xs_udp_send_request().(CVE-2024-42246)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwireguard: allowedips: avoid unaligned 64-bit memory accesses\r\n\r\nOn the parisc platform, the kernel issues kernel warnings because\nswap_endian() tries to load a 128-bit IPv6 address from an unaligned\nmemory location:\r\n\r\n Kernel: unaligned access to 0x55f4688c in wg_allowedips_insert_v6+0x2c/0x80 [wireguard] (iir 0xf3010df)\n Kernel: unaligned access to 0x55f46884 in wg_allowedips_insert_v6+0x38/0x80 [wireguard] (iir 0xf2010dc)\r\n\r\nAvoid such unaligned memory accesses by instead using the\nget_unaligned_be64() helper macro.\r\n\r\n[Jason: replace src[8] in original patch with src+8](CVE-2024-42247)",
"id": "OESA-2024-1992",
"modified": "2026-08-06T11:07:27Z",
"published": "2024-08-16T11:07:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1992"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47582"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48827"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52888"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39509"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40942"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40990"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41012"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41034"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41035"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41042"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41046"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41065"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41078"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41092"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42087"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42095"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42096"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42098"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42102"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42105"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42114"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42128"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42143"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42148"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42154"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42156"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42157"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42223"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42225"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42229"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42244"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42246"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42247"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2021-47582",
"CVE-2022-48827",
"CVE-2023-52888",
"CVE-2024-39509",
"CVE-2024-40942",
"CVE-2024-40990",
"CVE-2024-41012",
"CVE-2024-41034",
"CVE-2024-41035",
"CVE-2024-41042",
"CVE-2024-41046",
"CVE-2024-41065",
"CVE-2024-41078",
"CVE-2024-41092",
"CVE-2024-42087",
"CVE-2024-42095",
"CVE-2024-42096",
"CVE-2024-42098",
"CVE-2024-42102",
"CVE-2024-42105",
"CVE-2024-42114",
"CVE-2024-42128",
"CVE-2024-42143",
"CVE-2024-42148",
"CVE-2024-42154",
"CVE-2024-42156",
"CVE-2024-42157",
"CVE-2024-42223",
"CVE-2024-42225",
"CVE-2024-42229",
"CVE-2024-42244",
"CVE-2024-42246",
"CVE-2024-42247"
]
}
OESA-2024-1994 (CVE-2021-47582)
Vulnerability from osv_openeuler – Published: 2024-08-16 11:07 – Updated: 2026-08-06 11:07 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
USB: core: Make do_proc_control() and do_proc_bulk() killable
The USBDEVFS_CONTROL and USBDEVFS_BULK ioctls invoke usb_start_wait_urb(), which contains an uninterruptible wait with a user-specified timeout value. If timeout value is very large and the device being accessed does not respond in a reasonable amount of time, the kernel will complain about "Task X blocked for more than N seconds", as found in testing by syzbot:
INFO: task syz-executor.0:8700 blocked for more than 143 seconds. Not tainted 5.14.0-rc7-syzkaller #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:syz-executor.0 state:D stack:23192 pid: 8700 ppid: 8455 flags:0x00004004 Call Trace: context_switch kernel/sched/core.c:4681 [inline] __schedule+0xc07/0x11f0 kernel/sched/core.c:5938 schedule+0x14b/0x210 kernel/sched/core.c:6017 schedule_timeout+0x98/0x2f0 kernel/time/timer.c:1857 do_wait_for_common+0x2da/0x480 kernel/sched/completion.c:85 __wait_for_common kernel/sched/completion.c:106 [inline] wait_for_common kernel/sched/completion.c:117 [inline] wait_for_completion_timeout+0x46/0x60 kernel/sched/completion.c:157 usb_start_wait_urb+0x167/0x550 drivers/usb/core/message.c:63 do_proc_bulk+0x978/0x1080 drivers/usb/core/devio.c:1236 proc_bulk drivers/usb/core/devio.c:1273 [inline] usbdev_do_ioctl drivers/usb/core/devio.c:2547 [inline] usbdev_ioctl+0x3441/0x6b10 drivers/usb/core/devio.c:2713 ...
To fix this problem, this patch replaces usbfs's calls to usb_control_msg() and usb_bulk_msg() with special-purpose code that does essentially the same thing (as recommended in the comment for usb_start_wait_urb()), except that it always uses a killable wait and it uses GFP_KERNEL rather than GFP_NOIO.(CVE-2021-47582)
In the Linux kernel, the following vulnerability has been resolved:
media: mediatek: vcodec: Only free buffer VA that is not NULL
In the MediaTek vcodec driver, while mtk_vcodec_mem_free() is mostly called only when the buffer to free exists, there are some instances that didn't do the check and triggered warnings in practice.
We believe those checks were forgotten unintentionally. Add the checks back to fix the warnings.(CVE-2023-52888)
In the Linux kernel, the following vulnerability has been resolved:
HID: core: remove unnecessary WARN_ON() in implement()
Syzkaller hit a warning [1] in a call to implement() when trying to write a value into a field of smaller size in an output report.
Since implement() already has a warn message printed out with the help of hid_warn() and value in question gets trimmed with: ... value &= m; ... WARN_ON may be considered superfluous. Remove it to suppress future syzkaller triggers.
[1] WARNING: CPU: 0 PID: 5084 at drivers/hid/hid-core.c:1451 implement drivers/hid/hid-core.c:1451 [inline] WARNING: CPU: 0 PID: 5084 at drivers/hid/hid-core.c:1451 hid_output_report+0x548/0x760 drivers/hid/hid-core.c:1863 Modules linked in: CPU: 0 PID: 5084 Comm: syz-executor424 Not tainted 6.9.0-rc7-syzkaller-00183-gcf87f46fd34d #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024 RIP: 0010:implement drivers/hid/hid-core.c:1451 [inline] RIP: 0010:hid_output_report+0x548/0x760 drivers/hid/hid-core.c:1863 ... Call Trace: <TASK> __usbhid_submit_report drivers/hid/usbhid/hid-core.c:591 [inline] usbhid_submit_report+0x43d/0x9e0 drivers/hid/usbhid/hid-core.c:636 hiddev_ioctl+0x138b/0x1f00 drivers/hid/usbhid/hiddev.c:726 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:904 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:890 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f ...(CVE-2024-39509)
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: mesh: Fix leak of mesh_preq_queue objects
The hwmp code use objects of type mesh_preq_queue, added to a list in ieee80211_if_mesh, to keep track of mpath we need to resolve. If the mpath gets deleted, ex mesh interface is removed, the entries in that list will never get cleaned. Fix this by flushing all corresponding items of the preq_queue in mesh_path_flush_pending().
This should take care of KASAN reports like this:
unreferenced object 0xffff00000668d800 (size 128): comm "kworker/u8:4", pid 67, jiffies 4295419552 (age 1836.444s) hex dump (first 32 bytes): 00 1f 05 09 00 00 ff ff 00 d5 68 06 00 00 ff ff ..........h..... 8e 97 ea eb 3e b8 01 00 00 00 00 00 00 00 00 00 ....>........... backtrace: [<000000007302a0b6>] __kmem_cache_alloc_node+0x1e0/0x35c [<00000000049bd418>] kmalloc_trace+0x34/0x80 [<0000000000d792bb>] mesh_queue_preq+0x44/0x2a8 [<00000000c99c3696>] mesh_nexthop_resolve+0x198/0x19c [<00000000926bf598>] ieee80211_xmit+0x1d0/0x1f4 [<00000000fc8c2284>] __ieee80211_subif_start_xmit+0x30c/0x764 [<000000005926ee38>] ieee80211_subif_start_xmit+0x9c/0x7a4 [<000000004c86e916>] dev_hard_start_xmit+0x174/0x440 [<0000000023495647>] __dev_queue_xmit+0xe24/0x111c [<00000000cfe9ca78>] batadv_send_skb_packet+0x180/0x1e4 [<000000007bacc5d5>] batadv_v_elp_periodic_work+0x2f4/0x508 [<00000000adc3cd94>] process_one_work+0x4b8/0xa1c [<00000000b36425d1>] worker_thread+0x9c/0x634 [<0000000005852dd5>] kthread+0x1bc/0x1c4 [<000000005fccd770>] ret_from_fork+0x10/0x20 unreferenced object 0xffff000009051f00 (size 128): comm "kworker/u8:4", pid 67, jiffies 4295419553 (age 1836.440s) hex dump (first 32 bytes): 90 d6 92 0d 00 00 ff ff 00 d8 68 06 00 00 ff ff ..........h..... 36 27 92 e4 02 e0 01 00 00 58 79 06 00 00 ff ff 6'.......Xy..... backtrace: [<000000007302a0b6>] __kmem_cache_alloc_node+0x1e0/0x35c [<00000000049bd418>] kmalloc_trace+0x34/0x80 [<0000000000d792bb>] mesh_queue_preq+0x44/0x2a8 [<00000000c99c3696>] mesh_nexthop_resolve+0x198/0x19c [<00000000926bf598>] ieee80211_xmit+0x1d0/0x1f4 [<00000000fc8c2284>] __ieee80211_subif_start_xmit+0x30c/0x764 [<000000005926ee38>] ieee80211_subif_start_xmit+0x9c/0x7a4 [<000000004c86e916>] dev_hard_start_xmit+0x174/0x440 [<0000000023495647>] __dev_queue_xmit+0xe24/0x111c [<00000000cfe9ca78>] batadv_send_skb_packet+0x180/0x1e4 [<000000007bacc5d5>] batadv_v_elp_periodic_work+0x2f4/0x508 [<00000000adc3cd94>] process_one_work+0x4b8/0xa1c [<00000000b36425d1>] worker_thread+0x9c/0x634 [<0000000005852dd5>] kthread+0x1bc/0x1c4 [<000000005fccd770>] ret_from_fork+0x10/0x20(CVE-2024-40942)
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: idxd: Fix possible Use-After-Free in irq_process_work_list
Use list_for_each_entry_safe() to allow iterating through the list and deleting the entry in the iteration process. The descriptor is freed via idxd_desc_complete() and there's a slight chance may cause issue for the list iterator when the descriptor is reused by another thread without it being deleted from the list.(CVE-2024-40956)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/mlx5: Add check for srq max_sge attribute
max_sge attribute is passed by the user, and is inserted and used unchecked, so verify that the value doesn't exceed maximum allowed value before using it.(CVE-2024-40990)
In the Linux kernel, the following vulnerability has been resolved:
filelock: Remove locks reliably when fcntl/close race is detected
When fcntl_setlk() races with close(), it removes the created lock with do_lock_file_wait(). However, LSMs can allow the first do_lock_file_wait() that created the lock while denying the second do_lock_file_wait() that tries to remove the lock. Separately, posix_lock_file() could also fail to remove a lock due to GFP_KERNEL allocation failure (when splitting a range in the middle).
After the bug has been triggered, use-after-free reads will occur in lock_get_status() when userspace reads /proc/locks. This can likely be used to read arbitrary kernel memory, but can't corrupt kernel memory.
Fix it by calling locks_remove_posix() instead, which is designed to reliably get rid of POSIX locks associated with the given file and files_struct and is also used by filp_flush().(CVE-2024-41012)
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix kernel bug on rename operation of broken directory
Syzbot reported that in rename directory operation on broken directory on nilfs2, __block_write_begin_int() called to prepare block write may fail BUG_ON check for access exceeding the folio/page size.
This is because nilfs_dotdot(), which gets parent directory reference entry ("..") of the directory to be moved or renamed, does not check consistency enough, and may return location exceeding folio/page size for broken directories.
Fix this issue by checking required directory entries ("." and "..") in the first chunk of the directory in nilfs_dotdot().(CVE-2024-41034)
In the Linux kernel, the following vulnerability has been resolved:
USB: core: Fix duplicate endpoint bug by clearing reserved bits in the descriptor
Syzbot has identified a bug in usbcore (see the Closes: tag below) caused by our assumption that the reserved bits in an endpoint descriptor's bEndpointAddress field will always be 0. As a result of the bug, the endpoint_is_duplicate() routine in config.c (and possibly other routines as well) may believe that two descriptors are for distinct endpoints, even though they have the same direction and endpoint number. This can lead to confusion, including the bug identified by syzbot (two descriptors with matching endpoint numbers and directions, where one was interrupt and the other was bulk).
To fix the bug, we will clear the reserved bits in bEndpointAddress when we parse the descriptor. (Note that both the USB-2.0 and USB-3.1 specs say these bits are "Reserved, reset to zero".) This requires us to make a copy of the descriptor earlier in usb_parse_endpoint() and use the copy instead of the original when checking for duplicates.(CVE-2024-41035)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: prefer nft_chain_validate
nft_chain_validate already performs loop detection because a cycle will result in a call stack overflow (ctx->level >= NFT_JUMP_STACK_SIZE).
It also follows maps via ->validate callback in nft_lookup, so there appears no reason to iterate the maps again.
nf_tables_check_loops() and all its helper functions can be removed. This improves ruleset load time significantly, from 23s down to 12s.
This also fixes a crash bug. Old loop detection code can result in unbounded recursion:
BUG: TASK stack guard page was hit at .... Oops: stack guard page: 0000 [#1] PREEMPT SMP KASAN CPU: 4 PID: 1539 Comm: nft Not tainted 6.10.0-rc5+ #1 [..]
with a suitable ruleset during validation of register stores.
I can't see any actual reason to attempt to check for this from nft_validate_register_store(), at this point the transaction is still in progress, so we don't have a full picture of the rule graph.
For nf-next it might make sense to either remove it or make this depend on table->validate_state in case we could catch an error earlier (for improved error reporting to userspace).(CVE-2024-41042)
In the Linux kernel, the following vulnerability has been resolved:
net: ethernet: lantiq_etop: fix double free in detach
The number of the currently released descriptor is never incremented which results in the same skb being released multiple times.(CVE-2024-41046)
In the Linux kernel, the following vulnerability has been resolved:
powerpc/pseries: Whitelist dtl slub object for copying to userspace
Reading the dispatch trace log from /sys/kernel/debug/powerpc/dtl/cpu-* results in a BUG() when the config CONFIG_HARDENED_USERCOPY is enabled as shown below.
kernel BUG at mm/usercopy.c:102!
Oops: Exception in kernel mode, sig: 5 [#1]
LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries
Modules linked in: xfs libcrc32c dm_service_time sd_mod t10_pi sg ibmvfc
scsi_transport_fc ibmveth pseries_wdt dm_multipath dm_mirror dm_region_hash dm_log dm_mod fuse
CPU: 27 PID: 1815 Comm: python3 Not tainted 6.10.0-rc3 #85
Hardware name: IBM,9040-MRX POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1060.00 (NM1060_042) hv:phyp pSeries
NIP: c0000000005d23d4 LR: c0000000005d23d0 CTR: 00000000006ee6f8
REGS: c000000120c078c0 TRAP: 0700 Not tainted (6.10.0-rc3)
MSR: 8000000000029033 <SF,EE,ME,IR,DR,RI,LE> CR: 2828220f XER: 0000000e
CFAR: c0000000001fdc80 IRQMASK: 0
[ ... GPRs omitted ... ]
NIP [c0000000005d23d4] usercopy_abort+0x78/0xb0
LR [c0000000005d23d0] usercopy_abort+0x74/0xb0
Call Trace:
usercopy_abort+0x74/0xb0 (unreliable)
__check_heap_object+0xf8/0x120
check_heap_object+0x218/0x240
__check_object_size+0x84/0x1a4
dtl_file_read+0x17c/0x2c4
full_proxy_read+0x8c/0x110
vfs_read+0xdc/0x3a0
ksys_read+0x84/0x144
system_call_exception+0x124/0x330
system_call_vectored_common+0x15c/0x2ec
--- interrupt: 3000 at 0x7fff81f3ab34
Commit 6d07d1cd300f ("usercopy: Restrict non-usercopy caches to size 0") requires that only whitelisted areas in slab/slub objects can be copied to userspace when usercopy hardening is enabled using CONFIG_HARDENED_USERCOPY. Dtl contains hypervisor dispatch events which are expected to be read by privileged users. Hence mark this safe for user access. Specify useroffset=0 and usersize=DISPATCH_LOG_BYTES to whitelist the entire object.(CVE-2024-41065)
In the Linux kernel, the following vulnerability has been resolved:
btrfs: qgroup: fix quota root leak after quota disable failure
If during the quota disable we fail when cleaning the quota tree or when deleting the root from the root tree, we jump to the 'out' label without ever dropping the reference on the quota root, resulting in a leak of the root since fs_info->quota_root is no longer pointing to the root (we have set it to NULL just before those steps).
Fix this by always doing a btrfs_put_root() call under the 'out' label. This is a problem that exists since qgroups were first added in 2012 by commit bed92eae26cc ("Btrfs: qgroup implementation and prototypes"), but back then we missed a kfree on the quota root and free_extent_buffer() calls on its root and commit root nodes, since back then roots were not yet reference counted.(CVE-2024-41078)
In the Linux kernel, the following vulnerability has been resolved:
drm/i915/gt: Fix potential UAF by revoke of fence registers
CI has been sporadically reporting the following issue triggered by igt@i915_selftest@live@hangcheck on ADL-P and similar machines:
<6> [414.049203] i915: Running intel_hangcheck_live_selftests/igt_reset_evict_fence ... <6> [414.068804] i915 0000:00:02.0: [drm] GT0: GUC: submission enabled <6> [414.068812] i915 0000:00:02.0: [drm] GT0: GUC: SLPC enabled <3> [414.070354] Unable to pin Y-tiled fence; err:-4 <3> [414.071282] i915_vma_revoke_fence:301 GEM_BUG_ON(!i915_active_is_idle(&fence->active)) ... <4>[ 609.603992] ------------[ cut here ]------------ <2>[ 609.603995] kernel BUG at drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c:301! <4>[ 609.604003] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI <4>[ 609.604006] CPU: 0 PID: 268 Comm: kworker/u64:3 Tainted: G U W 6.9.0-CI_DRM_14785-g1ba62f8cea9c+ #1 <4>[ 609.604008] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023 <4>[ 609.604010] Workqueue: i915 __i915_gem_free_work [i915] <4>[ 609.604149] RIP: 0010:i915_vma_revoke_fence+0x187/0x1f0 [i915] ... <4>[ 609.604271] Call Trace: <4>[ 609.604273] <TASK> ... <4>[ 609.604716] __i915_vma_evict+0x2e9/0x550 [i915] <4>[ 609.604852] __i915_vma_unbind+0x7c/0x160 [i915] <4>[ 609.604977] force_unbind+0x24/0xa0 [i915] <4>[ 609.605098] i915_vma_destroy+0x2f/0xa0 [i915] <4>[ 609.605210] __i915_gem_object_pages_fini+0x51/0x2f0 [i915] <4>[ 609.605330] __i915_gem_free_objects.isra.0+0x6a/0xc0 [i915] <4>[ 609.605440] process_scheduled_works+0x351/0x690 ...
In the past, there were similar failures reported by CI from other IGT tests, observed on other platforms.
Before commit 63baf4f3d587 ("drm/i915/gt: Only wait for GPU activity before unbinding a GGTT fence"), i915_vma_revoke_fence() was waiting for idleness of vma->active via fence_update(). That commit introduced vma->fence->active in order for the fence_update() to be able to wait selectively on that one instead of vma->active since only idleness of fence registers was needed. But then, another commit 0d86ee35097a ("drm/i915/gt: Make fence revocation unequivocal") replaced the call to fence_update() in i915_vma_revoke_fence() with only fence_write(), and also added that GEM_BUG_ON(!i915_active_is_idle(&fence->active)) in front. No justification was provided on why we might then expect idleness of vma->fence->active without first waiting on it.
The issue can be potentially caused by a race among revocation of fence registers on one side and sequential execution of signal callbacks invoked on completion of a request that was using them on the other, still processed in parallel to revocation of those fence registers. Fix it by waiting for idleness of vma->fence->active in i915_vma_revoke_fence().
(cherry picked from commit 24bb052d3dd499c5956abad5f7d8e4fd07da7fb1)(CVE-2024-41092)
In the Linux kernel, the following vulnerability has been resolved:
drm/panel: ilitek-ili9881c: Fix warning with GPIO controllers that sleep
The ilitek-ili9881c controls the reset GPIO using the non-sleeping gpiod_set_value() function. This complains loudly when the GPIO controller needs to sleep. As the caller can sleep, use gpiod_set_value_cansleep() to fix the issue.(CVE-2024-42087)
In the Linux kernel, the following vulnerability has been resolved:
serial: 8250_omap: Implementation of Errata i2310
As per Errata i2310[0], Erroneous timeout can be triggered, if this Erroneous interrupt is not cleared then it may leads to storm of interrupts, therefore apply Errata i2310 solution.
[0] https://www.ti.com/lit/pdf/sprz536 page 23(CVE-2024-42095)
In the Linux kernel, the following vulnerability has been resolved:
x86: stop playing stack games in profile_pc()
The 'profile_pc()' function is used for timer-based profiling, which isn't really all that relevant any more to begin with, but it also ends up making assumptions based on the stack layout that aren't necessarily valid.
Basically, the code tries to account the time spent in spinlocks to the caller rather than the spinlock, and while I support that as a concept, it's not worth the code complexity or the KASAN warnings when no serious profiling is done using timers anyway these days.
And the code really does depend on stack layout that is only true in the simplest of cases. We've lost the comment at some point (I think when the 32-bit and 64-bit code was unified), but it used to say:
Assume the lock function has either no stack frame or a copy
of eflags from PUSHF.
which explains why it just blindly loads a word or two straight off the stack pointer and then takes a minimal look at the values to just check if they might be eflags or the return pc:
Eflags always has bits 22 and up cleared unlike kernel addresses
but that basic stack layout assumption assumes that there isn't any lock debugging etc going on that would complicate the code and cause a stack frame.
It causes KASAN unhappiness reported for years by syzkaller [1] and others [2].
With no real practical reason for this any more, just remove the code.
Just for historical interest, here's some background commits relating to this code from 2006:
0cb91a229364 ("i386: Account spinlocks to the caller during profiling for !FP kernels") 31679f38d886 ("Simplify profile_pc on x86-64")
and a code unification from 2009:
ef4512882dbe ("x86: time_32/64.c unify profile_pc")
but the basics of this thing actually goes back to before the git tree.(CVE-2024-42096)
In the Linux kernel, the following vulnerability has been resolved:
crypto: ecdh - explicitly zeroize private_key
private_key is overwritten with the key parameter passed in by the caller (if present), or alternatively a newly generated private key. However, it is possible that the caller provides a key (or the newly generated key) which is shorter than the previous key. In that scenario, some key material from the previous key would not be overwritten. The easiest solution is to explicitly zeroize the entire private_key array first.
Note that this patch slightly changes the behavior of this function: previously, if the ecc_gen_privkey failed, the old private_key would remain. Now, the private_key is always zeroized. This behavior is consistent with the case where params.key is set and ecc_is_key_valid fails.(CVE-2024-42098)
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix inode number range checks
Patch series "nilfs2: fix potential issues related to reserved inodes".
This series fixes one use-after-free issue reported by syzbot, caused by nilfs2's internal inode being exposed in the namespace on a corrupted filesystem, and a couple of flaws that cause problems if the starting number of non-reserved inodes written in the on-disk super block is intentionally (or corruptly) changed from its default value.
This patch (of 3):
In the current implementation of nilfs2, "nilfs->ns_first_ino", which gives the first non-reserved inode number, is read from the superblock, but its lower limit is not checked.
As a result, if a number that overlaps with the inode number range of reserved inodes such as the root directory or metadata files is set in the super block parameter, the inode number test macros (NILFS_MDT_INODE and NILFS_VALID_INODE) will not function properly.
In addition, these test macros use left bit-shift calculations using with the inode number as the shift count via the BIT macro, but the result of a shift calculation that exceeds the bit width of an integer is undefined in the C specification, so if "ns_first_ino" is set to a large value other than the default value NILFS_USER_INO (=11), the macros may potentially malfunction depending on the environment.
Fix these issues by checking the lower bound of "nilfs->ns_first_ino" and by preventing bit shifts equal to or greater than the NILFS_USER_INO constant in the inode number test macros.
Also, change the type of "ns_first_ino" from signed integer to unsigned integer to avoid the need for type casting in comparisons such as the lower bound check introduced this time.(CVE-2024-42105)
In the Linux kernel, the following vulnerability has been resolved:
wifi: cfg80211: restrict NL80211_ATTR_TXQ_QUANTUM values
syzbot is able to trigger softlockups, setting NL80211_ATTR_TXQ_QUANTUM to 2^31.
We had a similar issue in sch_fq, fixed with commit d9e15a273306 ("pkt_sched: fq: do not accept silly TCA_FQ_QUANTUM")
watchdog: BUG: soft lockup - CPU#1 stuck for 26s! [kworker/1:0:24] Modules linked in: irq event stamp: 131135 hardirqs last enabled at (131134): [<ffff80008ae8778c>] __exit_to_kernel_mode arch/arm64/kernel/entry-common.c:85 [inline] hardirqs last enabled at (131134): [<ffff80008ae8778c>] exit_to_kernel_mode+0xdc/0x10c arch/arm64/kernel/entry-common.c:95 hardirqs last disabled at (131135): [<ffff80008ae85378>] __el1_irq arch/arm64/kernel/entry-common.c:533 [inline] hardirqs last disabled at (131135): [<ffff80008ae85378>] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551 softirqs last enabled at (125892): [<ffff80008907e82c>] neigh_hh_init net/core/neighbour.c:1538 [inline] softirqs last enabled at (125892): [<ffff80008907e82c>] neigh_resolve_output+0x268/0x658 net/core/neighbour.c:1553 softirqs last disabled at (125896): [<ffff80008904166c>] local_bh_disable+0x10/0x34 include/linux/bottom_half.h:19 CPU: 1 PID: 24 Comm: kworker/1:0 Not tainted 6.9.0-rc7-syzkaller-gfda5695d692c #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 Workqueue: mld mld_ifc_work pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __list_del include/linux/list.h:195 [inline] pc : __list_del_entry include/linux/list.h:218 [inline] pc : list_move_tail include/linux/list.h:310 [inline] pc : fq_tin_dequeue include/net/fq_impl.h:112 [inline] pc : ieee80211_tx_dequeue+0x6b8/0x3b4c net/mac80211/tx.c:3854 lr : __list_del_entry include/linux/list.h:218 [inline] lr : list_move_tail include/linux/list.h:310 [inline] lr : fq_tin_dequeue include/net/fq_impl.h:112 [inline] lr : ieee80211_tx_dequeue+0x67c/0x3b4c net/mac80211/tx.c:3854 sp : ffff800093d36700 x29: ffff800093d36a60 x28: ffff800093d36960 x27: dfff800000000000 x26: ffff0000d800ad50 x25: ffff0000d800abe0 x24: ffff0000d800abf0 x23: ffff0000e0032468 x22: ffff0000e00324d4 x21: ffff0000d800abf0 x20: ffff0000d800abf8 x19: ffff0000d800abf0 x18: ffff800093d363c0 x17: 000000000000d476 x16: ffff8000805519dc x15: ffff7000127a6cc8 x14: 1ffff000127a6cc8 x13: 0000000000000004 x12: ffffffffffffffff x11: ffff7000127a6cc8 x10: 0000000000ff0100 x9 : 0000000000000000 x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 x5 : ffff80009287aa08 x4 : 0000000000000008 x3 : ffff80008034c7fc x2 : ffff0000e0032468 x1 : 00000000da0e46b8 x0 : ffff0000e0032470 Call trace: __list_del include/linux/list.h:195 [inline] __list_del_entry include/linux/list.h:218 [inline] list_move_tail include/linux/list.h:310 [inline] fq_tin_dequeue include/net/fq_impl.h:112 [inline] ieee80211_tx_dequeue+0x6b8/0x3b4c net/mac80211/tx.c:3854 wake_tx_push_queue net/mac80211/util.c:294 [inline] ieee80211_handle_wake_tx_queue+0x118/0x274 net/mac80211/util.c:315 drv_wake_tx_queue net/mac80211/driver-ops.h:1350 [inline] schedule_and_wake_txq net/mac80211/driver-ops.h:1357 [inline] ieee80211_queue_skb+0x18e8/0x2244 net/mac80211/tx.c:1664 ieee80211_tx+0x260/0x400 net/mac80211/tx.c:1966 ieee80211_xmit+0x278/0x354 net/mac80211/tx.c:2062 __ieee80211_subif_start_xmit+0xab8/0x122c net/mac80211/tx.c:4338 ieee80211_subif_start_xmit+0xe0/0x438 net/mac80211/tx.c:4532 __netdev_start_xmit include/linux/netdevice.h:4903 [inline] netdev_start_xmit include/linux/netdevice.h:4917 [inline] xmit_one net/core/dev.c:3531 [inline] dev_hard_start_xmit+0x27c/0x938 net/core/dev.c:3547 __dev_queue_xmit+0x1678/0x33fc net/core/dev.c:4341 dev_queue_xmit include/linux/netdevice.h:3091 [inline] neigh_resolve_output+0x558/0x658 net/core/neighbour.c:1563 neigh_output include/net/neighbour.h:542 [inline] ip6_fini ---truncated---(CVE-2024-42114)
In the Linux kernel, the following vulnerability has been resolved:
powerpc: Avoid nmi_enter/nmi_exit in real mode interrupt.
nmi_enter()/nmi_exit() touches per cpu variables which can lead to kernel crash when invoked during real mode interrupt handling (e.g. early HMI/MCE interrupt handler) if percpu allocation comes from vmalloc area.
Early HMI/MCE handlers are called through DEFINE_INTERRUPT_HANDLER_NMI() wrapper which invokes nmi_enter/nmi_exit calls. We don't see any issue when percpu allocation is from the embedded first chunk. However with CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK enabled there are chances where percpu allocation can come from the vmalloc area.
With kernel command line "percpu_alloc=page" we can force percpu allocation to come from vmalloc area and can see kernel crash in machine_check_early:
[ 1.215714] NIP [c000000000e49eb4] rcu_nmi_enter+0x24/0x110 [ 1.215717] LR [c0000000000461a0] machine_check_early+0xf0/0x2c0 [ 1.215719] --- interrupt: 200 [ 1.215720] [c000000fffd73180] [0000000000000000] 0x0 (unreliable) [ 1.215722] [c000000fffd731b0] [0000000000000000] 0x0 [ 1.215724] [c000000fffd73210] [c000000000008364] machine_check_early_common+0x134/0x1f8
Fix this by avoiding use of nmi_enter()/nmi_exit() in real mode if percpu first chunk is not embedded.(CVE-2024-42126)
In the Linux kernel, the following vulnerability has been resolved:
leds: an30259a: Use devm_mutex_init() for mutex initialization
In this driver LEDs are registered using devm_led_classdev_register() so they are automatically unregistered after module's remove() is done. led_classdev_unregister() calls module's led_set_brightness() to turn off the LEDs and that callback uses mutex which was destroyed already in module's remove() so use devm API instead.(CVE-2024-42128)
In the Linux kernel, the following vulnerability has been resolved:
orangefs: fix out-of-bounds fsid access
Arnd Bergmann sent a patch to fsdevel, he says:
"orangefs_statfs() copies two consecutive fields of the superblock into the statfs structure, which triggers a warning from the string fortification helpers"
Jan Kara suggested an alternate way to do the patch to make it more readable.
I ran both ideas through xfstests and both seem fine. This patch is based on Jan Kara's suggestion.(CVE-2024-42143)
In the Linux kernel, the following vulnerability has been resolved:
bnx2x: Fix multiple UBSAN array-index-out-of-bounds
Fix UBSAN warnings that occur when using a system with 32 physical cpu cores or more, or when the user defines a number of Ethernet queues greater than or equal to FP_SB_MAX_E1x using the num_queues module parameter.
Currently there is a read/write out of bounds that occurs on the array "struct stats_query_entry query" present inside the "bnx2x_fw_stats_req" struct in "drivers/net/ethernet/broadcom/bnx2x/bnx2x.h". Looking at the definition of the "struct stats_query_entry query" array:
struct stats_query_entry query[FP_SB_MAX_E1x+ BNX2X_FIRST_QUEUE_QUERY_IDX];
FP_SB_MAX_E1x is defined as the maximum number of fast path interrupts and has a value of 16, while BNX2X_FIRST_QUEUE_QUERY_IDX has a value of 3 meaning the array has a total size of 19. Since accesses to "struct stats_query_entry query" are offset-ted by BNX2X_FIRST_QUEUE_QUERY_IDX, that means that the total number of Ethernet queues should not exceed FP_SB_MAX_E1x (16). However one of these queues is reserved for FCOE and thus the number of Ethernet queues should be set to [FP_SB_MAX_E1x -1] (15) if FCOE is enabled or [FP_SB_MAX_E1x] (16) if it is not.
This is also described in a comment in the source code in drivers/net/ethernet/broadcom/bnx2x/bnx2x.h just above the Macro definition of FP_SB_MAX_E1x. Below is the part of this explanation that it important for this patch
/ * The total number of L2 queues, MSIX vectors and HW contexts (CIDs) is * control by the number of fast-path status blocks supported by the * device (HW/FW). Each fast-path status block (FP-SB) aka non-default * status block represents an independent interrupts context that can * serve a regular L2 networking queue. However special L2 queues such * as the FCoE queue do not require a FP-SB and other components like * the CNIC may consume FP-SB reducing the number of possible L2 queues * * If the maximum number of FP-SB available is X then: * a. If CNIC is supported it consumes 1 FP-SB thus the max number of * regular L2 queues is Y=X-1 * b. In MF mode the actual number of L2 queues is Y= (X-1/MF_factor) * c. If the FCoE L2 queue is supported the actual number of L2 queues * is Y+1 * d. The number of irqs (MSIX vectors) is either Y+1 (one extra for * slow-path interrupts) or Y+2 if CNIC is supported (one additional * FP interrupt context for the CNIC). * e. The number of HW context (CID count) is always X or X+1 if FCoE * L2 queue is supported. The cid for the FCoE L2 queue is always X. /
However this driver also supports NICs that use the E2 controller which can handle more queues due to having more FP-SB represented by FP_SB_MAX_E2. Looking at the commits when the E2 support was added, it was originally using the E1x parameters: commit f2e0899f0f27 ("bnx2x: Add 57712 support"). Back then FP_SB_MAX_E2 was set to 16 the same as E1x. However the driver was later updated to take full advantage of the E2 instead of having it be limited to the capabilities of the E1x. But as far as we can tell, the array "stats_query_entry query" was still limited to using the FP-SB available to the E1x cards as part of an oversignt when the driver was updated to take full advantage of the E2, and now with the driver being aware of the greater queue size supported by E2 NICs, it causes the UBSAN warnings seen in the stack traces below.
This patch increases the size of the "stats_query_entry query" array by replacing FP_SB_MAX_E1x with FP_SB_MAX_E2 to be large enough to handle both types of NICs.
Stack traces:
UBSAN: array-index-out-of-bounds in drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.c:1529:11 index 20 is out of range for type 'stats_query_entry [19]' CPU: 12 PID: 858 Comm: systemd-network Not tainted 6.9.0-060900rc7-generic #202405052133 Hardware name: HP ProLiant DL360 Gen9/ProLiant DL360 ---truncated---(CVE-2024-42148)
In the Linux kernel, the following vulnerability has been resolved:
tcp_metrics: validate source addr length
I don't see anything checking that TCP_METRICS_ATTR_SADDR_IPV4 is at least 4 bytes long, and the policy doesn't have an entry for this attribute at all (neither does it for IPv6 but v6 is manually validated).(CVE-2024-42154)
In the Linux kernel, the following vulnerability has been resolved:
s390/pkey: Wipe copies of clear-key structures on failure
Wipe all sensitive data from stack for all IOCTLs, which convert a clear-key into a protected- or secure-key.(CVE-2024-42156)
In the Linux kernel, the following vulnerability has been resolved:
s390/pkey: Wipe sensitive data on failure
Wipe sensitive data from stack also if the copy_to_user() fails.(CVE-2024-42157)
In the Linux kernel, the following vulnerability has been resolved:
s390/pkey: Use kfree_sensitive() to fix Coccinelle warnings
Replace memzero_explicit() and kfree() with kfree_sensitive() to fix warnings reported by Coccinelle:
WARNING opportunity for kfree_sensitive/kvfree_sensitive (line 1506) WARNING opportunity for kfree_sensitive/kvfree_sensitive (line 1643) WARNING opportunity for kfree_sensitive/kvfree_sensitive (line 1770)(CVE-2024-42158)
In the Linux kernel, the following vulnerability has been resolved:
media: dvb-frontends: tda10048: Fix integer overflow
state->xtal_hz can be up to 16M, so it can overflow a 32 bit integer when multiplied by pll_mfactor.
Create a new 64 bit variable to hold the calculations.(CVE-2024-42223)
In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: replace skb_put with skb_put_zero
Avoid potentially reusing uninitialized data(CVE-2024-42225)
In the Linux kernel, the following vulnerability has been resolved:
crypto: aead,cipher - zeroize key buffer after use
I.G 9.7.B for FIPS 140-3 specifies that variables temporarily holding cryptographic information should be zeroized once they are no longer needed. Accomplish this by using kfree_sensitive for buffers that previously held the private key.(CVE-2024-42229)
In the Linux kernel, the following vulnerability has been resolved:
USB: serial: mos7840: fix crash on resume
Since commit c49cfa917025 ("USB: serial: use generic method if no alternative is provided in usb serial layer"), USB serial core calls the generic resume implementation when the driver has not provided one.
This can trigger a crash on resume with mos7840 since support for multiple read URBs was added back in 2011. Specifically, both port read URBs are now submitted on resume for open ports, but the context pointer of the second URB is left set to the core rather than mos7840 port structure.
Fix this by implementing dedicated suspend and resume functions for mos7840.
Tested with Delock 87414 USB 2.0 to 4x serial adapter.
In the Linux kernel, the following vulnerability has been resolved:
net, sunrpc: Remap EPERM in case of connection failure in xs_tcp_setup_socket
When using a BPF program on kernel_connect(), the call can return -EPERM. This causes xs_tcp_setup_socket() to loop forever, filling up the syslog and causing the kernel to potentially freeze up.
Neil suggested:
This will propagate -EPERM up into other layers which might not be ready to handle it. It might be safer to map EPERM to an error we would be more likely to expect from the network system - such as ECONNREFUSED or ENETDOWN.
ECONNREFUSED as error seems reasonable. For programs setting a different error can be out of reach (see handling in 4fbac77d2d09) in particular on kernels which do not have f10d05966196 ("bpf: Make BPF_PROG_RUN_ARRAY return -err instead of allow boolean"), thus given that it is better to simply remap for consistent behavior. UDP does handle EPERM in xs_udp_send_request().(CVE-2024-42246)
In the Linux kernel, the following vulnerability has been resolved:
wireguard: allowedips: avoid unaligned 64-bit memory accesses
On the parisc platform, the kernel issues kernel warnings because swap_endian() tries to load a 128-bit IPv6 address from an unaligned memory location:
Kernel: unaligned access to 0x55f4688c in wg_allowedips_insert_v6+0x2c/0x80 [wireguard] (iir 0xf3010df) Kernel: unaligned access to 0x55f46884 in wg_allowedips_insert_v6+0x38/0x80 [wireguard] (iir 0xf2010dc)
Avoid such unaligned memory accesses by instead using the get_unaligned_be64() helper macro.
| URL | Type | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-5.10.0-223.0.0.122.oe2203sp4.aarch64.rpm",
"bpftool-debuginfo-5.10.0-223.0.0.122.oe2203sp4.aarch64.rpm",
"kernel-5.10.0-223.0.0.122.oe2203sp4.aarch64.rpm",
"kernel-debuginfo-5.10.0-223.0.0.122.oe2203sp4.aarch64.rpm",
"kernel-debugsource-5.10.0-223.0.0.122.oe2203sp4.aarch64.rpm",
"kernel-devel-5.10.0-223.0.0.122.oe2203sp4.aarch64.rpm",
"kernel-headers-5.10.0-223.0.0.122.oe2203sp4.aarch64.rpm",
"kernel-source-5.10.0-223.0.0.122.oe2203sp4.aarch64.rpm",
"kernel-tools-5.10.0-223.0.0.122.oe2203sp4.aarch64.rpm",
"kernel-tools-debuginfo-5.10.0-223.0.0.122.oe2203sp4.aarch64.rpm",
"kernel-tools-devel-5.10.0-223.0.0.122.oe2203sp4.aarch64.rpm",
"perf-5.10.0-223.0.0.122.oe2203sp4.aarch64.rpm",
"perf-debuginfo-5.10.0-223.0.0.122.oe2203sp4.aarch64.rpm",
"python3-perf-5.10.0-223.0.0.122.oe2203sp4.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-223.0.0.122.oe2203sp4.aarch64.rpm"
],
"src": [
"kernel-5.10.0-223.0.0.122.oe2203sp4.src.rpm"
],
"x86_64": [
"bpftool-5.10.0-223.0.0.122.oe2203sp4.x86_64.rpm",
"bpftool-debuginfo-5.10.0-223.0.0.122.oe2203sp4.x86_64.rpm",
"kernel-5.10.0-223.0.0.122.oe2203sp4.x86_64.rpm",
"kernel-debuginfo-5.10.0-223.0.0.122.oe2203sp4.x86_64.rpm",
"kernel-debugsource-5.10.0-223.0.0.122.oe2203sp4.x86_64.rpm",
"kernel-devel-5.10.0-223.0.0.122.oe2203sp4.x86_64.rpm",
"kernel-headers-5.10.0-223.0.0.122.oe2203sp4.x86_64.rpm",
"kernel-source-5.10.0-223.0.0.122.oe2203sp4.x86_64.rpm",
"kernel-tools-5.10.0-223.0.0.122.oe2203sp4.x86_64.rpm",
"kernel-tools-debuginfo-5.10.0-223.0.0.122.oe2203sp4.x86_64.rpm",
"kernel-tools-devel-5.10.0-223.0.0.122.oe2203sp4.x86_64.rpm",
"perf-5.10.0-223.0.0.122.oe2203sp4.x86_64.rpm",
"perf-debuginfo-5.10.0-223.0.0.122.oe2203sp4.x86_64.rpm",
"python3-perf-5.10.0-223.0.0.122.oe2203sp4.x86_64.rpm",
"python3-perf-debuginfo-5.10.0-223.0.0.122.oe2203sp4.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:22.03-LTS-SP4",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP4"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.10.0-223.0.0.122.oe2203sp4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nUSB: core: Make do_proc_control() and do_proc_bulk() killable\r\n\r\nThe USBDEVFS_CONTROL and USBDEVFS_BULK ioctls invoke\nusb_start_wait_urb(), which contains an uninterruptible wait with a\nuser-specified timeout value. If timeout value is very large and the\ndevice being accessed does not respond in a reasonable amount of time,\nthe kernel will complain about \u0026quot;Task X blocked for more than N\nseconds\u0026quot;, as found in testing by syzbot:\r\n\r\nINFO: task syz-executor.0:8700 blocked for more than 143 seconds.\n Not tainted 5.14.0-rc7-syzkaller #0\n\u0026quot;echo 0 \u0026gt; /proc/sys/kernel/hung_task_timeout_secs\u0026quot; disables this message.\ntask:syz-executor.0 state:D stack:23192 pid: 8700 ppid: 8455 flags:0x00004004\nCall Trace:\n context_switch kernel/sched/core.c:4681 [inline]\n __schedule+0xc07/0x11f0 kernel/sched/core.c:5938\n schedule+0x14b/0x210 kernel/sched/core.c:6017\n schedule_timeout+0x98/0x2f0 kernel/time/timer.c:1857\n do_wait_for_common+0x2da/0x480 kernel/sched/completion.c:85\n __wait_for_common kernel/sched/completion.c:106 [inline]\n wait_for_common kernel/sched/completion.c:117 [inline]\n wait_for_completion_timeout+0x46/0x60 kernel/sched/completion.c:157\n usb_start_wait_urb+0x167/0x550 drivers/usb/core/message.c:63\n do_proc_bulk+0x978/0x1080 drivers/usb/core/devio.c:1236\n proc_bulk drivers/usb/core/devio.c:1273 [inline]\n usbdev_do_ioctl drivers/usb/core/devio.c:2547 [inline]\n usbdev_ioctl+0x3441/0x6b10 drivers/usb/core/devio.c:2713\n...\r\n\r\nTo fix this problem, this patch replaces usbfs\u0026apos;s calls to\nusb_control_msg() and usb_bulk_msg() with special-purpose code that\ndoes essentially the same thing (as recommended in the comment for\nusb_start_wait_urb()), except that it always uses a killable wait and\nit uses GFP_KERNEL rather than GFP_NOIO.(CVE-2021-47582)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: mediatek: vcodec: Only free buffer VA that is not NULL\r\n\r\nIn the MediaTek vcodec driver, while mtk_vcodec_mem_free() is mostly\ncalled only when the buffer to free exists, there are some instances\nthat didn\u0026apos;t do the check and triggered warnings in practice.\r\n\r\nWe believe those checks were forgotten unintentionally. Add the checks\nback to fix the warnings.(CVE-2023-52888)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nHID: core: remove unnecessary WARN_ON() in implement()\r\n\r\nSyzkaller hit a warning [1] in a call to implement() when trying\nto write a value into a field of smaller size in an output report.\r\n\r\nSince implement() already has a warn message printed out with the\nhelp of hid_warn() and value in question gets trimmed with:\n\t...\n\tvalue \u0026amp;= m;\n\t...\nWARN_ON may be considered superfluous. Remove it to suppress future\nsyzkaller triggers.\r\n\r\n[1]\nWARNING: CPU: 0 PID: 5084 at drivers/hid/hid-core.c:1451 implement drivers/hid/hid-core.c:1451 [inline]\nWARNING: CPU: 0 PID: 5084 at drivers/hid/hid-core.c:1451 hid_output_report+0x548/0x760 drivers/hid/hid-core.c:1863\nModules linked in:\nCPU: 0 PID: 5084 Comm: syz-executor424 Not tainted 6.9.0-rc7-syzkaller-00183-gcf87f46fd34d #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024\nRIP: 0010:implement drivers/hid/hid-core.c:1451 [inline]\nRIP: 0010:hid_output_report+0x548/0x760 drivers/hid/hid-core.c:1863\n...\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __usbhid_submit_report drivers/hid/usbhid/hid-core.c:591 [inline]\n usbhid_submit_report+0x43d/0x9e0 drivers/hid/usbhid/hid-core.c:636\n hiddev_ioctl+0x138b/0x1f00 drivers/hid/usbhid/hiddev.c:726\n vfs_ioctl fs/ioctl.c:51 [inline]\n __do_sys_ioctl fs/ioctl.c:904 [inline]\n __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:890\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n...(CVE-2024-39509)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: mac80211: mesh: Fix leak of mesh_preq_queue objects\r\n\r\nThe hwmp code use objects of type mesh_preq_queue, added to a list in\nieee80211_if_mesh, to keep track of mpath we need to resolve. If the mpath\ngets deleted, ex mesh interface is removed, the entries in that list will\nnever get cleaned. Fix this by flushing all corresponding items of the\npreq_queue in mesh_path_flush_pending().\r\n\r\nThis should take care of KASAN reports like this:\r\n\r\nunreferenced object 0xffff00000668d800 (size 128):\n comm \u0026quot;kworker/u8:4\u0026quot;, pid 67, jiffies 4295419552 (age 1836.444s)\n hex dump (first 32 bytes):\n 00 1f 05 09 00 00 ff ff 00 d5 68 06 00 00 ff ff ..........h.....\n 8e 97 ea eb 3e b8 01 00 00 00 00 00 00 00 00 00 ....\u0026gt;...........\n backtrace:\n [\u0026lt;000000007302a0b6\u0026gt;] __kmem_cache_alloc_node+0x1e0/0x35c\n [\u0026lt;00000000049bd418\u0026gt;] kmalloc_trace+0x34/0x80\n [\u0026lt;0000000000d792bb\u0026gt;] mesh_queue_preq+0x44/0x2a8\n [\u0026lt;00000000c99c3696\u0026gt;] mesh_nexthop_resolve+0x198/0x19c\n [\u0026lt;00000000926bf598\u0026gt;] ieee80211_xmit+0x1d0/0x1f4\n [\u0026lt;00000000fc8c2284\u0026gt;] __ieee80211_subif_start_xmit+0x30c/0x764\n [\u0026lt;000000005926ee38\u0026gt;] ieee80211_subif_start_xmit+0x9c/0x7a4\n [\u0026lt;000000004c86e916\u0026gt;] dev_hard_start_xmit+0x174/0x440\n [\u0026lt;0000000023495647\u0026gt;] __dev_queue_xmit+0xe24/0x111c\n [\u0026lt;00000000cfe9ca78\u0026gt;] batadv_send_skb_packet+0x180/0x1e4\n [\u0026lt;000000007bacc5d5\u0026gt;] batadv_v_elp_periodic_work+0x2f4/0x508\n [\u0026lt;00000000adc3cd94\u0026gt;] process_one_work+0x4b8/0xa1c\n [\u0026lt;00000000b36425d1\u0026gt;] worker_thread+0x9c/0x634\n [\u0026lt;0000000005852dd5\u0026gt;] kthread+0x1bc/0x1c4\n [\u0026lt;000000005fccd770\u0026gt;] ret_from_fork+0x10/0x20\nunreferenced object 0xffff000009051f00 (size 128):\n comm \u0026quot;kworker/u8:4\u0026quot;, pid 67, jiffies 4295419553 (age 1836.440s)\n hex dump (first 32 bytes):\n 90 d6 92 0d 00 00 ff ff 00 d8 68 06 00 00 ff ff ..........h.....\n 36 27 92 e4 02 e0 01 00 00 58 79 06 00 00 ff ff 6\u0026apos;.......Xy.....\n backtrace:\n [\u0026lt;000000007302a0b6\u0026gt;] __kmem_cache_alloc_node+0x1e0/0x35c\n [\u0026lt;00000000049bd418\u0026gt;] kmalloc_trace+0x34/0x80\n [\u0026lt;0000000000d792bb\u0026gt;] mesh_queue_preq+0x44/0x2a8\n [\u0026lt;00000000c99c3696\u0026gt;] mesh_nexthop_resolve+0x198/0x19c\n [\u0026lt;00000000926bf598\u0026gt;] ieee80211_xmit+0x1d0/0x1f4\n [\u0026lt;00000000fc8c2284\u0026gt;] __ieee80211_subif_start_xmit+0x30c/0x764\n [\u0026lt;000000005926ee38\u0026gt;] ieee80211_subif_start_xmit+0x9c/0x7a4\n [\u0026lt;000000004c86e916\u0026gt;] dev_hard_start_xmit+0x174/0x440\n [\u0026lt;0000000023495647\u0026gt;] __dev_queue_xmit+0xe24/0x111c\n [\u0026lt;00000000cfe9ca78\u0026gt;] batadv_send_skb_packet+0x180/0x1e4\n [\u0026lt;000000007bacc5d5\u0026gt;] batadv_v_elp_periodic_work+0x2f4/0x508\n [\u0026lt;00000000adc3cd94\u0026gt;] process_one_work+0x4b8/0xa1c\n [\u0026lt;00000000b36425d1\u0026gt;] worker_thread+0x9c/0x634\n [\u0026lt;0000000005852dd5\u0026gt;] kthread+0x1bc/0x1c4\n [\u0026lt;000000005fccd770\u0026gt;] ret_from_fork+0x10/0x20(CVE-2024-40942)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndmaengine: idxd: Fix possible Use-After-Free in irq_process_work_list\r\n\r\nUse list_for_each_entry_safe() to allow iterating through the list and\ndeleting the entry in the iteration process. The descriptor is freed via\nidxd_desc_complete() and there\u0026apos;s a slight chance may cause issue for\nthe list iterator when the descriptor is reused by another thread\nwithout it being deleted from the list.(CVE-2024-40956)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nRDMA/mlx5: Add check for srq max_sge attribute\r\n\r\nmax_sge attribute is passed by the user, and is inserted and used\nunchecked, so verify that the value doesn\u0026apos;t exceed maximum allowed value\nbefore using it.(CVE-2024-40990)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfilelock: Remove locks reliably when fcntl/close race is detected\r\n\r\nWhen fcntl_setlk() races with close(), it removes the created lock with\ndo_lock_file_wait().\nHowever, LSMs can allow the first do_lock_file_wait() that created the lock\nwhile denying the second do_lock_file_wait() that tries to remove the lock.\nSeparately, posix_lock_file() could also fail to\nremove a lock due to GFP_KERNEL allocation failure (when splitting a range\nin the middle).\r\n\r\nAfter the bug has been triggered, use-after-free reads will occur in\nlock_get_status() when userspace reads /proc/locks. This can likely be used\nto read arbitrary kernel memory, but can\u0026apos;t corrupt kernel memory.\r\n\r\nFix it by calling locks_remove_posix() instead, which is designed to\nreliably get rid of POSIX locks associated with the given file and\nfiles_struct and is also used by filp_flush().(CVE-2024-41012)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: fix kernel bug on rename operation of broken directory\r\n\r\nSyzbot reported that in rename directory operation on broken directory on\nnilfs2, __block_write_begin_int() called to prepare block write may fail\nBUG_ON check for access exceeding the folio/page size.\r\n\r\nThis is because nilfs_dotdot(), which gets parent directory reference\nentry (\u0026quot;..\u0026quot;) of the directory to be moved or renamed, does not check\nconsistency enough, and may return location exceeding folio/page size for\nbroken directories.\r\n\r\nFix this issue by checking required directory entries (\u0026quot;.\u0026quot; and \u0026quot;..\u0026quot;) in\nthe first chunk of the directory in nilfs_dotdot().(CVE-2024-41034)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nUSB: core: Fix duplicate endpoint bug by clearing reserved bits in the descriptor\r\n\r\nSyzbot has identified a bug in usbcore (see the Closes: tag below)\ncaused by our assumption that the reserved bits in an endpoint\ndescriptor\u0026apos;s bEndpointAddress field will always be 0. As a result of\nthe bug, the endpoint_is_duplicate() routine in config.c (and possibly\nother routines as well) may believe that two descriptors are for\ndistinct endpoints, even though they have the same direction and\nendpoint number. This can lead to confusion, including the bug\nidentified by syzbot (two descriptors with matching endpoint numbers\nand directions, where one was interrupt and the other was bulk).\r\n\r\nTo fix the bug, we will clear the reserved bits in bEndpointAddress\nwhen we parse the descriptor. (Note that both the USB-2.0 and USB-3.1\nspecs say these bits are \u0026quot;Reserved, reset to zero\u0026quot;.) This requires us\nto make a copy of the descriptor earlier in usb_parse_endpoint() and\nuse the copy instead of the original when checking for duplicates.(CVE-2024-41035)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nf_tables: prefer nft_chain_validate\r\n\r\nnft_chain_validate already performs loop detection because a cycle will\nresult in a call stack overflow (ctx-\u0026gt;level \u0026gt;= NFT_JUMP_STACK_SIZE).\r\n\r\nIt also follows maps via -\u0026gt;validate callback in nft_lookup, so there\nappears no reason to iterate the maps again.\r\n\r\nnf_tables_check_loops() and all its helper functions can be removed.\nThis improves ruleset load time significantly, from 23s down to 12s.\r\n\r\nThis also fixes a crash bug. Old loop detection code can result in\nunbounded recursion:\r\n\r\nBUG: TASK stack guard page was hit at ....\nOops: stack guard page: 0000 [#1] PREEMPT SMP KASAN\nCPU: 4 PID: 1539 Comm: nft Not tainted 6.10.0-rc5+ #1\n[..]\r\n\r\nwith a suitable ruleset during validation of register stores.\r\n\r\nI can\u0026apos;t see any actual reason to attempt to check for this from\nnft_validate_register_store(), at this point the transaction is still in\nprogress, so we don\u0026apos;t have a full picture of the rule graph.\r\n\r\nFor nf-next it might make sense to either remove it or make this depend\non table-\u0026gt;validate_state in case we could catch an error earlier\n(for improved error reporting to userspace).(CVE-2024-41042)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: ethernet: lantiq_etop: fix double free in detach\r\n\r\nThe number of the currently released descriptor is never incremented\nwhich results in the same skb being released multiple times.(CVE-2024-41046)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npowerpc/pseries: Whitelist dtl slub object for copying to userspace\r\n\r\nReading the dispatch trace log from /sys/kernel/debug/powerpc/dtl/cpu-*\nresults in a BUG() when the config CONFIG_HARDENED_USERCOPY is enabled as\nshown below.\r\n\r\n kernel BUG at mm/usercopy.c:102!\n Oops: Exception in kernel mode, sig: 5 [#1]\n LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries\n Modules linked in: xfs libcrc32c dm_service_time sd_mod t10_pi sg ibmvfc\n scsi_transport_fc ibmveth pseries_wdt dm_multipath dm_mirror dm_region_hash dm_log dm_mod fuse\n CPU: 27 PID: 1815 Comm: python3 Not tainted 6.10.0-rc3 #85\n Hardware name: IBM,9040-MRX POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1060.00 (NM1060_042) hv:phyp pSeries\n NIP: c0000000005d23d4 LR: c0000000005d23d0 CTR: 00000000006ee6f8\n REGS: c000000120c078c0 TRAP: 0700 Not tainted (6.10.0-rc3)\n MSR: 8000000000029033 \u0026lt;SF,EE,ME,IR,DR,RI,LE\u0026gt; CR: 2828220f XER: 0000000e\n CFAR: c0000000001fdc80 IRQMASK: 0\n [ ... GPRs omitted ... ]\n NIP [c0000000005d23d4] usercopy_abort+0x78/0xb0\n LR [c0000000005d23d0] usercopy_abort+0x74/0xb0\n Call Trace:\n usercopy_abort+0x74/0xb0 (unreliable)\n __check_heap_object+0xf8/0x120\n check_heap_object+0x218/0x240\n __check_object_size+0x84/0x1a4\n dtl_file_read+0x17c/0x2c4\n full_proxy_read+0x8c/0x110\n vfs_read+0xdc/0x3a0\n ksys_read+0x84/0x144\n system_call_exception+0x124/0x330\n system_call_vectored_common+0x15c/0x2ec\n --- interrupt: 3000 at 0x7fff81f3ab34\r\n\r\nCommit 6d07d1cd300f (\u0026quot;usercopy: Restrict non-usercopy caches to size 0\u0026quot;)\nrequires that only whitelisted areas in slab/slub objects can be copied to\nuserspace when usercopy hardening is enabled using CONFIG_HARDENED_USERCOPY.\nDtl contains hypervisor dispatch events which are expected to be read by\nprivileged users. Hence mark this safe for user access.\nSpecify useroffset=0 and usersize=DISPATCH_LOG_BYTES to whitelist the\nentire object.(CVE-2024-41065)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: qgroup: fix quota root leak after quota disable failure\r\n\r\nIf during the quota disable we fail when cleaning the quota tree or when\ndeleting the root from the root tree, we jump to the \u0026apos;out\u0026apos; label without\never dropping the reference on the quota root, resulting in a leak of the\nroot since fs_info-\u0026gt;quota_root is no longer pointing to the root (we have\nset it to NULL just before those steps).\r\n\r\nFix this by always doing a btrfs_put_root() call under the \u0026apos;out\u0026apos; label.\nThis is a problem that exists since qgroups were first added in 2012 by\ncommit bed92eae26cc (\u0026quot;Btrfs: qgroup implementation and prototypes\u0026quot;), but\nback then we missed a kfree on the quota root and free_extent_buffer()\ncalls on its root and commit root nodes, since back then roots were not\nyet reference counted.(CVE-2024-41078)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/i915/gt: Fix potential UAF by revoke of fence registers\r\n\r\nCI has been sporadically reporting the following issue triggered by\nigt@i915_selftest@live@hangcheck on ADL-P and similar machines:\r\n\r\n\u0026lt;6\u0026gt; [414.049203] i915: Running intel_hangcheck_live_selftests/igt_reset_evict_fence\n...\n\u0026lt;6\u0026gt; [414.068804] i915 0000:00:02.0: [drm] GT0: GUC: submission enabled\n\u0026lt;6\u0026gt; [414.068812] i915 0000:00:02.0: [drm] GT0: GUC: SLPC enabled\n\u0026lt;3\u0026gt; [414.070354] Unable to pin Y-tiled fence; err:-4\n\u0026lt;3\u0026gt; [414.071282] i915_vma_revoke_fence:301 GEM_BUG_ON(!i915_active_is_idle(\u0026amp;fence-\u0026gt;active))\n...\n\u0026lt;4\u0026gt;[ 609.603992] ------------[ cut here ]------------\n\u0026lt;2\u0026gt;[ 609.603995] kernel BUG at drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c:301!\n\u0026lt;4\u0026gt;[ 609.604003] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI\n\u0026lt;4\u0026gt;[ 609.604006] CPU: 0 PID: 268 Comm: kworker/u64:3 Tainted: G U W 6.9.0-CI_DRM_14785-g1ba62f8cea9c+ #1\n\u0026lt;4\u0026gt;[ 609.604008] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023\n\u0026lt;4\u0026gt;[ 609.604010] Workqueue: i915 __i915_gem_free_work [i915]\n\u0026lt;4\u0026gt;[ 609.604149] RIP: 0010:i915_vma_revoke_fence+0x187/0x1f0 [i915]\n...\n\u0026lt;4\u0026gt;[ 609.604271] Call Trace:\n\u0026lt;4\u0026gt;[ 609.604273] \u0026lt;TASK\u0026gt;\n...\n\u0026lt;4\u0026gt;[ 609.604716] __i915_vma_evict+0x2e9/0x550 [i915]\n\u0026lt;4\u0026gt;[ 609.604852] __i915_vma_unbind+0x7c/0x160 [i915]\n\u0026lt;4\u0026gt;[ 609.604977] force_unbind+0x24/0xa0 [i915]\n\u0026lt;4\u0026gt;[ 609.605098] i915_vma_destroy+0x2f/0xa0 [i915]\n\u0026lt;4\u0026gt;[ 609.605210] __i915_gem_object_pages_fini+0x51/0x2f0 [i915]\n\u0026lt;4\u0026gt;[ 609.605330] __i915_gem_free_objects.isra.0+0x6a/0xc0 [i915]\n\u0026lt;4\u0026gt;[ 609.605440] process_scheduled_works+0x351/0x690\n...\r\n\r\nIn the past, there were similar failures reported by CI from other IGT\ntests, observed on other platforms.\r\n\r\nBefore commit 63baf4f3d587 (\u0026quot;drm/i915/gt: Only wait for GPU activity\nbefore unbinding a GGTT fence\u0026quot;), i915_vma_revoke_fence() was waiting for\nidleness of vma-\u0026gt;active via fence_update(). That commit introduced\nvma-\u0026gt;fence-\u0026gt;active in order for the fence_update() to be able to wait\nselectively on that one instead of vma-\u0026gt;active since only idleness of\nfence registers was needed. But then, another commit 0d86ee35097a\n(\u0026quot;drm/i915/gt: Make fence revocation unequivocal\u0026quot;) replaced the call to\nfence_update() in i915_vma_revoke_fence() with only fence_write(), and\nalso added that GEM_BUG_ON(!i915_active_is_idle(\u0026amp;fence-\u0026gt;active)) in front.\nNo justification was provided on why we might then expect idleness of\nvma-\u0026gt;fence-\u0026gt;active without first waiting on it.\r\n\r\nThe issue can be potentially caused by a race among revocation of fence\nregisters on one side and sequential execution of signal callbacks invoked\non completion of a request that was using them on the other, still\nprocessed in parallel to revocation of those fence registers. Fix it by\nwaiting for idleness of vma-\u0026gt;fence-\u0026gt;active in i915_vma_revoke_fence().\r\n\r\n(cherry picked from commit 24bb052d3dd499c5956abad5f7d8e4fd07da7fb1)(CVE-2024-41092)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/panel: ilitek-ili9881c: Fix warning with GPIO controllers that sleep\r\n\r\nThe ilitek-ili9881c controls the reset GPIO using the non-sleeping\ngpiod_set_value() function. This complains loudly when the GPIO\ncontroller needs to sleep. As the caller can sleep, use\ngpiod_set_value_cansleep() to fix the issue.(CVE-2024-42087)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nserial: 8250_omap: Implementation of Errata i2310\r\n\r\nAs per Errata i2310[0], Erroneous timeout can be triggered,\nif this Erroneous interrupt is not cleared then it may leads\nto storm of interrupts, therefore apply Errata i2310 solution.\r\n\r\n[0] https://www.ti.com/lit/pdf/sprz536 page 23(CVE-2024-42095)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nx86: stop playing stack games in profile_pc()\r\n\r\nThe \u0026apos;profile_pc()\u0026apos; function is used for timer-based profiling, which\nisn\u0026apos;t really all that relevant any more to begin with, but it also ends\nup making assumptions based on the stack layout that aren\u0026apos;t necessarily\nvalid.\r\n\r\nBasically, the code tries to account the time spent in spinlocks to the\ncaller rather than the spinlock, and while I support that as a concept,\nit\u0026apos;s not worth the code complexity or the KASAN warnings when no serious\nprofiling is done using timers anyway these days.\r\n\r\nAnd the code really does depend on stack layout that is only true in the\nsimplest of cases. We\u0026apos;ve lost the comment at some point (I think when\nthe 32-bit and 64-bit code was unified), but it used to say:\r\n\r\n\tAssume the lock function has either no stack frame or a copy\n\tof eflags from PUSHF.\r\n\r\nwhich explains why it just blindly loads a word or two straight off the\nstack pointer and then takes a minimal look at the values to just check\nif they might be eflags or the return pc:\r\n\r\n\tEflags always has bits 22 and up cleared unlike kernel addresses\r\n\r\nbut that basic stack layout assumption assumes that there isn\u0026apos;t any lock\ndebugging etc going on that would complicate the code and cause a stack\nframe.\r\n\r\nIt causes KASAN unhappiness reported for years by syzkaller [1] and\nothers [2].\r\n\r\nWith no real practical reason for this any more, just remove the code.\r\n\r\nJust for historical interest, here\u0026apos;s some background commits relating to\nthis code from 2006:\r\n\r\n 0cb91a229364 (\u0026quot;i386: Account spinlocks to the caller during profiling for !FP kernels\u0026quot;)\n 31679f38d886 (\u0026quot;Simplify profile_pc on x86-64\u0026quot;)\r\n\r\nand a code unification from 2009:\r\n\r\n ef4512882dbe (\u0026quot;x86: time_32/64.c unify profile_pc\u0026quot;)\r\n\r\nbut the basics of this thing actually goes back to before the git tree.(CVE-2024-42096)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncrypto: ecdh - explicitly zeroize private_key\r\n\r\nprivate_key is overwritten with the key parameter passed in by the\ncaller (if present), or alternatively a newly generated private key.\nHowever, it is possible that the caller provides a key (or the newly\ngenerated key) which is shorter than the previous key. In that\nscenario, some key material from the previous key would not be\noverwritten. The easiest solution is to explicitly zeroize the entire\nprivate_key array first.\r\n\r\nNote that this patch slightly changes the behavior of this function:\npreviously, if the ecc_gen_privkey failed, the old private_key would\nremain. Now, the private_key is always zeroized. This behavior is\nconsistent with the case where params.key is set and ecc_is_key_valid\nfails.(CVE-2024-42098)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: fix inode number range checks\r\n\r\nPatch series \u0026quot;nilfs2: fix potential issues related to reserved inodes\u0026quot;.\r\n\r\nThis series fixes one use-after-free issue reported by syzbot, caused by\nnilfs2\u0026apos;s internal inode being exposed in the namespace on a corrupted\nfilesystem, and a couple of flaws that cause problems if the starting\nnumber of non-reserved inodes written in the on-disk super block is\nintentionally (or corruptly) changed from its default value. \r\n\r\n\nThis patch (of 3):\r\n\r\nIn the current implementation of nilfs2, \u0026quot;nilfs-\u0026gt;ns_first_ino\u0026quot;, which\ngives the first non-reserved inode number, is read from the superblock,\nbut its lower limit is not checked.\r\n\r\nAs a result, if a number that overlaps with the inode number range of\nreserved inodes such as the root directory or metadata files is set in the\nsuper block parameter, the inode number test macros (NILFS_MDT_INODE and\nNILFS_VALID_INODE) will not function properly.\r\n\r\nIn addition, these test macros use left bit-shift calculations using with\nthe inode number as the shift count via the BIT macro, but the result of a\nshift calculation that exceeds the bit width of an integer is undefined in\nthe C specification, so if \u0026quot;ns_first_ino\u0026quot; is set to a large value other\nthan the default value NILFS_USER_INO (=11), the macros may potentially\nmalfunction depending on the environment.\r\n\r\nFix these issues by checking the lower bound of \u0026quot;nilfs-\u0026gt;ns_first_ino\u0026quot; and\nby preventing bit shifts equal to or greater than the NILFS_USER_INO\nconstant in the inode number test macros.\r\n\r\nAlso, change the type of \u0026quot;ns_first_ino\u0026quot; from signed integer to unsigned\ninteger to avoid the need for type casting in comparisons such as the\nlower bound check introduced this time.(CVE-2024-42105)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: cfg80211: restrict NL80211_ATTR_TXQ_QUANTUM values\r\n\r\nsyzbot is able to trigger softlockups, setting NL80211_ATTR_TXQ_QUANTUM\nto 2^31.\r\n\r\nWe had a similar issue in sch_fq, fixed with commit\nd9e15a273306 (\u0026quot;pkt_sched: fq: do not accept silly TCA_FQ_QUANTUM\u0026quot;)\r\n\r\nwatchdog: BUG: soft lockup - CPU#1 stuck for 26s! [kworker/1:0:24]\nModules linked in:\nirq event stamp: 131135\n hardirqs last enabled at (131134): [\u0026lt;ffff80008ae8778c\u0026gt;] __exit_to_kernel_mode arch/arm64/kernel/entry-common.c:85 [inline]\n hardirqs last enabled at (131134): [\u0026lt;ffff80008ae8778c\u0026gt;] exit_to_kernel_mode+0xdc/0x10c arch/arm64/kernel/entry-common.c:95\n hardirqs last disabled at (131135): [\u0026lt;ffff80008ae85378\u0026gt;] __el1_irq arch/arm64/kernel/entry-common.c:533 [inline]\n hardirqs last disabled at (131135): [\u0026lt;ffff80008ae85378\u0026gt;] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551\n softirqs last enabled at (125892): [\u0026lt;ffff80008907e82c\u0026gt;] neigh_hh_init net/core/neighbour.c:1538 [inline]\n softirqs last enabled at (125892): [\u0026lt;ffff80008907e82c\u0026gt;] neigh_resolve_output+0x268/0x658 net/core/neighbour.c:1553\n softirqs last disabled at (125896): [\u0026lt;ffff80008904166c\u0026gt;] local_bh_disable+0x10/0x34 include/linux/bottom_half.h:19\nCPU: 1 PID: 24 Comm: kworker/1:0 Not tainted 6.9.0-rc7-syzkaller-gfda5695d692c #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024\nWorkqueue: mld mld_ifc_work\npstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : __list_del include/linux/list.h:195 [inline]\n pc : __list_del_entry include/linux/list.h:218 [inline]\n pc : list_move_tail include/linux/list.h:310 [inline]\n pc : fq_tin_dequeue include/net/fq_impl.h:112 [inline]\n pc : ieee80211_tx_dequeue+0x6b8/0x3b4c net/mac80211/tx.c:3854\n lr : __list_del_entry include/linux/list.h:218 [inline]\n lr : list_move_tail include/linux/list.h:310 [inline]\n lr : fq_tin_dequeue include/net/fq_impl.h:112 [inline]\n lr : ieee80211_tx_dequeue+0x67c/0x3b4c net/mac80211/tx.c:3854\nsp : ffff800093d36700\nx29: ffff800093d36a60 x28: ffff800093d36960 x27: dfff800000000000\nx26: ffff0000d800ad50 x25: ffff0000d800abe0 x24: ffff0000d800abf0\nx23: ffff0000e0032468 x22: ffff0000e00324d4 x21: ffff0000d800abf0\nx20: ffff0000d800abf8 x19: ffff0000d800abf0 x18: ffff800093d363c0\nx17: 000000000000d476 x16: ffff8000805519dc x15: ffff7000127a6cc8\nx14: 1ffff000127a6cc8 x13: 0000000000000004 x12: ffffffffffffffff\nx11: ffff7000127a6cc8 x10: 0000000000ff0100 x9 : 0000000000000000\nx8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000\nx5 : ffff80009287aa08 x4 : 0000000000000008 x3 : ffff80008034c7fc\nx2 : ffff0000e0032468 x1 : 00000000da0e46b8 x0 : ffff0000e0032470\nCall trace:\n __list_del include/linux/list.h:195 [inline]\n __list_del_entry include/linux/list.h:218 [inline]\n list_move_tail include/linux/list.h:310 [inline]\n fq_tin_dequeue include/net/fq_impl.h:112 [inline]\n ieee80211_tx_dequeue+0x6b8/0x3b4c net/mac80211/tx.c:3854\n wake_tx_push_queue net/mac80211/util.c:294 [inline]\n ieee80211_handle_wake_tx_queue+0x118/0x274 net/mac80211/util.c:315\n drv_wake_tx_queue net/mac80211/driver-ops.h:1350 [inline]\n schedule_and_wake_txq net/mac80211/driver-ops.h:1357 [inline]\n ieee80211_queue_skb+0x18e8/0x2244 net/mac80211/tx.c:1664\n ieee80211_tx+0x260/0x400 net/mac80211/tx.c:1966\n ieee80211_xmit+0x278/0x354 net/mac80211/tx.c:2062\n __ieee80211_subif_start_xmit+0xab8/0x122c net/mac80211/tx.c:4338\n ieee80211_subif_start_xmit+0xe0/0x438 net/mac80211/tx.c:4532\n __netdev_start_xmit include/linux/netdevice.h:4903 [inline]\n netdev_start_xmit include/linux/netdevice.h:4917 [inline]\n xmit_one net/core/dev.c:3531 [inline]\n dev_hard_start_xmit+0x27c/0x938 net/core/dev.c:3547\n __dev_queue_xmit+0x1678/0x33fc net/core/dev.c:4341\n dev_queue_xmit include/linux/netdevice.h:3091 [inline]\n neigh_resolve_output+0x558/0x658 net/core/neighbour.c:1563\n neigh_output include/net/neighbour.h:542 [inline]\n ip6_fini\n---truncated---(CVE-2024-42114)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npowerpc: Avoid nmi_enter/nmi_exit in real mode interrupt.\r\n\r\nnmi_enter()/nmi_exit() touches per cpu variables which can lead to kernel\ncrash when invoked during real mode interrupt handling (e.g. early HMI/MCE\ninterrupt handler) if percpu allocation comes from vmalloc area.\r\n\r\nEarly HMI/MCE handlers are called through DEFINE_INTERRUPT_HANDLER_NMI()\nwrapper which invokes nmi_enter/nmi_exit calls. We don\u0026apos;t see any issue when\npercpu allocation is from the embedded first chunk. However with\nCONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK enabled there are chances where percpu\nallocation can come from the vmalloc area.\r\n\r\nWith kernel command line \u0026quot;percpu_alloc=page\u0026quot; we can force percpu allocation\nto come from vmalloc area and can see kernel crash in machine_check_early:\r\n\r\n[ 1.215714] NIP [c000000000e49eb4] rcu_nmi_enter+0x24/0x110\n[ 1.215717] LR [c0000000000461a0] machine_check_early+0xf0/0x2c0\n[ 1.215719] --- interrupt: 200\n[ 1.215720] [c000000fffd73180] [0000000000000000] 0x0 (unreliable)\n[ 1.215722] [c000000fffd731b0] [0000000000000000] 0x0\n[ 1.215724] [c000000fffd73210] [c000000000008364] machine_check_early_common+0x134/0x1f8\r\n\r\nFix this by avoiding use of nmi_enter()/nmi_exit() in real mode if percpu\nfirst chunk is not embedded.(CVE-2024-42126)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nleds: an30259a: Use devm_mutex_init() for mutex initialization\r\n\r\nIn this driver LEDs are registered using devm_led_classdev_register()\nso they are automatically unregistered after module\u0026apos;s remove() is done.\nled_classdev_unregister() calls module\u0026apos;s led_set_brightness() to turn off\nthe LEDs and that callback uses mutex which was destroyed already\nin module\u0026apos;s remove() so use devm API instead.(CVE-2024-42128)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\norangefs: fix out-of-bounds fsid access\r\n\r\nArnd Bergmann sent a patch to fsdevel, he says:\r\n\r\n\u0026quot;orangefs_statfs() copies two consecutive fields of the superblock into\nthe statfs structure, which triggers a warning from the string fortification\nhelpers\u0026quot;\r\n\r\nJan Kara suggested an alternate way to do the patch to make it more readable.\r\n\r\nI ran both ideas through xfstests and both seem fine. This patch\nis based on Jan Kara\u0026apos;s suggestion.(CVE-2024-42143)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbnx2x: Fix multiple UBSAN array-index-out-of-bounds\r\n\r\nFix UBSAN warnings that occur when using a system with 32 physical\ncpu cores or more, or when the user defines a number of Ethernet\nqueues greater than or equal to FP_SB_MAX_E1x using the num_queues\nmodule parameter.\r\n\r\nCurrently there is a read/write out of bounds that occurs on the array\n\u0026quot;struct stats_query_entry query\u0026quot; present inside the \u0026quot;bnx2x_fw_stats_req\u0026quot;\nstruct in \u0026quot;drivers/net/ethernet/broadcom/bnx2x/bnx2x.h\u0026quot;.\nLooking at the definition of the \u0026quot;struct stats_query_entry query\u0026quot; array:\r\n\r\nstruct stats_query_entry query[FP_SB_MAX_E1x+\n BNX2X_FIRST_QUEUE_QUERY_IDX];\r\n\r\nFP_SB_MAX_E1x is defined as the maximum number of fast path interrupts and\nhas a value of 16, while BNX2X_FIRST_QUEUE_QUERY_IDX has a value of 3\nmeaning the array has a total size of 19.\nSince accesses to \u0026quot;struct stats_query_entry query\u0026quot; are offset-ted by\nBNX2X_FIRST_QUEUE_QUERY_IDX, that means that the total number of Ethernet\nqueues should not exceed FP_SB_MAX_E1x (16). However one of these queues\nis reserved for FCOE and thus the number of Ethernet queues should be set\nto [FP_SB_MAX_E1x -1] (15) if FCOE is enabled or [FP_SB_MAX_E1x] (16) if\nit is not.\r\n\r\nThis is also described in a comment in the source code in\ndrivers/net/ethernet/broadcom/bnx2x/bnx2x.h just above the Macro definition\nof FP_SB_MAX_E1x. Below is the part of this explanation that it important\nfor this patch\r\n\r\n/*\n * The total number of L2 queues, MSIX vectors and HW contexts (CIDs) is\n * control by the number of fast-path status blocks supported by the\n * device (HW/FW). Each fast-path status block (FP-SB) aka non-default\n * status block represents an independent interrupts context that can\n * serve a regular L2 networking queue. However special L2 queues such\n * as the FCoE queue do not require a FP-SB and other components like\n * the CNIC may consume FP-SB reducing the number of possible L2 queues\n *\n * If the maximum number of FP-SB available is X then:\n * a. If CNIC is supported it consumes 1 FP-SB thus the max number of\n * regular L2 queues is Y=X-1\n * b. In MF mode the actual number of L2 queues is Y= (X-1/MF_factor)\n * c. If the FCoE L2 queue is supported the actual number of L2 queues\n * is Y+1\n * d. The number of irqs (MSIX vectors) is either Y+1 (one extra for\n * slow-path interrupts) or Y+2 if CNIC is supported (one additional\n * FP interrupt context for the CNIC).\n * e. The number of HW context (CID count) is always X or X+1 if FCoE\n * L2 queue is supported. The cid for the FCoE L2 queue is always X.\n */\r\n\r\nHowever this driver also supports NICs that use the E2 controller which can\nhandle more queues due to having more FP-SB represented by FP_SB_MAX_E2.\nLooking at the commits when the E2 support was added, it was originally\nusing the E1x parameters: commit f2e0899f0f27 (\u0026quot;bnx2x: Add 57712 support\u0026quot;).\nBack then FP_SB_MAX_E2 was set to 16 the same as E1x. However the driver\nwas later updated to take full advantage of the E2 instead of having it be\nlimited to the capabilities of the E1x. But as far as we can tell, the\narray \u0026quot;stats_query_entry query\u0026quot; was still limited to using the FP-SB\navailable to the E1x cards as part of an oversignt when the driver was\nupdated to take full advantage of the E2, and now with the driver being\naware of the greater queue size supported by E2 NICs, it causes the UBSAN\nwarnings seen in the stack traces below.\r\n\r\nThis patch increases the size of the \u0026quot;stats_query_entry query\u0026quot; array by\nreplacing FP_SB_MAX_E1x with FP_SB_MAX_E2 to be large enough to handle\nboth types of NICs.\r\n\r\nStack traces:\r\n\r\nUBSAN: array-index-out-of-bounds in\n drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.c:1529:11\nindex 20 is out of range for type \u0026apos;stats_query_entry [19]\u0026apos;\nCPU: 12 PID: 858 Comm: systemd-network Not tainted 6.9.0-060900rc7-generic\n\t #202405052133\nHardware name: HP ProLiant DL360 Gen9/ProLiant DL360 \n---truncated---(CVE-2024-42148)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntcp_metrics: validate source addr length\r\n\r\nI don\u0026apos;t see anything checking that TCP_METRICS_ATTR_SADDR_IPV4\nis at least 4 bytes long, and the policy doesn\u0026apos;t have an entry\nfor this attribute at all (neither does it for IPv6 but v6 is\nmanually validated).(CVE-2024-42154)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ns390/pkey: Wipe copies of clear-key structures on failure\r\n\r\nWipe all sensitive data from stack for all IOCTLs, which convert a\nclear-key into a protected- or secure-key.(CVE-2024-42156)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ns390/pkey: Wipe sensitive data on failure\r\n\r\nWipe sensitive data from stack also if the copy_to_user() fails.(CVE-2024-42157)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ns390/pkey: Use kfree_sensitive() to fix Coccinelle warnings\r\n\r\nReplace memzero_explicit() and kfree() with kfree_sensitive() to fix\nwarnings reported by Coccinelle:\r\n\r\nWARNING opportunity for kfree_sensitive/kvfree_sensitive (line 1506)\nWARNING opportunity for kfree_sensitive/kvfree_sensitive (line 1643)\nWARNING opportunity for kfree_sensitive/kvfree_sensitive (line 1770)(CVE-2024-42158)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: dvb-frontends: tda10048: Fix integer overflow\r\n\r\nstate-\u0026gt;xtal_hz can be up to 16M, so it can overflow a 32 bit integer\nwhen multiplied by pll_mfactor.\r\n\r\nCreate a new 64 bit variable to hold the calculations.(CVE-2024-42223)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: mt76: replace skb_put with skb_put_zero\r\n\r\nAvoid potentially reusing uninitialized data(CVE-2024-42225)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncrypto: aead,cipher - zeroize key buffer after use\r\n\r\nI.G 9.7.B for FIPS 140-3 specifies that variables temporarily holding\ncryptographic information should be zeroized once they are no longer\nneeded. Accomplish this by using kfree_sensitive for buffers that\npreviously held the private key.(CVE-2024-42229)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nUSB: serial: mos7840: fix crash on resume\r\n\r\nSince commit c49cfa917025 (\u0026quot;USB: serial: use generic method if no\nalternative is provided in usb serial layer\u0026quot;), USB serial core calls the\ngeneric resume implementation when the driver has not provided one.\r\n\r\nThis can trigger a crash on resume with mos7840 since support for\nmultiple read URBs was added back in 2011. Specifically, both port read\nURBs are now submitted on resume for open ports, but the context pointer\nof the second URB is left set to the core rather than mos7840 port\nstructure.\r\n\r\nFix this by implementing dedicated suspend and resume functions for\nmos7840.\r\n\r\nTested with Delock 87414 USB 2.0 to 4x serial adapter.\r\n\r\n[ johan: analyse crash and rewrite commit message; set busy flag on\n resume; drop bulk-in check; drop unnecessary usb_kill_urb() ](CVE-2024-42244)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet, sunrpc: Remap EPERM in case of connection failure in xs_tcp_setup_socket\r\n\r\nWhen using a BPF program on kernel_connect(), the call can return -EPERM. This\ncauses xs_tcp_setup_socket() to loop forever, filling up the syslog and causing\nthe kernel to potentially freeze up.\r\n\r\nNeil suggested:\r\n\r\n This will propagate -EPERM up into other layers which might not be ready\n to handle it. It might be safer to map EPERM to an error we would be more\n likely to expect from the network system - such as ECONNREFUSED or ENETDOWN.\r\n\r\nECONNREFUSED as error seems reasonable. For programs setting a different error\ncan be out of reach (see handling in 4fbac77d2d09) in particular on kernels\nwhich do not have f10d05966196 (\u0026quot;bpf: Make BPF_PROG_RUN_ARRAY return -err\ninstead of allow boolean\u0026quot;), thus given that it is better to simply remap for\nconsistent behavior. UDP does handle EPERM in xs_udp_send_request().(CVE-2024-42246)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwireguard: allowedips: avoid unaligned 64-bit memory accesses\r\n\r\nOn the parisc platform, the kernel issues kernel warnings because\nswap_endian() tries to load a 128-bit IPv6 address from an unaligned\nmemory location:\r\n\r\n Kernel: unaligned access to 0x55f4688c in wg_allowedips_insert_v6+0x2c/0x80 [wireguard] (iir 0xf3010df)\n Kernel: unaligned access to 0x55f46884 in wg_allowedips_insert_v6+0x38/0x80 [wireguard] (iir 0xf2010dc)\r\n\r\nAvoid such unaligned memory accesses by instead using the\nget_unaligned_be64() helper macro.\r\n\r\n[Jason: replace src[8] in original patch with src+8](CVE-2024-42247)",
"id": "OESA-2024-1994",
"modified": "2026-08-06T11:07:28Z",
"published": "2024-08-16T11:07:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1994"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47582"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52888"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39509"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40942"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40956"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40990"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41012"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41034"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41035"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41042"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41046"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41065"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41078"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41092"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42087"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42095"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42096"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42098"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42105"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42114"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42126"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42128"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42143"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42148"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42154"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42156"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42157"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42158"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42223"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42225"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42229"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42244"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42246"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42247"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2021-47582",
"CVE-2023-52888",
"CVE-2024-39509",
"CVE-2024-40942",
"CVE-2024-40956",
"CVE-2024-40990",
"CVE-2024-41012",
"CVE-2024-41034",
"CVE-2024-41035",
"CVE-2024-41042",
"CVE-2024-41046",
"CVE-2024-41065",
"CVE-2024-41078",
"CVE-2024-41092",
"CVE-2024-42087",
"CVE-2024-42095",
"CVE-2024-42096",
"CVE-2024-42098",
"CVE-2024-42105",
"CVE-2024-42114",
"CVE-2024-42126",
"CVE-2024-42128",
"CVE-2024-42143",
"CVE-2024-42148",
"CVE-2024-42154",
"CVE-2024-42156",
"CVE-2024-42157",
"CVE-2024-42158",
"CVE-2024-42223",
"CVE-2024-42225",
"CVE-2024-42229",
"CVE-2024-42244",
"CVE-2024-42246",
"CVE-2024-42247"
]
}
OESA-2024-1995 (CVE-2021-47582)
Vulnerability from osv_openeuler – Published: 2024-08-16 11:07 – Updated: 2026-08-06 11:07 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
USB: core: Make do_proc_control() and do_proc_bulk() killable
The USBDEVFS_CONTROL and USBDEVFS_BULK ioctls invoke usb_start_wait_urb(), which contains an uninterruptible wait with a user-specified timeout value. If timeout value is very large and the device being accessed does not respond in a reasonable amount of time, the kernel will complain about "Task X blocked for more than N seconds", as found in testing by syzbot:
INFO: task syz-executor.0:8700 blocked for more than 143 seconds. Not tainted 5.14.0-rc7-syzkaller #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:syz-executor.0 state:D stack:23192 pid: 8700 ppid: 8455 flags:0x00004004 Call Trace: context_switch kernel/sched/core.c:4681 [inline] __schedule+0xc07/0x11f0 kernel/sched/core.c:5938 schedule+0x14b/0x210 kernel/sched/core.c:6017 schedule_timeout+0x98/0x2f0 kernel/time/timer.c:1857 do_wait_for_common+0x2da/0x480 kernel/sched/completion.c:85 __wait_for_common kernel/sched/completion.c:106 [inline] wait_for_common kernel/sched/completion.c:117 [inline] wait_for_completion_timeout+0x46/0x60 kernel/sched/completion.c:157 usb_start_wait_urb+0x167/0x550 drivers/usb/core/message.c:63 do_proc_bulk+0x978/0x1080 drivers/usb/core/devio.c:1236 proc_bulk drivers/usb/core/devio.c:1273 [inline] usbdev_do_ioctl drivers/usb/core/devio.c:2547 [inline] usbdev_ioctl+0x3441/0x6b10 drivers/usb/core/devio.c:2713 ...
To fix this problem, this patch replaces usbfs's calls to usb_control_msg() and usb_bulk_msg() with special-purpose code that does essentially the same thing (as recommended in the comment for usb_start_wait_urb()), except that it always uses a killable wait and it uses GFP_KERNEL rather than GFP_NOIO.(CVE-2021-47582)
In the Linux kernel, the following vulnerability has been resolved:
media: mediatek: vcodec: Only free buffer VA that is not NULL
In the MediaTek vcodec driver, while mtk_vcodec_mem_free() is mostly called only when the buffer to free exists, there are some instances that didn't do the check and triggered warnings in practice.
We believe those checks were forgotten unintentionally. Add the checks back to fix the warnings.(CVE-2023-52888)
A race condition was found in the Linux kernel's drm/exynos device driver in exynos_drm_crtc_atomic_disable() function. This can result in a null pointer dereference issue, possibly leading to a kernel panic or denial of service issue.
(CVE-2024-22386)
In the Linux kernel, the following vulnerability has been resolved:
HID: core: remove unnecessary WARN_ON() in implement()
Syzkaller hit a warning [1] in a call to implement() when trying to write a value into a field of smaller size in an output report.
Since implement() already has a warn message printed out with the help of hid_warn() and value in question gets trimmed with: ... value &= m; ... WARN_ON may be considered superfluous. Remove it to suppress future syzkaller triggers.
[1] WARNING: CPU: 0 PID: 5084 at drivers/hid/hid-core.c:1451 implement drivers/hid/hid-core.c:1451 [inline] WARNING: CPU: 0 PID: 5084 at drivers/hid/hid-core.c:1451 hid_output_report+0x548/0x760 drivers/hid/hid-core.c:1863 Modules linked in: CPU: 0 PID: 5084 Comm: syz-executor424 Not tainted 6.9.0-rc7-syzkaller-00183-gcf87f46fd34d #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024 RIP: 0010:implement drivers/hid/hid-core.c:1451 [inline] RIP: 0010:hid_output_report+0x548/0x760 drivers/hid/hid-core.c:1863 ... Call Trace: <TASK> __usbhid_submit_report drivers/hid/usbhid/hid-core.c:591 [inline] usbhid_submit_report+0x43d/0x9e0 drivers/hid/usbhid/hid-core.c:636 hiddev_ioctl+0x138b/0x1f00 drivers/hid/usbhid/hiddev.c:726 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:904 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:890 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f ...(CVE-2024-39509)
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: mesh: Fix leak of mesh_preq_queue objects
The hwmp code use objects of type mesh_preq_queue, added to a list in ieee80211_if_mesh, to keep track of mpath we need to resolve. If the mpath gets deleted, ex mesh interface is removed, the entries in that list will never get cleaned. Fix this by flushing all corresponding items of the preq_queue in mesh_path_flush_pending().
This should take care of KASAN reports like this:
unreferenced object 0xffff00000668d800 (size 128): comm "kworker/u8:4", pid 67, jiffies 4295419552 (age 1836.444s) hex dump (first 32 bytes): 00 1f 05 09 00 00 ff ff 00 d5 68 06 00 00 ff ff ..........h..... 8e 97 ea eb 3e b8 01 00 00 00 00 00 00 00 00 00 ....>........... backtrace: [<000000007302a0b6>] __kmem_cache_alloc_node+0x1e0/0x35c [<00000000049bd418>] kmalloc_trace+0x34/0x80 [<0000000000d792bb>] mesh_queue_preq+0x44/0x2a8 [<00000000c99c3696>] mesh_nexthop_resolve+0x198/0x19c [<00000000926bf598>] ieee80211_xmit+0x1d0/0x1f4 [<00000000fc8c2284>] __ieee80211_subif_start_xmit+0x30c/0x764 [<000000005926ee38>] ieee80211_subif_start_xmit+0x9c/0x7a4 [<000000004c86e916>] dev_hard_start_xmit+0x174/0x440 [<0000000023495647>] __dev_queue_xmit+0xe24/0x111c [<00000000cfe9ca78>] batadv_send_skb_packet+0x180/0x1e4 [<000000007bacc5d5>] batadv_v_elp_periodic_work+0x2f4/0x508 [<00000000adc3cd94>] process_one_work+0x4b8/0xa1c [<00000000b36425d1>] worker_thread+0x9c/0x634 [<0000000005852dd5>] kthread+0x1bc/0x1c4 [<000000005fccd770>] ret_from_fork+0x10/0x20 unreferenced object 0xffff000009051f00 (size 128): comm "kworker/u8:4", pid 67, jiffies 4295419553 (age 1836.440s) hex dump (first 32 bytes): 90 d6 92 0d 00 00 ff ff 00 d8 68 06 00 00 ff ff ..........h..... 36 27 92 e4 02 e0 01 00 00 58 79 06 00 00 ff ff 6'.......Xy..... backtrace: [<000000007302a0b6>] __kmem_cache_alloc_node+0x1e0/0x35c [<00000000049bd418>] kmalloc_trace+0x34/0x80 [<0000000000d792bb>] mesh_queue_preq+0x44/0x2a8 [<00000000c99c3696>] mesh_nexthop_resolve+0x198/0x19c [<00000000926bf598>] ieee80211_xmit+0x1d0/0x1f4 [<00000000fc8c2284>] __ieee80211_subif_start_xmit+0x30c/0x764 [<000000005926ee38>] ieee80211_subif_start_xmit+0x9c/0x7a4 [<000000004c86e916>] dev_hard_start_xmit+0x174/0x440 [<0000000023495647>] __dev_queue_xmit+0xe24/0x111c [<00000000cfe9ca78>] batadv_send_skb_packet+0x180/0x1e4 [<000000007bacc5d5>] batadv_v_elp_periodic_work+0x2f4/0x508 [<00000000adc3cd94>] process_one_work+0x4b8/0xa1c [<00000000b36425d1>] worker_thread+0x9c/0x634 [<0000000005852dd5>] kthread+0x1bc/0x1c4 [<000000005fccd770>] ret_from_fork+0x10/0x20(CVE-2024-40942)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/mlx5: Add check for srq max_sge attribute
max_sge attribute is passed by the user, and is inserted and used unchecked, so verify that the value doesn't exceed maximum allowed value before using it.(CVE-2024-40990)
In the Linux kernel, the following vulnerability has been resolved:
filelock: Remove locks reliably when fcntl/close race is detected
When fcntl_setlk() races with close(), it removes the created lock with do_lock_file_wait(). However, LSMs can allow the first do_lock_file_wait() that created the lock while denying the second do_lock_file_wait() that tries to remove the lock. Separately, posix_lock_file() could also fail to remove a lock due to GFP_KERNEL allocation failure (when splitting a range in the middle).
After the bug has been triggered, use-after-free reads will occur in lock_get_status() when userspace reads /proc/locks. This can likely be used to read arbitrary kernel memory, but can't corrupt kernel memory.
Fix it by calling locks_remove_posix() instead, which is designed to reliably get rid of POSIX locks associated with the given file and files_struct and is also used by filp_flush().(CVE-2024-41012)
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix kernel bug on rename operation of broken directory
Syzbot reported that in rename directory operation on broken directory on nilfs2, __block_write_begin_int() called to prepare block write may fail BUG_ON check for access exceeding the folio/page size.
This is because nilfs_dotdot(), which gets parent directory reference entry ("..") of the directory to be moved or renamed, does not check consistency enough, and may return location exceeding folio/page size for broken directories.
Fix this issue by checking required directory entries ("." and "..") in the first chunk of the directory in nilfs_dotdot().(CVE-2024-41034)
In the Linux kernel, the following vulnerability has been resolved:
USB: core: Fix duplicate endpoint bug by clearing reserved bits in the descriptor
Syzbot has identified a bug in usbcore (see the Closes: tag below) caused by our assumption that the reserved bits in an endpoint descriptor's bEndpointAddress field will always be 0. As a result of the bug, the endpoint_is_duplicate() routine in config.c (and possibly other routines as well) may believe that two descriptors are for distinct endpoints, even though they have the same direction and endpoint number. This can lead to confusion, including the bug identified by syzbot (two descriptors with matching endpoint numbers and directions, where one was interrupt and the other was bulk).
To fix the bug, we will clear the reserved bits in bEndpointAddress when we parse the descriptor. (Note that both the USB-2.0 and USB-3.1 specs say these bits are "Reserved, reset to zero".) This requires us to make a copy of the descriptor earlier in usb_parse_endpoint() and use the copy instead of the original when checking for duplicates.(CVE-2024-41035)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: prefer nft_chain_validate
nft_chain_validate already performs loop detection because a cycle will result in a call stack overflow (ctx->level >= NFT_JUMP_STACK_SIZE).
It also follows maps via ->validate callback in nft_lookup, so there appears no reason to iterate the maps again.
nf_tables_check_loops() and all its helper functions can be removed. This improves ruleset load time significantly, from 23s down to 12s.
This also fixes a crash bug. Old loop detection code can result in unbounded recursion:
BUG: TASK stack guard page was hit at .... Oops: stack guard page: 0000 [#1] PREEMPT SMP KASAN CPU: 4 PID: 1539 Comm: nft Not tainted 6.10.0-rc5+ #1 [..]
with a suitable ruleset during validation of register stores.
I can't see any actual reason to attempt to check for this from nft_validate_register_store(), at this point the transaction is still in progress, so we don't have a full picture of the rule graph.
For nf-next it might make sense to either remove it or make this depend on table->validate_state in case we could catch an error earlier (for improved error reporting to userspace).(CVE-2024-41042)
In the Linux kernel, the following vulnerability has been resolved:
net: ethernet: lantiq_etop: fix double free in detach
The number of the currently released descriptor is never incremented which results in the same skb being released multiple times.(CVE-2024-41046)
In the Linux kernel, the following vulnerability has been resolved:
powerpc/pseries: Whitelist dtl slub object for copying to userspace
Reading the dispatch trace log from /sys/kernel/debug/powerpc/dtl/cpu-* results in a BUG() when the config CONFIG_HARDENED_USERCOPY is enabled as shown below.
kernel BUG at mm/usercopy.c:102!
Oops: Exception in kernel mode, sig: 5 [#1]
LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries
Modules linked in: xfs libcrc32c dm_service_time sd_mod t10_pi sg ibmvfc
scsi_transport_fc ibmveth pseries_wdt dm_multipath dm_mirror dm_region_hash dm_log dm_mod fuse
CPU: 27 PID: 1815 Comm: python3 Not tainted 6.10.0-rc3 #85
Hardware name: IBM,9040-MRX POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1060.00 (NM1060_042) hv:phyp pSeries
NIP: c0000000005d23d4 LR: c0000000005d23d0 CTR: 00000000006ee6f8
REGS: c000000120c078c0 TRAP: 0700 Not tainted (6.10.0-rc3)
MSR: 8000000000029033 <SF,EE,ME,IR,DR,RI,LE> CR: 2828220f XER: 0000000e
CFAR: c0000000001fdc80 IRQMASK: 0
[ ... GPRs omitted ... ]
NIP [c0000000005d23d4] usercopy_abort+0x78/0xb0
LR [c0000000005d23d0] usercopy_abort+0x74/0xb0
Call Trace:
usercopy_abort+0x74/0xb0 (unreliable)
__check_heap_object+0xf8/0x120
check_heap_object+0x218/0x240
__check_object_size+0x84/0x1a4
dtl_file_read+0x17c/0x2c4
full_proxy_read+0x8c/0x110
vfs_read+0xdc/0x3a0
ksys_read+0x84/0x144
system_call_exception+0x124/0x330
system_call_vectored_common+0x15c/0x2ec
--- interrupt: 3000 at 0x7fff81f3ab34
Commit 6d07d1cd300f ("usercopy: Restrict non-usercopy caches to size 0") requires that only whitelisted areas in slab/slub objects can be copied to userspace when usercopy hardening is enabled using CONFIG_HARDENED_USERCOPY. Dtl contains hypervisor dispatch events which are expected to be read by privileged users. Hence mark this safe for user access. Specify useroffset=0 and usersize=DISPATCH_LOG_BYTES to whitelist the entire object.(CVE-2024-41065)
In the Linux kernel, the following vulnerability has been resolved:
btrfs: qgroup: fix quota root leak after quota disable failure
If during the quota disable we fail when cleaning the quota tree or when deleting the root from the root tree, we jump to the 'out' label without ever dropping the reference on the quota root, resulting in a leak of the root since fs_info->quota_root is no longer pointing to the root (we have set it to NULL just before those steps).
Fix this by always doing a btrfs_put_root() call under the 'out' label. This is a problem that exists since qgroups were first added in 2012 by commit bed92eae26cc ("Btrfs: qgroup implementation and prototypes"), but back then we missed a kfree on the quota root and free_extent_buffer() calls on its root and commit root nodes, since back then roots were not yet reference counted.(CVE-2024-41078)
In the Linux kernel, the following vulnerability has been resolved:
drm/i915/gt: Fix potential UAF by revoke of fence registers
CI has been sporadically reporting the following issue triggered by igt@i915_selftest@live@hangcheck on ADL-P and similar machines:
<6> [414.049203] i915: Running intel_hangcheck_live_selftests/igt_reset_evict_fence ... <6> [414.068804] i915 0000:00:02.0: [drm] GT0: GUC: submission enabled <6> [414.068812] i915 0000:00:02.0: [drm] GT0: GUC: SLPC enabled <3> [414.070354] Unable to pin Y-tiled fence; err:-4 <3> [414.071282] i915_vma_revoke_fence:301 GEM_BUG_ON(!i915_active_is_idle(&fence->active)) ... <4>[ 609.603992] ------------[ cut here ]------------ <2>[ 609.603995] kernel BUG at drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c:301! <4>[ 609.604003] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI <4>[ 609.604006] CPU: 0 PID: 268 Comm: kworker/u64:3 Tainted: G U W 6.9.0-CI_DRM_14785-g1ba62f8cea9c+ #1 <4>[ 609.604008] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023 <4>[ 609.604010] Workqueue: i915 __i915_gem_free_work [i915] <4>[ 609.604149] RIP: 0010:i915_vma_revoke_fence+0x187/0x1f0 [i915] ... <4>[ 609.604271] Call Trace: <4>[ 609.604273] <TASK> ... <4>[ 609.604716] __i915_vma_evict+0x2e9/0x550 [i915] <4>[ 609.604852] __i915_vma_unbind+0x7c/0x160 [i915] <4>[ 609.604977] force_unbind+0x24/0xa0 [i915] <4>[ 609.605098] i915_vma_destroy+0x2f/0xa0 [i915] <4>[ 609.605210] __i915_gem_object_pages_fini+0x51/0x2f0 [i915] <4>[ 609.605330] __i915_gem_free_objects.isra.0+0x6a/0xc0 [i915] <4>[ 609.605440] process_scheduled_works+0x351/0x690 ...
In the past, there were similar failures reported by CI from other IGT tests, observed on other platforms.
Before commit 63baf4f3d587 ("drm/i915/gt: Only wait for GPU activity before unbinding a GGTT fence"), i915_vma_revoke_fence() was waiting for idleness of vma->active via fence_update(). That commit introduced vma->fence->active in order for the fence_update() to be able to wait selectively on that one instead of vma->active since only idleness of fence registers was needed. But then, another commit 0d86ee35097a ("drm/i915/gt: Make fence revocation unequivocal") replaced the call to fence_update() in i915_vma_revoke_fence() with only fence_write(), and also added that GEM_BUG_ON(!i915_active_is_idle(&fence->active)) in front. No justification was provided on why we might then expect idleness of vma->fence->active without first waiting on it.
The issue can be potentially caused by a race among revocation of fence registers on one side and sequential execution of signal callbacks invoked on completion of a request that was using them on the other, still processed in parallel to revocation of those fence registers. Fix it by waiting for idleness of vma->fence->active in i915_vma_revoke_fence().
(cherry picked from commit 24bb052d3dd499c5956abad5f7d8e4fd07da7fb1)(CVE-2024-41092)
In the Linux kernel, the following vulnerability has been resolved:
drm/panel: ilitek-ili9881c: Fix warning with GPIO controllers that sleep
The ilitek-ili9881c controls the reset GPIO using the non-sleeping gpiod_set_value() function. This complains loudly when the GPIO controller needs to sleep. As the caller can sleep, use gpiod_set_value_cansleep() to fix the issue.(CVE-2024-42087)
In the Linux kernel, the following vulnerability has been resolved:
serial: 8250_omap: Implementation of Errata i2310
As per Errata i2310[0], Erroneous timeout can be triggered, if this Erroneous interrupt is not cleared then it may leads to storm of interrupts, therefore apply Errata i2310 solution.
[0] https://www.ti.com/lit/pdf/sprz536 page 23(CVE-2024-42095)
In the Linux kernel, the following vulnerability has been resolved:
x86: stop playing stack games in profile_pc()
The 'profile_pc()' function is used for timer-based profiling, which isn't really all that relevant any more to begin with, but it also ends up making assumptions based on the stack layout that aren't necessarily valid.
Basically, the code tries to account the time spent in spinlocks to the caller rather than the spinlock, and while I support that as a concept, it's not worth the code complexity or the KASAN warnings when no serious profiling is done using timers anyway these days.
And the code really does depend on stack layout that is only true in the simplest of cases. We've lost the comment at some point (I think when the 32-bit and 64-bit code was unified), but it used to say:
Assume the lock function has either no stack frame or a copy
of eflags from PUSHF.
which explains why it just blindly loads a word or two straight off the stack pointer and then takes a minimal look at the values to just check if they might be eflags or the return pc:
Eflags always has bits 22 and up cleared unlike kernel addresses
but that basic stack layout assumption assumes that there isn't any lock debugging etc going on that would complicate the code and cause a stack frame.
It causes KASAN unhappiness reported for years by syzkaller [1] and others [2].
With no real practical reason for this any more, just remove the code.
Just for historical interest, here's some background commits relating to this code from 2006:
0cb91a229364 ("i386: Account spinlocks to the caller during profiling for !FP kernels") 31679f38d886 ("Simplify profile_pc on x86-64")
and a code unification from 2009:
ef4512882dbe ("x86: time_32/64.c unify profile_pc")
but the basics of this thing actually goes back to before the git tree.(CVE-2024-42096)
In the Linux kernel, the following vulnerability has been resolved:
crypto: ecdh - explicitly zeroize private_key
private_key is overwritten with the key parameter passed in by the caller (if present), or alternatively a newly generated private key. However, it is possible that the caller provides a key (or the newly generated key) which is shorter than the previous key. In that scenario, some key material from the previous key would not be overwritten. The easiest solution is to explicitly zeroize the entire private_key array first.
Note that this patch slightly changes the behavior of this function: previously, if the ecc_gen_privkey failed, the old private_key would remain. Now, the private_key is always zeroized. This behavior is consistent with the case where params.key is set and ecc_is_key_valid fails.(CVE-2024-42098)
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix inode number range checks
Patch series "nilfs2: fix potential issues related to reserved inodes".
This series fixes one use-after-free issue reported by syzbot, caused by nilfs2's internal inode being exposed in the namespace on a corrupted filesystem, and a couple of flaws that cause problems if the starting number of non-reserved inodes written in the on-disk super block is intentionally (or corruptly) changed from its default value.
This patch (of 3):
In the current implementation of nilfs2, "nilfs->ns_first_ino", which gives the first non-reserved inode number, is read from the superblock, but its lower limit is not checked.
As a result, if a number that overlaps with the inode number range of reserved inodes such as the root directory or metadata files is set in the super block parameter, the inode number test macros (NILFS_MDT_INODE and NILFS_VALID_INODE) will not function properly.
In addition, these test macros use left bit-shift calculations using with the inode number as the shift count via the BIT macro, but the result of a shift calculation that exceeds the bit width of an integer is undefined in the C specification, so if "ns_first_ino" is set to a large value other than the default value NILFS_USER_INO (=11), the macros may potentially malfunction depending on the environment.
Fix these issues by checking the lower bound of "nilfs->ns_first_ino" and by preventing bit shifts equal to or greater than the NILFS_USER_INO constant in the inode number test macros.
Also, change the type of "ns_first_ino" from signed integer to unsigned integer to avoid the need for type casting in comparisons such as the lower bound check introduced this time.(CVE-2024-42105)
In the Linux kernel, the following vulnerability has been resolved:
wifi: cfg80211: restrict NL80211_ATTR_TXQ_QUANTUM values
syzbot is able to trigger softlockups, setting NL80211_ATTR_TXQ_QUANTUM to 2^31.
We had a similar issue in sch_fq, fixed with commit d9e15a273306 ("pkt_sched: fq: do not accept silly TCA_FQ_QUANTUM")
watchdog: BUG: soft lockup - CPU#1 stuck for 26s! [kworker/1:0:24] Modules linked in: irq event stamp: 131135 hardirqs last enabled at (131134): [<ffff80008ae8778c>] __exit_to_kernel_mode arch/arm64/kernel/entry-common.c:85 [inline] hardirqs last enabled at (131134): [<ffff80008ae8778c>] exit_to_kernel_mode+0xdc/0x10c arch/arm64/kernel/entry-common.c:95 hardirqs last disabled at (131135): [<ffff80008ae85378>] __el1_irq arch/arm64/kernel/entry-common.c:533 [inline] hardirqs last disabled at (131135): [<ffff80008ae85378>] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551 softirqs last enabled at (125892): [<ffff80008907e82c>] neigh_hh_init net/core/neighbour.c:1538 [inline] softirqs last enabled at (125892): [<ffff80008907e82c>] neigh_resolve_output+0x268/0x658 net/core/neighbour.c:1553 softirqs last disabled at (125896): [<ffff80008904166c>] local_bh_disable+0x10/0x34 include/linux/bottom_half.h:19 CPU: 1 PID: 24 Comm: kworker/1:0 Not tainted 6.9.0-rc7-syzkaller-gfda5695d692c #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 Workqueue: mld mld_ifc_work pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __list_del include/linux/list.h:195 [inline] pc : __list_del_entry include/linux/list.h:218 [inline] pc : list_move_tail include/linux/list.h:310 [inline] pc : fq_tin_dequeue include/net/fq_impl.h:112 [inline] pc : ieee80211_tx_dequeue+0x6b8/0x3b4c net/mac80211/tx.c:3854 lr : __list_del_entry include/linux/list.h:218 [inline] lr : list_move_tail include/linux/list.h:310 [inline] lr : fq_tin_dequeue include/net/fq_impl.h:112 [inline] lr : ieee80211_tx_dequeue+0x67c/0x3b4c net/mac80211/tx.c:3854 sp : ffff800093d36700 x29: ffff800093d36a60 x28: ffff800093d36960 x27: dfff800000000000 x26: ffff0000d800ad50 x25: ffff0000d800abe0 x24: ffff0000d800abf0 x23: ffff0000e0032468 x22: ffff0000e00324d4 x21: ffff0000d800abf0 x20: ffff0000d800abf8 x19: ffff0000d800abf0 x18: ffff800093d363c0 x17: 000000000000d476 x16: ffff8000805519dc x15: ffff7000127a6cc8 x14: 1ffff000127a6cc8 x13: 0000000000000004 x12: ffffffffffffffff x11: ffff7000127a6cc8 x10: 0000000000ff0100 x9 : 0000000000000000 x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 x5 : ffff80009287aa08 x4 : 0000000000000008 x3 : ffff80008034c7fc x2 : ffff0000e0032468 x1 : 00000000da0e46b8 x0 : ffff0000e0032470 Call trace: __list_del include/linux/list.h:195 [inline] __list_del_entry include/linux/list.h:218 [inline] list_move_tail include/linux/list.h:310 [inline] fq_tin_dequeue include/net/fq_impl.h:112 [inline] ieee80211_tx_dequeue+0x6b8/0x3b4c net/mac80211/tx.c:3854 wake_tx_push_queue net/mac80211/util.c:294 [inline] ieee80211_handle_wake_tx_queue+0x118/0x274 net/mac80211/util.c:315 drv_wake_tx_queue net/mac80211/driver-ops.h:1350 [inline] schedule_and_wake_txq net/mac80211/driver-ops.h:1357 [inline] ieee80211_queue_skb+0x18e8/0x2244 net/mac80211/tx.c:1664 ieee80211_tx+0x260/0x400 net/mac80211/tx.c:1966 ieee80211_xmit+0x278/0x354 net/mac80211/tx.c:2062 __ieee80211_subif_start_xmit+0xab8/0x122c net/mac80211/tx.c:4338 ieee80211_subif_start_xmit+0xe0/0x438 net/mac80211/tx.c:4532 __netdev_start_xmit include/linux/netdevice.h:4903 [inline] netdev_start_xmit include/linux/netdevice.h:4917 [inline] xmit_one net/core/dev.c:3531 [inline] dev_hard_start_xmit+0x27c/0x938 net/core/dev.c:3547 __dev_queue_xmit+0x1678/0x33fc net/core/dev.c:4341 dev_queue_xmit include/linux/netdevice.h:3091 [inline] neigh_resolve_output+0x558/0x658 net/core/neighbour.c:1563 neigh_output include/net/neighbour.h:542 [inline] ip6_fini ---truncated---(CVE-2024-42114)
In the Linux kernel, the following vulnerability has been resolved:
powerpc: Avoid nmi_enter/nmi_exit in real mode interrupt.
nmi_enter()/nmi_exit() touches per cpu variables which can lead to kernel crash when invoked during real mode interrupt handling (e.g. early HMI/MCE interrupt handler) if percpu allocation comes from vmalloc area.
Early HMI/MCE handlers are called through DEFINE_INTERRUPT_HANDLER_NMI() wrapper which invokes nmi_enter/nmi_exit calls. We don't see any issue when percpu allocation is from the embedded first chunk. However with CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK enabled there are chances where percpu allocation can come from the vmalloc area.
With kernel command line "percpu_alloc=page" we can force percpu allocation to come from vmalloc area and can see kernel crash in machine_check_early:
[ 1.215714] NIP [c000000000e49eb4] rcu_nmi_enter+0x24/0x110 [ 1.215717] LR [c0000000000461a0] machine_check_early+0xf0/0x2c0 [ 1.215719] --- interrupt: 200 [ 1.215720] [c000000fffd73180] [0000000000000000] 0x0 (unreliable) [ 1.215722] [c000000fffd731b0] [0000000000000000] 0x0 [ 1.215724] [c000000fffd73210] [c000000000008364] machine_check_early_common+0x134/0x1f8
Fix this by avoiding use of nmi_enter()/nmi_exit() in real mode if percpu first chunk is not embedded.(CVE-2024-42126)
In the Linux kernel, the following vulnerability has been resolved:
leds: an30259a: Use devm_mutex_init() for mutex initialization
In this driver LEDs are registered using devm_led_classdev_register() so they are automatically unregistered after module's remove() is done. led_classdev_unregister() calls module's led_set_brightness() to turn off the LEDs and that callback uses mutex which was destroyed already in module's remove() so use devm API instead.(CVE-2024-42128)
In the Linux kernel, the following vulnerability has been resolved:
orangefs: fix out-of-bounds fsid access
Arnd Bergmann sent a patch to fsdevel, he says:
"orangefs_statfs() copies two consecutive fields of the superblock into the statfs structure, which triggers a warning from the string fortification helpers"
Jan Kara suggested an alternate way to do the patch to make it more readable.
I ran both ideas through xfstests and both seem fine. This patch is based on Jan Kara's suggestion.(CVE-2024-42143)
In the Linux kernel, the following vulnerability has been resolved:
bnx2x: Fix multiple UBSAN array-index-out-of-bounds
Fix UBSAN warnings that occur when using a system with 32 physical cpu cores or more, or when the user defines a number of Ethernet queues greater than or equal to FP_SB_MAX_E1x using the num_queues module parameter.
Currently there is a read/write out of bounds that occurs on the array "struct stats_query_entry query" present inside the "bnx2x_fw_stats_req" struct in "drivers/net/ethernet/broadcom/bnx2x/bnx2x.h". Looking at the definition of the "struct stats_query_entry query" array:
struct stats_query_entry query[FP_SB_MAX_E1x+ BNX2X_FIRST_QUEUE_QUERY_IDX];
FP_SB_MAX_E1x is defined as the maximum number of fast path interrupts and has a value of 16, while BNX2X_FIRST_QUEUE_QUERY_IDX has a value of 3 meaning the array has a total size of 19. Since accesses to "struct stats_query_entry query" are offset-ted by BNX2X_FIRST_QUEUE_QUERY_IDX, that means that the total number of Ethernet queues should not exceed FP_SB_MAX_E1x (16). However one of these queues is reserved for FCOE and thus the number of Ethernet queues should be set to [FP_SB_MAX_E1x -1] (15) if FCOE is enabled or [FP_SB_MAX_E1x] (16) if it is not.
This is also described in a comment in the source code in drivers/net/ethernet/broadcom/bnx2x/bnx2x.h just above the Macro definition of FP_SB_MAX_E1x. Below is the part of this explanation that it important for this patch
/ * The total number of L2 queues, MSIX vectors and HW contexts (CIDs) is * control by the number of fast-path status blocks supported by the * device (HW/FW). Each fast-path status block (FP-SB) aka non-default * status block represents an independent interrupts context that can * serve a regular L2 networking queue. However special L2 queues such * as the FCoE queue do not require a FP-SB and other components like * the CNIC may consume FP-SB reducing the number of possible L2 queues * * If the maximum number of FP-SB available is X then: * a. If CNIC is supported it consumes 1 FP-SB thus the max number of * regular L2 queues is Y=X-1 * b. In MF mode the actual number of L2 queues is Y= (X-1/MF_factor) * c. If the FCoE L2 queue is supported the actual number of L2 queues * is Y+1 * d. The number of irqs (MSIX vectors) is either Y+1 (one extra for * slow-path interrupts) or Y+2 if CNIC is supported (one additional * FP interrupt context for the CNIC). * e. The number of HW context (CID count) is always X or X+1 if FCoE * L2 queue is supported. The cid for the FCoE L2 queue is always X. /
However this driver also supports NICs that use the E2 controller which can handle more queues due to having more FP-SB represented by FP_SB_MAX_E2. Looking at the commits when the E2 support was added, it was originally using the E1x parameters: commit f2e0899f0f27 ("bnx2x: Add 57712 support"). Back then FP_SB_MAX_E2 was set to 16 the same as E1x. However the driver was later updated to take full advantage of the E2 instead of having it be limited to the capabilities of the E1x. But as far as we can tell, the array "stats_query_entry query" was still limited to using the FP-SB available to the E1x cards as part of an oversignt when the driver was updated to take full advantage of the E2, and now with the driver being aware of the greater queue size supported by E2 NICs, it causes the UBSAN warnings seen in the stack traces below.
This patch increases the size of the "stats_query_entry query" array by replacing FP_SB_MAX_E1x with FP_SB_MAX_E2 to be large enough to handle both types of NICs.
Stack traces:
UBSAN: array-index-out-of-bounds in drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.c:1529:11 index 20 is out of range for type 'stats_query_entry [19]' CPU: 12 PID: 858 Comm: systemd-network Not tainted 6.9.0-060900rc7-generic #202405052133 Hardware name: HP ProLiant DL360 Gen9/ProLiant DL360 ---truncated---(CVE-2024-42148)
In the Linux kernel, the following vulnerability has been resolved:
tcp_metrics: validate source addr length
I don't see anything checking that TCP_METRICS_ATTR_SADDR_IPV4 is at least 4 bytes long, and the policy doesn't have an entry for this attribute at all (neither does it for IPv6 but v6 is manually validated).(CVE-2024-42154)
In the Linux kernel, the following vulnerability has been resolved:
s390/pkey: Wipe copies of clear-key structures on failure
Wipe all sensitive data from stack for all IOCTLs, which convert a clear-key into a protected- or secure-key.(CVE-2024-42156)
In the Linux kernel, the following vulnerability has been resolved:
s390/pkey: Wipe sensitive data on failure
Wipe sensitive data from stack also if the copy_to_user() fails.(CVE-2024-42157)
In the Linux kernel, the following vulnerability has been resolved:
s390/pkey: Use kfree_sensitive() to fix Coccinelle warnings
Replace memzero_explicit() and kfree() with kfree_sensitive() to fix warnings reported by Coccinelle:
WARNING opportunity for kfree_sensitive/kvfree_sensitive (line 1506) WARNING opportunity for kfree_sensitive/kvfree_sensitive (line 1643) WARNING opportunity for kfree_sensitive/kvfree_sensitive (line 1770)(CVE-2024-42158)
In the Linux kernel, the following vulnerability has been resolved:
media: dvb-frontends: tda10048: Fix integer overflow
state->xtal_hz can be up to 16M, so it can overflow a 32 bit integer when multiplied by pll_mfactor.
Create a new 64 bit variable to hold the calculations.(CVE-2024-42223)
In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: replace skb_put with skb_put_zero
Avoid potentially reusing uninitialized data(CVE-2024-42225)
In the Linux kernel, the following vulnerability has been resolved:
crypto: aead,cipher - zeroize key buffer after use
I.G 9.7.B for FIPS 140-3 specifies that variables temporarily holding cryptographic information should be zeroized once they are no longer needed. Accomplish this by using kfree_sensitive for buffers that previously held the private key.(CVE-2024-42229)
In the Linux kernel, the following vulnerability has been resolved:
USB: serial: mos7840: fix crash on resume
Since commit c49cfa917025 ("USB: serial: use generic method if no alternative is provided in usb serial layer"), USB serial core calls the generic resume implementation when the driver has not provided one.
This can trigger a crash on resume with mos7840 since support for multiple read URBs was added back in 2011. Specifically, both port read URBs are now submitted on resume for open ports, but the context pointer of the second URB is left set to the core rather than mos7840 port structure.
Fix this by implementing dedicated suspend and resume functions for mos7840.
Tested with Delock 87414 USB 2.0 to 4x serial adapter.
In the Linux kernel, the following vulnerability has been resolved:
net, sunrpc: Remap EPERM in case of connection failure in xs_tcp_setup_socket
When using a BPF program on kernel_connect(), the call can return -EPERM. This causes xs_tcp_setup_socket() to loop forever, filling up the syslog and causing the kernel to potentially freeze up.
Neil suggested:
This will propagate -EPERM up into other layers which might not be ready to handle it. It might be safer to map EPERM to an error we would be more likely to expect from the network system - such as ECONNREFUSED or ENETDOWN.
ECONNREFUSED as error seems reasonable. For programs setting a different error can be out of reach (see handling in 4fbac77d2d09) in particular on kernels which do not have f10d05966196 ("bpf: Make BPF_PROG_RUN_ARRAY return -err instead of allow boolean"), thus given that it is better to simply remap for consistent behavior. UDP does handle EPERM in xs_udp_send_request().(CVE-2024-42246)
In the Linux kernel, the following vulnerability has been resolved:
wireguard: allowedips: avoid unaligned 64-bit memory accesses
On the parisc platform, the kernel issues kernel warnings because swap_endian() tries to load a 128-bit IPv6 address from an unaligned memory location:
Kernel: unaligned access to 0x55f4688c in wg_allowedips_insert_v6+0x2c/0x80 [wireguard] (iir 0xf3010df) Kernel: unaligned access to 0x55f46884 in wg_allowedips_insert_v6+0x38/0x80 [wireguard] (iir 0xf2010dc)
Avoid such unaligned memory accesses by instead using the get_unaligned_be64() helper macro.
| URL | Type | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"kernel-5.10.0-223.0.0.126.oe2203sp3.aarch64.rpm",
"kernel-debuginfo-5.10.0-223.0.0.126.oe2203sp3.aarch64.rpm",
"kernel-debugsource-5.10.0-223.0.0.126.oe2203sp3.aarch64.rpm",
"kernel-devel-5.10.0-223.0.0.126.oe2203sp3.aarch64.rpm",
"kernel-headers-5.10.0-223.0.0.126.oe2203sp3.aarch64.rpm",
"kernel-source-5.10.0-223.0.0.126.oe2203sp3.aarch64.rpm",
"kernel-tools-5.10.0-223.0.0.126.oe2203sp3.aarch64.rpm",
"kernel-tools-debuginfo-5.10.0-223.0.0.126.oe2203sp3.aarch64.rpm",
"kernel-tools-devel-5.10.0-223.0.0.126.oe2203sp3.aarch64.rpm",
"perf-5.10.0-223.0.0.126.oe2203sp3.aarch64.rpm",
"perf-debuginfo-5.10.0-223.0.0.126.oe2203sp3.aarch64.rpm",
"python3-perf-5.10.0-223.0.0.126.oe2203sp3.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-223.0.0.126.oe2203sp3.aarch64.rpm"
],
"src": [
"kernel-5.10.0-223.0.0.126.oe2203sp3.src.rpm"
],
"x86_64": [
"kernel-5.10.0-223.0.0.126.oe2203sp3.x86_64.rpm",
"kernel-debuginfo-5.10.0-223.0.0.126.oe2203sp3.x86_64.rpm",
"kernel-debugsource-5.10.0-223.0.0.126.oe2203sp3.x86_64.rpm",
"kernel-devel-5.10.0-223.0.0.126.oe2203sp3.x86_64.rpm",
"kernel-headers-5.10.0-223.0.0.126.oe2203sp3.x86_64.rpm",
"kernel-source-5.10.0-223.0.0.126.oe2203sp3.x86_64.rpm",
"kernel-tools-5.10.0-223.0.0.126.oe2203sp3.x86_64.rpm",
"kernel-tools-debuginfo-5.10.0-223.0.0.126.oe2203sp3.x86_64.rpm",
"kernel-tools-devel-5.10.0-223.0.0.126.oe2203sp3.x86_64.rpm",
"perf-5.10.0-223.0.0.126.oe2203sp3.x86_64.rpm",
"perf-debuginfo-5.10.0-223.0.0.126.oe2203sp3.x86_64.rpm",
"python3-perf-5.10.0-223.0.0.126.oe2203sp3.x86_64.rpm",
"python3-perf-debuginfo-5.10.0-223.0.0.126.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-223.0.0.126.oe2203sp3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nUSB: core: Make do_proc_control() and do_proc_bulk() killable\r\n\r\nThe USBDEVFS_CONTROL and USBDEVFS_BULK ioctls invoke\nusb_start_wait_urb(), which contains an uninterruptible wait with a\nuser-specified timeout value. If timeout value is very large and the\ndevice being accessed does not respond in a reasonable amount of time,\nthe kernel will complain about \u0026quot;Task X blocked for more than N\nseconds\u0026quot;, as found in testing by syzbot:\r\n\r\nINFO: task syz-executor.0:8700 blocked for more than 143 seconds.\n Not tainted 5.14.0-rc7-syzkaller #0\n\u0026quot;echo 0 \u0026gt; /proc/sys/kernel/hung_task_timeout_secs\u0026quot; disables this message.\ntask:syz-executor.0 state:D stack:23192 pid: 8700 ppid: 8455 flags:0x00004004\nCall Trace:\n context_switch kernel/sched/core.c:4681 [inline]\n __schedule+0xc07/0x11f0 kernel/sched/core.c:5938\n schedule+0x14b/0x210 kernel/sched/core.c:6017\n schedule_timeout+0x98/0x2f0 kernel/time/timer.c:1857\n do_wait_for_common+0x2da/0x480 kernel/sched/completion.c:85\n __wait_for_common kernel/sched/completion.c:106 [inline]\n wait_for_common kernel/sched/completion.c:117 [inline]\n wait_for_completion_timeout+0x46/0x60 kernel/sched/completion.c:157\n usb_start_wait_urb+0x167/0x550 drivers/usb/core/message.c:63\n do_proc_bulk+0x978/0x1080 drivers/usb/core/devio.c:1236\n proc_bulk drivers/usb/core/devio.c:1273 [inline]\n usbdev_do_ioctl drivers/usb/core/devio.c:2547 [inline]\n usbdev_ioctl+0x3441/0x6b10 drivers/usb/core/devio.c:2713\n...\r\n\r\nTo fix this problem, this patch replaces usbfs\u0026apos;s calls to\nusb_control_msg() and usb_bulk_msg() with special-purpose code that\ndoes essentially the same thing (as recommended in the comment for\nusb_start_wait_urb()), except that it always uses a killable wait and\nit uses GFP_KERNEL rather than GFP_NOIO.(CVE-2021-47582)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: mediatek: vcodec: Only free buffer VA that is not NULL\r\n\r\nIn the MediaTek vcodec driver, while mtk_vcodec_mem_free() is mostly\ncalled only when the buffer to free exists, there are some instances\nthat didn\u0026apos;t do the check and triggered warnings in practice.\r\n\r\nWe believe those checks were forgotten unintentionally. Add the checks\nback to fix the warnings.(CVE-2023-52888)\r\n\r\nA race condition was found in the Linux kernel\u0026apos;s drm/exynos device driver in\u00a0exynos_drm_crtc_atomic_disable() function. This can result in a null pointer dereference issue, possibly leading to a kernel panic or denial of service issue.\r\n\r\n\n(CVE-2024-22386)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nHID: core: remove unnecessary WARN_ON() in implement()\r\n\r\nSyzkaller hit a warning [1] in a call to implement() when trying\nto write a value into a field of smaller size in an output report.\r\n\r\nSince implement() already has a warn message printed out with the\nhelp of hid_warn() and value in question gets trimmed with:\n\t...\n\tvalue \u0026amp;= m;\n\t...\nWARN_ON may be considered superfluous. Remove it to suppress future\nsyzkaller triggers.\r\n\r\n[1]\nWARNING: CPU: 0 PID: 5084 at drivers/hid/hid-core.c:1451 implement drivers/hid/hid-core.c:1451 [inline]\nWARNING: CPU: 0 PID: 5084 at drivers/hid/hid-core.c:1451 hid_output_report+0x548/0x760 drivers/hid/hid-core.c:1863\nModules linked in:\nCPU: 0 PID: 5084 Comm: syz-executor424 Not tainted 6.9.0-rc7-syzkaller-00183-gcf87f46fd34d #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024\nRIP: 0010:implement drivers/hid/hid-core.c:1451 [inline]\nRIP: 0010:hid_output_report+0x548/0x760 drivers/hid/hid-core.c:1863\n...\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __usbhid_submit_report drivers/hid/usbhid/hid-core.c:591 [inline]\n usbhid_submit_report+0x43d/0x9e0 drivers/hid/usbhid/hid-core.c:636\n hiddev_ioctl+0x138b/0x1f00 drivers/hid/usbhid/hiddev.c:726\n vfs_ioctl fs/ioctl.c:51 [inline]\n __do_sys_ioctl fs/ioctl.c:904 [inline]\n __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:890\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n...(CVE-2024-39509)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: mac80211: mesh: Fix leak of mesh_preq_queue objects\r\n\r\nThe hwmp code use objects of type mesh_preq_queue, added to a list in\nieee80211_if_mesh, to keep track of mpath we need to resolve. If the mpath\ngets deleted, ex mesh interface is removed, the entries in that list will\nnever get cleaned. Fix this by flushing all corresponding items of the\npreq_queue in mesh_path_flush_pending().\r\n\r\nThis should take care of KASAN reports like this:\r\n\r\nunreferenced object 0xffff00000668d800 (size 128):\n comm \u0026quot;kworker/u8:4\u0026quot;, pid 67, jiffies 4295419552 (age 1836.444s)\n hex dump (first 32 bytes):\n 00 1f 05 09 00 00 ff ff 00 d5 68 06 00 00 ff ff ..........h.....\n 8e 97 ea eb 3e b8 01 00 00 00 00 00 00 00 00 00 ....\u0026gt;...........\n backtrace:\n [\u0026lt;000000007302a0b6\u0026gt;] __kmem_cache_alloc_node+0x1e0/0x35c\n [\u0026lt;00000000049bd418\u0026gt;] kmalloc_trace+0x34/0x80\n [\u0026lt;0000000000d792bb\u0026gt;] mesh_queue_preq+0x44/0x2a8\n [\u0026lt;00000000c99c3696\u0026gt;] mesh_nexthop_resolve+0x198/0x19c\n [\u0026lt;00000000926bf598\u0026gt;] ieee80211_xmit+0x1d0/0x1f4\n [\u0026lt;00000000fc8c2284\u0026gt;] __ieee80211_subif_start_xmit+0x30c/0x764\n [\u0026lt;000000005926ee38\u0026gt;] ieee80211_subif_start_xmit+0x9c/0x7a4\n [\u0026lt;000000004c86e916\u0026gt;] dev_hard_start_xmit+0x174/0x440\n [\u0026lt;0000000023495647\u0026gt;] __dev_queue_xmit+0xe24/0x111c\n [\u0026lt;00000000cfe9ca78\u0026gt;] batadv_send_skb_packet+0x180/0x1e4\n [\u0026lt;000000007bacc5d5\u0026gt;] batadv_v_elp_periodic_work+0x2f4/0x508\n [\u0026lt;00000000adc3cd94\u0026gt;] process_one_work+0x4b8/0xa1c\n [\u0026lt;00000000b36425d1\u0026gt;] worker_thread+0x9c/0x634\n [\u0026lt;0000000005852dd5\u0026gt;] kthread+0x1bc/0x1c4\n [\u0026lt;000000005fccd770\u0026gt;] ret_from_fork+0x10/0x20\nunreferenced object 0xffff000009051f00 (size 128):\n comm \u0026quot;kworker/u8:4\u0026quot;, pid 67, jiffies 4295419553 (age 1836.440s)\n hex dump (first 32 bytes):\n 90 d6 92 0d 00 00 ff ff 00 d8 68 06 00 00 ff ff ..........h.....\n 36 27 92 e4 02 e0 01 00 00 58 79 06 00 00 ff ff 6\u0026apos;.......Xy.....\n backtrace:\n [\u0026lt;000000007302a0b6\u0026gt;] __kmem_cache_alloc_node+0x1e0/0x35c\n [\u0026lt;00000000049bd418\u0026gt;] kmalloc_trace+0x34/0x80\n [\u0026lt;0000000000d792bb\u0026gt;] mesh_queue_preq+0x44/0x2a8\n [\u0026lt;00000000c99c3696\u0026gt;] mesh_nexthop_resolve+0x198/0x19c\n [\u0026lt;00000000926bf598\u0026gt;] ieee80211_xmit+0x1d0/0x1f4\n [\u0026lt;00000000fc8c2284\u0026gt;] __ieee80211_subif_start_xmit+0x30c/0x764\n [\u0026lt;000000005926ee38\u0026gt;] ieee80211_subif_start_xmit+0x9c/0x7a4\n [\u0026lt;000000004c86e916\u0026gt;] dev_hard_start_xmit+0x174/0x440\n [\u0026lt;0000000023495647\u0026gt;] __dev_queue_xmit+0xe24/0x111c\n [\u0026lt;00000000cfe9ca78\u0026gt;] batadv_send_skb_packet+0x180/0x1e4\n [\u0026lt;000000007bacc5d5\u0026gt;] batadv_v_elp_periodic_work+0x2f4/0x508\n [\u0026lt;00000000adc3cd94\u0026gt;] process_one_work+0x4b8/0xa1c\n [\u0026lt;00000000b36425d1\u0026gt;] worker_thread+0x9c/0x634\n [\u0026lt;0000000005852dd5\u0026gt;] kthread+0x1bc/0x1c4\n [\u0026lt;000000005fccd770\u0026gt;] ret_from_fork+0x10/0x20(CVE-2024-40942)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nRDMA/mlx5: Add check for srq max_sge attribute\r\n\r\nmax_sge attribute is passed by the user, and is inserted and used\nunchecked, so verify that the value doesn\u0026apos;t exceed maximum allowed value\nbefore using it.(CVE-2024-40990)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfilelock: Remove locks reliably when fcntl/close race is detected\r\n\r\nWhen fcntl_setlk() races with close(), it removes the created lock with\ndo_lock_file_wait().\nHowever, LSMs can allow the first do_lock_file_wait() that created the lock\nwhile denying the second do_lock_file_wait() that tries to remove the lock.\nSeparately, posix_lock_file() could also fail to\nremove a lock due to GFP_KERNEL allocation failure (when splitting a range\nin the middle).\r\n\r\nAfter the bug has been triggered, use-after-free reads will occur in\nlock_get_status() when userspace reads /proc/locks. This can likely be used\nto read arbitrary kernel memory, but can\u0026apos;t corrupt kernel memory.\r\n\r\nFix it by calling locks_remove_posix() instead, which is designed to\nreliably get rid of POSIX locks associated with the given file and\nfiles_struct and is also used by filp_flush().(CVE-2024-41012)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: fix kernel bug on rename operation of broken directory\r\n\r\nSyzbot reported that in rename directory operation on broken directory on\nnilfs2, __block_write_begin_int() called to prepare block write may fail\nBUG_ON check for access exceeding the folio/page size.\r\n\r\nThis is because nilfs_dotdot(), which gets parent directory reference\nentry (\u0026quot;..\u0026quot;) of the directory to be moved or renamed, does not check\nconsistency enough, and may return location exceeding folio/page size for\nbroken directories.\r\n\r\nFix this issue by checking required directory entries (\u0026quot;.\u0026quot; and \u0026quot;..\u0026quot;) in\nthe first chunk of the directory in nilfs_dotdot().(CVE-2024-41034)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nUSB: core: Fix duplicate endpoint bug by clearing reserved bits in the descriptor\r\n\r\nSyzbot has identified a bug in usbcore (see the Closes: tag below)\ncaused by our assumption that the reserved bits in an endpoint\ndescriptor\u0026apos;s bEndpointAddress field will always be 0. As a result of\nthe bug, the endpoint_is_duplicate() routine in config.c (and possibly\nother routines as well) may believe that two descriptors are for\ndistinct endpoints, even though they have the same direction and\nendpoint number. This can lead to confusion, including the bug\nidentified by syzbot (two descriptors with matching endpoint numbers\nand directions, where one was interrupt and the other was bulk).\r\n\r\nTo fix the bug, we will clear the reserved bits in bEndpointAddress\nwhen we parse the descriptor. (Note that both the USB-2.0 and USB-3.1\nspecs say these bits are \u0026quot;Reserved, reset to zero\u0026quot;.) This requires us\nto make a copy of the descriptor earlier in usb_parse_endpoint() and\nuse the copy instead of the original when checking for duplicates.(CVE-2024-41035)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nf_tables: prefer nft_chain_validate\r\n\r\nnft_chain_validate already performs loop detection because a cycle will\nresult in a call stack overflow (ctx-\u0026gt;level \u0026gt;= NFT_JUMP_STACK_SIZE).\r\n\r\nIt also follows maps via -\u0026gt;validate callback in nft_lookup, so there\nappears no reason to iterate the maps again.\r\n\r\nnf_tables_check_loops() and all its helper functions can be removed.\nThis improves ruleset load time significantly, from 23s down to 12s.\r\n\r\nThis also fixes a crash bug. Old loop detection code can result in\nunbounded recursion:\r\n\r\nBUG: TASK stack guard page was hit at ....\nOops: stack guard page: 0000 [#1] PREEMPT SMP KASAN\nCPU: 4 PID: 1539 Comm: nft Not tainted 6.10.0-rc5+ #1\n[..]\r\n\r\nwith a suitable ruleset during validation of register stores.\r\n\r\nI can\u0026apos;t see any actual reason to attempt to check for this from\nnft_validate_register_store(), at this point the transaction is still in\nprogress, so we don\u0026apos;t have a full picture of the rule graph.\r\n\r\nFor nf-next it might make sense to either remove it or make this depend\non table-\u0026gt;validate_state in case we could catch an error earlier\n(for improved error reporting to userspace).(CVE-2024-41042)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: ethernet: lantiq_etop: fix double free in detach\r\n\r\nThe number of the currently released descriptor is never incremented\nwhich results in the same skb being released multiple times.(CVE-2024-41046)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npowerpc/pseries: Whitelist dtl slub object for copying to userspace\r\n\r\nReading the dispatch trace log from /sys/kernel/debug/powerpc/dtl/cpu-*\nresults in a BUG() when the config CONFIG_HARDENED_USERCOPY is enabled as\nshown below.\r\n\r\n kernel BUG at mm/usercopy.c:102!\n Oops: Exception in kernel mode, sig: 5 [#1]\n LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries\n Modules linked in: xfs libcrc32c dm_service_time sd_mod t10_pi sg ibmvfc\n scsi_transport_fc ibmveth pseries_wdt dm_multipath dm_mirror dm_region_hash dm_log dm_mod fuse\n CPU: 27 PID: 1815 Comm: python3 Not tainted 6.10.0-rc3 #85\n Hardware name: IBM,9040-MRX POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1060.00 (NM1060_042) hv:phyp pSeries\n NIP: c0000000005d23d4 LR: c0000000005d23d0 CTR: 00000000006ee6f8\n REGS: c000000120c078c0 TRAP: 0700 Not tainted (6.10.0-rc3)\n MSR: 8000000000029033 \u0026lt;SF,EE,ME,IR,DR,RI,LE\u0026gt; CR: 2828220f XER: 0000000e\n CFAR: c0000000001fdc80 IRQMASK: 0\n [ ... GPRs omitted ... ]\n NIP [c0000000005d23d4] usercopy_abort+0x78/0xb0\n LR [c0000000005d23d0] usercopy_abort+0x74/0xb0\n Call Trace:\n usercopy_abort+0x74/0xb0 (unreliable)\n __check_heap_object+0xf8/0x120\n check_heap_object+0x218/0x240\n __check_object_size+0x84/0x1a4\n dtl_file_read+0x17c/0x2c4\n full_proxy_read+0x8c/0x110\n vfs_read+0xdc/0x3a0\n ksys_read+0x84/0x144\n system_call_exception+0x124/0x330\n system_call_vectored_common+0x15c/0x2ec\n --- interrupt: 3000 at 0x7fff81f3ab34\r\n\r\nCommit 6d07d1cd300f (\u0026quot;usercopy: Restrict non-usercopy caches to size 0\u0026quot;)\nrequires that only whitelisted areas in slab/slub objects can be copied to\nuserspace when usercopy hardening is enabled using CONFIG_HARDENED_USERCOPY.\nDtl contains hypervisor dispatch events which are expected to be read by\nprivileged users. Hence mark this safe for user access.\nSpecify useroffset=0 and usersize=DISPATCH_LOG_BYTES to whitelist the\nentire object.(CVE-2024-41065)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: qgroup: fix quota root leak after quota disable failure\r\n\r\nIf during the quota disable we fail when cleaning the quota tree or when\ndeleting the root from the root tree, we jump to the \u0026apos;out\u0026apos; label without\never dropping the reference on the quota root, resulting in a leak of the\nroot since fs_info-\u0026gt;quota_root is no longer pointing to the root (we have\nset it to NULL just before those steps).\r\n\r\nFix this by always doing a btrfs_put_root() call under the \u0026apos;out\u0026apos; label.\nThis is a problem that exists since qgroups were first added in 2012 by\ncommit bed92eae26cc (\u0026quot;Btrfs: qgroup implementation and prototypes\u0026quot;), but\nback then we missed a kfree on the quota root and free_extent_buffer()\ncalls on its root and commit root nodes, since back then roots were not\nyet reference counted.(CVE-2024-41078)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/i915/gt: Fix potential UAF by revoke of fence registers\r\n\r\nCI has been sporadically reporting the following issue triggered by\nigt@i915_selftest@live@hangcheck on ADL-P and similar machines:\r\n\r\n\u0026lt;6\u0026gt; [414.049203] i915: Running intel_hangcheck_live_selftests/igt_reset_evict_fence\n...\n\u0026lt;6\u0026gt; [414.068804] i915 0000:00:02.0: [drm] GT0: GUC: submission enabled\n\u0026lt;6\u0026gt; [414.068812] i915 0000:00:02.0: [drm] GT0: GUC: SLPC enabled\n\u0026lt;3\u0026gt; [414.070354] Unable to pin Y-tiled fence; err:-4\n\u0026lt;3\u0026gt; [414.071282] i915_vma_revoke_fence:301 GEM_BUG_ON(!i915_active_is_idle(\u0026amp;fence-\u0026gt;active))\n...\n\u0026lt;4\u0026gt;[ 609.603992] ------------[ cut here ]------------\n\u0026lt;2\u0026gt;[ 609.603995] kernel BUG at drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c:301!\n\u0026lt;4\u0026gt;[ 609.604003] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI\n\u0026lt;4\u0026gt;[ 609.604006] CPU: 0 PID: 268 Comm: kworker/u64:3 Tainted: G U W 6.9.0-CI_DRM_14785-g1ba62f8cea9c+ #1\n\u0026lt;4\u0026gt;[ 609.604008] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023\n\u0026lt;4\u0026gt;[ 609.604010] Workqueue: i915 __i915_gem_free_work [i915]\n\u0026lt;4\u0026gt;[ 609.604149] RIP: 0010:i915_vma_revoke_fence+0x187/0x1f0 [i915]\n...\n\u0026lt;4\u0026gt;[ 609.604271] Call Trace:\n\u0026lt;4\u0026gt;[ 609.604273] \u0026lt;TASK\u0026gt;\n...\n\u0026lt;4\u0026gt;[ 609.604716] __i915_vma_evict+0x2e9/0x550 [i915]\n\u0026lt;4\u0026gt;[ 609.604852] __i915_vma_unbind+0x7c/0x160 [i915]\n\u0026lt;4\u0026gt;[ 609.604977] force_unbind+0x24/0xa0 [i915]\n\u0026lt;4\u0026gt;[ 609.605098] i915_vma_destroy+0x2f/0xa0 [i915]\n\u0026lt;4\u0026gt;[ 609.605210] __i915_gem_object_pages_fini+0x51/0x2f0 [i915]\n\u0026lt;4\u0026gt;[ 609.605330] __i915_gem_free_objects.isra.0+0x6a/0xc0 [i915]\n\u0026lt;4\u0026gt;[ 609.605440] process_scheduled_works+0x351/0x690\n...\r\n\r\nIn the past, there were similar failures reported by CI from other IGT\ntests, observed on other platforms.\r\n\r\nBefore commit 63baf4f3d587 (\u0026quot;drm/i915/gt: Only wait for GPU activity\nbefore unbinding a GGTT fence\u0026quot;), i915_vma_revoke_fence() was waiting for\nidleness of vma-\u0026gt;active via fence_update(). That commit introduced\nvma-\u0026gt;fence-\u0026gt;active in order for the fence_update() to be able to wait\nselectively on that one instead of vma-\u0026gt;active since only idleness of\nfence registers was needed. But then, another commit 0d86ee35097a\n(\u0026quot;drm/i915/gt: Make fence revocation unequivocal\u0026quot;) replaced the call to\nfence_update() in i915_vma_revoke_fence() with only fence_write(), and\nalso added that GEM_BUG_ON(!i915_active_is_idle(\u0026amp;fence-\u0026gt;active)) in front.\nNo justification was provided on why we might then expect idleness of\nvma-\u0026gt;fence-\u0026gt;active without first waiting on it.\r\n\r\nThe issue can be potentially caused by a race among revocation of fence\nregisters on one side and sequential execution of signal callbacks invoked\non completion of a request that was using them on the other, still\nprocessed in parallel to revocation of those fence registers. Fix it by\nwaiting for idleness of vma-\u0026gt;fence-\u0026gt;active in i915_vma_revoke_fence().\r\n\r\n(cherry picked from commit 24bb052d3dd499c5956abad5f7d8e4fd07da7fb1)(CVE-2024-41092)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/panel: ilitek-ili9881c: Fix warning with GPIO controllers that sleep\r\n\r\nThe ilitek-ili9881c controls the reset GPIO using the non-sleeping\ngpiod_set_value() function. This complains loudly when the GPIO\ncontroller needs to sleep. As the caller can sleep, use\ngpiod_set_value_cansleep() to fix the issue.(CVE-2024-42087)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nserial: 8250_omap: Implementation of Errata i2310\r\n\r\nAs per Errata i2310[0], Erroneous timeout can be triggered,\nif this Erroneous interrupt is not cleared then it may leads\nto storm of interrupts, therefore apply Errata i2310 solution.\r\n\r\n[0] https://www.ti.com/lit/pdf/sprz536 page 23(CVE-2024-42095)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nx86: stop playing stack games in profile_pc()\r\n\r\nThe \u0026apos;profile_pc()\u0026apos; function is used for timer-based profiling, which\nisn\u0026apos;t really all that relevant any more to begin with, but it also ends\nup making assumptions based on the stack layout that aren\u0026apos;t necessarily\nvalid.\r\n\r\nBasically, the code tries to account the time spent in spinlocks to the\ncaller rather than the spinlock, and while I support that as a concept,\nit\u0026apos;s not worth the code complexity or the KASAN warnings when no serious\nprofiling is done using timers anyway these days.\r\n\r\nAnd the code really does depend on stack layout that is only true in the\nsimplest of cases. We\u0026apos;ve lost the comment at some point (I think when\nthe 32-bit and 64-bit code was unified), but it used to say:\r\n\r\n\tAssume the lock function has either no stack frame or a copy\n\tof eflags from PUSHF.\r\n\r\nwhich explains why it just blindly loads a word or two straight off the\nstack pointer and then takes a minimal look at the values to just check\nif they might be eflags or the return pc:\r\n\r\n\tEflags always has bits 22 and up cleared unlike kernel addresses\r\n\r\nbut that basic stack layout assumption assumes that there isn\u0026apos;t any lock\ndebugging etc going on that would complicate the code and cause a stack\nframe.\r\n\r\nIt causes KASAN unhappiness reported for years by syzkaller [1] and\nothers [2].\r\n\r\nWith no real practical reason for this any more, just remove the code.\r\n\r\nJust for historical interest, here\u0026apos;s some background commits relating to\nthis code from 2006:\r\n\r\n 0cb91a229364 (\u0026quot;i386: Account spinlocks to the caller during profiling for !FP kernels\u0026quot;)\n 31679f38d886 (\u0026quot;Simplify profile_pc on x86-64\u0026quot;)\r\n\r\nand a code unification from 2009:\r\n\r\n ef4512882dbe (\u0026quot;x86: time_32/64.c unify profile_pc\u0026quot;)\r\n\r\nbut the basics of this thing actually goes back to before the git tree.(CVE-2024-42096)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncrypto: ecdh - explicitly zeroize private_key\r\n\r\nprivate_key is overwritten with the key parameter passed in by the\ncaller (if present), or alternatively a newly generated private key.\nHowever, it is possible that the caller provides a key (or the newly\ngenerated key) which is shorter than the previous key. In that\nscenario, some key material from the previous key would not be\noverwritten. The easiest solution is to explicitly zeroize the entire\nprivate_key array first.\r\n\r\nNote that this patch slightly changes the behavior of this function:\npreviously, if the ecc_gen_privkey failed, the old private_key would\nremain. Now, the private_key is always zeroized. This behavior is\nconsistent with the case where params.key is set and ecc_is_key_valid\nfails.(CVE-2024-42098)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: fix inode number range checks\r\n\r\nPatch series \u0026quot;nilfs2: fix potential issues related to reserved inodes\u0026quot;.\r\n\r\nThis series fixes one use-after-free issue reported by syzbot, caused by\nnilfs2\u0026apos;s internal inode being exposed in the namespace on a corrupted\nfilesystem, and a couple of flaws that cause problems if the starting\nnumber of non-reserved inodes written in the on-disk super block is\nintentionally (or corruptly) changed from its default value. \r\n\r\n\nThis patch (of 3):\r\n\r\nIn the current implementation of nilfs2, \u0026quot;nilfs-\u0026gt;ns_first_ino\u0026quot;, which\ngives the first non-reserved inode number, is read from the superblock,\nbut its lower limit is not checked.\r\n\r\nAs a result, if a number that overlaps with the inode number range of\nreserved inodes such as the root directory or metadata files is set in the\nsuper block parameter, the inode number test macros (NILFS_MDT_INODE and\nNILFS_VALID_INODE) will not function properly.\r\n\r\nIn addition, these test macros use left bit-shift calculations using with\nthe inode number as the shift count via the BIT macro, but the result of a\nshift calculation that exceeds the bit width of an integer is undefined in\nthe C specification, so if \u0026quot;ns_first_ino\u0026quot; is set to a large value other\nthan the default value NILFS_USER_INO (=11), the macros may potentially\nmalfunction depending on the environment.\r\n\r\nFix these issues by checking the lower bound of \u0026quot;nilfs-\u0026gt;ns_first_ino\u0026quot; and\nby preventing bit shifts equal to or greater than the NILFS_USER_INO\nconstant in the inode number test macros.\r\n\r\nAlso, change the type of \u0026quot;ns_first_ino\u0026quot; from signed integer to unsigned\ninteger to avoid the need for type casting in comparisons such as the\nlower bound check introduced this time.(CVE-2024-42105)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: cfg80211: restrict NL80211_ATTR_TXQ_QUANTUM values\r\n\r\nsyzbot is able to trigger softlockups, setting NL80211_ATTR_TXQ_QUANTUM\nto 2^31.\r\n\r\nWe had a similar issue in sch_fq, fixed with commit\nd9e15a273306 (\u0026quot;pkt_sched: fq: do not accept silly TCA_FQ_QUANTUM\u0026quot;)\r\n\r\nwatchdog: BUG: soft lockup - CPU#1 stuck for 26s! [kworker/1:0:24]\nModules linked in:\nirq event stamp: 131135\n hardirqs last enabled at (131134): [\u0026lt;ffff80008ae8778c\u0026gt;] __exit_to_kernel_mode arch/arm64/kernel/entry-common.c:85 [inline]\n hardirqs last enabled at (131134): [\u0026lt;ffff80008ae8778c\u0026gt;] exit_to_kernel_mode+0xdc/0x10c arch/arm64/kernel/entry-common.c:95\n hardirqs last disabled at (131135): [\u0026lt;ffff80008ae85378\u0026gt;] __el1_irq arch/arm64/kernel/entry-common.c:533 [inline]\n hardirqs last disabled at (131135): [\u0026lt;ffff80008ae85378\u0026gt;] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551\n softirqs last enabled at (125892): [\u0026lt;ffff80008907e82c\u0026gt;] neigh_hh_init net/core/neighbour.c:1538 [inline]\n softirqs last enabled at (125892): [\u0026lt;ffff80008907e82c\u0026gt;] neigh_resolve_output+0x268/0x658 net/core/neighbour.c:1553\n softirqs last disabled at (125896): [\u0026lt;ffff80008904166c\u0026gt;] local_bh_disable+0x10/0x34 include/linux/bottom_half.h:19\nCPU: 1 PID: 24 Comm: kworker/1:0 Not tainted 6.9.0-rc7-syzkaller-gfda5695d692c #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024\nWorkqueue: mld mld_ifc_work\npstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : __list_del include/linux/list.h:195 [inline]\n pc : __list_del_entry include/linux/list.h:218 [inline]\n pc : list_move_tail include/linux/list.h:310 [inline]\n pc : fq_tin_dequeue include/net/fq_impl.h:112 [inline]\n pc : ieee80211_tx_dequeue+0x6b8/0x3b4c net/mac80211/tx.c:3854\n lr : __list_del_entry include/linux/list.h:218 [inline]\n lr : list_move_tail include/linux/list.h:310 [inline]\n lr : fq_tin_dequeue include/net/fq_impl.h:112 [inline]\n lr : ieee80211_tx_dequeue+0x67c/0x3b4c net/mac80211/tx.c:3854\nsp : ffff800093d36700\nx29: ffff800093d36a60 x28: ffff800093d36960 x27: dfff800000000000\nx26: ffff0000d800ad50 x25: ffff0000d800abe0 x24: ffff0000d800abf0\nx23: ffff0000e0032468 x22: ffff0000e00324d4 x21: ffff0000d800abf0\nx20: ffff0000d800abf8 x19: ffff0000d800abf0 x18: ffff800093d363c0\nx17: 000000000000d476 x16: ffff8000805519dc x15: ffff7000127a6cc8\nx14: 1ffff000127a6cc8 x13: 0000000000000004 x12: ffffffffffffffff\nx11: ffff7000127a6cc8 x10: 0000000000ff0100 x9 : 0000000000000000\nx8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000\nx5 : ffff80009287aa08 x4 : 0000000000000008 x3 : ffff80008034c7fc\nx2 : ffff0000e0032468 x1 : 00000000da0e46b8 x0 : ffff0000e0032470\nCall trace:\n __list_del include/linux/list.h:195 [inline]\n __list_del_entry include/linux/list.h:218 [inline]\n list_move_tail include/linux/list.h:310 [inline]\n fq_tin_dequeue include/net/fq_impl.h:112 [inline]\n ieee80211_tx_dequeue+0x6b8/0x3b4c net/mac80211/tx.c:3854\n wake_tx_push_queue net/mac80211/util.c:294 [inline]\n ieee80211_handle_wake_tx_queue+0x118/0x274 net/mac80211/util.c:315\n drv_wake_tx_queue net/mac80211/driver-ops.h:1350 [inline]\n schedule_and_wake_txq net/mac80211/driver-ops.h:1357 [inline]\n ieee80211_queue_skb+0x18e8/0x2244 net/mac80211/tx.c:1664\n ieee80211_tx+0x260/0x400 net/mac80211/tx.c:1966\n ieee80211_xmit+0x278/0x354 net/mac80211/tx.c:2062\n __ieee80211_subif_start_xmit+0xab8/0x122c net/mac80211/tx.c:4338\n ieee80211_subif_start_xmit+0xe0/0x438 net/mac80211/tx.c:4532\n __netdev_start_xmit include/linux/netdevice.h:4903 [inline]\n netdev_start_xmit include/linux/netdevice.h:4917 [inline]\n xmit_one net/core/dev.c:3531 [inline]\n dev_hard_start_xmit+0x27c/0x938 net/core/dev.c:3547\n __dev_queue_xmit+0x1678/0x33fc net/core/dev.c:4341\n dev_queue_xmit include/linux/netdevice.h:3091 [inline]\n neigh_resolve_output+0x558/0x658 net/core/neighbour.c:1563\n neigh_output include/net/neighbour.h:542 [inline]\n ip6_fini\n---truncated---(CVE-2024-42114)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npowerpc: Avoid nmi_enter/nmi_exit in real mode interrupt.\r\n\r\nnmi_enter()/nmi_exit() touches per cpu variables which can lead to kernel\ncrash when invoked during real mode interrupt handling (e.g. early HMI/MCE\ninterrupt handler) if percpu allocation comes from vmalloc area.\r\n\r\nEarly HMI/MCE handlers are called through DEFINE_INTERRUPT_HANDLER_NMI()\nwrapper which invokes nmi_enter/nmi_exit calls. We don\u0026apos;t see any issue when\npercpu allocation is from the embedded first chunk. However with\nCONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK enabled there are chances where percpu\nallocation can come from the vmalloc area.\r\n\r\nWith kernel command line \u0026quot;percpu_alloc=page\u0026quot; we can force percpu allocation\nto come from vmalloc area and can see kernel crash in machine_check_early:\r\n\r\n[ 1.215714] NIP [c000000000e49eb4] rcu_nmi_enter+0x24/0x110\n[ 1.215717] LR [c0000000000461a0] machine_check_early+0xf0/0x2c0\n[ 1.215719] --- interrupt: 200\n[ 1.215720] [c000000fffd73180] [0000000000000000] 0x0 (unreliable)\n[ 1.215722] [c000000fffd731b0] [0000000000000000] 0x0\n[ 1.215724] [c000000fffd73210] [c000000000008364] machine_check_early_common+0x134/0x1f8\r\n\r\nFix this by avoiding use of nmi_enter()/nmi_exit() in real mode if percpu\nfirst chunk is not embedded.(CVE-2024-42126)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nleds: an30259a: Use devm_mutex_init() for mutex initialization\r\n\r\nIn this driver LEDs are registered using devm_led_classdev_register()\nso they are automatically unregistered after module\u0026apos;s remove() is done.\nled_classdev_unregister() calls module\u0026apos;s led_set_brightness() to turn off\nthe LEDs and that callback uses mutex which was destroyed already\nin module\u0026apos;s remove() so use devm API instead.(CVE-2024-42128)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\norangefs: fix out-of-bounds fsid access\r\n\r\nArnd Bergmann sent a patch to fsdevel, he says:\r\n\r\n\u0026quot;orangefs_statfs() copies two consecutive fields of the superblock into\nthe statfs structure, which triggers a warning from the string fortification\nhelpers\u0026quot;\r\n\r\nJan Kara suggested an alternate way to do the patch to make it more readable.\r\n\r\nI ran both ideas through xfstests and both seem fine. This patch\nis based on Jan Kara\u0026apos;s suggestion.(CVE-2024-42143)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbnx2x: Fix multiple UBSAN array-index-out-of-bounds\r\n\r\nFix UBSAN warnings that occur when using a system with 32 physical\ncpu cores or more, or when the user defines a number of Ethernet\nqueues greater than or equal to FP_SB_MAX_E1x using the num_queues\nmodule parameter.\r\n\r\nCurrently there is a read/write out of bounds that occurs on the array\n\u0026quot;struct stats_query_entry query\u0026quot; present inside the \u0026quot;bnx2x_fw_stats_req\u0026quot;\nstruct in \u0026quot;drivers/net/ethernet/broadcom/bnx2x/bnx2x.h\u0026quot;.\nLooking at the definition of the \u0026quot;struct stats_query_entry query\u0026quot; array:\r\n\r\nstruct stats_query_entry query[FP_SB_MAX_E1x+\n BNX2X_FIRST_QUEUE_QUERY_IDX];\r\n\r\nFP_SB_MAX_E1x is defined as the maximum number of fast path interrupts and\nhas a value of 16, while BNX2X_FIRST_QUEUE_QUERY_IDX has a value of 3\nmeaning the array has a total size of 19.\nSince accesses to \u0026quot;struct stats_query_entry query\u0026quot; are offset-ted by\nBNX2X_FIRST_QUEUE_QUERY_IDX, that means that the total number of Ethernet\nqueues should not exceed FP_SB_MAX_E1x (16). However one of these queues\nis reserved for FCOE and thus the number of Ethernet queues should be set\nto [FP_SB_MAX_E1x -1] (15) if FCOE is enabled or [FP_SB_MAX_E1x] (16) if\nit is not.\r\n\r\nThis is also described in a comment in the source code in\ndrivers/net/ethernet/broadcom/bnx2x/bnx2x.h just above the Macro definition\nof FP_SB_MAX_E1x. Below is the part of this explanation that it important\nfor this patch\r\n\r\n/*\n * The total number of L2 queues, MSIX vectors and HW contexts (CIDs) is\n * control by the number of fast-path status blocks supported by the\n * device (HW/FW). Each fast-path status block (FP-SB) aka non-default\n * status block represents an independent interrupts context that can\n * serve a regular L2 networking queue. However special L2 queues such\n * as the FCoE queue do not require a FP-SB and other components like\n * the CNIC may consume FP-SB reducing the number of possible L2 queues\n *\n * If the maximum number of FP-SB available is X then:\n * a. If CNIC is supported it consumes 1 FP-SB thus the max number of\n * regular L2 queues is Y=X-1\n * b. In MF mode the actual number of L2 queues is Y= (X-1/MF_factor)\n * c. If the FCoE L2 queue is supported the actual number of L2 queues\n * is Y+1\n * d. The number of irqs (MSIX vectors) is either Y+1 (one extra for\n * slow-path interrupts) or Y+2 if CNIC is supported (one additional\n * FP interrupt context for the CNIC).\n * e. The number of HW context (CID count) is always X or X+1 if FCoE\n * L2 queue is supported. The cid for the FCoE L2 queue is always X.\n */\r\n\r\nHowever this driver also supports NICs that use the E2 controller which can\nhandle more queues due to having more FP-SB represented by FP_SB_MAX_E2.\nLooking at the commits when the E2 support was added, it was originally\nusing the E1x parameters: commit f2e0899f0f27 (\u0026quot;bnx2x: Add 57712 support\u0026quot;).\nBack then FP_SB_MAX_E2 was set to 16 the same as E1x. However the driver\nwas later updated to take full advantage of the E2 instead of having it be\nlimited to the capabilities of the E1x. But as far as we can tell, the\narray \u0026quot;stats_query_entry query\u0026quot; was still limited to using the FP-SB\navailable to the E1x cards as part of an oversignt when the driver was\nupdated to take full advantage of the E2, and now with the driver being\naware of the greater queue size supported by E2 NICs, it causes the UBSAN\nwarnings seen in the stack traces below.\r\n\r\nThis patch increases the size of the \u0026quot;stats_query_entry query\u0026quot; array by\nreplacing FP_SB_MAX_E1x with FP_SB_MAX_E2 to be large enough to handle\nboth types of NICs.\r\n\r\nStack traces:\r\n\r\nUBSAN: array-index-out-of-bounds in\n drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.c:1529:11\nindex 20 is out of range for type \u0026apos;stats_query_entry [19]\u0026apos;\nCPU: 12 PID: 858 Comm: systemd-network Not tainted 6.9.0-060900rc7-generic\n\t #202405052133\nHardware name: HP ProLiant DL360 Gen9/ProLiant DL360 \n---truncated---(CVE-2024-42148)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntcp_metrics: validate source addr length\r\n\r\nI don\u0026apos;t see anything checking that TCP_METRICS_ATTR_SADDR_IPV4\nis at least 4 bytes long, and the policy doesn\u0026apos;t have an entry\nfor this attribute at all (neither does it for IPv6 but v6 is\nmanually validated).(CVE-2024-42154)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ns390/pkey: Wipe copies of clear-key structures on failure\r\n\r\nWipe all sensitive data from stack for all IOCTLs, which convert a\nclear-key into a protected- or secure-key.(CVE-2024-42156)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ns390/pkey: Wipe sensitive data on failure\r\n\r\nWipe sensitive data from stack also if the copy_to_user() fails.(CVE-2024-42157)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ns390/pkey: Use kfree_sensitive() to fix Coccinelle warnings\r\n\r\nReplace memzero_explicit() and kfree() with kfree_sensitive() to fix\nwarnings reported by Coccinelle:\r\n\r\nWARNING opportunity for kfree_sensitive/kvfree_sensitive (line 1506)\nWARNING opportunity for kfree_sensitive/kvfree_sensitive (line 1643)\nWARNING opportunity for kfree_sensitive/kvfree_sensitive (line 1770)(CVE-2024-42158)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: dvb-frontends: tda10048: Fix integer overflow\r\n\r\nstate-\u0026gt;xtal_hz can be up to 16M, so it can overflow a 32 bit integer\nwhen multiplied by pll_mfactor.\r\n\r\nCreate a new 64 bit variable to hold the calculations.(CVE-2024-42223)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: mt76: replace skb_put with skb_put_zero\r\n\r\nAvoid potentially reusing uninitialized data(CVE-2024-42225)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncrypto: aead,cipher - zeroize key buffer after use\r\n\r\nI.G 9.7.B for FIPS 140-3 specifies that variables temporarily holding\ncryptographic information should be zeroized once they are no longer\nneeded. Accomplish this by using kfree_sensitive for buffers that\npreviously held the private key.(CVE-2024-42229)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nUSB: serial: mos7840: fix crash on resume\r\n\r\nSince commit c49cfa917025 (\u0026quot;USB: serial: use generic method if no\nalternative is provided in usb serial layer\u0026quot;), USB serial core calls the\ngeneric resume implementation when the driver has not provided one.\r\n\r\nThis can trigger a crash on resume with mos7840 since support for\nmultiple read URBs was added back in 2011. Specifically, both port read\nURBs are now submitted on resume for open ports, but the context pointer\nof the second URB is left set to the core rather than mos7840 port\nstructure.\r\n\r\nFix this by implementing dedicated suspend and resume functions for\nmos7840.\r\n\r\nTested with Delock 87414 USB 2.0 to 4x serial adapter.\r\n\r\n[ johan: analyse crash and rewrite commit message; set busy flag on\n resume; drop bulk-in check; drop unnecessary usb_kill_urb() ](CVE-2024-42244)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet, sunrpc: Remap EPERM in case of connection failure in xs_tcp_setup_socket\r\n\r\nWhen using a BPF program on kernel_connect(), the call can return -EPERM. This\ncauses xs_tcp_setup_socket() to loop forever, filling up the syslog and causing\nthe kernel to potentially freeze up.\r\n\r\nNeil suggested:\r\n\r\n This will propagate -EPERM up into other layers which might not be ready\n to handle it. It might be safer to map EPERM to an error we would be more\n likely to expect from the network system - such as ECONNREFUSED or ENETDOWN.\r\n\r\nECONNREFUSED as error seems reasonable. For programs setting a different error\ncan be out of reach (see handling in 4fbac77d2d09) in particular on kernels\nwhich do not have f10d05966196 (\u0026quot;bpf: Make BPF_PROG_RUN_ARRAY return -err\ninstead of allow boolean\u0026quot;), thus given that it is better to simply remap for\nconsistent behavior. UDP does handle EPERM in xs_udp_send_request().(CVE-2024-42246)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwireguard: allowedips: avoid unaligned 64-bit memory accesses\r\n\r\nOn the parisc platform, the kernel issues kernel warnings because\nswap_endian() tries to load a 128-bit IPv6 address from an unaligned\nmemory location:\r\n\r\n Kernel: unaligned access to 0x55f4688c in wg_allowedips_insert_v6+0x2c/0x80 [wireguard] (iir 0xf3010df)\n Kernel: unaligned access to 0x55f46884 in wg_allowedips_insert_v6+0x38/0x80 [wireguard] (iir 0xf2010dc)\r\n\r\nAvoid such unaligned memory accesses by instead using the\nget_unaligned_be64() helper macro.\r\n\r\n[Jason: replace src[8] in original patch with src+8](CVE-2024-42247)",
"id": "OESA-2024-1995",
"modified": "2026-08-06T11:07:28Z",
"published": "2024-08-16T11:07:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1995"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47582"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52888"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-22386"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39509"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40942"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40990"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41012"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41034"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41035"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41042"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41046"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41065"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41078"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41092"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42087"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42095"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42096"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42098"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42105"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42114"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42126"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42128"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42143"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42148"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42154"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42156"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42157"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42158"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42223"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42225"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42229"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42244"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42246"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42247"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2021-47582",
"CVE-2023-52888",
"CVE-2024-22386",
"CVE-2024-39509",
"CVE-2024-40942",
"CVE-2024-40990",
"CVE-2024-41012",
"CVE-2024-41034",
"CVE-2024-41035",
"CVE-2024-41042",
"CVE-2024-41046",
"CVE-2024-41065",
"CVE-2024-41078",
"CVE-2024-41092",
"CVE-2024-42087",
"CVE-2024-42095",
"CVE-2024-42096",
"CVE-2024-42098",
"CVE-2024-42105",
"CVE-2024-42114",
"CVE-2024-42126",
"CVE-2024-42128",
"CVE-2024-42143",
"CVE-2024-42148",
"CVE-2024-42154",
"CVE-2024-42156",
"CVE-2024-42157",
"CVE-2024-42158",
"CVE-2024-42223",
"CVE-2024-42225",
"CVE-2024-42229",
"CVE-2024-42244",
"CVE-2024-42246",
"CVE-2024-42247"
]
}
OESA-2024-1996 (CVE-2022-48860)
Vulnerability from osv_openeuler – Published: 2024-08-16 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:
ethernet: Fix error handling in xemaclite_of_probe
This node pointer is returned by of_parse_phandle() with refcount incremented in this function. Calling of_node_put() to avoid the refcount leak. As the remove function do.(CVE-2022-48860)
In the Linux kernel, the following vulnerability has been resolved:
HID: core: remove unnecessary WARN_ON() in implement()
Syzkaller hit a warning [1] in a call to implement() when trying to write a value into a field of smaller size in an output report.
Since implement() already has a warn message printed out with the help of hid_warn() and value in question gets trimmed with: ... value &= m; ... WARN_ON may be considered superfluous. Remove it to suppress future syzkaller triggers.
[1] WARNING: CPU: 0 PID: 5084 at drivers/hid/hid-core.c:1451 implement drivers/hid/hid-core.c:1451 [inline] WARNING: CPU: 0 PID: 5084 at drivers/hid/hid-core.c:1451 hid_output_report+0x548/0x760 drivers/hid/hid-core.c:1863 Modules linked in: CPU: 0 PID: 5084 Comm: syz-executor424 Not tainted 6.9.0-rc7-syzkaller-00183-gcf87f46fd34d #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024 RIP: 0010:implement drivers/hid/hid-core.c:1451 [inline] RIP: 0010:hid_output_report+0x548/0x760 drivers/hid/hid-core.c:1863 ... Call Trace: <TASK> __usbhid_submit_report drivers/hid/usbhid/hid-core.c:591 [inline] usbhid_submit_report+0x43d/0x9e0 drivers/hid/usbhid/hid-core.c:636 hiddev_ioctl+0x138b/0x1f00 drivers/hid/usbhid/hiddev.c:726 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:904 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:890 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f ...(CVE-2024-39509)
In the Linux kernel, the following vulnerability has been resolved:
filelock: Remove locks reliably when fcntl/close race is detected
When fcntl_setlk() races with close(), it removes the created lock with do_lock_file_wait(). However, LSMs can allow the first do_lock_file_wait() that created the lock while denying the second do_lock_file_wait() that tries to remove the lock. Separately, posix_lock_file() could also fail to remove a lock due to GFP_KERNEL allocation failure (when splitting a range in the middle).
After the bug has been triggered, use-after-free reads will occur in lock_get_status() when userspace reads /proc/locks. This can likely be used to read arbitrary kernel memory, but can't corrupt kernel memory.
Fix it by calling locks_remove_posix() instead, which is designed to reliably get rid of POSIX locks associated with the given file and files_struct and is also used by filp_flush().(CVE-2024-41012)
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix kernel bug on rename operation of broken directory
Syzbot reported that in rename directory operation on broken directory on nilfs2, __block_write_begin_int() called to prepare block write may fail BUG_ON check for access exceeding the folio/page size.
This is because nilfs_dotdot(), which gets parent directory reference entry ("..") of the directory to be moved or renamed, does not check consistency enough, and may return location exceeding folio/page size for broken directories.
Fix this issue by checking required directory entries ("." and "..") in the first chunk of the directory in nilfs_dotdot().(CVE-2024-41034)
In the Linux kernel, the following vulnerability has been resolved:
USB: core: Fix duplicate endpoint bug by clearing reserved bits in the descriptor
Syzbot has identified a bug in usbcore (see the Closes: tag below) caused by our assumption that the reserved bits in an endpoint descriptor's bEndpointAddress field will always be 0. As a result of the bug, the endpoint_is_duplicate() routine in config.c (and possibly other routines as well) may believe that two descriptors are for distinct endpoints, even though they have the same direction and endpoint number. This can lead to confusion, including the bug identified by syzbot (two descriptors with matching endpoint numbers and directions, where one was interrupt and the other was bulk).
To fix the bug, we will clear the reserved bits in bEndpointAddress when we parse the descriptor. (Note that both the USB-2.0 and USB-3.1 specs say these bits are "Reserved, reset to zero".) This requires us to make a copy of the descriptor earlier in usb_parse_endpoint() and use the copy instead of the original when checking for duplicates.(CVE-2024-41035)
In the Linux kernel, the following vulnerability has been resolved:
net: ethernet: lantiq_etop: fix double free in detach
The number of the currently released descriptor is never incremented which results in the same skb being released multiple times.(CVE-2024-41046)
In the Linux kernel, the following vulnerability has been resolved:
hfsplus: fix uninit-value in copy_name
[syzbot reported] BUG: KMSAN: uninit-value in sized_strscpy+0xc4/0x160 sized_strscpy+0xc4/0x160 copy_name+0x2af/0x320 fs/hfsplus/xattr.c:411 hfsplus_listxattr+0x11e9/0x1a50 fs/hfsplus/xattr.c:750 vfs_listxattr fs/xattr.c:493 [inline] listxattr+0x1f3/0x6b0 fs/xattr.c:840 path_listxattr fs/xattr.c:864 [inline] __do_sys_listxattr fs/xattr.c:876 [inline] __se_sys_listxattr fs/xattr.c:873 [inline] __x64_sys_listxattr+0x16b/0x2f0 fs/xattr.c:873 x64_sys_call+0x2ba0/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:195 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Uninit was created at: slab_post_alloc_hook mm/slub.c:3877 [inline] slab_alloc_node mm/slub.c:3918 [inline] kmalloc_trace+0x57b/0xbe0 mm/slub.c:4065 kmalloc include/linux/slab.h:628 [inline] hfsplus_listxattr+0x4cc/0x1a50 fs/hfsplus/xattr.c:699 vfs_listxattr fs/xattr.c:493 [inline] listxattr+0x1f3/0x6b0 fs/xattr.c:840 path_listxattr fs/xattr.c:864 [inline] __do_sys_listxattr fs/xattr.c:876 [inline] __se_sys_listxattr fs/xattr.c:873 [inline] __x64_sys_listxattr+0x16b/0x2f0 fs/xattr.c:873 x64_sys_call+0x2ba0/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:195 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f [Fix] When allocating memory to strbuf, initialize memory to 0.(CVE-2024-41059)
In the Linux kernel, the following vulnerability has been resolved:
powerpc/pseries: Whitelist dtl slub object for copying to userspace
Reading the dispatch trace log from /sys/kernel/debug/powerpc/dtl/cpu-* results in a BUG() when the config CONFIG_HARDENED_USERCOPY is enabled as shown below.
kernel BUG at mm/usercopy.c:102!
Oops: Exception in kernel mode, sig: 5 [#1]
LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries
Modules linked in: xfs libcrc32c dm_service_time sd_mod t10_pi sg ibmvfc
scsi_transport_fc ibmveth pseries_wdt dm_multipath dm_mirror dm_region_hash dm_log dm_mod fuse
CPU: 27 PID: 1815 Comm: python3 Not tainted 6.10.0-rc3 #85
Hardware name: IBM,9040-MRX POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1060.00 (NM1060_042) hv:phyp pSeries
NIP: c0000000005d23d4 LR: c0000000005d23d0 CTR: 00000000006ee6f8
REGS: c000000120c078c0 TRAP: 0700 Not tainted (6.10.0-rc3)
MSR: 8000000000029033 <SF,EE,ME,IR,DR,RI,LE> CR: 2828220f XER: 0000000e
CFAR: c0000000001fdc80 IRQMASK: 0
[ ... GPRs omitted ... ]
NIP [c0000000005d23d4] usercopy_abort+0x78/0xb0
LR [c0000000005d23d0] usercopy_abort+0x74/0xb0
Call Trace:
usercopy_abort+0x74/0xb0 (unreliable)
__check_heap_object+0xf8/0x120
check_heap_object+0x218/0x240
__check_object_size+0x84/0x1a4
dtl_file_read+0x17c/0x2c4
full_proxy_read+0x8c/0x110
vfs_read+0xdc/0x3a0
ksys_read+0x84/0x144
system_call_exception+0x124/0x330
system_call_vectored_common+0x15c/0x2ec
--- interrupt: 3000 at 0x7fff81f3ab34
Commit 6d07d1cd300f ("usercopy: Restrict non-usercopy caches to size 0") requires that only whitelisted areas in slab/slub objects can be copied to userspace when usercopy hardening is enabled using CONFIG_HARDENED_USERCOPY. Dtl contains hypervisor dispatch events which are expected to be read by privileged users. Hence mark this safe for user access. Specify useroffset=0 and usersize=DISPATCH_LOG_BYTES to whitelist the entire object.(CVE-2024-41065)
In the Linux kernel, the following vulnerability has been resolved:
ata: libata-core: Fix double free on error
If e.g. the ata_port_alloc() call in ata_host_alloc() fails, we will jump to the err_out label, which will call devres_release_group(). devres_release_group() will trigger a call to ata_host_release(). ata_host_release() calls kfree(host), so executing the kfree(host) in ata_host_alloc() will lead to a double free:
kernel BUG at mm/slub.c:553! Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 11 PID: 599 Comm: (udev-worker) Not tainted 6.10.0-rc5 #47 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:kfree+0x2cf/0x2f0 Code: 5d 41 5e 41 5f 5d e9 80 d6 ff ff 4d 89 f1 41 b8 01 00 00 00 48 89 d9 48 89 da RSP: 0018:ffffc90000f377f0 EFLAGS: 00010246 RAX: ffff888112b1f2c0 RBX: ffff888112b1f2c0 RCX: ffff888112b1f320 RDX: 000000000000400b RSI: ffffffffc02c9de5 RDI: ffff888112b1f2c0 RBP: ffffc90000f37830 R08: 0000000000000000 R09: 0000000000000000 R10: ffffc90000f37610 R11: 617461203a736b6e R12: ffffea00044ac780 R13: ffff888100046400 R14: ffffffffc02c9de5 R15: 0000000000000006 FS: 00007f2f1cabe980(0000) GS:ffff88813b380000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f2f1c3acf75 CR3: 0000000111724000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: <TASK> ? __die_body.cold+0x19/0x27 ? die+0x2e/0x50 ? do_trap+0xca/0x110 ? do_error_trap+0x6a/0x90 ? kfree+0x2cf/0x2f0 ? exc_invalid_op+0x50/0x70 ? kfree+0x2cf/0x2f0 ? asm_exc_invalid_op+0x1a/0x20 ? ata_host_alloc+0xf5/0x120 [libata] ? ata_host_alloc+0xf5/0x120 [libata] ? kfree+0x2cf/0x2f0 ata_host_alloc+0xf5/0x120 [libata] ata_host_alloc_pinfo+0x14/0xa0 [libata] ahci_init_one+0x6c9/0xd20 [ahci]
Ensure that we will not call kfree(host) twice, by performing the kfree() only if the devres_open_group() call failed.(CVE-2024-41087)
In the Linux kernel, the following vulnerability has been resolved:
ftruncate: pass a signed offset
The old ftruncate() syscall, using the 32-bit off_t misses a sign extension when called in compat mode on 64-bit architectures. As a result, passing a negative length accidentally succeeds in truncating to file size between 2GiB and 4GiB.
Changing the type of the compat syscall to the signed compat_off_t changes the behavior so it instead returns -EINVAL.
The native entry point, the truncate() syscall and the corresponding loff_t based variants are all correct already and do not suffer from this mistake.(CVE-2024-42084)
In the Linux kernel, the following vulnerability has been resolved:
drm/panel: ilitek-ili9881c: Fix warning with GPIO controllers that sleep
The ilitek-ili9881c controls the reset GPIO using the non-sleeping gpiod_set_value() function. This complains loudly when the GPIO controller needs to sleep. As the caller can sleep, use gpiod_set_value_cansleep() to fix the issue.(CVE-2024-42087)
In the Linux kernel, the following vulnerability has been resolved:
ASoC: fsl-asoc-card: set priv->pdev before using it
priv->pdev pointer was set after being used in fsl_asoc_card_audmux_init(). Move this assignment at the start of the probe function, so sub-functions can correctly use pdev through priv.
fsl_asoc_card_audmux_init() dereferences priv->pdev to get access to the dev struct, used with dev_err macros. As priv is zero-initialised, there would be a NULL pointer dereference. Note that if priv->dev is dereferenced before assignment but never used, for example if there is no error to be printed, the driver won't crash probably due to compiler optimisations.(CVE-2024-42089)
In the Linux kernel, the following vulnerability has been resolved:
x86: stop playing stack games in profile_pc()
The 'profile_pc()' function is used for timer-based profiling, which isn't really all that relevant any more to begin with, but it also ends up making assumptions based on the stack layout that aren't necessarily valid.
Basically, the code tries to account the time spent in spinlocks to the caller rather than the spinlock, and while I support that as a concept, it's not worth the code complexity or the KASAN warnings when no serious profiling is done using timers anyway these days.
And the code really does depend on stack layout that is only true in the simplest of cases. We've lost the comment at some point (I think when the 32-bit and 64-bit code was unified), but it used to say:
Assume the lock function has either no stack frame or a copy
of eflags from PUSHF.
which explains why it just blindly loads a word or two straight off the stack pointer and then takes a minimal look at the values to just check if they might be eflags or the return pc:
Eflags always has bits 22 and up cleared unlike kernel addresses
but that basic stack layout assumption assumes that there isn't any lock debugging etc going on that would complicate the code and cause a stack frame.
It causes KASAN unhappiness reported for years by syzkaller [1] and others [2].
With no real practical reason for this any more, just remove the code.
Just for historical interest, here's some background commits relating to this code from 2006:
0cb91a229364 ("i386: Account spinlocks to the caller during profiling for !FP kernels") 31679f38d886 ("Simplify profile_pc on x86-64")
and a code unification from 2009:
ef4512882dbe ("x86: time_32/64.c unify profile_pc")
but the basics of this thing actually goes back to before the git tree.(CVE-2024-42096)
In the Linux kernel, the following vulnerability has been resolved:
Revert "mm/writeback: fix possible divide-by-zero in wb_dirty_limits(), again"
Patch series "mm: Avoid possible overflows in dirty throttling".
Dirty throttling logic assumes dirty limits in page units fit into 32-bits. This patch series makes sure this is true (see patch 2/2 for more details).
This patch (of 2):
This reverts commit 9319b647902cbd5cc884ac08a8a6d54ce111fc78.
The commit is broken in several ways. Firstly, the removed (u64) cast from the multiplication will introduce a multiplication overflow on 32-bit archs if wb_thresh * bg_thresh >= 1<<32 (which is actually common - the default settings with 4GB of RAM will trigger this). Secondly, the div64_u64() is unnecessarily expensive on 32-bit archs. We have div64_ul() in case we want to be safe & cheap. Thirdly, if dirty thresholds are larger than 1<<32 pages, then dirty balancing is going to blow up in many other spectacular ways anyway so trying to fix one possible overflow is just moot.(CVE-2024-42102)
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix inode number range checks
Patch series "nilfs2: fix potential issues related to reserved inodes".
This series fixes one use-after-free issue reported by syzbot, caused by nilfs2's internal inode being exposed in the namespace on a corrupted filesystem, and a couple of flaws that cause problems if the starting number of non-reserved inodes written in the on-disk super block is intentionally (or corruptly) changed from its default value.
This patch (of 3):
In the current implementation of nilfs2, "nilfs->ns_first_ino", which gives the first non-reserved inode number, is read from the superblock, but its lower limit is not checked.
As a result, if a number that overlaps with the inode number range of reserved inodes such as the root directory or metadata files is set in the super block parameter, the inode number test macros (NILFS_MDT_INODE and NILFS_VALID_INODE) will not function properly.
In addition, these test macros use left bit-shift calculations using with the inode number as the shift count via the BIT macro, but the result of a shift calculation that exceeds the bit width of an integer is undefined in the C specification, so if "ns_first_ino" is set to a large value other than the default value NILFS_USER_INO (=11), the macros may potentially malfunction depending on the environment.
Fix these issues by checking the lower bound of "nilfs->ns_first_ino" and by preventing bit shifts equal to or greater than the NILFS_USER_INO constant in the inode number test macros.
Also, change the type of "ns_first_ino" from signed integer to unsigned integer to avoid the need for type casting in comparisons such as the lower bound check introduced this time.(CVE-2024-42105)
In the Linux kernel, the following vulnerability has been resolved:
orangefs: fix out-of-bounds fsid access
Arnd Bergmann sent a patch to fsdevel, he says:
"orangefs_statfs() copies two consecutive fields of the superblock into the statfs structure, which triggers a warning from the string fortification helpers"
Jan Kara suggested an alternate way to do the patch to make it more readable.
I ran both ideas through xfstests and both seem fine. This patch is based on Jan Kara's suggestion.(CVE-2024-42143)
In the Linux kernel, the following vulnerability has been resolved:
bnx2x: Fix multiple UBSAN array-index-out-of-bounds
Fix UBSAN warnings that occur when using a system with 32 physical cpu cores or more, or when the user defines a number of Ethernet queues greater than or equal to FP_SB_MAX_E1x using the num_queues module parameter.
Currently there is a read/write out of bounds that occurs on the array "struct stats_query_entry query" present inside the "bnx2x_fw_stats_req" struct in "drivers/net/ethernet/broadcom/bnx2x/bnx2x.h". Looking at the definition of the "struct stats_query_entry query" array:
struct stats_query_entry query[FP_SB_MAX_E1x+ BNX2X_FIRST_QUEUE_QUERY_IDX];
FP_SB_MAX_E1x is defined as the maximum number of fast path interrupts and has a value of 16, while BNX2X_FIRST_QUEUE_QUERY_IDX has a value of 3 meaning the array has a total size of 19. Since accesses to "struct stats_query_entry query" are offset-ted by BNX2X_FIRST_QUEUE_QUERY_IDX, that means that the total number of Ethernet queues should not exceed FP_SB_MAX_E1x (16). However one of these queues is reserved for FCOE and thus the number of Ethernet queues should be set to [FP_SB_MAX_E1x -1] (15) if FCOE is enabled or [FP_SB_MAX_E1x] (16) if it is not.
This is also described in a comment in the source code in drivers/net/ethernet/broadcom/bnx2x/bnx2x.h just above the Macro definition of FP_SB_MAX_E1x. Below is the part of this explanation that it important for this patch
/ * The total number of L2 queues, MSIX vectors and HW contexts (CIDs) is * control by the number of fast-path status blocks supported by the * device (HW/FW). Each fast-path status block (FP-SB) aka non-default * status block represents an independent interrupts context that can * serve a regular L2 networking queue. However special L2 queues such * as the FCoE queue do not require a FP-SB and other components like * the CNIC may consume FP-SB reducing the number of possible L2 queues * * If the maximum number of FP-SB available is X then: * a. If CNIC is supported it consumes 1 FP-SB thus the max number of * regular L2 queues is Y=X-1 * b. In MF mode the actual number of L2 queues is Y= (X-1/MF_factor) * c. If the FCoE L2 queue is supported the actual number of L2 queues * is Y+1 * d. The number of irqs (MSIX vectors) is either Y+1 (one extra for * slow-path interrupts) or Y+2 if CNIC is supported (one additional * FP interrupt context for the CNIC). * e. The number of HW context (CID count) is always X or X+1 if FCoE * L2 queue is supported. The cid for the FCoE L2 queue is always X. /
However this driver also supports NICs that use the E2 controller which can handle more queues due to having more FP-SB represented by FP_SB_MAX_E2. Looking at the commits when the E2 support was added, it was originally using the E1x parameters: commit f2e0899f0f27 ("bnx2x: Add 57712 support"). Back then FP_SB_MAX_E2 was set to 16 the same as E1x. However the driver was later updated to take full advantage of the E2 instead of having it be limited to the capabilities of the E1x. But as far as we can tell, the array "stats_query_entry query" was still limited to using the FP-SB available to the E1x cards as part of an oversignt when the driver was updated to take full advantage of the E2, and now with the driver being aware of the greater queue size supported by E2 NICs, it causes the UBSAN warnings seen in the stack traces below.
This patch increases the size of the "stats_query_entry query" array by replacing FP_SB_MAX_E1x with FP_SB_MAX_E2 to be large enough to handle both types of NICs.
Stack traces:
UBSAN: array-index-out-of-bounds in drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.c:1529:11 index 20 is out of range for type 'stats_query_entry [19]' CPU: 12 PID: 858 Comm: systemd-network Not tainted 6.9.0-060900rc7-generic #202405052133 Hardware name: HP ProLiant DL360 Gen9/ProLiant DL360 ---truncated---(CVE-2024-42148)
In the Linux kernel, the following vulnerability has been resolved:
tcp_metrics: validate source addr length
I don't see anything checking that TCP_METRICS_ATTR_SADDR_IPV4 is at least 4 bytes long, and the policy doesn't have an entry for this attribute at all (neither does it for IPv6 but v6 is manually validated).(CVE-2024-42154)
In the Linux kernel, the following vulnerability has been resolved:
s390/pkey: Wipe sensitive data on failure
Wipe sensitive data from stack also if the copy_to_user() fails.(CVE-2024-42157)
In the Linux kernel, the following vulnerability has been resolved:
f2fs: check validation of fault attrs in f2fs_build_fault_attr()
- It missed to check validation of fault attrs in parse_options(), let's fix to add check condition in f2fs_build_fault_attr().
- Use f2fs_build_fault_attr() in __sbi_store() to clean up code.(CVE-2024-42160)
In the Linux kernel, the following vulnerability has been resolved:
media: dvb-frontends: tda10048: Fix integer overflow
state->xtal_hz can be up to 16M, so it can overflow a 32 bit integer when multiplied by pll_mfactor.
Create a new 64 bit variable to hold the calculations.(CVE-2024-42223)
In the Linux kernel, the following vulnerability has been resolved:
USB: serial: mos7840: fix crash on resume
Since commit c49cfa917025 ("USB: serial: use generic method if no alternative is provided in usb serial layer"), USB serial core calls the generic resume implementation when the driver has not provided one.
This can trigger a crash on resume with mos7840 since support for multiple read URBs was added back in 2011. Specifically, both port read URBs are now submitted on resume for open ports, but the context pointer of the second URB is left set to the core rather than mos7840 port structure.
Fix this by implementing dedicated suspend and resume functions for mos7840.
Tested with Delock 87414 USB 2.0 to 4x serial adapter.
| URL | Type | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-4.19.90-2408.3.0.0290.oe2003sp4.aarch64.rpm",
"bpftool-debuginfo-4.19.90-2408.3.0.0290.oe2003sp4.aarch64.rpm",
"kernel-4.19.90-2408.3.0.0290.oe2003sp4.aarch64.rpm",
"kernel-debuginfo-4.19.90-2408.3.0.0290.oe2003sp4.aarch64.rpm",
"kernel-debugsource-4.19.90-2408.3.0.0290.oe2003sp4.aarch64.rpm",
"kernel-devel-4.19.90-2408.3.0.0290.oe2003sp4.aarch64.rpm",
"kernel-source-4.19.90-2408.3.0.0290.oe2003sp4.aarch64.rpm",
"kernel-tools-4.19.90-2408.3.0.0290.oe2003sp4.aarch64.rpm",
"kernel-tools-debuginfo-4.19.90-2408.3.0.0290.oe2003sp4.aarch64.rpm",
"kernel-tools-devel-4.19.90-2408.3.0.0290.oe2003sp4.aarch64.rpm",
"perf-4.19.90-2408.3.0.0290.oe2003sp4.aarch64.rpm",
"perf-debuginfo-4.19.90-2408.3.0.0290.oe2003sp4.aarch64.rpm",
"python2-perf-4.19.90-2408.3.0.0290.oe2003sp4.aarch64.rpm",
"python2-perf-debuginfo-4.19.90-2408.3.0.0290.oe2003sp4.aarch64.rpm",
"python3-perf-4.19.90-2408.3.0.0290.oe2003sp4.aarch64.rpm",
"python3-perf-debuginfo-4.19.90-2408.3.0.0290.oe2003sp4.aarch64.rpm"
],
"src": [
"kernel-4.19.90-2408.3.0.0290.oe2003sp4.src.rpm"
],
"x86_64": [
"bpftool-4.19.90-2408.3.0.0290.oe2003sp4.x86_64.rpm",
"bpftool-debuginfo-4.19.90-2408.3.0.0290.oe2003sp4.x86_64.rpm",
"kernel-4.19.90-2408.3.0.0290.oe2003sp4.x86_64.rpm",
"kernel-debuginfo-4.19.90-2408.3.0.0290.oe2003sp4.x86_64.rpm",
"kernel-debugsource-4.19.90-2408.3.0.0290.oe2003sp4.x86_64.rpm",
"kernel-devel-4.19.90-2408.3.0.0290.oe2003sp4.x86_64.rpm",
"kernel-source-4.19.90-2408.3.0.0290.oe2003sp4.x86_64.rpm",
"kernel-tools-4.19.90-2408.3.0.0290.oe2003sp4.x86_64.rpm",
"kernel-tools-debuginfo-4.19.90-2408.3.0.0290.oe2003sp4.x86_64.rpm",
"kernel-tools-devel-4.19.90-2408.3.0.0290.oe2003sp4.x86_64.rpm",
"perf-4.19.90-2408.3.0.0290.oe2003sp4.x86_64.rpm",
"perf-debuginfo-4.19.90-2408.3.0.0290.oe2003sp4.x86_64.rpm",
"python2-perf-4.19.90-2408.3.0.0290.oe2003sp4.x86_64.rpm",
"python2-perf-debuginfo-4.19.90-2408.3.0.0290.oe2003sp4.x86_64.rpm",
"python3-perf-4.19.90-2408.3.0.0290.oe2003sp4.x86_64.rpm",
"python3-perf-debuginfo-4.19.90-2408.3.0.0290.oe2003sp4.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:20.03-LTS-SP4",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-20.03-LTS-SP4"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.19.90-2408.3.0.0290.oe2003sp4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nethernet: Fix error handling in xemaclite_of_probe\r\n\r\nThis node pointer is returned by of_parse_phandle() with refcount\nincremented in this function. Calling of_node_put() to avoid the\nrefcount leak. As the remove function do.(CVE-2022-48860)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nHID: core: remove unnecessary WARN_ON() in implement()\r\n\r\nSyzkaller hit a warning [1] in a call to implement() when trying\nto write a value into a field of smaller size in an output report.\r\n\r\nSince implement() already has a warn message printed out with the\nhelp of hid_warn() and value in question gets trimmed with:\n\t...\n\tvalue \u0026amp;= m;\n\t...\nWARN_ON may be considered superfluous. Remove it to suppress future\nsyzkaller triggers.\r\n\r\n[1]\nWARNING: CPU: 0 PID: 5084 at drivers/hid/hid-core.c:1451 implement drivers/hid/hid-core.c:1451 [inline]\nWARNING: CPU: 0 PID: 5084 at drivers/hid/hid-core.c:1451 hid_output_report+0x548/0x760 drivers/hid/hid-core.c:1863\nModules linked in:\nCPU: 0 PID: 5084 Comm: syz-executor424 Not tainted 6.9.0-rc7-syzkaller-00183-gcf87f46fd34d #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024\nRIP: 0010:implement drivers/hid/hid-core.c:1451 [inline]\nRIP: 0010:hid_output_report+0x548/0x760 drivers/hid/hid-core.c:1863\n...\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __usbhid_submit_report drivers/hid/usbhid/hid-core.c:591 [inline]\n usbhid_submit_report+0x43d/0x9e0 drivers/hid/usbhid/hid-core.c:636\n hiddev_ioctl+0x138b/0x1f00 drivers/hid/usbhid/hiddev.c:726\n vfs_ioctl fs/ioctl.c:51 [inline]\n __do_sys_ioctl fs/ioctl.c:904 [inline]\n __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:890\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n...(CVE-2024-39509)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfilelock: Remove locks reliably when fcntl/close race is detected\r\n\r\nWhen fcntl_setlk() races with close(), it removes the created lock with\ndo_lock_file_wait().\nHowever, LSMs can allow the first do_lock_file_wait() that created the lock\nwhile denying the second do_lock_file_wait() that tries to remove the lock.\nSeparately, posix_lock_file() could also fail to\nremove a lock due to GFP_KERNEL allocation failure (when splitting a range\nin the middle).\r\n\r\nAfter the bug has been triggered, use-after-free reads will occur in\nlock_get_status() when userspace reads /proc/locks. This can likely be used\nto read arbitrary kernel memory, but can\u0026apos;t corrupt kernel memory.\r\n\r\nFix it by calling locks_remove_posix() instead, which is designed to\nreliably get rid of POSIX locks associated with the given file and\nfiles_struct and is also used by filp_flush().(CVE-2024-41012)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: fix kernel bug on rename operation of broken directory\r\n\r\nSyzbot reported that in rename directory operation on broken directory on\nnilfs2, __block_write_begin_int() called to prepare block write may fail\nBUG_ON check for access exceeding the folio/page size.\r\n\r\nThis is because nilfs_dotdot(), which gets parent directory reference\nentry (\u0026quot;..\u0026quot;) of the directory to be moved or renamed, does not check\nconsistency enough, and may return location exceeding folio/page size for\nbroken directories.\r\n\r\nFix this issue by checking required directory entries (\u0026quot;.\u0026quot; and \u0026quot;..\u0026quot;) in\nthe first chunk of the directory in nilfs_dotdot().(CVE-2024-41034)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nUSB: core: Fix duplicate endpoint bug by clearing reserved bits in the descriptor\r\n\r\nSyzbot has identified a bug in usbcore (see the Closes: tag below)\ncaused by our assumption that the reserved bits in an endpoint\ndescriptor\u0026apos;s bEndpointAddress field will always be 0. As a result of\nthe bug, the endpoint_is_duplicate() routine in config.c (and possibly\nother routines as well) may believe that two descriptors are for\ndistinct endpoints, even though they have the same direction and\nendpoint number. This can lead to confusion, including the bug\nidentified by syzbot (two descriptors with matching endpoint numbers\nand directions, where one was interrupt and the other was bulk).\r\n\r\nTo fix the bug, we will clear the reserved bits in bEndpointAddress\nwhen we parse the descriptor. (Note that both the USB-2.0 and USB-3.1\nspecs say these bits are \u0026quot;Reserved, reset to zero\u0026quot;.) This requires us\nto make a copy of the descriptor earlier in usb_parse_endpoint() and\nuse the copy instead of the original when checking for duplicates.(CVE-2024-41035)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: ethernet: lantiq_etop: fix double free in detach\r\n\r\nThe number of the currently released descriptor is never incremented\nwhich results in the same skb being released multiple times.(CVE-2024-41046)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nhfsplus: fix uninit-value in copy_name\r\n\r\n[syzbot reported]\nBUG: KMSAN: uninit-value in sized_strscpy+0xc4/0x160\n sized_strscpy+0xc4/0x160\n copy_name+0x2af/0x320 fs/hfsplus/xattr.c:411\n hfsplus_listxattr+0x11e9/0x1a50 fs/hfsplus/xattr.c:750\n vfs_listxattr fs/xattr.c:493 [inline]\n listxattr+0x1f3/0x6b0 fs/xattr.c:840\n path_listxattr fs/xattr.c:864 [inline]\n __do_sys_listxattr fs/xattr.c:876 [inline]\n __se_sys_listxattr fs/xattr.c:873 [inline]\n __x64_sys_listxattr+0x16b/0x2f0 fs/xattr.c:873\n x64_sys_call+0x2ba0/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:195\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\r\n\r\nUninit was created at:\n slab_post_alloc_hook mm/slub.c:3877 [inline]\n slab_alloc_node mm/slub.c:3918 [inline]\n kmalloc_trace+0x57b/0xbe0 mm/slub.c:4065\n kmalloc include/linux/slab.h:628 [inline]\n hfsplus_listxattr+0x4cc/0x1a50 fs/hfsplus/xattr.c:699\n vfs_listxattr fs/xattr.c:493 [inline]\n listxattr+0x1f3/0x6b0 fs/xattr.c:840\n path_listxattr fs/xattr.c:864 [inline]\n __do_sys_listxattr fs/xattr.c:876 [inline]\n __se_sys_listxattr fs/xattr.c:873 [inline]\n __x64_sys_listxattr+0x16b/0x2f0 fs/xattr.c:873\n x64_sys_call+0x2ba0/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:195\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n[Fix]\nWhen allocating memory to strbuf, initialize memory to 0.(CVE-2024-41059)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npowerpc/pseries: Whitelist dtl slub object for copying to userspace\r\n\r\nReading the dispatch trace log from /sys/kernel/debug/powerpc/dtl/cpu-*\nresults in a BUG() when the config CONFIG_HARDENED_USERCOPY is enabled as\nshown below.\r\n\r\n kernel BUG at mm/usercopy.c:102!\n Oops: Exception in kernel mode, sig: 5 [#1]\n LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries\n Modules linked in: xfs libcrc32c dm_service_time sd_mod t10_pi sg ibmvfc\n scsi_transport_fc ibmveth pseries_wdt dm_multipath dm_mirror dm_region_hash dm_log dm_mod fuse\n CPU: 27 PID: 1815 Comm: python3 Not tainted 6.10.0-rc3 #85\n Hardware name: IBM,9040-MRX POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1060.00 (NM1060_042) hv:phyp pSeries\n NIP: c0000000005d23d4 LR: c0000000005d23d0 CTR: 00000000006ee6f8\n REGS: c000000120c078c0 TRAP: 0700 Not tainted (6.10.0-rc3)\n MSR: 8000000000029033 \u0026lt;SF,EE,ME,IR,DR,RI,LE\u0026gt; CR: 2828220f XER: 0000000e\n CFAR: c0000000001fdc80 IRQMASK: 0\n [ ... GPRs omitted ... ]\n NIP [c0000000005d23d4] usercopy_abort+0x78/0xb0\n LR [c0000000005d23d0] usercopy_abort+0x74/0xb0\n Call Trace:\n usercopy_abort+0x74/0xb0 (unreliable)\n __check_heap_object+0xf8/0x120\n check_heap_object+0x218/0x240\n __check_object_size+0x84/0x1a4\n dtl_file_read+0x17c/0x2c4\n full_proxy_read+0x8c/0x110\n vfs_read+0xdc/0x3a0\n ksys_read+0x84/0x144\n system_call_exception+0x124/0x330\n system_call_vectored_common+0x15c/0x2ec\n --- interrupt: 3000 at 0x7fff81f3ab34\r\n\r\nCommit 6d07d1cd300f (\u0026quot;usercopy: Restrict non-usercopy caches to size 0\u0026quot;)\nrequires that only whitelisted areas in slab/slub objects can be copied to\nuserspace when usercopy hardening is enabled using CONFIG_HARDENED_USERCOPY.\nDtl contains hypervisor dispatch events which are expected to be read by\nprivileged users. Hence mark this safe for user access.\nSpecify useroffset=0 and usersize=DISPATCH_LOG_BYTES to whitelist the\nentire object.(CVE-2024-41065)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nata: libata-core: Fix double free on error\r\n\r\nIf e.g. the ata_port_alloc() call in ata_host_alloc() fails, we will jump\nto the err_out label, which will call devres_release_group().\ndevres_release_group() will trigger a call to ata_host_release().\nata_host_release() calls kfree(host), so executing the kfree(host) in\nata_host_alloc() will lead to a double free:\r\n\r\nkernel BUG at mm/slub.c:553!\nOops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI\nCPU: 11 PID: 599 Comm: (udev-worker) Not tainted 6.10.0-rc5 #47\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014\nRIP: 0010:kfree+0x2cf/0x2f0\nCode: 5d 41 5e 41 5f 5d e9 80 d6 ff ff 4d 89 f1 41 b8 01 00 00 00 48 89 d9 48 89 da\nRSP: 0018:ffffc90000f377f0 EFLAGS: 00010246\nRAX: ffff888112b1f2c0 RBX: ffff888112b1f2c0 RCX: ffff888112b1f320\nRDX: 000000000000400b RSI: ffffffffc02c9de5 RDI: ffff888112b1f2c0\nRBP: ffffc90000f37830 R08: 0000000000000000 R09: 0000000000000000\nR10: ffffc90000f37610 R11: 617461203a736b6e R12: ffffea00044ac780\nR13: ffff888100046400 R14: ffffffffc02c9de5 R15: 0000000000000006\nFS: 00007f2f1cabe980(0000) GS:ffff88813b380000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f2f1c3acf75 CR3: 0000000111724000 CR4: 0000000000750ef0\nPKRU: 55555554\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? __die_body.cold+0x19/0x27\n ? die+0x2e/0x50\n ? do_trap+0xca/0x110\n ? do_error_trap+0x6a/0x90\n ? kfree+0x2cf/0x2f0\n ? exc_invalid_op+0x50/0x70\n ? kfree+0x2cf/0x2f0\n ? asm_exc_invalid_op+0x1a/0x20\n ? ata_host_alloc+0xf5/0x120 [libata]\n ? ata_host_alloc+0xf5/0x120 [libata]\n ? kfree+0x2cf/0x2f0\n ata_host_alloc+0xf5/0x120 [libata]\n ata_host_alloc_pinfo+0x14/0xa0 [libata]\n ahci_init_one+0x6c9/0xd20 [ahci]\r\n\r\nEnsure that we will not call kfree(host) twice, by performing the kfree()\nonly if the devres_open_group() call failed.(CVE-2024-41087)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nftruncate: pass a signed offset\r\n\r\nThe old ftruncate() syscall, using the 32-bit off_t misses a sign\nextension when called in compat mode on 64-bit architectures. As a\nresult, passing a negative length accidentally succeeds in truncating\nto file size between 2GiB and 4GiB.\r\n\r\nChanging the type of the compat syscall to the signed compat_off_t\nchanges the behavior so it instead returns -EINVAL.\r\n\r\nThe native entry point, the truncate() syscall and the corresponding\nloff_t based variants are all correct already and do not suffer\nfrom this mistake.(CVE-2024-42084)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/panel: ilitek-ili9881c: Fix warning with GPIO controllers that sleep\r\n\r\nThe ilitek-ili9881c controls the reset GPIO using the non-sleeping\ngpiod_set_value() function. This complains loudly when the GPIO\ncontroller needs to sleep. As the caller can sleep, use\ngpiod_set_value_cansleep() to fix the issue.(CVE-2024-42087)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nASoC: fsl-asoc-card: set priv-\u0026gt;pdev before using it\r\n\r\npriv-\u0026gt;pdev pointer was set after being used in\nfsl_asoc_card_audmux_init().\nMove this assignment at the start of the probe function, so\nsub-functions can correctly use pdev through priv.\r\n\r\nfsl_asoc_card_audmux_init() dereferences priv-\u0026gt;pdev to get access to the\ndev struct, used with dev_err macros.\nAs priv is zero-initialised, there would be a NULL pointer dereference.\nNote that if priv-\u0026gt;dev is dereferenced before assignment but never used,\nfor example if there is no error to be printed, the driver won\u0026apos;t crash\nprobably due to compiler optimisations.(CVE-2024-42089)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nx86: stop playing stack games in profile_pc()\r\n\r\nThe \u0026apos;profile_pc()\u0026apos; function is used for timer-based profiling, which\nisn\u0026apos;t really all that relevant any more to begin with, but it also ends\nup making assumptions based on the stack layout that aren\u0026apos;t necessarily\nvalid.\r\n\r\nBasically, the code tries to account the time spent in spinlocks to the\ncaller rather than the spinlock, and while I support that as a concept,\nit\u0026apos;s not worth the code complexity or the KASAN warnings when no serious\nprofiling is done using timers anyway these days.\r\n\r\nAnd the code really does depend on stack layout that is only true in the\nsimplest of cases. We\u0026apos;ve lost the comment at some point (I think when\nthe 32-bit and 64-bit code was unified), but it used to say:\r\n\r\n\tAssume the lock function has either no stack frame or a copy\n\tof eflags from PUSHF.\r\n\r\nwhich explains why it just blindly loads a word or two straight off the\nstack pointer and then takes a minimal look at the values to just check\nif they might be eflags or the return pc:\r\n\r\n\tEflags always has bits 22 and up cleared unlike kernel addresses\r\n\r\nbut that basic stack layout assumption assumes that there isn\u0026apos;t any lock\ndebugging etc going on that would complicate the code and cause a stack\nframe.\r\n\r\nIt causes KASAN unhappiness reported for years by syzkaller [1] and\nothers [2].\r\n\r\nWith no real practical reason for this any more, just remove the code.\r\n\r\nJust for historical interest, here\u0026apos;s some background commits relating to\nthis code from 2006:\r\n\r\n 0cb91a229364 (\u0026quot;i386: Account spinlocks to the caller during profiling for !FP kernels\u0026quot;)\n 31679f38d886 (\u0026quot;Simplify profile_pc on x86-64\u0026quot;)\r\n\r\nand a code unification from 2009:\r\n\r\n ef4512882dbe (\u0026quot;x86: time_32/64.c unify profile_pc\u0026quot;)\r\n\r\nbut the basics of this thing actually goes back to before the git tree.(CVE-2024-42096)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nRevert \u0026quot;mm/writeback: fix possible divide-by-zero in wb_dirty_limits(), again\u0026quot;\r\n\r\nPatch series \u0026quot;mm: Avoid possible overflows in dirty throttling\u0026quot;.\r\n\r\nDirty throttling logic assumes dirty limits in page units fit into\n32-bits. This patch series makes sure this is true (see patch 2/2 for\nmore details).\r\n\r\n\nThis patch (of 2):\r\n\r\nThis reverts commit 9319b647902cbd5cc884ac08a8a6d54ce111fc78.\r\n\r\nThe commit is broken in several ways. Firstly, the removed (u64) cast\nfrom the multiplication will introduce a multiplication overflow on 32-bit\narchs if wb_thresh * bg_thresh \u0026gt;= 1\u0026lt;\u0026lt;32 (which is actually common - the\ndefault settings with 4GB of RAM will trigger this). Secondly, the\ndiv64_u64() is unnecessarily expensive on 32-bit archs. We have\ndiv64_ul() in case we want to be safe \u0026amp; cheap. Thirdly, if dirty\nthresholds are larger than 1\u0026lt;\u0026lt;32 pages, then dirty balancing is going to\nblow up in many other spectacular ways anyway so trying to fix one\npossible overflow is just moot.(CVE-2024-42102)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: fix inode number range checks\r\n\r\nPatch series \u0026quot;nilfs2: fix potential issues related to reserved inodes\u0026quot;.\r\n\r\nThis series fixes one use-after-free issue reported by syzbot, caused by\nnilfs2\u0026apos;s internal inode being exposed in the namespace on a corrupted\nfilesystem, and a couple of flaws that cause problems if the starting\nnumber of non-reserved inodes written in the on-disk super block is\nintentionally (or corruptly) changed from its default value. \r\n\r\n\nThis patch (of 3):\r\n\r\nIn the current implementation of nilfs2, \u0026quot;nilfs-\u0026gt;ns_first_ino\u0026quot;, which\ngives the first non-reserved inode number, is read from the superblock,\nbut its lower limit is not checked.\r\n\r\nAs a result, if a number that overlaps with the inode number range of\nreserved inodes such as the root directory or metadata files is set in the\nsuper block parameter, the inode number test macros (NILFS_MDT_INODE and\nNILFS_VALID_INODE) will not function properly.\r\n\r\nIn addition, these test macros use left bit-shift calculations using with\nthe inode number as the shift count via the BIT macro, but the result of a\nshift calculation that exceeds the bit width of an integer is undefined in\nthe C specification, so if \u0026quot;ns_first_ino\u0026quot; is set to a large value other\nthan the default value NILFS_USER_INO (=11), the macros may potentially\nmalfunction depending on the environment.\r\n\r\nFix these issues by checking the lower bound of \u0026quot;nilfs-\u0026gt;ns_first_ino\u0026quot; and\nby preventing bit shifts equal to or greater than the NILFS_USER_INO\nconstant in the inode number test macros.\r\n\r\nAlso, change the type of \u0026quot;ns_first_ino\u0026quot; from signed integer to unsigned\ninteger to avoid the need for type casting in comparisons such as the\nlower bound check introduced this time.(CVE-2024-42105)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\norangefs: fix out-of-bounds fsid access\r\n\r\nArnd Bergmann sent a patch to fsdevel, he says:\r\n\r\n\u0026quot;orangefs_statfs() copies two consecutive fields of the superblock into\nthe statfs structure, which triggers a warning from the string fortification\nhelpers\u0026quot;\r\n\r\nJan Kara suggested an alternate way to do the patch to make it more readable.\r\n\r\nI ran both ideas through xfstests and both seem fine. This patch\nis based on Jan Kara\u0026apos;s suggestion.(CVE-2024-42143)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbnx2x: Fix multiple UBSAN array-index-out-of-bounds\r\n\r\nFix UBSAN warnings that occur when using a system with 32 physical\ncpu cores or more, or when the user defines a number of Ethernet\nqueues greater than or equal to FP_SB_MAX_E1x using the num_queues\nmodule parameter.\r\n\r\nCurrently there is a read/write out of bounds that occurs on the array\n\u0026quot;struct stats_query_entry query\u0026quot; present inside the \u0026quot;bnx2x_fw_stats_req\u0026quot;\nstruct in \u0026quot;drivers/net/ethernet/broadcom/bnx2x/bnx2x.h\u0026quot;.\nLooking at the definition of the \u0026quot;struct stats_query_entry query\u0026quot; array:\r\n\r\nstruct stats_query_entry query[FP_SB_MAX_E1x+\n BNX2X_FIRST_QUEUE_QUERY_IDX];\r\n\r\nFP_SB_MAX_E1x is defined as the maximum number of fast path interrupts and\nhas a value of 16, while BNX2X_FIRST_QUEUE_QUERY_IDX has a value of 3\nmeaning the array has a total size of 19.\nSince accesses to \u0026quot;struct stats_query_entry query\u0026quot; are offset-ted by\nBNX2X_FIRST_QUEUE_QUERY_IDX, that means that the total number of Ethernet\nqueues should not exceed FP_SB_MAX_E1x (16). However one of these queues\nis reserved for FCOE and thus the number of Ethernet queues should be set\nto [FP_SB_MAX_E1x -1] (15) if FCOE is enabled or [FP_SB_MAX_E1x] (16) if\nit is not.\r\n\r\nThis is also described in a comment in the source code in\ndrivers/net/ethernet/broadcom/bnx2x/bnx2x.h just above the Macro definition\nof FP_SB_MAX_E1x. Below is the part of this explanation that it important\nfor this patch\r\n\r\n/*\n * The total number of L2 queues, MSIX vectors and HW contexts (CIDs) is\n * control by the number of fast-path status blocks supported by the\n * device (HW/FW). Each fast-path status block (FP-SB) aka non-default\n * status block represents an independent interrupts context that can\n * serve a regular L2 networking queue. However special L2 queues such\n * as the FCoE queue do not require a FP-SB and other components like\n * the CNIC may consume FP-SB reducing the number of possible L2 queues\n *\n * If the maximum number of FP-SB available is X then:\n * a. If CNIC is supported it consumes 1 FP-SB thus the max number of\n * regular L2 queues is Y=X-1\n * b. In MF mode the actual number of L2 queues is Y= (X-1/MF_factor)\n * c. If the FCoE L2 queue is supported the actual number of L2 queues\n * is Y+1\n * d. The number of irqs (MSIX vectors) is either Y+1 (one extra for\n * slow-path interrupts) or Y+2 if CNIC is supported (one additional\n * FP interrupt context for the CNIC).\n * e. The number of HW context (CID count) is always X or X+1 if FCoE\n * L2 queue is supported. The cid for the FCoE L2 queue is always X.\n */\r\n\r\nHowever this driver also supports NICs that use the E2 controller which can\nhandle more queues due to having more FP-SB represented by FP_SB_MAX_E2.\nLooking at the commits when the E2 support was added, it was originally\nusing the E1x parameters: commit f2e0899f0f27 (\u0026quot;bnx2x: Add 57712 support\u0026quot;).\nBack then FP_SB_MAX_E2 was set to 16 the same as E1x. However the driver\nwas later updated to take full advantage of the E2 instead of having it be\nlimited to the capabilities of the E1x. But as far as we can tell, the\narray \u0026quot;stats_query_entry query\u0026quot; was still limited to using the FP-SB\navailable to the E1x cards as part of an oversignt when the driver was\nupdated to take full advantage of the E2, and now with the driver being\naware of the greater queue size supported by E2 NICs, it causes the UBSAN\nwarnings seen in the stack traces below.\r\n\r\nThis patch increases the size of the \u0026quot;stats_query_entry query\u0026quot; array by\nreplacing FP_SB_MAX_E1x with FP_SB_MAX_E2 to be large enough to handle\nboth types of NICs.\r\n\r\nStack traces:\r\n\r\nUBSAN: array-index-out-of-bounds in\n drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.c:1529:11\nindex 20 is out of range for type \u0026apos;stats_query_entry [19]\u0026apos;\nCPU: 12 PID: 858 Comm: systemd-network Not tainted 6.9.0-060900rc7-generic\n\t #202405052133\nHardware name: HP ProLiant DL360 Gen9/ProLiant DL360 \n---truncated---(CVE-2024-42148)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntcp_metrics: validate source addr length\r\n\r\nI don\u0026apos;t see anything checking that TCP_METRICS_ATTR_SADDR_IPV4\nis at least 4 bytes long, and the policy doesn\u0026apos;t have an entry\nfor this attribute at all (neither does it for IPv6 but v6 is\nmanually validated).(CVE-2024-42154)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ns390/pkey: Wipe sensitive data on failure\r\n\r\nWipe sensitive data from stack also if the copy_to_user() fails.(CVE-2024-42157)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nf2fs: check validation of fault attrs in f2fs_build_fault_attr()\r\n\r\n- It missed to check validation of fault attrs in parse_options(),\nlet\u0026apos;s fix to add check condition in f2fs_build_fault_attr().\n- Use f2fs_build_fault_attr() in __sbi_store() to clean up code.(CVE-2024-42160)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: dvb-frontends: tda10048: Fix integer overflow\r\n\r\nstate-\u0026gt;xtal_hz can be up to 16M, so it can overflow a 32 bit integer\nwhen multiplied by pll_mfactor.\r\n\r\nCreate a new 64 bit variable to hold the calculations.(CVE-2024-42223)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nUSB: serial: mos7840: fix crash on resume\r\n\r\nSince commit c49cfa917025 (\u0026quot;USB: serial: use generic method if no\nalternative is provided in usb serial layer\u0026quot;), USB serial core calls the\ngeneric resume implementation when the driver has not provided one.\r\n\r\nThis can trigger a crash on resume with mos7840 since support for\nmultiple read URBs was added back in 2011. Specifically, both port read\nURBs are now submitted on resume for open ports, but the context pointer\nof the second URB is left set to the core rather than mos7840 port\nstructure.\r\n\r\nFix this by implementing dedicated suspend and resume functions for\nmos7840.\r\n\r\nTested with Delock 87414 USB 2.0 to 4x serial adapter.\r\n\r\n[ johan: analyse crash and rewrite commit message; set busy flag on\n resume; drop bulk-in check; drop unnecessary usb_kill_urb() ](CVE-2024-42244)",
"id": "OESA-2024-1996",
"modified": "2026-08-06T11:07:28Z",
"published": "2024-08-16T11:07:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1996"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48860"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39509"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41012"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41034"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41035"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41046"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41059"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41065"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41087"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42084"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42087"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42089"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42096"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42102"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42105"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42143"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42148"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42154"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42157"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42160"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42223"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42244"
}
],
"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-48860",
"CVE-2024-39509",
"CVE-2024-41012",
"CVE-2024-41034",
"CVE-2024-41035",
"CVE-2024-41046",
"CVE-2024-41059",
"CVE-2024-41065",
"CVE-2024-41087",
"CVE-2024-42084",
"CVE-2024-42087",
"CVE-2024-42089",
"CVE-2024-42096",
"CVE-2024-42102",
"CVE-2024-42105",
"CVE-2024-42143",
"CVE-2024-42148",
"CVE-2024-42154",
"CVE-2024-42157",
"CVE-2024-42160",
"CVE-2024-42223",
"CVE-2024-42244"
]
}
OESA-2025-2882 (CVE-2024-42154)
Vulnerability from osv_openeuler – Published: 2025-12-30 11:10 – Updated: 2026-08-06 11:10 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:tcp_metrics: validate source addr lengthI don t see anything checking that TCP_METRICS_ATTR_SADDR_IPV4is at least 4 bytes long, and the policy doesn t have an entryfor this attribute at all (neither does it for IPv6 but v6 ismanually validated).(CVE-2024-42154)
In the Linux kernel, the following vulnerability has been resolved:resource: fix region_intersects() vs add_memory_driver_managed()On a system with CXL memory, the resource tree (/proc/iomem) related toCXL memory may look like something as follows.490000000-50fffffff : CXL Window 0 490000000-50fffffff : region0 490000000-50fffffff : dax0.0 490000000-50fffffff : System RAM (kmem)Because drivers/dax/kmem.c calls add_memory_driver_managed() duringonlining CXL memory, which makes System RAM (kmem) a descendant of CXLWindow X . This confuses region_intersects(), which expects all SystemRAM resources to be at the top level of iomem_resource. This can lead tobugs.For example, when the following command line is executed to write somememory in CXL memory range via /dev/mem, $ dd if=data of=/dev/mem bs=$((1 << 10)) seek=$((0x490000000 >> 10)) count=1 dd: error writing /dev/mem : Bad address 1+0 records in 0+0 records out 0 bytes copied, 0.0283507 s, 0.0 kB/sthe command fails as expected. However, the error code is wrong. Itshould be Operation not permitted instead of Bad address . Moreseriously, the /dev/mem permission checking in devmem_is_allowed() passesincorrectly. Although the accessing is prevented later because ioremap()isn t allowed to map system RAM, it is a potential security issue. Duringcommand executing, the following warning is reported in the kernel log forcalling ioremap() on system RAM. ioremap on RAM at 0x0000000490000000 - 0x0000000490000fff WARNING: CPU: 2 PID: 416 at arch/x86/mm/ioremap.c:216 __ioremap_caller.constprop.0+0x131/0x35d Call Trace: memremap+0xcb/0x184 xlate_dev_mem_ptr+0x25/0x2f write_mem+0x94/0xfb vfs_write+0x128/0x26d ksys_write+0xac/0xfe do_syscall_64+0x9a/0xfd entry_SYSCALL_64_after_hwframe+0x4b/0x53The details of command execution process are as follows. In the aboveresource tree, System RAM is a descendant of CXL Window 0 instead of atop level resource. So, region_intersects() will report no System RAMresources in the CXL memory region incorrectly, because it only checks thetop level resources. Consequently, devmem_is_allowed() will return 1(allow access via /dev/mem) for CXL memory region incorrectly. Fortunately, ioremap() doesn t allow to map System RAM and reject theaccess.So, region_intersects() needs to be fixed to work correctly with theresource tree with System RAM not at top level as above. To fix it, ifwe found a unmatched resource in the top level, we will continue to searchmatched resources in its descendant resources. So, we will not miss anymatched resources in resource tree anymore.In the new implementation, an example resource tree|------------- CXL Window 0 ------------||-- System RAM --|will behave similar as the following fake resource tree forregion_intersects(, IORESOURCE_SYSTEM_RAM, ),|-- System RAM --||-- CXL Window 0a --|Where CXL Window 0a is part of the original CXL Window 0 thatisn t covered by System RAM .(CVE-2024-49878)
In the Linux kernel, the following vulnerability has been resolved:
wifi: ath10k: avoid NULL pointer error during sdio remove
When running 'rmmod ath10k', ath10k_sdio_remove() will free sdio workqueue by destroy_workqueue(). But if CONFIG_INIT_ON_FREE_DEFAULT_ON is set to yes, kernel panic will happen: Call trace: destroy_workqueue+0x1c/0x258 ath10k_sdio_remove+0x84/0x94 sdio_bus_remove+0x50/0x16c device_release_driver_internal+0x188/0x25c device_driver_detach+0x20/0x2c
This is because during 'rmmod ath10k', ath10k_sdio_remove() will call ath10k_core_destroy() before destroy_workqueue(). wiphy_dev_release() will finally be called in ath10k_core_destroy(). This function will free struct cfg80211_registered_device *rdev and all its members, including wiphy, dev and the pointer of sdio workqueue. Then the pointer of sdio workqueue will be set to NULL due to CONFIG_INIT_ON_FREE_DEFAULT_ON.
After device release, destroy_workqueue() will use NULL pointer then the kernel panic happen.
Call trace: ath10k_sdio_remove ->ath10k_core_unregister …… ->ath10k_core_stop ->ath10k_hif_stop ->ath10k_sdio_irq_disable ->ath10k_hif_power_down ->del_timer_sync(&ar_sdio->sleep_timer) ->ath10k_core_destroy ->ath10k_mac_destroy ->ieee80211_free_hw ->wiphy_free …… ->wiphy_dev_release ->destroy_workqueue
Need to call destroy_workqueue() before ath10k_core_destroy(), free the work queue buffer first and then free pointer of work queue by ath10k_core_destroy(). This order matches the error path order in ath10k_sdio_probe().
No work will be queued on sdio workqueue between it is destroyed and ath10k_core_destroy() is called. Based on the call_stack above, the reason is: Only ath10k_sdio_sleep_timer_handler(), ath10k_sdio_hif_tx_sg() and ath10k_sdio_irq_disable() will queue work on sdio workqueue. Sleep timer will be deleted before ath10k_core_destroy() in ath10k_hif_power_down(). ath10k_sdio_irq_disable() only be called in ath10k_hif_stop(). ath10k_core_unregister() will call ath10k_hif_power_down() to stop hif bus, so ath10k_sdio_hif_tx_sg() won't be called anymore.
Tested-on: QCA6174 hw3.2 SDIO WLAN.RMH.4.4.1-00189(CVE-2024-56599)
In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlwifi: limit printed string from FW file
There's no guarantee here that the file is always with a NUL-termination, so reading the string may read beyond the end of the TLV. If that's the last TLV in the file, it can perhaps even read beyond the end of the file buffer.
Fix that by limiting the print format to the size of the buffer we have.(CVE-2025-21905)
In the Linux kernel, the following vulnerability has been resolved:
ppp: Fix KMSAN uninit-value warning with bpf
Syzbot caught an "KMSAN: uninit-value" warning [1], which is caused by the ppp driver not initializing a 2-byte header when using socket filter.
The following code can generate a PPP filter BPF program: ''' struct bpf_program fp; pcap_t *handle; handle = pcap_open_dead(DLT_PPP_PPPD, 65535); pcap_compile(handle, &fp, "ip and outbound", 0, 0); bpf_dump(&fp, 1); ''' Its output is: ''' (000) ldh [2] (001) jeq #0x21 jt 2 jf 5 (002) ldb [0] (003) jeq #0x1 jt 4 jf 5 (004) ret #65535 (005) ret #0 ''' Wen can find similar code at the following link: https://github.com/ppp-project/ppp/blob/master/pppd/options.c#L1680 The maintainer of this code repository is also the original maintainer of the ppp driver.
As you can see the BPF program skips 2 bytes of data and then reads the 'Protocol' field to determine if it's an IP packet. Then it read the first byte of the first 2 bytes to determine the direction.
The issue is that only the first byte indicating direction is initialized in current ppp driver code while the second byte is not initialized.
For normal BPF programs generated by libpcap, uninitialized data won't be used, so it's not a problem. However, for carefully crafted BPF programs, such as those generated by syzkaller [2], which start reading from offset 0, the uninitialized data will be used and caught by KMSAN.
[1] https://syzkaller.appspot.com/bug?extid=853242d9c9917165d791 [2] https://syzkaller.appspot.com/text?tag=ReproC&x=11994913980000(CVE-2025-21922)
In the Linux kernel, the following vulnerability has been resolved:
media: venus: hfi: add check to handle incorrect queue size
qsize represents size of shared queued between driver and video firmware. Firmware can modify this value to an invalid large value. In such situation, empty_space will be bigger than the space actually available. Since new_wr_idx is not checked, so the following code will result in an OOB write. ... qsize = qhdr->q_size
if (wr_idx >= rd_idx) empty_space = qsize - (wr_idx - rd_idx) .... if (new_wr_idx < qsize) { memcpy(wr_ptr, packet, dwords << 2) --> OOB write
Add check to ensure qsize is within the allocated size while reading and writing packets into the queue.(CVE-2025-23158)
In the Linux kernel, the following vulnerability has been resolved:
media: mediatek: vcodec: Fix a resource leak related to the scp device in FW initialization
On Mediatek devices with a system companion processor (SCP) the mtk_scp structure has to be removed explicitly to avoid a resource leak. Free the structure in case the allocation of the firmware structure fails during the firmware initialization.(CVE-2025-23160)
In the Linux kernel, the following vulnerability has been resolved:
net: tls: explicitly disallow disconnect
syzbot discovered that it can disconnect a TLS socket and then run into all sort of unexpected corner cases. I have a vague recollection of Eric pointing this out to us a long time ago. Supporting disconnect is really hard, for one thing if offload is enabled we'd need to wait for all packets to be acked. Disconnect is not commonly used, disallow it.
The immediate problem syzbot run into is the warning in the strp, but that's just the easiest bug to trigger:
WARNING: CPU: 0 PID: 5834 at net/tls/tls_strp.c:486 tls_strp_msg_load+0x72e/0xa80 net/tls/tls_strp.c:486 RIP: 0010:tls_strp_msg_load+0x72e/0xa80 net/tls/tls_strp.c:486 Call Trace: <TASK> tls_rx_rec_wait+0x280/0xa60 net/tls/tls_sw.c:1363 tls_sw_recvmsg+0x85c/0x1c30 net/tls/tls_sw.c:2043 inet6_recvmsg+0x2c9/0x730 net/ipv6/af_inet6.c:678 sock_recvmsg_nosec net/socket.c:1023 [inline] sock_recvmsg+0x109/0x280 net/socket.c:1045 __sys_recvfrom+0x202/0x380 net/socket.c:2237(CVE-2025-37756)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix the warning from __kernel_write_iter
[ 2110.972290] ------------[ cut here ]------------ [ 2110.972301] WARNING: CPU: 3 PID: 735 at fs/read_write.c:599 __kernel_write_iter+0x21b/0x280
This patch doesn't allow writing to directory.(CVE-2025-37775)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix use-after-free in smb_break_all_levII_oplock()
There is a room in smb_break_all_levII_oplock that can cause racy issues when unlocking in the middle of the loop. This patch use read lock to protect whole loop.(CVE-2025-37776)
In the Linux kernel, the following vulnerability has been resolved:
pwm: mediatek: Prevent divide-by-zero in pwm_mediatek_config()
With CONFIG_COMPILE_TEST && !CONFIG_HAVE_CLK, pwm_mediatek_config() has a divide-by-zero in the following line:
do_div(resolution, clk_get_rate(pc->clk_pwms[pwm->hwpwm]));
due to the fact that the !CONFIG_HAVE_CLK version of clk_get_rate() returns zero.
This is presumably just a theoretical problem: COMPILE_TEST overrides the dependency on RALINK which would select COMMON_CLK. Regardless it's a good idea to check for the error explicitly to avoid divide-by-zero.
Fixes the following warning:
drivers/pwm/pwm-mediatek.o: warning: objtool: .text: unexpected end of section
ukleinek: s/CONFIG_CLK/CONFIG_HAVE_CLK/
In the Linux kernel, the following vulnerability has been resolved:
iommu/amd: Fix potential buffer overflow in parse_ivrs_acpihid
There is a string parsing logic error which can lead to an overflow of hid or uid buffers. Comparing ACPIID_LEN against a total string length doesn't take into account the lengths of individual hid and uid buffers so the check is insufficient in some cases. For example if the length of hid string is 4 and the length of the uid string is 260, the length of str will be equal to ACPIID_LEN + 1 but uid string will overflow uid buffer which size is 256.
The same applies to the hid string with length 13 and uid string with length 250.
Check the length of hid and uid strings separately to prevent buffer overflow.
Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-37927)
In the Linux kernel, the following vulnerability has been resolved:
x86/sev: Evict cache lines during SNP memory validation
An SNP cache coherency vulnerability requires a cache line eviction mitigation when validating memory after a page state change to private. The specific mitigation is to touch the first and last byte of each 4K page that is being validated. There is no need to perform the mitigation when performing a page state change to shared and rescinding validation.
CPUID bit Fn8000001F_EBX[31] defines the COHERENCY_SFW_NO CPUID bit that, when set, indicates that the software mitigation for this vulnerability is not needed.
Implement the mitigation and invoke it when validating memory (making it private) and the COHERENCY_SFW_NO bit is not set, indicating the SNP guest is vulnerable.(CVE-2025-38560)
In the Linux kernel, the following vulnerability has been resolved:
i40e: remove read access to debugfs files
The 'command' and 'netdev_ops' debugfs files are a legacy debugging interface supported by the i40e driver since its early days by commit 02e9c290814c ("i40e: debugfs interface").
Both of these debugfs files provide a read handler which is mostly useless, and which is implemented with questionable logic. They both use a static 256 byte buffer which is initialized to the empty string. In the case of the 'command' file this buffer is literally never used and simply wastes space. In the case of the 'netdev_ops' file, the last command written is saved here.
On read, the files contents are presented as the name of the device followed by a colon and then the contents of their respective static buffer. For 'command' this will always be "<device>: ". For 'netdev_ops', this will be "<device>: <last command written>". But note the buffer is shared between all devices operated by this module. At best, it is mostly meaningless information, and at worse it could be accessed simultaneously as there doesn't appear to be any locking mechanism.
We have also recently received multiple reports for both read functions about their use of snprintf and potential overflow that could result in reading arbitrary kernel memory. For the 'command' file, this is definitely impossible, since the static buffer is always zero and never written to. For the 'netdev_ops' file, it does appear to be possible, if the user carefully crafts the command input, it will be copied into the buffer, which could be large enough to cause snprintf to truncate, which then causes the copy_to_user to read beyond the length of the buffer allocated by kzalloc.
A minimal fix would be to replace snprintf() with scnprintf() which would cap the return to the number of bytes written, preventing an overflow. A more involved fix would be to drop the mostly useless static buffers, saving 512 bytes and modifying the read functions to stop needing those as input.
Instead, lets just completely drop the read access to these files. These are debug interfaces exposed as part of debugfs, and I don't believe that dropping read access will break any script, as the provided output is pretty useless. You can find the netdev name through other more standard interfaces, and the 'netdev_ops' interface can easily result in garbage if you issue simultaneous writes to multiple devices at once.
In order to properly remove the i40e_dbg_netdev_ops_buf, we need to refactor its write function to avoid using the static buffer. Instead, use the same logic as the i40e_dbg_command_write, with an allocated buffer. Update the code to use this instead of the static buffer, and ensure we free the buffer on exit. This fixes simultaneous writes to 'netdev_ops' on multiple devices, and allows us to remove the now unused static buffer along with removing the read access.(CVE-2025-39901)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: smbdirect: verify remaining_data_length respects max_fragmented_recv_size
This is inspired by the check for data_offset + data_length.(CVE-2025-39942)
In the Linux kernel, the following vulnerability has been resolved:
mm/ksm: fix flag-dropping behavior in ksm_madvise
syzkaller discovered the following crash: (kernel BUG)
[ 44.607039] ------------[ cut here ]------------ [ 44.607422] kernel BUG at mm/userfaultfd.c:2067! [ 44.608148] Oops: invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI [ 44.608814] CPU: 1 UID: 0 PID: 2475 Comm: reproducer Not tainted 6.16.0-rc6 #1 PREEMPT(none) [ 44.609635] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [ 44.610695] RIP: 0010:userfaultfd_release_all+0x3a8/0x460
<snip other registers, drop unreliable trace>
[ 44.617726] Call Trace: [ 44.617926] <TASK> [ 44.619284] userfaultfd_release+0xef/0x1b0 [ 44.620976] __fput+0x3f9/0xb60 [ 44.621240] fput_close_sync+0x110/0x210 [ 44.622222] __x64_sys_close+0x8f/0x120 [ 44.622530] do_syscall_64+0x5b/0x2f0 [ 44.622840] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 44.623244] RIP: 0033:0x7f365bb3f227
Kernel panics because it detects UFFD inconsistency during userfaultfd_release_all(). Specifically, a VMA which has a valid pointer to vma->vm_userfaultfd_ctx, but no UFFD flags in vma->vm_flags.
The inconsistency is caused in ksm_madvise(): when user calls madvise() with MADV_UNMEARGEABLE on a VMA that is registered for UFFD in MINOR mode, it accidentally clears all flags stored in the upper 32 bits of vma->vm_flags.
Assuming x86_64 kernel build, unsigned long is 64-bit and unsigned int and int are 32-bit wide. This setup causes the following mishap during the &= ~VM_MERGEABLE assignment.
VM_MERGEABLE is a 32-bit constant of type unsigned int, 0x8000'0000. After ~ is applied, it becomes 0x7fff'ffff unsigned int, which is then promoted to unsigned long before the & operation. This promotion fills upper 32 bits with leading 0s, as we're doing unsigned conversion (and even for a signed conversion, this wouldn't help as the leading bit is 0). & operation thus ends up AND-ing vm_flags with 0x0000'0000'7fff'ffff instead of intended 0xffff'ffff'7fff'ffff and hence accidentally clears the upper 32-bits of its value.
Fix it by changing VM_MERGEABLE constant to unsigned long, using the
BIT() macro.
Note: other VM_ flags are not affected: This only happens to the VM_MERGEABLE flag, as the other VM_ flags are all constants of type int and after ~ operation, they end up with leading 1 and are thus converted to unsigned long with leading 1s.
Note 2: After commit 31defc3b01d9 ("userfaultfd: remove (VM_)BUG_ON()s"), this is no longer a kernel BUG, but a WARNING at the same place:
[ 45.595973] WARNING: CPU: 1 PID: 2474 at mm/userfaultfd.c:2067
but the root-cause (flag-drop) remains the same.
[(CVE-2025-40040)
In the Linux kernel, the following vulnerability has been resolved:
net: use dst_dev_rcu() in sk_setup_caps()
Use RCU to protect accesses to dst->dev from sk_setup_caps() and sk_dst_gso_max_size().
Also use dst_dev_rcu() in ip6_dst_mtu_maybe_forward(), and ip_dst_mtu_maybe_forward().
ip4_dst_hoplimit() can use dst_dev_net_rcu().(CVE-2025-40170)
| URL | Type | |||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-6.6.0-129.0.0.114.oe2403.aarch64.rpm",
"bpftool-debuginfo-6.6.0-129.0.0.114.oe2403.aarch64.rpm",
"kernel-6.6.0-129.0.0.114.oe2403.aarch64.rpm",
"kernel-debuginfo-6.6.0-129.0.0.114.oe2403.aarch64.rpm",
"kernel-debugsource-6.6.0-129.0.0.114.oe2403.aarch64.rpm",
"kernel-devel-6.6.0-129.0.0.114.oe2403.aarch64.rpm",
"kernel-headers-6.6.0-129.0.0.114.oe2403.aarch64.rpm",
"kernel-source-6.6.0-129.0.0.114.oe2403.aarch64.rpm",
"kernel-tools-6.6.0-129.0.0.114.oe2403.aarch64.rpm",
"kernel-tools-debuginfo-6.6.0-129.0.0.114.oe2403.aarch64.rpm",
"kernel-tools-devel-6.6.0-129.0.0.114.oe2403.aarch64.rpm",
"perf-6.6.0-129.0.0.114.oe2403.aarch64.rpm",
"perf-debuginfo-6.6.0-129.0.0.114.oe2403.aarch64.rpm",
"python3-perf-6.6.0-129.0.0.114.oe2403.aarch64.rpm",
"python3-perf-debuginfo-6.6.0-129.0.0.114.oe2403.aarch64.rpm"
],
"src": [
"kernel-6.6.0-129.0.0.114.oe2403.src.rpm"
],
"x86_64": [
"bpftool-6.6.0-129.0.0.114.oe2403.x86_64.rpm",
"bpftool-debuginfo-6.6.0-129.0.0.114.oe2403.x86_64.rpm",
"kernel-6.6.0-129.0.0.114.oe2403.x86_64.rpm",
"kernel-debuginfo-6.6.0-129.0.0.114.oe2403.x86_64.rpm",
"kernel-debugsource-6.6.0-129.0.0.114.oe2403.x86_64.rpm",
"kernel-devel-6.6.0-129.0.0.114.oe2403.x86_64.rpm",
"kernel-headers-6.6.0-129.0.0.114.oe2403.x86_64.rpm",
"kernel-source-6.6.0-129.0.0.114.oe2403.x86_64.rpm",
"kernel-tools-6.6.0-129.0.0.114.oe2403.x86_64.rpm",
"kernel-tools-debuginfo-6.6.0-129.0.0.114.oe2403.x86_64.rpm",
"kernel-tools-devel-6.6.0-129.0.0.114.oe2403.x86_64.rpm",
"perf-6.6.0-129.0.0.114.oe2403.x86_64.rpm",
"perf-debuginfo-6.6.0-129.0.0.114.oe2403.x86_64.rpm",
"python3-perf-6.6.0-129.0.0.114.oe2403.x86_64.rpm",
"python3-perf-debuginfo-6.6.0-129.0.0.114.oe2403.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:24.03-LTS",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.6.0-129.0.0.114.oe2403"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:tcp_metrics: validate source addr lengthI don t see anything checking that TCP_METRICS_ATTR_SADDR_IPV4is at least 4 bytes long, and the policy doesn t have an entryfor this attribute at all (neither does it for IPv6 but v6 ismanually validated).(CVE-2024-42154)\n\nIn the Linux kernel, the following vulnerability has been resolved:resource: fix region_intersects() vs add_memory_driver_managed()On a system with CXL memory, the resource tree (/proc/iomem) related toCXL memory may look like something as follows.490000000-50fffffff : CXL Window 0 490000000-50fffffff : region0 490000000-50fffffff : dax0.0 490000000-50fffffff : System RAM (kmem)Because drivers/dax/kmem.c calls add_memory_driver_managed() duringonlining CXL memory, which makes System RAM (kmem) a descendant of CXLWindow X . This confuses region_intersects(), which expects all SystemRAM resources to be at the top level of iomem_resource. This can lead tobugs.For example, when the following command line is executed to write somememory in CXL memory range via /dev/mem, $ dd if=data of=/dev/mem bs=$((1 \u0026lt;\u0026lt; 10)) seek=$((0x490000000 \u0026gt;\u0026gt; 10)) count=1 dd: error writing /dev/mem : Bad address 1+0 records in 0+0 records out 0 bytes copied, 0.0283507 s, 0.0 kB/sthe command fails as expected. However, the error code is wrong. Itshould be Operation not permitted instead of Bad address . Moreseriously, the /dev/mem permission checking in devmem_is_allowed() passesincorrectly. Although the accessing is prevented later because ioremap()isn t allowed to map system RAM, it is a potential security issue. Duringcommand executing, the following warning is reported in the kernel log forcalling ioremap() on system RAM. ioremap on RAM at 0x0000000490000000 - 0x0000000490000fff WARNING: CPU: 2 PID: 416 at arch/x86/mm/ioremap.c:216 __ioremap_caller.constprop.0+0x131/0x35d Call Trace: memremap+0xcb/0x184 xlate_dev_mem_ptr+0x25/0x2f write_mem+0x94/0xfb vfs_write+0x128/0x26d ksys_write+0xac/0xfe do_syscall_64+0x9a/0xfd entry_SYSCALL_64_after_hwframe+0x4b/0x53The details of command execution process are as follows. In the aboveresource tree, System RAM is a descendant of CXL Window 0 instead of atop level resource. So, region_intersects() will report no System RAMresources in the CXL memory region incorrectly, because it only checks thetop level resources. Consequently, devmem_is_allowed() will return 1(allow access via /dev/mem) for CXL memory region incorrectly. Fortunately, ioremap() doesn t allow to map System RAM and reject theaccess.So, region_intersects() needs to be fixed to work correctly with theresource tree with System RAM not at top level as above. To fix it, ifwe found a unmatched resource in the top level, we will continue to searchmatched resources in its descendant resources. So, we will not miss anymatched resources in resource tree anymore.In the new implementation, an example resource tree|------------- CXL Window 0 ------------||-- System RAM --|will behave similar as the following fake resource tree forregion_intersects(, IORESOURCE_SYSTEM_RAM, ),|-- System RAM --||-- CXL Window 0a --|Where CXL Window 0a is part of the original CXL Window 0 thatisn t covered by System RAM .(CVE-2024-49878)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath10k: avoid NULL pointer error during sdio remove\n\nWhen running \u0026apos;rmmod ath10k\u0026apos;, ath10k_sdio_remove() will free sdio\nworkqueue by destroy_workqueue(). But if CONFIG_INIT_ON_FREE_DEFAULT_ON\nis set to yes, kernel panic will happen:\nCall trace:\n destroy_workqueue+0x1c/0x258\n ath10k_sdio_remove+0x84/0x94\n sdio_bus_remove+0x50/0x16c\n device_release_driver_internal+0x188/0x25c\n device_driver_detach+0x20/0x2c\n\nThis is because during \u0026apos;rmmod ath10k\u0026apos;, ath10k_sdio_remove() will call\nath10k_core_destroy() before destroy_workqueue(). wiphy_dev_release()\nwill finally be called in ath10k_core_destroy(). This function will free\nstruct cfg80211_registered_device *rdev and all its members, including\nwiphy, dev and the pointer of sdio workqueue. Then the pointer of sdio\nworkqueue will be set to NULL due to CONFIG_INIT_ON_FREE_DEFAULT_ON.\n\nAfter device release, destroy_workqueue() will use NULL pointer then the\nkernel panic happen.\n\nCall trace:\nath10k_sdio_remove\n -\u0026gt;ath10k_core_unregister\n \u2026\u2026\n -\u0026gt;ath10k_core_stop\n -\u0026gt;ath10k_hif_stop\n -\u0026gt;ath10k_sdio_irq_disable\n -\u0026gt;ath10k_hif_power_down\n -\u0026gt;del_timer_sync(\u0026amp;ar_sdio-\u0026gt;sleep_timer)\n -\u0026gt;ath10k_core_destroy\n -\u0026gt;ath10k_mac_destroy\n -\u0026gt;ieee80211_free_hw\n -\u0026gt;wiphy_free\n \u2026\u2026\n -\u0026gt;wiphy_dev_release\n -\u0026gt;destroy_workqueue\n\nNeed to call destroy_workqueue() before ath10k_core_destroy(), free\nthe work queue buffer first and then free pointer of work queue by\nath10k_core_destroy(). This order matches the error path order in\nath10k_sdio_probe().\n\nNo work will be queued on sdio workqueue between it is destroyed and\nath10k_core_destroy() is called. Based on the call_stack above, the\nreason is:\nOnly ath10k_sdio_sleep_timer_handler(), ath10k_sdio_hif_tx_sg() and\nath10k_sdio_irq_disable() will queue work on sdio workqueue.\nSleep timer will be deleted before ath10k_core_destroy() in\nath10k_hif_power_down().\nath10k_sdio_irq_disable() only be called in ath10k_hif_stop().\nath10k_core_unregister() will call ath10k_hif_power_down() to stop hif\nbus, so ath10k_sdio_hif_tx_sg() won\u0026apos;t be called anymore.\n\nTested-on: QCA6174 hw3.2 SDIO WLAN.RMH.4.4.1-00189(CVE-2024-56599)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: iwlwifi: limit printed string from FW file\n\nThere\u0026apos;s no guarantee here that the file is always with a\nNUL-termination, so reading the string may read beyond the\nend of the TLV. If that\u0026apos;s the last TLV in the file, it can\nperhaps even read beyond the end of the file buffer.\n\nFix that by limiting the print format to the size of the\nbuffer we have.(CVE-2025-21905)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nppp: Fix KMSAN uninit-value warning with bpf\n\nSyzbot caught an \u0026quot;KMSAN: uninit-value\u0026quot; warning [1], which is caused by the\nppp driver not initializing a 2-byte header when using socket filter.\n\nThe following code can generate a PPP filter BPF program:\n\u0026apos;\u0026apos;\u0026apos;\nstruct bpf_program fp;\npcap_t *handle;\nhandle = pcap_open_dead(DLT_PPP_PPPD, 65535);\npcap_compile(handle, \u0026amp;fp, \u0026quot;ip and outbound\u0026quot;, 0, 0);\nbpf_dump(\u0026amp;fp, 1);\n\u0026apos;\u0026apos;\u0026apos;\nIts output is:\n\u0026apos;\u0026apos;\u0026apos;\n(000) ldh [2]\n(001) jeq #0x21 jt 2 jf 5\n(002) ldb [0]\n(003) jeq #0x1 jt 4 jf 5\n(004) ret #65535\n(005) ret #0\n\u0026apos;\u0026apos;\u0026apos;\nWen can find similar code at the following link:\nhttps://github.com/ppp-project/ppp/blob/master/pppd/options.c#L1680\nThe maintainer of this code repository is also the original maintainer\nof the ppp driver.\n\nAs you can see the BPF program skips 2 bytes of data and then reads the\n\u0026apos;Protocol\u0026apos; field to determine if it\u0026apos;s an IP packet. Then it read the first\nbyte of the first 2 bytes to determine the direction.\n\nThe issue is that only the first byte indicating direction is initialized\nin current ppp driver code while the second byte is not initialized.\n\nFor normal BPF programs generated by libpcap, uninitialized data won\u0026apos;t be\nused, so it\u0026apos;s not a problem. However, for carefully crafted BPF programs,\nsuch as those generated by syzkaller [2], which start reading from offset\n0, the uninitialized data will be used and caught by KMSAN.\n\n[1] https://syzkaller.appspot.com/bug?extid=853242d9c9917165d791\n[2] https://syzkaller.appspot.com/text?tag=ReproC\u0026amp;x=11994913980000(CVE-2025-21922)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: venus: hfi: add check to handle incorrect queue size\n\nqsize represents size of shared queued between driver and video\nfirmware. Firmware can modify this value to an invalid large value. In\nsuch situation, empty_space will be bigger than the space actually\navailable. Since new_wr_idx is not checked, so the following code will\nresult in an OOB write.\n...\nqsize = qhdr-\u0026gt;q_size\n\nif (wr_idx \u0026gt;= rd_idx)\n empty_space = qsize - (wr_idx - rd_idx)\n....\nif (new_wr_idx \u0026lt; qsize) {\n memcpy(wr_ptr, packet, dwords \u0026lt;\u0026lt; 2) --\u0026gt; OOB write\n\nAdd check to ensure qsize is within the allocated size while\nreading and writing packets into the queue.(CVE-2025-23158)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: mediatek: vcodec: Fix a resource leak related to the scp device in FW initialization\n\nOn Mediatek devices with a system companion processor (SCP) the mtk_scp\nstructure has to be removed explicitly to avoid a resource leak.\nFree the structure in case the allocation of the firmware structure fails\nduring the firmware initialization.(CVE-2025-23160)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: tls: explicitly disallow disconnect\n\nsyzbot discovered that it can disconnect a TLS socket and then\nrun into all sort of unexpected corner cases. I have a vague\nrecollection of Eric pointing this out to us a long time ago.\nSupporting disconnect is really hard, for one thing if offload\nis enabled we\u0026apos;d need to wait for all packets to be _acked_.\nDisconnect is not commonly used, disallow it.\n\nThe immediate problem syzbot run into is the warning in the strp,\nbut that\u0026apos;s just the easiest bug to trigger:\n\n WARNING: CPU: 0 PID: 5834 at net/tls/tls_strp.c:486 tls_strp_msg_load+0x72e/0xa80 net/tls/tls_strp.c:486\n RIP: 0010:tls_strp_msg_load+0x72e/0xa80 net/tls/tls_strp.c:486\n Call Trace:\n \u0026lt;TASK\u0026gt;\n tls_rx_rec_wait+0x280/0xa60 net/tls/tls_sw.c:1363\n tls_sw_recvmsg+0x85c/0x1c30 net/tls/tls_sw.c:2043\n inet6_recvmsg+0x2c9/0x730 net/ipv6/af_inet6.c:678\n sock_recvmsg_nosec net/socket.c:1023 [inline]\n sock_recvmsg+0x109/0x280 net/socket.c:1045\n __sys_recvfrom+0x202/0x380 net/socket.c:2237(CVE-2025-37756)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix the warning from __kernel_write_iter\n\n[ 2110.972290] ------------[ cut here ]------------\n[ 2110.972301] WARNING: CPU: 3 PID: 735 at fs/read_write.c:599 __kernel_write_iter+0x21b/0x280\n\nThis patch doesn\u0026apos;t allow writing to directory.(CVE-2025-37775)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix use-after-free in smb_break_all_levII_oplock()\n\nThere is a room in smb_break_all_levII_oplock that can cause racy issues\nwhen unlocking in the middle of the loop. This patch use read lock\nto protect whole loop.(CVE-2025-37776)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npwm: mediatek: Prevent divide-by-zero in pwm_mediatek_config()\n\nWith CONFIG_COMPILE_TEST \u0026amp;\u0026amp; !CONFIG_HAVE_CLK, pwm_mediatek_config() has a\ndivide-by-zero in the following line:\n\n\tdo_div(resolution, clk_get_rate(pc-\u0026gt;clk_pwms[pwm-\u0026gt;hwpwm]));\n\ndue to the fact that the !CONFIG_HAVE_CLK version of clk_get_rate()\nreturns zero.\n\nThis is presumably just a theoretical problem: COMPILE_TEST overrides\nthe dependency on RALINK which would select COMMON_CLK. Regardless it\u0026apos;s\na good idea to check for the error explicitly to avoid divide-by-zero.\n\nFixes the following warning:\n\n drivers/pwm/pwm-mediatek.o: warning: objtool: .text: unexpected end of section\n\n[ukleinek: s/CONFIG_CLK/CONFIG_HAVE_CLK/](CVE-2025-37850)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niommu/amd: Fix potential buffer overflow in parse_ivrs_acpihid\n\nThere is a string parsing logic error which can lead to an overflow of hid\nor uid buffers. Comparing ACPIID_LEN against a total string length doesn\u0026apos;t\ntake into account the lengths of individual hid and uid buffers so the\ncheck is insufficient in some cases. For example if the length of hid\nstring is 4 and the length of the uid string is 260, the length of str\nwill be equal to ACPIID_LEN + 1 but uid string will overflow uid buffer\nwhich size is 256.\n\nThe same applies to the hid string with length 13 and uid string with\nlength 250.\n\nCheck the length of hid and uid strings separately to prevent\nbuffer overflow.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-37927)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nx86/sev: Evict cache lines during SNP memory validation\n\nAn SNP cache coherency vulnerability requires a cache line eviction\nmitigation when validating memory after a page state change to private.\nThe specific mitigation is to touch the first and last byte of each 4K\npage that is being validated. There is no need to perform the mitigation\nwhen performing a page state change to shared and rescinding validation.\n\nCPUID bit Fn8000001F_EBX[31] defines the COHERENCY_SFW_NO CPUID bit\nthat, when set, indicates that the software mitigation for this\nvulnerability is not needed.\n\nImplement the mitigation and invoke it when validating memory (making it\nprivate) and the COHERENCY_SFW_NO bit is not set, indicating the SNP\nguest is vulnerable.(CVE-2025-38560)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni40e: remove read access to debugfs files\n\nThe \u0026apos;command\u0026apos; and \u0026apos;netdev_ops\u0026apos; debugfs files are a legacy debugging\ninterface supported by the i40e driver since its early days by commit\n02e9c290814c (\u0026quot;i40e: debugfs interface\u0026quot;).\n\nBoth of these debugfs files provide a read handler which is mostly useless,\nand which is implemented with questionable logic. They both use a static\n256 byte buffer which is initialized to the empty string. In the case of\nthe \u0026apos;command\u0026apos; file this buffer is literally never used and simply wastes\nspace. In the case of the \u0026apos;netdev_ops\u0026apos; file, the last command written is\nsaved here.\n\nOn read, the files contents are presented as the name of the device\nfollowed by a colon and then the contents of their respective static\nbuffer. For \u0026apos;command\u0026apos; this will always be \u0026quot;\u0026lt;device\u0026gt;: \u0026quot;. For \u0026apos;netdev_ops\u0026apos;,\nthis will be \u0026quot;\u0026lt;device\u0026gt;: \u0026lt;last command written\u0026gt;\u0026quot;. But note the buffer is\nshared between all devices operated by this module. At best, it is mostly\nmeaningless information, and at worse it could be accessed simultaneously\nas there doesn\u0026apos;t appear to be any locking mechanism.\n\nWe have also recently received multiple reports for both read functions\nabout their use of snprintf and potential overflow that could result in\nreading arbitrary kernel memory. For the \u0026apos;command\u0026apos; file, this is definitely\nimpossible, since the static buffer is always zero and never written to.\nFor the \u0026apos;netdev_ops\u0026apos; file, it does appear to be possible, if the user\ncarefully crafts the command input, it will be copied into the buffer,\nwhich could be large enough to cause snprintf to truncate, which then\ncauses the copy_to_user to read beyond the length of the buffer allocated\nby kzalloc.\n\nA minimal fix would be to replace snprintf() with scnprintf() which would\ncap the return to the number of bytes written, preventing an overflow. A\nmore involved fix would be to drop the mostly useless static buffers,\nsaving 512 bytes and modifying the read functions to stop needing those as\ninput.\n\nInstead, lets just completely drop the read access to these files. These\nare debug interfaces exposed as part of debugfs, and I don\u0026apos;t believe that\ndropping read access will break any script, as the provided output is\npretty useless. You can find the netdev name through other more standard\ninterfaces, and the \u0026apos;netdev_ops\u0026apos; interface can easily result in garbage if\nyou issue simultaneous writes to multiple devices at once.\n\nIn order to properly remove the i40e_dbg_netdev_ops_buf, we need to\nrefactor its write function to avoid using the static buffer. Instead, use\nthe same logic as the i40e_dbg_command_write, with an allocated buffer.\nUpdate the code to use this instead of the static buffer, and ensure we\nfree the buffer on exit. This fixes simultaneous writes to \u0026apos;netdev_ops\u0026apos; on\nmultiple devices, and allows us to remove the now unused static buffer\nalong with removing the read access.(CVE-2025-39901)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: smbdirect: verify remaining_data_length respects max_fragmented_recv_size\n\nThis is inspired by the check for data_offset + data_length.(CVE-2025-39942)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/ksm: fix flag-dropping behavior in ksm_madvise\n\nsyzkaller discovered the following crash: (kernel BUG)\n\n[ 44.607039] ------------[ cut here ]------------\n[ 44.607422] kernel BUG at mm/userfaultfd.c:2067!\n[ 44.608148] Oops: invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI\n[ 44.608814] CPU: 1 UID: 0 PID: 2475 Comm: reproducer Not tainted 6.16.0-rc6 #1 PREEMPT(none)\n[ 44.609635] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014\n[ 44.610695] RIP: 0010:userfaultfd_release_all+0x3a8/0x460\n\n\u0026lt;snip other registers, drop unreliable trace\u0026gt;\n\n[ 44.617726] Call Trace:\n[ 44.617926] \u0026lt;TASK\u0026gt;\n[ 44.619284] userfaultfd_release+0xef/0x1b0\n[ 44.620976] __fput+0x3f9/0xb60\n[ 44.621240] fput_close_sync+0x110/0x210\n[ 44.622222] __x64_sys_close+0x8f/0x120\n[ 44.622530] do_syscall_64+0x5b/0x2f0\n[ 44.622840] entry_SYSCALL_64_after_hwframe+0x76/0x7e\n[ 44.623244] RIP: 0033:0x7f365bb3f227\n\nKernel panics because it detects UFFD inconsistency during\nuserfaultfd_release_all(). Specifically, a VMA which has a valid pointer\nto vma-\u0026gt;vm_userfaultfd_ctx, but no UFFD flags in vma-\u0026gt;vm_flags.\n\nThe inconsistency is caused in ksm_madvise(): when user calls madvise()\nwith MADV_UNMEARGEABLE on a VMA that is registered for UFFD in MINOR mode,\nit accidentally clears all flags stored in the upper 32 bits of\nvma-\u0026gt;vm_flags.\n\nAssuming x86_64 kernel build, unsigned long is 64-bit and unsigned int and\nint are 32-bit wide. This setup causes the following mishap during the \u0026amp;=\n~VM_MERGEABLE assignment.\n\nVM_MERGEABLE is a 32-bit constant of type unsigned int, 0x8000\u0026apos;0000. \nAfter ~ is applied, it becomes 0x7fff\u0026apos;ffff unsigned int, which is then\npromoted to unsigned long before the \u0026amp; operation. This promotion fills\nupper 32 bits with leading 0s, as we\u0026apos;re doing unsigned conversion (and\neven for a signed conversion, this wouldn\u0026apos;t help as the leading bit is 0).\n\u0026amp; operation thus ends up AND-ing vm_flags with 0x0000\u0026apos;0000\u0026apos;7fff\u0026apos;ffff\ninstead of intended 0xffff\u0026apos;ffff\u0026apos;7fff\u0026apos;ffff and hence accidentally clears\nthe upper 32-bits of its value.\n\nFix it by changing `VM_MERGEABLE` constant to unsigned long, using the\nBIT() macro.\n\nNote: other VM_* flags are not affected: This only happens to the\nVM_MERGEABLE flag, as the other VM_* flags are all constants of type int\nand after ~ operation, they end up with leading 1 and are thus converted\nto unsigned long with leading 1s.\n\nNote 2:\nAfter commit 31defc3b01d9 (\u0026quot;userfaultfd: remove (VM_)BUG_ON()s\u0026quot;), this is\nno longer a kernel BUG, but a WARNING at the same place:\n\n[ 45.595973] WARNING: CPU: 1 PID: 2474 at mm/userfaultfd.c:2067\n\nbut the root-cause (flag-drop) remains the same.\n\n[(CVE-2025-40040)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: use dst_dev_rcu() in sk_setup_caps()\n\nUse RCU to protect accesses to dst-\u0026gt;dev from sk_setup_caps()\nand sk_dst_gso_max_size().\n\nAlso use dst_dev_rcu() in ip6_dst_mtu_maybe_forward(),\nand ip_dst_mtu_maybe_forward().\n\nip4_dst_hoplimit() can use dst_dev_net_rcu().(CVE-2025-40170)",
"id": "OESA-2025-2882",
"modified": "2026-08-06T11:10:00Z",
"published": "2025-12-30T11:10:00Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2882"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42154"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49878"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56599"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21905"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21922"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23158"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23160"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37756"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37775"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37776"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37850"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37927"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38560"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39901"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39942"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40040"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40170"
}
],
"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-2024-42154",
"CVE-2024-49878",
"CVE-2024-56599",
"CVE-2025-21905",
"CVE-2025-21922",
"CVE-2025-23158",
"CVE-2025-23160",
"CVE-2025-37756",
"CVE-2025-37775",
"CVE-2025-37776",
"CVE-2025-37850",
"CVE-2025-37927",
"CVE-2025-38560",
"CVE-2025-39901",
"CVE-2025-39942",
"CVE-2025-40040",
"CVE-2025-40170"
]
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.