Action not permitted
Modal body text goes here.
Modal Title
Modal Body
CVE-2023-52880 (GCVE-0-2023-52880)
Vulnerability from cvelistv5 – Published: 2024-05-24 15:33 – Updated: 2026-08-05 09:11| Vendor | Product | Version | CPE status | |
|---|---|---|---|---|
| Linux | Linux |
Affected:
e1eaea46bb4020b38a141b84f88565d4603f8dd0 , < 7d303dee473ba3529d75b63491e9963342107bed
(git)
Affected: e1eaea46bb4020b38a141b84f88565d4603f8dd0 , < 7a529c9023a197ab3bf09bb95df32a3813f7ba58 (git) Affected: e1eaea46bb4020b38a141b84f88565d4603f8dd0 , < ada28eb4b9561aab93942f3224a2e41d76fe57fa (git) Affected: e1eaea46bb4020b38a141b84f88565d4603f8dd0 , < 2d154a54c58f9c8375bfbea9f7e51ba3bfb2e43a (git) Affected: e1eaea46bb4020b38a141b84f88565d4603f8dd0 , < 2b85977977cbd120591b23c2450e90a5806a7167 (git) Affected: e1eaea46bb4020b38a141b84f88565d4603f8dd0 , < 67c37756898a5a6b2941a13ae7260c89b54e0d88 (git) |
guessed | |
| Linux | Linux |
Affected:
2.6.35
Unaffected: 0 , < 2.6.35 (semver) Unaffected: 4.19.312 , ≤ 4.19.* (semver) Unaffected: 5.4.274 , ≤ 5.4.* (semver) Unaffected: 5.10.215 , ≤ 5.10.* (semver) Unaffected: 5.15.155 , ≤ 5.15.* (semver) Unaffected: 6.1.86 , ≤ 6.1.* (semver) Unaffected: 6.6 , ≤ * (original_commit_for_fix) |
guessed |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2023-52880",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2024-05-24T19:10:27.057428Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2024-06-04T17:23:31.686Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
},
{
"providerMetadata": {
"dateUpdated": "2024-08-02T23:18:41.167Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/7d303dee473ba3529d75b63491e9963342107bed"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/7a529c9023a197ab3bf09bb95df32a3813f7ba58"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/ada28eb4b9561aab93942f3224a2e41d76fe57fa"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/2d154a54c58f9c8375bfbea9f7e51ba3bfb2e43a"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/2b85977977cbd120591b23c2450e90a5806a7167"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/67c37756898a5a6b2941a13ae7260c89b54e0d88"
},
{
"tags": [
"x_transferred"
],
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"
},
{
"tags": [
"x_transferred"
],
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"
}
],
"title": "CVE Program Container"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/tty/n_gsm.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "7d303dee473ba3529d75b63491e9963342107bed",
"status": "affected",
"version": "e1eaea46bb4020b38a141b84f88565d4603f8dd0",
"versionType": "git"
},
{
"lessThan": "7a529c9023a197ab3bf09bb95df32a3813f7ba58",
"status": "affected",
"version": "e1eaea46bb4020b38a141b84f88565d4603f8dd0",
"versionType": "git"
},
{
"lessThan": "ada28eb4b9561aab93942f3224a2e41d76fe57fa",
"status": "affected",
"version": "e1eaea46bb4020b38a141b84f88565d4603f8dd0",
"versionType": "git"
},
{
"lessThan": "2d154a54c58f9c8375bfbea9f7e51ba3bfb2e43a",
"status": "affected",
"version": "e1eaea46bb4020b38a141b84f88565d4603f8dd0",
"versionType": "git"
},
{
"lessThan": "2b85977977cbd120591b23c2450e90a5806a7167",
"status": "affected",
"version": "e1eaea46bb4020b38a141b84f88565d4603f8dd0",
"versionType": "git"
},
{
"lessThan": "67c37756898a5a6b2941a13ae7260c89b54e0d88",
"status": "affected",
"version": "e1eaea46bb4020b38a141b84f88565d4603f8dd0",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/tty/n_gsm.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "2.6.35"
},
{
"lessThan": "2.6.35",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "4.19.*",
"status": "unaffected",
"version": "4.19.312",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.274",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.215",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.155",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.86",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.6",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "4.19.312",
"versionStartIncluding": "2.6.35",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.4.274",
"versionStartIncluding": "2.6.35",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.10.215",
"versionStartIncluding": "2.6.35",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.15.155",
"versionStartIncluding": "2.6.35",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.1.86",
"versionStartIncluding": "2.6.35",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6",
"versionStartIncluding": "2.6.35",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ntty: n_gsm: require CAP_NET_ADMIN to attach N_GSM0710 ldisc\n\nAny unprivileged user can attach N_GSM0710 ldisc, but it requires\nCAP_NET_ADMIN to create a GSM network anyway.\n\nRequire initial namespace CAP_NET_ADMIN to do that."
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 7.8,
"baseSeverity": "HIGH",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"scenarios": [
{
"lang": "en",
"value": "AV:L - Exploitation is entirely local: an attacker opens a pty (/dev/ptmx), issues ioctl(TIOCSETD, N_GSM0710) \u2192 tiocsetd \u2192 tty_set_ldisc \u2192 gsmld_open, then drives GSMIOC_SETCONF and frame I/O on that tty. There is no network-facing or adjacent-link path into this code.\nAC:L - Attaching the ldisc and configuring the mux is fully attacker-controlled and deterministic on a self-owned pty, with no race or other condition outside the attacker\u2019s influence.\nPR:L - Before the fix, gsmld_open had no capability check, so any unprivileged local user with a pty could attach N_GSM0710; CAP_NET_ADMIN was only required later for GSMIOC_ENABLE_NET, not for attach/configure.\nUI:N - The attacker performs openpty, TIOCSETD, GSMIOC_SETCONF, and subsequent I/O entirely in their own process; no victim action is required.\nS:U - Impact remains within the host kernel\u2019s security authority as a local privilege-escalation/DoS boundary; no VM, IOMMU, or sandbox boundary is crossed.\nC:H - Unprivileged attach exposes the full n_gsm mux/parser heap paths; throughout this CVE\u2019s lifetime the same entry path enabled serious memory-corruption bugs (e.g. CVE-2024-36016 heap OOB readable via DLCI/tty paths, timer/cleanup UAFs), yielding kernel disclosure primitives.\nI:H - The same exposed attach/configure/cleanup surface enables heap overflow and use-after-free write primitives against adjacent slab objects and gsm_mux control state, supporting arbitrary write and control-flow hijack.\nA:H - Abusing the unprivileged mux attach/teardown and parser paths reliably corrupts kernel state and triggers oops/panic (as seen in related n_gsm KASAN/oops reports), fully denying host availability."
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-08-05T09:11:49.513Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/7d303dee473ba3529d75b63491e9963342107bed"
},
{
"url": "https://git.kernel.org/stable/c/7a529c9023a197ab3bf09bb95df32a3813f7ba58"
},
{
"url": "https://git.kernel.org/stable/c/ada28eb4b9561aab93942f3224a2e41d76fe57fa"
},
{
"url": "https://git.kernel.org/stable/c/2d154a54c58f9c8375bfbea9f7e51ba3bfb2e43a"
},
{
"url": "https://git.kernel.org/stable/c/2b85977977cbd120591b23c2450e90a5806a7167"
},
{
"url": "https://git.kernel.org/stable/c/67c37756898a5a6b2941a13ae7260c89b54e0d88"
}
],
"title": "tty: n_gsm: require CAP_NET_ADMIN to attach N_GSM0710 ldisc",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2023-52880",
"datePublished": "2024-05-24T15:33:17.439Z",
"dateReserved": "2024-05-21T15:35:00.781Z",
"dateUpdated": "2026-08-05T09:11:49.513Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"epss": {
"cve": "CVE-2023-52880",
"date": "2026-09-22",
"epss": "0.00245",
"percentile": "0.16033"
},
"nvd": {
"cve": {
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/tty/n_gsm.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "7d303dee473ba3529d75b63491e9963342107bed",
"status": "affected",
"version": "e1eaea46bb4020b38a141b84f88565d4603f8dd0",
"versionType": "git"
},
{
"lessThan": "7a529c9023a197ab3bf09bb95df32a3813f7ba58",
"status": "affected",
"version": "e1eaea46bb4020b38a141b84f88565d4603f8dd0",
"versionType": "git"
},
{
"lessThan": "ada28eb4b9561aab93942f3224a2e41d76fe57fa",
"status": "affected",
"version": "e1eaea46bb4020b38a141b84f88565d4603f8dd0",
"versionType": "git"
},
{
"lessThan": "2d154a54c58f9c8375bfbea9f7e51ba3bfb2e43a",
"status": "affected",
"version": "e1eaea46bb4020b38a141b84f88565d4603f8dd0",
"versionType": "git"
},
{
"lessThan": "2b85977977cbd120591b23c2450e90a5806a7167",
"status": "affected",
"version": "e1eaea46bb4020b38a141b84f88565d4603f8dd0",
"versionType": "git"
},
{
"lessThan": "67c37756898a5a6b2941a13ae7260c89b54e0d88",
"status": "affected",
"version": "e1eaea46bb4020b38a141b84f88565d4603f8dd0",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/tty/n_gsm.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "2.6.35"
},
{
"lessThan": "2.6.35",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "4.19.*",
"status": "unaffected",
"version": "4.19.312",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.274",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.215",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.155",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.86",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.6",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"configurations": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "23F858DD-6739-4BD9-9DA9-A9F5F66187C0",
"versionEndExcluding": "4.19.312",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "F45A0F3C-C16D-49C4-86D6-D021C3D4B834",
"versionEndExcluding": "5.4.274",
"versionStartIncluding": "4.20",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "9CD5894E-58E9-4B4A-B0F4-3E6BC134B8F5",
"versionEndExcluding": "5.10.215",
"versionStartIncluding": "5.5",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "F11B6314-A852-4FBD-AD84-ECE23F5C092B",
"versionEndExcluding": "5.15.155",
"versionStartIncluding": "5.11",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "F5D13FF4-8931-475F-A397-FD0594589F56",
"versionEndExcluding": "6.1.86",
"versionStartIncluding": "5.16",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "6747FDB4-EF6B-4019-9232-82D90A3D6E73",
"versionEndExcluding": "6.6",
"versionStartIncluding": "6.2",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
},
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:debian:debian_linux:10.0:*:*:*:*:*:*:*",
"matchCriteriaId": "07B237A9-69A3-4A9C-9DA0-4E06BD37AE73",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ntty: n_gsm: require CAP_NET_ADMIN to attach N_GSM0710 ldisc\n\nAny unprivileged user can attach N_GSM0710 ldisc, but it requires\nCAP_NET_ADMIN to create a GSM network anyway.\n\nRequire initial namespace CAP_NET_ADMIN to do that."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tty: n_gsm: requiere CAP_NET_ADMIN para adjuntar el ldisc N_GSM0710. Cualquier usuario sin privilegios puede adjuntar el ldisc N_GSM0710, pero de todos modos requiere CAP_NET_ADMIN para crear una red GSM. Requiere el espacio de nombres inicial CAP_NET_ADMIN para hacer eso."
}
],
"id": "CVE-2023-52880",
"lastModified": "2026-08-04T10:18:47.410",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 7.8,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 5.9,
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"type": "Secondary"
},
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 5.5,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 3.6,
"source": "nvd@nist.gov",
"type": "Primary"
}
],
"ssvcV203": [
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"ssvcData": {
"id": "CVE-2023-52880",
"options": [
{
"exploitation": "none"
},
{
"automatable": "no"
},
{
"technicalImpact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2024-05-24T19:10:27.057428Z",
"version": "2.0.3"
}
}
]
},
"published": "2024-05-24T16:15:10.033",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/2b85977977cbd120591b23c2450e90a5806a7167"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/2d154a54c58f9c8375bfbea9f7e51ba3bfb2e43a"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/67c37756898a5a6b2941a13ae7260c89b54e0d88"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/7a529c9023a197ab3bf09bb95df32a3813f7ba58"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/7d303dee473ba3529d75b63491e9963342107bed"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/ada28eb4b9561aab93942f3224a2e41d76fe57fa"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/2b85977977cbd120591b23c2450e90a5806a7167"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/2d154a54c58f9c8375bfbea9f7e51ba3bfb2e43a"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/67c37756898a5a6b2941a13ae7260c89b54e0d88"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/7a529c9023a197ab3bf09bb95df32a3813f7ba58"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/7d303dee473ba3529d75b63491e9963342107bed"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/ada28eb4b9561aab93942f3224a2e41d76fe57fa"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Mailing List",
"Third Party Advisory"
],
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Mailing List",
"Third Party Advisory"
],
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00020.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": "Low",
"current_release_date": "2026-08-04T22:56:31+00:00",
"cve": "CVE-2023-52880",
"id": "CVE-2023-52880",
"initial_release_date": "2023-01-01T00:00:00+00:00",
"product_status:fixed": "513",
"product_status:known_affected": "98",
"product_status:known_not_affected": "15",
"source": "Red Hat CSAF VEX",
"status": "final",
"title": "kernel: tty: n_gsm: require CAP_NET_ADMIN to attach N_GSM0710 ldisc",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2023/cve-2023-52880.json",
"version": "3"
},
"vulnrichment": {
"containers": {
"adp": [
{
"providerMetadata": {
"dateUpdated": "2024-08-02T23:18:41.167Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/7d303dee473ba3529d75b63491e9963342107bed"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/7a529c9023a197ab3bf09bb95df32a3813f7ba58"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/ada28eb4b9561aab93942f3224a2e41d76fe57fa"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/2d154a54c58f9c8375bfbea9f7e51ba3bfb2e43a"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/2b85977977cbd120591b23c2450e90a5806a7167"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/67c37756898a5a6b2941a13ae7260c89b54e0d88"
},
{
"tags": [
"x_transferred"
],
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"
},
{
"tags": [
"x_transferred"
],
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"
}
],
"title": "CVE Program Container"
},
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2023-52880",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2024-05-24T19:10:27.057428Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2024-05-24T19:10:42.540Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/tty/n_gsm.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "7d303dee473ba3529d75b63491e9963342107bed",
"status": "affected",
"version": "e1eaea46bb4020b38a141b84f88565d4603f8dd0",
"versionType": "git"
},
{
"lessThan": "7a529c9023a197ab3bf09bb95df32a3813f7ba58",
"status": "affected",
"version": "e1eaea46bb4020b38a141b84f88565d4603f8dd0",
"versionType": "git"
},
{
"lessThan": "ada28eb4b9561aab93942f3224a2e41d76fe57fa",
"status": "affected",
"version": "e1eaea46bb4020b38a141b84f88565d4603f8dd0",
"versionType": "git"
},
{
"lessThan": "2d154a54c58f9c8375bfbea9f7e51ba3bfb2e43a",
"status": "affected",
"version": "e1eaea46bb4020b38a141b84f88565d4603f8dd0",
"versionType": "git"
},
{
"lessThan": "2b85977977cbd120591b23c2450e90a5806a7167",
"status": "affected",
"version": "e1eaea46bb4020b38a141b84f88565d4603f8dd0",
"versionType": "git"
},
{
"lessThan": "67c37756898a5a6b2941a13ae7260c89b54e0d88",
"status": "affected",
"version": "e1eaea46bb4020b38a141b84f88565d4603f8dd0",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/tty/n_gsm.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "2.6.35"
},
{
"lessThan": "2.6.35",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "4.19.*",
"status": "unaffected",
"version": "4.19.312",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.274",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.215",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.155",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.86",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.6",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "4.19.312",
"versionStartIncluding": "2.6.35",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.4.274",
"versionStartIncluding": "2.6.35",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.10.215",
"versionStartIncluding": "2.6.35",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.15.155",
"versionStartIncluding": "2.6.35",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.1.86",
"versionStartIncluding": "2.6.35",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6",
"versionStartIncluding": "2.6.35",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ntty: n_gsm: require CAP_NET_ADMIN to attach N_GSM0710 ldisc\n\nAny unprivileged user can attach N_GSM0710 ldisc, but it requires\nCAP_NET_ADMIN to create a GSM network anyway.\n\nRequire initial namespace CAP_NET_ADMIN to do that."
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 7.8,
"baseSeverity": "HIGH",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"scenarios": [
{
"lang": "en",
"value": "AV:L - Exploitation is entirely local: an attacker opens a pty (/dev/ptmx), issues ioctl(TIOCSETD, N_GSM0710) \u2192 tiocsetd \u2192 tty_set_ldisc \u2192 gsmld_open, then drives GSMIOC_SETCONF and frame I/O on that tty. There is no network-facing or adjacent-link path into this code.\nAC:L - Attaching the ldisc and configuring the mux is fully attacker-controlled and deterministic on a self-owned pty, with no race or other condition outside the attacker\u2019s influence.\nPR:L - Before the fix, gsmld_open had no capability check, so any unprivileged local user with a pty could attach N_GSM0710; CAP_NET_ADMIN was only required later for GSMIOC_ENABLE_NET, not for attach/configure.\nUI:N - The attacker performs openpty, TIOCSETD, GSMIOC_SETCONF, and subsequent I/O entirely in their own process; no victim action is required.\nS:U - Impact remains within the host kernel\u2019s security authority as a local privilege-escalation/DoS boundary; no VM, IOMMU, or sandbox boundary is crossed.\nC:H - Unprivileged attach exposes the full n_gsm mux/parser heap paths; throughout this CVE\u2019s lifetime the same entry path enabled serious memory-corruption bugs (e.g. CVE-2024-36016 heap OOB readable via DLCI/tty paths, timer/cleanup UAFs), yielding kernel disclosure primitives.\nI:H - The same exposed attach/configure/cleanup surface enables heap overflow and use-after-free write primitives against adjacent slab objects and gsm_mux control state, supporting arbitrary write and control-flow hijack.\nA:H - Abusing the unprivileged mux attach/teardown and parser paths reliably corrupts kernel state and triggers oops/panic (as seen in related n_gsm KASAN/oops reports), fully denying host availability."
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-08-05T09:11:49.513Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/7d303dee473ba3529d75b63491e9963342107bed"
},
{
"url": "https://git.kernel.org/stable/c/7a529c9023a197ab3bf09bb95df32a3813f7ba58"
},
{
"url": "https://git.kernel.org/stable/c/ada28eb4b9561aab93942f3224a2e41d76fe57fa"
},
{
"url": "https://git.kernel.org/stable/c/2d154a54c58f9c8375bfbea9f7e51ba3bfb2e43a"
},
{
"url": "https://git.kernel.org/stable/c/2b85977977cbd120591b23c2450e90a5806a7167"
},
{
"url": "https://git.kernel.org/stable/c/67c37756898a5a6b2941a13ae7260c89b54e0d88"
}
],
"title": "tty: n_gsm: require CAP_NET_ADMIN to attach N_GSM0710 ldisc",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2023-52880",
"datePublished": "2024-05-24T15:33:17.439Z",
"dateReserved": "2024-05-21T15:35:00.781Z",
"dateUpdated": "2026-08-05T09:11:49.513Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
}
}
OESA-2024-1707 (CVE-2021-47247)
Vulnerability from osv_openeuler – Published: 2024-06-14 11:07 – Updated: 2026-08-06 11:07 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Fix use-after-free of encap entry in neigh update handler
Function mlx5e_rep_neigh_update() wasn't updated to accommodate rtnl lock removal from TC filter update path and properly handle concurrent encap entry insertion/deletion which can lead to following use-after-free:
[23827.464923] ================================================================== [23827.469446] BUG: KASAN: use-after-free in mlx5e_encap_take+0x72/0x140 [mlx5_core] [23827.470971] Read of size 4 at addr ffff8881d132228c by task kworker/u20:6/21635 [23827.472251] [23827.472615] CPU: 9 PID: 21635 Comm: kworker/u20:6 Not tainted 5.13.0-rc3+ #5 [23827.473788] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 [23827.475639] Workqueue: mlx5e mlx5e_rep_neigh_update [mlx5_core] [23827.476731] Call Trace: [23827.477260] dump_stack+0xbb/0x107 [23827.477906] print_address_description.constprop.0+0x18/0x140 [23827.478896] ? mlx5e_encap_take+0x72/0x140 [mlx5_core] [23827.479879] ? mlx5e_encap_take+0x72/0x140 [mlx5_core] [23827.480905] kasan_report.cold+0x7c/0xd8 [23827.481701] ? mlx5e_encap_take+0x72/0x140 [mlx5_core] [23827.482744] kasan_check_range+0x145/0x1a0 [23827.493112] mlx5e_encap_take+0x72/0x140 [mlx5_core] [23827.494054] ? mlx5e_tc_tun_encap_info_equal_generic+0x140/0x140 [mlx5_core] [23827.495296] mlx5e_rep_neigh_update+0x41e/0x5e0 [mlx5_core] [23827.496338] ? mlx5e_rep_neigh_entry_release+0xb80/0xb80 [mlx5_core] [23827.497486] ? read_word_at_a_time+0xe/0x20 [23827.498250] ? strscpy+0xa0/0x2a0 [23827.498889] process_one_work+0x8ac/0x14e0 [23827.499638] ? lockdep_hardirqs_on_prepare+0x400/0x400 [23827.500537] ? pwq_dec_nr_in_flight+0x2c0/0x2c0 [23827.501359] ? rwlock_bug.part.0+0x90/0x90 [23827.502116] worker_thread+0x53b/0x1220 [23827.502831] ? process_one_work+0x14e0/0x14e0 [23827.503627] kthread+0x328/0x3f0 [23827.504254] ? _raw_spin_unlock_irq+0x24/0x40 [23827.505065] ? __kthread_bind_mask+0x90/0x90 [23827.505912] ret_from_fork+0x1f/0x30 [23827.506621] [23827.506987] Allocated by task 28248: [23827.507694] kasan_save_stack+0x1b/0x40 [23827.508476] __kasan_kmalloc+0x7c/0x90 [23827.509197] mlx5e_attach_encap+0xde1/0x1d40 [mlx5_core] [23827.510194] mlx5e_tc_add_fdb_flow+0x397/0xc40 [mlx5_core] [23827.511218] __mlx5e_add_fdb_flow+0x519/0xb30 [mlx5_core] [23827.512234] mlx5e_configure_flower+0x191c/0x4870 [mlx5_core] [23827.513298] tc_setup_cb_add+0x1d5/0x420 [23827.514023] fl_hw_replace_filter+0x382/0x6a0 [cls_flower] [23827.514975] fl_change+0x2ceb/0x4a51 [cls_flower] [23827.515821] tc_new_tfilter+0x89a/0x2070 [23827.516548] rtnetlink_rcv_msg+0x644/0x8c0 [23827.517300] netlink_rcv_skb+0x11d/0x340 [23827.518021] netlink_unicast+0x42b/0x700 [23827.518742] netlink_sendmsg+0x743/0xc20 [23827.519467] sock_sendmsg+0xb2/0xe0 [23827.520131] _syssendmsg+0x590/0x770 [23827.520851] _sys_sendmsg+0xd8/0x160 [23827.521552] __sys_sendmsg+0xb7/0x140 [23827.522238] do_syscall_64+0x3a/0x70 [23827.522907] entry_SYSCALL_64_after_hwframe+0x44/0xae [23827.523797] [23827.524163] Freed by task 25948: [23827.524780] kasan_save_stack+0x1b/0x40 [23827.525488] kasan_set_track+0x1c/0x30 [23827.526187] kasan_set_free_info+0x20/0x30 [23827.526968] __kasan_slab_free+0xed/0x130 [23827.527709] slab_free_freelist_hook+0xcf/0x1d0 [23827.528528] kmem_cache_free_bulk+0x33a/0x6e0 [23827.529317] kfree_rcu_work+0x55f/0xb70 [23827.530024] process_one_work+0x8ac/0x14e0 [23827.530770] worker_thread+0x53b/0x1220 [23827.531480] kthread+0x328/0x3f0 [23827.532114] ret_from_fork+0x1f/0x30 [23827.532785] [23827.533147] Last potentially related work creation: [23827.534007] kasan_save_stack+0x1b/0x40 [23827.534710] kasan_record_aux_stack+0xab/0xc0 [23827.535492] kvfree_call_rcu+0x31/0x7b0 [23827.536206] mlx5e_tc_del ---truncated---(CVE-2021-47247)
In the Linux kernel, the following vulnerability has been resolved:
octeontx2-af: Fix possible null pointer dereference.
This patch fixes possible null pointer dereference in files "rvu_debugfs.c" and "rvu_nix.c"(CVE-2021-47484)
In the Linux kernel, the following vulnerability has been resolved:
net: stmmac: Disable Tx queues when reconfiguring the interface
The Tx queues were not disabled in situations where the driver needed to stop the interface to apply a new configuration. This could result in a kernel panic when doing any of the 3 following actions: * reconfiguring the number of queues (ethtool -L) * reconfiguring the size of the ring buffers (ethtool -G) * installing/removing an XDP program (ip l set dev ethX xdp)
Prevent the panic by making sure netif_tx_disable is called when stopping an interface.
Without this patch, the following kernel panic can be observed when doing any of the actions above:
Unable to handle kernel paging request at virtual address ffff80001238d040 [....] Call trace: dwmac4_set_addr+0x8/0x10 dev_hard_start_xmit+0xe4/0x1ac sch_direct_xmit+0xe8/0x39c __dev_queue_xmit+0x3ec/0xaf0 dev_queue_xmit+0x14/0x20 [...] [ end trace 0000000000000002 ]---(CVE-2021-47558)
In the Linux kernel, the following vulnerability has been resolved:
ice: Fix crash by keep old cfg when update TCs more than queues
There are problems if allocated queues less than Traffic Classes.
Commit a632b2a4c920 ("ice: ethtool: Prohibit improper channel config for DCB") already disallow setting less queues than TCs.
Another case is if we first set less queues, and later update more TCs config due to LLDP, ice_vsi_cfg_tc() will failed but left dirty num_txq/rxq and tc_cfg in vsi, that will cause invalid pointer access.
[ 95.968089] ice 0000:3b:00.1: More TCs defined than queues/rings allocated. [ 95.968092] ice 0000:3b:00.1: Trying to use more Rx queues (8), than were allocated (1)! [ 95.968093] ice 0000:3b:00.1: Failed to config TC for VSI index: 0 [ 95.969621] general protection fault: 0000 [#1] SMP NOPTI [ 95.969705] CPU: 1 PID: 58405 Comm: lldpad Kdump: loaded Tainted: G U W O --------- -t - 4.18.0 #1 [ 95.969867] Hardware name: O.E.M/BC11SPSCB10, BIOS 8.23 12/30/2021 [ 95.969992] RIP: 0010:devm_kmalloc+0xa/0x60 [ 95.970052] Code: 5c ff ff ff 31 c0 5b 5d 41 5c c3 b8 f4 ff ff ff eb f4 0f 1f 40 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 89 d1 <8b> 97 60 02 00 00 48 8d 7e 18 48 39 f7 72 3f 55 89 ce 53 48 8b 4c [ 95.970344] RSP: 0018:ffffc9003f553888 EFLAGS: 00010206 [ 95.970425] RAX: dead000000000200 RBX: ffffea003c425b00 RCX: 00000000006080c0 [ 95.970536] RDX: 00000000006080c0 RSI: 0000000000000200 RDI: dead000000000200 [ 95.970648] RBP: dead000000000200 R08: 00000000000463c0 R09: ffff888ffa900000 [ 95.970760] R10: 0000000000000000 R11: 0000000000000002 R12: ffff888ff6b40100 [ 95.970870] R13: ffff888ff6a55018 R14: 0000000000000000 R15: ffff888ff6a55460 [ 95.970981] FS: 00007f51b7d24700(0000) GS:ffff88903ee80000(0000) knlGS:0000000000000000 [ 95.971108] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 95.971197] CR2: 00007fac5410d710 CR3: 0000000f2c1de002 CR4: 00000000007606e0 [ 95.971309] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 95.971419] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 95.971530] PKRU: 55555554 [ 95.971573] Call Trace: [ 95.971622] ice_setup_rx_ring+0x39/0x110 [ice] [ 95.971695] ice_vsi_setup_rx_rings+0x54/0x90 [ice] [ 95.971774] ice_vsi_open+0x25/0x120 [ice] [ 95.971843] ice_open_internal+0xb8/0x1f0 [ice] [ 95.971919] ice_ena_vsi+0x4f/0xd0 [ice] [ 95.971987] ice_dcb_ena_dis_vsi.constprop.5+0x29/0x90 [ice] [ 95.972082] ice_pf_dcb_cfg+0x29a/0x380 [ice] [ 95.972154] ice_dcbnl_setets+0x174/0x1b0 [ice] [ 95.972220] dcbnl_ieee_set+0x89/0x230 [ 95.972279] ? dcbnl_ieee_del+0x150/0x150 [ 95.972341] dcb_doit+0x124/0x1b0 [ 95.972392] rtnetlink_rcv_msg+0x243/0x2f0 [ 95.972457] ? dcb_doit+0x14d/0x1b0 [ 95.972510] ? __kmalloc_node_track_caller+0x1d3/0x280 [ 95.972591] ? rtnl_calcit.isra.31+0x100/0x100 [ 95.972661] netlink_rcv_skb+0xcf/0xf0 [ 95.972720] netlink_unicast+0x16d/0x220 [ 95.972781] netlink_sendmsg+0x2ba/0x3a0 [ 95.975891] sock_sendmsg+0x4c/0x50 [ 95.979032] syssendmsg+0x2e4/0x300 [ 95.982147] ? kmem_cache_alloc+0x13e/0x190 [ 95.985242] ? wake_up_common_lock+0x79/0x90 [ 95.988338] ? __check_object_size+0xac/0x1b0 [ 95.991440] ? _copy_to_user+0x22/0x30 [ 95.994539] ? move_addr_to_user+0xbb/0xd0 [ 95.997619] ? __sys_sendmsg+0x53/0x80 [ 96.000664] __sys_sendmsg+0x53/0x80 [ 96.003747] do_syscall_64+0x5b/0x1d0 [ 96.006862] entry_SYSCALL_64_after_hwframe+0x65/0xca
Only update num_txq/rxq when passed check, and restore tc_cfg if setup queue map failed.(CVE-2022-48652)
In the Linux kernel, the following vulnerability has been resolved:
pipe: wakeup wr_wait after setting max_usage
Commit c73be61cede5 ("pipe: Add general notification queue support") a regression was introduced that would lock up resized pipes under certain conditions. See the reproducer in [1].
The commit resizing the pipe ring size was moved to a different function, doing that moved the wakeup for pipe->wr_wait before actually raising pipe->max_usage. If a pipe was full before the resize occured it would result in the wakeup never actually triggering pipe_write.
Set @max_usage and @nr_accounted before waking writers if this isn't a watch queue.
Christian Brauner <brauner@kernel.org>: rewrite to account for watch queues
In the Linux kernel, the following vulnerability has been resolved:
ALSA: scarlett2: Add missing error checks to *_ctl_get()
The ctl_get() functions which call scarlett2_update() were not checking the return value. Fix to check the return value and pass to the caller.(CVE-2023-52680)
In the Linux kernel, the following vulnerability has been resolved:
powerpc/powernv: Add a null pointer check in opal_event_init()
kasprintf() returns a pointer to dynamically allocated memory which can be NULL upon failure.(CVE-2023-52686)
In the Linux kernel, the following vulnerability has been resolved:
ACPI: video: check for error while searching for backlight device parent
If acpi_get_parent() called in acpi_video_dev_register_backlight() fails, for example, because acpi_ut_acquire_mutex() fails inside acpi_get_parent), this can lead to incorrect (uninitialized) acpi_parent handle being passed to acpi_get_pci_dev() for detecting the parent pci device.
Check acpi_get_parent() result and set parent device only in case of success.
Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2023-52693)
In the Linux kernel, the following vulnerability has been resolved:
ceph: blocklist the kclient when receiving corrupted snap trace
When received corrupted snap trace we don't know what exactly has happened in MDS side. And we shouldn't continue IOs and metadatas access to MDS, which may corrupt or get incorrect contents.
This patch will just block all the further IO/MDS requests immediately and then evict the kclient itself.
The reason why we still need to evict the kclient just after blocking all the further IOs is that the MDS could revoke the caps faster.(CVE-2023-52732)
In the Linux kernel, the following vulnerability has been resolved:
virtio-blk: fix implicit overflow on virtio_max_dma_size
The following codes have an implicit conversion from size_t to u32: (u32)max_size = (size_t)virtio_max_dma_size(vdev);
This may lead overflow, Ex (size_t)4G -> (u32)0. Once virtio_max_dma_size() has a larger size than U32_MAX, use U32_MAX instead.(CVE-2023-52762)
In the Linux kernel, the following vulnerability has been resolved:
net/smc: avoid data corruption caused by decline
We found a data corruption issue during testing of SMC-R on Redis applications.
The benchmark has a low probability of reporting a strange error as shown below.
"Error: Protocol error, got "\xe2" as reply type byte"
Finally, we found that the retrieved error data was as follows:
0xE2 0xD4 0xC3 0xD9 0x04 0x00 0x2C 0x20 0xA6 0x56 0x00 0x16 0x3E 0x0C 0xCB 0x04 0x02 0x01 0x00 0x00 0x20 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xE2
It is quite obvious that this is a SMC DECLINE message, which means that the applications received SMC protocol message. We found that this was caused by the following situations:
client server ¦ clc proposal -------------> ¦ clc accept <------------- ¦ clc confirm -------------> wait llc confirm send llc confirm ¦failed llc confirm ¦ x------ (after 2s)timeout wait llc confirm rsp
wait decline
(after 1s) timeout (after 2s) timeout ¦ decline --------------> ¦ decline <--------------
As a result, a decline message was sent in the implementation, and this message was read from TCP by the already-fallback connection.
This patch double the client timeout as 2x of the server value, With this simple change, the Decline messages should never cross or collide (during Confirm link timeout).
This issue requires an immediate solution, since the protocol updates involve a more long-term solution.(CVE-2023-52775)
In the Linux kernel, the following vulnerability has been resolved:
SUNRPC: Fix RPC client cleaned up the freed pipefs dentries
RPC client pipefs dentries cleanup is in separated rpc_remove_pipedir() workqueue,which takes care about pipefs superblock locking. In some special scenarios, when kernel frees the pipefs sb of the current client and immediately alloctes a new pipefs sb, rpc_remove_pipedir function would misjudge the existence of pipefs sb which is not the one it used to hold. As a result, the rpc_remove_pipedir would clean the released freed pipefs dentries.
To fix this issue, rpc_remove_pipedir should check whether the current pipefs sb is consistent with the original pipefs sb.
This error can be catched by KASAN:
[ 250.497700] BUG: KASAN: slab-use-after-free in dget_parent+0x195/0x200 [ 250.498315] Read of size 4 at addr ffff88800a2ab804 by task kworker/0:18/106503 [ 250.500549] Workqueue: events rpc_free_client_work [ 250.501001] Call Trace: [ 250.502880] kasan_report+0xb6/0xf0 [ 250.503209] ? dget_parent+0x195/0x200 [ 250.503561] dget_parent+0x195/0x200 [ 250.503897] ? __pfx_rpc_clntdir_depopulate+0x10/0x10 [ 250.504384] rpc_rmdir_depopulate+0x1b/0x90 [ 250.504781] rpc_remove_client_dir+0xf5/0x150 [ 250.505195] rpc_free_client_work+0xe4/0x230 [ 250.505598] process_one_work+0x8ee/0x13b0 ... [ 22.039056] Allocated by task 244: [ 22.039390] kasan_save_stack+0x22/0x50 [ 22.039758] kasan_set_track+0x25/0x30 [ 22.040109] __kasan_slab_alloc+0x59/0x70 [ 22.040487] kmem_cache_alloc_lru+0xf0/0x240 [ 22.040889] __d_alloc+0x31/0x8e0 [ 22.041207] d_alloc+0x44/0x1f0 [ 22.041514] __rpc_lookup_create_exclusive+0x11c/0x140 [ 22.041987] rpc_mkdir_populate.constprop.0+0x5f/0x110 [ 22.042459] rpc_create_client_dir+0x34/0x150 [ 22.042874] rpc_setup_pipedir_sb+0x102/0x1c0 [ 22.043284] rpc_client_register+0x136/0x4e0 [ 22.043689] rpc_new_client+0x911/0x1020 [ 22.044057] rpc_create_xprt+0xcb/0x370 [ 22.044417] rpc_create+0x36b/0x6c0 ... [ 22.049524] Freed by task 0: [ 22.049803] kasan_save_stack+0x22/0x50 [ 22.050165] kasan_set_track+0x25/0x30 [ 22.050520] kasan_save_free_info+0x2b/0x50 [ 22.050921] __kasan_slab_free+0x10e/0x1a0 [ 22.051306] kmem_cache_free+0xa5/0x390 [ 22.051667] rcu_core+0x62c/0x1930 [ 22.051995] __do_softirq+0x165/0x52a [ 22.052347] [ 22.052503] Last potentially related work creation: [ 22.052952] kasan_save_stack+0x22/0x50 [ 22.053313] __kasan_record_aux_stack+0x8e/0xa0 [ 22.053739] __call_rcu_common.constprop.0+0x6b/0x8b0 [ 22.054209] dentry_free+0xb2/0x140 [ 22.054540] __dentry_kill+0x3be/0x540 [ 22.054900] shrink_dentry_list+0x199/0x510 [ 22.055293] shrink_dcache_parent+0x190/0x240 [ 22.055703] do_one_tree+0x11/0x40 [ 22.056028] shrink_dcache_for_umount+0x61/0x140 [ 22.056461] generic_shutdown_super+0x70/0x590 [ 22.056879] kill_anon_super+0x3a/0x60 [ 22.057234] rpc_kill_sb+0x121/0x200(CVE-2023-52803)
In the Linux kernel, the following vulnerability has been resolved:
fs/jfs: Add check for negative db_l2nbperpage
l2nbperpage is log2(number of blks per page), and the minimum legal value should be 0, not negative.
In the case of l2nbperpage being negative, an error will occur when subsequently used as shift exponent.
Syzbot reported this bug:
UBSAN: shift-out-of-bounds in fs/jfs/jfs_dmap.c:799:12 shift exponent -16777216 is negative(CVE-2023-52810)
In the Linux kernel, the following vulnerability has been resolved:
tty: n_gsm: require CAP_NET_ADMIN to attach N_GSM0710 ldisc
Any unprivileged user can attach N_GSM0710 ldisc, but it requires CAP_NET_ADMIN to create a GSM network anyway.
Require initial namespace CAP_NET_ADMIN to do that.(CVE-2023-52880)
In the Linux kernel, the following vulnerability has been resolved:
tcp: do not accept ACK of bytes we never sent
This patch is based on a detailed report and ideas from Yepeng Pan and Christian Rossow.
ACK seq validation is currently following RFC 5961 5.2 guidelines:
The ACK value is considered acceptable only if it is in the range of ((SND.UNA - MAX.SND.WND) <= SEG.ACK <= SND.NXT). All incoming segments whose ACK value doesn't satisfy the above condition MUST be discarded and an ACK sent back. It needs to be noted that RFC 793 on page 72 (fifth check) says: "If the ACK is a duplicate (SEG.ACK < SND.UNA), it can be ignored. If the ACK acknowledges something not yet sent (SEG.ACK > SND.NXT) then send an ACK, drop the segment, and return". The "ignored" above implies that the processing of the incoming data segment continues, which means the ACK value is treated as acceptable. This mitigation makes the ACK check more stringent since any ACK < SND.UNA wouldn't be accepted, instead only ACKs that are in the range ((SND.UNA - MAX.SND.WND) <= SEG.ACK <= SND.NXT) get through.
This can be refined for new (and possibly spoofed) flows, by not accepting ACK for bytes that were never sent.
This greatly improves TCP security at a little cost.
I added a Fixes: tag to make sure this patch will reach stable trees, even if the 'blamed' patch was adhering to the RFC.
tp->bytes_acked was added in linux-4.2
Following packetdrill test (courtesy of Yepeng Pan) shows the issue at hand:
0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3 +0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 +0 bind(3, ..., ...) = 0 +0 listen(3, 1024) = 0
// ---------------- Handshake ------------------- //
// when window scale is set to 14 the window size can be extended to // 65535 * (2^14) = 1073725440. Linux would accept an ACK packet // with ack number in (Server_ISN+1-1073725440. Server_ISN+1) // ,though this ack number acknowledges some data never // sent by the server.
+0 < S 0:0(0) win 65535 <mss 1400,nop,wscale 14> +0 > S. 0:0(0) ack 1 <...> +0 < . 1:1(0) ack 1 win 65535 +0 accept(3, ..., ...) = 4
// For the established connection, we send an ACK packet, // the ack packet uses ack number 1 - 1073725300 + 2^32, // where 2^32 is used to wrap around. // Note: we used 1073725300 instead of 1073725440 to avoid possible // edge cases. // 1 - 1073725300 + 2^32 = 3221241997
// Oops, old kernels happily accept this packet. +0 < . 1:1001(1000) ack 3221241997 win 65535
// After the kernel fix the following will be replaced by a challenge ACK, // and prior malicious frame would be dropped. +0 > . 1:1(0) ack 1001(CVE-2023-52881)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: set dormant flag on hook register failure
We need to set the dormant flag again if we fail to register the hooks.
During memory pressure hook registration can fail and we end up with a table marked as active but no registered hooks.
On table/base chain deletion, nf_tables will attempt to unregister the hook again which yields a warn splat from the nftables core.(CVE-2024-26835)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_core: Fix possible buffer overflow
struct hci_dev_info has a fixed size name[8] field so in the event that hdev->name is bigger than that strcpy would attempt to write past its size, so this fixes this problem by switching to use strscpy.(CVE-2024-26889)
In the Linux kernel, the following vulnerability has been resolved:
xen-netfront: Add missing skb_mark_for_recycle
Notice that skb_mark_for_recycle() is introduced later than fixes tag in commit 6a5bcd84e886 ("page_pool: Allow drivers to hint on SKB recycling").
It is believed that fixes tag were missing a call to page_pool_release_page() between v5.9 to v5.14, after which is should have used skb_mark_for_recycle(). Since v6.6 the call page_pool_release_page() were removed (in commit 535b9c61bdef ("net: page_pool: hide page_pool_release_page()") and remaining callers converted (in commit 6bfef2ec0172 ("Merge branch 'net-page_pool-remove-page_pool_release_page'")).
This leak became visible in v6.8 via commit dba1b8a7ab68 ("mm/page_pool: catch page_pool memory leaks").(CVE-2024-27393)
In the Linux kernel, the following vulnerability has been resolved:
phonet/pep: fix racy skb_queue_empty() use
The receive queues are protected by their respective spin-lock, not the socket lock. This could lead to skb_peek() unexpectedly returning NULL or a pointer to an already dequeued socket buffer.(CVE-2024-27402)
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: dw-edma: eDMA: Add sync read before starting the DMA transfer in remote setup
The Linked list element and pointer are not stored in the same memory as the eDMA controller register. If the doorbell register is toggled before the full write of the linked list a race condition error will occur. In remote setup we can only use a readl to the memory to assure the full write has occurred.(CVE-2024-27408)
In the Linux kernel, the following vulnerability has been resolved:
usb: typec: altmodes/displayport: create sysfs nodes as driver's default device attribute group
The DisplayPort driver's sysfs nodes may be present to the userspace before typec_altmode_set_drvdata() completes in dp_altmode_probe. This means that a sysfs read can trigger a NULL pointer error by deferencing dp->hpd in hpd_show or dp->lock in pin_assignment_show, as dev_get_drvdata() returns NULL in those cases.
Remove manual sysfs node creation in favor of adding attribute group as default for devices bound to the driver. The ATTRIBUTE_GROUPS() macro is not used here otherwise the path to the sysfs nodes is no longer compliant with the ABI.(CVE-2024-35790)
In the Linux kernel, the following vulnerability has been resolved:
PCI/PM: Drain runtime-idle callbacks before driver removal
A race condition between the .runtime_idle() callback and the .remove() callback in the rtsx_pcr PCI driver leads to a kernel crash due to an unhandled page fault [1].
The problem is that rtsx_pci_runtime_idle() is not expected to be running after pm_runtime_get_sync() has been called, but the latter doesn't really guarantee that. It only guarantees that the suspend and resume callbacks will not be running when it returns.
However, if a .runtime_idle() callback is already running when pm_runtime_get_sync() is called, the latter will notice that the runtime PM status of the device is RPM_ACTIVE and it will return right away without waiting for the former to complete. In fact, it cannot wait for .runtime_idle() to complete because it may be called from that callback (it arguably does not make much sense to do that, but it is not strictly prohibited).
Thus in general, whoever is providing a .runtime_idle() callback needs to protect it from running in parallel with whatever code runs after pm_runtime_get_sync(). [Note that .runtime_idle() will not start after pm_runtime_get_sync() has returned, but it may continue running then if it has started earlier.]
One way to address that race condition is to call pm_runtime_barrier() after pm_runtime_get_sync() (not before it, because a nonzero value of the runtime PM usage counter is necessary to prevent runtime PM callbacks from being invoked) to wait for the .runtime_idle() callback to complete should it be running at that point. A suitable place for doing that is in pci_device_remove() which calls pm_runtime_get_sync() before removing the driver, so it may as well call pm_runtime_barrier() subsequently, which will prevent the race in question from occurring, not just in the rtsx_pcr driver, but in any PCI drivers providing .runtime_idle() callbacks.(CVE-2024-35809)
In the Linux kernel, the following vulnerability has been resolved:
wifi: brcmfmac: Fix use-after-free bug in brcmf_cfg80211_detach
This is the candidate patch of CVE-2023-47233 : https://nvd.nist.gov/vuln/detail/CVE-2023-47233
In brcm80211 driver,it starts with the following invoking chain to start init a timeout worker:
->brcmf_usb_probe ->brcmf_usb_probe_cb ->brcmf_attach ->brcmf_bus_started ->brcmf_cfg80211_attach ->wl_init_priv ->brcmf_init_escan ->INIT_WORK(&cfg->escan_timeout_work, brcmf_cfg80211_escan_timeout_worker);
If we disconnect the USB by hotplug, it will call brcmf_usb_disconnect to make cleanup. The invoking chain is :
brcmf_usb_disconnect ->brcmf_usb_disconnect_cb ->brcmf_detach ->brcmf_cfg80211_detach ->kfree(cfg);
While the timeout woker may still be running. This will cause a use-after-free bug on cfg in brcmf_cfg80211_escan_timeout_worker.
Fix it by deleting the timer and canceling the worker in brcmf_cfg80211_detach.
arend.vanspriel@broadcom.com: keep timer delete as is and cancel work just before free
In the Linux kernel, the following vulnerability has been resolved:
mlxsw: spectrum_acl_tcam: Fix memory leak during rehash
The rehash delayed work migrates filters from one region to another. This is done by iterating over all chunks (all the filters with the same priority) in the region and in each chunk iterating over all the filters.
If the migration fails, the code tries to migrate the filters back to the old region. However, the rollback itself can also fail in which case another migration will be erroneously performed. Besides the fact that this ping pong is not a very good idea, it also creates a problem.
Each virtual chunk references two chunks: The currently used one ('vchunk->chunk') and a backup ('vchunk->chunk2'). During migration the first holds the chunk we want to migrate filters to and the second holds the chunk we are migrating filters from.
The code currently assumes - but does not verify - that the backup chunk does not exist (NULL) if the currently used chunk does not reference the target region. This assumption breaks when we are trying to rollback a rollback, resulting in the backup chunk being overwritten and leaked [1].
Fix by not rolling back a failed rollback and add a warning to avoid future cases.
[1] WARNING: CPU: 5 PID: 1063 at lib/parman.c:291 parman_destroy+0x17/0x20 Modules linked in: CPU: 5 PID: 1063 Comm: kworker/5:11 Tainted: G W 6.9.0-rc2-custom-00784-gc6a05c468a0b #14 Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019 Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work RIP: 0010:parman_destroy+0x17/0x20 [...] Call Trace: <TASK> mlxsw_sp_acl_atcam_region_fini+0x19/0x60 mlxsw_sp_acl_tcam_region_destroy+0x49/0xf0 mlxsw_sp_acl_tcam_vregion_rehash_work+0x1f1/0x470 process_one_work+0x151/0x370 worker_thread+0x2cb/0x3e0 kthread+0xd0/0x100 ret_from_fork+0x34/0x50 ret_from_fork_asm+0x1a/0x30 </TASK>(CVE-2024-35853)
In the Linux kernel, the following vulnerability has been resolved:
mlxsw: spectrum_acl_tcam: Fix possible use-after-free during rehash
The rehash delayed work migrates filters from one region to another according to the number of available credits.
The migrated from region is destroyed at the end of the work if the number of credits is non-negative as the assumption is that this is indicative of migration being complete. This assumption is incorrect as a non-negative number of credits can also be the result of a failed migration.
The destruction of a region that still has filters referencing it can result in a use-after-free [1].
Fix by not destroying the region if migration failed.
[1] BUG: KASAN: slab-use-after-free in mlxsw_sp_acl_ctcam_region_entry_remove+0x21d/0x230 Read of size 8 at addr ffff8881735319e8 by task kworker/0:31/3858
CPU: 0 PID: 3858 Comm: kworker/0:31 Tainted: G W 6.9.0-rc2-custom-00782-gf2275c2157d8 #5 Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019 Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work Call Trace: <TASK> dump_stack_lvl+0xc6/0x120 print_report+0xce/0x670 kasan_report+0xd7/0x110 mlxsw_sp_acl_ctcam_region_entry_remove+0x21d/0x230 mlxsw_sp_acl_ctcam_entry_del+0x2e/0x70 mlxsw_sp_acl_atcam_entry_del+0x81/0x210 mlxsw_sp_acl_tcam_vchunk_migrate_all+0x3cd/0xb50 mlxsw_sp_acl_tcam_vregion_rehash_work+0x157/0x1300 process_one_work+0x8eb/0x19b0 worker_thread+0x6c9/0xf70 kthread+0x2c9/0x3b0 ret_from_fork+0x4d/0x80 ret_from_fork_asm+0x1a/0x30 </TASK>
Allocated by task 174: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0 __kmalloc+0x19c/0x360 mlxsw_sp_acl_tcam_region_create+0xdf/0x9c0 mlxsw_sp_acl_tcam_vregion_rehash_work+0x954/0x1300 process_one_work+0x8eb/0x19b0 worker_thread+0x6c9/0xf70 kthread+0x2c9/0x3b0 ret_from_fork+0x4d/0x80 ret_from_fork_asm+0x1a/0x30
Freed by task 7: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 poison_slab_object+0x102/0x170 __kasan_slab_free+0x14/0x30 kfree+0xc1/0x290 mlxsw_sp_acl_tcam_region_destroy+0x272/0x310 mlxsw_sp_acl_tcam_vregion_rehash_work+0x731/0x1300 process_one_work+0x8eb/0x19b0 worker_thread+0x6c9/0xf70 kthread+0x2c9/0x3b0 ret_from_fork+0x4d/0x80 ret_from_fork_asm+0x1a/0x30(CVE-2024-35854)
In the Linux kernel, the following vulnerability has been resolved:
riscv: process: Fix kernel gp leakage
childregs represents the registers which are active for the new thread in user context. For a kernel thread, childregs->gp is never used since the kernel gp is not touched by switch_to. For a user mode helper, the gp value can be observed in user space after execve or possibly by other means.
[From the email thread]
The / Kernel thread / comment is somewhat inaccurate in that it is also used for user_mode_helper threads, which exec a user process, e.g. /sbin/init or when /proc/sys/kernel/core_pattern is a pipe. Such threads do not have PF_KTHREAD set and are valid targets for ptrace etc. even before they exec.
childregs is the user context during syscall execution and it is observable from userspace in at least five ways:
- kernel_execve does not currently clear integer registers, so the starting register state for PID 1 and other user processes started by the kernel has sp = user stack, gp = kernel __global_pointer$, all other integer registers zeroed by the memset in the patch comment.
This is a bug in its own right, but I'm unwilling to bet that it is the only way to exploit the issue addressed by this patch.
-
ptrace(PTRACE_GETREGSET): you can PTRACE_ATTACH to a user_mode_helper thread before it execs, but ptrace requires SIGSTOP to be delivered which can only happen at user/kernel boundaries.
-
/proc//task//syscall: this is perfectly happy to read pt_regs for user_mode_helpers before the exec completes, but gp is not one of the registers it returns.
-
PERF_SAMPLE_REGS_USER: LOCKDOWN_PERF normally prevents access to kernel addresses via PERF_SAMPLE_REGS_INTR, but due to this bug kernel addresses are also exposed via PERF_SAMPLE_REGS_USER which is permitted under LOCKDOWN_PERF. I have not attempted to write exploit code.
-
Much of the tracing infrastructure allows access to user registers. I have not attempted to determine which forms of tracing allow access to user registers without already allowing access to kernel registers.(CVE-2024-35871)
In the Linux kernel, the following vulnerability has been resolved:
erspan: make sure erspan_base_hdr is present in skb->head
syzbot reported a problem in ip6erspan_rcv() [1]
Issue is that ip6erspan_rcv() (and erspan_rcv()) no longer make sure erspan_base_hdr is present in skb linear part (skb->head) before getting @ver field from it.
Add the missing pskb_may_pull() calls.
v2: Reload iph pointer in erspan_rcv() after pskb_may_pull() because skb->head might have changed.
[1]
BUG: KMSAN: uninit-value in pskb_may_pull_reason include/linux/skbuff.h:2742 [inline] BUG: KMSAN: uninit-value in pskb_may_pull include/linux/skbuff.h:2756 [inline] BUG: KMSAN: uninit-value in ip6erspan_rcv net/ipv6/ip6_gre.c:541 [inline] BUG: KMSAN: uninit-value in gre_rcv+0x11f8/0x1930 net/ipv6/ip6_gre.c:610 pskb_may_pull_reason include/linux/skbuff.h:2742 [inline] pskb_may_pull include/linux/skbuff.h:2756 [inline] ip6erspan_rcv net/ipv6/ip6_gre.c:541 [inline] gre_rcv+0x11f8/0x1930 net/ipv6/ip6_gre.c:610 ip6_protocol_deliver_rcu+0x1d4c/0x2ca0 net/ipv6/ip6_input.c:438 ip6_input_finish net/ipv6/ip6_input.c:483 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] ip6_input+0x15d/0x430 net/ipv6/ip6_input.c:492 ip6_mc_input+0xa7e/0xc80 net/ipv6/ip6_input.c:586 dst_input include/net/dst.h:460 [inline] ip6_rcv_finish+0x955/0x970 net/ipv6/ip6_input.c:79 NF_HOOK include/linux/netfilter.h:314 [inline] ipv6_rcv+0xde/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core net/core/dev.c:5538 [inline] __netif_receive_skb+0x1da/0xa00 net/core/dev.c:5652 netif_receive_skb_internal net/core/dev.c:5738 [inline] netif_receive_skb+0x58/0x660 net/core/dev.c:5798 tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1549 tun_get_user+0x5566/0x69e0 drivers/net/tun.c:2002 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048 call_write_iter include/linux/fs.h:2108 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0xb63/0x1520 fs/read_write.c:590 ksys_write+0x20f/0x4c0 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __x64_sys_write+0x93/0xe0 fs/read_write.c:652 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75
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:1318 [inline] alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6504 sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2795 tun_alloc_skb drivers/net/tun.c:1525 [inline] tun_get_user+0x209a/0x69e0 drivers/net/tun.c:1846 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048 call_write_iter include/linux/fs.h:2108 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0xb63/0x1520 fs/read_write.c:590 ksys_write+0x20f/0x4c0 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __x64_sys_write+0x93/0xe0 fs/read_write.c:652 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75
CPU: 1 PID: 5045 Comm: syz-executor114 Not tainted 6.9.0-rc1-syzkaller-00021-g962490525cff #0(CVE-2024-35888)
In the Linux kernel, the following vulnerability has been resolved:
bpf, sockmap: Prevent lock inversion deadlock in map delete elem
syzkaller started using corpuses where a BPF tracing program deletes elements from a sockmap/sockhash map. Because BPF tracing programs can be invoked from any interrupt context, locks taken during a map_delete_elem operation must be hardirq-safe. Otherwise a deadlock due to lock inversion is possible, as reported by lockdep:
CPU0 CPU1
---- ----
lock(&htab->buckets[i].lock); local_irq_disable(); lock(&host->lock); lock(&htab->buckets[i].lock); <Interrupt> lock(&host->lock);
Locks in sockmap are hardirq-unsafe by design. We expects elements to be deleted from sockmap/sockhash only in task (normal) context with interrupts enabled, or in softirq context.
Detect when map_delete_elem operation is invoked from a context which is not hardirq-unsafe, that is interrupts are disabled, and bail out with an error.
Note that map updates are not affected by this issue. BPF verifier does not allow updating sockmap/sockhash from a BPF tracing program today.(CVE-2024-35895)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: validate user input for expected length
I got multiple syzbot reports showing old bugs exposed by BPF after commit 20f2505fb436 ("bpf: Try to avoid kzalloc in cgroup/{s,g}etsockopt")
setsockopt() @optlen argument should be taken into account before copying data.
BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline] BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline] BUG: KASAN: slab-out-of-bounds in do_replace net/ipv4/netfilter/ip_tables.c:1111 [inline] BUG: KASAN: slab-out-of-bounds in do_ipt_set_ctl+0x902/0x3dd0 net/ipv4/netfilter/ip_tables.c:1627 Read of size 96 at addr ffff88802cd73da0 by task syz-executor.4/7238
CPU: 1 PID: 7238 Comm: syz-executor.4 Not tainted 6.9.0-rc2-next-20240403-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 kasan_check_range+0x282/0x290 mm/kasan/generic.c:189 __asan_memcpy+0x29/0x70 mm/kasan/shadow.c:105 copy_from_sockptr_offset include/linux/sockptr.h:49 [inline] copy_from_sockptr include/linux/sockptr.h:55 [inline] do_replace net/ipv4/netfilter/ip_tables.c:1111 [inline] do_ipt_set_ctl+0x902/0x3dd0 net/ipv4/netfilter/ip_tables.c:1627 nf_setsockopt+0x295/0x2c0 net/netfilter/nf_sockopt.c:101 do_sock_setsockopt+0x3af/0x720 net/socket.c:2311 __sys_setsockopt+0x1ae/0x250 net/socket.c:2334 __do_sys_setsockopt net/socket.c:2343 [inline] __se_sys_setsockopt net/socket.c:2340 [inline] __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340 do_syscall_64+0xfb/0x240 entry_SYSCALL_64_after_hwframe+0x72/0x7a RIP: 0033:0x7fd22067dde9 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fd21f9ff0c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000036 RAX: ffffffffffffffda RBX: 00007fd2207abf80 RCX: 00007fd22067dde9 RDX: 0000000000000040 RSI: 0000000000000000 RDI: 0000000000000003 RBP: 00007fd2206ca47a R08: 0000000000000001 R09: 0000000000000000 R10: 0000000020000880 R11: 0000000000000246 R12: 0000000000000000 R13: 000000000000000b R14: 00007fd2207abf80 R15: 00007ffd2d0170d8 </TASK>
Allocated by task 7238: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:370 [inline] __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:387 kasan_kmalloc include/linux/kasan.h:211 [inline] __do_kmalloc_node mm/slub.c:4069 [inline] __kmalloc_noprof+0x200/0x410 mm/slub.c:4082 kmalloc_noprof include/linux/slab.h:664 [inline] __cgroup_bpf_run_filter_setsockopt+0xd47/0x1050 kernel/bpf/cgroup.c:1869 do_sock_setsockopt+0x6b4/0x720 net/socket.c:2293 __sys_setsockopt+0x1ae/0x250 net/socket.c:2334 __do_sys_setsockopt net/socket.c:2343 [inline] __se_sys_setsockopt net/socket.c:2340 [inline] __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340 do_syscall_64+0xfb/0x240 entry_SYSCALL_64_after_hwframe+0x72/0x7a
The buggy address belongs to the object at ffff88802cd73da0 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes inside of allocated 1-byte region [ffff88802cd73da0, ffff88802cd73da1)
The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff88802cd73020 pfn:0x2cd73 flags: 0xfff80000000000(node=0|zone=1|lastcpupid=0xfff) page_type: 0xffffefff(slab) raw: 00fff80000000000 ffff888015041280 dead000000000100 dead000000000122 raw: ffff88802cd73020 000000008080007f 00000001ffffefff 00 ---truncated---(CVE-2024-35896)
In the Linux kernel, the following vulnerability has been resolved:
bpf: Protect against int overflow for stack access size
This patch re-introduces protection against the size of access to stack memory being negative; the access size can appear negative as a result of overflowing its signed int representation. This should not actually happen, as there are other protections along the way, but we should protect against it anyway. One code path was missing such protections (fixed in the previous patch in the series), causing out-of-bounds array accesses in check_stack_range_initialized(). This patch causes the verification of a program with such a non-sensical access size to fail.
This check used to exist in a more indirect way, but was inadvertendly removed in a833a17aeac7.(CVE-2024-35905)
In the Linux kernel, the following vulnerability has been resolved:
usb: typec: ucsi: Limit read size on v1.2
Between UCSI 1.2 and UCSI 2.0, the size of the MESSAGE_IN region was increased from 16 to 256. In order to avoid overflowing reads for older systems, add a mechanism to use the read UCSI version to truncate read sizes on UCSI v1.2.(CVE-2024-35924)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: SCO: Fix not validating setsockopt user input
syzbot reported sco_sock_setsockopt() is copying data without checking user input length.
BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline] BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline] BUG: KASAN: slab-out-of-bounds in sco_sock_setsockopt+0xc0b/0xf90 net/bluetooth/sco.c:893 Read of size 4 at addr ffff88805f7b15a3 by task syz-executor.5/12578(CVE-2024-35967)
In the Linux kernel, the following vulnerability has been resolved:
geneve: fix header validation in geneve[6]_xmit_skb
syzbot is able to trigger an uninit-value in geneve_xmit() [1]
Problem : While most ip tunnel helpers (like ip_tunnel_get_dsfield()) uses skb_protocol(skb, true), pskb_inet_may_pull() is only using skb->protocol.
If anything else than ETH_P_IPV6 or ETH_P_IP is found in skb->protocol, pskb_inet_may_pull() does nothing at all.
If a vlan tag was provided by the caller (af_packet in the syzbot case), the network header might not point to the correct location, and skb linear part could be smaller than expected.
Add skb_vlan_inet_prepare() to perform a complete mac validation.
Use this in geneve for the moment, I suspect we need to adopt this more broadly.
v4 - Jakub reported v3 broke l2_tos_ttl_inherit.sh selftest - Only call __vlan_get_protocol() for vlan types.
v2,v3 - Addressed Sabrina comments on v1 and v2
[1]
BUG: KMSAN: uninit-value in geneve_xmit_skb drivers/net/geneve.c:910 [inline] BUG: KMSAN: uninit-value in geneve_xmit+0x302d/0x5420 drivers/net/geneve.c:1030 geneve_xmit_skb drivers/net/geneve.c:910 [inline] geneve_xmit+0x302d/0x5420 drivers/net/geneve.c:1030 __netdev_start_xmit include/linux/netdevice.h:4903 [inline] netdev_start_xmit include/linux/netdevice.h:4917 [inline] xmit_one net/core/dev.c:3531 [inline] dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3547 __dev_queue_xmit+0x348d/0x52c0 net/core/dev.c:4335 dev_queue_xmit include/linux/netdevice.h:3091 [inline] packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3081 [inline] packet_sendmsg+0x8bb0/0x9ef0 net/packet/af_packet.c:3113 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:745 __sys_sendto+0x685/0x830 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1d0 net/socket.c:2199 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75
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:1318 [inline] alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6504 sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2795 packet_alloc_skb net/packet/af_packet.c:2930 [inline] packet_snd net/packet/af_packet.c:3024 [inline] packet_sendmsg+0x722d/0x9ef0 net/packet/af_packet.c:3113 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:745 __sys_sendto+0x685/0x830 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1d0 net/socket.c:2199 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75
CPU: 0 PID: 5033 Comm: syz-executor346 Not tainted 6.9.0-rc1-syzkaller-00005-g928a87efa423 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024(CVE-2024-35973)
In the Linux kernel, the following vulnerability has been resolved:
batman-adv: Avoid infinite loop trying to resize local TT
If the MTU of one of an attached interface becomes too small to transmit the local translation table then it must be resized to fit inside all fragments (when enabled) or a single packet.
But if the MTU becomes too low to transmit even the header + the VLAN specific part then the resizing of the local TT will never succeed. This can for example happen when the usable space is 110 bytes and 11 VLANs are on top of batman-adv. In this case, at least 116 byte would be needed. There will just be an endless spam of
batman_adv: batadv0: Forced to purge local tt entries to fit new maximum fragment MTU (110)
in the log but the function will never finish. Problem here is that the timeout will be halved all the time and will then stagnate at 0 and therefore never be able to reduce the table even more.
There are other scenarios possible with a similar result. The number of BATADV_TT_CLIENT_NOPURGE entries in the local TT can for example be too high to fit inside a packet. Such a scenario can therefore happen also with only a single VLAN + 7 non-purgable addresses - requiring at least 120 bytes.
While this should be handled proactively when:
- interface with too low MTU is added
- VLAN is added
- non-purgeable local mac is added
- MTU of an attached interface is reduced
- fragmentation setting gets disabled (which most likely requires dropping attached interfaces)
not all of these scenarios can be prevented because batman-adv is only consuming events without the the possibility to prevent these actions (non-purgable MAC address added, MTU of an attached interface is reduced). It is therefore necessary to also make sure that the code is able to handle also the situations when there were already incompatible system configuration are present.(CVE-2024-35982)
In the Linux kernel, the following vulnerability has been resolved:
i2c: smbus: fix NULL function pointer dereference
Baruch reported an OOPS when using the designware controller as target only. Target-only modes break the assumption of one transfer function always being available. Fix this by always checking the pointer in __i2c_transfer.
wsa: dropped the simplification in core-smbus to avoid theoretical regressions
In the Linux kernel, the following vulnerability has been resolved:
rtnetlink: Correct nested IFLA_VF_VLAN_LIST attribute validation
Each attribute inside a nested IFLA_VF_VLAN_LIST is assumed to be a struct ifla_vf_vlan_info so the size of such attribute needs to be at least of sizeof(struct ifla_vf_vlan_info) which is 14 bytes. The current size validation in do_setvfinfo is against NLA_HDRLEN (4 bytes) which is less than sizeof(struct ifla_vf_vlan_info) so this validation is not enough and a too small attribute might be cast to a struct ifla_vf_vlan_info, this might result in an out of bands read access when accessing the saved (casted) entry in ivvl.(CVE-2024-36017)
In the Linux kernel, the following vulnerability has been resolved:
mmc: sdhci-msm: pervent access to suspended controller
Generic sdhci code registers LED device and uses host->runtime_suspended flag to protect access to it. The sdhci-msm driver doesn't set this flag, which causes a crash when LED is accessed while controller is runtime suspended. Fix this by setting the flag correctly.(CVE-2024-36029)
In the Linux kernel, the following vulnerability has been resolved:
net: fix out-of-bounds access in ops_init
net_alloc_generic is called by net_alloc, which is called without any locking. It reads max_gen_ptrs, which is changed under pernet_ops_rwsem. It is read twice, first to allocate an array, then to set s.len, which is later used to limit the bounds of the array access.
It is possible that the array is allocated and another thread is registering a new pernet ops, increments max_gen_ptrs, which is then used to set s.len with a larger than allocated length for the variable array.
Fix it by reading max_gen_ptrs only once in net_alloc_generic. If max_gen_ptrs is later incremented, it will be caught in net_assign_generic.(CVE-2024-36883)
In the Linux kernel, the following vulnerability has been resolved:
tipc: fix UAF in error path
Sam Page (sam4k) working with Trend Micro Zero Day Initiative reported a UAF in the tipc_buf_append() error path:
BUG: KASAN: slab-use-after-free in kfree_skb_list_reason+0x47e/0x4c0 linux/net/core/skbuff.c:1183 Read of size 8 at addr ffff88804d2a7c80 by task poc/8034
CPU: 1 PID: 8034 Comm: poc Not tainted 6.8.2 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-debian-1.16.0-5 04/01/2014 Call Trace: <IRQ> __dump_stack linux/lib/dump_stack.c:88 dump_stack_lvl+0xd9/0x1b0 linux/lib/dump_stack.c:106 print_address_description linux/mm/kasan/report.c:377 print_report+0xc4/0x620 linux/mm/kasan/report.c:488 kasan_report+0xda/0x110 linux/mm/kasan/report.c:601 kfree_skb_list_reason+0x47e/0x4c0 linux/net/core/skbuff.c:1183 skb_release_data+0x5af/0x880 linux/net/core/skbuff.c:1026 skb_release_all linux/net/core/skbuff.c:1094 __kfree_skb linux/net/core/skbuff.c:1108 kfree_skb_reason+0x12d/0x210 linux/net/core/skbuff.c:1144 kfree_skb linux/./include/linux/skbuff.h:1244 tipc_buf_append+0x425/0xb50 linux/net/tipc/msg.c:186 tipc_link_input+0x224/0x7c0 linux/net/tipc/link.c:1324 tipc_link_rcv+0x76e/0x2d70 linux/net/tipc/link.c:1824 tipc_rcv+0x45f/0x10f0 linux/net/tipc/node.c:2159 tipc_udp_recv+0x73b/0x8f0 linux/net/tipc/udp_media.c:390 udp_queue_rcv_one_skb+0xad2/0x1850 linux/net/ipv4/udp.c:2108 udp_queue_rcv_skb+0x131/0xb00 linux/net/ipv4/udp.c:2186 udp_unicast_rcv_skb+0x165/0x3b0 linux/net/ipv4/udp.c:2346 __udp4_lib_rcv+0x2594/0x3400 linux/net/ipv4/udp.c:2422 ip_protocol_deliver_rcu+0x30c/0x4e0 linux/net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x2e4/0x520 linux/net/ipv4/ip_input.c:233 NF_HOOK linux/./include/linux/netfilter.h:314 NF_HOOK linux/./include/linux/netfilter.h:308 ip_local_deliver+0x18e/0x1f0 linux/net/ipv4/ip_input.c:254 dst_input linux/./include/net/dst.h:461 ip_rcv_finish linux/net/ipv4/ip_input.c:449 NF_HOOK linux/./include/linux/netfilter.h:314 NF_HOOK linux/./include/linux/netfilter.h:308 ip_rcv+0x2c5/0x5d0 linux/net/ipv4/ip_input.c:569 __netif_receive_skb_one_core+0x199/0x1e0 linux/net/core/dev.c:5534 __netif_receive_skb+0x1f/0x1c0 linux/net/core/dev.c:5648 process_backlog+0x101/0x6b0 linux/net/core/dev.c:5976 __napi_poll.constprop.0+0xba/0x550 linux/net/core/dev.c:6576 napi_poll linux/net/core/dev.c:6645 net_rx_action+0x95a/0xe90 linux/net/core/dev.c:6781 __do_softirq+0x21f/0x8e7 linux/kernel/softirq.c:553 do_softirq linux/kernel/softirq.c:454 do_softirq+0xb2/0xf0 linux/kernel/softirq.c:441 </IRQ> <TASK> __local_bh_enable_ip+0x100/0x120 linux/kernel/softirq.c:381 local_bh_enable linux/./include/linux/bottom_half.h:33 rcu_read_unlock_bh linux/./include/linux/rcupdate.h:851 __dev_queue_xmit+0x871/0x3ee0 linux/net/core/dev.c:4378 dev_queue_xmit linux/./include/linux/netdevice.h:3169 neigh_hh_output linux/./include/net/neighbour.h:526 neigh_output linux/./include/net/neighbour.h:540 ip_finish_output2+0x169f/0x2550 linux/net/ipv4/ip_output.c:235 __ip_finish_output linux/net/ipv4/ip_output.c:313 __ip_finish_output+0x49e/0x950 linux/net/ipv4/ip_output.c:295 ip_finish_output+0x31/0x310 linux/net/ipv4/ip_output.c:323 NF_HOOK_COND linux/./include/linux/netfilter.h:303 ip_output+0x13b/0x2a0 linux/net/ipv4/ip_output.c:433 dst_output linux/./include/net/dst.h:451 ip_local_out linux/net/ipv4/ip_output.c:129 ip_send_skb+0x3e5/0x560 linux/net/ipv4/ip_output.c:1492 udp_send_skb+0x73f/0x1530 linux/net/ipv4/udp.c:963 udp_sendmsg+0x1a36/0x2b40 linux/net/ipv4/udp.c:1250 inet_sendmsg+0x105/0x140 linux/net/ipv4/af_inet.c:850 sock_sendmsg_nosec linux/net/socket.c:730 __sock_sendmsg linux/net/socket.c:745 __sys_sendto+0x42c/0x4e0 linux/net/socket.c:2191 __do_sys_sendto linux/net/socket.c:2203 __se_sys_sendto linux/net/socket.c:2199 __x64_sys_sendto+0xe0/0x1c0 linux/net/socket.c:2199 do_syscall_x64 linux/arch/x86/entry/common.c:52 do_syscall_ ---truncated---(CVE-2024-36886)
In the Linux kernel, the following vulnerability has been resolved:
mptcp: ensure snd_nxt is properly initialized on connect
Christoph reported a splat hinting at a corrupted snd_una:
WARNING: CPU: 1 PID: 38 at net/mptcp/protocol.c:1005 __mptcp_clean_una+0x4b3/0x620 net/mptcp/protocol.c:1005 Modules linked in: CPU: 1 PID: 38 Comm: kworker/1:1 Not tainted 6.9.0-rc1-gbbeac67456c9 #59 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014 Workqueue: events mptcp_worker RIP: 0010:__mptcp_clean_una+0x4b3/0x620 net/mptcp/protocol.c:1005 Code: be 06 01 00 00 bf 06 01 00 00 e8 a8 12 e7 fe e9 00 fe ff ff e8 8e 1a e7 fe 0f b7 ab 3e 02 00 00 e9 d3 fd ff ff e8 7d 1a e7 fe <0f> 0b 4c 8b bb e0 05 00 00 e9 74 fc ff ff e8 6a 1a e7 fe 0f 0b e9 RSP: 0018:ffffc9000013fd48 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff8881029bd280 RCX: ffffffff82382fe4 RDX: ffff8881003cbd00 RSI: ffffffff823833c3 RDI: 0000000000000001 RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: fefefefefefefeff R12: ffff888138ba8000 R13: 0000000000000106 R14: ffff8881029bd908 R15: ffff888126560000 FS: 0000000000000000(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f604a5dae38 CR3: 0000000101dac002 CR4: 0000000000170ef0 Call Trace: <TASK> __mptcp_clean_una_wakeup net/mptcp/protocol.c:1055 [inline] mptcp_clean_una_wakeup net/mptcp/protocol.c:1062 [inline] __mptcp_retrans+0x7f/0x7e0 net/mptcp/protocol.c:2615 mptcp_worker+0x434/0x740 net/mptcp/protocol.c:2767 process_one_work+0x1e0/0x560 kernel/workqueue.c:3254 process_scheduled_works kernel/workqueue.c:3335 [inline] worker_thread+0x3c7/0x640 kernel/workqueue.c:3416 kthread+0x121/0x170 kernel/kthread.c:388 ret_from_fork+0x44/0x50 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:243 </TASK>
When fallback to TCP happens early on a client socket, snd_nxt is not yet initialized and any incoming ack will copy such value into snd_una. If the mptcp worker (dumbly) tries mptcp-level re-injection after such ack, that would unconditionally trigger a send buffer cleanup using 'bad' snd_una values.
We could easily disable re-injection for fallback sockets, but such dumb behavior already helped catching a few subtle issues and a very low to zero impact in practice.
Instead address the issue always initializing snd_nxt (and write_seq, for consistency) at connect time.(CVE-2024-36889)
In the Linux kernel, the following vulnerability has been resolved:
gpiolib: cdev: fix uninitialised kfifo
If a line is requested with debounce, and that results in debouncing in software, and the line is subsequently reconfigured to enable edge detection then the allocation of the kfifo to contain edge events is overlooked. This results in events being written to and read from an uninitialised kfifo. Read events are returned to userspace.
Initialise the kfifo in the case where the software debounce is already active.(CVE-2024-36898)
In the Linux kernel, the following vulnerability has been resolved:
gpiolib: cdev: Fix use after free in lineinfo_changed_notify
The use-after-free issue occurs as follows: when the GPIO chip device file is being closed by invoking gpio_chrdev_release(), watched_lines is freed by bitmap_free(), but the unregistration of lineinfo_changed_nb notifier chain failed due to waiting write rwsem. Additionally, one of the GPIO chip's lines is also in the release process and holds the notifier chain's read rwsem. Consequently, a race condition leads to the use-after-free of watched_lines.
Here is the typical stack when issue happened:
[free] gpio_chrdev_release() --> bitmap_free(cdev->watched_lines) <-- freed --> blocking_notifier_chain_unregister() --> down_write(&nh->rwsem) <-- waiting rwsem --> __down_write_common() --> rwsem_down_write_slowpath() --> schedule_preempt_disabled() --> schedule()
[use] st54spi_gpio_dev_release() --> gpio_free() --> gpiod_free() --> gpiod_free_commit() --> gpiod_line_state_notify() --> blocking_notifier_call_chain() --> down_read(&nh->rwsem); <-- held rwsem --> notifier_call_chain() --> lineinfo_changed_notify() --> test_bit(xxxx, cdev->watched_lines) <-- use after free
The side effect of the use-after-free issue is that a GPIO line event is being generated for userspace where it shouldn't. However, since the chrdev is being closed, userspace won't have the chance to read that event anyway.
To fix the issue, call the bitmap_free() function after the unregistration of lineinfo_changed_nb notifier chain.(CVE-2024-36899)
In the Linux kernel, the following vulnerability has been resolved:
ipv6: prevent NULL dereference in ip6_output()
According to syzbot, there is a chance that ip6_dst_idev() returns NULL in ip6_output(). Most places in IPv6 stack deal with a NULL idev just fine, but not here.
syzbot reported:
general protection fault, probably for non-canonical address 0xdffffc00000000bc: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x00000000000005e0-0x00000000000005e7] CPU: 0 PID: 9775 Comm: syz-executor.4 Not tainted 6.9.0-rc5-syzkaller-00157-g6a30653b604a #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 RIP: 0010:ip6_output+0x231/0x3f0 net/ipv6/ip6_output.c:237 Code: 3c 1e 00 49 89 df 74 08 4c 89 ef e8 19 58 db f7 48 8b 44 24 20 49 89 45 00 49 89 c5 48 8d 9d e0 05 00 00 48 89 d8 48 c1 e8 03 <42> 0f b6 04 38 84 c0 4c 8b 74 24 28 0f 85 61 01 00 00 8b 1b 31 ff RSP: 0018:ffffc9000927f0d8 EFLAGS: 00010202 RAX: 00000000000000bc RBX: 00000000000005e0 RCX: 0000000000040000 RDX: ffffc900131f9000 RSI: 0000000000004f47 RDI: 0000000000004f48 RBP: 0000000000000000 R08: ffffffff8a1f0b9a R09: 1ffffffff1f51fad R10: dffffc0000000000 R11: fffffbfff1f51fae R12: ffff8880293ec8c0 R13: ffff88805d7fc000 R14: 1ffff1100527d91a R15: dffffc0000000000 FS: 00007f135c6856c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000080 CR3: 0000000064096000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> NF_HOOK include/linux/netfilter.h:314 [inline] ip6_xmit+0xefe/0x17f0 net/ipv6/ip6_output.c:358 sctp_v6_xmit+0x9f2/0x13f0 net/sctp/ipv6.c:248 sctp_packet_transmit+0x26ad/0x2ca0 net/sctp/output.c:653 sctp_packet_singleton+0x22c/0x320 net/sctp/outqueue.c:783 sctp_outq_flush_ctrl net/sctp/outqueue.c:914 [inline] sctp_outq_flush+0x6d5/0x3e20 net/sctp/outqueue.c:1212 sctp_side_effects net/sctp/sm_sideeffect.c:1198 [inline] sctp_do_sm+0x59cc/0x60c0 net/sctp/sm_sideeffect.c:1169 sctp_primitive_ASSOCIATE+0x95/0xc0 net/sctp/primitive.c:73 __sctp_connect+0x9cd/0xe30 net/sctp/socket.c:1234 sctp_connect net/sctp/socket.c:4819 [inline] sctp_inet_connect+0x149/0x1f0 net/sctp/socket.c:4834 __sys_connect_file net/socket.c:2048 [inline] __sys_connect+0x2df/0x310 net/socket.c:2065 __do_sys_connect net/socket.c:2075 [inline] __se_sys_connect net/socket.c:2072 [inline] __x64_sys_connect+0x7a/0x90 net/socket.c:2072 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2024-36901)
In the Linux kernel, the following vulnerability has been resolved:
ipv6: fib6_rules: avoid possible NULL dereference in fib6_rule_action()
syzbot is able to trigger the following crash [1], caused by unsafe ip6_dst_idev() use.
Indeed ip6_dst_idev() can return NULL, and must always be checked.
[1]
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 0 PID: 31648 Comm: syz-executor.0 Not tainted 6.9.0-rc4-next-20240417-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 RIP: 0010:__fib6_rule_action net/ipv6/fib6_rules.c:237 [inline] RIP: 0010:fib6_rule_action+0x241/0x7b0 net/ipv6/fib6_rules.c:267 Code: 02 00 00 49 8d 9f d8 00 00 00 48 89 d8 48 c1 e8 03 42 80 3c 20 00 74 08 48 89 df e8 f9 32 bf f7 48 8b 1b 48 89 d8 48 c1 e8 03 <42> 80 3c 20 00 74 08 48 89 df e8 e0 32 bf f7 4c 8b 03 48 89 ef 4c RSP: 0018:ffffc9000fc1f2f0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 1a772f98c8186700 RDX: 0000000000000003 RSI: ffffffff8bcac4e0 RDI: ffffffff8c1f9760 RBP: ffff8880673fb980 R08: ffffffff8fac15ef R09: 1ffffffff1f582bd R10: dffffc0000000000 R11: fffffbfff1f582be R12: dffffc0000000000 R13: 0000000000000080 R14: ffff888076509000 R15: ffff88807a029a00 FS: 00007f55e82ca6c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b31d23000 CR3: 0000000022b66000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> fib_rules_lookup+0x62c/0xdb0 net/core/fib_rules.c:317 fib6_rule_lookup+0x1fd/0x790 net/ipv6/fib6_rules.c:108 ip6_route_output_flags_noref net/ipv6/route.c:2637 [inline] ip6_route_output_flags+0x38e/0x610 net/ipv6/route.c:2649 ip6_route_output include/net/ip6_route.h:93 [inline] ip6_dst_lookup_tail+0x189/0x11a0 net/ipv6/ip6_output.c:1120 ip6_dst_lookup_flow+0xb9/0x180 net/ipv6/ip6_output.c:1250 sctp_v6_get_dst+0x792/0x1e20 net/sctp/ipv6.c:326 sctp_transport_route+0x12c/0x2e0 net/sctp/transport.c:455 sctp_assoc_add_peer+0x614/0x15c0 net/sctp/associola.c:662 sctp_connect_new_asoc+0x31d/0x6c0 net/sctp/socket.c:1099 __sctp_connect+0x66d/0xe30 net/sctp/socket.c:1197 sctp_connect net/sctp/socket.c:4819 [inline] sctp_inet_connect+0x149/0x1f0 net/sctp/socket.c:4834 __sys_connect_file net/socket.c:2048 [inline] __sys_connect+0x2df/0x310 net/socket.c:2065 __do_sys_connect net/socket.c:2075 [inline] __se_sys_connect net/socket.c:2072 [inline] __x64_sys_connect+0x7a/0x90 net/socket.c:2072 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2024-36902)
In the Linux kernel, the following vulnerability has been resolved:
ipv6: Fix potential uninit-value access in __ip6_make_skb()
As it was done in commit fc1092f51567 ("ipv4: Fix uninit-value access in __ip_make_skb()") for IPv4, check FLOWI_FLAG_KNOWN_NH on fl6->flowi6_flags instead of testing HDRINCL on the socket to avoid a race condition which causes uninit-value access.(CVE-2024-36903)
In the Linux kernel, the following vulnerability has been resolved:
ARM: 9381/1: kasan: clear stale stack poison
We found below OOB crash:
[ 33.452494] ================================================================== [ 33.453513] BUG: KASAN: stack-out-of-bounds in refresh_cpu_vm_stats.constprop.0+0xcc/0x2ec [ 33.454660] Write of size 164 at addr c1d03d30 by task swapper/0/0 [ 33.455515] [ 33.455767] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G O 6.1.25-mainline #1 [ 33.456880] Hardware name: Generic DT based system [ 33.457555] unwind_backtrace from show_stack+0x18/0x1c [ 33.458326] show_stack from dump_stack_lvl+0x40/0x4c [ 33.459072] dump_stack_lvl from print_report+0x158/0x4a4 [ 33.459863] print_report from kasan_report+0x9c/0x148 [ 33.460616] kasan_report from kasan_check_range+0x94/0x1a0 [ 33.461424] kasan_check_range from memset+0x20/0x3c [ 33.462157] memset from refresh_cpu_vm_stats.constprop.0+0xcc/0x2ec [ 33.463064] refresh_cpu_vm_stats.constprop.0 from tick_nohz_idle_stop_tick+0x180/0x53c [ 33.464181] tick_nohz_idle_stop_tick from do_idle+0x264/0x354 [ 33.465029] do_idle from cpu_startup_entry+0x20/0x24 [ 33.465769] cpu_startup_entry from rest_init+0xf0/0xf4 [ 33.466528] rest_init from arch_post_acpi_subsys_init+0x0/0x18 [ 33.467397] [ 33.467644] The buggy address belongs to stack of task swapper/0/0 [ 33.468493] and is located at offset 112 in frame: [ 33.469172] refresh_cpu_vm_stats.constprop.0+0x0/0x2ec [ 33.469917] [ 33.470165] This frame has 2 objects: [ 33.470696] [32, 76) 'global_zone_diff' [ 33.470729] [112, 276) 'global_node_diff' [ 33.471294] [ 33.472095] The buggy address belongs to the physical page: [ 33.472862] page:3cd72da8 refcount:1 mapcount:0 mapping:00000000 index:0x0 pfn:0x41d03 [ 33.473944] flags: 0x1000(reserved|zone=0) [ 33.474565] raw: 00001000 ed741470 ed741470 00000000 00000000 00000000 ffffffff 00000001 [ 33.475656] raw: 00000000 [ 33.476050] page dumped because: kasan: bad access detected [ 33.476816] [ 33.477061] Memory state around the buggy address: [ 33.477732] c1d03c00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 33.478630] c1d03c80: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00 00 00 [ 33.479526] >c1d03d00: 00 04 f2 f2 f2 f2 00 00 00 00 00 00 f1 f1 f1 f1 [ 33.480415] ^ [ 33.481195] c1d03d80: 00 00 00 00 00 00 00 00 00 00 04 f3 f3 f3 f3 f3 [ 33.482088] c1d03e00: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 [ 33.482978] ==================================================================
We find the root cause of this OOB is that arm does not clear stale stack poison in the case of cpuidle.
This patch refer to arch/arm64/kernel/sleep.S to resolve this issue.
From cited commit [1] that explain the problem
Functions which the compiler has instrumented for KASAN place poison on the stack shadow upon entry and remove this poison prior to returning.
In the case of cpuidle, CPUs exit the kernel a number of levels deep in C code. Any instrumented functions on this critical path will leave portions of the stack shadow poisoned.
If CPUs lose context and return to the kernel via a cold path, we restore a prior context saved in __cpu_suspend_enter are forgotten, and we never remove the poison they placed in the stack shadow area by functions calls between this and the actual exit of the kernel.
Thus, (depending on stackframe layout) subsequent calls to instrumented functions may hit this stale poison, resulting in (spurious) KASAN splats to the console.
To avoid this, clear any stale poison from the idle thread for a CPU prior to bringing a CPU online.
From cited commit [2]
Extend to check for CONFIG_KASAN_STACK
[1] commit 0d97e6d8024c ("arm64: kasan: clear stale stack poison") [2] commit d56a9ef84bd0 ("kasan, arm64: unpoison stack only with CONFIG_KASAN_STACK")(CVE-2024-36906)
In the Linux kernel, the following vulnerability has been resolved:
blk-iocost: do not WARN if iocg was already offlined
In iocg_pay_debt(), warn is triggered if 'active_list' is empty, which is intended to confirm iocg is active when it has debt. However, warn can be triggered during a blkcg or disk removal, if iocg_waitq_timer_fn() is run at that time:
WARNING: CPU: 0 PID: 2344971 at block/blk-iocost.c:1402 iocg_pay_debt+0x14c/0x190 Call trace: iocg_pay_debt+0x14c/0x190 iocg_kick_waitq+0x438/0x4c0 iocg_waitq_timer_fn+0xd8/0x130 __run_hrtimer+0x144/0x45c __hrtimer_run_queues+0x16c/0x244 hrtimer_interrupt+0x2cc/0x7b0
The warn in this situation is meaningless. Since this iocg is being removed, the state of the 'active_list' is irrelevant, and 'waitq_timer' is canceled after removing 'active_list' in ioc_pd_free(), which ensures iocg is freed after iocg_waitq_timer_fn() returns.
Therefore, add the check if iocg was already offlined to avoid warn when removing a blkcg or disk.(CVE-2024-36908)
In the Linux kernel, the following vulnerability has been resolved:
block: fix overflow in blk_ioctl_discard()
There is no check for overflow of 'start + len' in blk_ioctl_discard(). Hung task occurs if submit an discard ioctl with the following param: start = 0x80000000000ff000, len = 0x8000000000fff000; Add the overflow validation now.(CVE-2024-36917)
In the Linux kernel, the following vulnerability has been resolved:
scsi: lpfc: Release hbalock before calling lpfc_worker_wake_up()
lpfc_worker_wake_up() calls the lpfc_work_done() routine, which takes the hbalock. Thus, lpfc_worker_wake_up() should not be called while holding the hbalock to avoid potential deadlock.(CVE-2024-36924)
In the Linux kernel, the following vulnerability has been resolved:
s390/qeth: Fix kernel panic after setting hsuid
Symptom: When the hsuid attribute is set for the first time on an IQD Layer3 device while the corresponding network interface is already UP, the kernel will try to execute a napi function pointer that is NULL.
Example:
[ 2057.572696] illegal operation: 0001 ilc:1 [#1] SMP [ 2057.572702] Modules linked in: af_iucv qeth_l3 zfcp scsi_transport_fc sunrpc nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nf_tables_set nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables libcrc32c nfnetlink ghash_s390 prng xts aes_s390 des_s390 de s_generic sha3_512_s390 sha3_256_s390 sha512_s390 vfio_ccw vfio_mdev mdev vfio_iommu_type1 eadm_sch vfio ext4 mbcache jbd2 qeth_l2 bridge stp llc dasd_eckd_mod qeth dasd_mod qdio ccwgroup pkey zcrypt [ 2057.572739] CPU: 6 PID: 60182 Comm: stress_client Kdump: loaded Not tainted 4.18.0-541.el8.s390x #1 [ 2057.572742] Hardware name: IBM 3931 A01 704 (LPAR) [ 2057.572744] Krnl PSW : 0704f00180000000 0000000000000002 (0x2) [ 2057.572748] R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:3 PM:0 RI:0 EA:3 [ 2057.572751] Krnl GPRS: 0000000000000004 0000000000000000 00000000a3b008d8 0000000000000000 [ 2057.572754] 00000000a3b008d8 cb923a29c779abc5 0000000000000000 00000000814cfd80 [ 2057.572756] 000000000000012c 0000000000000000 00000000a3b008d8 00000000a3b008d8 [ 2057.572758] 00000000bab6d500 00000000814cfd80 0000000091317e46 00000000814cfc68 [ 2057.572762] Krnl Code:#0000000000000000: 0000 illegal >0000000000000002: 0000 illegal 0000000000000004: 0000 illegal 0000000000000006: 0000 illegal 0000000000000008: 0000 illegal 000000000000000a: 0000 illegal 000000000000000c: 0000 illegal 000000000000000e: 0000 illegal [ 2057.572800] Call Trace: [ 2057.572801] ([<00000000ec639700>] 0xec639700) [ 2057.572803] [<00000000913183e2>] net_rx_action+0x2ba/0x398 [ 2057.572809] [<0000000091515f76>] __do_softirq+0x11e/0x3a0 [ 2057.572813] [<0000000090ce160c>] do_softirq_own_stack+0x3c/0x58 [ 2057.572817] ([<0000000090d2cbd6>] do_softirq.part.1+0x56/0x60) [ 2057.572822] [<0000000090d2cc60>] __local_bh_enable_ip+0x80/0x98 [ 2057.572825] [<0000000091314706>] __dev_queue_xmit+0x2be/0xd70 [ 2057.572827] [<000003ff803dd6d6>] afiucv_hs_send+0x24e/0x300 [af_iucv] [ 2057.572830] [<000003ff803dd88a>] iucv_send_ctrl+0x102/0x138 [af_iucv] [ 2057.572833] [<000003ff803de72a>] iucv_sock_connect+0x37a/0x468 [af_iucv] [ 2057.572835] [<00000000912e7e90>] __sys_connect+0xa0/0xd8 [ 2057.572839] [<00000000912e9580>] sys_socketcall+0x228/0x348 [ 2057.572841] [<0000000091514e1a>] system_call+0x2a6/0x2c8 [ 2057.572843] Last Breaking-Event-Address: [ 2057.572844] [<0000000091317e44>] __napi_poll+0x4c/0x1d8 [ 2057.572846] [ 2057.572847] Kernel panic - not syncing: Fatal exception in interrupt
Analysis: There is one napi structure per out_q: card->qdio.out_qs[i].napi The napi.poll functions are set during qeth_open().
Since commit 1cfef80d4c2b ("s390/qeth: Don't call dev_close/dev_open (DOWN/UP)") qeth_set_offline()/qeth_set_online() no longer call dev_close()/ dev_open(). So if qeth_free_qdio_queues() cleared card->qdio.out_qs[i].napi.poll while the network interface was UP and the card was offline, they are not set again.
Reproduction: chzdev -e $devno layer2=0 ip link set dev $network_interface up echo 0 > /sys/bus/ccw ---truncated---(CVE-2024-36928)
In the Linux kernel, the following vulnerability has been resolved:
net: core: reject skb_copy(_expand) for fraglist GSO skbs
SKB_GSO_FRAGLIST skbs must not be linearized, otherwise they become invalid. Return NULL if such an skb is passed to skb_copy or skb_copy_expand, in order to prevent a crash on a potential later call to skb_gso_segment.(CVE-2024-36929)
In the Linux kernel, the following vulnerability has been resolved:
amd/amdkfd: sync all devices to wait all processes being evicted
If there are more than one device doing reset in parallel, the first device will call kfd_suspend_all_processes() to evict all processes on all devices, this call takes time to finish. other device will start reset and recover without waiting. if the process has not been evicted before doing recover, it will be restored, then caused page fault.(CVE-2024-36949)
In the Linux kernel, the following vulnerability has been resolved:
tipc: fix a possible memleak in tipc_buf_append
__skb_linearize() doesn't free the skb when it fails, so move '*buf = NULL' after __skb_linearize(), so that the skb can be freed on the err path.(CVE-2024-36954)
In the Linux kernel, the following vulnerability has been resolved:
octeontx2-af: avoid off-by-one read from userspace
We try to access count + 1 byte from userspace with memdup_user(buffer, count + 1). However, the userspace only provides buffer of count bytes and only these count bytes are verified to be okay to access. To ensure the copied buffer is NUL terminated, we use memdup_user_nul instead.(CVE-2024-36957)
In the Linux kernel, the following vulnerability has been resolved:
fs/9p: only translate RWX permissions for plain 9P2000
Garbage in plain 9P2000's perm bits is allowed through, which causes it to be able to set (among others) the suid bit. This was presumably not the intent since the unix extended bits are handled explicitly and conditionally on .u.(CVE-2024-36964)
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"perf-debuginfo-5.10.0-207.0.0.116.oe2203sp3.aarch64.rpm",
"kernel-debuginfo-5.10.0-207.0.0.116.oe2203sp3.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-207.0.0.116.oe2203sp3.aarch64.rpm",
"kernel-tools-debuginfo-5.10.0-207.0.0.116.oe2203sp3.aarch64.rpm",
"kernel-tools-5.10.0-207.0.0.116.oe2203sp3.aarch64.rpm",
"kernel-5.10.0-207.0.0.116.oe2203sp3.aarch64.rpm",
"kernel-headers-5.10.0-207.0.0.116.oe2203sp3.aarch64.rpm",
"kernel-devel-5.10.0-207.0.0.116.oe2203sp3.aarch64.rpm",
"python3-perf-5.10.0-207.0.0.116.oe2203sp3.aarch64.rpm",
"perf-5.10.0-207.0.0.116.oe2203sp3.aarch64.rpm",
"kernel-tools-devel-5.10.0-207.0.0.116.oe2203sp3.aarch64.rpm",
"kernel-debugsource-5.10.0-207.0.0.116.oe2203sp3.aarch64.rpm",
"kernel-source-5.10.0-207.0.0.116.oe2203sp3.aarch64.rpm"
],
"src": [
"kernel-5.10.0-207.0.0.116.oe2203sp3.src.rpm"
],
"x86_64": [
"kernel-debuginfo-5.10.0-207.0.0.116.oe2203sp3.x86_64.rpm",
"kernel-tools-5.10.0-207.0.0.116.oe2203sp3.x86_64.rpm",
"python3-perf-5.10.0-207.0.0.116.oe2203sp3.x86_64.rpm",
"kernel-source-5.10.0-207.0.0.116.oe2203sp3.x86_64.rpm",
"kernel-headers-5.10.0-207.0.0.116.oe2203sp3.x86_64.rpm",
"perf-5.10.0-207.0.0.116.oe2203sp3.x86_64.rpm",
"kernel-devel-5.10.0-207.0.0.116.oe2203sp3.x86_64.rpm",
"kernel-tools-devel-5.10.0-207.0.0.116.oe2203sp3.x86_64.rpm",
"kernel-debugsource-5.10.0-207.0.0.116.oe2203sp3.x86_64.rpm",
"kernel-tools-debuginfo-5.10.0-207.0.0.116.oe2203sp3.x86_64.rpm",
"kernel-5.10.0-207.0.0.116.oe2203sp3.x86_64.rpm",
"python3-perf-debuginfo-5.10.0-207.0.0.116.oe2203sp3.x86_64.rpm",
"perf-debuginfo-5.10.0-207.0.0.116.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-207.0.0.116.oe2203sp3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "Medium"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/mlx5e: Fix use-after-free of encap entry in neigh update handler\r\n\r\nFunction mlx5e_rep_neigh_update() wasn\u0026apos;t updated to accommodate rtnl lock\nremoval from TC filter update path and properly handle concurrent encap\nentry insertion/deletion which can lead to following use-after-free:\r\n\r\n [23827.464923] ==================================================================\n [23827.469446] BUG: KASAN: use-after-free in mlx5e_encap_take+0x72/0x140 [mlx5_core]\n [23827.470971] Read of size 4 at addr ffff8881d132228c by task kworker/u20:6/21635\n [23827.472251]\n [23827.472615] CPU: 9 PID: 21635 Comm: kworker/u20:6 Not tainted 5.13.0-rc3+ #5\n [23827.473788] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\n [23827.475639] Workqueue: mlx5e mlx5e_rep_neigh_update [mlx5_core]\n [23827.476731] Call Trace:\n [23827.477260] dump_stack+0xbb/0x107\n [23827.477906] print_address_description.constprop.0+0x18/0x140\n [23827.478896] ? mlx5e_encap_take+0x72/0x140 [mlx5_core]\n [23827.479879] ? mlx5e_encap_take+0x72/0x140 [mlx5_core]\n [23827.480905] kasan_report.cold+0x7c/0xd8\n [23827.481701] ? mlx5e_encap_take+0x72/0x140 [mlx5_core]\n [23827.482744] kasan_check_range+0x145/0x1a0\n [23827.493112] mlx5e_encap_take+0x72/0x140 [mlx5_core]\n [23827.494054] ? mlx5e_tc_tun_encap_info_equal_generic+0x140/0x140 [mlx5_core]\n [23827.495296] mlx5e_rep_neigh_update+0x41e/0x5e0 [mlx5_core]\n [23827.496338] ? mlx5e_rep_neigh_entry_release+0xb80/0xb80 [mlx5_core]\n [23827.497486] ? read_word_at_a_time+0xe/0x20\n [23827.498250] ? strscpy+0xa0/0x2a0\n [23827.498889] process_one_work+0x8ac/0x14e0\n [23827.499638] ? lockdep_hardirqs_on_prepare+0x400/0x400\n [23827.500537] ? pwq_dec_nr_in_flight+0x2c0/0x2c0\n [23827.501359] ? rwlock_bug.part.0+0x90/0x90\n [23827.502116] worker_thread+0x53b/0x1220\n [23827.502831] ? process_one_work+0x14e0/0x14e0\n [23827.503627] kthread+0x328/0x3f0\n [23827.504254] ? _raw_spin_unlock_irq+0x24/0x40\n [23827.505065] ? __kthread_bind_mask+0x90/0x90\n [23827.505912] ret_from_fork+0x1f/0x30\n [23827.506621]\n [23827.506987] Allocated by task 28248:\n [23827.507694] kasan_save_stack+0x1b/0x40\n [23827.508476] __kasan_kmalloc+0x7c/0x90\n [23827.509197] mlx5e_attach_encap+0xde1/0x1d40 [mlx5_core]\n [23827.510194] mlx5e_tc_add_fdb_flow+0x397/0xc40 [mlx5_core]\n [23827.511218] __mlx5e_add_fdb_flow+0x519/0xb30 [mlx5_core]\n [23827.512234] mlx5e_configure_flower+0x191c/0x4870 [mlx5_core]\n [23827.513298] tc_setup_cb_add+0x1d5/0x420\n [23827.514023] fl_hw_replace_filter+0x382/0x6a0 [cls_flower]\n [23827.514975] fl_change+0x2ceb/0x4a51 [cls_flower]\n [23827.515821] tc_new_tfilter+0x89a/0x2070\n [23827.516548] rtnetlink_rcv_msg+0x644/0x8c0\n [23827.517300] netlink_rcv_skb+0x11d/0x340\n [23827.518021] netlink_unicast+0x42b/0x700\n [23827.518742] netlink_sendmsg+0x743/0xc20\n [23827.519467] sock_sendmsg+0xb2/0xe0\n [23827.520131] ____sys_sendmsg+0x590/0x770\n [23827.520851] ___sys_sendmsg+0xd8/0x160\n [23827.521552] __sys_sendmsg+0xb7/0x140\n [23827.522238] do_syscall_64+0x3a/0x70\n [23827.522907] entry_SYSCALL_64_after_hwframe+0x44/0xae\n [23827.523797]\n [23827.524163] Freed by task 25948:\n [23827.524780] kasan_save_stack+0x1b/0x40\n [23827.525488] kasan_set_track+0x1c/0x30\n [23827.526187] kasan_set_free_info+0x20/0x30\n [23827.526968] __kasan_slab_free+0xed/0x130\n [23827.527709] slab_free_freelist_hook+0xcf/0x1d0\n [23827.528528] kmem_cache_free_bulk+0x33a/0x6e0\n [23827.529317] kfree_rcu_work+0x55f/0xb70\n [23827.530024] process_one_work+0x8ac/0x14e0\n [23827.530770] worker_thread+0x53b/0x1220\n [23827.531480] kthread+0x328/0x3f0\n [23827.532114] ret_from_fork+0x1f/0x30\n [23827.532785]\n [23827.533147] Last potentially related work creation:\n [23827.534007] kasan_save_stack+0x1b/0x40\n [23827.534710] kasan_record_aux_stack+0xab/0xc0\n [23827.535492] kvfree_call_rcu+0x31/0x7b0\n [23827.536206] mlx5e_tc_del\n---truncated---(CVE-2021-47247)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nocteontx2-af: Fix possible null pointer dereference.\r\n\r\nThis patch fixes possible null pointer dereference in files\n\u0026quot;rvu_debugfs.c\u0026quot; and \u0026quot;rvu_nix.c\u0026quot;(CVE-2021-47484)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: stmmac: Disable Tx queues when reconfiguring the interface\r\n\r\nThe Tx queues were not disabled in situations where the driver needed to\nstop the interface to apply a new configuration. This could result in a\nkernel panic when doing any of the 3 following actions:\n* reconfiguring the number of queues (ethtool -L)\n* reconfiguring the size of the ring buffers (ethtool -G)\n* installing/removing an XDP program (ip l set dev ethX xdp)\r\n\r\nPrevent the panic by making sure netif_tx_disable is called when stopping\nan interface.\r\n\r\nWithout this patch, the following kernel panic can be observed when doing\nany of the actions above:\r\n\r\nUnable to handle kernel paging request at virtual address ffff80001238d040\n[....]\n Call trace:\n dwmac4_set_addr+0x8/0x10\n dev_hard_start_xmit+0xe4/0x1ac\n sch_direct_xmit+0xe8/0x39c\n __dev_queue_xmit+0x3ec/0xaf0\n dev_queue_xmit+0x14/0x20\n[...]\n[ end trace 0000000000000002 ]---(CVE-2021-47558)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nice: Fix crash by keep old cfg when update TCs more than queues\r\n\r\nThere are problems if allocated queues less than Traffic Classes.\r\n\r\nCommit a632b2a4c920 (\u0026quot;ice: ethtool: Prohibit improper channel config\nfor DCB\u0026quot;) already disallow setting less queues than TCs.\r\n\r\nAnother case is if we first set less queues, and later update more TCs\nconfig due to LLDP, ice_vsi_cfg_tc() will failed but left dirty\nnum_txq/rxq and tc_cfg in vsi, that will cause invalid pointer access.\r\n\r\n[ 95.968089] ice 0000:3b:00.1: More TCs defined than queues/rings allocated.\n[ 95.968092] ice 0000:3b:00.1: Trying to use more Rx queues (8), than were allocated (1)!\n[ 95.968093] ice 0000:3b:00.1: Failed to config TC for VSI index: 0\n[ 95.969621] general protection fault: 0000 [#1] SMP NOPTI\n[ 95.969705] CPU: 1 PID: 58405 Comm: lldpad Kdump: loaded Tainted: G U W O --------- -t - 4.18.0 #1\n[ 95.969867] Hardware name: O.E.M/BC11SPSCB10, BIOS 8.23 12/30/2021\n[ 95.969992] RIP: 0010:devm_kmalloc+0xa/0x60\n[ 95.970052] Code: 5c ff ff ff 31 c0 5b 5d 41 5c c3 b8 f4 ff ff ff eb f4 0f 1f 40 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 89 d1 \u0026lt;8b\u0026gt; 97 60 02 00 00 48 8d 7e 18 48 39 f7 72 3f 55 89 ce 53 48 8b 4c\n[ 95.970344] RSP: 0018:ffffc9003f553888 EFLAGS: 00010206\n[ 95.970425] RAX: dead000000000200 RBX: ffffea003c425b00 RCX: 00000000006080c0\n[ 95.970536] RDX: 00000000006080c0 RSI: 0000000000000200 RDI: dead000000000200\n[ 95.970648] RBP: dead000000000200 R08: 00000000000463c0 R09: ffff888ffa900000\n[ 95.970760] R10: 0000000000000000 R11: 0000000000000002 R12: ffff888ff6b40100\n[ 95.970870] R13: ffff888ff6a55018 R14: 0000000000000000 R15: ffff888ff6a55460\n[ 95.970981] FS: 00007f51b7d24700(0000) GS:ffff88903ee80000(0000) knlGS:0000000000000000\n[ 95.971108] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 95.971197] CR2: 00007fac5410d710 CR3: 0000000f2c1de002 CR4: 00000000007606e0\n[ 95.971309] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[ 95.971419] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[ 95.971530] PKRU: 55555554\n[ 95.971573] Call Trace:\n[ 95.971622] ice_setup_rx_ring+0x39/0x110 [ice]\n[ 95.971695] ice_vsi_setup_rx_rings+0x54/0x90 [ice]\n[ 95.971774] ice_vsi_open+0x25/0x120 [ice]\n[ 95.971843] ice_open_internal+0xb8/0x1f0 [ice]\n[ 95.971919] ice_ena_vsi+0x4f/0xd0 [ice]\n[ 95.971987] ice_dcb_ena_dis_vsi.constprop.5+0x29/0x90 [ice]\n[ 95.972082] ice_pf_dcb_cfg+0x29a/0x380 [ice]\n[ 95.972154] ice_dcbnl_setets+0x174/0x1b0 [ice]\n[ 95.972220] dcbnl_ieee_set+0x89/0x230\n[ 95.972279] ? dcbnl_ieee_del+0x150/0x150\n[ 95.972341] dcb_doit+0x124/0x1b0\n[ 95.972392] rtnetlink_rcv_msg+0x243/0x2f0\n[ 95.972457] ? dcb_doit+0x14d/0x1b0\n[ 95.972510] ? __kmalloc_node_track_caller+0x1d3/0x280\n[ 95.972591] ? rtnl_calcit.isra.31+0x100/0x100\n[ 95.972661] netlink_rcv_skb+0xcf/0xf0\n[ 95.972720] netlink_unicast+0x16d/0x220\n[ 95.972781] netlink_sendmsg+0x2ba/0x3a0\n[ 95.975891] sock_sendmsg+0x4c/0x50\n[ 95.979032] ___sys_sendmsg+0x2e4/0x300\n[ 95.982147] ? kmem_cache_alloc+0x13e/0x190\n[ 95.985242] ? __wake_up_common_lock+0x79/0x90\n[ 95.988338] ? __check_object_size+0xac/0x1b0\n[ 95.991440] ? _copy_to_user+0x22/0x30\n[ 95.994539] ? move_addr_to_user+0xbb/0xd0\n[ 95.997619] ? __sys_sendmsg+0x53/0x80\n[ 96.000664] __sys_sendmsg+0x53/0x80\n[ 96.003747] do_syscall_64+0x5b/0x1d0\n[ 96.006862] entry_SYSCALL_64_after_hwframe+0x65/0xca\r\n\r\nOnly update num_txq/rxq when passed check, and restore tc_cfg if setup\nqueue map failed.(CVE-2022-48652)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npipe: wakeup wr_wait after setting max_usage\r\n\r\nCommit c73be61cede5 (\u0026quot;pipe: Add general notification queue support\u0026quot;) a\nregression was introduced that would lock up resized pipes under certain\nconditions. See the reproducer in [1].\r\n\r\nThe commit resizing the pipe ring size was moved to a different\nfunction, doing that moved the wakeup for pipe-\u0026gt;wr_wait before actually\nraising pipe-\u0026gt;max_usage. If a pipe was full before the resize occured it\nwould result in the wakeup never actually triggering pipe_write.\r\n\r\nSet @max_usage and @nr_accounted before waking writers if this isn\u0026apos;t a\nwatch queue.\r\n\r\n[Christian Brauner \u0026lt;brauner@kernel.org\u0026gt;: rewrite to account for watch queues](CVE-2023-52672)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nALSA: scarlett2: Add missing error checks to *_ctl_get()\r\n\r\nThe *_ctl_get() functions which call scarlett2_update_*() were not\nchecking the return value. Fix to check the return value and pass to\nthe caller.(CVE-2023-52680)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npowerpc/powernv: Add a null pointer check in opal_event_init()\r\n\r\nkasprintf() returns a pointer to dynamically allocated memory\nwhich can be NULL upon failure.(CVE-2023-52686)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nACPI: video: check for error while searching for backlight device parent\r\n\r\nIf acpi_get_parent() called in acpi_video_dev_register_backlight()\nfails, for example, because acpi_ut_acquire_mutex() fails inside\nacpi_get_parent), this can lead to incorrect (uninitialized)\nacpi_parent handle being passed to acpi_get_pci_dev() for detecting\nthe parent pci device.\r\n\r\nCheck acpi_get_parent() result and set parent device only in case of success.\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2023-52693)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nceph: blocklist the kclient when receiving corrupted snap trace\r\n\r\nWhen received corrupted snap trace we don\u0026apos;t know what exactly has\nhappened in MDS side. And we shouldn\u0026apos;t continue IOs and metadatas\naccess to MDS, which may corrupt or get incorrect contents.\r\n\r\nThis patch will just block all the further IO/MDS requests\nimmediately and then evict the kclient itself.\r\n\r\nThe reason why we still need to evict the kclient just after\nblocking all the further IOs is that the MDS could revoke the caps\nfaster.(CVE-2023-52732)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nvirtio-blk: fix implicit overflow on virtio_max_dma_size\r\n\r\nThe following codes have an implicit conversion from size_t to u32:\n(u32)max_size = (size_t)virtio_max_dma_size(vdev);\r\n\r\nThis may lead overflow, Ex (size_t)4G -\u0026gt; (u32)0. Once\nvirtio_max_dma_size() has a larger size than U32_MAX, use U32_MAX\ninstead.(CVE-2023-52762)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/smc: avoid data corruption caused by decline\r\n\r\nWe found a data corruption issue during testing of SMC-R on Redis\napplications.\r\n\r\nThe benchmark has a low probability of reporting a strange error as\nshown below.\r\n\r\n\u0026quot;Error: Protocol error, got \u0026quot;\\xe2\u0026quot; as reply type byte\u0026quot;\r\n\r\nFinally, we found that the retrieved error data was as follows:\r\n\r\n0xE2 0xD4 0xC3 0xD9 0x04 0x00 0x2C 0x20 0xA6 0x56 0x00 0x16 0x3E 0x0C\n0xCB 0x04 0x02 0x01 0x00 0x00 0x20 0x00 0x00 0x00 0x00 0x00 0x00 0x00\n0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xE2\r\n\r\nIt is quite obvious that this is a SMC DECLINE message, which means that\nthe applications received SMC protocol message.\nWe found that this was caused by the following situations:\r\n\r\nclient server\n \u00a6 clc proposal\n -------------\u0026gt;\n \u00a6 clc accept\n \u0026lt;-------------\n \u00a6 clc confirm\n -------------\u0026gt;\nwait llc confirm\n\t\t\tsend llc confirm\n \u00a6failed llc confirm\n \u00a6 x------\n(after 2s)timeout\n wait llc confirm rsp\r\n\r\nwait decline\r\n\r\n(after 1s) timeout\n (after 2s) timeout\n \u00a6 decline\n --------------\u0026gt;\n \u00a6 decline\n \u0026lt;--------------\r\n\r\nAs a result, a decline message was sent in the implementation, and this\nmessage was read from TCP by the already-fallback connection.\r\n\r\nThis patch double the client timeout as 2x of the server value,\nWith this simple change, the Decline messages should never cross or\ncollide (during Confirm link timeout).\r\n\r\nThis issue requires an immediate solution, since the protocol updates\ninvolve a more long-term solution.(CVE-2023-52775)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nSUNRPC: Fix RPC client cleaned up the freed pipefs dentries\r\n\r\nRPC client pipefs dentries cleanup is in separated rpc_remove_pipedir()\nworkqueue,which takes care about pipefs superblock locking.\nIn some special scenarios, when kernel frees the pipefs sb of the\ncurrent client and immediately alloctes a new pipefs sb,\nrpc_remove_pipedir function would misjudge the existence of pipefs\nsb which is not the one it used to hold. As a result,\nthe rpc_remove_pipedir would clean the released freed pipefs dentries.\r\n\r\nTo fix this issue, rpc_remove_pipedir should check whether the\ncurrent pipefs sb is consistent with the original pipefs sb.\r\n\r\nThis error can be catched by KASAN:\n=========================================================\n[ 250.497700] BUG: KASAN: slab-use-after-free in dget_parent+0x195/0x200\n[ 250.498315] Read of size 4 at addr ffff88800a2ab804 by task kworker/0:18/106503\n[ 250.500549] Workqueue: events rpc_free_client_work\n[ 250.501001] Call Trace:\n[ 250.502880] kasan_report+0xb6/0xf0\n[ 250.503209] ? dget_parent+0x195/0x200\n[ 250.503561] dget_parent+0x195/0x200\n[ 250.503897] ? __pfx_rpc_clntdir_depopulate+0x10/0x10\n[ 250.504384] rpc_rmdir_depopulate+0x1b/0x90\n[ 250.504781] rpc_remove_client_dir+0xf5/0x150\n[ 250.505195] rpc_free_client_work+0xe4/0x230\n[ 250.505598] process_one_work+0x8ee/0x13b0\n...\n[ 22.039056] Allocated by task 244:\n[ 22.039390] kasan_save_stack+0x22/0x50\n[ 22.039758] kasan_set_track+0x25/0x30\n[ 22.040109] __kasan_slab_alloc+0x59/0x70\n[ 22.040487] kmem_cache_alloc_lru+0xf0/0x240\n[ 22.040889] __d_alloc+0x31/0x8e0\n[ 22.041207] d_alloc+0x44/0x1f0\n[ 22.041514] __rpc_lookup_create_exclusive+0x11c/0x140\n[ 22.041987] rpc_mkdir_populate.constprop.0+0x5f/0x110\n[ 22.042459] rpc_create_client_dir+0x34/0x150\n[ 22.042874] rpc_setup_pipedir_sb+0x102/0x1c0\n[ 22.043284] rpc_client_register+0x136/0x4e0\n[ 22.043689] rpc_new_client+0x911/0x1020\n[ 22.044057] rpc_create_xprt+0xcb/0x370\n[ 22.044417] rpc_create+0x36b/0x6c0\n...\n[ 22.049524] Freed by task 0:\n[ 22.049803] kasan_save_stack+0x22/0x50\n[ 22.050165] kasan_set_track+0x25/0x30\n[ 22.050520] kasan_save_free_info+0x2b/0x50\n[ 22.050921] __kasan_slab_free+0x10e/0x1a0\n[ 22.051306] kmem_cache_free+0xa5/0x390\n[ 22.051667] rcu_core+0x62c/0x1930\n[ 22.051995] __do_softirq+0x165/0x52a\n[ 22.052347]\n[ 22.052503] Last potentially related work creation:\n[ 22.052952] kasan_save_stack+0x22/0x50\n[ 22.053313] __kasan_record_aux_stack+0x8e/0xa0\n[ 22.053739] __call_rcu_common.constprop.0+0x6b/0x8b0\n[ 22.054209] dentry_free+0xb2/0x140\n[ 22.054540] __dentry_kill+0x3be/0x540\n[ 22.054900] shrink_dentry_list+0x199/0x510\n[ 22.055293] shrink_dcache_parent+0x190/0x240\n[ 22.055703] do_one_tree+0x11/0x40\n[ 22.056028] shrink_dcache_for_umount+0x61/0x140\n[ 22.056461] generic_shutdown_super+0x70/0x590\n[ 22.056879] kill_anon_super+0x3a/0x60\n[ 22.057234] rpc_kill_sb+0x121/0x200(CVE-2023-52803)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfs/jfs: Add check for negative db_l2nbperpage\r\n\r\nl2nbperpage is log2(number of blks per page), and the minimum legal\nvalue should be 0, not negative.\r\n\r\nIn the case of l2nbperpage being negative, an error will occur\nwhen subsequently used as shift exponent.\r\n\r\nSyzbot reported this bug:\r\n\r\nUBSAN: shift-out-of-bounds in fs/jfs/jfs_dmap.c:799:12\nshift exponent -16777216 is negative(CVE-2023-52810)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntty: n_gsm: require CAP_NET_ADMIN to attach N_GSM0710 ldisc\r\n\r\nAny unprivileged user can attach N_GSM0710 ldisc, but it requires\nCAP_NET_ADMIN to create a GSM network anyway.\r\n\r\nRequire initial namespace CAP_NET_ADMIN to do that.(CVE-2023-52880)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntcp: do not accept ACK of bytes we never sent\r\n\r\nThis patch is based on a detailed report and ideas from Yepeng Pan\nand Christian Rossow.\r\n\r\nACK seq validation is currently following RFC 5961 5.2 guidelines:\r\n\r\n The ACK value is considered acceptable only if\n it is in the range of ((SND.UNA - MAX.SND.WND) \u0026lt;= SEG.ACK \u0026lt;=\n SND.NXT). All incoming segments whose ACK value doesn\u0026apos;t satisfy the\n above condition MUST be discarded and an ACK sent back. It needs to\n be noted that RFC 793 on page 72 (fifth check) says: \u0026quot;If the ACK is a\n duplicate (SEG.ACK \u0026lt; SND.UNA), it can be ignored. If the ACK\n acknowledges something not yet sent (SEG.ACK \u0026gt; SND.NXT) then send an\n ACK, drop the segment, and return\u0026quot;. The \u0026quot;ignored\u0026quot; above implies that\n the processing of the incoming data segment continues, which means\n the ACK value is treated as acceptable. This mitigation makes the\n ACK check more stringent since any ACK \u0026lt; SND.UNA wouldn\u0026apos;t be\n accepted, instead only ACKs that are in the range ((SND.UNA -\n MAX.SND.WND) \u0026lt;= SEG.ACK \u0026lt;= SND.NXT) get through.\r\n\r\nThis can be refined for new (and possibly spoofed) flows,\nby not accepting ACK for bytes that were never sent.\r\n\r\nThis greatly improves TCP security at a little cost.\r\n\r\nI added a Fixes: tag to make sure this patch will reach stable trees,\neven if the \u0026apos;blamed\u0026apos; patch was adhering to the RFC.\r\n\r\ntp-\u0026gt;bytes_acked was added in linux-4.2\r\n\r\nFollowing packetdrill test (courtesy of Yepeng Pan) shows\nthe issue at hand:\r\n\r\n0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3\n+0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0\n+0 bind(3, ..., ...) = 0\n+0 listen(3, 1024) = 0\r\n\r\n// ---------------- Handshake ------------------- //\r\n\r\n// when window scale is set to 14 the window size can be extended to\n// 65535 * (2^14) = 1073725440. Linux would accept an ACK packet\n// with ack number in (Server_ISN+1-1073725440. Server_ISN+1)\n// ,though this ack number acknowledges some data never\n// sent by the server.\r\n\r\n+0 \u0026lt; S 0:0(0) win 65535 \u0026lt;mss 1400,nop,wscale 14\u0026gt;\n+0 \u0026gt; S. 0:0(0) ack 1 \u0026lt;...\u0026gt;\n+0 \u0026lt; . 1:1(0) ack 1 win 65535\n+0 accept(3, ..., ...) = 4\r\n\r\n// For the established connection, we send an ACK packet,\n// the ack packet uses ack number 1 - 1073725300 + 2^32,\n// where 2^32 is used to wrap around.\n// Note: we used 1073725300 instead of 1073725440 to avoid possible\n// edge cases.\n// 1 - 1073725300 + 2^32 = 3221241997\r\n\r\n// Oops, old kernels happily accept this packet.\n+0 \u0026lt; . 1:1001(1000) ack 3221241997 win 65535\r\n\r\n// After the kernel fix the following will be replaced by a challenge ACK,\n// and prior malicious frame would be dropped.\n+0 \u0026gt; . 1:1(0) ack 1001(CVE-2023-52881)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nf_tables: set dormant flag on hook register failure\r\n\r\nWe need to set the dormant flag again if we fail to register\nthe hooks.\r\n\r\nDuring memory pressure hook registration can fail and we end up\nwith a table marked as active but no registered hooks.\r\n\r\nOn table/base chain deletion, nf_tables will attempt to unregister\nthe hook again which yields a warn splat from the nftables core.(CVE-2024-26835)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nBluetooth: hci_core: Fix possible buffer overflow\r\n\r\nstruct hci_dev_info has a fixed size name[8] field so in the event that\nhdev-\u0026gt;name is bigger than that strcpy would attempt to write past its\nsize, so this fixes this problem by switching to use strscpy.(CVE-2024-26889)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nxen-netfront: Add missing skb_mark_for_recycle\r\n\r\nNotice that skb_mark_for_recycle() is introduced later than fixes tag in\ncommit 6a5bcd84e886 (\u0026quot;page_pool: Allow drivers to hint on SKB recycling\u0026quot;).\r\n\r\nIt is believed that fixes tag were missing a call to page_pool_release_page()\nbetween v5.9 to v5.14, after which is should have used skb_mark_for_recycle().\nSince v6.6 the call page_pool_release_page() were removed (in\ncommit 535b9c61bdef (\u0026quot;net: page_pool: hide page_pool_release_page()\u0026quot;)\nand remaining callers converted (in commit 6bfef2ec0172 (\u0026quot;Merge branch\n\u0026apos;net-page_pool-remove-page_pool_release_page\u0026apos;\u0026quot;)).\r\n\r\nThis leak became visible in v6.8 via commit dba1b8a7ab68 (\u0026quot;mm/page_pool: catch\npage_pool memory leaks\u0026quot;).(CVE-2024-27393)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nphonet/pep: fix racy skb_queue_empty() use\r\n\r\nThe receive queues are protected by their respective spin-lock, not\nthe socket lock. This could lead to skb_peek() unexpectedly\nreturning NULL or a pointer to an already dequeued socket buffer.(CVE-2024-27402)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndmaengine: dw-edma: eDMA: Add sync read before starting the DMA transfer in remote setup\r\n\r\nThe Linked list element and pointer are not stored in the same memory as\nthe eDMA controller register. If the doorbell register is toggled before\nthe full write of the linked list a race condition error will occur.\nIn remote setup we can only use a readl to the memory to assure the full\nwrite has occurred.(CVE-2024-27408)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: typec: altmodes/displayport: create sysfs nodes as driver\u0026apos;s default device attribute group\r\n\r\nThe DisplayPort driver\u0026apos;s sysfs nodes may be present to the userspace before\ntypec_altmode_set_drvdata() completes in dp_altmode_probe. This means that\na sysfs read can trigger a NULL pointer error by deferencing dp-\u0026gt;hpd in\nhpd_show or dp-\u0026gt;lock in pin_assignment_show, as dev_get_drvdata() returns\nNULL in those cases.\r\n\r\nRemove manual sysfs node creation in favor of adding attribute group as\ndefault for devices bound to the driver. The ATTRIBUTE_GROUPS() macro is\nnot used here otherwise the path to the sysfs nodes is no longer compliant\nwith the ABI.(CVE-2024-35790)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nPCI/PM: Drain runtime-idle callbacks before driver removal\r\n\r\nA race condition between the .runtime_idle() callback and the .remove()\ncallback in the rtsx_pcr PCI driver leads to a kernel crash due to an\nunhandled page fault [1].\r\n\r\nThe problem is that rtsx_pci_runtime_idle() is not expected to be running\nafter pm_runtime_get_sync() has been called, but the latter doesn\u0026apos;t really\nguarantee that. It only guarantees that the suspend and resume callbacks\nwill not be running when it returns.\r\n\r\nHowever, if a .runtime_idle() callback is already running when\npm_runtime_get_sync() is called, the latter will notice that the runtime PM\nstatus of the device is RPM_ACTIVE and it will return right away without\nwaiting for the former to complete. In fact, it cannot wait for\n.runtime_idle() to complete because it may be called from that callback (it\narguably does not make much sense to do that, but it is not strictly\nprohibited).\r\n\r\nThus in general, whoever is providing a .runtime_idle() callback needs\nto protect it from running in parallel with whatever code runs after\npm_runtime_get_sync(). [Note that .runtime_idle() will not start after\npm_runtime_get_sync() has returned, but it may continue running then if it\nhas started earlier.]\r\n\r\nOne way to address that race condition is to call pm_runtime_barrier()\nafter pm_runtime_get_sync() (not before it, because a nonzero value of the\nruntime PM usage counter is necessary to prevent runtime PM callbacks from\nbeing invoked) to wait for the .runtime_idle() callback to complete should\nit be running at that point. A suitable place for doing that is in\npci_device_remove() which calls pm_runtime_get_sync() before removing the\ndriver, so it may as well call pm_runtime_barrier() subsequently, which\nwill prevent the race in question from occurring, not just in the rtsx_pcr\ndriver, but in any PCI drivers providing .runtime_idle() callbacks.(CVE-2024-35809)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: brcmfmac: Fix use-after-free bug in brcmf_cfg80211_detach\r\n\r\nThis is the candidate patch of CVE-2023-47233 :\nhttps://nvd.nist.gov/vuln/detail/CVE-2023-47233\r\n\r\nIn brcm80211 driver,it starts with the following invoking chain\nto start init a timeout worker:\r\n\r\n-\u0026gt;brcmf_usb_probe\n -\u0026gt;brcmf_usb_probe_cb\n -\u0026gt;brcmf_attach\n -\u0026gt;brcmf_bus_started\n -\u0026gt;brcmf_cfg80211_attach\n -\u0026gt;wl_init_priv\n -\u0026gt;brcmf_init_escan\n -\u0026gt;INIT_WORK(\u0026amp;cfg-\u0026gt;escan_timeout_work,\n\t\t brcmf_cfg80211_escan_timeout_worker);\r\n\r\nIf we disconnect the USB by hotplug, it will call\nbrcmf_usb_disconnect to make cleanup. The invoking chain is :\r\n\r\nbrcmf_usb_disconnect\n -\u0026gt;brcmf_usb_disconnect_cb\n -\u0026gt;brcmf_detach\n -\u0026gt;brcmf_cfg80211_detach\n -\u0026gt;kfree(cfg);\r\n\r\nWhile the timeout woker may still be running. This will cause\na use-after-free bug on cfg in brcmf_cfg80211_escan_timeout_worker.\r\n\r\nFix it by deleting the timer and canceling the worker in\nbrcmf_cfg80211_detach.\r\n\r\n[arend.vanspriel@broadcom.com: keep timer delete as is and cancel work just before free](CVE-2024-35811)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmlxsw: spectrum_acl_tcam: Fix memory leak during rehash\r\n\r\nThe rehash delayed work migrates filters from one region to another.\nThis is done by iterating over all chunks (all the filters with the same\npriority) in the region and in each chunk iterating over all the\nfilters.\r\n\r\nIf the migration fails, the code tries to migrate the filters back to\nthe old region. However, the rollback itself can also fail in which case\nanother migration will be erroneously performed. Besides the fact that\nthis ping pong is not a very good idea, it also creates a problem.\r\n\r\nEach virtual chunk references two chunks: The currently used one\n(\u0026apos;vchunk-\u0026gt;chunk\u0026apos;) and a backup (\u0026apos;vchunk-\u0026gt;chunk2\u0026apos;). During migration the\nfirst holds the chunk we want to migrate filters to and the second holds\nthe chunk we are migrating filters from.\r\n\r\nThe code currently assumes - but does not verify - that the backup chunk\ndoes not exist (NULL) if the currently used chunk does not reference the\ntarget region. This assumption breaks when we are trying to rollback a\nrollback, resulting in the backup chunk being overwritten and leaked\n[1].\r\n\r\nFix by not rolling back a failed rollback and add a warning to avoid\nfuture cases.\r\n\r\n[1]\nWARNING: CPU: 5 PID: 1063 at lib/parman.c:291 parman_destroy+0x17/0x20\nModules linked in:\nCPU: 5 PID: 1063 Comm: kworker/5:11 Tainted: G W 6.9.0-rc2-custom-00784-gc6a05c468a0b #14\nHardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019\nWorkqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work\nRIP: 0010:parman_destroy+0x17/0x20\n[...]\nCall Trace:\n \u0026lt;TASK\u0026gt;\n mlxsw_sp_acl_atcam_region_fini+0x19/0x60\n mlxsw_sp_acl_tcam_region_destroy+0x49/0xf0\n mlxsw_sp_acl_tcam_vregion_rehash_work+0x1f1/0x470\n process_one_work+0x151/0x370\n worker_thread+0x2cb/0x3e0\n kthread+0xd0/0x100\n ret_from_fork+0x34/0x50\n ret_from_fork_asm+0x1a/0x30\n \u0026lt;/TASK\u0026gt;(CVE-2024-35853)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmlxsw: spectrum_acl_tcam: Fix possible use-after-free during rehash\r\n\r\nThe rehash delayed work migrates filters from one region to another\naccording to the number of available credits.\r\n\r\nThe migrated from region is destroyed at the end of the work if the\nnumber of credits is non-negative as the assumption is that this is\nindicative of migration being complete. This assumption is incorrect as\na non-negative number of credits can also be the result of a failed\nmigration.\r\n\r\nThe destruction of a region that still has filters referencing it can\nresult in a use-after-free [1].\r\n\r\nFix by not destroying the region if migration failed.\r\n\r\n[1]\nBUG: KASAN: slab-use-after-free in mlxsw_sp_acl_ctcam_region_entry_remove+0x21d/0x230\nRead of size 8 at addr ffff8881735319e8 by task kworker/0:31/3858\r\n\r\nCPU: 0 PID: 3858 Comm: kworker/0:31 Tainted: G W 6.9.0-rc2-custom-00782-gf2275c2157d8 #5\nHardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019\nWorkqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0xc6/0x120\n print_report+0xce/0x670\n kasan_report+0xd7/0x110\n mlxsw_sp_acl_ctcam_region_entry_remove+0x21d/0x230\n mlxsw_sp_acl_ctcam_entry_del+0x2e/0x70\n mlxsw_sp_acl_atcam_entry_del+0x81/0x210\n mlxsw_sp_acl_tcam_vchunk_migrate_all+0x3cd/0xb50\n mlxsw_sp_acl_tcam_vregion_rehash_work+0x157/0x1300\n process_one_work+0x8eb/0x19b0\n worker_thread+0x6c9/0xf70\n kthread+0x2c9/0x3b0\n ret_from_fork+0x4d/0x80\n ret_from_fork_asm+0x1a/0x30\n \u0026lt;/TASK\u0026gt;\r\n\r\nAllocated by task 174:\n kasan_save_stack+0x33/0x60\n kasan_save_track+0x14/0x30\n __kasan_kmalloc+0x8f/0xa0\n __kmalloc+0x19c/0x360\n mlxsw_sp_acl_tcam_region_create+0xdf/0x9c0\n mlxsw_sp_acl_tcam_vregion_rehash_work+0x954/0x1300\n process_one_work+0x8eb/0x19b0\n worker_thread+0x6c9/0xf70\n kthread+0x2c9/0x3b0\n ret_from_fork+0x4d/0x80\n ret_from_fork_asm+0x1a/0x30\r\n\r\nFreed by task 7:\n kasan_save_stack+0x33/0x60\n kasan_save_track+0x14/0x30\n kasan_save_free_info+0x3b/0x60\n poison_slab_object+0x102/0x170\n __kasan_slab_free+0x14/0x30\n kfree+0xc1/0x290\n mlxsw_sp_acl_tcam_region_destroy+0x272/0x310\n mlxsw_sp_acl_tcam_vregion_rehash_work+0x731/0x1300\n process_one_work+0x8eb/0x19b0\n worker_thread+0x6c9/0xf70\n kthread+0x2c9/0x3b0\n ret_from_fork+0x4d/0x80\n ret_from_fork_asm+0x1a/0x30(CVE-2024-35854)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nriscv: process: Fix kernel gp leakage\r\n\r\nchildregs represents the registers which are active for the new thread\nin user context. For a kernel thread, childregs-\u0026gt;gp is never used since\nthe kernel gp is not touched by switch_to. For a user mode helper, the\ngp value can be observed in user space after execve or possibly by other\nmeans.\r\n\r\n[From the email thread]\r\n\r\nThe /* Kernel thread */ comment is somewhat inaccurate in that it is also used\nfor user_mode_helper threads, which exec a user process, e.g. /sbin/init or\nwhen /proc/sys/kernel/core_pattern is a pipe. Such threads do not have\nPF_KTHREAD set and are valid targets for ptrace etc. even before they exec.\r\n\r\nchildregs is the *user* context during syscall execution and it is observable\nfrom userspace in at least five ways:\r\n\r\n1. kernel_execve does not currently clear integer registers, so the starting\n register state for PID 1 and other user processes started by the kernel has\n sp = user stack, gp = kernel __global_pointer$, all other integer registers\n zeroed by the memset in the patch comment.\r\n\r\n This is a bug in its own right, but I\u0026apos;m unwilling to bet that it is the only\n way to exploit the issue addressed by this patch.\r\n\r\n2. ptrace(PTRACE_GETREGSET): you can PTRACE_ATTACH to a user_mode_helper thread\n before it execs, but ptrace requires SIGSTOP to be delivered which can only\n happen at user/kernel boundaries.\r\n\r\n3. /proc/*/task/*/syscall: this is perfectly happy to read pt_regs for\n user_mode_helpers before the exec completes, but gp is not one of the\n registers it returns.\r\n\r\n4. PERF_SAMPLE_REGS_USER: LOCKDOWN_PERF normally prevents access to kernel\n addresses via PERF_SAMPLE_REGS_INTR, but due to this bug kernel addresses\n are also exposed via PERF_SAMPLE_REGS_USER which is permitted under\n LOCKDOWN_PERF. I have not attempted to write exploit code.\r\n\r\n5. Much of the tracing infrastructure allows access to user registers. I have\n not attempted to determine which forms of tracing allow access to user\n registers without already allowing access to kernel registers.(CVE-2024-35871)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nerspan: make sure erspan_base_hdr is present in skb-\u0026gt;head\r\n\r\nsyzbot reported a problem in ip6erspan_rcv() [1]\r\n\r\nIssue is that ip6erspan_rcv() (and erspan_rcv()) no longer make\nsure erspan_base_hdr is present in skb linear part (skb-\u0026gt;head)\nbefore getting @ver field from it.\r\n\r\nAdd the missing pskb_may_pull() calls.\r\n\r\nv2: Reload iph pointer in erspan_rcv() after pskb_may_pull()\n because skb-\u0026gt;head might have changed.\r\n\r\n[1]\r\n\r\n BUG: KMSAN: uninit-value in pskb_may_pull_reason include/linux/skbuff.h:2742 [inline]\n BUG: KMSAN: uninit-value in pskb_may_pull include/linux/skbuff.h:2756 [inline]\n BUG: KMSAN: uninit-value in ip6erspan_rcv net/ipv6/ip6_gre.c:541 [inline]\n BUG: KMSAN: uninit-value in gre_rcv+0x11f8/0x1930 net/ipv6/ip6_gre.c:610\n pskb_may_pull_reason include/linux/skbuff.h:2742 [inline]\n pskb_may_pull include/linux/skbuff.h:2756 [inline]\n ip6erspan_rcv net/ipv6/ip6_gre.c:541 [inline]\n gre_rcv+0x11f8/0x1930 net/ipv6/ip6_gre.c:610\n ip6_protocol_deliver_rcu+0x1d4c/0x2ca0 net/ipv6/ip6_input.c:438\n ip6_input_finish net/ipv6/ip6_input.c:483 [inline]\n NF_HOOK include/linux/netfilter.h:314 [inline]\n ip6_input+0x15d/0x430 net/ipv6/ip6_input.c:492\n ip6_mc_input+0xa7e/0xc80 net/ipv6/ip6_input.c:586\n dst_input include/net/dst.h:460 [inline]\n ip6_rcv_finish+0x955/0x970 net/ipv6/ip6_input.c:79\n NF_HOOK include/linux/netfilter.h:314 [inline]\n ipv6_rcv+0xde/0x390 net/ipv6/ip6_input.c:310\n __netif_receive_skb_one_core net/core/dev.c:5538 [inline]\n __netif_receive_skb+0x1da/0xa00 net/core/dev.c:5652\n netif_receive_skb_internal net/core/dev.c:5738 [inline]\n netif_receive_skb+0x58/0x660 net/core/dev.c:5798\n tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1549\n tun_get_user+0x5566/0x69e0 drivers/net/tun.c:2002\n tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048\n call_write_iter include/linux/fs.h:2108 [inline]\n new_sync_write fs/read_write.c:497 [inline]\n vfs_write+0xb63/0x1520 fs/read_write.c:590\n ksys_write+0x20f/0x4c0 fs/read_write.c:643\n __do_sys_write fs/read_write.c:655 [inline]\n __se_sys_write fs/read_write.c:652 [inline]\n __x64_sys_write+0x93/0xe0 fs/read_write.c:652\n do_syscall_64+0xd5/0x1f0\n entry_SYSCALL_64_after_hwframe+0x6d/0x75\r\n\r\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:1318 [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 tun_alloc_skb drivers/net/tun.c:1525 [inline]\n tun_get_user+0x209a/0x69e0 drivers/net/tun.c:1846\n tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048\n call_write_iter include/linux/fs.h:2108 [inline]\n new_sync_write fs/read_write.c:497 [inline]\n vfs_write+0xb63/0x1520 fs/read_write.c:590\n ksys_write+0x20f/0x4c0 fs/read_write.c:643\n __do_sys_write fs/read_write.c:655 [inline]\n __se_sys_write fs/read_write.c:652 [inline]\n __x64_sys_write+0x93/0xe0 fs/read_write.c:652\n do_syscall_64+0xd5/0x1f0\n entry_SYSCALL_64_after_hwframe+0x6d/0x75\r\n\r\nCPU: 1 PID: 5045 Comm: syz-executor114 Not tainted 6.9.0-rc1-syzkaller-00021-g962490525cff #0(CVE-2024-35888)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbpf, sockmap: Prevent lock inversion deadlock in map delete elem\r\n\r\nsyzkaller started using corpuses where a BPF tracing program deletes\nelements from a sockmap/sockhash map. Because BPF tracing programs can be\ninvoked from any interrupt context, locks taken during a map_delete_elem\noperation must be hardirq-safe. Otherwise a deadlock due to lock inversion\nis possible, as reported by lockdep:\r\n\r\n CPU0 CPU1\n ---- ----\n lock(\u0026amp;htab-\u0026gt;buckets[i].lock);\n local_irq_disable();\n lock(\u0026amp;host-\u0026gt;lock);\n lock(\u0026amp;htab-\u0026gt;buckets[i].lock);\n \u0026lt;Interrupt\u0026gt;\n lock(\u0026amp;host-\u0026gt;lock);\r\n\r\nLocks in sockmap are hardirq-unsafe by design. We expects elements to be\ndeleted from sockmap/sockhash only in task (normal) context with interrupts\nenabled, or in softirq context.\r\n\r\nDetect when map_delete_elem operation is invoked from a context which is\n_not_ hardirq-unsafe, that is interrupts are disabled, and bail out with an\nerror.\r\n\r\nNote that map updates are not affected by this issue. BPF verifier does not\nallow updating sockmap/sockhash from a BPF tracing program today.(CVE-2024-35895)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: validate user input for expected length\r\n\r\nI got multiple syzbot reports showing old bugs exposed\nby BPF after commit 20f2505fb436 (\u0026quot;bpf: Try to avoid kzalloc\nin cgroup/{s,g}etsockopt\u0026quot;)\r\n\r\nsetsockopt() @optlen argument should be taken into account\nbefore copying data.\r\n\r\n BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline]\n BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline]\n BUG: KASAN: slab-out-of-bounds in do_replace net/ipv4/netfilter/ip_tables.c:1111 [inline]\n BUG: KASAN: slab-out-of-bounds in do_ipt_set_ctl+0x902/0x3dd0 net/ipv4/netfilter/ip_tables.c:1627\nRead of size 96 at addr ffff88802cd73da0 by task syz-executor.4/7238\r\n\r\nCPU: 1 PID: 7238 Comm: syz-executor.4 Not tainted 6.9.0-rc2-next-20240403-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114\n print_address_description mm/kasan/report.c:377 [inline]\n print_report+0x169/0x550 mm/kasan/report.c:488\n kasan_report+0x143/0x180 mm/kasan/report.c:601\n kasan_check_range+0x282/0x290 mm/kasan/generic.c:189\n __asan_memcpy+0x29/0x70 mm/kasan/shadow.c:105\n copy_from_sockptr_offset include/linux/sockptr.h:49 [inline]\n copy_from_sockptr include/linux/sockptr.h:55 [inline]\n do_replace net/ipv4/netfilter/ip_tables.c:1111 [inline]\n do_ipt_set_ctl+0x902/0x3dd0 net/ipv4/netfilter/ip_tables.c:1627\n nf_setsockopt+0x295/0x2c0 net/netfilter/nf_sockopt.c:101\n do_sock_setsockopt+0x3af/0x720 net/socket.c:2311\n __sys_setsockopt+0x1ae/0x250 net/socket.c:2334\n __do_sys_setsockopt net/socket.c:2343 [inline]\n __se_sys_setsockopt net/socket.c:2340 [inline]\n __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340\n do_syscall_64+0xfb/0x240\n entry_SYSCALL_64_after_hwframe+0x72/0x7a\nRIP: 0033:0x7fd22067dde9\nCode: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007fd21f9ff0c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000036\nRAX: ffffffffffffffda RBX: 00007fd2207abf80 RCX: 00007fd22067dde9\nRDX: 0000000000000040 RSI: 0000000000000000 RDI: 0000000000000003\nRBP: 00007fd2206ca47a R08: 0000000000000001 R09: 0000000000000000\nR10: 0000000020000880 R11: 0000000000000246 R12: 0000000000000000\nR13: 000000000000000b R14: 00007fd2207abf80 R15: 00007ffd2d0170d8\n \u0026lt;/TASK\u0026gt;\r\n\r\nAllocated by task 7238:\n kasan_save_stack mm/kasan/common.c:47 [inline]\n kasan_save_track+0x3f/0x80 mm/kasan/common.c:68\n poison_kmalloc_redzone mm/kasan/common.c:370 [inline]\n __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:387\n kasan_kmalloc include/linux/kasan.h:211 [inline]\n __do_kmalloc_node mm/slub.c:4069 [inline]\n __kmalloc_noprof+0x200/0x410 mm/slub.c:4082\n kmalloc_noprof include/linux/slab.h:664 [inline]\n __cgroup_bpf_run_filter_setsockopt+0xd47/0x1050 kernel/bpf/cgroup.c:1869\n do_sock_setsockopt+0x6b4/0x720 net/socket.c:2293\n __sys_setsockopt+0x1ae/0x250 net/socket.c:2334\n __do_sys_setsockopt net/socket.c:2343 [inline]\n __se_sys_setsockopt net/socket.c:2340 [inline]\n __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340\n do_syscall_64+0xfb/0x240\n entry_SYSCALL_64_after_hwframe+0x72/0x7a\r\n\r\nThe buggy address belongs to the object at ffff88802cd73da0\n which belongs to the cache kmalloc-8 of size 8\nThe buggy address is located 0 bytes inside of\n allocated 1-byte region [ffff88802cd73da0, ffff88802cd73da1)\r\n\r\nThe buggy address belongs to the physical page:\npage: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff88802cd73020 pfn:0x2cd73\nflags: 0xfff80000000000(node=0|zone=1|lastcpupid=0xfff)\npage_type: 0xffffefff(slab)\nraw: 00fff80000000000 ffff888015041280 dead000000000100 dead000000000122\nraw: ffff88802cd73020 000000008080007f 00000001ffffefff 00\n---truncated---(CVE-2024-35896)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbpf: Protect against int overflow for stack access size\r\n\r\nThis patch re-introduces protection against the size of access to stack\nmemory being negative; the access size can appear negative as a result\nof overflowing its signed int representation. This should not actually\nhappen, as there are other protections along the way, but we should\nprotect against it anyway. One code path was missing such protections\n(fixed in the previous patch in the series), causing out-of-bounds array\naccesses in check_stack_range_initialized(). This patch causes the\nverification of a program with such a non-sensical access size to fail.\r\n\r\nThis check used to exist in a more indirect way, but was inadvertendly\nremoved in a833a17aeac7.(CVE-2024-35905)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: typec: ucsi: Limit read size on v1.2\r\n\r\nBetween UCSI 1.2 and UCSI 2.0, the size of the MESSAGE_IN region was\nincreased from 16 to 256. In order to avoid overflowing reads for older\nsystems, add a mechanism to use the read UCSI version to truncate read\nsizes on UCSI v1.2.(CVE-2024-35924)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nBluetooth: SCO: Fix not validating setsockopt user input\r\n\r\nsyzbot reported sco_sock_setsockopt() is copying data without\nchecking user input length.\r\n\r\nBUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset\ninclude/linux/sockptr.h:49 [inline]\nBUG: KASAN: slab-out-of-bounds in copy_from_sockptr\ninclude/linux/sockptr.h:55 [inline]\nBUG: KASAN: slab-out-of-bounds in sco_sock_setsockopt+0xc0b/0xf90\nnet/bluetooth/sco.c:893\nRead of size 4 at addr ffff88805f7b15a3 by task syz-executor.5/12578(CVE-2024-35967)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ngeneve: fix header validation in geneve[6]_xmit_skb\r\n\r\nsyzbot is able to trigger an uninit-value in geneve_xmit() [1]\r\n\r\nProblem : While most ip tunnel helpers (like ip_tunnel_get_dsfield())\nuses skb_protocol(skb, true), pskb_inet_may_pull() is only using\nskb-\u0026gt;protocol.\r\n\r\nIf anything else than ETH_P_IPV6 or ETH_P_IP is found in skb-\u0026gt;protocol,\npskb_inet_may_pull() does nothing at all.\r\n\r\nIf a vlan tag was provided by the caller (af_packet in the syzbot case),\nthe network header might not point to the correct location, and skb\nlinear part could be smaller than expected.\r\n\r\nAdd skb_vlan_inet_prepare() to perform a complete mac validation.\r\n\r\nUse this in geneve for the moment, I suspect we need to adopt this\nmore broadly.\r\n\r\nv4 - Jakub reported v3 broke l2_tos_ttl_inherit.sh selftest\n - Only call __vlan_get_protocol() for vlan types.\r\n\r\nv2,v3 - Addressed Sabrina comments on v1 and v2\r\n\r\n[1]\r\n\r\nBUG: KMSAN: uninit-value in geneve_xmit_skb drivers/net/geneve.c:910 [inline]\n BUG: KMSAN: uninit-value in geneve_xmit+0x302d/0x5420 drivers/net/geneve.c:1030\n geneve_xmit_skb drivers/net/geneve.c:910 [inline]\n geneve_xmit+0x302d/0x5420 drivers/net/geneve.c:1030\n __netdev_start_xmit include/linux/netdevice.h:4903 [inline]\n netdev_start_xmit include/linux/netdevice.h:4917 [inline]\n xmit_one net/core/dev.c:3531 [inline]\n dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3547\n __dev_queue_xmit+0x348d/0x52c0 net/core/dev.c:4335\n dev_queue_xmit include/linux/netdevice.h:3091 [inline]\n packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276\n packet_snd net/packet/af_packet.c:3081 [inline]\n packet_sendmsg+0x8bb0/0x9ef0 net/packet/af_packet.c:3113\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg+0x30f/0x380 net/socket.c:745\n __sys_sendto+0x685/0x830 net/socket.c:2191\n __do_sys_sendto net/socket.c:2203 [inline]\n __se_sys_sendto net/socket.c:2199 [inline]\n __x64_sys_sendto+0x125/0x1d0 net/socket.c:2199\n do_syscall_64+0xd5/0x1f0\n entry_SYSCALL_64_after_hwframe+0x6d/0x75\r\n\r\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:1318 [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 packet_alloc_skb net/packet/af_packet.c:2930 [inline]\n packet_snd net/packet/af_packet.c:3024 [inline]\n packet_sendmsg+0x722d/0x9ef0 net/packet/af_packet.c:3113\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg+0x30f/0x380 net/socket.c:745\n __sys_sendto+0x685/0x830 net/socket.c:2191\n __do_sys_sendto net/socket.c:2203 [inline]\n __se_sys_sendto net/socket.c:2199 [inline]\n __x64_sys_sendto+0x125/0x1d0 net/socket.c:2199\n do_syscall_64+0xd5/0x1f0\n entry_SYSCALL_64_after_hwframe+0x6d/0x75\r\n\r\nCPU: 0 PID: 5033 Comm: syz-executor346 Not tainted 6.9.0-rc1-syzkaller-00005-g928a87efa423 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024(CVE-2024-35973)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbatman-adv: Avoid infinite loop trying to resize local TT\r\n\r\nIf the MTU of one of an attached interface becomes too small to transmit\nthe local translation table then it must be resized to fit inside all\nfragments (when enabled) or a single packet.\r\n\r\nBut if the MTU becomes too low to transmit even the header + the VLAN\nspecific part then the resizing of the local TT will never succeed. This\ncan for example happen when the usable space is 110 bytes and 11 VLANs are\non top of batman-adv. In this case, at least 116 byte would be needed.\nThere will just be an endless spam of\r\n\r\n batman_adv: batadv0: Forced to purge local tt entries to fit new maximum fragment MTU (110)\r\n\r\nin the log but the function will never finish. Problem here is that the\ntimeout will be halved all the time and will then stagnate at 0 and\ntherefore never be able to reduce the table even more.\r\n\r\nThere are other scenarios possible with a similar result. The number of\nBATADV_TT_CLIENT_NOPURGE entries in the local TT can for example be too\nhigh to fit inside a packet. Such a scenario can therefore happen also with\nonly a single VLAN + 7 non-purgable addresses - requiring at least 120\nbytes.\r\n\r\nWhile this should be handled proactively when:\r\n\r\n* interface with too low MTU is added\n* VLAN is added\n* non-purgeable local mac is added\n* MTU of an attached interface is reduced\n* fragmentation setting gets disabled (which most likely requires dropping\n attached interfaces)\r\n\r\nnot all of these scenarios can be prevented because batman-adv is only\nconsuming events without the the possibility to prevent these actions\n(non-purgable MAC address added, MTU of an attached interface is reduced).\nIt is therefore necessary to also make sure that the code is able to handle\nalso the situations when there were already incompatible system\nconfiguration are present.(CVE-2024-35982)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ni2c: smbus: fix NULL function pointer dereference\r\n\r\nBaruch reported an OOPS when using the designware controller as target\nonly. Target-only modes break the assumption of one transfer function\nalways being available. Fix this by always checking the pointer in\n__i2c_transfer.\r\n\r\n[wsa: dropped the simplification in core-smbus to avoid theoretical regressions](CVE-2024-35984)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nrtnetlink: Correct nested IFLA_VF_VLAN_LIST attribute validation\r\n\r\nEach attribute inside a nested IFLA_VF_VLAN_LIST is assumed to be a\nstruct ifla_vf_vlan_info so the size of such attribute needs to be at least\nof sizeof(struct ifla_vf_vlan_info) which is 14 bytes.\nThe current size validation in do_setvfinfo is against NLA_HDRLEN (4 bytes)\nwhich is less than sizeof(struct ifla_vf_vlan_info) so this validation\nis not enough and a too small attribute might be cast to a\nstruct ifla_vf_vlan_info, this might result in an out of bands\nread access when accessing the saved (casted) entry in ivvl.(CVE-2024-36017)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmmc: sdhci-msm: pervent access to suspended controller\r\n\r\nGeneric sdhci code registers LED device and uses host-\u0026gt;runtime_suspended\nflag to protect access to it. The sdhci-msm driver doesn\u0026apos;t set this flag,\nwhich causes a crash when LED is accessed while controller is runtime\nsuspended. Fix this by setting the flag correctly.(CVE-2024-36029)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: fix out-of-bounds access in ops_init\r\n\r\nnet_alloc_generic is called by net_alloc, which is called without any\nlocking. It reads max_gen_ptrs, which is changed under pernet_ops_rwsem. It\nis read twice, first to allocate an array, then to set s.len, which is\nlater used to limit the bounds of the array access.\r\n\r\nIt is possible that the array is allocated and another thread is\nregistering a new pernet ops, increments max_gen_ptrs, which is then used\nto set s.len with a larger than allocated length for the variable array.\r\n\r\nFix it by reading max_gen_ptrs only once in net_alloc_generic. If\nmax_gen_ptrs is later incremented, it will be caught in net_assign_generic.(CVE-2024-36883)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntipc: fix UAF in error path\r\n\r\nSam Page (sam4k) working with Trend Micro Zero Day Initiative reported\na UAF in the tipc_buf_append() error path:\r\n\r\nBUG: KASAN: slab-use-after-free in kfree_skb_list_reason+0x47e/0x4c0\nlinux/net/core/skbuff.c:1183\nRead of size 8 at addr ffff88804d2a7c80 by task poc/8034\r\n\r\nCPU: 1 PID: 8034 Comm: poc Not tainted 6.8.2 #1\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS\n1.16.0-debian-1.16.0-5 04/01/2014\nCall Trace:\n \u0026lt;IRQ\u0026gt;\n __dump_stack linux/lib/dump_stack.c:88\n dump_stack_lvl+0xd9/0x1b0 linux/lib/dump_stack.c:106\n print_address_description linux/mm/kasan/report.c:377\n print_report+0xc4/0x620 linux/mm/kasan/report.c:488\n kasan_report+0xda/0x110 linux/mm/kasan/report.c:601\n kfree_skb_list_reason+0x47e/0x4c0 linux/net/core/skbuff.c:1183\n skb_release_data+0x5af/0x880 linux/net/core/skbuff.c:1026\n skb_release_all linux/net/core/skbuff.c:1094\n __kfree_skb linux/net/core/skbuff.c:1108\n kfree_skb_reason+0x12d/0x210 linux/net/core/skbuff.c:1144\n kfree_skb linux/./include/linux/skbuff.h:1244\n tipc_buf_append+0x425/0xb50 linux/net/tipc/msg.c:186\n tipc_link_input+0x224/0x7c0 linux/net/tipc/link.c:1324\n tipc_link_rcv+0x76e/0x2d70 linux/net/tipc/link.c:1824\n tipc_rcv+0x45f/0x10f0 linux/net/tipc/node.c:2159\n tipc_udp_recv+0x73b/0x8f0 linux/net/tipc/udp_media.c:390\n udp_queue_rcv_one_skb+0xad2/0x1850 linux/net/ipv4/udp.c:2108\n udp_queue_rcv_skb+0x131/0xb00 linux/net/ipv4/udp.c:2186\n udp_unicast_rcv_skb+0x165/0x3b0 linux/net/ipv4/udp.c:2346\n __udp4_lib_rcv+0x2594/0x3400 linux/net/ipv4/udp.c:2422\n ip_protocol_deliver_rcu+0x30c/0x4e0 linux/net/ipv4/ip_input.c:205\n ip_local_deliver_finish+0x2e4/0x520 linux/net/ipv4/ip_input.c:233\n NF_HOOK linux/./include/linux/netfilter.h:314\n NF_HOOK linux/./include/linux/netfilter.h:308\n ip_local_deliver+0x18e/0x1f0 linux/net/ipv4/ip_input.c:254\n dst_input linux/./include/net/dst.h:461\n ip_rcv_finish linux/net/ipv4/ip_input.c:449\n NF_HOOK linux/./include/linux/netfilter.h:314\n NF_HOOK linux/./include/linux/netfilter.h:308\n ip_rcv+0x2c5/0x5d0 linux/net/ipv4/ip_input.c:569\n __netif_receive_skb_one_core+0x199/0x1e0 linux/net/core/dev.c:5534\n __netif_receive_skb+0x1f/0x1c0 linux/net/core/dev.c:5648\n process_backlog+0x101/0x6b0 linux/net/core/dev.c:5976\n __napi_poll.constprop.0+0xba/0x550 linux/net/core/dev.c:6576\n napi_poll linux/net/core/dev.c:6645\n net_rx_action+0x95a/0xe90 linux/net/core/dev.c:6781\n __do_softirq+0x21f/0x8e7 linux/kernel/softirq.c:553\n do_softirq linux/kernel/softirq.c:454\n do_softirq+0xb2/0xf0 linux/kernel/softirq.c:441\n \u0026lt;/IRQ\u0026gt;\n \u0026lt;TASK\u0026gt;\n __local_bh_enable_ip+0x100/0x120 linux/kernel/softirq.c:381\n local_bh_enable linux/./include/linux/bottom_half.h:33\n rcu_read_unlock_bh linux/./include/linux/rcupdate.h:851\n __dev_queue_xmit+0x871/0x3ee0 linux/net/core/dev.c:4378\n dev_queue_xmit linux/./include/linux/netdevice.h:3169\n neigh_hh_output linux/./include/net/neighbour.h:526\n neigh_output linux/./include/net/neighbour.h:540\n ip_finish_output2+0x169f/0x2550 linux/net/ipv4/ip_output.c:235\n __ip_finish_output linux/net/ipv4/ip_output.c:313\n __ip_finish_output+0x49e/0x950 linux/net/ipv4/ip_output.c:295\n ip_finish_output+0x31/0x310 linux/net/ipv4/ip_output.c:323\n NF_HOOK_COND linux/./include/linux/netfilter.h:303\n ip_output+0x13b/0x2a0 linux/net/ipv4/ip_output.c:433\n dst_output linux/./include/net/dst.h:451\n ip_local_out linux/net/ipv4/ip_output.c:129\n ip_send_skb+0x3e5/0x560 linux/net/ipv4/ip_output.c:1492\n udp_send_skb+0x73f/0x1530 linux/net/ipv4/udp.c:963\n udp_sendmsg+0x1a36/0x2b40 linux/net/ipv4/udp.c:1250\n inet_sendmsg+0x105/0x140 linux/net/ipv4/af_inet.c:850\n sock_sendmsg_nosec linux/net/socket.c:730\n __sock_sendmsg linux/net/socket.c:745\n __sys_sendto+0x42c/0x4e0 linux/net/socket.c:2191\n __do_sys_sendto linux/net/socket.c:2203\n __se_sys_sendto linux/net/socket.c:2199\n __x64_sys_sendto+0xe0/0x1c0 linux/net/socket.c:2199\n do_syscall_x64 linux/arch/x86/entry/common.c:52\n do_syscall_\n---truncated---(CVE-2024-36886)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmptcp: ensure snd_nxt is properly initialized on connect\r\n\r\nChristoph reported a splat hinting at a corrupted snd_una:\r\n\r\n WARNING: CPU: 1 PID: 38 at net/mptcp/protocol.c:1005 __mptcp_clean_una+0x4b3/0x620 net/mptcp/protocol.c:1005\n Modules linked in:\n CPU: 1 PID: 38 Comm: kworker/1:1 Not tainted 6.9.0-rc1-gbbeac67456c9 #59\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014\n Workqueue: events mptcp_worker\n RIP: 0010:__mptcp_clean_una+0x4b3/0x620 net/mptcp/protocol.c:1005\n Code: be 06 01 00 00 bf 06 01 00 00 e8 a8 12 e7 fe e9 00 fe ff ff e8\n \t8e 1a e7 fe 0f b7 ab 3e 02 00 00 e9 d3 fd ff ff e8 7d 1a e7 fe\n \t\u0026lt;0f\u0026gt; 0b 4c 8b bb e0 05 00 00 e9 74 fc ff ff e8 6a 1a e7 fe 0f 0b e9\n RSP: 0018:ffffc9000013fd48 EFLAGS: 00010293\n RAX: 0000000000000000 RBX: ffff8881029bd280 RCX: ffffffff82382fe4\n RDX: ffff8881003cbd00 RSI: ffffffff823833c3 RDI: 0000000000000001\n RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000\n R10: 0000000000000000 R11: fefefefefefefeff R12: ffff888138ba8000\n R13: 0000000000000106 R14: ffff8881029bd908 R15: ffff888126560000\n FS: 0000000000000000(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00007f604a5dae38 CR3: 0000000101dac002 CR4: 0000000000170ef0\n Call Trace:\n \u0026lt;TASK\u0026gt;\n __mptcp_clean_una_wakeup net/mptcp/protocol.c:1055 [inline]\n mptcp_clean_una_wakeup net/mptcp/protocol.c:1062 [inline]\n __mptcp_retrans+0x7f/0x7e0 net/mptcp/protocol.c:2615\n mptcp_worker+0x434/0x740 net/mptcp/protocol.c:2767\n process_one_work+0x1e0/0x560 kernel/workqueue.c:3254\n process_scheduled_works kernel/workqueue.c:3335 [inline]\n worker_thread+0x3c7/0x640 kernel/workqueue.c:3416\n kthread+0x121/0x170 kernel/kthread.c:388\n ret_from_fork+0x44/0x50 arch/x86/kernel/process.c:147\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:243\n \u0026lt;/TASK\u0026gt;\r\n\r\nWhen fallback to TCP happens early on a client socket, snd_nxt\nis not yet initialized and any incoming ack will copy such value\ninto snd_una. If the mptcp worker (dumbly) tries mptcp-level\nre-injection after such ack, that would unconditionally trigger a send\nbuffer cleanup using \u0026apos;bad\u0026apos; snd_una values.\r\n\r\nWe could easily disable re-injection for fallback sockets, but such\ndumb behavior already helped catching a few subtle issues and a very\nlow to zero impact in practice.\r\n\r\nInstead address the issue always initializing snd_nxt (and write_seq,\nfor consistency) at connect time.(CVE-2024-36889)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ngpiolib: cdev: fix uninitialised kfifo\r\n\r\nIf a line is requested with debounce, and that results in debouncing\nin software, and the line is subsequently reconfigured to enable edge\ndetection then the allocation of the kfifo to contain edge events is\noverlooked. This results in events being written to and read from an\nuninitialised kfifo. Read events are returned to userspace.\r\n\r\nInitialise the kfifo in the case where the software debounce is\nalready active.(CVE-2024-36898)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ngpiolib: cdev: Fix use after free in lineinfo_changed_notify\r\n\r\nThe use-after-free issue occurs as follows: when the GPIO chip device file\nis being closed by invoking gpio_chrdev_release(), watched_lines is freed\nby bitmap_free(), but the unregistration of lineinfo_changed_nb notifier\nchain failed due to waiting write rwsem. Additionally, one of the GPIO\nchip\u0026apos;s lines is also in the release process and holds the notifier chain\u0026apos;s\nread rwsem. Consequently, a race condition leads to the use-after-free of\nwatched_lines.\r\n\r\nHere is the typical stack when issue happened:\r\n\r\n[free]\ngpio_chrdev_release()\n --\u0026gt; bitmap_free(cdev-\u0026gt;watched_lines) \u0026lt;-- freed\n --\u0026gt; blocking_notifier_chain_unregister()\n --\u0026gt; down_write(\u0026amp;nh-\u0026gt;rwsem) \u0026lt;-- waiting rwsem\n --\u0026gt; __down_write_common()\n --\u0026gt; rwsem_down_write_slowpath()\n --\u0026gt; schedule_preempt_disabled()\n --\u0026gt; schedule()\r\n\r\n[use]\nst54spi_gpio_dev_release()\n --\u0026gt; gpio_free()\n --\u0026gt; gpiod_free()\n --\u0026gt; gpiod_free_commit()\n --\u0026gt; gpiod_line_state_notify()\n --\u0026gt; blocking_notifier_call_chain()\n --\u0026gt; down_read(\u0026amp;nh-\u0026gt;rwsem); \u0026lt;-- held rwsem\n --\u0026gt; notifier_call_chain()\n --\u0026gt; lineinfo_changed_notify()\n --\u0026gt; test_bit(xxxx, cdev-\u0026gt;watched_lines) \u0026lt;-- use after free\r\n\r\nThe side effect of the use-after-free issue is that a GPIO line event is\nbeing generated for userspace where it shouldn\u0026apos;t. However, since the chrdev\nis being closed, userspace won\u0026apos;t have the chance to read that event anyway.\r\n\r\nTo fix the issue, call the bitmap_free() function after the unregistration\nof lineinfo_changed_nb notifier chain.(CVE-2024-36899)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nipv6: prevent NULL dereference in ip6_output()\r\n\r\nAccording to syzbot, there is a chance that ip6_dst_idev()\nreturns NULL in ip6_output(). Most places in IPv6 stack\ndeal with a NULL idev just fine, but not here.\r\n\r\nsyzbot reported:\r\n\r\ngeneral protection fault, probably for non-canonical address 0xdffffc00000000bc: 0000 [#1] PREEMPT SMP KASAN PTI\nKASAN: null-ptr-deref in range [0x00000000000005e0-0x00000000000005e7]\nCPU: 0 PID: 9775 Comm: syz-executor.4 Not tainted 6.9.0-rc5-syzkaller-00157-g6a30653b604a #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024\n RIP: 0010:ip6_output+0x231/0x3f0 net/ipv6/ip6_output.c:237\nCode: 3c 1e 00 49 89 df 74 08 4c 89 ef e8 19 58 db f7 48 8b 44 24 20 49 89 45 00 49 89 c5 48 8d 9d e0 05 00 00 48 89 d8 48 c1 e8 03 \u0026lt;42\u0026gt; 0f b6 04 38 84 c0 4c 8b 74 24 28 0f 85 61 01 00 00 8b 1b 31 ff\nRSP: 0018:ffffc9000927f0d8 EFLAGS: 00010202\nRAX: 00000000000000bc RBX: 00000000000005e0 RCX: 0000000000040000\nRDX: ffffc900131f9000 RSI: 0000000000004f47 RDI: 0000000000004f48\nRBP: 0000000000000000 R08: ffffffff8a1f0b9a R09: 1ffffffff1f51fad\nR10: dffffc0000000000 R11: fffffbfff1f51fae R12: ffff8880293ec8c0\nR13: ffff88805d7fc000 R14: 1ffff1100527d91a R15: dffffc0000000000\nFS: 00007f135c6856c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000020000080 CR3: 0000000064096000 CR4: 00000000003506f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n NF_HOOK include/linux/netfilter.h:314 [inline]\n ip6_xmit+0xefe/0x17f0 net/ipv6/ip6_output.c:358\n sctp_v6_xmit+0x9f2/0x13f0 net/sctp/ipv6.c:248\n sctp_packet_transmit+0x26ad/0x2ca0 net/sctp/output.c:653\n sctp_packet_singleton+0x22c/0x320 net/sctp/outqueue.c:783\n sctp_outq_flush_ctrl net/sctp/outqueue.c:914 [inline]\n sctp_outq_flush+0x6d5/0x3e20 net/sctp/outqueue.c:1212\n sctp_side_effects net/sctp/sm_sideeffect.c:1198 [inline]\n sctp_do_sm+0x59cc/0x60c0 net/sctp/sm_sideeffect.c:1169\n sctp_primitive_ASSOCIATE+0x95/0xc0 net/sctp/primitive.c:73\n __sctp_connect+0x9cd/0xe30 net/sctp/socket.c:1234\n sctp_connect net/sctp/socket.c:4819 [inline]\n sctp_inet_connect+0x149/0x1f0 net/sctp/socket.c:4834\n __sys_connect_file net/socket.c:2048 [inline]\n __sys_connect+0x2df/0x310 net/socket.c:2065\n __do_sys_connect net/socket.c:2075 [inline]\n __se_sys_connect net/socket.c:2072 [inline]\n __x64_sys_connect+0x7a/0x90 net/socket.c:2072\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2024-36901)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nipv6: fib6_rules: avoid possible NULL dereference in fib6_rule_action()\r\n\r\nsyzbot is able to trigger the following crash [1],\ncaused by unsafe ip6_dst_idev() use.\r\n\r\nIndeed ip6_dst_idev() can return NULL, and must always be checked.\r\n\r\n[1]\r\n\r\nOops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI\nKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]\nCPU: 0 PID: 31648 Comm: syz-executor.0 Not tainted 6.9.0-rc4-next-20240417-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024\n RIP: 0010:__fib6_rule_action net/ipv6/fib6_rules.c:237 [inline]\n RIP: 0010:fib6_rule_action+0x241/0x7b0 net/ipv6/fib6_rules.c:267\nCode: 02 00 00 49 8d 9f d8 00 00 00 48 89 d8 48 c1 e8 03 42 80 3c 20 00 74 08 48 89 df e8 f9 32 bf f7 48 8b 1b 48 89 d8 48 c1 e8 03 \u0026lt;42\u0026gt; 80 3c 20 00 74 08 48 89 df e8 e0 32 bf f7 4c 8b 03 48 89 ef 4c\nRSP: 0018:ffffc9000fc1f2f0 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: 0000000000000000 RCX: 1a772f98c8186700\nRDX: 0000000000000003 RSI: ffffffff8bcac4e0 RDI: ffffffff8c1f9760\nRBP: ffff8880673fb980 R08: ffffffff8fac15ef R09: 1ffffffff1f582bd\nR10: dffffc0000000000 R11: fffffbfff1f582be R12: dffffc0000000000\nR13: 0000000000000080 R14: ffff888076509000 R15: ffff88807a029a00\nFS: 00007f55e82ca6c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000001b31d23000 CR3: 0000000022b66000 CR4: 00000000003506f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n fib_rules_lookup+0x62c/0xdb0 net/core/fib_rules.c:317\n fib6_rule_lookup+0x1fd/0x790 net/ipv6/fib6_rules.c:108\n ip6_route_output_flags_noref net/ipv6/route.c:2637 [inline]\n ip6_route_output_flags+0x38e/0x610 net/ipv6/route.c:2649\n ip6_route_output include/net/ip6_route.h:93 [inline]\n ip6_dst_lookup_tail+0x189/0x11a0 net/ipv6/ip6_output.c:1120\n ip6_dst_lookup_flow+0xb9/0x180 net/ipv6/ip6_output.c:1250\n sctp_v6_get_dst+0x792/0x1e20 net/sctp/ipv6.c:326\n sctp_transport_route+0x12c/0x2e0 net/sctp/transport.c:455\n sctp_assoc_add_peer+0x614/0x15c0 net/sctp/associola.c:662\n sctp_connect_new_asoc+0x31d/0x6c0 net/sctp/socket.c:1099\n __sctp_connect+0x66d/0xe30 net/sctp/socket.c:1197\n sctp_connect net/sctp/socket.c:4819 [inline]\n sctp_inet_connect+0x149/0x1f0 net/sctp/socket.c:4834\n __sys_connect_file net/socket.c:2048 [inline]\n __sys_connect+0x2df/0x310 net/socket.c:2065\n __do_sys_connect net/socket.c:2075 [inline]\n __se_sys_connect net/socket.c:2072 [inline]\n __x64_sys_connect+0x7a/0x90 net/socket.c:2072\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2024-36902)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nipv6: Fix potential uninit-value access in __ip6_make_skb()\r\n\r\nAs it was done in commit fc1092f51567 (\u0026quot;ipv4: Fix uninit-value access in\n__ip_make_skb()\u0026quot;) for IPv4, check FLOWI_FLAG_KNOWN_NH on fl6-\u0026gt;flowi6_flags\ninstead of testing HDRINCL on the socket to avoid a race condition which\ncauses uninit-value access.(CVE-2024-36903)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nARM: 9381/1: kasan: clear stale stack poison\r\n\r\nWe found below OOB crash:\r\n\r\n[ 33.452494] ==================================================================\n[ 33.453513] BUG: KASAN: stack-out-of-bounds in refresh_cpu_vm_stats.constprop.0+0xcc/0x2ec\n[ 33.454660] Write of size 164 at addr c1d03d30 by task swapper/0/0\n[ 33.455515]\n[ 33.455767] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G O 6.1.25-mainline #1\n[ 33.456880] Hardware name: Generic DT based system\n[ 33.457555] unwind_backtrace from show_stack+0x18/0x1c\n[ 33.458326] show_stack from dump_stack_lvl+0x40/0x4c\n[ 33.459072] dump_stack_lvl from print_report+0x158/0x4a4\n[ 33.459863] print_report from kasan_report+0x9c/0x148\n[ 33.460616] kasan_report from kasan_check_range+0x94/0x1a0\n[ 33.461424] kasan_check_range from memset+0x20/0x3c\n[ 33.462157] memset from refresh_cpu_vm_stats.constprop.0+0xcc/0x2ec\n[ 33.463064] refresh_cpu_vm_stats.constprop.0 from tick_nohz_idle_stop_tick+0x180/0x53c\n[ 33.464181] tick_nohz_idle_stop_tick from do_idle+0x264/0x354\n[ 33.465029] do_idle from cpu_startup_entry+0x20/0x24\n[ 33.465769] cpu_startup_entry from rest_init+0xf0/0xf4\n[ 33.466528] rest_init from arch_post_acpi_subsys_init+0x0/0x18\n[ 33.467397]\n[ 33.467644] The buggy address belongs to stack of task swapper/0/0\n[ 33.468493] and is located at offset 112 in frame:\n[ 33.469172] refresh_cpu_vm_stats.constprop.0+0x0/0x2ec\n[ 33.469917]\n[ 33.470165] This frame has 2 objects:\n[ 33.470696] [32, 76) \u0026apos;global_zone_diff\u0026apos;\n[ 33.470729] [112, 276) \u0026apos;global_node_diff\u0026apos;\n[ 33.471294]\n[ 33.472095] The buggy address belongs to the physical page:\n[ 33.472862] page:3cd72da8 refcount:1 mapcount:0 mapping:00000000 index:0x0 pfn:0x41d03\n[ 33.473944] flags: 0x1000(reserved|zone=0)\n[ 33.474565] raw: 00001000 ed741470 ed741470 00000000 00000000 00000000 ffffffff 00000001\n[ 33.475656] raw: 00000000\n[ 33.476050] page dumped because: kasan: bad access detected\n[ 33.476816]\n[ 33.477061] Memory state around the buggy address:\n[ 33.477732] c1d03c00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n[ 33.478630] c1d03c80: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00 00 00\n[ 33.479526] \u0026gt;c1d03d00: 00 04 f2 f2 f2 f2 00 00 00 00 00 00 f1 f1 f1 f1\n[ 33.480415] ^\n[ 33.481195] c1d03d80: 00 00 00 00 00 00 00 00 00 00 04 f3 f3 f3 f3 f3\n[ 33.482088] c1d03e00: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00\n[ 33.482978] ==================================================================\r\n\r\nWe find the root cause of this OOB is that arm does not clear stale stack\npoison in the case of cpuidle.\r\n\r\nThis patch refer to arch/arm64/kernel/sleep.S to resolve this issue.\r\n\r\nFrom cited commit [1] that explain the problem\r\n\r\nFunctions which the compiler has instrumented for KASAN place poison on\nthe stack shadow upon entry and remove this poison prior to returning.\r\n\r\nIn the case of cpuidle, CPUs exit the kernel a number of levels deep in\nC code. Any instrumented functions on this critical path will leave\nportions of the stack shadow poisoned.\r\n\r\nIf CPUs lose context and return to the kernel via a cold path, we\nrestore a prior context saved in __cpu_suspend_enter are forgotten, and\nwe never remove the poison they placed in the stack shadow area by\nfunctions calls between this and the actual exit of the kernel.\r\n\r\nThus, (depending on stackframe layout) subsequent calls to instrumented\nfunctions may hit this stale poison, resulting in (spurious) KASAN\nsplats to the console.\r\n\r\nTo avoid this, clear any stale poison from the idle thread for a CPU\nprior to bringing a CPU online.\r\n\r\nFrom cited commit [2]\r\n\r\nExtend to check for CONFIG_KASAN_STACK\r\n\r\n[1] commit 0d97e6d8024c (\u0026quot;arm64: kasan: clear stale stack poison\u0026quot;)\n[2] commit d56a9ef84bd0 (\u0026quot;kasan, arm64: unpoison stack only with CONFIG_KASAN_STACK\u0026quot;)(CVE-2024-36906)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nblk-iocost: do not WARN if iocg was already offlined\r\n\r\nIn iocg_pay_debt(), warn is triggered if \u0026apos;active_list\u0026apos; is empty, which\nis intended to confirm iocg is active when it has debt. However, warn\ncan be triggered during a blkcg or disk removal, if iocg_waitq_timer_fn()\nis run at that time:\r\n\r\n WARNING: CPU: 0 PID: 2344971 at block/blk-iocost.c:1402 iocg_pay_debt+0x14c/0x190\n Call trace:\n iocg_pay_debt+0x14c/0x190\n iocg_kick_waitq+0x438/0x4c0\n iocg_waitq_timer_fn+0xd8/0x130\n __run_hrtimer+0x144/0x45c\n __hrtimer_run_queues+0x16c/0x244\n hrtimer_interrupt+0x2cc/0x7b0\r\n\r\nThe warn in this situation is meaningless. Since this iocg is being\nremoved, the state of the \u0026apos;active_list\u0026apos; is irrelevant, and \u0026apos;waitq_timer\u0026apos;\nis canceled after removing \u0026apos;active_list\u0026apos; in ioc_pd_free(), which ensures\niocg is freed after iocg_waitq_timer_fn() returns.\r\n\r\nTherefore, add the check if iocg was already offlined to avoid warn\nwhen removing a blkcg or disk.(CVE-2024-36908)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nblock: fix overflow in blk_ioctl_discard()\r\n\r\nThere is no check for overflow of \u0026apos;start + len\u0026apos; in blk_ioctl_discard().\nHung task occurs if submit an discard ioctl with the following param:\n start = 0x80000000000ff000, len = 0x8000000000fff000;\nAdd the overflow validation now.(CVE-2024-36917)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: lpfc: Release hbalock before calling lpfc_worker_wake_up()\r\n\r\nlpfc_worker_wake_up() calls the lpfc_work_done() routine, which takes the\nhbalock. Thus, lpfc_worker_wake_up() should not be called while holding the\nhbalock to avoid potential deadlock.(CVE-2024-36924)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ns390/qeth: Fix kernel panic after setting hsuid\r\n\r\nSymptom:\nWhen the hsuid attribute is set for the first time on an IQD Layer3\ndevice while the corresponding network interface is already UP,\nthe kernel will try to execute a napi function pointer that is NULL.\r\n\r\nExample:\n---------------------------------------------------------------------------\n[ 2057.572696] illegal operation: 0001 ilc:1 [#1] SMP\n[ 2057.572702] Modules linked in: af_iucv qeth_l3 zfcp scsi_transport_fc sunrpc nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6\nnft_reject nft_ct nf_tables_set nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables libcrc32c nfnetlink ghash_s390 prng xts aes_s390 des_s390 de\ns_generic sha3_512_s390 sha3_256_s390 sha512_s390 vfio_ccw vfio_mdev mdev vfio_iommu_type1 eadm_sch vfio ext4 mbcache jbd2 qeth_l2 bridge stp llc dasd_eckd_mod qeth dasd_mod\n qdio ccwgroup pkey zcrypt\n[ 2057.572739] CPU: 6 PID: 60182 Comm: stress_client Kdump: loaded Not tainted 4.18.0-541.el8.s390x #1\n[ 2057.572742] Hardware name: IBM 3931 A01 704 (LPAR)\n[ 2057.572744] Krnl PSW : 0704f00180000000 0000000000000002 (0x2)\n[ 2057.572748] R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:3 PM:0 RI:0 EA:3\n[ 2057.572751] Krnl GPRS: 0000000000000004 0000000000000000 00000000a3b008d8 0000000000000000\n[ 2057.572754] 00000000a3b008d8 cb923a29c779abc5 0000000000000000 00000000814cfd80\n[ 2057.572756] 000000000000012c 0000000000000000 00000000a3b008d8 00000000a3b008d8\n[ 2057.572758] 00000000bab6d500 00000000814cfd80 0000000091317e46 00000000814cfc68\n[ 2057.572762] Krnl Code:#0000000000000000: 0000 illegal\n \u0026gt;0000000000000002: 0000 illegal\n 0000000000000004: 0000 illegal\n 0000000000000006: 0000 illegal\n 0000000000000008: 0000 illegal\n 000000000000000a: 0000 illegal\n 000000000000000c: 0000 illegal\n 000000000000000e: 0000 illegal\n[ 2057.572800] Call Trace:\n[ 2057.572801] ([\u0026lt;00000000ec639700\u0026gt;] 0xec639700)\n[ 2057.572803] [\u0026lt;00000000913183e2\u0026gt;] net_rx_action+0x2ba/0x398\n[ 2057.572809] [\u0026lt;0000000091515f76\u0026gt;] __do_softirq+0x11e/0x3a0\n[ 2057.572813] [\u0026lt;0000000090ce160c\u0026gt;] do_softirq_own_stack+0x3c/0x58\n[ 2057.572817] ([\u0026lt;0000000090d2cbd6\u0026gt;] do_softirq.part.1+0x56/0x60)\n[ 2057.572822] [\u0026lt;0000000090d2cc60\u0026gt;] __local_bh_enable_ip+0x80/0x98\n[ 2057.572825] [\u0026lt;0000000091314706\u0026gt;] __dev_queue_xmit+0x2be/0xd70\n[ 2057.572827] [\u0026lt;000003ff803dd6d6\u0026gt;] afiucv_hs_send+0x24e/0x300 [af_iucv]\n[ 2057.572830] [\u0026lt;000003ff803dd88a\u0026gt;] iucv_send_ctrl+0x102/0x138 [af_iucv]\n[ 2057.572833] [\u0026lt;000003ff803de72a\u0026gt;] iucv_sock_connect+0x37a/0x468 [af_iucv]\n[ 2057.572835] [\u0026lt;00000000912e7e90\u0026gt;] __sys_connect+0xa0/0xd8\n[ 2057.572839] [\u0026lt;00000000912e9580\u0026gt;] sys_socketcall+0x228/0x348\n[ 2057.572841] [\u0026lt;0000000091514e1a\u0026gt;] system_call+0x2a6/0x2c8\n[ 2057.572843] Last Breaking-Event-Address:\n[ 2057.572844] [\u0026lt;0000000091317e44\u0026gt;] __napi_poll+0x4c/0x1d8\n[ 2057.572846]\n[ 2057.572847] Kernel panic - not syncing: Fatal exception in interrupt\n-------------------------------------------------------------------------------------------\r\n\r\nAnalysis:\nThere is one napi structure per out_q: card-\u0026gt;qdio.out_qs[i].napi\nThe napi.poll functions are set during qeth_open().\r\n\r\nSince\ncommit 1cfef80d4c2b (\u0026quot;s390/qeth: Don\u0026apos;t call dev_close/dev_open (DOWN/UP)\u0026quot;)\nqeth_set_offline()/qeth_set_online() no longer call dev_close()/\ndev_open(). So if qeth_free_qdio_queues() cleared\ncard-\u0026gt;qdio.out_qs[i].napi.poll while the network interface was UP and the\ncard was offline, they are not set again.\r\n\r\nReproduction:\nchzdev -e $devno layer2=0\nip link set dev $network_interface up\necho 0 \u0026gt; /sys/bus/ccw\n---truncated---(CVE-2024-36928)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: core: reject skb_copy(_expand) for fraglist GSO skbs\r\n\r\nSKB_GSO_FRAGLIST skbs must not be linearized, otherwise they become\ninvalid. Return NULL if such an skb is passed to skb_copy or\nskb_copy_expand, in order to prevent a crash on a potential later\ncall to skb_gso_segment.(CVE-2024-36929)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\namd/amdkfd: sync all devices to wait all processes being evicted\r\n\r\nIf there are more than one device doing reset in parallel, the first\ndevice will call kfd_suspend_all_processes() to evict all processes\non all devices, this call takes time to finish. other device will\nstart reset and recover without waiting. if the process has not been\nevicted before doing recover, it will be restored, then caused page\nfault.(CVE-2024-36949)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntipc: fix a possible memleak in tipc_buf_append\r\n\r\n__skb_linearize() doesn\u0026apos;t free the skb when it fails, so move\n\u0026apos;*buf = NULL\u0026apos; after __skb_linearize(), so that the skb can be\nfreed on the err path.(CVE-2024-36954)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nocteontx2-af: avoid off-by-one read from userspace\r\n\r\nWe try to access count + 1 byte from userspace with memdup_user(buffer,\ncount + 1). However, the userspace only provides buffer of count bytes and\nonly these count bytes are verified to be okay to access. To ensure the\ncopied buffer is NUL terminated, we use memdup_user_nul instead.(CVE-2024-36957)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfs/9p: only translate RWX permissions for plain 9P2000\r\n\r\nGarbage in plain 9P2000\u0026apos;s perm bits is allowed through, which causes it\nto be able to set (among others) the suid bit. This was presumably not\nthe intent since the unix extended bits are handled explicitly and\nconditionally on .u.(CVE-2024-36964)",
"id": "OESA-2024-1707",
"modified": "2026-08-06T11:07:10Z",
"published": "2024-06-14T11:07:10Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1707"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47247"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47484"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47558"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48652"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52672"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52680"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52686"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52693"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52732"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52762"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52775"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52803"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52810"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52880"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52881"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26835"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26889"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27393"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27402"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27408"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35790"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35809"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35811"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35853"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35854"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35871"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35888"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35895"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35896"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35905"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35924"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35967"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35973"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35982"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35984"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36017"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36029"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36883"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36886"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36889"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36898"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36899"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36901"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36902"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36903"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36906"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36908"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36917"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36924"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36928"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36929"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36949"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36954"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36957"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36964"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2021-47247",
"CVE-2021-47484",
"CVE-2021-47558",
"CVE-2022-48652",
"CVE-2023-52672",
"CVE-2023-52680",
"CVE-2023-52686",
"CVE-2023-52693",
"CVE-2023-52732",
"CVE-2023-52762",
"CVE-2023-52775",
"CVE-2023-52803",
"CVE-2023-52810",
"CVE-2023-52880",
"CVE-2023-52881",
"CVE-2024-26835",
"CVE-2024-26889",
"CVE-2024-27393",
"CVE-2024-27402",
"CVE-2024-27408",
"CVE-2024-35790",
"CVE-2024-35809",
"CVE-2024-35811",
"CVE-2024-35853",
"CVE-2024-35854",
"CVE-2024-35871",
"CVE-2024-35888",
"CVE-2024-35895",
"CVE-2024-35896",
"CVE-2024-35905",
"CVE-2024-35924",
"CVE-2024-35967",
"CVE-2024-35973",
"CVE-2024-35982",
"CVE-2024-35984",
"CVE-2024-36017",
"CVE-2024-36029",
"CVE-2024-36883",
"CVE-2024-36886",
"CVE-2024-36889",
"CVE-2024-36898",
"CVE-2024-36899",
"CVE-2024-36901",
"CVE-2024-36902",
"CVE-2024-36903",
"CVE-2024-36906",
"CVE-2024-36908",
"CVE-2024-36917",
"CVE-2024-36924",
"CVE-2024-36928",
"CVE-2024-36929",
"CVE-2024-36949",
"CVE-2024-36954",
"CVE-2024-36957",
"CVE-2024-36964"
]
}
OESA-2024-1736 (CVE-2021-47229)
Vulnerability from osv_openeuler – Published: 2024-06-21 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:
PCI: aardvark: Fix kernel panic during PIO transfer
Trying to start a new PIO transfer by writing value 0 in PIO_START register when previous transfer has not yet completed (which is indicated by value 1 in PIO_START) causes an External Abort on CPU, which results in kernel panic:
SError Interrupt on CPU0, code 0xbf000002 -- SError
Kernel panic - not syncing: Asynchronous SError Interrupt
To prevent kernel panic, it is required to reject a new PIO transfer when previous one has not finished yet.
If previous PIO transfer is not finished yet, the kernel may issue a new PIO request only if the previous PIO transfer timed out.
In the past the root cause of this issue was incorrectly identified (as it often happens during link retraining or after link down event) and special hack was implemented in Trusted Firmware to catch all SError events in EL3, to ignore errors with code 0xbf000002 and not forwarding any other errors to kernel and instead throw panic from EL3 Trusted Firmware handler.
Links to discussion and patches about this issue: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/?id=3c7dcdac5c50 https://lore.kernel.org/linux-pci/20190316161243.29517-1-repk@triplefau.lt/ https://lore.kernel.org/linux-pci/971be151d24312cc533989a64bd454b4@www.loen.fr/ https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/1541
But the real cause was the fact that during link retraining or after link down event the PIO transfer may take longer time, up to the 1.44s until it times out. This increased probability that a new PIO transfer would be issued by kernel while previous one has not finished yet.
After applying this change into the kernel, it is possible to revert the mentioned TF-A hack and SError events do not have to be caught in TF-A EL3.(CVE-2021-47229)
In the Linux kernel, the following vulnerability has been resolved:
phy: phy-mtk-tphy: Fix some resource leaks in mtk_phy_init()
Use clk_disable_unprepare() in the error path of mtk_phy_init() to fix some resource leaks.(CVE-2021-47234)
In the Linux kernel, the following vulnerability has been resolved:
net: rds: fix memory leak in rds_recvmsg
Syzbot reported memory leak in rds. The problem was in unputted refcount in case of error.
int rds_recvmsg(struct socket sock, struct msghdr msg, size_t size, int msg_flags) { ...
if (!rds_next_incoming(rs, &inc)) {
...
}
After this "if" inc refcount incremented and
if (rds_cmsg_recv(inc, msg, rs)) {
ret = -EFAULT;
goto out;
}
... out: return ret; }
in case of rds_cmsg_recv() fail the refcount won't be decremented. And it's easy to see from ftrace log, that rds_inc_addref() don't have rds_inc_put() pair in rds_recvmsg() after rds_cmsg_recv()
1) | rds_recvmsg() { 1) 3.721 us | rds_inc_addref(); 1) 3.853 us | rds_message_inc_copy_to_user(); 1) + 10.395 us | rds_cmsg_recv(); 1) + 34.260 us | }(CVE-2021-47249)
In the Linux kernel, the following vulnerability has been resolved:
net: ieee802154: fix null deref in parse dev addr
Fix a logic error that could result in a null deref if the user sets the mode incorrectly for the given addr type.(CVE-2021-47257)
In the Linux kernel, the following vulnerability has been resolved:
usb: fix various gadget panics on 10gbps cabling
usb_assign_descriptors() is called with 5 parameters, the last 4 of which are the usb_descriptor_header for: full-speed (USB1.1 - 12Mbps [including USB1.0 low-speed @ 1.5Mbps), high-speed (USB2.0 - 480Mbps), super-speed (USB3.0 - 5Gbps), super-speed-plus (USB3.1 - 10Gbps).
The differences between full/high/super-speed descriptors are usually substantial (due to changes in the maximum usb block size from 64 to 512 to 1024 bytes and other differences in the specs), while the difference between 5 and 10Gbps descriptors may be as little as nothing (in many cases the same tuning is simply good enough).
However if a gadget driver calls usb_assign_descriptors() with a NULL descriptor for super-speed-plus and is then used on a max 10gbps configuration, the kernel will crash with a null pointer dereference, when a 10gbps capable device port + cable + host port combination shows up. (This wouldn't happen if the gadget max-speed was set to 5gbps, but it of course defaults to the maximum, and there's no real reason to artificially limit it)
The fix is to simply use the 5gbps descriptor as the 10gbps descriptor, if a 10gbps descriptor wasn't provided.
Obviously this won't fix the problem if the 5gbps descriptor is also NULL, but such cases can't be so trivially solved (and any such gadgets are unlikely to be used with USB3 ports any way).(CVE-2021-47267)
In the Linux kernel, the following vulnerability has been resolved:
ALSA: seq: Fix race of snd_seq_timer_open()
The timer instance per queue is exclusive, and snd_seq_timer_open() should have managed the concurrent accesses. It looks as if it's checking the already existing timer instance at the beginning, but it's not right, because there is no protection, hence any later concurrent call of snd_seq_timer_open() may override the timer instance easily. This may result in UAF, as the leftover timer instance can keep running while the queue itself gets closed, as spotted by syzkaller recently.
For avoiding the race, add a proper check at the assignment of tmr->timeri again, and return -EBUSY if it's been already registered.(CVE-2021-47281)
In the Linux kernel, the following vulnerability has been resolved:
igb: Fix use-after-free error during reset
Cleans the next descriptor to watch (next_to_watch) when cleaning the TX ring.
Failure to do so can cause invalid memory accesses. If igb_poll() runs while the controller is reset this can lead to the driver try to free a skb that was already freed.
(The crash is harder to reproduce with the igb driver, but the same potential problem exists as the code is identical to igc)(CVE-2021-47301)
In the Linux kernel, the following vulnerability has been resolved:
net: ti: fix UAF in tlan_remove_one
priv is netdev private data and it cannot be used after free_netdev() call. Using priv after free_netdev() can cause UAF bug. Fix it by moving free_netdev() at the end of the function.(CVE-2021-47310)
In the Linux kernel, the following vulnerability has been resolved:
watchdog: Fix possible use-after-free by calling del_timer_sync()
This driver's remove path calls del_timer(). However, that function does not wait until the timer handler finishes. This means that the timer handler may still be running after the driver's remove function has finished, which would result in a use-after-free.
Fix by calling del_timer_sync(), which makes sure the timer handler has finished, and unable to re-schedule itself.(CVE-2021-47321)
In the Linux kernel, the following vulnerability has been resolved:
misc/libmasm/module: Fix two use after free in ibmasm_init_one
In ibmasm_init_one, it calls ibmasm_init_remote_input_dev(). Inside ibmasm_init_remote_input_dev, mouse_dev and keybd_dev are allocated by input_allocate_device(), and assigned to sp->remote.mouse_dev and sp->remote.keybd_dev respectively.
In the err_free_devices error branch of ibmasm_init_one, mouse_dev and keybd_dev are freed by input_free_device(), and return error. Then the execution runs into error_send_message error branch of ibmasm_init_one, where ibmasm_free_remote_input_dev(sp) is called to unregister the freed sp->remote.mouse_dev and sp->remote.keybd_dev.
My patch add a "error_init_remote" label to handle the error of ibmasm_init_remote_input_dev(), to avoid the uaf bugs.(CVE-2021-47334)
In the Linux kernel, the following vulnerability has been resolved:
media: zr364xx: fix memory leak in zr364xx_start_readpipe
syzbot reported memory leak in zr364xx driver. The problem was in non-freed urb in case of usb_submit_urb() fail.
backtrace: [<ffffffff82baedf6>] kmalloc include/linux/slab.h:561 [inline] [<ffffffff82baedf6>] usb_alloc_urb+0x66/0xe0 drivers/usb/core/urb.c:74 [<ffffffff82f7cce8>] zr364xx_start_readpipe+0x78/0x130 drivers/media/usb/zr364xx/zr364xx.c:1022 [<ffffffff84251dfc>] zr364xx_board_init drivers/media/usb/zr364xx/zr364xx.c:1383 [inline] [<ffffffff84251dfc>] zr364xx_probe+0x6a3/0x851 drivers/media/usb/zr364xx/zr364xx.c:1516 [<ffffffff82bb6507>] usb_probe_interface+0x177/0x370 drivers/usb/core/driver.c:396 [<ffffffff826018a9>] really_probe+0x159/0x500 drivers/base/dd.c:576(CVE-2021-47344)
In the Linux kernel, the following vulnerability has been resolved:
drm/sched: Avoid data corruptions
Wait for all dependencies of a job to complete before killing it to avoid data corruptions.(CVE-2021-47354)
In the Linux kernel, the following vulnerability has been resolved:
net: macb: fix use after free on rmmod
plat_dev->dev->platform_data is released by platform_device_unregister(), use of pclk and hclk is a use-after-free. Since device unregister won't need a clk device we adjust the function call sequence to fix this issue.
[ 31.261225] BUG: KASAN: use-after-free in macb_remove+0x77/0xc6 [macb_pci] [ 31.275563] Freed by task 306: [ 30.276782] platform_device_release+0x25/0x80(CVE-2021-47372)
In the Linux kernel, the following vulnerability has been resolved:
i2c: acpi: fix resource leak in reconfiguration device addition
acpi_i2c_find_adapter_by_handle() calls bus_find_device() which takes a reference on the adapter which is never released which will result in a reference count leak and render the adapter unremovable. Make sure to put the adapter after creating the client in the same manner that we do for OF.
In the Linux kernel, the following vulnerability has been resolved:
net: encx24j600: check error in devm_regmap_init_encx24j600
devm_regmap_init may return error which caused by like out of memory, this will results in null pointer dereference later when reading or writing register:
general protection fault in encx24j600_spi_probe KASAN: null-ptr-deref in range [0x0000000000000090-0x0000000000000097] CPU: 0 PID: 286 Comm: spi-encx24j600- Not tainted 5.15.0-rc2-00142-g9978db750e31-dirty #11 9c53a778c1306b1b02359f3c2bbedc0222cba652 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:regcache_cache_bypass drivers/base/regmap/regcache.c:540 Code: 54 41 89 f4 55 53 48 89 fb 48 83 ec 08 e8 26 94 a8 fe 48 8d bb a0 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 4a 03 00 00 4c 8d ab b0 00 00 00 48 8b ab a0 00 RSP: 0018:ffffc900010476b8 EFLAGS: 00010207 RAX: dffffc0000000000 RBX: fffffffffffffff4 RCX: 0000000000000000 RDX: 0000000000000012 RSI: ffff888002de0000 RDI: 0000000000000094 RBP: ffff888013c9a000 R08: 0000000000000000 R09: fffffbfff3f9cc6a R10: ffffc900010476e8 R11: fffffbfff3f9cc69 R12: 0000000000000001 R13: 000000000000000a R14: ffff888013c9af54 R15: ffff888013c9ad08 FS: 00007ffa984ab580(0000) GS:ffff88801fe00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055a6384136c8 CR3: 000000003bbe6003 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: encx24j600_spi_probe drivers/net/ethernet/microchip/encx24j600.c:459 spi_probe drivers/spi/spi.c:397 really_probe drivers/base/dd.c:517 __driver_probe_device drivers/base/dd.c:751 driver_probe_device drivers/base/dd.c:782 __device_attach_driver drivers/base/dd.c:899 bus_for_each_drv drivers/base/bus.c:427 __device_attach drivers/base/dd.c:971 bus_probe_device drivers/base/bus.c:487 device_add drivers/base/core.c:3364 __spi_add_device drivers/spi/spi.c:599 spi_add_device drivers/spi/spi.c:641 spi_new_device drivers/spi/spi.c:717 new_device_store+0x18c/0x1f1 [spi_stub 4e02719357f1ff33f5a43d00630982840568e85e] dev_attr_store drivers/base/core.c:2074 sysfs_kf_write fs/sysfs/file.c:139 kernfs_fop_write_iter fs/kernfs/file.c:300 new_sync_write fs/read_write.c:508 (discriminator 4) vfs_write fs/read_write.c:594 ksys_write fs/read_write.c:648 do_syscall_64 arch/x86/entry/common.c:50 entry_SYSCALL_64_after_hwframe arch/x86/entry/entry_64.S:113
Add error check in devm_regmap_init_encx24j600 to avoid this situation.(CVE-2021-47440)
In the Linux kernel, the following vulnerability has been resolved:
can: peak_pci: peak_pci_remove(): fix UAF
When remove the module peek_pci, referencing 'chan' again after releasing 'dev' will cause UAF.
Fix this by releasing 'dev' later.
The following log reveals it:
[ 35.961814 ] BUG: KASAN: use-after-free in peak_pci_remove+0x16f/0x270 [peak_pci] [ 35.963414 ] Read of size 8 at addr ffff888136998ee8 by task modprobe/5537 [ 35.965513 ] Call Trace: [ 35.965718 ] dump_stack_lvl+0xa8/0xd1 [ 35.966028 ] print_address_description+0x87/0x3b0 [ 35.966420 ] kasan_report+0x172/0x1c0 [ 35.966725 ] ? peak_pci_remove+0x16f/0x270 [peak_pci] [ 35.967137 ] ? trace_irq_enable_rcuidle+0x10/0x170 [ 35.967529 ] ? peak_pci_remove+0x16f/0x270 [peak_pci] [ 35.967945 ] __asan_report_load8_noabort+0x14/0x20 [ 35.968346 ] peak_pci_remove+0x16f/0x270 [peak_pci] [ 35.968752 ] pci_device_remove+0xa9/0x250(CVE-2021-47456)
In the Linux kernel, the following vulnerability has been resolved:
isdn: mISDN: Fix sleeping function called from invalid context
The driver can call card->isac.release() function from an atomic context.
Fix this by calling this function after releasing the lock.
The following log reveals it:
[ 44.168226 ] BUG: sleeping function called from invalid context at kernel/workqueue.c:3018 [ 44.168941 ] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 5475, name: modprobe [ 44.169574 ] INFO: lockdep is turned off. [ 44.169899 ] irq event stamp: 0 [ 44.170160 ] hardirqs last enabled at (0): [<0000000000000000>] 0x0 [ 44.170627 ] hardirqs last disabled at (0): [<ffffffff814209ed>] copy_process+0x132d/0x3e00 [ 44.171240 ] softirqs last enabled at (0): [<ffffffff81420a1a>] copy_process+0x135a/0x3e00 [ 44.171852 ] softirqs last disabled at (0): [<0000000000000000>] 0x0 [ 44.172318 ] Preemption disabled at: [ 44.172320 ] [<ffffffffa009b0a9>] nj_release+0x69/0x500 [netjet] [ 44.174441 ] Call Trace: [ 44.174630 ] dump_stack_lvl+0xa8/0xd1 [ 44.174912 ] dump_stack+0x15/0x17 [ 44.175166 ] mightsleep+0x3a2/0x510 [ 44.175459 ] ? nj_release+0x69/0x500 [netjet] [ 44.175791 ] might_sleep+0x82/0xe0 [ 44.176063 ] ? start_flush_work+0x20/0x7b0 [ 44.176375 ] start_flush_work+0x33/0x7b0 [ 44.176672 ] ? trace_irq_enable_rcuidle+0x85/0x170 [ 44.177034 ] ? kasan_quarantine_put+0xaa/0x1f0 [ 44.177372 ] ? kasan_quarantine_put+0xaa/0x1f0 [ 44.177711 ] __flush_work+0x11a/0x1a0 [ 44.177991 ] ? flush_work+0x20/0x20 [ 44.178257 ] ? lock_release+0x13c/0x8f0 [ 44.178550 ] ? __kasan_check_write+0x14/0x20 [ 44.178872 ] ? do_raw_spin_lock+0x148/0x360 [ 44.179187 ] ? read_lock_is_recursive+0x20/0x20 [ 44.179530 ] ? __kasan_check_read+0x11/0x20 [ 44.179846 ] ? do_raw_spin_unlock+0x55/0x900 [ 44.180168 ] ? ____kasan_slab_free+0x116/0x140 [ 44.180505 ] ? _raw_spin_unlock_irqrestore+0x41/0x60 [ 44.180878 ] ? skb_queue_purge+0x1a3/0x1c0 [ 44.181189 ] ? kfree+0x13e/0x290 [ 44.181438 ] flush_work+0x17/0x20 [ 44.181695 ] mISDN_freedchannel+0xe8/0x100 [ 44.182006 ] isac_release+0x210/0x260 [mISDNipac] [ 44.182366 ] nj_release+0xf6/0x500 [netjet] [ 44.182685 ] nj_remove+0x48/0x70 [netjet] [ 44.182989 ] pci_device_remove+0xa9/0x250(CVE-2021-47468)
In the Linux kernel, the following vulnerability has been resolved:
comedi: vmk80xx: fix bulk-buffer overflow
The driver is using endpoint-sized buffers but must not assume that the tx and rx buffers are of equal size or a malicious device could overflow the slab-allocated receive buffer when doing bulk transfers.(CVE-2021-47474)
In the Linux kernel, the following vulnerability has been resolved:
net: batman-adv: fix error handling
Syzbot reported ODEBUG warning in batadv_nc_mesh_free(). The problem was in wrong error handling in batadv_mesh_init().
Before this patch batadv_mesh_init() was calling batadv_mesh_free() in case of any batadv_*_init() calls failure. This approach may work well, when there is some kind of indicator, which can tell which parts of batadv are initialized; but there isn't any.
All written above lead to cleaning up uninitialized fields. Even if we hide ODEBUG warning by initializing bat_priv->nc.work, syzbot was able to hit GPF in batadv_nc_purge_paths(), because hash pointer in still NULL. [1]
To fix these bugs we can unwind batadv_init() calls one by one. It is good approach for 2 reasons: 1) It fixes bugs on error handling path 2) It improves the performance, since we won't call unneeded batadv_free() functions.
So, this patch makes all batadv_init() clean up all allocated memory before returning with an error to no call correspoing batadv_free() and open-codes batadv_mesh_free() with proper order to avoid touching uninitialized fields.(CVE-2021-47482)
In the Linux kernel, the following vulnerability has been resolved:
regmap: Fix possible double-free in regcache_rbtree_exit()
In regcache_rbtree_insert_to_block(), when 'present' realloc failed, the 'blk' which is supposed to assign to 'rbnode->block' will be freed, so 'rbnode->block' points a freed memory, in the error handling path of regcache_rbtree_init(), 'rbnode->block' will be freed again in regcache_rbtree_exit(), KASAN will report double-free as follows:
BUG: KASAN: double-free or invalid-free in kfree+0xce/0x390 Call Trace: slab_free_freelist_hook+0x10d/0x240 kfree+0xce/0x390 regcache_rbtree_exit+0x15d/0x1a0 regcache_rbtree_init+0x224/0x2c0 regcache_init+0x88d/0x1310 __regmap_init+0x3151/0x4a80 __devm_regmap_init+0x7d/0x100 madera_spi_probe+0x10f/0x333 [madera_spi] spi_probe+0x183/0x210 really_probe+0x285/0xc30
To fix this, moving up the assignment of rbnode->block to immediately after the reallocation has succeeded so that the data structure stays valid even if the second reallocation fails.(CVE-2021-47483)
In the Linux kernel, the following vulnerability has been resolved:
IB/qib: Protect from buffer overflow in struct qib_user_sdma_pkt fields
Overflowing either addrlimit or bytes_togo can allow userspace to trigger a buffer overflow of kernel memory. Check for overflows in all the places doing math on user controlled buffers.(CVE-2021-47485)
In the Linux kernel, the following vulnerability has been resolved:
net/tls: Fix flipped sign in tls_err_abort() calls
sk->sk_err appears to expect a positive value, a convention that ktls doesn't always follow and that leads to memory corruption in other code. For instance,
[kworker]
tls_encrypt_done(..., err=<negative error from crypto request>)
tls_err_abort(.., err)
sk->sk_err = err;
[task]
splice_from_pipe_feed
...
tls_sw_do_sendpage
if (sk->sk_err) {
ret = -sk->sk_err; // ret is positive
splice_from_pipe_feed (continued)
ret = actor(...) // ret is still positive and interpreted as bytes
// written, resulting in underflow of buf->len and
// sd->len, leading to huge buf->offset and bogus
// addresses computed in later calls to actor()
Fix all tls_err_abort() callers to pass a negative error code consistently and centralize the error-prone sign flip there, throwing in a warning to catch future misuse and uninlining the function so it really does only warn once.(CVE-2021-47496)
In the Linux kernel, the following vulnerability has been resolved:
ALSA: pcm: oss: Limit the period size to 16MB
Set the practical limit to the period size (the fragment shift in OSS) instead of a full 31bit; a too large value could lead to the exhaust of memory as we allocate temporary buffers of the period size, too.
As of this patch, we set to 16MB limit, which should cover all use cases.(CVE-2021-47509)
In the Linux kernel, the following vulnerability has been resolved:
nfp: Fix memory leak in nfp_cpp_area_cache_add()
In line 800 (#1), nfp_cpp_area_alloc() allocates and initializes a CPP area structure. But in line 807 (#2), when the cache is allocated failed, this CPP area structure is not freed, which will result in memory leak.
We can fix it by freeing the CPP area when the cache is allocated failed (#2).
792 int nfp_cpp_area_cache_add(struct nfp_cpp cpp, size_t size) 793 { 794 struct nfp_cpp_area_cache cache; 795 struct nfp_cpp_area *area;
800 area = nfp_cpp_area_alloc(cpp, NFP_CPP_ID(7, NFP_CPP_ACTION_RW, 0), 801 0, size); // #1: allocates and initializes
802 if (!area) 803 return -ENOMEM;
805 cache = kzalloc(sizeof(*cache), GFP_KERNEL); 806 if (!cache) 807 return -ENOMEM; // #2: missing free
817 return 0; 818 }(CVE-2021-47516)
In the Linux kernel, the following vulnerability has been resolved:
staging: rtl8192e: Fix use after free in _rtl92e_pci_disconnect()
The free_rtllib() function frees the "dev" pointer so there is use after free on the next line. Re-arrange things to avoid that.(CVE-2021-47571)
In the Linux kernel, the following vulnerability has been resolved:
soc: brcmstb: pm-arm: Fix refcount leak and __iomem leak bugs
In brcmstb_pm_probe(), there are two kinds of leak bugs:
(1) we need to add of_node_put() when for_each__matching_node() breaks (2) we need to add iounmap() for each iomap in fail path(CVE-2022-48693)
In the Linux kernel, the following vulnerability has been resolved:
mmc: mmc_spi: fix error handling in mmc_spi_probe()
If mmc_add_host() fails, it doesn't need to call mmc_remove_host(), or it will cause null-ptr-deref, because of deleting a not added device in mmc_remove_host().
To fix this, goto label 'fail_glue_init', if mmc_add_host() fails, and change the label 'fail_add_host' to 'fail_gpiod_request'.(CVE-2023-52708)
In the Linux kernel, the following vulnerability has been resolved:
net: USB: Fix wrong-direction WARNING in plusb.c
The syzbot fuzzer detected a bug in the plusb network driver: A zero-length control-OUT transfer was treated as a read instead of a write. In modern kernels this error provokes a WARNING:
usb 1-1: BOGUS control dir, pipe 80000280 doesn't match bRequestType c0 WARNING: CPU: 0 PID: 4645 at drivers/usb/core/urb.c:411 usb_submit_urb+0x14a7/0x1880 drivers/usb/core/urb.c:411 Modules linked in: CPU: 1 PID: 4645 Comm: dhcpcd Not tainted 6.2.0-rc6-syzkaller-00050-g9f266ccaa2f5 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/12/2023 RIP: 0010:usb_submit_urb+0x14a7/0x1880 drivers/usb/core/urb.c:411 ... Call Trace: <TASK> usb_start_wait_urb+0x101/0x4b0 drivers/usb/core/message.c:58 usb_internal_control_msg drivers/usb/core/message.c:102 [inline] usb_control_msg+0x320/0x4a0 drivers/usb/core/message.c:153 __usbnet_read_cmd+0xb9/0x390 drivers/net/usb/usbnet.c:2010 usbnet_read_cmd+0x96/0xf0 drivers/net/usb/usbnet.c:2068 pl_vendor_req drivers/net/usb/plusb.c:60 [inline] pl_set_QuickLink_features drivers/net/usb/plusb.c:75 [inline] pl_reset+0x2f/0xf0 drivers/net/usb/plusb.c:85 usbnet_open+0xcc/0x5d0 drivers/net/usb/usbnet.c:889 __dev_open+0x297/0x4d0 net/core/dev.c:1417 __dev_change_flags+0x587/0x750 net/core/dev.c:8530 dev_change_flags+0x97/0x170 net/core/dev.c:8602 devinet_ioctl+0x15a2/0x1d70 net/ipv4/devinet.c:1147 inet_ioctl+0x33f/0x380 net/ipv4/af_inet.c:979 sock_do_ioctl+0xcc/0x230 net/socket.c:1169 sock_ioctl+0x1f8/0x680 net/socket.c:1286 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl fs/ioctl.c:856 [inline] __x64_sys_ioctl+0x197/0x210 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd
The fix is to call usbnet_write_cmd() instead of usbnet_read_cmd() and remove the USB_DIR_IN flag.(CVE-2023-52742)
In the Linux kernel, the following vulnerability has been resolved:
IB/hfi1: Restore allocated resources on failed copyout
Fix a resource leak if an error occurs.(CVE-2023-52747)
In the Linux kernel, the following vulnerability has been resolved:
media: gspca: cpia1: shift-out-of-bounds in set_flicker
Syzkaller reported the following issue: UBSAN: shift-out-of-bounds in drivers/media/usb/gspca/cpia1.c:1031:27 shift exponent 245 is too large for 32-bit type 'int'
When the value of the variable "sd->params.exposure.gain" exceeds the number of bits in an integer, a shift-out-of-bounds error is reported. It is triggered because the variable "currentexp" cannot be left-shifted by more than the number of bits in an integer. In order to avoid invalid range during left-shift, the conditional expression is added.(CVE-2023-52764)
In the Linux kernel, the following vulnerability has been resolved:
fs/jfs: Add check for negative db_l2nbperpage
l2nbperpage is log2(number of blks per page), and the minimum legal value should be 0, not negative.
In the case of l2nbperpage being negative, an error will occur when subsequently used as shift exponent.
Syzbot reported this bug:
UBSAN: shift-out-of-bounds in fs/jfs/jfs_dmap.c:799:12 shift exponent -16777216 is negative(CVE-2023-52810)
In the Linux kernel, the following vulnerability has been resolved:
locking/ww_mutex/test: Fix potential workqueue corruption
In some cases running with the test-ww_mutex code, I was seeing odd behavior where sometimes it seemed flush_workqueue was returning before all the work threads were finished.
Often this would cause strange crashes as the mutexes would be freed while they were being used.
Looking at the code, there is a lifetime problem as the controlling thread that spawns the work allocates the "struct stress" structures that are passed to the workqueue threads. Then when the workqueue threads are finished, they free the stress struct that was passed to them.
Unfortunately the workqueue work_struct node is in the stress struct. Which means the work_struct is freed before the work thread returns and while flush_workqueue is waiting.
It seems like a better idea to have the controlling thread both allocate and free the stress structures, so that we can be sure we don't corrupt the workqueue by freeing the structure prematurely.
So this patch reworks the test to do so, and with this change I no longer see the early flush_workqueue returns.(CVE-2023-52836)
In the Linux kernel, the following vulnerability has been resolved:
llc: verify mac len before reading mac header
LLC reads the mac header with eth_hdr without verifying that the skb has an Ethernet header.
Syzbot was able to enter llc_rcv on a tun device. Tun can insert packets without mac len and with user configurable skb->protocol (passing a tun_pi header when not configuring IFF_NO_PI).
BUG: KMSAN: uninit-value in llc_station_ac_send_test_r net/llc/llc_station.c:81 [inline]
BUG: KMSAN: uninit-value in llc_station_rcv+0x6fb/0x1290 net/llc/llc_station.c:111
llc_station_ac_send_test_r net/llc/llc_station.c:81 [inline]
llc_station_rcv+0x6fb/0x1290 net/llc/llc_station.c:111
llc_rcv+0xc5d/0x14a0 net/llc/llc_input.c:218
__netif_receive_skb_one_core net/core/dev.c:5523 [inline]
__netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5637
netif_receive_skb_internal net/core/dev.c:5723 [inline]
netif_receive_skb+0x58/0x660 net/core/dev.c:5782
tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555
tun_get_user+0x54c5/0x69c0 drivers/net/tun.c:2002
Add a mac_len test before all three eth_hdr(skb) calls under net/llc.
There are further uses in include/net/llc_pdu.h. All these are protected by a test skb->protocol == ETH_P_802_2. Which does not protect against this tun scenario.
But the mac_len test added in this patch in llc_fixup_skb will indirectly protect those too. That is called from llc_rcv before any other LLC code.
It is tempting to just add a blanket mac_len check in llc_rcv, but not sure whether that could break valid LLC paths that do not assume an Ethernet header. 802.2 LLC may be used on top of non-802.3 protocols in principle. The below referenced commit shows that used to, on top of Token Ring.
At least one of the three eth_hdr uses goes back to before the start of git history. But the one that syzbot exercises is introduced in this commit. That commit is old enough (2008), that effectively all stable kernels should receive this.(CVE-2023-52843)
In the Linux kernel, the following vulnerability has been resolved:
clk: mediatek: clk-mt2701: Add check for mtk_alloc_clk_data
Add the check for the return value of mtk_alloc_clk_data() in order to avoid NULL pointer dereference.(CVE-2023-52875)
In the Linux kernel, the following vulnerability has been resolved:
tty: n_gsm: require CAP_NET_ADMIN to attach N_GSM0710 ldisc
Any unprivileged user can attach N_GSM0710 ldisc, but it requires CAP_NET_ADMIN to create a GSM network anyway.
Require initial namespace CAP_NET_ADMIN to do that.(CVE-2023-52880)
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Prevent deadlock while disabling aRFS
When disabling aRFS under the priv->state_lock, any scheduled
aRFS works are canceled using the cancel_work_sync function,
which waits for the work to end if it has already started.
However, while waiting for the work handler, the handler will
try to acquire the state_lock which is already acquired.
The worker acquires the lock to delete the rules if the state is down, which is not the worker's responsibility since disabling aRFS deletes the rules.
Add an aRFS state variable, which indicates whether the aRFS is enabled and prevent adding rules when the aRFS is disabled.
Kernel log:
====================================================== WARNING: possible circular locking dependency detected 6.7.0-rc4_net_next_mlx5_5483eb2 #1 Tainted: G I
ethtool/386089 is trying to acquire lock: ffff88810f21ce68 ((work_completion)(&rule->arfs_work)){+.+.}-{0:0}, at: __flush_work+0x74/0x4e0
but task is already holding lock: ffff8884a1808cc0 (&priv->state_lock){+.+.}-{3:3}, at: mlx5e_ethtool_set_channels+0x53/0x200 [mlx5_core]
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&priv->state_lock){+.+.}-{3:3}: __mutex_lock+0x80/0xc90 arfs_handle_work+0x4b/0x3b0 [mlx5_core] process_one_work+0x1dc/0x4a0 worker_thread+0x1bf/0x3c0 kthread+0xd7/0x100 ret_from_fork+0x2d/0x50 ret_from_fork_asm+0x11/0x20
-> #0 ((work_completion)(&rule->arfs_work)){+.+.}-{0:0}: __lock_acquire+0x17b4/0x2c80 lock_acquire+0xd0/0x2b0 __flush_work+0x7a/0x4e0 __cancel_work_timer+0x131/0x1c0 arfs_del_rules+0x143/0x1e0 [mlx5_core] mlx5e_arfs_disable+0x1b/0x30 [mlx5_core] mlx5e_ethtool_set_channels+0xcb/0x200 [mlx5_core] ethnl_set_channels+0x28f/0x3b0 ethnl_default_set_doit+0xec/0x240 genl_family_rcv_msg_doit+0xd0/0x120 genl_rcv_msg+0x188/0x2c0 netlink_rcv_skb+0x54/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x1a1/0x270 netlink_sendmsg+0x214/0x460 __sock_sendmsg+0x38/0x60 __sys_sendto+0x113/0x170 __x64_sys_sendto+0x20/0x30 do_syscall_64+0x40/0xe0 entry_SYSCALL_64_after_hwframe+0x46/0x4e
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&priv->state_lock); lock((work_completion)(&rule->arfs_work)); lock(&priv->state_lock); lock((work_completion)(&rule->arfs_work));
*** DEADLOCK ***
3 locks held by ethtool/386089: #0: ffffffff82ea7210 (cb_lock){++++}-{3:3}, at: genl_rcv+0x15/0x40 #1: ffffffff82e94c88 (rtnl_mutex){+.+.}-{3:3}, at: ethnl_default_set_doit+0xd3/0x240 #2: ffff8884a1808cc0 (&priv->state_lock){+.+.}-{3:3}, at: mlx5e_ethtool_set_channels+0x53/0x200 [mlx5_core]
stack backtrace: CPU: 15 PID: 386089 Comm: ethtool Tainted: G I 6.7.0-rc4_net_next_mlx5_5483eb2 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x60/0xa0 check_noncircular+0x144/0x160 __lock_acquire+0x17b4/0x2c80 lock_acquire+0xd0/0x2b0 ? __flush_work+0x74/0x4e0 ? save_trace+0x3e/0x360 ? __flush_work+0x74/0x4e0 __flush_work+0x7a/0x4e0 ? __flush_work+0x74/0x4e0 ? __lock_acquire+0xa78/0x2c80 ? lock_acquire+0xd0/0x2b0 ? mark_held_locks+0x49/0x70 __cancel_work_timer+0x131/0x1c0 ? mark_held_locks+0x49/0x70 arfs_del_rules+0x143/0x1e0 [mlx5_core] mlx5e_arfs_disable+0x1b/0x30 [mlx5_core] mlx5e_ethtool_set_channels+0xcb/0x200 [mlx5_core] ethnl_set_channels+0x28f/0x3b0 ethnl_default_set_doit+0xec/0x240 genl_family_rcv_msg_doit+0xd0/0x120 genl_rcv_msg+0x188/0x2c0 ? ethn ---truncated---(CVE-2024-27014)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: Fix potential data-race in __nft_obj_type_get()
nft_unregister_obj() can concurrent with __nft_obj_type_get(), and there is not any protection when iterate over nf_tables_objects list in __nft_obj_type_get(). Therefore, there is potential data-race of nf_tables_objects list entry.
Use list_for_each_entry_rcu() to iterate over nf_tables_objects list in __nft_obj_type_get(), and use rcu_read_lock() in the caller nft_obj_type_get() to protect the entire type query process.(CVE-2024-27019)
In the Linux kernel, the following vulnerability has been resolved:
phonet/pep: fix racy skb_queue_empty() use
The receive queues are protected by their respective spin-lock, not the socket lock. This could lead to skb_peek() unexpectedly returning NULL or a pointer to an already dequeued socket buffer.(CVE-2024-27402)
In the Linux kernel, the following vulnerability has been resolved:
soc: fsl: qbman: Use raw spinlock for cgr_lock
smp_call_function always runs its callback in hard IRQ context, even on PREEMPT_RT, where spinlocks can sleep. So we need to use a raw spinlock for cgr_lock to ensure we aren't waiting on a sleeping task.
Although this bug has existed for a while, it was not apparent until commit ef2a8d5478b9 ("net: dpaa: Adjust queue depth on rate change") which invokes smp_call_function_single via qman_update_cgr_safe every time a link goes up or down.(CVE-2024-35819)
In the Linux kernel, the following vulnerability has been resolved:
ubifs: Set page uptodate in the correct place
Page cache reads are lockless, so setting the freshly allocated page uptodate before we've overwritten it with the data it's supposed to have in it will allow a simultaneous reader to see old data. Move the call to SetPageUptodate into ubifs_write_end(), which is after we copied the new data into the page.(CVE-2024-35821)
In the Linux kernel, the following vulnerability has been resolved:
wifi: libertas: fix some memleaks in lbs_allocate_cmd_buffer()
In the for statement of lbs_allocate_cmd_buffer(), if the allocation of cmdarray[i].cmdbuf fails, both cmdarray and cmdarray[i].cmdbuf needs to be freed. Otherwise, there will be memleaks in lbs_allocate_cmd_buffer().(CVE-2024-35828)
In the Linux kernel, the following vulnerability has been resolved:
tcp: properly terminate timers for kernel sockets
We had various syzbot reports about tcp timers firing after the corresponding netns has been dismantled.
Fortunately Josef Bacik could trigger the issue more often, and could test a patch I wrote two years ago.
When TCP sockets are closed, we call inet_csk_clear_xmit_timers() to 'stop' the timers.
inet_csk_clear_xmit_timers() can be called from any context, including when socket lock is held. This is the reason it uses sk_stop_timer(), aka del_timer(). This means that ongoing timers might finish much later.
For user sockets, this is fine because each running timer holds a reference on the socket, and the user socket holds a reference on the netns.
For kernel sockets, we risk that the netns is freed before timer can complete, because kernel sockets do not hold reference on the netns.
This patch adds inet_csk_clear_xmit_timers_sync() function that using sk_stop_timer_sync() to make sure all timers are terminated before the kernel socket is released. Modules using kernel sockets close them in their netns exit() handler.
Also add sock_not_owned_by_me() helper to get LOCKDEP support : inet_csk_clear_xmit_timers_sync() must not be called while socket lock is held.
It is very possible we can revert in the future commit 3a58f13a881e ("net: rds: acquire refcount on TCP sockets") which attempted to solve the issue in rds only. (net/smc/af_smc.c and net/mptcp/subflow.c have similar code)
We probably can remove the check_net() tests from tcp_out_of_resources() and __tcp_close() in the future.(CVE-2024-35910)
In the Linux kernel, the following vulnerability has been resolved:
btrfs: send: handle path ref underflow in header iterate_inode_ref()
Change BUG_ON to proper error handling if building the path buffer fails. The pointers are not printed so we don't accidentally leak kernel addresses.(CVE-2024-35935)
In the Linux kernel, the following vulnerability has been resolved:
wifi: cfg80211: check A-MSDU format more carefully
If it looks like there's another subframe in the A-MSDU but the header isn't fully there, we can end up reading data out of bounds, only to discard later. Make this a bit more careful and check if the subframe header can even be present.(CVE-2024-35937)
In the Linux kernel, the following vulnerability has been resolved:
dyndbg: fix old BUG_ON in >control parser
Fix a BUG_ON from 2009. Even if it looks "unreachable" (I didn't really look), lets make sure by removing it, doing pr_err and return -EINVAL instead.(CVE-2024-35947)
In the Linux kernel, the following vulnerability has been resolved:
batman-adv: Avoid infinite loop trying to resize local TT
If the MTU of one of an attached interface becomes too small to transmit the local translation table then it must be resized to fit inside all fragments (when enabled) or a single packet.
But if the MTU becomes too low to transmit even the header + the VLAN specific part then the resizing of the local TT will never succeed. This can for example happen when the usable space is 110 bytes and 11 VLANs are on top of batman-adv. In this case, at least 116 byte would be needed. There will just be an endless spam of
batman_adv: batadv0: Forced to purge local tt entries to fit new maximum fragment MTU (110)
in the log but the function will never finish. Problem here is that the timeout will be halved all the time and will then stagnate at 0 and therefore never be able to reduce the table even more.
There are other scenarios possible with a similar result. The number of BATADV_TT_CLIENT_NOPURGE entries in the local TT can for example be too high to fit inside a packet. Such a scenario can therefore happen also with only a single VLAN + 7 non-purgable addresses - requiring at least 120 bytes.
While this should be handled proactively when:
- interface with too low MTU is added
- VLAN is added
- non-purgeable local mac is added
- MTU of an attached interface is reduced
- fragmentation setting gets disabled (which most likely requires dropping attached interfaces)
not all of these scenarios can be prevented because batman-adv is only consuming events without the the possibility to prevent these actions (non-purgable MAC address added, MTU of an attached interface is reduced). It is therefore necessary to also make sure that the code is able to handle also the situations when there were already incompatible system configuration are present.(CVE-2024-35982)
In the Linux kernel, the following vulnerability has been resolved:
tty: n_gsm: fix possible out-of-bounds in gsm0_receive()
Assuming the following: - side A configures the n_gsm in basic option mode - side B sends the header of a basic option mode frame with data length 1 - side A switches to advanced option mode - side B sends 2 data bytes which exceeds gsm->len Reason: gsm->len is not used in advanced option mode. - side A switches to basic option mode - side B keeps sending until gsm0_receive() writes past gsm->buf Reason: Neither gsm->state nor gsm->len have been reset after reconfiguration.
Fix this by changing gsm->count to gsm->len comparison from equal to less than. Also add upper limit checks against the constant MAX_MRU in gsm0_receive() and gsm1_receive() to harden against memory corruption of gsm->len and gsm->mru.
All other checks remain as we still need to limit the data according to the user configuration and actual payload size.(CVE-2024-36016)
In the Linux kernel, the following vulnerability has been resolved:
tipc: fix UAF in error path
Sam Page (sam4k) working with Trend Micro Zero Day Initiative reported a UAF in the tipc_buf_append() error path:
BUG: KASAN: slab-use-after-free in kfree_skb_list_reason+0x47e/0x4c0 linux/net/core/skbuff.c:1183 Read of size 8 at addr ffff88804d2a7c80 by task poc/8034
CPU: 1 PID: 8034 Comm: poc Not tainted 6.8.2 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-debian-1.16.0-5 04/01/2014 Call Trace: <IRQ> __dump_stack linux/lib/dump_stack.c:88 dump_stack_lvl+0xd9/0x1b0 linux/lib/dump_stack.c:106 print_address_description linux/mm/kasan/report.c:377 print_report+0xc4/0x620 linux/mm/kasan/report.c:488 kasan_report+0xda/0x110 linux/mm/kasan/report.c:601 kfree_skb_list_reason+0x47e/0x4c0 linux/net/core/skbuff.c:1183 skb_release_data+0x5af/0x880 linux/net/core/skbuff.c:1026 skb_release_all linux/net/core/skbuff.c:1094 __kfree_skb linux/net/core/skbuff.c:1108 kfree_skb_reason+0x12d/0x210 linux/net/core/skbuff.c:1144 kfree_skb linux/./include/linux/skbuff.h:1244 tipc_buf_append+0x425/0xb50 linux/net/tipc/msg.c:186 tipc_link_input+0x224/0x7c0 linux/net/tipc/link.c:1324 tipc_link_rcv+0x76e/0x2d70 linux/net/tipc/link.c:1824 tipc_rcv+0x45f/0x10f0 linux/net/tipc/node.c:2159 tipc_udp_recv+0x73b/0x8f0 linux/net/tipc/udp_media.c:390 udp_queue_rcv_one_skb+0xad2/0x1850 linux/net/ipv4/udp.c:2108 udp_queue_rcv_skb+0x131/0xb00 linux/net/ipv4/udp.c:2186 udp_unicast_rcv_skb+0x165/0x3b0 linux/net/ipv4/udp.c:2346 __udp4_lib_rcv+0x2594/0x3400 linux/net/ipv4/udp.c:2422 ip_protocol_deliver_rcu+0x30c/0x4e0 linux/net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x2e4/0x520 linux/net/ipv4/ip_input.c:233 NF_HOOK linux/./include/linux/netfilter.h:314 NF_HOOK linux/./include/linux/netfilter.h:308 ip_local_deliver+0x18e/0x1f0 linux/net/ipv4/ip_input.c:254 dst_input linux/./include/net/dst.h:461 ip_rcv_finish linux/net/ipv4/ip_input.c:449 NF_HOOK linux/./include/linux/netfilter.h:314 NF_HOOK linux/./include/linux/netfilter.h:308 ip_rcv+0x2c5/0x5d0 linux/net/ipv4/ip_input.c:569 __netif_receive_skb_one_core+0x199/0x1e0 linux/net/core/dev.c:5534 __netif_receive_skb+0x1f/0x1c0 linux/net/core/dev.c:5648 process_backlog+0x101/0x6b0 linux/net/core/dev.c:5976 __napi_poll.constprop.0+0xba/0x550 linux/net/core/dev.c:6576 napi_poll linux/net/core/dev.c:6645 net_rx_action+0x95a/0xe90 linux/net/core/dev.c:6781 __do_softirq+0x21f/0x8e7 linux/kernel/softirq.c:553 do_softirq linux/kernel/softirq.c:454 do_softirq+0xb2/0xf0 linux/kernel/softirq.c:441 </IRQ> <TASK> __local_bh_enable_ip+0x100/0x120 linux/kernel/softirq.c:381 local_bh_enable linux/./include/linux/bottom_half.h:33 rcu_read_unlock_bh linux/./include/linux/rcupdate.h:851 __dev_queue_xmit+0x871/0x3ee0 linux/net/core/dev.c:4378 dev_queue_xmit linux/./include/linux/netdevice.h:3169 neigh_hh_output linux/./include/net/neighbour.h:526 neigh_output linux/./include/net/neighbour.h:540 ip_finish_output2+0x169f/0x2550 linux/net/ipv4/ip_output.c:235 __ip_finish_output linux/net/ipv4/ip_output.c:313 __ip_finish_output+0x49e/0x950 linux/net/ipv4/ip_output.c:295 ip_finish_output+0x31/0x310 linux/net/ipv4/ip_output.c:323 NF_HOOK_COND linux/./include/linux/netfilter.h:303 ip_output+0x13b/0x2a0 linux/net/ipv4/ip_output.c:433 dst_output linux/./include/net/dst.h:451 ip_local_out linux/net/ipv4/ip_output.c:129 ip_send_skb+0x3e5/0x560 linux/net/ipv4/ip_output.c:1492 udp_send_skb+0x73f/0x1530 linux/net/ipv4/udp.c:963 udp_sendmsg+0x1a36/0x2b40 linux/net/ipv4/udp.c:1250 inet_sendmsg+0x105/0x140 linux/net/ipv4/af_inet.c:850 sock_sendmsg_nosec linux/net/socket.c:730 __sock_sendmsg linux/net/socket.c:745 __sys_sendto+0x42c/0x4e0 linux/net/socket.c:2191 __do_sys_sendto linux/net/socket.c:2203 __se_sys_sendto linux/net/socket.c:2199 __x64_sys_sendto+0xe0/0x1c0 linux/net/socket.c:2199 do_syscall_x64 linux/arch/x86/entry/common.c:52 do_syscall_ ---truncated---(CVE-2024-36886)
In the Linux kernel, the following vulnerability has been resolved:
ipv6: prevent NULL dereference in ip6_output()
According to syzbot, there is a chance that ip6_dst_idev() returns NULL in ip6_output(). Most places in IPv6 stack deal with a NULL idev just fine, but not here.
syzbot reported:
general protection fault, probably for non-canonical address 0xdffffc00000000bc: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x00000000000005e0-0x00000000000005e7] CPU: 0 PID: 9775 Comm: syz-executor.4 Not tainted 6.9.0-rc5-syzkaller-00157-g6a30653b604a #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 RIP: 0010:ip6_output+0x231/0x3f0 net/ipv6/ip6_output.c:237 Code: 3c 1e 00 49 89 df 74 08 4c 89 ef e8 19 58 db f7 48 8b 44 24 20 49 89 45 00 49 89 c5 48 8d 9d e0 05 00 00 48 89 d8 48 c1 e8 03 <42> 0f b6 04 38 84 c0 4c 8b 74 24 28 0f 85 61 01 00 00 8b 1b 31 ff RSP: 0018:ffffc9000927f0d8 EFLAGS: 00010202 RAX: 00000000000000bc RBX: 00000000000005e0 RCX: 0000000000040000 RDX: ffffc900131f9000 RSI: 0000000000004f47 RDI: 0000000000004f48 RBP: 0000000000000000 R08: ffffffff8a1f0b9a R09: 1ffffffff1f51fad R10: dffffc0000000000 R11: fffffbfff1f51fae R12: ffff8880293ec8c0 R13: ffff88805d7fc000 R14: 1ffff1100527d91a R15: dffffc0000000000 FS: 00007f135c6856c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000080 CR3: 0000000064096000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> NF_HOOK include/linux/netfilter.h:314 [inline] ip6_xmit+0xefe/0x17f0 net/ipv6/ip6_output.c:358 sctp_v6_xmit+0x9f2/0x13f0 net/sctp/ipv6.c:248 sctp_packet_transmit+0x26ad/0x2ca0 net/sctp/output.c:653 sctp_packet_singleton+0x22c/0x320 net/sctp/outqueue.c:783 sctp_outq_flush_ctrl net/sctp/outqueue.c:914 [inline] sctp_outq_flush+0x6d5/0x3e20 net/sctp/outqueue.c:1212 sctp_side_effects net/sctp/sm_sideeffect.c:1198 [inline] sctp_do_sm+0x59cc/0x60c0 net/sctp/sm_sideeffect.c:1169 sctp_primitive_ASSOCIATE+0x95/0xc0 net/sctp/primitive.c:73 __sctp_connect+0x9cd/0xe30 net/sctp/socket.c:1234 sctp_connect net/sctp/socket.c:4819 [inline] sctp_inet_connect+0x149/0x1f0 net/sctp/socket.c:4834 __sys_connect_file net/socket.c:2048 [inline] __sys_connect+0x2df/0x310 net/socket.c:2065 __do_sys_connect net/socket.c:2075 [inline] __se_sys_connect net/socket.c:2072 [inline] __x64_sys_connect+0x7a/0x90 net/socket.c:2072 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2024-36901)
In the Linux kernel, the following vulnerability has been resolved:
tcp: defer shutdown(SEND_SHUTDOWN) for TCP_SYN_RECV sockets
TCP_SYN_RECV state is really special, it is only used by cross-syn connections, mostly used by fuzzers.
In the following crash [1], syzbot managed to trigger a divide by zero in tcp_rcv_space_adjust()
A socket makes the following state transitions, without ever calling tcp_init_transfer(), meaning tcp_init_buffer_space() is also not called.
TCP_CLOSE
connect() TCP_SYN_SENT TCP_SYN_RECV shutdown() -> tcp_shutdown(sk, SEND_SHUTDOWN) TCP_FIN_WAIT1
To fix this issue, change tcp_shutdown() to not perform a TCP_SYN_RECV -> TCP_FIN_WAIT1 transition, which makes no sense anyway.
When tcp_rcv_state_process() later changes socket state from TCP_SYN_RECV to TCP_ESTABLISH, then look at sk->sk_shutdown to finally enter TCP_FIN_WAIT1 state, and send a FIN packet from a sane socket state.
This means tcp_send_fin() can now be called from BH context, and must use GFP_ATOMIC allocations.
[1] divide error: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 1 PID: 5084 Comm: syz-executor358 Not tainted 6.9.0-rc6-syzkaller-00022-g98369dccd2f8 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 RIP: 0010:tcp_rcv_space_adjust+0x2df/0x890 net/ipv4/tcp_input.c:767 Code: e3 04 4c 01 eb 48 8b 44 24 38 0f b6 04 10 84 c0 49 89 d5 0f 85 a5 03 00 00 41 8b 8e c8 09 00 00 89 e8 29 c8 48 0f af c3 31 d2 <48> f7 f1 48 8d 1c 43 49 8d 96 76 08 00 00 48 89 d0 48 c1 e8 03 48 RSP: 0018:ffffc900031ef3f0 EFLAGS: 00010246 RAX: 0c677a10441f8f42 RBX: 000000004fb95e7e RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000027d4b11f R08: ffffffff89e535a4 R09: 1ffffffff25e6ab7 R10: dffffc0000000000 R11: ffffffff8135e920 R12: ffff88802a9f8d30 R13: dffffc0000000000 R14: ffff88802a9f8d00 R15: 1ffff1100553f2da FS: 00005555775c0380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f1155bf2304 CR3: 000000002b9f2000 CR4: 0000000000350ef0 Call Trace: <TASK> tcp_recvmsg_locked+0x106d/0x25a0 net/ipv4/tcp.c:2513 tcp_recvmsg+0x25d/0x920 net/ipv4/tcp.c:2578 inet6_recvmsg+0x16a/0x730 net/ipv6/af_inet6.c:680 sock_recvmsg_nosec net/socket.c:1046 [inline] sock_recvmsg+0x109/0x280 net/socket.c:1068 _sysrecvmsg+0x1db/0x470 net/socket.c:2803 _sys_recvmsg net/socket.c:2845 [inline] do_recvmmsg+0x474/0xae0 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+0x199/0x250 net/socket.c:3034 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7faeb6363db9 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 c1 17 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffcc1997168 EFLAGS: 00000246 ORIG_RAX: 000000000000012b RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007faeb6363db9 RDX: 0000000000000001 RSI: 0000000020000bc0 RDI: 0000000000000005 RBP: 0000000000000000 R08: 0000000000000000 R09: 000000000000001c R10: 0000000000000122 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000001(CVE-2024-36905)
In the Linux kernel, the following vulnerability has been resolved:
scsi: bnx2fc: Remove spin_lock_bh while releasing resources after upload
The session resources are used by FW and driver when session is offloaded, once session is uploaded these resources are not used. The lock is not required as these fields won't be used any longer. The offload and upload calls are sequential, hence lock is not required.
This will suppress following BUG_ON():
[ 449.843143] ------------[ cut here ]------------ [ 449.848302] kernel BUG at mm/vmalloc.c:2727! [ 449.853072] invalid opcode: 0000 [#1] PREEMPT SMP PTI [ 449.858712] CPU: 5 PID: 1996 Comm: kworker/u24:2 Not tainted 5.14.0-118.el9.x86_64 #1 Rebooting. [ 449.867454] Hardware name: Dell Inc. PowerEdge R730/0WCJNT, BIOS 2.3.4 11/08/2016 [ 449.876966] Workqueue: fc_rport_eq fc_rport_work [libfc] [ 449.882910] RIP: 0010:vunmap+0x2e/0x30 [ 449.887098] Code: 00 65 8b 05 14 a2 f0 4a a9 00 ff ff 00 75 1b 55 48 89 fd e8 34 36 79 00 48 85 ed 74 0b 48 89 ef 31 f6 5d e9 14 fc ff ff 5d c3 <0f> 0b 0f 1f 44 00 00 41 57 41 56 49 89 ce 41 55 49 89 fd 41 54 41 [ 449.908054] RSP: 0018:ffffb83d878b3d68 EFLAGS: 00010206 [ 449.913887] RAX: 0000000080000201 RBX: ffff8f4355133550 RCX: 000000000d400005 [ 449.921843] RDX: 0000000000000001 RSI: 0000000000001000 RDI: ffffb83da53f5000 [ 449.929808] RBP: ffff8f4ac6675800 R08: ffffb83d878b3d30 R09: 00000000000efbdf [ 449.937774] R10: 0000000000000003 R11: ffff8f434573e000 R12: 0000000000001000 [ 449.945736] R13: 0000000000001000 R14: ffffb83da53f5000 R15: ffff8f43d4ea3ae0 [ 449.953701] FS: 0000000000000000(0000) GS:ffff8f529fc80000(0000) knlGS:0000000000000000 [ 449.962732] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 449.969138] CR2: 00007f8cf993e150 CR3: 0000000efbe10003 CR4: 00000000003706e0 [ 449.977102] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 449.985065] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 449.993028] Call Trace: [ 449.995756] __iommu_dma_free+0x96/0x100 [ 450.000139] bnx2fc_free_session_resc+0x67/0x240 [bnx2fc] [ 450.006171] bnx2fc_upload_session+0xce/0x100 [bnx2fc] [ 450.011910] bnx2fc_rport_event_handler+0x9f/0x240 [bnx2fc] [ 450.018136] fc_rport_work+0x103/0x5b0 [libfc] [ 450.023103] process_one_work+0x1e8/0x3c0 [ 450.027581] worker_thread+0x50/0x3b0 [ 450.031669] ? rescuer_thread+0x370/0x370 [ 450.036143] kthread+0x149/0x170 [ 450.039744] ? set_kthread_struct+0x40/0x40 [ 450.044411] ret_from_fork+0x22/0x30 [ 450.048404] Modules linked in: vfat msdos fat xfs nfs_layout_nfsv41_files rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver dm_service_time qedf qed crc8 bnx2fc libfcoe libfc scsi_transport_fc intel_rapl_msr intel_rapl_common x86_pkg_temp_thermal intel_powerclamp dcdbas rapl intel_cstate intel_uncore mei_me pcspkr mei ipmi_ssif lpc_ich ipmi_si fuse zram ext4 mbcache jbd2 loop nfsv3 nfs_acl nfs lockd grace fscache netfs irdma ice sd_mod t10_pi sg ib_uverbs ib_core 8021q garp mrp stp llc mgag200 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt mxm_wmi fb_sys_fops cec crct10dif_pclmul ahci crc32_pclmul bnx2x drm ghash_clmulni_intel libahci rfkill i40e libata megaraid_sas mdio wmi sunrpc lrw dm_crypt dm_round_robin dm_multipath dm_snapshot dm_bufio dm_mirror dm_region_hash dm_log dm_zero dm_mod linear raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx raid6_pq libcrc32c crc32c_intel raid1 raid0 iscsi_ibft squashfs be2iscsi bnx2i cnic uio cxgb4i cxgb4 tls [ 450.048497] libcxgbi libcxgb qla4xxx iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi edd ipmi_devintf ipmi_msghandler [ 450.159753] ---[ end trace 712de2c57c64abc8 ]---(CVE-2024-36919)
In the Linux kernel, the following vulnerability has been resolved:
bna: ensure the copied buf is NUL terminated
Currently, we allocate a nbytes-sized kernel buffer and copy nbytes from userspace to that buffer. Later, we use sscanf on this buffer but we don't ensure that the string is terminated inside the buffer, this can lead to OOB read when using sscanf. Fix this issue by using memdup_user_nul instead of memdup_user.(CVE-2024-36934)
In the Linux kernel, the following vulnerability has been resolved:
scsi: lpfc: Move NPIV's transport unregistration to after resource clean up
There are cases after NPIV deletion where the fabric switch still believes the NPIV is logged into the fabric. This occurs when a vport is unregistered before the Remove All DA_ID CT and LOGO ELS are sent to the fabric.
Currently fc_remove_host(), which calls dev_loss_tmo for all D_IDs including the fabric D_ID, removes the last ndlp reference and frees the ndlp rport object. This sometimes causes the race condition where the final DA_ID and LOGO are skipped from being sent to the fabric switch.
Fix by moving the fc_remove_host() and scsi_remove_host() calls after DA_ID and LOGO are sent.(CVE-2024-36952)
In the Linux kernel, the following vulnerability has been resolved:
drm/vmwgfx: Fix invalid reads in fence signaled events
Correctly set the length of the drm_event to the size of the structure that's actually used.
The length of the drm_event was set to the parent structure instead of to the drm_vmw_event_fence which is supposed to be read. drm_read uses the length parameter to copy the event to the user space thus resuling in oob reads.(CVE-2024-36960)
| URL | Type | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"python3-perf-4.19.90-2406.3.0.0282.oe2003sp4.aarch64.rpm",
"bpftool-4.19.90-2406.3.0.0282.oe2003sp4.aarch64.rpm",
"python2-perf-debuginfo-4.19.90-2406.3.0.0282.oe2003sp4.aarch64.rpm",
"kernel-tools-4.19.90-2406.3.0.0282.oe2003sp4.aarch64.rpm",
"kernel-4.19.90-2406.3.0.0282.oe2003sp4.aarch64.rpm",
"kernel-devel-4.19.90-2406.3.0.0282.oe2003sp4.aarch64.rpm",
"perf-4.19.90-2406.3.0.0282.oe2003sp4.aarch64.rpm",
"kernel-tools-devel-4.19.90-2406.3.0.0282.oe2003sp4.aarch64.rpm",
"perf-debuginfo-4.19.90-2406.3.0.0282.oe2003sp4.aarch64.rpm",
"python3-perf-debuginfo-4.19.90-2406.3.0.0282.oe2003sp4.aarch64.rpm",
"kernel-tools-debuginfo-4.19.90-2406.3.0.0282.oe2003sp4.aarch64.rpm",
"kernel-debugsource-4.19.90-2406.3.0.0282.oe2003sp4.aarch64.rpm",
"python2-perf-4.19.90-2406.3.0.0282.oe2003sp4.aarch64.rpm",
"kernel-source-4.19.90-2406.3.0.0282.oe2003sp4.aarch64.rpm",
"kernel-debuginfo-4.19.90-2406.3.0.0282.oe2003sp4.aarch64.rpm",
"bpftool-debuginfo-4.19.90-2406.3.0.0282.oe2003sp4.aarch64.rpm"
],
"src": [
"kernel-4.19.90-2406.3.0.0282.oe2003sp4.src.rpm"
],
"x86_64": [
"python3-perf-debuginfo-4.19.90-2406.3.0.0282.oe2003sp4.x86_64.rpm",
"kernel-tools-devel-4.19.90-2406.3.0.0282.oe2003sp4.x86_64.rpm",
"kernel-4.19.90-2406.3.0.0282.oe2003sp4.x86_64.rpm",
"kernel-debugsource-4.19.90-2406.3.0.0282.oe2003sp4.x86_64.rpm",
"kernel-tools-4.19.90-2406.3.0.0282.oe2003sp4.x86_64.rpm",
"perf-debuginfo-4.19.90-2406.3.0.0282.oe2003sp4.x86_64.rpm",
"perf-4.19.90-2406.3.0.0282.oe2003sp4.x86_64.rpm",
"bpftool-4.19.90-2406.3.0.0282.oe2003sp4.x86_64.rpm",
"kernel-devel-4.19.90-2406.3.0.0282.oe2003sp4.x86_64.rpm",
"python2-perf-4.19.90-2406.3.0.0282.oe2003sp4.x86_64.rpm",
"python2-perf-debuginfo-4.19.90-2406.3.0.0282.oe2003sp4.x86_64.rpm",
"python3-perf-4.19.90-2406.3.0.0282.oe2003sp4.x86_64.rpm",
"kernel-tools-debuginfo-4.19.90-2406.3.0.0282.oe2003sp4.x86_64.rpm",
"kernel-debuginfo-4.19.90-2406.3.0.0282.oe2003sp4.x86_64.rpm",
"kernel-source-4.19.90-2406.3.0.0282.oe2003sp4.x86_64.rpm",
"bpftool-debuginfo-4.19.90-2406.3.0.0282.oe2003sp4.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:20.03-LTS-SP4",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-20.03-LTS-SP4"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.19.90-2406.3.0.0282.oe2003sp4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nPCI: aardvark: Fix kernel panic during PIO transfer\r\n\r\nTrying to start a new PIO transfer by writing value 0 in PIO_START register\nwhen previous transfer has not yet completed (which is indicated by value 1\nin PIO_START) causes an External Abort on CPU, which results in kernel\npanic:\r\n\r\n SError Interrupt on CPU0, code 0xbf000002 -- SError\n Kernel panic - not syncing: Asynchronous SError Interrupt\r\n\r\nTo prevent kernel panic, it is required to reject a new PIO transfer when\nprevious one has not finished yet.\r\n\r\nIf previous PIO transfer is not finished yet, the kernel may issue a new\nPIO request only if the previous PIO transfer timed out.\r\n\r\nIn the past the root cause of this issue was incorrectly identified (as it\noften happens during link retraining or after link down event) and special\nhack was implemented in Trusted Firmware to catch all SError events in EL3,\nto ignore errors with code 0xbf000002 and not forwarding any other errors\nto kernel and instead throw panic from EL3 Trusted Firmware handler.\r\n\r\nLinks to discussion and patches about this issue:\nhttps://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/?id=3c7dcdac5c50\nhttps://lore.kernel.org/linux-pci/20190316161243.29517-1-repk@triplefau.lt/\nhttps://lore.kernel.org/linux-pci/971be151d24312cc533989a64bd454b4@www.loen.fr/\nhttps://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/1541\r\n\r\nBut the real cause was the fact that during link retraining or after link\ndown event the PIO transfer may take longer time, up to the 1.44s until it\ntimes out. This increased probability that a new PIO transfer would be\nissued by kernel while previous one has not finished yet.\r\n\r\nAfter applying this change into the kernel, it is possible to revert the\nmentioned TF-A hack and SError events do not have to be caught in TF-A EL3.(CVE-2021-47229)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nphy: phy-mtk-tphy: Fix some resource leaks in mtk_phy_init()\r\n\r\nUse clk_disable_unprepare() in the error path of mtk_phy_init() to fix\nsome resource leaks.(CVE-2021-47234)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: rds: fix memory leak in rds_recvmsg\r\n\r\nSyzbot reported memory leak in rds. The problem\nwas in unputted refcount in case of error.\r\n\r\nint rds_recvmsg(struct socket *sock, struct msghdr *msg, size_t size,\n\t\tint msg_flags)\n{\n...\r\n\r\n\tif (!rds_next_incoming(rs, \u0026amp;inc)) {\n\t\t...\n\t}\r\n\r\nAfter this \u0026quot;if\u0026quot; inc refcount incremented and\r\n\r\n\tif (rds_cmsg_recv(inc, msg, rs)) {\n\t\tret = -EFAULT;\n\t\tgoto out;\n\t}\n...\nout:\n\treturn ret;\n}\r\n\r\nin case of rds_cmsg_recv() fail the refcount won\u0026apos;t be\ndecremented. And it\u0026apos;s easy to see from ftrace log, that\nrds_inc_addref() don\u0026apos;t have rds_inc_put() pair in\nrds_recvmsg() after rds_cmsg_recv()\r\n\r\n 1) | rds_recvmsg() {\n 1) 3.721 us | rds_inc_addref();\n 1) 3.853 us | rds_message_inc_copy_to_user();\n 1) + 10.395 us | rds_cmsg_recv();\n 1) + 34.260 us | }(CVE-2021-47249)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: ieee802154: fix null deref in parse dev addr\r\n\r\nFix a logic error that could result in a null deref if the user sets\nthe mode incorrectly for the given addr type.(CVE-2021-47257)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: fix various gadget panics on 10gbps cabling\r\n\r\nusb_assign_descriptors() is called with 5 parameters,\nthe last 4 of which are the usb_descriptor_header for:\n full-speed (USB1.1 - 12Mbps [including USB1.0 low-speed @ 1.5Mbps),\n high-speed (USB2.0 - 480Mbps),\n super-speed (USB3.0 - 5Gbps),\n super-speed-plus (USB3.1 - 10Gbps).\r\n\r\nThe differences between full/high/super-speed descriptors are usually\nsubstantial (due to changes in the maximum usb block size from 64 to 512\nto 1024 bytes and other differences in the specs), while the difference\nbetween 5 and 10Gbps descriptors may be as little as nothing\n(in many cases the same tuning is simply good enough).\r\n\r\nHowever if a gadget driver calls usb_assign_descriptors() with\na NULL descriptor for super-speed-plus and is then used on a max 10gbps\nconfiguration, the kernel will crash with a null pointer dereference,\nwhen a 10gbps capable device port + cable + host port combination shows up.\n(This wouldn\u0026apos;t happen if the gadget max-speed was set to 5gbps, but\nit of course defaults to the maximum, and there\u0026apos;s no real reason to\nartificially limit it)\r\n\r\nThe fix is to simply use the 5gbps descriptor as the 10gbps descriptor,\nif a 10gbps descriptor wasn\u0026apos;t provided.\r\n\r\nObviously this won\u0026apos;t fix the problem if the 5gbps descriptor is also\nNULL, but such cases can\u0026apos;t be so trivially solved (and any such gadgets\nare unlikely to be used with USB3 ports any way).(CVE-2021-47267)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nALSA: seq: Fix race of snd_seq_timer_open()\r\n\r\nThe timer instance per queue is exclusive, and snd_seq_timer_open()\nshould have managed the concurrent accesses. It looks as if it\u0026apos;s\nchecking the already existing timer instance at the beginning, but\nit\u0026apos;s not right, because there is no protection, hence any later\nconcurrent call of snd_seq_timer_open() may override the timer\ninstance easily. This may result in UAF, as the leftover timer\ninstance can keep running while the queue itself gets closed, as\nspotted by syzkaller recently.\r\n\r\nFor avoiding the race, add a proper check at the assignment of\ntmr-\u0026gt;timeri again, and return -EBUSY if it\u0026apos;s been already registered.(CVE-2021-47281)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nigb: Fix use-after-free error during reset\r\n\r\nCleans the next descriptor to watch (next_to_watch) when cleaning the\nTX ring.\r\n\r\nFailure to do so can cause invalid memory accesses. If igb_poll() runs\nwhile the controller is reset this can lead to the driver try to free\na skb that was already freed.\r\n\r\n(The crash is harder to reproduce with the igb driver, but the same\npotential problem exists as the code is identical to igc)(CVE-2021-47301)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: ti: fix UAF in tlan_remove_one\r\n\r\npriv is netdev private data and it cannot be\nused after free_netdev() call. Using priv after free_netdev()\ncan cause UAF bug. Fix it by moving free_netdev() at the end of the\nfunction.(CVE-2021-47310)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwatchdog: Fix possible use-after-free by calling del_timer_sync()\r\n\r\nThis driver\u0026apos;s remove path calls del_timer(). However, that function\ndoes not wait until the timer handler finishes. This means that the\ntimer handler may still be running after the driver\u0026apos;s remove function\nhas finished, which would result in a use-after-free.\r\n\r\nFix by calling del_timer_sync(), which makes sure the timer handler\nhas finished, and unable to re-schedule itself.(CVE-2021-47321)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmisc/libmasm/module: Fix two use after free in ibmasm_init_one\r\n\r\nIn ibmasm_init_one, it calls ibmasm_init_remote_input_dev().\nInside ibmasm_init_remote_input_dev, mouse_dev and keybd_dev are\nallocated by input_allocate_device(), and assigned to\nsp-\u0026gt;remote.mouse_dev and sp-\u0026gt;remote.keybd_dev respectively.\r\n\r\nIn the err_free_devices error branch of ibmasm_init_one,\nmouse_dev and keybd_dev are freed by input_free_device(), and return\nerror. Then the execution runs into error_send_message error branch\nof ibmasm_init_one, where ibmasm_free_remote_input_dev(sp) is called\nto unregister the freed sp-\u0026gt;remote.mouse_dev and sp-\u0026gt;remote.keybd_dev.\r\n\r\nMy patch add a \u0026quot;error_init_remote\u0026quot; label to handle the error of\nibmasm_init_remote_input_dev(), to avoid the uaf bugs.(CVE-2021-47334)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: zr364xx: fix memory leak in zr364xx_start_readpipe\r\n\r\nsyzbot reported memory leak in zr364xx driver.\nThe problem was in non-freed urb in case of\nusb_submit_urb() fail.\r\n\r\nbacktrace:\n [\u0026lt;ffffffff82baedf6\u0026gt;] kmalloc include/linux/slab.h:561 [inline]\n [\u0026lt;ffffffff82baedf6\u0026gt;] usb_alloc_urb+0x66/0xe0 drivers/usb/core/urb.c:74\n [\u0026lt;ffffffff82f7cce8\u0026gt;] zr364xx_start_readpipe+0x78/0x130 drivers/media/usb/zr364xx/zr364xx.c:1022\n [\u0026lt;ffffffff84251dfc\u0026gt;] zr364xx_board_init drivers/media/usb/zr364xx/zr364xx.c:1383 [inline]\n [\u0026lt;ffffffff84251dfc\u0026gt;] zr364xx_probe+0x6a3/0x851 drivers/media/usb/zr364xx/zr364xx.c:1516\n [\u0026lt;ffffffff82bb6507\u0026gt;] usb_probe_interface+0x177/0x370 drivers/usb/core/driver.c:396\n [\u0026lt;ffffffff826018a9\u0026gt;] really_probe+0x159/0x500 drivers/base/dd.c:576(CVE-2021-47344)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/sched: Avoid data corruptions\r\n\r\nWait for all dependencies of a job to complete before\nkilling it to avoid data corruptions.(CVE-2021-47354)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: macb: fix use after free on rmmod\r\n\r\nplat_dev-\u0026gt;dev-\u0026gt;platform_data is released by platform_device_unregister(),\nuse of pclk and hclk is a use-after-free. Since device unregister won\u0026apos;t\nneed a clk device we adjust the function call sequence to fix this issue.\r\n\r\n[ 31.261225] BUG: KASAN: use-after-free in macb_remove+0x77/0xc6 [macb_pci]\n[ 31.275563] Freed by task 306:\n[ 30.276782] platform_device_release+0x25/0x80(CVE-2021-47372)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ni2c: acpi: fix resource leak in reconfiguration device addition\r\n\r\nacpi_i2c_find_adapter_by_handle() calls bus_find_device() which takes a\nreference on the adapter which is never released which will result in a\nreference count leak and render the adapter unremovable. Make sure to\nput the adapter after creating the client in the same manner that we do\nfor OF.\r\n\r\n[wsa: fixed title](CVE-2021-47425)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: encx24j600: check error in devm_regmap_init_encx24j600\r\n\r\ndevm_regmap_init may return error which caused by like out of memory,\nthis will results in null pointer dereference later when reading\nor writing register:\r\n\r\ngeneral protection fault in encx24j600_spi_probe\nKASAN: null-ptr-deref in range [0x0000000000000090-0x0000000000000097]\nCPU: 0 PID: 286 Comm: spi-encx24j600- Not tainted 5.15.0-rc2-00142-g9978db750e31-dirty #11 9c53a778c1306b1b02359f3c2bbedc0222cba652\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014\nRIP: 0010:regcache_cache_bypass drivers/base/regmap/regcache.c:540\nCode: 54 41 89 f4 55 53 48 89 fb 48 83 ec 08 e8 26 94 a8 fe 48 8d bb a0 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 \u0026lt;80\u0026gt; 3c 02 00 0f 85 4a 03 00 00 4c 8d ab b0 00 00 00 48 8b ab a0 00\nRSP: 0018:ffffc900010476b8 EFLAGS: 00010207\nRAX: dffffc0000000000 RBX: fffffffffffffff4 RCX: 0000000000000000\nRDX: 0000000000000012 RSI: ffff888002de0000 RDI: 0000000000000094\nRBP: ffff888013c9a000 R08: 0000000000000000 R09: fffffbfff3f9cc6a\nR10: ffffc900010476e8 R11: fffffbfff3f9cc69 R12: 0000000000000001\nR13: 000000000000000a R14: ffff888013c9af54 R15: ffff888013c9ad08\nFS: 00007ffa984ab580(0000) GS:ffff88801fe00000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 000055a6384136c8 CR3: 000000003bbe6003 CR4: 0000000000770ef0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nPKRU: 55555554\nCall Trace:\n encx24j600_spi_probe drivers/net/ethernet/microchip/encx24j600.c:459\n spi_probe drivers/spi/spi.c:397\n really_probe drivers/base/dd.c:517\n __driver_probe_device drivers/base/dd.c:751\n driver_probe_device drivers/base/dd.c:782\n __device_attach_driver drivers/base/dd.c:899\n bus_for_each_drv drivers/base/bus.c:427\n __device_attach drivers/base/dd.c:971\n bus_probe_device drivers/base/bus.c:487\n device_add drivers/base/core.c:3364\n __spi_add_device drivers/spi/spi.c:599\n spi_add_device drivers/spi/spi.c:641\n spi_new_device drivers/spi/spi.c:717\n new_device_store+0x18c/0x1f1 [spi_stub 4e02719357f1ff33f5a43d00630982840568e85e]\n dev_attr_store drivers/base/core.c:2074\n sysfs_kf_write fs/sysfs/file.c:139\n kernfs_fop_write_iter fs/kernfs/file.c:300\n new_sync_write fs/read_write.c:508 (discriminator 4)\n vfs_write fs/read_write.c:594\n ksys_write fs/read_write.c:648\n do_syscall_64 arch/x86/entry/common.c:50\n entry_SYSCALL_64_after_hwframe arch/x86/entry/entry_64.S:113\r\n\r\nAdd error check in devm_regmap_init_encx24j600 to avoid this situation.(CVE-2021-47440)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncan: peak_pci: peak_pci_remove(): fix UAF\r\n\r\nWhen remove the module peek_pci, referencing \u0026apos;chan\u0026apos; again after\nreleasing \u0026apos;dev\u0026apos; will cause UAF.\r\n\r\nFix this by releasing \u0026apos;dev\u0026apos; later.\r\n\r\nThe following log reveals it:\r\n\r\n[ 35.961814 ] BUG: KASAN: use-after-free in peak_pci_remove+0x16f/0x270 [peak_pci]\n[ 35.963414 ] Read of size 8 at addr ffff888136998ee8 by task modprobe/5537\n[ 35.965513 ] Call Trace:\n[ 35.965718 ] dump_stack_lvl+0xa8/0xd1\n[ 35.966028 ] print_address_description+0x87/0x3b0\n[ 35.966420 ] kasan_report+0x172/0x1c0\n[ 35.966725 ] ? peak_pci_remove+0x16f/0x270 [peak_pci]\n[ 35.967137 ] ? trace_irq_enable_rcuidle+0x10/0x170\n[ 35.967529 ] ? peak_pci_remove+0x16f/0x270 [peak_pci]\n[ 35.967945 ] __asan_report_load8_noabort+0x14/0x20\n[ 35.968346 ] peak_pci_remove+0x16f/0x270 [peak_pci]\n[ 35.968752 ] pci_device_remove+0xa9/0x250(CVE-2021-47456)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nisdn: mISDN: Fix sleeping function called from invalid context\r\n\r\nThe driver can call card-\u0026gt;isac.release() function from an atomic\ncontext.\r\n\r\nFix this by calling this function after releasing the lock.\r\n\r\nThe following log reveals it:\r\n\r\n[ 44.168226 ] BUG: sleeping function called from invalid context at kernel/workqueue.c:3018\n[ 44.168941 ] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 5475, name: modprobe\n[ 44.169574 ] INFO: lockdep is turned off.\n[ 44.169899 ] irq event stamp: 0\n[ 44.170160 ] hardirqs last enabled at (0): [\u0026lt;0000000000000000\u0026gt;] 0x0\n[ 44.170627 ] hardirqs last disabled at (0): [\u0026lt;ffffffff814209ed\u0026gt;] copy_process+0x132d/0x3e00\n[ 44.171240 ] softirqs last enabled at (0): [\u0026lt;ffffffff81420a1a\u0026gt;] copy_process+0x135a/0x3e00\n[ 44.171852 ] softirqs last disabled at (0): [\u0026lt;0000000000000000\u0026gt;] 0x0\n[ 44.172318 ] Preemption disabled at:\n[ 44.172320 ] [\u0026lt;ffffffffa009b0a9\u0026gt;] nj_release+0x69/0x500 [netjet]\n[ 44.174441 ] Call Trace:\n[ 44.174630 ] dump_stack_lvl+0xa8/0xd1\n[ 44.174912 ] dump_stack+0x15/0x17\n[ 44.175166 ] ___might_sleep+0x3a2/0x510\n[ 44.175459 ] ? nj_release+0x69/0x500 [netjet]\n[ 44.175791 ] __might_sleep+0x82/0xe0\n[ 44.176063 ] ? start_flush_work+0x20/0x7b0\n[ 44.176375 ] start_flush_work+0x33/0x7b0\n[ 44.176672 ] ? trace_irq_enable_rcuidle+0x85/0x170\n[ 44.177034 ] ? kasan_quarantine_put+0xaa/0x1f0\n[ 44.177372 ] ? kasan_quarantine_put+0xaa/0x1f0\n[ 44.177711 ] __flush_work+0x11a/0x1a0\n[ 44.177991 ] ? flush_work+0x20/0x20\n[ 44.178257 ] ? lock_release+0x13c/0x8f0\n[ 44.178550 ] ? __kasan_check_write+0x14/0x20\n[ 44.178872 ] ? do_raw_spin_lock+0x148/0x360\n[ 44.179187 ] ? read_lock_is_recursive+0x20/0x20\n[ 44.179530 ] ? __kasan_check_read+0x11/0x20\n[ 44.179846 ] ? do_raw_spin_unlock+0x55/0x900\n[ 44.180168 ] ? ____kasan_slab_free+0x116/0x140\n[ 44.180505 ] ? _raw_spin_unlock_irqrestore+0x41/0x60\n[ 44.180878 ] ? skb_queue_purge+0x1a3/0x1c0\n[ 44.181189 ] ? kfree+0x13e/0x290\n[ 44.181438 ] flush_work+0x17/0x20\n[ 44.181695 ] mISDN_freedchannel+0xe8/0x100\n[ 44.182006 ] isac_release+0x210/0x260 [mISDNipac]\n[ 44.182366 ] nj_release+0xf6/0x500 [netjet]\n[ 44.182685 ] nj_remove+0x48/0x70 [netjet]\n[ 44.182989 ] pci_device_remove+0xa9/0x250(CVE-2021-47468)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncomedi: vmk80xx: fix bulk-buffer overflow\r\n\r\nThe driver is using endpoint-sized buffers but must not assume that the\ntx and rx buffers are of equal size or a malicious device could overflow\nthe slab-allocated receive buffer when doing bulk transfers.(CVE-2021-47474)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: batman-adv: fix error handling\r\n\r\nSyzbot reported ODEBUG warning in batadv_nc_mesh_free(). The problem was\nin wrong error handling in batadv_mesh_init().\r\n\r\nBefore this patch batadv_mesh_init() was calling batadv_mesh_free() in case\nof any batadv_*_init() calls failure. This approach may work well, when\nthere is some kind of indicator, which can tell which parts of batadv are\ninitialized; but there isn\u0026apos;t any.\r\n\r\nAll written above lead to cleaning up uninitialized fields. Even if we hide\nODEBUG warning by initializing bat_priv-\u0026gt;nc.work, syzbot was able to hit\nGPF in batadv_nc_purge_paths(), because hash pointer in still NULL. [1]\r\n\r\nTo fix these bugs we can unwind batadv_*_init() calls one by one.\nIt is good approach for 2 reasons: 1) It fixes bugs on error handling\npath 2) It improves the performance, since we won\u0026apos;t call unneeded\nbatadv_*_free() functions.\r\n\r\nSo, this patch makes all batadv_*_init() clean up all allocated memory\nbefore returning with an error to no call correspoing batadv_*_free()\nand open-codes batadv_mesh_free() with proper order to avoid touching\nuninitialized fields.(CVE-2021-47482)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nregmap: Fix possible double-free in regcache_rbtree_exit()\r\n\r\nIn regcache_rbtree_insert_to_block(), when \u0026apos;present\u0026apos; realloc failed,\nthe \u0026apos;blk\u0026apos; which is supposed to assign to \u0026apos;rbnode-\u0026gt;block\u0026apos; will be freed,\nso \u0026apos;rbnode-\u0026gt;block\u0026apos; points a freed memory, in the error handling path of\nregcache_rbtree_init(), \u0026apos;rbnode-\u0026gt;block\u0026apos; will be freed again in\nregcache_rbtree_exit(), KASAN will report double-free as follows:\r\n\r\nBUG: KASAN: double-free or invalid-free in kfree+0xce/0x390\nCall Trace:\n slab_free_freelist_hook+0x10d/0x240\n kfree+0xce/0x390\n regcache_rbtree_exit+0x15d/0x1a0\n regcache_rbtree_init+0x224/0x2c0\n regcache_init+0x88d/0x1310\n __regmap_init+0x3151/0x4a80\n __devm_regmap_init+0x7d/0x100\n madera_spi_probe+0x10f/0x333 [madera_spi]\n spi_probe+0x183/0x210\n really_probe+0x285/0xc30\r\n\r\nTo fix this, moving up the assignment of rbnode-\u0026gt;block to immediately after\nthe reallocation has succeeded so that the data structure stays valid even\nif the second reallocation fails.(CVE-2021-47483)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nIB/qib: Protect from buffer overflow in struct qib_user_sdma_pkt fields\r\n\r\nOverflowing either addrlimit or bytes_togo can allow userspace to trigger\na buffer overflow of kernel memory. Check for overflows in all the places\ndoing math on user controlled buffers.(CVE-2021-47485)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/tls: Fix flipped sign in tls_err_abort() calls\r\n\r\nsk-\u0026gt;sk_err appears to expect a positive value, a convention that ktls\ndoesn\u0026apos;t always follow and that leads to memory corruption in other code.\nFor instance,\r\n\r\n [kworker]\n tls_encrypt_done(..., err=\u0026lt;negative error from crypto request\u0026gt;)\n tls_err_abort(.., err)\n sk-\u0026gt;sk_err = err;\r\n\r\n [task]\n splice_from_pipe_feed\n ...\n tls_sw_do_sendpage\n if (sk-\u0026gt;sk_err) {\n ret = -sk-\u0026gt;sk_err; // ret is positive\r\n\r\n splice_from_pipe_feed (continued)\n ret = actor(...) // ret is still positive and interpreted as bytes\n // written, resulting in underflow of buf-\u0026gt;len and\n // sd-\u0026gt;len, leading to huge buf-\u0026gt;offset and bogus\n // addresses computed in later calls to actor()\r\n\r\nFix all tls_err_abort() callers to pass a negative error code\nconsistently and centralize the error-prone sign flip there, throwing in\na warning to catch future misuse and uninlining the function so it\nreally does only warn once.(CVE-2021-47496)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nALSA: pcm: oss: Limit the period size to 16MB\r\n\r\nSet the practical limit to the period size (the fragment shift in OSS)\ninstead of a full 31bit; a too large value could lead to the exhaust\nof memory as we allocate temporary buffers of the period size, too.\r\n\r\nAs of this patch, we set to 16MB limit, which should cover all use\ncases.(CVE-2021-47509)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnfp: Fix memory leak in nfp_cpp_area_cache_add()\r\n\r\nIn line 800 (#1), nfp_cpp_area_alloc() allocates and initializes a\nCPP area structure. But in line 807 (#2), when the cache is allocated\nfailed, this CPP area structure is not freed, which will result in\nmemory leak.\r\n\r\nWe can fix it by freeing the CPP area when the cache is allocated\nfailed (#2).\r\n\r\n792 int nfp_cpp_area_cache_add(struct nfp_cpp *cpp, size_t size)\n793 {\n794 \tstruct nfp_cpp_area_cache *cache;\n795 \tstruct nfp_cpp_area *area;\r\n\r\n800\tarea = nfp_cpp_area_alloc(cpp, NFP_CPP_ID(7, NFP_CPP_ACTION_RW, 0),\n801 \t\t\t\t 0, size);\n\t// #1: allocates and initializes\r\n\r\n802 \tif (!area)\n803 \t\treturn -ENOMEM;\r\n\r\n805 \tcache = kzalloc(sizeof(*cache), GFP_KERNEL);\n806 \tif (!cache)\n807 \t\treturn -ENOMEM; // #2: missing free\r\n\r\n817\treturn 0;\n818 }(CVE-2021-47516)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nstaging: rtl8192e: Fix use after free in _rtl92e_pci_disconnect()\r\n\r\nThe free_rtllib() function frees the \u0026quot;dev\u0026quot; pointer so there is use\nafter free on the next line. Re-arrange things to avoid that.(CVE-2021-47571)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsoc: brcmstb: pm-arm: Fix refcount leak and __iomem leak bugs\r\n\r\nIn brcmstb_pm_probe(), there are two kinds of leak bugs:\r\n\r\n(1) we need to add of_node_put() when for_each__matching_node() breaks\n(2) we need to add iounmap() for each iomap in fail path(CVE-2022-48693)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmmc: mmc_spi: fix error handling in mmc_spi_probe()\r\n\r\nIf mmc_add_host() fails, it doesn\u0026apos;t need to call mmc_remove_host(),\nor it will cause null-ptr-deref, because of deleting a not added\ndevice in mmc_remove_host().\r\n\r\nTo fix this, goto label \u0026apos;fail_glue_init\u0026apos;, if mmc_add_host() fails,\nand change the label \u0026apos;fail_add_host\u0026apos; to \u0026apos;fail_gpiod_request\u0026apos;.(CVE-2023-52708)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: USB: Fix wrong-direction WARNING in plusb.c\r\n\r\nThe syzbot fuzzer detected a bug in the plusb network driver: A\nzero-length control-OUT transfer was treated as a read instead of a\nwrite. In modern kernels this error provokes a WARNING:\r\n\r\nusb 1-1: BOGUS control dir, pipe 80000280 doesn\u0026apos;t match bRequestType c0\nWARNING: CPU: 0 PID: 4645 at drivers/usb/core/urb.c:411\nusb_submit_urb+0x14a7/0x1880 drivers/usb/core/urb.c:411\nModules linked in:\nCPU: 1 PID: 4645 Comm: dhcpcd Not tainted\n6.2.0-rc6-syzkaller-00050-g9f266ccaa2f5 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google\n01/12/2023\nRIP: 0010:usb_submit_urb+0x14a7/0x1880 drivers/usb/core/urb.c:411\n...\nCall Trace:\n \u0026lt;TASK\u0026gt;\n usb_start_wait_urb+0x101/0x4b0 drivers/usb/core/message.c:58\n usb_internal_control_msg drivers/usb/core/message.c:102 [inline]\n usb_control_msg+0x320/0x4a0 drivers/usb/core/message.c:153\n __usbnet_read_cmd+0xb9/0x390 drivers/net/usb/usbnet.c:2010\n usbnet_read_cmd+0x96/0xf0 drivers/net/usb/usbnet.c:2068\n pl_vendor_req drivers/net/usb/plusb.c:60 [inline]\n pl_set_QuickLink_features drivers/net/usb/plusb.c:75 [inline]\n pl_reset+0x2f/0xf0 drivers/net/usb/plusb.c:85\n usbnet_open+0xcc/0x5d0 drivers/net/usb/usbnet.c:889\n __dev_open+0x297/0x4d0 net/core/dev.c:1417\n __dev_change_flags+0x587/0x750 net/core/dev.c:8530\n dev_change_flags+0x97/0x170 net/core/dev.c:8602\n devinet_ioctl+0x15a2/0x1d70 net/ipv4/devinet.c:1147\n inet_ioctl+0x33f/0x380 net/ipv4/af_inet.c:979\n sock_do_ioctl+0xcc/0x230 net/socket.c:1169\n sock_ioctl+0x1f8/0x680 net/socket.c:1286\n vfs_ioctl fs/ioctl.c:51 [inline]\n __do_sys_ioctl fs/ioctl.c:870 [inline]\n __se_sys_ioctl fs/ioctl.c:856 [inline]\n __x64_sys_ioctl+0x197/0x210 fs/ioctl.c:856\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\r\n\r\nThe fix is to call usbnet_write_cmd() instead of usbnet_read_cmd() and\nremove the USB_DIR_IN flag.(CVE-2023-52742)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nIB/hfi1: Restore allocated resources on failed copyout\r\n\r\nFix a resource leak if an error occurs.(CVE-2023-52747)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: gspca: cpia1: shift-out-of-bounds in set_flicker\r\n\r\nSyzkaller reported the following issue:\nUBSAN: shift-out-of-bounds in drivers/media/usb/gspca/cpia1.c:1031:27\nshift exponent 245 is too large for 32-bit type \u0026apos;int\u0026apos;\r\n\r\nWhen the value of the variable \u0026quot;sd-\u0026gt;params.exposure.gain\u0026quot; exceeds the\nnumber of bits in an integer, a shift-out-of-bounds error is reported. It\nis triggered because the variable \u0026quot;currentexp\u0026quot; cannot be left-shifted by\nmore than the number of bits in an integer. In order to avoid invalid\nrange during left-shift, the conditional expression is added.(CVE-2023-52764)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfs/jfs: Add check for negative db_l2nbperpage\r\n\r\nl2nbperpage is log2(number of blks per page), and the minimum legal\nvalue should be 0, not negative.\r\n\r\nIn the case of l2nbperpage being negative, an error will occur\nwhen subsequently used as shift exponent.\r\n\r\nSyzbot reported this bug:\r\n\r\nUBSAN: shift-out-of-bounds in fs/jfs/jfs_dmap.c:799:12\nshift exponent -16777216 is negative(CVE-2023-52810)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nlocking/ww_mutex/test: Fix potential workqueue corruption\r\n\r\nIn some cases running with the test-ww_mutex code, I was seeing\nodd behavior where sometimes it seemed flush_workqueue was\nreturning before all the work threads were finished.\r\n\r\nOften this would cause strange crashes as the mutexes would be\nfreed while they were being used.\r\n\r\nLooking at the code, there is a lifetime problem as the\ncontrolling thread that spawns the work allocates the\n\u0026quot;struct stress\u0026quot; structures that are passed to the workqueue\nthreads. Then when the workqueue threads are finished,\nthey free the stress struct that was passed to them.\r\n\r\nUnfortunately the workqueue work_struct node is in the stress\nstruct. Which means the work_struct is freed before the work\nthread returns and while flush_workqueue is waiting.\r\n\r\nIt seems like a better idea to have the controlling thread\nboth allocate and free the stress structures, so that we can\nbe sure we don\u0026apos;t corrupt the workqueue by freeing the structure\nprematurely.\r\n\r\nSo this patch reworks the test to do so, and with this change\nI no longer see the early flush_workqueue returns.(CVE-2023-52836)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nllc: verify mac len before reading mac header\r\n\r\nLLC reads the mac header with eth_hdr without verifying that the skb\nhas an Ethernet header.\r\n\r\nSyzbot was able to enter llc_rcv on a tun device. Tun can insert\npackets without mac len and with user configurable skb-\u0026gt;protocol\n(passing a tun_pi header when not configuring IFF_NO_PI).\r\n\r\n BUG: KMSAN: uninit-value in llc_station_ac_send_test_r net/llc/llc_station.c:81 [inline]\n BUG: KMSAN: uninit-value in llc_station_rcv+0x6fb/0x1290 net/llc/llc_station.c:111\n llc_station_ac_send_test_r net/llc/llc_station.c:81 [inline]\n llc_station_rcv+0x6fb/0x1290 net/llc/llc_station.c:111\n llc_rcv+0xc5d/0x14a0 net/llc/llc_input.c:218\n __netif_receive_skb_one_core net/core/dev.c:5523 [inline]\n __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5637\n netif_receive_skb_internal net/core/dev.c:5723 [inline]\n netif_receive_skb+0x58/0x660 net/core/dev.c:5782\n tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555\n tun_get_user+0x54c5/0x69c0 drivers/net/tun.c:2002\r\n\r\nAdd a mac_len test before all three eth_hdr(skb) calls under net/llc.\r\n\r\nThere are further uses in include/net/llc_pdu.h. All these are\nprotected by a test skb-\u0026gt;protocol == ETH_P_802_2. Which does not\nprotect against this tun scenario.\r\n\r\nBut the mac_len test added in this patch in llc_fixup_skb will\nindirectly protect those too. That is called from llc_rcv before any\nother LLC code.\r\n\r\nIt is tempting to just add a blanket mac_len check in llc_rcv, but\nnot sure whether that could break valid LLC paths that do not assume\nan Ethernet header. 802.2 LLC may be used on top of non-802.3\nprotocols in principle. The below referenced commit shows that used\nto, on top of Token Ring.\r\n\r\nAt least one of the three eth_hdr uses goes back to before the start\nof git history. But the one that syzbot exercises is introduced in\nthis commit. That commit is old enough (2008), that effectively all\nstable kernels should receive this.(CVE-2023-52843)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nclk: mediatek: clk-mt2701: Add check for mtk_alloc_clk_data\r\n\r\nAdd the check for the return value of mtk_alloc_clk_data() in order to\navoid NULL pointer dereference.(CVE-2023-52875)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntty: n_gsm: require CAP_NET_ADMIN to attach N_GSM0710 ldisc\r\n\r\nAny unprivileged user can attach N_GSM0710 ldisc, but it requires\nCAP_NET_ADMIN to create a GSM network anyway.\r\n\r\nRequire initial namespace CAP_NET_ADMIN to do that.(CVE-2023-52880)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/mlx5e: Prevent deadlock while disabling aRFS\r\n\r\nWhen disabling aRFS under the `priv-\u0026gt;state_lock`, any scheduled\naRFS works are canceled using the `cancel_work_sync` function,\nwhich waits for the work to end if it has already started.\nHowever, while waiting for the work handler, the handler will\ntry to acquire the `state_lock` which is already acquired.\r\n\r\nThe worker acquires the lock to delete the rules if the state\nis down, which is not the worker\u0026apos;s responsibility since\ndisabling aRFS deletes the rules.\r\n\r\nAdd an aRFS state variable, which indicates whether the aRFS is\nenabled and prevent adding rules when the aRFS is disabled.\r\n\r\nKernel log:\r\n\r\n======================================================\nWARNING: possible circular locking dependency detected\n6.7.0-rc4_net_next_mlx5_5483eb2 #1 Tainted: G I\n------------------------------------------------------\nethtool/386089 is trying to acquire lock:\nffff88810f21ce68 ((work_completion)(\u0026amp;rule-\u0026gt;arfs_work)){+.+.}-{0:0}, at: __flush_work+0x74/0x4e0\r\n\r\nbut task is already holding lock:\nffff8884a1808cc0 (\u0026amp;priv-\u0026gt;state_lock){+.+.}-{3:3}, at: mlx5e_ethtool_set_channels+0x53/0x200 [mlx5_core]\r\n\r\nwhich lock already depends on the new lock.\r\n\r\nthe existing dependency chain (in reverse order) is:\r\n\r\n-\u0026gt; #1 (\u0026amp;priv-\u0026gt;state_lock){+.+.}-{3:3}:\n __mutex_lock+0x80/0xc90\n arfs_handle_work+0x4b/0x3b0 [mlx5_core]\n process_one_work+0x1dc/0x4a0\n worker_thread+0x1bf/0x3c0\n kthread+0xd7/0x100\n ret_from_fork+0x2d/0x50\n ret_from_fork_asm+0x11/0x20\r\n\r\n-\u0026gt; #0 ((work_completion)(\u0026amp;rule-\u0026gt;arfs_work)){+.+.}-{0:0}:\n __lock_acquire+0x17b4/0x2c80\n lock_acquire+0xd0/0x2b0\n __flush_work+0x7a/0x4e0\n __cancel_work_timer+0x131/0x1c0\n arfs_del_rules+0x143/0x1e0 [mlx5_core]\n mlx5e_arfs_disable+0x1b/0x30 [mlx5_core]\n mlx5e_ethtool_set_channels+0xcb/0x200 [mlx5_core]\n ethnl_set_channels+0x28f/0x3b0\n ethnl_default_set_doit+0xec/0x240\n genl_family_rcv_msg_doit+0xd0/0x120\n genl_rcv_msg+0x188/0x2c0\n netlink_rcv_skb+0x54/0x100\n genl_rcv+0x24/0x40\n netlink_unicast+0x1a1/0x270\n netlink_sendmsg+0x214/0x460\n __sock_sendmsg+0x38/0x60\n __sys_sendto+0x113/0x170\n __x64_sys_sendto+0x20/0x30\n do_syscall_64+0x40/0xe0\n entry_SYSCALL_64_after_hwframe+0x46/0x4e\r\n\r\nother info that might help us debug this:\r\n\r\n Possible unsafe locking scenario:\r\n\r\n CPU0 CPU1\n ---- ----\n lock(\u0026amp;priv-\u0026gt;state_lock);\n lock((work_completion)(\u0026amp;rule-\u0026gt;arfs_work));\n lock(\u0026amp;priv-\u0026gt;state_lock);\n lock((work_completion)(\u0026amp;rule-\u0026gt;arfs_work));\r\n\r\n *** DEADLOCK ***\r\n\r\n3 locks held by ethtool/386089:\n #0: ffffffff82ea7210 (cb_lock){++++}-{3:3}, at: genl_rcv+0x15/0x40\n #1: ffffffff82e94c88 (rtnl_mutex){+.+.}-{3:3}, at: ethnl_default_set_doit+0xd3/0x240\n #2: ffff8884a1808cc0 (\u0026amp;priv-\u0026gt;state_lock){+.+.}-{3:3}, at: mlx5e_ethtool_set_channels+0x53/0x200 [mlx5_core]\r\n\r\nstack backtrace:\nCPU: 15 PID: 386089 Comm: ethtool Tainted: G I 6.7.0-rc4_net_next_mlx5_5483eb2 #1\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x60/0xa0\n check_noncircular+0x144/0x160\n __lock_acquire+0x17b4/0x2c80\n lock_acquire+0xd0/0x2b0\n ? __flush_work+0x74/0x4e0\n ? save_trace+0x3e/0x360\n ? __flush_work+0x74/0x4e0\n __flush_work+0x7a/0x4e0\n ? __flush_work+0x74/0x4e0\n ? __lock_acquire+0xa78/0x2c80\n ? lock_acquire+0xd0/0x2b0\n ? mark_held_locks+0x49/0x70\n __cancel_work_timer+0x131/0x1c0\n ? mark_held_locks+0x49/0x70\n arfs_del_rules+0x143/0x1e0 [mlx5_core]\n mlx5e_arfs_disable+0x1b/0x30 [mlx5_core]\n mlx5e_ethtool_set_channels+0xcb/0x200 [mlx5_core]\n ethnl_set_channels+0x28f/0x3b0\n ethnl_default_set_doit+0xec/0x240\n genl_family_rcv_msg_doit+0xd0/0x120\n genl_rcv_msg+0x188/0x2c0\n ? ethn\n---truncated---(CVE-2024-27014)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nf_tables: Fix potential data-race in __nft_obj_type_get()\r\n\r\nnft_unregister_obj() can concurrent with __nft_obj_type_get(),\nand there is not any protection when iterate over nf_tables_objects\nlist in __nft_obj_type_get(). Therefore, there is potential data-race\nof nf_tables_objects list entry.\r\n\r\nUse list_for_each_entry_rcu() to iterate over nf_tables_objects\nlist in __nft_obj_type_get(), and use rcu_read_lock() in the caller\nnft_obj_type_get() to protect the entire type query process.(CVE-2024-27019)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nphonet/pep: fix racy skb_queue_empty() use\r\n\r\nThe receive queues are protected by their respective spin-lock, not\nthe socket lock. This could lead to skb_peek() unexpectedly\nreturning NULL or a pointer to an already dequeued socket buffer.(CVE-2024-27402)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsoc: fsl: qbman: Use raw spinlock for cgr_lock\r\n\r\nsmp_call_function always runs its callback in hard IRQ context, even on\nPREEMPT_RT, where spinlocks can sleep. So we need to use a raw spinlock\nfor cgr_lock to ensure we aren\u0026apos;t waiting on a sleeping task.\r\n\r\nAlthough this bug has existed for a while, it was not apparent until\ncommit ef2a8d5478b9 (\u0026quot;net: dpaa: Adjust queue depth on rate change\u0026quot;)\nwhich invokes smp_call_function_single via qman_update_cgr_safe every\ntime a link goes up or down.(CVE-2024-35819)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nubifs: Set page uptodate in the correct place\r\n\r\nPage cache reads are lockless, so setting the freshly allocated page\nuptodate before we\u0026apos;ve overwritten it with the data it\u0026apos;s supposed to have\nin it will allow a simultaneous reader to see old data. Move the call\nto SetPageUptodate into ubifs_write_end(), which is after we copied the\nnew data into the page.(CVE-2024-35821)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: libertas: fix some memleaks in lbs_allocate_cmd_buffer()\r\n\r\nIn the for statement of lbs_allocate_cmd_buffer(), if the allocation of\ncmdarray[i].cmdbuf fails, both cmdarray and cmdarray[i].cmdbuf needs to\nbe freed. Otherwise, there will be memleaks in lbs_allocate_cmd_buffer().(CVE-2024-35828)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntcp: properly terminate timers for kernel sockets\r\n\r\nWe had various syzbot reports about tcp timers firing after\nthe corresponding netns has been dismantled.\r\n\r\nFortunately Josef Bacik could trigger the issue more often,\nand could test a patch I wrote two years ago.\r\n\r\nWhen TCP sockets are closed, we call inet_csk_clear_xmit_timers()\nto \u0026apos;stop\u0026apos; the timers.\r\n\r\ninet_csk_clear_xmit_timers() can be called from any context,\nincluding when socket lock is held.\nThis is the reason it uses sk_stop_timer(), aka del_timer().\nThis means that ongoing timers might finish much later.\r\n\r\nFor user sockets, this is fine because each running timer\nholds a reference on the socket, and the user socket holds\na reference on the netns.\r\n\r\nFor kernel sockets, we risk that the netns is freed before\ntimer can complete, because kernel sockets do not hold\nreference on the netns.\r\n\r\nThis patch adds inet_csk_clear_xmit_timers_sync() function\nthat using sk_stop_timer_sync() to make sure all timers\nare terminated before the kernel socket is released.\nModules using kernel sockets close them in their netns exit()\nhandler.\r\n\r\nAlso add sock_not_owned_by_me() helper to get LOCKDEP\nsupport : inet_csk_clear_xmit_timers_sync() must not be called\nwhile socket lock is held.\r\n\r\nIt is very possible we can revert in the future commit\n3a58f13a881e (\u0026quot;net: rds: acquire refcount on TCP sockets\u0026quot;)\nwhich attempted to solve the issue in rds only.\n(net/smc/af_smc.c and net/mptcp/subflow.c have similar code)\r\n\r\nWe probably can remove the check_net() tests from\ntcp_out_of_resources() and __tcp_close() in the future.(CVE-2024-35910)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: send: handle path ref underflow in header iterate_inode_ref()\r\n\r\nChange BUG_ON to proper error handling if building the path buffer\nfails. The pointers are not printed so we don\u0026apos;t accidentally leak kernel\naddresses.(CVE-2024-35935)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: cfg80211: check A-MSDU format more carefully\r\n\r\nIf it looks like there\u0026apos;s another subframe in the A-MSDU\nbut the header isn\u0026apos;t fully there, we can end up reading\ndata out of bounds, only to discard later. Make this a\nbit more careful and check if the subframe header can\neven be present.(CVE-2024-35937)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndyndbg: fix old BUG_ON in \u0026gt;control parser\r\n\r\nFix a BUG_ON from 2009. Even if it looks \u0026quot;unreachable\u0026quot; (I didn\u0026apos;t\nreally look), lets make sure by removing it, doing pr_err and return\n-EINVAL instead.(CVE-2024-35947)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbatman-adv: Avoid infinite loop trying to resize local TT\r\n\r\nIf the MTU of one of an attached interface becomes too small to transmit\nthe local translation table then it must be resized to fit inside all\nfragments (when enabled) or a single packet.\r\n\r\nBut if the MTU becomes too low to transmit even the header + the VLAN\nspecific part then the resizing of the local TT will never succeed. This\ncan for example happen when the usable space is 110 bytes and 11 VLANs are\non top of batman-adv. In this case, at least 116 byte would be needed.\nThere will just be an endless spam of\r\n\r\n batman_adv: batadv0: Forced to purge local tt entries to fit new maximum fragment MTU (110)\r\n\r\nin the log but the function will never finish. Problem here is that the\ntimeout will be halved all the time and will then stagnate at 0 and\ntherefore never be able to reduce the table even more.\r\n\r\nThere are other scenarios possible with a similar result. The number of\nBATADV_TT_CLIENT_NOPURGE entries in the local TT can for example be too\nhigh to fit inside a packet. Such a scenario can therefore happen also with\nonly a single VLAN + 7 non-purgable addresses - requiring at least 120\nbytes.\r\n\r\nWhile this should be handled proactively when:\r\n\r\n* interface with too low MTU is added\n* VLAN is added\n* non-purgeable local mac is added\n* MTU of an attached interface is reduced\n* fragmentation setting gets disabled (which most likely requires dropping\n attached interfaces)\r\n\r\nnot all of these scenarios can be prevented because batman-adv is only\nconsuming events without the the possibility to prevent these actions\n(non-purgable MAC address added, MTU of an attached interface is reduced).\nIt is therefore necessary to also make sure that the code is able to handle\nalso the situations when there were already incompatible system\nconfiguration are present.(CVE-2024-35982)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntty: n_gsm: fix possible out-of-bounds in gsm0_receive()\r\n\r\nAssuming the following:\n- side A configures the n_gsm in basic option mode\n- side B sends the header of a basic option mode frame with data length 1\n- side A switches to advanced option mode\n- side B sends 2 data bytes which exceeds gsm-\u0026gt;len\n Reason: gsm-\u0026gt;len is not used in advanced option mode.\n- side A switches to basic option mode\n- side B keeps sending until gsm0_receive() writes past gsm-\u0026gt;buf\n Reason: Neither gsm-\u0026gt;state nor gsm-\u0026gt;len have been reset after\n reconfiguration.\r\n\r\nFix this by changing gsm-\u0026gt;count to gsm-\u0026gt;len comparison from equal to less\nthan. Also add upper limit checks against the constant MAX_MRU in\ngsm0_receive() and gsm1_receive() to harden against memory corruption of\ngsm-\u0026gt;len and gsm-\u0026gt;mru.\r\n\r\nAll other checks remain as we still need to limit the data according to the\nuser configuration and actual payload size.(CVE-2024-36016)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntipc: fix UAF in error path\r\n\r\nSam Page (sam4k) working with Trend Micro Zero Day Initiative reported\na UAF in the tipc_buf_append() error path:\r\n\r\nBUG: KASAN: slab-use-after-free in kfree_skb_list_reason+0x47e/0x4c0\nlinux/net/core/skbuff.c:1183\nRead of size 8 at addr ffff88804d2a7c80 by task poc/8034\r\n\r\nCPU: 1 PID: 8034 Comm: poc Not tainted 6.8.2 #1\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS\n1.16.0-debian-1.16.0-5 04/01/2014\nCall Trace:\n \u0026lt;IRQ\u0026gt;\n __dump_stack linux/lib/dump_stack.c:88\n dump_stack_lvl+0xd9/0x1b0 linux/lib/dump_stack.c:106\n print_address_description linux/mm/kasan/report.c:377\n print_report+0xc4/0x620 linux/mm/kasan/report.c:488\n kasan_report+0xda/0x110 linux/mm/kasan/report.c:601\n kfree_skb_list_reason+0x47e/0x4c0 linux/net/core/skbuff.c:1183\n skb_release_data+0x5af/0x880 linux/net/core/skbuff.c:1026\n skb_release_all linux/net/core/skbuff.c:1094\n __kfree_skb linux/net/core/skbuff.c:1108\n kfree_skb_reason+0x12d/0x210 linux/net/core/skbuff.c:1144\n kfree_skb linux/./include/linux/skbuff.h:1244\n tipc_buf_append+0x425/0xb50 linux/net/tipc/msg.c:186\n tipc_link_input+0x224/0x7c0 linux/net/tipc/link.c:1324\n tipc_link_rcv+0x76e/0x2d70 linux/net/tipc/link.c:1824\n tipc_rcv+0x45f/0x10f0 linux/net/tipc/node.c:2159\n tipc_udp_recv+0x73b/0x8f0 linux/net/tipc/udp_media.c:390\n udp_queue_rcv_one_skb+0xad2/0x1850 linux/net/ipv4/udp.c:2108\n udp_queue_rcv_skb+0x131/0xb00 linux/net/ipv4/udp.c:2186\n udp_unicast_rcv_skb+0x165/0x3b0 linux/net/ipv4/udp.c:2346\n __udp4_lib_rcv+0x2594/0x3400 linux/net/ipv4/udp.c:2422\n ip_protocol_deliver_rcu+0x30c/0x4e0 linux/net/ipv4/ip_input.c:205\n ip_local_deliver_finish+0x2e4/0x520 linux/net/ipv4/ip_input.c:233\n NF_HOOK linux/./include/linux/netfilter.h:314\n NF_HOOK linux/./include/linux/netfilter.h:308\n ip_local_deliver+0x18e/0x1f0 linux/net/ipv4/ip_input.c:254\n dst_input linux/./include/net/dst.h:461\n ip_rcv_finish linux/net/ipv4/ip_input.c:449\n NF_HOOK linux/./include/linux/netfilter.h:314\n NF_HOOK linux/./include/linux/netfilter.h:308\n ip_rcv+0x2c5/0x5d0 linux/net/ipv4/ip_input.c:569\n __netif_receive_skb_one_core+0x199/0x1e0 linux/net/core/dev.c:5534\n __netif_receive_skb+0x1f/0x1c0 linux/net/core/dev.c:5648\n process_backlog+0x101/0x6b0 linux/net/core/dev.c:5976\n __napi_poll.constprop.0+0xba/0x550 linux/net/core/dev.c:6576\n napi_poll linux/net/core/dev.c:6645\n net_rx_action+0x95a/0xe90 linux/net/core/dev.c:6781\n __do_softirq+0x21f/0x8e7 linux/kernel/softirq.c:553\n do_softirq linux/kernel/softirq.c:454\n do_softirq+0xb2/0xf0 linux/kernel/softirq.c:441\n \u0026lt;/IRQ\u0026gt;\n \u0026lt;TASK\u0026gt;\n __local_bh_enable_ip+0x100/0x120 linux/kernel/softirq.c:381\n local_bh_enable linux/./include/linux/bottom_half.h:33\n rcu_read_unlock_bh linux/./include/linux/rcupdate.h:851\n __dev_queue_xmit+0x871/0x3ee0 linux/net/core/dev.c:4378\n dev_queue_xmit linux/./include/linux/netdevice.h:3169\n neigh_hh_output linux/./include/net/neighbour.h:526\n neigh_output linux/./include/net/neighbour.h:540\n ip_finish_output2+0x169f/0x2550 linux/net/ipv4/ip_output.c:235\n __ip_finish_output linux/net/ipv4/ip_output.c:313\n __ip_finish_output+0x49e/0x950 linux/net/ipv4/ip_output.c:295\n ip_finish_output+0x31/0x310 linux/net/ipv4/ip_output.c:323\n NF_HOOK_COND linux/./include/linux/netfilter.h:303\n ip_output+0x13b/0x2a0 linux/net/ipv4/ip_output.c:433\n dst_output linux/./include/net/dst.h:451\n ip_local_out linux/net/ipv4/ip_output.c:129\n ip_send_skb+0x3e5/0x560 linux/net/ipv4/ip_output.c:1492\n udp_send_skb+0x73f/0x1530 linux/net/ipv4/udp.c:963\n udp_sendmsg+0x1a36/0x2b40 linux/net/ipv4/udp.c:1250\n inet_sendmsg+0x105/0x140 linux/net/ipv4/af_inet.c:850\n sock_sendmsg_nosec linux/net/socket.c:730\n __sock_sendmsg linux/net/socket.c:745\n __sys_sendto+0x42c/0x4e0 linux/net/socket.c:2191\n __do_sys_sendto linux/net/socket.c:2203\n __se_sys_sendto linux/net/socket.c:2199\n __x64_sys_sendto+0xe0/0x1c0 linux/net/socket.c:2199\n do_syscall_x64 linux/arch/x86/entry/common.c:52\n do_syscall_\n---truncated---(CVE-2024-36886)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nipv6: prevent NULL dereference in ip6_output()\r\n\r\nAccording to syzbot, there is a chance that ip6_dst_idev()\nreturns NULL in ip6_output(). Most places in IPv6 stack\ndeal with a NULL idev just fine, but not here.\r\n\r\nsyzbot reported:\r\n\r\ngeneral protection fault, probably for non-canonical address 0xdffffc00000000bc: 0000 [#1] PREEMPT SMP KASAN PTI\nKASAN: null-ptr-deref in range [0x00000000000005e0-0x00000000000005e7]\nCPU: 0 PID: 9775 Comm: syz-executor.4 Not tainted 6.9.0-rc5-syzkaller-00157-g6a30653b604a #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024\n RIP: 0010:ip6_output+0x231/0x3f0 net/ipv6/ip6_output.c:237\nCode: 3c 1e 00 49 89 df 74 08 4c 89 ef e8 19 58 db f7 48 8b 44 24 20 49 89 45 00 49 89 c5 48 8d 9d e0 05 00 00 48 89 d8 48 c1 e8 03 \u0026lt;42\u0026gt; 0f b6 04 38 84 c0 4c 8b 74 24 28 0f 85 61 01 00 00 8b 1b 31 ff\nRSP: 0018:ffffc9000927f0d8 EFLAGS: 00010202\nRAX: 00000000000000bc RBX: 00000000000005e0 RCX: 0000000000040000\nRDX: ffffc900131f9000 RSI: 0000000000004f47 RDI: 0000000000004f48\nRBP: 0000000000000000 R08: ffffffff8a1f0b9a R09: 1ffffffff1f51fad\nR10: dffffc0000000000 R11: fffffbfff1f51fae R12: ffff8880293ec8c0\nR13: ffff88805d7fc000 R14: 1ffff1100527d91a R15: dffffc0000000000\nFS: 00007f135c6856c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000020000080 CR3: 0000000064096000 CR4: 00000000003506f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n NF_HOOK include/linux/netfilter.h:314 [inline]\n ip6_xmit+0xefe/0x17f0 net/ipv6/ip6_output.c:358\n sctp_v6_xmit+0x9f2/0x13f0 net/sctp/ipv6.c:248\n sctp_packet_transmit+0x26ad/0x2ca0 net/sctp/output.c:653\n sctp_packet_singleton+0x22c/0x320 net/sctp/outqueue.c:783\n sctp_outq_flush_ctrl net/sctp/outqueue.c:914 [inline]\n sctp_outq_flush+0x6d5/0x3e20 net/sctp/outqueue.c:1212\n sctp_side_effects net/sctp/sm_sideeffect.c:1198 [inline]\n sctp_do_sm+0x59cc/0x60c0 net/sctp/sm_sideeffect.c:1169\n sctp_primitive_ASSOCIATE+0x95/0xc0 net/sctp/primitive.c:73\n __sctp_connect+0x9cd/0xe30 net/sctp/socket.c:1234\n sctp_connect net/sctp/socket.c:4819 [inline]\n sctp_inet_connect+0x149/0x1f0 net/sctp/socket.c:4834\n __sys_connect_file net/socket.c:2048 [inline]\n __sys_connect+0x2df/0x310 net/socket.c:2065\n __do_sys_connect net/socket.c:2075 [inline]\n __se_sys_connect net/socket.c:2072 [inline]\n __x64_sys_connect+0x7a/0x90 net/socket.c:2072\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2024-36901)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntcp: defer shutdown(SEND_SHUTDOWN) for TCP_SYN_RECV sockets\r\n\r\nTCP_SYN_RECV state is really special, it is only used by\ncross-syn connections, mostly used by fuzzers.\r\n\r\nIn the following crash [1], syzbot managed to trigger a divide\nby zero in tcp_rcv_space_adjust()\r\n\r\nA socket makes the following state transitions,\nwithout ever calling tcp_init_transfer(),\nmeaning tcp_init_buffer_space() is also not called.\r\n\r\n TCP_CLOSE\nconnect()\n TCP_SYN_SENT\n TCP_SYN_RECV\nshutdown() -\u0026gt; tcp_shutdown(sk, SEND_SHUTDOWN)\n TCP_FIN_WAIT1\r\n\r\nTo fix this issue, change tcp_shutdown() to not\nperform a TCP_SYN_RECV -\u0026gt; TCP_FIN_WAIT1 transition,\nwhich makes no sense anyway.\r\n\r\nWhen tcp_rcv_state_process() later changes socket state\nfrom TCP_SYN_RECV to TCP_ESTABLISH, then look at\nsk-\u0026gt;sk_shutdown to finally enter TCP_FIN_WAIT1 state,\nand send a FIN packet from a sane socket state.\r\n\r\nThis means tcp_send_fin() can now be called from BH\ncontext, and must use GFP_ATOMIC allocations.\r\n\r\n[1]\ndivide error: 0000 [#1] PREEMPT SMP KASAN NOPTI\nCPU: 1 PID: 5084 Comm: syz-executor358 Not tainted 6.9.0-rc6-syzkaller-00022-g98369dccd2f8 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024\n RIP: 0010:tcp_rcv_space_adjust+0x2df/0x890 net/ipv4/tcp_input.c:767\nCode: e3 04 4c 01 eb 48 8b 44 24 38 0f b6 04 10 84 c0 49 89 d5 0f 85 a5 03 00 00 41 8b 8e c8 09 00 00 89 e8 29 c8 48 0f af c3 31 d2 \u0026lt;48\u0026gt; f7 f1 48 8d 1c 43 49 8d 96 76 08 00 00 48 89 d0 48 c1 e8 03 48\nRSP: 0018:ffffc900031ef3f0 EFLAGS: 00010246\nRAX: 0c677a10441f8f42 RBX: 000000004fb95e7e RCX: 0000000000000000\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000\nRBP: 0000000027d4b11f R08: ffffffff89e535a4 R09: 1ffffffff25e6ab7\nR10: dffffc0000000000 R11: ffffffff8135e920 R12: ffff88802a9f8d30\nR13: dffffc0000000000 R14: ffff88802a9f8d00 R15: 1ffff1100553f2da\nFS: 00005555775c0380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f1155bf2304 CR3: 000000002b9f2000 CR4: 0000000000350ef0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n tcp_recvmsg_locked+0x106d/0x25a0 net/ipv4/tcp.c:2513\n tcp_recvmsg+0x25d/0x920 net/ipv4/tcp.c:2578\n inet6_recvmsg+0x16a/0x730 net/ipv6/af_inet6.c:680\n sock_recvmsg_nosec net/socket.c:1046 [inline]\n sock_recvmsg+0x109/0x280 net/socket.c:1068\n ____sys_recvmsg+0x1db/0x470 net/socket.c:2803\n ___sys_recvmsg net/socket.c:2845 [inline]\n do_recvmmsg+0x474/0xae0 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+0x199/0x250 net/socket.c:3034\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7faeb6363db9\nCode: 28 00 00 00 75 05 48 83 c4 28 c3 e8 c1 17 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007ffcc1997168 EFLAGS: 00000246 ORIG_RAX: 000000000000012b\nRAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007faeb6363db9\nRDX: 0000000000000001 RSI: 0000000020000bc0 RDI: 0000000000000005\nRBP: 0000000000000000 R08: 0000000000000000 R09: 000000000000001c\nR10: 0000000000000122 R11: 0000000000000246 R12: 0000000000000000\nR13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000001(CVE-2024-36905)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: bnx2fc: Remove spin_lock_bh while releasing resources after upload\r\n\r\nThe session resources are used by FW and driver when session is offloaded,\nonce session is uploaded these resources are not used. The lock is not\nrequired as these fields won\u0026apos;t be used any longer. The offload and upload\ncalls are sequential, hence lock is not required.\r\n\r\nThis will suppress following BUG_ON():\r\n\r\n[ 449.843143] ------------[ cut here ]------------\n[ 449.848302] kernel BUG at mm/vmalloc.c:2727!\n[ 449.853072] invalid opcode: 0000 [#1] PREEMPT SMP PTI\n[ 449.858712] CPU: 5 PID: 1996 Comm: kworker/u24:2 Not tainted 5.14.0-118.el9.x86_64 #1\nRebooting.\n[ 449.867454] Hardware name: Dell Inc. PowerEdge R730/0WCJNT, BIOS 2.3.4 11/08/2016\n[ 449.876966] Workqueue: fc_rport_eq fc_rport_work [libfc]\n[ 449.882910] RIP: 0010:vunmap+0x2e/0x30\n[ 449.887098] Code: 00 65 8b 05 14 a2 f0 4a a9 00 ff ff 00 75 1b 55 48 89 fd e8 34 36 79 00 48 85 ed 74 0b 48 89 ef 31 f6 5d e9 14 fc ff ff 5d c3 \u0026lt;0f\u0026gt; 0b 0f 1f 44 00 00 41 57 41 56 49 89 ce 41 55 49 89 fd 41 54 41\n[ 449.908054] RSP: 0018:ffffb83d878b3d68 EFLAGS: 00010206\n[ 449.913887] RAX: 0000000080000201 RBX: ffff8f4355133550 RCX: 000000000d400005\n[ 449.921843] RDX: 0000000000000001 RSI: 0000000000001000 RDI: ffffb83da53f5000\n[ 449.929808] RBP: ffff8f4ac6675800 R08: ffffb83d878b3d30 R09: 00000000000efbdf\n[ 449.937774] R10: 0000000000000003 R11: ffff8f434573e000 R12: 0000000000001000\n[ 449.945736] R13: 0000000000001000 R14: ffffb83da53f5000 R15: ffff8f43d4ea3ae0\n[ 449.953701] FS: 0000000000000000(0000) GS:ffff8f529fc80000(0000) knlGS:0000000000000000\n[ 449.962732] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 449.969138] CR2: 00007f8cf993e150 CR3: 0000000efbe10003 CR4: 00000000003706e0\n[ 449.977102] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[ 449.985065] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[ 449.993028] Call Trace:\n[ 449.995756] __iommu_dma_free+0x96/0x100\n[ 450.000139] bnx2fc_free_session_resc+0x67/0x240 [bnx2fc]\n[ 450.006171] bnx2fc_upload_session+0xce/0x100 [bnx2fc]\n[ 450.011910] bnx2fc_rport_event_handler+0x9f/0x240 [bnx2fc]\n[ 450.018136] fc_rport_work+0x103/0x5b0 [libfc]\n[ 450.023103] process_one_work+0x1e8/0x3c0\n[ 450.027581] worker_thread+0x50/0x3b0\n[ 450.031669] ? rescuer_thread+0x370/0x370\n[ 450.036143] kthread+0x149/0x170\n[ 450.039744] ? set_kthread_struct+0x40/0x40\n[ 450.044411] ret_from_fork+0x22/0x30\n[ 450.048404] Modules linked in: vfat msdos fat xfs nfs_layout_nfsv41_files rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver dm_service_time qedf qed crc8 bnx2fc libfcoe libfc scsi_transport_fc intel_rapl_msr intel_rapl_common x86_pkg_temp_thermal intel_powerclamp dcdbas rapl intel_cstate intel_uncore mei_me pcspkr mei ipmi_ssif lpc_ich ipmi_si fuse zram ext4 mbcache jbd2 loop nfsv3 nfs_acl nfs lockd grace fscache netfs irdma ice sd_mod t10_pi sg ib_uverbs ib_core 8021q garp mrp stp llc mgag200 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt mxm_wmi fb_sys_fops cec crct10dif_pclmul ahci crc32_pclmul bnx2x drm ghash_clmulni_intel libahci rfkill i40e libata megaraid_sas mdio wmi sunrpc lrw dm_crypt dm_round_robin dm_multipath dm_snapshot dm_bufio dm_mirror dm_region_hash dm_log dm_zero dm_mod linear raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx raid6_pq libcrc32c crc32c_intel raid1 raid0 iscsi_ibft squashfs be2iscsi bnx2i cnic uio cxgb4i cxgb4 tls\n[ 450.048497] libcxgbi libcxgb qla4xxx iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi edd ipmi_devintf ipmi_msghandler\n[ 450.159753] ---[ end trace 712de2c57c64abc8 ]---(CVE-2024-36919)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbna: ensure the copied buf is NUL terminated\r\n\r\nCurrently, we allocate a nbytes-sized kernel buffer and copy nbytes from\nuserspace to that buffer. Later, we use sscanf on this buffer but we don\u0026apos;t\nensure that the string is terminated inside the buffer, this can lead to\nOOB read when using sscanf. Fix this issue by using memdup_user_nul\ninstead of memdup_user.(CVE-2024-36934)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: lpfc: Move NPIV\u0026apos;s transport unregistration to after resource clean up\r\n\r\nThere are cases after NPIV deletion where the fabric switch still believes\nthe NPIV is logged into the fabric. This occurs when a vport is\nunregistered before the Remove All DA_ID CT and LOGO ELS are sent to the\nfabric.\r\n\r\nCurrently fc_remove_host(), which calls dev_loss_tmo for all D_IDs including\nthe fabric D_ID, removes the last ndlp reference and frees the ndlp rport\nobject. This sometimes causes the race condition where the final DA_ID and\nLOGO are skipped from being sent to the fabric switch.\r\n\r\nFix by moving the fc_remove_host() and scsi_remove_host() calls after DA_ID\nand LOGO are sent.(CVE-2024-36952)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/vmwgfx: Fix invalid reads in fence signaled events\r\n\r\nCorrectly set the length of the drm_event to the size of the structure\nthat\u0026apos;s actually used.\r\n\r\nThe length of the drm_event was set to the parent structure instead of\nto the drm_vmw_event_fence which is supposed to be read. drm_read\nuses the length parameter to copy the event to the user space thus\nresuling in oob reads.(CVE-2024-36960)",
"id": "OESA-2024-1736",
"modified": "2026-08-06T11:07:12Z",
"published": "2024-06-21T11:07:12Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1736"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47229"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47234"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47249"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47257"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47267"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47281"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47301"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47310"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47321"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47334"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47344"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47354"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47372"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47425"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47440"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47456"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47468"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47474"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47482"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47483"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47485"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47496"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47509"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47516"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47571"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48693"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52708"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52742"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52747"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52764"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52810"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52836"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52843"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52875"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52880"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27014"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27019"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27402"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35819"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35821"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35828"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35910"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35935"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35937"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35947"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35982"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36016"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36886"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36901"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36905"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36919"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36934"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36952"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36960"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2021-47229",
"CVE-2021-47234",
"CVE-2021-47249",
"CVE-2021-47257",
"CVE-2021-47267",
"CVE-2021-47281",
"CVE-2021-47301",
"CVE-2021-47310",
"CVE-2021-47321",
"CVE-2021-47334",
"CVE-2021-47344",
"CVE-2021-47354",
"CVE-2021-47372",
"CVE-2021-47425",
"CVE-2021-47440",
"CVE-2021-47456",
"CVE-2021-47468",
"CVE-2021-47474",
"CVE-2021-47482",
"CVE-2021-47483",
"CVE-2021-47485",
"CVE-2021-47496",
"CVE-2021-47509",
"CVE-2021-47516",
"CVE-2021-47571",
"CVE-2022-48693",
"CVE-2023-52708",
"CVE-2023-52742",
"CVE-2023-52747",
"CVE-2023-52764",
"CVE-2023-52810",
"CVE-2023-52836",
"CVE-2023-52843",
"CVE-2023-52875",
"CVE-2023-52880",
"CVE-2024-27014",
"CVE-2024-27019",
"CVE-2024-27402",
"CVE-2024-35819",
"CVE-2024-35821",
"CVE-2024-35828",
"CVE-2024-35910",
"CVE-2024-35935",
"CVE-2024-35937",
"CVE-2024-35947",
"CVE-2024-35982",
"CVE-2024-36016",
"CVE-2024-36886",
"CVE-2024-36901",
"CVE-2024-36905",
"CVE-2024-36919",
"CVE-2024-36934",
"CVE-2024-36952",
"CVE-2024-36960"
]
}
OESA-2024-2257 (CVE-2022-48688)
Vulnerability from osv_openeuler – Published: 2024-10-18 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:
i40e: Fix kernel crash during module removal
The driver incorrectly frees client instance and subsequent i40e module removal leads to kernel crash.
Reproducer: 1. Do ethtool offline test followed immediately by another one host# ethtool -t eth0 offline; ethtool -t eth0 offline 2. Remove recursively irdma module that also removes i40e module host# modprobe -r irdma
Result: [ 8675.035651] i40e 0000:3d:00.0 eno1: offline testing starting [ 8675.193774] i40e 0000:3d:00.0 eno1: testing finished [ 8675.201316] i40e 0000:3d:00.0 eno1: offline testing starting [ 8675.358921] i40e 0000:3d:00.0 eno1: testing finished [ 8675.496921] i40e 0000:3d:00.0: IRDMA hardware initialization FAILED init_state=2 status=-110 [ 8686.188955] i40e 0000:3d:00.1: i40e_ptp_stop: removed PHC on eno2 [ 8686.943890] i40e 0000:3d:00.1: Deleted LAN device PF1 bus=0x3d dev=0x00 func=0x01 [ 8686.952669] i40e 0000:3d:00.0: i40e_ptp_stop: removed PHC on eno1 [ 8687.761787] BUG: kernel NULL pointer dereference, address: 0000000000000030 [ 8687.768755] #PF: supervisor read access in kernel mode [ 8687.773895] #PF: error_code(0x0000) - not-present page [ 8687.779034] PGD 0 P4D 0 [ 8687.781575] Oops: 0000 [#1] PREEMPT SMP NOPTI [ 8687.785935] CPU: 51 PID: 172891 Comm: rmmod Kdump: loaded Tainted: G W I 5.19.0+ #2 [ 8687.794800] Hardware name: Intel Corporation S2600WFD/S2600WFD, BIOS SE5C620.86B.0X.02.0001.051420190324 05/14/2019 [ 8687.805222] RIP: 0010:i40e_lan_del_device+0x13/0xb0 [i40e] [ 8687.810719] Code: d4 84 c0 0f 84 b8 25 01 00 e9 9c 25 01 00 41 bc f4 ff ff ff eb 91 90 0f 1f 44 00 00 41 54 55 53 48 8b 87 58 08 00 00 48 89 fb <48> 8b 68 30 48 89 ef e8 21 8a 0f d5 48 89 ef e8 a9 78 0f d5 48 8b [ 8687.829462] RSP: 0018:ffffa604072efce0 EFLAGS: 00010202 [ 8687.834689] RAX: 0000000000000000 RBX: ffff8f43833b2000 RCX: 0000000000000000 [ 8687.841821] RDX: 0000000000000000 RSI: ffff8f4b0545b298 RDI: ffff8f43833b2000 [ 8687.848955] RBP: ffff8f43833b2000 R08: 0000000000000001 R09: 0000000000000000 [ 8687.856086] R10: 0000000000000000 R11: 000ffffffffff000 R12: ffff8f43833b2ef0 [ 8687.863218] R13: ffff8f43833b2ef0 R14: ffff915103966000 R15: ffff8f43833b2008 [ 8687.870342] FS: 00007f79501c3740(0000) GS:ffff8f4adffc0000(0000) knlGS:0000000000000000 [ 8687.878427] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 8687.884174] CR2: 0000000000000030 CR3: 000000014276e004 CR4: 00000000007706e0 [ 8687.891306] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 8687.898441] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 8687.905572] PKRU: 55555554 [ 8687.908286] Call Trace: [ 8687.910737] <TASK> [ 8687.912843] i40e_remove+0x2c0/0x330 [i40e] [ 8687.917040] pci_device_remove+0x33/0xa0 [ 8687.920962] device_release_driver_internal+0x1aa/0x230 [ 8687.926188] driver_detach+0x44/0x90 [ 8687.929770] bus_remove_driver+0x55/0xe0 [ 8687.933693] pci_unregister_driver+0x2a/0xb0 [ 8687.937967] i40e_exit_module+0xc/0xf48 [i40e]
Two offline tests cause IRDMA driver failure (ETIMEDOUT) and this failure is indicated back to i40e_client_subtask() that calls i40e_client_del_instance() to free client instance referenced by pf->cinst and sets this pointer to NULL. During the module removal i40e_remove() calls i40e_lan_del_device() that dereferences pf->cinst that is NULL -> crash. Do not remove client instance when client open callbacks fails and just clear __I40E_CLIENT_INSTANCE_OPENED bit. The driver also needs to take care about this situation (when netdev is up and client is NOT opened) in i40e_notify_client_of_netdev_close() and calls client close callback only when __I40E_CLIENT_INSTANCE_OPENED is set.(CVE-2022-48688)
In the Linux kernel, the following vulnerability has been resolved:
tracing/osnoise: Do not unregister events twice
Nicolas reported that using:
# trace-cmd record -e all -M 10 -p osnoise --poll
Resulted in the following kernel warning:
------------[ cut here ]------------ WARNING: CPU: 0 PID: 1217 at kernel/tracepoint.c:404 tracepoint_probe_unregister+0x280/0x370 [...] CPU: 0 PID: 1217 Comm: trace-cmd Not tainted 5.17.0-rc6-next-20220307-nico+ #19 RIP: 0010:tracepoint_probe_unregister+0x280/0x370 [...] CR2: 00007ff919b29497 CR3: 0000000109da4005 CR4: 0000000000170ef0 Call Trace: <TASK> osnoise_workload_stop+0x36/0x90 tracing_set_tracer+0x108/0x260 tracing_set_trace_write+0x94/0xd0 ? __check_object_size.part.0+0x10a/0x150 ? selinux_file_permission+0x104/0x150 vfs_write+0xb5/0x290 ksys_write+0x5f/0xe0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7ff919a18127 [...] ---[ end trace 0000000000000000 ]---
The warning complains about an attempt to unregister an unregistered tracepoint.
This happens on trace-cmd because it first stops tracing, and then switches the tracer to nop. Which is equivalent to:
# cd /sys/kernel/tracing/ # echo osnoise > current_tracer # echo 0 > tracing_on # echo nop > current_tracer
The osnoise tracer stops the workload when no trace instance is actually collecting data. This can be caused both by disabling tracing or disabling the tracer itself.
To avoid unregistering events twice, use the existing trace_osnoise_callback_enabled variable to check if the events (and the workload) are actually active before trying to deactivate them.(CVE-2022-48848)
In the Linux kernel, the following vulnerability has been resolved:
USB: gadgetfs: Fix race between mounting and unmounting
The syzbot fuzzer and Gerald Lee have identified a use-after-free bug in the gadgetfs driver, involving processes concurrently mounting and unmounting the gadgetfs filesystem. In particular, gadgetfs_fill_super() can race with gadgetfs_kill_sb(), causing the latter to deallocate the_device while the former is using it. The output from KASAN says, in part:
BUG: KASAN: use-after-free in instrument_atomic_read_write include/linux/instrumented.h:102 [inline] BUG: KASAN: use-after-free in atomic_fetch_sub_release include/linux/atomic/atomic-instrumented.h:176 [inline] BUG: KASAN: use-after-free in __refcount_sub_and_test include/linux/refcount.h:272 [inline] BUG: KASAN: use-after-free in __refcount_dec_and_test include/linux/refcount.h:315 [inline] BUG: KASAN: use-after-free in refcount_dec_and_test include/linux/refcount.h:333 [inline] BUG: KASAN: use-after-free in put_dev drivers/usb/gadget/legacy/inode.c:159 [inline] BUG: KASAN: use-after-free in gadgetfs_kill_sb+0x33/0x100 drivers/usb/gadget/legacy/inode.c:2086 Write of size 4 at addr ffff8880276d7840 by task syz-executor126/18689
CPU: 0 PID: 18689 Comm: syz-executor126 Not tainted 6.1.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022 Call Trace: <TASK> ... atomic_fetch_sub_release include/linux/atomic/atomic-instrumented.h:176 [inline] __refcount_sub_and_test include/linux/refcount.h:272 [inline] __refcount_dec_and_test include/linux/refcount.h:315 [inline] refcount_dec_and_test include/linux/refcount.h:333 [inline] put_dev drivers/usb/gadget/legacy/inode.c:159 [inline] gadgetfs_kill_sb+0x33/0x100 drivers/usb/gadget/legacy/inode.c:2086 deactivate_locked_super+0xa7/0xf0 fs/super.c:332 vfs_get_super fs/super.c:1190 [inline] get_tree_single+0xd0/0x160 fs/super.c:1207 vfs_get_tree+0x88/0x270 fs/super.c:1531 vfs_fsconfig_locked fs/fsopen.c:232 [inline]
The simplest solution is to ensure that gadgetfs_fill_super() and gadgetfs_kill_sb() are serialized by making them both acquire a new mutex.(CVE-2022-48869)
In the Linux kernel, the following vulnerability has been resolved:
efi: fix NULL-deref in init error path
In cases where runtime services are not supported or have been disabled, the runtime services workqueue will never have been allocated.
Do not try to destroy the workqueue unconditionally in the unlikely event that EFI initialisation fails to avoid dereferencing a NULL pointer.(CVE-2022-48879)
In the Linux kernel, the following vulnerability has been resolved:
drm/i915/gt: Cleanup partial engine discovery failures
If we abort driver initialisation in the middle of gt/engine discovery, some engines will be fully setup and some not. Those incompletely setup engines only have 'engine->release == NULL' and so will leak any of the common objects allocated.
v2: - Drop the destroy_pinned_context() helper for now. It's not really worth it with just a single callsite at the moment. (Janusz)(CVE-2022-48893)
In the Linux kernel, the following vulnerability has been resolved:
media: vivid: fix compose size exceed boundary
syzkaller found a bug:
BUG: unable to handle page fault for address: ffffc9000a3b1000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 100000067 P4D 100000067 PUD 10015f067 PMD 1121ca067 PTE 0 Oops: 0002 [#1] PREEMPT SMP CPU: 0 PID: 23489 Comm: vivid-000-vid-c Not tainted 6.1.0-rc1+ #512 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:memcpy_erms+0x6/0x10 [...] Call Trace: <TASK> ? tpg_fill_plane_buffer+0x856/0x15b0 vivid_fillbuff+0x8ac/0x1110 vivid_thread_vid_cap_tick+0x361/0xc90 vivid_thread_vid_cap+0x21a/0x3a0 kthread+0x143/0x180 ret_from_fork+0x1f/0x30 </TASK>
This is because we forget to check boundary after adjust compose->height int V4L2_SEL_TGT_CROP case. Add v4l2_rect_map_inside() to fix this problem for this case.(CVE-2022-48945)
A flaw possibility of memory leak in the Linux kernel cpu_entry_area mapping of X86 CPU data to memory was found in the way user can guess location of exception stack(s) or other important data. A local user could use this flaw to get access to some important data with expected location in memory.(CVE-2023-0597)
From the upstream fix below: The watchdog_timer can schedule tx_timeout_task and watchdog_work can also arm watchdog_timer [..] Although del_timer_sync() and cancel_work_sync() are called in cyttsp4_remove(), the timer and workqueue could still be rearmed. As a result, the possible use after free bugs could happen.
Upstream commit: https://github.com/torvalds/linux/commit/dbe836576f12743a7d2d170ad4ad4fd324c4d47a(CVE-2023-4134)
In the Linux kernel, the following vulnerability has been resolved:
efivarfs: force RO when remounting if SetVariable is not supported
If SetVariable at runtime is not supported by the firmware we never assign a callback for that function. At the same time mount the efivarfs as RO so no one can call that. However, we never check the permission flags when someone remounts the filesystem as RW. As a result this leads to a crash looking like this:
$ mount -o remount,rw /sys/firmware/efi/efivars $ efi-updatevar -f PK.auth PK
[ 303.279166] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 303.280482] Mem abort info: [ 303.280854] ESR = 0x0000000086000004 [ 303.281338] EC = 0x21: IABT (current EL), IL = 32 bits [ 303.282016] SET = 0, FnV = 0 [ 303.282414] EA = 0, S1PTW = 0 [ 303.282821] FSC = 0x04: level 0 translation fault [ 303.283771] user pgtable: 4k pages, 48-bit VAs, pgdp=000000004258c000 [ 303.284913] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000 [ 303.286076] Internal error: Oops: 0000000086000004 [#1] PREEMPT SMP [ 303.286936] Modules linked in: qrtr tpm_tis tpm_tis_core crct10dif_ce arm_smccc_trng rng_core drm fuse ip_tables x_tables ipv6 [ 303.288586] CPU: 1 PID: 755 Comm: efi-updatevar Not tainted 6.3.0-rc1-00108-gc7d0c4695c68 #1 [ 303.289748] Hardware name: Unknown Unknown Product/Unknown Product, BIOS 2023.04-00627-g88336918701d 04/01/2023 [ 303.291150] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 303.292123] pc : 0x0 [ 303.292443] lr : efivar_set_variable_locked+0x74/0xec [ 303.293156] sp : ffff800008673c10 [ 303.293619] x29: ffff800008673c10 x28: ffff0000037e8000 x27: 0000000000000000 [ 303.294592] x26: 0000000000000800 x25: ffff000002467400 x24: 0000000000000027 [ 303.295572] x23: ffffd49ea9832000 x22: ffff0000020c9800 x21: ffff000002467000 [ 303.296566] x20: 0000000000000001 x19: 00000000000007fc x18: 0000000000000000 [ 303.297531] x17: 0000000000000000 x16: 0000000000000000 x15: 0000aaaac807ab54 [ 303.298495] x14: ed37489f673633c0 x13: 71c45c606de13f80 x12: 47464259e219acf4 [ 303.299453] x11: ffff000002af7b01 x10: 0000000000000003 x9 : 0000000000000002 [ 303.300431] x8 : 0000000000000010 x7 : ffffd49ea8973230 x6 : 0000000000a85201 [ 303.301412] x5 : 0000000000000000 x4 : ffff0000020c9800 x3 : 00000000000007fc [ 303.302370] x2 : 0000000000000027 x1 : ffff000002467400 x0 : ffff000002467000 [ 303.303341] Call trace: [ 303.303679] 0x0 [ 303.303938] efivar_entry_set_get_size+0x98/0x16c [ 303.304585] efivarfs_file_write+0xd0/0x1a4 [ 303.305148] vfs_write+0xc4/0x2e4 [ 303.305601] ksys_write+0x70/0x104 [ 303.306073] __arm64_sys_write+0x1c/0x28 [ 303.306622] invoke_syscall+0x48/0x114 [ 303.307156] el0_svc_common.constprop.0+0x44/0xec [ 303.307803] do_el0_svc+0x38/0x98 [ 303.308268] el0_svc+0x2c/0x84 [ 303.308702] el0t_64_sync_handler+0xf4/0x120 [ 303.309293] el0t_64_sync+0x190/0x194 [ 303.309794] Code: ???????? ???????? ???????? ???????? (????????) [ 303.310612] ---[ end trace 0000000000000000 ]---
Fix this by adding a .reconfigure() function to the fs operations which we can use to check the requested flags and deny anything that's not RO if the firmware doesn't implement SetVariable at runtime.(CVE-2023-52463)
In the Linux kernel, the following vulnerability has been resolved:
sched/psi: Fix use-after-free in ep_remove_wait_queue()
If a non-root cgroup gets removed when there is a thread that registered trigger and is polling on a pressure file within the cgroup, the polling waitqueue gets freed in the following path:
do_rmdir cgroup_rmdir kernfs_drain_open_files cgroup_file_release cgroup_pressure_release psi_trigger_destroy
However, the polling thread still has a reference to the pressure file and will access the freed waitqueue when the file is closed or upon exit:
fput ep_eventpoll_release ep_free ep_remove_wait_queue remove_wait_queue
This results in use-after-free as pasted below.
The fundamental problem here is that cgroup_file_release() (and consequently waitqueue's lifetime) is not tied to the file's real lifetime. Using wake_up_pollfree() here might be less than ideal, but it is in line with the comment at commit 42288cb44c4b ("wait: add wake_up_pollfree()") since the waitqueue's lifetime is not tied to file's one and can be considered as another special case. While this would be fixable by somehow making cgroup_file_release() be tied to the fput(), it would require sizable refactoring at cgroups or higher layer which might be more justifiable if we identify more cases like this.
BUG: KASAN: use-after-free in _raw_spin_lock_irqsave+0x60/0xc0 Write of size 4 at addr ffff88810e625328 by task a.out/4404
CPU: 19 PID: 4404 Comm: a.out Not tainted 6.2.0-rc6 #38
Hardware name: Amazon EC2 c5a.8xlarge/, BIOS 1.0 10/16/2017
Call Trace:
<TASK>
dump_stack_lvl+0x73/0xa0
print_report+0x16c/0x4e0
kasan_report+0xc3/0xf0
kasan_check_range+0x2d2/0x310
_raw_spin_lock_irqsave+0x60/0xc0
remove_wait_queue+0x1a/0xa0
ep_free+0x12c/0x170
ep_eventpoll_release+0x26/0x30
__fput+0x202/0x400
task_work_run+0x11d/0x170
do_exit+0x495/0x1130
do_group_exit+0x100/0x100
get_signal+0xd67/0xde0
arch_do_signal_or_restart+0x2a/0x2b0
exit_to_user_mode_prepare+0x94/0x100
syscall_exit_to_user_mode+0x20/0x40
do_syscall_64+0x52/0x90
entry_SYSCALL_64_after_hwframe+0x63/0xcd
</TASK>
Allocated by task 4404:
kasan_set_track+0x3d/0x60
__kasan_kmalloc+0x85/0x90
psi_trigger_create+0x113/0x3e0
pressure_write+0x146/0x2e0
cgroup_file_write+0x11c/0x250
kernfs_fop_write_iter+0x186/0x220
vfs_write+0x3d8/0x5c0
ksys_write+0x90/0x110
do_syscall_64+0x43/0x90
entry_SYSCALL_64_after_hwframe+0x63/0xcd
Freed by task 4407:
kasan_set_track+0x3d/0x60
kasan_save_free_info+0x27/0x40
____kasan_slab_free+0x11d/0x170
slab_free_freelist_hook+0x87/0x150
__kmem_cache_free+0xcb/0x180
psi_trigger_destroy+0x2e8/0x310
cgroup_file_release+0x4f/0xb0
kernfs_drain_open_files+0x165/0x1f0
kernfs_drain+0x162/0x1a0
__kernfs_remove+0x1fb/0x310
kernfs_remove_by_name_ns+0x95/0xe0
cgroup_addrm_files+0x67f/0x700
cgroup_destroy_locked+0x283/0x3c0
cgroup_rmdir+0x29/0x100
kernfs_iop_rmdir+0xd1/0x140
vfs_rmdir+0xfe/0x240
do_rmdir+0x13d/0x280
__x64_sys_rmdir+0x2c/0x30
do_syscall_64+0x43/0x90
entry_SYSCALL_64_after_hwframe+0x63/0xcd(CVE-2023-52707)
In the Linux kernel, the following vulnerability has been resolved:
cifs: Fix use-after-free in rdata->read_into_pages()
When the network status is unstable, use-after-free may occur when read data from the server.
BUG: KASAN: use-after-free in readpages_fill_pages+0x14c/0x7e0
Call Trace: <TASK> dump_stack_lvl+0x38/0x4c print_report+0x16f/0x4a6 kasan_report+0xb7/0x130 readpages_fill_pages+0x14c/0x7e0 cifs_readv_receive+0x46d/0xa40 cifs_demultiplex_thread+0x121c/0x1490 kthread+0x16b/0x1a0 ret_from_fork+0x2c/0x50 </TASK>
Allocated by task 2535: kasan_save_stack+0x22/0x50 kasan_set_track+0x25/0x30 __kasan_kmalloc+0x82/0x90 cifs_readdata_direct_alloc+0x2c/0x110 cifs_readdata_alloc+0x2d/0x60 cifs_readahead+0x393/0xfe0 read_pages+0x12f/0x470 page_cache_ra_unbounded+0x1b1/0x240 filemap_get_pages+0x1c8/0x9a0 filemap_read+0x1c0/0x540 cifs_strict_readv+0x21b/0x240 vfs_read+0x395/0x4b0 ksys_read+0xb8/0x150 do_syscall_64+0x3f/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdc
Freed by task 79: kasan_save_stack+0x22/0x50 kasan_set_track+0x25/0x30 kasan_save_free_info+0x2e/0x50 __kasan_slab_free+0x10e/0x1a0 __kmem_cache_free+0x7a/0x1a0 cifs_readdata_release+0x49/0x60 process_one_work+0x46c/0x760 worker_thread+0x2a4/0x6f0 kthread+0x16b/0x1a0 ret_from_fork+0x2c/0x50
Last potentially related work creation: kasan_save_stack+0x22/0x50 __kasan_record_aux_stack+0x95/0xb0 insert_work+0x2b/0x130 __queue_work+0x1fe/0x660 queue_work_on+0x4b/0x60 smb2_readv_callback+0x396/0x800 cifs_abort_connection+0x474/0x6a0 cifs_reconnect+0x5cb/0xa50 cifs_readv_from_socket.cold+0x22/0x6c cifs_read_page_from_socket+0xc1/0x100 readpages_fill_pages.cold+0x2f/0x46 cifs_readv_receive+0x46d/0xa40 cifs_demultiplex_thread+0x121c/0x1490 kthread+0x16b/0x1a0 ret_from_fork+0x2c/0x50
The following function calls will cause UAF of the rdata pointer.
readpages_fill_pages cifs_read_page_from_socket cifs_readv_from_socket cifs_reconnect __cifs_reconnect cifs_abort_connection mid->callback() --> smb2_readv_callback queue_work(&rdata->work) # if the worker completes first, # the rdata is freed cifs_readv_complete kref_put cifs_readdata_release kfree(rdata) return rdata->... # UAF in readpages_fill_pages()
Similarly, this problem also occurs in the uncache_fill_pages().
Fix this by adjusts the order of condition judgment in the return statement.(CVE-2023-52741)
In the Linux kernel, the following vulnerability has been resolved:
tty: n_gsm: require CAP_NET_ADMIN to attach N_GSM0710 ldisc
Any unprivileged user can attach N_GSM0710 ldisc, but it requires CAP_NET_ADMIN to create a GSM network anyway.
Require initial namespace CAP_NET_ADMIN to do that.(CVE-2023-52880)
In the Linux kernel, the following vulnerability has been resolved:
keys: Fix overwrite of key expiration on instantiation
The expiry time of a key is unconditionally overwritten during instantiation, defaulting to turn it permanent. This causes a problem for DNS resolution as the expiration set by user-space is overwritten to TIME64_MAX, disabling further DNS updates. Fix this by restoring the condition that key_set_expiry is only called when the pre-parser sets a specific expiry.(CVE-2024-36031)
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix uninitialized ratelimit_state->lock access in __ext4_fill_super()
In the following concurrency we will access the uninitialized rs->lock:
ext4_fill_super ext4_register_sysfs // sysfs registered msg_ratelimit_interval_ms // Other processes modify rs->interval to // non-zero via msg_ratelimit_interval_ms ext4_orphan_cleanup ext4_msg(sb, KERN_INFO, "Errors on filesystem, " __ext4_msg ratelimit(&(EXT4SB(sb)->s_msg_ratelimit_state) if (!rs->interval) // do nothing if interval is 0 return 1; raw_spin_trylock_irqsave(&rs->lock, flags) raw_spin_trylock(lock) _raw_spin_trylock raw_spin_trylock spin_acquire(&lock->dep_map, 0, 1, RET_IP) lock_acquire __lock_acquire register_lock_class assign_lock_key dump_stack(); ratelimit_state_init(&sbi->s_msg_ratelimit_state, 5 * HZ, 10); raw_spin_lock_init(&rs->lock); // init rs->lock here
and get the following dump_stack:
========================================================= INFO: trying to register non-static key. The code is fine but needs lockdep annotation, or maybe you didn't initialize this object before use? turning off the locking correctness validator. CPU: 12 PID: 753 Comm: mount Tainted: G E 6.7.0-rc6-next-20231222 #504 [...] Call Trace: dump_stack_lvl+0xc5/0x170 dump_stack+0x18/0x30 register_lock_class+0x740/0x7c0 __lock_acquire+0x69/0x13a0 lock_acquire+0x120/0x450 _raw_spin_trylock+0x98/0xd0 ratelimit+0xf6/0x220 _ext4_msg+0x7f/0x160 [ext4] ext4_orphan_cleanup+0x665/0x740 [ext4] ext4_fill_super+0x21ea/0x2b10 [ext4] ext4_fill_super+0x14d/0x360 [ext4] [...] =========================================================
Normally interval is 0 until s_msg_ratelimit_state is initialized, so ___ratelimit() does nothing. But registering sysfs precedes initializing rs->lock, so it is possible to change rs->interval to a non-zero value via the msg_ratelimit_interval_ms interface of sysfs while rs->lock is uninitialized, and then a call to ext4_msg triggers the problem by accessing an uninitialized rs->lock. Therefore register sysfs after all initializations are complete to avoid such problems.(CVE-2024-40998)
In the Linux kernel, the following vulnerability has been resolved:
bpf: Take return from set_memory_rox() into account with bpf_jit_binary_lock_ro()
set_memory_rox() can fail, leaving memory unprotected.
Check return and bail out when bpf_jit_binary_lock_ro() returns an error.(CVE-2024-42067)
In the Linux kernel, the following vulnerability has been resolved:
net: nexthop: Initialize all fields in dumped nexthops
struct nexthop_grp contains two reserved fields that are not initialized by nla_put_nh_group(), and carry garbage. This can be observed e.g. with strace (edited for clarity):
# ip nexthop add id 1 dev lo
# ip nexthop add id 101 group 1
# strace -e recvmsg ip nexthop get id 101
...
recvmsg(... [{nla_len=12, nla_type=NHA_GROUP},
[{id=1, weight=0, resvd1=0x69, resvd2=0x67}]] ...) = 52
The fields are reserved and therefore not currently used. But as they are, they leak kernel memory, and the fact they are not just zero complicates repurposing of the fields for new ends. Initialize the full structure.(CVE-2024-42283)
In the Linux kernel, the following vulnerability has been resolved:
irqchip/imx-irqsteer: Handle runtime power management correctly
The power domain is automatically activated from clk_prepare(). However, on certain platforms like i.MX8QM and i.MX8QXP, the power-on handling invokes sleeping functions, which triggers the 'scheduling while atomic' bug in the context switch path during device probing:
BUG: scheduling while atomic: kworker/u13:1/48/0x00000002 Call trace: __schedule_bug+0x54/0x6c __schedule+0x7f0/0xa94 schedule+0x5c/0xc4 schedule_preempt_disabled+0x24/0x40 __mutex_lock.constprop.0+0x2c0/0x540 __mutex_lock_slowpath+0x14/0x20 mutex_lock+0x48/0x54 clk_prepare_lock+0x44/0xa0 clk_prepare+0x20/0x44 imx_irqsteer_resume+0x28/0xe0 pm_generic_runtime_resume+0x2c/0x44 __genpd_runtime_resume+0x30/0x80 genpd_runtime_resume+0xc8/0x2c0 __rpm_callback+0x48/0x1d8 rpm_callback+0x6c/0x78 rpm_resume+0x490/0x6b4 __pm_runtime_resume+0x50/0x94 irq_chip_pm_get+0x2c/0xa0 __irq_do_set_handler+0x178/0x24c irq_set_chained_handler_and_data+0x60/0xa4 mxc_gpio_probe+0x160/0x4b0
Cure this by implementing the irq_bus_lock/sync_unlock() interrupt chip callbacks and handle power management in them as they are invoked from non-atomic context.
tglx: Rewrote change log, added Fixes tag
In the Linux kernel, the following vulnerability has been resolved:
drm/gma500: fix null pointer dereference in psb_intel_lvds_get_modes
In psb_intel_lvds_get_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-42309)
In the Linux kernel, the following vulnerability has been resolved:
media: venus: fix use after free in vdec_close
There appears to be a possible use after free with vdec_close(). The firmware will add buffer release work to the work queue through HFI callbacks as a normal part of decoding. Randomly closing the decoder device from userspace during normal decoding can incur a read after free for inst.
Fix it by cancelling the work in vdec_close.(CVE-2024-42313)
In the Linux kernel, the following vulnerability has been resolved:
ipvs: properly dereference pe in ip_vs_add_service
Use pe directly to resolve sparse warning:
net/netfilter/ipvs/ip_vs_ctl.c:1471:27: warning: dereference of noderef expression(CVE-2024-42322)
In the Linux kernel, the following vulnerability has been resolved:
PCI: keystone: Fix NULL pointer dereference in case of DT error in ks_pcie_setup_rc_app_regs()
If IORESOURCE_MEM is not provided in Device Tree due to any error, resource_list_first_type() will return NULL and pci_parse_request_of_pci_ranges() will just emit a warning.
This will cause a NULL pointer dereference. Fix this bug by adding NULL return check.
Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-43823)
In the Linux kernel, the following vulnerability has been resolved:
leds: trigger: Unregister sysfs attributes before calling deactivate()
Triggers which have trigger specific sysfs attributes typically store related data in trigger-data allocated by the activate() callback and freed by the deactivate() callback.
Calling device_remove_groups() after calling deactivate() leaves a window where the sysfs attributes show/store functions could be called after deactivation and then operate on the just freed trigger-data.
Move the device_remove_groups() call to before deactivate() to close this race window.
This also makes the deactivation path properly do things in reverse order of the activation path which calls the activate() callback before calling device_add_groups().(CVE-2024-43830)
In the Linux kernel, the following vulnerability has been resolved:
md: fix deadlock between mddev_suspend and flush bio
Deadlock occurs when mddev is being suspended while some flush bio is in progress. It is a complex issue.
T1. the first flush is at the ending stage, it clears 'mddev->flush_bio' and tries to submit data, but is blocked because mddev is suspended by T4. T2. the second flush sets 'mddev->flush_bio', and attempts to queue md_submit_flush_data(), which is already running (T1) and won't execute again if on the same CPU as T1. T3. the third flush inc active_io and tries to flush, but is blocked because 'mddev->flush_bio' is not NULL (set by T2). T4. mddev_suspend() is called and waits for active_io dec to 0 which is inc by T3.
T1 T2 T3 T4 (flush 1) (flush 2) (third 3) (suspend) md_submit_flush_data mddev->flush_bio = NULL; . . md_flush_request . mddev->flush_bio = bio . queue submit_flushes . . . . md_handle_request . . active_io + 1 . . md_flush_request . . wait !mddev->flush_bio . . . . mddev_suspend . . wait !active_io . . . submit_flushes . queue_work md_submit_flush_data . //md_submit_flush_data is already running (T1) . md_handle_request wait resume
The root issue is non-atomic inc/dec of active_io during flush process. active_io is dec before md_submit_flush_data is queued, and inc soon after md_submit_flush_data() run. md_flush_request active_io + 1 submit_flushes active_io - 1 md_submit_flush_data md_handle_request active_io + 1 make_request active_io - 1
If active_io is dec after md_handle_request() instead of within submit_flushes(), make_request() can be called directly intead of md_handle_request() in md_submit_flush_data(), and active_io will only inc and dec once in the whole flush process. Deadlock will be fixed.
Additionally, the only difference between fixing the issue and before is that there is no return error handling of make_request(). But after previous patch cleaned md_write_start(), make_requst() only return error in raid5_make_request() by dm-raid, see commit 41425f96d7aa ("dm-raid456, md/raid456: fix a deadlock for dm-raid456 while io concurrent with reshape)". Since dm always splits data and flush operation into two separate io, io size of flush submitted by dm always is 0, make_request() will not be called in md_submit_flush_data(). To prevent future modifications from introducing issues, add WARN_ON to ensure make_request() no error is returned in this context.(CVE-2024-43855)
In the Linux kernel, the following vulnerability has been resolved:
memcg: protect concurrent access to mem_cgroup_idr
Commit 73f576c04b94 ("mm: memcontrol: fix cgroup creation failure after many small jobs") decoupled the memcg IDs from the CSS ID space to fix the cgroup creation failures. It introduced IDR to maintain the memcg ID space. The IDR depends on external synchronization mechanisms for modifications. For the mem_cgroup_idr, the idr_alloc() and idr_replace() happen within css callback and thus are protected through cgroup_mutex from concurrent modifications. However idr_remove() for mem_cgroup_idr was not protected against concurrency and can be run concurrently for different memcgs when they hit their refcnt to zero. Fix that.
We have been seeing list_lru based kernel crashes at a low frequency in our fleet for a long time. These crashes were in different part of list_lru code including list_lru_add(), list_lru_del() and reparenting code. Upon further inspection, it looked like for a given object (dentry and inode), the super_block's list_lru didn't have list_lru_one for the memcg of that object. The initial suspicions were either the object is not allocated through kmem_cache_alloc_lru() or somehow memcg_list_lru_alloc() failed to allocate list_lru_one() for a memcg but returned success. No evidence were found for these cases.
Looking more deeply, we started seeing situations where valid memcg's id is not present in mem_cgroup_idr and in some cases multiple valid memcgs have same id and mem_cgroup_idr is pointing to one of them. So, the most reasonable explanation is that these situations can happen due to race between multiple idr_remove() calls or race between idr_alloc()/idr_replace() and idr_remove(). These races are causing multiple memcgs to acquire the same ID and then offlining of one of them would cleanup list_lrus on the system for all of them. Later access from other memcgs to the list_lru cause crashes due to missing list_lru_one.(CVE-2024-43892)
In the Linux kernel, the following vulnerability has been resolved:
serial: core: check uartclk for zero to avoid divide by zero
Calling ioctl TIOCSSERIAL with an invalid baud_base can result in uartclk being zero, which will result in a divide by zero error in uart_get_divisor(). The check for uartclk being zero in uart_set_info() needs to be done before other settings are made as subsequent calls to ioctl TIOCSSERIAL for the same port would be impacted if the uartclk check was done where uartclk gets set.
Oops: divide error: 0000 PREEMPT SMP KASAN PTI RIP: 0010:uart_get_divisor (drivers/tty/serial/serial_core.c:580) Call Trace: <TASK> serial8250_get_divisor (drivers/tty/serial/8250/8250_port.c:2576 drivers/tty/serial/8250/8250_port.c:2589) serial8250_do_set_termios (drivers/tty/serial/8250/8250_port.c:502 drivers/tty/serial/8250/8250_port.c:2741) serial8250_set_termios (drivers/tty/serial/8250/8250_port.c:2862) uart_change_line_settings (./include/linux/spinlock.h:376 ./include/linux/serial_core.h:608 drivers/tty/serial/serial_core.c:222) uart_port_startup (drivers/tty/serial/serial_core.c:342) uart_startup (drivers/tty/serial/serial_core.c:368) uart_set_info (drivers/tty/serial/serial_core.c:1034) uart_set_info_user (drivers/tty/serial/serial_core.c:1059) tty_set_serial (drivers/tty/tty_io.c:2637) tty_ioctl (drivers/tty/tty_io.c:2647 drivers/tty/tty_io.c:2791) __x64_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:907 fs/ioctl.c:893 fs/ioctl.c:893) do_syscall_64 (arch/x86/entry/common.c:52 (discriminator 1) arch/x86/entry/common.c:83 (discriminator 1)) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
Rule: add(CVE-2024-43893)
In the Linux kernel, the following vulnerability has been resolved:
fou: remove warn in gue_gro_receive on unsupported protocol
Drop the WARN_ON_ONCE inn gue_gro_receive if the encapsulated type is not known or does not have a GRO handler.
Such a packet is easily constructed. Syzbot generates them and sets off this warning.
Remove the warning as it is expected and not actionable.
The warning was previously reduced from WARN_ON to WARN_ON_ONCE in commit 270136613bf7 ("fou: Do WARN_ON_ONCE in gue_gro_receive for bad proto callbacks").(CVE-2024-44940)
In the Linux kernel, the following vulnerability has been resolved:
atm: idt77252: prevent use after free in dequeue_rx()
We can't dereference "skb" after calling vcc->push() because the skb is released.(CVE-2024-44998)
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:
s390/dasd: fix error recovery leading to data corruption on ESE devices
Extent Space Efficient (ESE) or thin provisioned volumes need to be formatted on demand during usual IO processing.
The dasd_ese_needs_format function checks for error codes that signal the non existence of a proper track format.
The check for incorrect length is to imprecise since other error cases leading to transport of insufficient data also have this flag set. This might lead to data corruption in certain error cases for example during a storage server warmstart.
Fix by removing the check for incorrect length and replacing by explicitly checking for invalid track format in transport mode.
Also remove the check for file protected since this is not a valid ESE handling case.(CVE-2024-45026)
In the Linux kernel, the following vulnerability has been resolved:
nfc: pn533: Add poll mod list filling check
In case of im_protocols value is 1 and tm_protocols value is 0 this combination successfully passes the check 'if (!im_protocols && !tm_protocols)' in the nfc_start_poll(). But then after pn533_poll_create_mod_list() call in pn533_start_poll() poll mod list will remain empty and dev->poll_mod_count will remain 0 which lead to division by zero.
Normally no im protocol has value 1 in the mask, so this combination is not expected by driver. But these protocol values actually come from userspace via Netlink interface (NFC_CMD_START_POLL operation). So a broken or malicious program may pass a message containing a "bad" combination of protocol parameter values so that dev->poll_mod_count is not incremented inside pn533_poll_create_mod_list(), thus leading to division by zero. Call trace looks like: nfc_genl_start_poll() nfc_start_poll() ->start_poll() pn533_start_poll()
Add poll mod list filling check.
Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-46676)
In the Linux kernel, the following vulnerability has been resolved:
usb: typec: ucsi: Fix null pointer dereference in trace
ucsi_register_altmode checks IS_ERR for the alt pointer and treats NULL as valid. When CONFIG_TYPEC_DP_ALTMODE is not enabled, ucsi_register_displayport returns NULL which causes a NULL pointer dereference in trace. Rather than return NULL, call typec_port_register_altmode to register DisplayPort alternate mode as a non-controllable mode when CONFIG_TYPEC_DP_ALTMODE is not enabled.(CVE-2024-46719)
In the Linux kernel, the following vulnerability has been resolved:
bpf: Remove tst_run from lwt_seg6local_prog_ops.
The syzbot reported that the lwt_seg6 related BPF ops can be invoked via bpf_test_run() without without entering input_action_end_bpf() first.
Martin KaFai Lau said that self test for BPF_PROG_TYPE_LWT_SEG6LOCAL probably didn't work since it was introduced in commit 04d4b274e2a ("ipv6: sr: Add seg6local action End.BPF"). The reason is that the per-CPU variable seg6_bpf_srh_states::srh is never assigned in the self test case but each BPF function expects it.
Remove test_run for BPF_PROG_TYPE_LWT_SEG6LOCAL.(CVE-2024-46754)
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:
ksmbd: unset the binding mark of a reused connection
Steve French reported null pointer dereference error from sha256 lib. cifs.ko can send session setup requests on reused connection. If reused connection is used for binding session, conn->binding can still remain true and generate_preauth_hash() will not set sess->Preauth_HashValue and it will be NULL. It is used as a material to create an encryption key in ksmbd_gen_smb311_encryptionkey. ->Preauth_HashValue cause null pointer dereference error from crypto_shash_update().
BUG: kernel NULL pointer dereference, address: 0000000000000000
PF: supervisor read access in kernel mode
PF: error_code(0x0000) - not-present page
PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 8 PID: 429254 Comm: kworker/8:39 Hardware name: LENOVO 20MAS08500/20MAS08500, BIOS N2CET69W (1.52 ) Workqueue: ksmbd-io handle_ksmbd_work [ksmbd] RIP: 0010:lib_sha256_base_do_update.isra.0+0x11e/0x1d0 [sha256_ssse3] <TASK> ? show_regs+0x6d/0x80 ? __die+0x24/0x80 ? page_fault_oops+0x99/0x1b0 ? do_user_addr_fault+0x2ee/0x6b0 ? exc_page_fault+0x83/0x1b0 ? asm_exc_page_fault+0x27/0x30 ? __pfx_sha256_transform_rorx+0x10/0x10 [sha256_ssse3] ? lib_sha256_base_do_update.isra.0+0x11e/0x1d0 [sha256_ssse3] ? __pfx_sha256_transform_rorx+0x10/0x10 [sha256_ssse3] ? __pfx_sha256_transform_rorx+0x10/0x10 [sha256_ssse3] _sha256_update+0x77/0xa0 [sha256_ssse3] sha256_avx2_update+0x15/0x30 [sha256_ssse3] crypto_shash_update+0x1e/0x40 hmac_update+0x12/0x20 crypto_shash_update+0x1e/0x40 generate_key+0x234/0x380 [ksmbd] generate_smb3encryptionkey+0x40/0x1c0 [ksmbd] ksmbd_gen_smb311_encryptionkey+0x72/0xa0 [ksmbd] ntlm_authenticate.isra.0+0x423/0x5d0 [ksmbd] smb2_sess_setup+0x952/0xaa0 [ksmbd] __process_request+0xa3/0x1d0 [ksmbd] __handle_ksmbd_work+0x1c4/0x2f0 [ksmbd] handle_ksmbd_work+0x2d/0xa0 [ksmbd] process_one_work+0x16c/0x350 worker_thread+0x306/0x440 ? __pfx_worker_thread+0x10/0x10 kthread+0xef/0x120 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x44/0x70 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 </TASK>(CVE-2024-46795)
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: the warning dereferencing obj for nbio_v7_4
if ras_manager obj null, don't print NBIO err data(CVE-2024-46819)
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:
btrfs: clean up our handling of refs == 0 in snapshot delete
In reada we BUG_ON(refs == 0), which could be unkind since we aren't holding a lock on the extent leaf and thus could get a transient incorrect answer. In walk_down_proc we also BUG_ON(refs == 0), which could happen if we have extent tree corruption. Change that to return -EUCLEAN. In do_walk_down() we catch this case and handle it correctly, however we return -EIO, which -EUCLEAN is a more appropriate error code. Finally in walk_up_proc we have the same BUG_ON(refs == 0), so convert that to proper error handling. Also adjust the error message so we can actually do something with the information.(CVE-2024-46840)
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:
net: dpaa: Pad packets to ETH_ZLEN
When sending packets under 60 bytes, up to three bytes of the buffer following the data may be leaked. Avoid this by extending all packets to ETH_ZLEN, ensuring nothing is leaked in the padding. This bug can be reproduced by running
$ ping -s 11 destination(CVE-2024-46854)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nft_socket: fix sk refcount leaks
We must put 'sk' reference before returning.(CVE-2024-46855)
In the Linux kernel, the following vulnerability has been resolved:
mptcp: pm: Fix uaf in __timer_delete_sync
There are two paths to access mptcp_pm_del_add_timer, result in a race condition:
CPU1 CPU2
==== ====
net_rx_action
napi_poll netlink_sendmsg
__napi_poll netlink_unicast
process_backlog netlink_unicast_kernel
__netif_receive_skb genl_rcv
__netif_receive_skb_one_core netlink_rcv_skb
NF_HOOK genl_rcv_msg
ip_local_deliver_finish genl_family_rcv_msg
ip_protocol_deliver_rcu genl_family_rcv_msg_doit
tcp_v4_rcv mptcp_pm_nl_flush_addrs_doit
tcp_v4_do_rcv mptcp_nl_remove_addrs_list
tcp_rcv_established mptcp_pm_remove_addrs_and_subflows
tcp_data_queue remove_anno_list_by_saddr
mptcp_incoming_options mptcp_pm_del_add_timer
mptcp_pm_del_add_timer kfree(entry)
In remove_anno_list_by_saddr(running on CPU2), after leaving the critical zone protected by "pm.lock", the entry will be released, which leads to the occurrence of uaf in the mptcp_pm_del_add_timer(running on CPU1).
Keeping a reference to add_timer inside the lock, and calling sk_stop_timer_sync() with this reference, instead of "entry->add_timer".
Move list_del(&entry->list) to mptcp_pm_del_add_timer and inside the pm lock, do not directly access any members of the entry outside the pm lock, which can avoid similar "entry->x" uaf.(CVE-2024-46858)
In the Linux kernel, the following vulnerability has been resolved:
crypto: stm32/cryp - call finalize with bh disabled
The finalize operation in interrupt mode produce a produces a spinlock recursion warning. The reason is the fact that BH must be disabled during this process.(CVE-2024-47658)
In the Linux kernel, the following vulnerability has been resolved:
spi: hisi-kunpeng: Add verification for the max_frequency provided by the firmware
If the value of max_speed_hz is 0, it may cause a division by zero error in hisi_calc_effective_speed(). The value of max_speed_hz is provided by firmware. Firmware is generally considered as a trusted domain. However, as division by zero errors can cause system failure, for defense measure, the value of max_speed is validated here. So 0 is regarded as invalid and an error code is returned.(CVE-2024-47664)
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:
USB: usbtmc: prevent kernel-usb-infoleak
The syzbot reported a kernel-usb-infoleak in usbtmc_write, we need to clear the structure before filling fields.(CVE-2024-47671)
In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlwifi: mvm: don't wait for tx queues if firmware is dead
There is a WARNING in iwl_trans_wait_tx_queues_empty() (that was recently converted from just a message), that can be hit if we wait for TX queues to become empty after firmware died. Clearly, we can't expect anything from the firmware after it's declared dead.
Don't call iwl_trans_wait_tx_queues_empty() in this case. While it could be a good idea to stop the flow earlier, the flush functions do some maintenance work that is not related to the firmware, so keep that part of the code running even when the firmware is not running.
| URL | Type | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"kernel-5.10.0-136.97.0.178.oe2203sp1.aarch64.rpm",
"kernel-debuginfo-5.10.0-136.97.0.178.oe2203sp1.aarch64.rpm",
"kernel-debugsource-5.10.0-136.97.0.178.oe2203sp1.aarch64.rpm",
"kernel-devel-5.10.0-136.97.0.178.oe2203sp1.aarch64.rpm",
"kernel-headers-5.10.0-136.97.0.178.oe2203sp1.aarch64.rpm",
"kernel-source-5.10.0-136.97.0.178.oe2203sp1.aarch64.rpm",
"kernel-tools-5.10.0-136.97.0.178.oe2203sp1.aarch64.rpm",
"kernel-tools-debuginfo-5.10.0-136.97.0.178.oe2203sp1.aarch64.rpm",
"kernel-tools-devel-5.10.0-136.97.0.178.oe2203sp1.aarch64.rpm",
"perf-5.10.0-136.97.0.178.oe2203sp1.aarch64.rpm",
"perf-debuginfo-5.10.0-136.97.0.178.oe2203sp1.aarch64.rpm",
"python3-perf-5.10.0-136.97.0.178.oe2203sp1.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-136.97.0.178.oe2203sp1.aarch64.rpm"
],
"src": [
"kernel-5.10.0-136.97.0.178.oe2203sp1.src.rpm"
],
"x86_64": [
"kernel-5.10.0-136.97.0.178.oe2203sp1.x86_64.rpm",
"kernel-debuginfo-5.10.0-136.97.0.178.oe2203sp1.x86_64.rpm",
"kernel-debugsource-5.10.0-136.97.0.178.oe2203sp1.x86_64.rpm",
"kernel-devel-5.10.0-136.97.0.178.oe2203sp1.x86_64.rpm",
"kernel-headers-5.10.0-136.97.0.178.oe2203sp1.x86_64.rpm",
"kernel-source-5.10.0-136.97.0.178.oe2203sp1.x86_64.rpm",
"kernel-tools-5.10.0-136.97.0.178.oe2203sp1.x86_64.rpm",
"kernel-tools-debuginfo-5.10.0-136.97.0.178.oe2203sp1.x86_64.rpm",
"kernel-tools-devel-5.10.0-136.97.0.178.oe2203sp1.x86_64.rpm",
"perf-5.10.0-136.97.0.178.oe2203sp1.x86_64.rpm",
"perf-debuginfo-5.10.0-136.97.0.178.oe2203sp1.x86_64.rpm",
"python3-perf-5.10.0-136.97.0.178.oe2203sp1.x86_64.rpm",
"python3-perf-debuginfo-5.10.0-136.97.0.178.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.97.0.178.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\ni40e: Fix kernel crash during module removal\r\n\r\nThe driver incorrectly frees client instance and subsequent\ni40e module removal leads to kernel crash.\r\n\r\nReproducer:\n1. Do ethtool offline test followed immediately by another one\nhost# ethtool -t eth0 offline; ethtool -t eth0 offline\n2. Remove recursively irdma module that also removes i40e module\nhost# modprobe -r irdma\r\n\r\nResult:\n[ 8675.035651] i40e 0000:3d:00.0 eno1: offline testing starting\n[ 8675.193774] i40e 0000:3d:00.0 eno1: testing finished\n[ 8675.201316] i40e 0000:3d:00.0 eno1: offline testing starting\n[ 8675.358921] i40e 0000:3d:00.0 eno1: testing finished\n[ 8675.496921] i40e 0000:3d:00.0: IRDMA hardware initialization FAILED init_state=2 status=-110\n[ 8686.188955] i40e 0000:3d:00.1: i40e_ptp_stop: removed PHC on eno2\n[ 8686.943890] i40e 0000:3d:00.1: Deleted LAN device PF1 bus=0x3d dev=0x00 func=0x01\n[ 8686.952669] i40e 0000:3d:00.0: i40e_ptp_stop: removed PHC on eno1\n[ 8687.761787] BUG: kernel NULL pointer dereference, address: 0000000000000030\n[ 8687.768755] #PF: supervisor read access in kernel mode\n[ 8687.773895] #PF: error_code(0x0000) - not-present page\n[ 8687.779034] PGD 0 P4D 0\n[ 8687.781575] Oops: 0000 [#1] PREEMPT SMP NOPTI\n[ 8687.785935] CPU: 51 PID: 172891 Comm: rmmod Kdump: loaded Tainted: G W I 5.19.0+ #2\n[ 8687.794800] Hardware name: Intel Corporation S2600WFD/S2600WFD, BIOS SE5C620.86B.0X.02.0001.051420190324 05/14/2019\n[ 8687.805222] RIP: 0010:i40e_lan_del_device+0x13/0xb0 [i40e]\n[ 8687.810719] Code: d4 84 c0 0f 84 b8 25 01 00 e9 9c 25 01 00 41 bc f4 ff ff ff eb 91 90 0f 1f 44 00 00 41 54 55 53 48 8b 87 58 08 00 00 48 89 fb \u0026lt;48\u0026gt; 8b 68 30 48 89 ef e8 21 8a 0f d5 48 89 ef e8 a9 78 0f d5 48 8b\n[ 8687.829462] RSP: 0018:ffffa604072efce0 EFLAGS: 00010202\n[ 8687.834689] RAX: 0000000000000000 RBX: ffff8f43833b2000 RCX: 0000000000000000\n[ 8687.841821] RDX: 0000000000000000 RSI: ffff8f4b0545b298 RDI: ffff8f43833b2000\n[ 8687.848955] RBP: ffff8f43833b2000 R08: 0000000000000001 R09: 0000000000000000\n[ 8687.856086] R10: 0000000000000000 R11: 000ffffffffff000 R12: ffff8f43833b2ef0\n[ 8687.863218] R13: ffff8f43833b2ef0 R14: ffff915103966000 R15: ffff8f43833b2008\n[ 8687.870342] FS: 00007f79501c3740(0000) GS:ffff8f4adffc0000(0000) knlGS:0000000000000000\n[ 8687.878427] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 8687.884174] CR2: 0000000000000030 CR3: 000000014276e004 CR4: 00000000007706e0\n[ 8687.891306] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[ 8687.898441] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[ 8687.905572] PKRU: 55555554\n[ 8687.908286] Call Trace:\n[ 8687.910737] \u0026lt;TASK\u0026gt;\n[ 8687.912843] i40e_remove+0x2c0/0x330 [i40e]\n[ 8687.917040] pci_device_remove+0x33/0xa0\n[ 8687.920962] device_release_driver_internal+0x1aa/0x230\n[ 8687.926188] driver_detach+0x44/0x90\n[ 8687.929770] bus_remove_driver+0x55/0xe0\n[ 8687.933693] pci_unregister_driver+0x2a/0xb0\n[ 8687.937967] i40e_exit_module+0xc/0xf48 [i40e]\r\n\r\nTwo offline tests cause IRDMA driver failure (ETIMEDOUT) and this\nfailure is indicated back to i40e_client_subtask() that calls\ni40e_client_del_instance() to free client instance referenced\nby pf-\u0026gt;cinst and sets this pointer to NULL. During the module\nremoval i40e_remove() calls i40e_lan_del_device() that dereferences\npf-\u0026gt;cinst that is NULL -\u0026gt; crash.\nDo not remove client instance when client open callbacks fails and\njust clear __I40E_CLIENT_INSTANCE_OPENED bit. The driver also needs\nto take care about this situation (when netdev is up and client\nis NOT opened) in i40e_notify_client_of_netdev_close() and\ncalls client close callback only when __I40E_CLIENT_INSTANCE_OPENED\nis set.(CVE-2022-48688)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntracing/osnoise: Do not unregister events twice\r\n\r\nNicolas reported that using:\r\n\r\n # trace-cmd record -e all -M 10 -p osnoise --poll\r\n\r\nResulted in the following kernel warning:\r\n\r\n ------------[ cut here ]------------\n WARNING: CPU: 0 PID: 1217 at kernel/tracepoint.c:404 tracepoint_probe_unregister+0x280/0x370\n [...]\n CPU: 0 PID: 1217 Comm: trace-cmd Not tainted 5.17.0-rc6-next-20220307-nico+ #19\n RIP: 0010:tracepoint_probe_unregister+0x280/0x370\n [...]\n CR2: 00007ff919b29497 CR3: 0000000109da4005 CR4: 0000000000170ef0\n Call Trace:\n \u0026lt;TASK\u0026gt;\n osnoise_workload_stop+0x36/0x90\n tracing_set_tracer+0x108/0x260\n tracing_set_trace_write+0x94/0xd0\n ? __check_object_size.part.0+0x10a/0x150\n ? selinux_file_permission+0x104/0x150\n vfs_write+0xb5/0x290\n ksys_write+0x5f/0xe0\n do_syscall_64+0x3b/0x90\n entry_SYSCALL_64_after_hwframe+0x44/0xae\n RIP: 0033:0x7ff919a18127\n [...]\n ---[ end trace 0000000000000000 ]---\r\n\r\nThe warning complains about an attempt to unregister an\nunregistered tracepoint.\r\n\r\nThis happens on trace-cmd because it first stops tracing, and\nthen switches the tracer to nop. Which is equivalent to:\r\n\r\n # cd /sys/kernel/tracing/\n # echo osnoise \u0026gt; current_tracer\n # echo 0 \u0026gt; tracing_on\n # echo nop \u0026gt; current_tracer\r\n\r\nThe osnoise tracer stops the workload when no trace instance\nis actually collecting data. This can be caused both by\ndisabling tracing or disabling the tracer itself.\r\n\r\nTo avoid unregistering events twice, use the existing\ntrace_osnoise_callback_enabled variable to check if the events\n(and the workload) are actually active before trying to\ndeactivate them.(CVE-2022-48848)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nUSB: gadgetfs: Fix race between mounting and unmounting\r\n\r\nThe syzbot fuzzer and Gerald Lee have identified a use-after-free bug\nin the gadgetfs driver, involving processes concurrently mounting and\nunmounting the gadgetfs filesystem. In particular, gadgetfs_fill_super()\ncan race with gadgetfs_kill_sb(), causing the latter to deallocate\nthe_device while the former is using it. The output from KASAN says,\nin part:\r\n\r\nBUG: KASAN: use-after-free in instrument_atomic_read_write include/linux/instrumented.h:102 [inline]\nBUG: KASAN: use-after-free in atomic_fetch_sub_release include/linux/atomic/atomic-instrumented.h:176 [inline]\nBUG: KASAN: use-after-free in __refcount_sub_and_test include/linux/refcount.h:272 [inline]\nBUG: KASAN: use-after-free in __refcount_dec_and_test include/linux/refcount.h:315 [inline]\nBUG: KASAN: use-after-free in refcount_dec_and_test include/linux/refcount.h:333 [inline]\nBUG: KASAN: use-after-free in put_dev drivers/usb/gadget/legacy/inode.c:159 [inline]\nBUG: KASAN: use-after-free in gadgetfs_kill_sb+0x33/0x100 drivers/usb/gadget/legacy/inode.c:2086\nWrite of size 4 at addr ffff8880276d7840 by task syz-executor126/18689\r\n\r\nCPU: 0 PID: 18689 Comm: syz-executor126 Not tainted 6.1.0-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022\nCall Trace:\n \u0026lt;TASK\u0026gt;\n...\n atomic_fetch_sub_release include/linux/atomic/atomic-instrumented.h:176 [inline]\n __refcount_sub_and_test include/linux/refcount.h:272 [inline]\n __refcount_dec_and_test include/linux/refcount.h:315 [inline]\n refcount_dec_and_test include/linux/refcount.h:333 [inline]\n put_dev drivers/usb/gadget/legacy/inode.c:159 [inline]\n gadgetfs_kill_sb+0x33/0x100 drivers/usb/gadget/legacy/inode.c:2086\n deactivate_locked_super+0xa7/0xf0 fs/super.c:332\n vfs_get_super fs/super.c:1190 [inline]\n get_tree_single+0xd0/0x160 fs/super.c:1207\n vfs_get_tree+0x88/0x270 fs/super.c:1531\n vfs_fsconfig_locked fs/fsopen.c:232 [inline]\r\n\r\nThe simplest solution is to ensure that gadgetfs_fill_super() and\ngadgetfs_kill_sb() are serialized by making them both acquire a new\nmutex.(CVE-2022-48869)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nefi: fix NULL-deref in init error path\r\n\r\nIn cases where runtime services are not supported or have been disabled,\nthe runtime services workqueue will never have been allocated.\r\n\r\nDo not try to destroy the workqueue unconditionally in the unlikely\nevent that EFI initialisation fails to avoid dereferencing a NULL\npointer.(CVE-2022-48879)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/i915/gt: Cleanup partial engine discovery failures\r\n\r\nIf we abort driver initialisation in the middle of gt/engine discovery,\nsome engines will be fully setup and some not. Those incompletely setup\nengines only have \u0026apos;engine-\u0026gt;release == NULL\u0026apos; and so will leak any of the\ncommon objects allocated.\r\n\r\nv2:\n - Drop the destroy_pinned_context() helper for now. It\u0026apos;s not really\n worth it with just a single callsite at the moment. (Janusz)(CVE-2022-48893)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: vivid: fix compose size exceed boundary\r\n\r\nsyzkaller found a bug:\r\n\r\n BUG: unable to handle page fault for address: ffffc9000a3b1000\n #PF: supervisor write access in kernel mode\n #PF: error_code(0x0002) - not-present page\n PGD 100000067 P4D 100000067 PUD 10015f067 PMD 1121ca067 PTE 0\n Oops: 0002 [#1] PREEMPT SMP\n CPU: 0 PID: 23489 Comm: vivid-000-vid-c Not tainted 6.1.0-rc1+ #512\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014\n RIP: 0010:memcpy_erms+0x6/0x10\n[...]\n Call Trace:\n \u0026lt;TASK\u0026gt;\n ? tpg_fill_plane_buffer+0x856/0x15b0\n vivid_fillbuff+0x8ac/0x1110\n vivid_thread_vid_cap_tick+0x361/0xc90\n vivid_thread_vid_cap+0x21a/0x3a0\n kthread+0x143/0x180\n ret_from_fork+0x1f/0x30\n \u0026lt;/TASK\u0026gt;\r\n\r\nThis is because we forget to check boundary after adjust compose-\u0026gt;height\nint V4L2_SEL_TGT_CROP case. Add v4l2_rect_map_inside() to fix this problem\nfor this case.(CVE-2022-48945)\r\n\r\nA flaw possibility of memory leak in the Linux kernel cpu_entry_area mapping of X86 CPU data to memory was found in the way user can guess location of exception stack(s) or other important data. A local user could use this flaw to get access to some important data with expected location in memory.(CVE-2023-0597)\r\n\r\nFrom the upstream fix below: The watchdog_timer can schedule tx_timeout_task and watchdog_work can also arm watchdog_timer [..] Although del_timer_sync() and cancel_work_sync() are called in cyttsp4_remove(), the timer and workqueue could still be rearmed. As a result, the possible use after free bugs could happen.\r\n\r\nUpstream commit:\nhttps://github.com/torvalds/linux/commit/dbe836576f12743a7d2d170ad4ad4fd324c4d47a(CVE-2023-4134)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nefivarfs: force RO when remounting if SetVariable is not supported\r\n\r\nIf SetVariable at runtime is not supported by the firmware we never assign\na callback for that function. At the same time mount the efivarfs as\nRO so no one can call that. However, we never check the permission flags\nwhen someone remounts the filesystem as RW. As a result this leads to a\ncrash looking like this:\r\n\r\n$ mount -o remount,rw /sys/firmware/efi/efivars\n$ efi-updatevar -f PK.auth PK\r\n\r\n[ 303.279166] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000\n[ 303.280482] Mem abort info:\n[ 303.280854] ESR = 0x0000000086000004\n[ 303.281338] EC = 0x21: IABT (current EL), IL = 32 bits\n[ 303.282016] SET = 0, FnV = 0\n[ 303.282414] EA = 0, S1PTW = 0\n[ 303.282821] FSC = 0x04: level 0 translation fault\n[ 303.283771] user pgtable: 4k pages, 48-bit VAs, pgdp=000000004258c000\n[ 303.284913] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000\n[ 303.286076] Internal error: Oops: 0000000086000004 [#1] PREEMPT SMP\n[ 303.286936] Modules linked in: qrtr tpm_tis tpm_tis_core crct10dif_ce arm_smccc_trng rng_core drm fuse ip_tables x_tables ipv6\n[ 303.288586] CPU: 1 PID: 755 Comm: efi-updatevar Not tainted 6.3.0-rc1-00108-gc7d0c4695c68 #1\n[ 303.289748] Hardware name: Unknown Unknown Product/Unknown Product, BIOS 2023.04-00627-g88336918701d 04/01/2023\n[ 303.291150] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[ 303.292123] pc : 0x0\n[ 303.292443] lr : efivar_set_variable_locked+0x74/0xec\n[ 303.293156] sp : ffff800008673c10\n[ 303.293619] x29: ffff800008673c10 x28: ffff0000037e8000 x27: 0000000000000000\n[ 303.294592] x26: 0000000000000800 x25: ffff000002467400 x24: 0000000000000027\n[ 303.295572] x23: ffffd49ea9832000 x22: ffff0000020c9800 x21: ffff000002467000\n[ 303.296566] x20: 0000000000000001 x19: 00000000000007fc x18: 0000000000000000\n[ 303.297531] x17: 0000000000000000 x16: 0000000000000000 x15: 0000aaaac807ab54\n[ 303.298495] x14: ed37489f673633c0 x13: 71c45c606de13f80 x12: 47464259e219acf4\n[ 303.299453] x11: ffff000002af7b01 x10: 0000000000000003 x9 : 0000000000000002\n[ 303.300431] x8 : 0000000000000010 x7 : ffffd49ea8973230 x6 : 0000000000a85201\n[ 303.301412] x5 : 0000000000000000 x4 : ffff0000020c9800 x3 : 00000000000007fc\n[ 303.302370] x2 : 0000000000000027 x1 : ffff000002467400 x0 : ffff000002467000\n[ 303.303341] Call trace:\n[ 303.303679] 0x0\n[ 303.303938] efivar_entry_set_get_size+0x98/0x16c\n[ 303.304585] efivarfs_file_write+0xd0/0x1a4\n[ 303.305148] vfs_write+0xc4/0x2e4\n[ 303.305601] ksys_write+0x70/0x104\n[ 303.306073] __arm64_sys_write+0x1c/0x28\n[ 303.306622] invoke_syscall+0x48/0x114\n[ 303.307156] el0_svc_common.constprop.0+0x44/0xec\n[ 303.307803] do_el0_svc+0x38/0x98\n[ 303.308268] el0_svc+0x2c/0x84\n[ 303.308702] el0t_64_sync_handler+0xf4/0x120\n[ 303.309293] el0t_64_sync+0x190/0x194\n[ 303.309794] Code: ???????? ???????? ???????? ???????? (????????)\n[ 303.310612] ---[ end trace 0000000000000000 ]---\r\n\r\nFix this by adding a .reconfigure() function to the fs operations which\nwe can use to check the requested flags and deny anything that\u0026apos;s not RO\nif the firmware doesn\u0026apos;t implement SetVariable at runtime.(CVE-2023-52463)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsched/psi: Fix use-after-free in ep_remove_wait_queue()\r\n\r\nIf a non-root cgroup gets removed when there is a thread that registered\ntrigger and is polling on a pressure file within the cgroup, the polling\nwaitqueue gets freed in the following path:\r\n\r\n do_rmdir\n cgroup_rmdir\n kernfs_drain_open_files\n cgroup_file_release\n cgroup_pressure_release\n psi_trigger_destroy\r\n\r\nHowever, the polling thread still has a reference to the pressure file and\nwill access the freed waitqueue when the file is closed or upon exit:\r\n\r\n fput\n ep_eventpoll_release\n ep_free\n ep_remove_wait_queue\n remove_wait_queue\r\n\r\nThis results in use-after-free as pasted below.\r\n\r\nThe fundamental problem here is that cgroup_file_release() (and\nconsequently waitqueue\u0026apos;s lifetime) is not tied to the file\u0026apos;s real lifetime.\nUsing wake_up_pollfree() here might be less than ideal, but it is in line\nwith the comment at commit 42288cb44c4b (\u0026quot;wait: add wake_up_pollfree()\u0026quot;)\nsince the waitqueue\u0026apos;s lifetime is not tied to file\u0026apos;s one and can be\nconsidered as another special case. While this would be fixable by somehow\nmaking cgroup_file_release() be tied to the fput(), it would require\nsizable refactoring at cgroups or higher layer which might be more\njustifiable if we identify more cases like this.\r\n\r\n BUG: KASAN: use-after-free in _raw_spin_lock_irqsave+0x60/0xc0\n Write of size 4 at addr ffff88810e625328 by task a.out/4404\r\n\r\n\tCPU: 19 PID: 4404 Comm: a.out Not tainted 6.2.0-rc6 #38\n\tHardware name: Amazon EC2 c5a.8xlarge/, BIOS 1.0 10/16/2017\n\tCall Trace:\n\t\u0026lt;TASK\u0026gt;\n\tdump_stack_lvl+0x73/0xa0\n\tprint_report+0x16c/0x4e0\n\tkasan_report+0xc3/0xf0\n\tkasan_check_range+0x2d2/0x310\n\t_raw_spin_lock_irqsave+0x60/0xc0\n\tremove_wait_queue+0x1a/0xa0\n\tep_free+0x12c/0x170\n\tep_eventpoll_release+0x26/0x30\n\t__fput+0x202/0x400\n\ttask_work_run+0x11d/0x170\n\tdo_exit+0x495/0x1130\n\tdo_group_exit+0x100/0x100\n\tget_signal+0xd67/0xde0\n\tarch_do_signal_or_restart+0x2a/0x2b0\n\texit_to_user_mode_prepare+0x94/0x100\n\tsyscall_exit_to_user_mode+0x20/0x40\n\tdo_syscall_64+0x52/0x90\n\tentry_SYSCALL_64_after_hwframe+0x63/0xcd\n\t\u0026lt;/TASK\u0026gt;\r\n\r\n Allocated by task 4404:\r\n\r\n\tkasan_set_track+0x3d/0x60\n\t__kasan_kmalloc+0x85/0x90\n\tpsi_trigger_create+0x113/0x3e0\n\tpressure_write+0x146/0x2e0\n\tcgroup_file_write+0x11c/0x250\n\tkernfs_fop_write_iter+0x186/0x220\n\tvfs_write+0x3d8/0x5c0\n\tksys_write+0x90/0x110\n\tdo_syscall_64+0x43/0x90\n\tentry_SYSCALL_64_after_hwframe+0x63/0xcd\r\n\r\n Freed by task 4407:\r\n\r\n\tkasan_set_track+0x3d/0x60\n\tkasan_save_free_info+0x27/0x40\n\t____kasan_slab_free+0x11d/0x170\n\tslab_free_freelist_hook+0x87/0x150\n\t__kmem_cache_free+0xcb/0x180\n\tpsi_trigger_destroy+0x2e8/0x310\n\tcgroup_file_release+0x4f/0xb0\n\tkernfs_drain_open_files+0x165/0x1f0\n\tkernfs_drain+0x162/0x1a0\n\t__kernfs_remove+0x1fb/0x310\n\tkernfs_remove_by_name_ns+0x95/0xe0\n\tcgroup_addrm_files+0x67f/0x700\n\tcgroup_destroy_locked+0x283/0x3c0\n\tcgroup_rmdir+0x29/0x100\n\tkernfs_iop_rmdir+0xd1/0x140\n\tvfs_rmdir+0xfe/0x240\n\tdo_rmdir+0x13d/0x280\n\t__x64_sys_rmdir+0x2c/0x30\n\tdo_syscall_64+0x43/0x90\n\tentry_SYSCALL_64_after_hwframe+0x63/0xcd(CVE-2023-52707)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncifs: Fix use-after-free in rdata-\u0026gt;read_into_pages()\r\n\r\nWhen the network status is unstable, use-after-free may occur when\nread data from the server.\r\n\r\n BUG: KASAN: use-after-free in readpages_fill_pages+0x14c/0x7e0\r\n\r\n Call Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x38/0x4c\n print_report+0x16f/0x4a6\n kasan_report+0xb7/0x130\n readpages_fill_pages+0x14c/0x7e0\n cifs_readv_receive+0x46d/0xa40\n cifs_demultiplex_thread+0x121c/0x1490\n kthread+0x16b/0x1a0\n ret_from_fork+0x2c/0x50\n \u0026lt;/TASK\u0026gt;\r\n\r\n Allocated by task 2535:\n kasan_save_stack+0x22/0x50\n kasan_set_track+0x25/0x30\n __kasan_kmalloc+0x82/0x90\n cifs_readdata_direct_alloc+0x2c/0x110\n cifs_readdata_alloc+0x2d/0x60\n cifs_readahead+0x393/0xfe0\n read_pages+0x12f/0x470\n page_cache_ra_unbounded+0x1b1/0x240\n filemap_get_pages+0x1c8/0x9a0\n filemap_read+0x1c0/0x540\n cifs_strict_readv+0x21b/0x240\n vfs_read+0x395/0x4b0\n ksys_read+0xb8/0x150\n do_syscall_64+0x3f/0x90\n entry_SYSCALL_64_after_hwframe+0x72/0xdc\r\n\r\n Freed by task 79:\n kasan_save_stack+0x22/0x50\n kasan_set_track+0x25/0x30\n kasan_save_free_info+0x2e/0x50\n __kasan_slab_free+0x10e/0x1a0\n __kmem_cache_free+0x7a/0x1a0\n cifs_readdata_release+0x49/0x60\n process_one_work+0x46c/0x760\n worker_thread+0x2a4/0x6f0\n kthread+0x16b/0x1a0\n ret_from_fork+0x2c/0x50\r\n\r\n Last potentially related work creation:\n kasan_save_stack+0x22/0x50\n __kasan_record_aux_stack+0x95/0xb0\n insert_work+0x2b/0x130\n __queue_work+0x1fe/0x660\n queue_work_on+0x4b/0x60\n smb2_readv_callback+0x396/0x800\n cifs_abort_connection+0x474/0x6a0\n cifs_reconnect+0x5cb/0xa50\n cifs_readv_from_socket.cold+0x22/0x6c\n cifs_read_page_from_socket+0xc1/0x100\n readpages_fill_pages.cold+0x2f/0x46\n cifs_readv_receive+0x46d/0xa40\n cifs_demultiplex_thread+0x121c/0x1490\n kthread+0x16b/0x1a0\n ret_from_fork+0x2c/0x50\r\n\r\nThe following function calls will cause UAF of the rdata pointer.\r\n\r\nreadpages_fill_pages\n cifs_read_page_from_socket\n cifs_readv_from_socket\n cifs_reconnect\n __cifs_reconnect\n cifs_abort_connection\n mid-\u0026gt;callback() --\u0026gt; smb2_readv_callback\n queue_work(\u0026amp;rdata-\u0026gt;work) # if the worker completes first,\n # the rdata is freed\n cifs_readv_complete\n kref_put\n cifs_readdata_release\n kfree(rdata)\n return rdata-\u0026gt;... # UAF in readpages_fill_pages()\r\n\r\nSimilarly, this problem also occurs in the uncache_fill_pages().\r\n\r\nFix this by adjusts the order of condition judgment in the return\nstatement.(CVE-2023-52741)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntty: n_gsm: require CAP_NET_ADMIN to attach N_GSM0710 ldisc\r\n\r\nAny unprivileged user can attach N_GSM0710 ldisc, but it requires\nCAP_NET_ADMIN to create a GSM network anyway.\r\n\r\nRequire initial namespace CAP_NET_ADMIN to do that.(CVE-2023-52880)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nkeys: Fix overwrite of key expiration on instantiation\r\n\r\nThe expiry time of a key is unconditionally overwritten during\ninstantiation, defaulting to turn it permanent. This causes a problem\nfor DNS resolution as the expiration set by user-space is overwritten to\nTIME64_MAX, disabling further DNS updates. Fix this by restoring the\ncondition that key_set_expiry is only called when the pre-parser sets a\nspecific expiry.(CVE-2024-36031)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\next4: fix uninitialized ratelimit_state-\u0026gt;lock access in __ext4_fill_super()\r\n\r\nIn the following concurrency we will access the uninitialized rs-\u0026gt;lock:\r\n\r\next4_fill_super\n ext4_register_sysfs\n // sysfs registered msg_ratelimit_interval_ms\n // Other processes modify rs-\u0026gt;interval to\n // non-zero via msg_ratelimit_interval_ms\n ext4_orphan_cleanup\n ext4_msg(sb, KERN_INFO, \u0026quot;Errors on filesystem, \u0026quot;\n __ext4_msg\n ___ratelimit(\u0026amp;(EXT4_SB(sb)-\u0026gt;s_msg_ratelimit_state)\n if (!rs-\u0026gt;interval) // do nothing if interval is 0\n return 1;\n raw_spin_trylock_irqsave(\u0026amp;rs-\u0026gt;lock, flags)\n raw_spin_trylock(lock)\n _raw_spin_trylock\n __raw_spin_trylock\n spin_acquire(\u0026amp;lock-\u0026gt;dep_map, 0, 1, _RET_IP_)\n lock_acquire\n __lock_acquire\n register_lock_class\n assign_lock_key\n dump_stack();\n ratelimit_state_init(\u0026amp;sbi-\u0026gt;s_msg_ratelimit_state, 5 * HZ, 10);\n raw_spin_lock_init(\u0026amp;rs-\u0026gt;lock);\n // init rs-\u0026gt;lock here\r\n\r\nand get the following dump_stack:\r\n\r\n=========================================================\nINFO: trying to register non-static key.\nThe code is fine but needs lockdep annotation, or maybe\nyou didn\u0026apos;t initialize this object before use?\nturning off the locking correctness validator.\nCPU: 12 PID: 753 Comm: mount Tainted: G E 6.7.0-rc6-next-20231222 #504\n[...]\nCall Trace:\n dump_stack_lvl+0xc5/0x170\n dump_stack+0x18/0x30\n register_lock_class+0x740/0x7c0\n __lock_acquire+0x69/0x13a0\n lock_acquire+0x120/0x450\n _raw_spin_trylock+0x98/0xd0\n ___ratelimit+0xf6/0x220\n __ext4_msg+0x7f/0x160 [ext4]\n ext4_orphan_cleanup+0x665/0x740 [ext4]\n __ext4_fill_super+0x21ea/0x2b10 [ext4]\n ext4_fill_super+0x14d/0x360 [ext4]\n[...]\n=========================================================\r\n\r\nNormally interval is 0 until s_msg_ratelimit_state is initialized, so\n___ratelimit() does nothing. But registering sysfs precedes initializing\nrs-\u0026gt;lock, so it is possible to change rs-\u0026gt;interval to a non-zero value\nvia the msg_ratelimit_interval_ms interface of sysfs while rs-\u0026gt;lock is\nuninitialized, and then a call to ext4_msg triggers the problem by\naccessing an uninitialized rs-\u0026gt;lock. Therefore register sysfs after all\ninitializations are complete to avoid such problems.(CVE-2024-40998)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbpf: Take return from set_memory_rox() into account with bpf_jit_binary_lock_ro()\r\n\r\nset_memory_rox() can fail, leaving memory unprotected.\r\n\r\nCheck return and bail out when bpf_jit_binary_lock_ro() returns\nan error.(CVE-2024-42067)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: nexthop: Initialize all fields in dumped nexthops\r\n\r\nstruct nexthop_grp contains two reserved fields that are not initialized by\nnla_put_nh_group(), and carry garbage. This can be observed e.g. with\nstrace (edited for clarity):\r\n\r\n # ip nexthop add id 1 dev lo\n # ip nexthop add id 101 group 1\n # strace -e recvmsg ip nexthop get id 101\n ...\n recvmsg(... [{nla_len=12, nla_type=NHA_GROUP},\n [{id=1, weight=0, resvd1=0x69, resvd2=0x67}]] ...) = 52\r\n\r\nThe fields are reserved and therefore not currently used. But as they are, they\nleak kernel memory, and the fact they are not just zero complicates repurposing\nof the fields for new ends. Initialize the full structure.(CVE-2024-42283)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nirqchip/imx-irqsteer: Handle runtime power management correctly\r\n\r\nThe power domain is automatically activated from clk_prepare(). However, on\ncertain platforms like i.MX8QM and i.MX8QXP, the power-on handling invokes\nsleeping functions, which triggers the \u0026apos;scheduling while atomic\u0026apos; bug in the\ncontext switch path during device probing:\r\n\r\n BUG: scheduling while atomic: kworker/u13:1/48/0x00000002\n Call trace:\n __schedule_bug+0x54/0x6c\n __schedule+0x7f0/0xa94\n schedule+0x5c/0xc4\n schedule_preempt_disabled+0x24/0x40\n __mutex_lock.constprop.0+0x2c0/0x540\n __mutex_lock_slowpath+0x14/0x20\n mutex_lock+0x48/0x54\n clk_prepare_lock+0x44/0xa0\n clk_prepare+0x20/0x44\n imx_irqsteer_resume+0x28/0xe0\n pm_generic_runtime_resume+0x2c/0x44\n __genpd_runtime_resume+0x30/0x80\n genpd_runtime_resume+0xc8/0x2c0\n __rpm_callback+0x48/0x1d8\n rpm_callback+0x6c/0x78\n rpm_resume+0x490/0x6b4\n __pm_runtime_resume+0x50/0x94\n irq_chip_pm_get+0x2c/0xa0\n __irq_do_set_handler+0x178/0x24c\n irq_set_chained_handler_and_data+0x60/0xa4\n mxc_gpio_probe+0x160/0x4b0\r\n\r\nCure this by implementing the irq_bus_lock/sync_unlock() interrupt chip\ncallbacks and handle power management in them as they are invoked from\nnon-atomic context.\r\n\r\n[ tglx: Rewrote change log, added Fixes tag ](CVE-2024-42290)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/gma500: fix null pointer dereference in psb_intel_lvds_get_modes\r\n\r\nIn psb_intel_lvds_get_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-42309)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: venus: fix use after free in vdec_close\r\n\r\nThere appears to be a possible use after free with vdec_close().\nThe firmware will add buffer release work to the work queue through\nHFI callbacks as a normal part of decoding. Randomly closing the\ndecoder device from userspace during normal decoding can incur\na read after free for inst.\r\n\r\nFix it by cancelling the work in vdec_close.(CVE-2024-42313)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nipvs: properly dereference pe in ip_vs_add_service\r\n\r\nUse pe directly to resolve sparse warning:\r\n\r\n net/netfilter/ipvs/ip_vs_ctl.c:1471:27: warning: dereference of noderef expression(CVE-2024-42322)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nPCI: keystone: Fix NULL pointer dereference in case of DT error in ks_pcie_setup_rc_app_regs()\r\n\r\nIf IORESOURCE_MEM is not provided in Device Tree due to\nany error, resource_list_first_type() will return NULL and\npci_parse_request_of_pci_ranges() will just emit a warning.\r\n\r\nThis will cause a NULL pointer dereference. Fix this bug by adding NULL\nreturn check.\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-43823)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nleds: trigger: Unregister sysfs attributes before calling deactivate()\r\n\r\nTriggers which have trigger specific sysfs attributes typically store\nrelated data in trigger-data allocated by the activate() callback and\nfreed by the deactivate() callback.\r\n\r\nCalling device_remove_groups() after calling deactivate() leaves a window\nwhere the sysfs attributes show/store functions could be called after\ndeactivation and then operate on the just freed trigger-data.\r\n\r\nMove the device_remove_groups() call to before deactivate() to close\nthis race window.\r\n\r\nThis also makes the deactivation path properly do things in reverse order\nof the activation path which calls the activate() callback before calling\ndevice_add_groups().(CVE-2024-43830)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmd: fix deadlock between mddev_suspend and flush bio\r\n\r\nDeadlock occurs when mddev is being suspended while some flush bio is in\nprogress. It is a complex issue.\r\n\r\nT1. the first flush is at the ending stage, it clears \u0026apos;mddev-\u0026gt;flush_bio\u0026apos;\n and tries to submit data, but is blocked because mddev is suspended\n by T4.\nT2. the second flush sets \u0026apos;mddev-\u0026gt;flush_bio\u0026apos;, and attempts to queue\n md_submit_flush_data(), which is already running (T1) and won\u0026apos;t\n execute again if on the same CPU as T1.\nT3. the third flush inc active_io and tries to flush, but is blocked because\n \u0026apos;mddev-\u0026gt;flush_bio\u0026apos; is not NULL (set by T2).\nT4. mddev_suspend() is called and waits for active_io dec to 0 which is inc\n by T3.\r\n\r\n T1\t\tT2\t\tT3\t\tT4\n (flush 1)\t(flush 2)\t(third 3)\t(suspend)\n md_submit_flush_data\n mddev-\u0026gt;flush_bio = NULL;\n .\n .\t \tmd_flush_request\n .\t \t mddev-\u0026gt;flush_bio = bio\n .\t \t queue submit_flushes\n .\t\t .\n .\t\t .\t\tmd_handle_request\n .\t\t .\t\t active_io + 1\n .\t\t .\t\t md_flush_request\n .\t\t .\t\t wait !mddev-\u0026gt;flush_bio\n .\t\t .\n .\t\t .\t\t\t\tmddev_suspend\n .\t\t .\t\t\t\t wait !active_io\n .\t\t .\n .\t\t submit_flushes\n .\t\t queue_work md_submit_flush_data\n .\t\t //md_submit_flush_data is already running (T1)\n .\n md_handle_request\n wait resume\r\n\r\nThe root issue is non-atomic inc/dec of active_io during flush process.\nactive_io is dec before md_submit_flush_data is queued, and inc soon\nafter md_submit_flush_data() run.\n md_flush_request\n active_io + 1\n submit_flushes\n active_io - 1\n md_submit_flush_data\n md_handle_request\n active_io + 1\n make_request\n active_io - 1\r\n\r\nIf active_io is dec after md_handle_request() instead of within\nsubmit_flushes(), make_request() can be called directly intead of\nmd_handle_request() in md_submit_flush_data(), and active_io will\nonly inc and dec once in the whole flush process. Deadlock will be\nfixed.\r\n\r\nAdditionally, the only difference between fixing the issue and before is\nthat there is no return error handling of make_request(). But after\nprevious patch cleaned md_write_start(), make_requst() only return error\nin raid5_make_request() by dm-raid, see commit 41425f96d7aa (\u0026quot;dm-raid456,\nmd/raid456: fix a deadlock for dm-raid456 while io concurrent with\nreshape)\u0026quot;. Since dm always splits data and flush operation into two\nseparate io, io size of flush submitted by dm always is 0, make_request()\nwill not be called in md_submit_flush_data(). To prevent future\nmodifications from introducing issues, add WARN_ON to ensure\nmake_request() no error is returned in this context.(CVE-2024-43855)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmemcg: protect concurrent access to mem_cgroup_idr\r\n\r\nCommit 73f576c04b94 (\u0026quot;mm: memcontrol: fix cgroup creation failure after\nmany small jobs\u0026quot;) decoupled the memcg IDs from the CSS ID space to fix the\ncgroup creation failures. It introduced IDR to maintain the memcg ID\nspace. The IDR depends on external synchronization mechanisms for\nmodifications. For the mem_cgroup_idr, the idr_alloc() and idr_replace()\nhappen within css callback and thus are protected through cgroup_mutex\nfrom concurrent modifications. However idr_remove() for mem_cgroup_idr\nwas not protected against concurrency and can be run concurrently for\ndifferent memcgs when they hit their refcnt to zero. Fix that.\r\n\r\nWe have been seeing list_lru based kernel crashes at a low frequency in\nour fleet for a long time. These crashes were in different part of\nlist_lru code including list_lru_add(), list_lru_del() and reparenting\ncode. Upon further inspection, it looked like for a given object (dentry\nand inode), the super_block\u0026apos;s list_lru didn\u0026apos;t have list_lru_one for the\nmemcg of that object. The initial suspicions were either the object is\nnot allocated through kmem_cache_alloc_lru() or somehow\nmemcg_list_lru_alloc() failed to allocate list_lru_one() for a memcg but\nreturned success. No evidence were found for these cases.\r\n\r\nLooking more deeply, we started seeing situations where valid memcg\u0026apos;s id\nis not present in mem_cgroup_idr and in some cases multiple valid memcgs\nhave same id and mem_cgroup_idr is pointing to one of them. So, the most\nreasonable explanation is that these situations can happen due to race\nbetween multiple idr_remove() calls or race between\nidr_alloc()/idr_replace() and idr_remove(). These races are causing\nmultiple memcgs to acquire the same ID and then offlining of one of them\nwould cleanup list_lrus on the system for all of them. Later access from\nother memcgs to the list_lru cause crashes due to missing list_lru_one.(CVE-2024-43892)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nserial: core: check uartclk for zero to avoid divide by zero\r\n\r\nCalling ioctl TIOCSSERIAL with an invalid baud_base can\nresult in uartclk being zero, which will result in a\ndivide by zero error in uart_get_divisor(). The check for\nuartclk being zero in uart_set_info() needs to be done\nbefore other settings are made as subsequent calls to\nioctl TIOCSSERIAL for the same port would be impacted if\nthe uartclk check was done where uartclk gets set.\r\n\r\nOops: divide error: 0000 PREEMPT SMP KASAN PTI\nRIP: 0010:uart_get_divisor (drivers/tty/serial/serial_core.c:580)\nCall Trace:\n \u0026lt;TASK\u0026gt;\nserial8250_get_divisor (drivers/tty/serial/8250/8250_port.c:2576\n drivers/tty/serial/8250/8250_port.c:2589)\nserial8250_do_set_termios (drivers/tty/serial/8250/8250_port.c:502\n drivers/tty/serial/8250/8250_port.c:2741)\nserial8250_set_termios (drivers/tty/serial/8250/8250_port.c:2862)\nuart_change_line_settings (./include/linux/spinlock.h:376\n ./include/linux/serial_core.h:608 drivers/tty/serial/serial_core.c:222)\nuart_port_startup (drivers/tty/serial/serial_core.c:342)\nuart_startup (drivers/tty/serial/serial_core.c:368)\nuart_set_info (drivers/tty/serial/serial_core.c:1034)\nuart_set_info_user (drivers/tty/serial/serial_core.c:1059)\ntty_set_serial (drivers/tty/tty_io.c:2637)\ntty_ioctl (drivers/tty/tty_io.c:2647 drivers/tty/tty_io.c:2791)\n__x64_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:907\n fs/ioctl.c:893 fs/ioctl.c:893)\ndo_syscall_64 (arch/x86/entry/common.c:52\n (discriminator 1) arch/x86/entry/common.c:83 (discriminator 1))\nentry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)\r\n\r\nRule: add(CVE-2024-43893)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfou: remove warn in gue_gro_receive on unsupported protocol\r\n\r\nDrop the WARN_ON_ONCE inn gue_gro_receive if the encapsulated type is\nnot known or does not have a GRO handler.\r\n\r\nSuch a packet is easily constructed. Syzbot generates them and sets\noff this warning.\r\n\r\nRemove the warning as it is expected and not actionable.\r\n\r\nThe warning was previously reduced from WARN_ON to WARN_ON_ONCE in\ncommit 270136613bf7 (\u0026quot;fou: Do WARN_ON_ONCE in gue_gro_receive for bad\nproto callbacks\u0026quot;).(CVE-2024-44940)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\natm: idt77252: prevent use after free in dequeue_rx()\r\n\r\nWe can\u0026apos;t dereference \u0026quot;skb\u0026quot; after calling vcc-\u0026gt;push() because the skb\nis released.(CVE-2024-44998)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nxhci: Fix Panther point NULL pointer deref at full-speed re-enumeration\r\n\r\nre-enumerating full-speed devices after a failed address device command\ncan trigger a NULL pointer dereference.\r\n\r\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().\r\n\r\nOn Panther point xHC the xhci_configure_endpoint() function will\nadditionally check and reserve bandwidth in software. Other hosts do\nthis in hardware\r\n\r\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\r\n\r\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\r\n\r\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)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ns390/dasd: fix error recovery leading to data corruption on ESE devices\r\n\r\nExtent Space Efficient (ESE) or thin provisioned volumes need to be\nformatted on demand during usual IO processing.\r\n\r\nThe dasd_ese_needs_format function checks for error codes that signal\nthe non existence of a proper track format.\r\n\r\nThe check for incorrect length is to imprecise since other error cases\nleading to transport of insufficient data also have this flag set.\nThis might lead to data corruption in certain error cases for example\nduring a storage server warmstart.\r\n\r\nFix by removing the check for incorrect length and replacing by\nexplicitly checking for invalid track format in transport mode.\r\n\r\nAlso remove the check for file protected since this is not a valid\nESE handling case.(CVE-2024-45026)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnfc: pn533: Add poll mod list filling check\r\n\r\nIn case of im_protocols value is 1 and tm_protocols value is 0 this\ncombination successfully passes the check\n\u0026apos;if (!im_protocols \u0026amp;\u0026amp; !tm_protocols)\u0026apos; in the nfc_start_poll().\nBut then after pn533_poll_create_mod_list() call in pn533_start_poll()\npoll mod list will remain empty and dev-\u0026gt;poll_mod_count will remain 0\nwhich lead to division by zero.\r\n\r\nNormally no im protocol has value 1 in the mask, so this combination is\nnot expected by driver. But these protocol values actually come from\nuserspace via Netlink interface (NFC_CMD_START_POLL operation). So a\nbroken or malicious program may pass a message containing a \u0026quot;bad\u0026quot;\ncombination of protocol parameter values so that dev-\u0026gt;poll_mod_count\nis not incremented inside pn533_poll_create_mod_list(), thus leading\nto division by zero.\nCall trace looks like:\nnfc_genl_start_poll()\n nfc_start_poll()\n -\u0026gt;start_poll()\n pn533_start_poll()\r\n\r\nAdd poll mod list filling check.\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-46676)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: typec: ucsi: Fix null pointer dereference in trace\r\n\r\nucsi_register_altmode checks IS_ERR for the alt pointer and treats\nNULL as valid. When CONFIG_TYPEC_DP_ALTMODE is not enabled,\nucsi_register_displayport returns NULL which causes a NULL pointer\ndereference in trace. Rather than return NULL, call\ntypec_port_register_altmode to register DisplayPort alternate mode\nas a non-controllable mode when CONFIG_TYPEC_DP_ALTMODE is not enabled.(CVE-2024-46719)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbpf: Remove tst_run from lwt_seg6local_prog_ops.\r\n\r\nThe syzbot reported that the lwt_seg6 related BPF ops can be invoked\nvia bpf_test_run() without without entering input_action_end_bpf()\nfirst.\r\n\r\nMartin KaFai Lau said that self test for BPF_PROG_TYPE_LWT_SEG6LOCAL\nprobably didn\u0026apos;t work since it was introduced in commit 04d4b274e2a\n(\u0026quot;ipv6: sr: Add seg6local action End.BPF\u0026quot;). The reason is that the\nper-CPU variable seg6_bpf_srh_states::srh is never assigned in the self\ntest case but each BPF function expects it.\r\n\r\nRemove test_run for BPF_PROG_TYPE_LWT_SEG6LOCAL.(CVE-2024-46754)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nice: Add netif_device_attach/detach into PF reset flow\r\n\r\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.\r\n\r\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;\r\n\r\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\r\n\r\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:\r\n\r\n netlink error: No such device\r\n\r\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)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nksmbd: unset the binding mark of a reused connection\r\n\r\nSteve French reported null pointer dereference error from sha256 lib.\ncifs.ko can send session setup requests on reused connection.\nIf reused connection is used for binding session, conn-\u0026gt;binding can\nstill remain true and generate_preauth_hash() will not set\nsess-\u0026gt;Preauth_HashValue and it will be NULL.\nIt is used as a material to create an encryption key in\nksmbd_gen_smb311_encryptionkey. -\u0026gt;Preauth_HashValue cause null pointer\ndereference error from crypto_shash_update().\r\n\r\nBUG: kernel NULL pointer dereference, address: 0000000000000000\n#PF: supervisor read access in kernel mode\n#PF: error_code(0x0000) - not-present page\nPGD 0 P4D 0\nOops: 0000 [#1] PREEMPT SMP PTI\nCPU: 8 PID: 429254 Comm: kworker/8:39\nHardware name: LENOVO 20MAS08500/20MAS08500, BIOS N2CET69W (1.52 )\nWorkqueue: ksmbd-io handle_ksmbd_work [ksmbd]\nRIP: 0010:lib_sha256_base_do_update.isra.0+0x11e/0x1d0 [sha256_ssse3]\n\u0026lt;TASK\u0026gt;\n? show_regs+0x6d/0x80\n? __die+0x24/0x80\n? page_fault_oops+0x99/0x1b0\n? do_user_addr_fault+0x2ee/0x6b0\n? exc_page_fault+0x83/0x1b0\n? asm_exc_page_fault+0x27/0x30\n? __pfx_sha256_transform_rorx+0x10/0x10 [sha256_ssse3]\n? lib_sha256_base_do_update.isra.0+0x11e/0x1d0 [sha256_ssse3]\n? __pfx_sha256_transform_rorx+0x10/0x10 [sha256_ssse3]\n? __pfx_sha256_transform_rorx+0x10/0x10 [sha256_ssse3]\n_sha256_update+0x77/0xa0 [sha256_ssse3]\nsha256_avx2_update+0x15/0x30 [sha256_ssse3]\ncrypto_shash_update+0x1e/0x40\nhmac_update+0x12/0x20\ncrypto_shash_update+0x1e/0x40\ngenerate_key+0x234/0x380 [ksmbd]\ngenerate_smb3encryptionkey+0x40/0x1c0 [ksmbd]\nksmbd_gen_smb311_encryptionkey+0x72/0xa0 [ksmbd]\nntlm_authenticate.isra.0+0x423/0x5d0 [ksmbd]\nsmb2_sess_setup+0x952/0xaa0 [ksmbd]\n__process_request+0xa3/0x1d0 [ksmbd]\n__handle_ksmbd_work+0x1c4/0x2f0 [ksmbd]\nhandle_ksmbd_work+0x2d/0xa0 [ksmbd]\nprocess_one_work+0x16c/0x350\nworker_thread+0x306/0x440\n? __pfx_worker_thread+0x10/0x10\nkthread+0xef/0x120\n? __pfx_kthread+0x10/0x10\nret_from_fork+0x44/0x70\n? __pfx_kthread+0x10/0x10\nret_from_fork_asm+0x1b/0x30\n\u0026lt;/TASK\u0026gt;(CVE-2024-46795)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: the warning dereferencing obj for nbio_v7_4\r\n\r\nif ras_manager obj null, don\u0026apos;t print NBIO err data(CVE-2024-46819)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsched: sch_cake: fix bulk flow accounting logic for host fairness\r\n\r\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.\r\n\r\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).\r\n\r\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).\r\n\r\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.\r\n\r\nThis patch fixes the issue by introducing the same conditional check on\ndecrement as is used on increment.\r\n\r\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)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: clean up our handling of refs == 0 in snapshot delete\r\n\r\nIn reada we BUG_ON(refs == 0), which could be unkind since we aren\u0026apos;t\nholding a lock on the extent leaf and thus could get a transient\nincorrect answer. In walk_down_proc we also BUG_ON(refs == 0), which\ncould happen if we have extent tree corruption. Change that to return\n-EUCLEAN. In do_walk_down() we catch this case and handle it correctly,\nhowever we return -EIO, which -EUCLEAN is a more appropriate error code.\nFinally in walk_up_proc we have the same BUG_ON(refs == 0), so convert\nthat to proper error handling. Also adjust the error message so we can\nactually do something with the information.(CVE-2024-46840)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nperf/x86/intel: Limit the period on Haswell\r\n\r\nRunning the ltp test cve-2015-3290 concurrently reports the following\nwarnings.\r\n\r\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\r\n\r\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/)\r\n\r\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.\r\n\r\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)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: dpaa: Pad packets to ETH_ZLEN\r\n\r\nWhen sending packets under 60 bytes, up to three bytes of the buffer\nfollowing the data may be leaked. Avoid this by extending all packets to\nETH_ZLEN, ensuring nothing is leaked in the padding. This bug can be\nreproduced by running\r\n\r\n\t$ ping -s 11 destination(CVE-2024-46854)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nft_socket: fix sk refcount leaks\r\n\r\nWe must put \u0026apos;sk\u0026apos; reference before returning.(CVE-2024-46855)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmptcp: pm: Fix uaf in __timer_delete_sync\r\n\r\nThere are two paths to access mptcp_pm_del_add_timer, result in a race\ncondition:\r\n\r\n CPU1\t\t\t\tCPU2\n ==== ====\n net_rx_action\n napi_poll netlink_sendmsg\n __napi_poll netlink_unicast\n process_backlog netlink_unicast_kernel\n __netif_receive_skb genl_rcv\n __netif_receive_skb_one_core netlink_rcv_skb\n NF_HOOK genl_rcv_msg\n ip_local_deliver_finish genl_family_rcv_msg\n ip_protocol_deliver_rcu genl_family_rcv_msg_doit\n tcp_v4_rcv mptcp_pm_nl_flush_addrs_doit\n tcp_v4_do_rcv mptcp_nl_remove_addrs_list\n tcp_rcv_established mptcp_pm_remove_addrs_and_subflows\n tcp_data_queue remove_anno_list_by_saddr\n mptcp_incoming_options mptcp_pm_del_add_timer\n mptcp_pm_del_add_timer kfree(entry)\r\n\r\nIn remove_anno_list_by_saddr(running on CPU2), after leaving the critical\nzone protected by \u0026quot;pm.lock\u0026quot;, the entry will be released, which leads to the\noccurrence of uaf in the mptcp_pm_del_add_timer(running on CPU1).\r\n\r\nKeeping a reference to add_timer inside the lock, and calling\nsk_stop_timer_sync() with this reference, instead of \u0026quot;entry-\u0026gt;add_timer\u0026quot;.\r\n\r\nMove list_del(\u0026amp;entry-\u0026gt;list) to mptcp_pm_del_add_timer and inside the pm lock,\ndo not directly access any members of the entry outside the pm lock, which\ncan avoid similar \u0026quot;entry-\u0026gt;x\u0026quot; uaf.(CVE-2024-46858)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncrypto: stm32/cryp - call finalize with bh disabled\r\n\r\nThe finalize operation in interrupt mode produce a produces a spinlock\nrecursion warning. The reason is the fact that BH must be disabled\nduring this process.(CVE-2024-47658)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nspi: hisi-kunpeng: Add verification for the max_frequency provided by the firmware\r\n\r\nIf the value of max_speed_hz is 0, it may cause a division by zero\nerror in hisi_calc_effective_speed().\nThe value of max_speed_hz is provided by firmware.\nFirmware is generally considered as a trusted domain. However, as\ndivision by zero errors can cause system failure, for defense measure,\nthe value of max_speed is validated here. So 0 is regarded as invalid\nand an error code is returned.(CVE-2024-47664)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nocfs2: add bounds checking to ocfs2_xattr_find_entry()\r\n\r\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)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nUSB: usbtmc: prevent kernel-usb-infoleak\r\n\r\nThe syzbot reported a kernel-usb-infoleak in usbtmc_write,\nwe need to clear the structure before filling fields.(CVE-2024-47671)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: iwlwifi: mvm: don\u0026apos;t wait for tx queues if firmware is dead\r\n\r\nThere is a WARNING in iwl_trans_wait_tx_queues_empty() (that was\nrecently converted from just a message), that can be hit if we\nwait for TX queues to become empty after firmware died. Clearly,\nwe can\u0026apos;t expect anything from the firmware after it\u0026apos;s declared dead.\r\n\r\nDon\u0026apos;t call iwl_trans_wait_tx_queues_empty() in this case. While it could\nbe a good idea to stop the flow earlier, the flush functions do some\nmaintenance work that is not related to the firmware, so keep that part\nof the code running even when the firmware is not running.\r\n\r\n[edit commit message](CVE-2024-47672)",
"id": "OESA-2024-2257",
"modified": "2026-08-06T11:07:44Z",
"published": "2024-10-18T11:07:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2257"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48688"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48848"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48869"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48879"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48893"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48945"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-0597"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-4134"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52463"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52707"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52741"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52880"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36031"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40998"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42067"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42283"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42290"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42309"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42313"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42322"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43823"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43830"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43855"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43892"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43893"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44940"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44998"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45006"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45026"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46676"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46719"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46754"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46770"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46795"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46819"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46828"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46840"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46848"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46854"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46855"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46858"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47658"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47664"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47670"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47671"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47672"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2022-48688",
"CVE-2022-48848",
"CVE-2022-48869",
"CVE-2022-48879",
"CVE-2022-48893",
"CVE-2022-48945",
"CVE-2023-0597",
"CVE-2023-4134",
"CVE-2023-52463",
"CVE-2023-52707",
"CVE-2023-52741",
"CVE-2023-52880",
"CVE-2024-36031",
"CVE-2024-40998",
"CVE-2024-42067",
"CVE-2024-42283",
"CVE-2024-42290",
"CVE-2024-42309",
"CVE-2024-42313",
"CVE-2024-42322",
"CVE-2024-43823",
"CVE-2024-43830",
"CVE-2024-43855",
"CVE-2024-43892",
"CVE-2024-43893",
"CVE-2024-44940",
"CVE-2024-44998",
"CVE-2024-45006",
"CVE-2024-45026",
"CVE-2024-46676",
"CVE-2024-46719",
"CVE-2024-46754",
"CVE-2024-46770",
"CVE-2024-46795",
"CVE-2024-46819",
"CVE-2024-46828",
"CVE-2024-46840",
"CVE-2024-46848",
"CVE-2024-46854",
"CVE-2024-46855",
"CVE-2024-46858",
"CVE-2024-47658",
"CVE-2024-47664",
"CVE-2024-47670",
"CVE-2024-47671",
"CVE-2024-47672"
]
}
OESA-2025-2887 (CVE-2022-49426)
Vulnerability from osv_openeuler – Published: 2025-12-30 11:10 – Updated: 2026-08-06 11:10 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
iommu/arm-smmu-v3-sva: Fix mm use-after-free
We currently call arm64_mm_context_put() without holding a reference to the mm, which can result in use-after-free. Call mmgrab()/mmdrop() to ensure the mm only gets freed after we unpinned the ASID.(CVE-2022-49426)
In the Linux kernel, the following vulnerability has been resolved:
tty: n_gsm: require CAP_NET_ADMIN to attach N_GSM0710 ldisc
Any unprivileged user can attach N_GSM0710 ldisc, but it requires CAP_NET_ADMIN to create a GSM network anyway.
Require initial namespace CAP_NET_ADMIN to do that.(CVE-2023-52880)
In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: mt7915: fix memory leak in mt7915_mcu_exit
Always purge mcu skb queues in mt7915_mcu_exit routine even if mt7915_firmware_state fails.(CVE-2023-53466)
In the Linux kernel, the following vulnerability has been resolved:fou: Fix null-ptr-deref in GRO.We observed a null-ptr-deref in fou_gro_receive() while shutting downa host. [0]The NULL pointer is sk->sk_user_data, and the offset 8 is of protocolin struct fou.When fou_release() is called due to netns dismantle or explicit tunnelteardown, udp_tunnel_sock_release() sets NULL to sk->sk_user_data.Then, the tunnel socket is destroyed after a single RCU grace period.So, in-flight udp4_gro_receive() could find the socket and execute theFOU GRO handler, where sk->sk_user_data could be NULL.Let s use rcu_dereference_sk_user_data() in fou_from_sock() and add NULLchecks in FOU GRO handlers.[0]:BUG: kernel NULL pointer dereference, address: 0000000000000008 PF: supervisor read access in kernel mode PF: error_code(0x0000) - not-present pagePGD 80000001032f4067 P4D 80000001032f4067 PUD 103240067 PMD 0SMP PTICPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.216-204.855.amzn2.x86_64 #1Hardware name: Amazon EC2 c5.large/, BIOS 1.0 10/16/2017RIP: 0010:fou_gro_receive (net/ipv4/fou.c:233) [fou]Code: 41 5f c3 cc cc cc cc e8 e7 2e 69 f4 0f 1f 80 00 00 00 00 0f 1f 44 00 00 49 89 f8 41 54 48 89 f7 48 89 d6 49 8b 80 88 02 00 00 <0f> b6 48 08 0f b7 42 4a 66 25 fd fd 80 cc 02 66 89 42 4a 0f b6 42RSP: 0018:ffffa330c0003d08 EFLAGS: 00010297RAX: 0000000000000000 RBX: ffff93d9e3a6b900 RCX: 0000000000000010RDX: ffff93d9e3a6b900 RSI: ffff93d9e3a6b900 RDI: ffff93dac2e24d08RBP: ffff93d9e3a6b900 R08: ffff93dacbce6400 R09: 0000000000000002R10: 0000000000000000 R11: ffffffffb5f369b0 R12: ffff93dacbce6400R13: ffff93dac2e24d08 R14: 0000000000000000 R15: ffffffffb4edd1c0FS: 0000000000000000(0000) GS:ffff93daee800000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000000000008 CR3: 0000000102140001 CR4: 00000000007706f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400PKRU: 55555554Call Trace: <IRQ> ? show_trace_log_lvl (arch/x86/kernel/dumpstack.c:259) ? __die_body.cold (arch/x86/kernel/dumpstack.c:478 arch/x86/kernel/dumpstack.c:420) ? no_context (arch/x86/mm/fault.c:752) ? exc_page_fault (arch/x86/include/asm/irqflags.h:49 arch/x86/include/asm/irqflags.h:89 arch/x86/mm/fault.c:1435 arch/x86/mm/fault.c:1483) ? asm_exc_page_fault (arch/x86/include/asm/idtentry.h:571) ? fou_gro_receive (net/ipv4/fou.c:233) [fou] udp_gro_receive (include/linux/netdevice.h:2552 net/ipv4/udp_offload.c:559) udp4_gro_receive (net/ipv4/udp_offload.c:604) inet_gro_receive (net/ipv4/af_inet.c:1549 (discriminator 7)) dev_gro_receive (net/core/dev.c:6035 (discriminator 4)) napi_gro_receive (net/core/dev.c:6170) ena_clean_rx_irq (drivers/amazon/net/ena/ena_netdev.c:1558) [ena] ena_io_poll (drivers/amazon/net/ena/ena_netdev.c:1742) [ena] napi_poll (net/core/dev.c:6847) net_rx_action (net/core/dev.c:6917) __do_softirq (arch/x86/include/asm/jump_label.h:25 include/linux/jump_label.h:200 include/trace/events/irq.h:142 kernel/softirq.c:299) asm_call_irq_on_stack (arch/x86/entry/entry_64.S:809)</IRQ> do_softirq_own_stack (arch/x86/include/asm/irq_stack.h:27 arch/x86/include/asm/irq_stack.h:77 arch/x86/kernel/irq_64.c:77) irq_exit_rcu (kernel/softirq.c:393 kernel/softirq.c:423 kernel/softirq.c:435) common_interrupt (arch/x86/kernel/irq.c:239) asm_common_interrupt (arch/x86/include/asm/idtentry.h:626)RIP: 0010:acpi_idle_do_entry (arch/x86/include/asm/irqflags.h:49 arch/x86/include/asm/irqflags.h:89 drivers/acpi/processor_idle.c:114 drivers/acpi/processor_idle.c:575)Code: 8b 15 d1 3c c4 02 ed c3 cc cc cc cc 65 48 8b 04 25 40 ef 01 00 48 8b 00 a8 08 75 eb 0f 1f 44 00 00 0f 00 2d d5 09 55 00 fb f4 <fa> c3 cc cc cc cc e9 be fc ff ff 66 66 2e 0f 1f 84 00 00 00 00 00RSP: 0018:ffffffffb5603e58 EFLAGS: 00000246RAX: 0000000000004000 RBX: ffff93dac0929c00 RCX: ffff93daee833900RDX: ffff93daee800000 RSI: ffff93d---truncated---(CVE-2024-46763)
In the Linux kernel, the following vulnerability has been resolved:f2fs: Require FMODE_WRITE for atomic write ioctlsThe F2FS ioctls for starting and committing atomic writes check forinode_owner_or_capable(), but this does not give LSMs like SELinux orLandlock an opportunity to deny the write access - if the caller s FSUIDmatches the inode s UID, inode_owner_or_capable() immediately returns true.There are scenarios where LSMs want to deny a process the ability to writeparticular files, even files that the FSUID of the process owns; but thiscan currently partially be bypassed using atomic write ioctls in two ways: - F2FS_IOC_START_ATOMIC_REPLACE + F2FS_IOC_COMMIT_ATOMIC_WRITE can truncate an inode to size 0 - F2FS_IOC_START_ATOMIC_WRITE + F2FS_IOC_ABORT_ATOMIC_WRITE can revert changes another process concurrently made to a fileFix it by requiring FMODE_WRITE for these operations, just like forF2FS_IOC_MOVE_RANGE. Since any legitimate caller should only be using theseioctls when intending to write into the file, that seems unlikely to breakanything.(CVE-2024-47740)
In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: kTLS, Fix incorrect page refcountingThe kTLS tx handling code is using a mix of get_page() andpage_ref_inc() APIs to increment the page reference. But on the releasepath (mlx5e_ktls_tx_handle_resync_dump_comp()), only put_page() is used.This is an issue when using pages from large folios: the get_page()references are stored on the folio page while the page_ref_inc()references are stored directly in the given page. On release the foliopage will be dereferenced too many times.This was found while doing kTLS testing with sendfile() + ZC when theserved file was read from NFS on a kernel with NFS large folios support(commit 49b29a573da8 ( nfs: add support for large folios )).(CVE-2024-53138)
In the Linux kernel, the following vulnerability has been resolved:x86/xen: don t do PV iret hypercall through hypercall pageInstead of jumping to the Xen hypercall page for doing the irethypercall, 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:wifi: brcmfmac: fix NULL pointer dereference in brcmf_txfinalize()On removal of the device or unloading of the kernel module a potential NULLpointer dereference occurs.The following sequence deletes the interface: brcmf_detach() brcmf_remove_interface() brcmf_del_if()Inside the brcmf_del_if() function the drvr->if2bss[ifidx] is updated toBRCMF_BSSIDX_INVALID (-1) if the bsscfgidx matches.After brcmf_remove_interface() call the brcmf_proto_detach() function iscalled providing the following sequence: brcmf_detach() brcmf_proto_detach() brcmf_proto_msgbuf_detach() brcmf_flowring_detach() brcmf_msgbuf_delete_flowring() brcmf_msgbuf_remove_flowring() brcmf_flowring_delete() brcmf_get_ifp() brcmf_txfinalize()Since brcmf_get_ip() can and actually will return NULL in this case thecall to brcmf_txfinalize() will result in a NULL pointer dereference insidebrcmf_txfinalize() when trying to update ifp->ndev->stats.tx_errors.This will only happen if a flowring still has an skb.Although the NULL pointer dereference has only been seen when trying toupdate the tx statistic, all other uses of the ifp pointer have beenguarded as well with an early return if ifp is NULL.(CVE-2025-21744)
In the Linux kernel, the following vulnerability has been resolved:net: let net.core.dev_weight always be non-zeroThe following problem was encountered during stability test:(NULL net_device): NAPI poll function process_backlog+0x0/0x530 returned 1, exceeding its budget of 0.------------[ cut here ]------------list_add double add: new=ffff88905f746f48, prev=ffff88905f746f48, next=ffff88905f746e40.WARNING: CPU: 18 PID: 5462 at lib/list_debug.c:35 __list_add_valid_or_report+0xf3/0x130CPU: 18 UID: 0 PID: 5462 Comm: ping Kdump: loaded Not tainted 6.13.0-rc7+RIP: 0010:__list_add_valid_or_report+0xf3/0x130Call Trace:? __warn+0xcd/0x250? __list_add_valid_or_report+0xf3/0x130enqueue_to_backlog+0x923/0x1070netif_rx_internal+0x92/0x2b0__netif_rx+0x15/0x170loopback_xmit+0x2ef/0x450dev_hard_start_xmit+0x103/0x490__dev_queue_xmit+0xeac/0x1950ip_finish_output2+0x6cc/0x1620ip_output+0x161/0x270ip_push_pending_frames+0x155/0x1a0raw_sendmsg+0xe13/0x1550__sys_sendto+0x3bf/0x4e0__x64_sys_sendto+0xdc/0x1b0do_syscall_64+0x5b/0x170entry_SYSCALL_64_after_hwframe+0x76/0x7eThe reproduction command is as follows: sysctl -w net.core.dev_weight=0 ping 127.0.0.1This is because when the napi s weight is set to 0, process_backlog() mayreturn 0 and clear the NAPI_STATE_SCHED bit of napi->state, causing thisnapi to be re-polled in net_rx_action() until __do_softirq() times out.Since the NAPI_STATE_SCHED bit has been cleared, napi_schedule_rps() canbe retriggered in enqueue_to_backlog(), causing this issue.Making the napi s weight always non-zero solves this problem.Triggering this issue requires system-wide admin (setting isnot namespaced).(CVE-2025-21806)
In the Linux kernel, the following vulnerability has been resolved:tty: xilinx_uartps: split sysrq handlinglockdep detects the following circular locking dependency:CPU 0 CPU 1========================== ============================cdns_uart_isr() printk() uart_port_lock(port) console_lock() cdns_uart_console_write() if (!port->sysrq) uart_port_lock(port) uart_handle_break() port->sysrq = ... uart_handle_sysrq_char() printk() console_lock()The fixed commit attempts to avoid this situation by only taking theport lock in cdns_uart_console_write if port->sysrq unset. However, if(as shown above) cdns_uart_console_write runs before port->sysrq is set,then it will try to take the port lock anyway. This may result in adeadlock.Fix this by splitting sysrq handling into two parts. We use the preparehelper under the port lock and defer handling until we release the lock.(CVE-2025-21820)
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix kmemleak warning for percpu hashmap
Vlad Poenaru reported the following kmemleak issue:
unreferenced object 0x606fd7c44ac8 (size 32): backtrace (crc 0): pcpu_alloc_noprof+0x730/0xeb0 bpf_map_alloc_percpu+0x69/0xc0 prealloc_init+0x9d/0x1b0 htab_map_alloc+0x363/0x510 map_create+0x215/0x3a0 __sys_bpf+0x16b/0x3e0 __x64_sys_bpf+0x18/0x20 do_syscall_64+0x7b/0x150 entry_SYSCALL_64_after_hwframe+0x4b/0x53
Further investigation shows the reason is due to not 8-byte aligned store of percpu pointer in htab_elem_set_ptr(): (void __percpu *)(l->key + key_size) = pptr;
Note that the whole htab_elem alignment is 8 (for x86_64). If the key_size is 4, that means pptr is stored in a location which is 4 byte aligned but not 8 byte aligned. In mm/kmemleak.c, scan_block() scans the memory based on 8 byte stride, so it won't detect above pptr, hence reporting the memory leak.
In htab_map_alloc(), we already have
htab->elem_size = sizeof(struct htab_elem) +
round_up(htab->map.key_size, 8);
if (percpu)
htab->elem_size += sizeof(void *);
else
htab->elem_size += round_up(htab->map.value_size, 8);
So storing pptr with 8-byte alignment won't cause any problem and can fix kmemleak too.
The issue can be reproduced with bpf selftest as well: 1. Enable CONFIG_DEBUG_KMEMLEAK config 2. Add a getchar() before skel destroy in test_hash_map() in prog_tests/for_each.c. The purpose is to keep map available so kmemleak can be detected. 3. run './test_progs -t for_each/hash_map &' and a kmemleak should be reported.(CVE-2025-37807)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix Preauh_HashValue race condition
If client send multiple session setup requests to ksmbd, Preauh_HashValue race condition could happen. There is no need to free sess->Preauh_HashValue at session setup phase. It can be freed together with session at connection termination phase.(CVE-2025-38561)
In the Linux kernel, the following vulnerability has been resolved:
fs: Prevent file descriptor table allocations exceeding INT_MAX
When sysctl_nr_open is set to a very high value (for example, 1073741816 as set by systemd), processes attempting to use file descriptors near the limit can trigger massive memory allocation attempts that exceed INT_MAX, resulting in a WARNING in mm/slub.c:
WARNING: CPU: 0 PID: 44 at mm/slub.c:5027 __kvmalloc_node_noprof+0x21a/0x288
This happens because kvmalloc_array() and kvmalloc() check if the requested size exceeds INT_MAX and emit a warning when the allocation is not flagged with __GFP_NOWARN.
Specifically, when nr_open is set to 1073741816 (0x3ffffff8) and a process calls dup2(oldfd, 1073741880), the kernel attempts to allocate: - File descriptor array: 1073741880 * 8 bytes = 8,589,935,040 bytes - Multiple bitmaps: ~400MB - Total allocation size: > 8GB (exceeding INT_MAX = 2,147,483,647)
Reproducer: 1. Set /proc/sys/fs/nr_open to 1073741816: # echo 1073741816 > /proc/sys/fs/nr_open
- Run a program that uses a high file descriptor: #include <unistd.h> #include <sys/resource.h>
int main() { struct rlimit rlim = {1073741824, 1073741824}; setrlimit(RLIMIT_NOFILE, &rlim); dup2(2, 1073741880); // Triggers the warning return 0; }
- Observe WARNING in dmesg at mm/slub.c:5027
systemd commit a8b627a introduced automatic bumping of fs.nr_open to the maximum possible value. The rationale was that systems with memory control groups (memcg) no longer need separate file descriptor limits since memory is properly accounted. However, this change overlooked that:
- The kernel's allocation functions still enforce INT_MAX as a maximum size regardless of memcg accounting
- Programs and tests that legitimately test file descriptor limits can inadvertently trigger massive allocations
- The resulting allocations (>8GB) are impractical and will always fail
systemd's algorithm starts with INT_MAX and keeps halving the value until the kernel accepts it. On most systems, this results in nr_open being set to 1073741816 (0x3ffffff8), which is just under 1GB of file descriptors.
While processes rarely use file descriptors near this limit in normal operation, certain selftests (like tools/testing/selftests/core/unshare_test.c) and programs that test file descriptor limits can trigger this issue.
Fix this by adding a check in alloc_fdtable() to ensure the requested allocation size does not exceed INT_MAX. This causes the operation to fail with -EMFILE instead of triggering a kernel warning and avoids the impractical >8GB memory allocation request.(CVE-2025-39756)
In the Linux kernel, the following vulnerability has been resolved:
i40e: remove read access to debugfs files
The 'command' and 'netdev_ops' debugfs files are a legacy debugging interface supported by the i40e driver since its early days by commit 02e9c290814c ("i40e: debugfs interface").
Both of these debugfs files provide a read handler which is mostly useless, and which is implemented with questionable logic. They both use a static 256 byte buffer which is initialized to the empty string. In the case of the 'command' file this buffer is literally never used and simply wastes space. In the case of the 'netdev_ops' file, the last command written is saved here.
On read, the files contents are presented as the name of the device followed by a colon and then the contents of their respective static buffer. For 'command' this will always be "<device>: ". For 'netdev_ops', this will be "<device>: <last command written>". But note the buffer is shared between all devices operated by this module. At best, it is mostly meaningless information, and at worse it could be accessed simultaneously as there doesn't appear to be any locking mechanism.
We have also recently received multiple reports for both read functions about their use of snprintf and potential overflow that could result in reading arbitrary kernel memory. For the 'command' file, this is definitely impossible, since the static buffer is always zero and never written to. For the 'netdev_ops' file, it does appear to be possible, if the user carefully crafts the command input, it will be copied into the buffer, which could be large enough to cause snprintf to truncate, which then causes the copy_to_user to read beyond the length of the buffer allocated by kzalloc.
A minimal fix would be to replace snprintf() with scnprintf() which would cap the return to the number of bytes written, preventing an overflow. A more involved fix would be to drop the mostly useless static buffers, saving 512 bytes and modifying the read functions to stop needing those as input.
Instead, lets just completely drop the read access to these files. These are debug interfaces exposed as part of debugfs, and I don't believe that dropping read access will break any script, as the provided output is pretty useless. You can find the netdev name through other more standard interfaces, and the 'netdev_ops' interface can easily result in garbage if you issue simultaneous writes to multiple devices at once.
In order to properly remove the i40e_dbg_netdev_ops_buf, we need to refactor its write function to avoid using the static buffer. Instead, use the same logic as the i40e_dbg_command_write, with an allocated buffer. Update the code to use this instead of the static buffer, and ensure we free the buffer on exit. This fixes simultaneous writes to 'netdev_ops' on multiple devices, and allows us to remove the now unused static buffer along with removing the read access.(CVE-2025-39901)
In the Linux kernel, the following vulnerability has been resolved:
ACPI: video: Fix use-after-free in acpi_video_switch_brightness()
The switch_brightness_work delayed work accesses device->brightness and device->backlight, freed by acpi_video_dev_unregister_backlight() during device removal.
If the work executes after acpi_video_bus_unregister_backlight() frees these resources, it causes a use-after-free when acpi_video_switch_brightness() dereferences device->brightness or device->backlight.
Fix this by calling cancel_delayed_work_sync() for each device's switch_brightness_work in acpi_video_bus_remove_notify_handler() after removing the notify handler that queues the work. This ensures the work completes before the memory is freed.
| URL | Type | |||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-5.10.0-296.0.0.199.oe2203sp4.aarch64.rpm",
"bpftool-debuginfo-5.10.0-296.0.0.199.oe2203sp4.aarch64.rpm",
"kernel-5.10.0-296.0.0.199.oe2203sp4.aarch64.rpm",
"kernel-debuginfo-5.10.0-296.0.0.199.oe2203sp4.aarch64.rpm",
"kernel-debugsource-5.10.0-296.0.0.199.oe2203sp4.aarch64.rpm",
"kernel-devel-5.10.0-296.0.0.199.oe2203sp4.aarch64.rpm",
"kernel-headers-5.10.0-296.0.0.199.oe2203sp4.aarch64.rpm",
"kernel-source-5.10.0-296.0.0.199.oe2203sp4.aarch64.rpm",
"kernel-tools-5.10.0-296.0.0.199.oe2203sp4.aarch64.rpm",
"kernel-tools-debuginfo-5.10.0-296.0.0.199.oe2203sp4.aarch64.rpm",
"kernel-tools-devel-5.10.0-296.0.0.199.oe2203sp4.aarch64.rpm",
"perf-5.10.0-296.0.0.199.oe2203sp4.aarch64.rpm",
"perf-debuginfo-5.10.0-296.0.0.199.oe2203sp4.aarch64.rpm",
"python3-perf-5.10.0-296.0.0.199.oe2203sp4.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-296.0.0.199.oe2203sp4.aarch64.rpm"
],
"src": [
"kernel-5.10.0-296.0.0.199.oe2203sp4.src.rpm"
],
"x86_64": [
"bpftool-5.10.0-296.0.0.199.oe2203sp4.x86_64.rpm",
"bpftool-debuginfo-5.10.0-296.0.0.199.oe2203sp4.x86_64.rpm",
"kernel-5.10.0-296.0.0.199.oe2203sp4.x86_64.rpm",
"kernel-debuginfo-5.10.0-296.0.0.199.oe2203sp4.x86_64.rpm",
"kernel-debugsource-5.10.0-296.0.0.199.oe2203sp4.x86_64.rpm",
"kernel-devel-5.10.0-296.0.0.199.oe2203sp4.x86_64.rpm",
"kernel-headers-5.10.0-296.0.0.199.oe2203sp4.x86_64.rpm",
"kernel-source-5.10.0-296.0.0.199.oe2203sp4.x86_64.rpm",
"kernel-tools-5.10.0-296.0.0.199.oe2203sp4.x86_64.rpm",
"kernel-tools-debuginfo-5.10.0-296.0.0.199.oe2203sp4.x86_64.rpm",
"kernel-tools-devel-5.10.0-296.0.0.199.oe2203sp4.x86_64.rpm",
"perf-5.10.0-296.0.0.199.oe2203sp4.x86_64.rpm",
"perf-debuginfo-5.10.0-296.0.0.199.oe2203sp4.x86_64.rpm",
"python3-perf-5.10.0-296.0.0.199.oe2203sp4.x86_64.rpm",
"python3-perf-debuginfo-5.10.0-296.0.0.199.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-296.0.0.199.oe2203sp4"
}
],
"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\niommu/arm-smmu-v3-sva: Fix mm use-after-free\n\nWe currently call arm64_mm_context_put() without holding a reference to\nthe mm, which can result in use-after-free. Call mmgrab()/mmdrop() to\nensure the mm only gets freed after we unpinned the ASID.(CVE-2022-49426)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntty: n_gsm: require CAP_NET_ADMIN to attach N_GSM0710 ldisc\n\nAny unprivileged user can attach N_GSM0710 ldisc, but it requires\nCAP_NET_ADMIN to create a GSM network anyway.\n\nRequire initial namespace CAP_NET_ADMIN to do that.(CVE-2023-52880)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mt76: mt7915: fix memory leak in mt7915_mcu_exit\n\nAlways purge mcu skb queues in mt7915_mcu_exit routine even if\nmt7915_firmware_state fails.(CVE-2023-53466)\n\nIn the Linux kernel, the following vulnerability has been resolved:fou: Fix null-ptr-deref in GRO.We observed a null-ptr-deref in fou_gro_receive() while shutting downa host. [0]The NULL pointer is sk-\u0026gt;sk_user_data, and the offset 8 is of protocolin struct fou.When fou_release() is called due to netns dismantle or explicit tunnelteardown, udp_tunnel_sock_release() sets NULL to sk-\u0026gt;sk_user_data.Then, the tunnel socket is destroyed after a single RCU grace period.So, in-flight udp4_gro_receive() could find the socket and execute theFOU GRO handler, where sk-\u0026gt;sk_user_data could be NULL.Let s use rcu_dereference_sk_user_data() in fou_from_sock() and add NULLchecks in FOU GRO handlers.[0]:BUG: kernel NULL pointer dereference, address: 0000000000000008 PF: supervisor read access in kernel mode PF: error_code(0x0000) - not-present pagePGD 80000001032f4067 P4D 80000001032f4067 PUD 103240067 PMD 0SMP PTICPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.216-204.855.amzn2.x86_64 #1Hardware name: Amazon EC2 c5.large/, BIOS 1.0 10/16/2017RIP: 0010:fou_gro_receive (net/ipv4/fou.c:233) [fou]Code: 41 5f c3 cc cc cc cc e8 e7 2e 69 f4 0f 1f 80 00 00 00 00 0f 1f 44 00 00 49 89 f8 41 54 48 89 f7 48 89 d6 49 8b 80 88 02 00 00 \u0026lt;0f\u0026gt; b6 48 08 0f b7 42 4a 66 25 fd fd 80 cc 02 66 89 42 4a 0f b6 42RSP: 0018:ffffa330c0003d08 EFLAGS: 00010297RAX: 0000000000000000 RBX: ffff93d9e3a6b900 RCX: 0000000000000010RDX: ffff93d9e3a6b900 RSI: ffff93d9e3a6b900 RDI: ffff93dac2e24d08RBP: ffff93d9e3a6b900 R08: ffff93dacbce6400 R09: 0000000000000002R10: 0000000000000000 R11: ffffffffb5f369b0 R12: ffff93dacbce6400R13: ffff93dac2e24d08 R14: 0000000000000000 R15: ffffffffb4edd1c0FS: 0000000000000000(0000) GS:ffff93daee800000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000000000008 CR3: 0000000102140001 CR4: 00000000007706f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400PKRU: 55555554Call Trace: \u0026lt;IRQ\u0026gt; ? show_trace_log_lvl (arch/x86/kernel/dumpstack.c:259) ? __die_body.cold (arch/x86/kernel/dumpstack.c:478 arch/x86/kernel/dumpstack.c:420) ? no_context (arch/x86/mm/fault.c:752) ? exc_page_fault (arch/x86/include/asm/irqflags.h:49 arch/x86/include/asm/irqflags.h:89 arch/x86/mm/fault.c:1435 arch/x86/mm/fault.c:1483) ? asm_exc_page_fault (arch/x86/include/asm/idtentry.h:571) ? fou_gro_receive (net/ipv4/fou.c:233) [fou] udp_gro_receive (include/linux/netdevice.h:2552 net/ipv4/udp_offload.c:559) udp4_gro_receive (net/ipv4/udp_offload.c:604) inet_gro_receive (net/ipv4/af_inet.c:1549 (discriminator 7)) dev_gro_receive (net/core/dev.c:6035 (discriminator 4)) napi_gro_receive (net/core/dev.c:6170) ena_clean_rx_irq (drivers/amazon/net/ena/ena_netdev.c:1558) [ena] ena_io_poll (drivers/amazon/net/ena/ena_netdev.c:1742) [ena] napi_poll (net/core/dev.c:6847) net_rx_action (net/core/dev.c:6917) __do_softirq (arch/x86/include/asm/jump_label.h:25 include/linux/jump_label.h:200 include/trace/events/irq.h:142 kernel/softirq.c:299) asm_call_irq_on_stack (arch/x86/entry/entry_64.S:809)\u0026lt;/IRQ\u0026gt; do_softirq_own_stack (arch/x86/include/asm/irq_stack.h:27 arch/x86/include/asm/irq_stack.h:77 arch/x86/kernel/irq_64.c:77) irq_exit_rcu (kernel/softirq.c:393 kernel/softirq.c:423 kernel/softirq.c:435) common_interrupt (arch/x86/kernel/irq.c:239) asm_common_interrupt (arch/x86/include/asm/idtentry.h:626)RIP: 0010:acpi_idle_do_entry (arch/x86/include/asm/irqflags.h:49 arch/x86/include/asm/irqflags.h:89 drivers/acpi/processor_idle.c:114 drivers/acpi/processor_idle.c:575)Code: 8b 15 d1 3c c4 02 ed c3 cc cc cc cc 65 48 8b 04 25 40 ef 01 00 48 8b 00 a8 08 75 eb 0f 1f 44 00 00 0f 00 2d d5 09 55 00 fb f4 \u0026lt;fa\u0026gt; c3 cc cc cc cc e9 be fc ff ff 66 66 2e 0f 1f 84 00 00 00 00 00RSP: 0018:ffffffffb5603e58 EFLAGS: 00000246RAX: 0000000000004000 RBX: ffff93dac0929c00 RCX: ffff93daee833900RDX: ffff93daee800000 RSI: ffff93d---truncated---(CVE-2024-46763)\n\nIn the Linux kernel, the following vulnerability has been resolved:f2fs: Require FMODE_WRITE for atomic write ioctlsThe F2FS ioctls for starting and committing atomic writes check forinode_owner_or_capable(), but this does not give LSMs like SELinux orLandlock an opportunity to deny the write access - if the caller s FSUIDmatches the inode s UID, inode_owner_or_capable() immediately returns true.There are scenarios where LSMs want to deny a process the ability to writeparticular files, even files that the FSUID of the process owns; but thiscan currently partially be bypassed using atomic write ioctls in two ways: - F2FS_IOC_START_ATOMIC_REPLACE + F2FS_IOC_COMMIT_ATOMIC_WRITE can truncate an inode to size 0 - F2FS_IOC_START_ATOMIC_WRITE + F2FS_IOC_ABORT_ATOMIC_WRITE can revert changes another process concurrently made to a fileFix it by requiring FMODE_WRITE for these operations, just like forF2FS_IOC_MOVE_RANGE. Since any legitimate caller should only be using theseioctls when intending to write into the file, that seems unlikely to breakanything.(CVE-2024-47740)\n\nIn the Linux kernel, the following vulnerability has been resolved:net/mlx5e: kTLS, Fix incorrect page refcountingThe kTLS tx handling code is using a mix of get_page() andpage_ref_inc() APIs to increment the page reference. But on the releasepath (mlx5e_ktls_tx_handle_resync_dump_comp()), only put_page() is used.This is an issue when using pages from large folios: the get_page()references are stored on the folio page while the page_ref_inc()references are stored directly in the given page. On release the foliopage will be dereferenced too many times.This was found while doing kTLS testing with sendfile() + ZC when theserved file was read from NFS on a kernel with NFS large folios support(commit 49b29a573da8 ( nfs: add support for large folios )).(CVE-2024-53138)\n\nIn the Linux kernel, the following vulnerability has been resolved:x86/xen: don t do PV iret hypercall through hypercall pageInstead of jumping to the Xen hypercall page for doing the irethypercall, 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)\n\nIn the Linux kernel, the following vulnerability has been resolved:wifi: brcmfmac: fix NULL pointer dereference in brcmf_txfinalize()On removal of the device or unloading of the kernel module a potential NULLpointer dereference occurs.The following sequence deletes the interface: brcmf_detach() brcmf_remove_interface() brcmf_del_if()Inside the brcmf_del_if() function the drvr-\u0026gt;if2bss[ifidx] is updated toBRCMF_BSSIDX_INVALID (-1) if the bsscfgidx matches.After brcmf_remove_interface() call the brcmf_proto_detach() function iscalled providing the following sequence: brcmf_detach() brcmf_proto_detach() brcmf_proto_msgbuf_detach() brcmf_flowring_detach() brcmf_msgbuf_delete_flowring() brcmf_msgbuf_remove_flowring() brcmf_flowring_delete() brcmf_get_ifp() brcmf_txfinalize()Since brcmf_get_ip() can and actually will return NULL in this case thecall to brcmf_txfinalize() will result in a NULL pointer dereference insidebrcmf_txfinalize() when trying to update ifp-\u0026gt;ndev-\u0026gt;stats.tx_errors.This will only happen if a flowring still has an skb.Although the NULL pointer dereference has only been seen when trying toupdate the tx statistic, all other uses of the ifp pointer have beenguarded as well with an early return if ifp is NULL.(CVE-2025-21744)\n\nIn the Linux kernel, the following vulnerability has been resolved:net: let net.core.dev_weight always be non-zeroThe following problem was encountered during stability test:(NULL net_device): NAPI poll function process_backlog+0x0/0x530 returned 1, exceeding its budget of 0.------------[ cut here ]------------list_add double add: new=ffff88905f746f48, prev=ffff88905f746f48, next=ffff88905f746e40.WARNING: CPU: 18 PID: 5462 at lib/list_debug.c:35 __list_add_valid_or_report+0xf3/0x130CPU: 18 UID: 0 PID: 5462 Comm: ping Kdump: loaded Not tainted 6.13.0-rc7+RIP: 0010:__list_add_valid_or_report+0xf3/0x130Call Trace:? __warn+0xcd/0x250? __list_add_valid_or_report+0xf3/0x130enqueue_to_backlog+0x923/0x1070netif_rx_internal+0x92/0x2b0__netif_rx+0x15/0x170loopback_xmit+0x2ef/0x450dev_hard_start_xmit+0x103/0x490__dev_queue_xmit+0xeac/0x1950ip_finish_output2+0x6cc/0x1620ip_output+0x161/0x270ip_push_pending_frames+0x155/0x1a0raw_sendmsg+0xe13/0x1550__sys_sendto+0x3bf/0x4e0__x64_sys_sendto+0xdc/0x1b0do_syscall_64+0x5b/0x170entry_SYSCALL_64_after_hwframe+0x76/0x7eThe reproduction command is as follows: sysctl -w net.core.dev_weight=0 ping 127.0.0.1This is because when the napi s weight is set to 0, process_backlog() mayreturn 0 and clear the NAPI_STATE_SCHED bit of napi-\u0026gt;state, causing thisnapi to be re-polled in net_rx_action() until __do_softirq() times out.Since the NAPI_STATE_SCHED bit has been cleared, napi_schedule_rps() canbe retriggered in enqueue_to_backlog(), causing this issue.Making the napi s weight always non-zero solves this problem.Triggering this issue requires system-wide admin (setting isnot namespaced).(CVE-2025-21806)\n\nIn the Linux kernel, the following vulnerability has been resolved:tty: xilinx_uartps: split sysrq handlinglockdep detects the following circular locking dependency:CPU 0 CPU 1========================== ============================cdns_uart_isr() printk() uart_port_lock(port) console_lock() cdns_uart_console_write() if (!port-\u0026gt;sysrq) uart_port_lock(port) uart_handle_break() port-\u0026gt;sysrq = ... uart_handle_sysrq_char() printk() console_lock()The fixed commit attempts to avoid this situation by only taking theport lock in cdns_uart_console_write if port-\u0026gt;sysrq unset. However, if(as shown above) cdns_uart_console_write runs before port-\u0026gt;sysrq is set,then it will try to take the port lock anyway. This may result in adeadlock.Fix this by splitting sysrq handling into two parts. We use the preparehelper under the port lock and defer handling until we release the lock.(CVE-2025-21820)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix kmemleak warning for percpu hashmap\n\nVlad Poenaru reported the following kmemleak issue:\n\n unreferenced object 0x606fd7c44ac8 (size 32):\n backtrace (crc 0):\n pcpu_alloc_noprof+0x730/0xeb0\n bpf_map_alloc_percpu+0x69/0xc0\n prealloc_init+0x9d/0x1b0\n htab_map_alloc+0x363/0x510\n map_create+0x215/0x3a0\n __sys_bpf+0x16b/0x3e0\n __x64_sys_bpf+0x18/0x20\n do_syscall_64+0x7b/0x150\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\nFurther investigation shows the reason is due to not 8-byte aligned\nstore of percpu pointer in htab_elem_set_ptr():\n *(void __percpu **)(l-\u0026gt;key + key_size) = pptr;\n\nNote that the whole htab_elem alignment is 8 (for x86_64). If the key_size\nis 4, that means pptr is stored in a location which is 4 byte aligned but\nnot 8 byte aligned. In mm/kmemleak.c, scan_block() scans the memory based\non 8 byte stride, so it won\u0026apos;t detect above pptr, hence reporting the memory\nleak.\n\nIn htab_map_alloc(), we already have\n\n htab-\u0026gt;elem_size = sizeof(struct htab_elem) +\n round_up(htab-\u0026gt;map.key_size, 8);\n if (percpu)\n htab-\u0026gt;elem_size += sizeof(void *);\n else\n htab-\u0026gt;elem_size += round_up(htab-\u0026gt;map.value_size, 8);\n\nSo storing pptr with 8-byte alignment won\u0026apos;t cause any problem and can fix\nkmemleak too.\n\nThe issue can be reproduced with bpf selftest as well:\n 1. Enable CONFIG_DEBUG_KMEMLEAK config\n 2. Add a getchar() before skel destroy in test_hash_map() in prog_tests/for_each.c.\n The purpose is to keep map available so kmemleak can be detected.\n 3. run \u0026apos;./test_progs -t for_each/hash_map \u0026amp;\u0026apos; and a kmemleak should be reported.(CVE-2025-37807)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix Preauh_HashValue race condition\n\nIf client send multiple session setup requests to ksmbd,\nPreauh_HashValue race condition could happen.\nThere is no need to free sess-\u0026gt;Preauh_HashValue at session setup phase.\nIt can be freed together with session at connection termination phase.(CVE-2025-38561)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs: Prevent file descriptor table allocations exceeding INT_MAX\n\nWhen sysctl_nr_open is set to a very high value (for example, 1073741816\nas set by systemd), processes attempting to use file descriptors near\nthe limit can trigger massive memory allocation attempts that exceed\nINT_MAX, resulting in a WARNING in mm/slub.c:\n\n WARNING: CPU: 0 PID: 44 at mm/slub.c:5027 __kvmalloc_node_noprof+0x21a/0x288\n\nThis happens because kvmalloc_array() and kvmalloc() check if the\nrequested size exceeds INT_MAX and emit a warning when the allocation is\nnot flagged with __GFP_NOWARN.\n\nSpecifically, when nr_open is set to 1073741816 (0x3ffffff8) and a\nprocess calls dup2(oldfd, 1073741880), the kernel attempts to allocate:\n- File descriptor array: 1073741880 * 8 bytes = 8,589,935,040 bytes\n- Multiple bitmaps: ~400MB\n- Total allocation size: \u0026gt; 8GB (exceeding INT_MAX = 2,147,483,647)\n\nReproducer:\n1. Set /proc/sys/fs/nr_open to 1073741816:\n # echo 1073741816 \u0026gt; /proc/sys/fs/nr_open\n\n2. Run a program that uses a high file descriptor:\n #include \u0026lt;unistd.h\u0026gt;\n #include \u0026lt;sys/resource.h\u0026gt;\n\n int main() {\n struct rlimit rlim = {1073741824, 1073741824};\n setrlimit(RLIMIT_NOFILE, \u0026amp;rlim);\n dup2(2, 1073741880); // Triggers the warning\n return 0;\n }\n\n3. Observe WARNING in dmesg at mm/slub.c:5027\n\nsystemd commit a8b627a introduced automatic bumping of fs.nr_open to the\nmaximum possible value. The rationale was that systems with memory\ncontrol groups (memcg) no longer need separate file descriptor limits\nsince memory is properly accounted. However, this change overlooked\nthat:\n\n1. The kernel\u0026apos;s allocation functions still enforce INT_MAX as a maximum\n size regardless of memcg accounting\n2. Programs and tests that legitimately test file descriptor limits can\n inadvertently trigger massive allocations\n3. The resulting allocations (\u0026gt;8GB) are impractical and will always fail\n\nsystemd\u0026apos;s algorithm starts with INT_MAX and keeps halving the value\nuntil the kernel accepts it. On most systems, this results in nr_open\nbeing set to 1073741816 (0x3ffffff8), which is just under 1GB of file\ndescriptors.\n\nWhile processes rarely use file descriptors near this limit in normal\noperation, certain selftests (like\ntools/testing/selftests/core/unshare_test.c) and programs that test file\ndescriptor limits can trigger this issue.\n\nFix this by adding a check in alloc_fdtable() to ensure the requested\nallocation size does not exceed INT_MAX. This causes the operation to\nfail with -EMFILE instead of triggering a kernel warning and avoids the\nimpractical \u0026gt;8GB memory allocation request.(CVE-2025-39756)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni40e: remove read access to debugfs files\n\nThe \u0026apos;command\u0026apos; and \u0026apos;netdev_ops\u0026apos; debugfs files are a legacy debugging\ninterface supported by the i40e driver since its early days by commit\n02e9c290814c (\u0026quot;i40e: debugfs interface\u0026quot;).\n\nBoth of these debugfs files provide a read handler which is mostly useless,\nand which is implemented with questionable logic. They both use a static\n256 byte buffer which is initialized to the empty string. In the case of\nthe \u0026apos;command\u0026apos; file this buffer is literally never used and simply wastes\nspace. In the case of the \u0026apos;netdev_ops\u0026apos; file, the last command written is\nsaved here.\n\nOn read, the files contents are presented as the name of the device\nfollowed by a colon and then the contents of their respective static\nbuffer. For \u0026apos;command\u0026apos; this will always be \u0026quot;\u0026lt;device\u0026gt;: \u0026quot;. For \u0026apos;netdev_ops\u0026apos;,\nthis will be \u0026quot;\u0026lt;device\u0026gt;: \u0026lt;last command written\u0026gt;\u0026quot;. But note the buffer is\nshared between all devices operated by this module. At best, it is mostly\nmeaningless information, and at worse it could be accessed simultaneously\nas there doesn\u0026apos;t appear to be any locking mechanism.\n\nWe have also recently received multiple reports for both read functions\nabout their use of snprintf and potential overflow that could result in\nreading arbitrary kernel memory. For the \u0026apos;command\u0026apos; file, this is definitely\nimpossible, since the static buffer is always zero and never written to.\nFor the \u0026apos;netdev_ops\u0026apos; file, it does appear to be possible, if the user\ncarefully crafts the command input, it will be copied into the buffer,\nwhich could be large enough to cause snprintf to truncate, which then\ncauses the copy_to_user to read beyond the length of the buffer allocated\nby kzalloc.\n\nA minimal fix would be to replace snprintf() with scnprintf() which would\ncap the return to the number of bytes written, preventing an overflow. A\nmore involved fix would be to drop the mostly useless static buffers,\nsaving 512 bytes and modifying the read functions to stop needing those as\ninput.\n\nInstead, lets just completely drop the read access to these files. These\nare debug interfaces exposed as part of debugfs, and I don\u0026apos;t believe that\ndropping read access will break any script, as the provided output is\npretty useless. You can find the netdev name through other more standard\ninterfaces, and the \u0026apos;netdev_ops\u0026apos; interface can easily result in garbage if\nyou issue simultaneous writes to multiple devices at once.\n\nIn order to properly remove the i40e_dbg_netdev_ops_buf, we need to\nrefactor its write function to avoid using the static buffer. Instead, use\nthe same logic as the i40e_dbg_command_write, with an allocated buffer.\nUpdate the code to use this instead of the static buffer, and ensure we\nfree the buffer on exit. This fixes simultaneous writes to \u0026apos;netdev_ops\u0026apos; on\nmultiple devices, and allows us to remove the now unused static buffer\nalong with removing the read access.(CVE-2025-39901)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nACPI: video: Fix use-after-free in acpi_video_switch_brightness()\n\nThe switch_brightness_work delayed work accesses device-\u0026gt;brightness\nand device-\u0026gt;backlight, freed by acpi_video_dev_unregister_backlight()\nduring device removal.\n\nIf the work executes after acpi_video_bus_unregister_backlight()\nfrees these resources, it causes a use-after-free when\nacpi_video_switch_brightness() dereferences device-\u0026gt;brightness or\ndevice-\u0026gt;backlight.\n\nFix this by calling cancel_delayed_work_sync() for each device\u0026apos;s\nswitch_brightness_work in acpi_video_bus_remove_notify_handler()\nafter removing the notify handler that queues the work. This ensures\nthe work completes before the memory is freed.\n\n[ rjw: Changelog edit ](CVE-2025-40211)",
"id": "OESA-2025-2887",
"modified": "2026-08-06T11:10:01Z",
"published": "2025-12-30T11:10:01Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2887"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49426"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52880"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53466"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46763"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47740"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53138"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53241"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21744"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21806"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21820"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37807"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38561"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39756"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39901"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40211"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2022-49426",
"CVE-2023-52880",
"CVE-2023-53466",
"CVE-2024-46763",
"CVE-2024-47740",
"CVE-2024-53138",
"CVE-2024-53241",
"CVE-2025-21744",
"CVE-2025-21806",
"CVE-2025-21820",
"CVE-2025-37807",
"CVE-2025-38561",
"CVE-2025-39756",
"CVE-2025-39901",
"CVE-2025-40211"
]
}
RHSA-2024:5928
Vulnerability from csaf_opensuse - Published: 2024-08-28 00:00 - Updated: 2026-09-20 11:42RHSA-2024:6744
Vulnerability from csaf_redhat - Published: 2024-09-18 00:24 - Updated: 2026-08-19 17:33In the Linux kernel, the following vulnerability has been resolved: tty: n_gsm: require CAP_NET_ADMIN to attach N_GSM0710 ldisc Any unprivileged user can attach N_GSM0710 ldisc, but it requires CAP_NET_ADMIN to create a GSM network anyway. Require initial namespace CAP_NET_ADMIN to do that.
RHSA-2024:6745
Vulnerability from csaf_redhat - Published: 2024-09-18 00:09 - Updated: 2026-08-19 17:33In the Linux kernel, the following vulnerability has been resolved: tty: n_gsm: require CAP_NET_ADMIN to attach N_GSM0710 ldisc Any unprivileged user can attach N_GSM0710 ldisc, but it requires CAP_NET_ADMIN to create a GSM network anyway. Require initial namespace CAP_NET_ADMIN to do that.
SUSE-SU-2024:1978-1
Vulnerability from csaf_suse - Published: 2024-06-11 07:41 - Updated: 2026-09-20 15:53SUSE-SU-2024:1979-1
Vulnerability from csaf_suse - Published: 2024-06-11 07:41 - Updated: 2026-09-20 15:53SUSE-SU-2024:1983-1
Vulnerability from csaf_suse - Published: 2024-06-11 10:56 - Updated: 2026-09-20 15:53Sightings
| 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.