Action not permitted
Modal body text goes here.
Modal Title
Modal Body
CVE-2024-26960 (GCVE-0-2024-26960)
Vulnerability from cvelistv5 – Published: 2024-05-01 05:19 – Updated: 2026-08-05 11:28- CWE-362 - Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')
| Vendor | Product | Version | CPE status | |
|---|---|---|---|---|
| Linux | Linux |
Affected:
7c00bafee87c7bac7ed9eced7c161f8e5332cb4e , < d85c11c97ecf92d47a4b29e3faca714dc1f18d0d
(git)
Affected: 7c00bafee87c7bac7ed9eced7c161f8e5332cb4e , < 2da5568ee222ce0541bfe446a07998f92ed1643e (git) Affected: 7c00bafee87c7bac7ed9eced7c161f8e5332cb4e , < 1ede7f1d7eed1738d1b9333fd1e152ccb450b86a (git) Affected: 7c00bafee87c7bac7ed9eced7c161f8e5332cb4e , < 0f98f6d2fb5fad00f8299b84b85b6bc1b6d7d19a (git) Affected: 7c00bafee87c7bac7ed9eced7c161f8e5332cb4e , < 3ce4c4c653e4e478ecb15d3c88e690f12cbf6b39 (git) Affected: 7c00bafee87c7bac7ed9eced7c161f8e5332cb4e , < 363d17e7f7907c8e27a9e86968af0eaa2301787b (git) Affected: 7c00bafee87c7bac7ed9eced7c161f8e5332cb4e , < 82b1c07a0af603e3c47b906c8e991dc96f01688e (git) |
guessed | |
| Linux | Linux |
Affected:
4.11
Unaffected: 0 , < 4.11 (semver) Unaffected: 5.10.215 , ≤ 5.10.* (semver) Unaffected: 5.15.154 , ≤ 5.15.* (semver) Unaffected: 6.1.84 , ≤ 6.1.* (semver) Unaffected: 6.6.24 , ≤ 6.6.* (semver) Unaffected: 6.7.12 , ≤ 6.7.* (semver) Unaffected: 6.8.3 , ≤ 6.8.* (semver) Unaffected: 6.9 , ≤ * (original_commit_for_fix) |
guessed | |
| linux | linux_kernel |
Affected:
7c00bafee87c , < d85c11c97ecf
(custom)
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* |
||
| linux | linux_kernel |
Affected:
7c00bafee87c , < 2da5568ee222
(custom)
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* |
||
| linux | linux_kernel |
Affected:
7c00bafee87c , < 1ede7f1d7eed
(custom)
cpe:2.3:o:linux:linux_kernel:-:*:*:*:*:*:*:* |
||
| linux | linux_kernel |
Affected:
7c00bafee87c , < 0f98f6d2fb5f
(custom)
cpe:2.3:o:linux:linux_kernel:-:*:*:*:*:*:*:* |
||
| linux | linux_kernel |
Affected:
7c00bafee87c , < 3ce4c4c653e4
(custom)
cpe:2.3:o:linux:linux_kernel:-:*:*:*:*:*:*:* |
||
| linux | linux_kernel |
Affected:
7c00bafee87c , < 363d17e7f790
(custom)
cpe:2.3:o:linux:linux_kernel:-:*:*:*:*:*:*:* |
||
| linux | linux_kernel |
Affected:
7c00bafee87c , < 82b1c07a0af6
(custom)
cpe:2.3:o:linux:linux_kernel:-:*:*:*:*:*:*:* |
||
| linux | linux_kernel |
Unaffected:
5.10.215 , < 5.11
(custom)
cpe:2.3:o:linux:linux_kernel:-:*:*:*:*:*:*:* |
||
| linux | linux_kernel |
Unaffected:
6.1.84 , < 6.2
(custom)
cpe:2.3:o:linux:linux_kernel:-:*:*:*:*:*:*:* |
||
| linux | linux_kernel |
Unaffected:
6.6.24 , < 6.7
(custom)
cpe:2.3:o:linux:linux_kernel:-:*:*:*:*:*:*:* |
||
| linux | linux_kernel |
Unaffected:
6.8.3 , < 6.9
(custom)
cpe:2.3:o:linux:linux_kernel:-:*:*:*:*:*:*:* |
||
| linux | linux_kernel |
Unaffected:
6.9
cpe:2.3:o:linux:linux_kernel:-:*:*:*:*:*:*:* |
||
| linux | linux_kernel |
Unaffected:
0 , < 4.11
(custom)
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* |
||
| linux | linux_kernel |
Affected:
4.11
cpe:2.3:o:linux:linux_kernel:4.11:*:*:*:*:*:*:* |
||
| linux | linux_kernel |
Unaffected:
5.15.154 , < 5.16
(custom)
cpe:2.3:o:linux:linux_kernel:-:*:*:*:*:*:*:* |
||
| linux | linux_kernel |
Unaffected:
6.7.12 , < 6.8
(custom)
cpe:2.3:o:linux:linux_kernel:-:*:*:*:*:*:*:* |
||
| Siemens | SIMATIC S7-1500 TM MFP - GNU/Linux subsystem |
Affected:
0 , < *
(custom)
|
guessed |
{
"containers": {
"adp": [
{
"affected": [
{
"cpes": [
"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unknown",
"product": "linux_kernel",
"vendor": "linux",
"versions": [
{
"lessThan": "d85c11c97ecf",
"status": "affected",
"version": "7c00bafee87c",
"versionType": "custom"
}
]
},
{
"cpes": [
"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unknown",
"product": "linux_kernel",
"vendor": "linux",
"versions": [
{
"lessThan": "2da5568ee222",
"status": "affected",
"version": "7c00bafee87c",
"versionType": "custom"
}
]
},
{
"cpes": [
"cpe:2.3:o:linux:linux_kernel:-:*:*:*:*:*:*:*"
],
"defaultStatus": "unknown",
"product": "linux_kernel",
"vendor": "linux",
"versions": [
{
"lessThan": "1ede7f1d7eed",
"status": "affected",
"version": "7c00bafee87c",
"versionType": "custom"
}
]
},
{
"cpes": [
"cpe:2.3:o:linux:linux_kernel:-:*:*:*:*:*:*:*"
],
"defaultStatus": "unknown",
"product": "linux_kernel",
"vendor": "linux",
"versions": [
{
"lessThan": "0f98f6d2fb5f",
"status": "affected",
"version": "7c00bafee87c",
"versionType": "custom"
}
]
},
{
"cpes": [
"cpe:2.3:o:linux:linux_kernel:-:*:*:*:*:*:*:*"
],
"defaultStatus": "unknown",
"product": "linux_kernel",
"vendor": "linux",
"versions": [
{
"lessThan": "3ce4c4c653e4",
"status": "affected",
"version": "7c00bafee87c",
"versionType": "custom"
}
]
},
{
"cpes": [
"cpe:2.3:o:linux:linux_kernel:-:*:*:*:*:*:*:*"
],
"defaultStatus": "unknown",
"product": "linux_kernel",
"vendor": "linux",
"versions": [
{
"lessThan": "363d17e7f790",
"status": "affected",
"version": "7c00bafee87c",
"versionType": "custom"
}
]
},
{
"cpes": [
"cpe:2.3:o:linux:linux_kernel:-:*:*:*:*:*:*:*"
],
"defaultStatus": "unknown",
"product": "linux_kernel",
"vendor": "linux",
"versions": [
{
"lessThan": "82b1c07a0af6",
"status": "affected",
"version": "7c00bafee87c",
"versionType": "custom"
}
]
},
{
"cpes": [
"cpe:2.3:o:linux:linux_kernel:-:*:*:*:*:*:*:*"
],
"defaultStatus": "unknown",
"product": "linux_kernel",
"vendor": "linux",
"versions": [
{
"lessThan": "5.11",
"status": "unaffected",
"version": "5.10.215",
"versionType": "custom"
}
]
},
{
"cpes": [
"cpe:2.3:o:linux:linux_kernel:-:*:*:*:*:*:*:*"
],
"defaultStatus": "unknown",
"product": "linux_kernel",
"vendor": "linux",
"versions": [
{
"lessThan": "6.2",
"status": "unaffected",
"version": "6.1.84",
"versionType": "custom"
}
]
},
{
"cpes": [
"cpe:2.3:o:linux:linux_kernel:-:*:*:*:*:*:*:*"
],
"defaultStatus": "unknown",
"product": "linux_kernel",
"vendor": "linux",
"versions": [
{
"lessThan": "6.7",
"status": "unaffected",
"version": "6.6.24",
"versionType": "custom"
}
]
},
{
"cpes": [
"cpe:2.3:o:linux:linux_kernel:-:*:*:*:*:*:*:*"
],
"defaultStatus": "unknown",
"product": "linux_kernel",
"vendor": "linux",
"versions": [
{
"lessThan": "6.9",
"status": "unaffected",
"version": "6.8.3",
"versionType": "custom"
}
]
},
{
"cpes": [
"cpe:2.3:o:linux:linux_kernel:-:*:*:*:*:*:*:*"
],
"defaultStatus": "unknown",
"product": "linux_kernel",
"vendor": "linux",
"versions": [
{
"status": "unaffected",
"version": "6.9"
}
]
},
{
"cpes": [
"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unknown",
"product": "linux_kernel",
"vendor": "linux",
"versions": [
{
"lessThan": "4.11",
"status": "unaffected",
"version": "0",
"versionType": "custom"
}
]
},
{
"cpes": [
"cpe:2.3:o:linux:linux_kernel:4.11:*:*:*:*:*:*:*"
],
"defaultStatus": "unknown",
"product": "linux_kernel",
"vendor": "linux",
"versions": [
{
"status": "affected",
"version": "4.11"
}
]
},
{
"cpes": [
"cpe:2.3:o:linux:linux_kernel:-:*:*:*:*:*:*:*"
],
"defaultStatus": "unknown",
"product": "linux_kernel",
"vendor": "linux",
"versions": [
{
"lessThan": "5.16",
"status": "unaffected",
"version": "5.15.154",
"versionType": "custom"
}
]
},
{
"cpes": [
"cpe:2.3:o:linux:linux_kernel:-:*:*:*:*:*:*:*"
],
"defaultStatus": "unknown",
"product": "linux_kernel",
"vendor": "linux",
"versions": [
{
"lessThan": "6.8",
"status": "unaffected",
"version": "6.7.12",
"versionType": "custom"
}
]
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 5.5,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"version": "3.1"
}
},
{
"other": {
"content": {
"id": "CVE-2024-26960",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2025-02-05T21:09:23.358079Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-362",
"description": "CWE-362 Concurrent Execution using Shared Resource with Improper Synchronization (\u0027Race Condition\u0027)",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2025-02-05T21:09:44.704Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
},
{
"providerMetadata": {
"dateUpdated": "2024-08-02T00:21:06.048Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/d85c11c97ecf92d47a4b29e3faca714dc1f18d0d"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/2da5568ee222ce0541bfe446a07998f92ed1643e"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/1ede7f1d7eed1738d1b9333fd1e152ccb450b86a"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/0f98f6d2fb5fad00f8299b84b85b6bc1b6d7d19a"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/3ce4c4c653e4e478ecb15d3c88e690f12cbf6b39"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/363d17e7f7907c8e27a9e86968af0eaa2301787b"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/82b1c07a0af603e3c47b906c8e991dc96f01688e"
},
{
"tags": [
"x_transferred"
],
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"
}
],
"title": "CVE Program Container"
},
{
"affected": [
{
"defaultStatus": "unknown",
"product": "SIMATIC S7-1500 TM MFP - GNU/Linux subsystem",
"vendor": "Siemens",
"versions": [
{
"lessThan": "*",
"status": "affected",
"version": "0",
"versionType": "custom"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-05-12T11:50:50.097Z",
"orgId": "0b142b55-0307-4c5a-b3c9-f314f3fb7c5e",
"shortName": "siemens-SADP"
},
"references": [
{
"url": "https://cert-portal.siemens.com/productcert/html/ssa-265688.html"
}
],
"x_adpType": "supplier"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"mm/swapfile.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "d85c11c97ecf92d47a4b29e3faca714dc1f18d0d",
"status": "affected",
"version": "7c00bafee87c7bac7ed9eced7c161f8e5332cb4e",
"versionType": "git"
},
{
"lessThan": "2da5568ee222ce0541bfe446a07998f92ed1643e",
"status": "affected",
"version": "7c00bafee87c7bac7ed9eced7c161f8e5332cb4e",
"versionType": "git"
},
{
"lessThan": "1ede7f1d7eed1738d1b9333fd1e152ccb450b86a",
"status": "affected",
"version": "7c00bafee87c7bac7ed9eced7c161f8e5332cb4e",
"versionType": "git"
},
{
"lessThan": "0f98f6d2fb5fad00f8299b84b85b6bc1b6d7d19a",
"status": "affected",
"version": "7c00bafee87c7bac7ed9eced7c161f8e5332cb4e",
"versionType": "git"
},
{
"lessThan": "3ce4c4c653e4e478ecb15d3c88e690f12cbf6b39",
"status": "affected",
"version": "7c00bafee87c7bac7ed9eced7c161f8e5332cb4e",
"versionType": "git"
},
{
"lessThan": "363d17e7f7907c8e27a9e86968af0eaa2301787b",
"status": "affected",
"version": "7c00bafee87c7bac7ed9eced7c161f8e5332cb4e",
"versionType": "git"
},
{
"lessThan": "82b1c07a0af603e3c47b906c8e991dc96f01688e",
"status": "affected",
"version": "7c00bafee87c7bac7ed9eced7c161f8e5332cb4e",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"mm/swapfile.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "4.11"
},
{
"lessThan": "4.11",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.215",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.154",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.84",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.24",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.7.*",
"status": "unaffected",
"version": "6.7.12",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.8.*",
"status": "unaffected",
"version": "6.8.3",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.9",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.10.215",
"versionStartIncluding": "4.11",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.15.154",
"versionStartIncluding": "4.11",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.1.84",
"versionStartIncluding": "4.11",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6.24",
"versionStartIncluding": "4.11",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.7.12",
"versionStartIncluding": "4.11",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.8.3",
"versionStartIncluding": "4.11",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.9",
"versionStartIncluding": "4.11",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm: swap: fix race between free_swap_and_cache() and swapoff()\n\nThere was previously a theoretical window where swapoff() could run and\nteardown a swap_info_struct while a call to free_swap_and_cache() was\nrunning in another thread. This could cause, amongst other bad\npossibilities, swap_page_trans_huge_swapped() (called by\nfree_swap_and_cache()) to access the freed memory for swap_map.\n\nThis is a theoretical problem and I haven\u0027t been able to provoke it from a\ntest case. But there has been agreement based on code review that this is\npossible (see link below).\n\nFix it by using get_swap_device()/put_swap_device(), which will stall\nswapoff(). There was an extra check in _swap_info_get() to confirm that\nthe swap entry was not free. This isn\u0027t present in get_swap_device()\nbecause it doesn\u0027t make sense in general due to the race between getting\nthe reference and swapoff. So I\u0027ve added an equivalent check directly in\nfree_swap_and_cache().\n\nDetails of how to provoke one possible issue (thanks to David Hildenbrand\nfor deriving this):\n\n--8\u003c-----\n\n__swap_entry_free() might be the last user and result in\n\"count == SWAP_HAS_CACHE\".\n\nswapoff-\u003etry_to_unuse() will stop as soon as soon as si-\u003einuse_pages==0.\n\nSo the question is: could someone reclaim the folio and turn\nsi-\u003einuse_pages==0, before we completed swap_page_trans_huge_swapped().\n\nImagine the following: 2 MiB folio in the swapcache. Only 2 subpages are\nstill references by swap entries.\n\nProcess 1 still references subpage 0 via swap entry.\nProcess 2 still references subpage 1 via swap entry.\n\nProcess 1 quits. Calls free_swap_and_cache().\n-\u003e count == SWAP_HAS_CACHE\n[then, preempted in the hypervisor etc.]\n\nProcess 2 quits. Calls free_swap_and_cache().\n-\u003e count == SWAP_HAS_CACHE\n\nProcess 2 goes ahead, passes swap_page_trans_huge_swapped(), and calls\n__try_to_reclaim_swap().\n\n__try_to_reclaim_swap()-\u003efolio_free_swap()-\u003edelete_from_swap_cache()-\u003e\nput_swap_folio()-\u003efree_swap_slot()-\u003eswapcache_free_entries()-\u003e\nswap_entry_free()-\u003eswap_range_free()-\u003e\n...\nWRITE_ONCE(si-\u003einuse_pages, si-\u003einuse_pages - nr_entries);\n\nWhat stops swapoff to succeed after process 2 reclaimed the swap cache\nbut before process1 finished its call to swap_page_trans_huge_swapped()?\n\n--8\u003c-----"
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 7,
"baseSeverity": "HIGH",
"vectorString": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"scenarios": [
{
"lang": "en",
"value": "AV:L - The vulnerable path is reached only through local memory-management syscalls \u2014 `munmap`/`exit` (`zap_pte_range` \u2192 mm/memory.c:1636), `madvise(MADV_DONTNEED/MADV_FREE)` (mm/madvise.c:659), and tmpfs truncate/punch-hole (mm/shmem.c:842). No remote or adjacent-network consumer reaches `free_swap_and_cache()`.\nAC:H - The attacker controls only their half of the race; the other half is `swapoff()`, gated by `capable(CAP_SYS_ADMIN)` in the *initial* user namespace (mm/swapfile.c:2411, `capable()` not `ns_capable()`), so it cannot be induced from a user namespace and must be performed by an administrator or system script. Landing the hit additionally requires being preempted inside a sub-microsecond window between `__swap_entry_free()` and `swap_page_trans_huge_swapped()` while a second process reclaims the last swapcache reference \u2014 the author explicitly could not provoke it from a test case.\nPR:L - The attacker-controlled side needs nothing beyond an ordinary unprivileged local account: any process can spin `munmap`/`madvise`/tmpfs-punch loops over swapped-out anonymous pages to drive `free_swap_and_cache()` at high rate. No capability, namespace, or filesystem privilege is required for that half.\nUI:N - No victim is tricked into any action; the required `swapoff()` is routine system activity (systemd swap-unit deactivation, hibernate scripts, Android zram reconfiguration) that occurs without human participation, and that environmental dependency is already accounted for in AC:H rather than counted twice as UI:R.\nS:U - The corruption is confined to kernel data structures within the kernel\u0027s own security authority \u2014 standard local kernel memory corruption / privilege escalation. No VM, hypervisor, or IOMMU boundary is crossed.\nC:H - Use-after-free reads of the vfree\u0027d `swap_map`, the kvfree\u0027d `cluster_info`, and a freed `struct address_space` (XArray walk in `filemap_get_folio()`) can disclose reallocated kernel memory. Additionally, `swapoff`+`swapon` reuses the `swap_info_struct` slot, so the stale `free_swap_and_cache()` corrupts the *new* device\u0027s counts and prematurely frees slots still referenced by other processes, handing a victim\u0027s swapped-out anonymous data to the attacker on swap-in.\nI:H - `lock_cluster()` performs `spin_lock(\u0026ci-\u003elock)` on the kvfree\u0027d `cluster_info` \u2014 for typical swap sizes a kmalloc-slab object \u2014 giving a sprayable use-after-free *write* primitive, and `__try_to_reclaim_swap()` manipulates folio locks/refcounts derived from a freed `address_space`. Combined with silent swap-map count corruption after `swapon` reuse, this is exploitable for control-flow hijack and cross-process data modification.\nA:H - The most likely immediate outcome is a kernel oops \u2014 dereferencing a NULLed `si-\u003eswap_map`, faulting in the unmapped vfree\u0027d vmalloc range, a NULL `swapper_spaces[type]`, or tripping `VM_BUG_ON(count != SWAP_HAS_CACHE)` in `__swap_entry_free_locked()`. Any of these panics the kernel."
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-08-05T11:28:38.708Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/d85c11c97ecf92d47a4b29e3faca714dc1f18d0d"
},
{
"url": "https://git.kernel.org/stable/c/2da5568ee222ce0541bfe446a07998f92ed1643e"
},
{
"url": "https://git.kernel.org/stable/c/1ede7f1d7eed1738d1b9333fd1e152ccb450b86a"
},
{
"url": "https://git.kernel.org/stable/c/0f98f6d2fb5fad00f8299b84b85b6bc1b6d7d19a"
},
{
"url": "https://git.kernel.org/stable/c/3ce4c4c653e4e478ecb15d3c88e690f12cbf6b39"
},
{
"url": "https://git.kernel.org/stable/c/363d17e7f7907c8e27a9e86968af0eaa2301787b"
},
{
"url": "https://git.kernel.org/stable/c/82b1c07a0af603e3c47b906c8e991dc96f01688e"
}
],
"title": "mm: swap: fix race between free_swap_and_cache() and swapoff()",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2024-26960",
"datePublished": "2024-05-01T05:19:12.112Z",
"dateReserved": "2024-02-19T14:20:24.201Z",
"dateUpdated": "2026-08-05T11:28:38.708Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"epss": {
"cve": "CVE-2024-26960",
"date": "2026-09-18",
"epss": "0.00178",
"percentile": "0.0767"
},
"nvd": {
"cve": {
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"mm/swapfile.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "d85c11c97ecf92d47a4b29e3faca714dc1f18d0d",
"status": "affected",
"version": "7c00bafee87c7bac7ed9eced7c161f8e5332cb4e",
"versionType": "git"
},
{
"lessThan": "2da5568ee222ce0541bfe446a07998f92ed1643e",
"status": "affected",
"version": "7c00bafee87c7bac7ed9eced7c161f8e5332cb4e",
"versionType": "git"
},
{
"lessThan": "1ede7f1d7eed1738d1b9333fd1e152ccb450b86a",
"status": "affected",
"version": "7c00bafee87c7bac7ed9eced7c161f8e5332cb4e",
"versionType": "git"
},
{
"lessThan": "0f98f6d2fb5fad00f8299b84b85b6bc1b6d7d19a",
"status": "affected",
"version": "7c00bafee87c7bac7ed9eced7c161f8e5332cb4e",
"versionType": "git"
},
{
"lessThan": "3ce4c4c653e4e478ecb15d3c88e690f12cbf6b39",
"status": "affected",
"version": "7c00bafee87c7bac7ed9eced7c161f8e5332cb4e",
"versionType": "git"
},
{
"lessThan": "363d17e7f7907c8e27a9e86968af0eaa2301787b",
"status": "affected",
"version": "7c00bafee87c7bac7ed9eced7c161f8e5332cb4e",
"versionType": "git"
},
{
"lessThan": "82b1c07a0af603e3c47b906c8e991dc96f01688e",
"status": "affected",
"version": "7c00bafee87c7bac7ed9eced7c161f8e5332cb4e",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"mm/swapfile.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "4.11"
},
{
"lessThan": "4.11",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.215",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.154",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.84",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.24",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.7.*",
"status": "unaffected",
"version": "6.7.12",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.8.*",
"status": "unaffected",
"version": "6.8.3",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.9",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
},
{
"affectedData": [
{
"cpes": [
"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unknown",
"product": "linux_kernel",
"vendor": "linux",
"versions": [
{
"lessThan": "d85c11c97ecf",
"status": "affected",
"version": "7c00bafee87c",
"versionType": "custom"
}
]
},
{
"cpes": [
"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unknown",
"product": "linux_kernel",
"vendor": "linux",
"versions": [
{
"lessThan": "2da5568ee222",
"status": "affected",
"version": "7c00bafee87c",
"versionType": "custom"
}
]
},
{
"cpes": [
"cpe:2.3:o:linux:linux_kernel:-:*:*:*:*:*:*:*"
],
"defaultStatus": "unknown",
"product": "linux_kernel",
"vendor": "linux",
"versions": [
{
"lessThan": "1ede7f1d7eed",
"status": "affected",
"version": "7c00bafee87c",
"versionType": "custom"
}
]
},
{
"cpes": [
"cpe:2.3:o:linux:linux_kernel:-:*:*:*:*:*:*:*"
],
"defaultStatus": "unknown",
"product": "linux_kernel",
"vendor": "linux",
"versions": [
{
"lessThan": "0f98f6d2fb5f",
"status": "affected",
"version": "7c00bafee87c",
"versionType": "custom"
}
]
},
{
"cpes": [
"cpe:2.3:o:linux:linux_kernel:-:*:*:*:*:*:*:*"
],
"defaultStatus": "unknown",
"product": "linux_kernel",
"vendor": "linux",
"versions": [
{
"lessThan": "3ce4c4c653e4",
"status": "affected",
"version": "7c00bafee87c",
"versionType": "custom"
}
]
},
{
"cpes": [
"cpe:2.3:o:linux:linux_kernel:-:*:*:*:*:*:*:*"
],
"defaultStatus": "unknown",
"product": "linux_kernel",
"vendor": "linux",
"versions": [
{
"lessThan": "363d17e7f790",
"status": "affected",
"version": "7c00bafee87c",
"versionType": "custom"
}
]
},
{
"cpes": [
"cpe:2.3:o:linux:linux_kernel:-:*:*:*:*:*:*:*"
],
"defaultStatus": "unknown",
"product": "linux_kernel",
"vendor": "linux",
"versions": [
{
"lessThan": "82b1c07a0af6",
"status": "affected",
"version": "7c00bafee87c",
"versionType": "custom"
}
]
},
{
"cpes": [
"cpe:2.3:o:linux:linux_kernel:-:*:*:*:*:*:*:*"
],
"defaultStatus": "unknown",
"product": "linux_kernel",
"vendor": "linux",
"versions": [
{
"lessThan": "5.11",
"status": "unaffected",
"version": "5.10.215",
"versionType": "custom"
}
]
},
{
"cpes": [
"cpe:2.3:o:linux:linux_kernel:-:*:*:*:*:*:*:*"
],
"defaultStatus": "unknown",
"product": "linux_kernel",
"vendor": "linux",
"versions": [
{
"lessThan": "6.2",
"status": "unaffected",
"version": "6.1.84",
"versionType": "custom"
}
]
},
{
"cpes": [
"cpe:2.3:o:linux:linux_kernel:-:*:*:*:*:*:*:*"
],
"defaultStatus": "unknown",
"product": "linux_kernel",
"vendor": "linux",
"versions": [
{
"lessThan": "6.7",
"status": "unaffected",
"version": "6.6.24",
"versionType": "custom"
}
]
},
{
"cpes": [
"cpe:2.3:o:linux:linux_kernel:-:*:*:*:*:*:*:*"
],
"defaultStatus": "unknown",
"product": "linux_kernel",
"vendor": "linux",
"versions": [
{
"lessThan": "6.9",
"status": "unaffected",
"version": "6.8.3",
"versionType": "custom"
}
]
},
{
"cpes": [
"cpe:2.3:o:linux:linux_kernel:-:*:*:*:*:*:*:*"
],
"defaultStatus": "unknown",
"product": "linux_kernel",
"vendor": "linux",
"versions": [
{
"status": "unaffected",
"version": "6.9"
}
]
},
{
"cpes": [
"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unknown",
"product": "linux_kernel",
"vendor": "linux",
"versions": [
{
"lessThan": "4.11",
"status": "unaffected",
"version": "0",
"versionType": "custom"
}
]
},
{
"cpes": [
"cpe:2.3:o:linux:linux_kernel:4.11:*:*:*:*:*:*:*"
],
"defaultStatus": "unknown",
"product": "linux_kernel",
"vendor": "linux",
"versions": [
{
"status": "affected",
"version": "4.11"
}
]
},
{
"cpes": [
"cpe:2.3:o:linux:linux_kernel:-:*:*:*:*:*:*:*"
],
"defaultStatus": "unknown",
"product": "linux_kernel",
"vendor": "linux",
"versions": [
{
"lessThan": "5.16",
"status": "unaffected",
"version": "5.15.154",
"versionType": "custom"
}
]
},
{
"cpes": [
"cpe:2.3:o:linux:linux_kernel:-:*:*:*:*:*:*:*"
],
"defaultStatus": "unknown",
"product": "linux_kernel",
"vendor": "linux",
"versions": [
{
"lessThan": "6.8",
"status": "unaffected",
"version": "6.7.12",
"versionType": "custom"
}
]
}
],
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0"
},
{
"affectedData": [
{
"defaultStatus": "unknown",
"product": "SIMATIC S7-1500 TM MFP - GNU/Linux subsystem",
"vendor": "Siemens",
"versions": [
{
"lessThan": "*",
"status": "affected",
"version": "0",
"versionType": "custom"
}
]
}
],
"source": "0b142b55-0307-4c5a-b3c9-f314f3fb7c5e"
}
],
"configurations": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "C0958525-A5AB-4D52-BD1F-3138F23DCF13",
"versionEndExcluding": "5.10.215",
"versionStartIncluding": "4.11",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "577E212E-7E95-4A71-9B5C-F1D1A3AFFF46",
"versionEndExcluding": "5.15.154",
"versionStartIncluding": "5.11",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "834D9BD5-42A6-4D74-979E-4D6D93F630FD",
"versionEndExcluding": "6.1.84",
"versionStartIncluding": "5.16",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "8018C1D0-0A5F-48D0-BC72-A2B33FDDA693",
"versionEndExcluding": "6.6.24",
"versionStartIncluding": "6.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "6BE9771A-BAFD-4624-95F9-58D536540C53",
"versionEndExcluding": "6.7.12",
"versionStartIncluding": "6.7",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "4C59BBC3-6495-4A77-9C82-55EC7CDF5E02",
"versionEndExcluding": "6.8.3",
"versionStartIncluding": "6.8",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
},
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:debian:debian_linux:10.0:*:*:*:*:*:*:*",
"matchCriteriaId": "07B237A9-69A3-4A9C-9DA0-4E06BD37AE73",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm: swap: fix race between free_swap_and_cache() and swapoff()\n\nThere was previously a theoretical window where swapoff() could run and\nteardown a swap_info_struct while a call to free_swap_and_cache() was\nrunning in another thread. This could cause, amongst other bad\npossibilities, swap_page_trans_huge_swapped() (called by\nfree_swap_and_cache()) to access the freed memory for swap_map.\n\nThis is a theoretical problem and I haven\u0027t been able to provoke it from a\ntest case. But there has been agreement based on code review that this is\npossible (see link below).\n\nFix it by using get_swap_device()/put_swap_device(), which will stall\nswapoff(). There was an extra check in _swap_info_get() to confirm that\nthe swap entry was not free. This isn\u0027t present in get_swap_device()\nbecause it doesn\u0027t make sense in general due to the race between getting\nthe reference and swapoff. So I\u0027ve added an equivalent check directly in\nfree_swap_and_cache().\n\nDetails of how to provoke one possible issue (thanks to David Hildenbrand\nfor deriving this):\n\n--8\u003c-----\n\n__swap_entry_free() might be the last user and result in\n\"count == SWAP_HAS_CACHE\".\n\nswapoff-\u003etry_to_unuse() will stop as soon as soon as si-\u003einuse_pages==0.\n\nSo the question is: could someone reclaim the folio and turn\nsi-\u003einuse_pages==0, before we completed swap_page_trans_huge_swapped().\n\nImagine the following: 2 MiB folio in the swapcache. Only 2 subpages are\nstill references by swap entries.\n\nProcess 1 still references subpage 0 via swap entry.\nProcess 2 still references subpage 1 via swap entry.\n\nProcess 1 quits. Calls free_swap_and_cache().\n-\u003e count == SWAP_HAS_CACHE\n[then, preempted in the hypervisor etc.]\n\nProcess 2 quits. Calls free_swap_and_cache().\n-\u003e count == SWAP_HAS_CACHE\n\nProcess 2 goes ahead, passes swap_page_trans_huge_swapped(), and calls\n__try_to_reclaim_swap().\n\n__try_to_reclaim_swap()-\u003efolio_free_swap()-\u003edelete_from_swap_cache()-\u003e\nput_swap_folio()-\u003efree_swap_slot()-\u003eswapcache_free_entries()-\u003e\nswap_entry_free()-\u003eswap_range_free()-\u003e\n...\nWRITE_ONCE(si-\u003einuse_pages, si-\u003einuse_pages - nr_entries);\n\nWhat stops swapoff to succeed after process 2 reclaimed the swap cache\nbut before process1 finished its call to swap_page_trans_huge_swapped()?\n\n--8\u003c-----"
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm: swap: corrige la ejecuci\u00f3n entre free_swap_and_cache() y swapoff() Anteriormente exist\u00eda una ventana te\u00f3rica donde swapoff() pod\u00eda ejecutar y desmantelar un swap_info_struct mientras se realizaba una llamada a free_swap_and_cache(). corriendo en otro hilo. Esto podr\u00eda causar, entre otras malas posibilidades, que swap_page_trans_huge_swapped() (llamado por free_swap_and_cache()) acceda a la memoria liberada para swap_map. Este es un problema te\u00f3rico y no he podido provocarlo a partir de un caso de prueba. Pero ha habido un acuerdo basado en la revisi\u00f3n del c\u00f3digo de que esto es posible (ver enlace a continuaci\u00f3n). Solucionarlo usando get_swap_device()/put_swap_device(), lo que detendr\u00e1 swapoff(). Hubo una verificaci\u00f3n adicional en _swap_info_get() para confirmar que la entrada de intercambio no era gratuita. Esto no est\u00e1 presente en get_swap_device() porque en general no tiene sentido debido a la ejecuci\u00f3n entre obtener la referencia y el intercambio. As\u00ed que agregu\u00e9 una verificaci\u00f3n equivalente directamente en free_swap_and_cache(). Detalles de c\u00f3mo provocar un posible problema (gracias a David Hildenbrand por derivar esto): --8\u0026lt;----- __swap_entry_free() podr\u00eda ser el \u00faltimo usuario y dar como resultado \"count == SWAP_HAS_CACHE\". swapoff-\u0026gt;try_to_unuse() se detendr\u00e1 tan pronto como si-\u0026gt;inuse_pages==0. Entonces la pregunta es: \u00bfalguien podr\u00eda reclamar la publicaci\u00f3n y activar si-\u0026gt;inuse_pages==0, antes de que completemos swap_page_trans_huge_swapped()? Imagine lo siguiente: folio de 2 MiB en el swapcache. S\u00f3lo 2 subp\u00e1ginas siguen siendo referencias mediante entradas de intercambio. El proceso 1 todav\u00eda hace referencia a la subp\u00e1gina 0 mediante la entrada de intercambio. El proceso 2 todav\u00eda hace referencia a la subp\u00e1gina 1 mediante la entrada de intercambio. El proceso 1 se cierra. Llama a free_swap_and_cache(). -\u0026gt; count == SWAP_HAS_CACHE [luego, adelantado en el hipervisor, etc.] El proceso 2 se cierra. Llama a free_swap_and_cache(). -\u0026gt; count == SWAP_HAS_CACHE El proceso 2 contin\u00faa, pasa swap_page_trans_huge_swapped() y llama a __try_to_reclaim_swap(). __try_to_reclaim_swap()-\u0026gt;folio_free_swap()-\u0026gt;delete_from_swap_cache()-\u0026gt; put_swap_folio()-\u0026gt;free_swap_slot()-\u0026gt;swapcache_free_entries()-\u0026gt; swap_entry_free()-\u0026gt;swap_range_free()-\u0026gt; ... WRITE_ONCE(si-\u0026gt;inuse_pages, si-\u0026gt;inuse_pages - nr_entries); \u00bfQu\u00e9 impide que el intercambio tenga \u00e9xito despu\u00e9s de que el proceso 2 recuper\u00f3 el cach\u00e9 de intercambio pero antes de que el proceso 1 terminara su llamada a swap_page_trans_huge_swapped()? --8\u0026lt;-----"
}
],
"id": "CVE-2024-26960",
"lastModified": "2026-08-04T11:17:27.080",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "HIGH",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 7.0,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.0,
"impactScore": 5.9,
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"type": "Secondary"
},
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 5.5,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 3.6,
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"type": "Secondary"
}
],
"ssvcV203": [
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"ssvcData": {
"id": "CVE-2024-26960",
"options": [
{
"exploitation": "none"
},
{
"automatable": "no"
},
{
"technicalImpact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2025-02-05T21:09:23.358079Z",
"version": "2.0.3"
}
}
]
},
"published": "2024-05-01T06:15:12.323",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/0f98f6d2fb5fad00f8299b84b85b6bc1b6d7d19a"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/1ede7f1d7eed1738d1b9333fd1e152ccb450b86a"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/2da5568ee222ce0541bfe446a07998f92ed1643e"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/363d17e7f7907c8e27a9e86968af0eaa2301787b"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/3ce4c4c653e4e478ecb15d3c88e690f12cbf6b39"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/82b1c07a0af603e3c47b906c8e991dc96f01688e"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/d85c11c97ecf92d47a4b29e3faca714dc1f18d0d"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/0f98f6d2fb5fad00f8299b84b85b6bc1b6d7d19a"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/1ede7f1d7eed1738d1b9333fd1e152ccb450b86a"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/2da5568ee222ce0541bfe446a07998f92ed1643e"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/363d17e7f7907c8e27a9e86968af0eaa2301787b"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/3ce4c4c653e4e478ecb15d3c88e690f12cbf6b39"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/82b1c07a0af603e3c47b906c8e991dc96f01688e"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/d85c11c97ecf92d47a4b29e3faca714dc1f18d0d"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Mailing List",
"Third Party Advisory"
],
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"
},
{
"source": "0b142b55-0307-4c5a-b3c9-f314f3fb7c5e",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-265688.html"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Modified",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "CWE-362"
}
],
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"type": "Secondary"
}
]
}
},
"redhat_vex": {
"aggregate_severity": "Low",
"current_release_date": "2026-08-04T22:49:11+00:00",
"cve": "CVE-2024-26960",
"id": "CVE-2024-26960",
"initial_release_date": "2024-05-01T00:00:00+00:00",
"product_status:fixed": "709",
"product_status:known_affected": "64",
"product_status:known_not_affected": "8",
"source": "Red Hat CSAF VEX",
"status": "final",
"title": "kernel: mm: swap: fix race between free_swap_and_cache() and swapoff()",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2024/cve-2024-26960.json",
"version": "3"
},
"vulnrichment": {
"containers": {
"adp": [
{
"providerMetadata": {
"dateUpdated": "2024-08-02T00:21:06.048Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/d85c11c97ecf92d47a4b29e3faca714dc1f18d0d"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/2da5568ee222ce0541bfe446a07998f92ed1643e"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/1ede7f1d7eed1738d1b9333fd1e152ccb450b86a"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/0f98f6d2fb5fad00f8299b84b85b6bc1b6d7d19a"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/3ce4c4c653e4e478ecb15d3c88e690f12cbf6b39"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/363d17e7f7907c8e27a9e86968af0eaa2301787b"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/82b1c07a0af603e3c47b906c8e991dc96f01688e"
},
{
"tags": [
"x_transferred"
],
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"
}
],
"title": "CVE Program Container"
},
{
"affected": [
{
"defaultStatus": "unknown",
"product": "SIMATIC S7-1500 TM MFP - GNU/Linux subsystem",
"vendor": "Siemens",
"versions": [
{
"lessThan": "*",
"status": "affected",
"version": "0",
"versionType": "custom"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-05-12T11:50:50.097Z",
"orgId": "0b142b55-0307-4c5a-b3c9-f314f3fb7c5e",
"shortName": "siemens-SADP"
},
"references": [
{
"url": "https://cert-portal.siemens.com/productcert/html/ssa-265688.html"
}
],
"x_adpType": "supplier"
},
{
"affected": [
{
"cpes": [
"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unknown",
"product": "linux_kernel",
"vendor": "linux",
"versions": [
{
"lessThan": "d85c11c97ecf",
"status": "affected",
"version": "7c00bafee87c",
"versionType": "custom"
}
]
},
{
"cpes": [
"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unknown",
"product": "linux_kernel",
"vendor": "linux",
"versions": [
{
"lessThan": "2da5568ee222",
"status": "affected",
"version": "7c00bafee87c",
"versionType": "custom"
}
]
},
{
"cpes": [
"cpe:2.3:o:linux:linux_kernel:-:*:*:*:*:*:*:*"
],
"defaultStatus": "unknown",
"product": "linux_kernel",
"vendor": "linux",
"versions": [
{
"lessThan": "1ede7f1d7eed",
"status": "affected",
"version": "7c00bafee87c",
"versionType": "custom"
}
]
},
{
"cpes": [
"cpe:2.3:o:linux:linux_kernel:-:*:*:*:*:*:*:*"
],
"defaultStatus": "unknown",
"product": "linux_kernel",
"vendor": "linux",
"versions": [
{
"lessThan": "0f98f6d2fb5f",
"status": "affected",
"version": "7c00bafee87c",
"versionType": "custom"
}
]
},
{
"cpes": [
"cpe:2.3:o:linux:linux_kernel:-:*:*:*:*:*:*:*"
],
"defaultStatus": "unknown",
"product": "linux_kernel",
"vendor": "linux",
"versions": [
{
"lessThan": "3ce4c4c653e4",
"status": "affected",
"version": "7c00bafee87c",
"versionType": "custom"
}
]
},
{
"cpes": [
"cpe:2.3:o:linux:linux_kernel:-:*:*:*:*:*:*:*"
],
"defaultStatus": "unknown",
"product": "linux_kernel",
"vendor": "linux",
"versions": [
{
"lessThan": "363d17e7f790",
"status": "affected",
"version": "7c00bafee87c",
"versionType": "custom"
}
]
},
{
"cpes": [
"cpe:2.3:o:linux:linux_kernel:-:*:*:*:*:*:*:*"
],
"defaultStatus": "unknown",
"product": "linux_kernel",
"vendor": "linux",
"versions": [
{
"lessThan": "82b1c07a0af6",
"status": "affected",
"version": "7c00bafee87c",
"versionType": "custom"
}
]
},
{
"cpes": [
"cpe:2.3:o:linux:linux_kernel:-:*:*:*:*:*:*:*"
],
"defaultStatus": "unknown",
"product": "linux_kernel",
"vendor": "linux",
"versions": [
{
"lessThan": "5.11",
"status": "unaffected",
"version": "5.10.215",
"versionType": "custom"
}
]
},
{
"cpes": [
"cpe:2.3:o:linux:linux_kernel:-:*:*:*:*:*:*:*"
],
"defaultStatus": "unknown",
"product": "linux_kernel",
"vendor": "linux",
"versions": [
{
"lessThan": "6.2",
"status": "unaffected",
"version": "6.1.84",
"versionType": "custom"
}
]
},
{
"cpes": [
"cpe:2.3:o:linux:linux_kernel:-:*:*:*:*:*:*:*"
],
"defaultStatus": "unknown",
"product": "linux_kernel",
"vendor": "linux",
"versions": [
{
"lessThan": "6.7",
"status": "unaffected",
"version": "6.6.24",
"versionType": "custom"
}
]
},
{
"cpes": [
"cpe:2.3:o:linux:linux_kernel:-:*:*:*:*:*:*:*"
],
"defaultStatus": "unknown",
"product": "linux_kernel",
"vendor": "linux",
"versions": [
{
"lessThan": "6.9",
"status": "unaffected",
"version": "6.8.3",
"versionType": "custom"
}
]
},
{
"cpes": [
"cpe:2.3:o:linux:linux_kernel:-:*:*:*:*:*:*:*"
],
"defaultStatus": "unknown",
"product": "linux_kernel",
"vendor": "linux",
"versions": [
{
"status": "unaffected",
"version": "6.9"
}
]
},
{
"cpes": [
"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unknown",
"product": "linux_kernel",
"vendor": "linux",
"versions": [
{
"lessThan": "4.11",
"status": "unaffected",
"version": "0",
"versionType": "custom"
}
]
},
{
"cpes": [
"cpe:2.3:o:linux:linux_kernel:4.11:*:*:*:*:*:*:*"
],
"defaultStatus": "unknown",
"product": "linux_kernel",
"vendor": "linux",
"versions": [
{
"status": "affected",
"version": "4.11"
}
]
},
{
"cpes": [
"cpe:2.3:o:linux:linux_kernel:-:*:*:*:*:*:*:*"
],
"defaultStatus": "unknown",
"product": "linux_kernel",
"vendor": "linux",
"versions": [
{
"lessThan": "5.16",
"status": "unaffected",
"version": "5.15.154",
"versionType": "custom"
}
]
},
{
"cpes": [
"cpe:2.3:o:linux:linux_kernel:-:*:*:*:*:*:*:*"
],
"defaultStatus": "unknown",
"product": "linux_kernel",
"vendor": "linux",
"versions": [
{
"lessThan": "6.8",
"status": "unaffected",
"version": "6.7.12",
"versionType": "custom"
}
]
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 5.5,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"version": "3.1"
}
},
{
"other": {
"content": {
"id": "CVE-2024-26960",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2025-02-05T21:09:23.358079Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-362",
"description": "CWE-362 Concurrent Execution using Shared Resource with Improper Synchronization (\u0027Race Condition\u0027)",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2024-05-21T18:26:00.252Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"mm/swapfile.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "d85c11c97ecf92d47a4b29e3faca714dc1f18d0d",
"status": "affected",
"version": "7c00bafee87c7bac7ed9eced7c161f8e5332cb4e",
"versionType": "git"
},
{
"lessThan": "2da5568ee222ce0541bfe446a07998f92ed1643e",
"status": "affected",
"version": "7c00bafee87c7bac7ed9eced7c161f8e5332cb4e",
"versionType": "git"
},
{
"lessThan": "1ede7f1d7eed1738d1b9333fd1e152ccb450b86a",
"status": "affected",
"version": "7c00bafee87c7bac7ed9eced7c161f8e5332cb4e",
"versionType": "git"
},
{
"lessThan": "0f98f6d2fb5fad00f8299b84b85b6bc1b6d7d19a",
"status": "affected",
"version": "7c00bafee87c7bac7ed9eced7c161f8e5332cb4e",
"versionType": "git"
},
{
"lessThan": "3ce4c4c653e4e478ecb15d3c88e690f12cbf6b39",
"status": "affected",
"version": "7c00bafee87c7bac7ed9eced7c161f8e5332cb4e",
"versionType": "git"
},
{
"lessThan": "363d17e7f7907c8e27a9e86968af0eaa2301787b",
"status": "affected",
"version": "7c00bafee87c7bac7ed9eced7c161f8e5332cb4e",
"versionType": "git"
},
{
"lessThan": "82b1c07a0af603e3c47b906c8e991dc96f01688e",
"status": "affected",
"version": "7c00bafee87c7bac7ed9eced7c161f8e5332cb4e",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"mm/swapfile.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "4.11"
},
{
"lessThan": "4.11",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.215",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.154",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.84",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.24",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.7.*",
"status": "unaffected",
"version": "6.7.12",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.8.*",
"status": "unaffected",
"version": "6.8.3",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.9",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.10.215",
"versionStartIncluding": "4.11",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.15.154",
"versionStartIncluding": "4.11",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.1.84",
"versionStartIncluding": "4.11",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6.24",
"versionStartIncluding": "4.11",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.7.12",
"versionStartIncluding": "4.11",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.8.3",
"versionStartIncluding": "4.11",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.9",
"versionStartIncluding": "4.11",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm: swap: fix race between free_swap_and_cache() and swapoff()\n\nThere was previously a theoretical window where swapoff() could run and\nteardown a swap_info_struct while a call to free_swap_and_cache() was\nrunning in another thread. This could cause, amongst other bad\npossibilities, swap_page_trans_huge_swapped() (called by\nfree_swap_and_cache()) to access the freed memory for swap_map.\n\nThis is a theoretical problem and I haven\u0027t been able to provoke it from a\ntest case. But there has been agreement based on code review that this is\npossible (see link below).\n\nFix it by using get_swap_device()/put_swap_device(), which will stall\nswapoff(). There was an extra check in _swap_info_get() to confirm that\nthe swap entry was not free. This isn\u0027t present in get_swap_device()\nbecause it doesn\u0027t make sense in general due to the race between getting\nthe reference and swapoff. So I\u0027ve added an equivalent check directly in\nfree_swap_and_cache().\n\nDetails of how to provoke one possible issue (thanks to David Hildenbrand\nfor deriving this):\n\n--8\u003c-----\n\n__swap_entry_free() might be the last user and result in\n\"count == SWAP_HAS_CACHE\".\n\nswapoff-\u003etry_to_unuse() will stop as soon as soon as si-\u003einuse_pages==0.\n\nSo the question is: could someone reclaim the folio and turn\nsi-\u003einuse_pages==0, before we completed swap_page_trans_huge_swapped().\n\nImagine the following: 2 MiB folio in the swapcache. Only 2 subpages are\nstill references by swap entries.\n\nProcess 1 still references subpage 0 via swap entry.\nProcess 2 still references subpage 1 via swap entry.\n\nProcess 1 quits. Calls free_swap_and_cache().\n-\u003e count == SWAP_HAS_CACHE\n[then, preempted in the hypervisor etc.]\n\nProcess 2 quits. Calls free_swap_and_cache().\n-\u003e count == SWAP_HAS_CACHE\n\nProcess 2 goes ahead, passes swap_page_trans_huge_swapped(), and calls\n__try_to_reclaim_swap().\n\n__try_to_reclaim_swap()-\u003efolio_free_swap()-\u003edelete_from_swap_cache()-\u003e\nput_swap_folio()-\u003efree_swap_slot()-\u003eswapcache_free_entries()-\u003e\nswap_entry_free()-\u003eswap_range_free()-\u003e\n...\nWRITE_ONCE(si-\u003einuse_pages, si-\u003einuse_pages - nr_entries);\n\nWhat stops swapoff to succeed after process 2 reclaimed the swap cache\nbut before process1 finished its call to swap_page_trans_huge_swapped()?\n\n--8\u003c-----"
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 7,
"baseSeverity": "HIGH",
"vectorString": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"scenarios": [
{
"lang": "en",
"value": "AV:L - The vulnerable path is reached only through local memory-management syscalls \u2014 `munmap`/`exit` (`zap_pte_range` \u2192 mm/memory.c:1636), `madvise(MADV_DONTNEED/MADV_FREE)` (mm/madvise.c:659), and tmpfs truncate/punch-hole (mm/shmem.c:842). No remote or adjacent-network consumer reaches `free_swap_and_cache()`.\nAC:H - The attacker controls only their half of the race; the other half is `swapoff()`, gated by `capable(CAP_SYS_ADMIN)` in the *initial* user namespace (mm/swapfile.c:2411, `capable()` not `ns_capable()`), so it cannot be induced from a user namespace and must be performed by an administrator or system script. Landing the hit additionally requires being preempted inside a sub-microsecond window between `__swap_entry_free()` and `swap_page_trans_huge_swapped()` while a second process reclaims the last swapcache reference \u2014 the author explicitly could not provoke it from a test case.\nPR:L - The attacker-controlled side needs nothing beyond an ordinary unprivileged local account: any process can spin `munmap`/`madvise`/tmpfs-punch loops over swapped-out anonymous pages to drive `free_swap_and_cache()` at high rate. No capability, namespace, or filesystem privilege is required for that half.\nUI:N - No victim is tricked into any action; the required `swapoff()` is routine system activity (systemd swap-unit deactivation, hibernate scripts, Android zram reconfiguration) that occurs without human participation, and that environmental dependency is already accounted for in AC:H rather than counted twice as UI:R.\nS:U - The corruption is confined to kernel data structures within the kernel\u0027s own security authority \u2014 standard local kernel memory corruption / privilege escalation. No VM, hypervisor, or IOMMU boundary is crossed.\nC:H - Use-after-free reads of the vfree\u0027d `swap_map`, the kvfree\u0027d `cluster_info`, and a freed `struct address_space` (XArray walk in `filemap_get_folio()`) can disclose reallocated kernel memory. Additionally, `swapoff`+`swapon` reuses the `swap_info_struct` slot, so the stale `free_swap_and_cache()` corrupts the *new* device\u0027s counts and prematurely frees slots still referenced by other processes, handing a victim\u0027s swapped-out anonymous data to the attacker on swap-in.\nI:H - `lock_cluster()` performs `spin_lock(\u0026ci-\u003elock)` on the kvfree\u0027d `cluster_info` \u2014 for typical swap sizes a kmalloc-slab object \u2014 giving a sprayable use-after-free *write* primitive, and `__try_to_reclaim_swap()` manipulates folio locks/refcounts derived from a freed `address_space`. Combined with silent swap-map count corruption after `swapon` reuse, this is exploitable for control-flow hijack and cross-process data modification.\nA:H - The most likely immediate outcome is a kernel oops \u2014 dereferencing a NULLed `si-\u003eswap_map`, faulting in the unmapped vfree\u0027d vmalloc range, a NULL `swapper_spaces[type]`, or tripping `VM_BUG_ON(count != SWAP_HAS_CACHE)` in `__swap_entry_free_locked()`. Any of these panics the kernel."
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-08-05T11:28:38.708Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/d85c11c97ecf92d47a4b29e3faca714dc1f18d0d"
},
{
"url": "https://git.kernel.org/stable/c/2da5568ee222ce0541bfe446a07998f92ed1643e"
},
{
"url": "https://git.kernel.org/stable/c/1ede7f1d7eed1738d1b9333fd1e152ccb450b86a"
},
{
"url": "https://git.kernel.org/stable/c/0f98f6d2fb5fad00f8299b84b85b6bc1b6d7d19a"
},
{
"url": "https://git.kernel.org/stable/c/3ce4c4c653e4e478ecb15d3c88e690f12cbf6b39"
},
{
"url": "https://git.kernel.org/stable/c/363d17e7f7907c8e27a9e86968af0eaa2301787b"
},
{
"url": "https://git.kernel.org/stable/c/82b1c07a0af603e3c47b906c8e991dc96f01688e"
}
],
"title": "mm: swap: fix race between free_swap_and_cache() and swapoff()",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2024-26960",
"datePublished": "2024-05-01T05:19:12.112Z",
"dateReserved": "2024-02-19T14:20:24.201Z",
"dateUpdated": "2026-08-05T11:28:38.708Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
}
}
CERTFR-2026-AVI-1165
Vulnerability from certfr_avis - Published: 2026-09-11 - Updated: 2026-09-11
De multiples vulnérabilités ont été découvertes dans les produits IBM. Certaines d'entre elles permettent à un attaquant de provoquer une exécution de code arbitraire à distance, une élévation de privilèges et un déni de service à distance.
Solutions
Se référer au bulletin de sécurité de l'éditeur pour l'obtention des correctifs (cf. section Documentation).
| Vendor | Product | Description | ||
|---|---|---|---|---|
| IBM | Db2 | Db2 Common Container sans le correctif de sécurité 1159cn3 | ||
| IBM | Informix Dynamic Server | Informix Dynamic Server versions 15.0.x antérieures à 15.0.1.14 | ||
| IBM | QRadar Hub | QRadar Hub versions antérieures à 3.9.1 | ||
| IBM | WebSphere Application Server | WebSphere Application Server Liberty versions antérieures à 26.0.0.10 (disponibilité prévue pour le quatrième trimestre 2026) | ||
| IBM | Informix Dynamic Server | Informix Dynamic Server versions 12.10 antérieures à InformixHQ 3.3.1 | ||
| IBM | Informix Dynamic Server | Informix Dynamic Server versions 14.10.x antérieures à 14.10.xC14 | ||
| IBM | Db2 | Db2 versions V11.5.x sans le correctif de sécurité DT495924, DT474170, DT495462, DT470425 et DT501356 | ||
| IBM | Sterling Partner Engagement Manager Essentials Edition | Sterling Partner Engagement Manager Essentials Edition versions 6.2.4.x antérieures à 6.2.4.5 | ||
| IBM | Db2 | Db2 Bridge versions antérieures à 1.1.5.2 | ||
| IBM | Db2 | Db2 Warehouse on Cloud Pak for Data versions antérieures à v5.4 patch 6 | ||
| IBM | Sterling Partner Engagement Manager Standard Edition | Sterling Partner Engagement Manager Standard Edition versions 6.2.4.x antérieures à 6.2.4.5 | ||
| IBM | Db2 | Db2 Developer Extension versions 1.1.x antérieures à 1.1.2 | ||
| IBM | Sterling Partner Engagement Manager Essentials Edition | Sterling Partner Engagement Manager Essentials Edition versions 6.3.0.x antérieures à 6.3.0.3 | ||
| IBM | Db2 | Db2 on Cloud Pak for Data versions antérieures à v5.4 patch 6 | ||
| IBM | Db2 | Db2 versions V12.1 sans le correctif de sécurité DT495924, DT495462 et DT474170 |
| Title | Publication Time | Tags | ||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||||||||||||||||||||
{
"$ref": "https://www.cert.ssi.gouv.fr/openapi.json",
"affected_systems": [
{
"description": "Db2 Common Container sans le correctif de s\u00e9curit\u00e9 1159cn3",
"product": {
"name": "Db2",
"vendor": {
"name": "IBM",
"scada": false
}
}
},
{
"description": "Informix Dynamic Server versions 15.0.x ant\u00e9rieures \u00e0 15.0.1.14",
"product": {
"name": "Informix Dynamic Server",
"vendor": {
"name": "IBM",
"scada": false
}
}
},
{
"description": "QRadar Hub versions ant\u00e9rieures \u00e0 3.9.1",
"product": {
"name": "QRadar Hub",
"vendor": {
"name": "IBM",
"scada": false
}
}
},
{
"description": "WebSphere Application Server Liberty versions ant\u00e9rieures \u00e0 26.0.0.10 (disponibilit\u00e9 pr\u00e9vue pour le quatri\u00e8me trimestre 2026)",
"product": {
"name": "WebSphere Application Server",
"vendor": {
"name": "IBM",
"scada": false
}
}
},
{
"description": "Informix Dynamic Server versions 12.10 ant\u00e9rieures \u00e0 InformixHQ 3.3.1",
"product": {
"name": "Informix Dynamic Server",
"vendor": {
"name": "IBM",
"scada": false
}
}
},
{
"description": "Informix Dynamic Server versions 14.10.x ant\u00e9rieures \u00e0 14.10.xC14",
"product": {
"name": "Informix Dynamic Server",
"vendor": {
"name": "IBM",
"scada": false
}
}
},
{
"description": "Db2 versions V11.5.x sans le correctif de s\u00e9curit\u00e9 DT495924, DT474170, DT495462, DT470425 et DT501356",
"product": {
"name": "Db2",
"vendor": {
"name": "IBM",
"scada": false
}
}
},
{
"description": "Sterling Partner Engagement Manager Essentials Edition versions 6.2.4.x ant\u00e9rieures \u00e0 6.2.4.5",
"product": {
"name": "Sterling Partner Engagement Manager Essentials Edition",
"vendor": {
"name": "IBM",
"scada": false
}
}
},
{
"description": "Db2 Bridge versions ant\u00e9rieures \u00e0 1.1.5.2",
"product": {
"name": "Db2",
"vendor": {
"name": "IBM",
"scada": false
}
}
},
{
"description": "Db2 Warehouse on Cloud Pak for Data versions ant\u00e9rieures \u00e0 v5.4 patch 6",
"product": {
"name": "Db2",
"vendor": {
"name": "IBM",
"scada": false
}
}
},
{
"description": "Sterling Partner Engagement Manager Standard Edition versions 6.2.4.x ant\u00e9rieures \u00e0 6.2.4.5",
"product": {
"name": "Sterling Partner Engagement Manager Standard Edition",
"vendor": {
"name": "IBM",
"scada": false
}
}
},
{
"description": "Db2 Developer Extension versions 1.1.x ant\u00e9rieures \u00e0 1.1.2",
"product": {
"name": "Db2",
"vendor": {
"name": "IBM",
"scada": false
}
}
},
{
"description": "Sterling Partner Engagement Manager Essentials Edition versions 6.3.0.x ant\u00e9rieures \u00e0 6.3.0.3",
"product": {
"name": "Sterling Partner Engagement Manager Essentials Edition",
"vendor": {
"name": "IBM",
"scada": false
}
}
},
{
"description": "Db2 on Cloud Pak for Data versions ant\u00e9rieures \u00e0 v5.4 patch 6",
"product": {
"name": "Db2",
"vendor": {
"name": "IBM",
"scada": false
}
}
},
{
"description": "Db2 versions V12.1 sans le correctif de s\u00e9curit\u00e9 DT495924, DT495462 et DT474170",
"product": {
"name": "Db2",
"vendor": {
"name": "IBM",
"scada": false
}
}
}
],
"affected_systems_content": "",
"content": "## Solutions\n\nSe r\u00e9f\u00e9rer au bulletin de s\u00e9curit\u00e9 de l\u0027\u00e9diteur pour l\u0027obtention des correctifs (cf. section Documentation).",
"cves": [
{
"name": "CVE-2026-75595",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-75595"
},
{
"name": "CVE-2026-49978",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-49978"
},
{
"name": "CVE-2024-40931",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40931"
},
{
"name": "CVE-2023-52471",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52471"
},
{
"name": "CVE-2026-5588",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-5588"
},
{
"name": "CVE-2021-33036",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-33036"
},
{
"name": "CVE-2021-44906",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-44906"
},
{
"name": "CVE-2026-54264",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-54264"
},
{
"name": "CVE-2024-50142",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50142"
},
{
"name": "CVE-2026-59651",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59651"
},
{
"name": "CVE-2026-45819",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45819"
},
{
"name": "CVE-2024-46826",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46826"
},
{
"name": "CVE-2024-42070",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42070"
},
{
"name": "CVE-2024-36889",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36889"
},
{
"name": "CVE-2023-52675",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52675"
},
{
"name": "CVE-2024-35810",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35810"
},
{
"name": "CVE-2026-50557",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-50557"
},
{
"name": "CVE-2024-41093",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41093"
},
{
"name": "CVE-2026-59295",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59295"
},
{
"name": "CVE-2023-52834",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52834"
},
{
"name": "CVE-2024-38627",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38627"
},
{
"name": "CVE-2023-43642",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-43642"
},
{
"name": "CVE-2021-21409",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-21409"
},
{
"name": "CVE-2023-52622",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52622"
},
{
"name": "CVE-2018-14042",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-14042"
},
{
"name": "CVE-2024-35939",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35939"
},
{
"name": "CVE-2025-2534",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-2534"
},
{
"name": "CVE-2024-38555",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38555"
},
{
"name": "CVE-2024-41009",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41009"
},
{
"name": "CVE-2026-41254",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41254"
},
{
"name": "CVE-2024-36921",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36921"
},
{
"name": "CVE-2024-36939",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36939"
},
{
"name": "CVE-2024-39503",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39503"
},
{
"name": "CVE-2024-26656",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26656"
},
{
"name": "CVE-2024-42246",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42246"
},
{
"name": "CVE-2024-26614",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26614"
},
{
"name": "CVE-2026-16480",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-16480"
},
{
"name": "CVE-2018-1334",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-1334"
},
{
"name": "CVE-2023-52762",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52762"
},
{
"name": "CVE-2024-26974",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26974"
},
{
"name": "CVE-2024-40988",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40988"
},
{
"name": "CVE-2026-32990",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-32990"
},
{
"name": "CVE-2024-26595",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26595"
},
{
"name": "CVE-2026-50645",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-50645"
},
{
"name": "CVE-2026-22610",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22610"
},
{
"name": "CVE-2024-42292",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42292"
},
{
"name": "CVE-2026-42041",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42041"
},
{
"name": "CVE-2014-125087",
"url": "https://www.cve.org/CVERecord?id=CVE-2014-125087"
},
{
"name": "CVE-2026-14686",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-14686"
},
{
"name": "CVE-2026-68763",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68763"
},
{
"name": "CVE-2023-1370",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-1370"
},
{
"name": "CVE-2026-45416",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45416"
},
{
"name": "CVE-2024-36904",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36904"
},
{
"name": "CVE-2023-52845",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52845"
},
{
"name": "CVE-2023-33201",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-33201"
},
{
"name": "CVE-2026-10050",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-10050"
},
{
"name": "CVE-2024-27010",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27010"
},
{
"name": "CVE-2024-42284",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42284"
},
{
"name": "CVE-2024-35912",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35912"
},
{
"name": "CVE-2021-47432",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47432"
},
{
"name": "CVE-2026-53666",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53666"
},
{
"name": "CVE-2024-25739",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-25739"
},
{
"name": "CVE-2026-59648",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59648"
},
{
"name": "CVE-2026-69153",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-69153"
},
{
"name": "CVE-2026-3621",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-3621"
},
{
"name": "CVE-2026-43515",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43515"
},
{
"name": "CVE-2026-42402",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42402"
},
{
"name": "CVE-2021-47304",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47304"
},
{
"name": "CVE-2024-35807",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35807"
},
{
"name": "CVE-2022-48632",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48632"
},
{
"name": "CVE-2026-43868",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43868"
},
{
"name": "CVE-2026-50560",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-50560"
},
{
"name": "CVE-2024-26586",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26586"
},
{
"name": "CVE-2024-41060",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41060"
},
{
"name": "CVE-2015-5237",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-5237"
},
{
"name": "CVE-2026-71290",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-71290"
},
{
"name": "CVE-2019-10099",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-10099"
},
{
"name": "CVE-2024-26585",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26585"
},
{
"name": "CVE-2026-41716",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41716"
},
{
"name": "CVE-2018-11760",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-11760"
},
{
"name": "CVE-2026-15328",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-15328"
},
{
"name": "CVE-2026-59645",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59645"
},
{
"name": "CVE-2022-45688",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-45688"
},
{
"name": "CVE-2024-26961",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26961"
},
{
"name": "CVE-2024-38608",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38608"
},
{
"name": "CVE-2024-23944",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-23944"
},
{
"name": "CVE-2022-33891",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-33891"
},
{
"name": "CVE-2024-50275",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50275"
},
{
"name": "CVE-2026-13006",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-13006"
},
{
"name": "CVE-2024-26638",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26638"
},
{
"name": "CVE-2018-8024",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-8024"
},
{
"name": "CVE-2021-47284",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47284"
},
{
"name": "CVE-2024-27397",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27397"
},
{
"name": "CVE-2024-49350",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49350"
},
{
"name": "CVE-2022-48619",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48619"
},
{
"name": "CVE-2024-46679",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46679"
},
{
"name": "CVE-2025-66412",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-66412"
},
{
"name": "CVE-2025-36131",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-36131"
},
{
"name": "CVE-2024-36945",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36945"
},
{
"name": "CVE-2023-52653",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52653"
},
{
"name": "CVE-2026-54514",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-54514"
},
{
"name": "CVE-2023-52756",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52756"
},
{
"name": "CVE-2024-40924",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40924"
},
{
"name": "CVE-2018-14040",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-14040"
},
{
"name": "CVE-2024-35854",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35854"
},
{
"name": "CVE-2024-28757",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-28757"
},
{
"name": "CVE-2026-77414",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-77414"
},
{
"name": "CVE-2020-11988",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-11988"
},
{
"name": "CVE-2021-46939",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-46939"
},
{
"name": "CVE-2025-56200",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-56200"
},
{
"name": "CVE-2024-37071",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-37071"
},
{
"name": "CVE-2026-77413",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-77413"
},
{
"name": "CVE-2023-52878",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52878"
},
{
"name": "CVE-2026-54399",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-54399"
},
{
"name": "CVE-2026-53668",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53668"
},
{
"name": "CVE-2024-41038",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41038"
},
{
"name": "CVE-2025-30065",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-30065"
},
{
"name": "CVE-2026-16243",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-16243"
},
{
"name": "CVE-2016-4055",
"url": "https://www.cve.org/CVERecord?id=CVE-2016-4055"
},
{
"name": "CVE-2026-9171",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-9171"
},
{
"name": "CVE-2026-67214",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-67214"
},
{
"name": "CVE-2024-37356",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-37356"
},
{
"name": "CVE-2022-48743",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48743"
},
{
"name": "CVE-2024-25638",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-25638"
},
{
"name": "CVE-2026-12185",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-12185"
},
{
"name": "CVE-2026-59921",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59921"
},
{
"name": "CVE-2024-47118",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47118"
},
{
"name": "CVE-2024-35824",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35824"
},
{
"name": "CVE-2026-47010",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47010"
},
{
"name": "CVE-2023-45853",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-45853"
},
{
"name": "CVE-2024-26704",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26704"
},
{
"name": "CVE-2024-35925",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35925"
},
{
"name": "CVE-2023-45288",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-45288"
},
{
"name": "CVE-2024-36886",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36886"
},
{
"name": "CVE-2024-26976",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26976"
},
{
"name": "CVE-2026-14685",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-14685"
},
{
"name": "CVE-2023-52803",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52803"
},
{
"name": "CVE-2023-45178",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-45178"
},
{
"name": "CVE-2026-54171",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-54171"
},
{
"name": "CVE-2024-21823",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-21823"
},
{
"name": "CVE-2022-31160",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-31160"
},
{
"name": "CVE-2021-47441",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47441"
},
{
"name": "CVE-2020-10683",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-10683"
},
{
"name": "CVE-2018-1273",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-1273"
},
{
"name": "CVE-2026-41239",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41239"
},
{
"name": "CVE-2024-26600",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26600"
},
{
"name": "CVE-2026-33814",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-33814"
},
{
"name": "CVE-2023-28746",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-28746"
},
{
"name": "CVE-2026-47891",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47891"
},
{
"name": "CVE-2023-52847",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52847"
},
{
"name": "CVE-2024-42114",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42114"
},
{
"name": "CVE-2020-26945",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-26945"
},
{
"name": "CVE-2023-52864",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52864"
},
{
"name": "CVE-2024-50302",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50302"
},
{
"name": "CVE-2026-68569",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68569"
},
{
"name": "CVE-2026-59084",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59084"
},
{
"name": "CVE-2026-65183",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-65183"
},
{
"name": "CVE-2024-35897",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35897"
},
{
"name": "CVE-2026-14257",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-14257"
},
{
"name": "CVE-2026-41901",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41901"
},
{
"name": "CVE-2026-73088",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-73088"
},
{
"name": "CVE-2023-52478",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52478"
},
{
"name": "CVE-2024-23945",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-23945"
},
{
"name": "CVE-2021-41182",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-41182"
},
{
"name": "CVE-2024-38596",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38596"
},
{
"name": "CVE-2022-25647",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-25647"
},
{
"name": "CVE-2026-9072",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-9072"
},
{
"name": "CVE-2022-26612",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-26612"
},
{
"name": "CVE-2024-36929",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36929"
},
{
"name": "CVE-2024-26802",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26802"
},
{
"name": "CVE-2026-18097",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-18097"
},
{
"name": "CVE-2024-40904",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40904"
},
{
"name": "CVE-2024-42084",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42084"
},
{
"name": "CVE-2021-47455",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47455"
},
{
"name": "CVE-2023-52492",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52492"
},
{
"name": "CVE-2022-36364",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-36364"
},
{
"name": "CVE-2026-73089",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-73089"
},
{
"name": "CVE-2023-34610",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-34610"
},
{
"name": "CVE-2026-47057",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47057"
},
{
"name": "CVE-2024-47561",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47561"
},
{
"name": "CVE-2023-52669",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52669"
},
{
"name": "CVE-2024-36883",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36883"
},
{
"name": "CVE-2024-31881",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-31881"
},
{
"name": "CVE-2019-11358",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-11358"
},
{
"name": "CVE-2026-69152",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-69152"
},
{
"name": "CVE-2024-26665",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26665"
},
{
"name": "CVE-2026-68525",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68525"
},
{
"name": "CVE-2024-27062",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27062"
},
{
"name": "CVE-2026-59901",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59901"
},
{
"name": "CVE-2024-40960",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40960"
},
{
"name": "CVE-2024-35839",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35839"
},
{
"name": "CVE-2024-26852",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26852"
},
{
"name": "CVE-2024-40997",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40997"
},
{
"name": "CVE-2024-27395",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27395"
},
{
"name": "CVE-2026-14525",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-14525"
},
{
"name": "CVE-2026-67313",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-67313"
},
{
"name": "CVE-2020-13955",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-13955"
},
{
"name": "CVE-2024-42154",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42154"
},
{
"name": "CVE-2024-42228",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42228"
},
{
"name": "CVE-2026-8858",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-8858"
},
{
"name": "CVE-2026-42580",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42580"
},
{
"name": "CVE-2021-47352",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47352"
},
{
"name": "CVE-2024-36004",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36004"
},
{
"name": "CVE-2026-41691",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41691"
},
{
"name": "CVE-2024-26921",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26921"
},
{
"name": "CVE-2024-43889",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43889"
},
{
"name": "CVE-2024-35952",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35952"
},
{
"name": "CVE-2024-26859",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26859"
},
{
"name": "CVE-2026-65637",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-65637"
},
{
"name": "CVE-2018-8009",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-8009"
},
{
"name": "CVE-2026-50163",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-50163"
},
{
"name": "CVE-2026-67315",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-67315"
},
{
"name": "CVE-2026-54516",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-54516"
},
{
"name": "CVE-2026-55223",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-55223"
},
{
"name": "CVE-2025-7962",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-7962"
},
{
"name": "CVE-2026-18499",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-18499"
},
{
"name": "CVE-2019-20444",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-20444"
},
{
"name": "CVE-2026-54515",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-54515"
},
{
"name": "CVE-2026-5516",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-5516"
},
{
"name": "CVE-2023-34462",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-34462"
},
{
"name": "CVE-2024-41007",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41007"
},
{
"name": "CVE-2026-41721",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41721"
},
{
"name": "CVE-2018-1313",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-1313"
},
{
"name": "CVE-2026-16221",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-16221"
},
{
"name": "CVE-2023-34454",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-34454"
},
{
"name": "CVE-2024-35814",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35814"
},
{
"name": "CVE-2022-46337",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-46337"
},
{
"name": "CVE-2026-6790",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-6790"
},
{
"name": "CVE-2026-65911",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-65911"
},
{
"name": "CVE-2023-52764",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52764"
},
{
"name": "CVE-2026-18401",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-18401"
},
{
"name": "CVE-2021-35516",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-35516"
},
{
"name": "CVE-2024-26698",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26698"
},
{
"name": "CVE-2024-26686",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26686"
},
{
"name": "CVE-2024-35946",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35946"
},
{
"name": "CVE-2023-44487",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-44487"
},
{
"name": "CVE-2024-29857",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-29857"
},
{
"name": "CVE-2024-35959",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35959"
},
{
"name": "CVE-2024-26645",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26645"
},
{
"name": "CVE-2026-66143",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-66143"
},
{
"name": "CVE-2024-36020",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36020"
},
{
"name": "CVE-2024-42240",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42240"
},
{
"name": "CVE-2026-66144",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-66144"
},
{
"name": "CVE-2024-35962",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35962"
},
{
"name": "CVE-2026-44494",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-44494"
},
{
"name": "CVE-2023-26049",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-26049"
},
{
"name": "CVE-2024-40972",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40972"
},
{
"name": "CVE-2026-42585",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42585"
},
{
"name": "CVE-2024-50192",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50192"
},
{
"name": "CVE-2024-26720",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26720"
},
{
"name": "CVE-2024-35855",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35855"
},
{
"name": "CVE-2024-36917",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36917"
},
{
"name": "CVE-2024-45018",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45018"
},
{
"name": "CVE-2026-12860",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-12860"
},
{
"name": "CVE-2026-10571",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-10571"
},
{
"name": "CVE-2024-34447",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-34447"
},
{
"name": "CVE-2026-65901",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-65901"
},
{
"name": "CVE-2026-11541",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-11541"
},
{
"name": "CVE-2014-3578",
"url": "https://www.cve.org/CVERecord?id=CVE-2014-3578"
},
{
"name": "CVE-2026-41635",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41635"
},
{
"name": "CVE-2024-43871",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43871"
},
{
"name": "CVE-2023-52784",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52784"
},
{
"name": "CVE-2022-40897",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-40897"
},
{
"name": "CVE-2024-31880",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-31880"
},
{
"name": "CVE-2024-29025",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-29025"
},
{
"name": "CVE-2024-43880",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43880"
},
{
"name": "CVE-2021-47461",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47461"
},
{
"name": "CVE-2026-11546",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-11546"
},
{
"name": "CVE-2026-42036",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42036"
},
{
"name": "CVE-2024-40959",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40959"
},
{
"name": "CVE-2026-64607",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64607"
},
{
"name": "CVE-2026-59652",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59652"
},
{
"name": "CVE-2024-27042",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27042"
},
{
"name": "CVE-2023-34453",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-34453"
},
{
"name": "CVE-2024-26669",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26669"
},
{
"name": "CVE-2024-26801",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26801"
},
{
"name": "CVE-2024-27043",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27043"
},
{
"name": "CVE-2024-41761",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41761"
},
{
"name": "CVE-2024-36007",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36007"
},
{
"name": "CVE-2026-65903",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-65903"
},
{
"name": "CVE-2021-47311",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47311"
},
{
"name": "CVE-2026-65900",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-65900"
},
{
"name": "CVE-2026-66010",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-66010"
},
{
"name": "CVE-2026-52746",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52746"
},
{
"name": "CVE-2024-28762",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-28762"
},
{
"name": "CVE-2023-3635",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-3635"
},
{
"name": "CVE-2026-43827",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43827"
},
{
"name": "CVE-2026-50184",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-50184"
},
{
"name": "CVE-2026-47885",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47885"
},
{
"name": "CVE-2026-50169",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-50169"
},
{
"name": "CVE-2021-47287",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47287"
},
{
"name": "CVE-2021-47338",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47338"
},
{
"name": "CVE-2024-26940",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26940"
},
{
"name": "CVE-2026-47065",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47065"
},
{
"name": "CVE-2026-55831",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-55831"
},
{
"name": "CVE-2024-35937",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35937"
},
{
"name": "CVE-2023-5072",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-5072"
},
{
"name": "CVE-2026-47841",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47841"
},
{
"name": "CVE-2021-23337",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-23337"
},
{
"name": "CVE-2024-36952",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36952"
},
{
"name": "CVE-2024-38581",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38581"
},
{
"name": "CVE-2026-41707",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41707"
},
{
"name": "CVE-2021-23369",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-23369"
},
{
"name": "CVE-2026-77415",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-77415"
},
{
"name": "CVE-2026-42403",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42403"
},
{
"name": "CVE-2024-41056",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41056"
},
{
"name": "CVE-2024-38586",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38586"
},
{
"name": "CVE-2024-26880",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26880"
},
{
"name": "CVE-2022-31777",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-31777"
},
{
"name": "CVE-2019-14893",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-14893"
},
{
"name": "CVE-2026-10534",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-10534"
},
{
"name": "CVE-2024-36025",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36025"
},
{
"name": "CVE-2026-59880",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59880"
},
{
"name": "CVE-2026-65432",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-65432"
},
{
"name": "CVE-2026-59894",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59894"
},
{
"name": "CVE-2019-0231",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-0231"
},
{
"name": "CVE-2023-50298",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-50298"
},
{
"name": "CVE-2026-15057",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-15057"
},
{
"name": "CVE-2026-41607",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41607"
},
{
"name": "CVE-2024-26308",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26308"
},
{
"name": "CVE-2025-1992",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-1992"
},
{
"name": "CVE-2026-44248",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-44248"
},
{
"name": "CVE-2018-20676",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-20676"
},
{
"name": "CVE-2024-26773",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26773"
},
{
"name": "CVE-2024-53197",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53197"
},
{
"name": "CVE-2024-36017",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36017"
},
{
"name": "CVE-2024-31141",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-31141"
},
{
"name": "CVE-2024-27434",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27434"
},
{
"name": "CVE-2025-13755",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-13755"
},
{
"name": "CVE-2025-62718",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-62718"
},
{
"name": "CVE-2025-36136",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-36136"
},
{
"name": "CVE-2024-35852",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35852"
},
{
"name": "CVE-2024-26931",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26931"
},
{
"name": "CVE-2021-47560",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47560"
},
{
"name": "CVE-2026-49458",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-49458"
},
{
"name": "CVE-2026-4800",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-4800"
},
{
"name": "CVE-2024-40974",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40974"
},
{
"name": "CVE-2026-42584",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42584"
},
{
"name": "CVE-2024-35924",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35924"
},
{
"name": "CVE-2026-4410",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-4410"
},
{
"name": "CVE-2024-36928",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36928"
},
{
"name": "CVE-2024-38558",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38558"
},
{
"name": "CVE-2026-44249",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-44249"
},
{
"name": "CVE-2023-52775",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52775"
},
{
"name": "CVE-2026-41284",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41284"
},
{
"name": "CVE-2025-36008",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-36008"
},
{
"name": "CVE-2026-59647",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59647"
},
{
"name": "CVE-2024-42124",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42124"
},
{
"name": "CVE-2024-36960",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36960"
},
{
"name": "CVE-2021-35517",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-35517"
},
{
"name": "CVE-2024-30172",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-30172"
},
{
"name": "CVE-2026-42577",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42577"
},
{
"name": "CVE-2026-58059",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-58059"
},
{
"name": "CVE-2026-48978",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-48978"
},
{
"name": "CVE-2021-47582",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47582"
},
{
"name": "CVE-2023-52781",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52781"
},
{
"name": "CVE-2021-47385",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47385"
},
{
"name": "CVE-2026-75596",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-75596"
},
{
"name": "CVE-2026-8484",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-8484"
},
{
"name": "CVE-2026-8763",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-8763"
},
{
"name": "CVE-2026-6051",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-6051"
},
{
"name": "CVE-2026-44598",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-44598"
},
{
"name": "CVE-2023-52486",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52486"
},
{
"name": "CVE-2024-40989",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40989"
},
{
"name": "CVE-2024-35845",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35845"
},
{
"name": "CVE-2025-14917",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-14917"
},
{
"name": "CVE-2023-52619",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52619"
},
{
"name": "CVE-2023-52796",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52796"
},
{
"name": "CVE-2024-36286",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36286"
},
{
"name": "CVE-2026-15325",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-15325"
},
{
"name": "CVE-2021-47073",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47073"
},
{
"name": "CVE-2026-69247",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-69247"
},
{
"name": "CVE-2026-49268",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-49268"
},
{
"name": "CVE-2024-36124",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36124"
},
{
"name": "CVE-2021-47579",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47579"
},
{
"name": "CVE-2026-33671",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-33671"
},
{
"name": "CVE-2026-14976",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-14976"
},
{
"name": "CVE-2026-5598",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-5598"
},
{
"name": "CVE-2025-68470",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68470"
},
{
"name": "CVE-2024-27017",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27017"
},
{
"name": "CVE-2026-65182",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-65182"
},
{
"name": "CVE-2018-11087",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-11087"
},
{
"name": "CVE-2026-42033",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42033"
},
{
"name": "CVE-2024-39502",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39502"
},
{
"name": "CVE-2026-42035",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42035"
},
{
"name": "CVE-2024-26804",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26804"
},
{
"name": "CVE-2026-18446",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-18446"
},
{
"name": "CVE-2026-44495",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-44495"
},
{
"name": "CVE-2024-27065",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27065"
},
{
"name": "CVE-2026-41695",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41695"
},
{
"name": "CVE-2024-23454",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-23454"
},
{
"name": "CVE-2024-27388",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27388"
},
{
"name": "CVE-2024-50082",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50082"
},
{
"name": "CVE-2026-22740",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22740"
},
{
"name": "CVE-2026-47890",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47890"
},
{
"name": "CVE-2023-52686",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52686"
},
{
"name": "CVE-2024-36005",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36005"
},
{
"name": "CVE-2022-3510",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-3510"
},
{
"name": "CVE-2026-59903",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59903"
},
{
"name": "CVE-2024-40977",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40977"
},
{
"name": "CVE-2022-3509",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-3509"
},
{
"name": "CVE-2026-14684",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-14684"
},
{
"name": "CVE-2024-36905",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36905"
},
{
"name": "CVE-2026-56746",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-56746"
},
{
"name": "CVE-2024-35893",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35893"
},
{
"name": "CVE-2024-40983",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40983"
},
{
"name": "CVE-2021-37137",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-37137"
},
{
"name": "CVE-2026-10842",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-10842"
},
{
"name": "CVE-2021-47236",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47236"
},
{
"name": "CVE-2023-51074",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-51074"
},
{
"name": "CVE-2024-53122",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53122"
},
{
"name": "CVE-2021-47373",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47373"
},
{
"name": "CVE-2026-9496",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-9496"
},
{
"name": "CVE-2026-34478",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-34478"
},
{
"name": "CVE-2026-42586",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42586"
},
{
"name": "CVE-2026-35091",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-35091"
},
{
"name": "CVE-2024-57807",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57807"
},
{
"name": "CVE-2025-30474",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-30474"
},
{
"name": "CVE-2024-41008",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41008"
},
{
"name": "CVE-2026-40984",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-40984"
},
{
"name": "CVE-2021-41973",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-41973"
},
{
"name": "CVE-2023-52683",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52683"
},
{
"name": "CVE-2023-52800",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52800"
},
{
"name": "CVE-2024-8184",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-8184"
},
{
"name": "CVE-2026-54428",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-54428"
},
{
"name": "CVE-2026-50162",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-50162"
},
{
"name": "CVE-2026-42043",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42043"
},
{
"name": "CVE-2024-26935",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26935"
},
{
"name": "CVE-2025-11143",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-11143"
},
{
"name": "CVE-2026-15055",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-15055"
},
{
"name": "CVE-2026-8646",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-8646"
},
{
"name": "CVE-2026-45822",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45822"
},
{
"name": "CVE-2025-36006",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-36006"
},
{
"name": "CVE-2026-40477",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-40477"
},
{
"name": "CVE-2023-35701",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-35701"
},
{
"name": "CVE-2024-26846",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26846"
},
{
"name": "CVE-2026-47834",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47834"
},
{
"name": "CVE-2026-34480",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-34480"
},
{
"name": "CVE-2026-14682",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-14682"
},
{
"name": "CVE-2024-35890",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35890"
},
{
"name": "CVE-2024-41041",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41041"
},
{
"name": "CVE-2018-20677",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-20677"
},
{
"name": "CVE-2024-42131",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42131"
},
{
"name": "CVE-2026-84305",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-84305"
},
{
"name": "CVE-2024-35944",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35944"
},
{
"name": "CVE-2026-73180",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-73180"
},
{
"name": "CVE-2024-42079",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42079"
},
{
"name": "CVE-2024-35898",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35898"
},
{
"name": "CVE-2026-59869",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59869"
},
{
"name": "CVE-2026-47887",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47887"
},
{
"name": "CVE-2024-27399",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27399"
},
{
"name": "CVE-2025-36186",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-36186"
},
{
"name": "CVE-2024-36270",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36270"
},
{
"name": "CVE-2026-62243",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-62243"
},
{
"name": "CVE-2023-22946",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-22946"
},
{
"name": "CVE-2026-65904",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-65904"
},
{
"name": "CVE-2026-58061",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-58061"
},
{
"name": "CVE-2025-12758",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-12758"
},
{
"name": "CVE-2026-40175",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-40175"
},
{
"name": "CVE-2023-52469",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52469"
},
{
"name": "CVE-2024-26740",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26740"
},
{
"name": "CVE-2026-69151",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-69151"
},
{
"name": "CVE-2024-35809",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35809"
},
{
"name": "CVE-2024-43854",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43854"
},
{
"name": "CVE-2024-50264",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50264"
},
{
"name": "CVE-2024-41005",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41005"
},
{
"name": "CVE-2024-44935",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44935"
},
{
"name": "CVE-2026-27970",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-27970"
},
{
"name": "CVE-2021-47468",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47468"
},
{
"name": "CVE-2023-52877",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52877"
},
{
"name": "CVE-2026-9320",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-9320"
},
{
"name": "CVE-2026-49459",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-49459"
},
{
"name": "CVE-2023-52809",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52809"
},
{
"name": "CVE-2021-36090",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-36090"
},
{
"name": "CVE-2021-27568",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-27568"
},
{
"name": "CVE-2026-6053",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-6053"
},
{
"name": "CVE-2024-41039",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41039"
},
{
"name": "CVE-2024-23953",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-23953"
},
{
"name": "CVE-2026-54265",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-54265"
},
{
"name": "CVE-2025-68161",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68161"
},
{
"name": "CVE-2023-52451",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52451"
},
{
"name": "CVE-2024-41097",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41097"
},
{
"name": "CVE-2021-38296",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-38296"
},
{
"name": "CVE-2025-21785",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21785"
},
{
"name": "CVE-2022-24823",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-24823"
},
{
"name": "CVE-2024-39472",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39472"
},
{
"name": "CVE-2024-35790",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35790"
},
{
"name": "CVE-2024-26649",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26649"
},
{
"name": "CVE-2026-56624",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-56624"
},
{
"name": "CVE-2023-34455",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-34455"
},
{
"name": "CVE-2021-41184",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-41184"
},
{
"name": "CVE-2024-33621",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-33621"
},
{
"name": "CVE-2024-36978",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36978"
},
{
"name": "CVE-2024-29131",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-29131"
},
{
"name": "CVE-2021-41183",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-41183"
},
{
"name": "CVE-2024-42225",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42225"
},
{
"name": "CVE-2024-29869",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-29869"
},
{
"name": "CVE-2026-41240",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41240"
},
{
"name": "CVE-2026-67317",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-67317"
},
{
"name": "CVE-2026-40478",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-40478"
},
{
"name": "CVE-2026-22748",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22748"
},
{
"name": "CVE-2025-33012",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-33012"
},
{
"name": "CVE-2024-41066",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41066"
},
{
"name": "CVE-2026-34479",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-34479"
},
{
"name": "CVE-2024-52804",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-52804"
},
{
"name": "CVE-2026-43828",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43828"
},
{
"name": "CVE-2026-42040",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42040"
},
{
"name": "CVE-2023-36478",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-36478"
},
{
"name": "CVE-2021-37136",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-37136"
},
{
"name": "CVE-2018-1330",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-1330"
},
{
"name": "CVE-2026-47027",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47027"
},
{
"name": "CVE-2024-35947",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35947"
},
{
"name": "CVE-2026-47058",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47058"
},
{
"name": "CVE-2024-36927",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36927"
},
{
"name": "CVE-2024-42244",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42244"
},
{
"name": "CVE-2022-48836",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48836"
},
{
"name": "CVE-2026-16441",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-16441"
},
{
"name": "CVE-2024-6763",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-6763"
},
{
"name": "CVE-2026-6052",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-6052"
},
{
"name": "CVE-2024-41012",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41012"
},
{
"name": "CVE-2024-53088",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53088"
},
{
"name": "CVE-2024-26826",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26826"
},
{
"name": "CVE-2026-14981",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-14981"
},
{
"name": "CVE-2026-58060",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-58060"
},
{
"name": "CVE-2024-26583",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26583"
},
{
"name": "CVE-2021-21295",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-21295"
},
{
"name": "CVE-2024-36922",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36922"
},
{
"name": "CVE-2026-42778",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42778"
},
{
"name": "CVE-2026-14683",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-14683"
},
{
"name": "CVE-2021-47527",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47527"
},
{
"name": "CVE-2024-35847",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35847"
},
{
"name": "CVE-2024-35896",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35896"
},
{
"name": "CVE-2024-40912",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40912"
},
{
"name": "CVE-2024-26733",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26733"
},
{
"name": "CVE-2026-14529",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-14529"
},
{
"name": "CVE-2019-0204",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-0204"
},
{
"name": "CVE-2024-26851",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26851"
},
{
"name": "CVE-2022-2047",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-2047"
},
{
"name": "CVE-2024-39487",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39487"
},
{
"name": "CVE-2018-11793",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-11793"
},
{
"name": "CVE-2026-22741",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22741"
},
{
"name": "CVE-2023-39410",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-39410"
},
{
"name": "CVE-2024-35888",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35888"
},
{
"name": "CVE-2024-25710",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-25710"
},
{
"name": "CVE-2026-12802",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-12802"
},
{
"name": "CVE-2024-26837",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26837"
},
{
"name": "CVE-2024-7254",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-7254"
},
{
"name": "CVE-2024-46695",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46695"
},
{
"name": "CVE-2022-48773",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48773"
},
{
"name": "CVE-2020-9492",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-9492"
},
{
"name": "CVE-2023-52798",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52798"
},
{
"name": "CVE-2024-31076",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-31076"
},
{
"name": "CVE-2026-40181",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-40181"
},
{
"name": "CVE-2023-52700",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52700"
},
{
"name": "CVE-2025-14923",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-14923"
},
{
"name": "CVE-2024-36901",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36901"
},
{
"name": "CVE-2026-10649",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-10649"
},
{
"name": "CVE-2026-50020",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-50020"
},
{
"name": "CVE-2024-40998",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40998"
},
{
"name": "CVE-2024-27013",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27013"
},
{
"name": "CVE-2024-29133",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-29133"
},
{
"name": "CVE-2024-41090",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41090"
},
{
"name": "CVE-2026-54512",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-54512"
},
{
"name": "CVE-2026-58063",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-58063"
},
{
"name": "CVE-2026-57819",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-57819"
},
{
"name": "CVE-2026-42578",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42578"
},
{
"name": "CVE-2021-47624",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47624"
},
{
"name": "CVE-2021-47495",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47495"
},
{
"name": "CVE-2024-35910",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35910"
},
{
"name": "CVE-2024-26675",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26675"
},
{
"name": "CVE-2022-48757",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48757"
},
{
"name": "CVE-2024-24857",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-24857"
},
{
"name": "CVE-2026-65899",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-65899"
},
{
"name": "CVE-2026-43514",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43514"
},
{
"name": "CVE-2026-45773",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45773"
},
{
"name": "CVE-2026-67319",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-67319"
},
{
"name": "CVE-2024-49949",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49949"
},
{
"name": "CVE-2026-10532",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-10532"
},
{
"name": "CVE-2023-52470",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52470"
},
{
"name": "CVE-2024-26906",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26906"
},
{
"name": "CVE-2022-24785",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-24785"
},
{
"name": "CVE-2025-2518",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-2518"
},
{
"name": "CVE-2024-36971",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36971"
},
{
"name": "CVE-2024-26840",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26840"
},
{
"name": "CVE-2023-46120",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-46120"
},
{
"name": "CVE-2024-50099",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50099"
},
{
"name": "CVE-2024-57979",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57979"
},
{
"name": "CVE-2024-52046",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-52046"
},
{
"name": "CVE-2021-43797",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-43797"
},
{
"name": "CVE-2026-70907",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-70907"
},
{
"name": "CVE-2026-48589",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-48589"
},
{
"name": "CVE-2024-26584",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26584"
},
{
"name": "CVE-2021-37404",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-37404"
},
{
"name": "CVE-2021-47386",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47386"
},
{
"name": "CVE-2023-52832",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52832"
},
{
"name": "CVE-2026-42404",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42404"
},
{
"name": "CVE-2024-41092",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41092"
},
{
"name": "CVE-2022-45787",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-45787"
},
{
"name": "CVE-2024-40995",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40995"
},
{
"name": "CVE-2018-1199",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-1199"
},
{
"name": "CVE-2024-14041",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-14041"
},
{
"name": "CVE-2021-47412",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47412"
},
{
"name": "CVE-2022-48754",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48754"
},
{
"name": "CVE-2026-41586",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41586"
},
{
"name": "CVE-2026-16192",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-16192"
},
{
"name": "CVE-2024-5569",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-5569"
},
{
"name": "CVE-2026-2950",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-2950"
},
{
"name": "CVE-2016-6811",
"url": "https://www.cve.org/CVERecord?id=CVE-2016-6811"
},
{
"name": "CVE-2023-52662",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52662"
},
{
"name": "CVE-2026-68945",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68945"
},
{
"name": "CVE-2024-42238",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42238"
},
{
"name": "CVE-2023-44981",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-44981"
},
{
"name": "CVE-2026-40895",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-40895"
},
{
"name": "CVE-2026-47063",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47063"
},
{
"name": "CVE-2025-1493",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-1493"
},
{
"name": "CVE-2026-12816",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-12816"
},
{
"name": "CVE-2021-47466",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47466"
},
{
"name": "CVE-2024-40929",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40929"
},
{
"name": "CVE-2024-43830",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43830"
},
{
"name": "CVE-2026-59083",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59083"
},
{
"name": "CVE-2025-27553",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-27553"
},
{
"name": "CVE-2024-47535",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47535"
},
{
"name": "CVE-2026-45772",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45772"
},
{
"name": "CVE-2023-52428",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52428"
},
{
"name": "CVE-2021-47289",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47289"
},
{
"name": "CVE-2023-52730",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52730"
},
{
"name": "CVE-2024-42090",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42090"
},
{
"name": "CVE-2026-41606",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41606"
},
{
"name": "CVE-2024-36941",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36941"
},
{
"name": "CVE-2026-59888",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59888"
},
{
"name": "CVE-2024-36896",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36896"
},
{
"name": "CVE-2026-10543",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-10543"
},
{
"name": "CVE-2023-6040",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-6040"
},
{
"name": "CVE-2026-13149",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-13149"
},
{
"name": "CVE-2024-26958",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26958"
},
{
"name": "CVE-2024-36902",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36902"
},
{
"name": "CVE-2026-47021",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47021"
},
{
"name": "CVE-2024-41042",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41042"
},
{
"name": "CVE-2024-6485",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-6485"
},
{
"name": "CVE-2026-47842",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47842"
},
{
"name": "CVE-2025-3050",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-3050"
},
{
"name": "CVE-2023-40167",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-40167"
},
{
"name": "CVE-2018-1274",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-1274"
},
{
"name": "CVE-2021-47383",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47383"
},
{
"name": "CVE-2026-59898",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59898"
},
{
"name": "CVE-2026-16440",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-16440"
},
{
"name": "CVE-2024-36924",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36924"
},
{
"name": "CVE-2026-64958",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64958"
},
{
"name": "CVE-2024-9823",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-9823"
},
{
"name": "CVE-2024-35835",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35835"
},
{
"name": "CVE-2024-38570",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38570"
},
{
"name": "CVE-2026-66422",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-66422"
},
{
"name": "CVE-2024-26939",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26939"
},
{
"name": "CVE-2021-22569",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-22569"
},
{
"name": "CVE-2024-26960",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26960"
},
{
"name": "CVE-2024-26735",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26735"
},
{
"name": "CVE-2024-36489",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36489"
},
{
"name": "CVE-2024-41762",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41762"
},
{
"name": "CVE-2024-40901",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40901"
},
{
"name": "CVE-2023-6378",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-6378"
},
{
"name": "CVE-2024-38575",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38575"
},
{
"name": "CVE-2021-47384",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47384"
},
{
"name": "CVE-2026-41006",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41006"
},
{
"name": "CVE-2026-41711",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41711"
},
{
"name": "CVE-2021-47321",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47321"
},
{
"name": "CVE-2026-45205",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45205"
},
{
"name": "CVE-2026-27830",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-27830"
},
{
"name": "CVE-2023-52679",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52679"
},
{
"name": "CVE-2024-39471",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39471"
},
{
"name": "CVE-2021-47018",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47018"
},
{
"name": "CVE-2026-44487",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-44487"
},
{
"name": "CVE-2026-13506",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-13506"
},
{
"name": "CVE-2024-26640",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26640"
},
{
"name": "CVE-2024-35899",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35899"
},
{
"name": "CVE-2023-52881",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52881"
},
{
"name": "CVE-2026-2482",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-2482"
},
{
"name": "CVE-2026-11897",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-11897"
},
{
"name": "CVE-2026-35092",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-35092"
},
{
"name": "CVE-2026-42038",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42038"
},
{
"name": "CVE-2026-49844",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-49844"
},
{
"name": "CVE-2024-36919",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36919"
},
{
"name": "CVE-2021-46972",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-46972"
},
{
"name": "CVE-2026-18096",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-18096"
},
{
"name": "CVE-2024-35823",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35823"
},
{
"name": "CVE-2022-34169",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-34169"
},
{
"name": "CVE-2026-2332",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-2332"
},
{
"name": "CVE-2026-1561",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-1561"
},
{
"name": "CVE-2024-26923",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26923"
},
{
"name": "CVE-2024-40954",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40954"
},
{
"name": "CVE-2024-35989",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35989"
},
{
"name": "CVE-2026-42039",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42039"
},
{
"name": "CVE-2026-59879",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59879"
},
{
"name": "CVE-2024-35877",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35877"
},
{
"name": "CVE-2026-46968",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46968"
},
{
"name": "CVE-2026-40972",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-40972"
},
{
"name": "CVE-2024-43892",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43892"
},
{
"name": "CVE-2026-50010",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-50010"
},
{
"name": "CVE-2024-27020",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27020"
},
{
"name": "CVE-2022-48760",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48760"
},
{
"name": "CVE-2024-42096",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42096"
},
{
"name": "CVE-2023-52658",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52658"
},
{
"name": "CVE-2024-26769",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26769"
},
{
"name": "CVE-2023-36479",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-36479"
},
{
"name": "CVE-2024-50256",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50256"
},
{
"name": "CVE-2026-59296",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59296"
},
{
"name": "CVE-2024-38619",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38619"
},
{
"name": "CVE-2024-38573",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38573"
},
{
"name": "CVE-2026-33672",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-33672"
},
{
"name": "CVE-2026-75838",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-75838"
},
{
"name": "CVE-2018-14041",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-14041"
},
{
"name": "CVE-2022-48804",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48804"
},
{
"name": "CVE-2026-40983",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-40983"
},
{
"name": "CVE-2024-24549",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-24549"
},
{
"name": "CVE-2026-42581",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42581"
},
{
"name": "CVE-2021-47408",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47408"
},
{
"name": "CVE-2024-39476",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39476"
},
{
"name": "CVE-2025-0915",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-0915"
},
{
"name": "CVE-2024-47668",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47668"
},
{
"name": "CVE-2023-29267",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-29267"
},
{
"name": "CVE-2024-35938",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35938"
},
{
"name": "CVE-2026-42779",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42779"
},
{
"name": "CVE-2021-47097",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47097"
},
{
"name": "CVE-2024-42322",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42322"
},
{
"name": "CVE-2026-43513",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43513"
},
{
"name": "CVE-2023-28370",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-28370"
},
{
"name": "CVE-2024-42094",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42094"
},
{
"name": "CVE-2026-54517",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-54517"
},
{
"name": "CVE-2024-27019",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27019"
},
{
"name": "CVE-2024-23848",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-23848"
},
{
"name": "CVE-2024-26843",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26843"
},
{
"name": "CVE-2022-48747",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48747"
},
{
"name": "CVE-2026-25639",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-25639"
},
{
"name": "CVE-2026-40973",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-40973"
},
{
"name": "CVE-2024-41040",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41040"
},
{
"name": "CVE-2020-11022",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-11022"
},
{
"name": "CVE-2024-38564",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38564"
},
{
"name": "CVE-2026-15064",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-15064"
},
{
"name": "CVE-2026-42044",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42044"
},
{
"name": "CVE-2024-36950",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36950"
},
{
"name": "CVE-2024-40927",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40927"
},
{
"name": "CVE-2021-31684",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-31684"
},
{
"name": "CVE-2025-25193",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-25193"
},
{
"name": "CVE-2023-52667",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52667"
},
{
"name": "CVE-2026-8620",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-8620"
},
{
"name": "CVE-2024-41014",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41014"
},
{
"name": "CVE-2026-65905",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-65905"
},
{
"name": "CVE-2026-16439",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-16439"
},
{
"name": "CVE-2025-14915",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-14915"
},
{
"name": "CVE-2026-56745",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-56745"
},
{
"name": "CVE-2018-16487",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-16487"
},
{
"name": "CVE-2026-8633",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-8633"
},
{
"name": "CVE-2022-31159",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-31159"
},
{
"name": "CVE-2026-11714",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-11714"
},
{
"name": "CVE-2016-10735",
"url": "https://www.cve.org/CVERecord?id=CVE-2016-10735"
},
{
"name": "CVE-2024-52903",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-52903"
},
{
"name": "CVE-2026-47838",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47838"
},
{
"name": "CVE-2021-42550",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-42550"
},
{
"name": "CVE-2017-18214",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-18214"
},
{
"name": "CVE-2025-22870",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22870"
},
{
"name": "CVE-2026-59642",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59642"
},
{
"name": "CVE-2024-40941",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40941"
},
{
"name": "CVE-2023-52703",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52703"
},
{
"name": "CVE-2024-40679",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40679"
},
{
"name": "CVE-2026-42034",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42034"
},
{
"name": "CVE-2026-47884",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47884"
},
{
"name": "CVE-2026-41417",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41417"
},
{
"name": "CVE-2026-61308",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-61308"
},
{
"name": "CVE-2025-23215",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23215"
},
{
"name": "CVE-2026-48043",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-48043"
},
{
"name": "CVE-2026-9322",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-9322"
},
{
"name": "CVE-2024-41055",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41055"
},
{
"name": "CVE-2026-87958",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-87958"
},
{
"name": "CVE-2026-22745",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22745"
},
{
"name": "CVE-2024-30171",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-30171"
},
{
"name": "CVE-2026-42587",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42587"
},
{
"name": "CVE-2026-54513",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-54513"
},
{
"name": "CVE-2024-38541",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38541"
},
{
"name": "CVE-2021-47491",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47491"
},
{
"name": "CVE-2024-40984",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40984"
},
{
"name": "CVE-2025-14914",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-14914"
},
{
"name": "CVE-2024-36016",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36016"
},
{
"name": "CVE-2023-52922",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52922"
},
{
"name": "CVE-2026-65927",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-65927"
},
{
"name": "CVE-2022-48866",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48866"
},
{
"name": "CVE-2026-9563",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-9563"
},
{
"name": "CVE-2023-52623",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52623"
},
{
"name": "CVE-2026-54518",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-54518"
},
{
"name": "CVE-2020-9480",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-9480"
},
{
"name": "CVE-2024-36114",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36114"
},
{
"name": "CVE-2026-47244",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47244"
},
{
"name": "CVE-2024-38540",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38540"
},
{
"name": "CVE-2026-13676",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-13676"
},
{
"name": "CVE-2024-26759",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26759"
},
{
"name": "CVE-2026-54297",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-54297"
},
{
"name": "CVE-2026-53434",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53434"
},
{
"name": "CVE-2011-4969",
"url": "https://www.cve.org/CVERecord?id=CVE-2011-4969"
},
{
"name": "CVE-2026-60589",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-60589"
},
{
"name": "CVE-2026-67312",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-67312"
},
{
"name": "CVE-2026-6938",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-6938"
},
{
"name": "CVE-2025-8916",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-8916"
},
{
"name": "CVE-2024-35884",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35884"
},
{
"name": "CVE-2024-41076",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41076"
},
{
"name": "CVE-2026-66142",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-66142"
},
{
"name": "CVE-2025-8885",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-8885"
},
{
"name": "CVE-2023-52464",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52464"
},
{
"name": "CVE-2024-39276",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39276"
},
{
"name": "CVE-2023-52813",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52813"
},
{
"name": "CVE-2026-10051",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-10051"
},
{
"name": "CVE-2026-53669",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53669"
},
{
"name": "CVE-2024-39506",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39506"
},
{
"name": "CVE-2026-41409",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41409"
},
{
"name": "CVE-2018-1259",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-1259"
},
{
"name": "CVE-2024-36940",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36940"
},
{
"name": "CVE-2023-52811",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52811"
},
{
"name": "CVE-2026-6322",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-6322"
},
{
"name": "CVE-2024-35838",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35838"
},
{
"name": "CVE-2026-8400",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-8400"
},
{
"name": "CVE-2026-45623",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45623"
},
{
"name": "CVE-2026-14980",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-14980"
},
{
"name": "CVE-2024-40978",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40978"
},
{
"name": "CVE-2023-24998",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-24998"
},
{
"name": "CVE-2024-26894",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26894"
},
{
"name": "CVE-2026-58062",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-58062"
},
{
"name": "CVE-2024-41023",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41023"
},
{
"name": "CVE-2024-53104",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53104"
},
{
"name": "CVE-2023-52615",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52615"
},
{
"name": "CVE-2024-35801",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35801"
},
{
"name": "CVE-2026-12143",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-12143"
},
{
"name": "CVE-2026-67318",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-67318"
},
{
"name": "CVE-2026-59893",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59893"
},
{
"name": "CVE-2024-35930",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35930"
},
{
"name": "CVE-2024-26660",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26660"
},
{
"name": "CVE-2024-36010",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36010"
},
{
"name": "CVE-2021-21290",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-21290"
},
{
"name": "CVE-2024-41035",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41035"
},
{
"name": "CVE-2023-52560",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52560"
},
{
"name": "CVE-2026-50151",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-50151"
},
{
"name": "CVE-2024-26878",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26878"
},
{
"name": "CVE-2024-35900",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35900"
},
{
"name": "CVE-2024-41065",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41065"
},
{
"name": "CVE-2026-44486",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-44486"
},
{
"name": "CVE-2024-38598",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38598"
},
{
"name": "CVE-2026-42264",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42264"
},
{
"name": "CVE-2026-12803",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-12803"
},
{
"name": "CVE-2021-47069",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47069"
},
{
"name": "CVE-2026-8384",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-8384"
},
{
"name": "CVE-2024-35960",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35960"
},
{
"name": "CVE-2023-2976",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-2976"
},
{
"name": "CVE-2026-59650",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59650"
},
{
"name": "CVE-2025-1000",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-1000"
},
{
"name": "CVE-2023-52840",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52840"
},
{
"name": "CVE-2021-47548",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47548"
},
{
"name": "CVE-2026-44496",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-44496"
},
{
"name": "CVE-2018-8023",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-8023"
},
{
"name": "CVE-2024-41091",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41091"
},
{
"name": "CVE-2024-26853",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26853"
},
{
"name": "CVE-2026-44492",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-44492"
},
{
"name": "CVE-2024-36920",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36920"
},
{
"name": "CVE-2021-47393",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47393"
},
{
"name": "CVE-2026-54225",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-54225"
},
{
"name": "CVE-2026-39865",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-39865"
},
{
"name": "CVE-2026-41238",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41238"
},
{
"name": "CVE-2026-47877",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47877"
},
{
"name": "CVE-2023-52522",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52522"
},
{
"name": "CVE-2026-43512",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43512"
},
{
"name": "CVE-2024-41044",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41044"
},
{
"name": "CVE-2024-40958",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40958"
},
{
"name": "CVE-2020-26555",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-26555"
},
{
"name": "CVE-2021-47497",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47497"
},
{
"name": "CVE-2024-26717",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26717"
},
{
"name": "CVE-2024-38559",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38559"
},
{
"name": "CVE-2021-22570",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-22570"
},
{
"name": "CVE-2026-47883",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47883"
},
{
"name": "CVE-2021-35515",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-35515"
},
{
"name": "CVE-2024-44990",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44990"
},
{
"name": "CVE-2026-41007",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41007"
},
{
"name": "CVE-2026-42037",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42037"
},
{
"name": "CVE-2022-40898",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-40898"
},
{
"name": "CVE-2024-42265",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42265"
},
{
"name": "CVE-2021-46984",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-46984"
},
{
"name": "CVE-2026-55760",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-55760"
},
{
"name": "CVE-2024-2201",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-2201"
},
{
"name": "CVE-2023-26048",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-26048"
},
{
"name": "CVE-2026-42498",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42498"
},
{
"name": "CVE-2026-42042",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42042"
},
{
"name": "CVE-2024-42152",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42152"
},
{
"name": "CVE-2026-9071",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-9071"
},
{
"name": "CVE-2017-7669",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-7669"
},
{
"name": "CVE-2026-67213",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-67213"
},
{
"name": "CVE-2023-52777",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52777"
},
{
"name": "CVE-2024-41013",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41013"
},
{
"name": "CVE-2026-55833",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-55833"
},
{
"name": "CVE-2024-35789",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35789"
},
{
"name": "CVE-2023-52835",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52835"
},
{
"name": "CVE-2024-45663",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45663"
},
{
"name": "CVE-2026-13586",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-13586"
},
{
"name": "CVE-2025-33134",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-33134"
},
{
"name": "CVE-2021-47101",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47101"
},
{
"name": "CVE-2024-26982",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26982"
},
{
"name": "CVE-2023-26112",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-26112"
},
{
"name": "CVE-2024-39499",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39499"
},
{
"name": "CVE-2026-9370",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-9370"
},
{
"name": "CVE-2021-47310",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47310"
},
{
"name": "CVE-2024-38579",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38579"
},
{
"name": "CVE-2023-52626",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52626"
},
{
"name": "CVE-2024-36979",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36979"
},
{
"name": "CVE-2024-36006",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36006"
},
{
"name": "CVE-2026-11806",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-11806"
},
{
"name": "CVE-2023-52476",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52476"
},
{
"name": "CVE-2024-42301",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42301"
},
{
"name": "CVE-2026-12590",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-12590"
},
{
"name": "CVE-2026-34477",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-34477"
},
{
"name": "CVE-2026-65902",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-65902"
},
{
"name": "CVE-2023-52463",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52463"
},
{
"name": "CVE-2024-26925",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26925"
},
{
"name": "CVE-2026-56819",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-56819"
},
{
"name": "CVE-2026-54284",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-54284"
},
{
"name": "CVE-2026-6321",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-6321"
},
{
"name": "CVE-2022-3171",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-3171"
},
{
"name": "CVE-2024-26870",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26870"
},
{
"name": "CVE-2024-35958",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35958"
},
{
"name": "CVE-2024-36954",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36954"
},
{
"name": "CVE-2021-47456",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47456"
},
{
"name": "CVE-2026-44490",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-44490"
},
{
"name": "CVE-2016-7103",
"url": "https://www.cve.org/CVERecord?id=CVE-2016-7103"
},
{
"name": "CVE-2015-9251",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-9251"
},
{
"name": "CVE-2026-59639",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59639"
},
{
"name": "CVE-2026-86093",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-86093"
},
{
"name": "CVE-2024-36933",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36933"
},
{
"name": "CVE-2026-10852",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-10852"
},
{
"name": "CVE-2024-41064",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41064"
},
{
"name": "CVE-2026-28338",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-28338"
},
{
"name": "CVE-2024-40911",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40911"
},
{
"name": "CVE-2010-5312",
"url": "https://www.cve.org/CVERecord?id=CVE-2010-5312"
},
{
"name": "CVE-2026-68494",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68494"
},
{
"name": "CVE-2024-26810",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26810"
},
{
"name": "CVE-2023-52530",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52530"
},
{
"name": "CVE-2024-26772",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26772"
},
{
"name": "CVE-2012-6708",
"url": "https://www.cve.org/CVERecord?id=CVE-2012-6708"
},
{
"name": "CVE-2024-36000",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36000"
},
{
"name": "CVE-2024-50110",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50110"
},
{
"name": "CVE-2021-47356",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47356"
},
{
"name": "CVE-2020-7656",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-7656"
},
{
"name": "CVE-2018-8013",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-8013"
},
{
"name": "CVE-2021-47609",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47609"
},
{
"name": "CVE-2026-29063",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-29063"
},
{
"name": "CVE-2026-60147",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-60147"
},
{
"name": "CVE-2026-47889",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47889"
},
{
"name": "CVE-2024-26855",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26855"
},
{
"name": "CVE-2019-16869",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-16869"
},
{
"name": "CVE-2023-52648",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52648"
},
{
"name": "CVE-2026-15280",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-15280"
},
{
"name": "CVE-2026-67316",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-67316"
},
{
"name": "CVE-2025-14813",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-14813"
},
{
"name": "CVE-2022-41881",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-41881"
},
{
"name": "CVE-2025-13465",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-13465"
},
{
"name": "CVE-2023-52791",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52791"
},
{
"name": "CVE-2024-38538",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38538"
},
{
"name": "CVE-2026-44488",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-44488"
},
{
"name": "CVE-2024-42237",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42237"
},
{
"name": "CVE-2021-47353",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47353"
},
{
"name": "CVE-2023-52707",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52707"
},
{
"name": "CVE-2026-59899",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59899"
},
{
"name": "CVE-2026-1718",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-1718"
},
{
"name": "CVE-2026-71491",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-71491"
},
{
"name": "CVE-2026-34481",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-34481"
},
{
"name": "CVE-2024-27025",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27025"
},
{
"name": "CVE-2024-27011",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27011"
},
{
"name": "CVE-2024-36953",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36953"
},
{
"name": "CVE-2024-26924",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26924"
},
{
"name": "CVE-2021-47257",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47257"
},
{
"name": "CVE-2026-38969",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-38969"
},
{
"name": "CVE-2026-19880",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-19880"
},
{
"name": "CVE-2024-46858",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46858"
},
{
"name": "CVE-2026-47059",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47059"
},
{
"name": "CVE-2022-25168",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-25168"
},
{
"name": "CVE-2026-41293",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41293"
},
{
"name": "CVE-2024-38615",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38615"
},
{
"name": "CVE-2024-44989",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44989"
},
{
"name": "CVE-2024-6345",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-6345"
},
{
"name": "CVE-2026-77310",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-77310"
},
{
"name": "CVE-2024-57699",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57699"
},
{
"name": "CVE-2023-52817",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52817"
},
{
"name": "CVE-2026-65898",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-65898"
},
{
"name": "CVE-2020-11023",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-11023"
},
{
"name": "CVE-2023-5090",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-5090"
},
{
"name": "CVE-2024-27410",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27410"
},
{
"name": "CVE-2021-46909",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-46909"
},
{
"name": "CVE-2019-8331",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-8331"
},
{
"name": "CVE-2024-35853",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35853"
},
{
"name": "CVE-2018-1000632",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-1000632"
},
{
"name": "CVE-2019-20445",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-20445"
},
{
"name": "CVE-2024-26907",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26907"
},
{
"name": "CVE-2024-40961",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40961"
},
{
"name": "CVE-2026-59889",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59889"
},
{
"name": "CVE-2025-36185",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-36185"
},
{
"name": "CVE-2025-11226",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-11226"
}
],
"initial_release_date": "2026-09-11T00:00:00",
"last_revision_date": "2026-09-11T00:00:00",
"links": [],
"reference": "CERTFR-2026-AVI-1165",
"revisions": [
{
"description": "Version initiale",
"revision_date": "2026-09-11T00:00:00.000000"
}
],
"risks": [
{
"description": "D\u00e9ni de service \u00e0 distance"
},
{
"description": "Injection de code indirecte \u00e0 distance (XSS)"
},
{
"description": "Injection de requ\u00eates ill\u00e9gitimes par rebond (CSRF)"
},
{
"description": "Ex\u00e9cution de code arbitraire \u00e0 distance"
},
{
"description": "Atteinte \u00e0 l\u0027int\u00e9grit\u00e9 des donn\u00e9es"
},
{
"description": "Non sp\u00e9cifi\u00e9 par l\u0027\u00e9diteur"
},
{
"description": "Falsification de requ\u00eates c\u00f4t\u00e9 serveur (SSRF)"
},
{
"description": "Contournement de la politique de s\u00e9curit\u00e9"
},
{
"description": "Atteinte \u00e0 la confidentialit\u00e9 des donn\u00e9es"
},
{
"description": "\u00c9l\u00e9vation de privil\u00e8ges"
}
],
"summary": "De multiples vuln\u00e9rabilit\u00e9s ont \u00e9t\u00e9 d\u00e9couvertes dans les produits IBM. Certaines d\u0027entre elles permettent \u00e0 un attaquant de provoquer une ex\u00e9cution de code arbitraire \u00e0 distance, une \u00e9l\u00e9vation de privil\u00e8ges et un d\u00e9ni de service \u00e0 distance.",
"title": "Multiples vuln\u00e9rabilit\u00e9s dans les produits IBM",
"vendor_advisories": [
{
"published_at": "2026-09-09",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7286777",
"url": "https://www.ibm.com/support/pages/node/7286777"
},
{
"published_at": "2026-09-09",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7286776",
"url": "https://www.ibm.com/support/pages/node/7286776"
},
{
"published_at": "2026-09-10",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7286990",
"url": "https://www.ibm.com/support/pages/node/7286990"
},
{
"published_at": "2026-09-10",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7286976",
"url": "https://www.ibm.com/support/pages/node/7286976"
},
{
"published_at": "2026-09-10",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7286993",
"url": "https://www.ibm.com/support/pages/node/7286993"
},
{
"published_at": "2026-09-09",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7286782",
"url": "https://www.ibm.com/support/pages/node/7286782"
},
{
"published_at": "2026-09-07",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7286515",
"url": "https://www.ibm.com/support/pages/node/7286515"
},
{
"published_at": "2026-09-10",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7286646",
"url": "https://www.ibm.com/support/pages/node/7286646"
},
{
"published_at": "2026-09-11",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7287136",
"url": "https://www.ibm.com/support/pages/node/7287136"
},
{
"published_at": "2026-09-10",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7286986",
"url": "https://www.ibm.com/support/pages/node/7286986"
},
{
"published_at": "2026-09-10",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7286982",
"url": "https://www.ibm.com/support/pages/node/7286982"
},
{
"published_at": "2026-09-09",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7286775",
"url": "https://www.ibm.com/support/pages/node/7286775"
},
{
"published_at": "2026-09-10",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7286987",
"url": "https://www.ibm.com/support/pages/node/7286987"
},
{
"published_at": "2026-09-09",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7286910",
"url": "https://www.ibm.com/support/pages/node/7286910"
},
{
"published_at": "2026-09-07",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7286516",
"url": "https://www.ibm.com/support/pages/node/7286516"
},
{
"published_at": "2026-09-09",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7286909",
"url": "https://www.ibm.com/support/pages/node/7286909"
}
]
}
FKIE_CVE-2024-26960
Vulnerability from fkie_nvd - Published: 2024-05-01 06:15 - Updated: 2026-08-04 11:175.5 (Medium) - CVSS:3.1/
| Vendor | Product | Version | |
|---|---|---|---|
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| debian | debian_linux | 10.0 |
{
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"mm/swapfile.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "d85c11c97ecf92d47a4b29e3faca714dc1f18d0d",
"status": "affected",
"version": "7c00bafee87c7bac7ed9eced7c161f8e5332cb4e",
"versionType": "git"
},
{
"lessThan": "2da5568ee222ce0541bfe446a07998f92ed1643e",
"status": "affected",
"version": "7c00bafee87c7bac7ed9eced7c161f8e5332cb4e",
"versionType": "git"
},
{
"lessThan": "1ede7f1d7eed1738d1b9333fd1e152ccb450b86a",
"status": "affected",
"version": "7c00bafee87c7bac7ed9eced7c161f8e5332cb4e",
"versionType": "git"
},
{
"lessThan": "0f98f6d2fb5fad00f8299b84b85b6bc1b6d7d19a",
"status": "affected",
"version": "7c00bafee87c7bac7ed9eced7c161f8e5332cb4e",
"versionType": "git"
},
{
"lessThan": "3ce4c4c653e4e478ecb15d3c88e690f12cbf6b39",
"status": "affected",
"version": "7c00bafee87c7bac7ed9eced7c161f8e5332cb4e",
"versionType": "git"
},
{
"lessThan": "363d17e7f7907c8e27a9e86968af0eaa2301787b",
"status": "affected",
"version": "7c00bafee87c7bac7ed9eced7c161f8e5332cb4e",
"versionType": "git"
},
{
"lessThan": "82b1c07a0af603e3c47b906c8e991dc96f01688e",
"status": "affected",
"version": "7c00bafee87c7bac7ed9eced7c161f8e5332cb4e",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"mm/swapfile.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "4.11"
},
{
"lessThan": "4.11",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.215",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.154",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.84",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.24",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.7.*",
"status": "unaffected",
"version": "6.7.12",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.8.*",
"status": "unaffected",
"version": "6.8.3",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.9",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
},
{
"affectedData": [
{
"cpes": [
"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unknown",
"product": "linux_kernel",
"vendor": "linux",
"versions": [
{
"lessThan": "d85c11c97ecf",
"status": "affected",
"version": "7c00bafee87c",
"versionType": "custom"
}
]
},
{
"cpes": [
"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unknown",
"product": "linux_kernel",
"vendor": "linux",
"versions": [
{
"lessThan": "2da5568ee222",
"status": "affected",
"version": "7c00bafee87c",
"versionType": "custom"
}
]
},
{
"cpes": [
"cpe:2.3:o:linux:linux_kernel:-:*:*:*:*:*:*:*"
],
"defaultStatus": "unknown",
"product": "linux_kernel",
"vendor": "linux",
"versions": [
{
"lessThan": "1ede7f1d7eed",
"status": "affected",
"version": "7c00bafee87c",
"versionType": "custom"
}
]
},
{
"cpes": [
"cpe:2.3:o:linux:linux_kernel:-:*:*:*:*:*:*:*"
],
"defaultStatus": "unknown",
"product": "linux_kernel",
"vendor": "linux",
"versions": [
{
"lessThan": "0f98f6d2fb5f",
"status": "affected",
"version": "7c00bafee87c",
"versionType": "custom"
}
]
},
{
"cpes": [
"cpe:2.3:o:linux:linux_kernel:-:*:*:*:*:*:*:*"
],
"defaultStatus": "unknown",
"product": "linux_kernel",
"vendor": "linux",
"versions": [
{
"lessThan": "3ce4c4c653e4",
"status": "affected",
"version": "7c00bafee87c",
"versionType": "custom"
}
]
},
{
"cpes": [
"cpe:2.3:o:linux:linux_kernel:-:*:*:*:*:*:*:*"
],
"defaultStatus": "unknown",
"product": "linux_kernel",
"vendor": "linux",
"versions": [
{
"lessThan": "363d17e7f790",
"status": "affected",
"version": "7c00bafee87c",
"versionType": "custom"
}
]
},
{
"cpes": [
"cpe:2.3:o:linux:linux_kernel:-:*:*:*:*:*:*:*"
],
"defaultStatus": "unknown",
"product": "linux_kernel",
"vendor": "linux",
"versions": [
{
"lessThan": "82b1c07a0af6",
"status": "affected",
"version": "7c00bafee87c",
"versionType": "custom"
}
]
},
{
"cpes": [
"cpe:2.3:o:linux:linux_kernel:-:*:*:*:*:*:*:*"
],
"defaultStatus": "unknown",
"product": "linux_kernel",
"vendor": "linux",
"versions": [
{
"lessThan": "5.11",
"status": "unaffected",
"version": "5.10.215",
"versionType": "custom"
}
]
},
{
"cpes": [
"cpe:2.3:o:linux:linux_kernel:-:*:*:*:*:*:*:*"
],
"defaultStatus": "unknown",
"product": "linux_kernel",
"vendor": "linux",
"versions": [
{
"lessThan": "6.2",
"status": "unaffected",
"version": "6.1.84",
"versionType": "custom"
}
]
},
{
"cpes": [
"cpe:2.3:o:linux:linux_kernel:-:*:*:*:*:*:*:*"
],
"defaultStatus": "unknown",
"product": "linux_kernel",
"vendor": "linux",
"versions": [
{
"lessThan": "6.7",
"status": "unaffected",
"version": "6.6.24",
"versionType": "custom"
}
]
},
{
"cpes": [
"cpe:2.3:o:linux:linux_kernel:-:*:*:*:*:*:*:*"
],
"defaultStatus": "unknown",
"product": "linux_kernel",
"vendor": "linux",
"versions": [
{
"lessThan": "6.9",
"status": "unaffected",
"version": "6.8.3",
"versionType": "custom"
}
]
},
{
"cpes": [
"cpe:2.3:o:linux:linux_kernel:-:*:*:*:*:*:*:*"
],
"defaultStatus": "unknown",
"product": "linux_kernel",
"vendor": "linux",
"versions": [
{
"status": "unaffected",
"version": "6.9"
}
]
},
{
"cpes": [
"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unknown",
"product": "linux_kernel",
"vendor": "linux",
"versions": [
{
"lessThan": "4.11",
"status": "unaffected",
"version": "0",
"versionType": "custom"
}
]
},
{
"cpes": [
"cpe:2.3:o:linux:linux_kernel:4.11:*:*:*:*:*:*:*"
],
"defaultStatus": "unknown",
"product": "linux_kernel",
"vendor": "linux",
"versions": [
{
"status": "affected",
"version": "4.11"
}
]
},
{
"cpes": [
"cpe:2.3:o:linux:linux_kernel:-:*:*:*:*:*:*:*"
],
"defaultStatus": "unknown",
"product": "linux_kernel",
"vendor": "linux",
"versions": [
{
"lessThan": "5.16",
"status": "unaffected",
"version": "5.15.154",
"versionType": "custom"
}
]
},
{
"cpes": [
"cpe:2.3:o:linux:linux_kernel:-:*:*:*:*:*:*:*"
],
"defaultStatus": "unknown",
"product": "linux_kernel",
"vendor": "linux",
"versions": [
{
"lessThan": "6.8",
"status": "unaffected",
"version": "6.7.12",
"versionType": "custom"
}
]
}
],
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0"
},
{
"affectedData": [
{
"defaultStatus": "unknown",
"product": "SIMATIC S7-1500 TM MFP - GNU/Linux subsystem",
"vendor": "Siemens",
"versions": [
{
"lessThan": "*",
"status": "affected",
"version": "0",
"versionType": "custom"
}
]
}
],
"source": "0b142b55-0307-4c5a-b3c9-f314f3fb7c5e"
}
],
"configurations": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "C0958525-A5AB-4D52-BD1F-3138F23DCF13",
"versionEndExcluding": "5.10.215",
"versionStartIncluding": "4.11",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "577E212E-7E95-4A71-9B5C-F1D1A3AFFF46",
"versionEndExcluding": "5.15.154",
"versionStartIncluding": "5.11",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "834D9BD5-42A6-4D74-979E-4D6D93F630FD",
"versionEndExcluding": "6.1.84",
"versionStartIncluding": "5.16",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "8018C1D0-0A5F-48D0-BC72-A2B33FDDA693",
"versionEndExcluding": "6.6.24",
"versionStartIncluding": "6.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "6BE9771A-BAFD-4624-95F9-58D536540C53",
"versionEndExcluding": "6.7.12",
"versionStartIncluding": "6.7",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "4C59BBC3-6495-4A77-9C82-55EC7CDF5E02",
"versionEndExcluding": "6.8.3",
"versionStartIncluding": "6.8",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
},
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:debian:debian_linux:10.0:*:*:*:*:*:*:*",
"matchCriteriaId": "07B237A9-69A3-4A9C-9DA0-4E06BD37AE73",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm: swap: fix race between free_swap_and_cache() and swapoff()\n\nThere was previously a theoretical window where swapoff() could run and\nteardown a swap_info_struct while a call to free_swap_and_cache() was\nrunning in another thread. This could cause, amongst other bad\npossibilities, swap_page_trans_huge_swapped() (called by\nfree_swap_and_cache()) to access the freed memory for swap_map.\n\nThis is a theoretical problem and I haven\u0027t been able to provoke it from a\ntest case. But there has been agreement based on code review that this is\npossible (see link below).\n\nFix it by using get_swap_device()/put_swap_device(), which will stall\nswapoff(). There was an extra check in _swap_info_get() to confirm that\nthe swap entry was not free. This isn\u0027t present in get_swap_device()\nbecause it doesn\u0027t make sense in general due to the race between getting\nthe reference and swapoff. So I\u0027ve added an equivalent check directly in\nfree_swap_and_cache().\n\nDetails of how to provoke one possible issue (thanks to David Hildenbrand\nfor deriving this):\n\n--8\u003c-----\n\n__swap_entry_free() might be the last user and result in\n\"count == SWAP_HAS_CACHE\".\n\nswapoff-\u003etry_to_unuse() will stop as soon as soon as si-\u003einuse_pages==0.\n\nSo the question is: could someone reclaim the folio and turn\nsi-\u003einuse_pages==0, before we completed swap_page_trans_huge_swapped().\n\nImagine the following: 2 MiB folio in the swapcache. Only 2 subpages are\nstill references by swap entries.\n\nProcess 1 still references subpage 0 via swap entry.\nProcess 2 still references subpage 1 via swap entry.\n\nProcess 1 quits. Calls free_swap_and_cache().\n-\u003e count == SWAP_HAS_CACHE\n[then, preempted in the hypervisor etc.]\n\nProcess 2 quits. Calls free_swap_and_cache().\n-\u003e count == SWAP_HAS_CACHE\n\nProcess 2 goes ahead, passes swap_page_trans_huge_swapped(), and calls\n__try_to_reclaim_swap().\n\n__try_to_reclaim_swap()-\u003efolio_free_swap()-\u003edelete_from_swap_cache()-\u003e\nput_swap_folio()-\u003efree_swap_slot()-\u003eswapcache_free_entries()-\u003e\nswap_entry_free()-\u003eswap_range_free()-\u003e\n...\nWRITE_ONCE(si-\u003einuse_pages, si-\u003einuse_pages - nr_entries);\n\nWhat stops swapoff to succeed after process 2 reclaimed the swap cache\nbut before process1 finished its call to swap_page_trans_huge_swapped()?\n\n--8\u003c-----"
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm: swap: corrige la ejecuci\u00f3n entre free_swap_and_cache() y swapoff() Anteriormente exist\u00eda una ventana te\u00f3rica donde swapoff() pod\u00eda ejecutar y desmantelar un swap_info_struct mientras se realizaba una llamada a free_swap_and_cache(). corriendo en otro hilo. Esto podr\u00eda causar, entre otras malas posibilidades, que swap_page_trans_huge_swapped() (llamado por free_swap_and_cache()) acceda a la memoria liberada para swap_map. Este es un problema te\u00f3rico y no he podido provocarlo a partir de un caso de prueba. Pero ha habido un acuerdo basado en la revisi\u00f3n del c\u00f3digo de que esto es posible (ver enlace a continuaci\u00f3n). Solucionarlo usando get_swap_device()/put_swap_device(), lo que detendr\u00e1 swapoff(). Hubo una verificaci\u00f3n adicional en _swap_info_get() para confirmar que la entrada de intercambio no era gratuita. Esto no est\u00e1 presente en get_swap_device() porque en general no tiene sentido debido a la ejecuci\u00f3n entre obtener la referencia y el intercambio. As\u00ed que agregu\u00e9 una verificaci\u00f3n equivalente directamente en free_swap_and_cache(). Detalles de c\u00f3mo provocar un posible problema (gracias a David Hildenbrand por derivar esto): --8\u0026lt;----- __swap_entry_free() podr\u00eda ser el \u00faltimo usuario y dar como resultado \"count == SWAP_HAS_CACHE\". swapoff-\u0026gt;try_to_unuse() se detendr\u00e1 tan pronto como si-\u0026gt;inuse_pages==0. Entonces la pregunta es: \u00bfalguien podr\u00eda reclamar la publicaci\u00f3n y activar si-\u0026gt;inuse_pages==0, antes de que completemos swap_page_trans_huge_swapped()? Imagine lo siguiente: folio de 2 MiB en el swapcache. S\u00f3lo 2 subp\u00e1ginas siguen siendo referencias mediante entradas de intercambio. El proceso 1 todav\u00eda hace referencia a la subp\u00e1gina 0 mediante la entrada de intercambio. El proceso 2 todav\u00eda hace referencia a la subp\u00e1gina 1 mediante la entrada de intercambio. El proceso 1 se cierra. Llama a free_swap_and_cache(). -\u0026gt; count == SWAP_HAS_CACHE [luego, adelantado en el hipervisor, etc.] El proceso 2 se cierra. Llama a free_swap_and_cache(). -\u0026gt; count == SWAP_HAS_CACHE El proceso 2 contin\u00faa, pasa swap_page_trans_huge_swapped() y llama a __try_to_reclaim_swap(). __try_to_reclaim_swap()-\u0026gt;folio_free_swap()-\u0026gt;delete_from_swap_cache()-\u0026gt; put_swap_folio()-\u0026gt;free_swap_slot()-\u0026gt;swapcache_free_entries()-\u0026gt; swap_entry_free()-\u0026gt;swap_range_free()-\u0026gt; ... WRITE_ONCE(si-\u0026gt;inuse_pages, si-\u0026gt;inuse_pages - nr_entries); \u00bfQu\u00e9 impide que el intercambio tenga \u00e9xito despu\u00e9s de que el proceso 2 recuper\u00f3 el cach\u00e9 de intercambio pero antes de que el proceso 1 terminara su llamada a swap_page_trans_huge_swapped()? --8\u0026lt;-----"
}
],
"id": "CVE-2024-26960",
"lastModified": "2026-08-04T11:17:27.080",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "HIGH",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 7.0,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.0,
"impactScore": 5.9,
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"type": "Secondary"
},
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 5.5,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 3.6,
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"type": "Secondary"
}
],
"ssvcV203": [
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"ssvcData": {
"id": "CVE-2024-26960",
"options": [
{
"exploitation": "none"
},
{
"automatable": "no"
},
{
"technicalImpact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2025-02-05T21:09:23.358079Z",
"version": "2.0.3"
}
}
]
},
"published": "2024-05-01T06:15:12.323",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/0f98f6d2fb5fad00f8299b84b85b6bc1b6d7d19a"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/1ede7f1d7eed1738d1b9333fd1e152ccb450b86a"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/2da5568ee222ce0541bfe446a07998f92ed1643e"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/363d17e7f7907c8e27a9e86968af0eaa2301787b"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/3ce4c4c653e4e478ecb15d3c88e690f12cbf6b39"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/82b1c07a0af603e3c47b906c8e991dc96f01688e"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/d85c11c97ecf92d47a4b29e3faca714dc1f18d0d"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/0f98f6d2fb5fad00f8299b84b85b6bc1b6d7d19a"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/1ede7f1d7eed1738d1b9333fd1e152ccb450b86a"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/2da5568ee222ce0541bfe446a07998f92ed1643e"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/363d17e7f7907c8e27a9e86968af0eaa2301787b"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/3ce4c4c653e4e478ecb15d3c88e690f12cbf6b39"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/82b1c07a0af603e3c47b906c8e991dc96f01688e"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/d85c11c97ecf92d47a4b29e3faca714dc1f18d0d"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Mailing List",
"Third Party Advisory"
],
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"
},
{
"source": "0b142b55-0307-4c5a-b3c9-f314f3fb7c5e",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-265688.html"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Modified",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "CWE-362"
}
],
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"type": "Secondary"
}
]
}
GHSA-2FXM-8374-C95M
Vulnerability from github – Published: 2024-05-01 06:31 – Updated: 2026-05-12 12:31In the Linux kernel, the following vulnerability has been resolved:
mm: swap: fix race between free_swap_and_cache() and swapoff()
There was previously a theoretical window where swapoff() could run and teardown a swap_info_struct while a call to free_swap_and_cache() was running in another thread. This could cause, amongst other bad possibilities, swap_page_trans_huge_swapped() (called by free_swap_and_cache()) to access the freed memory for swap_map.
This is a theoretical problem and I haven't been able to provoke it from a test case. But there has been agreement based on code review that this is possible (see link below).
Fix it by using get_swap_device()/put_swap_device(), which will stall swapoff(). There was an extra check in _swap_info_get() to confirm that the swap entry was not free. This isn't present in get_swap_device() because it doesn't make sense in general due to the race between getting the reference and swapoff. So I've added an equivalent check directly in free_swap_and_cache().
Details of how to provoke one possible issue (thanks to David Hildenbrand for deriving this):
--8<-----
__swap_entry_free() might be the last user and result in "count == SWAP_HAS_CACHE".
swapoff->try_to_unuse() will stop as soon as soon as si->inuse_pages==0.
So the question is: could someone reclaim the folio and turn si->inuse_pages==0, before we completed swap_page_trans_huge_swapped().
Imagine the following: 2 MiB folio in the swapcache. Only 2 subpages are still references by swap entries.
Process 1 still references subpage 0 via swap entry. Process 2 still references subpage 1 via swap entry.
Process 1 quits. Calls free_swap_and_cache(). -> count == SWAP_HAS_CACHE [then, preempted in the hypervisor etc.]
Process 2 quits. Calls free_swap_and_cache(). -> count == SWAP_HAS_CACHE
Process 2 goes ahead, passes swap_page_trans_huge_swapped(), and calls __try_to_reclaim_swap().
__try_to_reclaim_swap()->folio_free_swap()->delete_from_swap_cache()-> put_swap_folio()->free_swap_slot()->swapcache_free_entries()-> swap_entry_free()->swap_range_free()-> ... WRITE_ONCE(si->inuse_pages, si->inuse_pages - nr_entries);
What stops swapoff to succeed after process 2 reclaimed the swap cache but before process1 finished its call to swap_page_trans_huge_swapped()?
--8<-----
{
"affected": [],
"aliases": [
"CVE-2024-26960"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-01T06:15:12Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm: swap: fix race between free_swap_and_cache() and swapoff()\n\nThere was previously a theoretical window where swapoff() could run and\nteardown a swap_info_struct while a call to free_swap_and_cache() was\nrunning in another thread. This could cause, amongst other bad\npossibilities, swap_page_trans_huge_swapped() (called by\nfree_swap_and_cache()) to access the freed memory for swap_map.\n\nThis is a theoretical problem and I haven\u0027t been able to provoke it from a\ntest case. But there has been agreement based on code review that this is\npossible (see link below).\n\nFix it by using get_swap_device()/put_swap_device(), which will stall\nswapoff(). There was an extra check in _swap_info_get() to confirm that\nthe swap entry was not free. This isn\u0027t present in get_swap_device()\nbecause it doesn\u0027t make sense in general due to the race between getting\nthe reference and swapoff. So I\u0027ve added an equivalent check directly in\nfree_swap_and_cache().\n\nDetails of how to provoke one possible issue (thanks to David Hildenbrand\nfor deriving this):\n\n--8\u003c-----\n\n__swap_entry_free() might be the last user and result in\n\"count == SWAP_HAS_CACHE\".\n\nswapoff-\u003etry_to_unuse() will stop as soon as soon as si-\u003einuse_pages==0.\n\nSo the question is: could someone reclaim the folio and turn\nsi-\u003einuse_pages==0, before we completed swap_page_trans_huge_swapped().\n\nImagine the following: 2 MiB folio in the swapcache. Only 2 subpages are\nstill references by swap entries.\n\nProcess 1 still references subpage 0 via swap entry.\nProcess 2 still references subpage 1 via swap entry.\n\nProcess 1 quits. Calls free_swap_and_cache().\n-\u003e count == SWAP_HAS_CACHE\n[then, preempted in the hypervisor etc.]\n\nProcess 2 quits. Calls free_swap_and_cache().\n-\u003e count == SWAP_HAS_CACHE\n\nProcess 2 goes ahead, passes swap_page_trans_huge_swapped(), and calls\n__try_to_reclaim_swap().\n\n__try_to_reclaim_swap()-\u003efolio_free_swap()-\u003edelete_from_swap_cache()-\u003e\nput_swap_folio()-\u003efree_swap_slot()-\u003eswapcache_free_entries()-\u003e\nswap_entry_free()-\u003eswap_range_free()-\u003e\n...\nWRITE_ONCE(si-\u003einuse_pages, si-\u003einuse_pages - nr_entries);\n\nWhat stops swapoff to succeed after process 2 reclaimed the swap cache\nbut before process1 finished its call to swap_page_trans_huge_swapped()?\n\n--8\u003c-----",
"id": "GHSA-2fxm-8374-c95m",
"modified": "2026-05-12T12:31:43Z",
"published": "2024-05-01T06:31:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26960"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-265688.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0f98f6d2fb5fad00f8299b84b85b6bc1b6d7d19a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1ede7f1d7eed1738d1b9333fd1e152ccb450b86a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2da5568ee222ce0541bfe446a07998f92ed1643e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/363d17e7f7907c8e27a9e86968af0eaa2301787b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3ce4c4c653e4e478ecb15d3c88e690f12cbf6b39"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/82b1c07a0af603e3c47b906c8e991dc96f01688e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d85c11c97ecf92d47a4b29e3faca714dc1f18d0d"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GSD-2024-26960
Vulnerability from gsd - Updated: 2024-02-20 06:02{
"gsd": {
"metadata": {
"exploitCode": "unknown",
"remediation": "unknown",
"reportConfidence": "confirmed",
"type": "vulnerability"
},
"osvSchema": {
"aliases": [
"CVE-2024-26960"
],
"id": "GSD-2024-26960",
"modified": "2024-02-20T06:02:29.067363Z",
"schema_version": "1.4.0"
}
},
"namespaces": {
"cve.org": {
"CVE_data_meta": {
"ASSIGNER": "cve@mitre.org",
"ID": "CVE-2024-26960",
"STATE": "RESERVED"
},
"data_format": "MITRE",
"data_type": "CVE",
"data_version": "4.0",
"description": {
"description_data": [
{
"lang": "eng",
"value": "** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem. When the candidate has been publicized, the details for this candidate will be provided."
}
]
}
}
}
}
ICSA-24-102-01
Vulnerability from csaf_cisa - Published: 2024-04-09 00:00 - Updated: 2026-05-14 06:00OESA-2024-1677 (CVE-2021-47269)
Vulnerability from osv_openeuler – Published: 2024-05-31 11:07 – Updated: 2026-08-06 11:07 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
usb: dwc3: ep0: fix NULL pointer exception
There is no validation of the index from dwc3_wIndex_to_dep() and we might be referring a non-existing ep and trigger a NULL pointer exception. In certain configurations we might use fewer eps and the index might wrongly indicate a larger ep index than existing.
By adding this validation from the patch we can actually report a wrong index back to the caller.
In our usecase we are using a composite device on an older kernel, but upstream might use this fix also. Unfortunately, I cannot describe the hardware for others to reproduce the issue as it is a proprietary implementation.
[ 82.958261] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a4 [ 82.966891] Mem abort info: [ 82.969663] ESR = 0x96000006 [ 82.972703] Exception class = DABT (current EL), IL = 32 bits [ 82.978603] SET = 0, FnV = 0 [ 82.981642] EA = 0, S1PTW = 0 [ 82.984765] Data abort info: [ 82.987631] ISV = 0, ISS = 0x00000006 [ 82.991449] CM = 0, WnR = 0 [ 82.994409] user pgtable: 4k pages, 39-bit VAs, pgdp = 00000000c6210ccc [ 83.000999] [00000000000000a4] pgd=0000000053aa5003, pud=0000000053aa5003, pmd=0000000000000000 [ 83.009685] Internal error: Oops: 96000006 [#1] PREEMPT SMP [ 83.026433] Process irq/62-dwc3 (pid: 303, stack limit = 0x000000003985154c) [ 83.033470] CPU: 0 PID: 303 Comm: irq/62-dwc3 Not tainted 4.19.124 #1 [ 83.044836] pstate: 60000085 (nZCv daIf -PAN -UAO) [ 83.049628] pc : dwc3_ep0_handle_feature+0x414/0x43c [ 83.054558] lr : dwc3_ep0_interrupt+0x3b4/0xc94
...
[ 83.141788] Call trace: [ 83.144227] dwc3_ep0_handle_feature+0x414/0x43c [ 83.148823] dwc3_ep0_interrupt+0x3b4/0xc94 [ 83.181546] ---[ end trace aac6b5267d84c32f ]---(CVE-2021-47269)
In the Linux kernel, the following vulnerability has been resolved:
isdn: mISDN: netjet: Fix crash in nj_probe:
'nj_setup' in netjet.c might fail with -EIO and in this case 'card->irq' is initialized and is bigger than zero. A subsequent call to 'nj_release' will free the irq that has not been requested.
Fix this bug by deleting the previous assignment to 'card->irq' and just keep the assignment before 'request_irq'.
The KASAN's log reveals it:
[ 3.354615 ] WARNING: CPU: 0 PID: 1 at kernel/irq/manage.c:1826 free_irq+0x100/0x480 [ 3.355112 ] Modules linked in: [ 3.355310 ] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.13.0-rc1-00144-g25a1298726e #13 [ 3.355816 ] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014 [ 3.356552 ] RIP: 0010:free_irq+0x100/0x480 [ 3.356820 ] Code: 6e 08 74 6f 4d 89 f4 e8 5e ac 09 00 4d 8b 74 24 18 4d 85 f6 75 e3 e8 4f ac 09 00 8b 75 c8 48 c7 c7 78 c1 2e 85 e8 e0 cf f5 ff <0f> 0b 48 8b 75 c0 4c 89 ff e8 72 33 0b 03 48 8b 43 40 4c 8b a0 80 [ 3.358012 ] RSP: 0000:ffffc90000017b48 EFLAGS: 00010082 [ 3.358357 ] RAX: 0000000000000000 RBX: ffff888104dc8000 RCX: 0000000000000000 [ 3.358814 ] RDX: ffff8881003c8000 RSI: ffffffff8124a9e6 RDI: 00000000ffffffff [ 3.359272 ] RBP: ffffc90000017b88 R08: 0000000000000000 R09: 0000000000000000 [ 3.359732 ] R10: ffffc900000179f0 R11: 0000000000001d04 R12: 0000000000000000 [ 3.360195 ] R13: ffff888107dc6000 R14: ffff888107dc6928 R15: ffff888104dc80a8 [ 3.360652 ] FS: 0000000000000000(0000) GS:ffff88817bc00000(0000) knlGS:0000000000000000 [ 3.361170 ] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 3.361538 ] CR2: 0000000000000000 CR3: 000000000582e000 CR4: 00000000000006f0 [ 3.362003 ] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 3.362175 ] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 3.362175 ] Call Trace: [ 3.362175 ] nj_release+0x51/0x1e0 [ 3.362175 ] nj_probe+0x450/0x950 [ 3.362175 ] ? pci_device_remove+0x110/0x110 [ 3.362175 ] local_pci_probe+0x45/0xa0 [ 3.362175 ] pci_device_probe+0x12b/0x1d0 [ 3.362175 ] really_probe+0x2a9/0x610 [ 3.362175 ] driver_probe_device+0x90/0x1d0 [ 3.362175 ] ? mutex_lock_nested+0x1b/0x20 [ 3.362175 ] device_driver_attach+0x68/0x70 [ 3.362175 ] __driver_attach+0x124/0x1b0 [ 3.362175 ] ? device_driver_attach+0x70/0x70 [ 3.362175 ] bus_for_each_dev+0xbb/0x110 [ 3.362175 ] ? rdinit_setup+0x45/0x45 [ 3.362175 ] driver_attach+0x27/0x30 [ 3.362175 ] bus_add_driver+0x1eb/0x2a0 [ 3.362175 ] driver_register+0xa9/0x180 [ 3.362175 ] __pci_register_driver+0x82/0x90 [ 3.362175 ] ? w6692_init+0x38/0x38 [ 3.362175 ] nj_init+0x36/0x38 [ 3.362175 ] do_one_initcall+0x7f/0x3d0 [ 3.362175 ] ? rdinit_setup+0x45/0x45 [ 3.362175 ] ? rcu_read_lock_sched_held+0x4f/0x80 [ 3.362175 ] kernel_init_freeable+0x2aa/0x301 [ 3.362175 ] ? rest_init+0x2c0/0x2c0 [ 3.362175 ] kernel_init+0x18/0x190 [ 3.362175 ] ? rest_init+0x2c0/0x2c0 [ 3.362175 ] ? rest_init+0x2c0/0x2c0 [ 3.362175 ] ret_from_fork+0x1f/0x30 [ 3.362175 ] Kernel panic - not syncing: panic_on_warn set ... [ 3.362175 ] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.13.0-rc1-00144-g25a1298726e #13 [ 3.362175 ] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014 [ 3.362175 ] Call Trace: [ 3.362175 ] dump_stack+0xba/0xf5 [ 3.362175 ] ? free_irq+0x100/0x480 [ 3.362175 ] panic+0x15a/0x3f2 [ 3.362175 ] ? __warn+0xf2/0x150 [ 3.362175 ] ? free_irq+0x100/0x480 [ 3.362175 ] __warn+0x108/0x150 [ 3.362175 ] ? free_irq+0x100/0x480 [ 3.362175 ] report_bug+0x119/0x1c0 [ 3.362175 ] handle_bug+0x3b/0x80 [ 3.362175 ] exc_invalid_op+0x18/0x70 [ 3.362175 ] asm_exc_invalid_op+0x12/0x20 [ 3.362175 ] RIP: 0010:free_irq+0x100 ---truncated---(CVE-2021-47284)
In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to avoid racing on fsync_entry_slab by multi filesystem instances
As syzbot reported, there is an use-after-free issue during f2fs recovery:
Use-after-free write at 0xffff88823bc16040 (in kfence-#10): kmem_cache_destroy+0x1f/0x120 mm/slab_common.c:486 f2fs_recover_fsync_data+0x75b0/0x8380 fs/f2fs/recovery.c:869 f2fs_fill_super+0x9393/0xa420 fs/f2fs/super.c:3945 mount_bdev+0x26c/0x3a0 fs/super.c:1367 legacy_get_tree+0xea/0x180 fs/fs_context.c:592 vfs_get_tree+0x86/0x270 fs/super.c:1497 do_new_mount fs/namespace.c:2905 [inline] path_mount+0x196f/0x2be0 fs/namespace.c:3235 do_mount fs/namespace.c:3248 [inline] __do_sys_mount fs/namespace.c:3456 [inline] __se_sys_mount+0x2f9/0x3b0 fs/namespace.c:3433 do_syscall_64+0x3f/0xb0 arch/x86/entry/common.c:47 entry_SYSCALL_64_after_hwframe+0x44/0xae
The root cause is multi f2fs filesystem instances can race on accessing global fsync_entry_slab pointer, result in use-after-free issue of slab cache, fixes to init/destroy this slab cache only once during module init/destroy procedure to avoid this issue.(CVE-2021-47335)
In the Linux kernel, the following vulnerability has been resolved:
hwmon: (mlxreg-fan) Return non-zero value when fan current state is enforced from sysfs
Fan speed minimum can be enforced from sysfs. For example, setting current fan speed to 20 is used to enforce fan speed to be at 100% speed, 19 - to be not below 90% speed, etcetera. This feature provides ability to limit fan speed according to some system wise considerations, like absence of some replaceable units or high system ambient temperature.
Request for changing fan minimum speed is configuration request and can be set only through 'sysfs' write procedure. In this situation value of argument 'state' is above nominal fan speed maximum.
Return non-zero code in this case to avoid thermal_cooling_device_stats_update() call, because in this case statistics update violates thermal statistics table range. The issues is observed in case kernel is configured with option CONFIG_THERMAL_STATISTICS.
Here is the trace from KASAN: [ 159.506659] BUG: KASAN: slab-out-of-bounds in thermal_cooling_device_stats_update+0x7d/0xb0 [ 159.516016] Read of size 4 at addr ffff888116163840 by task hw-management.s/7444 [ 159.545625] Call Trace: [ 159.548366] dump_stack+0x92/0xc1 [ 159.552084] ? thermal_cooling_device_stats_update+0x7d/0xb0 [ 159.635869] thermal_zone_device_update+0x345/0x780 [ 159.688711] thermal_zone_device_set_mode+0x7d/0xc0 [ 159.694174] mlxsw_thermal_modules_init+0x48f/0x590 [mlxsw_core] [ 159.700972] ? mlxsw_thermal_set_cur_state+0x5a0/0x5a0 [mlxsw_core] [ 159.731827] mlxsw_thermal_init+0x763/0x880 [mlxsw_core] [ 160.070233] RIP: 0033:0x7fd995909970 [ 160.074239] Code: 73 01 c3 48 8b 0d 28 d5 2b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d 99 2d 2c 00 00 75 10 b8 01 00 00 00 0f 05 <48> 3d 01 f0 ff .. [ 160.095242] RSP: 002b:00007fff54f5d938 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ 160.103722] RAX: ffffffffffffffda RBX: 0000000000000013 RCX: 00007fd995909970 [ 160.111710] RDX: 0000000000000013 RSI: 0000000001906008 RDI: 0000000000000001 [ 160.119699] RBP: 0000000001906008 R08: 00007fd995bc9760 R09: 00007fd996210700 [ 160.127687] R10: 0000000000000073 R11: 0000000000000246 R12: 0000000000000013 [ 160.135673] R13: 0000000000000001 R14: 00007fd995bc8600 R15: 0000000000000013 [ 160.143671] [ 160.145338] Allocated by task 2924: [ 160.149242] kasan_save_stack+0x19/0x40 [ 160.153541] __kasan_kmalloc+0x7f/0xa0 [ 160.157743] __kmalloc+0x1a2/0x2b0 [ 160.161552] thermal_cooling_device_setup_sysfs+0xf9/0x1a0 [ 160.167687] __thermal_cooling_device_register+0x1b5/0x500 [ 160.173833] devm_thermal_of_cooling_device_register+0x60/0xa0 [ 160.180356] mlxreg_fan_probe+0x474/0x5e0 [mlxreg_fan] [ 160.248140] [ 160.249807] The buggy address belongs to the object at ffff888116163400 [ 160.249807] which belongs to the cache kmalloc-1k of size 1024 [ 160.263814] The buggy address is located 64 bytes to the right of [ 160.263814] 1024-byte region [ffff888116163400, ffff888116163800) [ 160.277536] The buggy address belongs to the page: [ 160.282898] page:0000000012275840 refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888116167000 pfn:0x116160 [ 160.294872] head:0000000012275840 order:3 compound_mapcount:0 compound_pincount:0 [ 160.303251] flags: 0x200000000010200(slab|head|node=0|zone=2) [ 160.309694] raw: 0200000000010200 ffffea00046f7208 ffffea0004928208 ffff88810004dbc0 [ 160.318367] raw: ffff888116167000 00000000000a0006 00000001ffffffff 0000000000000000 [ 160.327033] page dumped because: kasan: bad access detected [ 160.333270] [ 160.334937] Memory state around the buggy address: [ 160.356469] >ffff888116163800: fc ..(CVE-2021-47393)
In the Linux kernel, the following vulnerability has been resolved:
ptp: Fix possible memory leak in ptp_clock_register()
I got memory leak as follows when doing fault injection test:
unreferenced object 0xffff88800906c618 (size 8): comm "i2c-idt82p33931", pid 4421, jiffies 4294948083 (age 13.188s) hex dump (first 8 bytes): 70 74 70 30 00 00 00 00 ptp0.... backtrace: [<00000000312ed458>] __kmalloc_track_caller+0x19f/0x3a0 [<0000000079f6e2ff>] kvasprintf+0xb5/0x150 [<0000000026aae54f>] kvasprintf_const+0x60/0x190 [<00000000f323a5f7>] kobject_set_name_vargs+0x56/0x150 [<000000004e35abdd>] dev_set_name+0xc0/0x100 [<00000000f20cfe25>] ptp_clock_register+0x9f4/0xd30 [ptp] [<000000008bb9f0de>] idt82p33_probe.cold+0x8b6/0x1561 [ptp_idt82p33]
When posix_clock_register() returns an error, the name allocated in dev_set_name() will be leaked, the put_device() should be used to give up the device reference, then the name will be freed in kobject_cleanup() and other memory will be freed in ptp_clock_release().(CVE-2021-47455)
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Fix a memory leak in an error path of qla2x00_process_els()
Commit 8c0eb596baa5 ("[SCSI] qla2xxx: Fix a memory leak in an error path of qla2x00_process_els()"), intended to change:
bsg_job->request->msgcode == FC_BSG_HST_ELS_NOLOGIN
bsg_job->request->msgcode != FC_BSG_RPT_ELS
but changed it to:
bsg_job->request->msgcode == FC_BSG_RPT_ELS
instead.
Change the == to a != to avoid leaking the fcport structure or freeing unallocated memory.(CVE-2021-47473)
In the Linux kernel, the following vulnerability has been resolved:
nvmem: Fix shift-out-of-bound (UBSAN) with byte size cells
If a cell has 'nbits' equal to a multiple of BITS_PER_BYTE the logic
*p &= GENMASK((cell->nbits%BITS_PER_BYTE) - 1, 0);
will become undefined behavior because nbits modulo BITS_PER_BYTE is 0, and we subtract one from that making a large number that is then shifted more than the number of bits that fit into an unsigned long.
UBSAN reports this problem:
UBSAN: shift-out-of-bounds in drivers/nvmem/core.c:1386:8 shift exponent 64 is too large for 64-bit type 'unsigned long' CPU: 6 PID: 7 Comm: kworker/u16:0 Not tainted 5.15.0-rc3+ #9 Hardware name: Google Lazor (rev3+) with KB Backlight (DT) Workqueue: events_unbound deferred_probe_work_func Call trace: dump_backtrace+0x0/0x170 show_stack+0x24/0x30 dump_stack_lvl+0x64/0x7c dump_stack+0x18/0x38 ubsan_epilogue+0x10/0x54 __ubsan_handle_shift_out_of_bounds+0x180/0x194 __nvmem_cell_read+0x1ec/0x21c nvmem_cell_read+0x58/0x94 nvmem_cell_read_variable_common+0x4c/0xb0 nvmem_cell_read_variable_le_u32+0x40/0x100 a6xx_gpu_init+0x170/0x2f4 adreno_bind+0x174/0x284 component_bind_all+0xf0/0x264 msm_drm_bind+0x1d8/0x7a0 try_to_bring_up_master+0x164/0x1ac __component_add+0xbc/0x13c component_add+0x20/0x2c dp_display_probe+0x340/0x384 platform_probe+0xc0/0x100 really_probe+0x110/0x304 __driver_probe_device+0xb8/0x120 driver_probe_device+0x4c/0xfc __device_attach_driver+0xb0/0x128 bus_for_each_drv+0x90/0xdc __device_attach+0xc8/0x174 device_initial_probe+0x20/0x2c bus_probe_device+0x40/0xa4 deferred_probe_work_func+0x7c/0xb8 process_one_work+0x128/0x21c process_scheduled_works+0x40/0x54 worker_thread+0x1ec/0x2a8 kthread+0x138/0x158 ret_from_fork+0x10/0x20
Fix it by making sure there are any bits to mask out.(CVE-2021-47497)
In the Linux kernel, the following vulnerability has been resolved:
scsi: mpt3sas: Fix use-after-free warning
Fix the following use-after-free warning which is observed during controller reset:
refcount_t: underflow; use-after-free. WARNING: CPU: 23 PID: 5399 at lib/refcount.c:28 refcount_warn_saturate+0xa6/0xf0(CVE-2022-48695)
In the Linux kernel, the following vulnerability has been resolved:
nvmet: fix a use-after-free
Fix the following use-after-free complaint triggered by blktests nvme/004:
BUG: KASAN: user-memory-access in blk_mq_complete_request_remote+0xac/0x350 Read of size 4 at addr 0000607bd1835943 by task kworker/13:1/460 Workqueue: nvmet-wq nvme_loop_execute_work [nvme_loop] Call Trace: show_stack+0x52/0x58 dump_stack_lvl+0x49/0x5e print_report.cold+0x36/0x1e2 kasan_report+0xb9/0xf0 __asan_load4+0x6b/0x80 blk_mq_complete_request_remote+0xac/0x350 nvme_loop_queue_response+0x1df/0x275 [nvme_loop] __nvmet_req_complete+0x132/0x4f0 [nvmet] nvmet_req_complete+0x15/0x40 [nvmet] nvmet_execute_io_connect+0x18a/0x1f0 [nvmet] nvme_loop_execute_work+0x20/0x30 [nvme_loop] process_one_work+0x56e/0xa70 worker_thread+0x2d1/0x640 kthread+0x183/0x1c0 ret_from_fork+0x1f/0x30(CVE-2022-48697)
In the Linux kernel, the following vulnerability has been resolved:
ALSA: emu10k1: Fix out of bounds access in snd_emu10k1_pcm_channel_alloc()
The voice allocator sometimes begins allocating from near the end of the array and then wraps around, however snd_emu10k1_pcm_channel_alloc() accesses the newly allocated voices as if it never wrapped around.
This results in out of bounds access if the first voice has a high enough index so that first_voice + requested_voice_count > NUM_G (64). The more voices are requested, the more likely it is for this to occur.
This was initially discovered using PipeWire, however it can be reproduced by calling aplay multiple times with 16 channels: aplay -r 48000 -D plughw:CARD=Live,DEV=3 -c 16 /dev/zero
UBSAN: array-index-out-of-bounds in sound/pci/emu10k1/emupcm.c:127:40 index 65 is out of range for type 'snd_emu10k1_voice [64]' CPU: 1 PID: 31977 Comm: aplay Tainted: G W IOE 6.0.0-rc2-emu10k1+ #7 Hardware name: ASUSTEK COMPUTER INC P5W DH Deluxe/P5W DH Deluxe, BIOS 3002 07/22/2010 Call Trace: <TASK> dump_stack_lvl+0x49/0x63 dump_stack+0x10/0x16 ubsan_epilogue+0x9/0x3f __ubsan_handle_out_of_bounds.cold+0x44/0x49 snd_emu10k1_playback_hw_params+0x3bc/0x420 [snd_emu10k1] snd_pcm_hw_params+0x29f/0x600 [snd_pcm] snd_pcm_common_ioctl+0x188/0x1410 [snd_pcm] ? exit_to_user_mode_prepare+0x35/0x170 ? do_syscall_64+0x69/0x90 ? syscall_exit_to_user_mode+0x26/0x50 ? do_syscall_64+0x69/0x90 ? exit_to_user_mode_prepare+0x35/0x170 snd_pcm_ioctl+0x27/0x40 [snd_pcm] __x64_sys_ioctl+0x95/0xd0 do_syscall_64+0x5c/0x90 ? do_syscall_64+0x69/0x90 ? do_syscall_64+0x69/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd(CVE-2022-48702)
In the Linux kernel, the following vulnerability has been resolved:
drm/radeon: add a force flush to delay work when radeon
Although radeon card fence and wait for gpu to finish processing current batch rings, there is still a corner case that radeon lockup work queue may not be fully flushed, and meanwhile the radeon_suspend_kms() function has called pci_set_power_state() to put device in D3hot state. Per PCI spec rev 4.0 on 5.3.1.4.1 D3hot State. > Configuration and Message requests are the only TLPs accepted by a Function in > the D3hot state. All other received Requests must be handled as Unsupported Requests, > and all received Completions may optionally be handled as Unexpected Completions. This issue will happen in following logs: Unable to handle kernel paging request at virtual address 00008800e0008010 CPU 0 kworker/0:3(131): Oops 0 pc = [<ffffffff811bea5c>] ra = [<ffffffff81240844>] ps = 0000 Tainted: G W pc is at si_gpu_check_soft_reset+0x3c/0x240 ra is at si_dma_is_lockup+0x34/0xd0 v0 = 0000000000000000 t0 = fff08800e0008010 t1 = 0000000000010000 t2 = 0000000000008010 t3 = fff00007e3c00000 t4 = fff00007e3c00258 t5 = 000000000000ffff t6 = 0000000000000001 t7 = fff00007ef078000 s0 = fff00007e3c016e8 s1 = fff00007e3c00000 s2 = fff00007e3c00018 s3 = fff00007e3c00000 s4 = fff00007fff59d80 s5 = 0000000000000000 s6 = fff00007ef07bd98 a0 = fff00007e3c00000 a1 = fff00007e3c016e8 a2 = 0000000000000008 a3 = 0000000000000001 a4 = 8f5c28f5c28f5c29 a5 = ffffffff810f4338 t8 = 0000000000000275 t9 = ffffffff809b66f8 t10 = ff6769c5d964b800 t11= 000000000000b886 pv = ffffffff811bea20 at = 0000000000000000 gp = ffffffff81d89690 sp = 00000000aa814126 Disabling lock debugging due to kernel taint Trace: [<ffffffff81240844>] si_dma_is_lockup+0x34/0xd0 [<ffffffff81119610>] radeon_fence_check_lockup+0xd0/0x290 [<ffffffff80977010>] process_one_work+0x280/0x550 [<ffffffff80977350>] worker_thread+0x70/0x7c0 [<ffffffff80977410>] worker_thread+0x130/0x7c0 [<ffffffff80982040>] kthread+0x200/0x210 [<ffffffff809772e0>] worker_thread+0x0/0x7c0 [<ffffffff80981f8c>] kthread+0x14c/0x210 [<ffffffff80911658>] ret_from_kernel_thread+0x18/0x20 [<ffffffff80981e40>] kthread+0x0/0x210 Code: ad3e0008 43f0074a ad7e0018 ad9e0020 8c3001e8 40230101 <88210000> 4821ed21 So force lockup work queue flush to fix this problem.(CVE-2022-48704)
In the Linux kernel, the following vulnerability has been resolved:
drm/radeon: fix a possible null pointer dereference
In radeon_fp_native_mode(), the return value of drm_mode_duplicate() is assigned to mode, which will lead to a NULL pointer dereference on failure of drm_mode_duplicate(). Add a check to avoid npd.
The failure status of drm_cvt_mode() on the other path is checked too.(CVE-2022-48710)
In the Linux kernel, the following vulnerability has been resolved:
drm/tegra: dsi: Add missing check for of_find_device_by_node
Add check for the return value of of_find_device_by_node() and return the error if it fails in order to avoid NULL pointer dereference.(CVE-2023-52650)
In the Linux kernel, the following vulnerability has been resolved:
NTB: fix possible name leak in ntb_register_device()
If device_register() fails in ntb_register_device(), the device name allocated by dev_set_name() should be freed. As per the comment in device_register(), callers should use put_device() to give up the reference in the error path. So fix this by calling put_device() in the error path so that the name can be freed in kobject_cleanup().
As a result of this, put_device() in the error path of ntb_register_device() is removed and the actual error is returned.
In the Linux kernel, the following vulnerability has been resolved:
SUNRPC: fix a memleak in gss_import_v2_context
The ctx->mech_used.data allocated by kmemdup is not freed in neither gss_import_v2_context nor it only caller gss_krb5_import_sec_context, which frees ctx on error.
Thus, this patch reform the last call of gss_import_v2_context to the gss_krb5_import_ctx_v2, preventing the memleak while keepping the return formation.(CVE-2023-52653)
In the Linux kernel, the following vulnerability has been resolved:
io_uring: drop any code related to SCM_RIGHTS
This is dead code after we dropped support for passing io_uring fds over SCM_RIGHTS, get rid of it.(CVE-2023-52656)
In the Linux kernel, the following vulnerability has been resolved:
ACPI: LPIT: Avoid u32 multiplication overflow
In lpit_update_residency() there is a possibility of overflow in multiplication, if tsc_khz is large enough (> UINT_MAX/1000).
Change multiplication to mul_u32_u32().
Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2023-52683)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/pm: fix a double-free in si_dpm_init
When the allocation of adev->pm.dpm.dyn_state.vddc_dependency_on_dispclk.entries fails, amdgpu_free_extended_power_table is called to free some fields of adev. However, when the control flow returns to si_dpm_sw_init, it goes to label dpm_failed and calls si_dpm_fini, which calls amdgpu_free_extended_power_table again and free those fields again. Thus a double-free is triggered.(CVE-2023-52691)
In the Linux kernel, the following vulnerability has been resolved:
calipso: fix memory leak in netlbl_calipso_add_pass()
If IPv6 support is disabled at boot (ipv6.disable=1), the calipso_init() -> netlbl_calipso_ops_register() function isn't called, and the netlbl_calipso_ops_get() function always returns NULL. In this case, the netlbl_calipso_add_pass() function allocates memory for the doi_def variable but doesn't free it with the calipso_doi_free().
BUG: memory leak unreferenced object 0xffff888011d68180 (size 64): comm "syz-executor.1", pid 10746, jiffies 4295410986 (age 17.928s) hex dump (first 32 bytes): 00 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<...>] kmalloc include/linux/slab.h:552 [inline] [<...>] netlbl_calipso_add_pass net/netlabel/netlabel_calipso.c:76 [inline] [<...>] netlbl_calipso_add+0x22e/0x4f0 net/netlabel/netlabel_calipso.c:111 [<...>] genl_family_rcv_msg_doit+0x22f/0x330 net/netlink/genetlink.c:739 [<...>] genl_family_rcv_msg net/netlink/genetlink.c:783 [inline] [<...>] genl_rcv_msg+0x341/0x5a0 net/netlink/genetlink.c:800 [<...>] netlink_rcv_skb+0x14d/0x440 net/netlink/af_netlink.c:2515 [<...>] genl_rcv+0x29/0x40 net/netlink/genetlink.c:811 [<...>] netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline] [<...>] netlink_unicast+0x54b/0x800 net/netlink/af_netlink.c:1339 [<...>] netlink_sendmsg+0x90a/0xdf0 net/netlink/af_netlink.c:1934 [<...>] sock_sendmsg_nosec net/socket.c:651 [inline] [<...>] sock_sendmsg+0x157/0x190 net/socket.c:671 [<...>] _syssendmsg+0x712/0x870 net/socket.c:2342 [<...>] _sys_sendmsg+0xf8/0x170 net/socket.c:2396 [<...>] __sys_sendmsg+0xea/0x1b0 net/socket.c:2429 [<...>] do_syscall_64+0x30/0x40 arch/x86/entry/common.c:46 [<...>] entry_SYSCALL_64_after_hwframe+0x61/0xc6
Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with Syzkaller
PM: merged via the LSM tree at Jakub Kicinski request
In the Linux kernel, the following vulnerability has been resolved:
crypto: pcrypt - Fix hungtask for PADATA_RESET
We found a hungtask bug in test_aead_vec_cfg as follows:
INFO: task cryptomgr_test:391009 blocked for more than 120 seconds. "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Call trace: __switch_to+0x98/0xe0 __schedule+0x6c4/0xf40 schedule+0xd8/0x1b4 schedule_timeout+0x474/0x560 wait_for_common+0x368/0x4e0 wait_for_completion+0x20/0x30 wait_for_completion+0x20/0x30 test_aead_vec_cfg+0xab4/0xd50 test_aead+0x144/0x1f0 alg_test_aead+0xd8/0x1e0 alg_test+0x634/0x890 cryptomgr_test+0x40/0x70 kthread+0x1e0/0x220 ret_from_fork+0x10/0x18 Kernel panic - not syncing: hung_task: blocked tasks
For padata_do_parallel, when the return err is 0 or -EBUSY, it will call wait_for_completion(&wait->completion) in test_aead_vec_cfg. In normal case, aead_request_complete() will be called in pcrypt_aead_serial and the return err is 0 for padata_do_parallel. But, when pinst->flags is PADATA_RESET, the return err is -EBUSY for padata_do_parallel, and it won't call aead_request_complete(). Therefore, test_aead_vec_cfg will hung at wait_for_completion(&wait->completion), which will cause hungtask.
The problem comes as following: (padata_do_parallel) | rcu_read_lock_bh(); | err = -EINVAL; | (padata_replace) | pinst->flags |= PADATA_RESET; err = -EBUSY | if (pinst->flags & PADATA_RESET) | rcu_read_unlock_bh() | return err
In order to resolve the problem, we replace the return err -EBUSY with -EAGAIN, which means parallel_data is changing, and the caller should call it again.
v3: remove retry and just change the return err. v2: introduce padata_try_do_parallel() in pcrypt_aead_encrypt and pcrypt_aead_decrypt to solve the hungtask.(CVE-2023-52813)
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Fix a null pointer access when the smc_rreg pointer is NULL
In certain types of chips, such as VEGA20, reading the amdgpu_regs_smc file could result in an abnormal null pointer access when the smc_rreg pointer is NULL. Below are the steps to reproduce this issue and the corresponding exception log:
- Navigate to the directory: /sys/kernel/debug/dri/0
- Execute command: cat amdgpu_regs_smc
- Exception Log:: [4005007.702554] BUG: kernel NULL pointer dereference, address: 0000000000000000 [4005007.702562] #PF: supervisor instruction fetch in kernel mode [4005007.702567] #PF: error_code(0x0010) - not-present page [4005007.702570] PGD 0 P4D 0 [4005007.702576] Oops: 0010 [#1] SMP NOPTI [4005007.702581] CPU: 4 PID: 62563 Comm: cat Tainted: G OE 5.15.0-43-generic #46-Ubunt u [4005007.702590] RIP: 0010:0x0 [4005007.702598] Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6. [4005007.702600] RSP: 0018:ffffa82b46d27da0 EFLAGS: 00010206 [4005007.702605] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffa82b46d27e68 [4005007.702609] RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff9940656e0000 [4005007.702612] RBP: ffffa82b46d27dd8 R08: 0000000000000000 R09: ffff994060c07980 [4005007.702615] R10: 0000000000020000 R11: 0000000000000000 R12: 00007f5e06753000 [4005007.702618] R13: ffff9940656e0000 R14: ffffa82b46d27e68 R15: 00007f5e06753000 [4005007.702622] FS: 00007f5e0755b740(0000) GS:ffff99479d300000(0000) knlGS:0000000000000000 [4005007.702626] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [4005007.702629] CR2: ffffffffffffffd6 CR3: 00000003253fc000 CR4: 00000000003506e0 [4005007.702633] Call Trace: [4005007.702636] <TASK> [4005007.702640] amdgpu_debugfs_regs_smc_read+0xb0/0x120 [amdgpu] [4005007.703002] full_proxy_read+0x5c/0x80 [4005007.703011] vfs_read+0x9f/0x1a0 [4005007.703019] ksys_read+0x67/0xe0 [4005007.703023] __x64_sys_read+0x19/0x20 [4005007.703028] do_syscall_64+0x5c/0xc0 [4005007.703034] ? do_user_addr_fault+0x1e3/0x670 [4005007.703040] ? exit_to_user_mode_prepare+0x37/0xb0 [4005007.703047] ? irqentry_exit_to_user_mode+0x9/0x20 [4005007.703052] ? irqentry_exit+0x19/0x30 [4005007.703057] ? exc_page_fault+0x89/0x160 [4005007.703062] ? asm_exc_page_fault+0x8/0x30 [4005007.703068] entry_SYSCALL_64_after_hwframe+0x44/0xae [4005007.703075] RIP: 0033:0x7f5e07672992 [4005007.703079] Code: c0 e9 b2 fe ff ff 50 48 8d 3d fa b2 0c 00 e8 c5 1d 02 00 0f 1f 44 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 0f 05 <48> 3d 00 f0 ff ff 77 56 c3 0f 1f 44 00 00 48 83 e c 28 48 89 54 24 [4005007.703083] RSP: 002b:00007ffe03097898 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 [4005007.703088] RAX: ffffffffffffffda RBX: 0000000000020000 RCX: 00007f5e07672992 [4005007.703091] RDX: 0000000000020000 RSI: 00007f5e06753000 RDI: 0000000000000003 [4005007.703094] RBP: 00007f5e06753000 R08: 00007f5e06752010 R09: 00007f5e06752010 [4005007.703096] R10: 0000000000000022 R11: 0000000000000246 R12: 0000000000022000 [4005007.703099] R13: 0000000000000003 R14: 0000000000020000 R15: 0000000000020000 [4005007.703105] </TASK> [4005007.703107] Modules linked in: nf_tables libcrc32c nfnetlink algif_hash af_alg binfmt_misc nls_ iso8859_1 ipmi_ssif ast intel_rapl_msr intel_rapl_common drm_vram_helper drm_ttm_helper amd64_edac t tm edac_mce_amd kvm_amd ccp mac_hid k10temp kvm acpi_ipmi ipmi_si rapl sch_fq_codel ipmi_devintf ipm i_msghandler msr parport_pc ppdev lp parport mtd pstore_blk efi_pstore ramoops pstore_zone reed_solo mon ip_tables x_tables autofs4 ib_uverbs ib_core amdgpu(OE) amddrm_ttm_helper(OE) amdttm(OE) iommu_v 2 amd_sched(OE) amdkcl(OE) drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops cec rc_core drm igb ahci xhci_pci libahci i2c_piix4 i2c_algo_bit xhci_pci_renesas dca [4005007.703184] CR2: 0000000000000000 [4005007.703188] ---[ en ---truncated---(CVE-2023-52817)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd: Fix UBSAN array-index-out-of-bounds for SMU7
For pptable structs that use flexible array sizes, use flexible arrays.(CVE-2023-52818)
In the Linux kernel, the following vulnerability has been resolved:
perf/core: Bail out early if the request AUX area is out of bound
When perf-record with a large AUX area, e.g 4GB, it fails with:
#perf record -C 0 -m ,4G -e arm_spe_0// -- sleep 1
failed to mmap with 12 (Cannot allocate memory)
and it reveals a WARNING with __alloc_pages():
------------[ cut here ]------------
WARNING: CPU: 44 PID: 17573 at mm/page_alloc.c:5568 __alloc_pages+0x1ec/0x248
Call trace:
__alloc_pages+0x1ec/0x248
__kmalloc_large_node+0xc0/0x1f8
__kmalloc_node+0x134/0x1e8
rb_alloc_aux+0xe0/0x298
perf_mmap+0x440/0x660
mmap_region+0x308/0x8a8
do_mmap+0x3c0/0x528
vm_mmap_pgoff+0xf4/0x1b8
ksys_mmap_pgoff+0x18c/0x218
__arm64_sys_mmap+0x38/0x58
invoke_syscall+0x50/0x128
el0_svc_common.constprop.0+0x58/0x188
do_el0_svc+0x34/0x50
el0_svc+0x34/0x108
el0t_64_sync_handler+0xb8/0xc0
el0t_64_sync+0x1a4/0x1a8
'rb->aux_pages' allocated by kcalloc() is a pointer array which is used to maintains AUX trace pages. The allocated page for this array is physically contiguous (and virtually contiguous) with an order of 0..MAX_ORDER. If the size of pointer array crosses the limitation set by MAX_ORDER, it reveals a WARNING.
So bail out early with -ENOMEM if the request AUX area is out of bound, e.g.:
#perf record -C 0 -m ,4G -e arm_spe_0// -- sleep 1
failed to mmap with 12 (Cannot allocate memory)(CVE-2023-52835)
In the Linux kernel, the following vulnerability has been resolved:
Input: synaptics-rmi4 - fix use after free in rmi_unregister_function()
The put_device() calls rmi_release_function() which frees "fn" so the dereference on the next line "fn->num_of_irqs" is a use after free. Move the put_device() to the end to fix this.(CVE-2023-52840)
In the Linux kernel, the following vulnerability has been resolved:
media: bttv: fix use after free error due to btv->timeout timer
There may be some a race condition between timer function bttv_irq_timeout and bttv_remove. The timer is setup in probe and there is no timer_delete operation in remove function. When it hit kfree btv, the function might still be invoked, which will cause use after free bug.
This bug is found by static analysis, it may be false positive.
Fix it by adding del_timer_sync invoking to the remove function.
cpu0 cpu1 bttv_probe ->timer_setup ->bttv_set_dma ->mod_timer; bttv_remove ->kfree(btv); ->bttv_irq_timeout ->USE btv(CVE-2023-52847)
In the Linux kernel, the following vulnerability has been resolved:
drm/radeon: possible buffer overflow
Buffer 'afmt_status' of size 6 could overflow, since index 'afmt_idx' is checked after access.(CVE-2023-52867)
In the Linux kernel, the following vulnerability has been resolved:
thermal: core: prevent potential string overflow
The dev->id value comes from ida_alloc() so it's a number between zero and INT_MAX. If it's too high then these sprintf()s will overflow.(CVE-2023-52868)
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: prevent kernel bug at submit_bh_wbc()
Fix a bug where nilfs_get_block() returns a successful status when searching and inserting the specified block both fail inconsistently. If this inconsistent behavior is not due to a previously fixed bug, then an unexpected race is occurring, so return a temporary error -EAGAIN instead.
This prevents callers such as __block_write_begin_int() from requesting a read into a buffer that is not mapped, which would cause the BUG_ON check for the BH_Mapped flag in submit_bh_wbc() to fail.(CVE-2024-26955)
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix failure to detect DAT corruption in btree and direct mappings
Patch series "nilfs2: fix kernel bug at submit_bh_wbc()".
This resolves a kernel BUG reported by syzbot. Since there are two flaws involved, I've made each one a separate patch.
The first patch alone resolves the syzbot-reported bug, but I think both fixes should be sent to stable, so I've tagged them as such.
This patch (of 2):
Syzbot has reported a kernel bug in submit_bh_wbc() when writing file data to a nilfs2 file system whose metadata is corrupted.
There are two flaws involved in this issue.
The first flaw is that when nilfs_get_block() locates a data block using btree or direct mapping, if the disk address translation routine nilfs_dat_translate() fails with internal code -ENOENT due to DAT metadata corruption, it can be passed back to nilfs_get_block(). This causes nilfs_get_block() to misidentify an existing block as non-existent, causing both data block lookup and insertion to fail inconsistently.
The second flaw is that nilfs_get_block() returns a successful status in this inconsistent state. This causes the caller __block_write_begin_int() or others to request a read even though the buffer is not mapped, resulting in a BUG_ON check for the BH_Mapped flag in submit_bh_wbc() failing.
This fixes the first issue by changing the return value to code -EINVAL when a conversion using DAT fails with code -ENOENT, avoiding the conflicting condition that leads to the kernel bug described above. Here, code -EINVAL indicates that metadata corruption was detected during the block lookup, which will be properly handled as a file system error and converted to -EIO when passing through the nilfs2 bmap layer.(CVE-2024-26956)
In the Linux kernel, the following vulnerability has been resolved:
s390/zcrypt: fix reference counting on zcrypt card objects
Tests with hot-plugging crytpo cards on KVM guests with debug kernel build revealed an use after free for the load field of the struct zcrypt_card. The reason was an incorrect reference handling of the zcrypt card object which could lead to a free of the zcrypt card object while it was still in use.
This is an example of the slab message:
kernel: 0x00000000885a7512-0x00000000885a7513 @offset=1298. First byte 0x68 instead of 0x6b
kernel: Allocated in zcrypt_card_alloc+0x36/0x70 [zcrypt] age=18046 cpu=3 pid=43
kernel: kmalloc_trace+0x3f2/0x470
kernel: zcrypt_card_alloc+0x36/0x70 [zcrypt]
kernel: zcrypt_cex4_card_probe+0x26/0x380 [zcrypt_cex4]
kernel: ap_device_probe+0x15c/0x290
kernel: really_probe+0xd2/0x468
kernel: driver_probe_device+0x40/0xf0
kernel: __device_attach_driver+0xc0/0x140
kernel: bus_for_each_drv+0x8c/0xd0
kernel: __device_attach+0x114/0x198
kernel: bus_probe_device+0xb4/0xc8
kernel: device_add+0x4d2/0x6e0
kernel: ap_scan_adapter+0x3d0/0x7c0
kernel: ap_scan_bus+0x5a/0x3b0
kernel: ap_scan_bus_wq_callback+0x40/0x60
kernel: process_one_work+0x26e/0x620
kernel: worker_thread+0x21c/0x440
kernel: Freed in zcrypt_card_put+0x54/0x80 [zcrypt] age=9024 cpu=3 pid=43
kernel: kfree+0x37e/0x418
kernel: zcrypt_card_put+0x54/0x80 [zcrypt]
kernel: ap_device_remove+0x4c/0xe0
kernel: device_release_driver_internal+0x1c4/0x270
kernel: bus_remove_device+0x100/0x188
kernel: device_del+0x164/0x3c0
kernel: device_unregister+0x30/0x90
kernel: ap_scan_adapter+0xc8/0x7c0
kernel: ap_scan_bus+0x5a/0x3b0
kernel: ap_scan_bus_wq_callback+0x40/0x60
kernel: process_one_work+0x26e/0x620
kernel: worker_thread+0x21c/0x440
kernel: kthread+0x150/0x168
kernel: __ret_from_fork+0x3c/0x58
kernel: ret_from_fork+0xa/0x30
kernel: Slab 0x00000372022169c0 objects=20 used=18 fp=0x00000000885a7c88 flags=0x3ffff00000000a00(workingset|slab|node=0|zone=1|lastcpupid=0x1ffff)
kernel: Object 0x00000000885a74b8 @offset=1208 fp=0x00000000885a7c88
kernel: Redzone 00000000885a74b0: bb bb bb bb bb bb bb bb ........
kernel: Object 00000000885a74b8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
kernel: Object 00000000885a74c8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
kernel: Object 00000000885a74d8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
kernel: Object 00000000885a74e8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
kernel: Object 00000000885a74f8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
kernel: Object 00000000885a7508: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 68 4b 6b 6b 6b a5 kkkkkkkkkkhKkkk.
kernel: Redzone 00000000885a7518: bb bb bb bb bb bb bb bb ........
kernel: Padding 00000000885a756c: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZ
kernel: CPU: 0 PID: 387 Comm: systemd-udevd Not tainted 6.8.0-HF #2
kernel: Hardware name: IBM 3931 A01 704 (KVM/Linux)
kernel: Call Trace:
kernel: [<00000000ca5ab5b8>] dump_stack_lvl+0x90/0x120
kernel: [<00000000c99d78bc>] check_bytes_and_report+0x114/0x140
kernel: [<00000000c99d53cc>] check_object+0x334/0x3f8
kernel: [<00000000c99d820c>] alloc_debug_processing+0xc4/0x1f8
kernel: [<00000000c99d852e>] get_partial_node.part.0+0x1ee/0x3e0
kernel: [<00000000c99d94ec>] ___slab_alloc+0xaf4/0x13c8
kernel: [<00000000c99d9e38>] __slab_alloc.constprop.0+0x78/0xb8
kernel: [<00000000c99dc8dc>] __kmalloc+0x434/0x590
kernel: [<00000000c9b4c0ce>] ext4_htree_store_dirent+0x4e/0x1c0
kernel: [<00000000c9b908a2>] htree_dirblock_to_tree+0x17a/0x3f0
kernel:
---truncated---(CVE-2024-26957)
In the Linux kernel, the following vulnerability has been resolved:
nfs: fix UAF in direct writes
In production we have been hitting the following warning consistently
------------[ cut here ]------------ refcount_t: underflow; use-after-free. WARNING: CPU: 17 PID: 1800359 at lib/refcount.c:28 refcount_warn_saturate+0x9c/0xe0 Workqueue: nfsiod nfs_direct_write_schedule_work [nfs] RIP: 0010:refcount_warn_saturate+0x9c/0xe0 PKRU: 55555554 Call Trace: <TASK> ? __warn+0x9f/0x130 ? refcount_warn_saturate+0x9c/0xe0 ? report_bug+0xcc/0x150 ? handle_bug+0x3d/0x70 ? exc_invalid_op+0x16/0x40 ? asm_exc_invalid_op+0x16/0x20 ? refcount_warn_saturate+0x9c/0xe0 nfs_direct_write_schedule_work+0x237/0x250 [nfs] process_one_work+0x12f/0x4a0 worker_thread+0x14e/0x3b0 ? ZSTD_getCParams_internal+0x220/0x220 kthread+0xdc/0x120 ? __btf_name_valid+0xa0/0xa0 ret_from_fork+0x1f/0x30
This is because we're completing the nfs_direct_request twice in a row.
The source of this is when we have our commit requests to submit, we process them and send them off, and then in the completion path for the commit requests we have
if (nfs_commit_end(cinfo.mds)) nfs_direct_write_complete(dreq);
However since we're submitting asynchronous requests we sometimes have one that completes before we submit the next one, so we end up calling complete on the nfs_direct_request twice.
The only other place we use nfs_generic_commit_list() is in __nfs_commit_inode, which wraps this call in a
nfs_commit_begin(); nfs_commit_end();
Which is a common pattern for this style of completion handling, one that is also repeated in the direct code with get_dreq()/put_dreq() calls around where we process events as well as in the completion paths.
Fix this by using the same pattern for the commit requests.
Before with my 200 node rocksdb stress running this warning would pop every 10ish minutes. With my patch the stress test has been running for several hours without popping.(CVE-2024-26958)
In the Linux kernel, the following vulnerability has been resolved:
mm: swap: fix race between free_swap_and_cache() and swapoff()
There was previously a theoretical window where swapoff() could run and teardown a swap_info_struct while a call to free_swap_and_cache() was running in another thread. This could cause, amongst other bad possibilities, swap_page_trans_huge_swapped() (called by free_swap_and_cache()) to access the freed memory for swap_map.
This is a theoretical problem and I haven't been able to provoke it from a test case. But there has been agreement based on code review that this is possible (see link below).
Fix it by using get_swap_device()/put_swap_device(), which will stall swapoff(). There was an extra check in _swap_info_get() to confirm that the swap entry was not free. This isn't present in get_swap_device() because it doesn't make sense in general due to the race between getting the reference and swapoff. So I've added an equivalent check directly in free_swap_and_cache().
Details of how to provoke one possible issue (thanks to David Hildenbrand for deriving this):
--8<-----
__swap_entry_free() might be the last user and result in "count == SWAP_HAS_CACHE".
swapoff->try_to_unuse() will stop as soon as soon as si->inuse_pages==0.
So the question is: could someone reclaim the folio and turn si->inuse_pages==0, before we completed swap_page_trans_huge_swapped().
Imagine the following: 2 MiB folio in the swapcache. Only 2 subpages are still references by swap entries.
Process 1 still references subpage 0 via swap entry. Process 2 still references subpage 1 via swap entry.
Process 1 quits. Calls free_swap_and_cache(). -> count == SWAP_HAS_CACHE [then, preempted in the hypervisor etc.]
Process 2 quits. Calls free_swap_and_cache(). -> count == SWAP_HAS_CACHE
Process 2 goes ahead, passes swap_page_trans_huge_swapped(), and calls __try_to_reclaim_swap().
__try_to_reclaim_swap()->folio_free_swap()->delete_from_swap_cache()-> put_swap_folio()->free_swap_slot()->swapcache_free_entries()-> swap_entry_free()->swap_range_free()-> ... WRITE_ONCE(si->inuse_pages, si->inuse_pages - nr_entries);
What stops swapoff to succeed after process 2 reclaimed the swap cache but before process1 finished its call to swap_page_trans_huge_swapped()?
--8<-----(CVE-2024-26960)
In the Linux kernel, the following vulnerability has been resolved:
mac802154: fix llsec key resources release in mac802154_llsec_key_del
mac802154_llsec_key_del() can free resources of a key directly without following the RCU rules for waiting before the end of a grace period. This may lead to use-after-free in case llsec_lookup_key() is traversing the list of keys in parallel with a key deletion:
refcount_t: addition on 0; use-after-free. WARNING: CPU: 4 PID: 16000 at lib/refcount.c:25 refcount_warn_saturate+0x162/0x2a0 Modules linked in: CPU: 4 PID: 16000 Comm: wpan-ping Not tainted 6.7.0 #19 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 RIP: 0010:refcount_warn_saturate+0x162/0x2a0 Call Trace: <TASK> llsec_lookup_key.isra.0+0x890/0x9e0 mac802154_llsec_encrypt+0x30c/0x9c0 ieee802154_subif_start_xmit+0x24/0x1e0 dev_hard_start_xmit+0x13e/0x690 sch_direct_xmit+0x2ae/0xbc0 __dev_queue_xmit+0x11dd/0x3c20 dgram_sendmsg+0x90b/0xd60 __sys_sendto+0x466/0x4c0 __x64_sys_sendto+0xe0/0x1c0 do_syscall_64+0x45/0xf0 entry_SYSCALL_64_after_hwframe+0x6e/0x76
Also, ieee802154_llsec_key_entry structures are not freed by mac802154_llsec_key_del():
unreferenced object 0xffff8880613b6980 (size 64): comm "iwpan", pid 2176, jiffies 4294761134 (age 60.475s) hex dump (first 32 bytes): 78 0d 8f 18 80 88 ff ff 22 01 00 00 00 00 ad de x......."....... 00 00 00 00 00 00 00 00 03 00 cd ab 00 00 00 00 ................ backtrace: [<ffffffff81dcfa62>] __kmem_cache_alloc_node+0x1e2/0x2d0 [<ffffffff81c43865>] kmalloc_trace+0x25/0xc0 [<ffffffff88968b09>] mac802154_llsec_key_add+0xac9/0xcf0 [<ffffffff8896e41a>] ieee802154_add_llsec_key+0x5a/0x80 [<ffffffff8892adc6>] nl802154_add_llsec_key+0x426/0x5b0 [<ffffffff86ff293e>] genl_family_rcv_msg_doit+0x1fe/0x2f0 [<ffffffff86ff46d1>] genl_rcv_msg+0x531/0x7d0 [<ffffffff86fee7a9>] netlink_rcv_skb+0x169/0x440 [<ffffffff86ff1d88>] genl_rcv+0x28/0x40 [<ffffffff86fec15c>] netlink_unicast+0x53c/0x820 [<ffffffff86fecd8b>] netlink_sendmsg+0x93b/0xe60 [<ffffffff86b91b35>] _syssendmsg+0xac5/0xca0 [<ffffffff86b9c3dd>] _sys_sendmsg+0x11d/0x1c0 [<ffffffff86b9c65a>] __sys_sendmsg+0xfa/0x1d0 [<ffffffff88eadbf5>] do_syscall_64+0x45/0xf0 [<ffffffff890000ea>] entry_SYSCALL_64_after_hwframe+0x6e/0x76
Handle the proper resource release in the RCU callback function mac802154_llsec_key_del_rcu().
Note that if llsec_lookup_key() finds a key, it gets a refcount via llsec_key_get() and locally copies key id from key_entry (which is a list element). So it's safe to call llsec_key_put() and free the list entry after the RCU grace period elapses.
Found by Linux Verification Center (linuxtesting.org).(CVE-2024-26961)
In the Linux kernel, the following vulnerability has been resolved:
clk: qcom: mmcc-msm8974: fix terminating of frequency table arrays
The frequency table arrays are supposed to be terminated with an empty element. Add such entry to the end of the arrays where it is missing in order to avoid possible out-of-bound access when the table is traversed by functions like qcom_find_freq() or qcom_find_freq_floor().
Only compile tested.(CVE-2024-26965)
In the Linux kernel, the following vulnerability has been resolved:
clk: qcom: mmcc-apq8084: fix terminating of frequency table arrays
The frequency table arrays are supposed to be terminated with an empty element. Add such entry to the end of the arrays where it is missing in order to avoid possible out-of-bound access when the table is traversed by functions like qcom_find_freq() or qcom_find_freq_floor().
Only compile tested.(CVE-2024-26966)
In the Linux kernel, the following vulnerability has been resolved:
clk: qcom: gcc-ipq8074: fix terminating of frequency table arrays
The frequency table arrays are supposed to be terminated with an empty element. Add such entry to the end of the arrays where it is missing in order to avoid possible out-of-bound access when the table is traversed by functions like qcom_find_freq() or qcom_find_freq_floor().
Only compile tested.(CVE-2024-26969)
In the Linux kernel, the following vulnerability has been resolved:
crypto: qat - resolve race condition during AER recovery
During the PCI AER system's error recovery process, the kernel driver may encounter a race condition with freeing the reset_data structure's memory. If the device restart will take more than 10 seconds the function scheduling that restart will exit due to a timeout, and the reset_data structure will be freed. However, this data structure is used for completion notification after the restart is completed, which leads to a UAF bug.
This results in a KFENCE bug notice.
BUG: KFENCE: use-after-free read in adf_device_reset_worker+0x38/0xa0 [intel_qat] Use-after-free read at 0x00000000bc56fddf (in kfence-#142): adf_device_reset_worker+0x38/0xa0 [intel_qat] process_one_work+0x173/0x340
To resolve this race condition, the memory associated to the container of the work_struct is freed on the worker if the timeout expired, otherwise on the function that schedules the worker. The timeout detection can be done by checking if the caller is still waiting for completion or not by using completion_done() function.(CVE-2024-26974)
In the Linux kernel, the following vulnerability has been resolved:
KVM: Always flush async #PF workqueue when vCPU is being destroyed
Always flush the per-vCPU async #PF workqueue when a vCPU is clearing its completion queue, e.g. when a VM and all its vCPUs is being destroyed. KVM must ensure that none of its workqueue callbacks is running when the last reference to the KVM module is put. Gifting a reference to the associated VM prevents the workqueue callback from dereferencing freed vCPU/VM memory, but does not prevent the KVM module from being unloaded before the callback completes.
Drop the misguided VM refcount gifting, as calling kvm_put_kvm() from async_pf_execute() if kvm_put_kvm() flushes the async #PF workqueue will result in deadlock. async_pf_execute() can't return until kvm_put_kvm() finishes, and kvm_put_kvm() can't return until async_pf_execute() finishes:
WARNING: CPU: 8 PID: 251 at virt/kvm/kvm_main.c:1435 kvm_put_kvm+0x2d/0x320 [kvm] Modules linked in: vhost_net vhost vhost_iotlb tap kvm_intel kvm irqbypass CPU: 8 PID: 251 Comm: kworker/8:1 Tainted: G W 6.6.0-rc1-e7af8d17224a-x86/gmem-vm #119 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Workqueue: events async_pf_execute [kvm] RIP: 0010:kvm_put_kvm+0x2d/0x320 [kvm] Call Trace: <TASK> async_pf_execute+0x198/0x260 [kvm] process_one_work+0x145/0x2d0 worker_thread+0x27e/0x3a0 kthread+0xba/0xe0 ret_from_fork+0x2d/0x50 ret_from_fork_asm+0x11/0x20 </TASK> ---[ end trace 0000000000000000 ]--- INFO: task kworker/8:1:251 blocked for more than 120 seconds. Tainted: G W 6.6.0-rc1-e7af8d17224a-x86/gmem-vm #119 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/8:1 state:D stack:0 pid:251 ppid:2 flags:0x00004000 Workqueue: events async_pf_execute [kvm] Call Trace: <TASK> __schedule+0x33f/0xa40 schedule+0x53/0xc0 schedule_timeout+0x12a/0x140 __wait_for_common+0x8d/0x1d0 __flush_work.isra.0+0x19f/0x2c0 kvm_clear_async_pf_completion_queue+0x129/0x190 [kvm] kvm_arch_destroy_vm+0x78/0x1b0 [kvm] kvm_put_kvm+0x1c1/0x320 [kvm] async_pf_execute+0x198/0x260 [kvm] process_one_work+0x145/0x2d0 worker_thread+0x27e/0x3a0 kthread+0xba/0xe0 ret_from_fork+0x2d/0x50 ret_from_fork_asm+0x11/0x20 </TASK>
If kvm_clear_async_pf_completion_queue() actually flushes the workqueue, then there's no need to gift async_pf_execute() a reference because all invocations of async_pf_execute() will be forced to complete before the vCPU and its VM are destroyed/freed. And that in turn fixes the module unloading bug as __fput() won't do module_put() on the last vCPU reference until the vCPU has been freed, e.g. if closing the vCPU file also puts the last reference to the KVM module.
Note that kvm_check_async_pf_completion() may also take the work item off the completion queue and so also needs to flush the work queue, as the work will not be seen by kvm_clear_async_pf_completion_queue(). Waiting on the workqueue could theoretically delay a vCPU due to waiting for the work to complete, but that's a very, very small chance, and likely a very small delay. kvm_arch_async_page_present_queued() unconditionally makes a new request, i.e. will effectively delay entering the guest, so the remaining work is really just:
trace_kvm_async_pf_completed(addr, cr2_or_gpa);
__kvm_vcpu_wake_up(vcpu);
mmput(mm);
and mmput() can't drop the last reference to the page tables if the vCPU is still alive, i.e. the vCPU won't get stuck tearing down page tables.
Add a helper to do the flushing, specifically to deal with "wakeup all" work items, as they aren't actually work items, i.e. are never placed in a workqueue. Trying to flush a bogus workqueue entry rightly makes __flush_work() complain (kudos to whoever added that sanity check).
Note, commit 5f6de5cbebee ("KVM: Prevent module exit until al ---truncated---(CVE-2024-26976)
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix OOB in nilfs_set_de_type
The size of the nilfs_type_by_mode array in the fs/nilfs2/dir.c file is defined as "S_IFMT >> S_SHIFT", but the nilfs_set_de_type() function, which uses this array, specifies the index to read from the array in the same way as "(mode & S_IFMT) >> S_SHIFT".
static void nilfs_set_de_type(struct nilfs_dir_entry de, struct inode inode) { umode_t mode = inode->i_mode;
de->file_type = nilfs_type_by_mode[(mode & S_IFMT)>>S_SHIFT]; // oob
}
However, when the index is determined this way, an out-of-bounds (OOB) error occurs by referring to an index that is 1 larger than the array size when the condition "mode & S_IFMT == S_IFMT" is satisfied. Therefore, a patch to resize the nilfs_type_by_mode array should be applied to prevent OOB errors.(CVE-2024-26981)
In the Linux kernel, the following vulnerability has been resolved:
Squashfs: check the inode number is not the invalid value of zero
Syskiller has produced an out of bounds access in fill_meta_index().
That out of bounds access is ultimately caused because the inode has an inode number with the invalid value of zero, which was not checked.
The reason this causes the out of bounds access is due to following sequence of events:
-
Fill_meta_index() is called to allocate (via empty_meta_index()) and fill a metadata index. It however suffers a data read error and aborts, invalidating the newly returned empty metadata index. It does this by setting the inode number of the index to zero, which means unused (zero is not a valid inode number).
-
When fill_meta_index() is subsequently called again on another read operation, locate_meta_index() returns the previous index because it matches the inode number of 0. Because this index has been returned it is expected to have been filled, and because it hasn't been, an out of bounds access is performed.
This patch adds a sanity check which checks that the inode number is not zero when the inode is created and returns -EINVAL if it is.
[phillip@squashfs.org.uk: whitespace fix] Link: https://lkml.kernel.org/r/20240409204723.446925-1-phillip@squashfs.org.uk(CVE-2024-26982)
In the Linux kernel, the following vulnerability has been resolved:
fs: sysfs: Fix reference leak in sysfs_break_active_protection()
The sysfs_break_active_protection() routine has an obvious reference leak in its error path. If the call to kernfs_find_and_get() fails then kn will be NULL, so the companion sysfs_unbreak_active_protection() routine won't get called (and would only cause an access violation by trying to dereference kn->parent if it was called). As a result, the reference to kobj acquired at the start of the function will never be released.
Fix the leak by adding an explicit kobject_put() call when kn is NULL.(CVE-2024-26993)
In the Linux kernel, the following vulnerability has been resolved:
speakup: Avoid crash on very long word
In case a console is set up really large and contains a really long word (> 256 characters), we have to stop before the length of the word buffer.(CVE-2024-26994)
In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: f_ncm: Fix UAF ncm object at re-bind after usb ep transport error
When ncm function is working and then stop usb0 interface for link down, eth_stop() is called. At this piont, accidentally if usb transport error should happen in usb_ep_enable(), 'in_ep' and/or 'out_ep' may not be enabled.
After that, ncm_disable() is called to disable for ncm unbind but gether_disconnect() is never called since 'in_ep' is not enabled.
As the result, ncm object is released in ncm unbind but 'dev->port_usb' associated to 'ncm->port' is not NULL.
And when ncm bind again to recover netdev, ncm object is reallocated but usb0 interface is already associated to previous released ncm object.
Therefore, once usb0 interface is up and eth_start_xmit() is called, released ncm object is dereferrenced and it might cause use-after-free memory.
[function unlink via configfs] usb0: eth_stop dev->port_usb=ffffff9b179c3200 --> error happens in usb_ep_enable(). NCM: ncm_disable: ncm=ffffff9b179c3200 --> no gether_disconnect() since ncm->port.in_ep->enabled is false. NCM: ncm_unbind: ncm unbind ncm=ffffff9b179c3200 NCM: ncm_free: ncm free ncm=ffffff9b179c3200 <-- released ncm
[function link via configfs] NCM: ncm_alloc: ncm alloc ncm=ffffff9ac4f8a000 NCM: ncm_bind: ncm bind ncm=ffffff9ac4f8a000 NCM: ncm_set_alt: ncm=ffffff9ac4f8a000 alt=0 usb0: eth_open dev->port_usb=ffffff9b179c3200 <-- previous released ncm usb0: eth_start dev->port_usb=ffffff9b179c3200 <-- eth_start_xmit() --> dev->wrap() Unable to handle kernel paging request at virtual address dead00000000014f
This patch addresses the issue by checking if 'ncm->netdev' is not NULL at ncm_disable() to call gether_disconnect() to deassociate 'dev->port_usb'. It's more reasonable to check 'ncm->netdev' to call gether_connect/disconnect rather than check 'ncm->port.in_ep->enabled' since it might not be enabled but the gether connection might be established.(CVE-2024-26996)
In the Linux kernel, the following vulnerability has been resolved:
serial/pmac_zilog: Remove flawed mitigation for rx irq flood
The mitigation was intended to stop the irq completely. That may be better than a hard lock-up but it turns out that you get a crash anyway if you're using pmac_zilog as a serial console:
ttyPZ0: pmz: rx irq flood ! BUG: spinlock recursion on CPU#0, swapper/0
That's because the pr_err() call in pmz_receive_chars() results in pmz_console_write() attempting to lock a spinlock already locked in pmz_interrupt(). With CONFIG_DEBUG_SPINLOCK=y, this produces a fatal BUG splat. The spinlock in question is the one in struct uart_port.
Even when it's not fatal, the serial port rx function ceases to work. Also, the iteration limit doesn't play nicely with QEMU, as can be seen in the bug report linked below.
A web search for other reports of the error message "pmz: rx irq flood" didn't produce anything. So I don't think this code is needed any more. Remove it.(CVE-2024-26999)
In the Linux kernel, the following vulnerability has been resolved:
serial: mxs-auart: add spinlock around changing cts state
The uart_handle_cts_change() function in serial_core expects the caller to hold uport->lock. For example, I have seen the below kernel splat, when the Bluetooth driver is loaded on an i.MX28 board.
[ 85.119255] ------------[ cut here ]------------
[ 85.124413] WARNING: CPU: 0 PID: 27 at /drivers/tty/serial/serial_core.c:3453 uart_handle_cts_change+0xb4/0xec
[ 85.134694] Modules linked in: hci_uart bluetooth ecdh_generic ecc wlcore_sdio configfs
[ 85.143314] CPU: 0 PID: 27 Comm: kworker/u3:0 Not tainted 6.6.3-00021-gd62a2f068f92 #1
[ 85.151396] Hardware name: Freescale MXS (Device Tree)
[ 85.156679] Workqueue: hci0 hci_power_on [bluetooth]
(...)
[ 85.191765] uart_handle_cts_change from mxs_auart_irq_handle+0x380/0x3f4
[ 85.198787] mxs_auart_irq_handle from __handle_irq_event_percpu+0x88/0x210
(...)(CVE-2024-27000)
In the Linux kernel, the following vulnerability has been resolved:
comedi: vmk80xx: fix incomplete endpoint checking
While vmk80xx does have endpoint checking implemented, some things can fall through the cracks. Depending on the hardware model, URBs can have either bulk or interrupt type, and current version of vmk80xx_find_usb_endpoints() function does not take that fully into account. While this warning does not seem to be too harmful, at the very least it will crash systems with 'panic_on_warn' set on them.
Fix the issue found by Syzkaller [1] by somewhat simplifying the endpoint checking process with usb_find_common_endpoints() and ensuring that only expected endpoint types are present.
This patch has not been tested on real hardware.
[1] Syzkaller report: usb 1-1: BOGUS urb xfer, pipe 1 != type 3 WARNING: CPU: 0 PID: 781 at drivers/usb/core/urb.c:504 usb_submit_urb+0xc4e/0x18c0 drivers/usb/core/urb.c:503 ... Call Trace: <TASK> usb_start_wait_urb+0x113/0x520 drivers/usb/core/message.c:59 vmk80xx_reset_device drivers/comedi/drivers/vmk80xx.c:227 [inline] vmk80xx_auto_attach+0xa1c/0x1a40 drivers/comedi/drivers/vmk80xx.c:818 comedi_auto_config+0x238/0x380 drivers/comedi/drivers.c:1067 usb_probe_interface+0x5cd/0xb00 drivers/usb/core/driver.c:399 ...
Similar issue also found by Syzkaller:(CVE-2024-27001)
In the Linux kernel, the following vulnerability has been resolved:
drm: nv04: Fix out of bounds access
When Output Resource (dcb->or) value is assigned in fabricate_dcb_output(), there may be out of bounds access to dac_users array in case dcb->or is zero because ffs(dcb->or) is used as index there. The 'or' argument of fabricate_dcb_output() must be interpreted as a number of bit to set, not value.
Utilize macros from 'enum nouveau_or' in calls instead of hardcoding.
Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-27008)
In the Linux kernel, the following vulnerability has been resolved:
net/sched: Fix mirred deadlock on device recursion
When the mirred action is used on a classful egress qdisc and a packet is mirrored or redirected to self we hit a qdisc lock deadlock. See trace below.
[..... other info removed for brevity....] [ 82.890906] [ 82.890906] ============================================ [ 82.890906] WARNING: possible recursive locking detected [ 82.890906] 6.8.0-05205-g77fadd89fe2d-dirty #213 Tainted: G W [ 82.890906] -------------------------------------------- [ 82.890906] ping/418 is trying to acquire lock: [ 82.890906] ffff888006994110 (&sch->q.lock){+.-.}-{3:3}, at: __dev_queue_xmit+0x1778/0x3550 [ 82.890906] [ 82.890906] but task is already holding lock: [ 82.890906] ffff888006994110 (&sch->q.lock){+.-.}-{3:3}, at: __dev_queue_xmit+0x1778/0x3550 [ 82.890906] [ 82.890906] other info that might help us debug this: [ 82.890906] Possible unsafe locking scenario: [ 82.890906] [ 82.890906] CPU0 [ 82.890906] ---- [ 82.890906] lock(&sch->q.lock); [ 82.890906] lock(&sch->q.lock); [ 82.890906] [ 82.890906] *** DEADLOCK *** [ 82.890906] [..... other info removed for brevity....]
Example setup (eth0->eth0) to recreate tc qdisc add dev eth0 root handle 1: htb default 30 tc filter add dev eth0 handle 1: protocol ip prio 2 matchall \ action mirred egress redirect dev eth0
Another example(eth0->eth1->eth0) to recreate tc qdisc add dev eth0 root handle 1: htb default 30 tc filter add dev eth0 handle 1: protocol ip prio 2 matchall \ action mirred egress redirect dev eth1
tc qdisc add dev eth1 root handle 1: htb default 30 tc filter add dev eth1 handle 1: protocol ip prio 2 matchall \ action mirred egress redirect dev eth0
We fix this by adding an owner field (CPU id) to struct Qdisc set after root qdisc is entered. When the softirq enters it a second time, if the qdisc owner is the same CPU, the packet is dropped to break the loop.(CVE-2024-27010)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: fix memleak in map from abort path
The delete set command does not rely on the transaction object for element removal, therefore, a combination of delete element + delete set from the abort path could result in restoring twice the refcount of the mapping.
Check for inactive element in the next generation for the delete element command in the abort path, skip restoring state if next generation bit has been already cleared. This is similar to the activate logic using the set walk iterator.
[ 6170.286929] ------------[ cut here ]------------ [ 6170.286939] WARNING: CPU: 6 PID: 790302 at net/netfilter/nf_tables_api.c:2086 nf_tables_chain_destroy+0x1f7/0x220 [nf_tables] [ 6170.287071] Modules linked in: [...] [ 6170.287633] CPU: 6 PID: 790302 Comm: kworker/6:2 Not tainted 6.9.0-rc3+ #365 [ 6170.287768] RIP: 0010:nf_tables_chain_destroy+0x1f7/0x220 [nf_tables] [ 6170.287886] Code: df 48 8d 7d 58 e8 69 2e 3b df 48 8b 7d 58 e8 80 1b 37 df 48 8d 7d 68 e8 57 2e 3b df 48 8b 7d 68 e8 6e 1b 37 df 48 89 ef eb c4 <0f> 0b 48 83 c4 08 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 0f [ 6170.287895] RSP: 0018:ffff888134b8fd08 EFLAGS: 00010202 [ 6170.287904] RAX: 0000000000000001 RBX: ffff888125bffb28 RCX: dffffc0000000000 [ 6170.287912] RDX: 0000000000000003 RSI: ffffffffa20298ab RDI: ffff88811ebe4750 [ 6170.287919] RBP: ffff88811ebe4700 R08: ffff88838e812650 R09: fffffbfff0623a55 [ 6170.287926] R10: ffffffff8311d2af R11: 0000000000000001 R12: ffff888125bffb10 [ 6170.287933] R13: ffff888125bffb10 R14: dead000000000122 R15: dead000000000100 [ 6170.287940] FS: 0000000000000000(0000) GS:ffff888390b00000(0000) knlGS:0000000000000000 [ 6170.287948] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 6170.287955] CR2: 00007fd31fc00710 CR3: 0000000133f60004 CR4: 00000000001706f0 [ 6170.287962] Call Trace: [ 6170.287967] <TASK> [ 6170.287973] ? __warn+0x9f/0x1a0 [ 6170.287986] ? nf_tables_chain_destroy+0x1f7/0x220 [nf_tables] [ 6170.288092] ? report_bug+0x1b1/0x1e0 [ 6170.287986] ? nf_tables_chain_destroy+0x1f7/0x220 [nf_tables] [ 6170.288092] ? report_bug+0x1b1/0x1e0 [ 6170.288104] ? handle_bug+0x3c/0x70 [ 6170.288112] ? exc_invalid_op+0x17/0x40 [ 6170.288120] ? asm_exc_invalid_op+0x1a/0x20 [ 6170.288132] ? nf_tables_chain_destroy+0x2b/0x220 [nf_tables] [ 6170.288243] ? nf_tables_chain_destroy+0x1f7/0x220 [nf_tables] [ 6170.288366] ? nf_tables_chain_destroy+0x2b/0x220 [nf_tables] [ 6170.288483] nf_tables_trans_destroy_work+0x588/0x590 nf_tables
In the Linux kernel, the following vulnerability has been resolved:
net/rds: fix WARNING in rds_conn_connect_if_down
If connection isn't established yet, get_mr() will fail, trigger connection after get_mr().(CVE-2024-27024)
In the Linux kernel, the following vulnerability has been resolved:
spi: spi-mt65xx: Fix NULL pointer access in interrupt handler
The TX buffer in spi_transfer can be a NULL pointer, so the interrupt handler may end up writing to the invalid memory and cause crashes.
Add a check to trans->tx_buf before using it.(CVE-2024-27028)
In the Linux kernel, the following vulnerability has been resolved:
clk: zynq: Prevent null pointer dereference caused by kmalloc failure
The kmalloc() in zynq_clk_setup() will return null if the physical memory has run out. As a result, if we use snprintf() to write data to the null address, the null pointer dereference bug will happen.
This patch uses a stack variable to replace the kmalloc().(CVE-2024-27037)
In the Linux kernel, the following vulnerability has been resolved:
nfp: flower: handle acti_netdevs allocation failure
The kmalloc_array() in nfp_fl_lag_do_work() will return null, if the physical memory has run out. As a result, if we dereference the acti_netdevs, the null pointer dereference bugs will happen.
This patch adds a check to judge whether allocation failure occurs. If it happens, the delayed work will be rescheduled and try again.(CVE-2024-27046)
In the Linux kernel, the following vulnerability has been resolved:
cpufreq: brcmstb-avs-cpufreq: add check for cpufreq_cpu_get's return value
cpufreq_cpu_get may return NULL. To avoid NULL-dereference check it and return 0 in case of error.
Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-27051)
In the Linux kernel, the following vulnerability has been resolved:
s390/dasd: fix double module refcount decrement
Once the discipline is associated with the device, deleting the device takes care of decrementing the module's refcount. Doing it manually on this error path causes refcount to artificially decrease on each error while it should just stay the same.(CVE-2024-27054)
In the Linux kernel, the following vulnerability has been resolved:
USB: usb-storage: Prevent divide-by-0 error in isd200_ata_command
The isd200 sub-driver in usb-storage uses the HEADS and SECTORS values in the ATA ID information to calculate cylinder and head values when creating a CDB for READ or WRITE commands. The calculation involves division and modulus operations, which will cause a crash if either of these values is 0. While this never happens with a genuine device, it could happen with a flawed or subversive emulation, as reported by the syzbot fuzzer.
Protect against this possibility by refusing to bind to the device if either the ATA_ID_HEADS or ATA_ID_SECTORS value in the device's ID information is 0. This requires isd200_Initialization() to return a negative error code when initialization fails; currently it always returns 0 (even when there is an error).(CVE-2024-27059)
In the Linux kernel, the following vulnerability has been resolved:
nouveau: lock the client object tree.
It appears the client object tree has no locking unless I've missed something else. Fix races around adding/removing client objects, mostly vram bar mappings.
4562.099306] general protection fault, probably for non-canonical address 0x6677ed422bceb80c: 0000 [#1] PREEMPT SMP PTI [ 4562.099314] CPU: 2 PID: 23171 Comm: deqp-vk Not tainted 6.8.0-rc6+ #27 [ 4562.099324] Hardware name: Gigabyte Technology Co., Ltd. Z390 I AORUS PRO WIFI/Z390 I AORUS PRO WIFI-CF, BIOS F8 11/05/2021 [ 4562.099330] RIP: 0010:nvkm_object_search+0x1d/0x70 [nouveau] [ 4562.099503] Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 0f 1f 44 00 00 48 89 f8 48 85 f6 74 39 48 8b 87 a0 00 00 00 48 85 c0 74 12 <48> 8b 48 f8 48 39 ce 73 15 48 8b 40 10 48 85 c0 75 ee 48 c7 c0 fe [ 4562.099506] RSP: 0000:ffffa94cc420bbf8 EFLAGS: 00010206 [ 4562.099512] RAX: 6677ed422bceb814 RBX: ffff98108791f400 RCX: ffff9810f26b8f58 [ 4562.099517] RDX: 0000000000000000 RSI: ffff9810f26b9158 RDI: ffff98108791f400 [ 4562.099519] RBP: ffff9810f26b9158 R08: 0000000000000000 R09: 0000000000000000 [ 4562.099521] R10: ffffa94cc420bc48 R11: 0000000000000001 R12: ffff9810f02a7cc0 [ 4562.099526] R13: 0000000000000000 R14: 00000000000000ff R15: 0000000000000007 [ 4562.099528] FS: 00007f629c5017c0(0000) GS:ffff98142c700000(0000) knlGS:0000000000000000 [ 4562.099534] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 4562.099536] CR2: 00007f629a882000 CR3: 000000017019e004 CR4: 00000000003706f0 [ 4562.099541] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 4562.099542] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 4562.099544] Call Trace: [ 4562.099555] <TASK> [ 4562.099573] ? die_addr+0x36/0x90 [ 4562.099583] ? exc_general_protection+0x246/0x4a0 [ 4562.099593] ? asm_exc_general_protection+0x26/0x30 [ 4562.099600] ? nvkm_object_search+0x1d/0x70 [nouveau] [ 4562.099730] nvkm_ioctl+0xa1/0x250 [nouveau] [ 4562.099861] nvif_object_map_handle+0xc8/0x180 [nouveau] [ 4562.099986] nouveau_ttm_io_mem_reserve+0x122/0x270 [nouveau] [ 4562.100156] ? dma_resv_test_signaled+0x26/0xb0 [ 4562.100163] ttm_bo_vm_fault_reserved+0x97/0x3c0 [ttm] [ 4562.100182] ? __mutex_unlock_slowpath+0x2a/0x270 [ 4562.100189] nouveau_ttm_fault+0x69/0xb0 [nouveau] [ 4562.100356] __do_fault+0x32/0x150 [ 4562.100362] do_fault+0x7c/0x560 [ 4562.100369] __handle_mm_fault+0x800/0xc10 [ 4562.100382] handle_mm_fault+0x17c/0x3e0 [ 4562.100388] do_user_addr_fault+0x208/0x860 [ 4562.100395] exc_page_fault+0x7f/0x200 [ 4562.100402] asm_exc_page_fault+0x26/0x30 [ 4562.100412] RIP: 0033:0x9b9870 [ 4562.100419] Code: 85 a8 f7 ff ff 8b 8d 80 f7 ff ff 89 08 e9 18 f2 ff ff 0f 1f 84 00 00 00 00 00 44 89 32 e9 90 fa ff ff 0f 1f 84 00 00 00 00 00 <44> 89 32 e9 f8 f1 ff ff 0f 1f 84 00 00 00 00 00 66 44 89 32 e9 e7 [ 4562.100422] RSP: 002b:00007fff9ba2dc70 EFLAGS: 00010246 [ 4562.100426] RAX: 0000000000000004 RBX: 000000000dd65e10 RCX: 000000fff0000000 [ 4562.100428] RDX: 00007f629a882000 RSI: 00007f629a882000 RDI: 0000000000000066 [ 4562.100432] RBP: 00007fff9ba2e570 R08: 0000000000000000 R09: 0000000123ddf000 [ 4562.100434] R10: 0000000000000001 R11: 0000000000000246 R12: 000000007fffffff [ 4562.100436] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 4562.100446] </TASK> [ 4562.100448] Modules linked in: nf_conntrack_netbios_ns nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables libcrc32c nfnetlink cmac bnep sunrpc iwlmvm intel_rapl_msr intel_rapl_common snd_sof_pci_intel_cnl x86_pkg_temp_thermal intel_powerclamp snd_sof_intel_hda_common mac80211 coretemp snd_soc_acpi_intel_match kvm_intel snd_soc_acpi snd_soc_hdac_hda snd_sof_pci snd_sof_xtensa_dsp snd_sof_intel_hda_mlink ---truncated---(CVE-2024-27062)
In the Linux kernel, the following vulnerability has been resolved:
media: usbtv: Remove useless locks in usbtv_video_free()
Remove locks calls in usbtv_video_free() because are useless and may led to a deadlock as reported here: https://syzkaller.appspot.com/x/bisect.txt?x=166dc872180000 Also remove usbtv_stop() call since it will be called when unregistering the device.
Before 'c838530d230b' this issue would only be noticed if you disconnect while streaming and now it is noticeable even when disconnecting while not streaming.
hverkuil: fix minor spelling mistake in log message
In the Linux kernel, the following vulnerability has been resolved:
media: ttpci: fix two memleaks in budget_av_attach
When saa7146_register_device and saa7146_vv_init fails, budget_av_attach should free the resources it allocates, like the error-handling of ttpci_budget_init does. Besides, there are two fixme comment refers to such deallocations.(CVE-2024-27073)
In the Linux kernel, the following vulnerability has been resolved:
media: dvb-frontends: avoid stack overflow warnings with clang
A previous patch worked around a KASAN issue in stv0367, now a similar problem showed up with clang:
drivers/media/dvb-frontends/stv0367.c:1222:12: error: stack frame size (3624) exceeds limit (2048) in 'stv0367ter_set_frontend' [-Werror,-Wframe-larger-than] 1214 | static int stv0367ter_set_frontend(struct dvb_frontend *fe)
Rework the stv0367_writereg() function to be simpler and mark both register access functions as noinline_for_stack so the temporary i2c_msg structures do not get duplicated on the stack when KASAN_STACK is enabled.(CVE-2024-27075)
In the Linux kernel, the following vulnerability has been resolved:
media: v4l2-mem2mem: fix a memleak in v4l2_m2m_register_entity
The entity->name (i.e. name) is allocated in v4l2_m2m_register_entity but isn't freed in its following error-handling paths. This patch adds such deallocation to prevent memleak of entity->name.(CVE-2024-27077)
In the Linux kernel, the following vulnerability has been resolved:
media: v4l2-tpg: fix some memleaks in tpg_alloc
In tpg_alloc, resources should be deallocated in each and every error-handling paths, since they are allocated in for statements. Otherwise there would be memleaks because tpg_free is called only when tpg_alloc return 0.(CVE-2024-27078)
In the Linux kernel, the following vulnerability has been resolved:
SUNRPC: fix some memleaks in gssx_dec_option_array
The creds and oa->data need to be freed in the error-handling paths after their allocation. So this patch add these deallocations in the corresponding paths.(CVE-2024-27388)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nft_flow_offload: reset dst in route object after setting up flow
dst is transferred to the flow object, route object does not own it anymore. Reset dst in route object, otherwise if flow_offload_add() fails, error path releases dst twice, leading to a refcount underflow.(CVE-2024-27403)
In the Linux kernel, the following vulnerability has been resolved:
netrom: Fix data-races around sysctl_net_busy_read
We need to protect the reader reading the sysctl value because the value can be changed concurrently.(CVE-2024-27419)
Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2024-27426)
Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2024-27427)
Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2024-27428)
In the Linux kernel, the following vulnerability has been resolved:
dm snapshot: fix lockup in dm_exception_table_exit
There was reported lockup when we exit a snapshot with many exceptions. Fix this by adding "cond_resched" to the loop that frees the exceptions.(CVE-2024-35805)
In the Linux kernel, the following vulnerability has been resolved:
soc: fsl: qbman: Always disable interrupts when taking cgr_lock
smp_call_function_single disables IRQs when executing the callback. To prevent deadlocks, we must disable IRQs when taking cgr_lock elsewhere. This is already done by qman_update_cgr and qman_delete_cgr; fix the other lockers.(CVE-2024-35806)
In the Linux kernel, the following vulnerability has been resolved:
fs/aio: Check IOCB_AIO_RW before the struct aio_kiocb conversion
The first kiocb_set_cancel_fn() argument may point at a struct kiocb that is not embedded inside struct aio_kiocb. With the current code, depending on the compiler, the req->ki_ctx read happens either before the IOCB_AIO_RW test or after that test. Move the req->ki_ctx read such that it is guaranteed that the IOCB_AIO_RW test happens first.(CVE-2024-35815)
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: fix a double-free in arfs_create_groups
When in allocated by kvzalloc fails, arfs_create_groups will free
ft->g and return an error. However, arfs_create_table, the only caller of
arfs_create_groups, will hold this error and call to
mlx5e_destroy_flow_table, in which the ft->g will be freed again.(CVE-2024-35835)
In the Linux kernel, the following vulnerability has been resolved:
ipv6: Fix infinite recursion in fib6_dump_done().
syzkaller reported infinite recursive calls of fib6_dump_done() during netlink socket destruction. [1]
From the log, syzkaller sent an AF_UNSPEC RTM_GETROUTE message, and then the response was generated. The following recvmmsg() resumed the dump for IPv6, but the first call of inet6_dump_fib() failed at kzalloc() due to the fault injection. [0]
12:01:34 executing program 3: r0 = socket$nl_route(0x10, 0x3, 0x0) sendmsg$nl_route(r0, ... snip ...) recvmmsg(r0, ... snip ...) (fail_nth: 8)
Here, fib6_dump_done() was set to nlk_sk(sk)->cb.done, and the next call of inet6_dump_fib() set it to nlk_sk(sk)->cb.args[3]. syzkaller stopped receiving the response halfway through, and finally netlink_sock_destruct() called nlk_sk(sk)->cb.done().
fib6_dump_done() calls fib6_dump_end() and nlk_sk(sk)->cb.done() if it is still not NULL. fib6_dump_end() rewrites nlk_sk(sk)->cb.done() by nlk_sk(sk)->cb.args[3], but it has the same function, not NULL, calling itself recursively and hitting the stack guard page.
To avoid the issue, let's set the destructor after kzalloc().
[0]: FAULT_INJECTION: forcing a failure. name failslab, interval 1, probability 0, space 0, times 0 CPU: 1 PID: 432110 Comm: syz-executor.3 Not tainted 6.8.0-12821-g537c2e91d354-dirty #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> dump_stack_lvl (lib/dump_stack.c:117) should_fail_ex (lib/fault-inject.c:52 lib/fault-inject.c:153) should_failslab (mm/slub.c:3733) kmalloc_trace (mm/slub.c:3748 mm/slub.c:3827 mm/slub.c:3992) inet6_dump_fib (./include/linux/slab.h:628 ./include/linux/slab.h:749 net/ipv6/ip6_fib.c:662) rtnl_dump_all (net/core/rtnetlink.c:4029) netlink_dump (net/netlink/af_netlink.c:2269) netlink_recvmsg (net/netlink/af_netlink.c:1988) _sysrecvmsg (net/socket.c:1046 net/socket.c:2801) _sys_recvmsg (net/socket.c:2846) do_recvmmsg (net/socket.c:2943) __x64_sys_recvmmsg (net/socket.c:3041 net/socket.c:3034 net/socket.c:3034)
[1]: BUG: TASK stack guard page was hit at 00000000f2fa9af1 (stack is 00000000b7912430..000000009a436beb) stack guard page: 0000 [#1] PREEMPT SMP KASAN CPU: 1 PID: 223719 Comm: kworker/1:3 Not tainted 6.8.0-12821-g537c2e91d354-dirty #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 Workqueue: events netlink_sock_destruct_work RIP: 0010:fib6_dump_done (net/ipv6/ip6_fib.c:570) Code: 3c 24 e8 f3 e9 51 fd e9 28 fd ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 41 57 41 56 41 55 41 54 55 48 89 fd <53> 48 8d 5d 60 e8 b6 4d 07 fd 48 89 da 48 b8 00 00 00 00 00 fc ff RSP: 0018:ffffc9000d980000 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffffffff84405990 RCX: ffffffff844059d3 RDX: ffff8881028e0000 RSI: ffffffff84405ac2 RDI: ffff88810c02f358 RBP: ffff88810c02f358 R08: 0000000000000007 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000224 R12: 0000000000000000 R13: ffff888007c82c78 R14: ffff888007c82c68 R15: ffff888007c82c68 FS: 0000000000000000(0000) GS:ffff88811b100000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffc9000d97fff8 CR3: 0000000102309002 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace: <#DF> </#DF> <TASK> fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1)) fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1)) ... fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1)) fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1)) netlink_sock_destruct (net/netlink/af_netlink.c:401) __sk_destruct (net/core/sock.c:2177 (discriminator 2)) sk_destruct (net/core/sock.c:2224) __sk_free (net/core/sock.c:2235) sk_free (net/core/sock.c:2246) process_one_work (kernel/workqueue.c:3259) worker_thread (kernel/workqueue.c:3329 kernel/workqueue. ---truncated---(CVE-2024-35886)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: Fix potential data-race in __nft_flowtable_type_get()
nft_unregister_flowtable_type() within nf_flow_inet_module_exit() can concurrent with __nft_flowtable_type_get() within nf_tables_newflowtable(). And thhere is not any protection when iterate over nf_tables_flowtables list in __nft_flowtable_type_get(). Therefore, there is pertential data-race of nf_tables_flowtables list entry.
Use list_for_each_entry_rcu() to iterate over nf_tables_flowtables list in __nft_flowtable_type_get(), and use rcu_read_lock() in the caller nft_flowtable_type_get() to protect the entire type query process.(CVE-2024-35898)
In the Linux kernel, the following vulnerability has been resolved:
fbmon: prevent division by zero in fb_videomode_from_videomode()
The expression htotal * vtotal can have a zero value on overflow. It is necessary to prevent division by zero like in fb_var_to_videomode().
Found by Linux Verification Center (linuxtesting.org) with Svace.(CVE-2024-35922)
In the Linux kernel, the following vulnerability has been resolved:
scsi: lpfc: Fix possible memory leak in lpfc_rcv_padisc()
The call to lpfc_sli4_resume_rpi() in lpfc_rcv_padisc() may return an unsuccessful status. In such cases, the elsiocb is not issued, the completion is not called, and thus the elsiocb resource is leaked.
Check return value after calling lpfc_sli4_resume_rpi() and conditionally release the elsiocb resource.(CVE-2024-35930)
In the Linux kernel, the following vulnerability has been resolved:
btrfs: handle chunk tree lookup error in btrfs_relocate_sys_chunks()
The unhandled case in btrfs_relocate_sys_chunks() loop is a corruption, as it could be caused only by two impossible conditions:
-
at first the search key is set up to look for a chunk tree item, with offset -1, this is an inexact search and the key->offset will contain the correct offset upon a successful search, a valid chunk tree item cannot have an offset -1
-
after first successful search, the found_key corresponds to a chunk item, the offset is decremented by 1 before the next loop, it's impossible to find a chunk item there due to alignment and size constraints(CVE-2024-35936)
In the Linux kernel, the following vulnerability has been resolved:
drm/client: Fully protect modes[] with dev->mode_config.mutex
The modes[] array contains pointers to modes on the connectors' mode lists, which are protected by dev->mode_config.mutex. Thus we need to extend modes[] the same protection or by the time we use it the elements may already be pointing to freed/reused memory.(CVE-2024-35950)
In the Linux kernel, the following vulnerability has been resolved:
xsk: validate user input for XDP_{UMEM|COMPLETION}_FILL_RING
syzbot reported an illegal copy in xsk_setsockopt() [1]
Make sure to validate setsockopt() @optlen parameter.
[1]
BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline] BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline] BUG: KASAN: slab-out-of-bounds in xsk_setsockopt+0x909/0xa40 net/xdp/xsk.c:1420 Read of size 4 at addr ffff888028c6cde3 by task syz-executor.0/7549
CPU: 0 PID: 7549 Comm: syz-executor.0 Not tainted 6.8.0-syzkaller-08951-gfe46a7dd189e #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 copy_from_sockptr_offset include/linux/sockptr.h:49 [inline] copy_from_sockptr include/linux/sockptr.h:55 [inline] xsk_setsockopt+0x909/0xa40 net/xdp/xsk.c:1420 do_sock_setsockopt+0x3af/0x720 net/socket.c:2311 __sys_setsockopt+0x1ae/0x250 net/socket.c:2334 __do_sys_setsockopt net/socket.c:2343 [inline] __se_sys_setsockopt net/socket.c:2340 [inline] __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340 do_syscall_64+0xfb/0x240 entry_SYSCALL_64_after_hwframe+0x6d/0x75 RIP: 0033:0x7fb40587de69 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fb40665a0c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000036 RAX: ffffffffffffffda RBX: 00007fb4059abf80 RCX: 00007fb40587de69 RDX: 0000000000000005 RSI: 000000000000011b RDI: 0000000000000006 RBP: 00007fb4058ca47a R08: 0000000000000002 R09: 0000000000000000 R10: 0000000020001980 R11: 0000000000000246 R12: 0000000000000000 R13: 000000000000000b R14: 00007fb4059abf80 R15: 00007fff57ee4d08 </TASK>
Allocated by task 7549: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:370 [inline] __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:387 kasan_kmalloc include/linux/kasan.h:211 [inline] __do_kmalloc_node mm/slub.c:3966 [inline] __kmalloc+0x233/0x4a0 mm/slub.c:3979 kmalloc include/linux/slab.h:632 [inline] __cgroup_bpf_run_filter_setsockopt+0xd2f/0x1040 kernel/bpf/cgroup.c:1869 do_sock_setsockopt+0x6b4/0x720 net/socket.c:2293 __sys_setsockopt+0x1ae/0x250 net/socket.c:2334 __do_sys_setsockopt net/socket.c:2343 [inline] __se_sys_setsockopt net/socket.c:2340 [inline] __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340 do_syscall_64+0xfb/0x240 entry_SYSCALL_64_after_hwframe+0x6d/0x75
The buggy address belongs to the object at ffff888028c6cde0 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 1 bytes to the right of allocated 2-byte region [ffff888028c6cde0, ffff888028c6cde2)
The buggy address belongs to the physical page: page:ffffea0000a31b00 refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888028c6c9c0 pfn:0x28c6c anon flags: 0xfff00000000800(slab|node=0|zone=1|lastcpupid=0x7ff) page_type: 0xffffffff() raw: 00fff00000000800 ffff888014c41280 0000000000000000 dead000000000001 raw: ffff888028c6c9c0 0000000080800057 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected page_owner tracks the page as allocated page last allocated via order 0, migratetype Unmovable, gfp_mask 0x112cc0(GFP_USER|__GFP_NOWARN|__GFP_NORETRY), pid 6648, tgid 6644 (syz-executor.0), ts 133906047828, free_ts 133859922223 set_page_owner include/linux/page_owner.h:31 [inline] post_alloc_hook+0x1ea/0x210 mm/page_alloc.c:1533 prep_new_page mm/page_alloc.c: ---truncated---(CVE-2024-35976)
In the Linux kernel, the following vulnerability has been resolved:
HID: i2c-hid: remove I2C_HID_READ_PENDING flag to prevent lock-up
The flag I2C_HID_READ_PENDING is used to serialize I2C operations. However, this is not necessary, because I2C core already has its own locking for that.
More importantly, this flag can cause a lock-up: if the flag is set in i2c_hid_xfer() and an interrupt happens, the interrupt handler (i2c_hid_irq) will check this flag and return immediately without doing anything, then the interrupt handler will be invoked again in an infinite loop.
Since interrupt handler is an RT task, it takes over the CPU and the flag-clearing task never gets scheduled, thus we have a lock-up.
Delete this unnecessary flag.(CVE-2024-35997)
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"kernel-4.19.90-2405.5.0.0251.oe1.aarch64.rpm",
"kernel-debugsource-4.19.90-2405.5.0.0251.oe1.aarch64.rpm",
"perf-debuginfo-4.19.90-2405.5.0.0251.oe1.aarch64.rpm",
"kernel-tools-debuginfo-4.19.90-2405.5.0.0251.oe1.aarch64.rpm",
"kernel-tools-4.19.90-2405.5.0.0251.oe1.aarch64.rpm",
"bpftool-4.19.90-2405.5.0.0251.oe1.aarch64.rpm",
"kernel-tools-devel-4.19.90-2405.5.0.0251.oe1.aarch64.rpm",
"kernel-debuginfo-4.19.90-2405.5.0.0251.oe1.aarch64.rpm",
"python3-perf-debuginfo-4.19.90-2405.5.0.0251.oe1.aarch64.rpm",
"python3-perf-4.19.90-2405.5.0.0251.oe1.aarch64.rpm",
"bpftool-debuginfo-4.19.90-2405.5.0.0251.oe1.aarch64.rpm",
"python2-perf-4.19.90-2405.5.0.0251.oe1.aarch64.rpm",
"perf-4.19.90-2405.5.0.0251.oe1.aarch64.rpm",
"kernel-source-4.19.90-2405.5.0.0251.oe1.aarch64.rpm",
"kernel-devel-4.19.90-2405.5.0.0251.oe1.aarch64.rpm",
"python2-perf-debuginfo-4.19.90-2405.5.0.0251.oe1.aarch64.rpm"
],
"src": [
"kernel-4.19.90-2405.5.0.0251.oe1.src.rpm"
],
"x86_64": [
"bpftool-4.19.90-2405.5.0.0251.oe1.x86_64.rpm",
"kernel-debuginfo-4.19.90-2405.5.0.0251.oe1.x86_64.rpm",
"kernel-tools-debuginfo-4.19.90-2405.5.0.0251.oe1.x86_64.rpm",
"python2-perf-4.19.90-2405.5.0.0251.oe1.x86_64.rpm",
"perf-4.19.90-2405.5.0.0251.oe1.x86_64.rpm",
"bpftool-debuginfo-4.19.90-2405.5.0.0251.oe1.x86_64.rpm",
"kernel-tools-devel-4.19.90-2405.5.0.0251.oe1.x86_64.rpm",
"kernel-debugsource-4.19.90-2405.5.0.0251.oe1.x86_64.rpm",
"kernel-devel-4.19.90-2405.5.0.0251.oe1.x86_64.rpm",
"kernel-tools-4.19.90-2405.5.0.0251.oe1.x86_64.rpm",
"python2-perf-debuginfo-4.19.90-2405.5.0.0251.oe1.x86_64.rpm",
"kernel-4.19.90-2405.5.0.0251.oe1.x86_64.rpm",
"perf-debuginfo-4.19.90-2405.5.0.0251.oe1.x86_64.rpm",
"python3-perf-debuginfo-4.19.90-2405.5.0.0251.oe1.x86_64.rpm",
"kernel-source-4.19.90-2405.5.0.0251.oe1.x86_64.rpm",
"python3-perf-4.19.90-2405.5.0.0251.oe1.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:20.03-LTS-SP1",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-20.03-LTS-SP1"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.19.90-2405.5.0.0251.oe1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: dwc3: ep0: fix NULL pointer exception\r\n\r\nThere is no validation of the index from dwc3_wIndex_to_dep() and we might\nbe referring a non-existing ep and trigger a NULL pointer exception. In\ncertain configurations we might use fewer eps and the index might wrongly\nindicate a larger ep index than existing.\r\n\r\nBy adding this validation from the patch we can actually report a wrong\nindex back to the caller.\r\n\r\nIn our usecase we are using a composite device on an older kernel, but\nupstream might use this fix also. Unfortunately, I cannot describe the\nhardware for others to reproduce the issue as it is a proprietary\nimplementation.\r\n\r\n[ 82.958261] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a4\n[ 82.966891] Mem abort info:\n[ 82.969663] ESR = 0x96000006\n[ 82.972703] Exception class = DABT (current EL), IL = 32 bits\n[ 82.978603] SET = 0, FnV = 0\n[ 82.981642] EA = 0, S1PTW = 0\n[ 82.984765] Data abort info:\n[ 82.987631] ISV = 0, ISS = 0x00000006\n[ 82.991449] CM = 0, WnR = 0\n[ 82.994409] user pgtable: 4k pages, 39-bit VAs, pgdp = 00000000c6210ccc\n[ 83.000999] [00000000000000a4] pgd=0000000053aa5003, pud=0000000053aa5003, pmd=0000000000000000\n[ 83.009685] Internal error: Oops: 96000006 [#1] PREEMPT SMP\n[ 83.026433] Process irq/62-dwc3 (pid: 303, stack limit = 0x000000003985154c)\n[ 83.033470] CPU: 0 PID: 303 Comm: irq/62-dwc3 Not tainted 4.19.124 #1\n[ 83.044836] pstate: 60000085 (nZCv daIf -PAN -UAO)\n[ 83.049628] pc : dwc3_ep0_handle_feature+0x414/0x43c\n[ 83.054558] lr : dwc3_ep0_interrupt+0x3b4/0xc94\r\n\r\n...\r\n\r\n[ 83.141788] Call trace:\n[ 83.144227] dwc3_ep0_handle_feature+0x414/0x43c\n[ 83.148823] dwc3_ep0_interrupt+0x3b4/0xc94\n[ 83.181546] ---[ end trace aac6b5267d84c32f ]---(CVE-2021-47269)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nisdn: mISDN: netjet: Fix crash in nj_probe:\r\n\r\n\u0026apos;nj_setup\u0026apos; in netjet.c might fail with -EIO and in this case\n\u0026apos;card-\u0026gt;irq\u0026apos; is initialized and is bigger than zero. A subsequent call to\n\u0026apos;nj_release\u0026apos; will free the irq that has not been requested.\r\n\r\nFix this bug by deleting the previous assignment to \u0026apos;card-\u0026gt;irq\u0026apos; and just\nkeep the assignment before \u0026apos;request_irq\u0026apos;.\r\n\r\nThe KASAN\u0026apos;s log reveals it:\r\n\r\n[ 3.354615 ] WARNING: CPU: 0 PID: 1 at kernel/irq/manage.c:1826\nfree_irq+0x100/0x480\n[ 3.355112 ] Modules linked in:\n[ 3.355310 ] CPU: 0 PID: 1 Comm: swapper/0 Not tainted\n5.13.0-rc1-00144-g25a1298726e #13\n[ 3.355816 ] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS\nrel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014\n[ 3.356552 ] RIP: 0010:free_irq+0x100/0x480\n[ 3.356820 ] Code: 6e 08 74 6f 4d 89 f4 e8 5e ac 09 00 4d 8b 74 24 18\n4d 85 f6 75 e3 e8 4f ac 09 00 8b 75 c8 48 c7 c7 78 c1 2e 85 e8 e0 cf f5\nff \u0026lt;0f\u0026gt; 0b 48 8b 75 c0 4c 89 ff e8 72 33 0b 03 48 8b 43 40 4c 8b a0 80\n[ 3.358012 ] RSP: 0000:ffffc90000017b48 EFLAGS: 00010082\n[ 3.358357 ] RAX: 0000000000000000 RBX: ffff888104dc8000 RCX:\n0000000000000000\n[ 3.358814 ] RDX: ffff8881003c8000 RSI: ffffffff8124a9e6 RDI:\n00000000ffffffff\n[ 3.359272 ] RBP: ffffc90000017b88 R08: 0000000000000000 R09:\n0000000000000000\n[ 3.359732 ] R10: ffffc900000179f0 R11: 0000000000001d04 R12:\n0000000000000000\n[ 3.360195 ] R13: ffff888107dc6000 R14: ffff888107dc6928 R15:\nffff888104dc80a8\n[ 3.360652 ] FS: 0000000000000000(0000) GS:ffff88817bc00000(0000)\nknlGS:0000000000000000\n[ 3.361170 ] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 3.361538 ] CR2: 0000000000000000 CR3: 000000000582e000 CR4:\n00000000000006f0\n[ 3.362003 ] DR0: 0000000000000000 DR1: 0000000000000000 DR2:\n0000000000000000\n[ 3.362175 ] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:\n0000000000000400\n[ 3.362175 ] Call Trace:\n[ 3.362175 ] nj_release+0x51/0x1e0\n[ 3.362175 ] nj_probe+0x450/0x950\n[ 3.362175 ] ? pci_device_remove+0x110/0x110\n[ 3.362175 ] local_pci_probe+0x45/0xa0\n[ 3.362175 ] pci_device_probe+0x12b/0x1d0\n[ 3.362175 ] really_probe+0x2a9/0x610\n[ 3.362175 ] driver_probe_device+0x90/0x1d0\n[ 3.362175 ] ? mutex_lock_nested+0x1b/0x20\n[ 3.362175 ] device_driver_attach+0x68/0x70\n[ 3.362175 ] __driver_attach+0x124/0x1b0\n[ 3.362175 ] ? device_driver_attach+0x70/0x70\n[ 3.362175 ] bus_for_each_dev+0xbb/0x110\n[ 3.362175 ] ? rdinit_setup+0x45/0x45\n[ 3.362175 ] driver_attach+0x27/0x30\n[ 3.362175 ] bus_add_driver+0x1eb/0x2a0\n[ 3.362175 ] driver_register+0xa9/0x180\n[ 3.362175 ] __pci_register_driver+0x82/0x90\n[ 3.362175 ] ? w6692_init+0x38/0x38\n[ 3.362175 ] nj_init+0x36/0x38\n[ 3.362175 ] do_one_initcall+0x7f/0x3d0\n[ 3.362175 ] ? rdinit_setup+0x45/0x45\n[ 3.362175 ] ? rcu_read_lock_sched_held+0x4f/0x80\n[ 3.362175 ] kernel_init_freeable+0x2aa/0x301\n[ 3.362175 ] ? rest_init+0x2c0/0x2c0\n[ 3.362175 ] kernel_init+0x18/0x190\n[ 3.362175 ] ? rest_init+0x2c0/0x2c0\n[ 3.362175 ] ? rest_init+0x2c0/0x2c0\n[ 3.362175 ] ret_from_fork+0x1f/0x30\n[ 3.362175 ] Kernel panic - not syncing: panic_on_warn set ...\n[ 3.362175 ] CPU: 0 PID: 1 Comm: swapper/0 Not tainted\n5.13.0-rc1-00144-g25a1298726e #13\n[ 3.362175 ] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS\nrel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014\n[ 3.362175 ] Call Trace:\n[ 3.362175 ] dump_stack+0xba/0xf5\n[ 3.362175 ] ? free_irq+0x100/0x480\n[ 3.362175 ] panic+0x15a/0x3f2\n[ 3.362175 ] ? __warn+0xf2/0x150\n[ 3.362175 ] ? free_irq+0x100/0x480\n[ 3.362175 ] __warn+0x108/0x150\n[ 3.362175 ] ? free_irq+0x100/0x480\n[ 3.362175 ] report_bug+0x119/0x1c0\n[ 3.362175 ] handle_bug+0x3b/0x80\n[ 3.362175 ] exc_invalid_op+0x18/0x70\n[ 3.362175 ] asm_exc_invalid_op+0x12/0x20\n[ 3.362175 ] RIP: 0010:free_irq+0x100\n---truncated---(CVE-2021-47284)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nf2fs: fix to avoid racing on fsync_entry_slab by multi filesystem instances\r\n\r\nAs syzbot reported, there is an use-after-free issue during f2fs recovery:\r\n\r\nUse-after-free write at 0xffff88823bc16040 (in kfence-#10):\n kmem_cache_destroy+0x1f/0x120 mm/slab_common.c:486\n f2fs_recover_fsync_data+0x75b0/0x8380 fs/f2fs/recovery.c:869\n f2fs_fill_super+0x9393/0xa420 fs/f2fs/super.c:3945\n mount_bdev+0x26c/0x3a0 fs/super.c:1367\n legacy_get_tree+0xea/0x180 fs/fs_context.c:592\n vfs_get_tree+0x86/0x270 fs/super.c:1497\n do_new_mount fs/namespace.c:2905 [inline]\n path_mount+0x196f/0x2be0 fs/namespace.c:3235\n do_mount fs/namespace.c:3248 [inline]\n __do_sys_mount fs/namespace.c:3456 [inline]\n __se_sys_mount+0x2f9/0x3b0 fs/namespace.c:3433\n do_syscall_64+0x3f/0xb0 arch/x86/entry/common.c:47\n entry_SYSCALL_64_after_hwframe+0x44/0xae\r\n\r\nThe root cause is multi f2fs filesystem instances can race on accessing\nglobal fsync_entry_slab pointer, result in use-after-free issue of slab\ncache, fixes to init/destroy this slab cache only once during module\ninit/destroy procedure to avoid this issue.(CVE-2021-47335)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nhwmon: (mlxreg-fan) Return non-zero value when fan current state is enforced from sysfs\r\n\r\nFan speed minimum can be enforced from sysfs. For example, setting\ncurrent fan speed to 20 is used to enforce fan speed to be at 100%\nspeed, 19 - to be not below 90% speed, etcetera. This feature provides\nability to limit fan speed according to some system wise\nconsiderations, like absence of some replaceable units or high system\nambient temperature.\r\n\r\nRequest for changing fan minimum speed is configuration request and can\nbe set only through \u0026apos;sysfs\u0026apos; write procedure. In this situation value of\nargument \u0026apos;state\u0026apos; is above nominal fan speed maximum.\r\n\r\nReturn non-zero code in this case to avoid\nthermal_cooling_device_stats_update() call, because in this case\nstatistics update violates thermal statistics table range.\nThe issues is observed in case kernel is configured with option\nCONFIG_THERMAL_STATISTICS.\r\n\r\nHere is the trace from KASAN:\n[ 159.506659] BUG: KASAN: slab-out-of-bounds in thermal_cooling_device_stats_update+0x7d/0xb0\n[ 159.516016] Read of size 4 at addr ffff888116163840 by task hw-management.s/7444\n[ 159.545625] Call Trace:\n[ 159.548366] dump_stack+0x92/0xc1\n[ 159.552084] ? thermal_cooling_device_stats_update+0x7d/0xb0\n[ 159.635869] thermal_zone_device_update+0x345/0x780\n[ 159.688711] thermal_zone_device_set_mode+0x7d/0xc0\n[ 159.694174] mlxsw_thermal_modules_init+0x48f/0x590 [mlxsw_core]\n[ 159.700972] ? mlxsw_thermal_set_cur_state+0x5a0/0x5a0 [mlxsw_core]\n[ 159.731827] mlxsw_thermal_init+0x763/0x880 [mlxsw_core]\n[ 160.070233] RIP: 0033:0x7fd995909970\n[ 160.074239] Code: 73 01 c3 48 8b 0d 28 d5 2b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d 99 2d 2c 00 00 75 10 b8 01 00 00 00 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ..\n[ 160.095242] RSP: 002b:00007fff54f5d938 EFLAGS: 00000246 ORIG_RAX: 0000000000000001\n[ 160.103722] RAX: ffffffffffffffda RBX: 0000000000000013 RCX: 00007fd995909970\n[ 160.111710] RDX: 0000000000000013 RSI: 0000000001906008 RDI: 0000000000000001\n[ 160.119699] RBP: 0000000001906008 R08: 00007fd995bc9760 R09: 00007fd996210700\n[ 160.127687] R10: 0000000000000073 R11: 0000000000000246 R12: 0000000000000013\n[ 160.135673] R13: 0000000000000001 R14: 00007fd995bc8600 R15: 0000000000000013\n[ 160.143671]\n[ 160.145338] Allocated by task 2924:\n[ 160.149242] kasan_save_stack+0x19/0x40\n[ 160.153541] __kasan_kmalloc+0x7f/0xa0\n[ 160.157743] __kmalloc+0x1a2/0x2b0\n[ 160.161552] thermal_cooling_device_setup_sysfs+0xf9/0x1a0\n[ 160.167687] __thermal_cooling_device_register+0x1b5/0x500\n[ 160.173833] devm_thermal_of_cooling_device_register+0x60/0xa0\n[ 160.180356] mlxreg_fan_probe+0x474/0x5e0 [mlxreg_fan]\n[ 160.248140]\n[ 160.249807] The buggy address belongs to the object at ffff888116163400\n[ 160.249807] which belongs to the cache kmalloc-1k of size 1024\n[ 160.263814] The buggy address is located 64 bytes to the right of\n[ 160.263814] 1024-byte region [ffff888116163400, ffff888116163800)\n[ 160.277536] The buggy address belongs to the page:\n[ 160.282898] page:0000000012275840 refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888116167000 pfn:0x116160\n[ 160.294872] head:0000000012275840 order:3 compound_mapcount:0 compound_pincount:0\n[ 160.303251] flags: 0x200000000010200(slab|head|node=0|zone=2)\n[ 160.309694] raw: 0200000000010200 ffffea00046f7208 ffffea0004928208 ffff88810004dbc0\n[ 160.318367] raw: ffff888116167000 00000000000a0006 00000001ffffffff 0000000000000000\n[ 160.327033] page dumped because: kasan: bad access detected\n[ 160.333270]\n[ 160.334937] Memory state around the buggy address:\n[ 160.356469] \u0026gt;ffff888116163800: fc ..(CVE-2021-47393)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nptp: Fix possible memory leak in ptp_clock_register()\r\n\r\nI got memory leak as follows when doing fault injection test:\r\n\r\nunreferenced object 0xffff88800906c618 (size 8):\n comm \u0026quot;i2c-idt82p33931\u0026quot;, pid 4421, jiffies 4294948083 (age 13.188s)\n hex dump (first 8 bytes):\n 70 74 70 30 00 00 00 00 ptp0....\n backtrace:\n [\u0026lt;00000000312ed458\u0026gt;] __kmalloc_track_caller+0x19f/0x3a0\n [\u0026lt;0000000079f6e2ff\u0026gt;] kvasprintf+0xb5/0x150\n [\u0026lt;0000000026aae54f\u0026gt;] kvasprintf_const+0x60/0x190\n [\u0026lt;00000000f323a5f7\u0026gt;] kobject_set_name_vargs+0x56/0x150\n [\u0026lt;000000004e35abdd\u0026gt;] dev_set_name+0xc0/0x100\n [\u0026lt;00000000f20cfe25\u0026gt;] ptp_clock_register+0x9f4/0xd30 [ptp]\n [\u0026lt;000000008bb9f0de\u0026gt;] idt82p33_probe.cold+0x8b6/0x1561 [ptp_idt82p33]\r\n\r\nWhen posix_clock_register() returns an error, the name allocated\nin dev_set_name() will be leaked, the put_device() should be used\nto give up the device reference, then the name will be freed in\nkobject_cleanup() and other memory will be freed in ptp_clock_release().(CVE-2021-47455)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: qla2xxx: Fix a memory leak in an error path of qla2x00_process_els()\r\n\r\nCommit 8c0eb596baa5 (\u0026quot;[SCSI] qla2xxx: Fix a memory leak in an error path of\nqla2x00_process_els()\u0026quot;), intended to change:\r\n\r\n bsg_job-\u0026gt;request-\u0026gt;msgcode == FC_BSG_HST_ELS_NOLOGIN\r\n\r\n\n bsg_job-\u0026gt;request-\u0026gt;msgcode != FC_BSG_RPT_ELS\r\n\r\nbut changed it to:\r\n\r\n bsg_job-\u0026gt;request-\u0026gt;msgcode == FC_BSG_RPT_ELS\r\n\r\ninstead.\r\n\r\nChange the == to a != to avoid leaking the fcport structure or freeing\nunallocated memory.(CVE-2021-47473)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnvmem: Fix shift-out-of-bound (UBSAN) with byte size cells\r\n\r\nIf a cell has \u0026apos;nbits\u0026apos; equal to a multiple of BITS_PER_BYTE the logic\r\n\r\n *p \u0026amp;= GENMASK((cell-\u0026gt;nbits%BITS_PER_BYTE) - 1, 0);\r\n\r\nwill become undefined behavior because nbits modulo BITS_PER_BYTE is 0, and we\nsubtract one from that making a large number that is then shifted more than the\nnumber of bits that fit into an unsigned long.\r\n\r\nUBSAN reports this problem:\r\n\r\n UBSAN: shift-out-of-bounds in drivers/nvmem/core.c:1386:8\n shift exponent 64 is too large for 64-bit type \u0026apos;unsigned long\u0026apos;\n CPU: 6 PID: 7 Comm: kworker/u16:0 Not tainted 5.15.0-rc3+ #9\n Hardware name: Google Lazor (rev3+) with KB Backlight (DT)\n Workqueue: events_unbound deferred_probe_work_func\n Call trace:\n dump_backtrace+0x0/0x170\n show_stack+0x24/0x30\n dump_stack_lvl+0x64/0x7c\n dump_stack+0x18/0x38\n ubsan_epilogue+0x10/0x54\n __ubsan_handle_shift_out_of_bounds+0x180/0x194\n __nvmem_cell_read+0x1ec/0x21c\n nvmem_cell_read+0x58/0x94\n nvmem_cell_read_variable_common+0x4c/0xb0\n nvmem_cell_read_variable_le_u32+0x40/0x100\n a6xx_gpu_init+0x170/0x2f4\n adreno_bind+0x174/0x284\n component_bind_all+0xf0/0x264\n msm_drm_bind+0x1d8/0x7a0\n try_to_bring_up_master+0x164/0x1ac\n __component_add+0xbc/0x13c\n component_add+0x20/0x2c\n dp_display_probe+0x340/0x384\n platform_probe+0xc0/0x100\n really_probe+0x110/0x304\n __driver_probe_device+0xb8/0x120\n driver_probe_device+0x4c/0xfc\n __device_attach_driver+0xb0/0x128\n bus_for_each_drv+0x90/0xdc\n __device_attach+0xc8/0x174\n device_initial_probe+0x20/0x2c\n bus_probe_device+0x40/0xa4\n deferred_probe_work_func+0x7c/0xb8\n process_one_work+0x128/0x21c\n process_scheduled_works+0x40/0x54\n worker_thread+0x1ec/0x2a8\n kthread+0x138/0x158\n ret_from_fork+0x10/0x20\r\n\r\nFix it by making sure there are any bits to mask out.(CVE-2021-47497)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: mpt3sas: Fix use-after-free warning\r\n\r\nFix the following use-after-free warning which is observed during\ncontroller reset:\r\n\r\nrefcount_t: underflow; use-after-free.\nWARNING: CPU: 23 PID: 5399 at lib/refcount.c:28 refcount_warn_saturate+0xa6/0xf0(CVE-2022-48695)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnvmet: fix a use-after-free\r\n\r\nFix the following use-after-free complaint triggered by blktests nvme/004:\r\n\r\nBUG: KASAN: user-memory-access in blk_mq_complete_request_remote+0xac/0x350\nRead of size 4 at addr 0000607bd1835943 by task kworker/13:1/460\nWorkqueue: nvmet-wq nvme_loop_execute_work [nvme_loop]\nCall Trace:\n show_stack+0x52/0x58\n dump_stack_lvl+0x49/0x5e\n print_report.cold+0x36/0x1e2\n kasan_report+0xb9/0xf0\n __asan_load4+0x6b/0x80\n blk_mq_complete_request_remote+0xac/0x350\n nvme_loop_queue_response+0x1df/0x275 [nvme_loop]\n __nvmet_req_complete+0x132/0x4f0 [nvmet]\n nvmet_req_complete+0x15/0x40 [nvmet]\n nvmet_execute_io_connect+0x18a/0x1f0 [nvmet]\n nvme_loop_execute_work+0x20/0x30 [nvme_loop]\n process_one_work+0x56e/0xa70\n worker_thread+0x2d1/0x640\n kthread+0x183/0x1c0\n ret_from_fork+0x1f/0x30(CVE-2022-48697)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nALSA: emu10k1: Fix out of bounds access in snd_emu10k1_pcm_channel_alloc()\r\n\r\nThe voice allocator sometimes begins allocating from near the end of the\narray and then wraps around, however snd_emu10k1_pcm_channel_alloc()\naccesses the newly allocated voices as if it never wrapped around.\r\n\r\nThis results in out of bounds access if the first voice has a high enough\nindex so that first_voice + requested_voice_count \u0026gt; NUM_G (64).\nThe more voices are requested, the more likely it is for this to occur.\r\n\r\nThis was initially discovered using PipeWire, however it can be reproduced\nby calling aplay multiple times with 16 channels:\naplay -r 48000 -D plughw:CARD=Live,DEV=3 -c 16 /dev/zero\r\n\r\nUBSAN: array-index-out-of-bounds in sound/pci/emu10k1/emupcm.c:127:40\nindex 65 is out of range for type \u0026apos;snd_emu10k1_voice [64]\u0026apos;\nCPU: 1 PID: 31977 Comm: aplay Tainted: G W IOE 6.0.0-rc2-emu10k1+ #7\nHardware name: ASUSTEK COMPUTER INC P5W DH Deluxe/P5W DH Deluxe, BIOS 3002 07/22/2010\nCall Trace:\n\u0026lt;TASK\u0026gt;\ndump_stack_lvl+0x49/0x63\ndump_stack+0x10/0x16\nubsan_epilogue+0x9/0x3f\n__ubsan_handle_out_of_bounds.cold+0x44/0x49\nsnd_emu10k1_playback_hw_params+0x3bc/0x420 [snd_emu10k1]\nsnd_pcm_hw_params+0x29f/0x600 [snd_pcm]\nsnd_pcm_common_ioctl+0x188/0x1410 [snd_pcm]\n? exit_to_user_mode_prepare+0x35/0x170\n? do_syscall_64+0x69/0x90\n? syscall_exit_to_user_mode+0x26/0x50\n? do_syscall_64+0x69/0x90\n? exit_to_user_mode_prepare+0x35/0x170\nsnd_pcm_ioctl+0x27/0x40 [snd_pcm]\n__x64_sys_ioctl+0x95/0xd0\ndo_syscall_64+0x5c/0x90\n? do_syscall_64+0x69/0x90\n? do_syscall_64+0x69/0x90\nentry_SYSCALL_64_after_hwframe+0x63/0xcd(CVE-2022-48702)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/radeon: add a force flush to delay work when radeon\r\n\r\nAlthough radeon card fence and wait for gpu to finish processing current batch rings,\nthere is still a corner case that radeon lockup work queue may not be fully flushed,\nand meanwhile the radeon_suspend_kms() function has called pci_set_power_state() to\nput device in D3hot state.\nPer PCI spec rev 4.0 on 5.3.1.4.1 D3hot State.\n\u0026gt; Configuration and Message requests are the only TLPs accepted by a Function in\n\u0026gt; the D3hot state. All other received Requests must be handled as Unsupported Requests,\n\u0026gt; and all received Completions may optionally be handled as Unexpected Completions.\nThis issue will happen in following logs:\nUnable to handle kernel paging request at virtual address 00008800e0008010\nCPU 0 kworker/0:3(131): Oops 0\npc = [\u0026lt;ffffffff811bea5c\u0026gt;] ra = [\u0026lt;ffffffff81240844\u0026gt;] ps = 0000 Tainted: G W\npc is at si_gpu_check_soft_reset+0x3c/0x240\nra is at si_dma_is_lockup+0x34/0xd0\nv0 = 0000000000000000 t0 = fff08800e0008010 t1 = 0000000000010000\nt2 = 0000000000008010 t3 = fff00007e3c00000 t4 = fff00007e3c00258\nt5 = 000000000000ffff t6 = 0000000000000001 t7 = fff00007ef078000\ns0 = fff00007e3c016e8 s1 = fff00007e3c00000 s2 = fff00007e3c00018\ns3 = fff00007e3c00000 s4 = fff00007fff59d80 s5 = 0000000000000000\ns6 = fff00007ef07bd98\na0 = fff00007e3c00000 a1 = fff00007e3c016e8 a2 = 0000000000000008\na3 = 0000000000000001 a4 = 8f5c28f5c28f5c29 a5 = ffffffff810f4338\nt8 = 0000000000000275 t9 = ffffffff809b66f8 t10 = ff6769c5d964b800\nt11= 000000000000b886 pv = ffffffff811bea20 at = 0000000000000000\ngp = ffffffff81d89690 sp = 00000000aa814126\nDisabling lock debugging due to kernel taint\nTrace:\n[\u0026lt;ffffffff81240844\u0026gt;] si_dma_is_lockup+0x34/0xd0\n[\u0026lt;ffffffff81119610\u0026gt;] radeon_fence_check_lockup+0xd0/0x290\n[\u0026lt;ffffffff80977010\u0026gt;] process_one_work+0x280/0x550\n[\u0026lt;ffffffff80977350\u0026gt;] worker_thread+0x70/0x7c0\n[\u0026lt;ffffffff80977410\u0026gt;] worker_thread+0x130/0x7c0\n[\u0026lt;ffffffff80982040\u0026gt;] kthread+0x200/0x210\n[\u0026lt;ffffffff809772e0\u0026gt;] worker_thread+0x0/0x7c0\n[\u0026lt;ffffffff80981f8c\u0026gt;] kthread+0x14c/0x210\n[\u0026lt;ffffffff80911658\u0026gt;] ret_from_kernel_thread+0x18/0x20\n[\u0026lt;ffffffff80981e40\u0026gt;] kthread+0x0/0x210\n Code: ad3e0008 43f0074a ad7e0018 ad9e0020 8c3001e8 40230101\n \u0026lt;88210000\u0026gt; 4821ed21\nSo force lockup work queue flush to fix this problem.(CVE-2022-48704)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/radeon: fix a possible null pointer dereference\r\n\r\nIn radeon_fp_native_mode(), the return value of drm_mode_duplicate()\nis assigned to mode, which will lead to a NULL pointer dereference\non failure of drm_mode_duplicate(). Add a check to avoid npd.\r\n\r\nThe failure status of drm_cvt_mode() on the other path is checked too.(CVE-2022-48710)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/tegra: dsi: Add missing check for of_find_device_by_node\r\n\r\nAdd check for the return value of of_find_device_by_node() and return\nthe error if it fails in order to avoid NULL pointer dereference.(CVE-2023-52650)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nNTB: fix possible name leak in ntb_register_device()\r\n\r\nIf device_register() fails in ntb_register_device(), the device name\nallocated by dev_set_name() should be freed. As per the comment in\ndevice_register(), callers should use put_device() to give up the\nreference in the error path. So fix this by calling put_device() in the\nerror path so that the name can be freed in kobject_cleanup().\r\n\r\nAs a result of this, put_device() in the error path of\nntb_register_device() is removed and the actual error is returned.\r\n\r\n[mani: reworded commit message](CVE-2023-52652)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nSUNRPC: fix a memleak in gss_import_v2_context\r\n\r\nThe ctx-\u0026gt;mech_used.data allocated by kmemdup is not freed in neither\ngss_import_v2_context nor it only caller gss_krb5_import_sec_context,\nwhich frees ctx on error.\r\n\r\nThus, this patch reform the last call of gss_import_v2_context to the\ngss_krb5_import_ctx_v2, preventing the memleak while keepping the return\nformation.(CVE-2023-52653)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nio_uring: drop any code related to SCM_RIGHTS\r\n\r\nThis is dead code after we dropped support for passing io_uring fds\nover SCM_RIGHTS, get rid of it.(CVE-2023-52656)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nACPI: LPIT: Avoid u32 multiplication overflow\r\n\r\nIn lpit_update_residency() there is a possibility of overflow\nin multiplication, if tsc_khz is large enough (\u0026gt; UINT_MAX/1000).\r\n\r\nChange multiplication to mul_u32_u32().\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2023-52683)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/pm: fix a double-free in si_dpm_init\r\n\r\nWhen the allocation of\nadev-\u0026gt;pm.dpm.dyn_state.vddc_dependency_on_dispclk.entries fails,\namdgpu_free_extended_power_table is called to free some fields of adev.\nHowever, when the control flow returns to si_dpm_sw_init, it goes to\nlabel dpm_failed and calls si_dpm_fini, which calls\namdgpu_free_extended_power_table again and free those fields again. Thus\na double-free is triggered.(CVE-2023-52691)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncalipso: fix memory leak in netlbl_calipso_add_pass()\r\n\r\nIf IPv6 support is disabled at boot (ipv6.disable=1),\nthe calipso_init() -\u0026gt; netlbl_calipso_ops_register() function isn\u0026apos;t called,\nand the netlbl_calipso_ops_get() function always returns NULL.\nIn this case, the netlbl_calipso_add_pass() function allocates memory\nfor the doi_def variable but doesn\u0026apos;t free it with the calipso_doi_free().\r\n\r\nBUG: memory leak\nunreferenced object 0xffff888011d68180 (size 64):\n comm \u0026quot;syz-executor.1\u0026quot;, pid 10746, jiffies 4295410986 (age 17.928s)\n hex dump (first 32 bytes):\n 00 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 ................\n 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n backtrace:\n [\u0026lt;...\u0026gt;] kmalloc include/linux/slab.h:552 [inline]\n [\u0026lt;...\u0026gt;] netlbl_calipso_add_pass net/netlabel/netlabel_calipso.c:76 [inline]\n [\u0026lt;...\u0026gt;] netlbl_calipso_add+0x22e/0x4f0 net/netlabel/netlabel_calipso.c:111\n [\u0026lt;...\u0026gt;] genl_family_rcv_msg_doit+0x22f/0x330 net/netlink/genetlink.c:739\n [\u0026lt;...\u0026gt;] genl_family_rcv_msg net/netlink/genetlink.c:783 [inline]\n [\u0026lt;...\u0026gt;] genl_rcv_msg+0x341/0x5a0 net/netlink/genetlink.c:800\n [\u0026lt;...\u0026gt;] netlink_rcv_skb+0x14d/0x440 net/netlink/af_netlink.c:2515\n [\u0026lt;...\u0026gt;] genl_rcv+0x29/0x40 net/netlink/genetlink.c:811\n [\u0026lt;...\u0026gt;] netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline]\n [\u0026lt;...\u0026gt;] netlink_unicast+0x54b/0x800 net/netlink/af_netlink.c:1339\n [\u0026lt;...\u0026gt;] netlink_sendmsg+0x90a/0xdf0 net/netlink/af_netlink.c:1934\n [\u0026lt;...\u0026gt;] sock_sendmsg_nosec net/socket.c:651 [inline]\n [\u0026lt;...\u0026gt;] sock_sendmsg+0x157/0x190 net/socket.c:671\n [\u0026lt;...\u0026gt;] ____sys_sendmsg+0x712/0x870 net/socket.c:2342\n [\u0026lt;...\u0026gt;] ___sys_sendmsg+0xf8/0x170 net/socket.c:2396\n [\u0026lt;...\u0026gt;] __sys_sendmsg+0xea/0x1b0 net/socket.c:2429\n [\u0026lt;...\u0026gt;] do_syscall_64+0x30/0x40 arch/x86/entry/common.c:46\n [\u0026lt;...\u0026gt;] entry_SYSCALL_64_after_hwframe+0x61/0xc6\r\n\r\nFound by InfoTeCS on behalf of Linux Verification Center\n(linuxtesting.org) with Syzkaller\r\n\r\n[PM: merged via the LSM tree at Jakub Kicinski request](CVE-2023-52698)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncrypto: pcrypt - Fix hungtask for PADATA_RESET\r\n\r\nWe found a hungtask bug in test_aead_vec_cfg as follows:\r\n\r\nINFO: task cryptomgr_test:391009 blocked for more than 120 seconds.\n\u0026quot;echo 0 \u0026gt; /proc/sys/kernel/hung_task_timeout_secs\u0026quot; disables this message.\nCall trace:\n __switch_to+0x98/0xe0\n __schedule+0x6c4/0xf40\n schedule+0xd8/0x1b4\n schedule_timeout+0x474/0x560\n wait_for_common+0x368/0x4e0\n wait_for_completion+0x20/0x30\n wait_for_completion+0x20/0x30\n test_aead_vec_cfg+0xab4/0xd50\n test_aead+0x144/0x1f0\n alg_test_aead+0xd8/0x1e0\n alg_test+0x634/0x890\n cryptomgr_test+0x40/0x70\n kthread+0x1e0/0x220\n ret_from_fork+0x10/0x18\n Kernel panic - not syncing: hung_task: blocked tasks\r\n\r\nFor padata_do_parallel, when the return err is 0 or -EBUSY, it will call\nwait_for_completion(\u0026amp;wait-\u0026gt;completion) in test_aead_vec_cfg. In normal\ncase, aead_request_complete() will be called in pcrypt_aead_serial and the\nreturn err is 0 for padata_do_parallel. But, when pinst-\u0026gt;flags is\nPADATA_RESET, the return err is -EBUSY for padata_do_parallel, and it\nwon\u0026apos;t call aead_request_complete(). Therefore, test_aead_vec_cfg will\nhung at wait_for_completion(\u0026amp;wait-\u0026gt;completion), which will cause\nhungtask.\r\n\r\nThe problem comes as following:\n(padata_do_parallel) |\n rcu_read_lock_bh(); |\n err = -EINVAL; | (padata_replace)\n | pinst-\u0026gt;flags |= PADATA_RESET;\n err = -EBUSY |\n if (pinst-\u0026gt;flags \u0026amp; PADATA_RESET) |\n rcu_read_unlock_bh() |\n return err\r\n\r\nIn order to resolve the problem, we replace the return err -EBUSY with\n-EAGAIN, which means parallel_data is changing, and the caller should call\nit again.\r\n\r\nv3:\nremove retry and just change the return err.\nv2:\nintroduce padata_try_do_parallel() in pcrypt_aead_encrypt and\npcrypt_aead_decrypt to solve the hungtask.(CVE-2023-52813)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: Fix a null pointer access when the smc_rreg pointer is NULL\r\n\r\nIn certain types of chips, such as VEGA20, reading the amdgpu_regs_smc file could result in an abnormal null pointer access when the smc_rreg pointer is NULL. Below are the steps to reproduce this issue and the corresponding exception log:\r\n\r\n1. Navigate to the directory: /sys/kernel/debug/dri/0\n2. Execute command: cat amdgpu_regs_smc\n3. Exception Log::\n[4005007.702554] BUG: kernel NULL pointer dereference, address: 0000000000000000\n[4005007.702562] #PF: supervisor instruction fetch in kernel mode\n[4005007.702567] #PF: error_code(0x0010) - not-present page\n[4005007.702570] PGD 0 P4D 0\n[4005007.702576] Oops: 0010 [#1] SMP NOPTI\n[4005007.702581] CPU: 4 PID: 62563 Comm: cat Tainted: G OE 5.15.0-43-generic #46-Ubunt u\n[4005007.702590] RIP: 0010:0x0\n[4005007.702598] Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6.\n[4005007.702600] RSP: 0018:ffffa82b46d27da0 EFLAGS: 00010206\n[4005007.702605] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffa82b46d27e68\n[4005007.702609] RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff9940656e0000\n[4005007.702612] RBP: ffffa82b46d27dd8 R08: 0000000000000000 R09: ffff994060c07980\n[4005007.702615] R10: 0000000000020000 R11: 0000000000000000 R12: 00007f5e06753000\n[4005007.702618] R13: ffff9940656e0000 R14: ffffa82b46d27e68 R15: 00007f5e06753000\n[4005007.702622] FS: 00007f5e0755b740(0000) GS:ffff99479d300000(0000) knlGS:0000000000000000\n[4005007.702626] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[4005007.702629] CR2: ffffffffffffffd6 CR3: 00000003253fc000 CR4: 00000000003506e0\n[4005007.702633] Call Trace:\n[4005007.702636] \u0026lt;TASK\u0026gt;\n[4005007.702640] amdgpu_debugfs_regs_smc_read+0xb0/0x120 [amdgpu]\n[4005007.703002] full_proxy_read+0x5c/0x80\n[4005007.703011] vfs_read+0x9f/0x1a0\n[4005007.703019] ksys_read+0x67/0xe0\n[4005007.703023] __x64_sys_read+0x19/0x20\n[4005007.703028] do_syscall_64+0x5c/0xc0\n[4005007.703034] ? do_user_addr_fault+0x1e3/0x670\n[4005007.703040] ? exit_to_user_mode_prepare+0x37/0xb0\n[4005007.703047] ? irqentry_exit_to_user_mode+0x9/0x20\n[4005007.703052] ? irqentry_exit+0x19/0x30\n[4005007.703057] ? exc_page_fault+0x89/0x160\n[4005007.703062] ? asm_exc_page_fault+0x8/0x30\n[4005007.703068] entry_SYSCALL_64_after_hwframe+0x44/0xae\n[4005007.703075] RIP: 0033:0x7f5e07672992\n[4005007.703079] Code: c0 e9 b2 fe ff ff 50 48 8d 3d fa b2 0c 00 e8 c5 1d 02 00 0f 1f 44 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 0f 05 \u0026lt;48\u0026gt; 3d 00 f0 ff ff 77 56 c3 0f 1f 44 00 00 48 83 e c 28 48 89 54 24\n[4005007.703083] RSP: 002b:00007ffe03097898 EFLAGS: 00000246 ORIG_RAX: 0000000000000000\n[4005007.703088] RAX: ffffffffffffffda RBX: 0000000000020000 RCX: 00007f5e07672992\n[4005007.703091] RDX: 0000000000020000 RSI: 00007f5e06753000 RDI: 0000000000000003\n[4005007.703094] RBP: 00007f5e06753000 R08: 00007f5e06752010 R09: 00007f5e06752010\n[4005007.703096] R10: 0000000000000022 R11: 0000000000000246 R12: 0000000000022000\n[4005007.703099] R13: 0000000000000003 R14: 0000000000020000 R15: 0000000000020000\n[4005007.703105] \u0026lt;/TASK\u0026gt;\n[4005007.703107] Modules linked in: nf_tables libcrc32c nfnetlink algif_hash af_alg binfmt_misc nls_ iso8859_1 ipmi_ssif ast intel_rapl_msr intel_rapl_common drm_vram_helper drm_ttm_helper amd64_edac t tm edac_mce_amd kvm_amd ccp mac_hid k10temp kvm acpi_ipmi ipmi_si rapl sch_fq_codel ipmi_devintf ipm i_msghandler msr parport_pc ppdev lp parport mtd pstore_blk efi_pstore ramoops pstore_zone reed_solo mon ip_tables x_tables autofs4 ib_uverbs ib_core amdgpu(OE) amddrm_ttm_helper(OE) amdttm(OE) iommu_v 2 amd_sched(OE) amdkcl(OE) drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops cec rc_core drm igb ahci xhci_pci libahci i2c_piix4 i2c_algo_bit xhci_pci_renesas dca\n[4005007.703184] CR2: 0000000000000000\n[4005007.703188] ---[ en\n---truncated---(CVE-2023-52817)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd: Fix UBSAN array-index-out-of-bounds for SMU7\r\n\r\nFor pptable structs that use flexible array sizes, use flexible arrays.(CVE-2023-52818)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nperf/core: Bail out early if the request AUX area is out of bound\r\n\r\nWhen perf-record with a large AUX area, e.g 4GB, it fails with:\r\n\r\n #perf record -C 0 -m ,4G -e arm_spe_0// -- sleep 1\n failed to mmap with 12 (Cannot allocate memory)\r\n\r\nand it reveals a WARNING with __alloc_pages():\r\n\r\n\t------------[ cut here ]------------\n\tWARNING: CPU: 44 PID: 17573 at mm/page_alloc.c:5568 __alloc_pages+0x1ec/0x248\n\tCall trace:\n\t __alloc_pages+0x1ec/0x248\n\t __kmalloc_large_node+0xc0/0x1f8\n\t __kmalloc_node+0x134/0x1e8\n\t rb_alloc_aux+0xe0/0x298\n\t perf_mmap+0x440/0x660\n\t mmap_region+0x308/0x8a8\n\t do_mmap+0x3c0/0x528\n\t vm_mmap_pgoff+0xf4/0x1b8\n\t ksys_mmap_pgoff+0x18c/0x218\n\t __arm64_sys_mmap+0x38/0x58\n\t invoke_syscall+0x50/0x128\n\t el0_svc_common.constprop.0+0x58/0x188\n\t do_el0_svc+0x34/0x50\n\t el0_svc+0x34/0x108\n\t el0t_64_sync_handler+0xb8/0xc0\n\t el0t_64_sync+0x1a4/0x1a8\r\n\r\n\u0026apos;rb-\u0026gt;aux_pages\u0026apos; allocated by kcalloc() is a pointer array which is used to\nmaintains AUX trace pages. The allocated page for this array is physically\ncontiguous (and virtually contiguous) with an order of 0..MAX_ORDER. If the\nsize of pointer array crosses the limitation set by MAX_ORDER, it reveals a\nWARNING.\r\n\r\nSo bail out early with -ENOMEM if the request AUX area is out of bound,\ne.g.:\r\n\r\n #perf record -C 0 -m ,4G -e arm_spe_0// -- sleep 1\n failed to mmap with 12 (Cannot allocate memory)(CVE-2023-52835)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nInput: synaptics-rmi4 - fix use after free in rmi_unregister_function()\r\n\r\nThe put_device() calls rmi_release_function() which frees \u0026quot;fn\u0026quot; so the\ndereference on the next line \u0026quot;fn-\u0026gt;num_of_irqs\u0026quot; is a use after free.\nMove the put_device() to the end to fix this.(CVE-2023-52840)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: bttv: fix use after free error due to btv-\u0026gt;timeout timer\r\n\r\nThere may be some a race condition between timer function\nbttv_irq_timeout and bttv_remove. The timer is setup in\nprobe and there is no timer_delete operation in remove\nfunction. When it hit kfree btv, the function might still be\ninvoked, which will cause use after free bug.\r\n\r\nThis bug is found by static analysis, it may be false positive.\r\n\r\nFix it by adding del_timer_sync invoking to the remove function.\r\n\r\ncpu0 cpu1\n bttv_probe\n -\u0026gt;timer_setup\n -\u0026gt;bttv_set_dma\n -\u0026gt;mod_timer;\nbttv_remove\n -\u0026gt;kfree(btv);\n -\u0026gt;bttv_irq_timeout\n -\u0026gt;USE btv(CVE-2023-52847)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/radeon: possible buffer overflow\r\n\r\nBuffer \u0026apos;afmt_status\u0026apos; of size 6 could overflow, since index \u0026apos;afmt_idx\u0026apos; is\nchecked after access.(CVE-2023-52867)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nthermal: core: prevent potential string overflow\r\n\r\nThe dev-\u0026gt;id value comes from ida_alloc() so it\u0026apos;s a number between zero\nand INT_MAX. If it\u0026apos;s too high then these sprintf()s will overflow.(CVE-2023-52868)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: prevent kernel bug at submit_bh_wbc()\r\n\r\nFix a bug where nilfs_get_block() returns a successful status when\nsearching and inserting the specified block both fail inconsistently. If\nthis inconsistent behavior is not due to a previously fixed bug, then an\nunexpected race is occurring, so return a temporary error -EAGAIN instead.\r\n\r\nThis prevents callers such as __block_write_begin_int() from requesting a\nread into a buffer that is not mapped, which would cause the BUG_ON check\nfor the BH_Mapped flag in submit_bh_wbc() to fail.(CVE-2024-26955)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: fix failure to detect DAT corruption in btree and direct mappings\r\n\r\nPatch series \u0026quot;nilfs2: fix kernel bug at submit_bh_wbc()\u0026quot;.\r\n\r\nThis resolves a kernel BUG reported by syzbot. Since there are two\nflaws involved, I\u0026apos;ve made each one a separate patch.\r\n\r\nThe first patch alone resolves the syzbot-reported bug, but I think\nboth fixes should be sent to stable, so I\u0026apos;ve tagged them as such.\r\n\r\n\nThis patch (of 2):\r\n\r\nSyzbot has reported a kernel bug in submit_bh_wbc() when writing file data\nto a nilfs2 file system whose metadata is corrupted.\r\n\r\nThere are two flaws involved in this issue.\r\n\r\nThe first flaw is that when nilfs_get_block() locates a data block using\nbtree or direct mapping, if the disk address translation routine\nnilfs_dat_translate() fails with internal code -ENOENT due to DAT metadata\ncorruption, it can be passed back to nilfs_get_block(). This causes\nnilfs_get_block() to misidentify an existing block as non-existent,\ncausing both data block lookup and insertion to fail inconsistently.\r\n\r\nThe second flaw is that nilfs_get_block() returns a successful status in\nthis inconsistent state. This causes the caller __block_write_begin_int()\nor others to request a read even though the buffer is not mapped,\nresulting in a BUG_ON check for the BH_Mapped flag in submit_bh_wbc()\nfailing.\r\n\r\nThis fixes the first issue by changing the return value to code -EINVAL\nwhen a conversion using DAT fails with code -ENOENT, avoiding the\nconflicting condition that leads to the kernel bug described above. Here,\ncode -EINVAL indicates that metadata corruption was detected during the\nblock lookup, which will be properly handled as a file system error and\nconverted to -EIO when passing through the nilfs2 bmap layer.(CVE-2024-26956)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ns390/zcrypt: fix reference counting on zcrypt card objects\r\n\r\nTests with hot-plugging crytpo cards on KVM guests with debug\nkernel build revealed an use after free for the load field of\nthe struct zcrypt_card. The reason was an incorrect reference\nhandling of the zcrypt card object which could lead to a free\nof the zcrypt card object while it was still in use.\r\n\r\nThis is an example of the slab message:\r\n\r\n kernel: 0x00000000885a7512-0x00000000885a7513 @offset=1298. First byte 0x68 instead of 0x6b\n kernel: Allocated in zcrypt_card_alloc+0x36/0x70 [zcrypt] age=18046 cpu=3 pid=43\n kernel: kmalloc_trace+0x3f2/0x470\n kernel: zcrypt_card_alloc+0x36/0x70 [zcrypt]\n kernel: zcrypt_cex4_card_probe+0x26/0x380 [zcrypt_cex4]\n kernel: ap_device_probe+0x15c/0x290\n kernel: really_probe+0xd2/0x468\n kernel: driver_probe_device+0x40/0xf0\n kernel: __device_attach_driver+0xc0/0x140\n kernel: bus_for_each_drv+0x8c/0xd0\n kernel: __device_attach+0x114/0x198\n kernel: bus_probe_device+0xb4/0xc8\n kernel: device_add+0x4d2/0x6e0\n kernel: ap_scan_adapter+0x3d0/0x7c0\n kernel: ap_scan_bus+0x5a/0x3b0\n kernel: ap_scan_bus_wq_callback+0x40/0x60\n kernel: process_one_work+0x26e/0x620\n kernel: worker_thread+0x21c/0x440\n kernel: Freed in zcrypt_card_put+0x54/0x80 [zcrypt] age=9024 cpu=3 pid=43\n kernel: kfree+0x37e/0x418\n kernel: zcrypt_card_put+0x54/0x80 [zcrypt]\n kernel: ap_device_remove+0x4c/0xe0\n kernel: device_release_driver_internal+0x1c4/0x270\n kernel: bus_remove_device+0x100/0x188\n kernel: device_del+0x164/0x3c0\n kernel: device_unregister+0x30/0x90\n kernel: ap_scan_adapter+0xc8/0x7c0\n kernel: ap_scan_bus+0x5a/0x3b0\n kernel: ap_scan_bus_wq_callback+0x40/0x60\n kernel: process_one_work+0x26e/0x620\n kernel: worker_thread+0x21c/0x440\n kernel: kthread+0x150/0x168\n kernel: __ret_from_fork+0x3c/0x58\n kernel: ret_from_fork+0xa/0x30\n kernel: Slab 0x00000372022169c0 objects=20 used=18 fp=0x00000000885a7c88 flags=0x3ffff00000000a00(workingset|slab|node=0|zone=1|lastcpupid=0x1ffff)\n kernel: Object 0x00000000885a74b8 @offset=1208 fp=0x00000000885a7c88\n kernel: Redzone 00000000885a74b0: bb bb bb bb bb bb bb bb ........\n kernel: Object 00000000885a74b8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk\n kernel: Object 00000000885a74c8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk\n kernel: Object 00000000885a74d8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk\n kernel: Object 00000000885a74e8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk\n kernel: Object 00000000885a74f8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk\n kernel: Object 00000000885a7508: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 68 4b 6b 6b 6b a5 kkkkkkkkkkhKkkk.\n kernel: Redzone 00000000885a7518: bb bb bb bb bb bb bb bb ........\n kernel: Padding 00000000885a756c: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZ\n kernel: CPU: 0 PID: 387 Comm: systemd-udevd Not tainted 6.8.0-HF #2\n kernel: Hardware name: IBM 3931 A01 704 (KVM/Linux)\n kernel: Call Trace:\n kernel: [\u0026lt;00000000ca5ab5b8\u0026gt;] dump_stack_lvl+0x90/0x120\n kernel: [\u0026lt;00000000c99d78bc\u0026gt;] check_bytes_and_report+0x114/0x140\n kernel: [\u0026lt;00000000c99d53cc\u0026gt;] check_object+0x334/0x3f8\n kernel: [\u0026lt;00000000c99d820c\u0026gt;] alloc_debug_processing+0xc4/0x1f8\n kernel: [\u0026lt;00000000c99d852e\u0026gt;] get_partial_node.part.0+0x1ee/0x3e0\n kernel: [\u0026lt;00000000c99d94ec\u0026gt;] ___slab_alloc+0xaf4/0x13c8\n kernel: [\u0026lt;00000000c99d9e38\u0026gt;] __slab_alloc.constprop.0+0x78/0xb8\n kernel: [\u0026lt;00000000c99dc8dc\u0026gt;] __kmalloc+0x434/0x590\n kernel: [\u0026lt;00000000c9b4c0ce\u0026gt;] ext4_htree_store_dirent+0x4e/0x1c0\n kernel: [\u0026lt;00000000c9b908a2\u0026gt;] htree_dirblock_to_tree+0x17a/0x3f0\n kernel: \n---truncated---(CVE-2024-26957)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnfs: fix UAF in direct writes\r\n\r\nIn production we have been hitting the following warning consistently\r\n\r\n------------[ cut here ]------------\nrefcount_t: underflow; use-after-free.\nWARNING: CPU: 17 PID: 1800359 at lib/refcount.c:28 refcount_warn_saturate+0x9c/0xe0\nWorkqueue: nfsiod nfs_direct_write_schedule_work [nfs]\nRIP: 0010:refcount_warn_saturate+0x9c/0xe0\nPKRU: 55555554\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? __warn+0x9f/0x130\n ? refcount_warn_saturate+0x9c/0xe0\n ? report_bug+0xcc/0x150\n ? handle_bug+0x3d/0x70\n ? exc_invalid_op+0x16/0x40\n ? asm_exc_invalid_op+0x16/0x20\n ? refcount_warn_saturate+0x9c/0xe0\n nfs_direct_write_schedule_work+0x237/0x250 [nfs]\n process_one_work+0x12f/0x4a0\n worker_thread+0x14e/0x3b0\n ? ZSTD_getCParams_internal+0x220/0x220\n kthread+0xdc/0x120\n ? __btf_name_valid+0xa0/0xa0\n ret_from_fork+0x1f/0x30\r\n\r\nThis is because we\u0026apos;re completing the nfs_direct_request twice in a row.\r\n\r\nThe source of this is when we have our commit requests to submit, we\nprocess them and send them off, and then in the completion path for the\ncommit requests we have\r\n\r\nif (nfs_commit_end(cinfo.mds))\n\tnfs_direct_write_complete(dreq);\r\n\r\nHowever since we\u0026apos;re submitting asynchronous requests we sometimes have\none that completes before we submit the next one, so we end up calling\ncomplete on the nfs_direct_request twice.\r\n\r\nThe only other place we use nfs_generic_commit_list() is in\n__nfs_commit_inode, which wraps this call in a\r\n\r\nnfs_commit_begin();\nnfs_commit_end();\r\n\r\nWhich is a common pattern for this style of completion handling, one\nthat is also repeated in the direct code with get_dreq()/put_dreq()\ncalls around where we process events as well as in the completion paths.\r\n\r\nFix this by using the same pattern for the commit requests.\r\n\r\nBefore with my 200 node rocksdb stress running this warning would pop\nevery 10ish minutes. With my patch the stress test has been running for\nseveral hours without popping.(CVE-2024-26958)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmm: swap: fix race between free_swap_and_cache() and swapoff()\r\n\r\nThere was previously a theoretical window where swapoff() could run and\nteardown a swap_info_struct while a call to free_swap_and_cache() was\nrunning in another thread. This could cause, amongst other bad\npossibilities, swap_page_trans_huge_swapped() (called by\nfree_swap_and_cache()) to access the freed memory for swap_map.\r\n\r\nThis is a theoretical problem and I haven\u0026apos;t been able to provoke it from a\ntest case. But there has been agreement based on code review that this is\npossible (see link below).\r\n\r\nFix it by using get_swap_device()/put_swap_device(), which will stall\nswapoff(). There was an extra check in _swap_info_get() to confirm that\nthe swap entry was not free. This isn\u0026apos;t present in get_swap_device()\nbecause it doesn\u0026apos;t make sense in general due to the race between getting\nthe reference and swapoff. So I\u0026apos;ve added an equivalent check directly in\nfree_swap_and_cache().\r\n\r\nDetails of how to provoke one possible issue (thanks to David Hildenbrand\nfor deriving this):\r\n\r\n--8\u0026lt;-----\r\n\r\n__swap_entry_free() might be the last user and result in\n\u0026quot;count == SWAP_HAS_CACHE\u0026quot;.\r\n\r\nswapoff-\u0026gt;try_to_unuse() will stop as soon as soon as si-\u0026gt;inuse_pages==0.\r\n\r\nSo the question is: could someone reclaim the folio and turn\nsi-\u0026gt;inuse_pages==0, before we completed swap_page_trans_huge_swapped().\r\n\r\nImagine the following: 2 MiB folio in the swapcache. Only 2 subpages are\nstill references by swap entries.\r\n\r\nProcess 1 still references subpage 0 via swap entry.\nProcess 2 still references subpage 1 via swap entry.\r\n\r\nProcess 1 quits. Calls free_swap_and_cache().\n-\u0026gt; count == SWAP_HAS_CACHE\n[then, preempted in the hypervisor etc.]\r\n\r\nProcess 2 quits. Calls free_swap_and_cache().\n-\u0026gt; count == SWAP_HAS_CACHE\r\n\r\nProcess 2 goes ahead, passes swap_page_trans_huge_swapped(), and calls\n__try_to_reclaim_swap().\r\n\r\n__try_to_reclaim_swap()-\u0026gt;folio_free_swap()-\u0026gt;delete_from_swap_cache()-\u0026gt;\nput_swap_folio()-\u0026gt;free_swap_slot()-\u0026gt;swapcache_free_entries()-\u0026gt;\nswap_entry_free()-\u0026gt;swap_range_free()-\u0026gt;\n...\nWRITE_ONCE(si-\u0026gt;inuse_pages, si-\u0026gt;inuse_pages - nr_entries);\r\n\r\nWhat stops swapoff to succeed after process 2 reclaimed the swap cache\nbut before process1 finished its call to swap_page_trans_huge_swapped()?\r\n\r\n--8\u0026lt;-----(CVE-2024-26960)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmac802154: fix llsec key resources release in mac802154_llsec_key_del\r\n\r\nmac802154_llsec_key_del() can free resources of a key directly without\nfollowing the RCU rules for waiting before the end of a grace period. This\nmay lead to use-after-free in case llsec_lookup_key() is traversing the\nlist of keys in parallel with a key deletion:\r\n\r\nrefcount_t: addition on 0; use-after-free.\nWARNING: CPU: 4 PID: 16000 at lib/refcount.c:25 refcount_warn_saturate+0x162/0x2a0\nModules linked in:\nCPU: 4 PID: 16000 Comm: wpan-ping Not tainted 6.7.0 #19\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014\nRIP: 0010:refcount_warn_saturate+0x162/0x2a0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n llsec_lookup_key.isra.0+0x890/0x9e0\n mac802154_llsec_encrypt+0x30c/0x9c0\n ieee802154_subif_start_xmit+0x24/0x1e0\n dev_hard_start_xmit+0x13e/0x690\n sch_direct_xmit+0x2ae/0xbc0\n __dev_queue_xmit+0x11dd/0x3c20\n dgram_sendmsg+0x90b/0xd60\n __sys_sendto+0x466/0x4c0\n __x64_sys_sendto+0xe0/0x1c0\n do_syscall_64+0x45/0xf0\n entry_SYSCALL_64_after_hwframe+0x6e/0x76\r\n\r\nAlso, ieee802154_llsec_key_entry structures are not freed by\nmac802154_llsec_key_del():\r\n\r\nunreferenced object 0xffff8880613b6980 (size 64):\n comm \u0026quot;iwpan\u0026quot;, pid 2176, jiffies 4294761134 (age 60.475s)\n hex dump (first 32 bytes):\n 78 0d 8f 18 80 88 ff ff 22 01 00 00 00 00 ad de x.......\u0026quot;.......\n 00 00 00 00 00 00 00 00 03 00 cd ab 00 00 00 00 ................\n backtrace:\n [\u0026lt;ffffffff81dcfa62\u0026gt;] __kmem_cache_alloc_node+0x1e2/0x2d0\n [\u0026lt;ffffffff81c43865\u0026gt;] kmalloc_trace+0x25/0xc0\n [\u0026lt;ffffffff88968b09\u0026gt;] mac802154_llsec_key_add+0xac9/0xcf0\n [\u0026lt;ffffffff8896e41a\u0026gt;] ieee802154_add_llsec_key+0x5a/0x80\n [\u0026lt;ffffffff8892adc6\u0026gt;] nl802154_add_llsec_key+0x426/0x5b0\n [\u0026lt;ffffffff86ff293e\u0026gt;] genl_family_rcv_msg_doit+0x1fe/0x2f0\n [\u0026lt;ffffffff86ff46d1\u0026gt;] genl_rcv_msg+0x531/0x7d0\n [\u0026lt;ffffffff86fee7a9\u0026gt;] netlink_rcv_skb+0x169/0x440\n [\u0026lt;ffffffff86ff1d88\u0026gt;] genl_rcv+0x28/0x40\n [\u0026lt;ffffffff86fec15c\u0026gt;] netlink_unicast+0x53c/0x820\n [\u0026lt;ffffffff86fecd8b\u0026gt;] netlink_sendmsg+0x93b/0xe60\n [\u0026lt;ffffffff86b91b35\u0026gt;] ____sys_sendmsg+0xac5/0xca0\n [\u0026lt;ffffffff86b9c3dd\u0026gt;] ___sys_sendmsg+0x11d/0x1c0\n [\u0026lt;ffffffff86b9c65a\u0026gt;] __sys_sendmsg+0xfa/0x1d0\n [\u0026lt;ffffffff88eadbf5\u0026gt;] do_syscall_64+0x45/0xf0\n [\u0026lt;ffffffff890000ea\u0026gt;] entry_SYSCALL_64_after_hwframe+0x6e/0x76\r\n\r\nHandle the proper resource release in the RCU callback function\nmac802154_llsec_key_del_rcu().\r\n\r\nNote that if llsec_lookup_key() finds a key, it gets a refcount via\nllsec_key_get() and locally copies key id from key_entry (which is a\nlist element). So it\u0026apos;s safe to call llsec_key_put() and free the list\nentry after the RCU grace period elapses.\r\n\r\nFound by Linux Verification Center (linuxtesting.org).(CVE-2024-26961)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nclk: qcom: mmcc-msm8974: fix terminating of frequency table arrays\r\n\r\nThe frequency table arrays are supposed to be terminated with an\nempty element. Add such entry to the end of the arrays where it\nis missing in order to avoid possible out-of-bound access when\nthe table is traversed by functions like qcom_find_freq() or\nqcom_find_freq_floor().\r\n\r\nOnly compile tested.(CVE-2024-26965)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nclk: qcom: mmcc-apq8084: fix terminating of frequency table arrays\r\n\r\nThe frequency table arrays are supposed to be terminated with an\nempty element. Add such entry to the end of the arrays where it\nis missing in order to avoid possible out-of-bound access when\nthe table is traversed by functions like qcom_find_freq() or\nqcom_find_freq_floor().\r\n\r\nOnly compile tested.(CVE-2024-26966)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nclk: qcom: gcc-ipq8074: fix terminating of frequency table arrays\r\n\r\nThe frequency table arrays are supposed to be terminated with an\nempty element. Add such entry to the end of the arrays where it\nis missing in order to avoid possible out-of-bound access when\nthe table is traversed by functions like qcom_find_freq() or\nqcom_find_freq_floor().\r\n\r\nOnly compile tested.(CVE-2024-26969)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncrypto: qat - resolve race condition during AER recovery\r\n\r\nDuring the PCI AER system\u0026apos;s error recovery process, the kernel driver\nmay encounter a race condition with freeing the reset_data structure\u0026apos;s\nmemory. If the device restart will take more than 10 seconds the function\nscheduling that restart will exit due to a timeout, and the reset_data\nstructure will be freed. However, this data structure is used for\ncompletion notification after the restart is completed, which leads\nto a UAF bug.\r\n\r\nThis results in a KFENCE bug notice.\r\n\r\n BUG: KFENCE: use-after-free read in adf_device_reset_worker+0x38/0xa0 [intel_qat]\n Use-after-free read at 0x00000000bc56fddf (in kfence-#142):\n adf_device_reset_worker+0x38/0xa0 [intel_qat]\n process_one_work+0x173/0x340\r\n\r\nTo resolve this race condition, the memory associated to the container\nof the work_struct is freed on the worker if the timeout expired,\notherwise on the function that schedules the worker.\nThe timeout detection can be done by checking if the caller is\nstill waiting for completion or not by using completion_done() function.(CVE-2024-26974)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nKVM: Always flush async #PF workqueue when vCPU is being destroyed\r\n\r\nAlways flush the per-vCPU async #PF workqueue when a vCPU is clearing its\ncompletion queue, e.g. when a VM and all its vCPUs is being destroyed.\nKVM must ensure that none of its workqueue callbacks is running when the\nlast reference to the KVM _module_ is put. Gifting a reference to the\nassociated VM prevents the workqueue callback from dereferencing freed\nvCPU/VM memory, but does not prevent the KVM module from being unloaded\nbefore the callback completes.\r\n\r\nDrop the misguided VM refcount gifting, as calling kvm_put_kvm() from\nasync_pf_execute() if kvm_put_kvm() flushes the async #PF workqueue will\nresult in deadlock. async_pf_execute() can\u0026apos;t return until kvm_put_kvm()\nfinishes, and kvm_put_kvm() can\u0026apos;t return until async_pf_execute() finishes:\r\n\r\n WARNING: CPU: 8 PID: 251 at virt/kvm/kvm_main.c:1435 kvm_put_kvm+0x2d/0x320 [kvm]\n Modules linked in: vhost_net vhost vhost_iotlb tap kvm_intel kvm irqbypass\n CPU: 8 PID: 251 Comm: kworker/8:1 Tainted: G W 6.6.0-rc1-e7af8d17224a-x86/gmem-vm #119\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015\n Workqueue: events async_pf_execute [kvm]\n RIP: 0010:kvm_put_kvm+0x2d/0x320 [kvm]\n Call Trace:\n \u0026lt;TASK\u0026gt;\n async_pf_execute+0x198/0x260 [kvm]\n process_one_work+0x145/0x2d0\n worker_thread+0x27e/0x3a0\n kthread+0xba/0xe0\n ret_from_fork+0x2d/0x50\n ret_from_fork_asm+0x11/0x20\n \u0026lt;/TASK\u0026gt;\n ---[ end trace 0000000000000000 ]---\n INFO: task kworker/8:1:251 blocked for more than 120 seconds.\n Tainted: G W 6.6.0-rc1-e7af8d17224a-x86/gmem-vm #119\n \u0026quot;echo 0 \u0026gt; /proc/sys/kernel/hung_task_timeout_secs\u0026quot; disables this message.\n task:kworker/8:1 state:D stack:0 pid:251 ppid:2 flags:0x00004000\n Workqueue: events async_pf_execute [kvm]\n Call Trace:\n \u0026lt;TASK\u0026gt;\n __schedule+0x33f/0xa40\n schedule+0x53/0xc0\n schedule_timeout+0x12a/0x140\n __wait_for_common+0x8d/0x1d0\n __flush_work.isra.0+0x19f/0x2c0\n kvm_clear_async_pf_completion_queue+0x129/0x190 [kvm]\n kvm_arch_destroy_vm+0x78/0x1b0 [kvm]\n kvm_put_kvm+0x1c1/0x320 [kvm]\n async_pf_execute+0x198/0x260 [kvm]\n process_one_work+0x145/0x2d0\n worker_thread+0x27e/0x3a0\n kthread+0xba/0xe0\n ret_from_fork+0x2d/0x50\n ret_from_fork_asm+0x11/0x20\n \u0026lt;/TASK\u0026gt;\r\n\r\nIf kvm_clear_async_pf_completion_queue() actually flushes the workqueue,\nthen there\u0026apos;s no need to gift async_pf_execute() a reference because all\ninvocations of async_pf_execute() will be forced to complete before the\nvCPU and its VM are destroyed/freed. And that in turn fixes the module\nunloading bug as __fput() won\u0026apos;t do module_put() on the last vCPU reference\nuntil the vCPU has been freed, e.g. if closing the vCPU file also puts the\nlast reference to the KVM module.\r\n\r\nNote that kvm_check_async_pf_completion() may also take the work item off\nthe completion queue and so also needs to flush the work queue, as the\nwork will not be seen by kvm_clear_async_pf_completion_queue(). Waiting\non the workqueue could theoretically delay a vCPU due to waiting for the\nwork to complete, but that\u0026apos;s a very, very small chance, and likely a very\nsmall delay. kvm_arch_async_page_present_queued() unconditionally makes a\nnew request, i.e. will effectively delay entering the guest, so the\nremaining work is really just:\r\n\r\n trace_kvm_async_pf_completed(addr, cr2_or_gpa);\r\n\r\n __kvm_vcpu_wake_up(vcpu);\r\n\r\n mmput(mm);\r\n\r\nand mmput() can\u0026apos;t drop the last reference to the page tables if the vCPU is\nstill alive, i.e. the vCPU won\u0026apos;t get stuck tearing down page tables.\r\n\r\nAdd a helper to do the flushing, specifically to deal with \u0026quot;wakeup all\u0026quot;\nwork items, as they aren\u0026apos;t actually work items, i.e. are never placed in a\nworkqueue. Trying to flush a bogus workqueue entry rightly makes\n__flush_work() complain (kudos to whoever added that sanity check).\r\n\r\nNote, commit 5f6de5cbebee (\u0026quot;KVM: Prevent module exit until al\n---truncated---(CVE-2024-26976)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: fix OOB in nilfs_set_de_type\r\n\r\nThe size of the nilfs_type_by_mode array in the fs/nilfs2/dir.c file is\ndefined as \u0026quot;S_IFMT \u0026gt;\u0026gt; S_SHIFT\u0026quot;, but the nilfs_set_de_type() function,\nwhich uses this array, specifies the index to read from the array in the\nsame way as \u0026quot;(mode \u0026amp; S_IFMT) \u0026gt;\u0026gt; S_SHIFT\u0026quot;.\r\n\r\nstatic void nilfs_set_de_type(struct nilfs_dir_entry *de, struct inode\n *inode)\n{\n\tumode_t mode = inode-\u0026gt;i_mode;\r\n\r\n\tde-\u0026gt;file_type = nilfs_type_by_mode[(mode \u0026amp; S_IFMT)\u0026gt;\u0026gt;S_SHIFT]; // oob\n}\r\n\r\nHowever, when the index is determined this way, an out-of-bounds (OOB)\nerror occurs by referring to an index that is 1 larger than the array size\nwhen the condition \u0026quot;mode \u0026amp; S_IFMT == S_IFMT\u0026quot; is satisfied. Therefore, a\npatch to resize the nilfs_type_by_mode array should be applied to prevent\nOOB errors.(CVE-2024-26981)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nSquashfs: check the inode number is not the invalid value of zero\r\n\r\nSyskiller has produced an out of bounds access in fill_meta_index().\r\n\r\nThat out of bounds access is ultimately caused because the inode\nhas an inode number with the invalid value of zero, which was not checked.\r\n\r\nThe reason this causes the out of bounds access is due to following\nsequence of events:\r\n\r\n1. Fill_meta_index() is called to allocate (via empty_meta_index())\n and fill a metadata index. It however suffers a data read error\n and aborts, invalidating the newly returned empty metadata index.\n It does this by setting the inode number of the index to zero,\n which means unused (zero is not a valid inode number).\r\n\r\n2. When fill_meta_index() is subsequently called again on another\n read operation, locate_meta_index() returns the previous index\n because it matches the inode number of 0. Because this index\n has been returned it is expected to have been filled, and because\n it hasn\u0026apos;t been, an out of bounds access is performed.\r\n\r\nThis patch adds a sanity check which checks that the inode number\nis not zero when the inode is created and returns -EINVAL if it is.\r\n\r\n[phillip@squashfs.org.uk: whitespace fix]\n Link: https://lkml.kernel.org/r/20240409204723.446925-1-phillip@squashfs.org.uk(CVE-2024-26982)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfs: sysfs: Fix reference leak in sysfs_break_active_protection()\r\n\r\nThe sysfs_break_active_protection() routine has an obvious reference\nleak in its error path. If the call to kernfs_find_and_get() fails then\nkn will be NULL, so the companion sysfs_unbreak_active_protection()\nroutine won\u0026apos;t get called (and would only cause an access violation by\ntrying to dereference kn-\u0026gt;parent if it was called). As a result, the\nreference to kobj acquired at the start of the function will never be\nreleased.\r\n\r\nFix the leak by adding an explicit kobject_put() call when kn is NULL.(CVE-2024-26993)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nspeakup: Avoid crash on very long word\r\n\r\nIn case a console is set up really large and contains a really long word\n(\u0026gt; 256 characters), we have to stop before the length of the word buffer.(CVE-2024-26994)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: gadget: f_ncm: Fix UAF ncm object at re-bind after usb ep transport error\r\n\r\nWhen ncm function is working and then stop usb0 interface for link down,\neth_stop() is called. At this piont, accidentally if usb transport error\nshould happen in usb_ep_enable(), \u0026apos;in_ep\u0026apos; and/or \u0026apos;out_ep\u0026apos; may not be enabled.\r\n\r\nAfter that, ncm_disable() is called to disable for ncm unbind\nbut gether_disconnect() is never called since \u0026apos;in_ep\u0026apos; is not enabled.\r\n\r\nAs the result, ncm object is released in ncm unbind\nbut \u0026apos;dev-\u0026gt;port_usb\u0026apos; associated to \u0026apos;ncm-\u0026gt;port\u0026apos; is not NULL.\r\n\r\nAnd when ncm bind again to recover netdev, ncm object is reallocated\nbut usb0 interface is already associated to previous released ncm object.\r\n\r\nTherefore, once usb0 interface is up and eth_start_xmit() is called,\nreleased ncm object is dereferrenced and it might cause use-after-free memory.\r\n\r\n[function unlink via configfs]\n usb0: eth_stop dev-\u0026gt;port_usb=ffffff9b179c3200\n --\u0026gt; error happens in usb_ep_enable().\n NCM: ncm_disable: ncm=ffffff9b179c3200\n --\u0026gt; no gether_disconnect() since ncm-\u0026gt;port.in_ep-\u0026gt;enabled is false.\n NCM: ncm_unbind: ncm unbind ncm=ffffff9b179c3200\n NCM: ncm_free: ncm free ncm=ffffff9b179c3200 \u0026lt;-- released ncm\r\n\r\n[function link via configfs]\n NCM: ncm_alloc: ncm alloc ncm=ffffff9ac4f8a000\n NCM: ncm_bind: ncm bind ncm=ffffff9ac4f8a000\n NCM: ncm_set_alt: ncm=ffffff9ac4f8a000 alt=0\n usb0: eth_open dev-\u0026gt;port_usb=ffffff9b179c3200 \u0026lt;-- previous released ncm\n usb0: eth_start dev-\u0026gt;port_usb=ffffff9b179c3200 \u0026lt;--\n eth_start_xmit()\n --\u0026gt; dev-\u0026gt;wrap()\n Unable to handle kernel paging request at virtual address dead00000000014f\r\n\r\nThis patch addresses the issue by checking if \u0026apos;ncm-\u0026gt;netdev\u0026apos; is not NULL at\nncm_disable() to call gether_disconnect() to deassociate \u0026apos;dev-\u0026gt;port_usb\u0026apos;.\nIt\u0026apos;s more reasonable to check \u0026apos;ncm-\u0026gt;netdev\u0026apos; to call gether_connect/disconnect\nrather than check \u0026apos;ncm-\u0026gt;port.in_ep-\u0026gt;enabled\u0026apos; since it might not be enabled\nbut the gether connection might be established.(CVE-2024-26996)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nserial/pmac_zilog: Remove flawed mitigation for rx irq flood\r\n\r\nThe mitigation was intended to stop the irq completely. That may be\nbetter than a hard lock-up but it turns out that you get a crash anyway\nif you\u0026apos;re using pmac_zilog as a serial console:\r\n\r\nttyPZ0: pmz: rx irq flood !\nBUG: spinlock recursion on CPU#0, swapper/0\r\n\r\nThat\u0026apos;s because the pr_err() call in pmz_receive_chars() results in\npmz_console_write() attempting to lock a spinlock already locked in\npmz_interrupt(). With CONFIG_DEBUG_SPINLOCK=y, this produces a fatal\nBUG splat. The spinlock in question is the one in struct uart_port.\r\n\r\nEven when it\u0026apos;s not fatal, the serial port rx function ceases to work.\nAlso, the iteration limit doesn\u0026apos;t play nicely with QEMU, as can be\nseen in the bug report linked below.\r\n\r\nA web search for other reports of the error message \u0026quot;pmz: rx irq flood\u0026quot;\ndidn\u0026apos;t produce anything. So I don\u0026apos;t think this code is needed any more.\nRemove it.(CVE-2024-26999)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nserial: mxs-auart: add spinlock around changing cts state\r\n\r\nThe uart_handle_cts_change() function in serial_core expects the caller\nto hold uport-\u0026gt;lock. For example, I have seen the below kernel splat,\nwhen the Bluetooth driver is loaded on an i.MX28 board.\r\n\r\n [ 85.119255] ------------[ cut here ]------------\n [ 85.124413] WARNING: CPU: 0 PID: 27 at /drivers/tty/serial/serial_core.c:3453 uart_handle_cts_change+0xb4/0xec\n [ 85.134694] Modules linked in: hci_uart bluetooth ecdh_generic ecc wlcore_sdio configfs\n [ 85.143314] CPU: 0 PID: 27 Comm: kworker/u3:0 Not tainted 6.6.3-00021-gd62a2f068f92 #1\n [ 85.151396] Hardware name: Freescale MXS (Device Tree)\n [ 85.156679] Workqueue: hci0 hci_power_on [bluetooth]\n (...)\n [ 85.191765] uart_handle_cts_change from mxs_auart_irq_handle+0x380/0x3f4\n [ 85.198787] mxs_auart_irq_handle from __handle_irq_event_percpu+0x88/0x210\n (...)(CVE-2024-27000)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncomedi: vmk80xx: fix incomplete endpoint checking\r\n\r\nWhile vmk80xx does have endpoint checking implemented, some things\ncan fall through the cracks. Depending on the hardware model,\nURBs can have either bulk or interrupt type, and current version\nof vmk80xx_find_usb_endpoints() function does not take that fully\ninto account. While this warning does not seem to be too harmful,\nat the very least it will crash systems with \u0026apos;panic_on_warn\u0026apos; set on\nthem.\r\n\r\nFix the issue found by Syzkaller [1] by somewhat simplifying the\nendpoint checking process with usb_find_common_endpoints() and\nensuring that only expected endpoint types are present.\r\n\r\nThis patch has not been tested on real hardware.\r\n\r\n[1] Syzkaller report:\nusb 1-1: BOGUS urb xfer, pipe 1 != type 3\nWARNING: CPU: 0 PID: 781 at drivers/usb/core/urb.c:504 usb_submit_urb+0xc4e/0x18c0 drivers/usb/core/urb.c:503\n...\nCall Trace:\n \u0026lt;TASK\u0026gt;\n usb_start_wait_urb+0x113/0x520 drivers/usb/core/message.c:59\n vmk80xx_reset_device drivers/comedi/drivers/vmk80xx.c:227 [inline]\n vmk80xx_auto_attach+0xa1c/0x1a40 drivers/comedi/drivers/vmk80xx.c:818\n comedi_auto_config+0x238/0x380 drivers/comedi/drivers.c:1067\n usb_probe_interface+0x5cd/0xb00 drivers/usb/core/driver.c:399\n...\r\n\r\nSimilar issue also found by Syzkaller:(CVE-2024-27001)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm: nv04: Fix out of bounds access\r\n\r\nWhen Output Resource (dcb-\u0026gt;or) value is assigned in\nfabricate_dcb_output(), there may be out of bounds access to\ndac_users array in case dcb-\u0026gt;or is zero because ffs(dcb-\u0026gt;or) is\nused as index there.\nThe \u0026apos;or\u0026apos; argument of fabricate_dcb_output() must be interpreted as a\nnumber of bit to set, not value.\r\n\r\nUtilize macros from \u0026apos;enum nouveau_or\u0026apos; in calls instead of hardcoding.\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-27008)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/sched: Fix mirred deadlock on device recursion\r\n\r\nWhen the mirred action is used on a classful egress qdisc and a packet is\nmirrored or redirected to self we hit a qdisc lock deadlock.\nSee trace below.\r\n\r\n[..... other info removed for brevity....]\n[ 82.890906]\n[ 82.890906] ============================================\n[ 82.890906] WARNING: possible recursive locking detected\n[ 82.890906] 6.8.0-05205-g77fadd89fe2d-dirty #213 Tainted: G W\n[ 82.890906] --------------------------------------------\n[ 82.890906] ping/418 is trying to acquire lock:\n[ 82.890906] ffff888006994110 (\u0026amp;sch-\u0026gt;q.lock){+.-.}-{3:3}, at:\n__dev_queue_xmit+0x1778/0x3550\n[ 82.890906]\n[ 82.890906] but task is already holding lock:\n[ 82.890906] ffff888006994110 (\u0026amp;sch-\u0026gt;q.lock){+.-.}-{3:3}, at:\n__dev_queue_xmit+0x1778/0x3550\n[ 82.890906]\n[ 82.890906] other info that might help us debug this:\n[ 82.890906] Possible unsafe locking scenario:\n[ 82.890906]\n[ 82.890906] CPU0\n[ 82.890906] ----\n[ 82.890906] lock(\u0026amp;sch-\u0026gt;q.lock);\n[ 82.890906] lock(\u0026amp;sch-\u0026gt;q.lock);\n[ 82.890906]\n[ 82.890906] *** DEADLOCK ***\n[ 82.890906]\n[..... other info removed for brevity....]\r\n\r\nExample setup (eth0-\u0026gt;eth0) to recreate\ntc qdisc add dev eth0 root handle 1: htb default 30\ntc filter add dev eth0 handle 1: protocol ip prio 2 matchall \\\n action mirred egress redirect dev eth0\r\n\r\nAnother example(eth0-\u0026gt;eth1-\u0026gt;eth0) to recreate\ntc qdisc add dev eth0 root handle 1: htb default 30\ntc filter add dev eth0 handle 1: protocol ip prio 2 matchall \\\n action mirred egress redirect dev eth1\r\n\r\ntc qdisc add dev eth1 root handle 1: htb default 30\ntc filter add dev eth1 handle 1: protocol ip prio 2 matchall \\\n action mirred egress redirect dev eth0\r\n\r\nWe fix this by adding an owner field (CPU id) to struct Qdisc set after\nroot qdisc is entered. When the softirq enters it a second time, if the\nqdisc owner is the same CPU, the packet is dropped to break the loop.(CVE-2024-27010)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nf_tables: fix memleak in map from abort path\r\n\r\nThe delete set command does not rely on the transaction object for\nelement removal, therefore, a combination of delete element + delete set\nfrom the abort path could result in restoring twice the refcount of the\nmapping.\r\n\r\nCheck for inactive element in the next generation for the delete element\ncommand in the abort path, skip restoring state if next generation bit\nhas been already cleared. This is similar to the activate logic using\nthe set walk iterator.\r\n\r\n[ 6170.286929] ------------[ cut here ]------------\n[ 6170.286939] WARNING: CPU: 6 PID: 790302 at net/netfilter/nf_tables_api.c:2086 nf_tables_chain_destroy+0x1f7/0x220 [nf_tables]\n[ 6170.287071] Modules linked in: [...]\n[ 6170.287633] CPU: 6 PID: 790302 Comm: kworker/6:2 Not tainted 6.9.0-rc3+ #365\n[ 6170.287768] RIP: 0010:nf_tables_chain_destroy+0x1f7/0x220 [nf_tables]\n[ 6170.287886] Code: df 48 8d 7d 58 e8 69 2e 3b df 48 8b 7d 58 e8 80 1b 37 df 48 8d 7d 68 e8 57 2e 3b df 48 8b 7d 68 e8 6e 1b 37 df 48 89 ef eb c4 \u0026lt;0f\u0026gt; 0b 48 83 c4 08 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 0f\n[ 6170.287895] RSP: 0018:ffff888134b8fd08 EFLAGS: 00010202\n[ 6170.287904] RAX: 0000000000000001 RBX: ffff888125bffb28 RCX: dffffc0000000000\n[ 6170.287912] RDX: 0000000000000003 RSI: ffffffffa20298ab RDI: ffff88811ebe4750\n[ 6170.287919] RBP: ffff88811ebe4700 R08: ffff88838e812650 R09: fffffbfff0623a55\n[ 6170.287926] R10: ffffffff8311d2af R11: 0000000000000001 R12: ffff888125bffb10\n[ 6170.287933] R13: ffff888125bffb10 R14: dead000000000122 R15: dead000000000100\n[ 6170.287940] FS: 0000000000000000(0000) GS:ffff888390b00000(0000) knlGS:0000000000000000\n[ 6170.287948] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 6170.287955] CR2: 00007fd31fc00710 CR3: 0000000133f60004 CR4: 00000000001706f0\n[ 6170.287962] Call Trace:\n[ 6170.287967] \u0026lt;TASK\u0026gt;\n[ 6170.287973] ? __warn+0x9f/0x1a0\n[ 6170.287986] ? nf_tables_chain_destroy+0x1f7/0x220 [nf_tables]\n[ 6170.288092] ? report_bug+0x1b1/0x1e0\n[ 6170.287986] ? nf_tables_chain_destroy+0x1f7/0x220 [nf_tables]\n[ 6170.288092] ? report_bug+0x1b1/0x1e0\n[ 6170.288104] ? handle_bug+0x3c/0x70\n[ 6170.288112] ? exc_invalid_op+0x17/0x40\n[ 6170.288120] ? asm_exc_invalid_op+0x1a/0x20\n[ 6170.288132] ? nf_tables_chain_destroy+0x2b/0x220 [nf_tables]\n[ 6170.288243] ? nf_tables_chain_destroy+0x1f7/0x220 [nf_tables]\n[ 6170.288366] ? nf_tables_chain_destroy+0x2b/0x220 [nf_tables]\n[ 6170.288483] nf_tables_trans_destroy_work+0x588/0x590 [nf_tables](CVE-2024-27011)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/rds: fix WARNING in rds_conn_connect_if_down\r\n\r\nIf connection isn\u0026apos;t established yet, get_mr() will fail, trigger connection after\nget_mr().(CVE-2024-27024)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nspi: spi-mt65xx: Fix NULL pointer access in interrupt handler\r\n\r\nThe TX buffer in spi_transfer can be a NULL pointer, so the interrupt\nhandler may end up writing to the invalid memory and cause crashes.\r\n\r\nAdd a check to trans-\u0026gt;tx_buf before using it.(CVE-2024-27028)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nclk: zynq: Prevent null pointer dereference caused by kmalloc failure\r\n\r\nThe kmalloc() in zynq_clk_setup() will return null if the\nphysical memory has run out. As a result, if we use snprintf()\nto write data to the null address, the null pointer dereference\nbug will happen.\r\n\r\nThis patch uses a stack variable to replace the kmalloc().(CVE-2024-27037)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnfp: flower: handle acti_netdevs allocation failure\r\n\r\nThe kmalloc_array() in nfp_fl_lag_do_work() will return null, if\nthe physical memory has run out. As a result, if we dereference\nthe acti_netdevs, the null pointer dereference bugs will happen.\r\n\r\nThis patch adds a check to judge whether allocation failure occurs.\nIf it happens, the delayed work will be rescheduled and try again.(CVE-2024-27046)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncpufreq: brcmstb-avs-cpufreq: add check for cpufreq_cpu_get\u0026apos;s return value\r\n\r\ncpufreq_cpu_get may return NULL. To avoid NULL-dereference check it\nand return 0 in case of error.\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-27051)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ns390/dasd: fix double module refcount decrement\r\n\r\nOnce the discipline is associated with the device, deleting the device\ntakes care of decrementing the module\u0026apos;s refcount. Doing it manually on\nthis error path causes refcount to artificially decrease on each error\nwhile it should just stay the same.(CVE-2024-27054)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nUSB: usb-storage: Prevent divide-by-0 error in isd200_ata_command\r\n\r\nThe isd200 sub-driver in usb-storage uses the HEADS and SECTORS values\nin the ATA ID information to calculate cylinder and head values when\ncreating a CDB for READ or WRITE commands. The calculation involves\ndivision and modulus operations, which will cause a crash if either of\nthese values is 0. While this never happens with a genuine device, it\ncould happen with a flawed or subversive emulation, as reported by the\nsyzbot fuzzer.\r\n\r\nProtect against this possibility by refusing to bind to the device if\neither the ATA_ID_HEADS or ATA_ID_SECTORS value in the device\u0026apos;s ID\ninformation is 0. This requires isd200_Initialization() to return a\nnegative error code when initialization fails; currently it always\nreturns 0 (even when there is an error).(CVE-2024-27059)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnouveau: lock the client object tree.\r\n\r\nIt appears the client object tree has no locking unless I\u0026apos;ve missed\nsomething else. Fix races around adding/removing client objects,\nmostly vram bar mappings.\r\n\r\n 4562.099306] general protection fault, probably for non-canonical address 0x6677ed422bceb80c: 0000 [#1] PREEMPT SMP PTI\n[ 4562.099314] CPU: 2 PID: 23171 Comm: deqp-vk Not tainted 6.8.0-rc6+ #27\n[ 4562.099324] Hardware name: Gigabyte Technology Co., Ltd. Z390 I AORUS PRO WIFI/Z390 I AORUS PRO WIFI-CF, BIOS F8 11/05/2021\n[ 4562.099330] RIP: 0010:nvkm_object_search+0x1d/0x70 [nouveau]\n[ 4562.099503] Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 0f 1f 44 00 00 48 89 f8 48 85 f6 74 39 48 8b 87 a0 00 00 00 48 85 c0 74 12 \u0026lt;48\u0026gt; 8b 48 f8 48 39 ce 73 15 48 8b 40 10 48 85 c0 75 ee 48 c7 c0 fe\n[ 4562.099506] RSP: 0000:ffffa94cc420bbf8 EFLAGS: 00010206\n[ 4562.099512] RAX: 6677ed422bceb814 RBX: ffff98108791f400 RCX: ffff9810f26b8f58\n[ 4562.099517] RDX: 0000000000000000 RSI: ffff9810f26b9158 RDI: ffff98108791f400\n[ 4562.099519] RBP: ffff9810f26b9158 R08: 0000000000000000 R09: 0000000000000000\n[ 4562.099521] R10: ffffa94cc420bc48 R11: 0000000000000001 R12: ffff9810f02a7cc0\n[ 4562.099526] R13: 0000000000000000 R14: 00000000000000ff R15: 0000000000000007\n[ 4562.099528] FS: 00007f629c5017c0(0000) GS:ffff98142c700000(0000) knlGS:0000000000000000\n[ 4562.099534] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 4562.099536] CR2: 00007f629a882000 CR3: 000000017019e004 CR4: 00000000003706f0\n[ 4562.099541] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[ 4562.099542] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[ 4562.099544] Call Trace:\n[ 4562.099555] \u0026lt;TASK\u0026gt;\n[ 4562.099573] ? die_addr+0x36/0x90\n[ 4562.099583] ? exc_general_protection+0x246/0x4a0\n[ 4562.099593] ? asm_exc_general_protection+0x26/0x30\n[ 4562.099600] ? nvkm_object_search+0x1d/0x70 [nouveau]\n[ 4562.099730] nvkm_ioctl+0xa1/0x250 [nouveau]\n[ 4562.099861] nvif_object_map_handle+0xc8/0x180 [nouveau]\n[ 4562.099986] nouveau_ttm_io_mem_reserve+0x122/0x270 [nouveau]\n[ 4562.100156] ? dma_resv_test_signaled+0x26/0xb0\n[ 4562.100163] ttm_bo_vm_fault_reserved+0x97/0x3c0 [ttm]\n[ 4562.100182] ? __mutex_unlock_slowpath+0x2a/0x270\n[ 4562.100189] nouveau_ttm_fault+0x69/0xb0 [nouveau]\n[ 4562.100356] __do_fault+0x32/0x150\n[ 4562.100362] do_fault+0x7c/0x560\n[ 4562.100369] __handle_mm_fault+0x800/0xc10\n[ 4562.100382] handle_mm_fault+0x17c/0x3e0\n[ 4562.100388] do_user_addr_fault+0x208/0x860\n[ 4562.100395] exc_page_fault+0x7f/0x200\n[ 4562.100402] asm_exc_page_fault+0x26/0x30\n[ 4562.100412] RIP: 0033:0x9b9870\n[ 4562.100419] Code: 85 a8 f7 ff ff 8b 8d 80 f7 ff ff 89 08 e9 18 f2 ff ff 0f 1f 84 00 00 00 00 00 44 89 32 e9 90 fa ff ff 0f 1f 84 00 00 00 00 00 \u0026lt;44\u0026gt; 89 32 e9 f8 f1 ff ff 0f 1f 84 00 00 00 00 00 66 44 89 32 e9 e7\n[ 4562.100422] RSP: 002b:00007fff9ba2dc70 EFLAGS: 00010246\n[ 4562.100426] RAX: 0000000000000004 RBX: 000000000dd65e10 RCX: 000000fff0000000\n[ 4562.100428] RDX: 00007f629a882000 RSI: 00007f629a882000 RDI: 0000000000000066\n[ 4562.100432] RBP: 00007fff9ba2e570 R08: 0000000000000000 R09: 0000000123ddf000\n[ 4562.100434] R10: 0000000000000001 R11: 0000000000000246 R12: 000000007fffffff\n[ 4562.100436] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000\n[ 4562.100446] \u0026lt;/TASK\u0026gt;\n[ 4562.100448] Modules linked in: nf_conntrack_netbios_ns nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables libcrc32c nfnetlink cmac bnep sunrpc iwlmvm intel_rapl_msr intel_rapl_common snd_sof_pci_intel_cnl x86_pkg_temp_thermal intel_powerclamp snd_sof_intel_hda_common mac80211 coretemp snd_soc_acpi_intel_match kvm_intel snd_soc_acpi snd_soc_hdac_hda snd_sof_pci snd_sof_xtensa_dsp snd_sof_intel_hda_mlink \n---truncated---(CVE-2024-27062)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: usbtv: Remove useless locks in usbtv_video_free()\r\n\r\nRemove locks calls in usbtv_video_free() because\nare useless and may led to a deadlock as reported here:\nhttps://syzkaller.appspot.com/x/bisect.txt?x=166dc872180000\nAlso remove usbtv_stop() call since it will be called when\nunregistering the device.\r\n\r\nBefore \u0026apos;c838530d230b\u0026apos; this issue would only be noticed if you\ndisconnect while streaming and now it is noticeable even when\ndisconnecting while not streaming.\r\n\r\n\n[hverkuil: fix minor spelling mistake in log message](CVE-2024-27072)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: ttpci: fix two memleaks in budget_av_attach\r\n\r\nWhen saa7146_register_device and saa7146_vv_init fails, budget_av_attach\nshould free the resources it allocates, like the error-handling of\nttpci_budget_init does. Besides, there are two fixme comment refers to\nsuch deallocations.(CVE-2024-27073)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: dvb-frontends: avoid stack overflow warnings with clang\r\n\r\nA previous patch worked around a KASAN issue in stv0367, now a similar\nproblem showed up with clang:\r\n\r\ndrivers/media/dvb-frontends/stv0367.c:1222:12: error: stack frame size (3624) exceeds limit (2048) in \u0026apos;stv0367ter_set_frontend\u0026apos; [-Werror,-Wframe-larger-than]\n 1214 | static int stv0367ter_set_frontend(struct dvb_frontend *fe)\r\n\r\nRework the stv0367_writereg() function to be simpler and mark both\nregister access functions as noinline_for_stack so the temporary\ni2c_msg structures do not get duplicated on the stack when KASAN_STACK\nis enabled.(CVE-2024-27075)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: v4l2-mem2mem: fix a memleak in v4l2_m2m_register_entity\r\n\r\nThe entity-\u0026gt;name (i.e. name) is allocated in v4l2_m2m_register_entity\nbut isn\u0026apos;t freed in its following error-handling paths. This patch\nadds such deallocation to prevent memleak of entity-\u0026gt;name.(CVE-2024-27077)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: v4l2-tpg: fix some memleaks in tpg_alloc\r\n\r\nIn tpg_alloc, resources should be deallocated in each and every\nerror-handling paths, since they are allocated in for statements.\nOtherwise there would be memleaks because tpg_free is called only when\ntpg_alloc return 0.(CVE-2024-27078)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nSUNRPC: fix some memleaks in gssx_dec_option_array\r\n\r\nThe creds and oa-\u0026gt;data need to be freed in the error-handling paths after\ntheir allocation. So this patch add these deallocations in the\ncorresponding paths.(CVE-2024-27388)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nft_flow_offload: reset dst in route object after setting up flow\r\n\r\ndst is transferred to the flow object, route object does not own it\nanymore. Reset dst in route object, otherwise if flow_offload_add()\nfails, error path releases dst twice, leading to a refcount underflow.(CVE-2024-27403)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetrom: Fix data-races around sysctl_net_busy_read\r\n\r\nWe need to protect the reader reading the sysctl value because the\nvalue can be changed concurrently.(CVE-2024-27419)\r\n\r\nRejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2024-27426)\r\n\r\nRejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2024-27427)\r\n\r\nRejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2024-27428)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndm snapshot: fix lockup in dm_exception_table_exit\r\n\r\nThere was reported lockup when we exit a snapshot with many exceptions.\nFix this by adding \u0026quot;cond_resched\u0026quot; to the loop that frees the exceptions.(CVE-2024-35805)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsoc: fsl: qbman: Always disable interrupts when taking cgr_lock\r\n\r\nsmp_call_function_single disables IRQs when executing the callback. To\nprevent deadlocks, we must disable IRQs when taking cgr_lock elsewhere.\nThis is already done by qman_update_cgr and qman_delete_cgr; fix the\nother lockers.(CVE-2024-35806)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfs/aio: Check IOCB_AIO_RW before the struct aio_kiocb conversion\r\n\r\nThe first kiocb_set_cancel_fn() argument may point at a struct kiocb\nthat is not embedded inside struct aio_kiocb. With the current code,\ndepending on the compiler, the req-\u0026gt;ki_ctx read happens either before\nthe IOCB_AIO_RW test or after that test. Move the req-\u0026gt;ki_ctx read such\nthat it is guaranteed that the IOCB_AIO_RW test happens first.(CVE-2024-35815)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/mlx5e: fix a double-free in arfs_create_groups\r\n\r\nWhen `in` allocated by kvzalloc fails, arfs_create_groups will free\nft-\u0026gt;g and return an error. However, arfs_create_table, the only caller of\narfs_create_groups, will hold this error and call to\nmlx5e_destroy_flow_table, in which the ft-\u0026gt;g will be freed again.(CVE-2024-35835)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nipv6: Fix infinite recursion in fib6_dump_done().\r\n\r\nsyzkaller reported infinite recursive calls of fib6_dump_done() during\nnetlink socket destruction. [1]\r\n\r\nFrom the log, syzkaller sent an AF_UNSPEC RTM_GETROUTE message, and then\nthe response was generated. The following recvmmsg() resumed the dump\nfor IPv6, but the first call of inet6_dump_fib() failed at kzalloc() due\nto the fault injection. [0]\r\n\r\n 12:01:34 executing program 3:\n r0 = socket$nl_route(0x10, 0x3, 0x0)\n sendmsg$nl_route(r0, ... snip ...)\n recvmmsg(r0, ... snip ...) (fail_nth: 8)\r\n\r\nHere, fib6_dump_done() was set to nlk_sk(sk)-\u0026gt;cb.done, and the next call\nof inet6_dump_fib() set it to nlk_sk(sk)-\u0026gt;cb.args[3]. syzkaller stopped\nreceiving the response halfway through, and finally netlink_sock_destruct()\ncalled nlk_sk(sk)-\u0026gt;cb.done().\r\n\r\nfib6_dump_done() calls fib6_dump_end() and nlk_sk(sk)-\u0026gt;cb.done() if it\nis still not NULL. fib6_dump_end() rewrites nlk_sk(sk)-\u0026gt;cb.done() by\nnlk_sk(sk)-\u0026gt;cb.args[3], but it has the same function, not NULL, calling\nitself recursively and hitting the stack guard page.\r\n\r\nTo avoid the issue, let\u0026apos;s set the destructor after kzalloc().\r\n\r\n[0]:\nFAULT_INJECTION: forcing a failure.\nname failslab, interval 1, probability 0, space 0, times 0\nCPU: 1 PID: 432110 Comm: syz-executor.3 Not tainted 6.8.0-12821-g537c2e91d354-dirty #11\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl (lib/dump_stack.c:117)\n should_fail_ex (lib/fault-inject.c:52 lib/fault-inject.c:153)\n should_failslab (mm/slub.c:3733)\n kmalloc_trace (mm/slub.c:3748 mm/slub.c:3827 mm/slub.c:3992)\n inet6_dump_fib (./include/linux/slab.h:628 ./include/linux/slab.h:749 net/ipv6/ip6_fib.c:662)\n rtnl_dump_all (net/core/rtnetlink.c:4029)\n netlink_dump (net/netlink/af_netlink.c:2269)\n netlink_recvmsg (net/netlink/af_netlink.c:1988)\n ____sys_recvmsg (net/socket.c:1046 net/socket.c:2801)\n ___sys_recvmsg (net/socket.c:2846)\n do_recvmmsg (net/socket.c:2943)\n __x64_sys_recvmmsg (net/socket.c:3041 net/socket.c:3034 net/socket.c:3034)\r\n\r\n[1]:\nBUG: TASK stack guard page was hit at 00000000f2fa9af1 (stack is 00000000b7912430..000000009a436beb)\nstack guard page: 0000 [#1] PREEMPT SMP KASAN\nCPU: 1 PID: 223719 Comm: kworker/1:3 Not tainted 6.8.0-12821-g537c2e91d354-dirty #11\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014\nWorkqueue: events netlink_sock_destruct_work\nRIP: 0010:fib6_dump_done (net/ipv6/ip6_fib.c:570)\nCode: 3c 24 e8 f3 e9 51 fd e9 28 fd ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 41 57 41 56 41 55 41 54 55 48 89 fd \u0026lt;53\u0026gt; 48 8d 5d 60 e8 b6 4d 07 fd 48 89 da 48 b8 00 00 00 00 00 fc ff\nRSP: 0018:ffffc9000d980000 EFLAGS: 00010293\nRAX: 0000000000000000 RBX: ffffffff84405990 RCX: ffffffff844059d3\nRDX: ffff8881028e0000 RSI: ffffffff84405ac2 RDI: ffff88810c02f358\nRBP: ffff88810c02f358 R08: 0000000000000007 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000224 R12: 0000000000000000\nR13: ffff888007c82c78 R14: ffff888007c82c68 R15: ffff888007c82c68\nFS: 0000000000000000(0000) GS:ffff88811b100000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: ffffc9000d97fff8 CR3: 0000000102309002 CR4: 0000000000770ef0\nPKRU: 55555554\nCall Trace:\n \u0026lt;#DF\u0026gt;\n \u0026lt;/#DF\u0026gt;\n \u0026lt;TASK\u0026gt;\n fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1))\n fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1))\n ...\n fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1))\n fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1))\n netlink_sock_destruct (net/netlink/af_netlink.c:401)\n __sk_destruct (net/core/sock.c:2177 (discriminator 2))\n sk_destruct (net/core/sock.c:2224)\n __sk_free (net/core/sock.c:2235)\n sk_free (net/core/sock.c:2246)\n process_one_work (kernel/workqueue.c:3259)\n worker_thread (kernel/workqueue.c:3329 kernel/workqueue.\n---truncated---(CVE-2024-35886)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nf_tables: Fix potential data-race in __nft_flowtable_type_get()\r\n\r\nnft_unregister_flowtable_type() within nf_flow_inet_module_exit() can\nconcurrent with __nft_flowtable_type_get() within nf_tables_newflowtable().\nAnd thhere is not any protection when iterate over nf_tables_flowtables\nlist in __nft_flowtable_type_get(). Therefore, there is pertential\ndata-race of nf_tables_flowtables list entry.\r\n\r\nUse list_for_each_entry_rcu() to iterate over nf_tables_flowtables list\nin __nft_flowtable_type_get(), and use rcu_read_lock() in the caller\nnft_flowtable_type_get() to protect the entire type query process.(CVE-2024-35898)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfbmon: prevent division by zero in fb_videomode_from_videomode()\r\n\r\nThe expression htotal * vtotal can have a zero value on\noverflow. It is necessary to prevent division by zero like in\nfb_var_to_videomode().\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with Svace.(CVE-2024-35922)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: lpfc: Fix possible memory leak in lpfc_rcv_padisc()\r\n\r\nThe call to lpfc_sli4_resume_rpi() in lpfc_rcv_padisc() may return an\nunsuccessful status. In such cases, the elsiocb is not issued, the\ncompletion is not called, and thus the elsiocb resource is leaked.\r\n\r\nCheck return value after calling lpfc_sli4_resume_rpi() and conditionally\nrelease the elsiocb resource.(CVE-2024-35930)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: handle chunk tree lookup error in btrfs_relocate_sys_chunks()\r\n\r\nThe unhandled case in btrfs_relocate_sys_chunks() loop is a corruption,\nas it could be caused only by two impossible conditions:\r\n\r\n- at first the search key is set up to look for a chunk tree item, with\n offset -1, this is an inexact search and the key-\u0026gt;offset will contain\n the correct offset upon a successful search, a valid chunk tree item\n cannot have an offset -1\r\n\r\n- after first successful search, the found_key corresponds to a chunk\n item, the offset is decremented by 1 before the next loop, it\u0026apos;s\n impossible to find a chunk item there due to alignment and size\n constraints(CVE-2024-35936)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/client: Fully protect modes[] with dev-\u0026gt;mode_config.mutex\r\n\r\nThe modes[] array contains pointers to modes on the connectors\u0026apos;\nmode lists, which are protected by dev-\u0026gt;mode_config.mutex.\nThus we need to extend modes[] the same protection or by the\ntime we use it the elements may already be pointing to\nfreed/reused memory.(CVE-2024-35950)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nxsk: validate user input for XDP_{UMEM|COMPLETION}_FILL_RING\r\n\r\nsyzbot reported an illegal copy in xsk_setsockopt() [1]\r\n\r\nMake sure to validate setsockopt() @optlen parameter.\r\n\r\n[1]\r\n\r\n BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline]\n BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline]\n BUG: KASAN: slab-out-of-bounds in xsk_setsockopt+0x909/0xa40 net/xdp/xsk.c:1420\nRead of size 4 at addr ffff888028c6cde3 by task syz-executor.0/7549\r\n\r\nCPU: 0 PID: 7549 Comm: syz-executor.0 Not tainted 6.8.0-syzkaller-08951-gfe46a7dd189e #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114\n print_address_description mm/kasan/report.c:377 [inline]\n print_report+0x169/0x550 mm/kasan/report.c:488\n kasan_report+0x143/0x180 mm/kasan/report.c:601\n copy_from_sockptr_offset include/linux/sockptr.h:49 [inline]\n copy_from_sockptr include/linux/sockptr.h:55 [inline]\n xsk_setsockopt+0x909/0xa40 net/xdp/xsk.c:1420\n do_sock_setsockopt+0x3af/0x720 net/socket.c:2311\n __sys_setsockopt+0x1ae/0x250 net/socket.c:2334\n __do_sys_setsockopt net/socket.c:2343 [inline]\n __se_sys_setsockopt net/socket.c:2340 [inline]\n __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340\n do_syscall_64+0xfb/0x240\n entry_SYSCALL_64_after_hwframe+0x6d/0x75\nRIP: 0033:0x7fb40587de69\nCode: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007fb40665a0c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000036\nRAX: ffffffffffffffda RBX: 00007fb4059abf80 RCX: 00007fb40587de69\nRDX: 0000000000000005 RSI: 000000000000011b RDI: 0000000000000006\nRBP: 00007fb4058ca47a R08: 0000000000000002 R09: 0000000000000000\nR10: 0000000020001980 R11: 0000000000000246 R12: 0000000000000000\nR13: 000000000000000b R14: 00007fb4059abf80 R15: 00007fff57ee4d08\n \u0026lt;/TASK\u0026gt;\r\n\r\nAllocated by task 7549:\n kasan_save_stack mm/kasan/common.c:47 [inline]\n kasan_save_track+0x3f/0x80 mm/kasan/common.c:68\n poison_kmalloc_redzone mm/kasan/common.c:370 [inline]\n __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:387\n kasan_kmalloc include/linux/kasan.h:211 [inline]\n __do_kmalloc_node mm/slub.c:3966 [inline]\n __kmalloc+0x233/0x4a0 mm/slub.c:3979\n kmalloc include/linux/slab.h:632 [inline]\n __cgroup_bpf_run_filter_setsockopt+0xd2f/0x1040 kernel/bpf/cgroup.c:1869\n do_sock_setsockopt+0x6b4/0x720 net/socket.c:2293\n __sys_setsockopt+0x1ae/0x250 net/socket.c:2334\n __do_sys_setsockopt net/socket.c:2343 [inline]\n __se_sys_setsockopt net/socket.c:2340 [inline]\n __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340\n do_syscall_64+0xfb/0x240\n entry_SYSCALL_64_after_hwframe+0x6d/0x75\r\n\r\nThe buggy address belongs to the object at ffff888028c6cde0\n which belongs to the cache kmalloc-8 of size 8\nThe buggy address is located 1 bytes to the right of\n allocated 2-byte region [ffff888028c6cde0, ffff888028c6cde2)\r\n\r\nThe buggy address belongs to the physical page:\npage:ffffea0000a31b00 refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888028c6c9c0 pfn:0x28c6c\nanon flags: 0xfff00000000800(slab|node=0|zone=1|lastcpupid=0x7ff)\npage_type: 0xffffffff()\nraw: 00fff00000000800 ffff888014c41280 0000000000000000 dead000000000001\nraw: ffff888028c6c9c0 0000000080800057 00000001ffffffff 0000000000000000\npage dumped because: kasan: bad access detected\npage_owner tracks the page as allocated\npage last allocated via order 0, migratetype Unmovable, gfp_mask 0x112cc0(GFP_USER|__GFP_NOWARN|__GFP_NORETRY), pid 6648, tgid 6644 (syz-executor.0), ts 133906047828, free_ts 133859922223\n set_page_owner include/linux/page_owner.h:31 [inline]\n post_alloc_hook+0x1ea/0x210 mm/page_alloc.c:1533\n prep_new_page mm/page_alloc.c:\n---truncated---(CVE-2024-35976)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nHID: i2c-hid: remove I2C_HID_READ_PENDING flag to prevent lock-up\r\n\r\nThe flag I2C_HID_READ_PENDING is used to serialize I2C operations.\nHowever, this is not necessary, because I2C core already has its own\nlocking for that.\r\n\r\nMore importantly, this flag can cause a lock-up: if the flag is set in\ni2c_hid_xfer() and an interrupt happens, the interrupt handler\n(i2c_hid_irq) will check this flag and return immediately without doing\nanything, then the interrupt handler will be invoked again in an\ninfinite loop.\r\n\r\nSince interrupt handler is an RT task, it takes over the CPU and the\nflag-clearing task never gets scheduled, thus we have a lock-up.\r\n\r\nDelete this unnecessary flag.(CVE-2024-35997)",
"id": "OESA-2024-1677",
"modified": "2026-08-06T11:07:08Z",
"published": "2024-05-31T11:07:08Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1677"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47269"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47284"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47335"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47393"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47455"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47473"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47497"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48695"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48697"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48702"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48704"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48710"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52650"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52652"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52653"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52656"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52683"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52691"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52698"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52813"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52817"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52818"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52835"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52840"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52847"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52867"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52868"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26955"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26956"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26957"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26958"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26960"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26961"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26965"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26966"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26969"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26974"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26976"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26981"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26982"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26993"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26994"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26996"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26999"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27000"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27001"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27008"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27010"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27011"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27024"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27028"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27037"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27046"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27051"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27054"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27059"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27062"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27072"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27073"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27075"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27077"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27078"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27388"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27403"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27419"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27426"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27427"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27428"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35805"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35806"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35815"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35835"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35886"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35898"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35922"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35930"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35936"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35950"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35976"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35997"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2021-47269",
"CVE-2021-47284",
"CVE-2021-47335",
"CVE-2021-47393",
"CVE-2021-47455",
"CVE-2021-47473",
"CVE-2021-47497",
"CVE-2022-48695",
"CVE-2022-48697",
"CVE-2022-48702",
"CVE-2022-48704",
"CVE-2022-48710",
"CVE-2023-52650",
"CVE-2023-52652",
"CVE-2023-52653",
"CVE-2023-52656",
"CVE-2023-52683",
"CVE-2023-52691",
"CVE-2023-52698",
"CVE-2023-52813",
"CVE-2023-52817",
"CVE-2023-52818",
"CVE-2023-52835",
"CVE-2023-52840",
"CVE-2023-52847",
"CVE-2023-52867",
"CVE-2023-52868",
"CVE-2024-26955",
"CVE-2024-26956",
"CVE-2024-26957",
"CVE-2024-26958",
"CVE-2024-26960",
"CVE-2024-26961",
"CVE-2024-26965",
"CVE-2024-26966",
"CVE-2024-26969",
"CVE-2024-26974",
"CVE-2024-26976",
"CVE-2024-26981",
"CVE-2024-26982",
"CVE-2024-26993",
"CVE-2024-26994",
"CVE-2024-26996",
"CVE-2024-26999",
"CVE-2024-27000",
"CVE-2024-27001",
"CVE-2024-27008",
"CVE-2024-27010",
"CVE-2024-27011",
"CVE-2024-27024",
"CVE-2024-27028",
"CVE-2024-27037",
"CVE-2024-27046",
"CVE-2024-27051",
"CVE-2024-27054",
"CVE-2024-27059",
"CVE-2024-27062",
"CVE-2024-27072",
"CVE-2024-27073",
"CVE-2024-27075",
"CVE-2024-27077",
"CVE-2024-27078",
"CVE-2024-27388",
"CVE-2024-27403",
"CVE-2024-27419",
"CVE-2024-27426",
"CVE-2024-27427",
"CVE-2024-27428",
"CVE-2024-35805",
"CVE-2024-35806",
"CVE-2024-35815",
"CVE-2024-35835",
"CVE-2024-35886",
"CVE-2024-35898",
"CVE-2024-35922",
"CVE-2024-35930",
"CVE-2024-35936",
"CVE-2024-35950",
"CVE-2024-35976",
"CVE-2024-35997"
]
}
OESA-2024-1678 (CVE-2021-47269)
Vulnerability from osv_openeuler – Published: 2024-05-31 11:07 – Updated: 2026-08-06 11:07 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
usb: dwc3: ep0: fix NULL pointer exception
There is no validation of the index from dwc3_wIndex_to_dep() and we might be referring a non-existing ep and trigger a NULL pointer exception. In certain configurations we might use fewer eps and the index might wrongly indicate a larger ep index than existing.
By adding this validation from the patch we can actually report a wrong index back to the caller.
In our usecase we are using a composite device on an older kernel, but upstream might use this fix also. Unfortunately, I cannot describe the hardware for others to reproduce the issue as it is a proprietary implementation.
[ 82.958261] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a4 [ 82.966891] Mem abort info: [ 82.969663] ESR = 0x96000006 [ 82.972703] Exception class = DABT (current EL), IL = 32 bits [ 82.978603] SET = 0, FnV = 0 [ 82.981642] EA = 0, S1PTW = 0 [ 82.984765] Data abort info: [ 82.987631] ISV = 0, ISS = 0x00000006 [ 82.991449] CM = 0, WnR = 0 [ 82.994409] user pgtable: 4k pages, 39-bit VAs, pgdp = 00000000c6210ccc [ 83.000999] [00000000000000a4] pgd=0000000053aa5003, pud=0000000053aa5003, pmd=0000000000000000 [ 83.009685] Internal error: Oops: 96000006 [#1] PREEMPT SMP [ 83.026433] Process irq/62-dwc3 (pid: 303, stack limit = 0x000000003985154c) [ 83.033470] CPU: 0 PID: 303 Comm: irq/62-dwc3 Not tainted 4.19.124 #1 [ 83.044836] pstate: 60000085 (nZCv daIf -PAN -UAO) [ 83.049628] pc : dwc3_ep0_handle_feature+0x414/0x43c [ 83.054558] lr : dwc3_ep0_interrupt+0x3b4/0xc94
...
[ 83.141788] Call trace: [ 83.144227] dwc3_ep0_handle_feature+0x414/0x43c [ 83.148823] dwc3_ep0_interrupt+0x3b4/0xc94 [ 83.181546] ---[ end trace aac6b5267d84c32f ]---(CVE-2021-47269)
In the Linux kernel, the following vulnerability has been resolved:
isdn: mISDN: netjet: Fix crash in nj_probe:
'nj_setup' in netjet.c might fail with -EIO and in this case 'card->irq' is initialized and is bigger than zero. A subsequent call to 'nj_release' will free the irq that has not been requested.
Fix this bug by deleting the previous assignment to 'card->irq' and just keep the assignment before 'request_irq'.
The KASAN's log reveals it:
[ 3.354615 ] WARNING: CPU: 0 PID: 1 at kernel/irq/manage.c:1826 free_irq+0x100/0x480 [ 3.355112 ] Modules linked in: [ 3.355310 ] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.13.0-rc1-00144-g25a1298726e #13 [ 3.355816 ] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014 [ 3.356552 ] RIP: 0010:free_irq+0x100/0x480 [ 3.356820 ] Code: 6e 08 74 6f 4d 89 f4 e8 5e ac 09 00 4d 8b 74 24 18 4d 85 f6 75 e3 e8 4f ac 09 00 8b 75 c8 48 c7 c7 78 c1 2e 85 e8 e0 cf f5 ff <0f> 0b 48 8b 75 c0 4c 89 ff e8 72 33 0b 03 48 8b 43 40 4c 8b a0 80 [ 3.358012 ] RSP: 0000:ffffc90000017b48 EFLAGS: 00010082 [ 3.358357 ] RAX: 0000000000000000 RBX: ffff888104dc8000 RCX: 0000000000000000 [ 3.358814 ] RDX: ffff8881003c8000 RSI: ffffffff8124a9e6 RDI: 00000000ffffffff [ 3.359272 ] RBP: ffffc90000017b88 R08: 0000000000000000 R09: 0000000000000000 [ 3.359732 ] R10: ffffc900000179f0 R11: 0000000000001d04 R12: 0000000000000000 [ 3.360195 ] R13: ffff888107dc6000 R14: ffff888107dc6928 R15: ffff888104dc80a8 [ 3.360652 ] FS: 0000000000000000(0000) GS:ffff88817bc00000(0000) knlGS:0000000000000000 [ 3.361170 ] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 3.361538 ] CR2: 0000000000000000 CR3: 000000000582e000 CR4: 00000000000006f0 [ 3.362003 ] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 3.362175 ] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 3.362175 ] Call Trace: [ 3.362175 ] nj_release+0x51/0x1e0 [ 3.362175 ] nj_probe+0x450/0x950 [ 3.362175 ] ? pci_device_remove+0x110/0x110 [ 3.362175 ] local_pci_probe+0x45/0xa0 [ 3.362175 ] pci_device_probe+0x12b/0x1d0 [ 3.362175 ] really_probe+0x2a9/0x610 [ 3.362175 ] driver_probe_device+0x90/0x1d0 [ 3.362175 ] ? mutex_lock_nested+0x1b/0x20 [ 3.362175 ] device_driver_attach+0x68/0x70 [ 3.362175 ] __driver_attach+0x124/0x1b0 [ 3.362175 ] ? device_driver_attach+0x70/0x70 [ 3.362175 ] bus_for_each_dev+0xbb/0x110 [ 3.362175 ] ? rdinit_setup+0x45/0x45 [ 3.362175 ] driver_attach+0x27/0x30 [ 3.362175 ] bus_add_driver+0x1eb/0x2a0 [ 3.362175 ] driver_register+0xa9/0x180 [ 3.362175 ] __pci_register_driver+0x82/0x90 [ 3.362175 ] ? w6692_init+0x38/0x38 [ 3.362175 ] nj_init+0x36/0x38 [ 3.362175 ] do_one_initcall+0x7f/0x3d0 [ 3.362175 ] ? rdinit_setup+0x45/0x45 [ 3.362175 ] ? rcu_read_lock_sched_held+0x4f/0x80 [ 3.362175 ] kernel_init_freeable+0x2aa/0x301 [ 3.362175 ] ? rest_init+0x2c0/0x2c0 [ 3.362175 ] kernel_init+0x18/0x190 [ 3.362175 ] ? rest_init+0x2c0/0x2c0 [ 3.362175 ] ? rest_init+0x2c0/0x2c0 [ 3.362175 ] ret_from_fork+0x1f/0x30 [ 3.362175 ] Kernel panic - not syncing: panic_on_warn set ... [ 3.362175 ] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.13.0-rc1-00144-g25a1298726e #13 [ 3.362175 ] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014 [ 3.362175 ] Call Trace: [ 3.362175 ] dump_stack+0xba/0xf5 [ 3.362175 ] ? free_irq+0x100/0x480 [ 3.362175 ] panic+0x15a/0x3f2 [ 3.362175 ] ? __warn+0xf2/0x150 [ 3.362175 ] ? free_irq+0x100/0x480 [ 3.362175 ] __warn+0x108/0x150 [ 3.362175 ] ? free_irq+0x100/0x480 [ 3.362175 ] report_bug+0x119/0x1c0 [ 3.362175 ] handle_bug+0x3b/0x80 [ 3.362175 ] exc_invalid_op+0x18/0x70 [ 3.362175 ] asm_exc_invalid_op+0x12/0x20 [ 3.362175 ] RIP: 0010:free_irq+0x100 ---truncated---(CVE-2021-47284)
In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to avoid racing on fsync_entry_slab by multi filesystem instances
As syzbot reported, there is an use-after-free issue during f2fs recovery:
Use-after-free write at 0xffff88823bc16040 (in kfence-#10): kmem_cache_destroy+0x1f/0x120 mm/slab_common.c:486 f2fs_recover_fsync_data+0x75b0/0x8380 fs/f2fs/recovery.c:869 f2fs_fill_super+0x9393/0xa420 fs/f2fs/super.c:3945 mount_bdev+0x26c/0x3a0 fs/super.c:1367 legacy_get_tree+0xea/0x180 fs/fs_context.c:592 vfs_get_tree+0x86/0x270 fs/super.c:1497 do_new_mount fs/namespace.c:2905 [inline] path_mount+0x196f/0x2be0 fs/namespace.c:3235 do_mount fs/namespace.c:3248 [inline] __do_sys_mount fs/namespace.c:3456 [inline] __se_sys_mount+0x2f9/0x3b0 fs/namespace.c:3433 do_syscall_64+0x3f/0xb0 arch/x86/entry/common.c:47 entry_SYSCALL_64_after_hwframe+0x44/0xae
The root cause is multi f2fs filesystem instances can race on accessing global fsync_entry_slab pointer, result in use-after-free issue of slab cache, fixes to init/destroy this slab cache only once during module init/destroy procedure to avoid this issue.(CVE-2021-47335)
In the Linux kernel, the following vulnerability has been resolved:
hwmon: (mlxreg-fan) Return non-zero value when fan current state is enforced from sysfs
Fan speed minimum can be enforced from sysfs. For example, setting current fan speed to 20 is used to enforce fan speed to be at 100% speed, 19 - to be not below 90% speed, etcetera. This feature provides ability to limit fan speed according to some system wise considerations, like absence of some replaceable units or high system ambient temperature.
Request for changing fan minimum speed is configuration request and can be set only through 'sysfs' write procedure. In this situation value of argument 'state' is above nominal fan speed maximum.
Return non-zero code in this case to avoid thermal_cooling_device_stats_update() call, because in this case statistics update violates thermal statistics table range. The issues is observed in case kernel is configured with option CONFIG_THERMAL_STATISTICS.
Here is the trace from KASAN: [ 159.506659] BUG: KASAN: slab-out-of-bounds in thermal_cooling_device_stats_update+0x7d/0xb0 [ 159.516016] Read of size 4 at addr ffff888116163840 by task hw-management.s/7444 [ 159.545625] Call Trace: [ 159.548366] dump_stack+0x92/0xc1 [ 159.552084] ? thermal_cooling_device_stats_update+0x7d/0xb0 [ 159.635869] thermal_zone_device_update+0x345/0x780 [ 159.688711] thermal_zone_device_set_mode+0x7d/0xc0 [ 159.694174] mlxsw_thermal_modules_init+0x48f/0x590 [mlxsw_core] [ 159.700972] ? mlxsw_thermal_set_cur_state+0x5a0/0x5a0 [mlxsw_core] [ 159.731827] mlxsw_thermal_init+0x763/0x880 [mlxsw_core] [ 160.070233] RIP: 0033:0x7fd995909970 [ 160.074239] Code: 73 01 c3 48 8b 0d 28 d5 2b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d 99 2d 2c 00 00 75 10 b8 01 00 00 00 0f 05 <48> 3d 01 f0 ff .. [ 160.095242] RSP: 002b:00007fff54f5d938 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ 160.103722] RAX: ffffffffffffffda RBX: 0000000000000013 RCX: 00007fd995909970 [ 160.111710] RDX: 0000000000000013 RSI: 0000000001906008 RDI: 0000000000000001 [ 160.119699] RBP: 0000000001906008 R08: 00007fd995bc9760 R09: 00007fd996210700 [ 160.127687] R10: 0000000000000073 R11: 0000000000000246 R12: 0000000000000013 [ 160.135673] R13: 0000000000000001 R14: 00007fd995bc8600 R15: 0000000000000013 [ 160.143671] [ 160.145338] Allocated by task 2924: [ 160.149242] kasan_save_stack+0x19/0x40 [ 160.153541] __kasan_kmalloc+0x7f/0xa0 [ 160.157743] __kmalloc+0x1a2/0x2b0 [ 160.161552] thermal_cooling_device_setup_sysfs+0xf9/0x1a0 [ 160.167687] __thermal_cooling_device_register+0x1b5/0x500 [ 160.173833] devm_thermal_of_cooling_device_register+0x60/0xa0 [ 160.180356] mlxreg_fan_probe+0x474/0x5e0 [mlxreg_fan] [ 160.248140] [ 160.249807] The buggy address belongs to the object at ffff888116163400 [ 160.249807] which belongs to the cache kmalloc-1k of size 1024 [ 160.263814] The buggy address is located 64 bytes to the right of [ 160.263814] 1024-byte region [ffff888116163400, ffff888116163800) [ 160.277536] The buggy address belongs to the page: [ 160.282898] page:0000000012275840 refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888116167000 pfn:0x116160 [ 160.294872] head:0000000012275840 order:3 compound_mapcount:0 compound_pincount:0 [ 160.303251] flags: 0x200000000010200(slab|head|node=0|zone=2) [ 160.309694] raw: 0200000000010200 ffffea00046f7208 ffffea0004928208 ffff88810004dbc0 [ 160.318367] raw: ffff888116167000 00000000000a0006 00000001ffffffff 0000000000000000 [ 160.327033] page dumped because: kasan: bad access detected [ 160.333270] [ 160.334937] Memory state around the buggy address: [ 160.356469] >ffff888116163800: fc ..(CVE-2021-47393)
In the Linux kernel, the following vulnerability has been resolved:
ptp: Fix possible memory leak in ptp_clock_register()
I got memory leak as follows when doing fault injection test:
unreferenced object 0xffff88800906c618 (size 8): comm "i2c-idt82p33931", pid 4421, jiffies 4294948083 (age 13.188s) hex dump (first 8 bytes): 70 74 70 30 00 00 00 00 ptp0.... backtrace: [<00000000312ed458>] __kmalloc_track_caller+0x19f/0x3a0 [<0000000079f6e2ff>] kvasprintf+0xb5/0x150 [<0000000026aae54f>] kvasprintf_const+0x60/0x190 [<00000000f323a5f7>] kobject_set_name_vargs+0x56/0x150 [<000000004e35abdd>] dev_set_name+0xc0/0x100 [<00000000f20cfe25>] ptp_clock_register+0x9f4/0xd30 [ptp] [<000000008bb9f0de>] idt82p33_probe.cold+0x8b6/0x1561 [ptp_idt82p33]
When posix_clock_register() returns an error, the name allocated in dev_set_name() will be leaked, the put_device() should be used to give up the device reference, then the name will be freed in kobject_cleanup() and other memory will be freed in ptp_clock_release().(CVE-2021-47455)
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Fix a memory leak in an error path of qla2x00_process_els()
Commit 8c0eb596baa5 ("[SCSI] qla2xxx: Fix a memory leak in an error path of qla2x00_process_els()"), intended to change:
bsg_job->request->msgcode == FC_BSG_HST_ELS_NOLOGIN
bsg_job->request->msgcode != FC_BSG_RPT_ELS
but changed it to:
bsg_job->request->msgcode == FC_BSG_RPT_ELS
instead.
Change the == to a != to avoid leaking the fcport structure or freeing unallocated memory.(CVE-2021-47473)
In the Linux kernel, the following vulnerability has been resolved:
nvmem: Fix shift-out-of-bound (UBSAN) with byte size cells
If a cell has 'nbits' equal to a multiple of BITS_PER_BYTE the logic
*p &= GENMASK((cell->nbits%BITS_PER_BYTE) - 1, 0);
will become undefined behavior because nbits modulo BITS_PER_BYTE is 0, and we subtract one from that making a large number that is then shifted more than the number of bits that fit into an unsigned long.
UBSAN reports this problem:
UBSAN: shift-out-of-bounds in drivers/nvmem/core.c:1386:8 shift exponent 64 is too large for 64-bit type 'unsigned long' CPU: 6 PID: 7 Comm: kworker/u16:0 Not tainted 5.15.0-rc3+ #9 Hardware name: Google Lazor (rev3+) with KB Backlight (DT) Workqueue: events_unbound deferred_probe_work_func Call trace: dump_backtrace+0x0/0x170 show_stack+0x24/0x30 dump_stack_lvl+0x64/0x7c dump_stack+0x18/0x38 ubsan_epilogue+0x10/0x54 __ubsan_handle_shift_out_of_bounds+0x180/0x194 __nvmem_cell_read+0x1ec/0x21c nvmem_cell_read+0x58/0x94 nvmem_cell_read_variable_common+0x4c/0xb0 nvmem_cell_read_variable_le_u32+0x40/0x100 a6xx_gpu_init+0x170/0x2f4 adreno_bind+0x174/0x284 component_bind_all+0xf0/0x264 msm_drm_bind+0x1d8/0x7a0 try_to_bring_up_master+0x164/0x1ac __component_add+0xbc/0x13c component_add+0x20/0x2c dp_display_probe+0x340/0x384 platform_probe+0xc0/0x100 really_probe+0x110/0x304 __driver_probe_device+0xb8/0x120 driver_probe_device+0x4c/0xfc __device_attach_driver+0xb0/0x128 bus_for_each_drv+0x90/0xdc __device_attach+0xc8/0x174 device_initial_probe+0x20/0x2c bus_probe_device+0x40/0xa4 deferred_probe_work_func+0x7c/0xb8 process_one_work+0x128/0x21c process_scheduled_works+0x40/0x54 worker_thread+0x1ec/0x2a8 kthread+0x138/0x158 ret_from_fork+0x10/0x20
Fix it by making sure there are any bits to mask out.(CVE-2021-47497)
In the Linux kernel, the following vulnerability has been resolved:
scsi: mpt3sas: Fix use-after-free warning
Fix the following use-after-free warning which is observed during controller reset:
refcount_t: underflow; use-after-free. WARNING: CPU: 23 PID: 5399 at lib/refcount.c:28 refcount_warn_saturate+0xa6/0xf0(CVE-2022-48695)
In the Linux kernel, the following vulnerability has been resolved:
nvmet: fix a use-after-free
Fix the following use-after-free complaint triggered by blktests nvme/004:
BUG: KASAN: user-memory-access in blk_mq_complete_request_remote+0xac/0x350 Read of size 4 at addr 0000607bd1835943 by task kworker/13:1/460 Workqueue: nvmet-wq nvme_loop_execute_work [nvme_loop] Call Trace: show_stack+0x52/0x58 dump_stack_lvl+0x49/0x5e print_report.cold+0x36/0x1e2 kasan_report+0xb9/0xf0 __asan_load4+0x6b/0x80 blk_mq_complete_request_remote+0xac/0x350 nvme_loop_queue_response+0x1df/0x275 [nvme_loop] __nvmet_req_complete+0x132/0x4f0 [nvmet] nvmet_req_complete+0x15/0x40 [nvmet] nvmet_execute_io_connect+0x18a/0x1f0 [nvmet] nvme_loop_execute_work+0x20/0x30 [nvme_loop] process_one_work+0x56e/0xa70 worker_thread+0x2d1/0x640 kthread+0x183/0x1c0 ret_from_fork+0x1f/0x30(CVE-2022-48697)
In the Linux kernel, the following vulnerability has been resolved:
ALSA: emu10k1: Fix out of bounds access in snd_emu10k1_pcm_channel_alloc()
The voice allocator sometimes begins allocating from near the end of the array and then wraps around, however snd_emu10k1_pcm_channel_alloc() accesses the newly allocated voices as if it never wrapped around.
This results in out of bounds access if the first voice has a high enough index so that first_voice + requested_voice_count > NUM_G (64). The more voices are requested, the more likely it is for this to occur.
This was initially discovered using PipeWire, however it can be reproduced by calling aplay multiple times with 16 channels: aplay -r 48000 -D plughw:CARD=Live,DEV=3 -c 16 /dev/zero
UBSAN: array-index-out-of-bounds in sound/pci/emu10k1/emupcm.c:127:40 index 65 is out of range for type 'snd_emu10k1_voice [64]' CPU: 1 PID: 31977 Comm: aplay Tainted: G W IOE 6.0.0-rc2-emu10k1+ #7 Hardware name: ASUSTEK COMPUTER INC P5W DH Deluxe/P5W DH Deluxe, BIOS 3002 07/22/2010 Call Trace: <TASK> dump_stack_lvl+0x49/0x63 dump_stack+0x10/0x16 ubsan_epilogue+0x9/0x3f __ubsan_handle_out_of_bounds.cold+0x44/0x49 snd_emu10k1_playback_hw_params+0x3bc/0x420 [snd_emu10k1] snd_pcm_hw_params+0x29f/0x600 [snd_pcm] snd_pcm_common_ioctl+0x188/0x1410 [snd_pcm] ? exit_to_user_mode_prepare+0x35/0x170 ? do_syscall_64+0x69/0x90 ? syscall_exit_to_user_mode+0x26/0x50 ? do_syscall_64+0x69/0x90 ? exit_to_user_mode_prepare+0x35/0x170 snd_pcm_ioctl+0x27/0x40 [snd_pcm] __x64_sys_ioctl+0x95/0xd0 do_syscall_64+0x5c/0x90 ? do_syscall_64+0x69/0x90 ? do_syscall_64+0x69/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd(CVE-2022-48702)
In the Linux kernel, the following vulnerability has been resolved:
drm/radeon: add a force flush to delay work when radeon
Although radeon card fence and wait for gpu to finish processing current batch rings, there is still a corner case that radeon lockup work queue may not be fully flushed, and meanwhile the radeon_suspend_kms() function has called pci_set_power_state() to put device in D3hot state. Per PCI spec rev 4.0 on 5.3.1.4.1 D3hot State. > Configuration and Message requests are the only TLPs accepted by a Function in > the D3hot state. All other received Requests must be handled as Unsupported Requests, > and all received Completions may optionally be handled as Unexpected Completions. This issue will happen in following logs: Unable to handle kernel paging request at virtual address 00008800e0008010 CPU 0 kworker/0:3(131): Oops 0 pc = [<ffffffff811bea5c>] ra = [<ffffffff81240844>] ps = 0000 Tainted: G W pc is at si_gpu_check_soft_reset+0x3c/0x240 ra is at si_dma_is_lockup+0x34/0xd0 v0 = 0000000000000000 t0 = fff08800e0008010 t1 = 0000000000010000 t2 = 0000000000008010 t3 = fff00007e3c00000 t4 = fff00007e3c00258 t5 = 000000000000ffff t6 = 0000000000000001 t7 = fff00007ef078000 s0 = fff00007e3c016e8 s1 = fff00007e3c00000 s2 = fff00007e3c00018 s3 = fff00007e3c00000 s4 = fff00007fff59d80 s5 = 0000000000000000 s6 = fff00007ef07bd98 a0 = fff00007e3c00000 a1 = fff00007e3c016e8 a2 = 0000000000000008 a3 = 0000000000000001 a4 = 8f5c28f5c28f5c29 a5 = ffffffff810f4338 t8 = 0000000000000275 t9 = ffffffff809b66f8 t10 = ff6769c5d964b800 t11= 000000000000b886 pv = ffffffff811bea20 at = 0000000000000000 gp = ffffffff81d89690 sp = 00000000aa814126 Disabling lock debugging due to kernel taint Trace: [<ffffffff81240844>] si_dma_is_lockup+0x34/0xd0 [<ffffffff81119610>] radeon_fence_check_lockup+0xd0/0x290 [<ffffffff80977010>] process_one_work+0x280/0x550 [<ffffffff80977350>] worker_thread+0x70/0x7c0 [<ffffffff80977410>] worker_thread+0x130/0x7c0 [<ffffffff80982040>] kthread+0x200/0x210 [<ffffffff809772e0>] worker_thread+0x0/0x7c0 [<ffffffff80981f8c>] kthread+0x14c/0x210 [<ffffffff80911658>] ret_from_kernel_thread+0x18/0x20 [<ffffffff80981e40>] kthread+0x0/0x210 Code: ad3e0008 43f0074a ad7e0018 ad9e0020 8c3001e8 40230101 <88210000> 4821ed21 So force lockup work queue flush to fix this problem.(CVE-2022-48704)
In the Linux kernel, the following vulnerability has been resolved:
drm/radeon: fix a possible null pointer dereference
In radeon_fp_native_mode(), the return value of drm_mode_duplicate() is assigned to mode, which will lead to a NULL pointer dereference on failure of drm_mode_duplicate(). Add a check to avoid npd.
The failure status of drm_cvt_mode() on the other path is checked too.(CVE-2022-48710)
In the Linux kernel, the following vulnerability has been resolved:
drm/tegra: dsi: Add missing check for of_find_device_by_node
Add check for the return value of of_find_device_by_node() and return the error if it fails in order to avoid NULL pointer dereference.(CVE-2023-52650)
In the Linux kernel, the following vulnerability has been resolved:
NTB: fix possible name leak in ntb_register_device()
If device_register() fails in ntb_register_device(), the device name allocated by dev_set_name() should be freed. As per the comment in device_register(), callers should use put_device() to give up the reference in the error path. So fix this by calling put_device() in the error path so that the name can be freed in kobject_cleanup().
As a result of this, put_device() in the error path of ntb_register_device() is removed and the actual error is returned.
In the Linux kernel, the following vulnerability has been resolved:
SUNRPC: fix a memleak in gss_import_v2_context
The ctx->mech_used.data allocated by kmemdup is not freed in neither gss_import_v2_context nor it only caller gss_krb5_import_sec_context, which frees ctx on error.
Thus, this patch reform the last call of gss_import_v2_context to the gss_krb5_import_ctx_v2, preventing the memleak while keepping the return formation.(CVE-2023-52653)
In the Linux kernel, the following vulnerability has been resolved:
io_uring: drop any code related to SCM_RIGHTS
This is dead code after we dropped support for passing io_uring fds over SCM_RIGHTS, get rid of it.(CVE-2023-52656)
In the Linux kernel, the following vulnerability has been resolved:
ACPI: LPIT: Avoid u32 multiplication overflow
In lpit_update_residency() there is a possibility of overflow in multiplication, if tsc_khz is large enough (> UINT_MAX/1000).
Change multiplication to mul_u32_u32().
Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2023-52683)
In the Linux kernel, the following vulnerability has been resolved:
pstore: ram_core: fix possible overflow in persistent_ram_init_ecc()
In persistent_ram_init_ecc(), on 64-bit arches DIV_ROUND_UP() will return 64-bit value since persistent_ram_zone::buffer_size has type size_t which is derived from the 64-bit unsigned long, while the ecc_blocks variable this value gets assigned to has (always 32-bit) int type. Even if that value fits into int type, an overflow is still possible when calculating the size_t typed ecc_total variable further below since there's no cast to any 64-bit type before multiplication. Declaring the ecc_blocks variable as size_t should fix this mess...
Found by Linux Verification Center (linuxtesting.org) with the SVACE static analysis tool.(CVE-2023-52685)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/pm: fix a double-free in si_dpm_init
When the allocation of adev->pm.dpm.dyn_state.vddc_dependency_on_dispclk.entries fails, amdgpu_free_extended_power_table is called to free some fields of adev. However, when the control flow returns to si_dpm_sw_init, it goes to label dpm_failed and calls si_dpm_fini, which calls amdgpu_free_extended_power_table again and free those fields again. Thus a double-free is triggered.(CVE-2023-52691)
In the Linux kernel, the following vulnerability has been resolved:
calipso: fix memory leak in netlbl_calipso_add_pass()
If IPv6 support is disabled at boot (ipv6.disable=1), the calipso_init() -> netlbl_calipso_ops_register() function isn't called, and the netlbl_calipso_ops_get() function always returns NULL. In this case, the netlbl_calipso_add_pass() function allocates memory for the doi_def variable but doesn't free it with the calipso_doi_free().
BUG: memory leak unreferenced object 0xffff888011d68180 (size 64): comm "syz-executor.1", pid 10746, jiffies 4295410986 (age 17.928s) hex dump (first 32 bytes): 00 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<...>] kmalloc include/linux/slab.h:552 [inline] [<...>] netlbl_calipso_add_pass net/netlabel/netlabel_calipso.c:76 [inline] [<...>] netlbl_calipso_add+0x22e/0x4f0 net/netlabel/netlabel_calipso.c:111 [<...>] genl_family_rcv_msg_doit+0x22f/0x330 net/netlink/genetlink.c:739 [<...>] genl_family_rcv_msg net/netlink/genetlink.c:783 [inline] [<...>] genl_rcv_msg+0x341/0x5a0 net/netlink/genetlink.c:800 [<...>] netlink_rcv_skb+0x14d/0x440 net/netlink/af_netlink.c:2515 [<...>] genl_rcv+0x29/0x40 net/netlink/genetlink.c:811 [<...>] netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline] [<...>] netlink_unicast+0x54b/0x800 net/netlink/af_netlink.c:1339 [<...>] netlink_sendmsg+0x90a/0xdf0 net/netlink/af_netlink.c:1934 [<...>] sock_sendmsg_nosec net/socket.c:651 [inline] [<...>] sock_sendmsg+0x157/0x190 net/socket.c:671 [<...>] _syssendmsg+0x712/0x870 net/socket.c:2342 [<...>] _sys_sendmsg+0xf8/0x170 net/socket.c:2396 [<...>] __sys_sendmsg+0xea/0x1b0 net/socket.c:2429 [<...>] do_syscall_64+0x30/0x40 arch/x86/entry/common.c:46 [<...>] entry_SYSCALL_64_after_hwframe+0x61/0xc6
Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with Syzkaller
PM: merged via the LSM tree at Jakub Kicinski request
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Fix a null pointer access when the smc_rreg pointer is NULL
In certain types of chips, such as VEGA20, reading the amdgpu_regs_smc file could result in an abnormal null pointer access when the smc_rreg pointer is NULL. Below are the steps to reproduce this issue and the corresponding exception log:
- Navigate to the directory: /sys/kernel/debug/dri/0
- Execute command: cat amdgpu_regs_smc
- Exception Log:: [4005007.702554] BUG: kernel NULL pointer dereference, address: 0000000000000000 [4005007.702562] #PF: supervisor instruction fetch in kernel mode [4005007.702567] #PF: error_code(0x0010) - not-present page [4005007.702570] PGD 0 P4D 0 [4005007.702576] Oops: 0010 [#1] SMP NOPTI [4005007.702581] CPU: 4 PID: 62563 Comm: cat Tainted: G OE 5.15.0-43-generic #46-Ubunt u [4005007.702590] RIP: 0010:0x0 [4005007.702598] Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6. [4005007.702600] RSP: 0018:ffffa82b46d27da0 EFLAGS: 00010206 [4005007.702605] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffa82b46d27e68 [4005007.702609] RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff9940656e0000 [4005007.702612] RBP: ffffa82b46d27dd8 R08: 0000000000000000 R09: ffff994060c07980 [4005007.702615] R10: 0000000000020000 R11: 0000000000000000 R12: 00007f5e06753000 [4005007.702618] R13: ffff9940656e0000 R14: ffffa82b46d27e68 R15: 00007f5e06753000 [4005007.702622] FS: 00007f5e0755b740(0000) GS:ffff99479d300000(0000) knlGS:0000000000000000 [4005007.702626] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [4005007.702629] CR2: ffffffffffffffd6 CR3: 00000003253fc000 CR4: 00000000003506e0 [4005007.702633] Call Trace: [4005007.702636] <TASK> [4005007.702640] amdgpu_debugfs_regs_smc_read+0xb0/0x120 [amdgpu] [4005007.703002] full_proxy_read+0x5c/0x80 [4005007.703011] vfs_read+0x9f/0x1a0 [4005007.703019] ksys_read+0x67/0xe0 [4005007.703023] __x64_sys_read+0x19/0x20 [4005007.703028] do_syscall_64+0x5c/0xc0 [4005007.703034] ? do_user_addr_fault+0x1e3/0x670 [4005007.703040] ? exit_to_user_mode_prepare+0x37/0xb0 [4005007.703047] ? irqentry_exit_to_user_mode+0x9/0x20 [4005007.703052] ? irqentry_exit+0x19/0x30 [4005007.703057] ? exc_page_fault+0x89/0x160 [4005007.703062] ? asm_exc_page_fault+0x8/0x30 [4005007.703068] entry_SYSCALL_64_after_hwframe+0x44/0xae [4005007.703075] RIP: 0033:0x7f5e07672992 [4005007.703079] Code: c0 e9 b2 fe ff ff 50 48 8d 3d fa b2 0c 00 e8 c5 1d 02 00 0f 1f 44 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 0f 05 <48> 3d 00 f0 ff ff 77 56 c3 0f 1f 44 00 00 48 83 e c 28 48 89 54 24 [4005007.703083] RSP: 002b:00007ffe03097898 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 [4005007.703088] RAX: ffffffffffffffda RBX: 0000000000020000 RCX: 00007f5e07672992 [4005007.703091] RDX: 0000000000020000 RSI: 00007f5e06753000 RDI: 0000000000000003 [4005007.703094] RBP: 00007f5e06753000 R08: 00007f5e06752010 R09: 00007f5e06752010 [4005007.703096] R10: 0000000000000022 R11: 0000000000000246 R12: 0000000000022000 [4005007.703099] R13: 0000000000000003 R14: 0000000000020000 R15: 0000000000020000 [4005007.703105] </TASK> [4005007.703107] Modules linked in: nf_tables libcrc32c nfnetlink algif_hash af_alg binfmt_misc nls_ iso8859_1 ipmi_ssif ast intel_rapl_msr intel_rapl_common drm_vram_helper drm_ttm_helper amd64_edac t tm edac_mce_amd kvm_amd ccp mac_hid k10temp kvm acpi_ipmi ipmi_si rapl sch_fq_codel ipmi_devintf ipm i_msghandler msr parport_pc ppdev lp parport mtd pstore_blk efi_pstore ramoops pstore_zone reed_solo mon ip_tables x_tables autofs4 ib_uverbs ib_core amdgpu(OE) amddrm_ttm_helper(OE) amdttm(OE) iommu_v 2 amd_sched(OE) amdkcl(OE) drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops cec rc_core drm igb ahci xhci_pci libahci i2c_piix4 i2c_algo_bit xhci_pci_renesas dca [4005007.703184] CR2: 0000000000000000 [4005007.703188] ---[ en ---truncated---(CVE-2023-52817)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd: Fix UBSAN array-index-out-of-bounds for SMU7
For pptable structs that use flexible array sizes, use flexible arrays.(CVE-2023-52818)
In the Linux kernel, the following vulnerability has been resolved:
perf/core: Bail out early if the request AUX area is out of bound
When perf-record with a large AUX area, e.g 4GB, it fails with:
#perf record -C 0 -m ,4G -e arm_spe_0// -- sleep 1
failed to mmap with 12 (Cannot allocate memory)
and it reveals a WARNING with __alloc_pages():
------------[ cut here ]------------
WARNING: CPU: 44 PID: 17573 at mm/page_alloc.c:5568 __alloc_pages+0x1ec/0x248
Call trace:
__alloc_pages+0x1ec/0x248
__kmalloc_large_node+0xc0/0x1f8
__kmalloc_node+0x134/0x1e8
rb_alloc_aux+0xe0/0x298
perf_mmap+0x440/0x660
mmap_region+0x308/0x8a8
do_mmap+0x3c0/0x528
vm_mmap_pgoff+0xf4/0x1b8
ksys_mmap_pgoff+0x18c/0x218
__arm64_sys_mmap+0x38/0x58
invoke_syscall+0x50/0x128
el0_svc_common.constprop.0+0x58/0x188
do_el0_svc+0x34/0x50
el0_svc+0x34/0x108
el0t_64_sync_handler+0xb8/0xc0
el0t_64_sync+0x1a4/0x1a8
'rb->aux_pages' allocated by kcalloc() is a pointer array which is used to maintains AUX trace pages. The allocated page for this array is physically contiguous (and virtually contiguous) with an order of 0..MAX_ORDER. If the size of pointer array crosses the limitation set by MAX_ORDER, it reveals a WARNING.
So bail out early with -ENOMEM if the request AUX area is out of bound, e.g.:
#perf record -C 0 -m ,4G -e arm_spe_0// -- sleep 1
failed to mmap with 12 (Cannot allocate memory)(CVE-2023-52835)
In the Linux kernel, the following vulnerability has been resolved:
Input: synaptics-rmi4 - fix use after free in rmi_unregister_function()
The put_device() calls rmi_release_function() which frees "fn" so the dereference on the next line "fn->num_of_irqs" is a use after free. Move the put_device() to the end to fix this.(CVE-2023-52840)
In the Linux kernel, the following vulnerability has been resolved:
media: bttv: fix use after free error due to btv->timeout timer
There may be some a race condition between timer function bttv_irq_timeout and bttv_remove. The timer is setup in probe and there is no timer_delete operation in remove function. When it hit kfree btv, the function might still be invoked, which will cause use after free bug.
This bug is found by static analysis, it may be false positive.
Fix it by adding del_timer_sync invoking to the remove function.
cpu0 cpu1 bttv_probe ->timer_setup ->bttv_set_dma ->mod_timer; bttv_remove ->kfree(btv); ->bttv_irq_timeout ->USE btv(CVE-2023-52847)
In the Linux kernel, the following vulnerability has been resolved:
drm/radeon: possible buffer overflow
Buffer 'afmt_status' of size 6 could overflow, since index 'afmt_idx' is checked after access.(CVE-2023-52867)
In the Linux kernel, the following vulnerability has been resolved:
thermal: core: prevent potential string overflow
The dev->id value comes from ida_alloc() so it's a number between zero and INT_MAX. If it's too high then these sprintf()s will overflow.(CVE-2023-52868)
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: prevent kernel bug at submit_bh_wbc()
Fix a bug where nilfs_get_block() returns a successful status when searching and inserting the specified block both fail inconsistently. If this inconsistent behavior is not due to a previously fixed bug, then an unexpected race is occurring, so return a temporary error -EAGAIN instead.
This prevents callers such as __block_write_begin_int() from requesting a read into a buffer that is not mapped, which would cause the BUG_ON check for the BH_Mapped flag in submit_bh_wbc() to fail.(CVE-2024-26955)
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix failure to detect DAT corruption in btree and direct mappings
Patch series "nilfs2: fix kernel bug at submit_bh_wbc()".
This resolves a kernel BUG reported by syzbot. Since there are two flaws involved, I've made each one a separate patch.
The first patch alone resolves the syzbot-reported bug, but I think both fixes should be sent to stable, so I've tagged them as such.
This patch (of 2):
Syzbot has reported a kernel bug in submit_bh_wbc() when writing file data to a nilfs2 file system whose metadata is corrupted.
There are two flaws involved in this issue.
The first flaw is that when nilfs_get_block() locates a data block using btree or direct mapping, if the disk address translation routine nilfs_dat_translate() fails with internal code -ENOENT due to DAT metadata corruption, it can be passed back to nilfs_get_block(). This causes nilfs_get_block() to misidentify an existing block as non-existent, causing both data block lookup and insertion to fail inconsistently.
The second flaw is that nilfs_get_block() returns a successful status in this inconsistent state. This causes the caller __block_write_begin_int() or others to request a read even though the buffer is not mapped, resulting in a BUG_ON check for the BH_Mapped flag in submit_bh_wbc() failing.
This fixes the first issue by changing the return value to code -EINVAL when a conversion using DAT fails with code -ENOENT, avoiding the conflicting condition that leads to the kernel bug described above. Here, code -EINVAL indicates that metadata corruption was detected during the block lookup, which will be properly handled as a file system error and converted to -EIO when passing through the nilfs2 bmap layer.(CVE-2024-26956)
In the Linux kernel, the following vulnerability has been resolved:
s390/zcrypt: fix reference counting on zcrypt card objects
Tests with hot-plugging crytpo cards on KVM guests with debug kernel build revealed an use after free for the load field of the struct zcrypt_card. The reason was an incorrect reference handling of the zcrypt card object which could lead to a free of the zcrypt card object while it was still in use.
This is an example of the slab message:
kernel: 0x00000000885a7512-0x00000000885a7513 @offset=1298. First byte 0x68 instead of 0x6b
kernel: Allocated in zcrypt_card_alloc+0x36/0x70 [zcrypt] age=18046 cpu=3 pid=43
kernel: kmalloc_trace+0x3f2/0x470
kernel: zcrypt_card_alloc+0x36/0x70 [zcrypt]
kernel: zcrypt_cex4_card_probe+0x26/0x380 [zcrypt_cex4]
kernel: ap_device_probe+0x15c/0x290
kernel: really_probe+0xd2/0x468
kernel: driver_probe_device+0x40/0xf0
kernel: __device_attach_driver+0xc0/0x140
kernel: bus_for_each_drv+0x8c/0xd0
kernel: __device_attach+0x114/0x198
kernel: bus_probe_device+0xb4/0xc8
kernel: device_add+0x4d2/0x6e0
kernel: ap_scan_adapter+0x3d0/0x7c0
kernel: ap_scan_bus+0x5a/0x3b0
kernel: ap_scan_bus_wq_callback+0x40/0x60
kernel: process_one_work+0x26e/0x620
kernel: worker_thread+0x21c/0x440
kernel: Freed in zcrypt_card_put+0x54/0x80 [zcrypt] age=9024 cpu=3 pid=43
kernel: kfree+0x37e/0x418
kernel: zcrypt_card_put+0x54/0x80 [zcrypt]
kernel: ap_device_remove+0x4c/0xe0
kernel: device_release_driver_internal+0x1c4/0x270
kernel: bus_remove_device+0x100/0x188
kernel: device_del+0x164/0x3c0
kernel: device_unregister+0x30/0x90
kernel: ap_scan_adapter+0xc8/0x7c0
kernel: ap_scan_bus+0x5a/0x3b0
kernel: ap_scan_bus_wq_callback+0x40/0x60
kernel: process_one_work+0x26e/0x620
kernel: worker_thread+0x21c/0x440
kernel: kthread+0x150/0x168
kernel: __ret_from_fork+0x3c/0x58
kernel: ret_from_fork+0xa/0x30
kernel: Slab 0x00000372022169c0 objects=20 used=18 fp=0x00000000885a7c88 flags=0x3ffff00000000a00(workingset|slab|node=0|zone=1|lastcpupid=0x1ffff)
kernel: Object 0x00000000885a74b8 @offset=1208 fp=0x00000000885a7c88
kernel: Redzone 00000000885a74b0: bb bb bb bb bb bb bb bb ........
kernel: Object 00000000885a74b8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
kernel: Object 00000000885a74c8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
kernel: Object 00000000885a74d8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
kernel: Object 00000000885a74e8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
kernel: Object 00000000885a74f8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
kernel: Object 00000000885a7508: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 68 4b 6b 6b 6b a5 kkkkkkkkkkhKkkk.
kernel: Redzone 00000000885a7518: bb bb bb bb bb bb bb bb ........
kernel: Padding 00000000885a756c: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZ
kernel: CPU: 0 PID: 387 Comm: systemd-udevd Not tainted 6.8.0-HF #2
kernel: Hardware name: IBM 3931 A01 704 (KVM/Linux)
kernel: Call Trace:
kernel: [<00000000ca5ab5b8>] dump_stack_lvl+0x90/0x120
kernel: [<00000000c99d78bc>] check_bytes_and_report+0x114/0x140
kernel: [<00000000c99d53cc>] check_object+0x334/0x3f8
kernel: [<00000000c99d820c>] alloc_debug_processing+0xc4/0x1f8
kernel: [<00000000c99d852e>] get_partial_node.part.0+0x1ee/0x3e0
kernel: [<00000000c99d94ec>] ___slab_alloc+0xaf4/0x13c8
kernel: [<00000000c99d9e38>] __slab_alloc.constprop.0+0x78/0xb8
kernel: [<00000000c99dc8dc>] __kmalloc+0x434/0x590
kernel: [<00000000c9b4c0ce>] ext4_htree_store_dirent+0x4e/0x1c0
kernel: [<00000000c9b908a2>] htree_dirblock_to_tree+0x17a/0x3f0
kernel:
---truncated---(CVE-2024-26957)
In the Linux kernel, the following vulnerability has been resolved:
nfs: fix UAF in direct writes
In production we have been hitting the following warning consistently
------------[ cut here ]------------ refcount_t: underflow; use-after-free. WARNING: CPU: 17 PID: 1800359 at lib/refcount.c:28 refcount_warn_saturate+0x9c/0xe0 Workqueue: nfsiod nfs_direct_write_schedule_work [nfs] RIP: 0010:refcount_warn_saturate+0x9c/0xe0 PKRU: 55555554 Call Trace: <TASK> ? __warn+0x9f/0x130 ? refcount_warn_saturate+0x9c/0xe0 ? report_bug+0xcc/0x150 ? handle_bug+0x3d/0x70 ? exc_invalid_op+0x16/0x40 ? asm_exc_invalid_op+0x16/0x20 ? refcount_warn_saturate+0x9c/0xe0 nfs_direct_write_schedule_work+0x237/0x250 [nfs] process_one_work+0x12f/0x4a0 worker_thread+0x14e/0x3b0 ? ZSTD_getCParams_internal+0x220/0x220 kthread+0xdc/0x120 ? __btf_name_valid+0xa0/0xa0 ret_from_fork+0x1f/0x30
This is because we're completing the nfs_direct_request twice in a row.
The source of this is when we have our commit requests to submit, we process them and send them off, and then in the completion path for the commit requests we have
if (nfs_commit_end(cinfo.mds)) nfs_direct_write_complete(dreq);
However since we're submitting asynchronous requests we sometimes have one that completes before we submit the next one, so we end up calling complete on the nfs_direct_request twice.
The only other place we use nfs_generic_commit_list() is in __nfs_commit_inode, which wraps this call in a
nfs_commit_begin(); nfs_commit_end();
Which is a common pattern for this style of completion handling, one that is also repeated in the direct code with get_dreq()/put_dreq() calls around where we process events as well as in the completion paths.
Fix this by using the same pattern for the commit requests.
Before with my 200 node rocksdb stress running this warning would pop every 10ish minutes. With my patch the stress test has been running for several hours without popping.(CVE-2024-26958)
In the Linux kernel, the following vulnerability has been resolved:
mm: swap: fix race between free_swap_and_cache() and swapoff()
There was previously a theoretical window where swapoff() could run and teardown a swap_info_struct while a call to free_swap_and_cache() was running in another thread. This could cause, amongst other bad possibilities, swap_page_trans_huge_swapped() (called by free_swap_and_cache()) to access the freed memory for swap_map.
This is a theoretical problem and I haven't been able to provoke it from a test case. But there has been agreement based on code review that this is possible (see link below).
Fix it by using get_swap_device()/put_swap_device(), which will stall swapoff(). There was an extra check in _swap_info_get() to confirm that the swap entry was not free. This isn't present in get_swap_device() because it doesn't make sense in general due to the race between getting the reference and swapoff. So I've added an equivalent check directly in free_swap_and_cache().
Details of how to provoke one possible issue (thanks to David Hildenbrand for deriving this):
--8<-----
__swap_entry_free() might be the last user and result in "count == SWAP_HAS_CACHE".
swapoff->try_to_unuse() will stop as soon as soon as si->inuse_pages==0.
So the question is: could someone reclaim the folio and turn si->inuse_pages==0, before we completed swap_page_trans_huge_swapped().
Imagine the following: 2 MiB folio in the swapcache. Only 2 subpages are still references by swap entries.
Process 1 still references subpage 0 via swap entry. Process 2 still references subpage 1 via swap entry.
Process 1 quits. Calls free_swap_and_cache(). -> count == SWAP_HAS_CACHE [then, preempted in the hypervisor etc.]
Process 2 quits. Calls free_swap_and_cache(). -> count == SWAP_HAS_CACHE
Process 2 goes ahead, passes swap_page_trans_huge_swapped(), and calls __try_to_reclaim_swap().
__try_to_reclaim_swap()->folio_free_swap()->delete_from_swap_cache()-> put_swap_folio()->free_swap_slot()->swapcache_free_entries()-> swap_entry_free()->swap_range_free()-> ... WRITE_ONCE(si->inuse_pages, si->inuse_pages - nr_entries);
What stops swapoff to succeed after process 2 reclaimed the swap cache but before process1 finished its call to swap_page_trans_huge_swapped()?
--8<-----(CVE-2024-26960)
In the Linux kernel, the following vulnerability has been resolved:
mac802154: fix llsec key resources release in mac802154_llsec_key_del
mac802154_llsec_key_del() can free resources of a key directly without following the RCU rules for waiting before the end of a grace period. This may lead to use-after-free in case llsec_lookup_key() is traversing the list of keys in parallel with a key deletion:
refcount_t: addition on 0; use-after-free. WARNING: CPU: 4 PID: 16000 at lib/refcount.c:25 refcount_warn_saturate+0x162/0x2a0 Modules linked in: CPU: 4 PID: 16000 Comm: wpan-ping Not tainted 6.7.0 #19 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 RIP: 0010:refcount_warn_saturate+0x162/0x2a0 Call Trace: <TASK> llsec_lookup_key.isra.0+0x890/0x9e0 mac802154_llsec_encrypt+0x30c/0x9c0 ieee802154_subif_start_xmit+0x24/0x1e0 dev_hard_start_xmit+0x13e/0x690 sch_direct_xmit+0x2ae/0xbc0 __dev_queue_xmit+0x11dd/0x3c20 dgram_sendmsg+0x90b/0xd60 __sys_sendto+0x466/0x4c0 __x64_sys_sendto+0xe0/0x1c0 do_syscall_64+0x45/0xf0 entry_SYSCALL_64_after_hwframe+0x6e/0x76
Also, ieee802154_llsec_key_entry structures are not freed by mac802154_llsec_key_del():
unreferenced object 0xffff8880613b6980 (size 64): comm "iwpan", pid 2176, jiffies 4294761134 (age 60.475s) hex dump (first 32 bytes): 78 0d 8f 18 80 88 ff ff 22 01 00 00 00 00 ad de x......."....... 00 00 00 00 00 00 00 00 03 00 cd ab 00 00 00 00 ................ backtrace: [<ffffffff81dcfa62>] __kmem_cache_alloc_node+0x1e2/0x2d0 [<ffffffff81c43865>] kmalloc_trace+0x25/0xc0 [<ffffffff88968b09>] mac802154_llsec_key_add+0xac9/0xcf0 [<ffffffff8896e41a>] ieee802154_add_llsec_key+0x5a/0x80 [<ffffffff8892adc6>] nl802154_add_llsec_key+0x426/0x5b0 [<ffffffff86ff293e>] genl_family_rcv_msg_doit+0x1fe/0x2f0 [<ffffffff86ff46d1>] genl_rcv_msg+0x531/0x7d0 [<ffffffff86fee7a9>] netlink_rcv_skb+0x169/0x440 [<ffffffff86ff1d88>] genl_rcv+0x28/0x40 [<ffffffff86fec15c>] netlink_unicast+0x53c/0x820 [<ffffffff86fecd8b>] netlink_sendmsg+0x93b/0xe60 [<ffffffff86b91b35>] _syssendmsg+0xac5/0xca0 [<ffffffff86b9c3dd>] _sys_sendmsg+0x11d/0x1c0 [<ffffffff86b9c65a>] __sys_sendmsg+0xfa/0x1d0 [<ffffffff88eadbf5>] do_syscall_64+0x45/0xf0 [<ffffffff890000ea>] entry_SYSCALL_64_after_hwframe+0x6e/0x76
Handle the proper resource release in the RCU callback function mac802154_llsec_key_del_rcu().
Note that if llsec_lookup_key() finds a key, it gets a refcount via llsec_key_get() and locally copies key id from key_entry (which is a list element). So it's safe to call llsec_key_put() and free the list entry after the RCU grace period elapses.
Found by Linux Verification Center (linuxtesting.org).(CVE-2024-26961)
In the Linux kernel, the following vulnerability has been resolved:
clk: qcom: mmcc-msm8974: fix terminating of frequency table arrays
The frequency table arrays are supposed to be terminated with an empty element. Add such entry to the end of the arrays where it is missing in order to avoid possible out-of-bound access when the table is traversed by functions like qcom_find_freq() or qcom_find_freq_floor().
Only compile tested.(CVE-2024-26965)
In the Linux kernel, the following vulnerability has been resolved:
clk: qcom: mmcc-apq8084: fix terminating of frequency table arrays
The frequency table arrays are supposed to be terminated with an empty element. Add such entry to the end of the arrays where it is missing in order to avoid possible out-of-bound access when the table is traversed by functions like qcom_find_freq() or qcom_find_freq_floor().
Only compile tested.(CVE-2024-26966)
In the Linux kernel, the following vulnerability has been resolved:
clk: qcom: gcc-ipq8074: fix terminating of frequency table arrays
The frequency table arrays are supposed to be terminated with an empty element. Add such entry to the end of the arrays where it is missing in order to avoid possible out-of-bound access when the table is traversed by functions like qcom_find_freq() or qcom_find_freq_floor().
Only compile tested.(CVE-2024-26969)
In the Linux kernel, the following vulnerability has been resolved:
crypto: qat - resolve race condition during AER recovery
During the PCI AER system's error recovery process, the kernel driver may encounter a race condition with freeing the reset_data structure's memory. If the device restart will take more than 10 seconds the function scheduling that restart will exit due to a timeout, and the reset_data structure will be freed. However, this data structure is used for completion notification after the restart is completed, which leads to a UAF bug.
This results in a KFENCE bug notice.
BUG: KFENCE: use-after-free read in adf_device_reset_worker+0x38/0xa0 [intel_qat] Use-after-free read at 0x00000000bc56fddf (in kfence-#142): adf_device_reset_worker+0x38/0xa0 [intel_qat] process_one_work+0x173/0x340
To resolve this race condition, the memory associated to the container of the work_struct is freed on the worker if the timeout expired, otherwise on the function that schedules the worker. The timeout detection can be done by checking if the caller is still waiting for completion or not by using completion_done() function.(CVE-2024-26974)
In the Linux kernel, the following vulnerability has been resolved:
KVM: Always flush async #PF workqueue when vCPU is being destroyed
Always flush the per-vCPU async #PF workqueue when a vCPU is clearing its completion queue, e.g. when a VM and all its vCPUs is being destroyed. KVM must ensure that none of its workqueue callbacks is running when the last reference to the KVM module is put. Gifting a reference to the associated VM prevents the workqueue callback from dereferencing freed vCPU/VM memory, but does not prevent the KVM module from being unloaded before the callback completes.
Drop the misguided VM refcount gifting, as calling kvm_put_kvm() from async_pf_execute() if kvm_put_kvm() flushes the async #PF workqueue will result in deadlock. async_pf_execute() can't return until kvm_put_kvm() finishes, and kvm_put_kvm() can't return until async_pf_execute() finishes:
WARNING: CPU: 8 PID: 251 at virt/kvm/kvm_main.c:1435 kvm_put_kvm+0x2d/0x320 [kvm] Modules linked in: vhost_net vhost vhost_iotlb tap kvm_intel kvm irqbypass CPU: 8 PID: 251 Comm: kworker/8:1 Tainted: G W 6.6.0-rc1-e7af8d17224a-x86/gmem-vm #119 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Workqueue: events async_pf_execute [kvm] RIP: 0010:kvm_put_kvm+0x2d/0x320 [kvm] Call Trace: <TASK> async_pf_execute+0x198/0x260 [kvm] process_one_work+0x145/0x2d0 worker_thread+0x27e/0x3a0 kthread+0xba/0xe0 ret_from_fork+0x2d/0x50 ret_from_fork_asm+0x11/0x20 </TASK> ---[ end trace 0000000000000000 ]--- INFO: task kworker/8:1:251 blocked for more than 120 seconds. Tainted: G W 6.6.0-rc1-e7af8d17224a-x86/gmem-vm #119 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/8:1 state:D stack:0 pid:251 ppid:2 flags:0x00004000 Workqueue: events async_pf_execute [kvm] Call Trace: <TASK> __schedule+0x33f/0xa40 schedule+0x53/0xc0 schedule_timeout+0x12a/0x140 __wait_for_common+0x8d/0x1d0 __flush_work.isra.0+0x19f/0x2c0 kvm_clear_async_pf_completion_queue+0x129/0x190 [kvm] kvm_arch_destroy_vm+0x78/0x1b0 [kvm] kvm_put_kvm+0x1c1/0x320 [kvm] async_pf_execute+0x198/0x260 [kvm] process_one_work+0x145/0x2d0 worker_thread+0x27e/0x3a0 kthread+0xba/0xe0 ret_from_fork+0x2d/0x50 ret_from_fork_asm+0x11/0x20 </TASK>
If kvm_clear_async_pf_completion_queue() actually flushes the workqueue, then there's no need to gift async_pf_execute() a reference because all invocations of async_pf_execute() will be forced to complete before the vCPU and its VM are destroyed/freed. And that in turn fixes the module unloading bug as __fput() won't do module_put() on the last vCPU reference until the vCPU has been freed, e.g. if closing the vCPU file also puts the last reference to the KVM module.
Note that kvm_check_async_pf_completion() may also take the work item off the completion queue and so also needs to flush the work queue, as the work will not be seen by kvm_clear_async_pf_completion_queue(). Waiting on the workqueue could theoretically delay a vCPU due to waiting for the work to complete, but that's a very, very small chance, and likely a very small delay. kvm_arch_async_page_present_queued() unconditionally makes a new request, i.e. will effectively delay entering the guest, so the remaining work is really just:
trace_kvm_async_pf_completed(addr, cr2_or_gpa);
__kvm_vcpu_wake_up(vcpu);
mmput(mm);
and mmput() can't drop the last reference to the page tables if the vCPU is still alive, i.e. the vCPU won't get stuck tearing down page tables.
Add a helper to do the flushing, specifically to deal with "wakeup all" work items, as they aren't actually work items, i.e. are never placed in a workqueue. Trying to flush a bogus workqueue entry rightly makes __flush_work() complain (kudos to whoever added that sanity check).
Note, commit 5f6de5cbebee ("KVM: Prevent module exit until al ---truncated---(CVE-2024-26976)
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix OOB in nilfs_set_de_type
The size of the nilfs_type_by_mode array in the fs/nilfs2/dir.c file is defined as "S_IFMT >> S_SHIFT", but the nilfs_set_de_type() function, which uses this array, specifies the index to read from the array in the same way as "(mode & S_IFMT) >> S_SHIFT".
static void nilfs_set_de_type(struct nilfs_dir_entry de, struct inode inode) { umode_t mode = inode->i_mode;
de->file_type = nilfs_type_by_mode[(mode & S_IFMT)>>S_SHIFT]; // oob
}
However, when the index is determined this way, an out-of-bounds (OOB) error occurs by referring to an index that is 1 larger than the array size when the condition "mode & S_IFMT == S_IFMT" is satisfied. Therefore, a patch to resize the nilfs_type_by_mode array should be applied to prevent OOB errors.(CVE-2024-26981)
In the Linux kernel, the following vulnerability has been resolved:
Squashfs: check the inode number is not the invalid value of zero
Syskiller has produced an out of bounds access in fill_meta_index().
That out of bounds access is ultimately caused because the inode has an inode number with the invalid value of zero, which was not checked.
The reason this causes the out of bounds access is due to following sequence of events:
-
Fill_meta_index() is called to allocate (via empty_meta_index()) and fill a metadata index. It however suffers a data read error and aborts, invalidating the newly returned empty metadata index. It does this by setting the inode number of the index to zero, which means unused (zero is not a valid inode number).
-
When fill_meta_index() is subsequently called again on another read operation, locate_meta_index() returns the previous index because it matches the inode number of 0. Because this index has been returned it is expected to have been filled, and because it hasn't been, an out of bounds access is performed.
This patch adds a sanity check which checks that the inode number is not zero when the inode is created and returns -EINVAL if it is.
[phillip@squashfs.org.uk: whitespace fix] Link: https://lkml.kernel.org/r/20240409204723.446925-1-phillip@squashfs.org.uk(CVE-2024-26982)
In the Linux kernel, the following vulnerability has been resolved:
fs: sysfs: Fix reference leak in sysfs_break_active_protection()
The sysfs_break_active_protection() routine has an obvious reference leak in its error path. If the call to kernfs_find_and_get() fails then kn will be NULL, so the companion sysfs_unbreak_active_protection() routine won't get called (and would only cause an access violation by trying to dereference kn->parent if it was called). As a result, the reference to kobj acquired at the start of the function will never be released.
Fix the leak by adding an explicit kobject_put() call when kn is NULL.(CVE-2024-26993)
In the Linux kernel, the following vulnerability has been resolved:
speakup: Avoid crash on very long word
In case a console is set up really large and contains a really long word (> 256 characters), we have to stop before the length of the word buffer.(CVE-2024-26994)
In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: f_ncm: Fix UAF ncm object at re-bind after usb ep transport error
When ncm function is working and then stop usb0 interface for link down, eth_stop() is called. At this piont, accidentally if usb transport error should happen in usb_ep_enable(), 'in_ep' and/or 'out_ep' may not be enabled.
After that, ncm_disable() is called to disable for ncm unbind but gether_disconnect() is never called since 'in_ep' is not enabled.
As the result, ncm object is released in ncm unbind but 'dev->port_usb' associated to 'ncm->port' is not NULL.
And when ncm bind again to recover netdev, ncm object is reallocated but usb0 interface is already associated to previous released ncm object.
Therefore, once usb0 interface is up and eth_start_xmit() is called, released ncm object is dereferrenced and it might cause use-after-free memory.
[function unlink via configfs] usb0: eth_stop dev->port_usb=ffffff9b179c3200 --> error happens in usb_ep_enable(). NCM: ncm_disable: ncm=ffffff9b179c3200 --> no gether_disconnect() since ncm->port.in_ep->enabled is false. NCM: ncm_unbind: ncm unbind ncm=ffffff9b179c3200 NCM: ncm_free: ncm free ncm=ffffff9b179c3200 <-- released ncm
[function link via configfs] NCM: ncm_alloc: ncm alloc ncm=ffffff9ac4f8a000 NCM: ncm_bind: ncm bind ncm=ffffff9ac4f8a000 NCM: ncm_set_alt: ncm=ffffff9ac4f8a000 alt=0 usb0: eth_open dev->port_usb=ffffff9b179c3200 <-- previous released ncm usb0: eth_start dev->port_usb=ffffff9b179c3200 <-- eth_start_xmit() --> dev->wrap() Unable to handle kernel paging request at virtual address dead00000000014f
This patch addresses the issue by checking if 'ncm->netdev' is not NULL at ncm_disable() to call gether_disconnect() to deassociate 'dev->port_usb'. It's more reasonable to check 'ncm->netdev' to call gether_connect/disconnect rather than check 'ncm->port.in_ep->enabled' since it might not be enabled but the gether connection might be established.(CVE-2024-26996)
In the Linux kernel, the following vulnerability has been resolved:
serial/pmac_zilog: Remove flawed mitigation for rx irq flood
The mitigation was intended to stop the irq completely. That may be better than a hard lock-up but it turns out that you get a crash anyway if you're using pmac_zilog as a serial console:
ttyPZ0: pmz: rx irq flood ! BUG: spinlock recursion on CPU#0, swapper/0
That's because the pr_err() call in pmz_receive_chars() results in pmz_console_write() attempting to lock a spinlock already locked in pmz_interrupt(). With CONFIG_DEBUG_SPINLOCK=y, this produces a fatal BUG splat. The spinlock in question is the one in struct uart_port.
Even when it's not fatal, the serial port rx function ceases to work. Also, the iteration limit doesn't play nicely with QEMU, as can be seen in the bug report linked below.
A web search for other reports of the error message "pmz: rx irq flood" didn't produce anything. So I don't think this code is needed any more. Remove it.(CVE-2024-26999)
In the Linux kernel, the following vulnerability has been resolved:
serial: mxs-auart: add spinlock around changing cts state
The uart_handle_cts_change() function in serial_core expects the caller to hold uport->lock. For example, I have seen the below kernel splat, when the Bluetooth driver is loaded on an i.MX28 board.
[ 85.119255] ------------[ cut here ]------------
[ 85.124413] WARNING: CPU: 0 PID: 27 at /drivers/tty/serial/serial_core.c:3453 uart_handle_cts_change+0xb4/0xec
[ 85.134694] Modules linked in: hci_uart bluetooth ecdh_generic ecc wlcore_sdio configfs
[ 85.143314] CPU: 0 PID: 27 Comm: kworker/u3:0 Not tainted 6.6.3-00021-gd62a2f068f92 #1
[ 85.151396] Hardware name: Freescale MXS (Device Tree)
[ 85.156679] Workqueue: hci0 hci_power_on [bluetooth]
(...)
[ 85.191765] uart_handle_cts_change from mxs_auart_irq_handle+0x380/0x3f4
[ 85.198787] mxs_auart_irq_handle from __handle_irq_event_percpu+0x88/0x210
(...)(CVE-2024-27000)
In the Linux kernel, the following vulnerability has been resolved:
comedi: vmk80xx: fix incomplete endpoint checking
While vmk80xx does have endpoint checking implemented, some things can fall through the cracks. Depending on the hardware model, URBs can have either bulk or interrupt type, and current version of vmk80xx_find_usb_endpoints() function does not take that fully into account. While this warning does not seem to be too harmful, at the very least it will crash systems with 'panic_on_warn' set on them.
Fix the issue found by Syzkaller [1] by somewhat simplifying the endpoint checking process with usb_find_common_endpoints() and ensuring that only expected endpoint types are present.
This patch has not been tested on real hardware.
[1] Syzkaller report: usb 1-1: BOGUS urb xfer, pipe 1 != type 3 WARNING: CPU: 0 PID: 781 at drivers/usb/core/urb.c:504 usb_submit_urb+0xc4e/0x18c0 drivers/usb/core/urb.c:503 ... Call Trace: <TASK> usb_start_wait_urb+0x113/0x520 drivers/usb/core/message.c:59 vmk80xx_reset_device drivers/comedi/drivers/vmk80xx.c:227 [inline] vmk80xx_auto_attach+0xa1c/0x1a40 drivers/comedi/drivers/vmk80xx.c:818 comedi_auto_config+0x238/0x380 drivers/comedi/drivers.c:1067 usb_probe_interface+0x5cd/0xb00 drivers/usb/core/driver.c:399 ...
Similar issue also found by Syzkaller:(CVE-2024-27001)
In the Linux kernel, the following vulnerability has been resolved:
drm: nv04: Fix out of bounds access
When Output Resource (dcb->or) value is assigned in fabricate_dcb_output(), there may be out of bounds access to dac_users array in case dcb->or is zero because ffs(dcb->or) is used as index there. The 'or' argument of fabricate_dcb_output() must be interpreted as a number of bit to set, not value.
Utilize macros from 'enum nouveau_or' in calls instead of hardcoding.
Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-27008)
In the Linux kernel, the following vulnerability has been resolved:
net/sched: Fix mirred deadlock on device recursion
When the mirred action is used on a classful egress qdisc and a packet is mirrored or redirected to self we hit a qdisc lock deadlock. See trace below.
[..... other info removed for brevity....] [ 82.890906] [ 82.890906] ============================================ [ 82.890906] WARNING: possible recursive locking detected [ 82.890906] 6.8.0-05205-g77fadd89fe2d-dirty #213 Tainted: G W [ 82.890906] -------------------------------------------- [ 82.890906] ping/418 is trying to acquire lock: [ 82.890906] ffff888006994110 (&sch->q.lock){+.-.}-{3:3}, at: __dev_queue_xmit+0x1778/0x3550 [ 82.890906] [ 82.890906] but task is already holding lock: [ 82.890906] ffff888006994110 (&sch->q.lock){+.-.}-{3:3}, at: __dev_queue_xmit+0x1778/0x3550 [ 82.890906] [ 82.890906] other info that might help us debug this: [ 82.890906] Possible unsafe locking scenario: [ 82.890906] [ 82.890906] CPU0 [ 82.890906] ---- [ 82.890906] lock(&sch->q.lock); [ 82.890906] lock(&sch->q.lock); [ 82.890906] [ 82.890906] *** DEADLOCK *** [ 82.890906] [..... other info removed for brevity....]
Example setup (eth0->eth0) to recreate tc qdisc add dev eth0 root handle 1: htb default 30 tc filter add dev eth0 handle 1: protocol ip prio 2 matchall \ action mirred egress redirect dev eth0
Another example(eth0->eth1->eth0) to recreate tc qdisc add dev eth0 root handle 1: htb default 30 tc filter add dev eth0 handle 1: protocol ip prio 2 matchall \ action mirred egress redirect dev eth1
tc qdisc add dev eth1 root handle 1: htb default 30 tc filter add dev eth1 handle 1: protocol ip prio 2 matchall \ action mirred egress redirect dev eth0
We fix this by adding an owner field (CPU id) to struct Qdisc set after root qdisc is entered. When the softirq enters it a second time, if the qdisc owner is the same CPU, the packet is dropped to break the loop.(CVE-2024-27010)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: fix memleak in map from abort path
The delete set command does not rely on the transaction object for element removal, therefore, a combination of delete element + delete set from the abort path could result in restoring twice the refcount of the mapping.
Check for inactive element in the next generation for the delete element command in the abort path, skip restoring state if next generation bit has been already cleared. This is similar to the activate logic using the set walk iterator.
[ 6170.286929] ------------[ cut here ]------------ [ 6170.286939] WARNING: CPU: 6 PID: 790302 at net/netfilter/nf_tables_api.c:2086 nf_tables_chain_destroy+0x1f7/0x220 [nf_tables] [ 6170.287071] Modules linked in: [...] [ 6170.287633] CPU: 6 PID: 790302 Comm: kworker/6:2 Not tainted 6.9.0-rc3+ #365 [ 6170.287768] RIP: 0010:nf_tables_chain_destroy+0x1f7/0x220 [nf_tables] [ 6170.287886] Code: df 48 8d 7d 58 e8 69 2e 3b df 48 8b 7d 58 e8 80 1b 37 df 48 8d 7d 68 e8 57 2e 3b df 48 8b 7d 68 e8 6e 1b 37 df 48 89 ef eb c4 <0f> 0b 48 83 c4 08 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 0f [ 6170.287895] RSP: 0018:ffff888134b8fd08 EFLAGS: 00010202 [ 6170.287904] RAX: 0000000000000001 RBX: ffff888125bffb28 RCX: dffffc0000000000 [ 6170.287912] RDX: 0000000000000003 RSI: ffffffffa20298ab RDI: ffff88811ebe4750 [ 6170.287919] RBP: ffff88811ebe4700 R08: ffff88838e812650 R09: fffffbfff0623a55 [ 6170.287926] R10: ffffffff8311d2af R11: 0000000000000001 R12: ffff888125bffb10 [ 6170.287933] R13: ffff888125bffb10 R14: dead000000000122 R15: dead000000000100 [ 6170.287940] FS: 0000000000000000(0000) GS:ffff888390b00000(0000) knlGS:0000000000000000 [ 6170.287948] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 6170.287955] CR2: 00007fd31fc00710 CR3: 0000000133f60004 CR4: 00000000001706f0 [ 6170.287962] Call Trace: [ 6170.287967] <TASK> [ 6170.287973] ? __warn+0x9f/0x1a0 [ 6170.287986] ? nf_tables_chain_destroy+0x1f7/0x220 [nf_tables] [ 6170.288092] ? report_bug+0x1b1/0x1e0 [ 6170.287986] ? nf_tables_chain_destroy+0x1f7/0x220 [nf_tables] [ 6170.288092] ? report_bug+0x1b1/0x1e0 [ 6170.288104] ? handle_bug+0x3c/0x70 [ 6170.288112] ? exc_invalid_op+0x17/0x40 [ 6170.288120] ? asm_exc_invalid_op+0x1a/0x20 [ 6170.288132] ? nf_tables_chain_destroy+0x2b/0x220 [nf_tables] [ 6170.288243] ? nf_tables_chain_destroy+0x1f7/0x220 [nf_tables] [ 6170.288366] ? nf_tables_chain_destroy+0x2b/0x220 [nf_tables] [ 6170.288483] nf_tables_trans_destroy_work+0x588/0x590 nf_tables
In the Linux kernel, the following vulnerability has been resolved:
net/rds: fix WARNING in rds_conn_connect_if_down
If connection isn't established yet, get_mr() will fail, trigger connection after get_mr().(CVE-2024-27024)
In the Linux kernel, the following vulnerability has been resolved:
spi: spi-mt65xx: Fix NULL pointer access in interrupt handler
The TX buffer in spi_transfer can be a NULL pointer, so the interrupt handler may end up writing to the invalid memory and cause crashes.
Add a check to trans->tx_buf before using it.(CVE-2024-27028)
In the Linux kernel, the following vulnerability has been resolved:
clk: zynq: Prevent null pointer dereference caused by kmalloc failure
The kmalloc() in zynq_clk_setup() will return null if the physical memory has run out. As a result, if we use snprintf() to write data to the null address, the null pointer dereference bug will happen.
This patch uses a stack variable to replace the kmalloc().(CVE-2024-27037)
In the Linux kernel, the following vulnerability has been resolved:
nfp: flower: handle acti_netdevs allocation failure
The kmalloc_array() in nfp_fl_lag_do_work() will return null, if the physical memory has run out. As a result, if we dereference the acti_netdevs, the null pointer dereference bugs will happen.
This patch adds a check to judge whether allocation failure occurs. If it happens, the delayed work will be rescheduled and try again.(CVE-2024-27046)
In the Linux kernel, the following vulnerability has been resolved:
cpufreq: brcmstb-avs-cpufreq: add check for cpufreq_cpu_get's return value
cpufreq_cpu_get may return NULL. To avoid NULL-dereference check it and return 0 in case of error.
Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-27051)
In the Linux kernel, the following vulnerability has been resolved:
s390/dasd: fix double module refcount decrement
Once the discipline is associated with the device, deleting the device takes care of decrementing the module's refcount. Doing it manually on this error path causes refcount to artificially decrease on each error while it should just stay the same.(CVE-2024-27054)
In the Linux kernel, the following vulnerability has been resolved:
USB: usb-storage: Prevent divide-by-0 error in isd200_ata_command
The isd200 sub-driver in usb-storage uses the HEADS and SECTORS values in the ATA ID information to calculate cylinder and head values when creating a CDB for READ or WRITE commands. The calculation involves division and modulus operations, which will cause a crash if either of these values is 0. While this never happens with a genuine device, it could happen with a flawed or subversive emulation, as reported by the syzbot fuzzer.
Protect against this possibility by refusing to bind to the device if either the ATA_ID_HEADS or ATA_ID_SECTORS value in the device's ID information is 0. This requires isd200_Initialization() to return a negative error code when initialization fails; currently it always returns 0 (even when there is an error).(CVE-2024-27059)
In the Linux kernel, the following vulnerability has been resolved:
nouveau: lock the client object tree.
It appears the client object tree has no locking unless I've missed something else. Fix races around adding/removing client objects, mostly vram bar mappings.
4562.099306] general protection fault, probably for non-canonical address 0x6677ed422bceb80c: 0000 [#1] PREEMPT SMP PTI [ 4562.099314] CPU: 2 PID: 23171 Comm: deqp-vk Not tainted 6.8.0-rc6+ #27 [ 4562.099324] Hardware name: Gigabyte Technology Co., Ltd. Z390 I AORUS PRO WIFI/Z390 I AORUS PRO WIFI-CF, BIOS F8 11/05/2021 [ 4562.099330] RIP: 0010:nvkm_object_search+0x1d/0x70 [nouveau] [ 4562.099503] Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 0f 1f 44 00 00 48 89 f8 48 85 f6 74 39 48 8b 87 a0 00 00 00 48 85 c0 74 12 <48> 8b 48 f8 48 39 ce 73 15 48 8b 40 10 48 85 c0 75 ee 48 c7 c0 fe [ 4562.099506] RSP: 0000:ffffa94cc420bbf8 EFLAGS: 00010206 [ 4562.099512] RAX: 6677ed422bceb814 RBX: ffff98108791f400 RCX: ffff9810f26b8f58 [ 4562.099517] RDX: 0000000000000000 RSI: ffff9810f26b9158 RDI: ffff98108791f400 [ 4562.099519] RBP: ffff9810f26b9158 R08: 0000000000000000 R09: 0000000000000000 [ 4562.099521] R10: ffffa94cc420bc48 R11: 0000000000000001 R12: ffff9810f02a7cc0 [ 4562.099526] R13: 0000000000000000 R14: 00000000000000ff R15: 0000000000000007 [ 4562.099528] FS: 00007f629c5017c0(0000) GS:ffff98142c700000(0000) knlGS:0000000000000000 [ 4562.099534] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 4562.099536] CR2: 00007f629a882000 CR3: 000000017019e004 CR4: 00000000003706f0 [ 4562.099541] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 4562.099542] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 4562.099544] Call Trace: [ 4562.099555] <TASK> [ 4562.099573] ? die_addr+0x36/0x90 [ 4562.099583] ? exc_general_protection+0x246/0x4a0 [ 4562.099593] ? asm_exc_general_protection+0x26/0x30 [ 4562.099600] ? nvkm_object_search+0x1d/0x70 [nouveau] [ 4562.099730] nvkm_ioctl+0xa1/0x250 [nouveau] [ 4562.099861] nvif_object_map_handle+0xc8/0x180 [nouveau] [ 4562.099986] nouveau_ttm_io_mem_reserve+0x122/0x270 [nouveau] [ 4562.100156] ? dma_resv_test_signaled+0x26/0xb0 [ 4562.100163] ttm_bo_vm_fault_reserved+0x97/0x3c0 [ttm] [ 4562.100182] ? __mutex_unlock_slowpath+0x2a/0x270 [ 4562.100189] nouveau_ttm_fault+0x69/0xb0 [nouveau] [ 4562.100356] __do_fault+0x32/0x150 [ 4562.100362] do_fault+0x7c/0x560 [ 4562.100369] __handle_mm_fault+0x800/0xc10 [ 4562.100382] handle_mm_fault+0x17c/0x3e0 [ 4562.100388] do_user_addr_fault+0x208/0x860 [ 4562.100395] exc_page_fault+0x7f/0x200 [ 4562.100402] asm_exc_page_fault+0x26/0x30 [ 4562.100412] RIP: 0033:0x9b9870 [ 4562.100419] Code: 85 a8 f7 ff ff 8b 8d 80 f7 ff ff 89 08 e9 18 f2 ff ff 0f 1f 84 00 00 00 00 00 44 89 32 e9 90 fa ff ff 0f 1f 84 00 00 00 00 00 <44> 89 32 e9 f8 f1 ff ff 0f 1f 84 00 00 00 00 00 66 44 89 32 e9 e7 [ 4562.100422] RSP: 002b:00007fff9ba2dc70 EFLAGS: 00010246 [ 4562.100426] RAX: 0000000000000004 RBX: 000000000dd65e10 RCX: 000000fff0000000 [ 4562.100428] RDX: 00007f629a882000 RSI: 00007f629a882000 RDI: 0000000000000066 [ 4562.100432] RBP: 00007fff9ba2e570 R08: 0000000000000000 R09: 0000000123ddf000 [ 4562.100434] R10: 0000000000000001 R11: 0000000000000246 R12: 000000007fffffff [ 4562.100436] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 4562.100446] </TASK> [ 4562.100448] Modules linked in: nf_conntrack_netbios_ns nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables libcrc32c nfnetlink cmac bnep sunrpc iwlmvm intel_rapl_msr intel_rapl_common snd_sof_pci_intel_cnl x86_pkg_temp_thermal intel_powerclamp snd_sof_intel_hda_common mac80211 coretemp snd_soc_acpi_intel_match kvm_intel snd_soc_acpi snd_soc_hdac_hda snd_sof_pci snd_sof_xtensa_dsp snd_sof_intel_hda_mlink ---truncated---(CVE-2024-27062)
In the Linux kernel, the following vulnerability has been resolved:
media: usbtv: Remove useless locks in usbtv_video_free()
Remove locks calls in usbtv_video_free() because are useless and may led to a deadlock as reported here: https://syzkaller.appspot.com/x/bisect.txt?x=166dc872180000 Also remove usbtv_stop() call since it will be called when unregistering the device.
Before 'c838530d230b' this issue would only be noticed if you disconnect while streaming and now it is noticeable even when disconnecting while not streaming.
hverkuil: fix minor spelling mistake in log message
In the Linux kernel, the following vulnerability has been resolved:
media: ttpci: fix two memleaks in budget_av_attach
When saa7146_register_device and saa7146_vv_init fails, budget_av_attach should free the resources it allocates, like the error-handling of ttpci_budget_init does. Besides, there are two fixme comment refers to such deallocations.(CVE-2024-27073)
In the Linux kernel, the following vulnerability has been resolved:
media: dvb-frontends: avoid stack overflow warnings with clang
A previous patch worked around a KASAN issue in stv0367, now a similar problem showed up with clang:
drivers/media/dvb-frontends/stv0367.c:1222:12: error: stack frame size (3624) exceeds limit (2048) in 'stv0367ter_set_frontend' [-Werror,-Wframe-larger-than] 1214 | static int stv0367ter_set_frontend(struct dvb_frontend *fe)
Rework the stv0367_writereg() function to be simpler and mark both register access functions as noinline_for_stack so the temporary i2c_msg structures do not get duplicated on the stack when KASAN_STACK is enabled.(CVE-2024-27075)
In the Linux kernel, the following vulnerability has been resolved:
media: v4l2-mem2mem: fix a memleak in v4l2_m2m_register_entity
The entity->name (i.e. name) is allocated in v4l2_m2m_register_entity but isn't freed in its following error-handling paths. This patch adds such deallocation to prevent memleak of entity->name.(CVE-2024-27077)
In the Linux kernel, the following vulnerability has been resolved:
media: v4l2-tpg: fix some memleaks in tpg_alloc
In tpg_alloc, resources should be deallocated in each and every error-handling paths, since they are allocated in for statements. Otherwise there would be memleaks because tpg_free is called only when tpg_alloc return 0.(CVE-2024-27078)
In the Linux kernel, the following vulnerability has been resolved:
SUNRPC: fix some memleaks in gssx_dec_option_array
The creds and oa->data need to be freed in the error-handling paths after their allocation. So this patch add these deallocations in the corresponding paths.(CVE-2024-27388)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nft_flow_offload: reset dst in route object after setting up flow
dst is transferred to the flow object, route object does not own it anymore. Reset dst in route object, otherwise if flow_offload_add() fails, error path releases dst twice, leading to a refcount underflow.(CVE-2024-27403)
In the Linux kernel, the following vulnerability has been resolved:
netrom: Fix data-races around sysctl_net_busy_read
We need to protect the reader reading the sysctl value because the value can be changed concurrently.(CVE-2024-27419)
Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2024-27426)
Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2024-27427)
Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2024-27428)
In the Linux kernel, the following vulnerability has been resolved:
dm snapshot: fix lockup in dm_exception_table_exit
There was reported lockup when we exit a snapshot with many exceptions. Fix this by adding "cond_resched" to the loop that frees the exceptions.(CVE-2024-35805)
In the Linux kernel, the following vulnerability has been resolved:
soc: fsl: qbman: Always disable interrupts when taking cgr_lock
smp_call_function_single disables IRQs when executing the callback. To prevent deadlocks, we must disable IRQs when taking cgr_lock elsewhere. This is already done by qman_update_cgr and qman_delete_cgr; fix the other lockers.(CVE-2024-35806)
In the Linux kernel, the following vulnerability has been resolved:
fs/aio: Check IOCB_AIO_RW before the struct aio_kiocb conversion
The first kiocb_set_cancel_fn() argument may point at a struct kiocb that is not embedded inside struct aio_kiocb. With the current code, depending on the compiler, the req->ki_ctx read happens either before the IOCB_AIO_RW test or after that test. Move the req->ki_ctx read such that it is guaranteed that the IOCB_AIO_RW test happens first.(CVE-2024-35815)
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: fix a double-free in arfs_create_groups
When in allocated by kvzalloc fails, arfs_create_groups will free
ft->g and return an error. However, arfs_create_table, the only caller of
arfs_create_groups, will hold this error and call to
mlx5e_destroy_flow_table, in which the ft->g will be freed again.(CVE-2024-35835)
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix information leak in btrfs_ioctl_logical_to_ino()
Syzbot reported the following information leak for in btrfs_ioctl_logical_to_ino():
BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline] BUG: KMSAN: kernel-infoleak in _copy_to_user+0xbc/0x110 lib/usercopy.c:40 instrument_copy_to_user include/linux/instrumented.h:114 [inline] _copy_to_user+0xbc/0x110 lib/usercopy.c:40 copy_to_user include/linux/uaccess.h:191 [inline] btrfs_ioctl_logical_to_ino+0x440/0x750 fs/btrfs/ioctl.c:3499 btrfs_ioctl+0x714/0x1260 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:904 [inline] __se_sys_ioctl+0x261/0x450 fs/ioctl.c:890 __x64_sys_ioctl+0x96/0xe0 fs/ioctl.c:890 x64_sys_call+0x1883/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:17 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Uninit was created at: __kmalloc_large_node+0x231/0x370 mm/slub.c:3921 __do_kmalloc_node mm/slub.c:3954 [inline] __kmalloc_node+0xb07/0x1060 mm/slub.c:3973 kmalloc_node include/linux/slab.h:648 [inline] kvmalloc_node+0xc0/0x2d0 mm/util.c:634 kvmalloc include/linux/slab.h:766 [inline] init_data_container+0x49/0x1e0 fs/btrfs/backref.c:2779 btrfs_ioctl_logical_to_ino+0x17c/0x750 fs/btrfs/ioctl.c:3480 btrfs_ioctl+0x714/0x1260 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:904 [inline] __se_sys_ioctl+0x261/0x450 fs/ioctl.c:890 __x64_sys_ioctl+0x96/0xe0 fs/ioctl.c:890 x64_sys_call+0x1883/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:17 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Bytes 40-65535 of 65536 are uninitialized Memory access of size 65536 starts at ffff888045a40000
This happens, because we're copying a 'struct btrfs_data_container' back to user-space. This btrfs_data_container is allocated in 'init_data_container()' via kvmalloc(), which does not zero-fill the memory.
Fix this by using kvzalloc() which zeroes out the memory on allocation.(CVE-2024-35849)
In the Linux kernel, the following vulnerability has been resolved:
ipv6: Fix infinite recursion in fib6_dump_done().
syzkaller reported infinite recursive calls of fib6_dump_done() during netlink socket destruction. [1]
From the log, syzkaller sent an AF_UNSPEC RTM_GETROUTE message, and then the response was generated. The following recvmmsg() resumed the dump for IPv6, but the first call of inet6_dump_fib() failed at kzalloc() due to the fault injection. [0]
12:01:34 executing program 3: r0 = socket$nl_route(0x10, 0x3, 0x0) sendmsg$nl_route(r0, ... snip ...) recvmmsg(r0, ... snip ...) (fail_nth: 8)
Here, fib6_dump_done() was set to nlk_sk(sk)->cb.done, and the next call of inet6_dump_fib() set it to nlk_sk(sk)->cb.args[3]. syzkaller stopped receiving the response halfway through, and finally netlink_sock_destruct() called nlk_sk(sk)->cb.done().
fib6_dump_done() calls fib6_dump_end() and nlk_sk(sk)->cb.done() if it is still not NULL. fib6_dump_end() rewrites nlk_sk(sk)->cb.done() by nlk_sk(sk)->cb.args[3], but it has the same function, not NULL, calling itself recursively and hitting the stack guard page.
To avoid the issue, let's set the destructor after kzalloc().
[0]: FAULT_INJECTION: forcing a failure. name failslab, interval 1, probability 0, space 0, times 0 CPU: 1 PID: 432110 Comm: syz-executor.3 Not tainted 6.8.0-12821-g537c2e91d354-dirty #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> dump_stack_lvl (lib/dump_stack.c:117) should_fail_ex (lib/fault-inject.c:52 lib/fault-inject.c:153) should_failslab (mm/slub.c:3733) kmalloc_trace (mm/slub.c:3748 mm/slub.c:3827 mm/slub.c:3992) inet6_dump_fib (./include/linux/slab.h:628 ./include/linux/slab.h:749 net/ipv6/ip6_fib.c:662) rtnl_dump_all (net/core/rtnetlink.c:4029) netlink_dump (net/netlink/af_netlink.c:2269) netlink_recvmsg (net/netlink/af_netlink.c:1988) _sysrecvmsg (net/socket.c:1046 net/socket.c:2801) _sys_recvmsg (net/socket.c:2846) do_recvmmsg (net/socket.c:2943) __x64_sys_recvmmsg (net/socket.c:3041 net/socket.c:3034 net/socket.c:3034)
[1]: BUG: TASK stack guard page was hit at 00000000f2fa9af1 (stack is 00000000b7912430..000000009a436beb) stack guard page: 0000 [#1] PREEMPT SMP KASAN CPU: 1 PID: 223719 Comm: kworker/1:3 Not tainted 6.8.0-12821-g537c2e91d354-dirty #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 Workqueue: events netlink_sock_destruct_work RIP: 0010:fib6_dump_done (net/ipv6/ip6_fib.c:570) Code: 3c 24 e8 f3 e9 51 fd e9 28 fd ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 41 57 41 56 41 55 41 54 55 48 89 fd <53> 48 8d 5d 60 e8 b6 4d 07 fd 48 89 da 48 b8 00 00 00 00 00 fc ff RSP: 0018:ffffc9000d980000 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffffffff84405990 RCX: ffffffff844059d3 RDX: ffff8881028e0000 RSI: ffffffff84405ac2 RDI: ffff88810c02f358 RBP: ffff88810c02f358 R08: 0000000000000007 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000224 R12: 0000000000000000 R13: ffff888007c82c78 R14: ffff888007c82c68 R15: ffff888007c82c68 FS: 0000000000000000(0000) GS:ffff88811b100000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffc9000d97fff8 CR3: 0000000102309002 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace: <#DF> </#DF> <TASK> fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1)) fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1)) ... fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1)) fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1)) netlink_sock_destruct (net/netlink/af_netlink.c:401) __sk_destruct (net/core/sock.c:2177 (discriminator 2)) sk_destruct (net/core/sock.c:2224) __sk_free (net/core/sock.c:2235) sk_free (net/core/sock.c:2246) process_one_work (kernel/workqueue.c:3259) worker_thread (kernel/workqueue.c:3329 kernel/workqueue. ---truncated---(CVE-2024-35886)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: Fix potential data-race in __nft_flowtable_type_get()
nft_unregister_flowtable_type() within nf_flow_inet_module_exit() can concurrent with __nft_flowtable_type_get() within nf_tables_newflowtable(). And thhere is not any protection when iterate over nf_tables_flowtables list in __nft_flowtable_type_get(). Therefore, there is pertential data-race of nf_tables_flowtables list entry.
Use list_for_each_entry_rcu() to iterate over nf_tables_flowtables list in __nft_flowtable_type_get(), and use rcu_read_lock() in the caller nft_flowtable_type_get() to protect the entire type query process.(CVE-2024-35898)
In the Linux kernel, the following vulnerability has been resolved:
fbmon: prevent division by zero in fb_videomode_from_videomode()
The expression htotal * vtotal can have a zero value on overflow. It is necessary to prevent division by zero like in fb_var_to_videomode().
Found by Linux Verification Center (linuxtesting.org) with Svace.(CVE-2024-35922)
In the Linux kernel, the following vulnerability has been resolved:
scsi: lpfc: Fix possible memory leak in lpfc_rcv_padisc()
The call to lpfc_sli4_resume_rpi() in lpfc_rcv_padisc() may return an unsuccessful status. In such cases, the elsiocb is not issued, the completion is not called, and thus the elsiocb resource is leaked.
Check return value after calling lpfc_sli4_resume_rpi() and conditionally release the elsiocb resource.(CVE-2024-35930)
In the Linux kernel, the following vulnerability has been resolved:
btrfs: handle chunk tree lookup error in btrfs_relocate_sys_chunks()
The unhandled case in btrfs_relocate_sys_chunks() loop is a corruption, as it could be caused only by two impossible conditions:
-
at first the search key is set up to look for a chunk tree item, with offset -1, this is an inexact search and the key->offset will contain the correct offset upon a successful search, a valid chunk tree item cannot have an offset -1
-
after first successful search, the found_key corresponds to a chunk item, the offset is decremented by 1 before the next loop, it's impossible to find a chunk item there due to alignment and size constraints(CVE-2024-35936)
In the Linux kernel, the following vulnerability has been resolved:
drm/client: Fully protect modes[] with dev->mode_config.mutex
The modes[] array contains pointers to modes on the connectors' mode lists, which are protected by dev->mode_config.mutex. Thus we need to extend modes[] the same protection or by the time we use it the elements may already be pointing to freed/reused memory.(CVE-2024-35950)
In the Linux kernel, the following vulnerability has been resolved:
xsk: validate user input for XDP_{UMEM|COMPLETION}_FILL_RING
syzbot reported an illegal copy in xsk_setsockopt() [1]
Make sure to validate setsockopt() @optlen parameter.
[1]
BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline] BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline] BUG: KASAN: slab-out-of-bounds in xsk_setsockopt+0x909/0xa40 net/xdp/xsk.c:1420 Read of size 4 at addr ffff888028c6cde3 by task syz-executor.0/7549
CPU: 0 PID: 7549 Comm: syz-executor.0 Not tainted 6.8.0-syzkaller-08951-gfe46a7dd189e #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 copy_from_sockptr_offset include/linux/sockptr.h:49 [inline] copy_from_sockptr include/linux/sockptr.h:55 [inline] xsk_setsockopt+0x909/0xa40 net/xdp/xsk.c:1420 do_sock_setsockopt+0x3af/0x720 net/socket.c:2311 __sys_setsockopt+0x1ae/0x250 net/socket.c:2334 __do_sys_setsockopt net/socket.c:2343 [inline] __se_sys_setsockopt net/socket.c:2340 [inline] __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340 do_syscall_64+0xfb/0x240 entry_SYSCALL_64_after_hwframe+0x6d/0x75 RIP: 0033:0x7fb40587de69 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fb40665a0c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000036 RAX: ffffffffffffffda RBX: 00007fb4059abf80 RCX: 00007fb40587de69 RDX: 0000000000000005 RSI: 000000000000011b RDI: 0000000000000006 RBP: 00007fb4058ca47a R08: 0000000000000002 R09: 0000000000000000 R10: 0000000020001980 R11: 0000000000000246 R12: 0000000000000000 R13: 000000000000000b R14: 00007fb4059abf80 R15: 00007fff57ee4d08 </TASK>
Allocated by task 7549: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:370 [inline] __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:387 kasan_kmalloc include/linux/kasan.h:211 [inline] __do_kmalloc_node mm/slub.c:3966 [inline] __kmalloc+0x233/0x4a0 mm/slub.c:3979 kmalloc include/linux/slab.h:632 [inline] __cgroup_bpf_run_filter_setsockopt+0xd2f/0x1040 kernel/bpf/cgroup.c:1869 do_sock_setsockopt+0x6b4/0x720 net/socket.c:2293 __sys_setsockopt+0x1ae/0x250 net/socket.c:2334 __do_sys_setsockopt net/socket.c:2343 [inline] __se_sys_setsockopt net/socket.c:2340 [inline] __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340 do_syscall_64+0xfb/0x240 entry_SYSCALL_64_after_hwframe+0x6d/0x75
The buggy address belongs to the object at ffff888028c6cde0 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 1 bytes to the right of allocated 2-byte region [ffff888028c6cde0, ffff888028c6cde2)
The buggy address belongs to the physical page: page:ffffea0000a31b00 refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888028c6c9c0 pfn:0x28c6c anon flags: 0xfff00000000800(slab|node=0|zone=1|lastcpupid=0x7ff) page_type: 0xffffffff() raw: 00fff00000000800 ffff888014c41280 0000000000000000 dead000000000001 raw: ffff888028c6c9c0 0000000080800057 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected page_owner tracks the page as allocated page last allocated via order 0, migratetype Unmovable, gfp_mask 0x112cc0(GFP_USER|__GFP_NOWARN|__GFP_NORETRY), pid 6648, tgid 6644 (syz-executor.0), ts 133906047828, free_ts 133859922223 set_page_owner include/linux/page_owner.h:31 [inline] post_alloc_hook+0x1ea/0x210 mm/page_alloc.c:1533 prep_new_page mm/page_alloc.c: ---truncated---(CVE-2024-35976)
In the Linux kernel, the following vulnerability has been resolved:
HID: i2c-hid: remove I2C_HID_READ_PENDING flag to prevent lock-up
The flag I2C_HID_READ_PENDING is used to serialize I2C operations. However, this is not necessary, because I2C core already has its own locking for that.
More importantly, this flag can cause a lock-up: if the flag is set in i2c_hid_xfer() and an interrupt happens, the interrupt handler (i2c_hid_irq) will check this flag and return immediately without doing anything, then the interrupt handler will be invoked again in an infinite loop.
Since interrupt handler is an RT task, it takes over the CPU and the flag-clearing task never gets scheduled, thus we have a lock-up.
Delete this unnecessary flag.(CVE-2024-35997)
| URL | Type | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"kernel-tools-debuginfo-4.19.90-2405.5.0.0278.oe2003sp4.aarch64.rpm",
"perf-debuginfo-4.19.90-2405.5.0.0278.oe2003sp4.aarch64.rpm",
"perf-4.19.90-2405.5.0.0278.oe2003sp4.aarch64.rpm",
"kernel-tools-4.19.90-2405.5.0.0278.oe2003sp4.aarch64.rpm",
"python3-perf-4.19.90-2405.5.0.0278.oe2003sp4.aarch64.rpm",
"kernel-debugsource-4.19.90-2405.5.0.0278.oe2003sp4.aarch64.rpm",
"kernel-4.19.90-2405.5.0.0278.oe2003sp4.aarch64.rpm",
"bpftool-debuginfo-4.19.90-2405.5.0.0278.oe2003sp4.aarch64.rpm",
"python3-perf-debuginfo-4.19.90-2405.5.0.0278.oe2003sp4.aarch64.rpm",
"kernel-source-4.19.90-2405.5.0.0278.oe2003sp4.aarch64.rpm",
"kernel-devel-4.19.90-2405.5.0.0278.oe2003sp4.aarch64.rpm",
"kernel-tools-devel-4.19.90-2405.5.0.0278.oe2003sp4.aarch64.rpm",
"python2-perf-debuginfo-4.19.90-2405.5.0.0278.oe2003sp4.aarch64.rpm",
"python2-perf-4.19.90-2405.5.0.0278.oe2003sp4.aarch64.rpm",
"bpftool-4.19.90-2405.5.0.0278.oe2003sp4.aarch64.rpm",
"kernel-debuginfo-4.19.90-2405.5.0.0278.oe2003sp4.aarch64.rpm"
],
"src": [
"kernel-4.19.90-2405.5.0.0278.oe2003sp4.src.rpm"
],
"x86_64": [
"python2-perf-4.19.90-2405.5.0.0278.oe2003sp4.x86_64.rpm",
"kernel-debugsource-4.19.90-2405.5.0.0278.oe2003sp4.x86_64.rpm",
"kernel-devel-4.19.90-2405.5.0.0278.oe2003sp4.x86_64.rpm",
"bpftool-4.19.90-2405.5.0.0278.oe2003sp4.x86_64.rpm",
"kernel-tools-devel-4.19.90-2405.5.0.0278.oe2003sp4.x86_64.rpm",
"python3-perf-debuginfo-4.19.90-2405.5.0.0278.oe2003sp4.x86_64.rpm",
"perf-debuginfo-4.19.90-2405.5.0.0278.oe2003sp4.x86_64.rpm",
"kernel-tools-debuginfo-4.19.90-2405.5.0.0278.oe2003sp4.x86_64.rpm",
"kernel-source-4.19.90-2405.5.0.0278.oe2003sp4.x86_64.rpm",
"kernel-4.19.90-2405.5.0.0278.oe2003sp4.x86_64.rpm",
"kernel-tools-4.19.90-2405.5.0.0278.oe2003sp4.x86_64.rpm",
"kernel-debuginfo-4.19.90-2405.5.0.0278.oe2003sp4.x86_64.rpm",
"perf-4.19.90-2405.5.0.0278.oe2003sp4.x86_64.rpm",
"python3-perf-4.19.90-2405.5.0.0278.oe2003sp4.x86_64.rpm",
"bpftool-debuginfo-4.19.90-2405.5.0.0278.oe2003sp4.x86_64.rpm",
"python2-perf-debuginfo-4.19.90-2405.5.0.0278.oe2003sp4.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:20.03-LTS-SP4",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-20.03-LTS-SP4"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.19.90-2405.5.0.0278.oe2003sp4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: dwc3: ep0: fix NULL pointer exception\r\n\r\nThere is no validation of the index from dwc3_wIndex_to_dep() and we might\nbe referring a non-existing ep and trigger a NULL pointer exception. In\ncertain configurations we might use fewer eps and the index might wrongly\nindicate a larger ep index than existing.\r\n\r\nBy adding this validation from the patch we can actually report a wrong\nindex back to the caller.\r\n\r\nIn our usecase we are using a composite device on an older kernel, but\nupstream might use this fix also. Unfortunately, I cannot describe the\nhardware for others to reproduce the issue as it is a proprietary\nimplementation.\r\n\r\n[ 82.958261] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a4\n[ 82.966891] Mem abort info:\n[ 82.969663] ESR = 0x96000006\n[ 82.972703] Exception class = DABT (current EL), IL = 32 bits\n[ 82.978603] SET = 0, FnV = 0\n[ 82.981642] EA = 0, S1PTW = 0\n[ 82.984765] Data abort info:\n[ 82.987631] ISV = 0, ISS = 0x00000006\n[ 82.991449] CM = 0, WnR = 0\n[ 82.994409] user pgtable: 4k pages, 39-bit VAs, pgdp = 00000000c6210ccc\n[ 83.000999] [00000000000000a4] pgd=0000000053aa5003, pud=0000000053aa5003, pmd=0000000000000000\n[ 83.009685] Internal error: Oops: 96000006 [#1] PREEMPT SMP\n[ 83.026433] Process irq/62-dwc3 (pid: 303, stack limit = 0x000000003985154c)\n[ 83.033470] CPU: 0 PID: 303 Comm: irq/62-dwc3 Not tainted 4.19.124 #1\n[ 83.044836] pstate: 60000085 (nZCv daIf -PAN -UAO)\n[ 83.049628] pc : dwc3_ep0_handle_feature+0x414/0x43c\n[ 83.054558] lr : dwc3_ep0_interrupt+0x3b4/0xc94\r\n\r\n...\r\n\r\n[ 83.141788] Call trace:\n[ 83.144227] dwc3_ep0_handle_feature+0x414/0x43c\n[ 83.148823] dwc3_ep0_interrupt+0x3b4/0xc94\n[ 83.181546] ---[ end trace aac6b5267d84c32f ]---(CVE-2021-47269)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nisdn: mISDN: netjet: Fix crash in nj_probe:\r\n\r\n\u0026apos;nj_setup\u0026apos; in netjet.c might fail with -EIO and in this case\n\u0026apos;card-\u0026gt;irq\u0026apos; is initialized and is bigger than zero. A subsequent call to\n\u0026apos;nj_release\u0026apos; will free the irq that has not been requested.\r\n\r\nFix this bug by deleting the previous assignment to \u0026apos;card-\u0026gt;irq\u0026apos; and just\nkeep the assignment before \u0026apos;request_irq\u0026apos;.\r\n\r\nThe KASAN\u0026apos;s log reveals it:\r\n\r\n[ 3.354615 ] WARNING: CPU: 0 PID: 1 at kernel/irq/manage.c:1826\nfree_irq+0x100/0x480\n[ 3.355112 ] Modules linked in:\n[ 3.355310 ] CPU: 0 PID: 1 Comm: swapper/0 Not tainted\n5.13.0-rc1-00144-g25a1298726e #13\n[ 3.355816 ] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS\nrel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014\n[ 3.356552 ] RIP: 0010:free_irq+0x100/0x480\n[ 3.356820 ] Code: 6e 08 74 6f 4d 89 f4 e8 5e ac 09 00 4d 8b 74 24 18\n4d 85 f6 75 e3 e8 4f ac 09 00 8b 75 c8 48 c7 c7 78 c1 2e 85 e8 e0 cf f5\nff \u0026lt;0f\u0026gt; 0b 48 8b 75 c0 4c 89 ff e8 72 33 0b 03 48 8b 43 40 4c 8b a0 80\n[ 3.358012 ] RSP: 0000:ffffc90000017b48 EFLAGS: 00010082\n[ 3.358357 ] RAX: 0000000000000000 RBX: ffff888104dc8000 RCX:\n0000000000000000\n[ 3.358814 ] RDX: ffff8881003c8000 RSI: ffffffff8124a9e6 RDI:\n00000000ffffffff\n[ 3.359272 ] RBP: ffffc90000017b88 R08: 0000000000000000 R09:\n0000000000000000\n[ 3.359732 ] R10: ffffc900000179f0 R11: 0000000000001d04 R12:\n0000000000000000\n[ 3.360195 ] R13: ffff888107dc6000 R14: ffff888107dc6928 R15:\nffff888104dc80a8\n[ 3.360652 ] FS: 0000000000000000(0000) GS:ffff88817bc00000(0000)\nknlGS:0000000000000000\n[ 3.361170 ] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 3.361538 ] CR2: 0000000000000000 CR3: 000000000582e000 CR4:\n00000000000006f0\n[ 3.362003 ] DR0: 0000000000000000 DR1: 0000000000000000 DR2:\n0000000000000000\n[ 3.362175 ] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:\n0000000000000400\n[ 3.362175 ] Call Trace:\n[ 3.362175 ] nj_release+0x51/0x1e0\n[ 3.362175 ] nj_probe+0x450/0x950\n[ 3.362175 ] ? pci_device_remove+0x110/0x110\n[ 3.362175 ] local_pci_probe+0x45/0xa0\n[ 3.362175 ] pci_device_probe+0x12b/0x1d0\n[ 3.362175 ] really_probe+0x2a9/0x610\n[ 3.362175 ] driver_probe_device+0x90/0x1d0\n[ 3.362175 ] ? mutex_lock_nested+0x1b/0x20\n[ 3.362175 ] device_driver_attach+0x68/0x70\n[ 3.362175 ] __driver_attach+0x124/0x1b0\n[ 3.362175 ] ? device_driver_attach+0x70/0x70\n[ 3.362175 ] bus_for_each_dev+0xbb/0x110\n[ 3.362175 ] ? rdinit_setup+0x45/0x45\n[ 3.362175 ] driver_attach+0x27/0x30\n[ 3.362175 ] bus_add_driver+0x1eb/0x2a0\n[ 3.362175 ] driver_register+0xa9/0x180\n[ 3.362175 ] __pci_register_driver+0x82/0x90\n[ 3.362175 ] ? w6692_init+0x38/0x38\n[ 3.362175 ] nj_init+0x36/0x38\n[ 3.362175 ] do_one_initcall+0x7f/0x3d0\n[ 3.362175 ] ? rdinit_setup+0x45/0x45\n[ 3.362175 ] ? rcu_read_lock_sched_held+0x4f/0x80\n[ 3.362175 ] kernel_init_freeable+0x2aa/0x301\n[ 3.362175 ] ? rest_init+0x2c0/0x2c0\n[ 3.362175 ] kernel_init+0x18/0x190\n[ 3.362175 ] ? rest_init+0x2c0/0x2c0\n[ 3.362175 ] ? rest_init+0x2c0/0x2c0\n[ 3.362175 ] ret_from_fork+0x1f/0x30\n[ 3.362175 ] Kernel panic - not syncing: panic_on_warn set ...\n[ 3.362175 ] CPU: 0 PID: 1 Comm: swapper/0 Not tainted\n5.13.0-rc1-00144-g25a1298726e #13\n[ 3.362175 ] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS\nrel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014\n[ 3.362175 ] Call Trace:\n[ 3.362175 ] dump_stack+0xba/0xf5\n[ 3.362175 ] ? free_irq+0x100/0x480\n[ 3.362175 ] panic+0x15a/0x3f2\n[ 3.362175 ] ? __warn+0xf2/0x150\n[ 3.362175 ] ? free_irq+0x100/0x480\n[ 3.362175 ] __warn+0x108/0x150\n[ 3.362175 ] ? free_irq+0x100/0x480\n[ 3.362175 ] report_bug+0x119/0x1c0\n[ 3.362175 ] handle_bug+0x3b/0x80\n[ 3.362175 ] exc_invalid_op+0x18/0x70\n[ 3.362175 ] asm_exc_invalid_op+0x12/0x20\n[ 3.362175 ] RIP: 0010:free_irq+0x100\n---truncated---(CVE-2021-47284)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nf2fs: fix to avoid racing on fsync_entry_slab by multi filesystem instances\r\n\r\nAs syzbot reported, there is an use-after-free issue during f2fs recovery:\r\n\r\nUse-after-free write at 0xffff88823bc16040 (in kfence-#10):\n kmem_cache_destroy+0x1f/0x120 mm/slab_common.c:486\n f2fs_recover_fsync_data+0x75b0/0x8380 fs/f2fs/recovery.c:869\n f2fs_fill_super+0x9393/0xa420 fs/f2fs/super.c:3945\n mount_bdev+0x26c/0x3a0 fs/super.c:1367\n legacy_get_tree+0xea/0x180 fs/fs_context.c:592\n vfs_get_tree+0x86/0x270 fs/super.c:1497\n do_new_mount fs/namespace.c:2905 [inline]\n path_mount+0x196f/0x2be0 fs/namespace.c:3235\n do_mount fs/namespace.c:3248 [inline]\n __do_sys_mount fs/namespace.c:3456 [inline]\n __se_sys_mount+0x2f9/0x3b0 fs/namespace.c:3433\n do_syscall_64+0x3f/0xb0 arch/x86/entry/common.c:47\n entry_SYSCALL_64_after_hwframe+0x44/0xae\r\n\r\nThe root cause is multi f2fs filesystem instances can race on accessing\nglobal fsync_entry_slab pointer, result in use-after-free issue of slab\ncache, fixes to init/destroy this slab cache only once during module\ninit/destroy procedure to avoid this issue.(CVE-2021-47335)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nhwmon: (mlxreg-fan) Return non-zero value when fan current state is enforced from sysfs\r\n\r\nFan speed minimum can be enforced from sysfs. For example, setting\ncurrent fan speed to 20 is used to enforce fan speed to be at 100%\nspeed, 19 - to be not below 90% speed, etcetera. This feature provides\nability to limit fan speed according to some system wise\nconsiderations, like absence of some replaceable units or high system\nambient temperature.\r\n\r\nRequest for changing fan minimum speed is configuration request and can\nbe set only through \u0026apos;sysfs\u0026apos; write procedure. In this situation value of\nargument \u0026apos;state\u0026apos; is above nominal fan speed maximum.\r\n\r\nReturn non-zero code in this case to avoid\nthermal_cooling_device_stats_update() call, because in this case\nstatistics update violates thermal statistics table range.\nThe issues is observed in case kernel is configured with option\nCONFIG_THERMAL_STATISTICS.\r\n\r\nHere is the trace from KASAN:\n[ 159.506659] BUG: KASAN: slab-out-of-bounds in thermal_cooling_device_stats_update+0x7d/0xb0\n[ 159.516016] Read of size 4 at addr ffff888116163840 by task hw-management.s/7444\n[ 159.545625] Call Trace:\n[ 159.548366] dump_stack+0x92/0xc1\n[ 159.552084] ? thermal_cooling_device_stats_update+0x7d/0xb0\n[ 159.635869] thermal_zone_device_update+0x345/0x780\n[ 159.688711] thermal_zone_device_set_mode+0x7d/0xc0\n[ 159.694174] mlxsw_thermal_modules_init+0x48f/0x590 [mlxsw_core]\n[ 159.700972] ? mlxsw_thermal_set_cur_state+0x5a0/0x5a0 [mlxsw_core]\n[ 159.731827] mlxsw_thermal_init+0x763/0x880 [mlxsw_core]\n[ 160.070233] RIP: 0033:0x7fd995909970\n[ 160.074239] Code: 73 01 c3 48 8b 0d 28 d5 2b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d 99 2d 2c 00 00 75 10 b8 01 00 00 00 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ..\n[ 160.095242] RSP: 002b:00007fff54f5d938 EFLAGS: 00000246 ORIG_RAX: 0000000000000001\n[ 160.103722] RAX: ffffffffffffffda RBX: 0000000000000013 RCX: 00007fd995909970\n[ 160.111710] RDX: 0000000000000013 RSI: 0000000001906008 RDI: 0000000000000001\n[ 160.119699] RBP: 0000000001906008 R08: 00007fd995bc9760 R09: 00007fd996210700\n[ 160.127687] R10: 0000000000000073 R11: 0000000000000246 R12: 0000000000000013\n[ 160.135673] R13: 0000000000000001 R14: 00007fd995bc8600 R15: 0000000000000013\n[ 160.143671]\n[ 160.145338] Allocated by task 2924:\n[ 160.149242] kasan_save_stack+0x19/0x40\n[ 160.153541] __kasan_kmalloc+0x7f/0xa0\n[ 160.157743] __kmalloc+0x1a2/0x2b0\n[ 160.161552] thermal_cooling_device_setup_sysfs+0xf9/0x1a0\n[ 160.167687] __thermal_cooling_device_register+0x1b5/0x500\n[ 160.173833] devm_thermal_of_cooling_device_register+0x60/0xa0\n[ 160.180356] mlxreg_fan_probe+0x474/0x5e0 [mlxreg_fan]\n[ 160.248140]\n[ 160.249807] The buggy address belongs to the object at ffff888116163400\n[ 160.249807] which belongs to the cache kmalloc-1k of size 1024\n[ 160.263814] The buggy address is located 64 bytes to the right of\n[ 160.263814] 1024-byte region [ffff888116163400, ffff888116163800)\n[ 160.277536] The buggy address belongs to the page:\n[ 160.282898] page:0000000012275840 refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888116167000 pfn:0x116160\n[ 160.294872] head:0000000012275840 order:3 compound_mapcount:0 compound_pincount:0\n[ 160.303251] flags: 0x200000000010200(slab|head|node=0|zone=2)\n[ 160.309694] raw: 0200000000010200 ffffea00046f7208 ffffea0004928208 ffff88810004dbc0\n[ 160.318367] raw: ffff888116167000 00000000000a0006 00000001ffffffff 0000000000000000\n[ 160.327033] page dumped because: kasan: bad access detected\n[ 160.333270]\n[ 160.334937] Memory state around the buggy address:\n[ 160.356469] \u0026gt;ffff888116163800: fc ..(CVE-2021-47393)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nptp: Fix possible memory leak in ptp_clock_register()\r\n\r\nI got memory leak as follows when doing fault injection test:\r\n\r\nunreferenced object 0xffff88800906c618 (size 8):\n comm \u0026quot;i2c-idt82p33931\u0026quot;, pid 4421, jiffies 4294948083 (age 13.188s)\n hex dump (first 8 bytes):\n 70 74 70 30 00 00 00 00 ptp0....\n backtrace:\n [\u0026lt;00000000312ed458\u0026gt;] __kmalloc_track_caller+0x19f/0x3a0\n [\u0026lt;0000000079f6e2ff\u0026gt;] kvasprintf+0xb5/0x150\n [\u0026lt;0000000026aae54f\u0026gt;] kvasprintf_const+0x60/0x190\n [\u0026lt;00000000f323a5f7\u0026gt;] kobject_set_name_vargs+0x56/0x150\n [\u0026lt;000000004e35abdd\u0026gt;] dev_set_name+0xc0/0x100\n [\u0026lt;00000000f20cfe25\u0026gt;] ptp_clock_register+0x9f4/0xd30 [ptp]\n [\u0026lt;000000008bb9f0de\u0026gt;] idt82p33_probe.cold+0x8b6/0x1561 [ptp_idt82p33]\r\n\r\nWhen posix_clock_register() returns an error, the name allocated\nin dev_set_name() will be leaked, the put_device() should be used\nto give up the device reference, then the name will be freed in\nkobject_cleanup() and other memory will be freed in ptp_clock_release().(CVE-2021-47455)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: qla2xxx: Fix a memory leak in an error path of qla2x00_process_els()\r\n\r\nCommit 8c0eb596baa5 (\u0026quot;[SCSI] qla2xxx: Fix a memory leak in an error path of\nqla2x00_process_els()\u0026quot;), intended to change:\r\n\r\n bsg_job-\u0026gt;request-\u0026gt;msgcode == FC_BSG_HST_ELS_NOLOGIN\r\n\r\n\n bsg_job-\u0026gt;request-\u0026gt;msgcode != FC_BSG_RPT_ELS\r\n\r\nbut changed it to:\r\n\r\n bsg_job-\u0026gt;request-\u0026gt;msgcode == FC_BSG_RPT_ELS\r\n\r\ninstead.\r\n\r\nChange the == to a != to avoid leaking the fcport structure or freeing\nunallocated memory.(CVE-2021-47473)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnvmem: Fix shift-out-of-bound (UBSAN) with byte size cells\r\n\r\nIf a cell has \u0026apos;nbits\u0026apos; equal to a multiple of BITS_PER_BYTE the logic\r\n\r\n *p \u0026amp;= GENMASK((cell-\u0026gt;nbits%BITS_PER_BYTE) - 1, 0);\r\n\r\nwill become undefined behavior because nbits modulo BITS_PER_BYTE is 0, and we\nsubtract one from that making a large number that is then shifted more than the\nnumber of bits that fit into an unsigned long.\r\n\r\nUBSAN reports this problem:\r\n\r\n UBSAN: shift-out-of-bounds in drivers/nvmem/core.c:1386:8\n shift exponent 64 is too large for 64-bit type \u0026apos;unsigned long\u0026apos;\n CPU: 6 PID: 7 Comm: kworker/u16:0 Not tainted 5.15.0-rc3+ #9\n Hardware name: Google Lazor (rev3+) with KB Backlight (DT)\n Workqueue: events_unbound deferred_probe_work_func\n Call trace:\n dump_backtrace+0x0/0x170\n show_stack+0x24/0x30\n dump_stack_lvl+0x64/0x7c\n dump_stack+0x18/0x38\n ubsan_epilogue+0x10/0x54\n __ubsan_handle_shift_out_of_bounds+0x180/0x194\n __nvmem_cell_read+0x1ec/0x21c\n nvmem_cell_read+0x58/0x94\n nvmem_cell_read_variable_common+0x4c/0xb0\n nvmem_cell_read_variable_le_u32+0x40/0x100\n a6xx_gpu_init+0x170/0x2f4\n adreno_bind+0x174/0x284\n component_bind_all+0xf0/0x264\n msm_drm_bind+0x1d8/0x7a0\n try_to_bring_up_master+0x164/0x1ac\n __component_add+0xbc/0x13c\n component_add+0x20/0x2c\n dp_display_probe+0x340/0x384\n platform_probe+0xc0/0x100\n really_probe+0x110/0x304\n __driver_probe_device+0xb8/0x120\n driver_probe_device+0x4c/0xfc\n __device_attach_driver+0xb0/0x128\n bus_for_each_drv+0x90/0xdc\n __device_attach+0xc8/0x174\n device_initial_probe+0x20/0x2c\n bus_probe_device+0x40/0xa4\n deferred_probe_work_func+0x7c/0xb8\n process_one_work+0x128/0x21c\n process_scheduled_works+0x40/0x54\n worker_thread+0x1ec/0x2a8\n kthread+0x138/0x158\n ret_from_fork+0x10/0x20\r\n\r\nFix it by making sure there are any bits to mask out.(CVE-2021-47497)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: mpt3sas: Fix use-after-free warning\r\n\r\nFix the following use-after-free warning which is observed during\ncontroller reset:\r\n\r\nrefcount_t: underflow; use-after-free.\nWARNING: CPU: 23 PID: 5399 at lib/refcount.c:28 refcount_warn_saturate+0xa6/0xf0(CVE-2022-48695)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnvmet: fix a use-after-free\r\n\r\nFix the following use-after-free complaint triggered by blktests nvme/004:\r\n\r\nBUG: KASAN: user-memory-access in blk_mq_complete_request_remote+0xac/0x350\nRead of size 4 at addr 0000607bd1835943 by task kworker/13:1/460\nWorkqueue: nvmet-wq nvme_loop_execute_work [nvme_loop]\nCall Trace:\n show_stack+0x52/0x58\n dump_stack_lvl+0x49/0x5e\n print_report.cold+0x36/0x1e2\n kasan_report+0xb9/0xf0\n __asan_load4+0x6b/0x80\n blk_mq_complete_request_remote+0xac/0x350\n nvme_loop_queue_response+0x1df/0x275 [nvme_loop]\n __nvmet_req_complete+0x132/0x4f0 [nvmet]\n nvmet_req_complete+0x15/0x40 [nvmet]\n nvmet_execute_io_connect+0x18a/0x1f0 [nvmet]\n nvme_loop_execute_work+0x20/0x30 [nvme_loop]\n process_one_work+0x56e/0xa70\n worker_thread+0x2d1/0x640\n kthread+0x183/0x1c0\n ret_from_fork+0x1f/0x30(CVE-2022-48697)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nALSA: emu10k1: Fix out of bounds access in snd_emu10k1_pcm_channel_alloc()\r\n\r\nThe voice allocator sometimes begins allocating from near the end of the\narray and then wraps around, however snd_emu10k1_pcm_channel_alloc()\naccesses the newly allocated voices as if it never wrapped around.\r\n\r\nThis results in out of bounds access if the first voice has a high enough\nindex so that first_voice + requested_voice_count \u0026gt; NUM_G (64).\nThe more voices are requested, the more likely it is for this to occur.\r\n\r\nThis was initially discovered using PipeWire, however it can be reproduced\nby calling aplay multiple times with 16 channels:\naplay -r 48000 -D plughw:CARD=Live,DEV=3 -c 16 /dev/zero\r\n\r\nUBSAN: array-index-out-of-bounds in sound/pci/emu10k1/emupcm.c:127:40\nindex 65 is out of range for type \u0026apos;snd_emu10k1_voice [64]\u0026apos;\nCPU: 1 PID: 31977 Comm: aplay Tainted: G W IOE 6.0.0-rc2-emu10k1+ #7\nHardware name: ASUSTEK COMPUTER INC P5W DH Deluxe/P5W DH Deluxe, BIOS 3002 07/22/2010\nCall Trace:\n\u0026lt;TASK\u0026gt;\ndump_stack_lvl+0x49/0x63\ndump_stack+0x10/0x16\nubsan_epilogue+0x9/0x3f\n__ubsan_handle_out_of_bounds.cold+0x44/0x49\nsnd_emu10k1_playback_hw_params+0x3bc/0x420 [snd_emu10k1]\nsnd_pcm_hw_params+0x29f/0x600 [snd_pcm]\nsnd_pcm_common_ioctl+0x188/0x1410 [snd_pcm]\n? exit_to_user_mode_prepare+0x35/0x170\n? do_syscall_64+0x69/0x90\n? syscall_exit_to_user_mode+0x26/0x50\n? do_syscall_64+0x69/0x90\n? exit_to_user_mode_prepare+0x35/0x170\nsnd_pcm_ioctl+0x27/0x40 [snd_pcm]\n__x64_sys_ioctl+0x95/0xd0\ndo_syscall_64+0x5c/0x90\n? do_syscall_64+0x69/0x90\n? do_syscall_64+0x69/0x90\nentry_SYSCALL_64_after_hwframe+0x63/0xcd(CVE-2022-48702)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/radeon: add a force flush to delay work when radeon\r\n\r\nAlthough radeon card fence and wait for gpu to finish processing current batch rings,\nthere is still a corner case that radeon lockup work queue may not be fully flushed,\nand meanwhile the radeon_suspend_kms() function has called pci_set_power_state() to\nput device in D3hot state.\nPer PCI spec rev 4.0 on 5.3.1.4.1 D3hot State.\n\u0026gt; Configuration and Message requests are the only TLPs accepted by a Function in\n\u0026gt; the D3hot state. All other received Requests must be handled as Unsupported Requests,\n\u0026gt; and all received Completions may optionally be handled as Unexpected Completions.\nThis issue will happen in following logs:\nUnable to handle kernel paging request at virtual address 00008800e0008010\nCPU 0 kworker/0:3(131): Oops 0\npc = [\u0026lt;ffffffff811bea5c\u0026gt;] ra = [\u0026lt;ffffffff81240844\u0026gt;] ps = 0000 Tainted: G W\npc is at si_gpu_check_soft_reset+0x3c/0x240\nra is at si_dma_is_lockup+0x34/0xd0\nv0 = 0000000000000000 t0 = fff08800e0008010 t1 = 0000000000010000\nt2 = 0000000000008010 t3 = fff00007e3c00000 t4 = fff00007e3c00258\nt5 = 000000000000ffff t6 = 0000000000000001 t7 = fff00007ef078000\ns0 = fff00007e3c016e8 s1 = fff00007e3c00000 s2 = fff00007e3c00018\ns3 = fff00007e3c00000 s4 = fff00007fff59d80 s5 = 0000000000000000\ns6 = fff00007ef07bd98\na0 = fff00007e3c00000 a1 = fff00007e3c016e8 a2 = 0000000000000008\na3 = 0000000000000001 a4 = 8f5c28f5c28f5c29 a5 = ffffffff810f4338\nt8 = 0000000000000275 t9 = ffffffff809b66f8 t10 = ff6769c5d964b800\nt11= 000000000000b886 pv = ffffffff811bea20 at = 0000000000000000\ngp = ffffffff81d89690 sp = 00000000aa814126\nDisabling lock debugging due to kernel taint\nTrace:\n[\u0026lt;ffffffff81240844\u0026gt;] si_dma_is_lockup+0x34/0xd0\n[\u0026lt;ffffffff81119610\u0026gt;] radeon_fence_check_lockup+0xd0/0x290\n[\u0026lt;ffffffff80977010\u0026gt;] process_one_work+0x280/0x550\n[\u0026lt;ffffffff80977350\u0026gt;] worker_thread+0x70/0x7c0\n[\u0026lt;ffffffff80977410\u0026gt;] worker_thread+0x130/0x7c0\n[\u0026lt;ffffffff80982040\u0026gt;] kthread+0x200/0x210\n[\u0026lt;ffffffff809772e0\u0026gt;] worker_thread+0x0/0x7c0\n[\u0026lt;ffffffff80981f8c\u0026gt;] kthread+0x14c/0x210\n[\u0026lt;ffffffff80911658\u0026gt;] ret_from_kernel_thread+0x18/0x20\n[\u0026lt;ffffffff80981e40\u0026gt;] kthread+0x0/0x210\n Code: ad3e0008 43f0074a ad7e0018 ad9e0020 8c3001e8 40230101\n \u0026lt;88210000\u0026gt; 4821ed21\nSo force lockup work queue flush to fix this problem.(CVE-2022-48704)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/radeon: fix a possible null pointer dereference\r\n\r\nIn radeon_fp_native_mode(), the return value of drm_mode_duplicate()\nis assigned to mode, which will lead to a NULL pointer dereference\non failure of drm_mode_duplicate(). Add a check to avoid npd.\r\n\r\nThe failure status of drm_cvt_mode() on the other path is checked too.(CVE-2022-48710)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/tegra: dsi: Add missing check for of_find_device_by_node\r\n\r\nAdd check for the return value of of_find_device_by_node() and return\nthe error if it fails in order to avoid NULL pointer dereference.(CVE-2023-52650)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nNTB: fix possible name leak in ntb_register_device()\r\n\r\nIf device_register() fails in ntb_register_device(), the device name\nallocated by dev_set_name() should be freed. As per the comment in\ndevice_register(), callers should use put_device() to give up the\nreference in the error path. So fix this by calling put_device() in the\nerror path so that the name can be freed in kobject_cleanup().\r\n\r\nAs a result of this, put_device() in the error path of\nntb_register_device() is removed and the actual error is returned.\r\n\r\n[mani: reworded commit message](CVE-2023-52652)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nSUNRPC: fix a memleak in gss_import_v2_context\r\n\r\nThe ctx-\u0026gt;mech_used.data allocated by kmemdup is not freed in neither\ngss_import_v2_context nor it only caller gss_krb5_import_sec_context,\nwhich frees ctx on error.\r\n\r\nThus, this patch reform the last call of gss_import_v2_context to the\ngss_krb5_import_ctx_v2, preventing the memleak while keepping the return\nformation.(CVE-2023-52653)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nio_uring: drop any code related to SCM_RIGHTS\r\n\r\nThis is dead code after we dropped support for passing io_uring fds\nover SCM_RIGHTS, get rid of it.(CVE-2023-52656)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nACPI: LPIT: Avoid u32 multiplication overflow\r\n\r\nIn lpit_update_residency() there is a possibility of overflow\nin multiplication, if tsc_khz is large enough (\u0026gt; UINT_MAX/1000).\r\n\r\nChange multiplication to mul_u32_u32().\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2023-52683)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npstore: ram_core: fix possible overflow in persistent_ram_init_ecc()\r\n\r\nIn persistent_ram_init_ecc(), on 64-bit arches DIV_ROUND_UP() will return\n64-bit value since persistent_ram_zone::buffer_size has type size_t which\nis derived from the 64-bit *unsigned long*, while the ecc_blocks variable\nthis value gets assigned to has (always 32-bit) *int* type. Even if that\nvalue fits into *int* type, an overflow is still possible when calculating\nthe size_t typed ecc_total variable further below since there\u0026apos;s no cast to\nany 64-bit type before multiplication. Declaring the ecc_blocks variable\nas *size_t* should fix this mess...\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with the SVACE static\nanalysis tool.(CVE-2023-52685)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/pm: fix a double-free in si_dpm_init\r\n\r\nWhen the allocation of\nadev-\u0026gt;pm.dpm.dyn_state.vddc_dependency_on_dispclk.entries fails,\namdgpu_free_extended_power_table is called to free some fields of adev.\nHowever, when the control flow returns to si_dpm_sw_init, it goes to\nlabel dpm_failed and calls si_dpm_fini, which calls\namdgpu_free_extended_power_table again and free those fields again. Thus\na double-free is triggered.(CVE-2023-52691)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncalipso: fix memory leak in netlbl_calipso_add_pass()\r\n\r\nIf IPv6 support is disabled at boot (ipv6.disable=1),\nthe calipso_init() -\u0026gt; netlbl_calipso_ops_register() function isn\u0026apos;t called,\nand the netlbl_calipso_ops_get() function always returns NULL.\nIn this case, the netlbl_calipso_add_pass() function allocates memory\nfor the doi_def variable but doesn\u0026apos;t free it with the calipso_doi_free().\r\n\r\nBUG: memory leak\nunreferenced object 0xffff888011d68180 (size 64):\n comm \u0026quot;syz-executor.1\u0026quot;, pid 10746, jiffies 4295410986 (age 17.928s)\n hex dump (first 32 bytes):\n 00 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 ................\n 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n backtrace:\n [\u0026lt;...\u0026gt;] kmalloc include/linux/slab.h:552 [inline]\n [\u0026lt;...\u0026gt;] netlbl_calipso_add_pass net/netlabel/netlabel_calipso.c:76 [inline]\n [\u0026lt;...\u0026gt;] netlbl_calipso_add+0x22e/0x4f0 net/netlabel/netlabel_calipso.c:111\n [\u0026lt;...\u0026gt;] genl_family_rcv_msg_doit+0x22f/0x330 net/netlink/genetlink.c:739\n [\u0026lt;...\u0026gt;] genl_family_rcv_msg net/netlink/genetlink.c:783 [inline]\n [\u0026lt;...\u0026gt;] genl_rcv_msg+0x341/0x5a0 net/netlink/genetlink.c:800\n [\u0026lt;...\u0026gt;] netlink_rcv_skb+0x14d/0x440 net/netlink/af_netlink.c:2515\n [\u0026lt;...\u0026gt;] genl_rcv+0x29/0x40 net/netlink/genetlink.c:811\n [\u0026lt;...\u0026gt;] netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline]\n [\u0026lt;...\u0026gt;] netlink_unicast+0x54b/0x800 net/netlink/af_netlink.c:1339\n [\u0026lt;...\u0026gt;] netlink_sendmsg+0x90a/0xdf0 net/netlink/af_netlink.c:1934\n [\u0026lt;...\u0026gt;] sock_sendmsg_nosec net/socket.c:651 [inline]\n [\u0026lt;...\u0026gt;] sock_sendmsg+0x157/0x190 net/socket.c:671\n [\u0026lt;...\u0026gt;] ____sys_sendmsg+0x712/0x870 net/socket.c:2342\n [\u0026lt;...\u0026gt;] ___sys_sendmsg+0xf8/0x170 net/socket.c:2396\n [\u0026lt;...\u0026gt;] __sys_sendmsg+0xea/0x1b0 net/socket.c:2429\n [\u0026lt;...\u0026gt;] do_syscall_64+0x30/0x40 arch/x86/entry/common.c:46\n [\u0026lt;...\u0026gt;] entry_SYSCALL_64_after_hwframe+0x61/0xc6\r\n\r\nFound by InfoTeCS on behalf of Linux Verification Center\n(linuxtesting.org) with Syzkaller\r\n\r\n[PM: merged via the LSM tree at Jakub Kicinski request](CVE-2023-52698)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: Fix a null pointer access when the smc_rreg pointer is NULL\r\n\r\nIn certain types of chips, such as VEGA20, reading the amdgpu_regs_smc file could result in an abnormal null pointer access when the smc_rreg pointer is NULL. Below are the steps to reproduce this issue and the corresponding exception log:\r\n\r\n1. Navigate to the directory: /sys/kernel/debug/dri/0\n2. Execute command: cat amdgpu_regs_smc\n3. Exception Log::\n[4005007.702554] BUG: kernel NULL pointer dereference, address: 0000000000000000\n[4005007.702562] #PF: supervisor instruction fetch in kernel mode\n[4005007.702567] #PF: error_code(0x0010) - not-present page\n[4005007.702570] PGD 0 P4D 0\n[4005007.702576] Oops: 0010 [#1] SMP NOPTI\n[4005007.702581] CPU: 4 PID: 62563 Comm: cat Tainted: G OE 5.15.0-43-generic #46-Ubunt u\n[4005007.702590] RIP: 0010:0x0\n[4005007.702598] Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6.\n[4005007.702600] RSP: 0018:ffffa82b46d27da0 EFLAGS: 00010206\n[4005007.702605] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffa82b46d27e68\n[4005007.702609] RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff9940656e0000\n[4005007.702612] RBP: ffffa82b46d27dd8 R08: 0000000000000000 R09: ffff994060c07980\n[4005007.702615] R10: 0000000000020000 R11: 0000000000000000 R12: 00007f5e06753000\n[4005007.702618] R13: ffff9940656e0000 R14: ffffa82b46d27e68 R15: 00007f5e06753000\n[4005007.702622] FS: 00007f5e0755b740(0000) GS:ffff99479d300000(0000) knlGS:0000000000000000\n[4005007.702626] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[4005007.702629] CR2: ffffffffffffffd6 CR3: 00000003253fc000 CR4: 00000000003506e0\n[4005007.702633] Call Trace:\n[4005007.702636] \u0026lt;TASK\u0026gt;\n[4005007.702640] amdgpu_debugfs_regs_smc_read+0xb0/0x120 [amdgpu]\n[4005007.703002] full_proxy_read+0x5c/0x80\n[4005007.703011] vfs_read+0x9f/0x1a0\n[4005007.703019] ksys_read+0x67/0xe0\n[4005007.703023] __x64_sys_read+0x19/0x20\n[4005007.703028] do_syscall_64+0x5c/0xc0\n[4005007.703034] ? do_user_addr_fault+0x1e3/0x670\n[4005007.703040] ? exit_to_user_mode_prepare+0x37/0xb0\n[4005007.703047] ? irqentry_exit_to_user_mode+0x9/0x20\n[4005007.703052] ? irqentry_exit+0x19/0x30\n[4005007.703057] ? exc_page_fault+0x89/0x160\n[4005007.703062] ? asm_exc_page_fault+0x8/0x30\n[4005007.703068] entry_SYSCALL_64_after_hwframe+0x44/0xae\n[4005007.703075] RIP: 0033:0x7f5e07672992\n[4005007.703079] Code: c0 e9 b2 fe ff ff 50 48 8d 3d fa b2 0c 00 e8 c5 1d 02 00 0f 1f 44 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 0f 05 \u0026lt;48\u0026gt; 3d 00 f0 ff ff 77 56 c3 0f 1f 44 00 00 48 83 e c 28 48 89 54 24\n[4005007.703083] RSP: 002b:00007ffe03097898 EFLAGS: 00000246 ORIG_RAX: 0000000000000000\n[4005007.703088] RAX: ffffffffffffffda RBX: 0000000000020000 RCX: 00007f5e07672992\n[4005007.703091] RDX: 0000000000020000 RSI: 00007f5e06753000 RDI: 0000000000000003\n[4005007.703094] RBP: 00007f5e06753000 R08: 00007f5e06752010 R09: 00007f5e06752010\n[4005007.703096] R10: 0000000000000022 R11: 0000000000000246 R12: 0000000000022000\n[4005007.703099] R13: 0000000000000003 R14: 0000000000020000 R15: 0000000000020000\n[4005007.703105] \u0026lt;/TASK\u0026gt;\n[4005007.703107] Modules linked in: nf_tables libcrc32c nfnetlink algif_hash af_alg binfmt_misc nls_ iso8859_1 ipmi_ssif ast intel_rapl_msr intel_rapl_common drm_vram_helper drm_ttm_helper amd64_edac t tm edac_mce_amd kvm_amd ccp mac_hid k10temp kvm acpi_ipmi ipmi_si rapl sch_fq_codel ipmi_devintf ipm i_msghandler msr parport_pc ppdev lp parport mtd pstore_blk efi_pstore ramoops pstore_zone reed_solo mon ip_tables x_tables autofs4 ib_uverbs ib_core amdgpu(OE) amddrm_ttm_helper(OE) amdttm(OE) iommu_v 2 amd_sched(OE) amdkcl(OE) drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops cec rc_core drm igb ahci xhci_pci libahci i2c_piix4 i2c_algo_bit xhci_pci_renesas dca\n[4005007.703184] CR2: 0000000000000000\n[4005007.703188] ---[ en\n---truncated---(CVE-2023-52817)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd: Fix UBSAN array-index-out-of-bounds for SMU7\r\n\r\nFor pptable structs that use flexible array sizes, use flexible arrays.(CVE-2023-52818)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nperf/core: Bail out early if the request AUX area is out of bound\r\n\r\nWhen perf-record with a large AUX area, e.g 4GB, it fails with:\r\n\r\n #perf record -C 0 -m ,4G -e arm_spe_0// -- sleep 1\n failed to mmap with 12 (Cannot allocate memory)\r\n\r\nand it reveals a WARNING with __alloc_pages():\r\n\r\n\t------------[ cut here ]------------\n\tWARNING: CPU: 44 PID: 17573 at mm/page_alloc.c:5568 __alloc_pages+0x1ec/0x248\n\tCall trace:\n\t __alloc_pages+0x1ec/0x248\n\t __kmalloc_large_node+0xc0/0x1f8\n\t __kmalloc_node+0x134/0x1e8\n\t rb_alloc_aux+0xe0/0x298\n\t perf_mmap+0x440/0x660\n\t mmap_region+0x308/0x8a8\n\t do_mmap+0x3c0/0x528\n\t vm_mmap_pgoff+0xf4/0x1b8\n\t ksys_mmap_pgoff+0x18c/0x218\n\t __arm64_sys_mmap+0x38/0x58\n\t invoke_syscall+0x50/0x128\n\t el0_svc_common.constprop.0+0x58/0x188\n\t do_el0_svc+0x34/0x50\n\t el0_svc+0x34/0x108\n\t el0t_64_sync_handler+0xb8/0xc0\n\t el0t_64_sync+0x1a4/0x1a8\r\n\r\n\u0026apos;rb-\u0026gt;aux_pages\u0026apos; allocated by kcalloc() is a pointer array which is used to\nmaintains AUX trace pages. The allocated page for this array is physically\ncontiguous (and virtually contiguous) with an order of 0..MAX_ORDER. If the\nsize of pointer array crosses the limitation set by MAX_ORDER, it reveals a\nWARNING.\r\n\r\nSo bail out early with -ENOMEM if the request AUX area is out of bound,\ne.g.:\r\n\r\n #perf record -C 0 -m ,4G -e arm_spe_0// -- sleep 1\n failed to mmap with 12 (Cannot allocate memory)(CVE-2023-52835)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nInput: synaptics-rmi4 - fix use after free in rmi_unregister_function()\r\n\r\nThe put_device() calls rmi_release_function() which frees \u0026quot;fn\u0026quot; so the\ndereference on the next line \u0026quot;fn-\u0026gt;num_of_irqs\u0026quot; is a use after free.\nMove the put_device() to the end to fix this.(CVE-2023-52840)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: bttv: fix use after free error due to btv-\u0026gt;timeout timer\r\n\r\nThere may be some a race condition between timer function\nbttv_irq_timeout and bttv_remove. The timer is setup in\nprobe and there is no timer_delete operation in remove\nfunction. When it hit kfree btv, the function might still be\ninvoked, which will cause use after free bug.\r\n\r\nThis bug is found by static analysis, it may be false positive.\r\n\r\nFix it by adding del_timer_sync invoking to the remove function.\r\n\r\ncpu0 cpu1\n bttv_probe\n -\u0026gt;timer_setup\n -\u0026gt;bttv_set_dma\n -\u0026gt;mod_timer;\nbttv_remove\n -\u0026gt;kfree(btv);\n -\u0026gt;bttv_irq_timeout\n -\u0026gt;USE btv(CVE-2023-52847)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/radeon: possible buffer overflow\r\n\r\nBuffer \u0026apos;afmt_status\u0026apos; of size 6 could overflow, since index \u0026apos;afmt_idx\u0026apos; is\nchecked after access.(CVE-2023-52867)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nthermal: core: prevent potential string overflow\r\n\r\nThe dev-\u0026gt;id value comes from ida_alloc() so it\u0026apos;s a number between zero\nand INT_MAX. If it\u0026apos;s too high then these sprintf()s will overflow.(CVE-2023-52868)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: prevent kernel bug at submit_bh_wbc()\r\n\r\nFix a bug where nilfs_get_block() returns a successful status when\nsearching and inserting the specified block both fail inconsistently. If\nthis inconsistent behavior is not due to a previously fixed bug, then an\nunexpected race is occurring, so return a temporary error -EAGAIN instead.\r\n\r\nThis prevents callers such as __block_write_begin_int() from requesting a\nread into a buffer that is not mapped, which would cause the BUG_ON check\nfor the BH_Mapped flag in submit_bh_wbc() to fail.(CVE-2024-26955)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: fix failure to detect DAT corruption in btree and direct mappings\r\n\r\nPatch series \u0026quot;nilfs2: fix kernel bug at submit_bh_wbc()\u0026quot;.\r\n\r\nThis resolves a kernel BUG reported by syzbot. Since there are two\nflaws involved, I\u0026apos;ve made each one a separate patch.\r\n\r\nThe first patch alone resolves the syzbot-reported bug, but I think\nboth fixes should be sent to stable, so I\u0026apos;ve tagged them as such.\r\n\r\n\nThis patch (of 2):\r\n\r\nSyzbot has reported a kernel bug in submit_bh_wbc() when writing file data\nto a nilfs2 file system whose metadata is corrupted.\r\n\r\nThere are two flaws involved in this issue.\r\n\r\nThe first flaw is that when nilfs_get_block() locates a data block using\nbtree or direct mapping, if the disk address translation routine\nnilfs_dat_translate() fails with internal code -ENOENT due to DAT metadata\ncorruption, it can be passed back to nilfs_get_block(). This causes\nnilfs_get_block() to misidentify an existing block as non-existent,\ncausing both data block lookup and insertion to fail inconsistently.\r\n\r\nThe second flaw is that nilfs_get_block() returns a successful status in\nthis inconsistent state. This causes the caller __block_write_begin_int()\nor others to request a read even though the buffer is not mapped,\nresulting in a BUG_ON check for the BH_Mapped flag in submit_bh_wbc()\nfailing.\r\n\r\nThis fixes the first issue by changing the return value to code -EINVAL\nwhen a conversion using DAT fails with code -ENOENT, avoiding the\nconflicting condition that leads to the kernel bug described above. Here,\ncode -EINVAL indicates that metadata corruption was detected during the\nblock lookup, which will be properly handled as a file system error and\nconverted to -EIO when passing through the nilfs2 bmap layer.(CVE-2024-26956)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ns390/zcrypt: fix reference counting on zcrypt card objects\r\n\r\nTests with hot-plugging crytpo cards on KVM guests with debug\nkernel build revealed an use after free for the load field of\nthe struct zcrypt_card. The reason was an incorrect reference\nhandling of the zcrypt card object which could lead to a free\nof the zcrypt card object while it was still in use.\r\n\r\nThis is an example of the slab message:\r\n\r\n kernel: 0x00000000885a7512-0x00000000885a7513 @offset=1298. First byte 0x68 instead of 0x6b\n kernel: Allocated in zcrypt_card_alloc+0x36/0x70 [zcrypt] age=18046 cpu=3 pid=43\n kernel: kmalloc_trace+0x3f2/0x470\n kernel: zcrypt_card_alloc+0x36/0x70 [zcrypt]\n kernel: zcrypt_cex4_card_probe+0x26/0x380 [zcrypt_cex4]\n kernel: ap_device_probe+0x15c/0x290\n kernel: really_probe+0xd2/0x468\n kernel: driver_probe_device+0x40/0xf0\n kernel: __device_attach_driver+0xc0/0x140\n kernel: bus_for_each_drv+0x8c/0xd0\n kernel: __device_attach+0x114/0x198\n kernel: bus_probe_device+0xb4/0xc8\n kernel: device_add+0x4d2/0x6e0\n kernel: ap_scan_adapter+0x3d0/0x7c0\n kernel: ap_scan_bus+0x5a/0x3b0\n kernel: ap_scan_bus_wq_callback+0x40/0x60\n kernel: process_one_work+0x26e/0x620\n kernel: worker_thread+0x21c/0x440\n kernel: Freed in zcrypt_card_put+0x54/0x80 [zcrypt] age=9024 cpu=3 pid=43\n kernel: kfree+0x37e/0x418\n kernel: zcrypt_card_put+0x54/0x80 [zcrypt]\n kernel: ap_device_remove+0x4c/0xe0\n kernel: device_release_driver_internal+0x1c4/0x270\n kernel: bus_remove_device+0x100/0x188\n kernel: device_del+0x164/0x3c0\n kernel: device_unregister+0x30/0x90\n kernel: ap_scan_adapter+0xc8/0x7c0\n kernel: ap_scan_bus+0x5a/0x3b0\n kernel: ap_scan_bus_wq_callback+0x40/0x60\n kernel: process_one_work+0x26e/0x620\n kernel: worker_thread+0x21c/0x440\n kernel: kthread+0x150/0x168\n kernel: __ret_from_fork+0x3c/0x58\n kernel: ret_from_fork+0xa/0x30\n kernel: Slab 0x00000372022169c0 objects=20 used=18 fp=0x00000000885a7c88 flags=0x3ffff00000000a00(workingset|slab|node=0|zone=1|lastcpupid=0x1ffff)\n kernel: Object 0x00000000885a74b8 @offset=1208 fp=0x00000000885a7c88\n kernel: Redzone 00000000885a74b0: bb bb bb bb bb bb bb bb ........\n kernel: Object 00000000885a74b8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk\n kernel: Object 00000000885a74c8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk\n kernel: Object 00000000885a74d8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk\n kernel: Object 00000000885a74e8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk\n kernel: Object 00000000885a74f8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk\n kernel: Object 00000000885a7508: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 68 4b 6b 6b 6b a5 kkkkkkkkkkhKkkk.\n kernel: Redzone 00000000885a7518: bb bb bb bb bb bb bb bb ........\n kernel: Padding 00000000885a756c: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZ\n kernel: CPU: 0 PID: 387 Comm: systemd-udevd Not tainted 6.8.0-HF #2\n kernel: Hardware name: IBM 3931 A01 704 (KVM/Linux)\n kernel: Call Trace:\n kernel: [\u0026lt;00000000ca5ab5b8\u0026gt;] dump_stack_lvl+0x90/0x120\n kernel: [\u0026lt;00000000c99d78bc\u0026gt;] check_bytes_and_report+0x114/0x140\n kernel: [\u0026lt;00000000c99d53cc\u0026gt;] check_object+0x334/0x3f8\n kernel: [\u0026lt;00000000c99d820c\u0026gt;] alloc_debug_processing+0xc4/0x1f8\n kernel: [\u0026lt;00000000c99d852e\u0026gt;] get_partial_node.part.0+0x1ee/0x3e0\n kernel: [\u0026lt;00000000c99d94ec\u0026gt;] ___slab_alloc+0xaf4/0x13c8\n kernel: [\u0026lt;00000000c99d9e38\u0026gt;] __slab_alloc.constprop.0+0x78/0xb8\n kernel: [\u0026lt;00000000c99dc8dc\u0026gt;] __kmalloc+0x434/0x590\n kernel: [\u0026lt;00000000c9b4c0ce\u0026gt;] ext4_htree_store_dirent+0x4e/0x1c0\n kernel: [\u0026lt;00000000c9b908a2\u0026gt;] htree_dirblock_to_tree+0x17a/0x3f0\n kernel: \n---truncated---(CVE-2024-26957)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnfs: fix UAF in direct writes\r\n\r\nIn production we have been hitting the following warning consistently\r\n\r\n------------[ cut here ]------------\nrefcount_t: underflow; use-after-free.\nWARNING: CPU: 17 PID: 1800359 at lib/refcount.c:28 refcount_warn_saturate+0x9c/0xe0\nWorkqueue: nfsiod nfs_direct_write_schedule_work [nfs]\nRIP: 0010:refcount_warn_saturate+0x9c/0xe0\nPKRU: 55555554\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? __warn+0x9f/0x130\n ? refcount_warn_saturate+0x9c/0xe0\n ? report_bug+0xcc/0x150\n ? handle_bug+0x3d/0x70\n ? exc_invalid_op+0x16/0x40\n ? asm_exc_invalid_op+0x16/0x20\n ? refcount_warn_saturate+0x9c/0xe0\n nfs_direct_write_schedule_work+0x237/0x250 [nfs]\n process_one_work+0x12f/0x4a0\n worker_thread+0x14e/0x3b0\n ? ZSTD_getCParams_internal+0x220/0x220\n kthread+0xdc/0x120\n ? __btf_name_valid+0xa0/0xa0\n ret_from_fork+0x1f/0x30\r\n\r\nThis is because we\u0026apos;re completing the nfs_direct_request twice in a row.\r\n\r\nThe source of this is when we have our commit requests to submit, we\nprocess them and send them off, and then in the completion path for the\ncommit requests we have\r\n\r\nif (nfs_commit_end(cinfo.mds))\n\tnfs_direct_write_complete(dreq);\r\n\r\nHowever since we\u0026apos;re submitting asynchronous requests we sometimes have\none that completes before we submit the next one, so we end up calling\ncomplete on the nfs_direct_request twice.\r\n\r\nThe only other place we use nfs_generic_commit_list() is in\n__nfs_commit_inode, which wraps this call in a\r\n\r\nnfs_commit_begin();\nnfs_commit_end();\r\n\r\nWhich is a common pattern for this style of completion handling, one\nthat is also repeated in the direct code with get_dreq()/put_dreq()\ncalls around where we process events as well as in the completion paths.\r\n\r\nFix this by using the same pattern for the commit requests.\r\n\r\nBefore with my 200 node rocksdb stress running this warning would pop\nevery 10ish minutes. With my patch the stress test has been running for\nseveral hours without popping.(CVE-2024-26958)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmm: swap: fix race between free_swap_and_cache() and swapoff()\r\n\r\nThere was previously a theoretical window where swapoff() could run and\nteardown a swap_info_struct while a call to free_swap_and_cache() was\nrunning in another thread. This could cause, amongst other bad\npossibilities, swap_page_trans_huge_swapped() (called by\nfree_swap_and_cache()) to access the freed memory for swap_map.\r\n\r\nThis is a theoretical problem and I haven\u0026apos;t been able to provoke it from a\ntest case. But there has been agreement based on code review that this is\npossible (see link below).\r\n\r\nFix it by using get_swap_device()/put_swap_device(), which will stall\nswapoff(). There was an extra check in _swap_info_get() to confirm that\nthe swap entry was not free. This isn\u0026apos;t present in get_swap_device()\nbecause it doesn\u0026apos;t make sense in general due to the race between getting\nthe reference and swapoff. So I\u0026apos;ve added an equivalent check directly in\nfree_swap_and_cache().\r\n\r\nDetails of how to provoke one possible issue (thanks to David Hildenbrand\nfor deriving this):\r\n\r\n--8\u0026lt;-----\r\n\r\n__swap_entry_free() might be the last user and result in\n\u0026quot;count == SWAP_HAS_CACHE\u0026quot;.\r\n\r\nswapoff-\u0026gt;try_to_unuse() will stop as soon as soon as si-\u0026gt;inuse_pages==0.\r\n\r\nSo the question is: could someone reclaim the folio and turn\nsi-\u0026gt;inuse_pages==0, before we completed swap_page_trans_huge_swapped().\r\n\r\nImagine the following: 2 MiB folio in the swapcache. Only 2 subpages are\nstill references by swap entries.\r\n\r\nProcess 1 still references subpage 0 via swap entry.\nProcess 2 still references subpage 1 via swap entry.\r\n\r\nProcess 1 quits. Calls free_swap_and_cache().\n-\u0026gt; count == SWAP_HAS_CACHE\n[then, preempted in the hypervisor etc.]\r\n\r\nProcess 2 quits. Calls free_swap_and_cache().\n-\u0026gt; count == SWAP_HAS_CACHE\r\n\r\nProcess 2 goes ahead, passes swap_page_trans_huge_swapped(), and calls\n__try_to_reclaim_swap().\r\n\r\n__try_to_reclaim_swap()-\u0026gt;folio_free_swap()-\u0026gt;delete_from_swap_cache()-\u0026gt;\nput_swap_folio()-\u0026gt;free_swap_slot()-\u0026gt;swapcache_free_entries()-\u0026gt;\nswap_entry_free()-\u0026gt;swap_range_free()-\u0026gt;\n...\nWRITE_ONCE(si-\u0026gt;inuse_pages, si-\u0026gt;inuse_pages - nr_entries);\r\n\r\nWhat stops swapoff to succeed after process 2 reclaimed the swap cache\nbut before process1 finished its call to swap_page_trans_huge_swapped()?\r\n\r\n--8\u0026lt;-----(CVE-2024-26960)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmac802154: fix llsec key resources release in mac802154_llsec_key_del\r\n\r\nmac802154_llsec_key_del() can free resources of a key directly without\nfollowing the RCU rules for waiting before the end of a grace period. This\nmay lead to use-after-free in case llsec_lookup_key() is traversing the\nlist of keys in parallel with a key deletion:\r\n\r\nrefcount_t: addition on 0; use-after-free.\nWARNING: CPU: 4 PID: 16000 at lib/refcount.c:25 refcount_warn_saturate+0x162/0x2a0\nModules linked in:\nCPU: 4 PID: 16000 Comm: wpan-ping Not tainted 6.7.0 #19\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014\nRIP: 0010:refcount_warn_saturate+0x162/0x2a0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n llsec_lookup_key.isra.0+0x890/0x9e0\n mac802154_llsec_encrypt+0x30c/0x9c0\n ieee802154_subif_start_xmit+0x24/0x1e0\n dev_hard_start_xmit+0x13e/0x690\n sch_direct_xmit+0x2ae/0xbc0\n __dev_queue_xmit+0x11dd/0x3c20\n dgram_sendmsg+0x90b/0xd60\n __sys_sendto+0x466/0x4c0\n __x64_sys_sendto+0xe0/0x1c0\n do_syscall_64+0x45/0xf0\n entry_SYSCALL_64_after_hwframe+0x6e/0x76\r\n\r\nAlso, ieee802154_llsec_key_entry structures are not freed by\nmac802154_llsec_key_del():\r\n\r\nunreferenced object 0xffff8880613b6980 (size 64):\n comm \u0026quot;iwpan\u0026quot;, pid 2176, jiffies 4294761134 (age 60.475s)\n hex dump (first 32 bytes):\n 78 0d 8f 18 80 88 ff ff 22 01 00 00 00 00 ad de x.......\u0026quot;.......\n 00 00 00 00 00 00 00 00 03 00 cd ab 00 00 00 00 ................\n backtrace:\n [\u0026lt;ffffffff81dcfa62\u0026gt;] __kmem_cache_alloc_node+0x1e2/0x2d0\n [\u0026lt;ffffffff81c43865\u0026gt;] kmalloc_trace+0x25/0xc0\n [\u0026lt;ffffffff88968b09\u0026gt;] mac802154_llsec_key_add+0xac9/0xcf0\n [\u0026lt;ffffffff8896e41a\u0026gt;] ieee802154_add_llsec_key+0x5a/0x80\n [\u0026lt;ffffffff8892adc6\u0026gt;] nl802154_add_llsec_key+0x426/0x5b0\n [\u0026lt;ffffffff86ff293e\u0026gt;] genl_family_rcv_msg_doit+0x1fe/0x2f0\n [\u0026lt;ffffffff86ff46d1\u0026gt;] genl_rcv_msg+0x531/0x7d0\n [\u0026lt;ffffffff86fee7a9\u0026gt;] netlink_rcv_skb+0x169/0x440\n [\u0026lt;ffffffff86ff1d88\u0026gt;] genl_rcv+0x28/0x40\n [\u0026lt;ffffffff86fec15c\u0026gt;] netlink_unicast+0x53c/0x820\n [\u0026lt;ffffffff86fecd8b\u0026gt;] netlink_sendmsg+0x93b/0xe60\n [\u0026lt;ffffffff86b91b35\u0026gt;] ____sys_sendmsg+0xac5/0xca0\n [\u0026lt;ffffffff86b9c3dd\u0026gt;] ___sys_sendmsg+0x11d/0x1c0\n [\u0026lt;ffffffff86b9c65a\u0026gt;] __sys_sendmsg+0xfa/0x1d0\n [\u0026lt;ffffffff88eadbf5\u0026gt;] do_syscall_64+0x45/0xf0\n [\u0026lt;ffffffff890000ea\u0026gt;] entry_SYSCALL_64_after_hwframe+0x6e/0x76\r\n\r\nHandle the proper resource release in the RCU callback function\nmac802154_llsec_key_del_rcu().\r\n\r\nNote that if llsec_lookup_key() finds a key, it gets a refcount via\nllsec_key_get() and locally copies key id from key_entry (which is a\nlist element). So it\u0026apos;s safe to call llsec_key_put() and free the list\nentry after the RCU grace period elapses.\r\n\r\nFound by Linux Verification Center (linuxtesting.org).(CVE-2024-26961)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nclk: qcom: mmcc-msm8974: fix terminating of frequency table arrays\r\n\r\nThe frequency table arrays are supposed to be terminated with an\nempty element. Add such entry to the end of the arrays where it\nis missing in order to avoid possible out-of-bound access when\nthe table is traversed by functions like qcom_find_freq() or\nqcom_find_freq_floor().\r\n\r\nOnly compile tested.(CVE-2024-26965)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nclk: qcom: mmcc-apq8084: fix terminating of frequency table arrays\r\n\r\nThe frequency table arrays are supposed to be terminated with an\nempty element. Add such entry to the end of the arrays where it\nis missing in order to avoid possible out-of-bound access when\nthe table is traversed by functions like qcom_find_freq() or\nqcom_find_freq_floor().\r\n\r\nOnly compile tested.(CVE-2024-26966)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nclk: qcom: gcc-ipq8074: fix terminating of frequency table arrays\r\n\r\nThe frequency table arrays are supposed to be terminated with an\nempty element. Add such entry to the end of the arrays where it\nis missing in order to avoid possible out-of-bound access when\nthe table is traversed by functions like qcom_find_freq() or\nqcom_find_freq_floor().\r\n\r\nOnly compile tested.(CVE-2024-26969)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncrypto: qat - resolve race condition during AER recovery\r\n\r\nDuring the PCI AER system\u0026apos;s error recovery process, the kernel driver\nmay encounter a race condition with freeing the reset_data structure\u0026apos;s\nmemory. If the device restart will take more than 10 seconds the function\nscheduling that restart will exit due to a timeout, and the reset_data\nstructure will be freed. However, this data structure is used for\ncompletion notification after the restart is completed, which leads\nto a UAF bug.\r\n\r\nThis results in a KFENCE bug notice.\r\n\r\n BUG: KFENCE: use-after-free read in adf_device_reset_worker+0x38/0xa0 [intel_qat]\n Use-after-free read at 0x00000000bc56fddf (in kfence-#142):\n adf_device_reset_worker+0x38/0xa0 [intel_qat]\n process_one_work+0x173/0x340\r\n\r\nTo resolve this race condition, the memory associated to the container\nof the work_struct is freed on the worker if the timeout expired,\notherwise on the function that schedules the worker.\nThe timeout detection can be done by checking if the caller is\nstill waiting for completion or not by using completion_done() function.(CVE-2024-26974)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nKVM: Always flush async #PF workqueue when vCPU is being destroyed\r\n\r\nAlways flush the per-vCPU async #PF workqueue when a vCPU is clearing its\ncompletion queue, e.g. when a VM and all its vCPUs is being destroyed.\nKVM must ensure that none of its workqueue callbacks is running when the\nlast reference to the KVM _module_ is put. Gifting a reference to the\nassociated VM prevents the workqueue callback from dereferencing freed\nvCPU/VM memory, but does not prevent the KVM module from being unloaded\nbefore the callback completes.\r\n\r\nDrop the misguided VM refcount gifting, as calling kvm_put_kvm() from\nasync_pf_execute() if kvm_put_kvm() flushes the async #PF workqueue will\nresult in deadlock. async_pf_execute() can\u0026apos;t return until kvm_put_kvm()\nfinishes, and kvm_put_kvm() can\u0026apos;t return until async_pf_execute() finishes:\r\n\r\n WARNING: CPU: 8 PID: 251 at virt/kvm/kvm_main.c:1435 kvm_put_kvm+0x2d/0x320 [kvm]\n Modules linked in: vhost_net vhost vhost_iotlb tap kvm_intel kvm irqbypass\n CPU: 8 PID: 251 Comm: kworker/8:1 Tainted: G W 6.6.0-rc1-e7af8d17224a-x86/gmem-vm #119\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015\n Workqueue: events async_pf_execute [kvm]\n RIP: 0010:kvm_put_kvm+0x2d/0x320 [kvm]\n Call Trace:\n \u0026lt;TASK\u0026gt;\n async_pf_execute+0x198/0x260 [kvm]\n process_one_work+0x145/0x2d0\n worker_thread+0x27e/0x3a0\n kthread+0xba/0xe0\n ret_from_fork+0x2d/0x50\n ret_from_fork_asm+0x11/0x20\n \u0026lt;/TASK\u0026gt;\n ---[ end trace 0000000000000000 ]---\n INFO: task kworker/8:1:251 blocked for more than 120 seconds.\n Tainted: G W 6.6.0-rc1-e7af8d17224a-x86/gmem-vm #119\n \u0026quot;echo 0 \u0026gt; /proc/sys/kernel/hung_task_timeout_secs\u0026quot; disables this message.\n task:kworker/8:1 state:D stack:0 pid:251 ppid:2 flags:0x00004000\n Workqueue: events async_pf_execute [kvm]\n Call Trace:\n \u0026lt;TASK\u0026gt;\n __schedule+0x33f/0xa40\n schedule+0x53/0xc0\n schedule_timeout+0x12a/0x140\n __wait_for_common+0x8d/0x1d0\n __flush_work.isra.0+0x19f/0x2c0\n kvm_clear_async_pf_completion_queue+0x129/0x190 [kvm]\n kvm_arch_destroy_vm+0x78/0x1b0 [kvm]\n kvm_put_kvm+0x1c1/0x320 [kvm]\n async_pf_execute+0x198/0x260 [kvm]\n process_one_work+0x145/0x2d0\n worker_thread+0x27e/0x3a0\n kthread+0xba/0xe0\n ret_from_fork+0x2d/0x50\n ret_from_fork_asm+0x11/0x20\n \u0026lt;/TASK\u0026gt;\r\n\r\nIf kvm_clear_async_pf_completion_queue() actually flushes the workqueue,\nthen there\u0026apos;s no need to gift async_pf_execute() a reference because all\ninvocations of async_pf_execute() will be forced to complete before the\nvCPU and its VM are destroyed/freed. And that in turn fixes the module\nunloading bug as __fput() won\u0026apos;t do module_put() on the last vCPU reference\nuntil the vCPU has been freed, e.g. if closing the vCPU file also puts the\nlast reference to the KVM module.\r\n\r\nNote that kvm_check_async_pf_completion() may also take the work item off\nthe completion queue and so also needs to flush the work queue, as the\nwork will not be seen by kvm_clear_async_pf_completion_queue(). Waiting\non the workqueue could theoretically delay a vCPU due to waiting for the\nwork to complete, but that\u0026apos;s a very, very small chance, and likely a very\nsmall delay. kvm_arch_async_page_present_queued() unconditionally makes a\nnew request, i.e. will effectively delay entering the guest, so the\nremaining work is really just:\r\n\r\n trace_kvm_async_pf_completed(addr, cr2_or_gpa);\r\n\r\n __kvm_vcpu_wake_up(vcpu);\r\n\r\n mmput(mm);\r\n\r\nand mmput() can\u0026apos;t drop the last reference to the page tables if the vCPU is\nstill alive, i.e. the vCPU won\u0026apos;t get stuck tearing down page tables.\r\n\r\nAdd a helper to do the flushing, specifically to deal with \u0026quot;wakeup all\u0026quot;\nwork items, as they aren\u0026apos;t actually work items, i.e. are never placed in a\nworkqueue. Trying to flush a bogus workqueue entry rightly makes\n__flush_work() complain (kudos to whoever added that sanity check).\r\n\r\nNote, commit 5f6de5cbebee (\u0026quot;KVM: Prevent module exit until al\n---truncated---(CVE-2024-26976)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: fix OOB in nilfs_set_de_type\r\n\r\nThe size of the nilfs_type_by_mode array in the fs/nilfs2/dir.c file is\ndefined as \u0026quot;S_IFMT \u0026gt;\u0026gt; S_SHIFT\u0026quot;, but the nilfs_set_de_type() function,\nwhich uses this array, specifies the index to read from the array in the\nsame way as \u0026quot;(mode \u0026amp; S_IFMT) \u0026gt;\u0026gt; S_SHIFT\u0026quot;.\r\n\r\nstatic void nilfs_set_de_type(struct nilfs_dir_entry *de, struct inode\n *inode)\n{\n\tumode_t mode = inode-\u0026gt;i_mode;\r\n\r\n\tde-\u0026gt;file_type = nilfs_type_by_mode[(mode \u0026amp; S_IFMT)\u0026gt;\u0026gt;S_SHIFT]; // oob\n}\r\n\r\nHowever, when the index is determined this way, an out-of-bounds (OOB)\nerror occurs by referring to an index that is 1 larger than the array size\nwhen the condition \u0026quot;mode \u0026amp; S_IFMT == S_IFMT\u0026quot; is satisfied. Therefore, a\npatch to resize the nilfs_type_by_mode array should be applied to prevent\nOOB errors.(CVE-2024-26981)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nSquashfs: check the inode number is not the invalid value of zero\r\n\r\nSyskiller has produced an out of bounds access in fill_meta_index().\r\n\r\nThat out of bounds access is ultimately caused because the inode\nhas an inode number with the invalid value of zero, which was not checked.\r\n\r\nThe reason this causes the out of bounds access is due to following\nsequence of events:\r\n\r\n1. Fill_meta_index() is called to allocate (via empty_meta_index())\n and fill a metadata index. It however suffers a data read error\n and aborts, invalidating the newly returned empty metadata index.\n It does this by setting the inode number of the index to zero,\n which means unused (zero is not a valid inode number).\r\n\r\n2. When fill_meta_index() is subsequently called again on another\n read operation, locate_meta_index() returns the previous index\n because it matches the inode number of 0. Because this index\n has been returned it is expected to have been filled, and because\n it hasn\u0026apos;t been, an out of bounds access is performed.\r\n\r\nThis patch adds a sanity check which checks that the inode number\nis not zero when the inode is created and returns -EINVAL if it is.\r\n\r\n[phillip@squashfs.org.uk: whitespace fix]\n Link: https://lkml.kernel.org/r/20240409204723.446925-1-phillip@squashfs.org.uk(CVE-2024-26982)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfs: sysfs: Fix reference leak in sysfs_break_active_protection()\r\n\r\nThe sysfs_break_active_protection() routine has an obvious reference\nleak in its error path. If the call to kernfs_find_and_get() fails then\nkn will be NULL, so the companion sysfs_unbreak_active_protection()\nroutine won\u0026apos;t get called (and would only cause an access violation by\ntrying to dereference kn-\u0026gt;parent if it was called). As a result, the\nreference to kobj acquired at the start of the function will never be\nreleased.\r\n\r\nFix the leak by adding an explicit kobject_put() call when kn is NULL.(CVE-2024-26993)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nspeakup: Avoid crash on very long word\r\n\r\nIn case a console is set up really large and contains a really long word\n(\u0026gt; 256 characters), we have to stop before the length of the word buffer.(CVE-2024-26994)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: gadget: f_ncm: Fix UAF ncm object at re-bind after usb ep transport error\r\n\r\nWhen ncm function is working and then stop usb0 interface for link down,\neth_stop() is called. At this piont, accidentally if usb transport error\nshould happen in usb_ep_enable(), \u0026apos;in_ep\u0026apos; and/or \u0026apos;out_ep\u0026apos; may not be enabled.\r\n\r\nAfter that, ncm_disable() is called to disable for ncm unbind\nbut gether_disconnect() is never called since \u0026apos;in_ep\u0026apos; is not enabled.\r\n\r\nAs the result, ncm object is released in ncm unbind\nbut \u0026apos;dev-\u0026gt;port_usb\u0026apos; associated to \u0026apos;ncm-\u0026gt;port\u0026apos; is not NULL.\r\n\r\nAnd when ncm bind again to recover netdev, ncm object is reallocated\nbut usb0 interface is already associated to previous released ncm object.\r\n\r\nTherefore, once usb0 interface is up and eth_start_xmit() is called,\nreleased ncm object is dereferrenced and it might cause use-after-free memory.\r\n\r\n[function unlink via configfs]\n usb0: eth_stop dev-\u0026gt;port_usb=ffffff9b179c3200\n --\u0026gt; error happens in usb_ep_enable().\n NCM: ncm_disable: ncm=ffffff9b179c3200\n --\u0026gt; no gether_disconnect() since ncm-\u0026gt;port.in_ep-\u0026gt;enabled is false.\n NCM: ncm_unbind: ncm unbind ncm=ffffff9b179c3200\n NCM: ncm_free: ncm free ncm=ffffff9b179c3200 \u0026lt;-- released ncm\r\n\r\n[function link via configfs]\n NCM: ncm_alloc: ncm alloc ncm=ffffff9ac4f8a000\n NCM: ncm_bind: ncm bind ncm=ffffff9ac4f8a000\n NCM: ncm_set_alt: ncm=ffffff9ac4f8a000 alt=0\n usb0: eth_open dev-\u0026gt;port_usb=ffffff9b179c3200 \u0026lt;-- previous released ncm\n usb0: eth_start dev-\u0026gt;port_usb=ffffff9b179c3200 \u0026lt;--\n eth_start_xmit()\n --\u0026gt; dev-\u0026gt;wrap()\n Unable to handle kernel paging request at virtual address dead00000000014f\r\n\r\nThis patch addresses the issue by checking if \u0026apos;ncm-\u0026gt;netdev\u0026apos; is not NULL at\nncm_disable() to call gether_disconnect() to deassociate \u0026apos;dev-\u0026gt;port_usb\u0026apos;.\nIt\u0026apos;s more reasonable to check \u0026apos;ncm-\u0026gt;netdev\u0026apos; to call gether_connect/disconnect\nrather than check \u0026apos;ncm-\u0026gt;port.in_ep-\u0026gt;enabled\u0026apos; since it might not be enabled\nbut the gether connection might be established.(CVE-2024-26996)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nserial/pmac_zilog: Remove flawed mitigation for rx irq flood\r\n\r\nThe mitigation was intended to stop the irq completely. That may be\nbetter than a hard lock-up but it turns out that you get a crash anyway\nif you\u0026apos;re using pmac_zilog as a serial console:\r\n\r\nttyPZ0: pmz: rx irq flood !\nBUG: spinlock recursion on CPU#0, swapper/0\r\n\r\nThat\u0026apos;s because the pr_err() call in pmz_receive_chars() results in\npmz_console_write() attempting to lock a spinlock already locked in\npmz_interrupt(). With CONFIG_DEBUG_SPINLOCK=y, this produces a fatal\nBUG splat. The spinlock in question is the one in struct uart_port.\r\n\r\nEven when it\u0026apos;s not fatal, the serial port rx function ceases to work.\nAlso, the iteration limit doesn\u0026apos;t play nicely with QEMU, as can be\nseen in the bug report linked below.\r\n\r\nA web search for other reports of the error message \u0026quot;pmz: rx irq flood\u0026quot;\ndidn\u0026apos;t produce anything. So I don\u0026apos;t think this code is needed any more.\nRemove it.(CVE-2024-26999)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nserial: mxs-auart: add spinlock around changing cts state\r\n\r\nThe uart_handle_cts_change() function in serial_core expects the caller\nto hold uport-\u0026gt;lock. For example, I have seen the below kernel splat,\nwhen the Bluetooth driver is loaded on an i.MX28 board.\r\n\r\n [ 85.119255] ------------[ cut here ]------------\n [ 85.124413] WARNING: CPU: 0 PID: 27 at /drivers/tty/serial/serial_core.c:3453 uart_handle_cts_change+0xb4/0xec\n [ 85.134694] Modules linked in: hci_uart bluetooth ecdh_generic ecc wlcore_sdio configfs\n [ 85.143314] CPU: 0 PID: 27 Comm: kworker/u3:0 Not tainted 6.6.3-00021-gd62a2f068f92 #1\n [ 85.151396] Hardware name: Freescale MXS (Device Tree)\n [ 85.156679] Workqueue: hci0 hci_power_on [bluetooth]\n (...)\n [ 85.191765] uart_handle_cts_change from mxs_auart_irq_handle+0x380/0x3f4\n [ 85.198787] mxs_auart_irq_handle from __handle_irq_event_percpu+0x88/0x210\n (...)(CVE-2024-27000)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncomedi: vmk80xx: fix incomplete endpoint checking\r\n\r\nWhile vmk80xx does have endpoint checking implemented, some things\ncan fall through the cracks. Depending on the hardware model,\nURBs can have either bulk or interrupt type, and current version\nof vmk80xx_find_usb_endpoints() function does not take that fully\ninto account. While this warning does not seem to be too harmful,\nat the very least it will crash systems with \u0026apos;panic_on_warn\u0026apos; set on\nthem.\r\n\r\nFix the issue found by Syzkaller [1] by somewhat simplifying the\nendpoint checking process with usb_find_common_endpoints() and\nensuring that only expected endpoint types are present.\r\n\r\nThis patch has not been tested on real hardware.\r\n\r\n[1] Syzkaller report:\nusb 1-1: BOGUS urb xfer, pipe 1 != type 3\nWARNING: CPU: 0 PID: 781 at drivers/usb/core/urb.c:504 usb_submit_urb+0xc4e/0x18c0 drivers/usb/core/urb.c:503\n...\nCall Trace:\n \u0026lt;TASK\u0026gt;\n usb_start_wait_urb+0x113/0x520 drivers/usb/core/message.c:59\n vmk80xx_reset_device drivers/comedi/drivers/vmk80xx.c:227 [inline]\n vmk80xx_auto_attach+0xa1c/0x1a40 drivers/comedi/drivers/vmk80xx.c:818\n comedi_auto_config+0x238/0x380 drivers/comedi/drivers.c:1067\n usb_probe_interface+0x5cd/0xb00 drivers/usb/core/driver.c:399\n...\r\n\r\nSimilar issue also found by Syzkaller:(CVE-2024-27001)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm: nv04: Fix out of bounds access\r\n\r\nWhen Output Resource (dcb-\u0026gt;or) value is assigned in\nfabricate_dcb_output(), there may be out of bounds access to\ndac_users array in case dcb-\u0026gt;or is zero because ffs(dcb-\u0026gt;or) is\nused as index there.\nThe \u0026apos;or\u0026apos; argument of fabricate_dcb_output() must be interpreted as a\nnumber of bit to set, not value.\r\n\r\nUtilize macros from \u0026apos;enum nouveau_or\u0026apos; in calls instead of hardcoding.\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-27008)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/sched: Fix mirred deadlock on device recursion\r\n\r\nWhen the mirred action is used on a classful egress qdisc and a packet is\nmirrored or redirected to self we hit a qdisc lock deadlock.\nSee trace below.\r\n\r\n[..... other info removed for brevity....]\n[ 82.890906]\n[ 82.890906] ============================================\n[ 82.890906] WARNING: possible recursive locking detected\n[ 82.890906] 6.8.0-05205-g77fadd89fe2d-dirty #213 Tainted: G W\n[ 82.890906] --------------------------------------------\n[ 82.890906] ping/418 is trying to acquire lock:\n[ 82.890906] ffff888006994110 (\u0026amp;sch-\u0026gt;q.lock){+.-.}-{3:3}, at:\n__dev_queue_xmit+0x1778/0x3550\n[ 82.890906]\n[ 82.890906] but task is already holding lock:\n[ 82.890906] ffff888006994110 (\u0026amp;sch-\u0026gt;q.lock){+.-.}-{3:3}, at:\n__dev_queue_xmit+0x1778/0x3550\n[ 82.890906]\n[ 82.890906] other info that might help us debug this:\n[ 82.890906] Possible unsafe locking scenario:\n[ 82.890906]\n[ 82.890906] CPU0\n[ 82.890906] ----\n[ 82.890906] lock(\u0026amp;sch-\u0026gt;q.lock);\n[ 82.890906] lock(\u0026amp;sch-\u0026gt;q.lock);\n[ 82.890906]\n[ 82.890906] *** DEADLOCK ***\n[ 82.890906]\n[..... other info removed for brevity....]\r\n\r\nExample setup (eth0-\u0026gt;eth0) to recreate\ntc qdisc add dev eth0 root handle 1: htb default 30\ntc filter add dev eth0 handle 1: protocol ip prio 2 matchall \\\n action mirred egress redirect dev eth0\r\n\r\nAnother example(eth0-\u0026gt;eth1-\u0026gt;eth0) to recreate\ntc qdisc add dev eth0 root handle 1: htb default 30\ntc filter add dev eth0 handle 1: protocol ip prio 2 matchall \\\n action mirred egress redirect dev eth1\r\n\r\ntc qdisc add dev eth1 root handle 1: htb default 30\ntc filter add dev eth1 handle 1: protocol ip prio 2 matchall \\\n action mirred egress redirect dev eth0\r\n\r\nWe fix this by adding an owner field (CPU id) to struct Qdisc set after\nroot qdisc is entered. When the softirq enters it a second time, if the\nqdisc owner is the same CPU, the packet is dropped to break the loop.(CVE-2024-27010)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nf_tables: fix memleak in map from abort path\r\n\r\nThe delete set command does not rely on the transaction object for\nelement removal, therefore, a combination of delete element + delete set\nfrom the abort path could result in restoring twice the refcount of the\nmapping.\r\n\r\nCheck for inactive element in the next generation for the delete element\ncommand in the abort path, skip restoring state if next generation bit\nhas been already cleared. This is similar to the activate logic using\nthe set walk iterator.\r\n\r\n[ 6170.286929] ------------[ cut here ]------------\n[ 6170.286939] WARNING: CPU: 6 PID: 790302 at net/netfilter/nf_tables_api.c:2086 nf_tables_chain_destroy+0x1f7/0x220 [nf_tables]\n[ 6170.287071] Modules linked in: [...]\n[ 6170.287633] CPU: 6 PID: 790302 Comm: kworker/6:2 Not tainted 6.9.0-rc3+ #365\n[ 6170.287768] RIP: 0010:nf_tables_chain_destroy+0x1f7/0x220 [nf_tables]\n[ 6170.287886] Code: df 48 8d 7d 58 e8 69 2e 3b df 48 8b 7d 58 e8 80 1b 37 df 48 8d 7d 68 e8 57 2e 3b df 48 8b 7d 68 e8 6e 1b 37 df 48 89 ef eb c4 \u0026lt;0f\u0026gt; 0b 48 83 c4 08 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 0f\n[ 6170.287895] RSP: 0018:ffff888134b8fd08 EFLAGS: 00010202\n[ 6170.287904] RAX: 0000000000000001 RBX: ffff888125bffb28 RCX: dffffc0000000000\n[ 6170.287912] RDX: 0000000000000003 RSI: ffffffffa20298ab RDI: ffff88811ebe4750\n[ 6170.287919] RBP: ffff88811ebe4700 R08: ffff88838e812650 R09: fffffbfff0623a55\n[ 6170.287926] R10: ffffffff8311d2af R11: 0000000000000001 R12: ffff888125bffb10\n[ 6170.287933] R13: ffff888125bffb10 R14: dead000000000122 R15: dead000000000100\n[ 6170.287940] FS: 0000000000000000(0000) GS:ffff888390b00000(0000) knlGS:0000000000000000\n[ 6170.287948] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 6170.287955] CR2: 00007fd31fc00710 CR3: 0000000133f60004 CR4: 00000000001706f0\n[ 6170.287962] Call Trace:\n[ 6170.287967] \u0026lt;TASK\u0026gt;\n[ 6170.287973] ? __warn+0x9f/0x1a0\n[ 6170.287986] ? nf_tables_chain_destroy+0x1f7/0x220 [nf_tables]\n[ 6170.288092] ? report_bug+0x1b1/0x1e0\n[ 6170.287986] ? nf_tables_chain_destroy+0x1f7/0x220 [nf_tables]\n[ 6170.288092] ? report_bug+0x1b1/0x1e0\n[ 6170.288104] ? handle_bug+0x3c/0x70\n[ 6170.288112] ? exc_invalid_op+0x17/0x40\n[ 6170.288120] ? asm_exc_invalid_op+0x1a/0x20\n[ 6170.288132] ? nf_tables_chain_destroy+0x2b/0x220 [nf_tables]\n[ 6170.288243] ? nf_tables_chain_destroy+0x1f7/0x220 [nf_tables]\n[ 6170.288366] ? nf_tables_chain_destroy+0x2b/0x220 [nf_tables]\n[ 6170.288483] nf_tables_trans_destroy_work+0x588/0x590 [nf_tables](CVE-2024-27011)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/rds: fix WARNING in rds_conn_connect_if_down\r\n\r\nIf connection isn\u0026apos;t established yet, get_mr() will fail, trigger connection after\nget_mr().(CVE-2024-27024)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nspi: spi-mt65xx: Fix NULL pointer access in interrupt handler\r\n\r\nThe TX buffer in spi_transfer can be a NULL pointer, so the interrupt\nhandler may end up writing to the invalid memory and cause crashes.\r\n\r\nAdd a check to trans-\u0026gt;tx_buf before using it.(CVE-2024-27028)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nclk: zynq: Prevent null pointer dereference caused by kmalloc failure\r\n\r\nThe kmalloc() in zynq_clk_setup() will return null if the\nphysical memory has run out. As a result, if we use snprintf()\nto write data to the null address, the null pointer dereference\nbug will happen.\r\n\r\nThis patch uses a stack variable to replace the kmalloc().(CVE-2024-27037)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnfp: flower: handle acti_netdevs allocation failure\r\n\r\nThe kmalloc_array() in nfp_fl_lag_do_work() will return null, if\nthe physical memory has run out. As a result, if we dereference\nthe acti_netdevs, the null pointer dereference bugs will happen.\r\n\r\nThis patch adds a check to judge whether allocation failure occurs.\nIf it happens, the delayed work will be rescheduled and try again.(CVE-2024-27046)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncpufreq: brcmstb-avs-cpufreq: add check for cpufreq_cpu_get\u0026apos;s return value\r\n\r\ncpufreq_cpu_get may return NULL. To avoid NULL-dereference check it\nand return 0 in case of error.\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-27051)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ns390/dasd: fix double module refcount decrement\r\n\r\nOnce the discipline is associated with the device, deleting the device\ntakes care of decrementing the module\u0026apos;s refcount. Doing it manually on\nthis error path causes refcount to artificially decrease on each error\nwhile it should just stay the same.(CVE-2024-27054)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nUSB: usb-storage: Prevent divide-by-0 error in isd200_ata_command\r\n\r\nThe isd200 sub-driver in usb-storage uses the HEADS and SECTORS values\nin the ATA ID information to calculate cylinder and head values when\ncreating a CDB for READ or WRITE commands. The calculation involves\ndivision and modulus operations, which will cause a crash if either of\nthese values is 0. While this never happens with a genuine device, it\ncould happen with a flawed or subversive emulation, as reported by the\nsyzbot fuzzer.\r\n\r\nProtect against this possibility by refusing to bind to the device if\neither the ATA_ID_HEADS or ATA_ID_SECTORS value in the device\u0026apos;s ID\ninformation is 0. This requires isd200_Initialization() to return a\nnegative error code when initialization fails; currently it always\nreturns 0 (even when there is an error).(CVE-2024-27059)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnouveau: lock the client object tree.\r\n\r\nIt appears the client object tree has no locking unless I\u0026apos;ve missed\nsomething else. Fix races around adding/removing client objects,\nmostly vram bar mappings.\r\n\r\n 4562.099306] general protection fault, probably for non-canonical address 0x6677ed422bceb80c: 0000 [#1] PREEMPT SMP PTI\n[ 4562.099314] CPU: 2 PID: 23171 Comm: deqp-vk Not tainted 6.8.0-rc6+ #27\n[ 4562.099324] Hardware name: Gigabyte Technology Co., Ltd. Z390 I AORUS PRO WIFI/Z390 I AORUS PRO WIFI-CF, BIOS F8 11/05/2021\n[ 4562.099330] RIP: 0010:nvkm_object_search+0x1d/0x70 [nouveau]\n[ 4562.099503] Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 0f 1f 44 00 00 48 89 f8 48 85 f6 74 39 48 8b 87 a0 00 00 00 48 85 c0 74 12 \u0026lt;48\u0026gt; 8b 48 f8 48 39 ce 73 15 48 8b 40 10 48 85 c0 75 ee 48 c7 c0 fe\n[ 4562.099506] RSP: 0000:ffffa94cc420bbf8 EFLAGS: 00010206\n[ 4562.099512] RAX: 6677ed422bceb814 RBX: ffff98108791f400 RCX: ffff9810f26b8f58\n[ 4562.099517] RDX: 0000000000000000 RSI: ffff9810f26b9158 RDI: ffff98108791f400\n[ 4562.099519] RBP: ffff9810f26b9158 R08: 0000000000000000 R09: 0000000000000000\n[ 4562.099521] R10: ffffa94cc420bc48 R11: 0000000000000001 R12: ffff9810f02a7cc0\n[ 4562.099526] R13: 0000000000000000 R14: 00000000000000ff R15: 0000000000000007\n[ 4562.099528] FS: 00007f629c5017c0(0000) GS:ffff98142c700000(0000) knlGS:0000000000000000\n[ 4562.099534] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 4562.099536] CR2: 00007f629a882000 CR3: 000000017019e004 CR4: 00000000003706f0\n[ 4562.099541] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[ 4562.099542] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[ 4562.099544] Call Trace:\n[ 4562.099555] \u0026lt;TASK\u0026gt;\n[ 4562.099573] ? die_addr+0x36/0x90\n[ 4562.099583] ? exc_general_protection+0x246/0x4a0\n[ 4562.099593] ? asm_exc_general_protection+0x26/0x30\n[ 4562.099600] ? nvkm_object_search+0x1d/0x70 [nouveau]\n[ 4562.099730] nvkm_ioctl+0xa1/0x250 [nouveau]\n[ 4562.099861] nvif_object_map_handle+0xc8/0x180 [nouveau]\n[ 4562.099986] nouveau_ttm_io_mem_reserve+0x122/0x270 [nouveau]\n[ 4562.100156] ? dma_resv_test_signaled+0x26/0xb0\n[ 4562.100163] ttm_bo_vm_fault_reserved+0x97/0x3c0 [ttm]\n[ 4562.100182] ? __mutex_unlock_slowpath+0x2a/0x270\n[ 4562.100189] nouveau_ttm_fault+0x69/0xb0 [nouveau]\n[ 4562.100356] __do_fault+0x32/0x150\n[ 4562.100362] do_fault+0x7c/0x560\n[ 4562.100369] __handle_mm_fault+0x800/0xc10\n[ 4562.100382] handle_mm_fault+0x17c/0x3e0\n[ 4562.100388] do_user_addr_fault+0x208/0x860\n[ 4562.100395] exc_page_fault+0x7f/0x200\n[ 4562.100402] asm_exc_page_fault+0x26/0x30\n[ 4562.100412] RIP: 0033:0x9b9870\n[ 4562.100419] Code: 85 a8 f7 ff ff 8b 8d 80 f7 ff ff 89 08 e9 18 f2 ff ff 0f 1f 84 00 00 00 00 00 44 89 32 e9 90 fa ff ff 0f 1f 84 00 00 00 00 00 \u0026lt;44\u0026gt; 89 32 e9 f8 f1 ff ff 0f 1f 84 00 00 00 00 00 66 44 89 32 e9 e7\n[ 4562.100422] RSP: 002b:00007fff9ba2dc70 EFLAGS: 00010246\n[ 4562.100426] RAX: 0000000000000004 RBX: 000000000dd65e10 RCX: 000000fff0000000\n[ 4562.100428] RDX: 00007f629a882000 RSI: 00007f629a882000 RDI: 0000000000000066\n[ 4562.100432] RBP: 00007fff9ba2e570 R08: 0000000000000000 R09: 0000000123ddf000\n[ 4562.100434] R10: 0000000000000001 R11: 0000000000000246 R12: 000000007fffffff\n[ 4562.100436] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000\n[ 4562.100446] \u0026lt;/TASK\u0026gt;\n[ 4562.100448] Modules linked in: nf_conntrack_netbios_ns nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables libcrc32c nfnetlink cmac bnep sunrpc iwlmvm intel_rapl_msr intel_rapl_common snd_sof_pci_intel_cnl x86_pkg_temp_thermal intel_powerclamp snd_sof_intel_hda_common mac80211 coretemp snd_soc_acpi_intel_match kvm_intel snd_soc_acpi snd_soc_hdac_hda snd_sof_pci snd_sof_xtensa_dsp snd_sof_intel_hda_mlink \n---truncated---(CVE-2024-27062)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: usbtv: Remove useless locks in usbtv_video_free()\r\n\r\nRemove locks calls in usbtv_video_free() because\nare useless and may led to a deadlock as reported here:\nhttps://syzkaller.appspot.com/x/bisect.txt?x=166dc872180000\nAlso remove usbtv_stop() call since it will be called when\nunregistering the device.\r\n\r\nBefore \u0026apos;c838530d230b\u0026apos; this issue would only be noticed if you\ndisconnect while streaming and now it is noticeable even when\ndisconnecting while not streaming.\r\n\r\n\n[hverkuil: fix minor spelling mistake in log message](CVE-2024-27072)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: ttpci: fix two memleaks in budget_av_attach\r\n\r\nWhen saa7146_register_device and saa7146_vv_init fails, budget_av_attach\nshould free the resources it allocates, like the error-handling of\nttpci_budget_init does. Besides, there are two fixme comment refers to\nsuch deallocations.(CVE-2024-27073)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: dvb-frontends: avoid stack overflow warnings with clang\r\n\r\nA previous patch worked around a KASAN issue in stv0367, now a similar\nproblem showed up with clang:\r\n\r\ndrivers/media/dvb-frontends/stv0367.c:1222:12: error: stack frame size (3624) exceeds limit (2048) in \u0026apos;stv0367ter_set_frontend\u0026apos; [-Werror,-Wframe-larger-than]\n 1214 | static int stv0367ter_set_frontend(struct dvb_frontend *fe)\r\n\r\nRework the stv0367_writereg() function to be simpler and mark both\nregister access functions as noinline_for_stack so the temporary\ni2c_msg structures do not get duplicated on the stack when KASAN_STACK\nis enabled.(CVE-2024-27075)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: v4l2-mem2mem: fix a memleak in v4l2_m2m_register_entity\r\n\r\nThe entity-\u0026gt;name (i.e. name) is allocated in v4l2_m2m_register_entity\nbut isn\u0026apos;t freed in its following error-handling paths. This patch\nadds such deallocation to prevent memleak of entity-\u0026gt;name.(CVE-2024-27077)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: v4l2-tpg: fix some memleaks in tpg_alloc\r\n\r\nIn tpg_alloc, resources should be deallocated in each and every\nerror-handling paths, since they are allocated in for statements.\nOtherwise there would be memleaks because tpg_free is called only when\ntpg_alloc return 0.(CVE-2024-27078)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nSUNRPC: fix some memleaks in gssx_dec_option_array\r\n\r\nThe creds and oa-\u0026gt;data need to be freed in the error-handling paths after\ntheir allocation. So this patch add these deallocations in the\ncorresponding paths.(CVE-2024-27388)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nft_flow_offload: reset dst in route object after setting up flow\r\n\r\ndst is transferred to the flow object, route object does not own it\nanymore. Reset dst in route object, otherwise if flow_offload_add()\nfails, error path releases dst twice, leading to a refcount underflow.(CVE-2024-27403)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetrom: Fix data-races around sysctl_net_busy_read\r\n\r\nWe need to protect the reader reading the sysctl value because the\nvalue can be changed concurrently.(CVE-2024-27419)\r\n\r\nRejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2024-27426)\r\n\r\nRejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2024-27427)\r\n\r\nRejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2024-27428)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndm snapshot: fix lockup in dm_exception_table_exit\r\n\r\nThere was reported lockup when we exit a snapshot with many exceptions.\nFix this by adding \u0026quot;cond_resched\u0026quot; to the loop that frees the exceptions.(CVE-2024-35805)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsoc: fsl: qbman: Always disable interrupts when taking cgr_lock\r\n\r\nsmp_call_function_single disables IRQs when executing the callback. To\nprevent deadlocks, we must disable IRQs when taking cgr_lock elsewhere.\nThis is already done by qman_update_cgr and qman_delete_cgr; fix the\nother lockers.(CVE-2024-35806)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfs/aio: Check IOCB_AIO_RW before the struct aio_kiocb conversion\r\n\r\nThe first kiocb_set_cancel_fn() argument may point at a struct kiocb\nthat is not embedded inside struct aio_kiocb. With the current code,\ndepending on the compiler, the req-\u0026gt;ki_ctx read happens either before\nthe IOCB_AIO_RW test or after that test. Move the req-\u0026gt;ki_ctx read such\nthat it is guaranteed that the IOCB_AIO_RW test happens first.(CVE-2024-35815)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/mlx5e: fix a double-free in arfs_create_groups\r\n\r\nWhen `in` allocated by kvzalloc fails, arfs_create_groups will free\nft-\u0026gt;g and return an error. However, arfs_create_table, the only caller of\narfs_create_groups, will hold this error and call to\nmlx5e_destroy_flow_table, in which the ft-\u0026gt;g will be freed again.(CVE-2024-35835)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: fix information leak in btrfs_ioctl_logical_to_ino()\r\n\r\nSyzbot reported the following information leak for in\nbtrfs_ioctl_logical_to_ino():\r\n\r\n BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline]\n BUG: KMSAN: kernel-infoleak in _copy_to_user+0xbc/0x110 lib/usercopy.c:40\n instrument_copy_to_user include/linux/instrumented.h:114 [inline]\n _copy_to_user+0xbc/0x110 lib/usercopy.c:40\n copy_to_user include/linux/uaccess.h:191 [inline]\n btrfs_ioctl_logical_to_ino+0x440/0x750 fs/btrfs/ioctl.c:3499\n btrfs_ioctl+0x714/0x1260\n vfs_ioctl fs/ioctl.c:51 [inline]\n __do_sys_ioctl fs/ioctl.c:904 [inline]\n __se_sys_ioctl+0x261/0x450 fs/ioctl.c:890\n __x64_sys_ioctl+0x96/0xe0 fs/ioctl.c:890\n x64_sys_call+0x1883/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:17\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\r\n\r\n Uninit was created at:\n __kmalloc_large_node+0x231/0x370 mm/slub.c:3921\n __do_kmalloc_node mm/slub.c:3954 [inline]\n __kmalloc_node+0xb07/0x1060 mm/slub.c:3973\n kmalloc_node include/linux/slab.h:648 [inline]\n kvmalloc_node+0xc0/0x2d0 mm/util.c:634\n kvmalloc include/linux/slab.h:766 [inline]\n init_data_container+0x49/0x1e0 fs/btrfs/backref.c:2779\n btrfs_ioctl_logical_to_ino+0x17c/0x750 fs/btrfs/ioctl.c:3480\n btrfs_ioctl+0x714/0x1260\n vfs_ioctl fs/ioctl.c:51 [inline]\n __do_sys_ioctl fs/ioctl.c:904 [inline]\n __se_sys_ioctl+0x261/0x450 fs/ioctl.c:890\n __x64_sys_ioctl+0x96/0xe0 fs/ioctl.c:890\n x64_sys_call+0x1883/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:17\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\r\n\r\n Bytes 40-65535 of 65536 are uninitialized\n Memory access of size 65536 starts at ffff888045a40000\r\n\r\nThis happens, because we\u0026apos;re copying a \u0026apos;struct btrfs_data_container\u0026apos; back\nto user-space. This btrfs_data_container is allocated in\n\u0026apos;init_data_container()\u0026apos; via kvmalloc(), which does not zero-fill the\nmemory.\r\n\r\nFix this by using kvzalloc() which zeroes out the memory on allocation.(CVE-2024-35849)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nipv6: Fix infinite recursion in fib6_dump_done().\r\n\r\nsyzkaller reported infinite recursive calls of fib6_dump_done() during\nnetlink socket destruction. [1]\r\n\r\nFrom the log, syzkaller sent an AF_UNSPEC RTM_GETROUTE message, and then\nthe response was generated. The following recvmmsg() resumed the dump\nfor IPv6, but the first call of inet6_dump_fib() failed at kzalloc() due\nto the fault injection. [0]\r\n\r\n 12:01:34 executing program 3:\n r0 = socket$nl_route(0x10, 0x3, 0x0)\n sendmsg$nl_route(r0, ... snip ...)\n recvmmsg(r0, ... snip ...) (fail_nth: 8)\r\n\r\nHere, fib6_dump_done() was set to nlk_sk(sk)-\u0026gt;cb.done, and the next call\nof inet6_dump_fib() set it to nlk_sk(sk)-\u0026gt;cb.args[3]. syzkaller stopped\nreceiving the response halfway through, and finally netlink_sock_destruct()\ncalled nlk_sk(sk)-\u0026gt;cb.done().\r\n\r\nfib6_dump_done() calls fib6_dump_end() and nlk_sk(sk)-\u0026gt;cb.done() if it\nis still not NULL. fib6_dump_end() rewrites nlk_sk(sk)-\u0026gt;cb.done() by\nnlk_sk(sk)-\u0026gt;cb.args[3], but it has the same function, not NULL, calling\nitself recursively and hitting the stack guard page.\r\n\r\nTo avoid the issue, let\u0026apos;s set the destructor after kzalloc().\r\n\r\n[0]:\nFAULT_INJECTION: forcing a failure.\nname failslab, interval 1, probability 0, space 0, times 0\nCPU: 1 PID: 432110 Comm: syz-executor.3 Not tainted 6.8.0-12821-g537c2e91d354-dirty #11\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl (lib/dump_stack.c:117)\n should_fail_ex (lib/fault-inject.c:52 lib/fault-inject.c:153)\n should_failslab (mm/slub.c:3733)\n kmalloc_trace (mm/slub.c:3748 mm/slub.c:3827 mm/slub.c:3992)\n inet6_dump_fib (./include/linux/slab.h:628 ./include/linux/slab.h:749 net/ipv6/ip6_fib.c:662)\n rtnl_dump_all (net/core/rtnetlink.c:4029)\n netlink_dump (net/netlink/af_netlink.c:2269)\n netlink_recvmsg (net/netlink/af_netlink.c:1988)\n ____sys_recvmsg (net/socket.c:1046 net/socket.c:2801)\n ___sys_recvmsg (net/socket.c:2846)\n do_recvmmsg (net/socket.c:2943)\n __x64_sys_recvmmsg (net/socket.c:3041 net/socket.c:3034 net/socket.c:3034)\r\n\r\n[1]:\nBUG: TASK stack guard page was hit at 00000000f2fa9af1 (stack is 00000000b7912430..000000009a436beb)\nstack guard page: 0000 [#1] PREEMPT SMP KASAN\nCPU: 1 PID: 223719 Comm: kworker/1:3 Not tainted 6.8.0-12821-g537c2e91d354-dirty #11\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014\nWorkqueue: events netlink_sock_destruct_work\nRIP: 0010:fib6_dump_done (net/ipv6/ip6_fib.c:570)\nCode: 3c 24 e8 f3 e9 51 fd e9 28 fd ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 41 57 41 56 41 55 41 54 55 48 89 fd \u0026lt;53\u0026gt; 48 8d 5d 60 e8 b6 4d 07 fd 48 89 da 48 b8 00 00 00 00 00 fc ff\nRSP: 0018:ffffc9000d980000 EFLAGS: 00010293\nRAX: 0000000000000000 RBX: ffffffff84405990 RCX: ffffffff844059d3\nRDX: ffff8881028e0000 RSI: ffffffff84405ac2 RDI: ffff88810c02f358\nRBP: ffff88810c02f358 R08: 0000000000000007 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000224 R12: 0000000000000000\nR13: ffff888007c82c78 R14: ffff888007c82c68 R15: ffff888007c82c68\nFS: 0000000000000000(0000) GS:ffff88811b100000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: ffffc9000d97fff8 CR3: 0000000102309002 CR4: 0000000000770ef0\nPKRU: 55555554\nCall Trace:\n \u0026lt;#DF\u0026gt;\n \u0026lt;/#DF\u0026gt;\n \u0026lt;TASK\u0026gt;\n fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1))\n fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1))\n ...\n fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1))\n fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1))\n netlink_sock_destruct (net/netlink/af_netlink.c:401)\n __sk_destruct (net/core/sock.c:2177 (discriminator 2))\n sk_destruct (net/core/sock.c:2224)\n __sk_free (net/core/sock.c:2235)\n sk_free (net/core/sock.c:2246)\n process_one_work (kernel/workqueue.c:3259)\n worker_thread (kernel/workqueue.c:3329 kernel/workqueue.\n---truncated---(CVE-2024-35886)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nf_tables: Fix potential data-race in __nft_flowtable_type_get()\r\n\r\nnft_unregister_flowtable_type() within nf_flow_inet_module_exit() can\nconcurrent with __nft_flowtable_type_get() within nf_tables_newflowtable().\nAnd thhere is not any protection when iterate over nf_tables_flowtables\nlist in __nft_flowtable_type_get(). Therefore, there is pertential\ndata-race of nf_tables_flowtables list entry.\r\n\r\nUse list_for_each_entry_rcu() to iterate over nf_tables_flowtables list\nin __nft_flowtable_type_get(), and use rcu_read_lock() in the caller\nnft_flowtable_type_get() to protect the entire type query process.(CVE-2024-35898)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfbmon: prevent division by zero in fb_videomode_from_videomode()\r\n\r\nThe expression htotal * vtotal can have a zero value on\noverflow. It is necessary to prevent division by zero like in\nfb_var_to_videomode().\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with Svace.(CVE-2024-35922)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: lpfc: Fix possible memory leak in lpfc_rcv_padisc()\r\n\r\nThe call to lpfc_sli4_resume_rpi() in lpfc_rcv_padisc() may return an\nunsuccessful status. In such cases, the elsiocb is not issued, the\ncompletion is not called, and thus the elsiocb resource is leaked.\r\n\r\nCheck return value after calling lpfc_sli4_resume_rpi() and conditionally\nrelease the elsiocb resource.(CVE-2024-35930)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: handle chunk tree lookup error in btrfs_relocate_sys_chunks()\r\n\r\nThe unhandled case in btrfs_relocate_sys_chunks() loop is a corruption,\nas it could be caused only by two impossible conditions:\r\n\r\n- at first the search key is set up to look for a chunk tree item, with\n offset -1, this is an inexact search and the key-\u0026gt;offset will contain\n the correct offset upon a successful search, a valid chunk tree item\n cannot have an offset -1\r\n\r\n- after first successful search, the found_key corresponds to a chunk\n item, the offset is decremented by 1 before the next loop, it\u0026apos;s\n impossible to find a chunk item there due to alignment and size\n constraints(CVE-2024-35936)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/client: Fully protect modes[] with dev-\u0026gt;mode_config.mutex\r\n\r\nThe modes[] array contains pointers to modes on the connectors\u0026apos;\nmode lists, which are protected by dev-\u0026gt;mode_config.mutex.\nThus we need to extend modes[] the same protection or by the\ntime we use it the elements may already be pointing to\nfreed/reused memory.(CVE-2024-35950)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nxsk: validate user input for XDP_{UMEM|COMPLETION}_FILL_RING\r\n\r\nsyzbot reported an illegal copy in xsk_setsockopt() [1]\r\n\r\nMake sure to validate setsockopt() @optlen parameter.\r\n\r\n[1]\r\n\r\n BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline]\n BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline]\n BUG: KASAN: slab-out-of-bounds in xsk_setsockopt+0x909/0xa40 net/xdp/xsk.c:1420\nRead of size 4 at addr ffff888028c6cde3 by task syz-executor.0/7549\r\n\r\nCPU: 0 PID: 7549 Comm: syz-executor.0 Not tainted 6.8.0-syzkaller-08951-gfe46a7dd189e #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114\n print_address_description mm/kasan/report.c:377 [inline]\n print_report+0x169/0x550 mm/kasan/report.c:488\n kasan_report+0x143/0x180 mm/kasan/report.c:601\n copy_from_sockptr_offset include/linux/sockptr.h:49 [inline]\n copy_from_sockptr include/linux/sockptr.h:55 [inline]\n xsk_setsockopt+0x909/0xa40 net/xdp/xsk.c:1420\n do_sock_setsockopt+0x3af/0x720 net/socket.c:2311\n __sys_setsockopt+0x1ae/0x250 net/socket.c:2334\n __do_sys_setsockopt net/socket.c:2343 [inline]\n __se_sys_setsockopt net/socket.c:2340 [inline]\n __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340\n do_syscall_64+0xfb/0x240\n entry_SYSCALL_64_after_hwframe+0x6d/0x75\nRIP: 0033:0x7fb40587de69\nCode: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007fb40665a0c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000036\nRAX: ffffffffffffffda RBX: 00007fb4059abf80 RCX: 00007fb40587de69\nRDX: 0000000000000005 RSI: 000000000000011b RDI: 0000000000000006\nRBP: 00007fb4058ca47a R08: 0000000000000002 R09: 0000000000000000\nR10: 0000000020001980 R11: 0000000000000246 R12: 0000000000000000\nR13: 000000000000000b R14: 00007fb4059abf80 R15: 00007fff57ee4d08\n \u0026lt;/TASK\u0026gt;\r\n\r\nAllocated by task 7549:\n kasan_save_stack mm/kasan/common.c:47 [inline]\n kasan_save_track+0x3f/0x80 mm/kasan/common.c:68\n poison_kmalloc_redzone mm/kasan/common.c:370 [inline]\n __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:387\n kasan_kmalloc include/linux/kasan.h:211 [inline]\n __do_kmalloc_node mm/slub.c:3966 [inline]\n __kmalloc+0x233/0x4a0 mm/slub.c:3979\n kmalloc include/linux/slab.h:632 [inline]\n __cgroup_bpf_run_filter_setsockopt+0xd2f/0x1040 kernel/bpf/cgroup.c:1869\n do_sock_setsockopt+0x6b4/0x720 net/socket.c:2293\n __sys_setsockopt+0x1ae/0x250 net/socket.c:2334\n __do_sys_setsockopt net/socket.c:2343 [inline]\n __se_sys_setsockopt net/socket.c:2340 [inline]\n __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340\n do_syscall_64+0xfb/0x240\n entry_SYSCALL_64_after_hwframe+0x6d/0x75\r\n\r\nThe buggy address belongs to the object at ffff888028c6cde0\n which belongs to the cache kmalloc-8 of size 8\nThe buggy address is located 1 bytes to the right of\n allocated 2-byte region [ffff888028c6cde0, ffff888028c6cde2)\r\n\r\nThe buggy address belongs to the physical page:\npage:ffffea0000a31b00 refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888028c6c9c0 pfn:0x28c6c\nanon flags: 0xfff00000000800(slab|node=0|zone=1|lastcpupid=0x7ff)\npage_type: 0xffffffff()\nraw: 00fff00000000800 ffff888014c41280 0000000000000000 dead000000000001\nraw: ffff888028c6c9c0 0000000080800057 00000001ffffffff 0000000000000000\npage dumped because: kasan: bad access detected\npage_owner tracks the page as allocated\npage last allocated via order 0, migratetype Unmovable, gfp_mask 0x112cc0(GFP_USER|__GFP_NOWARN|__GFP_NORETRY), pid 6648, tgid 6644 (syz-executor.0), ts 133906047828, free_ts 133859922223\n set_page_owner include/linux/page_owner.h:31 [inline]\n post_alloc_hook+0x1ea/0x210 mm/page_alloc.c:1533\n prep_new_page mm/page_alloc.c:\n---truncated---(CVE-2024-35976)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nHID: i2c-hid: remove I2C_HID_READ_PENDING flag to prevent lock-up\r\n\r\nThe flag I2C_HID_READ_PENDING is used to serialize I2C operations.\nHowever, this is not necessary, because I2C core already has its own\nlocking for that.\r\n\r\nMore importantly, this flag can cause a lock-up: if the flag is set in\ni2c_hid_xfer() and an interrupt happens, the interrupt handler\n(i2c_hid_irq) will check this flag and return immediately without doing\nanything, then the interrupt handler will be invoked again in an\ninfinite loop.\r\n\r\nSince interrupt handler is an RT task, it takes over the CPU and the\nflag-clearing task never gets scheduled, thus we have a lock-up.\r\n\r\nDelete this unnecessary flag.(CVE-2024-35997)",
"id": "OESA-2024-1678",
"modified": "2026-08-06T11:07:08Z",
"published": "2024-05-31T11:07:08Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1678"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47269"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47284"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47335"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47393"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47455"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47473"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47497"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48695"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48697"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48702"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48704"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48710"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52650"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52652"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52653"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52656"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52683"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52685"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52691"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52698"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52817"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52818"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52835"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52840"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52847"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52867"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52868"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26955"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26956"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26957"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26958"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26960"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26961"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26965"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26966"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26969"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26974"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26976"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26981"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26982"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26993"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26994"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26996"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26999"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27000"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27001"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27008"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27010"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27011"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27024"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27028"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27037"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27046"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27051"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27054"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27059"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27062"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27072"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27073"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27075"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27077"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27078"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27388"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27403"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27419"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27426"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27427"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27428"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35805"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35806"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35815"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35835"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35849"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35886"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35898"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35922"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35930"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35936"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35950"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35976"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35997"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2021-47269",
"CVE-2021-47284",
"CVE-2021-47335",
"CVE-2021-47393",
"CVE-2021-47455",
"CVE-2021-47473",
"CVE-2021-47497",
"CVE-2022-48695",
"CVE-2022-48697",
"CVE-2022-48702",
"CVE-2022-48704",
"CVE-2022-48710",
"CVE-2023-52650",
"CVE-2023-52652",
"CVE-2023-52653",
"CVE-2023-52656",
"CVE-2023-52683",
"CVE-2023-52685",
"CVE-2023-52691",
"CVE-2023-52698",
"CVE-2023-52817",
"CVE-2023-52818",
"CVE-2023-52835",
"CVE-2023-52840",
"CVE-2023-52847",
"CVE-2023-52867",
"CVE-2023-52868",
"CVE-2024-26955",
"CVE-2024-26956",
"CVE-2024-26957",
"CVE-2024-26958",
"CVE-2024-26960",
"CVE-2024-26961",
"CVE-2024-26965",
"CVE-2024-26966",
"CVE-2024-26969",
"CVE-2024-26974",
"CVE-2024-26976",
"CVE-2024-26981",
"CVE-2024-26982",
"CVE-2024-26993",
"CVE-2024-26994",
"CVE-2024-26996",
"CVE-2024-26999",
"CVE-2024-27000",
"CVE-2024-27001",
"CVE-2024-27008",
"CVE-2024-27010",
"CVE-2024-27011",
"CVE-2024-27024",
"CVE-2024-27028",
"CVE-2024-27037",
"CVE-2024-27046",
"CVE-2024-27051",
"CVE-2024-27054",
"CVE-2024-27059",
"CVE-2024-27062",
"CVE-2024-27072",
"CVE-2024-27073",
"CVE-2024-27075",
"CVE-2024-27077",
"CVE-2024-27078",
"CVE-2024-27388",
"CVE-2024-27403",
"CVE-2024-27419",
"CVE-2024-27426",
"CVE-2024-27427",
"CVE-2024-27428",
"CVE-2024-35805",
"CVE-2024-35806",
"CVE-2024-35815",
"CVE-2024-35835",
"CVE-2024-35849",
"CVE-2024-35886",
"CVE-2024-35898",
"CVE-2024-35922",
"CVE-2024-35930",
"CVE-2024-35936",
"CVE-2024-35950",
"CVE-2024-35976",
"CVE-2024-35997"
]
}
OESA-2024-1737 (CVE-2021-47366)
Vulnerability from osv_openeuler – Published: 2024-06-21 11:07 – Updated: 2026-08-06 11:07 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
afs: Fix corruption in reads at fpos 2G-4G from an OpenAFS server
AFS-3 has two data fetch RPC variants, FS.FetchData and FS.FetchData64, and Linux's afs client switches between them when talking to a non-YFS server if the read size, the file position or the sum of the two have the upper 32 bits set of the 64-bit value.
This is a problem, however, since the file position and length fields of FS.FetchData are signed 32-bit values.
Fix this by capturing the capability bits obtained from the fileserver when it's sent an FS.GetCapabilities RPC, rather than just discarding them, and then picking out the VICED_CAPABILITY_64BITFILES flag. This can then be used to decide whether to use FS.FetchData or FS.FetchData64 - and also FS.StoreData or FS.StoreData64 - rather than using upper_32_bits() to switch on the parameter values.
This capabilities flag could also be used to limit the maximum size of the file, but all servers must be checked for that.
Note that the issue does not exist with FS.StoreData - that uses unsigned 32-bit values. It's also not a problem with Auristor servers as its YFS.FetchData64 op uses unsigned 64-bit values.
This can be tested by cloning a git repo through an OpenAFS client to an OpenAFS server and then doing "git status" on it from a Linux afs client1. Provided the clone has a pack file that's in the 2G-4G range, the git status will show errors like:
error: packfile .git/objects/pack/pack-5e813c51d12b6847bbc0fcd97c2bca66da50079c.pack does not match index
error: packfile .git/objects/pack/pack-5e813c51d12b6847bbc0fcd97c2bca66da50079c.pack does not match index
This can be observed in the server's FileLog with something like the following appearing:
Sun Aug 29 19:31:39 2021 SRXAFS_FetchData, Fid = 2303380852.491776.3263114, Host 192.168.11.201:7001, Id 1001 Sun Aug 29 19:31:39 2021 CheckRights: len=0, for host=192.168.11.201:7001 Sun Aug 29 19:31:39 2021 FetchData_RXStyle: Pos 18446744071815340032, Len 3154 Sun Aug 29 19:31:39 2021 FetchData_RXStyle: file size 2400758866 ... Sun Aug 29 19:31:40 2021 SRXAFS_FetchData returns 5
Note the file position of 18446744071815340032. This is the requested file position sign-extended.(CVE-2021-47366)
In the Linux kernel, the following vulnerability has been resolved:
net/smc: Fix possible access to freed memory in link clear
After modifying the QP to the Error state, all RX WR would be completed with WC in IB_WC_WR_FLUSH_ERR status. Current implementation does not wait for it is done, but destroy the QP and free the link group directly. So there is a risk that accessing the freed memory in tasklet context.
Here is a crash example:
BUG: unable to handle page fault for address: ffffffff8f220860 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD f7300e067 P4D f7300e067 PUD f7300f063 PMD 8c4e45063 PTE 800ffff08c9df060 Oops: 0002 [#1] SMP PTI CPU: 1 PID: 0 Comm: swapper/1 Kdump: loaded Tainted: G S OE 5.10.0-0607+ #23 Hardware name: Inspur NF5280M4/YZMB-00689-101, BIOS 4.1.20 07/09/2018 RIP: 0010:native_queued_spin_lock_slowpath+0x176/0x1b0 Code: f3 90 48 8b 32 48 85 f6 74 f6 eb d5 c1 ee 12 83 e0 03 83 ee 01 48 c1 e0 05 48 63 f6 48 05 00 c8 02 00 48 03 04 f5 00 09 98 8e <48> 89 10 8b 42 08 85 c0 75 09 f3 90 8b 42 08 85 c0 74 f7 48 8b 32 RSP: 0018:ffffb3b6c001ebd8 EFLAGS: 00010086 RAX: ffffffff8f220860 RBX: 0000000000000246 RCX: 0000000000080000 RDX: ffff91db1f86c800 RSI: 000000000000173c RDI: ffff91db62bace00 RBP: ffff91db62bacc00 R08: 0000000000000000 R09: c00000010000028b R10: 0000000000055198 R11: ffffb3b6c001ea58 R12: ffff91db80e05010 R13: 000000000000000a R14: 0000000000000006 R15: 0000000000000040 FS: 0000000000000000(0000) GS:ffff91db1f840000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffff8f220860 CR3: 00000001f9580004 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <IRQ> _raw_spin_lock_irqsave+0x30/0x40 mlx5_ib_poll_cq+0x4c/0xc50 [mlx5_ib] smc_wr_rx_tasklet_fn+0x56/0xa0 [smc] tasklet_action_common.isra.21+0x66/0x100 __do_softirq+0xd5/0x29c asm_call_irq_on_stack+0x12/0x20 </IRQ> do_softirq_own_stack+0x37/0x40 irq_exit_rcu+0x9d/0xa0 sysvec_call_function_single+0x34/0x80 asm_sysvec_call_function_single+0x12/0x20(CVE-2022-48673)
In the Linux kernel, the following vulnerability has been resolved:
soc: brcmstb: pm-arm: Fix refcount leak and __iomem leak bugs
In brcmstb_pm_probe(), there are two kinds of leak bugs:
(1) we need to add of_node_put() when for_each__matching_node() breaks (2) we need to add iounmap() for each iomap in fail path(CVE-2022-48693)
In the Linux kernel, the following vulnerability has been resolved:
rpmsg: virtio: Free driver_override when rpmsg_remove()
Free driver_override when rpmsg_remove(), otherwise the following memory leak will occur:
unreferenced object 0xffff0000d55d7080 (size 128): comm "kworker/u8:2", pid 56, jiffies 4294893188 (age 214.272s) hex dump (first 32 bytes): 72 70 6d 73 67 5f 6e 73 00 00 00 00 00 00 00 00 rpmsg_ns........ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<000000009c94c9c1>] __kmem_cache_alloc_node+0x1f8/0x320 [<000000002300d89b>] __kmalloc_node_track_caller+0x44/0x70 [<00000000228a60c3>] kstrndup+0x4c/0x90 [<0000000077158695>] driver_set_override+0xd0/0x164 [<000000003e9c4ea5>] rpmsg_register_device_override+0x98/0x170 [<000000001c0c89a8>] rpmsg_ns_register_device+0x24/0x30 [<000000008bbf8fa2>] rpmsg_probe+0x2e0/0x3ec [<00000000e65a68df>] virtio_dev_probe+0x1c0/0x280 [<00000000443331cc>] really_probe+0xbc/0x2dc [<00000000391064b1>] __driver_probe_device+0x78/0xe0 [<00000000a41c9a5b>] driver_probe_device+0xd8/0x160 [<000000009c3bd5df>] __device_attach_driver+0xb8/0x140 [<0000000043cd7614>] bus_for_each_drv+0x7c/0xd4 [<000000003b929a36>] __device_attach+0x9c/0x19c [<00000000a94e0ba8>] device_initial_probe+0x14/0x20 [<000000003c999637>] bus_probe_device+0xa0/0xac(CVE-2023-52670)
In the Linux kernel, the following vulnerability has been resolved:
pipe: wakeup wr_wait after setting max_usage
Commit c73be61cede5 ("pipe: Add general notification queue support") a regression was introduced that would lock up resized pipes under certain conditions. See the reproducer in 1.
The commit resizing the pipe ring size was moved to a different function, doing that moved the wakeup for pipe->wr_wait before actually raising pipe->max_usage. If a pipe was full before the resize occured it would result in the wakeup never actually triggering pipe_write.
Set @max_usage and @nr_accounted before waking writers if this isn't a watch queue.
Christian Brauner <brauner@kernel.org>: rewrite to account for watch queues
In the Linux kernel, the following vulnerability has been resolved:
ACPI: video: check for error while searching for backlight device parent
If acpi_get_parent() called in acpi_video_dev_register_backlight() fails, for example, because acpi_ut_acquire_mutex() fails inside acpi_get_parent), this can lead to incorrect (uninitialized) acpi_parent handle being passed to acpi_get_pci_dev() for detecting the parent pci device.
Check acpi_get_parent() result and set parent device only in case of success.
Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2023-52693)
In the Linux kernel, the following vulnerability has been resolved:
mmc: mmc_spi: fix error handling in mmc_spi_probe()
If mmc_add_host() fails, it doesn't need to call mmc_remove_host(), or it will cause null-ptr-deref, because of deleting a not added device in mmc_remove_host().
To fix this, goto label 'fail_glue_init', if mmc_add_host() fails, and change the label 'fail_add_host' to 'fail_gpiod_request'.(CVE-2023-52708)
In the Linux kernel, the following vulnerability has been resolved:
ceph: blocklist the kclient when receiving corrupted snap trace
When received corrupted snap trace we don't know what exactly has happened in MDS side. And we shouldn't continue IOs and metadatas access to MDS, which may corrupt or get incorrect contents.
This patch will just block all the further IO/MDS requests immediately and then evict the kclient itself.
The reason why we still need to evict the kclient just after blocking all the further IOs is that the MDS could revoke the caps faster.(CVE-2023-52732)
In the Linux kernel, the following vulnerability has been resolved:
Fix page corruption caused by racy check in __free_pages
When we upgraded our kernel, we started seeing some page corruption like the following consistently:
BUG: Bad page state in process ganesha.nfsd pfn:1304ca page:0000000022261c55 refcount:0 mapcount:-128 mapping:0000000000000000 index:0x0 pfn:0x1304ca flags: 0x17ffffc0000000() raw: 0017ffffc0000000 ffff8a513ffd4c98 ffffeee24b35ec08 0000000000000000 raw: 0000000000000000 0000000000000001 00000000ffffff7f 0000000000000000 page dumped because: nonzero mapcount CPU: 0 PID: 15567 Comm: ganesha.nfsd Kdump: loaded Tainted: P B O 5.10.158-1.nutanix.20221209.el7.x86_64 #1 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 04/05/2016 Call Trace: dump_stack+0x74/0x96 bad_page.cold+0x63/0x94 check_new_page_bad+0x6d/0x80 rmqueue+0x46e/0x970 get_page_from_freelist+0xcb/0x3f0 ? _cond_resched+0x19/0x40 __alloc_pages_nodemask+0x164/0x300 alloc_pages_current+0x87/0xf0 skb_page_frag_refill+0x84/0x110 ...
Sometimes, it would also show up as corruption in the free list pointer and cause crashes.
After bisecting the issue, we found the issue started from commit e320d3012d25 ("mm/page_alloc.c: fix freeing non-compound pages"):
if (put_page_testzero(page))
free_the_page(page, order);
else if (!PageHead(page))
while (order-- > 0)
free_the_page(page + (1 << order), order);
So the problem is the check PageHead is racy because at this point we already dropped our reference to the page. So even if we came in with compound page, the page can already be freed and PageHead can return false and we will end up freeing all the tail pages causing double free.(CVE-2023-52739)
In the Linux kernel, the following vulnerability has been resolved:
IB/hfi1: Restore allocated resources on failed copyout
Fix a resource leak if an error occurs.(CVE-2023-52747)
In the Linux kernel, the following vulnerability has been resolved:
virtio-blk: fix implicit overflow on virtio_max_dma_size
The following codes have an implicit conversion from size_t to u32: (u32)max_size = (size_t)virtio_max_dma_size(vdev);
This may lead overflow, Ex (size_t)4G -> (u32)0. Once virtio_max_dma_size() has a larger size than U32_MAX, use U32_MAX instead.(CVE-2023-52762)
In the Linux kernel, the following vulnerability has been resolved:
fs/jfs: Add check for negative db_l2nbperpage
l2nbperpage is log2(number of blks per page), and the minimum legal value should be 0, not negative.
In the case of l2nbperpage being negative, an error will occur when subsequently used as shift exponent.
Syzbot reported this bug:
UBSAN: shift-out-of-bounds in fs/jfs/jfs_dmap.c:799:12 shift exponent -16777216 is negative(CVE-2023-52810)
In the Linux kernel, the following vulnerability has been resolved:
drm/panel: fix a possible null pointer dereference
In versatile_panel_get_modes(), the return value of drm_mode_duplicate() is assigned to mode, which will lead to a NULL pointer dereference on failure of drm_mode_duplicate(). Add a check to avoid npd.(CVE-2023-52821)
In the Linux kernel, the following vulnerability has been resolved:
media: vidtv: mux: Add check and kfree for kstrdup
Add check for the return value of kstrdup() and return the error if it fails in order to avoid NULL pointer dereference. Moreover, use kfree() in the later error handling in order to avoid memory leak.(CVE-2023-52841)
In the Linux kernel, the following vulnerability has been resolved:
hsr: Prevent use after free in prp_create_tagged_frame()
The prp_fill_rct() function can fail. In that situation, it frees the skb and returns NULL. Meanwhile on the success path, it returns the original skb. So it's straight forward to fix bug by using the returned value.(CVE-2023-52846)
In the Linux kernel, the following vulnerability has been resolved:
clk: sunxi-ng: h6: Reparent CPUX during PLL CPUX rate change
While PLL CPUX clock rate change when CPU is running from it works in vast majority of cases, now and then it causes instability. This leads to system crashes and other undefined behaviour. After a lot of testing (30+ hours) while also doing a lot of frequency switches, we can't observe any instability issues anymore when doing reparenting to stable clock like 24 MHz oscillator.(CVE-2023-52882)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: validate request buffer size in smb2_allocate_rsp_buf()
The response buffer should be allocated in smb2_allocate_rsp_buf before validating request. But the fields in payload as well as smb2 header is used in smb2_allocate_rsp_buf(). This patch add simple buffer size validation to avoid potencial out-of-bounds in request buffer.(CVE-2024-26936)
In the Linux kernel, the following vulnerability has been resolved:
ARM: 9359/1: flush: check if the folio is reserved for no-mapping addresses
Since commit a4d5613c4dc6 ("arm: extend pfn_valid to take into account freed memory map alignment") changes the semantics of pfn_valid() to check presence of the memory map for a PFN. A valid page for an address which is reserved but not mapped by the kernel1, the system crashed during some uio test with the following memory layout:
node 0: [mem 0x00000000c0a00000-0x00000000cc8fffff] node 0: [mem 0x00000000d0000000-0x00000000da1fffff] the uio layout is：0xc0900000, 0x100000
the crash backtrace like:
Unable to handle kernel paging request at virtual address bff00000 [...] CPU: 1 PID: 465 Comm: startapp.bin Tainted: G O 5.10.0 #1 Hardware name: Generic DT based system PC is at b15_flush_kern_dcache_area+0x24/0x3c LR is at __sync_icache_dcache+0x6c/0x98 [...] (b15_flush_kern_dcache_area) from (__sync_icache_dcache+0x6c/0x98) (__sync_icache_dcache) from (set_pte_at+0x28/0x54) (set_pte_at) from (remap_pfn_range+0x1a0/0x274) (remap_pfn_range) from (uio_mmap+0x184/0x1b8 [uio]) (uio_mmap [uio]) from (__mmap_region+0x264/0x5f4) (__mmap_region) from (__do_mmap_mm+0x3ec/0x440) (__do_mmap_mm) from (do_mmap+0x50/0x58) (do_mmap) from (vm_mmap_pgoff+0xfc/0x188) (vm_mmap_pgoff) from (ksys_mmap_pgoff+0xac/0xc4) (ksys_mmap_pgoff) from (ret_fast_syscall+0x0/0x5c) Code: e0801001 e2423001 e1c00003 f57ff04f (ee070f3e) ---[ end trace 09cf0734c3805d52 ]--- Kernel panic - not syncing: Fatal exception
So check if PG_reserved was set to solve this issue.
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:
mm: swap: fix race between free_swap_and_cache() and swapoff()
There was previously a theoretical window where swapoff() could run and teardown a swap_info_struct while a call to free_swap_and_cache() was running in another thread. This could cause, amongst other bad possibilities, swap_page_trans_huge_swapped() (called by free_swap_and_cache()) to access the freed memory for swap_map.
This is a theoretical problem and I haven't been able to provoke it from a test case. But there has been agreement based on code review that this is possible (see link below).
Fix it by using get_swap_device()/put_swap_device(), which will stall swapoff(). There was an extra check in _swap_info_get() to confirm that the swap entry was not free. This isn't present in get_swap_device() because it doesn't make sense in general due to the race between getting the reference and swapoff. So I've added an equivalent check directly in free_swap_and_cache().
Details of how to provoke one possible issue (thanks to David Hildenbrand for deriving this):
--8<-----
__swap_entry_free() might be the last user and result in "count == SWAP_HAS_CACHE".
swapoff->try_to_unuse() will stop as soon as soon as si->inuse_pages==0.
So the question is: could someone reclaim the folio and turn si->inuse_pages==0, before we completed swap_page_trans_huge_swapped().
Imagine the following: 2 MiB folio in the swapcache. Only 2 subpages are still references by swap entries.
Process 1 still references subpage 0 via swap entry. Process 2 still references subpage 1 via swap entry.
Process 1 quits. Calls free_swap_and_cache(). -> count == SWAP_HAS_CACHE [then, preempted in the hypervisor etc.]
Process 2 quits. Calls free_swap_and_cache(). -> count == SWAP_HAS_CACHE
Process 2 goes ahead, passes swap_page_trans_huge_swapped(), and calls __try_to_reclaim_swap().
__try_to_reclaim_swap()->folio_free_swap()->delete_from_swap_cache()-> put_swap_folio()->free_swap_slot()->swapcache_free_entries()-> swap_entry_free()->swap_range_free()-> ... WRITE_ONCE(si->inuse_pages, si->inuse_pages - nr_entries);
What stops swapoff to succeed after process 2 reclaimed the swap cache but before process1 finished its call to swap_page_trans_huge_swapped()?
--8<-----(CVE-2024-26960)
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Prevent deadlock while disabling aRFS
When disabling aRFS under the priv->state_lock, any scheduled
aRFS works are canceled using the cancel_work_sync function,
which waits for the work to end if it has already started.
However, while waiting for the work handler, the handler will
try to acquire the state_lock which is already acquired.
The worker acquires the lock to delete the rules if the state is down, which is not the worker's responsibility since disabling aRFS deletes the rules.
Add an aRFS state variable, which indicates whether the aRFS is enabled and prevent adding rules when the aRFS is disabled.
Kernel log:
====================================================== WARNING: possible circular locking dependency detected 6.7.0-rc4_net_next_mlx5_5483eb2 #1 Tainted: G I
ethtool/386089 is trying to acquire lock: ffff88810f21ce68 ((work_completion)(&rule->arfs_work)){+.+.}-{0:0}, at: __flush_work+0x74/0x4e0
but task is already holding lock: ffff8884a1808cc0 (&priv->state_lock){+.+.}-{3:3}, at: mlx5e_ethtool_set_channels+0x53/0x200 [mlx5_core]
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&priv->state_lock){+.+.}-{3:3}: __mutex_lock+0x80/0xc90 arfs_handle_work+0x4b/0x3b0 [mlx5_core] process_one_work+0x1dc/0x4a0 worker_thread+0x1bf/0x3c0 kthread+0xd7/0x100 ret_from_fork+0x2d/0x50 ret_from_fork_asm+0x11/0x20
-> #0 ((work_completion)(&rule->arfs_work)){+.+.}-{0:0}: __lock_acquire+0x17b4/0x2c80 lock_acquire+0xd0/0x2b0 __flush_work+0x7a/0x4e0 __cancel_work_timer+0x131/0x1c0 arfs_del_rules+0x143/0x1e0 [mlx5_core] mlx5e_arfs_disable+0x1b/0x30 [mlx5_core] mlx5e_ethtool_set_channels+0xcb/0x200 [mlx5_core] ethnl_set_channels+0x28f/0x3b0 ethnl_default_set_doit+0xec/0x240 genl_family_rcv_msg_doit+0xd0/0x120 genl_rcv_msg+0x188/0x2c0 netlink_rcv_skb+0x54/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x1a1/0x270 netlink_sendmsg+0x214/0x460 __sock_sendmsg+0x38/0x60 __sys_sendto+0x113/0x170 __x64_sys_sendto+0x20/0x30 do_syscall_64+0x40/0xe0 entry_SYSCALL_64_after_hwframe+0x46/0x4e
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&priv->state_lock); lock((work_completion)(&rule->arfs_work)); lock(&priv->state_lock); lock((work_completion)(&rule->arfs_work));
*** DEADLOCK ***
3 locks held by ethtool/386089: #0: ffffffff82ea7210 (cb_lock){++++}-{3:3}, at: genl_rcv+0x15/0x40 #1: ffffffff82e94c88 (rtnl_mutex){+.+.}-{3:3}, at: ethnl_default_set_doit+0xd3/0x240 #2: ffff8884a1808cc0 (&priv->state_lock){+.+.}-{3:3}, at: mlx5e_ethtool_set_channels+0x53/0x200 [mlx5_core]
stack backtrace: CPU: 15 PID: 386089 Comm: ethtool Tainted: G I 6.7.0-rc4_net_next_mlx5_5483eb2 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x60/0xa0 check_noncircular+0x144/0x160 __lock_acquire+0x17b4/0x2c80 lock_acquire+0xd0/0x2b0 ? __flush_work+0x74/0x4e0 ? save_trace+0x3e/0x360 ? __flush_work+0x74/0x4e0 __flush_work+0x7a/0x4e0 ? __flush_work+0x74/0x4e0 ? __lock_acquire+0xa78/0x2c80 ? lock_acquire+0xd0/0x2b0 ? mark_held_locks+0x49/0x70 __cancel_work_timer+0x131/0x1c0 ? mark_held_locks+0x49/0x70 arfs_del_rules+0x143/0x1e0 [mlx5_core] mlx5e_arfs_disable+0x1b/0x30 [mlx5_core] mlx5e_ethtool_set_channels+0xcb/0x200 [mlx5_core] ethnl_set_channels+0x28f/0x3b0 ethnl_default_set_doit+0xec/0x240 genl_family_rcv_msg_doit+0xd0/0x120 genl_rcv_msg+0x188/0x2c0 ? ethn ---truncated---(CVE-2024-27014)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: Fix potential data-race in __nft_obj_type_get()
nft_unregister_obj() can concurrent with __nft_obj_type_get(), and there is not any protection when iterate over nf_tables_objects list in __nft_obj_type_get(). Therefore, there is potential data-race of nf_tables_objects list entry.
Use list_for_each_entry_rcu() to iterate over nf_tables_objects list in __nft_obj_type_get(), and use rcu_read_lock() in the caller nft_obj_type_get() to protect the entire type query process.(CVE-2024-27019)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix potential NULL pointer dereferences in 'dcn10_set_output_transfer_func()'
The 'stream' pointer is used in dcn10_set_output_transfer_func() before the check if 'stream' is NULL.
Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn10/dcn10_hwseq.c:1892 dcn10_set_output_transfer_func() warn: variable dereferenced before check 'stream' (see line 1875)(CVE-2024-27044)
In the Linux kernel, the following vulnerability has been resolved:
net: ll_temac: platform_get_resource replaced by wrong function
The function platform_get_resource was replaced with devm_platform_ioremap_resource_byname and is called using 0 as name.
This eventually ends up in platform_get_resource_byname in the call stack, where it causes a null pointer in strcmp.
if (type == resource_type(r) && !strcmp(r->name, name))
It should have been replaced with devm_platform_ioremap_resource.(CVE-2024-35796)
In the Linux kernel, the following vulnerability has been resolved:
fs/aio: Check IOCB_AIO_RW before the struct aio_kiocb conversion
The first kiocb_set_cancel_fn() argument may point at a struct kiocb that is not embedded inside struct aio_kiocb. With the current code, depending on the compiler, the req->ki_ctx read happens either before the IOCB_AIO_RW test or after that test. Move the req->ki_ctx read such that it is guaranteed that the IOCB_AIO_RW test happens first.(CVE-2024-35815)
In the Linux kernel, the following vulnerability has been resolved:
soc: fsl: qbman: Use raw spinlock for cgr_lock
smp_call_function always runs its callback in hard IRQ context, even on PREEMPT_RT, where spinlocks can sleep. So we need to use a raw spinlock for cgr_lock to ensure we aren't waiting on a sleeping task.
Although this bug has existed for a while, it was not apparent until commit ef2a8d5478b9 ("net: dpaa: Adjust queue depth on rate change") which invokes smp_call_function_single via qman_update_cgr_safe every time a link goes up or down.(CVE-2024-35819)
In the Linux kernel, the following vulnerability has been resolved:
wifi: libertas: fix some memleaks in lbs_allocate_cmd_buffer()
In the for statement of lbs_allocate_cmd_buffer(), if the allocation of cmdarray[i].cmdbuf fails, both cmdarray and cmdarray[i].cmdbuf needs to be freed. Otherwise, there will be memleaks in lbs_allocate_cmd_buffer().(CVE-2024-35828)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: bridge: replace physindev with physinif in nf_bridge_info
An skb can be added to a neigh->arp_queue while waiting for an arp reply. Where original skb's skb->dev can be different to neigh's neigh->dev. For instance in case of bridging dnated skb from one veth to another, the skb would be added to a neigh->arp_queue of the bridge.
As skb->dev can be reset back to nf_bridge->physindev and used, and as there is no explicit mechanism that prevents this physindev from been freed under us (for instance neigh_flush_dev doesn't cleanup skbs from different device's neigh queue) we can crash on e.g. this stack:
arp_process neigh_update skb = __skb_dequeue(&neigh->arp_queue) neigh_resolve_output(..., skb) ... br_nf_dev_xmit br_nf_pre_routing_finish_bridge_slow skb->dev = nf_bridge->physindev br_handle_frame_finish
Let's use plain ifindex instead of net_device link. To peek into the original net_device we will use dev_get_by_index_rcu(). Thus either we get device and are safe to use it or we don't get it and drop skb.(CVE-2024-35839)
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix UAF in smb2_reconnect_server()
The UAF bug is due to smb2_reconnect_server() accessing a session that is already being teared down by another thread that is executing __cifs_put_smb_ses(). This can happen when (a) the client has connection to the server but no session or (b) another thread ends up setting @ses->ses_status again to something different than SES_EXITING.
To fix this, we need to make sure to unconditionally set @ses->ses_status to SES_EXITING and prevent any other threads from setting a new status while we're still tearing it down.
The following can be reproduced by adding some delay to right after the ipc is freed in __cifs_put_smb_ses() - which will give smb2_reconnect_server() worker a chance to run and then accessing @ses->ipc:
kinit ... mount.cifs //srv/share /mnt/1 -o sec=krb5,nohandlecache,echo_interval=10 [disconnect srv] ls /mnt/1 &>/dev/null sleep 30 kdestroy [reconnect srv] sleep 10 umount /mnt/1 ... CIFS: VFS: Verify user has a krb5 ticket and keyutils is installed CIFS: VFS: \srv Send error in SessSetup = -126 CIFS: VFS: Verify user has a krb5 ticket and keyutils is installed CIFS: VFS: \srv Send error in SessSetup = -126 general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b6b: 0000 [#1] PREEMPT SMP NOPTI CPU: 3 PID: 50 Comm: kworker/3:1 Not tainted 6.9.0-rc2 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-1.fc39 04/01/2014 Workqueue: cifsiod smb2_reconnect_server [cifs] RIP: 0010:__list_del_entry_valid_or_report+0x33/0xf0 Code: 4f 08 48 85 d2 74 42 48 85 c9 74 59 48 b8 00 01 00 00 00 00 ad de 48 39 c2 74 61 48 b8 22 01 00 00 00 00 74 69 <48> 8b 01 48 39 f8 75 7b 48 8b 72 08 48 39 c6 0f 85 88 00 00 00 b8 RSP: 0018:ffffc900001bfd70 EFLAGS: 00010a83 RAX: dead000000000122 RBX: ffff88810da53838 RCX: 6b6b6b6b6b6b6b6b RDX: 6b6b6b6b6b6b6b6b RSI: ffffffffc02f6878 RDI: ffff88810da53800 RBP: ffff88810da53800 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000001 R12: ffff88810c064000 R13: 0000000000000001 R14: ffff88810c064000 R15: ffff8881039cc000 FS: 0000000000000000(0000) GS:ffff888157c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fe3728b1000 CR3: 000000010caa4000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: <TASK> ? die_addr+0x36/0x90 ? exc_general_protection+0x1c1/0x3f0 ? asm_exc_general_protection+0x26/0x30 ? __list_del_entry_valid_or_report+0x33/0xf0 __cifs_put_smb_ses+0x1ae/0x500 [cifs] smb2_reconnect_server+0x4ed/0x710 [cifs] process_one_work+0x205/0x6b0 worker_thread+0x191/0x360 ? __pfx_worker_thread+0x10/0x10 kthread+0xe2/0x110 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK>(CVE-2024-35870)
In the Linux kernel, the following vulnerability has been resolved:
ax25: fix use-after-free bugs caused by ax25_ds_del_timer
When the ax25 device is detaching, the ax25_dev_device_down() calls ax25_ds_del_timer() to cleanup the slave_timer. When the timer handler is running, the ax25_ds_del_timer() that calls del_timer() in it will return directly. As a result, the use-after-free bugs could happen, one of the scenarios is shown below:
(Thread 1) | (Thread 2)
| ax25_ds_timeout()
ax25_dev_device_down() | ax25_ds_del_timer() | del_timer() | ax25_dev_put() //FREE | | ax25_dev-> //USE
In order to mitigate bugs, when the device is detaching, use timer_shutdown_sync() to stop the timer.(CVE-2024-35887)
In the Linux kernel, the following vulnerability has been resolved:
tcp: properly terminate timers for kernel sockets
We had various syzbot reports about tcp timers firing after the corresponding netns has been dismantled.
Fortunately Josef Bacik could trigger the issue more often, and could test a patch I wrote two years ago.
When TCP sockets are closed, we call inet_csk_clear_xmit_timers() to 'stop' the timers.
inet_csk_clear_xmit_timers() can be called from any context, including when socket lock is held. This is the reason it uses sk_stop_timer(), aka del_timer(). This means that ongoing timers might finish much later.
For user sockets, this is fine because each running timer holds a reference on the socket, and the user socket holds a reference on the netns.
For kernel sockets, we risk that the netns is freed before timer can complete, because kernel sockets do not hold reference on the netns.
This patch adds inet_csk_clear_xmit_timers_sync() function that using sk_stop_timer_sync() to make sure all timers are terminated before the kernel socket is released. Modules using kernel sockets close them in their netns exit() handler.
Also add sock_not_owned_by_me() helper to get LOCKDEP support : inet_csk_clear_xmit_timers_sync() must not be called while socket lock is held.
It is very possible we can revert in the future commit 3a58f13a881e ("net: rds: acquire refcount on TCP sockets") which attempted to solve the issue in rds only. (net/smc/af_smc.c and net/mptcp/subflow.c have similar code)
We probably can remove the check_net() tests from tcp_out_of_resources() and __tcp_close() in the future.(CVE-2024-35910)
In the Linux kernel, the following vulnerability has been resolved:
drm/vc4: don't check if plane->state->fb == state->fb
Currently, when using non-blocking commits, we can see the following kernel warning:
[ 110.908514] ------------[ cut here ]------------ [ 110.908529] refcount_t: underflow; use-after-free. [ 110.908620] WARNING: CPU: 0 PID: 1866 at lib/refcount.c:87 refcount_dec_not_one+0xb8/0xc0 [ 110.908664] Modules linked in: rfcomm snd_seq_dummy snd_hrtimer snd_seq snd_seq_device cmac algif_hash aes_arm64 aes_generic algif_skcipher af_alg bnep hid_logitech_hidpp vc4 brcmfmac hci_uart btbcm brcmutil bluetooth snd_soc_hdmi_codec cfg80211 cec drm_display_helper drm_dma_helper drm_kms_helper snd_soc_core snd_compress snd_pcm_dmaengine fb_sys_fops sysimgblt syscopyarea sysfillrect raspberrypi_hwmon ecdh_generic ecc rfkill libaes i2c_bcm2835 binfmt_misc joydev snd_bcm2835(C) bcm2835_codec(C) bcm2835_isp(C) v4l2_mem2mem videobuf2_dma_contig snd_pcm bcm2835_v4l2(C) raspberrypi_gpiomem bcm2835_mmal_vchiq(C) videobuf2_v4l2 snd_timer videobuf2_vmalloc videobuf2_memops videobuf2_common snd videodev vc_sm_cma(C) mc hid_logitech_dj uio_pdrv_genirq uio i2c_dev drm fuse dm_mod drm_panel_orientation_quirks backlight ip_tables x_tables ipv6 [ 110.909086] CPU: 0 PID: 1866 Comm: kodi.bin Tainted: G C 6.1.66-v8+ #32 [ 110.909104] Hardware name: Raspberry Pi 3 Model B Rev 1.2 (DT) [ 110.909114] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 110.909132] pc : refcount_dec_not_one+0xb8/0xc0 [ 110.909152] lr : refcount_dec_not_one+0xb4/0xc0 [ 110.909170] sp : ffffffc00913b9c0 [ 110.909177] x29: ffffffc00913b9c0 x28: 000000556969bbb0 x27: 000000556990df60 [ 110.909205] x26: 0000000000000002 x25: 0000000000000004 x24: ffffff8004448480 [ 110.909230] x23: ffffff800570b500 x22: ffffff802e03a7bc x21: ffffffecfca68c78 [ 110.909257] x20: ffffff8002b42000 x19: ffffff802e03a600 x18: 0000000000000000 [ 110.909283] x17: 0000000000000011 x16: ffffffffffffffff x15: 0000000000000004 [ 110.909308] x14: 0000000000000fff x13: ffffffed577e47e0 x12: 0000000000000003 [ 110.909333] x11: 0000000000000000 x10: 0000000000000027 x9 : c912d0d083728c00 [ 110.909359] x8 : c912d0d083728c00 x7 : 65646e75203a745f x6 : 746e756f63666572 [ 110.909384] x5 : ffffffed579f62ee x4 : ffffffed579eb01e x3 : 0000000000000000 [ 110.909409] x2 : 0000000000000000 x1 : ffffffc00913b750 x0 : 0000000000000001 [ 110.909434] Call trace: [ 110.909441] refcount_dec_not_one+0xb8/0xc0 [ 110.909461] vc4_bo_dec_usecnt+0x4c/0x1b0 [vc4] [ 110.909903] vc4_cleanup_fb+0x44/0x50 [vc4] [ 110.910315] drm_atomic_helper_cleanup_planes+0x88/0xa4 [drm_kms_helper] [ 110.910669] vc4_atomic_commit_tail+0x390/0x9dc [vc4] [ 110.911079] commit_tail+0xb0/0x164 [drm_kms_helper] [ 110.911397] drm_atomic_helper_commit+0x1d0/0x1f0 [drm_kms_helper] [ 110.911716] drm_atomic_commit+0xb0/0xdc [drm] [ 110.912569] drm_mode_atomic_ioctl+0x348/0x4b8 [drm] [ 110.913330] drm_ioctl_kernel+0xec/0x15c [drm] [ 110.914091] drm_ioctl+0x24c/0x3b0 [drm] [ 110.914850] __arm64_sys_ioctl+0x9c/0xd4 [ 110.914873] invoke_syscall+0x4c/0x114 [ 110.914897] el0_svc_common+0xd0/0x118 [ 110.914917] do_el0_svc+0x38/0xd0 [ 110.914936] el0_svc+0x30/0x8c [ 110.914958] el0t_64_sync_handler+0x84/0xf0 [ 110.914979] el0t_64_sync+0x18c/0x190 [ 110.914996] ---[ end trace 0000000000000000 ]---
This happens because, although prepare_fb and cleanup_fb are
perfectly balanced, we cannot guarantee consistency in the check
plane->state->fb == state->fb. This means that sometimes we can increase
the refcount in prepare_fb and don't decrease it in cleanup_fb. The
opposite can also be true.
In fact, the struct drm_plane .state shouldn't be accessed directly
but instead, the drm_atomic_get_new_plane_state() helper function should
be used. So, we could stick to this check, but using
drm_atomic_get_new_plane_state(). But actually, this check is not re
---truncated---(CVE-2024-35932)
In the Linux kernel, the following vulnerability has been resolved:
btrfs: send: handle path ref underflow in header iterate_inode_ref()
Change BUG_ON to proper error handling if building the path buffer fails. The pointers are not printed so we don't accidentally leak kernel addresses.(CVE-2024-35935)
In the Linux kernel, the following vulnerability has been resolved:
wifi: cfg80211: check A-MSDU format more carefully
If it looks like there's another subframe in the A-MSDU but the header isn't fully there, we can end up reading data out of bounds, only to discard later. Make this a bit more careful and check if the subframe header can even be present.(CVE-2024-35937)
In the Linux kernel, the following vulnerability has been resolved:
drm/panfrost: Fix the error path in panfrost_mmu_map_fault_addr()
Subject: [PATCH] drm/panfrost: Fix the error path in panfrost_mmu_map_fault_addr()
If some the pages or sgt allocation failed, we shouldn't release the pages ref we got earlier, otherwise we will end up with unbalanced get/put_pages() calls. We should instead leave everything in place and let the BO release function deal with extra cleanup when the object is destroyed, or let the fault handler try again next time it's called.(CVE-2024-35951)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Fix not validating setsockopt user input
Check user input length before copying data.(CVE-2024-35965)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: RFCOMM: Fix not validating setsockopt user input
syzbot reported rfcomm_sock_setsockopt_old() is copying data without checking user input length.
BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline] BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline] BUG: KASAN: slab-out-of-bounds in rfcomm_sock_setsockopt_old net/bluetooth/rfcomm/sock.c:632 [inline] BUG: KASAN: slab-out-of-bounds in rfcomm_sock_setsockopt+0x893/0xa70 net/bluetooth/rfcomm/sock.c:673 Read of size 4 at addr ffff8880209a8bc3 by task syz-executor632/5064(CVE-2024-35966)
In the Linux kernel, the following vulnerability has been resolved:
batman-adv: Avoid infinite loop trying to resize local TT
If the MTU of one of an attached interface becomes too small to transmit the local translation table then it must be resized to fit inside all fragments (when enabled) or a single packet.
But if the MTU becomes too low to transmit even the header + the VLAN specific part then the resizing of the local TT will never succeed. This can for example happen when the usable space is 110 bytes and 11 VLANs are on top of batman-adv. In this case, at least 116 byte would be needed. There will just be an endless spam of
batman_adv: batadv0: Forced to purge local tt entries to fit new maximum fragment MTU (110)
in the log but the function will never finish. Problem here is that the timeout will be halved all the time and will then stagnate at 0 and therefore never be able to reduce the table even more.
There are other scenarios possible with a similar result. The number of BATADV_TT_CLIENT_NOPURGE entries in the local TT can for example be too high to fit inside a packet. Such a scenario can therefore happen also with only a single VLAN + 7 non-purgable addresses - requiring at least 120 bytes.
While this should be handled proactively when:
- interface with too low MTU is added
- VLAN is added
- non-purgeable local mac is added
- MTU of an attached interface is reduced
- fragmentation setting gets disabled (which most likely requires dropping attached interfaces)
not all of these scenarios can be prevented because batman-adv is only consuming events without the the possibility to prevent these actions (non-purgable MAC address added, MTU of an attached interface is reduced). It is therefore necessary to also make sure that the code is able to handle also the situations when there were already incompatible system configuration are present.(CVE-2024-35982)
In the Linux kernel, the following vulnerability has been resolved:
tty: n_gsm: fix possible out-of-bounds in gsm0_receive()
Assuming the following: - side A configures the n_gsm in basic option mode - side B sends the header of a basic option mode frame with data length 1 - side A switches to advanced option mode - side B sends 2 data bytes which exceeds gsm->len Reason: gsm->len is not used in advanced option mode. - side A switches to basic option mode - side B keeps sending until gsm0_receive() writes past gsm->buf Reason: Neither gsm->state nor gsm->len have been reset after reconfiguration.
Fix this by changing gsm->count to gsm->len comparison from equal to less than. Also add upper limit checks against the constant MAX_MRU in gsm0_receive() and gsm1_receive() to harden against memory corruption of gsm->len and gsm->mru.
All other checks remain as we still need to limit the data according to the user configuration and actual payload size.(CVE-2024-36016)
In the Linux kernel, the following vulnerability has been resolved:
blk-iocost: avoid out of bounds shift
UBSAN catches undefined behavior in blk-iocost, where sometimes iocg->delay is shifted right by a number that is too large, resulting in undefined behavior on some architectures.
[ 186.556576] ------------[ cut here ]------------ UBSAN: shift-out-of-bounds in block/blk-iocost.c:1366:23 shift exponent 64 is too large for 64-bit type 'u64' (aka 'unsigned long long') CPU: 16 PID: 0 Comm: swapper/16 Tainted: G S E N 6.9.0-0_fbk700_debug_rc2_kbuilder_0_gc85af715cac0 #1 Hardware name: Quanta Twin Lakes MP/Twin Lakes Passive MP, BIOS F09_3A23 12/08/2020 Call Trace: <IRQ> dump_stack_lvl+0x8f/0xe0 __ubsan_handle_shift_out_of_bounds+0x22c/0x280 iocg_kick_delay+0x30b/0x310 ioc_timer_fn+0x2fb/0x1f80 __run_timer_base+0x1b6/0x250 ...
Avoid that undefined behavior by simply taking the "delay = 0" branch if the shift is too large.
I am not sure what the symptoms of an undefined value delay will be, but I suspect it could be more than a little annoying to debug.(CVE-2024-36916)
In the Linux kernel, the following vulnerability has been resolved:
block: fix overflow in blk_ioctl_discard()
There is no check for overflow of 'start + len' in blk_ioctl_discard(). Hung task occurs if submit an discard ioctl with the following param: start = 0x80000000000ff000, len = 0x8000000000fff000; Add the overflow validation now.(CVE-2024-36917)
In the Linux kernel, the following vulnerability has been resolved:
scsi: bnx2fc: Remove spin_lock_bh while releasing resources after upload
The session resources are used by FW and driver when session is offloaded, once session is uploaded these resources are not used. The lock is not required as these fields won't be used any longer. The offload and upload calls are sequential, hence lock is not required.
This will suppress following BUG_ON():
[ 449.843143] ------------[ cut here ]------------ [ 449.848302] kernel BUG at mm/vmalloc.c:2727! [ 449.853072] invalid opcode: 0000 [#1] PREEMPT SMP PTI [ 449.858712] CPU: 5 PID: 1996 Comm: kworker/u24:2 Not tainted 5.14.0-118.el9.x86_64 #1 Rebooting. [ 449.867454] Hardware name: Dell Inc. PowerEdge R730/0WCJNT, BIOS 2.3.4 11/08/2016 [ 449.876966] Workqueue: fc_rport_eq fc_rport_work [libfc] [ 449.882910] RIP: 0010:vunmap+0x2e/0x30 [ 449.887098] Code: 00 65 8b 05 14 a2 f0 4a a9 00 ff ff 00 75 1b 55 48 89 fd e8 34 36 79 00 48 85 ed 74 0b 48 89 ef 31 f6 5d e9 14 fc ff ff 5d c3 <0f> 0b 0f 1f 44 00 00 41 57 41 56 49 89 ce 41 55 49 89 fd 41 54 41 [ 449.908054] RSP: 0018:ffffb83d878b3d68 EFLAGS: 00010206 [ 449.913887] RAX: 0000000080000201 RBX: ffff8f4355133550 RCX: 000000000d400005 [ 449.921843] RDX: 0000000000000001 RSI: 0000000000001000 RDI: ffffb83da53f5000 [ 449.929808] RBP: ffff8f4ac6675800 R08: ffffb83d878b3d30 R09: 00000000000efbdf [ 449.937774] R10: 0000000000000003 R11: ffff8f434573e000 R12: 0000000000001000 [ 449.945736] R13: 0000000000001000 R14: ffffb83da53f5000 R15: ffff8f43d4ea3ae0 [ 449.953701] FS: 0000000000000000(0000) GS:ffff8f529fc80000(0000) knlGS:0000000000000000 [ 449.962732] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 449.969138] CR2: 00007f8cf993e150 CR3: 0000000efbe10003 CR4: 00000000003706e0 [ 449.977102] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 449.985065] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 449.993028] Call Trace: [ 449.995756] __iommu_dma_free+0x96/0x100 [ 450.000139] bnx2fc_free_session_resc+0x67/0x240 [bnx2fc] [ 450.006171] bnx2fc_upload_session+0xce/0x100 [bnx2fc] [ 450.011910] bnx2fc_rport_event_handler+0x9f/0x240 [bnx2fc] [ 450.018136] fc_rport_work+0x103/0x5b0 [libfc] [ 450.023103] process_one_work+0x1e8/0x3c0 [ 450.027581] worker_thread+0x50/0x3b0 [ 450.031669] ? rescuer_thread+0x370/0x370 [ 450.036143] kthread+0x149/0x170 [ 450.039744] ? set_kthread_struct+0x40/0x40 [ 450.044411] ret_from_fork+0x22/0x30 [ 450.048404] Modules linked in: vfat msdos fat xfs nfs_layout_nfsv41_files rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver dm_service_time qedf qed crc8 bnx2fc libfcoe libfc scsi_transport_fc intel_rapl_msr intel_rapl_common x86_pkg_temp_thermal intel_powerclamp dcdbas rapl intel_cstate intel_uncore mei_me pcspkr mei ipmi_ssif lpc_ich ipmi_si fuse zram ext4 mbcache jbd2 loop nfsv3 nfs_acl nfs lockd grace fscache netfs irdma ice sd_mod t10_pi sg ib_uverbs ib_core 8021q garp mrp stp llc mgag200 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt mxm_wmi fb_sys_fops cec crct10dif_pclmul ahci crc32_pclmul bnx2x drm ghash_clmulni_intel libahci rfkill i40e libata megaraid_sas mdio wmi sunrpc lrw dm_crypt dm_round_robin dm_multipath dm_snapshot dm_bufio dm_mirror dm_region_hash dm_log dm_zero dm_mod linear raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx raid6_pq libcrc32c crc32c_intel raid1 raid0 iscsi_ibft squashfs be2iscsi bnx2i cnic uio cxgb4i cxgb4 tls [ 450.048497] libcxgbi libcxgb qla4xxx iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi edd ipmi_devintf ipmi_msghandler [ 450.159753] ---[ end trace 712de2c57c64abc8 ]---(CVE-2024-36919)
In the Linux kernel, the following vulnerability has been resolved:
s390/qeth: Fix kernel panic after setting hsuid
Symptom: When the hsuid attribute is set for the first time on an IQD Layer3 device while the corresponding network interface is already UP, the kernel will try to execute a napi function pointer that is NULL.
Example:
[ 2057.572696] illegal operation: 0001 ilc:1 [#1] SMP [ 2057.572702] Modules linked in: af_iucv qeth_l3 zfcp scsi_transport_fc sunrpc nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nf_tables_set nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables libcrc32c nfnetlink ghash_s390 prng xts aes_s390 des_s390 de s_generic sha3_512_s390 sha3_256_s390 sha512_s390 vfio_ccw vfio_mdev mdev vfio_iommu_type1 eadm_sch vfio ext4 mbcache jbd2 qeth_l2 bridge stp llc dasd_eckd_mod qeth dasd_mod qdio ccwgroup pkey zcrypt [ 2057.572739] CPU: 6 PID: 60182 Comm: stress_client Kdump: loaded Not tainted 4.18.0-541.el8.s390x #1 [ 2057.572742] Hardware name: IBM 3931 A01 704 (LPAR) [ 2057.572744] Krnl PSW : 0704f00180000000 0000000000000002 (0x2) [ 2057.572748] R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:3 PM:0 RI:0 EA:3 [ 2057.572751] Krnl GPRS: 0000000000000004 0000000000000000 00000000a3b008d8 0000000000000000 [ 2057.572754] 00000000a3b008d8 cb923a29c779abc5 0000000000000000 00000000814cfd80 [ 2057.572756] 000000000000012c 0000000000000000 00000000a3b008d8 00000000a3b008d8 [ 2057.572758] 00000000bab6d500 00000000814cfd80 0000000091317e46 00000000814cfc68 [ 2057.572762] Krnl Code:#0000000000000000: 0000 illegal >0000000000000002: 0000 illegal 0000000000000004: 0000 illegal 0000000000000006: 0000 illegal 0000000000000008: 0000 illegal 000000000000000a: 0000 illegal 000000000000000c: 0000 illegal 000000000000000e: 0000 illegal [ 2057.572800] Call Trace: [ 2057.572801] ([<00000000ec639700>] 0xec639700) [ 2057.572803] [<00000000913183e2>] net_rx_action+0x2ba/0x398 [ 2057.572809] [<0000000091515f76>] __do_softirq+0x11e/0x3a0 [ 2057.572813] [<0000000090ce160c>] do_softirq_own_stack+0x3c/0x58 [ 2057.572817] ([<0000000090d2cbd6>] do_softirq.part.1+0x56/0x60) [ 2057.572822] [<0000000090d2cc60>] __local_bh_enable_ip+0x80/0x98 [ 2057.572825] [<0000000091314706>] __dev_queue_xmit+0x2be/0xd70 [ 2057.572827] [<000003ff803dd6d6>] afiucv_hs_send+0x24e/0x300 [af_iucv] [ 2057.572830] [<000003ff803dd88a>] iucv_send_ctrl+0x102/0x138 [af_iucv] [ 2057.572833] [<000003ff803de72a>] iucv_sock_connect+0x37a/0x468 [af_iucv] [ 2057.572835] [<00000000912e7e90>] __sys_connect+0xa0/0xd8 [ 2057.572839] [<00000000912e9580>] sys_socketcall+0x228/0x348 [ 2057.572841] [<0000000091514e1a>] system_call+0x2a6/0x2c8 [ 2057.572843] Last Breaking-Event-Address: [ 2057.572844] [<0000000091317e44>] __napi_poll+0x4c/0x1d8 [ 2057.572846] [ 2057.572847] Kernel panic - not syncing: Fatal exception in interrupt
Analysis: There is one napi structure per out_q: card->qdio.out_qs[i].napi The napi.poll functions are set during qeth_open().
Since commit 1cfef80d4c2b ("s390/qeth: Don't call dev_close/dev_open (DOWN/UP)") qeth_set_offline()/qeth_set_online() no longer call dev_close()/ dev_open(). So if qeth_free_qdio_queues() cleared card->qdio.out_qs[i].napi.poll while the network interface was UP and the card was offline, they are not set again.
Reproduction: chzdev -e $devno layer2=0 ip link set dev $network_interface up echo 0 > /sys/bus/ccw ---truncated---(CVE-2024-36928)
In the Linux kernel, the following vulnerability has been resolved:
scsi: lpfc: Move NPIV's transport unregistration to after resource clean up
There are cases after NPIV deletion where the fabric switch still believes the NPIV is logged into the fabric. This occurs when a vport is unregistered before the Remove All DA_ID CT and LOGO ELS are sent to the fabric.
Currently fc_remove_host(), which calls dev_loss_tmo for all D_IDs including the fabric D_ID, removes the last ndlp reference and frees the ndlp rport object. This sometimes causes the race condition where the final DA_ID and LOGO are skipped from being sent to the fabric switch.
Fix by moving the fc_remove_host() and scsi_remove_host() calls after DA_ID and LOGO are sent.(CVE-2024-36952)
In the Linux kernel, the following vulnerability has been resolved:
tipc: fix a possible memleak in tipc_buf_append
__skb_linearize() doesn't free the skb when it fails, so move '*buf = NULL' after __skb_linearize(), so that the skb can be freed on the err path.(CVE-2024-36954)
In the Linux kernel, the following vulnerability has been resolved:
drm/vmwgfx: Fix invalid reads in fence signaled events
Correctly set the length of the drm_event to the size of the structure that's actually used.
The length of the drm_event was set to the parent structure instead of to the drm_vmw_event_fence which is supposed to be read. drm_read uses the length parameter to copy the event to the user space thus resuling in oob reads.(CVE-2024-36960)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Fix div-by-zero in l2cap_le_flowctl_init()
l2cap_le_flowctl_init() can cause both div-by-zero and an integer overflow since hdev->le_mtu may not fall in the valid range.
Move MTU from hci_dev to hci_conn to validate MTU and stop the connection process earlier if MTU is invalid. Also, add a missing validation in read_buffer_size() and make it return an error value if the validation fails. Now hci_conn_add() returns ERR_PTR() as it can fail due to the both a kzalloc failure and invalid MTU value.
divide error: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 0 PID: 67 Comm: kworker/u5:0 Tainted: G W 6.9.0-rc5+ #20 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: hci0 hci_rx_work RIP: 0010:l2cap_le_flowctl_init+0x19e/0x3f0 net/bluetooth/l2cap_core.c:547 Code: e8 17 17 0c 00 66 41 89 9f 84 00 00 00 bf 01 00 00 00 41 b8 02 00 00 00 4c 89 fe 4c 89 e2 89 d9 e8 27 17 0c 00 44 89 f0 31 d2 <66> f7 f3 89 c3 ff c3 4d 8d b7 88 00 00 00 4c 89 f0 48 c1 e8 03 42 RSP: 0018:ffff88810bc0f858 EFLAGS: 00010246 RAX: 00000000000002a0 RBX: 0000000000000000 RCX: dffffc0000000000 RDX: 0000000000000000 RSI: ffff88810bc0f7c0 RDI: ffffc90002dcb66f RBP: ffff88810bc0f880 R08: aa69db2dda70ff01 R09: 0000ffaaaaaaaaaa R10: 0084000000ffaaaa R11: 0000000000000000 R12: ffff88810d65a084 R13: dffffc0000000000 R14: 00000000000002a0 R15: ffff88810d65a000 FS: 0000000000000000(0000) GS:ffff88811ac00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000100 CR3: 0000000103268003 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace: <TASK> l2cap_le_connect_req net/bluetooth/l2cap_core.c:4902 [inline] l2cap_le_sig_cmd net/bluetooth/l2cap_core.c:5420 [inline] l2cap_le_sig_channel net/bluetooth/l2cap_core.c:5486 [inline] l2cap_recv_frame+0xe59d/0x11710 net/bluetooth/l2cap_core.c:6809 l2cap_recv_acldata+0x544/0x10a0 net/bluetooth/l2cap_core.c:7506 hci_acldata_packet net/bluetooth/hci_core.c:3939 [inline] hci_rx_work+0x5e5/0xb20 net/bluetooth/hci_core.c:4176 process_one_work kernel/workqueue.c:3254 [inline] process_scheduled_works+0x90f/0x1530 kernel/workqueue.c:3335 worker_thread+0x926/0xe70 kernel/workqueue.c:3416 kthread+0x2e3/0x380 kernel/kthread.c:388 ret_from_fork+0x5c/0x90 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 </TASK> Modules linked in: ---[ end trace 0000000000000000 ]---(CVE-2024-36968)
In the Linux kernel, the following vulnerability has been resolved:
net: fix __dst_negative_advice() race
__dst_negative_advice() does not enforce proper RCU rules when sk->dst_cache must be cleared, leading to possible UAF.
RCU rules are that we must first clear sk->sk_dst_cache, then call dst_release(old_dst).
Note that sk_dst_reset(sk) is implementing this protocol correctly, while __dst_negative_advice() uses the wrong order.
Given that ip6_negative_advice() has special logic against RTF_CACHE, this means each of the three ->negative_advice() existing methods must perform the sk_dst_reset() themselves.
Note the check against NULL dst is centralized in __dst_negative_advice(), there is no need to duplicate it in various callbacks.
Many thanks to Clement Lecigne for tracking this issue.
This old bug became visible after the blamed commit, using UDP sockets.(CVE-2024-36971)
| URL | Type | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"kernel-source-5.10.0-136.80.0.160.oe2203sp1.aarch64.rpm",
"kernel-tools-devel-5.10.0-136.80.0.160.oe2203sp1.aarch64.rpm",
"perf-5.10.0-136.80.0.160.oe2203sp1.aarch64.rpm",
"kernel-debugsource-5.10.0-136.80.0.160.oe2203sp1.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-136.80.0.160.oe2203sp1.aarch64.rpm",
"kernel-tools-5.10.0-136.80.0.160.oe2203sp1.aarch64.rpm",
"kernel-devel-5.10.0-136.80.0.160.oe2203sp1.aarch64.rpm",
"kernel-5.10.0-136.80.0.160.oe2203sp1.aarch64.rpm",
"perf-debuginfo-5.10.0-136.80.0.160.oe2203sp1.aarch64.rpm",
"kernel-headers-5.10.0-136.80.0.160.oe2203sp1.aarch64.rpm",
"kernel-debuginfo-5.10.0-136.80.0.160.oe2203sp1.aarch64.rpm",
"python3-perf-5.10.0-136.80.0.160.oe2203sp1.aarch64.rpm",
"kernel-tools-debuginfo-5.10.0-136.80.0.160.oe2203sp1.aarch64.rpm"
],
"src": [
"kernel-5.10.0-136.80.0.160.oe2203sp1.src.rpm"
],
"x86_64": [
"kernel-tools-debuginfo-5.10.0-136.80.0.160.oe2203sp1.x86_64.rpm",
"python3-perf-5.10.0-136.80.0.160.oe2203sp1.x86_64.rpm",
"kernel-debugsource-5.10.0-136.80.0.160.oe2203sp1.x86_64.rpm",
"kernel-tools-devel-5.10.0-136.80.0.160.oe2203sp1.x86_64.rpm",
"kernel-devel-5.10.0-136.80.0.160.oe2203sp1.x86_64.rpm",
"kernel-headers-5.10.0-136.80.0.160.oe2203sp1.x86_64.rpm",
"kernel-tools-5.10.0-136.80.0.160.oe2203sp1.x86_64.rpm",
"kernel-5.10.0-136.80.0.160.oe2203sp1.x86_64.rpm",
"kernel-debuginfo-5.10.0-136.80.0.160.oe2203sp1.x86_64.rpm",
"kernel-source-5.10.0-136.80.0.160.oe2203sp1.x86_64.rpm",
"python3-perf-debuginfo-5.10.0-136.80.0.160.oe2203sp1.x86_64.rpm",
"perf-debuginfo-5.10.0-136.80.0.160.oe2203sp1.x86_64.rpm",
"perf-5.10.0-136.80.0.160.oe2203sp1.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:22.03-LTS-SP1",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP1"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.10.0-136.80.0.160.oe2203sp1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nafs: Fix corruption in reads at fpos 2G-4G from an OpenAFS server\r\n\r\nAFS-3 has two data fetch RPC variants, FS.FetchData and FS.FetchData64, and\nLinux\u0026apos;s afs client switches between them when talking to a non-YFS server\nif the read size, the file position or the sum of the two have the upper 32\nbits set of the 64-bit value.\r\n\r\nThis is a problem, however, since the file position and length fields of\nFS.FetchData are *signed* 32-bit values.\r\n\r\nFix this by capturing the capability bits obtained from the fileserver when\nit\u0026apos;s sent an FS.GetCapabilities RPC, rather than just discarding them, and\nthen picking out the VICED_CAPABILITY_64BITFILES flag. This can then be\nused to decide whether to use FS.FetchData or FS.FetchData64 - and also\nFS.StoreData or FS.StoreData64 - rather than using upper_32_bits() to\nswitch on the parameter values.\r\n\r\nThis capabilities flag could also be used to limit the maximum size of the\nfile, but all servers must be checked for that.\r\n\r\nNote that the issue does not exist with FS.StoreData - that uses *unsigned*\n32-bit values. It\u0026apos;s also not a problem with Auristor servers as its\nYFS.FetchData64 op uses unsigned 64-bit values.\r\n\r\nThis can be tested by cloning a git repo through an OpenAFS client to an\nOpenAFS server and then doing \u0026quot;git status\u0026quot; on it from a Linux afs\nclient[1]. Provided the clone has a pack file that\u0026apos;s in the 2G-4G range,\nthe git status will show errors like:\r\n\r\n\terror: packfile .git/objects/pack/pack-5e813c51d12b6847bbc0fcd97c2bca66da50079c.pack does not match index\n\terror: packfile .git/objects/pack/pack-5e813c51d12b6847bbc0fcd97c2bca66da50079c.pack does not match index\r\n\r\nThis can be observed in the server\u0026apos;s FileLog with something like the\nfollowing appearing:\r\n\r\nSun Aug 29 19:31:39 2021 SRXAFS_FetchData, Fid = 2303380852.491776.3263114, Host 192.168.11.201:7001, Id 1001\nSun Aug 29 19:31:39 2021 CheckRights: len=0, for host=192.168.11.201:7001\nSun Aug 29 19:31:39 2021 FetchData_RXStyle: Pos 18446744071815340032, Len 3154\nSun Aug 29 19:31:39 2021 FetchData_RXStyle: file size 2400758866\n...\nSun Aug 29 19:31:40 2021 SRXAFS_FetchData returns 5\r\n\r\nNote the file position of 18446744071815340032. This is the requested file\nposition sign-extended.(CVE-2021-47366)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/smc: Fix possible access to freed memory in link clear\r\n\r\nAfter modifying the QP to the Error state, all RX WR would be completed\nwith WC in IB_WC_WR_FLUSH_ERR status. Current implementation does not\nwait for it is done, but destroy the QP and free the link group directly.\nSo there is a risk that accessing the freed memory in tasklet context.\r\n\r\nHere is a crash example:\r\n\r\n BUG: unable to handle page fault for address: ffffffff8f220860\n #PF: supervisor write access in kernel mode\n #PF: error_code(0x0002) - not-present page\n PGD f7300e067 P4D f7300e067 PUD f7300f063 PMD 8c4e45063 PTE 800ffff08c9df060\n Oops: 0002 [#1] SMP PTI\n CPU: 1 PID: 0 Comm: swapper/1 Kdump: loaded Tainted: G S OE 5.10.0-0607+ #23\n Hardware name: Inspur NF5280M4/YZMB-00689-101, BIOS 4.1.20 07/09/2018\n RIP: 0010:native_queued_spin_lock_slowpath+0x176/0x1b0\n Code: f3 90 48 8b 32 48 85 f6 74 f6 eb d5 c1 ee 12 83 e0 03 83 ee 01 48 c1 e0 05 48 63 f6 48 05 00 c8 02 00 48 03 04 f5 00 09 98 8e \u0026lt;48\u0026gt; 89 10 8b 42 08 85 c0 75 09 f3 90 8b 42 08 85 c0 74 f7 48 8b 32\n RSP: 0018:ffffb3b6c001ebd8 EFLAGS: 00010086\n RAX: ffffffff8f220860 RBX: 0000000000000246 RCX: 0000000000080000\n RDX: ffff91db1f86c800 RSI: 000000000000173c RDI: ffff91db62bace00\n RBP: ffff91db62bacc00 R08: 0000000000000000 R09: c00000010000028b\n R10: 0000000000055198 R11: ffffb3b6c001ea58 R12: ffff91db80e05010\n R13: 000000000000000a R14: 0000000000000006 R15: 0000000000000040\n FS: 0000000000000000(0000) GS:ffff91db1f840000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: ffffffff8f220860 CR3: 00000001f9580004 CR4: 00000000003706e0\n DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n Call Trace:\n \u0026lt;IRQ\u0026gt;\n _raw_spin_lock_irqsave+0x30/0x40\n mlx5_ib_poll_cq+0x4c/0xc50 [mlx5_ib]\n smc_wr_rx_tasklet_fn+0x56/0xa0 [smc]\n tasklet_action_common.isra.21+0x66/0x100\n __do_softirq+0xd5/0x29c\n asm_call_irq_on_stack+0x12/0x20\n \u0026lt;/IRQ\u0026gt;\n do_softirq_own_stack+0x37/0x40\n irq_exit_rcu+0x9d/0xa0\n sysvec_call_function_single+0x34/0x80\n asm_sysvec_call_function_single+0x12/0x20(CVE-2022-48673)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsoc: brcmstb: pm-arm: Fix refcount leak and __iomem leak bugs\r\n\r\nIn brcmstb_pm_probe(), there are two kinds of leak bugs:\r\n\r\n(1) we need to add of_node_put() when for_each__matching_node() breaks\n(2) we need to add iounmap() for each iomap in fail path(CVE-2022-48693)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nrpmsg: virtio: Free driver_override when rpmsg_remove()\r\n\r\nFree driver_override when rpmsg_remove(), otherwise\nthe following memory leak will occur:\r\n\r\nunreferenced object 0xffff0000d55d7080 (size 128):\n comm \u0026quot;kworker/u8:2\u0026quot;, pid 56, jiffies 4294893188 (age 214.272s)\n hex dump (first 32 bytes):\n 72 70 6d 73 67 5f 6e 73 00 00 00 00 00 00 00 00 rpmsg_ns........\n 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n backtrace:\n [\u0026lt;000000009c94c9c1\u0026gt;] __kmem_cache_alloc_node+0x1f8/0x320\n [\u0026lt;000000002300d89b\u0026gt;] __kmalloc_node_track_caller+0x44/0x70\n [\u0026lt;00000000228a60c3\u0026gt;] kstrndup+0x4c/0x90\n [\u0026lt;0000000077158695\u0026gt;] driver_set_override+0xd0/0x164\n [\u0026lt;000000003e9c4ea5\u0026gt;] rpmsg_register_device_override+0x98/0x170\n [\u0026lt;000000001c0c89a8\u0026gt;] rpmsg_ns_register_device+0x24/0x30\n [\u0026lt;000000008bbf8fa2\u0026gt;] rpmsg_probe+0x2e0/0x3ec\n [\u0026lt;00000000e65a68df\u0026gt;] virtio_dev_probe+0x1c0/0x280\n [\u0026lt;00000000443331cc\u0026gt;] really_probe+0xbc/0x2dc\n [\u0026lt;00000000391064b1\u0026gt;] __driver_probe_device+0x78/0xe0\n [\u0026lt;00000000a41c9a5b\u0026gt;] driver_probe_device+0xd8/0x160\n [\u0026lt;000000009c3bd5df\u0026gt;] __device_attach_driver+0xb8/0x140\n [\u0026lt;0000000043cd7614\u0026gt;] bus_for_each_drv+0x7c/0xd4\n [\u0026lt;000000003b929a36\u0026gt;] __device_attach+0x9c/0x19c\n [\u0026lt;00000000a94e0ba8\u0026gt;] device_initial_probe+0x14/0x20\n [\u0026lt;000000003c999637\u0026gt;] bus_probe_device+0xa0/0xac(CVE-2023-52670)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npipe: wakeup wr_wait after setting max_usage\r\n\r\nCommit c73be61cede5 (\u0026quot;pipe: Add general notification queue support\u0026quot;) a\nregression was introduced that would lock up resized pipes under certain\nconditions. See the reproducer in [1].\r\n\r\nThe commit resizing the pipe ring size was moved to a different\nfunction, doing that moved the wakeup for pipe-\u0026gt;wr_wait before actually\nraising pipe-\u0026gt;max_usage. If a pipe was full before the resize occured it\nwould result in the wakeup never actually triggering pipe_write.\r\n\r\nSet @max_usage and @nr_accounted before waking writers if this isn\u0026apos;t a\nwatch queue.\r\n\r\n[Christian Brauner \u0026lt;brauner@kernel.org\u0026gt;: rewrite to account for watch queues](CVE-2023-52672)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nACPI: video: check for error while searching for backlight device parent\r\n\r\nIf acpi_get_parent() called in acpi_video_dev_register_backlight()\nfails, for example, because acpi_ut_acquire_mutex() fails inside\nacpi_get_parent), this can lead to incorrect (uninitialized)\nacpi_parent handle being passed to acpi_get_pci_dev() for detecting\nthe parent pci device.\r\n\r\nCheck acpi_get_parent() result and set parent device only in case of success.\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2023-52693)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmmc: mmc_spi: fix error handling in mmc_spi_probe()\r\n\r\nIf mmc_add_host() fails, it doesn\u0026apos;t need to call mmc_remove_host(),\nor it will cause null-ptr-deref, because of deleting a not added\ndevice in mmc_remove_host().\r\n\r\nTo fix this, goto label \u0026apos;fail_glue_init\u0026apos;, if mmc_add_host() fails,\nand change the label \u0026apos;fail_add_host\u0026apos; to \u0026apos;fail_gpiod_request\u0026apos;.(CVE-2023-52708)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nceph: blocklist the kclient when receiving corrupted snap trace\r\n\r\nWhen received corrupted snap trace we don\u0026apos;t know what exactly has\nhappened in MDS side. And we shouldn\u0026apos;t continue IOs and metadatas\naccess to MDS, which may corrupt or get incorrect contents.\r\n\r\nThis patch will just block all the further IO/MDS requests\nimmediately and then evict the kclient itself.\r\n\r\nThe reason why we still need to evict the kclient just after\nblocking all the further IOs is that the MDS could revoke the caps\nfaster.(CVE-2023-52732)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nFix page corruption caused by racy check in __free_pages\r\n\r\nWhen we upgraded our kernel, we started seeing some page corruption like\nthe following consistently:\r\n\r\n BUG: Bad page state in process ganesha.nfsd pfn:1304ca\n page:0000000022261c55 refcount:0 mapcount:-128 mapping:0000000000000000 index:0x0 pfn:0x1304ca\n flags: 0x17ffffc0000000()\n raw: 0017ffffc0000000 ffff8a513ffd4c98 ffffeee24b35ec08 0000000000000000\n raw: 0000000000000000 0000000000000001 00000000ffffff7f 0000000000000000\n page dumped because: nonzero mapcount\n CPU: 0 PID: 15567 Comm: ganesha.nfsd Kdump: loaded Tainted: P B O 5.10.158-1.nutanix.20221209.el7.x86_64 #1\n Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 04/05/2016\n Call Trace:\n dump_stack+0x74/0x96\n bad_page.cold+0x63/0x94\n check_new_page_bad+0x6d/0x80\n rmqueue+0x46e/0x970\n get_page_from_freelist+0xcb/0x3f0\n ? _cond_resched+0x19/0x40\n __alloc_pages_nodemask+0x164/0x300\n alloc_pages_current+0x87/0xf0\n skb_page_frag_refill+0x84/0x110\n ...\r\n\r\nSometimes, it would also show up as corruption in the free list pointer\nand cause crashes.\r\n\r\nAfter bisecting the issue, we found the issue started from commit\ne320d3012d25 (\u0026quot;mm/page_alloc.c: fix freeing non-compound pages\u0026quot;):\r\n\r\n\tif (put_page_testzero(page))\n\t\tfree_the_page(page, order);\n\telse if (!PageHead(page))\n\t\twhile (order-- \u0026gt; 0)\n\t\t\tfree_the_page(page + (1 \u0026lt;\u0026lt; order), order);\r\n\r\nSo the problem is the check PageHead is racy because at this point we\nalready dropped our reference to the page. So even if we came in with\ncompound page, the page can already be freed and PageHead can return\nfalse and we will end up freeing all the tail pages causing double free.(CVE-2023-52739)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nIB/hfi1: Restore allocated resources on failed copyout\r\n\r\nFix a resource leak if an error occurs.(CVE-2023-52747)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nvirtio-blk: fix implicit overflow on virtio_max_dma_size\r\n\r\nThe following codes have an implicit conversion from size_t to u32:\n(u32)max_size = (size_t)virtio_max_dma_size(vdev);\r\n\r\nThis may lead overflow, Ex (size_t)4G -\u0026gt; (u32)0. Once\nvirtio_max_dma_size() has a larger size than U32_MAX, use U32_MAX\ninstead.(CVE-2023-52762)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfs/jfs: Add check for negative db_l2nbperpage\r\n\r\nl2nbperpage is log2(number of blks per page), and the minimum legal\nvalue should be 0, not negative.\r\n\r\nIn the case of l2nbperpage being negative, an error will occur\nwhen subsequently used as shift exponent.\r\n\r\nSyzbot reported this bug:\r\n\r\nUBSAN: shift-out-of-bounds in fs/jfs/jfs_dmap.c:799:12\nshift exponent -16777216 is negative(CVE-2023-52810)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/panel: fix a possible null pointer dereference\r\n\r\nIn versatile_panel_get_modes(), the return value of drm_mode_duplicate()\nis assigned to mode, which will lead to a NULL pointer dereference\non failure of drm_mode_duplicate(). Add a check to avoid npd.(CVE-2023-52821)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: vidtv: mux: Add check and kfree for kstrdup\r\n\r\nAdd check for the return value of kstrdup() and return the error\nif it fails in order to avoid NULL pointer dereference.\nMoreover, use kfree() in the later error handling in order to avoid\nmemory leak.(CVE-2023-52841)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nhsr: Prevent use after free in prp_create_tagged_frame()\r\n\r\nThe prp_fill_rct() function can fail. In that situation, it frees the\nskb and returns NULL. Meanwhile on the success path, it returns the\noriginal skb. So it\u0026apos;s straight forward to fix bug by using the returned\nvalue.(CVE-2023-52846)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nclk: sunxi-ng: h6: Reparent CPUX during PLL CPUX rate change\r\n\r\nWhile PLL CPUX clock rate change when CPU is running from it works in\nvast majority of cases, now and then it causes instability. This leads\nto system crashes and other undefined behaviour. After a lot of testing\n(30+ hours) while also doing a lot of frequency switches, we can\u0026apos;t\nobserve any instability issues anymore when doing reparenting to stable\nclock like 24 MHz oscillator.(CVE-2023-52882)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nksmbd: validate request buffer size in smb2_allocate_rsp_buf()\r\n\r\nThe response buffer should be allocated in smb2_allocate_rsp_buf\nbefore validating request. But the fields in payload as well as smb2 header\nis used in smb2_allocate_rsp_buf(). This patch add simple buffer size\nvalidation to avoid potencial out-of-bounds in request buffer.(CVE-2024-26936)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nARM: 9359/1: flush: check if the folio is reserved for no-mapping addresses\r\n\r\nSince commit a4d5613c4dc6 (\u0026quot;arm: extend pfn_valid to take into account\nfreed memory map alignment\u0026quot;) changes the semantics of pfn_valid() to check\npresence of the memory map for a PFN. A valid page for an address which\nis reserved but not mapped by the kernel[1], the system crashed during\nsome uio test with the following memory layout:\r\n\r\n node 0: [mem 0x00000000c0a00000-0x00000000cc8fffff]\n node 0: [mem 0x00000000d0000000-0x00000000da1fffff]\n the uio layout is\uff1a0xc0900000, 0x100000\r\n\r\nthe crash backtrace like:\r\n\r\n Unable to handle kernel paging request at virtual address bff00000\n [...]\n CPU: 1 PID: 465 Comm: startapp.bin Tainted: G O 5.10.0 #1\n Hardware name: Generic DT based system\n PC is at b15_flush_kern_dcache_area+0x24/0x3c\n LR is at __sync_icache_dcache+0x6c/0x98\n [...]\n (b15_flush_kern_dcache_area) from (__sync_icache_dcache+0x6c/0x98)\n (__sync_icache_dcache) from (set_pte_at+0x28/0x54)\n (set_pte_at) from (remap_pfn_range+0x1a0/0x274)\n (remap_pfn_range) from (uio_mmap+0x184/0x1b8 [uio])\n (uio_mmap [uio]) from (__mmap_region+0x264/0x5f4)\n (__mmap_region) from (__do_mmap_mm+0x3ec/0x440)\n (__do_mmap_mm) from (do_mmap+0x50/0x58)\n (do_mmap) from (vm_mmap_pgoff+0xfc/0x188)\n (vm_mmap_pgoff) from (ksys_mmap_pgoff+0xac/0xc4)\n (ksys_mmap_pgoff) from (ret_fast_syscall+0x0/0x5c)\n Code: e0801001 e2423001 e1c00003 f57ff04f (ee070f3e)\n ---[ end trace 09cf0734c3805d52 ]---\n Kernel panic - not syncing: Fatal exception\r\n\r\nSo check if PG_reserved was set to solve this issue.\r\n\r\n[1]: https://lore.kernel.org/lkml/Zbtdue57RO0QScJM@linux.ibm.com/(CVE-2024-26947)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nksmbd: fix slab-out-of-bounds in smb_strndup_from_utf16()\r\n\r\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)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmm: swap: fix race between free_swap_and_cache() and swapoff()\r\n\r\nThere was previously a theoretical window where swapoff() could run and\nteardown a swap_info_struct while a call to free_swap_and_cache() was\nrunning in another thread. This could cause, amongst other bad\npossibilities, swap_page_trans_huge_swapped() (called by\nfree_swap_and_cache()) to access the freed memory for swap_map.\r\n\r\nThis is a theoretical problem and I haven\u0026apos;t been able to provoke it from a\ntest case. But there has been agreement based on code review that this is\npossible (see link below).\r\n\r\nFix it by using get_swap_device()/put_swap_device(), which will stall\nswapoff(). There was an extra check in _swap_info_get() to confirm that\nthe swap entry was not free. This isn\u0026apos;t present in get_swap_device()\nbecause it doesn\u0026apos;t make sense in general due to the race between getting\nthe reference and swapoff. So I\u0026apos;ve added an equivalent check directly in\nfree_swap_and_cache().\r\n\r\nDetails of how to provoke one possible issue (thanks to David Hildenbrand\nfor deriving this):\r\n\r\n--8\u0026lt;-----\r\n\r\n__swap_entry_free() might be the last user and result in\n\u0026quot;count == SWAP_HAS_CACHE\u0026quot;.\r\n\r\nswapoff-\u0026gt;try_to_unuse() will stop as soon as soon as si-\u0026gt;inuse_pages==0.\r\n\r\nSo the question is: could someone reclaim the folio and turn\nsi-\u0026gt;inuse_pages==0, before we completed swap_page_trans_huge_swapped().\r\n\r\nImagine the following: 2 MiB folio in the swapcache. Only 2 subpages are\nstill references by swap entries.\r\n\r\nProcess 1 still references subpage 0 via swap entry.\nProcess 2 still references subpage 1 via swap entry.\r\n\r\nProcess 1 quits. Calls free_swap_and_cache().\n-\u0026gt; count == SWAP_HAS_CACHE\n[then, preempted in the hypervisor etc.]\r\n\r\nProcess 2 quits. Calls free_swap_and_cache().\n-\u0026gt; count == SWAP_HAS_CACHE\r\n\r\nProcess 2 goes ahead, passes swap_page_trans_huge_swapped(), and calls\n__try_to_reclaim_swap().\r\n\r\n__try_to_reclaim_swap()-\u0026gt;folio_free_swap()-\u0026gt;delete_from_swap_cache()-\u0026gt;\nput_swap_folio()-\u0026gt;free_swap_slot()-\u0026gt;swapcache_free_entries()-\u0026gt;\nswap_entry_free()-\u0026gt;swap_range_free()-\u0026gt;\n...\nWRITE_ONCE(si-\u0026gt;inuse_pages, si-\u0026gt;inuse_pages - nr_entries);\r\n\r\nWhat stops swapoff to succeed after process 2 reclaimed the swap cache\nbut before process1 finished its call to swap_page_trans_huge_swapped()?\r\n\r\n--8\u0026lt;-----(CVE-2024-26960)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/mlx5e: Prevent deadlock while disabling aRFS\r\n\r\nWhen disabling aRFS under the `priv-\u0026gt;state_lock`, any scheduled\naRFS works are canceled using the `cancel_work_sync` function,\nwhich waits for the work to end if it has already started.\nHowever, while waiting for the work handler, the handler will\ntry to acquire the `state_lock` which is already acquired.\r\n\r\nThe worker acquires the lock to delete the rules if the state\nis down, which is not the worker\u0026apos;s responsibility since\ndisabling aRFS deletes the rules.\r\n\r\nAdd an aRFS state variable, which indicates whether the aRFS is\nenabled and prevent adding rules when the aRFS is disabled.\r\n\r\nKernel log:\r\n\r\n======================================================\nWARNING: possible circular locking dependency detected\n6.7.0-rc4_net_next_mlx5_5483eb2 #1 Tainted: G I\n------------------------------------------------------\nethtool/386089 is trying to acquire lock:\nffff88810f21ce68 ((work_completion)(\u0026amp;rule-\u0026gt;arfs_work)){+.+.}-{0:0}, at: __flush_work+0x74/0x4e0\r\n\r\nbut task is already holding lock:\nffff8884a1808cc0 (\u0026amp;priv-\u0026gt;state_lock){+.+.}-{3:3}, at: mlx5e_ethtool_set_channels+0x53/0x200 [mlx5_core]\r\n\r\nwhich lock already depends on the new lock.\r\n\r\nthe existing dependency chain (in reverse order) is:\r\n\r\n-\u0026gt; #1 (\u0026amp;priv-\u0026gt;state_lock){+.+.}-{3:3}:\n __mutex_lock+0x80/0xc90\n arfs_handle_work+0x4b/0x3b0 [mlx5_core]\n process_one_work+0x1dc/0x4a0\n worker_thread+0x1bf/0x3c0\n kthread+0xd7/0x100\n ret_from_fork+0x2d/0x50\n ret_from_fork_asm+0x11/0x20\r\n\r\n-\u0026gt; #0 ((work_completion)(\u0026amp;rule-\u0026gt;arfs_work)){+.+.}-{0:0}:\n __lock_acquire+0x17b4/0x2c80\n lock_acquire+0xd0/0x2b0\n __flush_work+0x7a/0x4e0\n __cancel_work_timer+0x131/0x1c0\n arfs_del_rules+0x143/0x1e0 [mlx5_core]\n mlx5e_arfs_disable+0x1b/0x30 [mlx5_core]\n mlx5e_ethtool_set_channels+0xcb/0x200 [mlx5_core]\n ethnl_set_channels+0x28f/0x3b0\n ethnl_default_set_doit+0xec/0x240\n genl_family_rcv_msg_doit+0xd0/0x120\n genl_rcv_msg+0x188/0x2c0\n netlink_rcv_skb+0x54/0x100\n genl_rcv+0x24/0x40\n netlink_unicast+0x1a1/0x270\n netlink_sendmsg+0x214/0x460\n __sock_sendmsg+0x38/0x60\n __sys_sendto+0x113/0x170\n __x64_sys_sendto+0x20/0x30\n do_syscall_64+0x40/0xe0\n entry_SYSCALL_64_after_hwframe+0x46/0x4e\r\n\r\nother info that might help us debug this:\r\n\r\n Possible unsafe locking scenario:\r\n\r\n CPU0 CPU1\n ---- ----\n lock(\u0026amp;priv-\u0026gt;state_lock);\n lock((work_completion)(\u0026amp;rule-\u0026gt;arfs_work));\n lock(\u0026amp;priv-\u0026gt;state_lock);\n lock((work_completion)(\u0026amp;rule-\u0026gt;arfs_work));\r\n\r\n *** DEADLOCK ***\r\n\r\n3 locks held by ethtool/386089:\n #0: ffffffff82ea7210 (cb_lock){++++}-{3:3}, at: genl_rcv+0x15/0x40\n #1: ffffffff82e94c88 (rtnl_mutex){+.+.}-{3:3}, at: ethnl_default_set_doit+0xd3/0x240\n #2: ffff8884a1808cc0 (\u0026amp;priv-\u0026gt;state_lock){+.+.}-{3:3}, at: mlx5e_ethtool_set_channels+0x53/0x200 [mlx5_core]\r\n\r\nstack backtrace:\nCPU: 15 PID: 386089 Comm: ethtool Tainted: G I 6.7.0-rc4_net_next_mlx5_5483eb2 #1\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x60/0xa0\n check_noncircular+0x144/0x160\n __lock_acquire+0x17b4/0x2c80\n lock_acquire+0xd0/0x2b0\n ? __flush_work+0x74/0x4e0\n ? save_trace+0x3e/0x360\n ? __flush_work+0x74/0x4e0\n __flush_work+0x7a/0x4e0\n ? __flush_work+0x74/0x4e0\n ? __lock_acquire+0xa78/0x2c80\n ? lock_acquire+0xd0/0x2b0\n ? mark_held_locks+0x49/0x70\n __cancel_work_timer+0x131/0x1c0\n ? mark_held_locks+0x49/0x70\n arfs_del_rules+0x143/0x1e0 [mlx5_core]\n mlx5e_arfs_disable+0x1b/0x30 [mlx5_core]\n mlx5e_ethtool_set_channels+0xcb/0x200 [mlx5_core]\n ethnl_set_channels+0x28f/0x3b0\n ethnl_default_set_doit+0xec/0x240\n genl_family_rcv_msg_doit+0xd0/0x120\n genl_rcv_msg+0x188/0x2c0\n ? ethn\n---truncated---(CVE-2024-27014)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nf_tables: Fix potential data-race in __nft_obj_type_get()\r\n\r\nnft_unregister_obj() can concurrent with __nft_obj_type_get(),\nand there is not any protection when iterate over nf_tables_objects\nlist in __nft_obj_type_get(). Therefore, there is potential data-race\nof nf_tables_objects list entry.\r\n\r\nUse list_for_each_entry_rcu() to iterate over nf_tables_objects\nlist in __nft_obj_type_get(), and use rcu_read_lock() in the caller\nnft_obj_type_get() to protect the entire type query process.(CVE-2024-27019)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Fix potential NULL pointer dereferences in \u0026apos;dcn10_set_output_transfer_func()\u0026apos;\r\n\r\nThe \u0026apos;stream\u0026apos; pointer is used in dcn10_set_output_transfer_func() before\nthe check if \u0026apos;stream\u0026apos; is NULL.\r\n\r\nFixes the below:\ndrivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn10/dcn10_hwseq.c:1892 dcn10_set_output_transfer_func() warn: variable dereferenced before check \u0026apos;stream\u0026apos; (see line 1875)(CVE-2024-27044)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: ll_temac: platform_get_resource replaced by wrong function\r\n\r\nThe function platform_get_resource was replaced with\ndevm_platform_ioremap_resource_byname and is called using 0 as name.\r\n\r\nThis eventually ends up in platform_get_resource_byname in the call\nstack, where it causes a null pointer in strcmp.\r\n\r\n\tif (type == resource_type(r) \u0026amp;\u0026amp; !strcmp(r-\u0026gt;name, name))\r\n\r\nIt should have been replaced with devm_platform_ioremap_resource.(CVE-2024-35796)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfs/aio: Check IOCB_AIO_RW before the struct aio_kiocb conversion\r\n\r\nThe first kiocb_set_cancel_fn() argument may point at a struct kiocb\nthat is not embedded inside struct aio_kiocb. With the current code,\ndepending on the compiler, the req-\u0026gt;ki_ctx read happens either before\nthe IOCB_AIO_RW test or after that test. Move the req-\u0026gt;ki_ctx read such\nthat it is guaranteed that the IOCB_AIO_RW test happens first.(CVE-2024-35815)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsoc: fsl: qbman: Use raw spinlock for cgr_lock\r\n\r\nsmp_call_function always runs its callback in hard IRQ context, even on\nPREEMPT_RT, where spinlocks can sleep. So we need to use a raw spinlock\nfor cgr_lock to ensure we aren\u0026apos;t waiting on a sleeping task.\r\n\r\nAlthough this bug has existed for a while, it was not apparent until\ncommit ef2a8d5478b9 (\u0026quot;net: dpaa: Adjust queue depth on rate change\u0026quot;)\nwhich invokes smp_call_function_single via qman_update_cgr_safe every\ntime a link goes up or down.(CVE-2024-35819)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: libertas: fix some memleaks in lbs_allocate_cmd_buffer()\r\n\r\nIn the for statement of lbs_allocate_cmd_buffer(), if the allocation of\ncmdarray[i].cmdbuf fails, both cmdarray and cmdarray[i].cmdbuf needs to\nbe freed. Otherwise, there will be memleaks in lbs_allocate_cmd_buffer().(CVE-2024-35828)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: bridge: replace physindev with physinif in nf_bridge_info\r\n\r\nAn skb can be added to a neigh-\u0026gt;arp_queue while waiting for an arp\nreply. Where original skb\u0026apos;s skb-\u0026gt;dev can be different to neigh\u0026apos;s\nneigh-\u0026gt;dev. For instance in case of bridging dnated skb from one veth to\nanother, the skb would be added to a neigh-\u0026gt;arp_queue of the bridge.\r\n\r\nAs skb-\u0026gt;dev can be reset back to nf_bridge-\u0026gt;physindev and used, and as\nthere is no explicit mechanism that prevents this physindev from been\nfreed under us (for instance neigh_flush_dev doesn\u0026apos;t cleanup skbs from\ndifferent device\u0026apos;s neigh queue) we can crash on e.g. this stack:\r\n\r\narp_process\n neigh_update\n skb = __skb_dequeue(\u0026amp;neigh-\u0026gt;arp_queue)\n neigh_resolve_output(..., skb)\n ...\n br_nf_dev_xmit\n br_nf_pre_routing_finish_bridge_slow\n skb-\u0026gt;dev = nf_bridge-\u0026gt;physindev\n br_handle_frame_finish\r\n\r\nLet\u0026apos;s use plain ifindex instead of net_device link. To peek into the\noriginal net_device we will use dev_get_by_index_rcu(). Thus either we\nget device and are safe to use it or we don\u0026apos;t get it and drop skb.(CVE-2024-35839)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsmb: client: fix UAF in smb2_reconnect_server()\r\n\r\nThe UAF bug is due to smb2_reconnect_server() accessing a session that\nis already being teared down by another thread that is executing\n__cifs_put_smb_ses(). This can happen when (a) the client has\nconnection to the server but no session or (b) another thread ends up\nsetting @ses-\u0026gt;ses_status again to something different than\nSES_EXITING.\r\n\r\nTo fix this, we need to make sure to unconditionally set\n@ses-\u0026gt;ses_status to SES_EXITING and prevent any other threads from\nsetting a new status while we\u0026apos;re still tearing it down.\r\n\r\nThe following can be reproduced by adding some delay to right after\nthe ipc is freed in __cifs_put_smb_ses() - which will give\nsmb2_reconnect_server() worker a chance to run and then accessing\n@ses-\u0026gt;ipc:\r\n\r\nkinit ...\nmount.cifs //srv/share /mnt/1 -o sec=krb5,nohandlecache,echo_interval=10\n[disconnect srv]\nls /mnt/1 \u0026amp;\u0026gt;/dev/null\nsleep 30\nkdestroy\n[reconnect srv]\nsleep 10\numount /mnt/1\n...\nCIFS: VFS: Verify user has a krb5 ticket and keyutils is installed\nCIFS: VFS: \\\\srv Send error in SessSetup = -126\nCIFS: VFS: Verify user has a krb5 ticket and keyutils is installed\nCIFS: VFS: \\\\srv Send error in SessSetup = -126\ngeneral protection fault, probably for non-canonical address\n0x6b6b6b6b6b6b6b6b: 0000 [#1] PREEMPT SMP NOPTI\nCPU: 3 PID: 50 Comm: kworker/3:1 Not tainted 6.9.0-rc2 #1\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-1.fc39\n04/01/2014\nWorkqueue: cifsiod smb2_reconnect_server [cifs]\nRIP: 0010:__list_del_entry_valid_or_report+0x33/0xf0\nCode: 4f 08 48 85 d2 74 42 48 85 c9 74 59 48 b8 00 01 00 00 00 00 ad\nde 48 39 c2 74 61 48 b8 22 01 00 00 00 00 74 69 \u0026lt;48\u0026gt; 8b 01 48 39 f8 75\n7b 48 8b 72 08 48 39 c6 0f 85 88 00 00 00 b8\nRSP: 0018:ffffc900001bfd70 EFLAGS: 00010a83\nRAX: dead000000000122 RBX: ffff88810da53838 RCX: 6b6b6b6b6b6b6b6b\nRDX: 6b6b6b6b6b6b6b6b RSI: ffffffffc02f6878 RDI: ffff88810da53800\nRBP: ffff88810da53800 R08: 0000000000000001 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000001 R12: ffff88810c064000\nR13: 0000000000000001 R14: ffff88810c064000 R15: ffff8881039cc000\nFS: 0000000000000000(0000) GS:ffff888157c00000(0000)\nknlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007fe3728b1000 CR3: 000000010caa4000 CR4: 0000000000750ef0\nPKRU: 55555554\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? die_addr+0x36/0x90\n ? exc_general_protection+0x1c1/0x3f0\n ? asm_exc_general_protection+0x26/0x30\n ? __list_del_entry_valid_or_report+0x33/0xf0\n __cifs_put_smb_ses+0x1ae/0x500 [cifs]\n smb2_reconnect_server+0x4ed/0x710 [cifs]\n process_one_work+0x205/0x6b0\n worker_thread+0x191/0x360\n ? __pfx_worker_thread+0x10/0x10\n kthread+0xe2/0x110\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x34/0x50\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1a/0x30\n \u0026lt;/TASK\u0026gt;(CVE-2024-35870)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nax25: fix use-after-free bugs caused by ax25_ds_del_timer\r\n\r\nWhen the ax25 device is detaching, the ax25_dev_device_down()\ncalls ax25_ds_del_timer() to cleanup the slave_timer. When\nthe timer handler is running, the ax25_ds_del_timer() that\ncalls del_timer() in it will return directly. As a result,\nthe use-after-free bugs could happen, one of the scenarios\nis shown below:\r\n\r\n (Thread 1) | (Thread 2)\n | ax25_ds_timeout()\nax25_dev_device_down() |\n ax25_ds_del_timer() |\n del_timer() |\n ax25_dev_put() //FREE |\n | ax25_dev-\u0026gt; //USE\r\n\r\nIn order to mitigate bugs, when the device is detaching, use\ntimer_shutdown_sync() to stop the timer.(CVE-2024-35887)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntcp: properly terminate timers for kernel sockets\r\n\r\nWe had various syzbot reports about tcp timers firing after\nthe corresponding netns has been dismantled.\r\n\r\nFortunately Josef Bacik could trigger the issue more often,\nand could test a patch I wrote two years ago.\r\n\r\nWhen TCP sockets are closed, we call inet_csk_clear_xmit_timers()\nto \u0026apos;stop\u0026apos; the timers.\r\n\r\ninet_csk_clear_xmit_timers() can be called from any context,\nincluding when socket lock is held.\nThis is the reason it uses sk_stop_timer(), aka del_timer().\nThis means that ongoing timers might finish much later.\r\n\r\nFor user sockets, this is fine because each running timer\nholds a reference on the socket, and the user socket holds\na reference on the netns.\r\n\r\nFor kernel sockets, we risk that the netns is freed before\ntimer can complete, because kernel sockets do not hold\nreference on the netns.\r\n\r\nThis patch adds inet_csk_clear_xmit_timers_sync() function\nthat using sk_stop_timer_sync() to make sure all timers\nare terminated before the kernel socket is released.\nModules using kernel sockets close them in their netns exit()\nhandler.\r\n\r\nAlso add sock_not_owned_by_me() helper to get LOCKDEP\nsupport : inet_csk_clear_xmit_timers_sync() must not be called\nwhile socket lock is held.\r\n\r\nIt is very possible we can revert in the future commit\n3a58f13a881e (\u0026quot;net: rds: acquire refcount on TCP sockets\u0026quot;)\nwhich attempted to solve the issue in rds only.\n(net/smc/af_smc.c and net/mptcp/subflow.c have similar code)\r\n\r\nWe probably can remove the check_net() tests from\ntcp_out_of_resources() and __tcp_close() in the future.(CVE-2024-35910)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/vc4: don\u0026apos;t check if plane-\u0026gt;state-\u0026gt;fb == state-\u0026gt;fb\r\n\r\nCurrently, when using non-blocking commits, we can see the following\nkernel warning:\r\n\r\n[ 110.908514] ------------[ cut here ]------------\n[ 110.908529] refcount_t: underflow; use-after-free.\n[ 110.908620] WARNING: CPU: 0 PID: 1866 at lib/refcount.c:87 refcount_dec_not_one+0xb8/0xc0\n[ 110.908664] Modules linked in: rfcomm snd_seq_dummy snd_hrtimer snd_seq snd_seq_device cmac algif_hash aes_arm64 aes_generic algif_skcipher af_alg bnep hid_logitech_hidpp vc4 brcmfmac hci_uart btbcm brcmutil bluetooth snd_soc_hdmi_codec cfg80211 cec drm_display_helper drm_dma_helper drm_kms_helper snd_soc_core snd_compress snd_pcm_dmaengine fb_sys_fops sysimgblt syscopyarea sysfillrect raspberrypi_hwmon ecdh_generic ecc rfkill libaes i2c_bcm2835 binfmt_misc joydev snd_bcm2835(C) bcm2835_codec(C) bcm2835_isp(C) v4l2_mem2mem videobuf2_dma_contig snd_pcm bcm2835_v4l2(C) raspberrypi_gpiomem bcm2835_mmal_vchiq(C) videobuf2_v4l2 snd_timer videobuf2_vmalloc videobuf2_memops videobuf2_common snd videodev vc_sm_cma(C) mc hid_logitech_dj uio_pdrv_genirq uio i2c_dev drm fuse dm_mod drm_panel_orientation_quirks backlight ip_tables x_tables ipv6\n[ 110.909086] CPU: 0 PID: 1866 Comm: kodi.bin Tainted: G C 6.1.66-v8+ #32\n[ 110.909104] Hardware name: Raspberry Pi 3 Model B Rev 1.2 (DT)\n[ 110.909114] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[ 110.909132] pc : refcount_dec_not_one+0xb8/0xc0\n[ 110.909152] lr : refcount_dec_not_one+0xb4/0xc0\n[ 110.909170] sp : ffffffc00913b9c0\n[ 110.909177] x29: ffffffc00913b9c0 x28: 000000556969bbb0 x27: 000000556990df60\n[ 110.909205] x26: 0000000000000002 x25: 0000000000000004 x24: ffffff8004448480\n[ 110.909230] x23: ffffff800570b500 x22: ffffff802e03a7bc x21: ffffffecfca68c78\n[ 110.909257] x20: ffffff8002b42000 x19: ffffff802e03a600 x18: 0000000000000000\n[ 110.909283] x17: 0000000000000011 x16: ffffffffffffffff x15: 0000000000000004\n[ 110.909308] x14: 0000000000000fff x13: ffffffed577e47e0 x12: 0000000000000003\n[ 110.909333] x11: 0000000000000000 x10: 0000000000000027 x9 : c912d0d083728c00\n[ 110.909359] x8 : c912d0d083728c00 x7 : 65646e75203a745f x6 : 746e756f63666572\n[ 110.909384] x5 : ffffffed579f62ee x4 : ffffffed579eb01e x3 : 0000000000000000\n[ 110.909409] x2 : 0000000000000000 x1 : ffffffc00913b750 x0 : 0000000000000001\n[ 110.909434] Call trace:\n[ 110.909441] refcount_dec_not_one+0xb8/0xc0\n[ 110.909461] vc4_bo_dec_usecnt+0x4c/0x1b0 [vc4]\n[ 110.909903] vc4_cleanup_fb+0x44/0x50 [vc4]\n[ 110.910315] drm_atomic_helper_cleanup_planes+0x88/0xa4 [drm_kms_helper]\n[ 110.910669] vc4_atomic_commit_tail+0x390/0x9dc [vc4]\n[ 110.911079] commit_tail+0xb0/0x164 [drm_kms_helper]\n[ 110.911397] drm_atomic_helper_commit+0x1d0/0x1f0 [drm_kms_helper]\n[ 110.911716] drm_atomic_commit+0xb0/0xdc [drm]\n[ 110.912569] drm_mode_atomic_ioctl+0x348/0x4b8 [drm]\n[ 110.913330] drm_ioctl_kernel+0xec/0x15c [drm]\n[ 110.914091] drm_ioctl+0x24c/0x3b0 [drm]\n[ 110.914850] __arm64_sys_ioctl+0x9c/0xd4\n[ 110.914873] invoke_syscall+0x4c/0x114\n[ 110.914897] el0_svc_common+0xd0/0x118\n[ 110.914917] do_el0_svc+0x38/0xd0\n[ 110.914936] el0_svc+0x30/0x8c\n[ 110.914958] el0t_64_sync_handler+0x84/0xf0\n[ 110.914979] el0t_64_sync+0x18c/0x190\n[ 110.914996] ---[ end trace 0000000000000000 ]---\r\n\r\nThis happens because, although `prepare_fb` and `cleanup_fb` are\nperfectly balanced, we cannot guarantee consistency in the check\nplane-\u0026gt;state-\u0026gt;fb == state-\u0026gt;fb. This means that sometimes we can increase\nthe refcount in `prepare_fb` and don\u0026apos;t decrease it in `cleanup_fb`. The\nopposite can also be true.\r\n\r\nIn fact, the struct drm_plane .state shouldn\u0026apos;t be accessed directly\nbut instead, the `drm_atomic_get_new_plane_state()` helper function should\nbe used. So, we could stick to this check, but using\n`drm_atomic_get_new_plane_state()`. But actually, this check is not re\n---truncated---(CVE-2024-35932)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: send: handle path ref underflow in header iterate_inode_ref()\r\n\r\nChange BUG_ON to proper error handling if building the path buffer\nfails. The pointers are not printed so we don\u0026apos;t accidentally leak kernel\naddresses.(CVE-2024-35935)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: cfg80211: check A-MSDU format more carefully\r\n\r\nIf it looks like there\u0026apos;s another subframe in the A-MSDU\nbut the header isn\u0026apos;t fully there, we can end up reading\ndata out of bounds, only to discard later. Make this a\nbit more careful and check if the subframe header can\neven be present.(CVE-2024-35937)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/panfrost: Fix the error path in panfrost_mmu_map_fault_addr()\r\n\r\nSubject: [PATCH] drm/panfrost: Fix the error path in\n panfrost_mmu_map_fault_addr()\r\n\r\nIf some the pages or sgt allocation failed, we shouldn\u0026apos;t release the\npages ref we got earlier, otherwise we will end up with unbalanced\nget/put_pages() calls. We should instead leave everything in place\nand let the BO release function deal with extra cleanup when the object\nis destroyed, or let the fault handler try again next time it\u0026apos;s called.(CVE-2024-35951)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nBluetooth: L2CAP: Fix not validating setsockopt user input\r\n\r\nCheck user input length before copying data.(CVE-2024-35965)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nBluetooth: RFCOMM: Fix not validating setsockopt user input\r\n\r\nsyzbot reported rfcomm_sock_setsockopt_old() is copying data without\nchecking user input length.\r\n\r\nBUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset\ninclude/linux/sockptr.h:49 [inline]\nBUG: KASAN: slab-out-of-bounds in copy_from_sockptr\ninclude/linux/sockptr.h:55 [inline]\nBUG: KASAN: slab-out-of-bounds in rfcomm_sock_setsockopt_old\nnet/bluetooth/rfcomm/sock.c:632 [inline]\nBUG: KASAN: slab-out-of-bounds in rfcomm_sock_setsockopt+0x893/0xa70\nnet/bluetooth/rfcomm/sock.c:673\nRead of size 4 at addr ffff8880209a8bc3 by task syz-executor632/5064(CVE-2024-35966)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbatman-adv: Avoid infinite loop trying to resize local TT\r\n\r\nIf the MTU of one of an attached interface becomes too small to transmit\nthe local translation table then it must be resized to fit inside all\nfragments (when enabled) or a single packet.\r\n\r\nBut if the MTU becomes too low to transmit even the header + the VLAN\nspecific part then the resizing of the local TT will never succeed. This\ncan for example happen when the usable space is 110 bytes and 11 VLANs are\non top of batman-adv. In this case, at least 116 byte would be needed.\nThere will just be an endless spam of\r\n\r\n batman_adv: batadv0: Forced to purge local tt entries to fit new maximum fragment MTU (110)\r\n\r\nin the log but the function will never finish. Problem here is that the\ntimeout will be halved all the time and will then stagnate at 0 and\ntherefore never be able to reduce the table even more.\r\n\r\nThere are other scenarios possible with a similar result. The number of\nBATADV_TT_CLIENT_NOPURGE entries in the local TT can for example be too\nhigh to fit inside a packet. Such a scenario can therefore happen also with\nonly a single VLAN + 7 non-purgable addresses - requiring at least 120\nbytes.\r\n\r\nWhile this should be handled proactively when:\r\n\r\n* interface with too low MTU is added\n* VLAN is added\n* non-purgeable local mac is added\n* MTU of an attached interface is reduced\n* fragmentation setting gets disabled (which most likely requires dropping\n attached interfaces)\r\n\r\nnot all of these scenarios can be prevented because batman-adv is only\nconsuming events without the the possibility to prevent these actions\n(non-purgable MAC address added, MTU of an attached interface is reduced).\nIt is therefore necessary to also make sure that the code is able to handle\nalso the situations when there were already incompatible system\nconfiguration are present.(CVE-2024-35982)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntty: n_gsm: fix possible out-of-bounds in gsm0_receive()\r\n\r\nAssuming the following:\n- side A configures the n_gsm in basic option mode\n- side B sends the header of a basic option mode frame with data length 1\n- side A switches to advanced option mode\n- side B sends 2 data bytes which exceeds gsm-\u0026gt;len\n Reason: gsm-\u0026gt;len is not used in advanced option mode.\n- side A switches to basic option mode\n- side B keeps sending until gsm0_receive() writes past gsm-\u0026gt;buf\n Reason: Neither gsm-\u0026gt;state nor gsm-\u0026gt;len have been reset after\n reconfiguration.\r\n\r\nFix this by changing gsm-\u0026gt;count to gsm-\u0026gt;len comparison from equal to less\nthan. Also add upper limit checks against the constant MAX_MRU in\ngsm0_receive() and gsm1_receive() to harden against memory corruption of\ngsm-\u0026gt;len and gsm-\u0026gt;mru.\r\n\r\nAll other checks remain as we still need to limit the data according to the\nuser configuration and actual payload size.(CVE-2024-36016)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nblk-iocost: avoid out of bounds shift\r\n\r\nUBSAN catches undefined behavior in blk-iocost, where sometimes\niocg-\u0026gt;delay is shifted right by a number that is too large,\nresulting in undefined behavior on some architectures.\r\n\r\n[ 186.556576] ------------[ cut here ]------------\nUBSAN: shift-out-of-bounds in block/blk-iocost.c:1366:23\nshift exponent 64 is too large for 64-bit type \u0026apos;u64\u0026apos; (aka \u0026apos;unsigned long long\u0026apos;)\nCPU: 16 PID: 0 Comm: swapper/16 Tainted: G S E N 6.9.0-0_fbk700_debug_rc2_kbuilder_0_gc85af715cac0 #1\nHardware name: Quanta Twin Lakes MP/Twin Lakes Passive MP, BIOS F09_3A23 12/08/2020\nCall Trace:\n \u0026lt;IRQ\u0026gt;\n dump_stack_lvl+0x8f/0xe0\n __ubsan_handle_shift_out_of_bounds+0x22c/0x280\n iocg_kick_delay+0x30b/0x310\n ioc_timer_fn+0x2fb/0x1f80\n __run_timer_base+0x1b6/0x250\n...\r\n\r\nAvoid that undefined behavior by simply taking the\n\u0026quot;delay = 0\u0026quot; branch if the shift is too large.\r\n\r\nI am not sure what the symptoms of an undefined value\ndelay will be, but I suspect it could be more than a\nlittle annoying to debug.(CVE-2024-36916)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nblock: fix overflow in blk_ioctl_discard()\r\n\r\nThere is no check for overflow of \u0026apos;start + len\u0026apos; in blk_ioctl_discard().\nHung task occurs if submit an discard ioctl with the following param:\n start = 0x80000000000ff000, len = 0x8000000000fff000;\nAdd the overflow validation now.(CVE-2024-36917)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: bnx2fc: Remove spin_lock_bh while releasing resources after upload\r\n\r\nThe session resources are used by FW and driver when session is offloaded,\nonce session is uploaded these resources are not used. The lock is not\nrequired as these fields won\u0026apos;t be used any longer. The offload and upload\ncalls are sequential, hence lock is not required.\r\n\r\nThis will suppress following BUG_ON():\r\n\r\n[ 449.843143] ------------[ cut here ]------------\n[ 449.848302] kernel BUG at mm/vmalloc.c:2727!\n[ 449.853072] invalid opcode: 0000 [#1] PREEMPT SMP PTI\n[ 449.858712] CPU: 5 PID: 1996 Comm: kworker/u24:2 Not tainted 5.14.0-118.el9.x86_64 #1\nRebooting.\n[ 449.867454] Hardware name: Dell Inc. PowerEdge R730/0WCJNT, BIOS 2.3.4 11/08/2016\n[ 449.876966] Workqueue: fc_rport_eq fc_rport_work [libfc]\n[ 449.882910] RIP: 0010:vunmap+0x2e/0x30\n[ 449.887098] Code: 00 65 8b 05 14 a2 f0 4a a9 00 ff ff 00 75 1b 55 48 89 fd e8 34 36 79 00 48 85 ed 74 0b 48 89 ef 31 f6 5d e9 14 fc ff ff 5d c3 \u0026lt;0f\u0026gt; 0b 0f 1f 44 00 00 41 57 41 56 49 89 ce 41 55 49 89 fd 41 54 41\n[ 449.908054] RSP: 0018:ffffb83d878b3d68 EFLAGS: 00010206\n[ 449.913887] RAX: 0000000080000201 RBX: ffff8f4355133550 RCX: 000000000d400005\n[ 449.921843] RDX: 0000000000000001 RSI: 0000000000001000 RDI: ffffb83da53f5000\n[ 449.929808] RBP: ffff8f4ac6675800 R08: ffffb83d878b3d30 R09: 00000000000efbdf\n[ 449.937774] R10: 0000000000000003 R11: ffff8f434573e000 R12: 0000000000001000\n[ 449.945736] R13: 0000000000001000 R14: ffffb83da53f5000 R15: ffff8f43d4ea3ae0\n[ 449.953701] FS: 0000000000000000(0000) GS:ffff8f529fc80000(0000) knlGS:0000000000000000\n[ 449.962732] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 449.969138] CR2: 00007f8cf993e150 CR3: 0000000efbe10003 CR4: 00000000003706e0\n[ 449.977102] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[ 449.985065] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[ 449.993028] Call Trace:\n[ 449.995756] __iommu_dma_free+0x96/0x100\n[ 450.000139] bnx2fc_free_session_resc+0x67/0x240 [bnx2fc]\n[ 450.006171] bnx2fc_upload_session+0xce/0x100 [bnx2fc]\n[ 450.011910] bnx2fc_rport_event_handler+0x9f/0x240 [bnx2fc]\n[ 450.018136] fc_rport_work+0x103/0x5b0 [libfc]\n[ 450.023103] process_one_work+0x1e8/0x3c0\n[ 450.027581] worker_thread+0x50/0x3b0\n[ 450.031669] ? rescuer_thread+0x370/0x370\n[ 450.036143] kthread+0x149/0x170\n[ 450.039744] ? set_kthread_struct+0x40/0x40\n[ 450.044411] ret_from_fork+0x22/0x30\n[ 450.048404] Modules linked in: vfat msdos fat xfs nfs_layout_nfsv41_files rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver dm_service_time qedf qed crc8 bnx2fc libfcoe libfc scsi_transport_fc intel_rapl_msr intel_rapl_common x86_pkg_temp_thermal intel_powerclamp dcdbas rapl intel_cstate intel_uncore mei_me pcspkr mei ipmi_ssif lpc_ich ipmi_si fuse zram ext4 mbcache jbd2 loop nfsv3 nfs_acl nfs lockd grace fscache netfs irdma ice sd_mod t10_pi sg ib_uverbs ib_core 8021q garp mrp stp llc mgag200 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt mxm_wmi fb_sys_fops cec crct10dif_pclmul ahci crc32_pclmul bnx2x drm ghash_clmulni_intel libahci rfkill i40e libata megaraid_sas mdio wmi sunrpc lrw dm_crypt dm_round_robin dm_multipath dm_snapshot dm_bufio dm_mirror dm_region_hash dm_log dm_zero dm_mod linear raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx raid6_pq libcrc32c crc32c_intel raid1 raid0 iscsi_ibft squashfs be2iscsi bnx2i cnic uio cxgb4i cxgb4 tls\n[ 450.048497] libcxgbi libcxgb qla4xxx iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi edd ipmi_devintf ipmi_msghandler\n[ 450.159753] ---[ end trace 712de2c57c64abc8 ]---(CVE-2024-36919)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ns390/qeth: Fix kernel panic after setting hsuid\r\n\r\nSymptom:\nWhen the hsuid attribute is set for the first time on an IQD Layer3\ndevice while the corresponding network interface is already UP,\nthe kernel will try to execute a napi function pointer that is NULL.\r\n\r\nExample:\n---------------------------------------------------------------------------\n[ 2057.572696] illegal operation: 0001 ilc:1 [#1] SMP\n[ 2057.572702] Modules linked in: af_iucv qeth_l3 zfcp scsi_transport_fc sunrpc nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6\nnft_reject nft_ct nf_tables_set nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables libcrc32c nfnetlink ghash_s390 prng xts aes_s390 des_s390 de\ns_generic sha3_512_s390 sha3_256_s390 sha512_s390 vfio_ccw vfio_mdev mdev vfio_iommu_type1 eadm_sch vfio ext4 mbcache jbd2 qeth_l2 bridge stp llc dasd_eckd_mod qeth dasd_mod\n qdio ccwgroup pkey zcrypt\n[ 2057.572739] CPU: 6 PID: 60182 Comm: stress_client Kdump: loaded Not tainted 4.18.0-541.el8.s390x #1\n[ 2057.572742] Hardware name: IBM 3931 A01 704 (LPAR)\n[ 2057.572744] Krnl PSW : 0704f00180000000 0000000000000002 (0x2)\n[ 2057.572748] R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:3 PM:0 RI:0 EA:3\n[ 2057.572751] Krnl GPRS: 0000000000000004 0000000000000000 00000000a3b008d8 0000000000000000\n[ 2057.572754] 00000000a3b008d8 cb923a29c779abc5 0000000000000000 00000000814cfd80\n[ 2057.572756] 000000000000012c 0000000000000000 00000000a3b008d8 00000000a3b008d8\n[ 2057.572758] 00000000bab6d500 00000000814cfd80 0000000091317e46 00000000814cfc68\n[ 2057.572762] Krnl Code:#0000000000000000: 0000 illegal\n \u0026gt;0000000000000002: 0000 illegal\n 0000000000000004: 0000 illegal\n 0000000000000006: 0000 illegal\n 0000000000000008: 0000 illegal\n 000000000000000a: 0000 illegal\n 000000000000000c: 0000 illegal\n 000000000000000e: 0000 illegal\n[ 2057.572800] Call Trace:\n[ 2057.572801] ([\u0026lt;00000000ec639700\u0026gt;] 0xec639700)\n[ 2057.572803] [\u0026lt;00000000913183e2\u0026gt;] net_rx_action+0x2ba/0x398\n[ 2057.572809] [\u0026lt;0000000091515f76\u0026gt;] __do_softirq+0x11e/0x3a0\n[ 2057.572813] [\u0026lt;0000000090ce160c\u0026gt;] do_softirq_own_stack+0x3c/0x58\n[ 2057.572817] ([\u0026lt;0000000090d2cbd6\u0026gt;] do_softirq.part.1+0x56/0x60)\n[ 2057.572822] [\u0026lt;0000000090d2cc60\u0026gt;] __local_bh_enable_ip+0x80/0x98\n[ 2057.572825] [\u0026lt;0000000091314706\u0026gt;] __dev_queue_xmit+0x2be/0xd70\n[ 2057.572827] [\u0026lt;000003ff803dd6d6\u0026gt;] afiucv_hs_send+0x24e/0x300 [af_iucv]\n[ 2057.572830] [\u0026lt;000003ff803dd88a\u0026gt;] iucv_send_ctrl+0x102/0x138 [af_iucv]\n[ 2057.572833] [\u0026lt;000003ff803de72a\u0026gt;] iucv_sock_connect+0x37a/0x468 [af_iucv]\n[ 2057.572835] [\u0026lt;00000000912e7e90\u0026gt;] __sys_connect+0xa0/0xd8\n[ 2057.572839] [\u0026lt;00000000912e9580\u0026gt;] sys_socketcall+0x228/0x348\n[ 2057.572841] [\u0026lt;0000000091514e1a\u0026gt;] system_call+0x2a6/0x2c8\n[ 2057.572843] Last Breaking-Event-Address:\n[ 2057.572844] [\u0026lt;0000000091317e44\u0026gt;] __napi_poll+0x4c/0x1d8\n[ 2057.572846]\n[ 2057.572847] Kernel panic - not syncing: Fatal exception in interrupt\n-------------------------------------------------------------------------------------------\r\n\r\nAnalysis:\nThere is one napi structure per out_q: card-\u0026gt;qdio.out_qs[i].napi\nThe napi.poll functions are set during qeth_open().\r\n\r\nSince\ncommit 1cfef80d4c2b (\u0026quot;s390/qeth: Don\u0026apos;t call dev_close/dev_open (DOWN/UP)\u0026quot;)\nqeth_set_offline()/qeth_set_online() no longer call dev_close()/\ndev_open(). So if qeth_free_qdio_queues() cleared\ncard-\u0026gt;qdio.out_qs[i].napi.poll while the network interface was UP and the\ncard was offline, they are not set again.\r\n\r\nReproduction:\nchzdev -e $devno layer2=0\nip link set dev $network_interface up\necho 0 \u0026gt; /sys/bus/ccw\n---truncated---(CVE-2024-36928)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: lpfc: Move NPIV\u0026apos;s transport unregistration to after resource clean up\r\n\r\nThere are cases after NPIV deletion where the fabric switch still believes\nthe NPIV is logged into the fabric. This occurs when a vport is\nunregistered before the Remove All DA_ID CT and LOGO ELS are sent to the\nfabric.\r\n\r\nCurrently fc_remove_host(), which calls dev_loss_tmo for all D_IDs including\nthe fabric D_ID, removes the last ndlp reference and frees the ndlp rport\nobject. This sometimes causes the race condition where the final DA_ID and\nLOGO are skipped from being sent to the fabric switch.\r\n\r\nFix by moving the fc_remove_host() and scsi_remove_host() calls after DA_ID\nand LOGO are sent.(CVE-2024-36952)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntipc: fix a possible memleak in tipc_buf_append\r\n\r\n__skb_linearize() doesn\u0026apos;t free the skb when it fails, so move\n\u0026apos;*buf = NULL\u0026apos; after __skb_linearize(), so that the skb can be\nfreed on the err path.(CVE-2024-36954)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/vmwgfx: Fix invalid reads in fence signaled events\r\n\r\nCorrectly set the length of the drm_event to the size of the structure\nthat\u0026apos;s actually used.\r\n\r\nThe length of the drm_event was set to the parent structure instead of\nto the drm_vmw_event_fence which is supposed to be read. drm_read\nuses the length parameter to copy the event to the user space thus\nresuling in oob reads.(CVE-2024-36960)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nBluetooth: L2CAP: Fix div-by-zero in l2cap_le_flowctl_init()\r\n\r\nl2cap_le_flowctl_init() can cause both div-by-zero and an integer\noverflow since hdev-\u0026gt;le_mtu may not fall in the valid range.\r\n\r\nMove MTU from hci_dev to hci_conn to validate MTU and stop the connection\nprocess earlier if MTU is invalid.\nAlso, add a missing validation in read_buffer_size() and make it return\nan error value if the validation fails.\nNow hci_conn_add() returns ERR_PTR() as it can fail due to the both a\nkzalloc failure and invalid MTU value.\r\n\r\ndivide error: 0000 [#1] PREEMPT SMP KASAN NOPTI\nCPU: 0 PID: 67 Comm: kworker/u5:0 Tainted: G W 6.9.0-rc5+ #20\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014\nWorkqueue: hci0 hci_rx_work\nRIP: 0010:l2cap_le_flowctl_init+0x19e/0x3f0 net/bluetooth/l2cap_core.c:547\nCode: e8 17 17 0c 00 66 41 89 9f 84 00 00 00 bf 01 00 00 00 41 b8 02 00 00 00 4c\n89 fe 4c 89 e2 89 d9 e8 27 17 0c 00 44 89 f0 31 d2 \u0026lt;66\u0026gt; f7 f3 89 c3 ff c3 4d 8d\nb7 88 00 00 00 4c 89 f0 48 c1 e8 03 42\nRSP: 0018:ffff88810bc0f858 EFLAGS: 00010246\nRAX: 00000000000002a0 RBX: 0000000000000000 RCX: dffffc0000000000\nRDX: 0000000000000000 RSI: ffff88810bc0f7c0 RDI: ffffc90002dcb66f\nRBP: ffff88810bc0f880 R08: aa69db2dda70ff01 R09: 0000ffaaaaaaaaaa\nR10: 0084000000ffaaaa R11: 0000000000000000 R12: ffff88810d65a084\nR13: dffffc0000000000 R14: 00000000000002a0 R15: ffff88810d65a000\nFS: 0000000000000000(0000) GS:ffff88811ac00000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000020000100 CR3: 0000000103268003 CR4: 0000000000770ef0\nPKRU: 55555554\nCall Trace:\n \u0026lt;TASK\u0026gt;\n l2cap_le_connect_req net/bluetooth/l2cap_core.c:4902 [inline]\n l2cap_le_sig_cmd net/bluetooth/l2cap_core.c:5420 [inline]\n l2cap_le_sig_channel net/bluetooth/l2cap_core.c:5486 [inline]\n l2cap_recv_frame+0xe59d/0x11710 net/bluetooth/l2cap_core.c:6809\n l2cap_recv_acldata+0x544/0x10a0 net/bluetooth/l2cap_core.c:7506\n hci_acldata_packet net/bluetooth/hci_core.c:3939 [inline]\n hci_rx_work+0x5e5/0xb20 net/bluetooth/hci_core.c:4176\n process_one_work kernel/workqueue.c:3254 [inline]\n process_scheduled_works+0x90f/0x1530 kernel/workqueue.c:3335\n worker_thread+0x926/0xe70 kernel/workqueue.c:3416\n kthread+0x2e3/0x380 kernel/kthread.c:388\n ret_from_fork+0x5c/0x90 arch/x86/kernel/process.c:147\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244\n \u0026lt;/TASK\u0026gt;\nModules linked in:\n---[ end trace 0000000000000000 ]---(CVE-2024-36968)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: fix __dst_negative_advice() race\r\n\r\n__dst_negative_advice() does not enforce proper RCU rules when\nsk-\u0026gt;dst_cache must be cleared, leading to possible UAF.\r\n\r\nRCU rules are that we must first clear sk-\u0026gt;sk_dst_cache,\nthen call dst_release(old_dst).\r\n\r\nNote that sk_dst_reset(sk) is implementing this protocol correctly,\nwhile __dst_negative_advice() uses the wrong order.\r\n\r\nGiven that ip6_negative_advice() has special logic\nagainst RTF_CACHE, this means each of the three -\u0026gt;negative_advice()\nexisting methods must perform the sk_dst_reset() themselves.\r\n\r\nNote the check against NULL dst is centralized in\n__dst_negative_advice(), there is no need to duplicate\nit in various callbacks.\r\n\r\nMany thanks to Clement Lecigne for tracking this issue.\r\n\r\nThis old bug became visible after the blamed commit, using UDP sockets.(CVE-2024-36971)",
"id": "OESA-2024-1737",
"modified": "2026-08-06T11:07:12Z",
"published": "2024-06-21T11:07:12Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1737"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47366"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48673"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48693"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52670"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52672"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52693"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52708"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52732"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52739"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52747"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52762"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52810"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52821"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52841"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52846"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52882"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26936"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26947"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26954"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26960"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27014"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27019"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27044"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35796"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35815"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35819"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35828"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35839"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35870"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35887"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35910"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35932"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35935"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35937"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35951"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35965"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35966"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35982"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36016"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36916"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36917"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36919"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36928"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36952"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36954"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36960"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36968"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36971"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2021-47366",
"CVE-2022-48673",
"CVE-2022-48693",
"CVE-2023-52670",
"CVE-2023-52672",
"CVE-2023-52693",
"CVE-2023-52708",
"CVE-2023-52732",
"CVE-2023-52739",
"CVE-2023-52747",
"CVE-2023-52762",
"CVE-2023-52810",
"CVE-2023-52821",
"CVE-2023-52841",
"CVE-2023-52846",
"CVE-2023-52882",
"CVE-2024-26936",
"CVE-2024-26947",
"CVE-2024-26954",
"CVE-2024-26960",
"CVE-2024-27014",
"CVE-2024-27019",
"CVE-2024-27044",
"CVE-2024-35796",
"CVE-2024-35815",
"CVE-2024-35819",
"CVE-2024-35828",
"CVE-2024-35839",
"CVE-2024-35870",
"CVE-2024-35887",
"CVE-2024-35910",
"CVE-2024-35932",
"CVE-2024-35935",
"CVE-2024-35937",
"CVE-2024-35951",
"CVE-2024-35965",
"CVE-2024-35966",
"CVE-2024-35982",
"CVE-2024-36016",
"CVE-2024-36916",
"CVE-2024-36917",
"CVE-2024-36919",
"CVE-2024-36928",
"CVE-2024-36952",
"CVE-2024-36954",
"CVE-2024-36960",
"CVE-2024-36968",
"CVE-2024-36971"
]
}
OESA-2024-1738 (CVE-2021-47366)
Vulnerability from osv_openeuler – Published: 2024-06-21 11:07 – Updated: 2026-08-06 11:07 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
afs: Fix corruption in reads at fpos 2G-4G from an OpenAFS server
AFS-3 has two data fetch RPC variants, FS.FetchData and FS.FetchData64, and Linux's afs client switches between them when talking to a non-YFS server if the read size, the file position or the sum of the two have the upper 32 bits set of the 64-bit value.
This is a problem, however, since the file position and length fields of FS.FetchData are signed 32-bit values.
Fix this by capturing the capability bits obtained from the fileserver when it's sent an FS.GetCapabilities RPC, rather than just discarding them, and then picking out the VICED_CAPABILITY_64BITFILES flag. This can then be used to decide whether to use FS.FetchData or FS.FetchData64 - and also FS.StoreData or FS.StoreData64 - rather than using upper_32_bits() to switch on the parameter values.
This capabilities flag could also be used to limit the maximum size of the file, but all servers must be checked for that.
Note that the issue does not exist with FS.StoreData - that uses unsigned 32-bit values. It's also not a problem with Auristor servers as its YFS.FetchData64 op uses unsigned 64-bit values.
This can be tested by cloning a git repo through an OpenAFS client to an OpenAFS server and then doing "git status" on it from a Linux afs client1. Provided the clone has a pack file that's in the 2G-4G range, the git status will show errors like:
error: packfile .git/objects/pack/pack-5e813c51d12b6847bbc0fcd97c2bca66da50079c.pack does not match index
error: packfile .git/objects/pack/pack-5e813c51d12b6847bbc0fcd97c2bca66da50079c.pack does not match index
This can be observed in the server's FileLog with something like the following appearing:
Sun Aug 29 19:31:39 2021 SRXAFS_FetchData, Fid = 2303380852.491776.3263114, Host 192.168.11.201:7001, Id 1001 Sun Aug 29 19:31:39 2021 CheckRights: len=0, for host=192.168.11.201:7001 Sun Aug 29 19:31:39 2021 FetchData_RXStyle: Pos 18446744071815340032, Len 3154 Sun Aug 29 19:31:39 2021 FetchData_RXStyle: file size 2400758866 ... Sun Aug 29 19:31:40 2021 SRXAFS_FetchData returns 5
Note the file position of 18446744071815340032. This is the requested file position sign-extended.(CVE-2021-47366)
In the Linux kernel, the following vulnerability has been resolved:
net/smc: Fix possible access to freed memory in link clear
After modifying the QP to the Error state, all RX WR would be completed with WC in IB_WC_WR_FLUSH_ERR status. Current implementation does not wait for it is done, but destroy the QP and free the link group directly. So there is a risk that accessing the freed memory in tasklet context.
Here is a crash example:
BUG: unable to handle page fault for address: ffffffff8f220860 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD f7300e067 P4D f7300e067 PUD f7300f063 PMD 8c4e45063 PTE 800ffff08c9df060 Oops: 0002 [#1] SMP PTI CPU: 1 PID: 0 Comm: swapper/1 Kdump: loaded Tainted: G S OE 5.10.0-0607+ #23 Hardware name: Inspur NF5280M4/YZMB-00689-101, BIOS 4.1.20 07/09/2018 RIP: 0010:native_queued_spin_lock_slowpath+0x176/0x1b0 Code: f3 90 48 8b 32 48 85 f6 74 f6 eb d5 c1 ee 12 83 e0 03 83 ee 01 48 c1 e0 05 48 63 f6 48 05 00 c8 02 00 48 03 04 f5 00 09 98 8e <48> 89 10 8b 42 08 85 c0 75 09 f3 90 8b 42 08 85 c0 74 f7 48 8b 32 RSP: 0018:ffffb3b6c001ebd8 EFLAGS: 00010086 RAX: ffffffff8f220860 RBX: 0000000000000246 RCX: 0000000000080000 RDX: ffff91db1f86c800 RSI: 000000000000173c RDI: ffff91db62bace00 RBP: ffff91db62bacc00 R08: 0000000000000000 R09: c00000010000028b R10: 0000000000055198 R11: ffffb3b6c001ea58 R12: ffff91db80e05010 R13: 000000000000000a R14: 0000000000000006 R15: 0000000000000040 FS: 0000000000000000(0000) GS:ffff91db1f840000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffff8f220860 CR3: 00000001f9580004 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <IRQ> _raw_spin_lock_irqsave+0x30/0x40 mlx5_ib_poll_cq+0x4c/0xc50 [mlx5_ib] smc_wr_rx_tasklet_fn+0x56/0xa0 [smc] tasklet_action_common.isra.21+0x66/0x100 __do_softirq+0xd5/0x29c asm_call_irq_on_stack+0x12/0x20 </IRQ> do_softirq_own_stack+0x37/0x40 irq_exit_rcu+0x9d/0xa0 sysvec_call_function_single+0x34/0x80 asm_sysvec_call_function_single+0x12/0x20(CVE-2022-48673)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/srp: Set scmnd->result only when scmnd is not NULL
This change fixes the following kernel NULL pointer dereference which is reproduced by blktests srp/007 occasionally.
BUG: kernel NULL pointer dereference, address: 0000000000000170 PGD 0 P4D 0 Oops: 0002 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 9 Comm: kworker/0:1H Kdump: loaded Not tainted 6.0.0-rc1+ #37 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.15.0-29-g6a62e0cb0dfe-prebuilt.qemu.org 04/01/2014 Workqueue: 0x0 (kblockd) RIP: 0010:srp_recv_done+0x176/0x500 [ib_srp] Code: 00 4d 85 ff 0f 84 52 02 00 00 48 c7 82 80 02 00 00 00 00 00 00 4c 89 df 4c 89 14 24 e8 53 d3 4a f6 4c 8b 14 24 41 0f b6 42 13 <41> 89 87 70 01 00 00 41 0f b6 52 12 f6 c2 02 74 44 41 8b 42 1c b9 RSP: 0018:ffffaef7c0003e28 EFLAGS: 00000282 RAX: 0000000000000000 RBX: ffff9bc9486dea60 RCX: 0000000000000000 RDX: 0000000000000102 RSI: ffffffffb76bbd0e RDI: 00000000ffffffff RBP: ffff9bc980099a00 R08: 0000000000000001 R09: 0000000000000001 R10: ffff9bca53ef0000 R11: ffff9bc980099a10 R12: ffff9bc956e14000 R13: ffff9bc9836b9cb0 R14: ffff9bc9557b4480 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff9bc97ec00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000170 CR3: 0000000007e04000 CR4: 00000000000006f0 Call Trace: <IRQ> __ib_process_cq+0xb7/0x280 [ib_core] ib_poll_handler+0x2b/0x130 [ib_core] irq_poll_softirq+0x93/0x150 __do_softirq+0xee/0x4b8 irq_exit_rcu+0xf7/0x130 sysvec_apic_timer_interrupt+0x8e/0xc0 </IRQ>(CVE-2022-48692)
In the Linux kernel, the following vulnerability has been resolved:
rpmsg: virtio: Free driver_override when rpmsg_remove()
Free driver_override when rpmsg_remove(), otherwise the following memory leak will occur:
unreferenced object 0xffff0000d55d7080 (size 128): comm "kworker/u8:2", pid 56, jiffies 4294893188 (age 214.272s) hex dump (first 32 bytes): 72 70 6d 73 67 5f 6e 73 00 00 00 00 00 00 00 00 rpmsg_ns........ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<000000009c94c9c1>] __kmem_cache_alloc_node+0x1f8/0x320 [<000000002300d89b>] __kmalloc_node_track_caller+0x44/0x70 [<00000000228a60c3>] kstrndup+0x4c/0x90 [<0000000077158695>] driver_set_override+0xd0/0x164 [<000000003e9c4ea5>] rpmsg_register_device_override+0x98/0x170 [<000000001c0c89a8>] rpmsg_ns_register_device+0x24/0x30 [<000000008bbf8fa2>] rpmsg_probe+0x2e0/0x3ec [<00000000e65a68df>] virtio_dev_probe+0x1c0/0x280 [<00000000443331cc>] really_probe+0xbc/0x2dc [<00000000391064b1>] __driver_probe_device+0x78/0xe0 [<00000000a41c9a5b>] driver_probe_device+0xd8/0x160 [<000000009c3bd5df>] __device_attach_driver+0xb8/0x140 [<0000000043cd7614>] bus_for_each_drv+0x7c/0xd4 [<000000003b929a36>] __device_attach+0x9c/0x19c [<00000000a94e0ba8>] device_initial_probe+0x14/0x20 [<000000003c999637>] bus_probe_device+0xa0/0xac(CVE-2023-52670)
In the Linux kernel, the following vulnerability has been resolved:
f2fs: avoid format-overflow warning
With gcc and W=1 option, there's a warning like this:
fs/f2fs/compress.c: In function ‘f2fs_init_page_array_cache’: fs/f2fs/compress.c:1984:47: error: ‘%u’ directive writing between 1 and 7 bytes into a region of size between 5 and 8 [-Werror=format-overflow=] 1984 | sprintf(slab_name, "f2fs_page_array_entry-%u:%u", MAJOR(dev), MINOR(dev)); | ^~
String "f2fs_page_array_entry-%u:%u" can up to 35. The first "%u" can up to 4 and the second "%u" can up to 7, so total size is "24 + 4 + 7 = 35". slab_name's size should be 35 rather than 32.(CVE-2023-52748)
In the Linux kernel, the following vulnerability has been resolved:
i2c: core: Run atomic i2c xfer when !preemptible
Since bae1d3a05a8b, i2c transfers are non-atomic if preemption is disabled. However, non-atomic i2c transfers require preemption (e.g. in wait_for_completion() while waiting for the DMA).
panic() calls preempt_disable_notrace() before calling emergency_restart(). Therefore, if an i2c device is used for the restart, the xfer should be atomic. This avoids warnings like:
[ 12.667612] WARNING: CPU: 1 PID: 1 at kernel/rcu/tree_plugin.h:318 rcu_note_context_switch+0x33c/0x6b0 [ 12.676926] Voluntary context switch within RCU read-side critical section! ... [ 12.742376] schedule_timeout from wait_for_completion_timeout+0x90/0x114 [ 12.749179] wait_for_completion_timeout from tegra_i2c_wait_completion+0x40/0x70 ... [ 12.994527] atomic_notifier_call_chain from machine_restart+0x34/0x58 [ 13.001050] machine_restart from panic+0x2a8/0x32c
Use !preemptible() instead, which is basically the same check as pre-v5.2.(CVE-2023-52791)
In the Linux kernel, the following vulnerability has been resolved:
drm/panel: fix a possible null pointer dereference
In versatile_panel_get_modes(), the return value of drm_mode_duplicate() is assigned to mode, which will lead to a NULL pointer dereference on failure of drm_mode_duplicate(). Add a check to avoid npd.(CVE-2023-52821)
In the Linux kernel, the following vulnerability has been resolved:
media: vidtv: mux: Add check and kfree for kstrdup
Add check for the return value of kstrdup() and return the error if it fails in order to avoid NULL pointer dereference. Moreover, use kfree() in the later error handling in order to avoid memory leak.(CVE-2023-52841)
In the Linux kernel, the following vulnerability has been resolved:
clk: mediatek: clk-mt6779: Add check for mtk_alloc_clk_data
Add the check for the return value of mtk_alloc_clk_data() in order to avoid NULL pointer dereference.(CVE-2023-52873)
In the Linux kernel, the following vulnerability has been resolved:
clk: sunxi-ng: h6: Reparent CPUX during PLL CPUX rate change
While PLL CPUX clock rate change when CPU is running from it works in vast majority of cases, now and then it causes instability. This leads to system crashes and other undefined behaviour. After a lot of testing (30+ hours) while also doing a lot of frequency switches, we can't observe any instability issues anymore when doing reparenting to stable clock like 24 MHz oscillator.(CVE-2023-52882)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nft_set_pipapo: do not free live element
Pablo reports a crash with large batches of elements with a back-to-back add/remove pattern. Quoting Pablo:
add_elem("00000000") timeout 100 ms ... add_elem("0000000X") timeout 100 ms del_elem("0000000X") <---------------- delete one that was just added ... add_elem("00005000") timeout 100 ms
1) nft_pipapo_remove() removes element 0000000X Then, KASAN shows a splat.
Looking at the remove function there is a chance that we will drop a rule that maps to a non-deactivated element.
Removal happens in two steps, first we do a lookup for key k and return the to-be-removed element and mark it as inactive in the next generation. Then, in a second step, the element gets removed from the set/map.
The _remove function does not work correctly if we have more than one element that share the same key.
This can happen if we insert an element into a set when the set already holds an element with same key, but the element mapping to the existing key has timed out or is not active in the next generation.
In such case its possible that removal will unmap the wrong element. If this happens, we will leak the non-deactivated element, it becomes unreachable.
The element that got deactivated (and will be freed later) will remain reachable in the set data structure, this can result in a crash when such an element is retrieved during lookup (stale pointer).
Add a check that the fully matching key does in fact map to the element that we have marked as inactive in the deactivation step. If not, we need to continue searching.
Add a bug/warn trap at the end of the function as well, the remove function must not ever be called with an invisible/unreachable/non-existent element.
v2: avoid uneeded temporary variable (Stefano)(CVE-2024-26924)
In the Linux kernel, the following vulnerability has been resolved:
scsi: core: Fix unremoved procfs host directory regression
Commit fc663711b944 ("scsi: core: Remove the /proc/scsi/${proc_name} directory earlier") fixed a bug related to modules loading/unloading, by adding a call to scsi_proc_hostdir_rm() on scsi_remove_host(). But that led to a potential duplicate call to the hostdir_rm() routine, since it's also called from scsi_host_dev_release(). That triggered a regression report, which was then fixed by commit be03df3d4bfe ("scsi: core: Fix a procfs host directory removal regression"). The fix just dropped the hostdir_rm() call from dev_release().
But it happens that this proc directory is created on scsi_host_alloc(), and that function "pairs" with scsi_host_dev_release(), while scsi_remove_host() pairs with scsi_add_host(). In other words, it seems the reason for removing the proc directory on dev_release() was meant to cover cases in which a SCSI host structure was allocated, but the call to scsi_add_host() didn't happen. And that pattern happens to exist in some error paths, for example.
Syzkaller causes that by using USB raw gadget device, error'ing on usb-storage driver, at usb_stor_probe2(). By checking that path, we can see that the BadDevice label leads to a scsi_host_put() after a SCSI host allocation, but there's no call to scsi_add_host() in such path. That leads to messages like this in dmesg (and a leak of the SCSI host proc structure):
usb-storage 4-1:87.51: USB Mass Storage device detected proc_dir_entry 'scsi/usb-storage' already registered WARNING: CPU: 1 PID: 3519 at fs/proc/generic.c:377 proc_register+0x347/0x4e0 fs/proc/generic.c:376
The proper fix seems to still call scsi_proc_hostdir_rm() on dev_release(), but guard that with the state check for SHOST_CREATED; there is even a comment in scsi_host_dev_release() detailing that: such conditional is meant for cases where the SCSI host was allocated but there was no calls to {add,remove}_host(), like the usb-storage case.
This is what we propose here and with that, the error path of usb-storage does not trigger the warning anymore.(CVE-2024-26935)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: validate request buffer size in smb2_allocate_rsp_buf()
The response buffer should be allocated in smb2_allocate_rsp_buf before validating request. But the fields in payload as well as smb2 header is used in smb2_allocate_rsp_buf(). This patch add simple buffer size validation to avoid potencial out-of-bounds in request buffer.(CVE-2024-26936)
In the Linux kernel, the following vulnerability has been resolved:
ARM: 9359/1: flush: check if the folio is reserved for no-mapping addresses
Since commit a4d5613c4dc6 ("arm: extend pfn_valid to take into account freed memory map alignment") changes the semantics of pfn_valid() to check presence of the memory map for a PFN. A valid page for an address which is reserved but not mapped by the kernel1, the system crashed during some uio test with the following memory layout:
node 0: [mem 0x00000000c0a00000-0x00000000cc8fffff] node 0: [mem 0x00000000d0000000-0x00000000da1fffff] the uio layout is：0xc0900000, 0x100000
the crash backtrace like:
Unable to handle kernel paging request at virtual address bff00000 [...] CPU: 1 PID: 465 Comm: startapp.bin Tainted: G O 5.10.0 #1 Hardware name: Generic DT based system PC is at b15_flush_kern_dcache_area+0x24/0x3c LR is at __sync_icache_dcache+0x6c/0x98 [...] (b15_flush_kern_dcache_area) from (__sync_icache_dcache+0x6c/0x98) (__sync_icache_dcache) from (set_pte_at+0x28/0x54) (set_pte_at) from (remap_pfn_range+0x1a0/0x274) (remap_pfn_range) from (uio_mmap+0x184/0x1b8 [uio]) (uio_mmap [uio]) from (__mmap_region+0x264/0x5f4) (__mmap_region) from (__do_mmap_mm+0x3ec/0x440) (__do_mmap_mm) from (do_mmap+0x50/0x58) (do_mmap) from (vm_mmap_pgoff+0xfc/0x188) (vm_mmap_pgoff) from (ksys_mmap_pgoff+0xac/0xc4) (ksys_mmap_pgoff) from (ret_fast_syscall+0x0/0x5c) Code: e0801001 e2423001 e1c00003 f57ff04f (ee070f3e) ---[ end trace 09cf0734c3805d52 ]--- Kernel panic - not syncing: Fatal exception
So check if PG_reserved was set to solve this issue.
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:
mm: swap: fix race between free_swap_and_cache() and swapoff()
There was previously a theoretical window where swapoff() could run and teardown a swap_info_struct while a call to free_swap_and_cache() was running in another thread. This could cause, amongst other bad possibilities, swap_page_trans_huge_swapped() (called by free_swap_and_cache()) to access the freed memory for swap_map.
This is a theoretical problem and I haven't been able to provoke it from a test case. But there has been agreement based on code review that this is possible (see link below).
Fix it by using get_swap_device()/put_swap_device(), which will stall swapoff(). There was an extra check in _swap_info_get() to confirm that the swap entry was not free. This isn't present in get_swap_device() because it doesn't make sense in general due to the race between getting the reference and swapoff. So I've added an equivalent check directly in free_swap_and_cache().
Details of how to provoke one possible issue (thanks to David Hildenbrand for deriving this):
--8<-----
__swap_entry_free() might be the last user and result in "count == SWAP_HAS_CACHE".
swapoff->try_to_unuse() will stop as soon as soon as si->inuse_pages==0.
So the question is: could someone reclaim the folio and turn si->inuse_pages==0, before we completed swap_page_trans_huge_swapped().
Imagine the following: 2 MiB folio in the swapcache. Only 2 subpages are still references by swap entries.
Process 1 still references subpage 0 via swap entry. Process 2 still references subpage 1 via swap entry.
Process 1 quits. Calls free_swap_and_cache(). -> count == SWAP_HAS_CACHE [then, preempted in the hypervisor etc.]
Process 2 quits. Calls free_swap_and_cache(). -> count == SWAP_HAS_CACHE
Process 2 goes ahead, passes swap_page_trans_huge_swapped(), and calls __try_to_reclaim_swap().
__try_to_reclaim_swap()->folio_free_swap()->delete_from_swap_cache()-> put_swap_folio()->free_swap_slot()->swapcache_free_entries()-> swap_entry_free()->swap_range_free()-> ... WRITE_ONCE(si->inuse_pages, si->inuse_pages - nr_entries);
What stops swapoff to succeed after process 2 reclaimed the swap cache but before process1 finished its call to swap_page_trans_huge_swapped()?
--8<-----(CVE-2024-26960)
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Prevent deadlock while disabling aRFS
When disabling aRFS under the priv->state_lock, any scheduled
aRFS works are canceled using the cancel_work_sync function,
which waits for the work to end if it has already started.
However, while waiting for the work handler, the handler will
try to acquire the state_lock which is already acquired.
The worker acquires the lock to delete the rules if the state is down, which is not the worker's responsibility since disabling aRFS deletes the rules.
Add an aRFS state variable, which indicates whether the aRFS is enabled and prevent adding rules when the aRFS is disabled.
Kernel log:
====================================================== WARNING: possible circular locking dependency detected 6.7.0-rc4_net_next_mlx5_5483eb2 #1 Tainted: G I
ethtool/386089 is trying to acquire lock: ffff88810f21ce68 ((work_completion)(&rule->arfs_work)){+.+.}-{0:0}, at: __flush_work+0x74/0x4e0
but task is already holding lock: ffff8884a1808cc0 (&priv->state_lock){+.+.}-{3:3}, at: mlx5e_ethtool_set_channels+0x53/0x200 [mlx5_core]
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&priv->state_lock){+.+.}-{3:3}: __mutex_lock+0x80/0xc90 arfs_handle_work+0x4b/0x3b0 [mlx5_core] process_one_work+0x1dc/0x4a0 worker_thread+0x1bf/0x3c0 kthread+0xd7/0x100 ret_from_fork+0x2d/0x50 ret_from_fork_asm+0x11/0x20
-> #0 ((work_completion)(&rule->arfs_work)){+.+.}-{0:0}: __lock_acquire+0x17b4/0x2c80 lock_acquire+0xd0/0x2b0 __flush_work+0x7a/0x4e0 __cancel_work_timer+0x131/0x1c0 arfs_del_rules+0x143/0x1e0 [mlx5_core] mlx5e_arfs_disable+0x1b/0x30 [mlx5_core] mlx5e_ethtool_set_channels+0xcb/0x200 [mlx5_core] ethnl_set_channels+0x28f/0x3b0 ethnl_default_set_doit+0xec/0x240 genl_family_rcv_msg_doit+0xd0/0x120 genl_rcv_msg+0x188/0x2c0 netlink_rcv_skb+0x54/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x1a1/0x270 netlink_sendmsg+0x214/0x460 __sock_sendmsg+0x38/0x60 __sys_sendto+0x113/0x170 __x64_sys_sendto+0x20/0x30 do_syscall_64+0x40/0xe0 entry_SYSCALL_64_after_hwframe+0x46/0x4e
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&priv->state_lock); lock((work_completion)(&rule->arfs_work)); lock(&priv->state_lock); lock((work_completion)(&rule->arfs_work));
*** DEADLOCK ***
3 locks held by ethtool/386089: #0: ffffffff82ea7210 (cb_lock){++++}-{3:3}, at: genl_rcv+0x15/0x40 #1: ffffffff82e94c88 (rtnl_mutex){+.+.}-{3:3}, at: ethnl_default_set_doit+0xd3/0x240 #2: ffff8884a1808cc0 (&priv->state_lock){+.+.}-{3:3}, at: mlx5e_ethtool_set_channels+0x53/0x200 [mlx5_core]
stack backtrace: CPU: 15 PID: 386089 Comm: ethtool Tainted: G I 6.7.0-rc4_net_next_mlx5_5483eb2 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x60/0xa0 check_noncircular+0x144/0x160 __lock_acquire+0x17b4/0x2c80 lock_acquire+0xd0/0x2b0 ? __flush_work+0x74/0x4e0 ? save_trace+0x3e/0x360 ? __flush_work+0x74/0x4e0 __flush_work+0x7a/0x4e0 ? __flush_work+0x74/0x4e0 ? __lock_acquire+0xa78/0x2c80 ? lock_acquire+0xd0/0x2b0 ? mark_held_locks+0x49/0x70 __cancel_work_timer+0x131/0x1c0 ? mark_held_locks+0x49/0x70 arfs_del_rules+0x143/0x1e0 [mlx5_core] mlx5e_arfs_disable+0x1b/0x30 [mlx5_core] mlx5e_ethtool_set_channels+0xcb/0x200 [mlx5_core] ethnl_set_channels+0x28f/0x3b0 ethnl_default_set_doit+0xec/0x240 genl_family_rcv_msg_doit+0xd0/0x120 genl_rcv_msg+0x188/0x2c0 ? ethn ---truncated---(CVE-2024-27014)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nft_set_pipapo: walk over current view on netlink dump
The generation mask can be updated while netlink dump is in progress. The pipapo set backend walk iterator cannot rely on it to infer what view of the datastructure is to be used. Add notation to specify if user wants to read/update the set.
Based on patch from Florian Westphal.(CVE-2024-27017)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: Fix potential data-race in __nft_obj_type_get()
nft_unregister_obj() can concurrent with __nft_obj_type_get(), and there is not any protection when iterate over nf_tables_objects list in __nft_obj_type_get(). Therefore, there is potential data-race of nf_tables_objects list entry.
Use list_for_each_entry_rcu() to iterate over nf_tables_objects list in __nft_obj_type_get(), and use rcu_read_lock() in the caller nft_obj_type_get() to protect the entire type query process.(CVE-2024-27019)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix potential NULL pointer dereferences in 'dcn10_set_output_transfer_func()'
The 'stream' pointer is used in dcn10_set_output_transfer_func() before the check if 'stream' is NULL.
Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn10/dcn10_hwseq.c:1892 dcn10_set_output_transfer_func() warn: variable dereferenced before check 'stream' (see line 1875)(CVE-2024-27044)
In the Linux kernel, the following vulnerability has been resolved:
net: ll_temac: platform_get_resource replaced by wrong function
The function platform_get_resource was replaced with devm_platform_ioremap_resource_byname and is called using 0 as name.
This eventually ends up in platform_get_resource_byname in the call stack, where it causes a null pointer in strcmp.
if (type == resource_type(r) && !strcmp(r->name, name))
It should have been replaced with devm_platform_ioremap_resource.(CVE-2024-35796)
In the Linux kernel, the following vulnerability has been resolved:
soc: fsl: qbman: Use raw spinlock for cgr_lock
smp_call_function always runs its callback in hard IRQ context, even on PREEMPT_RT, where spinlocks can sleep. So we need to use a raw spinlock for cgr_lock to ensure we aren't waiting on a sleeping task.
Although this bug has existed for a while, it was not apparent until commit ef2a8d5478b9 ("net: dpaa: Adjust queue depth on rate change") which invokes smp_call_function_single via qman_update_cgr_safe every time a link goes up or down.(CVE-2024-35819)
In the Linux kernel, the following vulnerability has been resolved:
ubifs: Set page uptodate in the correct place
Page cache reads are lockless, so setting the freshly allocated page uptodate before we've overwritten it with the data it's supposed to have in it will allow a simultaneous reader to see old data. Move the call to SetPageUptodate into ubifs_write_end(), which is after we copied the new data into the page.(CVE-2024-35821)
In the Linux kernel, the following vulnerability has been resolved:
wifi: libertas: fix some memleaks in lbs_allocate_cmd_buffer()
In the for statement of lbs_allocate_cmd_buffer(), if the allocation of cmdarray[i].cmdbuf fails, both cmdarray and cmdarray[i].cmdbuf needs to be freed. Otherwise, there will be memleaks in lbs_allocate_cmd_buffer().(CVE-2024-35828)
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix UAF in smb2_reconnect_server()
The UAF bug is due to smb2_reconnect_server() accessing a session that is already being teared down by another thread that is executing __cifs_put_smb_ses(). This can happen when (a) the client has connection to the server but no session or (b) another thread ends up setting @ses->ses_status again to something different than SES_EXITING.
To fix this, we need to make sure to unconditionally set @ses->ses_status to SES_EXITING and prevent any other threads from setting a new status while we're still tearing it down.
The following can be reproduced by adding some delay to right after the ipc is freed in __cifs_put_smb_ses() - which will give smb2_reconnect_server() worker a chance to run and then accessing @ses->ipc:
kinit ... mount.cifs //srv/share /mnt/1 -o sec=krb5,nohandlecache,echo_interval=10 [disconnect srv] ls /mnt/1 &>/dev/null sleep 30 kdestroy [reconnect srv] sleep 10 umount /mnt/1 ... CIFS: VFS: Verify user has a krb5 ticket and keyutils is installed CIFS: VFS: \srv Send error in SessSetup = -126 CIFS: VFS: Verify user has a krb5 ticket and keyutils is installed CIFS: VFS: \srv Send error in SessSetup = -126 general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b6b: 0000 [#1] PREEMPT SMP NOPTI CPU: 3 PID: 50 Comm: kworker/3:1 Not tainted 6.9.0-rc2 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-1.fc39 04/01/2014 Workqueue: cifsiod smb2_reconnect_server [cifs] RIP: 0010:__list_del_entry_valid_or_report+0x33/0xf0 Code: 4f 08 48 85 d2 74 42 48 85 c9 74 59 48 b8 00 01 00 00 00 00 ad de 48 39 c2 74 61 48 b8 22 01 00 00 00 00 74 69 <48> 8b 01 48 39 f8 75 7b 48 8b 72 08 48 39 c6 0f 85 88 00 00 00 b8 RSP: 0018:ffffc900001bfd70 EFLAGS: 00010a83 RAX: dead000000000122 RBX: ffff88810da53838 RCX: 6b6b6b6b6b6b6b6b RDX: 6b6b6b6b6b6b6b6b RSI: ffffffffc02f6878 RDI: ffff88810da53800 RBP: ffff88810da53800 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000001 R12: ffff88810c064000 R13: 0000000000000001 R14: ffff88810c064000 R15: ffff8881039cc000 FS: 0000000000000000(0000) GS:ffff888157c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fe3728b1000 CR3: 000000010caa4000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: <TASK> ? die_addr+0x36/0x90 ? exc_general_protection+0x1c1/0x3f0 ? asm_exc_general_protection+0x26/0x30 ? __list_del_entry_valid_or_report+0x33/0xf0 __cifs_put_smb_ses+0x1ae/0x500 [cifs] smb2_reconnect_server+0x4ed/0x710 [cifs] process_one_work+0x205/0x6b0 worker_thread+0x191/0x360 ? __pfx_worker_thread+0x10/0x10 kthread+0xe2/0x110 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK>(CVE-2024-35870)
In the Linux kernel, the following vulnerability has been resolved:
ax25: fix use-after-free bugs caused by ax25_ds_del_timer
When the ax25 device is detaching, the ax25_dev_device_down() calls ax25_ds_del_timer() to cleanup the slave_timer. When the timer handler is running, the ax25_ds_del_timer() that calls del_timer() in it will return directly. As a result, the use-after-free bugs could happen, one of the scenarios is shown below:
(Thread 1) | (Thread 2)
| ax25_ds_timeout()
ax25_dev_device_down() | ax25_ds_del_timer() | del_timer() | ax25_dev_put() //FREE | | ax25_dev-> //USE
In order to mitigate bugs, when the device is detaching, use timer_shutdown_sync() to stop the timer.(CVE-2024-35887)
In the Linux kernel, the following vulnerability has been resolved:
tcp: properly terminate timers for kernel sockets
We had various syzbot reports about tcp timers firing after the corresponding netns has been dismantled.
Fortunately Josef Bacik could trigger the issue more often, and could test a patch I wrote two years ago.
When TCP sockets are closed, we call inet_csk_clear_xmit_timers() to 'stop' the timers.
inet_csk_clear_xmit_timers() can be called from any context, including when socket lock is held. This is the reason it uses sk_stop_timer(), aka del_timer(). This means that ongoing timers might finish much later.
For user sockets, this is fine because each running timer holds a reference on the socket, and the user socket holds a reference on the netns.
For kernel sockets, we risk that the netns is freed before timer can complete, because kernel sockets do not hold reference on the netns.
This patch adds inet_csk_clear_xmit_timers_sync() function that using sk_stop_timer_sync() to make sure all timers are terminated before the kernel socket is released. Modules using kernel sockets close them in their netns exit() handler.
Also add sock_not_owned_by_me() helper to get LOCKDEP support : inet_csk_clear_xmit_timers_sync() must not be called while socket lock is held.
It is very possible we can revert in the future commit 3a58f13a881e ("net: rds: acquire refcount on TCP sockets") which attempted to solve the issue in rds only. (net/smc/af_smc.c and net/mptcp/subflow.c have similar code)
We probably can remove the check_net() tests from tcp_out_of_resources() and __tcp_close() in the future.(CVE-2024-35910)
In the Linux kernel, the following vulnerability has been resolved:
nfc: nci: Fix uninit-value in nci_dev_up and nci_ntf_packet
syzbot reported the following uninit-value access issue 1[2]:
nci_rx_work() parses and processes received packet. When the payload length is zero, each message type handler reads uninitialized payload and KMSAN detects this issue. The receipt of a packet with a zero-size payload is considered unexpected, and therefore, such packets should be silently discarded.
This patch resolved this issue by checking payload size before calling each message type handler codes.(CVE-2024-35915)
In the Linux kernel, the following vulnerability has been resolved:
drm/vc4: don't check if plane->state->fb == state->fb
Currently, when using non-blocking commits, we can see the following kernel warning:
[ 110.908514] ------------[ cut here ]------------ [ 110.908529] refcount_t: underflow; use-after-free. [ 110.908620] WARNING: CPU: 0 PID: 1866 at lib/refcount.c:87 refcount_dec_not_one+0xb8/0xc0 [ 110.908664] Modules linked in: rfcomm snd_seq_dummy snd_hrtimer snd_seq snd_seq_device cmac algif_hash aes_arm64 aes_generic algif_skcipher af_alg bnep hid_logitech_hidpp vc4 brcmfmac hci_uart btbcm brcmutil bluetooth snd_soc_hdmi_codec cfg80211 cec drm_display_helper drm_dma_helper drm_kms_helper snd_soc_core snd_compress snd_pcm_dmaengine fb_sys_fops sysimgblt syscopyarea sysfillrect raspberrypi_hwmon ecdh_generic ecc rfkill libaes i2c_bcm2835 binfmt_misc joydev snd_bcm2835(C) bcm2835_codec(C) bcm2835_isp(C) v4l2_mem2mem videobuf2_dma_contig snd_pcm bcm2835_v4l2(C) raspberrypi_gpiomem bcm2835_mmal_vchiq(C) videobuf2_v4l2 snd_timer videobuf2_vmalloc videobuf2_memops videobuf2_common snd videodev vc_sm_cma(C) mc hid_logitech_dj uio_pdrv_genirq uio i2c_dev drm fuse dm_mod drm_panel_orientation_quirks backlight ip_tables x_tables ipv6 [ 110.909086] CPU: 0 PID: 1866 Comm: kodi.bin Tainted: G C 6.1.66-v8+ #32 [ 110.909104] Hardware name: Raspberry Pi 3 Model B Rev 1.2 (DT) [ 110.909114] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 110.909132] pc : refcount_dec_not_one+0xb8/0xc0 [ 110.909152] lr : refcount_dec_not_one+0xb4/0xc0 [ 110.909170] sp : ffffffc00913b9c0 [ 110.909177] x29: ffffffc00913b9c0 x28: 000000556969bbb0 x27: 000000556990df60 [ 110.909205] x26: 0000000000000002 x25: 0000000000000004 x24: ffffff8004448480 [ 110.909230] x23: ffffff800570b500 x22: ffffff802e03a7bc x21: ffffffecfca68c78 [ 110.909257] x20: ffffff8002b42000 x19: ffffff802e03a600 x18: 0000000000000000 [ 110.909283] x17: 0000000000000011 x16: ffffffffffffffff x15: 0000000000000004 [ 110.909308] x14: 0000000000000fff x13: ffffffed577e47e0 x12: 0000000000000003 [ 110.909333] x11: 0000000000000000 x10: 0000000000000027 x9 : c912d0d083728c00 [ 110.909359] x8 : c912d0d083728c00 x7 : 65646e75203a745f x6 : 746e756f63666572 [ 110.909384] x5 : ffffffed579f62ee x4 : ffffffed579eb01e x3 : 0000000000000000 [ 110.909409] x2 : 0000000000000000 x1 : ffffffc00913b750 x0 : 0000000000000001 [ 110.909434] Call trace: [ 110.909441] refcount_dec_not_one+0xb8/0xc0 [ 110.909461] vc4_bo_dec_usecnt+0x4c/0x1b0 [vc4] [ 110.909903] vc4_cleanup_fb+0x44/0x50 [vc4] [ 110.910315] drm_atomic_helper_cleanup_planes+0x88/0xa4 [drm_kms_helper] [ 110.910669] vc4_atomic_commit_tail+0x390/0x9dc [vc4] [ 110.911079] commit_tail+0xb0/0x164 [drm_kms_helper] [ 110.911397] drm_atomic_helper_commit+0x1d0/0x1f0 [drm_kms_helper] [ 110.911716] drm_atomic_commit+0xb0/0xdc [drm] [ 110.912569] drm_mode_atomic_ioctl+0x348/0x4b8 [drm] [ 110.913330] drm_ioctl_kernel+0xec/0x15c [drm] [ 110.914091] drm_ioctl+0x24c/0x3b0 [drm] [ 110.914850] __arm64_sys_ioctl+0x9c/0xd4 [ 110.914873] invoke_syscall+0x4c/0x114 [ 110.914897] el0_svc_common+0xd0/0x118 [ 110.914917] do_el0_svc+0x38/0xd0 [ 110.914936] el0_svc+0x30/0x8c [ 110.914958] el0t_64_sync_handler+0x84/0xf0 [ 110.914979] el0t_64_sync+0x18c/0x190 [ 110.914996] ---[ end trace 0000000000000000 ]---
This happens because, although prepare_fb and cleanup_fb are
perfectly balanced, we cannot guarantee consistency in the check
plane->state->fb == state->fb. This means that sometimes we can increase
the refcount in prepare_fb and don't decrease it in cleanup_fb. The
opposite can also be true.
In fact, the struct drm_plane .state shouldn't be accessed directly
but instead, the drm_atomic_get_new_plane_state() helper function should
be used. So, we could stick to this check, but using
drm_atomic_get_new_plane_state(). But actually, this check is not re
---truncated---(CVE-2024-35932)
In the Linux kernel, the following vulnerability has been resolved:
btrfs: send: handle path ref underflow in header iterate_inode_ref()
Change BUG_ON to proper error handling if building the path buffer fails. The pointers are not printed so we don't accidentally leak kernel addresses.(CVE-2024-35935)
In the Linux kernel, the following vulnerability has been resolved:
wifi: cfg80211: check A-MSDU format more carefully
If it looks like there's another subframe in the A-MSDU but the header isn't fully there, we can end up reading data out of bounds, only to discard later. Make this a bit more careful and check if the subframe header can even be present.(CVE-2024-35937)
In the Linux kernel, the following vulnerability has been resolved:
drm/panfrost: Fix the error path in panfrost_mmu_map_fault_addr()
Subject: [PATCH] drm/panfrost: Fix the error path in panfrost_mmu_map_fault_addr()
If some the pages or sgt allocation failed, we shouldn't release the pages ref we got earlier, otherwise we will end up with unbalanced get/put_pages() calls. We should instead leave everything in place and let the BO release function deal with extra cleanup when the object is destroyed, or let the fault handler try again next time it's called.(CVE-2024-35951)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Fix not validating setsockopt user input
Check user input length before copying data.(CVE-2024-35965)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: RFCOMM: Fix not validating setsockopt user input
syzbot reported rfcomm_sock_setsockopt_old() is copying data without checking user input length.
BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline] BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline] BUG: KASAN: slab-out-of-bounds in rfcomm_sock_setsockopt_old net/bluetooth/rfcomm/sock.c:632 [inline] BUG: KASAN: slab-out-of-bounds in rfcomm_sock_setsockopt+0x893/0xa70 net/bluetooth/rfcomm/sock.c:673 Read of size 4 at addr ffff8880209a8bc3 by task syz-executor632/5064(CVE-2024-35966)
In the Linux kernel, the following vulnerability has been resolved:
tty: n_gsm: fix possible out-of-bounds in gsm0_receive()
Assuming the following: - side A configures the n_gsm in basic option mode - side B sends the header of a basic option mode frame with data length 1 - side A switches to advanced option mode - side B sends 2 data bytes which exceeds gsm->len Reason: gsm->len is not used in advanced option mode. - side A switches to basic option mode - side B keeps sending until gsm0_receive() writes past gsm->buf Reason: Neither gsm->state nor gsm->len have been reset after reconfiguration.
Fix this by changing gsm->count to gsm->len comparison from equal to less than. Also add upper limit checks against the constant MAX_MRU in gsm0_receive() and gsm1_receive() to harden against memory corruption of gsm->len and gsm->mru.
All other checks remain as we still need to limit the data according to the user configuration and actual payload size.(CVE-2024-36016)
In the Linux kernel, the following vulnerability has been resolved:
tcp: defer shutdown(SEND_SHUTDOWN) for TCP_SYN_RECV sockets
TCP_SYN_RECV state is really special, it is only used by cross-syn connections, mostly used by fuzzers.
In the following crash 1, syzbot managed to trigger a divide by zero in tcp_rcv_space_adjust()
A socket makes the following state transitions, without ever calling tcp_init_transfer(), meaning tcp_init_buffer_space() is also not called.
TCP_CLOSE
connect() TCP_SYN_SENT TCP_SYN_RECV shutdown() -> tcp_shutdown(sk, SEND_SHUTDOWN) TCP_FIN_WAIT1
To fix this issue, change tcp_shutdown() to not perform a TCP_SYN_RECV -> TCP_FIN_WAIT1 transition, which makes no sense anyway.
When tcp_rcv_state_process() later changes socket state from TCP_SYN_RECV to TCP_ESTABLISH, then look at sk->sk_shutdown to finally enter TCP_FIN_WAIT1 state, and send a FIN packet from a sane socket state.
This means tcp_send_fin() can now be called from BH context, and must use GFP_ATOMIC allocations.
1 divide error: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 1 PID: 5084 Comm: syz-executor358 Not tainted 6.9.0-rc6-syzkaller-00022-g98369dccd2f8 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 RIP: 0010:tcp_rcv_space_adjust+0x2df/0x890 net/ipv4/tcp_input.c:767 Code: e3 04 4c 01 eb 48 8b 44 24 38 0f b6 04 10 84 c0 49 89 d5 0f 85 a5 03 00 00 41 8b 8e c8 09 00 00 89 e8 29 c8 48 0f af c3 31 d2 <48> f7 f1 48 8d 1c 43 49 8d 96 76 08 00 00 48 89 d0 48 c1 e8 03 48 RSP: 0018:ffffc900031ef3f0 EFLAGS: 00010246 RAX: 0c677a10441f8f42 RBX: 000000004fb95e7e RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000027d4b11f R08: ffffffff89e535a4 R09: 1ffffffff25e6ab7 R10: dffffc0000000000 R11: ffffffff8135e920 R12: ffff88802a9f8d30 R13: dffffc0000000000 R14: ffff88802a9f8d00 R15: 1ffff1100553f2da FS: 00005555775c0380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f1155bf2304 CR3: 000000002b9f2000 CR4: 0000000000350ef0 Call Trace: <TASK> tcp_recvmsg_locked+0x106d/0x25a0 net/ipv4/tcp.c:2513 tcp_recvmsg+0x25d/0x920 net/ipv4/tcp.c:2578 inet6_recvmsg+0x16a/0x730 net/ipv6/af_inet6.c:680 sock_recvmsg_nosec net/socket.c:1046 [inline] sock_recvmsg+0x109/0x280 net/socket.c:1068 _sysrecvmsg+0x1db/0x470 net/socket.c:2803 _sys_recvmsg net/socket.c:2845 [inline] do_recvmmsg+0x474/0xae0 net/socket.c:2939 __sys_recvmmsg net/socket.c:3018 [inline] __do_sys_recvmmsg net/socket.c:3041 [inline] __se_sys_recvmmsg net/socket.c:3034 [inline] __x64_sys_recvmmsg+0x199/0x250 net/socket.c:3034 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7faeb6363db9 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 c1 17 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffcc1997168 EFLAGS: 00000246 ORIG_RAX: 000000000000012b RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007faeb6363db9 RDX: 0000000000000001 RSI: 0000000020000bc0 RDI: 0000000000000005 RBP: 0000000000000000 R08: 0000000000000000 R09: 000000000000001c R10: 0000000000000122 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000001(CVE-2024-36905)
In the Linux kernel, the following vulnerability has been resolved:
blk-iocost: avoid out of bounds shift
UBSAN catches undefined behavior in blk-iocost, where sometimes iocg->delay is shifted right by a number that is too large, resulting in undefined behavior on some architectures.
[ 186.556576] ------------[ cut here ]------------ UBSAN: shift-out-of-bounds in block/blk-iocost.c:1366:23 shift exponent 64 is too large for 64-bit type 'u64' (aka 'unsigned long long') CPU: 16 PID: 0 Comm: swapper/16 Tainted: G S E N 6.9.0-0_fbk700_debug_rc2_kbuilder_0_gc85af715cac0 #1 Hardware name: Quanta Twin Lakes MP/Twin Lakes Passive MP, BIOS F09_3A23 12/08/2020 Call Trace: <IRQ> dump_stack_lvl+0x8f/0xe0 __ubsan_handle_shift_out_of_bounds+0x22c/0x280 iocg_kick_delay+0x30b/0x310 ioc_timer_fn+0x2fb/0x1f80 __run_timer_base+0x1b6/0x250 ...
Avoid that undefined behavior by simply taking the "delay = 0" branch if the shift is too large.
I am not sure what the symptoms of an undefined value delay will be, but I suspect it could be more than a little annoying to debug.(CVE-2024-36916)
In the Linux kernel, the following vulnerability has been resolved:
scsi: bnx2fc: Remove spin_lock_bh while releasing resources after upload
The session resources are used by FW and driver when session is offloaded, once session is uploaded these resources are not used. The lock is not required as these fields won't be used any longer. The offload and upload calls are sequential, hence lock is not required.
This will suppress following BUG_ON():
[ 449.843143] ------------[ cut here ]------------ [ 449.848302] kernel BUG at mm/vmalloc.c:2727! [ 449.853072] invalid opcode: 0000 [#1] PREEMPT SMP PTI [ 449.858712] CPU: 5 PID: 1996 Comm: kworker/u24:2 Not tainted 5.14.0-118.el9.x86_64 #1 Rebooting. [ 449.867454] Hardware name: Dell Inc. PowerEdge R730/0WCJNT, BIOS 2.3.4 11/08/2016 [ 449.876966] Workqueue: fc_rport_eq fc_rport_work [libfc] [ 449.882910] RIP: 0010:vunmap+0x2e/0x30 [ 449.887098] Code: 00 65 8b 05 14 a2 f0 4a a9 00 ff ff 00 75 1b 55 48 89 fd e8 34 36 79 00 48 85 ed 74 0b 48 89 ef 31 f6 5d e9 14 fc ff ff 5d c3 <0f> 0b 0f 1f 44 00 00 41 57 41 56 49 89 ce 41 55 49 89 fd 41 54 41 [ 449.908054] RSP: 0018:ffffb83d878b3d68 EFLAGS: 00010206 [ 449.913887] RAX: 0000000080000201 RBX: ffff8f4355133550 RCX: 000000000d400005 [ 449.921843] RDX: 0000000000000001 RSI: 0000000000001000 RDI: ffffb83da53f5000 [ 449.929808] RBP: ffff8f4ac6675800 R08: ffffb83d878b3d30 R09: 00000000000efbdf [ 449.937774] R10: 0000000000000003 R11: ffff8f434573e000 R12: 0000000000001000 [ 449.945736] R13: 0000000000001000 R14: ffffb83da53f5000 R15: ffff8f43d4ea3ae0 [ 449.953701] FS: 0000000000000000(0000) GS:ffff8f529fc80000(0000) knlGS:0000000000000000 [ 449.962732] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 449.969138] CR2: 00007f8cf993e150 CR3: 0000000efbe10003 CR4: 00000000003706e0 [ 449.977102] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 449.985065] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 449.993028] Call Trace: [ 449.995756] __iommu_dma_free+0x96/0x100 [ 450.000139] bnx2fc_free_session_resc+0x67/0x240 [bnx2fc] [ 450.006171] bnx2fc_upload_session+0xce/0x100 [bnx2fc] [ 450.011910] bnx2fc_rport_event_handler+0x9f/0x240 [bnx2fc] [ 450.018136] fc_rport_work+0x103/0x5b0 [libfc] [ 450.023103] process_one_work+0x1e8/0x3c0 [ 450.027581] worker_thread+0x50/0x3b0 [ 450.031669] ? rescuer_thread+0x370/0x370 [ 450.036143] kthread+0x149/0x170 [ 450.039744] ? set_kthread_struct+0x40/0x40 [ 450.044411] ret_from_fork+0x22/0x30 [ 450.048404] Modules linked in: vfat msdos fat xfs nfs_layout_nfsv41_files rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver dm_service_time qedf qed crc8 bnx2fc libfcoe libfc scsi_transport_fc intel_rapl_msr intel_rapl_common x86_pkg_temp_thermal intel_powerclamp dcdbas rapl intel_cstate intel_uncore mei_me pcspkr mei ipmi_ssif lpc_ich ipmi_si fuse zram ext4 mbcache jbd2 loop nfsv3 nfs_acl nfs lockd grace fscache netfs irdma ice sd_mod t10_pi sg ib_uverbs ib_core 8021q garp mrp stp llc mgag200 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt mxm_wmi fb_sys_fops cec crct10dif_pclmul ahci crc32_pclmul bnx2x drm ghash_clmulni_intel libahci rfkill i40e libata megaraid_sas mdio wmi sunrpc lrw dm_crypt dm_round_robin dm_multipath dm_snapshot dm_bufio dm_mirror dm_region_hash dm_log dm_zero dm_mod linear raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx raid6_pq libcrc32c crc32c_intel raid1 raid0 iscsi_ibft squashfs be2iscsi bnx2i cnic uio cxgb4i cxgb4 tls [ 450.048497] libcxgbi libcxgb qla4xxx iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi edd ipmi_devintf ipmi_msghandler [ 450.159753] ---[ end trace 712de2c57c64abc8 ]---(CVE-2024-36919)
In the Linux kernel, the following vulnerability has been resolved:
scsi: lpfc: Move NPIV's transport unregistration to after resource clean up
There are cases after NPIV deletion where the fabric switch still believes the NPIV is logged into the fabric. This occurs when a vport is unregistered before the Remove All DA_ID CT and LOGO ELS are sent to the fabric.
Currently fc_remove_host(), which calls dev_loss_tmo for all D_IDs including the fabric D_ID, removes the last ndlp reference and frees the ndlp rport object. This sometimes causes the race condition where the final DA_ID and LOGO are skipped from being sent to the fabric switch.
Fix by moving the fc_remove_host() and scsi_remove_host() calls after DA_ID and LOGO are sent.(CVE-2024-36952)
In the Linux kernel, the following vulnerability has been resolved:
drm/vmwgfx: Fix invalid reads in fence signaled events
Correctly set the length of the drm_event to the size of the structure that's actually used.
The length of the drm_event was set to the parent structure instead of to the drm_vmw_event_fence which is supposed to be read. drm_read uses the length parameter to copy the event to the user space thus resuling in oob reads.(CVE-2024-36960)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Fix div-by-zero in l2cap_le_flowctl_init()
l2cap_le_flowctl_init() can cause both div-by-zero and an integer overflow since hdev->le_mtu may not fall in the valid range.
Move MTU from hci_dev to hci_conn to validate MTU and stop the connection process earlier if MTU is invalid. Also, add a missing validation in read_buffer_size() and make it return an error value if the validation fails. Now hci_conn_add() returns ERR_PTR() as it can fail due to the both a kzalloc failure and invalid MTU value.
divide error: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 0 PID: 67 Comm: kworker/u5:0 Tainted: G W 6.9.0-rc5+ #20 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: hci0 hci_rx_work RIP: 0010:l2cap_le_flowctl_init+0x19e/0x3f0 net/bluetooth/l2cap_core.c:547 Code: e8 17 17 0c 00 66 41 89 9f 84 00 00 00 bf 01 00 00 00 41 b8 02 00 00 00 4c 89 fe 4c 89 e2 89 d9 e8 27 17 0c 00 44 89 f0 31 d2 <66> f7 f3 89 c3 ff c3 4d 8d b7 88 00 00 00 4c 89 f0 48 c1 e8 03 42 RSP: 0018:ffff88810bc0f858 EFLAGS: 00010246 RAX: 00000000000002a0 RBX: 0000000000000000 RCX: dffffc0000000000 RDX: 0000000000000000 RSI: ffff88810bc0f7c0 RDI: ffffc90002dcb66f RBP: ffff88810bc0f880 R08: aa69db2dda70ff01 R09: 0000ffaaaaaaaaaa R10: 0084000000ffaaaa R11: 0000000000000000 R12: ffff88810d65a084 R13: dffffc0000000000 R14: 00000000000002a0 R15: ffff88810d65a000 FS: 0000000000000000(0000) GS:ffff88811ac00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000100 CR3: 0000000103268003 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace: <TASK> l2cap_le_connect_req net/bluetooth/l2cap_core.c:4902 [inline] l2cap_le_sig_cmd net/bluetooth/l2cap_core.c:5420 [inline] l2cap_le_sig_channel net/bluetooth/l2cap_core.c:5486 [inline] l2cap_recv_frame+0xe59d/0x11710 net/bluetooth/l2cap_core.c:6809 l2cap_recv_acldata+0x544/0x10a0 net/bluetooth/l2cap_core.c:7506 hci_acldata_packet net/bluetooth/hci_core.c:3939 [inline] hci_rx_work+0x5e5/0xb20 net/bluetooth/hci_core.c:4176 process_one_work kernel/workqueue.c:3254 [inline] process_scheduled_works+0x90f/0x1530 kernel/workqueue.c:3335 worker_thread+0x926/0xe70 kernel/workqueue.c:3416 kthread+0x2e3/0x380 kernel/kthread.c:388 ret_from_fork+0x5c/0x90 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 </TASK> Modules linked in: ---[ end trace 0000000000000000 ]---(CVE-2024-36968)
In the Linux kernel, the following vulnerability has been resolved:
net: fix __dst_negative_advice() race
__dst_negative_advice() does not enforce proper RCU rules when sk->dst_cache must be cleared, leading to possible UAF.
RCU rules are that we must first clear sk->sk_dst_cache, then call dst_release(old_dst).
Note that sk_dst_reset(sk) is implementing this protocol correctly, while __dst_negative_advice() uses the wrong order.
Given that ip6_negative_advice() has special logic against RTF_CACHE, this means each of the three ->negative_advice() existing methods must perform the sk_dst_reset() themselves.
Note the check against NULL dst is centralized in __dst_negative_advice(), there is no need to duplicate it in various callbacks.
Many thanks to Clement Lecigne for tracking this issue.
This old bug became visible after the blamed commit, using UDP sockets.(CVE-2024-36971)
| URL | Type | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"kernel-tools-5.10.0-209.0.0.117.oe2203sp3.aarch64.rpm",
"kernel-headers-5.10.0-209.0.0.117.oe2203sp3.aarch64.rpm",
"kernel-5.10.0-209.0.0.117.oe2203sp3.aarch64.rpm",
"kernel-devel-5.10.0-209.0.0.117.oe2203sp3.aarch64.rpm",
"kernel-tools-devel-5.10.0-209.0.0.117.oe2203sp3.aarch64.rpm",
"perf-debuginfo-5.10.0-209.0.0.117.oe2203sp3.aarch64.rpm",
"kernel-debugsource-5.10.0-209.0.0.117.oe2203sp3.aarch64.rpm",
"kernel-debuginfo-5.10.0-209.0.0.117.oe2203sp3.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-209.0.0.117.oe2203sp3.aarch64.rpm",
"perf-5.10.0-209.0.0.117.oe2203sp3.aarch64.rpm",
"kernel-source-5.10.0-209.0.0.117.oe2203sp3.aarch64.rpm",
"kernel-tools-debuginfo-5.10.0-209.0.0.117.oe2203sp3.aarch64.rpm",
"python3-perf-5.10.0-209.0.0.117.oe2203sp3.aarch64.rpm"
],
"src": [
"kernel-5.10.0-209.0.0.117.oe2203sp3.src.rpm"
],
"x86_64": [
"kernel-tools-devel-5.10.0-209.0.0.117.oe2203sp3.x86_64.rpm",
"kernel-source-5.10.0-209.0.0.117.oe2203sp3.x86_64.rpm",
"kernel-debugsource-5.10.0-209.0.0.117.oe2203sp3.x86_64.rpm",
"python3-perf-debuginfo-5.10.0-209.0.0.117.oe2203sp3.x86_64.rpm",
"kernel-headers-5.10.0-209.0.0.117.oe2203sp3.x86_64.rpm",
"python3-perf-5.10.0-209.0.0.117.oe2203sp3.x86_64.rpm",
"kernel-tools-5.10.0-209.0.0.117.oe2203sp3.x86_64.rpm",
"perf-debuginfo-5.10.0-209.0.0.117.oe2203sp3.x86_64.rpm",
"kernel-debuginfo-5.10.0-209.0.0.117.oe2203sp3.x86_64.rpm",
"kernel-devel-5.10.0-209.0.0.117.oe2203sp3.x86_64.rpm",
"kernel-5.10.0-209.0.0.117.oe2203sp3.x86_64.rpm",
"perf-5.10.0-209.0.0.117.oe2203sp3.x86_64.rpm",
"kernel-tools-debuginfo-5.10.0-209.0.0.117.oe2203sp3.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:22.03-LTS-SP3",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP3"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.10.0-209.0.0.117.oe2203sp3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nafs: Fix corruption in reads at fpos 2G-4G from an OpenAFS server\r\n\r\nAFS-3 has two data fetch RPC variants, FS.FetchData and FS.FetchData64, and\nLinux\u0026apos;s afs client switches between them when talking to a non-YFS server\nif the read size, the file position or the sum of the two have the upper 32\nbits set of the 64-bit value.\r\n\r\nThis is a problem, however, since the file position and length fields of\nFS.FetchData are *signed* 32-bit values.\r\n\r\nFix this by capturing the capability bits obtained from the fileserver when\nit\u0026apos;s sent an FS.GetCapabilities RPC, rather than just discarding them, and\nthen picking out the VICED_CAPABILITY_64BITFILES flag. This can then be\nused to decide whether to use FS.FetchData or FS.FetchData64 - and also\nFS.StoreData or FS.StoreData64 - rather than using upper_32_bits() to\nswitch on the parameter values.\r\n\r\nThis capabilities flag could also be used to limit the maximum size of the\nfile, but all servers must be checked for that.\r\n\r\nNote that the issue does not exist with FS.StoreData - that uses *unsigned*\n32-bit values. It\u0026apos;s also not a problem with Auristor servers as its\nYFS.FetchData64 op uses unsigned 64-bit values.\r\n\r\nThis can be tested by cloning a git repo through an OpenAFS client to an\nOpenAFS server and then doing \u0026quot;git status\u0026quot; on it from a Linux afs\nclient[1]. Provided the clone has a pack file that\u0026apos;s in the 2G-4G range,\nthe git status will show errors like:\r\n\r\n\terror: packfile .git/objects/pack/pack-5e813c51d12b6847bbc0fcd97c2bca66da50079c.pack does not match index\n\terror: packfile .git/objects/pack/pack-5e813c51d12b6847bbc0fcd97c2bca66da50079c.pack does not match index\r\n\r\nThis can be observed in the server\u0026apos;s FileLog with something like the\nfollowing appearing:\r\n\r\nSun Aug 29 19:31:39 2021 SRXAFS_FetchData, Fid = 2303380852.491776.3263114, Host 192.168.11.201:7001, Id 1001\nSun Aug 29 19:31:39 2021 CheckRights: len=0, for host=192.168.11.201:7001\nSun Aug 29 19:31:39 2021 FetchData_RXStyle: Pos 18446744071815340032, Len 3154\nSun Aug 29 19:31:39 2021 FetchData_RXStyle: file size 2400758866\n...\nSun Aug 29 19:31:40 2021 SRXAFS_FetchData returns 5\r\n\r\nNote the file position of 18446744071815340032. This is the requested file\nposition sign-extended.(CVE-2021-47366)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/smc: Fix possible access to freed memory in link clear\r\n\r\nAfter modifying the QP to the Error state, all RX WR would be completed\nwith WC in IB_WC_WR_FLUSH_ERR status. Current implementation does not\nwait for it is done, but destroy the QP and free the link group directly.\nSo there is a risk that accessing the freed memory in tasklet context.\r\n\r\nHere is a crash example:\r\n\r\n BUG: unable to handle page fault for address: ffffffff8f220860\n #PF: supervisor write access in kernel mode\n #PF: error_code(0x0002) - not-present page\n PGD f7300e067 P4D f7300e067 PUD f7300f063 PMD 8c4e45063 PTE 800ffff08c9df060\n Oops: 0002 [#1] SMP PTI\n CPU: 1 PID: 0 Comm: swapper/1 Kdump: loaded Tainted: G S OE 5.10.0-0607+ #23\n Hardware name: Inspur NF5280M4/YZMB-00689-101, BIOS 4.1.20 07/09/2018\n RIP: 0010:native_queued_spin_lock_slowpath+0x176/0x1b0\n Code: f3 90 48 8b 32 48 85 f6 74 f6 eb d5 c1 ee 12 83 e0 03 83 ee 01 48 c1 e0 05 48 63 f6 48 05 00 c8 02 00 48 03 04 f5 00 09 98 8e \u0026lt;48\u0026gt; 89 10 8b 42 08 85 c0 75 09 f3 90 8b 42 08 85 c0 74 f7 48 8b 32\n RSP: 0018:ffffb3b6c001ebd8 EFLAGS: 00010086\n RAX: ffffffff8f220860 RBX: 0000000000000246 RCX: 0000000000080000\n RDX: ffff91db1f86c800 RSI: 000000000000173c RDI: ffff91db62bace00\n RBP: ffff91db62bacc00 R08: 0000000000000000 R09: c00000010000028b\n R10: 0000000000055198 R11: ffffb3b6c001ea58 R12: ffff91db80e05010\n R13: 000000000000000a R14: 0000000000000006 R15: 0000000000000040\n FS: 0000000000000000(0000) GS:ffff91db1f840000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: ffffffff8f220860 CR3: 00000001f9580004 CR4: 00000000003706e0\n DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n Call Trace:\n \u0026lt;IRQ\u0026gt;\n _raw_spin_lock_irqsave+0x30/0x40\n mlx5_ib_poll_cq+0x4c/0xc50 [mlx5_ib]\n smc_wr_rx_tasklet_fn+0x56/0xa0 [smc]\n tasklet_action_common.isra.21+0x66/0x100\n __do_softirq+0xd5/0x29c\n asm_call_irq_on_stack+0x12/0x20\n \u0026lt;/IRQ\u0026gt;\n do_softirq_own_stack+0x37/0x40\n irq_exit_rcu+0x9d/0xa0\n sysvec_call_function_single+0x34/0x80\n asm_sysvec_call_function_single+0x12/0x20(CVE-2022-48673)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nRDMA/srp: Set scmnd-\u0026gt;result only when scmnd is not NULL\r\n\r\nThis change fixes the following kernel NULL pointer dereference\nwhich is reproduced by blktests srp/007 occasionally.\r\n\r\nBUG: kernel NULL pointer dereference, address: 0000000000000170\nPGD 0 P4D 0\nOops: 0002 [#1] PREEMPT SMP NOPTI\nCPU: 0 PID: 9 Comm: kworker/0:1H Kdump: loaded Not tainted 6.0.0-rc1+ #37\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.15.0-29-g6a62e0cb0dfe-prebuilt.qemu.org 04/01/2014\nWorkqueue: 0x0 (kblockd)\nRIP: 0010:srp_recv_done+0x176/0x500 [ib_srp]\nCode: 00 4d 85 ff 0f 84 52 02 00 00 48 c7 82 80 02 00 00 00 00 00 00 4c 89 df 4c 89 14 24 e8 53 d3 4a f6 4c 8b 14 24 41 0f b6 42 13 \u0026lt;41\u0026gt; 89 87 70 01 00 00 41 0f b6 52 12 f6 c2 02 74 44 41 8b 42 1c b9\nRSP: 0018:ffffaef7c0003e28 EFLAGS: 00000282\nRAX: 0000000000000000 RBX: ffff9bc9486dea60 RCX: 0000000000000000\nRDX: 0000000000000102 RSI: ffffffffb76bbd0e RDI: 00000000ffffffff\nRBP: ffff9bc980099a00 R08: 0000000000000001 R09: 0000000000000001\nR10: ffff9bca53ef0000 R11: ffff9bc980099a10 R12: ffff9bc956e14000\nR13: ffff9bc9836b9cb0 R14: ffff9bc9557b4480 R15: 0000000000000000\nFS: 0000000000000000(0000) GS:ffff9bc97ec00000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000170 CR3: 0000000007e04000 CR4: 00000000000006f0\nCall Trace:\n \u0026lt;IRQ\u0026gt;\n __ib_process_cq+0xb7/0x280 [ib_core]\n ib_poll_handler+0x2b/0x130 [ib_core]\n irq_poll_softirq+0x93/0x150\n __do_softirq+0xee/0x4b8\n irq_exit_rcu+0xf7/0x130\n sysvec_apic_timer_interrupt+0x8e/0xc0\n \u0026lt;/IRQ\u0026gt;(CVE-2022-48692)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nrpmsg: virtio: Free driver_override when rpmsg_remove()\r\n\r\nFree driver_override when rpmsg_remove(), otherwise\nthe following memory leak will occur:\r\n\r\nunreferenced object 0xffff0000d55d7080 (size 128):\n comm \u0026quot;kworker/u8:2\u0026quot;, pid 56, jiffies 4294893188 (age 214.272s)\n hex dump (first 32 bytes):\n 72 70 6d 73 67 5f 6e 73 00 00 00 00 00 00 00 00 rpmsg_ns........\n 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n backtrace:\n [\u0026lt;000000009c94c9c1\u0026gt;] __kmem_cache_alloc_node+0x1f8/0x320\n [\u0026lt;000000002300d89b\u0026gt;] __kmalloc_node_track_caller+0x44/0x70\n [\u0026lt;00000000228a60c3\u0026gt;] kstrndup+0x4c/0x90\n [\u0026lt;0000000077158695\u0026gt;] driver_set_override+0xd0/0x164\n [\u0026lt;000000003e9c4ea5\u0026gt;] rpmsg_register_device_override+0x98/0x170\n [\u0026lt;000000001c0c89a8\u0026gt;] rpmsg_ns_register_device+0x24/0x30\n [\u0026lt;000000008bbf8fa2\u0026gt;] rpmsg_probe+0x2e0/0x3ec\n [\u0026lt;00000000e65a68df\u0026gt;] virtio_dev_probe+0x1c0/0x280\n [\u0026lt;00000000443331cc\u0026gt;] really_probe+0xbc/0x2dc\n [\u0026lt;00000000391064b1\u0026gt;] __driver_probe_device+0x78/0xe0\n [\u0026lt;00000000a41c9a5b\u0026gt;] driver_probe_device+0xd8/0x160\n [\u0026lt;000000009c3bd5df\u0026gt;] __device_attach_driver+0xb8/0x140\n [\u0026lt;0000000043cd7614\u0026gt;] bus_for_each_drv+0x7c/0xd4\n [\u0026lt;000000003b929a36\u0026gt;] __device_attach+0x9c/0x19c\n [\u0026lt;00000000a94e0ba8\u0026gt;] device_initial_probe+0x14/0x20\n [\u0026lt;000000003c999637\u0026gt;] bus_probe_device+0xa0/0xac(CVE-2023-52670)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nf2fs: avoid format-overflow warning\r\n\r\nWith gcc and W=1 option, there\u0026apos;s a warning like this:\r\n\r\nfs/f2fs/compress.c: In function \u2018f2fs_init_page_array_cache\u2019:\nfs/f2fs/compress.c:1984:47: error: \u2018%u\u2019 directive writing between\n1 and 7 bytes into a region of size between 5 and 8\n[-Werror=format-overflow=]\n 1984 | sprintf(slab_name, \u0026quot;f2fs_page_array_entry-%u:%u\u0026quot;, MAJOR(dev),\n\t\tMINOR(dev));\n | ^~\r\n\r\nString \u0026quot;f2fs_page_array_entry-%u:%u\u0026quot; can up to 35. The first \u0026quot;%u\u0026quot; can up\nto 4 and the second \u0026quot;%u\u0026quot; can up to 7, so total size is \u0026quot;24 + 4 + 7 = 35\u0026quot;.\nslab_name\u0026apos;s size should be 35 rather than 32.(CVE-2023-52748)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ni2c: core: Run atomic i2c xfer when !preemptible\r\n\r\nSince bae1d3a05a8b, i2c transfers are non-atomic if preemption is\ndisabled. However, non-atomic i2c transfers require preemption (e.g. in\nwait_for_completion() while waiting for the DMA).\r\n\r\npanic() calls preempt_disable_notrace() before calling\nemergency_restart(). Therefore, if an i2c device is used for the\nrestart, the xfer should be atomic. This avoids warnings like:\r\n\r\n[ 12.667612] WARNING: CPU: 1 PID: 1 at kernel/rcu/tree_plugin.h:318 rcu_note_context_switch+0x33c/0x6b0\n[ 12.676926] Voluntary context switch within RCU read-side critical section!\n...\n[ 12.742376] schedule_timeout from wait_for_completion_timeout+0x90/0x114\n[ 12.749179] wait_for_completion_timeout from tegra_i2c_wait_completion+0x40/0x70\n...\n[ 12.994527] atomic_notifier_call_chain from machine_restart+0x34/0x58\n[ 13.001050] machine_restart from panic+0x2a8/0x32c\r\n\r\nUse !preemptible() instead, which is basically the same check as\npre-v5.2.(CVE-2023-52791)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/panel: fix a possible null pointer dereference\r\n\r\nIn versatile_panel_get_modes(), the return value of drm_mode_duplicate()\nis assigned to mode, which will lead to a NULL pointer dereference\non failure of drm_mode_duplicate(). Add a check to avoid npd.(CVE-2023-52821)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: vidtv: mux: Add check and kfree for kstrdup\r\n\r\nAdd check for the return value of kstrdup() and return the error\nif it fails in order to avoid NULL pointer dereference.\nMoreover, use kfree() in the later error handling in order to avoid\nmemory leak.(CVE-2023-52841)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nclk: mediatek: clk-mt6779: Add check for mtk_alloc_clk_data\r\n\r\nAdd the check for the return value of mtk_alloc_clk_data() in order to\navoid NULL pointer dereference.(CVE-2023-52873)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nclk: sunxi-ng: h6: Reparent CPUX during PLL CPUX rate change\r\n\r\nWhile PLL CPUX clock rate change when CPU is running from it works in\nvast majority of cases, now and then it causes instability. This leads\nto system crashes and other undefined behaviour. After a lot of testing\n(30+ hours) while also doing a lot of frequency switches, we can\u0026apos;t\nobserve any instability issues anymore when doing reparenting to stable\nclock like 24 MHz oscillator.(CVE-2023-52882)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nft_set_pipapo: do not free live element\r\n\r\nPablo reports a crash with large batches of elements with a\nback-to-back add/remove pattern. Quoting Pablo:\r\n\r\n add_elem(\u0026quot;00000000\u0026quot;) timeout 100 ms\n ...\n add_elem(\u0026quot;0000000X\u0026quot;) timeout 100 ms\n del_elem(\u0026quot;0000000X\u0026quot;) \u0026lt;---------------- delete one that was just added\n ...\n add_elem(\u0026quot;00005000\u0026quot;) timeout 100 ms\r\n\r\n 1) nft_pipapo_remove() removes element 0000000X\n Then, KASAN shows a splat.\r\n\r\nLooking at the remove function there is a chance that we will drop a\nrule that maps to a non-deactivated element.\r\n\r\nRemoval happens in two steps, first we do a lookup for key k and return the\nto-be-removed element and mark it as inactive in the next generation.\nThen, in a second step, the element gets removed from the set/map.\r\n\r\nThe _remove function does not work correctly if we have more than one\nelement that share the same key.\r\n\r\nThis can happen if we insert an element into a set when the set already\nholds an element with same key, but the element mapping to the existing\nkey has timed out or is not active in the next generation.\r\n\r\nIn such case its possible that removal will unmap the wrong element.\nIf this happens, we will leak the non-deactivated element, it becomes\nunreachable.\r\n\r\nThe element that got deactivated (and will be freed later) will\nremain reachable in the set data structure, this can result in\na crash when such an element is retrieved during lookup (stale\npointer).\r\n\r\nAdd a check that the fully matching key does in fact map to the element\nthat we have marked as inactive in the deactivation step.\nIf not, we need to continue searching.\r\n\r\nAdd a bug/warn trap at the end of the function as well, the remove\nfunction must not ever be called with an invisible/unreachable/non-existent\nelement.\r\n\r\nv2: avoid uneeded temporary variable (Stefano)(CVE-2024-26924)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: core: Fix unremoved procfs host directory regression\r\n\r\nCommit fc663711b944 (\u0026quot;scsi: core: Remove the /proc/scsi/${proc_name}\ndirectory earlier\u0026quot;) fixed a bug related to modules loading/unloading, by\nadding a call to scsi_proc_hostdir_rm() on scsi_remove_host(). But that led\nto a potential duplicate call to the hostdir_rm() routine, since it\u0026apos;s also\ncalled from scsi_host_dev_release(). That triggered a regression report,\nwhich was then fixed by commit be03df3d4bfe (\u0026quot;scsi: core: Fix a procfs host\ndirectory removal regression\u0026quot;). The fix just dropped the hostdir_rm() call\nfrom dev_release().\r\n\r\nBut it happens that this proc directory is created on scsi_host_alloc(),\nand that function \u0026quot;pairs\u0026quot; with scsi_host_dev_release(), while\nscsi_remove_host() pairs with scsi_add_host(). In other words, it seems the\nreason for removing the proc directory on dev_release() was meant to cover\ncases in which a SCSI host structure was allocated, but the call to\nscsi_add_host() didn\u0026apos;t happen. And that pattern happens to exist in some\nerror paths, for example.\r\n\r\nSyzkaller causes that by using USB raw gadget device, error\u0026apos;ing on\nusb-storage driver, at usb_stor_probe2(). By checking that path, we can see\nthat the BadDevice label leads to a scsi_host_put() after a SCSI host\nallocation, but there\u0026apos;s no call to scsi_add_host() in such path. That leads\nto messages like this in dmesg (and a leak of the SCSI host proc\nstructure):\r\n\r\nusb-storage 4-1:87.51: USB Mass Storage device detected\nproc_dir_entry \u0026apos;scsi/usb-storage\u0026apos; already registered\nWARNING: CPU: 1 PID: 3519 at fs/proc/generic.c:377 proc_register+0x347/0x4e0 fs/proc/generic.c:376\r\n\r\nThe proper fix seems to still call scsi_proc_hostdir_rm() on dev_release(),\nbut guard that with the state check for SHOST_CREATED; there is even a\ncomment in scsi_host_dev_release() detailing that: such conditional is\nmeant for cases where the SCSI host was allocated but there was no calls to\n{add,remove}_host(), like the usb-storage case.\r\n\r\nThis is what we propose here and with that, the error path of usb-storage\ndoes not trigger the warning anymore.(CVE-2024-26935)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nksmbd: validate request buffer size in smb2_allocate_rsp_buf()\r\n\r\nThe response buffer should be allocated in smb2_allocate_rsp_buf\nbefore validating request. But the fields in payload as well as smb2 header\nis used in smb2_allocate_rsp_buf(). This patch add simple buffer size\nvalidation to avoid potencial out-of-bounds in request buffer.(CVE-2024-26936)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nARM: 9359/1: flush: check if the folio is reserved for no-mapping addresses\r\n\r\nSince commit a4d5613c4dc6 (\u0026quot;arm: extend pfn_valid to take into account\nfreed memory map alignment\u0026quot;) changes the semantics of pfn_valid() to check\npresence of the memory map for a PFN. A valid page for an address which\nis reserved but not mapped by the kernel[1], the system crashed during\nsome uio test with the following memory layout:\r\n\r\n node 0: [mem 0x00000000c0a00000-0x00000000cc8fffff]\n node 0: [mem 0x00000000d0000000-0x00000000da1fffff]\n the uio layout is\uff1a0xc0900000, 0x100000\r\n\r\nthe crash backtrace like:\r\n\r\n Unable to handle kernel paging request at virtual address bff00000\n [...]\n CPU: 1 PID: 465 Comm: startapp.bin Tainted: G O 5.10.0 #1\n Hardware name: Generic DT based system\n PC is at b15_flush_kern_dcache_area+0x24/0x3c\n LR is at __sync_icache_dcache+0x6c/0x98\n [...]\n (b15_flush_kern_dcache_area) from (__sync_icache_dcache+0x6c/0x98)\n (__sync_icache_dcache) from (set_pte_at+0x28/0x54)\n (set_pte_at) from (remap_pfn_range+0x1a0/0x274)\n (remap_pfn_range) from (uio_mmap+0x184/0x1b8 [uio])\n (uio_mmap [uio]) from (__mmap_region+0x264/0x5f4)\n (__mmap_region) from (__do_mmap_mm+0x3ec/0x440)\n (__do_mmap_mm) from (do_mmap+0x50/0x58)\n (do_mmap) from (vm_mmap_pgoff+0xfc/0x188)\n (vm_mmap_pgoff) from (ksys_mmap_pgoff+0xac/0xc4)\n (ksys_mmap_pgoff) from (ret_fast_syscall+0x0/0x5c)\n Code: e0801001 e2423001 e1c00003 f57ff04f (ee070f3e)\n ---[ end trace 09cf0734c3805d52 ]---\n Kernel panic - not syncing: Fatal exception\r\n\r\nSo check if PG_reserved was set to solve this issue.\r\n\r\n[1]: https://lore.kernel.org/lkml/Zbtdue57RO0QScJM@linux.ibm.com/(CVE-2024-26947)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nksmbd: fix slab-out-of-bounds in smb_strndup_from_utf16()\r\n\r\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)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmm: swap: fix race between free_swap_and_cache() and swapoff()\r\n\r\nThere was previously a theoretical window where swapoff() could run and\nteardown a swap_info_struct while a call to free_swap_and_cache() was\nrunning in another thread. This could cause, amongst other bad\npossibilities, swap_page_trans_huge_swapped() (called by\nfree_swap_and_cache()) to access the freed memory for swap_map.\r\n\r\nThis is a theoretical problem and I haven\u0026apos;t been able to provoke it from a\ntest case. But there has been agreement based on code review that this is\npossible (see link below).\r\n\r\nFix it by using get_swap_device()/put_swap_device(), which will stall\nswapoff(). There was an extra check in _swap_info_get() to confirm that\nthe swap entry was not free. This isn\u0026apos;t present in get_swap_device()\nbecause it doesn\u0026apos;t make sense in general due to the race between getting\nthe reference and swapoff. So I\u0026apos;ve added an equivalent check directly in\nfree_swap_and_cache().\r\n\r\nDetails of how to provoke one possible issue (thanks to David Hildenbrand\nfor deriving this):\r\n\r\n--8\u0026lt;-----\r\n\r\n__swap_entry_free() might be the last user and result in\n\u0026quot;count == SWAP_HAS_CACHE\u0026quot;.\r\n\r\nswapoff-\u0026gt;try_to_unuse() will stop as soon as soon as si-\u0026gt;inuse_pages==0.\r\n\r\nSo the question is: could someone reclaim the folio and turn\nsi-\u0026gt;inuse_pages==0, before we completed swap_page_trans_huge_swapped().\r\n\r\nImagine the following: 2 MiB folio in the swapcache. Only 2 subpages are\nstill references by swap entries.\r\n\r\nProcess 1 still references subpage 0 via swap entry.\nProcess 2 still references subpage 1 via swap entry.\r\n\r\nProcess 1 quits. Calls free_swap_and_cache().\n-\u0026gt; count == SWAP_HAS_CACHE\n[then, preempted in the hypervisor etc.]\r\n\r\nProcess 2 quits. Calls free_swap_and_cache().\n-\u0026gt; count == SWAP_HAS_CACHE\r\n\r\nProcess 2 goes ahead, passes swap_page_trans_huge_swapped(), and calls\n__try_to_reclaim_swap().\r\n\r\n__try_to_reclaim_swap()-\u0026gt;folio_free_swap()-\u0026gt;delete_from_swap_cache()-\u0026gt;\nput_swap_folio()-\u0026gt;free_swap_slot()-\u0026gt;swapcache_free_entries()-\u0026gt;\nswap_entry_free()-\u0026gt;swap_range_free()-\u0026gt;\n...\nWRITE_ONCE(si-\u0026gt;inuse_pages, si-\u0026gt;inuse_pages - nr_entries);\r\n\r\nWhat stops swapoff to succeed after process 2 reclaimed the swap cache\nbut before process1 finished its call to swap_page_trans_huge_swapped()?\r\n\r\n--8\u0026lt;-----(CVE-2024-26960)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/mlx5e: Prevent deadlock while disabling aRFS\r\n\r\nWhen disabling aRFS under the `priv-\u0026gt;state_lock`, any scheduled\naRFS works are canceled using the `cancel_work_sync` function,\nwhich waits for the work to end if it has already started.\nHowever, while waiting for the work handler, the handler will\ntry to acquire the `state_lock` which is already acquired.\r\n\r\nThe worker acquires the lock to delete the rules if the state\nis down, which is not the worker\u0026apos;s responsibility since\ndisabling aRFS deletes the rules.\r\n\r\nAdd an aRFS state variable, which indicates whether the aRFS is\nenabled and prevent adding rules when the aRFS is disabled.\r\n\r\nKernel log:\r\n\r\n======================================================\nWARNING: possible circular locking dependency detected\n6.7.0-rc4_net_next_mlx5_5483eb2 #1 Tainted: G I\n------------------------------------------------------\nethtool/386089 is trying to acquire lock:\nffff88810f21ce68 ((work_completion)(\u0026amp;rule-\u0026gt;arfs_work)){+.+.}-{0:0}, at: __flush_work+0x74/0x4e0\r\n\r\nbut task is already holding lock:\nffff8884a1808cc0 (\u0026amp;priv-\u0026gt;state_lock){+.+.}-{3:3}, at: mlx5e_ethtool_set_channels+0x53/0x200 [mlx5_core]\r\n\r\nwhich lock already depends on the new lock.\r\n\r\nthe existing dependency chain (in reverse order) is:\r\n\r\n-\u0026gt; #1 (\u0026amp;priv-\u0026gt;state_lock){+.+.}-{3:3}:\n __mutex_lock+0x80/0xc90\n arfs_handle_work+0x4b/0x3b0 [mlx5_core]\n process_one_work+0x1dc/0x4a0\n worker_thread+0x1bf/0x3c0\n kthread+0xd7/0x100\n ret_from_fork+0x2d/0x50\n ret_from_fork_asm+0x11/0x20\r\n\r\n-\u0026gt; #0 ((work_completion)(\u0026amp;rule-\u0026gt;arfs_work)){+.+.}-{0:0}:\n __lock_acquire+0x17b4/0x2c80\n lock_acquire+0xd0/0x2b0\n __flush_work+0x7a/0x4e0\n __cancel_work_timer+0x131/0x1c0\n arfs_del_rules+0x143/0x1e0 [mlx5_core]\n mlx5e_arfs_disable+0x1b/0x30 [mlx5_core]\n mlx5e_ethtool_set_channels+0xcb/0x200 [mlx5_core]\n ethnl_set_channels+0x28f/0x3b0\n ethnl_default_set_doit+0xec/0x240\n genl_family_rcv_msg_doit+0xd0/0x120\n genl_rcv_msg+0x188/0x2c0\n netlink_rcv_skb+0x54/0x100\n genl_rcv+0x24/0x40\n netlink_unicast+0x1a1/0x270\n netlink_sendmsg+0x214/0x460\n __sock_sendmsg+0x38/0x60\n __sys_sendto+0x113/0x170\n __x64_sys_sendto+0x20/0x30\n do_syscall_64+0x40/0xe0\n entry_SYSCALL_64_after_hwframe+0x46/0x4e\r\n\r\nother info that might help us debug this:\r\n\r\n Possible unsafe locking scenario:\r\n\r\n CPU0 CPU1\n ---- ----\n lock(\u0026amp;priv-\u0026gt;state_lock);\n lock((work_completion)(\u0026amp;rule-\u0026gt;arfs_work));\n lock(\u0026amp;priv-\u0026gt;state_lock);\n lock((work_completion)(\u0026amp;rule-\u0026gt;arfs_work));\r\n\r\n *** DEADLOCK ***\r\n\r\n3 locks held by ethtool/386089:\n #0: ffffffff82ea7210 (cb_lock){++++}-{3:3}, at: genl_rcv+0x15/0x40\n #1: ffffffff82e94c88 (rtnl_mutex){+.+.}-{3:3}, at: ethnl_default_set_doit+0xd3/0x240\n #2: ffff8884a1808cc0 (\u0026amp;priv-\u0026gt;state_lock){+.+.}-{3:3}, at: mlx5e_ethtool_set_channels+0x53/0x200 [mlx5_core]\r\n\r\nstack backtrace:\nCPU: 15 PID: 386089 Comm: ethtool Tainted: G I 6.7.0-rc4_net_next_mlx5_5483eb2 #1\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x60/0xa0\n check_noncircular+0x144/0x160\n __lock_acquire+0x17b4/0x2c80\n lock_acquire+0xd0/0x2b0\n ? __flush_work+0x74/0x4e0\n ? save_trace+0x3e/0x360\n ? __flush_work+0x74/0x4e0\n __flush_work+0x7a/0x4e0\n ? __flush_work+0x74/0x4e0\n ? __lock_acquire+0xa78/0x2c80\n ? lock_acquire+0xd0/0x2b0\n ? mark_held_locks+0x49/0x70\n __cancel_work_timer+0x131/0x1c0\n ? mark_held_locks+0x49/0x70\n arfs_del_rules+0x143/0x1e0 [mlx5_core]\n mlx5e_arfs_disable+0x1b/0x30 [mlx5_core]\n mlx5e_ethtool_set_channels+0xcb/0x200 [mlx5_core]\n ethnl_set_channels+0x28f/0x3b0\n ethnl_default_set_doit+0xec/0x240\n genl_family_rcv_msg_doit+0xd0/0x120\n genl_rcv_msg+0x188/0x2c0\n ? ethn\n---truncated---(CVE-2024-27014)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nft_set_pipapo: walk over current view on netlink dump\r\n\r\nThe generation mask can be updated while netlink dump is in progress.\nThe pipapo set backend walk iterator cannot rely on it to infer what\nview of the datastructure is to be used. Add notation to specify if user\nwants to read/update the set.\r\n\r\nBased on patch from Florian Westphal.(CVE-2024-27017)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nf_tables: Fix potential data-race in __nft_obj_type_get()\r\n\r\nnft_unregister_obj() can concurrent with __nft_obj_type_get(),\nand there is not any protection when iterate over nf_tables_objects\nlist in __nft_obj_type_get(). Therefore, there is potential data-race\nof nf_tables_objects list entry.\r\n\r\nUse list_for_each_entry_rcu() to iterate over nf_tables_objects\nlist in __nft_obj_type_get(), and use rcu_read_lock() in the caller\nnft_obj_type_get() to protect the entire type query process.(CVE-2024-27019)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Fix potential NULL pointer dereferences in \u0026apos;dcn10_set_output_transfer_func()\u0026apos;\r\n\r\nThe \u0026apos;stream\u0026apos; pointer is used in dcn10_set_output_transfer_func() before\nthe check if \u0026apos;stream\u0026apos; is NULL.\r\n\r\nFixes the below:\ndrivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn10/dcn10_hwseq.c:1892 dcn10_set_output_transfer_func() warn: variable dereferenced before check \u0026apos;stream\u0026apos; (see line 1875)(CVE-2024-27044)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: ll_temac: platform_get_resource replaced by wrong function\r\n\r\nThe function platform_get_resource was replaced with\ndevm_platform_ioremap_resource_byname and is called using 0 as name.\r\n\r\nThis eventually ends up in platform_get_resource_byname in the call\nstack, where it causes a null pointer in strcmp.\r\n\r\n\tif (type == resource_type(r) \u0026amp;\u0026amp; !strcmp(r-\u0026gt;name, name))\r\n\r\nIt should have been replaced with devm_platform_ioremap_resource.(CVE-2024-35796)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsoc: fsl: qbman: Use raw spinlock for cgr_lock\r\n\r\nsmp_call_function always runs its callback in hard IRQ context, even on\nPREEMPT_RT, where spinlocks can sleep. So we need to use a raw spinlock\nfor cgr_lock to ensure we aren\u0026apos;t waiting on a sleeping task.\r\n\r\nAlthough this bug has existed for a while, it was not apparent until\ncommit ef2a8d5478b9 (\u0026quot;net: dpaa: Adjust queue depth on rate change\u0026quot;)\nwhich invokes smp_call_function_single via qman_update_cgr_safe every\ntime a link goes up or down.(CVE-2024-35819)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nubifs: Set page uptodate in the correct place\r\n\r\nPage cache reads are lockless, so setting the freshly allocated page\nuptodate before we\u0026apos;ve overwritten it with the data it\u0026apos;s supposed to have\nin it will allow a simultaneous reader to see old data. Move the call\nto SetPageUptodate into ubifs_write_end(), which is after we copied the\nnew data into the page.(CVE-2024-35821)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: libertas: fix some memleaks in lbs_allocate_cmd_buffer()\r\n\r\nIn the for statement of lbs_allocate_cmd_buffer(), if the allocation of\ncmdarray[i].cmdbuf fails, both cmdarray and cmdarray[i].cmdbuf needs to\nbe freed. Otherwise, there will be memleaks in lbs_allocate_cmd_buffer().(CVE-2024-35828)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsmb: client: fix UAF in smb2_reconnect_server()\r\n\r\nThe UAF bug is due to smb2_reconnect_server() accessing a session that\nis already being teared down by another thread that is executing\n__cifs_put_smb_ses(). This can happen when (a) the client has\nconnection to the server but no session or (b) another thread ends up\nsetting @ses-\u0026gt;ses_status again to something different than\nSES_EXITING.\r\n\r\nTo fix this, we need to make sure to unconditionally set\n@ses-\u0026gt;ses_status to SES_EXITING and prevent any other threads from\nsetting a new status while we\u0026apos;re still tearing it down.\r\n\r\nThe following can be reproduced by adding some delay to right after\nthe ipc is freed in __cifs_put_smb_ses() - which will give\nsmb2_reconnect_server() worker a chance to run and then accessing\n@ses-\u0026gt;ipc:\r\n\r\nkinit ...\nmount.cifs //srv/share /mnt/1 -o sec=krb5,nohandlecache,echo_interval=10\n[disconnect srv]\nls /mnt/1 \u0026amp;\u0026gt;/dev/null\nsleep 30\nkdestroy\n[reconnect srv]\nsleep 10\numount /mnt/1\n...\nCIFS: VFS: Verify user has a krb5 ticket and keyutils is installed\nCIFS: VFS: \\\\srv Send error in SessSetup = -126\nCIFS: VFS: Verify user has a krb5 ticket and keyutils is installed\nCIFS: VFS: \\\\srv Send error in SessSetup = -126\ngeneral protection fault, probably for non-canonical address\n0x6b6b6b6b6b6b6b6b: 0000 [#1] PREEMPT SMP NOPTI\nCPU: 3 PID: 50 Comm: kworker/3:1 Not tainted 6.9.0-rc2 #1\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-1.fc39\n04/01/2014\nWorkqueue: cifsiod smb2_reconnect_server [cifs]\nRIP: 0010:__list_del_entry_valid_or_report+0x33/0xf0\nCode: 4f 08 48 85 d2 74 42 48 85 c9 74 59 48 b8 00 01 00 00 00 00 ad\nde 48 39 c2 74 61 48 b8 22 01 00 00 00 00 74 69 \u0026lt;48\u0026gt; 8b 01 48 39 f8 75\n7b 48 8b 72 08 48 39 c6 0f 85 88 00 00 00 b8\nRSP: 0018:ffffc900001bfd70 EFLAGS: 00010a83\nRAX: dead000000000122 RBX: ffff88810da53838 RCX: 6b6b6b6b6b6b6b6b\nRDX: 6b6b6b6b6b6b6b6b RSI: ffffffffc02f6878 RDI: ffff88810da53800\nRBP: ffff88810da53800 R08: 0000000000000001 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000001 R12: ffff88810c064000\nR13: 0000000000000001 R14: ffff88810c064000 R15: ffff8881039cc000\nFS: 0000000000000000(0000) GS:ffff888157c00000(0000)\nknlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007fe3728b1000 CR3: 000000010caa4000 CR4: 0000000000750ef0\nPKRU: 55555554\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? die_addr+0x36/0x90\n ? exc_general_protection+0x1c1/0x3f0\n ? asm_exc_general_protection+0x26/0x30\n ? __list_del_entry_valid_or_report+0x33/0xf0\n __cifs_put_smb_ses+0x1ae/0x500 [cifs]\n smb2_reconnect_server+0x4ed/0x710 [cifs]\n process_one_work+0x205/0x6b0\n worker_thread+0x191/0x360\n ? __pfx_worker_thread+0x10/0x10\n kthread+0xe2/0x110\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x34/0x50\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1a/0x30\n \u0026lt;/TASK\u0026gt;(CVE-2024-35870)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nax25: fix use-after-free bugs caused by ax25_ds_del_timer\r\n\r\nWhen the ax25 device is detaching, the ax25_dev_device_down()\ncalls ax25_ds_del_timer() to cleanup the slave_timer. When\nthe timer handler is running, the ax25_ds_del_timer() that\ncalls del_timer() in it will return directly. As a result,\nthe use-after-free bugs could happen, one of the scenarios\nis shown below:\r\n\r\n (Thread 1) | (Thread 2)\n | ax25_ds_timeout()\nax25_dev_device_down() |\n ax25_ds_del_timer() |\n del_timer() |\n ax25_dev_put() //FREE |\n | ax25_dev-\u0026gt; //USE\r\n\r\nIn order to mitigate bugs, when the device is detaching, use\ntimer_shutdown_sync() to stop the timer.(CVE-2024-35887)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntcp: properly terminate timers for kernel sockets\r\n\r\nWe had various syzbot reports about tcp timers firing after\nthe corresponding netns has been dismantled.\r\n\r\nFortunately Josef Bacik could trigger the issue more often,\nand could test a patch I wrote two years ago.\r\n\r\nWhen TCP sockets are closed, we call inet_csk_clear_xmit_timers()\nto \u0026apos;stop\u0026apos; the timers.\r\n\r\ninet_csk_clear_xmit_timers() can be called from any context,\nincluding when socket lock is held.\nThis is the reason it uses sk_stop_timer(), aka del_timer().\nThis means that ongoing timers might finish much later.\r\n\r\nFor user sockets, this is fine because each running timer\nholds a reference on the socket, and the user socket holds\na reference on the netns.\r\n\r\nFor kernel sockets, we risk that the netns is freed before\ntimer can complete, because kernel sockets do not hold\nreference on the netns.\r\n\r\nThis patch adds inet_csk_clear_xmit_timers_sync() function\nthat using sk_stop_timer_sync() to make sure all timers\nare terminated before the kernel socket is released.\nModules using kernel sockets close them in their netns exit()\nhandler.\r\n\r\nAlso add sock_not_owned_by_me() helper to get LOCKDEP\nsupport : inet_csk_clear_xmit_timers_sync() must not be called\nwhile socket lock is held.\r\n\r\nIt is very possible we can revert in the future commit\n3a58f13a881e (\u0026quot;net: rds: acquire refcount on TCP sockets\u0026quot;)\nwhich attempted to solve the issue in rds only.\n(net/smc/af_smc.c and net/mptcp/subflow.c have similar code)\r\n\r\nWe probably can remove the check_net() tests from\ntcp_out_of_resources() and __tcp_close() in the future.(CVE-2024-35910)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnfc: nci: Fix uninit-value in nci_dev_up and nci_ntf_packet\r\n\r\nsyzbot reported the following uninit-value access issue [1][2]:\r\n\r\nnci_rx_work() parses and processes received packet. When the payload\nlength is zero, each message type handler reads uninitialized payload\nand KMSAN detects this issue. The receipt of a packet with a zero-size\npayload is considered unexpected, and therefore, such packets should be\nsilently discarded.\r\n\r\nThis patch resolved this issue by checking payload size before calling\neach message type handler codes.(CVE-2024-35915)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/vc4: don\u0026apos;t check if plane-\u0026gt;state-\u0026gt;fb == state-\u0026gt;fb\r\n\r\nCurrently, when using non-blocking commits, we can see the following\nkernel warning:\r\n\r\n[ 110.908514] ------------[ cut here ]------------\n[ 110.908529] refcount_t: underflow; use-after-free.\n[ 110.908620] WARNING: CPU: 0 PID: 1866 at lib/refcount.c:87 refcount_dec_not_one+0xb8/0xc0\n[ 110.908664] Modules linked in: rfcomm snd_seq_dummy snd_hrtimer snd_seq snd_seq_device cmac algif_hash aes_arm64 aes_generic algif_skcipher af_alg bnep hid_logitech_hidpp vc4 brcmfmac hci_uart btbcm brcmutil bluetooth snd_soc_hdmi_codec cfg80211 cec drm_display_helper drm_dma_helper drm_kms_helper snd_soc_core snd_compress snd_pcm_dmaengine fb_sys_fops sysimgblt syscopyarea sysfillrect raspberrypi_hwmon ecdh_generic ecc rfkill libaes i2c_bcm2835 binfmt_misc joydev snd_bcm2835(C) bcm2835_codec(C) bcm2835_isp(C) v4l2_mem2mem videobuf2_dma_contig snd_pcm bcm2835_v4l2(C) raspberrypi_gpiomem bcm2835_mmal_vchiq(C) videobuf2_v4l2 snd_timer videobuf2_vmalloc videobuf2_memops videobuf2_common snd videodev vc_sm_cma(C) mc hid_logitech_dj uio_pdrv_genirq uio i2c_dev drm fuse dm_mod drm_panel_orientation_quirks backlight ip_tables x_tables ipv6\n[ 110.909086] CPU: 0 PID: 1866 Comm: kodi.bin Tainted: G C 6.1.66-v8+ #32\n[ 110.909104] Hardware name: Raspberry Pi 3 Model B Rev 1.2 (DT)\n[ 110.909114] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[ 110.909132] pc : refcount_dec_not_one+0xb8/0xc0\n[ 110.909152] lr : refcount_dec_not_one+0xb4/0xc0\n[ 110.909170] sp : ffffffc00913b9c0\n[ 110.909177] x29: ffffffc00913b9c0 x28: 000000556969bbb0 x27: 000000556990df60\n[ 110.909205] x26: 0000000000000002 x25: 0000000000000004 x24: ffffff8004448480\n[ 110.909230] x23: ffffff800570b500 x22: ffffff802e03a7bc x21: ffffffecfca68c78\n[ 110.909257] x20: ffffff8002b42000 x19: ffffff802e03a600 x18: 0000000000000000\n[ 110.909283] x17: 0000000000000011 x16: ffffffffffffffff x15: 0000000000000004\n[ 110.909308] x14: 0000000000000fff x13: ffffffed577e47e0 x12: 0000000000000003\n[ 110.909333] x11: 0000000000000000 x10: 0000000000000027 x9 : c912d0d083728c00\n[ 110.909359] x8 : c912d0d083728c00 x7 : 65646e75203a745f x6 : 746e756f63666572\n[ 110.909384] x5 : ffffffed579f62ee x4 : ffffffed579eb01e x3 : 0000000000000000\n[ 110.909409] x2 : 0000000000000000 x1 : ffffffc00913b750 x0 : 0000000000000001\n[ 110.909434] Call trace:\n[ 110.909441] refcount_dec_not_one+0xb8/0xc0\n[ 110.909461] vc4_bo_dec_usecnt+0x4c/0x1b0 [vc4]\n[ 110.909903] vc4_cleanup_fb+0x44/0x50 [vc4]\n[ 110.910315] drm_atomic_helper_cleanup_planes+0x88/0xa4 [drm_kms_helper]\n[ 110.910669] vc4_atomic_commit_tail+0x390/0x9dc [vc4]\n[ 110.911079] commit_tail+0xb0/0x164 [drm_kms_helper]\n[ 110.911397] drm_atomic_helper_commit+0x1d0/0x1f0 [drm_kms_helper]\n[ 110.911716] drm_atomic_commit+0xb0/0xdc [drm]\n[ 110.912569] drm_mode_atomic_ioctl+0x348/0x4b8 [drm]\n[ 110.913330] drm_ioctl_kernel+0xec/0x15c [drm]\n[ 110.914091] drm_ioctl+0x24c/0x3b0 [drm]\n[ 110.914850] __arm64_sys_ioctl+0x9c/0xd4\n[ 110.914873] invoke_syscall+0x4c/0x114\n[ 110.914897] el0_svc_common+0xd0/0x118\n[ 110.914917] do_el0_svc+0x38/0xd0\n[ 110.914936] el0_svc+0x30/0x8c\n[ 110.914958] el0t_64_sync_handler+0x84/0xf0\n[ 110.914979] el0t_64_sync+0x18c/0x190\n[ 110.914996] ---[ end trace 0000000000000000 ]---\r\n\r\nThis happens because, although `prepare_fb` and `cleanup_fb` are\nperfectly balanced, we cannot guarantee consistency in the check\nplane-\u0026gt;state-\u0026gt;fb == state-\u0026gt;fb. This means that sometimes we can increase\nthe refcount in `prepare_fb` and don\u0026apos;t decrease it in `cleanup_fb`. The\nopposite can also be true.\r\n\r\nIn fact, the struct drm_plane .state shouldn\u0026apos;t be accessed directly\nbut instead, the `drm_atomic_get_new_plane_state()` helper function should\nbe used. So, we could stick to this check, but using\n`drm_atomic_get_new_plane_state()`. But actually, this check is not re\n---truncated---(CVE-2024-35932)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: send: handle path ref underflow in header iterate_inode_ref()\r\n\r\nChange BUG_ON to proper error handling if building the path buffer\nfails. The pointers are not printed so we don\u0026apos;t accidentally leak kernel\naddresses.(CVE-2024-35935)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: cfg80211: check A-MSDU format more carefully\r\n\r\nIf it looks like there\u0026apos;s another subframe in the A-MSDU\nbut the header isn\u0026apos;t fully there, we can end up reading\ndata out of bounds, only to discard later. Make this a\nbit more careful and check if the subframe header can\neven be present.(CVE-2024-35937)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/panfrost: Fix the error path in panfrost_mmu_map_fault_addr()\r\n\r\nSubject: [PATCH] drm/panfrost: Fix the error path in\n panfrost_mmu_map_fault_addr()\r\n\r\nIf some the pages or sgt allocation failed, we shouldn\u0026apos;t release the\npages ref we got earlier, otherwise we will end up with unbalanced\nget/put_pages() calls. We should instead leave everything in place\nand let the BO release function deal with extra cleanup when the object\nis destroyed, or let the fault handler try again next time it\u0026apos;s called.(CVE-2024-35951)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nBluetooth: L2CAP: Fix not validating setsockopt user input\r\n\r\nCheck user input length before copying data.(CVE-2024-35965)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nBluetooth: RFCOMM: Fix not validating setsockopt user input\r\n\r\nsyzbot reported rfcomm_sock_setsockopt_old() is copying data without\nchecking user input length.\r\n\r\nBUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset\ninclude/linux/sockptr.h:49 [inline]\nBUG: KASAN: slab-out-of-bounds in copy_from_sockptr\ninclude/linux/sockptr.h:55 [inline]\nBUG: KASAN: slab-out-of-bounds in rfcomm_sock_setsockopt_old\nnet/bluetooth/rfcomm/sock.c:632 [inline]\nBUG: KASAN: slab-out-of-bounds in rfcomm_sock_setsockopt+0x893/0xa70\nnet/bluetooth/rfcomm/sock.c:673\nRead of size 4 at addr ffff8880209a8bc3 by task syz-executor632/5064(CVE-2024-35966)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntty: n_gsm: fix possible out-of-bounds in gsm0_receive()\r\n\r\nAssuming the following:\n- side A configures the n_gsm in basic option mode\n- side B sends the header of a basic option mode frame with data length 1\n- side A switches to advanced option mode\n- side B sends 2 data bytes which exceeds gsm-\u0026gt;len\n Reason: gsm-\u0026gt;len is not used in advanced option mode.\n- side A switches to basic option mode\n- side B keeps sending until gsm0_receive() writes past gsm-\u0026gt;buf\n Reason: Neither gsm-\u0026gt;state nor gsm-\u0026gt;len have been reset after\n reconfiguration.\r\n\r\nFix this by changing gsm-\u0026gt;count to gsm-\u0026gt;len comparison from equal to less\nthan. Also add upper limit checks against the constant MAX_MRU in\ngsm0_receive() and gsm1_receive() to harden against memory corruption of\ngsm-\u0026gt;len and gsm-\u0026gt;mru.\r\n\r\nAll other checks remain as we still need to limit the data according to the\nuser configuration and actual payload size.(CVE-2024-36016)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntcp: defer shutdown(SEND_SHUTDOWN) for TCP_SYN_RECV sockets\r\n\r\nTCP_SYN_RECV state is really special, it is only used by\ncross-syn connections, mostly used by fuzzers.\r\n\r\nIn the following crash [1], syzbot managed to trigger a divide\nby zero in tcp_rcv_space_adjust()\r\n\r\nA socket makes the following state transitions,\nwithout ever calling tcp_init_transfer(),\nmeaning tcp_init_buffer_space() is also not called.\r\n\r\n TCP_CLOSE\nconnect()\n TCP_SYN_SENT\n TCP_SYN_RECV\nshutdown() -\u0026gt; tcp_shutdown(sk, SEND_SHUTDOWN)\n TCP_FIN_WAIT1\r\n\r\nTo fix this issue, change tcp_shutdown() to not\nperform a TCP_SYN_RECV -\u0026gt; TCP_FIN_WAIT1 transition,\nwhich makes no sense anyway.\r\n\r\nWhen tcp_rcv_state_process() later changes socket state\nfrom TCP_SYN_RECV to TCP_ESTABLISH, then look at\nsk-\u0026gt;sk_shutdown to finally enter TCP_FIN_WAIT1 state,\nand send a FIN packet from a sane socket state.\r\n\r\nThis means tcp_send_fin() can now be called from BH\ncontext, and must use GFP_ATOMIC allocations.\r\n\r\n[1]\ndivide error: 0000 [#1] PREEMPT SMP KASAN NOPTI\nCPU: 1 PID: 5084 Comm: syz-executor358 Not tainted 6.9.0-rc6-syzkaller-00022-g98369dccd2f8 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024\n RIP: 0010:tcp_rcv_space_adjust+0x2df/0x890 net/ipv4/tcp_input.c:767\nCode: e3 04 4c 01 eb 48 8b 44 24 38 0f b6 04 10 84 c0 49 89 d5 0f 85 a5 03 00 00 41 8b 8e c8 09 00 00 89 e8 29 c8 48 0f af c3 31 d2 \u0026lt;48\u0026gt; f7 f1 48 8d 1c 43 49 8d 96 76 08 00 00 48 89 d0 48 c1 e8 03 48\nRSP: 0018:ffffc900031ef3f0 EFLAGS: 00010246\nRAX: 0c677a10441f8f42 RBX: 000000004fb95e7e RCX: 0000000000000000\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000\nRBP: 0000000027d4b11f R08: ffffffff89e535a4 R09: 1ffffffff25e6ab7\nR10: dffffc0000000000 R11: ffffffff8135e920 R12: ffff88802a9f8d30\nR13: dffffc0000000000 R14: ffff88802a9f8d00 R15: 1ffff1100553f2da\nFS: 00005555775c0380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f1155bf2304 CR3: 000000002b9f2000 CR4: 0000000000350ef0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n tcp_recvmsg_locked+0x106d/0x25a0 net/ipv4/tcp.c:2513\n tcp_recvmsg+0x25d/0x920 net/ipv4/tcp.c:2578\n inet6_recvmsg+0x16a/0x730 net/ipv6/af_inet6.c:680\n sock_recvmsg_nosec net/socket.c:1046 [inline]\n sock_recvmsg+0x109/0x280 net/socket.c:1068\n ____sys_recvmsg+0x1db/0x470 net/socket.c:2803\n ___sys_recvmsg net/socket.c:2845 [inline]\n do_recvmmsg+0x474/0xae0 net/socket.c:2939\n __sys_recvmmsg net/socket.c:3018 [inline]\n __do_sys_recvmmsg net/socket.c:3041 [inline]\n __se_sys_recvmmsg net/socket.c:3034 [inline]\n __x64_sys_recvmmsg+0x199/0x250 net/socket.c:3034\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7faeb6363db9\nCode: 28 00 00 00 75 05 48 83 c4 28 c3 e8 c1 17 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007ffcc1997168 EFLAGS: 00000246 ORIG_RAX: 000000000000012b\nRAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007faeb6363db9\nRDX: 0000000000000001 RSI: 0000000020000bc0 RDI: 0000000000000005\nRBP: 0000000000000000 R08: 0000000000000000 R09: 000000000000001c\nR10: 0000000000000122 R11: 0000000000000246 R12: 0000000000000000\nR13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000001(CVE-2024-36905)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nblk-iocost: avoid out of bounds shift\r\n\r\nUBSAN catches undefined behavior in blk-iocost, where sometimes\niocg-\u0026gt;delay is shifted right by a number that is too large,\nresulting in undefined behavior on some architectures.\r\n\r\n[ 186.556576] ------------[ cut here ]------------\nUBSAN: shift-out-of-bounds in block/blk-iocost.c:1366:23\nshift exponent 64 is too large for 64-bit type \u0026apos;u64\u0026apos; (aka \u0026apos;unsigned long long\u0026apos;)\nCPU: 16 PID: 0 Comm: swapper/16 Tainted: G S E N 6.9.0-0_fbk700_debug_rc2_kbuilder_0_gc85af715cac0 #1\nHardware name: Quanta Twin Lakes MP/Twin Lakes Passive MP, BIOS F09_3A23 12/08/2020\nCall Trace:\n \u0026lt;IRQ\u0026gt;\n dump_stack_lvl+0x8f/0xe0\n __ubsan_handle_shift_out_of_bounds+0x22c/0x280\n iocg_kick_delay+0x30b/0x310\n ioc_timer_fn+0x2fb/0x1f80\n __run_timer_base+0x1b6/0x250\n...\r\n\r\nAvoid that undefined behavior by simply taking the\n\u0026quot;delay = 0\u0026quot; branch if the shift is too large.\r\n\r\nI am not sure what the symptoms of an undefined value\ndelay will be, but I suspect it could be more than a\nlittle annoying to debug.(CVE-2024-36916)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: bnx2fc: Remove spin_lock_bh while releasing resources after upload\r\n\r\nThe session resources are used by FW and driver when session is offloaded,\nonce session is uploaded these resources are not used. The lock is not\nrequired as these fields won\u0026apos;t be used any longer. The offload and upload\ncalls are sequential, hence lock is not required.\r\n\r\nThis will suppress following BUG_ON():\r\n\r\n[ 449.843143] ------------[ cut here ]------------\n[ 449.848302] kernel BUG at mm/vmalloc.c:2727!\n[ 449.853072] invalid opcode: 0000 [#1] PREEMPT SMP PTI\n[ 449.858712] CPU: 5 PID: 1996 Comm: kworker/u24:2 Not tainted 5.14.0-118.el9.x86_64 #1\nRebooting.\n[ 449.867454] Hardware name: Dell Inc. PowerEdge R730/0WCJNT, BIOS 2.3.4 11/08/2016\n[ 449.876966] Workqueue: fc_rport_eq fc_rport_work [libfc]\n[ 449.882910] RIP: 0010:vunmap+0x2e/0x30\n[ 449.887098] Code: 00 65 8b 05 14 a2 f0 4a a9 00 ff ff 00 75 1b 55 48 89 fd e8 34 36 79 00 48 85 ed 74 0b 48 89 ef 31 f6 5d e9 14 fc ff ff 5d c3 \u0026lt;0f\u0026gt; 0b 0f 1f 44 00 00 41 57 41 56 49 89 ce 41 55 49 89 fd 41 54 41\n[ 449.908054] RSP: 0018:ffffb83d878b3d68 EFLAGS: 00010206\n[ 449.913887] RAX: 0000000080000201 RBX: ffff8f4355133550 RCX: 000000000d400005\n[ 449.921843] RDX: 0000000000000001 RSI: 0000000000001000 RDI: ffffb83da53f5000\n[ 449.929808] RBP: ffff8f4ac6675800 R08: ffffb83d878b3d30 R09: 00000000000efbdf\n[ 449.937774] R10: 0000000000000003 R11: ffff8f434573e000 R12: 0000000000001000\n[ 449.945736] R13: 0000000000001000 R14: ffffb83da53f5000 R15: ffff8f43d4ea3ae0\n[ 449.953701] FS: 0000000000000000(0000) GS:ffff8f529fc80000(0000) knlGS:0000000000000000\n[ 449.962732] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 449.969138] CR2: 00007f8cf993e150 CR3: 0000000efbe10003 CR4: 00000000003706e0\n[ 449.977102] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[ 449.985065] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[ 449.993028] Call Trace:\n[ 449.995756] __iommu_dma_free+0x96/0x100\n[ 450.000139] bnx2fc_free_session_resc+0x67/0x240 [bnx2fc]\n[ 450.006171] bnx2fc_upload_session+0xce/0x100 [bnx2fc]\n[ 450.011910] bnx2fc_rport_event_handler+0x9f/0x240 [bnx2fc]\n[ 450.018136] fc_rport_work+0x103/0x5b0 [libfc]\n[ 450.023103] process_one_work+0x1e8/0x3c0\n[ 450.027581] worker_thread+0x50/0x3b0\n[ 450.031669] ? rescuer_thread+0x370/0x370\n[ 450.036143] kthread+0x149/0x170\n[ 450.039744] ? set_kthread_struct+0x40/0x40\n[ 450.044411] ret_from_fork+0x22/0x30\n[ 450.048404] Modules linked in: vfat msdos fat xfs nfs_layout_nfsv41_files rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver dm_service_time qedf qed crc8 bnx2fc libfcoe libfc scsi_transport_fc intel_rapl_msr intel_rapl_common x86_pkg_temp_thermal intel_powerclamp dcdbas rapl intel_cstate intel_uncore mei_me pcspkr mei ipmi_ssif lpc_ich ipmi_si fuse zram ext4 mbcache jbd2 loop nfsv3 nfs_acl nfs lockd grace fscache netfs irdma ice sd_mod t10_pi sg ib_uverbs ib_core 8021q garp mrp stp llc mgag200 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt mxm_wmi fb_sys_fops cec crct10dif_pclmul ahci crc32_pclmul bnx2x drm ghash_clmulni_intel libahci rfkill i40e libata megaraid_sas mdio wmi sunrpc lrw dm_crypt dm_round_robin dm_multipath dm_snapshot dm_bufio dm_mirror dm_region_hash dm_log dm_zero dm_mod linear raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx raid6_pq libcrc32c crc32c_intel raid1 raid0 iscsi_ibft squashfs be2iscsi bnx2i cnic uio cxgb4i cxgb4 tls\n[ 450.048497] libcxgbi libcxgb qla4xxx iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi edd ipmi_devintf ipmi_msghandler\n[ 450.159753] ---[ end trace 712de2c57c64abc8 ]---(CVE-2024-36919)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: lpfc: Move NPIV\u0026apos;s transport unregistration to after resource clean up\r\n\r\nThere are cases after NPIV deletion where the fabric switch still believes\nthe NPIV is logged into the fabric. This occurs when a vport is\nunregistered before the Remove All DA_ID CT and LOGO ELS are sent to the\nfabric.\r\n\r\nCurrently fc_remove_host(), which calls dev_loss_tmo for all D_IDs including\nthe fabric D_ID, removes the last ndlp reference and frees the ndlp rport\nobject. This sometimes causes the race condition where the final DA_ID and\nLOGO are skipped from being sent to the fabric switch.\r\n\r\nFix by moving the fc_remove_host() and scsi_remove_host() calls after DA_ID\nand LOGO are sent.(CVE-2024-36952)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/vmwgfx: Fix invalid reads in fence signaled events\r\n\r\nCorrectly set the length of the drm_event to the size of the structure\nthat\u0026apos;s actually used.\r\n\r\nThe length of the drm_event was set to the parent structure instead of\nto the drm_vmw_event_fence which is supposed to be read. drm_read\nuses the length parameter to copy the event to the user space thus\nresuling in oob reads.(CVE-2024-36960)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nBluetooth: L2CAP: Fix div-by-zero in l2cap_le_flowctl_init()\r\n\r\nl2cap_le_flowctl_init() can cause both div-by-zero and an integer\noverflow since hdev-\u0026gt;le_mtu may not fall in the valid range.\r\n\r\nMove MTU from hci_dev to hci_conn to validate MTU and stop the connection\nprocess earlier if MTU is invalid.\nAlso, add a missing validation in read_buffer_size() and make it return\nan error value if the validation fails.\nNow hci_conn_add() returns ERR_PTR() as it can fail due to the both a\nkzalloc failure and invalid MTU value.\r\n\r\ndivide error: 0000 [#1] PREEMPT SMP KASAN NOPTI\nCPU: 0 PID: 67 Comm: kworker/u5:0 Tainted: G W 6.9.0-rc5+ #20\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014\nWorkqueue: hci0 hci_rx_work\nRIP: 0010:l2cap_le_flowctl_init+0x19e/0x3f0 net/bluetooth/l2cap_core.c:547\nCode: e8 17 17 0c 00 66 41 89 9f 84 00 00 00 bf 01 00 00 00 41 b8 02 00 00 00 4c\n89 fe 4c 89 e2 89 d9 e8 27 17 0c 00 44 89 f0 31 d2 \u0026lt;66\u0026gt; f7 f3 89 c3 ff c3 4d 8d\nb7 88 00 00 00 4c 89 f0 48 c1 e8 03 42\nRSP: 0018:ffff88810bc0f858 EFLAGS: 00010246\nRAX: 00000000000002a0 RBX: 0000000000000000 RCX: dffffc0000000000\nRDX: 0000000000000000 RSI: ffff88810bc0f7c0 RDI: ffffc90002dcb66f\nRBP: ffff88810bc0f880 R08: aa69db2dda70ff01 R09: 0000ffaaaaaaaaaa\nR10: 0084000000ffaaaa R11: 0000000000000000 R12: ffff88810d65a084\nR13: dffffc0000000000 R14: 00000000000002a0 R15: ffff88810d65a000\nFS: 0000000000000000(0000) GS:ffff88811ac00000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000020000100 CR3: 0000000103268003 CR4: 0000000000770ef0\nPKRU: 55555554\nCall Trace:\n \u0026lt;TASK\u0026gt;\n l2cap_le_connect_req net/bluetooth/l2cap_core.c:4902 [inline]\n l2cap_le_sig_cmd net/bluetooth/l2cap_core.c:5420 [inline]\n l2cap_le_sig_channel net/bluetooth/l2cap_core.c:5486 [inline]\n l2cap_recv_frame+0xe59d/0x11710 net/bluetooth/l2cap_core.c:6809\n l2cap_recv_acldata+0x544/0x10a0 net/bluetooth/l2cap_core.c:7506\n hci_acldata_packet net/bluetooth/hci_core.c:3939 [inline]\n hci_rx_work+0x5e5/0xb20 net/bluetooth/hci_core.c:4176\n process_one_work kernel/workqueue.c:3254 [inline]\n process_scheduled_works+0x90f/0x1530 kernel/workqueue.c:3335\n worker_thread+0x926/0xe70 kernel/workqueue.c:3416\n kthread+0x2e3/0x380 kernel/kthread.c:388\n ret_from_fork+0x5c/0x90 arch/x86/kernel/process.c:147\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244\n \u0026lt;/TASK\u0026gt;\nModules linked in:\n---[ end trace 0000000000000000 ]---(CVE-2024-36968)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: fix __dst_negative_advice() race\r\n\r\n__dst_negative_advice() does not enforce proper RCU rules when\nsk-\u0026gt;dst_cache must be cleared, leading to possible UAF.\r\n\r\nRCU rules are that we must first clear sk-\u0026gt;sk_dst_cache,\nthen call dst_release(old_dst).\r\n\r\nNote that sk_dst_reset(sk) is implementing this protocol correctly,\nwhile __dst_negative_advice() uses the wrong order.\r\n\r\nGiven that ip6_negative_advice() has special logic\nagainst RTF_CACHE, this means each of the three -\u0026gt;negative_advice()\nexisting methods must perform the sk_dst_reset() themselves.\r\n\r\nNote the check against NULL dst is centralized in\n__dst_negative_advice(), there is no need to duplicate\nit in various callbacks.\r\n\r\nMany thanks to Clement Lecigne for tracking this issue.\r\n\r\nThis old bug became visible after the blamed commit, using UDP sockets.(CVE-2024-36971)",
"id": "OESA-2024-1738",
"modified": "2026-08-06T11:07:12Z",
"published": "2024-06-21T11:07:12Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1738"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47366"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48673"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48692"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52670"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52748"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52791"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52821"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52841"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52873"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52882"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26924"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26935"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26936"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26947"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26954"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26960"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27014"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27017"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27019"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27044"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35796"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35819"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35821"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35828"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35870"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35887"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35910"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35915"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35932"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35935"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35937"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35951"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35965"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35966"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36016"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36905"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36916"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36919"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36952"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36960"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36968"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36971"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2021-47366",
"CVE-2022-48673",
"CVE-2022-48692",
"CVE-2023-52670",
"CVE-2023-52748",
"CVE-2023-52791",
"CVE-2023-52821",
"CVE-2023-52841",
"CVE-2023-52873",
"CVE-2023-52882",
"CVE-2024-26924",
"CVE-2024-26935",
"CVE-2024-26936",
"CVE-2024-26947",
"CVE-2024-26954",
"CVE-2024-26960",
"CVE-2024-27014",
"CVE-2024-27017",
"CVE-2024-27019",
"CVE-2024-27044",
"CVE-2024-35796",
"CVE-2024-35819",
"CVE-2024-35821",
"CVE-2024-35828",
"CVE-2024-35870",
"CVE-2024-35887",
"CVE-2024-35910",
"CVE-2024-35915",
"CVE-2024-35932",
"CVE-2024-35935",
"CVE-2024-35937",
"CVE-2024-35951",
"CVE-2024-35965",
"CVE-2024-35966",
"CVE-2024-36016",
"CVE-2024-36905",
"CVE-2024-36916",
"CVE-2024-36919",
"CVE-2024-36952",
"CVE-2024-36960",
"CVE-2024-36968",
"CVE-2024-36971"
]
}
RHSA-2024:5101
Vulnerability from csaf_redhat - Published: 2024-08-08 04:53 - Updated: 2026-09-13 08:28In the Linux kernel, the following vulnerability has been resolved: mm: swap: fix race between free_swap_and_cache() and swapoff() The Linux kernel CVE team has assigned CVE-2024-26960 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024050129-CVE-2024-26960-ad6b@gregkh/T
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.