Action not permitted
Modal body text goes here.
Modal Title
Modal Body
CVE-2024-56704 (GCVE-0-2024-56704)
Vulnerability from cvelistv5 – Published: 2024-12-28 09:46 – Updated: 2026-08-05 11:46- CWE-415 - Double Free
| Vendor | Product | Version | CPE status | |
|---|---|---|---|---|
| Linux | Linux |
Affected:
71ebd71921e451f0f942ddfe85d01e31ddc6eb88 , < 692eb06703afc3e24d889d77e94a0e20229f6a4a
(git)
Affected: 71ebd71921e451f0f942ddfe85d01e31ddc6eb88 , < d74b4b297097bd361b8a9abfde9b521ff464ea9c (git) Affected: 71ebd71921e451f0f942ddfe85d01e31ddc6eb88 , < 7f5a2ed5c1810661e6b03f5a4ebf17682cdea850 (git) Affected: 71ebd71921e451f0f942ddfe85d01e31ddc6eb88 , < 4950408793b118cb8075bcee1f033b543fb719fa (git) Affected: 71ebd71921e451f0f942ddfe85d01e31ddc6eb88 , < b9e26059664bd9ebc64a0e8f5216266fc9f84265 (git) Affected: 71ebd71921e451f0f942ddfe85d01e31ddc6eb88 , < 2bb3ee1bf237557daea1d58007d2e1d4a6502ccf (git) Affected: 71ebd71921e451f0f942ddfe85d01e31ddc6eb88 , < d888f5f5d76b2722c267e6bdf51d445d60647b7b (git) Affected: 71ebd71921e451f0f942ddfe85d01e31ddc6eb88 , < 530bc9f03a102fac95b07cda513bfc16ff69e0ee (git) Affected: 71ebd71921e451f0f942ddfe85d01e31ddc6eb88 , < e43c608f40c065b30964f0a806348062991b802d (git) |
guessed | |
| Linux | Linux |
Affected:
4.12
Unaffected: 0 , < 4.12 (semver) Unaffected: 4.19.325 , ≤ 4.19.* (semver) Unaffected: 5.4.287 , ≤ 5.4.* (semver) Unaffected: 5.10.231 , ≤ 5.10.* (semver) Unaffected: 5.15.174 , ≤ 5.15.* (semver) Unaffected: 6.1.120 , ≤ 6.1.* (semver) Unaffected: 6.6.64 , ≤ 6.6.* (semver) Unaffected: 6.11.11 , ≤ 6.11.* (semver) Unaffected: 6.12.2 , ≤ 6.12.* (semver) Unaffected: 6.13 , ≤ * (original_commit_for_fix) |
guessed |
{
"containers": {
"adp": [
{
"metrics": [
{
"cvssV3_1": {
"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"
}
},
{
"other": {
"content": {
"id": "CVE-2024-56704",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2025-10-01T19:58:47.879822Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-415",
"description": "CWE-415 Double Free",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2025-10-01T20:07:07.289Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
},
{
"providerMetadata": {
"dateUpdated": "2025-11-03T20:52:55.105Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00001.html"
},
{
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html"
}
],
"title": "CVE Program Container"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"net/9p/trans_xen.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "692eb06703afc3e24d889d77e94a0e20229f6a4a",
"status": "affected",
"version": "71ebd71921e451f0f942ddfe85d01e31ddc6eb88",
"versionType": "git"
},
{
"lessThan": "d74b4b297097bd361b8a9abfde9b521ff464ea9c",
"status": "affected",
"version": "71ebd71921e451f0f942ddfe85d01e31ddc6eb88",
"versionType": "git"
},
{
"lessThan": "7f5a2ed5c1810661e6b03f5a4ebf17682cdea850",
"status": "affected",
"version": "71ebd71921e451f0f942ddfe85d01e31ddc6eb88",
"versionType": "git"
},
{
"lessThan": "4950408793b118cb8075bcee1f033b543fb719fa",
"status": "affected",
"version": "71ebd71921e451f0f942ddfe85d01e31ddc6eb88",
"versionType": "git"
},
{
"lessThan": "b9e26059664bd9ebc64a0e8f5216266fc9f84265",
"status": "affected",
"version": "71ebd71921e451f0f942ddfe85d01e31ddc6eb88",
"versionType": "git"
},
{
"lessThan": "2bb3ee1bf237557daea1d58007d2e1d4a6502ccf",
"status": "affected",
"version": "71ebd71921e451f0f942ddfe85d01e31ddc6eb88",
"versionType": "git"
},
{
"lessThan": "d888f5f5d76b2722c267e6bdf51d445d60647b7b",
"status": "affected",
"version": "71ebd71921e451f0f942ddfe85d01e31ddc6eb88",
"versionType": "git"
},
{
"lessThan": "530bc9f03a102fac95b07cda513bfc16ff69e0ee",
"status": "affected",
"version": "71ebd71921e451f0f942ddfe85d01e31ddc6eb88",
"versionType": "git"
},
{
"lessThan": "e43c608f40c065b30964f0a806348062991b802d",
"status": "affected",
"version": "71ebd71921e451f0f942ddfe85d01e31ddc6eb88",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"net/9p/trans_xen.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "4.12"
},
{
"lessThan": "4.12",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "4.19.*",
"status": "unaffected",
"version": "4.19.325",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.287",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.231",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.174",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.120",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.64",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.11.*",
"status": "unaffected",
"version": "6.11.11",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.2",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.13",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "4.19.325",
"versionStartIncluding": "4.12",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.4.287",
"versionStartIncluding": "4.12",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.10.231",
"versionStartIncluding": "4.12",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.15.174",
"versionStartIncluding": "4.12",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.1.120",
"versionStartIncluding": "4.12",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6.64",
"versionStartIncluding": "4.12",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.11.11",
"versionStartIncluding": "4.12",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.12.2",
"versionStartIncluding": "4.12",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.13",
"versionStartIncluding": "4.12",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\n9p/xen: fix release of IRQ\n\nKernel logs indicate an IRQ was double-freed.\n\nPass correct device ID during IRQ release.\n\n[Dominique: remove confusing variable reset to 0]"
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 8.4,
"baseSeverity": "HIGH",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"scenarios": [
{
"lang": "en",
"value": "AV:L - The Xen 9pfs frontend is reached through hypervisor-mediated grant-shared rings, event channels and xenstore state transitions, not through the network stack, so the attack path is a local read/write/signal channel into the guest kernel rather than a network protocol. Guest-side triggering (driver unbind, device teardown) is likewise local.\nAC:L - The wrong-dev_id `free_irq()` fails deterministically on every single ring teardown, so the WARN, the leaked irqaction and the missing `synchronize_irq()` barrier are guaranteed, and the attacker controls both sides of the resulting race by choosing when to drive the device to Closing/removal while continuously notifying the event channel. No condition lies outside the attacker\u0027s influence.\nPR:N - The realistic attacker is a compromised or malicious 9pfs backend/driver domain, which in Xen\u0027s disaggregated threat model holds zero privileges within the victim guest kernel yet fully controls the xenbus state transitions and event-channel notifications needed to trigger and race the teardown.\nUI:N - Device teardown is driven entirely by backend-initiated xenbus state changes and requires no action from any user in the guest; having a 9pfs device attached is a configuration precondition, not victim interaction.\nS:U - The corrupted memory and the resulting control-flow impact are all inside the victim guest\u0027s own Linux kernel, so the vulnerable and impacted components share one security authority; no VM-escape, IOMMU or sandbox boundary is crossed by the flaw itself.\nC:H - Because `synchronize_irq()` is skipped, `xen_9pfs_front_event_handler()` and the subsequently queued `p9_xen_response()` read `ring-\u003epriv-\u003eclient`, `ring-\u003eintf`, `ring-\u003edata.in` and the `p9_client`/`p9_req_t` structures after `kfree(priv-\u003erings)`/`kfree(priv)`, giving a use-after-free read over reclaimable kernel heap contents, which per guidance is High.\nI:H - `schedule_work(\u0026ring-\u003ework)` writes workqueue list pointers into the freed `xen_9pfs_dataring` allocation and later executes `p9_xen_response()` against attacker-reclaimable memory including the `p9_client` and its callback state, yielding a use-after-free write and control-flow hijack primitive suitable for privilege escalation inside the guest.\nA:H - Every teardown hits `WARN(1, \"Trying to free already-free IRQ\")`, which is an immediate panic under `panic_on_warn`, and the descriptor is freed with a live irqaction attached while the ring memory is released underneath a possibly-running handler, producing oopses and slab corruption; each cycle additionally leaks the `struct irqaction` and its module/PM references."
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-08-05T11:46:10.332Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/692eb06703afc3e24d889d77e94a0e20229f6a4a"
},
{
"url": "https://git.kernel.org/stable/c/d74b4b297097bd361b8a9abfde9b521ff464ea9c"
},
{
"url": "https://git.kernel.org/stable/c/7f5a2ed5c1810661e6b03f5a4ebf17682cdea850"
},
{
"url": "https://git.kernel.org/stable/c/4950408793b118cb8075bcee1f033b543fb719fa"
},
{
"url": "https://git.kernel.org/stable/c/b9e26059664bd9ebc64a0e8f5216266fc9f84265"
},
{
"url": "https://git.kernel.org/stable/c/2bb3ee1bf237557daea1d58007d2e1d4a6502ccf"
},
{
"url": "https://git.kernel.org/stable/c/d888f5f5d76b2722c267e6bdf51d445d60647b7b"
},
{
"url": "https://git.kernel.org/stable/c/530bc9f03a102fac95b07cda513bfc16ff69e0ee"
},
{
"url": "https://git.kernel.org/stable/c/e43c608f40c065b30964f0a806348062991b802d"
}
],
"title": "9p/xen: fix release of IRQ",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2024-56704",
"datePublished": "2024-12-28T09:46:25.766Z",
"dateReserved": "2024-12-27T15:00:39.856Z",
"dateUpdated": "2026-08-05T11:46:10.332Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"epss": {
"cve": "CVE-2024-56704",
"date": "2026-09-19",
"epss": "0.00242",
"percentile": "0.1571"
},
"nvd": {
"cve": {
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"net/9p/trans_xen.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "692eb06703afc3e24d889d77e94a0e20229f6a4a",
"status": "affected",
"version": "71ebd71921e451f0f942ddfe85d01e31ddc6eb88",
"versionType": "git"
},
{
"lessThan": "d74b4b297097bd361b8a9abfde9b521ff464ea9c",
"status": "affected",
"version": "71ebd71921e451f0f942ddfe85d01e31ddc6eb88",
"versionType": "git"
},
{
"lessThan": "7f5a2ed5c1810661e6b03f5a4ebf17682cdea850",
"status": "affected",
"version": "71ebd71921e451f0f942ddfe85d01e31ddc6eb88",
"versionType": "git"
},
{
"lessThan": "4950408793b118cb8075bcee1f033b543fb719fa",
"status": "affected",
"version": "71ebd71921e451f0f942ddfe85d01e31ddc6eb88",
"versionType": "git"
},
{
"lessThan": "b9e26059664bd9ebc64a0e8f5216266fc9f84265",
"status": "affected",
"version": "71ebd71921e451f0f942ddfe85d01e31ddc6eb88",
"versionType": "git"
},
{
"lessThan": "2bb3ee1bf237557daea1d58007d2e1d4a6502ccf",
"status": "affected",
"version": "71ebd71921e451f0f942ddfe85d01e31ddc6eb88",
"versionType": "git"
},
{
"lessThan": "d888f5f5d76b2722c267e6bdf51d445d60647b7b",
"status": "affected",
"version": "71ebd71921e451f0f942ddfe85d01e31ddc6eb88",
"versionType": "git"
},
{
"lessThan": "530bc9f03a102fac95b07cda513bfc16ff69e0ee",
"status": "affected",
"version": "71ebd71921e451f0f942ddfe85d01e31ddc6eb88",
"versionType": "git"
},
{
"lessThan": "e43c608f40c065b30964f0a806348062991b802d",
"status": "affected",
"version": "71ebd71921e451f0f942ddfe85d01e31ddc6eb88",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"net/9p/trans_xen.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "4.12"
},
{
"lessThan": "4.12",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "4.19.*",
"status": "unaffected",
"version": "4.19.325",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.287",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.231",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.174",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.120",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.64",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.11.*",
"status": "unaffected",
"version": "6.11.11",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.2",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.13",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"configurations": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "D82AB67D-EDD6-4051-90A4-E9E2918056A7",
"versionEndExcluding": "4.19.325",
"versionStartIncluding": "4.12",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "E4B15788-D35E-4E5B-A9C0-070AE3729B34",
"versionEndExcluding": "5.4.287",
"versionStartIncluding": "4.20",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "B5C644CC-2BD7-4E32-BC54-8DCC7ABE9935",
"versionEndExcluding": "5.10.231",
"versionStartIncluding": "5.5",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "419FD073-1517-4FD5-8158-F94BC68A1E89",
"versionEndExcluding": "5.15.174",
"versionStartIncluding": "5.11",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "09AC6122-E2A4-40FE-9D33-268A1B2EC265",
"versionEndExcluding": "6.1.120",
"versionStartIncluding": "5.16",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "CA16DEE3-ABEC-4449-9F4A-7A3DC4FC36C7",
"versionEndExcluding": "6.6.64",
"versionStartIncluding": "6.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "21434379-192D-472F-9B54-D45E3650E893",
"versionEndExcluding": "6.11.11",
"versionStartIncluding": "6.7",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "D8882B1B-2ABC-4838-AC1D-DBDBB5764776",
"versionEndExcluding": "6.12.2",
"versionStartIncluding": "6.12",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\n9p/xen: fix release of IRQ\n\nKernel logs indicate an IRQ was double-freed.\n\nPass correct device ID during IRQ release.\n\n[Dominique: remove confusing variable reset to 0]"
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: 9p/xen: se corrige la liberaci\u00f3n de IRQ. Los registros del kernel indican que se liber\u00f3 una IRQ dos veces. Se pasa la identificaci\u00f3n del dispositivo correcta durante la liberaci\u00f3n de IRQ. [Dominique: se elimina la variable confusa que se restablece a 0]"
}
],
"id": "CVE-2024-56704",
"lastModified": "2026-08-04T11:22:22.783",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 8.4,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"exploitabilityScore": 2.5,
"impactScore": 5.9,
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"type": "Secondary"
},
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 7.8,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 5.9,
"source": "nvd@nist.gov",
"type": "Primary"
},
{
"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": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"type": "Secondary"
}
],
"ssvcV203": [
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"ssvcData": {
"id": "CVE-2024-56704",
"options": [
{
"exploitation": "none"
},
{
"automatable": "no"
},
{
"technicalImpact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2025-10-01T19:58:47.879822Z",
"version": "2.0.3"
}
}
]
},
"published": "2024-12-28T10:15:18.817",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/2bb3ee1bf237557daea1d58007d2e1d4a6502ccf"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/4950408793b118cb8075bcee1f033b543fb719fa"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/530bc9f03a102fac95b07cda513bfc16ff69e0ee"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/692eb06703afc3e24d889d77e94a0e20229f6a4a"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/7f5a2ed5c1810661e6b03f5a4ebf17682cdea850"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/b9e26059664bd9ebc64a0e8f5216266fc9f84265"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/d74b4b297097bd361b8a9abfde9b521ff464ea9c"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/d888f5f5d76b2722c267e6bdf51d445d60647b7b"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/e43c608f40c065b30964f0a806348062991b802d"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00001.html"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Modified",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "CWE-415"
}
],
"source": "nvd@nist.gov",
"type": "Primary"
},
{
"description": [
{
"lang": "en",
"value": "CWE-415"
}
],
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"type": "Secondary"
}
]
}
},
"redhat_vex": {
"aggregate_severity": "Important",
"current_release_date": "2026-09-12T12:18:04+00:00",
"cve": "CVE-2024-56704",
"id": "CVE-2024-56704",
"initial_release_date": "2024-12-28T00:00:00+00:00",
"product_status:known_not_affected": "198",
"source": "Red Hat CSAF VEX",
"status": "final",
"title": "kernel: 9p/xen: fix release of IRQ",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2024/cve-2024-56704.json",
"version": "3"
},
"vulnrichment": {
"containers": {
"adp": [
{
"providerMetadata": {
"dateUpdated": "2025-11-03T20:52:55.105Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00001.html"
},
{
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html"
}
],
"title": "CVE Program Container"
},
{
"metrics": [
{
"cvssV3_1": {
"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"
}
},
{
"other": {
"content": {
"id": "CVE-2024-56704",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2025-10-01T19:58:47.879822Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-415",
"description": "CWE-415 Double Free",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2025-10-01T15:47:25.645Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"net/9p/trans_xen.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "692eb06703afc3e24d889d77e94a0e20229f6a4a",
"status": "affected",
"version": "71ebd71921e451f0f942ddfe85d01e31ddc6eb88",
"versionType": "git"
},
{
"lessThan": "d74b4b297097bd361b8a9abfde9b521ff464ea9c",
"status": "affected",
"version": "71ebd71921e451f0f942ddfe85d01e31ddc6eb88",
"versionType": "git"
},
{
"lessThan": "7f5a2ed5c1810661e6b03f5a4ebf17682cdea850",
"status": "affected",
"version": "71ebd71921e451f0f942ddfe85d01e31ddc6eb88",
"versionType": "git"
},
{
"lessThan": "4950408793b118cb8075bcee1f033b543fb719fa",
"status": "affected",
"version": "71ebd71921e451f0f942ddfe85d01e31ddc6eb88",
"versionType": "git"
},
{
"lessThan": "b9e26059664bd9ebc64a0e8f5216266fc9f84265",
"status": "affected",
"version": "71ebd71921e451f0f942ddfe85d01e31ddc6eb88",
"versionType": "git"
},
{
"lessThan": "2bb3ee1bf237557daea1d58007d2e1d4a6502ccf",
"status": "affected",
"version": "71ebd71921e451f0f942ddfe85d01e31ddc6eb88",
"versionType": "git"
},
{
"lessThan": "d888f5f5d76b2722c267e6bdf51d445d60647b7b",
"status": "affected",
"version": "71ebd71921e451f0f942ddfe85d01e31ddc6eb88",
"versionType": "git"
},
{
"lessThan": "530bc9f03a102fac95b07cda513bfc16ff69e0ee",
"status": "affected",
"version": "71ebd71921e451f0f942ddfe85d01e31ddc6eb88",
"versionType": "git"
},
{
"lessThan": "e43c608f40c065b30964f0a806348062991b802d",
"status": "affected",
"version": "71ebd71921e451f0f942ddfe85d01e31ddc6eb88",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"net/9p/trans_xen.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "4.12"
},
{
"lessThan": "4.12",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "4.19.*",
"status": "unaffected",
"version": "4.19.325",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.287",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.231",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.174",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.120",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.64",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.11.*",
"status": "unaffected",
"version": "6.11.11",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.2",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.13",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "4.19.325",
"versionStartIncluding": "4.12",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.4.287",
"versionStartIncluding": "4.12",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.10.231",
"versionStartIncluding": "4.12",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.15.174",
"versionStartIncluding": "4.12",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.1.120",
"versionStartIncluding": "4.12",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6.64",
"versionStartIncluding": "4.12",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.11.11",
"versionStartIncluding": "4.12",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.12.2",
"versionStartIncluding": "4.12",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.13",
"versionStartIncluding": "4.12",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\n9p/xen: fix release of IRQ\n\nKernel logs indicate an IRQ was double-freed.\n\nPass correct device ID during IRQ release.\n\n[Dominique: remove confusing variable reset to 0]"
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 8.4,
"baseSeverity": "HIGH",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"scenarios": [
{
"lang": "en",
"value": "AV:L - The Xen 9pfs frontend is reached through hypervisor-mediated grant-shared rings, event channels and xenstore state transitions, not through the network stack, so the attack path is a local read/write/signal channel into the guest kernel rather than a network protocol. Guest-side triggering (driver unbind, device teardown) is likewise local.\nAC:L - The wrong-dev_id `free_irq()` fails deterministically on every single ring teardown, so the WARN, the leaked irqaction and the missing `synchronize_irq()` barrier are guaranteed, and the attacker controls both sides of the resulting race by choosing when to drive the device to Closing/removal while continuously notifying the event channel. No condition lies outside the attacker\u0027s influence.\nPR:N - The realistic attacker is a compromised or malicious 9pfs backend/driver domain, which in Xen\u0027s disaggregated threat model holds zero privileges within the victim guest kernel yet fully controls the xenbus state transitions and event-channel notifications needed to trigger and race the teardown.\nUI:N - Device teardown is driven entirely by backend-initiated xenbus state changes and requires no action from any user in the guest; having a 9pfs device attached is a configuration precondition, not victim interaction.\nS:U - The corrupted memory and the resulting control-flow impact are all inside the victim guest\u0027s own Linux kernel, so the vulnerable and impacted components share one security authority; no VM-escape, IOMMU or sandbox boundary is crossed by the flaw itself.\nC:H - Because `synchronize_irq()` is skipped, `xen_9pfs_front_event_handler()` and the subsequently queued `p9_xen_response()` read `ring-\u003epriv-\u003eclient`, `ring-\u003eintf`, `ring-\u003edata.in` and the `p9_client`/`p9_req_t` structures after `kfree(priv-\u003erings)`/`kfree(priv)`, giving a use-after-free read over reclaimable kernel heap contents, which per guidance is High.\nI:H - `schedule_work(\u0026ring-\u003ework)` writes workqueue list pointers into the freed `xen_9pfs_dataring` allocation and later executes `p9_xen_response()` against attacker-reclaimable memory including the `p9_client` and its callback state, yielding a use-after-free write and control-flow hijack primitive suitable for privilege escalation inside the guest.\nA:H - Every teardown hits `WARN(1, \"Trying to free already-free IRQ\")`, which is an immediate panic under `panic_on_warn`, and the descriptor is freed with a live irqaction attached while the ring memory is released underneath a possibly-running handler, producing oopses and slab corruption; each cycle additionally leaks the `struct irqaction` and its module/PM references."
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-08-05T11:46:10.332Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/692eb06703afc3e24d889d77e94a0e20229f6a4a"
},
{
"url": "https://git.kernel.org/stable/c/d74b4b297097bd361b8a9abfde9b521ff464ea9c"
},
{
"url": "https://git.kernel.org/stable/c/7f5a2ed5c1810661e6b03f5a4ebf17682cdea850"
},
{
"url": "https://git.kernel.org/stable/c/4950408793b118cb8075bcee1f033b543fb719fa"
},
{
"url": "https://git.kernel.org/stable/c/b9e26059664bd9ebc64a0e8f5216266fc9f84265"
},
{
"url": "https://git.kernel.org/stable/c/2bb3ee1bf237557daea1d58007d2e1d4a6502ccf"
},
{
"url": "https://git.kernel.org/stable/c/d888f5f5d76b2722c267e6bdf51d445d60647b7b"
},
{
"url": "https://git.kernel.org/stable/c/530bc9f03a102fac95b07cda513bfc16ff69e0ee"
},
{
"url": "https://git.kernel.org/stable/c/e43c608f40c065b30964f0a806348062991b802d"
}
],
"title": "9p/xen: fix release of IRQ",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2024-56704",
"datePublished": "2024-12-28T09:46:25.766Z",
"dateReserved": "2024-12-27T15:00:39.856Z",
"dateUpdated": "2026-08-05T11:46:10.332Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
}
}
OESA-2025-1096 (CVE-2023-52434)
Vulnerability from osv_openeuler – Published: 2025-02-08 11:08 – Updated: 2026-08-06 11:08 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix potential OOBs in smb2_parse_contexts()
Validate offsets and lengths before dereferencing create contexts in smb2_parse_contexts().
This fixes following oops when accessing invalid create contexts from server:
BUG: unable to handle page fault for address: ffff8881178d8cc3 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 4a01067 P4D 4a01067 PUD 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 3 PID: 1736 Comm: mount.cifs Not tainted 6.7.0-rc4 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014 RIP: 0010:smb2_parse_contexts+0xa0/0x3a0 [cifs] Code: f8 10 75 13 48 b8 93 ad 25 50 9c b4 11 e7 49 39 06 0f 84 d2 00 00 00 8b 45 00 85 c0 74 61 41 29 c5 48 01 c5 41 83 fd 0f 76 55 <0f> b7 7d 04 0f b7 45 06 4c 8d 74 3d 00 66 83 f8 04 75 bc ba 04 00 RSP: 0018:ffffc900007939e0 EFLAGS: 00010216 RAX: ffffc90000793c78 RBX: ffff8880180cc000 RCX: ffffc90000793c90 RDX: ffffc90000793cc0 RSI: ffff8880178d8cc0 RDI: ffff8880180cc000 RBP: ffff8881178d8cbf R08: ffffc90000793c22 R09: 0000000000000000 R10: ffff8880180cc000 R11: 0000000000000024 R12: 0000000000000000 R13: 0000000000000020 R14: 0000000000000000 R15: ffffc90000793c22 FS: 00007f873753cbc0(0000) GS:ffff88806bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff8881178d8cc3 CR3: 00000000181ca000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: <TASK> ? __die+0x23/0x70 ? page_fault_oops+0x181/0x480 ? search_module_extables+0x19/0x60 ? srso_alias_return_thunk+0x5/0xfbef5 ? exc_page_fault+0x1b6/0x1c0 ? asm_exc_page_fault+0x26/0x30 ? smb2_parse_contexts+0xa0/0x3a0 [cifs] SMB2_open+0x38d/0x5f0 [cifs] ? smb2_is_path_accessible+0x138/0x260 [cifs] smb2_is_path_accessible+0x138/0x260 [cifs] cifs_is_path_remote+0x8d/0x230 [cifs] cifs_mount+0x7e/0x350 [cifs] cifs_smb3_do_mount+0x128/0x780 [cifs] smb3_get_tree+0xd9/0x290 [cifs] vfs_get_tree+0x2c/0x100 ? capable+0x37/0x70 path_mount+0x2d7/0xb80 ? srso_alias_return_thunk+0x5/0xfbef5 ? _raw_spin_unlock_irqrestore+0x44/0x60 __x64_sys_mount+0x11a/0x150 do_syscall_64+0x47/0xf0 entry_SYSCALL_64_after_hwframe+0x6f/0x77 RIP: 0033:0x7f8737657b1e(CVE-2023-52434)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix race condition between session lookup and expire
Thread A + Thread B ksmbd_session_lookup | smb2_sess_setup sess = xa_load | | | xa_erase(&conn->sessions, sess->id); | | ksmbd_session_destroy(sess) --> kfree(sess) | // UAF! | sess->last_active = jiffies | +
This patch add rwsem to fix race condition between ksmbd_session_lookup and ksmbd_expire_session.(CVE-2023-52480)
In the Linux kernel, the following vulnerability has been resolved:
PM / devfreq: Fix buffer overflow in trans_stat_show
Fix buffer overflow in trans_stat_show().
Convert simple snprintf to the more secure scnprintf with size of PAGE_SIZE.
Add condition checking if we are exceeding PAGE_SIZE and exit early from loop. Also add at the end a warning that we exceeded PAGE_SIZE and that stats is disabled.
Return -EFBIG in the case where we don't have enough space to write the full transition table.
Also document in the ABI that this function can return -EFBIG error.(CVE-2023-52614)
In the Linux kernel, the following vulnerability has been resolved:
iio: adc: ad7091r: Allow users to configure device events
AD7091R-5 devices are supported by the ad7091r-5 driver together with the ad7091r-base driver. Those drivers declared iio events for notifying user space when ADC readings fall bellow the thresholds of low limit registers or above the values set in high limit registers. However, to configure iio events and their thresholds, a set of callback functions must be implemented and those were not present until now. The consequence of trying to configure ad7091r-5 events without the proper callback functions was a null pointer dereference in the kernel because the pointers to the callback functions were not set.
Implement event configuration callbacks allowing users to read/write event thresholds and enable/disable event generation.
Since the event spec structs are generic to AD7091R devices, also move those from the ad7091r-5 driver the base driver so they can be reused when support for ad7091r-2/-4/-8 be added.(CVE-2023-52627)
In the Linux kernel, the following vulnerability has been resolved:
drm/i915: Fix potential context UAFs
gem_context_register() makes the context visible to userspace, and which point a separate thread can trigger the I915_GEM_CONTEXT_DESTROY ioctl. So we need to ensure that nothing uses the ctx ptr after this. And we need to ensure that adding the ctx to the xarray is the last thing that gem_context_register() does with the ctx pointer.
[tursulin: Stable and fixes tags add/tidy.] (cherry picked from commit bed4b455cf5374e68879be56971c1da563bcd90c)(CVE-2023-52913)
A race condition was found in the Linux kernel's net/bluetooth device driver in conn_info_{min,max}_age_set() function. This can result in integrity overflow issue, possibly leading to bluetooth connection abnormality or denial of service.
(CVE-2024-24857)
A race condition was found in the Linux kernel's net/bluetooth in sniff_{min,max}_interval_set() function. This can result in a bluetooth sniffing exception issue, possibly leading denial of service.
(CVE-2024-24859)
In the Linux kernel, the following vulnerability has been resolved:
xhci: handle isoc Babble and Buffer Overrun events properly
xHCI 4.9 explicitly forbids assuming that the xHC has released its ownership of a multi-TRB TD when it reports an error on one of the early TRBs. Yet the driver makes such assumption and releases the TD, allowing the remaining TRBs to be freed or overwritten by new TDs.
The xHC should also report completion of the final TRB due to its IOC flag being set by us, regardless of prior errors. This event cannot be recognized if the TD has already been freed earlier, resulting in "Transfer event TRB DMA ptr not part of current TD" error message.
Fix this by reusing the logic for processing isoc Transaction Errors. This also handles hosts which fail to report the final completion.
Fix transfer length reporting on Babble errors. They may be caused by device malfunction, no guarantee that the buffer has been filled.(CVE-2024-26659)
In the Linux kernel, the following vulnerability has been resolved:
hwmon: (coretemp) Fix out-of-bounds memory access
Fix a bug that pdata->cpu_map[] is set before out-of-bounds check. The problem might be triggered on systems with more than 128 cores per package.(CVE-2024-26664)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nft_ct: sanitize layer 3 and 4 protocol number in custom expectations
- Disallow families other than NFPROTO_{IPV4,IPV6,INET}.
- Disallow layer 4 protocol with no ports, since destination port is a mandatory attribute for this object.(CVE-2024-26673)
In the Linux kernel, the following vulnerability has been resolved:
usb: roles: fix NULL pointer issue when put module's reference
In current design, usb role class driver will get usb_role_switch parent's module reference after the user get usb_role_switch device and put the reference after the user put the usb_role_switch device. However, the parent device of usb_role_switch may be removed before the user put the usb_role_switch. If so, then, NULL pointer issue will be met when the user put the parent module's reference.
This will save the module pointer in structure of usb_role_switch. Then, we don't need to find module by iterating long relations.(CVE-2024-26747)
In the Linux kernel, the following vulnerability has been resolved:
usb: cdns3: fix memory double free when handle zero packet
829 if (request->complete) { 830 spin_unlock(&priv_dev->lock); 831 usb_gadget_giveback_request(&priv_ep->endpoint, 832 request); 833 spin_lock(&priv_dev->lock); 834 } 835 836 if (request->buf == priv_dev->zlp_buf) 837 cdns3_gadget_ep_free_request(&priv_ep->endpoint, request);
Driver append an additional zero packet request when queue a packet, which length mod max packet size is 0. When transfer complete, run to line 831, usb_gadget_giveback_request() will free this requestion. 836 condition is true, so cdns3_gadget_ep_free_request() free this request again.
Log:
[ 1920.140696][ T150] BUG: KFENCE: use-after-free read in cdns3_gadget_giveback+0x134/0x2c0 [cdns3] [ 1920.140696][ T150] [ 1920.151837][ T150] Use-after-free read at 0x000000003d1cd10b (in kfence-#36): [ 1920.159082][ T150] cdns3_gadget_giveback+0x134/0x2c0 [cdns3] [ 1920.164988][ T150] cdns3_transfer_completed+0x438/0x5f8 [cdns3]
Add check at line 829, skip call usb_gadget_giveback_request() if it is additional zero length packet request. Needn't call usb_gadget_giveback_request() because it is allocated in this driver.(CVE-2024-26748)
In the Linux kernel, the following vulnerability has been resolved:
usb: cdns3: fixed memory use after free at cdns3_gadget_ep_disable()
... cdns3_gadget_ep_free_request(&priv_ep->endpoint, &priv_req->request); list_del_init(&priv_req->list); ...
'priv_req' actually free at cdns3_gadget_ep_free_request(). But list_del_init() use priv_req->list after it.
[ 1542.642868][ T534] BUG: KFENCE: use-after-free read in __list_del_entry_valid+0x10/0xd4 [ 1542.642868][ T534] [ 1542.653162][ T534] Use-after-free read at 0x000000009ed0ba99 (in kfence-#3): [ 1542.660311][ T534] __list_del_entry_valid+0x10/0xd4 [ 1542.665375][ T534] cdns3_gadget_ep_disable+0x1f8/0x388 [cdns3] [ 1542.671571][ T534] usb_ep_disable+0x44/0xe4 [ 1542.675948][ T534] ffs_func_eps_disable+0x64/0xc8 [ 1542.680839][ T534] ffs_func_set_alt+0x74/0x368 [ 1542.685478][ T534] ffs_func_disable+0x18/0x28
Move list_del_init() before cdns3_gadget_ep_free_request() to resolve this problem.(CVE-2024-26749)
In the Linux kernel, the following vulnerability has been resolved:
crypto: virtio/akcipher - Fix stack overflow on memcpy
sizeof(struct virtio_crypto_akcipher_session_para) is less than sizeof(struct virtio_crypto_op_ctrl_req::u), copying more bytes from stack variable leads stack overflow. Clang reports this issue by commands: make -j CC=clang-14 mrproper >/dev/null 2>&1 make -j O=/tmp/crypto-build CC=clang-14 allmodconfig >/dev/null 2>&1 make -j O=/tmp/crypto-build W=1 CC=clang-14 drivers/crypto/virtio/ virtio_crypto_akcipher_algs.o(CVE-2024-26753)
In the Linux kernel, the following vulnerability has been resolved:
mptcp: fix possible deadlock in subflow diag
Syzbot and Eric reported a lockdep splat in the subflow diag:
WARNING: possible circular locking dependency detected 6.8.0-rc4-syzkaller-00212-g40b9385dd8e6 #0 Not tainted
syz-executor.2/24141 is trying to acquire lock: ffff888045870130 (k-sk_lock-AF_INET6){+.+.}-{0:0}, at: tcp_diag_put_ulp net/ipv4/tcp_diag.c:100 [inline] ffff888045870130 (k-sk_lock-AF_INET6){+.+.}-{0:0}, at: tcp_diag_get_aux+0x738/0x830 net/ipv4/tcp_diag.c:137
but task is already holding lock: ffffc9000135e488 (&h->lhash2[i].lock){+.+.}-{2:2}, at: spin_lock include/linux/spinlock.h:351 [inline] ffffc9000135e488 (&h->lhash2[i].lock){+.+.}-{2:2}, at: inet_diag_dump_icsk+0x39f/0x1f80 net/ipv4/inet_diag.c:1038
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&h->lhash2[i].lock){+.+.}-{2:2}: lock_acquire+0x1e3/0x530 kernel/locking/lockdep.c:5754 __raw_spin_lock include/linux/spinlock_api_smp.h:133 [inline] _raw_spin_lock+0x2e/0x40 kernel/locking/spinlock.c:154 spin_lock include/linux/spinlock.h:351 [inline] __inet_hash+0x335/0xbe0 net/ipv4/inet_hashtables.c:743 inet_csk_listen_start+0x23a/0x320 net/ipv4/inet_connection_sock.c:1261 __inet_listen_sk+0x2a2/0x770 net/ipv4/af_inet.c:217 inet_listen+0xa3/0x110 net/ipv4/af_inet.c:239 rds_tcp_listen_init+0x3fd/0x5a0 net/rds/tcp_listen.c:316 rds_tcp_init_net+0x141/0x320 net/rds/tcp.c:577 ops_init+0x352/0x610 net/core/net_namespace.c:136 __register_pernet_operations net/core/net_namespace.c:1214 [inline] register_pernet_operations+0x2cb/0x660 net/core/net_namespace.c:1283 register_pernet_device+0x33/0x80 net/core/net_namespace.c:1370 rds_tcp_init+0x62/0xd0 net/rds/tcp.c:735 do_one_initcall+0x238/0x830 init/main.c:1236 do_initcall_level+0x157/0x210 init/main.c:1298 do_initcalls+0x3f/0x80 init/main.c:1314 kernel_init_freeable+0x42f/0x5d0 init/main.c:1551 kernel_init+0x1d/0x2a0 init/main.c:1441 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:242
-> #0 (k-sk_lock-AF_INET6){+.+.}-{0:0}: check_prev_add kernel/locking/lockdep.c:3134 [inline] check_prevs_add kernel/locking/lockdep.c:3253 [inline] validate_chain+0x18ca/0x58e0 kernel/locking/lockdep.c:3869 __lock_acquire+0x1345/0x1fd0 kernel/locking/lockdep.c:5137 lock_acquire+0x1e3/0x530 kernel/locking/lockdep.c:5754 lock_sock_fast include/net/sock.h:1723 [inline] subflow_get_info+0x166/0xd20 net/mptcp/diag.c:28 tcp_diag_put_ulp net/ipv4/tcp_diag.c:100 [inline] tcp_diag_get_aux+0x738/0x830 net/ipv4/tcp_diag.c:137 inet_sk_diag_fill+0x10ed/0x1e00 net/ipv4/inet_diag.c:345 inet_diag_dump_icsk+0x55b/0x1f80 net/ipv4/inet_diag.c:1061 __inet_diag_dump+0x211/0x3a0 net/ipv4/inet_diag.c:1263 inet_diag_dump_compat+0x1c1/0x2d0 net/ipv4/inet_diag.c:1371 netlink_dump+0x59b/0xc80 net/netlink/af_netlink.c:2264 __netlink_dump_start+0x5df/0x790 net/netlink/af_netlink.c:2370 netlink_dump_start include/linux/netlink.h:338 [inline] inet_diag_rcv_msg_compat+0x209/0x4c0 net/ipv4/inet_diag.c:1405 sock_diag_rcv_msg+0xe7/0x410 netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2543 sock_diag_rcv+0x2a/0x40 net/core/sock_diag.c:280 netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline] netlink_unicast+0x7ea/0x980 net/netlink/af_netlink.c:1367 netlink_sendmsg+0xa3b/0xd70 net/netlink/af_netlink.c:1908 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:745 _syssendmsg+0x525/0x7d0 net/socket.c:2584 _sys_sendmsg net/socket.c:2638 [inline] __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667 do_syscall_64+0xf9/0x240 entry_SYSCALL_64_after_hwframe+0x6f/0x77
As noted by Eric we can break the lock dependency chain avoid dumping ---truncated---(CVE-2024-26781)
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: fsl-qdma: fix SoC may hang on 16 byte unaligned read
There is chip (ls1028a) errata:
The SoC may hang on 16 byte unaligned read transactions by QDMA.
Unaligned read transactions initiated by QDMA may stall in the NOC (Network On-Chip), causing a deadlock condition. Stalled transactions will trigger completion timeouts in PCIe controller.
Workaround: Enable prefetch by setting the source descriptor prefetchable bit ( SD[PF] = 1 ).
Implement this workaround.(CVE-2024-26790)
In the Linux kernel, the following vulnerability has been resolved:
gtp: fix use-after-free and null-ptr-deref in gtp_newlink()
The gtp_link_ops operations structure for the subsystem must be registered after registering the gtp_net_ops pernet operations structure.
Syzkaller hit 'general protection fault in gtp_genl_dump_pdp' bug:
[ 1010.702740] gtp: GTP module unloaded [ 1010.715877] general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] SMP KASAN NOPTI [ 1010.715888] KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] [ 1010.715895] CPU: 1 PID: 128616 Comm: a.out Not tainted 6.8.0-rc6-std-def-alt1 #1 [ 1010.715899] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-alt1 04/01/2014 [ 1010.715908] RIP: 0010:gtp_newlink+0x4d7/0x9c0 [gtp] [ 1010.715915] Code: 80 3c 02 00 0f 85 41 04 00 00 48 8b bb d8 05 00 00 e8 ed f6 ff ff 48 89 c2 48 89 c5 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f 85 4f 04 00 00 4c 89 e2 4c 8b 6d 00 48 b8 00 00 00 [ 1010.715920] RSP: 0018:ffff888020fbf180 EFLAGS: 00010203 [ 1010.715929] RAX: dffffc0000000000 RBX: ffff88800399c000 RCX: 0000000000000000 [ 1010.715933] RDX: 0000000000000001 RSI: ffffffff84805280 RDI: 0000000000000282 [ 1010.715938] RBP: 000000000000000d R08: 0000000000000001 R09: 0000000000000000 [ 1010.715942] R10: 0000000000000001 R11: 0000000000000001 R12: ffff88800399cc80 [ 1010.715947] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000400 [ 1010.715953] FS: 00007fd1509ab5c0(0000) GS:ffff88805b300000(0000) knlGS:0000000000000000 [ 1010.715958] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1010.715962] CR2: 0000000000000000 CR3: 000000001c07a000 CR4: 0000000000750ee0 [ 1010.715968] PKRU: 55555554 [ 1010.715972] Call Trace: [ 1010.715985] ? __die_body.cold+0x1a/0x1f [ 1010.715995] ? die_addr+0x43/0x70 [ 1010.716002] ? exc_general_protection+0x199/0x2f0 [ 1010.716016] ? asm_exc_general_protection+0x1e/0x30 [ 1010.716026] ? gtp_newlink+0x4d7/0x9c0 [gtp] [ 1010.716034] ? gtp_net_exit+0x150/0x150 [gtp] [ 1010.716042] __rtnl_newlink+0x1063/0x1700 [ 1010.716051] ? rtnl_setlink+0x3c0/0x3c0 [ 1010.716063] ? is_bpf_text_address+0xc0/0x1f0 [ 1010.716070] ? kernel_text_address.part.0+0xbb/0xd0 [ 1010.716076] ? __kernel_text_address+0x56/0xa0 [ 1010.716084] ? unwind_get_return_address+0x5a/0xa0 [ 1010.716091] ? create_prof_cpu_mask+0x30/0x30 [ 1010.716098] ? arch_stack_walk+0x9e/0xf0 [ 1010.716106] ? stack_trace_save+0x91/0xd0 [ 1010.716113] ? stack_trace_consume_entry+0x170/0x170 [ 1010.716121] ? __lock_acquire+0x15c5/0x5380 [ 1010.716139] ? mark_held_locks+0x9e/0xe0 [ 1010.716148] ? kmem_cache_alloc_trace+0x35f/0x3c0 [ 1010.716155] ? __rtnl_newlink+0x1700/0x1700 [ 1010.716160] rtnl_newlink+0x69/0xa0 [ 1010.716166] rtnetlink_rcv_msg+0x43b/0xc50 [ 1010.716172] ? rtnl_fdb_dump+0x9f0/0x9f0 [ 1010.716179] ? lock_acquire+0x1fe/0x560 [ 1010.716188] ? netlink_deliver_tap+0x12f/0xd50 [ 1010.716196] netlink_rcv_skb+0x14d/0x440 [ 1010.716202] ? rtnl_fdb_dump+0x9f0/0x9f0 [ 1010.716208] ? netlink_ack+0xab0/0xab0 [ 1010.716213] ? netlink_deliver_tap+0x202/0xd50 [ 1010.716220] ? netlink_deliver_tap+0x218/0xd50 [ 1010.716226] ? __virt_addr_valid+0x30b/0x590 [ 1010.716233] netlink_unicast+0x54b/0x800 [ 1010.716240] ? netlink_attachskb+0x870/0x870 [ 1010.716248] ? __check_object_size+0x2de/0x3b0 [ 1010.716254] netlink_sendmsg+0x938/0xe40 [ 1010.716261] ? netlink_unicast+0x800/0x800 [ 1010.716269] ? __import_iovec+0x292/0x510 [ 1010.716276] ? netlink_unicast+0x800/0x800 [ 1010.716284] __sock_sendmsg+0x159/0x190 [ 1010.716290] _syssendmsg+0x712/0x880 [ 1010.716297] ? sock_write_iter+0x3d0/0x3d0 [ 1010.716304] ? ia32_sys_recvmmsg+0x270/0x270 [ 1010.716309] ? lock_acquire+0x1fe/0x560 [ 1010.716315] ? drain_array_locked+0x90/0x90 [ 1010.716324] ___sys_sendmsg+0xf8/0x170 [ 1010.716331] ? sendmsg_copy_msghdr+0x170/0x170 [ 1010.716337] ? lockdep_init_map ---truncated---(CVE-2024-26793)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix potencial out-of-bounds when buffer offset is invalid
I found potencial out-of-bounds when buffer offset fields of a few requests is invalid. This patch set the minimum value of buffer offset field to ->Buffer offset to validate buffer length.(CVE-2024-26952)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix slab-out-of-bounds in smb_strndup_from_utf16()
If ->NameOffset of smb2_create_req is smaller than Buffer offset of smb2_create_req, slab-out-of-bounds read can happen from smb2_open. This patch set the minimum value of the name offset to the buffer offset to validate name length of smb2_create_req().(CVE-2024-26954)
In the Linux kernel, the following vulnerability has been resolved:
clk: Get runtime PM before walking tree during disable_unused
Doug reported [1] the following hung task:
INFO: task swapper/0:1 blocked for more than 122 seconds. Not tainted 5.15.149-21875-gf795ebc40eb8 #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:swapper/0 state:D stack: 0 pid: 1 ppid: 0 flags:0x00000008 Call trace: __switch_to+0xf4/0x1f4 __schedule+0x418/0xb80 schedule+0x5c/0x10c rpm_resume+0xe0/0x52c rpm_resume+0x178/0x52c __pm_runtime_resume+0x58/0x98 clk_pm_runtime_get+0x30/0xb0 clk_disable_unused_subtree+0x58/0x208 clk_disable_unused_subtree+0x38/0x208 clk_disable_unused_subtree+0x38/0x208 clk_disable_unused_subtree+0x38/0x208 clk_disable_unused_subtree+0x38/0x208 clk_disable_unused+0x4c/0xe4 do_one_initcall+0xcc/0x2d8 do_initcall_level+0xa4/0x148 do_initcalls+0x5c/0x9c do_basic_setup+0x24/0x30 kernel_init_freeable+0xec/0x164 kernel_init+0x28/0x120 ret_from_fork+0x10/0x20 INFO: task kworker/u16:0:9 blocked for more than 122 seconds. Not tainted 5.15.149-21875-gf795ebc40eb8 #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/u16:0 state:D stack: 0 pid: 9 ppid: 2 flags:0x00000008 Workqueue: events_unbound deferred_probe_work_func Call trace: __switch_to+0xf4/0x1f4 __schedule+0x418/0xb80 schedule+0x5c/0x10c schedule_preempt_disabled+0x2c/0x48 __mutex_lock+0x238/0x488 __mutex_lock_slowpath+0x1c/0x28 mutex_lock+0x50/0x74 clk_prepare_lock+0x7c/0x9c clk_core_prepare_lock+0x20/0x44 clk_prepare+0x24/0x30 clk_bulk_prepare+0x40/0xb0 mdss_runtime_resume+0x54/0x1c8 pm_generic_runtime_resume+0x30/0x44 __genpd_runtime_resume+0x68/0x7c genpd_runtime_resume+0x108/0x1f4 __rpm_callback+0x84/0x144 rpm_callback+0x30/0x88 rpm_resume+0x1f4/0x52c rpm_resume+0x178/0x52c __pm_runtime_resume+0x58/0x98 __device_attach+0xe0/0x170 device_initial_probe+0x1c/0x28 bus_probe_device+0x3c/0x9c device_add+0x644/0x814 mipi_dsi_device_register_full+0xe4/0x170 devm_mipi_dsi_device_register_full+0x28/0x70 ti_sn_bridge_probe+0x1dc/0x2c0 auxiliary_bus_probe+0x4c/0x94 really_probe+0xcc/0x2c8 __driver_probe_device+0xa8/0x130 driver_probe_device+0x48/0x110 __device_attach_driver+0xa4/0xcc bus_for_each_drv+0x8c/0xd8 __device_attach+0xf8/0x170 device_initial_probe+0x1c/0x28 bus_probe_device+0x3c/0x9c deferred_probe_work_func+0x9c/0xd8 process_one_work+0x148/0x518 worker_thread+0x138/0x350 kthread+0x138/0x1e0 ret_from_fork+0x10/0x20
The first thread is walking the clk tree and calling clk_pm_runtime_get() to power on devices required to read the clk hardware via struct clk_ops::is_enabled(). This thread holds the clk prepare_lock, and is trying to runtime PM resume a device, when it finds that the device is in the process of resuming so the thread schedule()s away waiting for the device to finish resuming before continuing. The second thread is runtime PM resuming the same device, but the runtime resume callback is calling clk_prepare(), trying to grab the prepare_lock waiting on the first thread.
This is a classic ABBA deadlock. To properly fix the deadlock, we must never runtime PM resume or suspend a device with the clk prepare_lock held. Actually doing that is near impossible today because the global prepare_lock would have to be dropped in the middle of the tree, the device runtime PM resumed/suspended, and then the prepare_lock grabbed again to ensure consistency of the clk tree topology. If anything changes with the clk tree in the meantime, we've lost and will need to start the operation all over again.
Luckily, most of the time we're simply incrementing or decrementing the runtime PM count on an active device, so we don't have the chance to schedule away with the prepare_lock held. Let's fix this immediate problem that can be ---truncated---(CVE-2024-27004)
In the Linux kernel, the following vulnerability has been resolved:
fpga: bridge: add owner module and take its refcount
The current implementation of the fpga bridge assumes that the low-level module registers a driver for the parent device and uses its owner pointer to take the module's refcount. This approach is problematic since it can lead to a null pointer dereference while attempting to get the bridge if the parent device does not have a driver.
To address this problem, add a module owner pointer to the fpga_bridge struct and use it to take the module's refcount. Modify the function for registering a bridge to take an additional owner module parameter and rename it to avoid conflicts. Use the old function name for a helper macro that automatically sets the module that registers the bridge as the owner. This ensures compatibility with existing low-level control modules and reduces the chances of registering a bridge without setting the owner.
Also, update the documentation to keep it consistent with the new interface for registering an fpga bridge.
Other changes: opportunistically move put_device() from __fpga_bridge_get() to fpga_bridge_get() and of_fpga_bridge_get() to improve code clarity since the bridge device is taken in these functions.(CVE-2024-36479)
In the Linux kernel, the following vulnerability has been resolved:
fpga: manager: add owner module and take its refcount
The current implementation of the fpga manager assumes that the low-level module registers a driver for the parent device and uses its owner pointer to take the module's refcount. This approach is problematic since it can lead to a null pointer dereference while attempting to get the manager if the parent device does not have a driver.
To address this problem, add a module owner pointer to the fpga_manager struct and use it to take the module's refcount. Modify the functions for registering the manager to take an additional owner module parameter and rename them to avoid conflicts. Use the old function names for helper macros that automatically set the module that registers the manager as the owner. This ensures compatibility with existing low-level control modules and reduces the chances of registering a manager without setting the owner.
Also, update the documentation to keep it consistent with the new interface for registering an fpga manager.
Other changes: opportunistically move put_device() from __fpga_mgr_get() to fpga_mgr_get() and of_fpga_mgr_get() to improve code clarity since the manager device is taken in these functions.(CVE-2024-37021)
In the Linux kernel, the following vulnerability has been resolved:
i2c: lpi2c: Avoid calling clk_get_rate during transfer
Instead of repeatedly calling clk_get_rate for each transfer, lock the clock rate and cache the value. A deadlock has been observed while adding tlv320aic32x4 audio codec to the system. When this clock provider adds its clock, the clk mutex is locked already, it needs to access i2c, which in return needs the mutex for clk_get_rate as well.(CVE-2024-40965)
In the Linux kernel, the following vulnerability has been resolved:
arm64: probes: Fix uprobes for big-endian kernels
The arm64 uprobes code is broken for big-endian kernels as it doesn't convert the in-memory instruction encoding (which is always little-endian) into the kernel's native endianness before analyzing and simulating instructions. This may result in a few distinct problems:
-
The kernel may may erroneously reject probing an instruction which can safely be probed.
-
The kernel may erroneously erroneously permit stepping an instruction out-of-line when that instruction cannot be stepped out-of-line safely.
-
The kernel may erroneously simulate instruction incorrectly dur to interpretting the byte-swapped encoding.
The endianness mismatch isn't caught by the compiler or sparse because:
-
The arch_uprobe::{insn,ixol} fields are encoded as arrays of u8, so the compiler and sparse have no idea these contain a little-endian 32-bit value. The core uprobes code populates these with a memcpy() which similarly does not handle endianness.
-
While the uprobe_opcode_t type is an alias for __le32, both arch_uprobe_analyze_insn() and arch_uprobe_skip_sstep() cast from u8[] to the similarly-named probe_opcode_t, which is an alias for u32. Hence there is no endianness conversion warning.
Fix this by changing the arch_uprobe::{insn,ixol} fields to __le32 and adding the appropriate __le32_to_cpu() conversions prior to consuming the instruction encoding. The core uprobes copies these fields as opaque ranges of bytes, and so is unaffected by this change.
At the same time, remove MAX_UINSN_BYTES and consistently use AARCH64_INSN_SIZE for clarity.
Tested with the following:
| #include <stdio.h> | #include <stdbool.h> | | #define noinline attribute((noinline)) | | static noinline void adrp_self(void) | { | void addr; | | asm volatile( | " adrp %x0, adrp_self\n" | " add %x0, %x0, :lo12:adrp_self\n" | : "=r" (addr)); | } | | | int main(int argc, char argv) | { | void ptr = adrp_self(); | bool equal = (ptr == adrp_self); | | printf("adrp_self => %p\n" | "adrp_self() => %p\n" | "%s\n", | adrp_self, ptr, equal ? "EQUAL" : "NOT EQUAL"); | | return 0; | }
.... where the adrp_self() function was compiled to:
| 00000000004007e0 <adrp_self>: | 4007e0: 90000000 adrp x0, 400000 <__ehdr_start> | 4007e4: 911f8000 add x0, x0, #0x7e0 | 4007e8: d65f03c0 ret
Before this patch, the ADRP is not recognized, and is assumed to be steppable, resulting in corruption of the result:
| # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL | # echo 'p /root/adrp-self:0x007e0' > /sys/kernel/tracing/uprobe_events | # echo 1 > /sys/kernel/tracing/events/uprobes/enable | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0xffffffffff7e0 | NOT EQUAL
After this patch, the ADRP is correctly recognized and simulated:
| # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL | # | # echo 'p /root/adrp-self:0x007e0' > /sys/kernel/tracing/uprobe_events | # echo 1 > /sys/kernel/tracing/events/uprobes/enable | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL(CVE-2024-50194)
In the Linux kernel, the following vulnerability has been resolved:
dm cache: fix flushing uninitialized delayed_work on cache_ctr error
An unexpected WARN_ON from flush_work() may occur when cache creation fails, caused by destroying the uninitialized delayed_work waker in the error path of cache_create(). For example, the warning appears on the superblock checksum error.
Reproduce steps:
dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" dmsetup create cdata --table "0 65536 linear /dev/sdc 8192" dmsetup create corig --table "0 524288 linear /dev/sdc 262144" dd if=/dev/urandom of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table "0 524288 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0"
Kernel logs:
(snip) WARNING: CPU: 0 PID: 84 at kernel/workqueue.c:4178 __flush_work+0x5d4/0x890
Fix by pulling out the cancel_delayed_work_sync() from the constructor's error path. This patch doesn't affect the use-after-free fix for concurrent dm_resume and dm_destroy (commit 6a459d8edbdb ("dm cache: Fix UAF in destroy()")) as cache_dtr is not changed.(CVE-2024-50280)
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix null-ptr-deref in block_touch_buffer tracepoint
Patch series "nilfs2: fix null-ptr-deref bugs on block tracepoints".
This series fixes null pointer dereference bugs that occur when using nilfs2 and two block-related tracepoints.
This patch (of 2):
It has been reported that when using "block:block_touch_buffer" tracepoint, touch_buffer() called from __nilfs_get_folio_block() causes a NULL pointer dereference, or a general protection fault when KASAN is enabled.
This happens because since the tracepoint was added in touch_buffer(), it references the dev_t member bh->b_bdev->bd_dev regardless of whether the buffer head has a pointer to a block_device structure. In the current implementation, the block_device structure is set after the function returns to the caller.
Here, touch_buffer() is used to mark the folio/page that owns the buffer head as accessed, but the common search helper for folio/page used by the caller function was optimized to mark the folio/page as accessed when it was reimplemented a long time ago, eliminating the need to call touch_buffer() here in the first place.
So this solves the issue by eliminating the touch_buffer() call itself.(CVE-2024-53131)
In the Linux kernel, the following vulnerability has been resolved:
um: net: Do not use drvdata in release
The drvdata is not available in release. Let's just use container_of() to get the uml_net instance. Otherwise, removing a network device will result in a crash:
RIP: 0033:net_device_release+0x10/0x6f RSP: 00000000e20c7c40 EFLAGS: 00010206 RAX: 000000006002e4e7 RBX: 00000000600f1baf RCX: 00000000624074e0 RDX: 0000000062778000 RSI: 0000000060551c80 RDI: 00000000627af028 RBP: 00000000e20c7c50 R08: 00000000603ad594 R09: 00000000e20c7b70 R10: 000000000000135a R11: 00000000603ad422 R12: 0000000000000000 R13: 0000000062c7af00 R14: 0000000062406d60 R15: 00000000627700b6 Kernel panic - not syncing: Segfault with no mm CPU: 0 UID: 0 PID: 29 Comm: kworker/0:2 Not tainted 6.12.0-rc6-g59b723cd2adb #1 Workqueue: events mc_work_proc Stack: 627af028 62c7af00 e20c7c80 60276fcd 62778000 603f5820 627af028 00000000 e20c7cb0 603a2bcd 627af000 62770010 Call Trace: [<60276fcd>] device_release+0x70/0xba [<603a2bcd>] kobject_put+0xba/0xe7 [<60277265>] put_device+0x19/0x1c [<60281266>] platform_device_put+0x26/0x29 [<60281e5f>] platform_device_unregister+0x2c/0x2e [<6002ec9c>] net_remove+0x63/0x69 [<60031316>] ? mconsole_reply+0x0/0x50 [<600310c8>] mconsole_remove+0x160/0x1cc [<60087d40>] ? __remove_hrtimer+0x38/0x74 [<60087ff8>] ? hrtimer_try_to_cancel+0x8c/0x98 [<6006b3cf>] ? dl_server_stop+0x3f/0x48 [<6006b390>] ? dl_server_stop+0x0/0x48 [<600672e8>] ? dequeue_entities+0x327/0x390 [<60038fa6>] ? um_set_signals+0x0/0x43 [<6003070c>] mc_work_proc+0x77/0x91 [<60057664>] process_scheduled_works+0x1b3/0x2dd [<60055f32>] ? assign_work+0x0/0x58 [<60057f0a>] worker_thread+0x1e9/0x293 [<6005406f>] ? set_pf_worker+0x0/0x64 [<6005d65d>] ? arch_local_irq_save+0x0/0x2d [<6005d748>] ? kthread_exit+0x0/0x3a [<60057d21>] ? worker_thread+0x0/0x293 [<6005dbf1>] kthread+0x126/0x12b [<600219c5>] new_thread_handler+0x85/0xb6(CVE-2024-53183)
In the Linux kernel, the following vulnerability has been resolved:
xen: Fix the issue of resource not being properly released in xenbus_dev_probe()
This patch fixes an issue in the function xenbus_dev_probe(). In the xenbus_dev_probe() function, within the if (err) branch at line 313, the program incorrectly returns err directly without releasing the resources allocated by err = drv->probe(dev, id). As the return value is non-zero, the upper layers assume the processing logic has failed. However, the probe operation was performed earlier without a corresponding remove operation. Since the probe actually allocates resources, failing to perform the remove operation could lead to problems.
To fix this issue, we followed the resource release logic of the xenbus_dev_remove() function by adding a new block fail_remove before the fail_put block. After entering the branch if (err) at line 313, the function will use a goto statement to jump to the fail_remove block, ensuring that the previously acquired resources are correctly released, thus preventing the reference count leak.
This bug was identified by an experimental static analysis tool developed by our team. The tool specializes in analyzing reference count operations and detecting potential issues where resources are not properly managed. In this case, the tool flagged the missing release operation as a potential problem, which led to the development of this patch.(CVE-2024-53198)
In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix null check for pipe_ctx->plane_state in dcn20_program_pipeThis commit addresses a null pointer dereference issue indcn20_program_pipe(). Previously, commit 8e4ed3cf1642 ( drm/amd/display:Add null check for pipe_ctx->plane_state in dcn20_program_pipe )partially fixed the null pointer dereference issue. However, indcn20_update_dchubp_dpp(), the variable pipe_ctx is passed in, andplane_state is accessed again through pipe_ctx. Multiple if statementsdirectly call attributes of plane_state, leading to potential nullpointer dereference issues. This patch adds necessary null checks toensure stability.(CVE-2024-53201)
In the Linux kernel, the following vulnerability has been resolved:
wifi: mwifiex: Fix memcpy() field-spanning write warning in mwifiex_config_scan()
Replace one-element array with a flexible-array member in struct
mwifiex_ie_types_wildcard_ssid_params to fix the following warning
on a MT8173 Chromebook (mt8173-elm-hana):
[ 356.775250] ------------[ cut here ]------------ [ 356.784543] memcpy: detected field-spanning write (size 6) of single field "wildcard_ssid_tlv->ssid" at drivers/net/wireless/marvell/mwifiex/scan.c:904 (size 1) [ 356.813403] WARNING: CPU: 3 PID: 742 at drivers/net/wireless/marvell/mwifiex/scan.c:904 mwifiex_scan_networks+0x4fc/0xf28 [mwifiex]
The "(size 6)" above is exactly the length of the SSID of the network this device was connected to. The source of the warning looks like:
ssid_len = user_scan_in->ssid_list[i].ssid_len;
[...]
memcpy(wildcard_ssid_tlv->ssid,
user_scan_in->ssid_list[i].ssid, ssid_len);
There is a #define WILDCARD_SSID_TLV_MAX_SIZE that uses sizeof() on this struct, but it already didn't account for the size of the one-element array, so it doesn't need to be changed.(CVE-2024-56539)
In the Linux kernel, the following vulnerability has been resolved:
media: uvcvideo: Require entities to have a non-zero unique ID
Per UVC 1.1+ specification 3.7.2, units and terminals must have a non-zero unique ID.
Each Unit and Terminal within the video function is assigned a unique
identification number, the Unit ID (UID) or Terminal ID (TID), contained in
the bUnitID or bTerminalID field of the descriptor. The value 0x00 is
reserved for undefined ID,
So, deny allocating an entity with ID 0 or an ID that belongs to a unit that is already added to the list of entities.
This also prevents some syzkaller reproducers from triggering warnings due to a chain of entities referring to themselves. In one particular case, an Output Unit is connected to an Input Unit, both with the same ID of 1. But when looking up for the source ID of the Output Unit, that same entity is found instead of the input entity, which leads to such warnings.
In another case, a backward chain was considered finished as the source ID was 0. Later on, that entity was found, but its pads were not valid.
Here is a sample stack trace for one of those cases.
[ 20.650953] usb 1-1: new high-speed USB device number 2 using dummy_hcd [ 20.830206] usb 1-1: Using ep0 maxpacket: 8 [ 20.833501] usb 1-1: config 0 descriptor?? [ 21.038518] usb 1-1: string descriptor 0 read error: -71 [ 21.038893] usb 1-1: Found UVC 0.00 device <unnamed> (2833:0201) [ 21.039299] uvcvideo 1-1:0.0: Entity type for entity Output 1 was not initialized! [ 21.041583] uvcvideo 1-1:0.0: Entity type for entity Input 1 was not initialized! [ 21.042218] ------------[ cut here ]------------ [ 21.042536] WARNING: CPU: 0 PID: 9 at drivers/media/mc/mc-entity.c:1147 media_create_pad_link+0x2c4/0x2e0 [ 21.043195] Modules linked in: [ 21.043535] CPU: 0 UID: 0 PID: 9 Comm: kworker/0:1 Not tainted 6.11.0-rc7-00030-g3480e43aeccf #444 [ 21.044101] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 [ 21.044639] Workqueue: usb_hub_wq hub_event [ 21.045100] RIP: 0010:media_create_pad_link+0x2c4/0x2e0 [ 21.045508] Code: fe e8 20 01 00 00 b8 f4 ff ff ff 48 83 c4 30 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 0f 0b eb e9 0f 0b eb 0a 0f 0b eb 06 <0f> 0b eb 02 0f 0b b8 ea ff ff ff eb d4 66 2e 0f 1f 84 00 00 00 00 [ 21.046801] RSP: 0018:ffffc9000004b318 EFLAGS: 00010246 [ 21.047227] RAX: ffff888004e5d458 RBX: 0000000000000000 RCX: ffffffff818fccf1 [ 21.047719] RDX: 000000000000007b RSI: 0000000000000000 RDI: ffff888004313290 [ 21.048241] RBP: ffff888004313290 R08: 0001ffffffffffff R09: 0000000000000000 [ 21.048701] R10: 0000000000000013 R11: 0001888004313290 R12: 0000000000000003 [ 21.049138] R13: ffff888004313080 R14: ffff888004313080 R15: 0000000000000000 [ 21.049648] FS: 0000000000000000(0000) GS:ffff88803ec00000(0000) knlGS:0000000000000000 [ 21.050271] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 21.050688] CR2: 0000592cc27635b0 CR3: 000000000431c000 CR4: 0000000000750ef0 [ 21.051136] PKRU: 55555554 [ 21.051331] Call Trace: [ 21.051480] <TASK> [ 21.051611] ? __warn+0xc4/0x210 [ 21.051861] ? media_create_pad_link+0x2c4/0x2e0 [ 21.052252] ? report_bug+0x11b/0x1a0 [ 21.052540] ? trace_hardirqs_on+0x31/0x40 [ 21.052901] ? handle_bug+0x3d/0x70 [ 21.053197] ? exc_invalid_op+0x1a/0x50 [ 21.053511] ? asm_exc_invalid_op+0x1a/0x20 [ 21.053924] ? media_create_pad_link+0x91/0x2e0 [ 21.054364] ? media_create_pad_link+0x2c4/0x2e0 [ 21.054834] ? media_create_pad_link+0x91/0x2e0 [ 21.055131] ? _raw_spin_unlock+0x1e/0x40 [ 21.055441] ? __v4l2_device_register_subdev+0x202/0x210 [ 21.055837] uvc_mc_register_entities+0x358/0x400 [ 21.056144] uvc_register_chains+0x1fd/0x290 [ 21.056413] uvc_probe+0x380e/0x3dc0 [ 21.056676] ? __lock_acquire+0x5aa/0x26e0 [ 21.056946] ? find_held_lock+0x33/0xa0 [ 21.057196] ? kernfs_activate+0x70/0x80 [ 21.057533] ? usb_match_dy ---truncated---(CVE-2024-56571)
In the Linux kernel, the following vulnerability has been resolved:
scsi: hisi_sas: Create all dump files during debugfs initialization
For the current debugfs of hisi_sas, after user triggers dump, the driver allocate memory space to save the register information and create debugfs files to display the saved information. In this process, the debugfs files created after each dump.
Therefore, when the dump is triggered while the driver is unbind, the following hang occurs:
[67840.853907] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a0 [67840.862947] Mem abort info: [67840.865855] ESR = 0x0000000096000004 [67840.869713] EC = 0x25: DABT (current EL), IL = 32 bits [67840.875125] SET = 0, FnV = 0 [67840.878291] EA = 0, S1PTW = 0 [67840.881545] FSC = 0x04: level 0 translation fault [67840.886528] Data abort info: [67840.889524] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [67840.895117] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [67840.900284] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [67840.905709] user pgtable: 4k pages, 48-bit VAs, pgdp=0000002803a1f000 [67840.912263] [00000000000000a0] pgd=0000000000000000, p4d=0000000000000000 [67840.919177] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [67840.996435] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [67841.003628] pc : down_write+0x30/0x98 [67841.007546] lr : start_creating.part.0+0x60/0x198 [67841.012495] sp : ffff8000b979ba20 [67841.016046] x29: ffff8000b979ba20 x28: 0000000000000010 x27: 0000000000024b40 [67841.023412] x26: 0000000000000012 x25: ffff20202b355ae8 x24: ffff20202b35a8c8 [67841.030779] x23: ffffa36877928208 x22: ffffa368b4972240 x21: ffff8000b979bb18 [67841.038147] x20: ffff00281dc1e3c0 x19: fffffffffffffffe x18: 0000000000000020 [67841.045515] x17: 0000000000000000 x16: ffffa368b128a530 x15: ffffffffffffffff [67841.052888] x14: ffff8000b979bc18 x13: ffffffffffffffff x12: ffff8000b979bb18 [67841.060263] x11: 0000000000000000 x10: 0000000000000000 x9 : ffffa368b1289b18 [67841.067640] x8 : 0000000000000012 x7 : 0000000000000000 x6 : 00000000000003a9 [67841.075014] x5 : 0000000000000000 x4 : ffff002818c5cb00 x3 : 0000000000000001 [67841.082388] x2 : 0000000000000000 x1 : ffff002818c5cb00 x0 : 00000000000000a0 [67841.089759] Call trace: [67841.092456] down_write+0x30/0x98 [67841.096017] start_creating.part.0+0x60/0x198 [67841.100613] debugfs_create_dir+0x48/0x1f8 [67841.104950] debugfs_create_files_v3_hw+0x88/0x348 [hisi_sas_v3_hw] [67841.111447] debugfs_snapshot_regs_v3_hw+0x708/0x798 [hisi_sas_v3_hw] [67841.118111] debugfs_trigger_dump_v3_hw_write+0x9c/0x120 [hisi_sas_v3_hw] [67841.125115] full_proxy_write+0x68/0xc8 [67841.129175] vfs_write+0xd8/0x3f0 [67841.132708] ksys_write+0x70/0x108 [67841.136317] __arm64_sys_write+0x24/0x38 [67841.140440] invoke_syscall+0x50/0x128 [67841.144385] el0_svc_common.constprop.0+0xc8/0xf0 [67841.149273] do_el0_svc+0x24/0x38 [67841.152773] el0_svc+0x38/0xd8 [67841.156009] el0t_64_sync_handler+0xc0/0xc8 [67841.160361] el0t_64_sync+0x1a4/0x1a8 [67841.164189] Code: b9000882 d2800002 d2800023 f9800011 (c85ffc05) [67841.170443] ---[ end trace 0000000000000000 ]---
To fix this issue, create all directories and files during debugfs initialization. In this way, the driver only needs to allocate memory space to save information each time the user triggers dumping.(CVE-2024-56588)
In the Linux kernel, the following vulnerability has been resolved:
kcsan: Turn report_filterlist_lock into a raw_spinlock
Ran Xiaokai reports that with a KCSAN-enabled PREEMPT_RT kernel, we can see splats like:
| BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 | in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/1 | preempt_count: 10002, expected: 0 | RCU nest depth: 0, expected: 0 | no locks held by swapper/1/0. | irq event stamp: 156674 | hardirqs last enabled at (156673): [<ffffffff81130bd9>] do_idle+0x1f9/0x240 | hardirqs last disabled at (156674): [<ffffffff82254f84>] sysvec_apic_timer_interrupt+0x14/0xc0 | softirqs last enabled at (0): [<ffffffff81099f47>] copy_process+0xfc7/0x4b60 | softirqs last disabled at (0): [<0000000000000000>] 0x0 | Preemption disabled at: | [<ffffffff814a3e2a>] paint_ptr+0x2a/0x90 | CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Not tainted 6.11.0+ #3 | Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-0-ga698c8995f-prebuilt.qemu.org 04/01/2014 | Call Trace: | <IRQ> | dump_stack_lvl+0x7e/0xc0 | dump_stack+0x1d/0x30 | __might_resched+0x1a2/0x270 | rt_spin_lock+0x68/0x170 | kcsan_skip_report_debugfs+0x43/0xe0 | print_report+0xb5/0x590 | kcsan_report_known_origin+0x1b1/0x1d0 | kcsan_setup_watchpoint+0x348/0x650 | __tsan_unaligned_write1+0x16d/0x1d0 | hrtimer_interrupt+0x3d6/0x430 | __sysvec_apic_timer_interrupt+0xe8/0x3a0 | sysvec_apic_timer_interrupt+0x97/0xc0 | </IRQ>
On a detected data race, KCSAN's reporting logic checks if it should filter the report. That list is protected by the report_filterlist_lock non-raw spinlock which may sleep on RT kernels.
Since KCSAN may report data races in any context, convert it to a raw_spinlock.
This requires being careful about when to allocate memory for the filter list itself which can be done via KCSAN's debugfs interface. Concurrent modification of the filter list via debugfs should be rare: the chosen strategy is to optimistically pre-allocate memory before the critical section and discard if unused.(CVE-2024-56610)
In the Linux kernel, the following vulnerability has been resolved:
mm/mempolicy: fix migrate_to_node() assuming there is at least one VMA in a MM
We currently assume that there is at least one VMA in a MM, which isn't true.
So we might end up having find_vma() return NULL, to then de-reference NULL. So properly handle find_vma() returning NULL.
This fixes the report:
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: 1 UID: 0 PID: 6021 Comm: syz-executor284 Not tainted 6.12.0-rc7-syzkaller-00187-gf868cd251776 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024 RIP: 0010:migrate_to_node mm/mempolicy.c:1090 [inline] RIP: 0010:do_migrate_pages+0x403/0x6f0 mm/mempolicy.c:1194 Code: ... RSP: 0018:ffffc9000375fd08 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffffc9000375fd78 RCX: 0000000000000000 RDX: ffff88807e171300 RSI: dffffc0000000000 RDI: ffff88803390c044 RBP: ffff88807e171428 R08: 0000000000000014 R09: fffffbfff2039ef1 R10: ffffffff901cf78f R11: 0000000000000000 R12: 0000000000000003 R13: ffffc9000375fe90 R14: ffffc9000375fe98 R15: ffffc9000375fdf8 FS: 00005555919e1380(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005555919e1ca8 CR3: 000000007f12a000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> kernel_migrate_pages+0x5b2/0x750 mm/mempolicy.c:1709 __do_sys_migrate_pages mm/mempolicy.c:1727 [inline] __se_sys_migrate_pages mm/mempolicy.c:1723 [inline] __x64_sys_migrate_pages+0x96/0x100 mm/mempolicy.c:1723 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f
akpm@linux-foundation.org: add unlikely()
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Fix use after free on unload
System crash is observed with stack trace warning of use after free. There are 2 signals to tell dpc_thread to terminate (UNLOADING flag and kthread_stop).
On setting the UNLOADING flag when dpc_thread happens to run at the time and sees the flag, this causes dpc_thread to exit and clean up itself. When kthread_stop is called for final cleanup, this causes use after free.
Remove UNLOADING signal to terminate dpc_thread. Use the kthread_stop as the main signal to exit dpc_thread.
[596663.812935] kernel BUG at mm/slub.c:294! [596663.812950] invalid opcode: 0000 [#1] SMP PTI [596663.812957] CPU: 13 PID: 1475935 Comm: rmmod Kdump: loaded Tainted: G IOE --------- - - 4.18.0-240.el8.x86_64 #1 [596663.812960] Hardware name: HP ProLiant DL380p Gen8, BIOS P70 08/20/2012 [596663.812974] RIP: 0010:__slab_free+0x17d/0x360
... [596663.813008] Call Trace: [596663.813022] ? __dentry_kill+0x121/0x170 [596663.813030] ? _cond_resched+0x15/0x30 [596663.813034] ? _cond_resched+0x15/0x30 [596663.813039] ? wait_for_completion+0x35/0x190 [596663.813048] ? try_to_wake_up+0x63/0x540 [596663.813055] free_task+0x5a/0x60 [596663.813061] kthread_stop+0xf3/0x100 [596663.813103] qla2x00_remove_one+0x284/0x440 qla2xxx
In the Linux kernel, the following vulnerability has been resolved:
sunrpc: clear XPRT_SOCK_UPD_TIMEOUT when reset transport
Since transport->sock has been set to NULL during reset transport, XPRT_SOCK_UPD_TIMEOUT also needs to be cleared. Otherwise, the xs_tcp_set_socket_timeouts() may be triggered in xs_tcp_send_request() to dereference the transport->sock that has been set to NULL.(CVE-2024-56688)
In the Linux kernel, the following vulnerability has been resolved:
9p/xen: fix release of IRQ
Kernel logs indicate an IRQ was double-freed.
Pass correct device ID during IRQ release.
Dominique: remove confusing variable reset to 0
In the Linux kernel, the following vulnerability has been resolved:
ionic: Fix netdev notifier unregister on failure
If register_netdev() fails, then the driver leaks the netdev notifier. Fix this by calling ionic_lif_unregister() on register_netdev() failure. This will also call ionic_lif_unregister_phc() if it has already been registered.(CVE-2024-56715)
In the Linux kernel, the following vulnerability has been resolved:
fbdev: sh7760fb: Fix a possible memory leak in sh7760fb_alloc_mem()
When information such as info->screen_base is not ready, calling sh7760fb_free_mem() does not release memory correctly. Call dma_free_coherent() instead.(CVE-2024-56746)
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: fix slab-use-after-free due to dangling pointer dqi_priv
When mounting ocfs2 and then remounting it as read-only, a slab-use-after-free occurs after the user uses a syscall to quota_getnextquota. Specifically, sb_dqinfo(sb, type)->dqi_priv is the dangling pointer.
During the remounting process, the pointer dqi_priv is freed but is never set as null leaving it to be accessed. Additionally, the read-only option for remounting sets the DQUOT_SUSPENDED flag instead of setting the DQUOT_USAGE_ENABLED flags. Moreover, later in the process of getting the next quota, the function ocfs2_get_next_id is called and only checks the quota usage flags and not the quota suspended flags.
To fix this, I set dqi_priv to null when it is freed after remounting with read-only and put a check for DQUOT_SUSPENDED in ocfs2_get_next_id.
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-5.10.0-248.0.0.147.oe2203sp4.aarch64.rpm",
"bpftool-debuginfo-5.10.0-248.0.0.147.oe2203sp4.aarch64.rpm",
"kernel-5.10.0-248.0.0.147.oe2203sp4.aarch64.rpm",
"kernel-debuginfo-5.10.0-248.0.0.147.oe2203sp4.aarch64.rpm",
"kernel-debugsource-5.10.0-248.0.0.147.oe2203sp4.aarch64.rpm",
"kernel-devel-5.10.0-248.0.0.147.oe2203sp4.aarch64.rpm",
"kernel-headers-5.10.0-248.0.0.147.oe2203sp4.aarch64.rpm",
"kernel-source-5.10.0-248.0.0.147.oe2203sp4.aarch64.rpm",
"kernel-tools-5.10.0-248.0.0.147.oe2203sp4.aarch64.rpm",
"kernel-tools-debuginfo-5.10.0-248.0.0.147.oe2203sp4.aarch64.rpm",
"kernel-tools-devel-5.10.0-248.0.0.147.oe2203sp4.aarch64.rpm",
"perf-5.10.0-248.0.0.147.oe2203sp4.aarch64.rpm",
"perf-debuginfo-5.10.0-248.0.0.147.oe2203sp4.aarch64.rpm",
"python3-perf-5.10.0-248.0.0.147.oe2203sp4.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-248.0.0.147.oe2203sp4.aarch64.rpm"
],
"src": [
"kernel-5.10.0-248.0.0.147.oe2203sp4.src.rpm"
],
"x86_64": [
"bpftool-5.10.0-248.0.0.147.oe2203sp4.x86_64.rpm",
"bpftool-debuginfo-5.10.0-248.0.0.147.oe2203sp4.x86_64.rpm",
"kernel-5.10.0-248.0.0.147.oe2203sp4.x86_64.rpm",
"kernel-debuginfo-5.10.0-248.0.0.147.oe2203sp4.x86_64.rpm",
"kernel-debugsource-5.10.0-248.0.0.147.oe2203sp4.x86_64.rpm",
"kernel-devel-5.10.0-248.0.0.147.oe2203sp4.x86_64.rpm",
"kernel-headers-5.10.0-248.0.0.147.oe2203sp4.x86_64.rpm",
"kernel-source-5.10.0-248.0.0.147.oe2203sp4.x86_64.rpm",
"kernel-tools-5.10.0-248.0.0.147.oe2203sp4.x86_64.rpm",
"kernel-tools-debuginfo-5.10.0-248.0.0.147.oe2203sp4.x86_64.rpm",
"kernel-tools-devel-5.10.0-248.0.0.147.oe2203sp4.x86_64.rpm",
"perf-5.10.0-248.0.0.147.oe2203sp4.x86_64.rpm",
"perf-debuginfo-5.10.0-248.0.0.147.oe2203sp4.x86_64.rpm",
"python3-perf-5.10.0-248.0.0.147.oe2203sp4.x86_64.rpm",
"python3-perf-debuginfo-5.10.0-248.0.0.147.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-248.0.0.147.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\nsmb: client: fix potential OOBs in smb2_parse_contexts()\n\nValidate offsets and lengths before dereferencing create contexts in\nsmb2_parse_contexts().\n\nThis fixes following oops when accessing invalid create contexts from\nserver:\n\n BUG: unable to handle page fault for address: ffff8881178d8cc3\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\n PGD 4a01067 P4D 4a01067 PUD 0\n Oops: 0000 [#1] PREEMPT SMP NOPTI\n CPU: 3 PID: 1736 Comm: mount.cifs Not tainted 6.7.0-rc4 #1\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS\n rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014\n RIP: 0010:smb2_parse_contexts+0xa0/0x3a0 [cifs]\n Code: f8 10 75 13 48 b8 93 ad 25 50 9c b4 11 e7 49 39 06 0f 84 d2 00\n 00 00 8b 45 00 85 c0 74 61 41 29 c5 48 01 c5 41 83 fd 0f 76 55 \u0026lt;0f\u0026gt; b7\n 7d 04 0f b7 45 06 4c 8d 74 3d 00 66 83 f8 04 75 bc ba 04 00\n RSP: 0018:ffffc900007939e0 EFLAGS: 00010216\n RAX: ffffc90000793c78 RBX: ffff8880180cc000 RCX: ffffc90000793c90\n RDX: ffffc90000793cc0 RSI: ffff8880178d8cc0 RDI: ffff8880180cc000\n RBP: ffff8881178d8cbf R08: ffffc90000793c22 R09: 0000000000000000\n R10: ffff8880180cc000 R11: 0000000000000024 R12: 0000000000000000\n R13: 0000000000000020 R14: 0000000000000000 R15: ffffc90000793c22\n FS: 00007f873753cbc0(0000) GS:ffff88806bc00000(0000)\n knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: ffff8881178d8cc3 CR3: 00000000181ca000 CR4: 0000000000750ef0\n PKRU: 55555554\n Call Trace:\n \u0026lt;TASK\u0026gt;\n ? __die+0x23/0x70\n ? page_fault_oops+0x181/0x480\n ? search_module_extables+0x19/0x60\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? exc_page_fault+0x1b6/0x1c0\n ? asm_exc_page_fault+0x26/0x30\n ? smb2_parse_contexts+0xa0/0x3a0 [cifs]\n SMB2_open+0x38d/0x5f0 [cifs]\n ? smb2_is_path_accessible+0x138/0x260 [cifs]\n smb2_is_path_accessible+0x138/0x260 [cifs]\n cifs_is_path_remote+0x8d/0x230 [cifs]\n cifs_mount+0x7e/0x350 [cifs]\n cifs_smb3_do_mount+0x128/0x780 [cifs]\n smb3_get_tree+0xd9/0x290 [cifs]\n vfs_get_tree+0x2c/0x100\n ? capable+0x37/0x70\n path_mount+0x2d7/0xb80\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? _raw_spin_unlock_irqrestore+0x44/0x60\n __x64_sys_mount+0x11a/0x150\n do_syscall_64+0x47/0xf0\n entry_SYSCALL_64_after_hwframe+0x6f/0x77\n RIP: 0033:0x7f8737657b1e(CVE-2023-52434)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix race condition between session lookup and expire\n\n Thread A + Thread B\n ksmbd_session_lookup | smb2_sess_setup\n sess = xa_load |\n |\n | xa_erase(\u0026amp;conn-\u0026gt;sessions, sess-\u0026gt;id);\n |\n | ksmbd_session_destroy(sess) --\u0026gt; kfree(sess)\n |\n // UAF! |\n sess-\u0026gt;last_active = jiffies |\n +\n\nThis patch add rwsem to fix race condition between ksmbd_session_lookup\nand ksmbd_expire_session.(CVE-2023-52480)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nPM / devfreq: Fix buffer overflow in trans_stat_show\n\nFix buffer overflow in trans_stat_show().\n\nConvert simple snprintf to the more secure scnprintf with size of\nPAGE_SIZE.\n\nAdd condition checking if we are exceeding PAGE_SIZE and exit early from\nloop. Also add at the end a warning that we exceeded PAGE_SIZE and that\nstats is disabled.\n\nReturn -EFBIG in the case where we don\u0026apos;t have enough space to write the\nfull transition table.\n\nAlso document in the ABI that this function can return -EFBIG error.(CVE-2023-52614)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niio: adc: ad7091r: Allow users to configure device events\n\nAD7091R-5 devices are supported by the ad7091r-5 driver together with\nthe ad7091r-base driver. Those drivers declared iio events for notifying\nuser space when ADC readings fall bellow the thresholds of low limit\nregisters or above the values set in high limit registers.\nHowever, to configure iio events and their thresholds, a set of callback\nfunctions must be implemented and those were not present until now.\nThe consequence of trying to configure ad7091r-5 events without the\nproper callback functions was a null pointer dereference in the kernel\nbecause the pointers to the callback functions were not set.\n\nImplement event configuration callbacks allowing users to read/write\nevent thresholds and enable/disable event generation.\n\nSince the event spec structs are generic to AD7091R devices, also move\nthose from the ad7091r-5 driver the base driver so they can be reused\nwhen support for ad7091r-2/-4/-8 be added.(CVE-2023-52627)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/i915: Fix potential context UAFs\n\ngem_context_register() makes the context visible to userspace, and which\npoint a separate thread can trigger the I915_GEM_CONTEXT_DESTROY ioctl.\nSo we need to ensure that nothing uses the ctx ptr after this. And we\nneed to ensure that adding the ctx to the xarray is the *last* thing\nthat gem_context_register() does with the ctx pointer.\n\n[tursulin: Stable and fixes tags add/tidy.]\n(cherry picked from commit bed4b455cf5374e68879be56971c1da563bcd90c)(CVE-2023-52913)\n\nA race condition was found in the Linux kernel\u0026apos;s net/bluetooth device driver in conn_info_{min,max}_age_set() function. This can result in integrity overflow issue, possibly leading to bluetooth connection abnormality or denial of service.\n\n\n\n\n(CVE-2024-24857)\n\nA race condition was found in the Linux kernel\u0026apos;s net/bluetooth in sniff_{min,max}_interval_set() function. This can result in a bluetooth sniffing exception issue, possibly leading denial of service.\n\n\n\n\n\n\n\n(CVE-2024-24859)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxhci: handle isoc Babble and Buffer Overrun events properly\n\nxHCI 4.9 explicitly forbids assuming that the xHC has released its\nownership of a multi-TRB TD when it reports an error on one of the\nearly TRBs. Yet the driver makes such assumption and releases the TD,\nallowing the remaining TRBs to be freed or overwritten by new TDs.\n\nThe xHC should also report completion of the final TRB due to its IOC\nflag being set by us, regardless of prior errors. This event cannot\nbe recognized if the TD has already been freed earlier, resulting in\n\u0026quot;Transfer event TRB DMA ptr not part of current TD\u0026quot; error message.\n\nFix this by reusing the logic for processing isoc Transaction Errors.\nThis also handles hosts which fail to report the final completion.\n\nFix transfer length reporting on Babble errors. They may be caused by\ndevice malfunction, no guarantee that the buffer has been filled.(CVE-2024-26659)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nhwmon: (coretemp) Fix out-of-bounds memory access\n\nFix a bug that pdata-\u0026gt;cpu_map[] is set before out-of-bounds check.\nThe problem might be triggered on systems with more than 128 cores per\npackage.(CVE-2024-26664)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nft_ct: sanitize layer 3 and 4 protocol number in custom expectations\n\n- Disallow families other than NFPROTO_{IPV4,IPV6,INET}.\n- Disallow layer 4 protocol with no ports, since destination port is a\n mandatory attribute for this object.(CVE-2024-26673)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: roles: fix NULL pointer issue when put module\u0026apos;s reference\n\nIn current design, usb role class driver will get usb_role_switch parent\u0026apos;s\nmodule reference after the user get usb_role_switch device and put the\nreference after the user put the usb_role_switch device. However, the\nparent device of usb_role_switch may be removed before the user put the\nusb_role_switch. If so, then, NULL pointer issue will be met when the user\nput the parent module\u0026apos;s reference.\n\nThis will save the module pointer in structure of usb_role_switch. Then,\nwe don\u0026apos;t need to find module by iterating long relations.(CVE-2024-26747)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: cdns3: fix memory double free when handle zero packet\n\n829 if (request-\u0026gt;complete) {\n830 spin_unlock(\u0026amp;priv_dev-\u0026gt;lock);\n831 usb_gadget_giveback_request(\u0026amp;priv_ep-\u0026gt;endpoint,\n832 request);\n833 spin_lock(\u0026amp;priv_dev-\u0026gt;lock);\n834 }\n835\n836 if (request-\u0026gt;buf == priv_dev-\u0026gt;zlp_buf)\n837 cdns3_gadget_ep_free_request(\u0026amp;priv_ep-\u0026gt;endpoint, request);\n\nDriver append an additional zero packet request when queue a packet, which\nlength mod max packet size is 0. When transfer complete, run to line 831,\nusb_gadget_giveback_request() will free this requestion. 836 condition is\ntrue, so cdns3_gadget_ep_free_request() free this request again.\n\nLog:\n\n[ 1920.140696][ T150] BUG: KFENCE: use-after-free read in cdns3_gadget_giveback+0x134/0x2c0 [cdns3]\n[ 1920.140696][ T150]\n[ 1920.151837][ T150] Use-after-free read at 0x000000003d1cd10b (in kfence-#36):\n[ 1920.159082][ T150] cdns3_gadget_giveback+0x134/0x2c0 [cdns3]\n[ 1920.164988][ T150] cdns3_transfer_completed+0x438/0x5f8 [cdns3]\n\nAdd check at line 829, skip call usb_gadget_giveback_request() if it is\nadditional zero length packet request. Needn\u0026apos;t call\nusb_gadget_giveback_request() because it is allocated in this driver.(CVE-2024-26748)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: cdns3: fixed memory use after free at cdns3_gadget_ep_disable()\n\n ...\n cdns3_gadget_ep_free_request(\u0026amp;priv_ep-\u0026gt;endpoint, \u0026amp;priv_req-\u0026gt;request);\n list_del_init(\u0026amp;priv_req-\u0026gt;list);\n ...\n\n\u0026apos;priv_req\u0026apos; actually free at cdns3_gadget_ep_free_request(). But\nlist_del_init() use priv_req-\u0026gt;list after it.\n\n[ 1542.642868][ T534] BUG: KFENCE: use-after-free read in __list_del_entry_valid+0x10/0xd4\n[ 1542.642868][ T534]\n[ 1542.653162][ T534] Use-after-free read at 0x000000009ed0ba99 (in kfence-#3):\n[ 1542.660311][ T534] __list_del_entry_valid+0x10/0xd4\n[ 1542.665375][ T534] cdns3_gadget_ep_disable+0x1f8/0x388 [cdns3]\n[ 1542.671571][ T534] usb_ep_disable+0x44/0xe4\n[ 1542.675948][ T534] ffs_func_eps_disable+0x64/0xc8\n[ 1542.680839][ T534] ffs_func_set_alt+0x74/0x368\n[ 1542.685478][ T534] ffs_func_disable+0x18/0x28\n\nMove list_del_init() before cdns3_gadget_ep_free_request() to resolve this\nproblem.(CVE-2024-26749)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: virtio/akcipher - Fix stack overflow on memcpy\n\nsizeof(struct virtio_crypto_akcipher_session_para) is less than\nsizeof(struct virtio_crypto_op_ctrl_req::u), copying more bytes from\nstack variable leads stack overflow. Clang reports this issue by\ncommands:\nmake -j CC=clang-14 mrproper \u0026gt;/dev/null 2\u0026gt;\u0026amp;1\nmake -j O=/tmp/crypto-build CC=clang-14 allmodconfig \u0026gt;/dev/null 2\u0026gt;\u0026amp;1\nmake -j O=/tmp/crypto-build W=1 CC=clang-14 drivers/crypto/virtio/\n virtio_crypto_akcipher_algs.o(CVE-2024-26753)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: fix possible deadlock in subflow diag\n\nSyzbot and Eric reported a lockdep splat in the subflow diag:\n\n WARNING: possible circular locking dependency detected\n 6.8.0-rc4-syzkaller-00212-g40b9385dd8e6 #0 Not tainted\n\n syz-executor.2/24141 is trying to acquire lock:\n ffff888045870130 (k-sk_lock-AF_INET6){+.+.}-{0:0}, at:\n tcp_diag_put_ulp net/ipv4/tcp_diag.c:100 [inline]\n ffff888045870130 (k-sk_lock-AF_INET6){+.+.}-{0:0}, at:\n tcp_diag_get_aux+0x738/0x830 net/ipv4/tcp_diag.c:137\n\n but task is already holding lock:\n ffffc9000135e488 (\u0026amp;h-\u0026gt;lhash2[i].lock){+.+.}-{2:2}, at: spin_lock\n include/linux/spinlock.h:351 [inline]\n ffffc9000135e488 (\u0026amp;h-\u0026gt;lhash2[i].lock){+.+.}-{2:2}, at:\n inet_diag_dump_icsk+0x39f/0x1f80 net/ipv4/inet_diag.c:1038\n\n which lock already depends on the new lock.\n\n the existing dependency chain (in reverse order) is:\n\n -\u0026gt; #1 (\u0026amp;h-\u0026gt;lhash2[i].lock){+.+.}-{2:2}:\n lock_acquire+0x1e3/0x530 kernel/locking/lockdep.c:5754\n __raw_spin_lock include/linux/spinlock_api_smp.h:133 [inline]\n _raw_spin_lock+0x2e/0x40 kernel/locking/spinlock.c:154\n spin_lock include/linux/spinlock.h:351 [inline]\n __inet_hash+0x335/0xbe0 net/ipv4/inet_hashtables.c:743\n inet_csk_listen_start+0x23a/0x320 net/ipv4/inet_connection_sock.c:1261\n __inet_listen_sk+0x2a2/0x770 net/ipv4/af_inet.c:217\n inet_listen+0xa3/0x110 net/ipv4/af_inet.c:239\n rds_tcp_listen_init+0x3fd/0x5a0 net/rds/tcp_listen.c:316\n rds_tcp_init_net+0x141/0x320 net/rds/tcp.c:577\n ops_init+0x352/0x610 net/core/net_namespace.c:136\n __register_pernet_operations net/core/net_namespace.c:1214 [inline]\n register_pernet_operations+0x2cb/0x660 net/core/net_namespace.c:1283\n register_pernet_device+0x33/0x80 net/core/net_namespace.c:1370\n rds_tcp_init+0x62/0xd0 net/rds/tcp.c:735\n do_one_initcall+0x238/0x830 init/main.c:1236\n do_initcall_level+0x157/0x210 init/main.c:1298\n do_initcalls+0x3f/0x80 init/main.c:1314\n kernel_init_freeable+0x42f/0x5d0 init/main.c:1551\n kernel_init+0x1d/0x2a0 init/main.c:1441\n ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147\n ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:242\n\n -\u0026gt; #0 (k-sk_lock-AF_INET6){+.+.}-{0:0}:\n check_prev_add kernel/locking/lockdep.c:3134 [inline]\n check_prevs_add kernel/locking/lockdep.c:3253 [inline]\n validate_chain+0x18ca/0x58e0 kernel/locking/lockdep.c:3869\n __lock_acquire+0x1345/0x1fd0 kernel/locking/lockdep.c:5137\n lock_acquire+0x1e3/0x530 kernel/locking/lockdep.c:5754\n lock_sock_fast include/net/sock.h:1723 [inline]\n subflow_get_info+0x166/0xd20 net/mptcp/diag.c:28\n tcp_diag_put_ulp net/ipv4/tcp_diag.c:100 [inline]\n tcp_diag_get_aux+0x738/0x830 net/ipv4/tcp_diag.c:137\n inet_sk_diag_fill+0x10ed/0x1e00 net/ipv4/inet_diag.c:345\n inet_diag_dump_icsk+0x55b/0x1f80 net/ipv4/inet_diag.c:1061\n __inet_diag_dump+0x211/0x3a0 net/ipv4/inet_diag.c:1263\n inet_diag_dump_compat+0x1c1/0x2d0 net/ipv4/inet_diag.c:1371\n netlink_dump+0x59b/0xc80 net/netlink/af_netlink.c:2264\n __netlink_dump_start+0x5df/0x790 net/netlink/af_netlink.c:2370\n netlink_dump_start include/linux/netlink.h:338 [inline]\n inet_diag_rcv_msg_compat+0x209/0x4c0 net/ipv4/inet_diag.c:1405\n sock_diag_rcv_msg+0xe7/0x410\n netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2543\n sock_diag_rcv+0x2a/0x40 net/core/sock_diag.c:280\n netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline]\n netlink_unicast+0x7ea/0x980 net/netlink/af_netlink.c:1367\n netlink_sendmsg+0xa3b/0xd70 net/netlink/af_netlink.c:1908\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg+0x221/0x270 net/socket.c:745\n ____sys_sendmsg+0x525/0x7d0 net/socket.c:2584\n ___sys_sendmsg net/socket.c:2638 [inline]\n __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667\n do_syscall_64+0xf9/0x240\n entry_SYSCALL_64_after_hwframe+0x6f/0x77\n\nAs noted by Eric we can break the lock dependency chain avoid\ndumping \n---truncated---(CVE-2024-26781)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: fsl-qdma: fix SoC may hang on 16 byte unaligned read\n\nThere is chip (ls1028a) errata:\n\nThe SoC may hang on 16 byte unaligned read transactions by QDMA.\n\nUnaligned read transactions initiated by QDMA may stall in the NOC\n(Network On-Chip), causing a deadlock condition. Stalled transactions will\ntrigger completion timeouts in PCIe controller.\n\nWorkaround:\nEnable prefetch by setting the source descriptor prefetchable bit\n( SD[PF] = 1 ).\n\nImplement this workaround.(CVE-2024-26790)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ngtp: fix use-after-free and null-ptr-deref in gtp_newlink()\n\nThe gtp_link_ops operations structure for the subsystem must be\nregistered after registering the gtp_net_ops pernet operations structure.\n\nSyzkaller hit \u0026apos;general protection fault in gtp_genl_dump_pdp\u0026apos; bug:\n\n[ 1010.702740] gtp: GTP module unloaded\n[ 1010.715877] general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] SMP KASAN NOPTI\n[ 1010.715888] KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]\n[ 1010.715895] CPU: 1 PID: 128616 Comm: a.out Not tainted 6.8.0-rc6-std-def-alt1 #1\n[ 1010.715899] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-alt1 04/01/2014\n[ 1010.715908] RIP: 0010:gtp_newlink+0x4d7/0x9c0 [gtp]\n[ 1010.715915] Code: 80 3c 02 00 0f 85 41 04 00 00 48 8b bb d8 05 00 00 e8 ed f6 ff ff 48 89 c2 48 89 c5 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 \u0026lt;80\u0026gt; 3c 02 00 0f 85 4f 04 00 00 4c 89 e2 4c 8b 6d 00 48 b8 00 00 00\n[ 1010.715920] RSP: 0018:ffff888020fbf180 EFLAGS: 00010203\n[ 1010.715929] RAX: dffffc0000000000 RBX: ffff88800399c000 RCX: 0000000000000000\n[ 1010.715933] RDX: 0000000000000001 RSI: ffffffff84805280 RDI: 0000000000000282\n[ 1010.715938] RBP: 000000000000000d R08: 0000000000000001 R09: 0000000000000000\n[ 1010.715942] R10: 0000000000000001 R11: 0000000000000001 R12: ffff88800399cc80\n[ 1010.715947] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000400\n[ 1010.715953] FS: 00007fd1509ab5c0(0000) GS:ffff88805b300000(0000) knlGS:0000000000000000\n[ 1010.715958] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 1010.715962] CR2: 0000000000000000 CR3: 000000001c07a000 CR4: 0000000000750ee0\n[ 1010.715968] PKRU: 55555554\n[ 1010.715972] Call Trace:\n[ 1010.715985] ? __die_body.cold+0x1a/0x1f\n[ 1010.715995] ? die_addr+0x43/0x70\n[ 1010.716002] ? exc_general_protection+0x199/0x2f0\n[ 1010.716016] ? asm_exc_general_protection+0x1e/0x30\n[ 1010.716026] ? gtp_newlink+0x4d7/0x9c0 [gtp]\n[ 1010.716034] ? gtp_net_exit+0x150/0x150 [gtp]\n[ 1010.716042] __rtnl_newlink+0x1063/0x1700\n[ 1010.716051] ? rtnl_setlink+0x3c0/0x3c0\n[ 1010.716063] ? is_bpf_text_address+0xc0/0x1f0\n[ 1010.716070] ? kernel_text_address.part.0+0xbb/0xd0\n[ 1010.716076] ? __kernel_text_address+0x56/0xa0\n[ 1010.716084] ? unwind_get_return_address+0x5a/0xa0\n[ 1010.716091] ? create_prof_cpu_mask+0x30/0x30\n[ 1010.716098] ? arch_stack_walk+0x9e/0xf0\n[ 1010.716106] ? stack_trace_save+0x91/0xd0\n[ 1010.716113] ? stack_trace_consume_entry+0x170/0x170\n[ 1010.716121] ? __lock_acquire+0x15c5/0x5380\n[ 1010.716139] ? mark_held_locks+0x9e/0xe0\n[ 1010.716148] ? kmem_cache_alloc_trace+0x35f/0x3c0\n[ 1010.716155] ? __rtnl_newlink+0x1700/0x1700\n[ 1010.716160] rtnl_newlink+0x69/0xa0\n[ 1010.716166] rtnetlink_rcv_msg+0x43b/0xc50\n[ 1010.716172] ? rtnl_fdb_dump+0x9f0/0x9f0\n[ 1010.716179] ? lock_acquire+0x1fe/0x560\n[ 1010.716188] ? netlink_deliver_tap+0x12f/0xd50\n[ 1010.716196] netlink_rcv_skb+0x14d/0x440\n[ 1010.716202] ? rtnl_fdb_dump+0x9f0/0x9f0\n[ 1010.716208] ? netlink_ack+0xab0/0xab0\n[ 1010.716213] ? netlink_deliver_tap+0x202/0xd50\n[ 1010.716220] ? netlink_deliver_tap+0x218/0xd50\n[ 1010.716226] ? __virt_addr_valid+0x30b/0x590\n[ 1010.716233] netlink_unicast+0x54b/0x800\n[ 1010.716240] ? netlink_attachskb+0x870/0x870\n[ 1010.716248] ? __check_object_size+0x2de/0x3b0\n[ 1010.716254] netlink_sendmsg+0x938/0xe40\n[ 1010.716261] ? netlink_unicast+0x800/0x800\n[ 1010.716269] ? __import_iovec+0x292/0x510\n[ 1010.716276] ? netlink_unicast+0x800/0x800\n[ 1010.716284] __sock_sendmsg+0x159/0x190\n[ 1010.716290] ____sys_sendmsg+0x712/0x880\n[ 1010.716297] ? sock_write_iter+0x3d0/0x3d0\n[ 1010.716304] ? __ia32_sys_recvmmsg+0x270/0x270\n[ 1010.716309] ? lock_acquire+0x1fe/0x560\n[ 1010.716315] ? drain_array_locked+0x90/0x90\n[ 1010.716324] ___sys_sendmsg+0xf8/0x170\n[ 1010.716331] ? sendmsg_copy_msghdr+0x170/0x170\n[ 1010.716337] ? lockdep_init_map\n---truncated---(CVE-2024-26793)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix potencial out-of-bounds when buffer offset is invalid\n\nI found potencial out-of-bounds when buffer offset fields of a few requests\nis invalid. This patch set the minimum value of buffer offset field to\n-\u0026gt;Buffer offset to validate buffer length.(CVE-2024-26952)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix slab-out-of-bounds in smb_strndup_from_utf16()\n\nIf -\u0026gt;NameOffset of smb2_create_req is smaller than Buffer offset of\nsmb2_create_req, slab-out-of-bounds read can happen from smb2_open.\nThis patch set the minimum value of the name offset to the buffer offset\nto validate name length of smb2_create_req().(CVE-2024-26954)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nclk: Get runtime PM before walking tree during disable_unused\n\nDoug reported [1] the following hung task:\n\n INFO: task swapper/0:1 blocked for more than 122 seconds.\n Not tainted 5.15.149-21875-gf795ebc40eb8 #1\n \u0026quot;echo 0 \u0026gt; /proc/sys/kernel/hung_task_timeout_secs\u0026quot; disables this message.\n task:swapper/0 state:D stack: 0 pid: 1 ppid: 0 flags:0x00000008\n Call trace:\n __switch_to+0xf4/0x1f4\n __schedule+0x418/0xb80\n schedule+0x5c/0x10c\n rpm_resume+0xe0/0x52c\n rpm_resume+0x178/0x52c\n __pm_runtime_resume+0x58/0x98\n clk_pm_runtime_get+0x30/0xb0\n clk_disable_unused_subtree+0x58/0x208\n clk_disable_unused_subtree+0x38/0x208\n clk_disable_unused_subtree+0x38/0x208\n clk_disable_unused_subtree+0x38/0x208\n clk_disable_unused_subtree+0x38/0x208\n clk_disable_unused+0x4c/0xe4\n do_one_initcall+0xcc/0x2d8\n do_initcall_level+0xa4/0x148\n do_initcalls+0x5c/0x9c\n do_basic_setup+0x24/0x30\n kernel_init_freeable+0xec/0x164\n kernel_init+0x28/0x120\n ret_from_fork+0x10/0x20\n INFO: task kworker/u16:0:9 blocked for more than 122 seconds.\n Not tainted 5.15.149-21875-gf795ebc40eb8 #1\n \u0026quot;echo 0 \u0026gt; /proc/sys/kernel/hung_task_timeout_secs\u0026quot; disables this message.\n task:kworker/u16:0 state:D stack: 0 pid: 9 ppid: 2 flags:0x00000008\n Workqueue: events_unbound deferred_probe_work_func\n Call trace:\n __switch_to+0xf4/0x1f4\n __schedule+0x418/0xb80\n schedule+0x5c/0x10c\n schedule_preempt_disabled+0x2c/0x48\n __mutex_lock+0x238/0x488\n __mutex_lock_slowpath+0x1c/0x28\n mutex_lock+0x50/0x74\n clk_prepare_lock+0x7c/0x9c\n clk_core_prepare_lock+0x20/0x44\n clk_prepare+0x24/0x30\n clk_bulk_prepare+0x40/0xb0\n mdss_runtime_resume+0x54/0x1c8\n pm_generic_runtime_resume+0x30/0x44\n __genpd_runtime_resume+0x68/0x7c\n genpd_runtime_resume+0x108/0x1f4\n __rpm_callback+0x84/0x144\n rpm_callback+0x30/0x88\n rpm_resume+0x1f4/0x52c\n rpm_resume+0x178/0x52c\n __pm_runtime_resume+0x58/0x98\n __device_attach+0xe0/0x170\n device_initial_probe+0x1c/0x28\n bus_probe_device+0x3c/0x9c\n device_add+0x644/0x814\n mipi_dsi_device_register_full+0xe4/0x170\n devm_mipi_dsi_device_register_full+0x28/0x70\n ti_sn_bridge_probe+0x1dc/0x2c0\n auxiliary_bus_probe+0x4c/0x94\n really_probe+0xcc/0x2c8\n __driver_probe_device+0xa8/0x130\n driver_probe_device+0x48/0x110\n __device_attach_driver+0xa4/0xcc\n bus_for_each_drv+0x8c/0xd8\n __device_attach+0xf8/0x170\n device_initial_probe+0x1c/0x28\n bus_probe_device+0x3c/0x9c\n deferred_probe_work_func+0x9c/0xd8\n process_one_work+0x148/0x518\n worker_thread+0x138/0x350\n kthread+0x138/0x1e0\n ret_from_fork+0x10/0x20\n\nThe first thread is walking the clk tree and calling\nclk_pm_runtime_get() to power on devices required to read the clk\nhardware via struct clk_ops::is_enabled(). This thread holds the clk\nprepare_lock, and is trying to runtime PM resume a device, when it finds\nthat the device is in the process of resuming so the thread schedule()s\naway waiting for the device to finish resuming before continuing. The\nsecond thread is runtime PM resuming the same device, but the runtime\nresume callback is calling clk_prepare(), trying to grab the\nprepare_lock waiting on the first thread.\n\nThis is a classic ABBA deadlock. To properly fix the deadlock, we must\nnever runtime PM resume or suspend a device with the clk prepare_lock\nheld. Actually doing that is near impossible today because the global\nprepare_lock would have to be dropped in the middle of the tree, the\ndevice runtime PM resumed/suspended, and then the prepare_lock grabbed\nagain to ensure consistency of the clk tree topology. If anything\nchanges with the clk tree in the meantime, we\u0026apos;ve lost and will need to\nstart the operation all over again.\n\nLuckily, most of the time we\u0026apos;re simply incrementing or decrementing the\nruntime PM count on an active device, so we don\u0026apos;t have the chance to\nschedule away with the prepare_lock held. Let\u0026apos;s fix this immediate\nproblem that can be\n---truncated---(CVE-2024-27004)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfpga: bridge: add owner module and take its refcount\n\nThe current implementation of the fpga bridge assumes that the low-level\nmodule registers a driver for the parent device and uses its owner pointer\nto take the module\u0026apos;s refcount. This approach is problematic since it can\nlead to a null pointer dereference while attempting to get the bridge if\nthe parent device does not have a driver.\n\nTo address this problem, add a module owner pointer to the fpga_bridge\nstruct and use it to take the module\u0026apos;s refcount. Modify the function for\nregistering a bridge to take an additional owner module parameter and\nrename it to avoid conflicts. Use the old function name for a helper macro\nthat automatically sets the module that registers the bridge as the owner.\nThis ensures compatibility with existing low-level control modules and\nreduces the chances of registering a bridge without setting the owner.\n\nAlso, update the documentation to keep it consistent with the new interface\nfor registering an fpga bridge.\n\nOther changes: opportunistically move put_device() from __fpga_bridge_get()\nto fpga_bridge_get() and of_fpga_bridge_get() to improve code clarity since\nthe bridge device is taken in these functions.(CVE-2024-36479)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfpga: manager: add owner module and take its refcount\n\nThe current implementation of the fpga manager assumes that the low-level\nmodule registers a driver for the parent device and uses its owner pointer\nto take the module\u0026apos;s refcount. This approach is problematic since it can\nlead to a null pointer dereference while attempting to get the manager if\nthe parent device does not have a driver.\n\nTo address this problem, add a module owner pointer to the fpga_manager\nstruct and use it to take the module\u0026apos;s refcount. Modify the functions for\nregistering the manager to take an additional owner module parameter and\nrename them to avoid conflicts. Use the old function names for helper\nmacros that automatically set the module that registers the manager as the\nowner. This ensures compatibility with existing low-level control modules\nand reduces the chances of registering a manager without setting the owner.\n\nAlso, update the documentation to keep it consistent with the new interface\nfor registering an fpga manager.\n\nOther changes: opportunistically move put_device() from __fpga_mgr_get() to\nfpga_mgr_get() and of_fpga_mgr_get() to improve code clarity since the\nmanager device is taken in these functions.(CVE-2024-37021)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni2c: lpi2c: Avoid calling clk_get_rate during transfer\n\nInstead of repeatedly calling clk_get_rate for each transfer, lock\nthe clock rate and cache the value.\nA deadlock has been observed while adding tlv320aic32x4 audio codec to\nthe system. When this clock provider adds its clock, the clk mutex is\nlocked already, it needs to access i2c, which in return needs the mutex\nfor clk_get_rate as well.(CVE-2024-40965)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\narm64: probes: Fix uprobes for big-endian kernels\n\nThe arm64 uprobes code is broken for big-endian kernels as it doesn\u0026apos;t\nconvert the in-memory instruction encoding (which is always\nlittle-endian) into the kernel\u0026apos;s native endianness before analyzing and\nsimulating instructions. This may result in a few distinct problems:\n\n* The kernel may may erroneously reject probing an instruction which can\n safely be probed.\n\n* The kernel may erroneously erroneously permit stepping an\n instruction out-of-line when that instruction cannot be stepped\n out-of-line safely.\n\n* The kernel may erroneously simulate instruction incorrectly dur to\n interpretting the byte-swapped encoding.\n\nThe endianness mismatch isn\u0026apos;t caught by the compiler or sparse because:\n\n* The arch_uprobe::{insn,ixol} fields are encoded as arrays of u8, so\n the compiler and sparse have no idea these contain a little-endian\n 32-bit value. The core uprobes code populates these with a memcpy()\n which similarly does not handle endianness.\n\n* While the uprobe_opcode_t type is an alias for __le32, both\n arch_uprobe_analyze_insn() and arch_uprobe_skip_sstep() cast from u8[]\n to the similarly-named probe_opcode_t, which is an alias for u32.\n Hence there is no endianness conversion warning.\n\nFix this by changing the arch_uprobe::{insn,ixol} fields to __le32 and\nadding the appropriate __le32_to_cpu() conversions prior to consuming\nthe instruction encoding. The core uprobes copies these fields as opaque\nranges of bytes, and so is unaffected by this change.\n\nAt the same time, remove MAX_UINSN_BYTES and consistently use\nAARCH64_INSN_SIZE for clarity.\n\nTested with the following:\n\n| #include \u0026lt;stdio.h\u0026gt;\n| #include \u0026lt;stdbool.h\u0026gt;\n|\n| #define noinline __attribute__((noinline))\n|\n| static noinline void *adrp_self(void)\n| {\n| void *addr;\n|\n| asm volatile(\n| \u0026quot; adrp %x0, adrp_self\\n\u0026quot;\n| \u0026quot; add %x0, %x0, :lo12:adrp_self\\n\u0026quot;\n| : \u0026quot;=r\u0026quot; (addr));\n| }\n|\n|\n| int main(int argc, char *argv)\n| {\n| void *ptr = adrp_self();\n| bool equal = (ptr == adrp_self);\n|\n| printf(\u0026quot;adrp_self =\u0026gt; %p\\n\u0026quot;\n| \u0026quot;adrp_self() =\u0026gt; %p\\n\u0026quot;\n| \u0026quot;%s\\n\u0026quot;,\n| adrp_self, ptr, equal ? \u0026quot;EQUAL\u0026quot; : \u0026quot;NOT EQUAL\u0026quot;);\n|\n| return 0;\n| }\n\n.... where the adrp_self() function was compiled to:\n\n| 00000000004007e0 \u0026lt;adrp_self\u0026gt;:\n| 4007e0: 90000000 adrp x0, 400000 \u0026lt;__ehdr_start\u0026gt;\n| 4007e4: 911f8000 add x0, x0, #0x7e0\n| 4007e8: d65f03c0 ret\n\nBefore this patch, the ADRP is not recognized, and is assumed to be\nsteppable, resulting in corruption of the result:\n\n| # ./adrp-self\n| adrp_self =\u0026gt; 0x4007e0\n| adrp_self() =\u0026gt; 0x4007e0\n| EQUAL\n| # echo \u0026apos;p /root/adrp-self:0x007e0\u0026apos; \u0026gt; /sys/kernel/tracing/uprobe_events\n| # echo 1 \u0026gt; /sys/kernel/tracing/events/uprobes/enable\n| # ./adrp-self\n| adrp_self =\u0026gt; 0x4007e0\n| adrp_self() =\u0026gt; 0xffffffffff7e0\n| NOT EQUAL\n\nAfter this patch, the ADRP is correctly recognized and simulated:\n\n| # ./adrp-self\n| adrp_self =\u0026gt; 0x4007e0\n| adrp_self() =\u0026gt; 0x4007e0\n| EQUAL\n| #\n| # echo \u0026apos;p /root/adrp-self:0x007e0\u0026apos; \u0026gt; /sys/kernel/tracing/uprobe_events\n| # echo 1 \u0026gt; /sys/kernel/tracing/events/uprobes/enable\n| # ./adrp-self\n| adrp_self =\u0026gt; 0x4007e0\n| adrp_self() =\u0026gt; 0x4007e0\n| EQUAL(CVE-2024-50194)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndm cache: fix flushing uninitialized delayed_work on cache_ctr error\n\nAn unexpected WARN_ON from flush_work() may occur when cache creation\nfails, caused by destroying the uninitialized delayed_work waker in the\nerror path of cache_create(). For example, the warning appears on the\nsuperblock checksum error.\n\nReproduce steps:\n\ndmsetup create cmeta --table \u0026quot;0 8192 linear /dev/sdc 0\u0026quot;\ndmsetup create cdata --table \u0026quot;0 65536 linear /dev/sdc 8192\u0026quot;\ndmsetup create corig --table \u0026quot;0 524288 linear /dev/sdc 262144\u0026quot;\ndd if=/dev/urandom of=/dev/mapper/cmeta bs=4k count=1 oflag=direct\ndmsetup create cache --table \u0026quot;0 524288 cache /dev/mapper/cmeta \\\n/dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\u0026quot;\n\nKernel logs:\n\n(snip)\nWARNING: CPU: 0 PID: 84 at kernel/workqueue.c:4178 __flush_work+0x5d4/0x890\n\nFix by pulling out the cancel_delayed_work_sync() from the constructor\u0026apos;s\nerror path. This patch doesn\u0026apos;t affect the use-after-free fix for\nconcurrent dm_resume and dm_destroy (commit 6a459d8edbdb (\u0026quot;dm cache: Fix\nUAF in destroy()\u0026quot;)) as cache_dtr is not changed.(CVE-2024-50280)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnilfs2: fix null-ptr-deref in block_touch_buffer tracepoint\n\nPatch series \u0026quot;nilfs2: fix null-ptr-deref bugs on block tracepoints\u0026quot;.\n\nThis series fixes null pointer dereference bugs that occur when using\nnilfs2 and two block-related tracepoints.\n\n\nThis patch (of 2):\n\nIt has been reported that when using \u0026quot;block:block_touch_buffer\u0026quot;\ntracepoint, touch_buffer() called from __nilfs_get_folio_block() causes a\nNULL pointer dereference, or a general protection fault when KASAN is\nenabled.\n\nThis happens because since the tracepoint was added in touch_buffer(), it\nreferences the dev_t member bh-\u0026gt;b_bdev-\u0026gt;bd_dev regardless of whether the\nbuffer head has a pointer to a block_device structure. In the current\nimplementation, the block_device structure is set after the function\nreturns to the caller.\n\nHere, touch_buffer() is used to mark the folio/page that owns the buffer\nhead as accessed, but the common search helper for folio/page used by the\ncaller function was optimized to mark the folio/page as accessed when it\nwas reimplemented a long time ago, eliminating the need to call\ntouch_buffer() here in the first place.\n\nSo this solves the issue by eliminating the touch_buffer() call itself.(CVE-2024-53131)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\num: net: Do not use drvdata in release\n\nThe drvdata is not available in release. Let\u0026apos;s just use container_of()\nto get the uml_net instance. Otherwise, removing a network device will\nresult in a crash:\n\nRIP: 0033:net_device_release+0x10/0x6f\nRSP: 00000000e20c7c40 EFLAGS: 00010206\nRAX: 000000006002e4e7 RBX: 00000000600f1baf RCX: 00000000624074e0\nRDX: 0000000062778000 RSI: 0000000060551c80 RDI: 00000000627af028\nRBP: 00000000e20c7c50 R08: 00000000603ad594 R09: 00000000e20c7b70\nR10: 000000000000135a R11: 00000000603ad422 R12: 0000000000000000\nR13: 0000000062c7af00 R14: 0000000062406d60 R15: 00000000627700b6\nKernel panic - not syncing: Segfault with no mm\nCPU: 0 UID: 0 PID: 29 Comm: kworker/0:2 Not tainted 6.12.0-rc6-g59b723cd2adb #1\nWorkqueue: events mc_work_proc\nStack:\n 627af028 62c7af00 e20c7c80 60276fcd\n 62778000 603f5820 627af028 00000000\n e20c7cb0 603a2bcd 627af000 62770010\nCall Trace:\n [\u0026lt;60276fcd\u0026gt;] device_release+0x70/0xba\n [\u0026lt;603a2bcd\u0026gt;] kobject_put+0xba/0xe7\n [\u0026lt;60277265\u0026gt;] put_device+0x19/0x1c\n [\u0026lt;60281266\u0026gt;] platform_device_put+0x26/0x29\n [\u0026lt;60281e5f\u0026gt;] platform_device_unregister+0x2c/0x2e\n [\u0026lt;6002ec9c\u0026gt;] net_remove+0x63/0x69\n [\u0026lt;60031316\u0026gt;] ? mconsole_reply+0x0/0x50\n [\u0026lt;600310c8\u0026gt;] mconsole_remove+0x160/0x1cc\n [\u0026lt;60087d40\u0026gt;] ? __remove_hrtimer+0x38/0x74\n [\u0026lt;60087ff8\u0026gt;] ? hrtimer_try_to_cancel+0x8c/0x98\n [\u0026lt;6006b3cf\u0026gt;] ? dl_server_stop+0x3f/0x48\n [\u0026lt;6006b390\u0026gt;] ? dl_server_stop+0x0/0x48\n [\u0026lt;600672e8\u0026gt;] ? dequeue_entities+0x327/0x390\n [\u0026lt;60038fa6\u0026gt;] ? um_set_signals+0x0/0x43\n [\u0026lt;6003070c\u0026gt;] mc_work_proc+0x77/0x91\n [\u0026lt;60057664\u0026gt;] process_scheduled_works+0x1b3/0x2dd\n [\u0026lt;60055f32\u0026gt;] ? assign_work+0x0/0x58\n [\u0026lt;60057f0a\u0026gt;] worker_thread+0x1e9/0x293\n [\u0026lt;6005406f\u0026gt;] ? set_pf_worker+0x0/0x64\n [\u0026lt;6005d65d\u0026gt;] ? arch_local_irq_save+0x0/0x2d\n [\u0026lt;6005d748\u0026gt;] ? kthread_exit+0x0/0x3a\n [\u0026lt;60057d21\u0026gt;] ? worker_thread+0x0/0x293\n [\u0026lt;6005dbf1\u0026gt;] kthread+0x126/0x12b\n [\u0026lt;600219c5\u0026gt;] new_thread_handler+0x85/0xb6(CVE-2024-53183)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxen: Fix the issue of resource not being properly released in xenbus_dev_probe()\n\nThis patch fixes an issue in the function xenbus_dev_probe(). In the\nxenbus_dev_probe() function, within the if (err) branch at line 313, the\nprogram incorrectly returns err directly without releasing the resources\nallocated by err = drv-\u0026gt;probe(dev, id). As the return value is non-zero,\nthe upper layers assume the processing logic has failed. However, the probe\noperation was performed earlier without a corresponding remove operation.\nSince the probe actually allocates resources, failing to perform the remove\noperation could lead to problems.\n\nTo fix this issue, we followed the resource release logic of the\nxenbus_dev_remove() function by adding a new block fail_remove before the\nfail_put block. After entering the branch if (err) at line 313, the\nfunction will use a goto statement to jump to the fail_remove block,\nensuring that the previously acquired resources are correctly released,\nthus preventing the reference count leak.\n\nThis bug was identified by an experimental static analysis tool developed\nby our team. The tool specializes in analyzing reference count operations\nand detecting potential issues where resources are not properly managed.\nIn this case, the tool flagged the missing release operation as a\npotential problem, which led to the development of this patch.(CVE-2024-53198)\n\nIn the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix null check for pipe_ctx-\u0026gt;plane_state in dcn20_program_pipeThis commit addresses a null pointer dereference issue indcn20_program_pipe(). Previously, commit 8e4ed3cf1642 ( drm/amd/display:Add null check for pipe_ctx-\u0026gt;plane_state in dcn20_program_pipe )partially fixed the null pointer dereference issue. However, indcn20_update_dchubp_dpp(), the variable pipe_ctx is passed in, andplane_state is accessed again through pipe_ctx. Multiple if statementsdirectly call attributes of plane_state, leading to potential nullpointer dereference issues. This patch adds necessary null checks toensure stability.(CVE-2024-53201)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mwifiex: Fix memcpy() field-spanning write warning in mwifiex_config_scan()\n\nReplace one-element array with a flexible-array member in `struct\nmwifiex_ie_types_wildcard_ssid_params` to fix the following warning\non a MT8173 Chromebook (mt8173-elm-hana):\n\n[ 356.775250] ------------[ cut here ]------------\n[ 356.784543] memcpy: detected field-spanning write (size 6) of single field \u0026quot;wildcard_ssid_tlv-\u0026gt;ssid\u0026quot; at drivers/net/wireless/marvell/mwifiex/scan.c:904 (size 1)\n[ 356.813403] WARNING: CPU: 3 PID: 742 at drivers/net/wireless/marvell/mwifiex/scan.c:904 mwifiex_scan_networks+0x4fc/0xf28 [mwifiex]\n\nThe \u0026quot;(size 6)\u0026quot; above is exactly the length of the SSID of the network\nthis device was connected to. The source of the warning looks like:\n\n ssid_len = user_scan_in-\u0026gt;ssid_list[i].ssid_len;\n [...]\n memcpy(wildcard_ssid_tlv-\u0026gt;ssid,\n user_scan_in-\u0026gt;ssid_list[i].ssid, ssid_len);\n\nThere is a #define WILDCARD_SSID_TLV_MAX_SIZE that uses sizeof() on this\nstruct, but it already didn\u0026apos;t account for the size of the one-element\narray, so it doesn\u0026apos;t need to be changed.(CVE-2024-56539)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: uvcvideo: Require entities to have a non-zero unique ID\n\nPer UVC 1.1+ specification 3.7.2, units and terminals must have a non-zero\nunique ID.\n\n```\nEach Unit and Terminal within the video function is assigned a unique\nidentification number, the Unit ID (UID) or Terminal ID (TID), contained in\nthe bUnitID or bTerminalID field of the descriptor. The value 0x00 is\nreserved for undefined ID,\n```\n\nSo, deny allocating an entity with ID 0 or an ID that belongs to a unit\nthat is already added to the list of entities.\n\nThis also prevents some syzkaller reproducers from triggering warnings due\nto a chain of entities referring to themselves. In one particular case, an\nOutput Unit is connected to an Input Unit, both with the same ID of 1. But\nwhen looking up for the source ID of the Output Unit, that same entity is\nfound instead of the input entity, which leads to such warnings.\n\nIn another case, a backward chain was considered finished as the source ID\nwas 0. Later on, that entity was found, but its pads were not valid.\n\nHere is a sample stack trace for one of those cases.\n\n[ 20.650953] usb 1-1: new high-speed USB device number 2 using dummy_hcd\n[ 20.830206] usb 1-1: Using ep0 maxpacket: 8\n[ 20.833501] usb 1-1: config 0 descriptor??\n[ 21.038518] usb 1-1: string descriptor 0 read error: -71\n[ 21.038893] usb 1-1: Found UVC 0.00 device \u0026lt;unnamed\u0026gt; (2833:0201)\n[ 21.039299] uvcvideo 1-1:0.0: Entity type for entity Output 1 was not initialized!\n[ 21.041583] uvcvideo 1-1:0.0: Entity type for entity Input 1 was not initialized!\n[ 21.042218] ------------[ cut here ]------------\n[ 21.042536] WARNING: CPU: 0 PID: 9 at drivers/media/mc/mc-entity.c:1147 media_create_pad_link+0x2c4/0x2e0\n[ 21.043195] Modules linked in:\n[ 21.043535] CPU: 0 UID: 0 PID: 9 Comm: kworker/0:1 Not tainted 6.11.0-rc7-00030-g3480e43aeccf #444\n[ 21.044101] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014\n[ 21.044639] Workqueue: usb_hub_wq hub_event\n[ 21.045100] RIP: 0010:media_create_pad_link+0x2c4/0x2e0\n[ 21.045508] Code: fe e8 20 01 00 00 b8 f4 ff ff ff 48 83 c4 30 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 0f 0b eb e9 0f 0b eb 0a 0f 0b eb 06 \u0026lt;0f\u0026gt; 0b eb 02 0f 0b b8 ea ff ff ff eb d4 66 2e 0f 1f 84 00 00 00 00\n[ 21.046801] RSP: 0018:ffffc9000004b318 EFLAGS: 00010246\n[ 21.047227] RAX: ffff888004e5d458 RBX: 0000000000000000 RCX: ffffffff818fccf1\n[ 21.047719] RDX: 000000000000007b RSI: 0000000000000000 RDI: ffff888004313290\n[ 21.048241] RBP: ffff888004313290 R08: 0001ffffffffffff R09: 0000000000000000\n[ 21.048701] R10: 0000000000000013 R11: 0001888004313290 R12: 0000000000000003\n[ 21.049138] R13: ffff888004313080 R14: ffff888004313080 R15: 0000000000000000\n[ 21.049648] FS: 0000000000000000(0000) GS:ffff88803ec00000(0000) knlGS:0000000000000000\n[ 21.050271] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 21.050688] CR2: 0000592cc27635b0 CR3: 000000000431c000 CR4: 0000000000750ef0\n[ 21.051136] PKRU: 55555554\n[ 21.051331] Call Trace:\n[ 21.051480] \u0026lt;TASK\u0026gt;\n[ 21.051611] ? __warn+0xc4/0x210\n[ 21.051861] ? media_create_pad_link+0x2c4/0x2e0\n[ 21.052252] ? report_bug+0x11b/0x1a0\n[ 21.052540] ? trace_hardirqs_on+0x31/0x40\n[ 21.052901] ? handle_bug+0x3d/0x70\n[ 21.053197] ? exc_invalid_op+0x1a/0x50\n[ 21.053511] ? asm_exc_invalid_op+0x1a/0x20\n[ 21.053924] ? media_create_pad_link+0x91/0x2e0\n[ 21.054364] ? media_create_pad_link+0x2c4/0x2e0\n[ 21.054834] ? media_create_pad_link+0x91/0x2e0\n[ 21.055131] ? _raw_spin_unlock+0x1e/0x40\n[ 21.055441] ? __v4l2_device_register_subdev+0x202/0x210\n[ 21.055837] uvc_mc_register_entities+0x358/0x400\n[ 21.056144] uvc_register_chains+0x1fd/0x290\n[ 21.056413] uvc_probe+0x380e/0x3dc0\n[ 21.056676] ? __lock_acquire+0x5aa/0x26e0\n[ 21.056946] ? find_held_lock+0x33/0xa0\n[ 21.057196] ? kernfs_activate+0x70/0x80\n[ 21.057533] ? usb_match_dy\n---truncated---(CVE-2024-56571)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: hisi_sas: Create all dump files during debugfs initialization\n\nFor the current debugfs of hisi_sas, after user triggers dump, the\ndriver allocate memory space to save the register information and create\ndebugfs files to display the saved information. In this process, the\ndebugfs files created after each dump.\n\nTherefore, when the dump is triggered while the driver is unbind, the\nfollowing hang occurs:\n\n[67840.853907] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a0\n[67840.862947] Mem abort info:\n[67840.865855] ESR = 0x0000000096000004\n[67840.869713] EC = 0x25: DABT (current EL), IL = 32 bits\n[67840.875125] SET = 0, FnV = 0\n[67840.878291] EA = 0, S1PTW = 0\n[67840.881545] FSC = 0x04: level 0 translation fault\n[67840.886528] Data abort info:\n[67840.889524] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000\n[67840.895117] CM = 0, WnR = 0, TnD = 0, TagAccess = 0\n[67840.900284] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\n[67840.905709] user pgtable: 4k pages, 48-bit VAs, pgdp=0000002803a1f000\n[67840.912263] [00000000000000a0] pgd=0000000000000000, p4d=0000000000000000\n[67840.919177] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP\n[67840.996435] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[67841.003628] pc : down_write+0x30/0x98\n[67841.007546] lr : start_creating.part.0+0x60/0x198\n[67841.012495] sp : ffff8000b979ba20\n[67841.016046] x29: ffff8000b979ba20 x28: 0000000000000010 x27: 0000000000024b40\n[67841.023412] x26: 0000000000000012 x25: ffff20202b355ae8 x24: ffff20202b35a8c8\n[67841.030779] x23: ffffa36877928208 x22: ffffa368b4972240 x21: ffff8000b979bb18\n[67841.038147] x20: ffff00281dc1e3c0 x19: fffffffffffffffe x18: 0000000000000020\n[67841.045515] x17: 0000000000000000 x16: ffffa368b128a530 x15: ffffffffffffffff\n[67841.052888] x14: ffff8000b979bc18 x13: ffffffffffffffff x12: ffff8000b979bb18\n[67841.060263] x11: 0000000000000000 x10: 0000000000000000 x9 : ffffa368b1289b18\n[67841.067640] x8 : 0000000000000012 x7 : 0000000000000000 x6 : 00000000000003a9\n[67841.075014] x5 : 0000000000000000 x4 : ffff002818c5cb00 x3 : 0000000000000001\n[67841.082388] x2 : 0000000000000000 x1 : ffff002818c5cb00 x0 : 00000000000000a0\n[67841.089759] Call trace:\n[67841.092456] down_write+0x30/0x98\n[67841.096017] start_creating.part.0+0x60/0x198\n[67841.100613] debugfs_create_dir+0x48/0x1f8\n[67841.104950] debugfs_create_files_v3_hw+0x88/0x348 [hisi_sas_v3_hw]\n[67841.111447] debugfs_snapshot_regs_v3_hw+0x708/0x798 [hisi_sas_v3_hw]\n[67841.118111] debugfs_trigger_dump_v3_hw_write+0x9c/0x120 [hisi_sas_v3_hw]\n[67841.125115] full_proxy_write+0x68/0xc8\n[67841.129175] vfs_write+0xd8/0x3f0\n[67841.132708] ksys_write+0x70/0x108\n[67841.136317] __arm64_sys_write+0x24/0x38\n[67841.140440] invoke_syscall+0x50/0x128\n[67841.144385] el0_svc_common.constprop.0+0xc8/0xf0\n[67841.149273] do_el0_svc+0x24/0x38\n[67841.152773] el0_svc+0x38/0xd8\n[67841.156009] el0t_64_sync_handler+0xc0/0xc8\n[67841.160361] el0t_64_sync+0x1a4/0x1a8\n[67841.164189] Code: b9000882 d2800002 d2800023 f9800011 (c85ffc05)\n[67841.170443] ---[ end trace 0000000000000000 ]---\n\nTo fix this issue, create all directories and files during debugfs\ninitialization. In this way, the driver only needs to allocate memory\nspace to save information each time the user triggers dumping.(CVE-2024-56588)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nkcsan: Turn report_filterlist_lock into a raw_spinlock\n\nRan Xiaokai reports that with a KCSAN-enabled PREEMPT_RT kernel, we can see\nsplats like:\n\n| BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48\n| in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/1\n| preempt_count: 10002, expected: 0\n| RCU nest depth: 0, expected: 0\n| no locks held by swapper/1/0.\n| irq event stamp: 156674\n| hardirqs last enabled at (156673): [\u0026lt;ffffffff81130bd9\u0026gt;] do_idle+0x1f9/0x240\n| hardirqs last disabled at (156674): [\u0026lt;ffffffff82254f84\u0026gt;] sysvec_apic_timer_interrupt+0x14/0xc0\n| softirqs last enabled at (0): [\u0026lt;ffffffff81099f47\u0026gt;] copy_process+0xfc7/0x4b60\n| softirqs last disabled at (0): [\u0026lt;0000000000000000\u0026gt;] 0x0\n| Preemption disabled at:\n| [\u0026lt;ffffffff814a3e2a\u0026gt;] paint_ptr+0x2a/0x90\n| CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Not tainted 6.11.0+ #3\n| Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-0-ga698c8995f-prebuilt.qemu.org 04/01/2014\n| Call Trace:\n| \u0026lt;IRQ\u0026gt;\n| dump_stack_lvl+0x7e/0xc0\n| dump_stack+0x1d/0x30\n| __might_resched+0x1a2/0x270\n| rt_spin_lock+0x68/0x170\n| kcsan_skip_report_debugfs+0x43/0xe0\n| print_report+0xb5/0x590\n| kcsan_report_known_origin+0x1b1/0x1d0\n| kcsan_setup_watchpoint+0x348/0x650\n| __tsan_unaligned_write1+0x16d/0x1d0\n| hrtimer_interrupt+0x3d6/0x430\n| __sysvec_apic_timer_interrupt+0xe8/0x3a0\n| sysvec_apic_timer_interrupt+0x97/0xc0\n| \u0026lt;/IRQ\u0026gt;\n\nOn a detected data race, KCSAN\u0026apos;s reporting logic checks if it should\nfilter the report. That list is protected by the report_filterlist_lock\n*non-raw* spinlock which may sleep on RT kernels.\n\nSince KCSAN may report data races in any context, convert it to a\nraw_spinlock.\n\nThis requires being careful about when to allocate memory for the filter\nlist itself which can be done via KCSAN\u0026apos;s debugfs interface. Concurrent\nmodification of the filter list via debugfs should be rare: the chosen\nstrategy is to optimistically pre-allocate memory before the critical\nsection and discard if unused.(CVE-2024-56610)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/mempolicy: fix migrate_to_node() assuming there is at least one VMA in a MM\n\nWe currently assume that there is at least one VMA in a MM, which isn\u0026apos;t\ntrue.\n\nSo we might end up having find_vma() return NULL, to then de-reference\nNULL. So properly handle find_vma() returning NULL.\n\nThis fixes the report:\n\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: 1 UID: 0 PID: 6021 Comm: syz-executor284 Not tainted 6.12.0-rc7-syzkaller-00187-gf868cd251776 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024\nRIP: 0010:migrate_to_node mm/mempolicy.c:1090 [inline]\nRIP: 0010:do_migrate_pages+0x403/0x6f0 mm/mempolicy.c:1194\nCode: ...\nRSP: 0018:ffffc9000375fd08 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: ffffc9000375fd78 RCX: 0000000000000000\nRDX: ffff88807e171300 RSI: dffffc0000000000 RDI: ffff88803390c044\nRBP: ffff88807e171428 R08: 0000000000000014 R09: fffffbfff2039ef1\nR10: ffffffff901cf78f R11: 0000000000000000 R12: 0000000000000003\nR13: ffffc9000375fe90 R14: ffffc9000375fe98 R15: ffffc9000375fdf8\nFS: 00005555919e1380(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00005555919e1ca8 CR3: 000000007f12a000 CR4: 00000000003526f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n kernel_migrate_pages+0x5b2/0x750 mm/mempolicy.c:1709\n __do_sys_migrate_pages mm/mempolicy.c:1727 [inline]\n __se_sys_migrate_pages mm/mempolicy.c:1723 [inline]\n __x64_sys_migrate_pages+0x96/0x100 mm/mempolicy.c:1723\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\n[akpm@linux-foundation.org: add unlikely()](CVE-2024-56611)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qla2xxx: Fix use after free on unload\n\nSystem crash is observed with stack trace warning of use after\nfree. There are 2 signals to tell dpc_thread to terminate (UNLOADING\nflag and kthread_stop).\n\nOn setting the UNLOADING flag when dpc_thread happens to run at the time\nand sees the flag, this causes dpc_thread to exit and clean up\nitself. When kthread_stop is called for final cleanup, this causes use\nafter free.\n\nRemove UNLOADING signal to terminate dpc_thread. Use the kthread_stop\nas the main signal to exit dpc_thread.\n\n[596663.812935] kernel BUG at mm/slub.c:294!\n[596663.812950] invalid opcode: 0000 [#1] SMP PTI\n[596663.812957] CPU: 13 PID: 1475935 Comm: rmmod Kdump: loaded Tainted: G IOE --------- - - 4.18.0-240.el8.x86_64 #1\n[596663.812960] Hardware name: HP ProLiant DL380p Gen8, BIOS P70 08/20/2012\n[596663.812974] RIP: 0010:__slab_free+0x17d/0x360\n\n...\n[596663.813008] Call Trace:\n[596663.813022] ? __dentry_kill+0x121/0x170\n[596663.813030] ? _cond_resched+0x15/0x30\n[596663.813034] ? _cond_resched+0x15/0x30\n[596663.813039] ? wait_for_completion+0x35/0x190\n[596663.813048] ? try_to_wake_up+0x63/0x540\n[596663.813055] free_task+0x5a/0x60\n[596663.813061] kthread_stop+0xf3/0x100\n[596663.813103] qla2x00_remove_one+0x284/0x440 [qla2xxx](CVE-2024-56623)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsunrpc: clear XPRT_SOCK_UPD_TIMEOUT when reset transport\n\nSince transport-\u0026gt;sock has been set to NULL during reset transport,\nXPRT_SOCK_UPD_TIMEOUT also needs to be cleared. Otherwise, the\nxs_tcp_set_socket_timeouts() may be triggered in xs_tcp_send_request()\nto dereference the transport-\u0026gt;sock that has been set to NULL.(CVE-2024-56688)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\n9p/xen: fix release of IRQ\n\nKernel logs indicate an IRQ was double-freed.\n\nPass correct device ID during IRQ release.\n\n[Dominique: remove confusing variable reset to 0](CVE-2024-56704)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nionic: Fix netdev notifier unregister on failure\n\nIf register_netdev() fails, then the driver leaks the netdev notifier.\nFix this by calling ionic_lif_unregister() on register_netdev()\nfailure. This will also call ionic_lif_unregister_phc() if it has\nalready been registered.(CVE-2024-56715)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfbdev: sh7760fb: Fix a possible memory leak in sh7760fb_alloc_mem()\n\nWhen information such as info-\u0026gt;screen_base is not ready, calling\nsh7760fb_free_mem() does not release memory correctly. Call\ndma_free_coherent() instead.(CVE-2024-56746)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nocfs2: fix slab-use-after-free due to dangling pointer dqi_priv\n\nWhen mounting ocfs2 and then remounting it as read-only, a\nslab-use-after-free occurs after the user uses a syscall to\nquota_getnextquota. Specifically, sb_dqinfo(sb, type)-\u0026gt;dqi_priv is the\ndangling pointer.\n\nDuring the remounting process, the pointer dqi_priv is freed but is never\nset as null leaving it to be accessed. Additionally, the read-only option\nfor remounting sets the DQUOT_SUSPENDED flag instead of setting the\nDQUOT_USAGE_ENABLED flags. Moreover, later in the process of getting the\nnext quota, the function ocfs2_get_next_id is called and only checks the\nquota usage flags and not the quota suspended flags.\n\nTo fix this, I set dqi_priv to null when it is freed after remounting with\nread-only and put a check for DQUOT_SUSPENDED in ocfs2_get_next_id.\n\n[akpm@linux-foundation.org: coding-style cleanups](CVE-2024-57892)",
"id": "OESA-2025-1096",
"modified": "2026-08-06T11:08:11Z",
"published": "2025-02-08T11:08:11Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1096"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52434"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52480"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52614"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52627"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52913"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-24857"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-24859"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26659"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26664"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26673"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26747"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26748"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26749"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26753"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26781"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26790"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26793"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26952"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26954"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27004"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36479"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-37021"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40965"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50194"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50280"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53131"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53183"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53198"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53201"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56539"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56571"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56588"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56610"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56611"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56623"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56688"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56704"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56715"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56746"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57892"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2023-52434",
"CVE-2023-52480",
"CVE-2023-52614",
"CVE-2023-52627",
"CVE-2023-52913",
"CVE-2024-24857",
"CVE-2024-24859",
"CVE-2024-26659",
"CVE-2024-26664",
"CVE-2024-26673",
"CVE-2024-26747",
"CVE-2024-26748",
"CVE-2024-26749",
"CVE-2024-26753",
"CVE-2024-26781",
"CVE-2024-26790",
"CVE-2024-26793",
"CVE-2024-26952",
"CVE-2024-26954",
"CVE-2024-27004",
"CVE-2024-36479",
"CVE-2024-37021",
"CVE-2024-40965",
"CVE-2024-50194",
"CVE-2024-50280",
"CVE-2024-53131",
"CVE-2024-53183",
"CVE-2024-53198",
"CVE-2024-53201",
"CVE-2024-56539",
"CVE-2024-56571",
"CVE-2024-56588",
"CVE-2024-56610",
"CVE-2024-56611",
"CVE-2024-56623",
"CVE-2024-56688",
"CVE-2024-56704",
"CVE-2024-56715",
"CVE-2024-56746",
"CVE-2024-57892"
]
}
OESA-2025-1286 (CVE-2023-52926)
Vulnerability from osv_openeuler – Published: 2025-03-14 11:08 – Updated: 2026-08-06 11:08 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
IORING_OP_READ did not correctly consume the provided buffer list when read i/o returned < 0 (except for -EAGAIN and -EIOCBQUEUED return). This can lead to a potential use-after-free when the completion via io_rw_done runs at separate context.(CVE-2023-52926)
In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to shrink read extent node in batches
We use rwlock to protect core structure data of extent tree during its shrink, however, if there is a huge number of extent nodes in extent tree, during shrink of extent tree, it may hold rwlock for a very long time, which may trigger kernel hang issue.
This patch fixes to shrink read extent node in batches, so that, critical region of the rwlock can be shrunk to avoid its extreme long time hold.(CVE-2024-41935)
In the Linux kernel, the following vulnerability has been resolved:
dma-debug: fix a possible deadlock on radix_lock
radix_lock() shouldn't be held while holding dma_hash_entry[idx].lock otherwise, there's a possible deadlock scenario when dma debug API is called holding rq_lock():
CPU0 CPU1 CPU2 dma_free_attrs() check_unmap() add_dma_entry() __schedule() //out (A) rq_lock() get_hash_bucket() (A) dma_entry_hash check_sync() (A) radix_lock() (W) dma_entry_hash dma_entry_free() (W) radix_lock() // CPU2's one (W) rq_lock()
CPU1 situation can happen when it extending radix tree and it tries to wake up kswapd via wake_all_kswapd().
CPU2 situation can happen while perf_event_task_sched_out() (i.e. dma sync operation is called while deleting perf_event using etm and etr tmc which are Arm Coresight hwtracing driver backends).
To remove this possible situation, call dma_entry_free() after put_hash_bucket() in check_unmap().(CVE-2024-47143)
In the Linux kernel, the following vulnerability has been resolved:
dlm: fix possible lkb_resource null dereference
This patch fixes a possible null pointer dereference when this function is called from request_lock() as lkb->lkb_resource is not assigned yet, only after validate_lock_args() by calling attach_lkb(). Another issue is that a resource name could be a non printable bytearray and we cannot assume to be ASCII coded.
The log functionality is probably never being hit when DLM is used in normal way and no debug logging is enabled. The null pointer dereference can only occur on a new created lkb that does not have the resource assigned yet, it probably never hits the null pointer dereference but we should be sure that other changes might not change this behaviour and we actually can hit the mentioned null pointer dereference.
In this patch we just drop the printout of the resource name, the lkb id is enough to make a possible connection to a resource name if this exists.(CVE-2024-47809)
In the Linux kernel, the following vulnerability has been resolved:
bcache: revert replacing IS_ERR_OR_NULL with IS_ERR again
Commit 028ddcac477b ("bcache: Remove unnecessary NULL point check in node allocations") leads a NULL pointer deference in cache_set_flush().
1721 if (!IS_ERR_OR_NULL(c->root)) 1722 list_add(&c->root->list, &c->btree_cache);
>From the above code in cache_set_flush(), if previous registration code fails before allocating c->root, it is possible c->root is NULL as what it is initialized. __bch_btree_node_alloc() never returns NULL but c->root is possible to be NULL at above line 1721.
This patch replaces IS_ERR() by IS_ERR_OR_NULL() to fix this.(CVE-2024-48881)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: ipset: add missing range check in bitmap_ip_uadt
When tb[IPSET_ATTR_IP_TO] is not present but tb[IPSET_ATTR_CIDR] exists, the values of ip and ip_to are slightly swapped. Therefore, the range check for ip should be done later, but this part is missing and it seems that the vulnerability occurs.
So we should add missing range checks and remove unnecessary range checks.(CVE-2024-53141)
In the Linux kernel, the following vulnerability has been resolved:
comedi: Flush partial mappings in error case
If some remap_pfn_range() calls succeeded before one failed, we still have buffer pages mapped into the userspace page tables when we drop the buffer reference with comedi_buf_map_put(bm). The userspace mappings are only cleaned up later in the mmap error path.
Fix it by explicitly flushing all mappings in our VMA on the error path.
See commit 79a61cc3fc04 ("mm: avoid leaving partial pfn mappings around in error case").(CVE-2024-53148)
In the Linux kernel, the following vulnerability has been resolved:
wifi: ath9k: add range check for conn_rsp_epid in htc_connect_service()
I found the following bug in my fuzzer:
UBSAN: array-index-out-of-bounds in drivers/net/wireless/ath/ath9k/htc_hst.c:26:51 index 255 is out of range for type 'htc_endpoint [22]' CPU: 0 UID: 0 PID: 8 Comm: kworker/0:0 Not tainted 6.11.0-rc6-dirty #14 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: events request_firmware_work_func Call Trace: <TASK> dump_stack_lvl+0x180/0x1b0 __ubsan_handle_out_of_bounds+0xd4/0x130 htc_issue_send.constprop.0+0x20c/0x230 ? _raw_spin_unlock_irqrestore+0x3c/0x70 ath9k_wmi_cmd+0x41d/0x610 ? mark_held_locks+0x9f/0xe0 ...
Since this bug has been confirmed to be caused by insufficient verification of conn_rsp_epid, I think it would be appropriate to add a range check for conn_rsp_epid to htc_connect_service() to prevent the bug from occurring.(CVE-2024-53156)
In the Linux kernel, the following vulnerability has been resolved:
smb: During unmount, ensure all cached dir instances drop their dentry
The unmount process (cifs_kill_sb() calling close_all_cached_dirs()) can race with various cached directory operations, which ultimately results in dentries not being dropped and these kernel BUGs:
BUG: Dentry ffff88814f37e358{i=1000000000080,n=/} still in use (2) [unmount of cifs cifs] VFS: Busy inodes after unmount of cifs (cifs) ------------[ cut here ]------------ kernel BUG at fs/super.c:661!
This happens when a cfid is in the process of being cleaned up when, and has been removed from the cfids->entries list, including:
- Receiving a lease break from the server
- Server reconnection triggers invalidate_all_cached_dirs(), which removes all the cfids from the list
- The laundromat thread decides to expire an old cfid.
To solve these problems, dropping the dentry is done in queued work done in a newly-added cfid_put_wq workqueue, and close_all_cached_dirs() flushes that workqueue after it drops all the dentries of which it's aware. This is a global workqueue (rather than scoped to a mount), but the queued work is minimal.
The final cleanup work for cleaning up a cfid is performed via work queued in the serverclose_wq workqueue; this is done separate from dropping the dentries so that close_all_cached_dirs() doesn't block on any server operations.
Both of these queued works expect to invoked with a cfid reference and a tcon reference to avoid those objects from being freed while the work is ongoing.
While we're here, add proper locking to close_all_cached_dirs(), and locking around the freeing of cfid->dentry.(CVE-2024-53176)
In the Linux kernel, the following vulnerability has been resolved:
smb: prevent use-after-free due to open_cached_dir error paths
If open_cached_dir() encounters an error parsing the lease from the server, the error handling may race with receiving a lease break, resulting in open_cached_dir() freeing the cfid while the queued work is pending.
Update open_cached_dir() to drop refs rather than directly freeing the cfid.
Have cached_dir_lease_break(), cfids_laundromat_worker(), and invalidate_all_cached_dirs() clear has_lease immediately while still holding cfids->cfid_list_lock, and then use this to also simplify the reference counting in cfids_laundromat_worker() and invalidate_all_cached_dirs().
Fixes this KASAN splat (which manually injects an error and lease break in open_cached_dir()):
================================================================== BUG: KASAN: slab-use-after-free in smb2_cached_lease_break+0x27/0xb0 Read of size 8 at addr ffff88811cc24c10 by task kworker/3:1/65
CPU: 3 UID: 0 PID: 65 Comm: kworker/3:1 Not tainted 6.12.0-rc6-g255cf264e6e5-dirty #87 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 Workqueue: cifsiod smb2_cached_lease_break Call Trace: <TASK> dump_stack_lvl+0x77/0xb0 print_report+0xce/0x660 kasan_report+0xd3/0x110 smb2_cached_lease_break+0x27/0xb0 process_one_work+0x50a/0xc50 worker_thread+0x2ba/0x530 kthread+0x17c/0x1c0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30 </TASK>
Allocated by task 2464: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 open_cached_dir+0xa7d/0x1fb0 smb2_query_path_info+0x43c/0x6e0 cifs_get_fattr+0x346/0xf10 cifs_get_inode_info+0x157/0x210 cifs_revalidate_dentry_attr+0x2d1/0x460 cifs_getattr+0x173/0x470 vfs_statx_path+0x10f/0x160 vfs_statx+0xe9/0x150 vfs_fstatat+0x5e/0xc0 __do_sys_newfstatat+0x91/0xf0 do_syscall_64+0x95/0x1a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e
Freed by task 2464: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x51/0x70 kfree+0x174/0x520 open_cached_dir+0x97f/0x1fb0 smb2_query_path_info+0x43c/0x6e0 cifs_get_fattr+0x346/0xf10 cifs_get_inode_info+0x157/0x210 cifs_revalidate_dentry_attr+0x2d1/0x460 cifs_getattr+0x173/0x470 vfs_statx_path+0x10f/0x160 vfs_statx+0xe9/0x150 vfs_fstatat+0x5e/0xc0 __do_sys_newfstatat+0x91/0xf0 do_syscall_64+0x95/0x1a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e
Last potentially related work creation: kasan_save_stack+0x33/0x60 __kasan_record_aux_stack+0xad/0xc0 insert_work+0x32/0x100 __queue_work+0x5c9/0x870 queue_work_on+0x82/0x90 open_cached_dir+0x1369/0x1fb0 smb2_query_path_info+0x43c/0x6e0 cifs_get_fattr+0x346/0xf10 cifs_get_inode_info+0x157/0x210 cifs_revalidate_dentry_attr+0x2d1/0x460 cifs_getattr+0x173/0x470 vfs_statx_path+0x10f/0x160 vfs_statx+0xe9/0x150 vfs_fstatat+0x5e/0xc0 __do_sys_newfstatat+0x91/0xf0 do_syscall_64+0x95/0x1a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e
The buggy address belongs to the object at ffff88811cc24c00 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 16 bytes inside of freed 1024-byte region [ffff88811cc24c00, ffff88811cc25000)(CVE-2024-53177)
In the Linux kernel, the following vulnerability has been resolved:
smb: Don't leak cfid when reconnect races with open_cached_dir
open_cached_dir() may either race with the tcon reconnection even before compound_send_recv() or directly trigger a reconnection via SMB2_open_init() or SMB_query_info_init().
The reconnection process invokes invalidate_all_cached_dirs() via cifs_mark_open_files_invalid(), which removes all cfids from the cfids->entries list but doesn't drop a ref if has_lease isn't true. This results in the currently-being-constructed cfid not being on the list, but still having a refcount of 2. It leaks if returned from open_cached_dir().
Fix this by setting cfid->has_lease when the ref is actually taken; the cfid will not be used by other threads until it has a valid time.
Addresses these kmemleaks:
unreferenced object 0xffff8881090c4000 (size 1024): comm "bash", pid 1860, jiffies 4295126592 hex dump (first 32 bytes): 00 01 00 00 00 00 ad de 22 01 00 00 00 00 ad de ........"....... 00 ca 45 22 81 88 ff ff f8 dc 4f 04 81 88 ff ff ..E"......O..... backtrace (crc 6f58c20f): [<ffffffff8b895a1e>] __kmalloc_cache_noprof+0x2be/0x350 [<ffffffff8bda06e3>] open_cached_dir+0x993/0x1fb0 [<ffffffff8bdaa750>] cifs_readdir+0x15a0/0x1d50 [<ffffffff8b9a853f>] iterate_dir+0x28f/0x4b0 [<ffffffff8b9a9aed>] __x64_sys_getdents64+0xfd/0x200 [<ffffffff8cf6da05>] do_syscall_64+0x95/0x1a0 [<ffffffff8d00012f>] entry_SYSCALL_64_after_hwframe+0x76/0x7e unreferenced object 0xffff8881044fdcf8 (size 8): comm "bash", pid 1860, jiffies 4295126592 hex dump (first 8 bytes): 00 cc cc cc cc cc cc cc ........ backtrace (crc 10c106a9): [<ffffffff8b89a3d3>] __kmalloc_node_track_caller_noprof+0x363/0x480 [<ffffffff8b7d7256>] kstrdup+0x36/0x60 [<ffffffff8bda0700>] open_cached_dir+0x9b0/0x1fb0 [<ffffffff8bdaa750>] cifs_readdir+0x15a0/0x1d50 [<ffffffff8b9a853f>] iterate_dir+0x28f/0x4b0 [<ffffffff8b9a9aed>] __x64_sys_getdents64+0xfd/0x200 [<ffffffff8cf6da05>] do_syscall_64+0x95/0x1a0 [<ffffffff8d00012f>] entry_SYSCALL_64_after_hwframe+0x76/0x7e
And addresses these BUG splats when unmounting the SMB filesystem:
BUG: Dentry ffff888140590ba0{i=1000000000080,n=/} still in use (2) [unmount of cifs cifs] WARNING: CPU: 3 PID: 3433 at fs/dcache.c:1536 umount_check+0xd0/0x100 Modules linked in: CPU: 3 UID: 0 PID: 3433 Comm: bash Not tainted 6.12.0-rc4-g850925a8133c-dirty #49 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 RIP: 0010:umount_check+0xd0/0x100 Code: 8d 7c 24 40 e8 31 5a f4 ff 49 8b 54 24 40 41 56 49 89 e9 45 89 e8 48 89 d9 41 57 48 89 de 48 c7 c7 80 e7 db ac e8 f0 72 9a ff <0f> 0b 58 31 c0 5a 5b 5d 41 5c 41 5d 41 5e 41 5f e9 2b e5 5d 01 41 RSP: 0018:ffff88811cc27978 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff888140590ba0 RCX: ffffffffaaf20bae RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff8881f6fb6f40 RBP: ffff8881462ec000 R08: 0000000000000001 R09: ffffed1023984ee3 R10: ffff88811cc2771f R11: 00000000016cfcc0 R12: ffff888134383e08 R13: 0000000000000002 R14: ffff8881462ec668 R15: ffffffffaceab4c0 FS: 00007f23bfa98740(0000) GS:ffff8881f6f80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000556de4a6f808 CR3: 0000000123c80000 CR4: 0000000000350ef0 Call Trace: <TASK> d_walk+0x6a/0x530 shrink_dcache_for_umount+0x6a/0x200 generic_shutdown_super+0x52/0x2a0 kill_anon_super+0x22/0x40 cifs_kill_sb+0x159/0x1e0 deactivate_locked_super+0x66/0xe0 cleanup_mnt+0x140/0x210 task_work_run+0xfb/0x170 syscall_exit_to_user_mode+0x29f/0x2b0 do_syscall_64+0xa1/0x1a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f23bfb93ae7 Code: ff ff ff ff c3 66 0f 1f 44 00 00 48 8b 0d 11 93 0d 00 f7 d8 64 89 01 b8 ff ff ff ff eb bf 0f 1f 44 00 00 b8 50 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d e9 92 0d 00 f7 d8 64 89 ---truncated---(CVE-2024-53178)
In the Linux kernel, the following vulnerability has been resolved:
um: vector: Do not use drvdata in release
The drvdata is not available in release. Let's just use container_of() to get the vector_device instance. Otherwise, removing a vector device will result in a crash:
RIP: 0033:vector_device_release+0xf/0x50 RSP: 00000000e187bc40 EFLAGS: 00010202 RAX: 0000000060028f61 RBX: 00000000600f1baf RCX: 00000000620074e0 RDX: 000000006220b9c0 RSI: 0000000060551c80 RDI: 0000000000000000 RBP: 00000000e187bc50 R08: 00000000603ad594 R09: 00000000e187bb70 R10: 000000000000135a R11: 00000000603ad422 R12: 00000000623ae028 R13: 000000006287a200 R14: 0000000062006d30 R15: 00000000623700b6 Kernel panic - not syncing: Segfault with no mm CPU: 0 UID: 0 PID: 16 Comm: kworker/0:1 Not tainted 6.12.0-rc6-g59b723cd2adb #1 Workqueue: events mc_work_proc Stack: 60028f61 623ae028 e187bc80 60276fcd 6220b9c0 603f5820 623ae028 00000000 e187bcb0 603a2bcd 623ae000 62370010 Call Trace: [<60028f61>] ? vector_device_release+0x0/0x50 [<60276fcd>] device_release+0x70/0xba [<603a2bcd>] kobject_put+0xba/0xe7 [<60277265>] put_device+0x19/0x1c [<60281266>] platform_device_put+0x26/0x29 [<60281e5f>] platform_device_unregister+0x2c/0x2e [<60029422>] vector_remove+0x52/0x58 [<60031316>] ? mconsole_reply+0x0/0x50 [<600310c8>] mconsole_remove+0x160/0x1cc [<603b19f4>] ? strlen+0x0/0x15 [<60066611>] ? __dequeue_entity+0x1a9/0x206 [<600666a7>] ? set_next_entity+0x39/0x63 [<6006666e>] ? set_next_entity+0x0/0x63 [<60038fa6>] ? um_set_signals+0x0/0x43 [<6003070c>] mc_work_proc+0x77/0x91 [<60057664>] process_scheduled_works+0x1b3/0x2dd [<60055f32>] ? assign_work+0x0/0x58 [<60057f0a>] worker_thread+0x1e9/0x293 [<6005406f>] ? set_pf_worker+0x0/0x64 [<6005d65d>] ? arch_local_irq_save+0x0/0x2d [<6005d748>] ? kthread_exit+0x0/0x3a [<60057d21>] ? worker_thread+0x0/0x293 [<6005dbf1>] kthread+0x126/0x12b [<600219c5>] new_thread_handler+0x85/0xb6(CVE-2024-53181)
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix NULL ptr deref in crypto_aead_setkey()
Neither SMB3.0 or SMB3.02 supports encryption negotiate context, so when SMB2_GLOBAL_CAP_ENCRYPTION flag is set in the negotiate response, the client uses AES-128-CCM as the default cipher. See MS-SMB2 3.3.5.4.
Commit b0abcd65ec54 ("smb: client: fix UAF in async decryption") added a @server->cipher_type check to conditionally call smb3_crypto_aead_allocate(), but that check would always be false as @server->cipher_type is unset for SMB3.02.
Fix the following KASAN splat by setting @server->cipher_type for SMB3.02 as well.
mount.cifs //srv/share /mnt -o vers=3.02,seal,...
BUG: KASAN: null-ptr-deref in crypto_aead_setkey+0x2c/0x130 Read of size 8 at addr 0000000000000020 by task mount.cifs/1095 CPU: 1 UID: 0 PID: 1095 Comm: mount.cifs Not tainted 6.12.0 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-3.fc41 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x5d/0x80 ? crypto_aead_setkey+0x2c/0x130 kasan_report+0xda/0x110 ? crypto_aead_setkey+0x2c/0x130 crypto_aead_setkey+0x2c/0x130 crypt_message+0x258/0xec0 [cifs] ? __asan_memset+0x23/0x50 ? __pfx_crypt_message+0x10/0x10 [cifs] ? mark_lock+0xb0/0x6a0 ? hlock_class+0x32/0xb0 ? mark_lock+0xb0/0x6a0 smb3_init_transform_rq+0x352/0x3f0 [cifs] ? lock_acquire.part.0+0xf4/0x2a0 smb_send_rqst+0x144/0x230 [cifs] ? __pfx_smb_send_rqst+0x10/0x10 [cifs] ? hlock_class+0x32/0xb0 ? smb2_setup_request+0x225/0x3a0 [cifs] ? __pfx_cifs_compound_last_callback+0x10/0x10 [cifs] compound_send_recv+0x59b/0x1140 [cifs] ? __pfx_compound_send_recv+0x10/0x10 [cifs] ? __create_object+0x5e/0x90 ? hlock_class+0x32/0xb0 ? do_raw_spin_unlock+0x9a/0xf0 cifs_send_recv+0x23/0x30 [cifs] SMB2_tcon+0x3ec/0xb30 [cifs] ? __pfx_SMB2_tcon+0x10/0x10 [cifs] ? lock_acquire.part.0+0xf4/0x2a0 ? __pfx_lock_release+0x10/0x10 ? do_raw_spin_trylock+0xc6/0x120 ? lock_acquire+0x3f/0x90 ? _get_xid+0x16/0xd0 [cifs] ? __pfx_SMB2_tcon+0x10/0x10 [cifs] ? cifs_get_smb_ses+0xcdd/0x10a0 [cifs] cifs_get_smb_ses+0xcdd/0x10a0 [cifs] ? __pfx_cifs_get_smb_ses+0x10/0x10 [cifs] ? cifs_get_tcp_session+0xaa0/0xca0 [cifs] cifs_mount_get_session+0x8a/0x210 [cifs] dfs_mount_share+0x1b0/0x11d0 [cifs] ? __pfxlockacquire+0x10/0x10 ? pfx_dfs_mount_share+0x10/0x10 [cifs] ? lock_acquire.part.0+0xf4/0x2a0 ? find_held_lock+0x8a/0xa0 ? hlock_class+0x32/0xb0 ? lock_release+0x203/0x5d0 cifs_mount+0xb3/0x3d0 [cifs] ? do_raw_spin_trylock+0xc6/0x120 ? __pfx_cifs_mount+0x10/0x10 [cifs] ? lock_acquire+0x3f/0x90 ? find_nls+0x16/0xa0 ? smb3_update_mnt_flags+0x372/0x3b0 [cifs] cifs_smb3_do_mount+0x1e2/0xc80 [cifs] ? __pfx_vfs_parse_fs_string+0x10/0x10 ? __pfx_cifs_smb3_do_mount+0x10/0x10 [cifs] smb3_get_tree+0x1bf/0x330 [cifs] vfs_get_tree+0x4a/0x160 path_mount+0x3c1/0xfb0 ? kasan_quarantine_put+0xc7/0x1d0 ? __pfx_path_mount+0x10/0x10 ? kmem_cache_free+0x118/0x3e0 ? user_path_at+0x74/0xa0 __x64_sys_mount+0x1a6/0x1e0 ? __pfx___x64_sys_mount+0x10/0x10 ? mark_held_locks+0x1a/0x90 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2024-53185)
In the Linux kernel, the following vulnerability has been resolved:
s390/iucv: MSG_PEEK causes memory leak in iucv_sock_destruct()
Passing MSG_PEEK flag to skb_recv_datagram() increments skb refcount (skb->users) and iucv_sock_recvmsg() does not decrement skb refcount at exit. This results in skb memory leak in skb_queue_purge() and WARN_ON in iucv_sock_destruct() during socket close. To fix this decrease skb refcount by one if MSG_PEEK is set in order to prevent memory leak and WARN_ON.
WARNING: CPU: 2 PID: 6292 at net/iucv/af_iucv.c:286 iucv_sock_destruct+0x144/0x1a0 [af_iucv] CPU: 2 PID: 6292 Comm: afiucv_test_msg Kdump: loaded Tainted: G W 6.10.0-rc7 #1 Hardware name: IBM 3931 A01 704 (z/VM 7.3.0) Call Trace: [<001587c682c4aa98>] iucv_sock_destruct+0x148/0x1a0 [af_iucv] [<001587c682c4a9d0>] iucv_sock_destruct+0x80/0x1a0 [af_iucv] [<001587c704117a32>] __sk_destruct+0x52/0x550 [<001587c704104a54>] __sock_release+0xa4/0x230 [<001587c704104c0c>] sock_close+0x2c/0x40 [<001587c702c5f5a8>] __fput+0x2e8/0x970 [<001587c7024148c4>] task_work_run+0x1c4/0x2c0 [<001587c7023b0716>] do_exit+0x996/0x1050 [<001587c7023b13aa>] do_group_exit+0x13a/0x360 [<001587c7023b1626>] __s390x_sys_exit_group+0x56/0x60 [<001587c7022bccca>] do_syscall+0x27a/0x380 [<001587c7049a6a0c>] __do_syscall+0x9c/0x160 [<001587c7049ce8a8>] system_call+0x70/0x98 Last Breaking-Event-Address: [<001587c682c4a9d4>] iucv_sock_destruct+0x84/0x1a0 af_iucv
In the Linux kernel, the following vulnerability has been resolved:
vfio/pci: Properly hide first-in-list PCIe extended capability
There are cases where a PCIe extended capability should be hidden from the user. For example, an unknown capability (i.e., capability with ID greater than PCI_EXT_CAP_ID_MAX) or a capability that is intentionally chosen to be hidden from the user.
Hiding a capability is done by virtualizing and modifying the 'Next Capability Offset' field of the previous capability so it points to the capability after the one that should be hidden.
The special case where the first capability in the list should be hidden is handled differently because there is no previous capability that can be modified. In this case, the capability ID and version are zeroed while leaving the next pointer intact. This hides the capability and leaves an anchor for the rest of the capability list.
However, today, hiding the first capability in the list is not done properly if the capability is unknown, as struct vfio_pci_core_device->pci_config_map is set to the capability ID during initialization but the capability ID is not properly checked later when used in vfio_config_do_rw(). This leads to the following warning [1] and to an out-of-bounds access to ecap_perms array.
Fix it by checking cap_id in vfio_config_do_rw(), and if it is greater than PCI_EXT_CAP_ID_MAX, use an alternative struct perm_bits for direct read only access instead of the ecap_perms array.
Note that this is safe since the above is the only case where cap_id can exceed PCI_EXT_CAP_ID_MAX (except for the special capabilities, which are already checked before).
[1]
WARNING: CPU: 118 PID: 5329 at drivers/vfio/pci/vfio_pci_config.c:1900 vfio_pci_config_rw+0x395/0x430 [vfio_pci_core] CPU: 118 UID: 0 PID: 5329 Comm: simx-qemu-syste Not tainted 6.12.0+ #1 (snip) Call Trace: <TASK> ? show_regs+0x69/0x80 ? __warn+0x8d/0x140 ? vfio_pci_config_rw+0x395/0x430 [vfio_pci_core] ? report_bug+0x18f/0x1a0 ? handle_bug+0x63/0xa0 ? exc_invalid_op+0x19/0x70 ? asm_exc_invalid_op+0x1b/0x20 ? vfio_pci_config_rw+0x395/0x430 [vfio_pci_core] ? vfio_pci_config_rw+0x244/0x430 [vfio_pci_core] vfio_pci_rw+0x101/0x1b0 [vfio_pci_core] vfio_pci_core_read+0x1d/0x30 [vfio_pci_core] vfio_device_fops_read+0x27/0x40 [vfio] vfs_read+0xbd/0x340 ? vfio_device_fops_unl_ioctl+0xbb/0x740 [vfio] ? __rseq_handle_notify_resume+0xa4/0x4b0 __x64_sys_pread64+0x96/0xc0 x64_sys_call+0x1c3d/0x20d0 do_syscall_64+0x4d/0x120 entry_SYSCALL_64_after_hwframe+0x76/0x7e(CVE-2024-53214)
In the Linux kernel, the following vulnerability has been resolved:
nfsd: release svc_expkey/svc_export with rcu_work
The last reference for cache_head can be reduced to zero in c_show
and e_show(using rcu_read_lock and rcu_read_unlock). Consequently,
svc_export_put and expkey_put will be invoked, leading to two
issues:
- The
svc_export_putwill directly free ex_uuid. However,e_show/c_showwill accessex_uuidaftercache_put, which can trigger a use-after-free issue, shown below.
================================================================== BUG: KASAN: slab-use-after-free in svc_export_show+0x362/0x430 [nfsd] Read of size 1 at addr ff11000010fdc120 by task cat/870
CPU: 1 UID: 0 PID: 870 Comm: cat Not tainted 6.12.0-rc3+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x53/0x70 print_address_description.constprop.0+0x2c/0x3a0 print_report+0xb9/0x280 kasan_report+0xae/0xe0 svc_export_show+0x362/0x430 [nfsd] c_show+0x161/0x390 [sunrpc] seq_read_iter+0x589/0x770 seq_read+0x1e5/0x270 proc_reg_read+0xe1/0x140 vfs_read+0x125/0x530 ksys_read+0xc1/0x160 do_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e
Allocated by task 830: kasan_save_stack+0x20/0x40 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0 __kmalloc_node_track_caller_noprof+0x1bc/0x400 kmemdup_noprof+0x22/0x50 svc_export_parse+0x8a9/0xb80 [nfsd] cache_do_downcall+0x71/0xa0 [sunrpc] cache_write_procfs+0x8e/0xd0 [sunrpc] proc_reg_write+0xe1/0x140 vfs_write+0x1a5/0x6d0 ksys_write+0xc1/0x160 do_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e
Freed by task 868: kasan_save_stack+0x20/0x40 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x37/0x50 kfree+0xf3/0x3e0 svc_export_put+0x87/0xb0 [nfsd] cache_purge+0x17f/0x1f0 [sunrpc] nfsd_destroy_serv+0x226/0x2d0 [nfsd] nfsd_svc+0x125/0x1e0 [nfsd] write_threads+0x16a/0x2a0 [nfsd] nfsctl_transaction_write+0x74/0xa0 [nfsd] vfs_write+0x1a5/0x6d0 ksys_write+0xc1/0x160 do_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e
- We cannot sleep while using
rcu_read_lock/rcu_read_unlock. However,svc_export_put/expkey_putwill call path_put, which subsequently triggers a sleeping operation due to the followingdput.
============================= WARNING: suspicious RCU usage 5.10.0-dirty #141 Not tainted
... Call Trace: dump_stack+0x9a/0xd0 ___might_sleep+0x231/0x240 dput+0x39/0x600 path_put+0x1b/0x30 svc_export_put+0x17/0x80 e_show+0x1c9/0x200 seq_read_iter+0x63f/0x7c0 seq_read+0x226/0x2d0 vfs_read+0x113/0x2c0 ksys_read+0xc9/0x170 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x67/0xd1
Fix these issues by using rcu_work to help release
svc_expkey/svc_export. This approach allows for an asynchronous
context to invoke path_put and also facilitates the freeing of
uuid/exp/key after an RCU grace period.(CVE-2024-53216)
In the Linux kernel, the following vulnerability has been resolved:
unicode: Fix utf8_load() error path
utf8_load() requests the symbol "utf8_data_table" and then checks if the requested UTF-8 version is supported. If it's unsupported, it tries to put the data table using symbol_put(). If an unsupported version is requested, symbol_put() fails like this:
kernel BUG at kernel/module/main.c:786! RIP: 0010:__symbol_put+0x93/0xb0 Call Trace: <TASK> ? __die_body.cold+0x19/0x27 ? die+0x2e/0x50 ? do_trap+0xca/0x110 ? do_error_trap+0x65/0x80 ? __symbol_put+0x93/0xb0 ? exc_invalid_op+0x51/0x70 ? __symbol_put+0x93/0xb0 ? asm_exc_invalid_op+0x1a/0x20 ? __pfx_cmp_name+0x10/0x10 ? __symbol_put+0x93/0xb0 ? __symbol_put+0x62/0xb0 utf8_load+0xf8/0x150
That happens because symbol_put() expects the unique string that identify the symbol, instead of a pointer to the loaded symbol. Fix that by using such string.(CVE-2024-53233)
In the Linux kernel, the following vulnerability has been resolved:
NFS: Fix potential buffer overflowin nfs_sysfs_link_rpc_client()
name is char[64] where the size of clnt->cl_program->name remains unknown. Invoking strcat() directly will also lead to potential buffer overflow. Change them to strscpy() and strncat() to fix potential issues.(CVE-2024-54456)
In the Linux kernel, the following vulnerability has been resolved:
ALSA: caiaq: Use snd_card_free_when_closed() at disconnection
The USB disconnect callback is supposed to be short and not too-long waiting. OTOH, the current code uses snd_card_free() at disconnection, but this waits for the close of all used fds, hence it can take long. It eventually blocks the upper layer USB ioctls, which may trigger a soft lockup.
An easy workaround is to replace snd_card_free() with snd_card_free_when_closed(). This variant returns immediately while the release of resources is done asynchronously by the card device release at the last close.
This patch also splits the code to the disconnect and the free phases; the former is called immediately at the USB disconnect callback while the latter is called from the card destructor.(CVE-2024-56531)
In the Linux kernel, the following vulnerability has been resolved:
ALSA: usx2y: Use snd_card_free_when_closed() at disconnection
The USB disconnect callback is supposed to be short and not too-long waiting. OTOH, the current code uses snd_card_free() at disconnection, but this waits for the close of all used fds, hence it can take long. It eventually blocks the upper layer USB ioctls, which may trigger a soft lockup.
An easy workaround is to replace snd_card_free() with snd_card_free_when_closed(). This variant returns immediately while the release of resources is done asynchronously by the card device release at the last close.(CVE-2024-56533)
In the Linux kernel, the following vulnerability has been resolved:
wifi: mwifiex: Fix memcpy() field-spanning write warning in mwifiex_config_scan()
Replace one-element array with a flexible-array member in struct
mwifiex_ie_types_wildcard_ssid_params to fix the following warning
on a MT8173 Chromebook (mt8173-elm-hana):
[ 356.775250] ------------[ cut here ]------------ [ 356.784543] memcpy: detected field-spanning write (size 6) of single field "wildcard_ssid_tlv->ssid" at drivers/net/wireless/marvell/mwifiex/scan.c:904 (size 1) [ 356.813403] WARNING: CPU: 3 PID: 742 at drivers/net/wireless/marvell/mwifiex/scan.c:904 mwifiex_scan_networks+0x4fc/0xf28 [mwifiex]
The "(size 6)" above is exactly the length of the SSID of the network this device was connected to. The source of the warning looks like:
ssid_len = user_scan_in->ssid_list[i].ssid_len;
[...]
memcpy(wildcard_ssid_tlv->ssid,
user_scan_in->ssid_list[i].ssid, ssid_len);
There is a #define WILDCARD_SSID_TLV_MAX_SIZE that uses sizeof() on this struct, but it already didn't account for the size of the one-element array, so it doesn't need to be changed.(CVE-2024-56539)
In the Linux kernel, the following vulnerability has been resolved:
HID: hyperv: streamline driver probe to avoid devres issues
It was found that unloading 'hid_hyperv' module results in a devres complaint:
... hv_vmbus: unregistering driver hid_hyperv ------------[ cut here ]------------ WARNING: CPU: 2 PID: 3983 at drivers/base/devres.c:691 devres_release_group+0x1f2/0x2c0 ... Call Trace: <TASK> ? devres_release_group+0x1f2/0x2c0 ? __warn+0xd1/0x1c0 ? devres_release_group+0x1f2/0x2c0 ? report_bug+0x32a/0x3c0 ? handle_bug+0x53/0xa0 ? exc_invalid_op+0x18/0x50 ? asm_exc_invalid_op+0x1a/0x20 ? devres_release_group+0x1f2/0x2c0 ? devres_release_group+0x90/0x2c0 ? rcu_is_watching+0x15/0xb0 ? __pfx_devres_release_group+0x10/0x10 hid_device_remove+0xf5/0x220 device_release_driver_internal+0x371/0x540 ? klist_put+0xf3/0x170 bus_remove_device+0x1f1/0x3f0 device_del+0x33f/0x8c0 ? __pfx_device_del+0x10/0x10 ? cleanup_srcu_struct+0x337/0x500 hid_destroy_device+0xc8/0x130 mousevsc_remove+0xd2/0x1d0 [hid_hyperv] device_release_driver_internal+0x371/0x540 driver_detach+0xc5/0x180 bus_remove_driver+0x11e/0x2a0 ? __mutex_unlock_slowpath+0x160/0x5e0 vmbus_driver_unregister+0x62/0x2b0 [hv_vmbus] ...
And the issue seems to be that the corresponding devres group is not allocated. Normally, devres_open_group() is called from __hid_device_probe() but Hyper-V HID driver overrides 'hid_dev->driver' with 'mousevsc_hid_driver' stub and basically re-implements __hid_device_probe() by calling hid_parse() and hid_hw_start() but not devres_open_group(). hid_device_probe() does not call __hid_device_probe() for it. Later, when the driver is removed, hid_device_remove() calls devres_release_group() as it doesn't check whether hdev->driver was initially overridden or not.
The issue seems to be related to the commit 62c68e7cee33 ("HID: ensure timely release of driver-allocated resources") but the commit itself seems to be correct.
Fix the issue by dropping the 'hid_dev->driver' override and using hid_register_driver()/hid_unregister_driver() instead. Alternatively, it would have been possible to rely on the default handling but HID_CONNECT_DEFAULT implies HID_CONNECT_HIDRAW and it doesn't seem to work for mousevsc as-is.(CVE-2024-56545)
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: fix usage slab after free
[ +0.000021] BUG: KASAN: slab-use-after-free in drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched] [ +0.000027] Read of size 8 at addr ffff8881b8605f88 by task amd_pci_unplug/2147
[ +0.000023] CPU: 6 PID: 2147 Comm: amd_pci_unplug Not tainted 6.10.0+ #1 [ +0.000016] Hardware name: ASUS System Product Name/ROG STRIX B550-F GAMING (WI-FI), BIOS 1401 12/03/2020 [ +0.000016] Call Trace: [ +0.000008] <TASK> [ +0.000009] dump_stack_lvl+0x76/0xa0 [ +0.000017] print_report+0xce/0x5f0 [ +0.000017] ? drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched] [ +0.000019] ? srso_return_thunk+0x5/0x5f [ +0.000015] ? kasan_complete_mode_report_info+0x72/0x200 [ +0.000016] ? drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched] [ +0.000019] kasan_report+0xbe/0x110 [ +0.000015] ? drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched] [ +0.000023] __asan_report_load8_noabort+0x14/0x30 [ +0.000014] drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched] [ +0.000020] ? srso_return_thunk+0x5/0x5f [ +0.000013] ? __kasan_check_write+0x14/0x30 [ +0.000016] ? __pfx_drm_sched_entity_flush+0x10/0x10 [gpu_sched] [ +0.000020] ? srso_return_thunk+0x5/0x5f [ +0.000013] ? __kasan_check_write+0x14/0x30 [ +0.000013] ? srso_return_thunk+0x5/0x5f [ +0.000013] ? enable_work+0x124/0x220 [ +0.000015] ? __pfx_enable_work+0x10/0x10 [ +0.000013] ? srso_return_thunk+0x5/0x5f [ +0.000014] ? free_large_kmalloc+0x85/0xf0 [ +0.000016] drm_sched_entity_destroy+0x18/0x30 [gpu_sched] [ +0.000020] amdgpu_vce_sw_fini+0x55/0x170 [amdgpu] [ +0.000735] ? __kasan_check_read+0x11/0x20 [ +0.000016] vce_v4_0_sw_fini+0x80/0x110 [amdgpu] [ +0.000726] amdgpu_device_fini_sw+0x331/0xfc0 [amdgpu] [ +0.000679] ? mutex_unlock+0x80/0xe0 [ +0.000017] ? __pfx_amdgpu_device_fini_sw+0x10/0x10 [amdgpu] [ +0.000662] ? srso_return_thunk+0x5/0x5f [ +0.000014] ? __kasan_check_write+0x14/0x30 [ +0.000013] ? srso_return_thunk+0x5/0x5f [ +0.000013] ? mutex_unlock+0x80/0xe0 [ +0.000016] amdgpu_driver_release_kms+0x16/0x80 [amdgpu] [ +0.000663] drm_minor_release+0xc9/0x140 [drm] [ +0.000081] drm_release+0x1fd/0x390 [drm] [ +0.000082] __fput+0x36c/0xad0 [ +0.000018] __fput_sync+0x3c/0x50 [ +0.000014] __x64_sys_close+0x7d/0xe0 [ +0.000014] x64_sys_call+0x1bc6/0x2680 [ +0.000014] do_syscall_64+0x70/0x130 [ +0.000014] ? srso_return_thunk+0x5/0x5f [ +0.000014] ? irqentry_exit_to_user_mode+0x60/0x190 [ +0.000015] ? srso_return_thunk+0x5/0x5f [ +0.000014] ? irqentry_exit+0x43/0x50 [ +0.000012] ? srso_return_thunk+0x5/0x5f [ +0.000013] ? exc_page_fault+0x7c/0x110 [ +0.000015] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ +0.000014] RIP: 0033:0x7ffff7b14f67 [ +0.000013] Code: ff e8 0d 16 02 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 41 c3 48 83 ec 18 89 7c 24 0c e8 73 ba f7 ff [ +0.000026] RSP: 002b:00007fffffffe378 EFLAGS: 00000246 ORIG_RAX: 0000000000000003 [ +0.000019] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007ffff7b14f67 [ +0.000014] RDX: 0000000000000000 RSI: 00007ffff7f6f47a RDI: 0000000000000003 [ +0.000014] RBP: 00007fffffffe3a0 R08: 0000555555569890 R09: 0000000000000000 [ +0.000014] R10: 0000000000000000 R11: 0000000000000246 R12: 00007fffffffe5c8 [ +0.000013] R13: 00005555555552a9 R14: 0000555555557d48 R15: 00007ffff7ffd040 [ +0.000020] </TASK>
[ +0.000016] Allocated by task 383 on cpu 7 at 26.880319s: [ +0.000014] kasan_save_stack+0x28/0x60 [ +0.000008] kasan_save_track+0x18/0x70 [ +0.000007] kasan_save_alloc_info+0x38/0x60 [ +0.000007] __kasan_kmalloc+0xc1/0xd0 [ +0.000007] kmalloc_trace_noprof+0x180/0x380 [ +0.000007] drm_sched_init+0x411/0xec0 [gpu_sched] [ +0.000012] amdgpu_device_init+0x695f/0xa610 [amdgpu] [ +0.000658] amdgpu_driver_load_kms+0x1a/0x120 [amdgpu] [ +0.000662] amdgpu_pci_p ---truncated---(CVE-2024-56551)
In the Linux kernel, the following vulnerability has been resolved:
nfsd: make sure exp active before svc_export_show
The function e_show was called with protection from RCU. This only
ensures that exp will not be freed. Therefore, the reference count for
exp can drop to zero, which will trigger a refcount use-after-free
warning when exp_get is called. To resolve this issue, use
cache_get_rcu to ensure that exp remains active.
------------[ cut here ]------------ refcount_t: addition on 0; use-after-free. WARNING: CPU: 3 PID: 819 at lib/refcount.c:25 refcount_warn_saturate+0xb1/0x120 CPU: 3 UID: 0 PID: 819 Comm: cat Not tainted 6.12.0-rc3+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 RIP: 0010:refcount_warn_saturate+0xb1/0x120 ... Call Trace: <TASK> e_show+0x20b/0x230 [nfsd] seq_read_iter+0x589/0x770 seq_read+0x1e5/0x270 vfs_read+0x125/0x530 ksys_read+0xc1/0x160 do_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e(CVE-2024-56558)
In the Linux kernel, the following vulnerability has been resolved:
mm/slub: Avoid list corruption when removing a slab from the full list
Boot with slub_debug=UFPZ.
If allocated object failed in alloc_consistency_checks, all objects of the slab will be marked as used, and then the slab will be removed from the partial list.
When an object belonging to the slab got freed later, the remove_full() function is called. Because the slab is neither on the partial list nor on the full list, it eventually lead to a list corruption (actually a list poison being detected).
So we need to mark and isolate the slab page with metadata corruption, do not put it back in circulation.
Because the debug caches avoid all the fastpaths, reusing the frozen bit to mark slab page with metadata corruption seems to be fine.
[ 4277.385669] list_del corruption, ffffea00044b3e50->next is LIST_POISON1 (dead000000000100) [ 4277.387023] ------------[ cut here ]------------ [ 4277.387880] kernel BUG at lib/list_debug.c:56! [ 4277.388680] invalid opcode: 0000 [#1] PREEMPT SMP PTI [ 4277.389562] CPU: 5 PID: 90 Comm: kworker/5:1 Kdump: loaded Tainted: G OE 6.6.1-1 #1 [ 4277.392113] Workqueue: xfs-inodegc/vda1 xfs_inodegc_worker [xfs] [ 4277.393551] RIP: 0010:__list_del_entry_valid_or_report+0x7b/0xc0 [ 4277.394518] Code: 48 91 82 e8 37 f9 9a ff 0f 0b 48 89 fe 48 c7 c7 28 49 91 82 e8 26 f9 9a ff 0f 0b 48 89 fe 48 c7 c7 58 49 91 [ 4277.397292] RSP: 0018:ffffc90000333b38 EFLAGS: 00010082 [ 4277.398202] RAX: 000000000000004e RBX: ffffea00044b3e50 RCX: 0000000000000000 [ 4277.399340] RDX: 0000000000000002 RSI: ffffffff828f8715 RDI: 00000000ffffffff [ 4277.400545] RBP: ffffea00044b3e40 R08: 0000000000000000 R09: ffffc900003339f0 [ 4277.401710] R10: 0000000000000003 R11: ffffffff82d44088 R12: ffff888112cf9910 [ 4277.402887] R13: 0000000000000001 R14: 0000000000000001 R15: ffff8881000424c0 [ 4277.404049] FS: 0000000000000000(0000) GS:ffff88842fd40000(0000) knlGS:0000000000000000 [ 4277.405357] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 4277.406389] CR2: 00007f2ad0b24000 CR3: 0000000102a3a006 CR4: 00000000007706e0 [ 4277.407589] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 4277.408780] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 4277.410000] PKRU: 55555554 [ 4277.410645] Call Trace: [ 4277.411234] <TASK> [ 4277.411777] ? die+0x32/0x80 [ 4277.412439] ? do_trap+0xd6/0x100 [ 4277.413150] ? __list_del_entry_valid_or_report+0x7b/0xc0 [ 4277.414158] ? do_error_trap+0x6a/0x90 [ 4277.414948] ? __list_del_entry_valid_or_report+0x7b/0xc0 [ 4277.415915] ? exc_invalid_op+0x4c/0x60 [ 4277.416710] ? __list_del_entry_valid_or_report+0x7b/0xc0 [ 4277.417675] ? asm_exc_invalid_op+0x16/0x20 [ 4277.418482] ? __list_del_entry_valid_or_report+0x7b/0xc0 [ 4277.419466] ? __list_del_entry_valid_or_report+0x7b/0xc0 [ 4277.420410] free_to_partial_list+0x515/0x5e0 [ 4277.421242] ? xfs_iext_remove+0x41a/0xa10 [xfs] [ 4277.422298] xfs_iext_remove+0x41a/0xa10 [xfs] [ 4277.423316] ? xfs_inodegc_worker+0xb4/0x1a0 [xfs] [ 4277.424383] xfs_bmap_del_extent_delay+0x4fe/0x7d0 [xfs] [ 4277.425490] __xfs_bunmapi+0x50d/0x840 [xfs] [ 4277.426445] xfs_itruncate_extents_flags+0x13a/0x490 [xfs] [ 4277.427553] xfs_inactive_truncate+0xa3/0x120 [xfs] [ 4277.428567] xfs_inactive+0x22d/0x290 [xfs] [ 4277.429500] xfs_inodegc_worker+0xb4/0x1a0 [xfs] [ 4277.430479] process_one_work+0x171/0x340 [ 4277.431227] worker_thread+0x277/0x390 [ 4277.431962] ? __pfx_worker_thread+0x10/0x10 [ 4277.432752] kthread+0xf0/0x120 [ 4277.433382] ? __pfx_kthread+0x10/0x10 [ 4277.434134] ret_from_fork+0x2d/0x50 [ 4277.434837] ? __pfx_kthread+0x10/0x10 [ 4277.435566] ret_from_fork_asm+0x1b/0x30 [ 4277.436280] </TASK>(CVE-2024-56566)
In the Linux kernel, the following vulnerability has been resolved:
efi/libstub: Free correct pointer on failure
cmdline_ptr is an out parameter, which is not allocated by the function itself, and likely points into the caller's stack.
cmdline refers to the pool allocation that should be freed when cleaning up after a failure, so pass this instead to free_pool().(CVE-2024-56573)
In the Linux kernel, the following vulnerability has been resolved:
media: ts2020: fix null-ptr-deref in ts2020_probe()
KASAN reported a null-ptr-deref issue when executing the following command:
# echo ts2020 0x20 > /sys/bus/i2c/devices/i2c-0/new_device KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] CPU: 53 UID: 0 PID: 970 Comm: systemd-udevd Not tainted 6.12.0-rc2+ #24 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) RIP: 0010:ts2020_probe+0xad/0xe10 [ts2020] RSP: 0018:ffffc9000abbf598 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffffc0714809 RDX: 0000000000000002 RSI: ffff88811550be00 RDI: 0000000000000010 RBP: ffff888109868800 R08: 0000000000000001 R09: fffff52001577eb6 R10: 0000000000000000 R11: ffffc9000abbff50 R12: ffffffffc0714790 R13: 1ffff92001577eb8 R14: ffffffffc07190d0 R15: 0000000000000001 FS: 00007f95f13b98c0(0000) GS:ffff888149280000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000555d2634b000 CR3: 0000000152236000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ts2020_probe+0xad/0xe10 [ts2020] i2c_device_probe+0x421/0xb40 really_probe+0x266/0x850 ...
The cause of the problem is that when using sysfs to dynamically register an i2c device, there is no platform data, but the probe process of ts2020 needs to use platform data, resulting in a null pointer being accessed.
Solve this problem by adding checks to platform data.(CVE-2024-56574)
In the Linux kernel, the following vulnerability has been resolved:
media: i2c: tc358743: Fix crash in the probe error path when using polling
If an error occurs in the probe() function, we should remove the polling timer that was alarmed earlier, otherwise the timer is called with arguments that are already freed, which results in a crash.
------------[ cut here ]------------ WARNING: CPU: 3 PID: 0 at kernel/time/timer.c:1830 __run_timers+0x244/0x268 Modules linked in: CPU: 3 UID: 0 PID: 0 Comm: swapper/3 Not tainted 6.11.0 #226 Hardware name: Diasom DS-RK3568-SOM-EVB (DT) pstate: 804000c9 (Nzcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __run_timers+0x244/0x268 lr : __run_timers+0x1d4/0x268 sp : ffffff80eff2baf0 x29: ffffff80eff2bb50 x28: 7fffffffffffffff x27: ffffff80eff2bb00 x26: ffffffc080f669c0 x25: ffffff80efef6bf0 x24: ffffff80eff2bb00 x23: 0000000000000000 x22: dead000000000122 x21: 0000000000000000 x20: ffffff80efef6b80 x19: ffffff80041c8bf8 x18: ffffffffffffffff x17: ffffffc06f146000 x16: ffffff80eff27dc0 x15: 000000000000003e x14: 0000000000000000 x13: 00000000000054da x12: 0000000000000000 x11: 00000000000639c0 x10: 000000000000000c x9 : 0000000000000009 x8 : ffffff80eff2cb40 x7 : ffffff80eff2cb40 x6 : ffffff8002bee480 x5 : ffffffc080cb2220 x4 : ffffffc080cb2150 x3 : 00000000000f4240 x2 : 0000000000000102 x1 : ffffff80eff2bb00 x0 : ffffff80041c8bf0 Call trace: __run_timers+0x244/0x268 timer_expire_remote+0x50/0x68 tmigr_handle_remote+0x388/0x39c run_timer_softirq+0x38/0x44 handle_softirqs+0x138/0x298 __do_softirq+0x14/0x20 _dosoftirq+0x10/0x1c call_on_irq_stack+0x24/0x4c do_softirq_own_stack+0x1c/0x2c irq_exit_rcu+0x9c/0xcc el1_interrupt+0x48/0xc0 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x7c/0x80 default_idle_call+0x34/0x68 do_idle+0x23c/0x294 cpu_startup_entry+0x38/0x3c secondary_start_kernel+0x128/0x160 secondary_switched+0xb8/0xbc ---[ end trace 0000000000000000 ]---(CVE-2024-56576)
In the Linux kernel, the following vulnerability has been resolved:
media: mtk-jpeg: Fix null-ptr-deref during unload module
The workqueue should be destroyed in mtk_jpeg_core.c since commit 09aea13ecf6f ("media: mtk-jpeg: refactor some variables"), otherwise the below calltrace can be easily triggered.
[ 677.862514] Unable to handle kernel paging request at virtual address dfff800000000023 [ 677.863633] KASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f] ... [ 677.879654] CPU: 6 PID: 1071 Comm: modprobe Tainted: G O 6.8.12-mtk+gfa1a78e5d24b+ #17 ... [ 677.882838] pc : destroy_workqueue+0x3c/0x770 [ 677.883413] lr : mtk_jpegdec_destroy_workqueue+0x70/0x88 [mtk_jpeg_dec_hw] [ 677.884314] sp : ffff80008ad974f0 [ 677.884744] x29: ffff80008ad974f0 x28: ffff0000d7115580 x27: ffff0000dd691070 [ 677.885669] x26: ffff0000dd691408 x25: ffff8000844af3e0 x24: ffff80008ad97690 [ 677.886592] x23: ffff0000e051d400 x22: ffff0000dd691010 x21: dfff800000000000 [ 677.887515] x20: 0000000000000000 x19: 0000000000000000 x18: ffff800085397ac0 [ 677.888438] x17: 0000000000000000 x16: ffff8000801b87c8 x15: 1ffff000115b2e10 [ 677.889361] x14: 00000000f1f1f1f1 x13: 0000000000000000 x12: ffff7000115b2e4d [ 677.890285] x11: 1ffff000115b2e4c x10: ffff7000115b2e4c x9 : ffff80000aa43e90 [ 677.891208] x8 : 00008fffeea4d1b4 x7 : ffff80008ad97267 x6 : 0000000000000001 [ 677.892131] x5 : ffff80008ad97260 x4 : ffff7000115b2e4d x3 : 0000000000000000 [ 677.893054] x2 : 0000000000000023 x1 : dfff800000000000 x0 : 0000000000000118 [ 677.893977] Call trace: [ 677.894297] destroy_workqueue+0x3c/0x770 [ 677.894826] mtk_jpegdec_destroy_workqueue+0x70/0x88 [mtk_jpeg_dec_hw] [ 677.895677] devm_action_release+0x50/0x90 [ 677.896211] release_nodes+0xe8/0x170 [ 677.896688] devres_release_all+0xf8/0x178 [ 677.897219] device_unbind_cleanup+0x24/0x170 [ 677.897785] device_release_driver_internal+0x35c/0x480 [ 677.898461] device_release_driver+0x20/0x38 ... [ 677.912665] ---[ end trace 0000000000000000 ]---(CVE-2024-56577)
In the Linux kernel, the following vulnerability has been resolved:
media: amphion: Set video drvdata before register video device
The video drvdata should be set before the video device is registered, otherwise video_drvdata() may return NULL in the open() file ops, and led to oops.(CVE-2024-56579)
In the Linux kernel, the following vulnerability has been resolved:
leds: class: Protect brightness_show() with led_cdev->led_access mutex
There is NULL pointer issue observed if from Process A where hid device being added which results in adding a led_cdev addition and later a another call to access of led_cdev attribute from Process B can result in NULL pointer issue.
Use mutex led_cdev->led_access to protect access to led->cdev and its attribute inside brightness_show() and max_brightness_show() and also update the comment for mutex that it should be used to protect the led class device fields.
Process A Process B
kthread+0x114 worker_thread+0x244 process_scheduled_works+0x248 uhid_device_add_worker+0x24 hid_add_device+0x120 device_add+0x268 bus_probe_device+0x94 device_initial_probe+0x14 __device_attach+0xfc bus_for_each_drv+0x10c __device_attach_driver+0x14c driver_probe_device+0x3c __driver_probe_device+0xa0 really_probe+0x190 hid_device_probe+0x130 ps_probe+0x990 ps_led_register+0x94 devm_led_classdev_register_ext+0x58 led_classdev_register_ext+0x1f8 device_create_with_groups+0x48 device_create_groups_vargs+0xc8 device_add+0x244 kobject_uevent+0x14 kobject_uevent_env[jt]+0x224 mutex_unlock[jt]+0xc4 __mutex_unlock_slowpath+0xd4 wake_up_q+0x70 try_to_wake_up[jt]+0x48c preempt_schedule_common+0x28 __schedule+0x628 __switch_to+0x174 el0t_64_sync+0x1a8/0x1ac el0t_64_sync_handler+0x68/0xbc el0_svc+0x38/0x68 do_el0_svc+0x1c/0x28 el0_svc_common+0x80/0xe0 invoke_syscall+0x58/0x114 __arm64_sys_read+0x1c/0x2c ksys_read+0x78/0xe8 vfs_read+0x1e0/0x2c8 kernfs_fop_read_iter+0x68/0x1b4 seq_read_iter+0x158/0x4ec kernfs_seq_show+0x44/0x54 sysfs_kf_seq_show+0xb4/0x130 dev_attr_show+0x38/0x74 brightness_show+0x20/0x4c dualshock4_led_get_brightness+0xc/0x74
[ 3313.874295][ T4013] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000060 [ 3313.874301][ T4013] Mem abort info: [ 3313.874303][ T4013] ESR = 0x0000000096000006 [ 3313.874305][ T4013] EC = 0x25: DABT (current EL), IL = 32 bits [ 3313.874307][ T4013] SET = 0, FnV = 0 [ 3313.874309][ T4013] EA = 0, S1PTW = 0 [ 3313.874311][ T4013] FSC = 0x06: level 2 translation fault [ 3313.874313][ T4013] Data abort info: [ 3313.874314][ T4013] ISV = 0, ISS = 0x00000006, ISS2 = 0x00000000 [ 3313.874316][ T4013] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 3313.874318][ T4013] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 3313.874320][ T4013] user pgtable: 4k pages, 39-bit VAs, pgdp=00000008f2b0a000 ..
[ 3313.874332][ T4013] Dumping ftrace buffer: [ 3313.874334][ T4013] (ftrace buffer empty) .. .. [ dd3313.874639][ T4013] CPU: 6 PID: 4013 Comm: InputReader [ 3313.874648][ T4013] pc : dualshock4_led_get_brightness+0xc/0x74 [ 3313.874653][ T4013] lr : led_update_brightness+0x38/0x60 [ 3313.874656][ T4013] sp : ffffffc0b910bbd0 .. .. [ 3313.874685][ T4013] Call trace: [ 3313.874687][ T4013] dualshock4_led_get_brightness+0xc/0x74 [ 3313.874690][ T4013] brightness_show+0x20/0x4c [ 3313.874692][ T4013] dev_attr_show+0x38/0x74 [ 3313.874696][ T4013] sysfs_kf_seq_show+0xb4/0x130 [ 3313.874700][ T4013] kernfs_seq_show+0x44/0x54 [ 3313.874703][ T4013] seq_read_iter+0x158/0x4ec [ 3313.874705][ T4013] kernfs_fop_read_iter+0x68/0x1b4 [ 3313.874708][ T4013] vfs_read+0x1e0/0x2c8 [ 3313.874711][ T4013] ksys_read+0x78/0xe8 [ 3313.874714][ T4013] __arm64_sys_read+0x1c/0x2c [ 3313.874718][ T4013] invoke_syscall+0x58/0x114 [ 3313.874721][ T4013] el0_svc_common+0x80/0xe0 [ 3313.874724][ T4013] do_el0_svc+0x1c/0x28 [ 3313.874727][ T4013] el0_svc+0x38/0x68 [ 3313.874730][ T4013] el0t_64_sync_handler+0x68/0xbc [ 3313.874732][ T4013] el0t_64_sync+0x1a8/0x1ac(CVE-2024-56587)
In the Linux kernel, the following vulnerability has been resolved:
wifi: brcmfmac: Fix oops due to NULL pointer dereference in brcmf_sdiod_sglist_rw()
This patch fixes a NULL pointer dereference bug in brcmfmac that occurs when a high 'sd_sgentry_align' value applies (e.g. 512) and a lot of queued SKBs are sent from the pkt queue.
The problem is the number of entries in the pre-allocated sgtable, it is nents = max(rxglom_size, txglom_size) + max(rxglom_size, txglom_size) >> 4 + 1. Given the default [rt]xglom_size=32 it's actually 35 which is too small. Worst case, the pkt queue can end up with 64 SKBs. This occurs when a new SKB is added for each original SKB if tailroom isn't enough to hold tail_pad. At least one sg entry is needed for each SKB. So, eventually the "skb_queue_walk loop" in brcmf_sdiod_sglist_rw may run out of sg entries. This makes sg_next return NULL and this causes the oops.
The patch sets nents to max(rxglom_size, txglom_size) * 2 to be able handle the worst-case. Btw. this requires only 64-35=29 * 16 (or 20 if CONFIG_NEED_SG_DMA_LENGTH) = 464 additional bytes of memory.(CVE-2024-56593)
In the Linux kernel, the following vulnerability has been resolved:
net: inet6: do not leave a dangling sk pointer in inet6_create()
sock_init_data() attaches the allocated sk pointer to the provided sock object. If inet6_create() fails later, the sk object is released, but the sock object retains the dangling sk pointer, which may cause use-after-free later.
Clear the sock sk pointer on error.(CVE-2024-56600)
In the Linux kernel, the following vulnerability has been resolved:
net: inet: do not leave a dangling sk pointer in inet_create()
sock_init_data() attaches the allocated sk object to the provided sock object. If inet_create() fails later, the sk object is freed, but the sock object retains the dangling pointer, which may create use-after-free later.
Clear the sk pointer in the sock object on error.(CVE-2024-56601)
In the Linux kernel, the following vulnerability has been resolved:
net: ieee802154: do not leave a dangling sk pointer in ieee802154_create()
sock_init_data() attaches the allocated sk object to the provided sock object. If ieee802154_create() fails later, the allocated sk object is freed, but the dangling pointer remains in the provided sock object, which may allow use-after-free.
Clear the sk pointer in the sock object on error.(CVE-2024-56602)
In the Linux kernel, the following vulnerability has been resolved:
net: af_can: do not leave a dangling sk pointer in can_create()
On error can_create() frees the allocated sk object, but sock_init_data() has already attached it to the provided sock object. This will leave a dangling sk pointer in the sock object and may cause use-after-free later.(CVE-2024-56603)
In the Linux kernel, the following vulnerability has been resolved:
af_packet: avoid erroring out after sock_init_data() in packet_create()
After sock_init_data() the allocated sk object is attached to the provided sock object. On error, packet_create() frees the sk object leaving the dangling pointer in the sock object on return. Some other code may try to use this pointer and cause use-after-free.(CVE-2024-56606)
In the Linux kernel, the following vulnerability has been resolved:
can: dev: can_set_termination(): allow sleeping GPIOs
In commit 6e86a1543c37 ("can: dev: provide optional GPIO based termination support") GPIO based termination support was added.
For no particular reason that patch uses gpiod_set_value() to set the GPIO. This leads to the following warning, if the systems uses a sleeping GPIO, i.e. behind an I2C port expander:
| WARNING: CPU: 0 PID: 379 at /drivers/gpio/gpiolib.c:3496 gpiod_set_value+0x50/0x6c | CPU: 0 UID: 0 PID: 379 Comm: ip Not tainted 6.11.0-20241016-1 #1 823affae360cc91126e4d316d7a614a8bf86236c
Replace gpiod_set_value() by gpiod_set_value_cansleep() to allow the use of sleeping GPIOs.(CVE-2024-56625)
In the Linux kernel, the following vulnerability has been resolved:
LoongArch: Add architecture specific huge_pte_clear()
When executing mm selftests run_vmtests.sh, there is such an error:
BUG: Bad page state in process uffd-unit-tests pfn:00000 page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x0 flags: 0xffff0000002000(reserved|node=0|zone=0|lastcpupid=0xffff) raw: 00ffff0000002000 ffffbf0000000008 ffffbf0000000008 0000000000000000 raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set Modules linked in: snd_seq_dummy snd_seq snd_seq_device rfkill vfat fat virtio_balloon efi_pstore virtio_net pstore net_failover failover fuse nfnetlink virtio_scsi virtio_gpu virtio_dma_buf dm_multipath efivarfs CPU: 2 UID: 0 PID: 1913 Comm: uffd-unit-tests Not tainted 6.12.0 #184 Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 2/2/2022 Stack : 900000047c8ac000 0000000000000000 9000000000223a7c 900000047c8ac000 900000047c8af690 900000047c8af698 0000000000000000 900000047c8af7d8 900000047c8af7d0 900000047c8af7d0 900000047c8af5b0 0000000000000001 0000000000000001 900000047c8af698 10b3c7d53da40d26 0000010000000000 0000000000000022 0000000fffffffff fffffffffe000000 ffff800000000000 000000000000002f 0000800000000000 000000017a6d4000 90000000028f8940 0000000000000000 0000000000000000 90000000025aa5e0 9000000002905000 0000000000000000 90000000028f8940 ffff800000000000 0000000000000000 0000000000000000 0000000000000000 9000000000223a94 000000012001839c 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1d ... Call Trace: [<9000000000223a94>] show_stack+0x5c/0x180 [<9000000001c3fd64>] dump_stack_lvl+0x6c/0xa0 [<900000000056aa08>] bad_page+0x1a0/0x1f0 [<9000000000574978>] free_unref_folios+0xbf0/0xd20 [<90000000004e65cc>] folios_put_refs+0x1a4/0x2b8 [<9000000000599a0c>] free_pages_and_swap_cache+0x164/0x260 [<9000000000547698>] tlb_batch_pages_flush+0xa8/0x1c0 [<9000000000547f30>] tlb_finish_mmu+0xa8/0x218 [<9000000000543cb8>] exit_mmap+0x1a0/0x360 [<9000000000247658>] __mmput+0x78/0x200 [<900000000025583c>] do_exit+0x43c/0xde8 [<9000000000256490>] do_group_exit+0x68/0x110 [<9000000000256554>] sys_exit_group+0x1c/0x20 [<9000000001c413b4>] do_syscall+0x94/0x130 [<90000000002216d8>] handle_syscall+0xb8/0x158 Disabling lock debugging due to kernel taint BUG: non-zero pgtables_bytes on freeing mm: -16384
On LoongArch system, invalid huge pte entry should be invalid_pte_table or a single _PAGE_HUGE bit rather than a zero value. And it should be the same with invalid pmd entry, since pmd_none() is called by function free_pgd_range() and pmd_none() return 0 by huge_pte_clear(). So single _PAGE_HUGE bit is also treated as a valid pte table and free_pte_range() will be called in free_pmd_range().
free_pmd_range() pmd = pmd_offset(pud, addr); do { next = pmd_addr_end(addr, end); if (pmd_none_or_clear_bad(pmd)) continue; free_pte_range(tlb, pmd, addr); } while (pmd++, addr = next, addr != end);
Here invalid_pte_table is used for both invalid huge pte entry and pmd entry.(CVE-2024-56628)
In the Linux kernel, the following vulnerability has been resolved:
geneve: do not assume mac header is set in geneve_xmit_skb()
We should not assume mac header is set in output path.
Use skb_eth_hdr() instead of eth_hdr() to fix the issue.
sysbot reported the following :
WARNING: CPU: 0 PID: 11635 at include/linux/skbuff.h:3052 skb_mac_header include/linux/skbuff.h:3052 [inline] WARNING: CPU: 0 PID: 11635 at include/linux/skbuff.h:3052 eth_hdr include/linux/if_ether.h:24 [inline] WARNING: CPU: 0 PID: 11635 at include/linux/skbuff.h:3052 geneve_xmit_skb drivers/net/geneve.c:898 [inline] WARNING: CPU: 0 PID: 11635 at include/linux/skbuff.h:3052 geneve_xmit+0x4c38/0x5730 drivers/net/geneve.c:1039 Modules linked in: CPU: 0 UID: 0 PID: 11635 Comm: syz.4.1423 Not tainted 6.12.0-syzkaller-10296-gaaf20f870da0 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:skb_mac_header include/linux/skbuff.h:3052 [inline] RIP: 0010:eth_hdr include/linux/if_ether.h:24 [inline] RIP: 0010:geneve_xmit_skb drivers/net/geneve.c:898 [inline] RIP: 0010:geneve_xmit+0x4c38/0x5730 drivers/net/geneve.c:1039 Code: 21 c6 02 e9 35 d4 ff ff e8 a5 48 4c fb 90 0f 0b 90 e9 fd f5 ff ff e8 97 48 4c fb 90 0f 0b 90 e9 d8 f5 ff ff e8 89 48 4c fb 90 <0f> 0b 90 e9 41 e4 ff ff e8 7b 48 4c fb 90 0f 0b 90 e9 cd e7 ff ff RSP: 0018:ffffc90003b2f870 EFLAGS: 00010283 RAX: 000000000000037a RBX: 000000000000ffff RCX: ffffc9000dc3d000 RDX: 0000000000080000 RSI: ffffffff86428417 RDI: 0000000000000003 RBP: ffffc90003b2f9f0 R08: 0000000000000003 R09: 000000000000ffff R10: 000000000000ffff R11: 0000000000000002 R12: ffff88806603c000 R13: 0000000000000000 R14: ffff8880685b2780 R15: 0000000000000e23 FS: 00007fdc2deed6c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b30a1dff8 CR3: 0000000056b8c000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __netdev_start_xmit include/linux/netdevice.h:5002 [inline] netdev_start_xmit include/linux/netdevice.h:5011 [inline] __dev_direct_xmit+0x58a/0x720 net/core/dev.c:4490 dev_direct_xmit include/linux/netdevice.h:3181 [inline] packet_xmit+0x1e4/0x360 net/packet/af_packet.c:285 packet_snd net/packet/af_packet.c:3146 [inline] packet_sendmsg+0x2700/0x5660 net/packet/af_packet.c:3178 sock_sendmsg_nosec net/socket.c:711 [inline] __sock_sendmsg net/socket.c:726 [inline] __sys_sendto+0x488/0x4f0 net/socket.c:2197 __do_sys_sendto net/socket.c:2204 [inline] __se_sys_sendto net/socket.c:2200 [inline] __x64_sys_sendto+0xe0/0x1c0 net/socket.c:2200 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2024-56636)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: ipset: Hold module reference while requesting a module
User space may unload ip_set.ko while it is itself requesting a set type backend module, leading to a kernel crash. The race condition may be provoked by inserting an mdelay() right after the nfnl_unlock() call.(CVE-2024-56637)
In the Linux kernel, the following vulnerability has been resolved:
dccp: Fix memory leak in dccp_feat_change_recv
If dccp_feat_push_confirm() fails after new value for SP feature was accepted without reconciliation ('entry == NULL' branch), memory allocated for that value with dccp_feat_clone_sp_val() is never freed.
Here is the kmemleak stack for this:
unreferenced object 0xffff88801d4ab488 (size 8): comm "syz-executor310", pid 1127, jiffies 4295085598 (age 41.666s) hex dump (first 8 bytes): 01 b4 4a 1d 80 88 ff ff ..J..... backtrace: [<00000000db7cabfe>] kmemdup+0x23/0x50 mm/util.c:128 [<0000000019b38405>] kmemdup include/linux/string.h:465 [inline] [<0000000019b38405>] dccp_feat_clone_sp_val net/dccp/feat.c:371 [inline] [<0000000019b38405>] dccp_feat_clone_sp_val net/dccp/feat.c:367 [inline] [<0000000019b38405>] dccp_feat_change_recv net/dccp/feat.c:1145 [inline] [<0000000019b38405>] dccp_feat_parse_options+0x1196/0x2180 net/dccp/feat.c:1416 [<00000000b1f6d94a>] dccp_parse_options+0xa2a/0x1260 net/dccp/options.c:125 [<0000000030d7b621>] dccp_rcv_state_process+0x197/0x13d0 net/dccp/input.c:650 [<000000001f74c72e>] dccp_v4_do_rcv+0xf9/0x1a0 net/dccp/ipv4.c:688 [<00000000a6c24128>] sk_backlog_rcv include/net/sock.h:1041 [inline] [<00000000a6c24128>] __release_sock+0x139/0x3b0 net/core/sock.c:2570 [<00000000cf1f3a53>] release_sock+0x54/0x1b0 net/core/sock.c:3111 [<000000008422fa23>] inet_wait_for_connect net/ipv4/af_inet.c:603 [inline] [<000000008422fa23>] __inet_stream_connect+0x5d0/0xf70 net/ipv4/af_inet.c:696 [<0000000015b6f64d>] inet_stream_connect+0x53/0xa0 net/ipv4/af_inet.c:735 [<0000000010122488>] __sys_connect_file+0x15c/0x1a0 net/socket.c:1865 [<00000000b4b70023>] __sys_connect+0x165/0x1a0 net/socket.c:1882 [<00000000f4cb3815>] __do_sys_connect net/socket.c:1892 [inline] [<00000000f4cb3815>] __se_sys_connect net/socket.c:1889 [inline] [<00000000f4cb3815>] __x64_sys_connect+0x6e/0xb0 net/socket.c:1889 [<00000000e7b1e839>] do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46 [<0000000055e91434>] entry_SYSCALL_64_after_hwframe+0x67/0xd1
Clean up the allocated memory in case of dccp_feat_push_confirm() failure and bail out with an error reset code.
Found by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2024-56643)
In the Linux kernel, the following vulnerability has been resolved:
net/ipv6: release expired exception dst cached in socket
Dst objects get leaked in ip6_negative_advice() when this function is executed for an expired IPv6 route located in the exception table. There are several conditions that must be fulfilled for the leak to occur: * an ICMPv6 packet indicating a change of the MTU for the path is received, resulting in an exception dst being created * a TCP connection that uses the exception dst for routing packets must start timing out so that TCP begins retransmissions * after the exception dst expires, the FIB6 garbage collector must not run before TCP executes ip6_negative_advice() for the expired exception dst
When TCP executes ip6_negative_advice() for an exception dst that has expired and if no other socket holds a reference to the exception dst, the refcount of the exception dst is 2, which corresponds to the increment made by dst_init() and the increment made by the TCP socket for which the connection is timing out. The refcount made by the socket is never released. The refcount of the dst is decremented in sk_dst_reset() but that decrement is counteracted by a dst_hold() intentionally placed just before the sk_dst_reset() in ip6_negative_advice(). After ip6_negative_advice() has finished, there is no other object tied to the dst. The socket lost its reference stored in sk_dst_cache and the dst is no longer in the exception table. The exception dst becomes a leaked object.
As a result of this dst leak, an unbalanced refcount is reported for the loopback device of a net namespace being destroyed under kernels that do not contain e5f80fcf869a ("ipv6: give an IPv6 dev to blackhole_netdev"): unregister_netdevice: waiting for lo to become free. Usage count = 2
Fix the dst leak by removing the dst_hold() in ip6_negative_advice(). The patch that introduced the dst_hold() in ip6_negative_advice() was 92f1655aa2b22 ("net: fix __dst_negative_advice() race"). But 92f1655aa2b22 merely refactored the code with regards to the dst refcount so the issue was present even before 92f1655aa2b22. The bug was introduced in 54c1a859efd9f ("ipv6: Don't drop cache route entry unless timer actually expired.") where the expired cached route is deleted and the sk_dst_cache member of the socket is set to NULL by calling dst_negative_advice() but the refcount belonging to the socket is left unbalanced.
The IPv4 version - ipv4_negative_advice() - is not affected by this bug. When the TCP connection times out ipv4_negative_advice() merely resets the sk_dst_cache of the socket while decrementing the refcount of the exception dst.(CVE-2024-56644)
In the Linux kernel, the following vulnerability has been resolved:
can: j1939: j1939_session_new(): fix skb reference counting
Since j1939_session_skb_queue() does an extra skb_get() for each new skb, do the same for the initial one in j1939_session_new() to avoid refcount underflow.
In the Linux kernel, the following vulnerability has been resolved:
netfilter: x_tables: fix LED ID check in led_tg_check()
Syzbot has reported the following BUG detected by KASAN:
BUG: KASAN: slab-out-of-bounds in strlen+0x58/0x70 Read of size 1 at addr ffff8881022da0c8 by task repro/5879 ... Call Trace: <TASK> dump_stack_lvl+0x241/0x360 ? __pfx_dump_stack_lvl+0x10/0x10 ? __pfx__printk+0x10/0x10 ? _printk+0xd5/0x120 ? __virt_addr_valid+0x183/0x530 ? __virt_addr_valid+0x183/0x530 print_report+0x169/0x550 ? __virt_addr_valid+0x183/0x530 ? __virt_addr_valid+0x183/0x530 ? __virt_addr_valid+0x45f/0x530 ? __phys_addr+0xba/0x170 ? strlen+0x58/0x70 kasan_report+0x143/0x180 ? strlen+0x58/0x70 strlen+0x58/0x70 kstrdup+0x20/0x80 led_tg_check+0x18b/0x3c0 xt_check_target+0x3bb/0xa40 ? __pfx_xt_check_target+0x10/0x10 ? stack_depot_save_flags+0x6e4/0x830 ? nft_target_init+0x174/0xc30 nft_target_init+0x82d/0xc30 ? __pfx_nft_target_init+0x10/0x10 ? nf_tables_newrule+0x1609/0x2980 ? nf_tables_newrule+0x1609/0x2980 ? rcu_is_watching+0x15/0xb0 ? nf_tables_newrule+0x1609/0x2980 ? nf_tables_newrule+0x1609/0x2980 ? __kmalloc_noprof+0x21a/0x400 nf_tables_newrule+0x1860/0x2980 ? __pfx_nf_tables_newrule+0x10/0x10 ? __nla_parse+0x40/0x60 nfnetlink_rcv+0x14e5/0x2ab0 ? __pfx_validate_chain+0x10/0x10 ? __pfx_nfnetlink_rcv+0x10/0x10 ? __lock_acquire+0x1384/0x2050 ? netlink_deliver_tap+0x2e/0x1b0 ? __pfx_lock_release+0x10/0x10 ? netlink_deliver_tap+0x2e/0x1b0 netlink_unicast+0x7f8/0x990 ? __pfx_netlink_unicast+0x10/0x10 ? __virt_addr_valid+0x183/0x530 ? __check_object_size+0x48e/0x900 netlink_sendmsg+0x8e4/0xcb0 ? __pfx_netlink_sendmsg+0x10/0x10 ? aa_sock_msg_perm+0x91/0x160 ? __pfx_netlink_sendmsg+0x10/0x10 __sock_sendmsg+0x223/0x270 _syssendmsg+0x52a/0x7e0 ? pfx_sys_sendmsg+0x10/0x10 sys_sendmsg+0x292/0x380 ? __pfxsyssendmsg+0x10/0x10 ? lockdep_hardirqs_on_prepare+0x43d/0x780 ? pfx_lockdep_hardirqs_on_prepare+0x10/0x10 ? exc_page_fault+0x590/0x8c0 ? do_syscall_64+0xb6/0x230 do_syscall_64+0xf3/0x230 entry_SYSCALL_64_after_hwframe+0x77/0x7f ... </TASK>
Since an invalid (without '\0' byte at all) byte sequence may be passed from userspace, add an extra check to ensure that such a sequence is rejected as possible ID and so never passed to 'kstrdup()' and further.(CVE-2024-56650)
In the Linux kernel, the following vulnerability has been resolved:
can: hi311x: hi3110_can_ist(): fix potential use-after-free
The commit a22bd630cfff ("can: hi311x: do not report txerr and rxerr during bus-off") removed the reporting of rxerr and txerr even in case of correct operation (i. e. not bus-off).
The error count information added to the CAN frame after netif_rx() is a potential use after free, since there is no guarantee that the skb is in the same state. It might be freed or reused.
Fix the issue by postponing the netif_rx() call in case of txerr and rxerr reporting.(CVE-2024-56651)
In the Linux kernel, the following vulnerability has been resolved:
powerpc/mm/fault: Fix kfence page fault reporting
copy_from_kernel_nofault() can be called when doing read of /proc/kcore. /proc/kcore can have some unmapped kfence objects which when read via copy_from_kernel_nofault() can cause page faults. Since *_nofault() functions define their own fixup table for handling fault, use that instead of asking kfence to handle such faults.
Hence we search the exception tables for the nip which generated the fault. If there is an entry then we let the fixup table handler handle the page fault by returning an error from within ___do_page_fault().
This can be easily triggered if someone tries to do dd from /proc/kcore. eg. dd if=/proc/kcore of=/dev/null bs=1M
Some example false negatives:
=============================== BUG: KFENCE: invalid read in copy_from_kernel_nofault+0x9c/0x1a0 Invalid read at 0xc0000000fdff0000: copy_from_kernel_nofault+0x9c/0x1a0 0xc00000000665f950 read_kcore_iter+0x57c/0xa04 proc_reg_read_iter+0xe4/0x16c vfs_read+0x320/0x3ec ksys_read+0x90/0x154 system_call_exception+0x120/0x310 system_call_vectored_common+0x15c/0x2ec
BUG: KFENCE: use-after-free read in copy_from_kernel_nofault+0x9c/0x1a0 Use-after-free read at 0xc0000000fe050000 (in kfence-#2): copy_from_kernel_nofault+0x9c/0x1a0 0xc00000000665f950 read_kcore_iter+0x57c/0xa04 proc_reg_read_iter+0xe4/0x16c vfs_read+0x320/0x3ec ksys_read+0x90/0x154 system_call_exception+0x120/0x310 system_call_vectored_common+0x15c/0x2ec(CVE-2024-56678)
In the Linux kernel, the following vulnerability has been resolved:
PCI: endpoint: epf-mhi: Avoid NULL dereference if DT lacks 'mmio'
If platform_get_resource_byname() fails and returns NULL because DT lacks an 'mmio' property for the MHI endpoint, dereferencing res->start will cause a NULL pointer access. Add a check to prevent it.
[kwilczynski: error message update per the review feedback] bhelgaas: commit log
In the Linux kernel, the following vulnerability has been resolved:
9p/xen: fix release of IRQ
Kernel logs indicate an IRQ was double-freed.
Pass correct device ID during IRQ release.
Dominique: remove confusing variable reset to 0
In the Linux kernel, the following vulnerability has been resolved:
octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_dmac_flt.c
Add error pointer checks after calling otx2_mbox_get_rsp().(CVE-2024-56707)
In the Linux kernel, the following vulnerability has been resolved:
mfd: intel_soc_pmic_bxtwc: Use IRQ domain for PMIC devices
While design wise the idea of converting the driver to use the hierarchy of the IRQ chips is correct, the implementation has (inherited) flaws. This was unveiled when platform_get_irq() had started WARN() on IRQ 0 that is supposed to be a Linux IRQ number (also known as vIRQ).
Rework the driver to respect IRQ domain when creating each MFD device separately, as the domain is not the same for all of them.(CVE-2024-56723)
In the Linux kernel, the following vulnerability has been resolved:
mfd: intel_soc_pmic_bxtwc: Use IRQ domain for TMU device
While design wise the idea of converting the driver to use the hierarchy of the IRQ chips is correct, the implementation has (inherited) flaws. This was unveiled when platform_get_irq() had started WARN() on IRQ 0 that is supposed to be a Linux IRQ number (also known as vIRQ).
Rework the driver to respect IRQ domain when creating each MFD device separately, as the domain is not the same for all of them.(CVE-2024-56724)
In the Linux kernel, the following vulnerability has been resolved:
octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_dcbnl.c
Add error pointer check after calling otx2_mbox_get_rsp().(CVE-2024-56725)
In the Linux kernel, the following vulnerability has been resolved:
octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_flows.c
Adding error pointer check after calling otx2_mbox_get_rsp().(CVE-2024-56727)
In the Linux kernel, the following vulnerability has been resolved:
fbdev: sh7760fb: Fix a possible memory leak in sh7760fb_alloc_mem()
When information such as info->screen_base is not ready, calling sh7760fb_free_mem() does not release memory correctly. Call dma_free_coherent() instead.(CVE-2024-56746)
In the Linux kernel, the following vulnerability has been resolved:
ipv6: release nexthop on device removal
The CI is hitting some aperiodic hangup at device removal time in the pmtu.sh self-test:
unregister_netdevice: waiting for veth_A-R1 to become free. Usage count = 6 ref_tracker: veth_A-R1@ffff888013df15d8 has 1/5 users at dst_init+0x84/0x4a0 dst_alloc+0x97/0x150 ip6_dst_alloc+0x23/0x90 ip6_rt_pcpu_alloc+0x1e6/0x520 ip6_pol_route+0x56f/0x840 fib6_rule_lookup+0x334/0x630 ip6_route_output_flags+0x259/0x480 ip6_dst_lookup_tail.constprop.0+0x5c2/0x940 ip6_dst_lookup_flow+0x88/0x190 udp_tunnel6_dst_lookup+0x2a7/0x4c0 vxlan_xmit_one+0xbde/0x4a50 [vxlan] vxlan_xmit+0x9ad/0xf20 [vxlan] dev_hard_start_xmit+0x10e/0x360 __dev_queue_xmit+0xf95/0x18c0 arp_solicit+0x4a2/0xe00 neigh_probe+0xaa/0xf0
While the first suspect is the dst_cache, explicitly tracking the dst owing the last device reference via probes proved such dst is held by the nexthop in the originating fib6_info.
Similar to commit f5b51fe804ec ("ipv6: route: purge exception on removal"), we need to explicitly release the originating fib info when disconnecting a to-be-removed device from a live ipv6 dst: move the fib6_info cleanup into ip6_dst_ifdown().
Tested running:
./pmtu.sh cleanup_ipv6_exception
in a tight loop for more than 400 iterations with no spat, running an unpatched kernel I observed a splat every ~10 iterations.(CVE-2024-56751)
In the Linux kernel, the following vulnerability has been resolved:
crypto: caam - Fix the pointer passed to caam_qi_shutdown()
The type of the last parameter given to devm_add_action_or_reset() is "struct caam_drv_private ", but in caam_qi_shutdown(), it is casted to "struct device ".
Pass the correct parameter to devm_add_action_or_reset() so that the resources are released as expected.(CVE-2024-56754)
In the Linux kernel, the following vulnerability has been resolved:
btrfs: add a sanity check for btrfs root in btrfs_search_slot()
Syzbot reports a null-ptr-deref in btrfs_search_slot().
The reproducer is using rescue=ibadroots, and the extent tree root is corrupted thus the extent tree is NULL.
When scrub tries to search the extent tree to gather the needed extent info, btrfs_search_slot() doesn't check if the target root is NULL or not, resulting the null-ptr-deref.
Add sanity check for btrfs root before using it in btrfs_search_slot().(CVE-2024-56774)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nft_socket: remove WARN_ON_ONCE on maximum cgroup level
cgroup maximum depth is INT_MAX by default, there is a cgroup toggle to restrict this maximum depth to a more reasonable value not to harm performance. Remove unnecessary WARN_ON_ONCE which is reachable from userspace.(CVE-2024-56783)
In the Linux kernel, the following vulnerability has been resolved:
MIPS: Loongson64: DTS: Really fix PCIe port nodes for ls7a
Fix the dtc warnings:
arch/mips/boot/dts/loongson/ls7a-pch.dtsi:68.16-416.5: Warning (interrupt_provider): /bus@10000000/pci@1a000000: '#interrupt-cells' found, but node is not an interrupt provider
arch/mips/boot/dts/loongson/ls7a-pch.dtsi:68.16-416.5: Warning (interrupt_provider): /bus@10000000/pci@1a000000: '#interrupt-cells' found, but node is not an interrupt provider
arch/mips/boot/dts/loongson/loongson64g_4core_ls7a.dtb: Warning (interrupt_map): Failed prerequisite 'interrupt_provider'
And a runtime warning introduced in commit 045b14ca5c36 ("of: WARN on deprecated #address-cells/#size-cells handling"):
WARNING: CPU: 0 PID: 1 at drivers/of/base.c:106 of_bus_n_addr_cells+0x9c/0xe0
Missing '#address-cells' in /bus@10000000/pci@1a000000/pci_bridge@9,0
The fix is similar to commit d89a415ff8d5 ("MIPS: Loongson64: DTS: Fix PCIe port nodes for ls7a"), which has fixed the issue for ls2k (despite its subject mentions ls7a).(CVE-2024-56785)
In the Linux kernel, the following vulnerability has been resolved:
s390/entry: Mark IRQ entries to fix stack depot warnings
The stack depot filters out everything outside of the top interrupt context as an uninteresting or irrelevant part of the stack traces. This helps with stack trace de-duplication, avoiding an explosion of saved stack traces that share the same IRQ context code path but originate from different randomly interrupted points, eventually exhausting the stack depot.
Filtering uses in_irqentry_text() to identify functions within the .irqentry.text and .softirqentry.text sections, which then become the last stack trace entries being saved.
While __do_softirq() is placed into the .softirqentry.text section by common code, populating .irqentry.text is architecture-specific.
Currently, the .irqentry.text section on s390 is empty, which prevents stack depot filtering and de-duplication and could result in warnings like:
Stack depot reached limit capacity WARNING: CPU: 0 PID: 286113 at lib/stackdepot.c:252 depot_alloc_stack+0x39a/0x3c8
with PREEMPT and KASAN enabled.
Fix this by moving the IO/EXT interrupt handlers from .kprobes.text into the .irqentry.text section and updating the kprobes blacklist to include the .irqentry.text section.
This is done only for asynchronous interrupts and explicitly not for program checks, which are synchronous and where the context beyond the program check is important to preserve. Despite machine checks being somewhat in between, they are extremely rare, and preserving context when possible is also of value.
SVCs and Restart Interrupts are not relevant, one being always at the boundary to user space and the other being a one-time thing.
IRQ entries filtering is also optionally used in ftrace function graph, where the same logic applies.(CVE-2024-57838)
In the Linux kernel, the following vulnerability has been resolved:
drm/dp_mst: Fix resetting msg rx state after topology removal
If the MST topology is removed during the reception of an MST down reply or MST up request sideband message, the drm_dp_mst_topology_mgr::up_req_recv/down_rep_recv states could be reset from one thread via drm_dp_mst_topology_mgr_set_mst(false), racing with the reading/parsing of the message from another thread via drm_dp_mst_handle_down_rep() or drm_dp_mst_handle_up_req(). The race is possible since the reader/parser doesn't hold any lock while accessing the reception state. This in turn can lead to a memory corruption in the reader/parser as described by commit bd2fccac61b4 ("drm/dp_mst: Fix MST sideband message body length check").
Fix the above by resetting the message reception state if needed before reading/parsing a message. Another solution would be to hold the drm_dp_mst_topology_mgr::lock for the whole duration of the message reception/parsing in drm_dp_mst_handle_down_rep() and drm_dp_mst_handle_up_req(), however this would require a bigger change. Since the fix is also needed for stable, opting for the simpler solution in this patch.(CVE-2024-57876)
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: fix mbss changed flags corruption on 32 bit systems
On 32-bit systems, the size of an unsigned long is 4 bytes, while a u64 is 8 bytes. Therefore, when using or_each_set_bit(bit, &bits, sizeof(changed) * BITS_PER_BYTE), the code is incorrectly searching for a bit in a 32-bit variable that is expected to be 64 bits in size, leading to incorrect bit finding.
Solution: Ensure that the size of the bits variable is correctly adjusted for each architecture.
Call Trace: ? show_regs+0x54/0x58 ? __warn+0x6b/0xd4 ? ieee80211_link_info_change_notify+0xcc/0xd4 [mac80211] ? report_bug+0x113/0x150 ? exc_overflow+0x30/0x30 ? handle_bug+0x27/0x44 ? exc_invalid_op+0x18/0x50 ? handle_exception+0xf6/0xf6 ? exc_overflow+0x30/0x30 ? ieee80211_link_info_change_notify+0xcc/0xd4 [mac80211] ? exc_overflow+0x30/0x30 ? ieee80211_link_info_change_notify+0xcc/0xd4 [mac80211] ? ieee80211_mesh_work+0xff/0x260 [mac80211] ? cfg80211_wiphy_work+0x72/0x98 [cfg80211] ? process_one_work+0xf1/0x1fc ? worker_thread+0x2c0/0x3b4 ? kthread+0xc7/0xf0 ? mod_delayed_work_on+0x4c/0x4c ? kthread_complete_and_exit+0x14/0x14 ? ret_from_fork+0x24/0x38 ? kthread_complete_and_exit+0x14/0x14 ? ret_from_fork_asm+0xf/0x14 ? entry_INT80_32+0xf0/0xf0
restore no-op path for no changes
In the Linux kernel, the following vulnerability has been resolved:
usb: xhci: Fix NULL pointer dereference on certain command aborts
If a command is queued to the final usable TRB of a ring segment, the enqueue pointer is advanced to the subsequent link TRB and no further. If the command is later aborted, when the abort completion is handled the dequeue pointer is advanced to the first TRB of the next segment.
If no further commands are queued, xhci_handle_stopped_cmd_ring() sees the ring pointers unequal and assumes that there is a pending command, so it calls xhci_mod_cmd_timer() which crashes if cur_cmd was NULL.
Don't attempt timer setup if cur_cmd is NULL. The subsequent doorbell ring likely is unnecessary too, but it's harmless. Leave it alone.
This is probably Bug 219532, but no confirmation has been received.
The issue has been independently reproduced and confirmed fixed using a USB MCU programmed to NAK the Status stage of SET_ADDRESS forever. Everything continued working normally after several prevented crashes.(CVE-2024-57981)
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: handle a symlink read error correctly
Patch series "Convert ocfs2 to use folios".
Mark did a conversion of ocfs2 to use folios and sent it to me as a giant patch for review ;-)
So I've redone it as individual patches, and credited Mark for the patches where his code is substantially the same. It's not a bad way to do it; his patch had some bugs and my patches had some bugs. Hopefully all our bugs were different from each other. And hopefully Mark likes all the changes I made to his code!
This patch (of 23):
If we can't read the buffer, be sure to unlock the page before returning.(CVE-2024-58001)
In the Linux kernel, the following vulnerability has been resolved:
bpf: bpf_local_storage: Always use bpf_mem_alloc in PREEMPT_RT
In PREEMPT_RT, kmalloc(GFP_ATOMIC) is still not safe in non preemptible context. bpf_mem_alloc must be used in PREEMPT_RT. This patch is to enforce bpf_mem_alloc in the bpf_local_storage when CONFIG_PREEMPT_RT is enabled.
[ 35.118559] BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 [ 35.118566] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1832, name: test_progs [ 35.118569] preempt_count: 1, expected: 0 [ 35.118571] RCU nest depth: 1, expected: 1 [ 35.118577] INFO: lockdep is turned off. ... [ 35.118647] __might_resched+0x433/0x5b0 [ 35.118677] rt_spin_lock+0xc3/0x290 [ 35.118700] slaballoc+0x72/0xc40 [ 35.118723] kmalloc_noprof+0x13f/0x4e0 [ 35.118732] bpf_map_kzalloc+0xe5/0x220 [ 35.118740] bpf_selem_alloc+0x1d2/0x7b0 [ 35.118755] bpf_local_storage_update+0x2fa/0x8b0 [ 35.118784] bpf_sk_storage_get_tracing+0x15a/0x1d0 [ 35.118791] bpf_prog_9a118d86fca78ebb_trace_inet_sock_set_state+0x44/0x66 [ 35.118795] bpf_trace_run3+0x222/0x400 [ 35.118820] __bpf_trace_inet_sock_set_state+0x11/0x20 [ 35.118824] trace_inet_sock_set_state+0x112/0x130 [ 35.118830] inet_sk_state_store+0x41/0x90 [ 35.118836] tcp_set_state+0x3b3/0x640
There is no need to adjust the gfp_flags passing to the bpf_mem_cache_alloc_flags() which only honors the GFP_KERNEL. The verifier has ensured GFP_KERNEL is passed only in sleepable context.
It has been an old issue since the first introduction of the bpf_local_storage ~5 years ago, so this patch targets the bpf-next.
bpf_mem_alloc is needed to solve it, so the Fixes tag is set to the commit when bpf_mem_alloc was first used in the bpf_local_storage.(CVE-2024-58070)
In the Linux kernel, the following vulnerability has been resolved:
wifi: rtw89: fix race between cancel_hw_scan and hw_scan completion
The rtwdev->scanning flag isn't protected by mutex originally, so cancel_hw_scan can pass the condition, but suddenly hw_scan completion unset the flag and calls ieee80211_scan_completed() that will free local->hw_scan_req. Then, cancel_hw_scan raises null-ptr-deref and use-after-free. Fix it by moving the check condition to where protected by mutex.
KASAN: null-ptr-deref in range [0x0000000000000088-0x000000000000008f] CPU: 2 PID: 6922 Comm: kworker/2:2 Tainted: G OE Hardware name: LENOVO 2356AD1/2356AD1, BIOS G7ETB6WW (2.76 ) 09/10/2019 Workqueue: events cfg80211_conn_work [cfg80211] RIP: 0010:rtw89_fw_h2c_scan_offload_be+0xc33/0x13c3 [rtw89_core] Code: 00 45 89 6c 24 1c 0f 85 23 01 00 00 48 8b 85 20 ff ff ff 48 8d RSP: 0018:ffff88811fd9f068 EFLAGS: 00010206 RAX: dffffc0000000000 RBX: ffff88811fd9f258 RCX: 0000000000000001 RDX: 0000000000000011 RSI: 0000000000000001 RDI: 0000000000000089 RBP: ffff88811fd9f170 R08: 0000000000000000 R09: 0000000000000000 R10: ffff88811fd9f108 R11: 0000000000000000 R12: ffff88810e47f960 R13: 0000000000000000 R14: 000000000000ffff R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff8881d6f00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007531dfca55b0 CR3: 00000001be296004 CR4: 00000000001706e0 Call Trace: <TASK> ? show_regs+0x61/0x73 ? __die_body+0x20/0x73 ? die_addr+0x4f/0x7b ? exc_general_protection+0x191/0x1db ? asm_exc_general_protection+0x27/0x30 ? rtw89_fw_h2c_scan_offload_be+0xc33/0x13c3 [rtw89_core] ? rtw89_fw_h2c_scan_offload_be+0x458/0x13c3 [rtw89_core] ? __pfx_rtw89_fw_h2c_scan_offload_be+0x10/0x10 [rtw89_core] ? do_raw_spin_lock+0x75/0xdb ? __pfx_do_raw_spin_lock+0x10/0x10 rtw89_hw_scan_offload+0xb5e/0xbf7 [rtw89_core] ? _raw_spin_unlock+0xe/0x24 ? __mutex_lock.constprop.0+0x40c/0x471 ? __pfx_rtw89_hw_scan_offload+0x10/0x10 [rtw89_core] ? __mutex_lock_slowpath+0x13/0x1f ? mutex_lock+0xa2/0xdc ? __pfx_mutex_lock+0x10/0x10 rtw89_hw_scan_abort+0x58/0xb7 [rtw89_core] rtw89_ops_cancel_hw_scan+0x120/0x13b [rtw89_core] ieee80211_scan_cancel+0x468/0x4d0 [mac80211] ieee80211_prep_connection+0x858/0x899 [mac80211] ieee80211_mgd_auth+0xbea/0xdde [mac80211] ? __pfx_ieee80211_mgd_auth+0x10/0x10 [mac80211] ? cfg80211_find_elem+0x15/0x29 [cfg80211] ? is_bss+0x1b7/0x1d7 [cfg80211] ieee80211_auth+0x18/0x27 [mac80211] cfg80211_mlme_auth+0x3bb/0x3e7 [cfg80211] cfg80211_conn_do_work+0x410/0xb81 [cfg80211] ? __pfx_cfg80211_conn_do_work+0x10/0x10 [cfg80211] ? __kasan_check_read+0x11/0x1f ? psi_group_change+0x8bc/0x944 ? __kasan_check_write+0x14/0x22 ? mutex_lock+0x8e/0xdc ? __pfx_mutex_lock+0x10/0x10 ? __pfxradixtree_lookup+0x10/0x10 cfg80211_conn_work+0x245/0x34d [cfg80211] ? pfx_cfg80211_conn_work+0x10/0x10 [cfg80211] ? update_cfs_rq_load_avg+0x3bc/0x3d7 ? sched_clock_noinstr+0x9/0x1a ? sched_clock+0x10/0x24 ? sched_clock_cpu+0x7e/0x42e ? newidle_balance+0x796/0x937 ? __pfx_sched_clock_cpu+0x10/0x10 ? __pfx_newidle_balance+0x10/0x10 ? __kasan_check_read+0x11/0x1f ? psi_group_change+0x8bc/0x944 ? _raw_spin_unlock+0xe/0x24 ? raw_spin_rq_unlock+0x47/0x54 ? raw_spin_rq_unlock_irq+0x9/0x1f ? finish_task_switch.isra.0+0x347/0x586 ? __schedule+0x27bf/0x2892 ? mutex_unlock+0x80/0xd0 ? do_raw_spin_lock+0x75/0xdb ? __pfxschedule+0x10/0x10 processscheduled_works+0x58c/0x821 worker_thread+0x4c7/0x586 ? kasan_check_read+0x11/0x1f kthread+0x285/0x294 ? __pfx_worker_thread+0x10/0x10 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x29/0x6f ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 </TASK>(CVE-2025-21729)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/mlx5: Fix a race for an ODP MR which leads to CQE with error
This patch addresses a race condition for an ODP MR that can result in a CQE with an error on the UMR QP.
During the __mlx5_ib_dereg_mr() flow, the following sequence of calls occurs:
mlx5_revoke_mr() mlx5r_umr_revoke_mr() mlx5r_umr_post_send_wait()
At this point, the lkey is freed from the hardware's perspective.
However, concurrently, mlx5_ib_invalidate_range() might be triggered by another task attempting to invalidate a range for the same freed lkey.
This task will: - Acquire the umem_odp->umem_mutex lock. - Call mlx5r_umr_update_xlt() on the UMR QP. - Since the lkey has already been freed, this can lead to a CQE error, causing the UMR QP to enter an error state [1].
To resolve this race condition, the umem_odp->umem_mutex lock is now also acquired as part of the mlx5_revoke_mr() scope. Upon successful revoke, we set umem_odp->private which points to that MR to NULL, preventing any further invalidation attempts on its lkey.
[1] From dmesg:
infiniband rocep8s0f0: dump_cqe:277:(pid 0): WC error: 6, Message: memory bind operation error cqe_dump: 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 cqe_dump: 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 cqe_dump: 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 cqe_dump: 00000030: 00 00 00 00 08 00 78 06 25 00 11 b9 00 0e dd d2
WARNING: CPU: 15 PID: 1506 at drivers/infiniband/hw/mlx5/umr.c:394 mlx5r_umr_post_send_wait+0x15a/0x2b0 [mlx5_ib] Modules linked in: ip6table_mangle ip6table_natip6table_filter ip6_tables iptable_mangle xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry overlay rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_umad ib_ipoib ib_cm mlx5_ib ib_uverbs ib_core fuse mlx5_core CPU: 15 UID: 0 PID: 1506 Comm: ibv_rc_pingpong Not tainted 6.12.0-rc7+ #1626 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:mlx5r_umr_post_send_wait+0x15a/0x2b0 [mlx5_ib] [..] Call Trace: <TASK> mlx5r_umr_update_xlt+0x23c/0x3e0 [mlx5_ib] mlx5_ib_invalidate_range+0x2e1/0x330 [mlx5_ib] __mmu_notifier_invalidate_range_start+0x1e1/0x240 zap_page_range_single+0xf1/0x1a0 madvise_vma_behavior+0x677/0x6e0 do_madvise+0x1a2/0x4b0 __x64_sys_madvise+0x25/0x30 do_syscall_64+0x6b/0x140 entry_SYSCALL_64_after_hwframe+0x76/0x7e(CVE-2025-21732)
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix possible int overflows in nilfs_fiemap()
Since nilfs_bmap_lookup_contig() in nilfs_fiemap() calculates its result by being prepared to go through potentially maxblocks == INT_MAX blocks, the value in n may experience an overflow caused by left shift of blkbits.
While it is extremely unlikely to occur, play it safe and cast right hand expression to wider type to mitigate the issue.
Found by Linux Verification Center (linuxtesting.org) with static analysis tool SVACE.(CVE-2025-21736)
In the Linux kernel, the following vulnerability has been resolved:
usbnet: ipheth: fix possible overflow in DPE length check
Originally, it was possible for the DPE length check to overflow if wDatagramIndex + wDatagramLength > U16_MAX. This could lead to an OoB read.
Move the wDatagramIndex term to the other side of the inequality.
An existing condition ensures that wDatagramIndex < urb->actual_length.(CVE-2025-21743)
In the Linux kernel, the following vulnerability has been resolved:
clocksource: Use migrate_disable() to avoid calling get_random_u32() in atomic context
The following bug report happened with a PREEMPT_RT kernel:
BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 2012, name: kwatchdog preempt_count: 1, expected: 0 RCU nest depth: 0, expected: 0 get_random_u32+0x4f/0x110 clocksource_verify_choose_cpus+0xab/0x1a0 clocksource_verify_percpu.part.0+0x6b/0x330 clocksource_watchdog_kthread+0x193/0x1a0
It is due to the fact that clocksource_verify_choose_cpus() is invoked with preemption disabled. This function invokes get_random_u32() to obtain random numbers for choosing CPUs. The batched_entropy_32 local lock and/or the base_crng.lock spinlock in driver/char/random.c will be acquired during the call. In PREEMPT_RT kernel, they are both sleeping locks and so cannot be acquired in atomic context.
Fix this problem by using migrate_disable() to allow smp_processor_id() to be reliably used without introducing atomic context. preempt_disable() is then called after clocksource_verify_choose_cpus() but before the clocksource measurement is being run to avoid introducing unexpected latency.(CVE-2025-21767)
In the Linux kernel, the following vulnerability has been resolved:
USB: hub: Ignore non-compliant devices with too many configs or interfaces
Robert Morris created a test program which can cause usb_hub_to_struct_hub() to dereference a NULL or inappropriate pointer:
Oops: general protection fault, probably for non-canonical address 0xcccccccccccccccc: 0000 [#1] SMP DEBUG_PAGEALLOC PTI CPU: 7 UID: 0 PID: 117 Comm: kworker/7:1 Not tainted 6.13.0-rc3-00017-gf44d154d6e3d #14 Hardware name: FreeBSD BHYVE/BHYVE, BIOS 14.0 10/17/2021 Workqueue: usb_hub_wq hub_event RIP: 0010:usb_hub_adjust_deviceremovable+0x78/0x110 ... Call Trace: <TASK> ? die_addr+0x31/0x80 ? exc_general_protection+0x1b4/0x3c0 ? asm_exc_general_protection+0x26/0x30 ? usb_hub_adjust_deviceremovable+0x78/0x110 hub_probe+0x7c7/0xab0 usb_probe_interface+0x14b/0x350 really_probe+0xd0/0x2d0 ? __pfxdeviceattach_driver+0x10/0x10 driver_probe_device+0x6e/0x110 driver_probe_device+0x1a/0x90 __device_attach_driver+0x7e/0xc0 bus_for_each_drv+0x7f/0xd0 __device_attach+0xaa/0x1a0 bus_probe_device+0x8b/0xa0 device_add+0x62e/0x810 usb_set_configuration+0x65d/0x990 usb_generic_driver_probe+0x4b/0x70 usb_probe_device+0x36/0xd0
The cause of this error is that the device has two interfaces, and the hub driver binds to interface 1 instead of interface 0, which is where usb_hub_to_struct_hub() looks.
We can prevent the problem from occurring by refusing to accept hub devices that violate the USB spec by having more than one configuration or interface.(CVE-2025-21776)
In the Linux kernel, the following vulnerability has been resolved:
orangefs: fix a oob in orangefs_debug_write
I got a syzbot report: slab-out-of-bounds Read in orangefs_debug_write... several people suggested fixes, I tested Al Viro's suggestion and made this patch.(CVE-2025-21782)
In the Linux kernel, the following vulnerability has been resolved:
gpiolib: Fix crash on error in gpiochip_get_ngpios()
The gpiochip_get_ngpios() uses chip_() macros to print messages. However these macros rely on gpiodev to be initialised and set, which is not the case when called via bgpio_init(). In such a case the printing messages will crash on NULL pointer dereference. Replace chip_() macros by the respective dev_*() ones to avoid such crash.(CVE-2025-21783)
In the Linux kernel, the following vulnerability has been resolved:
LoongArch: csum: Fix OoB access in IP checksum code for negative lengths
Commit 69e3a6aa6be2 ("LoongArch: Add checksum optimization for 64-bit system") would cause an undefined shift and an out-of-bounds read.
Commit 8bd795fedb84 ("arm64: csum: Fix OoB access in IP checksum code for negative lengths") fixes the same issue on ARM64.(CVE-2025-21789)
In the Linux kernel, the following vulnerability has been resolved:
NFSD: fix hang in nfsd4_shutdown_callback
If nfs4_client is in courtesy state then there is no point to send the callback. This causes nfsd4_shutdown_callback to hang since cl_cb_inflight is not 0. This hang lasts about 15 minutes until TCP notifies NFSD that the connection was dropped.
This patch modifies nfsd4_run_cb_work to skip the RPC call if nfs4_client is in courtesy state.(CVE-2025-21795)
In the Linux kernel, the following vulnerability has been resolved:
nfsd: clear acl_access/acl_default after releasing them
If getting acl_default fails, acl_access and acl_default will be released simultaneously. However, acl_access will still retain a pointer pointing to the released posix_acl, which will trigger a WARNING in nfs3svc_release_getacl like this:
------------[ cut here ]------------ refcount_t: underflow; use-after-free. WARNING: CPU: 26 PID: 3199 at lib/refcount.c:28 refcount_warn_saturate+0xb5/0x170 Modules linked in: CPU: 26 UID: 0 PID: 3199 Comm: nfsd Not tainted 6.12.0-rc6-00079-g04ae226af01f-dirty #8 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 RIP: 0010:refcount_warn_saturate+0xb5/0x170 Code: cc cc 0f b6 1d b3 20 a5 03 80 fb 01 0f 87 65 48 d8 00 83 e3 01 75 e4 48 c7 c7 c0 3b 9b 85 c6 05 97 20 a5 03 01 e8 fb 3e 30 ff <0f> 0b eb cd 0f b6 1d 8a3 RSP: 0018:ffffc90008637cd8 EFLAGS: 00010282 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff83904fde RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff88871ed36380 RBP: ffff888158beeb40 R08: 0000000000000001 R09: fffff520010c6f56 R10: ffffc90008637ab7 R11: 0000000000000001 R12: 0000000000000001 R13: ffff888140e77400 R14: ffff888140e77408 R15: ffffffff858b42c0 FS: 0000000000000000(0000) GS:ffff88871ed00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000562384d32158 CR3: 000000055cc6a000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? refcount_warn_saturate+0xb5/0x170 ? __warn+0xa5/0x140 ? refcount_warn_saturate+0xb5/0x170 ? report_bug+0x1b1/0x1e0 ? handle_bug+0x53/0xa0 ? exc_invalid_op+0x17/0x40 ? asm_exc_invalid_op+0x1a/0x20 ? tick_nohz_tick_stopped+0x1e/0x40 ? refcount_warn_saturate+0xb5/0x170 ? refcount_warn_saturate+0xb5/0x170 nfs3svc_release_getacl+0xc9/0xe0 svc_process_common+0x5db/0xb60 ? __pfx_svc_process_common+0x10/0x10 ? __rcu_read_unlock+0x69/0xa0 ? __pfx_nfsd_dispatch+0x10/0x10 ? svc_xprt_received+0xa1/0x120 ? xdr_init_decode+0x11d/0x190 svc_process+0x2a7/0x330 svc_handle_xprt+0x69d/0x940 svc_recv+0x180/0x2d0 nfsd+0x168/0x200 ? __pfx_nfsd+0x10/0x10 kthread+0x1a2/0x1e0 ? kthread+0xf4/0x1e0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x60 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> Kernel panic - not syncing: kernel: panic_on_warn set ...
Clear acl_access/acl_default after posix_acl_release is called to prevent UAF from being triggered.(CVE-2025-21796)
In the Linux kernel, the following vulnerability has been resolved:
ptp: Ensure info->enable callback is always set
The ioctl and sysfs handlers unconditionally call the ->enable callback. Not all drivers implement that callback, leading to NULL dereferences. Example of affected drivers: ptp_s390.c, ptp_vclock.c and ptp_mock.c.
Instead use a dummy callback if no better was specified by the driver.(CVE-2025-21814)
In the Linux kernel, the following vulnerability has been resolved:
block: mark GFP_NOIO around sysfs ->store()
sysfs ->store is called with queue freezed, meantime we have several ->store() callbacks(update_nr_requests, wbt, scheduler) to allocate memory with GFP_KERNEL which may run into direct reclaim code path, then potential deadlock can be caused.
Fix the issue by marking NOIO around sysfs ->store()(CVE-2025-21817)
| URL | Type | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-6.6.0-82.0.0.86.oe2403sp1.aarch64.rpm",
"bpftool-debuginfo-6.6.0-82.0.0.86.oe2403sp1.aarch64.rpm",
"kernel-6.6.0-82.0.0.86.oe2403sp1.aarch64.rpm",
"kernel-debuginfo-6.6.0-82.0.0.86.oe2403sp1.aarch64.rpm",
"kernel-debugsource-6.6.0-82.0.0.86.oe2403sp1.aarch64.rpm",
"kernel-devel-6.6.0-82.0.0.86.oe2403sp1.aarch64.rpm",
"kernel-headers-6.6.0-82.0.0.86.oe2403sp1.aarch64.rpm",
"kernel-source-6.6.0-82.0.0.86.oe2403sp1.aarch64.rpm",
"kernel-tools-6.6.0-82.0.0.86.oe2403sp1.aarch64.rpm",
"kernel-tools-debuginfo-6.6.0-82.0.0.86.oe2403sp1.aarch64.rpm",
"kernel-tools-devel-6.6.0-82.0.0.86.oe2403sp1.aarch64.rpm",
"perf-6.6.0-82.0.0.86.oe2403sp1.aarch64.rpm",
"perf-debuginfo-6.6.0-82.0.0.86.oe2403sp1.aarch64.rpm",
"python3-perf-6.6.0-82.0.0.86.oe2403sp1.aarch64.rpm",
"python3-perf-debuginfo-6.6.0-82.0.0.86.oe2403sp1.aarch64.rpm"
],
"src": [
"kernel-6.6.0-82.0.0.86.oe2403sp1.src.rpm"
],
"x86_64": [
"bpftool-6.6.0-82.0.0.86.oe2403sp1.x86_64.rpm",
"bpftool-debuginfo-6.6.0-82.0.0.86.oe2403sp1.x86_64.rpm",
"kernel-6.6.0-82.0.0.86.oe2403sp1.x86_64.rpm",
"kernel-debuginfo-6.6.0-82.0.0.86.oe2403sp1.x86_64.rpm",
"kernel-debugsource-6.6.0-82.0.0.86.oe2403sp1.x86_64.rpm",
"kernel-devel-6.6.0-82.0.0.86.oe2403sp1.x86_64.rpm",
"kernel-headers-6.6.0-82.0.0.86.oe2403sp1.x86_64.rpm",
"kernel-source-6.6.0-82.0.0.86.oe2403sp1.x86_64.rpm",
"kernel-tools-6.6.0-82.0.0.86.oe2403sp1.x86_64.rpm",
"kernel-tools-debuginfo-6.6.0-82.0.0.86.oe2403sp1.x86_64.rpm",
"kernel-tools-devel-6.6.0-82.0.0.86.oe2403sp1.x86_64.rpm",
"perf-6.6.0-82.0.0.86.oe2403sp1.x86_64.rpm",
"perf-debuginfo-6.6.0-82.0.0.86.oe2403sp1.x86_64.rpm",
"python3-perf-6.6.0-82.0.0.86.oe2403sp1.x86_64.rpm",
"python3-perf-debuginfo-6.6.0-82.0.0.86.oe2403sp1.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:24.03-LTS-SP1",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS-SP1"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.6.0-82.0.0.86.oe2403sp1"
}
],
"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\nIORING_OP_READ did not correctly consume the provided buffer list when\nread i/o returned \u0026lt; 0 (except for -EAGAIN and -EIOCBQUEUED return).\nThis can lead to a potential use-after-free when the completion via\nio_rw_done runs at separate context.(CVE-2023-52926)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: fix to shrink read extent node in batches\n\nWe use rwlock to protect core structure data of extent tree during\nits shrink, however, if there is a huge number of extent nodes in\nextent tree, during shrink of extent tree, it may hold rwlock for\na very long time, which may trigger kernel hang issue.\n\nThis patch fixes to shrink read extent node in batches, so that,\ncritical region of the rwlock can be shrunk to avoid its extreme\nlong time hold.(CVE-2024-41935)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndma-debug: fix a possible deadlock on radix_lock\n\nradix_lock() shouldn\u0026apos;t be held while holding dma_hash_entry[idx].lock\notherwise, there\u0026apos;s a possible deadlock scenario when\ndma debug API is called holding rq_lock():\n\nCPU0 CPU1 CPU2\ndma_free_attrs()\ncheck_unmap() add_dma_entry() __schedule() //out\n (A) rq_lock()\nget_hash_bucket()\n(A) dma_entry_hash\n check_sync()\n (A) radix_lock() (W) dma_entry_hash\ndma_entry_free()\n(W) radix_lock()\n // CPU2\u0026apos;s one\n (W) rq_lock()\n\nCPU1 situation can happen when it extending radix tree and\nit tries to wake up kswapd via wake_all_kswapd().\n\nCPU2 situation can happen while perf_event_task_sched_out()\n(i.e. dma sync operation is called while deleting perf_event using\n etm and etr tmc which are Arm Coresight hwtracing driver backends).\n\nTo remove this possible situation, call dma_entry_free() after\nput_hash_bucket() in check_unmap().(CVE-2024-47143)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndlm: fix possible lkb_resource null dereference\n\nThis patch fixes a possible null pointer dereference when this function is\ncalled from request_lock() as lkb-\u0026gt;lkb_resource is not assigned yet,\nonly after validate_lock_args() by calling attach_lkb(). Another issue\nis that a resource name could be a non printable bytearray and we cannot\nassume to be ASCII coded.\n\nThe log functionality is probably never being hit when DLM is used in\nnormal way and no debug logging is enabled. The null pointer dereference\ncan only occur on a new created lkb that does not have the resource\nassigned yet, it probably never hits the null pointer dereference but we\nshould be sure that other changes might not change this behaviour and we\nactually can hit the mentioned null pointer dereference.\n\nIn this patch we just drop the printout of the resource name, the lkb id\nis enough to make a possible connection to a resource name if this\nexists.(CVE-2024-47809)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbcache: revert replacing IS_ERR_OR_NULL with IS_ERR again\n\nCommit 028ddcac477b (\u0026quot;bcache: Remove unnecessary NULL point check in\nnode allocations\u0026quot;) leads a NULL pointer deference in cache_set_flush().\n\n1721 if (!IS_ERR_OR_NULL(c-\u0026gt;root))\n1722 list_add(\u0026amp;c-\u0026gt;root-\u0026gt;list, \u0026amp;c-\u0026gt;btree_cache);\n\n\u0026gt;From the above code in cache_set_flush(), if previous registration code\nfails before allocating c-\u0026gt;root, it is possible c-\u0026gt;root is NULL as what\nit is initialized. __bch_btree_node_alloc() never returns NULL but\nc-\u0026gt;root is possible to be NULL at above line 1721.\n\nThis patch replaces IS_ERR() by IS_ERR_OR_NULL() to fix this.(CVE-2024-48881)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: ipset: add missing range check in bitmap_ip_uadt\n\nWhen tb[IPSET_ATTR_IP_TO] is not present but tb[IPSET_ATTR_CIDR] exists,\nthe values of ip and ip_to are slightly swapped. Therefore, the range check\nfor ip should be done later, but this part is missing and it seems that the\nvulnerability occurs.\n\nSo we should add missing range checks and remove unnecessary range checks.(CVE-2024-53141)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncomedi: Flush partial mappings in error case\n\nIf some remap_pfn_range() calls succeeded before one failed, we still have\nbuffer pages mapped into the userspace page tables when we drop the buffer\nreference with comedi_buf_map_put(bm). The userspace mappings are only\ncleaned up later in the mmap error path.\n\nFix it by explicitly flushing all mappings in our VMA on the error path.\n\nSee commit 79a61cc3fc04 (\u0026quot;mm: avoid leaving partial pfn mappings around in\nerror case\u0026quot;).(CVE-2024-53148)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath9k: add range check for conn_rsp_epid in htc_connect_service()\n\nI found the following bug in my fuzzer:\n\n UBSAN: array-index-out-of-bounds in drivers/net/wireless/ath/ath9k/htc_hst.c:26:51\n index 255 is out of range for type \u0026apos;htc_endpoint [22]\u0026apos;\n CPU: 0 UID: 0 PID: 8 Comm: kworker/0:0 Not tainted 6.11.0-rc6-dirty #14\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014\n Workqueue: events request_firmware_work_func\n Call Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x180/0x1b0\n __ubsan_handle_out_of_bounds+0xd4/0x130\n htc_issue_send.constprop.0+0x20c/0x230\n ? _raw_spin_unlock_irqrestore+0x3c/0x70\n ath9k_wmi_cmd+0x41d/0x610\n ? mark_held_locks+0x9f/0xe0\n ...\n\nSince this bug has been confirmed to be caused by insufficient verification\nof conn_rsp_epid, I think it would be appropriate to add a range check for\nconn_rsp_epid to htc_connect_service() to prevent the bug from occurring.(CVE-2024-53156)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: During unmount, ensure all cached dir instances drop their dentry\n\nThe unmount process (cifs_kill_sb() calling close_all_cached_dirs()) can\nrace with various cached directory operations, which ultimately results\nin dentries not being dropped and these kernel BUGs:\n\nBUG: Dentry ffff88814f37e358{i=1000000000080,n=/} still in use (2) [unmount of cifs cifs]\nVFS: Busy inodes after unmount of cifs (cifs)\n------------[ cut here ]------------\nkernel BUG at fs/super.c:661!\n\nThis happens when a cfid is in the process of being cleaned up when, and\nhas been removed from the cfids-\u0026gt;entries list, including:\n\n- Receiving a lease break from the server\n- Server reconnection triggers invalidate_all_cached_dirs(), which\n removes all the cfids from the list\n- The laundromat thread decides to expire an old cfid.\n\nTo solve these problems, dropping the dentry is done in queued work done\nin a newly-added cfid_put_wq workqueue, and close_all_cached_dirs()\nflushes that workqueue after it drops all the dentries of which it\u0026apos;s\naware. This is a global workqueue (rather than scoped to a mount), but\nthe queued work is minimal.\n\nThe final cleanup work for cleaning up a cfid is performed via work\nqueued in the serverclose_wq workqueue; this is done separate from\ndropping the dentries so that close_all_cached_dirs() doesn\u0026apos;t block on\nany server operations.\n\nBoth of these queued works expect to invoked with a cfid reference and\na tcon reference to avoid those objects from being freed while the work\nis ongoing.\n\nWhile we\u0026apos;re here, add proper locking to close_all_cached_dirs(), and\nlocking around the freeing of cfid-\u0026gt;dentry.(CVE-2024-53176)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: prevent use-after-free due to open_cached_dir error paths\n\nIf open_cached_dir() encounters an error parsing the lease from the\nserver, the error handling may race with receiving a lease break,\nresulting in open_cached_dir() freeing the cfid while the queued work is\npending.\n\nUpdate open_cached_dir() to drop refs rather than directly freeing the\ncfid.\n\nHave cached_dir_lease_break(), cfids_laundromat_worker(), and\ninvalidate_all_cached_dirs() clear has_lease immediately while still\nholding cfids-\u0026gt;cfid_list_lock, and then use this to also simplify the\nreference counting in cfids_laundromat_worker() and\ninvalidate_all_cached_dirs().\n\nFixes this KASAN splat (which manually injects an error and lease break\nin open_cached_dir()):\n\n==================================================================\nBUG: KASAN: slab-use-after-free in smb2_cached_lease_break+0x27/0xb0\nRead of size 8 at addr ffff88811cc24c10 by task kworker/3:1/65\n\nCPU: 3 UID: 0 PID: 65 Comm: kworker/3:1 Not tainted 6.12.0-rc6-g255cf264e6e5-dirty #87\nHardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020\nWorkqueue: cifsiod smb2_cached_lease_break\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x77/0xb0\n print_report+0xce/0x660\n kasan_report+0xd3/0x110\n smb2_cached_lease_break+0x27/0xb0\n process_one_work+0x50a/0xc50\n worker_thread+0x2ba/0x530\n kthread+0x17c/0x1c0\n ret_from_fork+0x34/0x60\n ret_from_fork_asm+0x1a/0x30\n \u0026lt;/TASK\u0026gt;\n\nAllocated by task 2464:\n kasan_save_stack+0x33/0x60\n kasan_save_track+0x14/0x30\n __kasan_kmalloc+0xaa/0xb0\n open_cached_dir+0xa7d/0x1fb0\n smb2_query_path_info+0x43c/0x6e0\n cifs_get_fattr+0x346/0xf10\n cifs_get_inode_info+0x157/0x210\n cifs_revalidate_dentry_attr+0x2d1/0x460\n cifs_getattr+0x173/0x470\n vfs_statx_path+0x10f/0x160\n vfs_statx+0xe9/0x150\n vfs_fstatat+0x5e/0xc0\n __do_sys_newfstatat+0x91/0xf0\n do_syscall_64+0x95/0x1a0\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nFreed by task 2464:\n kasan_save_stack+0x33/0x60\n kasan_save_track+0x14/0x30\n kasan_save_free_info+0x3b/0x60\n __kasan_slab_free+0x51/0x70\n kfree+0x174/0x520\n open_cached_dir+0x97f/0x1fb0\n smb2_query_path_info+0x43c/0x6e0\n cifs_get_fattr+0x346/0xf10\n cifs_get_inode_info+0x157/0x210\n cifs_revalidate_dentry_attr+0x2d1/0x460\n cifs_getattr+0x173/0x470\n vfs_statx_path+0x10f/0x160\n vfs_statx+0xe9/0x150\n vfs_fstatat+0x5e/0xc0\n __do_sys_newfstatat+0x91/0xf0\n do_syscall_64+0x95/0x1a0\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nLast potentially related work creation:\n kasan_save_stack+0x33/0x60\n __kasan_record_aux_stack+0xad/0xc0\n insert_work+0x32/0x100\n __queue_work+0x5c9/0x870\n queue_work_on+0x82/0x90\n open_cached_dir+0x1369/0x1fb0\n smb2_query_path_info+0x43c/0x6e0\n cifs_get_fattr+0x346/0xf10\n cifs_get_inode_info+0x157/0x210\n cifs_revalidate_dentry_attr+0x2d1/0x460\n cifs_getattr+0x173/0x470\n vfs_statx_path+0x10f/0x160\n vfs_statx+0xe9/0x150\n vfs_fstatat+0x5e/0xc0\n __do_sys_newfstatat+0x91/0xf0\n do_syscall_64+0x95/0x1a0\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nThe buggy address belongs to the object at ffff88811cc24c00\n which belongs to the cache kmalloc-1k of size 1024\nThe buggy address is located 16 bytes inside of\n freed 1024-byte region [ffff88811cc24c00, ffff88811cc25000)(CVE-2024-53177)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: Don\u0026apos;t leak cfid when reconnect races with open_cached_dir\n\nopen_cached_dir() may either race with the tcon reconnection even before\ncompound_send_recv() or directly trigger a reconnection via\nSMB2_open_init() or SMB_query_info_init().\n\nThe reconnection process invokes invalidate_all_cached_dirs() via\ncifs_mark_open_files_invalid(), which removes all cfids from the\ncfids-\u0026gt;entries list but doesn\u0026apos;t drop a ref if has_lease isn\u0026apos;t true. This\nresults in the currently-being-constructed cfid not being on the list,\nbut still having a refcount of 2. It leaks if returned from\nopen_cached_dir().\n\nFix this by setting cfid-\u0026gt;has_lease when the ref is actually taken; the\ncfid will not be used by other threads until it has a valid time.\n\nAddresses these kmemleaks:\n\nunreferenced object 0xffff8881090c4000 (size 1024):\n comm \u0026quot;bash\u0026quot;, pid 1860, jiffies 4295126592\n hex dump (first 32 bytes):\n 00 01 00 00 00 00 ad de 22 01 00 00 00 00 ad de ........\u0026quot;.......\n 00 ca 45 22 81 88 ff ff f8 dc 4f 04 81 88 ff ff ..E\u0026quot;......O.....\n backtrace (crc 6f58c20f):\n [\u0026lt;ffffffff8b895a1e\u0026gt;] __kmalloc_cache_noprof+0x2be/0x350\n [\u0026lt;ffffffff8bda06e3\u0026gt;] open_cached_dir+0x993/0x1fb0\n [\u0026lt;ffffffff8bdaa750\u0026gt;] cifs_readdir+0x15a0/0x1d50\n [\u0026lt;ffffffff8b9a853f\u0026gt;] iterate_dir+0x28f/0x4b0\n [\u0026lt;ffffffff8b9a9aed\u0026gt;] __x64_sys_getdents64+0xfd/0x200\n [\u0026lt;ffffffff8cf6da05\u0026gt;] do_syscall_64+0x95/0x1a0\n [\u0026lt;ffffffff8d00012f\u0026gt;] entry_SYSCALL_64_after_hwframe+0x76/0x7e\nunreferenced object 0xffff8881044fdcf8 (size 8):\n comm \u0026quot;bash\u0026quot;, pid 1860, jiffies 4295126592\n hex dump (first 8 bytes):\n 00 cc cc cc cc cc cc cc ........\n backtrace (crc 10c106a9):\n [\u0026lt;ffffffff8b89a3d3\u0026gt;] __kmalloc_node_track_caller_noprof+0x363/0x480\n [\u0026lt;ffffffff8b7d7256\u0026gt;] kstrdup+0x36/0x60\n [\u0026lt;ffffffff8bda0700\u0026gt;] open_cached_dir+0x9b0/0x1fb0\n [\u0026lt;ffffffff8bdaa750\u0026gt;] cifs_readdir+0x15a0/0x1d50\n [\u0026lt;ffffffff8b9a853f\u0026gt;] iterate_dir+0x28f/0x4b0\n [\u0026lt;ffffffff8b9a9aed\u0026gt;] __x64_sys_getdents64+0xfd/0x200\n [\u0026lt;ffffffff8cf6da05\u0026gt;] do_syscall_64+0x95/0x1a0\n [\u0026lt;ffffffff8d00012f\u0026gt;] entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nAnd addresses these BUG splats when unmounting the SMB filesystem:\n\nBUG: Dentry ffff888140590ba0{i=1000000000080,n=/} still in use (2) [unmount of cifs cifs]\nWARNING: CPU: 3 PID: 3433 at fs/dcache.c:1536 umount_check+0xd0/0x100\nModules linked in:\nCPU: 3 UID: 0 PID: 3433 Comm: bash Not tainted 6.12.0-rc4-g850925a8133c-dirty #49\nHardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020\nRIP: 0010:umount_check+0xd0/0x100\nCode: 8d 7c 24 40 e8 31 5a f4 ff 49 8b 54 24 40 41 56 49 89 e9 45 89 e8 48 89 d9 41 57 48 89 de 48 c7 c7 80 e7 db ac e8 f0 72 9a ff \u0026lt;0f\u0026gt; 0b 58 31 c0 5a 5b 5d 41 5c 41 5d 41 5e 41 5f e9 2b e5 5d 01 41\nRSP: 0018:ffff88811cc27978 EFLAGS: 00010286\nRAX: 0000000000000000 RBX: ffff888140590ba0 RCX: ffffffffaaf20bae\nRDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff8881f6fb6f40\nRBP: ffff8881462ec000 R08: 0000000000000001 R09: ffffed1023984ee3\nR10: ffff88811cc2771f R11: 00000000016cfcc0 R12: ffff888134383e08\nR13: 0000000000000002 R14: ffff8881462ec668 R15: ffffffffaceab4c0\nFS: 00007f23bfa98740(0000) GS:ffff8881f6f80000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000556de4a6f808 CR3: 0000000123c80000 CR4: 0000000000350ef0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n d_walk+0x6a/0x530\n shrink_dcache_for_umount+0x6a/0x200\n generic_shutdown_super+0x52/0x2a0\n kill_anon_super+0x22/0x40\n cifs_kill_sb+0x159/0x1e0\n deactivate_locked_super+0x66/0xe0\n cleanup_mnt+0x140/0x210\n task_work_run+0xfb/0x170\n syscall_exit_to_user_mode+0x29f/0x2b0\n do_syscall_64+0xa1/0x1a0\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\nRIP: 0033:0x7f23bfb93ae7\nCode: ff ff ff ff c3 66 0f 1f 44 00 00 48 8b 0d 11 93 0d 00 f7 d8 64 89 01 b8 ff ff ff ff eb bf 0f 1f 44 00 00 b8 50 00 00 00 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 8b 0d e9 92 0d 00 f7 d8 64 89 \n---truncated---(CVE-2024-53178)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\num: vector: Do not use drvdata in release\n\nThe drvdata is not available in release. Let\u0026apos;s just use container_of()\nto get the vector_device instance. Otherwise, removing a vector device\nwill result in a crash:\n\nRIP: 0033:vector_device_release+0xf/0x50\nRSP: 00000000e187bc40 EFLAGS: 00010202\nRAX: 0000000060028f61 RBX: 00000000600f1baf RCX: 00000000620074e0\nRDX: 000000006220b9c0 RSI: 0000000060551c80 RDI: 0000000000000000\nRBP: 00000000e187bc50 R08: 00000000603ad594 R09: 00000000e187bb70\nR10: 000000000000135a R11: 00000000603ad422 R12: 00000000623ae028\nR13: 000000006287a200 R14: 0000000062006d30 R15: 00000000623700b6\nKernel panic - not syncing: Segfault with no mm\nCPU: 0 UID: 0 PID: 16 Comm: kworker/0:1 Not tainted 6.12.0-rc6-g59b723cd2adb #1\nWorkqueue: events mc_work_proc\nStack:\n 60028f61 623ae028 e187bc80 60276fcd\n 6220b9c0 603f5820 623ae028 00000000\n e187bcb0 603a2bcd 623ae000 62370010\nCall Trace:\n [\u0026lt;60028f61\u0026gt;] ? vector_device_release+0x0/0x50\n [\u0026lt;60276fcd\u0026gt;] device_release+0x70/0xba\n [\u0026lt;603a2bcd\u0026gt;] kobject_put+0xba/0xe7\n [\u0026lt;60277265\u0026gt;] put_device+0x19/0x1c\n [\u0026lt;60281266\u0026gt;] platform_device_put+0x26/0x29\n [\u0026lt;60281e5f\u0026gt;] platform_device_unregister+0x2c/0x2e\n [\u0026lt;60029422\u0026gt;] vector_remove+0x52/0x58\n [\u0026lt;60031316\u0026gt;] ? mconsole_reply+0x0/0x50\n [\u0026lt;600310c8\u0026gt;] mconsole_remove+0x160/0x1cc\n [\u0026lt;603b19f4\u0026gt;] ? strlen+0x0/0x15\n [\u0026lt;60066611\u0026gt;] ? __dequeue_entity+0x1a9/0x206\n [\u0026lt;600666a7\u0026gt;] ? set_next_entity+0x39/0x63\n [\u0026lt;6006666e\u0026gt;] ? set_next_entity+0x0/0x63\n [\u0026lt;60038fa6\u0026gt;] ? um_set_signals+0x0/0x43\n [\u0026lt;6003070c\u0026gt;] mc_work_proc+0x77/0x91\n [\u0026lt;60057664\u0026gt;] process_scheduled_works+0x1b3/0x2dd\n [\u0026lt;60055f32\u0026gt;] ? assign_work+0x0/0x58\n [\u0026lt;60057f0a\u0026gt;] worker_thread+0x1e9/0x293\n [\u0026lt;6005406f\u0026gt;] ? set_pf_worker+0x0/0x64\n [\u0026lt;6005d65d\u0026gt;] ? arch_local_irq_save+0x0/0x2d\n [\u0026lt;6005d748\u0026gt;] ? kthread_exit+0x0/0x3a\n [\u0026lt;60057d21\u0026gt;] ? worker_thread+0x0/0x293\n [\u0026lt;6005dbf1\u0026gt;] kthread+0x126/0x12b\n [\u0026lt;600219c5\u0026gt;] new_thread_handler+0x85/0xb6(CVE-2024-53181)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix NULL ptr deref in crypto_aead_setkey()\n\nNeither SMB3.0 or SMB3.02 supports encryption negotiate context, so\nwhen SMB2_GLOBAL_CAP_ENCRYPTION flag is set in the negotiate response,\nthe client uses AES-128-CCM as the default cipher. See MS-SMB2\n3.3.5.4.\n\nCommit b0abcd65ec54 (\u0026quot;smb: client: fix UAF in async decryption\u0026quot;) added\na @server-\u0026gt;cipher_type check to conditionally call\nsmb3_crypto_aead_allocate(), but that check would always be false as\n@server-\u0026gt;cipher_type is unset for SMB3.02.\n\nFix the following KASAN splat by setting @server-\u0026gt;cipher_type for\nSMB3.02 as well.\n\nmount.cifs //srv/share /mnt -o vers=3.02,seal,...\n\nBUG: KASAN: null-ptr-deref in crypto_aead_setkey+0x2c/0x130\nRead of size 8 at addr 0000000000000020 by task mount.cifs/1095\nCPU: 1 UID: 0 PID: 1095 Comm: mount.cifs Not tainted 6.12.0 #1\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-3.fc41\n04/01/2014\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x5d/0x80\n ? crypto_aead_setkey+0x2c/0x130\n kasan_report+0xda/0x110\n ? crypto_aead_setkey+0x2c/0x130\n crypto_aead_setkey+0x2c/0x130\n crypt_message+0x258/0xec0 [cifs]\n ? __asan_memset+0x23/0x50\n ? __pfx_crypt_message+0x10/0x10 [cifs]\n ? mark_lock+0xb0/0x6a0\n ? hlock_class+0x32/0xb0\n ? mark_lock+0xb0/0x6a0\n smb3_init_transform_rq+0x352/0x3f0 [cifs]\n ? lock_acquire.part.0+0xf4/0x2a0\n smb_send_rqst+0x144/0x230 [cifs]\n ? __pfx_smb_send_rqst+0x10/0x10 [cifs]\n ? hlock_class+0x32/0xb0\n ? smb2_setup_request+0x225/0x3a0 [cifs]\n ? __pfx_cifs_compound_last_callback+0x10/0x10 [cifs]\n compound_send_recv+0x59b/0x1140 [cifs]\n ? __pfx_compound_send_recv+0x10/0x10 [cifs]\n ? __create_object+0x5e/0x90\n ? hlock_class+0x32/0xb0\n ? do_raw_spin_unlock+0x9a/0xf0\n cifs_send_recv+0x23/0x30 [cifs]\n SMB2_tcon+0x3ec/0xb30 [cifs]\n ? __pfx_SMB2_tcon+0x10/0x10 [cifs]\n ? lock_acquire.part.0+0xf4/0x2a0\n ? __pfx_lock_release+0x10/0x10\n ? do_raw_spin_trylock+0xc6/0x120\n ? lock_acquire+0x3f/0x90\n ? _get_xid+0x16/0xd0 [cifs]\n ? __pfx_SMB2_tcon+0x10/0x10 [cifs]\n ? cifs_get_smb_ses+0xcdd/0x10a0 [cifs]\n cifs_get_smb_ses+0xcdd/0x10a0 [cifs]\n ? __pfx_cifs_get_smb_ses+0x10/0x10 [cifs]\n ? cifs_get_tcp_session+0xaa0/0xca0 [cifs]\n cifs_mount_get_session+0x8a/0x210 [cifs]\n dfs_mount_share+0x1b0/0x11d0 [cifs]\n ? __pfx___lock_acquire+0x10/0x10\n ? __pfx_dfs_mount_share+0x10/0x10 [cifs]\n ? lock_acquire.part.0+0xf4/0x2a0\n ? find_held_lock+0x8a/0xa0\n ? hlock_class+0x32/0xb0\n ? lock_release+0x203/0x5d0\n cifs_mount+0xb3/0x3d0 [cifs]\n ? do_raw_spin_trylock+0xc6/0x120\n ? __pfx_cifs_mount+0x10/0x10 [cifs]\n ? lock_acquire+0x3f/0x90\n ? find_nls+0x16/0xa0\n ? smb3_update_mnt_flags+0x372/0x3b0 [cifs]\n cifs_smb3_do_mount+0x1e2/0xc80 [cifs]\n ? __pfx_vfs_parse_fs_string+0x10/0x10\n ? __pfx_cifs_smb3_do_mount+0x10/0x10 [cifs]\n smb3_get_tree+0x1bf/0x330 [cifs]\n vfs_get_tree+0x4a/0x160\n path_mount+0x3c1/0xfb0\n ? kasan_quarantine_put+0xc7/0x1d0\n ? __pfx_path_mount+0x10/0x10\n ? kmem_cache_free+0x118/0x3e0\n ? user_path_at+0x74/0xa0\n __x64_sys_mount+0x1a6/0x1e0\n ? __pfx___x64_sys_mount+0x10/0x10\n ? mark_held_locks+0x1a/0x90\n do_syscall_64+0xbb/0x1d0\n entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2024-53185)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ns390/iucv: MSG_PEEK causes memory leak in iucv_sock_destruct()\n\nPassing MSG_PEEK flag to skb_recv_datagram() increments skb refcount\n(skb-\u0026gt;users) and iucv_sock_recvmsg() does not decrement skb refcount\nat exit.\nThis results in skb memory leak in skb_queue_purge() and WARN_ON in\niucv_sock_destruct() during socket close. To fix this decrease\nskb refcount by one if MSG_PEEK is set in order to prevent memory\nleak and WARN_ON.\n\nWARNING: CPU: 2 PID: 6292 at net/iucv/af_iucv.c:286 iucv_sock_destruct+0x144/0x1a0 [af_iucv]\nCPU: 2 PID: 6292 Comm: afiucv_test_msg Kdump: loaded Tainted: G W 6.10.0-rc7 #1\nHardware name: IBM 3931 A01 704 (z/VM 7.3.0)\nCall Trace:\n [\u0026lt;001587c682c4aa98\u0026gt;] iucv_sock_destruct+0x148/0x1a0 [af_iucv]\n [\u0026lt;001587c682c4a9d0\u0026gt;] iucv_sock_destruct+0x80/0x1a0 [af_iucv]\n [\u0026lt;001587c704117a32\u0026gt;] __sk_destruct+0x52/0x550\n [\u0026lt;001587c704104a54\u0026gt;] __sock_release+0xa4/0x230\n [\u0026lt;001587c704104c0c\u0026gt;] sock_close+0x2c/0x40\n [\u0026lt;001587c702c5f5a8\u0026gt;] __fput+0x2e8/0x970\n [\u0026lt;001587c7024148c4\u0026gt;] task_work_run+0x1c4/0x2c0\n [\u0026lt;001587c7023b0716\u0026gt;] do_exit+0x996/0x1050\n [\u0026lt;001587c7023b13aa\u0026gt;] do_group_exit+0x13a/0x360\n [\u0026lt;001587c7023b1626\u0026gt;] __s390x_sys_exit_group+0x56/0x60\n [\u0026lt;001587c7022bccca\u0026gt;] do_syscall+0x27a/0x380\n [\u0026lt;001587c7049a6a0c\u0026gt;] __do_syscall+0x9c/0x160\n [\u0026lt;001587c7049ce8a8\u0026gt;] system_call+0x70/0x98\n Last Breaking-Event-Address:\n [\u0026lt;001587c682c4a9d4\u0026gt;] iucv_sock_destruct+0x84/0x1a0 [af_iucv](CVE-2024-53210)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvfio/pci: Properly hide first-in-list PCIe extended capability\n\nThere are cases where a PCIe extended capability should be hidden from\nthe user. For example, an unknown capability (i.e., capability with ID\ngreater than PCI_EXT_CAP_ID_MAX) or a capability that is intentionally\nchosen to be hidden from the user.\n\nHiding a capability is done by virtualizing and modifying the \u0026apos;Next\nCapability Offset\u0026apos; field of the previous capability so it points to the\ncapability after the one that should be hidden.\n\nThe special case where the first capability in the list should be hidden\nis handled differently because there is no previous capability that can\nbe modified. In this case, the capability ID and version are zeroed\nwhile leaving the next pointer intact. This hides the capability and\nleaves an anchor for the rest of the capability list.\n\nHowever, today, hiding the first capability in the list is not done\nproperly if the capability is unknown, as struct\nvfio_pci_core_device-\u0026gt;pci_config_map is set to the capability ID during\ninitialization but the capability ID is not properly checked later when\nused in vfio_config_do_rw(). This leads to the following warning [1] and\nto an out-of-bounds access to ecap_perms array.\n\nFix it by checking cap_id in vfio_config_do_rw(), and if it is greater\nthan PCI_EXT_CAP_ID_MAX, use an alternative struct perm_bits for direct\nread only access instead of the ecap_perms array.\n\nNote that this is safe since the above is the only case where cap_id can\nexceed PCI_EXT_CAP_ID_MAX (except for the special capabilities, which\nare already checked before).\n\n[1]\n\nWARNING: CPU: 118 PID: 5329 at drivers/vfio/pci/vfio_pci_config.c:1900 vfio_pci_config_rw+0x395/0x430 [vfio_pci_core]\nCPU: 118 UID: 0 PID: 5329 Comm: simx-qemu-syste Not tainted 6.12.0+ #1\n(snip)\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? show_regs+0x69/0x80\n ? __warn+0x8d/0x140\n ? vfio_pci_config_rw+0x395/0x430 [vfio_pci_core]\n ? report_bug+0x18f/0x1a0\n ? handle_bug+0x63/0xa0\n ? exc_invalid_op+0x19/0x70\n ? asm_exc_invalid_op+0x1b/0x20\n ? vfio_pci_config_rw+0x395/0x430 [vfio_pci_core]\n ? vfio_pci_config_rw+0x244/0x430 [vfio_pci_core]\n vfio_pci_rw+0x101/0x1b0 [vfio_pci_core]\n vfio_pci_core_read+0x1d/0x30 [vfio_pci_core]\n vfio_device_fops_read+0x27/0x40 [vfio]\n vfs_read+0xbd/0x340\n ? vfio_device_fops_unl_ioctl+0xbb/0x740 [vfio]\n ? __rseq_handle_notify_resume+0xa4/0x4b0\n __x64_sys_pread64+0x96/0xc0\n x64_sys_call+0x1c3d/0x20d0\n do_syscall_64+0x4d/0x120\n entry_SYSCALL_64_after_hwframe+0x76/0x7e(CVE-2024-53214)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: release svc_expkey/svc_export with rcu_work\n\nThe last reference for `cache_head` can be reduced to zero in `c_show`\nand `e_show`(using `rcu_read_lock` and `rcu_read_unlock`). Consequently,\n`svc_export_put` and `expkey_put` will be invoked, leading to two\nissues:\n\n1. The `svc_export_put` will directly free ex_uuid. However,\n `e_show`/`c_show` will access `ex_uuid` after `cache_put`, which can\n trigger a use-after-free issue, shown below.\n\n ==================================================================\n BUG: KASAN: slab-use-after-free in svc_export_show+0x362/0x430 [nfsd]\n Read of size 1 at addr ff11000010fdc120 by task cat/870\n\n CPU: 1 UID: 0 PID: 870 Comm: cat Not tainted 6.12.0-rc3+ #1\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS\n 1.16.1-2.fc37 04/01/2014\n Call Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x53/0x70\n print_address_description.constprop.0+0x2c/0x3a0\n print_report+0xb9/0x280\n kasan_report+0xae/0xe0\n svc_export_show+0x362/0x430 [nfsd]\n c_show+0x161/0x390 [sunrpc]\n seq_read_iter+0x589/0x770\n seq_read+0x1e5/0x270\n proc_reg_read+0xe1/0x140\n vfs_read+0x125/0x530\n ksys_read+0xc1/0x160\n do_syscall_64+0x5f/0x170\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\n Allocated by task 830:\n kasan_save_stack+0x20/0x40\n kasan_save_track+0x14/0x30\n __kasan_kmalloc+0x8f/0xa0\n __kmalloc_node_track_caller_noprof+0x1bc/0x400\n kmemdup_noprof+0x22/0x50\n svc_export_parse+0x8a9/0xb80 [nfsd]\n cache_do_downcall+0x71/0xa0 [sunrpc]\n cache_write_procfs+0x8e/0xd0 [sunrpc]\n proc_reg_write+0xe1/0x140\n vfs_write+0x1a5/0x6d0\n ksys_write+0xc1/0x160\n do_syscall_64+0x5f/0x170\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\n Freed by task 868:\n kasan_save_stack+0x20/0x40\n kasan_save_track+0x14/0x30\n kasan_save_free_info+0x3b/0x60\n __kasan_slab_free+0x37/0x50\n kfree+0xf3/0x3e0\n svc_export_put+0x87/0xb0 [nfsd]\n cache_purge+0x17f/0x1f0 [sunrpc]\n nfsd_destroy_serv+0x226/0x2d0 [nfsd]\n nfsd_svc+0x125/0x1e0 [nfsd]\n write_threads+0x16a/0x2a0 [nfsd]\n nfsctl_transaction_write+0x74/0xa0 [nfsd]\n vfs_write+0x1a5/0x6d0\n ksys_write+0xc1/0x160\n do_syscall_64+0x5f/0x170\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\n2. We cannot sleep while using `rcu_read_lock`/`rcu_read_unlock`.\n However, `svc_export_put`/`expkey_put` will call path_put, which\n subsequently triggers a sleeping operation due to the following\n `dput`.\n\n =============================\n WARNING: suspicious RCU usage\n 5.10.0-dirty #141 Not tainted\n -----------------------------\n ...\n Call Trace:\n dump_stack+0x9a/0xd0\n ___might_sleep+0x231/0x240\n dput+0x39/0x600\n path_put+0x1b/0x30\n svc_export_put+0x17/0x80\n e_show+0x1c9/0x200\n seq_read_iter+0x63f/0x7c0\n seq_read+0x226/0x2d0\n vfs_read+0x113/0x2c0\n ksys_read+0xc9/0x170\n do_syscall_64+0x33/0x40\n entry_SYSCALL_64_after_hwframe+0x67/0xd1\n\nFix these issues by using `rcu_work` to help release\n`svc_expkey`/`svc_export`. This approach allows for an asynchronous\ncontext to invoke `path_put` and also facilitates the freeing of\n`uuid/exp/key` after an RCU grace period.(CVE-2024-53216)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nunicode: Fix utf8_load() error path\n\nutf8_load() requests the symbol \u0026quot;utf8_data_table\u0026quot; and then checks if the\nrequested UTF-8 version is supported. If it\u0026apos;s unsupported, it tries to\nput the data table using symbol_put(). If an unsupported version is\nrequested, symbol_put() fails like this:\n\n kernel BUG at kernel/module/main.c:786!\n RIP: 0010:__symbol_put+0x93/0xb0\n Call Trace:\n \u0026lt;TASK\u0026gt;\n ? __die_body.cold+0x19/0x27\n ? die+0x2e/0x50\n ? do_trap+0xca/0x110\n ? do_error_trap+0x65/0x80\n ? __symbol_put+0x93/0xb0\n ? exc_invalid_op+0x51/0x70\n ? __symbol_put+0x93/0xb0\n ? asm_exc_invalid_op+0x1a/0x20\n ? __pfx_cmp_name+0x10/0x10\n ? __symbol_put+0x93/0xb0\n ? __symbol_put+0x62/0xb0\n utf8_load+0xf8/0x150\n\nThat happens because symbol_put() expects the unique string that\nidentify the symbol, instead of a pointer to the loaded symbol. Fix that\nby using such string.(CVE-2024-53233)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFS: Fix potential buffer overflowin nfs_sysfs_link_rpc_client()\n\nname is char[64] where the size of clnt-\u0026gt;cl_program-\u0026gt;name remains\nunknown. Invoking strcat() directly will also lead to potential buffer\noverflow. Change them to strscpy() and strncat() to fix potential\nissues.(CVE-2024-54456)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nALSA: caiaq: Use snd_card_free_when_closed() at disconnection\n\nThe USB disconnect callback is supposed to be short and not too-long\nwaiting. OTOH, the current code uses snd_card_free() at\ndisconnection, but this waits for the close of all used fds, hence it\ncan take long. It eventually blocks the upper layer USB ioctls, which\nmay trigger a soft lockup.\n\nAn easy workaround is to replace snd_card_free() with\nsnd_card_free_when_closed(). This variant returns immediately while\nthe release of resources is done asynchronously by the card device\nrelease at the last close.\n\nThis patch also splits the code to the disconnect and the free phases;\nthe former is called immediately at the USB disconnect callback while\nthe latter is called from the card destructor.(CVE-2024-56531)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nALSA: usx2y: Use snd_card_free_when_closed() at disconnection\n\nThe USB disconnect callback is supposed to be short and not too-long\nwaiting. OTOH, the current code uses snd_card_free() at\ndisconnection, but this waits for the close of all used fds, hence it\ncan take long. It eventually blocks the upper layer USB ioctls, which\nmay trigger a soft lockup.\n\nAn easy workaround is to replace snd_card_free() with\nsnd_card_free_when_closed(). This variant returns immediately while\nthe release of resources is done asynchronously by the card device\nrelease at the last close.(CVE-2024-56533)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mwifiex: Fix memcpy() field-spanning write warning in mwifiex_config_scan()\n\nReplace one-element array with a flexible-array member in `struct\nmwifiex_ie_types_wildcard_ssid_params` to fix the following warning\non a MT8173 Chromebook (mt8173-elm-hana):\n\n[ 356.775250] ------------[ cut here ]------------\n[ 356.784543] memcpy: detected field-spanning write (size 6) of single field \u0026quot;wildcard_ssid_tlv-\u0026gt;ssid\u0026quot; at drivers/net/wireless/marvell/mwifiex/scan.c:904 (size 1)\n[ 356.813403] WARNING: CPU: 3 PID: 742 at drivers/net/wireless/marvell/mwifiex/scan.c:904 mwifiex_scan_networks+0x4fc/0xf28 [mwifiex]\n\nThe \u0026quot;(size 6)\u0026quot; above is exactly the length of the SSID of the network\nthis device was connected to. The source of the warning looks like:\n\n ssid_len = user_scan_in-\u0026gt;ssid_list[i].ssid_len;\n [...]\n memcpy(wildcard_ssid_tlv-\u0026gt;ssid,\n user_scan_in-\u0026gt;ssid_list[i].ssid, ssid_len);\n\nThere is a #define WILDCARD_SSID_TLV_MAX_SIZE that uses sizeof() on this\nstruct, but it already didn\u0026apos;t account for the size of the one-element\narray, so it doesn\u0026apos;t need to be changed.(CVE-2024-56539)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: hyperv: streamline driver probe to avoid devres issues\n\nIt was found that unloading \u0026apos;hid_hyperv\u0026apos; module results in a devres\ncomplaint:\n\n ...\n hv_vmbus: unregistering driver hid_hyperv\n ------------[ cut here ]------------\n WARNING: CPU: 2 PID: 3983 at drivers/base/devres.c:691 devres_release_group+0x1f2/0x2c0\n ...\n Call Trace:\n \u0026lt;TASK\u0026gt;\n ? devres_release_group+0x1f2/0x2c0\n ? __warn+0xd1/0x1c0\n ? devres_release_group+0x1f2/0x2c0\n ? report_bug+0x32a/0x3c0\n ? handle_bug+0x53/0xa0\n ? exc_invalid_op+0x18/0x50\n ? asm_exc_invalid_op+0x1a/0x20\n ? devres_release_group+0x1f2/0x2c0\n ? devres_release_group+0x90/0x2c0\n ? rcu_is_watching+0x15/0xb0\n ? __pfx_devres_release_group+0x10/0x10\n hid_device_remove+0xf5/0x220\n device_release_driver_internal+0x371/0x540\n ? klist_put+0xf3/0x170\n bus_remove_device+0x1f1/0x3f0\n device_del+0x33f/0x8c0\n ? __pfx_device_del+0x10/0x10\n ? cleanup_srcu_struct+0x337/0x500\n hid_destroy_device+0xc8/0x130\n mousevsc_remove+0xd2/0x1d0 [hid_hyperv]\n device_release_driver_internal+0x371/0x540\n driver_detach+0xc5/0x180\n bus_remove_driver+0x11e/0x2a0\n ? __mutex_unlock_slowpath+0x160/0x5e0\n vmbus_driver_unregister+0x62/0x2b0 [hv_vmbus]\n ...\n\nAnd the issue seems to be that the corresponding devres group is not\nallocated. Normally, devres_open_group() is called from\n__hid_device_probe() but Hyper-V HID driver overrides \u0026apos;hid_dev-\u0026gt;driver\u0026apos;\nwith \u0026apos;mousevsc_hid_driver\u0026apos; stub and basically re-implements\n__hid_device_probe() by calling hid_parse() and hid_hw_start() but not\ndevres_open_group(). hid_device_probe() does not call __hid_device_probe()\nfor it. Later, when the driver is removed, hid_device_remove() calls\ndevres_release_group() as it doesn\u0026apos;t check whether hdev-\u0026gt;driver was\ninitially overridden or not.\n\nThe issue seems to be related to the commit 62c68e7cee33 (\u0026quot;HID: ensure\ntimely release of driver-allocated resources\u0026quot;) but the commit itself seems\nto be correct.\n\nFix the issue by dropping the \u0026apos;hid_dev-\u0026gt;driver\u0026apos; override and using\nhid_register_driver()/hid_unregister_driver() instead. Alternatively, it\nwould have been possible to rely on the default handling but\nHID_CONNECT_DEFAULT implies HID_CONNECT_HIDRAW and it doesn\u0026apos;t seem to work\nfor mousevsc as-is.(CVE-2024-56545)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu: fix usage slab after free\n\n[ +0.000021] BUG: KASAN: slab-use-after-free in drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched]\n[ +0.000027] Read of size 8 at addr ffff8881b8605f88 by task amd_pci_unplug/2147\n\n[ +0.000023] CPU: 6 PID: 2147 Comm: amd_pci_unplug Not tainted 6.10.0+ #1\n[ +0.000016] Hardware name: ASUS System Product Name/ROG STRIX B550-F GAMING (WI-FI), BIOS 1401 12/03/2020\n[ +0.000016] Call Trace:\n[ +0.000008] \u0026lt;TASK\u0026gt;\n[ +0.000009] dump_stack_lvl+0x76/0xa0\n[ +0.000017] print_report+0xce/0x5f0\n[ +0.000017] ? drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched]\n[ +0.000019] ? srso_return_thunk+0x5/0x5f\n[ +0.000015] ? kasan_complete_mode_report_info+0x72/0x200\n[ +0.000016] ? drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched]\n[ +0.000019] kasan_report+0xbe/0x110\n[ +0.000015] ? drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched]\n[ +0.000023] __asan_report_load8_noabort+0x14/0x30\n[ +0.000014] drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched]\n[ +0.000020] ? srso_return_thunk+0x5/0x5f\n[ +0.000013] ? __kasan_check_write+0x14/0x30\n[ +0.000016] ? __pfx_drm_sched_entity_flush+0x10/0x10 [gpu_sched]\n[ +0.000020] ? srso_return_thunk+0x5/0x5f\n[ +0.000013] ? __kasan_check_write+0x14/0x30\n[ +0.000013] ? srso_return_thunk+0x5/0x5f\n[ +0.000013] ? enable_work+0x124/0x220\n[ +0.000015] ? __pfx_enable_work+0x10/0x10\n[ +0.000013] ? srso_return_thunk+0x5/0x5f\n[ +0.000014] ? free_large_kmalloc+0x85/0xf0\n[ +0.000016] drm_sched_entity_destroy+0x18/0x30 [gpu_sched]\n[ +0.000020] amdgpu_vce_sw_fini+0x55/0x170 [amdgpu]\n[ +0.000735] ? __kasan_check_read+0x11/0x20\n[ +0.000016] vce_v4_0_sw_fini+0x80/0x110 [amdgpu]\n[ +0.000726] amdgpu_device_fini_sw+0x331/0xfc0 [amdgpu]\n[ +0.000679] ? mutex_unlock+0x80/0xe0\n[ +0.000017] ? __pfx_amdgpu_device_fini_sw+0x10/0x10 [amdgpu]\n[ +0.000662] ? srso_return_thunk+0x5/0x5f\n[ +0.000014] ? __kasan_check_write+0x14/0x30\n[ +0.000013] ? srso_return_thunk+0x5/0x5f\n[ +0.000013] ? mutex_unlock+0x80/0xe0\n[ +0.000016] amdgpu_driver_release_kms+0x16/0x80 [amdgpu]\n[ +0.000663] drm_minor_release+0xc9/0x140 [drm]\n[ +0.000081] drm_release+0x1fd/0x390 [drm]\n[ +0.000082] __fput+0x36c/0xad0\n[ +0.000018] __fput_sync+0x3c/0x50\n[ +0.000014] __x64_sys_close+0x7d/0xe0\n[ +0.000014] x64_sys_call+0x1bc6/0x2680\n[ +0.000014] do_syscall_64+0x70/0x130\n[ +0.000014] ? srso_return_thunk+0x5/0x5f\n[ +0.000014] ? irqentry_exit_to_user_mode+0x60/0x190\n[ +0.000015] ? srso_return_thunk+0x5/0x5f\n[ +0.000014] ? irqentry_exit+0x43/0x50\n[ +0.000012] ? srso_return_thunk+0x5/0x5f\n[ +0.000013] ? exc_page_fault+0x7c/0x110\n[ +0.000015] entry_SYSCALL_64_after_hwframe+0x76/0x7e\n[ +0.000014] RIP: 0033:0x7ffff7b14f67\n[ +0.000013] Code: ff e8 0d 16 02 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 03 00 00 00 0f 05 \u0026lt;48\u0026gt; 3d 00 f0 ff ff 77 41 c3 48 83 ec 18 89 7c 24 0c e8 73 ba f7 ff\n[ +0.000026] RSP: 002b:00007fffffffe378 EFLAGS: 00000246 ORIG_RAX: 0000000000000003\n[ +0.000019] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007ffff7b14f67\n[ +0.000014] RDX: 0000000000000000 RSI: 00007ffff7f6f47a RDI: 0000000000000003\n[ +0.000014] RBP: 00007fffffffe3a0 R08: 0000555555569890 R09: 0000000000000000\n[ +0.000014] R10: 0000000000000000 R11: 0000000000000246 R12: 00007fffffffe5c8\n[ +0.000013] R13: 00005555555552a9 R14: 0000555555557d48 R15: 00007ffff7ffd040\n[ +0.000020] \u0026lt;/TASK\u0026gt;\n\n[ +0.000016] Allocated by task 383 on cpu 7 at 26.880319s:\n[ +0.000014] kasan_save_stack+0x28/0x60\n[ +0.000008] kasan_save_track+0x18/0x70\n[ +0.000007] kasan_save_alloc_info+0x38/0x60\n[ +0.000007] __kasan_kmalloc+0xc1/0xd0\n[ +0.000007] kmalloc_trace_noprof+0x180/0x380\n[ +0.000007] drm_sched_init+0x411/0xec0 [gpu_sched]\n[ +0.000012] amdgpu_device_init+0x695f/0xa610 [amdgpu]\n[ +0.000658] amdgpu_driver_load_kms+0x1a/0x120 [amdgpu]\n[ +0.000662] amdgpu_pci_p\n---truncated---(CVE-2024-56551)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: make sure exp active before svc_export_show\n\nThe function `e_show` was called with protection from RCU. This only\nensures that `exp` will not be freed. Therefore, the reference count for\n`exp` can drop to zero, which will trigger a refcount use-after-free\nwarning when `exp_get` is called. To resolve this issue, use\n`cache_get_rcu` to ensure that `exp` remains active.\n\n------------[ cut here ]------------\nrefcount_t: addition on 0; use-after-free.\nWARNING: CPU: 3 PID: 819 at lib/refcount.c:25\nrefcount_warn_saturate+0xb1/0x120\nCPU: 3 UID: 0 PID: 819 Comm: cat Not tainted 6.12.0-rc3+ #1\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS\n1.16.1-2.fc37 04/01/2014\nRIP: 0010:refcount_warn_saturate+0xb1/0x120\n...\nCall Trace:\n \u0026lt;TASK\u0026gt;\n e_show+0x20b/0x230 [nfsd]\n seq_read_iter+0x589/0x770\n seq_read+0x1e5/0x270\n vfs_read+0x125/0x530\n ksys_read+0xc1/0x160\n do_syscall_64+0x5f/0x170\n entry_SYSCALL_64_after_hwframe+0x76/0x7e(CVE-2024-56558)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/slub: Avoid list corruption when removing a slab from the full list\n\nBoot with slub_debug=UFPZ.\n\nIf allocated object failed in alloc_consistency_checks, all objects of\nthe slab will be marked as used, and then the slab will be removed from\nthe partial list.\n\nWhen an object belonging to the slab got freed later, the remove_full()\nfunction is called. Because the slab is neither on the partial list nor\non the full list, it eventually lead to a list corruption (actually a\nlist poison being detected).\n\nSo we need to mark and isolate the slab page with metadata corruption,\ndo not put it back in circulation.\n\nBecause the debug caches avoid all the fastpaths, reusing the frozen bit\nto mark slab page with metadata corruption seems to be fine.\n\n[ 4277.385669] list_del corruption, ffffea00044b3e50-\u0026gt;next is LIST_POISON1 (dead000000000100)\n[ 4277.387023] ------------[ cut here ]------------\n[ 4277.387880] kernel BUG at lib/list_debug.c:56!\n[ 4277.388680] invalid opcode: 0000 [#1] PREEMPT SMP PTI\n[ 4277.389562] CPU: 5 PID: 90 Comm: kworker/5:1 Kdump: loaded Tainted: G OE 6.6.1-1 #1\n[ 4277.392113] Workqueue: xfs-inodegc/vda1 xfs_inodegc_worker [xfs]\n[ 4277.393551] RIP: 0010:__list_del_entry_valid_or_report+0x7b/0xc0\n[ 4277.394518] Code: 48 91 82 e8 37 f9 9a ff 0f 0b 48 89 fe 48 c7 c7 28 49 91 82 e8 26 f9 9a ff 0f 0b 48 89 fe 48 c7 c7 58 49 91\n[ 4277.397292] RSP: 0018:ffffc90000333b38 EFLAGS: 00010082\n[ 4277.398202] RAX: 000000000000004e RBX: ffffea00044b3e50 RCX: 0000000000000000\n[ 4277.399340] RDX: 0000000000000002 RSI: ffffffff828f8715 RDI: 00000000ffffffff\n[ 4277.400545] RBP: ffffea00044b3e40 R08: 0000000000000000 R09: ffffc900003339f0\n[ 4277.401710] R10: 0000000000000003 R11: ffffffff82d44088 R12: ffff888112cf9910\n[ 4277.402887] R13: 0000000000000001 R14: 0000000000000001 R15: ffff8881000424c0\n[ 4277.404049] FS: 0000000000000000(0000) GS:ffff88842fd40000(0000) knlGS:0000000000000000\n[ 4277.405357] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 4277.406389] CR2: 00007f2ad0b24000 CR3: 0000000102a3a006 CR4: 00000000007706e0\n[ 4277.407589] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[ 4277.408780] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[ 4277.410000] PKRU: 55555554\n[ 4277.410645] Call Trace:\n[ 4277.411234] \u0026lt;TASK\u0026gt;\n[ 4277.411777] ? die+0x32/0x80\n[ 4277.412439] ? do_trap+0xd6/0x100\n[ 4277.413150] ? __list_del_entry_valid_or_report+0x7b/0xc0\n[ 4277.414158] ? do_error_trap+0x6a/0x90\n[ 4277.414948] ? __list_del_entry_valid_or_report+0x7b/0xc0\n[ 4277.415915] ? exc_invalid_op+0x4c/0x60\n[ 4277.416710] ? __list_del_entry_valid_or_report+0x7b/0xc0\n[ 4277.417675] ? asm_exc_invalid_op+0x16/0x20\n[ 4277.418482] ? __list_del_entry_valid_or_report+0x7b/0xc0\n[ 4277.419466] ? __list_del_entry_valid_or_report+0x7b/0xc0\n[ 4277.420410] free_to_partial_list+0x515/0x5e0\n[ 4277.421242] ? xfs_iext_remove+0x41a/0xa10 [xfs]\n[ 4277.422298] xfs_iext_remove+0x41a/0xa10 [xfs]\n[ 4277.423316] ? xfs_inodegc_worker+0xb4/0x1a0 [xfs]\n[ 4277.424383] xfs_bmap_del_extent_delay+0x4fe/0x7d0 [xfs]\n[ 4277.425490] __xfs_bunmapi+0x50d/0x840 [xfs]\n[ 4277.426445] xfs_itruncate_extents_flags+0x13a/0x490 [xfs]\n[ 4277.427553] xfs_inactive_truncate+0xa3/0x120 [xfs]\n[ 4277.428567] xfs_inactive+0x22d/0x290 [xfs]\n[ 4277.429500] xfs_inodegc_worker+0xb4/0x1a0 [xfs]\n[ 4277.430479] process_one_work+0x171/0x340\n[ 4277.431227] worker_thread+0x277/0x390\n[ 4277.431962] ? __pfx_worker_thread+0x10/0x10\n[ 4277.432752] kthread+0xf0/0x120\n[ 4277.433382] ? __pfx_kthread+0x10/0x10\n[ 4277.434134] ret_from_fork+0x2d/0x50\n[ 4277.434837] ? __pfx_kthread+0x10/0x10\n[ 4277.435566] ret_from_fork_asm+0x1b/0x30\n[ 4277.436280] \u0026lt;/TASK\u0026gt;(CVE-2024-56566)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nefi/libstub: Free correct pointer on failure\n\ncmdline_ptr is an out parameter, which is not allocated by the function\nitself, and likely points into the caller\u0026apos;s stack.\n\ncmdline refers to the pool allocation that should be freed when cleaning\nup after a failure, so pass this instead to free_pool().(CVE-2024-56573)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: ts2020: fix null-ptr-deref in ts2020_probe()\n\nKASAN reported a null-ptr-deref issue when executing the following\ncommand:\n\n # echo ts2020 0x20 \u0026gt; /sys/bus/i2c/devices/i2c-0/new_device\n KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]\n CPU: 53 UID: 0 PID: 970 Comm: systemd-udevd Not tainted 6.12.0-rc2+ #24\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009)\n RIP: 0010:ts2020_probe+0xad/0xe10 [ts2020]\n RSP: 0018:ffffc9000abbf598 EFLAGS: 00010202\n RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffffc0714809\n RDX: 0000000000000002 RSI: ffff88811550be00 RDI: 0000000000000010\n RBP: ffff888109868800 R08: 0000000000000001 R09: fffff52001577eb6\n R10: 0000000000000000 R11: ffffc9000abbff50 R12: ffffffffc0714790\n R13: 1ffff92001577eb8 R14: ffffffffc07190d0 R15: 0000000000000001\n FS: 00007f95f13b98c0(0000) GS:ffff888149280000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 0000555d2634b000 CR3: 0000000152236000 CR4: 00000000000006f0\n DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n Call Trace:\n \u0026lt;TASK\u0026gt;\n ts2020_probe+0xad/0xe10 [ts2020]\n i2c_device_probe+0x421/0xb40\n really_probe+0x266/0x850\n ...\n\nThe cause of the problem is that when using sysfs to dynamically register\nan i2c device, there is no platform data, but the probe process of ts2020\nneeds to use platform data, resulting in a null pointer being accessed.\n\nSolve this problem by adding checks to platform data.(CVE-2024-56574)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: i2c: tc358743: Fix crash in the probe error path when using polling\n\nIf an error occurs in the probe() function, we should remove the polling\ntimer that was alarmed earlier, otherwise the timer is called with\narguments that are already freed, which results in a crash.\n\n------------[ cut here ]------------\nWARNING: CPU: 3 PID: 0 at kernel/time/timer.c:1830 __run_timers+0x244/0x268\nModules linked in:\nCPU: 3 UID: 0 PID: 0 Comm: swapper/3 Not tainted 6.11.0 #226\nHardware name: Diasom DS-RK3568-SOM-EVB (DT)\npstate: 804000c9 (Nzcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : __run_timers+0x244/0x268\nlr : __run_timers+0x1d4/0x268\nsp : ffffff80eff2baf0\nx29: ffffff80eff2bb50 x28: 7fffffffffffffff x27: ffffff80eff2bb00\nx26: ffffffc080f669c0 x25: ffffff80efef6bf0 x24: ffffff80eff2bb00\nx23: 0000000000000000 x22: dead000000000122 x21: 0000000000000000\nx20: ffffff80efef6b80 x19: ffffff80041c8bf8 x18: ffffffffffffffff\nx17: ffffffc06f146000 x16: ffffff80eff27dc0 x15: 000000000000003e\nx14: 0000000000000000 x13: 00000000000054da x12: 0000000000000000\nx11: 00000000000639c0 x10: 000000000000000c x9 : 0000000000000009\nx8 : ffffff80eff2cb40 x7 : ffffff80eff2cb40 x6 : ffffff8002bee480\nx5 : ffffffc080cb2220 x4 : ffffffc080cb2150 x3 : 00000000000f4240\nx2 : 0000000000000102 x1 : ffffff80eff2bb00 x0 : ffffff80041c8bf0\nCall trace:\n\u00a0__run_timers+0x244/0x268\n\u00a0timer_expire_remote+0x50/0x68\n\u00a0tmigr_handle_remote+0x388/0x39c\n\u00a0run_timer_softirq+0x38/0x44\n\u00a0handle_softirqs+0x138/0x298\n\u00a0__do_softirq+0x14/0x20\n\u00a0____do_softirq+0x10/0x1c\n\u00a0call_on_irq_stack+0x24/0x4c\n\u00a0do_softirq_own_stack+0x1c/0x2c\n\u00a0irq_exit_rcu+0x9c/0xcc\n\u00a0el1_interrupt+0x48/0xc0\n\u00a0el1h_64_irq_handler+0x18/0x24\n\u00a0el1h_64_irq+0x7c/0x80\n\u00a0default_idle_call+0x34/0x68\n\u00a0do_idle+0x23c/0x294\n\u00a0cpu_startup_entry+0x38/0x3c\n\u00a0secondary_start_kernel+0x128/0x160\n\u00a0__secondary_switched+0xb8/0xbc\n---[ end trace 0000000000000000 ]---(CVE-2024-56576)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: mtk-jpeg: Fix null-ptr-deref during unload module\n\nThe workqueue should be destroyed in mtk_jpeg_core.c since commit\n09aea13ecf6f (\u0026quot;media: mtk-jpeg: refactor some variables\u0026quot;), otherwise\nthe below calltrace can be easily triggered.\n\n[ 677.862514] Unable to handle kernel paging request at virtual address dfff800000000023\n[ 677.863633] KASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f]\n...\n[ 677.879654] CPU: 6 PID: 1071 Comm: modprobe Tainted: G O 6.8.12-mtk+gfa1a78e5d24b+ #17\n...\n[ 677.882838] pc : destroy_workqueue+0x3c/0x770\n[ 677.883413] lr : mtk_jpegdec_destroy_workqueue+0x70/0x88 [mtk_jpeg_dec_hw]\n[ 677.884314] sp : ffff80008ad974f0\n[ 677.884744] x29: ffff80008ad974f0 x28: ffff0000d7115580 x27: ffff0000dd691070\n[ 677.885669] x26: ffff0000dd691408 x25: ffff8000844af3e0 x24: ffff80008ad97690\n[ 677.886592] x23: ffff0000e051d400 x22: ffff0000dd691010 x21: dfff800000000000\n[ 677.887515] x20: 0000000000000000 x19: 0000000000000000 x18: ffff800085397ac0\n[ 677.888438] x17: 0000000000000000 x16: ffff8000801b87c8 x15: 1ffff000115b2e10\n[ 677.889361] x14: 00000000f1f1f1f1 x13: 0000000000000000 x12: ffff7000115b2e4d\n[ 677.890285] x11: 1ffff000115b2e4c x10: ffff7000115b2e4c x9 : ffff80000aa43e90\n[ 677.891208] x8 : 00008fffeea4d1b4 x7 : ffff80008ad97267 x6 : 0000000000000001\n[ 677.892131] x5 : ffff80008ad97260 x4 : ffff7000115b2e4d x3 : 0000000000000000\n[ 677.893054] x2 : 0000000000000023 x1 : dfff800000000000 x0 : 0000000000000118\n[ 677.893977] Call trace:\n[ 677.894297] destroy_workqueue+0x3c/0x770\n[ 677.894826] mtk_jpegdec_destroy_workqueue+0x70/0x88 [mtk_jpeg_dec_hw]\n[ 677.895677] devm_action_release+0x50/0x90\n[ 677.896211] release_nodes+0xe8/0x170\n[ 677.896688] devres_release_all+0xf8/0x178\n[ 677.897219] device_unbind_cleanup+0x24/0x170\n[ 677.897785] device_release_driver_internal+0x35c/0x480\n[ 677.898461] device_release_driver+0x20/0x38\n...\n[ 677.912665] ---[ end trace 0000000000000000 ]---(CVE-2024-56577)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: amphion: Set video drvdata before register video device\n\nThe video drvdata should be set before the video device is registered,\notherwise video_drvdata() may return NULL in the open() file ops, and led\nto oops.(CVE-2024-56579)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nleds: class: Protect brightness_show() with led_cdev-\u0026gt;led_access mutex\n\nThere is NULL pointer issue observed if from Process A where hid device\nbeing added which results in adding a led_cdev addition and later a\nanother call to access of led_cdev attribute from Process B can result\nin NULL pointer issue.\n\nUse mutex led_cdev-\u0026gt;led_access to protect access to led-\u0026gt;cdev and its\nattribute inside brightness_show() and max_brightness_show() and also\nupdate the comment for mutex that it should be used to protect the led\nclass device fields.\n\n\tProcess A \t\t\t\tProcess B\n\n kthread+0x114\n worker_thread+0x244\n process_scheduled_works+0x248\n uhid_device_add_worker+0x24\n hid_add_device+0x120\n device_add+0x268\n bus_probe_device+0x94\n device_initial_probe+0x14\n __device_attach+0xfc\n bus_for_each_drv+0x10c\n __device_attach_driver+0x14c\n driver_probe_device+0x3c\n __driver_probe_device+0xa0\n really_probe+0x190\n hid_device_probe+0x130\n ps_probe+0x990\n ps_led_register+0x94\n devm_led_classdev_register_ext+0x58\n led_classdev_register_ext+0x1f8\n device_create_with_groups+0x48\n device_create_groups_vargs+0xc8\n device_add+0x244\n kobject_uevent+0x14\n kobject_uevent_env[jt]+0x224\n mutex_unlock[jt]+0xc4\n __mutex_unlock_slowpath+0xd4\n wake_up_q+0x70\n try_to_wake_up[jt]+0x48c\n preempt_schedule_common+0x28\n __schedule+0x628\n __switch_to+0x174\n\t\t\t\t\t\tel0t_64_sync+0x1a8/0x1ac\n\t\t\t\t\t\tel0t_64_sync_handler+0x68/0xbc\n\t\t\t\t\t\tel0_svc+0x38/0x68\n\t\t\t\t\t\tdo_el0_svc+0x1c/0x28\n\t\t\t\t\t\tel0_svc_common+0x80/0xe0\n\t\t\t\t\t\tinvoke_syscall+0x58/0x114\n\t\t\t\t\t\t__arm64_sys_read+0x1c/0x2c\n\t\t\t\t\t\tksys_read+0x78/0xe8\n\t\t\t\t\t\tvfs_read+0x1e0/0x2c8\n\t\t\t\t\t\tkernfs_fop_read_iter+0x68/0x1b4\n\t\t\t\t\t\tseq_read_iter+0x158/0x4ec\n\t\t\t\t\t\tkernfs_seq_show+0x44/0x54\n\t\t\t\t\t\tsysfs_kf_seq_show+0xb4/0x130\n\t\t\t\t\t\tdev_attr_show+0x38/0x74\n\t\t\t\t\t\tbrightness_show+0x20/0x4c\n\t\t\t\t\t\tdualshock4_led_get_brightness+0xc/0x74\n\n[ 3313.874295][ T4013] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000060\n[ 3313.874301][ T4013] Mem abort info:\n[ 3313.874303][ T4013] ESR = 0x0000000096000006\n[ 3313.874305][ T4013] EC = 0x25: DABT (current EL), IL = 32 bits\n[ 3313.874307][ T4013] SET = 0, FnV = 0\n[ 3313.874309][ T4013] EA = 0, S1PTW = 0\n[ 3313.874311][ T4013] FSC = 0x06: level 2 translation fault\n[ 3313.874313][ T4013] Data abort info:\n[ 3313.874314][ T4013] ISV = 0, ISS = 0x00000006, ISS2 = 0x00000000\n[ 3313.874316][ T4013] CM = 0, WnR = 0, TnD = 0, TagAccess = 0\n[ 3313.874318][ T4013] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\n[ 3313.874320][ T4013] user pgtable: 4k pages, 39-bit VAs, pgdp=00000008f2b0a000\n..\n\n[ 3313.874332][ T4013] Dumping ftrace buffer:\n[ 3313.874334][ T4013] (ftrace buffer empty)\n..\n..\n[ dd3313.874639][ T4013] CPU: 6 PID: 4013 Comm: InputReader\n[ 3313.874648][ T4013] pc : dualshock4_led_get_brightness+0xc/0x74\n[ 3313.874653][ T4013] lr : led_update_brightness+0x38/0x60\n[ 3313.874656][ T4013] sp : ffffffc0b910bbd0\n..\n..\n[ 3313.874685][ T4013] Call trace:\n[ 3313.874687][ T4013] dualshock4_led_get_brightness+0xc/0x74\n[ 3313.874690][ T4013] brightness_show+0x20/0x4c\n[ 3313.874692][ T4013] dev_attr_show+0x38/0x74\n[ 3313.874696][ T4013] sysfs_kf_seq_show+0xb4/0x130\n[ 3313.874700][ T4013] kernfs_seq_show+0x44/0x54\n[ 3313.874703][ T4013] seq_read_iter+0x158/0x4ec\n[ 3313.874705][ T4013] kernfs_fop_read_iter+0x68/0x1b4\n[ 3313.874708][ T4013] vfs_read+0x1e0/0x2c8\n[ 3313.874711][ T4013] ksys_read+0x78/0xe8\n[ 3313.874714][ T4013] __arm64_sys_read+0x1c/0x2c\n[ 3313.874718][ T4013] invoke_syscall+0x58/0x114\n[ 3313.874721][ T4013] el0_svc_common+0x80/0xe0\n[ 3313.874724][ T4013] do_el0_svc+0x1c/0x28\n[ 3313.874727][ T4013] el0_svc+0x38/0x68\n[ 3313.874730][ T4013] el0t_64_sync_handler+0x68/0xbc\n[ 3313.874732][ T4013] el0t_64_sync+0x1a8/0x1ac(CVE-2024-56587)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: brcmfmac: Fix oops due to NULL pointer dereference in brcmf_sdiod_sglist_rw()\n\nThis patch fixes a NULL pointer dereference bug in brcmfmac that occurs\nwhen a high \u0026apos;sd_sgentry_align\u0026apos; value applies (e.g. 512) and a lot of queued SKBs\nare sent from the pkt queue.\n\nThe problem is the number of entries in the pre-allocated sgtable, it is\nnents = max(rxglom_size, txglom_size) + max(rxglom_size, txglom_size) \u0026gt;\u0026gt; 4 + 1.\nGiven the default [rt]xglom_size=32 it\u0026apos;s actually 35 which is too small.\nWorst case, the pkt queue can end up with 64 SKBs. This occurs when a new SKB\nis added for each original SKB if tailroom isn\u0026apos;t enough to hold tail_pad.\nAt least one sg entry is needed for each SKB. So, eventually the \u0026quot;skb_queue_walk loop\u0026quot;\nin brcmf_sdiod_sglist_rw may run out of sg entries. This makes sg_next return\nNULL and this causes the oops.\n\nThe patch sets nents to max(rxglom_size, txglom_size) * 2 to be able handle\nthe worst-case.\nBtw. this requires only 64-35=29 * 16 (or 20 if CONFIG_NEED_SG_DMA_LENGTH) = 464\nadditional bytes of memory.(CVE-2024-56593)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: inet6: do not leave a dangling sk pointer in inet6_create()\n\nsock_init_data() attaches the allocated sk pointer to the provided sock\nobject. If inet6_create() fails later, the sk object is released, but the\nsock object retains the dangling sk pointer, which may cause use-after-free\nlater.\n\nClear the sock sk pointer on error.(CVE-2024-56600)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: inet: do not leave a dangling sk pointer in inet_create()\n\nsock_init_data() attaches the allocated sk object to the provided sock\nobject. If inet_create() fails later, the sk object is freed, but the\nsock object retains the dangling pointer, which may create use-after-free\nlater.\n\nClear the sk pointer in the sock object on error.(CVE-2024-56601)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: ieee802154: do not leave a dangling sk pointer in ieee802154_create()\n\nsock_init_data() attaches the allocated sk object to the provided sock\nobject. If ieee802154_create() fails later, the allocated sk object is\nfreed, but the dangling pointer remains in the provided sock object, which\nmay allow use-after-free.\n\nClear the sk pointer in the sock object on error.(CVE-2024-56602)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: af_can: do not leave a dangling sk pointer in can_create()\n\nOn error can_create() frees the allocated sk object, but sock_init_data()\nhas already attached it to the provided sock object. This will leave a\ndangling sk pointer in the sock object and may cause use-after-free later.(CVE-2024-56603)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\naf_packet: avoid erroring out after sock_init_data() in packet_create()\n\nAfter sock_init_data() the allocated sk object is attached to the provided\nsock object. On error, packet_create() frees the sk object leaving the\ndangling pointer in the sock object on return. Some other code may try\nto use this pointer and cause use-after-free.(CVE-2024-56606)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncan: dev: can_set_termination(): allow sleeping GPIOs\n\nIn commit 6e86a1543c37 (\u0026quot;can: dev: provide optional GPIO based\ntermination support\u0026quot;) GPIO based termination support was added.\n\nFor no particular reason that patch uses gpiod_set_value() to set the\nGPIO. This leads to the following warning, if the systems uses a\nsleeping GPIO, i.e. behind an I2C port expander:\n\n| WARNING: CPU: 0 PID: 379 at /drivers/gpio/gpiolib.c:3496 gpiod_set_value+0x50/0x6c\n| CPU: 0 UID: 0 PID: 379 Comm: ip Not tainted 6.11.0-20241016-1 #1 823affae360cc91126e4d316d7a614a8bf86236c\n\nReplace gpiod_set_value() by gpiod_set_value_cansleep() to allow the\nuse of sleeping GPIOs.(CVE-2024-56625)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nLoongArch: Add architecture specific huge_pte_clear()\n\nWhen executing mm selftests run_vmtests.sh, there is such an error:\n\n BUG: Bad page state in process uffd-unit-tests pfn:00000\n page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x0\n flags: 0xffff0000002000(reserved|node=0|zone=0|lastcpupid=0xffff)\n raw: 00ffff0000002000 ffffbf0000000008 ffffbf0000000008 0000000000000000\n raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000\n page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set\n Modules linked in: snd_seq_dummy snd_seq snd_seq_device rfkill vfat fat\n virtio_balloon efi_pstore virtio_net pstore net_failover failover fuse\n nfnetlink virtio_scsi virtio_gpu virtio_dma_buf dm_multipath efivarfs\n CPU: 2 UID: 0 PID: 1913 Comm: uffd-unit-tests Not tainted 6.12.0 #184\n Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 2/2/2022\n Stack : 900000047c8ac000 0000000000000000 9000000000223a7c 900000047c8ac000\n 900000047c8af690 900000047c8af698 0000000000000000 900000047c8af7d8\n 900000047c8af7d0 900000047c8af7d0 900000047c8af5b0 0000000000000001\n 0000000000000001 900000047c8af698 10b3c7d53da40d26 0000010000000000\n 0000000000000022 0000000fffffffff fffffffffe000000 ffff800000000000\n 000000000000002f 0000800000000000 000000017a6d4000 90000000028f8940\n 0000000000000000 0000000000000000 90000000025aa5e0 9000000002905000\n 0000000000000000 90000000028f8940 ffff800000000000 0000000000000000\n 0000000000000000 0000000000000000 9000000000223a94 000000012001839c\n 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1d\n ...\n Call Trace:\n [\u0026lt;9000000000223a94\u0026gt;] show_stack+0x5c/0x180\n [\u0026lt;9000000001c3fd64\u0026gt;] dump_stack_lvl+0x6c/0xa0\n [\u0026lt;900000000056aa08\u0026gt;] bad_page+0x1a0/0x1f0\n [\u0026lt;9000000000574978\u0026gt;] free_unref_folios+0xbf0/0xd20\n [\u0026lt;90000000004e65cc\u0026gt;] folios_put_refs+0x1a4/0x2b8\n [\u0026lt;9000000000599a0c\u0026gt;] free_pages_and_swap_cache+0x164/0x260\n [\u0026lt;9000000000547698\u0026gt;] tlb_batch_pages_flush+0xa8/0x1c0\n [\u0026lt;9000000000547f30\u0026gt;] tlb_finish_mmu+0xa8/0x218\n [\u0026lt;9000000000543cb8\u0026gt;] exit_mmap+0x1a0/0x360\n [\u0026lt;9000000000247658\u0026gt;] __mmput+0x78/0x200\n [\u0026lt;900000000025583c\u0026gt;] do_exit+0x43c/0xde8\n [\u0026lt;9000000000256490\u0026gt;] do_group_exit+0x68/0x110\n [\u0026lt;9000000000256554\u0026gt;] sys_exit_group+0x1c/0x20\n [\u0026lt;9000000001c413b4\u0026gt;] do_syscall+0x94/0x130\n [\u0026lt;90000000002216d8\u0026gt;] handle_syscall+0xb8/0x158\n Disabling lock debugging due to kernel taint\n BUG: non-zero pgtables_bytes on freeing mm: -16384\n\nOn LoongArch system, invalid huge pte entry should be invalid_pte_table\nor a single _PAGE_HUGE bit rather than a zero value. And it should be\nthe same with invalid pmd entry, since pmd_none() is called by function\nfree_pgd_range() and pmd_none() return 0 by huge_pte_clear(). So single\n_PAGE_HUGE bit is also treated as a valid pte table and free_pte_range()\nwill be called in free_pmd_range().\n\n free_pmd_range()\n pmd = pmd_offset(pud, addr);\n do {\n next = pmd_addr_end(addr, end);\n if (pmd_none_or_clear_bad(pmd))\n continue;\n free_pte_range(tlb, pmd, addr);\n } while (pmd++, addr = next, addr != end);\n\nHere invalid_pte_table is used for both invalid huge pte entry and\npmd entry.(CVE-2024-56628)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ngeneve: do not assume mac header is set in geneve_xmit_skb()\n\nWe should not assume mac header is set in output path.\n\nUse skb_eth_hdr() instead of eth_hdr() to fix the issue.\n\nsysbot reported the following :\n\n WARNING: CPU: 0 PID: 11635 at include/linux/skbuff.h:3052 skb_mac_header include/linux/skbuff.h:3052 [inline]\n WARNING: CPU: 0 PID: 11635 at include/linux/skbuff.h:3052 eth_hdr include/linux/if_ether.h:24 [inline]\n WARNING: CPU: 0 PID: 11635 at include/linux/skbuff.h:3052 geneve_xmit_skb drivers/net/geneve.c:898 [inline]\n WARNING: CPU: 0 PID: 11635 at include/linux/skbuff.h:3052 geneve_xmit+0x4c38/0x5730 drivers/net/geneve.c:1039\nModules linked in:\nCPU: 0 UID: 0 PID: 11635 Comm: syz.4.1423 Not tainted 6.12.0-syzkaller-10296-gaaf20f870da0 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024\n RIP: 0010:skb_mac_header include/linux/skbuff.h:3052 [inline]\n RIP: 0010:eth_hdr include/linux/if_ether.h:24 [inline]\n RIP: 0010:geneve_xmit_skb drivers/net/geneve.c:898 [inline]\n RIP: 0010:geneve_xmit+0x4c38/0x5730 drivers/net/geneve.c:1039\nCode: 21 c6 02 e9 35 d4 ff ff e8 a5 48 4c fb 90 0f 0b 90 e9 fd f5 ff ff e8 97 48 4c fb 90 0f 0b 90 e9 d8 f5 ff ff e8 89 48 4c fb 90 \u0026lt;0f\u0026gt; 0b 90 e9 41 e4 ff ff e8 7b 48 4c fb 90 0f 0b 90 e9 cd e7 ff ff\nRSP: 0018:ffffc90003b2f870 EFLAGS: 00010283\nRAX: 000000000000037a RBX: 000000000000ffff RCX: ffffc9000dc3d000\nRDX: 0000000000080000 RSI: ffffffff86428417 RDI: 0000000000000003\nRBP: ffffc90003b2f9f0 R08: 0000000000000003 R09: 000000000000ffff\nR10: 000000000000ffff R11: 0000000000000002 R12: ffff88806603c000\nR13: 0000000000000000 R14: ffff8880685b2780 R15: 0000000000000e23\nFS: 00007fdc2deed6c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000001b30a1dff8 CR3: 0000000056b8c000 CR4: 00000000003526f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __netdev_start_xmit include/linux/netdevice.h:5002 [inline]\n netdev_start_xmit include/linux/netdevice.h:5011 [inline]\n __dev_direct_xmit+0x58a/0x720 net/core/dev.c:4490\n dev_direct_xmit include/linux/netdevice.h:3181 [inline]\n packet_xmit+0x1e4/0x360 net/packet/af_packet.c:285\n packet_snd net/packet/af_packet.c:3146 [inline]\n packet_sendmsg+0x2700/0x5660 net/packet/af_packet.c:3178\n sock_sendmsg_nosec net/socket.c:711 [inline]\n __sock_sendmsg net/socket.c:726 [inline]\n __sys_sendto+0x488/0x4f0 net/socket.c:2197\n __do_sys_sendto net/socket.c:2204 [inline]\n __se_sys_sendto net/socket.c:2200 [inline]\n __x64_sys_sendto+0xe0/0x1c0 net/socket.c:2200\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2024-56636)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: ipset: Hold module reference while requesting a module\n\nUser space may unload ip_set.ko while it is itself requesting a set type\nbackend module, leading to a kernel crash. The race condition may be\nprovoked by inserting an mdelay() right after the nfnl_unlock() call.(CVE-2024-56637)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndccp: Fix memory leak in dccp_feat_change_recv\n\nIf dccp_feat_push_confirm() fails after new value for SP feature was accepted\nwithout reconciliation (\u0026apos;entry == NULL\u0026apos; branch), memory allocated for that value\nwith dccp_feat_clone_sp_val() is never freed.\n\nHere is the kmemleak stack for this:\n\nunreferenced object 0xffff88801d4ab488 (size 8):\n comm \u0026quot;syz-executor310\u0026quot;, pid 1127, jiffies 4295085598 (age 41.666s)\n hex dump (first 8 bytes):\n 01 b4 4a 1d 80 88 ff ff ..J.....\n backtrace:\n [\u0026lt;00000000db7cabfe\u0026gt;] kmemdup+0x23/0x50 mm/util.c:128\n [\u0026lt;0000000019b38405\u0026gt;] kmemdup include/linux/string.h:465 [inline]\n [\u0026lt;0000000019b38405\u0026gt;] dccp_feat_clone_sp_val net/dccp/feat.c:371 [inline]\n [\u0026lt;0000000019b38405\u0026gt;] dccp_feat_clone_sp_val net/dccp/feat.c:367 [inline]\n [\u0026lt;0000000019b38405\u0026gt;] dccp_feat_change_recv net/dccp/feat.c:1145 [inline]\n [\u0026lt;0000000019b38405\u0026gt;] dccp_feat_parse_options+0x1196/0x2180 net/dccp/feat.c:1416\n [\u0026lt;00000000b1f6d94a\u0026gt;] dccp_parse_options+0xa2a/0x1260 net/dccp/options.c:125\n [\u0026lt;0000000030d7b621\u0026gt;] dccp_rcv_state_process+0x197/0x13d0 net/dccp/input.c:650\n [\u0026lt;000000001f74c72e\u0026gt;] dccp_v4_do_rcv+0xf9/0x1a0 net/dccp/ipv4.c:688\n [\u0026lt;00000000a6c24128\u0026gt;] sk_backlog_rcv include/net/sock.h:1041 [inline]\n [\u0026lt;00000000a6c24128\u0026gt;] __release_sock+0x139/0x3b0 net/core/sock.c:2570\n [\u0026lt;00000000cf1f3a53\u0026gt;] release_sock+0x54/0x1b0 net/core/sock.c:3111\n [\u0026lt;000000008422fa23\u0026gt;] inet_wait_for_connect net/ipv4/af_inet.c:603 [inline]\n [\u0026lt;000000008422fa23\u0026gt;] __inet_stream_connect+0x5d0/0xf70 net/ipv4/af_inet.c:696\n [\u0026lt;0000000015b6f64d\u0026gt;] inet_stream_connect+0x53/0xa0 net/ipv4/af_inet.c:735\n [\u0026lt;0000000010122488\u0026gt;] __sys_connect_file+0x15c/0x1a0 net/socket.c:1865\n [\u0026lt;00000000b4b70023\u0026gt;] __sys_connect+0x165/0x1a0 net/socket.c:1882\n [\u0026lt;00000000f4cb3815\u0026gt;] __do_sys_connect net/socket.c:1892 [inline]\n [\u0026lt;00000000f4cb3815\u0026gt;] __se_sys_connect net/socket.c:1889 [inline]\n [\u0026lt;00000000f4cb3815\u0026gt;] __x64_sys_connect+0x6e/0xb0 net/socket.c:1889\n [\u0026lt;00000000e7b1e839\u0026gt;] do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46\n [\u0026lt;0000000055e91434\u0026gt;] entry_SYSCALL_64_after_hwframe+0x67/0xd1\n\nClean up the allocated memory in case of dccp_feat_push_confirm() failure\nand bail out with an error reset code.\n\nFound by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2024-56643)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/ipv6: release expired exception dst cached in socket\n\nDst objects get leaked in ip6_negative_advice() when this function is\nexecuted for an expired IPv6 route located in the exception table. There\nare several conditions that must be fulfilled for the leak to occur:\n* an ICMPv6 packet indicating a change of the MTU for the path is received,\n resulting in an exception dst being created\n* a TCP connection that uses the exception dst for routing packets must\n start timing out so that TCP begins retransmissions\n* after the exception dst expires, the FIB6 garbage collector must not run\n before TCP executes ip6_negative_advice() for the expired exception dst\n\nWhen TCP executes ip6_negative_advice() for an exception dst that has\nexpired and if no other socket holds a reference to the exception dst, the\nrefcount of the exception dst is 2, which corresponds to the increment\nmade by dst_init() and the increment made by the TCP socket for which the\nconnection is timing out. The refcount made by the socket is never\nreleased. The refcount of the dst is decremented in sk_dst_reset() but\nthat decrement is counteracted by a dst_hold() intentionally placed just\nbefore the sk_dst_reset() in ip6_negative_advice(). After\nip6_negative_advice() has finished, there is no other object tied to the\ndst. The socket lost its reference stored in sk_dst_cache and the dst is\nno longer in the exception table. The exception dst becomes a leaked\nobject.\n\nAs a result of this dst leak, an unbalanced refcount is reported for the\nloopback device of a net namespace being destroyed under kernels that do\nnot contain e5f80fcf869a (\u0026quot;ipv6: give an IPv6 dev to blackhole_netdev\u0026quot;):\nunregister_netdevice: waiting for lo to become free. Usage count = 2\n\nFix the dst leak by removing the dst_hold() in ip6_negative_advice(). The\npatch that introduced the dst_hold() in ip6_negative_advice() was\n92f1655aa2b22 (\u0026quot;net: fix __dst_negative_advice() race\u0026quot;). But 92f1655aa2b22\nmerely refactored the code with regards to the dst refcount so the issue\nwas present even before 92f1655aa2b22. The bug was introduced in\n54c1a859efd9f (\u0026quot;ipv6: Don\u0026apos;t drop cache route entry unless timer actually\nexpired.\u0026quot;) where the expired cached route is deleted and the sk_dst_cache\nmember of the socket is set to NULL by calling dst_negative_advice() but\nthe refcount belonging to the socket is left unbalanced.\n\nThe IPv4 version - ipv4_negative_advice() - is not affected by this bug.\nWhen the TCP connection times out ipv4_negative_advice() merely resets the\nsk_dst_cache of the socket while decrementing the refcount of the\nexception dst.(CVE-2024-56644)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncan: j1939: j1939_session_new(): fix skb reference counting\n\nSince j1939_session_skb_queue() does an extra skb_get() for each new\nskb, do the same for the initial one in j1939_session_new() to avoid\nrefcount underflow.\n\n[mkl: clean up commit message](CVE-2024-56645)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: x_tables: fix LED ID check in led_tg_check()\n\nSyzbot has reported the following BUG detected by KASAN:\n\nBUG: KASAN: slab-out-of-bounds in strlen+0x58/0x70\nRead of size 1 at addr ffff8881022da0c8 by task repro/5879\n...\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x241/0x360\n ? __pfx_dump_stack_lvl+0x10/0x10\n ? __pfx__printk+0x10/0x10\n ? _printk+0xd5/0x120\n ? __virt_addr_valid+0x183/0x530\n ? __virt_addr_valid+0x183/0x530\n print_report+0x169/0x550\n ? __virt_addr_valid+0x183/0x530\n ? __virt_addr_valid+0x183/0x530\n ? __virt_addr_valid+0x45f/0x530\n ? __phys_addr+0xba/0x170\n ? strlen+0x58/0x70\n kasan_report+0x143/0x180\n ? strlen+0x58/0x70\n strlen+0x58/0x70\n kstrdup+0x20/0x80\n led_tg_check+0x18b/0x3c0\n xt_check_target+0x3bb/0xa40\n ? __pfx_xt_check_target+0x10/0x10\n ? stack_depot_save_flags+0x6e4/0x830\n ? nft_target_init+0x174/0xc30\n nft_target_init+0x82d/0xc30\n ? __pfx_nft_target_init+0x10/0x10\n ? nf_tables_newrule+0x1609/0x2980\n ? nf_tables_newrule+0x1609/0x2980\n ? rcu_is_watching+0x15/0xb0\n ? nf_tables_newrule+0x1609/0x2980\n ? nf_tables_newrule+0x1609/0x2980\n ? __kmalloc_noprof+0x21a/0x400\n nf_tables_newrule+0x1860/0x2980\n ? __pfx_nf_tables_newrule+0x10/0x10\n ? __nla_parse+0x40/0x60\n nfnetlink_rcv+0x14e5/0x2ab0\n ? __pfx_validate_chain+0x10/0x10\n ? __pfx_nfnetlink_rcv+0x10/0x10\n ? __lock_acquire+0x1384/0x2050\n ? netlink_deliver_tap+0x2e/0x1b0\n ? __pfx_lock_release+0x10/0x10\n ? netlink_deliver_tap+0x2e/0x1b0\n netlink_unicast+0x7f8/0x990\n ? __pfx_netlink_unicast+0x10/0x10\n ? __virt_addr_valid+0x183/0x530\n ? __check_object_size+0x48e/0x900\n netlink_sendmsg+0x8e4/0xcb0\n ? __pfx_netlink_sendmsg+0x10/0x10\n ? aa_sock_msg_perm+0x91/0x160\n ? __pfx_netlink_sendmsg+0x10/0x10\n __sock_sendmsg+0x223/0x270\n ____sys_sendmsg+0x52a/0x7e0\n ? __pfx_____sys_sendmsg+0x10/0x10\n __sys_sendmsg+0x292/0x380\n ? __pfx___sys_sendmsg+0x10/0x10\n ? lockdep_hardirqs_on_prepare+0x43d/0x780\n ? __pfx_lockdep_hardirqs_on_prepare+0x10/0x10\n ? exc_page_fault+0x590/0x8c0\n ? do_syscall_64+0xb6/0x230\n do_syscall_64+0xf3/0x230\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n...\n \u0026lt;/TASK\u0026gt;\n\nSince an invalid (without \u0026apos;\\0\u0026apos; byte at all) byte sequence may be passed\nfrom userspace, add an extra check to ensure that such a sequence is\nrejected as possible ID and so never passed to \u0026apos;kstrdup()\u0026apos; and further.(CVE-2024-56650)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncan: hi311x: hi3110_can_ist(): fix potential use-after-free\n\nThe commit a22bd630cfff (\u0026quot;can: hi311x: do not report txerr and rxerr\nduring bus-off\u0026quot;) removed the reporting of rxerr and txerr even in case\nof correct operation (i. e. not bus-off).\n\nThe error count information added to the CAN frame after netif_rx() is\na potential use after free, since there is no guarantee that the skb\nis in the same state. It might be freed or reused.\n\nFix the issue by postponing the netif_rx() call in case of txerr and\nrxerr reporting.(CVE-2024-56651)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/mm/fault: Fix kfence page fault reporting\n\ncopy_from_kernel_nofault() can be called when doing read of /proc/kcore.\n/proc/kcore can have some unmapped kfence objects which when read via\ncopy_from_kernel_nofault() can cause page faults. Since *_nofault()\nfunctions define their own fixup table for handling fault, use that\ninstead of asking kfence to handle such faults.\n\nHence we search the exception tables for the nip which generated the\nfault. If there is an entry then we let the fixup table handler handle the\npage fault by returning an error from within ___do_page_fault().\n\nThis can be easily triggered if someone tries to do dd from /proc/kcore.\neg. dd if=/proc/kcore of=/dev/null bs=1M\n\nSome example false negatives:\n\n ===============================\n BUG: KFENCE: invalid read in copy_from_kernel_nofault+0x9c/0x1a0\n Invalid read at 0xc0000000fdff0000:\n copy_from_kernel_nofault+0x9c/0x1a0\n 0xc00000000665f950\n read_kcore_iter+0x57c/0xa04\n proc_reg_read_iter+0xe4/0x16c\n vfs_read+0x320/0x3ec\n ksys_read+0x90/0x154\n system_call_exception+0x120/0x310\n system_call_vectored_common+0x15c/0x2ec\n\n BUG: KFENCE: use-after-free read in copy_from_kernel_nofault+0x9c/0x1a0\n Use-after-free read at 0xc0000000fe050000 (in kfence-#2):\n copy_from_kernel_nofault+0x9c/0x1a0\n 0xc00000000665f950\n read_kcore_iter+0x57c/0xa04\n proc_reg_read_iter+0xe4/0x16c\n vfs_read+0x320/0x3ec\n ksys_read+0x90/0x154\n system_call_exception+0x120/0x310\n system_call_vectored_common+0x15c/0x2ec(CVE-2024-56678)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nPCI: endpoint: epf-mhi: Avoid NULL dereference if DT lacks \u0026apos;mmio\u0026apos;\n\nIf platform_get_resource_byname() fails and returns NULL because DT lacks\nan \u0026apos;mmio\u0026apos; property for the MHI endpoint, dereferencing res-\u0026gt;start will\ncause a NULL pointer access. Add a check to prevent it.\n\n[kwilczynski: error message update per the review feedback]\n[bhelgaas: commit log](CVE-2024-56689)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\n9p/xen: fix release of IRQ\n\nKernel logs indicate an IRQ was double-freed.\n\nPass correct device ID during IRQ release.\n\n[Dominique: remove confusing variable reset to 0](CVE-2024-56704)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nocteontx2-pf: handle otx2_mbox_get_rsp errors in otx2_dmac_flt.c\n\nAdd error pointer checks after calling otx2_mbox_get_rsp().(CVE-2024-56707)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmfd: intel_soc_pmic_bxtwc: Use IRQ domain for PMIC devices\n\nWhile design wise the idea of converting the driver to use\nthe hierarchy of the IRQ chips is correct, the implementation\nhas (inherited) flaws. This was unveiled when platform_get_irq()\nhad started WARN() on IRQ 0 that is supposed to be a Linux\nIRQ number (also known as vIRQ).\n\nRework the driver to respect IRQ domain when creating each MFD\ndevice separately, as the domain is not the same for all of them.(CVE-2024-56723)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmfd: intel_soc_pmic_bxtwc: Use IRQ domain for TMU device\n\nWhile design wise the idea of converting the driver to use\nthe hierarchy of the IRQ chips is correct, the implementation\nhas (inherited) flaws. This was unveiled when platform_get_irq()\nhad started WARN() on IRQ 0 that is supposed to be a Linux\nIRQ number (also known as vIRQ).\n\nRework the driver to respect IRQ domain when creating each MFD\ndevice separately, as the domain is not the same for all of them.(CVE-2024-56724)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nocteontx2-pf: handle otx2_mbox_get_rsp errors in otx2_dcbnl.c\n\nAdd error pointer check after calling otx2_mbox_get_rsp().(CVE-2024-56725)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nocteontx2-pf: handle otx2_mbox_get_rsp errors in otx2_flows.c\n\nAdding error pointer check after calling otx2_mbox_get_rsp().(CVE-2024-56727)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfbdev: sh7760fb: Fix a possible memory leak in sh7760fb_alloc_mem()\n\nWhen information such as info-\u0026gt;screen_base is not ready, calling\nsh7760fb_free_mem() does not release memory correctly. Call\ndma_free_coherent() instead.(CVE-2024-56746)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: release nexthop on device removal\n\nThe CI is hitting some aperiodic hangup at device removal time in the\npmtu.sh self-test:\n\nunregister_netdevice: waiting for veth_A-R1 to become free. Usage count = 6\nref_tracker: veth_A-R1@ffff888013df15d8 has 1/5 users at\n\tdst_init+0x84/0x4a0\n\tdst_alloc+0x97/0x150\n\tip6_dst_alloc+0x23/0x90\n\tip6_rt_pcpu_alloc+0x1e6/0x520\n\tip6_pol_route+0x56f/0x840\n\tfib6_rule_lookup+0x334/0x630\n\tip6_route_output_flags+0x259/0x480\n\tip6_dst_lookup_tail.constprop.0+0x5c2/0x940\n\tip6_dst_lookup_flow+0x88/0x190\n\tudp_tunnel6_dst_lookup+0x2a7/0x4c0\n\tvxlan_xmit_one+0xbde/0x4a50 [vxlan]\n\tvxlan_xmit+0x9ad/0xf20 [vxlan]\n\tdev_hard_start_xmit+0x10e/0x360\n\t__dev_queue_xmit+0xf95/0x18c0\n\tarp_solicit+0x4a2/0xe00\n\tneigh_probe+0xaa/0xf0\n\nWhile the first suspect is the dst_cache, explicitly tracking the dst\nowing the last device reference via probes proved such dst is held by\nthe nexthop in the originating fib6_info.\n\nSimilar to commit f5b51fe804ec (\u0026quot;ipv6: route: purge exception on\nremoval\u0026quot;), we need to explicitly release the originating fib info when\ndisconnecting a to-be-removed device from a live ipv6 dst: move the\nfib6_info cleanup into ip6_dst_ifdown().\n\nTested running:\n\n./pmtu.sh cleanup_ipv6_exception\n\nin a tight loop for more than 400 iterations with no spat, running an\nunpatched kernel I observed a splat every ~10 iterations.(CVE-2024-56751)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: caam - Fix the pointer passed to caam_qi_shutdown()\n\nThe type of the last parameter given to devm_add_action_or_reset() is\n\u0026quot;struct caam_drv_private *\u0026quot;, but in caam_qi_shutdown(), it is casted to\n\u0026quot;struct device *\u0026quot;.\n\nPass the correct parameter to devm_add_action_or_reset() so that the\nresources are released as expected.(CVE-2024-56754)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: add a sanity check for btrfs root in btrfs_search_slot()\n\nSyzbot reports a null-ptr-deref in btrfs_search_slot().\n\nThe reproducer is using rescue=ibadroots, and the extent tree root is\ncorrupted thus the extent tree is NULL.\n\nWhen scrub tries to search the extent tree to gather the needed extent\ninfo, btrfs_search_slot() doesn\u0026apos;t check if the target root is NULL or\nnot, resulting the null-ptr-deref.\n\nAdd sanity check for btrfs root before using it in btrfs_search_slot().(CVE-2024-56774)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nft_socket: remove WARN_ON_ONCE on maximum cgroup level\n\ncgroup maximum depth is INT_MAX by default, there is a cgroup toggle to\nrestrict this maximum depth to a more reasonable value not to harm\nperformance. Remove unnecessary WARN_ON_ONCE which is reachable from\nuserspace.(CVE-2024-56783)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nMIPS: Loongson64: DTS: Really fix PCIe port nodes for ls7a\n\nFix the dtc warnings:\n\n arch/mips/boot/dts/loongson/ls7a-pch.dtsi:68.16-416.5: Warning (interrupt_provider): /bus@10000000/pci@1a000000: \u0026apos;#interrupt-cells\u0026apos; found, but node is not an interrupt provider\n arch/mips/boot/dts/loongson/ls7a-pch.dtsi:68.16-416.5: Warning (interrupt_provider): /bus@10000000/pci@1a000000: \u0026apos;#interrupt-cells\u0026apos; found, but node is not an interrupt provider\n arch/mips/boot/dts/loongson/loongson64g_4core_ls7a.dtb: Warning (interrupt_map): Failed prerequisite \u0026apos;interrupt_provider\u0026apos;\n\nAnd a runtime warning introduced in commit 045b14ca5c36 (\u0026quot;of: WARN on\ndeprecated #address-cells/#size-cells handling\u0026quot;):\n\n WARNING: CPU: 0 PID: 1 at drivers/of/base.c:106 of_bus_n_addr_cells+0x9c/0xe0\n Missing \u0026apos;#address-cells\u0026apos; in /bus@10000000/pci@1a000000/pci_bridge@9,0\n\nThe fix is similar to commit d89a415ff8d5 (\u0026quot;MIPS: Loongson64: DTS: Fix PCIe\nport nodes for ls7a\u0026quot;), which has fixed the issue for ls2k (despite its\nsubject mentions ls7a).(CVE-2024-56785)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ns390/entry: Mark IRQ entries to fix stack depot warnings\n\nThe stack depot filters out everything outside of the top interrupt\ncontext as an uninteresting or irrelevant part of the stack traces. This\nhelps with stack trace de-duplication, avoiding an explosion of saved\nstack traces that share the same IRQ context code path but originate\nfrom different randomly interrupted points, eventually exhausting the\nstack depot.\n\nFiltering uses in_irqentry_text() to identify functions within the\n.irqentry.text and .softirqentry.text sections, which then become the\nlast stack trace entries being saved.\n\nWhile __do_softirq() is placed into the .softirqentry.text section by\ncommon code, populating .irqentry.text is architecture-specific.\n\nCurrently, the .irqentry.text section on s390 is empty, which prevents\nstack depot filtering and de-duplication and could result in warnings\nlike:\n\nStack depot reached limit capacity\nWARNING: CPU: 0 PID: 286113 at lib/stackdepot.c:252 depot_alloc_stack+0x39a/0x3c8\n\nwith PREEMPT and KASAN enabled.\n\nFix this by moving the IO/EXT interrupt handlers from .kprobes.text into\nthe .irqentry.text section and updating the kprobes blacklist to include\nthe .irqentry.text section.\n\nThis is done only for asynchronous interrupts and explicitly not for\nprogram checks, which are synchronous and where the context beyond the\nprogram check is important to preserve. Despite machine checks being\nsomewhat in between, they are extremely rare, and preserving context\nwhen possible is also of value.\n\nSVCs and Restart Interrupts are not relevant, one being always at the\nboundary to user space and the other being a one-time thing.\n\nIRQ entries filtering is also optionally used in ftrace function graph,\nwhere the same logic applies.(CVE-2024-57838)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/dp_mst: Fix resetting msg rx state after topology removal\n\nIf the MST topology is removed during the reception of an MST down reply\nor MST up request sideband message, the\ndrm_dp_mst_topology_mgr::up_req_recv/down_rep_recv states could be reset\nfrom one thread via drm_dp_mst_topology_mgr_set_mst(false), racing with\nthe reading/parsing of the message from another thread via\ndrm_dp_mst_handle_down_rep() or drm_dp_mst_handle_up_req(). The race is\npossible since the reader/parser doesn\u0026apos;t hold any lock while accessing\nthe reception state. This in turn can lead to a memory corruption in the\nreader/parser as described by commit bd2fccac61b4 (\u0026quot;drm/dp_mst: Fix MST\nsideband message body length check\u0026quot;).\n\nFix the above by resetting the message reception state if needed before\nreading/parsing a message. Another solution would be to hold the\ndrm_dp_mst_topology_mgr::lock for the whole duration of the message\nreception/parsing in drm_dp_mst_handle_down_rep() and\ndrm_dp_mst_handle_up_req(), however this would require a bigger change.\nSince the fix is also needed for stable, opting for the simpler solution\nin this patch.(CVE-2024-57876)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mac80211: fix mbss changed flags corruption on 32 bit systems\n\nOn 32-bit systems, the size of an unsigned long is 4 bytes,\nwhile a u64 is 8 bytes. Therefore, when using\nor_each_set_bit(bit, \u0026amp;bits, sizeof(changed) * BITS_PER_BYTE),\nthe code is incorrectly searching for a bit in a 32-bit\nvariable that is expected to be 64 bits in size,\nleading to incorrect bit finding.\n\nSolution: Ensure that the size of the bits variable is correctly\nadjusted for each architecture.\n\n Call Trace:\n ? show_regs+0x54/0x58\n ? __warn+0x6b/0xd4\n ? ieee80211_link_info_change_notify+0xcc/0xd4 [mac80211]\n ? report_bug+0x113/0x150\n ? exc_overflow+0x30/0x30\n ? handle_bug+0x27/0x44\n ? exc_invalid_op+0x18/0x50\n ? handle_exception+0xf6/0xf6\n ? exc_overflow+0x30/0x30\n ? ieee80211_link_info_change_notify+0xcc/0xd4 [mac80211]\n ? exc_overflow+0x30/0x30\n ? ieee80211_link_info_change_notify+0xcc/0xd4 [mac80211]\n ? ieee80211_mesh_work+0xff/0x260 [mac80211]\n ? cfg80211_wiphy_work+0x72/0x98 [cfg80211]\n ? process_one_work+0xf1/0x1fc\n ? worker_thread+0x2c0/0x3b4\n ? kthread+0xc7/0xf0\n ? mod_delayed_work_on+0x4c/0x4c\n ? kthread_complete_and_exit+0x14/0x14\n ? ret_from_fork+0x24/0x38\n ? kthread_complete_and_exit+0x14/0x14\n ? ret_from_fork_asm+0xf/0x14\n ? entry_INT80_32+0xf0/0xf0\n\n[restore no-op path for no changes](CVE-2024-57899)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: xhci: Fix NULL pointer dereference on certain command aborts\n\nIf a command is queued to the final usable TRB of a ring segment, the\nenqueue pointer is advanced to the subsequent link TRB and no further.\nIf the command is later aborted, when the abort completion is handled\nthe dequeue pointer is advanced to the first TRB of the next segment.\n\nIf no further commands are queued, xhci_handle_stopped_cmd_ring() sees\nthe ring pointers unequal and assumes that there is a pending command,\nso it calls xhci_mod_cmd_timer() which crashes if cur_cmd was NULL.\n\nDon\u0026apos;t attempt timer setup if cur_cmd is NULL. The subsequent doorbell\nring likely is unnecessary too, but it\u0026apos;s harmless. Leave it alone.\n\nThis is probably Bug 219532, but no confirmation has been received.\n\nThe issue has been independently reproduced and confirmed fixed using\na USB MCU programmed to NAK the Status stage of SET_ADDRESS forever.\nEverything continued working normally after several prevented crashes.(CVE-2024-57981)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nocfs2: handle a symlink read error correctly\n\nPatch series \u0026quot;Convert ocfs2 to use folios\u0026quot;.\n\nMark did a conversion of ocfs2 to use folios and sent it to me as a\ngiant patch for review ;-)\n\nSo I\u0026apos;ve redone it as individual patches, and credited Mark for the patches\nwhere his code is substantially the same. It\u0026apos;s not a bad way to do it;\nhis patch had some bugs and my patches had some bugs. Hopefully all our\nbugs were different from each other. And hopefully Mark likes all the\nchanges I made to his code!\n\n\nThis patch (of 23):\n\nIf we can\u0026apos;t read the buffer, be sure to unlock the page before returning.(CVE-2024-58001)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: bpf_local_storage: Always use bpf_mem_alloc in PREEMPT_RT\n\nIn PREEMPT_RT, kmalloc(GFP_ATOMIC) is still not safe in non preemptible\ncontext. bpf_mem_alloc must be used in PREEMPT_RT. This patch is\nto enforce bpf_mem_alloc in the bpf_local_storage when CONFIG_PREEMPT_RT\nis enabled.\n\n[ 35.118559] BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48\n[ 35.118566] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1832, name: test_progs\n[ 35.118569] preempt_count: 1, expected: 0\n[ 35.118571] RCU nest depth: 1, expected: 1\n[ 35.118577] INFO: lockdep is turned off.\n ...\n[ 35.118647] __might_resched+0x433/0x5b0\n[ 35.118677] rt_spin_lock+0xc3/0x290\n[ 35.118700] ___slab_alloc+0x72/0xc40\n[ 35.118723] __kmalloc_noprof+0x13f/0x4e0\n[ 35.118732] bpf_map_kzalloc+0xe5/0x220\n[ 35.118740] bpf_selem_alloc+0x1d2/0x7b0\n[ 35.118755] bpf_local_storage_update+0x2fa/0x8b0\n[ 35.118784] bpf_sk_storage_get_tracing+0x15a/0x1d0\n[ 35.118791] bpf_prog_9a118d86fca78ebb_trace_inet_sock_set_state+0x44/0x66\n[ 35.118795] bpf_trace_run3+0x222/0x400\n[ 35.118820] __bpf_trace_inet_sock_set_state+0x11/0x20\n[ 35.118824] trace_inet_sock_set_state+0x112/0x130\n[ 35.118830] inet_sk_state_store+0x41/0x90\n[ 35.118836] tcp_set_state+0x3b3/0x640\n\nThere is no need to adjust the gfp_flags passing to the\nbpf_mem_cache_alloc_flags() which only honors the GFP_KERNEL.\nThe verifier has ensured GFP_KERNEL is passed only in sleepable context.\n\nIt has been an old issue since the first introduction of the\nbpf_local_storage ~5 years ago, so this patch targets the bpf-next.\n\nbpf_mem_alloc is needed to solve it, so the Fixes tag is set\nto the commit when bpf_mem_alloc was first used in the bpf_local_storage.(CVE-2024-58070)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: rtw89: fix race between cancel_hw_scan and hw_scan completion\n\nThe rtwdev-\u0026gt;scanning flag isn\u0026apos;t protected by mutex originally, so\ncancel_hw_scan can pass the condition, but suddenly hw_scan completion\nunset the flag and calls ieee80211_scan_completed() that will free\nlocal-\u0026gt;hw_scan_req. Then, cancel_hw_scan raises null-ptr-deref and\nuse-after-free. Fix it by moving the check condition to where\nprotected by mutex.\n\n KASAN: null-ptr-deref in range [0x0000000000000088-0x000000000000008f]\n CPU: 2 PID: 6922 Comm: kworker/2:2 Tainted: G OE\n Hardware name: LENOVO 2356AD1/2356AD1, BIOS G7ETB6WW (2.76 ) 09/10/2019\n Workqueue: events cfg80211_conn_work [cfg80211]\n RIP: 0010:rtw89_fw_h2c_scan_offload_be+0xc33/0x13c3 [rtw89_core]\n Code: 00 45 89 6c 24 1c 0f 85 23 01 00 00 48 8b 85 20 ff ff ff 48 8d\n RSP: 0018:ffff88811fd9f068 EFLAGS: 00010206\n RAX: dffffc0000000000 RBX: ffff88811fd9f258 RCX: 0000000000000001\n RDX: 0000000000000011 RSI: 0000000000000001 RDI: 0000000000000089\n RBP: ffff88811fd9f170 R08: 0000000000000000 R09: 0000000000000000\n R10: ffff88811fd9f108 R11: 0000000000000000 R12: ffff88810e47f960\n R13: 0000000000000000 R14: 000000000000ffff R15: 0000000000000000\n FS: 0000000000000000(0000) GS:ffff8881d6f00000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00007531dfca55b0 CR3: 00000001be296004 CR4: 00000000001706e0\n Call Trace:\n \u0026lt;TASK\u0026gt;\n ? show_regs+0x61/0x73\n ? __die_body+0x20/0x73\n ? die_addr+0x4f/0x7b\n ? exc_general_protection+0x191/0x1db\n ? asm_exc_general_protection+0x27/0x30\n ? rtw89_fw_h2c_scan_offload_be+0xc33/0x13c3 [rtw89_core]\n ? rtw89_fw_h2c_scan_offload_be+0x458/0x13c3 [rtw89_core]\n ? __pfx_rtw89_fw_h2c_scan_offload_be+0x10/0x10 [rtw89_core]\n ? do_raw_spin_lock+0x75/0xdb\n ? __pfx_do_raw_spin_lock+0x10/0x10\n rtw89_hw_scan_offload+0xb5e/0xbf7 [rtw89_core]\n ? _raw_spin_unlock+0xe/0x24\n ? __mutex_lock.constprop.0+0x40c/0x471\n ? __pfx_rtw89_hw_scan_offload+0x10/0x10 [rtw89_core]\n ? __mutex_lock_slowpath+0x13/0x1f\n ? mutex_lock+0xa2/0xdc\n ? __pfx_mutex_lock+0x10/0x10\n rtw89_hw_scan_abort+0x58/0xb7 [rtw89_core]\n rtw89_ops_cancel_hw_scan+0x120/0x13b [rtw89_core]\n ieee80211_scan_cancel+0x468/0x4d0 [mac80211]\n ieee80211_prep_connection+0x858/0x899 [mac80211]\n ieee80211_mgd_auth+0xbea/0xdde [mac80211]\n ? __pfx_ieee80211_mgd_auth+0x10/0x10 [mac80211]\n ? cfg80211_find_elem+0x15/0x29 [cfg80211]\n ? is_bss+0x1b7/0x1d7 [cfg80211]\n ieee80211_auth+0x18/0x27 [mac80211]\n cfg80211_mlme_auth+0x3bb/0x3e7 [cfg80211]\n cfg80211_conn_do_work+0x410/0xb81 [cfg80211]\n ? __pfx_cfg80211_conn_do_work+0x10/0x10 [cfg80211]\n ? __kasan_check_read+0x11/0x1f\n ? psi_group_change+0x8bc/0x944\n ? __kasan_check_write+0x14/0x22\n ? mutex_lock+0x8e/0xdc\n ? __pfx_mutex_lock+0x10/0x10\n ? __pfx___radix_tree_lookup+0x10/0x10\n cfg80211_conn_work+0x245/0x34d [cfg80211]\n ? __pfx_cfg80211_conn_work+0x10/0x10 [cfg80211]\n ? update_cfs_rq_load_avg+0x3bc/0x3d7\n ? sched_clock_noinstr+0x9/0x1a\n ? sched_clock+0x10/0x24\n ? sched_clock_cpu+0x7e/0x42e\n ? newidle_balance+0x796/0x937\n ? __pfx_sched_clock_cpu+0x10/0x10\n ? __pfx_newidle_balance+0x10/0x10\n ? __kasan_check_read+0x11/0x1f\n ? psi_group_change+0x8bc/0x944\n ? _raw_spin_unlock+0xe/0x24\n ? raw_spin_rq_unlock+0x47/0x54\n ? raw_spin_rq_unlock_irq+0x9/0x1f\n ? finish_task_switch.isra.0+0x347/0x586\n ? __schedule+0x27bf/0x2892\n ? mutex_unlock+0x80/0xd0\n ? do_raw_spin_lock+0x75/0xdb\n ? __pfx___schedule+0x10/0x10\n process_scheduled_works+0x58c/0x821\n worker_thread+0x4c7/0x586\n ? __kasan_check_read+0x11/0x1f\n kthread+0x285/0x294\n ? __pfx_worker_thread+0x10/0x10\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x29/0x6f\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1b/0x30\n \u0026lt;/TASK\u0026gt;(CVE-2025-21729)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/mlx5: Fix a race for an ODP MR which leads to CQE with error\n\nThis patch addresses a race condition for an ODP MR that can result in a\nCQE with an error on the UMR QP.\n\nDuring the __mlx5_ib_dereg_mr() flow, the following sequence of calls\noccurs:\n\nmlx5_revoke_mr()\n mlx5r_umr_revoke_mr()\n mlx5r_umr_post_send_wait()\n\nAt this point, the lkey is freed from the hardware\u0026apos;s perspective.\n\nHowever, concurrently, mlx5_ib_invalidate_range() might be triggered by\nanother task attempting to invalidate a range for the same freed lkey.\n\nThis task will:\n - Acquire the umem_odp-\u0026gt;umem_mutex lock.\n - Call mlx5r_umr_update_xlt() on the UMR QP.\n - Since the lkey has already been freed, this can lead to a CQE error,\n causing the UMR QP to enter an error state [1].\n\nTo resolve this race condition, the umem_odp-\u0026gt;umem_mutex lock is now also\nacquired as part of the mlx5_revoke_mr() scope. Upon successful revoke,\nwe set umem_odp-\u0026gt;private which points to that MR to NULL, preventing any\nfurther invalidation attempts on its lkey.\n\n[1] From dmesg:\n\n infiniband rocep8s0f0: dump_cqe:277:(pid 0): WC error: 6, Message: memory bind operation error\n cqe_dump: 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n cqe_dump: 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n cqe_dump: 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n cqe_dump: 00000030: 00 00 00 00 08 00 78 06 25 00 11 b9 00 0e dd d2\n\n WARNING: CPU: 15 PID: 1506 at drivers/infiniband/hw/mlx5/umr.c:394 mlx5r_umr_post_send_wait+0x15a/0x2b0 [mlx5_ib]\n Modules linked in: ip6table_mangle ip6table_natip6table_filter ip6_tables iptable_mangle xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry overlay rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_umad ib_ipoib ib_cm mlx5_ib ib_uverbs ib_core fuse mlx5_core\n CPU: 15 UID: 0 PID: 1506 Comm: ibv_rc_pingpong Not tainted 6.12.0-rc7+ #1626\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\n RIP: 0010:mlx5r_umr_post_send_wait+0x15a/0x2b0 [mlx5_ib]\n [..]\n Call Trace:\n \u0026lt;TASK\u0026gt;\n mlx5r_umr_update_xlt+0x23c/0x3e0 [mlx5_ib]\n mlx5_ib_invalidate_range+0x2e1/0x330 [mlx5_ib]\n __mmu_notifier_invalidate_range_start+0x1e1/0x240\n zap_page_range_single+0xf1/0x1a0\n madvise_vma_behavior+0x677/0x6e0\n do_madvise+0x1a2/0x4b0\n __x64_sys_madvise+0x25/0x30\n do_syscall_64+0x6b/0x140\n entry_SYSCALL_64_after_hwframe+0x76/0x7e(CVE-2025-21732)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnilfs2: fix possible int overflows in nilfs_fiemap()\n\nSince nilfs_bmap_lookup_contig() in nilfs_fiemap() calculates its result\nby being prepared to go through potentially maxblocks == INT_MAX blocks,\nthe value in n may experience an overflow caused by left shift of blkbits.\n\nWhile it is extremely unlikely to occur, play it safe and cast right hand\nexpression to wider type to mitigate the issue.\n\nFound by Linux Verification Center (linuxtesting.org) with static analysis\ntool SVACE.(CVE-2025-21736)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusbnet: ipheth: fix possible overflow in DPE length check\n\nOriginally, it was possible for the DPE length check to overflow if\nwDatagramIndex + wDatagramLength \u0026gt; U16_MAX. This could lead to an OoB\nread.\n\nMove the wDatagramIndex term to the other side of the inequality.\n\nAn existing condition ensures that wDatagramIndex \u0026lt; urb-\u0026gt;actual_length.(CVE-2025-21743)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nclocksource: Use migrate_disable() to avoid calling get_random_u32() in atomic context\n\nThe following bug report happened with a PREEMPT_RT kernel:\n\n BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48\n in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 2012, name: kwatchdog\n preempt_count: 1, expected: 0\n RCU nest depth: 0, expected: 0\n get_random_u32+0x4f/0x110\n clocksource_verify_choose_cpus+0xab/0x1a0\n clocksource_verify_percpu.part.0+0x6b/0x330\n clocksource_watchdog_kthread+0x193/0x1a0\n\nIt is due to the fact that clocksource_verify_choose_cpus() is invoked with\npreemption disabled. This function invokes get_random_u32() to obtain\nrandom numbers for choosing CPUs. The batched_entropy_32 local lock and/or\nthe base_crng.lock spinlock in driver/char/random.c will be acquired during\nthe call. In PREEMPT_RT kernel, they are both sleeping locks and so cannot\nbe acquired in atomic context.\n\nFix this problem by using migrate_disable() to allow smp_processor_id() to\nbe reliably used without introducing atomic context. preempt_disable() is\nthen called after clocksource_verify_choose_cpus() but before the\nclocksource measurement is being run to avoid introducing unexpected\nlatency.(CVE-2025-21767)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nUSB: hub: Ignore non-compliant devices with too many configs or interfaces\n\nRobert Morris created a test program which can cause\nusb_hub_to_struct_hub() to dereference a NULL or inappropriate\npointer:\n\nOops: general protection fault, probably for non-canonical address\n0xcccccccccccccccc: 0000 [#1] SMP DEBUG_PAGEALLOC PTI\nCPU: 7 UID: 0 PID: 117 Comm: kworker/7:1 Not tainted 6.13.0-rc3-00017-gf44d154d6e3d #14\nHardware name: FreeBSD BHYVE/BHYVE, BIOS 14.0 10/17/2021\nWorkqueue: usb_hub_wq hub_event\nRIP: 0010:usb_hub_adjust_deviceremovable+0x78/0x110\n...\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? die_addr+0x31/0x80\n ? exc_general_protection+0x1b4/0x3c0\n ? asm_exc_general_protection+0x26/0x30\n ? usb_hub_adjust_deviceremovable+0x78/0x110\n hub_probe+0x7c7/0xab0\n usb_probe_interface+0x14b/0x350\n really_probe+0xd0/0x2d0\n ? __pfx___device_attach_driver+0x10/0x10\n __driver_probe_device+0x6e/0x110\n driver_probe_device+0x1a/0x90\n __device_attach_driver+0x7e/0xc0\n bus_for_each_drv+0x7f/0xd0\n __device_attach+0xaa/0x1a0\n bus_probe_device+0x8b/0xa0\n device_add+0x62e/0x810\n usb_set_configuration+0x65d/0x990\n usb_generic_driver_probe+0x4b/0x70\n usb_probe_device+0x36/0xd0\n\nThe cause of this error is that the device has two interfaces, and the\nhub driver binds to interface 1 instead of interface 0, which is where\nusb_hub_to_struct_hub() looks.\n\nWe can prevent the problem from occurring by refusing to accept hub\ndevices that violate the USB spec by having more than one\nconfiguration or interface.(CVE-2025-21776)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\norangefs: fix a oob in orangefs_debug_write\n\nI got a syzbot report: slab-out-of-bounds Read in\norangefs_debug_write... several people suggested fixes,\nI tested Al Viro\u0026apos;s suggestion and made this patch.(CVE-2025-21782)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ngpiolib: Fix crash on error in gpiochip_get_ngpios()\n\nThe gpiochip_get_ngpios() uses chip_*() macros to print messages.\nHowever these macros rely on gpiodev to be initialised and set,\nwhich is not the case when called via bgpio_init(). In such a case\nthe printing messages will crash on NULL pointer dereference.\nReplace chip_*() macros by the respective dev_*() ones to avoid\nsuch crash.(CVE-2025-21783)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nLoongArch: csum: Fix OoB access in IP checksum code for negative lengths\n\nCommit 69e3a6aa6be2 (\u0026quot;LoongArch: Add checksum optimization for 64-bit\nsystem\u0026quot;) would cause an undefined shift and an out-of-bounds read.\n\nCommit 8bd795fedb84 (\u0026quot;arm64: csum: Fix OoB access in IP checksum code\nfor negative lengths\u0026quot;) fixes the same issue on ARM64.(CVE-2025-21789)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFSD: fix hang in nfsd4_shutdown_callback\n\nIf nfs4_client is in courtesy state then there is no point to send\nthe callback. This causes nfsd4_shutdown_callback to hang since\ncl_cb_inflight is not 0. This hang lasts about 15 minutes until TCP\nnotifies NFSD that the connection was dropped.\n\nThis patch modifies nfsd4_run_cb_work to skip the RPC call if\nnfs4_client is in courtesy state.(CVE-2025-21795)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: clear acl_access/acl_default after releasing them\n\nIf getting acl_default fails, acl_access and acl_default will be released\nsimultaneously. However, acl_access will still retain a pointer pointing\nto the released posix_acl, which will trigger a WARNING in\nnfs3svc_release_getacl like this:\n\n------------[ cut here ]------------\nrefcount_t: underflow; use-after-free.\nWARNING: CPU: 26 PID: 3199 at lib/refcount.c:28\nrefcount_warn_saturate+0xb5/0x170\nModules linked in:\nCPU: 26 UID: 0 PID: 3199 Comm: nfsd Not tainted\n6.12.0-rc6-00079-g04ae226af01f-dirty #8\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS\n1.16.1-2.fc37 04/01/2014\nRIP: 0010:refcount_warn_saturate+0xb5/0x170\nCode: cc cc 0f b6 1d b3 20 a5 03 80 fb 01 0f 87 65 48 d8 00 83 e3 01 75\ne4 48 c7 c7 c0 3b 9b 85 c6 05 97 20 a5 03 01 e8 fb 3e 30 ff \u0026lt;0f\u0026gt; 0b eb\ncd 0f b6 1d 8a3\nRSP: 0018:ffffc90008637cd8 EFLAGS: 00010282\nRAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff83904fde\nRDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff88871ed36380\nRBP: ffff888158beeb40 R08: 0000000000000001 R09: fffff520010c6f56\nR10: ffffc90008637ab7 R11: 0000000000000001 R12: 0000000000000001\nR13: ffff888140e77400 R14: ffff888140e77408 R15: ffffffff858b42c0\nFS: 0000000000000000(0000) GS:ffff88871ed00000(0000)\nknlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000562384d32158 CR3: 000000055cc6a000 CR4: 00000000000006f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? refcount_warn_saturate+0xb5/0x170\n ? __warn+0xa5/0x140\n ? refcount_warn_saturate+0xb5/0x170\n ? report_bug+0x1b1/0x1e0\n ? handle_bug+0x53/0xa0\n ? exc_invalid_op+0x17/0x40\n ? asm_exc_invalid_op+0x1a/0x20\n ? tick_nohz_tick_stopped+0x1e/0x40\n ? refcount_warn_saturate+0xb5/0x170\n ? refcount_warn_saturate+0xb5/0x170\n nfs3svc_release_getacl+0xc9/0xe0\n svc_process_common+0x5db/0xb60\n ? __pfx_svc_process_common+0x10/0x10\n ? __rcu_read_unlock+0x69/0xa0\n ? __pfx_nfsd_dispatch+0x10/0x10\n ? svc_xprt_received+0xa1/0x120\n ? xdr_init_decode+0x11d/0x190\n svc_process+0x2a7/0x330\n svc_handle_xprt+0x69d/0x940\n svc_recv+0x180/0x2d0\n nfsd+0x168/0x200\n ? __pfx_nfsd+0x10/0x10\n kthread+0x1a2/0x1e0\n ? kthread+0xf4/0x1e0\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x34/0x60\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1a/0x30\n \u0026lt;/TASK\u0026gt;\nKernel panic - not syncing: kernel: panic_on_warn set ...\n\nClear acl_access/acl_default after posix_acl_release is called to prevent\nUAF from being triggered.(CVE-2025-21796)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nptp: Ensure info-\u0026gt;enable callback is always set\n\nThe ioctl and sysfs handlers unconditionally call the -\u0026gt;enable callback.\nNot all drivers implement that callback, leading to NULL dereferences.\nExample of affected drivers: ptp_s390.c, ptp_vclock.c and ptp_mock.c.\n\nInstead use a dummy callback if no better was specified by the driver.(CVE-2025-21814)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nblock: mark GFP_NOIO around sysfs -\u0026gt;store()\n\nsysfs -\u0026gt;store is called with queue freezed, meantime we have several\n-\u0026gt;store() callbacks(update_nr_requests, wbt, scheduler) to allocate\nmemory with GFP_KERNEL which may run into direct reclaim code path,\nthen potential deadlock can be caused.\n\nFix the issue by marking NOIO around sysfs -\u0026gt;store()(CVE-2025-21817)",
"id": "OESA-2025-1286",
"modified": "2026-08-06T11:08:23Z",
"published": "2025-03-14T11:08:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1286"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52926"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41935"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47143"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47809"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-48881"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53141"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53148"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53156"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53176"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53177"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53178"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53181"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53185"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53210"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53214"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53216"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53233"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-54456"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56531"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56533"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56539"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56545"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56551"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56558"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56566"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56573"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56574"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56576"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56577"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56579"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56587"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56593"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56600"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56601"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56602"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56603"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56606"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56625"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56628"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56636"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56637"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56643"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56644"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56645"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56650"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56651"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56678"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56689"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56704"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56707"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56723"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56724"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56725"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56727"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56746"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56751"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56754"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56774"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56783"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56785"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57838"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57876"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57899"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57981"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58001"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58070"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21729"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21732"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21736"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21743"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21767"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21776"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21782"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21783"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21789"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21795"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21796"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21814"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21817"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2023-52926",
"CVE-2024-41935",
"CVE-2024-47143",
"CVE-2024-47809",
"CVE-2024-48881",
"CVE-2024-53141",
"CVE-2024-53148",
"CVE-2024-53156",
"CVE-2024-53176",
"CVE-2024-53177",
"CVE-2024-53178",
"CVE-2024-53181",
"CVE-2024-53185",
"CVE-2024-53210",
"CVE-2024-53214",
"CVE-2024-53216",
"CVE-2024-53233",
"CVE-2024-54456",
"CVE-2024-56531",
"CVE-2024-56533",
"CVE-2024-56539",
"CVE-2024-56545",
"CVE-2024-56551",
"CVE-2024-56558",
"CVE-2024-56566",
"CVE-2024-56573",
"CVE-2024-56574",
"CVE-2024-56576",
"CVE-2024-56577",
"CVE-2024-56579",
"CVE-2024-56587",
"CVE-2024-56593",
"CVE-2024-56600",
"CVE-2024-56601",
"CVE-2024-56602",
"CVE-2024-56603",
"CVE-2024-56606",
"CVE-2024-56625",
"CVE-2024-56628",
"CVE-2024-56636",
"CVE-2024-56637",
"CVE-2024-56643",
"CVE-2024-56644",
"CVE-2024-56645",
"CVE-2024-56650",
"CVE-2024-56651",
"CVE-2024-56678",
"CVE-2024-56689",
"CVE-2024-56704",
"CVE-2024-56707",
"CVE-2024-56723",
"CVE-2024-56724",
"CVE-2024-56725",
"CVE-2024-56727",
"CVE-2024-56746",
"CVE-2024-56751",
"CVE-2024-56754",
"CVE-2024-56774",
"CVE-2024-56783",
"CVE-2024-56785",
"CVE-2024-57838",
"CVE-2024-57876",
"CVE-2024-57899",
"CVE-2024-57981",
"CVE-2024-58001",
"CVE-2024-58070",
"CVE-2025-21729",
"CVE-2025-21732",
"CVE-2025-21736",
"CVE-2025-21743",
"CVE-2025-21767",
"CVE-2025-21776",
"CVE-2025-21782",
"CVE-2025-21783",
"CVE-2025-21789",
"CVE-2025-21795",
"CVE-2025-21796",
"CVE-2025-21814",
"CVE-2025-21817"
]
}
OESA-2025-1339 (CVE-2024-47143)
Vulnerability from osv_openeuler – Published: 2025-03-29 11:08 – Updated: 2026-08-06 11:08 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
dma-debug: fix a possible deadlock on radix_lock
radix_lock() shouldn't be held while holding dma_hash_entry[idx].lock otherwise, there's a possible deadlock scenario when dma debug API is called holding rq_lock():
CPU0 CPU1 CPU2 dma_free_attrs() check_unmap() add_dma_entry() __schedule() //out (A) rq_lock() get_hash_bucket() (A) dma_entry_hash check_sync() (A) radix_lock() (W) dma_entry_hash dma_entry_free() (W) radix_lock() // CPU2's one (W) rq_lock()
CPU1 situation can happen when it extending radix tree and it tries to wake up kswapd via wake_all_kswapd().
CPU2 situation can happen while perf_event_task_sched_out() (i.e. dma sync operation is called while deleting perf_event using etm and etr tmc which are Arm Coresight hwtracing driver backends).
To remove this possible situation, call dma_entry_free() after put_hash_bucket() in check_unmap().(CVE-2024-47143)
In the Linux kernel, the following vulnerability has been resolved:
dlm: fix possible lkb_resource null dereference
This patch fixes a possible null pointer dereference when this function is called from request_lock() as lkb->lkb_resource is not assigned yet, only after validate_lock_args() by calling attach_lkb(). Another issue is that a resource name could be a non printable bytearray and we cannot assume to be ASCII coded.
The log functionality is probably never being hit when DLM is used in normal way and no debug logging is enabled. The null pointer dereference can only occur on a new created lkb that does not have the resource assigned yet, it probably never hits the null pointer dereference but we should be sure that other changes might not change this behaviour and we actually can hit the mentioned null pointer dereference.
In this patch we just drop the printout of the resource name, the lkb id is enough to make a possible connection to a resource name if this exists.(CVE-2024-47809)
In the Linux kernel, the following vulnerability has been resolved:
bcache: revert replacing IS_ERR_OR_NULL with IS_ERR again
Commit 028ddcac477b ("bcache: Remove unnecessary NULL point check in node allocations") leads a NULL pointer deference in cache_set_flush().
1721 if (!IS_ERR_OR_NULL(c->root)) 1722 list_add(&c->root->list, &c->btree_cache);
>From the above code in cache_set_flush(), if previous registration code fails before allocating c->root, it is possible c->root is NULL as what it is initialized. __bch_btree_node_alloc() never returns NULL but c->root is possible to be NULL at above line 1721.
This patch replaces IS_ERR() by IS_ERR_OR_NULL() to fix this.(CVE-2024-48881)
In the Linux kernel, the following vulnerability has been resolved:
vfio/pci: Properly hide first-in-list PCIe extended capability
There are cases where a PCIe extended capability should be hidden from the user. For example, an unknown capability (i.e., capability with ID greater than PCI_EXT_CAP_ID_MAX) or a capability that is intentionally chosen to be hidden from the user.
Hiding a capability is done by virtualizing and modifying the 'Next Capability Offset' field of the previous capability so it points to the capability after the one that should be hidden.
The special case where the first capability in the list should be hidden is handled differently because there is no previous capability that can be modified. In this case, the capability ID and version are zeroed while leaving the next pointer intact. This hides the capability and leaves an anchor for the rest of the capability list.
However, today, hiding the first capability in the list is not done properly if the capability is unknown, as struct vfio_pci_core_device->pci_config_map is set to the capability ID during initialization but the capability ID is not properly checked later when used in vfio_config_do_rw(). This leads to the following warning [1] and to an out-of-bounds access to ecap_perms array.
Fix it by checking cap_id in vfio_config_do_rw(), and if it is greater than PCI_EXT_CAP_ID_MAX, use an alternative struct perm_bits for direct read only access instead of the ecap_perms array.
Note that this is safe since the above is the only case where cap_id can exceed PCI_EXT_CAP_ID_MAX (except for the special capabilities, which are already checked before).
[1]
WARNING: CPU: 118 PID: 5329 at drivers/vfio/pci/vfio_pci_config.c:1900 vfio_pci_config_rw+0x395/0x430 [vfio_pci_core] CPU: 118 UID: 0 PID: 5329 Comm: simx-qemu-syste Not tainted 6.12.0+ #1 (snip) Call Trace: <TASK> ? show_regs+0x69/0x80 ? __warn+0x8d/0x140 ? vfio_pci_config_rw+0x395/0x430 [vfio_pci_core] ? report_bug+0x18f/0x1a0 ? handle_bug+0x63/0xa0 ? exc_invalid_op+0x19/0x70 ? asm_exc_invalid_op+0x1b/0x20 ? vfio_pci_config_rw+0x395/0x430 [vfio_pci_core] ? vfio_pci_config_rw+0x244/0x430 [vfio_pci_core] vfio_pci_rw+0x101/0x1b0 [vfio_pci_core] vfio_pci_core_read+0x1d/0x30 [vfio_pci_core] vfio_device_fops_read+0x27/0x40 [vfio] vfs_read+0xbd/0x340 ? vfio_device_fops_unl_ioctl+0xbb/0x740 [vfio] ? __rseq_handle_notify_resume+0xa4/0x4b0 __x64_sys_pread64+0x96/0xc0 x64_sys_call+0x1c3d/0x20d0 do_syscall_64+0x4d/0x120 entry_SYSCALL_64_after_hwframe+0x76/0x7e(CVE-2024-53214)
In the Linux kernel, the following vulnerability has been resolved:
net: af_can: do not leave a dangling sk pointer in can_create()
On error can_create() frees the allocated sk object, but sock_init_data() has already attached it to the provided sock object. This will leave a dangling sk pointer in the sock object and may cause use-after-free later.(CVE-2024-56603)
In the Linux kernel, the following vulnerability has been resolved:
af_packet: avoid erroring out after sock_init_data() in packet_create()
After sock_init_data() the allocated sk object is attached to the provided sock object. On error, packet_create() frees the sk object leaving the dangling pointer in the sock object on return. Some other code may try to use this pointer and cause use-after-free.(CVE-2024-56606)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: ipset: Hold module reference while requesting a module
User space may unload ip_set.ko while it is itself requesting a set type backend module, leading to a kernel crash. The race condition may be provoked by inserting an mdelay() right after the nfnl_unlock() call.(CVE-2024-56637)
In the Linux kernel, the following vulnerability has been resolved:
tipc: Fix use-after-free of kernel socket in cleanup_bearer().
syzkaller reported a use-after-free of UDP kernel socket in cleanup_bearer() without repro. [0][1]
When bearer_disable() calls tipc_udp_disable(), cleanup of the UDP kernel socket is deferred by work calling cleanup_bearer().
tipc_exit_net() waits for such works to finish by checking tipc_net(net)->wq_count. However, the work decrements the count too early before releasing the kernel socket, unblocking cleanup_net() and resulting in use-after-free.
Let's move the decrement after releasing the socket in cleanup_bearer().
[0]: ref_tracker: net notrefcnt@000000009b3d1faf has 1/1 users at sk_alloc+0x438/0x608 inet_create+0x4c8/0xcb0 __sock_create+0x350/0x6b8 sock_create_kern+0x58/0x78 udp_sock_create4+0x68/0x398 udp_sock_create+0x88/0xc8 tipc_udp_enable+0x5e8/0x848 __tipc_nl_bearer_enable+0x84c/0xed8 tipc_nl_bearer_enable+0x38/0x60 genl_family_rcv_msg_doit+0x170/0x248 genl_rcv_msg+0x400/0x5b0 netlink_rcv_skb+0x1dc/0x398 genl_rcv+0x44/0x68 netlink_unicast+0x678/0x8b0 netlink_sendmsg+0x5e4/0x898 ____sys_sendmsg+0x500/0x830
[1]: BUG: KMSAN: use-after-free in udp_hashslot include/net/udp.h:85 [inline] BUG: KMSAN: use-after-free in udp_lib_unhash+0x3b8/0x930 net/ipv4/udp.c:1979 udp_hashslot include/net/udp.h:85 [inline] udp_lib_unhash+0x3b8/0x930 net/ipv4/udp.c:1979 sk_common_release+0xaf/0x3f0 net/core/sock.c:3820 inet_release+0x1e0/0x260 net/ipv4/af_inet.c:437 inet6_release+0x6f/0xd0 net/ipv6/af_inet6.c:489 __sock_release net/socket.c:658 [inline] sock_release+0xa0/0x210 net/socket.c:686 cleanup_bearer+0x42d/0x4c0 net/tipc/udp_media.c:819 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xcaf/0x1c90 kernel/workqueue.c:3310 worker_thread+0xf6c/0x1510 kernel/workqueue.c:3391 kthread+0x531/0x6b0 kernel/kthread.c:389 ret_from_fork+0x60/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:244
Uninit was created at: slab_free_hook mm/slub.c:2269 [inline] slab_free mm/slub.c:4580 [inline] kmem_cache_free+0x207/0xc40 mm/slub.c:4682 net_free net/core/net_namespace.c:454 [inline] cleanup_net+0x16f2/0x19d0 net/core/net_namespace.c:647 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xcaf/0x1c90 kernel/workqueue.c:3310 worker_thread+0xf6c/0x1510 kernel/workqueue.c:3391 kthread+0x531/0x6b0 kernel/kthread.c:389 ret_from_fork+0x60/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:244
CPU: 0 UID: 0 PID: 54 Comm: kworker/0:2 Not tainted 6.12.0-rc1-00131-gf66ebf37d69c #7 91723d6f74857f70725e1583cba3cf4adc716cfa Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 Workqueue: events cleanup_bearer(CVE-2024-56642)
In the Linux kernel, the following vulnerability has been resolved:
net: hsr: avoid potential out-of-bound access in fill_frame_info()
syzbot is able to feed a packet with 14 bytes, pretending it is a vlan one.
Since fill_frame_info() is relying on skb->mac_len already, extend the check to cover this case.
BUG: KMSAN: uninit-value in fill_frame_info net/hsr/hsr_forward.c:709 [inline] BUG: KMSAN: uninit-value in hsr_forward_skb+0x9ee/0x3b10 net/hsr/hsr_forward.c:724 fill_frame_info net/hsr/hsr_forward.c:709 [inline] hsr_forward_skb+0x9ee/0x3b10 net/hsr/hsr_forward.c:724 hsr_dev_xmit+0x2f0/0x350 net/hsr/hsr_device.c:235 __netdev_start_xmit include/linux/netdevice.h:5002 [inline] netdev_start_xmit include/linux/netdevice.h:5011 [inline] xmit_one net/core/dev.c:3590 [inline] dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3606 __dev_queue_xmit+0x366a/0x57d0 net/core/dev.c:4434 dev_queue_xmit include/linux/netdevice.h:3168 [inline] packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3146 [inline] packet_sendmsg+0x91ae/0xa6f0 net/packet/af_packet.c:3178 sock_sendmsg_nosec net/socket.c:711 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:726 __sys_sendto+0x594/0x750 net/socket.c:2197 __do_sys_sendto net/socket.c:2204 [inline] __se_sys_sendto net/socket.c:2200 [inline] __x64_sys_sendto+0x125/0x1d0 net/socket.c:2200 x64_sys_call+0x346a/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:45 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Uninit was created at: slab_post_alloc_hook mm/slub.c:4091 [inline] slab_alloc_node mm/slub.c:4134 [inline] kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4186 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587 __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678 alloc_skb include/linux/skbuff.h:1323 [inline] alloc_skb_with_frags+0xc8/0xd00 net/core/skbuff.c:6612 sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2881 packet_alloc_skb net/packet/af_packet.c:2995 [inline] packet_snd net/packet/af_packet.c:3089 [inline] packet_sendmsg+0x74c6/0xa6f0 net/packet/af_packet.c:3178 sock_sendmsg_nosec net/socket.c:711 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:726 __sys_sendto+0x594/0x750 net/socket.c:2197 __do_sys_sendto net/socket.c:2204 [inline] __se_sys_sendto net/socket.c:2200 [inline] __x64_sys_sendto+0x125/0x1d0 net/socket.c:2200 x64_sys_call+0x346a/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:45 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2024-56648)
In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: u_serial: Fix the issue that gs_start_io crashed due to accessing null pointer
Considering that in some extreme cases, when u_serial driver is accessed by multiple threads, Thread A is executing the open operation and calling the gs_open, Thread B is executing the disconnect operation and calling the gserial_disconnect function,The port->port_usb pointer will be set to NULL.
E.g. Thread A Thread B gs_open() gadget_unbind_driver() gs_start_io() composite_disconnect() gs_start_rx() gserial_disconnect() ... ... spin_unlock(&port->port_lock) status = usb_ep_queue() spin_lock(&port->port_lock) spin_lock(&port->port_lock) port->port_usb = NULL gs_free_requests(port->port_usb->in) spin_unlock(&port->port_lock) Crash
This causes thread A to access a null pointer (port->port_usb is null) when calling the gs_free_requests function, causing a crash.
If port_usb is NULL, the release request will be skipped as it will be done by gserial_disconnect.
So add a null pointer check to gs_start_io before attempting to access the value of the pointer port->port_usb.
Call trace: gs_start_io+0x164/0x25c gs_open+0x108/0x13c tty_open+0x314/0x638 chrdev_open+0x1b8/0x258 do_dentry_open+0x2c4/0x700 vfs_open+0x2c/0x3c path_openat+0xa64/0xc60 do_filp_open+0xb8/0x164 do_sys_openat2+0x84/0xf0 __arm64_sys_openat+0x70/0x9c invoke_syscall+0x58/0x114 el0_svc_common+0x80/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x38/0x68(CVE-2024-56670)
In the Linux kernel, the following vulnerability has been resolved:
9p/xen: fix release of IRQ
Kernel logs indicate an IRQ was double-freed.
Pass correct device ID during IRQ release.
Dominique: remove confusing variable reset to 0
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nft_socket: remove WARN_ON_ONCE on maximum cgroup level
cgroup maximum depth is INT_MAX by default, there is a cgroup toggle to restrict this maximum depth to a more reasonable value not to harm performance. Remove unnecessary WARN_ON_ONCE which is reachable from userspace.(CVE-2024-56783)
In the Linux kernel, the following vulnerability has been resolved:
MIPS: Loongson64: DTS: Really fix PCIe port nodes for ls7a
Fix the dtc warnings:
arch/mips/boot/dts/loongson/ls7a-pch.dtsi:68.16-416.5: Warning (interrupt_provider): /bus@10000000/pci@1a000000: '#interrupt-cells' found, but node is not an interrupt provider
arch/mips/boot/dts/loongson/ls7a-pch.dtsi:68.16-416.5: Warning (interrupt_provider): /bus@10000000/pci@1a000000: '#interrupt-cells' found, but node is not an interrupt provider
arch/mips/boot/dts/loongson/loongson64g_4core_ls7a.dtb: Warning (interrupt_map): Failed prerequisite 'interrupt_provider'
And a runtime warning introduced in commit 045b14ca5c36 ("of: WARN on deprecated #address-cells/#size-cells handling"):
WARNING: CPU: 0 PID: 1 at drivers/of/base.c:106 of_bus_n_addr_cells+0x9c/0xe0
Missing '#address-cells' in /bus@10000000/pci@1a000000/pci_bridge@9,0
The fix is similar to commit d89a415ff8d5 ("MIPS: Loongson64: DTS: Fix PCIe port nodes for ls7a"), which has fixed the issue for ls2k (despite its subject mentions ls7a).(CVE-2024-56785)
In the Linux kernel, the following vulnerability has been resolved:
s390/entry: Mark IRQ entries to fix stack depot warnings
The stack depot filters out everything outside of the top interrupt context as an uninteresting or irrelevant part of the stack traces. This helps with stack trace de-duplication, avoiding an explosion of saved stack traces that share the same IRQ context code path but originate from different randomly interrupted points, eventually exhausting the stack depot.
Filtering uses in_irqentry_text() to identify functions within the .irqentry.text and .softirqentry.text sections, which then become the last stack trace entries being saved.
While __do_softirq() is placed into the .softirqentry.text section by common code, populating .irqentry.text is architecture-specific.
Currently, the .irqentry.text section on s390 is empty, which prevents stack depot filtering and de-duplication and could result in warnings like:
Stack depot reached limit capacity WARNING: CPU: 0 PID: 286113 at lib/stackdepot.c:252 depot_alloc_stack+0x39a/0x3c8
with PREEMPT and KASAN enabled.
Fix this by moving the IO/EXT interrupt handlers from .kprobes.text into the .irqentry.text section and updating the kprobes blacklist to include the .irqentry.text section.
This is done only for asynchronous interrupts and explicitly not for program checks, which are synchronous and where the context beyond the program check is important to preserve. Despite machine checks being somewhat in between, they are extremely rare, and preserving context when possible is also of value.
SVCs and Restart Interrupts are not relevant, one being always at the boundary to user space and the other being a one-time thing.
IRQ entries filtering is also optionally used in ftrace function graph, where the same logic applies.(CVE-2024-57838)
In the Linux kernel, the following vulnerability has been resolved:
drm/dp_mst: Fix resetting msg rx state after topology removal
If the MST topology is removed during the reception of an MST down reply or MST up request sideband message, the drm_dp_mst_topology_mgr::up_req_recv/down_rep_recv states could be reset from one thread via drm_dp_mst_topology_mgr_set_mst(false), racing with the reading/parsing of the message from another thread via drm_dp_mst_handle_down_rep() or drm_dp_mst_handle_up_req(). The race is possible since the reader/parser doesn't hold any lock while accessing the reception state. This in turn can lead to a memory corruption in the reader/parser as described by commit bd2fccac61b4 ("drm/dp_mst: Fix MST sideband message body length check").
Fix the above by resetting the message reception state if needed before reading/parsing a message. Another solution would be to hold the drm_dp_mst_topology_mgr::lock for the whole duration of the message reception/parsing in drm_dp_mst_handle_down_rep() and drm_dp_mst_handle_up_req(), however this would require a bigger change. Since the fix is also needed for stable, opting for the simpler solution in this patch.(CVE-2024-57876)
In the Linux kernel, the following vulnerability has been resolved:
rdma/cxgb4: Prevent potential integer overflow on 32bit
The "gl->tot_len" variable is controlled by the user. It comes from process_responses(). On 32bit systems, the "gl->tot_len + sizeof(struct cpl_pass_accept_req) + sizeof(struct rss_header)" addition could have an integer wrapping bug. Use size_add() to prevent this.(CVE-2024-57973)
In the Linux kernel, the following vulnerability has been resolved:
media: imx-jpeg: Fix potential error pointer dereference in detach_pm()
The proble is on the first line:
if (jpeg->pd_dev[i] && !pm_runtime_suspended(jpeg->pd_dev[i]))
If jpeg->pd_dev[i] is an error pointer, then passing it to pm_runtime_suspended() will lead to an Oops. The other conditions check for both error pointers and NULL, but it would be more clear to use the IS_ERR_OR_NULL() check for that.(CVE-2024-57978)
In the Linux kernel, the following vulnerability has been resolved:
HID: core: Fix assumption that Resolution Multipliers must be in Logical Collections
A report in 2019 by the syzbot fuzzer was found to be connected to two errors in the HID core associated with Resolution Multipliers. One of the errors was fixed by commit ea427a222d8b ("HID: core: Fix deadloop in hid_apply_multiplier."), but the other has not been fixed.
This error arises because hid_apply_multipler() assumes that every Resolution Multiplier control is contained in a Logical Collection, i.e., there's no way the routine can ever set multiplier_collection to NULL. This is in spite of the fact that the function starts with a big comment saying:
* "The Resolution Multiplier control must be contained in the same
* Logical Collection as the control(s) to which it is to be applied.
...
* If no Logical Collection is
* defined, the Resolution Multiplier is associated with all
* controls in the report."
* HID Usage Table, v1.12, Section 4.3.1, p30
*
* Thus, search from the current collection upwards until we find a
* logical collection...
The comment and the code overlook the possibility that none of the collections found may be a Logical Collection.
The fix is to set the multiplier_collection pointer to NULL if the collection found isn't a Logical Collection.(CVE-2024-57986)
In the Linux kernel, the following vulnerability has been resolved:
HID: hid-thrustmaster: Fix warning in thrustmaster_probe by adding endpoint check
syzbot has found a type mismatch between a USB pipe and the transfer endpoint, which is triggered by the hid-thrustmaster driver[1]. There is a number of similar, already fixed issues [2]. In this case as in others, implementing check for endpoint type fixes the issue.
[1] https://syzkaller.appspot.com/bug?extid=040e8b3db6a96908d470 [2] https://syzkaller.appspot.com/bug?extid=348331f63b034f89b622(CVE-2024-57993)
In the Linux kernel, the following vulnerability has been resolved:
wifi: wcn36xx: fix channel survey memory allocation size
KASAN reported a memory allocation issue in wcn->chan_survey due to incorrect size calculation. This commit uses kcalloc to allocate memory for wcn->chan_survey, ensuring proper initialization and preventing the use of uninitialized values when there are no frames on the channel.(CVE-2024-57997)
In the Linux kernel, the following vulnerability has been resolved:
OPP: add index check to assert to avoid buffer overflow in _read_freq()
Pass the freq index to the assert function to make sure we do not read a freq out of the opp->rates[] table when called from the indexed variants: dev_pm_opp_find_freq_exact_indexed() or dev_pm_opp_find_freq_ceil/floor_indexed().
Add a secondary parameter to the assert function, unused for assert_single_clk() then add assert_clk_index() which will check for the clock index when called from the _indexed() find functions.(CVE-2024-57998)
In the Linux kernel, the following vulnerability has been resolved:
PCI: dwc: ep: Prevent changing BAR size/flags in pci_epc_set_bar()
In commit 4284c88fff0e ("PCI: designware-ep: Allow pci_epc_set_bar() update inbound map address") set_bar() was modified to support dynamically changing the backing physical address of a BAR that was already configured.
This means that set_bar() can be called twice, without ever calling clear_bar() (as calling clear_bar() would clear the BAR's PCI address assigned by the host).
This can only be done if the new BAR size/flags does not differ from the existing BAR configuration. Add these missing checks.
If we allow set_bar() to set e.g. a new BAR size that differs from the existing BAR size, the new address translation range will be smaller than the BAR size already determined by the host, which would mean that a read past the new BAR size would pass the iATU untranslated, which could allow the host to read memory not belonging to the new struct pci_epf_bar.
While at it, add comments which clarifies the support for dynamically changing the physical address of a BAR. (Which was also missing.)(CVE-2024-58006)
In the Linux kernel, the following vulnerability has been resolved:
memory: tegra20-emc: fix an OF node reference bug in tegra_emc_find_node_by_ram_code()
As of_find_node_by_name() release the reference of the argument device node, tegra_emc_find_node_by_ram_code() releases some device nodes while still in use, resulting in possible UAFs. According to the bindings and the in-tree DTS files, the "emc-tables" node is always device's child node with the property "nvidia,use-ram-code", and the "lpddr2" node is a child of the "emc-tables" node. Thus utilize the for_each_child_of_node() macro and of_get_child_by_name() instead of of_find_node_by_name() to simplify the code.
This bug was found by an experimental verification tool that I am developing.
krzysztof: applied v1, adjust the commit msg to incorporate v2 parts
In the Linux kernel, the following vulnerability has been resolved:
ipmi: ipmb: Add check devm_kasprintf() returned value
devm_kasprintf() can return a NULL pointer on failure but this returned value is not checked.(CVE-2024-58051)
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Fix potential NULL pointer dereference in atomctrl_get_smc_sclk_range_table
The function atomctrl_get_smc_sclk_range_table() does not check the return value of smu_atom_get_data_table(). If smu_atom_get_data_table() fails to retrieve SMU_Info table, it returns NULL which is later dereferenced.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
In practice this should never happen as this code only gets called on polaris chips and the vbios data table will always be present on those chips.(CVE-2024-58052)
In the Linux kernel, the following vulnerability has been resolved:
rxrpc: Fix handling of received connection abort
Fix the handling of a connection abort that we've received. Though the abort is at the connection level, it needs propagating to the calls on that connection. Whilst the propagation bit is performed, the calls aren't then woken up to go and process their termination, and as no further input is forthcoming, they just hang.
Also add some tracing for the logging of connection aborts.(CVE-2024-58053)
In the Linux kernel, the following vulnerability has been resolved:
staging: media: max96712: fix kernel oops when removing module
The following kernel oops is thrown when trying to remove the max96712 module:
Unable to handle kernel paging request at virtual address 00007375746174db Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=000000010af89000 [00007375746174db] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP Modules linked in: crct10dif_ce polyval_ce mxc_jpeg_encdec flexcan snd_soc_fsl_sai snd_soc_fsl_asoc_card snd_soc_fsl_micfil dwc_mipi_csi2 imx_csi_formatter polyval_generic v4l2_jpeg imx_pcm_dma can_dev snd_soc_imx_audmux snd_soc_wm8962 snd_soc_imx_card snd_soc_fsl_utils max96712(C-) rpmsg_ctrl rpmsg_char pwm_fan fuse [last unloaded: imx8_isi] CPU: 0 UID: 0 PID: 754 Comm: rmmod Tainted: G C 6.12.0-rc6-06364-g327fec852c31 #17 Tainted: [C]=CRAP Hardware name: NXP i.MX95 19X19 board (DT) pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : led_put+0x1c/0x40 lr : v4l2_subdev_put_privacy_led+0x48/0x58 sp : ffff80008699bbb0 x29: ffff80008699bbb0 x28: ffff00008ac233c0 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000 x23: ffff000080cf1170 x22: ffff00008b53bd00 x21: ffff8000822ad1c8 x20: ffff000080ff5c00 x19: ffff00008b53be40 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000004 x13: ffff0000800f8010 x12: 0000000000000000 x11: ffff000082acf5c0 x10: ffff000082acf478 x9 : ffff0000800f8010 x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff6364626d x5 : 8080808000000000 x4 : 0000000000000020 x3 : 00000000553a3dc1 x2 : ffff00008ac233c0 x1 : ffff00008ac233c0 x0 : ff00737574617473 Call trace: led_put+0x1c/0x40 v4l2_subdev_put_privacy_led+0x48/0x58 v4l2_async_unregister_subdev+0x2c/0x1a4 max96712_remove+0x1c/0x38 [max96712] i2c_device_remove+0x2c/0x9c device_remove+0x4c/0x80 device_release_driver_internal+0x1cc/0x228 driver_detach+0x4c/0x98 bus_remove_driver+0x6c/0xbc driver_unregister+0x30/0x60 i2c_del_driver+0x54/0x64 max96712_i2c_driver_exit+0x18/0x1d0 [max96712] __arm64_sys_delete_module+0x1a4/0x290 invoke_syscall+0x48/0x10c el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xd8 el0t_64_sync_handler+0x120/0x12c el0t_64_sync+0x190/0x194 Code: f9000bf3 aa0003f3 f9402800 f9402000 (f9403400) ---[ end trace 0000000000000000 ]---
This happens because in v4l2_i2c_subdev_init(), the i2c_set_cliendata() is called again and the data is overwritten to point to sd, instead of priv. So, in remove(), the wrong pointer is passed to v4l2_async_unregister_subdev(), leading to a crash.(CVE-2024-58054)
In the Linux kernel, the following vulnerability has been resolved:
remoteproc: core: Fix ida_free call while not allocated
In the rproc_alloc() function, on error, put_device(&rproc->dev) is called, leading to the call of the rproc_type_release() function. An error can occurs before ida_alloc is called.
In such case in rproc_type_release(), the condition (rproc->index >= 0) is true as rproc->index has been initialized to 0. ida_free() is called reporting a warning: [ 4.181906] WARNING: CPU: 1 PID: 24 at lib/idr.c:525 ida_free+0x100/0x164 [ 4.186378] stm32-display-dsi 5a000000.dsi: Fixed dependency cycle(s) with /soc/dsi@5a000000/panel@0 [ 4.188854] ida_free called for id=0 which is not allocated. [ 4.198256] mipi-dsi 5a000000.dsi.0: Fixed dependency cycle(s) with /soc/dsi@5a000000 [ 4.203556] Modules linked in: panel_orisetech_otm8009a dw_mipi_dsi_stm(+) gpu_sched dw_mipi_dsi stm32_rproc stm32_crc32 stm32_ipcc(+) optee(+) [ 4.224307] CPU: 1 UID: 0 PID: 24 Comm: kworker/u10:0 Not tainted 6.12.0 #442 [ 4.231481] Hardware name: STM32 (Device Tree Support) [ 4.236627] Workqueue: events_unbound deferred_probe_work_func [ 4.242504] Call trace: [ 4.242522] unwind_backtrace from show_stack+0x10/0x14 [ 4.250218] show_stack from dump_stack_lvl+0x50/0x64 [ 4.255274] dump_stack_lvl from __warn+0x80/0x12c [ 4.260134] __warn from warn_slowpath_fmt+0x114/0x188 [ 4.265199] warn_slowpath_fmt from ida_free+0x100/0x164 [ 4.270565] ida_free from rproc_type_release+0x38/0x60 [ 4.275832] rproc_type_release from device_release+0x30/0xa0 [ 4.281601] device_release from kobject_put+0xc4/0x294 [ 4.286762] kobject_put from rproc_alloc.part.0+0x208/0x28c [ 4.292430] rproc_alloc.part.0 from devm_rproc_alloc+0x80/0xc4 [ 4.298393] devm_rproc_alloc from stm32_rproc_probe+0xd0/0x844 [stm32_rproc] [ 4.305575] stm32_rproc_probe [stm32_rproc] from platform_probe+0x5c/0xbc
Calling ida_alloc earlier in rproc_alloc ensures that the rproc->index is properly set.(CVE-2024-58056)
In the Linux kernel, the following vulnerability has been resolved:
ubifs: skip dumping tnc tree when zroot is null
Clearing slab cache will free all znode in memory and make c->zroot.znode = NULL, then dumping tnc tree will access c->zroot.znode which cause null pointer dereference.(CVE-2024-58058)
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: prohibit deactivating all links
In the internal API this calls this is a WARN_ON, but that should remain since internally we want to know about bugs that may cause this. Prevent deactivating all links in the debugfs write directly.(CVE-2024-58061)
In the Linux kernel, the following vulnerability has been resolved:
wifi: rtlwifi: fix memory leaks and invalid access at probe error path
Deinitialize at reverse order when probe fails.
When init_sw_vars fails, rtl_deinit_core should not be called, specially now that it destroys the rtl_wq workqueue.
And call rtl_pci_deinit and deinit_sw_vars, otherwise, memory will be leaked.
Remove pci_set_drvdata call as it will already be cleaned up by the core driver code and could lead to memory leaks too. cf. commit 8d450935ae7f ("wireless: rtlwifi: remove unnecessary pci_set_drvdata()") and commit 3d86b93064c7 ("rtlwifi: Fix PCI probe error path orphaned memory").(CVE-2024-58063)
In the Linux kernel, the following vulnerability has been resolved:
OPP: fix dev_pm_opp_find_bw_*() when bandwidth table not initialized
If a driver calls dev_pm_opp_find_bw_ceil/floor() the retrieve bandwidth from the OPP table but the bandwidth table was not created because the interconnect properties were missing in the OPP consumer node, the kernel will crash with:
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004 ... pc : _read_bw+0x8/0x10 lr : _opp_table_find_key+0x9c/0x174 ... Call trace: _read_bw+0x8/0x10 (P) _opp_table_find_key+0x9c/0x174 (L) _find_key+0x98/0x168 dev_pm_opp_find_bw_ceil+0x50/0x88 ...
In order to fix the crash, create an assert function to check if the bandwidth table was created before trying to get a bandwidth with _read_bw().(CVE-2024-58068)
In the Linux kernel, the following vulnerability has been resolved:
team: prevent adding a device which is already a team device lower
Prevent adding a device which is already a team device lower, e.g. adding veth0 if vlan1 was already added and veth0 is a lower of vlan1.
This is not useful in practice and can lead to recursive locking:
$ ip link add veth0 type veth peer name veth1 $ ip link set veth0 up $ ip link set veth1 up $ ip link add link veth0 name veth0.1 type vlan protocol 802.1Q id 1 $ ip link add team0 type team $ ip link set veth0.1 down $ ip link set veth0.1 master team0 team0: Port device veth0.1 added $ ip link set veth0 down $ ip link set veth0 master team0
============================================ WARNING: possible recursive locking detected 6.13.0-rc2-virtme-00441-ga14a429069bb #46 Not tainted
ip/7684 is trying to acquire lock: ffff888016848e00 (team->team_lock_key){+.+.}-{4:4}, at: team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)
but task is already holding lock: ffff888016848e00 (team->team_lock_key){+.+.}-{4:4}, at: team_add_slave (drivers/net/team/team_core.c:1147 drivers/net/team/team_core.c:1977)
other info that might help us debug this: Possible unsafe locking scenario:
CPU0
lock(team->team_lock_key); lock(team->team_lock_key);
*** DEADLOCK ***
May be due to missing lock nesting notation
2 locks held by ip/7684:
stack backtrace: CPU: 3 UID: 0 PID: 7684 Comm: ip Not tainted 6.13.0-rc2-virtme-00441-ga14a429069bb #46 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: <TASK> dump_stack_lvl (lib/dump_stack.c:122) print_deadlock_bug.cold (kernel/locking/lockdep.c:3040) __lock_acquire (kernel/locking/lockdep.c:3893 kernel/locking/lockdep.c:5226) ? netlink_broadcast_filtered (net/netlink/af_netlink.c:1548) lock_acquire.part.0 (kernel/locking/lockdep.c:467 kernel/locking/lockdep.c:5851) ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) ? trace_lock_acquire (./include/trace/events/lock.h:24 (discriminator 2)) ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) ? lock_acquire (kernel/locking/lockdep.c:5822) ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) __mutex_lock (kernel/locking/mutex.c:587 kernel/locking/mutex.c:735) ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) ? fib_sync_up (net/ipv4/fib_semantics.c:2167) ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) notifier_call_chain (kernel/notifier.c:85) call_netdevice_notifiers_info (net/core/dev.c:1996) __dev_notify_flags (net/core/dev.c:8993) ? __dev_change_flags (net/core/dev.c:8975) dev_change_flags (net/core/dev.c:9027) vlan_device_event (net/8021q/vlan.c:85 net/8021q/vlan.c:470) ? br_device_event (net/bridge/br.c:143) notifier_call_chain (kernel/notifier.c:85) call_netdevice_notifiers_info (net/core/dev.c:1996) dev_open (net/core/dev.c:1519 net/core/dev.c:1505) team_add_slave (drivers/net/team/team_core.c:1219 drivers/net/team/team_core.c:1977) ? __pfx_team_add_slave (drivers/net/team/team_core.c:1972) do_set_master (net/core/rtnetlink.c:2917) do_setlink.isra.0 (net/core/rtnetlink.c:3117)(CVE-2024-58071)
In the Linux kernel, the following vulnerability has been resolved:
wifi: rtlwifi: remove unused check_buddy_priv
Commit 2461c7d60f9f ("rtlwifi: Update header file") introduced a global list of private data structures.
Later on, commit 26634c4b1868 ("rtlwifi Modify existing bits to match vendor version 2013.02.07") started adding the private data to that list at probe time and added a hook, check_buddy_priv to find the private data from a similar device.
However, that function was never used.
Besides, though there is a lock for that list, it is never used. And when the probe fails, the private data is never removed from the list. This would cause a second probe to access freed memory.
Remove the unused hook, structures and members, which will prevent the potential race condition on the list and its corruption during a second probe when probe fails.(CVE-2024-58072)
In the Linux kernel, the following vulnerability has been resolved:
vfio/platform: check the bounds of read/write syscalls
count and offset are passed from user space and not checked, only offset is capped to 40 bits, which can be used to read/write out of bounds of the device.(CVE-2025-21687)
In the Linux kernel, the following vulnerability has been resolved:
mptcp: handle fastopen disconnect correctly
Syzbot was able to trigger a data stream corruption:
WARNING: CPU: 0 PID: 9846 at net/mptcp/protocol.c:1024 __mptcp_clean_una+0xddb/0xff0 net/mptcp/protocol.c:1024 Modules linked in: CPU: 0 UID: 0 PID: 9846 Comm: syz-executor351 Not tainted 6.13.0-rc2-syzkaller-00059-g00a5acdbf398 #0 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 11/25/2024 RIP: 0010:__mptcp_clean_una+0xddb/0xff0 net/mptcp/protocol.c:1024 Code: fa ff ff 48 8b 4c 24 18 80 e1 07 fe c1 38 c1 0f 8c 8e fa ff ff 48 8b 7c 24 18 e8 e0 db 54 f6 e9 7f fa ff ff e8 e6 80 ee f5 90 <0f> 0b 90 4c 8b 6c 24 40 4d 89 f4 e9 04 f5 ff ff 44 89 f1 80 e1 07 RSP: 0018:ffffc9000c0cf400 EFLAGS: 00010293 RAX: ffffffff8bb0dd5a RBX: ffff888033f5d230 RCX: ffff888059ce8000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffc9000c0cf518 R08: ffffffff8bb0d1dd R09: 1ffff110170c8928 R10: dffffc0000000000 R11: ffffed10170c8929 R12: 0000000000000000 R13: ffff888033f5d220 R14: dffffc0000000000 R15: ffff8880592b8000 FS: 00007f6e866496c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f6e86f491a0 CR3: 00000000310e6000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __mptcp_clean_una_wakeup+0x7f/0x2d0 net/mptcp/protocol.c:1074 mptcp_release_cb+0x7cb/0xb30 net/mptcp/protocol.c:3493 release_sock+0x1aa/0x1f0 net/core/sock.c:3640 inet_wait_for_connect net/ipv4/af_inet.c:609 [inline] __inet_stream_connect+0x8bd/0xf30 net/ipv4/af_inet.c:703 mptcp_sendmsg_fastopen+0x2a2/0x530 net/mptcp/protocol.c:1755 mptcp_sendmsg+0x1884/0x1b10 net/mptcp/protocol.c:1830 sock_sendmsg_nosec net/socket.c:711 [inline] __sock_sendmsg+0x1a6/0x270 net/socket.c:726 _syssendmsg+0x52a/0x7e0 net/socket.c:2583 _sys_sendmsg net/socket.c:2637 [inline] __sys_sendmsg+0x269/0x350 net/socket.c:2669 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f6e86ebfe69 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 b1 1f 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:00007f6e86649168 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f6e86f491b8 RCX: 00007f6e86ebfe69 RDX: 0000000030004001 RSI: 0000000020000080 RDI: 0000000000000003 RBP: 00007f6e86f491b0 R08: 00007f6e866496c0 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f6e86f491bc R13: 000000000000006e R14: 00007ffe445d9420 R15: 00007ffe445d9508 </TASK>
The root cause is the bad handling of disconnect() generated internally by the MPTCP protocol in case of connect FASTOPEN errors.
Address the issue increasing the socket disconnect counter even on such a case, to allow other threads waiting on the same socket lock to properly error out.(CVE-2025-21705)
In the Linux kernel, the following vulnerability has been resolved:
mptcp: consolidate suboption status
MPTCP maintains the received sub-options status is the bitmask carrying the received suboptions and in several bitfields carrying per suboption additional info.
Zeroing the bitmask before parsing is not enough to ensure a consistent status, and the MPTCP code has to additionally clear some bitfiled depending on the actually parsed suboption.
The above schema is fragile, and syzbot managed to trigger a path where a relevant bitfield is not cleared/initialized:
BUG: KMSAN: uninit-value in __mptcp_expand_seq net/mptcp/options.c:1030 [inline] BUG: KMSAN: uninit-value in mptcp_expand_seq net/mptcp/protocol.h:864 [inline] BUG: KMSAN: uninit-value in ack_update_msk net/mptcp/options.c:1060 [inline] BUG: KMSAN: uninit-value in mptcp_incoming_options+0x2036/0x3d30 net/mptcp/options.c:1209 __mptcp_expand_seq net/mptcp/options.c:1030 [inline] mptcp_expand_seq net/mptcp/protocol.h:864 [inline] ack_update_msk net/mptcp/options.c:1060 [inline] mptcp_incoming_options+0x2036/0x3d30 net/mptcp/options.c:1209 tcp_data_queue+0xb4/0x7be0 net/ipv4/tcp_input.c:5233 tcp_rcv_established+0x1061/0x2510 net/ipv4/tcp_input.c:6264 tcp_v4_do_rcv+0x7f3/0x11a0 net/ipv4/tcp_ipv4.c:1916 tcp_v4_rcv+0x51df/0x5750 net/ipv4/tcp_ipv4.c:2351 ip_protocol_deliver_rcu+0x2a3/0x13d0 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x336/0x500 net/ipv4/ip_input.c:233 NF_HOOK include/linux/netfilter.h:314 [inline] ip_local_deliver+0x21f/0x490 net/ipv4/ip_input.c:254 dst_input include/net/dst.h:460 [inline] ip_rcv_finish+0x4a2/0x520 net/ipv4/ip_input.c:447 NF_HOOK include/linux/netfilter.h:314 [inline] ip_rcv+0xcd/0x380 net/ipv4/ip_input.c:567 __netif_receive_skb_one_core net/core/dev.c:5704 [inline] __netif_receive_skb+0x319/0xa00 net/core/dev.c:5817 process_backlog+0x4ad/0xa50 net/core/dev.c:6149 __napi_poll+0xe7/0x980 net/core/dev.c:6902 napi_poll net/core/dev.c:6971 [inline] net_rx_action+0xa5a/0x19b0 net/core/dev.c:7093 handle_softirqs+0x1a0/0x7c0 kernel/softirq.c:561 __do_softirq+0x14/0x1a kernel/softirq.c:595 do_softirq+0x9a/0x100 kernel/softirq.c:462 __local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:389 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:919 [inline] __dev_queue_xmit+0x2758/0x57d0 net/core/dev.c:4493 dev_queue_xmit include/linux/netdevice.h:3168 [inline] neigh_hh_output include/net/neighbour.h:523 [inline] neigh_output include/net/neighbour.h:537 [inline] ip_finish_output2+0x187c/0x1b70 net/ipv4/ip_output.c:236 __ip_finish_output+0x287/0x810 ip_finish_output+0x4b/0x600 net/ipv4/ip_output.c:324 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip_output+0x15f/0x3f0 net/ipv4/ip_output.c:434 dst_output include/net/dst.h:450 [inline] ip_local_out net/ipv4/ip_output.c:130 [inline] __ip_queue_xmit+0x1f2a/0x20d0 net/ipv4/ip_output.c:536 ip_queue_xmit+0x60/0x80 net/ipv4/ip_output.c:550 __tcp_transmit_skb+0x3cea/0x4900 net/ipv4/tcp_output.c:1468 tcp_transmit_skb net/ipv4/tcp_output.c:1486 [inline] tcp_write_xmit+0x3b90/0x9070 net/ipv4/tcp_output.c:2829 __tcp_push_pending_frames+0xc4/0x380 net/ipv4/tcp_output.c:3012 tcp_send_fin+0x9f6/0xf50 net/ipv4/tcp_output.c:3618 __tcp_close+0x140c/0x1550 net/ipv4/tcp.c:3130 __mptcp_close_ssk+0x74e/0x16f0 net/mptcp/protocol.c:2496 mptcp_close_ssk+0x26b/0x2c0 net/mptcp/protocol.c:2550 mptcp_pm_nl_rm_addr_or_subflow+0x635/0xd10 net/mptcp/pm_netlink.c:889 mptcp_pm_nl_rm_subflow_received net/mptcp/pm_netlink.c:924 [inline] mptcp_pm_flush_addrs_and_subflows net/mptcp/pm_netlink.c:1688 [inline] mptcp_nl_flush_addrs_list net/mptcp/pm_netlink.c:1709 [inline] mptcp_pm_nl_flush_addrs_doit+0xe10/0x1630 net/mptcp/pm_netlink.c:1750 genl_family_rcv_msg_doit net/netlink/genetlink.c:1115 [inline]
---truncated---(CVE-2025-21707)
In the Linux kernel, the following vulnerability has been resolved:
net: usb: rtl8150: enable basic endpoint checking
Syzkaller reports [1] encountering a common issue of utilizing a wrong usb endpoint type during URB submitting stage. This, in turn, triggers a warning shown below.
For now, enable simple endpoint checking (specifically, bulk and interrupt eps, testing control one is not essential) to mitigate the issue with a view to do other related cosmetic changes later, if they are necessary.
[1] Syzkaller report: usb 1-1: BOGUS urb xfer, pipe 3 != type 1 WARNING: CPU: 1 PID: 2586 at drivers/usb/core/urb.c:503 usb_submit_urb+0xe4b/0x1730 driv> Modules linked in: CPU: 1 UID: 0 PID: 2586 Comm: dhcpcd Not tainted 6.11.0-rc4-syzkaller-00069-gfc88bb11617> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:usb_submit_urb+0xe4b/0x1730 drivers/usb/core/urb.c:503 Code: 84 3c 02 00 00 e8 05 e4 fc fc 4c 89 ef e8 fd 25 d7 fe 45 89 e0 89 e9 4c 89 f2 48 8> RSP: 0018:ffffc9000441f740 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff888112487a00 RCX: ffffffff811a99a9 RDX: ffff88810df6ba80 RSI: ffffffff811a99b6 RDI: 0000000000000001 RBP: 0000000000000003 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000001 R13: ffff8881023bf0a8 R14: ffff888112452a20 R15: ffff888112487a7c FS: 00007fc04eea5740(0000) GS:ffff8881f6300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f0a1de9f870 CR3: 000000010dbd0000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> rtl8150_open+0x300/0xe30 drivers/net/usb/rtl8150.c:733 __dev_open+0x2d4/0x4e0 net/core/dev.c:1474 __dev_change_flags+0x561/0x720 net/core/dev.c:8838 dev_change_flags+0x8f/0x160 net/core/dev.c:8910 devinet_ioctl+0x127a/0x1f10 net/ipv4/devinet.c:1177 inet_ioctl+0x3aa/0x3f0 net/ipv4/af_inet.c:1003 sock_do_ioctl+0x116/0x280 net/socket.c:1222 sock_ioctl+0x22e/0x6c0 net/socket.c:1341 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl fs/ioctl.c:893 [inline] __x64_sys_ioctl+0x193/0x220 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fc04ef73d49 ...
This change has not been tested on real hardware.(CVE-2025-21708)
In the Linux kernel, the following vulnerability has been resolved:
tcp: correct handling of extreme memory squeeze
Testing with iperf3 using the "pasta" protocol splicer has revealed a problem in the way tcp handles window advertising in extreme memory squeeze situations.
Under memory pressure, a socket endpoint may temporarily advertise a zero-sized window, but this is not stored as part of the socket data. The reasoning behind this is that it is considered a temporary setting which shouldn't influence any further calculations.
However, if we happen to stall at an unfortunate value of the current window size, the algorithm selecting a new value will consistently fail to advertise a non-zero window once we have freed up enough memory. This means that this side's notion of the current window size is different from the one last advertised to the peer, causing the latter to not send any data to resolve the sitution.
The problem occurs on the iperf3 server side, and the socket in question is a completely regular socket with the default settings for the fedora40 kernel. We do not use SO_PEEK or SO_RCVBUF on the socket.
The following excerpt of a logging session, with own comments added, shows more in detail what is happening:
// tcp_v4_rcv(->) // tcp_rcv_established(->) 5201<->39222: ==== Activating log @ net/ipv4/tcp_input.c/tcp_data_queue()/5257 ====
5201<->39222: DROPPING skb [265600160..265665640], reason: SKB_DROP_REASON_PROTO_MEM [rcv_nxt 265600160, rcv_wnd 262144, snt_ack 265469200, win_now 131184] [copied_seq 259909392->260034360 (124968), unread 5565800, qlen 85, ofoq 0] [OFO queue: gap: 65480, len: 0]
[tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160]
5201<->39222: (inet_csk(sk)->icsk_ack.pending & ICSK_ACK_NOMEM) ? --> TRUE [tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160] returning 0
5201<->39222: ADVERTISING WIN 0, ACK_SEQ: 265600160
// Receive queue is at 85 buffers and we are out of memory. // We drop the incoming buffer, although it is in sequence, and decide // to send an advertisement with a window of zero. // We don't update tp->rcv_wnd and tp->rcv_wup accordingly, which means // we unconditionally shrink the window.
5201<->39222: __tcp_cleanup_rbuf(->) tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160 5201<->39222: new_win = 0, win_now = 131184, 2 * win_now = 262368: new_win >= (2 * win_now) ? --> time_to_ack = 0: NOT calling tcp_send_ack() [tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160]
[rcv_nxt 265600160, rcv_wnd 262144, snt_ack 265469200, win_now 131184]
[copied_seq 260040464->260040464 (0), unread 5559696, qlen 85, ofoq 0]
returning 6104 bytes
// After each read, the algorithm for calculating the new receive // window in __tcp_cleanup_rbuf() finds it is too small to advertise // or to update tp->rcv_wnd. // Meanwhile, the peer thinks the window is zero, and will not send // any more data to trigger an update from the interrupt mode side.
5201<->39222: __tcp_cleanup_rbuf(->) tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160 5201<->39222: [new_win = 262144, win_now = 131184, 2 * win_n ---truncated---(CVE-2025-21710)
In the Linux kernel, the following vulnerability has been resolved:
net/rose: prevent integer overflows in rose_setsockopt()
In case of possible unpredictably large arguments passed to rose_setsockopt() and multiplied by extra values on top of that, integer overflows may occur.
Do the safest minimum and fix these issues by checking the contents of 'opt' and returning -EINVAL if they are too large. Also, switch to unsigned int and remove useless check for negative 'opt' in ROSE_IDLE case.(CVE-2025-21711)
In the Linux kernel, the following vulnerability has been resolved:
net: davicom: fix UAF in dm9000_drv_remove
dm is netdev private data and it cannot be used after free_netdev() call. Using dm after free_netdev() can cause UAF bug. Fix it by moving free_netdev() at the end of the function.
This is similar to the issue fixed in commit ad297cd2db89 ("net: qcom/emac: fix UAF in emac_remove").
This bug is detected by our static analysis tool.(CVE-2025-21715)
In the Linux kernel, the following vulnerability has been resolved:
vxlan: Fix uninit-value in vxlan_vnifilter_dump()
KMSAN reported an uninit-value access in vxlan_vnifilter_dump() [1].
If the length of the netlink message payload is less than sizeof(struct tunnel_msg), vxlan_vnifilter_dump() accesses bytes beyond the message. This can lead to uninit-value access. Fix this by returning an error in such situations.
[1] BUG: KMSAN: uninit-value in vxlan_vnifilter_dump+0x328/0x920 drivers/net/vxlan/vxlan_vnifilter.c:422 vxlan_vnifilter_dump+0x328/0x920 drivers/net/vxlan/vxlan_vnifilter.c:422 rtnl_dumpit+0xd5/0x2f0 net/core/rtnetlink.c:6786 netlink_dump+0x93e/0x15f0 net/netlink/af_netlink.c:2317 __netlink_dump_start+0x716/0xd60 net/netlink/af_netlink.c:2432 netlink_dump_start include/linux/netlink.h:340 [inline] rtnetlink_dump_start net/core/rtnetlink.c:6815 [inline] rtnetlink_rcv_msg+0x1256/0x14a0 net/core/rtnetlink.c:6882 netlink_rcv_skb+0x467/0x660 net/netlink/af_netlink.c:2542 rtnetlink_rcv+0x35/0x40 net/core/rtnetlink.c:6944 netlink_unicast_kernel net/netlink/af_netlink.c:1321 [inline] netlink_unicast+0xed6/0x1290 net/netlink/af_netlink.c:1347 netlink_sendmsg+0x1092/0x1230 net/netlink/af_netlink.c:1891 sock_sendmsg_nosec net/socket.c:711 [inline] __sock_sendmsg+0x330/0x3d0 net/socket.c:726 _syssendmsg+0x7f4/0xb50 net/socket.c:2583 _sys_sendmsg+0x271/0x3b0 net/socket.c:2637 __sys_sendmsg net/socket.c:2669 [inline] __do_sys_sendmsg net/socket.c:2674 [inline] __se_sys_sendmsg net/socket.c:2672 [inline] __x64_sys_sendmsg+0x211/0x3e0 net/socket.c:2672 x64_sys_call+0x3878/0x3d90 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xd9/0x1d0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Uninit was created at: slab_post_alloc_hook mm/slub.c:4110 [inline] slab_alloc_node mm/slub.c:4153 [inline] kmem_cache_alloc_node_noprof+0x800/0xe80 mm/slub.c:4205 kmalloc_reserve+0x13b/0x4b0 net/core/skbuff.c:587 __alloc_skb+0x347/0x7d0 net/core/skbuff.c:678 alloc_skb include/linux/skbuff.h:1323 [inline] netlink_alloc_large_skb+0xa5/0x280 net/netlink/af_netlink.c:1196 netlink_sendmsg+0xac9/0x1230 net/netlink/af_netlink.c:1866 sock_sendmsg_nosec net/socket.c:711 [inline] __sock_sendmsg+0x330/0x3d0 net/socket.c:726 _syssendmsg+0x7f4/0xb50 net/socket.c:2583 _sys_sendmsg+0x271/0x3b0 net/socket.c:2637 __sys_sendmsg net/socket.c:2669 [inline] __do_sys_sendmsg net/socket.c:2674 [inline] __se_sys_sendmsg net/socket.c:2672 [inline] __x64_sys_sendmsg+0x211/0x3e0 net/socket.c:2672 x64_sys_call+0x3878/0x3d90 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xd9/0x1d0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f
CPU: 0 UID: 0 PID: 30991 Comm: syz.4.10630 Not tainted 6.12.0-10694-gc44daa7e3c73 #29 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014(CVE-2025-21716)
In the Linux kernel, the following vulnerability has been resolved:
xfrm: delete intermediate secpath entry in packet offload mode
Packets handled by hardware have added secpath as a way to inform XFRM core code that this path was already handled. That secpath is not needed at all after policy is checked and it is removed later in the stack.
However, in the case of IP forwarding is enabled (/proc/sys/net/ipv4/ip_forward), that secpath is not removed and packets which already were handled are reentered to the driver TX path with xfrm_offload set.
The following kernel panic is observed in mlx5 in such case:
mlx5_core 0000:04:00.0 enp4s0f0np0: Link up mlx5_core 0000:04:00.1 enp4s0f1np1: Link up Initializing XFRM netlink socket IPsec XFRM device driver BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor instruction fetch in kernel mode #PF: error_code(0x0010) - not-present page PGD 0 P4D 0 Oops: Oops: 0010 [#1] PREEMPT SMP CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.13.0-rc1-alex #3 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:0x0 Code: Unable to access opcode bytes at 0xffffffffffffffd6. RSP: 0018:ffffb87380003800 EFLAGS: 00010206 RAX: ffff8df004e02600 RBX: ffffb873800038d8 RCX: 00000000ffff98cf RDX: ffff8df00733e108 RSI: ffff8df00521fb80 RDI: ffff8df001661f00 RBP: ffffb87380003850 R08: ffff8df013980000 R09: 0000000000000010 R10: 0000000000000002 R11: 0000000000000002 R12: ffff8df001661f00 R13: ffff8df00521fb80 R14: ffff8df00733e108 R15: ffff8df011faf04e FS: 0000000000000000(0000) GS:ffff8df46b800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffffffffd6 CR3: 0000000106384000 CR4: 0000000000350ef0 Call Trace: <IRQ> ? show_regs+0x63/0x70 ? __die_body+0x20/0x60 ? __die+0x2b/0x40 ? page_fault_oops+0x15c/0x550 ? do_user_addr_fault+0x3ed/0x870 ? exc_page_fault+0x7f/0x190 ? asm_exc_page_fault+0x27/0x30 mlx5e_ipsec_handle_tx_skb+0xe7/0x2f0 [mlx5_core] mlx5e_xmit+0x58e/0x1980 [mlx5_core] ? __fib_lookup+0x6a/0xb0 dev_hard_start_xmit+0x82/0x1d0 sch_direct_xmit+0xfe/0x390 __dev_queue_xmit+0x6d8/0xee0 ? __fib_lookup+0x6a/0xb0 ? internal_add_timer+0x48/0x70 ? mod_timer+0xe2/0x2b0 neigh_resolve_output+0x115/0x1b0 __neigh_update+0x26a/0xc50 neigh_update+0x14/0x20 arp_process+0x2cb/0x8e0 ? __napi_build_skb+0x5e/0x70 arp_rcv+0x11e/0x1c0 ? dev_gro_receive+0x574/0x820 __netif_receive_skb_list_core+0x1cf/0x1f0 netif_receive_skb_list_internal+0x183/0x2a0 napi_complete_done+0x76/0x1c0 mlx5e_napi_poll+0x234/0x7a0 [mlx5_core] __napi_poll+0x2d/0x1f0 net_rx_action+0x1a6/0x370 ? atomic_notifier_call_chain+0x3b/0x50 ? irq_int_handler+0x15/0x20 [mlx5_core] handle_softirqs+0xb9/0x2f0 ? handle_irq_event+0x44/0x60 irq_exit_rcu+0xdb/0x100 common_interrupt+0x98/0xc0 </IRQ> <TASK> asm_common_interrupt+0x27/0x40 RIP: 0010:pv_native_safe_halt+0xb/0x10 Code: 09 c3 66 66 2e 0f 1f 84 00 00 00 00 00 66 90 0f 22 0f 1f 84 00 00 00 00 00 90 eb 07 0f 00 2d 7f e9 36 00 fb 40 00 83 ff 07 77 21 89 ff ff 24 fd 88 3d a1 bd 0f 21 f8 RSP: 0018:ffffffffbe603de8 EFLAGS: 00000202 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000f92f46680 RDX: 0000000000000037 RSI: 00000000ffffffff RDI: 00000000000518d4 RBP: ffffffffbe603df0 R08: 000000cd42e4dffb R09: ffffffffbe603d70 R10: 0000004d80d62680 R11: 0000000000000001 R12: ffffffffbe60bf40 R13: 0000000000000000 R14: 0000000000000000 R15: ffffffffbe60aff8 ? default_idle+0x9/0x20 arch_cpu_idle+0x9/0x10 default_idle_call+0x29/0xf0 do_idle+0x1f2/0x240 cpu_startup_entry+0x2c/0x30 rest_init+0xe7/0x100 start_kernel+0x76b/0xb90 x86_64_start_reservations+0x18/0x30 x86_64_start_kernel+0xc0/0x110 ? setup_ghcb+0xe/0x130 common_startup_64+0x13e/0x141 </TASK> Modules linked in: esp4_offload esp4 xfrm_interface xfrm6_tunnel tunnel4 tunnel6 xfrm_user xfrm_algo binf ---truncated---(CVE-2025-21720)
In the Linux kernel, the following vulnerability has been resolved:
iommufd/iova_bitmap: Fix shift-out-of-bounds in iova_bitmap_offset_to_index()
Resolve a UBSAN shift-out-of-bounds issue in iova_bitmap_offset_to_index() where shifting the constant "1" (of type int) by bitmap->mapped.pgshift (an unsigned long value) could result in undefined behavior.
The constant "1" defaults to a 32-bit "int", and when "pgshift" exceeds 31 (e.g., pgshift = 63) the shift operation overflows, as the result cannot be represented in a 32-bit type.
To resolve this, the constant is updated to "1UL", promoting it to an unsigned long type to match the operand's type.(CVE-2025-21724)
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix oops due to unset link speed
It isn't guaranteed that NETWORK_INTERFACE_INFO::LinkSpeed will always be set by the server, so the client must handle any values and then prevent oopses like below from happening:
Oops: divide error: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 0 UID: 0 PID: 1323 Comm: cat Not tainted 6.13.0-rc7 #2 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-3.fc41 04/01/2014 RIP: 0010:cifs_debug_data_proc_show+0xa45/0x1460 [cifs] Code: 00 00 48 89 df e8 3b cd 1b c1 41 f6 44 24 2c 04 0f 84 50 01 00 00 48 89 ef e8 e7 d0 1b c1 49 8b 44 24 18 31 d2 49 8d 7c 24 28 <48> f7 74 24 18 48 89 c3 e8 6e cf 1b c1 41 8b 6c 24 28 49 8d 7c 24 RSP: 0018:ffffc90001817be0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff88811230022c RCX: ffffffffc041bd99 RDX: 0000000000000000 RSI: 0000000000000567 RDI: ffff888112300228 RBP: ffff888112300218 R08: fffff52000302f5f R09: ffffed1022fa58ac R10: ffff888117d2c566 R11: 00000000fffffffe R12: ffff888112300200 R13: 000000012a15343f R14: 0000000000000001 R15: ffff888113f2db58 FS: 00007fe27119e740(0000) GS:ffff888148600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fe2633c5000 CR3: 0000000124da0000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: <TASK> ? __die_body.cold+0x19/0x27 ? die+0x2e/0x50 ? do_trap+0x159/0x1b0 ? cifs_debug_data_proc_show+0xa45/0x1460 [cifs] ? do_error_trap+0x90/0x130 ? cifs_debug_data_proc_show+0xa45/0x1460 [cifs] ? exc_divide_error+0x39/0x50 ? cifs_debug_data_proc_show+0xa45/0x1460 [cifs] ? asm_exc_divide_error+0x1a/0x20 ? cifs_debug_data_proc_show+0xa39/0x1460 [cifs] ? cifs_debug_data_proc_show+0xa45/0x1460 [cifs] ? seq_read_iter+0x42e/0x790 seq_read_iter+0x19a/0x790 proc_reg_read_iter+0xbe/0x110 ? __pfx_proc_reg_read_iter+0x10/0x10 vfs_read+0x469/0x570 ? do_user_addr_fault+0x398/0x760 ? __pfx_vfs_read+0x10/0x10 ? find_held_lock+0x8a/0xa0 ? __pfx_lock_release+0x10/0x10 ksys_read+0xd3/0x170 ? __pfx_ksys_read+0x10/0x10 ? __rcu_read_unlock+0x50/0x270 ? mark_held_locks+0x1a/0x90 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fe271288911 Code: 00 48 8b 15 01 25 10 00 f7 d8 64 89 02 b8 ff ff ff ff eb bd e8 20 ad 01 00 f3 0f 1e fa 80 3d b5 a7 10 00 00 74 13 31 c0 0f 05 <48> 3d 00 f0 ff ff 77 4f c3 66 0f 1f 44 00 00 55 48 89 e5 48 83 ec RSP: 002b:00007ffe87c079d8 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 RAX: ffffffffffffffda RBX: 0000000000040000 RCX: 00007fe271288911 RDX: 0000000000040000 RSI: 00007fe2633c6000 RDI: 0000000000000003 RBP: 00007ffe87c07a00 R08: 0000000000000000 R09: 00007fe2713e6380 R10: 0000000000000022 R11: 0000000000000246 R12: 0000000000040000 R13: 00007fe2633c6000 R14: 0000000000000003 R15: 0000000000000000 </TASK>
Fix this by setting cifs_server_iface::speed to a sane value (1Gbps) by default when link speed is unset.(CVE-2025-21725)
In the Linux kernel, the following vulnerability has been resolved:
padata: avoid UAF for reorder_work
Although the previous patch can avoid ps and ps UAF for _do_serial, it can not avoid potential UAF issue for reorder_work. This issue can happen just as below:
crypto_request crypto_request crypto_del_alg padata_do_serial ... padata_reorder // processes all remaining // requests then breaks while (1) { if (!padata) break; ... }
padata_do_serial
// new request added
list_add
// sees the new request
queue_work(reorder_work)
padata_reorder
queue_work_on(squeue->work)
...
<kworker context>
padata_serial_worker
// completes new request,
// no more outstanding
// requests
crypto_del_alg
// free pd
<kworker context> invoke_padata_reorder // UAF of pd
To avoid UAF for 'reorder_work', get 'pd' ref before put 'reorder_work' into the 'serial_wq' and put 'pd' ref until the 'serial_wq' finish.(CVE-2025-21726)
In the Linux kernel, the following vulnerability has been resolved:
padata: fix UAF in padata_reorder
A bug was found when run ltp test:
BUG: KASAN: slab-use-after-free in padata_find_next+0x29/0x1a0 Read of size 4 at addr ffff88bbfe003524 by task kworker/u113:2/3039206
CPU: 0 PID: 3039206 Comm: kworker/u113:2 Kdump: loaded Not tainted 6.6.0+ Workqueue: pdecrypt_parallel padata_parallel_worker Call Trace: <TASK> dump_stack_lvl+0x32/0x50 print_address_description.constprop.0+0x6b/0x3d0 print_report+0xdd/0x2c0 kasan_report+0xa5/0xd0 padata_find_next+0x29/0x1a0 padata_reorder+0x131/0x220 padata_parallel_worker+0x3d/0xc0 process_one_work+0x2ec/0x5a0
If 'mdelay(10)' is added before calling 'padata_find_next' in the 'padata_reorder' function, this issue could be reproduced easily with ltp test (pcrypt_aead01).
This can be explained as bellow:
pcrypt_aead_encrypt ... padata_do_parallel refcount_inc(&pd->refcnt); // add refcnt ... padata_do_serial padata_reorder // pd while (1) { padata_find_next(pd, true); // using pd queue_work_on ... padata_serial_worker crypto_del_alg padata_put_pd_cnt // sub refcnt padata_free_shell padata_put_pd(ps->pd); // pd is freed // loop again, but pd is freed // call padata_find_next, UAF }
In the padata_reorder function, when it loops in 'while', if the alg is deleted, the refcnt may be decreased to 0 before entering 'padata_find_next', which leads to UAF.
As mentioned in [1], do_serial is supposed to be called with BHs disabled and always happen under RCU protection, to address this issue, add synchronize_rcu() in 'padata_free_shell' wait for all _do_serial calls to finish.
[1] https://lore.kernel.org/all/20221028160401.cccypv4euxikusiq@parnassus.localdomain/ [2] https://lore.kernel.org/linux-kernel/jfjz5d7zwbytztackem7ibzalm5lnxldi2eofeiczqmqs2m7o6@fq426cwnjtkm/(CVE-2025-21727)
In the Linux kernel, the following vulnerability has been resolved:
bpf: Send signals asynchronously if !preemptible
BPF programs can execute in all kinds of contexts and when a program
running in a non-preemptible context uses the bpf_send_signal() kfunc,
it will cause issues because this kfunc can sleep.
Change irqs_disabled() to !preemptible().(CVE-2025-21728)
In the Linux kernel, the following vulnerability has been resolved:
blk-cgroup: Fix class @block_class's subsystem refcount leakage
blkcg_fill_root_iostats() iterates over @block_class's devices by class_dev_iter_(init|next)(), but does not end iterating with class_dev_iter_exit(), so causes the class's subsystem refcount leakage.
Fix by ending the iterating with class_dev_iter_exit().(CVE-2025-21745)
In the Linux kernel, the following vulnerability has been resolved:
net: ethernet: ti: am65-cpsw: fix freeing IRQ in am65_cpsw_nuss_remove_tx_chns()
When getting the IRQ we use k3_udma_glue_tx_get_irq() which returns negative error value on error. So not NULL check is not sufficient to deteremine if IRQ is valid. Check that IRQ is greater then zero to ensure it is valid.
There is no issue at probe time but at runtime user can invoke .set_channels which results in the following call chain. am65_cpsw_set_channels() am65_cpsw_nuss_update_tx_rx_chns() am65_cpsw_nuss_remove_tx_chns() am65_cpsw_nuss_init_tx_chns()
At this point if am65_cpsw_nuss_init_tx_chns() fails due to k3_udma_glue_tx_get_irq() then tx_chn->irq will be set to a negative value.
Then, at subsequent .set_channels with higher channel count we will attempt to free an invalid IRQ in am65_cpsw_nuss_remove_tx_chns() leading to a kernel warning.
The issue is present in the original commit that introduced this driver, although there, am65_cpsw_nuss_update_tx_rx_chns() existed as am65_cpsw_nuss_update_tx_chns().(CVE-2025-21799)
In the Linux kernel, the following vulnerability has been resolved:
LoongArch: Fix warnings during S3 suspend
The enable_gpe_wakeup() function calls acpi_enable_all_wakeup_gpes(), and the later one may call the preempt_schedule_common() function, resulting in a thread switch and causing the CPU to be in an interrupt enabled state after the enable_gpe_wakeup() function returns, leading to the warnings as follow.
[ C0] WARNING: ... at kernel/time/timekeeping.c:845 ktime_get+0xbc/0xc8 [ C0] ... [ C0] Call Trace: [ C0] [<90000000002243b4>] show_stack+0x64/0x188 [ C0] [<900000000164673c>] dump_stack_lvl+0x60/0x88 [ C0] [<90000000002687e4>] __warn+0x8c/0x148 [ C0] [<90000000015e9978>] report_bug+0x1c0/0x2b0 [ C0] [<90000000016478e4>] do_bp+0x204/0x3b8 [ C0] [<90000000025b1924>] exception_handlers+0x1924/0x10000 [ C0] [<9000000000343bbc>] ktime_get+0xbc/0xc8 [ C0] [<9000000000354c08>] tick_sched_timer+0x30/0xb0 [ C0] [<90000000003408e0>] __hrtimer_run_queues+0x160/0x378 [ C0] [<9000000000341f14>] hrtimer_interrupt+0x144/0x388 [ C0] [<9000000000228348>] constant_timer_interrupt+0x38/0x48 [ C0] [<90000000002feba4>] __handle_irq_event_percpu+0x64/0x1e8 [ C0] [<90000000002fed48>] handle_irq_event_percpu+0x20/0x80 [ C0] [<9000000000306b9c>] handle_percpu_irq+0x5c/0x98 [ C0] [<90000000002fd4a0>] generic_handle_domain_irq+0x30/0x48 [ C0] [<9000000000d0c7b0>] handle_cpu_irq+0x70/0xa8 [ C0] [<9000000001646b30>] handle_loongarch_irq+0x30/0x48 [ C0] [<9000000001646bc8>] do_vint+0x80/0xe0 [ C0] [<90000000002aea1c>] finish_task_switch.isra.0+0x8c/0x2a8 [ C0] [<900000000164e34c>] __schedule+0x314/0xa48 [ C0] [<900000000164ead8>] schedule+0x58/0xf0 [ C0] [<9000000000294a2c>] worker_thread+0x224/0x498 [ C0] [<900000000029d2f0>] kthread+0xf8/0x108 [ C0] [<9000000000221f28>] ret_from_kernel_thread+0xc/0xa4 [ C0] [ C0] ---[ end trace 0000000000000000 ]---
The root cause is acpi_enable_all_wakeup_gpes() uses a mutex to protect acpi_hw_enable_all_wakeup_gpes(), and acpi_ut_acquire_mutex() may cause a thread switch. Since there is no longer concurrent execution during loongarch_acpi_suspend(), we can call acpi_hw_enable_all_wakeup_gpes() directly in enable_gpe_wakeup().
The solution is similar to commit 22db06337f590d01 ("ACPI: sleep: Avoid breaking S3 wakeup due to might_sleep()").(CVE-2025-21803)
In the Linux kernel, the following vulnerability has been resolved:
PCI: rcar-ep: Fix incorrect variable used when calling devm_request_mem_region()
The rcar_pcie_parse_outbound_ranges() uses the devm_request_mem_region() macro to request a needed resource. A string variable that lives on the stack is then used to store a dynamically computed resource name, which is then passed on as one of the macro arguments. This can lead to undefined behavior.
Depending on the current contents of the memory, the manifestations of errors may vary. One possible output may be as follows:
$ cat /proc/iomem 30000000-37ffffff : 38000000-3fffffff :
Sometimes, garbage may appear after the colon.
In very rare cases, if no NULL-terminator is found in memory, the system might crash because the string iterator will overrun which can lead to access of unmapped memory above the stack.
Thus, fix this by replacing outbound_name with the name of the previously requested resource. With the changes applied, the output will be as follows:
$ cat /proc/iomem 30000000-37ffffff : memory2 38000000-3fffffff : memory3
In the Linux kernel, the following vulnerability has been resolved:
net: let net.core.dev_weight always be non-zero
The 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/0x130 CPU: 18 UID: 0 PID: 5462 Comm: ping Kdump: loaded Not tainted 6.13.0-rc7+ RIP: 0010:__list_add_valid_or_report+0xf3/0x130 Call Trace: ? __warn+0xcd/0x250 ? __list_add_valid_or_report+0xf3/0x130 enqueue_to_backlog+0x923/0x1070 netif_rx_internal+0x92/0x2b0 __netif_rx+0x15/0x170 loopback_xmit+0x2ef/0x450 dev_hard_start_xmit+0x103/0x490 __dev_queue_xmit+0xeac/0x1950 ip_finish_output2+0x6cc/0x1620 ip_output+0x161/0x270 ip_push_pending_frames+0x155/0x1a0 raw_sendmsg+0xe13/0x1550 __sys_sendto+0x3bf/0x4e0 __x64_sys_sendto+0xdc/0x1b0 do_syscall_64+0x5b/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e
The reproduction command is as follows: sysctl -w net.core.dev_weight=0 ping 127.0.0.1
This is because when the napi's weight is set to 0, process_backlog() may return 0 and clear the NAPI_STATE_SCHED bit of napi->state, causing this napi 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() can be 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 is not namespaced).(CVE-2025-21806)
In the Linux kernel, the following vulnerability has been resolved:
net: xdp: Disallow attaching device-bound programs in generic mode
Device-bound programs are used to support RX metadata kfuncs. These kfuncs are driver-specific and rely on the driver context to read the metadata. This means they can't work in generic XDP mode. However, there is no check to disallow such programs from being attached in generic mode, in which case the metadata kfuncs will be called in an invalid context, leading to crashes.
Fix this by adding a check to disallow attaching device-bound programs in generic mode.(CVE-2025-21808)
In the Linux kernel, the following vulnerability has been resolved:
driver core: class: Fix wild pointer dereferences in API class_dev_iter_next()
There are a potential wild pointer dereferences issue regarding APIs class_dev_iter_(init|next|exit)(), as explained by below typical usage:
// All members of @iter are wild pointers. struct class_dev_iter iter;
// class_dev_iter_init(@iter, @class, ...) checks parameter @class for // potential class_to_subsys() error, and it returns void type and does // not initialize its output parameter @iter, so caller can not detect // the error and continues to invoke class_dev_iter_next(@iter) even if // @iter still contains wild pointers. class_dev_iter_init(&iter, ...);
// Dereference these wild pointers in @iter here once suffer the error. while (dev = class_dev_iter_next(&iter)) { ... };
// Also dereference these wild pointers here. class_dev_iter_exit(&iter);
Actually, all callers of these APIs have such usage pattern in kernel tree. Fix by: - Initialize output parameter @iter by memset() in class_dev_iter_init() and give callers prompt by pr_crit() for the error. - Check if @iter is valid in class_dev_iter_next().(CVE-2025-21810)
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: protect access to buffers with no active references
nilfs_lookup_dirty_data_buffers(), which iterates through the buffers attached to dirty data folios/pages, accesses the attached buffers without locking the folios/pages.
For data cache, nilfs_clear_folio_dirty() may be called asynchronously when the file system degenerates to read only, so nilfs_lookup_dirty_data_buffers() still has the potential to cause use after free issues when buffers lose the protection of their dirty state midway due to this asynchronous clearing and are unintentionally freed by try_to_free_buffers().
Eliminate this race issue by adjusting the lock section in this function.(CVE-2025-21811)
In the Linux kernel, the following vulnerability has been resolved:
ax25: rcu protect dev->ax25_ptr
syzbot found a lockdep issue [1].
We should remove ax25 RTNL dependency in ax25_setsockopt()
This should also fix a variety of possible UAF in ax25.
[1]
WARNING: possible circular locking dependency detected 6.13.0-rc3-syzkaller-00762-g9268abe611b0 #0 Not tainted
syz.5.1818/12806 is trying to acquire lock: ffffffff8fcb3988 (rtnl_mutex){+.+.}-{4:4}, at: ax25_setsockopt+0xa55/0xe90 net/ax25/af_ax25.c:680
but task is already holding lock: ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1618 [inline] ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: ax25_setsockopt+0x209/0xe90 net/ax25/af_ax25.c:574
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (sk_lock-AF_AX25){+.+.}-{0:0}: lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5849 lock_sock_nested+0x48/0x100 net/core/sock.c:3642 lock_sock include/net/sock.h:1618 [inline] ax25_kill_by_device net/ax25/af_ax25.c:101 [inline] ax25_device_event+0x24d/0x580 net/ax25/af_ax25.c:146 notifier_call_chain+0x1a5/0x3f0 kernel/notifier.c:85 __dev_notify_flags+0x207/0x400 dev_change_flags+0xf0/0x1a0 net/core/dev.c:9026 dev_ifsioc+0x7c8/0xe70 net/core/dev_ioctl.c:563 dev_ioctl+0x719/0x1340 net/core/dev_ioctl.c:820 sock_do_ioctl+0x240/0x460 net/socket.c:1234 sock_ioctl+0x626/0x8e0 net/socket.c:1339 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:906 [inline] __se_sys_ioctl+0xf5/0x170 fs/ioctl.c:892 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f
-> #0 (rtnl_mutex){+.+.}-{4:4}: check_prev_add kernel/locking/lockdep.c:3161 [inline] check_prevs_add kernel/locking/lockdep.c:3280 [inline] validate_chain+0x18ef/0x5920 kernel/locking/lockdep.c:3904 __lock_acquire+0x1397/0x2100 kernel/locking/lockdep.c:5226 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5849 __mutex_lock_common kernel/locking/mutex.c:585 [inline] __mutex_lock+0x1ac/0xee0 kernel/locking/mutex.c:735 ax25_setsockopt+0xa55/0xe90 net/ax25/af_ax25.c:680 do_sock_setsockopt+0x3af/0x720 net/socket.c:2324 __sys_setsockopt net/socket.c:2349 [inline] __do_sys_setsockopt net/socket.c:2355 [inline] __se_sys_setsockopt net/socket.c:2352 [inline] __x64_sys_setsockopt+0x1ee/0x280 net/socket.c:2352 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(sk_lock-AF_AX25); lock(rtnl_mutex); lock(sk_lock-AF_AX25); lock(rtnl_mutex);
*** DEADLOCK ***
1 lock held by syz.5.1818/12806: #0: ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1618 [inline] #0: ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: ax25_setsockopt+0x209/0xe90 net/ax25/af_ax25.c:574
stack backtrace: CPU: 1 UID: 0 PID: 12806 Comm: syz.5.1818 Not tainted 6.13.0-rc3-syzkaller-00762-g9268abe611b0 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_circular_bug+0x13a/0x1b0 kernel/locking/lockdep.c:2074 check_noncircular+0x36a/0x4a0 kernel/locking/lockdep.c:2206 check_prev_add kernel/locking/lockdep.c:3161 [inline] check_prevs_add kernel/lockin ---truncated---(CVE-2025-21812)
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: don't flush non-uploaded STAs
If STA state is pre-moved to AUTHORIZED (such as in IBSS scenarios) and insertion fails, the station is freed. In this case, the driver never knew about the station, so trying to flush it is unexpected and may crash.
Check if the sta was uploaded to the driver before and fix this.(CVE-2025-21828)
In the Linux kernel, the following vulnerability has been resolved:
bpf: avoid holding freeze_mutex during mmap operation
We use map->freeze_mutex to prevent races between map_freeze() and memory mapping BPF map contents with writable permissions. The way we naively do this means we'll hold freeze_mutex for entire duration of all the mm and VMA manipulations, which is completely unnecessary. This can potentially also lead to deadlocks, as reported by syzbot in [0].
So, instead, hold freeze_mutex only during writeability checks, bump (proactively) "write active" count for the map, unlock the mutex and proceed with mmap logic. And only if something went wrong during mmap logic, then undo that "write active" counter increment.
[0] https://lore.kernel.org/bpf/678dcbc9.050a0220.303755.0066.GAE@google.com/(CVE-2025-21853)
| URL | Type | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-6.6.0-84.0.0.78.oe2403.aarch64.rpm",
"bpftool-debuginfo-6.6.0-84.0.0.78.oe2403.aarch64.rpm",
"kernel-6.6.0-84.0.0.78.oe2403.aarch64.rpm",
"kernel-debuginfo-6.6.0-84.0.0.78.oe2403.aarch64.rpm",
"kernel-debugsource-6.6.0-84.0.0.78.oe2403.aarch64.rpm",
"kernel-devel-6.6.0-84.0.0.78.oe2403.aarch64.rpm",
"kernel-headers-6.6.0-84.0.0.78.oe2403.aarch64.rpm",
"kernel-source-6.6.0-84.0.0.78.oe2403.aarch64.rpm",
"kernel-tools-6.6.0-84.0.0.78.oe2403.aarch64.rpm",
"kernel-tools-debuginfo-6.6.0-84.0.0.78.oe2403.aarch64.rpm",
"kernel-tools-devel-6.6.0-84.0.0.78.oe2403.aarch64.rpm",
"perf-6.6.0-84.0.0.78.oe2403.aarch64.rpm",
"perf-debuginfo-6.6.0-84.0.0.78.oe2403.aarch64.rpm",
"python3-perf-6.6.0-84.0.0.78.oe2403.aarch64.rpm",
"python3-perf-debuginfo-6.6.0-84.0.0.78.oe2403.aarch64.rpm"
],
"src": [
"kernel-6.6.0-84.0.0.78.oe2403.src.rpm"
],
"x86_64": [
"bpftool-6.6.0-84.0.0.78.oe2403.x86_64.rpm",
"bpftool-debuginfo-6.6.0-84.0.0.78.oe2403.x86_64.rpm",
"kernel-6.6.0-84.0.0.78.oe2403.x86_64.rpm",
"kernel-debuginfo-6.6.0-84.0.0.78.oe2403.x86_64.rpm",
"kernel-debugsource-6.6.0-84.0.0.78.oe2403.x86_64.rpm",
"kernel-devel-6.6.0-84.0.0.78.oe2403.x86_64.rpm",
"kernel-headers-6.6.0-84.0.0.78.oe2403.x86_64.rpm",
"kernel-source-6.6.0-84.0.0.78.oe2403.x86_64.rpm",
"kernel-tools-6.6.0-84.0.0.78.oe2403.x86_64.rpm",
"kernel-tools-debuginfo-6.6.0-84.0.0.78.oe2403.x86_64.rpm",
"kernel-tools-devel-6.6.0-84.0.0.78.oe2403.x86_64.rpm",
"perf-6.6.0-84.0.0.78.oe2403.x86_64.rpm",
"perf-debuginfo-6.6.0-84.0.0.78.oe2403.x86_64.rpm",
"python3-perf-6.6.0-84.0.0.78.oe2403.x86_64.rpm",
"python3-perf-debuginfo-6.6.0-84.0.0.78.oe2403.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:24.03-LTS",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.6.0-84.0.0.78.oe2403"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndma-debug: fix a possible deadlock on radix_lock\n\nradix_lock() shouldn\u0026apos;t be held while holding dma_hash_entry[idx].lock\notherwise, there\u0026apos;s a possible deadlock scenario when\ndma debug API is called holding rq_lock():\n\nCPU0 CPU1 CPU2\ndma_free_attrs()\ncheck_unmap() add_dma_entry() __schedule() //out\n (A) rq_lock()\nget_hash_bucket()\n(A) dma_entry_hash\n check_sync()\n (A) radix_lock() (W) dma_entry_hash\ndma_entry_free()\n(W) radix_lock()\n // CPU2\u0026apos;s one\n (W) rq_lock()\n\nCPU1 situation can happen when it extending radix tree and\nit tries to wake up kswapd via wake_all_kswapd().\n\nCPU2 situation can happen while perf_event_task_sched_out()\n(i.e. dma sync operation is called while deleting perf_event using\n etm and etr tmc which are Arm Coresight hwtracing driver backends).\n\nTo remove this possible situation, call dma_entry_free() after\nput_hash_bucket() in check_unmap().(CVE-2024-47143)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndlm: fix possible lkb_resource null dereference\n\nThis patch fixes a possible null pointer dereference when this function is\ncalled from request_lock() as lkb-\u0026gt;lkb_resource is not assigned yet,\nonly after validate_lock_args() by calling attach_lkb(). Another issue\nis that a resource name could be a non printable bytearray and we cannot\nassume to be ASCII coded.\n\nThe log functionality is probably never being hit when DLM is used in\nnormal way and no debug logging is enabled. The null pointer dereference\ncan only occur on a new created lkb that does not have the resource\nassigned yet, it probably never hits the null pointer dereference but we\nshould be sure that other changes might not change this behaviour and we\nactually can hit the mentioned null pointer dereference.\n\nIn this patch we just drop the printout of the resource name, the lkb id\nis enough to make a possible connection to a resource name if this\nexists.(CVE-2024-47809)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbcache: revert replacing IS_ERR_OR_NULL with IS_ERR again\n\nCommit 028ddcac477b (\u0026quot;bcache: Remove unnecessary NULL point check in\nnode allocations\u0026quot;) leads a NULL pointer deference in cache_set_flush().\n\n1721 if (!IS_ERR_OR_NULL(c-\u0026gt;root))\n1722 list_add(\u0026amp;c-\u0026gt;root-\u0026gt;list, \u0026amp;c-\u0026gt;btree_cache);\n\n\u0026gt;From the above code in cache_set_flush(), if previous registration code\nfails before allocating c-\u0026gt;root, it is possible c-\u0026gt;root is NULL as what\nit is initialized. __bch_btree_node_alloc() never returns NULL but\nc-\u0026gt;root is possible to be NULL at above line 1721.\n\nThis patch replaces IS_ERR() by IS_ERR_OR_NULL() to fix this.(CVE-2024-48881)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvfio/pci: Properly hide first-in-list PCIe extended capability\n\nThere are cases where a PCIe extended capability should be hidden from\nthe user. For example, an unknown capability (i.e., capability with ID\ngreater than PCI_EXT_CAP_ID_MAX) or a capability that is intentionally\nchosen to be hidden from the user.\n\nHiding a capability is done by virtualizing and modifying the \u0026apos;Next\nCapability Offset\u0026apos; field of the previous capability so it points to the\ncapability after the one that should be hidden.\n\nThe special case where the first capability in the list should be hidden\nis handled differently because there is no previous capability that can\nbe modified. In this case, the capability ID and version are zeroed\nwhile leaving the next pointer intact. This hides the capability and\nleaves an anchor for the rest of the capability list.\n\nHowever, today, hiding the first capability in the list is not done\nproperly if the capability is unknown, as struct\nvfio_pci_core_device-\u0026gt;pci_config_map is set to the capability ID during\ninitialization but the capability ID is not properly checked later when\nused in vfio_config_do_rw(). This leads to the following warning [1] and\nto an out-of-bounds access to ecap_perms array.\n\nFix it by checking cap_id in vfio_config_do_rw(), and if it is greater\nthan PCI_EXT_CAP_ID_MAX, use an alternative struct perm_bits for direct\nread only access instead of the ecap_perms array.\n\nNote that this is safe since the above is the only case where cap_id can\nexceed PCI_EXT_CAP_ID_MAX (except for the special capabilities, which\nare already checked before).\n\n[1]\n\nWARNING: CPU: 118 PID: 5329 at drivers/vfio/pci/vfio_pci_config.c:1900 vfio_pci_config_rw+0x395/0x430 [vfio_pci_core]\nCPU: 118 UID: 0 PID: 5329 Comm: simx-qemu-syste Not tainted 6.12.0+ #1\n(snip)\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? show_regs+0x69/0x80\n ? __warn+0x8d/0x140\n ? vfio_pci_config_rw+0x395/0x430 [vfio_pci_core]\n ? report_bug+0x18f/0x1a0\n ? handle_bug+0x63/0xa0\n ? exc_invalid_op+0x19/0x70\n ? asm_exc_invalid_op+0x1b/0x20\n ? vfio_pci_config_rw+0x395/0x430 [vfio_pci_core]\n ? vfio_pci_config_rw+0x244/0x430 [vfio_pci_core]\n vfio_pci_rw+0x101/0x1b0 [vfio_pci_core]\n vfio_pci_core_read+0x1d/0x30 [vfio_pci_core]\n vfio_device_fops_read+0x27/0x40 [vfio]\n vfs_read+0xbd/0x340\n ? vfio_device_fops_unl_ioctl+0xbb/0x740 [vfio]\n ? __rseq_handle_notify_resume+0xa4/0x4b0\n __x64_sys_pread64+0x96/0xc0\n x64_sys_call+0x1c3d/0x20d0\n do_syscall_64+0x4d/0x120\n entry_SYSCALL_64_after_hwframe+0x76/0x7e(CVE-2024-53214)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: af_can: do not leave a dangling sk pointer in can_create()\n\nOn error can_create() frees the allocated sk object, but sock_init_data()\nhas already attached it to the provided sock object. This will leave a\ndangling sk pointer in the sock object and may cause use-after-free later.(CVE-2024-56603)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\naf_packet: avoid erroring out after sock_init_data() in packet_create()\n\nAfter sock_init_data() the allocated sk object is attached to the provided\nsock object. On error, packet_create() frees the sk object leaving the\ndangling pointer in the sock object on return. Some other code may try\nto use this pointer and cause use-after-free.(CVE-2024-56606)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: ipset: Hold module reference while requesting a module\n\nUser space may unload ip_set.ko while it is itself requesting a set type\nbackend module, leading to a kernel crash. The race condition may be\nprovoked by inserting an mdelay() right after the nfnl_unlock() call.(CVE-2024-56637)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntipc: Fix use-after-free of kernel socket in cleanup_bearer().\n\nsyzkaller reported a use-after-free of UDP kernel socket\nin cleanup_bearer() without repro. [0][1]\n\nWhen bearer_disable() calls tipc_udp_disable(), cleanup\nof the UDP kernel socket is deferred by work calling\ncleanup_bearer().\n\ntipc_exit_net() waits for such works to finish by checking\ntipc_net(net)-\u0026gt;wq_count. However, the work decrements the\ncount too early before releasing the kernel socket,\nunblocking cleanup_net() and resulting in use-after-free.\n\nLet\u0026apos;s move the decrement after releasing the socket in\ncleanup_bearer().\n\n[0]:\nref_tracker: net notrefcnt@000000009b3d1faf has 1/1 users at\n sk_alloc+0x438/0x608\n inet_create+0x4c8/0xcb0\n __sock_create+0x350/0x6b8\n sock_create_kern+0x58/0x78\n udp_sock_create4+0x68/0x398\n udp_sock_create+0x88/0xc8\n tipc_udp_enable+0x5e8/0x848\n __tipc_nl_bearer_enable+0x84c/0xed8\n tipc_nl_bearer_enable+0x38/0x60\n genl_family_rcv_msg_doit+0x170/0x248\n genl_rcv_msg+0x400/0x5b0\n netlink_rcv_skb+0x1dc/0x398\n genl_rcv+0x44/0x68\n netlink_unicast+0x678/0x8b0\n netlink_sendmsg+0x5e4/0x898\n ____sys_sendmsg+0x500/0x830\n\n[1]:\nBUG: KMSAN: use-after-free in udp_hashslot include/net/udp.h:85 [inline]\nBUG: KMSAN: use-after-free in udp_lib_unhash+0x3b8/0x930 net/ipv4/udp.c:1979\n udp_hashslot include/net/udp.h:85 [inline]\n udp_lib_unhash+0x3b8/0x930 net/ipv4/udp.c:1979\n sk_common_release+0xaf/0x3f0 net/core/sock.c:3820\n inet_release+0x1e0/0x260 net/ipv4/af_inet.c:437\n inet6_release+0x6f/0xd0 net/ipv6/af_inet6.c:489\n __sock_release net/socket.c:658 [inline]\n sock_release+0xa0/0x210 net/socket.c:686\n cleanup_bearer+0x42d/0x4c0 net/tipc/udp_media.c:819\n process_one_work kernel/workqueue.c:3229 [inline]\n process_scheduled_works+0xcaf/0x1c90 kernel/workqueue.c:3310\n worker_thread+0xf6c/0x1510 kernel/workqueue.c:3391\n kthread+0x531/0x6b0 kernel/kthread.c:389\n ret_from_fork+0x60/0x80 arch/x86/kernel/process.c:147\n ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:244\n\nUninit was created at:\n slab_free_hook mm/slub.c:2269 [inline]\n slab_free mm/slub.c:4580 [inline]\n kmem_cache_free+0x207/0xc40 mm/slub.c:4682\n net_free net/core/net_namespace.c:454 [inline]\n cleanup_net+0x16f2/0x19d0 net/core/net_namespace.c:647\n process_one_work kernel/workqueue.c:3229 [inline]\n process_scheduled_works+0xcaf/0x1c90 kernel/workqueue.c:3310\n worker_thread+0xf6c/0x1510 kernel/workqueue.c:3391\n kthread+0x531/0x6b0 kernel/kthread.c:389\n ret_from_fork+0x60/0x80 arch/x86/kernel/process.c:147\n ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:244\n\nCPU: 0 UID: 0 PID: 54 Comm: kworker/0:2 Not tainted 6.12.0-rc1-00131-gf66ebf37d69c #7 91723d6f74857f70725e1583cba3cf4adc716cfa\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014\nWorkqueue: events cleanup_bearer(CVE-2024-56642)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: hsr: avoid potential out-of-bound access in fill_frame_info()\n\nsyzbot is able to feed a packet with 14 bytes, pretending\nit is a vlan one.\n\nSince fill_frame_info() is relying on skb-\u0026gt;mac_len already,\nextend the check to cover this case.\n\nBUG: KMSAN: uninit-value in fill_frame_info net/hsr/hsr_forward.c:709 [inline]\n BUG: KMSAN: uninit-value in hsr_forward_skb+0x9ee/0x3b10 net/hsr/hsr_forward.c:724\n fill_frame_info net/hsr/hsr_forward.c:709 [inline]\n hsr_forward_skb+0x9ee/0x3b10 net/hsr/hsr_forward.c:724\n hsr_dev_xmit+0x2f0/0x350 net/hsr/hsr_device.c:235\n __netdev_start_xmit include/linux/netdevice.h:5002 [inline]\n netdev_start_xmit include/linux/netdevice.h:5011 [inline]\n xmit_one net/core/dev.c:3590 [inline]\n dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3606\n __dev_queue_xmit+0x366a/0x57d0 net/core/dev.c:4434\n dev_queue_xmit include/linux/netdevice.h:3168 [inline]\n packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276\n packet_snd net/packet/af_packet.c:3146 [inline]\n packet_sendmsg+0x91ae/0xa6f0 net/packet/af_packet.c:3178\n sock_sendmsg_nosec net/socket.c:711 [inline]\n __sock_sendmsg+0x30f/0x380 net/socket.c:726\n __sys_sendto+0x594/0x750 net/socket.c:2197\n __do_sys_sendto net/socket.c:2204 [inline]\n __se_sys_sendto net/socket.c:2200 [inline]\n __x64_sys_sendto+0x125/0x1d0 net/socket.c:2200\n x64_sys_call+0x346a/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:45\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nUninit was created at:\n slab_post_alloc_hook mm/slub.c:4091 [inline]\n slab_alloc_node mm/slub.c:4134 [inline]\n kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4186\n kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587\n __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678\n alloc_skb include/linux/skbuff.h:1323 [inline]\n alloc_skb_with_frags+0xc8/0xd00 net/core/skbuff.c:6612\n sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2881\n packet_alloc_skb net/packet/af_packet.c:2995 [inline]\n packet_snd net/packet/af_packet.c:3089 [inline]\n packet_sendmsg+0x74c6/0xa6f0 net/packet/af_packet.c:3178\n sock_sendmsg_nosec net/socket.c:711 [inline]\n __sock_sendmsg+0x30f/0x380 net/socket.c:726\n __sys_sendto+0x594/0x750 net/socket.c:2197\n __do_sys_sendto net/socket.c:2204 [inline]\n __se_sys_sendto net/socket.c:2200 [inline]\n __x64_sys_sendto+0x125/0x1d0 net/socket.c:2200\n x64_sys_call+0x346a/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:45\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2024-56648)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: gadget: u_serial: Fix the issue that gs_start_io crashed due to accessing null pointer\n\nConsidering that in some extreme cases,\nwhen u_serial driver is accessed by multiple threads,\nThread A is executing the open operation and calling the gs_open,\nThread B is executing the disconnect operation and calling the\ngserial_disconnect function,The port-\u0026gt;port_usb pointer will be set to NULL.\n\nE.g.\n Thread A Thread B\n gs_open() gadget_unbind_driver()\n gs_start_io() composite_disconnect()\n gs_start_rx() gserial_disconnect()\n ... ...\n spin_unlock(\u0026amp;port-\u0026gt;port_lock)\n status = usb_ep_queue() spin_lock(\u0026amp;port-\u0026gt;port_lock)\n spin_lock(\u0026amp;port-\u0026gt;port_lock) port-\u0026gt;port_usb = NULL\n gs_free_requests(port-\u0026gt;port_usb-\u0026gt;in) spin_unlock(\u0026amp;port-\u0026gt;port_lock)\n Crash\n\nThis causes thread A to access a null pointer (port-\u0026gt;port_usb is null)\nwhen calling the gs_free_requests function, causing a crash.\n\nIf port_usb is NULL, the release request will be skipped as it\nwill be done by gserial_disconnect.\n\nSo add a null pointer check to gs_start_io before attempting\nto access the value of the pointer port-\u0026gt;port_usb.\n\nCall trace:\n gs_start_io+0x164/0x25c\n gs_open+0x108/0x13c\n tty_open+0x314/0x638\n chrdev_open+0x1b8/0x258\n do_dentry_open+0x2c4/0x700\n vfs_open+0x2c/0x3c\n path_openat+0xa64/0xc60\n do_filp_open+0xb8/0x164\n do_sys_openat2+0x84/0xf0\n __arm64_sys_openat+0x70/0x9c\n invoke_syscall+0x58/0x114\n el0_svc_common+0x80/0xe0\n do_el0_svc+0x1c/0x28\n el0_svc+0x38/0x68(CVE-2024-56670)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\n9p/xen: fix release of IRQ\n\nKernel logs indicate an IRQ was double-freed.\n\nPass correct device ID during IRQ release.\n\n[Dominique: remove confusing variable reset to 0](CVE-2024-56704)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nft_socket: remove WARN_ON_ONCE on maximum cgroup level\n\ncgroup maximum depth is INT_MAX by default, there is a cgroup toggle to\nrestrict this maximum depth to a more reasonable value not to harm\nperformance. Remove unnecessary WARN_ON_ONCE which is reachable from\nuserspace.(CVE-2024-56783)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nMIPS: Loongson64: DTS: Really fix PCIe port nodes for ls7a\n\nFix the dtc warnings:\n\n arch/mips/boot/dts/loongson/ls7a-pch.dtsi:68.16-416.5: Warning (interrupt_provider): /bus@10000000/pci@1a000000: \u0026apos;#interrupt-cells\u0026apos; found, but node is not an interrupt provider\n arch/mips/boot/dts/loongson/ls7a-pch.dtsi:68.16-416.5: Warning (interrupt_provider): /bus@10000000/pci@1a000000: \u0026apos;#interrupt-cells\u0026apos; found, but node is not an interrupt provider\n arch/mips/boot/dts/loongson/loongson64g_4core_ls7a.dtb: Warning (interrupt_map): Failed prerequisite \u0026apos;interrupt_provider\u0026apos;\n\nAnd a runtime warning introduced in commit 045b14ca5c36 (\u0026quot;of: WARN on\ndeprecated #address-cells/#size-cells handling\u0026quot;):\n\n WARNING: CPU: 0 PID: 1 at drivers/of/base.c:106 of_bus_n_addr_cells+0x9c/0xe0\n Missing \u0026apos;#address-cells\u0026apos; in /bus@10000000/pci@1a000000/pci_bridge@9,0\n\nThe fix is similar to commit d89a415ff8d5 (\u0026quot;MIPS: Loongson64: DTS: Fix PCIe\nport nodes for ls7a\u0026quot;), which has fixed the issue for ls2k (despite its\nsubject mentions ls7a).(CVE-2024-56785)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ns390/entry: Mark IRQ entries to fix stack depot warnings\n\nThe stack depot filters out everything outside of the top interrupt\ncontext as an uninteresting or irrelevant part of the stack traces. This\nhelps with stack trace de-duplication, avoiding an explosion of saved\nstack traces that share the same IRQ context code path but originate\nfrom different randomly interrupted points, eventually exhausting the\nstack depot.\n\nFiltering uses in_irqentry_text() to identify functions within the\n.irqentry.text and .softirqentry.text sections, which then become the\nlast stack trace entries being saved.\n\nWhile __do_softirq() is placed into the .softirqentry.text section by\ncommon code, populating .irqentry.text is architecture-specific.\n\nCurrently, the .irqentry.text section on s390 is empty, which prevents\nstack depot filtering and de-duplication and could result in warnings\nlike:\n\nStack depot reached limit capacity\nWARNING: CPU: 0 PID: 286113 at lib/stackdepot.c:252 depot_alloc_stack+0x39a/0x3c8\n\nwith PREEMPT and KASAN enabled.\n\nFix this by moving the IO/EXT interrupt handlers from .kprobes.text into\nthe .irqentry.text section and updating the kprobes blacklist to include\nthe .irqentry.text section.\n\nThis is done only for asynchronous interrupts and explicitly not for\nprogram checks, which are synchronous and where the context beyond the\nprogram check is important to preserve. Despite machine checks being\nsomewhat in between, they are extremely rare, and preserving context\nwhen possible is also of value.\n\nSVCs and Restart Interrupts are not relevant, one being always at the\nboundary to user space and the other being a one-time thing.\n\nIRQ entries filtering is also optionally used in ftrace function graph,\nwhere the same logic applies.(CVE-2024-57838)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/dp_mst: Fix resetting msg rx state after topology removal\n\nIf the MST topology is removed during the reception of an MST down reply\nor MST up request sideband message, the\ndrm_dp_mst_topology_mgr::up_req_recv/down_rep_recv states could be reset\nfrom one thread via drm_dp_mst_topology_mgr_set_mst(false), racing with\nthe reading/parsing of the message from another thread via\ndrm_dp_mst_handle_down_rep() or drm_dp_mst_handle_up_req(). The race is\npossible since the reader/parser doesn\u0026apos;t hold any lock while accessing\nthe reception state. This in turn can lead to a memory corruption in the\nreader/parser as described by commit bd2fccac61b4 (\u0026quot;drm/dp_mst: Fix MST\nsideband message body length check\u0026quot;).\n\nFix the above by resetting the message reception state if needed before\nreading/parsing a message. Another solution would be to hold the\ndrm_dp_mst_topology_mgr::lock for the whole duration of the message\nreception/parsing in drm_dp_mst_handle_down_rep() and\ndrm_dp_mst_handle_up_req(), however this would require a bigger change.\nSince the fix is also needed for stable, opting for the simpler solution\nin this patch.(CVE-2024-57876)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nrdma/cxgb4: Prevent potential integer overflow on 32bit\n\nThe \u0026quot;gl-\u0026gt;tot_len\u0026quot; variable is controlled by the user. It comes from\nprocess_responses(). On 32bit systems, the \u0026quot;gl-\u0026gt;tot_len + sizeof(struct\ncpl_pass_accept_req) + sizeof(struct rss_header)\u0026quot; addition could have an\ninteger wrapping bug. Use size_add() to prevent this.(CVE-2024-57973)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: imx-jpeg: Fix potential error pointer dereference in detach_pm()\n\nThe proble is on the first line:\n\n\tif (jpeg-\u0026gt;pd_dev[i] \u0026amp;\u0026amp; !pm_runtime_suspended(jpeg-\u0026gt;pd_dev[i]))\n\nIf jpeg-\u0026gt;pd_dev[i] is an error pointer, then passing it to\npm_runtime_suspended() will lead to an Oops. The other conditions\ncheck for both error pointers and NULL, but it would be more clear to\nuse the IS_ERR_OR_NULL() check for that.(CVE-2024-57978)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: core: Fix assumption that Resolution Multipliers must be in Logical Collections\n\nA report in 2019 by the syzbot fuzzer was found to be connected to two\nerrors in the HID core associated with Resolution Multipliers. One of\nthe errors was fixed by commit ea427a222d8b (\u0026quot;HID: core: Fix deadloop\nin hid_apply_multiplier.\u0026quot;), but the other has not been fixed.\n\nThis error arises because hid_apply_multipler() assumes that every\nResolution Multiplier control is contained in a Logical Collection,\ni.e., there\u0026apos;s no way the routine can ever set multiplier_collection to\nNULL. This is in spite of the fact that the function starts with a\nbig comment saying:\n\n\t * \u0026quot;The Resolution Multiplier control must be contained in the same\n\t * Logical Collection as the control(s) to which it is to be applied.\n\t ...\n\t * If no Logical Collection is\n\t * defined, the Resolution Multiplier is associated with all\n\t * controls in the report.\u0026quot;\n\t * HID Usage Table, v1.12, Section 4.3.1, p30\n\t *\n\t * Thus, search from the current collection upwards until we find a\n\t * logical collection...\n\nThe comment and the code overlook the possibility that none of the\ncollections found may be a Logical Collection.\n\nThe fix is to set the multiplier_collection pointer to NULL if the\ncollection found isn\u0026apos;t a Logical Collection.(CVE-2024-57986)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: hid-thrustmaster: Fix warning in thrustmaster_probe by adding endpoint check\n\nsyzbot has found a type mismatch between a USB pipe and the transfer\nendpoint, which is triggered by the hid-thrustmaster driver[1].\nThere is a number of similar, already fixed issues [2].\nIn this case as in others, implementing check for endpoint type fixes the issue.\n\n[1] https://syzkaller.appspot.com/bug?extid=040e8b3db6a96908d470\n[2] https://syzkaller.appspot.com/bug?extid=348331f63b034f89b622(CVE-2024-57993)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: wcn36xx: fix channel survey memory allocation size\n\nKASAN reported a memory allocation issue in wcn-\u0026gt;chan_survey\ndue to incorrect size calculation.\nThis commit uses kcalloc to allocate memory for wcn-\u0026gt;chan_survey,\nensuring proper initialization and preventing the use of uninitialized\nvalues when there are no frames on the channel.(CVE-2024-57997)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nOPP: add index check to assert to avoid buffer overflow in _read_freq()\n\nPass the freq index to the assert function to make sure\nwe do not read a freq out of the opp-\u0026gt;rates[] table when called\nfrom the indexed variants:\ndev_pm_opp_find_freq_exact_indexed() or\ndev_pm_opp_find_freq_ceil/floor_indexed().\n\nAdd a secondary parameter to the assert function, unused\nfor assert_single_clk() then add assert_clk_index() which\nwill check for the clock index when called from the _indexed()\nfind functions.(CVE-2024-57998)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nPCI: dwc: ep: Prevent changing BAR size/flags in pci_epc_set_bar()\n\nIn commit 4284c88fff0e (\u0026quot;PCI: designware-ep: Allow pci_epc_set_bar() update\ninbound map address\u0026quot;) set_bar() was modified to support dynamically\nchanging the backing physical address of a BAR that was already configured.\n\nThis means that set_bar() can be called twice, without ever calling\nclear_bar() (as calling clear_bar() would clear the BAR\u0026apos;s PCI address\nassigned by the host).\n\nThis can only be done if the new BAR size/flags does not differ from the\nexisting BAR configuration. Add these missing checks.\n\nIf we allow set_bar() to set e.g. a new BAR size that differs from the\nexisting BAR size, the new address translation range will be smaller than\nthe BAR size already determined by the host, which would mean that a read\npast the new BAR size would pass the iATU untranslated, which could allow\nthe host to read memory not belonging to the new struct pci_epf_bar.\n\nWhile at it, add comments which clarifies the support for dynamically\nchanging the physical address of a BAR. (Which was also missing.)(CVE-2024-58006)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmemory: tegra20-emc: fix an OF node reference bug in tegra_emc_find_node_by_ram_code()\n\nAs of_find_node_by_name() release the reference of the argument device\nnode, tegra_emc_find_node_by_ram_code() releases some device nodes while\nstill in use, resulting in possible UAFs. According to the bindings and\nthe in-tree DTS files, the \u0026quot;emc-tables\u0026quot; node is always device\u0026apos;s child\nnode with the property \u0026quot;nvidia,use-ram-code\u0026quot;, and the \u0026quot;lpddr2\u0026quot; node is a\nchild of the \u0026quot;emc-tables\u0026quot; node. Thus utilize the\nfor_each_child_of_node() macro and of_get_child_by_name() instead of\nof_find_node_by_name() to simplify the code.\n\nThis bug was found by an experimental verification tool that I am\ndeveloping.\n\n[krzysztof: applied v1, adjust the commit msg to incorporate v2 parts](CVE-2024-58034)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipmi: ipmb: Add check devm_kasprintf() returned value\n\ndevm_kasprintf() can return a NULL pointer on failure but this\nreturned value is not checked.(CVE-2024-58051)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu: Fix potential NULL pointer dereference in atomctrl_get_smc_sclk_range_table\n\nThe function atomctrl_get_smc_sclk_range_table() does not check the return\nvalue of smu_atom_get_data_table(). If smu_atom_get_data_table() fails to\nretrieve SMU_Info table, it returns NULL which is later dereferenced.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.\n\nIn practice this should never happen as this code only gets called\non polaris chips and the vbios data table will always be present on\nthose chips.(CVE-2024-58052)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nrxrpc: Fix handling of received connection abort\n\nFix the handling of a connection abort that we\u0026apos;ve received. Though the\nabort is at the connection level, it needs propagating to the calls on that\nconnection. Whilst the propagation bit is performed, the calls aren\u0026apos;t then\nwoken up to go and process their termination, and as no further input is\nforthcoming, they just hang.\n\nAlso add some tracing for the logging of connection aborts.(CVE-2024-58053)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nstaging: media: max96712: fix kernel oops when removing module\n\nThe following kernel oops is thrown when trying to remove the max96712\nmodule:\n\nUnable to handle kernel paging request at virtual address 00007375746174db\nMem abort info:\n ESR = 0x0000000096000004\n EC = 0x25: DABT (current EL), IL = 32 bits\n SET = 0, FnV = 0\n EA = 0, S1PTW = 0\n FSC = 0x04: level 0 translation fault\nData abort info:\n ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000\n CM = 0, WnR = 0, TnD = 0, TagAccess = 0\n GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\nuser pgtable: 4k pages, 48-bit VAs, pgdp=000000010af89000\n[00007375746174db] pgd=0000000000000000, p4d=0000000000000000\nInternal error: Oops: 0000000096000004 [#1] PREEMPT SMP\nModules linked in: crct10dif_ce polyval_ce mxc_jpeg_encdec flexcan\n snd_soc_fsl_sai snd_soc_fsl_asoc_card snd_soc_fsl_micfil dwc_mipi_csi2\n imx_csi_formatter polyval_generic v4l2_jpeg imx_pcm_dma can_dev\n snd_soc_imx_audmux snd_soc_wm8962 snd_soc_imx_card snd_soc_fsl_utils\n max96712(C-) rpmsg_ctrl rpmsg_char pwm_fan fuse\n [last unloaded: imx8_isi]\nCPU: 0 UID: 0 PID: 754 Comm: rmmod\n\t Tainted: G C 6.12.0-rc6-06364-g327fec852c31 #17\nTainted: [C]=CRAP\nHardware name: NXP i.MX95 19X19 board (DT)\npstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : led_put+0x1c/0x40\nlr : v4l2_subdev_put_privacy_led+0x48/0x58\nsp : ffff80008699bbb0\nx29: ffff80008699bbb0 x28: ffff00008ac233c0 x27: 0000000000000000\nx26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000\nx23: ffff000080cf1170 x22: ffff00008b53bd00 x21: ffff8000822ad1c8\nx20: ffff000080ff5c00 x19: ffff00008b53be40 x18: 0000000000000000\nx17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000\nx14: 0000000000000004 x13: ffff0000800f8010 x12: 0000000000000000\nx11: ffff000082acf5c0 x10: ffff000082acf478 x9 : ffff0000800f8010\nx8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff6364626d\nx5 : 8080808000000000 x4 : 0000000000000020 x3 : 00000000553a3dc1\nx2 : ffff00008ac233c0 x1 : ffff00008ac233c0 x0 : ff00737574617473\nCall trace:\n led_put+0x1c/0x40\n v4l2_subdev_put_privacy_led+0x48/0x58\n v4l2_async_unregister_subdev+0x2c/0x1a4\n max96712_remove+0x1c/0x38 [max96712]\n i2c_device_remove+0x2c/0x9c\n device_remove+0x4c/0x80\n device_release_driver_internal+0x1cc/0x228\n driver_detach+0x4c/0x98\n bus_remove_driver+0x6c/0xbc\n driver_unregister+0x30/0x60\n i2c_del_driver+0x54/0x64\n max96712_i2c_driver_exit+0x18/0x1d0 [max96712]\n __arm64_sys_delete_module+0x1a4/0x290\n invoke_syscall+0x48/0x10c\n el0_svc_common.constprop.0+0xc0/0xe0\n do_el0_svc+0x1c/0x28\n el0_svc+0x34/0xd8\n el0t_64_sync_handler+0x120/0x12c\n el0t_64_sync+0x190/0x194\nCode: f9000bf3 aa0003f3 f9402800 f9402000 (f9403400)\n---[ end trace 0000000000000000 ]---\n\nThis happens because in v4l2_i2c_subdev_init(), the i2c_set_cliendata()\nis called again and the data is overwritten to point to sd, instead of\npriv. So, in remove(), the wrong pointer is passed to\nv4l2_async_unregister_subdev(), leading to a crash.(CVE-2024-58054)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nremoteproc: core: Fix ida_free call while not allocated\n\nIn the rproc_alloc() function, on error, put_device(\u0026amp;rproc-\u0026gt;dev) is\ncalled, leading to the call of the rproc_type_release() function.\nAn error can occurs before ida_alloc is called.\n\nIn such case in rproc_type_release(), the condition (rproc-\u0026gt;index \u0026gt;= 0) is\ntrue as rproc-\u0026gt;index has been initialized to 0.\nida_free() is called reporting a warning:\n[ 4.181906] WARNING: CPU: 1 PID: 24 at lib/idr.c:525 ida_free+0x100/0x164\n[ 4.186378] stm32-display-dsi 5a000000.dsi: Fixed dependency cycle(s) with /soc/dsi@5a000000/panel@0\n[ 4.188854] ida_free called for id=0 which is not allocated.\n[ 4.198256] mipi-dsi 5a000000.dsi.0: Fixed dependency cycle(s) with /soc/dsi@5a000000\n[ 4.203556] Modules linked in: panel_orisetech_otm8009a dw_mipi_dsi_stm(+) gpu_sched dw_mipi_dsi stm32_rproc stm32_crc32 stm32_ipcc(+) optee(+)\n[ 4.224307] CPU: 1 UID: 0 PID: 24 Comm: kworker/u10:0 Not tainted 6.12.0 #442\n[ 4.231481] Hardware name: STM32 (Device Tree Support)\n[ 4.236627] Workqueue: events_unbound deferred_probe_work_func\n[ 4.242504] Call trace:\n[ 4.242522] unwind_backtrace from show_stack+0x10/0x14\n[ 4.250218] show_stack from dump_stack_lvl+0x50/0x64\n[ 4.255274] dump_stack_lvl from __warn+0x80/0x12c\n[ 4.260134] __warn from warn_slowpath_fmt+0x114/0x188\n[ 4.265199] warn_slowpath_fmt from ida_free+0x100/0x164\n[ 4.270565] ida_free from rproc_type_release+0x38/0x60\n[ 4.275832] rproc_type_release from device_release+0x30/0xa0\n[ 4.281601] device_release from kobject_put+0xc4/0x294\n[ 4.286762] kobject_put from rproc_alloc.part.0+0x208/0x28c\n[ 4.292430] rproc_alloc.part.0 from devm_rproc_alloc+0x80/0xc4\n[ 4.298393] devm_rproc_alloc from stm32_rproc_probe+0xd0/0x844 [stm32_rproc]\n[ 4.305575] stm32_rproc_probe [stm32_rproc] from platform_probe+0x5c/0xbc\n\nCalling ida_alloc earlier in rproc_alloc ensures that the rproc-\u0026gt;index is\nproperly set.(CVE-2024-58056)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nubifs: skip dumping tnc tree when zroot is null\n\nClearing slab cache will free all znode in memory and make\nc-\u0026gt;zroot.znode = NULL, then dumping tnc tree will access\nc-\u0026gt;zroot.znode which cause null pointer dereference.(CVE-2024-58058)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mac80211: prohibit deactivating all links\n\nIn the internal API this calls this is a WARN_ON, but that\nshould remain since internally we want to know about bugs\nthat may cause this. Prevent deactivating all links in the\ndebugfs write directly.(CVE-2024-58061)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: rtlwifi: fix memory leaks and invalid access at probe error path\n\nDeinitialize at reverse order when probe fails.\n\nWhen init_sw_vars fails, rtl_deinit_core should not be called, specially\nnow that it destroys the rtl_wq workqueue.\n\nAnd call rtl_pci_deinit and deinit_sw_vars, otherwise, memory will be\nleaked.\n\nRemove pci_set_drvdata call as it will already be cleaned up by the core\ndriver code and could lead to memory leaks too. cf. commit 8d450935ae7f\n(\u0026quot;wireless: rtlwifi: remove unnecessary pci_set_drvdata()\u0026quot;) and\ncommit 3d86b93064c7 (\u0026quot;rtlwifi: Fix PCI probe error path orphaned memory\u0026quot;).(CVE-2024-58063)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nOPP: fix dev_pm_opp_find_bw_*() when bandwidth table not initialized\n\nIf a driver calls dev_pm_opp_find_bw_ceil/floor() the retrieve bandwidth\nfrom the OPP table but the bandwidth table was not created because the\ninterconnect properties were missing in the OPP consumer node, the\nkernel will crash with:\n\nUnable to handle kernel NULL pointer dereference at virtual address 0000000000000004\n...\npc : _read_bw+0x8/0x10\nlr : _opp_table_find_key+0x9c/0x174\n...\nCall trace:\n _read_bw+0x8/0x10 (P)\n _opp_table_find_key+0x9c/0x174 (L)\n _find_key+0x98/0x168\n dev_pm_opp_find_bw_ceil+0x50/0x88\n...\n\nIn order to fix the crash, create an assert function to check\nif the bandwidth table was created before trying to get a\nbandwidth with _read_bw().(CVE-2024-58068)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nteam: prevent adding a device which is already a team device lower\n\nPrevent adding a device which is already a team device lower,\ne.g. adding veth0 if vlan1 was already added and veth0 is a lower of\nvlan1.\n\nThis is not useful in practice and can lead to recursive locking:\n\n$ ip link add veth0 type veth peer name veth1\n$ ip link set veth0 up\n$ ip link set veth1 up\n$ ip link add link veth0 name veth0.1 type vlan protocol 802.1Q id 1\n$ ip link add team0 type team\n$ ip link set veth0.1 down\n$ ip link set veth0.1 master team0\nteam0: Port device veth0.1 added\n$ ip link set veth0 down\n$ ip link set veth0 master team0\n\n============================================\nWARNING: possible recursive locking detected\n6.13.0-rc2-virtme-00441-ga14a429069bb #46 Not tainted\n--------------------------------------------\nip/7684 is trying to acquire lock:\nffff888016848e00 (team-\u0026gt;team_lock_key){+.+.}-{4:4}, at: team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)\n\nbut task is already holding lock:\nffff888016848e00 (team-\u0026gt;team_lock_key){+.+.}-{4:4}, at: team_add_slave (drivers/net/team/team_core.c:1147 drivers/net/team/team_core.c:1977)\n\nother info that might help us debug this:\nPossible unsafe locking scenario:\n\nCPU0\n----\nlock(team-\u0026gt;team_lock_key);\nlock(team-\u0026gt;team_lock_key);\n\n*** DEADLOCK ***\n\nMay be due to missing lock nesting notation\n\n2 locks held by ip/7684:\n\nstack backtrace:\nCPU: 3 UID: 0 PID: 7684 Comm: ip Not tainted 6.13.0-rc2-virtme-00441-ga14a429069bb #46\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\nCall Trace:\n\u0026lt;TASK\u0026gt;\ndump_stack_lvl (lib/dump_stack.c:122)\nprint_deadlock_bug.cold (kernel/locking/lockdep.c:3040)\n__lock_acquire (kernel/locking/lockdep.c:3893 kernel/locking/lockdep.c:5226)\n? netlink_broadcast_filtered (net/netlink/af_netlink.c:1548)\nlock_acquire.part.0 (kernel/locking/lockdep.c:467 kernel/locking/lockdep.c:5851)\n? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)\n? trace_lock_acquire (./include/trace/events/lock.h:24 (discriminator 2))\n? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)\n? lock_acquire (kernel/locking/lockdep.c:5822)\n? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)\n__mutex_lock (kernel/locking/mutex.c:587 kernel/locking/mutex.c:735)\n? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)\n? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)\n? fib_sync_up (net/ipv4/fib_semantics.c:2167)\n? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)\nteam_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)\nnotifier_call_chain (kernel/notifier.c:85)\ncall_netdevice_notifiers_info (net/core/dev.c:1996)\n__dev_notify_flags (net/core/dev.c:8993)\n? __dev_change_flags (net/core/dev.c:8975)\ndev_change_flags (net/core/dev.c:9027)\nvlan_device_event (net/8021q/vlan.c:85 net/8021q/vlan.c:470)\n? br_device_event (net/bridge/br.c:143)\nnotifier_call_chain (kernel/notifier.c:85)\ncall_netdevice_notifiers_info (net/core/dev.c:1996)\ndev_open (net/core/dev.c:1519 net/core/dev.c:1505)\nteam_add_slave (drivers/net/team/team_core.c:1219 drivers/net/team/team_core.c:1977)\n? __pfx_team_add_slave (drivers/net/team/team_core.c:1972)\ndo_set_master (net/core/rtnetlink.c:2917)\ndo_setlink.isra.0 (net/core/rtnetlink.c:3117)(CVE-2024-58071)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: rtlwifi: remove unused check_buddy_priv\n\nCommit 2461c7d60f9f (\u0026quot;rtlwifi: Update header file\u0026quot;) introduced a global\nlist of private data structures.\n\nLater on, commit 26634c4b1868 (\u0026quot;rtlwifi Modify existing bits to match\nvendor version 2013.02.07\u0026quot;) started adding the private data to that list at\nprobe time and added a hook, check_buddy_priv to find the private data from\na similar device.\n\nHowever, that function was never used.\n\nBesides, though there is a lock for that list, it is never used. And when\nthe probe fails, the private data is never removed from the list. This\nwould cause a second probe to access freed memory.\n\nRemove the unused hook, structures and members, which will prevent the\npotential race condition on the list and its corruption during a second\nprobe when probe fails.(CVE-2024-58072)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvfio/platform: check the bounds of read/write syscalls\n\ncount and offset are passed from user space and not checked, only\noffset is capped to 40 bits, which can be used to read/write out of\nbounds of the device.(CVE-2025-21687)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: handle fastopen disconnect correctly\n\nSyzbot was able to trigger a data stream corruption:\n\n WARNING: CPU: 0 PID: 9846 at net/mptcp/protocol.c:1024 __mptcp_clean_una+0xddb/0xff0 net/mptcp/protocol.c:1024\n Modules linked in:\n CPU: 0 UID: 0 PID: 9846 Comm: syz-executor351 Not tainted 6.13.0-rc2-syzkaller-00059-g00a5acdbf398 #0\n Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 11/25/2024\n RIP: 0010:__mptcp_clean_una+0xddb/0xff0 net/mptcp/protocol.c:1024\n Code: fa ff ff 48 8b 4c 24 18 80 e1 07 fe c1 38 c1 0f 8c 8e fa ff ff 48 8b 7c 24 18 e8 e0 db 54 f6 e9 7f fa ff ff e8 e6 80 ee f5 90 \u0026lt;0f\u0026gt; 0b 90 4c 8b 6c 24 40 4d 89 f4 e9 04 f5 ff ff 44 89 f1 80 e1 07\n RSP: 0018:ffffc9000c0cf400 EFLAGS: 00010293\n RAX: ffffffff8bb0dd5a RBX: ffff888033f5d230 RCX: ffff888059ce8000\n RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000\n RBP: ffffc9000c0cf518 R08: ffffffff8bb0d1dd R09: 1ffff110170c8928\n R10: dffffc0000000000 R11: ffffed10170c8929 R12: 0000000000000000\n R13: ffff888033f5d220 R14: dffffc0000000000 R15: ffff8880592b8000\n FS: 00007f6e866496c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00007f6e86f491a0 CR3: 00000000310e6000 CR4: 00000000003526f0\n DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n Call Trace:\n \u0026lt;TASK\u0026gt;\n __mptcp_clean_una_wakeup+0x7f/0x2d0 net/mptcp/protocol.c:1074\n mptcp_release_cb+0x7cb/0xb30 net/mptcp/protocol.c:3493\n release_sock+0x1aa/0x1f0 net/core/sock.c:3640\n inet_wait_for_connect net/ipv4/af_inet.c:609 [inline]\n __inet_stream_connect+0x8bd/0xf30 net/ipv4/af_inet.c:703\n mptcp_sendmsg_fastopen+0x2a2/0x530 net/mptcp/protocol.c:1755\n mptcp_sendmsg+0x1884/0x1b10 net/mptcp/protocol.c:1830\n sock_sendmsg_nosec net/socket.c:711 [inline]\n __sock_sendmsg+0x1a6/0x270 net/socket.c:726\n ____sys_sendmsg+0x52a/0x7e0 net/socket.c:2583\n ___sys_sendmsg net/socket.c:2637 [inline]\n __sys_sendmsg+0x269/0x350 net/socket.c:2669\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n RIP: 0033:0x7f6e86ebfe69\n Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 b1 1f 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\n RSP: 002b:00007f6e86649168 EFLAGS: 00000246 ORIG_RAX: 000000000000002e\n RAX: ffffffffffffffda RBX: 00007f6e86f491b8 RCX: 00007f6e86ebfe69\n RDX: 0000000030004001 RSI: 0000000020000080 RDI: 0000000000000003\n RBP: 00007f6e86f491b0 R08: 00007f6e866496c0 R09: 0000000000000000\n R10: 0000000000000000 R11: 0000000000000246 R12: 00007f6e86f491bc\n R13: 000000000000006e R14: 00007ffe445d9420 R15: 00007ffe445d9508\n \u0026lt;/TASK\u0026gt;\n\nThe root cause is the bad handling of disconnect() generated internally\nby the MPTCP protocol in case of connect FASTOPEN errors.\n\nAddress the issue increasing the socket disconnect counter even on such\na case, to allow other threads waiting on the same socket lock to\nproperly error out.(CVE-2025-21705)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: consolidate suboption status\n\nMPTCP maintains the received sub-options status is the bitmask carrying\nthe received suboptions and in several bitfields carrying per suboption\nadditional info.\n\nZeroing the bitmask before parsing is not enough to ensure a consistent\nstatus, and the MPTCP code has to additionally clear some bitfiled\ndepending on the actually parsed suboption.\n\nThe above schema is fragile, and syzbot managed to trigger a path where\na relevant bitfield is not cleared/initialized:\n\n BUG: KMSAN: uninit-value in __mptcp_expand_seq net/mptcp/options.c:1030 [inline]\n BUG: KMSAN: uninit-value in mptcp_expand_seq net/mptcp/protocol.h:864 [inline]\n BUG: KMSAN: uninit-value in ack_update_msk net/mptcp/options.c:1060 [inline]\n BUG: KMSAN: uninit-value in mptcp_incoming_options+0x2036/0x3d30 net/mptcp/options.c:1209\n __mptcp_expand_seq net/mptcp/options.c:1030 [inline]\n mptcp_expand_seq net/mptcp/protocol.h:864 [inline]\n ack_update_msk net/mptcp/options.c:1060 [inline]\n mptcp_incoming_options+0x2036/0x3d30 net/mptcp/options.c:1209\n tcp_data_queue+0xb4/0x7be0 net/ipv4/tcp_input.c:5233\n tcp_rcv_established+0x1061/0x2510 net/ipv4/tcp_input.c:6264\n tcp_v4_do_rcv+0x7f3/0x11a0 net/ipv4/tcp_ipv4.c:1916\n tcp_v4_rcv+0x51df/0x5750 net/ipv4/tcp_ipv4.c:2351\n ip_protocol_deliver_rcu+0x2a3/0x13d0 net/ipv4/ip_input.c:205\n ip_local_deliver_finish+0x336/0x500 net/ipv4/ip_input.c:233\n NF_HOOK include/linux/netfilter.h:314 [inline]\n ip_local_deliver+0x21f/0x490 net/ipv4/ip_input.c:254\n dst_input include/net/dst.h:460 [inline]\n ip_rcv_finish+0x4a2/0x520 net/ipv4/ip_input.c:447\n NF_HOOK include/linux/netfilter.h:314 [inline]\n ip_rcv+0xcd/0x380 net/ipv4/ip_input.c:567\n __netif_receive_skb_one_core net/core/dev.c:5704 [inline]\n __netif_receive_skb+0x319/0xa00 net/core/dev.c:5817\n process_backlog+0x4ad/0xa50 net/core/dev.c:6149\n __napi_poll+0xe7/0x980 net/core/dev.c:6902\n napi_poll net/core/dev.c:6971 [inline]\n net_rx_action+0xa5a/0x19b0 net/core/dev.c:7093\n handle_softirqs+0x1a0/0x7c0 kernel/softirq.c:561\n __do_softirq+0x14/0x1a kernel/softirq.c:595\n do_softirq+0x9a/0x100 kernel/softirq.c:462\n __local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:389\n local_bh_enable include/linux/bottom_half.h:33 [inline]\n rcu_read_unlock_bh include/linux/rcupdate.h:919 [inline]\n __dev_queue_xmit+0x2758/0x57d0 net/core/dev.c:4493\n dev_queue_xmit include/linux/netdevice.h:3168 [inline]\n neigh_hh_output include/net/neighbour.h:523 [inline]\n neigh_output include/net/neighbour.h:537 [inline]\n ip_finish_output2+0x187c/0x1b70 net/ipv4/ip_output.c:236\n __ip_finish_output+0x287/0x810\n ip_finish_output+0x4b/0x600 net/ipv4/ip_output.c:324\n NF_HOOK_COND include/linux/netfilter.h:303 [inline]\n ip_output+0x15f/0x3f0 net/ipv4/ip_output.c:434\n dst_output include/net/dst.h:450 [inline]\n ip_local_out net/ipv4/ip_output.c:130 [inline]\n __ip_queue_xmit+0x1f2a/0x20d0 net/ipv4/ip_output.c:536\n ip_queue_xmit+0x60/0x80 net/ipv4/ip_output.c:550\n __tcp_transmit_skb+0x3cea/0x4900 net/ipv4/tcp_output.c:1468\n tcp_transmit_skb net/ipv4/tcp_output.c:1486 [inline]\n tcp_write_xmit+0x3b90/0x9070 net/ipv4/tcp_output.c:2829\n __tcp_push_pending_frames+0xc4/0x380 net/ipv4/tcp_output.c:3012\n tcp_send_fin+0x9f6/0xf50 net/ipv4/tcp_output.c:3618\n __tcp_close+0x140c/0x1550 net/ipv4/tcp.c:3130\n __mptcp_close_ssk+0x74e/0x16f0 net/mptcp/protocol.c:2496\n mptcp_close_ssk+0x26b/0x2c0 net/mptcp/protocol.c:2550\n mptcp_pm_nl_rm_addr_or_subflow+0x635/0xd10 net/mptcp/pm_netlink.c:889\n mptcp_pm_nl_rm_subflow_received net/mptcp/pm_netlink.c:924 [inline]\n mptcp_pm_flush_addrs_and_subflows net/mptcp/pm_netlink.c:1688 [inline]\n mptcp_nl_flush_addrs_list net/mptcp/pm_netlink.c:1709 [inline]\n mptcp_pm_nl_flush_addrs_doit+0xe10/0x1630 net/mptcp/pm_netlink.c:1750\n genl_family_rcv_msg_doit net/netlink/genetlink.c:1115 [inline]\n \n---truncated---(CVE-2025-21707)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: usb: rtl8150: enable basic endpoint checking\n\nSyzkaller reports [1] encountering a common issue of utilizing a wrong\nusb endpoint type during URB submitting stage. This, in turn, triggers\na warning shown below.\n\nFor now, enable simple endpoint checking (specifically, bulk and\ninterrupt eps, testing control one is not essential) to mitigate\nthe issue with a view to do other related cosmetic changes later,\nif they are necessary.\n\n[1] Syzkaller report:\nusb 1-1: BOGUS urb xfer, pipe 3 != type 1\nWARNING: CPU: 1 PID: 2586 at drivers/usb/core/urb.c:503 usb_submit_urb+0xe4b/0x1730 driv\u0026gt;\nModules linked in:\nCPU: 1 UID: 0 PID: 2586 Comm: dhcpcd Not tainted 6.11.0-rc4-syzkaller-00069-gfc88bb11617\u0026gt;\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024\nRIP: 0010:usb_submit_urb+0xe4b/0x1730 drivers/usb/core/urb.c:503\nCode: 84 3c 02 00 00 e8 05 e4 fc fc 4c 89 ef e8 fd 25 d7 fe 45 89 e0 89 e9 4c 89 f2 48 8\u0026gt;\nRSP: 0018:ffffc9000441f740 EFLAGS: 00010282\nRAX: 0000000000000000 RBX: ffff888112487a00 RCX: ffffffff811a99a9\nRDX: ffff88810df6ba80 RSI: ffffffff811a99b6 RDI: 0000000000000001\nRBP: 0000000000000003 R08: 0000000000000001 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000001\nR13: ffff8881023bf0a8 R14: ffff888112452a20 R15: ffff888112487a7c\nFS: 00007fc04eea5740(0000) GS:ffff8881f6300000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f0a1de9f870 CR3: 000000010dbd0000 CR4: 00000000003506f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n rtl8150_open+0x300/0xe30 drivers/net/usb/rtl8150.c:733\n __dev_open+0x2d4/0x4e0 net/core/dev.c:1474\n __dev_change_flags+0x561/0x720 net/core/dev.c:8838\n dev_change_flags+0x8f/0x160 net/core/dev.c:8910\n devinet_ioctl+0x127a/0x1f10 net/ipv4/devinet.c:1177\n inet_ioctl+0x3aa/0x3f0 net/ipv4/af_inet.c:1003\n sock_do_ioctl+0x116/0x280 net/socket.c:1222\n sock_ioctl+0x22e/0x6c0 net/socket.c:1341\n vfs_ioctl fs/ioctl.c:51 [inline]\n __do_sys_ioctl fs/ioctl.c:907 [inline]\n __se_sys_ioctl fs/ioctl.c:893 [inline]\n __x64_sys_ioctl+0x193/0x220 fs/ioctl.c:893\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7fc04ef73d49\n...\n\nThis change has not been tested on real hardware.(CVE-2025-21708)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntcp: correct handling of extreme memory squeeze\n\nTesting with iperf3 using the \u0026quot;pasta\u0026quot; protocol splicer has revealed\na problem in the way tcp handles window advertising in extreme memory\nsqueeze situations.\n\nUnder memory pressure, a socket endpoint may temporarily advertise\na zero-sized window, but this is not stored as part of the socket data.\nThe reasoning behind this is that it is considered a temporary setting\nwhich shouldn\u0026apos;t influence any further calculations.\n\nHowever, if we happen to stall at an unfortunate value of the current\nwindow size, the algorithm selecting a new value will consistently fail\nto advertise a non-zero window once we have freed up enough memory.\nThis means that this side\u0026apos;s notion of the current window size is\ndifferent from the one last advertised to the peer, causing the latter\nto not send any data to resolve the sitution.\n\nThe problem occurs on the iperf3 server side, and the socket in question\nis a completely regular socket with the default settings for the\nfedora40 kernel. We do not use SO_PEEK or SO_RCVBUF on the socket.\n\nThe following excerpt of a logging session, with own comments added,\nshows more in detail what is happening:\n\n// tcp_v4_rcv(-\u0026gt;)\n// tcp_rcv_established(-\u0026gt;)\n[5201\u0026lt;-\u0026gt;39222]: ==== Activating log @ net/ipv4/tcp_input.c/tcp_data_queue()/5257 ====\n[5201\u0026lt;-\u0026gt;39222]: tcp_data_queue(-\u0026gt;)\n[5201\u0026lt;-\u0026gt;39222]: DROPPING skb [265600160..265665640], reason: SKB_DROP_REASON_PROTO_MEM\n [rcv_nxt 265600160, rcv_wnd 262144, snt_ack 265469200, win_now 131184]\n [copied_seq 259909392-\u0026gt;260034360 (124968), unread 5565800, qlen 85, ofoq 0]\n [OFO queue: gap: 65480, len: 0]\n[5201\u0026lt;-\u0026gt;39222]: tcp_data_queue(\u0026lt;-)\n[5201\u0026lt;-\u0026gt;39222]: __tcp_transmit_skb(-\u0026gt;)\n [tp-\u0026gt;rcv_wup: 265469200, tp-\u0026gt;rcv_wnd: 262144, tp-\u0026gt;rcv_nxt 265600160]\n[5201\u0026lt;-\u0026gt;39222]: tcp_select_window(-\u0026gt;)\n[5201\u0026lt;-\u0026gt;39222]: (inet_csk(sk)-\u0026gt;icsk_ack.pending \u0026amp; ICSK_ACK_NOMEM) ? --\u0026gt; TRUE\n [tp-\u0026gt;rcv_wup: 265469200, tp-\u0026gt;rcv_wnd: 262144, tp-\u0026gt;rcv_nxt 265600160]\n returning 0\n[5201\u0026lt;-\u0026gt;39222]: tcp_select_window(\u0026lt;-)\n[5201\u0026lt;-\u0026gt;39222]: ADVERTISING WIN 0, ACK_SEQ: 265600160\n[5201\u0026lt;-\u0026gt;39222]: [__tcp_transmit_skb(\u0026lt;-)\n[5201\u0026lt;-\u0026gt;39222]: tcp_rcv_established(\u0026lt;-)\n[5201\u0026lt;-\u0026gt;39222]: tcp_v4_rcv(\u0026lt;-)\n\n// Receive queue is at 85 buffers and we are out of memory.\n// We drop the incoming buffer, although it is in sequence, and decide\n// to send an advertisement with a window of zero.\n// We don\u0026apos;t update tp-\u0026gt;rcv_wnd and tp-\u0026gt;rcv_wup accordingly, which means\n// we unconditionally shrink the window.\n\n[5201\u0026lt;-\u0026gt;39222]: tcp_recvmsg_locked(-\u0026gt;)\n[5201\u0026lt;-\u0026gt;39222]: __tcp_cleanup_rbuf(-\u0026gt;) tp-\u0026gt;rcv_wup: 265469200, tp-\u0026gt;rcv_wnd: 262144, tp-\u0026gt;rcv_nxt 265600160\n[5201\u0026lt;-\u0026gt;39222]: [new_win = 0, win_now = 131184, 2 * win_now = 262368]\n[5201\u0026lt;-\u0026gt;39222]: [new_win \u0026gt;= (2 * win_now) ? --\u0026gt; time_to_ack = 0]\n[5201\u0026lt;-\u0026gt;39222]: NOT calling tcp_send_ack()\n [tp-\u0026gt;rcv_wup: 265469200, tp-\u0026gt;rcv_wnd: 262144, tp-\u0026gt;rcv_nxt 265600160]\n[5201\u0026lt;-\u0026gt;39222]: __tcp_cleanup_rbuf(\u0026lt;-)\n [rcv_nxt 265600160, rcv_wnd 262144, snt_ack 265469200, win_now 131184]\n [copied_seq 260040464-\u0026gt;260040464 (0), unread 5559696, qlen 85, ofoq 0]\n returning 6104 bytes\n[5201\u0026lt;-\u0026gt;39222]: tcp_recvmsg_locked(\u0026lt;-)\n\n// After each read, the algorithm for calculating the new receive\n// window in __tcp_cleanup_rbuf() finds it is too small to advertise\n// or to update tp-\u0026gt;rcv_wnd.\n// Meanwhile, the peer thinks the window is zero, and will not send\n// any more data to trigger an update from the interrupt mode side.\n\n[5201\u0026lt;-\u0026gt;39222]: tcp_recvmsg_locked(-\u0026gt;)\n[5201\u0026lt;-\u0026gt;39222]: __tcp_cleanup_rbuf(-\u0026gt;) tp-\u0026gt;rcv_wup: 265469200, tp-\u0026gt;rcv_wnd: 262144, tp-\u0026gt;rcv_nxt 265600160\n[5201\u0026lt;-\u0026gt;39222]: [new_win = 262144, win_now = 131184, 2 * win_n\n---truncated---(CVE-2025-21710)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/rose: prevent integer overflows in rose_setsockopt()\n\nIn case of possible unpredictably large arguments passed to\nrose_setsockopt() and multiplied by extra values on top of that,\ninteger overflows may occur.\n\nDo the safest minimum and fix these issues by checking the\ncontents of \u0026apos;opt\u0026apos; and returning -EINVAL if they are too large. Also,\nswitch to unsigned int and remove useless check for negative \u0026apos;opt\u0026apos;\nin ROSE_IDLE case.(CVE-2025-21711)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: davicom: fix UAF in dm9000_drv_remove\n\ndm is netdev private data and it cannot be\nused after free_netdev() call. Using dm after free_netdev()\ncan cause UAF bug. Fix it by moving free_netdev() at the end of the\nfunction.\n\nThis is similar to the issue fixed in commit\nad297cd2db89 (\u0026quot;net: qcom/emac: fix UAF in emac_remove\u0026quot;).\n\nThis bug is detected by our static analysis tool.(CVE-2025-21715)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvxlan: Fix uninit-value in vxlan_vnifilter_dump()\n\nKMSAN reported an uninit-value access in vxlan_vnifilter_dump() [1].\n\nIf the length of the netlink message payload is less than\nsizeof(struct tunnel_msg), vxlan_vnifilter_dump() accesses bytes\nbeyond the message. This can lead to uninit-value access. Fix this by\nreturning an error in such situations.\n\n[1]\nBUG: KMSAN: uninit-value in vxlan_vnifilter_dump+0x328/0x920 drivers/net/vxlan/vxlan_vnifilter.c:422\n vxlan_vnifilter_dump+0x328/0x920 drivers/net/vxlan/vxlan_vnifilter.c:422\n rtnl_dumpit+0xd5/0x2f0 net/core/rtnetlink.c:6786\n netlink_dump+0x93e/0x15f0 net/netlink/af_netlink.c:2317\n __netlink_dump_start+0x716/0xd60 net/netlink/af_netlink.c:2432\n netlink_dump_start include/linux/netlink.h:340 [inline]\n rtnetlink_dump_start net/core/rtnetlink.c:6815 [inline]\n rtnetlink_rcv_msg+0x1256/0x14a0 net/core/rtnetlink.c:6882\n netlink_rcv_skb+0x467/0x660 net/netlink/af_netlink.c:2542\n rtnetlink_rcv+0x35/0x40 net/core/rtnetlink.c:6944\n netlink_unicast_kernel net/netlink/af_netlink.c:1321 [inline]\n netlink_unicast+0xed6/0x1290 net/netlink/af_netlink.c:1347\n netlink_sendmsg+0x1092/0x1230 net/netlink/af_netlink.c:1891\n sock_sendmsg_nosec net/socket.c:711 [inline]\n __sock_sendmsg+0x330/0x3d0 net/socket.c:726\n ____sys_sendmsg+0x7f4/0xb50 net/socket.c:2583\n ___sys_sendmsg+0x271/0x3b0 net/socket.c:2637\n __sys_sendmsg net/socket.c:2669 [inline]\n __do_sys_sendmsg net/socket.c:2674 [inline]\n __se_sys_sendmsg net/socket.c:2672 [inline]\n __x64_sys_sendmsg+0x211/0x3e0 net/socket.c:2672\n x64_sys_call+0x3878/0x3d90 arch/x86/include/generated/asm/syscalls_64.h:47\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xd9/0x1d0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nUninit was created at:\n slab_post_alloc_hook mm/slub.c:4110 [inline]\n slab_alloc_node mm/slub.c:4153 [inline]\n kmem_cache_alloc_node_noprof+0x800/0xe80 mm/slub.c:4205\n kmalloc_reserve+0x13b/0x4b0 net/core/skbuff.c:587\n __alloc_skb+0x347/0x7d0 net/core/skbuff.c:678\n alloc_skb include/linux/skbuff.h:1323 [inline]\n netlink_alloc_large_skb+0xa5/0x280 net/netlink/af_netlink.c:1196\n netlink_sendmsg+0xac9/0x1230 net/netlink/af_netlink.c:1866\n sock_sendmsg_nosec net/socket.c:711 [inline]\n __sock_sendmsg+0x330/0x3d0 net/socket.c:726\n ____sys_sendmsg+0x7f4/0xb50 net/socket.c:2583\n ___sys_sendmsg+0x271/0x3b0 net/socket.c:2637\n __sys_sendmsg net/socket.c:2669 [inline]\n __do_sys_sendmsg net/socket.c:2674 [inline]\n __se_sys_sendmsg net/socket.c:2672 [inline]\n __x64_sys_sendmsg+0x211/0x3e0 net/socket.c:2672\n x64_sys_call+0x3878/0x3d90 arch/x86/include/generated/asm/syscalls_64.h:47\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xd9/0x1d0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nCPU: 0 UID: 0 PID: 30991 Comm: syz.4.10630 Not tainted 6.12.0-10694-gc44daa7e3c73 #29\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014(CVE-2025-21716)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: delete intermediate secpath entry in packet offload mode\n\nPackets handled by hardware have added secpath as a way to inform XFRM\ncore code that this path was already handled. That secpath is not needed\nat all after policy is checked and it is removed later in the stack.\n\nHowever, in the case of IP forwarding is enabled (/proc/sys/net/ipv4/ip_forward),\nthat secpath is not removed and packets which already were handled are reentered\nto the driver TX path with xfrm_offload set.\n\nThe following kernel panic is observed in mlx5 in such case:\n\n mlx5_core 0000:04:00.0 enp4s0f0np0: Link up\n mlx5_core 0000:04:00.1 enp4s0f1np1: Link up\n Initializing XFRM netlink socket\n IPsec XFRM device driver\n BUG: kernel NULL pointer dereference, address: 0000000000000000\n #PF: supervisor instruction fetch in kernel mode\n #PF: error_code(0x0010) - not-present page\n PGD 0 P4D 0\n Oops: Oops: 0010 [#1] PREEMPT SMP\n CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.13.0-rc1-alex #3\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-1ubuntu1.1 04/01/2014\n RIP: 0010:0x0\n Code: Unable to access opcode bytes at 0xffffffffffffffd6.\n RSP: 0018:ffffb87380003800 EFLAGS: 00010206\n RAX: ffff8df004e02600 RBX: ffffb873800038d8 RCX: 00000000ffff98cf\n RDX: ffff8df00733e108 RSI: ffff8df00521fb80 RDI: ffff8df001661f00\n RBP: ffffb87380003850 R08: ffff8df013980000 R09: 0000000000000010\n R10: 0000000000000002 R11: 0000000000000002 R12: ffff8df001661f00\n R13: ffff8df00521fb80 R14: ffff8df00733e108 R15: ffff8df011faf04e\n FS: 0000000000000000(0000) GS:ffff8df46b800000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: ffffffffffffffd6 CR3: 0000000106384000 CR4: 0000000000350ef0\n Call Trace:\n \u0026lt;IRQ\u0026gt;\n ? show_regs+0x63/0x70\n ? __die_body+0x20/0x60\n ? __die+0x2b/0x40\n ? page_fault_oops+0x15c/0x550\n ? do_user_addr_fault+0x3ed/0x870\n ? exc_page_fault+0x7f/0x190\n ? asm_exc_page_fault+0x27/0x30\n mlx5e_ipsec_handle_tx_skb+0xe7/0x2f0 [mlx5_core]\n mlx5e_xmit+0x58e/0x1980 [mlx5_core]\n ? __fib_lookup+0x6a/0xb0\n dev_hard_start_xmit+0x82/0x1d0\n sch_direct_xmit+0xfe/0x390\n __dev_queue_xmit+0x6d8/0xee0\n ? __fib_lookup+0x6a/0xb0\n ? internal_add_timer+0x48/0x70\n ? mod_timer+0xe2/0x2b0\n neigh_resolve_output+0x115/0x1b0\n __neigh_update+0x26a/0xc50\n neigh_update+0x14/0x20\n arp_process+0x2cb/0x8e0\n ? __napi_build_skb+0x5e/0x70\n arp_rcv+0x11e/0x1c0\n ? dev_gro_receive+0x574/0x820\n __netif_receive_skb_list_core+0x1cf/0x1f0\n netif_receive_skb_list_internal+0x183/0x2a0\n napi_complete_done+0x76/0x1c0\n mlx5e_napi_poll+0x234/0x7a0 [mlx5_core]\n __napi_poll+0x2d/0x1f0\n net_rx_action+0x1a6/0x370\n ? atomic_notifier_call_chain+0x3b/0x50\n ? irq_int_handler+0x15/0x20 [mlx5_core]\n handle_softirqs+0xb9/0x2f0\n ? handle_irq_event+0x44/0x60\n irq_exit_rcu+0xdb/0x100\n common_interrupt+0x98/0xc0\n \u0026lt;/IRQ\u0026gt;\n \u0026lt;TASK\u0026gt;\n asm_common_interrupt+0x27/0x40\n RIP: 0010:pv_native_safe_halt+0xb/0x10\n Code: 09 c3 66 66 2e 0f 1f 84 00 00 00 00 00 66 90 0f 22\n 0f 1f 84 00 00 00 00 00 90 eb 07 0f 00 2d 7f e9 36 00 fb\n40 00 83 ff 07 77 21 89 ff ff 24 fd 88 3d a1 bd 0f 21 f8\n RSP: 0018:ffffffffbe603de8 EFLAGS: 00000202\n RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000f92f46680\n RDX: 0000000000000037 RSI: 00000000ffffffff RDI: 00000000000518d4\n RBP: ffffffffbe603df0 R08: 000000cd42e4dffb R09: ffffffffbe603d70\n R10: 0000004d80d62680 R11: 0000000000000001 R12: ffffffffbe60bf40\n R13: 0000000000000000 R14: 0000000000000000 R15: ffffffffbe60aff8\n ? default_idle+0x9/0x20\n arch_cpu_idle+0x9/0x10\n default_idle_call+0x29/0xf0\n do_idle+0x1f2/0x240\n cpu_startup_entry+0x2c/0x30\n rest_init+0xe7/0x100\n start_kernel+0x76b/0xb90\n x86_64_start_reservations+0x18/0x30\n x86_64_start_kernel+0xc0/0x110\n ? setup_ghcb+0xe/0x130\n common_startup_64+0x13e/0x141\n \u0026lt;/TASK\u0026gt;\n Modules linked in: esp4_offload esp4 xfrm_interface\nxfrm6_tunnel tunnel4 tunnel6 xfrm_user xfrm_algo binf\n---truncated---(CVE-2025-21720)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niommufd/iova_bitmap: Fix shift-out-of-bounds in iova_bitmap_offset_to_index()\n\nResolve a UBSAN shift-out-of-bounds issue in iova_bitmap_offset_to_index()\nwhere shifting the constant \u0026quot;1\u0026quot; (of type int) by bitmap-\u0026gt;mapped.pgshift\n(an unsigned long value) could result in undefined behavior.\n\nThe constant \u0026quot;1\u0026quot; defaults to a 32-bit \u0026quot;int\u0026quot;, and when \u0026quot;pgshift\u0026quot; exceeds\n31 (e.g., pgshift = 63) the shift operation overflows, as the result\ncannot be represented in a 32-bit type.\n\nTo resolve this, the constant is updated to \u0026quot;1UL\u0026quot;, promoting it to an\nunsigned long type to match the operand\u0026apos;s type.(CVE-2025-21724)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix oops due to unset link speed\n\nIt isn\u0026apos;t guaranteed that NETWORK_INTERFACE_INFO::LinkSpeed will always\nbe set by the server, so the client must handle any values and then\nprevent oopses like below from happening:\n\nOops: divide error: 0000 [#1] PREEMPT SMP KASAN NOPTI\nCPU: 0 UID: 0 PID: 1323 Comm: cat Not tainted 6.13.0-rc7 #2\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-3.fc41\n04/01/2014\nRIP: 0010:cifs_debug_data_proc_show+0xa45/0x1460 [cifs] Code: 00 00 48\n89 df e8 3b cd 1b c1 41 f6 44 24 2c 04 0f 84 50 01 00 00 48 89 ef e8\ne7 d0 1b c1 49 8b 44 24 18 31 d2 49 8d 7c 24 28 \u0026lt;48\u0026gt; f7 74 24 18 48 89\nc3 e8 6e cf 1b c1 41 8b 6c 24 28 49 8d 7c 24\nRSP: 0018:ffffc90001817be0 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: ffff88811230022c RCX: ffffffffc041bd99\nRDX: 0000000000000000 RSI: 0000000000000567 RDI: ffff888112300228\nRBP: ffff888112300218 R08: fffff52000302f5f R09: ffffed1022fa58ac\nR10: ffff888117d2c566 R11: 00000000fffffffe R12: ffff888112300200\nR13: 000000012a15343f R14: 0000000000000001 R15: ffff888113f2db58\nFS: 00007fe27119e740(0000) GS:ffff888148600000(0000)\nknlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007fe2633c5000 CR3: 0000000124da0000 CR4: 0000000000750ef0\nPKRU: 55555554\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? __die_body.cold+0x19/0x27\n ? die+0x2e/0x50\n ? do_trap+0x159/0x1b0\n ? cifs_debug_data_proc_show+0xa45/0x1460 [cifs]\n ? do_error_trap+0x90/0x130\n ? cifs_debug_data_proc_show+0xa45/0x1460 [cifs]\n ? exc_divide_error+0x39/0x50\n ? cifs_debug_data_proc_show+0xa45/0x1460 [cifs]\n ? asm_exc_divide_error+0x1a/0x20\n ? cifs_debug_data_proc_show+0xa39/0x1460 [cifs]\n ? cifs_debug_data_proc_show+0xa45/0x1460 [cifs]\n ? seq_read_iter+0x42e/0x790\n seq_read_iter+0x19a/0x790\n proc_reg_read_iter+0xbe/0x110\n ? __pfx_proc_reg_read_iter+0x10/0x10\n vfs_read+0x469/0x570\n ? do_user_addr_fault+0x398/0x760\n ? __pfx_vfs_read+0x10/0x10\n ? find_held_lock+0x8a/0xa0\n ? __pfx_lock_release+0x10/0x10\n ksys_read+0xd3/0x170\n ? __pfx_ksys_read+0x10/0x10\n ? __rcu_read_unlock+0x50/0x270\n ? mark_held_locks+0x1a/0x90\n do_syscall_64+0xbb/0x1d0\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7fe271288911\nCode: 00 48 8b 15 01 25 10 00 f7 d8 64 89 02 b8 ff ff ff ff eb bd e8\n20 ad 01 00 f3 0f 1e fa 80 3d b5 a7 10 00 00 74 13 31 c0 0f 05 \u0026lt;48\u0026gt; 3d\n00 f0 ff ff 77 4f c3 66 0f 1f 44 00 00 55 48 89 e5 48 83 ec\nRSP: 002b:00007ffe87c079d8 EFLAGS: 00000246 ORIG_RAX: 0000000000000000\nRAX: ffffffffffffffda RBX: 0000000000040000 RCX: 00007fe271288911\nRDX: 0000000000040000 RSI: 00007fe2633c6000 RDI: 0000000000000003\nRBP: 00007ffe87c07a00 R08: 0000000000000000 R09: 00007fe2713e6380\nR10: 0000000000000022 R11: 0000000000000246 R12: 0000000000040000\nR13: 00007fe2633c6000 R14: 0000000000000003 R15: 0000000000000000\n \u0026lt;/TASK\u0026gt;\n\nFix this by setting cifs_server_iface::speed to a sane value (1Gbps)\nby default when link speed is unset.(CVE-2025-21725)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npadata: avoid UAF for reorder_work\n\nAlthough the previous patch can avoid ps and ps UAF for _do_serial, it\ncan not avoid potential UAF issue for reorder_work. This issue can\nhappen just as below:\n\ncrypto_request\t\t\tcrypto_request\t\tcrypto_del_alg\npadata_do_serial\n ...\n padata_reorder\n // processes all remaining\n // requests then breaks\n while (1) {\n if (!padata)\n break;\n ...\n }\n\n\t\t\t\tpadata_do_serial\n\t\t\t\t // new request added\n\t\t\t\t list_add\n // sees the new request\n queue_work(reorder_work)\n\t\t\t\t padata_reorder\n\t\t\t\t queue_work_on(squeue-\u0026gt;work)\n...\n\n\t\t\t\t\u0026lt;kworker context\u0026gt;\n\t\t\t\tpadata_serial_worker\n\t\t\t\t// completes new request,\n\t\t\t\t// no more outstanding\n\t\t\t\t// requests\n\n\t\t\t\t\t\t\tcrypto_del_alg\n\t\t\t\t\t\t\t // free pd\n\n\u0026lt;kworker context\u0026gt;\ninvoke_padata_reorder\n // UAF of pd\n\nTo avoid UAF for \u0026apos;reorder_work\u0026apos;, get \u0026apos;pd\u0026apos; ref before put \u0026apos;reorder_work\u0026apos;\ninto the \u0026apos;serial_wq\u0026apos; and put \u0026apos;pd\u0026apos; ref until the \u0026apos;serial_wq\u0026apos; finish.(CVE-2025-21726)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npadata: fix UAF in padata_reorder\n\nA bug was found when run ltp test:\n\nBUG: KASAN: slab-use-after-free in padata_find_next+0x29/0x1a0\nRead of size 4 at addr ffff88bbfe003524 by task kworker/u113:2/3039206\n\nCPU: 0 PID: 3039206 Comm: kworker/u113:2 Kdump: loaded Not tainted 6.6.0+\nWorkqueue: pdecrypt_parallel padata_parallel_worker\nCall Trace:\n\u0026lt;TASK\u0026gt;\ndump_stack_lvl+0x32/0x50\nprint_address_description.constprop.0+0x6b/0x3d0\nprint_report+0xdd/0x2c0\nkasan_report+0xa5/0xd0\npadata_find_next+0x29/0x1a0\npadata_reorder+0x131/0x220\npadata_parallel_worker+0x3d/0xc0\nprocess_one_work+0x2ec/0x5a0\n\nIf \u0026apos;mdelay(10)\u0026apos; is added before calling \u0026apos;padata_find_next\u0026apos; in the\n\u0026apos;padata_reorder\u0026apos; function, this issue could be reproduced easily with\nltp test (pcrypt_aead01).\n\nThis can be explained as bellow:\n\npcrypt_aead_encrypt\n...\npadata_do_parallel\nrefcount_inc(\u0026amp;pd-\u0026gt;refcnt); // add refcnt\n...\npadata_do_serial\npadata_reorder // pd\nwhile (1) {\npadata_find_next(pd, true); // using pd\nqueue_work_on\n...\npadata_serial_worker\t\t\t\tcrypto_del_alg\npadata_put_pd_cnt // sub refcnt\n\t\t\t\t\t\tpadata_free_shell\n\t\t\t\t\t\tpadata_put_pd(ps-\u0026gt;pd);\n\t\t\t\t\t\t// pd is freed\n// loop again, but pd is freed\n// call padata_find_next, UAF\n}\n\nIn the padata_reorder function, when it loops in \u0026apos;while\u0026apos;, if the alg is\ndeleted, the refcnt may be decreased to 0 before entering\n\u0026apos;padata_find_next\u0026apos;, which leads to UAF.\n\nAs mentioned in [1], do_serial is supposed to be called with BHs disabled\nand always happen under RCU protection, to address this issue, add\nsynchronize_rcu() in \u0026apos;padata_free_shell\u0026apos; wait for all _do_serial calls\nto finish.\n\n[1] https://lore.kernel.org/all/20221028160401.cccypv4euxikusiq@parnassus.localdomain/\n[2] https://lore.kernel.org/linux-kernel/jfjz5d7zwbytztackem7ibzalm5lnxldi2eofeiczqmqs2m7o6@fq426cwnjtkm/(CVE-2025-21727)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Send signals asynchronously if !preemptible\n\nBPF programs can execute in all kinds of contexts and when a program\nrunning in a non-preemptible context uses the bpf_send_signal() kfunc,\nit will cause issues because this kfunc can sleep.\nChange `irqs_disabled()` to `!preemptible()`.(CVE-2025-21728)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nblk-cgroup: Fix class @block_class\u0026apos;s subsystem refcount leakage\n\nblkcg_fill_root_iostats() iterates over @block_class\u0026apos;s devices by\nclass_dev_iter_(init|next)(), but does not end iterating with\nclass_dev_iter_exit(), so causes the class\u0026apos;s subsystem refcount leakage.\n\nFix by ending the iterating with class_dev_iter_exit().(CVE-2025-21745)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: ethernet: ti: am65-cpsw: fix freeing IRQ in am65_cpsw_nuss_remove_tx_chns()\n\nWhen getting the IRQ we use k3_udma_glue_tx_get_irq() which returns\nnegative error value on error. So not NULL check is not sufficient\nto deteremine if IRQ is valid. Check that IRQ is greater then zero\nto ensure it is valid.\n\nThere is no issue at probe time but at runtime user can invoke\n.set_channels which results in the following call chain.\nam65_cpsw_set_channels()\n am65_cpsw_nuss_update_tx_rx_chns()\n am65_cpsw_nuss_remove_tx_chns()\n am65_cpsw_nuss_init_tx_chns()\n\nAt this point if am65_cpsw_nuss_init_tx_chns() fails due to\nk3_udma_glue_tx_get_irq() then tx_chn-\u0026gt;irq will be set to a\nnegative value.\n\nThen, at subsequent .set_channels with higher channel count we\nwill attempt to free an invalid IRQ in am65_cpsw_nuss_remove_tx_chns()\nleading to a kernel warning.\n\nThe issue is present in the original commit that introduced this driver,\nalthough there, am65_cpsw_nuss_update_tx_rx_chns() existed as\nam65_cpsw_nuss_update_tx_chns().(CVE-2025-21799)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nLoongArch: Fix warnings during S3 suspend\n\nThe enable_gpe_wakeup() function calls acpi_enable_all_wakeup_gpes(),\nand the later one may call the preempt_schedule_common() function,\nresulting in a thread switch and causing the CPU to be in an interrupt\nenabled state after the enable_gpe_wakeup() function returns, leading\nto the warnings as follow.\n\n[ C0] WARNING: ... at kernel/time/timekeeping.c:845 ktime_get+0xbc/0xc8\n[ C0] ...\n[ C0] Call Trace:\n[ C0] [\u0026lt;90000000002243b4\u0026gt;] show_stack+0x64/0x188\n[ C0] [\u0026lt;900000000164673c\u0026gt;] dump_stack_lvl+0x60/0x88\n[ C0] [\u0026lt;90000000002687e4\u0026gt;] __warn+0x8c/0x148\n[ C0] [\u0026lt;90000000015e9978\u0026gt;] report_bug+0x1c0/0x2b0\n[ C0] [\u0026lt;90000000016478e4\u0026gt;] do_bp+0x204/0x3b8\n[ C0] [\u0026lt;90000000025b1924\u0026gt;] exception_handlers+0x1924/0x10000\n[ C0] [\u0026lt;9000000000343bbc\u0026gt;] ktime_get+0xbc/0xc8\n[ C0] [\u0026lt;9000000000354c08\u0026gt;] tick_sched_timer+0x30/0xb0\n[ C0] [\u0026lt;90000000003408e0\u0026gt;] __hrtimer_run_queues+0x160/0x378\n[ C0] [\u0026lt;9000000000341f14\u0026gt;] hrtimer_interrupt+0x144/0x388\n[ C0] [\u0026lt;9000000000228348\u0026gt;] constant_timer_interrupt+0x38/0x48\n[ C0] [\u0026lt;90000000002feba4\u0026gt;] __handle_irq_event_percpu+0x64/0x1e8\n[ C0] [\u0026lt;90000000002fed48\u0026gt;] handle_irq_event_percpu+0x20/0x80\n[ C0] [\u0026lt;9000000000306b9c\u0026gt;] handle_percpu_irq+0x5c/0x98\n[ C0] [\u0026lt;90000000002fd4a0\u0026gt;] generic_handle_domain_irq+0x30/0x48\n[ C0] [\u0026lt;9000000000d0c7b0\u0026gt;] handle_cpu_irq+0x70/0xa8\n[ C0] [\u0026lt;9000000001646b30\u0026gt;] handle_loongarch_irq+0x30/0x48\n[ C0] [\u0026lt;9000000001646bc8\u0026gt;] do_vint+0x80/0xe0\n[ C0] [\u0026lt;90000000002aea1c\u0026gt;] finish_task_switch.isra.0+0x8c/0x2a8\n[ C0] [\u0026lt;900000000164e34c\u0026gt;] __schedule+0x314/0xa48\n[ C0] [\u0026lt;900000000164ead8\u0026gt;] schedule+0x58/0xf0\n[ C0] [\u0026lt;9000000000294a2c\u0026gt;] worker_thread+0x224/0x498\n[ C0] [\u0026lt;900000000029d2f0\u0026gt;] kthread+0xf8/0x108\n[ C0] [\u0026lt;9000000000221f28\u0026gt;] ret_from_kernel_thread+0xc/0xa4\n[ C0]\n[ C0] ---[ end trace 0000000000000000 ]---\n\nThe root cause is acpi_enable_all_wakeup_gpes() uses a mutex to protect\nacpi_hw_enable_all_wakeup_gpes(), and acpi_ut_acquire_mutex() may cause\na thread switch. Since there is no longer concurrent execution during\nloongarch_acpi_suspend(), we can call acpi_hw_enable_all_wakeup_gpes()\ndirectly in enable_gpe_wakeup().\n\nThe solution is similar to commit 22db06337f590d01 (\u0026quot;ACPI: sleep: Avoid\nbreaking S3 wakeup due to might_sleep()\u0026quot;).(CVE-2025-21803)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nPCI: rcar-ep: Fix incorrect variable used when calling devm_request_mem_region()\n\nThe rcar_pcie_parse_outbound_ranges() uses the devm_request_mem_region()\nmacro to request a needed resource. A string variable that lives on the\nstack is then used to store a dynamically computed resource name, which\nis then passed on as one of the macro arguments. This can lead to\nundefined behavior.\n\nDepending on the current contents of the memory, the manifestations of\nerrors may vary. One possible output may be as follows:\n\n $ cat /proc/iomem\n 30000000-37ffffff :\n 38000000-3fffffff :\n\nSometimes, garbage may appear after the colon.\n\nIn very rare cases, if no NULL-terminator is found in memory, the system\nmight crash because the string iterator will overrun which can lead to\naccess of unmapped memory above the stack.\n\nThus, fix this by replacing outbound_name with the name of the previously\nrequested resource. With the changes applied, the output will be as\nfollows:\n\n $ cat /proc/iomem\n 30000000-37ffffff : memory2\n 38000000-3fffffff : memory3\n\n[kwilczynski: commit log](CVE-2025-21804)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: let net.core.dev_weight always be non-zero\n\nThe following problem was encountered during stability test:\n\n(NULL net_device): NAPI poll function process_backlog+0x0/0x530 \\\n\treturned 1, exceeding its budget of 0.\n------------[ cut here ]------------\nlist_add double add: new=ffff88905f746f48, prev=ffff88905f746f48, \\\n\tnext=ffff88905f746e40.\nWARNING: CPU: 18 PID: 5462 at lib/list_debug.c:35 \\\n\t__list_add_valid_or_report+0xf3/0x130\nCPU: 18 UID: 0 PID: 5462 Comm: ping Kdump: loaded Not tainted 6.13.0-rc7+\nRIP: 0010:__list_add_valid_or_report+0xf3/0x130\nCall Trace:\n? __warn+0xcd/0x250\n? __list_add_valid_or_report+0xf3/0x130\nenqueue_to_backlog+0x923/0x1070\nnetif_rx_internal+0x92/0x2b0\n__netif_rx+0x15/0x170\nloopback_xmit+0x2ef/0x450\ndev_hard_start_xmit+0x103/0x490\n__dev_queue_xmit+0xeac/0x1950\nip_finish_output2+0x6cc/0x1620\nip_output+0x161/0x270\nip_push_pending_frames+0x155/0x1a0\nraw_sendmsg+0xe13/0x1550\n__sys_sendto+0x3bf/0x4e0\n__x64_sys_sendto+0xdc/0x1b0\ndo_syscall_64+0x5b/0x170\nentry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nThe reproduction command is as follows:\n sysctl -w net.core.dev_weight=0\n ping 127.0.0.1\n\nThis is because when the napi\u0026apos;s weight is set to 0, process_backlog() may\nreturn 0 and clear the NAPI_STATE_SCHED bit of napi-\u0026gt;state, causing this\nnapi to be re-polled in net_rx_action() until __do_softirq() times out.\nSince the NAPI_STATE_SCHED bit has been cleared, napi_schedule_rps() can\nbe retriggered in enqueue_to_backlog(), causing this issue.\n\nMaking the napi\u0026apos;s weight always non-zero solves this problem.\n\nTriggering this issue requires system-wide admin (setting is\nnot namespaced).(CVE-2025-21806)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: xdp: Disallow attaching device-bound programs in generic mode\n\nDevice-bound programs are used to support RX metadata kfuncs. These\nkfuncs are driver-specific and rely on the driver context to read the\nmetadata. This means they can\u0026apos;t work in generic XDP mode. However, there\nis no check to disallow such programs from being attached in generic\nmode, in which case the metadata kfuncs will be called in an invalid\ncontext, leading to crashes.\n\nFix this by adding a check to disallow attaching device-bound programs\nin generic mode.(CVE-2025-21808)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndriver core: class: Fix wild pointer dereferences in API class_dev_iter_next()\n\nThere are a potential wild pointer dereferences issue regarding APIs\nclass_dev_iter_(init|next|exit)(), as explained by below typical usage:\n\n// All members of @iter are wild pointers.\nstruct class_dev_iter iter;\n\n// class_dev_iter_init(@iter, @class, ...) checks parameter @class for\n// potential class_to_subsys() error, and it returns void type and does\n// not initialize its output parameter @iter, so caller can not detect\n// the error and continues to invoke class_dev_iter_next(@iter) even if\n// @iter still contains wild pointers.\nclass_dev_iter_init(\u0026amp;iter, ...);\n\n// Dereference these wild pointers in @iter here once suffer the error.\nwhile (dev = class_dev_iter_next(\u0026amp;iter)) { ... };\n\n// Also dereference these wild pointers here.\nclass_dev_iter_exit(\u0026amp;iter);\n\nActually, all callers of these APIs have such usage pattern in kernel tree.\nFix by:\n- Initialize output parameter @iter by memset() in class_dev_iter_init()\n and give callers prompt by pr_crit() for the error.\n- Check if @iter is valid in class_dev_iter_next().(CVE-2025-21810)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnilfs2: protect access to buffers with no active references\n\nnilfs_lookup_dirty_data_buffers(), which iterates through the buffers\nattached to dirty data folios/pages, accesses the attached buffers without\nlocking the folios/pages.\n\nFor data cache, nilfs_clear_folio_dirty() may be called asynchronously\nwhen the file system degenerates to read only, so\nnilfs_lookup_dirty_data_buffers() still has the potential to cause use\nafter free issues when buffers lose the protection of their dirty state\nmidway due to this asynchronous clearing and are unintentionally freed by\ntry_to_free_buffers().\n\nEliminate this race issue by adjusting the lock section in this function.(CVE-2025-21811)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nax25: rcu protect dev-\u0026gt;ax25_ptr\n\nsyzbot found a lockdep issue [1].\n\nWe should remove ax25 RTNL dependency in ax25_setsockopt()\n\nThis should also fix a variety of possible UAF in ax25.\n\n[1]\n\nWARNING: possible circular locking dependency detected\n6.13.0-rc3-syzkaller-00762-g9268abe611b0 #0 Not tainted\n------------------------------------------------------\nsyz.5.1818/12806 is trying to acquire lock:\n ffffffff8fcb3988 (rtnl_mutex){+.+.}-{4:4}, at: ax25_setsockopt+0xa55/0xe90 net/ax25/af_ax25.c:680\n\nbut task is already holding lock:\n ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1618 [inline]\n ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: ax25_setsockopt+0x209/0xe90 net/ax25/af_ax25.c:574\n\nwhich lock already depends on the new lock.\n\nthe existing dependency chain (in reverse order) is:\n\n-\u0026gt; #1 (sk_lock-AF_AX25){+.+.}-{0:0}:\n lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5849\n lock_sock_nested+0x48/0x100 net/core/sock.c:3642\n lock_sock include/net/sock.h:1618 [inline]\n ax25_kill_by_device net/ax25/af_ax25.c:101 [inline]\n ax25_device_event+0x24d/0x580 net/ax25/af_ax25.c:146\n notifier_call_chain+0x1a5/0x3f0 kernel/notifier.c:85\n __dev_notify_flags+0x207/0x400\n dev_change_flags+0xf0/0x1a0 net/core/dev.c:9026\n dev_ifsioc+0x7c8/0xe70 net/core/dev_ioctl.c:563\n dev_ioctl+0x719/0x1340 net/core/dev_ioctl.c:820\n sock_do_ioctl+0x240/0x460 net/socket.c:1234\n sock_ioctl+0x626/0x8e0 net/socket.c:1339\n vfs_ioctl fs/ioctl.c:51 [inline]\n __do_sys_ioctl fs/ioctl.c:906 [inline]\n __se_sys_ioctl+0xf5/0x170 fs/ioctl.c:892\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\n-\u0026gt; #0 (rtnl_mutex){+.+.}-{4:4}:\n check_prev_add kernel/locking/lockdep.c:3161 [inline]\n check_prevs_add kernel/locking/lockdep.c:3280 [inline]\n validate_chain+0x18ef/0x5920 kernel/locking/lockdep.c:3904\n __lock_acquire+0x1397/0x2100 kernel/locking/lockdep.c:5226\n lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5849\n __mutex_lock_common kernel/locking/mutex.c:585 [inline]\n __mutex_lock+0x1ac/0xee0 kernel/locking/mutex.c:735\n ax25_setsockopt+0xa55/0xe90 net/ax25/af_ax25.c:680\n do_sock_setsockopt+0x3af/0x720 net/socket.c:2324\n __sys_setsockopt net/socket.c:2349 [inline]\n __do_sys_setsockopt net/socket.c:2355 [inline]\n __se_sys_setsockopt net/socket.c:2352 [inline]\n __x64_sys_setsockopt+0x1ee/0x280 net/socket.c:2352\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nother info that might help us debug this:\n\n Possible unsafe locking scenario:\n\n CPU0 CPU1\n ---- ----\n lock(sk_lock-AF_AX25);\n lock(rtnl_mutex);\n lock(sk_lock-AF_AX25);\n lock(rtnl_mutex);\n\n *** DEADLOCK ***\n\n1 lock held by syz.5.1818/12806:\n #0: ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1618 [inline]\n #0: ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: ax25_setsockopt+0x209/0xe90 net/ax25/af_ax25.c:574\n\nstack backtrace:\nCPU: 1 UID: 0 PID: 12806 Comm: syz.5.1818 Not tainted 6.13.0-rc3-syzkaller-00762-g9268abe611b0 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120\n print_circular_bug+0x13a/0x1b0 kernel/locking/lockdep.c:2074\n check_noncircular+0x36a/0x4a0 kernel/locking/lockdep.c:2206\n check_prev_add kernel/locking/lockdep.c:3161 [inline]\n check_prevs_add kernel/lockin\n---truncated---(CVE-2025-21812)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mac80211: don\u0026apos;t flush non-uploaded STAs\n\nIf STA state is pre-moved to AUTHORIZED (such as in IBSS\nscenarios) and insertion fails, the station is freed.\nIn this case, the driver never knew about the station,\nso trying to flush it is unexpected and may crash.\n\nCheck if the sta was uploaded to the driver before and\nfix this.(CVE-2025-21828)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: avoid holding freeze_mutex during mmap operation\n\nWe use map-\u0026gt;freeze_mutex to prevent races between map_freeze() and\nmemory mapping BPF map contents with writable permissions. The way we\nnaively do this means we\u0026apos;ll hold freeze_mutex for entire duration of all\nthe mm and VMA manipulations, which is completely unnecessary. This can\npotentially also lead to deadlocks, as reported by syzbot in [0].\n\nSo, instead, hold freeze_mutex only during writeability checks, bump\n(proactively) \u0026quot;write active\u0026quot; count for the map, unlock the mutex and\nproceed with mmap logic. And only if something went wrong during mmap\nlogic, then undo that \u0026quot;write active\u0026quot; counter increment.\n\n [0] https://lore.kernel.org/bpf/678dcbc9.050a0220.303755.0066.GAE@google.com/(CVE-2025-21853)",
"id": "OESA-2025-1339",
"modified": "2026-08-06T11:08:26Z",
"published": "2025-03-29T11:08:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1339"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47143"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47809"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-48881"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53214"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56603"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56606"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56637"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56642"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56648"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56670"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56704"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56783"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56785"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57838"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57876"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57973"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57978"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57986"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57993"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57997"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57998"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58006"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58034"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58051"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58052"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58053"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58054"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58056"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58058"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58061"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58063"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58068"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58071"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58072"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21687"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21705"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21707"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21708"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21710"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21711"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21715"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21716"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21720"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21724"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21725"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21726"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21727"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21728"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21745"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21799"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21803"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21804"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21806"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21808"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21810"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21811"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21812"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21828"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21853"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2024-47143",
"CVE-2024-47809",
"CVE-2024-48881",
"CVE-2024-53214",
"CVE-2024-56603",
"CVE-2024-56606",
"CVE-2024-56637",
"CVE-2024-56642",
"CVE-2024-56648",
"CVE-2024-56670",
"CVE-2024-56704",
"CVE-2024-56783",
"CVE-2024-56785",
"CVE-2024-57838",
"CVE-2024-57876",
"CVE-2024-57973",
"CVE-2024-57978",
"CVE-2024-57986",
"CVE-2024-57993",
"CVE-2024-57997",
"CVE-2024-57998",
"CVE-2024-58006",
"CVE-2024-58034",
"CVE-2024-58051",
"CVE-2024-58052",
"CVE-2024-58053",
"CVE-2024-58054",
"CVE-2024-58056",
"CVE-2024-58058",
"CVE-2024-58061",
"CVE-2024-58063",
"CVE-2024-58068",
"CVE-2024-58071",
"CVE-2024-58072",
"CVE-2025-21687",
"CVE-2025-21705",
"CVE-2025-21707",
"CVE-2025-21708",
"CVE-2025-21710",
"CVE-2025-21711",
"CVE-2025-21715",
"CVE-2025-21716",
"CVE-2025-21720",
"CVE-2025-21724",
"CVE-2025-21725",
"CVE-2025-21726",
"CVE-2025-21727",
"CVE-2025-21728",
"CVE-2025-21745",
"CVE-2025-21799",
"CVE-2025-21803",
"CVE-2025-21804",
"CVE-2025-21806",
"CVE-2025-21808",
"CVE-2025-21810",
"CVE-2025-21811",
"CVE-2025-21812",
"CVE-2025-21828",
"CVE-2025-21853"
]
}
SSA-355557
Vulnerability from csaf_siemens - Published: 2025-08-12 00:00 - Updated: 2026-02-24 00:00SUSE-SU-2025:0202-1
Vulnerability from csaf_suse - Published: 2025-01-21 12:52 - Updated: 2025-01-21 12:52SUSE-SU-2025:0230-1
Vulnerability from csaf_suse - Published: 2025-01-24 10:10 - Updated: 2025-01-24 10:10SUSE-SU-2025:0236-1
Vulnerability from csaf_suse - Published: 2025-01-24 17:02 - Updated: 2025-01-24 17:02SUSE-SU-2025:0289-1
Vulnerability from csaf_suse - Published: 2025-01-29 16:11 - Updated: 2025-01-29 16:11SUSE-SU-2025:0428-1
Vulnerability from csaf_suse - Published: 2025-02-11 10:40 - Updated: 2025-02-11 10:40SUSE-SU-2025:0499-1
Vulnerability from csaf_suse - Published: 2025-02-13 08:14 - Updated: 2025-02-13 08:14Sightings
| 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.