Action not permitted
Modal body text goes here.
Modal Title
Modal Body
CVE-2024-49959 (GCVE-0-2024-49959)
Vulnerability from cvelistv5 – Published: 2024-10-21 18:02 – Updated: 2026-05-11 20:42| Vendor | Product | Version | CPE status | |
|---|---|---|---|---|
| Linux | Linux |
Affected:
8c3f25d8950c3e9fe6c9849f88679b3f2a071550 , < 801a35dfef6996f3d5eaa96a59caf00440d9165e
(git)
Affected: 8c3f25d8950c3e9fe6c9849f88679b3f2a071550 , < d5dc65370a746750dbb2f03eabcf86b18db65f32 (git) Affected: 8c3f25d8950c3e9fe6c9849f88679b3f2a071550 , < 481e8f18a290e39e04ddb7feb2bb2a2cc3b213ed (git) Affected: 8c3f25d8950c3e9fe6c9849f88679b3f2a071550 , < ec7f8337c98ad281020ad1f11ba492462d80737a (git) Affected: 8c3f25d8950c3e9fe6c9849f88679b3f2a071550 , < 70bae48377a2c4296fd3caf4caf8f11079111019 (git) Affected: 8c3f25d8950c3e9fe6c9849f88679b3f2a071550 , < 1c62dc0d82c62f0dc8fcdc4843208e522acccaf5 (git) Affected: 8c3f25d8950c3e9fe6c9849f88679b3f2a071550 , < 3ced0fe6c0eff032733ea8b38778b34707270138 (git) Affected: 8c3f25d8950c3e9fe6c9849f88679b3f2a071550 , < c6bf043b210eac67d35a114e345c4e5585672913 (git) Affected: 8c3f25d8950c3e9fe6c9849f88679b3f2a071550 , < f5cacdc6f2bb2a9bf214469dd7112b43dd2dd68a (git) |
guessed | |
| Linux | Linux |
Affected:
2.6.28
Unaffected: 0 , < 2.6.28 (semver) Unaffected: 4.19.323 , ≤ 4.19.* (semver) Unaffected: 5.4.285 , ≤ 5.4.* (semver) Unaffected: 5.10.227 , ≤ 5.10.* (semver) Unaffected: 5.15.168 , ≤ 5.15.* (semver) Unaffected: 6.1.113 , ≤ 6.1.* (semver) Unaffected: 6.6.55 , ≤ 6.6.* (semver) Unaffected: 6.10.14 , ≤ 6.10.* (semver) Unaffected: 6.11.3 , ≤ 6.11.* (semver) Unaffected: 6.12 , ≤ * (original_commit_for_fix) |
guessed |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2024-49959",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2024-10-22T13:35:21.788104Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2024-10-22T13:38:47.931Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
},
{
"providerMetadata": {
"dateUpdated": "2025-11-03T22:23:39.640Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html"
},
{
"url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
}
],
"title": "CVE Program Container"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"fs/jbd2/checkpoint.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "801a35dfef6996f3d5eaa96a59caf00440d9165e",
"status": "affected",
"version": "8c3f25d8950c3e9fe6c9849f88679b3f2a071550",
"versionType": "git"
},
{
"lessThan": "d5dc65370a746750dbb2f03eabcf86b18db65f32",
"status": "affected",
"version": "8c3f25d8950c3e9fe6c9849f88679b3f2a071550",
"versionType": "git"
},
{
"lessThan": "481e8f18a290e39e04ddb7feb2bb2a2cc3b213ed",
"status": "affected",
"version": "8c3f25d8950c3e9fe6c9849f88679b3f2a071550",
"versionType": "git"
},
{
"lessThan": "ec7f8337c98ad281020ad1f11ba492462d80737a",
"status": "affected",
"version": "8c3f25d8950c3e9fe6c9849f88679b3f2a071550",
"versionType": "git"
},
{
"lessThan": "70bae48377a2c4296fd3caf4caf8f11079111019",
"status": "affected",
"version": "8c3f25d8950c3e9fe6c9849f88679b3f2a071550",
"versionType": "git"
},
{
"lessThan": "1c62dc0d82c62f0dc8fcdc4843208e522acccaf5",
"status": "affected",
"version": "8c3f25d8950c3e9fe6c9849f88679b3f2a071550",
"versionType": "git"
},
{
"lessThan": "3ced0fe6c0eff032733ea8b38778b34707270138",
"status": "affected",
"version": "8c3f25d8950c3e9fe6c9849f88679b3f2a071550",
"versionType": "git"
},
{
"lessThan": "c6bf043b210eac67d35a114e345c4e5585672913",
"status": "affected",
"version": "8c3f25d8950c3e9fe6c9849f88679b3f2a071550",
"versionType": "git"
},
{
"lessThan": "f5cacdc6f2bb2a9bf214469dd7112b43dd2dd68a",
"status": "affected",
"version": "8c3f25d8950c3e9fe6c9849f88679b3f2a071550",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"fs/jbd2/checkpoint.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "2.6.28"
},
{
"lessThan": "2.6.28",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "4.19.*",
"status": "unaffected",
"version": "4.19.323",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.285",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.227",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.168",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.113",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.55",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.10.*",
"status": "unaffected",
"version": "6.10.14",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.11.*",
"status": "unaffected",
"version": "6.11.3",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.12",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "4.19.323",
"versionStartIncluding": "2.6.28",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.4.285",
"versionStartIncluding": "2.6.28",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.10.227",
"versionStartIncluding": "2.6.28",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.15.168",
"versionStartIncluding": "2.6.28",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.1.113",
"versionStartIncluding": "2.6.28",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6.55",
"versionStartIncluding": "2.6.28",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.10.14",
"versionStartIncluding": "2.6.28",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.11.3",
"versionStartIncluding": "2.6.28",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.12",
"versionStartIncluding": "2.6.28",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\njbd2: stop waiting for space when jbd2_cleanup_journal_tail() returns error\n\nIn __jbd2_log_wait_for_space(), we might call jbd2_cleanup_journal_tail()\nto recover some journal space. But if an error occurs while executing\njbd2_cleanup_journal_tail() (e.g., an EIO), we don\u0027t stop waiting for free\nspace right away, we try other branches, and if j_committing_transaction\nis NULL (i.e., the tid is 0), we will get the following complain:\n\n============================================\nJBD2: I/O error when updating journal superblock for sdd-8.\n__jbd2_log_wait_for_space: needed 256 blocks and only had 217 space available\n__jbd2_log_wait_for_space: no way to get more journal space in sdd-8\n------------[ cut here ]------------\nWARNING: CPU: 2 PID: 139804 at fs/jbd2/checkpoint.c:109 __jbd2_log_wait_for_space+0x251/0x2e0\nModules linked in:\nCPU: 2 PID: 139804 Comm: kworker/u8:3 Not tainted 6.6.0+ #1\nRIP: 0010:__jbd2_log_wait_for_space+0x251/0x2e0\nCall Trace:\n \u003cTASK\u003e\n add_transaction_credits+0x5d1/0x5e0\n start_this_handle+0x1ef/0x6a0\n jbd2__journal_start+0x18b/0x340\n ext4_dirty_inode+0x5d/0xb0\n __mark_inode_dirty+0xe4/0x5d0\n generic_update_time+0x60/0x70\n[...]\n============================================\n\nSo only if jbd2_cleanup_journal_tail() returns 1, i.e., there is nothing to\nclean up at the moment, continue to try to reclaim free space in other ways.\n\nNote that this fix relies on commit 6f6a6fda2945 (\"jbd2: fix ocfs2 corrupt\nwhen updating journal superblock fails\") to make jbd2_cleanup_journal_tail\nreturn the correct error code."
}
],
"providerMetadata": {
"dateUpdated": "2026-05-11T20:42:51.196Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/801a35dfef6996f3d5eaa96a59caf00440d9165e"
},
{
"url": "https://git.kernel.org/stable/c/d5dc65370a746750dbb2f03eabcf86b18db65f32"
},
{
"url": "https://git.kernel.org/stable/c/481e8f18a290e39e04ddb7feb2bb2a2cc3b213ed"
},
{
"url": "https://git.kernel.org/stable/c/ec7f8337c98ad281020ad1f11ba492462d80737a"
},
{
"url": "https://git.kernel.org/stable/c/70bae48377a2c4296fd3caf4caf8f11079111019"
},
{
"url": "https://git.kernel.org/stable/c/1c62dc0d82c62f0dc8fcdc4843208e522acccaf5"
},
{
"url": "https://git.kernel.org/stable/c/3ced0fe6c0eff032733ea8b38778b34707270138"
},
{
"url": "https://git.kernel.org/stable/c/c6bf043b210eac67d35a114e345c4e5585672913"
},
{
"url": "https://git.kernel.org/stable/c/f5cacdc6f2bb2a9bf214469dd7112b43dd2dd68a"
}
],
"title": "jbd2: stop waiting for space when jbd2_cleanup_journal_tail() returns error",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2024-49959",
"datePublished": "2024-10-21T18:02:12.355Z",
"dateReserved": "2024-10-21T12:17:06.049Z",
"dateUpdated": "2026-05-11T20:42:51.196Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"epss": {
"cve": "CVE-2024-49959",
"date": "2026-10-10",
"epss": "0.00257",
"percentile": "0.16035"
},
"microsoft_vex": {
"current_release_date": "2026-02-21T00:55:09.000Z",
"cve": "CVE-2024-49959",
"id": "msrc_CVE-2024-49959",
"initial_release_date": "2024-10-01T07:00:00.000Z",
"product_status:fixed": "5",
"product_status:known_affected": "5",
"source": "Microsoft CSAF VEX",
"status": "final",
"title": "jbd2: stop waiting for space when jbd2_cleanup_journal_tail() returns error",
"url": "https://msrc.microsoft.com/csaf/vex/2024/msrc_cve-2024-49959.json",
"version": "3"
},
"nvd": {
"cve": {
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"fs/jbd2/checkpoint.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "801a35dfef6996f3d5eaa96a59caf00440d9165e",
"status": "affected",
"version": "8c3f25d8950c3e9fe6c9849f88679b3f2a071550",
"versionType": "git"
},
{
"lessThan": "d5dc65370a746750dbb2f03eabcf86b18db65f32",
"status": "affected",
"version": "8c3f25d8950c3e9fe6c9849f88679b3f2a071550",
"versionType": "git"
},
{
"lessThan": "481e8f18a290e39e04ddb7feb2bb2a2cc3b213ed",
"status": "affected",
"version": "8c3f25d8950c3e9fe6c9849f88679b3f2a071550",
"versionType": "git"
},
{
"lessThan": "ec7f8337c98ad281020ad1f11ba492462d80737a",
"status": "affected",
"version": "8c3f25d8950c3e9fe6c9849f88679b3f2a071550",
"versionType": "git"
},
{
"lessThan": "70bae48377a2c4296fd3caf4caf8f11079111019",
"status": "affected",
"version": "8c3f25d8950c3e9fe6c9849f88679b3f2a071550",
"versionType": "git"
},
{
"lessThan": "1c62dc0d82c62f0dc8fcdc4843208e522acccaf5",
"status": "affected",
"version": "8c3f25d8950c3e9fe6c9849f88679b3f2a071550",
"versionType": "git"
},
{
"lessThan": "3ced0fe6c0eff032733ea8b38778b34707270138",
"status": "affected",
"version": "8c3f25d8950c3e9fe6c9849f88679b3f2a071550",
"versionType": "git"
},
{
"lessThan": "c6bf043b210eac67d35a114e345c4e5585672913",
"status": "affected",
"version": "8c3f25d8950c3e9fe6c9849f88679b3f2a071550",
"versionType": "git"
},
{
"lessThan": "f5cacdc6f2bb2a9bf214469dd7112b43dd2dd68a",
"status": "affected",
"version": "8c3f25d8950c3e9fe6c9849f88679b3f2a071550",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"fs/jbd2/checkpoint.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "2.6.28"
},
{
"lessThan": "2.6.28",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "4.19.*",
"status": "unaffected",
"version": "4.19.323",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.285",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.227",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.168",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.113",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.55",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.10.*",
"status": "unaffected",
"version": "6.10.14",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.11.*",
"status": "unaffected",
"version": "6.11.3",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.12",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"configurations": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "1ECF4EB9-CCE6-413E-9A66-D01E03C462EF",
"versionEndExcluding": "5.10.227",
"versionStartIncluding": "2.6.28",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "4D51C05D-455B-4D8D-89E7-A58E140B864C",
"versionEndExcluding": "5.15.168",
"versionStartIncluding": "5.11",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "D01BD22E-ACD1-4618-9D01-6116570BE1EE",
"versionEndExcluding": "6.1.113",
"versionStartIncluding": "5.16",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "E90B9576-56C4-47BC-AAB0-C5B2D438F5D0",
"versionEndExcluding": "6.6.55",
"versionStartIncluding": "6.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "4C16BCE0-FFA0-4599-BE0A-1FD65101C021",
"versionEndExcluding": "6.10.14",
"versionStartIncluding": "6.7",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "54D9C704-D679-41A7-9C40-10A6B1E7FFE9",
"versionEndExcluding": "6.11.3",
"versionStartIncluding": "6.11",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\njbd2: stop waiting for space when jbd2_cleanup_journal_tail() returns error\n\nIn __jbd2_log_wait_for_space(), we might call jbd2_cleanup_journal_tail()\nto recover some journal space. But if an error occurs while executing\njbd2_cleanup_journal_tail() (e.g., an EIO), we don\u0027t stop waiting for free\nspace right away, we try other branches, and if j_committing_transaction\nis NULL (i.e., the tid is 0), we will get the following complain:\n\n============================================\nJBD2: I/O error when updating journal superblock for sdd-8.\n__jbd2_log_wait_for_space: needed 256 blocks and only had 217 space available\n__jbd2_log_wait_for_space: no way to get more journal space in sdd-8\n------------[ cut here ]------------\nWARNING: CPU: 2 PID: 139804 at fs/jbd2/checkpoint.c:109 __jbd2_log_wait_for_space+0x251/0x2e0\nModules linked in:\nCPU: 2 PID: 139804 Comm: kworker/u8:3 Not tainted 6.6.0+ #1\nRIP: 0010:__jbd2_log_wait_for_space+0x251/0x2e0\nCall Trace:\n \u003cTASK\u003e\n add_transaction_credits+0x5d1/0x5e0\n start_this_handle+0x1ef/0x6a0\n jbd2__journal_start+0x18b/0x340\n ext4_dirty_inode+0x5d/0xb0\n __mark_inode_dirty+0xe4/0x5d0\n generic_update_time+0x60/0x70\n[...]\n============================================\n\nSo only if jbd2_cleanup_journal_tail() returns 1, i.e., there is nothing to\nclean up at the moment, continue to try to reclaim free space in other ways.\n\nNote that this fix relies on commit 6f6a6fda2945 (\"jbd2: fix ocfs2 corrupt\nwhen updating journal superblock fails\") to make jbd2_cleanup_journal_tail\nreturn the correct error code."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: jbd2: dejad de esperar espacio cuando jbd2_cleanup_journal_tail() devuelve un error En __jbd2_log_wait_for_space(), podr\u00edamos llamar a jbd2_cleanup_journal_tail() para recuperar algo de espacio en el diario. Pero si ocurre un error mientras se ejecuta jbd2_cleanup_journal_tail() (por ejemplo, un EIO), no dejamos de esperar espacio libre de inmediato, probamos otras ramas y, si j_committing_transaction es NULL (es decir, el tid es 0), obtendremos la siguiente queja: =============================================== JBD2: Error de E/S al actualizar el superbloque del diario para sdd-8. __jbd2_log_wait_for_space: se necesitaban 256 bloques y solo hab\u00eda 217 de espacio disponible __jbd2_log_wait_for_space: no hay forma de obtener m\u00e1s espacio de diario en sdd-8 ------------[ cortar aqu\u00ed ]------------ ADVERTENCIA: CPU: 2 PID: 139804 en fs/jbd2/checkpoint.c:109 __jbd2_log_wait_for_space+0x251/0x2e0 M\u00f3dulos vinculados: CPU: 2 PID: 139804 Comm: kworker/u8:3 No contaminado 6.6.0+ #1 RIP: 0010:__jbd2_log_wait_for_space+0x251/0x2e0 Rastreo de llamadas: add_transaction_credits+0x5d1/0x5e0 start_this_handle+0x1ef/0x6a0 jbd2__journal_start+0x18b/0x340 ext4_dirty_inode+0x5d/0xb0 __mark_inode_dirty+0xe4/0x5d0 generic_update_time+0x60/0x70 [...] == ..."
}
],
"id": "CVE-2024-49959",
"lastModified": "2026-06-17T08:00:49.560",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 5.5,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 3.6,
"source": "nvd@nist.gov",
"type": "Primary"
}
],
"ssvcV203": [
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"ssvcData": {
"id": "CVE-2024-49959",
"options": [
{
"exploitation": "none"
},
{
"automatable": "no"
},
{
"technicalImpact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2024-10-22T13:35:21.788104Z",
"version": "2.0.3"
}
}
]
},
"published": "2024-10-21T18:15:17.123",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/1c62dc0d82c62f0dc8fcdc4843208e522acccaf5"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/3ced0fe6c0eff032733ea8b38778b34707270138"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/481e8f18a290e39e04ddb7feb2bb2a2cc3b213ed"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/70bae48377a2c4296fd3caf4caf8f11079111019"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/801a35dfef6996f3d5eaa96a59caf00440d9165e"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/c6bf043b210eac67d35a114e345c4e5585672913"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/d5dc65370a746750dbb2f03eabcf86b18db65f32"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/ec7f8337c98ad281020ad1f11ba492462d80737a"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/f5cacdc6f2bb2a9bf214469dd7112b43dd2dd68a"
},
{
"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://lists.debian.org/debian-lts-announce/2025/03/msg00002.html"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Modified",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "NVD-CWE-noinfo"
}
],
"source": "nvd@nist.gov",
"type": "Primary"
}
]
}
},
"redhat_vex": {
"aggregate_severity": "Moderate",
"current_release_date": "2026-09-13T15:30:50+00:00",
"cve": "CVE-2024-49959",
"id": "CVE-2024-49959",
"initial_release_date": "2024-10-21T00:00:00+00:00",
"product_status:fixed": "305",
"product_status:known_affected": "112",
"source": "Red Hat CSAF VEX",
"status": "final",
"title": "kernel: jbd2: stop waiting for space when jbd2_cleanup_journal_tail() returns error",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2024/cve-2024-49959.json",
"version": "3"
},
"vulnrichment": {
"containers": {
"adp": [
{
"providerMetadata": {
"dateUpdated": "2025-11-03T22:23:39.640Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html"
},
{
"url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
}
],
"title": "CVE Program Container"
},
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2024-49959",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2024-10-22T13:35:21.788104Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2024-10-22T13:35:24.984Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"fs/jbd2/checkpoint.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "801a35dfef6996f3d5eaa96a59caf00440d9165e",
"status": "affected",
"version": "8c3f25d8950c3e9fe6c9849f88679b3f2a071550",
"versionType": "git"
},
{
"lessThan": "d5dc65370a746750dbb2f03eabcf86b18db65f32",
"status": "affected",
"version": "8c3f25d8950c3e9fe6c9849f88679b3f2a071550",
"versionType": "git"
},
{
"lessThan": "481e8f18a290e39e04ddb7feb2bb2a2cc3b213ed",
"status": "affected",
"version": "8c3f25d8950c3e9fe6c9849f88679b3f2a071550",
"versionType": "git"
},
{
"lessThan": "ec7f8337c98ad281020ad1f11ba492462d80737a",
"status": "affected",
"version": "8c3f25d8950c3e9fe6c9849f88679b3f2a071550",
"versionType": "git"
},
{
"lessThan": "70bae48377a2c4296fd3caf4caf8f11079111019",
"status": "affected",
"version": "8c3f25d8950c3e9fe6c9849f88679b3f2a071550",
"versionType": "git"
},
{
"lessThan": "1c62dc0d82c62f0dc8fcdc4843208e522acccaf5",
"status": "affected",
"version": "8c3f25d8950c3e9fe6c9849f88679b3f2a071550",
"versionType": "git"
},
{
"lessThan": "3ced0fe6c0eff032733ea8b38778b34707270138",
"status": "affected",
"version": "8c3f25d8950c3e9fe6c9849f88679b3f2a071550",
"versionType": "git"
},
{
"lessThan": "c6bf043b210eac67d35a114e345c4e5585672913",
"status": "affected",
"version": "8c3f25d8950c3e9fe6c9849f88679b3f2a071550",
"versionType": "git"
},
{
"lessThan": "f5cacdc6f2bb2a9bf214469dd7112b43dd2dd68a",
"status": "affected",
"version": "8c3f25d8950c3e9fe6c9849f88679b3f2a071550",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"fs/jbd2/checkpoint.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "2.6.28"
},
{
"lessThan": "2.6.28",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "4.19.*",
"status": "unaffected",
"version": "4.19.323",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.285",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.227",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.168",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.113",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.55",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.10.*",
"status": "unaffected",
"version": "6.10.14",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.11.*",
"status": "unaffected",
"version": "6.11.3",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.12",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "4.19.323",
"versionStartIncluding": "2.6.28",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.4.285",
"versionStartIncluding": "2.6.28",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.10.227",
"versionStartIncluding": "2.6.28",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.15.168",
"versionStartIncluding": "2.6.28",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.1.113",
"versionStartIncluding": "2.6.28",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6.55",
"versionStartIncluding": "2.6.28",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.10.14",
"versionStartIncluding": "2.6.28",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.11.3",
"versionStartIncluding": "2.6.28",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.12",
"versionStartIncluding": "2.6.28",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\njbd2: stop waiting for space when jbd2_cleanup_journal_tail() returns error\n\nIn __jbd2_log_wait_for_space(), we might call jbd2_cleanup_journal_tail()\nto recover some journal space. But if an error occurs while executing\njbd2_cleanup_journal_tail() (e.g., an EIO), we don\u0027t stop waiting for free\nspace right away, we try other branches, and if j_committing_transaction\nis NULL (i.e., the tid is 0), we will get the following complain:\n\n============================================\nJBD2: I/O error when updating journal superblock for sdd-8.\n__jbd2_log_wait_for_space: needed 256 blocks and only had 217 space available\n__jbd2_log_wait_for_space: no way to get more journal space in sdd-8\n------------[ cut here ]------------\nWARNING: CPU: 2 PID: 139804 at fs/jbd2/checkpoint.c:109 __jbd2_log_wait_for_space+0x251/0x2e0\nModules linked in:\nCPU: 2 PID: 139804 Comm: kworker/u8:3 Not tainted 6.6.0+ #1\nRIP: 0010:__jbd2_log_wait_for_space+0x251/0x2e0\nCall Trace:\n \u003cTASK\u003e\n add_transaction_credits+0x5d1/0x5e0\n start_this_handle+0x1ef/0x6a0\n jbd2__journal_start+0x18b/0x340\n ext4_dirty_inode+0x5d/0xb0\n __mark_inode_dirty+0xe4/0x5d0\n generic_update_time+0x60/0x70\n[...]\n============================================\n\nSo only if jbd2_cleanup_journal_tail() returns 1, i.e., there is nothing to\nclean up at the moment, continue to try to reclaim free space in other ways.\n\nNote that this fix relies on commit 6f6a6fda2945 (\"jbd2: fix ocfs2 corrupt\nwhen updating journal superblock fails\") to make jbd2_cleanup_journal_tail\nreturn the correct error code."
}
],
"providerMetadata": {
"dateUpdated": "2025-05-04T09:42:22.577Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/801a35dfef6996f3d5eaa96a59caf00440d9165e"
},
{
"url": "https://git.kernel.org/stable/c/d5dc65370a746750dbb2f03eabcf86b18db65f32"
},
{
"url": "https://git.kernel.org/stable/c/481e8f18a290e39e04ddb7feb2bb2a2cc3b213ed"
},
{
"url": "https://git.kernel.org/stable/c/ec7f8337c98ad281020ad1f11ba492462d80737a"
},
{
"url": "https://git.kernel.org/stable/c/70bae48377a2c4296fd3caf4caf8f11079111019"
},
{
"url": "https://git.kernel.org/stable/c/1c62dc0d82c62f0dc8fcdc4843208e522acccaf5"
},
{
"url": "https://git.kernel.org/stable/c/3ced0fe6c0eff032733ea8b38778b34707270138"
},
{
"url": "https://git.kernel.org/stable/c/c6bf043b210eac67d35a114e345c4e5585672913"
},
{
"url": "https://git.kernel.org/stable/c/f5cacdc6f2bb2a9bf214469dd7112b43dd2dd68a"
}
],
"title": "jbd2: stop waiting for space when jbd2_cleanup_journal_tail() returns error",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2024-49959",
"datePublished": "2024-10-21T18:02:12.355Z",
"dateReserved": "2024-10-21T12:17:06.049Z",
"dateUpdated": "2025-11-03T22:23:39.640Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
}
}
FKIE_CVE-2024-49959
Vulnerability from fkie_nvd - Published: 2024-10-21 18:15 - Updated: 2026-06-17 08:00| Vendor | Product | Version | |
|---|---|---|---|
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * |
{
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"fs/jbd2/checkpoint.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "801a35dfef6996f3d5eaa96a59caf00440d9165e",
"status": "affected",
"version": "8c3f25d8950c3e9fe6c9849f88679b3f2a071550",
"versionType": "git"
},
{
"lessThan": "d5dc65370a746750dbb2f03eabcf86b18db65f32",
"status": "affected",
"version": "8c3f25d8950c3e9fe6c9849f88679b3f2a071550",
"versionType": "git"
},
{
"lessThan": "481e8f18a290e39e04ddb7feb2bb2a2cc3b213ed",
"status": "affected",
"version": "8c3f25d8950c3e9fe6c9849f88679b3f2a071550",
"versionType": "git"
},
{
"lessThan": "ec7f8337c98ad281020ad1f11ba492462d80737a",
"status": "affected",
"version": "8c3f25d8950c3e9fe6c9849f88679b3f2a071550",
"versionType": "git"
},
{
"lessThan": "70bae48377a2c4296fd3caf4caf8f11079111019",
"status": "affected",
"version": "8c3f25d8950c3e9fe6c9849f88679b3f2a071550",
"versionType": "git"
},
{
"lessThan": "1c62dc0d82c62f0dc8fcdc4843208e522acccaf5",
"status": "affected",
"version": "8c3f25d8950c3e9fe6c9849f88679b3f2a071550",
"versionType": "git"
},
{
"lessThan": "3ced0fe6c0eff032733ea8b38778b34707270138",
"status": "affected",
"version": "8c3f25d8950c3e9fe6c9849f88679b3f2a071550",
"versionType": "git"
},
{
"lessThan": "c6bf043b210eac67d35a114e345c4e5585672913",
"status": "affected",
"version": "8c3f25d8950c3e9fe6c9849f88679b3f2a071550",
"versionType": "git"
},
{
"lessThan": "f5cacdc6f2bb2a9bf214469dd7112b43dd2dd68a",
"status": "affected",
"version": "8c3f25d8950c3e9fe6c9849f88679b3f2a071550",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"fs/jbd2/checkpoint.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "2.6.28"
},
{
"lessThan": "2.6.28",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "4.19.*",
"status": "unaffected",
"version": "4.19.323",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.285",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.227",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.168",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.113",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.55",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.10.*",
"status": "unaffected",
"version": "6.10.14",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.11.*",
"status": "unaffected",
"version": "6.11.3",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.12",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"configurations": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "1ECF4EB9-CCE6-413E-9A66-D01E03C462EF",
"versionEndExcluding": "5.10.227",
"versionStartIncluding": "2.6.28",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "4D51C05D-455B-4D8D-89E7-A58E140B864C",
"versionEndExcluding": "5.15.168",
"versionStartIncluding": "5.11",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "D01BD22E-ACD1-4618-9D01-6116570BE1EE",
"versionEndExcluding": "6.1.113",
"versionStartIncluding": "5.16",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "E90B9576-56C4-47BC-AAB0-C5B2D438F5D0",
"versionEndExcluding": "6.6.55",
"versionStartIncluding": "6.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "4C16BCE0-FFA0-4599-BE0A-1FD65101C021",
"versionEndExcluding": "6.10.14",
"versionStartIncluding": "6.7",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "54D9C704-D679-41A7-9C40-10A6B1E7FFE9",
"versionEndExcluding": "6.11.3",
"versionStartIncluding": "6.11",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\njbd2: stop waiting for space when jbd2_cleanup_journal_tail() returns error\n\nIn __jbd2_log_wait_for_space(), we might call jbd2_cleanup_journal_tail()\nto recover some journal space. But if an error occurs while executing\njbd2_cleanup_journal_tail() (e.g., an EIO), we don\u0027t stop waiting for free\nspace right away, we try other branches, and if j_committing_transaction\nis NULL (i.e., the tid is 0), we will get the following complain:\n\n============================================\nJBD2: I/O error when updating journal superblock for sdd-8.\n__jbd2_log_wait_for_space: needed 256 blocks and only had 217 space available\n__jbd2_log_wait_for_space: no way to get more journal space in sdd-8\n------------[ cut here ]------------\nWARNING: CPU: 2 PID: 139804 at fs/jbd2/checkpoint.c:109 __jbd2_log_wait_for_space+0x251/0x2e0\nModules linked in:\nCPU: 2 PID: 139804 Comm: kworker/u8:3 Not tainted 6.6.0+ #1\nRIP: 0010:__jbd2_log_wait_for_space+0x251/0x2e0\nCall Trace:\n \u003cTASK\u003e\n add_transaction_credits+0x5d1/0x5e0\n start_this_handle+0x1ef/0x6a0\n jbd2__journal_start+0x18b/0x340\n ext4_dirty_inode+0x5d/0xb0\n __mark_inode_dirty+0xe4/0x5d0\n generic_update_time+0x60/0x70\n[...]\n============================================\n\nSo only if jbd2_cleanup_journal_tail() returns 1, i.e., there is nothing to\nclean up at the moment, continue to try to reclaim free space in other ways.\n\nNote that this fix relies on commit 6f6a6fda2945 (\"jbd2: fix ocfs2 corrupt\nwhen updating journal superblock fails\") to make jbd2_cleanup_journal_tail\nreturn the correct error code."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: jbd2: dejad de esperar espacio cuando jbd2_cleanup_journal_tail() devuelve un error En __jbd2_log_wait_for_space(), podr\u00edamos llamar a jbd2_cleanup_journal_tail() para recuperar algo de espacio en el diario. Pero si ocurre un error mientras se ejecuta jbd2_cleanup_journal_tail() (por ejemplo, un EIO), no dejamos de esperar espacio libre de inmediato, probamos otras ramas y, si j_committing_transaction es NULL (es decir, el tid es 0), obtendremos la siguiente queja: =============================================== JBD2: Error de E/S al actualizar el superbloque del diario para sdd-8. __jbd2_log_wait_for_space: se necesitaban 256 bloques y solo hab\u00eda 217 de espacio disponible __jbd2_log_wait_for_space: no hay forma de obtener m\u00e1s espacio de diario en sdd-8 ------------[ cortar aqu\u00ed ]------------ ADVERTENCIA: CPU: 2 PID: 139804 en fs/jbd2/checkpoint.c:109 __jbd2_log_wait_for_space+0x251/0x2e0 M\u00f3dulos vinculados: CPU: 2 PID: 139804 Comm: kworker/u8:3 No contaminado 6.6.0+ #1 RIP: 0010:__jbd2_log_wait_for_space+0x251/0x2e0 Rastreo de llamadas: add_transaction_credits+0x5d1/0x5e0 start_this_handle+0x1ef/0x6a0 jbd2__journal_start+0x18b/0x340 ext4_dirty_inode+0x5d/0xb0 __mark_inode_dirty+0xe4/0x5d0 generic_update_time+0x60/0x70 [...] == ..."
}
],
"id": "CVE-2024-49959",
"lastModified": "2026-06-17T08:00:49.560",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 5.5,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 3.6,
"source": "nvd@nist.gov",
"type": "Primary"
}
],
"ssvcV203": [
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"ssvcData": {
"id": "CVE-2024-49959",
"options": [
{
"exploitation": "none"
},
{
"automatable": "no"
},
{
"technicalImpact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2024-10-22T13:35:21.788104Z",
"version": "2.0.3"
}
}
]
},
"published": "2024-10-21T18:15:17.123",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/1c62dc0d82c62f0dc8fcdc4843208e522acccaf5"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/3ced0fe6c0eff032733ea8b38778b34707270138"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/481e8f18a290e39e04ddb7feb2bb2a2cc3b213ed"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/70bae48377a2c4296fd3caf4caf8f11079111019"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/801a35dfef6996f3d5eaa96a59caf00440d9165e"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/c6bf043b210eac67d35a114e345c4e5585672913"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/d5dc65370a746750dbb2f03eabcf86b18db65f32"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/ec7f8337c98ad281020ad1f11ba492462d80737a"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/f5cacdc6f2bb2a9bf214469dd7112b43dd2dd68a"
},
{
"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://lists.debian.org/debian-lts-announce/2025/03/msg00002.html"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Modified",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "NVD-CWE-noinfo"
}
],
"source": "nvd@nist.gov",
"type": "Primary"
}
]
}
GHSA-Q7PC-7WVX-9QCX
Vulnerability from github – Published: 2024-10-21 18:30 – Updated: 2025-11-04 00:31In the Linux kernel, the following vulnerability has been resolved:
jbd2: stop waiting for space when jbd2_cleanup_journal_tail() returns error
In __jbd2_log_wait_for_space(), we might call jbd2_cleanup_journal_tail() to recover some journal space. But if an error occurs while executing jbd2_cleanup_journal_tail() (e.g., an EIO), we don't stop waiting for free space right away, we try other branches, and if j_committing_transaction is NULL (i.e., the tid is 0), we will get the following complain:
============================================ JBD2: I/O error when updating journal superblock for sdd-8. __jbd2_log_wait_for_space: needed 256 blocks and only had 217 space available __jbd2_log_wait_for_space: no way to get more journal space in sdd-8 ------------[ cut here ]------------ WARNING: CPU: 2 PID: 139804 at fs/jbd2/checkpoint.c:109 __jbd2_log_wait_for_space+0x251/0x2e0 Modules linked in: CPU: 2 PID: 139804 Comm: kworker/u8:3 Not tainted 6.6.0+ #1 RIP: 0010:__jbd2_log_wait_for_space+0x251/0x2e0 Call Trace: add_transaction_credits+0x5d1/0x5e0 start_this_handle+0x1ef/0x6a0 jbd2__journal_start+0x18b/0x340 ext4_dirty_inode+0x5d/0xb0 __mark_inode_dirty+0xe4/0x5d0 generic_update_time+0x60/0x70 [...] ============================================
So only if jbd2_cleanup_journal_tail() returns 1, i.e., there is nothing to clean up at the moment, continue to try to reclaim free space in other ways.
Note that this fix relies on commit 6f6a6fda2945 ("jbd2: fix ocfs2 corrupt when updating journal superblock fails") to make jbd2_cleanup_journal_tail return the correct error code.
{
"affected": [],
"aliases": [
"CVE-2024-49959"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-10-21T18:15:17Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\njbd2: stop waiting for space when jbd2_cleanup_journal_tail() returns error\n\nIn __jbd2_log_wait_for_space(), we might call jbd2_cleanup_journal_tail()\nto recover some journal space. But if an error occurs while executing\njbd2_cleanup_journal_tail() (e.g., an EIO), we don\u0027t stop waiting for free\nspace right away, we try other branches, and if j_committing_transaction\nis NULL (i.e., the tid is 0), we will get the following complain:\n\n============================================\nJBD2: I/O error when updating journal superblock for sdd-8.\n__jbd2_log_wait_for_space: needed 256 blocks and only had 217 space available\n__jbd2_log_wait_for_space: no way to get more journal space in sdd-8\n------------[ cut here ]------------\nWARNING: CPU: 2 PID: 139804 at fs/jbd2/checkpoint.c:109 __jbd2_log_wait_for_space+0x251/0x2e0\nModules linked in:\nCPU: 2 PID: 139804 Comm: kworker/u8:3 Not tainted 6.6.0+ #1\nRIP: 0010:__jbd2_log_wait_for_space+0x251/0x2e0\nCall Trace:\n \u003cTASK\u003e\n add_transaction_credits+0x5d1/0x5e0\n start_this_handle+0x1ef/0x6a0\n jbd2__journal_start+0x18b/0x340\n ext4_dirty_inode+0x5d/0xb0\n __mark_inode_dirty+0xe4/0x5d0\n generic_update_time+0x60/0x70\n[...]\n============================================\n\nSo only if jbd2_cleanup_journal_tail() returns 1, i.e., there is nothing to\nclean up at the moment, continue to try to reclaim free space in other ways.\n\nNote that this fix relies on commit 6f6a6fda2945 (\"jbd2: fix ocfs2 corrupt\nwhen updating journal superblock fails\") to make jbd2_cleanup_journal_tail\nreturn the correct error code.",
"id": "GHSA-q7pc-7wvx-9qcx",
"modified": "2025-11-04T00:31:43Z",
"published": "2024-10-21T18:30:59Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49959"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1c62dc0d82c62f0dc8fcdc4843208e522acccaf5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3ced0fe6c0eff032733ea8b38778b34707270138"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/481e8f18a290e39e04ddb7feb2bb2a2cc3b213ed"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/70bae48377a2c4296fd3caf4caf8f11079111019"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/801a35dfef6996f3d5eaa96a59caf00440d9165e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c6bf043b210eac67d35a114e345c4e5585672913"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d5dc65370a746750dbb2f03eabcf86b18db65f32"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ec7f8337c98ad281020ad1f11ba492462d80737a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f5cacdc6f2bb2a9bf214469dd7112b43dd2dd68a"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
ICSA-25-226-07
Vulnerability from csaf_cisa - Published: 2025-08-12 00:00 - Updated: 2026-02-25 07:00MSRC_CVE-2024-49959
Vulnerability from csaf_microsoft - Published: 2024-10-01 07:00 - Updated: 2026-02-21 00:55OESA-2024-2321 (CVE-2022-48916)
Vulnerability from osv_openeuler – Published: 2024-11-01 11:07 – Updated: 2026-08-06 11:07 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
iommu/vt-d: Fix double list_add when enabling VMD in scalable mode
When enabling VMD and IOMMU scalable mode, the following kernel panic call trace/kernel log is shown in Eagle Stream platform (Sapphire Rapids CPU) during booting:
pci 0000:59:00.5: Adding to iommu group 42 ... vmd 0000:59:00.5: PCI host bridge to bus 10000:80 pci 10000:80:01.0: [8086:352a] type 01 class 0x060400 pci 10000:80:01.0: reg 0x10: [mem 0x00000000-0x0001ffff 64bit] pci 10000:80:01.0: enabling Extended Tags pci 10000:80:01.0: PME# supported from D0 D3hot D3cold pci 10000:80:01.0: DMAR: Setup RID2PASID failed pci 10000:80:01.0: Failed to add to iommu group 42: -16 pci 10000:80:03.0: [8086:352b] type 01 class 0x060400 pci 10000:80:03.0: reg 0x10: [mem 0x00000000-0x0001ffff 64bit] pci 10000:80:03.0: enabling Extended Tags pci 10000:80:03.0: PME# supported from D0 D3hot D3cold ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:29! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 7 Comm: kworker/0:1 Not tainted 5.17.0-rc3+ #7 Hardware name: Lenovo ThinkSystem SR650V3/SB27A86647, BIOS ESE101Y-1.00 01/13/2022 Workqueue: events work_for_cpu_fn RIP: 0010:__list_add_valid.cold+0x26/0x3f Code: 9a 4a ab ff 4c 89 c1 48 c7 c7 40 0c d9 9e e8 b9 b1 fe ff 0f 0b 48 89 f2 4c 89 c1 48 89 fe 48 c7 c7 f0 0c d9 9e e8 a2 b1 fe ff <0f> 0b 48 89 d1 4c 89 c6 4c 89 ca 48 c7 c7 98 0c d9 9e e8 8b b1 fe RSP: 0000:ff5ad434865b3a40 EFLAGS: 00010246 RAX: 0000000000000058 RBX: ff4d61160b74b880 RCX: ff4d61255e1fffa8 RDX: 0000000000000000 RSI: 00000000fffeffff RDI: ffffffff9fd34f20 RBP: ff4d611d8e245c00 R08: 0000000000000000 R09: ff5ad434865b3888 R10: ff5ad434865b3880 R11: ff4d61257fdc6fe8 R12: ff4d61160b74b8a0 R13: ff4d61160b74b8a0 R14: ff4d611d8e245c10 R15: ff4d611d8001ba70 FS: 0000000000000000(0000) GS:ff4d611d5ea00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ff4d611fa1401000 CR3: 0000000aa0210001 CR4: 0000000000771ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> intel_pasid_alloc_table+0x9c/0x1d0 dmar_insert_one_dev_info+0x423/0x540 ? device_to_iommu+0x12d/0x2f0 intel_iommu_attach_device+0x116/0x290 __iommu_attach_device+0x1a/0x90 iommu_group_add_device+0x190/0x2c0 __iommu_probe_device+0x13e/0x250 iommu_probe_device+0x24/0x150 iommu_bus_notifier+0x69/0x90 blocking_notifier_call_chain+0x5a/0x80 device_add+0x3db/0x7b0 ? arch_memremap_can_ram_remap+0x19/0x50 ? memremap+0x75/0x140 pci_device_add+0x193/0x1d0 pci_scan_single_device+0xb9/0xf0 pci_scan_slot+0x4c/0x110 pci_scan_child_bus_extend+0x3a/0x290 vmd_enable_domain.constprop.0+0x63e/0x820 vmd_probe+0x163/0x190 local_pci_probe+0x42/0x80 work_for_cpu_fn+0x13/0x20 process_one_work+0x1e2/0x3b0 worker_thread+0x1c4/0x3a0 ? rescuer_thread+0x370/0x370 kthread+0xc7/0xf0 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30 </TASK> Modules linked in: ---[ end trace 0000000000000000 ]--- ... Kernel panic - not syncing: Fatal exception Kernel Offset: 0x1ca00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) ---[ end Kernel panic - not syncing: Fatal exception ]---
The following 'lspci' output shows devices '10000:80:*' are subdevices of the VMD device 0000:59:00.5:
$ lspci ... 0000:59:00.5 RAID bus controller: Intel Corporation Volume Management Device NVMe RAID Controller (rev 20) ... 10000:80:01.0 PCI bridge: Intel Corporation Device 352a (rev 03) 10000:80:03.0 PCI bridge: Intel Corporation Device 352b (rev 03) 10000:80:05.0 PCI bridge: Intel Corporation Device 352c (rev 03) 10000:80:07.0 PCI bridge: Intel Corporation Device 352d (rev 03) 10000:81:00.0 Non-Volatile memory controller: Intel Corporation NVMe Datacenter SSD [3DNAND, Beta Rock Controller] 10000:82:00 ---truncated---(CVE-2022-48916)
In the Linux kernel, the following vulnerability has been resolved: PCI: mt7621: Add sentinel to quirks table Current driver is missing a sentinel in the struct soc_device_attribute array, which causes an oops when assessed by the soc_device_match(mt7621_pcie_quirks_match) call. This was only exposed once the CONFIG_SOC_MT7621 mt7621 soc_dev_attr was fixed to register the SOC as a device, in: commit 7c18b64bba3b ("mips: ralink: mt7621: do not use kzalloc too early") Fix it by adding the required sentinel.(CVE-2022-48952)
In the Linux kernel, the following vulnerability has been resolved: ntb: intel: Fix the NULL vs IS_ERR() bug for debugfs_create_dir() The debugfs_create_dir() function returns error pointers. It never returns NULL. So use IS_ERR() to check it.(CVE-2023-52917)
In the Linux kernel, the following vulnerability has been resolved: media: pci: cx23885: check cx23885_vdev_init() return cx23885_vdev_init() can return a NULL pointer, but that pointer is used in the next line without a check. Add a NULL pointer check and go to the error unwind if it is NULL.(CVE-2023-52918)
In the Linux kernel, the following vulnerability has been resolved:
of: module: prevent NULL pointer dereference in vsnprintf()
In of_modalias(), we can get passed the str and len parameters which would cause a kernel oops in vsnprintf() since it only allows passing a NULL ptr when the length is also 0. Also, we need to filter out the negative values of the len parameter as these will result in a really huge buffer since snprintf() takes size_t parameter while ours is ssize_t...
Found by Linux Verification Center (linuxtesting.org) with the Svace static analysis tool.(CVE-2024-35878)
In the Linux kernel, the following vulnerability has been resolved:
dma: xilinx_dpdma: Fix locking
There are several places where either chan->lock or chan->vchan.lock was not held. Add appropriate locking. This fixes lockdep warnings like
[ 31.077578] ------------[ cut here ]------------ [ 31.077831] WARNING: CPU: 2 PID: 40 at drivers/dma/xilinx/xilinx_dpdma.c:834 xilinx_dpdma_chan_queue_transfer+0x274/0x5e0 [ 31.077953] Modules linked in: [ 31.078019] CPU: 2 PID: 40 Comm: kworker/u12:1 Not tainted 6.6.20+ #98 [ 31.078102] Hardware name: xlnx,zynqmp (DT) [ 31.078169] Workqueue: events_unbound deferred_probe_work_func [ 31.078272] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 31.078377] pc : xilinx_dpdma_chan_queue_transfer+0x274/0x5e0 [ 31.078473] lr : xilinx_dpdma_chan_queue_transfer+0x270/0x5e0 [ 31.078550] sp : ffffffc083bb2e10 [ 31.078590] x29: ffffffc083bb2e10 x28: 0000000000000000 x27: ffffff880165a168 [ 31.078754] x26: ffffff880164e920 x25: ffffff880164eab8 x24: ffffff880164d480 [ 31.078920] x23: ffffff880165a148 x22: ffffff880164e988 x21: 0000000000000000 [ 31.079132] x20: ffffffc082aa3000 x19: ffffff880164e880 x18: 0000000000000000 [ 31.079295] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 31.079453] x14: 0000000000000000 x13: ffffff8802263dc0 x12: 0000000000000001 [ 31.079613] x11: 0001ffc083bb2e34 x10: 0001ff880164e98f x9 : 0001ffc082aa3def [ 31.079824] x8 : 0001ffc082aa3dec x7 : 0000000000000000 x6 : 0000000000000516 [ 31.079982] x5 : ffffffc7f8d43000 x4 : ffffff88003c9c40 x3 : ffffffffffffffff [ 31.080147] x2 : ffffffc7f8d43000 x1 : 00000000000000c0 x0 : 0000000000000000 [ 31.080307] Call trace: [ 31.080340] xilinx_dpdma_chan_queue_transfer+0x274/0x5e0 [ 31.080518] xilinx_dpdma_issue_pending+0x11c/0x120 [ 31.080595] zynqmp_disp_layer_update+0x180/0x3ac [ 31.080712] zynqmp_dpsub_plane_atomic_update+0x11c/0x21c [ 31.080825] drm_atomic_helper_commit_planes+0x20c/0x684 [ 31.080951] drm_atomic_helper_commit_tail+0x5c/0xb0 [ 31.081139] commit_tail+0x234/0x294 [ 31.081246] drm_atomic_helper_commit+0x1f8/0x210 [ 31.081363] drm_atomic_commit+0x100/0x140 [ 31.081477] drm_client_modeset_commit_atomic+0x318/0x384 [ 31.081634] drm_client_modeset_commit_locked+0x8c/0x24c [ 31.081725] drm_client_modeset_commit+0x34/0x5c [ 31.081812] __drm_fb_helper_restore_fbdev_mode_unlocked+0x104/0x168 [ 31.081899] drm_fb_helper_set_par+0x50/0x70 [ 31.081971] fbcon_init+0x538/0xc48 [ 31.082047] visual_init+0x16c/0x23c [ 31.082207] do_bind_con_driver.isra.0+0x2d0/0x634 [ 31.082320] do_take_over_console+0x24c/0x33c [ 31.082429] do_fbcon_takeover+0xbc/0x1b0 [ 31.082503] fbcon_fb_registered+0x2d0/0x34c [ 31.082663] register_framebuffer+0x27c/0x38c [ 31.082767] __drm_fb_helper_initial_config_and_unlock+0x5c0/0x91c [ 31.082939] drm_fb_helper_initial_config+0x50/0x74 [ 31.083012] drm_fbdev_dma_client_hotplug+0xb8/0x108 [ 31.083115] drm_client_register+0xa0/0xf4 [ 31.083195] drm_fbdev_dma_setup+0xb0/0x1cc [ 31.083293] zynqmp_dpsub_drm_init+0x45c/0x4e0 [ 31.083431] zynqmp_dpsub_probe+0x444/0x5e0 [ 31.083616] platform_probe+0x8c/0x13c [ 31.083713] really_probe+0x258/0x59c [ 31.083793] __driver_probe_device+0xc4/0x224 [ 31.083878] driver_probe_device+0x70/0x1c0 [ 31.083961] __device_attach_driver+0x108/0x1e0 [ 31.084052] bus_for_each_drv+0x9c/0x100 [ 31.084125] __device_attach+0x100/0x298 [ 31.084207] device_initial_probe+0x14/0x20 [ 31.084292] bus_probe_device+0xd8/0xdc [ 31.084368] deferred_probe_work_func+0x11c/0x180 [ 31.084451] process_one_work+0x3ac/0x988 [ 31.084643] worker_thread+0x398/0x694 [ 31.084752] kthread+0x1bc/0x1c0 [ 31.084848] ret_from_fork+0x10/0x20 [ 31.084932] irq event stamp: 64549 [ 31.084970] hardirqs last enabled at (64548): [<ffffffc081adf35c>] _raw_spin_unlock_irqrestore+0x80/0x90 [ 31.085157] ---truncated---(CVE-2024-35990)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nfnetlink_queue: acquire rcu_read_lock() in instance_destroy_rcu()
syzbot reported that nf_reinject() could be called without rcu_read_lock() :
WARNING: suspicious RCU usage 6.9.0-rc7-syzkaller-02060-g5c1672705a1a #0 Not tainted
net/netfilter/nfnetlink_queue.c:263 suspicious rcu_dereference_check() usage!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 1 2 locks held by syz-executor.4/13427: #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_lock_acquire include/linux/rcupdate.h:329 [inline] #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_do_batch kernel/rcu/tree.c:2190 [inline] #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_core+0xa86/0x1830 kernel/rcu/tree.c:2471 #1: ffff88801ca92958 (&inst->lock){+.-.}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline] #1: ffff88801ca92958 (&inst->lock){+.-.}-{2:2}, at: nfqnl_flush net/netfilter/nfnetlink_queue.c:405 [inline] #1: ffff88801ca92958 (&inst->lock){+.-.}-{2:2}, at: instance_destroy_rcu+0x30/0x220 net/netfilter/nfnetlink_queue.c:172
stack backtrace: CPU: 0 PID: 13427 Comm: syz-executor.4 Not tainted 6.9.0-rc7-syzkaller-02060-g5c1672705a1a #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024 Call Trace: <IRQ> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 lockdep_rcu_suspicious+0x221/0x340 kernel/locking/lockdep.c:6712 nf_reinject net/netfilter/nfnetlink_queue.c:323 [inline] nfqnl_reinject+0x6ec/0x1120 net/netfilter/nfnetlink_queue.c:397 nfqnl_flush net/netfilter/nfnetlink_queue.c:410 [inline] instance_destroy_rcu+0x1ae/0x220 net/netfilter/nfnetlink_queue.c:172 rcu_do_batch kernel/rcu/tree.c:2196 [inline] rcu_core+0xafd/0x1830 kernel/rcu/tree.c:2471 handle_softirqs+0x2d6/0x990 kernel/softirq.c:554 __do_softirq kernel/softirq.c:588 [inline] invoke_softirq kernel/softirq.c:428 [inline] __irq_exit_rcu+0xf4/0x1c0 kernel/softirq.c:637 irq_exit_rcu+0x9/0x30 kernel/softirq.c:649 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1043 [inline] sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1043 </IRQ> <TASK>(CVE-2024-36286)
In the Linux kernel, the following vulnerability has been resolved:
ALSA: core: Fix NULL module pointer assignment at card init
The commit 81033c6b584b ("ALSA: core: Warn on empty module") introduced a WARN_ON() for a NULL module pointer passed at snd_card object creation, and it also wraps the code around it with '#ifdef MODULE'. This works in most cases, but the devils are always in details. "MODULE" is defined when the target code (i.e. the sound core) is built as a module; but this doesn't mean that the caller is also built-in or not. Namely, when only the sound core is built-in (CONFIG_SND=y) while the driver is a module (CONFIG_SND_USB_AUDIO=m), the passed module pointer is ignored even if it's non-NULL, and card->module remains as NULL. This would result in the missing module reference up/down at the device open/close, leading to a race with the code execution after the module removal.
For addressing the bug, move the assignment of card->module again out of ifdef. The WARN_ON() is still wrapped with ifdef because the module can be really NULL when all sound drivers are built-in.
Note that we keep 'ifdef MODULE' for WARN_ON(), otherwise it would lead to a false-positive NULL module check. Admittedly it won't catch perfectly, i.e. no check is performed when CONFIG_SND=y. But, it's no real problem as it's only for debugging, and the condition is pretty rare.(CVE-2024-38605)
In the Linux kernel, the following vulnerability has been resolved:
soundwire: cadence: fix invalid PDI offset
For some reason, we add an offset to the PDI, presumably to skip the PDI0 and PDI1 which are reserved for BPT.
This code is however completely wrong and leads to an out-of-bounds access. We were just lucky so far since we used only a couple of PDIs and remained within the PDI array bounds.
A Fixes: tag is not provided since there are no known platforms where the out-of-bounds would be accessed, and the initial code had problems as well.
A follow-up patch completely removes this useless offset.(CVE-2024-38635)
In the Linux kernel, the following vulnerability has been resolved:
riscv: prevent pt_regs corruption for secondary idle threads
Top of the kernel thread stack should be reserved for pt_regs. However this is not the case for the idle threads of the secondary boot harts. Their stacks overlap with their pt_regs, so both may get corrupted.
Similar issue has been fixed for the primary hart, see c7cdd96eca28 ("riscv: prevent stack corruption by reserving task_pt_regs(p) early"). However that fix was not propagated to the secondary harts. The problem has been noticed in some CPU hotplug tests with V enabled. The function smp_callin stored several registers on stack, corrupting top of pt_regs structure including status field. As a result, kernel attempted to save or restore inexistent V context.(CVE-2024-38667)
In the Linux kernel, the following vulnerability has been resolved:
nvmet: fix a possible leak when destroy a ctrl during qp establishment
In nvmet_sq_destroy we capture sq->ctrl early and if it is non-NULL we know that a ctrl was allocated (in the admin connect request handler) and we need to release pending AERs, clear ctrl->sqs and sq->ctrl (for nvme-loop primarily), and drop the final reference on the ctrl.
However, a small window is possible where nvmet_sq_destroy starts (as a result of the client giving up and disconnecting) concurrently with the nvme admin connect cmd (which may be in an early stage). But before kill_and_confirm of sq->ref (i.e. the admin connect managed to get an sq live reference). In this case, sq->ctrl was allocated however after it was captured in a local variable in nvmet_sq_destroy. This prevented the final reference drop on the ctrl.
Solve this by re-capturing the sq->ctrl after all inflight request has completed, where for sure sq->ctrl reference is final, and move forward based on that.
This issue was observed in an environment with many hosts connecting multiple ctrls simoutanuosly, creating a delay in allocating a ctrl leading up to this race window.(CVE-2024-42152)
In the Linux kernel, the following vulnerability has been resolved:
dev/parport: fix the array out-of-bounds risk
Fixed array out-of-bounds issues caused by sprintf by replacing it with snprintf for safer data copying, ensuring the destination buffer is not overflowed.
Below is the stack trace I encountered during the actual issue:
[ 66.575408s] [pid:5118,cpu4,QThread,4]Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: do_hardware_base_addr+0xcc/0xd0 [parport] [ 66.575408s] [pid:5118,cpu4,QThread,5]CPU: 4 PID: 5118 Comm: QThread Tainted: G S W O 5.10.97-arm64-desktop #7100.57021.2 [ 66.575439s] [pid:5118,cpu4,QThread,6]TGID: 5087 Comm: EFileApp [ 66.575439s] [pid:5118,cpu4,QThread,7]Hardware name: HUAWEI HUAWEI QingYun PGUX-W515x-B081/SP1PANGUXM, BIOS 1.00.07 04/29/2024 [ 66.575439s] [pid:5118,cpu4,QThread,8]Call trace: [ 66.575469s] [pid:5118,cpu4,QThread,9] dump_backtrace+0x0/0x1c0 [ 66.575469s] [pid:5118,cpu4,QThread,0] show_stack+0x14/0x20 [ 66.575469s] [pid:5118,cpu4,QThread,1] dump_stack+0xd4/0x10c [ 66.575500s] [pid:5118,cpu4,QThread,2] panic+0x1d8/0x3bc [ 66.575500s] [pid:5118,cpu4,QThread,3] __stack_chk_fail+0x2c/0x38 [ 66.575500s] [pid:5118,cpu4,QThread,4] do_hardware_base_addr+0xcc/0xd0 parport
In the Linux kernel, the following vulnerability has been resolved:
exfat: fix potential deadlock on __exfat_get_dentry_set
When accessing a file with more entries than ES_MAX_ENTRY_NUM, the bh-array is allocated in __exfat_get_entry_set. The problem is that the bh-array is allocated with GFP_KERNEL. It does not make sense. In the following cases, a deadlock for sbi->s_lock between the two processes may occur.
CPU0 CPU1
---- ----
kswapd balance_pgdat lock(fs_reclaim) exfat_iterate lock(&sbi->s_lock) exfat_readdir exfat_get_uniname_from_ext_entry exfat_get_dentry_set __exfat_get_dentry_set kmalloc_array ... lock(fs_reclaim) ... evict exfat_evict_inode lock(&sbi->s_lock)
To fix this, let's allocate bh-array with GFP_NOFS.(CVE-2024-42315)
In the Linux kernel, the following vulnerability has been resolved:
wifi: virt_wifi: avoid reporting connection success with wrong SSID
When user issues a connection with a different SSID than the one virt_wifi has advertised, the __cfg80211_connect_result() will trigger the warning: WARN_ON(bss_not_found).
The issue is because the connection code in virt_wifi does not check the SSID from user space (it only checks the BSSID), and virt_wifi will call cfg80211_connect_result() with WLAN_STATUS_SUCCESS even if the SSID is different from the one virt_wifi has advertised. Eventually cfg80211 won't be able to find the cfg80211_bss and generate the warning.
Fixed it by checking the SSID (from user space) in the connection code.(CVE-2024-43841)
In the Linux kernel, the following vulnerability has been resolved:
jfs: Fix array-index-out-of-bounds in diFree(CVE-2024-43858)
In the Linux kernel, the following vulnerability has been resolved:
drm/nouveau: prime: fix refcount underflow
Calling nouveau_bo_ref() on a nouveau_bo without initializing it (and hence the backing ttm_bo) leads to a refcount underflow.
Instead of calling nouveau_bo_ref() in the unwind path of drm_gem_object_init(), clean things up manually.
(cherry picked from commit 1b93f3e89d03cfc576636e195466a0d728ad8de5)(CVE-2024-43867)
In the Linux kernel, the following vulnerability has been resolved:
devres: Fix memory leakage caused by driver API devm_free_percpu()
It will cause memory leakage when use driver API devm_free_percpu() to free memory allocated by devm_alloc_percpu(), fixed by using devres_release() instead of devres_destroy() within devm_free_percpu().(CVE-2024-43871)
In the Linux kernel, the following vulnerability has been resolved:
drm/client: fix null pointer dereference in drm_client_modeset_probe
In drm_client_modeset_probe(), the return value of drm_mode_duplicate() is assigned to modeset->mode, which will lead to a possible NULL pointer dereference on failure of drm_mode_duplicate(). Add a check to avoid npd.(CVE-2024-43894)
In the Linux kernel, the following vulnerability has been resolved:
mptcp: pm: only decrement add_addr_accepted for MPJ req
Adding the following warning ...
WARN_ON_ONCE(msk->pm.add_addr_accepted == 0)
... before decrementing the add_addr_accepted counter helped to find a bug when running the "remove single subflow" subtest from the mptcp_join.sh selftest.
Removing a 'subflow' endpoint will first trigger a RM_ADDR, then the subflow closure. Before this patch, and upon the reception of the RM_ADDR, the other peer will then try to decrement this add_addr_accepted. That's not correct because the attached subflows have not been created upon the reception of an ADD_ADDR.
A way to solve that is to decrement the counter only if the attached subflow was an MP_JOIN to a remote id that was not 0, and initiated by the host receiving the RM_ADDR.(CVE-2024-45009)
In the Linux kernel, the following vulnerability has been resolved:
usb: dwc3: core: Prevent USB core invalid event buffer address access
This commit addresses an issue where the USB core could access an invalid event buffer address during runtime suspend, potentially causing SMMU faults and other memory issues in Exynos platforms. The problem arises from the following sequence. 1. In dwc3_gadget_suspend, there is a chance of a timeout when moving the USB core to the halt state after clearing the run/stop bit by software. 2. In dwc3_core_exit, the event buffer is cleared regardless of the USB core's status, which may lead to an SMMU faults and other memory issues. if the USB core tries to access the event buffer address.
To prevent this hardware quirk on Exynos platforms, this commit ensures that the event buffer address is not cleared by software when the USB core is active during runtime suspend by checking its status before clearing the buffer address.(CVE-2024-46675)
In the Linux kernel, the following vulnerability has been resolved:
soc: qcom: cmd-db: Map shared memory as WC, not WB
Linux does not write into cmd-db region. This region of memory is write protected by XPU. XPU may sometime falsely detect clean cache eviction as "write" into the write protected region leading to secure interrupt which causes an endless loop somewhere in Trust Zone.
The only reason it is working right now is because Qualcomm Hypervisor maps the same region as Non-Cacheable memory in Stage 2 translation tables. The issue manifests if we want to use another hypervisor (like Xen or KVM), which does not know anything about those specific mappings.
Changing the mapping of cmd-db memory from MEMREMAP_WB to MEMREMAP_WT/WC removes dependency on correct mappings in Stage 2 tables. This patch fixes the issue by updating the mapping to MEMREMAP_WC.
I tested this on SA8155P with Xen.(CVE-2024-46689)
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: fix mc_data out-of-bounds read warning
Clear warning that read mc_data[i-1] may out-of-bounds.(CVE-2024-46722)
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Fix out-of-bounds read of df_v1_7_channel_number
Check the fb_channel_number range to avoid the array out-of-bounds read error(CVE-2024-46724)
In the Linux kernel, the following vulnerability has been resolved:
hwmon: (nct6775-core) Fix underflows seen when writing limit attributes
DIV_ROUND_CLOSEST() after kstrtol() results in an underflow if a large negative number such as -9223372036854775808 is provided by the user. Fix it by reordering clamp_val() and DIV_ROUND_CLOSEST() operations.(CVE-2024-46757)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: added NULL check at start of dc_validate_stream
[Why] prevent invalid memory access
[How] check if dc and stream are NULL(CVE-2024-46802)
In the Linux kernel, the following vulnerability has been resolved:
KVM: x86: Acquire kvm->srcu when handling KVM_SET_VCPU_EVENTS
Grab kvm->srcu when processing KVM_SET_VCPU_EVENTS, as KVM will forcibly leave nested VMX/SVM if SMM mode is being toggled, and leaving nested VMX reads guest memory.
Note, kvm_vcpu_ioctl_x86_set_vcpu_events() can also be called from KVM_RUN via sync_regs(), which already holds SRCU. I.e. trying to precisely use kvm_vcpu_srcu_read_lock() around the problematic SMM code would cause problems. Acquiring SRCU isn't all that expensive, so for simplicity, grab it unconditionally for KVM_SET_VCPU_EVENTS.
============================= WARNING: suspicious RCU usage 6.10.0-rc7-332d2c1d713e-next-vm #552 Not tainted
include/linux/kvm_host.h:1027 suspicious rcu_dereference_check() usage!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 1 1 lock held by repro/1071: #0: ffff88811e424430 (&vcpu->mutex){+.+.}-{3:3}, at: kvm_vcpu_ioctl+0x7d/0x970 [kvm]
stack backtrace: CPU: 15 PID: 1071 Comm: repro Not tainted 6.10.0-rc7-332d2c1d713e-next-vm #552 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: <TASK> dump_stack_lvl+0x7f/0x90 lockdep_rcu_suspicious+0x13f/0x1a0 kvm_vcpu_gfn_to_memslot+0x168/0x190 [kvm] kvm_vcpu_read_guest+0x3e/0x90 [kvm] nested_vmx_load_msr+0x6b/0x1d0 [kvm_intel] load_vmcs12_host_state+0x432/0xb40 [kvm_intel] vmx_leave_nested+0x30/0x40 [kvm_intel] kvm_vcpu_ioctl_x86_set_vcpu_events+0x15d/0x2b0 [kvm] kvm_arch_vcpu_ioctl+0x1107/0x1750 [kvm] ? mark_held_locks+0x49/0x70 ? kvm_vcpu_ioctl+0x7d/0x970 [kvm] ? kvm_vcpu_ioctl+0x497/0x970 [kvm] kvm_vcpu_ioctl+0x497/0x970 [kvm] ? lock_acquire+0xba/0x2d0 ? find_held_lock+0x2b/0x80 ? do_user_addr_fault+0x40c/0x6f0 ? lock_release+0xb7/0x270 __x64_sys_ioctl+0x82/0xb0 do_syscall_64+0x6c/0x170 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7ff11eb1b539 </TASK>(CVE-2024-46830)
In the Linux kernel, the following vulnerability has been resolved:
spi: nxp-fspi: fix the KASAN report out-of-bounds bug
Change the memcpy length to fix the out-of-bounds issue when writing the data that is not 4 byte aligned to TX FIFO.
To reproduce the issue, write 3 bytes data to NOR chip.
dd if=3b of=/dev/mtd0 [ 36.926103] ================================================================== [ 36.933409] BUG: KASAN: slab-out-of-bounds in nxp_fspi_exec_op+0x26ec/0x2838 [ 36.940514] Read of size 4 at addr ffff00081037c2a0 by task dd/455 [ 36.946721] [ 36.948235] CPU: 3 UID: 0 PID: 455 Comm: dd Not tainted 6.11.0-rc5-gc7b0e37c8434 #1070 [ 36.956185] Hardware name: Freescale i.MX8QM MEK (DT) [ 36.961260] Call trace: [ 36.963723] dump_backtrace+0x90/0xe8 [ 36.967414] show_stack+0x18/0x24 [ 36.970749] dump_stack_lvl+0x78/0x90 [ 36.974451] print_report+0x114/0x5cc [ 36.978151] kasan_report+0xa4/0xf0 [ 36.981670] __asan_report_load_n_noabort+0x1c/0x28 [ 36.986587] nxp_fspi_exec_op+0x26ec/0x2838 [ 36.990800] spi_mem_exec_op+0x8ec/0xd30 [ 36.994762] spi_mem_no_dirmap_read+0x190/0x1e0 [ 36.999323] spi_mem_dirmap_write+0x238/0x32c [ 37.003710] spi_nor_write_data+0x220/0x374 [ 37.007932] spi_nor_write+0x110/0x2e8 [ 37.011711] mtd_write_oob_std+0x154/0x1f0 [ 37.015838] mtd_write_oob+0x104/0x1d0 [ 37.019617] mtd_write+0xb8/0x12c [ 37.022953] mtdchar_write+0x224/0x47c [ 37.026732] vfs_write+0x1e4/0x8c8 [ 37.030163] ksys_write+0xec/0x1d0 [ 37.033586] __arm64_sys_write+0x6c/0x9c [ 37.037539] invoke_syscall+0x6c/0x258 [ 37.041327] el0_svc_common.constprop.0+0x160/0x22c [ 37.046244] do_el0_svc+0x44/0x5c [ 37.049589] el0_svc+0x38/0x78 [ 37.052681] el0t_64_sync_handler+0x13c/0x158 [ 37.057077] el0t_64_sync+0x190/0x194 [ 37.060775] [ 37.062274] Allocated by task 455: [ 37.065701] kasan_save_stack+0x2c/0x54 [ 37.069570] kasan_save_track+0x20/0x3c [ 37.073438] kasan_save_alloc_info+0x40/0x54 [ 37.077736] __kasan_kmalloc+0xa0/0xb8 [ 37.081515] __kmalloc_noprof+0x158/0x2f8 [ 37.085563] mtd_kmalloc_up_to+0x120/0x154 [ 37.089690] mtdchar_write+0x130/0x47c [ 37.093469] vfs_write+0x1e4/0x8c8 [ 37.096901] ksys_write+0xec/0x1d0 [ 37.100332] __arm64_sys_write+0x6c/0x9c [ 37.104287] invoke_syscall+0x6c/0x258 [ 37.108064] el0_svc_common.constprop.0+0x160/0x22c [ 37.112972] do_el0_svc+0x44/0x5c [ 37.116319] el0_svc+0x38/0x78 [ 37.119401] el0t_64_sync_handler+0x13c/0x158 [ 37.123788] el0t_64_sync+0x190/0x194 [ 37.127474] [ 37.128977] The buggy address belongs to the object at ffff00081037c2a0 [ 37.128977] which belongs to the cache kmalloc-8 of size 8 [ 37.141177] The buggy address is located 0 bytes inside of [ 37.141177] allocated 3-byte region [ffff00081037c2a0, ffff00081037c2a3) [ 37.153465] [ 37.154971] The buggy address belongs to the physical page: [ 37.160559] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x89037c [ 37.168596] flags: 0xbfffe0000000000(node=0|zone=2|lastcpupid=0x1ffff) [ 37.175149] page_type: 0xfdffffff(slab) [ 37.179021] raw: 0bfffe0000000000 ffff000800002500 dead000000000122 0000000000000000 [ 37.186788] raw: 0000000000000000 0000000080800080 00000001fdffffff 0000000000000000 [ 37.194553] page dumped because: kasan: bad access detected [ 37.200144] [ 37.201647] Memory state around the buggy address: [ 37.206460] ffff00081037c180: fa fc fc fc fa fc fc fc fa fc fc fc fa fc fc fc [ 37.213701] ffff00081037c200: fa fc fc fc 05 fc fc fc 03 fc fc fc 02 fc fc fc [ 37.220946] >ffff00081037c280: 06 fc fc fc 03 fc fc fc fc fc fc fc fc fc fc fc [ 37.228186] ^ [ 37.232473] ffff00081037c300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 37.239718] ffff00081037c380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 37.246962] ============================================================== ---truncated---(CVE-2024-46853)
In the Linux kernel, the following vulnerability has been resolved:
PCI: keystone: Add workaround for Errata #i2037 (AM65x SR 1.0)
Errata #i2037 in AM65x/DRA80xM Processors Silicon Revision 1.0 (SPRZ452D_July 2018_Revised December 2019 [1]) mentions when an inbound PCIe TLP spans more than two internal AXI 128-byte bursts, the bus may corrupt the packet payload and the corrupt data may cause associated applications or the processor to hang.
The workaround for Errata #i2037 is to limit the maximum read request size and maximum payload size to 128 bytes. Add workaround for Errata #i2037 here.
The errata and workaround is applicable only to AM65x SR 1.0 and later versions of the silicon will have this fixed.
[1] -> https://www.ti.com/lit/er/sprz452i/sprz452i.pdf(CVE-2024-47667)
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix state management in error path of log writing function
After commit a694291a6211 ("nilfs2: separate wait function from nilfs_segctor_write") was applied, the log writing function nilfs_segctor_do_construct() was able to issue I/O requests continuously even if user data blocks were split into multiple logs across segments, but two potential flaws were introduced in its error handling.
First, if nilfs_segctor_begin_construction() fails while creating the second or subsequent logs, the log writing function returns without calling nilfs_segctor_abort_construction(), so the writeback flag set on pages/folios will remain uncleared. This causes page cache operations to hang waiting for the writeback flag. For example, truncate_inode_pages_final(), which is called via nilfs_evict_inode() when an inode is evicted from memory, will hang.
Second, the NILFS_I_COLLECTED flag set on normal inodes remain uncleared. As a result, if the next log write involves checkpoint creation, that's fine, but if a partial log write is performed that does not, inodes with NILFS_I_COLLECTED set are erroneously removed from the "sc_dirty_files" list, and their data and b-tree blocks may not be written to the device, corrupting the block mapping.
Fix these issues by uniformly calling nilfs_segctor_abort_construction() on failure of each step in the loop in nilfs_segctor_do_construct(), having it clean up logs and segment usages according to progress, and correcting the conditions for calling nilfs_redirty_inodes() to ensure that the NILFS_I_COLLECTED flag is cleared.(CVE-2024-47669)
In the Linux kernel, the following vulnerability has been resolved: tcp: check skb is non-NULL in tcp_rto_delta_us() We have some machines running stock Ubuntu 20.04.6 which is their 5.4.0-174-generic kernel that are running ceph and recently hit a null ptr dereference in tcp_rearm_rto(). Initially hitting it from the TLP path, but then later we also saw it getting hit from the RACK case as well. Here are examples of the oops messages we saw in each of those cases: Jul 26 15:05:02 rx [11061395.780353] BUG: kernel NULL pointer dereference, address: 0000000000000020 Jul 26 15:05:02 rx [11061395.787572] #PF: supervisor read access in kernel mode Jul 26 15:05:02 rx [11061395.792971] #PF: error_code(0x0000) - not-present page Jul 26 15:05:02 rx [11061395.798362] PGD 0 P4D 0 Jul 26 15:05:02 rx [11061395.801164] Oops: 0000 [#1] SMP NOPTI Jul 26 15:05:02 rx [11061395.805091] CPU: 0 PID: 9180 Comm: msgr-worker-1 Tainted: G W 5.4.0-174-generic #193-Ubuntu Jul 26 15:05:02 rx [11061395.814996] Hardware name: Supermicro SMC 2x26 os-gen8 64C NVME-Y 256G/H12SSW-NTR, BIOS 2.5.V1.2U.NVMe.UEFI 05/09/2023 Jul 26 15:05:02 rx [11061395.825952] RIP: 0010:tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.830656] Code: 87 ca 04 00 00 00 5b 41 5c 41 5d 5d c3 c3 49 8b bc 24 40 06 00 00 eb 8d 48 bb cf f7 53 e3 a5 9b c4 20 4c 89 ef e8 0c fe 0e 00 <48> 8b 78 20 48 c1 ef 03 48 89 f8 41 8b bc 24 80 04 00 00 48 f7 e3 Jul 26 15:05:02 rx [11061395.849665] RSP: 0018:ffffb75d40003e08 EFLAGS: 00010246 Jul 26 15:05:02 rx [11061395.855149] RAX: 0000000000000000 RBX: 20c49ba5e353f7cf RCX: 0000000000000000 Jul 26 15:05:02 rx [11061395.862542] RDX: 0000000062177c30 RSI: 000000000000231c RDI: ffff9874ad283a60 Jul 26 15:05:02 rx [11061395.869933] RBP: ffffb75d40003e20 R08: 0000000000000000 R09: ffff987605e20aa8 Jul 26 15:05:02 rx [11061395.877318] R10: ffffb75d40003f00 R11: ffffb75d4460f740 R12: ffff9874ad283900 Jul 26 15:05:02 rx [11061395.884710] R13: ffff9874ad283a60 R14: ffff9874ad283980 R15: ffff9874ad283d30 Jul 26 15:05:02 rx [11061395.892095] FS: 00007f1ef4a2e700(0000) GS:ffff987605e00000(0000) knlGS:0000000000000000 Jul 26 15:05:02 rx [11061395.900438] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Jul 26 15:05:02 rx [11061395.906435] CR2: 0000000000000020 CR3: 0000003e450ba003 CR4: 0000000000760ef0 Jul 26 15:05:02 rx [11061395.913822] PKRU: 55555554 Jul 26 15:05:02 rx [11061395.916786] Call Trace: Jul 26 15:05:02 rx [11061395.919488] Jul 26 15:05:02 rx [11061395.921765] ? show_regs.cold+0x1a/0x1f Jul 26 15:05:02 rx [11061395.925859] ? __die+0x90/0xd9 Jul 26 15:05:02 rx [11061395.929169] ? no_context+0x196/0x380 Jul 26 15:05:02 rx [11061395.933088] ? ip6_protocol_deliver_rcu+0x4e0/0x4e0 Jul 26 15:05:02 rx [11061395.938216] ? ip6_sublist_rcv_finish+0x3d/0x50 Jul 26 15:05:02 rx [11061395.943000] ? __bad_area_nosemaphore+0x50/0x1a0 Jul 26 15:05:02 rx [11061395.947873] ? bad_area_nosemaphore+0x16/0x20 Jul 26 15:05:02 rx [11061395.952486] ? do_user_addr_fault+0x267/0x450 Jul 26 15:05:02 rx [11061395.957104] ? ipv6_list_rcv+0x112/0x140 Jul 26 15:05:02 rx [11061395.961279] ? __do_page_fault+0x58/0x90 Jul 26 15:05:02 rx [11061395.965458] ? do_page_fault+0x2c/0xe0 Jul 26 15:05:02 rx [11061395.969465] ? page_fault+0x34/0x40 Jul 26 15:05:02 rx [11061395.973217] ? tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.977313] ? tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.981408] tcp_send_loss_probe+0x10b/0x220 Jul 26 15:05:02 rx [11061395.985937] tcp_write_timer_handler+0x1b4/0x240 Jul 26 15:05:02 rx [11061395.990809] tcp_write_timer+0x9e/0xe0 Jul 26 15:05:02 rx [11061395.994814] ? tcp_write_timer_handler+0x240/0x240 Jul 26 15:05:02 rx [11061395.999866] call_timer_fn+0x32/0x130 Jul 26 15:05:02 rx [11061396.003782] __run_timers.part.0+0x180/0x280 Jul 26 15:05:02 rx [11061396.008309] ? recalibrate_cpu_khz+0x10/0x10 Jul 26 15:05:02 rx [11061396.012841] ? native_x2apic_icr_write+0x30/0x30 Jul 26 15:05:02 rx [11061396.017718] ? lapic_next_even ---truncated---(CVE-2024-47684)
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_reject_ipv6: fix nf_reject_ip6_tcphdr_put() syzbot reported that nf_reject_ip6_tcphdr_put() was possibly sending garbage on the four reserved tcp bits (th->res1) Use skb_put_zero() to clear the whole TCP header, as done in nf_reject_ip_tcphdr_put() BUG: KMSAN: uninit-value in nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255 nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255 nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344 nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core net/core/dev.c:5661 [inline] __netif_receive_skb+0x1da/0xa00 net/core/dev.c:5775 process_backlog+0x4ad/0xa50 net/core/dev.c:6108 __napi_poll+0xe7/0x980 net/core/dev.c:6772 napi_poll net/core/dev.c:6841 [inline] net_rx_action+0xa5a/0x19b0 net/core/dev.c:6963 handle_softirqs+0x1ce/0x800 kernel/softirq.c:554 __do_softirq+0x14/0x1a kernel/softirq.c:588 do_softirq+0x9a/0x100 kernel/softirq.c:455 __local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:382 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:908 [inline] __dev_queue_xmit+0x2692/0x5610 net/core/dev.c:4450 dev_queue_xmit include/linux/netdevice.h:3105 [inline] neigh_resolve_output+0x9ca/0xae0 net/core/neighbour.c:1565 neigh_output include/net/neighbour.h:542 [inline] ip6_finish_output2+0x2347/0x2ba0 net/ipv6/ip6_output.c:141 __ip6_finish_output net/ipv6/ip6_output.c:215 [inline] ip6_finish_output+0xbb8/0x14b0 net/ipv6/ip6_output.c:226 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip6_output+0x356/0x620 net/ipv6/ip6_output.c:247 dst_output include/net/dst.h:450 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] ip6_xmit+0x1ba6/0x25d0 net/ipv6/ip6_output.c:366 inet6_csk_xmit+0x442/0x530 net/ipv6/inet6_connection_sock.c:135 __tcp_transmit_skb+0x3b07/0x4880 net/ipv4/tcp_output.c:1466 tcp_transmit_skb net/ipv4/tcp_output.c:1484 [inline] tcp_connect+0x35b6/0x7130 net/ipv4/tcp_output.c:4143 tcp_v6_connect+0x1bcc/0x1e40 net/ipv6/tcp_ipv6.c:333 __inet_stream_connect+0x2ef/0x1730 net/ipv4/af_inet.c:679 inet_stream_connect+0x6a/0xd0 net/ipv4/af_inet.c:750 __sys_connect_file net/socket.c:2061 [inline] __sys_connect+0x606/0x690 net/socket.c:2078 __do_sys_connect net/socket.c:2088 [inline] __se_sys_connect net/socket.c:2085 [inline] __x64_sys_connect+0x91/0xe0 net/socket.c:2085 x64_sys_call+0x27a5/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:43 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit was stored to memory at: nf_reject_ip6_tcphdr_put+0x60c/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:249 nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344 nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core ---truncated---(CVE-2024-47685)
In the Linux kernel, the following vulnerability has been resolved: nfsd: return -EINVAL when namelen is 0 When we have a corrupted main.sqlite in /var/lib/nfs/nfsdcld/, it may result in namelen being 0, which will cause memdup_user() to return ZERO_SIZE_PTR. When we access the name.data that has been assigned the value of ZERO_SIZE_PTR in nfs4_client_to_reclaim(), null pointer dereference is triggered. [ T1205] ================================================================== [ T1205] BUG: KASAN: null-ptr-deref in nfs4_client_to_reclaim+0xe9/0x260 [ T1205] Read of size 1 at addr 0000000000000010 by task nfsdcld/1205 [ T1205] [ T1205] CPU: 11 PID: 1205 Comm: nfsdcld Not tainted 5.10.0-00003-g2c1423731b8d #406 [ T1205] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014 [ T1205] Call Trace: [ T1205] dump_stack+0x9a/0xd0 [ T1205] ? nfs4_client_to_reclaim+0xe9/0x260 [ T1205] __kasan_report.cold+0x34/0x84 [ T1205] ? nfs4_client_to_reclaim+0xe9/0x260 [ T1205] kasan_report+0x3a/0x50 [ T1205] nfs4_client_to_reclaim+0xe9/0x260 [ T1205] ? nfsd4_release_lockowner+0x410/0x410 [ T1205] cld_pipe_downcall+0x5ca/0x760 [ T1205] ? nfsd4_cld_tracking_exit+0x1d0/0x1d0 [ T1205] ? down_write_killable_nested+0x170/0x170 [ T1205] ? avc_policy_seqno+0x28/0x40 [ T1205] ? selinux_file_permission+0x1b4/0x1e0 [ T1205] rpc_pipe_write+0x84/0xb0 [ T1205] vfs_write+0x143/0x520 [ T1205] ksys_write+0xc9/0x170 [ T1205] ? __ia32_sys_read+0x50/0x50 [ T1205] ? ktime_get_coarse_real_ts64+0xfe/0x110 [ T1205] ? ktime_get_coarse_real_ts64+0xa2/0x110 [ T1205] do_syscall_64+0x33/0x40 [ T1205] entry_SYSCALL_64_after_hwframe+0x67/0xd1 [ T1205] RIP: 0033:0x7fdbdb761bc7 [ T1205] Code: 0f 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 514 [ T1205] RSP: 002b:00007fff8c4b7248 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ T1205] RAX: ffffffffffffffda RBX: 000000000000042b RCX: 00007fdbdb761bc7 [ T1205] RDX: 000000000000042b RSI: 00007fff8c4b75f0 RDI: 0000000000000008 [ T1205] RBP: 00007fdbdb761bb0 R08: 0000000000000000 R09: 0000000000000001 [ T1205] R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000042b [ T1205] R13: 0000000000000008 R14: 00007fff8c4b75f0 R15: 0000000000000000 [ T1205] ================================================================== Fix it by checking namelen.(CVE-2024-47692)
In the Linux kernel, the following vulnerability has been resolved: RDMA/rtrs-clt: Reset cid to con_num - 1 to stay in bounds In the function init_conns(), after the create_con() and create_cm() for loop if something fails. In the cleanup for loop after the destroy tag, we access out of bound memory because cid is set to clt_path->s.con_num. This commits resets the cid to clt_path->s.con_num - 1, to stay in bounds in the cleanup loop later.(CVE-2024-47695)
In the Linux kernel, the following vulnerability has been resolved: drivers: media: dvb-frontends/rtl2832: fix an out-of-bounds write error Ensure index in rtl2832_pid_filter does not exceed 31 to prevent out-of-bounds access. dev->filters is a 32-bit value, so set_bit and clear_bit functions should only operate on indices from 0 to 31. If index is 32, it will attempt to access a non-existent 33rd bit, leading to out-of-bounds access. Change the boundary check from index > 32 to index >= 32 to resolve this issue. hverkuil: added fixes tag, rtl2830_pid_filter -> rtl2832_pid_filter in logmsg
In the Linux kernel, the following vulnerability has been resolved: can: bcm: Clear bo->bcm_proc_read after remove_proc_entry(). syzbot reported a warning in bcm_release(). [0] The blamed change fixed another warning that is triggered when connect() is issued again for a socket whose connect()ed device has been unregistered. However, if the socket is just close()d without the 2nd connect(), the remaining bo->bcm_proc_read triggers unnecessary remove_proc_entry() in bcm_release(). Let's clear bo->bcm_proc_read after remove_proc_entry() in bcm_notify(). [0] name '4986' WARNING: CPU: 0 PID: 5234 at fs/proc/generic.c:711 remove_proc_entry+0x2e7/0x5d0 fs/proc/generic.c:711 Modules linked in: CPU: 0 UID: 0 PID: 5234 Comm: syz-executor606 Not tainted 6.11.0-rc5-syzkaller-00178-g5517ae241919 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:remove_proc_entry+0x2e7/0x5d0 fs/proc/generic.c:711 Code: ff eb 05 e8 cb 1e 5e ff 48 8b 5c 24 10 48 c7 c7 e0 f7 aa 8e e8 2a 38 8e 09 90 48 c7 c7 60 3a 1b 8c 48 89 de e8 da 42 20 ff 90 <0f> 0b 90 90 48 8b 44 24 18 48 c7 44 24 40 0e 36 e0 45 49 c7 04 07 RSP: 0018:ffffc9000345fa20 EFLAGS: 00010246 RAX: 2a2d0aee2eb64600 RBX: ffff888032f1f548 RCX: ffff888029431e00 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffc9000345fb08 R08: ffffffff8155b2f2 R09: 1ffff1101710519a R10: dffffc0000000000 R11: ffffed101710519b R12: ffff888011d38640 R13: 0000000000000004 R14: 0000000000000000 R15: dffffc0000000000 FS: 0000000000000000(0000) GS:ffff8880b8800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fcfb52722f0 CR3: 000000000e734000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> bcm_release+0x250/0x880 net/can/bcm.c:1578 __sock_release net/socket.c:659 [inline] sock_close+0xbc/0x240 net/socket.c:1421 __fput+0x24a/0x8a0 fs/file_table.c:422 task_work_run+0x24f/0x310 kernel/task_work.c:228 exit_task_work include/linux/task_work.h:40 [inline] do_exit+0xa2f/0x27f0 kernel/exit.c:882 do_group_exit+0x207/0x2c0 kernel/exit.c:1031 __do_sys_exit_group kernel/exit.c:1042 [inline] __se_sys_exit_group kernel/exit.c:1040 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1040 x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fcfb51ee969 Code: Unable to access opcode bytes at 0x7fcfb51ee93f. RSP: 002b:00007ffce0109ca8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007fcfb51ee969 RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000001 RBP: 00007fcfb526f3b0 R08: ffffffffffffffb8 R09: 0000555500000000 R10: 0000555500000000 R11: 0000000000000246 R12: 00007fcfb526f3b0 R13: 0000000000000000 R14: 00007fcfb5271ee0 R15: 00007fcfb51bf160 </TASK>(CVE-2024-47709)
In the Linux kernel, the following vulnerability has been resolved: sock_map: Add a cond_resched() in sock_hash_free() Several syzbot soft lockup reports all have in common sock_hash_free() If a map with a large number of buckets is destroyed, we need to yield the cpu when needed.(CVE-2024-47710)
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for set_output_gamma in dcn30_set_output_transfer_func This commit adds a null check for the set_output_gamma function pointer in the dcn30_set_output_transfer_func function. Previously, set_output_gamma was being checked for nullity at line 386, but then it was being dereferenced without any nullity check at line 401. This could potentially lead to a null pointer dereference error if set_output_gamma is indeed null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a nullity check for set_output_gamma before the call to set_output_gamma at line 401. If set_output_gamma is null, we log an error message and do not call the function. This fix prevents a potential null pointer dereference error. drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:401 dcn30_set_output_transfer_func() error: we previously assumed 'mpc->funcs->set_output_gamma' could be null (see line 386) drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c 373 bool dcn30_set_output_transfer_func(struct dc dc, 374 struct pipe_ctx pipe_ctx, 375 const struct dc_stream_state stream) 376 { 377 int mpcc_id = pipe_ctx->plane_res.hubp->inst; 378 struct mpc mpc = pipe_ctx->stream_res.opp->ctx->dc->res_pool->mpc; 379 const struct pwl_params params = NULL; 380 bool ret = false; 381 382 / program OGAM or 3DLUT only for the top pipe/ 383 if (pipe_ctx->top_pipe == NULL) { 384 /program rmu shaper and 3dlut in MPC/ 385 ret = dcn30_set_mpc_shaper_3dlut(pipe_ctx, stream); 386 if (ret == false && mpc->funcs->set_output_gamma) { ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ If this is NULL 387 if (stream->out_transfer_func.type == TF_TYPE_HWPWL) 388 params = &stream->out_transfer_func.pwl; 389 else if (pipe_ctx->stream->out_transfer_func.type == 390 TF_TYPE_DISTRIBUTED_POINTS && 391 cm3_helper_translate_curve_to_hw_format( 392 &stream->out_transfer_func, 393 &mpc->blender_params, false)) 394 params = &mpc->blender_params; 395 / there are no ROM LUTs in OUTGAM */ 396 if (stream->out_transfer_func.type == TF_TYPE_PREDEFINED) 397 BREAK_TO_DEBUGGER(); 398 } 399 } 400 --> 401 mpc->funcs->set_output_gamma(mpc, mpcc_id, params); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Then it will crash 402 return ret; 403 }(CVE-2024-47720)
In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix spin_unlock_irqrestore() called with IRQs enabled Fix missuse of spin_lock_irq()/spin_unlock_irq() when spin_lock_irqsave()/spin_lock_irqrestore() was hold. This was discovered through the lock debugging, and the corresponding log is as follows: raw_local_irq_restore() called with IRQs enabled WARNING: CPU: 96 PID: 2074 at kernel/locking/irqflag-debug.c:10 warn_bogus_irq_restore+0x30/0x40 ... Call trace: warn_bogus_irq_restore+0x30/0x40 _raw_spin_unlock_irqrestore+0x84/0xc8 add_qp_to_list+0x11c/0x148 [hns_roce_hw_v2] hns_roce_create_qp_common.constprop.0+0x240/0x780 [hns_roce_hw_v2] hns_roce_create_qp+0x98/0x160 [hns_roce_hw_v2] create_qp+0x138/0x258 ib_create_qp_kernel+0x50/0xe8 create_mad_qp+0xa8/0x128 ib_mad_port_open+0x218/0x448 ib_mad_init_device+0x70/0x1f8 add_client_context+0xfc/0x220 enable_device_and_get+0xd0/0x140 ib_register_device.part.0+0xf4/0x1c8 ib_register_device+0x34/0x50 hns_roce_register_device+0x174/0x3d0 [hns_roce_hw_v2] hns_roce_init+0xfc/0x2c0 [hns_roce_hw_v2] __hns_roce_hw_v2_init_instance+0x7c/0x1d0 [hns_roce_hw_v2] hns_roce_hw_v2_init_instance+0x9c/0x180 hns_roce_hw_v2
In the Linux kernel, the following vulnerability has been resolved: nfsd: call cache_put if xdr_reserve_space returns NULL If not enough buffer space available, but idmap_lookup has triggered lookup_fn which calls cache_get and returns successfully. Then we missed to call cache_put here which pairs with cache_get. Reviwed-by: Jeff Layton <jlayton@kernel.org>(CVE-2024-47737)
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential oob read in nilfs_btree_check_delete() The function nilfs_btree_check_delete(), which checks whether degeneration to direct mapping occurs before deleting a b-tree entry, causes memory access outside the block buffer when retrieving the maximum key if the root node has no entries. This does not usually happen because b-tree mappings with 0 child nodes are never created by mkfs.nilfs2 or nilfs2 itself. However, it can happen if the b-tree root node read from a device is configured that way, so fix this potential issue by adding a check for that case.(CVE-2024-47757)
In the Linux kernel, the following vulnerability has been resolved: tracing/timerlat: Fix a race during cpuhp processing There is another found exception that the "timerlat/1" thread was scheduled on CPU0, and lead to timer corruption finally: ODEBUG: init active (active state 0) object: ffff888237c2e108 object type: hrtimer hint: timerlat_irq+0x0/0x220 WARNING: CPU: 0 PID: 426 at lib/debugobjects.c:518 debug_print_object+0x7d/0xb0 Modules linked in: CPU: 0 UID: 0 PID: 426 Comm: timerlat/1 Not tainted 6.11.0-rc7+ #45 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:debug_print_object+0x7d/0xb0 ... Call Trace: <TASK> ? __warn+0x7c/0x110 ? debug_print_object+0x7d/0xb0 ? report_bug+0xf1/0x1d0 ? prb_read_valid+0x17/0x20 ? handle_bug+0x3f/0x70 ? exc_invalid_op+0x13/0x60 ? asm_exc_invalid_op+0x16/0x20 ? debug_print_object+0x7d/0xb0 ? debug_print_object+0x7d/0xb0 ? __pfx_timerlat_irq+0x10/0x10 __debug_object_init+0x110/0x150 hrtimer_init+0x1d/0x60 timerlat_main+0xab/0x2d0 ? __pfx_timerlat_main+0x10/0x10 kthread+0xb7/0xe0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> After tracing the scheduling event, it was discovered that the migration of the "timerlat/1" thread was performed during thread creation. Further analysis confirmed that it is because the CPU online processing for osnoise is implemented through workers, which is asynchronous with the offline processing. When the worker was scheduled to create a thread, the CPU may has already been removed from the cpu_online_mask during the offline process, resulting in the inability to select the right CPU: T1 | T2 [CPUHP_ONLINE] | cpu_device_down() osnoise_hotplug_workfn() | | cpus_write_lock() | takedown_cpu(1) | cpus_write_unlock() [CPUHP_OFFLINE] | cpus_read_lock() | start_kthread(1) | cpus_read_unlock() | To fix this, skip online processing if the CPU is already offline.(CVE-2024-49866)
In the Linux kernel, the following vulnerability has been resolved: btrfs: wait for fixup workers before stopping cleaner kthread during umount During unmount, at close_ctree(), we have the following steps in this order: 1) Park the cleaner kthread - this doesn't destroy the kthread, it basically halts its execution (wake ups against it work but do nothing); 2) We stop the cleaner kthread - this results in freeing the respective struct task_struct; 3) We call btrfs_stop_all_workers() which waits for any jobs running in all the work queues and then free the work queues. Syzbot reported a case where a fixup worker resulted in a crash when doing a delayed iput on its inode while attempting to wake up the cleaner at btrfs_add_delayed_iput(), because the task_struct of the cleaner kthread was already freed. This can happen during unmount because we don't wait for any fixup workers still running before we call kthread_stop() against the cleaner kthread, which stops and free all its resources. Fix this by waiting for any fixup workers at close_ctree() before we call kthread_stop() against the cleaner and run pending delayed iputs. The stack traces reported by syzbot were the following: BUG: KASAN: slab-use-after-free in __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065 Read of size 8 at addr ffff8880272a8a18 by task kworker/u8:3/52 CPU: 1 UID: 0 PID: 52 Comm: kworker/u8:3 Not tainted 6.12.0-rc1-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Workqueue: btrfs-fixup btrfs_work_helper Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0xd5/0x120 kernel/locking/spinlock.c:162 class_raw_spinlock_irqsave_constructor include/linux/spinlock.h:551 [inline] try_to_wake_up+0xb0/0x1480 kernel/sched/core.c:4154 btrfs_writepage_fixup_worker+0xc16/0xdf0 fs/btrfs/inode.c:2842 btrfs_work_helper+0x390/0xc50 fs/btrfs/async-thread.c:314 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa63/0x1850 kernel/workqueue.c:3310 worker_thread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 </TASK> Allocated by task 2: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:319 [inline] __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:345 kasan_slab_alloc include/linux/kasan.h:247 [inline] slab_post_alloc_hook mm/slub.c:4086 [inline] slab_alloc_node mm/slub.c:4135 [inline] kmem_cache_alloc_node_noprof+0x16b/0x320 mm/slub.c:4187 alloc_task_struct_node kernel/fork.c:180 [inline] dup_task_struct+0x57/0x8c0 kernel/fork.c:1107 copy_process+0x5d1/0x3d50 kernel/fork.c:2206 kernel_clone+0x223/0x880 kernel/fork.c:2787 kernel_thread+0x1bc/0x240 kernel/fork.c:2849 create_kthread kernel/kthread.c:412 [inline] kthreadd+0x60d/0x810 kernel/kthread.c:765 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Freed by task 61: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:230 [inline] slab_free_h ---truncated---(CVE-2024-49867)
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix a NULL pointer dereference when failed to start a new trasacntion [BUG] Syzbot reported a NULL pointer dereference with the following crash: FAULT_INJECTION: forcing a failure. start_transaction+0x830/0x1670 fs/btrfs/transaction.c:676 prepare_to_relocate+0x31f/0x4c0 fs/btrfs/relocation.c:3642 relocate_block_group+0x169/0xd20 fs/btrfs/relocation.c:3678 ... BTRFS info (device loop0): balance: ended with status: -12 Oops: general protection fault, probably for non-canonical address 0xdffffc00000000cc: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000660-0x0000000000000667] RIP: 0010:btrfs_update_reloc_root+0x362/0xa80 fs/btrfs/relocation.c:926 Call Trace: <TASK> commit_fs_roots+0x2ee/0x720 fs/btrfs/transaction.c:1496 btrfs_commit_transaction+0xfaf/0x3740 fs/btrfs/transaction.c:2430 del_balance_item fs/btrfs/volumes.c:3678 [inline] reset_balance_state+0x25e/0x3c0 fs/btrfs/volumes.c:3742 btrfs_balance+0xead/0x10c0 fs/btrfs/volumes.c:4574 btrfs_ioctl_balance+0x493/0x7c0 fs/btrfs/ioctl.c:3673 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f [CAUSE] The allocation failure happens at the start_transaction() inside prepare_to_relocate(), and during the error handling we call unset_reloc_control(), which makes fs_info->balance_ctl to be NULL. Then we continue the error path cleanup in btrfs_balance() by calling reset_balance_state() which will call del_balance_item() to fully delete the balance item in the root tree. However during the small window between set_reloc_contrl() and unset_reloc_control(), we can have a subvolume tree update and created a reloc_root for that subvolume. Then we go into the final btrfs_commit_transaction() of del_balance_item(), and into btrfs_update_reloc_root() inside commit_fs_roots(). That function checks if fs_info->reloc_ctl is in the merge_reloc_tree stage, but since fs_info->reloc_ctl is NULL, it results a NULL pointer dereference. [FIX] Just add extra check on fs_info->reloc_ctl inside btrfs_update_reloc_root(), before checking fs_info->reloc_ctl->merge_reloc_tree. That DEAD_RELOC_TREE handling is to prevent further modification to the reloc tree during merge stage, but since there is no reloc_ctl at all, we do not need to bother that.(CVE-2024-49868)
In the Linux kernel, the following vulnerability has been resolved: nfsd: map the EBADMSG to nfserr_io to avoid warning Ext4 will throw -EBADMSG through ext4_readdir when a checksum error occurs, resulting in the following WARNING. Fix it by mapping EBADMSG to nfserr_io. nfsd_buffered_readdir iterate_dir // -EBADMSG -74 ext4_readdir // .iterate_shared ext4_dx_readdir ext4_htree_fill_tree htree_dirblock_to_tree ext4_read_dirblock __ext4_read_dirblock ext4_dirblock_csum_verify warn_no_space_for_csum __warn_no_space_for_csum return ERR_PTR(-EFSBADCRC) // -EBADMSG -74 nfserrno // WARNING [ 161.115610] ------------[ cut here ]------------ [ 161.116465] nfsd: non-standard errno: -74 [ 161.117315] WARNING: CPU: 1 PID: 780 at fs/nfsd/nfsproc.c:878 nfserrno+0x9d/0xd0 [ 161.118596] Modules linked in: [ 161.119243] CPU: 1 PID: 780 Comm: nfsd Not tainted 5.10.0-00014-g79679361fd5d #138 [ 161.120684] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qe mu.org 04/01/2014 [ 161.123601] RIP: 0010:nfserrno+0x9d/0xd0 [ 161.124676] Code: 0f 87 da 30 dd 00 83 e3 01 b8 00 00 00 05 75 d7 44 89 ee 48 c7 c7 c0 57 24 98 89 44 24 04 c6 05 ce 2b 61 03 01 e8 99 20 d8 00 <0f> 0b 8b 44 24 04 eb b5 4c 89 e6 48 c7 c7 a0 6d a4 99 e8 cc 15 33 [ 161.127797] RSP: 0018:ffffc90000e2f9c0 EFLAGS: 00010286 [ 161.128794] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 161.130089] RDX: 1ffff1103ee16f6d RSI: 0000000000000008 RDI: fffff520001c5f2a [ 161.131379] RBP: 0000000000000022 R08: 0000000000000001 R09: ffff8881f70c1827 [ 161.132664] R10: ffffed103ee18304 R11: 0000000000000001 R12: 0000000000000021 [ 161.133949] R13: 00000000ffffffb6 R14: ffff8881317c0000 R15: ffffc90000e2fbd8 [ 161.135244] FS: 0000000000000000(0000) GS:ffff8881f7080000(0000) knlGS:0000000000000000 [ 161.136695] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 161.137761] CR2: 00007fcaad70b348 CR3: 0000000144256006 CR4: 0000000000770ee0 [ 161.139041] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 161.140291] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 161.141519] PKRU: 55555554 [ 161.142076] Call Trace: [ 161.142575] ? __warn+0x9b/0x140 [ 161.143229] ? nfserrno+0x9d/0xd0 [ 161.143872] ? report_bug+0x125/0x150 [ 161.144595] ? handle_bug+0x41/0x90 [ 161.145284] ? exc_invalid_op+0x14/0x70 [ 161.146009] ? asm_exc_invalid_op+0x12/0x20 [ 161.146816] ? nfserrno+0x9d/0xd0 [ 161.147487] nfsd_buffered_readdir+0x28b/0x2b0 [ 161.148333] ? nfsd4_encode_dirent_fattr+0x380/0x380 [ 161.149258] ? nfsd_buffered_filldir+0xf0/0xf0 [ 161.150093] ? wait_for_concurrent_writes+0x170/0x170 [ 161.151004] ? generic_file_llseek_size+0x48/0x160 [ 161.151895] nfsd_readdir+0x132/0x190 [ 161.152606] ? nfsd4_encode_dirent_fattr+0x380/0x380 [ 161.153516] ? nfsd_unlink+0x380/0x380 [ 161.154256] ? override_creds+0x45/0x60 [ 161.155006] nfsd4_encode_readdir+0x21a/0x3d0 [ 161.155850] ? nfsd4_encode_readlink+0x210/0x210 [ 161.156731] ? write_bytes_to_xdr_buf+0x97/0xe0 [ 161.157598] ? __write_bytes_to_xdr_buf+0xd0/0xd0 [ 161.158494] ? lock_downgrade+0x90/0x90 [ 161.159232] ? nfs4svc_decode_voidarg+0x10/0x10 [ 161.160092] nfsd4_encode_operation+0x15a/0x440 [ 161.160959] nfsd4_proc_compound+0x718/0xe90 [ 161.161818] nfsd_dispatch+0x18e/0x2c0 [ 161.162586] svc_process_common+0x786/0xc50 [ 161.163403] ? nfsd_svc+0x380/0x380 [ 161.164137] ? svc_printk+0x160/0x160 [ 161.164846] ? svc_xprt_do_enqueue.part.0+0x365/0x380 [ 161.165808] ? nfsd_svc+0x380/0x380 [ 161.166523] ? rcu_is_watching+0x23/0x40 [ 161.167309] svc_process+0x1a5/0x200 [ 161.168019] nfsd+0x1f5/0x380 [ 161.168663] ? nfsd_shutdown_threads+0x260/0x260 [ 161.169554] kthread+0x1c4/0x210 [ 161.170224] ? kthread_insert_work_sanity_check+0x80/0x80 [ 161.171246] ret_from_fork+0x1f/0x30(CVE-2024-49875)
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Initialize get_bytes_per_element's default to 1 Variables, used as denominators and maybe not assigned to other values, should not be 0. bytes_per_element_y & bytes_per_element_c are initialized by get_bytes_per_element() which should never return 0. This fixes 10 DIVIDE_BY_ZERO issues reported by Coverity.(CVE-2024-49892)
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in degamma hardware format translation Fixes index out of bounds issue in cm_helper_translate_curve_to_degamma_hw_format function. The issue could occur when the index 'i' exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure 'i' is within bounds before accessing the transfer function points. If 'i' is out of bounds the function returns false to indicate an error. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:594 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:595 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:596 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max(CVE-2024-49894)
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in DCN30 degamma hardware format translation This commit addresses a potential index out of bounds issue in the cm3_helper_translate_curve_to_degamma_hw_format function in the DCN30 color management module. The issue could occur when the index 'i' exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure 'i' is within bounds before accessing the transfer function points. If 'i' is out of bounds, the function returns false to indicate an error. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:338 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:339 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:340 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max(CVE-2024-49895)
In the Linux kernel, the following vulnerability has been resolved: jfs: Fix uninit-value access of new_ea in ea_buffer syzbot reports that lzo1x_1_do_compress is using uninit-value: ===================================================== BUG: KMSAN: uninit-value in lzo1x_1_do_compress+0x19f9/0x2510 lib/lzo/lzo1x_compress.c:178 ... Uninit was stored to memory at: ea_put fs/jfs/xattr.c:639 [inline] ... Local variable ea_buf created at: __jfs_setxattr+0x5d/0x1ae0 fs/jfs/xattr.c:662 __jfs_xattr_set+0xe6/0x1f0 fs/jfs/xattr.c:934 ===================================================== The reason is ea_buf->new_ea is not initialized properly. Fix this by using memset to empty its content at the beginning in ea_get().(CVE-2024-49900)
In the Linux kernel, the following vulnerability has been resolved: jfs: check if leafidx greater than num leaves per dmap tree syzbot report a out of bounds in dbSplit, it because dmt_leafidx greater than num leaves per dmap tree, add a checking for dmt_leafidx in dbFindLeaf. Shaggy: Modified sanity check to apply to control pages as well as leaf pages.(CVE-2024-49902)
In the Linux kernel, the following vulnerability has been resolved: jfs: Fix uaf in dbFreeBits [syzbot reported] ================================================================== BUG: KASAN: slab-use-after-free in __mutex_lock_common kernel/locking/mutex.c:587 [inline] BUG: KASAN: slab-use-after-free in __mutex_lock+0xfe/0xd70 kernel/locking/mutex.c:752 Read of size 8 at addr ffff8880229254b0 by task syz-executor357/5216 CPU: 0 UID: 0 PID: 5216 Comm: syz-executor357 Not tainted 6.11.0-rc3-syzkaller-00156-gd7a5aa4b3c00 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 __mutex_lock_common kernel/locking/mutex.c:587 [inline] __mutex_lock+0xfe/0xd70 kernel/locking/mutex.c:752 dbFreeBits+0x7ea/0xd90 fs/jfs/jfs_dmap.c:2390 dbFreeDmap fs/jfs/jfs_dmap.c:2089 [inline] dbFree+0x35b/0x680 fs/jfs/jfs_dmap.c:409 dbDiscardAG+0x8a9/0xa20 fs/jfs/jfs_dmap.c:1650 jfs_ioc_trim+0x433/0x670 fs/jfs/jfs_discard.c:100 jfs_ioctl+0x2d0/0x3e0 fs/jfs/ioctl.c:131 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 Freed by task 5218: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579 poison_slab_object+0xe0/0x150 mm/kasan/common.c:240 __kasan_slab_free+0x37/0x60 mm/kasan/common.c:256 kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2252 [inline] slab_free mm/slub.c:4473 [inline] kfree+0x149/0x360 mm/slub.c:4594 dbUnmount+0x11d/0x190 fs/jfs/jfs_dmap.c:278 jfs_mount_rw+0x4ac/0x6a0 fs/jfs/jfs_mount.c:247 jfs_remount+0x3d1/0x6b0 fs/jfs/super.c:454 reconfigure_super+0x445/0x880 fs/super.c:1083 vfs_cmd_reconfigure fs/fsopen.c:263 [inline] vfs_fsconfig_locked fs/fsopen.c:292 [inline] __do_sys_fsconfig fs/fsopen.c:473 [inline] __se_sys_fsconfig+0xb6e/0xf80 fs/fsopen.c:345 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f [Analysis] There are two paths (dbUnmount and jfs_ioc_trim) that generate race condition when accessing bmap, which leads to the occurrence of uaf. Use the lock s_umount to synchronize them, in order to avoid uaf caused by race condition.(CVE-2024-49903)
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for function pointer in dcn20_set_output_transfer_func This commit adds a null check for the set_output_gamma function pointer in the dcn20_set_output_transfer_func function. Previously, set_output_gamma was being checked for null at line 1030, but then it was being dereferenced without any null check at line 1048. This could potentially lead to a null pointer dereference error if set_output_gamma is null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a null check for set_output_gamma before the call to set_output_gamma at line 1048.(CVE-2024-49911)
In the Linux kernel, the following vulnerability has been resolved: x86/ioapic: Handle allocation failures gracefully Breno observed panics when using failslab under certain conditions during runtime: can not alloc irq_pin_list (-1,0,20) Kernel panic - not syncing: IO-APIC: failed to add irq-pin. Can not proceed panic+0x4e9/0x590 mp_irqdomain_alloc+0x9ab/0xa80 irq_domain_alloc_irqs_locked+0x25d/0x8d0 __irq_domain_alloc_irqs+0x80/0x110 mp_map_pin_to_irq+0x645/0x890 acpi_register_gsi_ioapic+0xe6/0x150 hpet_open+0x313/0x480 That's a pointless panic which is a leftover of the historic IO/APIC code which panic'ed during early boot when the interrupt allocation failed. The only place which might justify panic is the PIT/HPET timer_check() code which tries to figure out whether the timer interrupt is delivered through the IO/APIC. But that code does not require to handle interrupt allocation failures. If the interrupt cannot be allocated then timer delivery fails and it either panics due to that or falls back to legacy mode. Cure this by removing the panic wrapper around __add_pin_to_irq_node() and making mp_irqdomain_alloc() aware of the failure condition and handle it as any other failure in this function gracefully.(CVE-2024-49927)
In the Linux kernel, the following vulnerability has been resolved: jbd2: stop waiting for space when jbd2_cleanup_journal_tail() returns error In __jbd2_log_wait_for_space(), we might call jbd2_cleanup_journal_tail() to recover some journal space. But if an error occurs while executing jbd2_cleanup_journal_tail() (e.g., an EIO), we don't stop waiting for free space right away, we try other branches, and if j_committing_transaction is NULL (i.e., the tid is 0), we will get the following complain: ============================================ JBD2: I/O error when updating journal superblock for sdd-8. __jbd2_log_wait_for_space: needed 256 blocks and only had 217 space available __jbd2_log_wait_for_space: no way to get more journal space in sdd-8 ------------[ cut here ]------------ WARNING: CPU: 2 PID: 139804 at fs/jbd2/checkpoint.c:109 __jbd2_log_wait_for_space+0x251/0x2e0 Modules linked in: CPU: 2 PID: 139804 Comm: kworker/u8:3 Not tainted 6.6.0+ #1 RIP: 0010:__jbd2_log_wait_for_space+0x251/0x2e0 Call Trace: <TASK> add_transaction_credits+0x5d1/0x5e0 start_this_handle+0x1ef/0x6a0 jbd2__journal_start+0x18b/0x340 ext4_dirty_inode+0x5d/0xb0 __mark_inode_dirty+0xe4/0x5d0 generic_update_time+0x60/0x70 [...] ============================================ So only if jbd2_cleanup_journal_tail() returns 1, i.e., there is nothing to clean up at the moment, continue to try to reclaim free space in other ways. Note that this fix relies on commit 6f6a6fda2945 ("jbd2: fix ocfs2 corrupt when updating journal superblock fails") to make jbd2_cleanup_journal_tail return the correct error code.(CVE-2024-49959)
In the Linux kernel, the following vulnerability has been resolved: ocfs2: remove unreasonable unlock in ocfs2_read_blocks Patch series "Misc fixes for ocfs2_read_blocks", v5. This series contains 2 fixes for ocfs2_read_blocks(). The first patch fix the issue reported by syzbot, which detects bad unlock balance in ocfs2_read_blocks(). The second patch fixes an issue reported by Heming Zhao when reviewing above fix. This patch (of 2): There was a lock release before exiting, so remove the unreasonable unlock.(CVE-2024-49965)
In the Linux kernel, the following vulnerability has been resolved: ocfs2: cancel dqi_sync_work before freeing oinfo ocfs2_global_read_info() will initialize and schedule dqi_sync_work at the end, if error occurs after successfully reading global quota, it will trigger the following warning with CONFIG_DEBUG_OBJECTS_* enabled: ODEBUG: free active (active state 0) object: 00000000d8b0ce28 object type: timer_list hint: qsync_work_fn+0x0/0x16c This reports that there is an active delayed work when freeing oinfo in error handling, so cancel dqi_sync_work first. BTW, return status instead of -1 when .read_file_info fails.(CVE-2024-49966)
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in DCN30 color transformation This commit addresses a potential index out of bounds issue in the cm3_helper_translate_curve_to_hw_format function in the DCN30 color management module. The issue could occur when the index 'i' exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure 'i' is within bounds before accessing the transfer function points. If 'i' is out of bounds, the function returns false to indicate an error. drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:180 cm3_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:181 cm3_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:182 cm3_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max(CVE-2024-49969)
In the Linux kernel, the following vulnerability has been resolved: NFSD: Limit the number of concurrent async COPY operations Nothing appears to limit the number of concurrent async COPY operations that clients can start. In addition, AFAICT each async COPY can copy an unlimited number of 4MB chunks, so can run for a long time. Thus IMO async COPY can become a DoS vector. Add a restriction mechanism that bounds the number of concurrent background COPY operations. Start simple and try to be fair -- this patch implements a per-namespace limit. An async COPY request that occurs while this limit is exceeded gets NFS4ERR_DELAY. The requesting client can choose to send the request again after a delay or fall back to a traditional read/write style copy. If there is need to make the mechanism more sophisticated, we can visit that in future patches.(CVE-2024-49974)
In the Linux kernel, the following vulnerability has been resolved: i2c: stm32f7: Do not prepare/unprepare clock during runtime suspend/resume In case there is any sort of clock controller attached to this I2C bus controller, for example Versaclock or even an AIC32x4 I2C codec, then an I2C transfer triggered from the clock controller clk_ops .prepare callback may trigger a deadlock on drivers/clk/clk.c prepare_lock mutex. This is because the clock controller first grabs the prepare_lock mutex and then performs the prepare operation, including its I2C access. The I2C access resumes this I2C bus controller via .runtime_resume callback, which calls clk_prepare_enable(), which attempts to grab the prepare_lock mutex again and deadlocks. Since the clock are already prepared since probe() and unprepared in remove(), use simple clk_enable()/clk_disable() calls to enable and disable the clock on runtime suspend and resume, to avoid hitting the prepare_lock mutex.(CVE-2024-49985)
In the Linux kernel, the following vulnerability has been resolved: scsi: fnic: Move flush_work initialization out of if block After commit 379a58caa199 ("scsi: fnic: Move fnic_fnic_flush_tx() to a work queue"), it can happen that a work item is sent to an uninitialized work queue. This may has the effect that the item being queued is never actually queued, and any further actions depending on it will not proceed. The following warning is observed while the fnic driver is loaded: kernel: WARNING: CPU: 11 PID: 0 at ../kernel/workqueue.c:1524 __queue_work+0x373/0x410 kernel: <IRQ> kernel: queue_work_on+0x3a/0x50 kernel: fnic_wq_copy_cmpl_handler+0x54a/0x730 [fnic 62fbff0c42e7fb825c60a55cde2fb91facb2ed24] kernel: fnic_isr_msix_wq_copy+0x2d/0x60 [fnic 62fbff0c42e7fb825c60a55cde2fb91facb2ed24] kernel: __handle_irq_event_percpu+0x36/0x1a0 kernel: handle_irq_event_percpu+0x30/0x70 kernel: handle_irq_event+0x34/0x60 kernel: handle_edge_irq+0x7e/0x1a0 kernel: __common_interrupt+0x3b/0xb0 kernel: common_interrupt+0x58/0xa0 kernel: </IRQ> It has been observed that this may break the rediscovery of Fibre Channel devices after a temporary fabric failure. This patch fixes it by moving the work queue initialization out of an if block in fnic_probe().(CVE-2024-50025)
In the Linux kernel, the following vulnerability has been resolved: net: do not delay dst_entries_add() in dst_release() dst_entries_add() uses per-cpu data that might be freed at netns dismantle from ip6_route_net_exit() calling dst_entries_destroy() Before ip6_route_net_exit() can be called, we release all the dsts associated with this netns, via calls to dst_release(), which waits an rcu grace period before calling dst_destroy() dst_entries_add() use in dst_destroy() is racy, because dst_entries_destroy() could have been called already. Decrementing the number of dsts must happen sooner. Notes: 1) in CONFIG_XFRM case, dst_destroy() can call dst_release_immediate(child), this might also cause UAF if the child does not have DST_NOCOUNT set. IPSEC maintainers might take a look and see how to address this. 2) There is also discussion about removing this count of dst, which might happen in future kernels.(CVE-2024-50036)
In the Linux kernel, the following vulnerability has been resolved: NFSv4: Prevent NULL-pointer dereference in nfs42_complete_copies() On the node of an NFS client, some files saved in the mountpoint of the NFS server were copied to another location of the same NFS server. Accidentally, the nfs42_complete_copies() got a NULL-pointer dereference crash with the following syslog: [232064.838881] NFSv4: state recovery failed for open file nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116 [232064.839360] NFSv4: state recovery failed for open file nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116 [232066.588183] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000058 [232066.588586] Mem abort info: [232066.588701] ESR = 0x0000000096000007 [232066.588862] EC = 0x25: DABT (current EL), IL = 32 bits [232066.589084] SET = 0, FnV = 0 [232066.589216] EA = 0, S1PTW = 0 [232066.589340] FSC = 0x07: level 3 translation fault [232066.589559] Data abort info: [232066.589683] ISV = 0, ISS = 0x00000007 [232066.589842] CM = 0, WnR = 0 [232066.589967] user pgtable: 64k pages, 48-bit VAs, pgdp=00002000956ff400 [232066.590231] [0000000000000058] pgd=08001100ae100003, p4d=08001100ae100003, pud=08001100ae100003, pmd=08001100b3c00003, pte=0000000000000000 [232066.590757] Internal error: Oops: 96000007 [#1] SMP [232066.590958] Modules linked in: rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm vhost_net vhost vhost_iotlb tap tun ipt_rpfilter xt_multiport ip_set_hash_ip ip_set_hash_net xfrm_interface xfrm6_tunnel tunnel4 tunnel6 esp4 ah4 wireguard libcurve25519_generic veth xt_addrtype xt_set nf_conntrack_netlink ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_bitmap_port ip_set_hash_ipport dummy ip_set ip_vs_sh ip_vs_wrr ip_vs_rr ip_vs iptable_filter sch_ingress nfnetlink_cttimeout vport_gre ip_gre ip_tunnel gre vport_geneve geneve vport_vxlan vxlan ip6_udp_tunnel udp_tunnel openvswitch nf_conncount dm_round_robin dm_service_time dm_multipath xt_nat xt_MASQUERADE nft_chain_nat nf_nat xt_mark xt_conntrack xt_comment nft_compat nft_counter nf_tables nfnetlink ocfs2 ocfs2_nodemanager ocfs2_stackglue iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ipmi_ssif nbd overlay 8021q garp mrp bonding tls rfkill sunrpc ext4 mbcache jbd2 [232066.591052] vfat fat cas_cache cas_disk ses enclosure scsi_transport_sas sg acpi_ipmi ipmi_si ipmi_devintf ipmi_msghandler ip_tables vfio_pci vfio_pci_core vfio_virqfd vfio_iommu_type1 vfio dm_mirror dm_region_hash dm_log dm_mod nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter bridge stp llc fuse xfs libcrc32c ast drm_vram_helper qla2xxx drm_kms_helper syscopyarea crct10dif_ce sysfillrect ghash_ce sysimgblt sha2_ce fb_sys_fops cec sha256_arm64 sha1_ce drm_ttm_helper ttm nvme_fc igb sbsa_gwdt nvme_fabrics drm nvme_core i2c_algo_bit i40e scsi_transport_fc megaraid_sas aes_neon_bs [232066.596953] CPU: 6 PID: 4124696 Comm: 10.253.166.125- Kdump: loaded Not tainted 5.15.131-9.cl9_ocfs2.aarch64 #1 [232066.597356] Hardware name: Great Wall .\x93\x8e...RF6260 V5/GWMSSE2GL1T, BIOS T656FBE_V3.0.18 2024-01-06 [232066.597721] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [232066.598034] pc : nfs4_reclaim_open_state+0x220/0x800 [nfsv4] [232066.598327] lr : nfs4_reclaim_open_state+0x12c/0x800 [nfsv4] [232066.598595] sp : ffff8000f568fc70 [232066.598731] x29: ffff8000f568fc70 x28: 0000000000001000 x27: ffff21003db33000 [232066.599030] x26: ffff800005521ae0 x25: ffff0100f98fa3f0 x24: 0000000000000001 [232066.599319] x23: ffff800009920008 x22: ffff21003db33040 x21: ffff21003db33050 [232066.599628] x20: ffff410172fe9e40 x19: ffff410172fe9e00 x18: 0000000000000000 [232066.599914] x17: 0000000000000000 x16: 0000000000000004 x15: 0000000000000000 [232066.600195] x14: 0000000000000000 x13: ffff800008e685a8 x12: 00000000eac0c6e6 [232066.600498] x11: 00000000000000 ---truncated---(CVE-2024-50046)
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointer before dereferencing se [WHAT & HOW] se is null checked previously in the same function, indicating it might be null; therefore, it must be checked when used again. This fixes 1 FORWARD_NULL issue reported by Coverity.(CVE-2024-50049)
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-5.10.0-234.0.0.133.oe2203sp4.aarch64.rpm",
"bpftool-debuginfo-5.10.0-234.0.0.133.oe2203sp4.aarch64.rpm",
"kernel-5.10.0-234.0.0.133.oe2203sp4.aarch64.rpm",
"kernel-debuginfo-5.10.0-234.0.0.133.oe2203sp4.aarch64.rpm",
"kernel-debugsource-5.10.0-234.0.0.133.oe2203sp4.aarch64.rpm",
"kernel-devel-5.10.0-234.0.0.133.oe2203sp4.aarch64.rpm",
"kernel-headers-5.10.0-234.0.0.133.oe2203sp4.aarch64.rpm",
"kernel-source-5.10.0-234.0.0.133.oe2203sp4.aarch64.rpm",
"kernel-tools-5.10.0-234.0.0.133.oe2203sp4.aarch64.rpm",
"kernel-tools-debuginfo-5.10.0-234.0.0.133.oe2203sp4.aarch64.rpm",
"kernel-tools-devel-5.10.0-234.0.0.133.oe2203sp4.aarch64.rpm",
"perf-5.10.0-234.0.0.133.oe2203sp4.aarch64.rpm",
"perf-debuginfo-5.10.0-234.0.0.133.oe2203sp4.aarch64.rpm",
"python3-perf-5.10.0-234.0.0.133.oe2203sp4.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-234.0.0.133.oe2203sp4.aarch64.rpm"
],
"src": [
"kernel-5.10.0-234.0.0.133.oe2203sp4.src.rpm"
],
"x86_64": [
"bpftool-5.10.0-234.0.0.133.oe2203sp4.x86_64.rpm",
"bpftool-debuginfo-5.10.0-234.0.0.133.oe2203sp4.x86_64.rpm",
"kernel-5.10.0-234.0.0.133.oe2203sp4.x86_64.rpm",
"kernel-debuginfo-5.10.0-234.0.0.133.oe2203sp4.x86_64.rpm",
"kernel-debugsource-5.10.0-234.0.0.133.oe2203sp4.x86_64.rpm",
"kernel-devel-5.10.0-234.0.0.133.oe2203sp4.x86_64.rpm",
"kernel-headers-5.10.0-234.0.0.133.oe2203sp4.x86_64.rpm",
"kernel-source-5.10.0-234.0.0.133.oe2203sp4.x86_64.rpm",
"kernel-tools-5.10.0-234.0.0.133.oe2203sp4.x86_64.rpm",
"kernel-tools-debuginfo-5.10.0-234.0.0.133.oe2203sp4.x86_64.rpm",
"kernel-tools-devel-5.10.0-234.0.0.133.oe2203sp4.x86_64.rpm",
"perf-5.10.0-234.0.0.133.oe2203sp4.x86_64.rpm",
"perf-debuginfo-5.10.0-234.0.0.133.oe2203sp4.x86_64.rpm",
"python3-perf-5.10.0-234.0.0.133.oe2203sp4.x86_64.rpm",
"python3-perf-debuginfo-5.10.0-234.0.0.133.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-234.0.0.133.oe2203sp4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "Critical"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\niommu/vt-d: Fix double list_add when enabling VMD in scalable mode\r\n\r\nWhen enabling VMD and IOMMU scalable mode, the following kernel panic\ncall trace/kernel log is shown in Eagle Stream platform (Sapphire Rapids\nCPU) during booting:\r\n\r\npci 0000:59:00.5: Adding to iommu group 42\n...\nvmd 0000:59:00.5: PCI host bridge to bus 10000:80\npci 10000:80:01.0: [8086:352a] type 01 class 0x060400\npci 10000:80:01.0: reg 0x10: [mem 0x00000000-0x0001ffff 64bit]\npci 10000:80:01.0: enabling Extended Tags\npci 10000:80:01.0: PME# supported from D0 D3hot D3cold\npci 10000:80:01.0: DMAR: Setup RID2PASID failed\npci 10000:80:01.0: Failed to add to iommu group 42: -16\npci 10000:80:03.0: [8086:352b] type 01 class 0x060400\npci 10000:80:03.0: reg 0x10: [mem 0x00000000-0x0001ffff 64bit]\npci 10000:80:03.0: enabling Extended Tags\npci 10000:80:03.0: PME# supported from D0 D3hot D3cold\n------------[ cut here ]------------\nkernel BUG at lib/list_debug.c:29!\ninvalid opcode: 0000 [#1] PREEMPT SMP NOPTI\nCPU: 0 PID: 7 Comm: kworker/0:1 Not tainted 5.17.0-rc3+ #7\nHardware name: Lenovo ThinkSystem SR650V3/SB27A86647, BIOS ESE101Y-1.00 01/13/2022\nWorkqueue: events work_for_cpu_fn\nRIP: 0010:__list_add_valid.cold+0x26/0x3f\nCode: 9a 4a ab ff 4c 89 c1 48 c7 c7 40 0c d9 9e e8 b9 b1 fe ff 0f\n 0b 48 89 f2 4c 89 c1 48 89 fe 48 c7 c7 f0 0c d9 9e e8 a2 b1\n fe ff \u0026lt;0f\u0026gt; 0b 48 89 d1 4c 89 c6 4c 89 ca 48 c7 c7 98 0c d9\n 9e e8 8b b1 fe\nRSP: 0000:ff5ad434865b3a40 EFLAGS: 00010246\nRAX: 0000000000000058 RBX: ff4d61160b74b880 RCX: ff4d61255e1fffa8\nRDX: 0000000000000000 RSI: 00000000fffeffff RDI: ffffffff9fd34f20\nRBP: ff4d611d8e245c00 R08: 0000000000000000 R09: ff5ad434865b3888\nR10: ff5ad434865b3880 R11: ff4d61257fdc6fe8 R12: ff4d61160b74b8a0\nR13: ff4d61160b74b8a0 R14: ff4d611d8e245c10 R15: ff4d611d8001ba70\nFS: 0000000000000000(0000) GS:ff4d611d5ea00000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: ff4d611fa1401000 CR3: 0000000aa0210001 CR4: 0000000000771ef0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400\nPKRU: 55555554\nCall Trace:\n \u0026lt;TASK\u0026gt;\n intel_pasid_alloc_table+0x9c/0x1d0\n dmar_insert_one_dev_info+0x423/0x540\n ? device_to_iommu+0x12d/0x2f0\n intel_iommu_attach_device+0x116/0x290\n __iommu_attach_device+0x1a/0x90\n iommu_group_add_device+0x190/0x2c0\n __iommu_probe_device+0x13e/0x250\n iommu_probe_device+0x24/0x150\n iommu_bus_notifier+0x69/0x90\n blocking_notifier_call_chain+0x5a/0x80\n device_add+0x3db/0x7b0\n ? arch_memremap_can_ram_remap+0x19/0x50\n ? memremap+0x75/0x140\n pci_device_add+0x193/0x1d0\n pci_scan_single_device+0xb9/0xf0\n pci_scan_slot+0x4c/0x110\n pci_scan_child_bus_extend+0x3a/0x290\n vmd_enable_domain.constprop.0+0x63e/0x820\n vmd_probe+0x163/0x190\n local_pci_probe+0x42/0x80\n work_for_cpu_fn+0x13/0x20\n process_one_work+0x1e2/0x3b0\n worker_thread+0x1c4/0x3a0\n ? rescuer_thread+0x370/0x370\n kthread+0xc7/0xf0\n ? kthread_complete_and_exit+0x20/0x20\n ret_from_fork+0x1f/0x30\n \u0026lt;/TASK\u0026gt;\nModules linked in:\n---[ end trace 0000000000000000 ]---\n...\nKernel panic - not syncing: Fatal exception\nKernel Offset: 0x1ca00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)\n---[ end Kernel panic - not syncing: Fatal exception ]---\r\n\r\nThe following \u0026apos;lspci\u0026apos; output shows devices \u0026apos;10000:80:*\u0026apos; are subdevices of\nthe VMD device 0000:59:00.5:\r\n\r\n $ lspci\n ...\n 0000:59:00.5 RAID bus controller: Intel Corporation Volume Management Device NVMe RAID Controller (rev 20)\n ...\n 10000:80:01.0 PCI bridge: Intel Corporation Device 352a (rev 03)\n 10000:80:03.0 PCI bridge: Intel Corporation Device 352b (rev 03)\n 10000:80:05.0 PCI bridge: Intel Corporation Device 352c (rev 03)\n 10000:80:07.0 PCI bridge: Intel Corporation Device 352d (rev 03)\n 10000:81:00.0 Non-Volatile memory controller: Intel Corporation NVMe Datacenter SSD [3DNAND, Beta Rock Controller]\n 10000:82:00\n---truncated---(CVE-2022-48916)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: PCI: mt7621: Add sentinel to quirks table Current driver is missing a sentinel in the struct soc_device_attribute array, which causes an oops when assessed by the soc_device_match(mt7621_pcie_quirks_match) call. This was only exposed once the CONFIG_SOC_MT7621 mt7621 soc_dev_attr was fixed to register the SOC as a device, in: commit 7c18b64bba3b (\u0026quot;mips: ralink: mt7621: do not use kzalloc too early\u0026quot;) Fix it by adding the required sentinel.(CVE-2022-48952)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: ntb: intel: Fix the NULL vs IS_ERR() bug for debugfs_create_dir() The debugfs_create_dir() function returns error pointers. It never returns NULL. So use IS_ERR() to check it.(CVE-2023-52917)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: media: pci: cx23885: check cx23885_vdev_init() return cx23885_vdev_init() can return a NULL pointer, but that pointer is used in the next line without a check. Add a NULL pointer check and go to the error unwind if it is NULL.(CVE-2023-52918)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nof: module: prevent NULL pointer dereference in vsnprintf()\r\n\r\nIn of_modalias(), we can get passed the str and len parameters which would\ncause a kernel oops in vsnprintf() since it only allows passing a NULL ptr\nwhen the length is also 0. Also, we need to filter out the negative values\nof the len parameter as these will result in a really huge buffer since\nsnprintf() takes size_t parameter while ours is ssize_t...\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with the Svace static\nanalysis tool.(CVE-2024-35878)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndma: xilinx_dpdma: Fix locking\r\n\r\nThere are several places where either chan-\u0026gt;lock or chan-\u0026gt;vchan.lock was\nnot held. Add appropriate locking. This fixes lockdep warnings like\r\n\r\n[ 31.077578] ------------[ cut here ]------------\n[ 31.077831] WARNING: CPU: 2 PID: 40 at drivers/dma/xilinx/xilinx_dpdma.c:834 xilinx_dpdma_chan_queue_transfer+0x274/0x5e0\n[ 31.077953] Modules linked in:\n[ 31.078019] CPU: 2 PID: 40 Comm: kworker/u12:1 Not tainted 6.6.20+ #98\n[ 31.078102] Hardware name: xlnx,zynqmp (DT)\n[ 31.078169] Workqueue: events_unbound deferred_probe_work_func\n[ 31.078272] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[ 31.078377] pc : xilinx_dpdma_chan_queue_transfer+0x274/0x5e0\n[ 31.078473] lr : xilinx_dpdma_chan_queue_transfer+0x270/0x5e0\n[ 31.078550] sp : ffffffc083bb2e10\n[ 31.078590] x29: ffffffc083bb2e10 x28: 0000000000000000 x27: ffffff880165a168\n[ 31.078754] x26: ffffff880164e920 x25: ffffff880164eab8 x24: ffffff880164d480\n[ 31.078920] x23: ffffff880165a148 x22: ffffff880164e988 x21: 0000000000000000\n[ 31.079132] x20: ffffffc082aa3000 x19: ffffff880164e880 x18: 0000000000000000\n[ 31.079295] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000\n[ 31.079453] x14: 0000000000000000 x13: ffffff8802263dc0 x12: 0000000000000001\n[ 31.079613] x11: 0001ffc083bb2e34 x10: 0001ff880164e98f x9 : 0001ffc082aa3def\n[ 31.079824] x8 : 0001ffc082aa3dec x7 : 0000000000000000 x6 : 0000000000000516\n[ 31.079982] x5 : ffffffc7f8d43000 x4 : ffffff88003c9c40 x3 : ffffffffffffffff\n[ 31.080147] x2 : ffffffc7f8d43000 x1 : 00000000000000c0 x0 : 0000000000000000\n[ 31.080307] Call trace:\n[ 31.080340] xilinx_dpdma_chan_queue_transfer+0x274/0x5e0\n[ 31.080518] xilinx_dpdma_issue_pending+0x11c/0x120\n[ 31.080595] zynqmp_disp_layer_update+0x180/0x3ac\n[ 31.080712] zynqmp_dpsub_plane_atomic_update+0x11c/0x21c\n[ 31.080825] drm_atomic_helper_commit_planes+0x20c/0x684\n[ 31.080951] drm_atomic_helper_commit_tail+0x5c/0xb0\n[ 31.081139] commit_tail+0x234/0x294\n[ 31.081246] drm_atomic_helper_commit+0x1f8/0x210\n[ 31.081363] drm_atomic_commit+0x100/0x140\n[ 31.081477] drm_client_modeset_commit_atomic+0x318/0x384\n[ 31.081634] drm_client_modeset_commit_locked+0x8c/0x24c\n[ 31.081725] drm_client_modeset_commit+0x34/0x5c\n[ 31.081812] __drm_fb_helper_restore_fbdev_mode_unlocked+0x104/0x168\n[ 31.081899] drm_fb_helper_set_par+0x50/0x70\n[ 31.081971] fbcon_init+0x538/0xc48\n[ 31.082047] visual_init+0x16c/0x23c\n[ 31.082207] do_bind_con_driver.isra.0+0x2d0/0x634\n[ 31.082320] do_take_over_console+0x24c/0x33c\n[ 31.082429] do_fbcon_takeover+0xbc/0x1b0\n[ 31.082503] fbcon_fb_registered+0x2d0/0x34c\n[ 31.082663] register_framebuffer+0x27c/0x38c\n[ 31.082767] __drm_fb_helper_initial_config_and_unlock+0x5c0/0x91c\n[ 31.082939] drm_fb_helper_initial_config+0x50/0x74\n[ 31.083012] drm_fbdev_dma_client_hotplug+0xb8/0x108\n[ 31.083115] drm_client_register+0xa0/0xf4\n[ 31.083195] drm_fbdev_dma_setup+0xb0/0x1cc\n[ 31.083293] zynqmp_dpsub_drm_init+0x45c/0x4e0\n[ 31.083431] zynqmp_dpsub_probe+0x444/0x5e0\n[ 31.083616] platform_probe+0x8c/0x13c\n[ 31.083713] really_probe+0x258/0x59c\n[ 31.083793] __driver_probe_device+0xc4/0x224\n[ 31.083878] driver_probe_device+0x70/0x1c0\n[ 31.083961] __device_attach_driver+0x108/0x1e0\n[ 31.084052] bus_for_each_drv+0x9c/0x100\n[ 31.084125] __device_attach+0x100/0x298\n[ 31.084207] device_initial_probe+0x14/0x20\n[ 31.084292] bus_probe_device+0xd8/0xdc\n[ 31.084368] deferred_probe_work_func+0x11c/0x180\n[ 31.084451] process_one_work+0x3ac/0x988\n[ 31.084643] worker_thread+0x398/0x694\n[ 31.084752] kthread+0x1bc/0x1c0\n[ 31.084848] ret_from_fork+0x10/0x20\n[ 31.084932] irq event stamp: 64549\n[ 31.084970] hardirqs last enabled at (64548): [\u0026lt;ffffffc081adf35c\u0026gt;] _raw_spin_unlock_irqrestore+0x80/0x90\n[ 31.085157]\n---truncated---(CVE-2024-35990)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nfnetlink_queue: acquire rcu_read_lock() in instance_destroy_rcu()\r\n\r\nsyzbot reported that nf_reinject() could be called without rcu_read_lock() :\r\n\r\nWARNING: suspicious RCU usage\n6.9.0-rc7-syzkaller-02060-g5c1672705a1a #0 Not tainted\r\n\r\nnet/netfilter/nfnetlink_queue.c:263 suspicious rcu_dereference_check() usage!\r\n\r\nother info that might help us debug this:\r\n\r\nrcu_scheduler_active = 2, debug_locks = 1\n2 locks held by syz-executor.4/13427:\n #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_lock_acquire include/linux/rcupdate.h:329 [inline]\n #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_do_batch kernel/rcu/tree.c:2190 [inline]\n #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_core+0xa86/0x1830 kernel/rcu/tree.c:2471\n #1: ffff88801ca92958 (\u0026amp;inst-\u0026gt;lock){+.-.}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline]\n #1: ffff88801ca92958 (\u0026amp;inst-\u0026gt;lock){+.-.}-{2:2}, at: nfqnl_flush net/netfilter/nfnetlink_queue.c:405 [inline]\n #1: ffff88801ca92958 (\u0026amp;inst-\u0026gt;lock){+.-.}-{2:2}, at: instance_destroy_rcu+0x30/0x220 net/netfilter/nfnetlink_queue.c:172\r\n\r\nstack backtrace:\nCPU: 0 PID: 13427 Comm: syz-executor.4 Not tainted 6.9.0-rc7-syzkaller-02060-g5c1672705a1a #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024\nCall Trace:\n \u0026lt;IRQ\u0026gt;\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114\n lockdep_rcu_suspicious+0x221/0x340 kernel/locking/lockdep.c:6712\n nf_reinject net/netfilter/nfnetlink_queue.c:323 [inline]\n nfqnl_reinject+0x6ec/0x1120 net/netfilter/nfnetlink_queue.c:397\n nfqnl_flush net/netfilter/nfnetlink_queue.c:410 [inline]\n instance_destroy_rcu+0x1ae/0x220 net/netfilter/nfnetlink_queue.c:172\n rcu_do_batch kernel/rcu/tree.c:2196 [inline]\n rcu_core+0xafd/0x1830 kernel/rcu/tree.c:2471\n handle_softirqs+0x2d6/0x990 kernel/softirq.c:554\n __do_softirq kernel/softirq.c:588 [inline]\n invoke_softirq kernel/softirq.c:428 [inline]\n __irq_exit_rcu+0xf4/0x1c0 kernel/softirq.c:637\n irq_exit_rcu+0x9/0x30 kernel/softirq.c:649\n instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1043 [inline]\n sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1043\n \u0026lt;/IRQ\u0026gt;\n \u0026lt;TASK\u0026gt;(CVE-2024-36286)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nALSA: core: Fix NULL module pointer assignment at card init\r\n\r\nThe commit 81033c6b584b (\u0026quot;ALSA: core: Warn on empty module\u0026quot;)\nintroduced a WARN_ON() for a NULL module pointer passed at snd_card\nobject creation, and it also wraps the code around it with \u0026apos;#ifdef\nMODULE\u0026apos;. This works in most cases, but the devils are always in\ndetails. \u0026quot;MODULE\u0026quot; is defined when the target code (i.e. the sound\ncore) is built as a module; but this doesn\u0026apos;t mean that the caller is\nalso built-in or not. Namely, when only the sound core is built-in\n(CONFIG_SND=y) while the driver is a module (CONFIG_SND_USB_AUDIO=m),\nthe passed module pointer is ignored even if it\u0026apos;s non-NULL, and\ncard-\u0026gt;module remains as NULL. This would result in the missing module\nreference up/down at the device open/close, leading to a race with the\ncode execution after the module removal.\r\n\r\nFor addressing the bug, move the assignment of card-\u0026gt;module again out\nof ifdef. The WARN_ON() is still wrapped with ifdef because the\nmodule can be really NULL when all sound drivers are built-in.\r\n\r\nNote that we keep \u0026apos;ifdef MODULE\u0026apos; for WARN_ON(), otherwise it would\nlead to a false-positive NULL module check. Admittedly it won\u0026apos;t catch\nperfectly, i.e. no check is performed when CONFIG_SND=y. But, it\u0026apos;s no\nreal problem as it\u0026apos;s only for debugging, and the condition is pretty\nrare.(CVE-2024-38605)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsoundwire: cadence: fix invalid PDI offset\r\n\r\nFor some reason, we add an offset to the PDI, presumably to skip the\nPDI0 and PDI1 which are reserved for BPT.\r\n\r\nThis code is however completely wrong and leads to an out-of-bounds\naccess. We were just lucky so far since we used only a couple of PDIs\nand remained within the PDI array bounds.\r\n\r\nA Fixes: tag is not provided since there are no known platforms where\nthe out-of-bounds would be accessed, and the initial code had problems\nas well.\r\n\r\nA follow-up patch completely removes this useless offset.(CVE-2024-38635)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nriscv: prevent pt_regs corruption for secondary idle threads\r\n\r\nTop of the kernel thread stack should be reserved for pt_regs. However\nthis is not the case for the idle threads of the secondary boot harts.\nTheir stacks overlap with their pt_regs, so both may get corrupted.\r\n\r\nSimilar issue has been fixed for the primary hart, see c7cdd96eca28\n(\u0026quot;riscv: prevent stack corruption by reserving task_pt_regs(p) early\u0026quot;).\nHowever that fix was not propagated to the secondary harts. The problem\nhas been noticed in some CPU hotplug tests with V enabled. The function\nsmp_callin stored several registers on stack, corrupting top of pt_regs\nstructure including status field. As a result, kernel attempted to save\nor restore inexistent V context.(CVE-2024-38667)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnvmet: fix a possible leak when destroy a ctrl during qp establishment\r\n\r\nIn nvmet_sq_destroy we capture sq-\u0026gt;ctrl early and if it is non-NULL we\nknow that a ctrl was allocated (in the admin connect request handler)\nand we need to release pending AERs, clear ctrl-\u0026gt;sqs and sq-\u0026gt;ctrl\n(for nvme-loop primarily), and drop the final reference on the ctrl.\r\n\r\nHowever, a small window is possible where nvmet_sq_destroy starts (as\na result of the client giving up and disconnecting) concurrently with\nthe nvme admin connect cmd (which may be in an early stage). But *before*\nkill_and_confirm of sq-\u0026gt;ref (i.e. the admin connect managed to get an sq\nlive reference). In this case, sq-\u0026gt;ctrl was allocated however after it was\ncaptured in a local variable in nvmet_sq_destroy.\nThis prevented the final reference drop on the ctrl.\r\n\r\nSolve this by re-capturing the sq-\u0026gt;ctrl after all inflight request has\ncompleted, where for sure sq-\u0026gt;ctrl reference is final, and move forward\nbased on that.\r\n\r\nThis issue was observed in an environment with many hosts connecting\nmultiple ctrls simoutanuosly, creating a delay in allocating a ctrl\nleading up to this race window.(CVE-2024-42152)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndev/parport: fix the array out-of-bounds risk\r\n\r\nFixed array out-of-bounds issues caused by sprintf\nby replacing it with snprintf for safer data copying,\nensuring the destination buffer is not overflowed.\r\n\r\nBelow is the stack trace I encountered during the actual issue:\r\n\r\n[ 66.575408s] [pid:5118,cpu4,QThread,4]Kernel panic - not syncing: stack-protector:\nKernel stack is corrupted in: do_hardware_base_addr+0xcc/0xd0 [parport]\n[ 66.575408s] [pid:5118,cpu4,QThread,5]CPU: 4 PID: 5118 Comm:\nQThread Tainted: G S W O 5.10.97-arm64-desktop #7100.57021.2\n[ 66.575439s] [pid:5118,cpu4,QThread,6]TGID: 5087 Comm: EFileApp\n[ 66.575439s] [pid:5118,cpu4,QThread,7]Hardware name: HUAWEI HUAWEI QingYun\nPGUX-W515x-B081/SP1PANGUXM, BIOS 1.00.07 04/29/2024\n[ 66.575439s] [pid:5118,cpu4,QThread,8]Call trace:\n[ 66.575469s] [pid:5118,cpu4,QThread,9] dump_backtrace+0x0/0x1c0\n[ 66.575469s] [pid:5118,cpu4,QThread,0] show_stack+0x14/0x20\n[ 66.575469s] [pid:5118,cpu4,QThread,1] dump_stack+0xd4/0x10c\n[ 66.575500s] [pid:5118,cpu4,QThread,2] panic+0x1d8/0x3bc\n[ 66.575500s] [pid:5118,cpu4,QThread,3] __stack_chk_fail+0x2c/0x38\n[ 66.575500s] [pid:5118,cpu4,QThread,4] do_hardware_base_addr+0xcc/0xd0 [parport](CVE-2024-42301)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nexfat: fix potential deadlock on __exfat_get_dentry_set\r\n\r\nWhen accessing a file with more entries than ES_MAX_ENTRY_NUM, the bh-array\nis allocated in __exfat_get_entry_set. The problem is that the bh-array is\nallocated with GFP_KERNEL. It does not make sense. In the following cases,\na deadlock for sbi-\u0026gt;s_lock between the two processes may occur.\r\n\r\n CPU0 CPU1\n ---- ----\n kswapd\n balance_pgdat\n lock(fs_reclaim)\n exfat_iterate\n lock(\u0026amp;sbi-\u0026gt;s_lock)\n exfat_readdir\n exfat_get_uniname_from_ext_entry\n exfat_get_dentry_set\n __exfat_get_dentry_set\n kmalloc_array\n ...\n lock(fs_reclaim)\n ...\n evict\n exfat_evict_inode\n lock(\u0026amp;sbi-\u0026gt;s_lock)\r\n\r\nTo fix this, let\u0026apos;s allocate bh-array with GFP_NOFS.(CVE-2024-42315)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: virt_wifi: avoid reporting connection success with wrong SSID\r\n\r\nWhen user issues a connection with a different SSID than the one\nvirt_wifi has advertised, the __cfg80211_connect_result() will\ntrigger the warning: WARN_ON(bss_not_found).\r\n\r\nThe issue is because the connection code in virt_wifi does not\ncheck the SSID from user space (it only checks the BSSID), and\nvirt_wifi will call cfg80211_connect_result() with WLAN_STATUS_SUCCESS\neven if the SSID is different from the one virt_wifi has advertised.\nEventually cfg80211 won\u0026apos;t be able to find the cfg80211_bss and generate\nthe warning.\r\n\r\nFixed it by checking the SSID (from user space) in the connection code.(CVE-2024-43841)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\njfs: Fix array-index-out-of-bounds in diFree(CVE-2024-43858)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/nouveau: prime: fix refcount underflow\r\n\r\nCalling nouveau_bo_ref() on a nouveau_bo without initializing it (and\nhence the backing ttm_bo) leads to a refcount underflow.\r\n\r\nInstead of calling nouveau_bo_ref() in the unwind path of\ndrm_gem_object_init(), clean things up manually.\r\n\r\n(cherry picked from commit 1b93f3e89d03cfc576636e195466a0d728ad8de5)(CVE-2024-43867)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndevres: Fix memory leakage caused by driver API devm_free_percpu()\r\n\r\nIt will cause memory leakage when use driver API devm_free_percpu()\nto free memory allocated by devm_alloc_percpu(), fixed by using\ndevres_release() instead of devres_destroy() within devm_free_percpu().(CVE-2024-43871)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/client: fix null pointer dereference in drm_client_modeset_probe\r\n\r\nIn drm_client_modeset_probe(), the return value of drm_mode_duplicate() is\nassigned to modeset-\u0026gt;mode, which will lead to a possible NULL pointer\ndereference on failure of drm_mode_duplicate(). Add a check to avoid npd.(CVE-2024-43894)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmptcp: pm: only decrement add_addr_accepted for MPJ req\r\n\r\nAdding the following warning ...\r\n\r\n WARN_ON_ONCE(msk-\u0026gt;pm.add_addr_accepted == 0)\r\n\r\n... before decrementing the add_addr_accepted counter helped to find a\nbug when running the \u0026quot;remove single subflow\u0026quot; subtest from the\nmptcp_join.sh selftest.\r\n\r\nRemoving a \u0026apos;subflow\u0026apos; endpoint will first trigger a RM_ADDR, then the\nsubflow closure. Before this patch, and upon the reception of the\nRM_ADDR, the other peer will then try to decrement this\nadd_addr_accepted. That\u0026apos;s not correct because the attached subflows have\nnot been created upon the reception of an ADD_ADDR.\r\n\r\nA way to solve that is to decrement the counter only if the attached\nsubflow was an MP_JOIN to a remote id that was not 0, and initiated by\nthe host receiving the RM_ADDR.(CVE-2024-45009)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: dwc3: core: Prevent USB core invalid event buffer address access\r\n\r\nThis commit addresses an issue where the USB core could access an\ninvalid event buffer address during runtime suspend, potentially causing\nSMMU faults and other memory issues in Exynos platforms. The problem\narises from the following sequence.\n 1. In dwc3_gadget_suspend, there is a chance of a timeout when\n moving the USB core to the halt state after clearing the\n run/stop bit by software.\n 2. In dwc3_core_exit, the event buffer is cleared regardless of\n the USB core\u0026apos;s status, which may lead to an SMMU faults and\n other memory issues. if the USB core tries to access the event\n buffer address.\r\n\r\nTo prevent this hardware quirk on Exynos platforms, this commit ensures\nthat the event buffer address is not cleared by software when the USB\ncore is active during runtime suspend by checking its status before\nclearing the buffer address.(CVE-2024-46675)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsoc: qcom: cmd-db: Map shared memory as WC, not WB\r\n\r\nLinux does not write into cmd-db region. This region of memory is write\nprotected by XPU. XPU may sometime falsely detect clean cache eviction\nas \u0026quot;write\u0026quot; into the write protected region leading to secure interrupt\nwhich causes an endless loop somewhere in Trust Zone.\r\n\r\nThe only reason it is working right now is because Qualcomm Hypervisor\nmaps the same region as Non-Cacheable memory in Stage 2 translation\ntables. The issue manifests if we want to use another hypervisor (like\nXen or KVM), which does not know anything about those specific mappings.\r\n\r\nChanging the mapping of cmd-db memory from MEMREMAP_WB to MEMREMAP_WT/WC\nremoves dependency on correct mappings in Stage 2 tables. This patch\nfixes the issue by updating the mapping to MEMREMAP_WC.\r\n\r\nI tested this on SA8155P with Xen.(CVE-2024-46689)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: fix mc_data out-of-bounds read warning\r\n\r\nClear warning that read mc_data[i-1] may out-of-bounds.(CVE-2024-46722)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: Fix out-of-bounds read of df_v1_7_channel_number\r\n\r\nCheck the fb_channel_number range to avoid the array out-of-bounds\nread error(CVE-2024-46724)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nhwmon: (nct6775-core) Fix underflows seen when writing limit attributes\r\n\r\nDIV_ROUND_CLOSEST() after kstrtol() results in an underflow if a large\nnegative number such as -9223372036854775808 is provided by the user.\nFix it by reordering clamp_val() and DIV_ROUND_CLOSEST() operations.(CVE-2024-46757)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: added NULL check at start of dc_validate_stream\r\n\r\n[Why]\nprevent invalid memory access\r\n\r\n[How]\ncheck if dc and stream are NULL(CVE-2024-46802)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nKVM: x86: Acquire kvm-\u0026gt;srcu when handling KVM_SET_VCPU_EVENTS\r\n\r\nGrab kvm-\u0026gt;srcu when processing KVM_SET_VCPU_EVENTS, as KVM will forcibly\nleave nested VMX/SVM if SMM mode is being toggled, and leaving nested VMX\nreads guest memory.\r\n\r\nNote, kvm_vcpu_ioctl_x86_set_vcpu_events() can also be called from KVM_RUN\nvia sync_regs(), which already holds SRCU. I.e. trying to precisely use\nkvm_vcpu_srcu_read_lock() around the problematic SMM code would cause\nproblems. Acquiring SRCU isn\u0026apos;t all that expensive, so for simplicity,\ngrab it unconditionally for KVM_SET_VCPU_EVENTS.\r\n\r\n =============================\n WARNING: suspicious RCU usage\n 6.10.0-rc7-332d2c1d713e-next-vm #552 Not tainted\n -----------------------------\n include/linux/kvm_host.h:1027 suspicious rcu_dereference_check() usage!\r\n\r\n other info that might help us debug this:\r\n\r\n rcu_scheduler_active = 2, debug_locks = 1\n 1 lock held by repro/1071:\n #0: ffff88811e424430 (\u0026amp;vcpu-\u0026gt;mutex){+.+.}-{3:3}, at: kvm_vcpu_ioctl+0x7d/0x970 [kvm]\r\n\r\n stack backtrace:\n CPU: 15 PID: 1071 Comm: repro Not tainted 6.10.0-rc7-332d2c1d713e-next-vm #552\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015\n Call Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x7f/0x90\n lockdep_rcu_suspicious+0x13f/0x1a0\n kvm_vcpu_gfn_to_memslot+0x168/0x190 [kvm]\n kvm_vcpu_read_guest+0x3e/0x90 [kvm]\n nested_vmx_load_msr+0x6b/0x1d0 [kvm_intel]\n load_vmcs12_host_state+0x432/0xb40 [kvm_intel]\n vmx_leave_nested+0x30/0x40 [kvm_intel]\n kvm_vcpu_ioctl_x86_set_vcpu_events+0x15d/0x2b0 [kvm]\n kvm_arch_vcpu_ioctl+0x1107/0x1750 [kvm]\n ? mark_held_locks+0x49/0x70\n ? kvm_vcpu_ioctl+0x7d/0x970 [kvm]\n ? kvm_vcpu_ioctl+0x497/0x970 [kvm]\n kvm_vcpu_ioctl+0x497/0x970 [kvm]\n ? lock_acquire+0xba/0x2d0\n ? find_held_lock+0x2b/0x80\n ? do_user_addr_fault+0x40c/0x6f0\n ? lock_release+0xb7/0x270\n __x64_sys_ioctl+0x82/0xb0\n do_syscall_64+0x6c/0x170\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n RIP: 0033:0x7ff11eb1b539\n \u0026lt;/TASK\u0026gt;(CVE-2024-46830)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nspi: nxp-fspi: fix the KASAN report out-of-bounds bug\r\n\r\nChange the memcpy length to fix the out-of-bounds issue when writing the\ndata that is not 4 byte aligned to TX FIFO.\r\n\r\nTo reproduce the issue, write 3 bytes data to NOR chip.\r\n\r\ndd if=3b of=/dev/mtd0\n[ 36.926103] ==================================================================\n[ 36.933409] BUG: KASAN: slab-out-of-bounds in nxp_fspi_exec_op+0x26ec/0x2838\n[ 36.940514] Read of size 4 at addr ffff00081037c2a0 by task dd/455\n[ 36.946721]\n[ 36.948235] CPU: 3 UID: 0 PID: 455 Comm: dd Not tainted 6.11.0-rc5-gc7b0e37c8434 #1070\n[ 36.956185] Hardware name: Freescale i.MX8QM MEK (DT)\n[ 36.961260] Call trace:\n[ 36.963723] dump_backtrace+0x90/0xe8\n[ 36.967414] show_stack+0x18/0x24\n[ 36.970749] dump_stack_lvl+0x78/0x90\n[ 36.974451] print_report+0x114/0x5cc\n[ 36.978151] kasan_report+0xa4/0xf0\n[ 36.981670] __asan_report_load_n_noabort+0x1c/0x28\n[ 36.986587] nxp_fspi_exec_op+0x26ec/0x2838\n[ 36.990800] spi_mem_exec_op+0x8ec/0xd30\n[ 36.994762] spi_mem_no_dirmap_read+0x190/0x1e0\n[ 36.999323] spi_mem_dirmap_write+0x238/0x32c\n[ 37.003710] spi_nor_write_data+0x220/0x374\n[ 37.007932] spi_nor_write+0x110/0x2e8\n[ 37.011711] mtd_write_oob_std+0x154/0x1f0\n[ 37.015838] mtd_write_oob+0x104/0x1d0\n[ 37.019617] mtd_write+0xb8/0x12c\n[ 37.022953] mtdchar_write+0x224/0x47c\n[ 37.026732] vfs_write+0x1e4/0x8c8\n[ 37.030163] ksys_write+0xec/0x1d0\n[ 37.033586] __arm64_sys_write+0x6c/0x9c\n[ 37.037539] invoke_syscall+0x6c/0x258\n[ 37.041327] el0_svc_common.constprop.0+0x160/0x22c\n[ 37.046244] do_el0_svc+0x44/0x5c\n[ 37.049589] el0_svc+0x38/0x78\n[ 37.052681] el0t_64_sync_handler+0x13c/0x158\n[ 37.057077] el0t_64_sync+0x190/0x194\n[ 37.060775]\n[ 37.062274] Allocated by task 455:\n[ 37.065701] kasan_save_stack+0x2c/0x54\n[ 37.069570] kasan_save_track+0x20/0x3c\n[ 37.073438] kasan_save_alloc_info+0x40/0x54\n[ 37.077736] __kasan_kmalloc+0xa0/0xb8\n[ 37.081515] __kmalloc_noprof+0x158/0x2f8\n[ 37.085563] mtd_kmalloc_up_to+0x120/0x154\n[ 37.089690] mtdchar_write+0x130/0x47c\n[ 37.093469] vfs_write+0x1e4/0x8c8\n[ 37.096901] ksys_write+0xec/0x1d0\n[ 37.100332] __arm64_sys_write+0x6c/0x9c\n[ 37.104287] invoke_syscall+0x6c/0x258\n[ 37.108064] el0_svc_common.constprop.0+0x160/0x22c\n[ 37.112972] do_el0_svc+0x44/0x5c\n[ 37.116319] el0_svc+0x38/0x78\n[ 37.119401] el0t_64_sync_handler+0x13c/0x158\n[ 37.123788] el0t_64_sync+0x190/0x194\n[ 37.127474]\n[ 37.128977] The buggy address belongs to the object at ffff00081037c2a0\n[ 37.128977] which belongs to the cache kmalloc-8 of size 8\n[ 37.141177] The buggy address is located 0 bytes inside of\n[ 37.141177] allocated 3-byte region [ffff00081037c2a0, ffff00081037c2a3)\n[ 37.153465]\n[ 37.154971] The buggy address belongs to the physical page:\n[ 37.160559] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x89037c\n[ 37.168596] flags: 0xbfffe0000000000(node=0|zone=2|lastcpupid=0x1ffff)\n[ 37.175149] page_type: 0xfdffffff(slab)\n[ 37.179021] raw: 0bfffe0000000000 ffff000800002500 dead000000000122 0000000000000000\n[ 37.186788] raw: 0000000000000000 0000000080800080 00000001fdffffff 0000000000000000\n[ 37.194553] page dumped because: kasan: bad access detected\n[ 37.200144]\n[ 37.201647] Memory state around the buggy address:\n[ 37.206460] ffff00081037c180: fa fc fc fc fa fc fc fc fa fc fc fc fa fc fc fc\n[ 37.213701] ffff00081037c200: fa fc fc fc 05 fc fc fc 03 fc fc fc 02 fc fc fc\n[ 37.220946] \u0026gt;ffff00081037c280: 06 fc fc fc 03 fc fc fc fc fc fc fc fc fc fc fc\n[ 37.228186] ^\n[ 37.232473] ffff00081037c300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc\n[ 37.239718] ffff00081037c380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc\n[ 37.246962] ==============================================================\n---truncated---(CVE-2024-46853)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nPCI: keystone: Add workaround for Errata #i2037 (AM65x SR 1.0)\r\n\r\nErrata #i2037 in AM65x/DRA80xM Processors Silicon Revision 1.0\n(SPRZ452D_July 2018_Revised December 2019 [1]) mentions when an\ninbound PCIe TLP spans more than two internal AXI 128-byte bursts,\nthe bus may corrupt the packet payload and the corrupt data may\ncause associated applications or the processor to hang.\r\n\r\nThe workaround for Errata #i2037 is to limit the maximum read\nrequest size and maximum payload size to 128 bytes. Add workaround\nfor Errata #i2037 here.\r\n\r\nThe errata and workaround is applicable only to AM65x SR 1.0 and\nlater versions of the silicon will have this fixed.\r\n\r\n[1] -\u0026gt; https://www.ti.com/lit/er/sprz452i/sprz452i.pdf(CVE-2024-47667)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: fix state management in error path of log writing function\r\n\r\nAfter commit a694291a6211 (\u0026quot;nilfs2: separate wait function from\nnilfs_segctor_write\u0026quot;) was applied, the log writing function\nnilfs_segctor_do_construct() was able to issue I/O requests continuously\neven if user data blocks were split into multiple logs across segments,\nbut two potential flaws were introduced in its error handling.\r\n\r\nFirst, if nilfs_segctor_begin_construction() fails while creating the\nsecond or subsequent logs, the log writing function returns without\ncalling nilfs_segctor_abort_construction(), so the writeback flag set on\npages/folios will remain uncleared. This causes page cache operations to\nhang waiting for the writeback flag. For example,\ntruncate_inode_pages_final(), which is called via nilfs_evict_inode() when\nan inode is evicted from memory, will hang.\r\n\r\nSecond, the NILFS_I_COLLECTED flag set on normal inodes remain uncleared. \nAs a result, if the next log write involves checkpoint creation, that\u0026apos;s\nfine, but if a partial log write is performed that does not, inodes with\nNILFS_I_COLLECTED set are erroneously removed from the \u0026quot;sc_dirty_files\u0026quot;\nlist, and their data and b-tree blocks may not be written to the device,\ncorrupting the block mapping.\r\n\r\nFix these issues by uniformly calling nilfs_segctor_abort_construction()\non failure of each step in the loop in nilfs_segctor_do_construct(),\nhaving it clean up logs and segment usages according to progress, and\ncorrecting the conditions for calling nilfs_redirty_inodes() to ensure\nthat the NILFS_I_COLLECTED flag is cleared.(CVE-2024-47669)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: tcp: check skb is non-NULL in tcp_rto_delta_us() We have some machines running stock Ubuntu 20.04.6 which is their 5.4.0-174-generic kernel that are running ceph and recently hit a null ptr dereference in tcp_rearm_rto(). Initially hitting it from the TLP path, but then later we also saw it getting hit from the RACK case as well. Here are examples of the oops messages we saw in each of those cases: Jul 26 15:05:02 rx [11061395.780353] BUG: kernel NULL pointer dereference, address: 0000000000000020 Jul 26 15:05:02 rx [11061395.787572] #PF: supervisor read access in kernel mode Jul 26 15:05:02 rx [11061395.792971] #PF: error_code(0x0000) - not-present page Jul 26 15:05:02 rx [11061395.798362] PGD 0 P4D 0 Jul 26 15:05:02 rx [11061395.801164] Oops: 0000 [#1] SMP NOPTI Jul 26 15:05:02 rx [11061395.805091] CPU: 0 PID: 9180 Comm: msgr-worker-1 Tainted: G W 5.4.0-174-generic #193-Ubuntu Jul 26 15:05:02 rx [11061395.814996] Hardware name: Supermicro SMC 2x26 os-gen8 64C NVME-Y 256G/H12SSW-NTR, BIOS 2.5.V1.2U.NVMe.UEFI 05/09/2023 Jul 26 15:05:02 rx [11061395.825952] RIP: 0010:tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.830656] Code: 87 ca 04 00 00 00 5b 41 5c 41 5d 5d c3 c3 49 8b bc 24 40 06 00 00 eb 8d 48 bb cf f7 53 e3 a5 9b c4 20 4c 89 ef e8 0c fe 0e 00 \u0026lt;48\u0026gt; 8b 78 20 48 c1 ef 03 48 89 f8 41 8b bc 24 80 04 00 00 48 f7 e3 Jul 26 15:05:02 rx [11061395.849665] RSP: 0018:ffffb75d40003e08 EFLAGS: 00010246 Jul 26 15:05:02 rx [11061395.855149] RAX: 0000000000000000 RBX: 20c49ba5e353f7cf RCX: 0000000000000000 Jul 26 15:05:02 rx [11061395.862542] RDX: 0000000062177c30 RSI: 000000000000231c RDI: ffff9874ad283a60 Jul 26 15:05:02 rx [11061395.869933] RBP: ffffb75d40003e20 R08: 0000000000000000 R09: ffff987605e20aa8 Jul 26 15:05:02 rx [11061395.877318] R10: ffffb75d40003f00 R11: ffffb75d4460f740 R12: ffff9874ad283900 Jul 26 15:05:02 rx [11061395.884710] R13: ffff9874ad283a60 R14: ffff9874ad283980 R15: ffff9874ad283d30 Jul 26 15:05:02 rx [11061395.892095] FS: 00007f1ef4a2e700(0000) GS:ffff987605e00000(0000) knlGS:0000000000000000 Jul 26 15:05:02 rx [11061395.900438] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Jul 26 15:05:02 rx [11061395.906435] CR2: 0000000000000020 CR3: 0000003e450ba003 CR4: 0000000000760ef0 Jul 26 15:05:02 rx [11061395.913822] PKRU: 55555554 Jul 26 15:05:02 rx [11061395.916786] Call Trace: Jul 26 15:05:02 rx [11061395.919488] Jul 26 15:05:02 rx [11061395.921765] ? show_regs.cold+0x1a/0x1f Jul 26 15:05:02 rx [11061395.925859] ? __die+0x90/0xd9 Jul 26 15:05:02 rx [11061395.929169] ? no_context+0x196/0x380 Jul 26 15:05:02 rx [11061395.933088] ? ip6_protocol_deliver_rcu+0x4e0/0x4e0 Jul 26 15:05:02 rx [11061395.938216] ? ip6_sublist_rcv_finish+0x3d/0x50 Jul 26 15:05:02 rx [11061395.943000] ? __bad_area_nosemaphore+0x50/0x1a0 Jul 26 15:05:02 rx [11061395.947873] ? bad_area_nosemaphore+0x16/0x20 Jul 26 15:05:02 rx [11061395.952486] ? do_user_addr_fault+0x267/0x450 Jul 26 15:05:02 rx [11061395.957104] ? ipv6_list_rcv+0x112/0x140 Jul 26 15:05:02 rx [11061395.961279] ? __do_page_fault+0x58/0x90 Jul 26 15:05:02 rx [11061395.965458] ? do_page_fault+0x2c/0xe0 Jul 26 15:05:02 rx [11061395.969465] ? page_fault+0x34/0x40 Jul 26 15:05:02 rx [11061395.973217] ? tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.977313] ? tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.981408] tcp_send_loss_probe+0x10b/0x220 Jul 26 15:05:02 rx [11061395.985937] tcp_write_timer_handler+0x1b4/0x240 Jul 26 15:05:02 rx [11061395.990809] tcp_write_timer+0x9e/0xe0 Jul 26 15:05:02 rx [11061395.994814] ? tcp_write_timer_handler+0x240/0x240 Jul 26 15:05:02 rx [11061395.999866] call_timer_fn+0x32/0x130 Jul 26 15:05:02 rx [11061396.003782] __run_timers.part.0+0x180/0x280 Jul 26 15:05:02 rx [11061396.008309] ? recalibrate_cpu_khz+0x10/0x10 Jul 26 15:05:02 rx [11061396.012841] ? native_x2apic_icr_write+0x30/0x30 Jul 26 15:05:02 rx [11061396.017718] ? lapic_next_even ---truncated---(CVE-2024-47684)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: netfilter: nf_reject_ipv6: fix nf_reject_ip6_tcphdr_put() syzbot reported that nf_reject_ip6_tcphdr_put() was possibly sending garbage on the four reserved tcp bits (th-\u0026gt;res1) Use skb_put_zero() to clear the whole TCP header, as done in nf_reject_ip_tcphdr_put() BUG: KMSAN: uninit-value in nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255 nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255 nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344 nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core net/core/dev.c:5661 [inline] __netif_receive_skb+0x1da/0xa00 net/core/dev.c:5775 process_backlog+0x4ad/0xa50 net/core/dev.c:6108 __napi_poll+0xe7/0x980 net/core/dev.c:6772 napi_poll net/core/dev.c:6841 [inline] net_rx_action+0xa5a/0x19b0 net/core/dev.c:6963 handle_softirqs+0x1ce/0x800 kernel/softirq.c:554 __do_softirq+0x14/0x1a kernel/softirq.c:588 do_softirq+0x9a/0x100 kernel/softirq.c:455 __local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:382 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:908 [inline] __dev_queue_xmit+0x2692/0x5610 net/core/dev.c:4450 dev_queue_xmit include/linux/netdevice.h:3105 [inline] neigh_resolve_output+0x9ca/0xae0 net/core/neighbour.c:1565 neigh_output include/net/neighbour.h:542 [inline] ip6_finish_output2+0x2347/0x2ba0 net/ipv6/ip6_output.c:141 __ip6_finish_output net/ipv6/ip6_output.c:215 [inline] ip6_finish_output+0xbb8/0x14b0 net/ipv6/ip6_output.c:226 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip6_output+0x356/0x620 net/ipv6/ip6_output.c:247 dst_output include/net/dst.h:450 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] ip6_xmit+0x1ba6/0x25d0 net/ipv6/ip6_output.c:366 inet6_csk_xmit+0x442/0x530 net/ipv6/inet6_connection_sock.c:135 __tcp_transmit_skb+0x3b07/0x4880 net/ipv4/tcp_output.c:1466 tcp_transmit_skb net/ipv4/tcp_output.c:1484 [inline] tcp_connect+0x35b6/0x7130 net/ipv4/tcp_output.c:4143 tcp_v6_connect+0x1bcc/0x1e40 net/ipv6/tcp_ipv6.c:333 __inet_stream_connect+0x2ef/0x1730 net/ipv4/af_inet.c:679 inet_stream_connect+0x6a/0xd0 net/ipv4/af_inet.c:750 __sys_connect_file net/socket.c:2061 [inline] __sys_connect+0x606/0x690 net/socket.c:2078 __do_sys_connect net/socket.c:2088 [inline] __se_sys_connect net/socket.c:2085 [inline] __x64_sys_connect+0x91/0xe0 net/socket.c:2085 x64_sys_call+0x27a5/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:43 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit was stored to memory at: nf_reject_ip6_tcphdr_put+0x60c/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:249 nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344 nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core ---truncated---(CVE-2024-47685)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: nfsd: return -EINVAL when namelen is 0 When we have a corrupted main.sqlite in /var/lib/nfs/nfsdcld/, it may result in namelen being 0, which will cause memdup_user() to return ZERO_SIZE_PTR. When we access the name.data that has been assigned the value of ZERO_SIZE_PTR in nfs4_client_to_reclaim(), null pointer dereference is triggered. [ T1205] ================================================================== [ T1205] BUG: KASAN: null-ptr-deref in nfs4_client_to_reclaim+0xe9/0x260 [ T1205] Read of size 1 at addr 0000000000000010 by task nfsdcld/1205 [ T1205] [ T1205] CPU: 11 PID: 1205 Comm: nfsdcld Not tainted 5.10.0-00003-g2c1423731b8d #406 [ T1205] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014 [ T1205] Call Trace: [ T1205] dump_stack+0x9a/0xd0 [ T1205] ? nfs4_client_to_reclaim+0xe9/0x260 [ T1205] __kasan_report.cold+0x34/0x84 [ T1205] ? nfs4_client_to_reclaim+0xe9/0x260 [ T1205] kasan_report+0x3a/0x50 [ T1205] nfs4_client_to_reclaim+0xe9/0x260 [ T1205] ? nfsd4_release_lockowner+0x410/0x410 [ T1205] cld_pipe_downcall+0x5ca/0x760 [ T1205] ? nfsd4_cld_tracking_exit+0x1d0/0x1d0 [ T1205] ? down_write_killable_nested+0x170/0x170 [ T1205] ? avc_policy_seqno+0x28/0x40 [ T1205] ? selinux_file_permission+0x1b4/0x1e0 [ T1205] rpc_pipe_write+0x84/0xb0 [ T1205] vfs_write+0x143/0x520 [ T1205] ksys_write+0xc9/0x170 [ T1205] ? __ia32_sys_read+0x50/0x50 [ T1205] ? ktime_get_coarse_real_ts64+0xfe/0x110 [ T1205] ? ktime_get_coarse_real_ts64+0xa2/0x110 [ T1205] do_syscall_64+0x33/0x40 [ T1205] entry_SYSCALL_64_after_hwframe+0x67/0xd1 [ T1205] RIP: 0033:0x7fdbdb761bc7 [ T1205] Code: 0f 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 \u0026lt;48\u0026gt; 3d 00 f0 ff ff 77 514 [ T1205] RSP: 002b:00007fff8c4b7248 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ T1205] RAX: ffffffffffffffda RBX: 000000000000042b RCX: 00007fdbdb761bc7 [ T1205] RDX: 000000000000042b RSI: 00007fff8c4b75f0 RDI: 0000000000000008 [ T1205] RBP: 00007fdbdb761bb0 R08: 0000000000000000 R09: 0000000000000001 [ T1205] R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000042b [ T1205] R13: 0000000000000008 R14: 00007fff8c4b75f0 R15: 0000000000000000 [ T1205] ================================================================== Fix it by checking namelen.(CVE-2024-47692)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: RDMA/rtrs-clt: Reset cid to con_num - 1 to stay in bounds In the function init_conns(), after the create_con() and create_cm() for loop if something fails. In the cleanup for loop after the destroy tag, we access out of bound memory because cid is set to clt_path-\u0026gt;s.con_num. This commits resets the cid to clt_path-\u0026gt;s.con_num - 1, to stay in bounds in the cleanup loop later.(CVE-2024-47695)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: drivers: media: dvb-frontends/rtl2832: fix an out-of-bounds write error Ensure index in rtl2832_pid_filter does not exceed 31 to prevent out-of-bounds access. dev-\u0026gt;filters is a 32-bit value, so set_bit and clear_bit functions should only operate on indices from 0 to 31. If index is 32, it will attempt to access a non-existent 33rd bit, leading to out-of-bounds access. Change the boundary check from index \u0026gt; 32 to index \u0026gt;= 32 to resolve this issue. [hverkuil: added fixes tag, rtl2830_pid_filter -\u0026gt; rtl2832_pid_filter in logmsg](CVE-2024-47698)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: can: bcm: Clear bo-\u0026gt;bcm_proc_read after remove_proc_entry(). syzbot reported a warning in bcm_release(). [0] The blamed change fixed another warning that is triggered when connect() is issued again for a socket whose connect()ed device has been unregistered. However, if the socket is just close()d without the 2nd connect(), the remaining bo-\u0026gt;bcm_proc_read triggers unnecessary remove_proc_entry() in bcm_release(). Let\u0026apos;s clear bo-\u0026gt;bcm_proc_read after remove_proc_entry() in bcm_notify(). [0] name \u0026apos;4986\u0026apos; WARNING: CPU: 0 PID: 5234 at fs/proc/generic.c:711 remove_proc_entry+0x2e7/0x5d0 fs/proc/generic.c:711 Modules linked in: CPU: 0 UID: 0 PID: 5234 Comm: syz-executor606 Not tainted 6.11.0-rc5-syzkaller-00178-g5517ae241919 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:remove_proc_entry+0x2e7/0x5d0 fs/proc/generic.c:711 Code: ff eb 05 e8 cb 1e 5e ff 48 8b 5c 24 10 48 c7 c7 e0 f7 aa 8e e8 2a 38 8e 09 90 48 c7 c7 60 3a 1b 8c 48 89 de e8 da 42 20 ff 90 \u0026lt;0f\u0026gt; 0b 90 90 48 8b 44 24 18 48 c7 44 24 40 0e 36 e0 45 49 c7 04 07 RSP: 0018:ffffc9000345fa20 EFLAGS: 00010246 RAX: 2a2d0aee2eb64600 RBX: ffff888032f1f548 RCX: ffff888029431e00 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffc9000345fb08 R08: ffffffff8155b2f2 R09: 1ffff1101710519a R10: dffffc0000000000 R11: ffffed101710519b R12: ffff888011d38640 R13: 0000000000000004 R14: 0000000000000000 R15: dffffc0000000000 FS: 0000000000000000(0000) GS:ffff8880b8800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fcfb52722f0 CR3: 000000000e734000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: \u0026lt;TASK\u0026gt; bcm_release+0x250/0x880 net/can/bcm.c:1578 __sock_release net/socket.c:659 [inline] sock_close+0xbc/0x240 net/socket.c:1421 __fput+0x24a/0x8a0 fs/file_table.c:422 task_work_run+0x24f/0x310 kernel/task_work.c:228 exit_task_work include/linux/task_work.h:40 [inline] do_exit+0xa2f/0x27f0 kernel/exit.c:882 do_group_exit+0x207/0x2c0 kernel/exit.c:1031 __do_sys_exit_group kernel/exit.c:1042 [inline] __se_sys_exit_group kernel/exit.c:1040 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1040 x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fcfb51ee969 Code: Unable to access opcode bytes at 0x7fcfb51ee93f. RSP: 002b:00007ffce0109ca8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007fcfb51ee969 RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000001 RBP: 00007fcfb526f3b0 R08: ffffffffffffffb8 R09: 0000555500000000 R10: 0000555500000000 R11: 0000000000000246 R12: 00007fcfb526f3b0 R13: 0000000000000000 R14: 00007fcfb5271ee0 R15: 00007fcfb51bf160 \u0026lt;/TASK\u0026gt;(CVE-2024-47709)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: sock_map: Add a cond_resched() in sock_hash_free() Several syzbot soft lockup reports all have in common sock_hash_free() If a map with a large number of buckets is destroyed, we need to yield the cpu when needed.(CVE-2024-47710)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for set_output_gamma in dcn30_set_output_transfer_func This commit adds a null check for the set_output_gamma function pointer in the dcn30_set_output_transfer_func function. Previously, set_output_gamma was being checked for nullity at line 386, but then it was being dereferenced without any nullity check at line 401. This could potentially lead to a null pointer dereference error if set_output_gamma is indeed null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a nullity check for set_output_gamma before the call to set_output_gamma at line 401. If set_output_gamma is null, we log an error message and do not call the function. This fix prevents a potential null pointer dereference error. drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:401 dcn30_set_output_transfer_func() error: we previously assumed \u0026apos;mpc-\u0026gt;funcs-\u0026gt;set_output_gamma\u0026apos; could be null (see line 386) drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c 373 bool dcn30_set_output_transfer_func(struct dc *dc, 374 struct pipe_ctx *pipe_ctx, 375 const struct dc_stream_state *stream) 376 { 377 int mpcc_id = pipe_ctx-\u0026gt;plane_res.hubp-\u0026gt;inst; 378 struct mpc *mpc = pipe_ctx-\u0026gt;stream_res.opp-\u0026gt;ctx-\u0026gt;dc-\u0026gt;res_pool-\u0026gt;mpc; 379 const struct pwl_params *params = NULL; 380 bool ret = false; 381 382 /* program OGAM or 3DLUT only for the top pipe*/ 383 if (pipe_ctx-\u0026gt;top_pipe == NULL) { 384 /*program rmu shaper and 3dlut in MPC*/ 385 ret = dcn30_set_mpc_shaper_3dlut(pipe_ctx, stream); 386 if (ret == false \u0026amp;\u0026amp; mpc-\u0026gt;funcs-\u0026gt;set_output_gamma) { ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ If this is NULL 387 if (stream-\u0026gt;out_transfer_func.type == TF_TYPE_HWPWL) 388 params = \u0026amp;stream-\u0026gt;out_transfer_func.pwl; 389 else if (pipe_ctx-\u0026gt;stream-\u0026gt;out_transfer_func.type == 390 TF_TYPE_DISTRIBUTED_POINTS \u0026amp;\u0026amp; 391 cm3_helper_translate_curve_to_hw_format( 392 \u0026amp;stream-\u0026gt;out_transfer_func, 393 \u0026amp;mpc-\u0026gt;blender_params, false)) 394 params = \u0026amp;mpc-\u0026gt;blender_params; 395 /* there are no ROM LUTs in OUTGAM */ 396 if (stream-\u0026gt;out_transfer_func.type == TF_TYPE_PREDEFINED) 397 BREAK_TO_DEBUGGER(); 398 } 399 } 400 --\u0026gt; 401 mpc-\u0026gt;funcs-\u0026gt;set_output_gamma(mpc, mpcc_id, params); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Then it will crash 402 return ret; 403 }(CVE-2024-47720)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix spin_unlock_irqrestore() called with IRQs enabled Fix missuse of spin_lock_irq()/spin_unlock_irq() when spin_lock_irqsave()/spin_lock_irqrestore() was hold. This was discovered through the lock debugging, and the corresponding log is as follows: raw_local_irq_restore() called with IRQs enabled WARNING: CPU: 96 PID: 2074 at kernel/locking/irqflag-debug.c:10 warn_bogus_irq_restore+0x30/0x40 ... Call trace: warn_bogus_irq_restore+0x30/0x40 _raw_spin_unlock_irqrestore+0x84/0xc8 add_qp_to_list+0x11c/0x148 [hns_roce_hw_v2] hns_roce_create_qp_common.constprop.0+0x240/0x780 [hns_roce_hw_v2] hns_roce_create_qp+0x98/0x160 [hns_roce_hw_v2] create_qp+0x138/0x258 ib_create_qp_kernel+0x50/0xe8 create_mad_qp+0xa8/0x128 ib_mad_port_open+0x218/0x448 ib_mad_init_device+0x70/0x1f8 add_client_context+0xfc/0x220 enable_device_and_get+0xd0/0x140 ib_register_device.part.0+0xf4/0x1c8 ib_register_device+0x34/0x50 hns_roce_register_device+0x174/0x3d0 [hns_roce_hw_v2] hns_roce_init+0xfc/0x2c0 [hns_roce_hw_v2] __hns_roce_hw_v2_init_instance+0x7c/0x1d0 [hns_roce_hw_v2] hns_roce_hw_v2_init_instance+0x9c/0x180 [hns_roce_hw_v2](CVE-2024-47735)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: nfsd: call cache_put if xdr_reserve_space returns NULL If not enough buffer space available, but idmap_lookup has triggered lookup_fn which calls cache_get and returns successfully. Then we missed to call cache_put here which pairs with cache_get. Reviwed-by: Jeff Layton \u0026lt;jlayton@kernel.org\u0026gt;(CVE-2024-47737)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential oob read in nilfs_btree_check_delete() The function nilfs_btree_check_delete(), which checks whether degeneration to direct mapping occurs before deleting a b-tree entry, causes memory access outside the block buffer when retrieving the maximum key if the root node has no entries. This does not usually happen because b-tree mappings with 0 child nodes are never created by mkfs.nilfs2 or nilfs2 itself. However, it can happen if the b-tree root node read from a device is configured that way, so fix this potential issue by adding a check for that case.(CVE-2024-47757)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: tracing/timerlat: Fix a race during cpuhp processing There is another found exception that the \u0026quot;timerlat/1\u0026quot; thread was scheduled on CPU0, and lead to timer corruption finally: ``` ODEBUG: init active (active state 0) object: ffff888237c2e108 object type: hrtimer hint: timerlat_irq+0x0/0x220 WARNING: CPU: 0 PID: 426 at lib/debugobjects.c:518 debug_print_object+0x7d/0xb0 Modules linked in: CPU: 0 UID: 0 PID: 426 Comm: timerlat/1 Not tainted 6.11.0-rc7+ #45 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:debug_print_object+0x7d/0xb0 ... Call Trace: \u0026lt;TASK\u0026gt; ? __warn+0x7c/0x110 ? debug_print_object+0x7d/0xb0 ? report_bug+0xf1/0x1d0 ? prb_read_valid+0x17/0x20 ? handle_bug+0x3f/0x70 ? exc_invalid_op+0x13/0x60 ? asm_exc_invalid_op+0x16/0x20 ? debug_print_object+0x7d/0xb0 ? debug_print_object+0x7d/0xb0 ? __pfx_timerlat_irq+0x10/0x10 __debug_object_init+0x110/0x150 hrtimer_init+0x1d/0x60 timerlat_main+0xab/0x2d0 ? __pfx_timerlat_main+0x10/0x10 kthread+0xb7/0xe0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 \u0026lt;/TASK\u0026gt; ``` After tracing the scheduling event, it was discovered that the migration of the \u0026quot;timerlat/1\u0026quot; thread was performed during thread creation. Further analysis confirmed that it is because the CPU online processing for osnoise is implemented through workers, which is asynchronous with the offline processing. When the worker was scheduled to create a thread, the CPU may has already been removed from the cpu_online_mask during the offline process, resulting in the inability to select the right CPU: T1 | T2 [CPUHP_ONLINE] | cpu_device_down() osnoise_hotplug_workfn() | | cpus_write_lock() | takedown_cpu(1) | cpus_write_unlock() [CPUHP_OFFLINE] | cpus_read_lock() | start_kthread(1) | cpus_read_unlock() | To fix this, skip online processing if the CPU is already offline.(CVE-2024-49866)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: btrfs: wait for fixup workers before stopping cleaner kthread during umount During unmount, at close_ctree(), we have the following steps in this order: 1) Park the cleaner kthread - this doesn\u0026apos;t destroy the kthread, it basically halts its execution (wake ups against it work but do nothing); 2) We stop the cleaner kthread - this results in freeing the respective struct task_struct; 3) We call btrfs_stop_all_workers() which waits for any jobs running in all the work queues and then free the work queues. Syzbot reported a case where a fixup worker resulted in a crash when doing a delayed iput on its inode while attempting to wake up the cleaner at btrfs_add_delayed_iput(), because the task_struct of the cleaner kthread was already freed. This can happen during unmount because we don\u0026apos;t wait for any fixup workers still running before we call kthread_stop() against the cleaner kthread, which stops and free all its resources. Fix this by waiting for any fixup workers at close_ctree() before we call kthread_stop() against the cleaner and run pending delayed iputs. The stack traces reported by syzbot were the following: BUG: KASAN: slab-use-after-free in __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065 Read of size 8 at addr ffff8880272a8a18 by task kworker/u8:3/52 CPU: 1 UID: 0 PID: 52 Comm: kworker/u8:3 Not tainted 6.12.0-rc1-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Workqueue: btrfs-fixup btrfs_work_helper Call Trace: \u0026lt;TASK\u0026gt; __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0xd5/0x120 kernel/locking/spinlock.c:162 class_raw_spinlock_irqsave_constructor include/linux/spinlock.h:551 [inline] try_to_wake_up+0xb0/0x1480 kernel/sched/core.c:4154 btrfs_writepage_fixup_worker+0xc16/0xdf0 fs/btrfs/inode.c:2842 btrfs_work_helper+0x390/0xc50 fs/btrfs/async-thread.c:314 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa63/0x1850 kernel/workqueue.c:3310 worker_thread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 \u0026lt;/TASK\u0026gt; Allocated by task 2: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:319 [inline] __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:345 kasan_slab_alloc include/linux/kasan.h:247 [inline] slab_post_alloc_hook mm/slub.c:4086 [inline] slab_alloc_node mm/slub.c:4135 [inline] kmem_cache_alloc_node_noprof+0x16b/0x320 mm/slub.c:4187 alloc_task_struct_node kernel/fork.c:180 [inline] dup_task_struct+0x57/0x8c0 kernel/fork.c:1107 copy_process+0x5d1/0x3d50 kernel/fork.c:2206 kernel_clone+0x223/0x880 kernel/fork.c:2787 kernel_thread+0x1bc/0x240 kernel/fork.c:2849 create_kthread kernel/kthread.c:412 [inline] kthreadd+0x60d/0x810 kernel/kthread.c:765 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Freed by task 61: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:230 [inline] slab_free_h ---truncated---(CVE-2024-49867)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: btrfs: fix a NULL pointer dereference when failed to start a new trasacntion [BUG] Syzbot reported a NULL pointer dereference with the following crash: FAULT_INJECTION: forcing a failure. start_transaction+0x830/0x1670 fs/btrfs/transaction.c:676 prepare_to_relocate+0x31f/0x4c0 fs/btrfs/relocation.c:3642 relocate_block_group+0x169/0xd20 fs/btrfs/relocation.c:3678 ... BTRFS info (device loop0): balance: ended with status: -12 Oops: general protection fault, probably for non-canonical address 0xdffffc00000000cc: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000660-0x0000000000000667] RIP: 0010:btrfs_update_reloc_root+0x362/0xa80 fs/btrfs/relocation.c:926 Call Trace: \u0026lt;TASK\u0026gt; commit_fs_roots+0x2ee/0x720 fs/btrfs/transaction.c:1496 btrfs_commit_transaction+0xfaf/0x3740 fs/btrfs/transaction.c:2430 del_balance_item fs/btrfs/volumes.c:3678 [inline] reset_balance_state+0x25e/0x3c0 fs/btrfs/volumes.c:3742 btrfs_balance+0xead/0x10c0 fs/btrfs/volumes.c:4574 btrfs_ioctl_balance+0x493/0x7c0 fs/btrfs/ioctl.c:3673 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f [CAUSE] The allocation failure happens at the start_transaction() inside prepare_to_relocate(), and during the error handling we call unset_reloc_control(), which makes fs_info-\u0026gt;balance_ctl to be NULL. Then we continue the error path cleanup in btrfs_balance() by calling reset_balance_state() which will call del_balance_item() to fully delete the balance item in the root tree. However during the small window between set_reloc_contrl() and unset_reloc_control(), we can have a subvolume tree update and created a reloc_root for that subvolume. Then we go into the final btrfs_commit_transaction() of del_balance_item(), and into btrfs_update_reloc_root() inside commit_fs_roots(). That function checks if fs_info-\u0026gt;reloc_ctl is in the merge_reloc_tree stage, but since fs_info-\u0026gt;reloc_ctl is NULL, it results a NULL pointer dereference. [FIX] Just add extra check on fs_info-\u0026gt;reloc_ctl inside btrfs_update_reloc_root(), before checking fs_info-\u0026gt;reloc_ctl-\u0026gt;merge_reloc_tree. That DEAD_RELOC_TREE handling is to prevent further modification to the reloc tree during merge stage, but since there is no reloc_ctl at all, we do not need to bother that.(CVE-2024-49868)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: nfsd: map the EBADMSG to nfserr_io to avoid warning Ext4 will throw -EBADMSG through ext4_readdir when a checksum error occurs, resulting in the following WARNING. Fix it by mapping EBADMSG to nfserr_io. nfsd_buffered_readdir iterate_dir // -EBADMSG -74 ext4_readdir // .iterate_shared ext4_dx_readdir ext4_htree_fill_tree htree_dirblock_to_tree ext4_read_dirblock __ext4_read_dirblock ext4_dirblock_csum_verify warn_no_space_for_csum __warn_no_space_for_csum return ERR_PTR(-EFSBADCRC) // -EBADMSG -74 nfserrno // WARNING [ 161.115610] ------------[ cut here ]------------ [ 161.116465] nfsd: non-standard errno: -74 [ 161.117315] WARNING: CPU: 1 PID: 780 at fs/nfsd/nfsproc.c:878 nfserrno+0x9d/0xd0 [ 161.118596] Modules linked in: [ 161.119243] CPU: 1 PID: 780 Comm: nfsd Not tainted 5.10.0-00014-g79679361fd5d #138 [ 161.120684] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qe mu.org 04/01/2014 [ 161.123601] RIP: 0010:nfserrno+0x9d/0xd0 [ 161.124676] Code: 0f 87 da 30 dd 00 83 e3 01 b8 00 00 00 05 75 d7 44 89 ee 48 c7 c7 c0 57 24 98 89 44 24 04 c6 05 ce 2b 61 03 01 e8 99 20 d8 00 \u0026lt;0f\u0026gt; 0b 8b 44 24 04 eb b5 4c 89 e6 48 c7 c7 a0 6d a4 99 e8 cc 15 33 [ 161.127797] RSP: 0018:ffffc90000e2f9c0 EFLAGS: 00010286 [ 161.128794] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 161.130089] RDX: 1ffff1103ee16f6d RSI: 0000000000000008 RDI: fffff520001c5f2a [ 161.131379] RBP: 0000000000000022 R08: 0000000000000001 R09: ffff8881f70c1827 [ 161.132664] R10: ffffed103ee18304 R11: 0000000000000001 R12: 0000000000000021 [ 161.133949] R13: 00000000ffffffb6 R14: ffff8881317c0000 R15: ffffc90000e2fbd8 [ 161.135244] FS: 0000000000000000(0000) GS:ffff8881f7080000(0000) knlGS:0000000000000000 [ 161.136695] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 161.137761] CR2: 00007fcaad70b348 CR3: 0000000144256006 CR4: 0000000000770ee0 [ 161.139041] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 161.140291] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 161.141519] PKRU: 55555554 [ 161.142076] Call Trace: [ 161.142575] ? __warn+0x9b/0x140 [ 161.143229] ? nfserrno+0x9d/0xd0 [ 161.143872] ? report_bug+0x125/0x150 [ 161.144595] ? handle_bug+0x41/0x90 [ 161.145284] ? exc_invalid_op+0x14/0x70 [ 161.146009] ? asm_exc_invalid_op+0x12/0x20 [ 161.146816] ? nfserrno+0x9d/0xd0 [ 161.147487] nfsd_buffered_readdir+0x28b/0x2b0 [ 161.148333] ? nfsd4_encode_dirent_fattr+0x380/0x380 [ 161.149258] ? nfsd_buffered_filldir+0xf0/0xf0 [ 161.150093] ? wait_for_concurrent_writes+0x170/0x170 [ 161.151004] ? generic_file_llseek_size+0x48/0x160 [ 161.151895] nfsd_readdir+0x132/0x190 [ 161.152606] ? nfsd4_encode_dirent_fattr+0x380/0x380 [ 161.153516] ? nfsd_unlink+0x380/0x380 [ 161.154256] ? override_creds+0x45/0x60 [ 161.155006] nfsd4_encode_readdir+0x21a/0x3d0 [ 161.155850] ? nfsd4_encode_readlink+0x210/0x210 [ 161.156731] ? write_bytes_to_xdr_buf+0x97/0xe0 [ 161.157598] ? __write_bytes_to_xdr_buf+0xd0/0xd0 [ 161.158494] ? lock_downgrade+0x90/0x90 [ 161.159232] ? nfs4svc_decode_voidarg+0x10/0x10 [ 161.160092] nfsd4_encode_operation+0x15a/0x440 [ 161.160959] nfsd4_proc_compound+0x718/0xe90 [ 161.161818] nfsd_dispatch+0x18e/0x2c0 [ 161.162586] svc_process_common+0x786/0xc50 [ 161.163403] ? nfsd_svc+0x380/0x380 [ 161.164137] ? svc_printk+0x160/0x160 [ 161.164846] ? svc_xprt_do_enqueue.part.0+0x365/0x380 [ 161.165808] ? nfsd_svc+0x380/0x380 [ 161.166523] ? rcu_is_watching+0x23/0x40 [ 161.167309] svc_process+0x1a5/0x200 [ 161.168019] nfsd+0x1f5/0x380 [ 161.168663] ? nfsd_shutdown_threads+0x260/0x260 [ 161.169554] kthread+0x1c4/0x210 [ 161.170224] ? kthread_insert_work_sanity_check+0x80/0x80 [ 161.171246] ret_from_fork+0x1f/0x30(CVE-2024-49875)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Initialize get_bytes_per_element\u0026apos;s default to 1 Variables, used as denominators and maybe not assigned to other values, should not be 0. bytes_per_element_y \u0026amp; bytes_per_element_c are initialized by get_bytes_per_element() which should never return 0. This fixes 10 DIVIDE_BY_ZERO issues reported by Coverity.(CVE-2024-49892)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in degamma hardware format translation Fixes index out of bounds issue in `cm_helper_translate_curve_to_degamma_hw_format` function. The issue could occur when the index \u0026apos;i\u0026apos; exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure \u0026apos;i\u0026apos; is within bounds before accessing the transfer function points. If \u0026apos;i\u0026apos; is out of bounds the function returns false to indicate an error. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:594 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.red\u0026apos; 1025 \u0026lt;= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:595 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.green\u0026apos; 1025 \u0026lt;= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:596 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.blue\u0026apos; 1025 \u0026lt;= s32max(CVE-2024-49894)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in DCN30 degamma hardware format translation This commit addresses a potential index out of bounds issue in the `cm3_helper_translate_curve_to_degamma_hw_format` function in the DCN30 color management module. The issue could occur when the index \u0026apos;i\u0026apos; exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure \u0026apos;i\u0026apos; is within bounds before accessing the transfer function points. If \u0026apos;i\u0026apos; is out of bounds, the function returns false to indicate an error. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:338 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.red\u0026apos; 1025 \u0026lt;= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:339 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.green\u0026apos; 1025 \u0026lt;= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:340 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.blue\u0026apos; 1025 \u0026lt;= s32max(CVE-2024-49895)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: jfs: Fix uninit-value access of new_ea in ea_buffer syzbot reports that lzo1x_1_do_compress is using uninit-value: ===================================================== BUG: KMSAN: uninit-value in lzo1x_1_do_compress+0x19f9/0x2510 lib/lzo/lzo1x_compress.c:178 ... Uninit was stored to memory at: ea_put fs/jfs/xattr.c:639 [inline] ... Local variable ea_buf created at: __jfs_setxattr+0x5d/0x1ae0 fs/jfs/xattr.c:662 __jfs_xattr_set+0xe6/0x1f0 fs/jfs/xattr.c:934 ===================================================== The reason is ea_buf-\u0026gt;new_ea is not initialized properly. Fix this by using memset to empty its content at the beginning in ea_get().(CVE-2024-49900)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: jfs: check if leafidx greater than num leaves per dmap tree syzbot report a out of bounds in dbSplit, it because dmt_leafidx greater than num leaves per dmap tree, add a checking for dmt_leafidx in dbFindLeaf. Shaggy: Modified sanity check to apply to control pages as well as leaf pages.(CVE-2024-49902)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: jfs: Fix uaf in dbFreeBits [syzbot reported] ================================================================== BUG: KASAN: slab-use-after-free in __mutex_lock_common kernel/locking/mutex.c:587 [inline] BUG: KASAN: slab-use-after-free in __mutex_lock+0xfe/0xd70 kernel/locking/mutex.c:752 Read of size 8 at addr ffff8880229254b0 by task syz-executor357/5216 CPU: 0 UID: 0 PID: 5216 Comm: syz-executor357 Not tainted 6.11.0-rc3-syzkaller-00156-gd7a5aa4b3c00 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024 Call Trace: \u0026lt;TASK\u0026gt; __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 __mutex_lock_common kernel/locking/mutex.c:587 [inline] __mutex_lock+0xfe/0xd70 kernel/locking/mutex.c:752 dbFreeBits+0x7ea/0xd90 fs/jfs/jfs_dmap.c:2390 dbFreeDmap fs/jfs/jfs_dmap.c:2089 [inline] dbFree+0x35b/0x680 fs/jfs/jfs_dmap.c:409 dbDiscardAG+0x8a9/0xa20 fs/jfs/jfs_dmap.c:1650 jfs_ioc_trim+0x433/0x670 fs/jfs/jfs_discard.c:100 jfs_ioctl+0x2d0/0x3e0 fs/jfs/ioctl.c:131 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 Freed by task 5218: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579 poison_slab_object+0xe0/0x150 mm/kasan/common.c:240 __kasan_slab_free+0x37/0x60 mm/kasan/common.c:256 kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2252 [inline] slab_free mm/slub.c:4473 [inline] kfree+0x149/0x360 mm/slub.c:4594 dbUnmount+0x11d/0x190 fs/jfs/jfs_dmap.c:278 jfs_mount_rw+0x4ac/0x6a0 fs/jfs/jfs_mount.c:247 jfs_remount+0x3d1/0x6b0 fs/jfs/super.c:454 reconfigure_super+0x445/0x880 fs/super.c:1083 vfs_cmd_reconfigure fs/fsopen.c:263 [inline] vfs_fsconfig_locked fs/fsopen.c:292 [inline] __do_sys_fsconfig fs/fsopen.c:473 [inline] __se_sys_fsconfig+0xb6e/0xf80 fs/fsopen.c:345 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f [Analysis] There are two paths (dbUnmount and jfs_ioc_trim) that generate race condition when accessing bmap, which leads to the occurrence of uaf. Use the lock s_umount to synchronize them, in order to avoid uaf caused by race condition.(CVE-2024-49903)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for function pointer in dcn20_set_output_transfer_func This commit adds a null check for the set_output_gamma function pointer in the dcn20_set_output_transfer_func function. Previously, set_output_gamma was being checked for null at line 1030, but then it was being dereferenced without any null check at line 1048. This could potentially lead to a null pointer dereference error if set_output_gamma is null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a null check for set_output_gamma before the call to set_output_gamma at line 1048.(CVE-2024-49911)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: x86/ioapic: Handle allocation failures gracefully Breno observed panics when using failslab under certain conditions during runtime: can not alloc irq_pin_list (-1,0,20) Kernel panic - not syncing: IO-APIC: failed to add irq-pin. Can not proceed panic+0x4e9/0x590 mp_irqdomain_alloc+0x9ab/0xa80 irq_domain_alloc_irqs_locked+0x25d/0x8d0 __irq_domain_alloc_irqs+0x80/0x110 mp_map_pin_to_irq+0x645/0x890 acpi_register_gsi_ioapic+0xe6/0x150 hpet_open+0x313/0x480 That\u0026apos;s a pointless panic which is a leftover of the historic IO/APIC code which panic\u0026apos;ed during early boot when the interrupt allocation failed. The only place which might justify panic is the PIT/HPET timer_check() code which tries to figure out whether the timer interrupt is delivered through the IO/APIC. But that code does not require to handle interrupt allocation failures. If the interrupt cannot be allocated then timer delivery fails and it either panics due to that or falls back to legacy mode. Cure this by removing the panic wrapper around __add_pin_to_irq_node() and making mp_irqdomain_alloc() aware of the failure condition and handle it as any other failure in this function gracefully.(CVE-2024-49927)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: jbd2: stop waiting for space when jbd2_cleanup_journal_tail() returns error In __jbd2_log_wait_for_space(), we might call jbd2_cleanup_journal_tail() to recover some journal space. But if an error occurs while executing jbd2_cleanup_journal_tail() (e.g., an EIO), we don\u0026apos;t stop waiting for free space right away, we try other branches, and if j_committing_transaction is NULL (i.e., the tid is 0), we will get the following complain: ============================================ JBD2: I/O error when updating journal superblock for sdd-8. __jbd2_log_wait_for_space: needed 256 blocks and only had 217 space available __jbd2_log_wait_for_space: no way to get more journal space in sdd-8 ------------[ cut here ]------------ WARNING: CPU: 2 PID: 139804 at fs/jbd2/checkpoint.c:109 __jbd2_log_wait_for_space+0x251/0x2e0 Modules linked in: CPU: 2 PID: 139804 Comm: kworker/u8:3 Not tainted 6.6.0+ #1 RIP: 0010:__jbd2_log_wait_for_space+0x251/0x2e0 Call Trace: \u0026lt;TASK\u0026gt; add_transaction_credits+0x5d1/0x5e0 start_this_handle+0x1ef/0x6a0 jbd2__journal_start+0x18b/0x340 ext4_dirty_inode+0x5d/0xb0 __mark_inode_dirty+0xe4/0x5d0 generic_update_time+0x60/0x70 [...] ============================================ So only if jbd2_cleanup_journal_tail() returns 1, i.e., there is nothing to clean up at the moment, continue to try to reclaim free space in other ways. Note that this fix relies on commit 6f6a6fda2945 (\u0026quot;jbd2: fix ocfs2 corrupt when updating journal superblock fails\u0026quot;) to make jbd2_cleanup_journal_tail return the correct error code.(CVE-2024-49959)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: ocfs2: remove unreasonable unlock in ocfs2_read_blocks Patch series \u0026quot;Misc fixes for ocfs2_read_blocks\u0026quot;, v5. This series contains 2 fixes for ocfs2_read_blocks(). The first patch fix the issue reported by syzbot, which detects bad unlock balance in ocfs2_read_blocks(). The second patch fixes an issue reported by Heming Zhao when reviewing above fix. This patch (of 2): There was a lock release before exiting, so remove the unreasonable unlock.(CVE-2024-49965)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: ocfs2: cancel dqi_sync_work before freeing oinfo ocfs2_global_read_info() will initialize and schedule dqi_sync_work at the end, if error occurs after successfully reading global quota, it will trigger the following warning with CONFIG_DEBUG_OBJECTS_* enabled: ODEBUG: free active (active state 0) object: 00000000d8b0ce28 object type: timer_list hint: qsync_work_fn+0x0/0x16c This reports that there is an active delayed work when freeing oinfo in error handling, so cancel dqi_sync_work first. BTW, return status instead of -1 when .read_file_info fails.(CVE-2024-49966)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in DCN30 color transformation This commit addresses a potential index out of bounds issue in the `cm3_helper_translate_curve_to_hw_format` function in the DCN30 color management module. The issue could occur when the index \u0026apos;i\u0026apos; exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure \u0026apos;i\u0026apos; is within bounds before accessing the transfer function points. If \u0026apos;i\u0026apos; is out of bounds, the function returns false to indicate an error. drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:180 cm3_helper_translate_curve_to_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.red\u0026apos; 1025 \u0026lt;= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:181 cm3_helper_translate_curve_to_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.green\u0026apos; 1025 \u0026lt;= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:182 cm3_helper_translate_curve_to_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.blue\u0026apos; 1025 \u0026lt;= s32max(CVE-2024-49969)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: NFSD: Limit the number of concurrent async COPY operations Nothing appears to limit the number of concurrent async COPY operations that clients can start. In addition, AFAICT each async COPY can copy an unlimited number of 4MB chunks, so can run for a long time. Thus IMO async COPY can become a DoS vector. Add a restriction mechanism that bounds the number of concurrent background COPY operations. Start simple and try to be fair -- this patch implements a per-namespace limit. An async COPY request that occurs while this limit is exceeded gets NFS4ERR_DELAY. The requesting client can choose to send the request again after a delay or fall back to a traditional read/write style copy. If there is need to make the mechanism more sophisticated, we can visit that in future patches.(CVE-2024-49974)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: i2c: stm32f7: Do not prepare/unprepare clock during runtime suspend/resume In case there is any sort of clock controller attached to this I2C bus controller, for example Versaclock or even an AIC32x4 I2C codec, then an I2C transfer triggered from the clock controller clk_ops .prepare callback may trigger a deadlock on drivers/clk/clk.c prepare_lock mutex. This is because the clock controller first grabs the prepare_lock mutex and then performs the prepare operation, including its I2C access. The I2C access resumes this I2C bus controller via .runtime_resume callback, which calls clk_prepare_enable(), which attempts to grab the prepare_lock mutex again and deadlocks. Since the clock are already prepared since probe() and unprepared in remove(), use simple clk_enable()/clk_disable() calls to enable and disable the clock on runtime suspend and resume, to avoid hitting the prepare_lock mutex.(CVE-2024-49985)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: scsi: fnic: Move flush_work initialization out of if block After commit 379a58caa199 (\u0026quot;scsi: fnic: Move fnic_fnic_flush_tx() to a work queue\u0026quot;), it can happen that a work item is sent to an uninitialized work queue. This may has the effect that the item being queued is never actually queued, and any further actions depending on it will not proceed. The following warning is observed while the fnic driver is loaded: kernel: WARNING: CPU: 11 PID: 0 at ../kernel/workqueue.c:1524 __queue_work+0x373/0x410 kernel: \u0026lt;IRQ\u0026gt; kernel: queue_work_on+0x3a/0x50 kernel: fnic_wq_copy_cmpl_handler+0x54a/0x730 [fnic 62fbff0c42e7fb825c60a55cde2fb91facb2ed24] kernel: fnic_isr_msix_wq_copy+0x2d/0x60 [fnic 62fbff0c42e7fb825c60a55cde2fb91facb2ed24] kernel: __handle_irq_event_percpu+0x36/0x1a0 kernel: handle_irq_event_percpu+0x30/0x70 kernel: handle_irq_event+0x34/0x60 kernel: handle_edge_irq+0x7e/0x1a0 kernel: __common_interrupt+0x3b/0xb0 kernel: common_interrupt+0x58/0xa0 kernel: \u0026lt;/IRQ\u0026gt; It has been observed that this may break the rediscovery of Fibre Channel devices after a temporary fabric failure. This patch fixes it by moving the work queue initialization out of an if block in fnic_probe().(CVE-2024-50025)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: net: do not delay dst_entries_add() in dst_release() dst_entries_add() uses per-cpu data that might be freed at netns dismantle from ip6_route_net_exit() calling dst_entries_destroy() Before ip6_route_net_exit() can be called, we release all the dsts associated with this netns, via calls to dst_release(), which waits an rcu grace period before calling dst_destroy() dst_entries_add() use in dst_destroy() is racy, because dst_entries_destroy() could have been called already. Decrementing the number of dsts must happen sooner. Notes: 1) in CONFIG_XFRM case, dst_destroy() can call dst_release_immediate(child), this might also cause UAF if the child does not have DST_NOCOUNT set. IPSEC maintainers might take a look and see how to address this. 2) There is also discussion about removing this count of dst, which might happen in future kernels.(CVE-2024-50036)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: NFSv4: Prevent NULL-pointer dereference in nfs42_complete_copies() On the node of an NFS client, some files saved in the mountpoint of the NFS server were copied to another location of the same NFS server. Accidentally, the nfs42_complete_copies() got a NULL-pointer dereference crash with the following syslog: [232064.838881] NFSv4: state recovery failed for open file nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116 [232064.839360] NFSv4: state recovery failed for open file nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116 [232066.588183] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000058 [232066.588586] Mem abort info: [232066.588701] ESR = 0x0000000096000007 [232066.588862] EC = 0x25: DABT (current EL), IL = 32 bits [232066.589084] SET = 0, FnV = 0 [232066.589216] EA = 0, S1PTW = 0 [232066.589340] FSC = 0x07: level 3 translation fault [232066.589559] Data abort info: [232066.589683] ISV = 0, ISS = 0x00000007 [232066.589842] CM = 0, WnR = 0 [232066.589967] user pgtable: 64k pages, 48-bit VAs, pgdp=00002000956ff400 [232066.590231] [0000000000000058] pgd=08001100ae100003, p4d=08001100ae100003, pud=08001100ae100003, pmd=08001100b3c00003, pte=0000000000000000 [232066.590757] Internal error: Oops: 96000007 [#1] SMP [232066.590958] Modules linked in: rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm vhost_net vhost vhost_iotlb tap tun ipt_rpfilter xt_multiport ip_set_hash_ip ip_set_hash_net xfrm_interface xfrm6_tunnel tunnel4 tunnel6 esp4 ah4 wireguard libcurve25519_generic veth xt_addrtype xt_set nf_conntrack_netlink ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_bitmap_port ip_set_hash_ipport dummy ip_set ip_vs_sh ip_vs_wrr ip_vs_rr ip_vs iptable_filter sch_ingress nfnetlink_cttimeout vport_gre ip_gre ip_tunnel gre vport_geneve geneve vport_vxlan vxlan ip6_udp_tunnel udp_tunnel openvswitch nf_conncount dm_round_robin dm_service_time dm_multipath xt_nat xt_MASQUERADE nft_chain_nat nf_nat xt_mark xt_conntrack xt_comment nft_compat nft_counter nf_tables nfnetlink ocfs2 ocfs2_nodemanager ocfs2_stackglue iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ipmi_ssif nbd overlay 8021q garp mrp bonding tls rfkill sunrpc ext4 mbcache jbd2 [232066.591052] vfat fat cas_cache cas_disk ses enclosure scsi_transport_sas sg acpi_ipmi ipmi_si ipmi_devintf ipmi_msghandler ip_tables vfio_pci vfio_pci_core vfio_virqfd vfio_iommu_type1 vfio dm_mirror dm_region_hash dm_log dm_mod nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter bridge stp llc fuse xfs libcrc32c ast drm_vram_helper qla2xxx drm_kms_helper syscopyarea crct10dif_ce sysfillrect ghash_ce sysimgblt sha2_ce fb_sys_fops cec sha256_arm64 sha1_ce drm_ttm_helper ttm nvme_fc igb sbsa_gwdt nvme_fabrics drm nvme_core i2c_algo_bit i40e scsi_transport_fc megaraid_sas aes_neon_bs [232066.596953] CPU: 6 PID: 4124696 Comm: 10.253.166.125- Kdump: loaded Not tainted 5.15.131-9.cl9_ocfs2.aarch64 #1 [232066.597356] Hardware name: Great Wall .\\x93\\x8e...RF6260 V5/GWMSSE2GL1T, BIOS T656FBE_V3.0.18 2024-01-06 [232066.597721] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [232066.598034] pc : nfs4_reclaim_open_state+0x220/0x800 [nfsv4] [232066.598327] lr : nfs4_reclaim_open_state+0x12c/0x800 [nfsv4] [232066.598595] sp : ffff8000f568fc70 [232066.598731] x29: ffff8000f568fc70 x28: 0000000000001000 x27: ffff21003db33000 [232066.599030] x26: ffff800005521ae0 x25: ffff0100f98fa3f0 x24: 0000000000000001 [232066.599319] x23: ffff800009920008 x22: ffff21003db33040 x21: ffff21003db33050 [232066.599628] x20: ffff410172fe9e40 x19: ffff410172fe9e00 x18: 0000000000000000 [232066.599914] x17: 0000000000000000 x16: 0000000000000004 x15: 0000000000000000 [232066.600195] x14: 0000000000000000 x13: ffff800008e685a8 x12: 00000000eac0c6e6 [232066.600498] x11: 00000000000000 ---truncated---(CVE-2024-50046)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointer before dereferencing se [WHAT \u0026amp; HOW] se is null checked previously in the same function, indicating it might be null; therefore, it must be checked when used again. This fixes 1 FORWARD_NULL issue reported by Coverity.(CVE-2024-50049)",
"id": "OESA-2024-2321",
"modified": "2026-08-06T11:07:47Z",
"published": "2024-11-01T11:07:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2321"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48916"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48952"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52917"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52918"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35878"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35990"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36286"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38605"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38635"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38667"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42152"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42301"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42315"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43841"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43858"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43867"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43871"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43894"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45009"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46675"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46689"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46722"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46724"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46757"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46802"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46830"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46853"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47667"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47669"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47684"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47685"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47692"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47695"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47698"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47709"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47710"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47720"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47735"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47737"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47757"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49866"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49867"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49868"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49875"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49892"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49894"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49895"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49900"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49902"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49903"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49911"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49927"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49959"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49965"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49966"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49969"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49974"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49985"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50025"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50036"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50046"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50049"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2022-48916",
"CVE-2022-48952",
"CVE-2023-52917",
"CVE-2023-52918",
"CVE-2024-35878",
"CVE-2024-35990",
"CVE-2024-36286",
"CVE-2024-38605",
"CVE-2024-38635",
"CVE-2024-38667",
"CVE-2024-42152",
"CVE-2024-42301",
"CVE-2024-42315",
"CVE-2024-43841",
"CVE-2024-43858",
"CVE-2024-43867",
"CVE-2024-43871",
"CVE-2024-43894",
"CVE-2024-45009",
"CVE-2024-46675",
"CVE-2024-46689",
"CVE-2024-46722",
"CVE-2024-46724",
"CVE-2024-46757",
"CVE-2024-46802",
"CVE-2024-46830",
"CVE-2024-46853",
"CVE-2024-47667",
"CVE-2024-47669",
"CVE-2024-47684",
"CVE-2024-47685",
"CVE-2024-47692",
"CVE-2024-47695",
"CVE-2024-47698",
"CVE-2024-47709",
"CVE-2024-47710",
"CVE-2024-47720",
"CVE-2024-47735",
"CVE-2024-47737",
"CVE-2024-47757",
"CVE-2024-49866",
"CVE-2024-49867",
"CVE-2024-49868",
"CVE-2024-49875",
"CVE-2024-49892",
"CVE-2024-49894",
"CVE-2024-49895",
"CVE-2024-49900",
"CVE-2024-49902",
"CVE-2024-49903",
"CVE-2024-49911",
"CVE-2024-49927",
"CVE-2024-49959",
"CVE-2024-49965",
"CVE-2024-49966",
"CVE-2024-49969",
"CVE-2024-49974",
"CVE-2024-49985",
"CVE-2024-50025",
"CVE-2024-50036",
"CVE-2024-50046",
"CVE-2024-50049"
]
}
OESA-2024-2322 (CVE-2022-48916)
Vulnerability from osv_openeuler – Published: 2024-11-01 11:07 – Updated: 2026-08-06 11:07 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
iommu/vt-d: Fix double list_add when enabling VMD in scalable mode
When enabling VMD and IOMMU scalable mode, the following kernel panic call trace/kernel log is shown in Eagle Stream platform (Sapphire Rapids CPU) during booting:
pci 0000:59:00.5: Adding to iommu group 42 ... vmd 0000:59:00.5: PCI host bridge to bus 10000:80 pci 10000:80:01.0: [8086:352a] type 01 class 0x060400 pci 10000:80:01.0: reg 0x10: [mem 0x00000000-0x0001ffff 64bit] pci 10000:80:01.0: enabling Extended Tags pci 10000:80:01.0: PME# supported from D0 D3hot D3cold pci 10000:80:01.0: DMAR: Setup RID2PASID failed pci 10000:80:01.0: Failed to add to iommu group 42: -16 pci 10000:80:03.0: [8086:352b] type 01 class 0x060400 pci 10000:80:03.0: reg 0x10: [mem 0x00000000-0x0001ffff 64bit] pci 10000:80:03.0: enabling Extended Tags pci 10000:80:03.0: PME# supported from D0 D3hot D3cold ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:29! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 7 Comm: kworker/0:1 Not tainted 5.17.0-rc3+ #7 Hardware name: Lenovo ThinkSystem SR650V3/SB27A86647, BIOS ESE101Y-1.00 01/13/2022 Workqueue: events work_for_cpu_fn RIP: 0010:__list_add_valid.cold+0x26/0x3f Code: 9a 4a ab ff 4c 89 c1 48 c7 c7 40 0c d9 9e e8 b9 b1 fe ff 0f 0b 48 89 f2 4c 89 c1 48 89 fe 48 c7 c7 f0 0c d9 9e e8 a2 b1 fe ff <0f> 0b 48 89 d1 4c 89 c6 4c 89 ca 48 c7 c7 98 0c d9 9e e8 8b b1 fe RSP: 0000:ff5ad434865b3a40 EFLAGS: 00010246 RAX: 0000000000000058 RBX: ff4d61160b74b880 RCX: ff4d61255e1fffa8 RDX: 0000000000000000 RSI: 00000000fffeffff RDI: ffffffff9fd34f20 RBP: ff4d611d8e245c00 R08: 0000000000000000 R09: ff5ad434865b3888 R10: ff5ad434865b3880 R11: ff4d61257fdc6fe8 R12: ff4d61160b74b8a0 R13: ff4d61160b74b8a0 R14: ff4d611d8e245c10 R15: ff4d611d8001ba70 FS: 0000000000000000(0000) GS:ff4d611d5ea00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ff4d611fa1401000 CR3: 0000000aa0210001 CR4: 0000000000771ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> intel_pasid_alloc_table+0x9c/0x1d0 dmar_insert_one_dev_info+0x423/0x540 ? device_to_iommu+0x12d/0x2f0 intel_iommu_attach_device+0x116/0x290 __iommu_attach_device+0x1a/0x90 iommu_group_add_device+0x190/0x2c0 __iommu_probe_device+0x13e/0x250 iommu_probe_device+0x24/0x150 iommu_bus_notifier+0x69/0x90 blocking_notifier_call_chain+0x5a/0x80 device_add+0x3db/0x7b0 ? arch_memremap_can_ram_remap+0x19/0x50 ? memremap+0x75/0x140 pci_device_add+0x193/0x1d0 pci_scan_single_device+0xb9/0xf0 pci_scan_slot+0x4c/0x110 pci_scan_child_bus_extend+0x3a/0x290 vmd_enable_domain.constprop.0+0x63e/0x820 vmd_probe+0x163/0x190 local_pci_probe+0x42/0x80 work_for_cpu_fn+0x13/0x20 process_one_work+0x1e2/0x3b0 worker_thread+0x1c4/0x3a0 ? rescuer_thread+0x370/0x370 kthread+0xc7/0xf0 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30 </TASK> Modules linked in: ---[ end trace 0000000000000000 ]--- ... Kernel panic - not syncing: Fatal exception Kernel Offset: 0x1ca00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) ---[ end Kernel panic - not syncing: Fatal exception ]---
The following 'lspci' output shows devices '10000:80:*' are subdevices of the VMD device 0000:59:00.5:
$ lspci ... 0000:59:00.5 RAID bus controller: Intel Corporation Volume Management Device NVMe RAID Controller (rev 20) ... 10000:80:01.0 PCI bridge: Intel Corporation Device 352a (rev 03) 10000:80:03.0 PCI bridge: Intel Corporation Device 352b (rev 03) 10000:80:05.0 PCI bridge: Intel Corporation Device 352c (rev 03) 10000:80:07.0 PCI bridge: Intel Corporation Device 352d (rev 03) 10000:81:00.0 Non-Volatile memory controller: Intel Corporation NVMe Datacenter SSD [3DNAND, Beta Rock Controller] 10000:82:00 ---truncated---(CVE-2022-48916)
In the Linux kernel, the following vulnerability has been resolved: PCI: mt7621: Add sentinel to quirks table Current driver is missing a sentinel in the struct soc_device_attribute array, which causes an oops when assessed by the soc_device_match(mt7621_pcie_quirks_match) call. This was only exposed once the CONFIG_SOC_MT7621 mt7621 soc_dev_attr was fixed to register the SOC as a device, in: commit 7c18b64bba3b ("mips: ralink: mt7621: do not use kzalloc too early") Fix it by adding the required sentinel.(CVE-2022-48952)
In the Linux kernel, the following vulnerability has been resolved: memcg: fix possible use-after-free in memcg_write_event_control() memcg_write_event_control() accesses the dentry->d_name of the specified control fd to route the write call. As a cgroup interface file can't be renamed, it's safe to access d_name as long as the specified file is a regular cgroup file. Also, as these cgroup interface files can't be removed before the directory, it's safe to access the parent too. Prior to 347c4a874710 ("memcg: remove cgroup_event->cft"), there was a call to __file_cft() which verified that the specified file is a regular cgroupfs file before further accesses. The cftype pointer returned from __file_cft() was no longer necessary and the commit inadvertently dropped the file type check with it allowing any file to slip through. With the invarients broken, the d_name and parent accesses can now race against renames and removals of arbitrary files and cause use-after-free's. Fix the bug by resurrecting the file type check in __file_cft(). Now that cgroupfs is implemented through kernfs, checking the file operations needs to go through a layer of indirection. Instead, let's check the superblock and dentry type.(CVE-2022-48988)
In the Linux kernel, the following vulnerability has been resolved: ntb: intel: Fix the NULL vs IS_ERR() bug for debugfs_create_dir() The debugfs_create_dir() function returns error pointers. It never returns NULL. So use IS_ERR() to check it.(CVE-2023-52917)
In the Linux kernel, the following vulnerability has been resolved: media: pci: cx23885: check cx23885_vdev_init() return cx23885_vdev_init() can return a NULL pointer, but that pointer is used in the next line without a check. Add a NULL pointer check and go to the error unwind if it is NULL.(CVE-2023-52918)
In the Linux kernel, the following vulnerability has been resolved: nfc: nci: fix possible NULL pointer dereference in send_acknowledge() Handle memory allocation failure from nci_skb_alloc() (calling alloc_skb()) to avoid possible NULL pointer dereference.(CVE-2023-52919)
In the Linux kernel, the following vulnerability has been resolved:
of: module: prevent NULL pointer dereference in vsnprintf()
In of_modalias(), we can get passed the str and len parameters which would cause a kernel oops in vsnprintf() since it only allows passing a NULL ptr when the length is also 0. Also, we need to filter out the negative values of the len parameter as these will result in a really huge buffer since snprintf() takes size_t parameter while ours is ssize_t...
Found by Linux Verification Center (linuxtesting.org) with the Svace static analysis tool.(CVE-2024-35878)
In the Linux kernel, the following vulnerability has been resolved:
dma: xilinx_dpdma: Fix locking
There are several places where either chan->lock or chan->vchan.lock was not held. Add appropriate locking. This fixes lockdep warnings like
[ 31.077578] ------------[ cut here ]------------ [ 31.077831] WARNING: CPU: 2 PID: 40 at drivers/dma/xilinx/xilinx_dpdma.c:834 xilinx_dpdma_chan_queue_transfer+0x274/0x5e0 [ 31.077953] Modules linked in: [ 31.078019] CPU: 2 PID: 40 Comm: kworker/u12:1 Not tainted 6.6.20+ #98 [ 31.078102] Hardware name: xlnx,zynqmp (DT) [ 31.078169] Workqueue: events_unbound deferred_probe_work_func [ 31.078272] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 31.078377] pc : xilinx_dpdma_chan_queue_transfer+0x274/0x5e0 [ 31.078473] lr : xilinx_dpdma_chan_queue_transfer+0x270/0x5e0 [ 31.078550] sp : ffffffc083bb2e10 [ 31.078590] x29: ffffffc083bb2e10 x28: 0000000000000000 x27: ffffff880165a168 [ 31.078754] x26: ffffff880164e920 x25: ffffff880164eab8 x24: ffffff880164d480 [ 31.078920] x23: ffffff880165a148 x22: ffffff880164e988 x21: 0000000000000000 [ 31.079132] x20: ffffffc082aa3000 x19: ffffff880164e880 x18: 0000000000000000 [ 31.079295] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 31.079453] x14: 0000000000000000 x13: ffffff8802263dc0 x12: 0000000000000001 [ 31.079613] x11: 0001ffc083bb2e34 x10: 0001ff880164e98f x9 : 0001ffc082aa3def [ 31.079824] x8 : 0001ffc082aa3dec x7 : 0000000000000000 x6 : 0000000000000516 [ 31.079982] x5 : ffffffc7f8d43000 x4 : ffffff88003c9c40 x3 : ffffffffffffffff [ 31.080147] x2 : ffffffc7f8d43000 x1 : 00000000000000c0 x0 : 0000000000000000 [ 31.080307] Call trace: [ 31.080340] xilinx_dpdma_chan_queue_transfer+0x274/0x5e0 [ 31.080518] xilinx_dpdma_issue_pending+0x11c/0x120 [ 31.080595] zynqmp_disp_layer_update+0x180/0x3ac [ 31.080712] zynqmp_dpsub_plane_atomic_update+0x11c/0x21c [ 31.080825] drm_atomic_helper_commit_planes+0x20c/0x684 [ 31.080951] drm_atomic_helper_commit_tail+0x5c/0xb0 [ 31.081139] commit_tail+0x234/0x294 [ 31.081246] drm_atomic_helper_commit+0x1f8/0x210 [ 31.081363] drm_atomic_commit+0x100/0x140 [ 31.081477] drm_client_modeset_commit_atomic+0x318/0x384 [ 31.081634] drm_client_modeset_commit_locked+0x8c/0x24c [ 31.081725] drm_client_modeset_commit+0x34/0x5c [ 31.081812] __drm_fb_helper_restore_fbdev_mode_unlocked+0x104/0x168 [ 31.081899] drm_fb_helper_set_par+0x50/0x70 [ 31.081971] fbcon_init+0x538/0xc48 [ 31.082047] visual_init+0x16c/0x23c [ 31.082207] do_bind_con_driver.isra.0+0x2d0/0x634 [ 31.082320] do_take_over_console+0x24c/0x33c [ 31.082429] do_fbcon_takeover+0xbc/0x1b0 [ 31.082503] fbcon_fb_registered+0x2d0/0x34c [ 31.082663] register_framebuffer+0x27c/0x38c [ 31.082767] __drm_fb_helper_initial_config_and_unlock+0x5c0/0x91c [ 31.082939] drm_fb_helper_initial_config+0x50/0x74 [ 31.083012] drm_fbdev_dma_client_hotplug+0xb8/0x108 [ 31.083115] drm_client_register+0xa0/0xf4 [ 31.083195] drm_fbdev_dma_setup+0xb0/0x1cc [ 31.083293] zynqmp_dpsub_drm_init+0x45c/0x4e0 [ 31.083431] zynqmp_dpsub_probe+0x444/0x5e0 [ 31.083616] platform_probe+0x8c/0x13c [ 31.083713] really_probe+0x258/0x59c [ 31.083793] __driver_probe_device+0xc4/0x224 [ 31.083878] driver_probe_device+0x70/0x1c0 [ 31.083961] __device_attach_driver+0x108/0x1e0 [ 31.084052] bus_for_each_drv+0x9c/0x100 [ 31.084125] __device_attach+0x100/0x298 [ 31.084207] device_initial_probe+0x14/0x20 [ 31.084292] bus_probe_device+0xd8/0xdc [ 31.084368] deferred_probe_work_func+0x11c/0x180 [ 31.084451] process_one_work+0x3ac/0x988 [ 31.084643] worker_thread+0x398/0x694 [ 31.084752] kthread+0x1bc/0x1c0 [ 31.084848] ret_from_fork+0x10/0x20 [ 31.084932] irq event stamp: 64549 [ 31.084970] hardirqs last enabled at (64548): [<ffffffc081adf35c>] _raw_spin_unlock_irqrestore+0x80/0x90 [ 31.085157] ---truncated---(CVE-2024-35990)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nfnetlink_queue: acquire rcu_read_lock() in instance_destroy_rcu()
syzbot reported that nf_reinject() could be called without rcu_read_lock() :
WARNING: suspicious RCU usage 6.9.0-rc7-syzkaller-02060-g5c1672705a1a #0 Not tainted
net/netfilter/nfnetlink_queue.c:263 suspicious rcu_dereference_check() usage!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 1 2 locks held by syz-executor.4/13427: #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_lock_acquire include/linux/rcupdate.h:329 [inline] #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_do_batch kernel/rcu/tree.c:2190 [inline] #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_core+0xa86/0x1830 kernel/rcu/tree.c:2471 #1: ffff88801ca92958 (&inst->lock){+.-.}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline] #1: ffff88801ca92958 (&inst->lock){+.-.}-{2:2}, at: nfqnl_flush net/netfilter/nfnetlink_queue.c:405 [inline] #1: ffff88801ca92958 (&inst->lock){+.-.}-{2:2}, at: instance_destroy_rcu+0x30/0x220 net/netfilter/nfnetlink_queue.c:172
stack backtrace: CPU: 0 PID: 13427 Comm: syz-executor.4 Not tainted 6.9.0-rc7-syzkaller-02060-g5c1672705a1a #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024 Call Trace: <IRQ> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 lockdep_rcu_suspicious+0x221/0x340 kernel/locking/lockdep.c:6712 nf_reinject net/netfilter/nfnetlink_queue.c:323 [inline] nfqnl_reinject+0x6ec/0x1120 net/netfilter/nfnetlink_queue.c:397 nfqnl_flush net/netfilter/nfnetlink_queue.c:410 [inline] instance_destroy_rcu+0x1ae/0x220 net/netfilter/nfnetlink_queue.c:172 rcu_do_batch kernel/rcu/tree.c:2196 [inline] rcu_core+0xafd/0x1830 kernel/rcu/tree.c:2471 handle_softirqs+0x2d6/0x990 kernel/softirq.c:554 __do_softirq kernel/softirq.c:588 [inline] invoke_softirq kernel/softirq.c:428 [inline] __irq_exit_rcu+0xf4/0x1c0 kernel/softirq.c:637 irq_exit_rcu+0x9/0x30 kernel/softirq.c:649 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1043 [inline] sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1043 </IRQ> <TASK>(CVE-2024-36286)
In the Linux kernel, the following vulnerability has been resolved:
soundwire: cadence: fix invalid PDI offset
For some reason, we add an offset to the PDI, presumably to skip the PDI0 and PDI1 which are reserved for BPT.
This code is however completely wrong and leads to an out-of-bounds access. We were just lucky so far since we used only a couple of PDIs and remained within the PDI array bounds.
A Fixes: tag is not provided since there are no known platforms where the out-of-bounds would be accessed, and the initial code had problems as well.
A follow-up patch completely removes this useless offset.(CVE-2024-38635)
In the Linux kernel, the following vulnerability has been resolved:
riscv: prevent pt_regs corruption for secondary idle threads
Top of the kernel thread stack should be reserved for pt_regs. However this is not the case for the idle threads of the secondary boot harts. Their stacks overlap with their pt_regs, so both may get corrupted.
Similar issue has been fixed for the primary hart, see c7cdd96eca28 ("riscv: prevent stack corruption by reserving task_pt_regs(p) early"). However that fix was not propagated to the secondary harts. The problem has been noticed in some CPU hotplug tests with V enabled. The function smp_callin stored several registers on stack, corrupting top of pt_regs structure including status field. As a result, kernel attempted to save or restore inexistent V context.(CVE-2024-38667)
In the Linux kernel, the following vulnerability has been resolved:
nvmet: fix a possible leak when destroy a ctrl during qp establishment
In nvmet_sq_destroy we capture sq->ctrl early and if it is non-NULL we know that a ctrl was allocated (in the admin connect request handler) and we need to release pending AERs, clear ctrl->sqs and sq->ctrl (for nvme-loop primarily), and drop the final reference on the ctrl.
However, a small window is possible where nvmet_sq_destroy starts (as a result of the client giving up and disconnecting) concurrently with the nvme admin connect cmd (which may be in an early stage). But before kill_and_confirm of sq->ref (i.e. the admin connect managed to get an sq live reference). In this case, sq->ctrl was allocated however after it was captured in a local variable in nvmet_sq_destroy. This prevented the final reference drop on the ctrl.
Solve this by re-capturing the sq->ctrl after all inflight request has completed, where for sure sq->ctrl reference is final, and move forward based on that.
This issue was observed in an environment with many hosts connecting multiple ctrls simoutanuosly, creating a delay in allocating a ctrl leading up to this race window.(CVE-2024-42152)
In the Linux kernel, the following vulnerability has been resolved:
dev/parport: fix the array out-of-bounds risk
Fixed array out-of-bounds issues caused by sprintf by replacing it with snprintf for safer data copying, ensuring the destination buffer is not overflowed.
Below is the stack trace I encountered during the actual issue:
[ 66.575408s] [pid:5118,cpu4,QThread,4]Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: do_hardware_base_addr+0xcc/0xd0 [parport] [ 66.575408s] [pid:5118,cpu4,QThread,5]CPU: 4 PID: 5118 Comm: QThread Tainted: G S W O 5.10.97-arm64-desktop #7100.57021.2 [ 66.575439s] [pid:5118,cpu4,QThread,6]TGID: 5087 Comm: EFileApp [ 66.575439s] [pid:5118,cpu4,QThread,7]Hardware name: HUAWEI HUAWEI QingYun PGUX-W515x-B081/SP1PANGUXM, BIOS 1.00.07 04/29/2024 [ 66.575439s] [pid:5118,cpu4,QThread,8]Call trace: [ 66.575469s] [pid:5118,cpu4,QThread,9] dump_backtrace+0x0/0x1c0 [ 66.575469s] [pid:5118,cpu4,QThread,0] show_stack+0x14/0x20 [ 66.575469s] [pid:5118,cpu4,QThread,1] dump_stack+0xd4/0x10c [ 66.575500s] [pid:5118,cpu4,QThread,2] panic+0x1d8/0x3bc [ 66.575500s] [pid:5118,cpu4,QThread,3] __stack_chk_fail+0x2c/0x38 [ 66.575500s] [pid:5118,cpu4,QThread,4] do_hardware_base_addr+0xcc/0xd0 parport
In the Linux kernel, the following vulnerability has been resolved:
exfat: fix potential deadlock on __exfat_get_dentry_set
When accessing a file with more entries than ES_MAX_ENTRY_NUM, the bh-array is allocated in __exfat_get_entry_set. The problem is that the bh-array is allocated with GFP_KERNEL. It does not make sense. In the following cases, a deadlock for sbi->s_lock between the two processes may occur.
CPU0 CPU1
---- ----
kswapd balance_pgdat lock(fs_reclaim) exfat_iterate lock(&sbi->s_lock) exfat_readdir exfat_get_uniname_from_ext_entry exfat_get_dentry_set __exfat_get_dentry_set kmalloc_array ... lock(fs_reclaim) ... evict exfat_evict_inode lock(&sbi->s_lock)
To fix this, let's allocate bh-array with GFP_NOFS.(CVE-2024-42315)
In the Linux kernel, the following vulnerability has been resolved:
wifi: virt_wifi: avoid reporting connection success with wrong SSID
When user issues a connection with a different SSID than the one virt_wifi has advertised, the __cfg80211_connect_result() will trigger the warning: WARN_ON(bss_not_found).
The issue is because the connection code in virt_wifi does not check the SSID from user space (it only checks the BSSID), and virt_wifi will call cfg80211_connect_result() with WLAN_STATUS_SUCCESS even if the SSID is different from the one virt_wifi has advertised. Eventually cfg80211 won't be able to find the cfg80211_bss and generate the warning.
Fixed it by checking the SSID (from user space) in the connection code.(CVE-2024-43841)
In the Linux kernel, the following vulnerability has been resolved:
jfs: Fix array-index-out-of-bounds in diFree(CVE-2024-43858)
In the Linux kernel, the following vulnerability has been resolved:
drm/nouveau: prime: fix refcount underflow
Calling nouveau_bo_ref() on a nouveau_bo without initializing it (and hence the backing ttm_bo) leads to a refcount underflow.
Instead of calling nouveau_bo_ref() in the unwind path of drm_gem_object_init(), clean things up manually.
(cherry picked from commit 1b93f3e89d03cfc576636e195466a0d728ad8de5)(CVE-2024-43867)
In the Linux kernel, the following vulnerability has been resolved:
devres: Fix memory leakage caused by driver API devm_free_percpu()
It will cause memory leakage when use driver API devm_free_percpu() to free memory allocated by devm_alloc_percpu(), fixed by using devres_release() instead of devres_destroy() within devm_free_percpu().(CVE-2024-43871)
In the Linux kernel, the following vulnerability has been resolved:
drm/client: fix null pointer dereference in drm_client_modeset_probe
In drm_client_modeset_probe(), the return value of drm_mode_duplicate() is assigned to modeset->mode, which will lead to a possible NULL pointer dereference on failure of drm_mode_duplicate(). Add a check to avoid npd.(CVE-2024-43894)
In the Linux kernel, the following vulnerability has been resolved:
mptcp: pm: only decrement add_addr_accepted for MPJ req
Adding the following warning ...
WARN_ON_ONCE(msk->pm.add_addr_accepted == 0)
... before decrementing the add_addr_accepted counter helped to find a bug when running the "remove single subflow" subtest from the mptcp_join.sh selftest.
Removing a 'subflow' endpoint will first trigger a RM_ADDR, then the subflow closure. Before this patch, and upon the reception of the RM_ADDR, the other peer will then try to decrement this add_addr_accepted. That's not correct because the attached subflows have not been created upon the reception of an ADD_ADDR.
A way to solve that is to decrement the counter only if the attached subflow was an MP_JOIN to a remote id that was not 0, and initiated by the host receiving the RM_ADDR.(CVE-2024-45009)
In the Linux kernel, the following vulnerability has been resolved:
usb: dwc3: core: Prevent USB core invalid event buffer address access
This commit addresses an issue where the USB core could access an invalid event buffer address during runtime suspend, potentially causing SMMU faults and other memory issues in Exynos platforms. The problem arises from the following sequence. 1. In dwc3_gadget_suspend, there is a chance of a timeout when moving the USB core to the halt state after clearing the run/stop bit by software. 2. In dwc3_core_exit, the event buffer is cleared regardless of the USB core's status, which may lead to an SMMU faults and other memory issues. if the USB core tries to access the event buffer address.
To prevent this hardware quirk on Exynos platforms, this commit ensures that the event buffer address is not cleared by software when the USB core is active during runtime suspend by checking its status before clearing the buffer address.(CVE-2024-46675)
In the Linux kernel, the following vulnerability has been resolved:
soc: qcom: cmd-db: Map shared memory as WC, not WB
Linux does not write into cmd-db region. This region of memory is write protected by XPU. XPU may sometime falsely detect clean cache eviction as "write" into the write protected region leading to secure interrupt which causes an endless loop somewhere in Trust Zone.
The only reason it is working right now is because Qualcomm Hypervisor maps the same region as Non-Cacheable memory in Stage 2 translation tables. The issue manifests if we want to use another hypervisor (like Xen or KVM), which does not know anything about those specific mappings.
Changing the mapping of cmd-db memory from MEMREMAP_WB to MEMREMAP_WT/WC removes dependency on correct mappings in Stage 2 tables. This patch fixes the issue by updating the mapping to MEMREMAP_WC.
I tested this on SA8155P with Xen.(CVE-2024-46689)
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: fix mc_data out-of-bounds read warning
Clear warning that read mc_data[i-1] may out-of-bounds.(CVE-2024-46722)
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Fix out-of-bounds read of df_v1_7_channel_number
Check the fb_channel_number range to avoid the array out-of-bounds read error(CVE-2024-46724)
In the Linux kernel, the following vulnerability has been resolved:
hwmon: (nct6775-core) Fix underflows seen when writing limit attributes
DIV_ROUND_CLOSEST() after kstrtol() results in an underflow if a large negative number such as -9223372036854775808 is provided by the user. Fix it by reordering clamp_val() and DIV_ROUND_CLOSEST() operations.(CVE-2024-46757)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: added NULL check at start of dc_validate_stream
[Why] prevent invalid memory access
[How] check if dc and stream are NULL(CVE-2024-46802)
In the Linux kernel, the following vulnerability has been resolved:
KVM: x86: Acquire kvm->srcu when handling KVM_SET_VCPU_EVENTS
Grab kvm->srcu when processing KVM_SET_VCPU_EVENTS, as KVM will forcibly leave nested VMX/SVM if SMM mode is being toggled, and leaving nested VMX reads guest memory.
Note, kvm_vcpu_ioctl_x86_set_vcpu_events() can also be called from KVM_RUN via sync_regs(), which already holds SRCU. I.e. trying to precisely use kvm_vcpu_srcu_read_lock() around the problematic SMM code would cause problems. Acquiring SRCU isn't all that expensive, so for simplicity, grab it unconditionally for KVM_SET_VCPU_EVENTS.
============================= WARNING: suspicious RCU usage 6.10.0-rc7-332d2c1d713e-next-vm #552 Not tainted
include/linux/kvm_host.h:1027 suspicious rcu_dereference_check() usage!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 1 1 lock held by repro/1071: #0: ffff88811e424430 (&vcpu->mutex){+.+.}-{3:3}, at: kvm_vcpu_ioctl+0x7d/0x970 [kvm]
stack backtrace: CPU: 15 PID: 1071 Comm: repro Not tainted 6.10.0-rc7-332d2c1d713e-next-vm #552 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: <TASK> dump_stack_lvl+0x7f/0x90 lockdep_rcu_suspicious+0x13f/0x1a0 kvm_vcpu_gfn_to_memslot+0x168/0x190 [kvm] kvm_vcpu_read_guest+0x3e/0x90 [kvm] nested_vmx_load_msr+0x6b/0x1d0 [kvm_intel] load_vmcs12_host_state+0x432/0xb40 [kvm_intel] vmx_leave_nested+0x30/0x40 [kvm_intel] kvm_vcpu_ioctl_x86_set_vcpu_events+0x15d/0x2b0 [kvm] kvm_arch_vcpu_ioctl+0x1107/0x1750 [kvm] ? mark_held_locks+0x49/0x70 ? kvm_vcpu_ioctl+0x7d/0x970 [kvm] ? kvm_vcpu_ioctl+0x497/0x970 [kvm] kvm_vcpu_ioctl+0x497/0x970 [kvm] ? lock_acquire+0xba/0x2d0 ? find_held_lock+0x2b/0x80 ? do_user_addr_fault+0x40c/0x6f0 ? lock_release+0xb7/0x270 __x64_sys_ioctl+0x82/0xb0 do_syscall_64+0x6c/0x170 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7ff11eb1b539 </TASK>(CVE-2024-46830)
In the Linux kernel, the following vulnerability has been resolved:
spi: nxp-fspi: fix the KASAN report out-of-bounds bug
Change the memcpy length to fix the out-of-bounds issue when writing the data that is not 4 byte aligned to TX FIFO.
To reproduce the issue, write 3 bytes data to NOR chip.
dd if=3b of=/dev/mtd0 [ 36.926103] ================================================================== [ 36.933409] BUG: KASAN: slab-out-of-bounds in nxp_fspi_exec_op+0x26ec/0x2838 [ 36.940514] Read of size 4 at addr ffff00081037c2a0 by task dd/455 [ 36.946721] [ 36.948235] CPU: 3 UID: 0 PID: 455 Comm: dd Not tainted 6.11.0-rc5-gc7b0e37c8434 #1070 [ 36.956185] Hardware name: Freescale i.MX8QM MEK (DT) [ 36.961260] Call trace: [ 36.963723] dump_backtrace+0x90/0xe8 [ 36.967414] show_stack+0x18/0x24 [ 36.970749] dump_stack_lvl+0x78/0x90 [ 36.974451] print_report+0x114/0x5cc [ 36.978151] kasan_report+0xa4/0xf0 [ 36.981670] __asan_report_load_n_noabort+0x1c/0x28 [ 36.986587] nxp_fspi_exec_op+0x26ec/0x2838 [ 36.990800] spi_mem_exec_op+0x8ec/0xd30 [ 36.994762] spi_mem_no_dirmap_read+0x190/0x1e0 [ 36.999323] spi_mem_dirmap_write+0x238/0x32c [ 37.003710] spi_nor_write_data+0x220/0x374 [ 37.007932] spi_nor_write+0x110/0x2e8 [ 37.011711] mtd_write_oob_std+0x154/0x1f0 [ 37.015838] mtd_write_oob+0x104/0x1d0 [ 37.019617] mtd_write+0xb8/0x12c [ 37.022953] mtdchar_write+0x224/0x47c [ 37.026732] vfs_write+0x1e4/0x8c8 [ 37.030163] ksys_write+0xec/0x1d0 [ 37.033586] __arm64_sys_write+0x6c/0x9c [ 37.037539] invoke_syscall+0x6c/0x258 [ 37.041327] el0_svc_common.constprop.0+0x160/0x22c [ 37.046244] do_el0_svc+0x44/0x5c [ 37.049589] el0_svc+0x38/0x78 [ 37.052681] el0t_64_sync_handler+0x13c/0x158 [ 37.057077] el0t_64_sync+0x190/0x194 [ 37.060775] [ 37.062274] Allocated by task 455: [ 37.065701] kasan_save_stack+0x2c/0x54 [ 37.069570] kasan_save_track+0x20/0x3c [ 37.073438] kasan_save_alloc_info+0x40/0x54 [ 37.077736] __kasan_kmalloc+0xa0/0xb8 [ 37.081515] __kmalloc_noprof+0x158/0x2f8 [ 37.085563] mtd_kmalloc_up_to+0x120/0x154 [ 37.089690] mtdchar_write+0x130/0x47c [ 37.093469] vfs_write+0x1e4/0x8c8 [ 37.096901] ksys_write+0xec/0x1d0 [ 37.100332] __arm64_sys_write+0x6c/0x9c [ 37.104287] invoke_syscall+0x6c/0x258 [ 37.108064] el0_svc_common.constprop.0+0x160/0x22c [ 37.112972] do_el0_svc+0x44/0x5c [ 37.116319] el0_svc+0x38/0x78 [ 37.119401] el0t_64_sync_handler+0x13c/0x158 [ 37.123788] el0t_64_sync+0x190/0x194 [ 37.127474] [ 37.128977] The buggy address belongs to the object at ffff00081037c2a0 [ 37.128977] which belongs to the cache kmalloc-8 of size 8 [ 37.141177] The buggy address is located 0 bytes inside of [ 37.141177] allocated 3-byte region [ffff00081037c2a0, ffff00081037c2a3) [ 37.153465] [ 37.154971] The buggy address belongs to the physical page: [ 37.160559] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x89037c [ 37.168596] flags: 0xbfffe0000000000(node=0|zone=2|lastcpupid=0x1ffff) [ 37.175149] page_type: 0xfdffffff(slab) [ 37.179021] raw: 0bfffe0000000000 ffff000800002500 dead000000000122 0000000000000000 [ 37.186788] raw: 0000000000000000 0000000080800080 00000001fdffffff 0000000000000000 [ 37.194553] page dumped because: kasan: bad access detected [ 37.200144] [ 37.201647] Memory state around the buggy address: [ 37.206460] ffff00081037c180: fa fc fc fc fa fc fc fc fa fc fc fc fa fc fc fc [ 37.213701] ffff00081037c200: fa fc fc fc 05 fc fc fc 03 fc fc fc 02 fc fc fc [ 37.220946] >ffff00081037c280: 06 fc fc fc 03 fc fc fc fc fc fc fc fc fc fc fc [ 37.228186] ^ [ 37.232473] ffff00081037c300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 37.239718] ffff00081037c380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 37.246962] ============================================================== ---truncated---(CVE-2024-46853)
In the Linux kernel, the following vulnerability has been resolved:
PCI: keystone: Add workaround for Errata #i2037 (AM65x SR 1.0)
Errata #i2037 in AM65x/DRA80xM Processors Silicon Revision 1.0 (SPRZ452D_July 2018_Revised December 2019 [1]) mentions when an inbound PCIe TLP spans more than two internal AXI 128-byte bursts, the bus may corrupt the packet payload and the corrupt data may cause associated applications or the processor to hang.
The workaround for Errata #i2037 is to limit the maximum read request size and maximum payload size to 128 bytes. Add workaround for Errata #i2037 here.
The errata and workaround is applicable only to AM65x SR 1.0 and later versions of the silicon will have this fixed.
[1] -> https://www.ti.com/lit/er/sprz452i/sprz452i.pdf(CVE-2024-47667)
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix state management in error path of log writing function
After commit a694291a6211 ("nilfs2: separate wait function from nilfs_segctor_write") was applied, the log writing function nilfs_segctor_do_construct() was able to issue I/O requests continuously even if user data blocks were split into multiple logs across segments, but two potential flaws were introduced in its error handling.
First, if nilfs_segctor_begin_construction() fails while creating the second or subsequent logs, the log writing function returns without calling nilfs_segctor_abort_construction(), so the writeback flag set on pages/folios will remain uncleared. This causes page cache operations to hang waiting for the writeback flag. For example, truncate_inode_pages_final(), which is called via nilfs_evict_inode() when an inode is evicted from memory, will hang.
Second, the NILFS_I_COLLECTED flag set on normal inodes remain uncleared. As a result, if the next log write involves checkpoint creation, that's fine, but if a partial log write is performed that does not, inodes with NILFS_I_COLLECTED set are erroneously removed from the "sc_dirty_files" list, and their data and b-tree blocks may not be written to the device, corrupting the block mapping.
Fix these issues by uniformly calling nilfs_segctor_abort_construction() on failure of each step in the loop in nilfs_segctor_do_construct(), having it clean up logs and segment usages according to progress, and correcting the conditions for calling nilfs_redirty_inodes() to ensure that the NILFS_I_COLLECTED flag is cleared.(CVE-2024-47669)
In the Linux kernel, the following vulnerability has been resolved: tcp: check skb is non-NULL in tcp_rto_delta_us() We have some machines running stock Ubuntu 20.04.6 which is their 5.4.0-174-generic kernel that are running ceph and recently hit a null ptr dereference in tcp_rearm_rto(). Initially hitting it from the TLP path, but then later we also saw it getting hit from the RACK case as well. Here are examples of the oops messages we saw in each of those cases: Jul 26 15:05:02 rx [11061395.780353] BUG: kernel NULL pointer dereference, address: 0000000000000020 Jul 26 15:05:02 rx [11061395.787572] #PF: supervisor read access in kernel mode Jul 26 15:05:02 rx [11061395.792971] #PF: error_code(0x0000) - not-present page Jul 26 15:05:02 rx [11061395.798362] PGD 0 P4D 0 Jul 26 15:05:02 rx [11061395.801164] Oops: 0000 [#1] SMP NOPTI Jul 26 15:05:02 rx [11061395.805091] CPU: 0 PID: 9180 Comm: msgr-worker-1 Tainted: G W 5.4.0-174-generic #193-Ubuntu Jul 26 15:05:02 rx [11061395.814996] Hardware name: Supermicro SMC 2x26 os-gen8 64C NVME-Y 256G/H12SSW-NTR, BIOS 2.5.V1.2U.NVMe.UEFI 05/09/2023 Jul 26 15:05:02 rx [11061395.825952] RIP: 0010:tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.830656] Code: 87 ca 04 00 00 00 5b 41 5c 41 5d 5d c3 c3 49 8b bc 24 40 06 00 00 eb 8d 48 bb cf f7 53 e3 a5 9b c4 20 4c 89 ef e8 0c fe 0e 00 <48> 8b 78 20 48 c1 ef 03 48 89 f8 41 8b bc 24 80 04 00 00 48 f7 e3 Jul 26 15:05:02 rx [11061395.849665] RSP: 0018:ffffb75d40003e08 EFLAGS: 00010246 Jul 26 15:05:02 rx [11061395.855149] RAX: 0000000000000000 RBX: 20c49ba5e353f7cf RCX: 0000000000000000 Jul 26 15:05:02 rx [11061395.862542] RDX: 0000000062177c30 RSI: 000000000000231c RDI: ffff9874ad283a60 Jul 26 15:05:02 rx [11061395.869933] RBP: ffffb75d40003e20 R08: 0000000000000000 R09: ffff987605e20aa8 Jul 26 15:05:02 rx [11061395.877318] R10: ffffb75d40003f00 R11: ffffb75d4460f740 R12: ffff9874ad283900 Jul 26 15:05:02 rx [11061395.884710] R13: ffff9874ad283a60 R14: ffff9874ad283980 R15: ffff9874ad283d30 Jul 26 15:05:02 rx [11061395.892095] FS: 00007f1ef4a2e700(0000) GS:ffff987605e00000(0000) knlGS:0000000000000000 Jul 26 15:05:02 rx [11061395.900438] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Jul 26 15:05:02 rx [11061395.906435] CR2: 0000000000000020 CR3: 0000003e450ba003 CR4: 0000000000760ef0 Jul 26 15:05:02 rx [11061395.913822] PKRU: 55555554 Jul 26 15:05:02 rx [11061395.916786] Call Trace: Jul 26 15:05:02 rx [11061395.919488] Jul 26 15:05:02 rx [11061395.921765] ? show_regs.cold+0x1a/0x1f Jul 26 15:05:02 rx [11061395.925859] ? __die+0x90/0xd9 Jul 26 15:05:02 rx [11061395.929169] ? no_context+0x196/0x380 Jul 26 15:05:02 rx [11061395.933088] ? ip6_protocol_deliver_rcu+0x4e0/0x4e0 Jul 26 15:05:02 rx [11061395.938216] ? ip6_sublist_rcv_finish+0x3d/0x50 Jul 26 15:05:02 rx [11061395.943000] ? __bad_area_nosemaphore+0x50/0x1a0 Jul 26 15:05:02 rx [11061395.947873] ? bad_area_nosemaphore+0x16/0x20 Jul 26 15:05:02 rx [11061395.952486] ? do_user_addr_fault+0x267/0x450 Jul 26 15:05:02 rx [11061395.957104] ? ipv6_list_rcv+0x112/0x140 Jul 26 15:05:02 rx [11061395.961279] ? __do_page_fault+0x58/0x90 Jul 26 15:05:02 rx [11061395.965458] ? do_page_fault+0x2c/0xe0 Jul 26 15:05:02 rx [11061395.969465] ? page_fault+0x34/0x40 Jul 26 15:05:02 rx [11061395.973217] ? tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.977313] ? tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.981408] tcp_send_loss_probe+0x10b/0x220 Jul 26 15:05:02 rx [11061395.985937] tcp_write_timer_handler+0x1b4/0x240 Jul 26 15:05:02 rx [11061395.990809] tcp_write_timer+0x9e/0xe0 Jul 26 15:05:02 rx [11061395.994814] ? tcp_write_timer_handler+0x240/0x240 Jul 26 15:05:02 rx [11061395.999866] call_timer_fn+0x32/0x130 Jul 26 15:05:02 rx [11061396.003782] __run_timers.part.0+0x180/0x280 Jul 26 15:05:02 rx [11061396.008309] ? recalibrate_cpu_khz+0x10/0x10 Jul 26 15:05:02 rx [11061396.012841] ? native_x2apic_icr_write+0x30/0x30 Jul 26 15:05:02 rx [11061396.017718] ? lapic_next_even ---truncated---(CVE-2024-47684)
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_reject_ipv6: fix nf_reject_ip6_tcphdr_put() syzbot reported that nf_reject_ip6_tcphdr_put() was possibly sending garbage on the four reserved tcp bits (th->res1) Use skb_put_zero() to clear the whole TCP header, as done in nf_reject_ip_tcphdr_put() BUG: KMSAN: uninit-value in nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255 nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255 nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344 nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core net/core/dev.c:5661 [inline] __netif_receive_skb+0x1da/0xa00 net/core/dev.c:5775 process_backlog+0x4ad/0xa50 net/core/dev.c:6108 __napi_poll+0xe7/0x980 net/core/dev.c:6772 napi_poll net/core/dev.c:6841 [inline] net_rx_action+0xa5a/0x19b0 net/core/dev.c:6963 handle_softirqs+0x1ce/0x800 kernel/softirq.c:554 __do_softirq+0x14/0x1a kernel/softirq.c:588 do_softirq+0x9a/0x100 kernel/softirq.c:455 __local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:382 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:908 [inline] __dev_queue_xmit+0x2692/0x5610 net/core/dev.c:4450 dev_queue_xmit include/linux/netdevice.h:3105 [inline] neigh_resolve_output+0x9ca/0xae0 net/core/neighbour.c:1565 neigh_output include/net/neighbour.h:542 [inline] ip6_finish_output2+0x2347/0x2ba0 net/ipv6/ip6_output.c:141 __ip6_finish_output net/ipv6/ip6_output.c:215 [inline] ip6_finish_output+0xbb8/0x14b0 net/ipv6/ip6_output.c:226 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip6_output+0x356/0x620 net/ipv6/ip6_output.c:247 dst_output include/net/dst.h:450 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] ip6_xmit+0x1ba6/0x25d0 net/ipv6/ip6_output.c:366 inet6_csk_xmit+0x442/0x530 net/ipv6/inet6_connection_sock.c:135 __tcp_transmit_skb+0x3b07/0x4880 net/ipv4/tcp_output.c:1466 tcp_transmit_skb net/ipv4/tcp_output.c:1484 [inline] tcp_connect+0x35b6/0x7130 net/ipv4/tcp_output.c:4143 tcp_v6_connect+0x1bcc/0x1e40 net/ipv6/tcp_ipv6.c:333 __inet_stream_connect+0x2ef/0x1730 net/ipv4/af_inet.c:679 inet_stream_connect+0x6a/0xd0 net/ipv4/af_inet.c:750 __sys_connect_file net/socket.c:2061 [inline] __sys_connect+0x606/0x690 net/socket.c:2078 __do_sys_connect net/socket.c:2088 [inline] __se_sys_connect net/socket.c:2085 [inline] __x64_sys_connect+0x91/0xe0 net/socket.c:2085 x64_sys_call+0x27a5/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:43 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit was stored to memory at: nf_reject_ip6_tcphdr_put+0x60c/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:249 nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344 nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core ---truncated---(CVE-2024-47685)
In the Linux kernel, the following vulnerability has been resolved: nfsd: return -EINVAL when namelen is 0 When we have a corrupted main.sqlite in /var/lib/nfs/nfsdcld/, it may result in namelen being 0, which will cause memdup_user() to return ZERO_SIZE_PTR. When we access the name.data that has been assigned the value of ZERO_SIZE_PTR in nfs4_client_to_reclaim(), null pointer dereference is triggered. [ T1205] ================================================================== [ T1205] BUG: KASAN: null-ptr-deref in nfs4_client_to_reclaim+0xe9/0x260 [ T1205] Read of size 1 at addr 0000000000000010 by task nfsdcld/1205 [ T1205] [ T1205] CPU: 11 PID: 1205 Comm: nfsdcld Not tainted 5.10.0-00003-g2c1423731b8d #406 [ T1205] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014 [ T1205] Call Trace: [ T1205] dump_stack+0x9a/0xd0 [ T1205] ? nfs4_client_to_reclaim+0xe9/0x260 [ T1205] __kasan_report.cold+0x34/0x84 [ T1205] ? nfs4_client_to_reclaim+0xe9/0x260 [ T1205] kasan_report+0x3a/0x50 [ T1205] nfs4_client_to_reclaim+0xe9/0x260 [ T1205] ? nfsd4_release_lockowner+0x410/0x410 [ T1205] cld_pipe_downcall+0x5ca/0x760 [ T1205] ? nfsd4_cld_tracking_exit+0x1d0/0x1d0 [ T1205] ? down_write_killable_nested+0x170/0x170 [ T1205] ? avc_policy_seqno+0x28/0x40 [ T1205] ? selinux_file_permission+0x1b4/0x1e0 [ T1205] rpc_pipe_write+0x84/0xb0 [ T1205] vfs_write+0x143/0x520 [ T1205] ksys_write+0xc9/0x170 [ T1205] ? __ia32_sys_read+0x50/0x50 [ T1205] ? ktime_get_coarse_real_ts64+0xfe/0x110 [ T1205] ? ktime_get_coarse_real_ts64+0xa2/0x110 [ T1205] do_syscall_64+0x33/0x40 [ T1205] entry_SYSCALL_64_after_hwframe+0x67/0xd1 [ T1205] RIP: 0033:0x7fdbdb761bc7 [ T1205] Code: 0f 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 514 [ T1205] RSP: 002b:00007fff8c4b7248 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ T1205] RAX: ffffffffffffffda RBX: 000000000000042b RCX: 00007fdbdb761bc7 [ T1205] RDX: 000000000000042b RSI: 00007fff8c4b75f0 RDI: 0000000000000008 [ T1205] RBP: 00007fdbdb761bb0 R08: 0000000000000000 R09: 0000000000000001 [ T1205] R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000042b [ T1205] R13: 0000000000000008 R14: 00007fff8c4b75f0 R15: 0000000000000000 [ T1205] ================================================================== Fix it by checking namelen.(CVE-2024-47692)
In the Linux kernel, the following vulnerability has been resolved: RDMA/rtrs-clt: Reset cid to con_num - 1 to stay in bounds In the function init_conns(), after the create_con() and create_cm() for loop if something fails. In the cleanup for loop after the destroy tag, we access out of bound memory because cid is set to clt_path->s.con_num. This commits resets the cid to clt_path->s.con_num - 1, to stay in bounds in the cleanup loop later.(CVE-2024-47695)
In the Linux kernel, the following vulnerability has been resolved: drivers: media: dvb-frontends/rtl2832: fix an out-of-bounds write error Ensure index in rtl2832_pid_filter does not exceed 31 to prevent out-of-bounds access. dev->filters is a 32-bit value, so set_bit and clear_bit functions should only operate on indices from 0 to 31. If index is 32, it will attempt to access a non-existent 33rd bit, leading to out-of-bounds access. Change the boundary check from index > 32 to index >= 32 to resolve this issue. hverkuil: added fixes tag, rtl2830_pid_filter -> rtl2832_pid_filter in logmsg
In the Linux kernel, the following vulnerability has been resolved: can: bcm: Clear bo->bcm_proc_read after remove_proc_entry(). syzbot reported a warning in bcm_release(). [0] The blamed change fixed another warning that is triggered when connect() is issued again for a socket whose connect()ed device has been unregistered. However, if the socket is just close()d without the 2nd connect(), the remaining bo->bcm_proc_read triggers unnecessary remove_proc_entry() in bcm_release(). Let's clear bo->bcm_proc_read after remove_proc_entry() in bcm_notify(). [0] name '4986' WARNING: CPU: 0 PID: 5234 at fs/proc/generic.c:711 remove_proc_entry+0x2e7/0x5d0 fs/proc/generic.c:711 Modules linked in: CPU: 0 UID: 0 PID: 5234 Comm: syz-executor606 Not tainted 6.11.0-rc5-syzkaller-00178-g5517ae241919 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:remove_proc_entry+0x2e7/0x5d0 fs/proc/generic.c:711 Code: ff eb 05 e8 cb 1e 5e ff 48 8b 5c 24 10 48 c7 c7 e0 f7 aa 8e e8 2a 38 8e 09 90 48 c7 c7 60 3a 1b 8c 48 89 de e8 da 42 20 ff 90 <0f> 0b 90 90 48 8b 44 24 18 48 c7 44 24 40 0e 36 e0 45 49 c7 04 07 RSP: 0018:ffffc9000345fa20 EFLAGS: 00010246 RAX: 2a2d0aee2eb64600 RBX: ffff888032f1f548 RCX: ffff888029431e00 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffc9000345fb08 R08: ffffffff8155b2f2 R09: 1ffff1101710519a R10: dffffc0000000000 R11: ffffed101710519b R12: ffff888011d38640 R13: 0000000000000004 R14: 0000000000000000 R15: dffffc0000000000 FS: 0000000000000000(0000) GS:ffff8880b8800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fcfb52722f0 CR3: 000000000e734000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> bcm_release+0x250/0x880 net/can/bcm.c:1578 __sock_release net/socket.c:659 [inline] sock_close+0xbc/0x240 net/socket.c:1421 __fput+0x24a/0x8a0 fs/file_table.c:422 task_work_run+0x24f/0x310 kernel/task_work.c:228 exit_task_work include/linux/task_work.h:40 [inline] do_exit+0xa2f/0x27f0 kernel/exit.c:882 do_group_exit+0x207/0x2c0 kernel/exit.c:1031 __do_sys_exit_group kernel/exit.c:1042 [inline] __se_sys_exit_group kernel/exit.c:1040 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1040 x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fcfb51ee969 Code: Unable to access opcode bytes at 0x7fcfb51ee93f. RSP: 002b:00007ffce0109ca8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007fcfb51ee969 RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000001 RBP: 00007fcfb526f3b0 R08: ffffffffffffffb8 R09: 0000555500000000 R10: 0000555500000000 R11: 0000000000000246 R12: 00007fcfb526f3b0 R13: 0000000000000000 R14: 00007fcfb5271ee0 R15: 00007fcfb51bf160 </TASK>(CVE-2024-47709)
In the Linux kernel, the following vulnerability has been resolved: sock_map: Add a cond_resched() in sock_hash_free() Several syzbot soft lockup reports all have in common sock_hash_free() If a map with a large number of buckets is destroyed, we need to yield the cpu when needed.(CVE-2024-47710)
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for set_output_gamma in dcn30_set_output_transfer_func This commit adds a null check for the set_output_gamma function pointer in the dcn30_set_output_transfer_func function. Previously, set_output_gamma was being checked for nullity at line 386, but then it was being dereferenced without any nullity check at line 401. This could potentially lead to a null pointer dereference error if set_output_gamma is indeed null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a nullity check for set_output_gamma before the call to set_output_gamma at line 401. If set_output_gamma is null, we log an error message and do not call the function. This fix prevents a potential null pointer dereference error. drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:401 dcn30_set_output_transfer_func() error: we previously assumed 'mpc->funcs->set_output_gamma' could be null (see line 386) drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c 373 bool dcn30_set_output_transfer_func(struct dc dc, 374 struct pipe_ctx pipe_ctx, 375 const struct dc_stream_state stream) 376 { 377 int mpcc_id = pipe_ctx->plane_res.hubp->inst; 378 struct mpc mpc = pipe_ctx->stream_res.opp->ctx->dc->res_pool->mpc; 379 const struct pwl_params params = NULL; 380 bool ret = false; 381 382 / program OGAM or 3DLUT only for the top pipe/ 383 if (pipe_ctx->top_pipe == NULL) { 384 /program rmu shaper and 3dlut in MPC/ 385 ret = dcn30_set_mpc_shaper_3dlut(pipe_ctx, stream); 386 if (ret == false && mpc->funcs->set_output_gamma) { ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ If this is NULL 387 if (stream->out_transfer_func.type == TF_TYPE_HWPWL) 388 params = &stream->out_transfer_func.pwl; 389 else if (pipe_ctx->stream->out_transfer_func.type == 390 TF_TYPE_DISTRIBUTED_POINTS && 391 cm3_helper_translate_curve_to_hw_format( 392 &stream->out_transfer_func, 393 &mpc->blender_params, false)) 394 params = &mpc->blender_params; 395 / there are no ROM LUTs in OUTGAM */ 396 if (stream->out_transfer_func.type == TF_TYPE_PREDEFINED) 397 BREAK_TO_DEBUGGER(); 398 } 399 } 400 --> 401 mpc->funcs->set_output_gamma(mpc, mpcc_id, params); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Then it will crash 402 return ret; 403 }(CVE-2024-47720)
In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix spin_unlock_irqrestore() called with IRQs enabled Fix missuse of spin_lock_irq()/spin_unlock_irq() when spin_lock_irqsave()/spin_lock_irqrestore() was hold. This was discovered through the lock debugging, and the corresponding log is as follows: raw_local_irq_restore() called with IRQs enabled WARNING: CPU: 96 PID: 2074 at kernel/locking/irqflag-debug.c:10 warn_bogus_irq_restore+0x30/0x40 ... Call trace: warn_bogus_irq_restore+0x30/0x40 _raw_spin_unlock_irqrestore+0x84/0xc8 add_qp_to_list+0x11c/0x148 [hns_roce_hw_v2] hns_roce_create_qp_common.constprop.0+0x240/0x780 [hns_roce_hw_v2] hns_roce_create_qp+0x98/0x160 [hns_roce_hw_v2] create_qp+0x138/0x258 ib_create_qp_kernel+0x50/0xe8 create_mad_qp+0xa8/0x128 ib_mad_port_open+0x218/0x448 ib_mad_init_device+0x70/0x1f8 add_client_context+0xfc/0x220 enable_device_and_get+0xd0/0x140 ib_register_device.part.0+0xf4/0x1c8 ib_register_device+0x34/0x50 hns_roce_register_device+0x174/0x3d0 [hns_roce_hw_v2] hns_roce_init+0xfc/0x2c0 [hns_roce_hw_v2] __hns_roce_hw_v2_init_instance+0x7c/0x1d0 [hns_roce_hw_v2] hns_roce_hw_v2_init_instance+0x9c/0x180 hns_roce_hw_v2
In the Linux kernel, the following vulnerability has been resolved: nfsd: call cache_put if xdr_reserve_space returns NULL If not enough buffer space available, but idmap_lookup has triggered lookup_fn which calls cache_get and returns successfully. Then we missed to call cache_put here which pairs with cache_get. Reviwed-by: Jeff Layton <jlayton@kernel.org>(CVE-2024-47737)
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential oob read in nilfs_btree_check_delete() The function nilfs_btree_check_delete(), which checks whether degeneration to direct mapping occurs before deleting a b-tree entry, causes memory access outside the block buffer when retrieving the maximum key if the root node has no entries. This does not usually happen because b-tree mappings with 0 child nodes are never created by mkfs.nilfs2 or nilfs2 itself. However, it can happen if the b-tree root node read from a device is configured that way, so fix this potential issue by adding a check for that case.(CVE-2024-47757)
In the Linux kernel, the following vulnerability has been resolved: tracing/timerlat: Fix a race during cpuhp processing There is another found exception that the "timerlat/1" thread was scheduled on CPU0, and lead to timer corruption finally: ODEBUG: init active (active state 0) object: ffff888237c2e108 object type: hrtimer hint: timerlat_irq+0x0/0x220 WARNING: CPU: 0 PID: 426 at lib/debugobjects.c:518 debug_print_object+0x7d/0xb0 Modules linked in: CPU: 0 UID: 0 PID: 426 Comm: timerlat/1 Not tainted 6.11.0-rc7+ #45 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:debug_print_object+0x7d/0xb0 ... Call Trace: <TASK> ? __warn+0x7c/0x110 ? debug_print_object+0x7d/0xb0 ? report_bug+0xf1/0x1d0 ? prb_read_valid+0x17/0x20 ? handle_bug+0x3f/0x70 ? exc_invalid_op+0x13/0x60 ? asm_exc_invalid_op+0x16/0x20 ? debug_print_object+0x7d/0xb0 ? debug_print_object+0x7d/0xb0 ? __pfx_timerlat_irq+0x10/0x10 __debug_object_init+0x110/0x150 hrtimer_init+0x1d/0x60 timerlat_main+0xab/0x2d0 ? __pfx_timerlat_main+0x10/0x10 kthread+0xb7/0xe0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> After tracing the scheduling event, it was discovered that the migration of the "timerlat/1" thread was performed during thread creation. Further analysis confirmed that it is because the CPU online processing for osnoise is implemented through workers, which is asynchronous with the offline processing. When the worker was scheduled to create a thread, the CPU may has already been removed from the cpu_online_mask during the offline process, resulting in the inability to select the right CPU: T1 | T2 [CPUHP_ONLINE] | cpu_device_down() osnoise_hotplug_workfn() | | cpus_write_lock() | takedown_cpu(1) | cpus_write_unlock() [CPUHP_OFFLINE] | cpus_read_lock() | start_kthread(1) | cpus_read_unlock() | To fix this, skip online processing if the CPU is already offline.(CVE-2024-49866)
In the Linux kernel, the following vulnerability has been resolved: btrfs: wait for fixup workers before stopping cleaner kthread during umount During unmount, at close_ctree(), we have the following steps in this order: 1) Park the cleaner kthread - this doesn't destroy the kthread, it basically halts its execution (wake ups against it work but do nothing); 2) We stop the cleaner kthread - this results in freeing the respective struct task_struct; 3) We call btrfs_stop_all_workers() which waits for any jobs running in all the work queues and then free the work queues. Syzbot reported a case where a fixup worker resulted in a crash when doing a delayed iput on its inode while attempting to wake up the cleaner at btrfs_add_delayed_iput(), because the task_struct of the cleaner kthread was already freed. This can happen during unmount because we don't wait for any fixup workers still running before we call kthread_stop() against the cleaner kthread, which stops and free all its resources. Fix this by waiting for any fixup workers at close_ctree() before we call kthread_stop() against the cleaner and run pending delayed iputs. The stack traces reported by syzbot were the following: BUG: KASAN: slab-use-after-free in __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065 Read of size 8 at addr ffff8880272a8a18 by task kworker/u8:3/52 CPU: 1 UID: 0 PID: 52 Comm: kworker/u8:3 Not tainted 6.12.0-rc1-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Workqueue: btrfs-fixup btrfs_work_helper Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0xd5/0x120 kernel/locking/spinlock.c:162 class_raw_spinlock_irqsave_constructor include/linux/spinlock.h:551 [inline] try_to_wake_up+0xb0/0x1480 kernel/sched/core.c:4154 btrfs_writepage_fixup_worker+0xc16/0xdf0 fs/btrfs/inode.c:2842 btrfs_work_helper+0x390/0xc50 fs/btrfs/async-thread.c:314 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa63/0x1850 kernel/workqueue.c:3310 worker_thread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 </TASK> Allocated by task 2: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:319 [inline] __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:345 kasan_slab_alloc include/linux/kasan.h:247 [inline] slab_post_alloc_hook mm/slub.c:4086 [inline] slab_alloc_node mm/slub.c:4135 [inline] kmem_cache_alloc_node_noprof+0x16b/0x320 mm/slub.c:4187 alloc_task_struct_node kernel/fork.c:180 [inline] dup_task_struct+0x57/0x8c0 kernel/fork.c:1107 copy_process+0x5d1/0x3d50 kernel/fork.c:2206 kernel_clone+0x223/0x880 kernel/fork.c:2787 kernel_thread+0x1bc/0x240 kernel/fork.c:2849 create_kthread kernel/kthread.c:412 [inline] kthreadd+0x60d/0x810 kernel/kthread.c:765 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Freed by task 61: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:230 [inline] slab_free_h ---truncated---(CVE-2024-49867)
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix a NULL pointer dereference when failed to start a new trasacntion [BUG] Syzbot reported a NULL pointer dereference with the following crash: FAULT_INJECTION: forcing a failure. start_transaction+0x830/0x1670 fs/btrfs/transaction.c:676 prepare_to_relocate+0x31f/0x4c0 fs/btrfs/relocation.c:3642 relocate_block_group+0x169/0xd20 fs/btrfs/relocation.c:3678 ... BTRFS info (device loop0): balance: ended with status: -12 Oops: general protection fault, probably for non-canonical address 0xdffffc00000000cc: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000660-0x0000000000000667] RIP: 0010:btrfs_update_reloc_root+0x362/0xa80 fs/btrfs/relocation.c:926 Call Trace: <TASK> commit_fs_roots+0x2ee/0x720 fs/btrfs/transaction.c:1496 btrfs_commit_transaction+0xfaf/0x3740 fs/btrfs/transaction.c:2430 del_balance_item fs/btrfs/volumes.c:3678 [inline] reset_balance_state+0x25e/0x3c0 fs/btrfs/volumes.c:3742 btrfs_balance+0xead/0x10c0 fs/btrfs/volumes.c:4574 btrfs_ioctl_balance+0x493/0x7c0 fs/btrfs/ioctl.c:3673 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f [CAUSE] The allocation failure happens at the start_transaction() inside prepare_to_relocate(), and during the error handling we call unset_reloc_control(), which makes fs_info->balance_ctl to be NULL. Then we continue the error path cleanup in btrfs_balance() by calling reset_balance_state() which will call del_balance_item() to fully delete the balance item in the root tree. However during the small window between set_reloc_contrl() and unset_reloc_control(), we can have a subvolume tree update and created a reloc_root for that subvolume. Then we go into the final btrfs_commit_transaction() of del_balance_item(), and into btrfs_update_reloc_root() inside commit_fs_roots(). That function checks if fs_info->reloc_ctl is in the merge_reloc_tree stage, but since fs_info->reloc_ctl is NULL, it results a NULL pointer dereference. [FIX] Just add extra check on fs_info->reloc_ctl inside btrfs_update_reloc_root(), before checking fs_info->reloc_ctl->merge_reloc_tree. That DEAD_RELOC_TREE handling is to prevent further modification to the reloc tree during merge stage, but since there is no reloc_ctl at all, we do not need to bother that.(CVE-2024-49868)
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Initialize get_bytes_per_element's default to 1 Variables, used as denominators and maybe not assigned to other values, should not be 0. bytes_per_element_y & bytes_per_element_c are initialized by get_bytes_per_element() which should never return 0. This fixes 10 DIVIDE_BY_ZERO issues reported by Coverity.(CVE-2024-49892)
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in degamma hardware format translation Fixes index out of bounds issue in cm_helper_translate_curve_to_degamma_hw_format function. The issue could occur when the index 'i' exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure 'i' is within bounds before accessing the transfer function points. If 'i' is out of bounds the function returns false to indicate an error. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:594 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:595 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:596 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max(CVE-2024-49894)
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in DCN30 degamma hardware format translation This commit addresses a potential index out of bounds issue in the cm3_helper_translate_curve_to_degamma_hw_format function in the DCN30 color management module. The issue could occur when the index 'i' exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure 'i' is within bounds before accessing the transfer function points. If 'i' is out of bounds, the function returns false to indicate an error. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:338 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:339 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:340 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max(CVE-2024-49895)
In the Linux kernel, the following vulnerability has been resolved: jfs: Fix uninit-value access of new_ea in ea_buffer syzbot reports that lzo1x_1_do_compress is using uninit-value: ===================================================== BUG: KMSAN: uninit-value in lzo1x_1_do_compress+0x19f9/0x2510 lib/lzo/lzo1x_compress.c:178 ... Uninit was stored to memory at: ea_put fs/jfs/xattr.c:639 [inline] ... Local variable ea_buf created at: __jfs_setxattr+0x5d/0x1ae0 fs/jfs/xattr.c:662 __jfs_xattr_set+0xe6/0x1f0 fs/jfs/xattr.c:934 ===================================================== The reason is ea_buf->new_ea is not initialized properly. Fix this by using memset to empty its content at the beginning in ea_get().(CVE-2024-49900)
In the Linux kernel, the following vulnerability has been resolved: jfs: check if leafidx greater than num leaves per dmap tree syzbot report a out of bounds in dbSplit, it because dmt_leafidx greater than num leaves per dmap tree, add a checking for dmt_leafidx in dbFindLeaf. Shaggy: Modified sanity check to apply to control pages as well as leaf pages.(CVE-2024-49902)
In the Linux kernel, the following vulnerability has been resolved: jfs: Fix uaf in dbFreeBits [syzbot reported] ================================================================== BUG: KASAN: slab-use-after-free in __mutex_lock_common kernel/locking/mutex.c:587 [inline] BUG: KASAN: slab-use-after-free in __mutex_lock+0xfe/0xd70 kernel/locking/mutex.c:752 Read of size 8 at addr ffff8880229254b0 by task syz-executor357/5216 CPU: 0 UID: 0 PID: 5216 Comm: syz-executor357 Not tainted 6.11.0-rc3-syzkaller-00156-gd7a5aa4b3c00 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 __mutex_lock_common kernel/locking/mutex.c:587 [inline] __mutex_lock+0xfe/0xd70 kernel/locking/mutex.c:752 dbFreeBits+0x7ea/0xd90 fs/jfs/jfs_dmap.c:2390 dbFreeDmap fs/jfs/jfs_dmap.c:2089 [inline] dbFree+0x35b/0x680 fs/jfs/jfs_dmap.c:409 dbDiscardAG+0x8a9/0xa20 fs/jfs/jfs_dmap.c:1650 jfs_ioc_trim+0x433/0x670 fs/jfs/jfs_discard.c:100 jfs_ioctl+0x2d0/0x3e0 fs/jfs/ioctl.c:131 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 Freed by task 5218: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579 poison_slab_object+0xe0/0x150 mm/kasan/common.c:240 __kasan_slab_free+0x37/0x60 mm/kasan/common.c:256 kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2252 [inline] slab_free mm/slub.c:4473 [inline] kfree+0x149/0x360 mm/slub.c:4594 dbUnmount+0x11d/0x190 fs/jfs/jfs_dmap.c:278 jfs_mount_rw+0x4ac/0x6a0 fs/jfs/jfs_mount.c:247 jfs_remount+0x3d1/0x6b0 fs/jfs/super.c:454 reconfigure_super+0x445/0x880 fs/super.c:1083 vfs_cmd_reconfigure fs/fsopen.c:263 [inline] vfs_fsconfig_locked fs/fsopen.c:292 [inline] __do_sys_fsconfig fs/fsopen.c:473 [inline] __se_sys_fsconfig+0xb6e/0xf80 fs/fsopen.c:345 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f [Analysis] There are two paths (dbUnmount and jfs_ioc_trim) that generate race condition when accessing bmap, which leads to the occurrence of uaf. Use the lock s_umount to synchronize them, in order to avoid uaf caused by race condition.(CVE-2024-49903)
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for function pointer in dcn20_set_output_transfer_func This commit adds a null check for the set_output_gamma function pointer in the dcn20_set_output_transfer_func function. Previously, set_output_gamma was being checked for null at line 1030, but then it was being dereferenced without any null check at line 1048. This could potentially lead to a null pointer dereference error if set_output_gamma is null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a null check for set_output_gamma before the call to set_output_gamma at line 1048.(CVE-2024-49911)
In the Linux kernel, the following vulnerability has been resolved: x86/ioapic: Handle allocation failures gracefully Breno observed panics when using failslab under certain conditions during runtime: can not alloc irq_pin_list (-1,0,20) Kernel panic - not syncing: IO-APIC: failed to add irq-pin. Can not proceed panic+0x4e9/0x590 mp_irqdomain_alloc+0x9ab/0xa80 irq_domain_alloc_irqs_locked+0x25d/0x8d0 __irq_domain_alloc_irqs+0x80/0x110 mp_map_pin_to_irq+0x645/0x890 acpi_register_gsi_ioapic+0xe6/0x150 hpet_open+0x313/0x480 That's a pointless panic which is a leftover of the historic IO/APIC code which panic'ed during early boot when the interrupt allocation failed. The only place which might justify panic is the PIT/HPET timer_check() code which tries to figure out whether the timer interrupt is delivered through the IO/APIC. But that code does not require to handle interrupt allocation failures. If the interrupt cannot be allocated then timer delivery fails and it either panics due to that or falls back to legacy mode. Cure this by removing the panic wrapper around __add_pin_to_irq_node() and making mp_irqdomain_alloc() aware of the failure condition and handle it as any other failure in this function gracefully.(CVE-2024-49927)
In the Linux kernel, the following vulnerability has been resolved: jbd2: stop waiting for space when jbd2_cleanup_journal_tail() returns error In __jbd2_log_wait_for_space(), we might call jbd2_cleanup_journal_tail() to recover some journal space. But if an error occurs while executing jbd2_cleanup_journal_tail() (e.g., an EIO), we don't stop waiting for free space right away, we try other branches, and if j_committing_transaction is NULL (i.e., the tid is 0), we will get the following complain: ============================================ JBD2: I/O error when updating journal superblock for sdd-8. __jbd2_log_wait_for_space: needed 256 blocks and only had 217 space available __jbd2_log_wait_for_space: no way to get more journal space in sdd-8 ------------[ cut here ]------------ WARNING: CPU: 2 PID: 139804 at fs/jbd2/checkpoint.c:109 __jbd2_log_wait_for_space+0x251/0x2e0 Modules linked in: CPU: 2 PID: 139804 Comm: kworker/u8:3 Not tainted 6.6.0+ #1 RIP: 0010:__jbd2_log_wait_for_space+0x251/0x2e0 Call Trace: <TASK> add_transaction_credits+0x5d1/0x5e0 start_this_handle+0x1ef/0x6a0 jbd2__journal_start+0x18b/0x340 ext4_dirty_inode+0x5d/0xb0 __mark_inode_dirty+0xe4/0x5d0 generic_update_time+0x60/0x70 [...] ============================================ So only if jbd2_cleanup_journal_tail() returns 1, i.e., there is nothing to clean up at the moment, continue to try to reclaim free space in other ways. Note that this fix relies on commit 6f6a6fda2945 ("jbd2: fix ocfs2 corrupt when updating journal superblock fails") to make jbd2_cleanup_journal_tail return the correct error code.(CVE-2024-49959)
In the Linux kernel, the following vulnerability has been resolved: ocfs2: remove unreasonable unlock in ocfs2_read_blocks Patch series "Misc fixes for ocfs2_read_blocks", v5. This series contains 2 fixes for ocfs2_read_blocks(). The first patch fix the issue reported by syzbot, which detects bad unlock balance in ocfs2_read_blocks(). The second patch fixes an issue reported by Heming Zhao when reviewing above fix. This patch (of 2): There was a lock release before exiting, so remove the unreasonable unlock.(CVE-2024-49965)
In the Linux kernel, the following vulnerability has been resolved: ocfs2: cancel dqi_sync_work before freeing oinfo ocfs2_global_read_info() will initialize and schedule dqi_sync_work at the end, if error occurs after successfully reading global quota, it will trigger the following warning with CONFIG_DEBUG_OBJECTS_* enabled: ODEBUG: free active (active state 0) object: 00000000d8b0ce28 object type: timer_list hint: qsync_work_fn+0x0/0x16c This reports that there is an active delayed work when freeing oinfo in error handling, so cancel dqi_sync_work first. BTW, return status instead of -1 when .read_file_info fails.(CVE-2024-49966)
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in DCN30 color transformation This commit addresses a potential index out of bounds issue in the cm3_helper_translate_curve_to_hw_format function in the DCN30 color management module. The issue could occur when the index 'i' exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure 'i' is within bounds before accessing the transfer function points. If 'i' is out of bounds, the function returns false to indicate an error. drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:180 cm3_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:181 cm3_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:182 cm3_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max(CVE-2024-49969)
In the Linux kernel, the following vulnerability has been resolved: NFSD: Limit the number of concurrent async COPY operations Nothing appears to limit the number of concurrent async COPY operations that clients can start. In addition, AFAICT each async COPY can copy an unlimited number of 4MB chunks, so can run for a long time. Thus IMO async COPY can become a DoS vector. Add a restriction mechanism that bounds the number of concurrent background COPY operations. Start simple and try to be fair -- this patch implements a per-namespace limit. An async COPY request that occurs while this limit is exceeded gets NFS4ERR_DELAY. The requesting client can choose to send the request again after a delay or fall back to a traditional read/write style copy. If there is need to make the mechanism more sophisticated, we can visit that in future patches.(CVE-2024-49974)
In the Linux kernel, the following vulnerability has been resolved: i2c: stm32f7: Do not prepare/unprepare clock during runtime suspend/resume In case there is any sort of clock controller attached to this I2C bus controller, for example Versaclock or even an AIC32x4 I2C codec, then an I2C transfer triggered from the clock controller clk_ops .prepare callback may trigger a deadlock on drivers/clk/clk.c prepare_lock mutex. This is because the clock controller first grabs the prepare_lock mutex and then performs the prepare operation, including its I2C access. The I2C access resumes this I2C bus controller via .runtime_resume callback, which calls clk_prepare_enable(), which attempts to grab the prepare_lock mutex again and deadlocks. Since the clock are already prepared since probe() and unprepared in remove(), use simple clk_enable()/clk_disable() calls to enable and disable the clock on runtime suspend and resume, to avoid hitting the prepare_lock mutex.(CVE-2024-49985)
In the Linux kernel, the following vulnerability has been resolved: scsi: fnic: Move flush_work initialization out of if block After commit 379a58caa199 ("scsi: fnic: Move fnic_fnic_flush_tx() to a work queue"), it can happen that a work item is sent to an uninitialized work queue. This may has the effect that the item being queued is never actually queued, and any further actions depending on it will not proceed. The following warning is observed while the fnic driver is loaded: kernel: WARNING: CPU: 11 PID: 0 at ../kernel/workqueue.c:1524 __queue_work+0x373/0x410 kernel: <IRQ> kernel: queue_work_on+0x3a/0x50 kernel: fnic_wq_copy_cmpl_handler+0x54a/0x730 [fnic 62fbff0c42e7fb825c60a55cde2fb91facb2ed24] kernel: fnic_isr_msix_wq_copy+0x2d/0x60 [fnic 62fbff0c42e7fb825c60a55cde2fb91facb2ed24] kernel: __handle_irq_event_percpu+0x36/0x1a0 kernel: handle_irq_event_percpu+0x30/0x70 kernel: handle_irq_event+0x34/0x60 kernel: handle_edge_irq+0x7e/0x1a0 kernel: __common_interrupt+0x3b/0xb0 kernel: common_interrupt+0x58/0xa0 kernel: </IRQ> It has been observed that this may break the rediscovery of Fibre Channel devices after a temporary fabric failure. This patch fixes it by moving the work queue initialization out of an if block in fnic_probe().(CVE-2024-50025)
In the Linux kernel, the following vulnerability has been resolved: net: do not delay dst_entries_add() in dst_release() dst_entries_add() uses per-cpu data that might be freed at netns dismantle from ip6_route_net_exit() calling dst_entries_destroy() Before ip6_route_net_exit() can be called, we release all the dsts associated with this netns, via calls to dst_release(), which waits an rcu grace period before calling dst_destroy() dst_entries_add() use in dst_destroy() is racy, because dst_entries_destroy() could have been called already. Decrementing the number of dsts must happen sooner. Notes: 1) in CONFIG_XFRM case, dst_destroy() can call dst_release_immediate(child), this might also cause UAF if the child does not have DST_NOCOUNT set. IPSEC maintainers might take a look and see how to address this. 2) There is also discussion about removing this count of dst, which might happen in future kernels.(CVE-2024-50036)
In the Linux kernel, the following vulnerability has been resolved: NFSv4: Prevent NULL-pointer dereference in nfs42_complete_copies() On the node of an NFS client, some files saved in the mountpoint of the NFS server were copied to another location of the same NFS server. Accidentally, the nfs42_complete_copies() got a NULL-pointer dereference crash with the following syslog: [232064.838881] NFSv4: state recovery failed for open file nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116 [232064.839360] NFSv4: state recovery failed for open file nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116 [232066.588183] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000058 [232066.588586] Mem abort info: [232066.588701] ESR = 0x0000000096000007 [232066.588862] EC = 0x25: DABT (current EL), IL = 32 bits [232066.589084] SET = 0, FnV = 0 [232066.589216] EA = 0, S1PTW = 0 [232066.589340] FSC = 0x07: level 3 translation fault [232066.589559] Data abort info: [232066.589683] ISV = 0, ISS = 0x00000007 [232066.589842] CM = 0, WnR = 0 [232066.589967] user pgtable: 64k pages, 48-bit VAs, pgdp=00002000956ff400 [232066.590231] [0000000000000058] pgd=08001100ae100003, p4d=08001100ae100003, pud=08001100ae100003, pmd=08001100b3c00003, pte=0000000000000000 [232066.590757] Internal error: Oops: 96000007 [#1] SMP [232066.590958] Modules linked in: rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm vhost_net vhost vhost_iotlb tap tun ipt_rpfilter xt_multiport ip_set_hash_ip ip_set_hash_net xfrm_interface xfrm6_tunnel tunnel4 tunnel6 esp4 ah4 wireguard libcurve25519_generic veth xt_addrtype xt_set nf_conntrack_netlink ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_bitmap_port ip_set_hash_ipport dummy ip_set ip_vs_sh ip_vs_wrr ip_vs_rr ip_vs iptable_filter sch_ingress nfnetlink_cttimeout vport_gre ip_gre ip_tunnel gre vport_geneve geneve vport_vxlan vxlan ip6_udp_tunnel udp_tunnel openvswitch nf_conncount dm_round_robin dm_service_time dm_multipath xt_nat xt_MASQUERADE nft_chain_nat nf_nat xt_mark xt_conntrack xt_comment nft_compat nft_counter nf_tables nfnetlink ocfs2 ocfs2_nodemanager ocfs2_stackglue iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ipmi_ssif nbd overlay 8021q garp mrp bonding tls rfkill sunrpc ext4 mbcache jbd2 [232066.591052] vfat fat cas_cache cas_disk ses enclosure scsi_transport_sas sg acpi_ipmi ipmi_si ipmi_devintf ipmi_msghandler ip_tables vfio_pci vfio_pci_core vfio_virqfd vfio_iommu_type1 vfio dm_mirror dm_region_hash dm_log dm_mod nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter bridge stp llc fuse xfs libcrc32c ast drm_vram_helper qla2xxx drm_kms_helper syscopyarea crct10dif_ce sysfillrect ghash_ce sysimgblt sha2_ce fb_sys_fops cec sha256_arm64 sha1_ce drm_ttm_helper ttm nvme_fc igb sbsa_gwdt nvme_fabrics drm nvme_core i2c_algo_bit i40e scsi_transport_fc megaraid_sas aes_neon_bs [232066.596953] CPU: 6 PID: 4124696 Comm: 10.253.166.125- Kdump: loaded Not tainted 5.15.131-9.cl9_ocfs2.aarch64 #1 [232066.597356] Hardware name: Great Wall .\x93\x8e...RF6260 V5/GWMSSE2GL1T, BIOS T656FBE_V3.0.18 2024-01-06 [232066.597721] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [232066.598034] pc : nfs4_reclaim_open_state+0x220/0x800 [nfsv4] [232066.598327] lr : nfs4_reclaim_open_state+0x12c/0x800 [nfsv4] [232066.598595] sp : ffff8000f568fc70 [232066.598731] x29: ffff8000f568fc70 x28: 0000000000001000 x27: ffff21003db33000 [232066.599030] x26: ffff800005521ae0 x25: ffff0100f98fa3f0 x24: 0000000000000001 [232066.599319] x23: ffff800009920008 x22: ffff21003db33040 x21: ffff21003db33050 [232066.599628] x20: ffff410172fe9e40 x19: ffff410172fe9e00 x18: 0000000000000000 [232066.599914] x17: 0000000000000000 x16: 0000000000000004 x15: 0000000000000000 [232066.600195] x14: 0000000000000000 x13: ffff800008e685a8 x12: 00000000eac0c6e6 [232066.600498] x11: 00000000000000 ---truncated---(CVE-2024-50046)
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointer before dereferencing se [WHAT & HOW] se is null checked previously in the same function, indicating it might be null; therefore, it must be checked when used again. This fixes 1 FORWARD_NULL issue reported by Coverity.(CVE-2024-50049)
| URL | Type | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"kernel-5.10.0-234.0.0.136.oe2203sp3.aarch64.rpm",
"kernel-debuginfo-5.10.0-234.0.0.136.oe2203sp3.aarch64.rpm",
"kernel-debugsource-5.10.0-234.0.0.136.oe2203sp3.aarch64.rpm",
"kernel-devel-5.10.0-234.0.0.136.oe2203sp3.aarch64.rpm",
"kernel-headers-5.10.0-234.0.0.136.oe2203sp3.aarch64.rpm",
"kernel-source-5.10.0-234.0.0.136.oe2203sp3.aarch64.rpm",
"kernel-tools-5.10.0-234.0.0.136.oe2203sp3.aarch64.rpm",
"kernel-tools-debuginfo-5.10.0-234.0.0.136.oe2203sp3.aarch64.rpm",
"kernel-tools-devel-5.10.0-234.0.0.136.oe2203sp3.aarch64.rpm",
"perf-5.10.0-234.0.0.136.oe2203sp3.aarch64.rpm",
"perf-debuginfo-5.10.0-234.0.0.136.oe2203sp3.aarch64.rpm",
"python3-perf-5.10.0-234.0.0.136.oe2203sp3.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-234.0.0.136.oe2203sp3.aarch64.rpm"
],
"src": [
"kernel-5.10.0-234.0.0.136.oe2203sp3.src.rpm"
],
"x86_64": [
"kernel-5.10.0-234.0.0.136.oe2203sp3.x86_64.rpm",
"kernel-debuginfo-5.10.0-234.0.0.136.oe2203sp3.x86_64.rpm",
"kernel-debugsource-5.10.0-234.0.0.136.oe2203sp3.x86_64.rpm",
"kernel-devel-5.10.0-234.0.0.136.oe2203sp3.x86_64.rpm",
"kernel-headers-5.10.0-234.0.0.136.oe2203sp3.x86_64.rpm",
"kernel-source-5.10.0-234.0.0.136.oe2203sp3.x86_64.rpm",
"kernel-tools-5.10.0-234.0.0.136.oe2203sp3.x86_64.rpm",
"kernel-tools-debuginfo-5.10.0-234.0.0.136.oe2203sp3.x86_64.rpm",
"kernel-tools-devel-5.10.0-234.0.0.136.oe2203sp3.x86_64.rpm",
"perf-5.10.0-234.0.0.136.oe2203sp3.x86_64.rpm",
"perf-debuginfo-5.10.0-234.0.0.136.oe2203sp3.x86_64.rpm",
"python3-perf-5.10.0-234.0.0.136.oe2203sp3.x86_64.rpm",
"python3-perf-debuginfo-5.10.0-234.0.0.136.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-234.0.0.136.oe2203sp3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "Critical"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\niommu/vt-d: Fix double list_add when enabling VMD in scalable mode\r\n\r\nWhen enabling VMD and IOMMU scalable mode, the following kernel panic\ncall trace/kernel log is shown in Eagle Stream platform (Sapphire Rapids\nCPU) during booting:\r\n\r\npci 0000:59:00.5: Adding to iommu group 42\n...\nvmd 0000:59:00.5: PCI host bridge to bus 10000:80\npci 10000:80:01.0: [8086:352a] type 01 class 0x060400\npci 10000:80:01.0: reg 0x10: [mem 0x00000000-0x0001ffff 64bit]\npci 10000:80:01.0: enabling Extended Tags\npci 10000:80:01.0: PME# supported from D0 D3hot D3cold\npci 10000:80:01.0: DMAR: Setup RID2PASID failed\npci 10000:80:01.0: Failed to add to iommu group 42: -16\npci 10000:80:03.0: [8086:352b] type 01 class 0x060400\npci 10000:80:03.0: reg 0x10: [mem 0x00000000-0x0001ffff 64bit]\npci 10000:80:03.0: enabling Extended Tags\npci 10000:80:03.0: PME# supported from D0 D3hot D3cold\n------------[ cut here ]------------\nkernel BUG at lib/list_debug.c:29!\ninvalid opcode: 0000 [#1] PREEMPT SMP NOPTI\nCPU: 0 PID: 7 Comm: kworker/0:1 Not tainted 5.17.0-rc3+ #7\nHardware name: Lenovo ThinkSystem SR650V3/SB27A86647, BIOS ESE101Y-1.00 01/13/2022\nWorkqueue: events work_for_cpu_fn\nRIP: 0010:__list_add_valid.cold+0x26/0x3f\nCode: 9a 4a ab ff 4c 89 c1 48 c7 c7 40 0c d9 9e e8 b9 b1 fe ff 0f\n 0b 48 89 f2 4c 89 c1 48 89 fe 48 c7 c7 f0 0c d9 9e e8 a2 b1\n fe ff \u0026lt;0f\u0026gt; 0b 48 89 d1 4c 89 c6 4c 89 ca 48 c7 c7 98 0c d9\n 9e e8 8b b1 fe\nRSP: 0000:ff5ad434865b3a40 EFLAGS: 00010246\nRAX: 0000000000000058 RBX: ff4d61160b74b880 RCX: ff4d61255e1fffa8\nRDX: 0000000000000000 RSI: 00000000fffeffff RDI: ffffffff9fd34f20\nRBP: ff4d611d8e245c00 R08: 0000000000000000 R09: ff5ad434865b3888\nR10: ff5ad434865b3880 R11: ff4d61257fdc6fe8 R12: ff4d61160b74b8a0\nR13: ff4d61160b74b8a0 R14: ff4d611d8e245c10 R15: ff4d611d8001ba70\nFS: 0000000000000000(0000) GS:ff4d611d5ea00000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: ff4d611fa1401000 CR3: 0000000aa0210001 CR4: 0000000000771ef0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400\nPKRU: 55555554\nCall Trace:\n \u0026lt;TASK\u0026gt;\n intel_pasid_alloc_table+0x9c/0x1d0\n dmar_insert_one_dev_info+0x423/0x540\n ? device_to_iommu+0x12d/0x2f0\n intel_iommu_attach_device+0x116/0x290\n __iommu_attach_device+0x1a/0x90\n iommu_group_add_device+0x190/0x2c0\n __iommu_probe_device+0x13e/0x250\n iommu_probe_device+0x24/0x150\n iommu_bus_notifier+0x69/0x90\n blocking_notifier_call_chain+0x5a/0x80\n device_add+0x3db/0x7b0\n ? arch_memremap_can_ram_remap+0x19/0x50\n ? memremap+0x75/0x140\n pci_device_add+0x193/0x1d0\n pci_scan_single_device+0xb9/0xf0\n pci_scan_slot+0x4c/0x110\n pci_scan_child_bus_extend+0x3a/0x290\n vmd_enable_domain.constprop.0+0x63e/0x820\n vmd_probe+0x163/0x190\n local_pci_probe+0x42/0x80\n work_for_cpu_fn+0x13/0x20\n process_one_work+0x1e2/0x3b0\n worker_thread+0x1c4/0x3a0\n ? rescuer_thread+0x370/0x370\n kthread+0xc7/0xf0\n ? kthread_complete_and_exit+0x20/0x20\n ret_from_fork+0x1f/0x30\n \u0026lt;/TASK\u0026gt;\nModules linked in:\n---[ end trace 0000000000000000 ]---\n...\nKernel panic - not syncing: Fatal exception\nKernel Offset: 0x1ca00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)\n---[ end Kernel panic - not syncing: Fatal exception ]---\r\n\r\nThe following \u0026apos;lspci\u0026apos; output shows devices \u0026apos;10000:80:*\u0026apos; are subdevices of\nthe VMD device 0000:59:00.5:\r\n\r\n $ lspci\n ...\n 0000:59:00.5 RAID bus controller: Intel Corporation Volume Management Device NVMe RAID Controller (rev 20)\n ...\n 10000:80:01.0 PCI bridge: Intel Corporation Device 352a (rev 03)\n 10000:80:03.0 PCI bridge: Intel Corporation Device 352b (rev 03)\n 10000:80:05.0 PCI bridge: Intel Corporation Device 352c (rev 03)\n 10000:80:07.0 PCI bridge: Intel Corporation Device 352d (rev 03)\n 10000:81:00.0 Non-Volatile memory controller: Intel Corporation NVMe Datacenter SSD [3DNAND, Beta Rock Controller]\n 10000:82:00\n---truncated---(CVE-2022-48916)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: PCI: mt7621: Add sentinel to quirks table Current driver is missing a sentinel in the struct soc_device_attribute array, which causes an oops when assessed by the soc_device_match(mt7621_pcie_quirks_match) call. This was only exposed once the CONFIG_SOC_MT7621 mt7621 soc_dev_attr was fixed to register the SOC as a device, in: commit 7c18b64bba3b (\u0026quot;mips: ralink: mt7621: do not use kzalloc too early\u0026quot;) Fix it by adding the required sentinel.(CVE-2022-48952)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: memcg: fix possible use-after-free in memcg_write_event_control() memcg_write_event_control() accesses the dentry-\u0026gt;d_name of the specified control fd to route the write call. As a cgroup interface file can\u0026apos;t be renamed, it\u0026apos;s safe to access d_name as long as the specified file is a regular cgroup file. Also, as these cgroup interface files can\u0026apos;t be removed before the directory, it\u0026apos;s safe to access the parent too. Prior to 347c4a874710 (\u0026quot;memcg: remove cgroup_event-\u0026gt;cft\u0026quot;), there was a call to __file_cft() which verified that the specified file is a regular cgroupfs file before further accesses. The cftype pointer returned from __file_cft() was no longer necessary and the commit inadvertently dropped the file type check with it allowing any file to slip through. With the invarients broken, the d_name and parent accesses can now race against renames and removals of arbitrary files and cause use-after-free\u0026apos;s. Fix the bug by resurrecting the file type check in __file_cft(). Now that cgroupfs is implemented through kernfs, checking the file operations needs to go through a layer of indirection. Instead, let\u0026apos;s check the superblock and dentry type.(CVE-2022-48988)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: ntb: intel: Fix the NULL vs IS_ERR() bug for debugfs_create_dir() The debugfs_create_dir() function returns error pointers. It never returns NULL. So use IS_ERR() to check it.(CVE-2023-52917)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: media: pci: cx23885: check cx23885_vdev_init() return cx23885_vdev_init() can return a NULL pointer, but that pointer is used in the next line without a check. Add a NULL pointer check and go to the error unwind if it is NULL.(CVE-2023-52918)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: nfc: nci: fix possible NULL pointer dereference in send_acknowledge() Handle memory allocation failure from nci_skb_alloc() (calling alloc_skb()) to avoid possible NULL pointer dereference.(CVE-2023-52919)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nof: module: prevent NULL pointer dereference in vsnprintf()\r\n\r\nIn of_modalias(), we can get passed the str and len parameters which would\ncause a kernel oops in vsnprintf() since it only allows passing a NULL ptr\nwhen the length is also 0. Also, we need to filter out the negative values\nof the len parameter as these will result in a really huge buffer since\nsnprintf() takes size_t parameter while ours is ssize_t...\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with the Svace static\nanalysis tool.(CVE-2024-35878)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndma: xilinx_dpdma: Fix locking\r\n\r\nThere are several places where either chan-\u0026gt;lock or chan-\u0026gt;vchan.lock was\nnot held. Add appropriate locking. This fixes lockdep warnings like\r\n\r\n[ 31.077578] ------------[ cut here ]------------\n[ 31.077831] WARNING: CPU: 2 PID: 40 at drivers/dma/xilinx/xilinx_dpdma.c:834 xilinx_dpdma_chan_queue_transfer+0x274/0x5e0\n[ 31.077953] Modules linked in:\n[ 31.078019] CPU: 2 PID: 40 Comm: kworker/u12:1 Not tainted 6.6.20+ #98\n[ 31.078102] Hardware name: xlnx,zynqmp (DT)\n[ 31.078169] Workqueue: events_unbound deferred_probe_work_func\n[ 31.078272] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[ 31.078377] pc : xilinx_dpdma_chan_queue_transfer+0x274/0x5e0\n[ 31.078473] lr : xilinx_dpdma_chan_queue_transfer+0x270/0x5e0\n[ 31.078550] sp : ffffffc083bb2e10\n[ 31.078590] x29: ffffffc083bb2e10 x28: 0000000000000000 x27: ffffff880165a168\n[ 31.078754] x26: ffffff880164e920 x25: ffffff880164eab8 x24: ffffff880164d480\n[ 31.078920] x23: ffffff880165a148 x22: ffffff880164e988 x21: 0000000000000000\n[ 31.079132] x20: ffffffc082aa3000 x19: ffffff880164e880 x18: 0000000000000000\n[ 31.079295] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000\n[ 31.079453] x14: 0000000000000000 x13: ffffff8802263dc0 x12: 0000000000000001\n[ 31.079613] x11: 0001ffc083bb2e34 x10: 0001ff880164e98f x9 : 0001ffc082aa3def\n[ 31.079824] x8 : 0001ffc082aa3dec x7 : 0000000000000000 x6 : 0000000000000516\n[ 31.079982] x5 : ffffffc7f8d43000 x4 : ffffff88003c9c40 x3 : ffffffffffffffff\n[ 31.080147] x2 : ffffffc7f8d43000 x1 : 00000000000000c0 x0 : 0000000000000000\n[ 31.080307] Call trace:\n[ 31.080340] xilinx_dpdma_chan_queue_transfer+0x274/0x5e0\n[ 31.080518] xilinx_dpdma_issue_pending+0x11c/0x120\n[ 31.080595] zynqmp_disp_layer_update+0x180/0x3ac\n[ 31.080712] zynqmp_dpsub_plane_atomic_update+0x11c/0x21c\n[ 31.080825] drm_atomic_helper_commit_planes+0x20c/0x684\n[ 31.080951] drm_atomic_helper_commit_tail+0x5c/0xb0\n[ 31.081139] commit_tail+0x234/0x294\n[ 31.081246] drm_atomic_helper_commit+0x1f8/0x210\n[ 31.081363] drm_atomic_commit+0x100/0x140\n[ 31.081477] drm_client_modeset_commit_atomic+0x318/0x384\n[ 31.081634] drm_client_modeset_commit_locked+0x8c/0x24c\n[ 31.081725] drm_client_modeset_commit+0x34/0x5c\n[ 31.081812] __drm_fb_helper_restore_fbdev_mode_unlocked+0x104/0x168\n[ 31.081899] drm_fb_helper_set_par+0x50/0x70\n[ 31.081971] fbcon_init+0x538/0xc48\n[ 31.082047] visual_init+0x16c/0x23c\n[ 31.082207] do_bind_con_driver.isra.0+0x2d0/0x634\n[ 31.082320] do_take_over_console+0x24c/0x33c\n[ 31.082429] do_fbcon_takeover+0xbc/0x1b0\n[ 31.082503] fbcon_fb_registered+0x2d0/0x34c\n[ 31.082663] register_framebuffer+0x27c/0x38c\n[ 31.082767] __drm_fb_helper_initial_config_and_unlock+0x5c0/0x91c\n[ 31.082939] drm_fb_helper_initial_config+0x50/0x74\n[ 31.083012] drm_fbdev_dma_client_hotplug+0xb8/0x108\n[ 31.083115] drm_client_register+0xa0/0xf4\n[ 31.083195] drm_fbdev_dma_setup+0xb0/0x1cc\n[ 31.083293] zynqmp_dpsub_drm_init+0x45c/0x4e0\n[ 31.083431] zynqmp_dpsub_probe+0x444/0x5e0\n[ 31.083616] platform_probe+0x8c/0x13c\n[ 31.083713] really_probe+0x258/0x59c\n[ 31.083793] __driver_probe_device+0xc4/0x224\n[ 31.083878] driver_probe_device+0x70/0x1c0\n[ 31.083961] __device_attach_driver+0x108/0x1e0\n[ 31.084052] bus_for_each_drv+0x9c/0x100\n[ 31.084125] __device_attach+0x100/0x298\n[ 31.084207] device_initial_probe+0x14/0x20\n[ 31.084292] bus_probe_device+0xd8/0xdc\n[ 31.084368] deferred_probe_work_func+0x11c/0x180\n[ 31.084451] process_one_work+0x3ac/0x988\n[ 31.084643] worker_thread+0x398/0x694\n[ 31.084752] kthread+0x1bc/0x1c0\n[ 31.084848] ret_from_fork+0x10/0x20\n[ 31.084932] irq event stamp: 64549\n[ 31.084970] hardirqs last enabled at (64548): [\u0026lt;ffffffc081adf35c\u0026gt;] _raw_spin_unlock_irqrestore+0x80/0x90\n[ 31.085157]\n---truncated---(CVE-2024-35990)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nfnetlink_queue: acquire rcu_read_lock() in instance_destroy_rcu()\r\n\r\nsyzbot reported that nf_reinject() could be called without rcu_read_lock() :\r\n\r\nWARNING: suspicious RCU usage\n6.9.0-rc7-syzkaller-02060-g5c1672705a1a #0 Not tainted\r\n\r\nnet/netfilter/nfnetlink_queue.c:263 suspicious rcu_dereference_check() usage!\r\n\r\nother info that might help us debug this:\r\n\r\nrcu_scheduler_active = 2, debug_locks = 1\n2 locks held by syz-executor.4/13427:\n #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_lock_acquire include/linux/rcupdate.h:329 [inline]\n #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_do_batch kernel/rcu/tree.c:2190 [inline]\n #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_core+0xa86/0x1830 kernel/rcu/tree.c:2471\n #1: ffff88801ca92958 (\u0026amp;inst-\u0026gt;lock){+.-.}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline]\n #1: ffff88801ca92958 (\u0026amp;inst-\u0026gt;lock){+.-.}-{2:2}, at: nfqnl_flush net/netfilter/nfnetlink_queue.c:405 [inline]\n #1: ffff88801ca92958 (\u0026amp;inst-\u0026gt;lock){+.-.}-{2:2}, at: instance_destroy_rcu+0x30/0x220 net/netfilter/nfnetlink_queue.c:172\r\n\r\nstack backtrace:\nCPU: 0 PID: 13427 Comm: syz-executor.4 Not tainted 6.9.0-rc7-syzkaller-02060-g5c1672705a1a #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024\nCall Trace:\n \u0026lt;IRQ\u0026gt;\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114\n lockdep_rcu_suspicious+0x221/0x340 kernel/locking/lockdep.c:6712\n nf_reinject net/netfilter/nfnetlink_queue.c:323 [inline]\n nfqnl_reinject+0x6ec/0x1120 net/netfilter/nfnetlink_queue.c:397\n nfqnl_flush net/netfilter/nfnetlink_queue.c:410 [inline]\n instance_destroy_rcu+0x1ae/0x220 net/netfilter/nfnetlink_queue.c:172\n rcu_do_batch kernel/rcu/tree.c:2196 [inline]\n rcu_core+0xafd/0x1830 kernel/rcu/tree.c:2471\n handle_softirqs+0x2d6/0x990 kernel/softirq.c:554\n __do_softirq kernel/softirq.c:588 [inline]\n invoke_softirq kernel/softirq.c:428 [inline]\n __irq_exit_rcu+0xf4/0x1c0 kernel/softirq.c:637\n irq_exit_rcu+0x9/0x30 kernel/softirq.c:649\n instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1043 [inline]\n sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1043\n \u0026lt;/IRQ\u0026gt;\n \u0026lt;TASK\u0026gt;(CVE-2024-36286)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsoundwire: cadence: fix invalid PDI offset\r\n\r\nFor some reason, we add an offset to the PDI, presumably to skip the\nPDI0 and PDI1 which are reserved for BPT.\r\n\r\nThis code is however completely wrong and leads to an out-of-bounds\naccess. We were just lucky so far since we used only a couple of PDIs\nand remained within the PDI array bounds.\r\n\r\nA Fixes: tag is not provided since there are no known platforms where\nthe out-of-bounds would be accessed, and the initial code had problems\nas well.\r\n\r\nA follow-up patch completely removes this useless offset.(CVE-2024-38635)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nriscv: prevent pt_regs corruption for secondary idle threads\r\n\r\nTop of the kernel thread stack should be reserved for pt_regs. However\nthis is not the case for the idle threads of the secondary boot harts.\nTheir stacks overlap with their pt_regs, so both may get corrupted.\r\n\r\nSimilar issue has been fixed for the primary hart, see c7cdd96eca28\n(\u0026quot;riscv: prevent stack corruption by reserving task_pt_regs(p) early\u0026quot;).\nHowever that fix was not propagated to the secondary harts. The problem\nhas been noticed in some CPU hotplug tests with V enabled. The function\nsmp_callin stored several registers on stack, corrupting top of pt_regs\nstructure including status field. As a result, kernel attempted to save\nor restore inexistent V context.(CVE-2024-38667)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnvmet: fix a possible leak when destroy a ctrl during qp establishment\r\n\r\nIn nvmet_sq_destroy we capture sq-\u0026gt;ctrl early and if it is non-NULL we\nknow that a ctrl was allocated (in the admin connect request handler)\nand we need to release pending AERs, clear ctrl-\u0026gt;sqs and sq-\u0026gt;ctrl\n(for nvme-loop primarily), and drop the final reference on the ctrl.\r\n\r\nHowever, a small window is possible where nvmet_sq_destroy starts (as\na result of the client giving up and disconnecting) concurrently with\nthe nvme admin connect cmd (which may be in an early stage). But *before*\nkill_and_confirm of sq-\u0026gt;ref (i.e. the admin connect managed to get an sq\nlive reference). In this case, sq-\u0026gt;ctrl was allocated however after it was\ncaptured in a local variable in nvmet_sq_destroy.\nThis prevented the final reference drop on the ctrl.\r\n\r\nSolve this by re-capturing the sq-\u0026gt;ctrl after all inflight request has\ncompleted, where for sure sq-\u0026gt;ctrl reference is final, and move forward\nbased on that.\r\n\r\nThis issue was observed in an environment with many hosts connecting\nmultiple ctrls simoutanuosly, creating a delay in allocating a ctrl\nleading up to this race window.(CVE-2024-42152)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndev/parport: fix the array out-of-bounds risk\r\n\r\nFixed array out-of-bounds issues caused by sprintf\nby replacing it with snprintf for safer data copying,\nensuring the destination buffer is not overflowed.\r\n\r\nBelow is the stack trace I encountered during the actual issue:\r\n\r\n[ 66.575408s] [pid:5118,cpu4,QThread,4]Kernel panic - not syncing: stack-protector:\nKernel stack is corrupted in: do_hardware_base_addr+0xcc/0xd0 [parport]\n[ 66.575408s] [pid:5118,cpu4,QThread,5]CPU: 4 PID: 5118 Comm:\nQThread Tainted: G S W O 5.10.97-arm64-desktop #7100.57021.2\n[ 66.575439s] [pid:5118,cpu4,QThread,6]TGID: 5087 Comm: EFileApp\n[ 66.575439s] [pid:5118,cpu4,QThread,7]Hardware name: HUAWEI HUAWEI QingYun\nPGUX-W515x-B081/SP1PANGUXM, BIOS 1.00.07 04/29/2024\n[ 66.575439s] [pid:5118,cpu4,QThread,8]Call trace:\n[ 66.575469s] [pid:5118,cpu4,QThread,9] dump_backtrace+0x0/0x1c0\n[ 66.575469s] [pid:5118,cpu4,QThread,0] show_stack+0x14/0x20\n[ 66.575469s] [pid:5118,cpu4,QThread,1] dump_stack+0xd4/0x10c\n[ 66.575500s] [pid:5118,cpu4,QThread,2] panic+0x1d8/0x3bc\n[ 66.575500s] [pid:5118,cpu4,QThread,3] __stack_chk_fail+0x2c/0x38\n[ 66.575500s] [pid:5118,cpu4,QThread,4] do_hardware_base_addr+0xcc/0xd0 [parport](CVE-2024-42301)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nexfat: fix potential deadlock on __exfat_get_dentry_set\r\n\r\nWhen accessing a file with more entries than ES_MAX_ENTRY_NUM, the bh-array\nis allocated in __exfat_get_entry_set. The problem is that the bh-array is\nallocated with GFP_KERNEL. It does not make sense. In the following cases,\na deadlock for sbi-\u0026gt;s_lock between the two processes may occur.\r\n\r\n CPU0 CPU1\n ---- ----\n kswapd\n balance_pgdat\n lock(fs_reclaim)\n exfat_iterate\n lock(\u0026amp;sbi-\u0026gt;s_lock)\n exfat_readdir\n exfat_get_uniname_from_ext_entry\n exfat_get_dentry_set\n __exfat_get_dentry_set\n kmalloc_array\n ...\n lock(fs_reclaim)\n ...\n evict\n exfat_evict_inode\n lock(\u0026amp;sbi-\u0026gt;s_lock)\r\n\r\nTo fix this, let\u0026apos;s allocate bh-array with GFP_NOFS.(CVE-2024-42315)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: virt_wifi: avoid reporting connection success with wrong SSID\r\n\r\nWhen user issues a connection with a different SSID than the one\nvirt_wifi has advertised, the __cfg80211_connect_result() will\ntrigger the warning: WARN_ON(bss_not_found).\r\n\r\nThe issue is because the connection code in virt_wifi does not\ncheck the SSID from user space (it only checks the BSSID), and\nvirt_wifi will call cfg80211_connect_result() with WLAN_STATUS_SUCCESS\neven if the SSID is different from the one virt_wifi has advertised.\nEventually cfg80211 won\u0026apos;t be able to find the cfg80211_bss and generate\nthe warning.\r\n\r\nFixed it by checking the SSID (from user space) in the connection code.(CVE-2024-43841)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\njfs: Fix array-index-out-of-bounds in diFree(CVE-2024-43858)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/nouveau: prime: fix refcount underflow\r\n\r\nCalling nouveau_bo_ref() on a nouveau_bo without initializing it (and\nhence the backing ttm_bo) leads to a refcount underflow.\r\n\r\nInstead of calling nouveau_bo_ref() in the unwind path of\ndrm_gem_object_init(), clean things up manually.\r\n\r\n(cherry picked from commit 1b93f3e89d03cfc576636e195466a0d728ad8de5)(CVE-2024-43867)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndevres: Fix memory leakage caused by driver API devm_free_percpu()\r\n\r\nIt will cause memory leakage when use driver API devm_free_percpu()\nto free memory allocated by devm_alloc_percpu(), fixed by using\ndevres_release() instead of devres_destroy() within devm_free_percpu().(CVE-2024-43871)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/client: fix null pointer dereference in drm_client_modeset_probe\r\n\r\nIn drm_client_modeset_probe(), the return value of drm_mode_duplicate() is\nassigned to modeset-\u0026gt;mode, which will lead to a possible NULL pointer\ndereference on failure of drm_mode_duplicate(). Add a check to avoid npd.(CVE-2024-43894)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmptcp: pm: only decrement add_addr_accepted for MPJ req\r\n\r\nAdding the following warning ...\r\n\r\n WARN_ON_ONCE(msk-\u0026gt;pm.add_addr_accepted == 0)\r\n\r\n... before decrementing the add_addr_accepted counter helped to find a\nbug when running the \u0026quot;remove single subflow\u0026quot; subtest from the\nmptcp_join.sh selftest.\r\n\r\nRemoving a \u0026apos;subflow\u0026apos; endpoint will first trigger a RM_ADDR, then the\nsubflow closure. Before this patch, and upon the reception of the\nRM_ADDR, the other peer will then try to decrement this\nadd_addr_accepted. That\u0026apos;s not correct because the attached subflows have\nnot been created upon the reception of an ADD_ADDR.\r\n\r\nA way to solve that is to decrement the counter only if the attached\nsubflow was an MP_JOIN to a remote id that was not 0, and initiated by\nthe host receiving the RM_ADDR.(CVE-2024-45009)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: dwc3: core: Prevent USB core invalid event buffer address access\r\n\r\nThis commit addresses an issue where the USB core could access an\ninvalid event buffer address during runtime suspend, potentially causing\nSMMU faults and other memory issues in Exynos platforms. The problem\narises from the following sequence.\n 1. In dwc3_gadget_suspend, there is a chance of a timeout when\n moving the USB core to the halt state after clearing the\n run/stop bit by software.\n 2. In dwc3_core_exit, the event buffer is cleared regardless of\n the USB core\u0026apos;s status, which may lead to an SMMU faults and\n other memory issues. if the USB core tries to access the event\n buffer address.\r\n\r\nTo prevent this hardware quirk on Exynos platforms, this commit ensures\nthat the event buffer address is not cleared by software when the USB\ncore is active during runtime suspend by checking its status before\nclearing the buffer address.(CVE-2024-46675)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsoc: qcom: cmd-db: Map shared memory as WC, not WB\r\n\r\nLinux does not write into cmd-db region. This region of memory is write\nprotected by XPU. XPU may sometime falsely detect clean cache eviction\nas \u0026quot;write\u0026quot; into the write protected region leading to secure interrupt\nwhich causes an endless loop somewhere in Trust Zone.\r\n\r\nThe only reason it is working right now is because Qualcomm Hypervisor\nmaps the same region as Non-Cacheable memory in Stage 2 translation\ntables. The issue manifests if we want to use another hypervisor (like\nXen or KVM), which does not know anything about those specific mappings.\r\n\r\nChanging the mapping of cmd-db memory from MEMREMAP_WB to MEMREMAP_WT/WC\nremoves dependency on correct mappings in Stage 2 tables. This patch\nfixes the issue by updating the mapping to MEMREMAP_WC.\r\n\r\nI tested this on SA8155P with Xen.(CVE-2024-46689)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: fix mc_data out-of-bounds read warning\r\n\r\nClear warning that read mc_data[i-1] may out-of-bounds.(CVE-2024-46722)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: Fix out-of-bounds read of df_v1_7_channel_number\r\n\r\nCheck the fb_channel_number range to avoid the array out-of-bounds\nread error(CVE-2024-46724)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nhwmon: (nct6775-core) Fix underflows seen when writing limit attributes\r\n\r\nDIV_ROUND_CLOSEST() after kstrtol() results in an underflow if a large\nnegative number such as -9223372036854775808 is provided by the user.\nFix it by reordering clamp_val() and DIV_ROUND_CLOSEST() operations.(CVE-2024-46757)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: added NULL check at start of dc_validate_stream\r\n\r\n[Why]\nprevent invalid memory access\r\n\r\n[How]\ncheck if dc and stream are NULL(CVE-2024-46802)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nKVM: x86: Acquire kvm-\u0026gt;srcu when handling KVM_SET_VCPU_EVENTS\r\n\r\nGrab kvm-\u0026gt;srcu when processing KVM_SET_VCPU_EVENTS, as KVM will forcibly\nleave nested VMX/SVM if SMM mode is being toggled, and leaving nested VMX\nreads guest memory.\r\n\r\nNote, kvm_vcpu_ioctl_x86_set_vcpu_events() can also be called from KVM_RUN\nvia sync_regs(), which already holds SRCU. I.e. trying to precisely use\nkvm_vcpu_srcu_read_lock() around the problematic SMM code would cause\nproblems. Acquiring SRCU isn\u0026apos;t all that expensive, so for simplicity,\ngrab it unconditionally for KVM_SET_VCPU_EVENTS.\r\n\r\n =============================\n WARNING: suspicious RCU usage\n 6.10.0-rc7-332d2c1d713e-next-vm #552 Not tainted\n -----------------------------\n include/linux/kvm_host.h:1027 suspicious rcu_dereference_check() usage!\r\n\r\n other info that might help us debug this:\r\n\r\n rcu_scheduler_active = 2, debug_locks = 1\n 1 lock held by repro/1071:\n #0: ffff88811e424430 (\u0026amp;vcpu-\u0026gt;mutex){+.+.}-{3:3}, at: kvm_vcpu_ioctl+0x7d/0x970 [kvm]\r\n\r\n stack backtrace:\n CPU: 15 PID: 1071 Comm: repro Not tainted 6.10.0-rc7-332d2c1d713e-next-vm #552\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015\n Call Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x7f/0x90\n lockdep_rcu_suspicious+0x13f/0x1a0\n kvm_vcpu_gfn_to_memslot+0x168/0x190 [kvm]\n kvm_vcpu_read_guest+0x3e/0x90 [kvm]\n nested_vmx_load_msr+0x6b/0x1d0 [kvm_intel]\n load_vmcs12_host_state+0x432/0xb40 [kvm_intel]\n vmx_leave_nested+0x30/0x40 [kvm_intel]\n kvm_vcpu_ioctl_x86_set_vcpu_events+0x15d/0x2b0 [kvm]\n kvm_arch_vcpu_ioctl+0x1107/0x1750 [kvm]\n ? mark_held_locks+0x49/0x70\n ? kvm_vcpu_ioctl+0x7d/0x970 [kvm]\n ? kvm_vcpu_ioctl+0x497/0x970 [kvm]\n kvm_vcpu_ioctl+0x497/0x970 [kvm]\n ? lock_acquire+0xba/0x2d0\n ? find_held_lock+0x2b/0x80\n ? do_user_addr_fault+0x40c/0x6f0\n ? lock_release+0xb7/0x270\n __x64_sys_ioctl+0x82/0xb0\n do_syscall_64+0x6c/0x170\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n RIP: 0033:0x7ff11eb1b539\n \u0026lt;/TASK\u0026gt;(CVE-2024-46830)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nspi: nxp-fspi: fix the KASAN report out-of-bounds bug\r\n\r\nChange the memcpy length to fix the out-of-bounds issue when writing the\ndata that is not 4 byte aligned to TX FIFO.\r\n\r\nTo reproduce the issue, write 3 bytes data to NOR chip.\r\n\r\ndd if=3b of=/dev/mtd0\n[ 36.926103] ==================================================================\n[ 36.933409] BUG: KASAN: slab-out-of-bounds in nxp_fspi_exec_op+0x26ec/0x2838\n[ 36.940514] Read of size 4 at addr ffff00081037c2a0 by task dd/455\n[ 36.946721]\n[ 36.948235] CPU: 3 UID: 0 PID: 455 Comm: dd Not tainted 6.11.0-rc5-gc7b0e37c8434 #1070\n[ 36.956185] Hardware name: Freescale i.MX8QM MEK (DT)\n[ 36.961260] Call trace:\n[ 36.963723] dump_backtrace+0x90/0xe8\n[ 36.967414] show_stack+0x18/0x24\n[ 36.970749] dump_stack_lvl+0x78/0x90\n[ 36.974451] print_report+0x114/0x5cc\n[ 36.978151] kasan_report+0xa4/0xf0\n[ 36.981670] __asan_report_load_n_noabort+0x1c/0x28\n[ 36.986587] nxp_fspi_exec_op+0x26ec/0x2838\n[ 36.990800] spi_mem_exec_op+0x8ec/0xd30\n[ 36.994762] spi_mem_no_dirmap_read+0x190/0x1e0\n[ 36.999323] spi_mem_dirmap_write+0x238/0x32c\n[ 37.003710] spi_nor_write_data+0x220/0x374\n[ 37.007932] spi_nor_write+0x110/0x2e8\n[ 37.011711] mtd_write_oob_std+0x154/0x1f0\n[ 37.015838] mtd_write_oob+0x104/0x1d0\n[ 37.019617] mtd_write+0xb8/0x12c\n[ 37.022953] mtdchar_write+0x224/0x47c\n[ 37.026732] vfs_write+0x1e4/0x8c8\n[ 37.030163] ksys_write+0xec/0x1d0\n[ 37.033586] __arm64_sys_write+0x6c/0x9c\n[ 37.037539] invoke_syscall+0x6c/0x258\n[ 37.041327] el0_svc_common.constprop.0+0x160/0x22c\n[ 37.046244] do_el0_svc+0x44/0x5c\n[ 37.049589] el0_svc+0x38/0x78\n[ 37.052681] el0t_64_sync_handler+0x13c/0x158\n[ 37.057077] el0t_64_sync+0x190/0x194\n[ 37.060775]\n[ 37.062274] Allocated by task 455:\n[ 37.065701] kasan_save_stack+0x2c/0x54\n[ 37.069570] kasan_save_track+0x20/0x3c\n[ 37.073438] kasan_save_alloc_info+0x40/0x54\n[ 37.077736] __kasan_kmalloc+0xa0/0xb8\n[ 37.081515] __kmalloc_noprof+0x158/0x2f8\n[ 37.085563] mtd_kmalloc_up_to+0x120/0x154\n[ 37.089690] mtdchar_write+0x130/0x47c\n[ 37.093469] vfs_write+0x1e4/0x8c8\n[ 37.096901] ksys_write+0xec/0x1d0\n[ 37.100332] __arm64_sys_write+0x6c/0x9c\n[ 37.104287] invoke_syscall+0x6c/0x258\n[ 37.108064] el0_svc_common.constprop.0+0x160/0x22c\n[ 37.112972] do_el0_svc+0x44/0x5c\n[ 37.116319] el0_svc+0x38/0x78\n[ 37.119401] el0t_64_sync_handler+0x13c/0x158\n[ 37.123788] el0t_64_sync+0x190/0x194\n[ 37.127474]\n[ 37.128977] The buggy address belongs to the object at ffff00081037c2a0\n[ 37.128977] which belongs to the cache kmalloc-8 of size 8\n[ 37.141177] The buggy address is located 0 bytes inside of\n[ 37.141177] allocated 3-byte region [ffff00081037c2a0, ffff00081037c2a3)\n[ 37.153465]\n[ 37.154971] The buggy address belongs to the physical page:\n[ 37.160559] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x89037c\n[ 37.168596] flags: 0xbfffe0000000000(node=0|zone=2|lastcpupid=0x1ffff)\n[ 37.175149] page_type: 0xfdffffff(slab)\n[ 37.179021] raw: 0bfffe0000000000 ffff000800002500 dead000000000122 0000000000000000\n[ 37.186788] raw: 0000000000000000 0000000080800080 00000001fdffffff 0000000000000000\n[ 37.194553] page dumped because: kasan: bad access detected\n[ 37.200144]\n[ 37.201647] Memory state around the buggy address:\n[ 37.206460] ffff00081037c180: fa fc fc fc fa fc fc fc fa fc fc fc fa fc fc fc\n[ 37.213701] ffff00081037c200: fa fc fc fc 05 fc fc fc 03 fc fc fc 02 fc fc fc\n[ 37.220946] \u0026gt;ffff00081037c280: 06 fc fc fc 03 fc fc fc fc fc fc fc fc fc fc fc\n[ 37.228186] ^\n[ 37.232473] ffff00081037c300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc\n[ 37.239718] ffff00081037c380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc\n[ 37.246962] ==============================================================\n---truncated---(CVE-2024-46853)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nPCI: keystone: Add workaround for Errata #i2037 (AM65x SR 1.0)\r\n\r\nErrata #i2037 in AM65x/DRA80xM Processors Silicon Revision 1.0\n(SPRZ452D_July 2018_Revised December 2019 [1]) mentions when an\ninbound PCIe TLP spans more than two internal AXI 128-byte bursts,\nthe bus may corrupt the packet payload and the corrupt data may\ncause associated applications or the processor to hang.\r\n\r\nThe workaround for Errata #i2037 is to limit the maximum read\nrequest size and maximum payload size to 128 bytes. Add workaround\nfor Errata #i2037 here.\r\n\r\nThe errata and workaround is applicable only to AM65x SR 1.0 and\nlater versions of the silicon will have this fixed.\r\n\r\n[1] -\u0026gt; https://www.ti.com/lit/er/sprz452i/sprz452i.pdf(CVE-2024-47667)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: fix state management in error path of log writing function\r\n\r\nAfter commit a694291a6211 (\u0026quot;nilfs2: separate wait function from\nnilfs_segctor_write\u0026quot;) was applied, the log writing function\nnilfs_segctor_do_construct() was able to issue I/O requests continuously\neven if user data blocks were split into multiple logs across segments,\nbut two potential flaws were introduced in its error handling.\r\n\r\nFirst, if nilfs_segctor_begin_construction() fails while creating the\nsecond or subsequent logs, the log writing function returns without\ncalling nilfs_segctor_abort_construction(), so the writeback flag set on\npages/folios will remain uncleared. This causes page cache operations to\nhang waiting for the writeback flag. For example,\ntruncate_inode_pages_final(), which is called via nilfs_evict_inode() when\nan inode is evicted from memory, will hang.\r\n\r\nSecond, the NILFS_I_COLLECTED flag set on normal inodes remain uncleared. \nAs a result, if the next log write involves checkpoint creation, that\u0026apos;s\nfine, but if a partial log write is performed that does not, inodes with\nNILFS_I_COLLECTED set are erroneously removed from the \u0026quot;sc_dirty_files\u0026quot;\nlist, and their data and b-tree blocks may not be written to the device,\ncorrupting the block mapping.\r\n\r\nFix these issues by uniformly calling nilfs_segctor_abort_construction()\non failure of each step in the loop in nilfs_segctor_do_construct(),\nhaving it clean up logs and segment usages according to progress, and\ncorrecting the conditions for calling nilfs_redirty_inodes() to ensure\nthat the NILFS_I_COLLECTED flag is cleared.(CVE-2024-47669)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: tcp: check skb is non-NULL in tcp_rto_delta_us() We have some machines running stock Ubuntu 20.04.6 which is their 5.4.0-174-generic kernel that are running ceph and recently hit a null ptr dereference in tcp_rearm_rto(). Initially hitting it from the TLP path, but then later we also saw it getting hit from the RACK case as well. Here are examples of the oops messages we saw in each of those cases: Jul 26 15:05:02 rx [11061395.780353] BUG: kernel NULL pointer dereference, address: 0000000000000020 Jul 26 15:05:02 rx [11061395.787572] #PF: supervisor read access in kernel mode Jul 26 15:05:02 rx [11061395.792971] #PF: error_code(0x0000) - not-present page Jul 26 15:05:02 rx [11061395.798362] PGD 0 P4D 0 Jul 26 15:05:02 rx [11061395.801164] Oops: 0000 [#1] SMP NOPTI Jul 26 15:05:02 rx [11061395.805091] CPU: 0 PID: 9180 Comm: msgr-worker-1 Tainted: G W 5.4.0-174-generic #193-Ubuntu Jul 26 15:05:02 rx [11061395.814996] Hardware name: Supermicro SMC 2x26 os-gen8 64C NVME-Y 256G/H12SSW-NTR, BIOS 2.5.V1.2U.NVMe.UEFI 05/09/2023 Jul 26 15:05:02 rx [11061395.825952] RIP: 0010:tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.830656] Code: 87 ca 04 00 00 00 5b 41 5c 41 5d 5d c3 c3 49 8b bc 24 40 06 00 00 eb 8d 48 bb cf f7 53 e3 a5 9b c4 20 4c 89 ef e8 0c fe 0e 00 \u0026lt;48\u0026gt; 8b 78 20 48 c1 ef 03 48 89 f8 41 8b bc 24 80 04 00 00 48 f7 e3 Jul 26 15:05:02 rx [11061395.849665] RSP: 0018:ffffb75d40003e08 EFLAGS: 00010246 Jul 26 15:05:02 rx [11061395.855149] RAX: 0000000000000000 RBX: 20c49ba5e353f7cf RCX: 0000000000000000 Jul 26 15:05:02 rx [11061395.862542] RDX: 0000000062177c30 RSI: 000000000000231c RDI: ffff9874ad283a60 Jul 26 15:05:02 rx [11061395.869933] RBP: ffffb75d40003e20 R08: 0000000000000000 R09: ffff987605e20aa8 Jul 26 15:05:02 rx [11061395.877318] R10: ffffb75d40003f00 R11: ffffb75d4460f740 R12: ffff9874ad283900 Jul 26 15:05:02 rx [11061395.884710] R13: ffff9874ad283a60 R14: ffff9874ad283980 R15: ffff9874ad283d30 Jul 26 15:05:02 rx [11061395.892095] FS: 00007f1ef4a2e700(0000) GS:ffff987605e00000(0000) knlGS:0000000000000000 Jul 26 15:05:02 rx [11061395.900438] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Jul 26 15:05:02 rx [11061395.906435] CR2: 0000000000000020 CR3: 0000003e450ba003 CR4: 0000000000760ef0 Jul 26 15:05:02 rx [11061395.913822] PKRU: 55555554 Jul 26 15:05:02 rx [11061395.916786] Call Trace: Jul 26 15:05:02 rx [11061395.919488] Jul 26 15:05:02 rx [11061395.921765] ? show_regs.cold+0x1a/0x1f Jul 26 15:05:02 rx [11061395.925859] ? __die+0x90/0xd9 Jul 26 15:05:02 rx [11061395.929169] ? no_context+0x196/0x380 Jul 26 15:05:02 rx [11061395.933088] ? ip6_protocol_deliver_rcu+0x4e0/0x4e0 Jul 26 15:05:02 rx [11061395.938216] ? ip6_sublist_rcv_finish+0x3d/0x50 Jul 26 15:05:02 rx [11061395.943000] ? __bad_area_nosemaphore+0x50/0x1a0 Jul 26 15:05:02 rx [11061395.947873] ? bad_area_nosemaphore+0x16/0x20 Jul 26 15:05:02 rx [11061395.952486] ? do_user_addr_fault+0x267/0x450 Jul 26 15:05:02 rx [11061395.957104] ? ipv6_list_rcv+0x112/0x140 Jul 26 15:05:02 rx [11061395.961279] ? __do_page_fault+0x58/0x90 Jul 26 15:05:02 rx [11061395.965458] ? do_page_fault+0x2c/0xe0 Jul 26 15:05:02 rx [11061395.969465] ? page_fault+0x34/0x40 Jul 26 15:05:02 rx [11061395.973217] ? tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.977313] ? tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.981408] tcp_send_loss_probe+0x10b/0x220 Jul 26 15:05:02 rx [11061395.985937] tcp_write_timer_handler+0x1b4/0x240 Jul 26 15:05:02 rx [11061395.990809] tcp_write_timer+0x9e/0xe0 Jul 26 15:05:02 rx [11061395.994814] ? tcp_write_timer_handler+0x240/0x240 Jul 26 15:05:02 rx [11061395.999866] call_timer_fn+0x32/0x130 Jul 26 15:05:02 rx [11061396.003782] __run_timers.part.0+0x180/0x280 Jul 26 15:05:02 rx [11061396.008309] ? recalibrate_cpu_khz+0x10/0x10 Jul 26 15:05:02 rx [11061396.012841] ? native_x2apic_icr_write+0x30/0x30 Jul 26 15:05:02 rx [11061396.017718] ? lapic_next_even ---truncated---(CVE-2024-47684)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: netfilter: nf_reject_ipv6: fix nf_reject_ip6_tcphdr_put() syzbot reported that nf_reject_ip6_tcphdr_put() was possibly sending garbage on the four reserved tcp bits (th-\u0026gt;res1) Use skb_put_zero() to clear the whole TCP header, as done in nf_reject_ip_tcphdr_put() BUG: KMSAN: uninit-value in nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255 nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255 nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344 nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core net/core/dev.c:5661 [inline] __netif_receive_skb+0x1da/0xa00 net/core/dev.c:5775 process_backlog+0x4ad/0xa50 net/core/dev.c:6108 __napi_poll+0xe7/0x980 net/core/dev.c:6772 napi_poll net/core/dev.c:6841 [inline] net_rx_action+0xa5a/0x19b0 net/core/dev.c:6963 handle_softirqs+0x1ce/0x800 kernel/softirq.c:554 __do_softirq+0x14/0x1a kernel/softirq.c:588 do_softirq+0x9a/0x100 kernel/softirq.c:455 __local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:382 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:908 [inline] __dev_queue_xmit+0x2692/0x5610 net/core/dev.c:4450 dev_queue_xmit include/linux/netdevice.h:3105 [inline] neigh_resolve_output+0x9ca/0xae0 net/core/neighbour.c:1565 neigh_output include/net/neighbour.h:542 [inline] ip6_finish_output2+0x2347/0x2ba0 net/ipv6/ip6_output.c:141 __ip6_finish_output net/ipv6/ip6_output.c:215 [inline] ip6_finish_output+0xbb8/0x14b0 net/ipv6/ip6_output.c:226 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip6_output+0x356/0x620 net/ipv6/ip6_output.c:247 dst_output include/net/dst.h:450 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] ip6_xmit+0x1ba6/0x25d0 net/ipv6/ip6_output.c:366 inet6_csk_xmit+0x442/0x530 net/ipv6/inet6_connection_sock.c:135 __tcp_transmit_skb+0x3b07/0x4880 net/ipv4/tcp_output.c:1466 tcp_transmit_skb net/ipv4/tcp_output.c:1484 [inline] tcp_connect+0x35b6/0x7130 net/ipv4/tcp_output.c:4143 tcp_v6_connect+0x1bcc/0x1e40 net/ipv6/tcp_ipv6.c:333 __inet_stream_connect+0x2ef/0x1730 net/ipv4/af_inet.c:679 inet_stream_connect+0x6a/0xd0 net/ipv4/af_inet.c:750 __sys_connect_file net/socket.c:2061 [inline] __sys_connect+0x606/0x690 net/socket.c:2078 __do_sys_connect net/socket.c:2088 [inline] __se_sys_connect net/socket.c:2085 [inline] __x64_sys_connect+0x91/0xe0 net/socket.c:2085 x64_sys_call+0x27a5/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:43 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit was stored to memory at: nf_reject_ip6_tcphdr_put+0x60c/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:249 nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344 nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core ---truncated---(CVE-2024-47685)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: nfsd: return -EINVAL when namelen is 0 When we have a corrupted main.sqlite in /var/lib/nfs/nfsdcld/, it may result in namelen being 0, which will cause memdup_user() to return ZERO_SIZE_PTR. When we access the name.data that has been assigned the value of ZERO_SIZE_PTR in nfs4_client_to_reclaim(), null pointer dereference is triggered. [ T1205] ================================================================== [ T1205] BUG: KASAN: null-ptr-deref in nfs4_client_to_reclaim+0xe9/0x260 [ T1205] Read of size 1 at addr 0000000000000010 by task nfsdcld/1205 [ T1205] [ T1205] CPU: 11 PID: 1205 Comm: nfsdcld Not tainted 5.10.0-00003-g2c1423731b8d #406 [ T1205] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014 [ T1205] Call Trace: [ T1205] dump_stack+0x9a/0xd0 [ T1205] ? nfs4_client_to_reclaim+0xe9/0x260 [ T1205] __kasan_report.cold+0x34/0x84 [ T1205] ? nfs4_client_to_reclaim+0xe9/0x260 [ T1205] kasan_report+0x3a/0x50 [ T1205] nfs4_client_to_reclaim+0xe9/0x260 [ T1205] ? nfsd4_release_lockowner+0x410/0x410 [ T1205] cld_pipe_downcall+0x5ca/0x760 [ T1205] ? nfsd4_cld_tracking_exit+0x1d0/0x1d0 [ T1205] ? down_write_killable_nested+0x170/0x170 [ T1205] ? avc_policy_seqno+0x28/0x40 [ T1205] ? selinux_file_permission+0x1b4/0x1e0 [ T1205] rpc_pipe_write+0x84/0xb0 [ T1205] vfs_write+0x143/0x520 [ T1205] ksys_write+0xc9/0x170 [ T1205] ? __ia32_sys_read+0x50/0x50 [ T1205] ? ktime_get_coarse_real_ts64+0xfe/0x110 [ T1205] ? ktime_get_coarse_real_ts64+0xa2/0x110 [ T1205] do_syscall_64+0x33/0x40 [ T1205] entry_SYSCALL_64_after_hwframe+0x67/0xd1 [ T1205] RIP: 0033:0x7fdbdb761bc7 [ T1205] Code: 0f 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 \u0026lt;48\u0026gt; 3d 00 f0 ff ff 77 514 [ T1205] RSP: 002b:00007fff8c4b7248 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ T1205] RAX: ffffffffffffffda RBX: 000000000000042b RCX: 00007fdbdb761bc7 [ T1205] RDX: 000000000000042b RSI: 00007fff8c4b75f0 RDI: 0000000000000008 [ T1205] RBP: 00007fdbdb761bb0 R08: 0000000000000000 R09: 0000000000000001 [ T1205] R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000042b [ T1205] R13: 0000000000000008 R14: 00007fff8c4b75f0 R15: 0000000000000000 [ T1205] ================================================================== Fix it by checking namelen.(CVE-2024-47692)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: RDMA/rtrs-clt: Reset cid to con_num - 1 to stay in bounds In the function init_conns(), after the create_con() and create_cm() for loop if something fails. In the cleanup for loop after the destroy tag, we access out of bound memory because cid is set to clt_path-\u0026gt;s.con_num. This commits resets the cid to clt_path-\u0026gt;s.con_num - 1, to stay in bounds in the cleanup loop later.(CVE-2024-47695)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: drivers: media: dvb-frontends/rtl2832: fix an out-of-bounds write error Ensure index in rtl2832_pid_filter does not exceed 31 to prevent out-of-bounds access. dev-\u0026gt;filters is a 32-bit value, so set_bit and clear_bit functions should only operate on indices from 0 to 31. If index is 32, it will attempt to access a non-existent 33rd bit, leading to out-of-bounds access. Change the boundary check from index \u0026gt; 32 to index \u0026gt;= 32 to resolve this issue. [hverkuil: added fixes tag, rtl2830_pid_filter -\u0026gt; rtl2832_pid_filter in logmsg](CVE-2024-47698)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: can: bcm: Clear bo-\u0026gt;bcm_proc_read after remove_proc_entry(). syzbot reported a warning in bcm_release(). [0] The blamed change fixed another warning that is triggered when connect() is issued again for a socket whose connect()ed device has been unregistered. However, if the socket is just close()d without the 2nd connect(), the remaining bo-\u0026gt;bcm_proc_read triggers unnecessary remove_proc_entry() in bcm_release(). Let\u0026apos;s clear bo-\u0026gt;bcm_proc_read after remove_proc_entry() in bcm_notify(). [0] name \u0026apos;4986\u0026apos; WARNING: CPU: 0 PID: 5234 at fs/proc/generic.c:711 remove_proc_entry+0x2e7/0x5d0 fs/proc/generic.c:711 Modules linked in: CPU: 0 UID: 0 PID: 5234 Comm: syz-executor606 Not tainted 6.11.0-rc5-syzkaller-00178-g5517ae241919 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:remove_proc_entry+0x2e7/0x5d0 fs/proc/generic.c:711 Code: ff eb 05 e8 cb 1e 5e ff 48 8b 5c 24 10 48 c7 c7 e0 f7 aa 8e e8 2a 38 8e 09 90 48 c7 c7 60 3a 1b 8c 48 89 de e8 da 42 20 ff 90 \u0026lt;0f\u0026gt; 0b 90 90 48 8b 44 24 18 48 c7 44 24 40 0e 36 e0 45 49 c7 04 07 RSP: 0018:ffffc9000345fa20 EFLAGS: 00010246 RAX: 2a2d0aee2eb64600 RBX: ffff888032f1f548 RCX: ffff888029431e00 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffc9000345fb08 R08: ffffffff8155b2f2 R09: 1ffff1101710519a R10: dffffc0000000000 R11: ffffed101710519b R12: ffff888011d38640 R13: 0000000000000004 R14: 0000000000000000 R15: dffffc0000000000 FS: 0000000000000000(0000) GS:ffff8880b8800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fcfb52722f0 CR3: 000000000e734000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: \u0026lt;TASK\u0026gt; bcm_release+0x250/0x880 net/can/bcm.c:1578 __sock_release net/socket.c:659 [inline] sock_close+0xbc/0x240 net/socket.c:1421 __fput+0x24a/0x8a0 fs/file_table.c:422 task_work_run+0x24f/0x310 kernel/task_work.c:228 exit_task_work include/linux/task_work.h:40 [inline] do_exit+0xa2f/0x27f0 kernel/exit.c:882 do_group_exit+0x207/0x2c0 kernel/exit.c:1031 __do_sys_exit_group kernel/exit.c:1042 [inline] __se_sys_exit_group kernel/exit.c:1040 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1040 x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fcfb51ee969 Code: Unable to access opcode bytes at 0x7fcfb51ee93f. RSP: 002b:00007ffce0109ca8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007fcfb51ee969 RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000001 RBP: 00007fcfb526f3b0 R08: ffffffffffffffb8 R09: 0000555500000000 R10: 0000555500000000 R11: 0000000000000246 R12: 00007fcfb526f3b0 R13: 0000000000000000 R14: 00007fcfb5271ee0 R15: 00007fcfb51bf160 \u0026lt;/TASK\u0026gt;(CVE-2024-47709)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: sock_map: Add a cond_resched() in sock_hash_free() Several syzbot soft lockup reports all have in common sock_hash_free() If a map with a large number of buckets is destroyed, we need to yield the cpu when needed.(CVE-2024-47710)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for set_output_gamma in dcn30_set_output_transfer_func This commit adds a null check for the set_output_gamma function pointer in the dcn30_set_output_transfer_func function. Previously, set_output_gamma was being checked for nullity at line 386, but then it was being dereferenced without any nullity check at line 401. This could potentially lead to a null pointer dereference error if set_output_gamma is indeed null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a nullity check for set_output_gamma before the call to set_output_gamma at line 401. If set_output_gamma is null, we log an error message and do not call the function. This fix prevents a potential null pointer dereference error. drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:401 dcn30_set_output_transfer_func() error: we previously assumed \u0026apos;mpc-\u0026gt;funcs-\u0026gt;set_output_gamma\u0026apos; could be null (see line 386) drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c 373 bool dcn30_set_output_transfer_func(struct dc *dc, 374 struct pipe_ctx *pipe_ctx, 375 const struct dc_stream_state *stream) 376 { 377 int mpcc_id = pipe_ctx-\u0026gt;plane_res.hubp-\u0026gt;inst; 378 struct mpc *mpc = pipe_ctx-\u0026gt;stream_res.opp-\u0026gt;ctx-\u0026gt;dc-\u0026gt;res_pool-\u0026gt;mpc; 379 const struct pwl_params *params = NULL; 380 bool ret = false; 381 382 /* program OGAM or 3DLUT only for the top pipe*/ 383 if (pipe_ctx-\u0026gt;top_pipe == NULL) { 384 /*program rmu shaper and 3dlut in MPC*/ 385 ret = dcn30_set_mpc_shaper_3dlut(pipe_ctx, stream); 386 if (ret == false \u0026amp;\u0026amp; mpc-\u0026gt;funcs-\u0026gt;set_output_gamma) { ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ If this is NULL 387 if (stream-\u0026gt;out_transfer_func.type == TF_TYPE_HWPWL) 388 params = \u0026amp;stream-\u0026gt;out_transfer_func.pwl; 389 else if (pipe_ctx-\u0026gt;stream-\u0026gt;out_transfer_func.type == 390 TF_TYPE_DISTRIBUTED_POINTS \u0026amp;\u0026amp; 391 cm3_helper_translate_curve_to_hw_format( 392 \u0026amp;stream-\u0026gt;out_transfer_func, 393 \u0026amp;mpc-\u0026gt;blender_params, false)) 394 params = \u0026amp;mpc-\u0026gt;blender_params; 395 /* there are no ROM LUTs in OUTGAM */ 396 if (stream-\u0026gt;out_transfer_func.type == TF_TYPE_PREDEFINED) 397 BREAK_TO_DEBUGGER(); 398 } 399 } 400 --\u0026gt; 401 mpc-\u0026gt;funcs-\u0026gt;set_output_gamma(mpc, mpcc_id, params); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Then it will crash 402 return ret; 403 }(CVE-2024-47720)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix spin_unlock_irqrestore() called with IRQs enabled Fix missuse of spin_lock_irq()/spin_unlock_irq() when spin_lock_irqsave()/spin_lock_irqrestore() was hold. This was discovered through the lock debugging, and the corresponding log is as follows: raw_local_irq_restore() called with IRQs enabled WARNING: CPU: 96 PID: 2074 at kernel/locking/irqflag-debug.c:10 warn_bogus_irq_restore+0x30/0x40 ... Call trace: warn_bogus_irq_restore+0x30/0x40 _raw_spin_unlock_irqrestore+0x84/0xc8 add_qp_to_list+0x11c/0x148 [hns_roce_hw_v2] hns_roce_create_qp_common.constprop.0+0x240/0x780 [hns_roce_hw_v2] hns_roce_create_qp+0x98/0x160 [hns_roce_hw_v2] create_qp+0x138/0x258 ib_create_qp_kernel+0x50/0xe8 create_mad_qp+0xa8/0x128 ib_mad_port_open+0x218/0x448 ib_mad_init_device+0x70/0x1f8 add_client_context+0xfc/0x220 enable_device_and_get+0xd0/0x140 ib_register_device.part.0+0xf4/0x1c8 ib_register_device+0x34/0x50 hns_roce_register_device+0x174/0x3d0 [hns_roce_hw_v2] hns_roce_init+0xfc/0x2c0 [hns_roce_hw_v2] __hns_roce_hw_v2_init_instance+0x7c/0x1d0 [hns_roce_hw_v2] hns_roce_hw_v2_init_instance+0x9c/0x180 [hns_roce_hw_v2](CVE-2024-47735)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: nfsd: call cache_put if xdr_reserve_space returns NULL If not enough buffer space available, but idmap_lookup has triggered lookup_fn which calls cache_get and returns successfully. Then we missed to call cache_put here which pairs with cache_get. Reviwed-by: Jeff Layton \u0026lt;jlayton@kernel.org\u0026gt;(CVE-2024-47737)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential oob read in nilfs_btree_check_delete() The function nilfs_btree_check_delete(), which checks whether degeneration to direct mapping occurs before deleting a b-tree entry, causes memory access outside the block buffer when retrieving the maximum key if the root node has no entries. This does not usually happen because b-tree mappings with 0 child nodes are never created by mkfs.nilfs2 or nilfs2 itself. However, it can happen if the b-tree root node read from a device is configured that way, so fix this potential issue by adding a check for that case.(CVE-2024-47757)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: tracing/timerlat: Fix a race during cpuhp processing There is another found exception that the \u0026quot;timerlat/1\u0026quot; thread was scheduled on CPU0, and lead to timer corruption finally: ``` ODEBUG: init active (active state 0) object: ffff888237c2e108 object type: hrtimer hint: timerlat_irq+0x0/0x220 WARNING: CPU: 0 PID: 426 at lib/debugobjects.c:518 debug_print_object+0x7d/0xb0 Modules linked in: CPU: 0 UID: 0 PID: 426 Comm: timerlat/1 Not tainted 6.11.0-rc7+ #45 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:debug_print_object+0x7d/0xb0 ... Call Trace: \u0026lt;TASK\u0026gt; ? __warn+0x7c/0x110 ? debug_print_object+0x7d/0xb0 ? report_bug+0xf1/0x1d0 ? prb_read_valid+0x17/0x20 ? handle_bug+0x3f/0x70 ? exc_invalid_op+0x13/0x60 ? asm_exc_invalid_op+0x16/0x20 ? debug_print_object+0x7d/0xb0 ? debug_print_object+0x7d/0xb0 ? __pfx_timerlat_irq+0x10/0x10 __debug_object_init+0x110/0x150 hrtimer_init+0x1d/0x60 timerlat_main+0xab/0x2d0 ? __pfx_timerlat_main+0x10/0x10 kthread+0xb7/0xe0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 \u0026lt;/TASK\u0026gt; ``` After tracing the scheduling event, it was discovered that the migration of the \u0026quot;timerlat/1\u0026quot; thread was performed during thread creation. Further analysis confirmed that it is because the CPU online processing for osnoise is implemented through workers, which is asynchronous with the offline processing. When the worker was scheduled to create a thread, the CPU may has already been removed from the cpu_online_mask during the offline process, resulting in the inability to select the right CPU: T1 | T2 [CPUHP_ONLINE] | cpu_device_down() osnoise_hotplug_workfn() | | cpus_write_lock() | takedown_cpu(1) | cpus_write_unlock() [CPUHP_OFFLINE] | cpus_read_lock() | start_kthread(1) | cpus_read_unlock() | To fix this, skip online processing if the CPU is already offline.(CVE-2024-49866)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: btrfs: wait for fixup workers before stopping cleaner kthread during umount During unmount, at close_ctree(), we have the following steps in this order: 1) Park the cleaner kthread - this doesn\u0026apos;t destroy the kthread, it basically halts its execution (wake ups against it work but do nothing); 2) We stop the cleaner kthread - this results in freeing the respective struct task_struct; 3) We call btrfs_stop_all_workers() which waits for any jobs running in all the work queues and then free the work queues. Syzbot reported a case where a fixup worker resulted in a crash when doing a delayed iput on its inode while attempting to wake up the cleaner at btrfs_add_delayed_iput(), because the task_struct of the cleaner kthread was already freed. This can happen during unmount because we don\u0026apos;t wait for any fixup workers still running before we call kthread_stop() against the cleaner kthread, which stops and free all its resources. Fix this by waiting for any fixup workers at close_ctree() before we call kthread_stop() against the cleaner and run pending delayed iputs. The stack traces reported by syzbot were the following: BUG: KASAN: slab-use-after-free in __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065 Read of size 8 at addr ffff8880272a8a18 by task kworker/u8:3/52 CPU: 1 UID: 0 PID: 52 Comm: kworker/u8:3 Not tainted 6.12.0-rc1-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Workqueue: btrfs-fixup btrfs_work_helper Call Trace: \u0026lt;TASK\u0026gt; __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0xd5/0x120 kernel/locking/spinlock.c:162 class_raw_spinlock_irqsave_constructor include/linux/spinlock.h:551 [inline] try_to_wake_up+0xb0/0x1480 kernel/sched/core.c:4154 btrfs_writepage_fixup_worker+0xc16/0xdf0 fs/btrfs/inode.c:2842 btrfs_work_helper+0x390/0xc50 fs/btrfs/async-thread.c:314 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa63/0x1850 kernel/workqueue.c:3310 worker_thread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 \u0026lt;/TASK\u0026gt; Allocated by task 2: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:319 [inline] __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:345 kasan_slab_alloc include/linux/kasan.h:247 [inline] slab_post_alloc_hook mm/slub.c:4086 [inline] slab_alloc_node mm/slub.c:4135 [inline] kmem_cache_alloc_node_noprof+0x16b/0x320 mm/slub.c:4187 alloc_task_struct_node kernel/fork.c:180 [inline] dup_task_struct+0x57/0x8c0 kernel/fork.c:1107 copy_process+0x5d1/0x3d50 kernel/fork.c:2206 kernel_clone+0x223/0x880 kernel/fork.c:2787 kernel_thread+0x1bc/0x240 kernel/fork.c:2849 create_kthread kernel/kthread.c:412 [inline] kthreadd+0x60d/0x810 kernel/kthread.c:765 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Freed by task 61: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:230 [inline] slab_free_h ---truncated---(CVE-2024-49867)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: btrfs: fix a NULL pointer dereference when failed to start a new trasacntion [BUG] Syzbot reported a NULL pointer dereference with the following crash: FAULT_INJECTION: forcing a failure. start_transaction+0x830/0x1670 fs/btrfs/transaction.c:676 prepare_to_relocate+0x31f/0x4c0 fs/btrfs/relocation.c:3642 relocate_block_group+0x169/0xd20 fs/btrfs/relocation.c:3678 ... BTRFS info (device loop0): balance: ended with status: -12 Oops: general protection fault, probably for non-canonical address 0xdffffc00000000cc: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000660-0x0000000000000667] RIP: 0010:btrfs_update_reloc_root+0x362/0xa80 fs/btrfs/relocation.c:926 Call Trace: \u0026lt;TASK\u0026gt; commit_fs_roots+0x2ee/0x720 fs/btrfs/transaction.c:1496 btrfs_commit_transaction+0xfaf/0x3740 fs/btrfs/transaction.c:2430 del_balance_item fs/btrfs/volumes.c:3678 [inline] reset_balance_state+0x25e/0x3c0 fs/btrfs/volumes.c:3742 btrfs_balance+0xead/0x10c0 fs/btrfs/volumes.c:4574 btrfs_ioctl_balance+0x493/0x7c0 fs/btrfs/ioctl.c:3673 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f [CAUSE] The allocation failure happens at the start_transaction() inside prepare_to_relocate(), and during the error handling we call unset_reloc_control(), which makes fs_info-\u0026gt;balance_ctl to be NULL. Then we continue the error path cleanup in btrfs_balance() by calling reset_balance_state() which will call del_balance_item() to fully delete the balance item in the root tree. However during the small window between set_reloc_contrl() and unset_reloc_control(), we can have a subvolume tree update and created a reloc_root for that subvolume. Then we go into the final btrfs_commit_transaction() of del_balance_item(), and into btrfs_update_reloc_root() inside commit_fs_roots(). That function checks if fs_info-\u0026gt;reloc_ctl is in the merge_reloc_tree stage, but since fs_info-\u0026gt;reloc_ctl is NULL, it results a NULL pointer dereference. [FIX] Just add extra check on fs_info-\u0026gt;reloc_ctl inside btrfs_update_reloc_root(), before checking fs_info-\u0026gt;reloc_ctl-\u0026gt;merge_reloc_tree. That DEAD_RELOC_TREE handling is to prevent further modification to the reloc tree during merge stage, but since there is no reloc_ctl at all, we do not need to bother that.(CVE-2024-49868)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Initialize get_bytes_per_element\u0026apos;s default to 1 Variables, used as denominators and maybe not assigned to other values, should not be 0. bytes_per_element_y \u0026amp; bytes_per_element_c are initialized by get_bytes_per_element() which should never return 0. This fixes 10 DIVIDE_BY_ZERO issues reported by Coverity.(CVE-2024-49892)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in degamma hardware format translation Fixes index out of bounds issue in `cm_helper_translate_curve_to_degamma_hw_format` function. The issue could occur when the index \u0026apos;i\u0026apos; exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure \u0026apos;i\u0026apos; is within bounds before accessing the transfer function points. If \u0026apos;i\u0026apos; is out of bounds the function returns false to indicate an error. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:594 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.red\u0026apos; 1025 \u0026lt;= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:595 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.green\u0026apos; 1025 \u0026lt;= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:596 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.blue\u0026apos; 1025 \u0026lt;= s32max(CVE-2024-49894)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in DCN30 degamma hardware format translation This commit addresses a potential index out of bounds issue in the `cm3_helper_translate_curve_to_degamma_hw_format` function in the DCN30 color management module. The issue could occur when the index \u0026apos;i\u0026apos; exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure \u0026apos;i\u0026apos; is within bounds before accessing the transfer function points. If \u0026apos;i\u0026apos; is out of bounds, the function returns false to indicate an error. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:338 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.red\u0026apos; 1025 \u0026lt;= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:339 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.green\u0026apos; 1025 \u0026lt;= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:340 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.blue\u0026apos; 1025 \u0026lt;= s32max(CVE-2024-49895)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: jfs: Fix uninit-value access of new_ea in ea_buffer syzbot reports that lzo1x_1_do_compress is using uninit-value: ===================================================== BUG: KMSAN: uninit-value in lzo1x_1_do_compress+0x19f9/0x2510 lib/lzo/lzo1x_compress.c:178 ... Uninit was stored to memory at: ea_put fs/jfs/xattr.c:639 [inline] ... Local variable ea_buf created at: __jfs_setxattr+0x5d/0x1ae0 fs/jfs/xattr.c:662 __jfs_xattr_set+0xe6/0x1f0 fs/jfs/xattr.c:934 ===================================================== The reason is ea_buf-\u0026gt;new_ea is not initialized properly. Fix this by using memset to empty its content at the beginning in ea_get().(CVE-2024-49900)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: jfs: check if leafidx greater than num leaves per dmap tree syzbot report a out of bounds in dbSplit, it because dmt_leafidx greater than num leaves per dmap tree, add a checking for dmt_leafidx in dbFindLeaf. Shaggy: Modified sanity check to apply to control pages as well as leaf pages.(CVE-2024-49902)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: jfs: Fix uaf in dbFreeBits [syzbot reported] ================================================================== BUG: KASAN: slab-use-after-free in __mutex_lock_common kernel/locking/mutex.c:587 [inline] BUG: KASAN: slab-use-after-free in __mutex_lock+0xfe/0xd70 kernel/locking/mutex.c:752 Read of size 8 at addr ffff8880229254b0 by task syz-executor357/5216 CPU: 0 UID: 0 PID: 5216 Comm: syz-executor357 Not tainted 6.11.0-rc3-syzkaller-00156-gd7a5aa4b3c00 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024 Call Trace: \u0026lt;TASK\u0026gt; __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 __mutex_lock_common kernel/locking/mutex.c:587 [inline] __mutex_lock+0xfe/0xd70 kernel/locking/mutex.c:752 dbFreeBits+0x7ea/0xd90 fs/jfs/jfs_dmap.c:2390 dbFreeDmap fs/jfs/jfs_dmap.c:2089 [inline] dbFree+0x35b/0x680 fs/jfs/jfs_dmap.c:409 dbDiscardAG+0x8a9/0xa20 fs/jfs/jfs_dmap.c:1650 jfs_ioc_trim+0x433/0x670 fs/jfs/jfs_discard.c:100 jfs_ioctl+0x2d0/0x3e0 fs/jfs/ioctl.c:131 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 Freed by task 5218: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579 poison_slab_object+0xe0/0x150 mm/kasan/common.c:240 __kasan_slab_free+0x37/0x60 mm/kasan/common.c:256 kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2252 [inline] slab_free mm/slub.c:4473 [inline] kfree+0x149/0x360 mm/slub.c:4594 dbUnmount+0x11d/0x190 fs/jfs/jfs_dmap.c:278 jfs_mount_rw+0x4ac/0x6a0 fs/jfs/jfs_mount.c:247 jfs_remount+0x3d1/0x6b0 fs/jfs/super.c:454 reconfigure_super+0x445/0x880 fs/super.c:1083 vfs_cmd_reconfigure fs/fsopen.c:263 [inline] vfs_fsconfig_locked fs/fsopen.c:292 [inline] __do_sys_fsconfig fs/fsopen.c:473 [inline] __se_sys_fsconfig+0xb6e/0xf80 fs/fsopen.c:345 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f [Analysis] There are two paths (dbUnmount and jfs_ioc_trim) that generate race condition when accessing bmap, which leads to the occurrence of uaf. Use the lock s_umount to synchronize them, in order to avoid uaf caused by race condition.(CVE-2024-49903)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for function pointer in dcn20_set_output_transfer_func This commit adds a null check for the set_output_gamma function pointer in the dcn20_set_output_transfer_func function. Previously, set_output_gamma was being checked for null at line 1030, but then it was being dereferenced without any null check at line 1048. This could potentially lead to a null pointer dereference error if set_output_gamma is null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a null check for set_output_gamma before the call to set_output_gamma at line 1048.(CVE-2024-49911)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: x86/ioapic: Handle allocation failures gracefully Breno observed panics when using failslab under certain conditions during runtime: can not alloc irq_pin_list (-1,0,20) Kernel panic - not syncing: IO-APIC: failed to add irq-pin. Can not proceed panic+0x4e9/0x590 mp_irqdomain_alloc+0x9ab/0xa80 irq_domain_alloc_irqs_locked+0x25d/0x8d0 __irq_domain_alloc_irqs+0x80/0x110 mp_map_pin_to_irq+0x645/0x890 acpi_register_gsi_ioapic+0xe6/0x150 hpet_open+0x313/0x480 That\u0026apos;s a pointless panic which is a leftover of the historic IO/APIC code which panic\u0026apos;ed during early boot when the interrupt allocation failed. The only place which might justify panic is the PIT/HPET timer_check() code which tries to figure out whether the timer interrupt is delivered through the IO/APIC. But that code does not require to handle interrupt allocation failures. If the interrupt cannot be allocated then timer delivery fails and it either panics due to that or falls back to legacy mode. Cure this by removing the panic wrapper around __add_pin_to_irq_node() and making mp_irqdomain_alloc() aware of the failure condition and handle it as any other failure in this function gracefully.(CVE-2024-49927)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: jbd2: stop waiting for space when jbd2_cleanup_journal_tail() returns error In __jbd2_log_wait_for_space(), we might call jbd2_cleanup_journal_tail() to recover some journal space. But if an error occurs while executing jbd2_cleanup_journal_tail() (e.g., an EIO), we don\u0026apos;t stop waiting for free space right away, we try other branches, and if j_committing_transaction is NULL (i.e., the tid is 0), we will get the following complain: ============================================ JBD2: I/O error when updating journal superblock for sdd-8. __jbd2_log_wait_for_space: needed 256 blocks and only had 217 space available __jbd2_log_wait_for_space: no way to get more journal space in sdd-8 ------------[ cut here ]------------ WARNING: CPU: 2 PID: 139804 at fs/jbd2/checkpoint.c:109 __jbd2_log_wait_for_space+0x251/0x2e0 Modules linked in: CPU: 2 PID: 139804 Comm: kworker/u8:3 Not tainted 6.6.0+ #1 RIP: 0010:__jbd2_log_wait_for_space+0x251/0x2e0 Call Trace: \u0026lt;TASK\u0026gt; add_transaction_credits+0x5d1/0x5e0 start_this_handle+0x1ef/0x6a0 jbd2__journal_start+0x18b/0x340 ext4_dirty_inode+0x5d/0xb0 __mark_inode_dirty+0xe4/0x5d0 generic_update_time+0x60/0x70 [...] ============================================ So only if jbd2_cleanup_journal_tail() returns 1, i.e., there is nothing to clean up at the moment, continue to try to reclaim free space in other ways. Note that this fix relies on commit 6f6a6fda2945 (\u0026quot;jbd2: fix ocfs2 corrupt when updating journal superblock fails\u0026quot;) to make jbd2_cleanup_journal_tail return the correct error code.(CVE-2024-49959)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: ocfs2: remove unreasonable unlock in ocfs2_read_blocks Patch series \u0026quot;Misc fixes for ocfs2_read_blocks\u0026quot;, v5. This series contains 2 fixes for ocfs2_read_blocks(). The first patch fix the issue reported by syzbot, which detects bad unlock balance in ocfs2_read_blocks(). The second patch fixes an issue reported by Heming Zhao when reviewing above fix. This patch (of 2): There was a lock release before exiting, so remove the unreasonable unlock.(CVE-2024-49965)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: ocfs2: cancel dqi_sync_work before freeing oinfo ocfs2_global_read_info() will initialize and schedule dqi_sync_work at the end, if error occurs after successfully reading global quota, it will trigger the following warning with CONFIG_DEBUG_OBJECTS_* enabled: ODEBUG: free active (active state 0) object: 00000000d8b0ce28 object type: timer_list hint: qsync_work_fn+0x0/0x16c This reports that there is an active delayed work when freeing oinfo in error handling, so cancel dqi_sync_work first. BTW, return status instead of -1 when .read_file_info fails.(CVE-2024-49966)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in DCN30 color transformation This commit addresses a potential index out of bounds issue in the `cm3_helper_translate_curve_to_hw_format` function in the DCN30 color management module. The issue could occur when the index \u0026apos;i\u0026apos; exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure \u0026apos;i\u0026apos; is within bounds before accessing the transfer function points. If \u0026apos;i\u0026apos; is out of bounds, the function returns false to indicate an error. drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:180 cm3_helper_translate_curve_to_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.red\u0026apos; 1025 \u0026lt;= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:181 cm3_helper_translate_curve_to_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.green\u0026apos; 1025 \u0026lt;= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:182 cm3_helper_translate_curve_to_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.blue\u0026apos; 1025 \u0026lt;= s32max(CVE-2024-49969)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: NFSD: Limit the number of concurrent async COPY operations Nothing appears to limit the number of concurrent async COPY operations that clients can start. In addition, AFAICT each async COPY can copy an unlimited number of 4MB chunks, so can run for a long time. Thus IMO async COPY can become a DoS vector. Add a restriction mechanism that bounds the number of concurrent background COPY operations. Start simple and try to be fair -- this patch implements a per-namespace limit. An async COPY request that occurs while this limit is exceeded gets NFS4ERR_DELAY. The requesting client can choose to send the request again after a delay or fall back to a traditional read/write style copy. If there is need to make the mechanism more sophisticated, we can visit that in future patches.(CVE-2024-49974)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: i2c: stm32f7: Do not prepare/unprepare clock during runtime suspend/resume In case there is any sort of clock controller attached to this I2C bus controller, for example Versaclock or even an AIC32x4 I2C codec, then an I2C transfer triggered from the clock controller clk_ops .prepare callback may trigger a deadlock on drivers/clk/clk.c prepare_lock mutex. This is because the clock controller first grabs the prepare_lock mutex and then performs the prepare operation, including its I2C access. The I2C access resumes this I2C bus controller via .runtime_resume callback, which calls clk_prepare_enable(), which attempts to grab the prepare_lock mutex again and deadlocks. Since the clock are already prepared since probe() and unprepared in remove(), use simple clk_enable()/clk_disable() calls to enable and disable the clock on runtime suspend and resume, to avoid hitting the prepare_lock mutex.(CVE-2024-49985)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: scsi: fnic: Move flush_work initialization out of if block After commit 379a58caa199 (\u0026quot;scsi: fnic: Move fnic_fnic_flush_tx() to a work queue\u0026quot;), it can happen that a work item is sent to an uninitialized work queue. This may has the effect that the item being queued is never actually queued, and any further actions depending on it will not proceed. The following warning is observed while the fnic driver is loaded: kernel: WARNING: CPU: 11 PID: 0 at ../kernel/workqueue.c:1524 __queue_work+0x373/0x410 kernel: \u0026lt;IRQ\u0026gt; kernel: queue_work_on+0x3a/0x50 kernel: fnic_wq_copy_cmpl_handler+0x54a/0x730 [fnic 62fbff0c42e7fb825c60a55cde2fb91facb2ed24] kernel: fnic_isr_msix_wq_copy+0x2d/0x60 [fnic 62fbff0c42e7fb825c60a55cde2fb91facb2ed24] kernel: __handle_irq_event_percpu+0x36/0x1a0 kernel: handle_irq_event_percpu+0x30/0x70 kernel: handle_irq_event+0x34/0x60 kernel: handle_edge_irq+0x7e/0x1a0 kernel: __common_interrupt+0x3b/0xb0 kernel: common_interrupt+0x58/0xa0 kernel: \u0026lt;/IRQ\u0026gt; It has been observed that this may break the rediscovery of Fibre Channel devices after a temporary fabric failure. This patch fixes it by moving the work queue initialization out of an if block in fnic_probe().(CVE-2024-50025)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: net: do not delay dst_entries_add() in dst_release() dst_entries_add() uses per-cpu data that might be freed at netns dismantle from ip6_route_net_exit() calling dst_entries_destroy() Before ip6_route_net_exit() can be called, we release all the dsts associated with this netns, via calls to dst_release(), which waits an rcu grace period before calling dst_destroy() dst_entries_add() use in dst_destroy() is racy, because dst_entries_destroy() could have been called already. Decrementing the number of dsts must happen sooner. Notes: 1) in CONFIG_XFRM case, dst_destroy() can call dst_release_immediate(child), this might also cause UAF if the child does not have DST_NOCOUNT set. IPSEC maintainers might take a look and see how to address this. 2) There is also discussion about removing this count of dst, which might happen in future kernels.(CVE-2024-50036)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: NFSv4: Prevent NULL-pointer dereference in nfs42_complete_copies() On the node of an NFS client, some files saved in the mountpoint of the NFS server were copied to another location of the same NFS server. Accidentally, the nfs42_complete_copies() got a NULL-pointer dereference crash with the following syslog: [232064.838881] NFSv4: state recovery failed for open file nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116 [232064.839360] NFSv4: state recovery failed for open file nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116 [232066.588183] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000058 [232066.588586] Mem abort info: [232066.588701] ESR = 0x0000000096000007 [232066.588862] EC = 0x25: DABT (current EL), IL = 32 bits [232066.589084] SET = 0, FnV = 0 [232066.589216] EA = 0, S1PTW = 0 [232066.589340] FSC = 0x07: level 3 translation fault [232066.589559] Data abort info: [232066.589683] ISV = 0, ISS = 0x00000007 [232066.589842] CM = 0, WnR = 0 [232066.589967] user pgtable: 64k pages, 48-bit VAs, pgdp=00002000956ff400 [232066.590231] [0000000000000058] pgd=08001100ae100003, p4d=08001100ae100003, pud=08001100ae100003, pmd=08001100b3c00003, pte=0000000000000000 [232066.590757] Internal error: Oops: 96000007 [#1] SMP [232066.590958] Modules linked in: rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm vhost_net vhost vhost_iotlb tap tun ipt_rpfilter xt_multiport ip_set_hash_ip ip_set_hash_net xfrm_interface xfrm6_tunnel tunnel4 tunnel6 esp4 ah4 wireguard libcurve25519_generic veth xt_addrtype xt_set nf_conntrack_netlink ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_bitmap_port ip_set_hash_ipport dummy ip_set ip_vs_sh ip_vs_wrr ip_vs_rr ip_vs iptable_filter sch_ingress nfnetlink_cttimeout vport_gre ip_gre ip_tunnel gre vport_geneve geneve vport_vxlan vxlan ip6_udp_tunnel udp_tunnel openvswitch nf_conncount dm_round_robin dm_service_time dm_multipath xt_nat xt_MASQUERADE nft_chain_nat nf_nat xt_mark xt_conntrack xt_comment nft_compat nft_counter nf_tables nfnetlink ocfs2 ocfs2_nodemanager ocfs2_stackglue iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ipmi_ssif nbd overlay 8021q garp mrp bonding tls rfkill sunrpc ext4 mbcache jbd2 [232066.591052] vfat fat cas_cache cas_disk ses enclosure scsi_transport_sas sg acpi_ipmi ipmi_si ipmi_devintf ipmi_msghandler ip_tables vfio_pci vfio_pci_core vfio_virqfd vfio_iommu_type1 vfio dm_mirror dm_region_hash dm_log dm_mod nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter bridge stp llc fuse xfs libcrc32c ast drm_vram_helper qla2xxx drm_kms_helper syscopyarea crct10dif_ce sysfillrect ghash_ce sysimgblt sha2_ce fb_sys_fops cec sha256_arm64 sha1_ce drm_ttm_helper ttm nvme_fc igb sbsa_gwdt nvme_fabrics drm nvme_core i2c_algo_bit i40e scsi_transport_fc megaraid_sas aes_neon_bs [232066.596953] CPU: 6 PID: 4124696 Comm: 10.253.166.125- Kdump: loaded Not tainted 5.15.131-9.cl9_ocfs2.aarch64 #1 [232066.597356] Hardware name: Great Wall .\\x93\\x8e...RF6260 V5/GWMSSE2GL1T, BIOS T656FBE_V3.0.18 2024-01-06 [232066.597721] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [232066.598034] pc : nfs4_reclaim_open_state+0x220/0x800 [nfsv4] [232066.598327] lr : nfs4_reclaim_open_state+0x12c/0x800 [nfsv4] [232066.598595] sp : ffff8000f568fc70 [232066.598731] x29: ffff8000f568fc70 x28: 0000000000001000 x27: ffff21003db33000 [232066.599030] x26: ffff800005521ae0 x25: ffff0100f98fa3f0 x24: 0000000000000001 [232066.599319] x23: ffff800009920008 x22: ffff21003db33040 x21: ffff21003db33050 [232066.599628] x20: ffff410172fe9e40 x19: ffff410172fe9e00 x18: 0000000000000000 [232066.599914] x17: 0000000000000000 x16: 0000000000000004 x15: 0000000000000000 [232066.600195] x14: 0000000000000000 x13: ffff800008e685a8 x12: 00000000eac0c6e6 [232066.600498] x11: 00000000000000 ---truncated---(CVE-2024-50046)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointer before dereferencing se [WHAT \u0026amp; HOW] se is null checked previously in the same function, indicating it might be null; therefore, it must be checked when used again. This fixes 1 FORWARD_NULL issue reported by Coverity.(CVE-2024-50049)",
"id": "OESA-2024-2322",
"modified": "2026-08-06T11:07:48Z",
"published": "2024-11-01T11:07:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2322"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48916"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48952"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48988"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52917"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52918"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52919"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35878"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35990"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36286"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38635"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38667"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42152"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42301"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42315"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43841"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43858"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43867"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43871"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43894"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45009"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46675"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46689"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46722"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46724"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46757"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46802"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46830"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46853"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47667"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47669"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47684"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47685"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47692"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47695"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47698"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47709"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47710"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47720"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47735"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47737"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47757"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49866"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49867"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49868"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49892"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49894"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49895"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49900"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49902"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49903"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49911"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49927"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49959"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49965"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49966"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49969"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49974"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49985"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50025"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50036"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50046"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50049"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2022-48916",
"CVE-2022-48952",
"CVE-2022-48988",
"CVE-2023-52917",
"CVE-2023-52918",
"CVE-2023-52919",
"CVE-2024-35878",
"CVE-2024-35990",
"CVE-2024-36286",
"CVE-2024-38635",
"CVE-2024-38667",
"CVE-2024-42152",
"CVE-2024-42301",
"CVE-2024-42315",
"CVE-2024-43841",
"CVE-2024-43858",
"CVE-2024-43867",
"CVE-2024-43871",
"CVE-2024-43894",
"CVE-2024-45009",
"CVE-2024-46675",
"CVE-2024-46689",
"CVE-2024-46722",
"CVE-2024-46724",
"CVE-2024-46757",
"CVE-2024-46802",
"CVE-2024-46830",
"CVE-2024-46853",
"CVE-2024-47667",
"CVE-2024-47669",
"CVE-2024-47684",
"CVE-2024-47685",
"CVE-2024-47692",
"CVE-2024-47695",
"CVE-2024-47698",
"CVE-2024-47709",
"CVE-2024-47710",
"CVE-2024-47720",
"CVE-2024-47735",
"CVE-2024-47737",
"CVE-2024-47757",
"CVE-2024-49866",
"CVE-2024-49867",
"CVE-2024-49868",
"CVE-2024-49892",
"CVE-2024-49894",
"CVE-2024-49895",
"CVE-2024-49900",
"CVE-2024-49902",
"CVE-2024-49903",
"CVE-2024-49911",
"CVE-2024-49927",
"CVE-2024-49959",
"CVE-2024-49965",
"CVE-2024-49966",
"CVE-2024-49969",
"CVE-2024-49974",
"CVE-2024-49985",
"CVE-2024-50025",
"CVE-2024-50036",
"CVE-2024-50046",
"CVE-2024-50049"
]
}
OESA-2024-2323 (CVE-2022-48946)
Vulnerability from osv_openeuler – Published: 2024-11-01 11:07 – Updated: 2026-08-06 11:07 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved: udf: Fix preallocation discarding at indirect extent boundary When preallocation extent is the first one in the extent block, the code would corrupt extent tree header instead. Fix the problem and use udf_delete_aext() for deleting extent to avoid some code duplication.(CVE-2022-48946)
In the Linux kernel, the following vulnerability has been resolved: NFC: nci: Bounds check struct nfc_target arrays While running under CONFIG_FORTIFY_SOURCE=y, syzkaller reported: memcpy: detected field-spanning write (size 129) of single field "target->sensf_res" at net/nfc/nci/ntf.c:260 (size 18) This appears to be a legitimate lack of bounds checking in nci_add_new_protocol(). Add the missing checks.(CVE-2022-48967)
In the Linux kernel, the following vulnerability has been resolved: gpio: amd8111: Fix PCI device reference count leak for_each_pci_dev() is implemented by pci_get_device(). The comment of pci_get_device() says that it will increase the reference count for the returned pci_dev and also decrease the reference count for the input pci_dev @from if it is not NULL. If we break for_each_pci_dev() loop with pdev not NULL, we need to call pci_dev_put() to decrease the reference count. Add the missing pci_dev_put() after the 'out' label. Since pci_dev_put() can handle NULL input parameter, there is no problem for the 'Device not found' branch. For the normal path, add pci_dev_put() in amd_gpio_exit().(CVE-2022-48973)
In the Linux kernel, the following vulnerability has been resolved: ALSA: seq: Fix function prototype mismatch in snd_seq_expand_var_event With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG), indirect call targets are validated against the expected function pointer prototype to make sure the call target is valid to help mitigate ROP attacks. If they are not identical, there is a failure at run time, which manifests as either a kernel panic or thread getting killed. seq_copy_in_user() and seq_copy_in_kernel() did not have prototypes matching snd_seq_dump_func_t. Adjust this and remove the casts. There are not resulting binary output differences. This was found as a result of Clang's new -Wcast-function-type-strict flag, which is more sensitive than the simpler -Wcast-function-type, which only checks for type width mismatches.(CVE-2022-48994)
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix NULL pointer dereference in nilfs_palloc_commit_free_entry() Syzbot reported a null-ptr-deref bug: NILFS (loop0): segctord starting. Construction interval = 5 seconds, CP frequency < 30 seconds general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] CPU: 1 PID: 3603 Comm: segctord Not tainted 6.1.0-rc2-syzkaller-00105-gb229b6ca5abb #0 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 10/11/2022 RIP: 0010:nilfs_palloc_commit_free_entry+0xe5/0x6b0 fs/nilfs2/alloc.c:608 Code: 00 00 00 00 fc ff df 80 3c 02 00 0f 85 cd 05 00 00 48 b8 00 00 00 00 00 fc ff df 4c 8b 73 08 49 8d 7e 10 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 26 05 00 00 49 8b 46 10 be a6 00 00 00 48 c7 c7 RSP: 0018:ffffc90003dff830 EFLAGS: 00010212 RAX: dffffc0000000000 RBX: ffff88802594e218 RCX: 000000000000000d RDX: 0000000000000002 RSI: 0000000000002000 RDI: 0000000000000010 RBP: ffff888071880222 R08: 0000000000000005 R09: 000000000000003f R10: 000000000000000d R11: 0000000000000000 R12: ffff888071880158 R13: ffff88802594e220 R14: 0000000000000000 R15: 0000000000000004 FS: 0000000000000000(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fb1c08316a8 CR3: 0000000018560000 CR4: 0000000000350ee0 Call Trace: <TASK> nilfs_dat_commit_free fs/nilfs2/dat.c:114 [inline] nilfs_dat_commit_end+0x464/0x5f0 fs/nilfs2/dat.c:193 nilfs_dat_commit_update+0x26/0x40 fs/nilfs2/dat.c:236 nilfs_btree_commit_update_v+0x87/0x4a0 fs/nilfs2/btree.c:1940 nilfs_btree_commit_propagate_v fs/nilfs2/btree.c:2016 [inline] nilfs_btree_propagate_v fs/nilfs2/btree.c:2046 [inline] nilfs_btree_propagate+0xa00/0xd60 fs/nilfs2/btree.c:2088 nilfs_bmap_propagate+0x73/0x170 fs/nilfs2/bmap.c:337 nilfs_collect_file_data+0x45/0xd0 fs/nilfs2/segment.c:568 nilfs_segctor_apply_buffers+0x14a/0x470 fs/nilfs2/segment.c:1018 nilfs_segctor_scan_file+0x3f4/0x6f0 fs/nilfs2/segment.c:1067 nilfs_segctor_collect_blocks fs/nilfs2/segment.c:1197 [inline] nilfs_segctor_collect fs/nilfs2/segment.c:1503 [inline] nilfs_segctor_do_construct+0x12fc/0x6af0 fs/nilfs2/segment.c:2045 nilfs_segctor_construct+0x8e3/0xb30 fs/nilfs2/segment.c:2379 nilfs_segctor_thread_construct fs/nilfs2/segment.c:2487 [inline] nilfs_segctor_thread+0x3c3/0xf30 fs/nilfs2/segment.c:2570 kthread+0x2e4/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306 </TASK> ... If DAT metadata file is corrupted on disk, there is a case where req->pr_desc_bh is NULL and blocknr is 0 at nilfs_dat_commit_end() during a b-tree operation that cascadingly updates ancestor nodes of the b-tree, because nilfs_dat_commit_alloc() for a lower level block can initialize the blocknr on the same DAT entry between nilfs_dat_prepare_end() and nilfs_dat_commit_end(). If this happens, nilfs_dat_commit_end() calls nilfs_dat_commit_free() without valid buffer heads in req->pr_desc_bh and req->pr_bitmap_bh, and causes the NULL pointer dereference above in nilfs_palloc_commit_free_entry() function, which leads to a crash. Fix this by adding a NULL check on req->pr_desc_bh and req->pr_bitmap_bh before nilfs_palloc_commit_free_entry() in nilfs_dat_commit_free(). This also calls nilfs_error() in that case to notify that there is a fatal flaw in the filesystem metadata and prevent further operations.(CVE-2022-49007)
In the Linux kernel, the following vulnerability has been resolved: hwmon: (coretemp) Check for null before removing sysfs attrs If coretemp_add_core() gets an error then pdata->core_data[indx] is already NULL and has been kfreed. Don't pass that to sysfs_remove_group() as that will crash in sysfs_remove_group(). [Shortened for readability] [91854.020159] sysfs: cannot create duplicate filename '/devices/platform/coretemp.0/hwmon/hwmon2/temp20_label' <cpu offline> [91855.126115] BUG: kernel NULL pointer dereference, address: 0000000000000188 [91855.165103] #PF: supervisor read access in kernel mode [91855.194506] #PF: error_code(0x0000) - not-present page [91855.224445] PGD 0 P4D 0 [91855.238508] Oops: 0000 [#1] PREEMPT SMP PTI ... [91855.342716] RIP: 0010:sysfs_remove_group+0xc/0x80 ... [91855.796571] Call Trace: [91855.810524] coretemp_cpu_offline+0x12b/0x1dd [coretemp] [91855.841738] ? coretemp_cpu_online+0x180/0x180 [coretemp] [91855.871107] cpuhp_invoke_callback+0x105/0x4b0 [91855.893432] cpuhp_thread_fun+0x8e/0x150 ... Fix this by checking for NULL first.(CVE-2022-49010)
In the Linux kernel, the following vulnerability has been resolved: hwmon: (ibmpex) Fix possible UAF when ibmpex_register_bmc() fails Smatch report warning as follows: drivers/hwmon/ibmpex.c:509 ibmpex_register_bmc() warn: '&data->list' not removed from list If ibmpex_find_sensors() fails in ibmpex_register_bmc(), data will be freed, but data->list will not be removed from driver_data.bmc_data, then list traversal may cause UAF. Fix by removeing it from driver_data.bmc_data before free().(CVE-2022-49029)
In the Linux kernel, the following vulnerability has been resolved: btrfs: qgroup: fix sleep from invalid context bug in btrfs_qgroup_inherit() Syzkaller reported BUG as follows: BUG: sleeping function called from invalid context at include/linux/sched/mm.h:274 Call Trace: <TASK> dump_stack_lvl+0xcd/0x134 __might_resched.cold+0x222/0x26b kmem_cache_alloc+0x2e7/0x3c0 update_qgroup_limit_item+0xe1/0x390 btrfs_qgroup_inherit+0x147b/0x1ee0 create_subvol+0x4eb/0x1710 btrfs_mksubvol+0xfe5/0x13f0 __btrfs_ioctl_snap_create+0x2b0/0x430 btrfs_ioctl_snap_create_v2+0x25a/0x520 btrfs_ioctl+0x2a1c/0x5ce0 __x64_sys_ioctl+0x193/0x200 do_syscall_64+0x35/0x80 Fix this by calling qgroup_dirty() on @dstqgroup, and update limit item in btrfs_run_qgroups() later outside of the spinlock context.(CVE-2022-49033)
In the Linux kernel, the following vulnerability has been resolved: media: pci: cx23885: check cx23885_vdev_init() return cx23885_vdev_init() can return a NULL pointer, but that pointer is used in the next line without a check. Add a NULL pointer check and go to the error unwind if it is NULL.(CVE-2023-52918)
In the Linux kernel, the following vulnerability has been resolved: nfc: nci: fix possible NULL pointer dereference in send_acknowledge() Handle memory allocation failure from nci_skb_alloc() (calling alloc_skb()) to avoid possible NULL pointer dereference.(CVE-2023-52919)
In the Linux kernel, the following vulnerability has been resolved:
usb: dwc3: core: Prevent USB core invalid event buffer address access
This commit addresses an issue where the USB core could access an invalid event buffer address during runtime suspend, potentially causing SMMU faults and other memory issues in Exynos platforms. The problem arises from the following sequence. 1. In dwc3_gadget_suspend, there is a chance of a timeout when moving the USB core to the halt state after clearing the run/stop bit by software. 2. In dwc3_core_exit, the event buffer is cleared regardless of the USB core's status, which may lead to an SMMU faults and other memory issues. if the USB core tries to access the event buffer address.
To prevent this hardware quirk on Exynos platforms, this commit ensures that the event buffer address is not cleared by software when the USB core is active during runtime suspend by checking its status before clearing the buffer address.(CVE-2024-46675)
In the Linux kernel, the following vulnerability has been resolved:
gtp: fix a potential NULL pointer dereference
When sockfd_lookup() fails, gtp_encap_enable_socket() returns a NULL pointer, but its callers only check for error pointers thus miss the NULL pointer case.
Fix it by returning an error pointer with the error code carried from sockfd_lookup().
(I found this bug during code inspection.)(CVE-2024-46677)
In the Linux kernel, the following vulnerability has been resolved:
pinctrl: single: fix potential NULL dereference in pcs_get_function()
pinmux_generic_get_function() can return NULL and the pointer 'function' was dereferenced without checking against NULL. Add checking of pointer 'function' in pcs_get_function().
Found by code review.(CVE-2024-46685)
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Fix out-of-bounds read of df_v1_7_channel_number
Check the fb_channel_number range to avoid the array out-of-bounds read error(CVE-2024-46724)
In the Linux kernel, the following vulnerability has been resolved:
of/irq: Prevent device address out-of-bounds read in interrupt map walk
When of_irq_parse_raw() is invoked with a device address smaller than the interrupt parent node (from #address-cells property), KASAN detects the following out-of-bounds read when populating the initial match table (dyndbg="func of_irq_parse_* +p"):
OF: of_irq_parse_one: dev=/soc@0/picasso/watchdog, index=0 OF: parent=/soc@0/pci@878000000000/gpio0@17,0, intsize=2 OF: intspec=4 OF: of_irq_parse_raw: ipar=/soc@0/pci@878000000000/gpio0@17,0, size=2 OF: -> addrsize=3 ================================================================== BUG: KASAN: slab-out-of-bounds in of_irq_parse_raw+0x2b8/0x8d0 Read of size 4 at addr ffffff81beca5608 by task bash/764
CPU: 1 PID: 764 Comm: bash Tainted: G O 6.1.67-484c613561-nokia_sm_arm64 #1 Hardware name: Unknown Unknown Product/Unknown Product, BIOS 2023.01-12.24.03-dirty 01/01/2023 Call trace: dump_backtrace+0xdc/0x130 show_stack+0x1c/0x30 dump_stack_lvl+0x6c/0x84 print_report+0x150/0x448 kasan_report+0x98/0x140 __asan_load4+0x78/0xa0 of_irq_parse_raw+0x2b8/0x8d0 of_irq_parse_one+0x24c/0x270 parse_interrupts+0xc0/0x120 of_fwnode_add_links+0x100/0x2d0 fw_devlink_parse_fwtree+0x64/0xc0 device_add+0xb38/0xc30 of_device_add+0x64/0x90 of_platform_device_create_pdata+0xd0/0x170 of_platform_bus_create+0x244/0x600 of_platform_notify+0x1b0/0x254 blocking_notifier_call_chain+0x9c/0xd0 __of_changeset_entry_notify+0x1b8/0x230 __of_changeset_apply_notify+0x54/0xe4 of_overlay_fdt_apply+0xc04/0xd94 ...
The buggy address belongs to the object at ffffff81beca5600 which belongs to the cache kmalloc-128 of size 128 The buggy address is located 8 bytes inside of 128-byte region [ffffff81beca5600, ffffff81beca5680)
The buggy address belongs to the physical page: page:00000000230d3d03 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1beca4 head:00000000230d3d03 order:1 compound_mapcount:0 compound_pincount:0 flags: 0x8000000000010200(slab|head|zone=2) raw: 8000000000010200 0000000000000000 dead000000000122 ffffff810000c300 raw: 0000000000000000 0000000000200020 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected
Memory state around the buggy address: ffffff81beca5500: 04 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffffff81beca5580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffffff81beca5600: 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ^ ffffff81beca5680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffffff81beca5700: 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc ================================================================== OF: -> got it !
Prevent the out-of-bounds read by copying the device address into a buffer of sufficient size.(CVE-2024-46743)
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_reject_ipv6: fix nf_reject_ip6_tcphdr_put() syzbot reported that nf_reject_ip6_tcphdr_put() was possibly sending garbage on the four reserved tcp bits (th->res1) Use skb_put_zero() to clear the whole TCP header, as done in nf_reject_ip_tcphdr_put() BUG: KMSAN: uninit-value in nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255 nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255 nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344 nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core net/core/dev.c:5661 [inline] __netif_receive_skb+0x1da/0xa00 net/core/dev.c:5775 process_backlog+0x4ad/0xa50 net/core/dev.c:6108 __napi_poll+0xe7/0x980 net/core/dev.c:6772 napi_poll net/core/dev.c:6841 [inline] net_rx_action+0xa5a/0x19b0 net/core/dev.c:6963 handle_softirqs+0x1ce/0x800 kernel/softirq.c:554 __do_softirq+0x14/0x1a kernel/softirq.c:588 do_softirq+0x9a/0x100 kernel/softirq.c:455 __local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:382 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:908 [inline] __dev_queue_xmit+0x2692/0x5610 net/core/dev.c:4450 dev_queue_xmit include/linux/netdevice.h:3105 [inline] neigh_resolve_output+0x9ca/0xae0 net/core/neighbour.c:1565 neigh_output include/net/neighbour.h:542 [inline] ip6_finish_output2+0x2347/0x2ba0 net/ipv6/ip6_output.c:141 __ip6_finish_output net/ipv6/ip6_output.c:215 [inline] ip6_finish_output+0xbb8/0x14b0 net/ipv6/ip6_output.c:226 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip6_output+0x356/0x620 net/ipv6/ip6_output.c:247 dst_output include/net/dst.h:450 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] ip6_xmit+0x1ba6/0x25d0 net/ipv6/ip6_output.c:366 inet6_csk_xmit+0x442/0x530 net/ipv6/inet6_connection_sock.c:135 __tcp_transmit_skb+0x3b07/0x4880 net/ipv4/tcp_output.c:1466 tcp_transmit_skb net/ipv4/tcp_output.c:1484 [inline] tcp_connect+0x35b6/0x7130 net/ipv4/tcp_output.c:4143 tcp_v6_connect+0x1bcc/0x1e40 net/ipv6/tcp_ipv6.c:333 __inet_stream_connect+0x2ef/0x1730 net/ipv4/af_inet.c:679 inet_stream_connect+0x6a/0xd0 net/ipv4/af_inet.c:750 __sys_connect_file net/socket.c:2061 [inline] __sys_connect+0x606/0x690 net/socket.c:2078 __do_sys_connect net/socket.c:2088 [inline] __se_sys_connect net/socket.c:2085 [inline] __x64_sys_connect+0x91/0xe0 net/socket.c:2085 x64_sys_call+0x27a5/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:43 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit was stored to memory at: nf_reject_ip6_tcphdr_put+0x60c/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:249 nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344 nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core ---truncated---(CVE-2024-47685)
In the Linux kernel, the following vulnerability has been resolved: drivers: media: dvb-frontends/rtl2832: fix an out-of-bounds write error Ensure index in rtl2832_pid_filter does not exceed 31 to prevent out-of-bounds access. dev->filters is a 32-bit value, so set_bit and clear_bit functions should only operate on indices from 0 to 31. If index is 32, it will attempt to access a non-existent 33rd bit, leading to out-of-bounds access. Change the boundary check from index > 32 to index >= 32 to resolve this issue. hverkuil: added fixes tag, rtl2830_pid_filter -> rtl2832_pid_filter in logmsg
In the Linux kernel, the following vulnerability has been resolved: can: bcm: Clear bo->bcm_proc_read after remove_proc_entry(). syzbot reported a warning in bcm_release(). [0] The blamed change fixed another warning that is triggered when connect() is issued again for a socket whose connect()ed device has been unregistered. However, if the socket is just close()d without the 2nd connect(), the remaining bo->bcm_proc_read triggers unnecessary remove_proc_entry() in bcm_release(). Let's clear bo->bcm_proc_read after remove_proc_entry() in bcm_notify(). [0] name '4986' WARNING: CPU: 0 PID: 5234 at fs/proc/generic.c:711 remove_proc_entry+0x2e7/0x5d0 fs/proc/generic.c:711 Modules linked in: CPU: 0 UID: 0 PID: 5234 Comm: syz-executor606 Not tainted 6.11.0-rc5-syzkaller-00178-g5517ae241919 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:remove_proc_entry+0x2e7/0x5d0 fs/proc/generic.c:711 Code: ff eb 05 e8 cb 1e 5e ff 48 8b 5c 24 10 48 c7 c7 e0 f7 aa 8e e8 2a 38 8e 09 90 48 c7 c7 60 3a 1b 8c 48 89 de e8 da 42 20 ff 90 <0f> 0b 90 90 48 8b 44 24 18 48 c7 44 24 40 0e 36 e0 45 49 c7 04 07 RSP: 0018:ffffc9000345fa20 EFLAGS: 00010246 RAX: 2a2d0aee2eb64600 RBX: ffff888032f1f548 RCX: ffff888029431e00 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffc9000345fb08 R08: ffffffff8155b2f2 R09: 1ffff1101710519a R10: dffffc0000000000 R11: ffffed101710519b R12: ffff888011d38640 R13: 0000000000000004 R14: 0000000000000000 R15: dffffc0000000000 FS: 0000000000000000(0000) GS:ffff8880b8800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fcfb52722f0 CR3: 000000000e734000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> bcm_release+0x250/0x880 net/can/bcm.c:1578 __sock_release net/socket.c:659 [inline] sock_close+0xbc/0x240 net/socket.c:1421 __fput+0x24a/0x8a0 fs/file_table.c:422 task_work_run+0x24f/0x310 kernel/task_work.c:228 exit_task_work include/linux/task_work.h:40 [inline] do_exit+0xa2f/0x27f0 kernel/exit.c:882 do_group_exit+0x207/0x2c0 kernel/exit.c:1031 __do_sys_exit_group kernel/exit.c:1042 [inline] __se_sys_exit_group kernel/exit.c:1040 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1040 x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fcfb51ee969 Code: Unable to access opcode bytes at 0x7fcfb51ee93f. RSP: 002b:00007ffce0109ca8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007fcfb51ee969 RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000001 RBP: 00007fcfb526f3b0 R08: ffffffffffffffb8 R09: 0000555500000000 R10: 0000555500000000 R11: 0000000000000246 R12: 00007fcfb526f3b0 R13: 0000000000000000 R14: 00007fcfb5271ee0 R15: 00007fcfb51bf160 </TASK>(CVE-2024-47709)
In the Linux kernel, the following vulnerability has been resolved: nbd: fix race between timeout and normal completion If request timetout is handled by nbd_requeue_cmd(), normal completion has to be stopped for avoiding to complete this requeued request, other use-after-free can be triggered. Fix the race by clearing NBD_CMD_INFLIGHT in nbd_requeue_cmd(), meantime make sure that cmd->lock is grabbed for clearing the flag and the requeue.(CVE-2024-49855)
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in degamma hardware format translation Fixes index out of bounds issue in cm_helper_translate_curve_to_degamma_hw_format function. The issue could occur when the index 'i' exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure 'i' is within bounds before accessing the transfer function points. If 'i' is out of bounds the function returns false to indicate an error. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:594 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:595 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:596 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max(CVE-2024-49894)
In the Linux kernel, the following vulnerability has been resolved: jfs: Fix uninit-value access of new_ea in ea_buffer syzbot reports that lzo1x_1_do_compress is using uninit-value: ===================================================== BUG: KMSAN: uninit-value in lzo1x_1_do_compress+0x19f9/0x2510 lib/lzo/lzo1x_compress.c:178 ... Uninit was stored to memory at: ea_put fs/jfs/xattr.c:639 [inline] ... Local variable ea_buf created at: __jfs_setxattr+0x5d/0x1ae0 fs/jfs/xattr.c:662 __jfs_xattr_set+0xe6/0x1f0 fs/jfs/xattr.c:934 ===================================================== The reason is ea_buf->new_ea is not initialized properly. Fix this by using memset to empty its content at the beginning in ea_get().(CVE-2024-49900)
In the Linux kernel, the following vulnerability has been resolved: jbd2: stop waiting for space when jbd2_cleanup_journal_tail() returns error In __jbd2_log_wait_for_space(), we might call jbd2_cleanup_journal_tail() to recover some journal space. But if an error occurs while executing jbd2_cleanup_journal_tail() (e.g., an EIO), we don't stop waiting for free space right away, we try other branches, and if j_committing_transaction is NULL (i.e., the tid is 0), we will get the following complain: ============================================ JBD2: I/O error when updating journal superblock for sdd-8. __jbd2_log_wait_for_space: needed 256 blocks and only had 217 space available __jbd2_log_wait_for_space: no way to get more journal space in sdd-8 ------------[ cut here ]------------ WARNING: CPU: 2 PID: 139804 at fs/jbd2/checkpoint.c:109 __jbd2_log_wait_for_space+0x251/0x2e0 Modules linked in: CPU: 2 PID: 139804 Comm: kworker/u8:3 Not tainted 6.6.0+ #1 RIP: 0010:__jbd2_log_wait_for_space+0x251/0x2e0 Call Trace: <TASK> add_transaction_credits+0x5d1/0x5e0 start_this_handle+0x1ef/0x6a0 jbd2__journal_start+0x18b/0x340 ext4_dirty_inode+0x5d/0xb0 __mark_inode_dirty+0xe4/0x5d0 generic_update_time+0x60/0x70 [...] ============================================ So only if jbd2_cleanup_journal_tail() returns 1, i.e., there is nothing to clean up at the moment, continue to try to reclaim free space in other ways. Note that this fix relies on commit 6f6a6fda2945 ("jbd2: fix ocfs2 corrupt when updating journal superblock fails") to make jbd2_cleanup_journal_tail return the correct error code.(CVE-2024-49959)
In the Linux kernel, the following vulnerability has been resolved: net: do not delay dst_entries_add() in dst_release() dst_entries_add() uses per-cpu data that might be freed at netns dismantle from ip6_route_net_exit() calling dst_entries_destroy() Before ip6_route_net_exit() can be called, we release all the dsts associated with this netns, via calls to dst_release(), which waits an rcu grace period before calling dst_destroy() dst_entries_add() use in dst_destroy() is racy, because dst_entries_destroy() could have been called already. Decrementing the number of dsts must happen sooner. Notes: 1) in CONFIG_XFRM case, dst_destroy() can call dst_release_immediate(child), this might also cause UAF if the child does not have DST_NOCOUNT set. IPSEC maintainers might take a look and see how to address this. 2) There is also discussion about removing this count of dst, which might happen in future kernels.(CVE-2024-50036)
| URL | Type | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-4.19.90-2411.1.0.0301.oe2003sp4.aarch64.rpm",
"bpftool-debuginfo-4.19.90-2411.1.0.0301.oe2003sp4.aarch64.rpm",
"kernel-4.19.90-2411.1.0.0301.oe2003sp4.aarch64.rpm",
"kernel-debuginfo-4.19.90-2411.1.0.0301.oe2003sp4.aarch64.rpm",
"kernel-debugsource-4.19.90-2411.1.0.0301.oe2003sp4.aarch64.rpm",
"kernel-devel-4.19.90-2411.1.0.0301.oe2003sp4.aarch64.rpm",
"kernel-source-4.19.90-2411.1.0.0301.oe2003sp4.aarch64.rpm",
"kernel-tools-4.19.90-2411.1.0.0301.oe2003sp4.aarch64.rpm",
"kernel-tools-debuginfo-4.19.90-2411.1.0.0301.oe2003sp4.aarch64.rpm",
"kernel-tools-devel-4.19.90-2411.1.0.0301.oe2003sp4.aarch64.rpm",
"perf-4.19.90-2411.1.0.0301.oe2003sp4.aarch64.rpm",
"perf-debuginfo-4.19.90-2411.1.0.0301.oe2003sp4.aarch64.rpm",
"python2-perf-4.19.90-2411.1.0.0301.oe2003sp4.aarch64.rpm",
"python2-perf-debuginfo-4.19.90-2411.1.0.0301.oe2003sp4.aarch64.rpm",
"python3-perf-4.19.90-2411.1.0.0301.oe2003sp4.aarch64.rpm",
"python3-perf-debuginfo-4.19.90-2411.1.0.0301.oe2003sp4.aarch64.rpm"
],
"src": [
"kernel-4.19.90-2411.1.0.0301.oe2003sp4.src.rpm"
],
"x86_64": [
"bpftool-4.19.90-2411.1.0.0301.oe2003sp4.x86_64.rpm",
"bpftool-debuginfo-4.19.90-2411.1.0.0301.oe2003sp4.x86_64.rpm",
"kernel-4.19.90-2411.1.0.0301.oe2003sp4.x86_64.rpm",
"kernel-debuginfo-4.19.90-2411.1.0.0301.oe2003sp4.x86_64.rpm",
"kernel-debugsource-4.19.90-2411.1.0.0301.oe2003sp4.x86_64.rpm",
"kernel-devel-4.19.90-2411.1.0.0301.oe2003sp4.x86_64.rpm",
"kernel-source-4.19.90-2411.1.0.0301.oe2003sp4.x86_64.rpm",
"kernel-tools-4.19.90-2411.1.0.0301.oe2003sp4.x86_64.rpm",
"kernel-tools-debuginfo-4.19.90-2411.1.0.0301.oe2003sp4.x86_64.rpm",
"kernel-tools-devel-4.19.90-2411.1.0.0301.oe2003sp4.x86_64.rpm",
"perf-4.19.90-2411.1.0.0301.oe2003sp4.x86_64.rpm",
"perf-debuginfo-4.19.90-2411.1.0.0301.oe2003sp4.x86_64.rpm",
"python2-perf-4.19.90-2411.1.0.0301.oe2003sp4.x86_64.rpm",
"python2-perf-debuginfo-4.19.90-2411.1.0.0301.oe2003sp4.x86_64.rpm",
"python3-perf-4.19.90-2411.1.0.0301.oe2003sp4.x86_64.rpm",
"python3-perf-debuginfo-4.19.90-2411.1.0.0301.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-2411.1.0.0301.oe2003sp4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "Critical"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: udf: Fix preallocation discarding at indirect extent boundary When preallocation extent is the first one in the extent block, the code would corrupt extent tree header instead. Fix the problem and use udf_delete_aext() for deleting extent to avoid some code duplication.(CVE-2022-48946)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: NFC: nci: Bounds check struct nfc_target arrays While running under CONFIG_FORTIFY_SOURCE=y, syzkaller reported: memcpy: detected field-spanning write (size 129) of single field \u0026quot;target-\u0026gt;sensf_res\u0026quot; at net/nfc/nci/ntf.c:260 (size 18) This appears to be a legitimate lack of bounds checking in nci_add_new_protocol(). Add the missing checks.(CVE-2022-48967)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: gpio: amd8111: Fix PCI device reference count leak for_each_pci_dev() is implemented by pci_get_device(). The comment of pci_get_device() says that it will increase the reference count for the returned pci_dev and also decrease the reference count for the input pci_dev @from if it is not NULL. If we break for_each_pci_dev() loop with pdev not NULL, we need to call pci_dev_put() to decrease the reference count. Add the missing pci_dev_put() after the \u0026apos;out\u0026apos; label. Since pci_dev_put() can handle NULL input parameter, there is no problem for the \u0026apos;Device not found\u0026apos; branch. For the normal path, add pci_dev_put() in amd_gpio_exit().(CVE-2022-48973)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: ALSA: seq: Fix function prototype mismatch in snd_seq_expand_var_event With clang\u0026apos;s kernel control flow integrity (kCFI, CONFIG_CFI_CLANG), indirect call targets are validated against the expected function pointer prototype to make sure the call target is valid to help mitigate ROP attacks. If they are not identical, there is a failure at run time, which manifests as either a kernel panic or thread getting killed. seq_copy_in_user() and seq_copy_in_kernel() did not have prototypes matching snd_seq_dump_func_t. Adjust this and remove the casts. There are not resulting binary output differences. This was found as a result of Clang\u0026apos;s new -Wcast-function-type-strict flag, which is more sensitive than the simpler -Wcast-function-type, which only checks for type width mismatches.(CVE-2022-48994)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: nilfs2: fix NULL pointer dereference in nilfs_palloc_commit_free_entry() Syzbot reported a null-ptr-deref bug: NILFS (loop0): segctord starting. Construction interval = 5 seconds, CP frequency \u0026lt; 30 seconds general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] CPU: 1 PID: 3603 Comm: segctord Not tainted 6.1.0-rc2-syzkaller-00105-gb229b6ca5abb #0 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 10/11/2022 RIP: 0010:nilfs_palloc_commit_free_entry+0xe5/0x6b0 fs/nilfs2/alloc.c:608 Code: 00 00 00 00 fc ff df 80 3c 02 00 0f 85 cd 05 00 00 48 b8 00 00 00 00 00 fc ff df 4c 8b 73 08 49 8d 7e 10 48 89 fa 48 c1 ea 03 \u0026lt;80\u0026gt; 3c 02 00 0f 85 26 05 00 00 49 8b 46 10 be a6 00 00 00 48 c7 c7 RSP: 0018:ffffc90003dff830 EFLAGS: 00010212 RAX: dffffc0000000000 RBX: ffff88802594e218 RCX: 000000000000000d RDX: 0000000000000002 RSI: 0000000000002000 RDI: 0000000000000010 RBP: ffff888071880222 R08: 0000000000000005 R09: 000000000000003f R10: 000000000000000d R11: 0000000000000000 R12: ffff888071880158 R13: ffff88802594e220 R14: 0000000000000000 R15: 0000000000000004 FS: 0000000000000000(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fb1c08316a8 CR3: 0000000018560000 CR4: 0000000000350ee0 Call Trace: \u0026lt;TASK\u0026gt; nilfs_dat_commit_free fs/nilfs2/dat.c:114 [inline] nilfs_dat_commit_end+0x464/0x5f0 fs/nilfs2/dat.c:193 nilfs_dat_commit_update+0x26/0x40 fs/nilfs2/dat.c:236 nilfs_btree_commit_update_v+0x87/0x4a0 fs/nilfs2/btree.c:1940 nilfs_btree_commit_propagate_v fs/nilfs2/btree.c:2016 [inline] nilfs_btree_propagate_v fs/nilfs2/btree.c:2046 [inline] nilfs_btree_propagate+0xa00/0xd60 fs/nilfs2/btree.c:2088 nilfs_bmap_propagate+0x73/0x170 fs/nilfs2/bmap.c:337 nilfs_collect_file_data+0x45/0xd0 fs/nilfs2/segment.c:568 nilfs_segctor_apply_buffers+0x14a/0x470 fs/nilfs2/segment.c:1018 nilfs_segctor_scan_file+0x3f4/0x6f0 fs/nilfs2/segment.c:1067 nilfs_segctor_collect_blocks fs/nilfs2/segment.c:1197 [inline] nilfs_segctor_collect fs/nilfs2/segment.c:1503 [inline] nilfs_segctor_do_construct+0x12fc/0x6af0 fs/nilfs2/segment.c:2045 nilfs_segctor_construct+0x8e3/0xb30 fs/nilfs2/segment.c:2379 nilfs_segctor_thread_construct fs/nilfs2/segment.c:2487 [inline] nilfs_segctor_thread+0x3c3/0xf30 fs/nilfs2/segment.c:2570 kthread+0x2e4/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306 \u0026lt;/TASK\u0026gt; ... If DAT metadata file is corrupted on disk, there is a case where req-\u0026gt;pr_desc_bh is NULL and blocknr is 0 at nilfs_dat_commit_end() during a b-tree operation that cascadingly updates ancestor nodes of the b-tree, because nilfs_dat_commit_alloc() for a lower level block can initialize the blocknr on the same DAT entry between nilfs_dat_prepare_end() and nilfs_dat_commit_end(). If this happens, nilfs_dat_commit_end() calls nilfs_dat_commit_free() without valid buffer heads in req-\u0026gt;pr_desc_bh and req-\u0026gt;pr_bitmap_bh, and causes the NULL pointer dereference above in nilfs_palloc_commit_free_entry() function, which leads to a crash. Fix this by adding a NULL check on req-\u0026gt;pr_desc_bh and req-\u0026gt;pr_bitmap_bh before nilfs_palloc_commit_free_entry() in nilfs_dat_commit_free(). This also calls nilfs_error() in that case to notify that there is a fatal flaw in the filesystem metadata and prevent further operations.(CVE-2022-49007)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: hwmon: (coretemp) Check for null before removing sysfs attrs If coretemp_add_core() gets an error then pdata-\u0026gt;core_data[indx] is already NULL and has been kfreed. Don\u0026apos;t pass that to sysfs_remove_group() as that will crash in sysfs_remove_group(). [Shortened for readability] [91854.020159] sysfs: cannot create duplicate filename \u0026apos;/devices/platform/coretemp.0/hwmon/hwmon2/temp20_label\u0026apos; \u0026lt;cpu offline\u0026gt; [91855.126115] BUG: kernel NULL pointer dereference, address: 0000000000000188 [91855.165103] #PF: supervisor read access in kernel mode [91855.194506] #PF: error_code(0x0000) - not-present page [91855.224445] PGD 0 P4D 0 [91855.238508] Oops: 0000 [#1] PREEMPT SMP PTI ... [91855.342716] RIP: 0010:sysfs_remove_group+0xc/0x80 ... [91855.796571] Call Trace: [91855.810524] coretemp_cpu_offline+0x12b/0x1dd [coretemp] [91855.841738] ? coretemp_cpu_online+0x180/0x180 [coretemp] [91855.871107] cpuhp_invoke_callback+0x105/0x4b0 [91855.893432] cpuhp_thread_fun+0x8e/0x150 ... Fix this by checking for NULL first.(CVE-2022-49010)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: hwmon: (ibmpex) Fix possible UAF when ibmpex_register_bmc() fails Smatch report warning as follows: drivers/hwmon/ibmpex.c:509 ibmpex_register_bmc() warn: \u0026apos;\u0026amp;data-\u0026gt;list\u0026apos; not removed from list If ibmpex_find_sensors() fails in ibmpex_register_bmc(), data will be freed, but data-\u0026gt;list will not be removed from driver_data.bmc_data, then list traversal may cause UAF. Fix by removeing it from driver_data.bmc_data before free().(CVE-2022-49029)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: btrfs: qgroup: fix sleep from invalid context bug in btrfs_qgroup_inherit() Syzkaller reported BUG as follows: BUG: sleeping function called from invalid context at include/linux/sched/mm.h:274 Call Trace: \u0026lt;TASK\u0026gt; dump_stack_lvl+0xcd/0x134 __might_resched.cold+0x222/0x26b kmem_cache_alloc+0x2e7/0x3c0 update_qgroup_limit_item+0xe1/0x390 btrfs_qgroup_inherit+0x147b/0x1ee0 create_subvol+0x4eb/0x1710 btrfs_mksubvol+0xfe5/0x13f0 __btrfs_ioctl_snap_create+0x2b0/0x430 btrfs_ioctl_snap_create_v2+0x25a/0x520 btrfs_ioctl+0x2a1c/0x5ce0 __x64_sys_ioctl+0x193/0x200 do_syscall_64+0x35/0x80 Fix this by calling qgroup_dirty() on @dstqgroup, and update limit item in btrfs_run_qgroups() later outside of the spinlock context.(CVE-2022-49033)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: media: pci: cx23885: check cx23885_vdev_init() return cx23885_vdev_init() can return a NULL pointer, but that pointer is used in the next line without a check. Add a NULL pointer check and go to the error unwind if it is NULL.(CVE-2023-52918)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: nfc: nci: fix possible NULL pointer dereference in send_acknowledge() Handle memory allocation failure from nci_skb_alloc() (calling alloc_skb()) to avoid possible NULL pointer dereference.(CVE-2023-52919)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: dwc3: core: Prevent USB core invalid event buffer address access\r\n\r\nThis commit addresses an issue where the USB core could access an\ninvalid event buffer address during runtime suspend, potentially causing\nSMMU faults and other memory issues in Exynos platforms. The problem\narises from the following sequence.\n 1. In dwc3_gadget_suspend, there is a chance of a timeout when\n moving the USB core to the halt state after clearing the\n run/stop bit by software.\n 2. In dwc3_core_exit, the event buffer is cleared regardless of\n the USB core\u0026apos;s status, which may lead to an SMMU faults and\n other memory issues. if the USB core tries to access the event\n buffer address.\r\n\r\nTo prevent this hardware quirk on Exynos platforms, this commit ensures\nthat the event buffer address is not cleared by software when the USB\ncore is active during runtime suspend by checking its status before\nclearing the buffer address.(CVE-2024-46675)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ngtp: fix a potential NULL pointer dereference\r\n\r\nWhen sockfd_lookup() fails, gtp_encap_enable_socket() returns a\nNULL pointer, but its callers only check for error pointers thus miss\nthe NULL pointer case.\r\n\r\nFix it by returning an error pointer with the error code carried from\nsockfd_lookup().\r\n\r\n(I found this bug during code inspection.)(CVE-2024-46677)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npinctrl: single: fix potential NULL dereference in pcs_get_function()\r\n\r\npinmux_generic_get_function() can return NULL and the pointer \u0026apos;function\u0026apos;\nwas dereferenced without checking against NULL. Add checking of pointer\n\u0026apos;function\u0026apos; in pcs_get_function().\r\n\r\nFound by code review.(CVE-2024-46685)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: Fix out-of-bounds read of df_v1_7_channel_number\r\n\r\nCheck the fb_channel_number range to avoid the array out-of-bounds\nread error(CVE-2024-46724)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nof/irq: Prevent device address out-of-bounds read in interrupt map walk\r\n\r\nWhen of_irq_parse_raw() is invoked with a device address smaller than\nthe interrupt parent node (from #address-cells property), KASAN detects\nthe following out-of-bounds read when populating the initial match table\n(dyndbg=\u0026quot;func of_irq_parse_* +p\u0026quot;):\r\n\r\n OF: of_irq_parse_one: dev=/soc@0/picasso/watchdog, index=0\n OF: parent=/soc@0/pci@878000000000/gpio0@17,0, intsize=2\n OF: intspec=4\n OF: of_irq_parse_raw: ipar=/soc@0/pci@878000000000/gpio0@17,0, size=2\n OF: -\u0026gt; addrsize=3\n ==================================================================\n BUG: KASAN: slab-out-of-bounds in of_irq_parse_raw+0x2b8/0x8d0\n Read of size 4 at addr ffffff81beca5608 by task bash/764\r\n\r\n CPU: 1 PID: 764 Comm: bash Tainted: G O 6.1.67-484c613561-nokia_sm_arm64 #1\n Hardware name: Unknown Unknown Product/Unknown Product, BIOS 2023.01-12.24.03-dirty 01/01/2023\n Call trace:\n dump_backtrace+0xdc/0x130\n show_stack+0x1c/0x30\n dump_stack_lvl+0x6c/0x84\n print_report+0x150/0x448\n kasan_report+0x98/0x140\n __asan_load4+0x78/0xa0\n of_irq_parse_raw+0x2b8/0x8d0\n of_irq_parse_one+0x24c/0x270\n parse_interrupts+0xc0/0x120\n of_fwnode_add_links+0x100/0x2d0\n fw_devlink_parse_fwtree+0x64/0xc0\n device_add+0xb38/0xc30\n of_device_add+0x64/0x90\n of_platform_device_create_pdata+0xd0/0x170\n of_platform_bus_create+0x244/0x600\n of_platform_notify+0x1b0/0x254\n blocking_notifier_call_chain+0x9c/0xd0\n __of_changeset_entry_notify+0x1b8/0x230\n __of_changeset_apply_notify+0x54/0xe4\n of_overlay_fdt_apply+0xc04/0xd94\n ...\r\n\r\n The buggy address belongs to the object at ffffff81beca5600\n which belongs to the cache kmalloc-128 of size 128\n The buggy address is located 8 bytes inside of\n 128-byte region [ffffff81beca5600, ffffff81beca5680)\r\n\r\n The buggy address belongs to the physical page:\n page:00000000230d3d03 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1beca4\n head:00000000230d3d03 order:1 compound_mapcount:0 compound_pincount:0\n flags: 0x8000000000010200(slab|head|zone=2)\n raw: 8000000000010200 0000000000000000 dead000000000122 ffffff810000c300\n raw: 0000000000000000 0000000000200020 00000001ffffffff 0000000000000000\n page dumped because: kasan: bad access detected\r\n\r\n Memory state around the buggy address:\n ffffff81beca5500: 04 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc\n ffffff81beca5580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc\n \u0026gt;ffffff81beca5600: 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc\n ^\n ffffff81beca5680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc\n ffffff81beca5700: 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc\n ==================================================================\n OF: -\u0026gt; got it !\r\n\r\nPrevent the out-of-bounds read by copying the device address into a\nbuffer of sufficient size.(CVE-2024-46743)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: netfilter: nf_reject_ipv6: fix nf_reject_ip6_tcphdr_put() syzbot reported that nf_reject_ip6_tcphdr_put() was possibly sending garbage on the four reserved tcp bits (th-\u0026gt;res1) Use skb_put_zero() to clear the whole TCP header, as done in nf_reject_ip_tcphdr_put() BUG: KMSAN: uninit-value in nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255 nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255 nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344 nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core net/core/dev.c:5661 [inline] __netif_receive_skb+0x1da/0xa00 net/core/dev.c:5775 process_backlog+0x4ad/0xa50 net/core/dev.c:6108 __napi_poll+0xe7/0x980 net/core/dev.c:6772 napi_poll net/core/dev.c:6841 [inline] net_rx_action+0xa5a/0x19b0 net/core/dev.c:6963 handle_softirqs+0x1ce/0x800 kernel/softirq.c:554 __do_softirq+0x14/0x1a kernel/softirq.c:588 do_softirq+0x9a/0x100 kernel/softirq.c:455 __local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:382 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:908 [inline] __dev_queue_xmit+0x2692/0x5610 net/core/dev.c:4450 dev_queue_xmit include/linux/netdevice.h:3105 [inline] neigh_resolve_output+0x9ca/0xae0 net/core/neighbour.c:1565 neigh_output include/net/neighbour.h:542 [inline] ip6_finish_output2+0x2347/0x2ba0 net/ipv6/ip6_output.c:141 __ip6_finish_output net/ipv6/ip6_output.c:215 [inline] ip6_finish_output+0xbb8/0x14b0 net/ipv6/ip6_output.c:226 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip6_output+0x356/0x620 net/ipv6/ip6_output.c:247 dst_output include/net/dst.h:450 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] ip6_xmit+0x1ba6/0x25d0 net/ipv6/ip6_output.c:366 inet6_csk_xmit+0x442/0x530 net/ipv6/inet6_connection_sock.c:135 __tcp_transmit_skb+0x3b07/0x4880 net/ipv4/tcp_output.c:1466 tcp_transmit_skb net/ipv4/tcp_output.c:1484 [inline] tcp_connect+0x35b6/0x7130 net/ipv4/tcp_output.c:4143 tcp_v6_connect+0x1bcc/0x1e40 net/ipv6/tcp_ipv6.c:333 __inet_stream_connect+0x2ef/0x1730 net/ipv4/af_inet.c:679 inet_stream_connect+0x6a/0xd0 net/ipv4/af_inet.c:750 __sys_connect_file net/socket.c:2061 [inline] __sys_connect+0x606/0x690 net/socket.c:2078 __do_sys_connect net/socket.c:2088 [inline] __se_sys_connect net/socket.c:2085 [inline] __x64_sys_connect+0x91/0xe0 net/socket.c:2085 x64_sys_call+0x27a5/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:43 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit was stored to memory at: nf_reject_ip6_tcphdr_put+0x60c/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:249 nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344 nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core ---truncated---(CVE-2024-47685)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: drivers: media: dvb-frontends/rtl2832: fix an out-of-bounds write error Ensure index in rtl2832_pid_filter does not exceed 31 to prevent out-of-bounds access. dev-\u0026gt;filters is a 32-bit value, so set_bit and clear_bit functions should only operate on indices from 0 to 31. If index is 32, it will attempt to access a non-existent 33rd bit, leading to out-of-bounds access. Change the boundary check from index \u0026gt; 32 to index \u0026gt;= 32 to resolve this issue. [hverkuil: added fixes tag, rtl2830_pid_filter -\u0026gt; rtl2832_pid_filter in logmsg](CVE-2024-47698)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: can: bcm: Clear bo-\u0026gt;bcm_proc_read after remove_proc_entry(). syzbot reported a warning in bcm_release(). [0] The blamed change fixed another warning that is triggered when connect() is issued again for a socket whose connect()ed device has been unregistered. However, if the socket is just close()d without the 2nd connect(), the remaining bo-\u0026gt;bcm_proc_read triggers unnecessary remove_proc_entry() in bcm_release(). Let\u0026apos;s clear bo-\u0026gt;bcm_proc_read after remove_proc_entry() in bcm_notify(). [0] name \u0026apos;4986\u0026apos; WARNING: CPU: 0 PID: 5234 at fs/proc/generic.c:711 remove_proc_entry+0x2e7/0x5d0 fs/proc/generic.c:711 Modules linked in: CPU: 0 UID: 0 PID: 5234 Comm: syz-executor606 Not tainted 6.11.0-rc5-syzkaller-00178-g5517ae241919 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:remove_proc_entry+0x2e7/0x5d0 fs/proc/generic.c:711 Code: ff eb 05 e8 cb 1e 5e ff 48 8b 5c 24 10 48 c7 c7 e0 f7 aa 8e e8 2a 38 8e 09 90 48 c7 c7 60 3a 1b 8c 48 89 de e8 da 42 20 ff 90 \u0026lt;0f\u0026gt; 0b 90 90 48 8b 44 24 18 48 c7 44 24 40 0e 36 e0 45 49 c7 04 07 RSP: 0018:ffffc9000345fa20 EFLAGS: 00010246 RAX: 2a2d0aee2eb64600 RBX: ffff888032f1f548 RCX: ffff888029431e00 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffc9000345fb08 R08: ffffffff8155b2f2 R09: 1ffff1101710519a R10: dffffc0000000000 R11: ffffed101710519b R12: ffff888011d38640 R13: 0000000000000004 R14: 0000000000000000 R15: dffffc0000000000 FS: 0000000000000000(0000) GS:ffff8880b8800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fcfb52722f0 CR3: 000000000e734000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: \u0026lt;TASK\u0026gt; bcm_release+0x250/0x880 net/can/bcm.c:1578 __sock_release net/socket.c:659 [inline] sock_close+0xbc/0x240 net/socket.c:1421 __fput+0x24a/0x8a0 fs/file_table.c:422 task_work_run+0x24f/0x310 kernel/task_work.c:228 exit_task_work include/linux/task_work.h:40 [inline] do_exit+0xa2f/0x27f0 kernel/exit.c:882 do_group_exit+0x207/0x2c0 kernel/exit.c:1031 __do_sys_exit_group kernel/exit.c:1042 [inline] __se_sys_exit_group kernel/exit.c:1040 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1040 x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fcfb51ee969 Code: Unable to access opcode bytes at 0x7fcfb51ee93f. RSP: 002b:00007ffce0109ca8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007fcfb51ee969 RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000001 RBP: 00007fcfb526f3b0 R08: ffffffffffffffb8 R09: 0000555500000000 R10: 0000555500000000 R11: 0000000000000246 R12: 00007fcfb526f3b0 R13: 0000000000000000 R14: 00007fcfb5271ee0 R15: 00007fcfb51bf160 \u0026lt;/TASK\u0026gt;(CVE-2024-47709)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: nbd: fix race between timeout and normal completion If request timetout is handled by nbd_requeue_cmd(), normal completion has to be stopped for avoiding to complete this requeued request, other use-after-free can be triggered. Fix the race by clearing NBD_CMD_INFLIGHT in nbd_requeue_cmd(), meantime make sure that cmd-\u0026gt;lock is grabbed for clearing the flag and the requeue.(CVE-2024-49855)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in degamma hardware format translation Fixes index out of bounds issue in `cm_helper_translate_curve_to_degamma_hw_format` function. The issue could occur when the index \u0026apos;i\u0026apos; exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure \u0026apos;i\u0026apos; is within bounds before accessing the transfer function points. If \u0026apos;i\u0026apos; is out of bounds the function returns false to indicate an error. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:594 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.red\u0026apos; 1025 \u0026lt;= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:595 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.green\u0026apos; 1025 \u0026lt;= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:596 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.blue\u0026apos; 1025 \u0026lt;= s32max(CVE-2024-49894)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: jfs: Fix uninit-value access of new_ea in ea_buffer syzbot reports that lzo1x_1_do_compress is using uninit-value: ===================================================== BUG: KMSAN: uninit-value in lzo1x_1_do_compress+0x19f9/0x2510 lib/lzo/lzo1x_compress.c:178 ... Uninit was stored to memory at: ea_put fs/jfs/xattr.c:639 [inline] ... Local variable ea_buf created at: __jfs_setxattr+0x5d/0x1ae0 fs/jfs/xattr.c:662 __jfs_xattr_set+0xe6/0x1f0 fs/jfs/xattr.c:934 ===================================================== The reason is ea_buf-\u0026gt;new_ea is not initialized properly. Fix this by using memset to empty its content at the beginning in ea_get().(CVE-2024-49900)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: jbd2: stop waiting for space when jbd2_cleanup_journal_tail() returns error In __jbd2_log_wait_for_space(), we might call jbd2_cleanup_journal_tail() to recover some journal space. But if an error occurs while executing jbd2_cleanup_journal_tail() (e.g., an EIO), we don\u0026apos;t stop waiting for free space right away, we try other branches, and if j_committing_transaction is NULL (i.e., the tid is 0), we will get the following complain: ============================================ JBD2: I/O error when updating journal superblock for sdd-8. __jbd2_log_wait_for_space: needed 256 blocks and only had 217 space available __jbd2_log_wait_for_space: no way to get more journal space in sdd-8 ------------[ cut here ]------------ WARNING: CPU: 2 PID: 139804 at fs/jbd2/checkpoint.c:109 __jbd2_log_wait_for_space+0x251/0x2e0 Modules linked in: CPU: 2 PID: 139804 Comm: kworker/u8:3 Not tainted 6.6.0+ #1 RIP: 0010:__jbd2_log_wait_for_space+0x251/0x2e0 Call Trace: \u0026lt;TASK\u0026gt; add_transaction_credits+0x5d1/0x5e0 start_this_handle+0x1ef/0x6a0 jbd2__journal_start+0x18b/0x340 ext4_dirty_inode+0x5d/0xb0 __mark_inode_dirty+0xe4/0x5d0 generic_update_time+0x60/0x70 [...] ============================================ So only if jbd2_cleanup_journal_tail() returns 1, i.e., there is nothing to clean up at the moment, continue to try to reclaim free space in other ways. Note that this fix relies on commit 6f6a6fda2945 (\u0026quot;jbd2: fix ocfs2 corrupt when updating journal superblock fails\u0026quot;) to make jbd2_cleanup_journal_tail return the correct error code.(CVE-2024-49959)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: net: do not delay dst_entries_add() in dst_release() dst_entries_add() uses per-cpu data that might be freed at netns dismantle from ip6_route_net_exit() calling dst_entries_destroy() Before ip6_route_net_exit() can be called, we release all the dsts associated with this netns, via calls to dst_release(), which waits an rcu grace period before calling dst_destroy() dst_entries_add() use in dst_destroy() is racy, because dst_entries_destroy() could have been called already. Decrementing the number of dsts must happen sooner. Notes: 1) in CONFIG_XFRM case, dst_destroy() can call dst_release_immediate(child), this might also cause UAF if the child does not have DST_NOCOUNT set. IPSEC maintainers might take a look and see how to address this. 2) There is also discussion about removing this count of dst, which might happen in future kernels.(CVE-2024-50036)",
"id": "OESA-2024-2323",
"modified": "2026-08-06T11:07:48Z",
"published": "2024-11-01T11:07:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2323"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48946"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48967"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48973"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48994"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49007"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49010"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49029"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49033"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52918"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52919"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46675"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46677"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46685"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46724"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46743"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47685"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47698"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47709"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49855"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49894"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49900"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49959"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50036"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2022-48946",
"CVE-2022-48967",
"CVE-2022-48973",
"CVE-2022-48994",
"CVE-2022-49007",
"CVE-2022-49010",
"CVE-2022-49029",
"CVE-2022-49033",
"CVE-2023-52918",
"CVE-2023-52919",
"CVE-2024-46675",
"CVE-2024-46677",
"CVE-2024-46685",
"CVE-2024-46724",
"CVE-2024-46743",
"CVE-2024-47685",
"CVE-2024-47698",
"CVE-2024-47709",
"CVE-2024-49855",
"CVE-2024-49894",
"CVE-2024-49900",
"CVE-2024-49959",
"CVE-2024-50036"
]
}
OESA-2024-2324 (CVE-2022-48916)
Vulnerability from osv_openeuler – Published: 2024-11-01 11:07 – Updated: 2026-08-06 11:07 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
iommu/vt-d: Fix double list_add when enabling VMD in scalable mode
When enabling VMD and IOMMU scalable mode, the following kernel panic call trace/kernel log is shown in Eagle Stream platform (Sapphire Rapids CPU) during booting:
pci 0000:59:00.5: Adding to iommu group 42 ... vmd 0000:59:00.5: PCI host bridge to bus 10000:80 pci 10000:80:01.0: [8086:352a] type 01 class 0x060400 pci 10000:80:01.0: reg 0x10: [mem 0x00000000-0x0001ffff 64bit] pci 10000:80:01.0: enabling Extended Tags pci 10000:80:01.0: PME# supported from D0 D3hot D3cold pci 10000:80:01.0: DMAR: Setup RID2PASID failed pci 10000:80:01.0: Failed to add to iommu group 42: -16 pci 10000:80:03.0: [8086:352b] type 01 class 0x060400 pci 10000:80:03.0: reg 0x10: [mem 0x00000000-0x0001ffff 64bit] pci 10000:80:03.0: enabling Extended Tags pci 10000:80:03.0: PME# supported from D0 D3hot D3cold ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:29! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 7 Comm: kworker/0:1 Not tainted 5.17.0-rc3+ #7 Hardware name: Lenovo ThinkSystem SR650V3/SB27A86647, BIOS ESE101Y-1.00 01/13/2022 Workqueue: events work_for_cpu_fn RIP: 0010:__list_add_valid.cold+0x26/0x3f Code: 9a 4a ab ff 4c 89 c1 48 c7 c7 40 0c d9 9e e8 b9 b1 fe ff 0f 0b 48 89 f2 4c 89 c1 48 89 fe 48 c7 c7 f0 0c d9 9e e8 a2 b1 fe ff <0f> 0b 48 89 d1 4c 89 c6 4c 89 ca 48 c7 c7 98 0c d9 9e e8 8b b1 fe RSP: 0000:ff5ad434865b3a40 EFLAGS: 00010246 RAX: 0000000000000058 RBX: ff4d61160b74b880 RCX: ff4d61255e1fffa8 RDX: 0000000000000000 RSI: 00000000fffeffff RDI: ffffffff9fd34f20 RBP: ff4d611d8e245c00 R08: 0000000000000000 R09: ff5ad434865b3888 R10: ff5ad434865b3880 R11: ff4d61257fdc6fe8 R12: ff4d61160b74b8a0 R13: ff4d61160b74b8a0 R14: ff4d611d8e245c10 R15: ff4d611d8001ba70 FS: 0000000000000000(0000) GS:ff4d611d5ea00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ff4d611fa1401000 CR3: 0000000aa0210001 CR4: 0000000000771ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> intel_pasid_alloc_table+0x9c/0x1d0 dmar_insert_one_dev_info+0x423/0x540 ? device_to_iommu+0x12d/0x2f0 intel_iommu_attach_device+0x116/0x290 __iommu_attach_device+0x1a/0x90 iommu_group_add_device+0x190/0x2c0 __iommu_probe_device+0x13e/0x250 iommu_probe_device+0x24/0x150 iommu_bus_notifier+0x69/0x90 blocking_notifier_call_chain+0x5a/0x80 device_add+0x3db/0x7b0 ? arch_memremap_can_ram_remap+0x19/0x50 ? memremap+0x75/0x140 pci_device_add+0x193/0x1d0 pci_scan_single_device+0xb9/0xf0 pci_scan_slot+0x4c/0x110 pci_scan_child_bus_extend+0x3a/0x290 vmd_enable_domain.constprop.0+0x63e/0x820 vmd_probe+0x163/0x190 local_pci_probe+0x42/0x80 work_for_cpu_fn+0x13/0x20 process_one_work+0x1e2/0x3b0 worker_thread+0x1c4/0x3a0 ? rescuer_thread+0x370/0x370 kthread+0xc7/0xf0 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30 </TASK> Modules linked in: ---[ end trace 0000000000000000 ]--- ... Kernel panic - not syncing: Fatal exception Kernel Offset: 0x1ca00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) ---[ end Kernel panic - not syncing: Fatal exception ]---
The following 'lspci' output shows devices '10000:80:*' are subdevices of the VMD device 0000:59:00.5:
$ lspci ... 0000:59:00.5 RAID bus controller: Intel Corporation Volume Management Device NVMe RAID Controller (rev 20) ... 10000:80:01.0 PCI bridge: Intel Corporation Device 352a (rev 03) 10000:80:03.0 PCI bridge: Intel Corporation Device 352b (rev 03) 10000:80:05.0 PCI bridge: Intel Corporation Device 352c (rev 03) 10000:80:07.0 PCI bridge: Intel Corporation Device 352d (rev 03) 10000:81:00.0 Non-Volatile memory controller: Intel Corporation NVMe Datacenter SSD [3DNAND, Beta Rock Controller] 10000:82:00 ---truncated---(CVE-2022-48916)
In the Linux kernel, the following vulnerability has been resolved: udf: Fix preallocation discarding at indirect extent boundary When preallocation extent is the first one in the extent block, the code would corrupt extent tree header instead. Fix the problem and use udf_delete_aext() for deleting extent to avoid some code duplication.(CVE-2022-48946)
In the Linux kernel, the following vulnerability has been resolved: PCI: mt7621: Add sentinel to quirks table Current driver is missing a sentinel in the struct soc_device_attribute array, which causes an oops when assessed by the soc_device_match(mt7621_pcie_quirks_match) call. This was only exposed once the CONFIG_SOC_MT7621 mt7621 soc_dev_attr was fixed to register the SOC as a device, in: commit 7c18b64bba3b ("mips: ralink: mt7621: do not use kzalloc too early") Fix it by adding the required sentinel.(CVE-2022-48952)
In the Linux kernel, the following vulnerability has been resolved: NFC: nci: Bounds check struct nfc_target arrays While running under CONFIG_FORTIFY_SOURCE=y, syzkaller reported: memcpy: detected field-spanning write (size 129) of single field "target->sensf_res" at net/nfc/nci/ntf.c:260 (size 18) This appears to be a legitimate lack of bounds checking in nci_add_new_protocol(). Add the missing checks.(CVE-2022-48967)
In the Linux kernel, the following vulnerability has been resolved: gpio: amd8111: Fix PCI device reference count leak for_each_pci_dev() is implemented by pci_get_device(). The comment of pci_get_device() says that it will increase the reference count for the returned pci_dev and also decrease the reference count for the input pci_dev @from if it is not NULL. If we break for_each_pci_dev() loop with pdev not NULL, we need to call pci_dev_put() to decrease the reference count. Add the missing pci_dev_put() after the 'out' label. Since pci_dev_put() can handle NULL input parameter, there is no problem for the 'Device not found' branch. For the normal path, add pci_dev_put() in amd_gpio_exit().(CVE-2022-48973)
In the Linux kernel, the following vulnerability has been resolved: can: af_can: fix NULL pointer dereference in can_rcv_filter Analogue to commit 8aa59e355949 ("can: af_can: fix NULL pointer dereference in can_rx_register()") we need to check for a missing initialization of ml_priv in the receive path of CAN frames. Since commit 4e096a18867a ("net: introduce CAN specific pointer in the struct net_device") the check for dev->type to be ARPHRD_CAN is not sufficient anymore since bonding or tun netdevices claim to be CAN devices but do not initialize ml_priv accordingly.(CVE-2022-48977)
In the Linux kernel, the following vulnerability has been resolved: mm/gup: fix gup_pud_range() for dax For dax pud, pud_huge() returns true on x86. So the function works as long as hugetlb is configured. However, dax doesn't depend on hugetlb. Commit 414fd080d125 ("mm/gup: fix gup_pmd_range() for dax") fixed devmap-backed huge PMDs, but missed devmap-backed huge PUDs. Fix this as well. This fixes the below kernel panic: general protection fault, probably for non-canonical address 0x69e7c000cc478: 0000 [#1] SMP < snip > Call Trace: <TASK> get_user_pages_fast+0x1f/0x40 iov_iter_get_pages+0xc6/0x3b0 ? mempool_alloc+0x5d/0x170 bio_iov_iter_get_pages+0x82/0x4e0 ? bvec_alloc+0x91/0xc0 ? bio_alloc_bioset+0x19a/0x2a0 blkdev_direct_IO+0x282/0x480 ? __io_complete_rw_common+0xc0/0xc0 ? filemap_range_has_page+0x82/0xc0 generic_file_direct_write+0x9d/0x1a0 ? inode_update_time+0x24/0x30 __generic_file_write_iter+0xbd/0x1e0 blkdev_write_iter+0xb4/0x150 ? io_import_iovec+0x8d/0x340 io_write+0xf9/0x300 io_issue_sqe+0x3c3/0x1d30 ? sysvec_reschedule_ipi+0x6c/0x80 __io_queue_sqe+0x33/0x240 ? fget+0x76/0xa0 io_submit_sqes+0xe6a/0x18d0 ? __fget_light+0xd1/0x100 __x64_sys_io_uring_enter+0x199/0x880 ? __context_tracking_enter+0x1f/0x70 ? irqentry_exit_to_user_mode+0x24/0x30 ? irqentry_exit+0x1d/0x30 ? __context_tracking_exit+0xe/0x70 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x61/0xcb RIP: 0033:0x7fc97c11a7be < snip > </TASK> ---[ end trace 48b2e0e67debcaeb ]--- RIP: 0010:internal_get_user_pages_fast+0x340/0x990 < snip > Kernel panic - not syncing: Fatal exception Kernel Offset: disabled(CVE-2022-48986)
In the Linux kernel, the following vulnerability has been resolved: memcg: fix possible use-after-free in memcg_write_event_control() memcg_write_event_control() accesses the dentry->d_name of the specified control fd to route the write call. As a cgroup interface file can't be renamed, it's safe to access d_name as long as the specified file is a regular cgroup file. Also, as these cgroup interface files can't be removed before the directory, it's safe to access the parent too. Prior to 347c4a874710 ("memcg: remove cgroup_event->cft"), there was a call to __file_cft() which verified that the specified file is a regular cgroupfs file before further accesses. The cftype pointer returned from __file_cft() was no longer necessary and the commit inadvertently dropped the file type check with it allowing any file to slip through. With the invarients broken, the d_name and parent accesses can now race against renames and removals of arbitrary files and cause use-after-free's. Fix the bug by resurrecting the file type check in __file_cft(). Now that cgroupfs is implemented through kernfs, checking the file operations needs to go through a layer of indirection. Instead, let's check the superblock and dentry type.(CVE-2022-48988)
In the Linux kernel, the following vulnerability has been resolved: mm/khugepaged: invoke MMU notifiers in shmem/file collapse paths Any codepath that zaps page table entries must invoke MMU notifiers to ensure that secondary MMUs (like KVM) don't keep accessing pages which aren't mapped anymore. Secondary MMUs don't hold their own references to pages that are mirrored over, so failing to notify them can lead to page use-after-free. I'm marking this as addressing an issue introduced in commit f3f0e1d2150b ("khugepaged: add support of collapse for tmpfs/shmem pages"), but most of the security impact of this only came in commit 27e1f8273113 ("khugepaged: enable collapse pmd for pte-mapped THP"), which actually omitted flushes for the removal of present PTEs, not just for the removal of empty page tables.(CVE-2022-48991)
In the Linux kernel, the following vulnerability has been resolved: ALSA: seq: Fix function prototype mismatch in snd_seq_expand_var_event With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG), indirect call targets are validated against the expected function pointer prototype to make sure the call target is valid to help mitigate ROP attacks. If they are not identical, there is a failure at run time, which manifests as either a kernel panic or thread getting killed. seq_copy_in_user() and seq_copy_in_kernel() did not have prototypes matching snd_seq_dump_func_t. Adjust this and remove the casts. There are not resulting binary output differences. This was found as a result of Clang's new -Wcast-function-type-strict flag, which is more sensitive than the simpler -Wcast-function-type, which only checks for type width mismatches.(CVE-2022-48994)
In the Linux kernel, the following vulnerability has been resolved: tracing: Free buffers when a used dynamic event is removed(CVE-2022-49006)
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix NULL pointer dereference in nilfs_palloc_commit_free_entry() Syzbot reported a null-ptr-deref bug: NILFS (loop0): segctord starting. Construction interval = 5 seconds, CP frequency < 30 seconds general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] CPU: 1 PID: 3603 Comm: segctord Not tainted 6.1.0-rc2-syzkaller-00105-gb229b6ca5abb #0 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 10/11/2022 RIP: 0010:nilfs_palloc_commit_free_entry+0xe5/0x6b0 fs/nilfs2/alloc.c:608 Code: 00 00 00 00 fc ff df 80 3c 02 00 0f 85 cd 05 00 00 48 b8 00 00 00 00 00 fc ff df 4c 8b 73 08 49 8d 7e 10 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 26 05 00 00 49 8b 46 10 be a6 00 00 00 48 c7 c7 RSP: 0018:ffffc90003dff830 EFLAGS: 00010212 RAX: dffffc0000000000 RBX: ffff88802594e218 RCX: 000000000000000d RDX: 0000000000000002 RSI: 0000000000002000 RDI: 0000000000000010 RBP: ffff888071880222 R08: 0000000000000005 R09: 000000000000003f R10: 000000000000000d R11: 0000000000000000 R12: ffff888071880158 R13: ffff88802594e220 R14: 0000000000000000 R15: 0000000000000004 FS: 0000000000000000(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fb1c08316a8 CR3: 0000000018560000 CR4: 0000000000350ee0 Call Trace: <TASK> nilfs_dat_commit_free fs/nilfs2/dat.c:114 [inline] nilfs_dat_commit_end+0x464/0x5f0 fs/nilfs2/dat.c:193 nilfs_dat_commit_update+0x26/0x40 fs/nilfs2/dat.c:236 nilfs_btree_commit_update_v+0x87/0x4a0 fs/nilfs2/btree.c:1940 nilfs_btree_commit_propagate_v fs/nilfs2/btree.c:2016 [inline] nilfs_btree_propagate_v fs/nilfs2/btree.c:2046 [inline] nilfs_btree_propagate+0xa00/0xd60 fs/nilfs2/btree.c:2088 nilfs_bmap_propagate+0x73/0x170 fs/nilfs2/bmap.c:337 nilfs_collect_file_data+0x45/0xd0 fs/nilfs2/segment.c:568 nilfs_segctor_apply_buffers+0x14a/0x470 fs/nilfs2/segment.c:1018 nilfs_segctor_scan_file+0x3f4/0x6f0 fs/nilfs2/segment.c:1067 nilfs_segctor_collect_blocks fs/nilfs2/segment.c:1197 [inline] nilfs_segctor_collect fs/nilfs2/segment.c:1503 [inline] nilfs_segctor_do_construct+0x12fc/0x6af0 fs/nilfs2/segment.c:2045 nilfs_segctor_construct+0x8e3/0xb30 fs/nilfs2/segment.c:2379 nilfs_segctor_thread_construct fs/nilfs2/segment.c:2487 [inline] nilfs_segctor_thread+0x3c3/0xf30 fs/nilfs2/segment.c:2570 kthread+0x2e4/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306 </TASK> ... If DAT metadata file is corrupted on disk, there is a case where req->pr_desc_bh is NULL and blocknr is 0 at nilfs_dat_commit_end() during a b-tree operation that cascadingly updates ancestor nodes of the b-tree, because nilfs_dat_commit_alloc() for a lower level block can initialize the blocknr on the same DAT entry between nilfs_dat_prepare_end() and nilfs_dat_commit_end(). If this happens, nilfs_dat_commit_end() calls nilfs_dat_commit_free() without valid buffer heads in req->pr_desc_bh and req->pr_bitmap_bh, and causes the NULL pointer dereference above in nilfs_palloc_commit_free_entry() function, which leads to a crash. Fix this by adding a NULL check on req->pr_desc_bh and req->pr_bitmap_bh before nilfs_palloc_commit_free_entry() in nilfs_dat_commit_free(). This also calls nilfs_error() in that case to notify that there is a fatal flaw in the filesystem metadata and prevent further operations.(CVE-2022-49007)
In the Linux kernel, the following vulnerability has been resolved: net: ethernet: nixge: fix NULL dereference In function nixge_hw_dma_bd_release() dereference of NULL pointer priv->rx_bd_v is possible for the case of its allocation failure in nixge_hw_dma_bd_init(). Move for() loop with priv->rx_bd_v dereference under the check for its validity. Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2022-49019)
In the Linux kernel, the following vulnerability has been resolved: hwmon: (ibmpex) Fix possible UAF when ibmpex_register_bmc() fails Smatch report warning as follows: drivers/hwmon/ibmpex.c:509 ibmpex_register_bmc() warn: '&data->list' not removed from list If ibmpex_find_sensors() fails in ibmpex_register_bmc(), data will be freed, but data->list will not be removed from driver_data.bmc_data, then list traversal may cause UAF. Fix by removeing it from driver_data.bmc_data before free().(CVE-2022-49029)
In the Linux kernel, the following vulnerability has been resolved: libbpf: Handle size overflow for ringbuf mmap The maximum size of ringbuf is 2GB on x86-64 host, so 2 * max_entries will overflow u32 when mapping producer page and data pages. Only casting max_entries to size_t is not enough, because for 32-bits application on 64-bits kernel the size of read-only mmap region also could overflow size_t. So fixing it by casting the size of read-only mmap region into a __u64 and checking whether or not there will be overflow during mmap.(CVE-2022-49030)
In the Linux kernel, the following vulnerability has been resolved: btrfs: qgroup: fix sleep from invalid context bug in btrfs_qgroup_inherit() Syzkaller reported BUG as follows: BUG: sleeping function called from invalid context at include/linux/sched/mm.h:274 Call Trace: <TASK> dump_stack_lvl+0xcd/0x134 __might_resched.cold+0x222/0x26b kmem_cache_alloc+0x2e7/0x3c0 update_qgroup_limit_item+0xe1/0x390 btrfs_qgroup_inherit+0x147b/0x1ee0 create_subvol+0x4eb/0x1710 btrfs_mksubvol+0xfe5/0x13f0 __btrfs_ioctl_snap_create+0x2b0/0x430 btrfs_ioctl_snap_create_v2+0x25a/0x520 btrfs_ioctl+0x2a1c/0x5ce0 __x64_sys_ioctl+0x193/0x200 do_syscall_64+0x35/0x80 Fix this by calling qgroup_dirty() on @dstqgroup, and update limit item in btrfs_run_qgroups() later outside of the spinlock context.(CVE-2022-49033)
In the Linux kernel, the following vulnerability has been resolved:
media: imon: fix access to invalid resource for the second interface
imon driver probes two USB interfaces, and at the probe of the second interface, the driver assumes blindly that the first interface got bound with the same imon driver. It's usually true, but it's still possible that the first interface is bound with another driver via a malformed descriptor. Then it may lead to a memory corruption, as spotted by syzkaller; imon driver accesses the data from drvdata as struct imon_context object although it's a completely different one that was assigned by another driver.
This patch adds a sanity check -- whether the first interface is really bound with the imon driver or not -- for avoiding the problem above at the probe time.(CVE-2023-52754)
In the Linux kernel, the following vulnerability has been resolved:
usb: dwc2: fix possible NULL pointer dereference caused by driver concurrency
In _dwc2_hcd_urb_enqueue(), "urb->hcpriv = NULL" is executed without holding the lock "hsotg->lock". In _dwc2_hcd_urb_dequeue():
spin_lock_irqsave(&hsotg->lock, flags);
...
if (!urb->hcpriv) {
dev_dbg(hsotg->dev, "## urb->hcpriv is NULL ##\n");
goto out;
}
rc = dwc2_hcd_urb_dequeue(hsotg, urb->hcpriv); // Use urb->hcpriv
...
out: spin_unlock_irqrestore(&hsotg->lock, flags);
When _dwc2_hcd_urb_enqueue() and _dwc2_hcd_urb_dequeue() are concurrently executed, the NULL check of "urb->hcpriv" can be executed before "urb->hcpriv = NULL". After urb->hcpriv is NULL, it can be used in the function call to dwc2_hcd_urb_dequeue(), which can cause a NULL pointer dereference.
This possible bug is found by an experimental static analysis tool developed by myself. This tool analyzes the locking APIs to extract function pairs that can be concurrently executed, and then analyzes the instructions in the paired functions to identify possible concurrency bugs including data races and atomicity violations. The above possible bug is reported, when my tool analyzes the source code of Linux 6.5.
To fix this possible bug, "urb->hcpriv = NULL" should be executed with holding the lock "hsotg->lock". After using this patch, my tool never reports the possible bug, with the kernelconfiguration allyesconfig for x86_64. Because I have no associated hardware, I cannot test the patch in runtime testing, and just verify it according to the code logic.(CVE-2023-52855)
In the Linux kernel, the following vulnerability has been resolved: ntb: intel: Fix the NULL vs IS_ERR() bug for debugfs_create_dir() The debugfs_create_dir() function returns error pointers. It never returns NULL. So use IS_ERR() to check it.(CVE-2023-52917)
In the Linux kernel, the following vulnerability has been resolved: media: pci: cx23885: check cx23885_vdev_init() return cx23885_vdev_init() can return a NULL pointer, but that pointer is used in the next line without a check. Add a NULL pointer check and go to the error unwind if it is NULL.(CVE-2023-52918)
In the Linux kernel, the following vulnerability has been resolved: nfc: nci: fix possible NULL pointer dereference in send_acknowledge() Handle memory allocation failure from nci_skb_alloc() (calling alloc_skb()) to avoid possible NULL pointer dereference.(CVE-2023-52919)
In the Linux kernel, the following vulnerability has been resolved:
scsi: Revert "scsi: fcoe: Fix potential deadlock on &fip->ctlr_lock"
This reverts commit 1a1975551943f681772720f639ff42fbaa746212.
This commit causes interrupts to be lost for FCoE devices, since it changed sping locks from "bh" to "irqsave".
Instead, a work queue should be used, and will be addressed in a separate commit.(CVE-2024-26917)
In the Linux kernel, the following vulnerability has been resolved:
of: module: prevent NULL pointer dereference in vsnprintf()
In of_modalias(), we can get passed the str and len parameters which would cause a kernel oops in vsnprintf() since it only allows passing a NULL ptr when the length is also 0. Also, we need to filter out the negative values of the len parameter as these will result in a really huge buffer since snprintf() takes size_t parameter while ours is ssize_t...
Found by Linux Verification Center (linuxtesting.org) with the Svace static analysis tool.(CVE-2024-35878)
In the Linux kernel, the following vulnerability has been resolved:
dma: xilinx_dpdma: Fix locking
There are several places where either chan->lock or chan->vchan.lock was not held. Add appropriate locking. This fixes lockdep warnings like
[ 31.077578] ------------[ cut here ]------------ [ 31.077831] WARNING: CPU: 2 PID: 40 at drivers/dma/xilinx/xilinx_dpdma.c:834 xilinx_dpdma_chan_queue_transfer+0x274/0x5e0 [ 31.077953] Modules linked in: [ 31.078019] CPU: 2 PID: 40 Comm: kworker/u12:1 Not tainted 6.6.20+ #98 [ 31.078102] Hardware name: xlnx,zynqmp (DT) [ 31.078169] Workqueue: events_unbound deferred_probe_work_func [ 31.078272] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 31.078377] pc : xilinx_dpdma_chan_queue_transfer+0x274/0x5e0 [ 31.078473] lr : xilinx_dpdma_chan_queue_transfer+0x270/0x5e0 [ 31.078550] sp : ffffffc083bb2e10 [ 31.078590] x29: ffffffc083bb2e10 x28: 0000000000000000 x27: ffffff880165a168 [ 31.078754] x26: ffffff880164e920 x25: ffffff880164eab8 x24: ffffff880164d480 [ 31.078920] x23: ffffff880165a148 x22: ffffff880164e988 x21: 0000000000000000 [ 31.079132] x20: ffffffc082aa3000 x19: ffffff880164e880 x18: 0000000000000000 [ 31.079295] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 31.079453] x14: 0000000000000000 x13: ffffff8802263dc0 x12: 0000000000000001 [ 31.079613] x11: 0001ffc083bb2e34 x10: 0001ff880164e98f x9 : 0001ffc082aa3def [ 31.079824] x8 : 0001ffc082aa3dec x7 : 0000000000000000 x6 : 0000000000000516 [ 31.079982] x5 : ffffffc7f8d43000 x4 : ffffff88003c9c40 x3 : ffffffffffffffff [ 31.080147] x2 : ffffffc7f8d43000 x1 : 00000000000000c0 x0 : 0000000000000000 [ 31.080307] Call trace: [ 31.080340] xilinx_dpdma_chan_queue_transfer+0x274/0x5e0 [ 31.080518] xilinx_dpdma_issue_pending+0x11c/0x120 [ 31.080595] zynqmp_disp_layer_update+0x180/0x3ac [ 31.080712] zynqmp_dpsub_plane_atomic_update+0x11c/0x21c [ 31.080825] drm_atomic_helper_commit_planes+0x20c/0x684 [ 31.080951] drm_atomic_helper_commit_tail+0x5c/0xb0 [ 31.081139] commit_tail+0x234/0x294 [ 31.081246] drm_atomic_helper_commit+0x1f8/0x210 [ 31.081363] drm_atomic_commit+0x100/0x140 [ 31.081477] drm_client_modeset_commit_atomic+0x318/0x384 [ 31.081634] drm_client_modeset_commit_locked+0x8c/0x24c [ 31.081725] drm_client_modeset_commit+0x34/0x5c [ 31.081812] __drm_fb_helper_restore_fbdev_mode_unlocked+0x104/0x168 [ 31.081899] drm_fb_helper_set_par+0x50/0x70 [ 31.081971] fbcon_init+0x538/0xc48 [ 31.082047] visual_init+0x16c/0x23c [ 31.082207] do_bind_con_driver.isra.0+0x2d0/0x634 [ 31.082320] do_take_over_console+0x24c/0x33c [ 31.082429] do_fbcon_takeover+0xbc/0x1b0 [ 31.082503] fbcon_fb_registered+0x2d0/0x34c [ 31.082663] register_framebuffer+0x27c/0x38c [ 31.082767] __drm_fb_helper_initial_config_and_unlock+0x5c0/0x91c [ 31.082939] drm_fb_helper_initial_config+0x50/0x74 [ 31.083012] drm_fbdev_dma_client_hotplug+0xb8/0x108 [ 31.083115] drm_client_register+0xa0/0xf4 [ 31.083195] drm_fbdev_dma_setup+0xb0/0x1cc [ 31.083293] zynqmp_dpsub_drm_init+0x45c/0x4e0 [ 31.083431] zynqmp_dpsub_probe+0x444/0x5e0 [ 31.083616] platform_probe+0x8c/0x13c [ 31.083713] really_probe+0x258/0x59c [ 31.083793] __driver_probe_device+0xc4/0x224 [ 31.083878] driver_probe_device+0x70/0x1c0 [ 31.083961] __device_attach_driver+0x108/0x1e0 [ 31.084052] bus_for_each_drv+0x9c/0x100 [ 31.084125] __device_attach+0x100/0x298 [ 31.084207] device_initial_probe+0x14/0x20 [ 31.084292] bus_probe_device+0xd8/0xdc [ 31.084368] deferred_probe_work_func+0x11c/0x180 [ 31.084451] process_one_work+0x3ac/0x988 [ 31.084643] worker_thread+0x398/0x694 [ 31.084752] kthread+0x1bc/0x1c0 [ 31.084848] ret_from_fork+0x10/0x20 [ 31.084932] irq event stamp: 64549 [ 31.084970] hardirqs last enabled at (64548): [<ffffffc081adf35c>] _raw_spin_unlock_irqrestore+0x80/0x90 [ 31.085157] ---truncated---(CVE-2024-35990)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nfnetlink_queue: acquire rcu_read_lock() in instance_destroy_rcu()
syzbot reported that nf_reinject() could be called without rcu_read_lock() :
WARNING: suspicious RCU usage 6.9.0-rc7-syzkaller-02060-g5c1672705a1a #0 Not tainted
net/netfilter/nfnetlink_queue.c:263 suspicious rcu_dereference_check() usage!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 1 2 locks held by syz-executor.4/13427: #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_lock_acquire include/linux/rcupdate.h:329 [inline] #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_do_batch kernel/rcu/tree.c:2190 [inline] #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_core+0xa86/0x1830 kernel/rcu/tree.c:2471 #1: ffff88801ca92958 (&inst->lock){+.-.}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline] #1: ffff88801ca92958 (&inst->lock){+.-.}-{2:2}, at: nfqnl_flush net/netfilter/nfnetlink_queue.c:405 [inline] #1: ffff88801ca92958 (&inst->lock){+.-.}-{2:2}, at: instance_destroy_rcu+0x30/0x220 net/netfilter/nfnetlink_queue.c:172
stack backtrace: CPU: 0 PID: 13427 Comm: syz-executor.4 Not tainted 6.9.0-rc7-syzkaller-02060-g5c1672705a1a #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024 Call Trace: <IRQ> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 lockdep_rcu_suspicious+0x221/0x340 kernel/locking/lockdep.c:6712 nf_reinject net/netfilter/nfnetlink_queue.c:323 [inline] nfqnl_reinject+0x6ec/0x1120 net/netfilter/nfnetlink_queue.c:397 nfqnl_flush net/netfilter/nfnetlink_queue.c:410 [inline] instance_destroy_rcu+0x1ae/0x220 net/netfilter/nfnetlink_queue.c:172 rcu_do_batch kernel/rcu/tree.c:2196 [inline] rcu_core+0xafd/0x1830 kernel/rcu/tree.c:2471 handle_softirqs+0x2d6/0x990 kernel/softirq.c:554 __do_softirq kernel/softirq.c:588 [inline] invoke_softirq kernel/softirq.c:428 [inline] __irq_exit_rcu+0xf4/0x1c0 kernel/softirq.c:637 irq_exit_rcu+0x9/0x30 kernel/softirq.c:649 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1043 [inline] sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1043 </IRQ> <TASK>(CVE-2024-36286)
In the Linux kernel, the following vulnerability has been resolved:
soundwire: cadence: fix invalid PDI offset
For some reason, we add an offset to the PDI, presumably to skip the PDI0 and PDI1 which are reserved for BPT.
This code is however completely wrong and leads to an out-of-bounds access. We were just lucky so far since we used only a couple of PDIs and remained within the PDI array bounds.
A Fixes: tag is not provided since there are no known platforms where the out-of-bounds would be accessed, and the initial code had problems as well.
A follow-up patch completely removes this useless offset.(CVE-2024-38635)
In the Linux kernel, the following vulnerability has been resolved:
riscv: prevent pt_regs corruption for secondary idle threads
Top of the kernel thread stack should be reserved for pt_regs. However this is not the case for the idle threads of the secondary boot harts. Their stacks overlap with their pt_regs, so both may get corrupted.
Similar issue has been fixed for the primary hart, see c7cdd96eca28 ("riscv: prevent stack corruption by reserving task_pt_regs(p) early"). However that fix was not propagated to the secondary harts. The problem has been noticed in some CPU hotplug tests with V enabled. The function smp_callin stored several registers on stack, corrupting top of pt_regs structure including status field. As a result, kernel attempted to save or restore inexistent V context.(CVE-2024-38667)
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: add bounds checking to ocfs2_check_dir_entry()
This adds sanity checks for ocfs2_dir_entry to make sure all members of ocfs2_dir_entry don't stray beyond valid memory region.(CVE-2024-41015)
In the Linux kernel, the following vulnerability has been resolved:
nvmet: fix a possible leak when destroy a ctrl during qp establishment
In nvmet_sq_destroy we capture sq->ctrl early and if it is non-NULL we know that a ctrl was allocated (in the admin connect request handler) and we need to release pending AERs, clear ctrl->sqs and sq->ctrl (for nvme-loop primarily), and drop the final reference on the ctrl.
However, a small window is possible where nvmet_sq_destroy starts (as a result of the client giving up and disconnecting) concurrently with the nvme admin connect cmd (which may be in an early stage). But before kill_and_confirm of sq->ref (i.e. the admin connect managed to get an sq live reference). In this case, sq->ctrl was allocated however after it was captured in a local variable in nvmet_sq_destroy. This prevented the final reference drop on the ctrl.
Solve this by re-capturing the sq->ctrl after all inflight request has completed, where for sure sq->ctrl reference is final, and move forward based on that.
This issue was observed in an environment with many hosts connecting multiple ctrls simoutanuosly, creating a delay in allocating a ctrl leading up to this race window.(CVE-2024-42152)
In the Linux kernel, the following vulnerability has been resolved:
dev/parport: fix the array out-of-bounds risk
Fixed array out-of-bounds issues caused by sprintf by replacing it with snprintf for safer data copying, ensuring the destination buffer is not overflowed.
Below is the stack trace I encountered during the actual issue:
[ 66.575408s] [pid:5118,cpu4,QThread,4]Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: do_hardware_base_addr+0xcc/0xd0 [parport] [ 66.575408s] [pid:5118,cpu4,QThread,5]CPU: 4 PID: 5118 Comm: QThread Tainted: G S W O 5.10.97-arm64-desktop #7100.57021.2 [ 66.575439s] [pid:5118,cpu4,QThread,6]TGID: 5087 Comm: EFileApp [ 66.575439s] [pid:5118,cpu4,QThread,7]Hardware name: HUAWEI HUAWEI QingYun PGUX-W515x-B081/SP1PANGUXM, BIOS 1.00.07 04/29/2024 [ 66.575439s] [pid:5118,cpu4,QThread,8]Call trace: [ 66.575469s] [pid:5118,cpu4,QThread,9] dump_backtrace+0x0/0x1c0 [ 66.575469s] [pid:5118,cpu4,QThread,0] show_stack+0x14/0x20 [ 66.575469s] [pid:5118,cpu4,QThread,1] dump_stack+0xd4/0x10c [ 66.575500s] [pid:5118,cpu4,QThread,2] panic+0x1d8/0x3bc [ 66.575500s] [pid:5118,cpu4,QThread,3] __stack_chk_fail+0x2c/0x38 [ 66.575500s] [pid:5118,cpu4,QThread,4] do_hardware_base_addr+0xcc/0xd0 parport
In the Linux kernel, the following vulnerability has been resolved:
wifi: virt_wifi: avoid reporting connection success with wrong SSID
When user issues a connection with a different SSID than the one virt_wifi has advertised, the __cfg80211_connect_result() will trigger the warning: WARN_ON(bss_not_found).
The issue is because the connection code in virt_wifi does not check the SSID from user space (it only checks the BSSID), and virt_wifi will call cfg80211_connect_result() with WLAN_STATUS_SUCCESS even if the SSID is different from the one virt_wifi has advertised. Eventually cfg80211 won't be able to find the cfg80211_bss and generate the warning.
Fixed it by checking the SSID (from user space) in the connection code.(CVE-2024-43841)
In the Linux kernel, the following vulnerability has been resolved:
jfs: Fix array-index-out-of-bounds in diFree(CVE-2024-43858)
In the Linux kernel, the following vulnerability has been resolved:
drm/nouveau: prime: fix refcount underflow
Calling nouveau_bo_ref() on a nouveau_bo without initializing it (and hence the backing ttm_bo) leads to a refcount underflow.
Instead of calling nouveau_bo_ref() in the unwind path of drm_gem_object_init(), clean things up manually.
(cherry picked from commit 1b93f3e89d03cfc576636e195466a0d728ad8de5)(CVE-2024-43867)
In the Linux kernel, the following vulnerability has been resolved:
devres: Fix memory leakage caused by driver API devm_free_percpu()
It will cause memory leakage when use driver API devm_free_percpu() to free memory allocated by devm_alloc_percpu(), fixed by using devres_release() instead of devres_destroy() within devm_free_percpu().(CVE-2024-43871)
In the Linux kernel, the following vulnerability has been resolved:
drm/client: fix null pointer dereference in drm_client_modeset_probe
In drm_client_modeset_probe(), the return value of drm_mode_duplicate() is assigned to modeset->mode, which will lead to a possible NULL pointer dereference on failure of drm_mode_duplicate(). Add a check to avoid npd.(CVE-2024-43894)
In the Linux kernel, the following vulnerability has been resolved:
usb: dwc3: core: Prevent USB core invalid event buffer address access
This commit addresses an issue where the USB core could access an invalid event buffer address during runtime suspend, potentially causing SMMU faults and other memory issues in Exynos platforms. The problem arises from the following sequence. 1. In dwc3_gadget_suspend, there is a chance of a timeout when moving the USB core to the halt state after clearing the run/stop bit by software. 2. In dwc3_core_exit, the event buffer is cleared regardless of the USB core's status, which may lead to an SMMU faults and other memory issues. if the USB core tries to access the event buffer address.
To prevent this hardware quirk on Exynos platforms, this commit ensures that the event buffer address is not cleared by software when the USB core is active during runtime suspend by checking its status before clearing the buffer address.(CVE-2024-46675)
In the Linux kernel, the following vulnerability has been resolved:
soc: qcom: cmd-db: Map shared memory as WC, not WB
Linux does not write into cmd-db region. This region of memory is write protected by XPU. XPU may sometime falsely detect clean cache eviction as "write" into the write protected region leading to secure interrupt which causes an endless loop somewhere in Trust Zone.
The only reason it is working right now is because Qualcomm Hypervisor maps the same region as Non-Cacheable memory in Stage 2 translation tables. The issue manifests if we want to use another hypervisor (like Xen or KVM), which does not know anything about those specific mappings.
Changing the mapping of cmd-db memory from MEMREMAP_WB to MEMREMAP_WT/WC removes dependency on correct mappings in Stage 2 tables. This patch fixes the issue by updating the mapping to MEMREMAP_WC.
I tested this on SA8155P with Xen.(CVE-2024-46689)
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: fix mc_data out-of-bounds read warning
Clear warning that read mc_data[i-1] may out-of-bounds.(CVE-2024-46722)
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Fix out-of-bounds read of df_v1_7_channel_number
Check the fb_channel_number range to avoid the array out-of-bounds read error(CVE-2024-46724)
In the Linux kernel, the following vulnerability has been resolved:
hwmon: (nct6775-core) Fix underflows seen when writing limit attributes
DIV_ROUND_CLOSEST() after kstrtol() results in an underflow if a large negative number such as -9223372036854775808 is provided by the user. Fix it by reordering clamp_val() and DIV_ROUND_CLOSEST() operations.(CVE-2024-46757)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: added NULL check at start of dc_validate_stream
[Why] prevent invalid memory access
[How] check if dc and stream are NULL(CVE-2024-46802)
In the Linux kernel, the following vulnerability has been resolved:
KVM: x86: Acquire kvm->srcu when handling KVM_SET_VCPU_EVENTS
Grab kvm->srcu when processing KVM_SET_VCPU_EVENTS, as KVM will forcibly leave nested VMX/SVM if SMM mode is being toggled, and leaving nested VMX reads guest memory.
Note, kvm_vcpu_ioctl_x86_set_vcpu_events() can also be called from KVM_RUN via sync_regs(), which already holds SRCU. I.e. trying to precisely use kvm_vcpu_srcu_read_lock() around the problematic SMM code would cause problems. Acquiring SRCU isn't all that expensive, so for simplicity, grab it unconditionally for KVM_SET_VCPU_EVENTS.
============================= WARNING: suspicious RCU usage 6.10.0-rc7-332d2c1d713e-next-vm #552 Not tainted
include/linux/kvm_host.h:1027 suspicious rcu_dereference_check() usage!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 1 1 lock held by repro/1071: #0: ffff88811e424430 (&vcpu->mutex){+.+.}-{3:3}, at: kvm_vcpu_ioctl+0x7d/0x970 [kvm]
stack backtrace: CPU: 15 PID: 1071 Comm: repro Not tainted 6.10.0-rc7-332d2c1d713e-next-vm #552 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: <TASK> dump_stack_lvl+0x7f/0x90 lockdep_rcu_suspicious+0x13f/0x1a0 kvm_vcpu_gfn_to_memslot+0x168/0x190 [kvm] kvm_vcpu_read_guest+0x3e/0x90 [kvm] nested_vmx_load_msr+0x6b/0x1d0 [kvm_intel] load_vmcs12_host_state+0x432/0xb40 [kvm_intel] vmx_leave_nested+0x30/0x40 [kvm_intel] kvm_vcpu_ioctl_x86_set_vcpu_events+0x15d/0x2b0 [kvm] kvm_arch_vcpu_ioctl+0x1107/0x1750 [kvm] ? mark_held_locks+0x49/0x70 ? kvm_vcpu_ioctl+0x7d/0x970 [kvm] ? kvm_vcpu_ioctl+0x497/0x970 [kvm] kvm_vcpu_ioctl+0x497/0x970 [kvm] ? lock_acquire+0xba/0x2d0 ? find_held_lock+0x2b/0x80 ? do_user_addr_fault+0x40c/0x6f0 ? lock_release+0xb7/0x270 __x64_sys_ioctl+0x82/0xb0 do_syscall_64+0x6c/0x170 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7ff11eb1b539 </TASK>(CVE-2024-46830)
In the Linux kernel, the following vulnerability has been resolved:
spi: nxp-fspi: fix the KASAN report out-of-bounds bug
Change the memcpy length to fix the out-of-bounds issue when writing the data that is not 4 byte aligned to TX FIFO.
To reproduce the issue, write 3 bytes data to NOR chip.
dd if=3b of=/dev/mtd0 [ 36.926103] ================================================================== [ 36.933409] BUG: KASAN: slab-out-of-bounds in nxp_fspi_exec_op+0x26ec/0x2838 [ 36.940514] Read of size 4 at addr ffff00081037c2a0 by task dd/455 [ 36.946721] [ 36.948235] CPU: 3 UID: 0 PID: 455 Comm: dd Not tainted 6.11.0-rc5-gc7b0e37c8434 #1070 [ 36.956185] Hardware name: Freescale i.MX8QM MEK (DT) [ 36.961260] Call trace: [ 36.963723] dump_backtrace+0x90/0xe8 [ 36.967414] show_stack+0x18/0x24 [ 36.970749] dump_stack_lvl+0x78/0x90 [ 36.974451] print_report+0x114/0x5cc [ 36.978151] kasan_report+0xa4/0xf0 [ 36.981670] __asan_report_load_n_noabort+0x1c/0x28 [ 36.986587] nxp_fspi_exec_op+0x26ec/0x2838 [ 36.990800] spi_mem_exec_op+0x8ec/0xd30 [ 36.994762] spi_mem_no_dirmap_read+0x190/0x1e0 [ 36.999323] spi_mem_dirmap_write+0x238/0x32c [ 37.003710] spi_nor_write_data+0x220/0x374 [ 37.007932] spi_nor_write+0x110/0x2e8 [ 37.011711] mtd_write_oob_std+0x154/0x1f0 [ 37.015838] mtd_write_oob+0x104/0x1d0 [ 37.019617] mtd_write+0xb8/0x12c [ 37.022953] mtdchar_write+0x224/0x47c [ 37.026732] vfs_write+0x1e4/0x8c8 [ 37.030163] ksys_write+0xec/0x1d0 [ 37.033586] __arm64_sys_write+0x6c/0x9c [ 37.037539] invoke_syscall+0x6c/0x258 [ 37.041327] el0_svc_common.constprop.0+0x160/0x22c [ 37.046244] do_el0_svc+0x44/0x5c [ 37.049589] el0_svc+0x38/0x78 [ 37.052681] el0t_64_sync_handler+0x13c/0x158 [ 37.057077] el0t_64_sync+0x190/0x194 [ 37.060775] [ 37.062274] Allocated by task 455: [ 37.065701] kasan_save_stack+0x2c/0x54 [ 37.069570] kasan_save_track+0x20/0x3c [ 37.073438] kasan_save_alloc_info+0x40/0x54 [ 37.077736] __kasan_kmalloc+0xa0/0xb8 [ 37.081515] __kmalloc_noprof+0x158/0x2f8 [ 37.085563] mtd_kmalloc_up_to+0x120/0x154 [ 37.089690] mtdchar_write+0x130/0x47c [ 37.093469] vfs_write+0x1e4/0x8c8 [ 37.096901] ksys_write+0xec/0x1d0 [ 37.100332] __arm64_sys_write+0x6c/0x9c [ 37.104287] invoke_syscall+0x6c/0x258 [ 37.108064] el0_svc_common.constprop.0+0x160/0x22c [ 37.112972] do_el0_svc+0x44/0x5c [ 37.116319] el0_svc+0x38/0x78 [ 37.119401] el0t_64_sync_handler+0x13c/0x158 [ 37.123788] el0t_64_sync+0x190/0x194 [ 37.127474] [ 37.128977] The buggy address belongs to the object at ffff00081037c2a0 [ 37.128977] which belongs to the cache kmalloc-8 of size 8 [ 37.141177] The buggy address is located 0 bytes inside of [ 37.141177] allocated 3-byte region [ffff00081037c2a0, ffff00081037c2a3) [ 37.153465] [ 37.154971] The buggy address belongs to the physical page: [ 37.160559] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x89037c [ 37.168596] flags: 0xbfffe0000000000(node=0|zone=2|lastcpupid=0x1ffff) [ 37.175149] page_type: 0xfdffffff(slab) [ 37.179021] raw: 0bfffe0000000000 ffff000800002500 dead000000000122 0000000000000000 [ 37.186788] raw: 0000000000000000 0000000080800080 00000001fdffffff 0000000000000000 [ 37.194553] page dumped because: kasan: bad access detected [ 37.200144] [ 37.201647] Memory state around the buggy address: [ 37.206460] ffff00081037c180: fa fc fc fc fa fc fc fc fa fc fc fc fa fc fc fc [ 37.213701] ffff00081037c200: fa fc fc fc 05 fc fc fc 03 fc fc fc 02 fc fc fc [ 37.220946] >ffff00081037c280: 06 fc fc fc 03 fc fc fc fc fc fc fc fc fc fc fc [ 37.228186] ^ [ 37.232473] ffff00081037c300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 37.239718] ffff00081037c380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 37.246962] ============================================================== ---truncated---(CVE-2024-46853)
In the Linux kernel, the following vulnerability has been resolved:
PCI: keystone: Add workaround for Errata #i2037 (AM65x SR 1.0)
Errata #i2037 in AM65x/DRA80xM Processors Silicon Revision 1.0 (SPRZ452D_July 2018_Revised December 2019 [1]) mentions when an inbound PCIe TLP spans more than two internal AXI 128-byte bursts, the bus may corrupt the packet payload and the corrupt data may cause associated applications or the processor to hang.
The workaround for Errata #i2037 is to limit the maximum read request size and maximum payload size to 128 bytes. Add workaround for Errata #i2037 here.
The errata and workaround is applicable only to AM65x SR 1.0 and later versions of the silicon will have this fixed.
[1] -> https://www.ti.com/lit/er/sprz452i/sprz452i.pdf(CVE-2024-47667)
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix state management in error path of log writing function
After commit a694291a6211 ("nilfs2: separate wait function from nilfs_segctor_write") was applied, the log writing function nilfs_segctor_do_construct() was able to issue I/O requests continuously even if user data blocks were split into multiple logs across segments, but two potential flaws were introduced in its error handling.
First, if nilfs_segctor_begin_construction() fails while creating the second or subsequent logs, the log writing function returns without calling nilfs_segctor_abort_construction(), so the writeback flag set on pages/folios will remain uncleared. This causes page cache operations to hang waiting for the writeback flag. For example, truncate_inode_pages_final(), which is called via nilfs_evict_inode() when an inode is evicted from memory, will hang.
Second, the NILFS_I_COLLECTED flag set on normal inodes remain uncleared. As a result, if the next log write involves checkpoint creation, that's fine, but if a partial log write is performed that does not, inodes with NILFS_I_COLLECTED set are erroneously removed from the "sc_dirty_files" list, and their data and b-tree blocks may not be written to the device, corrupting the block mapping.
Fix these issues by uniformly calling nilfs_segctor_abort_construction() on failure of each step in the loop in nilfs_segctor_do_construct(), having it clean up logs and segment usages according to progress, and correcting the conditions for calling nilfs_redirty_inodes() to ensure that the NILFS_I_COLLECTED flag is cleared.(CVE-2024-47669)
In the Linux kernel, the following vulnerability has been resolved: tcp: check skb is non-NULL in tcp_rto_delta_us() We have some machines running stock Ubuntu 20.04.6 which is their 5.4.0-174-generic kernel that are running ceph and recently hit a null ptr dereference in tcp_rearm_rto(). Initially hitting it from the TLP path, but then later we also saw it getting hit from the RACK case as well. Here are examples of the oops messages we saw in each of those cases: Jul 26 15:05:02 rx [11061395.780353] BUG: kernel NULL pointer dereference, address: 0000000000000020 Jul 26 15:05:02 rx [11061395.787572] #PF: supervisor read access in kernel mode Jul 26 15:05:02 rx [11061395.792971] #PF: error_code(0x0000) - not-present page Jul 26 15:05:02 rx [11061395.798362] PGD 0 P4D 0 Jul 26 15:05:02 rx [11061395.801164] Oops: 0000 [#1] SMP NOPTI Jul 26 15:05:02 rx [11061395.805091] CPU: 0 PID: 9180 Comm: msgr-worker-1 Tainted: G W 5.4.0-174-generic #193-Ubuntu Jul 26 15:05:02 rx [11061395.814996] Hardware name: Supermicro SMC 2x26 os-gen8 64C NVME-Y 256G/H12SSW-NTR, BIOS 2.5.V1.2U.NVMe.UEFI 05/09/2023 Jul 26 15:05:02 rx [11061395.825952] RIP: 0010:tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.830656] Code: 87 ca 04 00 00 00 5b 41 5c 41 5d 5d c3 c3 49 8b bc 24 40 06 00 00 eb 8d 48 bb cf f7 53 e3 a5 9b c4 20 4c 89 ef e8 0c fe 0e 00 <48> 8b 78 20 48 c1 ef 03 48 89 f8 41 8b bc 24 80 04 00 00 48 f7 e3 Jul 26 15:05:02 rx [11061395.849665] RSP: 0018:ffffb75d40003e08 EFLAGS: 00010246 Jul 26 15:05:02 rx [11061395.855149] RAX: 0000000000000000 RBX: 20c49ba5e353f7cf RCX: 0000000000000000 Jul 26 15:05:02 rx [11061395.862542] RDX: 0000000062177c30 RSI: 000000000000231c RDI: ffff9874ad283a60 Jul 26 15:05:02 rx [11061395.869933] RBP: ffffb75d40003e20 R08: 0000000000000000 R09: ffff987605e20aa8 Jul 26 15:05:02 rx [11061395.877318] R10: ffffb75d40003f00 R11: ffffb75d4460f740 R12: ffff9874ad283900 Jul 26 15:05:02 rx [11061395.884710] R13: ffff9874ad283a60 R14: ffff9874ad283980 R15: ffff9874ad283d30 Jul 26 15:05:02 rx [11061395.892095] FS: 00007f1ef4a2e700(0000) GS:ffff987605e00000(0000) knlGS:0000000000000000 Jul 26 15:05:02 rx [11061395.900438] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Jul 26 15:05:02 rx [11061395.906435] CR2: 0000000000000020 CR3: 0000003e450ba003 CR4: 0000000000760ef0 Jul 26 15:05:02 rx [11061395.913822] PKRU: 55555554 Jul 26 15:05:02 rx [11061395.916786] Call Trace: Jul 26 15:05:02 rx [11061395.919488] Jul 26 15:05:02 rx [11061395.921765] ? show_regs.cold+0x1a/0x1f Jul 26 15:05:02 rx [11061395.925859] ? __die+0x90/0xd9 Jul 26 15:05:02 rx [11061395.929169] ? no_context+0x196/0x380 Jul 26 15:05:02 rx [11061395.933088] ? ip6_protocol_deliver_rcu+0x4e0/0x4e0 Jul 26 15:05:02 rx [11061395.938216] ? ip6_sublist_rcv_finish+0x3d/0x50 Jul 26 15:05:02 rx [11061395.943000] ? __bad_area_nosemaphore+0x50/0x1a0 Jul 26 15:05:02 rx [11061395.947873] ? bad_area_nosemaphore+0x16/0x20 Jul 26 15:05:02 rx [11061395.952486] ? do_user_addr_fault+0x267/0x450 Jul 26 15:05:02 rx [11061395.957104] ? ipv6_list_rcv+0x112/0x140 Jul 26 15:05:02 rx [11061395.961279] ? __do_page_fault+0x58/0x90 Jul 26 15:05:02 rx [11061395.965458] ? do_page_fault+0x2c/0xe0 Jul 26 15:05:02 rx [11061395.969465] ? page_fault+0x34/0x40 Jul 26 15:05:02 rx [11061395.973217] ? tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.977313] ? tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.981408] tcp_send_loss_probe+0x10b/0x220 Jul 26 15:05:02 rx [11061395.985937] tcp_write_timer_handler+0x1b4/0x240 Jul 26 15:05:02 rx [11061395.990809] tcp_write_timer+0x9e/0xe0 Jul 26 15:05:02 rx [11061395.994814] ? tcp_write_timer_handler+0x240/0x240 Jul 26 15:05:02 rx [11061395.999866] call_timer_fn+0x32/0x130 Jul 26 15:05:02 rx [11061396.003782] __run_timers.part.0+0x180/0x280 Jul 26 15:05:02 rx [11061396.008309] ? recalibrate_cpu_khz+0x10/0x10 Jul 26 15:05:02 rx [11061396.012841] ? native_x2apic_icr_write+0x30/0x30 Jul 26 15:05:02 rx [11061396.017718] ? lapic_next_even ---truncated---(CVE-2024-47684)
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_reject_ipv6: fix nf_reject_ip6_tcphdr_put() syzbot reported that nf_reject_ip6_tcphdr_put() was possibly sending garbage on the four reserved tcp bits (th->res1) Use skb_put_zero() to clear the whole TCP header, as done in nf_reject_ip_tcphdr_put() BUG: KMSAN: uninit-value in nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255 nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255 nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344 nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core net/core/dev.c:5661 [inline] __netif_receive_skb+0x1da/0xa00 net/core/dev.c:5775 process_backlog+0x4ad/0xa50 net/core/dev.c:6108 __napi_poll+0xe7/0x980 net/core/dev.c:6772 napi_poll net/core/dev.c:6841 [inline] net_rx_action+0xa5a/0x19b0 net/core/dev.c:6963 handle_softirqs+0x1ce/0x800 kernel/softirq.c:554 __do_softirq+0x14/0x1a kernel/softirq.c:588 do_softirq+0x9a/0x100 kernel/softirq.c:455 __local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:382 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:908 [inline] __dev_queue_xmit+0x2692/0x5610 net/core/dev.c:4450 dev_queue_xmit include/linux/netdevice.h:3105 [inline] neigh_resolve_output+0x9ca/0xae0 net/core/neighbour.c:1565 neigh_output include/net/neighbour.h:542 [inline] ip6_finish_output2+0x2347/0x2ba0 net/ipv6/ip6_output.c:141 __ip6_finish_output net/ipv6/ip6_output.c:215 [inline] ip6_finish_output+0xbb8/0x14b0 net/ipv6/ip6_output.c:226 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip6_output+0x356/0x620 net/ipv6/ip6_output.c:247 dst_output include/net/dst.h:450 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] ip6_xmit+0x1ba6/0x25d0 net/ipv6/ip6_output.c:366 inet6_csk_xmit+0x442/0x530 net/ipv6/inet6_connection_sock.c:135 __tcp_transmit_skb+0x3b07/0x4880 net/ipv4/tcp_output.c:1466 tcp_transmit_skb net/ipv4/tcp_output.c:1484 [inline] tcp_connect+0x35b6/0x7130 net/ipv4/tcp_output.c:4143 tcp_v6_connect+0x1bcc/0x1e40 net/ipv6/tcp_ipv6.c:333 __inet_stream_connect+0x2ef/0x1730 net/ipv4/af_inet.c:679 inet_stream_connect+0x6a/0xd0 net/ipv4/af_inet.c:750 __sys_connect_file net/socket.c:2061 [inline] __sys_connect+0x606/0x690 net/socket.c:2078 __do_sys_connect net/socket.c:2088 [inline] __se_sys_connect net/socket.c:2085 [inline] __x64_sys_connect+0x91/0xe0 net/socket.c:2085 x64_sys_call+0x27a5/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:43 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit was stored to memory at: nf_reject_ip6_tcphdr_put+0x60c/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:249 nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344 nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core ---truncated---(CVE-2024-47685)
In the Linux kernel, the following vulnerability has been resolved: RDMA/rtrs-clt: Reset cid to con_num - 1 to stay in bounds In the function init_conns(), after the create_con() and create_cm() for loop if something fails. In the cleanup for loop after the destroy tag, we access out of bound memory because cid is set to clt_path->s.con_num. This commits resets the cid to clt_path->s.con_num - 1, to stay in bounds in the cleanup loop later.(CVE-2024-47695)
In the Linux kernel, the following vulnerability has been resolved: drivers: media: dvb-frontends/rtl2832: fix an out-of-bounds write error Ensure index in rtl2832_pid_filter does not exceed 31 to prevent out-of-bounds access. dev->filters is a 32-bit value, so set_bit and clear_bit functions should only operate on indices from 0 to 31. If index is 32, it will attempt to access a non-existent 33rd bit, leading to out-of-bounds access. Change the boundary check from index > 32 to index >= 32 to resolve this issue. hverkuil: added fixes tag, rtl2830_pid_filter -> rtl2832_pid_filter in logmsg
In the Linux kernel, the following vulnerability has been resolved: can: bcm: Clear bo->bcm_proc_read after remove_proc_entry(). syzbot reported a warning in bcm_release(). [0] The blamed change fixed another warning that is triggered when connect() is issued again for a socket whose connect()ed device has been unregistered. However, if the socket is just close()d without the 2nd connect(), the remaining bo->bcm_proc_read triggers unnecessary remove_proc_entry() in bcm_release(). Let's clear bo->bcm_proc_read after remove_proc_entry() in bcm_notify(). [0] name '4986' WARNING: CPU: 0 PID: 5234 at fs/proc/generic.c:711 remove_proc_entry+0x2e7/0x5d0 fs/proc/generic.c:711 Modules linked in: CPU: 0 UID: 0 PID: 5234 Comm: syz-executor606 Not tainted 6.11.0-rc5-syzkaller-00178-g5517ae241919 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:remove_proc_entry+0x2e7/0x5d0 fs/proc/generic.c:711 Code: ff eb 05 e8 cb 1e 5e ff 48 8b 5c 24 10 48 c7 c7 e0 f7 aa 8e e8 2a 38 8e 09 90 48 c7 c7 60 3a 1b 8c 48 89 de e8 da 42 20 ff 90 <0f> 0b 90 90 48 8b 44 24 18 48 c7 44 24 40 0e 36 e0 45 49 c7 04 07 RSP: 0018:ffffc9000345fa20 EFLAGS: 00010246 RAX: 2a2d0aee2eb64600 RBX: ffff888032f1f548 RCX: ffff888029431e00 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffc9000345fb08 R08: ffffffff8155b2f2 R09: 1ffff1101710519a R10: dffffc0000000000 R11: ffffed101710519b R12: ffff888011d38640 R13: 0000000000000004 R14: 0000000000000000 R15: dffffc0000000000 FS: 0000000000000000(0000) GS:ffff8880b8800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fcfb52722f0 CR3: 000000000e734000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> bcm_release+0x250/0x880 net/can/bcm.c:1578 __sock_release net/socket.c:659 [inline] sock_close+0xbc/0x240 net/socket.c:1421 __fput+0x24a/0x8a0 fs/file_table.c:422 task_work_run+0x24f/0x310 kernel/task_work.c:228 exit_task_work include/linux/task_work.h:40 [inline] do_exit+0xa2f/0x27f0 kernel/exit.c:882 do_group_exit+0x207/0x2c0 kernel/exit.c:1031 __do_sys_exit_group kernel/exit.c:1042 [inline] __se_sys_exit_group kernel/exit.c:1040 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1040 x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fcfb51ee969 Code: Unable to access opcode bytes at 0x7fcfb51ee93f. RSP: 002b:00007ffce0109ca8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007fcfb51ee969 RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000001 RBP: 00007fcfb526f3b0 R08: ffffffffffffffb8 R09: 0000555500000000 R10: 0000555500000000 R11: 0000000000000246 R12: 00007fcfb526f3b0 R13: 0000000000000000 R14: 00007fcfb5271ee0 R15: 00007fcfb51bf160 </TASK>(CVE-2024-47709)
In the Linux kernel, the following vulnerability has been resolved: sock_map: Add a cond_resched() in sock_hash_free() Several syzbot soft lockup reports all have in common sock_hash_free() If a map with a large number of buckets is destroyed, we need to yield the cpu when needed.(CVE-2024-47710)
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for set_output_gamma in dcn30_set_output_transfer_func This commit adds a null check for the set_output_gamma function pointer in the dcn30_set_output_transfer_func function. Previously, set_output_gamma was being checked for nullity at line 386, but then it was being dereferenced without any nullity check at line 401. This could potentially lead to a null pointer dereference error if set_output_gamma is indeed null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a nullity check for set_output_gamma before the call to set_output_gamma at line 401. If set_output_gamma is null, we log an error message and do not call the function. This fix prevents a potential null pointer dereference error. drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:401 dcn30_set_output_transfer_func() error: we previously assumed 'mpc->funcs->set_output_gamma' could be null (see line 386) drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c 373 bool dcn30_set_output_transfer_func(struct dc dc, 374 struct pipe_ctx pipe_ctx, 375 const struct dc_stream_state stream) 376 { 377 int mpcc_id = pipe_ctx->plane_res.hubp->inst; 378 struct mpc mpc = pipe_ctx->stream_res.opp->ctx->dc->res_pool->mpc; 379 const struct pwl_params params = NULL; 380 bool ret = false; 381 382 / program OGAM or 3DLUT only for the top pipe/ 383 if (pipe_ctx->top_pipe == NULL) { 384 /program rmu shaper and 3dlut in MPC/ 385 ret = dcn30_set_mpc_shaper_3dlut(pipe_ctx, stream); 386 if (ret == false && mpc->funcs->set_output_gamma) { ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ If this is NULL 387 if (stream->out_transfer_func.type == TF_TYPE_HWPWL) 388 params = &stream->out_transfer_func.pwl; 389 else if (pipe_ctx->stream->out_transfer_func.type == 390 TF_TYPE_DISTRIBUTED_POINTS && 391 cm3_helper_translate_curve_to_hw_format( 392 &stream->out_transfer_func, 393 &mpc->blender_params, false)) 394 params = &mpc->blender_params; 395 / there are no ROM LUTs in OUTGAM */ 396 if (stream->out_transfer_func.type == TF_TYPE_PREDEFINED) 397 BREAK_TO_DEBUGGER(); 398 } 399 } 400 --> 401 mpc->funcs->set_output_gamma(mpc, mpcc_id, params); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Then it will crash 402 return ret; 403 }(CVE-2024-47720)
In the Linux kernel, the following vulnerability has been resolved: nfsd: call cache_put if xdr_reserve_space returns NULL If not enough buffer space available, but idmap_lookup has triggered lookup_fn which calls cache_get and returns successfully. Then we missed to call cache_put here which pairs with cache_get. Reviwed-by: Jeff Layton <jlayton@kernel.org>(CVE-2024-47737)
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential oob read in nilfs_btree_check_delete() The function nilfs_btree_check_delete(), which checks whether degeneration to direct mapping occurs before deleting a b-tree entry, causes memory access outside the block buffer when retrieving the maximum key if the root node has no entries. This does not usually happen because b-tree mappings with 0 child nodes are never created by mkfs.nilfs2 or nilfs2 itself. However, it can happen if the b-tree root node read from a device is configured that way, so fix this potential issue by adding a check for that case.(CVE-2024-47757)
In the Linux kernel, the following vulnerability has been resolved: tracing/timerlat: Fix a race during cpuhp processing There is another found exception that the "timerlat/1" thread was scheduled on CPU0, and lead to timer corruption finally: ODEBUG: init active (active state 0) object: ffff888237c2e108 object type: hrtimer hint: timerlat_irq+0x0/0x220 WARNING: CPU: 0 PID: 426 at lib/debugobjects.c:518 debug_print_object+0x7d/0xb0 Modules linked in: CPU: 0 UID: 0 PID: 426 Comm: timerlat/1 Not tainted 6.11.0-rc7+ #45 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:debug_print_object+0x7d/0xb0 ... Call Trace: <TASK> ? __warn+0x7c/0x110 ? debug_print_object+0x7d/0xb0 ? report_bug+0xf1/0x1d0 ? prb_read_valid+0x17/0x20 ? handle_bug+0x3f/0x70 ? exc_invalid_op+0x13/0x60 ? asm_exc_invalid_op+0x16/0x20 ? debug_print_object+0x7d/0xb0 ? debug_print_object+0x7d/0xb0 ? __pfx_timerlat_irq+0x10/0x10 __debug_object_init+0x110/0x150 hrtimer_init+0x1d/0x60 timerlat_main+0xab/0x2d0 ? __pfx_timerlat_main+0x10/0x10 kthread+0xb7/0xe0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> After tracing the scheduling event, it was discovered that the migration of the "timerlat/1" thread was performed during thread creation. Further analysis confirmed that it is because the CPU online processing for osnoise is implemented through workers, which is asynchronous with the offline processing. When the worker was scheduled to create a thread, the CPU may has already been removed from the cpu_online_mask during the offline process, resulting in the inability to select the right CPU: T1 | T2 [CPUHP_ONLINE] | cpu_device_down() osnoise_hotplug_workfn() | | cpus_write_lock() | takedown_cpu(1) | cpus_write_unlock() [CPUHP_OFFLINE] | cpus_read_lock() | start_kthread(1) | cpus_read_unlock() | To fix this, skip online processing if the CPU is already offline.(CVE-2024-49866)
In the Linux kernel, the following vulnerability has been resolved: btrfs: wait for fixup workers before stopping cleaner kthread during umount During unmount, at close_ctree(), we have the following steps in this order: 1) Park the cleaner kthread - this doesn't destroy the kthread, it basically halts its execution (wake ups against it work but do nothing); 2) We stop the cleaner kthread - this results in freeing the respective struct task_struct; 3) We call btrfs_stop_all_workers() which waits for any jobs running in all the work queues and then free the work queues. Syzbot reported a case where a fixup worker resulted in a crash when doing a delayed iput on its inode while attempting to wake up the cleaner at btrfs_add_delayed_iput(), because the task_struct of the cleaner kthread was already freed. This can happen during unmount because we don't wait for any fixup workers still running before we call kthread_stop() against the cleaner kthread, which stops and free all its resources. Fix this by waiting for any fixup workers at close_ctree() before we call kthread_stop() against the cleaner and run pending delayed iputs. The stack traces reported by syzbot were the following: BUG: KASAN: slab-use-after-free in __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065 Read of size 8 at addr ffff8880272a8a18 by task kworker/u8:3/52 CPU: 1 UID: 0 PID: 52 Comm: kworker/u8:3 Not tainted 6.12.0-rc1-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Workqueue: btrfs-fixup btrfs_work_helper Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0xd5/0x120 kernel/locking/spinlock.c:162 class_raw_spinlock_irqsave_constructor include/linux/spinlock.h:551 [inline] try_to_wake_up+0xb0/0x1480 kernel/sched/core.c:4154 btrfs_writepage_fixup_worker+0xc16/0xdf0 fs/btrfs/inode.c:2842 btrfs_work_helper+0x390/0xc50 fs/btrfs/async-thread.c:314 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa63/0x1850 kernel/workqueue.c:3310 worker_thread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 </TASK> Allocated by task 2: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:319 [inline] __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:345 kasan_slab_alloc include/linux/kasan.h:247 [inline] slab_post_alloc_hook mm/slub.c:4086 [inline] slab_alloc_node mm/slub.c:4135 [inline] kmem_cache_alloc_node_noprof+0x16b/0x320 mm/slub.c:4187 alloc_task_struct_node kernel/fork.c:180 [inline] dup_task_struct+0x57/0x8c0 kernel/fork.c:1107 copy_process+0x5d1/0x3d50 kernel/fork.c:2206 kernel_clone+0x223/0x880 kernel/fork.c:2787 kernel_thread+0x1bc/0x240 kernel/fork.c:2849 create_kthread kernel/kthread.c:412 [inline] kthreadd+0x60d/0x810 kernel/kthread.c:765 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Freed by task 61: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:230 [inline] slab_free_h ---truncated---(CVE-2024-49867)
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix a NULL pointer dereference when failed to start a new trasacntion [BUG] Syzbot reported a NULL pointer dereference with the following crash: FAULT_INJECTION: forcing a failure. start_transaction+0x830/0x1670 fs/btrfs/transaction.c:676 prepare_to_relocate+0x31f/0x4c0 fs/btrfs/relocation.c:3642 relocate_block_group+0x169/0xd20 fs/btrfs/relocation.c:3678 ... BTRFS info (device loop0): balance: ended with status: -12 Oops: general protection fault, probably for non-canonical address 0xdffffc00000000cc: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000660-0x0000000000000667] RIP: 0010:btrfs_update_reloc_root+0x362/0xa80 fs/btrfs/relocation.c:926 Call Trace: <TASK> commit_fs_roots+0x2ee/0x720 fs/btrfs/transaction.c:1496 btrfs_commit_transaction+0xfaf/0x3740 fs/btrfs/transaction.c:2430 del_balance_item fs/btrfs/volumes.c:3678 [inline] reset_balance_state+0x25e/0x3c0 fs/btrfs/volumes.c:3742 btrfs_balance+0xead/0x10c0 fs/btrfs/volumes.c:4574 btrfs_ioctl_balance+0x493/0x7c0 fs/btrfs/ioctl.c:3673 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f [CAUSE] The allocation failure happens at the start_transaction() inside prepare_to_relocate(), and during the error handling we call unset_reloc_control(), which makes fs_info->balance_ctl to be NULL. Then we continue the error path cleanup in btrfs_balance() by calling reset_balance_state() which will call del_balance_item() to fully delete the balance item in the root tree. However during the small window between set_reloc_contrl() and unset_reloc_control(), we can have a subvolume tree update and created a reloc_root for that subvolume. Then we go into the final btrfs_commit_transaction() of del_balance_item(), and into btrfs_update_reloc_root() inside commit_fs_roots(). That function checks if fs_info->reloc_ctl is in the merge_reloc_tree stage, but since fs_info->reloc_ctl is NULL, it results a NULL pointer dereference. [FIX] Just add extra check on fs_info->reloc_ctl inside btrfs_update_reloc_root(), before checking fs_info->reloc_ctl->merge_reloc_tree. That DEAD_RELOC_TREE handling is to prevent further modification to the reloc tree during merge stage, but since there is no reloc_ctl at all, we do not need to bother that.(CVE-2024-49868)
In the Linux kernel, the following vulnerability has been resolved: nfsd: map the EBADMSG to nfserr_io to avoid warning Ext4 will throw -EBADMSG through ext4_readdir when a checksum error occurs, resulting in the following WARNING. Fix it by mapping EBADMSG to nfserr_io. nfsd_buffered_readdir iterate_dir // -EBADMSG -74 ext4_readdir // .iterate_shared ext4_dx_readdir ext4_htree_fill_tree htree_dirblock_to_tree ext4_read_dirblock __ext4_read_dirblock ext4_dirblock_csum_verify warn_no_space_for_csum __warn_no_space_for_csum return ERR_PTR(-EFSBADCRC) // -EBADMSG -74 nfserrno // WARNING [ 161.115610] ------------[ cut here ]------------ [ 161.116465] nfsd: non-standard errno: -74 [ 161.117315] WARNING: CPU: 1 PID: 780 at fs/nfsd/nfsproc.c:878 nfserrno+0x9d/0xd0 [ 161.118596] Modules linked in: [ 161.119243] CPU: 1 PID: 780 Comm: nfsd Not tainted 5.10.0-00014-g79679361fd5d #138 [ 161.120684] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qe mu.org 04/01/2014 [ 161.123601] RIP: 0010:nfserrno+0x9d/0xd0 [ 161.124676] Code: 0f 87 da 30 dd 00 83 e3 01 b8 00 00 00 05 75 d7 44 89 ee 48 c7 c7 c0 57 24 98 89 44 24 04 c6 05 ce 2b 61 03 01 e8 99 20 d8 00 <0f> 0b 8b 44 24 04 eb b5 4c 89 e6 48 c7 c7 a0 6d a4 99 e8 cc 15 33 [ 161.127797] RSP: 0018:ffffc90000e2f9c0 EFLAGS: 00010286 [ 161.128794] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 161.130089] RDX: 1ffff1103ee16f6d RSI: 0000000000000008 RDI: fffff520001c5f2a [ 161.131379] RBP: 0000000000000022 R08: 0000000000000001 R09: ffff8881f70c1827 [ 161.132664] R10: ffffed103ee18304 R11: 0000000000000001 R12: 0000000000000021 [ 161.133949] R13: 00000000ffffffb6 R14: ffff8881317c0000 R15: ffffc90000e2fbd8 [ 161.135244] FS: 0000000000000000(0000) GS:ffff8881f7080000(0000) knlGS:0000000000000000 [ 161.136695] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 161.137761] CR2: 00007fcaad70b348 CR3: 0000000144256006 CR4: 0000000000770ee0 [ 161.139041] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 161.140291] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 161.141519] PKRU: 55555554 [ 161.142076] Call Trace: [ 161.142575] ? __warn+0x9b/0x140 [ 161.143229] ? nfserrno+0x9d/0xd0 [ 161.143872] ? report_bug+0x125/0x150 [ 161.144595] ? handle_bug+0x41/0x90 [ 161.145284] ? exc_invalid_op+0x14/0x70 [ 161.146009] ? asm_exc_invalid_op+0x12/0x20 [ 161.146816] ? nfserrno+0x9d/0xd0 [ 161.147487] nfsd_buffered_readdir+0x28b/0x2b0 [ 161.148333] ? nfsd4_encode_dirent_fattr+0x380/0x380 [ 161.149258] ? nfsd_buffered_filldir+0xf0/0xf0 [ 161.150093] ? wait_for_concurrent_writes+0x170/0x170 [ 161.151004] ? generic_file_llseek_size+0x48/0x160 [ 161.151895] nfsd_readdir+0x132/0x190 [ 161.152606] ? nfsd4_encode_dirent_fattr+0x380/0x380 [ 161.153516] ? nfsd_unlink+0x380/0x380 [ 161.154256] ? override_creds+0x45/0x60 [ 161.155006] nfsd4_encode_readdir+0x21a/0x3d0 [ 161.155850] ? nfsd4_encode_readlink+0x210/0x210 [ 161.156731] ? write_bytes_to_xdr_buf+0x97/0xe0 [ 161.157598] ? __write_bytes_to_xdr_buf+0xd0/0xd0 [ 161.158494] ? lock_downgrade+0x90/0x90 [ 161.159232] ? nfs4svc_decode_voidarg+0x10/0x10 [ 161.160092] nfsd4_encode_operation+0x15a/0x440 [ 161.160959] nfsd4_proc_compound+0x718/0xe90 [ 161.161818] nfsd_dispatch+0x18e/0x2c0 [ 161.162586] svc_process_common+0x786/0xc50 [ 161.163403] ? nfsd_svc+0x380/0x380 [ 161.164137] ? svc_printk+0x160/0x160 [ 161.164846] ? svc_xprt_do_enqueue.part.0+0x365/0x380 [ 161.165808] ? nfsd_svc+0x380/0x380 [ 161.166523] ? rcu_is_watching+0x23/0x40 [ 161.167309] svc_process+0x1a5/0x200 [ 161.168019] nfsd+0x1f5/0x380 [ 161.168663] ? nfsd_shutdown_threads+0x260/0x260 [ 161.169554] kthread+0x1c4/0x210 [ 161.170224] ? kthread_insert_work_sanity_check+0x80/0x80 [ 161.171246] ret_from_fork+0x1f/0x30(CVE-2024-49875)
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in degamma hardware format translation Fixes index out of bounds issue in cm_helper_translate_curve_to_degamma_hw_format function. The issue could occur when the index 'i' exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure 'i' is within bounds before accessing the transfer function points. If 'i' is out of bounds the function returns false to indicate an error. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:594 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:595 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:596 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max(CVE-2024-49894)
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in DCN30 degamma hardware format translation This commit addresses a potential index out of bounds issue in the cm3_helper_translate_curve_to_degamma_hw_format function in the DCN30 color management module. The issue could occur when the index 'i' exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure 'i' is within bounds before accessing the transfer function points. If 'i' is out of bounds, the function returns false to indicate an error. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:338 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:339 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:340 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max(CVE-2024-49895)
In the Linux kernel, the following vulnerability has been resolved: jfs: Fix uninit-value access of new_ea in ea_buffer syzbot reports that lzo1x_1_do_compress is using uninit-value: ===================================================== BUG: KMSAN: uninit-value in lzo1x_1_do_compress+0x19f9/0x2510 lib/lzo/lzo1x_compress.c:178 ... Uninit was stored to memory at: ea_put fs/jfs/xattr.c:639 [inline] ... Local variable ea_buf created at: __jfs_setxattr+0x5d/0x1ae0 fs/jfs/xattr.c:662 __jfs_xattr_set+0xe6/0x1f0 fs/jfs/xattr.c:934 ===================================================== The reason is ea_buf->new_ea is not initialized properly. Fix this by using memset to empty its content at the beginning in ea_get().(CVE-2024-49900)
In the Linux kernel, the following vulnerability has been resolved: jfs: check if leafidx greater than num leaves per dmap tree syzbot report a out of bounds in dbSplit, it because dmt_leafidx greater than num leaves per dmap tree, add a checking for dmt_leafidx in dbFindLeaf. Shaggy: Modified sanity check to apply to control pages as well as leaf pages.(CVE-2024-49902)
In the Linux kernel, the following vulnerability has been resolved: jfs: Fix uaf in dbFreeBits [syzbot reported] ================================================================== BUG: KASAN: slab-use-after-free in __mutex_lock_common kernel/locking/mutex.c:587 [inline] BUG: KASAN: slab-use-after-free in __mutex_lock+0xfe/0xd70 kernel/locking/mutex.c:752 Read of size 8 at addr ffff8880229254b0 by task syz-executor357/5216 CPU: 0 UID: 0 PID: 5216 Comm: syz-executor357 Not tainted 6.11.0-rc3-syzkaller-00156-gd7a5aa4b3c00 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 __mutex_lock_common kernel/locking/mutex.c:587 [inline] __mutex_lock+0xfe/0xd70 kernel/locking/mutex.c:752 dbFreeBits+0x7ea/0xd90 fs/jfs/jfs_dmap.c:2390 dbFreeDmap fs/jfs/jfs_dmap.c:2089 [inline] dbFree+0x35b/0x680 fs/jfs/jfs_dmap.c:409 dbDiscardAG+0x8a9/0xa20 fs/jfs/jfs_dmap.c:1650 jfs_ioc_trim+0x433/0x670 fs/jfs/jfs_discard.c:100 jfs_ioctl+0x2d0/0x3e0 fs/jfs/ioctl.c:131 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 Freed by task 5218: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579 poison_slab_object+0xe0/0x150 mm/kasan/common.c:240 __kasan_slab_free+0x37/0x60 mm/kasan/common.c:256 kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2252 [inline] slab_free mm/slub.c:4473 [inline] kfree+0x149/0x360 mm/slub.c:4594 dbUnmount+0x11d/0x190 fs/jfs/jfs_dmap.c:278 jfs_mount_rw+0x4ac/0x6a0 fs/jfs/jfs_mount.c:247 jfs_remount+0x3d1/0x6b0 fs/jfs/super.c:454 reconfigure_super+0x445/0x880 fs/super.c:1083 vfs_cmd_reconfigure fs/fsopen.c:263 [inline] vfs_fsconfig_locked fs/fsopen.c:292 [inline] __do_sys_fsconfig fs/fsopen.c:473 [inline] __se_sys_fsconfig+0xb6e/0xf80 fs/fsopen.c:345 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f [Analysis] There are two paths (dbUnmount and jfs_ioc_trim) that generate race condition when accessing bmap, which leads to the occurrence of uaf. Use the lock s_umount to synchronize them, in order to avoid uaf caused by race condition.(CVE-2024-49903)
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for function pointer in dcn20_set_output_transfer_func This commit adds a null check for the set_output_gamma function pointer in the dcn20_set_output_transfer_func function. Previously, set_output_gamma was being checked for null at line 1030, but then it was being dereferenced without any null check at line 1048. This could potentially lead to a null pointer dereference error if set_output_gamma is null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a null check for set_output_gamma before the call to set_output_gamma at line 1048.(CVE-2024-49911)
In the Linux kernel, the following vulnerability has been resolved: x86/ioapic: Handle allocation failures gracefully Breno observed panics when using failslab under certain conditions during runtime: can not alloc irq_pin_list (-1,0,20) Kernel panic - not syncing: IO-APIC: failed to add irq-pin. Can not proceed panic+0x4e9/0x590 mp_irqdomain_alloc+0x9ab/0xa80 irq_domain_alloc_irqs_locked+0x25d/0x8d0 __irq_domain_alloc_irqs+0x80/0x110 mp_map_pin_to_irq+0x645/0x890 acpi_register_gsi_ioapic+0xe6/0x150 hpet_open+0x313/0x480 That's a pointless panic which is a leftover of the historic IO/APIC code which panic'ed during early boot when the interrupt allocation failed. The only place which might justify panic is the PIT/HPET timer_check() code which tries to figure out whether the timer interrupt is delivered through the IO/APIC. But that code does not require to handle interrupt allocation failures. If the interrupt cannot be allocated then timer delivery fails and it either panics due to that or falls back to legacy mode. Cure this by removing the panic wrapper around __add_pin_to_irq_node() and making mp_irqdomain_alloc() aware of the failure condition and handle it as any other failure in this function gracefully.(CVE-2024-49927)
In the Linux kernel, the following vulnerability has been resolved: jbd2: stop waiting for space when jbd2_cleanup_journal_tail() returns error In __jbd2_log_wait_for_space(), we might call jbd2_cleanup_journal_tail() to recover some journal space. But if an error occurs while executing jbd2_cleanup_journal_tail() (e.g., an EIO), we don't stop waiting for free space right away, we try other branches, and if j_committing_transaction is NULL (i.e., the tid is 0), we will get the following complain: ============================================ JBD2: I/O error when updating journal superblock for sdd-8. __jbd2_log_wait_for_space: needed 256 blocks and only had 217 space available __jbd2_log_wait_for_space: no way to get more journal space in sdd-8 ------------[ cut here ]------------ WARNING: CPU: 2 PID: 139804 at fs/jbd2/checkpoint.c:109 __jbd2_log_wait_for_space+0x251/0x2e0 Modules linked in: CPU: 2 PID: 139804 Comm: kworker/u8:3 Not tainted 6.6.0+ #1 RIP: 0010:__jbd2_log_wait_for_space+0x251/0x2e0 Call Trace: <TASK> add_transaction_credits+0x5d1/0x5e0 start_this_handle+0x1ef/0x6a0 jbd2__journal_start+0x18b/0x340 ext4_dirty_inode+0x5d/0xb0 __mark_inode_dirty+0xe4/0x5d0 generic_update_time+0x60/0x70 [...] ============================================ So only if jbd2_cleanup_journal_tail() returns 1, i.e., there is nothing to clean up at the moment, continue to try to reclaim free space in other ways. Note that this fix relies on commit 6f6a6fda2945 ("jbd2: fix ocfs2 corrupt when updating journal superblock fails") to make jbd2_cleanup_journal_tail return the correct error code.(CVE-2024-49959)
In the Linux kernel, the following vulnerability has been resolved: ocfs2: cancel dqi_sync_work before freeing oinfo ocfs2_global_read_info() will initialize and schedule dqi_sync_work at the end, if error occurs after successfully reading global quota, it will trigger the following warning with CONFIG_DEBUG_OBJECTS_* enabled: ODEBUG: free active (active state 0) object: 00000000d8b0ce28 object type: timer_list hint: qsync_work_fn+0x0/0x16c This reports that there is an active delayed work when freeing oinfo in error handling, so cancel dqi_sync_work first. BTW, return status instead of -1 when .read_file_info fails.(CVE-2024-49966)
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in DCN30 color transformation This commit addresses a potential index out of bounds issue in the cm3_helper_translate_curve_to_hw_format function in the DCN30 color management module. The issue could occur when the index 'i' exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure 'i' is within bounds before accessing the transfer function points. If 'i' is out of bounds, the function returns false to indicate an error. drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:180 cm3_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:181 cm3_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:182 cm3_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max(CVE-2024-49969)
In the Linux kernel, the following vulnerability has been resolved: NFSD: Limit the number of concurrent async COPY operations Nothing appears to limit the number of concurrent async COPY operations that clients can start. In addition, AFAICT each async COPY can copy an unlimited number of 4MB chunks, so can run for a long time. Thus IMO async COPY can become a DoS vector. Add a restriction mechanism that bounds the number of concurrent background COPY operations. Start simple and try to be fair -- this patch implements a per-namespace limit. An async COPY request that occurs while this limit is exceeded gets NFS4ERR_DELAY. The requesting client can choose to send the request again after a delay or fall back to a traditional read/write style copy. If there is need to make the mechanism more sophisticated, we can visit that in future patches.(CVE-2024-49974)
In the Linux kernel, the following vulnerability has been resolved: i2c: stm32f7: Do not prepare/unprepare clock during runtime suspend/resume In case there is any sort of clock controller attached to this I2C bus controller, for example Versaclock or even an AIC32x4 I2C codec, then an I2C transfer triggered from the clock controller clk_ops .prepare callback may trigger a deadlock on drivers/clk/clk.c prepare_lock mutex. This is because the clock controller first grabs the prepare_lock mutex and then performs the prepare operation, including its I2C access. The I2C access resumes this I2C bus controller via .runtime_resume callback, which calls clk_prepare_enable(), which attempts to grab the prepare_lock mutex again and deadlocks. Since the clock are already prepared since probe() and unprepared in remove(), use simple clk_enable()/clk_disable() calls to enable and disable the clock on runtime suspend and resume, to avoid hitting the prepare_lock mutex.(CVE-2024-49985)
In the Linux kernel, the following vulnerability has been resolved: ALSA: asihpi: Fix potential OOB array access ASIHPI driver stores some values in the static array upon a response from the driver, and its index depends on the firmware. We shouldn't trust it blindly. This patch adds a sanity check of the array index to fit in the array size.(CVE-2024-50007)
In the Linux kernel, the following vulnerability has been resolved: scsi: fnic: Move flush_work initialization out of if block After commit 379a58caa199 ("scsi: fnic: Move fnic_fnic_flush_tx() to a work queue"), it can happen that a work item is sent to an uninitialized work queue. This may has the effect that the item being queued is never actually queued, and any further actions depending on it will not proceed. The following warning is observed while the fnic driver is loaded: kernel: WARNING: CPU: 11 PID: 0 at ../kernel/workqueue.c:1524 __queue_work+0x373/0x410 kernel: <IRQ> kernel: queue_work_on+0x3a/0x50 kernel: fnic_wq_copy_cmpl_handler+0x54a/0x730 [fnic 62fbff0c42e7fb825c60a55cde2fb91facb2ed24] kernel: fnic_isr_msix_wq_copy+0x2d/0x60 [fnic 62fbff0c42e7fb825c60a55cde2fb91facb2ed24] kernel: __handle_irq_event_percpu+0x36/0x1a0 kernel: handle_irq_event_percpu+0x30/0x70 kernel: handle_irq_event+0x34/0x60 kernel: handle_edge_irq+0x7e/0x1a0 kernel: __common_interrupt+0x3b/0xb0 kernel: common_interrupt+0x58/0xa0 kernel: </IRQ> It has been observed that this may break the rediscovery of Fibre Channel devices after a temporary fabric failure. This patch fixes it by moving the work queue initialization out of an if block in fnic_probe().(CVE-2024-50025)
In the Linux kernel, the following vulnerability has been resolved: net: do not delay dst_entries_add() in dst_release() dst_entries_add() uses per-cpu data that might be freed at netns dismantle from ip6_route_net_exit() calling dst_entries_destroy() Before ip6_route_net_exit() can be called, we release all the dsts associated with this netns, via calls to dst_release(), which waits an rcu grace period before calling dst_destroy() dst_entries_add() use in dst_destroy() is racy, because dst_entries_destroy() could have been called already. Decrementing the number of dsts must happen sooner. Notes: 1) in CONFIG_XFRM case, dst_destroy() can call dst_release_immediate(child), this might also cause UAF if the child does not have DST_NOCOUNT set. IPSEC maintainers might take a look and see how to address this. 2) There is also discussion about removing this count of dst, which might happen in future kernels.(CVE-2024-50036)
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointer before dereferencing se [WHAT & HOW] se is null checked previously in the same function, indicating it might be null; therefore, it must be checked when used again. This fixes 1 FORWARD_NULL issue reported by Coverity.(CVE-2024-50049)
| URL | Type | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"kernel-5.10.0-136.99.0.180.oe2203sp1.aarch64.rpm",
"kernel-debuginfo-5.10.0-136.99.0.180.oe2203sp1.aarch64.rpm",
"kernel-debugsource-5.10.0-136.99.0.180.oe2203sp1.aarch64.rpm",
"kernel-devel-5.10.0-136.99.0.180.oe2203sp1.aarch64.rpm",
"kernel-headers-5.10.0-136.99.0.180.oe2203sp1.aarch64.rpm",
"kernel-source-5.10.0-136.99.0.180.oe2203sp1.aarch64.rpm",
"kernel-tools-5.10.0-136.99.0.180.oe2203sp1.aarch64.rpm",
"kernel-tools-debuginfo-5.10.0-136.99.0.180.oe2203sp1.aarch64.rpm",
"kernel-tools-devel-5.10.0-136.99.0.180.oe2203sp1.aarch64.rpm",
"perf-5.10.0-136.99.0.180.oe2203sp1.aarch64.rpm",
"perf-debuginfo-5.10.0-136.99.0.180.oe2203sp1.aarch64.rpm",
"python3-perf-5.10.0-136.99.0.180.oe2203sp1.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-136.99.0.180.oe2203sp1.aarch64.rpm"
],
"src": [
"kernel-5.10.0-136.99.0.180.oe2203sp1.src.rpm"
],
"x86_64": [
"kernel-5.10.0-136.99.0.180.oe2203sp1.x86_64.rpm",
"kernel-debuginfo-5.10.0-136.99.0.180.oe2203sp1.x86_64.rpm",
"kernel-debugsource-5.10.0-136.99.0.180.oe2203sp1.x86_64.rpm",
"kernel-devel-5.10.0-136.99.0.180.oe2203sp1.x86_64.rpm",
"kernel-headers-5.10.0-136.99.0.180.oe2203sp1.x86_64.rpm",
"kernel-source-5.10.0-136.99.0.180.oe2203sp1.x86_64.rpm",
"kernel-tools-5.10.0-136.99.0.180.oe2203sp1.x86_64.rpm",
"kernel-tools-debuginfo-5.10.0-136.99.0.180.oe2203sp1.x86_64.rpm",
"kernel-tools-devel-5.10.0-136.99.0.180.oe2203sp1.x86_64.rpm",
"perf-5.10.0-136.99.0.180.oe2203sp1.x86_64.rpm",
"perf-debuginfo-5.10.0-136.99.0.180.oe2203sp1.x86_64.rpm",
"python3-perf-5.10.0-136.99.0.180.oe2203sp1.x86_64.rpm",
"python3-perf-debuginfo-5.10.0-136.99.0.180.oe2203sp1.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:22.03-LTS-SP1",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP1"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.10.0-136.99.0.180.oe2203sp1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "Critical"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\niommu/vt-d: Fix double list_add when enabling VMD in scalable mode\r\n\r\nWhen enabling VMD and IOMMU scalable mode, the following kernel panic\ncall trace/kernel log is shown in Eagle Stream platform (Sapphire Rapids\nCPU) during booting:\r\n\r\npci 0000:59:00.5: Adding to iommu group 42\n...\nvmd 0000:59:00.5: PCI host bridge to bus 10000:80\npci 10000:80:01.0: [8086:352a] type 01 class 0x060400\npci 10000:80:01.0: reg 0x10: [mem 0x00000000-0x0001ffff 64bit]\npci 10000:80:01.0: enabling Extended Tags\npci 10000:80:01.0: PME# supported from D0 D3hot D3cold\npci 10000:80:01.0: DMAR: Setup RID2PASID failed\npci 10000:80:01.0: Failed to add to iommu group 42: -16\npci 10000:80:03.0: [8086:352b] type 01 class 0x060400\npci 10000:80:03.0: reg 0x10: [mem 0x00000000-0x0001ffff 64bit]\npci 10000:80:03.0: enabling Extended Tags\npci 10000:80:03.0: PME# supported from D0 D3hot D3cold\n------------[ cut here ]------------\nkernel BUG at lib/list_debug.c:29!\ninvalid opcode: 0000 [#1] PREEMPT SMP NOPTI\nCPU: 0 PID: 7 Comm: kworker/0:1 Not tainted 5.17.0-rc3+ #7\nHardware name: Lenovo ThinkSystem SR650V3/SB27A86647, BIOS ESE101Y-1.00 01/13/2022\nWorkqueue: events work_for_cpu_fn\nRIP: 0010:__list_add_valid.cold+0x26/0x3f\nCode: 9a 4a ab ff 4c 89 c1 48 c7 c7 40 0c d9 9e e8 b9 b1 fe ff 0f\n 0b 48 89 f2 4c 89 c1 48 89 fe 48 c7 c7 f0 0c d9 9e e8 a2 b1\n fe ff \u0026lt;0f\u0026gt; 0b 48 89 d1 4c 89 c6 4c 89 ca 48 c7 c7 98 0c d9\n 9e e8 8b b1 fe\nRSP: 0000:ff5ad434865b3a40 EFLAGS: 00010246\nRAX: 0000000000000058 RBX: ff4d61160b74b880 RCX: ff4d61255e1fffa8\nRDX: 0000000000000000 RSI: 00000000fffeffff RDI: ffffffff9fd34f20\nRBP: ff4d611d8e245c00 R08: 0000000000000000 R09: ff5ad434865b3888\nR10: ff5ad434865b3880 R11: ff4d61257fdc6fe8 R12: ff4d61160b74b8a0\nR13: ff4d61160b74b8a0 R14: ff4d611d8e245c10 R15: ff4d611d8001ba70\nFS: 0000000000000000(0000) GS:ff4d611d5ea00000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: ff4d611fa1401000 CR3: 0000000aa0210001 CR4: 0000000000771ef0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400\nPKRU: 55555554\nCall Trace:\n \u0026lt;TASK\u0026gt;\n intel_pasid_alloc_table+0x9c/0x1d0\n dmar_insert_one_dev_info+0x423/0x540\n ? device_to_iommu+0x12d/0x2f0\n intel_iommu_attach_device+0x116/0x290\n __iommu_attach_device+0x1a/0x90\n iommu_group_add_device+0x190/0x2c0\n __iommu_probe_device+0x13e/0x250\n iommu_probe_device+0x24/0x150\n iommu_bus_notifier+0x69/0x90\n blocking_notifier_call_chain+0x5a/0x80\n device_add+0x3db/0x7b0\n ? arch_memremap_can_ram_remap+0x19/0x50\n ? memremap+0x75/0x140\n pci_device_add+0x193/0x1d0\n pci_scan_single_device+0xb9/0xf0\n pci_scan_slot+0x4c/0x110\n pci_scan_child_bus_extend+0x3a/0x290\n vmd_enable_domain.constprop.0+0x63e/0x820\n vmd_probe+0x163/0x190\n local_pci_probe+0x42/0x80\n work_for_cpu_fn+0x13/0x20\n process_one_work+0x1e2/0x3b0\n worker_thread+0x1c4/0x3a0\n ? rescuer_thread+0x370/0x370\n kthread+0xc7/0xf0\n ? kthread_complete_and_exit+0x20/0x20\n ret_from_fork+0x1f/0x30\n \u0026lt;/TASK\u0026gt;\nModules linked in:\n---[ end trace 0000000000000000 ]---\n...\nKernel panic - not syncing: Fatal exception\nKernel Offset: 0x1ca00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)\n---[ end Kernel panic - not syncing: Fatal exception ]---\r\n\r\nThe following \u0026apos;lspci\u0026apos; output shows devices \u0026apos;10000:80:*\u0026apos; are subdevices of\nthe VMD device 0000:59:00.5:\r\n\r\n $ lspci\n ...\n 0000:59:00.5 RAID bus controller: Intel Corporation Volume Management Device NVMe RAID Controller (rev 20)\n ...\n 10000:80:01.0 PCI bridge: Intel Corporation Device 352a (rev 03)\n 10000:80:03.0 PCI bridge: Intel Corporation Device 352b (rev 03)\n 10000:80:05.0 PCI bridge: Intel Corporation Device 352c (rev 03)\n 10000:80:07.0 PCI bridge: Intel Corporation Device 352d (rev 03)\n 10000:81:00.0 Non-Volatile memory controller: Intel Corporation NVMe Datacenter SSD [3DNAND, Beta Rock Controller]\n 10000:82:00\n---truncated---(CVE-2022-48916)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: udf: Fix preallocation discarding at indirect extent boundary When preallocation extent is the first one in the extent block, the code would corrupt extent tree header instead. Fix the problem and use udf_delete_aext() for deleting extent to avoid some code duplication.(CVE-2022-48946)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: PCI: mt7621: Add sentinel to quirks table Current driver is missing a sentinel in the struct soc_device_attribute array, which causes an oops when assessed by the soc_device_match(mt7621_pcie_quirks_match) call. This was only exposed once the CONFIG_SOC_MT7621 mt7621 soc_dev_attr was fixed to register the SOC as a device, in: commit 7c18b64bba3b (\u0026quot;mips: ralink: mt7621: do not use kzalloc too early\u0026quot;) Fix it by adding the required sentinel.(CVE-2022-48952)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: NFC: nci: Bounds check struct nfc_target arrays While running under CONFIG_FORTIFY_SOURCE=y, syzkaller reported: memcpy: detected field-spanning write (size 129) of single field \u0026quot;target-\u0026gt;sensf_res\u0026quot; at net/nfc/nci/ntf.c:260 (size 18) This appears to be a legitimate lack of bounds checking in nci_add_new_protocol(). Add the missing checks.(CVE-2022-48967)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: gpio: amd8111: Fix PCI device reference count leak for_each_pci_dev() is implemented by pci_get_device(). The comment of pci_get_device() says that it will increase the reference count for the returned pci_dev and also decrease the reference count for the input pci_dev @from if it is not NULL. If we break for_each_pci_dev() loop with pdev not NULL, we need to call pci_dev_put() to decrease the reference count. Add the missing pci_dev_put() after the \u0026apos;out\u0026apos; label. Since pci_dev_put() can handle NULL input parameter, there is no problem for the \u0026apos;Device not found\u0026apos; branch. For the normal path, add pci_dev_put() in amd_gpio_exit().(CVE-2022-48973)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: can: af_can: fix NULL pointer dereference in can_rcv_filter Analogue to commit 8aa59e355949 (\u0026quot;can: af_can: fix NULL pointer dereference in can_rx_register()\u0026quot;) we need to check for a missing initialization of ml_priv in the receive path of CAN frames. Since commit 4e096a18867a (\u0026quot;net: introduce CAN specific pointer in the struct net_device\u0026quot;) the check for dev-\u0026gt;type to be ARPHRD_CAN is not sufficient anymore since bonding or tun netdevices claim to be CAN devices but do not initialize ml_priv accordingly.(CVE-2022-48977)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: mm/gup: fix gup_pud_range() for dax For dax pud, pud_huge() returns true on x86. So the function works as long as hugetlb is configured. However, dax doesn\u0026apos;t depend on hugetlb. Commit 414fd080d125 (\u0026quot;mm/gup: fix gup_pmd_range() for dax\u0026quot;) fixed devmap-backed huge PMDs, but missed devmap-backed huge PUDs. Fix this as well. This fixes the below kernel panic: general protection fault, probably for non-canonical address 0x69e7c000cc478: 0000 [#1] SMP \u0026lt; snip \u0026gt; Call Trace: \u0026lt;TASK\u0026gt; get_user_pages_fast+0x1f/0x40 iov_iter_get_pages+0xc6/0x3b0 ? mempool_alloc+0x5d/0x170 bio_iov_iter_get_pages+0x82/0x4e0 ? bvec_alloc+0x91/0xc0 ? bio_alloc_bioset+0x19a/0x2a0 blkdev_direct_IO+0x282/0x480 ? __io_complete_rw_common+0xc0/0xc0 ? filemap_range_has_page+0x82/0xc0 generic_file_direct_write+0x9d/0x1a0 ? inode_update_time+0x24/0x30 __generic_file_write_iter+0xbd/0x1e0 blkdev_write_iter+0xb4/0x150 ? io_import_iovec+0x8d/0x340 io_write+0xf9/0x300 io_issue_sqe+0x3c3/0x1d30 ? sysvec_reschedule_ipi+0x6c/0x80 __io_queue_sqe+0x33/0x240 ? fget+0x76/0xa0 io_submit_sqes+0xe6a/0x18d0 ? __fget_light+0xd1/0x100 __x64_sys_io_uring_enter+0x199/0x880 ? __context_tracking_enter+0x1f/0x70 ? irqentry_exit_to_user_mode+0x24/0x30 ? irqentry_exit+0x1d/0x30 ? __context_tracking_exit+0xe/0x70 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x61/0xcb RIP: 0033:0x7fc97c11a7be \u0026lt; snip \u0026gt; \u0026lt;/TASK\u0026gt; ---[ end trace 48b2e0e67debcaeb ]--- RIP: 0010:internal_get_user_pages_fast+0x340/0x990 \u0026lt; snip \u0026gt; Kernel panic - not syncing: Fatal exception Kernel Offset: disabled(CVE-2022-48986)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: memcg: fix possible use-after-free in memcg_write_event_control() memcg_write_event_control() accesses the dentry-\u0026gt;d_name of the specified control fd to route the write call. As a cgroup interface file can\u0026apos;t be renamed, it\u0026apos;s safe to access d_name as long as the specified file is a regular cgroup file. Also, as these cgroup interface files can\u0026apos;t be removed before the directory, it\u0026apos;s safe to access the parent too. Prior to 347c4a874710 (\u0026quot;memcg: remove cgroup_event-\u0026gt;cft\u0026quot;), there was a call to __file_cft() which verified that the specified file is a regular cgroupfs file before further accesses. The cftype pointer returned from __file_cft() was no longer necessary and the commit inadvertently dropped the file type check with it allowing any file to slip through. With the invarients broken, the d_name and parent accesses can now race against renames and removals of arbitrary files and cause use-after-free\u0026apos;s. Fix the bug by resurrecting the file type check in __file_cft(). Now that cgroupfs is implemented through kernfs, checking the file operations needs to go through a layer of indirection. Instead, let\u0026apos;s check the superblock and dentry type.(CVE-2022-48988)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: mm/khugepaged: invoke MMU notifiers in shmem/file collapse paths Any codepath that zaps page table entries must invoke MMU notifiers to ensure that secondary MMUs (like KVM) don\u0026apos;t keep accessing pages which aren\u0026apos;t mapped anymore. Secondary MMUs don\u0026apos;t hold their own references to pages that are mirrored over, so failing to notify them can lead to page use-after-free. I\u0026apos;m marking this as addressing an issue introduced in commit f3f0e1d2150b (\u0026quot;khugepaged: add support of collapse for tmpfs/shmem pages\u0026quot;), but most of the security impact of this only came in commit 27e1f8273113 (\u0026quot;khugepaged: enable collapse pmd for pte-mapped THP\u0026quot;), which actually omitted flushes for the removal of present PTEs, not just for the removal of empty page tables.(CVE-2022-48991)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: ALSA: seq: Fix function prototype mismatch in snd_seq_expand_var_event With clang\u0026apos;s kernel control flow integrity (kCFI, CONFIG_CFI_CLANG), indirect call targets are validated against the expected function pointer prototype to make sure the call target is valid to help mitigate ROP attacks. If they are not identical, there is a failure at run time, which manifests as either a kernel panic or thread getting killed. seq_copy_in_user() and seq_copy_in_kernel() did not have prototypes matching snd_seq_dump_func_t. Adjust this and remove the casts. There are not resulting binary output differences. This was found as a result of Clang\u0026apos;s new -Wcast-function-type-strict flag, which is more sensitive than the simpler -Wcast-function-type, which only checks for type width mismatches.(CVE-2022-48994)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: tracing: Free buffers when a used dynamic event is removed(CVE-2022-49006)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: nilfs2: fix NULL pointer dereference in nilfs_palloc_commit_free_entry() Syzbot reported a null-ptr-deref bug: NILFS (loop0): segctord starting. Construction interval = 5 seconds, CP frequency \u0026lt; 30 seconds general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] CPU: 1 PID: 3603 Comm: segctord Not tainted 6.1.0-rc2-syzkaller-00105-gb229b6ca5abb #0 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 10/11/2022 RIP: 0010:nilfs_palloc_commit_free_entry+0xe5/0x6b0 fs/nilfs2/alloc.c:608 Code: 00 00 00 00 fc ff df 80 3c 02 00 0f 85 cd 05 00 00 48 b8 00 00 00 00 00 fc ff df 4c 8b 73 08 49 8d 7e 10 48 89 fa 48 c1 ea 03 \u0026lt;80\u0026gt; 3c 02 00 0f 85 26 05 00 00 49 8b 46 10 be a6 00 00 00 48 c7 c7 RSP: 0018:ffffc90003dff830 EFLAGS: 00010212 RAX: dffffc0000000000 RBX: ffff88802594e218 RCX: 000000000000000d RDX: 0000000000000002 RSI: 0000000000002000 RDI: 0000000000000010 RBP: ffff888071880222 R08: 0000000000000005 R09: 000000000000003f R10: 000000000000000d R11: 0000000000000000 R12: ffff888071880158 R13: ffff88802594e220 R14: 0000000000000000 R15: 0000000000000004 FS: 0000000000000000(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fb1c08316a8 CR3: 0000000018560000 CR4: 0000000000350ee0 Call Trace: \u0026lt;TASK\u0026gt; nilfs_dat_commit_free fs/nilfs2/dat.c:114 [inline] nilfs_dat_commit_end+0x464/0x5f0 fs/nilfs2/dat.c:193 nilfs_dat_commit_update+0x26/0x40 fs/nilfs2/dat.c:236 nilfs_btree_commit_update_v+0x87/0x4a0 fs/nilfs2/btree.c:1940 nilfs_btree_commit_propagate_v fs/nilfs2/btree.c:2016 [inline] nilfs_btree_propagate_v fs/nilfs2/btree.c:2046 [inline] nilfs_btree_propagate+0xa00/0xd60 fs/nilfs2/btree.c:2088 nilfs_bmap_propagate+0x73/0x170 fs/nilfs2/bmap.c:337 nilfs_collect_file_data+0x45/0xd0 fs/nilfs2/segment.c:568 nilfs_segctor_apply_buffers+0x14a/0x470 fs/nilfs2/segment.c:1018 nilfs_segctor_scan_file+0x3f4/0x6f0 fs/nilfs2/segment.c:1067 nilfs_segctor_collect_blocks fs/nilfs2/segment.c:1197 [inline] nilfs_segctor_collect fs/nilfs2/segment.c:1503 [inline] nilfs_segctor_do_construct+0x12fc/0x6af0 fs/nilfs2/segment.c:2045 nilfs_segctor_construct+0x8e3/0xb30 fs/nilfs2/segment.c:2379 nilfs_segctor_thread_construct fs/nilfs2/segment.c:2487 [inline] nilfs_segctor_thread+0x3c3/0xf30 fs/nilfs2/segment.c:2570 kthread+0x2e4/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306 \u0026lt;/TASK\u0026gt; ... If DAT metadata file is corrupted on disk, there is a case where req-\u0026gt;pr_desc_bh is NULL and blocknr is 0 at nilfs_dat_commit_end() during a b-tree operation that cascadingly updates ancestor nodes of the b-tree, because nilfs_dat_commit_alloc() for a lower level block can initialize the blocknr on the same DAT entry between nilfs_dat_prepare_end() and nilfs_dat_commit_end(). If this happens, nilfs_dat_commit_end() calls nilfs_dat_commit_free() without valid buffer heads in req-\u0026gt;pr_desc_bh and req-\u0026gt;pr_bitmap_bh, and causes the NULL pointer dereference above in nilfs_palloc_commit_free_entry() function, which leads to a crash. Fix this by adding a NULL check on req-\u0026gt;pr_desc_bh and req-\u0026gt;pr_bitmap_bh before nilfs_palloc_commit_free_entry() in nilfs_dat_commit_free(). This also calls nilfs_error() in that case to notify that there is a fatal flaw in the filesystem metadata and prevent further operations.(CVE-2022-49007)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: net: ethernet: nixge: fix NULL dereference In function nixge_hw_dma_bd_release() dereference of NULL pointer priv-\u0026gt;rx_bd_v is possible for the case of its allocation failure in nixge_hw_dma_bd_init(). Move for() loop with priv-\u0026gt;rx_bd_v dereference under the check for its validity. Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2022-49019)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: hwmon: (ibmpex) Fix possible UAF when ibmpex_register_bmc() fails Smatch report warning as follows: drivers/hwmon/ibmpex.c:509 ibmpex_register_bmc() warn: \u0026apos;\u0026amp;data-\u0026gt;list\u0026apos; not removed from list If ibmpex_find_sensors() fails in ibmpex_register_bmc(), data will be freed, but data-\u0026gt;list will not be removed from driver_data.bmc_data, then list traversal may cause UAF. Fix by removeing it from driver_data.bmc_data before free().(CVE-2022-49029)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: libbpf: Handle size overflow for ringbuf mmap The maximum size of ringbuf is 2GB on x86-64 host, so 2 * max_entries will overflow u32 when mapping producer page and data pages. Only casting max_entries to size_t is not enough, because for 32-bits application on 64-bits kernel the size of read-only mmap region also could overflow size_t. So fixing it by casting the size of read-only mmap region into a __u64 and checking whether or not there will be overflow during mmap.(CVE-2022-49030)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: btrfs: qgroup: fix sleep from invalid context bug in btrfs_qgroup_inherit() Syzkaller reported BUG as follows: BUG: sleeping function called from invalid context at include/linux/sched/mm.h:274 Call Trace: \u0026lt;TASK\u0026gt; dump_stack_lvl+0xcd/0x134 __might_resched.cold+0x222/0x26b kmem_cache_alloc+0x2e7/0x3c0 update_qgroup_limit_item+0xe1/0x390 btrfs_qgroup_inherit+0x147b/0x1ee0 create_subvol+0x4eb/0x1710 btrfs_mksubvol+0xfe5/0x13f0 __btrfs_ioctl_snap_create+0x2b0/0x430 btrfs_ioctl_snap_create_v2+0x25a/0x520 btrfs_ioctl+0x2a1c/0x5ce0 __x64_sys_ioctl+0x193/0x200 do_syscall_64+0x35/0x80 Fix this by calling qgroup_dirty() on @dstqgroup, and update limit item in btrfs_run_qgroups() later outside of the spinlock context.(CVE-2022-49033)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: imon: fix access to invalid resource for the second interface\r\n\r\nimon driver probes two USB interfaces, and at the probe of the second\ninterface, the driver assumes blindly that the first interface got\nbound with the same imon driver. It\u0026apos;s usually true, but it\u0026apos;s still\npossible that the first interface is bound with another driver via a\nmalformed descriptor. Then it may lead to a memory corruption, as\nspotted by syzkaller; imon driver accesses the data from drvdata as\nstruct imon_context object although it\u0026apos;s a completely different one\nthat was assigned by another driver.\r\n\r\nThis patch adds a sanity check -- whether the first interface is\nreally bound with the imon driver or not -- for avoiding the problem\nabove at the probe time.(CVE-2023-52754)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: dwc2: fix possible NULL pointer dereference caused by driver concurrency\r\n\r\nIn _dwc2_hcd_urb_enqueue(), \u0026quot;urb-\u0026gt;hcpriv = NULL\u0026quot; is executed without\nholding the lock \u0026quot;hsotg-\u0026gt;lock\u0026quot;. In _dwc2_hcd_urb_dequeue():\r\n\r\n spin_lock_irqsave(\u0026amp;hsotg-\u0026gt;lock, flags);\n ...\n\tif (!urb-\u0026gt;hcpriv) {\n\t\tdev_dbg(hsotg-\u0026gt;dev, \u0026quot;## urb-\u0026gt;hcpriv is NULL ##\\n\u0026quot;);\n\t\tgoto out;\n\t}\n rc = dwc2_hcd_urb_dequeue(hsotg, urb-\u0026gt;hcpriv); // Use urb-\u0026gt;hcpriv\n ...\nout:\n spin_unlock_irqrestore(\u0026amp;hsotg-\u0026gt;lock, flags);\r\n\r\nWhen _dwc2_hcd_urb_enqueue() and _dwc2_hcd_urb_dequeue() are\nconcurrently executed, the NULL check of \u0026quot;urb-\u0026gt;hcpriv\u0026quot; can be executed\nbefore \u0026quot;urb-\u0026gt;hcpriv = NULL\u0026quot;. After urb-\u0026gt;hcpriv is NULL, it can be used\nin the function call to dwc2_hcd_urb_dequeue(), which can cause a NULL\npointer dereference.\r\n\r\nThis possible bug is found by an experimental static analysis tool\ndeveloped by myself. This tool analyzes the locking APIs to extract\nfunction pairs that can be concurrently executed, and then analyzes the\ninstructions in the paired functions to identify possible concurrency\nbugs including data races and atomicity violations. The above possible\nbug is reported, when my tool analyzes the source code of Linux 6.5.\r\n\r\nTo fix this possible bug, \u0026quot;urb-\u0026gt;hcpriv = NULL\u0026quot; should be executed with\nholding the lock \u0026quot;hsotg-\u0026gt;lock\u0026quot;. After using this patch, my tool never\nreports the possible bug, with the kernelconfiguration allyesconfig for\nx86_64. Because I have no associated hardware, I cannot test the patch\nin runtime testing, and just verify it according to the code logic.(CVE-2023-52855)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: ntb: intel: Fix the NULL vs IS_ERR() bug for debugfs_create_dir() The debugfs_create_dir() function returns error pointers. It never returns NULL. So use IS_ERR() to check it.(CVE-2023-52917)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: media: pci: cx23885: check cx23885_vdev_init() return cx23885_vdev_init() can return a NULL pointer, but that pointer is used in the next line without a check. Add a NULL pointer check and go to the error unwind if it is NULL.(CVE-2023-52918)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: nfc: nci: fix possible NULL pointer dereference in send_acknowledge() Handle memory allocation failure from nci_skb_alloc() (calling alloc_skb()) to avoid possible NULL pointer dereference.(CVE-2023-52919)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: Revert \u0026quot;scsi: fcoe: Fix potential deadlock on \u0026amp;fip-\u0026gt;ctlr_lock\u0026quot;\r\n\r\nThis reverts commit 1a1975551943f681772720f639ff42fbaa746212.\r\n\r\nThis commit causes interrupts to be lost for FCoE devices, since it changed\nsping locks from \u0026quot;bh\u0026quot; to \u0026quot;irqsave\u0026quot;.\r\n\r\nInstead, a work queue should be used, and will be addressed in a separate\ncommit.(CVE-2024-26917)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nof: module: prevent NULL pointer dereference in vsnprintf()\r\n\r\nIn of_modalias(), we can get passed the str and len parameters which would\ncause a kernel oops in vsnprintf() since it only allows passing a NULL ptr\nwhen the length is also 0. Also, we need to filter out the negative values\nof the len parameter as these will result in a really huge buffer since\nsnprintf() takes size_t parameter while ours is ssize_t...\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with the Svace static\nanalysis tool.(CVE-2024-35878)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndma: xilinx_dpdma: Fix locking\r\n\r\nThere are several places where either chan-\u0026gt;lock or chan-\u0026gt;vchan.lock was\nnot held. Add appropriate locking. This fixes lockdep warnings like\r\n\r\n[ 31.077578] ------------[ cut here ]------------\n[ 31.077831] WARNING: CPU: 2 PID: 40 at drivers/dma/xilinx/xilinx_dpdma.c:834 xilinx_dpdma_chan_queue_transfer+0x274/0x5e0\n[ 31.077953] Modules linked in:\n[ 31.078019] CPU: 2 PID: 40 Comm: kworker/u12:1 Not tainted 6.6.20+ #98\n[ 31.078102] Hardware name: xlnx,zynqmp (DT)\n[ 31.078169] Workqueue: events_unbound deferred_probe_work_func\n[ 31.078272] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[ 31.078377] pc : xilinx_dpdma_chan_queue_transfer+0x274/0x5e0\n[ 31.078473] lr : xilinx_dpdma_chan_queue_transfer+0x270/0x5e0\n[ 31.078550] sp : ffffffc083bb2e10\n[ 31.078590] x29: ffffffc083bb2e10 x28: 0000000000000000 x27: ffffff880165a168\n[ 31.078754] x26: ffffff880164e920 x25: ffffff880164eab8 x24: ffffff880164d480\n[ 31.078920] x23: ffffff880165a148 x22: ffffff880164e988 x21: 0000000000000000\n[ 31.079132] x20: ffffffc082aa3000 x19: ffffff880164e880 x18: 0000000000000000\n[ 31.079295] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000\n[ 31.079453] x14: 0000000000000000 x13: ffffff8802263dc0 x12: 0000000000000001\n[ 31.079613] x11: 0001ffc083bb2e34 x10: 0001ff880164e98f x9 : 0001ffc082aa3def\n[ 31.079824] x8 : 0001ffc082aa3dec x7 : 0000000000000000 x6 : 0000000000000516\n[ 31.079982] x5 : ffffffc7f8d43000 x4 : ffffff88003c9c40 x3 : ffffffffffffffff\n[ 31.080147] x2 : ffffffc7f8d43000 x1 : 00000000000000c0 x0 : 0000000000000000\n[ 31.080307] Call trace:\n[ 31.080340] xilinx_dpdma_chan_queue_transfer+0x274/0x5e0\n[ 31.080518] xilinx_dpdma_issue_pending+0x11c/0x120\n[ 31.080595] zynqmp_disp_layer_update+0x180/0x3ac\n[ 31.080712] zynqmp_dpsub_plane_atomic_update+0x11c/0x21c\n[ 31.080825] drm_atomic_helper_commit_planes+0x20c/0x684\n[ 31.080951] drm_atomic_helper_commit_tail+0x5c/0xb0\n[ 31.081139] commit_tail+0x234/0x294\n[ 31.081246] drm_atomic_helper_commit+0x1f8/0x210\n[ 31.081363] drm_atomic_commit+0x100/0x140\n[ 31.081477] drm_client_modeset_commit_atomic+0x318/0x384\n[ 31.081634] drm_client_modeset_commit_locked+0x8c/0x24c\n[ 31.081725] drm_client_modeset_commit+0x34/0x5c\n[ 31.081812] __drm_fb_helper_restore_fbdev_mode_unlocked+0x104/0x168\n[ 31.081899] drm_fb_helper_set_par+0x50/0x70\n[ 31.081971] fbcon_init+0x538/0xc48\n[ 31.082047] visual_init+0x16c/0x23c\n[ 31.082207] do_bind_con_driver.isra.0+0x2d0/0x634\n[ 31.082320] do_take_over_console+0x24c/0x33c\n[ 31.082429] do_fbcon_takeover+0xbc/0x1b0\n[ 31.082503] fbcon_fb_registered+0x2d0/0x34c\n[ 31.082663] register_framebuffer+0x27c/0x38c\n[ 31.082767] __drm_fb_helper_initial_config_and_unlock+0x5c0/0x91c\n[ 31.082939] drm_fb_helper_initial_config+0x50/0x74\n[ 31.083012] drm_fbdev_dma_client_hotplug+0xb8/0x108\n[ 31.083115] drm_client_register+0xa0/0xf4\n[ 31.083195] drm_fbdev_dma_setup+0xb0/0x1cc\n[ 31.083293] zynqmp_dpsub_drm_init+0x45c/0x4e0\n[ 31.083431] zynqmp_dpsub_probe+0x444/0x5e0\n[ 31.083616] platform_probe+0x8c/0x13c\n[ 31.083713] really_probe+0x258/0x59c\n[ 31.083793] __driver_probe_device+0xc4/0x224\n[ 31.083878] driver_probe_device+0x70/0x1c0\n[ 31.083961] __device_attach_driver+0x108/0x1e0\n[ 31.084052] bus_for_each_drv+0x9c/0x100\n[ 31.084125] __device_attach+0x100/0x298\n[ 31.084207] device_initial_probe+0x14/0x20\n[ 31.084292] bus_probe_device+0xd8/0xdc\n[ 31.084368] deferred_probe_work_func+0x11c/0x180\n[ 31.084451] process_one_work+0x3ac/0x988\n[ 31.084643] worker_thread+0x398/0x694\n[ 31.084752] kthread+0x1bc/0x1c0\n[ 31.084848] ret_from_fork+0x10/0x20\n[ 31.084932] irq event stamp: 64549\n[ 31.084970] hardirqs last enabled at (64548): [\u0026lt;ffffffc081adf35c\u0026gt;] _raw_spin_unlock_irqrestore+0x80/0x90\n[ 31.085157]\n---truncated---(CVE-2024-35990)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nfnetlink_queue: acquire rcu_read_lock() in instance_destroy_rcu()\r\n\r\nsyzbot reported that nf_reinject() could be called without rcu_read_lock() :\r\n\r\nWARNING: suspicious RCU usage\n6.9.0-rc7-syzkaller-02060-g5c1672705a1a #0 Not tainted\r\n\r\nnet/netfilter/nfnetlink_queue.c:263 suspicious rcu_dereference_check() usage!\r\n\r\nother info that might help us debug this:\r\n\r\nrcu_scheduler_active = 2, debug_locks = 1\n2 locks held by syz-executor.4/13427:\n #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_lock_acquire include/linux/rcupdate.h:329 [inline]\n #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_do_batch kernel/rcu/tree.c:2190 [inline]\n #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_core+0xa86/0x1830 kernel/rcu/tree.c:2471\n #1: ffff88801ca92958 (\u0026amp;inst-\u0026gt;lock){+.-.}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline]\n #1: ffff88801ca92958 (\u0026amp;inst-\u0026gt;lock){+.-.}-{2:2}, at: nfqnl_flush net/netfilter/nfnetlink_queue.c:405 [inline]\n #1: ffff88801ca92958 (\u0026amp;inst-\u0026gt;lock){+.-.}-{2:2}, at: instance_destroy_rcu+0x30/0x220 net/netfilter/nfnetlink_queue.c:172\r\n\r\nstack backtrace:\nCPU: 0 PID: 13427 Comm: syz-executor.4 Not tainted 6.9.0-rc7-syzkaller-02060-g5c1672705a1a #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024\nCall Trace:\n \u0026lt;IRQ\u0026gt;\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114\n lockdep_rcu_suspicious+0x221/0x340 kernel/locking/lockdep.c:6712\n nf_reinject net/netfilter/nfnetlink_queue.c:323 [inline]\n nfqnl_reinject+0x6ec/0x1120 net/netfilter/nfnetlink_queue.c:397\n nfqnl_flush net/netfilter/nfnetlink_queue.c:410 [inline]\n instance_destroy_rcu+0x1ae/0x220 net/netfilter/nfnetlink_queue.c:172\n rcu_do_batch kernel/rcu/tree.c:2196 [inline]\n rcu_core+0xafd/0x1830 kernel/rcu/tree.c:2471\n handle_softirqs+0x2d6/0x990 kernel/softirq.c:554\n __do_softirq kernel/softirq.c:588 [inline]\n invoke_softirq kernel/softirq.c:428 [inline]\n __irq_exit_rcu+0xf4/0x1c0 kernel/softirq.c:637\n irq_exit_rcu+0x9/0x30 kernel/softirq.c:649\n instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1043 [inline]\n sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1043\n \u0026lt;/IRQ\u0026gt;\n \u0026lt;TASK\u0026gt;(CVE-2024-36286)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsoundwire: cadence: fix invalid PDI offset\r\n\r\nFor some reason, we add an offset to the PDI, presumably to skip the\nPDI0 and PDI1 which are reserved for BPT.\r\n\r\nThis code is however completely wrong and leads to an out-of-bounds\naccess. We were just lucky so far since we used only a couple of PDIs\nand remained within the PDI array bounds.\r\n\r\nA Fixes: tag is not provided since there are no known platforms where\nthe out-of-bounds would be accessed, and the initial code had problems\nas well.\r\n\r\nA follow-up patch completely removes this useless offset.(CVE-2024-38635)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nriscv: prevent pt_regs corruption for secondary idle threads\r\n\r\nTop of the kernel thread stack should be reserved for pt_regs. However\nthis is not the case for the idle threads of the secondary boot harts.\nTheir stacks overlap with their pt_regs, so both may get corrupted.\r\n\r\nSimilar issue has been fixed for the primary hart, see c7cdd96eca28\n(\u0026quot;riscv: prevent stack corruption by reserving task_pt_regs(p) early\u0026quot;).\nHowever that fix was not propagated to the secondary harts. The problem\nhas been noticed in some CPU hotplug tests with V enabled. The function\nsmp_callin stored several registers on stack, corrupting top of pt_regs\nstructure including status field. As a result, kernel attempted to save\nor restore inexistent V context.(CVE-2024-38667)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nocfs2: add bounds checking to ocfs2_check_dir_entry()\r\n\r\nThis adds sanity checks for ocfs2_dir_entry to make sure all members of\nocfs2_dir_entry don\u0026apos;t stray beyond valid memory region.(CVE-2024-41015)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnvmet: fix a possible leak when destroy a ctrl during qp establishment\r\n\r\nIn nvmet_sq_destroy we capture sq-\u0026gt;ctrl early and if it is non-NULL we\nknow that a ctrl was allocated (in the admin connect request handler)\nand we need to release pending AERs, clear ctrl-\u0026gt;sqs and sq-\u0026gt;ctrl\n(for nvme-loop primarily), and drop the final reference on the ctrl.\r\n\r\nHowever, a small window is possible where nvmet_sq_destroy starts (as\na result of the client giving up and disconnecting) concurrently with\nthe nvme admin connect cmd (which may be in an early stage). But *before*\nkill_and_confirm of sq-\u0026gt;ref (i.e. the admin connect managed to get an sq\nlive reference). In this case, sq-\u0026gt;ctrl was allocated however after it was\ncaptured in a local variable in nvmet_sq_destroy.\nThis prevented the final reference drop on the ctrl.\r\n\r\nSolve this by re-capturing the sq-\u0026gt;ctrl after all inflight request has\ncompleted, where for sure sq-\u0026gt;ctrl reference is final, and move forward\nbased on that.\r\n\r\nThis issue was observed in an environment with many hosts connecting\nmultiple ctrls simoutanuosly, creating a delay in allocating a ctrl\nleading up to this race window.(CVE-2024-42152)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndev/parport: fix the array out-of-bounds risk\r\n\r\nFixed array out-of-bounds issues caused by sprintf\nby replacing it with snprintf for safer data copying,\nensuring the destination buffer is not overflowed.\r\n\r\nBelow is the stack trace I encountered during the actual issue:\r\n\r\n[ 66.575408s] [pid:5118,cpu4,QThread,4]Kernel panic - not syncing: stack-protector:\nKernel stack is corrupted in: do_hardware_base_addr+0xcc/0xd0 [parport]\n[ 66.575408s] [pid:5118,cpu4,QThread,5]CPU: 4 PID: 5118 Comm:\nQThread Tainted: G S W O 5.10.97-arm64-desktop #7100.57021.2\n[ 66.575439s] [pid:5118,cpu4,QThread,6]TGID: 5087 Comm: EFileApp\n[ 66.575439s] [pid:5118,cpu4,QThread,7]Hardware name: HUAWEI HUAWEI QingYun\nPGUX-W515x-B081/SP1PANGUXM, BIOS 1.00.07 04/29/2024\n[ 66.575439s] [pid:5118,cpu4,QThread,8]Call trace:\n[ 66.575469s] [pid:5118,cpu4,QThread,9] dump_backtrace+0x0/0x1c0\n[ 66.575469s] [pid:5118,cpu4,QThread,0] show_stack+0x14/0x20\n[ 66.575469s] [pid:5118,cpu4,QThread,1] dump_stack+0xd4/0x10c\n[ 66.575500s] [pid:5118,cpu4,QThread,2] panic+0x1d8/0x3bc\n[ 66.575500s] [pid:5118,cpu4,QThread,3] __stack_chk_fail+0x2c/0x38\n[ 66.575500s] [pid:5118,cpu4,QThread,4] do_hardware_base_addr+0xcc/0xd0 [parport](CVE-2024-42301)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: virt_wifi: avoid reporting connection success with wrong SSID\r\n\r\nWhen user issues a connection with a different SSID than the one\nvirt_wifi has advertised, the __cfg80211_connect_result() will\ntrigger the warning: WARN_ON(bss_not_found).\r\n\r\nThe issue is because the connection code in virt_wifi does not\ncheck the SSID from user space (it only checks the BSSID), and\nvirt_wifi will call cfg80211_connect_result() with WLAN_STATUS_SUCCESS\neven if the SSID is different from the one virt_wifi has advertised.\nEventually cfg80211 won\u0026apos;t be able to find the cfg80211_bss and generate\nthe warning.\r\n\r\nFixed it by checking the SSID (from user space) in the connection code.(CVE-2024-43841)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\njfs: Fix array-index-out-of-bounds in diFree(CVE-2024-43858)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/nouveau: prime: fix refcount underflow\r\n\r\nCalling nouveau_bo_ref() on a nouveau_bo without initializing it (and\nhence the backing ttm_bo) leads to a refcount underflow.\r\n\r\nInstead of calling nouveau_bo_ref() in the unwind path of\ndrm_gem_object_init(), clean things up manually.\r\n\r\n(cherry picked from commit 1b93f3e89d03cfc576636e195466a0d728ad8de5)(CVE-2024-43867)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndevres: Fix memory leakage caused by driver API devm_free_percpu()\r\n\r\nIt will cause memory leakage when use driver API devm_free_percpu()\nto free memory allocated by devm_alloc_percpu(), fixed by using\ndevres_release() instead of devres_destroy() within devm_free_percpu().(CVE-2024-43871)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/client: fix null pointer dereference in drm_client_modeset_probe\r\n\r\nIn drm_client_modeset_probe(), the return value of drm_mode_duplicate() is\nassigned to modeset-\u0026gt;mode, which will lead to a possible NULL pointer\ndereference on failure of drm_mode_duplicate(). Add a check to avoid npd.(CVE-2024-43894)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: dwc3: core: Prevent USB core invalid event buffer address access\r\n\r\nThis commit addresses an issue where the USB core could access an\ninvalid event buffer address during runtime suspend, potentially causing\nSMMU faults and other memory issues in Exynos platforms. The problem\narises from the following sequence.\n 1. In dwc3_gadget_suspend, there is a chance of a timeout when\n moving the USB core to the halt state after clearing the\n run/stop bit by software.\n 2. In dwc3_core_exit, the event buffer is cleared regardless of\n the USB core\u0026apos;s status, which may lead to an SMMU faults and\n other memory issues. if the USB core tries to access the event\n buffer address.\r\n\r\nTo prevent this hardware quirk on Exynos platforms, this commit ensures\nthat the event buffer address is not cleared by software when the USB\ncore is active during runtime suspend by checking its status before\nclearing the buffer address.(CVE-2024-46675)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsoc: qcom: cmd-db: Map shared memory as WC, not WB\r\n\r\nLinux does not write into cmd-db region. This region of memory is write\nprotected by XPU. XPU may sometime falsely detect clean cache eviction\nas \u0026quot;write\u0026quot; into the write protected region leading to secure interrupt\nwhich causes an endless loop somewhere in Trust Zone.\r\n\r\nThe only reason it is working right now is because Qualcomm Hypervisor\nmaps the same region as Non-Cacheable memory in Stage 2 translation\ntables. The issue manifests if we want to use another hypervisor (like\nXen or KVM), which does not know anything about those specific mappings.\r\n\r\nChanging the mapping of cmd-db memory from MEMREMAP_WB to MEMREMAP_WT/WC\nremoves dependency on correct mappings in Stage 2 tables. This patch\nfixes the issue by updating the mapping to MEMREMAP_WC.\r\n\r\nI tested this on SA8155P with Xen.(CVE-2024-46689)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: fix mc_data out-of-bounds read warning\r\n\r\nClear warning that read mc_data[i-1] may out-of-bounds.(CVE-2024-46722)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: Fix out-of-bounds read of df_v1_7_channel_number\r\n\r\nCheck the fb_channel_number range to avoid the array out-of-bounds\nread error(CVE-2024-46724)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nhwmon: (nct6775-core) Fix underflows seen when writing limit attributes\r\n\r\nDIV_ROUND_CLOSEST() after kstrtol() results in an underflow if a large\nnegative number such as -9223372036854775808 is provided by the user.\nFix it by reordering clamp_val() and DIV_ROUND_CLOSEST() operations.(CVE-2024-46757)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: added NULL check at start of dc_validate_stream\r\n\r\n[Why]\nprevent invalid memory access\r\n\r\n[How]\ncheck if dc and stream are NULL(CVE-2024-46802)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nKVM: x86: Acquire kvm-\u0026gt;srcu when handling KVM_SET_VCPU_EVENTS\r\n\r\nGrab kvm-\u0026gt;srcu when processing KVM_SET_VCPU_EVENTS, as KVM will forcibly\nleave nested VMX/SVM if SMM mode is being toggled, and leaving nested VMX\nreads guest memory.\r\n\r\nNote, kvm_vcpu_ioctl_x86_set_vcpu_events() can also be called from KVM_RUN\nvia sync_regs(), which already holds SRCU. I.e. trying to precisely use\nkvm_vcpu_srcu_read_lock() around the problematic SMM code would cause\nproblems. Acquiring SRCU isn\u0026apos;t all that expensive, so for simplicity,\ngrab it unconditionally for KVM_SET_VCPU_EVENTS.\r\n\r\n =============================\n WARNING: suspicious RCU usage\n 6.10.0-rc7-332d2c1d713e-next-vm #552 Not tainted\n -----------------------------\n include/linux/kvm_host.h:1027 suspicious rcu_dereference_check() usage!\r\n\r\n other info that might help us debug this:\r\n\r\n rcu_scheduler_active = 2, debug_locks = 1\n 1 lock held by repro/1071:\n #0: ffff88811e424430 (\u0026amp;vcpu-\u0026gt;mutex){+.+.}-{3:3}, at: kvm_vcpu_ioctl+0x7d/0x970 [kvm]\r\n\r\n stack backtrace:\n CPU: 15 PID: 1071 Comm: repro Not tainted 6.10.0-rc7-332d2c1d713e-next-vm #552\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015\n Call Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x7f/0x90\n lockdep_rcu_suspicious+0x13f/0x1a0\n kvm_vcpu_gfn_to_memslot+0x168/0x190 [kvm]\n kvm_vcpu_read_guest+0x3e/0x90 [kvm]\n nested_vmx_load_msr+0x6b/0x1d0 [kvm_intel]\n load_vmcs12_host_state+0x432/0xb40 [kvm_intel]\n vmx_leave_nested+0x30/0x40 [kvm_intel]\n kvm_vcpu_ioctl_x86_set_vcpu_events+0x15d/0x2b0 [kvm]\n kvm_arch_vcpu_ioctl+0x1107/0x1750 [kvm]\n ? mark_held_locks+0x49/0x70\n ? kvm_vcpu_ioctl+0x7d/0x970 [kvm]\n ? kvm_vcpu_ioctl+0x497/0x970 [kvm]\n kvm_vcpu_ioctl+0x497/0x970 [kvm]\n ? lock_acquire+0xba/0x2d0\n ? find_held_lock+0x2b/0x80\n ? do_user_addr_fault+0x40c/0x6f0\n ? lock_release+0xb7/0x270\n __x64_sys_ioctl+0x82/0xb0\n do_syscall_64+0x6c/0x170\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n RIP: 0033:0x7ff11eb1b539\n \u0026lt;/TASK\u0026gt;(CVE-2024-46830)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nspi: nxp-fspi: fix the KASAN report out-of-bounds bug\r\n\r\nChange the memcpy length to fix the out-of-bounds issue when writing the\ndata that is not 4 byte aligned to TX FIFO.\r\n\r\nTo reproduce the issue, write 3 bytes data to NOR chip.\r\n\r\ndd if=3b of=/dev/mtd0\n[ 36.926103] ==================================================================\n[ 36.933409] BUG: KASAN: slab-out-of-bounds in nxp_fspi_exec_op+0x26ec/0x2838\n[ 36.940514] Read of size 4 at addr ffff00081037c2a0 by task dd/455\n[ 36.946721]\n[ 36.948235] CPU: 3 UID: 0 PID: 455 Comm: dd Not tainted 6.11.0-rc5-gc7b0e37c8434 #1070\n[ 36.956185] Hardware name: Freescale i.MX8QM MEK (DT)\n[ 36.961260] Call trace:\n[ 36.963723] dump_backtrace+0x90/0xe8\n[ 36.967414] show_stack+0x18/0x24\n[ 36.970749] dump_stack_lvl+0x78/0x90\n[ 36.974451] print_report+0x114/0x5cc\n[ 36.978151] kasan_report+0xa4/0xf0\n[ 36.981670] __asan_report_load_n_noabort+0x1c/0x28\n[ 36.986587] nxp_fspi_exec_op+0x26ec/0x2838\n[ 36.990800] spi_mem_exec_op+0x8ec/0xd30\n[ 36.994762] spi_mem_no_dirmap_read+0x190/0x1e0\n[ 36.999323] spi_mem_dirmap_write+0x238/0x32c\n[ 37.003710] spi_nor_write_data+0x220/0x374\n[ 37.007932] spi_nor_write+0x110/0x2e8\n[ 37.011711] mtd_write_oob_std+0x154/0x1f0\n[ 37.015838] mtd_write_oob+0x104/0x1d0\n[ 37.019617] mtd_write+0xb8/0x12c\n[ 37.022953] mtdchar_write+0x224/0x47c\n[ 37.026732] vfs_write+0x1e4/0x8c8\n[ 37.030163] ksys_write+0xec/0x1d0\n[ 37.033586] __arm64_sys_write+0x6c/0x9c\n[ 37.037539] invoke_syscall+0x6c/0x258\n[ 37.041327] el0_svc_common.constprop.0+0x160/0x22c\n[ 37.046244] do_el0_svc+0x44/0x5c\n[ 37.049589] el0_svc+0x38/0x78\n[ 37.052681] el0t_64_sync_handler+0x13c/0x158\n[ 37.057077] el0t_64_sync+0x190/0x194\n[ 37.060775]\n[ 37.062274] Allocated by task 455:\n[ 37.065701] kasan_save_stack+0x2c/0x54\n[ 37.069570] kasan_save_track+0x20/0x3c\n[ 37.073438] kasan_save_alloc_info+0x40/0x54\n[ 37.077736] __kasan_kmalloc+0xa0/0xb8\n[ 37.081515] __kmalloc_noprof+0x158/0x2f8\n[ 37.085563] mtd_kmalloc_up_to+0x120/0x154\n[ 37.089690] mtdchar_write+0x130/0x47c\n[ 37.093469] vfs_write+0x1e4/0x8c8\n[ 37.096901] ksys_write+0xec/0x1d0\n[ 37.100332] __arm64_sys_write+0x6c/0x9c\n[ 37.104287] invoke_syscall+0x6c/0x258\n[ 37.108064] el0_svc_common.constprop.0+0x160/0x22c\n[ 37.112972] do_el0_svc+0x44/0x5c\n[ 37.116319] el0_svc+0x38/0x78\n[ 37.119401] el0t_64_sync_handler+0x13c/0x158\n[ 37.123788] el0t_64_sync+0x190/0x194\n[ 37.127474]\n[ 37.128977] The buggy address belongs to the object at ffff00081037c2a0\n[ 37.128977] which belongs to the cache kmalloc-8 of size 8\n[ 37.141177] The buggy address is located 0 bytes inside of\n[ 37.141177] allocated 3-byte region [ffff00081037c2a0, ffff00081037c2a3)\n[ 37.153465]\n[ 37.154971] The buggy address belongs to the physical page:\n[ 37.160559] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x89037c\n[ 37.168596] flags: 0xbfffe0000000000(node=0|zone=2|lastcpupid=0x1ffff)\n[ 37.175149] page_type: 0xfdffffff(slab)\n[ 37.179021] raw: 0bfffe0000000000 ffff000800002500 dead000000000122 0000000000000000\n[ 37.186788] raw: 0000000000000000 0000000080800080 00000001fdffffff 0000000000000000\n[ 37.194553] page dumped because: kasan: bad access detected\n[ 37.200144]\n[ 37.201647] Memory state around the buggy address:\n[ 37.206460] ffff00081037c180: fa fc fc fc fa fc fc fc fa fc fc fc fa fc fc fc\n[ 37.213701] ffff00081037c200: fa fc fc fc 05 fc fc fc 03 fc fc fc 02 fc fc fc\n[ 37.220946] \u0026gt;ffff00081037c280: 06 fc fc fc 03 fc fc fc fc fc fc fc fc fc fc fc\n[ 37.228186] ^\n[ 37.232473] ffff00081037c300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc\n[ 37.239718] ffff00081037c380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc\n[ 37.246962] ==============================================================\n---truncated---(CVE-2024-46853)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nPCI: keystone: Add workaround for Errata #i2037 (AM65x SR 1.0)\r\n\r\nErrata #i2037 in AM65x/DRA80xM Processors Silicon Revision 1.0\n(SPRZ452D_July 2018_Revised December 2019 [1]) mentions when an\ninbound PCIe TLP spans more than two internal AXI 128-byte bursts,\nthe bus may corrupt the packet payload and the corrupt data may\ncause associated applications or the processor to hang.\r\n\r\nThe workaround for Errata #i2037 is to limit the maximum read\nrequest size and maximum payload size to 128 bytes. Add workaround\nfor Errata #i2037 here.\r\n\r\nThe errata and workaround is applicable only to AM65x SR 1.0 and\nlater versions of the silicon will have this fixed.\r\n\r\n[1] -\u0026gt; https://www.ti.com/lit/er/sprz452i/sprz452i.pdf(CVE-2024-47667)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: fix state management in error path of log writing function\r\n\r\nAfter commit a694291a6211 (\u0026quot;nilfs2: separate wait function from\nnilfs_segctor_write\u0026quot;) was applied, the log writing function\nnilfs_segctor_do_construct() was able to issue I/O requests continuously\neven if user data blocks were split into multiple logs across segments,\nbut two potential flaws were introduced in its error handling.\r\n\r\nFirst, if nilfs_segctor_begin_construction() fails while creating the\nsecond or subsequent logs, the log writing function returns without\ncalling nilfs_segctor_abort_construction(), so the writeback flag set on\npages/folios will remain uncleared. This causes page cache operations to\nhang waiting for the writeback flag. For example,\ntruncate_inode_pages_final(), which is called via nilfs_evict_inode() when\nan inode is evicted from memory, will hang.\r\n\r\nSecond, the NILFS_I_COLLECTED flag set on normal inodes remain uncleared. \nAs a result, if the next log write involves checkpoint creation, that\u0026apos;s\nfine, but if a partial log write is performed that does not, inodes with\nNILFS_I_COLLECTED set are erroneously removed from the \u0026quot;sc_dirty_files\u0026quot;\nlist, and their data and b-tree blocks may not be written to the device,\ncorrupting the block mapping.\r\n\r\nFix these issues by uniformly calling nilfs_segctor_abort_construction()\non failure of each step in the loop in nilfs_segctor_do_construct(),\nhaving it clean up logs and segment usages according to progress, and\ncorrecting the conditions for calling nilfs_redirty_inodes() to ensure\nthat the NILFS_I_COLLECTED flag is cleared.(CVE-2024-47669)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: tcp: check skb is non-NULL in tcp_rto_delta_us() We have some machines running stock Ubuntu 20.04.6 which is their 5.4.0-174-generic kernel that are running ceph and recently hit a null ptr dereference in tcp_rearm_rto(). Initially hitting it from the TLP path, but then later we also saw it getting hit from the RACK case as well. Here are examples of the oops messages we saw in each of those cases: Jul 26 15:05:02 rx [11061395.780353] BUG: kernel NULL pointer dereference, address: 0000000000000020 Jul 26 15:05:02 rx [11061395.787572] #PF: supervisor read access in kernel mode Jul 26 15:05:02 rx [11061395.792971] #PF: error_code(0x0000) - not-present page Jul 26 15:05:02 rx [11061395.798362] PGD 0 P4D 0 Jul 26 15:05:02 rx [11061395.801164] Oops: 0000 [#1] SMP NOPTI Jul 26 15:05:02 rx [11061395.805091] CPU: 0 PID: 9180 Comm: msgr-worker-1 Tainted: G W 5.4.0-174-generic #193-Ubuntu Jul 26 15:05:02 rx [11061395.814996] Hardware name: Supermicro SMC 2x26 os-gen8 64C NVME-Y 256G/H12SSW-NTR, BIOS 2.5.V1.2U.NVMe.UEFI 05/09/2023 Jul 26 15:05:02 rx [11061395.825952] RIP: 0010:tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.830656] Code: 87 ca 04 00 00 00 5b 41 5c 41 5d 5d c3 c3 49 8b bc 24 40 06 00 00 eb 8d 48 bb cf f7 53 e3 a5 9b c4 20 4c 89 ef e8 0c fe 0e 00 \u0026lt;48\u0026gt; 8b 78 20 48 c1 ef 03 48 89 f8 41 8b bc 24 80 04 00 00 48 f7 e3 Jul 26 15:05:02 rx [11061395.849665] RSP: 0018:ffffb75d40003e08 EFLAGS: 00010246 Jul 26 15:05:02 rx [11061395.855149] RAX: 0000000000000000 RBX: 20c49ba5e353f7cf RCX: 0000000000000000 Jul 26 15:05:02 rx [11061395.862542] RDX: 0000000062177c30 RSI: 000000000000231c RDI: ffff9874ad283a60 Jul 26 15:05:02 rx [11061395.869933] RBP: ffffb75d40003e20 R08: 0000000000000000 R09: ffff987605e20aa8 Jul 26 15:05:02 rx [11061395.877318] R10: ffffb75d40003f00 R11: ffffb75d4460f740 R12: ffff9874ad283900 Jul 26 15:05:02 rx [11061395.884710] R13: ffff9874ad283a60 R14: ffff9874ad283980 R15: ffff9874ad283d30 Jul 26 15:05:02 rx [11061395.892095] FS: 00007f1ef4a2e700(0000) GS:ffff987605e00000(0000) knlGS:0000000000000000 Jul 26 15:05:02 rx [11061395.900438] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Jul 26 15:05:02 rx [11061395.906435] CR2: 0000000000000020 CR3: 0000003e450ba003 CR4: 0000000000760ef0 Jul 26 15:05:02 rx [11061395.913822] PKRU: 55555554 Jul 26 15:05:02 rx [11061395.916786] Call Trace: Jul 26 15:05:02 rx [11061395.919488] Jul 26 15:05:02 rx [11061395.921765] ? show_regs.cold+0x1a/0x1f Jul 26 15:05:02 rx [11061395.925859] ? __die+0x90/0xd9 Jul 26 15:05:02 rx [11061395.929169] ? no_context+0x196/0x380 Jul 26 15:05:02 rx [11061395.933088] ? ip6_protocol_deliver_rcu+0x4e0/0x4e0 Jul 26 15:05:02 rx [11061395.938216] ? ip6_sublist_rcv_finish+0x3d/0x50 Jul 26 15:05:02 rx [11061395.943000] ? __bad_area_nosemaphore+0x50/0x1a0 Jul 26 15:05:02 rx [11061395.947873] ? bad_area_nosemaphore+0x16/0x20 Jul 26 15:05:02 rx [11061395.952486] ? do_user_addr_fault+0x267/0x450 Jul 26 15:05:02 rx [11061395.957104] ? ipv6_list_rcv+0x112/0x140 Jul 26 15:05:02 rx [11061395.961279] ? __do_page_fault+0x58/0x90 Jul 26 15:05:02 rx [11061395.965458] ? do_page_fault+0x2c/0xe0 Jul 26 15:05:02 rx [11061395.969465] ? page_fault+0x34/0x40 Jul 26 15:05:02 rx [11061395.973217] ? tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.977313] ? tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.981408] tcp_send_loss_probe+0x10b/0x220 Jul 26 15:05:02 rx [11061395.985937] tcp_write_timer_handler+0x1b4/0x240 Jul 26 15:05:02 rx [11061395.990809] tcp_write_timer+0x9e/0xe0 Jul 26 15:05:02 rx [11061395.994814] ? tcp_write_timer_handler+0x240/0x240 Jul 26 15:05:02 rx [11061395.999866] call_timer_fn+0x32/0x130 Jul 26 15:05:02 rx [11061396.003782] __run_timers.part.0+0x180/0x280 Jul 26 15:05:02 rx [11061396.008309] ? recalibrate_cpu_khz+0x10/0x10 Jul 26 15:05:02 rx [11061396.012841] ? native_x2apic_icr_write+0x30/0x30 Jul 26 15:05:02 rx [11061396.017718] ? lapic_next_even ---truncated---(CVE-2024-47684)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: netfilter: nf_reject_ipv6: fix nf_reject_ip6_tcphdr_put() syzbot reported that nf_reject_ip6_tcphdr_put() was possibly sending garbage on the four reserved tcp bits (th-\u0026gt;res1) Use skb_put_zero() to clear the whole TCP header, as done in nf_reject_ip_tcphdr_put() BUG: KMSAN: uninit-value in nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255 nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255 nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344 nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core net/core/dev.c:5661 [inline] __netif_receive_skb+0x1da/0xa00 net/core/dev.c:5775 process_backlog+0x4ad/0xa50 net/core/dev.c:6108 __napi_poll+0xe7/0x980 net/core/dev.c:6772 napi_poll net/core/dev.c:6841 [inline] net_rx_action+0xa5a/0x19b0 net/core/dev.c:6963 handle_softirqs+0x1ce/0x800 kernel/softirq.c:554 __do_softirq+0x14/0x1a kernel/softirq.c:588 do_softirq+0x9a/0x100 kernel/softirq.c:455 __local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:382 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:908 [inline] __dev_queue_xmit+0x2692/0x5610 net/core/dev.c:4450 dev_queue_xmit include/linux/netdevice.h:3105 [inline] neigh_resolve_output+0x9ca/0xae0 net/core/neighbour.c:1565 neigh_output include/net/neighbour.h:542 [inline] ip6_finish_output2+0x2347/0x2ba0 net/ipv6/ip6_output.c:141 __ip6_finish_output net/ipv6/ip6_output.c:215 [inline] ip6_finish_output+0xbb8/0x14b0 net/ipv6/ip6_output.c:226 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip6_output+0x356/0x620 net/ipv6/ip6_output.c:247 dst_output include/net/dst.h:450 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] ip6_xmit+0x1ba6/0x25d0 net/ipv6/ip6_output.c:366 inet6_csk_xmit+0x442/0x530 net/ipv6/inet6_connection_sock.c:135 __tcp_transmit_skb+0x3b07/0x4880 net/ipv4/tcp_output.c:1466 tcp_transmit_skb net/ipv4/tcp_output.c:1484 [inline] tcp_connect+0x35b6/0x7130 net/ipv4/tcp_output.c:4143 tcp_v6_connect+0x1bcc/0x1e40 net/ipv6/tcp_ipv6.c:333 __inet_stream_connect+0x2ef/0x1730 net/ipv4/af_inet.c:679 inet_stream_connect+0x6a/0xd0 net/ipv4/af_inet.c:750 __sys_connect_file net/socket.c:2061 [inline] __sys_connect+0x606/0x690 net/socket.c:2078 __do_sys_connect net/socket.c:2088 [inline] __se_sys_connect net/socket.c:2085 [inline] __x64_sys_connect+0x91/0xe0 net/socket.c:2085 x64_sys_call+0x27a5/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:43 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit was stored to memory at: nf_reject_ip6_tcphdr_put+0x60c/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:249 nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344 nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core ---truncated---(CVE-2024-47685)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: RDMA/rtrs-clt: Reset cid to con_num - 1 to stay in bounds In the function init_conns(), after the create_con() and create_cm() for loop if something fails. In the cleanup for loop after the destroy tag, we access out of bound memory because cid is set to clt_path-\u0026gt;s.con_num. This commits resets the cid to clt_path-\u0026gt;s.con_num - 1, to stay in bounds in the cleanup loop later.(CVE-2024-47695)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: drivers: media: dvb-frontends/rtl2832: fix an out-of-bounds write error Ensure index in rtl2832_pid_filter does not exceed 31 to prevent out-of-bounds access. dev-\u0026gt;filters is a 32-bit value, so set_bit and clear_bit functions should only operate on indices from 0 to 31. If index is 32, it will attempt to access a non-existent 33rd bit, leading to out-of-bounds access. Change the boundary check from index \u0026gt; 32 to index \u0026gt;= 32 to resolve this issue. [hverkuil: added fixes tag, rtl2830_pid_filter -\u0026gt; rtl2832_pid_filter in logmsg](CVE-2024-47698)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: can: bcm: Clear bo-\u0026gt;bcm_proc_read after remove_proc_entry(). syzbot reported a warning in bcm_release(). [0] The blamed change fixed another warning that is triggered when connect() is issued again for a socket whose connect()ed device has been unregistered. However, if the socket is just close()d without the 2nd connect(), the remaining bo-\u0026gt;bcm_proc_read triggers unnecessary remove_proc_entry() in bcm_release(). Let\u0026apos;s clear bo-\u0026gt;bcm_proc_read after remove_proc_entry() in bcm_notify(). [0] name \u0026apos;4986\u0026apos; WARNING: CPU: 0 PID: 5234 at fs/proc/generic.c:711 remove_proc_entry+0x2e7/0x5d0 fs/proc/generic.c:711 Modules linked in: CPU: 0 UID: 0 PID: 5234 Comm: syz-executor606 Not tainted 6.11.0-rc5-syzkaller-00178-g5517ae241919 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:remove_proc_entry+0x2e7/0x5d0 fs/proc/generic.c:711 Code: ff eb 05 e8 cb 1e 5e ff 48 8b 5c 24 10 48 c7 c7 e0 f7 aa 8e e8 2a 38 8e 09 90 48 c7 c7 60 3a 1b 8c 48 89 de e8 da 42 20 ff 90 \u0026lt;0f\u0026gt; 0b 90 90 48 8b 44 24 18 48 c7 44 24 40 0e 36 e0 45 49 c7 04 07 RSP: 0018:ffffc9000345fa20 EFLAGS: 00010246 RAX: 2a2d0aee2eb64600 RBX: ffff888032f1f548 RCX: ffff888029431e00 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffc9000345fb08 R08: ffffffff8155b2f2 R09: 1ffff1101710519a R10: dffffc0000000000 R11: ffffed101710519b R12: ffff888011d38640 R13: 0000000000000004 R14: 0000000000000000 R15: dffffc0000000000 FS: 0000000000000000(0000) GS:ffff8880b8800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fcfb52722f0 CR3: 000000000e734000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: \u0026lt;TASK\u0026gt; bcm_release+0x250/0x880 net/can/bcm.c:1578 __sock_release net/socket.c:659 [inline] sock_close+0xbc/0x240 net/socket.c:1421 __fput+0x24a/0x8a0 fs/file_table.c:422 task_work_run+0x24f/0x310 kernel/task_work.c:228 exit_task_work include/linux/task_work.h:40 [inline] do_exit+0xa2f/0x27f0 kernel/exit.c:882 do_group_exit+0x207/0x2c0 kernel/exit.c:1031 __do_sys_exit_group kernel/exit.c:1042 [inline] __se_sys_exit_group kernel/exit.c:1040 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1040 x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fcfb51ee969 Code: Unable to access opcode bytes at 0x7fcfb51ee93f. RSP: 002b:00007ffce0109ca8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007fcfb51ee969 RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000001 RBP: 00007fcfb526f3b0 R08: ffffffffffffffb8 R09: 0000555500000000 R10: 0000555500000000 R11: 0000000000000246 R12: 00007fcfb526f3b0 R13: 0000000000000000 R14: 00007fcfb5271ee0 R15: 00007fcfb51bf160 \u0026lt;/TASK\u0026gt;(CVE-2024-47709)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: sock_map: Add a cond_resched() in sock_hash_free() Several syzbot soft lockup reports all have in common sock_hash_free() If a map with a large number of buckets is destroyed, we need to yield the cpu when needed.(CVE-2024-47710)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for set_output_gamma in dcn30_set_output_transfer_func This commit adds a null check for the set_output_gamma function pointer in the dcn30_set_output_transfer_func function. Previously, set_output_gamma was being checked for nullity at line 386, but then it was being dereferenced without any nullity check at line 401. This could potentially lead to a null pointer dereference error if set_output_gamma is indeed null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a nullity check for set_output_gamma before the call to set_output_gamma at line 401. If set_output_gamma is null, we log an error message and do not call the function. This fix prevents a potential null pointer dereference error. drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:401 dcn30_set_output_transfer_func() error: we previously assumed \u0026apos;mpc-\u0026gt;funcs-\u0026gt;set_output_gamma\u0026apos; could be null (see line 386) drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c 373 bool dcn30_set_output_transfer_func(struct dc *dc, 374 struct pipe_ctx *pipe_ctx, 375 const struct dc_stream_state *stream) 376 { 377 int mpcc_id = pipe_ctx-\u0026gt;plane_res.hubp-\u0026gt;inst; 378 struct mpc *mpc = pipe_ctx-\u0026gt;stream_res.opp-\u0026gt;ctx-\u0026gt;dc-\u0026gt;res_pool-\u0026gt;mpc; 379 const struct pwl_params *params = NULL; 380 bool ret = false; 381 382 /* program OGAM or 3DLUT only for the top pipe*/ 383 if (pipe_ctx-\u0026gt;top_pipe == NULL) { 384 /*program rmu shaper and 3dlut in MPC*/ 385 ret = dcn30_set_mpc_shaper_3dlut(pipe_ctx, stream); 386 if (ret == false \u0026amp;\u0026amp; mpc-\u0026gt;funcs-\u0026gt;set_output_gamma) { ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ If this is NULL 387 if (stream-\u0026gt;out_transfer_func.type == TF_TYPE_HWPWL) 388 params = \u0026amp;stream-\u0026gt;out_transfer_func.pwl; 389 else if (pipe_ctx-\u0026gt;stream-\u0026gt;out_transfer_func.type == 390 TF_TYPE_DISTRIBUTED_POINTS \u0026amp;\u0026amp; 391 cm3_helper_translate_curve_to_hw_format( 392 \u0026amp;stream-\u0026gt;out_transfer_func, 393 \u0026amp;mpc-\u0026gt;blender_params, false)) 394 params = \u0026amp;mpc-\u0026gt;blender_params; 395 /* there are no ROM LUTs in OUTGAM */ 396 if (stream-\u0026gt;out_transfer_func.type == TF_TYPE_PREDEFINED) 397 BREAK_TO_DEBUGGER(); 398 } 399 } 400 --\u0026gt; 401 mpc-\u0026gt;funcs-\u0026gt;set_output_gamma(mpc, mpcc_id, params); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Then it will crash 402 return ret; 403 }(CVE-2024-47720)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: nfsd: call cache_put if xdr_reserve_space returns NULL If not enough buffer space available, but idmap_lookup has triggered lookup_fn which calls cache_get and returns successfully. Then we missed to call cache_put here which pairs with cache_get. Reviwed-by: Jeff Layton \u0026lt;jlayton@kernel.org\u0026gt;(CVE-2024-47737)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential oob read in nilfs_btree_check_delete() The function nilfs_btree_check_delete(), which checks whether degeneration to direct mapping occurs before deleting a b-tree entry, causes memory access outside the block buffer when retrieving the maximum key if the root node has no entries. This does not usually happen because b-tree mappings with 0 child nodes are never created by mkfs.nilfs2 or nilfs2 itself. However, it can happen if the b-tree root node read from a device is configured that way, so fix this potential issue by adding a check for that case.(CVE-2024-47757)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: tracing/timerlat: Fix a race during cpuhp processing There is another found exception that the \u0026quot;timerlat/1\u0026quot; thread was scheduled on CPU0, and lead to timer corruption finally: ``` ODEBUG: init active (active state 0) object: ffff888237c2e108 object type: hrtimer hint: timerlat_irq+0x0/0x220 WARNING: CPU: 0 PID: 426 at lib/debugobjects.c:518 debug_print_object+0x7d/0xb0 Modules linked in: CPU: 0 UID: 0 PID: 426 Comm: timerlat/1 Not tainted 6.11.0-rc7+ #45 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:debug_print_object+0x7d/0xb0 ... Call Trace: \u0026lt;TASK\u0026gt; ? __warn+0x7c/0x110 ? debug_print_object+0x7d/0xb0 ? report_bug+0xf1/0x1d0 ? prb_read_valid+0x17/0x20 ? handle_bug+0x3f/0x70 ? exc_invalid_op+0x13/0x60 ? asm_exc_invalid_op+0x16/0x20 ? debug_print_object+0x7d/0xb0 ? debug_print_object+0x7d/0xb0 ? __pfx_timerlat_irq+0x10/0x10 __debug_object_init+0x110/0x150 hrtimer_init+0x1d/0x60 timerlat_main+0xab/0x2d0 ? __pfx_timerlat_main+0x10/0x10 kthread+0xb7/0xe0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 \u0026lt;/TASK\u0026gt; ``` After tracing the scheduling event, it was discovered that the migration of the \u0026quot;timerlat/1\u0026quot; thread was performed during thread creation. Further analysis confirmed that it is because the CPU online processing for osnoise is implemented through workers, which is asynchronous with the offline processing. When the worker was scheduled to create a thread, the CPU may has already been removed from the cpu_online_mask during the offline process, resulting in the inability to select the right CPU: T1 | T2 [CPUHP_ONLINE] | cpu_device_down() osnoise_hotplug_workfn() | | cpus_write_lock() | takedown_cpu(1) | cpus_write_unlock() [CPUHP_OFFLINE] | cpus_read_lock() | start_kthread(1) | cpus_read_unlock() | To fix this, skip online processing if the CPU is already offline.(CVE-2024-49866)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: btrfs: wait for fixup workers before stopping cleaner kthread during umount During unmount, at close_ctree(), we have the following steps in this order: 1) Park the cleaner kthread - this doesn\u0026apos;t destroy the kthread, it basically halts its execution (wake ups against it work but do nothing); 2) We stop the cleaner kthread - this results in freeing the respective struct task_struct; 3) We call btrfs_stop_all_workers() which waits for any jobs running in all the work queues and then free the work queues. Syzbot reported a case where a fixup worker resulted in a crash when doing a delayed iput on its inode while attempting to wake up the cleaner at btrfs_add_delayed_iput(), because the task_struct of the cleaner kthread was already freed. This can happen during unmount because we don\u0026apos;t wait for any fixup workers still running before we call kthread_stop() against the cleaner kthread, which stops and free all its resources. Fix this by waiting for any fixup workers at close_ctree() before we call kthread_stop() against the cleaner and run pending delayed iputs. The stack traces reported by syzbot were the following: BUG: KASAN: slab-use-after-free in __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065 Read of size 8 at addr ffff8880272a8a18 by task kworker/u8:3/52 CPU: 1 UID: 0 PID: 52 Comm: kworker/u8:3 Not tainted 6.12.0-rc1-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Workqueue: btrfs-fixup btrfs_work_helper Call Trace: \u0026lt;TASK\u0026gt; __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0xd5/0x120 kernel/locking/spinlock.c:162 class_raw_spinlock_irqsave_constructor include/linux/spinlock.h:551 [inline] try_to_wake_up+0xb0/0x1480 kernel/sched/core.c:4154 btrfs_writepage_fixup_worker+0xc16/0xdf0 fs/btrfs/inode.c:2842 btrfs_work_helper+0x390/0xc50 fs/btrfs/async-thread.c:314 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa63/0x1850 kernel/workqueue.c:3310 worker_thread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 \u0026lt;/TASK\u0026gt; Allocated by task 2: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:319 [inline] __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:345 kasan_slab_alloc include/linux/kasan.h:247 [inline] slab_post_alloc_hook mm/slub.c:4086 [inline] slab_alloc_node mm/slub.c:4135 [inline] kmem_cache_alloc_node_noprof+0x16b/0x320 mm/slub.c:4187 alloc_task_struct_node kernel/fork.c:180 [inline] dup_task_struct+0x57/0x8c0 kernel/fork.c:1107 copy_process+0x5d1/0x3d50 kernel/fork.c:2206 kernel_clone+0x223/0x880 kernel/fork.c:2787 kernel_thread+0x1bc/0x240 kernel/fork.c:2849 create_kthread kernel/kthread.c:412 [inline] kthreadd+0x60d/0x810 kernel/kthread.c:765 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Freed by task 61: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:230 [inline] slab_free_h ---truncated---(CVE-2024-49867)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: btrfs: fix a NULL pointer dereference when failed to start a new trasacntion [BUG] Syzbot reported a NULL pointer dereference with the following crash: FAULT_INJECTION: forcing a failure. start_transaction+0x830/0x1670 fs/btrfs/transaction.c:676 prepare_to_relocate+0x31f/0x4c0 fs/btrfs/relocation.c:3642 relocate_block_group+0x169/0xd20 fs/btrfs/relocation.c:3678 ... BTRFS info (device loop0): balance: ended with status: -12 Oops: general protection fault, probably for non-canonical address 0xdffffc00000000cc: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000660-0x0000000000000667] RIP: 0010:btrfs_update_reloc_root+0x362/0xa80 fs/btrfs/relocation.c:926 Call Trace: \u0026lt;TASK\u0026gt; commit_fs_roots+0x2ee/0x720 fs/btrfs/transaction.c:1496 btrfs_commit_transaction+0xfaf/0x3740 fs/btrfs/transaction.c:2430 del_balance_item fs/btrfs/volumes.c:3678 [inline] reset_balance_state+0x25e/0x3c0 fs/btrfs/volumes.c:3742 btrfs_balance+0xead/0x10c0 fs/btrfs/volumes.c:4574 btrfs_ioctl_balance+0x493/0x7c0 fs/btrfs/ioctl.c:3673 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f [CAUSE] The allocation failure happens at the start_transaction() inside prepare_to_relocate(), and during the error handling we call unset_reloc_control(), which makes fs_info-\u0026gt;balance_ctl to be NULL. Then we continue the error path cleanup in btrfs_balance() by calling reset_balance_state() which will call del_balance_item() to fully delete the balance item in the root tree. However during the small window between set_reloc_contrl() and unset_reloc_control(), we can have a subvolume tree update and created a reloc_root for that subvolume. Then we go into the final btrfs_commit_transaction() of del_balance_item(), and into btrfs_update_reloc_root() inside commit_fs_roots(). That function checks if fs_info-\u0026gt;reloc_ctl is in the merge_reloc_tree stage, but since fs_info-\u0026gt;reloc_ctl is NULL, it results a NULL pointer dereference. [FIX] Just add extra check on fs_info-\u0026gt;reloc_ctl inside btrfs_update_reloc_root(), before checking fs_info-\u0026gt;reloc_ctl-\u0026gt;merge_reloc_tree. That DEAD_RELOC_TREE handling is to prevent further modification to the reloc tree during merge stage, but since there is no reloc_ctl at all, we do not need to bother that.(CVE-2024-49868)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: nfsd: map the EBADMSG to nfserr_io to avoid warning Ext4 will throw -EBADMSG through ext4_readdir when a checksum error occurs, resulting in the following WARNING. Fix it by mapping EBADMSG to nfserr_io. nfsd_buffered_readdir iterate_dir // -EBADMSG -74 ext4_readdir // .iterate_shared ext4_dx_readdir ext4_htree_fill_tree htree_dirblock_to_tree ext4_read_dirblock __ext4_read_dirblock ext4_dirblock_csum_verify warn_no_space_for_csum __warn_no_space_for_csum return ERR_PTR(-EFSBADCRC) // -EBADMSG -74 nfserrno // WARNING [ 161.115610] ------------[ cut here ]------------ [ 161.116465] nfsd: non-standard errno: -74 [ 161.117315] WARNING: CPU: 1 PID: 780 at fs/nfsd/nfsproc.c:878 nfserrno+0x9d/0xd0 [ 161.118596] Modules linked in: [ 161.119243] CPU: 1 PID: 780 Comm: nfsd Not tainted 5.10.0-00014-g79679361fd5d #138 [ 161.120684] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qe mu.org 04/01/2014 [ 161.123601] RIP: 0010:nfserrno+0x9d/0xd0 [ 161.124676] Code: 0f 87 da 30 dd 00 83 e3 01 b8 00 00 00 05 75 d7 44 89 ee 48 c7 c7 c0 57 24 98 89 44 24 04 c6 05 ce 2b 61 03 01 e8 99 20 d8 00 \u0026lt;0f\u0026gt; 0b 8b 44 24 04 eb b5 4c 89 e6 48 c7 c7 a0 6d a4 99 e8 cc 15 33 [ 161.127797] RSP: 0018:ffffc90000e2f9c0 EFLAGS: 00010286 [ 161.128794] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 161.130089] RDX: 1ffff1103ee16f6d RSI: 0000000000000008 RDI: fffff520001c5f2a [ 161.131379] RBP: 0000000000000022 R08: 0000000000000001 R09: ffff8881f70c1827 [ 161.132664] R10: ffffed103ee18304 R11: 0000000000000001 R12: 0000000000000021 [ 161.133949] R13: 00000000ffffffb6 R14: ffff8881317c0000 R15: ffffc90000e2fbd8 [ 161.135244] FS: 0000000000000000(0000) GS:ffff8881f7080000(0000) knlGS:0000000000000000 [ 161.136695] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 161.137761] CR2: 00007fcaad70b348 CR3: 0000000144256006 CR4: 0000000000770ee0 [ 161.139041] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 161.140291] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 161.141519] PKRU: 55555554 [ 161.142076] Call Trace: [ 161.142575] ? __warn+0x9b/0x140 [ 161.143229] ? nfserrno+0x9d/0xd0 [ 161.143872] ? report_bug+0x125/0x150 [ 161.144595] ? handle_bug+0x41/0x90 [ 161.145284] ? exc_invalid_op+0x14/0x70 [ 161.146009] ? asm_exc_invalid_op+0x12/0x20 [ 161.146816] ? nfserrno+0x9d/0xd0 [ 161.147487] nfsd_buffered_readdir+0x28b/0x2b0 [ 161.148333] ? nfsd4_encode_dirent_fattr+0x380/0x380 [ 161.149258] ? nfsd_buffered_filldir+0xf0/0xf0 [ 161.150093] ? wait_for_concurrent_writes+0x170/0x170 [ 161.151004] ? generic_file_llseek_size+0x48/0x160 [ 161.151895] nfsd_readdir+0x132/0x190 [ 161.152606] ? nfsd4_encode_dirent_fattr+0x380/0x380 [ 161.153516] ? nfsd_unlink+0x380/0x380 [ 161.154256] ? override_creds+0x45/0x60 [ 161.155006] nfsd4_encode_readdir+0x21a/0x3d0 [ 161.155850] ? nfsd4_encode_readlink+0x210/0x210 [ 161.156731] ? write_bytes_to_xdr_buf+0x97/0xe0 [ 161.157598] ? __write_bytes_to_xdr_buf+0xd0/0xd0 [ 161.158494] ? lock_downgrade+0x90/0x90 [ 161.159232] ? nfs4svc_decode_voidarg+0x10/0x10 [ 161.160092] nfsd4_encode_operation+0x15a/0x440 [ 161.160959] nfsd4_proc_compound+0x718/0xe90 [ 161.161818] nfsd_dispatch+0x18e/0x2c0 [ 161.162586] svc_process_common+0x786/0xc50 [ 161.163403] ? nfsd_svc+0x380/0x380 [ 161.164137] ? svc_printk+0x160/0x160 [ 161.164846] ? svc_xprt_do_enqueue.part.0+0x365/0x380 [ 161.165808] ? nfsd_svc+0x380/0x380 [ 161.166523] ? rcu_is_watching+0x23/0x40 [ 161.167309] svc_process+0x1a5/0x200 [ 161.168019] nfsd+0x1f5/0x380 [ 161.168663] ? nfsd_shutdown_threads+0x260/0x260 [ 161.169554] kthread+0x1c4/0x210 [ 161.170224] ? kthread_insert_work_sanity_check+0x80/0x80 [ 161.171246] ret_from_fork+0x1f/0x30(CVE-2024-49875)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in degamma hardware format translation Fixes index out of bounds issue in `cm_helper_translate_curve_to_degamma_hw_format` function. The issue could occur when the index \u0026apos;i\u0026apos; exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure \u0026apos;i\u0026apos; is within bounds before accessing the transfer function points. If \u0026apos;i\u0026apos; is out of bounds the function returns false to indicate an error. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:594 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.red\u0026apos; 1025 \u0026lt;= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:595 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.green\u0026apos; 1025 \u0026lt;= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:596 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.blue\u0026apos; 1025 \u0026lt;= s32max(CVE-2024-49894)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in DCN30 degamma hardware format translation This commit addresses a potential index out of bounds issue in the `cm3_helper_translate_curve_to_degamma_hw_format` function in the DCN30 color management module. The issue could occur when the index \u0026apos;i\u0026apos; exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure \u0026apos;i\u0026apos; is within bounds before accessing the transfer function points. If \u0026apos;i\u0026apos; is out of bounds, the function returns false to indicate an error. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:338 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.red\u0026apos; 1025 \u0026lt;= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:339 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.green\u0026apos; 1025 \u0026lt;= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:340 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.blue\u0026apos; 1025 \u0026lt;= s32max(CVE-2024-49895)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: jfs: Fix uninit-value access of new_ea in ea_buffer syzbot reports that lzo1x_1_do_compress is using uninit-value: ===================================================== BUG: KMSAN: uninit-value in lzo1x_1_do_compress+0x19f9/0x2510 lib/lzo/lzo1x_compress.c:178 ... Uninit was stored to memory at: ea_put fs/jfs/xattr.c:639 [inline] ... Local variable ea_buf created at: __jfs_setxattr+0x5d/0x1ae0 fs/jfs/xattr.c:662 __jfs_xattr_set+0xe6/0x1f0 fs/jfs/xattr.c:934 ===================================================== The reason is ea_buf-\u0026gt;new_ea is not initialized properly. Fix this by using memset to empty its content at the beginning in ea_get().(CVE-2024-49900)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: jfs: check if leafidx greater than num leaves per dmap tree syzbot report a out of bounds in dbSplit, it because dmt_leafidx greater than num leaves per dmap tree, add a checking for dmt_leafidx in dbFindLeaf. Shaggy: Modified sanity check to apply to control pages as well as leaf pages.(CVE-2024-49902)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: jfs: Fix uaf in dbFreeBits [syzbot reported] ================================================================== BUG: KASAN: slab-use-after-free in __mutex_lock_common kernel/locking/mutex.c:587 [inline] BUG: KASAN: slab-use-after-free in __mutex_lock+0xfe/0xd70 kernel/locking/mutex.c:752 Read of size 8 at addr ffff8880229254b0 by task syz-executor357/5216 CPU: 0 UID: 0 PID: 5216 Comm: syz-executor357 Not tainted 6.11.0-rc3-syzkaller-00156-gd7a5aa4b3c00 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024 Call Trace: \u0026lt;TASK\u0026gt; __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 __mutex_lock_common kernel/locking/mutex.c:587 [inline] __mutex_lock+0xfe/0xd70 kernel/locking/mutex.c:752 dbFreeBits+0x7ea/0xd90 fs/jfs/jfs_dmap.c:2390 dbFreeDmap fs/jfs/jfs_dmap.c:2089 [inline] dbFree+0x35b/0x680 fs/jfs/jfs_dmap.c:409 dbDiscardAG+0x8a9/0xa20 fs/jfs/jfs_dmap.c:1650 jfs_ioc_trim+0x433/0x670 fs/jfs/jfs_discard.c:100 jfs_ioctl+0x2d0/0x3e0 fs/jfs/ioctl.c:131 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 Freed by task 5218: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579 poison_slab_object+0xe0/0x150 mm/kasan/common.c:240 __kasan_slab_free+0x37/0x60 mm/kasan/common.c:256 kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2252 [inline] slab_free mm/slub.c:4473 [inline] kfree+0x149/0x360 mm/slub.c:4594 dbUnmount+0x11d/0x190 fs/jfs/jfs_dmap.c:278 jfs_mount_rw+0x4ac/0x6a0 fs/jfs/jfs_mount.c:247 jfs_remount+0x3d1/0x6b0 fs/jfs/super.c:454 reconfigure_super+0x445/0x880 fs/super.c:1083 vfs_cmd_reconfigure fs/fsopen.c:263 [inline] vfs_fsconfig_locked fs/fsopen.c:292 [inline] __do_sys_fsconfig fs/fsopen.c:473 [inline] __se_sys_fsconfig+0xb6e/0xf80 fs/fsopen.c:345 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f [Analysis] There are two paths (dbUnmount and jfs_ioc_trim) that generate race condition when accessing bmap, which leads to the occurrence of uaf. Use the lock s_umount to synchronize them, in order to avoid uaf caused by race condition.(CVE-2024-49903)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for function pointer in dcn20_set_output_transfer_func This commit adds a null check for the set_output_gamma function pointer in the dcn20_set_output_transfer_func function. Previously, set_output_gamma was being checked for null at line 1030, but then it was being dereferenced without any null check at line 1048. This could potentially lead to a null pointer dereference error if set_output_gamma is null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a null check for set_output_gamma before the call to set_output_gamma at line 1048.(CVE-2024-49911)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: x86/ioapic: Handle allocation failures gracefully Breno observed panics when using failslab under certain conditions during runtime: can not alloc irq_pin_list (-1,0,20) Kernel panic - not syncing: IO-APIC: failed to add irq-pin. Can not proceed panic+0x4e9/0x590 mp_irqdomain_alloc+0x9ab/0xa80 irq_domain_alloc_irqs_locked+0x25d/0x8d0 __irq_domain_alloc_irqs+0x80/0x110 mp_map_pin_to_irq+0x645/0x890 acpi_register_gsi_ioapic+0xe6/0x150 hpet_open+0x313/0x480 That\u0026apos;s a pointless panic which is a leftover of the historic IO/APIC code which panic\u0026apos;ed during early boot when the interrupt allocation failed. The only place which might justify panic is the PIT/HPET timer_check() code which tries to figure out whether the timer interrupt is delivered through the IO/APIC. But that code does not require to handle interrupt allocation failures. If the interrupt cannot be allocated then timer delivery fails and it either panics due to that or falls back to legacy mode. Cure this by removing the panic wrapper around __add_pin_to_irq_node() and making mp_irqdomain_alloc() aware of the failure condition and handle it as any other failure in this function gracefully.(CVE-2024-49927)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: jbd2: stop waiting for space when jbd2_cleanup_journal_tail() returns error In __jbd2_log_wait_for_space(), we might call jbd2_cleanup_journal_tail() to recover some journal space. But if an error occurs while executing jbd2_cleanup_journal_tail() (e.g., an EIO), we don\u0026apos;t stop waiting for free space right away, we try other branches, and if j_committing_transaction is NULL (i.e., the tid is 0), we will get the following complain: ============================================ JBD2: I/O error when updating journal superblock for sdd-8. __jbd2_log_wait_for_space: needed 256 blocks and only had 217 space available __jbd2_log_wait_for_space: no way to get more journal space in sdd-8 ------------[ cut here ]------------ WARNING: CPU: 2 PID: 139804 at fs/jbd2/checkpoint.c:109 __jbd2_log_wait_for_space+0x251/0x2e0 Modules linked in: CPU: 2 PID: 139804 Comm: kworker/u8:3 Not tainted 6.6.0+ #1 RIP: 0010:__jbd2_log_wait_for_space+0x251/0x2e0 Call Trace: \u0026lt;TASK\u0026gt; add_transaction_credits+0x5d1/0x5e0 start_this_handle+0x1ef/0x6a0 jbd2__journal_start+0x18b/0x340 ext4_dirty_inode+0x5d/0xb0 __mark_inode_dirty+0xe4/0x5d0 generic_update_time+0x60/0x70 [...] ============================================ So only if jbd2_cleanup_journal_tail() returns 1, i.e., there is nothing to clean up at the moment, continue to try to reclaim free space in other ways. Note that this fix relies on commit 6f6a6fda2945 (\u0026quot;jbd2: fix ocfs2 corrupt when updating journal superblock fails\u0026quot;) to make jbd2_cleanup_journal_tail return the correct error code.(CVE-2024-49959)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: ocfs2: cancel dqi_sync_work before freeing oinfo ocfs2_global_read_info() will initialize and schedule dqi_sync_work at the end, if error occurs after successfully reading global quota, it will trigger the following warning with CONFIG_DEBUG_OBJECTS_* enabled: ODEBUG: free active (active state 0) object: 00000000d8b0ce28 object type: timer_list hint: qsync_work_fn+0x0/0x16c This reports that there is an active delayed work when freeing oinfo in error handling, so cancel dqi_sync_work first. BTW, return status instead of -1 when .read_file_info fails.(CVE-2024-49966)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in DCN30 color transformation This commit addresses a potential index out of bounds issue in the `cm3_helper_translate_curve_to_hw_format` function in the DCN30 color management module. The issue could occur when the index \u0026apos;i\u0026apos; exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure \u0026apos;i\u0026apos; is within bounds before accessing the transfer function points. If \u0026apos;i\u0026apos; is out of bounds, the function returns false to indicate an error. drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:180 cm3_helper_translate_curve_to_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.red\u0026apos; 1025 \u0026lt;= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:181 cm3_helper_translate_curve_to_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.green\u0026apos; 1025 \u0026lt;= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:182 cm3_helper_translate_curve_to_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.blue\u0026apos; 1025 \u0026lt;= s32max(CVE-2024-49969)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: NFSD: Limit the number of concurrent async COPY operations Nothing appears to limit the number of concurrent async COPY operations that clients can start. In addition, AFAICT each async COPY can copy an unlimited number of 4MB chunks, so can run for a long time. Thus IMO async COPY can become a DoS vector. Add a restriction mechanism that bounds the number of concurrent background COPY operations. Start simple and try to be fair -- this patch implements a per-namespace limit. An async COPY request that occurs while this limit is exceeded gets NFS4ERR_DELAY. The requesting client can choose to send the request again after a delay or fall back to a traditional read/write style copy. If there is need to make the mechanism more sophisticated, we can visit that in future patches.(CVE-2024-49974)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: i2c: stm32f7: Do not prepare/unprepare clock during runtime suspend/resume In case there is any sort of clock controller attached to this I2C bus controller, for example Versaclock or even an AIC32x4 I2C codec, then an I2C transfer triggered from the clock controller clk_ops .prepare callback may trigger a deadlock on drivers/clk/clk.c prepare_lock mutex. This is because the clock controller first grabs the prepare_lock mutex and then performs the prepare operation, including its I2C access. The I2C access resumes this I2C bus controller via .runtime_resume callback, which calls clk_prepare_enable(), which attempts to grab the prepare_lock mutex again and deadlocks. Since the clock are already prepared since probe() and unprepared in remove(), use simple clk_enable()/clk_disable() calls to enable and disable the clock on runtime suspend and resume, to avoid hitting the prepare_lock mutex.(CVE-2024-49985)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: ALSA: asihpi: Fix potential OOB array access ASIHPI driver stores some values in the static array upon a response from the driver, and its index depends on the firmware. We shouldn\u0026apos;t trust it blindly. This patch adds a sanity check of the array index to fit in the array size.(CVE-2024-50007)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: scsi: fnic: Move flush_work initialization out of if block After commit 379a58caa199 (\u0026quot;scsi: fnic: Move fnic_fnic_flush_tx() to a work queue\u0026quot;), it can happen that a work item is sent to an uninitialized work queue. This may has the effect that the item being queued is never actually queued, and any further actions depending on it will not proceed. The following warning is observed while the fnic driver is loaded: kernel: WARNING: CPU: 11 PID: 0 at ../kernel/workqueue.c:1524 __queue_work+0x373/0x410 kernel: \u0026lt;IRQ\u0026gt; kernel: queue_work_on+0x3a/0x50 kernel: fnic_wq_copy_cmpl_handler+0x54a/0x730 [fnic 62fbff0c42e7fb825c60a55cde2fb91facb2ed24] kernel: fnic_isr_msix_wq_copy+0x2d/0x60 [fnic 62fbff0c42e7fb825c60a55cde2fb91facb2ed24] kernel: __handle_irq_event_percpu+0x36/0x1a0 kernel: handle_irq_event_percpu+0x30/0x70 kernel: handle_irq_event+0x34/0x60 kernel: handle_edge_irq+0x7e/0x1a0 kernel: __common_interrupt+0x3b/0xb0 kernel: common_interrupt+0x58/0xa0 kernel: \u0026lt;/IRQ\u0026gt; It has been observed that this may break the rediscovery of Fibre Channel devices after a temporary fabric failure. This patch fixes it by moving the work queue initialization out of an if block in fnic_probe().(CVE-2024-50025)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: net: do not delay dst_entries_add() in dst_release() dst_entries_add() uses per-cpu data that might be freed at netns dismantle from ip6_route_net_exit() calling dst_entries_destroy() Before ip6_route_net_exit() can be called, we release all the dsts associated with this netns, via calls to dst_release(), which waits an rcu grace period before calling dst_destroy() dst_entries_add() use in dst_destroy() is racy, because dst_entries_destroy() could have been called already. Decrementing the number of dsts must happen sooner. Notes: 1) in CONFIG_XFRM case, dst_destroy() can call dst_release_immediate(child), this might also cause UAF if the child does not have DST_NOCOUNT set. IPSEC maintainers might take a look and see how to address this. 2) There is also discussion about removing this count of dst, which might happen in future kernels.(CVE-2024-50036)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointer before dereferencing se [WHAT \u0026amp; HOW] se is null checked previously in the same function, indicating it might be null; therefore, it must be checked when used again. This fixes 1 FORWARD_NULL issue reported by Coverity.(CVE-2024-50049)",
"id": "OESA-2024-2324",
"modified": "2026-08-06T11:07:48Z",
"published": "2024-11-01T11:07:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2324"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48916"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48946"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48952"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48967"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48973"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48977"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48986"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48988"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48991"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48994"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49006"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49007"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49019"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49029"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49030"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49033"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52754"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52855"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52917"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52918"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52919"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26917"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35878"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35990"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36286"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38635"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38667"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41015"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42152"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42301"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43841"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43858"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43867"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43871"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43894"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46675"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46689"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46722"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46724"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46757"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46802"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46830"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46853"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47667"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47669"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47684"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47685"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47695"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47698"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47709"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47710"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47720"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47737"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47757"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49866"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49867"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49868"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49875"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49894"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49895"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49900"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49902"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49903"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49911"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49927"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49959"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49966"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49969"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49974"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49985"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50007"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50025"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50036"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50049"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2022-48916",
"CVE-2022-48946",
"CVE-2022-48952",
"CVE-2022-48967",
"CVE-2022-48973",
"CVE-2022-48977",
"CVE-2022-48986",
"CVE-2022-48988",
"CVE-2022-48991",
"CVE-2022-48994",
"CVE-2022-49006",
"CVE-2022-49007",
"CVE-2022-49019",
"CVE-2022-49029",
"CVE-2022-49030",
"CVE-2022-49033",
"CVE-2023-52754",
"CVE-2023-52855",
"CVE-2023-52917",
"CVE-2023-52918",
"CVE-2023-52919",
"CVE-2024-26917",
"CVE-2024-35878",
"CVE-2024-35990",
"CVE-2024-36286",
"CVE-2024-38635",
"CVE-2024-38667",
"CVE-2024-41015",
"CVE-2024-42152",
"CVE-2024-42301",
"CVE-2024-43841",
"CVE-2024-43858",
"CVE-2024-43867",
"CVE-2024-43871",
"CVE-2024-43894",
"CVE-2024-46675",
"CVE-2024-46689",
"CVE-2024-46722",
"CVE-2024-46724",
"CVE-2024-46757",
"CVE-2024-46802",
"CVE-2024-46830",
"CVE-2024-46853",
"CVE-2024-47667",
"CVE-2024-47669",
"CVE-2024-47684",
"CVE-2024-47685",
"CVE-2024-47695",
"CVE-2024-47698",
"CVE-2024-47709",
"CVE-2024-47710",
"CVE-2024-47720",
"CVE-2024-47737",
"CVE-2024-47757",
"CVE-2024-49866",
"CVE-2024-49867",
"CVE-2024-49868",
"CVE-2024-49875",
"CVE-2024-49894",
"CVE-2024-49895",
"CVE-2024-49900",
"CVE-2024-49902",
"CVE-2024-49903",
"CVE-2024-49911",
"CVE-2024-49927",
"CVE-2024-49959",
"CVE-2024-49966",
"CVE-2024-49969",
"CVE-2024-49974",
"CVE-2024-49985",
"CVE-2024-50007",
"CVE-2024-50025",
"CVE-2024-50036",
"CVE-2024-50049"
]
}
OESA-2025-1078 (CVE-2023-52887)
Vulnerability from osv_openeuler – Published: 2025-01-24 11:08 – Updated: 2026-08-06 11:08 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
net: can: j1939: enhanced error handling for tightly received RTS messages in xtp_rx_rts_session_new
This patch enhances error handling in scenarios with RTS (Request to Send) messages arriving closely. It replaces the less informative WARN_ON_ONCE backtraces with a new error handling method. This provides clearer error messages and allows for the early termination of problematic sessions. Previously, sessions were only released at the end of j1939_xtp_rx_rts().
Potentially this could be reproduced with something like: testj1939 -r vcan0:0x80 & while true; do # send first RTS cansend vcan0 18EC8090#1014000303002301; # send second RTS cansend vcan0 18EC8090#1014000303002301; # send abort cansend vcan0 18EC8090#ff00000000002301; done(CVE-2023-52887)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Fix slab-use-after-free in l2cap_connect()
Extend a critical section to prevent chan from early freeing. Also make the l2cap_connect() return type void. Nothing is using the returned value but it is ugly to return a potentially freed pointer. Making it void will help with backports because earlier kernels did use the return value. Now the compile will break for kernels where this patch is not a complete fix.
Call stack summary:
[use] l2cap_bredr_sig_cmd l2cap_connect ┌ mutex_lock(&conn->chan_lock); │ chan = pchan->ops->new_connection(pchan); <- alloc chan │ __l2cap_chan_add(conn, chan); │ l2cap_chan_hold(chan); │ list_add(&chan->list, &conn->chan_l); ... (1) └ mutex_unlock(&conn->chan_lock); chan->conf_state ... (4) <- use after free
[free] l2cap_conn_del ┌ mutex_lock(&conn->chan_lock); │ foreach chan in conn->chan_l: ... (2) │ l2cap_chan_put(chan); │ l2cap_chan_destroy │ kfree(chan) ... (3) <- chan freed └ mutex_unlock(&conn->chan_lock);
================================================================== BUG: KASAN: slab-use-after-free in instrument_atomic_read include/linux/instrumented.h:68 [inline] BUG: KASAN: slab-use-after-free in _test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline] BUG: KASAN: slab-use-after-free in l2cap_connect+0xa67/0x11a0 net/bluetooth/l2cap_core.c:4260 Read of size 8 at addr ffff88810bf040a0 by task kworker/u3:1/311(CVE-2024-36013)
In the Linux kernel, the following vulnerability has been resolved:
net: hns3: fix kernel crash when devlink reload during pf initialization
The devlink reload process will access the hardware resources, but the register operation is done before the hardware is initialized. So, processing the devlink reload during initialization may lead to kernel crash. This patch fixes this by taking devl_lock during initialization.(CVE-2024-36021)
In the Linux kernel, the following vulnerability has been resolved:
bnxt_re: avoid shift undefined behavior in bnxt_qplib_alloc_init_hwq
Undefined behavior is triggered when bnxt_qplib_alloc_init_hwq is called with hwq_attr->aux_depth != 0 and hwq_attr->aux_stride == 0. In that case, "roundup_pow_of_two(hwq_attr->aux_stride)" gets called. roundup_pow_of_two is documented as undefined for 0.
Fix it in the one caller that had this combination.
The undefined behavior was detected by UBSAN: UBSAN: shift-out-of-bounds in ./include/linux/log2.h:57:13 shift exponent 64 is too large for 64-bit type 'long unsigned int' CPU: 24 PID: 1075 Comm: (udev-worker) Not tainted 6.9.0-rc6+ #4 Hardware name: Abacus electric, s.r.o. - servis@abacus.cz Super Server/H12SSW-iN, BIOS 2.7 10/25/2023 Call Trace: <TASK> dump_stack_lvl+0x5d/0x80 ubsan_epilogue+0x5/0x30 __ubsan_handle_shift_out_of_bounds.cold+0x61/0xec __roundup_pow_of_two+0x25/0x35 [bnxt_re] bnxt_qplib_alloc_init_hwq+0xa1/0x470 [bnxt_re] bnxt_qplib_create_qp+0x19e/0x840 [bnxt_re] bnxt_re_create_qp+0x9b1/0xcd0 [bnxt_re] ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 ? __kmalloc+0x1b6/0x4f0 ? create_qp.part.0+0x128/0x1c0 [ib_core] ? __pfx_bnxt_re_create_qp+0x10/0x10 [bnxt_re] create_qp.part.0+0x128/0x1c0 [ib_core] ib_create_qp_kernel+0x50/0xd0 [ib_core] create_mad_qp+0x8e/0xe0 [ib_core] ? __pfx_qp_event_handler+0x10/0x10 [ib_core] ib_mad_init_device+0x2be/0x680 [ib_core] add_client_context+0x10d/0x1a0 [ib_core] enable_device_and_get+0xe0/0x1d0 [ib_core] ib_register_device+0x53c/0x630 [ib_core] ? srso_alias_return_thunk+0x5/0xfbef5 bnxt_re_probe+0xbd8/0xe50 [bnxt_re] ? __pfx_bnxt_re_probe+0x10/0x10 [bnxt_re] auxiliary_bus_probe+0x49/0x80 ? driver_sysfs_add+0x57/0xc0 really_probe+0xde/0x340 ? pm_runtime_barrier+0x54/0x90 ? __pfxdriverattach+0x10/0x10 driver_probe_device+0x78/0x110 driver_probe_device+0x1f/0xa0 __driver_attach+0xba/0x1c0 bus_for_each_dev+0x8f/0xe0 bus_add_driver+0x146/0x220 driver_register+0x72/0xd0 __auxiliary_driver_register+0x6e/0xd0 ? __pfx_bnxt_re_mod_init+0x10/0x10 [bnxt_re] bnxt_re_mod_init+0x3e/0xff0 [bnxt_re] ? __pfx_bnxt_re_mod_init+0x10/0x10 [bnxt_re] do_one_initcall+0x5b/0x310 do_init_module+0x90/0x250 init_module_from_file+0x86/0xc0 idempotent_init_module+0x121/0x2b0 __x64_sys_finit_module+0x5e/0xb0 do_syscall_64+0x82/0x160 ? srso_alias_return_thunk+0x5/0xfbef5 ? syscall_exit_to_user_mode_prepare+0x149/0x170 ? srso_alias_return_thunk+0x5/0xfbef5 ? syscall_exit_to_user_mode+0x75/0x230 ? srso_alias_return_thunk+0x5/0xfbef5 ? do_syscall_64+0x8e/0x160 ? srso_alias_return_thunk+0x5/0xfbef5 ? __count_memcg_events+0x69/0x100 ? srso_alias_return_thunk+0x5/0xfbef5 ? count_memcg_events.constprop.0+0x1a/0x30 ? srso_alias_return_thunk+0x5/0xfbef5 ? handle_mm_fault+0x1f0/0x300 ? srso_alias_return_thunk+0x5/0xfbef5 ? do_user_addr_fault+0x34e/0x640 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f4e5132821d Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d e3 db 0c 00 f7 d8 64 89 01 48 RSP: 002b:00007ffca9c906a8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 RAX: ffffffffffffffda RBX: 0000563ec8a8f130 RCX: 00007f4e5132821d RDX: 0000000000000000 RSI: 00007f4e518fa07d RDI: 000000000000003b RBP: 00007ffca9c90760 R08: 00007f4e513f6b20 R09: 00007ffca9c906f0 R10: 0000563ec8a8faa0 R11: 0000000000000246 R12: 00007f4e518fa07d R13: 0000000000020000 R14: 0000563ec8409e90 R15: 0000563ec8a8fa60 </TASK> ---[ end trace ]---(CVE-2024-38540)
In the Linux kernel, the following vulnerability has been resolved:
media: atomisp: ssh_css: Fix a null-pointer dereference in load_video_binaries
The allocation failure of mycs->yuv_scaler_binary in load_video_binaries() is followed with a dereference of mycs->yuv_scaler_binary after the following call chain:
sh_css_pipe_load_binaries() |-> load_video_binaries(mycs->yuv_scaler_binary == NULL) | |-> sh_css_pipe_unload_binaries() |-> unload_video_binaries()
In unload_video_binaries(), it calls to ia_css_binary_unload with argument &pipe->pipe_settings.video.yuv_scaler_binary[i], which refers to the same memory slot as mycs->yuv_scaler_binary. Thus, a null-pointer dereference is triggered.(CVE-2024-38547)
In the Linux kernel, the following vulnerability has been resolved:
um: Add winch to winch_handlers before registering winch IRQ
Registering a winch IRQ is racy, an interrupt may occur before the winch is added to the winch_handlers list.
If that happens, register_winch_irq() adds to that list a winch that is scheduled to be (or has already been) freed, causing a panic later in winch_cleanup().
Avoid the race by adding the winch to the winch_handlers list before registering the IRQ, and rolling back if um_request_irq() fails.(CVE-2024-39292)
In the Linux kernel, the following vulnerability has been resolved:
drm/shmem-helper: Fix BUG_ON() on mmap(PROT_WRITE, MAP_PRIVATE)
Lack of check for copy-on-write (COW) mapping in drm_gem_shmem_mmap allows users to call mmap with PROT_WRITE and MAP_PRIVATE flag causing a kernel panic due to BUG_ON in vmf_insert_pfn_prot: BUG_ON((vma->vm_flags & VM_PFNMAP) && is_cow_mapping(vma->vm_flags));
Return -EINVAL early if COW mapping is detected.
This bug affects all drm drivers using default shmem helpers. It can be reproduced by this simple example: void *ptr = mmap(0, size, PROT_WRITE, MAP_PRIVATE, fd, mmap_offset); ptr[0] = 0;(CVE-2024-39497)
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:
jfs: don't walk off the end of ealist
Add a check before visiting the members of ea to make sure each ea stays within the ealist.(CVE-2024-41017)
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Fix signedness bug in sdma_v4_0_process_trap_irq()
The "instance" variable needs to be signed for the error handling to work.(CVE-2024-41022)
In the Linux kernel, the following vulnerability has been resolved:
Fix userfaultfd_api to return EINVAL as expected
Currently if we request a feature that is not set in the Kernel config we fail silently and return all the available features. However, the man page indicates we should return an EINVAL.
We need to fix this issue since we can end up with a Kernel warning should a program request the feature UFFD_FEATURE_WP_UNPOPULATED on a kernel with the config not set with this feature.
[ 200.812896] WARNING: CPU: 91 PID: 13634 at mm/memory.c:1660 zap_pte_range+0x43d/0x660 [ 200.820738] Modules linked in: [ 200.869387] CPU: 91 PID: 13634 Comm: userfaultfd Kdump: loaded Not tainted 6.9.0-rc5+ #8 [ 200.877477] Hardware name: Dell Inc. PowerEdge R6525/0N7YGH, BIOS 2.7.3 03/30/2022 [ 200.885052] RIP: 0010:zap_pte_range+0x43d/0x660(CVE-2024-41027)
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:
mm: prevent derefencing NULL ptr in pfn_section_valid()
Commit 5ec8e8ea8b77 ("mm/sparsemem: fix race in accessing memory_section->usage") changed pfn_section_valid() to add a READ_ONCE() call around "ms->usage" to fix a race with section_deactivate() where ms->usage can be cleared. The READ_ONCE() call, by itself, is not enough to prevent NULL pointer dereference. We need to check its value before dereferencing it.(CVE-2024-41055)
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:
KVM: PPC: Book3S HV: Prevent UAF in kvm_spapr_tce_attach_iommu_group()
Al reported a possible use-after-free (UAF) in kvm_spapr_tce_attach_iommu_group().
It looks up stt from tablefd, but then continues to use it after doing
fdput() on the returned fd. After the fdput() the tablefd is free to be
closed by another thread. The close calls kvm_spapr_tce_release() and
then release_spapr_tce_table() (via call_rcu()) which frees stt.
Although there are calls to rcu_read_lock() in
kvm_spapr_tce_attach_iommu_group() they are not sufficient to prevent
the UAF, because stt is used outside the locked regions.
With an artifcial delay after the fdput() and a userspace program which triggers the race, KASAN detects the UAF:
BUG: KASAN: slab-use-after-free in kvm_spapr_tce_attach_iommu_group+0x298/0x720 [kvm] Read of size 4 at addr c000200027552c30 by task kvm-vfio/2505 CPU: 54 PID: 2505 Comm: kvm-vfio Not tainted 6.10.0-rc3-next-20240612-dirty #1 Hardware name: 8335-GTH POWER9 0x4e1202 opal:skiboot-v6.5.3-35-g1851b2a06 PowerNV Call Trace: dump_stack_lvl+0xb4/0x108 (unreliable) print_report+0x2b4/0x6ec kasan_report+0x118/0x2b0 __asan_load4+0xb8/0xd0 kvm_spapr_tce_attach_iommu_group+0x298/0x720 [kvm] kvm_vfio_set_attr+0x524/0xac0 [kvm] kvm_device_ioctl+0x144/0x240 [kvm] sys_ioctl+0x62c/0x1810 system_call_exception+0x190/0x440 system_call_vectored_common+0x15c/0x2ec ... Freed by task 0: ... kfree+0xec/0x3e0 release_spapr_tce_table+0xd4/0x11c [kvm] rcu_core+0x568/0x16a0 handle_softirqs+0x23c/0x920 do_softirq_own_stack+0x6c/0x90 do_softirq_own_stack+0x58/0x90 __irq_exit_rcu+0x218/0x2d0 irq_exit+0x30/0x80 arch_local_irq_restore+0x128/0x230 arch_local_irq_enable+0x1c/0x30 cpuidle_enter_state+0x134/0x5cc cpuidle_enter+0x6c/0xb0 call_cpuidle+0x7c/0x100 do_idle+0x394/0x410 cpu_startup_entry+0x60/0x70 start_secondary+0x3fc/0x410 start_secondary_prolog+0x10/0x14
Fix it by delaying the fdput() until stt is no longer in use, which
is effectively the entire function. To keep the patch minimal add a call
to fdput() at each of the existing return paths. Future work can convert
the function to goto or __cleanup style cleanup.
With the fix in place the test case no longer triggers the UAF.(CVE-2024-41070)
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:
ila: block BH in ila_output()
As explained in commit 1378817486d6 ("tipc: block BH before using dst_cache"), net/core/dst_cache.c helpers need to be called with BH disabled.
ila_output() is called from lwtunnel_output() possibly from process context, and under rcu_read_lock().
We might be interrupted by a softirq, re-enter ila_output() and corrupt dst_cache data structures.
Fix the race by using local_bh_disable().(CVE-2024-41081)
In the Linux kernel, the following vulnerability has been resolved:
drm/nouveau/dispnv04: fix null pointer dereference in nv17_tv_get_hd_modes
In nv17_tv_get_hd_modes(), the return value of drm_mode_duplicate() is assigned to mode, which will lead to a possible NULL pointer dereference on failure of drm_mode_duplicate(). The same applies to drm_cvt_mode(). Add a check to avoid null pointer dereference.(CVE-2024-41089)
In the Linux kernel, the following vulnerability has been resolved:
drm/nouveau/dispnv04: fix null pointer dereference in nv17_tv_get_ld_modes
In nv17_tv_get_ld_modes(), the return value of drm_mode_duplicate() is assigned to mode, which will lead to a possible NULL pointer dereference on failure of drm_mode_duplicate(). Add a check to avoid npd.(CVE-2024-41095)
In the Linux kernel, the following vulnerability has been resolved:
usb: atm: cxacru: fix endpoint checking in cxacru_bind()
Syzbot is still reporting quite an old issue [1] that occurs due to incomplete checking of present usb endpoints. As such, wrong endpoints types may be used at urb sumbitting stage which in turn triggers a warning in usb_submit_urb().
Fix the issue by verifying that required endpoint types are present for both in and out endpoints, taking into account cmd endpoint type.
Unfortunately, this patch has not been tested on real hardware.
[1] Syzbot report: usb 1-1: BOGUS urb xfer, pipe 1 != type 3 WARNING: CPU: 0 PID: 8667 at drivers/usb/core/urb.c:502 usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502 Modules linked in: CPU: 0 PID: 8667 Comm: kworker/0:4 Not tainted 5.14.0-rc4-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: usb_hub_wq hub_event RIP: 0010:usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502 ... Call Trace: cxacru_cm+0x3c0/0x8e0 drivers/usb/atm/cxacru.c:649 cxacru_card_status+0x22/0xd0 drivers/usb/atm/cxacru.c:760 cxacru_bind+0x7ac/0x11a0 drivers/usb/atm/cxacru.c:1209 usbatm_usb_probe+0x321/0x1ae0 drivers/usb/atm/usbatm.c:1055 cxacru_usb_probe+0xdf/0x1e0 drivers/usb/atm/cxacru.c:1363 usb_probe_interface+0x315/0x7f0 drivers/usb/core/driver.c:396 call_driver_probe drivers/base/dd.c:517 [inline] really_probe+0x23c/0xcd0 drivers/base/dd.c:595 __driver_probe_device+0x338/0x4d0 drivers/base/dd.c:747 driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:777 __device_attach_driver+0x20b/0x2f0 drivers/base/dd.c:894 bus_for_each_drv+0x15f/0x1e0 drivers/base/bus.c:427 __device_attach+0x228/0x4a0 drivers/base/dd.c:965 bus_probe_device+0x1e4/0x290 drivers/base/bus.c:487 device_add+0xc2f/0x2180 drivers/base/core.c:3354 usb_set_configuration+0x113a/0x1910 drivers/usb/core/message.c:2170 usb_generic_driver_probe+0xba/0x100 drivers/usb/core/generic.c:238 usb_probe_device+0xd9/0x2c0 drivers/usb/core/driver.c:293(CVE-2024-41097)
In the Linux kernel, the following vulnerability has been resolved:
net: can: j1939: Initialize unused data in j1939_send_one()
syzbot reported kernel-infoleak in raw_recvmsg() [1]. j1939_send_one() creates full frame including unused data, but it doesn't initialize it. This causes the kernel-infoleak issue. Fix this by initializing unused data.
[1] BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline] BUG: KMSAN: kernel-infoleak in copy_to_user_iter lib/iov_iter.c:24 [inline] BUG: KMSAN: kernel-infoleak in iterate_ubuf include/linux/iov_iter.h:29 [inline] BUG: KMSAN: kernel-infoleak in iterate_and_advance2 include/linux/iov_iter.h:245 [inline] BUG: KMSAN: kernel-infoleak in iterate_and_advance include/linux/iov_iter.h:271 [inline] BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185 instrument_copy_to_user include/linux/instrumented.h:114 [inline] copy_to_user_iter lib/iov_iter.c:24 [inline] iterate_ubuf include/linux/iov_iter.h:29 [inline] iterate_and_advance2 include/linux/iov_iter.h:245 [inline] iterate_and_advance include/linux/iov_iter.h:271 [inline] _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185 copy_to_iter include/linux/uio.h:196 [inline] memcpy_to_msg include/linux/skbuff.h:4113 [inline] raw_recvmsg+0x2b8/0x9e0 net/can/raw.c:1008 sock_recvmsg_nosec net/socket.c:1046 [inline] sock_recvmsg+0x2c4/0x340 net/socket.c:1068 _sysrecvmsg+0x18a/0x620 net/socket.c:2803 _sys_recvmsg+0x223/0x840 net/socket.c:2845 do_recvmmsg+0x4fc/0xfd0 net/socket.c:2939 __sys_recvmmsg net/socket.c:3018 [inline] __do_sys_recvmmsg net/socket.c:3041 [inline] __se_sys_recvmmsg net/socket.c:3034 [inline] __x64_sys_recvmmsg+0x397/0x490 net/socket.c:3034 x64_sys_call+0xf6c/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:300 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:3804 [inline] slab_alloc_node mm/slub.c:3845 [inline] kmem_cache_alloc_node+0x613/0xc50 mm/slub.c:3888 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:577 __alloc_skb+0x35b/0x7a0 net/core/skbuff.c:668 alloc_skb include/linux/skbuff.h:1313 [inline] alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6504 sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2795 sock_alloc_send_skb include/net/sock.h:1842 [inline] j1939_sk_alloc_skb net/can/j1939/socket.c:878 [inline] j1939_sk_send_loop net/can/j1939/socket.c:1142 [inline] j1939_sk_sendmsg+0xc0a/0x2730 net/can/j1939/socket.c:1277 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:745 _syssendmsg+0x877/0xb60 net/socket.c:2584 _sys_sendmsg+0x28d/0x3c0 net/socket.c:2638 __sys_sendmsg net/socket.c:2667 [inline] __do_sys_sendmsg net/socket.c:2676 [inline] __se_sys_sendmsg net/socket.c:2674 [inline] __x64_sys_sendmsg+0x307/0x4a0 net/socket.c:2674 x64_sys_call+0xc4b/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Bytes 12-15 of 16 are uninitialized Memory access of size 16 starts at ffff888120969690 Data copied to user address 00000000200017c0
CPU: 1 PID: 5050 Comm: syz-executor198 Not tainted 6.9.0-rc5-syzkaller-00031-g71b1543c83d6 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024(CVE-2024-42076)
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: fix DIO failure due to insufficient transaction credits
The code in ocfs2_dio_end_io_write() estimates number of necessary transaction credits using ocfs2_calc_extend_credits(). This however does not take into account that the IO could be arbitrarily large and can contain arbitrary number of extents.
Extent tree manipulations do often extend the current transaction but not in all of the cases. For example if we have only single block extents in the tree, ocfs2_mark_extent_written() will end up calling ocfs2_replace_extent_rec() all the time and we will never extend the current transaction and eventually exhaust all the transaction credits if the IO contains many single block extents. Once that happens a WARN_ON(jbd2_handle_buffer_credits(handle) <= 0) is triggered in jbd2_journal_dirty_metadata() and subsequently OCFS2 aborts in response to this error. This was actually triggered by one of our customers on a heavily fragmented OCFS2 filesystem.
To fix the issue make sure the transaction always has enough credits for one extent insert before each call of ocfs2_mark_extent_written().
Heming Zhao said:
PANIC: "Kernel panic - not syncing: OCFS2: (device dm-1): panic forced after error"
PID: xxx TASK: xxxx CPU: 5 COMMAND: "SubmitThread-CA" #0 machine_kexec at ffffffff8c069932 #1 __crash_kexec at ffffffff8c1338fa #2 panic at ffffffff8c1d69b9 #3 ocfs2_handle_error at ffffffffc0c86c0c [ocfs2] #4 __ocfs2_abort at ffffffffc0c88387 [ocfs2] #5 ocfs2_journal_dirty at ffffffffc0c51e98 [ocfs2] #6 ocfs2_split_extent at ffffffffc0c27ea3 [ocfs2] #7 ocfs2_change_extent_flag at ffffffffc0c28053 [ocfs2] #8 ocfs2_mark_extent_written at ffffffffc0c28347 [ocfs2] #9 ocfs2_dio_end_io_write at ffffffffc0c2bef9 [ocfs2]
10 ocfs2_dio_end_io at ffffffffc0c2c0f5 [ocfs2]
11 dio_complete at ffffffff8c2b9fa7
12 do_blockdev_direct_IO at ffffffff8c2bc09f
13 ocfs2_direct_IO at ffffffffc0c2b653 [ocfs2]
14 generic_file_direct_write at ffffffff8c1dcf14
15 __generic_file_write_iter at ffffffff8c1dd07b
16 ocfs2_file_write_iter at ffffffffc0c49f1f [ocfs2]
17 aio_write at ffffffff8c2cc72e
18 kmem_cache_alloc at ffffffff8c248dde
19 do_io_submit at ffffffff8c2ccada
20 do_syscall_64 at ffffffff8c004984
21 entry_SYSCALL_64_after_hwframe at ffffffff8c8000ba(CVE-2024-42077)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/restrack: Fix potential invalid address access
struct rdma_restrack_entry's kern_name was set to KBUILD_MODNAME in ib_create_cq(), while if the module exited but forgot del this rdma_restrack_entry, it would cause a invalid address access in rdma_restrack_clean() when print the owner of this rdma_restrack_entry.
These code is used to help find one forgotten PD release in one of the ULPs. But it is not needed anymore, so delete them.(CVE-2024-42080)
In the Linux kernel, the following vulnerability has been resolved:
xdp: Remove WARN() from __xdp_reg_mem_model()
syzkaller reports a warning in __xdp_reg_mem_model().
The warning occurs only if __mem_id_init_hash_table() returns an error. It returns the error in two cases:
- memory allocation fails;
- rhashtable_init() fails when some fields of rhashtable_params struct are not initialized properly.
The second case cannot happen since there is a static const rhashtable_params struct with valid fields. So, warning is only triggered when there is a problem with memory allocation.
Thus, there is no sense in using WARN() to handle this error and it can be safely removed.
WARNING: CPU: 0 PID: 5065 at net/core/xdp.c:299 __xdp_reg_mem_model+0x2d9/0x650 net/core/xdp.c:299
CPU: 0 PID: 5065 Comm: syz-executor883 Not tainted 6.8.0-syzkaller-05271-gf99c5f563c17 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 RIP: 0010:__xdp_reg_mem_model+0x2d9/0x650 net/core/xdp.c:299
Call Trace: xdp_reg_mem_model+0x22/0x40 net/core/xdp.c:344 xdp_test_run_setup net/bpf/test_run.c:188 [inline] bpf_test_run_xdp_live+0x365/0x1e90 net/bpf/test_run.c:377 bpf_prog_test_run_xdp+0x813/0x11b0 net/bpf/test_run.c:1267 bpf_prog_test_run+0x33a/0x3b0 kernel/bpf/syscall.c:4240 __sys_bpf+0x48d/0x810 kernel/bpf/syscall.c:5649 __do_sys_bpf kernel/bpf/syscall.c:5738 [inline] __se_sys_bpf kernel/bpf/syscall.c:5736 [inline] __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:5736 do_syscall_64+0xfb/0x240 entry_SYSCALL_64_after_hwframe+0x6d/0x75
Found by Linux Verification Center (linuxtesting.org) with syzkaller.(CVE-2024-42082)
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:
pinctrl: fix deadlock in create_pinctrl() when handling -EPROBE_DEFER
In create_pinctrl(), pinctrl_maps_mutex is acquired before calling add_setting(). If add_setting() returns -EPROBE_DEFER, create_pinctrl() calls pinctrl_free(). However, pinctrl_free() attempts to acquire pinctrl_maps_mutex, which is already held by create_pinctrl(), leading to a potential deadlock.
This patch resolves the issue by releasing pinctrl_maps_mutex before calling pinctrl_free(), preventing the deadlock.
This bug was discovered and resolved using Coverity Static Analysis Security Testing (SAST) by Synopsys, Inc.(CVE-2024-42090)
In the Linux kernel, the following vulnerability has been resolved:
gpio: davinci: Validate the obtained number of IRQs
Value of pdata->gpio_unbanked is taken from Device Tree. In case of broken DT due to any error this value can be any. Without this value validation there can be out of chips->irqs array boundaries access in davinci_gpio_probe().
Validate the obtained nirq value so that it won't exceed the maximum number of IRQs per bank.
Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-42092)
In the Linux kernel, the following vulnerability has been resolved:
net/dpaa2: Avoid explicit cpumask var allocation on stack
For CONFIG_CPUMASK_OFFSTACK=y kernel, explicit allocation of cpumask variable on stack is not recommended since it can cause potential stack overflow.
Instead, kernel code should always use *cpumask_var API(s) to allocate cpumask var in config-neutral way, leaving allocation strategy to CONFIG_CPUMASK_OFFSTACK.
Use *cpumask_var API(s) to address it.(CVE-2024-42093)
In the Linux kernel, the following vulnerability has been resolved:
net/iucv: Avoid explicit cpumask var allocation on stack
For CONFIG_CPUMASK_OFFSTACK=y kernel, explicit allocation of cpumask variable on stack is not recommended since it can cause potential stack overflow.
Instead, kernel code should always use *cpumask_var API(s) to allocate cpumask var in config-neutral way, leaving allocation strategy to CONFIG_CPUMASK_OFFSTACK.
Use *cpumask_var API(s) to address it.(CVE-2024-42094)
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:
inet_diag: Initialize pad field in struct inet_diag_req_v2
KMSAN reported uninit-value access in raw_lookup() [1]. Diag for raw sockets uses the pad field in struct inet_diag_req_v2 for the underlying protocol. This field corresponds to the sdiag_raw_protocol field in struct inet_diag_req_raw.
inet_diag_get_exact_compat() converts inet_diag_req to inet_diag_req_v2, but leaves the pad field uninitialized. So the issue occurs when raw_lookup() accesses the sdiag_raw_protocol field.
Fix this by initializing the pad field in inet_diag_get_exact_compat(). Also, do the same fix in inet_diag_dump_compat() to avoid the similar issue in the future.
[1] BUG: KMSAN: uninit-value in raw_lookup net/ipv4/raw_diag.c:49 [inline] BUG: KMSAN: uninit-value in raw_sock_get+0x657/0x800 net/ipv4/raw_diag.c:71 raw_lookup net/ipv4/raw_diag.c:49 [inline] raw_sock_get+0x657/0x800 net/ipv4/raw_diag.c:71 raw_diag_dump_one+0xa1/0x660 net/ipv4/raw_diag.c:99 inet_diag_cmd_exact+0x7d9/0x980 inet_diag_get_exact_compat net/ipv4/inet_diag.c:1404 [inline] inet_diag_rcv_msg_compat+0x469/0x530 net/ipv4/inet_diag.c:1426 sock_diag_rcv_msg+0x23d/0x740 net/core/sock_diag.c:282 netlink_rcv_skb+0x537/0x670 net/netlink/af_netlink.c:2564 sock_diag_rcv+0x35/0x40 net/core/sock_diag.c:297 netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline] netlink_unicast+0xe74/0x1240 net/netlink/af_netlink.c:1361 netlink_sendmsg+0x10c6/0x1260 net/netlink/af_netlink.c:1905 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x332/0x3d0 net/socket.c:745 _syssendmsg+0x7f0/0xb70 net/socket.c:2585 _sys_sendmsg+0x271/0x3b0 net/socket.c:2639 __sys_sendmsg net/socket.c:2668 [inline] __do_sys_sendmsg net/socket.c:2677 [inline] __se_sys_sendmsg net/socket.c:2675 [inline] __x64_sys_sendmsg+0x27e/0x4a0 net/socket.c:2675 x64_sys_call+0x135e/0x3ce0 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xd9/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Uninit was stored to memory at: raw_sock_get+0x650/0x800 net/ipv4/raw_diag.c:71 raw_diag_dump_one+0xa1/0x660 net/ipv4/raw_diag.c:99 inet_diag_cmd_exact+0x7d9/0x980 inet_diag_get_exact_compat net/ipv4/inet_diag.c:1404 [inline] inet_diag_rcv_msg_compat+0x469/0x530 net/ipv4/inet_diag.c:1426 sock_diag_rcv_msg+0x23d/0x740 net/core/sock_diag.c:282 netlink_rcv_skb+0x537/0x670 net/netlink/af_netlink.c:2564 sock_diag_rcv+0x35/0x40 net/core/sock_diag.c:297 netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline] netlink_unicast+0xe74/0x1240 net/netlink/af_netlink.c:1361 netlink_sendmsg+0x10c6/0x1260 net/netlink/af_netlink.c:1905 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x332/0x3d0 net/socket.c:745 _syssendmsg+0x7f0/0xb70 net/socket.c:2585 _sys_sendmsg+0x271/0x3b0 net/socket.c:2639 __sys_sendmsg net/socket.c:2668 [inline] __do_sys_sendmsg net/socket.c:2677 [inline] __se_sys_sendmsg net/socket.c:2675 [inline] __x64_sys_sendmsg+0x27e/0x4a0 net/socket.c:2675 x64_sys_call+0x135e/0x3ce0 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xd9/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Local variable req.i created at: inet_diag_get_exact_compat net/ipv4/inet_diag.c:1396 [inline] inet_diag_rcv_msg_compat+0x2a6/0x530 net/ipv4/inet_diag.c:1426 sock_diag_rcv_msg+0x23d/0x740 net/core/sock_diag.c:282
CPU: 1 PID: 8888 Comm: syz-executor.6 Not tainted 6.10.0-rc4-00217-g35bb670d65fc #32 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014(CVE-2024-42106)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Skip finding free audio for unknown engine_id
[WHY] ENGINE_ID_UNKNOWN = -1 and can not be used as an array index. Plus, it also means it is uninitialized and does not need free audio.
[HOW] Skip and return NULL.
This fixes 2 OVERRUN issues reported by Coverity.(CVE-2024-42119)
In the Linux kernel, the following vulnerability has been resolved:
scsi: qedf: Make qedf_execute_tmf() non-preemptible
Stop calling smp_processor_id() from preemptible code in qedf_execute_tmf90. This results in BUG_ON() when running an RT kernel.
[ 659.343280] BUG: using smp_processor_id() in preemptible [00000000] code: sg_reset/3646 [ 659.343282] caller is qedf_execute_tmf+0x8b/0x360 qedf
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: qca: Fix BT enable failure again for QCA6390 after warm reboot
Commit 272970be3dab ("Bluetooth: hci_qca: Fix driver shutdown on closed serdev") will cause below regression issue:
BT can't be enabled after below steps: cold boot -> enable BT -> disable BT -> warm reboot -> BT enable failure if property enable-gpios is not configured within DT|ACPI for QCA6390.
The commit is to fix a use-after-free issue within qca_serdev_shutdown() by adding condition to avoid the serdev is flushed or wrote after closed but also introduces this regression issue regarding above steps since the VSC is not sent to reset controller during warm reboot.
Fixed by sending the VSC to reset controller within qca_serdev_shutdown() once BT was ever enabled, and the use-after-free issue is also fixed by this change since the serdev is still opened before it is flushed or wrote.
Verified by the reported machine Dell XPS 13 9310 laptop over below two kernel commits: commit e00fc2700a3f ("Bluetooth: btusb: Fix triggering coredump implementation for QCA") of bluetooth-next tree. commit b23d98d46d28 ("Bluetooth: btusb: Fix triggering coredump implementation for QCA") of linus mainline tree.(CVE-2024-42137)
Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2024-42143)
In the Linux kernel, the following vulnerability has been resolved:
IB/core: Implement a limit on UMAD receive List
The existing behavior of ib_umad, which maintains received MAD packets in an unbounded list, poses a risk of uncontrolled growth. As user-space applications extract packets from this list, the rate of extraction may not match the rate of incoming packets, leading to potential list overflow.
To address this, we introduce a limit to the size of the list. After considering typical scenarios, such as OpenSM processing, which can handle approximately 100k packets per second, and the 1-second retry timeout for most packets, we set the list size limit to 200k. Packets received beyond this limit are dropped, assuming they are likely timed out by the time they are handled by user-space.
Notably, packets queued on the receive list due to reasons like timed-out sends are preserved even when the list is full.(CVE-2024-42145)
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:
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:
bpf: Fix a segment issue when downgrading gso_size
Linearize the skb when downgrading gso_size because it may trigger a BUG_ON() later when the skb is segmented as described in [1,2].(CVE-2024-42281)
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Fix for possible memory corruption
Init Control Block is dereferenced incorrectly. Correctly dereference ICB(CVE-2024-42288)
In the Linux kernel, the following vulnerability has been resolved:
ext4: make sure the first directory block is not a hole
The syzbot constructs a directory that has no dirblock but is non-inline, i.e. the first directory block is a hole. And no errors are reported when creating files in this directory in the following flow.
ext4_mknod
...
ext4_add_entry
// Read block 0
ext4_read_dirblock(dir, block, DIRENT)
bh = ext4_bread(NULL, inode, block, 0)
if (!bh && (type == INDEX || type == DIRENT_HTREE))
// The first directory block is a hole
// But type == DIRENT, so no error is reported.
After that, we get a directory block without '.' and '..' but with a valid dentry. This may cause some code that relies on dot or dotdot (such as make_indexed_dir()) to crash.
Therefore when ext4_read_dirblock() finds that the first directory block is a hole report that the filesystem is corrupted and return an error to avoid loading corrupted data from disk causing something bad.(CVE-2024-42304)
In the Linux kernel, the following vulnerability has been resolved:
drm/gma500: fix null pointer dereference in cdv_intel_lvds_get_modes
In cdv_intel_lvds_get_modes(), the return value of drm_mode_duplicate() is assigned to mode, which will lead to a NULL pointer dereference on failure of drm_mode_duplicate(). Add a check to avoid npd.(CVE-2024-42310)
In the Linux kernel, the following vulnerability has been resolved:
landlock: Don't lose track of restrictions on cred_transfer
When a process' cred struct is replaced, this almost always invokes the cred_prepare LSM hook; but in one special case (when KEYCTL_SESSION_TO_PARENT updates the parent's credentials), the cred_transfer LSM hook is used instead. Landlock only implements the cred_prepare hook, not cred_transfer, so KEYCTL_SESSION_TO_PARENT causes all information on Landlock restrictions to be lost.
This basically means that a process with the ability to use the fork() and keyctl() syscalls can get rid of all Landlock restrictions on itself.
Fix it by adding a cred_transfer hook that does the same thing as the existing cred_prepare hook. (Implemented by having hook_cred_prepare() call hook_cred_transfer() so that the two functions are less likely to accidentally diverge in the future.)(CVE-2024-42318)
In the Linux kernel, the following vulnerability has been resolved:
bna: adjust 'name' buf size of bna_tcb and bna_ccb structures
To have enough space to write all possible sprintf() args. Currently 'name' size is 16, but the first '%s' specifier may already need at least 16 characters, since 'bnad->netdev->name' is used there.
For '%d' specifiers, assume that they require: * 1 char for 'tx_id + tx_info->tcb[i]->id' sum, BNAD_MAX_TXQ_PER_TX is 8 * 2 chars for 'rx_id + rx_info->rx_ctrl[i].ccb->id', BNAD_MAX_RXP_PER_RX is 16
And replace sprintf with snprintf.
Detected using the static analysis tool - Svace.(CVE-2024-43839)
In the Linux kernel, the following vulnerability has been resolved:
block: initialize integrity buffer to zero before writing it to media
Metadata added by bio_integrity_prep is using plain kmalloc, which leads to random kernel memory being written media. For PI metadata this is limited to the app tag that isn't used by kernel generated metadata, but for non-PI metadata the entire buffer leaks kernel memory.
Fix this by adding the __GFP_ZERO flag to allocations for writes.(CVE-2024-43854)
In the Linux kernel, the following vulnerability has been resolved:
wifi: cfg80211: handle 2x996 RU allocation in cfg80211_calculate_bitrate_he()
Currently NL80211_RATE_INFO_HE_RU_ALLOC_2x996 is not handled in cfg80211_calculate_bitrate_he(), leading to below warning:
kernel: invalid HE MCS: bw:6, ru:6 kernel: WARNING: CPU: 0 PID: 2312 at net/wireless/util.c:1501 cfg80211_calculate_bitrate_he+0x22b/0x270 [cfg80211]
Fix it by handling 2x996 RU allocation in the same way as 160 MHz bandwidth.(CVE-2024-43879)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: ctnetlink: use helper function to calculate expect ID
Delete expectation path is missing a call to the nf_expect_get_id() helper function to calculate the expectation ID, otherwise LSB of the expectation object address is leaked to userspace.(CVE-2024-44944)
In the Linux kernel, the following vulnerability has been resolved:
xhci: Fix Panther point NULL pointer deref at full-speed re-enumeration
re-enumerating full-speed devices after a failed address device command can trigger a NULL pointer dereference.
Full-speed devices may need to reconfigure the endpoint 0 Max Packet Size value during enumeration. Usb core calls usb_ep0_reinit() in this case, which ends up calling xhci_configure_endpoint().
On Panther point xHC the xhci_configure_endpoint() function will additionally check and reserve bandwidth in software. Other hosts do this in hardware
If xHC address device command fails then a new xhci_virt_device structure is allocated as part of re-enabling the slot, but the bandwidth table pointers are not set up properly here. This triggers the NULL pointer dereference the next time usb_ep0_reinit() is called and xhci_configure_endpoint() tries to check and reserve bandwidth
[46710.713538] usb 3-1: new full-speed USB device number 5 using xhci_hcd [46710.713699] usb 3-1: Device not responding to setup address. [46710.917684] usb 3-1: Device not responding to setup address. [46711.125536] usb 3-1: device not accepting address 5, error -71 [46711.125594] BUG: kernel NULL pointer dereference, address: 0000000000000008 [46711.125600] #PF: supervisor read access in kernel mode [46711.125603] #PF: error_code(0x0000) - not-present page [46711.125606] PGD 0 P4D 0 [46711.125610] Oops: Oops: 0000 [#1] PREEMPT SMP PTI [46711.125615] CPU: 1 PID: 25760 Comm: kworker/1:2 Not tainted 6.10.3_2 #1 [46711.125620] Hardware name: Gigabyte Technology Co., Ltd. [46711.125623] Workqueue: usb_hub_wq hub_event [usbcore] [46711.125668] RIP: 0010:xhci_reserve_bandwidth (drivers/usb/host/xhci.c
Fix this by making sure bandwidth table pointers are set up correctly after a failed address device command, and additionally by avoiding checking for bandwidth in cases like this where no actual endpoints are added or removed, i.e. only context for default control endpoint 0 is evaluated.(CVE-2024-45006)
In the Linux kernel, the following vulnerability has been resolved:
KVM: arm64: Make ICC_SGI_EL1 undef in the absence of a vGICv3
On a system with a GICv3, if a guest hasn't been configured with GICv3 and that the host is not capable of GICv2 emulation, a write to any of the ICC_SGI_EL1 registers is trapped to EL2.
We therefore try to emulate the SGI access, only to hit a NULL pointer as no private interrupt is allocated (no GIC, remember?).
The obvious fix is to give the guest what it deserves, in the shape of a UNDEF exception.(CVE-2024-46707)
In the Linux kernel, the following vulnerability has been resolved:
ice: Add netif_device_attach/detach into PF reset flow
Ethtool callbacks can be executed while reset is in progress and try to access deleted resources, e.g. getting coalesce settings can result in a NULL pointer dereference seen below.
Reproduction steps: Once the driver is fully initialized, trigger reset: # echo 1 > /sys/class/net/<interface>/device/reset when reset is in progress try to get coalesce settings using ethtool: # ethtool -c <interface>
BUG: kernel NULL pointer dereference, address: 0000000000000020 PGD 0 P4D 0 Oops: Oops: 0000 [#1] PREEMPT SMP PTI CPU: 11 PID: 19713 Comm: ethtool Tainted: G S 6.10.0-rc7+ #7 RIP: 0010:ice_get_q_coalesce+0x2e/0xa0 [ice] RSP: 0018:ffffbab1e9bcf6a8 EFLAGS: 00010206 RAX: 000000000000000c RBX: ffff94512305b028 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff9451c3f2e588 RDI: ffff9451c3f2e588 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: ffff9451c3f2e580 R11: 000000000000001f R12: ffff945121fa9000 R13: ffffbab1e9bcf760 R14: 0000000000000013 R15: ffffffff9e65dd40 FS: 00007faee5fbe740(0000) GS:ffff94546fd80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000020 CR3: 0000000106c2e005 CR4: 00000000001706f0 Call Trace: <TASK> ice_get_coalesce+0x17/0x30 [ice] coalesce_prepare_data+0x61/0x80 ethnl_default_doit+0xde/0x340 genl_family_rcv_msg_doit+0xf2/0x150 genl_rcv_msg+0x1b3/0x2c0 netlink_rcv_skb+0x5b/0x110 genl_rcv+0x28/0x40 netlink_unicast+0x19c/0x290 netlink_sendmsg+0x222/0x490 __sys_sendto+0x1df/0x1f0 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x82/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7faee60d8e27
Calling netif_device_detach() before reset makes the net core not call the driver when ethtool command is issued, the attempt to execute an ethtool command during reset will result in the following message:
netlink error: No such device
instead of NULL pointer dereference. Once reset is done and ice_rebuild() is executing, the netif_device_attach() is called to allow for ethtool operations to occur again in a safe manner.(CVE-2024-46770)
In the Linux kernel, the following vulnerability has been resolved:
sched: sch_cake: fix bulk flow accounting logic for host fairness
In sch_cake, we keep track of the count of active bulk flows per host, when running in dst/src host fairness mode, which is used as the round-robin weight when iterating through flows. The count of active bulk flows is updated whenever a flow changes state.
This has a peculiar interaction with the hash collision handling: when a hash collision occurs (after the set-associative hashing), the state of the hash bucket is simply updated to match the new packet that collided, and if host fairness is enabled, that also means assigning new per-host state to the flow. For this reason, the bulk flow counters of the host(s) assigned to the flow are decremented, before new state is assigned (and the counters, which may not belong to the same host anymore, are incremented again).
Back when this code was introduced, the host fairness mode was always enabled, so the decrement was unconditional. When the configuration flags were introduced the increment was made conditional, but the decrement was not. Which of course can lead to a spurious decrement (and associated wrap-around to U16_MAX).
AFAICT, when host fairness is disabled, the decrement and wrap-around happens as soon as a hash collision occurs (which is not that common in itself, due to the set-associative hashing). However, in most cases this is harmless, as the value is only used when host fairness mode is enabled. So in order to trigger an array overflow, sch_cake has to first be configured with host fairness disabled, and while running in this mode, a hash collision has to occur to cause the overflow. Then, the qdisc has to be reconfigured to enable host fairness, which leads to the array out-of-bounds because the wrapped-around value is retained and used as an array index. It seems that syzbot managed to trigger this, which is quite impressive in its own right.
This patch fixes the issue by introducing the same conditional check on decrement as is used on increment.
The original bug predates the upstreaming of cake, but the commit listed in the Fixes tag touched that code, meaning that this patch won't apply before that.(CVE-2024-46828)
In the Linux kernel, the following vulnerability has been resolved:
perf/x86/intel: Limit the period on Haswell
Running the ltp test cve-2015-3290 concurrently reports the following warnings.
perfevents: irq loop stuck! WARNING: CPU: 31 PID: 32438 at arch/x86/events/intel/core.c:3174 intel_pmu_handle_irq+0x285/0x370 Call Trace: <NMI> ? __warn+0xa4/0x220 ? intel_pmu_handle_irq+0x285/0x370 ? __report_bug+0x123/0x130 ? intel_pmu_handle_irq+0x285/0x370 ? __report_bug+0x123/0x130 ? intel_pmu_handle_irq+0x285/0x370 ? report_bug+0x3e/0xa0 ? handle_bug+0x3c/0x70 ? exc_invalid_op+0x18/0x50 ? asm_exc_invalid_op+0x1a/0x20 ? irq_work_claim+0x1e/0x40 ? intel_pmu_handle_irq+0x285/0x370 perf_event_nmi_handler+0x3d/0x60 nmi_handle+0x104/0x330
Thanks to Thomas Gleixner's analysis, the issue is caused by the low initial period (1) of the frequency estimation algorithm, which triggers the defects of the HW, specifically erratum HSW11 and HSW143. (For the details, please refer https://lore.kernel.org/lkml/87plq9l5d2.ffs@tglx/)
The HSW11 requires a period larger than 100 for the INST_RETIRED.ALL event, but the initial period in the freq mode is 1. The erratum is the same as the BDM11, which has been supported in the kernel. A minimum period of 128 is enforced as well on HSW.
HSW143 is regarding that the fixed counter 1 may overcount 32 with the Hyper-Threading is enabled. However, based on the test, the hardware has more issues than it tells. Besides the fixed counter 1, the message 'interrupt took too long' can be observed on any counter which was armed with a period < 32 and two events expired in the same NMI. A minimum period of 32 is enforced for the rest of the events. The recommended workaround code of the HSW143 is not implemented. Because it only addresses the issue for the fixed counter. It brings extra overhead through extra MSR writing. No related overcounting issue has been reported so far.(CVE-2024-46848)
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: add bounds checking to ocfs2_xattr_find_entry()
Add a paranoia check to make sure it doesn't stray beyond valid memory region containing ocfs2 xattr entries when scanning for a match. It will prevent out-of-bound access in case of crafted images.(CVE-2024-47670)
In the Linux kernel, the following vulnerability has been resolved:
wifi: ath9k_htc: Use __skb_set_length() for resetting urb before resubmit
Syzbot points out that skb_trim() has a sanity check on the existing length of the skb, which can be uninitialised in some error paths. The intent here is clearly just to reset the length to zero before resubmitting, so switch to calling __skb_set_length(skb, 0) directly. In addition, __skb_set_length() already contains a call to skb_reset_tail_pointer(), so remove the redundant call.
The syzbot report came from ath9k_hif_usb_reg_in_cb(), but there's a similar usage of skb_trim() in ath9k_hif_usb_rx_cb(), change both while we're at it.(CVE-2024-49938)
In the Linux kernel, the following vulnerability has been resolved:
sctp: set sk_state back to CLOSED if autobind fails in sctp_listen_start
In sctp_listen_start() invoked by sctp_inet_listen(), it should set the sk_state back to CLOSED if sctp_autobind() fails due to whatever reason.
Otherwise, next time when calling sctp_inet_listen(), if sctp_sk(sk)->reuse is already set via setsockopt(SCTP_REUSE_PORT), sctp_sk(sk)->bind_hash will be dereferenced as sk_state is LISTENING, which causes a crash as bind_hash is NULL.
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:sctp_inet_listen+0x7f0/0xa20 net/sctp/socket.c:8617 Call Trace: <TASK> __sys_listen_socket net/socket.c:1883 [inline] __sys_listen+0x1b7/0x230 net/socket.c:1894 __do_sys_listen net/socket.c:1902 inline
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: prevent nf_skb_duplicated corruption
syzbot found that nf_dup_ipv4() or nf_dup_ipv6() could write per-cpu variable nf_skb_duplicated in an unsafe way [1].
Disabling preemption as hinted by the splat is not enough, we have to disable soft interrupts as well.
[1] BUG: using __this_cpu_write() in preemptible [00000000] code: syz.4.282/6316 caller is nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87 CPU: 0 UID: 0 PID: 6316 Comm: syz.4.282 Not tainted 6.11.0-rc7-syzkaller-00104-g7052622fccb1 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 check_preemption_disabled+0x10e/0x120 lib/smp_processor_id.c:49 nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87 nft_dup_ipv4_eval+0x1db/0x300 net/ipv4/netfilter/nft_dup_ipv4.c:30 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x4ad/0x1da0 net/netfilter/nf_tables_core.c:288 nft_do_chain_ipv4+0x202/0x320 net/netfilter/nft_chain_filter.c:23 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626 nf_hook+0x2c4/0x450 include/linux/netfilter.h:269 NF_HOOK_COND include/linux/netfilter.h:302 [inline] ip_output+0x185/0x230 net/ipv4/ip_output.c:433 ip_local_out net/ipv4/ip_output.c:129 [inline] ip_send_skb+0x74/0x100 net/ipv4/ip_output.c:1495 udp_send_skb+0xacf/0x1650 net/ipv4/udp.c:981 udp_sendmsg+0x1c21/0x2a60 net/ipv4/udp.c:1269 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x1a6/0x270 net/socket.c:745 _syssendmsg+0x525/0x7d0 net/socket.c:2597 _sys_sendmsg net/socket.c:2651 [inline] __sys_sendmmsg+0x3b2/0x740 net/socket.c:2737 __do_sys_sendmmsg net/socket.c:2766 [inline] __se_sys_sendmmsg net/socket.c:2763 [inline] __x64_sys_sendmmsg+0xa0/0xb0 net/socket.c:2763 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f4ce4f7def9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f4ce5d4a038 EFLAGS: 00000246 ORIG_RAX: 0000000000000133 RAX: ffffffffffffffda RBX: 00007f4ce5135f80 RCX: 00007f4ce4f7def9 RDX: 0000000000000001 RSI: 0000000020005d40 RDI: 0000000000000006 RBP: 00007f4ce4ff0b76 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f4ce5135f80 R15: 00007ffd4cbc6d68 </TASK>(CVE-2024-49952)
In the Linux kernel, the following vulnerability has been resolved:
jbd2: stop waiting for space when jbd2_cleanup_journal_tail() returns error
In __jbd2_log_wait_for_space(), we might call jbd2_cleanup_journal_tail() to recover some journal space. But if an error occurs while executing jbd2_cleanup_journal_tail() (e.g., an EIO), we don't stop waiting for free space right away, we try other branches, and if j_committing_transaction is NULL (i.e., the tid is 0), we will get the following complain:
============================================ JBD2: I/O error when updating journal superblock for sdd-8. __jbd2_log_wait_for_space: needed 256 blocks and only had 217 space available __jbd2_log_wait_for_space: no way to get more journal space in sdd-8 ------------[ cut here ]------------ WARNING: CPU: 2 PID: 139804 at fs/jbd2/checkpoint.c:109 __jbd2_log_wait_for_space+0x251/0x2e0 Modules linked in: CPU: 2 PID: 139804 Comm: kworker/u8:3 Not tainted 6.6.0+ #1 RIP: 0010:__jbd2_log_wait_for_space+0x251/0x2e0 Call Trace: <TASK> add_transaction_credits+0x5d1/0x5e0 start_this_handle+0x1ef/0x6a0 jbd2__journal_start+0x18b/0x340 ext4_dirty_inode+0x5d/0xb0 __mark_inode_dirty+0xe4/0x5d0 generic_update_time+0x60/0x70 [...] ============================================
So only if jbd2_cleanup_journal_tail() returns 1, i.e., there is nothing to clean up at the moment, continue to try to reclaim free space in other ways.
Note that this fix relies on commit 6f6a6fda2945 ("jbd2: fix ocfs2 corrupt when updating journal superblock fails") to make jbd2_cleanup_journal_tail return the correct error code.(CVE-2024-49959)
In the Linux kernel, the following vulnerability has been resolved:
mailbox: bcm2835: Fix timeout during suspend mode
During noirq suspend phase the Raspberry Pi power driver suffer of firmware property timeouts. The reason is that the IRQ of the underlying BCM2835 mailbox is disabled and rpi_firmware_property_list() will always run into a timeout [1].
Since the VideoCore side isn't consider as a wakeup source, set the IRQF_NO_SUSPEND flag for the mailbox IRQ in order to keep it enabled during suspend-resume cycle.
[1] PM: late suspend of devices complete after 1.754 msecs WARNING: CPU: 0 PID: 438 at drivers/firmware/raspberrypi.c:128 rpi_firmware_property_list+0x204/0x22c Firmware transaction 0x00028001 timeout Modules linked in: CPU: 0 PID: 438 Comm: bash Tainted: G C 6.9.3-dirty #17 Hardware name: BCM2835 Call trace: unwind_backtrace from show_stack+0x18/0x1c show_stack from dump_stack_lvl+0x34/0x44 dump_stack_lvl from __warn+0x88/0xec __warn from warn_slowpath_fmt+0x7c/0xb0 warn_slowpath_fmt from rpi_firmware_property_list+0x204/0x22c rpi_firmware_property_list from rpi_firmware_property+0x68/0x8c rpi_firmware_property from rpi_firmware_set_power+0x54/0xc0 rpi_firmware_set_power from _genpd_power_off+0xe4/0x148 _genpd_power_off from genpd_sync_power_off+0x7c/0x11c genpd_sync_power_off from genpd_finish_suspend+0xcc/0xe0 genpd_finish_suspend from dpm_run_callback+0x78/0xd0 dpm_run_callback from device_suspend_noirq+0xc0/0x238 device_suspend_noirq from dpm_suspend_noirq+0xb0/0x168 dpm_suspend_noirq from suspend_devices_and_enter+0x1b8/0x5ac suspend_devices_and_enter from pm_suspend+0x254/0x2e4 pm_suspend from state_store+0xa8/0xd4 state_store from kernfs_fop_write_iter+0x154/0x1a0 kernfs_fop_write_iter from vfs_write+0x12c/0x184 vfs_write from ksys_write+0x78/0xc0 ksys_write from ret_fast_syscall+0x0/0x54 Exception stack(0xcc93dfa8 to 0xcc93dff0) [...] PM: noirq suspend of devices complete after 3095.584 msecs(CVE-2024-49963)
In the Linux kernel, the following vulnerability has been resolved:
tty: n_gsm: Fix use-after-free in gsm_cleanup_mux
BUG: KASAN: slab-use-after-free in gsm_cleanup_mux+0x77b/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] Read of size 8 at addr ffff88815fe99c00 by task poc/3379 CPU: 0 UID: 0 PID: 3379 Comm: poc Not tainted 6.11.0+ #56 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 Call Trace: <TASK> gsm_cleanup_mux+0x77b/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] __pfx_gsm_cleanup_mux+0x10/0x10 drivers/tty/n_gsm.c:3124 [n_gsm] __pfx_sched_clock_cpu+0x10/0x10 kernel/sched/clock.c:389 update_load_avg+0x1c1/0x27b0 kernel/sched/fair.c:4500 __pfx_min_vruntime_cb_rotate+0x10/0x10 kernel/sched/fair.c:846 __rb_insert_augmented+0x492/0xbf0 lib/rbtree.c:161 gsmld_ioctl+0x395/0x1450 drivers/tty/n_gsm.c:3408 [n_gsm] _raw_spin_lock_irqsave+0x92/0xf0 arch/x86/include/asm/atomic.h:107 __pfx_gsmld_ioctl+0x10/0x10 drivers/tty/n_gsm.c:3822 [n_gsm] ktime_get+0x5e/0x140 kernel/time/timekeeping.c:195 ldsem_down_read+0x94/0x4e0 arch/x86/include/asm/atomic64_64.h:79 __pfx_ldsem_down_read+0x10/0x10 drivers/tty/tty_ldsem.c:338 __pfx_do_vfs_ioctl+0x10/0x10 fs/ioctl.c:805 tty_ioctl+0x643/0x1100 drivers/tty/tty_io.c:2818
Allocated by task 65: gsm_data_alloc.constprop.0+0x27/0x190 drivers/tty/n_gsm.c:926 [n_gsm] gsm_send+0x2c/0x580 drivers/tty/n_gsm.c:819 [n_gsm] gsm1_receive+0x547/0xad0 drivers/tty/n_gsm.c:3038 [n_gsm] gsmld_receive_buf+0x176/0x280 drivers/tty/n_gsm.c:3609 [n_gsm] tty_ldisc_receive_buf+0x101/0x1e0 drivers/tty/tty_buffer.c:391 tty_port_default_receive_buf+0x61/0xa0 drivers/tty/tty_port.c:39 flush_to_ldisc+0x1b0/0x750 drivers/tty/tty_buffer.c:445 process_scheduled_works+0x2b0/0x10d0 kernel/workqueue.c:3229 worker_thread+0x3dc/0x950 kernel/workqueue.c:3391 kthread+0x2a3/0x370 kernel/kthread.c:389 ret_from_fork+0x2d/0x70 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:257
Freed by task 3367: kfree+0x126/0x420 mm/slub.c:4580 gsm_cleanup_mux+0x36c/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] gsmld_ioctl+0x395/0x1450 drivers/tty/n_gsm.c:3408 [n_gsm] tty_ioctl+0x643/0x1100 drivers/tty/tty_io.c:2818
[Analysis] gsm_msg on the tx_ctrl_list or tx_data_list of gsm_mux can be freed by multi threads through ioctl,which leads to the occurrence of uaf. Protect it by gsm tx lock.(CVE-2024-50073)
In the Linux kernel, the following vulnerability has been resolved:
LoongArch: Don't crash in stack_top() for tasks without vDSO
Not all tasks have a vDSO mapped, for example kthreads never do. If such a task ever ends up calling stack_top(), it will derefence the NULL vdso pointer and crash.
This can for example happen when using kunit:
[<9000000000203874>] stack_top+0x58/0xa8
[<90000000002956cc>] arch_pick_mmap_layout+0x164/0x220
[<90000000003c284c>] kunit_vm_mmap_init+0x108/0x12c
[<90000000003c1fbc>] __kunit_add_resource+0x38/0x8c
[<90000000003c2704>] kunit_vm_mmap+0x88/0xc8
[<9000000000410b14>] usercopy_test_init+0xbc/0x25c
[<90000000003c1db4>] kunit_try_run_case+0x5c/0x184
[<90000000003c3d54>] kunit_generic_run_threadfn_adapter+0x24/0x48
[<900000000022e4bc>] kthread+0xc8/0xd4
[<9000000000200ce8>] ret_from_kernel_thread+0xc/0xa4(CVE-2024-50133)
In the Linux kernel, the following vulnerability has been resolved:
xfrm: validate new SA's prefixlen using SA family when sel.family is unset
This expands the validation introduced in commit 07bf7908950a ("xfrm: Validate address prefix lengths in the xfrm selector.")
syzbot created an SA with usersa.sel.family = AF_UNSPEC usersa.sel.prefixlen_s = 128 usersa.family = AF_INET
Because of the AF_UNSPEC selector, verify_newsa_info doesn't put limits on prefixlen_{s,d}. But then copy_from_user_state sets x->sel.family to usersa.family (AF_INET). Do the same conversion in verify_newsa_info before validating prefixlen_{s,d}, since that's how prefixlen is going to be used later on.(CVE-2024-50142)
In the Linux kernel, the following vulnerability has been resolved:
be2net: fix potential memory leak in be_xmit()
The be_xmit() returns NETDEV_TX_OK without freeing skb in case of be_xmit_enqueue() fails, add dev_kfree_skb_any() to fix it.(CVE-2024-50167)
In the Linux kernel, the following vulnerability has been resolved:
net/sun3_82586: fix potential memory leak in sun3_82586_send_packet()
The sun3_82586_send_packet() returns NETDEV_TX_OK without freeing skb in case of skb->len being too long, add dev_kfree_skb() to fix it.(CVE-2024-50168)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nft_payload: sanitize offset and length before calling skb_checksum()
If access to offset + length is larger than the skbuff length, then skb_checksum() triggers BUG_ON().
skb_checksum() internally subtracts the length parameter while iterating over skbuff, BUG_ON(len) at the end of it checks that the expected length to be included in the checksum calculation is fully consumed.(CVE-2024-50251)
In the Linux kernel, the following vulnerability has been resolved:
drm/i915/hdcp: Add encoder check in hdcp2_get_capability
Add encoder check in intel_hdcp2_get_capability to avoid null pointer error.(CVE-2024-53050)
In the Linux kernel, the following vulnerability has been resolved:
bpf: Check validity of link->type in bpf_link_show_fdinfo()
If a newly-added link type doesn't invoke BPF_LINK_TYPE(), accessing bpf_link_type_strs[link->type] may result in an out-of-bounds access.
To spot such missed invocations early in the future, checking the validity of link->type in bpf_link_show_fdinfo() and emitting a warning when such invocations are missed.(CVE-2024-53099)
In the Linux kernel, the following vulnerability has been resolved:
fs: Fix uninitialized value issue in from_kuid and from_kgid
ocfs2_setattr() uses attr->ia_mode, attr->ia_uid and attr->ia_gid in a trace point even though ATTR_MODE, ATTR_UID and ATTR_GID aren't set.
Initialize all fields of newattrs to avoid uninitialized variables, by checking if ATTR_MODE, ATTR_UID, ATTR_GID are initialized, otherwise 0.(CVE-2024-53101)
In the Linux kernel, the following vulnerability has been resolved:
sched/task_stack: fix object_is_on_stack() for KASAN tagged pointers
When CONFIG_KASAN_SW_TAGS and CONFIG_KASAN_STACK are enabled, the object_is_on_stack() function may produce incorrect results due to the presence of tags in the obj pointer, while the stack pointer does not have tags. This discrepancy can lead to incorrect stack object detection and subsequently trigger warnings if CONFIG_DEBUG_OBJECTS is also enabled.
Example of the warning:
ODEBUG: object 3eff800082ea7bb0 is NOT on stack ffff800082ea0000, but annotated. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1 at lib/debugobjects.c:557 __debug_object_init+0x330/0x364 Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-rc5 #4 Hardware name: linux,dummy-virt (DT) pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __debug_object_init+0x330/0x364 lr : __debug_object_init+0x330/0x364 sp : ffff800082ea7b40 x29: ffff800082ea7b40 x28: 98ff0000c0164518 x27: 98ff0000c0164534 x26: ffff800082d93ec8 x25: 0000000000000001 x24: 1cff0000c00172a0 x23: 0000000000000000 x22: ffff800082d93ed0 x21: ffff800081a24418 x20: 3eff800082ea7bb0 x19: efff800000000000 x18: 0000000000000000 x17: 00000000000000ff x16: 0000000000000047 x15: 206b63617473206e x14: 0000000000000018 x13: ffff800082ea7780 x12: 0ffff800082ea78e x11: 0ffff800082ea790 x10: 0ffff800082ea79d x9 : 34d77febe173e800 x8 : 34d77febe173e800 x7 : 0000000000000001 x6 : 0000000000000001 x5 : feff800082ea74b8 x4 : ffff800082870a90 x3 : ffff80008018d3c4 x2 : 0000000000000001 x1 : ffff800082858810 x0 : 0000000000000050 Call trace: __debug_object_init+0x330/0x364 debug_object_init_on_stack+0x30/0x3c schedule_hrtimeout_range_clock+0xac/0x26c schedule_hrtimeout+0x1c/0x30 wait_task_inactive+0x1d4/0x25c kthread_bind_mask+0x28/0x98 init_rescuer+0x1e8/0x280 workqueue_init+0x1a0/0x3cc kernel_init_freeable+0x118/0x200 kernel_init+0x28/0x1f0 ret_from_fork+0x10/0x20 ---[ end trace 0000000000000000 ]--- ODEBUG: object 3eff800082ea7bb0 is NOT on stack ffff800082ea0000, but annotated. ------------[ cut here ]------------(CVE-2024-53128)
In the Linux kernel, the following vulnerability has been resolved:
ALSA: usb-audio: Fix out of bounds reads when finding clock sources
The current USB-audio driver code doesn't check bLength of each descriptor at traversing for clock descriptors. That is, when a device provides a bogus descriptor with a shorter bLength, the driver might hit out-of-bounds reads.
For addressing it, this patch adds sanity checks to the validator functions for the clock descriptor traversal. When the descriptor length is shorter than expected, it's skipped in the loop.
For the clock source and clock multiplier descriptors, we can just check bLength against the sizeof() of each descriptor type. OTOH, the clock selector descriptor of UAC2 and UAC3 has an array of bNrInPins elements and two more fields at its tail, hence those have to be checked in addition to the sizeof() check.(CVE-2024-53150)
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: fix uninitialized value in ocfs2_file_read_iter()
Syzbot has reported the following KMSAN splat:
BUG: KMSAN: uninit-value in ocfs2_file_read_iter+0x9a4/0xf80 ocfs2_file_read_iter+0x9a4/0xf80 __io_read+0x8d4/0x20f0 io_read+0x3e/0xf0 io_issue_sqe+0x42b/0x22c0 io_wq_submit_work+0xaf9/0xdc0 io_worker_handle_work+0xd13/0x2110 io_wq_worker+0x447/0x1410 ret_from_fork+0x6f/0x90 ret_from_fork_asm+0x1a/0x30
Uninit was created at: __alloc_pages_noprof+0x9a7/0xe00 alloc_pages_mpol_noprof+0x299/0x990 alloc_pages_noprof+0x1bf/0x1e0 allocate_slab+0x33a/0x1250 slaballoc+0x12ef/0x35e0 kmem_cache_alloc_bulk_noprof+0x486/0x1330 io_alloc_req_refill+0x84/0x560 io_submit_sqes+0x172f/0x2f30 __se_sys_io_uring_enter+0x406/0x41c0 __x64_sys_io_uring_enter+0x11f/0x1a0 x64_sys_call+0x2b54/0x3ba0 do_syscall_64+0xcd/0x1e0 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Since an instance of 'struct kiocb' may be passed from the block layer with 'private' field uninitialized, introduce 'ocfs2_iocb_init_rw_locked()' and use it from where 'ocfs2_dio_end_io()' might take care, i.e. in 'ocfs2_file_read_iter()' and 'ocfs2_file_write_iter()'.(CVE-2024-53155)
In the Linux kernel, the following vulnerability has been resolved:
firmware: arm_scpi: Check the DVFS OPP count returned by the firmware
Fix a kernel crash with the below call trace when the SCPI firmware returns OPP count of zero.
dvfs_info.opp_count may be zero on some platforms during the reboot test, and the kernel will crash after dereferencing the pointer to kcalloc(info->count, sizeof(*opp), GFP_KERNEL).
| Unable to handle kernel NULL pointer dereference at virtual address 0000000000000028 | Mem abort info: | ESR = 0x96000004 | Exception class = DABT (current EL), IL = 32 bits | SET = 0, FnV = 0 | EA = 0, S1PTW = 0 | Data abort info: | ISV = 0, ISS = 0x00000004 | CM = 0, WnR = 0 | user pgtable: 4k pages, 48-bit VAs, pgdp = 00000000faefa08c | [0000000000000028] pgd=0000000000000000 | Internal error: Oops: 96000004 [#1] SMP | scpi-hwmon: probe of PHYT000D:00 failed with error -110 | Process systemd-udevd (pid: 1701, stack limit = 0x00000000aaede86c) | CPU: 2 PID: 1701 Comm: systemd-udevd Not tainted 4.19.90+ #1 | Hardware name: PHYTIUM LTD Phytium FT2000/4/Phytium FT2000/4, BIOS | pstate: 60000005 (nZCv daif -PAN -UAO) | pc : scpi_dvfs_recalc_rate+0x40/0x58 [clk_scpi] | lr : clk_register+0x438/0x720 | Call trace: | scpi_dvfs_recalc_rate+0x40/0x58 [clk_scpi] | devm_clk_hw_register+0x50/0xa0 | scpi_clk_ops_init.isra.2+0xa0/0x138 [clk_scpi] | scpi_clocks_probe+0x528/0x70c [clk_scpi] | platform_drv_probe+0x58/0xa8 | really_probe+0x260/0x3d0 | driver_probe_device+0x12c/0x148 | device_driver_attach+0x74/0x98 | __driver_attach+0xb4/0xe8 | bus_for_each_dev+0x88/0xe0 | driver_attach+0x30/0x40 | bus_add_driver+0x178/0x2b0 | driver_register+0x64/0x118 | __platform_driver_register+0x54/0x60 | scpi_clocks_driver_init+0x24/0x1000 [clk_scpi] | do_one_initcall+0x54/0x220 | do_init_module+0x54/0x1c8 | load_module+0x14a4/0x1668 | __se_sys_finit_module+0xf8/0x110 | __arm64_sys_finit_module+0x24/0x30 | el0_svc_common+0x78/0x170 | el0_svc_handler+0x38/0x78 | el0_svc+0x8/0x340 | Code: 937d7c00 a94153f3 a8c27bfd f9400421 (b8606820) | ---[ end trace 06feb22469d89fa8 ]--- | Kernel panic - not syncing: Fatal exception | SMP: stopping secondary CPUs | Kernel Offset: disabled | CPU features: 0x10,a0002008 | Memory Limit: none(CVE-2024-53157)
In the Linux kernel, the following vulnerability has been resolved:
soc: qcom: geni-se: fix array underflow in geni_se_clk_tbl_get()
This loop is supposed to break if the frequency returned from clk_round_rate() is the same as on the previous iteration. However, that check doesn't make sense on the first iteration through the loop. It leads to reading before the start of these->clk_perf_tbl[] array.(CVE-2024-53158)
Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2024-53159)
In the Linux kernel, the following vulnerability has been resolved:
rcu/kvfree: Fix data-race in __mod_timer / kvfree_call_rcu
KCSAN reports a data race when access the krcp->monitor_work.timer.expires variable in the schedule_delayed_monitor_work() function:
<snip> BUG: KCSAN: data-race in __mod_timer / kvfree_call_rcu
read to 0xffff888237d1cce8 of 8 bytes by task 10149 on cpu 1: schedule_delayed_monitor_work kernel/rcu/tree.c:3520 [inline] kvfree_call_rcu+0x3b8/0x510 kernel/rcu/tree.c:3839 trie_update_elem+0x47c/0x620 kernel/bpf/lpm_trie.c:441 bpf_map_update_value+0x324/0x350 kernel/bpf/syscall.c:203 generic_map_update_batch+0x401/0x520 kernel/bpf/syscall.c:1849 bpf_map_do_batch+0x28c/0x3f0 kernel/bpf/syscall.c:5143 __sys_bpf+0x2e5/0x7a0 __do_sys_bpf kernel/bpf/syscall.c:5741 [inline] __se_sys_bpf kernel/bpf/syscall.c:5739 [inline] __x64_sys_bpf+0x43/0x50 kernel/bpf/syscall.c:5739 x64_sys_call+0x2625/0x2d60 arch/x86/include/generated/asm/syscalls_64.h:322 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xc9/0x1c0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f
write to 0xffff888237d1cce8 of 8 bytes by task 56 on cpu 0: __mod_timer+0x578/0x7f0 kernel/time/timer.c:1173 add_timer_global+0x51/0x70 kernel/time/timer.c:1330 __queue_delayed_work+0x127/0x1a0 kernel/workqueue.c:2523 queue_delayed_work_on+0xdf/0x190 kernel/workqueue.c:2552 queue_delayed_work include/linux/workqueue.h:677 [inline] schedule_delayed_monitor_work kernel/rcu/tree.c:3525 [inline] kfree_rcu_monitor+0x5e8/0x660 kernel/rcu/tree.c:3643 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0x483/0x9a0 kernel/workqueue.c:3310 worker_thread+0x51d/0x6f0 kernel/workqueue.c:3391 kthread+0x1d1/0x210 kernel/kthread.c:389 ret_from_fork+0x4b/0x60 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
Reported by Kernel Concurrency Sanitizer on: CPU: 0 UID: 0 PID: 56 Comm: kworker/u8:4 Not tainted 6.12.0-rc2-syzkaller-00050-g5b7c893ed5ed #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Workqueue: events_unbound kfree_rcu_monitor <snip>
kfree_rcu_monitor() rearms the work if a "krcp" has to be still offloaded and this is done without holding krcp->lock, whereas the kvfree_call_rcu() holds it.
Fix it by acquiring the "krcp->lock" for kfree_rcu_monitor() so both functions do not race anymore.(CVE-2024-53160)
In the Linux kernel, the following vulnerability has been resolved:
ubifs: authentication: Fix use-after-free in ubifs_tnc_end_commit
After an insertion in TNC, the tree might split and cause a node to
change its znode->parent. A further deletion of other nodes in the
tree (which also could free the nodes), the aforementioned node's
znode->cparent could still point to a freed node. This
znode->cparent may not be updated when getting nodes to commit in
ubifs_tnc_start_commit(). This could then trigger a use-after-free
when accessing the znode->cparent in write_index() in
ubifs_tnc_end_commit().
This can be triggered by running
rm -f /etc/test-file.bin dd if=/dev/urandom of=/etc/test-file.bin bs=1M count=60 conv=fsync
in a loop, and with CONFIG_UBIFS_FS_AUTHENTICATION. KASAN then
reports:
BUG: KASAN: use-after-free in ubifs_tnc_end_commit+0xa5c/0x1950 Write of size 32 at addr ffffff800a3af86c by task ubifs_bgt0_20/153
Call trace: dump_backtrace+0x0/0x340 show_stack+0x18/0x24 dump_stack_lvl+0x9c/0xbc print_address_description.constprop.0+0x74/0x2b0 kasan_report+0x1d8/0x1f0 kasan_check_range+0xf8/0x1a0 memcpy+0x84/0xf4 ubifs_tnc_end_commit+0xa5c/0x1950 do_commit+0x4e0/0x1340 ubifs_bg_thread+0x234/0x2e0 kthread+0x36c/0x410 ret_from_fork+0x10/0x20
Allocated by task 401: kasan_save_stack+0x38/0x70 __kasan_kmalloc+0x8c/0xd0 __kmalloc+0x34c/0x5bc tnc_insert+0x140/0x16a4 ubifs_tnc_add+0x370/0x52c ubifs_jnl_write_data+0x5d8/0x870 do_writepage+0x36c/0x510 ubifs_writepage+0x190/0x4dc __writepage+0x58/0x154 write_cache_pages+0x394/0x830 do_writepages+0x1f0/0x5b0 filemap_fdatawrite_wbc+0x170/0x25c file_write_and_wait_range+0x140/0x190 ubifs_fsync+0xe8/0x290 vfs_fsync_range+0xc0/0x1e4 do_fsync+0x40/0x90 __arm64_sys_fsync+0x34/0x50 invoke_syscall.constprop.0+0xa8/0x260 do_el0_svc+0xc8/0x1f0 el0_svc+0x34/0x70 el0t_64_sync_handler+0x108/0x114 el0t_64_sync+0x1a4/0x1a8
Freed by task 403: kasan_save_stack+0x38/0x70 kasan_set_track+0x28/0x40 kasan_set_free_info+0x28/0x4c __kasan_slab_free+0xd4/0x13c kfree+0xc4/0x3a0 tnc_delete+0x3f4/0xe40 ubifs_tnc_remove_range+0x368/0x73c ubifs_tnc_remove_ino+0x29c/0x2e0 ubifs_jnl_delete_inode+0x150/0x260 ubifs_evict_inode+0x1d4/0x2e4 evict+0x1c8/0x450 iput+0x2a0/0x3c4 do_unlinkat+0x2cc/0x490 __arm64_sys_unlinkat+0x90/0x100 invoke_syscall.constprop.0+0xa8/0x260 do_el0_svc+0xc8/0x1f0 el0_svc+0x34/0x70 el0t_64_sync_handler+0x108/0x114 el0t_64_sync+0x1a4/0x1a8
The offending memcpy() in ubifs_copy_hash() has a use-after-free
when a node becomes root in TNC but still has a cparent to an already
freed node. More specifically, consider the following TNC:
zroot
/
/
zp1
/
/
zn
Inserting a new node zn_new with a key smaller then zn will trigger
a split in tnc_insert() if zp1 is full:
zroot
/ \
/ \
zp1 zp2
/ \
/ \
zn_new zn
zn->parent has now been moved to zp2, but zn->cparent still
points to zp1.
Now, consider a removal of all the nodes except zn. Just when
tnc_delete() is about to delete zroot and zp2:
zroot
\
\
zp2
\
\
zn
zroot and zp2 get freed and the tree collapses:
zn
zn now becomes the new zroot.
get_znodes_to_commit() will now only find zn, the new zroot, and
write_index() will check its znode->cparent that wrongly points to
the already freed zp1. ubifs_copy_hash() thus gets wrongly called
with znode->cparent->zbranch[znode->iip].hash that triggers the
use-after-free!
Fix this by explicitly setting znode->cparent to NULL in
get_znodes_to_commit() for the root node. The search for the dirty
nodes
---truncated---(CVE-2024-53171)
In the Linux kernel, the following vulnerability has been resolved:
ALSA: pcm: Add sanity NULL check for the default mmap fault handler
A driver might allow the mmap access before initializing its runtime->dma_area properly. Add a proper NULL check before passing to virt_to_page() for avoiding a panic.(CVE-2024-53180)
In the Linux kernel, the following vulnerability has been resolved:
io_uring: check for overflows in io_pin_pages
WARNING: CPU: 0 PID: 5834 at io_uring/memmap.c:144 io_pin_pages+0x149/0x180 io_uring/memmap.c:144 CPU: 0 UID: 0 PID: 5834 Comm: syz-executor825 Not tainted 6.12.0-next-20241118-syzkaller #0 Call Trace: <TASK> __io_uaddr_map+0xfb/0x2d0 io_uring/memmap.c:183 io_rings_map io_uring/io_uring.c:2611 [inline] io_allocate_scq_urings+0x1c0/0x650 io_uring/io_uring.c:3470 io_uring_create+0x5b5/0xc00 io_uring/io_uring.c:3692 io_uring_setup io_uring/io_uring.c:3781 [inline] ... </TASK>
io_pin_pages()'s uaddr parameter came directly from the user and can be garbage. Don't just add size to it as it can overflow.(CVE-2024-53187)
In the Linux kernel, the following vulnerability has been resolved:
wifi: rtlwifi: Drastically reduce the attempts to read efuse in case of failures
Syzkaller reported a hung task with uevent_show() on stack trace. That specific issue was addressed by another commit [0], but even with that fix applied (for example, running v6.12-rc5) we face another type of hung task that comes from the same reproducer [1]. By investigating that, we could narrow it to the following path:
(a) Syzkaller emulates a Realtek USB WiFi adapter using raw-gadget and dummy_hcd infrastructure.
(b) During the probe of rtl8192cu, the driver ends-up performing an efuse read procedure (which is related to EEPROM load IIUC), and here lies the issue: the function read_efuse() calls read_efuse_byte() many times, as loop iterations depending on the efuse size (in our example, 512 in total).
This procedure for reading efuse bytes relies in a loop that performs an I/O read up to 10k times in case of failures. We measured the time of the loop inside read_efuse_byte() alone, and in this reproducer (which involves the dummy_hcd emulation layer), it takes 15 seconds each. As a consequence, we have the driver stuck in its probe routine for big time, exposing a stack trace like below if we attempt to reboot the system, for example:
task:kworker/0:3 state:D stack:0 pid:662 tgid:662 ppid:2 flags:0x00004000 Workqueue: usb_hub_wq hub_event Call Trace: __schedule+0xe22/0xeb6 schedule_timeout+0xe7/0x132 __wait_for_common+0xb5/0x12e usb_start_wait_urb+0xc5/0x1ef ? usb_alloc_urb+0x95/0xa4 usb_control_msg+0xff/0x184 _usbctrl_vendorreq_sync+0xa0/0x161 _usb_read_sync+0xb3/0xc5 read_efuse_byte+0x13c/0x146 read_efuse+0x351/0x5f0 efuse_read_all_map+0x42/0x52 rtl_efuse_shadow_map_update+0x60/0xef rtl_get_hwinfo+0x5d/0x1c2 rtl92cu_read_eeprom_info+0x10a/0x8d5 ? rtl92c_read_chip_version+0x14f/0x17e rtl_usb_probe+0x323/0x851 usb_probe_interface+0x278/0x34b really_probe+0x202/0x4a4 __driver_probe_device+0x166/0x1b2 driver_probe_device+0x2f/0xd8 [...]
We propose hereby to drastically reduce the attempts of doing the I/O reads in case of failures, restricted to USB devices (given that they're inherently slower than PCIe ones). By retrying up to 10 times (instead of 10000), we got reponsiveness in the reproducer, while seems reasonable to believe that there's no sane USB device implementation in the field requiring this amount of retries at every I/O read in order to properly work. Based on that assumption, it'd be good to have it backported to stable but maybe not since driver implementation (the 10k number comes from day 0), perhaps up to 6.x series makes sense.
[0] Commit 15fffc6a5624 ("driver core: Fix uevent_show() vs driver detach race")
[1] A note about that: this syzkaller report presents multiple reproducers that differs by the type of emulated USB device. For this specific case, check the entry from 2024/08/08 06:23 in the list of crashes; the C repro is available at https://syzkaller.appspot.com/text?tag=ReproC&x=1521fc83980000.(CVE-2024-53190)
In the Linux kernel, the following vulnerability has been resolved:
wifi: ath12k: fix warning when unbinding
If there is an error during some initialization related to firmware, the buffers dp->tx_ring[i].tx_status are released. However this is released again when the device is unbinded (ath12k_pci), and we get: WARNING: CPU: 0 PID: 2098 at mm/slub.c:4689 free_large_kmalloc+0x4d/0x80 Call Trace: free_large_kmalloc ath12k_dp_free ath12k_core_deinit ath12k_pci_remove ...
The issue is always reproducible from a VM because the MSI addressing initialization is failing.
In order to fix the issue, just set the buffers to NULL after releasing in order to avoid the double free.(CVE-2024-53191)
In the Linux kernel, the following vulnerability has been resolved:
PCI: Fix use-after-free of slot->bus on hot remove
Dennis reports a boot crash on recent Lenovo laptops with a USB4 dock.
Since commit 0fc70886569c ("thunderbolt: Reset USB4 v2 host router") and commit 59a54c5f3dbd ("thunderbolt: Reset topology created by the boot firmware"), USB4 v2 and v1 Host Routers are reset on probe of the thunderbolt driver.
The reset clears the Presence Detect State and Data Link Layer Link Active bits at the USB4 Host Router's Root Port and thus causes hot removal of the dock.
The crash occurs when pciehp is unbound from one of the dock's Downstream Ports: pciehp creates a pci_slot on bind and destroys it on unbind. The pci_slot contains a pointer to the pci_bus below the Downstream Port, but a reference on that pci_bus is never acquired. The pci_bus is destroyed before the pci_slot, so a use-after-free ensues when pci_slot_release() accesses slot->bus.
In principle this should not happen because pci_stop_bus_device() unbinds pciehp (and therefore destroys the pci_slot) before the pci_bus is destroyed by pci_remove_bus_device().
However the stacktrace provided by Dennis shows that pciehp is unbound from pci_remove_bus_device() instead of pci_stop_bus_device(). To understand the significance of this, one needs to know that the PCI core uses a two step process to remove a portion of the hierarchy: It first unbinds all drivers in the sub-hierarchy in pci_stop_bus_device() and then actually removes the devices in pci_remove_bus_device(). There is no precaution to prevent driver binding in-between pci_stop_bus_device() and pci_remove_bus_device().
In Dennis' case, it seems removal of the hierarchy by pciehp races with driver binding by pci_bus_add_devices(). pciehp is bound to the Downstream Port after pci_stop_bus_device() has run, so it is unbound by pci_remove_bus_device() instead of pci_stop_bus_device(). Because the pci_bus has already been destroyed at that point, accesses to it result in a use-after-free.
One might conclude that driver binding needs to be prevented after pci_stop_bus_device() has run. However it seems risky that pci_slot points to pci_bus without holding a reference. Solely relying on correct ordering of driver unbind versus pci_bus destruction is certainly not defensive programming.
If pci_slot has a need to access data in pci_bus, it ought to acquire a reference. Amend pci_create_slot() accordingly. Dennis reports that the crash is not reproducible with this change.
Abridged stacktrace:
pcieport 0000:00:07.0: PME: Signaling with IRQ 156 pcieport 0000:00:07.0: pciehp: Slot #12 AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ Surprise+ Interlock- NoCompl+ IbPresDis- LLActRep+ pci_bus 0000:20: dev 00, created physical slot 12 pcieport 0000:00:07.0: pciehp: Slot(12): Card not present ... pcieport 0000:21:02.0: pciehp: pcie_disable_notification: SLOTCTRL d8 write cmd 0 Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b6b: 0000 [#1] PREEMPT SMP NOPTI CPU: 13 UID: 0 PID: 134 Comm: irq/156-pciehp Not tainted 6.11.0-devel+ #1 RIP: 0010:dev_driver_string+0x12/0x40 pci_destroy_slot pciehp_remove pcie_port_remove_service device_release_driver_internal bus_remove_device device_del device_unregister remove_iter device_for_each_child pcie_portdrv_remove pci_device_remove device_release_driver_internal bus_remove_device device_del pci_remove_bus_device (recursive invocation) pci_remove_bus_device pciehp_unconfigure_device pciehp_disable_slot pciehp_handle_presence_or_link_change pciehp_ist(CVE-2024-53194)
In the Linux kernel, the following vulnerability has been resolved:
KVM: arm64: Don't retire aborted MMIO instruction
Returning an abort to the guest for an unsupported MMIO access is a documented feature of the KVM UAPI. Nevertheless, it's clear that this plumbing has seen limited testing, since userspace can trivially cause a WARN in the MMIO return:
WARNING: CPU: 0 PID: 30558 at arch/arm64/include/asm/kvm_emulate.h:536 kvm_handle_mmio_return+0x46c/0x5c4 arch/arm64/include/asm/kvm_emulate.h:536 Call trace: kvm_handle_mmio_return+0x46c/0x5c4 arch/arm64/include/asm/kvm_emulate.h:536 kvm_arch_vcpu_ioctl_run+0x98/0x15b4 arch/arm64/kvm/arm.c:1133 kvm_vcpu_ioctl+0x75c/0xa78 virt/kvm/kvm_main.c:4487 __do_sys_ioctl fs/ioctl.c:51 [inline] __se_sys_ioctl fs/ioctl.c:893 [inline] __arm64_sys_ioctl+0x14c/0x1c8 fs/ioctl.c:893 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x1e0/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x38/0x68 arch/arm64/kernel/entry-common.c:712 el0t_64_sync_handler+0x90/0xfc arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598
The splat is complaining that KVM is advancing PC while an exception is pending, i.e. that KVM is retiring the MMIO instruction despite a pending synchronous external abort. Womp womp.
Fix the glaring UAPI bug by skipping over all the MMIO emulation in case there is a pending synchronous exception. Note that while userspace is capable of pending an asynchronous exception (SError, IRQ, or FIQ), it is still safe to retire the MMIO instruction in this case as (1) they are by definition asynchronous, and (2) KVM relies on hardware support for pending/delivering these exceptions instead of the software state machine for advancing PC.(CVE-2024-53196)
In the Linux kernel, the following vulnerability has been resolved:
usb: typec: fix potential array underflow in ucsi_ccg_sync_control()
The "command" variable can be controlled by the user via debugfs. The worry is that if con_index is zero then "&uc->ucsi->connector[con_index - 1]" would be an array underflow.(CVE-2024-53203)
In the Linux kernel, the following vulnerability has been resolved:
net: usb: lan78xx: Fix double free issue with interrupt buffer allocation
In lan78xx_probe(), the buffer buf was being freed twice: once
implicitly through usb_free_urb(dev->urb_intr) with the
URB_FREE_BUFFER flag and again explicitly by kfree(buf). This caused
a double free issue.
To resolve this, reordered kmalloc() and usb_alloc_urb() calls to
simplify the initialization sequence and removed the redundant
kfree(buf). Now, buf is allocated after usb_alloc_urb(), ensuring
it is correctly managed by usb_fill_int_urb() and freed by
usb_free_urb() as intended.(CVE-2024-53213)
In the Linux kernel, the following vulnerability has been resolved:
svcrdma: fix miss destroy percpu_counter in svc_rdma_proc_init()
There's issue as follows: RPC: Registered rdma transport module. RPC: Registered rdma backchannel transport module. RPC: Unregistered rdma transport module. RPC: Unregistered rdma backchannel transport module. BUG: unable to handle page fault for address: fffffbfff80c609a PGD 123fee067 P4D 123fee067 PUD 123fea067 PMD 10c624067 PTE 0 Oops: Oops: 0000 [#1] PREEMPT SMP KASAN NOPTI RIP: 0010:percpu_counter_destroy_many+0xf7/0x2a0 Call Trace: <TASK> __die+0x1f/0x70 page_fault_oops+0x2cd/0x860 spurious_kernel_fault+0x36/0x450 do_kern_addr_fault+0xca/0x100 exc_page_fault+0x128/0x150 asm_exc_page_fault+0x26/0x30 percpu_counter_destroy_many+0xf7/0x2a0 mmdrop+0x209/0x350 finish_task_switch.isra.0+0x481/0x840 schedule_tail+0xe/0xd0 ret_from_fork+0x23/0x80 ret_from_fork_asm+0x1a/0x30 </TASK>
If register_sysctl() return NULL, then svc_rdma_proc_cleanup() will not destroy the percpu counters which init in svc_rdma_proc_init(). If CONFIG_HOTPLUG_CPU is enabled, residual nodes may be in the 'percpu_counters' list. The above issue may occur once the module is removed. If the CONFIG_HOTPLUG_CPU configuration is not enabled, memory leakage occurs. To solve above issue just destroy all percpu counters when register_sysctl() return NULL.(CVE-2024-53215)
In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix race in concurrent f2fs_stop_gc_thread
In my test case, concurrent calls to f2fs shutdown report the following stack trace:
Oops: general protection fault, probably for non-canonical address 0xc6cfff63bb5513fc: 0000 [#1] PREEMPT SMP PTI CPU: 0 UID: 0 PID: 678 Comm: f2fs_rep_shutdo Not tainted 6.12.0-rc5-next-20241029-g6fb2fa9805c5-dirty #85 Call Trace: <TASK> ? show_regs+0x8b/0xa0 ? __die_body+0x26/0xa0 ? die_addr+0x54/0x90 ? exc_general_protection+0x24b/0x5c0 ? asm_exc_general_protection+0x26/0x30 ? kthread_stop+0x46/0x390 f2fs_stop_gc_thread+0x6c/0x110 f2fs_do_shutdown+0x309/0x3a0 f2fs_ioc_shutdown+0x150/0x1c0 __f2fs_ioctl+0xffd/0x2ac0 f2fs_ioctl+0x76/0xe0 vfs_ioctl+0x23/0x60 __x64_sys_ioctl+0xce/0xf0 x64_sys_call+0x2b1b/0x4540 do_syscall_64+0xa7/0x240 entry_SYSCALL_64_after_hwframe+0x76/0x7e
The root cause is a race condition in f2fs_stop_gc_thread() called from different f2fs shutdown paths:
[CPU0] [CPU1] ---------------------- ----------------------- f2fs_stop_gc_thread f2fs_stop_gc_thread gc_th = sbi->gc_thread gc_th = sbi->gc_thread kfree(gc_th) sbi->gc_thread = NULL < gc_th != NULL > kthread_stop(gc_th->f2fs_gc_task) //UAF
The commit c7f114d864ac ("f2fs: fix to avoid use-after-free in f2fs_stop_gc_thread()") attempted to fix this issue by using a read semaphore to prevent races between shutdown and remount threads, but it fails to prevent all race conditions.
Fix it by converting to write lock of s_umount in f2fs_do_shutdown().(CVE-2024-53218)
In the Linux kernel, the following vulnerability has been resolved:
virtiofs: use pages instead of pointer for kernel direct IO
When trying to insert a 10MB kernel module kept in a virtio-fs with cache disabled, the following warning was reported:
------------[ cut here ]------------ WARNING: CPU: 1 PID: 404 at mm/page_alloc.c:4551 ...... Modules linked in: CPU: 1 PID: 404 Comm: insmod Not tainted 6.9.0-rc5+ #123 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) ...... RIP: 0010:__alloc_pages+0x2bf/0x380 ...... Call Trace: <TASK> ? __warn+0x8e/0x150 ? __alloc_pages+0x2bf/0x380 __kmalloc_large_node+0x86/0x160 __kmalloc+0x33c/0x480 virtio_fs_enqueue_req+0x240/0x6d0 virtio_fs_wake_pending_and_unlock+0x7f/0x190 queue_request_and_unlock+0x55/0x60 fuse_simple_request+0x152/0x2b0 fuse_direct_io+0x5d2/0x8c0 fuse_file_read_iter+0x121/0x160 __kernel_read+0x151/0x2d0 kernel_read+0x45/0x50 kernel_read_file+0x1a9/0x2a0 init_module_from_file+0x6a/0xe0 idempotent_init_module+0x175/0x230 __x64_sys_finit_module+0x5d/0xb0 x64_sys_call+0x1c3/0x9e0 do_syscall_64+0x3d/0xc0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 ...... </TASK> ---[ end trace 0000000000000000 ]---
The warning is triggered as follows:
1) syscall finit_module() handles the module insertion and it invokes kernel_read_file() to read the content of the module first.
2) kernel_read_file() allocates a 10MB buffer by using vmalloc() and passes it to kernel_read(). kernel_read() constructs a kvec iter by using iov_iter_kvec() and passes it to fuse_file_read_iter().
3) virtio-fs disables the cache, so fuse_file_read_iter() invokes fuse_direct_io(). As for now, the maximal read size for kvec iter is only limited by fc->max_read. For virtio-fs, max_read is UINT_MAX, so fuse_direct_io() doesn't split the 10MB buffer. It saves the address and the size of the 10MB-sized buffer in out_args[0] of a fuse request and passes the fuse request to virtio_fs_wake_pending_and_unlock().
4) virtio_fs_wake_pending_and_unlock() uses virtio_fs_enqueue_req() to queue the request. Because virtiofs need DMA-able address, so virtio_fs_enqueue_req() uses kmalloc() to allocate a bounce buffer for all fuse args, copies these args into the bounce buffer and passed the physical address of the bounce buffer to virtiofsd. The total length of these fuse args for the passed fuse request is about 10MB, so copy_args_to_argbuf() invokes kmalloc() with a 10MB size parameter and it triggers the warning in __alloc_pages():
if (WARN_ON_ONCE_GFP(order > MAX_PAGE_ORDER, gfp))
return NULL;
5) virtio_fs_enqueue_req() will retry the memory allocation in a kworker, but it won't help, because kmalloc() will always return NULL due to the abnormal size and finit_module() will hang forever.
A feasible solution is to limit the value of max_read for virtio-fs, so the length passed to kmalloc() will be limited. However it will affect the maximal read size for normal read. And for virtio-fs write initiated from kernel, it has the similar problem but now there is no way to limit fc->max_write in kernel.
So instead of limiting both the values of max_read and max_write in kernel, introducing use_pages_for_kvec_io in fuse_conn and setting it as true in virtiofs. When use_pages_for_kvec_io is enabled, fuse will use pages instead of pointer to pass the KVEC_IO data.
After switching to pages for KVEC_IO data, these pages will be used for DMA through virtio-fs. If these pages are backed by vmalloc(), {flush|invalidate}_kernel_vmap_range() are necessary to flush or invalidate the cache before the DMA operation. So add two new fields in fuse_args_pages to record the base address of vmalloc area and the condition indicating whether invalidation is needed. Perform the flush in fuse_get_user_pages() for write operations and the invalidation in fuse_release_user_pages() for read operations.
It may seem necessary to introduce another fie ---truncated---(CVE-2024-53219)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/mlx5: Move events notifier registration to be after device registration
Move pkey change work initialization and cleanup from device resources stage to notifier stage, since this is the stage which handles this work events.
Fix a race between the device deregistration and pkey change work by moving MLX5_IB_STAGE_DEVICE_NOTIFIER to be after MLX5_IB_STAGE_IB_REG in order to ensure that the notifier is deregistered before the device during cleanup. Which ensures there are no works that are being executed after the device has already unregistered which can cause the panic below.
BUG: kernel NULL pointer dereference, address: 0000000000000000 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 630071 Comm: kworker/1:2 Kdump: loaded Tainted: G W OE --------- --- 5.14.0-162.6.1.el9_1.x86_64 #1 Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS 090008 02/27/2023 Workqueue: events pkey_change_handler [mlx5_ib] RIP: 0010:setup_qp+0x38/0x1f0 [mlx5_ib] Code: ee 41 54 45 31 e4 55 89 f5 53 48 89 fb 48 83 ec 20 8b 77 08 65 48 8b 04 25 28 00 00 00 48 89 44 24 18 48 8b 07 48 8d 4c 24 16 <4c> 8b 38 49 8b 87 80 0b 00 00 4c 89 ff 48 8b 80 08 05 00 00 8b 40 RSP: 0018:ffffbcc54068be20 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff954054494128 RCX: ffffbcc54068be36 RDX: ffff954004934000 RSI: 0000000000000001 RDI: ffff954054494128 RBP: 0000000000000023 R08: ffff954001be2c20 R09: 0000000000000001 R10: ffff954001be2c20 R11: ffff9540260133c0 R12: 0000000000000000 R13: 0000000000000023 R14: 0000000000000000 R15: ffff9540ffcb0905 FS: 0000000000000000(0000) GS:ffff9540ffc80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000010625c001 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: mlx5_ib_gsi_pkey_change+0x20/0x40 [mlx5_ib] process_one_work+0x1e8/0x3c0 worker_thread+0x50/0x3b0 ? rescuer_thread+0x380/0x380 kthread+0x149/0x170 ? set_kthread_struct+0x50/0x50 ret_from_fork+0x22/0x30 Modules linked in: rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_umad(OE) mlx5_ib(OE) mlx5_fwctl(OE) fwctl(OE) ib_uverbs(OE) mlx5_core(OE) mlxdevm(OE) ib_core(OE) mlx_compat(OE) psample mlxfw(OE) tls knem(OE) netconsole nfsv3 nfs_acl nfs lockd grace fscache netfs qrtr rfkill sunrpc intel_rapl_msr intel_rapl_common rapl hv_balloon hv_utils i2c_piix4 pcspkr joydev fuse ext4 mbcache jbd2 sr_mod sd_mod cdrom t10_pi sg ata_generic pci_hyperv pci_hyperv_intf hyperv_drm drm_shmem_helper drm_kms_helper hv_storvsc syscopyarea hv_netvsc sysfillrect sysimgblt hid_hyperv fb_sys_fops scsi_transport_fc hyperv_keyboard drm ata_piix crct10dif_pclmul crc32_pclmul crc32c_intel libata ghash_clmulni_intel hv_vmbus serio_raw [last unloaded: ib_core] CR2: 0000000000000000 ---[ end trace f6f8be4eae12f7bc ]---(CVE-2024-53224)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/hns: Fix NULL pointer derefernce in hns_roce_map_mr_sg()
ib_map_mr_sg() allows ULPs to specify NULL as the sg_offset argument. The driver needs to check whether it is a NULL pointer before dereferencing it.(CVE-2024-53226)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/rxe: Fix the qp flush warnings in req
When the qp is in error state, the status of WQEs in the queue should be set to error. Or else the following will appear.
[ 920.617269] WARNING: CPU: 1 PID: 21 at drivers/infiniband/sw/rxe/rxe_comp.c:756 rxe_completer+0x989/0xcc0 [rdma_rxe] [ 920.617744] Modules linked in: rnbd_client(O) rtrs_client(O) rtrs_core(O) rdma_ucm rdma_cm iw_cm ib_cm crc32_generic rdma_rxe ip6_udp_tunnel udp_tunnel ib_uverbs ib_core loop brd null_blk ipv6 [ 920.618516] CPU: 1 PID: 21 Comm: ksoftirqd/1 Tainted: G O 6.1.113-storage+ #65 [ 920.618986] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 [ 920.619396] RIP: 0010:rxe_completer+0x989/0xcc0 [rdma_rxe] [ 920.619658] Code: 0f b6 84 24 3a 02 00 00 41 89 84 24 44 04 00 00 e9 2a f7 ff ff 39 ca bb 03 00 00 00 b8 0e 00 00 00 48 0f 45 d8 e9 15 f7 ff ff <0f> 0b e9 cb f8 ff ff 41 bf f5 ff ff ff e9 08 f8 ff ff 49 8d bc 24 [ 920.620482] RSP: 0018:ffff97b7c00bbc38 EFLAGS: 00010246 [ 920.620817] RAX: 0000000000000000 RBX: 000000000000000c RCX: 0000000000000008 [ 920.621183] RDX: ffff960dc396ebc0 RSI: 0000000000005400 RDI: ffff960dc4e2fbac [ 920.621548] RBP: 0000000000000000 R08: 0000000000000001 R09: ffffffffac406450 [ 920.621884] R10: ffffffffac4060c0 R11: 0000000000000001 R12: ffff960dc4e2f800 [ 920.622254] R13: ffff960dc4e2f928 R14: ffff97b7c029c580 R15: 0000000000000000 [ 920.622609] FS: 0000000000000000(0000) GS:ffff960ef7d00000(0000) knlGS:0000000000000000 [ 920.622979] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 920.623245] CR2: 00007fa056965e90 CR3: 00000001107f1000 CR4: 00000000000006e0 [ 920.623680] Call Trace: [ 920.623815] <TASK> [ 920.623933] ? __warn+0x79/0xc0 [ 920.624116] ? rxe_completer+0x989/0xcc0 [rdma_rxe] [ 920.624356] ? report_bug+0xfb/0x150 [ 920.624594] ? handle_bug+0x3c/0x60 [ 920.624796] ? exc_invalid_op+0x14/0x70 [ 920.624976] ? asm_exc_invalid_op+0x16/0x20 [ 920.625203] ? rxe_completer+0x989/0xcc0 [rdma_rxe] [ 920.625474] ? rxe_completer+0x329/0xcc0 [rdma_rxe] [ 920.625749] rxe_do_task+0x80/0x110 [rdma_rxe] [ 920.626037] rxe_requester+0x625/0xde0 [rdma_rxe] [ 920.626310] ? rxe_cq_post+0xe2/0x180 [rdma_rxe] [ 920.626583] ? do_complete+0x18d/0x220 [rdma_rxe] [ 920.626812] ? rxe_completer+0x1a3/0xcc0 [rdma_rxe] [ 920.627050] rxe_do_task+0x80/0x110 [rdma_rxe] [ 920.627285] tasklet_action_common.constprop.0+0xa4/0x120 [ 920.627522] handle_softirqs+0xc2/0x250 [ 920.627728] ? sort_range+0x20/0x20 [ 920.627942] run_ksoftirqd+0x1f/0x30 [ 920.628158] smpboot_thread_fn+0xc7/0x1b0 [ 920.628334] kthread+0xd6/0x100 [ 920.628504] ? kthread_complete_and_exit+0x20/0x20 [ 920.628709] ret_from_fork+0x1f/0x30 [ 920.628892] </TASK>(CVE-2024-53229)
In the Linux kernel, the following vulnerability has been resolved:
cpufreq: CPPC: Fix possible null-ptr-deref for cpufreq_cpu_get_raw()
cpufreq_cpu_get_raw() may return NULL if the cpu is not in policy->cpus cpu mask and it will cause null pointer dereference.(CVE-2024-53231)
In the Linux kernel, the following vulnerability has been resolved:
erofs: handle NONHEAD !delta[1] lclusters gracefully
syzbot reported a WARNING in iomap_iter_done: iomap_fiemap+0x73b/0x9b0 fs/iomap/fiemap.c:80 ioctl_fiemap fs/ioctl.c:220 [inline]
Generally, NONHEAD lclusters won't have delta[1]==0, except for crafted images and filesystems created by pre-1.0 mkfs versions.
Previously, it would immediately bail out if delta[1]==0, which led to inadequate decompressed lengths (thus FIEMAP is impacted). Treat it as delta[1]=1 to work around these legacy mkfs versions.
lclusterbits > 14 is illegal for compact indexes, error out too.(CVE-2024-53234)
In the Linux kernel, the following vulnerability has been resolved:
ALSA: 6fire: Release resources at card release
The current 6fire code tries to release the resources right after the call of usb6fire_chip_abort(). But at this moment, the card object might be still in use (as we're calling snd_card_free_when_closed()).
For avoid potential UAFs, move the release of resources to the card's private_free instead of the manual call of usb6fire_chip_destroy() at the USB disconnect callback.(CVE-2024-53239)
In the Linux kernel, the following vulnerability has been resolved:
x86/xen: don't do PV iret hypercall through hypercall page
Instead of jumping to the Xen hypercall page for doing the iret hypercall, directly code the required sequence in xen-asm.S.
This is done in preparation of no longer using hypercall page at all, as it has shown to cause problems with speculation mitigations.
This is part of XSA-466 / CVE-2024-53241.(CVE-2024-53241)
In the Linux kernel, the following vulnerability has been resolved:
net: renesas: rswitch: avoid use-after-put for a device tree node
The device tree node saved in the rswitch_device structure is used at several driver locations. So passing this node to of_node_put() after the first use is wrong.
Move of_node_put() for this node to exit paths.(CVE-2024-55639)
In the Linux kernel, the following vulnerability has been resolved:
wifi: ath12k: Skip Rx TID cleanup for self peer
During peer create, dp setup for the peer is done where Rx TID is updated for all the TIDs. Peer object for self peer will not go through dp setup.
When core halts, dp cleanup is done for all the peers. While cleanup, rx_tid::ab is accessed which causes below stack trace for self peer.
WARNING: CPU: 6 PID: 12297 at drivers/net/wireless/ath/ath12k/dp_rx.c:851 Call Trace: __warn+0x7b/0x1a0 ath12k_dp_rx_frags_cleanup+0xd2/0xe0 [ath12k] report_bug+0x10b/0x200 handle_bug+0x3f/0x70 exc_invalid_op+0x13/0x60 asm_exc_invalid_op+0x16/0x20 ath12k_dp_rx_frags_cleanup+0xd2/0xe0 [ath12k] ath12k_dp_rx_frags_cleanup+0xca/0xe0 [ath12k] ath12k_dp_rx_peer_tid_cleanup+0x39/0xa0 [ath12k] ath12k_mac_peer_cleanup_all+0x61/0x100 [ath12k] ath12k_core_halt+0x3b/0x100 [ath12k] ath12k_core_reset+0x494/0x4c0 [ath12k]
sta object in peer will be updated when remote peer is created. Hence use peer::sta to detect the self peer and skip the cleanup.
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3(CVE-2024-56543)
In the Linux kernel, the following vulnerability has been resolved:
drivers: soc: xilinx: add the missing kfree in xlnx_add_cb_for_suspend()
If we fail to allocate memory for cb_data by kmalloc, the memory allocation for eve_data is never freed, add the missing kfree() in the error handling path.(CVE-2024-56546)
In the Linux kernel, the following vulnerability has been resolved:
cachefiles: Fix NULL pointer dereference in object->file
At present, the object->file has the NULL pointer dereference problem in ondemand-mode. The root cause is that the allocated fd and object->file lifetime are inconsistent, and the user-space invocation to anon_fd uses object->file. Following is the process that triggers the issue:
[write fd] [umount]
cachefiles_ondemand_fd_write_iter fscache_cookie_state_machine cachefiles_withdraw_cookie if (!file) return -ENOBUFS cachefiles_clean_up_object cachefiles_unmark_inode_in_use fput(object->file) object->file = NULL // file NULL pointer dereference! __cachefiles_write(..., file, ...)
Fix this issue by add an additional reference count to the object->file before write/llseek, and decrement after it finished.(CVE-2024-56549)
In the Linux kernel, the following vulnerability has been resolved:
i3c: master: Fix miss free init_dyn_addr at i3c_master_put_i3c_addrs()
if (dev->boardinfo && dev->boardinfo->init_dyn_addr) ^^^ here check "init_dyn_addr" i3c_bus_set_addr_slot_status(&master->bus, dev->info.dyn_addr, ...) ^^^^ free "dyn_addr" Fix copy/paste error "dyn_addr" by replacing it with "init_dyn_addr".(CVE-2024-56562)
In the Linux kernel, the following vulnerability has been resolved:
ovl: Filter invalid inodes with missing lookup function
Add a check to the ovl_dentry_weird() function to prevent the processing of directory inodes that lack the lookup function. This is important because such inodes can cause errors in overlayfs when passed to the lowerstack.(CVE-2024-56570)
In the Linux kernel, the following vulnerability has been resolved:
media: platform: allegro-dvt: Fix possible memory leak in allocate_buffers_internal()
The buffer in the loop should be released under the exception path, otherwise there may be a memory leak here.
To mitigate this, free the buffer when allegro_alloc_buffer fails.(CVE-2024-56572)
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix use-after-free in btrfs_encoded_read_endio()
Shinichiro reported the following use-after free that sometimes is happening in our CI system when running fstests' btrfs/284 on a TCMU runner device:
BUG: KASAN: slab-use-after-free in lock_release+0x708/0x780 Read of size 8 at addr ffff888106a83f18 by task kworker/u80:6/219
CPU: 8 UID: 0 PID: 219 Comm: kworker/u80:6 Not tainted 6.12.0-rc6-kts+ #15 Hardware name: Supermicro Super Server/X11SPi-TF, BIOS 3.3 02/21/2020 Workqueue: btrfs-endio btrfs_end_bio_work [btrfs] Call Trace: <TASK> dump_stack_lvl+0x6e/0xa0 ? lock_release+0x708/0x780 print_report+0x174/0x505 ? lock_release+0x708/0x780 ? __virt_addr_valid+0x224/0x410 ? lock_release+0x708/0x780 kasan_report+0xda/0x1b0 ? lock_release+0x708/0x780 ? __wake_up+0x44/0x60 lock_release+0x708/0x780 ? __pfx_lock_release+0x10/0x10 ? __pfx_do_raw_spin_lock+0x10/0x10 ? lock_is_held_type+0x9a/0x110 _raw_spin_unlock_irqrestore+0x1f/0x60 __wake_up+0x44/0x60 btrfs_encoded_read_endio+0x14b/0x190 [btrfs] btrfs_check_read_bio+0x8d9/0x1360 [btrfs] ? lock_release+0x1b0/0x780 ? trace_lock_acquire+0x12f/0x1a0 ? __pfx_btrfs_check_read_bio+0x10/0x10 [btrfs] ? process_one_work+0x7e3/0x1460 ? lock_acquire+0x31/0xc0 ? process_one_work+0x7e3/0x1460 process_one_work+0x85c/0x1460 ? __pfx_process_one_work+0x10/0x10 ? assign_work+0x16c/0x240 worker_thread+0x5e6/0xfc0 ? __pfx_worker_thread+0x10/0x10 kthread+0x2c3/0x3a0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x31/0x70 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK>
Allocated by task 3661: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 btrfs_encoded_read_regular_fill_pages+0x16c/0x6d0 [btrfs] send_extent_data+0xf0f/0x24a0 [btrfs] process_extent+0x48a/0x1830 [btrfs] changed_cb+0x178b/0x2ea0 [btrfs] btrfs_ioctl_send+0x3bf9/0x5c20 [btrfs] _btrfs_ioctl_send+0x117/0x330 [btrfs] btrfs_ioctl+0x184a/0x60a0 [btrfs] __x64_sys_ioctl+0x12e/0x1a0 do_syscall_64+0x95/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e
Freed by task 3661: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x70 __kasan_slab_free+0x4f/0x70 kfree+0x143/0x490 btrfs_encoded_read_regular_fill_pages+0x531/0x6d0 [btrfs] send_extent_data+0xf0f/0x24a0 [btrfs] process_extent+0x48a/0x1830 [btrfs] changed_cb+0x178b/0x2ea0 [btrfs] btrfs_ioctl_send+0x3bf9/0x5c20 [btrfs] _btrfs_ioctl_send+0x117/0x330 [btrfs] btrfs_ioctl+0x184a/0x60a0 [btrfs] __x64_sys_ioctl+0x12e/0x1a0 do_syscall_64+0x95/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e
The buggy address belongs to the object at ffff888106a83f00 which belongs to the cache kmalloc-rnd-07-96 of size 96 The buggy address is located 24 bytes inside of freed 96-byte region [ffff888106a83f00, ffff888106a83f60)
The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888106a83800 pfn:0x106a83 flags: 0x17ffffc0000000(node=0|zone=2|lastcpupid=0x1fffff) page_type: f5(slab) raw: 0017ffffc0000000 ffff888100053680 ffffea0004917200 0000000000000004 raw: ffff888106a83800 0000000080200019 00000001f5000000 0000000000000000 page dumped because: kasan: bad access detected
Memory state around the buggy address: ffff888106a83e00: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc ffff888106a83e80: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc >ffff888106a83f00: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc ^ ffff888106a83f80: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc ffff888106a84000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ==================================================================
Further analyzing the trace and ---truncated---(CVE-2024-56582)
In the Linux kernel, the following vulnerability has been resolved:
sched/deadline: Fix warning in migrate_enable for boosted tasks
When running the following command:
while true; do stress-ng --cyclic 30 --timeout 30s --minimize --quiet done
a warning is eventually triggered:
WARNING: CPU: 43 PID: 2848 at kernel/sched/deadline.c:794 setup_new_dl_entity+0x13e/0x180 ... Call Trace: <TASK> ? show_trace_log_lvl+0x1c4/0x2df ? enqueue_dl_entity+0x631/0x6e0 ? setup_new_dl_entity+0x13e/0x180 ? __warn+0x7e/0xd0 ? report_bug+0x11a/0x1a0 ? handle_bug+0x3c/0x70 ? exc_invalid_op+0x14/0x70 ? asm_exc_invalid_op+0x16/0x20 enqueue_dl_entity+0x631/0x6e0 enqueue_task_dl+0x7d/0x120 __do_set_cpus_allowed+0xe3/0x280 __set_cpus_allowed_ptr_locked+0x140/0x1d0 __set_cpus_allowed_ptr+0x54/0xa0 migrate_enable+0x7e/0x150 rt_spin_unlock+0x1c/0x90 group_send_sig_info+0xf7/0x1a0 ? kill_pid_info+0x1f/0x1d0 kill_pid_info+0x78/0x1d0 kill_proc_info+0x5b/0x110 __x64_sys_kill+0x93/0xc0 do_syscall_64+0x5c/0xf0 entry_SYSCALL_64_after_hwframe+0x6e/0x76 RIP: 0033:0x7f0dab31f92b
This warning occurs because set_cpus_allowed dequeues and enqueues tasks with the ENQUEUE_RESTORE flag set. If the task is boosted, the warning is triggered. A boosted task already had its parameters set by rt_mutex_setprio, and a new call to setup_new_dl_entity is unnecessary, hence the WARN_ON call.
Check if we are requeueing a boosted task and avoid calling setup_new_dl_entity if that's the case.(CVE-2024-56583)
In the Linux kernel, the following vulnerability has been resolved:
LoongArch: Fix sleeping in atomic context for PREEMPT_RT
Commit bab1c299f3945ffe79 ("LoongArch: Fix sleeping in atomic context in setup_tlb_handler()") changes the gfp flag from GFP_KERNEL to GFP_ATOMIC for alloc_pages_node(). However, for PREEMPT_RT kernels we can still get a "sleeping in atomic context" error:
[ 0.372259] BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 [ 0.372266] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/1 [ 0.372268] preempt_count: 1, expected: 0 [ 0.372270] RCU nest depth: 1, expected: 1 [ 0.372272] 3 locks held by swapper/1/0: [ 0.372274] #0: 900000000c9f5e60 (&pcp->lock){+.+.}-{3:3}, at: get_page_from_freelist+0x524/0x1c60 [ 0.372294] #1: 90000000087013b8 (rcu_read_lock){....}-{1:3}, at: rt_spin_trylock+0x50/0x140 [ 0.372305] #2: 900000047fffd388 (&zone->lock){+.+.}-{3:3}, at: __rmqueue_pcplist+0x30c/0xea0 [ 0.372314] irq event stamp: 0 [ 0.372316] hardirqs last enabled at (0): [<0000000000000000>] 0x0 [ 0.372322] hardirqs last disabled at (0): [<9000000005947320>] copy_process+0x9c0/0x26e0 [ 0.372329] softirqs last enabled at (0): [<9000000005947320>] copy_process+0x9c0/0x26e0 [ 0.372335] softirqs last disabled at (0): [<0000000000000000>] 0x0 [ 0.372341] CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Not tainted 6.12.0-rc7+ #1891 [ 0.372346] Hardware name: Loongson Loongson-3A5000-7A1000-1w-CRB/Loongson-LS3A5000-7A1000-1w-CRB, BIOS vUDK2018-LoongArch-V2.0.0-prebeta9 10/21/2022 [ 0.372349] Stack : 0000000000000089 9000000005a0db9c 90000000071519c8 9000000100388000 [ 0.372486] 900000010038b890 0000000000000000 900000010038b898 9000000007e53788 [ 0.372492] 900000000815bcc8 900000000815bcc0 900000010038b700 0000000000000001 [ 0.372498] 0000000000000001 4b031894b9d6b725 00000000055ec000 9000000100338fc0 [ 0.372503] 00000000000000c4 0000000000000001 000000000000002d 0000000000000003 [ 0.372509] 0000000000000030 0000000000000003 00000000055ec000 0000000000000003 [ 0.372515] 900000000806d000 9000000007e53788 00000000000000b0 0000000000000004 [ 0.372521] 0000000000000000 0000000000000000 900000000c9f5f10 0000000000000000 [ 0.372526] 90000000076f12d8 9000000007e53788 9000000005924778 0000000000000000 [ 0.372532] 00000000000000b0 0000000000000004 0000000000000000 0000000000070000 [ 0.372537] ... [ 0.372540] Call Trace: [ 0.372542] [<9000000005924778>] show_stack+0x38/0x180 [ 0.372548] [<90000000071519c4>] dump_stack_lvl+0x94/0xe4 [ 0.372555] [<900000000599b880>] __might_resched+0x1a0/0x260 [ 0.372561] [<90000000071675cc>] rt_spin_lock+0x4c/0x140 [ 0.372565] [<9000000005cbb768>] __rmqueue_pcplist+0x308/0xea0 [ 0.372570] [<9000000005cbed84>] get_page_from_freelist+0x564/0x1c60 [ 0.372575] [<9000000005cc0d98>] __alloc_pages_noprof+0x218/0x1820 [ 0.372580] [<900000000593b36c>] tlb_init+0x1ac/0x298 [ 0.372585] [<9000000005924b74>] per_cpu_trap_init+0x114/0x140 [ 0.372589] [<9000000005921964>] cpu_probe+0x4e4/0xa60 [ 0.372592] [<9000000005934874>] start_secondary+0x34/0xc0 [ 0.372599] [<900000000715615c>] smpboot_entry+0x64/0x6c
This is because in PREEMPT_RT kernels normal spinlocks are replaced by rt spinlocks and rt_spin_lock() will cause sleeping. Fix it by disabling NUMA optimization completely for PREEMPT_RT kernels.(CVE-2024-56585)
In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix f2fs_bug_on when uninstalling filesystem call f2fs_evict_inode.
creating a large files during checkpoint disable until it runs out of space and then delete it, then remount to enable checkpoint again, and then unmount the filesystem triggers the f2fs_bug_on as below:
------------[ cut here ]------------ kernel BUG at fs/f2fs/inode.c:896! CPU: 2 UID: 0 PID: 1286 Comm: umount Not tainted 6.11.0-rc7-dirty #360 Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI RIP: 0010:f2fs_evict_inode+0x58c/0x610 Call Trace: __die_body+0x15/0x60 die+0x33/0x50 do_trap+0x10a/0x120 f2fs_evict_inode+0x58c/0x610 do_error_trap+0x60/0x80 f2fs_evict_inode+0x58c/0x610 exc_invalid_op+0x53/0x60 f2fs_evict_inode+0x58c/0x610 asm_exc_invalid_op+0x16/0x20 f2fs_evict_inode+0x58c/0x610 evict+0x101/0x260 dispose_list+0x30/0x50 evict_inodes+0x140/0x190 generic_shutdown_super+0x2f/0x150 kill_block_super+0x11/0x40 kill_f2fs_super+0x7d/0x140 deactivate_locked_super+0x2a/0x70 cleanup_mnt+0xb3/0x140 task_work_run+0x61/0x90
The root cause is: creating large files during disable checkpoint period results in not enough free segments, so when writing back root inode will failed in f2fs_enable_checkpoint. When umount the file system after enabling checkpoint, the root inode is dirty in f2fs_evict_inode function, which triggers BUG_ON. The steps to reproduce are as follows:
dd if=/dev/zero of=f2fs.img bs=1M count=55 mount f2fs.img f2fs_dir -o checkpoint=disable:10% dd if=/dev/zero of=big bs=1M count=50 sync rm big mount -o remount,checkpoint=enable f2fs_dir umount f2fs_dir
Let's redirty inode when there is not free segments during checkpoint is disable.(CVE-2024-56586)
In the Linux kernel, the following vulnerability has been resolved:
bpf: Call free_htab_elem() after htab_unlock_bucket()
For htab of maps, when the map is removed from the htab, it may hold the last reference of the map. bpf_map_fd_put_ptr() will invoke bpf_map_free_id() to free the id of the removed map element. However, bpf_map_fd_put_ptr() is invoked while holding a bucket lock (raw_spin_lock_t), and bpf_map_free_id() attempts to acquire map_idr_lock (spinlock_t), triggering the following lockdep warning:
============================= [ BUG: Invalid wait context ] 6.11.0-rc4+ #49 Not tainted
test_maps/4881 is trying to lock: ffffffff84884578 (map_idr_lock){+...}-{3:3}, at: bpf_map_free_id.part.0+0x21/0x70 other info that might help us debug this: context-{5:5} 2 locks held by test_maps/4881: #0: ffffffff846caf60 (rcu_read_lock){....}-{1:3}, at: bpf_fd_htab_map_update_elem+0xf9/0x270 #1: ffff888149ced148 (&htab->lockdep_key#2){....}-{2:2}, at: htab_map_update_elem+0x178/0xa80 stack backtrace: CPU: 0 UID: 0 PID: 4881 Comm: test_maps Not tainted 6.11.0-rc4+ #49 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), ... Call Trace: <TASK> dump_stack_lvl+0x6e/0xb0 dump_stack+0x10/0x20 __lock_acquire+0x73e/0x36c0 lock_acquire+0x182/0x450 _raw_spin_lock_irqsave+0x43/0x70 bpf_map_free_id.part.0+0x21/0x70 bpf_map_put+0xcf/0x110 bpf_map_fd_put_ptr+0x9a/0xb0 free_htab_elem+0x69/0xe0 htab_map_update_elem+0x50f/0xa80 bpf_fd_htab_map_update_elem+0x131/0x270 htab_map_update_elem+0x50f/0xa80 bpf_fd_htab_map_update_elem+0x131/0x270 bpf_map_update_value+0x266/0x380 __sys_bpf+0x21bb/0x36b0 __x64_sys_bpf+0x45/0x60 x64_sys_call+0x1b2a/0x20d0 do_syscall_64+0x5d/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e
One way to fix the lockdep warning is using raw_spinlock_t for map_idr_lock as well. However, bpf_map_alloc_id() invokes idr_alloc_cyclic() after acquiring map_idr_lock, it will trigger a similar lockdep warning because the slab's lock (s->cpu_slab->lock) is still a spinlock.
Instead of changing map_idr_lock's type, fix the issue by invoking htab_put_fd_value() after htab_unlock_bucket(). However, only deferring the invocation of htab_put_fd_value() is not enough, because the old map pointers in htab of maps can not be saved during batched deletion. Therefore, also defer the invocation of free_htab_elem(), so these to-be-freed elements could be linked together similar to lru map.
There are four callers for ->map_fd_put_ptr:
(1) alloc_htab_elem() (through htab_put_fd_value()) It invokes ->map_fd_put_ptr() under a raw_spinlock_t. The invocation of htab_put_fd_value() can not simply move after htab_unlock_bucket(), because the old element has already been stashed in htab->extra_elems. It may be reused immediately after htab_unlock_bucket() and the invocation of htab_put_fd_value() after htab_unlock_bucket() may release the newly-added element incorrectly. Therefore, saving the map pointer of the old element for htab of maps before unlocking the bucket and releasing the map_ptr after unlock. Beside the map pointer in the old element, should do the same thing for the special fields in the old element as well.
(2) free_htab_elem() (through htab_put_fd_value()) Its caller includes __htab_map_lookup_and_delete_elem(), htab_map_delete_elem() and __htab_map_lookup_and_delete_batch().
For htab_map_delete_elem(), simply invoke free_htab_elem() after htab_unlock_bucket(). For __htab_map_lookup_and_delete_batch(), just like lru map, linking the to-be-freed element into node_to_free list and invoking free_htab_elem() for these element after unlock. It is safe to reuse batch_flink as the link for node_to_free, because these elements have been removed from the hash llist.
Because htab of maps doesn't support lookup_and_delete operation, __htab_map_lookup_and_delete_elem() doesn't have the problem, so kept it as ---truncated---(CVE-2024-56592)
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: set the right AMDGPU sg segment limitation
The driver needs to set the correct max_segment_size; otherwise debug_dma_map_sg() will complain about the over-mapping of the AMDGPU sg length as following:
WARNING: CPU: 6 PID: 1964 at kernel/dma/debug.c:1178 debug_dma_map_sg+0x2dc/0x370 [ 364.049444] Modules linked in: veth amdgpu(OE) amdxcp drm_exec gpu_sched drm_buddy drm_ttm_helper ttm(OE) drm_suballoc_helper drm_display_helper drm_kms_helper i2c_algo_bit rpcsec_gss_krb5 auth_rpcgss nfsv4 nfs lockd grace netfs xt_conntrack xt_MASQUERADE nf_conntrack_netlink xfrm_user xfrm_algo iptable_nat xt_addrtype iptable_filter br_netfilter nvme_fabrics overlay nfnetlink_cttimeout nfnetlink openvswitch nsh nf_conncount nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c bridge stp llc amd_atl intel_rapl_msr intel_rapl_common sunrpc sch_fq_codel snd_hda_codec_realtek snd_hda_codec_generic snd_hda_scodec_component snd_hda_codec_hdmi snd_hda_intel snd_intel_dspcfg edac_mce_amd binfmt_misc snd_hda_codec snd_pci_acp6x snd_hda_core snd_acp_config snd_hwdep snd_soc_acpi kvm_amd snd_pcm kvm snd_seq_midi snd_seq_midi_event crct10dif_pclmul ghash_clmulni_intel sha512_ssse3 snd_rawmidi sha256_ssse3 sha1_ssse3 aesni_intel snd_seq nls_iso8859_1 crypto_simd snd_seq_device cryptd snd_timer rapl input_leds snd [ 364.049532] ipmi_devintf wmi_bmof ccp serio_raw k10temp sp5100_tco soundcore ipmi_msghandler cm32181 industrialio mac_hid msr parport_pc ppdev lp parport drm efi_pstore ip_tables x_tables pci_stub crc32_pclmul nvme ahci libahci i2c_piix4 r8169 nvme_core i2c_designware_pci realtek i2c_ccgx_ucsi video wmi hid_generic cdc_ether usbnet usbhid hid r8152 mii [ 364.049576] CPU: 6 PID: 1964 Comm: rocminfo Tainted: G OE 6.10.0-custom #492 [ 364.049579] Hardware name: AMD Majolica-RN/Majolica-RN, BIOS RMJ1009A 06/13/2021 [ 364.049582] RIP: 0010:debug_dma_map_sg+0x2dc/0x370 [ 364.049585] Code: 89 4d b8 e8 36 b1 86 00 8b 4d b8 48 8b 55 b0 44 8b 45 a8 4c 8b 4d a0 48 89 c6 48 c7 c7 00 4b 74 bc 4c 89 4d b8 e8 b4 73 f3 ff <0f> 0b 4c 8b 4d b8 8b 15 c8 2c b8 01 85 d2 0f 85 ee fd ff ff 8b 05 [ 364.049588] RSP: 0018:ffff9ca600b57ac0 EFLAGS: 00010286 [ 364.049590] RAX: 0000000000000000 RBX: ffff88b7c132b0c8 RCX: 0000000000000027 [ 364.049592] RDX: ffff88bb0f521688 RSI: 0000000000000001 RDI: ffff88bb0f521680 [ 364.049594] RBP: ffff9ca600b57b20 R08: 000000000000006f R09: ffff9ca600b57930 [ 364.049596] R10: ffff9ca600b57928 R11: ffffffffbcb46328 R12: 0000000000000000 [ 364.049597] R13: 0000000000000001 R14: ffff88b7c19c0700 R15: ffff88b7c9059800 [ 364.049599] FS: 00007fb2d3516e80(0000) GS:ffff88bb0f500000(0000) knlGS:0000000000000000 [ 364.049601] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 364.049603] CR2: 000055610bd03598 CR3: 00000001049f6000 CR4: 0000000000350ef0 [ 364.049605] Call Trace: [ 364.049607] <TASK> [ 364.049609] ? show_regs+0x6d/0x80 [ 364.049614] ? __warn+0x8c/0x140 [ 364.049618] ? debug_dma_map_sg+0x2dc/0x370 [ 364.049621] ? report_bug+0x193/0x1a0 [ 364.049627] ? handle_bug+0x46/0x80 [ 364.049631] ? exc_invalid_op+0x1d/0x80 [ 364.049635] ? asm_exc_invalid_op+0x1f/0x30 [ 364.049642] ? debug_dma_map_sg+0x2dc/0x370 [ 364.049647] __dma_map_sg_attrs+0x90/0xe0 [ 364.049651] dma_map_sgtable+0x25/0x40 [ 364.049654] amdgpu_bo_move+0x59a/0x850 [amdgpu] [ 364.049935] ? srso_return_thunk+0x5/0x5f [ 364.049939] ? amdgpu_ttm_tt_populate+0x5d/0xc0 [amdgpu] [ 364.050095] ttm_bo_handle_move_mem+0xc3/0x180 [ttm] [ 364.050103] ttm_bo_validate+0xc1/0x160 [ttm] [ 364.050108] ? amdgpu_ttm_tt_get_user_pages+0xe5/0x1b0 [amdgpu] [ 364.050263] amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu+0xa12/0xc90 [amdgpu] [ 364.050473] kfd_ioctl_alloc_memory_of_gpu+0x16b/0x3b0 [amdgpu] [ 364.050680] kfd_ioctl+0x3c2/0x530 [amdgpu] [ 364.050866] ? __pfx_kfd_ioctl_alloc_memory_of_gpu+0x10/0x10 [amdgpu] [ 364.05105 ---truncated---(CVE-2024-56594)
In the Linux kernel, the following vulnerability has been resolved:
jfs: add a check to prevent array-index-out-of-bounds in dbAdjTree
When the value of lp is 0 at the beginning of the for loop, it will become negative in the next assignment and we should bail out.(CVE-2024-56595)
In the Linux kernel, the following vulnerability has been resolved:
jfs: fix array-index-out-of-bounds in jfs_readdir
The stbl might contain some invalid values. Added a check to return error code in that case.(CVE-2024-56596)
In the Linux kernel, the following vulnerability has been resolved:
jfs: fix shift-out-of-bounds in dbSplit
When dmt_budmin is less than zero, it causes errors in the later stages. Added a check to return an error beforehand in dbAllocCtl itself.(CVE-2024-56597)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: do not leave dangling sk pointer on error in l2cap_sock_create()
bt_sock_alloc() allocates the sk object and attaches it to the provided sock object. On error l2cap_sock_alloc() frees the sk object, but the dangling pointer is still attached to the sock object, which may create use-after-free in other code.(CVE-2024-56605)
In the Linux kernel, the following vulnerability has been resolved:
wifi: rtw88: use ieee80211_purge_tx_queue() to purge TX skb
When removing kernel modules by: rmmod rtw88_8723cs rtw88_8703b rtw88_8723x rtw88_sdio rtw88_core
Driver uses skb_queue_purge() to purge TX skb, but not report tx status causing "Have pending ack frames!" warning. Use ieee80211_purge_tx_queue() to correct this.
Since ieee80211_purge_tx_queue() doesn't take locks, to prevent racing between TX work and purge TX queue, flush and destroy TX work in advance.
wlan0: deauthenticating from aa:f5:fd:60:4c:a8 by local choice (Reason: 3=DEAUTH_LEAVING) ------------[ cut here ]------------ Have pending ack frames! WARNING: CPU: 3 PID: 9232 at net/mac80211/main.c:1691 ieee80211_free_ack_frame+0x5c/0x90 [mac80211] CPU: 3 PID: 9232 Comm: rmmod Tainted: G C 6.10.1-200.fc40.aarch64 #1 Hardware name: pine64 Pine64 PinePhone Braveheart (1.1)/Pine64 PinePhone Braveheart (1.1), BIOS 2024.01 01/01/2024 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : ieee80211_free_ack_frame+0x5c/0x90 [mac80211] lr : ieee80211_free_ack_frame+0x5c/0x90 [mac80211] sp : ffff80008c1b37b0 x29: ffff80008c1b37b0 x28: ffff000003be8000 x27: 0000000000000000 x26: 0000000000000000 x25: ffff000003dc14b8 x24: ffff80008c1b37d0 x23: ffff000000ff9f80 x22: 0000000000000000 x21: 000000007fffffff x20: ffff80007c7e93d8 x19: ffff00006e66f400 x18: 0000000000000000 x17: ffff7ffffd2b3000 x16: ffff800083fc0000 x15: 0000000000000000 x14: 0000000000000000 x13: 2173656d61726620 x12: 6b636120676e6964 x11: 0000000000000000 x10: 000000000000005d x9 : ffff8000802af2b0 x8 : ffff80008c1b3430 x7 : 0000000000000001 x6 : 0000000000000001 x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000003be8000 Call trace: ieee80211_free_ack_frame+0x5c/0x90 [mac80211] idr_for_each+0x74/0x110 ieee80211_free_hw+0x44/0xe8 [mac80211] rtw_sdio_remove+0x9c/0xc0 [rtw88_sdio] sdio_bus_remove+0x44/0x180 device_remove+0x54/0x90 device_release_driver_internal+0x1d4/0x238 driver_detach+0x54/0xc0 bus_remove_driver+0x78/0x108 driver_unregister+0x38/0x78 sdio_unregister_driver+0x2c/0x40 rtw_8723cs_driver_exit+0x18/0x1000 [rtw88_8723cs] __do_sys_delete_module.isra.0+0x190/0x338 __arm64_sys_delete_module+0x1c/0x30 invoke_syscall+0x74/0x100 el0_svc_common.constprop.0+0x48/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x3c/0x158 el0t_64_sync_handler+0x120/0x138 el0t_64_sync+0x194/0x198 ---[ end trace 0000000000000000 ]---(CVE-2024-56609)
In the Linux kernel, the following vulnerability has been resolved:
sched/numa: fix memory leak due to the overwritten vma->numab_state
[Problem Description] When running the hackbench program of LTP, the following memory leak is reported by kmemleak.
# /opt/ltp/testcases/bin/hackbench 20 thread 1000 Running with 20*40 (== 800) tasks.
# dmesg | grep kmemleak ... kmemleak: 480 new suspected memory leaks (see /sys/kernel/debug/kmemleak) kmemleak: 665 new suspected memory leaks (see /sys/kernel/debug/kmemleak)
# cat /sys/kernel/debug/kmemleak unreferenced object 0xffff888cd8ca2c40 (size 64): comm "hackbench", pid 17142, jiffies 4299780315 hex dump (first 32 bytes): ac 74 49 00 01 00 00 00 4c 84 49 00 01 00 00 00 .tI.....L.I..... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc bff18fd4): [<ffffffff81419a89>] __kmalloc_cache_noprof+0x2f9/0x3f0 [<ffffffff8113f715>] task_numa_work+0x725/0xa00 [<ffffffff8110f878>] task_work_run+0x58/0x90 [<ffffffff81ddd9f8>] syscall_exit_to_user_mode+0x1c8/0x1e0 [<ffffffff81dd78d5>] do_syscall_64+0x85/0x150 [<ffffffff81e0012b>] entry_SYSCALL_64_after_hwframe+0x76/0x7e ...
This issue can be consistently reproduced on three different servers: * a 448-core server * a 256-core server * a 192-core server
[Root Cause] Since multiple threads are created by the hackbench program (along with the command argument 'thread'), a shared vma might be accessed by two or more cores simultaneously. When two or more cores observe that vma->numab_state is NULL at the same time, vma->numab_state will be overwritten.
Although current code ensures that only one thread scans the VMAs in a single 'numa_scan_period', there might be a chance for another thread to enter in the next 'numa_scan_period' while we have not gotten till numab_state allocation [1].
Note that the command /opt/ltp/testcases/bin/hackbench 50 process 1000
cannot the reproduce the issue. It is verified with 200+ test runs.
[Solution] Use the cmpxchg atomic operation to ensure that only one thread executes the vma->numab_state assignment.
[1] https://lore.kernel.org/lkml/1794be3c-358c-4cdc-a43d-a1f841d91ef7@amd.com/(CVE-2024-56613)
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix potential out-of-bounds memory access in nilfs_find_entry()
Syzbot reported that when searching for records in a directory where the inode's i_size is corrupted and has a large value, memory access outside the folio/page range may occur, or a use-after-free bug may be detected if KASAN is enabled.
This is because nilfs_last_byte(), which is called by nilfs_find_entry() and others to calculate the number of valid bytes of directory data in a page from i_size and the page index, loses the upper 32 bits of the 64-bit size information due to an inappropriate type of local variable to which the i_size value is assigned.
This caused a large byte offset value due to underflow in the end address calculation in the calling nilfs_find_entry(), resulting in memory access that exceeds the folio/page size.
Fix this issue by changing the type of the local variable causing the bit loss from "unsigned int" to "u64". The return value of nilfs_last_byte() is also of type "unsigned int", but it is truncated so as not to exceed PAGE_SIZE and no bit loss occurs, so no change is required.(CVE-2024-56619)
In the Linux kernel, the following vulnerability has been resolved:
scsi: ufs: core: sysfs: Prevent div by zero
Prevent a division by 0 when monitoring is not enabled.(CVE-2024-56622)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix Out-of-Bounds Write in ksmbd_vfs_stream_write
An offset from client could be a negative value, It could allows to write data outside the bounds of the allocated buffer. Note that this issue is coming when setting 'vfs objects = streams_xattr parameter' in ksmbd.conf..(CVE-2024-56626)
In the Linux kernel, the following vulnerability has been resolved:
scsi: sg: Fix slab-use-after-free read in sg_release()
Fix a use-after-free bug in sg_release(), detected by syzbot with KASAN:
BUG: KASAN: slab-use-after-free in lock_release+0x151/0xa30 kernel/locking/lockdep.c:5838 __mutex_unlock_slowpath+0xe2/0x750 kernel/locking/mutex.c:912 sg_release+0x1f4/0x2e0 drivers/scsi/sg.c:407
In sg_release(), the function kref_put(&sfp->f_ref, sg_remove_sfp) is called before releasing the open_rel_lock mutex. The kref_put() call may decrement the reference count of sfp to zero, triggering its cleanup through sg_remove_sfp(). This cleanup includes scheduling deferred work via sg_remove_sfp_usercontext(), which ultimately frees sfp.
After kref_put(), sg_release() continues to unlock open_rel_lock and may reference sfp or sdp. If sfp has already been freed, this results in a slab-use-after-free error.
Move the kref_put(&sfp->f_ref, sg_remove_sfp) call after unlocking the open_rel_lock mutex. This ensures:
-
No references to sfp or sdp occur after the reference count is decremented.
-
Cleanup functions such as sg_remove_sfp() and sg_remove_sfp_usercontext() can safely execute without impacting the mutex handling in sg_release().
The fix has been tested and validated by syzbot. This patch closes the bug reported at the following syzkaller link and ensures proper sequencing of resource cleanup and mutex operations, eliminating the risk of use-after-free errors in sg_release().(CVE-2024-56631)
In the Linux kernel, the following vulnerability has been resolved:
tcp_bpf: Fix the sk_mem_uncharge logic in tcp_bpf_sendmsg
The current sk memory accounting logic in __SK_REDIRECT is pre-uncharging tosend bytes, which is either msg->sg.size or a smaller value apply_bytes.
Potential problems with this strategy are as follows:
-
If the actual sent bytes are smaller than tosend, we need to charge some bytes back, as in line 487, which is okay but seems not clean.
-
When tosend is set to apply_bytes, as in line 417, and (ret < 0), we may miss uncharging (msg->sg.size - apply_bytes) bytes.
[...] 415 tosend = msg->sg.size; 416 if (psock->apply_bytes && psock->apply_bytes < tosend) 417 tosend = psock->apply_bytes; [...] 443 sk_msg_return(sk, msg, tosend); 444 release_sock(sk); 446 origsize = msg->sg.size; 447 ret = tcp_bpf_sendmsg_redir(sk_redir, redir_ingress, 448 msg, tosend, flags); 449 sent = origsize - msg->sg.size; [...] 454 lock_sock(sk); 455 if (unlikely(ret < 0)) { 456 int free = sk_msg_free_nocharge(sk, msg); 458 if (!cork) 459 *copied -= free; 460 } [...] 487 if (eval == __SK_REDIRECT) 488 sk_mem_charge(sk, tosend - sent); [...]
When running the selftest test_txmsg_redir_wait_sndmem with txmsg_apply, the following warning will be reported:
------------[ cut here ]------------ WARNING: CPU: 6 PID: 57 at net/ipv4/af_inet.c:156 inet_sock_destruct+0x190/0x1a0 Modules linked in: CPU: 6 UID: 0 PID: 57 Comm: kworker/6:0 Not tainted 6.12.0-rc1.bm.1-amd64+ #43 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 Workqueue: events sk_psock_destroy RIP: 0010:inet_sock_destruct+0x190/0x1a0 RSP: 0018:ffffad0a8021fe08 EFLAGS: 00010206 RAX: 0000000000000011 RBX: ffff9aab4475b900 RCX: ffff9aab481a0800 RDX: 0000000000000303 RSI: 0000000000000011 RDI: ffff9aab4475b900 RBP: ffff9aab4475b990 R08: 0000000000000000 R09: ffff9aab40050ec0 R10: 0000000000000000 R11: ffff9aae6fdb1d01 R12: ffff9aab49c60400 R13: ffff9aab49c60598 R14: ffff9aab49c60598 R15: dead000000000100 FS: 0000000000000000(0000) GS:ffff9aae6fd80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffec7e47bd8 CR3: 00000001a1a1c004 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> ? __warn+0x89/0x130 ? inet_sock_destruct+0x190/0x1a0 ? report_bug+0xfc/0x1e0 ? handle_bug+0x5c/0xa0 ? exc_invalid_op+0x17/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? inet_sock_destruct+0x190/0x1a0 __sk_destruct+0x25/0x220 sk_psock_destroy+0x2b2/0x310 process_scheduled_works+0xa3/0x3e0 worker_thread+0x117/0x240 ? __pfx_worker_thread+0x10/0x10 kthread+0xcf/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x31/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> ---[ end trace 0000000000000000 ]---
In __SK_REDIRECT, a more concise way is delaying the uncharging after sent bytes are finalized, and uncharge this value. When (ret < 0), we shall invoke sk_msg_free.
Same thing happens in case __SK_DROP, when tosend is set to apply_bytes, we may miss uncharging (msg->sg.size - apply_bytes) bytes. The same warning will be reported in selftest.
[...] 468 case __SK_DROP: 469 default: 470 sk_msg_free_partial(sk, msg, tosend); 471 sk_msg_apply_bytes(psock, tosend); 472 *copied -= (tosend + delta); 473 return -EACCES; [...]
So instead of sk_msg_free_partial we can do sk_msg_free here.(CVE-2024-56633)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nft_inner: incorrect percpu area handling under softirq
Softirq can interrupt ongoing packet from process context that is walking over the percpu area that contains inner header offsets.
Disable bh and perform three checks before restoring the percpu inner header offsets to validate that the percpu area is valid for this skbuff:
1) If the NFT_PKTINFO_INNER_FULL flag is set on, then this skbuff has already been parsed before for inner header fetching to register.
2) Validate that the percpu area refers to this skbuff using the skbuff pointer as a cookie. If there is a cookie mismatch, then this skbuff needs to be parsed again.
3) Finally, validate if the percpu area refers to this tunnel type.
Only after these three checks the percpu area is restored to a on-stack copy and bh is enabled again.
After inner header fetching, the on-stack copy is stored back to the percpu area.(CVE-2024-56638)
In the Linux kernel, the following vulnerability has been resolved:
net: enetc: Do not configure preemptible TCs if SIs do not support
Both ENETC PF and VF drivers share enetc_setup_tc_mqprio() to configure MQPRIO. And enetc_setup_tc_mqprio() calls enetc_change_preemptible_tcs() to configure preemptible TCs. However, only PF is able to configure preemptible TCs. Because only PF has related registers, while VF does not have these registers. So for VF, its hw->port pointer is NULL. Therefore, VF will access an invalid pointer when accessing a non-existent register, which will cause a crash issue. The simplified log is as follows.
root@ls1028ardb:~# tc qdisc add dev eno0vf0 parent root handle 100: \ mqprio num_tc 4 map 0 0 1 1 2 2 3 3 queues 1@0 1@1 1@2 1@3 hw 1 [ 187.290775] Unable to handle kernel paging request at virtual address 0000000000001f00 [ 187.424831] pc : enetc_mm_commit_preemptible_tcs+0x1c4/0x400 [ 187.430518] lr : enetc_mm_commit_preemptible_tcs+0x30c/0x400 [ 187.511140] Call trace: [ 187.513588] enetc_mm_commit_preemptible_tcs+0x1c4/0x400 [ 187.518918] enetc_setup_tc_mqprio+0x180/0x214 [ 187.523374] enetc_vf_setup_tc+0x1c/0x30 [ 187.527306] mqprio_enable_offload+0x144/0x178 [ 187.531766] mqprio_init+0x3ec/0x668 [ 187.535351] qdisc_create+0x15c/0x488 [ 187.539023] tc_modify_qdisc+0x398/0x73c [ 187.542958] rtnetlink_rcv_msg+0x128/0x378 [ 187.547064] netlink_rcv_skb+0x60/0x130 [ 187.550910] rtnetlink_rcv+0x18/0x24 [ 187.554492] netlink_unicast+0x300/0x36c [ 187.558425] netlink_sendmsg+0x1a8/0x420 [ 187.606759] ---[ end trace 0000000000000000 ]---
In addition, some PFs also do not support configuring preemptible TCs, such as eno1 and eno3 on LS1028A. It won't crash like it does for VFs, but we should prevent these PFs from accessing these unimplemented registers.(CVE-2024-56649)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_event: Fix using rcu_read_(un)lock while iterating
The usage of rcu_read_(un)lock while inside list_for_each_entry_rcu is not safe since for the most part entries fetched this way shall be treated as rcu_dereference:
Note that the value returned by rcu_dereference() is valid
only within the enclosing RCU read-side critical section [1]_.
For example, the following is **not** legal::
rcu_read_lock();
p = rcu_dereference(head.next);
rcu_read_unlock();
x = p->address; /* BUG!!! */
rcu_read_lock();
y = p->data; /* BUG!!! */
rcu_read_unlock();(CVE-2024-56654)
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: DR, prevent potential error pointer dereference
The dr_domain_add_vport_cap() function generally returns NULL on error but sometimes we want it to return ERR_PTR(-EBUSY) so the caller can retry. The problem here is that "ret" can be either -EBUSY or -ENOMEM and if it's and -ENOMEM then the error pointer is propogated back and eventually dereferenced in dr_ste_v0_build_src_gvmi_qpn_tag().(CVE-2024-56660)
In the Linux kernel, the following vulnerability has been resolved:
acpi: nfit: vmalloc-out-of-bounds Read in acpi_nfit_ctl
Fix an issue detected by syzbot with KASAN:
BUG: KASAN: vmalloc-out-of-bounds in cmd_to_func drivers/acpi/nfit/ core.c:416 [inline] BUG: KASAN: vmalloc-out-of-bounds in acpi_nfit_ctl+0x20e8/0x24a0 drivers/acpi/nfit/core.c:459
The issue occurs in cmd_to_func when the call_pkg->nd_reserved2 array is accessed without verifying that call_pkg points to a buffer that is appropriately sized as a struct nd_cmd_pkg. This can lead to out-of-bounds access and undefined behavior if the buffer does not have sufficient space.
To address this, a check was added in acpi_nfit_ctl() to ensure that buf is not NULL and that buf_len is less than sizeof(*call_pkg) before accessing it. This ensures safe access to the members of call_pkg, including the nd_reserved2 array.(CVE-2024-56662)
In the Linux kernel, the following vulnerability has been resolved:
wifi: nl80211: fix NL80211_ATTR_MLO_LINK_ID off-by-one
Since the netlink attribute range validation provides inclusive checking, the max of attribute NL80211_ATTR_MLO_LINK_ID should be IEEE80211_MLD_MAX_NUM_LINKS - 1 otherwise causing an off-by-one.
One crash stack for demonstration:
BUG: KASAN: wild-memory-access in ieee80211_tx_control_port+0x3b6/0xca0 net/mac80211/tx.c:5939 Read of size 6 at addr 001102080000000c by task fuzzer.386/9508
CPU: 1 PID: 9508 Comm: syz.1.386 Not tainted 6.1.70 #2 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x177/0x231 lib/dump_stack.c:106 print_report+0xe0/0x750 mm/kasan/report.c:398 kasan_report+0x139/0x170 mm/kasan/report.c:495 kasan_check_range+0x287/0x290 mm/kasan/generic.c:189 memcpy+0x25/0x60 mm/kasan/shadow.c:65 ieee80211_tx_control_port+0x3b6/0xca0 net/mac80211/tx.c:5939 rdev_tx_control_port net/wireless/rdev-ops.h:761 [inline] nl80211_tx_control_port+0x7b3/0xc40 net/wireless/nl80211.c:15453 genl_family_rcv_msg_doit+0x22e/0x320 net/netlink/genetlink.c:756 genl_family_rcv_msg net/netlink/genetlink.c:833 [inline] genl_rcv_msg+0x539/0x740 net/netlink/genetlink.c:850 netlink_rcv_skb+0x1de/0x420 net/netlink/af_netlink.c:2508 genl_rcv+0x24/0x40 net/netlink/genetlink.c:861 netlink_unicast_kernel net/netlink/af_netlink.c:1326 [inline] netlink_unicast+0x74b/0x8c0 net/netlink/af_netlink.c:1352 netlink_sendmsg+0x882/0xb90 net/netlink/af_netlink.c:1874 sock_sendmsg_nosec net/socket.c:716 [inline] __sock_sendmsg net/socket.c:728 [inline] _syssendmsg+0x5cc/0x8f0 net/socket.c:2499 _sys_sendmsg+0x21c/0x290 net/socket.c:2553 __sys_sendmsg net/socket.c:2582 [inline] __do_sys_sendmsg net/socket.c:2591 [inline] __se_sys_sendmsg+0x19e/0x270 net/socket.c:2589 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x45/0x90 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x63/0xcd
Update the policy to ensure correct validation.(CVE-2024-56663)
In the Linux kernel, the following vulnerability has been resolved:
drm/i915: Fix NULL pointer dereference in capture_engine
When the intel_context structure contains NULL, it raises a NULL pointer dereference error in drm_info().
(cherry picked from commit 754302a5bc1bd8fd3b7d85c168b0a1af6d4bba4d)(CVE-2024-56667)
In the Linux kernel, the following vulnerability has been resolved:
blk-cgroup: Fix UAF in blkcg_unpin_online()
blkcg_unpin_online() walks up the blkcg hierarchy putting the online pin. To walk up, it uses blkcg_parent(blkcg) but it was calling that after blkcg_destroy_blkgs(blkcg) which could free the blkcg, leading to the following UAF:
================================================================== BUG: KASAN: slab-use-after-free in blkcg_unpin_online+0x15a/0x270 Read of size 8 at addr ffff8881057678c0 by task kworker/9:1/117
CPU: 9 UID: 0 PID: 117 Comm: kworker/9:1 Not tainted 6.13.0-rc1-work-00182-gb8f52214c61a-dirty #48 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS unknown 02/02/2022 Workqueue: cgwb_release cgwb_release_workfn Call Trace: <TASK> dump_stack_lvl+0x27/0x80 print_report+0x151/0x710 kasan_report+0xc0/0x100 blkcg_unpin_online+0x15a/0x270 cgwb_release_workfn+0x194/0x480 process_scheduled_works+0x71b/0xe20 worker_thread+0x82a/0xbd0 kthread+0x242/0x2c0 ret_from_fork+0x33/0x70 ret_from_fork_asm+0x1a/0x30 </TASK> ... Freed by task 1944: kasan_save_track+0x2b/0x70 kasan_save_free_info+0x3c/0x50 __kasan_slab_free+0x33/0x50 kfree+0x10c/0x330 css_free_rwork_fn+0xe6/0xb30 process_scheduled_works+0x71b/0xe20 worker_thread+0x82a/0xbd0 kthread+0x242/0x2c0 ret_from_fork+0x33/0x70 ret_from_fork_asm+0x1a/0x30
Note that the UAF is not easy to trigger as the free path is indirected behind a couple RCU grace periods and a work item execution. I could only trigger it with artifical msleep() injected in blkcg_unpin_online().
Fix it by reading the parent pointer before destroying the blkcg's blkg's.(CVE-2024-56672)
In the Linux kernel, the following vulnerability has been resolved:
octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_common.c
Add error pointer check after calling otx2_mbox_get_rsp().(CVE-2024-56679)
In the Linux kernel, the following vulnerability has been resolved:
mfd: intel_soc_pmic_bxtwc: Use IRQ domain for USB Type-C device
While design wise the idea of converting the driver to use the hierarchy of the IRQ chips is correct, the implementation has (inherited) flaws. This was unveiled when platform_get_irq() had started WARN() on IRQ 0 that is supposed to be a Linux IRQ number (also known as vIRQ).
Rework the driver to respect IRQ domain when creating each MFD device separately, as the domain is not the same for all of them.(CVE-2024-56691)
In the Linux kernel, the following vulnerability has been resolved:
bpf, sockmap: Several fixes to bpf_msg_pop_data
Several fixes to bpf_msg_pop_data, 1. In sk_msg_shift_left, we should put_page 2. if (len == 0), return early is better 3. pop the entire sk_msg (last == msg->sg.size) should be supported 4. Fix for the value of variable "a" 5. In sk_msg_shift_left, after shifting, i has already pointed to the next element. Addtional sk_msg_iter_var_next may result in BUG.(CVE-2024-56720)
In the Linux kernel, the following vulnerability has been resolved:
octeontx2-pf: handle otx2_mbox_get_rsp errors in cn10k.c
Add error pointer check after calling otx2_mbox_get_rsp().(CVE-2024-56726)
In the Linux kernel, the following vulnerability has been resolved:
rtc: check if __rtc_read_time was successful in rtc_timer_do_work()
If the __rtc_read_time call fails,, the struct rtc_time tm; may contain uninitialized data, or an illegal date/time read from the RTC hardware.
When calling rtc_tm_to_ktime later, the result may be a very large value (possibly KTIME_MAX). If there are periodic timers in rtc->timerqueue, they will continually expire, may causing kernel softlockup.(CVE-2024-56739)
In the Linux kernel, the following vulnerability has been resolved:
vfio/mlx5: Fix an unwind issue in mlx5vf_add_migration_pages()
Fix an unwind issue in mlx5vf_add_migration_pages().
If a set of pages is allocated but fails to be added to the SG table, they need to be freed to prevent a memory leak.
Any pages successfully added to the SG table will be freed as part of mlx5vf_free_data_buffer().(CVE-2024-56742)
In the Linux kernel, the following vulnerability has been resolved:
PCI: Fix reset_method_store() memory leak
In reset_method_store(), a string is allocated via kstrndup() and assigned to the local "options". options is then used in with strsep() to find spaces:
while ((name = strsep(&options, " ")) != NULL) {
If there are no remaining spaces, then options is set to NULL by strsep(), so the subsequent kfree(options) doesn't free the memory allocated via kstrndup().
Fix by using a separate tmp_options to iterate with strsep() so options is preserved.(CVE-2024-56745)
In the Linux kernel, the following vulnerability has been resolved:
scsi: qedi: Fix a possible memory leak in qedi_alloc_and_init_sb()
Hook "qedi_ops->common->sb_init = qed_sb_init" does not release the DMA memory sb_virt when it fails. Add dma_free_coherent() to free it. This is the same way as qedr_alloc_mem_sb() and qede_alloc_mem_sb().(CVE-2024-56747)
In the Linux kernel, the following vulnerability has been resolved:
netfs/fscache: Add a memory barrier for FSCACHE_VOLUME_CREATING
In fscache_create_volume(), there is a missing memory barrier between the bit-clearing operation and the wake-up operation. This may cause a situation where, after a wake-up, the bit-clearing operation hasn't been detected yet, leading to an indefinite wait. The triggering process is as follows:
[cookie1] [cookie2] [volume_work] fscache_perform_lookup fscache_create_volume fscache_perform_lookup fscache_create_volume fscache_create_volume_work cachefiles_acquire_volume clear_and_wake_up_bit test_and_set_bit test_and_set_bit goto maybe_wait goto no_wait
In the above process, cookie1 and cookie2 has the same volume. When cookie1 enters the -no_wait- process, it will clear the bit and wake up the waiting process. If a barrier is missing, it may cause cookie2 to remain in the -wait- process indefinitely.
In commit 3288666c7256 ("fscache: Use clear_and_wake_up_bit() in fscache_create_volume_work()"), barriers were added to similar operations in fscache_create_volume_work(), but fscache_create_volume() was missed.
By combining the clear and wake operations into clear_and_wake_up_bit() to fix this issue.(CVE-2024-56755)
In the Linux kernel, the following vulnerability has been resolved:
nvme-pci: fix freeing of the HMB descriptor table
The HMB descriptor table is sized to the maximum number of descriptors that could be used for a given device, but __nvme_alloc_host_mem could break out of the loop earlier on memory allocation failure and end up using less descriptors than planned for, which leads to an incorrect size passed to dma_free_coherent.
In practice this was not showing up because the number of descriptors tends to be low and the dma coherent allocator always allocates and frees at least a page.(CVE-2024-56756)
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix use-after-free when COWing tree bock and tracing is enabled
When a COWing a tree block, at btrfs_cow_block(), and we have the tracepoint trace_btrfs_cow_block() enabled and preemption is also enabled (CONFIG_PREEMPT=y), we can trigger a use-after-free in the COWed extent buffer while inside the tracepoint code. This is because in some paths that call btrfs_cow_block(), such as btrfs_search_slot(), we are holding the last reference on the extent buffer @buf so btrfs_force_cow_block() drops the last reference on the @buf extent buffer when it calls free_extent_buffer_stale(buf), which schedules the release of the extent buffer with RCU. This means that if we are on a kernel with preemption, the current task may be preempted before calling trace_btrfs_cow_block() and the extent buffer already released by the time trace_btrfs_cow_block() is called, resulting in a use-after-free.
Fix this by moving the trace_btrfs_cow_block() from btrfs_cow_block() to btrfs_force_cow_block() before the COWed extent buffer is freed. This also has a side effect of invoking the tracepoint in the tree defrag code, at defrag.c:btrfs_realloc_node(), since btrfs_force_cow_block() is called there, but this is fine and it was actually missing there.(CVE-2024-56759)
In the Linux kernel, the following vulnerability has been resolved:
tracing: Prevent bad count for tracing_cpumask_write
If a large count is provided, it will trigger a warning in bitmap_parse_user. Also check zero for it.(CVE-2024-56763)
| URL | Type | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-6.6.0-75.0.0.68.oe2403.aarch64.rpm",
"bpftool-debuginfo-6.6.0-75.0.0.68.oe2403.aarch64.rpm",
"kernel-6.6.0-75.0.0.68.oe2403.aarch64.rpm",
"kernel-debuginfo-6.6.0-75.0.0.68.oe2403.aarch64.rpm",
"kernel-debugsource-6.6.0-75.0.0.68.oe2403.aarch64.rpm",
"kernel-devel-6.6.0-75.0.0.68.oe2403.aarch64.rpm",
"kernel-headers-6.6.0-75.0.0.68.oe2403.aarch64.rpm",
"kernel-source-6.6.0-75.0.0.68.oe2403.aarch64.rpm",
"kernel-tools-6.6.0-75.0.0.68.oe2403.aarch64.rpm",
"kernel-tools-debuginfo-6.6.0-75.0.0.68.oe2403.aarch64.rpm",
"kernel-tools-devel-6.6.0-75.0.0.68.oe2403.aarch64.rpm",
"perf-6.6.0-75.0.0.68.oe2403.aarch64.rpm",
"perf-debuginfo-6.6.0-75.0.0.68.oe2403.aarch64.rpm",
"python3-perf-6.6.0-75.0.0.68.oe2403.aarch64.rpm",
"python3-perf-debuginfo-6.6.0-75.0.0.68.oe2403.aarch64.rpm"
],
"src": [
"kernel-6.6.0-75.0.0.68.oe2403.src.rpm"
],
"x86_64": [
"bpftool-6.6.0-75.0.0.68.oe2403.x86_64.rpm",
"bpftool-debuginfo-6.6.0-75.0.0.68.oe2403.x86_64.rpm",
"kernel-6.6.0-75.0.0.68.oe2403.x86_64.rpm",
"kernel-debuginfo-6.6.0-75.0.0.68.oe2403.x86_64.rpm",
"kernel-debugsource-6.6.0-75.0.0.68.oe2403.x86_64.rpm",
"kernel-devel-6.6.0-75.0.0.68.oe2403.x86_64.rpm",
"kernel-headers-6.6.0-75.0.0.68.oe2403.x86_64.rpm",
"kernel-source-6.6.0-75.0.0.68.oe2403.x86_64.rpm",
"kernel-tools-6.6.0-75.0.0.68.oe2403.x86_64.rpm",
"kernel-tools-debuginfo-6.6.0-75.0.0.68.oe2403.x86_64.rpm",
"kernel-tools-devel-6.6.0-75.0.0.68.oe2403.x86_64.rpm",
"perf-6.6.0-75.0.0.68.oe2403.x86_64.rpm",
"perf-debuginfo-6.6.0-75.0.0.68.oe2403.x86_64.rpm",
"python3-perf-6.6.0-75.0.0.68.oe2403.x86_64.rpm",
"python3-perf-debuginfo-6.6.0-75.0.0.68.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-75.0.0.68.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:\n\nnet: can: j1939: enhanced error handling for tightly received RTS messages in xtp_rx_rts_session_new\n\nThis patch enhances error handling in scenarios with RTS (Request to\nSend) messages arriving closely. It replaces the less informative WARN_ON_ONCE\nbacktraces with a new error handling method. This provides clearer error\nmessages and allows for the early termination of problematic sessions.\nPreviously, sessions were only released at the end of j1939_xtp_rx_rts().\n\nPotentially this could be reproduced with something like:\ntestj1939 -r vcan0:0x80 \u0026amp;\nwhile true; do\n\t# send first RTS\n\tcansend vcan0 18EC8090#1014000303002301;\n\t# send second RTS\n\tcansend vcan0 18EC8090#1014000303002301;\n\t# send abort\n\tcansend vcan0 18EC8090#ff00000000002301;\ndone(CVE-2023-52887)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: L2CAP: Fix slab-use-after-free in l2cap_connect()\n\nExtend a critical section to prevent chan from early freeing.\nAlso make the l2cap_connect() return type void. Nothing is using the\nreturned value but it is ugly to return a potentially freed pointer.\nMaking it void will help with backports because earlier kernels did use\nthe return value. Now the compile will break for kernels where this\npatch is not a complete fix.\n\nCall stack summary:\n\n[use]\nl2cap_bredr_sig_cmd\n l2cap_connect\n \u250c mutex_lock(\u0026amp;conn-\u0026gt;chan_lock);\n \u2502 chan = pchan-\u0026gt;ops-\u0026gt;new_connection(pchan); \u0026lt;- alloc chan\n \u2502 __l2cap_chan_add(conn, chan);\n \u2502 l2cap_chan_hold(chan);\n \u2502 list_add(\u0026amp;chan-\u0026gt;list, \u0026amp;conn-\u0026gt;chan_l); ... (1)\n \u2514 mutex_unlock(\u0026amp;conn-\u0026gt;chan_lock);\n chan-\u0026gt;conf_state ... (4) \u0026lt;- use after free\n\n[free]\nl2cap_conn_del\n\u250c mutex_lock(\u0026amp;conn-\u0026gt;chan_lock);\n\u2502 foreach chan in conn-\u0026gt;chan_l: ... (2)\n\u2502 l2cap_chan_put(chan);\n\u2502 l2cap_chan_destroy\n\u2502 kfree(chan) ... (3) \u0026lt;- chan freed\n\u2514 mutex_unlock(\u0026amp;conn-\u0026gt;chan_lock);\n\n==================================================================\nBUG: KASAN: slab-use-after-free in instrument_atomic_read\ninclude/linux/instrumented.h:68 [inline]\nBUG: KASAN: slab-use-after-free in _test_bit\ninclude/asm-generic/bitops/instrumented-non-atomic.h:141 [inline]\nBUG: KASAN: slab-use-after-free in l2cap_connect+0xa67/0x11a0\nnet/bluetooth/l2cap_core.c:4260\nRead of size 8 at addr ffff88810bf040a0 by task kworker/u3:1/311(CVE-2024-36013)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: hns3: fix kernel crash when devlink reload during pf initialization\n\nThe devlink reload process will access the hardware resources,\nbut the register operation is done before the hardware is initialized.\nSo, processing the devlink reload during initialization may lead to kernel\ncrash. This patch fixes this by taking devl_lock during initialization.(CVE-2024-36021)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbnxt_re: avoid shift undefined behavior in bnxt_qplib_alloc_init_hwq\n\nUndefined behavior is triggered when bnxt_qplib_alloc_init_hwq is called\nwith hwq_attr-\u0026gt;aux_depth != 0 and hwq_attr-\u0026gt;aux_stride == 0.\nIn that case, \u0026quot;roundup_pow_of_two(hwq_attr-\u0026gt;aux_stride)\u0026quot; gets called.\nroundup_pow_of_two is documented as undefined for 0.\n\nFix it in the one caller that had this combination.\n\nThe undefined behavior was detected by UBSAN:\n UBSAN: shift-out-of-bounds in ./include/linux/log2.h:57:13\n shift exponent 64 is too large for 64-bit type \u0026apos;long unsigned int\u0026apos;\n CPU: 24 PID: 1075 Comm: (udev-worker) Not tainted 6.9.0-rc6+ #4\n Hardware name: Abacus electric, s.r.o. - servis@abacus.cz Super Server/H12SSW-iN, BIOS 2.7 10/25/2023\n Call Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x5d/0x80\n ubsan_epilogue+0x5/0x30\n __ubsan_handle_shift_out_of_bounds.cold+0x61/0xec\n __roundup_pow_of_two+0x25/0x35 [bnxt_re]\n bnxt_qplib_alloc_init_hwq+0xa1/0x470 [bnxt_re]\n bnxt_qplib_create_qp+0x19e/0x840 [bnxt_re]\n bnxt_re_create_qp+0x9b1/0xcd0 [bnxt_re]\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? __kmalloc+0x1b6/0x4f0\n ? create_qp.part.0+0x128/0x1c0 [ib_core]\n ? __pfx_bnxt_re_create_qp+0x10/0x10 [bnxt_re]\n create_qp.part.0+0x128/0x1c0 [ib_core]\n ib_create_qp_kernel+0x50/0xd0 [ib_core]\n create_mad_qp+0x8e/0xe0 [ib_core]\n ? __pfx_qp_event_handler+0x10/0x10 [ib_core]\n ib_mad_init_device+0x2be/0x680 [ib_core]\n add_client_context+0x10d/0x1a0 [ib_core]\n enable_device_and_get+0xe0/0x1d0 [ib_core]\n ib_register_device+0x53c/0x630 [ib_core]\n ? srso_alias_return_thunk+0x5/0xfbef5\n bnxt_re_probe+0xbd8/0xe50 [bnxt_re]\n ? __pfx_bnxt_re_probe+0x10/0x10 [bnxt_re]\n auxiliary_bus_probe+0x49/0x80\n ? driver_sysfs_add+0x57/0xc0\n really_probe+0xde/0x340\n ? pm_runtime_barrier+0x54/0x90\n ? __pfx___driver_attach+0x10/0x10\n __driver_probe_device+0x78/0x110\n driver_probe_device+0x1f/0xa0\n __driver_attach+0xba/0x1c0\n bus_for_each_dev+0x8f/0xe0\n bus_add_driver+0x146/0x220\n driver_register+0x72/0xd0\n __auxiliary_driver_register+0x6e/0xd0\n ? __pfx_bnxt_re_mod_init+0x10/0x10 [bnxt_re]\n bnxt_re_mod_init+0x3e/0xff0 [bnxt_re]\n ? __pfx_bnxt_re_mod_init+0x10/0x10 [bnxt_re]\n do_one_initcall+0x5b/0x310\n do_init_module+0x90/0x250\n init_module_from_file+0x86/0xc0\n idempotent_init_module+0x121/0x2b0\n __x64_sys_finit_module+0x5e/0xb0\n do_syscall_64+0x82/0x160\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? syscall_exit_to_user_mode_prepare+0x149/0x170\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? syscall_exit_to_user_mode+0x75/0x230\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? do_syscall_64+0x8e/0x160\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? __count_memcg_events+0x69/0x100\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? count_memcg_events.constprop.0+0x1a/0x30\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? handle_mm_fault+0x1f0/0x300\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? do_user_addr_fault+0x34e/0x640\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? srso_alias_return_thunk+0x5/0xfbef5\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n RIP: 0033:0x7f4e5132821d\n Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 8b 0d e3 db 0c 00 f7 d8 64 89 01 48\n RSP: 002b:00007ffca9c906a8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139\n RAX: ffffffffffffffda RBX: 0000563ec8a8f130 RCX: 00007f4e5132821d\n RDX: 0000000000000000 RSI: 00007f4e518fa07d RDI: 000000000000003b\n RBP: 00007ffca9c90760 R08: 00007f4e513f6b20 R09: 00007ffca9c906f0\n R10: 0000563ec8a8faa0 R11: 0000000000000246 R12: 00007f4e518fa07d\n R13: 0000000000020000 R14: 0000563ec8409e90 R15: 0000563ec8a8fa60\n \u0026lt;/TASK\u0026gt;\n ---[ end trace ]---(CVE-2024-38540)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: atomisp: ssh_css: Fix a null-pointer dereference in load_video_binaries\n\nThe allocation failure of mycs-\u0026gt;yuv_scaler_binary in load_video_binaries()\nis followed with a dereference of mycs-\u0026gt;yuv_scaler_binary after the\nfollowing call chain:\n\nsh_css_pipe_load_binaries()\n |-\u0026gt; load_video_binaries(mycs-\u0026gt;yuv_scaler_binary == NULL)\n |\n |-\u0026gt; sh_css_pipe_unload_binaries()\n |-\u0026gt; unload_video_binaries()\n\nIn unload_video_binaries(), it calls to ia_css_binary_unload with argument\n\u0026amp;pipe-\u0026gt;pipe_settings.video.yuv_scaler_binary[i], which refers to the\nsame memory slot as mycs-\u0026gt;yuv_scaler_binary. Thus, a null-pointer\ndereference is triggered.(CVE-2024-38547)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\num: Add winch to winch_handlers before registering winch IRQ\n\nRegistering a winch IRQ is racy, an interrupt may occur before the winch is\nadded to the winch_handlers list.\n\nIf that happens, register_winch_irq() adds to that list a winch that is\nscheduled to be (or has already been) freed, causing a panic later in\nwinch_cleanup().\n\nAvoid the race by adding the winch to the winch_handlers list before\nregistering the IRQ, and rolling back if um_request_irq() fails.(CVE-2024-39292)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/shmem-helper: Fix BUG_ON() on mmap(PROT_WRITE, MAP_PRIVATE)\n\nLack of check for copy-on-write (COW) mapping in drm_gem_shmem_mmap\nallows users to call mmap with PROT_WRITE and MAP_PRIVATE flag\ncausing a kernel panic due to BUG_ON in vmf_insert_pfn_prot:\nBUG_ON((vma-\u0026gt;vm_flags \u0026amp; VM_PFNMAP) \u0026amp;\u0026amp; is_cow_mapping(vma-\u0026gt;vm_flags));\n\nReturn -EINVAL early if COW mapping is detected.\n\nThis bug affects all drm drivers using default shmem helpers.\nIt can be reproduced by this simple example:\nvoid *ptr = mmap(0, size, PROT_WRITE, MAP_PRIVATE, fd, mmap_offset);\nptr[0] = 0;(CVE-2024-39497)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mac80211: mesh: Fix leak of mesh_preq_queue objects\n\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().\n\nThis should take care of KASAN reports like this:\n\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)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\njfs: don\u0026apos;t walk off the end of ealist\n\nAdd a check before visiting the members of ea to\nmake sure each ea stays within the ealist.(CVE-2024-41017)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu: Fix signedness bug in sdma_v4_0_process_trap_irq()\n\nThe \u0026quot;instance\u0026quot; variable needs to be signed for the error handling to work.(CVE-2024-41022)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nFix userfaultfd_api to return EINVAL as expected\n\nCurrently if we request a feature that is not set in the Kernel config we\nfail silently and return all the available features. However, the man\npage indicates we should return an EINVAL.\n\nWe need to fix this issue since we can end up with a Kernel warning should\na program request the feature UFFD_FEATURE_WP_UNPOPULATED on a kernel with\nthe config not set with this feature.\n\n [ 200.812896] WARNING: CPU: 91 PID: 13634 at mm/memory.c:1660 zap_pte_range+0x43d/0x660\n [ 200.820738] Modules linked in:\n [ 200.869387] CPU: 91 PID: 13634 Comm: userfaultfd Kdump: loaded Not tainted 6.9.0-rc5+ #8\n [ 200.877477] Hardware name: Dell Inc. PowerEdge R6525/0N7YGH, BIOS 2.7.3 03/30/2022\n [ 200.885052] RIP: 0010:zap_pte_range+0x43d/0x660(CVE-2024-41027)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnilfs2: fix kernel bug on rename operation of broken directory\n\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.\n\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.\n\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)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm: prevent derefencing NULL ptr in pfn_section_valid()\n\nCommit 5ec8e8ea8b77 (\u0026quot;mm/sparsemem: fix race in accessing\nmemory_section-\u0026gt;usage\u0026quot;) changed pfn_section_valid() to add a READ_ONCE()\ncall around \u0026quot;ms-\u0026gt;usage\u0026quot; to fix a race with section_deactivate() where\nms-\u0026gt;usage can be cleared. The READ_ONCE() call, by itself, is not enough\nto prevent NULL pointer dereference. We need to check its value before\ndereferencing it.(CVE-2024-41055)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/pseries: Whitelist dtl slub object for copying to userspace\n\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.\n\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\n\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)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: PPC: Book3S HV: Prevent UAF in kvm_spapr_tce_attach_iommu_group()\n\nAl reported a possible use-after-free (UAF) in kvm_spapr_tce_attach_iommu_group().\n\nIt looks up `stt` from tablefd, but then continues to use it after doing\nfdput() on the returned fd. After the fdput() the tablefd is free to be\nclosed by another thread. The close calls kvm_spapr_tce_release() and\nthen release_spapr_tce_table() (via call_rcu()) which frees `stt`.\n\nAlthough there are calls to rcu_read_lock() in\nkvm_spapr_tce_attach_iommu_group() they are not sufficient to prevent\nthe UAF, because `stt` is used outside the locked regions.\n\nWith an artifcial delay after the fdput() and a userspace program which\ntriggers the race, KASAN detects the UAF:\n\n BUG: KASAN: slab-use-after-free in kvm_spapr_tce_attach_iommu_group+0x298/0x720 [kvm]\n Read of size 4 at addr c000200027552c30 by task kvm-vfio/2505\n CPU: 54 PID: 2505 Comm: kvm-vfio Not tainted 6.10.0-rc3-next-20240612-dirty #1\n Hardware name: 8335-GTH POWER9 0x4e1202 opal:skiboot-v6.5.3-35-g1851b2a06 PowerNV\n Call Trace:\n dump_stack_lvl+0xb4/0x108 (unreliable)\n print_report+0x2b4/0x6ec\n kasan_report+0x118/0x2b0\n __asan_load4+0xb8/0xd0\n kvm_spapr_tce_attach_iommu_group+0x298/0x720 [kvm]\n kvm_vfio_set_attr+0x524/0xac0 [kvm]\n kvm_device_ioctl+0x144/0x240 [kvm]\n sys_ioctl+0x62c/0x1810\n system_call_exception+0x190/0x440\n system_call_vectored_common+0x15c/0x2ec\n ...\n Freed by task 0:\n ...\n kfree+0xec/0x3e0\n release_spapr_tce_table+0xd4/0x11c [kvm]\n rcu_core+0x568/0x16a0\n handle_softirqs+0x23c/0x920\n do_softirq_own_stack+0x6c/0x90\n do_softirq_own_stack+0x58/0x90\n __irq_exit_rcu+0x218/0x2d0\n irq_exit+0x30/0x80\n arch_local_irq_restore+0x128/0x230\n arch_local_irq_enable+0x1c/0x30\n cpuidle_enter_state+0x134/0x5cc\n cpuidle_enter+0x6c/0xb0\n call_cpuidle+0x7c/0x100\n do_idle+0x394/0x410\n cpu_startup_entry+0x60/0x70\n start_secondary+0x3fc/0x410\n start_secondary_prolog+0x10/0x14\n\nFix it by delaying the fdput() until `stt` is no longer in use, which\nis effectively the entire function. To keep the patch minimal add a call\nto fdput() at each of the existing return paths. Future work can convert\nthe function to goto or __cleanup style cleanup.\n\nWith the fix in place the test case no longer triggers the UAF.(CVE-2024-41070)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: qgroup: fix quota root leak after quota disable failure\n\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).\n\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)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nila: block BH in ila_output()\n\nAs explained in commit 1378817486d6 (\u0026quot;tipc: block BH\nbefore using dst_cache\u0026quot;), net/core/dst_cache.c\nhelpers need to be called with BH disabled.\n\nila_output() is called from lwtunnel_output()\npossibly from process context, and under rcu_read_lock().\n\nWe might be interrupted by a softirq, re-enter ila_output()\nand corrupt dst_cache data structures.\n\nFix the race by using local_bh_disable().(CVE-2024-41081)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/nouveau/dispnv04: fix null pointer dereference in nv17_tv_get_hd_modes\n\nIn nv17_tv_get_hd_modes(), the return value of drm_mode_duplicate() is\nassigned to mode, which will lead to a possible NULL pointer dereference\non failure of drm_mode_duplicate(). The same applies to drm_cvt_mode().\nAdd a check to avoid null pointer dereference.(CVE-2024-41089)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/nouveau/dispnv04: fix null pointer dereference in nv17_tv_get_ld_modes\n\nIn nv17_tv_get_ld_modes(), the return value of drm_mode_duplicate() is\nassigned to mode, which will lead to a possible NULL pointer dereference\non failure of drm_mode_duplicate(). Add a check to avoid npd.(CVE-2024-41095)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: atm: cxacru: fix endpoint checking in cxacru_bind()\n\nSyzbot is still reporting quite an old issue [1] that occurs due to\nincomplete checking of present usb endpoints. As such, wrong\nendpoints types may be used at urb sumbitting stage which in turn\ntriggers a warning in usb_submit_urb().\n\nFix the issue by verifying that required endpoint types are present\nfor both in and out endpoints, taking into account cmd endpoint type.\n\nUnfortunately, this patch has not been tested on real hardware.\n\n[1] Syzbot report:\nusb 1-1: BOGUS urb xfer, pipe 1 != type 3\nWARNING: CPU: 0 PID: 8667 at drivers/usb/core/urb.c:502 usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502\nModules linked in:\nCPU: 0 PID: 8667 Comm: kworker/0:4 Not tainted 5.14.0-rc4-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011\nWorkqueue: usb_hub_wq hub_event\nRIP: 0010:usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502\n...\nCall Trace:\n cxacru_cm+0x3c0/0x8e0 drivers/usb/atm/cxacru.c:649\n cxacru_card_status+0x22/0xd0 drivers/usb/atm/cxacru.c:760\n cxacru_bind+0x7ac/0x11a0 drivers/usb/atm/cxacru.c:1209\n usbatm_usb_probe+0x321/0x1ae0 drivers/usb/atm/usbatm.c:1055\n cxacru_usb_probe+0xdf/0x1e0 drivers/usb/atm/cxacru.c:1363\n usb_probe_interface+0x315/0x7f0 drivers/usb/core/driver.c:396\n call_driver_probe drivers/base/dd.c:517 [inline]\n really_probe+0x23c/0xcd0 drivers/base/dd.c:595\n __driver_probe_device+0x338/0x4d0 drivers/base/dd.c:747\n driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:777\n __device_attach_driver+0x20b/0x2f0 drivers/base/dd.c:894\n bus_for_each_drv+0x15f/0x1e0 drivers/base/bus.c:427\n __device_attach+0x228/0x4a0 drivers/base/dd.c:965\n bus_probe_device+0x1e4/0x290 drivers/base/bus.c:487\n device_add+0xc2f/0x2180 drivers/base/core.c:3354\n usb_set_configuration+0x113a/0x1910 drivers/usb/core/message.c:2170\n usb_generic_driver_probe+0xba/0x100 drivers/usb/core/generic.c:238\n usb_probe_device+0xd9/0x2c0 drivers/usb/core/driver.c:293(CVE-2024-41097)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: can: j1939: Initialize unused data in j1939_send_one()\n\nsyzbot reported kernel-infoleak in raw_recvmsg() [1]. j1939_send_one()\ncreates full frame including unused data, but it doesn\u0026apos;t initialize\nit. This causes the kernel-infoleak issue. Fix this by initializing\nunused data.\n\n[1]\nBUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline]\nBUG: KMSAN: kernel-infoleak in copy_to_user_iter lib/iov_iter.c:24 [inline]\nBUG: KMSAN: kernel-infoleak in iterate_ubuf include/linux/iov_iter.h:29 [inline]\nBUG: KMSAN: kernel-infoleak in iterate_and_advance2 include/linux/iov_iter.h:245 [inline]\nBUG: KMSAN: kernel-infoleak in iterate_and_advance include/linux/iov_iter.h:271 [inline]\nBUG: KMSAN: kernel-infoleak in _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185\n instrument_copy_to_user include/linux/instrumented.h:114 [inline]\n copy_to_user_iter lib/iov_iter.c:24 [inline]\n iterate_ubuf include/linux/iov_iter.h:29 [inline]\n iterate_and_advance2 include/linux/iov_iter.h:245 [inline]\n iterate_and_advance include/linux/iov_iter.h:271 [inline]\n _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185\n copy_to_iter include/linux/uio.h:196 [inline]\n memcpy_to_msg include/linux/skbuff.h:4113 [inline]\n raw_recvmsg+0x2b8/0x9e0 net/can/raw.c:1008\n sock_recvmsg_nosec net/socket.c:1046 [inline]\n sock_recvmsg+0x2c4/0x340 net/socket.c:1068\n ____sys_recvmsg+0x18a/0x620 net/socket.c:2803\n ___sys_recvmsg+0x223/0x840 net/socket.c:2845\n do_recvmmsg+0x4fc/0xfd0 net/socket.c:2939\n __sys_recvmmsg net/socket.c:3018 [inline]\n __do_sys_recvmmsg net/socket.c:3041 [inline]\n __se_sys_recvmmsg net/socket.c:3034 [inline]\n __x64_sys_recvmmsg+0x397/0x490 net/socket.c:3034\n x64_sys_call+0xf6c/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:300\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\nUninit was created at:\n slab_post_alloc_hook mm/slub.c:3804 [inline]\n slab_alloc_node mm/slub.c:3845 [inline]\n kmem_cache_alloc_node+0x613/0xc50 mm/slub.c:3888\n kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:577\n __alloc_skb+0x35b/0x7a0 net/core/skbuff.c:668\n alloc_skb include/linux/skbuff.h:1313 [inline]\n alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6504\n sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2795\n sock_alloc_send_skb include/net/sock.h:1842 [inline]\n j1939_sk_alloc_skb net/can/j1939/socket.c:878 [inline]\n j1939_sk_send_loop net/can/j1939/socket.c:1142 [inline]\n j1939_sk_sendmsg+0xc0a/0x2730 net/can/j1939/socket.c:1277\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg+0x30f/0x380 net/socket.c:745\n ____sys_sendmsg+0x877/0xb60 net/socket.c:2584\n ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638\n __sys_sendmsg net/socket.c:2667 [inline]\n __do_sys_sendmsg net/socket.c:2676 [inline]\n __se_sys_sendmsg net/socket.c:2674 [inline]\n __x64_sys_sendmsg+0x307/0x4a0 net/socket.c:2674\n x64_sys_call+0xc4b/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:47\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\nBytes 12-15 of 16 are uninitialized\nMemory access of size 16 starts at ffff888120969690\nData copied to user address 00000000200017c0\n\nCPU: 1 PID: 5050 Comm: syz-executor198 Not tainted 6.9.0-rc5-syzkaller-00031-g71b1543c83d6 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024(CVE-2024-42076)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nocfs2: fix DIO failure due to insufficient transaction credits\n\nThe code in ocfs2_dio_end_io_write() estimates number of necessary\ntransaction credits using ocfs2_calc_extend_credits(). This however does\nnot take into account that the IO could be arbitrarily large and can\ncontain arbitrary number of extents.\n\nExtent tree manipulations do often extend the current transaction but not\nin all of the cases. For example if we have only single block extents in\nthe tree, ocfs2_mark_extent_written() will end up calling\nocfs2_replace_extent_rec() all the time and we will never extend the\ncurrent transaction and eventually exhaust all the transaction credits if\nthe IO contains many single block extents. Once that happens a\nWARN_ON(jbd2_handle_buffer_credits(handle) \u0026lt;= 0) is triggered in\njbd2_journal_dirty_metadata() and subsequently OCFS2 aborts in response to\nthis error. This was actually triggered by one of our customers on a\nheavily fragmented OCFS2 filesystem.\n\nTo fix the issue make sure the transaction always has enough credits for\none extent insert before each call of ocfs2_mark_extent_written().\n\nHeming Zhao said:\n\n------\nPANIC: \u0026quot;Kernel panic - not syncing: OCFS2: (device dm-1): panic forced after error\u0026quot;\n\nPID: xxx TASK: xxxx CPU: 5 COMMAND: \u0026quot;SubmitThread-CA\u0026quot;\n #0 machine_kexec at ffffffff8c069932\n #1 __crash_kexec at ffffffff8c1338fa\n #2 panic at ffffffff8c1d69b9\n #3 ocfs2_handle_error at ffffffffc0c86c0c [ocfs2]\n #4 __ocfs2_abort at ffffffffc0c88387 [ocfs2]\n #5 ocfs2_journal_dirty at ffffffffc0c51e98 [ocfs2]\n #6 ocfs2_split_extent at ffffffffc0c27ea3 [ocfs2]\n #7 ocfs2_change_extent_flag at ffffffffc0c28053 [ocfs2]\n #8 ocfs2_mark_extent_written at ffffffffc0c28347 [ocfs2]\n #9 ocfs2_dio_end_io_write at ffffffffc0c2bef9 [ocfs2]\n#10 ocfs2_dio_end_io at ffffffffc0c2c0f5 [ocfs2]\n#11 dio_complete at ffffffff8c2b9fa7\n#12 do_blockdev_direct_IO at ffffffff8c2bc09f\n#13 ocfs2_direct_IO at ffffffffc0c2b653 [ocfs2]\n#14 generic_file_direct_write at ffffffff8c1dcf14\n#15 __generic_file_write_iter at ffffffff8c1dd07b\n#16 ocfs2_file_write_iter at ffffffffc0c49f1f [ocfs2]\n#17 aio_write at ffffffff8c2cc72e\n#18 kmem_cache_alloc at ffffffff8c248dde\n#19 do_io_submit at ffffffff8c2ccada\n#20 do_syscall_64 at ffffffff8c004984\n#21 entry_SYSCALL_64_after_hwframe at ffffffff8c8000ba(CVE-2024-42077)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/restrack: Fix potential invalid address access\n\nstruct rdma_restrack_entry\u0026apos;s kern_name was set to KBUILD_MODNAME\nin ib_create_cq(), while if the module exited but forgot del this\nrdma_restrack_entry, it would cause a invalid address access in\nrdma_restrack_clean() when print the owner of this rdma_restrack_entry.\n\nThese code is used to help find one forgotten PD release in one of the\nULPs. But it is not needed anymore, so delete them.(CVE-2024-42080)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxdp: Remove WARN() from __xdp_reg_mem_model()\n\nsyzkaller reports a warning in __xdp_reg_mem_model().\n\nThe warning occurs only if __mem_id_init_hash_table() returns an error. It\nreturns the error in two cases:\n\n 1. memory allocation fails;\n 2. rhashtable_init() fails when some fields of rhashtable_params\n struct are not initialized properly.\n\nThe second case cannot happen since there is a static const rhashtable_params\nstruct with valid fields. So, warning is only triggered when there is a\nproblem with memory allocation.\n\nThus, there is no sense in using WARN() to handle this error and it can be\nsafely removed.\n\nWARNING: CPU: 0 PID: 5065 at net/core/xdp.c:299 __xdp_reg_mem_model+0x2d9/0x650 net/core/xdp.c:299\n\nCPU: 0 PID: 5065 Comm: syz-executor883 Not tainted 6.8.0-syzkaller-05271-gf99c5f563c17 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024\nRIP: 0010:__xdp_reg_mem_model+0x2d9/0x650 net/core/xdp.c:299\n\nCall Trace:\n xdp_reg_mem_model+0x22/0x40 net/core/xdp.c:344\n xdp_test_run_setup net/bpf/test_run.c:188 [inline]\n bpf_test_run_xdp_live+0x365/0x1e90 net/bpf/test_run.c:377\n bpf_prog_test_run_xdp+0x813/0x11b0 net/bpf/test_run.c:1267\n bpf_prog_test_run+0x33a/0x3b0 kernel/bpf/syscall.c:4240\n __sys_bpf+0x48d/0x810 kernel/bpf/syscall.c:5649\n __do_sys_bpf kernel/bpf/syscall.c:5738 [inline]\n __se_sys_bpf kernel/bpf/syscall.c:5736 [inline]\n __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:5736\n do_syscall_64+0xfb/0x240\n entry_SYSCALL_64_after_hwframe+0x6d/0x75\n\nFound by Linux Verification Center (linuxtesting.org) with syzkaller.(CVE-2024-42082)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nftruncate: pass a signed offset\n\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.\n\nChanging the type of the compat syscall to the signed compat_off_t\nchanges the behavior so it instead returns -EINVAL.\n\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)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/panel: ilitek-ili9881c: Fix warning with GPIO controllers that sleep\n\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)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nASoC: fsl-asoc-card: set priv-\u0026gt;pdev before using it\n\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.\n\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)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npinctrl: fix deadlock in create_pinctrl() when handling -EPROBE_DEFER\n\nIn create_pinctrl(), pinctrl_maps_mutex is acquired before calling\nadd_setting(). If add_setting() returns -EPROBE_DEFER, create_pinctrl()\ncalls pinctrl_free(). However, pinctrl_free() attempts to acquire\npinctrl_maps_mutex, which is already held by create_pinctrl(), leading to\na potential deadlock.\n\nThis patch resolves the issue by releasing pinctrl_maps_mutex before\ncalling pinctrl_free(), preventing the deadlock.\n\nThis bug was discovered and resolved using Coverity Static Analysis\nSecurity Testing (SAST) by Synopsys, Inc.(CVE-2024-42090)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ngpio: davinci: Validate the obtained number of IRQs\n\nValue of pdata-\u0026gt;gpio_unbanked is taken from Device Tree. In case of broken\nDT due to any error this value can be any. Without this value validation\nthere can be out of chips-\u0026gt;irqs array boundaries access in\ndavinci_gpio_probe().\n\nValidate the obtained nirq value so that it won\u0026apos;t exceed the maximum\nnumber of IRQs per bank.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-42092)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/dpaa2: Avoid explicit cpumask var allocation on stack\n\nFor CONFIG_CPUMASK_OFFSTACK=y kernel, explicit allocation of cpumask\nvariable on stack is not recommended since it can cause potential stack\noverflow.\n\nInstead, kernel code should always use *cpumask_var API(s) to allocate\ncpumask var in config-neutral way, leaving allocation strategy to\nCONFIG_CPUMASK_OFFSTACK.\n\nUse *cpumask_var API(s) to address it.(CVE-2024-42093)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/iucv: Avoid explicit cpumask var allocation on stack\n\nFor CONFIG_CPUMASK_OFFSTACK=y kernel, explicit allocation of cpumask\nvariable on stack is not recommended since it can cause potential stack\noverflow.\n\nInstead, kernel code should always use *cpumask_var API(s) to allocate\ncpumask var in config-neutral way, leaving allocation strategy to\nCONFIG_CPUMASK_OFFSTACK.\n\nUse *cpumask_var API(s) to address it.(CVE-2024-42094)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nserial: 8250_omap: Implementation of Errata i2310\n\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.\n\n[0] https://www.ti.com/lit/pdf/sprz536 page 23(CVE-2024-42095)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nx86: stop playing stack games in profile_pc()\n\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.\n\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.\n\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:\n\n\tAssume the lock function has either no stack frame or a copy\n\tof eflags from PUSHF.\n\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:\n\n\tEflags always has bits 22 and up cleared unlike kernel addresses\n\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.\n\nIt causes KASAN unhappiness reported for years by syzkaller [1] and\nothers [2].\n\nWith no real practical reason for this any more, just remove the code.\n\nJust for historical interest, here\u0026apos;s some background commits relating to\nthis code from 2006:\n\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;)\n\nand a code unification from 2009:\n\n ef4512882dbe (\u0026quot;x86: time_32/64.c unify profile_pc\u0026quot;)\n\nbut the basics of this thing actually goes back to before the git tree.(CVE-2024-42096)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: ecdh - explicitly zeroize private_key\n\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.\n\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)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ninet_diag: Initialize pad field in struct inet_diag_req_v2\n\nKMSAN reported uninit-value access in raw_lookup() [1]. Diag for raw\nsockets uses the pad field in struct inet_diag_req_v2 for the\nunderlying protocol. This field corresponds to the sdiag_raw_protocol\nfield in struct inet_diag_req_raw.\n\ninet_diag_get_exact_compat() converts inet_diag_req to\ninet_diag_req_v2, but leaves the pad field uninitialized. So the issue\noccurs when raw_lookup() accesses the sdiag_raw_protocol field.\n\nFix this by initializing the pad field in\ninet_diag_get_exact_compat(). Also, do the same fix in\ninet_diag_dump_compat() to avoid the similar issue in the future.\n\n[1]\nBUG: KMSAN: uninit-value in raw_lookup net/ipv4/raw_diag.c:49 [inline]\nBUG: KMSAN: uninit-value in raw_sock_get+0x657/0x800 net/ipv4/raw_diag.c:71\n raw_lookup net/ipv4/raw_diag.c:49 [inline]\n raw_sock_get+0x657/0x800 net/ipv4/raw_diag.c:71\n raw_diag_dump_one+0xa1/0x660 net/ipv4/raw_diag.c:99\n inet_diag_cmd_exact+0x7d9/0x980\n inet_diag_get_exact_compat net/ipv4/inet_diag.c:1404 [inline]\n inet_diag_rcv_msg_compat+0x469/0x530 net/ipv4/inet_diag.c:1426\n sock_diag_rcv_msg+0x23d/0x740 net/core/sock_diag.c:282\n netlink_rcv_skb+0x537/0x670 net/netlink/af_netlink.c:2564\n sock_diag_rcv+0x35/0x40 net/core/sock_diag.c:297\n netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline]\n netlink_unicast+0xe74/0x1240 net/netlink/af_netlink.c:1361\n netlink_sendmsg+0x10c6/0x1260 net/netlink/af_netlink.c:1905\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg+0x332/0x3d0 net/socket.c:745\n ____sys_sendmsg+0x7f0/0xb70 net/socket.c:2585\n ___sys_sendmsg+0x271/0x3b0 net/socket.c:2639\n __sys_sendmsg net/socket.c:2668 [inline]\n __do_sys_sendmsg net/socket.c:2677 [inline]\n __se_sys_sendmsg net/socket.c:2675 [inline]\n __x64_sys_sendmsg+0x27e/0x4a0 net/socket.c:2675\n x64_sys_call+0x135e/0x3ce0 arch/x86/include/generated/asm/syscalls_64.h:47\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xd9/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nUninit was stored to memory at:\n raw_sock_get+0x650/0x800 net/ipv4/raw_diag.c:71\n raw_diag_dump_one+0xa1/0x660 net/ipv4/raw_diag.c:99\n inet_diag_cmd_exact+0x7d9/0x980\n inet_diag_get_exact_compat net/ipv4/inet_diag.c:1404 [inline]\n inet_diag_rcv_msg_compat+0x469/0x530 net/ipv4/inet_diag.c:1426\n sock_diag_rcv_msg+0x23d/0x740 net/core/sock_diag.c:282\n netlink_rcv_skb+0x537/0x670 net/netlink/af_netlink.c:2564\n sock_diag_rcv+0x35/0x40 net/core/sock_diag.c:297\n netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline]\n netlink_unicast+0xe74/0x1240 net/netlink/af_netlink.c:1361\n netlink_sendmsg+0x10c6/0x1260 net/netlink/af_netlink.c:1905\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg+0x332/0x3d0 net/socket.c:745\n ____sys_sendmsg+0x7f0/0xb70 net/socket.c:2585\n ___sys_sendmsg+0x271/0x3b0 net/socket.c:2639\n __sys_sendmsg net/socket.c:2668 [inline]\n __do_sys_sendmsg net/socket.c:2677 [inline]\n __se_sys_sendmsg net/socket.c:2675 [inline]\n __x64_sys_sendmsg+0x27e/0x4a0 net/socket.c:2675\n x64_sys_call+0x135e/0x3ce0 arch/x86/include/generated/asm/syscalls_64.h:47\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xd9/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nLocal variable req.i created at:\n inet_diag_get_exact_compat net/ipv4/inet_diag.c:1396 [inline]\n inet_diag_rcv_msg_compat+0x2a6/0x530 net/ipv4/inet_diag.c:1426\n sock_diag_rcv_msg+0x23d/0x740 net/core/sock_diag.c:282\n\nCPU: 1 PID: 8888 Comm: syz-executor.6 Not tainted 6.10.0-rc4-00217-g35bb670d65fc #32\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014(CVE-2024-42106)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Skip finding free audio for unknown engine_id\n\n[WHY]\nENGINE_ID_UNKNOWN = -1 and can not be used as an array index. Plus, it\nalso means it is uninitialized and does not need free audio.\n\n[HOW]\nSkip and return NULL.\n\nThis fixes 2 OVERRUN issues reported by Coverity.(CVE-2024-42119)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qedf: Make qedf_execute_tmf() non-preemptible\n\nStop calling smp_processor_id() from preemptible code in\nqedf_execute_tmf90. This results in BUG_ON() when running an RT kernel.\n\n[ 659.343280] BUG: using smp_processor_id() in preemptible [00000000] code: sg_reset/3646\n[ 659.343282] caller is qedf_execute_tmf+0x8b/0x360 [qedf](CVE-2024-42124)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: qca: Fix BT enable failure again for QCA6390 after warm reboot\n\nCommit 272970be3dab (\u0026quot;Bluetooth: hci_qca: Fix driver shutdown on closed\nserdev\u0026quot;) will cause below regression issue:\n\nBT can\u0026apos;t be enabled after below steps:\ncold boot -\u0026gt; enable BT -\u0026gt; disable BT -\u0026gt; warm reboot -\u0026gt; BT enable failure\nif property enable-gpios is not configured within DT|ACPI for QCA6390.\n\nThe commit is to fix a use-after-free issue within qca_serdev_shutdown()\nby adding condition to avoid the serdev is flushed or wrote after closed\nbut also introduces this regression issue regarding above steps since the\nVSC is not sent to reset controller during warm reboot.\n\nFixed by sending the VSC to reset controller within qca_serdev_shutdown()\nonce BT was ever enabled, and the use-after-free issue is also fixed by\nthis change since the serdev is still opened before it is flushed or wrote.\n\nVerified by the reported machine Dell XPS 13 9310 laptop over below two\nkernel commits:\ncommit e00fc2700a3f (\u0026quot;Bluetooth: btusb: Fix triggering coredump\nimplementation for QCA\u0026quot;) of bluetooth-next tree.\ncommit b23d98d46d28 (\u0026quot;Bluetooth: btusb: Fix triggering coredump\nimplementation for QCA\u0026quot;) of linus mainline tree.(CVE-2024-42137)\n\nRejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2024-42143)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nIB/core: Implement a limit on UMAD receive List\n\nThe existing behavior of ib_umad, which maintains received MAD\npackets in an unbounded list, poses a risk of uncontrolled growth.\nAs user-space applications extract packets from this list, the rate\nof extraction may not match the rate of incoming packets, leading\nto potential list overflow.\n\nTo address this, we introduce a limit to the size of the list. After\nconsidering typical scenarios, such as OpenSM processing, which can\nhandle approximately 100k packets per second, and the 1-second retry\ntimeout for most packets, we set the list size limit to 200k. Packets\nreceived beyond this limit are dropped, assuming they are likely timed\nout by the time they are handled by user-space.\n\nNotably, packets queued on the receive list due to reasons like\ntimed-out sends are preserved even when the list is full.(CVE-2024-42145)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbnx2x: Fix multiple UBSAN array-index-out-of-bounds\n\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.\n\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:\n\nstruct stats_query_entry query[FP_SB_MAX_E1x+\n BNX2X_FIRST_QUEUE_QUERY_IDX];\n\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.\n\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\n\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 */\n\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.\n\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.\n\nStack traces:\n\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)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nUSB: serial: mos7840: fix crash on resume\n\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.\n\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.\n\nFix this by implementing dedicated suspend and resume functions for\nmos7840.\n\nTested with Delock 87414 USB 2.0 to 4x serial adapter.\n\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)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet, sunrpc: Remap EPERM in case of connection failure in xs_tcp_setup_socket\n\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.\n\nNeil suggested:\n\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.\n\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)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix a segment issue when downgrading gso_size\n\nLinearize the skb when downgrading gso_size because it may trigger a\nBUG_ON() later when the skb is segmented as described in [1,2].(CVE-2024-42281)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qla2xxx: Fix for possible memory corruption\n\nInit Control Block is dereferenced incorrectly. Correctly dereference ICB(CVE-2024-42288)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: make sure the first directory block is not a hole\n\nThe syzbot constructs a directory that has no dirblock but is non-inline,\ni.e. the first directory block is a hole. And no errors are reported when\ncreating files in this directory in the following flow.\n\n ext4_mknod\n ...\n ext4_add_entry\n // Read block 0\n ext4_read_dirblock(dir, block, DIRENT)\n bh = ext4_bread(NULL, inode, block, 0)\n if (!bh \u0026amp;\u0026amp; (type == INDEX || type == DIRENT_HTREE))\n // The first directory block is a hole\n // But type == DIRENT, so no error is reported.\n\nAfter that, we get a directory block without \u0026apos;.\u0026apos; and \u0026apos;..\u0026apos; but with a valid\ndentry. This may cause some code that relies on dot or dotdot (such as\nmake_indexed_dir()) to crash.\n\nTherefore when ext4_read_dirblock() finds that the first directory block\nis a hole report that the filesystem is corrupted and return an error to\navoid loading corrupted data from disk causing something bad.(CVE-2024-42304)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/gma500: fix null pointer dereference in cdv_intel_lvds_get_modes\n\nIn cdv_intel_lvds_get_modes(), the return value of drm_mode_duplicate()\nis assigned to mode, which will lead to a NULL pointer dereference on\nfailure of drm_mode_duplicate(). Add a check to avoid npd.(CVE-2024-42310)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nlandlock: Don\u0026apos;t lose track of restrictions on cred_transfer\n\nWhen a process\u0026apos; cred struct is replaced, this _almost_ always invokes\nthe cred_prepare LSM hook; but in one special case (when\nKEYCTL_SESSION_TO_PARENT updates the parent\u0026apos;s credentials), the\ncred_transfer LSM hook is used instead. Landlock only implements the\ncred_prepare hook, not cred_transfer, so KEYCTL_SESSION_TO_PARENT causes\nall information on Landlock restrictions to be lost.\n\nThis basically means that a process with the ability to use the fork()\nand keyctl() syscalls can get rid of all Landlock restrictions on\nitself.\n\nFix it by adding a cred_transfer hook that does the same thing as the\nexisting cred_prepare hook. (Implemented by having hook_cred_prepare()\ncall hook_cred_transfer() so that the two functions are less likely to\naccidentally diverge in the future.)(CVE-2024-42318)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbna: adjust \u0026apos;name\u0026apos; buf size of bna_tcb and bna_ccb structures\n\nTo have enough space to write all possible sprintf() args. Currently\n\u0026apos;name\u0026apos; size is 16, but the first \u0026apos;%s\u0026apos; specifier may already need at\nleast 16 characters, since \u0026apos;bnad-\u0026gt;netdev-\u0026gt;name\u0026apos; is used there.\n\nFor \u0026apos;%d\u0026apos; specifiers, assume that they require:\n * 1 char for \u0026apos;tx_id + tx_info-\u0026gt;tcb[i]-\u0026gt;id\u0026apos; sum, BNAD_MAX_TXQ_PER_TX is 8\n * 2 chars for \u0026apos;rx_id + rx_info-\u0026gt;rx_ctrl[i].ccb-\u0026gt;id\u0026apos;, BNAD_MAX_RXP_PER_RX\n is 16\n\nAnd replace sprintf with snprintf.\n\nDetected using the static analysis tool - Svace.(CVE-2024-43839)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nblock: initialize integrity buffer to zero before writing it to media\n\nMetadata added by bio_integrity_prep is using plain kmalloc, which leads\nto random kernel memory being written media. For PI metadata this is\nlimited to the app tag that isn\u0026apos;t used by kernel generated metadata,\nbut for non-PI metadata the entire buffer leaks kernel memory.\n\nFix this by adding the __GFP_ZERO flag to allocations for writes.(CVE-2024-43854)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: cfg80211: handle 2x996 RU allocation in cfg80211_calculate_bitrate_he()\n\nCurrently NL80211_RATE_INFO_HE_RU_ALLOC_2x996 is not handled in\ncfg80211_calculate_bitrate_he(), leading to below warning:\n\nkernel: invalid HE MCS: bw:6, ru:6\nkernel: WARNING: CPU: 0 PID: 2312 at net/wireless/util.c:1501 cfg80211_calculate_bitrate_he+0x22b/0x270 [cfg80211]\n\nFix it by handling 2x996 RU allocation in the same way as 160 MHz bandwidth.(CVE-2024-43879)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: ctnetlink: use helper function to calculate expect ID\n\nDelete expectation path is missing a call to the nf_expect_get_id()\nhelper function to calculate the expectation ID, otherwise LSB of the\nexpectation object address is leaked to userspace.(CVE-2024-44944)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxhci: Fix Panther point NULL pointer deref at full-speed re-enumeration\n\nre-enumerating full-speed devices after a failed address device command\ncan trigger a NULL pointer dereference.\n\nFull-speed devices may need to reconfigure the endpoint 0 Max Packet Size\nvalue during enumeration. Usb core calls usb_ep0_reinit() in this case,\nwhich ends up calling xhci_configure_endpoint().\n\nOn Panther point xHC the xhci_configure_endpoint() function will\nadditionally check and reserve bandwidth in software. Other hosts do\nthis in hardware\n\nIf xHC address device command fails then a new xhci_virt_device structure\nis allocated as part of re-enabling the slot, but the bandwidth table\npointers are not set up properly here.\nThis triggers the NULL pointer dereference the next time usb_ep0_reinit()\nis called and xhci_configure_endpoint() tries to check and reserve\nbandwidth\n\n[46710.713538] usb 3-1: new full-speed USB device number 5 using xhci_hcd\n[46710.713699] usb 3-1: Device not responding to setup address.\n[46710.917684] usb 3-1: Device not responding to setup address.\n[46711.125536] usb 3-1: device not accepting address 5, error -71\n[46711.125594] BUG: kernel NULL pointer dereference, address: 0000000000000008\n[46711.125600] #PF: supervisor read access in kernel mode\n[46711.125603] #PF: error_code(0x0000) - not-present page\n[46711.125606] PGD 0 P4D 0\n[46711.125610] Oops: Oops: 0000 [#1] PREEMPT SMP PTI\n[46711.125615] CPU: 1 PID: 25760 Comm: kworker/1:2 Not tainted 6.10.3_2 #1\n[46711.125620] Hardware name: Gigabyte Technology Co., Ltd.\n[46711.125623] Workqueue: usb_hub_wq hub_event [usbcore]\n[46711.125668] RIP: 0010:xhci_reserve_bandwidth (drivers/usb/host/xhci.c\n\nFix this by making sure bandwidth table pointers are set up correctly\nafter a failed address device command, and additionally by avoiding\nchecking for bandwidth in cases like this where no actual endpoints are\nadded or removed, i.e. only context for default control endpoint 0 is\nevaluated.(CVE-2024-45006)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: arm64: Make ICC_*SGI*_EL1 undef in the absence of a vGICv3\n\nOn a system with a GICv3, if a guest hasn\u0026apos;t been configured with\nGICv3 and that the host is not capable of GICv2 emulation,\na write to any of the ICC_*SGI*_EL1 registers is trapped to EL2.\n\nWe therefore try to emulate the SGI access, only to hit a NULL\npointer as no private interrupt is allocated (no GIC, remember?).\n\nThe obvious fix is to give the guest what it deserves, in the\nshape of a UNDEF exception.(CVE-2024-46707)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nice: Add netif_device_attach/detach into PF reset flow\n\nEthtool callbacks can be executed while reset is in progress and try to\naccess deleted resources, e.g. getting coalesce settings can result in a\nNULL pointer dereference seen below.\n\nReproduction steps:\nOnce the driver is fully initialized, trigger reset:\n\t# echo 1 \u0026gt; /sys/class/net/\u0026lt;interface\u0026gt;/device/reset\nwhen reset is in progress try to get coalesce settings using ethtool:\n\t# ethtool -c \u0026lt;interface\u0026gt;\n\nBUG: kernel NULL pointer dereference, address: 0000000000000020\nPGD 0 P4D 0\nOops: Oops: 0000 [#1] PREEMPT SMP PTI\nCPU: 11 PID: 19713 Comm: ethtool Tainted: G S 6.10.0-rc7+ #7\nRIP: 0010:ice_get_q_coalesce+0x2e/0xa0 [ice]\nRSP: 0018:ffffbab1e9bcf6a8 EFLAGS: 00010206\nRAX: 000000000000000c RBX: ffff94512305b028 RCX: 0000000000000000\nRDX: 0000000000000000 RSI: ffff9451c3f2e588 RDI: ffff9451c3f2e588\nRBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000\nR10: ffff9451c3f2e580 R11: 000000000000001f R12: ffff945121fa9000\nR13: ffffbab1e9bcf760 R14: 0000000000000013 R15: ffffffff9e65dd40\nFS: 00007faee5fbe740(0000) GS:ffff94546fd80000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000020 CR3: 0000000106c2e005 CR4: 00000000001706f0\nCall Trace:\n\u0026lt;TASK\u0026gt;\nice_get_coalesce+0x17/0x30 [ice]\ncoalesce_prepare_data+0x61/0x80\nethnl_default_doit+0xde/0x340\ngenl_family_rcv_msg_doit+0xf2/0x150\ngenl_rcv_msg+0x1b3/0x2c0\nnetlink_rcv_skb+0x5b/0x110\ngenl_rcv+0x28/0x40\nnetlink_unicast+0x19c/0x290\nnetlink_sendmsg+0x222/0x490\n__sys_sendto+0x1df/0x1f0\n__x64_sys_sendto+0x24/0x30\ndo_syscall_64+0x82/0x160\nentry_SYSCALL_64_after_hwframe+0x76/0x7e\nRIP: 0033:0x7faee60d8e27\n\nCalling netif_device_detach() before reset makes the net core not call\nthe driver when ethtool command is issued, the attempt to execute an\nethtool command during reset will result in the following message:\n\n netlink error: No such device\n\ninstead of NULL pointer dereference. Once reset is done and\nice_rebuild() is executing, the netif_device_attach() is called to allow\nfor ethtool operations to occur again in a safe manner.(CVE-2024-46770)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsched: sch_cake: fix bulk flow accounting logic for host fairness\n\nIn sch_cake, we keep track of the count of active bulk flows per host,\nwhen running in dst/src host fairness mode, which is used as the\nround-robin weight when iterating through flows. The count of active\nbulk flows is updated whenever a flow changes state.\n\nThis has a peculiar interaction with the hash collision handling: when a\nhash collision occurs (after the set-associative hashing), the state of\nthe hash bucket is simply updated to match the new packet that collided,\nand if host fairness is enabled, that also means assigning new per-host\nstate to the flow. For this reason, the bulk flow counters of the\nhost(s) assigned to the flow are decremented, before new state is\nassigned (and the counters, which may not belong to the same host\nanymore, are incremented again).\n\nBack when this code was introduced, the host fairness mode was always\nenabled, so the decrement was unconditional. When the configuration\nflags were introduced the *increment* was made conditional, but\nthe *decrement* was not. Which of course can lead to a spurious\ndecrement (and associated wrap-around to U16_MAX).\n\nAFAICT, when host fairness is disabled, the decrement and wrap-around\nhappens as soon as a hash collision occurs (which is not that common in\nitself, due to the set-associative hashing). However, in most cases this\nis harmless, as the value is only used when host fairness mode is\nenabled. So in order to trigger an array overflow, sch_cake has to first\nbe configured with host fairness disabled, and while running in this\nmode, a hash collision has to occur to cause the overflow. Then, the\nqdisc has to be reconfigured to enable host fairness, which leads to the\narray out-of-bounds because the wrapped-around value is retained and\nused as an array index. It seems that syzbot managed to trigger this,\nwhich is quite impressive in its own right.\n\nThis patch fixes the issue by introducing the same conditional check on\ndecrement as is used on increment.\n\nThe original bug predates the upstreaming of cake, but the commit listed\nin the Fixes tag touched that code, meaning that this patch won\u0026apos;t apply\nbefore that.(CVE-2024-46828)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nperf/x86/intel: Limit the period on Haswell\n\nRunning the ltp test cve-2015-3290 concurrently reports the following\nwarnings.\n\nperfevents: irq loop stuck!\n WARNING: CPU: 31 PID: 32438 at arch/x86/events/intel/core.c:3174\n intel_pmu_handle_irq+0x285/0x370\n Call Trace:\n \u0026lt;NMI\u0026gt;\n ? __warn+0xa4/0x220\n ? intel_pmu_handle_irq+0x285/0x370\n ? __report_bug+0x123/0x130\n ? intel_pmu_handle_irq+0x285/0x370\n ? __report_bug+0x123/0x130\n ? intel_pmu_handle_irq+0x285/0x370\n ? report_bug+0x3e/0xa0\n ? handle_bug+0x3c/0x70\n ? exc_invalid_op+0x18/0x50\n ? asm_exc_invalid_op+0x1a/0x20\n ? irq_work_claim+0x1e/0x40\n ? intel_pmu_handle_irq+0x285/0x370\n perf_event_nmi_handler+0x3d/0x60\n nmi_handle+0x104/0x330\n\nThanks to Thomas Gleixner\u0026apos;s analysis, the issue is caused by the low\ninitial period (1) of the frequency estimation algorithm, which triggers\nthe defects of the HW, specifically erratum HSW11 and HSW143. (For the\ndetails, please refer https://lore.kernel.org/lkml/87plq9l5d2.ffs@tglx/)\n\nThe HSW11 requires a period larger than 100 for the INST_RETIRED.ALL\nevent, but the initial period in the freq mode is 1. The erratum is the\nsame as the BDM11, which has been supported in the kernel. A minimum\nperiod of 128 is enforced as well on HSW.\n\nHSW143 is regarding that the fixed counter 1 may overcount 32 with the\nHyper-Threading is enabled. However, based on the test, the hardware\nhas more issues than it tells. Besides the fixed counter 1, the message\n\u0026apos;interrupt took too long\u0026apos; can be observed on any counter which was armed\nwith a period \u0026lt; 32 and two events expired in the same NMI. A minimum\nperiod of 32 is enforced for the rest of the events.\nThe recommended workaround code of the HSW143 is not implemented.\nBecause it only addresses the issue for the fixed counter. It brings\nextra overhead through extra MSR writing. No related overcounting issue\nhas been reported so far.(CVE-2024-46848)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nocfs2: add bounds checking to ocfs2_xattr_find_entry()\n\nAdd a paranoia check to make sure it doesn\u0026apos;t stray beyond valid memory\nregion containing ocfs2 xattr entries when scanning for a match. It will\nprevent out-of-bound access in case of crafted images.(CVE-2024-47670)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath9k_htc: Use __skb_set_length() for resetting urb before resubmit\n\nSyzbot points out that skb_trim() has a sanity check on the existing length of\nthe skb, which can be uninitialised in some error paths. The intent here is\nclearly just to reset the length to zero before resubmitting, so switch to\ncalling __skb_set_length(skb, 0) directly. In addition, __skb_set_length()\nalready contains a call to skb_reset_tail_pointer(), so remove the redundant\ncall.\n\nThe syzbot report came from ath9k_hif_usb_reg_in_cb(), but there\u0026apos;s a similar\nusage of skb_trim() in ath9k_hif_usb_rx_cb(), change both while we\u0026apos;re at it.(CVE-2024-49938)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsctp: set sk_state back to CLOSED if autobind fails in sctp_listen_start\n\nIn sctp_listen_start() invoked by sctp_inet_listen(), it should set the\nsk_state back to CLOSED if sctp_autobind() fails due to whatever reason.\n\nOtherwise, next time when calling sctp_inet_listen(), if sctp_sk(sk)-\u0026gt;reuse\nis already set via setsockopt(SCTP_REUSE_PORT), sctp_sk(sk)-\u0026gt;bind_hash will\nbe dereferenced as sk_state is LISTENING, which causes a crash as bind_hash\nis NULL.\n\n KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]\n RIP: 0010:sctp_inet_listen+0x7f0/0xa20 net/sctp/socket.c:8617\n Call Trace:\n \u0026lt;TASK\u0026gt;\n __sys_listen_socket net/socket.c:1883 [inline]\n __sys_listen+0x1b7/0x230 net/socket.c:1894\n __do_sys_listen net/socket.c:1902 [inline](CVE-2024-49944)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_tables: prevent nf_skb_duplicated corruption\n\nsyzbot found that nf_dup_ipv4() or nf_dup_ipv6() could write\nper-cpu variable nf_skb_duplicated in an unsafe way [1].\n\nDisabling preemption as hinted by the splat is not enough,\nwe have to disable soft interrupts as well.\n\n[1]\nBUG: using __this_cpu_write() in preemptible [00000000] code: syz.4.282/6316\n caller is nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87\nCPU: 0 UID: 0 PID: 6316 Comm: syz.4.282 Not tainted 6.11.0-rc7-syzkaller-00104-g7052622fccb1 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:93 [inline]\n dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119\n check_preemption_disabled+0x10e/0x120 lib/smp_processor_id.c:49\n nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87\n nft_dup_ipv4_eval+0x1db/0x300 net/ipv4/netfilter/nft_dup_ipv4.c:30\n expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline]\n nft_do_chain+0x4ad/0x1da0 net/netfilter/nf_tables_core.c:288\n nft_do_chain_ipv4+0x202/0x320 net/netfilter/nft_chain_filter.c:23\n nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]\n nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626\n nf_hook+0x2c4/0x450 include/linux/netfilter.h:269\n NF_HOOK_COND include/linux/netfilter.h:302 [inline]\n ip_output+0x185/0x230 net/ipv4/ip_output.c:433\n ip_local_out net/ipv4/ip_output.c:129 [inline]\n ip_send_skb+0x74/0x100 net/ipv4/ip_output.c:1495\n udp_send_skb+0xacf/0x1650 net/ipv4/udp.c:981\n udp_sendmsg+0x1c21/0x2a60 net/ipv4/udp.c:1269\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg+0x1a6/0x270 net/socket.c:745\n ____sys_sendmsg+0x525/0x7d0 net/socket.c:2597\n ___sys_sendmsg net/socket.c:2651 [inline]\n __sys_sendmmsg+0x3b2/0x740 net/socket.c:2737\n __do_sys_sendmmsg net/socket.c:2766 [inline]\n __se_sys_sendmmsg net/socket.c:2763 [inline]\n __x64_sys_sendmmsg+0xa0/0xb0 net/socket.c:2763\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7f4ce4f7def9\nCode: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007f4ce5d4a038 EFLAGS: 00000246 ORIG_RAX: 0000000000000133\nRAX: ffffffffffffffda RBX: 00007f4ce5135f80 RCX: 00007f4ce4f7def9\nRDX: 0000000000000001 RSI: 0000000020005d40 RDI: 0000000000000006\nRBP: 00007f4ce4ff0b76 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000\nR13: 0000000000000000 R14: 00007f4ce5135f80 R15: 00007ffd4cbc6d68\n \u0026lt;/TASK\u0026gt;(CVE-2024-49952)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\njbd2: stop waiting for space when jbd2_cleanup_journal_tail() returns error\n\nIn __jbd2_log_wait_for_space(), we might call jbd2_cleanup_journal_tail()\nto recover some journal space. But if an error occurs while executing\njbd2_cleanup_journal_tail() (e.g., an EIO), we don\u0026apos;t stop waiting for free\nspace right away, we try other branches, and if j_committing_transaction\nis NULL (i.e., the tid is 0), we will get the following complain:\n\n============================================\nJBD2: I/O error when updating journal superblock for sdd-8.\n__jbd2_log_wait_for_space: needed 256 blocks and only had 217 space available\n__jbd2_log_wait_for_space: no way to get more journal space in sdd-8\n------------[ cut here ]------------\nWARNING: CPU: 2 PID: 139804 at fs/jbd2/checkpoint.c:109 __jbd2_log_wait_for_space+0x251/0x2e0\nModules linked in:\nCPU: 2 PID: 139804 Comm: kworker/u8:3 Not tainted 6.6.0+ #1\nRIP: 0010:__jbd2_log_wait_for_space+0x251/0x2e0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n add_transaction_credits+0x5d1/0x5e0\n start_this_handle+0x1ef/0x6a0\n jbd2__journal_start+0x18b/0x340\n ext4_dirty_inode+0x5d/0xb0\n __mark_inode_dirty+0xe4/0x5d0\n generic_update_time+0x60/0x70\n[...]\n============================================\n\nSo only if jbd2_cleanup_journal_tail() returns 1, i.e., there is nothing to\nclean up at the moment, continue to try to reclaim free space in other ways.\n\nNote that this fix relies on commit 6f6a6fda2945 (\u0026quot;jbd2: fix ocfs2 corrupt\nwhen updating journal superblock fails\u0026quot;) to make jbd2_cleanup_journal_tail\nreturn the correct error code.(CVE-2024-49959)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmailbox: bcm2835: Fix timeout during suspend mode\n\nDuring noirq suspend phase the Raspberry Pi power driver suffer of\nfirmware property timeouts. The reason is that the IRQ of the underlying\nBCM2835 mailbox is disabled and rpi_firmware_property_list() will always\nrun into a timeout [1].\n\nSince the VideoCore side isn\u0026apos;t consider as a wakeup source, set the\nIRQF_NO_SUSPEND flag for the mailbox IRQ in order to keep it enabled\nduring suspend-resume cycle.\n\n[1]\nPM: late suspend of devices complete after 1.754 msecs\nWARNING: CPU: 0 PID: 438 at drivers/firmware/raspberrypi.c:128\n rpi_firmware_property_list+0x204/0x22c\nFirmware transaction 0x00028001 timeout\nModules linked in:\nCPU: 0 PID: 438 Comm: bash Tainted: G C 6.9.3-dirty #17\nHardware name: BCM2835\nCall trace:\nunwind_backtrace from show_stack+0x18/0x1c\nshow_stack from dump_stack_lvl+0x34/0x44\ndump_stack_lvl from __warn+0x88/0xec\n__warn from warn_slowpath_fmt+0x7c/0xb0\nwarn_slowpath_fmt from rpi_firmware_property_list+0x204/0x22c\nrpi_firmware_property_list from rpi_firmware_property+0x68/0x8c\nrpi_firmware_property from rpi_firmware_set_power+0x54/0xc0\nrpi_firmware_set_power from _genpd_power_off+0xe4/0x148\n_genpd_power_off from genpd_sync_power_off+0x7c/0x11c\ngenpd_sync_power_off from genpd_finish_suspend+0xcc/0xe0\ngenpd_finish_suspend from dpm_run_callback+0x78/0xd0\ndpm_run_callback from device_suspend_noirq+0xc0/0x238\ndevice_suspend_noirq from dpm_suspend_noirq+0xb0/0x168\ndpm_suspend_noirq from suspend_devices_and_enter+0x1b8/0x5ac\nsuspend_devices_and_enter from pm_suspend+0x254/0x2e4\npm_suspend from state_store+0xa8/0xd4\nstate_store from kernfs_fop_write_iter+0x154/0x1a0\nkernfs_fop_write_iter from vfs_write+0x12c/0x184\nvfs_write from ksys_write+0x78/0xc0\nksys_write from ret_fast_syscall+0x0/0x54\nException stack(0xcc93dfa8 to 0xcc93dff0)\n[...]\nPM: noirq suspend of devices complete after 3095.584 msecs(CVE-2024-49963)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntty: n_gsm: Fix use-after-free in gsm_cleanup_mux\n\nBUG: KASAN: slab-use-after-free in gsm_cleanup_mux+0x77b/0x7b0\ndrivers/tty/n_gsm.c:3160 [n_gsm]\nRead of size 8 at addr ffff88815fe99c00 by task poc/3379\nCPU: 0 UID: 0 PID: 3379 Comm: poc Not tainted 6.11.0+ #56\nHardware name: VMware, Inc. VMware Virtual Platform/440BX\nDesktop Reference Platform, BIOS 6.00 11/12/2020\nCall Trace:\n \u0026lt;TASK\u0026gt;\n gsm_cleanup_mux+0x77b/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm]\n __pfx_gsm_cleanup_mux+0x10/0x10 drivers/tty/n_gsm.c:3124 [n_gsm]\n __pfx_sched_clock_cpu+0x10/0x10 kernel/sched/clock.c:389\n update_load_avg+0x1c1/0x27b0 kernel/sched/fair.c:4500\n __pfx_min_vruntime_cb_rotate+0x10/0x10 kernel/sched/fair.c:846\n __rb_insert_augmented+0x492/0xbf0 lib/rbtree.c:161\n gsmld_ioctl+0x395/0x1450 drivers/tty/n_gsm.c:3408 [n_gsm]\n _raw_spin_lock_irqsave+0x92/0xf0 arch/x86/include/asm/atomic.h:107\n __pfx_gsmld_ioctl+0x10/0x10 drivers/tty/n_gsm.c:3822 [n_gsm]\n ktime_get+0x5e/0x140 kernel/time/timekeeping.c:195\n ldsem_down_read+0x94/0x4e0 arch/x86/include/asm/atomic64_64.h:79\n __pfx_ldsem_down_read+0x10/0x10 drivers/tty/tty_ldsem.c:338\n __pfx_do_vfs_ioctl+0x10/0x10 fs/ioctl.c:805\n tty_ioctl+0x643/0x1100 drivers/tty/tty_io.c:2818\n\nAllocated by task 65:\n gsm_data_alloc.constprop.0+0x27/0x190 drivers/tty/n_gsm.c:926 [n_gsm]\n gsm_send+0x2c/0x580 drivers/tty/n_gsm.c:819 [n_gsm]\n gsm1_receive+0x547/0xad0 drivers/tty/n_gsm.c:3038 [n_gsm]\n gsmld_receive_buf+0x176/0x280 drivers/tty/n_gsm.c:3609 [n_gsm]\n tty_ldisc_receive_buf+0x101/0x1e0 drivers/tty/tty_buffer.c:391\n tty_port_default_receive_buf+0x61/0xa0 drivers/tty/tty_port.c:39\n flush_to_ldisc+0x1b0/0x750 drivers/tty/tty_buffer.c:445\n process_scheduled_works+0x2b0/0x10d0 kernel/workqueue.c:3229\n worker_thread+0x3dc/0x950 kernel/workqueue.c:3391\n kthread+0x2a3/0x370 kernel/kthread.c:389\n ret_from_fork+0x2d/0x70 arch/x86/kernel/process.c:147\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:257\n\nFreed by task 3367:\n kfree+0x126/0x420 mm/slub.c:4580\n gsm_cleanup_mux+0x36c/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm]\n gsmld_ioctl+0x395/0x1450 drivers/tty/n_gsm.c:3408 [n_gsm]\n tty_ioctl+0x643/0x1100 drivers/tty/tty_io.c:2818\n\n[Analysis]\ngsm_msg on the tx_ctrl_list or tx_data_list of gsm_mux\ncan be freed by multi threads through ioctl,which leads\nto the occurrence of uaf. Protect it by gsm tx lock.(CVE-2024-50073)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nLoongArch: Don\u0026apos;t crash in stack_top() for tasks without vDSO\n\nNot all tasks have a vDSO mapped, for example kthreads never do. If such\na task ever ends up calling stack_top(), it will derefence the NULL vdso\npointer and crash.\n\nThis can for example happen when using kunit:\n\n\t[\u0026lt;9000000000203874\u0026gt;] stack_top+0x58/0xa8\n\t[\u0026lt;90000000002956cc\u0026gt;] arch_pick_mmap_layout+0x164/0x220\n\t[\u0026lt;90000000003c284c\u0026gt;] kunit_vm_mmap_init+0x108/0x12c\n\t[\u0026lt;90000000003c1fbc\u0026gt;] __kunit_add_resource+0x38/0x8c\n\t[\u0026lt;90000000003c2704\u0026gt;] kunit_vm_mmap+0x88/0xc8\n\t[\u0026lt;9000000000410b14\u0026gt;] usercopy_test_init+0xbc/0x25c\n\t[\u0026lt;90000000003c1db4\u0026gt;] kunit_try_run_case+0x5c/0x184\n\t[\u0026lt;90000000003c3d54\u0026gt;] kunit_generic_run_threadfn_adapter+0x24/0x48\n\t[\u0026lt;900000000022e4bc\u0026gt;] kthread+0xc8/0xd4\n\t[\u0026lt;9000000000200ce8\u0026gt;] ret_from_kernel_thread+0xc/0xa4(CVE-2024-50133)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: validate new SA\u0026apos;s prefixlen using SA family when sel.family is unset\n\nThis expands the validation introduced in commit 07bf7908950a (\u0026quot;xfrm:\nValidate address prefix lengths in the xfrm selector.\u0026quot;)\n\nsyzbot created an SA with\n usersa.sel.family = AF_UNSPEC\n usersa.sel.prefixlen_s = 128\n usersa.family = AF_INET\n\nBecause of the AF_UNSPEC selector, verify_newsa_info doesn\u0026apos;t put\nlimits on prefixlen_{s,d}. But then copy_from_user_state sets\nx-\u0026gt;sel.family to usersa.family (AF_INET). Do the same conversion in\nverify_newsa_info before validating prefixlen_{s,d}, since that\u0026apos;s how\nprefixlen is going to be used later on.(CVE-2024-50142)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbe2net: fix potential memory leak in be_xmit()\n\nThe be_xmit() returns NETDEV_TX_OK without freeing skb\nin case of be_xmit_enqueue() fails, add dev_kfree_skb_any() to fix it.(CVE-2024-50167)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/sun3_82586: fix potential memory leak in sun3_82586_send_packet()\n\nThe sun3_82586_send_packet() returns NETDEV_TX_OK without freeing skb\nin case of skb-\u0026gt;len being too long, add dev_kfree_skb() to fix it.(CVE-2024-50168)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nft_payload: sanitize offset and length before calling skb_checksum()\n\nIf access to offset + length is larger than the skbuff length, then\nskb_checksum() triggers BUG_ON().\n\nskb_checksum() internally subtracts the length parameter while iterating\nover skbuff, BUG_ON(len) at the end of it checks that the expected\nlength to be included in the checksum calculation is fully consumed.(CVE-2024-50251)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/i915/hdcp: Add encoder check in hdcp2_get_capability\n\nAdd encoder check in intel_hdcp2_get_capability to avoid\nnull pointer error.(CVE-2024-53050)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Check validity of link-\u0026gt;type in bpf_link_show_fdinfo()\n\nIf a newly-added link type doesn\u0026apos;t invoke BPF_LINK_TYPE(), accessing\nbpf_link_type_strs[link-\u0026gt;type] may result in an out-of-bounds access.\n\nTo spot such missed invocations early in the future, checking the\nvalidity of link-\u0026gt;type in bpf_link_show_fdinfo() and emitting a warning\nwhen such invocations are missed.(CVE-2024-53099)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs: Fix uninitialized value issue in from_kuid and from_kgid\n\nocfs2_setattr() uses attr-\u0026gt;ia_mode, attr-\u0026gt;ia_uid and attr-\u0026gt;ia_gid in\na trace point even though ATTR_MODE, ATTR_UID and ATTR_GID aren\u0026apos;t set.\n\nInitialize all fields of newattrs to avoid uninitialized variables, by\nchecking if ATTR_MODE, ATTR_UID, ATTR_GID are initialized, otherwise 0.(CVE-2024-53101)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsched/task_stack: fix object_is_on_stack() for KASAN tagged pointers\n\nWhen CONFIG_KASAN_SW_TAGS and CONFIG_KASAN_STACK are enabled, the\nobject_is_on_stack() function may produce incorrect results due to the\npresence of tags in the obj pointer, while the stack pointer does not have\ntags. This discrepancy can lead to incorrect stack object detection and\nsubsequently trigger warnings if CONFIG_DEBUG_OBJECTS is also enabled.\n\nExample of the warning:\n\nODEBUG: object 3eff800082ea7bb0 is NOT on stack ffff800082ea0000, but annotated.\n------------[ cut here ]------------\nWARNING: CPU: 0 PID: 1 at lib/debugobjects.c:557 __debug_object_init+0x330/0x364\nModules linked in:\nCPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-rc5 #4\nHardware name: linux,dummy-virt (DT)\npstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : __debug_object_init+0x330/0x364\nlr : __debug_object_init+0x330/0x364\nsp : ffff800082ea7b40\nx29: ffff800082ea7b40 x28: 98ff0000c0164518 x27: 98ff0000c0164534\nx26: ffff800082d93ec8 x25: 0000000000000001 x24: 1cff0000c00172a0\nx23: 0000000000000000 x22: ffff800082d93ed0 x21: ffff800081a24418\nx20: 3eff800082ea7bb0 x19: efff800000000000 x18: 0000000000000000\nx17: 00000000000000ff x16: 0000000000000047 x15: 206b63617473206e\nx14: 0000000000000018 x13: ffff800082ea7780 x12: 0ffff800082ea78e\nx11: 0ffff800082ea790 x10: 0ffff800082ea79d x9 : 34d77febe173e800\nx8 : 34d77febe173e800 x7 : 0000000000000001 x6 : 0000000000000001\nx5 : feff800082ea74b8 x4 : ffff800082870a90 x3 : ffff80008018d3c4\nx2 : 0000000000000001 x1 : ffff800082858810 x0 : 0000000000000050\nCall trace:\n __debug_object_init+0x330/0x364\n debug_object_init_on_stack+0x30/0x3c\n schedule_hrtimeout_range_clock+0xac/0x26c\n schedule_hrtimeout+0x1c/0x30\n wait_task_inactive+0x1d4/0x25c\n kthread_bind_mask+0x28/0x98\n init_rescuer+0x1e8/0x280\n workqueue_init+0x1a0/0x3cc\n kernel_init_freeable+0x118/0x200\n kernel_init+0x28/0x1f0\n ret_from_fork+0x10/0x20\n---[ end trace 0000000000000000 ]---\nODEBUG: object 3eff800082ea7bb0 is NOT on stack ffff800082ea0000, but annotated.\n------------[ cut here ]------------(CVE-2024-53128)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nALSA: usb-audio: Fix out of bounds reads when finding clock sources\n\nThe current USB-audio driver code doesn\u0026apos;t check bLength of each\ndescriptor at traversing for clock descriptors. That is, when a\ndevice provides a bogus descriptor with a shorter bLength, the driver\nmight hit out-of-bounds reads.\n\nFor addressing it, this patch adds sanity checks to the validator\nfunctions for the clock descriptor traversal. When the descriptor\nlength is shorter than expected, it\u0026apos;s skipped in the loop.\n\nFor the clock source and clock multiplier descriptors, we can just\ncheck bLength against the sizeof() of each descriptor type.\nOTOH, the clock selector descriptor of UAC2 and UAC3 has an array\nof bNrInPins elements and two more fields at its tail, hence those\nhave to be checked in addition to the sizeof() check.(CVE-2024-53150)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nocfs2: fix uninitialized value in ocfs2_file_read_iter()\n\nSyzbot has reported the following KMSAN splat:\n\nBUG: KMSAN: uninit-value in ocfs2_file_read_iter+0x9a4/0xf80\n ocfs2_file_read_iter+0x9a4/0xf80\n __io_read+0x8d4/0x20f0\n io_read+0x3e/0xf0\n io_issue_sqe+0x42b/0x22c0\n io_wq_submit_work+0xaf9/0xdc0\n io_worker_handle_work+0xd13/0x2110\n io_wq_worker+0x447/0x1410\n ret_from_fork+0x6f/0x90\n ret_from_fork_asm+0x1a/0x30\n\nUninit was created at:\n __alloc_pages_noprof+0x9a7/0xe00\n alloc_pages_mpol_noprof+0x299/0x990\n alloc_pages_noprof+0x1bf/0x1e0\n allocate_slab+0x33a/0x1250\n ___slab_alloc+0x12ef/0x35e0\n kmem_cache_alloc_bulk_noprof+0x486/0x1330\n __io_alloc_req_refill+0x84/0x560\n io_submit_sqes+0x172f/0x2f30\n __se_sys_io_uring_enter+0x406/0x41c0\n __x64_sys_io_uring_enter+0x11f/0x1a0\n x64_sys_call+0x2b54/0x3ba0\n do_syscall_64+0xcd/0x1e0\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nSince an instance of \u0026apos;struct kiocb\u0026apos; may be passed from the block layer\nwith \u0026apos;private\u0026apos; field uninitialized, introduce \u0026apos;ocfs2_iocb_init_rw_locked()\u0026apos;\nand use it from where \u0026apos;ocfs2_dio_end_io()\u0026apos; might take care, i.e. in\n\u0026apos;ocfs2_file_read_iter()\u0026apos; and \u0026apos;ocfs2_file_write_iter()\u0026apos;.(CVE-2024-53155)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfirmware: arm_scpi: Check the DVFS OPP count returned by the firmware\n\nFix a kernel crash with the below call trace when the SCPI firmware\nreturns OPP count of zero.\n\ndvfs_info.opp_count may be zero on some platforms during the reboot\ntest, and the kernel will crash after dereferencing the pointer to\nkcalloc(info-\u0026gt;count, sizeof(*opp), GFP_KERNEL).\n\n | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000028\n | Mem abort info:\n | ESR = 0x96000004\n | Exception class = DABT (current EL), IL = 32 bits\n | SET = 0, FnV = 0\n | EA = 0, S1PTW = 0\n | Data abort info:\n | ISV = 0, ISS = 0x00000004\n | CM = 0, WnR = 0\n | user pgtable: 4k pages, 48-bit VAs, pgdp = 00000000faefa08c\n | [0000000000000028] pgd=0000000000000000\n | Internal error: Oops: 96000004 [#1] SMP\n | scpi-hwmon: probe of PHYT000D:00 failed with error -110\n | Process systemd-udevd (pid: 1701, stack limit = 0x00000000aaede86c)\n | CPU: 2 PID: 1701 Comm: systemd-udevd Not tainted 4.19.90+ #1\n | Hardware name: PHYTIUM LTD Phytium FT2000/4/Phytium FT2000/4, BIOS\n | pstate: 60000005 (nZCv daif -PAN -UAO)\n | pc : scpi_dvfs_recalc_rate+0x40/0x58 [clk_scpi]\n | lr : clk_register+0x438/0x720\n | Call trace:\n | scpi_dvfs_recalc_rate+0x40/0x58 [clk_scpi]\n | devm_clk_hw_register+0x50/0xa0\n | scpi_clk_ops_init.isra.2+0xa0/0x138 [clk_scpi]\n | scpi_clocks_probe+0x528/0x70c [clk_scpi]\n | platform_drv_probe+0x58/0xa8\n | really_probe+0x260/0x3d0\n | driver_probe_device+0x12c/0x148\n | device_driver_attach+0x74/0x98\n | __driver_attach+0xb4/0xe8\n | bus_for_each_dev+0x88/0xe0\n | driver_attach+0x30/0x40\n | bus_add_driver+0x178/0x2b0\n | driver_register+0x64/0x118\n | __platform_driver_register+0x54/0x60\n | scpi_clocks_driver_init+0x24/0x1000 [clk_scpi]\n | do_one_initcall+0x54/0x220\n | do_init_module+0x54/0x1c8\n | load_module+0x14a4/0x1668\n | __se_sys_finit_module+0xf8/0x110\n | __arm64_sys_finit_module+0x24/0x30\n | el0_svc_common+0x78/0x170\n | el0_svc_handler+0x38/0x78\n | el0_svc+0x8/0x340\n | Code: 937d7c00 a94153f3 a8c27bfd f9400421 (b8606820)\n | ---[ end trace 06feb22469d89fa8 ]---\n | Kernel panic - not syncing: Fatal exception\n | SMP: stopping secondary CPUs\n | Kernel Offset: disabled\n | CPU features: 0x10,a0002008\n | Memory Limit: none(CVE-2024-53157)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsoc: qcom: geni-se: fix array underflow in geni_se_clk_tbl_get()\n\nThis loop is supposed to break if the frequency returned from\nclk_round_rate() is the same as on the previous iteration. However,\nthat check doesn\u0026apos;t make sense on the first iteration through the loop.\nIt leads to reading before the start of these-\u0026gt;clk_perf_tbl[] array.(CVE-2024-53158)\n\nRejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2024-53159)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nrcu/kvfree: Fix data-race in __mod_timer / kvfree_call_rcu\n\nKCSAN reports a data race when access the krcp-\u0026gt;monitor_work.timer.expires\nvariable in the schedule_delayed_monitor_work() function:\n\n\u0026lt;snip\u0026gt;\nBUG: KCSAN: data-race in __mod_timer / kvfree_call_rcu\n\nread to 0xffff888237d1cce8 of 8 bytes by task 10149 on cpu 1:\n schedule_delayed_monitor_work kernel/rcu/tree.c:3520 [inline]\n kvfree_call_rcu+0x3b8/0x510 kernel/rcu/tree.c:3839\n trie_update_elem+0x47c/0x620 kernel/bpf/lpm_trie.c:441\n bpf_map_update_value+0x324/0x350 kernel/bpf/syscall.c:203\n generic_map_update_batch+0x401/0x520 kernel/bpf/syscall.c:1849\n bpf_map_do_batch+0x28c/0x3f0 kernel/bpf/syscall.c:5143\n __sys_bpf+0x2e5/0x7a0\n __do_sys_bpf kernel/bpf/syscall.c:5741 [inline]\n __se_sys_bpf kernel/bpf/syscall.c:5739 [inline]\n __x64_sys_bpf+0x43/0x50 kernel/bpf/syscall.c:5739\n x64_sys_call+0x2625/0x2d60 arch/x86/include/generated/asm/syscalls_64.h:322\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xc9/0x1c0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nwrite to 0xffff888237d1cce8 of 8 bytes by task 56 on cpu 0:\n __mod_timer+0x578/0x7f0 kernel/time/timer.c:1173\n add_timer_global+0x51/0x70 kernel/time/timer.c:1330\n __queue_delayed_work+0x127/0x1a0 kernel/workqueue.c:2523\n queue_delayed_work_on+0xdf/0x190 kernel/workqueue.c:2552\n queue_delayed_work include/linux/workqueue.h:677 [inline]\n schedule_delayed_monitor_work kernel/rcu/tree.c:3525 [inline]\n kfree_rcu_monitor+0x5e8/0x660 kernel/rcu/tree.c:3643\n process_one_work kernel/workqueue.c:3229 [inline]\n process_scheduled_works+0x483/0x9a0 kernel/workqueue.c:3310\n worker_thread+0x51d/0x6f0 kernel/workqueue.c:3391\n kthread+0x1d1/0x210 kernel/kthread.c:389\n ret_from_fork+0x4b/0x60 arch/x86/kernel/process.c:147\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244\n\nReported by Kernel Concurrency Sanitizer on:\nCPU: 0 UID: 0 PID: 56 Comm: kworker/u8:4 Not tainted 6.12.0-rc2-syzkaller-00050-g5b7c893ed5ed #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024\nWorkqueue: events_unbound kfree_rcu_monitor\n\u0026lt;snip\u0026gt;\n\nkfree_rcu_monitor() rearms the work if a \u0026quot;krcp\u0026quot; has to be still\noffloaded and this is done without holding krcp-\u0026gt;lock, whereas\nthe kvfree_call_rcu() holds it.\n\nFix it by acquiring the \u0026quot;krcp-\u0026gt;lock\u0026quot; for kfree_rcu_monitor() so\nboth functions do not race anymore.(CVE-2024-53160)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nubifs: authentication: Fix use-after-free in ubifs_tnc_end_commit\n\nAfter an insertion in TNC, the tree might split and cause a node to\nchange its `znode-\u0026gt;parent`. A further deletion of other nodes in the\ntree (which also could free the nodes), the aforementioned node\u0026apos;s\n`znode-\u0026gt;cparent` could still point to a freed node. This\n`znode-\u0026gt;cparent` may not be updated when getting nodes to commit in\n`ubifs_tnc_start_commit()`. This could then trigger a use-after-free\nwhen accessing the `znode-\u0026gt;cparent` in `write_index()` in\n`ubifs_tnc_end_commit()`.\n\nThis can be triggered by running\n\n rm -f /etc/test-file.bin\n dd if=/dev/urandom of=/etc/test-file.bin bs=1M count=60 conv=fsync\n\nin a loop, and with `CONFIG_UBIFS_FS_AUTHENTICATION`. KASAN then\nreports:\n\n BUG: KASAN: use-after-free in ubifs_tnc_end_commit+0xa5c/0x1950\n Write of size 32 at addr ffffff800a3af86c by task ubifs_bgt0_20/153\n\n Call trace:\n dump_backtrace+0x0/0x340\n show_stack+0x18/0x24\n dump_stack_lvl+0x9c/0xbc\n print_address_description.constprop.0+0x74/0x2b0\n kasan_report+0x1d8/0x1f0\n kasan_check_range+0xf8/0x1a0\n memcpy+0x84/0xf4\n ubifs_tnc_end_commit+0xa5c/0x1950\n do_commit+0x4e0/0x1340\n ubifs_bg_thread+0x234/0x2e0\n kthread+0x36c/0x410\n ret_from_fork+0x10/0x20\n\n Allocated by task 401:\n kasan_save_stack+0x38/0x70\n __kasan_kmalloc+0x8c/0xd0\n __kmalloc+0x34c/0x5bc\n tnc_insert+0x140/0x16a4\n ubifs_tnc_add+0x370/0x52c\n ubifs_jnl_write_data+0x5d8/0x870\n do_writepage+0x36c/0x510\n ubifs_writepage+0x190/0x4dc\n __writepage+0x58/0x154\n write_cache_pages+0x394/0x830\n do_writepages+0x1f0/0x5b0\n filemap_fdatawrite_wbc+0x170/0x25c\n file_write_and_wait_range+0x140/0x190\n ubifs_fsync+0xe8/0x290\n vfs_fsync_range+0xc0/0x1e4\n do_fsync+0x40/0x90\n __arm64_sys_fsync+0x34/0x50\n invoke_syscall.constprop.0+0xa8/0x260\n do_el0_svc+0xc8/0x1f0\n el0_svc+0x34/0x70\n el0t_64_sync_handler+0x108/0x114\n el0t_64_sync+0x1a4/0x1a8\n\n Freed by task 403:\n kasan_save_stack+0x38/0x70\n kasan_set_track+0x28/0x40\n kasan_set_free_info+0x28/0x4c\n __kasan_slab_free+0xd4/0x13c\n kfree+0xc4/0x3a0\n tnc_delete+0x3f4/0xe40\n ubifs_tnc_remove_range+0x368/0x73c\n ubifs_tnc_remove_ino+0x29c/0x2e0\n ubifs_jnl_delete_inode+0x150/0x260\n ubifs_evict_inode+0x1d4/0x2e4\n evict+0x1c8/0x450\n iput+0x2a0/0x3c4\n do_unlinkat+0x2cc/0x490\n __arm64_sys_unlinkat+0x90/0x100\n invoke_syscall.constprop.0+0xa8/0x260\n do_el0_svc+0xc8/0x1f0\n el0_svc+0x34/0x70\n el0t_64_sync_handler+0x108/0x114\n el0t_64_sync+0x1a4/0x1a8\n\nThe offending `memcpy()` in `ubifs_copy_hash()` has a use-after-free\nwhen a node becomes root in TNC but still has a `cparent` to an already\nfreed node. More specifically, consider the following TNC:\n\n zroot\n /\n /\n zp1\n /\n /\n zn\n\nInserting a new node `zn_new` with a key smaller then `zn` will trigger\na split in `tnc_insert()` if `zp1` is full:\n\n zroot\n / \\\n / \\\n zp1 zp2\n / \\\n / \\\n zn_new zn\n\n`zn-\u0026gt;parent` has now been moved to `zp2`, *but* `zn-\u0026gt;cparent` still\npoints to `zp1`.\n\nNow, consider a removal of all the nodes _except_ `zn`. Just when\n`tnc_delete()` is about to delete `zroot` and `zp2`:\n\n zroot\n \\\n \\\n zp2\n \\\n \\\n zn\n\n`zroot` and `zp2` get freed and the tree collapses:\n\n zn\n\n`zn` now becomes the new `zroot`.\n\n`get_znodes_to_commit()` will now only find `zn`, the new `zroot`, and\n`write_index()` will check its `znode-\u0026gt;cparent` that wrongly points to\nthe already freed `zp1`. `ubifs_copy_hash()` thus gets wrongly called\nwith `znode-\u0026gt;cparent-\u0026gt;zbranch[znode-\u0026gt;iip].hash` that triggers the\nuse-after-free!\n\nFix this by explicitly setting `znode-\u0026gt;cparent` to `NULL` in\n`get_znodes_to_commit()` for the root node. The search for the dirty\nnodes\n---truncated---(CVE-2024-53171)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nALSA: pcm: Add sanity NULL check for the default mmap fault handler\n\nA driver might allow the mmap access before initializing its\nruntime-\u0026gt;dma_area properly. Add a proper NULL check before passing to\nvirt_to_page() for avoiding a panic.(CVE-2024-53180)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nio_uring: check for overflows in io_pin_pages\n\nWARNING: CPU: 0 PID: 5834 at io_uring/memmap.c:144 io_pin_pages+0x149/0x180 io_uring/memmap.c:144\nCPU: 0 UID: 0 PID: 5834 Comm: syz-executor825 Not tainted 6.12.0-next-20241118-syzkaller #0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __io_uaddr_map+0xfb/0x2d0 io_uring/memmap.c:183\n io_rings_map io_uring/io_uring.c:2611 [inline]\n io_allocate_scq_urings+0x1c0/0x650 io_uring/io_uring.c:3470\n io_uring_create+0x5b5/0xc00 io_uring/io_uring.c:3692\n io_uring_setup io_uring/io_uring.c:3781 [inline]\n ...\n \u0026lt;/TASK\u0026gt;\n\nio_pin_pages()\u0026apos;s uaddr parameter came directly from the user and can be\ngarbage. Don\u0026apos;t just add size to it as it can overflow.(CVE-2024-53187)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: rtlwifi: Drastically reduce the attempts to read efuse in case of failures\n\nSyzkaller reported a hung task with uevent_show() on stack trace. That\nspecific issue was addressed by another commit [0], but even with that\nfix applied (for example, running v6.12-rc5) we face another type of hung\ntask that comes from the same reproducer [1]. By investigating that, we\ncould narrow it to the following path:\n\n(a) Syzkaller emulates a Realtek USB WiFi adapter using raw-gadget and\ndummy_hcd infrastructure.\n\n(b) During the probe of rtl8192cu, the driver ends-up performing an efuse\nread procedure (which is related to EEPROM load IIUC), and here lies the\nissue: the function read_efuse() calls read_efuse_byte() many times, as\nloop iterations depending on the efuse size (in our example, 512 in total).\n\nThis procedure for reading efuse bytes relies in a loop that performs an\nI/O read up to *10k* times in case of failures. We measured the time of\nthe loop inside read_efuse_byte() alone, and in this reproducer (which\ninvolves the dummy_hcd emulation layer), it takes 15 seconds each. As a\nconsequence, we have the driver stuck in its probe routine for big time,\nexposing a stack trace like below if we attempt to reboot the system, for\nexample:\n\ntask:kworker/0:3 state:D stack:0 pid:662 tgid:662 ppid:2 flags:0x00004000\nWorkqueue: usb_hub_wq hub_event\nCall Trace:\n __schedule+0xe22/0xeb6\n schedule_timeout+0xe7/0x132\n __wait_for_common+0xb5/0x12e\n usb_start_wait_urb+0xc5/0x1ef\n ? usb_alloc_urb+0x95/0xa4\n usb_control_msg+0xff/0x184\n _usbctrl_vendorreq_sync+0xa0/0x161\n _usb_read_sync+0xb3/0xc5\n read_efuse_byte+0x13c/0x146\n read_efuse+0x351/0x5f0\n efuse_read_all_map+0x42/0x52\n rtl_efuse_shadow_map_update+0x60/0xef\n rtl_get_hwinfo+0x5d/0x1c2\n rtl92cu_read_eeprom_info+0x10a/0x8d5\n ? rtl92c_read_chip_version+0x14f/0x17e\n rtl_usb_probe+0x323/0x851\n usb_probe_interface+0x278/0x34b\n really_probe+0x202/0x4a4\n __driver_probe_device+0x166/0x1b2\n driver_probe_device+0x2f/0xd8\n [...]\n\nWe propose hereby to drastically reduce the attempts of doing the I/O\nreads in case of failures, restricted to USB devices (given that\nthey\u0026apos;re inherently slower than PCIe ones). By retrying up to 10 times\n(instead of 10000), we got reponsiveness in the reproducer, while seems\nreasonable to believe that there\u0026apos;s no sane USB device implementation in\nthe field requiring this amount of retries at every I/O read in order\nto properly work. Based on that assumption, it\u0026apos;d be good to have it\nbackported to stable but maybe not since driver implementation (the 10k\nnumber comes from day 0), perhaps up to 6.x series makes sense.\n\n[0] Commit 15fffc6a5624 (\u0026quot;driver core: Fix uevent_show() vs driver detach race\u0026quot;)\n\n[1] A note about that: this syzkaller report presents multiple reproducers\nthat differs by the type of emulated USB device. For this specific case,\ncheck the entry from 2024/08/08 06:23 in the list of crashes; the C repro\nis available at https://syzkaller.appspot.com/text?tag=ReproC\u0026amp;x=1521fc83980000.(CVE-2024-53190)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath12k: fix warning when unbinding\n\nIf there is an error during some initialization related to firmware,\nthe buffers dp-\u0026gt;tx_ring[i].tx_status are released.\nHowever this is released again when the device is unbinded (ath12k_pci),\nand we get:\nWARNING: CPU: 0 PID: 2098 at mm/slub.c:4689 free_large_kmalloc+0x4d/0x80\nCall Trace:\nfree_large_kmalloc\nath12k_dp_free\nath12k_core_deinit\nath12k_pci_remove\n...\n\nThe issue is always reproducible from a VM because the MSI addressing\ninitialization is failing.\n\nIn order to fix the issue, just set the buffers to NULL after releasing in\norder to avoid the double free.(CVE-2024-53191)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nPCI: Fix use-after-free of slot-\u0026gt;bus on hot remove\n\nDennis reports a boot crash on recent Lenovo laptops with a USB4 dock.\n\nSince commit 0fc70886569c (\u0026quot;thunderbolt: Reset USB4 v2 host router\u0026quot;) and\ncommit 59a54c5f3dbd (\u0026quot;thunderbolt: Reset topology created by the boot\nfirmware\u0026quot;), USB4 v2 and v1 Host Routers are reset on probe of the\nthunderbolt driver.\n\nThe reset clears the Presence Detect State and Data Link Layer Link Active\nbits at the USB4 Host Router\u0026apos;s Root Port and thus causes hot removal of the\ndock.\n\nThe crash occurs when pciehp is unbound from one of the dock\u0026apos;s Downstream\nPorts: pciehp creates a pci_slot on bind and destroys it on unbind. The\npci_slot contains a pointer to the pci_bus below the Downstream Port, but\na reference on that pci_bus is never acquired. The pci_bus is destroyed\nbefore the pci_slot, so a use-after-free ensues when pci_slot_release()\naccesses slot-\u0026gt;bus.\n\nIn principle this should not happen because pci_stop_bus_device() unbinds\npciehp (and therefore destroys the pci_slot) before the pci_bus is\ndestroyed by pci_remove_bus_device().\n\nHowever the stacktrace provided by Dennis shows that pciehp is unbound from\npci_remove_bus_device() instead of pci_stop_bus_device(). To understand\nthe significance of this, one needs to know that the PCI core uses a two\nstep process to remove a portion of the hierarchy: It first unbinds all\ndrivers in the sub-hierarchy in pci_stop_bus_device() and then actually\nremoves the devices in pci_remove_bus_device(). There is no precaution to\nprevent driver binding in-between pci_stop_bus_device() and\npci_remove_bus_device().\n\nIn Dennis\u0026apos; case, it seems removal of the hierarchy by pciehp races with\ndriver binding by pci_bus_add_devices(). pciehp is bound to the\nDownstream Port after pci_stop_bus_device() has run, so it is unbound by\npci_remove_bus_device() instead of pci_stop_bus_device(). Because the\npci_bus has already been destroyed at that point, accesses to it result in\na use-after-free.\n\nOne might conclude that driver binding needs to be prevented after\npci_stop_bus_device() has run. However it seems risky that pci_slot points\nto pci_bus without holding a reference. Solely relying on correct ordering\nof driver unbind versus pci_bus destruction is certainly not defensive\nprogramming.\n\nIf pci_slot has a need to access data in pci_bus, it ought to acquire a\nreference. Amend pci_create_slot() accordingly. Dennis reports that the\ncrash is not reproducible with this change.\n\nAbridged stacktrace:\n\n pcieport 0000:00:07.0: PME: Signaling with IRQ 156\n pcieport 0000:00:07.0: pciehp: Slot #12 AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ Surprise+ Interlock- NoCompl+ IbPresDis- LLActRep+\n pci_bus 0000:20: dev 00, created physical slot 12\n pcieport 0000:00:07.0: pciehp: Slot(12): Card not present\n ...\n pcieport 0000:21:02.0: pciehp: pcie_disable_notification: SLOTCTRL d8 write cmd 0\n Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b6b: 0000 [#1] PREEMPT SMP NOPTI\n CPU: 13 UID: 0 PID: 134 Comm: irq/156-pciehp Not tainted 6.11.0-devel+ #1\n RIP: 0010:dev_driver_string+0x12/0x40\n pci_destroy_slot\n pciehp_remove\n pcie_port_remove_service\n device_release_driver_internal\n bus_remove_device\n device_del\n device_unregister\n remove_iter\n device_for_each_child\n pcie_portdrv_remove\n pci_device_remove\n device_release_driver_internal\n bus_remove_device\n device_del\n pci_remove_bus_device (recursive invocation)\n pci_remove_bus_device\n pciehp_unconfigure_device\n pciehp_disable_slot\n pciehp_handle_presence_or_link_change\n pciehp_ist(CVE-2024-53194)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: arm64: Don\u0026apos;t retire aborted MMIO instruction\n\nReturning an abort to the guest for an unsupported MMIO access is a\ndocumented feature of the KVM UAPI. Nevertheless, it\u0026apos;s clear that this\nplumbing has seen limited testing, since userspace can trivially cause a\nWARN in the MMIO return:\n\n WARNING: CPU: 0 PID: 30558 at arch/arm64/include/asm/kvm_emulate.h:536 kvm_handle_mmio_return+0x46c/0x5c4 arch/arm64/include/asm/kvm_emulate.h:536\n Call trace:\n kvm_handle_mmio_return+0x46c/0x5c4 arch/arm64/include/asm/kvm_emulate.h:536\n kvm_arch_vcpu_ioctl_run+0x98/0x15b4 arch/arm64/kvm/arm.c:1133\n kvm_vcpu_ioctl+0x75c/0xa78 virt/kvm/kvm_main.c:4487\n __do_sys_ioctl fs/ioctl.c:51 [inline]\n __se_sys_ioctl fs/ioctl.c:893 [inline]\n __arm64_sys_ioctl+0x14c/0x1c8 fs/ioctl.c:893\n __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]\n invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49\n el0_svc_common+0x1e0/0x23c arch/arm64/kernel/syscall.c:132\n do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151\n el0_svc+0x38/0x68 arch/arm64/kernel/entry-common.c:712\n el0t_64_sync_handler+0x90/0xfc arch/arm64/kernel/entry-common.c:730\n el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598\n\nThe splat is complaining that KVM is advancing PC while an exception is\npending, i.e. that KVM is retiring the MMIO instruction despite a\npending synchronous external abort. Womp womp.\n\nFix the glaring UAPI bug by skipping over all the MMIO emulation in\ncase there is a pending synchronous exception. Note that while userspace\nis capable of pending an asynchronous exception (SError, IRQ, or FIQ),\nit is still safe to retire the MMIO instruction in this case as (1) they\nare by definition asynchronous, and (2) KVM relies on hardware support\nfor pending/delivering these exceptions instead of the software state\nmachine for advancing PC.(CVE-2024-53196)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: typec: fix potential array underflow in ucsi_ccg_sync_control()\n\nThe \u0026quot;command\u0026quot; variable can be controlled by the user via debugfs. The\nworry is that if con_index is zero then \u0026quot;\u0026amp;uc-\u0026gt;ucsi-\u0026gt;connector[con_index\n- 1]\u0026quot; would be an array underflow.(CVE-2024-53203)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: usb: lan78xx: Fix double free issue with interrupt buffer allocation\n\nIn lan78xx_probe(), the buffer `buf` was being freed twice: once\nimplicitly through `usb_free_urb(dev-\u0026gt;urb_intr)` with the\n`URB_FREE_BUFFER` flag and again explicitly by `kfree(buf)`. This caused\na double free issue.\n\nTo resolve this, reordered `kmalloc()` and `usb_alloc_urb()` calls to\nsimplify the initialization sequence and removed the redundant\n`kfree(buf)`. Now, `buf` is allocated after `usb_alloc_urb()`, ensuring\nit is correctly managed by `usb_fill_int_urb()` and freed by\n`usb_free_urb()` as intended.(CVE-2024-53213)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsvcrdma: fix miss destroy percpu_counter in svc_rdma_proc_init()\n\nThere\u0026apos;s issue as follows:\nRPC: Registered rdma transport module.\nRPC: Registered rdma backchannel transport module.\nRPC: Unregistered rdma transport module.\nRPC: Unregistered rdma backchannel transport module.\nBUG: unable to handle page fault for address: fffffbfff80c609a\nPGD 123fee067 P4D 123fee067 PUD 123fea067 PMD 10c624067 PTE 0\nOops: Oops: 0000 [#1] PREEMPT SMP KASAN NOPTI\nRIP: 0010:percpu_counter_destroy_many+0xf7/0x2a0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __die+0x1f/0x70\n page_fault_oops+0x2cd/0x860\n spurious_kernel_fault+0x36/0x450\n do_kern_addr_fault+0xca/0x100\n exc_page_fault+0x128/0x150\n asm_exc_page_fault+0x26/0x30\n percpu_counter_destroy_many+0xf7/0x2a0\n mmdrop+0x209/0x350\n finish_task_switch.isra.0+0x481/0x840\n schedule_tail+0xe/0xd0\n ret_from_fork+0x23/0x80\n ret_from_fork_asm+0x1a/0x30\n \u0026lt;/TASK\u0026gt;\n\nIf register_sysctl() return NULL, then svc_rdma_proc_cleanup() will not\ndestroy the percpu counters which init in svc_rdma_proc_init().\nIf CONFIG_HOTPLUG_CPU is enabled, residual nodes may be in the\n\u0026apos;percpu_counters\u0026apos; list. The above issue may occur once the module is\nremoved. If the CONFIG_HOTPLUG_CPU configuration is not enabled, memory\nleakage occurs.\nTo solve above issue just destroy all percpu counters when\nregister_sysctl() return NULL.(CVE-2024-53215)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: fix race in concurrent f2fs_stop_gc_thread\n\nIn my test case, concurrent calls to f2fs shutdown report the following\nstack trace:\n\n Oops: general protection fault, probably for non-canonical address 0xc6cfff63bb5513fc: 0000 [#1] PREEMPT SMP PTI\n CPU: 0 UID: 0 PID: 678 Comm: f2fs_rep_shutdo Not tainted 6.12.0-rc5-next-20241029-g6fb2fa9805c5-dirty #85\n Call Trace:\n \u0026lt;TASK\u0026gt;\n ? show_regs+0x8b/0xa0\n ? __die_body+0x26/0xa0\n ? die_addr+0x54/0x90\n ? exc_general_protection+0x24b/0x5c0\n ? asm_exc_general_protection+0x26/0x30\n ? kthread_stop+0x46/0x390\n f2fs_stop_gc_thread+0x6c/0x110\n f2fs_do_shutdown+0x309/0x3a0\n f2fs_ioc_shutdown+0x150/0x1c0\n __f2fs_ioctl+0xffd/0x2ac0\n f2fs_ioctl+0x76/0xe0\n vfs_ioctl+0x23/0x60\n __x64_sys_ioctl+0xce/0xf0\n x64_sys_call+0x2b1b/0x4540\n do_syscall_64+0xa7/0x240\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nThe root cause is a race condition in f2fs_stop_gc_thread() called from\ndifferent f2fs shutdown paths:\n\n [CPU0] [CPU1]\n ---------------------- -----------------------\n f2fs_stop_gc_thread f2fs_stop_gc_thread\n gc_th = sbi-\u0026gt;gc_thread\n gc_th = sbi-\u0026gt;gc_thread\n kfree(gc_th)\n sbi-\u0026gt;gc_thread = NULL\n \u0026lt; gc_th != NULL \u0026gt;\n kthread_stop(gc_th-\u0026gt;f2fs_gc_task) //UAF\n\nThe commit c7f114d864ac (\u0026quot;f2fs: fix to avoid use-after-free in\nf2fs_stop_gc_thread()\u0026quot;) attempted to fix this issue by using a read\nsemaphore to prevent races between shutdown and remount threads, but\nit fails to prevent all race conditions.\n\nFix it by converting to write lock of s_umount in f2fs_do_shutdown().(CVE-2024-53218)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvirtiofs: use pages instead of pointer for kernel direct IO\n\nWhen trying to insert a 10MB kernel module kept in a virtio-fs with cache\ndisabled, the following warning was reported:\n\n ------------[ cut here ]------------\n WARNING: CPU: 1 PID: 404 at mm/page_alloc.c:4551 ......\n Modules linked in:\n CPU: 1 PID: 404 Comm: insmod Not tainted 6.9.0-rc5+ #123\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) ......\n RIP: 0010:__alloc_pages+0x2bf/0x380\n ......\n Call Trace:\n \u0026lt;TASK\u0026gt;\n ? __warn+0x8e/0x150\n ? __alloc_pages+0x2bf/0x380\n __kmalloc_large_node+0x86/0x160\n __kmalloc+0x33c/0x480\n virtio_fs_enqueue_req+0x240/0x6d0\n virtio_fs_wake_pending_and_unlock+0x7f/0x190\n queue_request_and_unlock+0x55/0x60\n fuse_simple_request+0x152/0x2b0\n fuse_direct_io+0x5d2/0x8c0\n fuse_file_read_iter+0x121/0x160\n __kernel_read+0x151/0x2d0\n kernel_read+0x45/0x50\n kernel_read_file+0x1a9/0x2a0\n init_module_from_file+0x6a/0xe0\n idempotent_init_module+0x175/0x230\n __x64_sys_finit_module+0x5d/0xb0\n x64_sys_call+0x1c3/0x9e0\n do_syscall_64+0x3d/0xc0\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n ......\n \u0026lt;/TASK\u0026gt;\n ---[ end trace 0000000000000000 ]---\n\nThe warning is triggered as follows:\n\n1) syscall finit_module() handles the module insertion and it invokes\nkernel_read_file() to read the content of the module first.\n\n2) kernel_read_file() allocates a 10MB buffer by using vmalloc() and\npasses it to kernel_read(). kernel_read() constructs a kvec iter by\nusing iov_iter_kvec() and passes it to fuse_file_read_iter().\n\n3) virtio-fs disables the cache, so fuse_file_read_iter() invokes\nfuse_direct_io(). As for now, the maximal read size for kvec iter is\nonly limited by fc-\u0026gt;max_read. For virtio-fs, max_read is UINT_MAX, so\nfuse_direct_io() doesn\u0026apos;t split the 10MB buffer. It saves the address and\nthe size of the 10MB-sized buffer in out_args[0] of a fuse request and\npasses the fuse request to virtio_fs_wake_pending_and_unlock().\n\n4) virtio_fs_wake_pending_and_unlock() uses virtio_fs_enqueue_req() to\nqueue the request. Because virtiofs need DMA-able address, so\nvirtio_fs_enqueue_req() uses kmalloc() to allocate a bounce buffer for\nall fuse args, copies these args into the bounce buffer and passed the\nphysical address of the bounce buffer to virtiofsd. The total length of\nthese fuse args for the passed fuse request is about 10MB, so\ncopy_args_to_argbuf() invokes kmalloc() with a 10MB size parameter and\nit triggers the warning in __alloc_pages():\n\n\tif (WARN_ON_ONCE_GFP(order \u0026gt; MAX_PAGE_ORDER, gfp))\n\t\treturn NULL;\n\n5) virtio_fs_enqueue_req() will retry the memory allocation in a\nkworker, but it won\u0026apos;t help, because kmalloc() will always return NULL\ndue to the abnormal size and finit_module() will hang forever.\n\nA feasible solution is to limit the value of max_read for virtio-fs, so\nthe length passed to kmalloc() will be limited. However it will affect\nthe maximal read size for normal read. And for virtio-fs write initiated\nfrom kernel, it has the similar problem but now there is no way to limit\nfc-\u0026gt;max_write in kernel.\n\nSo instead of limiting both the values of max_read and max_write in\nkernel, introducing use_pages_for_kvec_io in fuse_conn and setting it as\ntrue in virtiofs. When use_pages_for_kvec_io is enabled, fuse will use\npages instead of pointer to pass the KVEC_IO data.\n\nAfter switching to pages for KVEC_IO data, these pages will be used for\nDMA through virtio-fs. If these pages are backed by vmalloc(),\n{flush|invalidate}_kernel_vmap_range() are necessary to flush or\ninvalidate the cache before the DMA operation. So add two new fields in\nfuse_args_pages to record the base address of vmalloc area and the\ncondition indicating whether invalidation is needed. Perform the flush\nin fuse_get_user_pages() for write operations and the invalidation in\nfuse_release_user_pages() for read operations.\n\nIt may seem necessary to introduce another fie\n---truncated---(CVE-2024-53219)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/mlx5: Move events notifier registration to be after device registration\n\nMove pkey change work initialization and cleanup from device resources\nstage to notifier stage, since this is the stage which handles this work\nevents.\n\nFix a race between the device deregistration and pkey change work by moving\nMLX5_IB_STAGE_DEVICE_NOTIFIER to be after MLX5_IB_STAGE_IB_REG in order to\nensure that the notifier is deregistered before the device during cleanup.\nWhich ensures there are no works that are being executed after the\ndevice has already unregistered which can cause the panic below.\n\nBUG: kernel NULL pointer dereference, address: 0000000000000000\nPGD 0 P4D 0\nOops: 0000 [#1] PREEMPT SMP PTI\nCPU: 1 PID: 630071 Comm: kworker/1:2 Kdump: loaded Tainted: G W OE --------- --- 5.14.0-162.6.1.el9_1.x86_64 #1\nHardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS 090008 02/27/2023\nWorkqueue: events pkey_change_handler [mlx5_ib]\nRIP: 0010:setup_qp+0x38/0x1f0 [mlx5_ib]\nCode: ee 41 54 45 31 e4 55 89 f5 53 48 89 fb 48 83 ec 20 8b 77 08 65 48 8b 04 25 28 00 00 00 48 89 44 24 18 48 8b 07 48 8d 4c 24 16 \u0026lt;4c\u0026gt; 8b 38 49 8b 87 80 0b 00 00 4c 89 ff 48 8b 80 08 05 00 00 8b 40\nRSP: 0018:ffffbcc54068be20 EFLAGS: 00010282\nRAX: 0000000000000000 RBX: ffff954054494128 RCX: ffffbcc54068be36\nRDX: ffff954004934000 RSI: 0000000000000001 RDI: ffff954054494128\nRBP: 0000000000000023 R08: ffff954001be2c20 R09: 0000000000000001\nR10: ffff954001be2c20 R11: ffff9540260133c0 R12: 0000000000000000\nR13: 0000000000000023 R14: 0000000000000000 R15: ffff9540ffcb0905\nFS: 0000000000000000(0000) GS:ffff9540ffc80000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000000 CR3: 000000010625c001 CR4: 00000000003706e0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\nmlx5_ib_gsi_pkey_change+0x20/0x40 [mlx5_ib]\nprocess_one_work+0x1e8/0x3c0\nworker_thread+0x50/0x3b0\n? rescuer_thread+0x380/0x380\nkthread+0x149/0x170\n? set_kthread_struct+0x50/0x50\nret_from_fork+0x22/0x30\nModules linked in: rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_umad(OE) mlx5_ib(OE) mlx5_fwctl(OE) fwctl(OE) ib_uverbs(OE) mlx5_core(OE) mlxdevm(OE) ib_core(OE) mlx_compat(OE) psample mlxfw(OE) tls knem(OE) netconsole nfsv3 nfs_acl nfs lockd grace fscache netfs qrtr rfkill sunrpc intel_rapl_msr intel_rapl_common rapl hv_balloon hv_utils i2c_piix4 pcspkr joydev fuse ext4 mbcache jbd2 sr_mod sd_mod cdrom t10_pi sg ata_generic pci_hyperv pci_hyperv_intf hyperv_drm drm_shmem_helper drm_kms_helper hv_storvsc syscopyarea hv_netvsc sysfillrect sysimgblt hid_hyperv fb_sys_fops scsi_transport_fc hyperv_keyboard drm ata_piix crct10dif_pclmul crc32_pclmul crc32c_intel libata ghash_clmulni_intel hv_vmbus serio_raw [last unloaded: ib_core]\nCR2: 0000000000000000\n---[ end trace f6f8be4eae12f7bc ]---(CVE-2024-53224)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/hns: Fix NULL pointer derefernce in hns_roce_map_mr_sg()\n\nib_map_mr_sg() allows ULPs to specify NULL as the sg_offset argument.\nThe driver needs to check whether it is a NULL pointer before\ndereferencing it.(CVE-2024-53226)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/rxe: Fix the qp flush warnings in req\n\nWhen the qp is in error state, the status of WQEs in the queue should be\nset to error. Or else the following will appear.\n\n[ 920.617269] WARNING: CPU: 1 PID: 21 at drivers/infiniband/sw/rxe/rxe_comp.c:756 rxe_completer+0x989/0xcc0 [rdma_rxe]\n[ 920.617744] Modules linked in: rnbd_client(O) rtrs_client(O) rtrs_core(O) rdma_ucm rdma_cm iw_cm ib_cm crc32_generic rdma_rxe ip6_udp_tunnel udp_tunnel ib_uverbs ib_core loop brd null_blk ipv6\n[ 920.618516] CPU: 1 PID: 21 Comm: ksoftirqd/1 Tainted: G O 6.1.113-storage+ #65\n[ 920.618986] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014\n[ 920.619396] RIP: 0010:rxe_completer+0x989/0xcc0 [rdma_rxe]\n[ 920.619658] Code: 0f b6 84 24 3a 02 00 00 41 89 84 24 44 04 00 00 e9 2a f7 ff ff 39 ca bb 03 00 00 00 b8 0e 00 00 00 48 0f 45 d8 e9 15 f7 ff ff \u0026lt;0f\u0026gt; 0b e9 cb f8 ff ff 41 bf f5 ff ff ff e9 08 f8 ff ff 49 8d bc 24\n[ 920.620482] RSP: 0018:ffff97b7c00bbc38 EFLAGS: 00010246\n[ 920.620817] RAX: 0000000000000000 RBX: 000000000000000c RCX: 0000000000000008\n[ 920.621183] RDX: ffff960dc396ebc0 RSI: 0000000000005400 RDI: ffff960dc4e2fbac\n[ 920.621548] RBP: 0000000000000000 R08: 0000000000000001 R09: ffffffffac406450\n[ 920.621884] R10: ffffffffac4060c0 R11: 0000000000000001 R12: ffff960dc4e2f800\n[ 920.622254] R13: ffff960dc4e2f928 R14: ffff97b7c029c580 R15: 0000000000000000\n[ 920.622609] FS: 0000000000000000(0000) GS:ffff960ef7d00000(0000) knlGS:0000000000000000\n[ 920.622979] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 920.623245] CR2: 00007fa056965e90 CR3: 00000001107f1000 CR4: 00000000000006e0\n[ 920.623680] Call Trace:\n[ 920.623815] \u0026lt;TASK\u0026gt;\n[ 920.623933] ? __warn+0x79/0xc0\n[ 920.624116] ? rxe_completer+0x989/0xcc0 [rdma_rxe]\n[ 920.624356] ? report_bug+0xfb/0x150\n[ 920.624594] ? handle_bug+0x3c/0x60\n[ 920.624796] ? exc_invalid_op+0x14/0x70\n[ 920.624976] ? asm_exc_invalid_op+0x16/0x20\n[ 920.625203] ? rxe_completer+0x989/0xcc0 [rdma_rxe]\n[ 920.625474] ? rxe_completer+0x329/0xcc0 [rdma_rxe]\n[ 920.625749] rxe_do_task+0x80/0x110 [rdma_rxe]\n[ 920.626037] rxe_requester+0x625/0xde0 [rdma_rxe]\n[ 920.626310] ? rxe_cq_post+0xe2/0x180 [rdma_rxe]\n[ 920.626583] ? do_complete+0x18d/0x220 [rdma_rxe]\n[ 920.626812] ? rxe_completer+0x1a3/0xcc0 [rdma_rxe]\n[ 920.627050] rxe_do_task+0x80/0x110 [rdma_rxe]\n[ 920.627285] tasklet_action_common.constprop.0+0xa4/0x120\n[ 920.627522] handle_softirqs+0xc2/0x250\n[ 920.627728] ? sort_range+0x20/0x20\n[ 920.627942] run_ksoftirqd+0x1f/0x30\n[ 920.628158] smpboot_thread_fn+0xc7/0x1b0\n[ 920.628334] kthread+0xd6/0x100\n[ 920.628504] ? kthread_complete_and_exit+0x20/0x20\n[ 920.628709] ret_from_fork+0x1f/0x30\n[ 920.628892] \u0026lt;/TASK\u0026gt;(CVE-2024-53229)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncpufreq: CPPC: Fix possible null-ptr-deref for cpufreq_cpu_get_raw()\n\ncpufreq_cpu_get_raw() may return NULL if the cpu is not in\npolicy-\u0026gt;cpus cpu mask and it will cause null pointer dereference.(CVE-2024-53231)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nerofs: handle NONHEAD !delta[1] lclusters gracefully\n\nsyzbot reported a WARNING in iomap_iter_done:\n iomap_fiemap+0x73b/0x9b0 fs/iomap/fiemap.c:80\n ioctl_fiemap fs/ioctl.c:220 [inline]\n\nGenerally, NONHEAD lclusters won\u0026apos;t have delta[1]==0, except for crafted\nimages and filesystems created by pre-1.0 mkfs versions.\n\nPreviously, it would immediately bail out if delta[1]==0, which led to\ninadequate decompressed lengths (thus FIEMAP is impacted). Treat it as\ndelta[1]=1 to work around these legacy mkfs versions.\n\n`lclusterbits \u0026gt; 14` is illegal for compact indexes, error out too.(CVE-2024-53234)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nALSA: 6fire: Release resources at card release\n\nThe current 6fire code tries to release the resources right after the\ncall of usb6fire_chip_abort(). But at this moment, the card object\nmight be still in use (as we\u0026apos;re calling snd_card_free_when_closed()).\n\nFor avoid potential UAFs, move the release of resources to the card\u0026apos;s\nprivate_free instead of the manual call of usb6fire_chip_destroy() at\nthe USB disconnect callback.(CVE-2024-53239)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nx86/xen: don\u0026apos;t do PV iret hypercall through hypercall page\n\nInstead of jumping to the Xen hypercall page for doing the iret\nhypercall, directly code the required sequence in xen-asm.S.\n\nThis is done in preparation of no longer using hypercall page at all,\nas it has shown to cause problems with speculation mitigations.\n\nThis is part of XSA-466 / CVE-2024-53241.(CVE-2024-53241)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: renesas: rswitch: avoid use-after-put for a device tree node\n\nThe device tree node saved in the rswitch_device structure is used at\nseveral driver locations. So passing this node to of_node_put() after\nthe first use is wrong.\n\nMove of_node_put() for this node to exit paths.(CVE-2024-55639)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath12k: Skip Rx TID cleanup for self peer\n\nDuring peer create, dp setup for the peer is done where Rx TID is\nupdated for all the TIDs. Peer object for self peer will not go through\ndp setup.\n\nWhen core halts, dp cleanup is done for all the peers. While cleanup,\nrx_tid::ab is accessed which causes below stack trace for self peer.\n\nWARNING: CPU: 6 PID: 12297 at drivers/net/wireless/ath/ath12k/dp_rx.c:851\nCall Trace:\n__warn+0x7b/0x1a0\nath12k_dp_rx_frags_cleanup+0xd2/0xe0 [ath12k]\nreport_bug+0x10b/0x200\nhandle_bug+0x3f/0x70\nexc_invalid_op+0x13/0x60\nasm_exc_invalid_op+0x16/0x20\nath12k_dp_rx_frags_cleanup+0xd2/0xe0 [ath12k]\nath12k_dp_rx_frags_cleanup+0xca/0xe0 [ath12k]\nath12k_dp_rx_peer_tid_cleanup+0x39/0xa0 [ath12k]\nath12k_mac_peer_cleanup_all+0x61/0x100 [ath12k]\nath12k_core_halt+0x3b/0x100 [ath12k]\nath12k_core_reset+0x494/0x4c0 [ath12k]\n\nsta object in peer will be updated when remote peer is created. Hence\nuse peer::sta to detect the self peer and skip the cleanup.\n\nTested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1\nTested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3(CVE-2024-56543)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrivers: soc: xilinx: add the missing kfree in xlnx_add_cb_for_suspend()\n\nIf we fail to allocate memory for cb_data by kmalloc, the memory\nallocation for eve_data is never freed, add the missing kfree()\nin the error handling path.(CVE-2024-56546)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncachefiles: Fix NULL pointer dereference in object-\u0026gt;file\n\nAt present, the object-\u0026gt;file has the NULL pointer dereference problem in\nondemand-mode. The root cause is that the allocated fd and object-\u0026gt;file\nlifetime are inconsistent, and the user-space invocation to anon_fd uses\nobject-\u0026gt;file. Following is the process that triggers the issue:\n\n\t [write fd]\t\t\t\t[umount]\ncachefiles_ondemand_fd_write_iter\n\t\t\t\t fscache_cookie_state_machine\n\t\t\t\t\t cachefiles_withdraw_cookie\n if (!file) return -ENOBUFS\n\t\t\t\t\t cachefiles_clean_up_object\n\t\t\t\t\t cachefiles_unmark_inode_in_use\n\t\t\t\t\t fput(object-\u0026gt;file)\n\t\t\t\t\t object-\u0026gt;file = NULL\n // file NULL pointer dereference!\n __cachefiles_write(..., file, ...)\n\nFix this issue by add an additional reference count to the object-\u0026gt;file\nbefore write/llseek, and decrement after it finished.(CVE-2024-56549)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni3c: master: Fix miss free init_dyn_addr at i3c_master_put_i3c_addrs()\n\nif (dev-\u0026gt;boardinfo \u0026amp;\u0026amp; dev-\u0026gt;boardinfo-\u0026gt;init_dyn_addr)\n ^^^ here check \u0026quot;init_dyn_addr\u0026quot;\n\ti3c_bus_set_addr_slot_status(\u0026amp;master-\u0026gt;bus, dev-\u0026gt;info.dyn_addr, ...)\n\t\t\t\t\t\t ^^^^\n\t\t\t\t\t\t\tfree \u0026quot;dyn_addr\u0026quot;\nFix copy/paste error \u0026quot;dyn_addr\u0026quot; by replacing it with \u0026quot;init_dyn_addr\u0026quot;.(CVE-2024-56562)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\novl: Filter invalid inodes with missing lookup function\n\nAdd a check to the ovl_dentry_weird() function to prevent the\nprocessing of directory inodes that lack the lookup function.\nThis is important because such inodes can cause errors in overlayfs\nwhen passed to the lowerstack.(CVE-2024-56570)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: platform: allegro-dvt: Fix possible memory leak in allocate_buffers_internal()\n\nThe buffer in the loop should be released under the exception path,\notherwise there may be a memory leak here.\n\nTo mitigate this, free the buffer when allegro_alloc_buffer fails.(CVE-2024-56572)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix use-after-free in btrfs_encoded_read_endio()\n\nShinichiro reported the following use-after free that sometimes is\nhappening in our CI system when running fstests\u0026apos; btrfs/284 on a TCMU\nrunner device:\n\n BUG: KASAN: slab-use-after-free in lock_release+0x708/0x780\n Read of size 8 at addr ffff888106a83f18 by task kworker/u80:6/219\n\n CPU: 8 UID: 0 PID: 219 Comm: kworker/u80:6 Not tainted 6.12.0-rc6-kts+ #15\n Hardware name: Supermicro Super Server/X11SPi-TF, BIOS 3.3 02/21/2020\n Workqueue: btrfs-endio btrfs_end_bio_work [btrfs]\n Call Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x6e/0xa0\n ? lock_release+0x708/0x780\n print_report+0x174/0x505\n ? lock_release+0x708/0x780\n ? __virt_addr_valid+0x224/0x410\n ? lock_release+0x708/0x780\n kasan_report+0xda/0x1b0\n ? lock_release+0x708/0x780\n ? __wake_up+0x44/0x60\n lock_release+0x708/0x780\n ? __pfx_lock_release+0x10/0x10\n ? __pfx_do_raw_spin_lock+0x10/0x10\n ? lock_is_held_type+0x9a/0x110\n _raw_spin_unlock_irqrestore+0x1f/0x60\n __wake_up+0x44/0x60\n btrfs_encoded_read_endio+0x14b/0x190 [btrfs]\n btrfs_check_read_bio+0x8d9/0x1360 [btrfs]\n ? lock_release+0x1b0/0x780\n ? trace_lock_acquire+0x12f/0x1a0\n ? __pfx_btrfs_check_read_bio+0x10/0x10 [btrfs]\n ? process_one_work+0x7e3/0x1460\n ? lock_acquire+0x31/0xc0\n ? process_one_work+0x7e3/0x1460\n process_one_work+0x85c/0x1460\n ? __pfx_process_one_work+0x10/0x10\n ? assign_work+0x16c/0x240\n worker_thread+0x5e6/0xfc0\n ? __pfx_worker_thread+0x10/0x10\n kthread+0x2c3/0x3a0\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x31/0x70\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1a/0x30\n \u0026lt;/TASK\u0026gt;\n\n Allocated by task 3661:\n kasan_save_stack+0x30/0x50\n kasan_save_track+0x14/0x30\n __kasan_kmalloc+0xaa/0xb0\n btrfs_encoded_read_regular_fill_pages+0x16c/0x6d0 [btrfs]\n send_extent_data+0xf0f/0x24a0 [btrfs]\n process_extent+0x48a/0x1830 [btrfs]\n changed_cb+0x178b/0x2ea0 [btrfs]\n btrfs_ioctl_send+0x3bf9/0x5c20 [btrfs]\n _btrfs_ioctl_send+0x117/0x330 [btrfs]\n btrfs_ioctl+0x184a/0x60a0 [btrfs]\n __x64_sys_ioctl+0x12e/0x1a0\n do_syscall_64+0x95/0x180\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\n Freed by task 3661:\n kasan_save_stack+0x30/0x50\n kasan_save_track+0x14/0x30\n kasan_save_free_info+0x3b/0x70\n __kasan_slab_free+0x4f/0x70\n kfree+0x143/0x490\n btrfs_encoded_read_regular_fill_pages+0x531/0x6d0 [btrfs]\n send_extent_data+0xf0f/0x24a0 [btrfs]\n process_extent+0x48a/0x1830 [btrfs]\n changed_cb+0x178b/0x2ea0 [btrfs]\n btrfs_ioctl_send+0x3bf9/0x5c20 [btrfs]\n _btrfs_ioctl_send+0x117/0x330 [btrfs]\n btrfs_ioctl+0x184a/0x60a0 [btrfs]\n __x64_sys_ioctl+0x12e/0x1a0\n do_syscall_64+0x95/0x180\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\n The buggy address belongs to the object at ffff888106a83f00\n which belongs to the cache kmalloc-rnd-07-96 of size 96\n The buggy address is located 24 bytes inside of\n freed 96-byte region [ffff888106a83f00, ffff888106a83f60)\n\n The buggy address belongs to the physical page:\n page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888106a83800 pfn:0x106a83\n flags: 0x17ffffc0000000(node=0|zone=2|lastcpupid=0x1fffff)\n page_type: f5(slab)\n raw: 0017ffffc0000000 ffff888100053680 ffffea0004917200 0000000000000004\n raw: ffff888106a83800 0000000080200019 00000001f5000000 0000000000000000\n page dumped because: kasan: bad access detected\n\n Memory state around the buggy address:\n ffff888106a83e00: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc\n ffff888106a83e80: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc\n \u0026gt;ffff888106a83f00: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc\n ^\n ffff888106a83f80: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc\n ffff888106a84000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n ==================================================================\n\nFurther analyzing the trace and \n---truncated---(CVE-2024-56582)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsched/deadline: Fix warning in migrate_enable for boosted tasks\n\nWhen running the following command:\n\nwhile true; do\n stress-ng --cyclic 30 --timeout 30s --minimize --quiet\ndone\n\na warning is eventually triggered:\n\nWARNING: CPU: 43 PID: 2848 at kernel/sched/deadline.c:794\nsetup_new_dl_entity+0x13e/0x180\n...\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? show_trace_log_lvl+0x1c4/0x2df\n ? enqueue_dl_entity+0x631/0x6e0\n ? setup_new_dl_entity+0x13e/0x180\n ? __warn+0x7e/0xd0\n ? report_bug+0x11a/0x1a0\n ? handle_bug+0x3c/0x70\n ? exc_invalid_op+0x14/0x70\n ? asm_exc_invalid_op+0x16/0x20\n enqueue_dl_entity+0x631/0x6e0\n enqueue_task_dl+0x7d/0x120\n __do_set_cpus_allowed+0xe3/0x280\n __set_cpus_allowed_ptr_locked+0x140/0x1d0\n __set_cpus_allowed_ptr+0x54/0xa0\n migrate_enable+0x7e/0x150\n rt_spin_unlock+0x1c/0x90\n group_send_sig_info+0xf7/0x1a0\n ? kill_pid_info+0x1f/0x1d0\n kill_pid_info+0x78/0x1d0\n kill_proc_info+0x5b/0x110\n __x64_sys_kill+0x93/0xc0\n do_syscall_64+0x5c/0xf0\n entry_SYSCALL_64_after_hwframe+0x6e/0x76\n RIP: 0033:0x7f0dab31f92b\n\nThis warning occurs because set_cpus_allowed dequeues and enqueues tasks\nwith the ENQUEUE_RESTORE flag set. If the task is boosted, the warning\nis triggered. A boosted task already had its parameters set by\nrt_mutex_setprio, and a new call to setup_new_dl_entity is unnecessary,\nhence the WARN_ON call.\n\nCheck if we are requeueing a boosted task and avoid calling\nsetup_new_dl_entity if that\u0026apos;s the case.(CVE-2024-56583)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nLoongArch: Fix sleeping in atomic context for PREEMPT_RT\n\nCommit bab1c299f3945ffe79 (\u0026quot;LoongArch: Fix sleeping in atomic context in\nsetup_tlb_handler()\u0026quot;) changes the gfp flag from GFP_KERNEL to GFP_ATOMIC\nfor alloc_pages_node(). However, for PREEMPT_RT kernels we can still get\na \u0026quot;sleeping in atomic context\u0026quot; error:\n\n[ 0.372259] BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48\n[ 0.372266] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/1\n[ 0.372268] preempt_count: 1, expected: 0\n[ 0.372270] RCU nest depth: 1, expected: 1\n[ 0.372272] 3 locks held by swapper/1/0:\n[ 0.372274] #0: 900000000c9f5e60 (\u0026amp;pcp-\u0026gt;lock){+.+.}-{3:3}, at: get_page_from_freelist+0x524/0x1c60\n[ 0.372294] #1: 90000000087013b8 (rcu_read_lock){....}-{1:3}, at: rt_spin_trylock+0x50/0x140\n[ 0.372305] #2: 900000047fffd388 (\u0026amp;zone-\u0026gt;lock){+.+.}-{3:3}, at: __rmqueue_pcplist+0x30c/0xea0\n[ 0.372314] irq event stamp: 0\n[ 0.372316] hardirqs last enabled at (0): [\u0026lt;0000000000000000\u0026gt;] 0x0\n[ 0.372322] hardirqs last disabled at (0): [\u0026lt;9000000005947320\u0026gt;] copy_process+0x9c0/0x26e0\n[ 0.372329] softirqs last enabled at (0): [\u0026lt;9000000005947320\u0026gt;] copy_process+0x9c0/0x26e0\n[ 0.372335] softirqs last disabled at (0): [\u0026lt;0000000000000000\u0026gt;] 0x0\n[ 0.372341] CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Not tainted 6.12.0-rc7+ #1891\n[ 0.372346] Hardware name: Loongson Loongson-3A5000-7A1000-1w-CRB/Loongson-LS3A5000-7A1000-1w-CRB, BIOS vUDK2018-LoongArch-V2.0.0-prebeta9 10/21/2022\n[ 0.372349] Stack : 0000000000000089 9000000005a0db9c 90000000071519c8 9000000100388000\n[ 0.372486] 900000010038b890 0000000000000000 900000010038b898 9000000007e53788\n[ 0.372492] 900000000815bcc8 900000000815bcc0 900000010038b700 0000000000000001\n[ 0.372498] 0000000000000001 4b031894b9d6b725 00000000055ec000 9000000100338fc0\n[ 0.372503] 00000000000000c4 0000000000000001 000000000000002d 0000000000000003\n[ 0.372509] 0000000000000030 0000000000000003 00000000055ec000 0000000000000003\n[ 0.372515] 900000000806d000 9000000007e53788 00000000000000b0 0000000000000004\n[ 0.372521] 0000000000000000 0000000000000000 900000000c9f5f10 0000000000000000\n[ 0.372526] 90000000076f12d8 9000000007e53788 9000000005924778 0000000000000000\n[ 0.372532] 00000000000000b0 0000000000000004 0000000000000000 0000000000070000\n[ 0.372537] ...\n[ 0.372540] Call Trace:\n[ 0.372542] [\u0026lt;9000000005924778\u0026gt;] show_stack+0x38/0x180\n[ 0.372548] [\u0026lt;90000000071519c4\u0026gt;] dump_stack_lvl+0x94/0xe4\n[ 0.372555] [\u0026lt;900000000599b880\u0026gt;] __might_resched+0x1a0/0x260\n[ 0.372561] [\u0026lt;90000000071675cc\u0026gt;] rt_spin_lock+0x4c/0x140\n[ 0.372565] [\u0026lt;9000000005cbb768\u0026gt;] __rmqueue_pcplist+0x308/0xea0\n[ 0.372570] [\u0026lt;9000000005cbed84\u0026gt;] get_page_from_freelist+0x564/0x1c60\n[ 0.372575] [\u0026lt;9000000005cc0d98\u0026gt;] __alloc_pages_noprof+0x218/0x1820\n[ 0.372580] [\u0026lt;900000000593b36c\u0026gt;] tlb_init+0x1ac/0x298\n[ 0.372585] [\u0026lt;9000000005924b74\u0026gt;] per_cpu_trap_init+0x114/0x140\n[ 0.372589] [\u0026lt;9000000005921964\u0026gt;] cpu_probe+0x4e4/0xa60\n[ 0.372592] [\u0026lt;9000000005934874\u0026gt;] start_secondary+0x34/0xc0\n[ 0.372599] [\u0026lt;900000000715615c\u0026gt;] smpboot_entry+0x64/0x6c\n\nThis is because in PREEMPT_RT kernels normal spinlocks are replaced by\nrt spinlocks and rt_spin_lock() will cause sleeping. Fix it by disabling\nNUMA optimization completely for PREEMPT_RT kernels.(CVE-2024-56585)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: fix f2fs_bug_on when uninstalling filesystem call f2fs_evict_inode.\n\ncreating a large files during checkpoint disable until it runs out of\nspace and then delete it, then remount to enable checkpoint again, and\nthen unmount the filesystem triggers the f2fs_bug_on as below:\n\n------------[ cut here ]------------\nkernel BUG at fs/f2fs/inode.c:896!\nCPU: 2 UID: 0 PID: 1286 Comm: umount Not tainted 6.11.0-rc7-dirty #360\nOops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI\nRIP: 0010:f2fs_evict_inode+0x58c/0x610\nCall Trace:\n __die_body+0x15/0x60\n die+0x33/0x50\n do_trap+0x10a/0x120\n f2fs_evict_inode+0x58c/0x610\n do_error_trap+0x60/0x80\n f2fs_evict_inode+0x58c/0x610\n exc_invalid_op+0x53/0x60\n f2fs_evict_inode+0x58c/0x610\n asm_exc_invalid_op+0x16/0x20\n f2fs_evict_inode+0x58c/0x610\n evict+0x101/0x260\n dispose_list+0x30/0x50\n evict_inodes+0x140/0x190\n generic_shutdown_super+0x2f/0x150\n kill_block_super+0x11/0x40\n kill_f2fs_super+0x7d/0x140\n deactivate_locked_super+0x2a/0x70\n cleanup_mnt+0xb3/0x140\n task_work_run+0x61/0x90\n\nThe root cause is: creating large files during disable checkpoint\nperiod results in not enough free segments, so when writing back root\ninode will failed in f2fs_enable_checkpoint. When umount the file\nsystem after enabling checkpoint, the root inode is dirty in\nf2fs_evict_inode function, which triggers BUG_ON. The steps to\nreproduce are as follows:\n\ndd if=/dev/zero of=f2fs.img bs=1M count=55\nmount f2fs.img f2fs_dir -o checkpoint=disable:10%\ndd if=/dev/zero of=big bs=1M count=50\nsync\nrm big\nmount -o remount,checkpoint=enable f2fs_dir\numount f2fs_dir\n\nLet\u0026apos;s redirty inode when there is not free segments during checkpoint\nis disable.(CVE-2024-56586)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Call free_htab_elem() after htab_unlock_bucket()\n\nFor htab of maps, when the map is removed from the htab, it may hold the\nlast reference of the map. bpf_map_fd_put_ptr() will invoke\nbpf_map_free_id() to free the id of the removed map element. However,\nbpf_map_fd_put_ptr() is invoked while holding a bucket lock\n(raw_spin_lock_t), and bpf_map_free_id() attempts to acquire map_idr_lock\n(spinlock_t), triggering the following lockdep warning:\n\n =============================\n [ BUG: Invalid wait context ]\n 6.11.0-rc4+ #49 Not tainted\n -----------------------------\n test_maps/4881 is trying to lock:\n ffffffff84884578 (map_idr_lock){+...}-{3:3}, at: bpf_map_free_id.part.0+0x21/0x70\n other info that might help us debug this:\n context-{5:5}\n 2 locks held by test_maps/4881:\n #0: ffffffff846caf60 (rcu_read_lock){....}-{1:3}, at: bpf_fd_htab_map_update_elem+0xf9/0x270\n #1: ffff888149ced148 (\u0026amp;htab-\u0026gt;lockdep_key#2){....}-{2:2}, at: htab_map_update_elem+0x178/0xa80\n stack backtrace:\n CPU: 0 UID: 0 PID: 4881 Comm: test_maps Not tainted 6.11.0-rc4+ #49\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), ...\n Call Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x6e/0xb0\n dump_stack+0x10/0x20\n __lock_acquire+0x73e/0x36c0\n lock_acquire+0x182/0x450\n _raw_spin_lock_irqsave+0x43/0x70\n bpf_map_free_id.part.0+0x21/0x70\n bpf_map_put+0xcf/0x110\n bpf_map_fd_put_ptr+0x9a/0xb0\n free_htab_elem+0x69/0xe0\n htab_map_update_elem+0x50f/0xa80\n bpf_fd_htab_map_update_elem+0x131/0x270\n htab_map_update_elem+0x50f/0xa80\n bpf_fd_htab_map_update_elem+0x131/0x270\n bpf_map_update_value+0x266/0x380\n __sys_bpf+0x21bb/0x36b0\n __x64_sys_bpf+0x45/0x60\n x64_sys_call+0x1b2a/0x20d0\n do_syscall_64+0x5d/0x100\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nOne way to fix the lockdep warning is using raw_spinlock_t for\nmap_idr_lock as well. However, bpf_map_alloc_id() invokes\nidr_alloc_cyclic() after acquiring map_idr_lock, it will trigger a\nsimilar lockdep warning because the slab\u0026apos;s lock (s-\u0026gt;cpu_slab-\u0026gt;lock) is\nstill a spinlock.\n\nInstead of changing map_idr_lock\u0026apos;s type, fix the issue by invoking\nhtab_put_fd_value() after htab_unlock_bucket(). However, only deferring\nthe invocation of htab_put_fd_value() is not enough, because the old map\npointers in htab of maps can not be saved during batched deletion.\nTherefore, also defer the invocation of free_htab_elem(), so these\nto-be-freed elements could be linked together similar to lru map.\n\nThere are four callers for -\u0026gt;map_fd_put_ptr:\n\n(1) alloc_htab_elem() (through htab_put_fd_value())\nIt invokes -\u0026gt;map_fd_put_ptr() under a raw_spinlock_t. The invocation of\nhtab_put_fd_value() can not simply move after htab_unlock_bucket(),\nbecause the old element has already been stashed in htab-\u0026gt;extra_elems.\nIt may be reused immediately after htab_unlock_bucket() and the\ninvocation of htab_put_fd_value() after htab_unlock_bucket() may release\nthe newly-added element incorrectly. Therefore, saving the map pointer\nof the old element for htab of maps before unlocking the bucket and\nreleasing the map_ptr after unlock. Beside the map pointer in the old\nelement, should do the same thing for the special fields in the old\nelement as well.\n\n(2) free_htab_elem() (through htab_put_fd_value())\nIts caller includes __htab_map_lookup_and_delete_elem(),\nhtab_map_delete_elem() and __htab_map_lookup_and_delete_batch().\n\nFor htab_map_delete_elem(), simply invoke free_htab_elem() after\nhtab_unlock_bucket(). For __htab_map_lookup_and_delete_batch(), just\nlike lru map, linking the to-be-freed element into node_to_free list\nand invoking free_htab_elem() for these element after unlock. It is safe\nto reuse batch_flink as the link for node_to_free, because these\nelements have been removed from the hash llist.\n\nBecause htab of maps doesn\u0026apos;t support lookup_and_delete operation,\n__htab_map_lookup_and_delete_elem() doesn\u0026apos;t have the problem, so kept\nit as\n---truncated---(CVE-2024-56592)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu: set the right AMDGPU sg segment limitation\n\nThe driver needs to set the correct max_segment_size;\notherwise debug_dma_map_sg() will complain about the\nover-mapping of the AMDGPU sg length as following:\n\nWARNING: CPU: 6 PID: 1964 at kernel/dma/debug.c:1178 debug_dma_map_sg+0x2dc/0x370\n[ 364.049444] Modules linked in: veth amdgpu(OE) amdxcp drm_exec gpu_sched drm_buddy drm_ttm_helper ttm(OE) drm_suballoc_helper drm_display_helper drm_kms_helper i2c_algo_bit rpcsec_gss_krb5 auth_rpcgss nfsv4 nfs lockd grace netfs xt_conntrack xt_MASQUERADE nf_conntrack_netlink xfrm_user xfrm_algo iptable_nat xt_addrtype iptable_filter br_netfilter nvme_fabrics overlay nfnetlink_cttimeout nfnetlink openvswitch nsh nf_conncount nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c bridge stp llc amd_atl intel_rapl_msr intel_rapl_common sunrpc sch_fq_codel snd_hda_codec_realtek snd_hda_codec_generic snd_hda_scodec_component snd_hda_codec_hdmi snd_hda_intel snd_intel_dspcfg edac_mce_amd binfmt_misc snd_hda_codec snd_pci_acp6x snd_hda_core snd_acp_config snd_hwdep snd_soc_acpi kvm_amd snd_pcm kvm snd_seq_midi snd_seq_midi_event crct10dif_pclmul ghash_clmulni_intel sha512_ssse3 snd_rawmidi sha256_ssse3 sha1_ssse3 aesni_intel snd_seq nls_iso8859_1 crypto_simd snd_seq_device cryptd snd_timer rapl input_leds snd\n[ 364.049532] ipmi_devintf wmi_bmof ccp serio_raw k10temp sp5100_tco soundcore ipmi_msghandler cm32181 industrialio mac_hid msr parport_pc ppdev lp parport drm efi_pstore ip_tables x_tables pci_stub crc32_pclmul nvme ahci libahci i2c_piix4 r8169 nvme_core i2c_designware_pci realtek i2c_ccgx_ucsi video wmi hid_generic cdc_ether usbnet usbhid hid r8152 mii\n[ 364.049576] CPU: 6 PID: 1964 Comm: rocminfo Tainted: G OE 6.10.0-custom #492\n[ 364.049579] Hardware name: AMD Majolica-RN/Majolica-RN, BIOS RMJ1009A 06/13/2021\n[ 364.049582] RIP: 0010:debug_dma_map_sg+0x2dc/0x370\n[ 364.049585] Code: 89 4d b8 e8 36 b1 86 00 8b 4d b8 48 8b 55 b0 44 8b 45 a8 4c 8b 4d a0 48 89 c6 48 c7 c7 00 4b 74 bc 4c 89 4d b8 e8 b4 73 f3 ff \u0026lt;0f\u0026gt; 0b 4c 8b 4d b8 8b 15 c8 2c b8 01 85 d2 0f 85 ee fd ff ff 8b 05\n[ 364.049588] RSP: 0018:ffff9ca600b57ac0 EFLAGS: 00010286\n[ 364.049590] RAX: 0000000000000000 RBX: ffff88b7c132b0c8 RCX: 0000000000000027\n[ 364.049592] RDX: ffff88bb0f521688 RSI: 0000000000000001 RDI: ffff88bb0f521680\n[ 364.049594] RBP: ffff9ca600b57b20 R08: 000000000000006f R09: ffff9ca600b57930\n[ 364.049596] R10: ffff9ca600b57928 R11: ffffffffbcb46328 R12: 0000000000000000\n[ 364.049597] R13: 0000000000000001 R14: ffff88b7c19c0700 R15: ffff88b7c9059800\n[ 364.049599] FS: 00007fb2d3516e80(0000) GS:ffff88bb0f500000(0000) knlGS:0000000000000000\n[ 364.049601] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 364.049603] CR2: 000055610bd03598 CR3: 00000001049f6000 CR4: 0000000000350ef0\n[ 364.049605] Call Trace:\n[ 364.049607] \u0026lt;TASK\u0026gt;\n[ 364.049609] ? show_regs+0x6d/0x80\n[ 364.049614] ? __warn+0x8c/0x140\n[ 364.049618] ? debug_dma_map_sg+0x2dc/0x370\n[ 364.049621] ? report_bug+0x193/0x1a0\n[ 364.049627] ? handle_bug+0x46/0x80\n[ 364.049631] ? exc_invalid_op+0x1d/0x80\n[ 364.049635] ? asm_exc_invalid_op+0x1f/0x30\n[ 364.049642] ? debug_dma_map_sg+0x2dc/0x370\n[ 364.049647] __dma_map_sg_attrs+0x90/0xe0\n[ 364.049651] dma_map_sgtable+0x25/0x40\n[ 364.049654] amdgpu_bo_move+0x59a/0x850 [amdgpu]\n[ 364.049935] ? srso_return_thunk+0x5/0x5f\n[ 364.049939] ? amdgpu_ttm_tt_populate+0x5d/0xc0 [amdgpu]\n[ 364.050095] ttm_bo_handle_move_mem+0xc3/0x180 [ttm]\n[ 364.050103] ttm_bo_validate+0xc1/0x160 [ttm]\n[ 364.050108] ? amdgpu_ttm_tt_get_user_pages+0xe5/0x1b0 [amdgpu]\n[ 364.050263] amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu+0xa12/0xc90 [amdgpu]\n[ 364.050473] kfd_ioctl_alloc_memory_of_gpu+0x16b/0x3b0 [amdgpu]\n[ 364.050680] kfd_ioctl+0x3c2/0x530 [amdgpu]\n[ 364.050866] ? __pfx_kfd_ioctl_alloc_memory_of_gpu+0x10/0x10 [amdgpu]\n[ 364.05105\n---truncated---(CVE-2024-56594)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\njfs: add a check to prevent array-index-out-of-bounds in dbAdjTree\n\nWhen the value of lp is 0 at the beginning of the for loop, it will\nbecome negative in the next assignment and we should bail out.(CVE-2024-56595)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\njfs: fix array-index-out-of-bounds in jfs_readdir\n\nThe stbl might contain some invalid values. Added a check to\nreturn error code in that case.(CVE-2024-56596)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\njfs: fix shift-out-of-bounds in dbSplit\n\nWhen dmt_budmin is less than zero, it causes errors\nin the later stages. Added a check to return an error beforehand\nin dbAllocCtl itself.(CVE-2024-56597)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: L2CAP: do not leave dangling sk pointer on error in l2cap_sock_create()\n\nbt_sock_alloc() allocates the sk object and attaches it to the provided\nsock object. On error l2cap_sock_alloc() frees the sk object, but the\ndangling pointer is still attached to the sock object, which may create\nuse-after-free in other code.(CVE-2024-56605)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: rtw88: use ieee80211_purge_tx_queue() to purge TX skb\n\nWhen removing kernel modules by:\n rmmod rtw88_8723cs rtw88_8703b rtw88_8723x rtw88_sdio rtw88_core\n\nDriver uses skb_queue_purge() to purge TX skb, but not report tx status\ncausing \u0026quot;Have pending ack frames!\u0026quot; warning. Use ieee80211_purge_tx_queue()\nto correct this.\n\nSince ieee80211_purge_tx_queue() doesn\u0026apos;t take locks, to prevent racing\nbetween TX work and purge TX queue, flush and destroy TX work in advance.\n\n wlan0: deauthenticating from aa:f5:fd:60:4c:a8 by local\n choice (Reason: 3=DEAUTH_LEAVING)\n ------------[ cut here ]------------\n Have pending ack frames!\n WARNING: CPU: 3 PID: 9232 at net/mac80211/main.c:1691\n ieee80211_free_ack_frame+0x5c/0x90 [mac80211]\n CPU: 3 PID: 9232 Comm: rmmod Tainted: G C\n 6.10.1-200.fc40.aarch64 #1\n Hardware name: pine64 Pine64 PinePhone Braveheart\n (1.1)/Pine64 PinePhone Braveheart (1.1), BIOS 2024.01 01/01/2024\n pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : ieee80211_free_ack_frame+0x5c/0x90 [mac80211]\n lr : ieee80211_free_ack_frame+0x5c/0x90 [mac80211]\n sp : ffff80008c1b37b0\n x29: ffff80008c1b37b0 x28: ffff000003be8000 x27: 0000000000000000\n x26: 0000000000000000 x25: ffff000003dc14b8 x24: ffff80008c1b37d0\n x23: ffff000000ff9f80 x22: 0000000000000000 x21: 000000007fffffff\n x20: ffff80007c7e93d8 x19: ffff00006e66f400 x18: 0000000000000000\n x17: ffff7ffffd2b3000 x16: ffff800083fc0000 x15: 0000000000000000\n x14: 0000000000000000 x13: 2173656d61726620 x12: 6b636120676e6964\n x11: 0000000000000000 x10: 000000000000005d x9 : ffff8000802af2b0\n x8 : ffff80008c1b3430 x7 : 0000000000000001 x6 : 0000000000000001\n x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000\n x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000003be8000\n Call trace:\n ieee80211_free_ack_frame+0x5c/0x90 [mac80211]\n idr_for_each+0x74/0x110\n ieee80211_free_hw+0x44/0xe8 [mac80211]\n rtw_sdio_remove+0x9c/0xc0 [rtw88_sdio]\n sdio_bus_remove+0x44/0x180\n device_remove+0x54/0x90\n device_release_driver_internal+0x1d4/0x238\n driver_detach+0x54/0xc0\n bus_remove_driver+0x78/0x108\n driver_unregister+0x38/0x78\n sdio_unregister_driver+0x2c/0x40\n rtw_8723cs_driver_exit+0x18/0x1000 [rtw88_8723cs]\n __do_sys_delete_module.isra.0+0x190/0x338\n __arm64_sys_delete_module+0x1c/0x30\n invoke_syscall+0x74/0x100\n el0_svc_common.constprop.0+0x48/0xf0\n do_el0_svc+0x24/0x38\n el0_svc+0x3c/0x158\n el0t_64_sync_handler+0x120/0x138\n el0t_64_sync+0x194/0x198\n ---[ end trace 0000000000000000 ]---(CVE-2024-56609)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsched/numa: fix memory leak due to the overwritten vma-\u0026gt;numab_state\n\n[Problem Description]\nWhen running the hackbench program of LTP, the following memory leak is\nreported by kmemleak.\n\n # /opt/ltp/testcases/bin/hackbench 20 thread 1000\n Running with 20*40 (== 800) tasks.\n\n # dmesg | grep kmemleak\n ...\n kmemleak: 480 new suspected memory leaks (see /sys/kernel/debug/kmemleak)\n kmemleak: 665 new suspected memory leaks (see /sys/kernel/debug/kmemleak)\n\n # cat /sys/kernel/debug/kmemleak\n unreferenced object 0xffff888cd8ca2c40 (size 64):\n comm \u0026quot;hackbench\u0026quot;, pid 17142, jiffies 4299780315\n hex dump (first 32 bytes):\n ac 74 49 00 01 00 00 00 4c 84 49 00 01 00 00 00 .tI.....L.I.....\n 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n backtrace (crc bff18fd4):\n [\u0026lt;ffffffff81419a89\u0026gt;] __kmalloc_cache_noprof+0x2f9/0x3f0\n [\u0026lt;ffffffff8113f715\u0026gt;] task_numa_work+0x725/0xa00\n [\u0026lt;ffffffff8110f878\u0026gt;] task_work_run+0x58/0x90\n [\u0026lt;ffffffff81ddd9f8\u0026gt;] syscall_exit_to_user_mode+0x1c8/0x1e0\n [\u0026lt;ffffffff81dd78d5\u0026gt;] do_syscall_64+0x85/0x150\n [\u0026lt;ffffffff81e0012b\u0026gt;] entry_SYSCALL_64_after_hwframe+0x76/0x7e\n ...\n\nThis issue can be consistently reproduced on three different servers:\n * a 448-core server\n * a 256-core server\n * a 192-core server\n\n[Root Cause]\nSince multiple threads are created by the hackbench program (along with\nthe command argument \u0026apos;thread\u0026apos;), a shared vma might be accessed by two or\nmore cores simultaneously. When two or more cores observe that\nvma-\u0026gt;numab_state is NULL at the same time, vma-\u0026gt;numab_state will be\noverwritten.\n\nAlthough current code ensures that only one thread scans the VMAs in a\nsingle \u0026apos;numa_scan_period\u0026apos;, there might be a chance for another thread\nto enter in the next \u0026apos;numa_scan_period\u0026apos; while we have not gotten till\nnumab_state allocation [1].\n\nNote that the command `/opt/ltp/testcases/bin/hackbench 50 process 1000`\ncannot the reproduce the issue. It is verified with 200+ test runs.\n\n[Solution]\nUse the cmpxchg atomic operation to ensure that only one thread executes\nthe vma-\u0026gt;numab_state assignment.\n\n[1] https://lore.kernel.org/lkml/1794be3c-358c-4cdc-a43d-a1f841d91ef7@amd.com/(CVE-2024-56613)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnilfs2: fix potential out-of-bounds memory access in nilfs_find_entry()\n\nSyzbot reported that when searching for records in a directory where the\ninode\u0026apos;s i_size is corrupted and has a large value, memory access outside\nthe folio/page range may occur, or a use-after-free bug may be detected if\nKASAN is enabled.\n\nThis is because nilfs_last_byte(), which is called by nilfs_find_entry()\nand others to calculate the number of valid bytes of directory data in a\npage from i_size and the page index, loses the upper 32 bits of the 64-bit\nsize information due to an inappropriate type of local variable to which\nthe i_size value is assigned.\n\nThis caused a large byte offset value due to underflow in the end address\ncalculation in the calling nilfs_find_entry(), resulting in memory access\nthat exceeds the folio/page size.\n\nFix this issue by changing the type of the local variable causing the bit\nloss from \u0026quot;unsigned int\u0026quot; to \u0026quot;u64\u0026quot;. The return value of nilfs_last_byte()\nis also of type \u0026quot;unsigned int\u0026quot;, but it is truncated so as not to exceed\nPAGE_SIZE and no bit loss occurs, so no change is required.(CVE-2024-56619)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: ufs: core: sysfs: Prevent div by zero\n\nPrevent a division by 0 when monitoring is not enabled.(CVE-2024-56622)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix Out-of-Bounds Write in ksmbd_vfs_stream_write\n\nAn offset from client could be a negative value, It could allows\nto write data outside the bounds of the allocated buffer.\nNote that this issue is coming when setting\n\u0026apos;vfs objects = streams_xattr parameter\u0026apos; in ksmbd.conf..(CVE-2024-56626)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: sg: Fix slab-use-after-free read in sg_release()\n\nFix a use-after-free bug in sg_release(), detected by syzbot with KASAN:\n\nBUG: KASAN: slab-use-after-free in lock_release+0x151/0xa30\nkernel/locking/lockdep.c:5838\n__mutex_unlock_slowpath+0xe2/0x750 kernel/locking/mutex.c:912\nsg_release+0x1f4/0x2e0 drivers/scsi/sg.c:407\n\nIn sg_release(), the function kref_put(\u0026amp;sfp-\u0026gt;f_ref, sg_remove_sfp) is\ncalled before releasing the open_rel_lock mutex. The kref_put() call may\ndecrement the reference count of sfp to zero, triggering its cleanup\nthrough sg_remove_sfp(). This cleanup includes scheduling deferred work\nvia sg_remove_sfp_usercontext(), which ultimately frees sfp.\n\nAfter kref_put(), sg_release() continues to unlock open_rel_lock and may\nreference sfp or sdp. If sfp has already been freed, this results in a\nslab-use-after-free error.\n\nMove the kref_put(\u0026amp;sfp-\u0026gt;f_ref, sg_remove_sfp) call after unlocking the\nopen_rel_lock mutex. This ensures:\n\n - No references to sfp or sdp occur after the reference count is\n decremented.\n\n - Cleanup functions such as sg_remove_sfp() and\n sg_remove_sfp_usercontext() can safely execute without impacting the\n mutex handling in sg_release().\n\nThe fix has been tested and validated by syzbot. This patch closes the\nbug reported at the following syzkaller link and ensures proper\nsequencing of resource cleanup and mutex operations, eliminating the\nrisk of use-after-free errors in sg_release().(CVE-2024-56631)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntcp_bpf: Fix the sk_mem_uncharge logic in tcp_bpf_sendmsg\n\nThe current sk memory accounting logic in __SK_REDIRECT is pre-uncharging\ntosend bytes, which is either msg-\u0026gt;sg.size or a smaller value apply_bytes.\n\nPotential problems with this strategy are as follows:\n\n- If the actual sent bytes are smaller than tosend, we need to charge some\n bytes back, as in line 487, which is okay but seems not clean.\n\n- When tosend is set to apply_bytes, as in line 417, and (ret \u0026lt; 0), we may\n miss uncharging (msg-\u0026gt;sg.size - apply_bytes) bytes.\n\n[...]\n415 tosend = msg-\u0026gt;sg.size;\n416 if (psock-\u0026gt;apply_bytes \u0026amp;\u0026amp; psock-\u0026gt;apply_bytes \u0026lt; tosend)\n417 tosend = psock-\u0026gt;apply_bytes;\n[...]\n443 sk_msg_return(sk, msg, tosend);\n444 release_sock(sk);\n446 origsize = msg-\u0026gt;sg.size;\n447 ret = tcp_bpf_sendmsg_redir(sk_redir, redir_ingress,\n448 msg, tosend, flags);\n449 sent = origsize - msg-\u0026gt;sg.size;\n[...]\n454 lock_sock(sk);\n455 if (unlikely(ret \u0026lt; 0)) {\n456 int free = sk_msg_free_nocharge(sk, msg);\n458 if (!cork)\n459 *copied -= free;\n460 }\n[...]\n487 if (eval == __SK_REDIRECT)\n488 sk_mem_charge(sk, tosend - sent);\n[...]\n\nWhen running the selftest test_txmsg_redir_wait_sndmem with txmsg_apply,\nthe following warning will be reported:\n\n------------[ cut here ]------------\nWARNING: CPU: 6 PID: 57 at net/ipv4/af_inet.c:156 inet_sock_destruct+0x190/0x1a0\nModules linked in:\nCPU: 6 UID: 0 PID: 57 Comm: kworker/6:0 Not tainted 6.12.0-rc1.bm.1-amd64+ #43\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014\nWorkqueue: events sk_psock_destroy\nRIP: 0010:inet_sock_destruct+0x190/0x1a0\nRSP: 0018:ffffad0a8021fe08 EFLAGS: 00010206\nRAX: 0000000000000011 RBX: ffff9aab4475b900 RCX: ffff9aab481a0800\nRDX: 0000000000000303 RSI: 0000000000000011 RDI: ffff9aab4475b900\nRBP: ffff9aab4475b990 R08: 0000000000000000 R09: ffff9aab40050ec0\nR10: 0000000000000000 R11: ffff9aae6fdb1d01 R12: ffff9aab49c60400\nR13: ffff9aab49c60598 R14: ffff9aab49c60598 R15: dead000000000100\nFS: 0000000000000000(0000) GS:ffff9aae6fd80000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007ffec7e47bd8 CR3: 00000001a1a1c004 CR4: 0000000000770ef0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nPKRU: 55555554\nCall Trace:\n\u0026lt;TASK\u0026gt;\n? __warn+0x89/0x130\n? inet_sock_destruct+0x190/0x1a0\n? report_bug+0xfc/0x1e0\n? handle_bug+0x5c/0xa0\n? exc_invalid_op+0x17/0x70\n? asm_exc_invalid_op+0x1a/0x20\n? inet_sock_destruct+0x190/0x1a0\n__sk_destruct+0x25/0x220\nsk_psock_destroy+0x2b2/0x310\nprocess_scheduled_works+0xa3/0x3e0\nworker_thread+0x117/0x240\n? __pfx_worker_thread+0x10/0x10\nkthread+0xcf/0x100\n? __pfx_kthread+0x10/0x10\nret_from_fork+0x31/0x40\n? __pfx_kthread+0x10/0x10\nret_from_fork_asm+0x1a/0x30\n\u0026lt;/TASK\u0026gt;\n---[ end trace 0000000000000000 ]---\n\nIn __SK_REDIRECT, a more concise way is delaying the uncharging after sent\nbytes are finalized, and uncharge this value. When (ret \u0026lt; 0), we shall\ninvoke sk_msg_free.\n\nSame thing happens in case __SK_DROP, when tosend is set to apply_bytes,\nwe may miss uncharging (msg-\u0026gt;sg.size - apply_bytes) bytes. The same\nwarning will be reported in selftest.\n\n[...]\n468 case __SK_DROP:\n469 default:\n470 sk_msg_free_partial(sk, msg, tosend);\n471 sk_msg_apply_bytes(psock, tosend);\n472 *copied -= (tosend + delta);\n473 return -EACCES;\n[...]\n\nSo instead of sk_msg_free_partial we can do sk_msg_free here.(CVE-2024-56633)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nft_inner: incorrect percpu area handling under softirq\n\nSoftirq can interrupt ongoing packet from process context that is\nwalking over the percpu area that contains inner header offsets.\n\nDisable bh and perform three checks before restoring the percpu inner\nheader offsets to validate that the percpu area is valid for this\nskbuff:\n\n1) If the NFT_PKTINFO_INNER_FULL flag is set on, then this skbuff\n has already been parsed before for inner header fetching to\n register.\n\n2) Validate that the percpu area refers to this skbuff using the\n skbuff pointer as a cookie. If there is a cookie mismatch, then\n this skbuff needs to be parsed again.\n\n3) Finally, validate if the percpu area refers to this tunnel type.\n\nOnly after these three checks the percpu area is restored to a on-stack\ncopy and bh is enabled again.\n\nAfter inner header fetching, the on-stack copy is stored back to the\npercpu area.(CVE-2024-56638)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: enetc: Do not configure preemptible TCs if SIs do not support\n\nBoth ENETC PF and VF drivers share enetc_setup_tc_mqprio() to configure\nMQPRIO. And enetc_setup_tc_mqprio() calls enetc_change_preemptible_tcs()\nto configure preemptible TCs. However, only PF is able to configure\npreemptible TCs. Because only PF has related registers, while VF does not\nhave these registers. So for VF, its hw-\u0026gt;port pointer is NULL. Therefore,\nVF will access an invalid pointer when accessing a non-existent register,\nwhich will cause a crash issue. The simplified log is as follows.\n\nroot@ls1028ardb:~# tc qdisc add dev eno0vf0 parent root handle 100: \\\nmqprio num_tc 4 map 0 0 1 1 2 2 3 3 queues 1@0 1@1 1@2 1@3 hw 1\n[ 187.290775] Unable to handle kernel paging request at virtual address 0000000000001f00\n[ 187.424831] pc : enetc_mm_commit_preemptible_tcs+0x1c4/0x400\n[ 187.430518] lr : enetc_mm_commit_preemptible_tcs+0x30c/0x400\n[ 187.511140] Call trace:\n[ 187.513588] enetc_mm_commit_preemptible_tcs+0x1c4/0x400\n[ 187.518918] enetc_setup_tc_mqprio+0x180/0x214\n[ 187.523374] enetc_vf_setup_tc+0x1c/0x30\n[ 187.527306] mqprio_enable_offload+0x144/0x178\n[ 187.531766] mqprio_init+0x3ec/0x668\n[ 187.535351] qdisc_create+0x15c/0x488\n[ 187.539023] tc_modify_qdisc+0x398/0x73c\n[ 187.542958] rtnetlink_rcv_msg+0x128/0x378\n[ 187.547064] netlink_rcv_skb+0x60/0x130\n[ 187.550910] rtnetlink_rcv+0x18/0x24\n[ 187.554492] netlink_unicast+0x300/0x36c\n[ 187.558425] netlink_sendmsg+0x1a8/0x420\n[ 187.606759] ---[ end trace 0000000000000000 ]---\n\nIn addition, some PFs also do not support configuring preemptible TCs,\nsuch as eno1 and eno3 on LS1028A. It won\u0026apos;t crash like it does for VFs,\nbut we should prevent these PFs from accessing these unimplemented\nregisters.(CVE-2024-56649)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_event: Fix using rcu_read_(un)lock while iterating\n\nThe usage of rcu_read_(un)lock while inside list_for_each_entry_rcu is\nnot safe since for the most part entries fetched this way shall be\ntreated as rcu_dereference:\n\n\tNote that the value returned by rcu_dereference() is valid\n\tonly within the enclosing RCU read-side critical section [1]_.\n\tFor example, the following is **not** legal::\n\n\t\trcu_read_lock();\n\t\tp = rcu_dereference(head.next);\n\t\trcu_read_unlock();\n\t\tx = p-\u0026gt;address;\t/* BUG!!! */\n\t\trcu_read_lock();\n\t\ty = p-\u0026gt;data;\t/* BUG!!! */\n\t\trcu_read_unlock();(CVE-2024-56654)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5: DR, prevent potential error pointer dereference\n\nThe dr_domain_add_vport_cap() function generally returns NULL on error\nbut sometimes we want it to return ERR_PTR(-EBUSY) so the caller can\nretry. The problem here is that \u0026quot;ret\u0026quot; can be either -EBUSY or -ENOMEM\nand if it\u0026apos;s and -ENOMEM then the error pointer is propogated back and\neventually dereferenced in dr_ste_v0_build_src_gvmi_qpn_tag().(CVE-2024-56660)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nacpi: nfit: vmalloc-out-of-bounds Read in acpi_nfit_ctl\n\nFix an issue detected by syzbot with KASAN:\n\nBUG: KASAN: vmalloc-out-of-bounds in cmd_to_func drivers/acpi/nfit/\ncore.c:416 [inline]\nBUG: KASAN: vmalloc-out-of-bounds in acpi_nfit_ctl+0x20e8/0x24a0\ndrivers/acpi/nfit/core.c:459\n\nThe issue occurs in cmd_to_func when the call_pkg-\u0026gt;nd_reserved2\narray is accessed without verifying that call_pkg points to a buffer\nthat is appropriately sized as a struct nd_cmd_pkg. This can lead\nto out-of-bounds access and undefined behavior if the buffer does not\nhave sufficient space.\n\nTo address this, a check was added in acpi_nfit_ctl() to ensure that\nbuf is not NULL and that buf_len is less than sizeof(*call_pkg)\nbefore accessing it. This ensures safe access to the members of\ncall_pkg, including the nd_reserved2 array.(CVE-2024-56662)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: nl80211: fix NL80211_ATTR_MLO_LINK_ID off-by-one\n\nSince the netlink attribute range validation provides inclusive\nchecking, the *max* of attribute NL80211_ATTR_MLO_LINK_ID should be\nIEEE80211_MLD_MAX_NUM_LINKS - 1 otherwise causing an off-by-one.\n\nOne crash stack for demonstration:\n==================================================================\nBUG: KASAN: wild-memory-access in ieee80211_tx_control_port+0x3b6/0xca0 net/mac80211/tx.c:5939\nRead of size 6 at addr 001102080000000c by task fuzzer.386/9508\n\nCPU: 1 PID: 9508 Comm: syz.1.386 Not tainted 6.1.70 #2\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0x177/0x231 lib/dump_stack.c:106\n print_report+0xe0/0x750 mm/kasan/report.c:398\n kasan_report+0x139/0x170 mm/kasan/report.c:495\n kasan_check_range+0x287/0x290 mm/kasan/generic.c:189\n memcpy+0x25/0x60 mm/kasan/shadow.c:65\n ieee80211_tx_control_port+0x3b6/0xca0 net/mac80211/tx.c:5939\n rdev_tx_control_port net/wireless/rdev-ops.h:761 [inline]\n nl80211_tx_control_port+0x7b3/0xc40 net/wireless/nl80211.c:15453\n genl_family_rcv_msg_doit+0x22e/0x320 net/netlink/genetlink.c:756\n genl_family_rcv_msg net/netlink/genetlink.c:833 [inline]\n genl_rcv_msg+0x539/0x740 net/netlink/genetlink.c:850\n netlink_rcv_skb+0x1de/0x420 net/netlink/af_netlink.c:2508\n genl_rcv+0x24/0x40 net/netlink/genetlink.c:861\n netlink_unicast_kernel net/netlink/af_netlink.c:1326 [inline]\n netlink_unicast+0x74b/0x8c0 net/netlink/af_netlink.c:1352\n netlink_sendmsg+0x882/0xb90 net/netlink/af_netlink.c:1874\n sock_sendmsg_nosec net/socket.c:716 [inline]\n __sock_sendmsg net/socket.c:728 [inline]\n ____sys_sendmsg+0x5cc/0x8f0 net/socket.c:2499\n ___sys_sendmsg+0x21c/0x290 net/socket.c:2553\n __sys_sendmsg net/socket.c:2582 [inline]\n __do_sys_sendmsg net/socket.c:2591 [inline]\n __se_sys_sendmsg+0x19e/0x270 net/socket.c:2589\n do_syscall_x64 arch/x86/entry/common.c:51 [inline]\n do_syscall_64+0x45/0x90 arch/x86/entry/common.c:81\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nUpdate the policy to ensure correct validation.(CVE-2024-56663)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/i915: Fix NULL pointer dereference in capture_engine\n\nWhen the intel_context structure contains NULL,\nit raises a NULL pointer dereference error in drm_info().\n\n(cherry picked from commit 754302a5bc1bd8fd3b7d85c168b0a1af6d4bba4d)(CVE-2024-56667)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nblk-cgroup: Fix UAF in blkcg_unpin_online()\n\nblkcg_unpin_online() walks up the blkcg hierarchy putting the online pin. To\nwalk up, it uses blkcg_parent(blkcg) but it was calling that after\nblkcg_destroy_blkgs(blkcg) which could free the blkcg, leading to the\nfollowing UAF:\n\n ==================================================================\n BUG: KASAN: slab-use-after-free in blkcg_unpin_online+0x15a/0x270\n Read of size 8 at addr ffff8881057678c0 by task kworker/9:1/117\n\n CPU: 9 UID: 0 PID: 117 Comm: kworker/9:1 Not tainted 6.13.0-rc1-work-00182-gb8f52214c61a-dirty #48\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS unknown 02/02/2022\n Workqueue: cgwb_release cgwb_release_workfn\n Call Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x27/0x80\n print_report+0x151/0x710\n kasan_report+0xc0/0x100\n blkcg_unpin_online+0x15a/0x270\n cgwb_release_workfn+0x194/0x480\n process_scheduled_works+0x71b/0xe20\n worker_thread+0x82a/0xbd0\n kthread+0x242/0x2c0\n ret_from_fork+0x33/0x70\n ret_from_fork_asm+0x1a/0x30\n \u0026lt;/TASK\u0026gt;\n ...\n Freed by task 1944:\n kasan_save_track+0x2b/0x70\n kasan_save_free_info+0x3c/0x50\n __kasan_slab_free+0x33/0x50\n kfree+0x10c/0x330\n css_free_rwork_fn+0xe6/0xb30\n process_scheduled_works+0x71b/0xe20\n worker_thread+0x82a/0xbd0\n kthread+0x242/0x2c0\n ret_from_fork+0x33/0x70\n ret_from_fork_asm+0x1a/0x30\n\nNote that the UAF is not easy to trigger as the free path is indirected\nbehind a couple RCU grace periods and a work item execution. I could only\ntrigger it with artifical msleep() injected in blkcg_unpin_online().\n\nFix it by reading the parent pointer before destroying the blkcg\u0026apos;s blkg\u0026apos;s.(CVE-2024-56672)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nocteontx2-pf: handle otx2_mbox_get_rsp errors in otx2_common.c\n\nAdd error pointer check after calling otx2_mbox_get_rsp().(CVE-2024-56679)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmfd: intel_soc_pmic_bxtwc: Use IRQ domain for USB Type-C device\n\nWhile design wise the idea of converting the driver to use\nthe hierarchy of the IRQ chips is correct, the implementation\nhas (inherited) flaws. This was unveiled when platform_get_irq()\nhad started WARN() on IRQ 0 that is supposed to be a Linux\nIRQ number (also known as vIRQ).\n\nRework the driver to respect IRQ domain when creating each MFD\ndevice separately, as the domain is not the same for all of them.(CVE-2024-56691)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf, sockmap: Several fixes to bpf_msg_pop_data\n\nSeveral fixes to bpf_msg_pop_data,\n1. In sk_msg_shift_left, we should put_page\n2. if (len == 0), return early is better\n3. pop the entire sk_msg (last == msg-\u0026gt;sg.size) should be supported\n4. Fix for the value of variable \u0026quot;a\u0026quot;\n5. In sk_msg_shift_left, after shifting, i has already pointed to the next\nelement. Addtional sk_msg_iter_var_next may result in BUG.(CVE-2024-56720)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nocteontx2-pf: handle otx2_mbox_get_rsp errors in cn10k.c\n\nAdd error pointer check after calling otx2_mbox_get_rsp().(CVE-2024-56726)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nrtc: check if __rtc_read_time was successful in rtc_timer_do_work()\n\nIf the __rtc_read_time call fails,, the struct rtc_time tm; may contain\nuninitialized data, or an illegal date/time read from the RTC hardware.\n\nWhen calling rtc_tm_to_ktime later, the result may be a very large value\n(possibly KTIME_MAX). If there are periodic timers in rtc-\u0026gt;timerqueue,\nthey will continually expire, may causing kernel softlockup.(CVE-2024-56739)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvfio/mlx5: Fix an unwind issue in mlx5vf_add_migration_pages()\n\nFix an unwind issue in mlx5vf_add_migration_pages().\n\nIf a set of pages is allocated but fails to be added to the SG table,\nthey need to be freed to prevent a memory leak.\n\nAny pages successfully added to the SG table will be freed as part of\nmlx5vf_free_data_buffer().(CVE-2024-56742)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nPCI: Fix reset_method_store() memory leak\n\nIn reset_method_store(), a string is allocated via kstrndup() and assigned\nto the local \u0026quot;options\u0026quot;. options is then used in with strsep() to find\nspaces:\n\n while ((name = strsep(\u0026amp;options, \u0026quot; \u0026quot;)) != NULL) {\n\nIf there are no remaining spaces, then options is set to NULL by strsep(),\nso the subsequent kfree(options) doesn\u0026apos;t free the memory allocated via\nkstrndup().\n\nFix by using a separate tmp_options to iterate with strsep() so options is\npreserved.(CVE-2024-56745)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qedi: Fix a possible memory leak in qedi_alloc_and_init_sb()\n\nHook \u0026quot;qedi_ops-\u0026gt;common-\u0026gt;sb_init = qed_sb_init\u0026quot; does not release the DMA\nmemory sb_virt when it fails. Add dma_free_coherent() to free it. This\nis the same way as qedr_alloc_mem_sb() and qede_alloc_mem_sb().(CVE-2024-56747)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfs/fscache: Add a memory barrier for FSCACHE_VOLUME_CREATING\n\nIn fscache_create_volume(), there is a missing memory barrier between the\nbit-clearing operation and the wake-up operation. This may cause a\nsituation where, after a wake-up, the bit-clearing operation hasn\u0026apos;t been\ndetected yet, leading to an indefinite wait. The triggering process is as\nfollows:\n\n [cookie1] [cookie2] [volume_work]\nfscache_perform_lookup\n fscache_create_volume\n fscache_perform_lookup\n fscache_create_volume\n\t\t\t fscache_create_volume_work\n cachefiles_acquire_volume\n clear_and_wake_up_bit\n test_and_set_bit\n test_and_set_bit\n goto maybe_wait\n goto no_wait\n\nIn the above process, cookie1 and cookie2 has the same volume. When cookie1\nenters the -no_wait- process, it will clear the bit and wake up the waiting\nprocess. If a barrier is missing, it may cause cookie2 to remain in the\n-wait- process indefinitely.\n\nIn commit 3288666c7256 (\u0026quot;fscache: Use clear_and_wake_up_bit() in\nfscache_create_volume_work()\u0026quot;), barriers were added to similar operations\nin fscache_create_volume_work(), but fscache_create_volume() was missed.\n\nBy combining the clear and wake operations into clear_and_wake_up_bit() to\nfix this issue.(CVE-2024-56755)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvme-pci: fix freeing of the HMB descriptor table\n\nThe HMB descriptor table is sized to the maximum number of descriptors\nthat could be used for a given device, but __nvme_alloc_host_mem could\nbreak out of the loop earlier on memory allocation failure and end up\nusing less descriptors than planned for, which leads to an incorrect\nsize passed to dma_free_coherent.\n\nIn practice this was not showing up because the number of descriptors\ntends to be low and the dma coherent allocator always allocates and\nfrees at least a page.(CVE-2024-56756)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix use-after-free when COWing tree bock and tracing is enabled\n\nWhen a COWing a tree block, at btrfs_cow_block(), and we have the\ntracepoint trace_btrfs_cow_block() enabled and preemption is also enabled\n(CONFIG_PREEMPT=y), we can trigger a use-after-free in the COWed extent\nbuffer while inside the tracepoint code. This is because in some paths\nthat call btrfs_cow_block(), such as btrfs_search_slot(), we are holding\nthe last reference on the extent buffer @buf so btrfs_force_cow_block()\ndrops the last reference on the @buf extent buffer when it calls\nfree_extent_buffer_stale(buf), which schedules the release of the extent\nbuffer with RCU. This means that if we are on a kernel with preemption,\nthe current task may be preempted before calling trace_btrfs_cow_block()\nand the extent buffer already released by the time trace_btrfs_cow_block()\nis called, resulting in a use-after-free.\n\nFix this by moving the trace_btrfs_cow_block() from btrfs_cow_block() to\nbtrfs_force_cow_block() before the COWed extent buffer is freed.\nThis also has a side effect of invoking the tracepoint in the tree defrag\ncode, at defrag.c:btrfs_realloc_node(), since btrfs_force_cow_block() is\ncalled there, but this is fine and it was actually missing there.(CVE-2024-56759)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Prevent bad count for tracing_cpumask_write\n\nIf a large count is provided, it will trigger a warning in bitmap_parse_user.\nAlso check zero for it.(CVE-2024-56763)",
"id": "OESA-2025-1078",
"modified": "2026-08-06T11:08:10Z",
"published": "2025-01-24T11:08:10Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1078"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52887"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36013"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36021"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38540"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38547"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39292"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39497"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40942"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41017"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41022"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41027"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41034"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41055"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41065"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41070"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41078"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41081"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41089"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41095"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41097"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42076"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42077"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42080"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42082"
},
{
"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-42090"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42092"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42093"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42094"
},
{
"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-42106"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42119"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42124"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42137"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42143"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42145"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42148"
},
{
"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-42281"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42288"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42304"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42310"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42318"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43839"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43854"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43879"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44944"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45006"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46707"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46770"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46828"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46848"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47670"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49938"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49944"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49952"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49959"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49963"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50073"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50133"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50142"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50167"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50168"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50251"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53050"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53099"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53101"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53128"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53150"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53155"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53157"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53158"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53159"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53160"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53171"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53180"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53187"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53190"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53191"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53194"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53196"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53203"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53213"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53215"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53218"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53219"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53224"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53226"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53229"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53231"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53234"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53239"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53241"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-55639"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56543"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56546"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56549"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56562"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56570"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56572"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56582"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56583"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56585"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56586"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56592"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56594"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56595"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56596"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56597"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56605"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56609"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56613"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56619"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56622"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56626"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56631"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56633"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56638"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56649"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56654"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56660"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56662"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56663"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56667"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56672"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56679"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56691"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56720"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56726"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56739"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56742"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56745"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56747"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56755"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56756"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56759"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56763"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2023-52887",
"CVE-2024-36013",
"CVE-2024-36021",
"CVE-2024-38540",
"CVE-2024-38547",
"CVE-2024-39292",
"CVE-2024-39497",
"CVE-2024-40942",
"CVE-2024-41017",
"CVE-2024-41022",
"CVE-2024-41027",
"CVE-2024-41034",
"CVE-2024-41055",
"CVE-2024-41065",
"CVE-2024-41070",
"CVE-2024-41078",
"CVE-2024-41081",
"CVE-2024-41089",
"CVE-2024-41095",
"CVE-2024-41097",
"CVE-2024-42076",
"CVE-2024-42077",
"CVE-2024-42080",
"CVE-2024-42082",
"CVE-2024-42084",
"CVE-2024-42087",
"CVE-2024-42089",
"CVE-2024-42090",
"CVE-2024-42092",
"CVE-2024-42093",
"CVE-2024-42094",
"CVE-2024-42095",
"CVE-2024-42096",
"CVE-2024-42098",
"CVE-2024-42106",
"CVE-2024-42119",
"CVE-2024-42124",
"CVE-2024-42137",
"CVE-2024-42143",
"CVE-2024-42145",
"CVE-2024-42148",
"CVE-2024-42244",
"CVE-2024-42246",
"CVE-2024-42281",
"CVE-2024-42288",
"CVE-2024-42304",
"CVE-2024-42310",
"CVE-2024-42318",
"CVE-2024-43839",
"CVE-2024-43854",
"CVE-2024-43879",
"CVE-2024-44944",
"CVE-2024-45006",
"CVE-2024-46707",
"CVE-2024-46770",
"CVE-2024-46828",
"CVE-2024-46848",
"CVE-2024-47670",
"CVE-2024-49938",
"CVE-2024-49944",
"CVE-2024-49952",
"CVE-2024-49959",
"CVE-2024-49963",
"CVE-2024-50073",
"CVE-2024-50133",
"CVE-2024-50142",
"CVE-2024-50167",
"CVE-2024-50168",
"CVE-2024-50251",
"CVE-2024-53050",
"CVE-2024-53099",
"CVE-2024-53101",
"CVE-2024-53128",
"CVE-2024-53150",
"CVE-2024-53155",
"CVE-2024-53157",
"CVE-2024-53158",
"CVE-2024-53159",
"CVE-2024-53160",
"CVE-2024-53171",
"CVE-2024-53180",
"CVE-2024-53187",
"CVE-2024-53190",
"CVE-2024-53191",
"CVE-2024-53194",
"CVE-2024-53196",
"CVE-2024-53203",
"CVE-2024-53213",
"CVE-2024-53215",
"CVE-2024-53218",
"CVE-2024-53219",
"CVE-2024-53224",
"CVE-2024-53226",
"CVE-2024-53229",
"CVE-2024-53231",
"CVE-2024-53234",
"CVE-2024-53239",
"CVE-2024-53241",
"CVE-2024-55639",
"CVE-2024-56543",
"CVE-2024-56546",
"CVE-2024-56549",
"CVE-2024-56562",
"CVE-2024-56570",
"CVE-2024-56572",
"CVE-2024-56582",
"CVE-2024-56583",
"CVE-2024-56585",
"CVE-2024-56586",
"CVE-2024-56592",
"CVE-2024-56594",
"CVE-2024-56595",
"CVE-2024-56596",
"CVE-2024-56597",
"CVE-2024-56605",
"CVE-2024-56609",
"CVE-2024-56613",
"CVE-2024-56619",
"CVE-2024-56622",
"CVE-2024-56626",
"CVE-2024-56631",
"CVE-2024-56633",
"CVE-2024-56638",
"CVE-2024-56649",
"CVE-2024-56654",
"CVE-2024-56660",
"CVE-2024-56662",
"CVE-2024-56663",
"CVE-2024-56667",
"CVE-2024-56672",
"CVE-2024-56679",
"CVE-2024-56691",
"CVE-2024-56720",
"CVE-2024-56726",
"CVE-2024-56739",
"CVE-2024-56742",
"CVE-2024-56745",
"CVE-2024-56747",
"CVE-2024-56755",
"CVE-2024-56756",
"CVE-2024-56759",
"CVE-2024-56763"
]
}
OPENSUSE-SU-2024:14500-1
Vulnerability from csaf_opensuse - Published: 2024-11-15 00:00 - Updated: 2026-09-20 21:21Sightings
| 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.