Action not permitted
Modal body text goes here.
Modal Title
Modal Body
CVE-2024-56531 (GCVE-0-2024-56531)
Vulnerability from cvelistv5 – Published: 2024-12-27 14:11 – Updated: 2026-08-05 11:44- CWE-667 - Improper Locking
| Vendor | Product | Version | CPE status | |
|---|---|---|---|---|
| Linux | Linux |
Affected:
523f1dce37434a9a6623bf46e7893e2b4b10ac3c , < 3993edf44d3df7b6e8c753eac6ac8783473fcbab
(git)
Affected: 523f1dce37434a9a6623bf46e7893e2b4b10ac3c , < ebad462eec93b0f701dfe4de98990e7355283801 (git) Affected: 523f1dce37434a9a6623bf46e7893e2b4b10ac3c , < 4dd821dcbfcecf7af6a08370b0b217cde2818acf (git) Affected: 523f1dce37434a9a6623bf46e7893e2b4b10ac3c , < cadf1d8e9ddcd74584ec961aeac14ac549b261d8 (git) Affected: 523f1dce37434a9a6623bf46e7893e2b4b10ac3c , < 237f3faf0177bdde728fa3106d730d806436aa4d (git) Affected: 523f1dce37434a9a6623bf46e7893e2b4b10ac3c , < 4507a8b9b30344c5ddd8219945f446d47e966a6d (git) Affected: 523f1dce37434a9a6623bf46e7893e2b4b10ac3c , < dd0de8cb708951cebf727aa045e8242ba651bb52 (git) Affected: 523f1dce37434a9a6623bf46e7893e2b4b10ac3c , < a3f9314752dbb6f6aa1f0f2b4c58243bda800738 (git) Affected: 523f1dce37434a9a6623bf46e7893e2b4b10ac3c , < b04dcbb7f7b1908806b7dc22671cdbe78ff2b82c (git) |
guessed | |
| Linux | Linux |
Affected:
2.6.22
Unaffected: 0 , < 2.6.22 (semver) Unaffected: 4.19.325 , ≤ 4.19.* (semver) Unaffected: 5.4.287 , ≤ 5.4.* (semver) Unaffected: 5.10.231 , ≤ 5.10.* (semver) Unaffected: 5.15.174 , ≤ 5.15.* (semver) Unaffected: 6.1.120 , ≤ 6.1.* (semver) Unaffected: 6.6.64 , ≤ 6.6.* (semver) Unaffected: 6.11.11 , ≤ 6.11.* (semver) Unaffected: 6.12.2 , ≤ 6.12.* (semver) Unaffected: 6.13 , ≤ * (original_commit_for_fix) |
guessed |
{
"containers": {
"adp": [
{
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 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-56531",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2025-10-01T20:02:52.447796Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-667",
"description": "CWE-667 Improper Locking",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2025-10-01T20:07:17.750Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
},
{
"providerMetadata": {
"dateUpdated": "2025-11-03T20:49:10.948Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00001.html"
},
{
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html"
}
],
"title": "CVE Program Container"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"sound/usb/caiaq/audio.c",
"sound/usb/caiaq/audio.h",
"sound/usb/caiaq/device.c",
"sound/usb/caiaq/input.c",
"sound/usb/caiaq/input.h"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "3993edf44d3df7b6e8c753eac6ac8783473fcbab",
"status": "affected",
"version": "523f1dce37434a9a6623bf46e7893e2b4b10ac3c",
"versionType": "git"
},
{
"lessThan": "ebad462eec93b0f701dfe4de98990e7355283801",
"status": "affected",
"version": "523f1dce37434a9a6623bf46e7893e2b4b10ac3c",
"versionType": "git"
},
{
"lessThan": "4dd821dcbfcecf7af6a08370b0b217cde2818acf",
"status": "affected",
"version": "523f1dce37434a9a6623bf46e7893e2b4b10ac3c",
"versionType": "git"
},
{
"lessThan": "cadf1d8e9ddcd74584ec961aeac14ac549b261d8",
"status": "affected",
"version": "523f1dce37434a9a6623bf46e7893e2b4b10ac3c",
"versionType": "git"
},
{
"lessThan": "237f3faf0177bdde728fa3106d730d806436aa4d",
"status": "affected",
"version": "523f1dce37434a9a6623bf46e7893e2b4b10ac3c",
"versionType": "git"
},
{
"lessThan": "4507a8b9b30344c5ddd8219945f446d47e966a6d",
"status": "affected",
"version": "523f1dce37434a9a6623bf46e7893e2b4b10ac3c",
"versionType": "git"
},
{
"lessThan": "dd0de8cb708951cebf727aa045e8242ba651bb52",
"status": "affected",
"version": "523f1dce37434a9a6623bf46e7893e2b4b10ac3c",
"versionType": "git"
},
{
"lessThan": "a3f9314752dbb6f6aa1f0f2b4c58243bda800738",
"status": "affected",
"version": "523f1dce37434a9a6623bf46e7893e2b4b10ac3c",
"versionType": "git"
},
{
"lessThan": "b04dcbb7f7b1908806b7dc22671cdbe78ff2b82c",
"status": "affected",
"version": "523f1dce37434a9a6623bf46e7893e2b4b10ac3c",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"sound/usb/caiaq/audio.c",
"sound/usb/caiaq/audio.h",
"sound/usb/caiaq/device.c",
"sound/usb/caiaq/input.c",
"sound/usb/caiaq/input.h"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "2.6.22"
},
{
"lessThan": "2.6.22",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "4.19.*",
"status": "unaffected",
"version": "4.19.325",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.287",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.231",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.174",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.120",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.64",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.11.*",
"status": "unaffected",
"version": "6.11.11",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.2",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.13",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "4.19.325",
"versionStartIncluding": "2.6.22",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.4.287",
"versionStartIncluding": "2.6.22",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.10.231",
"versionStartIncluding": "2.6.22",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.15.174",
"versionStartIncluding": "2.6.22",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.1.120",
"versionStartIncluding": "2.6.22",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6.64",
"versionStartIncluding": "2.6.22",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.11.11",
"versionStartIncluding": "2.6.22",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.12.2",
"versionStartIncluding": "2.6.22",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.13",
"versionStartIncluding": "2.6.22",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nALSA: caiaq: Use snd_card_free_when_closed() at disconnection\n\nThe USB disconnect callback is supposed to be short and not too-long\nwaiting. OTOH, the current code uses snd_card_free() at\ndisconnection, but this waits for the close of all used fds, hence it\ncan take long. It eventually blocks the upper layer USB ioctls, which\nmay trigger a soft lockup.\n\nAn easy workaround is to replace snd_card_free() with\nsnd_card_free_when_closed(). This variant returns immediately while\nthe release of resources is done asynchronously by the card device\nrelease at the last close.\n\nThis patch also splits the code to the disconnect and the free phases;\nthe former is called immediately at the USB disconnect callback while\nthe latter is called from the card destructor."
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 7.8,
"baseSeverity": "HIGH",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"scenarios": [
{
"lang": "en",
"value": "AV:L - The vulnerability is driven by a local unprivileged process holding open file descriptors on the card\u0027s `/dev/snd/*` nodes, which is what stalls the disconnect callback and leaves freed URBs reachable. No network path exists, and the kernel CNA consistently scores USB disconnect/unbind-time driver bugs (btusb, rtsx_usb_ms, uvcvideo) as Local rather than Physical.\nAC:L - The attacker simply opens a PCM/control/MIDI fd and never closes it; no memory-layout condition or timing beyond the attacker\u0027s influence is needed to wedge `snd_card_free()`. The associated free-ordering race is one the attacker widens at will by keeping streams open and issuing concurrent prepare/trigger ioctls.\nPR:L - Only the ability to open the caiaq card\u0027s `/dev/snd` device nodes is required, which is granted to the `audio` group and to the logged-in seat user by default logind ACLs. No capability check exists anywhere on the path.\nUI:N - No victim action is required \u2014 the attacker\u0027s own held fd is what blocks the disconnect callback, and the disconnect/unbind event is an ordinary system event rather than a deliberate user operation.\nS:U - The impact is confined to the kernel of the same host; there is no VM, IOMMU, or sandbox boundary crossed.\nC:H - Pre-fix, `data_urbs_in/out`, their transfer buffers, `data_cb_info` and the input device are freed while userspace fds still reference them, so a race between an in-flight `snd_pcm_prepare()`/`ep1_in_urb` completion and disconnect yields use-after-free reads on reallocated heap objects, which can be leveraged to disclose kernel memory.\nI:H - The same use-after-free window allows `usb_submit_urb()` on a freed `struct urb` and `input_report_*()` writes into a freed input device, giving the USB HCD and the driver write access to attacker-groomed heap memory \u2014 a control-flow-relevant corruption primitive.\nA:H - `snd_card_free()` blocks the USB disconnect callback indefinitely while holding the USB device lock, stalling hub event processing and all upper-layer USB ioctls and producing hung-task/soft-lockup conditions that require a reboot to clear; the use-after-free independently causes kernel oopses."
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-08-05T11:44:54.186Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/3993edf44d3df7b6e8c753eac6ac8783473fcbab"
},
{
"url": "https://git.kernel.org/stable/c/ebad462eec93b0f701dfe4de98990e7355283801"
},
{
"url": "https://git.kernel.org/stable/c/4dd821dcbfcecf7af6a08370b0b217cde2818acf"
},
{
"url": "https://git.kernel.org/stable/c/cadf1d8e9ddcd74584ec961aeac14ac549b261d8"
},
{
"url": "https://git.kernel.org/stable/c/237f3faf0177bdde728fa3106d730d806436aa4d"
},
{
"url": "https://git.kernel.org/stable/c/4507a8b9b30344c5ddd8219945f446d47e966a6d"
},
{
"url": "https://git.kernel.org/stable/c/dd0de8cb708951cebf727aa045e8242ba651bb52"
},
{
"url": "https://git.kernel.org/stable/c/a3f9314752dbb6f6aa1f0f2b4c58243bda800738"
},
{
"url": "https://git.kernel.org/stable/c/b04dcbb7f7b1908806b7dc22671cdbe78ff2b82c"
}
],
"title": "ALSA: caiaq: Use snd_card_free_when_closed() at disconnection",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2024-56531",
"datePublished": "2024-12-27T14:11:14.161Z",
"dateReserved": "2024-12-27T14:03:05.984Z",
"dateUpdated": "2026-08-05T11:44:54.186Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"epss": {
"cve": "CVE-2024-56531",
"date": "2026-10-05",
"epss": "0.00224",
"percentile": "0.11867"
},
"fkie_nvd": {
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nALSA: caiaq: Use snd_card_free_when_closed() at disconnection\n\nThe USB disconnect callback is supposed to be short and not too-long\nwaiting. OTOH, the current code uses snd_card_free() at\ndisconnection, but this waits for the close of all used fds, hence it\ncan take long. It eventually blocks the upper layer USB ioctls, which\nmay trigger a soft lockup.\n\nAn easy workaround is to replace snd_card_free() with\nsnd_card_free_when_closed(). This variant returns immediately while\nthe release of resources is done asynchronously by the card device\nrelease at the last close.\n\nThis patch also splits the code to the disconnect and the free phases;\nthe former is called immediately at the USB disconnect callback while\nthe latter is called from the card destructor."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: caiaq: Usar snd_card_free_when_closed() en la desconexi\u00f3n Se supone que la devoluci\u00f3n de llamada de desconexi\u00f3n USB es corta y no requiere una espera demasiado larga. Por otro lado, el c\u00f3digo actual usa snd_card_free() en la desconexi\u00f3n, pero esto espera el cierre de todos los fds usados, por lo tanto, puede tomar mucho tiempo. Eventualmente bloquea los ioctl USB de la capa superior, lo que puede desencadenar un bloqueo suave. Una soluci\u00f3n f\u00e1cil es reemplazar snd_card_free() con snd_card_free_when_closed(). Esta variante regresa inmediatamente mientras que la liberaci\u00f3n de recursos se realiza de forma asincr\u00f3nica por la liberaci\u00f3n del dispositivo de la tarjeta en el \u00faltimo cierre. Este parche tambi\u00e9n divide el c\u00f3digo en las fases de desconexi\u00f3n y liberaci\u00f3n; la primera se llama inmediatamente en la devoluci\u00f3n de llamada de desconexi\u00f3n USB mientras que la segunda se llama desde el destructor de la tarjeta."
}
],
"id": "CVE-2024-56531",
"lastModified": "2024-12-27T14:15:32.503",
"published": "2024-12-27T14:15:32.503",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/237f3faf0177bdde728fa3106d730d806436aa4d"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/3993edf44d3df7b6e8c753eac6ac8783473fcbab"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/4507a8b9b30344c5ddd8219945f446d47e966a6d"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/4dd821dcbfcecf7af6a08370b0b217cde2818acf"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/a3f9314752dbb6f6aa1f0f2b4c58243bda800738"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/b04dcbb7f7b1908806b7dc22671cdbe78ff2b82c"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/cadf1d8e9ddcd74584ec961aeac14ac549b261d8"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/dd0de8cb708951cebf727aa045e8242ba651bb52"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/ebad462eec93b0f701dfe4de98990e7355283801"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Awaiting Analysis"
},
"nvd": {
"cve": {
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"sound/usb/caiaq/audio.c",
"sound/usb/caiaq/audio.h",
"sound/usb/caiaq/device.c",
"sound/usb/caiaq/input.c",
"sound/usb/caiaq/input.h"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "3993edf44d3df7b6e8c753eac6ac8783473fcbab",
"status": "affected",
"version": "523f1dce37434a9a6623bf46e7893e2b4b10ac3c",
"versionType": "git"
},
{
"lessThan": "ebad462eec93b0f701dfe4de98990e7355283801",
"status": "affected",
"version": "523f1dce37434a9a6623bf46e7893e2b4b10ac3c",
"versionType": "git"
},
{
"lessThan": "4dd821dcbfcecf7af6a08370b0b217cde2818acf",
"status": "affected",
"version": "523f1dce37434a9a6623bf46e7893e2b4b10ac3c",
"versionType": "git"
},
{
"lessThan": "cadf1d8e9ddcd74584ec961aeac14ac549b261d8",
"status": "affected",
"version": "523f1dce37434a9a6623bf46e7893e2b4b10ac3c",
"versionType": "git"
},
{
"lessThan": "237f3faf0177bdde728fa3106d730d806436aa4d",
"status": "affected",
"version": "523f1dce37434a9a6623bf46e7893e2b4b10ac3c",
"versionType": "git"
},
{
"lessThan": "4507a8b9b30344c5ddd8219945f446d47e966a6d",
"status": "affected",
"version": "523f1dce37434a9a6623bf46e7893e2b4b10ac3c",
"versionType": "git"
},
{
"lessThan": "dd0de8cb708951cebf727aa045e8242ba651bb52",
"status": "affected",
"version": "523f1dce37434a9a6623bf46e7893e2b4b10ac3c",
"versionType": "git"
},
{
"lessThan": "a3f9314752dbb6f6aa1f0f2b4c58243bda800738",
"status": "affected",
"version": "523f1dce37434a9a6623bf46e7893e2b4b10ac3c",
"versionType": "git"
},
{
"lessThan": "b04dcbb7f7b1908806b7dc22671cdbe78ff2b82c",
"status": "affected",
"version": "523f1dce37434a9a6623bf46e7893e2b4b10ac3c",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"sound/usb/caiaq/audio.c",
"sound/usb/caiaq/audio.h",
"sound/usb/caiaq/device.c",
"sound/usb/caiaq/input.c",
"sound/usb/caiaq/input.h"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "2.6.22"
},
{
"lessThan": "2.6.22",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "4.19.*",
"status": "unaffected",
"version": "4.19.325",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.287",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.231",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.174",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.120",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.64",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.11.*",
"status": "unaffected",
"version": "6.11.11",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.2",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.13",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"configurations": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "7E224302-1ABD-4043-A983-C2B7F13E4454",
"versionEndExcluding": "4.19.325",
"versionStartIncluding": "2.6.22",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "E4B15788-D35E-4E5B-A9C0-070AE3729B34",
"versionEndExcluding": "5.4.287",
"versionStartIncluding": "4.20",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "B5C644CC-2BD7-4E32-BC54-8DCC7ABE9935",
"versionEndExcluding": "5.10.231",
"versionStartIncluding": "5.5",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "419FD073-1517-4FD5-8158-F94BC68A1E89",
"versionEndExcluding": "5.15.174",
"versionStartIncluding": "5.11",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "09AC6122-E2A4-40FE-9D33-268A1B2EC265",
"versionEndExcluding": "6.1.120",
"versionStartIncluding": "5.16",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "CA16DEE3-ABEC-4449-9F4A-7A3DC4FC36C7",
"versionEndExcluding": "6.6.64",
"versionStartIncluding": "6.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "21434379-192D-472F-9B54-D45E3650E893",
"versionEndExcluding": "6.11.11",
"versionStartIncluding": "6.7",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "D8882B1B-2ABC-4838-AC1D-DBDBB5764776",
"versionEndExcluding": "6.12.2",
"versionStartIncluding": "6.12",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nALSA: caiaq: Use snd_card_free_when_closed() at disconnection\n\nThe USB disconnect callback is supposed to be short and not too-long\nwaiting. OTOH, the current code uses snd_card_free() at\ndisconnection, but this waits for the close of all used fds, hence it\ncan take long. It eventually blocks the upper layer USB ioctls, which\nmay trigger a soft lockup.\n\nAn easy workaround is to replace snd_card_free() with\nsnd_card_free_when_closed(). This variant returns immediately while\nthe release of resources is done asynchronously by the card device\nrelease at the last close.\n\nThis patch also splits the code to the disconnect and the free phases;\nthe former is called immediately at the USB disconnect callback while\nthe latter is called from the card destructor."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: caiaq: Usar snd_card_free_when_closed() en la desconexi\u00f3n Se supone que la devoluci\u00f3n de llamada de desconexi\u00f3n USB es corta y no requiere una espera demasiado larga. Por otro lado, el c\u00f3digo actual usa snd_card_free() en la desconexi\u00f3n, pero esto espera el cierre de todos los fds usados, por lo tanto, puede tomar mucho tiempo. Eventualmente bloquea los ioctl USB de la capa superior, lo que puede desencadenar un bloqueo suave. Una soluci\u00f3n f\u00e1cil es reemplazar snd_card_free() con snd_card_free_when_closed(). Esta variante regresa inmediatamente mientras que la liberaci\u00f3n de recursos se realiza de forma asincr\u00f3nica por la liberaci\u00f3n del dispositivo de la tarjeta en el \u00faltimo cierre. Este parche tambi\u00e9n divide el c\u00f3digo en las fases de desconexi\u00f3n y liberaci\u00f3n; la primera se llama inmediatamente en la devoluci\u00f3n de llamada de desconexi\u00f3n USB mientras que la segunda se llama desde el destructor de la tarjeta."
}
],
"id": "CVE-2024-56531",
"lastModified": "2026-08-04T11:22:08.723",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 7.8,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 5.9,
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"type": "Secondary"
},
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 5.5,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 3.6,
"source": "nvd@nist.gov",
"type": "Primary"
},
{
"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-56531",
"options": [
{
"exploitation": "none"
},
{
"automatable": "no"
},
{
"technicalImpact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2025-10-01T20:02:52.447796Z",
"version": "2.0.3"
}
}
]
},
"published": "2024-12-27T14:15:32.503",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/237f3faf0177bdde728fa3106d730d806436aa4d"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/3993edf44d3df7b6e8c753eac6ac8783473fcbab"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/4507a8b9b30344c5ddd8219945f446d47e966a6d"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/4dd821dcbfcecf7af6a08370b0b217cde2818acf"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/a3f9314752dbb6f6aa1f0f2b4c58243bda800738"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/b04dcbb7f7b1908806b7dc22671cdbe78ff2b82c"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/cadf1d8e9ddcd74584ec961aeac14ac549b261d8"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/dd0de8cb708951cebf727aa045e8242ba651bb52"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/ebad462eec93b0f701dfe4de98990e7355283801"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00001.html"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Modified",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "CWE-667"
}
],
"source": "nvd@nist.gov",
"type": "Primary"
},
{
"description": [
{
"lang": "en",
"value": "CWE-667"
}
],
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"type": "Secondary"
}
]
}
},
"redhat_vex": {
"aggregate_severity": "Low",
"current_release_date": "2026-08-04T22:40:32+00:00",
"cve": "CVE-2024-56531",
"id": "CVE-2024-56531",
"initial_release_date": "2024-12-27T00:00:00+00:00",
"product_status:known_affected": "198",
"source": "Red Hat CSAF VEX",
"status": "final",
"title": "kernel: ALSA: caiaq: Use snd_card_free_when_closed() at disconnection",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2024/cve-2024-56531.json",
"version": "3"
},
"suse_vex": {
"aggregate_severity": "low",
"current_release_date": "2026-10-02T00:20:22Z",
"cve": "CVE-2024-56531",
"id": "CVE-2024-56531",
"initial_release_date": "2024-12-28T03:49:24Z",
"product_status:known_affected": "658",
"product_status:known_not_affected": "73",
"product_status:recommended": "499",
"source": "SUSE CSAF VEX",
"status": "interim",
"title": "SUSE CVE CVE-2024-56531",
"url": "https://ftp.suse.com/pub/projects/security/csaf-vex/cve-2024-56531.json",
"version": "75"
},
"vulnrichment": {
"containers": {
"adp": [
{
"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-56531",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2025-10-01T20:02:52.447796Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-667",
"description": "CWE-667 Improper Locking",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2025-10-01T15:40:08.192Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"sound/usb/caiaq/audio.c",
"sound/usb/caiaq/audio.h",
"sound/usb/caiaq/device.c",
"sound/usb/caiaq/input.c",
"sound/usb/caiaq/input.h"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "3993edf44d3df7b6e8c753eac6ac8783473fcbab",
"status": "affected",
"version": "523f1dce37434a9a6623bf46e7893e2b4b10ac3c",
"versionType": "git"
},
{
"lessThan": "ebad462eec93b0f701dfe4de98990e7355283801",
"status": "affected",
"version": "523f1dce37434a9a6623bf46e7893e2b4b10ac3c",
"versionType": "git"
},
{
"lessThan": "4dd821dcbfcecf7af6a08370b0b217cde2818acf",
"status": "affected",
"version": "523f1dce37434a9a6623bf46e7893e2b4b10ac3c",
"versionType": "git"
},
{
"lessThan": "cadf1d8e9ddcd74584ec961aeac14ac549b261d8",
"status": "affected",
"version": "523f1dce37434a9a6623bf46e7893e2b4b10ac3c",
"versionType": "git"
},
{
"lessThan": "237f3faf0177bdde728fa3106d730d806436aa4d",
"status": "affected",
"version": "523f1dce37434a9a6623bf46e7893e2b4b10ac3c",
"versionType": "git"
},
{
"lessThan": "4507a8b9b30344c5ddd8219945f446d47e966a6d",
"status": "affected",
"version": "523f1dce37434a9a6623bf46e7893e2b4b10ac3c",
"versionType": "git"
},
{
"lessThan": "dd0de8cb708951cebf727aa045e8242ba651bb52",
"status": "affected",
"version": "523f1dce37434a9a6623bf46e7893e2b4b10ac3c",
"versionType": "git"
},
{
"lessThan": "a3f9314752dbb6f6aa1f0f2b4c58243bda800738",
"status": "affected",
"version": "523f1dce37434a9a6623bf46e7893e2b4b10ac3c",
"versionType": "git"
},
{
"lessThan": "b04dcbb7f7b1908806b7dc22671cdbe78ff2b82c",
"status": "affected",
"version": "523f1dce37434a9a6623bf46e7893e2b4b10ac3c",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"sound/usb/caiaq/audio.c",
"sound/usb/caiaq/audio.h",
"sound/usb/caiaq/device.c",
"sound/usb/caiaq/input.c",
"sound/usb/caiaq/input.h"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "2.6.22"
},
{
"lessThan": "2.6.22",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "4.19.*",
"status": "unaffected",
"version": "4.19.325",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.287",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.231",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.174",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.120",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.64",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.11.*",
"status": "unaffected",
"version": "6.11.11",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.2",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.13",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "4.19.325",
"versionStartIncluding": "2.6.22",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.4.287",
"versionStartIncluding": "2.6.22",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.10.231",
"versionStartIncluding": "2.6.22",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.15.174",
"versionStartIncluding": "2.6.22",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.1.120",
"versionStartIncluding": "2.6.22",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6.64",
"versionStartIncluding": "2.6.22",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.11.11",
"versionStartIncluding": "2.6.22",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.12.2",
"versionStartIncluding": "2.6.22",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.13",
"versionStartIncluding": "2.6.22",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nALSA: caiaq: Use snd_card_free_when_closed() at disconnection\n\nThe USB disconnect callback is supposed to be short and not too-long\nwaiting. OTOH, the current code uses snd_card_free() at\ndisconnection, but this waits for the close of all used fds, hence it\ncan take long. It eventually blocks the upper layer USB ioctls, which\nmay trigger a soft lockup.\n\nAn easy workaround is to replace snd_card_free() with\nsnd_card_free_when_closed(). This variant returns immediately while\nthe release of resources is done asynchronously by the card device\nrelease at the last close.\n\nThis patch also splits the code to the disconnect and the free phases;\nthe former is called immediately at the USB disconnect callback while\nthe latter is called from the card destructor."
}
],
"providerMetadata": {
"dateUpdated": "2025-05-04T09:57:26.124Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/3993edf44d3df7b6e8c753eac6ac8783473fcbab"
},
{
"url": "https://git.kernel.org/stable/c/ebad462eec93b0f701dfe4de98990e7355283801"
},
{
"url": "https://git.kernel.org/stable/c/4dd821dcbfcecf7af6a08370b0b217cde2818acf"
},
{
"url": "https://git.kernel.org/stable/c/cadf1d8e9ddcd74584ec961aeac14ac549b261d8"
},
{
"url": "https://git.kernel.org/stable/c/237f3faf0177bdde728fa3106d730d806436aa4d"
},
{
"url": "https://git.kernel.org/stable/c/4507a8b9b30344c5ddd8219945f446d47e966a6d"
},
{
"url": "https://git.kernel.org/stable/c/dd0de8cb708951cebf727aa045e8242ba651bb52"
},
{
"url": "https://git.kernel.org/stable/c/a3f9314752dbb6f6aa1f0f2b4c58243bda800738"
},
{
"url": "https://git.kernel.org/stable/c/b04dcbb7f7b1908806b7dc22671cdbe78ff2b82c"
}
],
"title": "ALSA: caiaq: Use snd_card_free_when_closed() at disconnection",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2024-56531",
"datePublished": "2024-12-27T14:11:14.161Z",
"dateReserved": "2024-12-27T14:03:05.984Z",
"dateUpdated": "2025-10-01T20:07:17.750Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.1"
}
}
}
OESA-2025-1286 (CVE-2023-52926)
Vulnerability from osv_openeuler – Published: 2025-03-14 11:08 – Updated: 2026-08-06 11:08 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
IORING_OP_READ did not correctly consume the provided buffer list when read i/o returned < 0 (except for -EAGAIN and -EIOCBQUEUED return). This can lead to a potential use-after-free when the completion via io_rw_done runs at separate context.(CVE-2023-52926)
In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to shrink read extent node in batches
We use rwlock to protect core structure data of extent tree during its shrink, however, if there is a huge number of extent nodes in extent tree, during shrink of extent tree, it may hold rwlock for a very long time, which may trigger kernel hang issue.
This patch fixes to shrink read extent node in batches, so that, critical region of the rwlock can be shrunk to avoid its extreme long time hold.(CVE-2024-41935)
In the Linux kernel, the following vulnerability has been resolved:
dma-debug: fix a possible deadlock on radix_lock
radix_lock() shouldn't be held while holding dma_hash_entry[idx].lock otherwise, there's a possible deadlock scenario when dma debug API is called holding rq_lock():
CPU0 CPU1 CPU2 dma_free_attrs() check_unmap() add_dma_entry() __schedule() //out (A) rq_lock() get_hash_bucket() (A) dma_entry_hash check_sync() (A) radix_lock() (W) dma_entry_hash dma_entry_free() (W) radix_lock() // CPU2's one (W) rq_lock()
CPU1 situation can happen when it extending radix tree and it tries to wake up kswapd via wake_all_kswapd().
CPU2 situation can happen while perf_event_task_sched_out() (i.e. dma sync operation is called while deleting perf_event using etm and etr tmc which are Arm Coresight hwtracing driver backends).
To remove this possible situation, call dma_entry_free() after put_hash_bucket() in check_unmap().(CVE-2024-47143)
In the Linux kernel, the following vulnerability has been resolved:
dlm: fix possible lkb_resource null dereference
This patch fixes a possible null pointer dereference when this function is called from request_lock() as lkb->lkb_resource is not assigned yet, only after validate_lock_args() by calling attach_lkb(). Another issue is that a resource name could be a non printable bytearray and we cannot assume to be ASCII coded.
The log functionality is probably never being hit when DLM is used in normal way and no debug logging is enabled. The null pointer dereference can only occur on a new created lkb that does not have the resource assigned yet, it probably never hits the null pointer dereference but we should be sure that other changes might not change this behaviour and we actually can hit the mentioned null pointer dereference.
In this patch we just drop the printout of the resource name, the lkb id is enough to make a possible connection to a resource name if this exists.(CVE-2024-47809)
In the Linux kernel, the following vulnerability has been resolved:
bcache: revert replacing IS_ERR_OR_NULL with IS_ERR again
Commit 028ddcac477b ("bcache: Remove unnecessary NULL point check in node allocations") leads a NULL pointer deference in cache_set_flush().
1721 if (!IS_ERR_OR_NULL(c->root)) 1722 list_add(&c->root->list, &c->btree_cache);
>From the above code in cache_set_flush(), if previous registration code fails before allocating c->root, it is possible c->root is NULL as what it is initialized. __bch_btree_node_alloc() never returns NULL but c->root is possible to be NULL at above line 1721.
This patch replaces IS_ERR() by IS_ERR_OR_NULL() to fix this.(CVE-2024-48881)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: ipset: add missing range check in bitmap_ip_uadt
When tb[IPSET_ATTR_IP_TO] is not present but tb[IPSET_ATTR_CIDR] exists, the values of ip and ip_to are slightly swapped. Therefore, the range check for ip should be done later, but this part is missing and it seems that the vulnerability occurs.
So we should add missing range checks and remove unnecessary range checks.(CVE-2024-53141)
In the Linux kernel, the following vulnerability has been resolved:
comedi: Flush partial mappings in error case
If some remap_pfn_range() calls succeeded before one failed, we still have buffer pages mapped into the userspace page tables when we drop the buffer reference with comedi_buf_map_put(bm). The userspace mappings are only cleaned up later in the mmap error path.
Fix it by explicitly flushing all mappings in our VMA on the error path.
See commit 79a61cc3fc04 ("mm: avoid leaving partial pfn mappings around in error case").(CVE-2024-53148)
In the Linux kernel, the following vulnerability has been resolved:
wifi: ath9k: add range check for conn_rsp_epid in htc_connect_service()
I found the following bug in my fuzzer:
UBSAN: array-index-out-of-bounds in drivers/net/wireless/ath/ath9k/htc_hst.c:26:51 index 255 is out of range for type 'htc_endpoint [22]' CPU: 0 UID: 0 PID: 8 Comm: kworker/0:0 Not tainted 6.11.0-rc6-dirty #14 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: events request_firmware_work_func Call Trace: <TASK> dump_stack_lvl+0x180/0x1b0 __ubsan_handle_out_of_bounds+0xd4/0x130 htc_issue_send.constprop.0+0x20c/0x230 ? _raw_spin_unlock_irqrestore+0x3c/0x70 ath9k_wmi_cmd+0x41d/0x610 ? mark_held_locks+0x9f/0xe0 ...
Since this bug has been confirmed to be caused by insufficient verification of conn_rsp_epid, I think it would be appropriate to add a range check for conn_rsp_epid to htc_connect_service() to prevent the bug from occurring.(CVE-2024-53156)
In the Linux kernel, the following vulnerability has been resolved:
smb: During unmount, ensure all cached dir instances drop their dentry
The unmount process (cifs_kill_sb() calling close_all_cached_dirs()) can race with various cached directory operations, which ultimately results in dentries not being dropped and these kernel BUGs:
BUG: Dentry ffff88814f37e358{i=1000000000080,n=/} still in use (2) [unmount of cifs cifs] VFS: Busy inodes after unmount of cifs (cifs) ------------[ cut here ]------------ kernel BUG at fs/super.c:661!
This happens when a cfid is in the process of being cleaned up when, and has been removed from the cfids->entries list, including:
- Receiving a lease break from the server
- Server reconnection triggers invalidate_all_cached_dirs(), which removes all the cfids from the list
- The laundromat thread decides to expire an old cfid.
To solve these problems, dropping the dentry is done in queued work done in a newly-added cfid_put_wq workqueue, and close_all_cached_dirs() flushes that workqueue after it drops all the dentries of which it's aware. This is a global workqueue (rather than scoped to a mount), but the queued work is minimal.
The final cleanup work for cleaning up a cfid is performed via work queued in the serverclose_wq workqueue; this is done separate from dropping the dentries so that close_all_cached_dirs() doesn't block on any server operations.
Both of these queued works expect to invoked with a cfid reference and a tcon reference to avoid those objects from being freed while the work is ongoing.
While we're here, add proper locking to close_all_cached_dirs(), and locking around the freeing of cfid->dentry.(CVE-2024-53176)
In the Linux kernel, the following vulnerability has been resolved:
smb: prevent use-after-free due to open_cached_dir error paths
If open_cached_dir() encounters an error parsing the lease from the server, the error handling may race with receiving a lease break, resulting in open_cached_dir() freeing the cfid while the queued work is pending.
Update open_cached_dir() to drop refs rather than directly freeing the cfid.
Have cached_dir_lease_break(), cfids_laundromat_worker(), and invalidate_all_cached_dirs() clear has_lease immediately while still holding cfids->cfid_list_lock, and then use this to also simplify the reference counting in cfids_laundromat_worker() and invalidate_all_cached_dirs().
Fixes this KASAN splat (which manually injects an error and lease break in open_cached_dir()):
================================================================== BUG: KASAN: slab-use-after-free in smb2_cached_lease_break+0x27/0xb0 Read of size 8 at addr ffff88811cc24c10 by task kworker/3:1/65
CPU: 3 UID: 0 PID: 65 Comm: kworker/3:1 Not tainted 6.12.0-rc6-g255cf264e6e5-dirty #87 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 Workqueue: cifsiod smb2_cached_lease_break Call Trace: <TASK> dump_stack_lvl+0x77/0xb0 print_report+0xce/0x660 kasan_report+0xd3/0x110 smb2_cached_lease_break+0x27/0xb0 process_one_work+0x50a/0xc50 worker_thread+0x2ba/0x530 kthread+0x17c/0x1c0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30 </TASK>
Allocated by task 2464: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 open_cached_dir+0xa7d/0x1fb0 smb2_query_path_info+0x43c/0x6e0 cifs_get_fattr+0x346/0xf10 cifs_get_inode_info+0x157/0x210 cifs_revalidate_dentry_attr+0x2d1/0x460 cifs_getattr+0x173/0x470 vfs_statx_path+0x10f/0x160 vfs_statx+0xe9/0x150 vfs_fstatat+0x5e/0xc0 __do_sys_newfstatat+0x91/0xf0 do_syscall_64+0x95/0x1a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e
Freed by task 2464: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x51/0x70 kfree+0x174/0x520 open_cached_dir+0x97f/0x1fb0 smb2_query_path_info+0x43c/0x6e0 cifs_get_fattr+0x346/0xf10 cifs_get_inode_info+0x157/0x210 cifs_revalidate_dentry_attr+0x2d1/0x460 cifs_getattr+0x173/0x470 vfs_statx_path+0x10f/0x160 vfs_statx+0xe9/0x150 vfs_fstatat+0x5e/0xc0 __do_sys_newfstatat+0x91/0xf0 do_syscall_64+0x95/0x1a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e
Last potentially related work creation: kasan_save_stack+0x33/0x60 __kasan_record_aux_stack+0xad/0xc0 insert_work+0x32/0x100 __queue_work+0x5c9/0x870 queue_work_on+0x82/0x90 open_cached_dir+0x1369/0x1fb0 smb2_query_path_info+0x43c/0x6e0 cifs_get_fattr+0x346/0xf10 cifs_get_inode_info+0x157/0x210 cifs_revalidate_dentry_attr+0x2d1/0x460 cifs_getattr+0x173/0x470 vfs_statx_path+0x10f/0x160 vfs_statx+0xe9/0x150 vfs_fstatat+0x5e/0xc0 __do_sys_newfstatat+0x91/0xf0 do_syscall_64+0x95/0x1a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e
The buggy address belongs to the object at ffff88811cc24c00 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 16 bytes inside of freed 1024-byte region [ffff88811cc24c00, ffff88811cc25000)(CVE-2024-53177)
In the Linux kernel, the following vulnerability has been resolved:
smb: Don't leak cfid when reconnect races with open_cached_dir
open_cached_dir() may either race with the tcon reconnection even before compound_send_recv() or directly trigger a reconnection via SMB2_open_init() or SMB_query_info_init().
The reconnection process invokes invalidate_all_cached_dirs() via cifs_mark_open_files_invalid(), which removes all cfids from the cfids->entries list but doesn't drop a ref if has_lease isn't true. This results in the currently-being-constructed cfid not being on the list, but still having a refcount of 2. It leaks if returned from open_cached_dir().
Fix this by setting cfid->has_lease when the ref is actually taken; the cfid will not be used by other threads until it has a valid time.
Addresses these kmemleaks:
unreferenced object 0xffff8881090c4000 (size 1024): comm "bash", pid 1860, jiffies 4295126592 hex dump (first 32 bytes): 00 01 00 00 00 00 ad de 22 01 00 00 00 00 ad de ........"....... 00 ca 45 22 81 88 ff ff f8 dc 4f 04 81 88 ff ff ..E"......O..... backtrace (crc 6f58c20f): [<ffffffff8b895a1e>] __kmalloc_cache_noprof+0x2be/0x350 [<ffffffff8bda06e3>] open_cached_dir+0x993/0x1fb0 [<ffffffff8bdaa750>] cifs_readdir+0x15a0/0x1d50 [<ffffffff8b9a853f>] iterate_dir+0x28f/0x4b0 [<ffffffff8b9a9aed>] __x64_sys_getdents64+0xfd/0x200 [<ffffffff8cf6da05>] do_syscall_64+0x95/0x1a0 [<ffffffff8d00012f>] entry_SYSCALL_64_after_hwframe+0x76/0x7e unreferenced object 0xffff8881044fdcf8 (size 8): comm "bash", pid 1860, jiffies 4295126592 hex dump (first 8 bytes): 00 cc cc cc cc cc cc cc ........ backtrace (crc 10c106a9): [<ffffffff8b89a3d3>] __kmalloc_node_track_caller_noprof+0x363/0x480 [<ffffffff8b7d7256>] kstrdup+0x36/0x60 [<ffffffff8bda0700>] open_cached_dir+0x9b0/0x1fb0 [<ffffffff8bdaa750>] cifs_readdir+0x15a0/0x1d50 [<ffffffff8b9a853f>] iterate_dir+0x28f/0x4b0 [<ffffffff8b9a9aed>] __x64_sys_getdents64+0xfd/0x200 [<ffffffff8cf6da05>] do_syscall_64+0x95/0x1a0 [<ffffffff8d00012f>] entry_SYSCALL_64_after_hwframe+0x76/0x7e
And addresses these BUG splats when unmounting the SMB filesystem:
BUG: Dentry ffff888140590ba0{i=1000000000080,n=/} still in use (2) [unmount of cifs cifs] WARNING: CPU: 3 PID: 3433 at fs/dcache.c:1536 umount_check+0xd0/0x100 Modules linked in: CPU: 3 UID: 0 PID: 3433 Comm: bash Not tainted 6.12.0-rc4-g850925a8133c-dirty #49 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 RIP: 0010:umount_check+0xd0/0x100 Code: 8d 7c 24 40 e8 31 5a f4 ff 49 8b 54 24 40 41 56 49 89 e9 45 89 e8 48 89 d9 41 57 48 89 de 48 c7 c7 80 e7 db ac e8 f0 72 9a ff <0f> 0b 58 31 c0 5a 5b 5d 41 5c 41 5d 41 5e 41 5f e9 2b e5 5d 01 41 RSP: 0018:ffff88811cc27978 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff888140590ba0 RCX: ffffffffaaf20bae RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff8881f6fb6f40 RBP: ffff8881462ec000 R08: 0000000000000001 R09: ffffed1023984ee3 R10: ffff88811cc2771f R11: 00000000016cfcc0 R12: ffff888134383e08 R13: 0000000000000002 R14: ffff8881462ec668 R15: ffffffffaceab4c0 FS: 00007f23bfa98740(0000) GS:ffff8881f6f80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000556de4a6f808 CR3: 0000000123c80000 CR4: 0000000000350ef0 Call Trace: <TASK> d_walk+0x6a/0x530 shrink_dcache_for_umount+0x6a/0x200 generic_shutdown_super+0x52/0x2a0 kill_anon_super+0x22/0x40 cifs_kill_sb+0x159/0x1e0 deactivate_locked_super+0x66/0xe0 cleanup_mnt+0x140/0x210 task_work_run+0xfb/0x170 syscall_exit_to_user_mode+0x29f/0x2b0 do_syscall_64+0xa1/0x1a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f23bfb93ae7 Code: ff ff ff ff c3 66 0f 1f 44 00 00 48 8b 0d 11 93 0d 00 f7 d8 64 89 01 b8 ff ff ff ff eb bf 0f 1f 44 00 00 b8 50 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d e9 92 0d 00 f7 d8 64 89 ---truncated---(CVE-2024-53178)
In the Linux kernel, the following vulnerability has been resolved:
um: vector: Do not use drvdata in release
The drvdata is not available in release. Let's just use container_of() to get the vector_device instance. Otherwise, removing a vector device will result in a crash:
RIP: 0033:vector_device_release+0xf/0x50 RSP: 00000000e187bc40 EFLAGS: 00010202 RAX: 0000000060028f61 RBX: 00000000600f1baf RCX: 00000000620074e0 RDX: 000000006220b9c0 RSI: 0000000060551c80 RDI: 0000000000000000 RBP: 00000000e187bc50 R08: 00000000603ad594 R09: 00000000e187bb70 R10: 000000000000135a R11: 00000000603ad422 R12: 00000000623ae028 R13: 000000006287a200 R14: 0000000062006d30 R15: 00000000623700b6 Kernel panic - not syncing: Segfault with no mm CPU: 0 UID: 0 PID: 16 Comm: kworker/0:1 Not tainted 6.12.0-rc6-g59b723cd2adb #1 Workqueue: events mc_work_proc Stack: 60028f61 623ae028 e187bc80 60276fcd 6220b9c0 603f5820 623ae028 00000000 e187bcb0 603a2bcd 623ae000 62370010 Call Trace: [<60028f61>] ? vector_device_release+0x0/0x50 [<60276fcd>] device_release+0x70/0xba [<603a2bcd>] kobject_put+0xba/0xe7 [<60277265>] put_device+0x19/0x1c [<60281266>] platform_device_put+0x26/0x29 [<60281e5f>] platform_device_unregister+0x2c/0x2e [<60029422>] vector_remove+0x52/0x58 [<60031316>] ? mconsole_reply+0x0/0x50 [<600310c8>] mconsole_remove+0x160/0x1cc [<603b19f4>] ? strlen+0x0/0x15 [<60066611>] ? __dequeue_entity+0x1a9/0x206 [<600666a7>] ? set_next_entity+0x39/0x63 [<6006666e>] ? set_next_entity+0x0/0x63 [<60038fa6>] ? um_set_signals+0x0/0x43 [<6003070c>] mc_work_proc+0x77/0x91 [<60057664>] process_scheduled_works+0x1b3/0x2dd [<60055f32>] ? assign_work+0x0/0x58 [<60057f0a>] worker_thread+0x1e9/0x293 [<6005406f>] ? set_pf_worker+0x0/0x64 [<6005d65d>] ? arch_local_irq_save+0x0/0x2d [<6005d748>] ? kthread_exit+0x0/0x3a [<60057d21>] ? worker_thread+0x0/0x293 [<6005dbf1>] kthread+0x126/0x12b [<600219c5>] new_thread_handler+0x85/0xb6(CVE-2024-53181)
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix NULL ptr deref in crypto_aead_setkey()
Neither SMB3.0 or SMB3.02 supports encryption negotiate context, so when SMB2_GLOBAL_CAP_ENCRYPTION flag is set in the negotiate response, the client uses AES-128-CCM as the default cipher. See MS-SMB2 3.3.5.4.
Commit b0abcd65ec54 ("smb: client: fix UAF in async decryption") added a @server->cipher_type check to conditionally call smb3_crypto_aead_allocate(), but that check would always be false as @server->cipher_type is unset for SMB3.02.
Fix the following KASAN splat by setting @server->cipher_type for SMB3.02 as well.
mount.cifs //srv/share /mnt -o vers=3.02,seal,...
BUG: KASAN: null-ptr-deref in crypto_aead_setkey+0x2c/0x130 Read of size 8 at addr 0000000000000020 by task mount.cifs/1095 CPU: 1 UID: 0 PID: 1095 Comm: mount.cifs Not tainted 6.12.0 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-3.fc41 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x5d/0x80 ? crypto_aead_setkey+0x2c/0x130 kasan_report+0xda/0x110 ? crypto_aead_setkey+0x2c/0x130 crypto_aead_setkey+0x2c/0x130 crypt_message+0x258/0xec0 [cifs] ? __asan_memset+0x23/0x50 ? __pfx_crypt_message+0x10/0x10 [cifs] ? mark_lock+0xb0/0x6a0 ? hlock_class+0x32/0xb0 ? mark_lock+0xb0/0x6a0 smb3_init_transform_rq+0x352/0x3f0 [cifs] ? lock_acquire.part.0+0xf4/0x2a0 smb_send_rqst+0x144/0x230 [cifs] ? __pfx_smb_send_rqst+0x10/0x10 [cifs] ? hlock_class+0x32/0xb0 ? smb2_setup_request+0x225/0x3a0 [cifs] ? __pfx_cifs_compound_last_callback+0x10/0x10 [cifs] compound_send_recv+0x59b/0x1140 [cifs] ? __pfx_compound_send_recv+0x10/0x10 [cifs] ? __create_object+0x5e/0x90 ? hlock_class+0x32/0xb0 ? do_raw_spin_unlock+0x9a/0xf0 cifs_send_recv+0x23/0x30 [cifs] SMB2_tcon+0x3ec/0xb30 [cifs] ? __pfx_SMB2_tcon+0x10/0x10 [cifs] ? lock_acquire.part.0+0xf4/0x2a0 ? __pfx_lock_release+0x10/0x10 ? do_raw_spin_trylock+0xc6/0x120 ? lock_acquire+0x3f/0x90 ? _get_xid+0x16/0xd0 [cifs] ? __pfx_SMB2_tcon+0x10/0x10 [cifs] ? cifs_get_smb_ses+0xcdd/0x10a0 [cifs] cifs_get_smb_ses+0xcdd/0x10a0 [cifs] ? __pfx_cifs_get_smb_ses+0x10/0x10 [cifs] ? cifs_get_tcp_session+0xaa0/0xca0 [cifs] cifs_mount_get_session+0x8a/0x210 [cifs] dfs_mount_share+0x1b0/0x11d0 [cifs] ? __pfxlockacquire+0x10/0x10 ? pfx_dfs_mount_share+0x10/0x10 [cifs] ? lock_acquire.part.0+0xf4/0x2a0 ? find_held_lock+0x8a/0xa0 ? hlock_class+0x32/0xb0 ? lock_release+0x203/0x5d0 cifs_mount+0xb3/0x3d0 [cifs] ? do_raw_spin_trylock+0xc6/0x120 ? __pfx_cifs_mount+0x10/0x10 [cifs] ? lock_acquire+0x3f/0x90 ? find_nls+0x16/0xa0 ? smb3_update_mnt_flags+0x372/0x3b0 [cifs] cifs_smb3_do_mount+0x1e2/0xc80 [cifs] ? __pfx_vfs_parse_fs_string+0x10/0x10 ? __pfx_cifs_smb3_do_mount+0x10/0x10 [cifs] smb3_get_tree+0x1bf/0x330 [cifs] vfs_get_tree+0x4a/0x160 path_mount+0x3c1/0xfb0 ? kasan_quarantine_put+0xc7/0x1d0 ? __pfx_path_mount+0x10/0x10 ? kmem_cache_free+0x118/0x3e0 ? user_path_at+0x74/0xa0 __x64_sys_mount+0x1a6/0x1e0 ? __pfx___x64_sys_mount+0x10/0x10 ? mark_held_locks+0x1a/0x90 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2024-53185)
In the Linux kernel, the following vulnerability has been resolved:
s390/iucv: MSG_PEEK causes memory leak in iucv_sock_destruct()
Passing MSG_PEEK flag to skb_recv_datagram() increments skb refcount (skb->users) and iucv_sock_recvmsg() does not decrement skb refcount at exit. This results in skb memory leak in skb_queue_purge() and WARN_ON in iucv_sock_destruct() during socket close. To fix this decrease skb refcount by one if MSG_PEEK is set in order to prevent memory leak and WARN_ON.
WARNING: CPU: 2 PID: 6292 at net/iucv/af_iucv.c:286 iucv_sock_destruct+0x144/0x1a0 [af_iucv] CPU: 2 PID: 6292 Comm: afiucv_test_msg Kdump: loaded Tainted: G W 6.10.0-rc7 #1 Hardware name: IBM 3931 A01 704 (z/VM 7.3.0) Call Trace: [<001587c682c4aa98>] iucv_sock_destruct+0x148/0x1a0 [af_iucv] [<001587c682c4a9d0>] iucv_sock_destruct+0x80/0x1a0 [af_iucv] [<001587c704117a32>] __sk_destruct+0x52/0x550 [<001587c704104a54>] __sock_release+0xa4/0x230 [<001587c704104c0c>] sock_close+0x2c/0x40 [<001587c702c5f5a8>] __fput+0x2e8/0x970 [<001587c7024148c4>] task_work_run+0x1c4/0x2c0 [<001587c7023b0716>] do_exit+0x996/0x1050 [<001587c7023b13aa>] do_group_exit+0x13a/0x360 [<001587c7023b1626>] __s390x_sys_exit_group+0x56/0x60 [<001587c7022bccca>] do_syscall+0x27a/0x380 [<001587c7049a6a0c>] __do_syscall+0x9c/0x160 [<001587c7049ce8a8>] system_call+0x70/0x98 Last Breaking-Event-Address: [<001587c682c4a9d4>] iucv_sock_destruct+0x84/0x1a0 af_iucv
In the Linux kernel, the following vulnerability has been resolved:
vfio/pci: Properly hide first-in-list PCIe extended capability
There are cases where a PCIe extended capability should be hidden from the user. For example, an unknown capability (i.e., capability with ID greater than PCI_EXT_CAP_ID_MAX) or a capability that is intentionally chosen to be hidden from the user.
Hiding a capability is done by virtualizing and modifying the 'Next Capability Offset' field of the previous capability so it points to the capability after the one that should be hidden.
The special case where the first capability in the list should be hidden is handled differently because there is no previous capability that can be modified. In this case, the capability ID and version are zeroed while leaving the next pointer intact. This hides the capability and leaves an anchor for the rest of the capability list.
However, today, hiding the first capability in the list is not done properly if the capability is unknown, as struct vfio_pci_core_device->pci_config_map is set to the capability ID during initialization but the capability ID is not properly checked later when used in vfio_config_do_rw(). This leads to the following warning [1] and to an out-of-bounds access to ecap_perms array.
Fix it by checking cap_id in vfio_config_do_rw(), and if it is greater than PCI_EXT_CAP_ID_MAX, use an alternative struct perm_bits for direct read only access instead of the ecap_perms array.
Note that this is safe since the above is the only case where cap_id can exceed PCI_EXT_CAP_ID_MAX (except for the special capabilities, which are already checked before).
[1]
WARNING: CPU: 118 PID: 5329 at drivers/vfio/pci/vfio_pci_config.c:1900 vfio_pci_config_rw+0x395/0x430 [vfio_pci_core] CPU: 118 UID: 0 PID: 5329 Comm: simx-qemu-syste Not tainted 6.12.0+ #1 (snip) Call Trace: <TASK> ? show_regs+0x69/0x80 ? __warn+0x8d/0x140 ? vfio_pci_config_rw+0x395/0x430 [vfio_pci_core] ? report_bug+0x18f/0x1a0 ? handle_bug+0x63/0xa0 ? exc_invalid_op+0x19/0x70 ? asm_exc_invalid_op+0x1b/0x20 ? vfio_pci_config_rw+0x395/0x430 [vfio_pci_core] ? vfio_pci_config_rw+0x244/0x430 [vfio_pci_core] vfio_pci_rw+0x101/0x1b0 [vfio_pci_core] vfio_pci_core_read+0x1d/0x30 [vfio_pci_core] vfio_device_fops_read+0x27/0x40 [vfio] vfs_read+0xbd/0x340 ? vfio_device_fops_unl_ioctl+0xbb/0x740 [vfio] ? __rseq_handle_notify_resume+0xa4/0x4b0 __x64_sys_pread64+0x96/0xc0 x64_sys_call+0x1c3d/0x20d0 do_syscall_64+0x4d/0x120 entry_SYSCALL_64_after_hwframe+0x76/0x7e(CVE-2024-53214)
In the Linux kernel, the following vulnerability has been resolved:
nfsd: release svc_expkey/svc_export with rcu_work
The last reference for cache_head can be reduced to zero in c_show
and e_show(using rcu_read_lock and rcu_read_unlock). Consequently,
svc_export_put and expkey_put will be invoked, leading to two
issues:
- The
svc_export_putwill directly free ex_uuid. However,e_show/c_showwill accessex_uuidaftercache_put, which can trigger a use-after-free issue, shown below.
================================================================== BUG: KASAN: slab-use-after-free in svc_export_show+0x362/0x430 [nfsd] Read of size 1 at addr ff11000010fdc120 by task cat/870
CPU: 1 UID: 0 PID: 870 Comm: cat Not tainted 6.12.0-rc3+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x53/0x70 print_address_description.constprop.0+0x2c/0x3a0 print_report+0xb9/0x280 kasan_report+0xae/0xe0 svc_export_show+0x362/0x430 [nfsd] c_show+0x161/0x390 [sunrpc] seq_read_iter+0x589/0x770 seq_read+0x1e5/0x270 proc_reg_read+0xe1/0x140 vfs_read+0x125/0x530 ksys_read+0xc1/0x160 do_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e
Allocated by task 830: kasan_save_stack+0x20/0x40 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0 __kmalloc_node_track_caller_noprof+0x1bc/0x400 kmemdup_noprof+0x22/0x50 svc_export_parse+0x8a9/0xb80 [nfsd] cache_do_downcall+0x71/0xa0 [sunrpc] cache_write_procfs+0x8e/0xd0 [sunrpc] proc_reg_write+0xe1/0x140 vfs_write+0x1a5/0x6d0 ksys_write+0xc1/0x160 do_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e
Freed by task 868: kasan_save_stack+0x20/0x40 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x37/0x50 kfree+0xf3/0x3e0 svc_export_put+0x87/0xb0 [nfsd] cache_purge+0x17f/0x1f0 [sunrpc] nfsd_destroy_serv+0x226/0x2d0 [nfsd] nfsd_svc+0x125/0x1e0 [nfsd] write_threads+0x16a/0x2a0 [nfsd] nfsctl_transaction_write+0x74/0xa0 [nfsd] vfs_write+0x1a5/0x6d0 ksys_write+0xc1/0x160 do_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e
- We cannot sleep while using
rcu_read_lock/rcu_read_unlock. However,svc_export_put/expkey_putwill call path_put, which subsequently triggers a sleeping operation due to the followingdput.
============================= WARNING: suspicious RCU usage 5.10.0-dirty #141 Not tainted
... Call Trace: dump_stack+0x9a/0xd0 ___might_sleep+0x231/0x240 dput+0x39/0x600 path_put+0x1b/0x30 svc_export_put+0x17/0x80 e_show+0x1c9/0x200 seq_read_iter+0x63f/0x7c0 seq_read+0x226/0x2d0 vfs_read+0x113/0x2c0 ksys_read+0xc9/0x170 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x67/0xd1
Fix these issues by using rcu_work to help release
svc_expkey/svc_export. This approach allows for an asynchronous
context to invoke path_put and also facilitates the freeing of
uuid/exp/key after an RCU grace period.(CVE-2024-53216)
In the Linux kernel, the following vulnerability has been resolved:
unicode: Fix utf8_load() error path
utf8_load() requests the symbol "utf8_data_table" and then checks if the requested UTF-8 version is supported. If it's unsupported, it tries to put the data table using symbol_put(). If an unsupported version is requested, symbol_put() fails like this:
kernel BUG at kernel/module/main.c:786! RIP: 0010:__symbol_put+0x93/0xb0 Call Trace: <TASK> ? __die_body.cold+0x19/0x27 ? die+0x2e/0x50 ? do_trap+0xca/0x110 ? do_error_trap+0x65/0x80 ? __symbol_put+0x93/0xb0 ? exc_invalid_op+0x51/0x70 ? __symbol_put+0x93/0xb0 ? asm_exc_invalid_op+0x1a/0x20 ? __pfx_cmp_name+0x10/0x10 ? __symbol_put+0x93/0xb0 ? __symbol_put+0x62/0xb0 utf8_load+0xf8/0x150
That happens because symbol_put() expects the unique string that identify the symbol, instead of a pointer to the loaded symbol. Fix that by using such string.(CVE-2024-53233)
In the Linux kernel, the following vulnerability has been resolved:
NFS: Fix potential buffer overflowin nfs_sysfs_link_rpc_client()
name is char[64] where the size of clnt->cl_program->name remains unknown. Invoking strcat() directly will also lead to potential buffer overflow. Change them to strscpy() and strncat() to fix potential issues.(CVE-2024-54456)
In the Linux kernel, the following vulnerability has been resolved:
ALSA: caiaq: Use snd_card_free_when_closed() at disconnection
The USB disconnect callback is supposed to be short and not too-long waiting. OTOH, the current code uses snd_card_free() at disconnection, but this waits for the close of all used fds, hence it can take long. It eventually blocks the upper layer USB ioctls, which may trigger a soft lockup.
An easy workaround is to replace snd_card_free() with snd_card_free_when_closed(). This variant returns immediately while the release of resources is done asynchronously by the card device release at the last close.
This patch also splits the code to the disconnect and the free phases; the former is called immediately at the USB disconnect callback while the latter is called from the card destructor.(CVE-2024-56531)
In the Linux kernel, the following vulnerability has been resolved:
ALSA: usx2y: Use snd_card_free_when_closed() at disconnection
The USB disconnect callback is supposed to be short and not too-long waiting. OTOH, the current code uses snd_card_free() at disconnection, but this waits for the close of all used fds, hence it can take long. It eventually blocks the upper layer USB ioctls, which may trigger a soft lockup.
An easy workaround is to replace snd_card_free() with snd_card_free_when_closed(). This variant returns immediately while the release of resources is done asynchronously by the card device release at the last close.(CVE-2024-56533)
In the Linux kernel, the following vulnerability has been resolved:
wifi: mwifiex: Fix memcpy() field-spanning write warning in mwifiex_config_scan()
Replace one-element array with a flexible-array member in struct
mwifiex_ie_types_wildcard_ssid_params to fix the following warning
on a MT8173 Chromebook (mt8173-elm-hana):
[ 356.775250] ------------[ cut here ]------------ [ 356.784543] memcpy: detected field-spanning write (size 6) of single field "wildcard_ssid_tlv->ssid" at drivers/net/wireless/marvell/mwifiex/scan.c:904 (size 1) [ 356.813403] WARNING: CPU: 3 PID: 742 at drivers/net/wireless/marvell/mwifiex/scan.c:904 mwifiex_scan_networks+0x4fc/0xf28 [mwifiex]
The "(size 6)" above is exactly the length of the SSID of the network this device was connected to. The source of the warning looks like:
ssid_len = user_scan_in->ssid_list[i].ssid_len;
[...]
memcpy(wildcard_ssid_tlv->ssid,
user_scan_in->ssid_list[i].ssid, ssid_len);
There is a #define WILDCARD_SSID_TLV_MAX_SIZE that uses sizeof() on this struct, but it already didn't account for the size of the one-element array, so it doesn't need to be changed.(CVE-2024-56539)
In the Linux kernel, the following vulnerability has been resolved:
HID: hyperv: streamline driver probe to avoid devres issues
It was found that unloading 'hid_hyperv' module results in a devres complaint:
... hv_vmbus: unregistering driver hid_hyperv ------------[ cut here ]------------ WARNING: CPU: 2 PID: 3983 at drivers/base/devres.c:691 devres_release_group+0x1f2/0x2c0 ... Call Trace: <TASK> ? devres_release_group+0x1f2/0x2c0 ? __warn+0xd1/0x1c0 ? devres_release_group+0x1f2/0x2c0 ? report_bug+0x32a/0x3c0 ? handle_bug+0x53/0xa0 ? exc_invalid_op+0x18/0x50 ? asm_exc_invalid_op+0x1a/0x20 ? devres_release_group+0x1f2/0x2c0 ? devres_release_group+0x90/0x2c0 ? rcu_is_watching+0x15/0xb0 ? __pfx_devres_release_group+0x10/0x10 hid_device_remove+0xf5/0x220 device_release_driver_internal+0x371/0x540 ? klist_put+0xf3/0x170 bus_remove_device+0x1f1/0x3f0 device_del+0x33f/0x8c0 ? __pfx_device_del+0x10/0x10 ? cleanup_srcu_struct+0x337/0x500 hid_destroy_device+0xc8/0x130 mousevsc_remove+0xd2/0x1d0 [hid_hyperv] device_release_driver_internal+0x371/0x540 driver_detach+0xc5/0x180 bus_remove_driver+0x11e/0x2a0 ? __mutex_unlock_slowpath+0x160/0x5e0 vmbus_driver_unregister+0x62/0x2b0 [hv_vmbus] ...
And the issue seems to be that the corresponding devres group is not allocated. Normally, devres_open_group() is called from __hid_device_probe() but Hyper-V HID driver overrides 'hid_dev->driver' with 'mousevsc_hid_driver' stub and basically re-implements __hid_device_probe() by calling hid_parse() and hid_hw_start() but not devres_open_group(). hid_device_probe() does not call __hid_device_probe() for it. Later, when the driver is removed, hid_device_remove() calls devres_release_group() as it doesn't check whether hdev->driver was initially overridden or not.
The issue seems to be related to the commit 62c68e7cee33 ("HID: ensure timely release of driver-allocated resources") but the commit itself seems to be correct.
Fix the issue by dropping the 'hid_dev->driver' override and using hid_register_driver()/hid_unregister_driver() instead. Alternatively, it would have been possible to rely on the default handling but HID_CONNECT_DEFAULT implies HID_CONNECT_HIDRAW and it doesn't seem to work for mousevsc as-is.(CVE-2024-56545)
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: fix usage slab after free
[ +0.000021] BUG: KASAN: slab-use-after-free in drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched] [ +0.000027] Read of size 8 at addr ffff8881b8605f88 by task amd_pci_unplug/2147
[ +0.000023] CPU: 6 PID: 2147 Comm: amd_pci_unplug Not tainted 6.10.0+ #1 [ +0.000016] Hardware name: ASUS System Product Name/ROG STRIX B550-F GAMING (WI-FI), BIOS 1401 12/03/2020 [ +0.000016] Call Trace: [ +0.000008] <TASK> [ +0.000009] dump_stack_lvl+0x76/0xa0 [ +0.000017] print_report+0xce/0x5f0 [ +0.000017] ? drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched] [ +0.000019] ? srso_return_thunk+0x5/0x5f [ +0.000015] ? kasan_complete_mode_report_info+0x72/0x200 [ +0.000016] ? drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched] [ +0.000019] kasan_report+0xbe/0x110 [ +0.000015] ? drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched] [ +0.000023] __asan_report_load8_noabort+0x14/0x30 [ +0.000014] drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched] [ +0.000020] ? srso_return_thunk+0x5/0x5f [ +0.000013] ? __kasan_check_write+0x14/0x30 [ +0.000016] ? __pfx_drm_sched_entity_flush+0x10/0x10 [gpu_sched] [ +0.000020] ? srso_return_thunk+0x5/0x5f [ +0.000013] ? __kasan_check_write+0x14/0x30 [ +0.000013] ? srso_return_thunk+0x5/0x5f [ +0.000013] ? enable_work+0x124/0x220 [ +0.000015] ? __pfx_enable_work+0x10/0x10 [ +0.000013] ? srso_return_thunk+0x5/0x5f [ +0.000014] ? free_large_kmalloc+0x85/0xf0 [ +0.000016] drm_sched_entity_destroy+0x18/0x30 [gpu_sched] [ +0.000020] amdgpu_vce_sw_fini+0x55/0x170 [amdgpu] [ +0.000735] ? __kasan_check_read+0x11/0x20 [ +0.000016] vce_v4_0_sw_fini+0x80/0x110 [amdgpu] [ +0.000726] amdgpu_device_fini_sw+0x331/0xfc0 [amdgpu] [ +0.000679] ? mutex_unlock+0x80/0xe0 [ +0.000017] ? __pfx_amdgpu_device_fini_sw+0x10/0x10 [amdgpu] [ +0.000662] ? srso_return_thunk+0x5/0x5f [ +0.000014] ? __kasan_check_write+0x14/0x30 [ +0.000013] ? srso_return_thunk+0x5/0x5f [ +0.000013] ? mutex_unlock+0x80/0xe0 [ +0.000016] amdgpu_driver_release_kms+0x16/0x80 [amdgpu] [ +0.000663] drm_minor_release+0xc9/0x140 [drm] [ +0.000081] drm_release+0x1fd/0x390 [drm] [ +0.000082] __fput+0x36c/0xad0 [ +0.000018] __fput_sync+0x3c/0x50 [ +0.000014] __x64_sys_close+0x7d/0xe0 [ +0.000014] x64_sys_call+0x1bc6/0x2680 [ +0.000014] do_syscall_64+0x70/0x130 [ +0.000014] ? srso_return_thunk+0x5/0x5f [ +0.000014] ? irqentry_exit_to_user_mode+0x60/0x190 [ +0.000015] ? srso_return_thunk+0x5/0x5f [ +0.000014] ? irqentry_exit+0x43/0x50 [ +0.000012] ? srso_return_thunk+0x5/0x5f [ +0.000013] ? exc_page_fault+0x7c/0x110 [ +0.000015] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ +0.000014] RIP: 0033:0x7ffff7b14f67 [ +0.000013] Code: ff e8 0d 16 02 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 41 c3 48 83 ec 18 89 7c 24 0c e8 73 ba f7 ff [ +0.000026] RSP: 002b:00007fffffffe378 EFLAGS: 00000246 ORIG_RAX: 0000000000000003 [ +0.000019] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007ffff7b14f67 [ +0.000014] RDX: 0000000000000000 RSI: 00007ffff7f6f47a RDI: 0000000000000003 [ +0.000014] RBP: 00007fffffffe3a0 R08: 0000555555569890 R09: 0000000000000000 [ +0.000014] R10: 0000000000000000 R11: 0000000000000246 R12: 00007fffffffe5c8 [ +0.000013] R13: 00005555555552a9 R14: 0000555555557d48 R15: 00007ffff7ffd040 [ +0.000020] </TASK>
[ +0.000016] Allocated by task 383 on cpu 7 at 26.880319s: [ +0.000014] kasan_save_stack+0x28/0x60 [ +0.000008] kasan_save_track+0x18/0x70 [ +0.000007] kasan_save_alloc_info+0x38/0x60 [ +0.000007] __kasan_kmalloc+0xc1/0xd0 [ +0.000007] kmalloc_trace_noprof+0x180/0x380 [ +0.000007] drm_sched_init+0x411/0xec0 [gpu_sched] [ +0.000012] amdgpu_device_init+0x695f/0xa610 [amdgpu] [ +0.000658] amdgpu_driver_load_kms+0x1a/0x120 [amdgpu] [ +0.000662] amdgpu_pci_p ---truncated---(CVE-2024-56551)
In the Linux kernel, the following vulnerability has been resolved:
nfsd: make sure exp active before svc_export_show
The function e_show was called with protection from RCU. This only
ensures that exp will not be freed. Therefore, the reference count for
exp can drop to zero, which will trigger a refcount use-after-free
warning when exp_get is called. To resolve this issue, use
cache_get_rcu to ensure that exp remains active.
------------[ cut here ]------------ refcount_t: addition on 0; use-after-free. WARNING: CPU: 3 PID: 819 at lib/refcount.c:25 refcount_warn_saturate+0xb1/0x120 CPU: 3 UID: 0 PID: 819 Comm: cat Not tainted 6.12.0-rc3+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 RIP: 0010:refcount_warn_saturate+0xb1/0x120 ... Call Trace: <TASK> e_show+0x20b/0x230 [nfsd] seq_read_iter+0x589/0x770 seq_read+0x1e5/0x270 vfs_read+0x125/0x530 ksys_read+0xc1/0x160 do_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e(CVE-2024-56558)
In the Linux kernel, the following vulnerability has been resolved:
mm/slub: Avoid list corruption when removing a slab from the full list
Boot with slub_debug=UFPZ.
If allocated object failed in alloc_consistency_checks, all objects of the slab will be marked as used, and then the slab will be removed from the partial list.
When an object belonging to the slab got freed later, the remove_full() function is called. Because the slab is neither on the partial list nor on the full list, it eventually lead to a list corruption (actually a list poison being detected).
So we need to mark and isolate the slab page with metadata corruption, do not put it back in circulation.
Because the debug caches avoid all the fastpaths, reusing the frozen bit to mark slab page with metadata corruption seems to be fine.
[ 4277.385669] list_del corruption, ffffea00044b3e50->next is LIST_POISON1 (dead000000000100) [ 4277.387023] ------------[ cut here ]------------ [ 4277.387880] kernel BUG at lib/list_debug.c:56! [ 4277.388680] invalid opcode: 0000 [#1] PREEMPT SMP PTI [ 4277.389562] CPU: 5 PID: 90 Comm: kworker/5:1 Kdump: loaded Tainted: G OE 6.6.1-1 #1 [ 4277.392113] Workqueue: xfs-inodegc/vda1 xfs_inodegc_worker [xfs] [ 4277.393551] RIP: 0010:__list_del_entry_valid_or_report+0x7b/0xc0 [ 4277.394518] Code: 48 91 82 e8 37 f9 9a ff 0f 0b 48 89 fe 48 c7 c7 28 49 91 82 e8 26 f9 9a ff 0f 0b 48 89 fe 48 c7 c7 58 49 91 [ 4277.397292] RSP: 0018:ffffc90000333b38 EFLAGS: 00010082 [ 4277.398202] RAX: 000000000000004e RBX: ffffea00044b3e50 RCX: 0000000000000000 [ 4277.399340] RDX: 0000000000000002 RSI: ffffffff828f8715 RDI: 00000000ffffffff [ 4277.400545] RBP: ffffea00044b3e40 R08: 0000000000000000 R09: ffffc900003339f0 [ 4277.401710] R10: 0000000000000003 R11: ffffffff82d44088 R12: ffff888112cf9910 [ 4277.402887] R13: 0000000000000001 R14: 0000000000000001 R15: ffff8881000424c0 [ 4277.404049] FS: 0000000000000000(0000) GS:ffff88842fd40000(0000) knlGS:0000000000000000 [ 4277.405357] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 4277.406389] CR2: 00007f2ad0b24000 CR3: 0000000102a3a006 CR4: 00000000007706e0 [ 4277.407589] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 4277.408780] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 4277.410000] PKRU: 55555554 [ 4277.410645] Call Trace: [ 4277.411234] <TASK> [ 4277.411777] ? die+0x32/0x80 [ 4277.412439] ? do_trap+0xd6/0x100 [ 4277.413150] ? __list_del_entry_valid_or_report+0x7b/0xc0 [ 4277.414158] ? do_error_trap+0x6a/0x90 [ 4277.414948] ? __list_del_entry_valid_or_report+0x7b/0xc0 [ 4277.415915] ? exc_invalid_op+0x4c/0x60 [ 4277.416710] ? __list_del_entry_valid_or_report+0x7b/0xc0 [ 4277.417675] ? asm_exc_invalid_op+0x16/0x20 [ 4277.418482] ? __list_del_entry_valid_or_report+0x7b/0xc0 [ 4277.419466] ? __list_del_entry_valid_or_report+0x7b/0xc0 [ 4277.420410] free_to_partial_list+0x515/0x5e0 [ 4277.421242] ? xfs_iext_remove+0x41a/0xa10 [xfs] [ 4277.422298] xfs_iext_remove+0x41a/0xa10 [xfs] [ 4277.423316] ? xfs_inodegc_worker+0xb4/0x1a0 [xfs] [ 4277.424383] xfs_bmap_del_extent_delay+0x4fe/0x7d0 [xfs] [ 4277.425490] __xfs_bunmapi+0x50d/0x840 [xfs] [ 4277.426445] xfs_itruncate_extents_flags+0x13a/0x490 [xfs] [ 4277.427553] xfs_inactive_truncate+0xa3/0x120 [xfs] [ 4277.428567] xfs_inactive+0x22d/0x290 [xfs] [ 4277.429500] xfs_inodegc_worker+0xb4/0x1a0 [xfs] [ 4277.430479] process_one_work+0x171/0x340 [ 4277.431227] worker_thread+0x277/0x390 [ 4277.431962] ? __pfx_worker_thread+0x10/0x10 [ 4277.432752] kthread+0xf0/0x120 [ 4277.433382] ? __pfx_kthread+0x10/0x10 [ 4277.434134] ret_from_fork+0x2d/0x50 [ 4277.434837] ? __pfx_kthread+0x10/0x10 [ 4277.435566] ret_from_fork_asm+0x1b/0x30 [ 4277.436280] </TASK>(CVE-2024-56566)
In the Linux kernel, the following vulnerability has been resolved:
efi/libstub: Free correct pointer on failure
cmdline_ptr is an out parameter, which is not allocated by the function itself, and likely points into the caller's stack.
cmdline refers to the pool allocation that should be freed when cleaning up after a failure, so pass this instead to free_pool().(CVE-2024-56573)
In the Linux kernel, the following vulnerability has been resolved:
media: ts2020: fix null-ptr-deref in ts2020_probe()
KASAN reported a null-ptr-deref issue when executing the following command:
# echo ts2020 0x20 > /sys/bus/i2c/devices/i2c-0/new_device KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] CPU: 53 UID: 0 PID: 970 Comm: systemd-udevd Not tainted 6.12.0-rc2+ #24 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) RIP: 0010:ts2020_probe+0xad/0xe10 [ts2020] RSP: 0018:ffffc9000abbf598 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffffc0714809 RDX: 0000000000000002 RSI: ffff88811550be00 RDI: 0000000000000010 RBP: ffff888109868800 R08: 0000000000000001 R09: fffff52001577eb6 R10: 0000000000000000 R11: ffffc9000abbff50 R12: ffffffffc0714790 R13: 1ffff92001577eb8 R14: ffffffffc07190d0 R15: 0000000000000001 FS: 00007f95f13b98c0(0000) GS:ffff888149280000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000555d2634b000 CR3: 0000000152236000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ts2020_probe+0xad/0xe10 [ts2020] i2c_device_probe+0x421/0xb40 really_probe+0x266/0x850 ...
The cause of the problem is that when using sysfs to dynamically register an i2c device, there is no platform data, but the probe process of ts2020 needs to use platform data, resulting in a null pointer being accessed.
Solve this problem by adding checks to platform data.(CVE-2024-56574)
In the Linux kernel, the following vulnerability has been resolved:
media: i2c: tc358743: Fix crash in the probe error path when using polling
If an error occurs in the probe() function, we should remove the polling timer that was alarmed earlier, otherwise the timer is called with arguments that are already freed, which results in a crash.
------------[ cut here ]------------ WARNING: CPU: 3 PID: 0 at kernel/time/timer.c:1830 __run_timers+0x244/0x268 Modules linked in: CPU: 3 UID: 0 PID: 0 Comm: swapper/3 Not tainted 6.11.0 #226 Hardware name: Diasom DS-RK3568-SOM-EVB (DT) pstate: 804000c9 (Nzcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __run_timers+0x244/0x268 lr : __run_timers+0x1d4/0x268 sp : ffffff80eff2baf0 x29: ffffff80eff2bb50 x28: 7fffffffffffffff x27: ffffff80eff2bb00 x26: ffffffc080f669c0 x25: ffffff80efef6bf0 x24: ffffff80eff2bb00 x23: 0000000000000000 x22: dead000000000122 x21: 0000000000000000 x20: ffffff80efef6b80 x19: ffffff80041c8bf8 x18: ffffffffffffffff x17: ffffffc06f146000 x16: ffffff80eff27dc0 x15: 000000000000003e x14: 0000000000000000 x13: 00000000000054da x12: 0000000000000000 x11: 00000000000639c0 x10: 000000000000000c x9 : 0000000000000009 x8 : ffffff80eff2cb40 x7 : ffffff80eff2cb40 x6 : ffffff8002bee480 x5 : ffffffc080cb2220 x4 : ffffffc080cb2150 x3 : 00000000000f4240 x2 : 0000000000000102 x1 : ffffff80eff2bb00 x0 : ffffff80041c8bf0 Call trace: __run_timers+0x244/0x268 timer_expire_remote+0x50/0x68 tmigr_handle_remote+0x388/0x39c run_timer_softirq+0x38/0x44 handle_softirqs+0x138/0x298 __do_softirq+0x14/0x20 _dosoftirq+0x10/0x1c call_on_irq_stack+0x24/0x4c do_softirq_own_stack+0x1c/0x2c irq_exit_rcu+0x9c/0xcc el1_interrupt+0x48/0xc0 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x7c/0x80 default_idle_call+0x34/0x68 do_idle+0x23c/0x294 cpu_startup_entry+0x38/0x3c secondary_start_kernel+0x128/0x160 secondary_switched+0xb8/0xbc ---[ end trace 0000000000000000 ]---(CVE-2024-56576)
In the Linux kernel, the following vulnerability has been resolved:
media: mtk-jpeg: Fix null-ptr-deref during unload module
The workqueue should be destroyed in mtk_jpeg_core.c since commit 09aea13ecf6f ("media: mtk-jpeg: refactor some variables"), otherwise the below calltrace can be easily triggered.
[ 677.862514] Unable to handle kernel paging request at virtual address dfff800000000023 [ 677.863633] KASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f] ... [ 677.879654] CPU: 6 PID: 1071 Comm: modprobe Tainted: G O 6.8.12-mtk+gfa1a78e5d24b+ #17 ... [ 677.882838] pc : destroy_workqueue+0x3c/0x770 [ 677.883413] lr : mtk_jpegdec_destroy_workqueue+0x70/0x88 [mtk_jpeg_dec_hw] [ 677.884314] sp : ffff80008ad974f0 [ 677.884744] x29: ffff80008ad974f0 x28: ffff0000d7115580 x27: ffff0000dd691070 [ 677.885669] x26: ffff0000dd691408 x25: ffff8000844af3e0 x24: ffff80008ad97690 [ 677.886592] x23: ffff0000e051d400 x22: ffff0000dd691010 x21: dfff800000000000 [ 677.887515] x20: 0000000000000000 x19: 0000000000000000 x18: ffff800085397ac0 [ 677.888438] x17: 0000000000000000 x16: ffff8000801b87c8 x15: 1ffff000115b2e10 [ 677.889361] x14: 00000000f1f1f1f1 x13: 0000000000000000 x12: ffff7000115b2e4d [ 677.890285] x11: 1ffff000115b2e4c x10: ffff7000115b2e4c x9 : ffff80000aa43e90 [ 677.891208] x8 : 00008fffeea4d1b4 x7 : ffff80008ad97267 x6 : 0000000000000001 [ 677.892131] x5 : ffff80008ad97260 x4 : ffff7000115b2e4d x3 : 0000000000000000 [ 677.893054] x2 : 0000000000000023 x1 : dfff800000000000 x0 : 0000000000000118 [ 677.893977] Call trace: [ 677.894297] destroy_workqueue+0x3c/0x770 [ 677.894826] mtk_jpegdec_destroy_workqueue+0x70/0x88 [mtk_jpeg_dec_hw] [ 677.895677] devm_action_release+0x50/0x90 [ 677.896211] release_nodes+0xe8/0x170 [ 677.896688] devres_release_all+0xf8/0x178 [ 677.897219] device_unbind_cleanup+0x24/0x170 [ 677.897785] device_release_driver_internal+0x35c/0x480 [ 677.898461] device_release_driver+0x20/0x38 ... [ 677.912665] ---[ end trace 0000000000000000 ]---(CVE-2024-56577)
In the Linux kernel, the following vulnerability has been resolved:
media: amphion: Set video drvdata before register video device
The video drvdata should be set before the video device is registered, otherwise video_drvdata() may return NULL in the open() file ops, and led to oops.(CVE-2024-56579)
In the Linux kernel, the following vulnerability has been resolved:
leds: class: Protect brightness_show() with led_cdev->led_access mutex
There is NULL pointer issue observed if from Process A where hid device being added which results in adding a led_cdev addition and later a another call to access of led_cdev attribute from Process B can result in NULL pointer issue.
Use mutex led_cdev->led_access to protect access to led->cdev and its attribute inside brightness_show() and max_brightness_show() and also update the comment for mutex that it should be used to protect the led class device fields.
Process A Process B
kthread+0x114 worker_thread+0x244 process_scheduled_works+0x248 uhid_device_add_worker+0x24 hid_add_device+0x120 device_add+0x268 bus_probe_device+0x94 device_initial_probe+0x14 __device_attach+0xfc bus_for_each_drv+0x10c __device_attach_driver+0x14c driver_probe_device+0x3c __driver_probe_device+0xa0 really_probe+0x190 hid_device_probe+0x130 ps_probe+0x990 ps_led_register+0x94 devm_led_classdev_register_ext+0x58 led_classdev_register_ext+0x1f8 device_create_with_groups+0x48 device_create_groups_vargs+0xc8 device_add+0x244 kobject_uevent+0x14 kobject_uevent_env[jt]+0x224 mutex_unlock[jt]+0xc4 __mutex_unlock_slowpath+0xd4 wake_up_q+0x70 try_to_wake_up[jt]+0x48c preempt_schedule_common+0x28 __schedule+0x628 __switch_to+0x174 el0t_64_sync+0x1a8/0x1ac el0t_64_sync_handler+0x68/0xbc el0_svc+0x38/0x68 do_el0_svc+0x1c/0x28 el0_svc_common+0x80/0xe0 invoke_syscall+0x58/0x114 __arm64_sys_read+0x1c/0x2c ksys_read+0x78/0xe8 vfs_read+0x1e0/0x2c8 kernfs_fop_read_iter+0x68/0x1b4 seq_read_iter+0x158/0x4ec kernfs_seq_show+0x44/0x54 sysfs_kf_seq_show+0xb4/0x130 dev_attr_show+0x38/0x74 brightness_show+0x20/0x4c dualshock4_led_get_brightness+0xc/0x74
[ 3313.874295][ T4013] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000060 [ 3313.874301][ T4013] Mem abort info: [ 3313.874303][ T4013] ESR = 0x0000000096000006 [ 3313.874305][ T4013] EC = 0x25: DABT (current EL), IL = 32 bits [ 3313.874307][ T4013] SET = 0, FnV = 0 [ 3313.874309][ T4013] EA = 0, S1PTW = 0 [ 3313.874311][ T4013] FSC = 0x06: level 2 translation fault [ 3313.874313][ T4013] Data abort info: [ 3313.874314][ T4013] ISV = 0, ISS = 0x00000006, ISS2 = 0x00000000 [ 3313.874316][ T4013] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 3313.874318][ T4013] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 3313.874320][ T4013] user pgtable: 4k pages, 39-bit VAs, pgdp=00000008f2b0a000 ..
[ 3313.874332][ T4013] Dumping ftrace buffer: [ 3313.874334][ T4013] (ftrace buffer empty) .. .. [ dd3313.874639][ T4013] CPU: 6 PID: 4013 Comm: InputReader [ 3313.874648][ T4013] pc : dualshock4_led_get_brightness+0xc/0x74 [ 3313.874653][ T4013] lr : led_update_brightness+0x38/0x60 [ 3313.874656][ T4013] sp : ffffffc0b910bbd0 .. .. [ 3313.874685][ T4013] Call trace: [ 3313.874687][ T4013] dualshock4_led_get_brightness+0xc/0x74 [ 3313.874690][ T4013] brightness_show+0x20/0x4c [ 3313.874692][ T4013] dev_attr_show+0x38/0x74 [ 3313.874696][ T4013] sysfs_kf_seq_show+0xb4/0x130 [ 3313.874700][ T4013] kernfs_seq_show+0x44/0x54 [ 3313.874703][ T4013] seq_read_iter+0x158/0x4ec [ 3313.874705][ T4013] kernfs_fop_read_iter+0x68/0x1b4 [ 3313.874708][ T4013] vfs_read+0x1e0/0x2c8 [ 3313.874711][ T4013] ksys_read+0x78/0xe8 [ 3313.874714][ T4013] __arm64_sys_read+0x1c/0x2c [ 3313.874718][ T4013] invoke_syscall+0x58/0x114 [ 3313.874721][ T4013] el0_svc_common+0x80/0xe0 [ 3313.874724][ T4013] do_el0_svc+0x1c/0x28 [ 3313.874727][ T4013] el0_svc+0x38/0x68 [ 3313.874730][ T4013] el0t_64_sync_handler+0x68/0xbc [ 3313.874732][ T4013] el0t_64_sync+0x1a8/0x1ac(CVE-2024-56587)
In the Linux kernel, the following vulnerability has been resolved:
wifi: brcmfmac: Fix oops due to NULL pointer dereference in brcmf_sdiod_sglist_rw()
This patch fixes a NULL pointer dereference bug in brcmfmac that occurs when a high 'sd_sgentry_align' value applies (e.g. 512) and a lot of queued SKBs are sent from the pkt queue.
The problem is the number of entries in the pre-allocated sgtable, it is nents = max(rxglom_size, txglom_size) + max(rxglom_size, txglom_size) >> 4 + 1. Given the default [rt]xglom_size=32 it's actually 35 which is too small. Worst case, the pkt queue can end up with 64 SKBs. This occurs when a new SKB is added for each original SKB if tailroom isn't enough to hold tail_pad. At least one sg entry is needed for each SKB. So, eventually the "skb_queue_walk loop" in brcmf_sdiod_sglist_rw may run out of sg entries. This makes sg_next return NULL and this causes the oops.
The patch sets nents to max(rxglom_size, txglom_size) * 2 to be able handle the worst-case. Btw. this requires only 64-35=29 * 16 (or 20 if CONFIG_NEED_SG_DMA_LENGTH) = 464 additional bytes of memory.(CVE-2024-56593)
In the Linux kernel, the following vulnerability has been resolved:
net: inet6: do not leave a dangling sk pointer in inet6_create()
sock_init_data() attaches the allocated sk pointer to the provided sock object. If inet6_create() fails later, the sk object is released, but the sock object retains the dangling sk pointer, which may cause use-after-free later.
Clear the sock sk pointer on error.(CVE-2024-56600)
In the Linux kernel, the following vulnerability has been resolved:
net: inet: do not leave a dangling sk pointer in inet_create()
sock_init_data() attaches the allocated sk object to the provided sock object. If inet_create() fails later, the sk object is freed, but the sock object retains the dangling pointer, which may create use-after-free later.
Clear the sk pointer in the sock object on error.(CVE-2024-56601)
In the Linux kernel, the following vulnerability has been resolved:
net: ieee802154: do not leave a dangling sk pointer in ieee802154_create()
sock_init_data() attaches the allocated sk object to the provided sock object. If ieee802154_create() fails later, the allocated sk object is freed, but the dangling pointer remains in the provided sock object, which may allow use-after-free.
Clear the sk pointer in the sock object on error.(CVE-2024-56602)
In the Linux kernel, the following vulnerability has been resolved:
net: af_can: do not leave a dangling sk pointer in can_create()
On error can_create() frees the allocated sk object, but sock_init_data() has already attached it to the provided sock object. This will leave a dangling sk pointer in the sock object and may cause use-after-free later.(CVE-2024-56603)
In the Linux kernel, the following vulnerability has been resolved:
af_packet: avoid erroring out after sock_init_data() in packet_create()
After sock_init_data() the allocated sk object is attached to the provided sock object. On error, packet_create() frees the sk object leaving the dangling pointer in the sock object on return. Some other code may try to use this pointer and cause use-after-free.(CVE-2024-56606)
In the Linux kernel, the following vulnerability has been resolved:
can: dev: can_set_termination(): allow sleeping GPIOs
In commit 6e86a1543c37 ("can: dev: provide optional GPIO based termination support") GPIO based termination support was added.
For no particular reason that patch uses gpiod_set_value() to set the GPIO. This leads to the following warning, if the systems uses a sleeping GPIO, i.e. behind an I2C port expander:
| WARNING: CPU: 0 PID: 379 at /drivers/gpio/gpiolib.c:3496 gpiod_set_value+0x50/0x6c | CPU: 0 UID: 0 PID: 379 Comm: ip Not tainted 6.11.0-20241016-1 #1 823affae360cc91126e4d316d7a614a8bf86236c
Replace gpiod_set_value() by gpiod_set_value_cansleep() to allow the use of sleeping GPIOs.(CVE-2024-56625)
In the Linux kernel, the following vulnerability has been resolved:
LoongArch: Add architecture specific huge_pte_clear()
When executing mm selftests run_vmtests.sh, there is such an error:
BUG: Bad page state in process uffd-unit-tests pfn:00000 page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x0 flags: 0xffff0000002000(reserved|node=0|zone=0|lastcpupid=0xffff) raw: 00ffff0000002000 ffffbf0000000008 ffffbf0000000008 0000000000000000 raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set Modules linked in: snd_seq_dummy snd_seq snd_seq_device rfkill vfat fat virtio_balloon efi_pstore virtio_net pstore net_failover failover fuse nfnetlink virtio_scsi virtio_gpu virtio_dma_buf dm_multipath efivarfs CPU: 2 UID: 0 PID: 1913 Comm: uffd-unit-tests Not tainted 6.12.0 #184 Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 2/2/2022 Stack : 900000047c8ac000 0000000000000000 9000000000223a7c 900000047c8ac000 900000047c8af690 900000047c8af698 0000000000000000 900000047c8af7d8 900000047c8af7d0 900000047c8af7d0 900000047c8af5b0 0000000000000001 0000000000000001 900000047c8af698 10b3c7d53da40d26 0000010000000000 0000000000000022 0000000fffffffff fffffffffe000000 ffff800000000000 000000000000002f 0000800000000000 000000017a6d4000 90000000028f8940 0000000000000000 0000000000000000 90000000025aa5e0 9000000002905000 0000000000000000 90000000028f8940 ffff800000000000 0000000000000000 0000000000000000 0000000000000000 9000000000223a94 000000012001839c 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1d ... Call Trace: [<9000000000223a94>] show_stack+0x5c/0x180 [<9000000001c3fd64>] dump_stack_lvl+0x6c/0xa0 [<900000000056aa08>] bad_page+0x1a0/0x1f0 [<9000000000574978>] free_unref_folios+0xbf0/0xd20 [<90000000004e65cc>] folios_put_refs+0x1a4/0x2b8 [<9000000000599a0c>] free_pages_and_swap_cache+0x164/0x260 [<9000000000547698>] tlb_batch_pages_flush+0xa8/0x1c0 [<9000000000547f30>] tlb_finish_mmu+0xa8/0x218 [<9000000000543cb8>] exit_mmap+0x1a0/0x360 [<9000000000247658>] __mmput+0x78/0x200 [<900000000025583c>] do_exit+0x43c/0xde8 [<9000000000256490>] do_group_exit+0x68/0x110 [<9000000000256554>] sys_exit_group+0x1c/0x20 [<9000000001c413b4>] do_syscall+0x94/0x130 [<90000000002216d8>] handle_syscall+0xb8/0x158 Disabling lock debugging due to kernel taint BUG: non-zero pgtables_bytes on freeing mm: -16384
On LoongArch system, invalid huge pte entry should be invalid_pte_table or a single _PAGE_HUGE bit rather than a zero value. And it should be the same with invalid pmd entry, since pmd_none() is called by function free_pgd_range() and pmd_none() return 0 by huge_pte_clear(). So single _PAGE_HUGE bit is also treated as a valid pte table and free_pte_range() will be called in free_pmd_range().
free_pmd_range() pmd = pmd_offset(pud, addr); do { next = pmd_addr_end(addr, end); if (pmd_none_or_clear_bad(pmd)) continue; free_pte_range(tlb, pmd, addr); } while (pmd++, addr = next, addr != end);
Here invalid_pte_table is used for both invalid huge pte entry and pmd entry.(CVE-2024-56628)
In the Linux kernel, the following vulnerability has been resolved:
geneve: do not assume mac header is set in geneve_xmit_skb()
We should not assume mac header is set in output path.
Use skb_eth_hdr() instead of eth_hdr() to fix the issue.
sysbot reported the following :
WARNING: CPU: 0 PID: 11635 at include/linux/skbuff.h:3052 skb_mac_header include/linux/skbuff.h:3052 [inline] WARNING: CPU: 0 PID: 11635 at include/linux/skbuff.h:3052 eth_hdr include/linux/if_ether.h:24 [inline] WARNING: CPU: 0 PID: 11635 at include/linux/skbuff.h:3052 geneve_xmit_skb drivers/net/geneve.c:898 [inline] WARNING: CPU: 0 PID: 11635 at include/linux/skbuff.h:3052 geneve_xmit+0x4c38/0x5730 drivers/net/geneve.c:1039 Modules linked in: CPU: 0 UID: 0 PID: 11635 Comm: syz.4.1423 Not tainted 6.12.0-syzkaller-10296-gaaf20f870da0 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:skb_mac_header include/linux/skbuff.h:3052 [inline] RIP: 0010:eth_hdr include/linux/if_ether.h:24 [inline] RIP: 0010:geneve_xmit_skb drivers/net/geneve.c:898 [inline] RIP: 0010:geneve_xmit+0x4c38/0x5730 drivers/net/geneve.c:1039 Code: 21 c6 02 e9 35 d4 ff ff e8 a5 48 4c fb 90 0f 0b 90 e9 fd f5 ff ff e8 97 48 4c fb 90 0f 0b 90 e9 d8 f5 ff ff e8 89 48 4c fb 90 <0f> 0b 90 e9 41 e4 ff ff e8 7b 48 4c fb 90 0f 0b 90 e9 cd e7 ff ff RSP: 0018:ffffc90003b2f870 EFLAGS: 00010283 RAX: 000000000000037a RBX: 000000000000ffff RCX: ffffc9000dc3d000 RDX: 0000000000080000 RSI: ffffffff86428417 RDI: 0000000000000003 RBP: ffffc90003b2f9f0 R08: 0000000000000003 R09: 000000000000ffff R10: 000000000000ffff R11: 0000000000000002 R12: ffff88806603c000 R13: 0000000000000000 R14: ffff8880685b2780 R15: 0000000000000e23 FS: 00007fdc2deed6c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b30a1dff8 CR3: 0000000056b8c000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __netdev_start_xmit include/linux/netdevice.h:5002 [inline] netdev_start_xmit include/linux/netdevice.h:5011 [inline] __dev_direct_xmit+0x58a/0x720 net/core/dev.c:4490 dev_direct_xmit include/linux/netdevice.h:3181 [inline] packet_xmit+0x1e4/0x360 net/packet/af_packet.c:285 packet_snd net/packet/af_packet.c:3146 [inline] packet_sendmsg+0x2700/0x5660 net/packet/af_packet.c:3178 sock_sendmsg_nosec net/socket.c:711 [inline] __sock_sendmsg net/socket.c:726 [inline] __sys_sendto+0x488/0x4f0 net/socket.c:2197 __do_sys_sendto net/socket.c:2204 [inline] __se_sys_sendto net/socket.c:2200 [inline] __x64_sys_sendto+0xe0/0x1c0 net/socket.c:2200 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2024-56636)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: ipset: Hold module reference while requesting a module
User space may unload ip_set.ko while it is itself requesting a set type backend module, leading to a kernel crash. The race condition may be provoked by inserting an mdelay() right after the nfnl_unlock() call.(CVE-2024-56637)
In the Linux kernel, the following vulnerability has been resolved:
dccp: Fix memory leak in dccp_feat_change_recv
If dccp_feat_push_confirm() fails after new value for SP feature was accepted without reconciliation ('entry == NULL' branch), memory allocated for that value with dccp_feat_clone_sp_val() is never freed.
Here is the kmemleak stack for this:
unreferenced object 0xffff88801d4ab488 (size 8): comm "syz-executor310", pid 1127, jiffies 4295085598 (age 41.666s) hex dump (first 8 bytes): 01 b4 4a 1d 80 88 ff ff ..J..... backtrace: [<00000000db7cabfe>] kmemdup+0x23/0x50 mm/util.c:128 [<0000000019b38405>] kmemdup include/linux/string.h:465 [inline] [<0000000019b38405>] dccp_feat_clone_sp_val net/dccp/feat.c:371 [inline] [<0000000019b38405>] dccp_feat_clone_sp_val net/dccp/feat.c:367 [inline] [<0000000019b38405>] dccp_feat_change_recv net/dccp/feat.c:1145 [inline] [<0000000019b38405>] dccp_feat_parse_options+0x1196/0x2180 net/dccp/feat.c:1416 [<00000000b1f6d94a>] dccp_parse_options+0xa2a/0x1260 net/dccp/options.c:125 [<0000000030d7b621>] dccp_rcv_state_process+0x197/0x13d0 net/dccp/input.c:650 [<000000001f74c72e>] dccp_v4_do_rcv+0xf9/0x1a0 net/dccp/ipv4.c:688 [<00000000a6c24128>] sk_backlog_rcv include/net/sock.h:1041 [inline] [<00000000a6c24128>] __release_sock+0x139/0x3b0 net/core/sock.c:2570 [<00000000cf1f3a53>] release_sock+0x54/0x1b0 net/core/sock.c:3111 [<000000008422fa23>] inet_wait_for_connect net/ipv4/af_inet.c:603 [inline] [<000000008422fa23>] __inet_stream_connect+0x5d0/0xf70 net/ipv4/af_inet.c:696 [<0000000015b6f64d>] inet_stream_connect+0x53/0xa0 net/ipv4/af_inet.c:735 [<0000000010122488>] __sys_connect_file+0x15c/0x1a0 net/socket.c:1865 [<00000000b4b70023>] __sys_connect+0x165/0x1a0 net/socket.c:1882 [<00000000f4cb3815>] __do_sys_connect net/socket.c:1892 [inline] [<00000000f4cb3815>] __se_sys_connect net/socket.c:1889 [inline] [<00000000f4cb3815>] __x64_sys_connect+0x6e/0xb0 net/socket.c:1889 [<00000000e7b1e839>] do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46 [<0000000055e91434>] entry_SYSCALL_64_after_hwframe+0x67/0xd1
Clean up the allocated memory in case of dccp_feat_push_confirm() failure and bail out with an error reset code.
Found by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2024-56643)
In the Linux kernel, the following vulnerability has been resolved:
net/ipv6: release expired exception dst cached in socket
Dst objects get leaked in ip6_negative_advice() when this function is executed for an expired IPv6 route located in the exception table. There are several conditions that must be fulfilled for the leak to occur: * an ICMPv6 packet indicating a change of the MTU for the path is received, resulting in an exception dst being created * a TCP connection that uses the exception dst for routing packets must start timing out so that TCP begins retransmissions * after the exception dst expires, the FIB6 garbage collector must not run before TCP executes ip6_negative_advice() for the expired exception dst
When TCP executes ip6_negative_advice() for an exception dst that has expired and if no other socket holds a reference to the exception dst, the refcount of the exception dst is 2, which corresponds to the increment made by dst_init() and the increment made by the TCP socket for which the connection is timing out. The refcount made by the socket is never released. The refcount of the dst is decremented in sk_dst_reset() but that decrement is counteracted by a dst_hold() intentionally placed just before the sk_dst_reset() in ip6_negative_advice(). After ip6_negative_advice() has finished, there is no other object tied to the dst. The socket lost its reference stored in sk_dst_cache and the dst is no longer in the exception table. The exception dst becomes a leaked object.
As a result of this dst leak, an unbalanced refcount is reported for the loopback device of a net namespace being destroyed under kernels that do not contain e5f80fcf869a ("ipv6: give an IPv6 dev to blackhole_netdev"): unregister_netdevice: waiting for lo to become free. Usage count = 2
Fix the dst leak by removing the dst_hold() in ip6_negative_advice(). The patch that introduced the dst_hold() in ip6_negative_advice() was 92f1655aa2b22 ("net: fix __dst_negative_advice() race"). But 92f1655aa2b22 merely refactored the code with regards to the dst refcount so the issue was present even before 92f1655aa2b22. The bug was introduced in 54c1a859efd9f ("ipv6: Don't drop cache route entry unless timer actually expired.") where the expired cached route is deleted and the sk_dst_cache member of the socket is set to NULL by calling dst_negative_advice() but the refcount belonging to the socket is left unbalanced.
The IPv4 version - ipv4_negative_advice() - is not affected by this bug. When the TCP connection times out ipv4_negative_advice() merely resets the sk_dst_cache of the socket while decrementing the refcount of the exception dst.(CVE-2024-56644)
In the Linux kernel, the following vulnerability has been resolved:
can: j1939: j1939_session_new(): fix skb reference counting
Since j1939_session_skb_queue() does an extra skb_get() for each new skb, do the same for the initial one in j1939_session_new() to avoid refcount underflow.
In the Linux kernel, the following vulnerability has been resolved:
netfilter: x_tables: fix LED ID check in led_tg_check()
Syzbot has reported the following BUG detected by KASAN:
BUG: KASAN: slab-out-of-bounds in strlen+0x58/0x70 Read of size 1 at addr ffff8881022da0c8 by task repro/5879 ... Call Trace: <TASK> dump_stack_lvl+0x241/0x360 ? __pfx_dump_stack_lvl+0x10/0x10 ? __pfx__printk+0x10/0x10 ? _printk+0xd5/0x120 ? __virt_addr_valid+0x183/0x530 ? __virt_addr_valid+0x183/0x530 print_report+0x169/0x550 ? __virt_addr_valid+0x183/0x530 ? __virt_addr_valid+0x183/0x530 ? __virt_addr_valid+0x45f/0x530 ? __phys_addr+0xba/0x170 ? strlen+0x58/0x70 kasan_report+0x143/0x180 ? strlen+0x58/0x70 strlen+0x58/0x70 kstrdup+0x20/0x80 led_tg_check+0x18b/0x3c0 xt_check_target+0x3bb/0xa40 ? __pfx_xt_check_target+0x10/0x10 ? stack_depot_save_flags+0x6e4/0x830 ? nft_target_init+0x174/0xc30 nft_target_init+0x82d/0xc30 ? __pfx_nft_target_init+0x10/0x10 ? nf_tables_newrule+0x1609/0x2980 ? nf_tables_newrule+0x1609/0x2980 ? rcu_is_watching+0x15/0xb0 ? nf_tables_newrule+0x1609/0x2980 ? nf_tables_newrule+0x1609/0x2980 ? __kmalloc_noprof+0x21a/0x400 nf_tables_newrule+0x1860/0x2980 ? __pfx_nf_tables_newrule+0x10/0x10 ? __nla_parse+0x40/0x60 nfnetlink_rcv+0x14e5/0x2ab0 ? __pfx_validate_chain+0x10/0x10 ? __pfx_nfnetlink_rcv+0x10/0x10 ? __lock_acquire+0x1384/0x2050 ? netlink_deliver_tap+0x2e/0x1b0 ? __pfx_lock_release+0x10/0x10 ? netlink_deliver_tap+0x2e/0x1b0 netlink_unicast+0x7f8/0x990 ? __pfx_netlink_unicast+0x10/0x10 ? __virt_addr_valid+0x183/0x530 ? __check_object_size+0x48e/0x900 netlink_sendmsg+0x8e4/0xcb0 ? __pfx_netlink_sendmsg+0x10/0x10 ? aa_sock_msg_perm+0x91/0x160 ? __pfx_netlink_sendmsg+0x10/0x10 __sock_sendmsg+0x223/0x270 _syssendmsg+0x52a/0x7e0 ? pfx_sys_sendmsg+0x10/0x10 sys_sendmsg+0x292/0x380 ? __pfxsyssendmsg+0x10/0x10 ? lockdep_hardirqs_on_prepare+0x43d/0x780 ? pfx_lockdep_hardirqs_on_prepare+0x10/0x10 ? exc_page_fault+0x590/0x8c0 ? do_syscall_64+0xb6/0x230 do_syscall_64+0xf3/0x230 entry_SYSCALL_64_after_hwframe+0x77/0x7f ... </TASK>
Since an invalid (without '\0' byte at all) byte sequence may be passed from userspace, add an extra check to ensure that such a sequence is rejected as possible ID and so never passed to 'kstrdup()' and further.(CVE-2024-56650)
In the Linux kernel, the following vulnerability has been resolved:
can: hi311x: hi3110_can_ist(): fix potential use-after-free
The commit a22bd630cfff ("can: hi311x: do not report txerr and rxerr during bus-off") removed the reporting of rxerr and txerr even in case of correct operation (i. e. not bus-off).
The error count information added to the CAN frame after netif_rx() is a potential use after free, since there is no guarantee that the skb is in the same state. It might be freed or reused.
Fix the issue by postponing the netif_rx() call in case of txerr and rxerr reporting.(CVE-2024-56651)
In the Linux kernel, the following vulnerability has been resolved:
powerpc/mm/fault: Fix kfence page fault reporting
copy_from_kernel_nofault() can be called when doing read of /proc/kcore. /proc/kcore can have some unmapped kfence objects which when read via copy_from_kernel_nofault() can cause page faults. Since *_nofault() functions define their own fixup table for handling fault, use that instead of asking kfence to handle such faults.
Hence we search the exception tables for the nip which generated the fault. If there is an entry then we let the fixup table handler handle the page fault by returning an error from within ___do_page_fault().
This can be easily triggered if someone tries to do dd from /proc/kcore. eg. dd if=/proc/kcore of=/dev/null bs=1M
Some example false negatives:
=============================== BUG: KFENCE: invalid read in copy_from_kernel_nofault+0x9c/0x1a0 Invalid read at 0xc0000000fdff0000: copy_from_kernel_nofault+0x9c/0x1a0 0xc00000000665f950 read_kcore_iter+0x57c/0xa04 proc_reg_read_iter+0xe4/0x16c vfs_read+0x320/0x3ec ksys_read+0x90/0x154 system_call_exception+0x120/0x310 system_call_vectored_common+0x15c/0x2ec
BUG: KFENCE: use-after-free read in copy_from_kernel_nofault+0x9c/0x1a0 Use-after-free read at 0xc0000000fe050000 (in kfence-#2): copy_from_kernel_nofault+0x9c/0x1a0 0xc00000000665f950 read_kcore_iter+0x57c/0xa04 proc_reg_read_iter+0xe4/0x16c vfs_read+0x320/0x3ec ksys_read+0x90/0x154 system_call_exception+0x120/0x310 system_call_vectored_common+0x15c/0x2ec(CVE-2024-56678)
In the Linux kernel, the following vulnerability has been resolved:
PCI: endpoint: epf-mhi: Avoid NULL dereference if DT lacks 'mmio'
If platform_get_resource_byname() fails and returns NULL because DT lacks an 'mmio' property for the MHI endpoint, dereferencing res->start will cause a NULL pointer access. Add a check to prevent it.
[kwilczynski: error message update per the review feedback] bhelgaas: commit log
In the Linux kernel, the following vulnerability has been resolved:
9p/xen: fix release of IRQ
Kernel logs indicate an IRQ was double-freed.
Pass correct device ID during IRQ release.
Dominique: remove confusing variable reset to 0
In the Linux kernel, the following vulnerability has been resolved:
octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_dmac_flt.c
Add error pointer checks after calling otx2_mbox_get_rsp().(CVE-2024-56707)
In the Linux kernel, the following vulnerability has been resolved:
mfd: intel_soc_pmic_bxtwc: Use IRQ domain for PMIC devices
While design wise the idea of converting the driver to use the hierarchy of the IRQ chips is correct, the implementation has (inherited) flaws. This was unveiled when platform_get_irq() had started WARN() on IRQ 0 that is supposed to be a Linux IRQ number (also known as vIRQ).
Rework the driver to respect IRQ domain when creating each MFD device separately, as the domain is not the same for all of them.(CVE-2024-56723)
In the Linux kernel, the following vulnerability has been resolved:
mfd: intel_soc_pmic_bxtwc: Use IRQ domain for TMU device
While design wise the idea of converting the driver to use the hierarchy of the IRQ chips is correct, the implementation has (inherited) flaws. This was unveiled when platform_get_irq() had started WARN() on IRQ 0 that is supposed to be a Linux IRQ number (also known as vIRQ).
Rework the driver to respect IRQ domain when creating each MFD device separately, as the domain is not the same for all of them.(CVE-2024-56724)
In the Linux kernel, the following vulnerability has been resolved:
octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_dcbnl.c
Add error pointer check after calling otx2_mbox_get_rsp().(CVE-2024-56725)
In the Linux kernel, the following vulnerability has been resolved:
octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_flows.c
Adding error pointer check after calling otx2_mbox_get_rsp().(CVE-2024-56727)
In the Linux kernel, the following vulnerability has been resolved:
fbdev: sh7760fb: Fix a possible memory leak in sh7760fb_alloc_mem()
When information such as info->screen_base is not ready, calling sh7760fb_free_mem() does not release memory correctly. Call dma_free_coherent() instead.(CVE-2024-56746)
In the Linux kernel, the following vulnerability has been resolved:
ipv6: release nexthop on device removal
The CI is hitting some aperiodic hangup at device removal time in the pmtu.sh self-test:
unregister_netdevice: waiting for veth_A-R1 to become free. Usage count = 6 ref_tracker: veth_A-R1@ffff888013df15d8 has 1/5 users at dst_init+0x84/0x4a0 dst_alloc+0x97/0x150 ip6_dst_alloc+0x23/0x90 ip6_rt_pcpu_alloc+0x1e6/0x520 ip6_pol_route+0x56f/0x840 fib6_rule_lookup+0x334/0x630 ip6_route_output_flags+0x259/0x480 ip6_dst_lookup_tail.constprop.0+0x5c2/0x940 ip6_dst_lookup_flow+0x88/0x190 udp_tunnel6_dst_lookup+0x2a7/0x4c0 vxlan_xmit_one+0xbde/0x4a50 [vxlan] vxlan_xmit+0x9ad/0xf20 [vxlan] dev_hard_start_xmit+0x10e/0x360 __dev_queue_xmit+0xf95/0x18c0 arp_solicit+0x4a2/0xe00 neigh_probe+0xaa/0xf0
While the first suspect is the dst_cache, explicitly tracking the dst owing the last device reference via probes proved such dst is held by the nexthop in the originating fib6_info.
Similar to commit f5b51fe804ec ("ipv6: route: purge exception on removal"), we need to explicitly release the originating fib info when disconnecting a to-be-removed device from a live ipv6 dst: move the fib6_info cleanup into ip6_dst_ifdown().
Tested running:
./pmtu.sh cleanup_ipv6_exception
in a tight loop for more than 400 iterations with no spat, running an unpatched kernel I observed a splat every ~10 iterations.(CVE-2024-56751)
In the Linux kernel, the following vulnerability has been resolved:
crypto: caam - Fix the pointer passed to caam_qi_shutdown()
The type of the last parameter given to devm_add_action_or_reset() is "struct caam_drv_private ", but in caam_qi_shutdown(), it is casted to "struct device ".
Pass the correct parameter to devm_add_action_or_reset() so that the resources are released as expected.(CVE-2024-56754)
In the Linux kernel, the following vulnerability has been resolved:
btrfs: add a sanity check for btrfs root in btrfs_search_slot()
Syzbot reports a null-ptr-deref in btrfs_search_slot().
The reproducer is using rescue=ibadroots, and the extent tree root is corrupted thus the extent tree is NULL.
When scrub tries to search the extent tree to gather the needed extent info, btrfs_search_slot() doesn't check if the target root is NULL or not, resulting the null-ptr-deref.
Add sanity check for btrfs root before using it in btrfs_search_slot().(CVE-2024-56774)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nft_socket: remove WARN_ON_ONCE on maximum cgroup level
cgroup maximum depth is INT_MAX by default, there is a cgroup toggle to restrict this maximum depth to a more reasonable value not to harm performance. Remove unnecessary WARN_ON_ONCE which is reachable from userspace.(CVE-2024-56783)
In the Linux kernel, the following vulnerability has been resolved:
MIPS: Loongson64: DTS: Really fix PCIe port nodes for ls7a
Fix the dtc warnings:
arch/mips/boot/dts/loongson/ls7a-pch.dtsi:68.16-416.5: Warning (interrupt_provider): /bus@10000000/pci@1a000000: '#interrupt-cells' found, but node is not an interrupt provider
arch/mips/boot/dts/loongson/ls7a-pch.dtsi:68.16-416.5: Warning (interrupt_provider): /bus@10000000/pci@1a000000: '#interrupt-cells' found, but node is not an interrupt provider
arch/mips/boot/dts/loongson/loongson64g_4core_ls7a.dtb: Warning (interrupt_map): Failed prerequisite 'interrupt_provider'
And a runtime warning introduced in commit 045b14ca5c36 ("of: WARN on deprecated #address-cells/#size-cells handling"):
WARNING: CPU: 0 PID: 1 at drivers/of/base.c:106 of_bus_n_addr_cells+0x9c/0xe0
Missing '#address-cells' in /bus@10000000/pci@1a000000/pci_bridge@9,0
The fix is similar to commit d89a415ff8d5 ("MIPS: Loongson64: DTS: Fix PCIe port nodes for ls7a"), which has fixed the issue for ls2k (despite its subject mentions ls7a).(CVE-2024-56785)
In the Linux kernel, the following vulnerability has been resolved:
s390/entry: Mark IRQ entries to fix stack depot warnings
The stack depot filters out everything outside of the top interrupt context as an uninteresting or irrelevant part of the stack traces. This helps with stack trace de-duplication, avoiding an explosion of saved stack traces that share the same IRQ context code path but originate from different randomly interrupted points, eventually exhausting the stack depot.
Filtering uses in_irqentry_text() to identify functions within the .irqentry.text and .softirqentry.text sections, which then become the last stack trace entries being saved.
While __do_softirq() is placed into the .softirqentry.text section by common code, populating .irqentry.text is architecture-specific.
Currently, the .irqentry.text section on s390 is empty, which prevents stack depot filtering and de-duplication and could result in warnings like:
Stack depot reached limit capacity WARNING: CPU: 0 PID: 286113 at lib/stackdepot.c:252 depot_alloc_stack+0x39a/0x3c8
with PREEMPT and KASAN enabled.
Fix this by moving the IO/EXT interrupt handlers from .kprobes.text into the .irqentry.text section and updating the kprobes blacklist to include the .irqentry.text section.
This is done only for asynchronous interrupts and explicitly not for program checks, which are synchronous and where the context beyond the program check is important to preserve. Despite machine checks being somewhat in between, they are extremely rare, and preserving context when possible is also of value.
SVCs and Restart Interrupts are not relevant, one being always at the boundary to user space and the other being a one-time thing.
IRQ entries filtering is also optionally used in ftrace function graph, where the same logic applies.(CVE-2024-57838)
In the Linux kernel, the following vulnerability has been resolved:
drm/dp_mst: Fix resetting msg rx state after topology removal
If the MST topology is removed during the reception of an MST down reply or MST up request sideband message, the drm_dp_mst_topology_mgr::up_req_recv/down_rep_recv states could be reset from one thread via drm_dp_mst_topology_mgr_set_mst(false), racing with the reading/parsing of the message from another thread via drm_dp_mst_handle_down_rep() or drm_dp_mst_handle_up_req(). The race is possible since the reader/parser doesn't hold any lock while accessing the reception state. This in turn can lead to a memory corruption in the reader/parser as described by commit bd2fccac61b4 ("drm/dp_mst: Fix MST sideband message body length check").
Fix the above by resetting the message reception state if needed before reading/parsing a message. Another solution would be to hold the drm_dp_mst_topology_mgr::lock for the whole duration of the message reception/parsing in drm_dp_mst_handle_down_rep() and drm_dp_mst_handle_up_req(), however this would require a bigger change. Since the fix is also needed for stable, opting for the simpler solution in this patch.(CVE-2024-57876)
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: fix mbss changed flags corruption on 32 bit systems
On 32-bit systems, the size of an unsigned long is 4 bytes, while a u64 is 8 bytes. Therefore, when using or_each_set_bit(bit, &bits, sizeof(changed) * BITS_PER_BYTE), the code is incorrectly searching for a bit in a 32-bit variable that is expected to be 64 bits in size, leading to incorrect bit finding.
Solution: Ensure that the size of the bits variable is correctly adjusted for each architecture.
Call Trace: ? show_regs+0x54/0x58 ? __warn+0x6b/0xd4 ? ieee80211_link_info_change_notify+0xcc/0xd4 [mac80211] ? report_bug+0x113/0x150 ? exc_overflow+0x30/0x30 ? handle_bug+0x27/0x44 ? exc_invalid_op+0x18/0x50 ? handle_exception+0xf6/0xf6 ? exc_overflow+0x30/0x30 ? ieee80211_link_info_change_notify+0xcc/0xd4 [mac80211] ? exc_overflow+0x30/0x30 ? ieee80211_link_info_change_notify+0xcc/0xd4 [mac80211] ? ieee80211_mesh_work+0xff/0x260 [mac80211] ? cfg80211_wiphy_work+0x72/0x98 [cfg80211] ? process_one_work+0xf1/0x1fc ? worker_thread+0x2c0/0x3b4 ? kthread+0xc7/0xf0 ? mod_delayed_work_on+0x4c/0x4c ? kthread_complete_and_exit+0x14/0x14 ? ret_from_fork+0x24/0x38 ? kthread_complete_and_exit+0x14/0x14 ? ret_from_fork_asm+0xf/0x14 ? entry_INT80_32+0xf0/0xf0
restore no-op path for no changes
In the Linux kernel, the following vulnerability has been resolved:
usb: xhci: Fix NULL pointer dereference on certain command aborts
If a command is queued to the final usable TRB of a ring segment, the enqueue pointer is advanced to the subsequent link TRB and no further. If the command is later aborted, when the abort completion is handled the dequeue pointer is advanced to the first TRB of the next segment.
If no further commands are queued, xhci_handle_stopped_cmd_ring() sees the ring pointers unequal and assumes that there is a pending command, so it calls xhci_mod_cmd_timer() which crashes if cur_cmd was NULL.
Don't attempt timer setup if cur_cmd is NULL. The subsequent doorbell ring likely is unnecessary too, but it's harmless. Leave it alone.
This is probably Bug 219532, but no confirmation has been received.
The issue has been independently reproduced and confirmed fixed using a USB MCU programmed to NAK the Status stage of SET_ADDRESS forever. Everything continued working normally after several prevented crashes.(CVE-2024-57981)
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: handle a symlink read error correctly
Patch series "Convert ocfs2 to use folios".
Mark did a conversion of ocfs2 to use folios and sent it to me as a giant patch for review ;-)
So I've redone it as individual patches, and credited Mark for the patches where his code is substantially the same. It's not a bad way to do it; his patch had some bugs and my patches had some bugs. Hopefully all our bugs were different from each other. And hopefully Mark likes all the changes I made to his code!
This patch (of 23):
If we can't read the buffer, be sure to unlock the page before returning.(CVE-2024-58001)
In the Linux kernel, the following vulnerability has been resolved:
bpf: bpf_local_storage: Always use bpf_mem_alloc in PREEMPT_RT
In PREEMPT_RT, kmalloc(GFP_ATOMIC) is still not safe in non preemptible context. bpf_mem_alloc must be used in PREEMPT_RT. This patch is to enforce bpf_mem_alloc in the bpf_local_storage when CONFIG_PREEMPT_RT is enabled.
[ 35.118559] BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 [ 35.118566] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1832, name: test_progs [ 35.118569] preempt_count: 1, expected: 0 [ 35.118571] RCU nest depth: 1, expected: 1 [ 35.118577] INFO: lockdep is turned off. ... [ 35.118647] __might_resched+0x433/0x5b0 [ 35.118677] rt_spin_lock+0xc3/0x290 [ 35.118700] slaballoc+0x72/0xc40 [ 35.118723] kmalloc_noprof+0x13f/0x4e0 [ 35.118732] bpf_map_kzalloc+0xe5/0x220 [ 35.118740] bpf_selem_alloc+0x1d2/0x7b0 [ 35.118755] bpf_local_storage_update+0x2fa/0x8b0 [ 35.118784] bpf_sk_storage_get_tracing+0x15a/0x1d0 [ 35.118791] bpf_prog_9a118d86fca78ebb_trace_inet_sock_set_state+0x44/0x66 [ 35.118795] bpf_trace_run3+0x222/0x400 [ 35.118820] __bpf_trace_inet_sock_set_state+0x11/0x20 [ 35.118824] trace_inet_sock_set_state+0x112/0x130 [ 35.118830] inet_sk_state_store+0x41/0x90 [ 35.118836] tcp_set_state+0x3b3/0x640
There is no need to adjust the gfp_flags passing to the bpf_mem_cache_alloc_flags() which only honors the GFP_KERNEL. The verifier has ensured GFP_KERNEL is passed only in sleepable context.
It has been an old issue since the first introduction of the bpf_local_storage ~5 years ago, so this patch targets the bpf-next.
bpf_mem_alloc is needed to solve it, so the Fixes tag is set to the commit when bpf_mem_alloc was first used in the bpf_local_storage.(CVE-2024-58070)
In the Linux kernel, the following vulnerability has been resolved:
wifi: rtw89: fix race between cancel_hw_scan and hw_scan completion
The rtwdev->scanning flag isn't protected by mutex originally, so cancel_hw_scan can pass the condition, but suddenly hw_scan completion unset the flag and calls ieee80211_scan_completed() that will free local->hw_scan_req. Then, cancel_hw_scan raises null-ptr-deref and use-after-free. Fix it by moving the check condition to where protected by mutex.
KASAN: null-ptr-deref in range [0x0000000000000088-0x000000000000008f] CPU: 2 PID: 6922 Comm: kworker/2:2 Tainted: G OE Hardware name: LENOVO 2356AD1/2356AD1, BIOS G7ETB6WW (2.76 ) 09/10/2019 Workqueue: events cfg80211_conn_work [cfg80211] RIP: 0010:rtw89_fw_h2c_scan_offload_be+0xc33/0x13c3 [rtw89_core] Code: 00 45 89 6c 24 1c 0f 85 23 01 00 00 48 8b 85 20 ff ff ff 48 8d RSP: 0018:ffff88811fd9f068 EFLAGS: 00010206 RAX: dffffc0000000000 RBX: ffff88811fd9f258 RCX: 0000000000000001 RDX: 0000000000000011 RSI: 0000000000000001 RDI: 0000000000000089 RBP: ffff88811fd9f170 R08: 0000000000000000 R09: 0000000000000000 R10: ffff88811fd9f108 R11: 0000000000000000 R12: ffff88810e47f960 R13: 0000000000000000 R14: 000000000000ffff R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff8881d6f00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007531dfca55b0 CR3: 00000001be296004 CR4: 00000000001706e0 Call Trace: <TASK> ? show_regs+0x61/0x73 ? __die_body+0x20/0x73 ? die_addr+0x4f/0x7b ? exc_general_protection+0x191/0x1db ? asm_exc_general_protection+0x27/0x30 ? rtw89_fw_h2c_scan_offload_be+0xc33/0x13c3 [rtw89_core] ? rtw89_fw_h2c_scan_offload_be+0x458/0x13c3 [rtw89_core] ? __pfx_rtw89_fw_h2c_scan_offload_be+0x10/0x10 [rtw89_core] ? do_raw_spin_lock+0x75/0xdb ? __pfx_do_raw_spin_lock+0x10/0x10 rtw89_hw_scan_offload+0xb5e/0xbf7 [rtw89_core] ? _raw_spin_unlock+0xe/0x24 ? __mutex_lock.constprop.0+0x40c/0x471 ? __pfx_rtw89_hw_scan_offload+0x10/0x10 [rtw89_core] ? __mutex_lock_slowpath+0x13/0x1f ? mutex_lock+0xa2/0xdc ? __pfx_mutex_lock+0x10/0x10 rtw89_hw_scan_abort+0x58/0xb7 [rtw89_core] rtw89_ops_cancel_hw_scan+0x120/0x13b [rtw89_core] ieee80211_scan_cancel+0x468/0x4d0 [mac80211] ieee80211_prep_connection+0x858/0x899 [mac80211] ieee80211_mgd_auth+0xbea/0xdde [mac80211] ? __pfx_ieee80211_mgd_auth+0x10/0x10 [mac80211] ? cfg80211_find_elem+0x15/0x29 [cfg80211] ? is_bss+0x1b7/0x1d7 [cfg80211] ieee80211_auth+0x18/0x27 [mac80211] cfg80211_mlme_auth+0x3bb/0x3e7 [cfg80211] cfg80211_conn_do_work+0x410/0xb81 [cfg80211] ? __pfx_cfg80211_conn_do_work+0x10/0x10 [cfg80211] ? __kasan_check_read+0x11/0x1f ? psi_group_change+0x8bc/0x944 ? __kasan_check_write+0x14/0x22 ? mutex_lock+0x8e/0xdc ? __pfx_mutex_lock+0x10/0x10 ? __pfxradixtree_lookup+0x10/0x10 cfg80211_conn_work+0x245/0x34d [cfg80211] ? pfx_cfg80211_conn_work+0x10/0x10 [cfg80211] ? update_cfs_rq_load_avg+0x3bc/0x3d7 ? sched_clock_noinstr+0x9/0x1a ? sched_clock+0x10/0x24 ? sched_clock_cpu+0x7e/0x42e ? newidle_balance+0x796/0x937 ? __pfx_sched_clock_cpu+0x10/0x10 ? __pfx_newidle_balance+0x10/0x10 ? __kasan_check_read+0x11/0x1f ? psi_group_change+0x8bc/0x944 ? _raw_spin_unlock+0xe/0x24 ? raw_spin_rq_unlock+0x47/0x54 ? raw_spin_rq_unlock_irq+0x9/0x1f ? finish_task_switch.isra.0+0x347/0x586 ? __schedule+0x27bf/0x2892 ? mutex_unlock+0x80/0xd0 ? do_raw_spin_lock+0x75/0xdb ? __pfxschedule+0x10/0x10 processscheduled_works+0x58c/0x821 worker_thread+0x4c7/0x586 ? kasan_check_read+0x11/0x1f kthread+0x285/0x294 ? __pfx_worker_thread+0x10/0x10 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x29/0x6f ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 </TASK>(CVE-2025-21729)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/mlx5: Fix a race for an ODP MR which leads to CQE with error
This patch addresses a race condition for an ODP MR that can result in a CQE with an error on the UMR QP.
During the __mlx5_ib_dereg_mr() flow, the following sequence of calls occurs:
mlx5_revoke_mr() mlx5r_umr_revoke_mr() mlx5r_umr_post_send_wait()
At this point, the lkey is freed from the hardware's perspective.
However, concurrently, mlx5_ib_invalidate_range() might be triggered by another task attempting to invalidate a range for the same freed lkey.
This task will: - Acquire the umem_odp->umem_mutex lock. - Call mlx5r_umr_update_xlt() on the UMR QP. - Since the lkey has already been freed, this can lead to a CQE error, causing the UMR QP to enter an error state [1].
To resolve this race condition, the umem_odp->umem_mutex lock is now also acquired as part of the mlx5_revoke_mr() scope. Upon successful revoke, we set umem_odp->private which points to that MR to NULL, preventing any further invalidation attempts on its lkey.
[1] From dmesg:
infiniband rocep8s0f0: dump_cqe:277:(pid 0): WC error: 6, Message: memory bind operation error cqe_dump: 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 cqe_dump: 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 cqe_dump: 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 cqe_dump: 00000030: 00 00 00 00 08 00 78 06 25 00 11 b9 00 0e dd d2
WARNING: CPU: 15 PID: 1506 at drivers/infiniband/hw/mlx5/umr.c:394 mlx5r_umr_post_send_wait+0x15a/0x2b0 [mlx5_ib] Modules linked in: ip6table_mangle ip6table_natip6table_filter ip6_tables iptable_mangle xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry overlay rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_umad ib_ipoib ib_cm mlx5_ib ib_uverbs ib_core fuse mlx5_core CPU: 15 UID: 0 PID: 1506 Comm: ibv_rc_pingpong Not tainted 6.12.0-rc7+ #1626 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:mlx5r_umr_post_send_wait+0x15a/0x2b0 [mlx5_ib] [..] Call Trace: <TASK> mlx5r_umr_update_xlt+0x23c/0x3e0 [mlx5_ib] mlx5_ib_invalidate_range+0x2e1/0x330 [mlx5_ib] __mmu_notifier_invalidate_range_start+0x1e1/0x240 zap_page_range_single+0xf1/0x1a0 madvise_vma_behavior+0x677/0x6e0 do_madvise+0x1a2/0x4b0 __x64_sys_madvise+0x25/0x30 do_syscall_64+0x6b/0x140 entry_SYSCALL_64_after_hwframe+0x76/0x7e(CVE-2025-21732)
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix possible int overflows in nilfs_fiemap()
Since nilfs_bmap_lookup_contig() in nilfs_fiemap() calculates its result by being prepared to go through potentially maxblocks == INT_MAX blocks, the value in n may experience an overflow caused by left shift of blkbits.
While it is extremely unlikely to occur, play it safe and cast right hand expression to wider type to mitigate the issue.
Found by Linux Verification Center (linuxtesting.org) with static analysis tool SVACE.(CVE-2025-21736)
In the Linux kernel, the following vulnerability has been resolved:
usbnet: ipheth: fix possible overflow in DPE length check
Originally, it was possible for the DPE length check to overflow if wDatagramIndex + wDatagramLength > U16_MAX. This could lead to an OoB read.
Move the wDatagramIndex term to the other side of the inequality.
An existing condition ensures that wDatagramIndex < urb->actual_length.(CVE-2025-21743)
In the Linux kernel, the following vulnerability has been resolved:
clocksource: Use migrate_disable() to avoid calling get_random_u32() in atomic context
The following bug report happened with a PREEMPT_RT kernel:
BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 2012, name: kwatchdog preempt_count: 1, expected: 0 RCU nest depth: 0, expected: 0 get_random_u32+0x4f/0x110 clocksource_verify_choose_cpus+0xab/0x1a0 clocksource_verify_percpu.part.0+0x6b/0x330 clocksource_watchdog_kthread+0x193/0x1a0
It is due to the fact that clocksource_verify_choose_cpus() is invoked with preemption disabled. This function invokes get_random_u32() to obtain random numbers for choosing CPUs. The batched_entropy_32 local lock and/or the base_crng.lock spinlock in driver/char/random.c will be acquired during the call. In PREEMPT_RT kernel, they are both sleeping locks and so cannot be acquired in atomic context.
Fix this problem by using migrate_disable() to allow smp_processor_id() to be reliably used without introducing atomic context. preempt_disable() is then called after clocksource_verify_choose_cpus() but before the clocksource measurement is being run to avoid introducing unexpected latency.(CVE-2025-21767)
In the Linux kernel, the following vulnerability has been resolved:
USB: hub: Ignore non-compliant devices with too many configs or interfaces
Robert Morris created a test program which can cause usb_hub_to_struct_hub() to dereference a NULL or inappropriate pointer:
Oops: general protection fault, probably for non-canonical address 0xcccccccccccccccc: 0000 [#1] SMP DEBUG_PAGEALLOC PTI CPU: 7 UID: 0 PID: 117 Comm: kworker/7:1 Not tainted 6.13.0-rc3-00017-gf44d154d6e3d #14 Hardware name: FreeBSD BHYVE/BHYVE, BIOS 14.0 10/17/2021 Workqueue: usb_hub_wq hub_event RIP: 0010:usb_hub_adjust_deviceremovable+0x78/0x110 ... Call Trace: <TASK> ? die_addr+0x31/0x80 ? exc_general_protection+0x1b4/0x3c0 ? asm_exc_general_protection+0x26/0x30 ? usb_hub_adjust_deviceremovable+0x78/0x110 hub_probe+0x7c7/0xab0 usb_probe_interface+0x14b/0x350 really_probe+0xd0/0x2d0 ? __pfxdeviceattach_driver+0x10/0x10 driver_probe_device+0x6e/0x110 driver_probe_device+0x1a/0x90 __device_attach_driver+0x7e/0xc0 bus_for_each_drv+0x7f/0xd0 __device_attach+0xaa/0x1a0 bus_probe_device+0x8b/0xa0 device_add+0x62e/0x810 usb_set_configuration+0x65d/0x990 usb_generic_driver_probe+0x4b/0x70 usb_probe_device+0x36/0xd0
The cause of this error is that the device has two interfaces, and the hub driver binds to interface 1 instead of interface 0, which is where usb_hub_to_struct_hub() looks.
We can prevent the problem from occurring by refusing to accept hub devices that violate the USB spec by having more than one configuration or interface.(CVE-2025-21776)
In the Linux kernel, the following vulnerability has been resolved:
orangefs: fix a oob in orangefs_debug_write
I got a syzbot report: slab-out-of-bounds Read in orangefs_debug_write... several people suggested fixes, I tested Al Viro's suggestion and made this patch.(CVE-2025-21782)
In the Linux kernel, the following vulnerability has been resolved:
gpiolib: Fix crash on error in gpiochip_get_ngpios()
The gpiochip_get_ngpios() uses chip_() macros to print messages. However these macros rely on gpiodev to be initialised and set, which is not the case when called via bgpio_init(). In such a case the printing messages will crash on NULL pointer dereference. Replace chip_() macros by the respective dev_*() ones to avoid such crash.(CVE-2025-21783)
In the Linux kernel, the following vulnerability has been resolved:
LoongArch: csum: Fix OoB access in IP checksum code for negative lengths
Commit 69e3a6aa6be2 ("LoongArch: Add checksum optimization for 64-bit system") would cause an undefined shift and an out-of-bounds read.
Commit 8bd795fedb84 ("arm64: csum: Fix OoB access in IP checksum code for negative lengths") fixes the same issue on ARM64.(CVE-2025-21789)
In the Linux kernel, the following vulnerability has been resolved:
NFSD: fix hang in nfsd4_shutdown_callback
If nfs4_client is in courtesy state then there is no point to send the callback. This causes nfsd4_shutdown_callback to hang since cl_cb_inflight is not 0. This hang lasts about 15 minutes until TCP notifies NFSD that the connection was dropped.
This patch modifies nfsd4_run_cb_work to skip the RPC call if nfs4_client is in courtesy state.(CVE-2025-21795)
In the Linux kernel, the following vulnerability has been resolved:
nfsd: clear acl_access/acl_default after releasing them
If getting acl_default fails, acl_access and acl_default will be released simultaneously. However, acl_access will still retain a pointer pointing to the released posix_acl, which will trigger a WARNING in nfs3svc_release_getacl like this:
------------[ cut here ]------------ refcount_t: underflow; use-after-free. WARNING: CPU: 26 PID: 3199 at lib/refcount.c:28 refcount_warn_saturate+0xb5/0x170 Modules linked in: CPU: 26 UID: 0 PID: 3199 Comm: nfsd Not tainted 6.12.0-rc6-00079-g04ae226af01f-dirty #8 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 RIP: 0010:refcount_warn_saturate+0xb5/0x170 Code: cc cc 0f b6 1d b3 20 a5 03 80 fb 01 0f 87 65 48 d8 00 83 e3 01 75 e4 48 c7 c7 c0 3b 9b 85 c6 05 97 20 a5 03 01 e8 fb 3e 30 ff <0f> 0b eb cd 0f b6 1d 8a3 RSP: 0018:ffffc90008637cd8 EFLAGS: 00010282 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff83904fde RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff88871ed36380 RBP: ffff888158beeb40 R08: 0000000000000001 R09: fffff520010c6f56 R10: ffffc90008637ab7 R11: 0000000000000001 R12: 0000000000000001 R13: ffff888140e77400 R14: ffff888140e77408 R15: ffffffff858b42c0 FS: 0000000000000000(0000) GS:ffff88871ed00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000562384d32158 CR3: 000000055cc6a000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? refcount_warn_saturate+0xb5/0x170 ? __warn+0xa5/0x140 ? refcount_warn_saturate+0xb5/0x170 ? report_bug+0x1b1/0x1e0 ? handle_bug+0x53/0xa0 ? exc_invalid_op+0x17/0x40 ? asm_exc_invalid_op+0x1a/0x20 ? tick_nohz_tick_stopped+0x1e/0x40 ? refcount_warn_saturate+0xb5/0x170 ? refcount_warn_saturate+0xb5/0x170 nfs3svc_release_getacl+0xc9/0xe0 svc_process_common+0x5db/0xb60 ? __pfx_svc_process_common+0x10/0x10 ? __rcu_read_unlock+0x69/0xa0 ? __pfx_nfsd_dispatch+0x10/0x10 ? svc_xprt_received+0xa1/0x120 ? xdr_init_decode+0x11d/0x190 svc_process+0x2a7/0x330 svc_handle_xprt+0x69d/0x940 svc_recv+0x180/0x2d0 nfsd+0x168/0x200 ? __pfx_nfsd+0x10/0x10 kthread+0x1a2/0x1e0 ? kthread+0xf4/0x1e0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x60 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> Kernel panic - not syncing: kernel: panic_on_warn set ...
Clear acl_access/acl_default after posix_acl_release is called to prevent UAF from being triggered.(CVE-2025-21796)
In the Linux kernel, the following vulnerability has been resolved:
ptp: Ensure info->enable callback is always set
The ioctl and sysfs handlers unconditionally call the ->enable callback. Not all drivers implement that callback, leading to NULL dereferences. Example of affected drivers: ptp_s390.c, ptp_vclock.c and ptp_mock.c.
Instead use a dummy callback if no better was specified by the driver.(CVE-2025-21814)
In the Linux kernel, the following vulnerability has been resolved:
block: mark GFP_NOIO around sysfs ->store()
sysfs ->store is called with queue freezed, meantime we have several ->store() callbacks(update_nr_requests, wbt, scheduler) to allocate memory with GFP_KERNEL which may run into direct reclaim code path, then potential deadlock can be caused.
Fix the issue by marking NOIO around sysfs ->store()(CVE-2025-21817)
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-6.6.0-82.0.0.86.oe2403sp1.aarch64.rpm",
"bpftool-debuginfo-6.6.0-82.0.0.86.oe2403sp1.aarch64.rpm",
"kernel-6.6.0-82.0.0.86.oe2403sp1.aarch64.rpm",
"kernel-debuginfo-6.6.0-82.0.0.86.oe2403sp1.aarch64.rpm",
"kernel-debugsource-6.6.0-82.0.0.86.oe2403sp1.aarch64.rpm",
"kernel-devel-6.6.0-82.0.0.86.oe2403sp1.aarch64.rpm",
"kernel-headers-6.6.0-82.0.0.86.oe2403sp1.aarch64.rpm",
"kernel-source-6.6.0-82.0.0.86.oe2403sp1.aarch64.rpm",
"kernel-tools-6.6.0-82.0.0.86.oe2403sp1.aarch64.rpm",
"kernel-tools-debuginfo-6.6.0-82.0.0.86.oe2403sp1.aarch64.rpm",
"kernel-tools-devel-6.6.0-82.0.0.86.oe2403sp1.aarch64.rpm",
"perf-6.6.0-82.0.0.86.oe2403sp1.aarch64.rpm",
"perf-debuginfo-6.6.0-82.0.0.86.oe2403sp1.aarch64.rpm",
"python3-perf-6.6.0-82.0.0.86.oe2403sp1.aarch64.rpm",
"python3-perf-debuginfo-6.6.0-82.0.0.86.oe2403sp1.aarch64.rpm"
],
"src": [
"kernel-6.6.0-82.0.0.86.oe2403sp1.src.rpm"
],
"x86_64": [
"bpftool-6.6.0-82.0.0.86.oe2403sp1.x86_64.rpm",
"bpftool-debuginfo-6.6.0-82.0.0.86.oe2403sp1.x86_64.rpm",
"kernel-6.6.0-82.0.0.86.oe2403sp1.x86_64.rpm",
"kernel-debuginfo-6.6.0-82.0.0.86.oe2403sp1.x86_64.rpm",
"kernel-debugsource-6.6.0-82.0.0.86.oe2403sp1.x86_64.rpm",
"kernel-devel-6.6.0-82.0.0.86.oe2403sp1.x86_64.rpm",
"kernel-headers-6.6.0-82.0.0.86.oe2403sp1.x86_64.rpm",
"kernel-source-6.6.0-82.0.0.86.oe2403sp1.x86_64.rpm",
"kernel-tools-6.6.0-82.0.0.86.oe2403sp1.x86_64.rpm",
"kernel-tools-debuginfo-6.6.0-82.0.0.86.oe2403sp1.x86_64.rpm",
"kernel-tools-devel-6.6.0-82.0.0.86.oe2403sp1.x86_64.rpm",
"perf-6.6.0-82.0.0.86.oe2403sp1.x86_64.rpm",
"perf-debuginfo-6.6.0-82.0.0.86.oe2403sp1.x86_64.rpm",
"python3-perf-6.6.0-82.0.0.86.oe2403sp1.x86_64.rpm",
"python3-perf-debuginfo-6.6.0-82.0.0.86.oe2403sp1.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:24.03-LTS-SP1",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS-SP1"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.6.0-82.0.0.86.oe2403sp1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nIORING_OP_READ did not correctly consume the provided buffer list when\nread i/o returned \u0026lt; 0 (except for -EAGAIN and -EIOCBQUEUED return).\nThis can lead to a potential use-after-free when the completion via\nio_rw_done runs at separate context.(CVE-2023-52926)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: fix to shrink read extent node in batches\n\nWe use rwlock to protect core structure data of extent tree during\nits shrink, however, if there is a huge number of extent nodes in\nextent tree, during shrink of extent tree, it may hold rwlock for\na very long time, which may trigger kernel hang issue.\n\nThis patch fixes to shrink read extent node in batches, so that,\ncritical region of the rwlock can be shrunk to avoid its extreme\nlong time hold.(CVE-2024-41935)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndma-debug: fix a possible deadlock on radix_lock\n\nradix_lock() shouldn\u0026apos;t be held while holding dma_hash_entry[idx].lock\notherwise, there\u0026apos;s a possible deadlock scenario when\ndma debug API is called holding rq_lock():\n\nCPU0 CPU1 CPU2\ndma_free_attrs()\ncheck_unmap() add_dma_entry() __schedule() //out\n (A) rq_lock()\nget_hash_bucket()\n(A) dma_entry_hash\n check_sync()\n (A) radix_lock() (W) dma_entry_hash\ndma_entry_free()\n(W) radix_lock()\n // CPU2\u0026apos;s one\n (W) rq_lock()\n\nCPU1 situation can happen when it extending radix tree and\nit tries to wake up kswapd via wake_all_kswapd().\n\nCPU2 situation can happen while perf_event_task_sched_out()\n(i.e. dma sync operation is called while deleting perf_event using\n etm and etr tmc which are Arm Coresight hwtracing driver backends).\n\nTo remove this possible situation, call dma_entry_free() after\nput_hash_bucket() in check_unmap().(CVE-2024-47143)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndlm: fix possible lkb_resource null dereference\n\nThis patch fixes a possible null pointer dereference when this function is\ncalled from request_lock() as lkb-\u0026gt;lkb_resource is not assigned yet,\nonly after validate_lock_args() by calling attach_lkb(). Another issue\nis that a resource name could be a non printable bytearray and we cannot\nassume to be ASCII coded.\n\nThe log functionality is probably never being hit when DLM is used in\nnormal way and no debug logging is enabled. The null pointer dereference\ncan only occur on a new created lkb that does not have the resource\nassigned yet, it probably never hits the null pointer dereference but we\nshould be sure that other changes might not change this behaviour and we\nactually can hit the mentioned null pointer dereference.\n\nIn this patch we just drop the printout of the resource name, the lkb id\nis enough to make a possible connection to a resource name if this\nexists.(CVE-2024-47809)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbcache: revert replacing IS_ERR_OR_NULL with IS_ERR again\n\nCommit 028ddcac477b (\u0026quot;bcache: Remove unnecessary NULL point check in\nnode allocations\u0026quot;) leads a NULL pointer deference in cache_set_flush().\n\n1721 if (!IS_ERR_OR_NULL(c-\u0026gt;root))\n1722 list_add(\u0026amp;c-\u0026gt;root-\u0026gt;list, \u0026amp;c-\u0026gt;btree_cache);\n\n\u0026gt;From the above code in cache_set_flush(), if previous registration code\nfails before allocating c-\u0026gt;root, it is possible c-\u0026gt;root is NULL as what\nit is initialized. __bch_btree_node_alloc() never returns NULL but\nc-\u0026gt;root is possible to be NULL at above line 1721.\n\nThis patch replaces IS_ERR() by IS_ERR_OR_NULL() to fix this.(CVE-2024-48881)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: ipset: add missing range check in bitmap_ip_uadt\n\nWhen tb[IPSET_ATTR_IP_TO] is not present but tb[IPSET_ATTR_CIDR] exists,\nthe values of ip and ip_to are slightly swapped. Therefore, the range check\nfor ip should be done later, but this part is missing and it seems that the\nvulnerability occurs.\n\nSo we should add missing range checks and remove unnecessary range checks.(CVE-2024-53141)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncomedi: Flush partial mappings in error case\n\nIf some remap_pfn_range() calls succeeded before one failed, we still have\nbuffer pages mapped into the userspace page tables when we drop the buffer\nreference with comedi_buf_map_put(bm). The userspace mappings are only\ncleaned up later in the mmap error path.\n\nFix it by explicitly flushing all mappings in our VMA on the error path.\n\nSee commit 79a61cc3fc04 (\u0026quot;mm: avoid leaving partial pfn mappings around in\nerror case\u0026quot;).(CVE-2024-53148)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath9k: add range check for conn_rsp_epid in htc_connect_service()\n\nI found the following bug in my fuzzer:\n\n UBSAN: array-index-out-of-bounds in drivers/net/wireless/ath/ath9k/htc_hst.c:26:51\n index 255 is out of range for type \u0026apos;htc_endpoint [22]\u0026apos;\n CPU: 0 UID: 0 PID: 8 Comm: kworker/0:0 Not tainted 6.11.0-rc6-dirty #14\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014\n Workqueue: events request_firmware_work_func\n Call Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x180/0x1b0\n __ubsan_handle_out_of_bounds+0xd4/0x130\n htc_issue_send.constprop.0+0x20c/0x230\n ? _raw_spin_unlock_irqrestore+0x3c/0x70\n ath9k_wmi_cmd+0x41d/0x610\n ? mark_held_locks+0x9f/0xe0\n ...\n\nSince this bug has been confirmed to be caused by insufficient verification\nof conn_rsp_epid, I think it would be appropriate to add a range check for\nconn_rsp_epid to htc_connect_service() to prevent the bug from occurring.(CVE-2024-53156)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: During unmount, ensure all cached dir instances drop their dentry\n\nThe unmount process (cifs_kill_sb() calling close_all_cached_dirs()) can\nrace with various cached directory operations, which ultimately results\nin dentries not being dropped and these kernel BUGs:\n\nBUG: Dentry ffff88814f37e358{i=1000000000080,n=/} still in use (2) [unmount of cifs cifs]\nVFS: Busy inodes after unmount of cifs (cifs)\n------------[ cut here ]------------\nkernel BUG at fs/super.c:661!\n\nThis happens when a cfid is in the process of being cleaned up when, and\nhas been removed from the cfids-\u0026gt;entries list, including:\n\n- Receiving a lease break from the server\n- Server reconnection triggers invalidate_all_cached_dirs(), which\n removes all the cfids from the list\n- The laundromat thread decides to expire an old cfid.\n\nTo solve these problems, dropping the dentry is done in queued work done\nin a newly-added cfid_put_wq workqueue, and close_all_cached_dirs()\nflushes that workqueue after it drops all the dentries of which it\u0026apos;s\naware. This is a global workqueue (rather than scoped to a mount), but\nthe queued work is minimal.\n\nThe final cleanup work for cleaning up a cfid is performed via work\nqueued in the serverclose_wq workqueue; this is done separate from\ndropping the dentries so that close_all_cached_dirs() doesn\u0026apos;t block on\nany server operations.\n\nBoth of these queued works expect to invoked with a cfid reference and\na tcon reference to avoid those objects from being freed while the work\nis ongoing.\n\nWhile we\u0026apos;re here, add proper locking to close_all_cached_dirs(), and\nlocking around the freeing of cfid-\u0026gt;dentry.(CVE-2024-53176)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: prevent use-after-free due to open_cached_dir error paths\n\nIf open_cached_dir() encounters an error parsing the lease from the\nserver, the error handling may race with receiving a lease break,\nresulting in open_cached_dir() freeing the cfid while the queued work is\npending.\n\nUpdate open_cached_dir() to drop refs rather than directly freeing the\ncfid.\n\nHave cached_dir_lease_break(), cfids_laundromat_worker(), and\ninvalidate_all_cached_dirs() clear has_lease immediately while still\nholding cfids-\u0026gt;cfid_list_lock, and then use this to also simplify the\nreference counting in cfids_laundromat_worker() and\ninvalidate_all_cached_dirs().\n\nFixes this KASAN splat (which manually injects an error and lease break\nin open_cached_dir()):\n\n==================================================================\nBUG: KASAN: slab-use-after-free in smb2_cached_lease_break+0x27/0xb0\nRead of size 8 at addr ffff88811cc24c10 by task kworker/3:1/65\n\nCPU: 3 UID: 0 PID: 65 Comm: kworker/3:1 Not tainted 6.12.0-rc6-g255cf264e6e5-dirty #87\nHardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020\nWorkqueue: cifsiod smb2_cached_lease_break\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x77/0xb0\n print_report+0xce/0x660\n kasan_report+0xd3/0x110\n smb2_cached_lease_break+0x27/0xb0\n process_one_work+0x50a/0xc50\n worker_thread+0x2ba/0x530\n kthread+0x17c/0x1c0\n ret_from_fork+0x34/0x60\n ret_from_fork_asm+0x1a/0x30\n \u0026lt;/TASK\u0026gt;\n\nAllocated by task 2464:\n kasan_save_stack+0x33/0x60\n kasan_save_track+0x14/0x30\n __kasan_kmalloc+0xaa/0xb0\n open_cached_dir+0xa7d/0x1fb0\n smb2_query_path_info+0x43c/0x6e0\n cifs_get_fattr+0x346/0xf10\n cifs_get_inode_info+0x157/0x210\n cifs_revalidate_dentry_attr+0x2d1/0x460\n cifs_getattr+0x173/0x470\n vfs_statx_path+0x10f/0x160\n vfs_statx+0xe9/0x150\n vfs_fstatat+0x5e/0xc0\n __do_sys_newfstatat+0x91/0xf0\n do_syscall_64+0x95/0x1a0\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nFreed by task 2464:\n kasan_save_stack+0x33/0x60\n kasan_save_track+0x14/0x30\n kasan_save_free_info+0x3b/0x60\n __kasan_slab_free+0x51/0x70\n kfree+0x174/0x520\n open_cached_dir+0x97f/0x1fb0\n smb2_query_path_info+0x43c/0x6e0\n cifs_get_fattr+0x346/0xf10\n cifs_get_inode_info+0x157/0x210\n cifs_revalidate_dentry_attr+0x2d1/0x460\n cifs_getattr+0x173/0x470\n vfs_statx_path+0x10f/0x160\n vfs_statx+0xe9/0x150\n vfs_fstatat+0x5e/0xc0\n __do_sys_newfstatat+0x91/0xf0\n do_syscall_64+0x95/0x1a0\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nLast potentially related work creation:\n kasan_save_stack+0x33/0x60\n __kasan_record_aux_stack+0xad/0xc0\n insert_work+0x32/0x100\n __queue_work+0x5c9/0x870\n queue_work_on+0x82/0x90\n open_cached_dir+0x1369/0x1fb0\n smb2_query_path_info+0x43c/0x6e0\n cifs_get_fattr+0x346/0xf10\n cifs_get_inode_info+0x157/0x210\n cifs_revalidate_dentry_attr+0x2d1/0x460\n cifs_getattr+0x173/0x470\n vfs_statx_path+0x10f/0x160\n vfs_statx+0xe9/0x150\n vfs_fstatat+0x5e/0xc0\n __do_sys_newfstatat+0x91/0xf0\n do_syscall_64+0x95/0x1a0\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nThe buggy address belongs to the object at ffff88811cc24c00\n which belongs to the cache kmalloc-1k of size 1024\nThe buggy address is located 16 bytes inside of\n freed 1024-byte region [ffff88811cc24c00, ffff88811cc25000)(CVE-2024-53177)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: Don\u0026apos;t leak cfid when reconnect races with open_cached_dir\n\nopen_cached_dir() may either race with the tcon reconnection even before\ncompound_send_recv() or directly trigger a reconnection via\nSMB2_open_init() or SMB_query_info_init().\n\nThe reconnection process invokes invalidate_all_cached_dirs() via\ncifs_mark_open_files_invalid(), which removes all cfids from the\ncfids-\u0026gt;entries list but doesn\u0026apos;t drop a ref if has_lease isn\u0026apos;t true. This\nresults in the currently-being-constructed cfid not being on the list,\nbut still having a refcount of 2. It leaks if returned from\nopen_cached_dir().\n\nFix this by setting cfid-\u0026gt;has_lease when the ref is actually taken; the\ncfid will not be used by other threads until it has a valid time.\n\nAddresses these kmemleaks:\n\nunreferenced object 0xffff8881090c4000 (size 1024):\n comm \u0026quot;bash\u0026quot;, pid 1860, jiffies 4295126592\n hex dump (first 32 bytes):\n 00 01 00 00 00 00 ad de 22 01 00 00 00 00 ad de ........\u0026quot;.......\n 00 ca 45 22 81 88 ff ff f8 dc 4f 04 81 88 ff ff ..E\u0026quot;......O.....\n backtrace (crc 6f58c20f):\n [\u0026lt;ffffffff8b895a1e\u0026gt;] __kmalloc_cache_noprof+0x2be/0x350\n [\u0026lt;ffffffff8bda06e3\u0026gt;] open_cached_dir+0x993/0x1fb0\n [\u0026lt;ffffffff8bdaa750\u0026gt;] cifs_readdir+0x15a0/0x1d50\n [\u0026lt;ffffffff8b9a853f\u0026gt;] iterate_dir+0x28f/0x4b0\n [\u0026lt;ffffffff8b9a9aed\u0026gt;] __x64_sys_getdents64+0xfd/0x200\n [\u0026lt;ffffffff8cf6da05\u0026gt;] do_syscall_64+0x95/0x1a0\n [\u0026lt;ffffffff8d00012f\u0026gt;] entry_SYSCALL_64_after_hwframe+0x76/0x7e\nunreferenced object 0xffff8881044fdcf8 (size 8):\n comm \u0026quot;bash\u0026quot;, pid 1860, jiffies 4295126592\n hex dump (first 8 bytes):\n 00 cc cc cc cc cc cc cc ........\n backtrace (crc 10c106a9):\n [\u0026lt;ffffffff8b89a3d3\u0026gt;] __kmalloc_node_track_caller_noprof+0x363/0x480\n [\u0026lt;ffffffff8b7d7256\u0026gt;] kstrdup+0x36/0x60\n [\u0026lt;ffffffff8bda0700\u0026gt;] open_cached_dir+0x9b0/0x1fb0\n [\u0026lt;ffffffff8bdaa750\u0026gt;] cifs_readdir+0x15a0/0x1d50\n [\u0026lt;ffffffff8b9a853f\u0026gt;] iterate_dir+0x28f/0x4b0\n [\u0026lt;ffffffff8b9a9aed\u0026gt;] __x64_sys_getdents64+0xfd/0x200\n [\u0026lt;ffffffff8cf6da05\u0026gt;] do_syscall_64+0x95/0x1a0\n [\u0026lt;ffffffff8d00012f\u0026gt;] entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nAnd addresses these BUG splats when unmounting the SMB filesystem:\n\nBUG: Dentry ffff888140590ba0{i=1000000000080,n=/} still in use (2) [unmount of cifs cifs]\nWARNING: CPU: 3 PID: 3433 at fs/dcache.c:1536 umount_check+0xd0/0x100\nModules linked in:\nCPU: 3 UID: 0 PID: 3433 Comm: bash Not tainted 6.12.0-rc4-g850925a8133c-dirty #49\nHardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020\nRIP: 0010:umount_check+0xd0/0x100\nCode: 8d 7c 24 40 e8 31 5a f4 ff 49 8b 54 24 40 41 56 49 89 e9 45 89 e8 48 89 d9 41 57 48 89 de 48 c7 c7 80 e7 db ac e8 f0 72 9a ff \u0026lt;0f\u0026gt; 0b 58 31 c0 5a 5b 5d 41 5c 41 5d 41 5e 41 5f e9 2b e5 5d 01 41\nRSP: 0018:ffff88811cc27978 EFLAGS: 00010286\nRAX: 0000000000000000 RBX: ffff888140590ba0 RCX: ffffffffaaf20bae\nRDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff8881f6fb6f40\nRBP: ffff8881462ec000 R08: 0000000000000001 R09: ffffed1023984ee3\nR10: ffff88811cc2771f R11: 00000000016cfcc0 R12: ffff888134383e08\nR13: 0000000000000002 R14: ffff8881462ec668 R15: ffffffffaceab4c0\nFS: 00007f23bfa98740(0000) GS:ffff8881f6f80000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000556de4a6f808 CR3: 0000000123c80000 CR4: 0000000000350ef0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n d_walk+0x6a/0x530\n shrink_dcache_for_umount+0x6a/0x200\n generic_shutdown_super+0x52/0x2a0\n kill_anon_super+0x22/0x40\n cifs_kill_sb+0x159/0x1e0\n deactivate_locked_super+0x66/0xe0\n cleanup_mnt+0x140/0x210\n task_work_run+0xfb/0x170\n syscall_exit_to_user_mode+0x29f/0x2b0\n do_syscall_64+0xa1/0x1a0\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\nRIP: 0033:0x7f23bfb93ae7\nCode: ff ff ff ff c3 66 0f 1f 44 00 00 48 8b 0d 11 93 0d 00 f7 d8 64 89 01 b8 ff ff ff ff eb bf 0f 1f 44 00 00 b8 50 00 00 00 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 8b 0d e9 92 0d 00 f7 d8 64 89 \n---truncated---(CVE-2024-53178)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\num: vector: Do not use drvdata in release\n\nThe drvdata is not available in release. Let\u0026apos;s just use container_of()\nto get the vector_device instance. Otherwise, removing a vector device\nwill result in a crash:\n\nRIP: 0033:vector_device_release+0xf/0x50\nRSP: 00000000e187bc40 EFLAGS: 00010202\nRAX: 0000000060028f61 RBX: 00000000600f1baf RCX: 00000000620074e0\nRDX: 000000006220b9c0 RSI: 0000000060551c80 RDI: 0000000000000000\nRBP: 00000000e187bc50 R08: 00000000603ad594 R09: 00000000e187bb70\nR10: 000000000000135a R11: 00000000603ad422 R12: 00000000623ae028\nR13: 000000006287a200 R14: 0000000062006d30 R15: 00000000623700b6\nKernel panic - not syncing: Segfault with no mm\nCPU: 0 UID: 0 PID: 16 Comm: kworker/0:1 Not tainted 6.12.0-rc6-g59b723cd2adb #1\nWorkqueue: events mc_work_proc\nStack:\n 60028f61 623ae028 e187bc80 60276fcd\n 6220b9c0 603f5820 623ae028 00000000\n e187bcb0 603a2bcd 623ae000 62370010\nCall Trace:\n [\u0026lt;60028f61\u0026gt;] ? vector_device_release+0x0/0x50\n [\u0026lt;60276fcd\u0026gt;] device_release+0x70/0xba\n [\u0026lt;603a2bcd\u0026gt;] kobject_put+0xba/0xe7\n [\u0026lt;60277265\u0026gt;] put_device+0x19/0x1c\n [\u0026lt;60281266\u0026gt;] platform_device_put+0x26/0x29\n [\u0026lt;60281e5f\u0026gt;] platform_device_unregister+0x2c/0x2e\n [\u0026lt;60029422\u0026gt;] vector_remove+0x52/0x58\n [\u0026lt;60031316\u0026gt;] ? mconsole_reply+0x0/0x50\n [\u0026lt;600310c8\u0026gt;] mconsole_remove+0x160/0x1cc\n [\u0026lt;603b19f4\u0026gt;] ? strlen+0x0/0x15\n [\u0026lt;60066611\u0026gt;] ? __dequeue_entity+0x1a9/0x206\n [\u0026lt;600666a7\u0026gt;] ? set_next_entity+0x39/0x63\n [\u0026lt;6006666e\u0026gt;] ? set_next_entity+0x0/0x63\n [\u0026lt;60038fa6\u0026gt;] ? um_set_signals+0x0/0x43\n [\u0026lt;6003070c\u0026gt;] mc_work_proc+0x77/0x91\n [\u0026lt;60057664\u0026gt;] process_scheduled_works+0x1b3/0x2dd\n [\u0026lt;60055f32\u0026gt;] ? assign_work+0x0/0x58\n [\u0026lt;60057f0a\u0026gt;] worker_thread+0x1e9/0x293\n [\u0026lt;6005406f\u0026gt;] ? set_pf_worker+0x0/0x64\n [\u0026lt;6005d65d\u0026gt;] ? arch_local_irq_save+0x0/0x2d\n [\u0026lt;6005d748\u0026gt;] ? kthread_exit+0x0/0x3a\n [\u0026lt;60057d21\u0026gt;] ? worker_thread+0x0/0x293\n [\u0026lt;6005dbf1\u0026gt;] kthread+0x126/0x12b\n [\u0026lt;600219c5\u0026gt;] new_thread_handler+0x85/0xb6(CVE-2024-53181)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix NULL ptr deref in crypto_aead_setkey()\n\nNeither SMB3.0 or SMB3.02 supports encryption negotiate context, so\nwhen SMB2_GLOBAL_CAP_ENCRYPTION flag is set in the negotiate response,\nthe client uses AES-128-CCM as the default cipher. See MS-SMB2\n3.3.5.4.\n\nCommit b0abcd65ec54 (\u0026quot;smb: client: fix UAF in async decryption\u0026quot;) added\na @server-\u0026gt;cipher_type check to conditionally call\nsmb3_crypto_aead_allocate(), but that check would always be false as\n@server-\u0026gt;cipher_type is unset for SMB3.02.\n\nFix the following KASAN splat by setting @server-\u0026gt;cipher_type for\nSMB3.02 as well.\n\nmount.cifs //srv/share /mnt -o vers=3.02,seal,...\n\nBUG: KASAN: null-ptr-deref in crypto_aead_setkey+0x2c/0x130\nRead of size 8 at addr 0000000000000020 by task mount.cifs/1095\nCPU: 1 UID: 0 PID: 1095 Comm: mount.cifs Not tainted 6.12.0 #1\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-3.fc41\n04/01/2014\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x5d/0x80\n ? crypto_aead_setkey+0x2c/0x130\n kasan_report+0xda/0x110\n ? crypto_aead_setkey+0x2c/0x130\n crypto_aead_setkey+0x2c/0x130\n crypt_message+0x258/0xec0 [cifs]\n ? __asan_memset+0x23/0x50\n ? __pfx_crypt_message+0x10/0x10 [cifs]\n ? mark_lock+0xb0/0x6a0\n ? hlock_class+0x32/0xb0\n ? mark_lock+0xb0/0x6a0\n smb3_init_transform_rq+0x352/0x3f0 [cifs]\n ? lock_acquire.part.0+0xf4/0x2a0\n smb_send_rqst+0x144/0x230 [cifs]\n ? __pfx_smb_send_rqst+0x10/0x10 [cifs]\n ? hlock_class+0x32/0xb0\n ? smb2_setup_request+0x225/0x3a0 [cifs]\n ? __pfx_cifs_compound_last_callback+0x10/0x10 [cifs]\n compound_send_recv+0x59b/0x1140 [cifs]\n ? __pfx_compound_send_recv+0x10/0x10 [cifs]\n ? __create_object+0x5e/0x90\n ? hlock_class+0x32/0xb0\n ? do_raw_spin_unlock+0x9a/0xf0\n cifs_send_recv+0x23/0x30 [cifs]\n SMB2_tcon+0x3ec/0xb30 [cifs]\n ? __pfx_SMB2_tcon+0x10/0x10 [cifs]\n ? lock_acquire.part.0+0xf4/0x2a0\n ? __pfx_lock_release+0x10/0x10\n ? do_raw_spin_trylock+0xc6/0x120\n ? lock_acquire+0x3f/0x90\n ? _get_xid+0x16/0xd0 [cifs]\n ? __pfx_SMB2_tcon+0x10/0x10 [cifs]\n ? cifs_get_smb_ses+0xcdd/0x10a0 [cifs]\n cifs_get_smb_ses+0xcdd/0x10a0 [cifs]\n ? __pfx_cifs_get_smb_ses+0x10/0x10 [cifs]\n ? cifs_get_tcp_session+0xaa0/0xca0 [cifs]\n cifs_mount_get_session+0x8a/0x210 [cifs]\n dfs_mount_share+0x1b0/0x11d0 [cifs]\n ? __pfx___lock_acquire+0x10/0x10\n ? __pfx_dfs_mount_share+0x10/0x10 [cifs]\n ? lock_acquire.part.0+0xf4/0x2a0\n ? find_held_lock+0x8a/0xa0\n ? hlock_class+0x32/0xb0\n ? lock_release+0x203/0x5d0\n cifs_mount+0xb3/0x3d0 [cifs]\n ? do_raw_spin_trylock+0xc6/0x120\n ? __pfx_cifs_mount+0x10/0x10 [cifs]\n ? lock_acquire+0x3f/0x90\n ? find_nls+0x16/0xa0\n ? smb3_update_mnt_flags+0x372/0x3b0 [cifs]\n cifs_smb3_do_mount+0x1e2/0xc80 [cifs]\n ? __pfx_vfs_parse_fs_string+0x10/0x10\n ? __pfx_cifs_smb3_do_mount+0x10/0x10 [cifs]\n smb3_get_tree+0x1bf/0x330 [cifs]\n vfs_get_tree+0x4a/0x160\n path_mount+0x3c1/0xfb0\n ? kasan_quarantine_put+0xc7/0x1d0\n ? __pfx_path_mount+0x10/0x10\n ? kmem_cache_free+0x118/0x3e0\n ? user_path_at+0x74/0xa0\n __x64_sys_mount+0x1a6/0x1e0\n ? __pfx___x64_sys_mount+0x10/0x10\n ? mark_held_locks+0x1a/0x90\n do_syscall_64+0xbb/0x1d0\n entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2024-53185)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ns390/iucv: MSG_PEEK causes memory leak in iucv_sock_destruct()\n\nPassing MSG_PEEK flag to skb_recv_datagram() increments skb refcount\n(skb-\u0026gt;users) and iucv_sock_recvmsg() does not decrement skb refcount\nat exit.\nThis results in skb memory leak in skb_queue_purge() and WARN_ON in\niucv_sock_destruct() during socket close. To fix this decrease\nskb refcount by one if MSG_PEEK is set in order to prevent memory\nleak and WARN_ON.\n\nWARNING: CPU: 2 PID: 6292 at net/iucv/af_iucv.c:286 iucv_sock_destruct+0x144/0x1a0 [af_iucv]\nCPU: 2 PID: 6292 Comm: afiucv_test_msg Kdump: loaded Tainted: G W 6.10.0-rc7 #1\nHardware name: IBM 3931 A01 704 (z/VM 7.3.0)\nCall Trace:\n [\u0026lt;001587c682c4aa98\u0026gt;] iucv_sock_destruct+0x148/0x1a0 [af_iucv]\n [\u0026lt;001587c682c4a9d0\u0026gt;] iucv_sock_destruct+0x80/0x1a0 [af_iucv]\n [\u0026lt;001587c704117a32\u0026gt;] __sk_destruct+0x52/0x550\n [\u0026lt;001587c704104a54\u0026gt;] __sock_release+0xa4/0x230\n [\u0026lt;001587c704104c0c\u0026gt;] sock_close+0x2c/0x40\n [\u0026lt;001587c702c5f5a8\u0026gt;] __fput+0x2e8/0x970\n [\u0026lt;001587c7024148c4\u0026gt;] task_work_run+0x1c4/0x2c0\n [\u0026lt;001587c7023b0716\u0026gt;] do_exit+0x996/0x1050\n [\u0026lt;001587c7023b13aa\u0026gt;] do_group_exit+0x13a/0x360\n [\u0026lt;001587c7023b1626\u0026gt;] __s390x_sys_exit_group+0x56/0x60\n [\u0026lt;001587c7022bccca\u0026gt;] do_syscall+0x27a/0x380\n [\u0026lt;001587c7049a6a0c\u0026gt;] __do_syscall+0x9c/0x160\n [\u0026lt;001587c7049ce8a8\u0026gt;] system_call+0x70/0x98\n Last Breaking-Event-Address:\n [\u0026lt;001587c682c4a9d4\u0026gt;] iucv_sock_destruct+0x84/0x1a0 [af_iucv](CVE-2024-53210)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvfio/pci: Properly hide first-in-list PCIe extended capability\n\nThere are cases where a PCIe extended capability should be hidden from\nthe user. For example, an unknown capability (i.e., capability with ID\ngreater than PCI_EXT_CAP_ID_MAX) or a capability that is intentionally\nchosen to be hidden from the user.\n\nHiding a capability is done by virtualizing and modifying the \u0026apos;Next\nCapability Offset\u0026apos; field of the previous capability so it points to the\ncapability after the one that should be hidden.\n\nThe special case where the first capability in the list should be hidden\nis handled differently because there is no previous capability that can\nbe modified. In this case, the capability ID and version are zeroed\nwhile leaving the next pointer intact. This hides the capability and\nleaves an anchor for the rest of the capability list.\n\nHowever, today, hiding the first capability in the list is not done\nproperly if the capability is unknown, as struct\nvfio_pci_core_device-\u0026gt;pci_config_map is set to the capability ID during\ninitialization but the capability ID is not properly checked later when\nused in vfio_config_do_rw(). This leads to the following warning [1] and\nto an out-of-bounds access to ecap_perms array.\n\nFix it by checking cap_id in vfio_config_do_rw(), and if it is greater\nthan PCI_EXT_CAP_ID_MAX, use an alternative struct perm_bits for direct\nread only access instead of the ecap_perms array.\n\nNote that this is safe since the above is the only case where cap_id can\nexceed PCI_EXT_CAP_ID_MAX (except for the special capabilities, which\nare already checked before).\n\n[1]\n\nWARNING: CPU: 118 PID: 5329 at drivers/vfio/pci/vfio_pci_config.c:1900 vfio_pci_config_rw+0x395/0x430 [vfio_pci_core]\nCPU: 118 UID: 0 PID: 5329 Comm: simx-qemu-syste Not tainted 6.12.0+ #1\n(snip)\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? show_regs+0x69/0x80\n ? __warn+0x8d/0x140\n ? vfio_pci_config_rw+0x395/0x430 [vfio_pci_core]\n ? report_bug+0x18f/0x1a0\n ? handle_bug+0x63/0xa0\n ? exc_invalid_op+0x19/0x70\n ? asm_exc_invalid_op+0x1b/0x20\n ? vfio_pci_config_rw+0x395/0x430 [vfio_pci_core]\n ? vfio_pci_config_rw+0x244/0x430 [vfio_pci_core]\n vfio_pci_rw+0x101/0x1b0 [vfio_pci_core]\n vfio_pci_core_read+0x1d/0x30 [vfio_pci_core]\n vfio_device_fops_read+0x27/0x40 [vfio]\n vfs_read+0xbd/0x340\n ? vfio_device_fops_unl_ioctl+0xbb/0x740 [vfio]\n ? __rseq_handle_notify_resume+0xa4/0x4b0\n __x64_sys_pread64+0x96/0xc0\n x64_sys_call+0x1c3d/0x20d0\n do_syscall_64+0x4d/0x120\n entry_SYSCALL_64_after_hwframe+0x76/0x7e(CVE-2024-53214)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: release svc_expkey/svc_export with rcu_work\n\nThe last reference for `cache_head` can be reduced to zero in `c_show`\nand `e_show`(using `rcu_read_lock` and `rcu_read_unlock`). Consequently,\n`svc_export_put` and `expkey_put` will be invoked, leading to two\nissues:\n\n1. The `svc_export_put` will directly free ex_uuid. However,\n `e_show`/`c_show` will access `ex_uuid` after `cache_put`, which can\n trigger a use-after-free issue, shown below.\n\n ==================================================================\n BUG: KASAN: slab-use-after-free in svc_export_show+0x362/0x430 [nfsd]\n Read of size 1 at addr ff11000010fdc120 by task cat/870\n\n CPU: 1 UID: 0 PID: 870 Comm: cat Not tainted 6.12.0-rc3+ #1\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS\n 1.16.1-2.fc37 04/01/2014\n Call Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x53/0x70\n print_address_description.constprop.0+0x2c/0x3a0\n print_report+0xb9/0x280\n kasan_report+0xae/0xe0\n svc_export_show+0x362/0x430 [nfsd]\n c_show+0x161/0x390 [sunrpc]\n seq_read_iter+0x589/0x770\n seq_read+0x1e5/0x270\n proc_reg_read+0xe1/0x140\n vfs_read+0x125/0x530\n ksys_read+0xc1/0x160\n do_syscall_64+0x5f/0x170\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\n Allocated by task 830:\n kasan_save_stack+0x20/0x40\n kasan_save_track+0x14/0x30\n __kasan_kmalloc+0x8f/0xa0\n __kmalloc_node_track_caller_noprof+0x1bc/0x400\n kmemdup_noprof+0x22/0x50\n svc_export_parse+0x8a9/0xb80 [nfsd]\n cache_do_downcall+0x71/0xa0 [sunrpc]\n cache_write_procfs+0x8e/0xd0 [sunrpc]\n proc_reg_write+0xe1/0x140\n vfs_write+0x1a5/0x6d0\n ksys_write+0xc1/0x160\n do_syscall_64+0x5f/0x170\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\n Freed by task 868:\n kasan_save_stack+0x20/0x40\n kasan_save_track+0x14/0x30\n kasan_save_free_info+0x3b/0x60\n __kasan_slab_free+0x37/0x50\n kfree+0xf3/0x3e0\n svc_export_put+0x87/0xb0 [nfsd]\n cache_purge+0x17f/0x1f0 [sunrpc]\n nfsd_destroy_serv+0x226/0x2d0 [nfsd]\n nfsd_svc+0x125/0x1e0 [nfsd]\n write_threads+0x16a/0x2a0 [nfsd]\n nfsctl_transaction_write+0x74/0xa0 [nfsd]\n vfs_write+0x1a5/0x6d0\n ksys_write+0xc1/0x160\n do_syscall_64+0x5f/0x170\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\n2. We cannot sleep while using `rcu_read_lock`/`rcu_read_unlock`.\n However, `svc_export_put`/`expkey_put` will call path_put, which\n subsequently triggers a sleeping operation due to the following\n `dput`.\n\n =============================\n WARNING: suspicious RCU usage\n 5.10.0-dirty #141 Not tainted\n -----------------------------\n ...\n Call Trace:\n dump_stack+0x9a/0xd0\n ___might_sleep+0x231/0x240\n dput+0x39/0x600\n path_put+0x1b/0x30\n svc_export_put+0x17/0x80\n e_show+0x1c9/0x200\n seq_read_iter+0x63f/0x7c0\n seq_read+0x226/0x2d0\n vfs_read+0x113/0x2c0\n ksys_read+0xc9/0x170\n do_syscall_64+0x33/0x40\n entry_SYSCALL_64_after_hwframe+0x67/0xd1\n\nFix these issues by using `rcu_work` to help release\n`svc_expkey`/`svc_export`. This approach allows for an asynchronous\ncontext to invoke `path_put` and also facilitates the freeing of\n`uuid/exp/key` after an RCU grace period.(CVE-2024-53216)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nunicode: Fix utf8_load() error path\n\nutf8_load() requests the symbol \u0026quot;utf8_data_table\u0026quot; and then checks if the\nrequested UTF-8 version is supported. If it\u0026apos;s unsupported, it tries to\nput the data table using symbol_put(). If an unsupported version is\nrequested, symbol_put() fails like this:\n\n kernel BUG at kernel/module/main.c:786!\n RIP: 0010:__symbol_put+0x93/0xb0\n Call Trace:\n \u0026lt;TASK\u0026gt;\n ? __die_body.cold+0x19/0x27\n ? die+0x2e/0x50\n ? do_trap+0xca/0x110\n ? do_error_trap+0x65/0x80\n ? __symbol_put+0x93/0xb0\n ? exc_invalid_op+0x51/0x70\n ? __symbol_put+0x93/0xb0\n ? asm_exc_invalid_op+0x1a/0x20\n ? __pfx_cmp_name+0x10/0x10\n ? __symbol_put+0x93/0xb0\n ? __symbol_put+0x62/0xb0\n utf8_load+0xf8/0x150\n\nThat happens because symbol_put() expects the unique string that\nidentify the symbol, instead of a pointer to the loaded symbol. Fix that\nby using such string.(CVE-2024-53233)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFS: Fix potential buffer overflowin nfs_sysfs_link_rpc_client()\n\nname is char[64] where the size of clnt-\u0026gt;cl_program-\u0026gt;name remains\nunknown. Invoking strcat() directly will also lead to potential buffer\noverflow. Change them to strscpy() and strncat() to fix potential\nissues.(CVE-2024-54456)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nALSA: caiaq: Use snd_card_free_when_closed() at disconnection\n\nThe USB disconnect callback is supposed to be short and not too-long\nwaiting. OTOH, the current code uses snd_card_free() at\ndisconnection, but this waits for the close of all used fds, hence it\ncan take long. It eventually blocks the upper layer USB ioctls, which\nmay trigger a soft lockup.\n\nAn easy workaround is to replace snd_card_free() with\nsnd_card_free_when_closed(). This variant returns immediately while\nthe release of resources is done asynchronously by the card device\nrelease at the last close.\n\nThis patch also splits the code to the disconnect and the free phases;\nthe former is called immediately at the USB disconnect callback while\nthe latter is called from the card destructor.(CVE-2024-56531)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nALSA: usx2y: Use snd_card_free_when_closed() at disconnection\n\nThe USB disconnect callback is supposed to be short and not too-long\nwaiting. OTOH, the current code uses snd_card_free() at\ndisconnection, but this waits for the close of all used fds, hence it\ncan take long. It eventually blocks the upper layer USB ioctls, which\nmay trigger a soft lockup.\n\nAn easy workaround is to replace snd_card_free() with\nsnd_card_free_when_closed(). This variant returns immediately while\nthe release of resources is done asynchronously by the card device\nrelease at the last close.(CVE-2024-56533)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mwifiex: Fix memcpy() field-spanning write warning in mwifiex_config_scan()\n\nReplace one-element array with a flexible-array member in `struct\nmwifiex_ie_types_wildcard_ssid_params` to fix the following warning\non a MT8173 Chromebook (mt8173-elm-hana):\n\n[ 356.775250] ------------[ cut here ]------------\n[ 356.784543] memcpy: detected field-spanning write (size 6) of single field \u0026quot;wildcard_ssid_tlv-\u0026gt;ssid\u0026quot; at drivers/net/wireless/marvell/mwifiex/scan.c:904 (size 1)\n[ 356.813403] WARNING: CPU: 3 PID: 742 at drivers/net/wireless/marvell/mwifiex/scan.c:904 mwifiex_scan_networks+0x4fc/0xf28 [mwifiex]\n\nThe \u0026quot;(size 6)\u0026quot; above is exactly the length of the SSID of the network\nthis device was connected to. The source of the warning looks like:\n\n ssid_len = user_scan_in-\u0026gt;ssid_list[i].ssid_len;\n [...]\n memcpy(wildcard_ssid_tlv-\u0026gt;ssid,\n user_scan_in-\u0026gt;ssid_list[i].ssid, ssid_len);\n\nThere is a #define WILDCARD_SSID_TLV_MAX_SIZE that uses sizeof() on this\nstruct, but it already didn\u0026apos;t account for the size of the one-element\narray, so it doesn\u0026apos;t need to be changed.(CVE-2024-56539)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: hyperv: streamline driver probe to avoid devres issues\n\nIt was found that unloading \u0026apos;hid_hyperv\u0026apos; module results in a devres\ncomplaint:\n\n ...\n hv_vmbus: unregistering driver hid_hyperv\n ------------[ cut here ]------------\n WARNING: CPU: 2 PID: 3983 at drivers/base/devres.c:691 devres_release_group+0x1f2/0x2c0\n ...\n Call Trace:\n \u0026lt;TASK\u0026gt;\n ? devres_release_group+0x1f2/0x2c0\n ? __warn+0xd1/0x1c0\n ? devres_release_group+0x1f2/0x2c0\n ? report_bug+0x32a/0x3c0\n ? handle_bug+0x53/0xa0\n ? exc_invalid_op+0x18/0x50\n ? asm_exc_invalid_op+0x1a/0x20\n ? devres_release_group+0x1f2/0x2c0\n ? devres_release_group+0x90/0x2c0\n ? rcu_is_watching+0x15/0xb0\n ? __pfx_devres_release_group+0x10/0x10\n hid_device_remove+0xf5/0x220\n device_release_driver_internal+0x371/0x540\n ? klist_put+0xf3/0x170\n bus_remove_device+0x1f1/0x3f0\n device_del+0x33f/0x8c0\n ? __pfx_device_del+0x10/0x10\n ? cleanup_srcu_struct+0x337/0x500\n hid_destroy_device+0xc8/0x130\n mousevsc_remove+0xd2/0x1d0 [hid_hyperv]\n device_release_driver_internal+0x371/0x540\n driver_detach+0xc5/0x180\n bus_remove_driver+0x11e/0x2a0\n ? __mutex_unlock_slowpath+0x160/0x5e0\n vmbus_driver_unregister+0x62/0x2b0 [hv_vmbus]\n ...\n\nAnd the issue seems to be that the corresponding devres group is not\nallocated. Normally, devres_open_group() is called from\n__hid_device_probe() but Hyper-V HID driver overrides \u0026apos;hid_dev-\u0026gt;driver\u0026apos;\nwith \u0026apos;mousevsc_hid_driver\u0026apos; stub and basically re-implements\n__hid_device_probe() by calling hid_parse() and hid_hw_start() but not\ndevres_open_group(). hid_device_probe() does not call __hid_device_probe()\nfor it. Later, when the driver is removed, hid_device_remove() calls\ndevres_release_group() as it doesn\u0026apos;t check whether hdev-\u0026gt;driver was\ninitially overridden or not.\n\nThe issue seems to be related to the commit 62c68e7cee33 (\u0026quot;HID: ensure\ntimely release of driver-allocated resources\u0026quot;) but the commit itself seems\nto be correct.\n\nFix the issue by dropping the \u0026apos;hid_dev-\u0026gt;driver\u0026apos; override and using\nhid_register_driver()/hid_unregister_driver() instead. Alternatively, it\nwould have been possible to rely on the default handling but\nHID_CONNECT_DEFAULT implies HID_CONNECT_HIDRAW and it doesn\u0026apos;t seem to work\nfor mousevsc as-is.(CVE-2024-56545)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu: fix usage slab after free\n\n[ +0.000021] BUG: KASAN: slab-use-after-free in drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched]\n[ +0.000027] Read of size 8 at addr ffff8881b8605f88 by task amd_pci_unplug/2147\n\n[ +0.000023] CPU: 6 PID: 2147 Comm: amd_pci_unplug Not tainted 6.10.0+ #1\n[ +0.000016] Hardware name: ASUS System Product Name/ROG STRIX B550-F GAMING (WI-FI), BIOS 1401 12/03/2020\n[ +0.000016] Call Trace:\n[ +0.000008] \u0026lt;TASK\u0026gt;\n[ +0.000009] dump_stack_lvl+0x76/0xa0\n[ +0.000017] print_report+0xce/0x5f0\n[ +0.000017] ? drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched]\n[ +0.000019] ? srso_return_thunk+0x5/0x5f\n[ +0.000015] ? kasan_complete_mode_report_info+0x72/0x200\n[ +0.000016] ? drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched]\n[ +0.000019] kasan_report+0xbe/0x110\n[ +0.000015] ? drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched]\n[ +0.000023] __asan_report_load8_noabort+0x14/0x30\n[ +0.000014] drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched]\n[ +0.000020] ? srso_return_thunk+0x5/0x5f\n[ +0.000013] ? __kasan_check_write+0x14/0x30\n[ +0.000016] ? __pfx_drm_sched_entity_flush+0x10/0x10 [gpu_sched]\n[ +0.000020] ? srso_return_thunk+0x5/0x5f\n[ +0.000013] ? __kasan_check_write+0x14/0x30\n[ +0.000013] ? srso_return_thunk+0x5/0x5f\n[ +0.000013] ? enable_work+0x124/0x220\n[ +0.000015] ? __pfx_enable_work+0x10/0x10\n[ +0.000013] ? srso_return_thunk+0x5/0x5f\n[ +0.000014] ? free_large_kmalloc+0x85/0xf0\n[ +0.000016] drm_sched_entity_destroy+0x18/0x30 [gpu_sched]\n[ +0.000020] amdgpu_vce_sw_fini+0x55/0x170 [amdgpu]\n[ +0.000735] ? __kasan_check_read+0x11/0x20\n[ +0.000016] vce_v4_0_sw_fini+0x80/0x110 [amdgpu]\n[ +0.000726] amdgpu_device_fini_sw+0x331/0xfc0 [amdgpu]\n[ +0.000679] ? mutex_unlock+0x80/0xe0\n[ +0.000017] ? __pfx_amdgpu_device_fini_sw+0x10/0x10 [amdgpu]\n[ +0.000662] ? srso_return_thunk+0x5/0x5f\n[ +0.000014] ? __kasan_check_write+0x14/0x30\n[ +0.000013] ? srso_return_thunk+0x5/0x5f\n[ +0.000013] ? mutex_unlock+0x80/0xe0\n[ +0.000016] amdgpu_driver_release_kms+0x16/0x80 [amdgpu]\n[ +0.000663] drm_minor_release+0xc9/0x140 [drm]\n[ +0.000081] drm_release+0x1fd/0x390 [drm]\n[ +0.000082] __fput+0x36c/0xad0\n[ +0.000018] __fput_sync+0x3c/0x50\n[ +0.000014] __x64_sys_close+0x7d/0xe0\n[ +0.000014] x64_sys_call+0x1bc6/0x2680\n[ +0.000014] do_syscall_64+0x70/0x130\n[ +0.000014] ? srso_return_thunk+0x5/0x5f\n[ +0.000014] ? irqentry_exit_to_user_mode+0x60/0x190\n[ +0.000015] ? srso_return_thunk+0x5/0x5f\n[ +0.000014] ? irqentry_exit+0x43/0x50\n[ +0.000012] ? srso_return_thunk+0x5/0x5f\n[ +0.000013] ? exc_page_fault+0x7c/0x110\n[ +0.000015] entry_SYSCALL_64_after_hwframe+0x76/0x7e\n[ +0.000014] RIP: 0033:0x7ffff7b14f67\n[ +0.000013] Code: ff e8 0d 16 02 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 03 00 00 00 0f 05 \u0026lt;48\u0026gt; 3d 00 f0 ff ff 77 41 c3 48 83 ec 18 89 7c 24 0c e8 73 ba f7 ff\n[ +0.000026] RSP: 002b:00007fffffffe378 EFLAGS: 00000246 ORIG_RAX: 0000000000000003\n[ +0.000019] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007ffff7b14f67\n[ +0.000014] RDX: 0000000000000000 RSI: 00007ffff7f6f47a RDI: 0000000000000003\n[ +0.000014] RBP: 00007fffffffe3a0 R08: 0000555555569890 R09: 0000000000000000\n[ +0.000014] R10: 0000000000000000 R11: 0000000000000246 R12: 00007fffffffe5c8\n[ +0.000013] R13: 00005555555552a9 R14: 0000555555557d48 R15: 00007ffff7ffd040\n[ +0.000020] \u0026lt;/TASK\u0026gt;\n\n[ +0.000016] Allocated by task 383 on cpu 7 at 26.880319s:\n[ +0.000014] kasan_save_stack+0x28/0x60\n[ +0.000008] kasan_save_track+0x18/0x70\n[ +0.000007] kasan_save_alloc_info+0x38/0x60\n[ +0.000007] __kasan_kmalloc+0xc1/0xd0\n[ +0.000007] kmalloc_trace_noprof+0x180/0x380\n[ +0.000007] drm_sched_init+0x411/0xec0 [gpu_sched]\n[ +0.000012] amdgpu_device_init+0x695f/0xa610 [amdgpu]\n[ +0.000658] amdgpu_driver_load_kms+0x1a/0x120 [amdgpu]\n[ +0.000662] amdgpu_pci_p\n---truncated---(CVE-2024-56551)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: make sure exp active before svc_export_show\n\nThe function `e_show` was called with protection from RCU. This only\nensures that `exp` will not be freed. Therefore, the reference count for\n`exp` can drop to zero, which will trigger a refcount use-after-free\nwarning when `exp_get` is called. To resolve this issue, use\n`cache_get_rcu` to ensure that `exp` remains active.\n\n------------[ cut here ]------------\nrefcount_t: addition on 0; use-after-free.\nWARNING: CPU: 3 PID: 819 at lib/refcount.c:25\nrefcount_warn_saturate+0xb1/0x120\nCPU: 3 UID: 0 PID: 819 Comm: cat Not tainted 6.12.0-rc3+ #1\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS\n1.16.1-2.fc37 04/01/2014\nRIP: 0010:refcount_warn_saturate+0xb1/0x120\n...\nCall Trace:\n \u0026lt;TASK\u0026gt;\n e_show+0x20b/0x230 [nfsd]\n seq_read_iter+0x589/0x770\n seq_read+0x1e5/0x270\n vfs_read+0x125/0x530\n ksys_read+0xc1/0x160\n do_syscall_64+0x5f/0x170\n entry_SYSCALL_64_after_hwframe+0x76/0x7e(CVE-2024-56558)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/slub: Avoid list corruption when removing a slab from the full list\n\nBoot with slub_debug=UFPZ.\n\nIf allocated object failed in alloc_consistency_checks, all objects of\nthe slab will be marked as used, and then the slab will be removed from\nthe partial list.\n\nWhen an object belonging to the slab got freed later, the remove_full()\nfunction is called. Because the slab is neither on the partial list nor\non the full list, it eventually lead to a list corruption (actually a\nlist poison being detected).\n\nSo we need to mark and isolate the slab page with metadata corruption,\ndo not put it back in circulation.\n\nBecause the debug caches avoid all the fastpaths, reusing the frozen bit\nto mark slab page with metadata corruption seems to be fine.\n\n[ 4277.385669] list_del corruption, ffffea00044b3e50-\u0026gt;next is LIST_POISON1 (dead000000000100)\n[ 4277.387023] ------------[ cut here ]------------\n[ 4277.387880] kernel BUG at lib/list_debug.c:56!\n[ 4277.388680] invalid opcode: 0000 [#1] PREEMPT SMP PTI\n[ 4277.389562] CPU: 5 PID: 90 Comm: kworker/5:1 Kdump: loaded Tainted: G OE 6.6.1-1 #1\n[ 4277.392113] Workqueue: xfs-inodegc/vda1 xfs_inodegc_worker [xfs]\n[ 4277.393551] RIP: 0010:__list_del_entry_valid_or_report+0x7b/0xc0\n[ 4277.394518] Code: 48 91 82 e8 37 f9 9a ff 0f 0b 48 89 fe 48 c7 c7 28 49 91 82 e8 26 f9 9a ff 0f 0b 48 89 fe 48 c7 c7 58 49 91\n[ 4277.397292] RSP: 0018:ffffc90000333b38 EFLAGS: 00010082\n[ 4277.398202] RAX: 000000000000004e RBX: ffffea00044b3e50 RCX: 0000000000000000\n[ 4277.399340] RDX: 0000000000000002 RSI: ffffffff828f8715 RDI: 00000000ffffffff\n[ 4277.400545] RBP: ffffea00044b3e40 R08: 0000000000000000 R09: ffffc900003339f0\n[ 4277.401710] R10: 0000000000000003 R11: ffffffff82d44088 R12: ffff888112cf9910\n[ 4277.402887] R13: 0000000000000001 R14: 0000000000000001 R15: ffff8881000424c0\n[ 4277.404049] FS: 0000000000000000(0000) GS:ffff88842fd40000(0000) knlGS:0000000000000000\n[ 4277.405357] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 4277.406389] CR2: 00007f2ad0b24000 CR3: 0000000102a3a006 CR4: 00000000007706e0\n[ 4277.407589] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[ 4277.408780] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[ 4277.410000] PKRU: 55555554\n[ 4277.410645] Call Trace:\n[ 4277.411234] \u0026lt;TASK\u0026gt;\n[ 4277.411777] ? die+0x32/0x80\n[ 4277.412439] ? do_trap+0xd6/0x100\n[ 4277.413150] ? __list_del_entry_valid_or_report+0x7b/0xc0\n[ 4277.414158] ? do_error_trap+0x6a/0x90\n[ 4277.414948] ? __list_del_entry_valid_or_report+0x7b/0xc0\n[ 4277.415915] ? exc_invalid_op+0x4c/0x60\n[ 4277.416710] ? __list_del_entry_valid_or_report+0x7b/0xc0\n[ 4277.417675] ? asm_exc_invalid_op+0x16/0x20\n[ 4277.418482] ? __list_del_entry_valid_or_report+0x7b/0xc0\n[ 4277.419466] ? __list_del_entry_valid_or_report+0x7b/0xc0\n[ 4277.420410] free_to_partial_list+0x515/0x5e0\n[ 4277.421242] ? xfs_iext_remove+0x41a/0xa10 [xfs]\n[ 4277.422298] xfs_iext_remove+0x41a/0xa10 [xfs]\n[ 4277.423316] ? xfs_inodegc_worker+0xb4/0x1a0 [xfs]\n[ 4277.424383] xfs_bmap_del_extent_delay+0x4fe/0x7d0 [xfs]\n[ 4277.425490] __xfs_bunmapi+0x50d/0x840 [xfs]\n[ 4277.426445] xfs_itruncate_extents_flags+0x13a/0x490 [xfs]\n[ 4277.427553] xfs_inactive_truncate+0xa3/0x120 [xfs]\n[ 4277.428567] xfs_inactive+0x22d/0x290 [xfs]\n[ 4277.429500] xfs_inodegc_worker+0xb4/0x1a0 [xfs]\n[ 4277.430479] process_one_work+0x171/0x340\n[ 4277.431227] worker_thread+0x277/0x390\n[ 4277.431962] ? __pfx_worker_thread+0x10/0x10\n[ 4277.432752] kthread+0xf0/0x120\n[ 4277.433382] ? __pfx_kthread+0x10/0x10\n[ 4277.434134] ret_from_fork+0x2d/0x50\n[ 4277.434837] ? __pfx_kthread+0x10/0x10\n[ 4277.435566] ret_from_fork_asm+0x1b/0x30\n[ 4277.436280] \u0026lt;/TASK\u0026gt;(CVE-2024-56566)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nefi/libstub: Free correct pointer on failure\n\ncmdline_ptr is an out parameter, which is not allocated by the function\nitself, and likely points into the caller\u0026apos;s stack.\n\ncmdline refers to the pool allocation that should be freed when cleaning\nup after a failure, so pass this instead to free_pool().(CVE-2024-56573)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: ts2020: fix null-ptr-deref in ts2020_probe()\n\nKASAN reported a null-ptr-deref issue when executing the following\ncommand:\n\n # echo ts2020 0x20 \u0026gt; /sys/bus/i2c/devices/i2c-0/new_device\n KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]\n CPU: 53 UID: 0 PID: 970 Comm: systemd-udevd Not tainted 6.12.0-rc2+ #24\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009)\n RIP: 0010:ts2020_probe+0xad/0xe10 [ts2020]\n RSP: 0018:ffffc9000abbf598 EFLAGS: 00010202\n RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffffc0714809\n RDX: 0000000000000002 RSI: ffff88811550be00 RDI: 0000000000000010\n RBP: ffff888109868800 R08: 0000000000000001 R09: fffff52001577eb6\n R10: 0000000000000000 R11: ffffc9000abbff50 R12: ffffffffc0714790\n R13: 1ffff92001577eb8 R14: ffffffffc07190d0 R15: 0000000000000001\n FS: 00007f95f13b98c0(0000) GS:ffff888149280000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 0000555d2634b000 CR3: 0000000152236000 CR4: 00000000000006f0\n DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n Call Trace:\n \u0026lt;TASK\u0026gt;\n ts2020_probe+0xad/0xe10 [ts2020]\n i2c_device_probe+0x421/0xb40\n really_probe+0x266/0x850\n ...\n\nThe cause of the problem is that when using sysfs to dynamically register\nan i2c device, there is no platform data, but the probe process of ts2020\nneeds to use platform data, resulting in a null pointer being accessed.\n\nSolve this problem by adding checks to platform data.(CVE-2024-56574)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: i2c: tc358743: Fix crash in the probe error path when using polling\n\nIf an error occurs in the probe() function, we should remove the polling\ntimer that was alarmed earlier, otherwise the timer is called with\narguments that are already freed, which results in a crash.\n\n------------[ cut here ]------------\nWARNING: CPU: 3 PID: 0 at kernel/time/timer.c:1830 __run_timers+0x244/0x268\nModules linked in:\nCPU: 3 UID: 0 PID: 0 Comm: swapper/3 Not tainted 6.11.0 #226\nHardware name: Diasom DS-RK3568-SOM-EVB (DT)\npstate: 804000c9 (Nzcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : __run_timers+0x244/0x268\nlr : __run_timers+0x1d4/0x268\nsp : ffffff80eff2baf0\nx29: ffffff80eff2bb50 x28: 7fffffffffffffff x27: ffffff80eff2bb00\nx26: ffffffc080f669c0 x25: ffffff80efef6bf0 x24: ffffff80eff2bb00\nx23: 0000000000000000 x22: dead000000000122 x21: 0000000000000000\nx20: ffffff80efef6b80 x19: ffffff80041c8bf8 x18: ffffffffffffffff\nx17: ffffffc06f146000 x16: ffffff80eff27dc0 x15: 000000000000003e\nx14: 0000000000000000 x13: 00000000000054da x12: 0000000000000000\nx11: 00000000000639c0 x10: 000000000000000c x9 : 0000000000000009\nx8 : ffffff80eff2cb40 x7 : ffffff80eff2cb40 x6 : ffffff8002bee480\nx5 : ffffffc080cb2220 x4 : ffffffc080cb2150 x3 : 00000000000f4240\nx2 : 0000000000000102 x1 : ffffff80eff2bb00 x0 : ffffff80041c8bf0\nCall trace:\n\u00a0__run_timers+0x244/0x268\n\u00a0timer_expire_remote+0x50/0x68\n\u00a0tmigr_handle_remote+0x388/0x39c\n\u00a0run_timer_softirq+0x38/0x44\n\u00a0handle_softirqs+0x138/0x298\n\u00a0__do_softirq+0x14/0x20\n\u00a0____do_softirq+0x10/0x1c\n\u00a0call_on_irq_stack+0x24/0x4c\n\u00a0do_softirq_own_stack+0x1c/0x2c\n\u00a0irq_exit_rcu+0x9c/0xcc\n\u00a0el1_interrupt+0x48/0xc0\n\u00a0el1h_64_irq_handler+0x18/0x24\n\u00a0el1h_64_irq+0x7c/0x80\n\u00a0default_idle_call+0x34/0x68\n\u00a0do_idle+0x23c/0x294\n\u00a0cpu_startup_entry+0x38/0x3c\n\u00a0secondary_start_kernel+0x128/0x160\n\u00a0__secondary_switched+0xb8/0xbc\n---[ end trace 0000000000000000 ]---(CVE-2024-56576)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: mtk-jpeg: Fix null-ptr-deref during unload module\n\nThe workqueue should be destroyed in mtk_jpeg_core.c since commit\n09aea13ecf6f (\u0026quot;media: mtk-jpeg: refactor some variables\u0026quot;), otherwise\nthe below calltrace can be easily triggered.\n\n[ 677.862514] Unable to handle kernel paging request at virtual address dfff800000000023\n[ 677.863633] KASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f]\n...\n[ 677.879654] CPU: 6 PID: 1071 Comm: modprobe Tainted: G O 6.8.12-mtk+gfa1a78e5d24b+ #17\n...\n[ 677.882838] pc : destroy_workqueue+0x3c/0x770\n[ 677.883413] lr : mtk_jpegdec_destroy_workqueue+0x70/0x88 [mtk_jpeg_dec_hw]\n[ 677.884314] sp : ffff80008ad974f0\n[ 677.884744] x29: ffff80008ad974f0 x28: ffff0000d7115580 x27: ffff0000dd691070\n[ 677.885669] x26: ffff0000dd691408 x25: ffff8000844af3e0 x24: ffff80008ad97690\n[ 677.886592] x23: ffff0000e051d400 x22: ffff0000dd691010 x21: dfff800000000000\n[ 677.887515] x20: 0000000000000000 x19: 0000000000000000 x18: ffff800085397ac0\n[ 677.888438] x17: 0000000000000000 x16: ffff8000801b87c8 x15: 1ffff000115b2e10\n[ 677.889361] x14: 00000000f1f1f1f1 x13: 0000000000000000 x12: ffff7000115b2e4d\n[ 677.890285] x11: 1ffff000115b2e4c x10: ffff7000115b2e4c x9 : ffff80000aa43e90\n[ 677.891208] x8 : 00008fffeea4d1b4 x7 : ffff80008ad97267 x6 : 0000000000000001\n[ 677.892131] x5 : ffff80008ad97260 x4 : ffff7000115b2e4d x3 : 0000000000000000\n[ 677.893054] x2 : 0000000000000023 x1 : dfff800000000000 x0 : 0000000000000118\n[ 677.893977] Call trace:\n[ 677.894297] destroy_workqueue+0x3c/0x770\n[ 677.894826] mtk_jpegdec_destroy_workqueue+0x70/0x88 [mtk_jpeg_dec_hw]\n[ 677.895677] devm_action_release+0x50/0x90\n[ 677.896211] release_nodes+0xe8/0x170\n[ 677.896688] devres_release_all+0xf8/0x178\n[ 677.897219] device_unbind_cleanup+0x24/0x170\n[ 677.897785] device_release_driver_internal+0x35c/0x480\n[ 677.898461] device_release_driver+0x20/0x38\n...\n[ 677.912665] ---[ end trace 0000000000000000 ]---(CVE-2024-56577)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: amphion: Set video drvdata before register video device\n\nThe video drvdata should be set before the video device is registered,\notherwise video_drvdata() may return NULL in the open() file ops, and led\nto oops.(CVE-2024-56579)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nleds: class: Protect brightness_show() with led_cdev-\u0026gt;led_access mutex\n\nThere is NULL pointer issue observed if from Process A where hid device\nbeing added which results in adding a led_cdev addition and later a\nanother call to access of led_cdev attribute from Process B can result\nin NULL pointer issue.\n\nUse mutex led_cdev-\u0026gt;led_access to protect access to led-\u0026gt;cdev and its\nattribute inside brightness_show() and max_brightness_show() and also\nupdate the comment for mutex that it should be used to protect the led\nclass device fields.\n\n\tProcess A \t\t\t\tProcess B\n\n kthread+0x114\n worker_thread+0x244\n process_scheduled_works+0x248\n uhid_device_add_worker+0x24\n hid_add_device+0x120\n device_add+0x268\n bus_probe_device+0x94\n device_initial_probe+0x14\n __device_attach+0xfc\n bus_for_each_drv+0x10c\n __device_attach_driver+0x14c\n driver_probe_device+0x3c\n __driver_probe_device+0xa0\n really_probe+0x190\n hid_device_probe+0x130\n ps_probe+0x990\n ps_led_register+0x94\n devm_led_classdev_register_ext+0x58\n led_classdev_register_ext+0x1f8\n device_create_with_groups+0x48\n device_create_groups_vargs+0xc8\n device_add+0x244\n kobject_uevent+0x14\n kobject_uevent_env[jt]+0x224\n mutex_unlock[jt]+0xc4\n __mutex_unlock_slowpath+0xd4\n wake_up_q+0x70\n try_to_wake_up[jt]+0x48c\n preempt_schedule_common+0x28\n __schedule+0x628\n __switch_to+0x174\n\t\t\t\t\t\tel0t_64_sync+0x1a8/0x1ac\n\t\t\t\t\t\tel0t_64_sync_handler+0x68/0xbc\n\t\t\t\t\t\tel0_svc+0x38/0x68\n\t\t\t\t\t\tdo_el0_svc+0x1c/0x28\n\t\t\t\t\t\tel0_svc_common+0x80/0xe0\n\t\t\t\t\t\tinvoke_syscall+0x58/0x114\n\t\t\t\t\t\t__arm64_sys_read+0x1c/0x2c\n\t\t\t\t\t\tksys_read+0x78/0xe8\n\t\t\t\t\t\tvfs_read+0x1e0/0x2c8\n\t\t\t\t\t\tkernfs_fop_read_iter+0x68/0x1b4\n\t\t\t\t\t\tseq_read_iter+0x158/0x4ec\n\t\t\t\t\t\tkernfs_seq_show+0x44/0x54\n\t\t\t\t\t\tsysfs_kf_seq_show+0xb4/0x130\n\t\t\t\t\t\tdev_attr_show+0x38/0x74\n\t\t\t\t\t\tbrightness_show+0x20/0x4c\n\t\t\t\t\t\tdualshock4_led_get_brightness+0xc/0x74\n\n[ 3313.874295][ T4013] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000060\n[ 3313.874301][ T4013] Mem abort info:\n[ 3313.874303][ T4013] ESR = 0x0000000096000006\n[ 3313.874305][ T4013] EC = 0x25: DABT (current EL), IL = 32 bits\n[ 3313.874307][ T4013] SET = 0, FnV = 0\n[ 3313.874309][ T4013] EA = 0, S1PTW = 0\n[ 3313.874311][ T4013] FSC = 0x06: level 2 translation fault\n[ 3313.874313][ T4013] Data abort info:\n[ 3313.874314][ T4013] ISV = 0, ISS = 0x00000006, ISS2 = 0x00000000\n[ 3313.874316][ T4013] CM = 0, WnR = 0, TnD = 0, TagAccess = 0\n[ 3313.874318][ T4013] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\n[ 3313.874320][ T4013] user pgtable: 4k pages, 39-bit VAs, pgdp=00000008f2b0a000\n..\n\n[ 3313.874332][ T4013] Dumping ftrace buffer:\n[ 3313.874334][ T4013] (ftrace buffer empty)\n..\n..\n[ dd3313.874639][ T4013] CPU: 6 PID: 4013 Comm: InputReader\n[ 3313.874648][ T4013] pc : dualshock4_led_get_brightness+0xc/0x74\n[ 3313.874653][ T4013] lr : led_update_brightness+0x38/0x60\n[ 3313.874656][ T4013] sp : ffffffc0b910bbd0\n..\n..\n[ 3313.874685][ T4013] Call trace:\n[ 3313.874687][ T4013] dualshock4_led_get_brightness+0xc/0x74\n[ 3313.874690][ T4013] brightness_show+0x20/0x4c\n[ 3313.874692][ T4013] dev_attr_show+0x38/0x74\n[ 3313.874696][ T4013] sysfs_kf_seq_show+0xb4/0x130\n[ 3313.874700][ T4013] kernfs_seq_show+0x44/0x54\n[ 3313.874703][ T4013] seq_read_iter+0x158/0x4ec\n[ 3313.874705][ T4013] kernfs_fop_read_iter+0x68/0x1b4\n[ 3313.874708][ T4013] vfs_read+0x1e0/0x2c8\n[ 3313.874711][ T4013] ksys_read+0x78/0xe8\n[ 3313.874714][ T4013] __arm64_sys_read+0x1c/0x2c\n[ 3313.874718][ T4013] invoke_syscall+0x58/0x114\n[ 3313.874721][ T4013] el0_svc_common+0x80/0xe0\n[ 3313.874724][ T4013] do_el0_svc+0x1c/0x28\n[ 3313.874727][ T4013] el0_svc+0x38/0x68\n[ 3313.874730][ T4013] el0t_64_sync_handler+0x68/0xbc\n[ 3313.874732][ T4013] el0t_64_sync+0x1a8/0x1ac(CVE-2024-56587)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: brcmfmac: Fix oops due to NULL pointer dereference in brcmf_sdiod_sglist_rw()\n\nThis patch fixes a NULL pointer dereference bug in brcmfmac that occurs\nwhen a high \u0026apos;sd_sgentry_align\u0026apos; value applies (e.g. 512) and a lot of queued SKBs\nare sent from the pkt queue.\n\nThe problem is the number of entries in the pre-allocated sgtable, it is\nnents = max(rxglom_size, txglom_size) + max(rxglom_size, txglom_size) \u0026gt;\u0026gt; 4 + 1.\nGiven the default [rt]xglom_size=32 it\u0026apos;s actually 35 which is too small.\nWorst case, the pkt queue can end up with 64 SKBs. This occurs when a new SKB\nis added for each original SKB if tailroom isn\u0026apos;t enough to hold tail_pad.\nAt least one sg entry is needed for each SKB. So, eventually the \u0026quot;skb_queue_walk loop\u0026quot;\nin brcmf_sdiod_sglist_rw may run out of sg entries. This makes sg_next return\nNULL and this causes the oops.\n\nThe patch sets nents to max(rxglom_size, txglom_size) * 2 to be able handle\nthe worst-case.\nBtw. this requires only 64-35=29 * 16 (or 20 if CONFIG_NEED_SG_DMA_LENGTH) = 464\nadditional bytes of memory.(CVE-2024-56593)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: inet6: do not leave a dangling sk pointer in inet6_create()\n\nsock_init_data() attaches the allocated sk pointer to the provided sock\nobject. If inet6_create() fails later, the sk object is released, but the\nsock object retains the dangling sk pointer, which may cause use-after-free\nlater.\n\nClear the sock sk pointer on error.(CVE-2024-56600)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: inet: do not leave a dangling sk pointer in inet_create()\n\nsock_init_data() attaches the allocated sk object to the provided sock\nobject. If inet_create() fails later, the sk object is freed, but the\nsock object retains the dangling pointer, which may create use-after-free\nlater.\n\nClear the sk pointer in the sock object on error.(CVE-2024-56601)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: ieee802154: do not leave a dangling sk pointer in ieee802154_create()\n\nsock_init_data() attaches the allocated sk object to the provided sock\nobject. If ieee802154_create() fails later, the allocated sk object is\nfreed, but the dangling pointer remains in the provided sock object, which\nmay allow use-after-free.\n\nClear the sk pointer in the sock object on error.(CVE-2024-56602)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: af_can: do not leave a dangling sk pointer in can_create()\n\nOn error can_create() frees the allocated sk object, but sock_init_data()\nhas already attached it to the provided sock object. This will leave a\ndangling sk pointer in the sock object and may cause use-after-free later.(CVE-2024-56603)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\naf_packet: avoid erroring out after sock_init_data() in packet_create()\n\nAfter sock_init_data() the allocated sk object is attached to the provided\nsock object. On error, packet_create() frees the sk object leaving the\ndangling pointer in the sock object on return. Some other code may try\nto use this pointer and cause use-after-free.(CVE-2024-56606)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncan: dev: can_set_termination(): allow sleeping GPIOs\n\nIn commit 6e86a1543c37 (\u0026quot;can: dev: provide optional GPIO based\ntermination support\u0026quot;) GPIO based termination support was added.\n\nFor no particular reason that patch uses gpiod_set_value() to set the\nGPIO. This leads to the following warning, if the systems uses a\nsleeping GPIO, i.e. behind an I2C port expander:\n\n| WARNING: CPU: 0 PID: 379 at /drivers/gpio/gpiolib.c:3496 gpiod_set_value+0x50/0x6c\n| CPU: 0 UID: 0 PID: 379 Comm: ip Not tainted 6.11.0-20241016-1 #1 823affae360cc91126e4d316d7a614a8bf86236c\n\nReplace gpiod_set_value() by gpiod_set_value_cansleep() to allow the\nuse of sleeping GPIOs.(CVE-2024-56625)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nLoongArch: Add architecture specific huge_pte_clear()\n\nWhen executing mm selftests run_vmtests.sh, there is such an error:\n\n BUG: Bad page state in process uffd-unit-tests pfn:00000\n page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x0\n flags: 0xffff0000002000(reserved|node=0|zone=0|lastcpupid=0xffff)\n raw: 00ffff0000002000 ffffbf0000000008 ffffbf0000000008 0000000000000000\n raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000\n page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set\n Modules linked in: snd_seq_dummy snd_seq snd_seq_device rfkill vfat fat\n virtio_balloon efi_pstore virtio_net pstore net_failover failover fuse\n nfnetlink virtio_scsi virtio_gpu virtio_dma_buf dm_multipath efivarfs\n CPU: 2 UID: 0 PID: 1913 Comm: uffd-unit-tests Not tainted 6.12.0 #184\n Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 2/2/2022\n Stack : 900000047c8ac000 0000000000000000 9000000000223a7c 900000047c8ac000\n 900000047c8af690 900000047c8af698 0000000000000000 900000047c8af7d8\n 900000047c8af7d0 900000047c8af7d0 900000047c8af5b0 0000000000000001\n 0000000000000001 900000047c8af698 10b3c7d53da40d26 0000010000000000\n 0000000000000022 0000000fffffffff fffffffffe000000 ffff800000000000\n 000000000000002f 0000800000000000 000000017a6d4000 90000000028f8940\n 0000000000000000 0000000000000000 90000000025aa5e0 9000000002905000\n 0000000000000000 90000000028f8940 ffff800000000000 0000000000000000\n 0000000000000000 0000000000000000 9000000000223a94 000000012001839c\n 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1d\n ...\n Call Trace:\n [\u0026lt;9000000000223a94\u0026gt;] show_stack+0x5c/0x180\n [\u0026lt;9000000001c3fd64\u0026gt;] dump_stack_lvl+0x6c/0xa0\n [\u0026lt;900000000056aa08\u0026gt;] bad_page+0x1a0/0x1f0\n [\u0026lt;9000000000574978\u0026gt;] free_unref_folios+0xbf0/0xd20\n [\u0026lt;90000000004e65cc\u0026gt;] folios_put_refs+0x1a4/0x2b8\n [\u0026lt;9000000000599a0c\u0026gt;] free_pages_and_swap_cache+0x164/0x260\n [\u0026lt;9000000000547698\u0026gt;] tlb_batch_pages_flush+0xa8/0x1c0\n [\u0026lt;9000000000547f30\u0026gt;] tlb_finish_mmu+0xa8/0x218\n [\u0026lt;9000000000543cb8\u0026gt;] exit_mmap+0x1a0/0x360\n [\u0026lt;9000000000247658\u0026gt;] __mmput+0x78/0x200\n [\u0026lt;900000000025583c\u0026gt;] do_exit+0x43c/0xde8\n [\u0026lt;9000000000256490\u0026gt;] do_group_exit+0x68/0x110\n [\u0026lt;9000000000256554\u0026gt;] sys_exit_group+0x1c/0x20\n [\u0026lt;9000000001c413b4\u0026gt;] do_syscall+0x94/0x130\n [\u0026lt;90000000002216d8\u0026gt;] handle_syscall+0xb8/0x158\n Disabling lock debugging due to kernel taint\n BUG: non-zero pgtables_bytes on freeing mm: -16384\n\nOn LoongArch system, invalid huge pte entry should be invalid_pte_table\nor a single _PAGE_HUGE bit rather than a zero value. And it should be\nthe same with invalid pmd entry, since pmd_none() is called by function\nfree_pgd_range() and pmd_none() return 0 by huge_pte_clear(). So single\n_PAGE_HUGE bit is also treated as a valid pte table and free_pte_range()\nwill be called in free_pmd_range().\n\n free_pmd_range()\n pmd = pmd_offset(pud, addr);\n do {\n next = pmd_addr_end(addr, end);\n if (pmd_none_or_clear_bad(pmd))\n continue;\n free_pte_range(tlb, pmd, addr);\n } while (pmd++, addr = next, addr != end);\n\nHere invalid_pte_table is used for both invalid huge pte entry and\npmd entry.(CVE-2024-56628)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ngeneve: do not assume mac header is set in geneve_xmit_skb()\n\nWe should not assume mac header is set in output path.\n\nUse skb_eth_hdr() instead of eth_hdr() to fix the issue.\n\nsysbot reported the following :\n\n WARNING: CPU: 0 PID: 11635 at include/linux/skbuff.h:3052 skb_mac_header include/linux/skbuff.h:3052 [inline]\n WARNING: CPU: 0 PID: 11635 at include/linux/skbuff.h:3052 eth_hdr include/linux/if_ether.h:24 [inline]\n WARNING: CPU: 0 PID: 11635 at include/linux/skbuff.h:3052 geneve_xmit_skb drivers/net/geneve.c:898 [inline]\n WARNING: CPU: 0 PID: 11635 at include/linux/skbuff.h:3052 geneve_xmit+0x4c38/0x5730 drivers/net/geneve.c:1039\nModules linked in:\nCPU: 0 UID: 0 PID: 11635 Comm: syz.4.1423 Not tainted 6.12.0-syzkaller-10296-gaaf20f870da0 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024\n RIP: 0010:skb_mac_header include/linux/skbuff.h:3052 [inline]\n RIP: 0010:eth_hdr include/linux/if_ether.h:24 [inline]\n RIP: 0010:geneve_xmit_skb drivers/net/geneve.c:898 [inline]\n RIP: 0010:geneve_xmit+0x4c38/0x5730 drivers/net/geneve.c:1039\nCode: 21 c6 02 e9 35 d4 ff ff e8 a5 48 4c fb 90 0f 0b 90 e9 fd f5 ff ff e8 97 48 4c fb 90 0f 0b 90 e9 d8 f5 ff ff e8 89 48 4c fb 90 \u0026lt;0f\u0026gt; 0b 90 e9 41 e4 ff ff e8 7b 48 4c fb 90 0f 0b 90 e9 cd e7 ff ff\nRSP: 0018:ffffc90003b2f870 EFLAGS: 00010283\nRAX: 000000000000037a RBX: 000000000000ffff RCX: ffffc9000dc3d000\nRDX: 0000000000080000 RSI: ffffffff86428417 RDI: 0000000000000003\nRBP: ffffc90003b2f9f0 R08: 0000000000000003 R09: 000000000000ffff\nR10: 000000000000ffff R11: 0000000000000002 R12: ffff88806603c000\nR13: 0000000000000000 R14: ffff8880685b2780 R15: 0000000000000e23\nFS: 00007fdc2deed6c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000001b30a1dff8 CR3: 0000000056b8c000 CR4: 00000000003526f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __netdev_start_xmit include/linux/netdevice.h:5002 [inline]\n netdev_start_xmit include/linux/netdevice.h:5011 [inline]\n __dev_direct_xmit+0x58a/0x720 net/core/dev.c:4490\n dev_direct_xmit include/linux/netdevice.h:3181 [inline]\n packet_xmit+0x1e4/0x360 net/packet/af_packet.c:285\n packet_snd net/packet/af_packet.c:3146 [inline]\n packet_sendmsg+0x2700/0x5660 net/packet/af_packet.c:3178\n sock_sendmsg_nosec net/socket.c:711 [inline]\n __sock_sendmsg net/socket.c:726 [inline]\n __sys_sendto+0x488/0x4f0 net/socket.c:2197\n __do_sys_sendto net/socket.c:2204 [inline]\n __se_sys_sendto net/socket.c:2200 [inline]\n __x64_sys_sendto+0xe0/0x1c0 net/socket.c:2200\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2024-56636)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: ipset: Hold module reference while requesting a module\n\nUser space may unload ip_set.ko while it is itself requesting a set type\nbackend module, leading to a kernel crash. The race condition may be\nprovoked by inserting an mdelay() right after the nfnl_unlock() call.(CVE-2024-56637)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndccp: Fix memory leak in dccp_feat_change_recv\n\nIf dccp_feat_push_confirm() fails after new value for SP feature was accepted\nwithout reconciliation (\u0026apos;entry == NULL\u0026apos; branch), memory allocated for that value\nwith dccp_feat_clone_sp_val() is never freed.\n\nHere is the kmemleak stack for this:\n\nunreferenced object 0xffff88801d4ab488 (size 8):\n comm \u0026quot;syz-executor310\u0026quot;, pid 1127, jiffies 4295085598 (age 41.666s)\n hex dump (first 8 bytes):\n 01 b4 4a 1d 80 88 ff ff ..J.....\n backtrace:\n [\u0026lt;00000000db7cabfe\u0026gt;] kmemdup+0x23/0x50 mm/util.c:128\n [\u0026lt;0000000019b38405\u0026gt;] kmemdup include/linux/string.h:465 [inline]\n [\u0026lt;0000000019b38405\u0026gt;] dccp_feat_clone_sp_val net/dccp/feat.c:371 [inline]\n [\u0026lt;0000000019b38405\u0026gt;] dccp_feat_clone_sp_val net/dccp/feat.c:367 [inline]\n [\u0026lt;0000000019b38405\u0026gt;] dccp_feat_change_recv net/dccp/feat.c:1145 [inline]\n [\u0026lt;0000000019b38405\u0026gt;] dccp_feat_parse_options+0x1196/0x2180 net/dccp/feat.c:1416\n [\u0026lt;00000000b1f6d94a\u0026gt;] dccp_parse_options+0xa2a/0x1260 net/dccp/options.c:125\n [\u0026lt;0000000030d7b621\u0026gt;] dccp_rcv_state_process+0x197/0x13d0 net/dccp/input.c:650\n [\u0026lt;000000001f74c72e\u0026gt;] dccp_v4_do_rcv+0xf9/0x1a0 net/dccp/ipv4.c:688\n [\u0026lt;00000000a6c24128\u0026gt;] sk_backlog_rcv include/net/sock.h:1041 [inline]\n [\u0026lt;00000000a6c24128\u0026gt;] __release_sock+0x139/0x3b0 net/core/sock.c:2570\n [\u0026lt;00000000cf1f3a53\u0026gt;] release_sock+0x54/0x1b0 net/core/sock.c:3111\n [\u0026lt;000000008422fa23\u0026gt;] inet_wait_for_connect net/ipv4/af_inet.c:603 [inline]\n [\u0026lt;000000008422fa23\u0026gt;] __inet_stream_connect+0x5d0/0xf70 net/ipv4/af_inet.c:696\n [\u0026lt;0000000015b6f64d\u0026gt;] inet_stream_connect+0x53/0xa0 net/ipv4/af_inet.c:735\n [\u0026lt;0000000010122488\u0026gt;] __sys_connect_file+0x15c/0x1a0 net/socket.c:1865\n [\u0026lt;00000000b4b70023\u0026gt;] __sys_connect+0x165/0x1a0 net/socket.c:1882\n [\u0026lt;00000000f4cb3815\u0026gt;] __do_sys_connect net/socket.c:1892 [inline]\n [\u0026lt;00000000f4cb3815\u0026gt;] __se_sys_connect net/socket.c:1889 [inline]\n [\u0026lt;00000000f4cb3815\u0026gt;] __x64_sys_connect+0x6e/0xb0 net/socket.c:1889\n [\u0026lt;00000000e7b1e839\u0026gt;] do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46\n [\u0026lt;0000000055e91434\u0026gt;] entry_SYSCALL_64_after_hwframe+0x67/0xd1\n\nClean up the allocated memory in case of dccp_feat_push_confirm() failure\nand bail out with an error reset code.\n\nFound by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2024-56643)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/ipv6: release expired exception dst cached in socket\n\nDst objects get leaked in ip6_negative_advice() when this function is\nexecuted for an expired IPv6 route located in the exception table. There\nare several conditions that must be fulfilled for the leak to occur:\n* an ICMPv6 packet indicating a change of the MTU for the path is received,\n resulting in an exception dst being created\n* a TCP connection that uses the exception dst for routing packets must\n start timing out so that TCP begins retransmissions\n* after the exception dst expires, the FIB6 garbage collector must not run\n before TCP executes ip6_negative_advice() for the expired exception dst\n\nWhen TCP executes ip6_negative_advice() for an exception dst that has\nexpired and if no other socket holds a reference to the exception dst, the\nrefcount of the exception dst is 2, which corresponds to the increment\nmade by dst_init() and the increment made by the TCP socket for which the\nconnection is timing out. The refcount made by the socket is never\nreleased. The refcount of the dst is decremented in sk_dst_reset() but\nthat decrement is counteracted by a dst_hold() intentionally placed just\nbefore the sk_dst_reset() in ip6_negative_advice(). After\nip6_negative_advice() has finished, there is no other object tied to the\ndst. The socket lost its reference stored in sk_dst_cache and the dst is\nno longer in the exception table. The exception dst becomes a leaked\nobject.\n\nAs a result of this dst leak, an unbalanced refcount is reported for the\nloopback device of a net namespace being destroyed under kernels that do\nnot contain e5f80fcf869a (\u0026quot;ipv6: give an IPv6 dev to blackhole_netdev\u0026quot;):\nunregister_netdevice: waiting for lo to become free. Usage count = 2\n\nFix the dst leak by removing the dst_hold() in ip6_negative_advice(). The\npatch that introduced the dst_hold() in ip6_negative_advice() was\n92f1655aa2b22 (\u0026quot;net: fix __dst_negative_advice() race\u0026quot;). But 92f1655aa2b22\nmerely refactored the code with regards to the dst refcount so the issue\nwas present even before 92f1655aa2b22. The bug was introduced in\n54c1a859efd9f (\u0026quot;ipv6: Don\u0026apos;t drop cache route entry unless timer actually\nexpired.\u0026quot;) where the expired cached route is deleted and the sk_dst_cache\nmember of the socket is set to NULL by calling dst_negative_advice() but\nthe refcount belonging to the socket is left unbalanced.\n\nThe IPv4 version - ipv4_negative_advice() - is not affected by this bug.\nWhen the TCP connection times out ipv4_negative_advice() merely resets the\nsk_dst_cache of the socket while decrementing the refcount of the\nexception dst.(CVE-2024-56644)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncan: j1939: j1939_session_new(): fix skb reference counting\n\nSince j1939_session_skb_queue() does an extra skb_get() for each new\nskb, do the same for the initial one in j1939_session_new() to avoid\nrefcount underflow.\n\n[mkl: clean up commit message](CVE-2024-56645)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: x_tables: fix LED ID check in led_tg_check()\n\nSyzbot has reported the following BUG detected by KASAN:\n\nBUG: KASAN: slab-out-of-bounds in strlen+0x58/0x70\nRead of size 1 at addr ffff8881022da0c8 by task repro/5879\n...\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x241/0x360\n ? __pfx_dump_stack_lvl+0x10/0x10\n ? __pfx__printk+0x10/0x10\n ? _printk+0xd5/0x120\n ? __virt_addr_valid+0x183/0x530\n ? __virt_addr_valid+0x183/0x530\n print_report+0x169/0x550\n ? __virt_addr_valid+0x183/0x530\n ? __virt_addr_valid+0x183/0x530\n ? __virt_addr_valid+0x45f/0x530\n ? __phys_addr+0xba/0x170\n ? strlen+0x58/0x70\n kasan_report+0x143/0x180\n ? strlen+0x58/0x70\n strlen+0x58/0x70\n kstrdup+0x20/0x80\n led_tg_check+0x18b/0x3c0\n xt_check_target+0x3bb/0xa40\n ? __pfx_xt_check_target+0x10/0x10\n ? stack_depot_save_flags+0x6e4/0x830\n ? nft_target_init+0x174/0xc30\n nft_target_init+0x82d/0xc30\n ? __pfx_nft_target_init+0x10/0x10\n ? nf_tables_newrule+0x1609/0x2980\n ? nf_tables_newrule+0x1609/0x2980\n ? rcu_is_watching+0x15/0xb0\n ? nf_tables_newrule+0x1609/0x2980\n ? nf_tables_newrule+0x1609/0x2980\n ? __kmalloc_noprof+0x21a/0x400\n nf_tables_newrule+0x1860/0x2980\n ? __pfx_nf_tables_newrule+0x10/0x10\n ? __nla_parse+0x40/0x60\n nfnetlink_rcv+0x14e5/0x2ab0\n ? __pfx_validate_chain+0x10/0x10\n ? __pfx_nfnetlink_rcv+0x10/0x10\n ? __lock_acquire+0x1384/0x2050\n ? netlink_deliver_tap+0x2e/0x1b0\n ? __pfx_lock_release+0x10/0x10\n ? netlink_deliver_tap+0x2e/0x1b0\n netlink_unicast+0x7f8/0x990\n ? __pfx_netlink_unicast+0x10/0x10\n ? __virt_addr_valid+0x183/0x530\n ? __check_object_size+0x48e/0x900\n netlink_sendmsg+0x8e4/0xcb0\n ? __pfx_netlink_sendmsg+0x10/0x10\n ? aa_sock_msg_perm+0x91/0x160\n ? __pfx_netlink_sendmsg+0x10/0x10\n __sock_sendmsg+0x223/0x270\n ____sys_sendmsg+0x52a/0x7e0\n ? __pfx_____sys_sendmsg+0x10/0x10\n __sys_sendmsg+0x292/0x380\n ? __pfx___sys_sendmsg+0x10/0x10\n ? lockdep_hardirqs_on_prepare+0x43d/0x780\n ? __pfx_lockdep_hardirqs_on_prepare+0x10/0x10\n ? exc_page_fault+0x590/0x8c0\n ? do_syscall_64+0xb6/0x230\n do_syscall_64+0xf3/0x230\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n...\n \u0026lt;/TASK\u0026gt;\n\nSince an invalid (without \u0026apos;\\0\u0026apos; byte at all) byte sequence may be passed\nfrom userspace, add an extra check to ensure that such a sequence is\nrejected as possible ID and so never passed to \u0026apos;kstrdup()\u0026apos; and further.(CVE-2024-56650)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncan: hi311x: hi3110_can_ist(): fix potential use-after-free\n\nThe commit a22bd630cfff (\u0026quot;can: hi311x: do not report txerr and rxerr\nduring bus-off\u0026quot;) removed the reporting of rxerr and txerr even in case\nof correct operation (i. e. not bus-off).\n\nThe error count information added to the CAN frame after netif_rx() is\na potential use after free, since there is no guarantee that the skb\nis in the same state. It might be freed or reused.\n\nFix the issue by postponing the netif_rx() call in case of txerr and\nrxerr reporting.(CVE-2024-56651)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/mm/fault: Fix kfence page fault reporting\n\ncopy_from_kernel_nofault() can be called when doing read of /proc/kcore.\n/proc/kcore can have some unmapped kfence objects which when read via\ncopy_from_kernel_nofault() can cause page faults. Since *_nofault()\nfunctions define their own fixup table for handling fault, use that\ninstead of asking kfence to handle such faults.\n\nHence we search the exception tables for the nip which generated the\nfault. If there is an entry then we let the fixup table handler handle the\npage fault by returning an error from within ___do_page_fault().\n\nThis can be easily triggered if someone tries to do dd from /proc/kcore.\neg. dd if=/proc/kcore of=/dev/null bs=1M\n\nSome example false negatives:\n\n ===============================\n BUG: KFENCE: invalid read in copy_from_kernel_nofault+0x9c/0x1a0\n Invalid read at 0xc0000000fdff0000:\n copy_from_kernel_nofault+0x9c/0x1a0\n 0xc00000000665f950\n read_kcore_iter+0x57c/0xa04\n proc_reg_read_iter+0xe4/0x16c\n vfs_read+0x320/0x3ec\n ksys_read+0x90/0x154\n system_call_exception+0x120/0x310\n system_call_vectored_common+0x15c/0x2ec\n\n BUG: KFENCE: use-after-free read in copy_from_kernel_nofault+0x9c/0x1a0\n Use-after-free read at 0xc0000000fe050000 (in kfence-#2):\n copy_from_kernel_nofault+0x9c/0x1a0\n 0xc00000000665f950\n read_kcore_iter+0x57c/0xa04\n proc_reg_read_iter+0xe4/0x16c\n vfs_read+0x320/0x3ec\n ksys_read+0x90/0x154\n system_call_exception+0x120/0x310\n system_call_vectored_common+0x15c/0x2ec(CVE-2024-56678)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nPCI: endpoint: epf-mhi: Avoid NULL dereference if DT lacks \u0026apos;mmio\u0026apos;\n\nIf platform_get_resource_byname() fails and returns NULL because DT lacks\nan \u0026apos;mmio\u0026apos; property for the MHI endpoint, dereferencing res-\u0026gt;start will\ncause a NULL pointer access. Add a check to prevent it.\n\n[kwilczynski: error message update per the review feedback]\n[bhelgaas: commit log](CVE-2024-56689)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\n9p/xen: fix release of IRQ\n\nKernel logs indicate an IRQ was double-freed.\n\nPass correct device ID during IRQ release.\n\n[Dominique: remove confusing variable reset to 0](CVE-2024-56704)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nocteontx2-pf: handle otx2_mbox_get_rsp errors in otx2_dmac_flt.c\n\nAdd error pointer checks after calling otx2_mbox_get_rsp().(CVE-2024-56707)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmfd: intel_soc_pmic_bxtwc: Use IRQ domain for PMIC devices\n\nWhile design wise the idea of converting the driver to use\nthe hierarchy of the IRQ chips is correct, the implementation\nhas (inherited) flaws. This was unveiled when platform_get_irq()\nhad started WARN() on IRQ 0 that is supposed to be a Linux\nIRQ number (also known as vIRQ).\n\nRework the driver to respect IRQ domain when creating each MFD\ndevice separately, as the domain is not the same for all of them.(CVE-2024-56723)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmfd: intel_soc_pmic_bxtwc: Use IRQ domain for TMU device\n\nWhile design wise the idea of converting the driver to use\nthe hierarchy of the IRQ chips is correct, the implementation\nhas (inherited) flaws. This was unveiled when platform_get_irq()\nhad started WARN() on IRQ 0 that is supposed to be a Linux\nIRQ number (also known as vIRQ).\n\nRework the driver to respect IRQ domain when creating each MFD\ndevice separately, as the domain is not the same for all of them.(CVE-2024-56724)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nocteontx2-pf: handle otx2_mbox_get_rsp errors in otx2_dcbnl.c\n\nAdd error pointer check after calling otx2_mbox_get_rsp().(CVE-2024-56725)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nocteontx2-pf: handle otx2_mbox_get_rsp errors in otx2_flows.c\n\nAdding error pointer check after calling otx2_mbox_get_rsp().(CVE-2024-56727)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfbdev: sh7760fb: Fix a possible memory leak in sh7760fb_alloc_mem()\n\nWhen information such as info-\u0026gt;screen_base is not ready, calling\nsh7760fb_free_mem() does not release memory correctly. Call\ndma_free_coherent() instead.(CVE-2024-56746)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: release nexthop on device removal\n\nThe CI is hitting some aperiodic hangup at device removal time in the\npmtu.sh self-test:\n\nunregister_netdevice: waiting for veth_A-R1 to become free. Usage count = 6\nref_tracker: veth_A-R1@ffff888013df15d8 has 1/5 users at\n\tdst_init+0x84/0x4a0\n\tdst_alloc+0x97/0x150\n\tip6_dst_alloc+0x23/0x90\n\tip6_rt_pcpu_alloc+0x1e6/0x520\n\tip6_pol_route+0x56f/0x840\n\tfib6_rule_lookup+0x334/0x630\n\tip6_route_output_flags+0x259/0x480\n\tip6_dst_lookup_tail.constprop.0+0x5c2/0x940\n\tip6_dst_lookup_flow+0x88/0x190\n\tudp_tunnel6_dst_lookup+0x2a7/0x4c0\n\tvxlan_xmit_one+0xbde/0x4a50 [vxlan]\n\tvxlan_xmit+0x9ad/0xf20 [vxlan]\n\tdev_hard_start_xmit+0x10e/0x360\n\t__dev_queue_xmit+0xf95/0x18c0\n\tarp_solicit+0x4a2/0xe00\n\tneigh_probe+0xaa/0xf0\n\nWhile the first suspect is the dst_cache, explicitly tracking the dst\nowing the last device reference via probes proved such dst is held by\nthe nexthop in the originating fib6_info.\n\nSimilar to commit f5b51fe804ec (\u0026quot;ipv6: route: purge exception on\nremoval\u0026quot;), we need to explicitly release the originating fib info when\ndisconnecting a to-be-removed device from a live ipv6 dst: move the\nfib6_info cleanup into ip6_dst_ifdown().\n\nTested running:\n\n./pmtu.sh cleanup_ipv6_exception\n\nin a tight loop for more than 400 iterations with no spat, running an\nunpatched kernel I observed a splat every ~10 iterations.(CVE-2024-56751)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: caam - Fix the pointer passed to caam_qi_shutdown()\n\nThe type of the last parameter given to devm_add_action_or_reset() is\n\u0026quot;struct caam_drv_private *\u0026quot;, but in caam_qi_shutdown(), it is casted to\n\u0026quot;struct device *\u0026quot;.\n\nPass the correct parameter to devm_add_action_or_reset() so that the\nresources are released as expected.(CVE-2024-56754)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: add a sanity check for btrfs root in btrfs_search_slot()\n\nSyzbot reports a null-ptr-deref in btrfs_search_slot().\n\nThe reproducer is using rescue=ibadroots, and the extent tree root is\ncorrupted thus the extent tree is NULL.\n\nWhen scrub tries to search the extent tree to gather the needed extent\ninfo, btrfs_search_slot() doesn\u0026apos;t check if the target root is NULL or\nnot, resulting the null-ptr-deref.\n\nAdd sanity check for btrfs root before using it in btrfs_search_slot().(CVE-2024-56774)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nft_socket: remove WARN_ON_ONCE on maximum cgroup level\n\ncgroup maximum depth is INT_MAX by default, there is a cgroup toggle to\nrestrict this maximum depth to a more reasonable value not to harm\nperformance. Remove unnecessary WARN_ON_ONCE which is reachable from\nuserspace.(CVE-2024-56783)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nMIPS: Loongson64: DTS: Really fix PCIe port nodes for ls7a\n\nFix the dtc warnings:\n\n arch/mips/boot/dts/loongson/ls7a-pch.dtsi:68.16-416.5: Warning (interrupt_provider): /bus@10000000/pci@1a000000: \u0026apos;#interrupt-cells\u0026apos; found, but node is not an interrupt provider\n arch/mips/boot/dts/loongson/ls7a-pch.dtsi:68.16-416.5: Warning (interrupt_provider): /bus@10000000/pci@1a000000: \u0026apos;#interrupt-cells\u0026apos; found, but node is not an interrupt provider\n arch/mips/boot/dts/loongson/loongson64g_4core_ls7a.dtb: Warning (interrupt_map): Failed prerequisite \u0026apos;interrupt_provider\u0026apos;\n\nAnd a runtime warning introduced in commit 045b14ca5c36 (\u0026quot;of: WARN on\ndeprecated #address-cells/#size-cells handling\u0026quot;):\n\n WARNING: CPU: 0 PID: 1 at drivers/of/base.c:106 of_bus_n_addr_cells+0x9c/0xe0\n Missing \u0026apos;#address-cells\u0026apos; in /bus@10000000/pci@1a000000/pci_bridge@9,0\n\nThe fix is similar to commit d89a415ff8d5 (\u0026quot;MIPS: Loongson64: DTS: Fix PCIe\nport nodes for ls7a\u0026quot;), which has fixed the issue for ls2k (despite its\nsubject mentions ls7a).(CVE-2024-56785)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ns390/entry: Mark IRQ entries to fix stack depot warnings\n\nThe stack depot filters out everything outside of the top interrupt\ncontext as an uninteresting or irrelevant part of the stack traces. This\nhelps with stack trace de-duplication, avoiding an explosion of saved\nstack traces that share the same IRQ context code path but originate\nfrom different randomly interrupted points, eventually exhausting the\nstack depot.\n\nFiltering uses in_irqentry_text() to identify functions within the\n.irqentry.text and .softirqentry.text sections, which then become the\nlast stack trace entries being saved.\n\nWhile __do_softirq() is placed into the .softirqentry.text section by\ncommon code, populating .irqentry.text is architecture-specific.\n\nCurrently, the .irqentry.text section on s390 is empty, which prevents\nstack depot filtering and de-duplication and could result in warnings\nlike:\n\nStack depot reached limit capacity\nWARNING: CPU: 0 PID: 286113 at lib/stackdepot.c:252 depot_alloc_stack+0x39a/0x3c8\n\nwith PREEMPT and KASAN enabled.\n\nFix this by moving the IO/EXT interrupt handlers from .kprobes.text into\nthe .irqentry.text section and updating the kprobes blacklist to include\nthe .irqentry.text section.\n\nThis is done only for asynchronous interrupts and explicitly not for\nprogram checks, which are synchronous and where the context beyond the\nprogram check is important to preserve. Despite machine checks being\nsomewhat in between, they are extremely rare, and preserving context\nwhen possible is also of value.\n\nSVCs and Restart Interrupts are not relevant, one being always at the\nboundary to user space and the other being a one-time thing.\n\nIRQ entries filtering is also optionally used in ftrace function graph,\nwhere the same logic applies.(CVE-2024-57838)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/dp_mst: Fix resetting msg rx state after topology removal\n\nIf the MST topology is removed during the reception of an MST down reply\nor MST up request sideband message, the\ndrm_dp_mst_topology_mgr::up_req_recv/down_rep_recv states could be reset\nfrom one thread via drm_dp_mst_topology_mgr_set_mst(false), racing with\nthe reading/parsing of the message from another thread via\ndrm_dp_mst_handle_down_rep() or drm_dp_mst_handle_up_req(). The race is\npossible since the reader/parser doesn\u0026apos;t hold any lock while accessing\nthe reception state. This in turn can lead to a memory corruption in the\nreader/parser as described by commit bd2fccac61b4 (\u0026quot;drm/dp_mst: Fix MST\nsideband message body length check\u0026quot;).\n\nFix the above by resetting the message reception state if needed before\nreading/parsing a message. Another solution would be to hold the\ndrm_dp_mst_topology_mgr::lock for the whole duration of the message\nreception/parsing in drm_dp_mst_handle_down_rep() and\ndrm_dp_mst_handle_up_req(), however this would require a bigger change.\nSince the fix is also needed for stable, opting for the simpler solution\nin this patch.(CVE-2024-57876)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mac80211: fix mbss changed flags corruption on 32 bit systems\n\nOn 32-bit systems, the size of an unsigned long is 4 bytes,\nwhile a u64 is 8 bytes. Therefore, when using\nor_each_set_bit(bit, \u0026amp;bits, sizeof(changed) * BITS_PER_BYTE),\nthe code is incorrectly searching for a bit in a 32-bit\nvariable that is expected to be 64 bits in size,\nleading to incorrect bit finding.\n\nSolution: Ensure that the size of the bits variable is correctly\nadjusted for each architecture.\n\n Call Trace:\n ? show_regs+0x54/0x58\n ? __warn+0x6b/0xd4\n ? ieee80211_link_info_change_notify+0xcc/0xd4 [mac80211]\n ? report_bug+0x113/0x150\n ? exc_overflow+0x30/0x30\n ? handle_bug+0x27/0x44\n ? exc_invalid_op+0x18/0x50\n ? handle_exception+0xf6/0xf6\n ? exc_overflow+0x30/0x30\n ? ieee80211_link_info_change_notify+0xcc/0xd4 [mac80211]\n ? exc_overflow+0x30/0x30\n ? ieee80211_link_info_change_notify+0xcc/0xd4 [mac80211]\n ? ieee80211_mesh_work+0xff/0x260 [mac80211]\n ? cfg80211_wiphy_work+0x72/0x98 [cfg80211]\n ? process_one_work+0xf1/0x1fc\n ? worker_thread+0x2c0/0x3b4\n ? kthread+0xc7/0xf0\n ? mod_delayed_work_on+0x4c/0x4c\n ? kthread_complete_and_exit+0x14/0x14\n ? ret_from_fork+0x24/0x38\n ? kthread_complete_and_exit+0x14/0x14\n ? ret_from_fork_asm+0xf/0x14\n ? entry_INT80_32+0xf0/0xf0\n\n[restore no-op path for no changes](CVE-2024-57899)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: xhci: Fix NULL pointer dereference on certain command aborts\n\nIf a command is queued to the final usable TRB of a ring segment, the\nenqueue pointer is advanced to the subsequent link TRB and no further.\nIf the command is later aborted, when the abort completion is handled\nthe dequeue pointer is advanced to the first TRB of the next segment.\n\nIf no further commands are queued, xhci_handle_stopped_cmd_ring() sees\nthe ring pointers unequal and assumes that there is a pending command,\nso it calls xhci_mod_cmd_timer() which crashes if cur_cmd was NULL.\n\nDon\u0026apos;t attempt timer setup if cur_cmd is NULL. The subsequent doorbell\nring likely is unnecessary too, but it\u0026apos;s harmless. Leave it alone.\n\nThis is probably Bug 219532, but no confirmation has been received.\n\nThe issue has been independently reproduced and confirmed fixed using\na USB MCU programmed to NAK the Status stage of SET_ADDRESS forever.\nEverything continued working normally after several prevented crashes.(CVE-2024-57981)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nocfs2: handle a symlink read error correctly\n\nPatch series \u0026quot;Convert ocfs2 to use folios\u0026quot;.\n\nMark did a conversion of ocfs2 to use folios and sent it to me as a\ngiant patch for review ;-)\n\nSo I\u0026apos;ve redone it as individual patches, and credited Mark for the patches\nwhere his code is substantially the same. It\u0026apos;s not a bad way to do it;\nhis patch had some bugs and my patches had some bugs. Hopefully all our\nbugs were different from each other. And hopefully Mark likes all the\nchanges I made to his code!\n\n\nThis patch (of 23):\n\nIf we can\u0026apos;t read the buffer, be sure to unlock the page before returning.(CVE-2024-58001)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: bpf_local_storage: Always use bpf_mem_alloc in PREEMPT_RT\n\nIn PREEMPT_RT, kmalloc(GFP_ATOMIC) is still not safe in non preemptible\ncontext. bpf_mem_alloc must be used in PREEMPT_RT. This patch is\nto enforce bpf_mem_alloc in the bpf_local_storage when CONFIG_PREEMPT_RT\nis enabled.\n\n[ 35.118559] BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48\n[ 35.118566] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1832, name: test_progs\n[ 35.118569] preempt_count: 1, expected: 0\n[ 35.118571] RCU nest depth: 1, expected: 1\n[ 35.118577] INFO: lockdep is turned off.\n ...\n[ 35.118647] __might_resched+0x433/0x5b0\n[ 35.118677] rt_spin_lock+0xc3/0x290\n[ 35.118700] ___slab_alloc+0x72/0xc40\n[ 35.118723] __kmalloc_noprof+0x13f/0x4e0\n[ 35.118732] bpf_map_kzalloc+0xe5/0x220\n[ 35.118740] bpf_selem_alloc+0x1d2/0x7b0\n[ 35.118755] bpf_local_storage_update+0x2fa/0x8b0\n[ 35.118784] bpf_sk_storage_get_tracing+0x15a/0x1d0\n[ 35.118791] bpf_prog_9a118d86fca78ebb_trace_inet_sock_set_state+0x44/0x66\n[ 35.118795] bpf_trace_run3+0x222/0x400\n[ 35.118820] __bpf_trace_inet_sock_set_state+0x11/0x20\n[ 35.118824] trace_inet_sock_set_state+0x112/0x130\n[ 35.118830] inet_sk_state_store+0x41/0x90\n[ 35.118836] tcp_set_state+0x3b3/0x640\n\nThere is no need to adjust the gfp_flags passing to the\nbpf_mem_cache_alloc_flags() which only honors the GFP_KERNEL.\nThe verifier has ensured GFP_KERNEL is passed only in sleepable context.\n\nIt has been an old issue since the first introduction of the\nbpf_local_storage ~5 years ago, so this patch targets the bpf-next.\n\nbpf_mem_alloc is needed to solve it, so the Fixes tag is set\nto the commit when bpf_mem_alloc was first used in the bpf_local_storage.(CVE-2024-58070)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: rtw89: fix race between cancel_hw_scan and hw_scan completion\n\nThe rtwdev-\u0026gt;scanning flag isn\u0026apos;t protected by mutex originally, so\ncancel_hw_scan can pass the condition, but suddenly hw_scan completion\nunset the flag and calls ieee80211_scan_completed() that will free\nlocal-\u0026gt;hw_scan_req. Then, cancel_hw_scan raises null-ptr-deref and\nuse-after-free. Fix it by moving the check condition to where\nprotected by mutex.\n\n KASAN: null-ptr-deref in range [0x0000000000000088-0x000000000000008f]\n CPU: 2 PID: 6922 Comm: kworker/2:2 Tainted: G OE\n Hardware name: LENOVO 2356AD1/2356AD1, BIOS G7ETB6WW (2.76 ) 09/10/2019\n Workqueue: events cfg80211_conn_work [cfg80211]\n RIP: 0010:rtw89_fw_h2c_scan_offload_be+0xc33/0x13c3 [rtw89_core]\n Code: 00 45 89 6c 24 1c 0f 85 23 01 00 00 48 8b 85 20 ff ff ff 48 8d\n RSP: 0018:ffff88811fd9f068 EFLAGS: 00010206\n RAX: dffffc0000000000 RBX: ffff88811fd9f258 RCX: 0000000000000001\n RDX: 0000000000000011 RSI: 0000000000000001 RDI: 0000000000000089\n RBP: ffff88811fd9f170 R08: 0000000000000000 R09: 0000000000000000\n R10: ffff88811fd9f108 R11: 0000000000000000 R12: ffff88810e47f960\n R13: 0000000000000000 R14: 000000000000ffff R15: 0000000000000000\n FS: 0000000000000000(0000) GS:ffff8881d6f00000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00007531dfca55b0 CR3: 00000001be296004 CR4: 00000000001706e0\n Call Trace:\n \u0026lt;TASK\u0026gt;\n ? show_regs+0x61/0x73\n ? __die_body+0x20/0x73\n ? die_addr+0x4f/0x7b\n ? exc_general_protection+0x191/0x1db\n ? asm_exc_general_protection+0x27/0x30\n ? rtw89_fw_h2c_scan_offload_be+0xc33/0x13c3 [rtw89_core]\n ? rtw89_fw_h2c_scan_offload_be+0x458/0x13c3 [rtw89_core]\n ? __pfx_rtw89_fw_h2c_scan_offload_be+0x10/0x10 [rtw89_core]\n ? do_raw_spin_lock+0x75/0xdb\n ? __pfx_do_raw_spin_lock+0x10/0x10\n rtw89_hw_scan_offload+0xb5e/0xbf7 [rtw89_core]\n ? _raw_spin_unlock+0xe/0x24\n ? __mutex_lock.constprop.0+0x40c/0x471\n ? __pfx_rtw89_hw_scan_offload+0x10/0x10 [rtw89_core]\n ? __mutex_lock_slowpath+0x13/0x1f\n ? mutex_lock+0xa2/0xdc\n ? __pfx_mutex_lock+0x10/0x10\n rtw89_hw_scan_abort+0x58/0xb7 [rtw89_core]\n rtw89_ops_cancel_hw_scan+0x120/0x13b [rtw89_core]\n ieee80211_scan_cancel+0x468/0x4d0 [mac80211]\n ieee80211_prep_connection+0x858/0x899 [mac80211]\n ieee80211_mgd_auth+0xbea/0xdde [mac80211]\n ? __pfx_ieee80211_mgd_auth+0x10/0x10 [mac80211]\n ? cfg80211_find_elem+0x15/0x29 [cfg80211]\n ? is_bss+0x1b7/0x1d7 [cfg80211]\n ieee80211_auth+0x18/0x27 [mac80211]\n cfg80211_mlme_auth+0x3bb/0x3e7 [cfg80211]\n cfg80211_conn_do_work+0x410/0xb81 [cfg80211]\n ? __pfx_cfg80211_conn_do_work+0x10/0x10 [cfg80211]\n ? __kasan_check_read+0x11/0x1f\n ? psi_group_change+0x8bc/0x944\n ? __kasan_check_write+0x14/0x22\n ? mutex_lock+0x8e/0xdc\n ? __pfx_mutex_lock+0x10/0x10\n ? __pfx___radix_tree_lookup+0x10/0x10\n cfg80211_conn_work+0x245/0x34d [cfg80211]\n ? __pfx_cfg80211_conn_work+0x10/0x10 [cfg80211]\n ? update_cfs_rq_load_avg+0x3bc/0x3d7\n ? sched_clock_noinstr+0x9/0x1a\n ? sched_clock+0x10/0x24\n ? sched_clock_cpu+0x7e/0x42e\n ? newidle_balance+0x796/0x937\n ? __pfx_sched_clock_cpu+0x10/0x10\n ? __pfx_newidle_balance+0x10/0x10\n ? __kasan_check_read+0x11/0x1f\n ? psi_group_change+0x8bc/0x944\n ? _raw_spin_unlock+0xe/0x24\n ? raw_spin_rq_unlock+0x47/0x54\n ? raw_spin_rq_unlock_irq+0x9/0x1f\n ? finish_task_switch.isra.0+0x347/0x586\n ? __schedule+0x27bf/0x2892\n ? mutex_unlock+0x80/0xd0\n ? do_raw_spin_lock+0x75/0xdb\n ? __pfx___schedule+0x10/0x10\n process_scheduled_works+0x58c/0x821\n worker_thread+0x4c7/0x586\n ? __kasan_check_read+0x11/0x1f\n kthread+0x285/0x294\n ? __pfx_worker_thread+0x10/0x10\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x29/0x6f\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1b/0x30\n \u0026lt;/TASK\u0026gt;(CVE-2025-21729)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/mlx5: Fix a race for an ODP MR which leads to CQE with error\n\nThis patch addresses a race condition for an ODP MR that can result in a\nCQE with an error on the UMR QP.\n\nDuring the __mlx5_ib_dereg_mr() flow, the following sequence of calls\noccurs:\n\nmlx5_revoke_mr()\n mlx5r_umr_revoke_mr()\n mlx5r_umr_post_send_wait()\n\nAt this point, the lkey is freed from the hardware\u0026apos;s perspective.\n\nHowever, concurrently, mlx5_ib_invalidate_range() might be triggered by\nanother task attempting to invalidate a range for the same freed lkey.\n\nThis task will:\n - Acquire the umem_odp-\u0026gt;umem_mutex lock.\n - Call mlx5r_umr_update_xlt() on the UMR QP.\n - Since the lkey has already been freed, this can lead to a CQE error,\n causing the UMR QP to enter an error state [1].\n\nTo resolve this race condition, the umem_odp-\u0026gt;umem_mutex lock is now also\nacquired as part of the mlx5_revoke_mr() scope. Upon successful revoke,\nwe set umem_odp-\u0026gt;private which points to that MR to NULL, preventing any\nfurther invalidation attempts on its lkey.\n\n[1] From dmesg:\n\n infiniband rocep8s0f0: dump_cqe:277:(pid 0): WC error: 6, Message: memory bind operation error\n cqe_dump: 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n cqe_dump: 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n cqe_dump: 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n cqe_dump: 00000030: 00 00 00 00 08 00 78 06 25 00 11 b9 00 0e dd d2\n\n WARNING: CPU: 15 PID: 1506 at drivers/infiniband/hw/mlx5/umr.c:394 mlx5r_umr_post_send_wait+0x15a/0x2b0 [mlx5_ib]\n Modules linked in: ip6table_mangle ip6table_natip6table_filter ip6_tables iptable_mangle xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry overlay rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_umad ib_ipoib ib_cm mlx5_ib ib_uverbs ib_core fuse mlx5_core\n CPU: 15 UID: 0 PID: 1506 Comm: ibv_rc_pingpong Not tainted 6.12.0-rc7+ #1626\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\n RIP: 0010:mlx5r_umr_post_send_wait+0x15a/0x2b0 [mlx5_ib]\n [..]\n Call Trace:\n \u0026lt;TASK\u0026gt;\n mlx5r_umr_update_xlt+0x23c/0x3e0 [mlx5_ib]\n mlx5_ib_invalidate_range+0x2e1/0x330 [mlx5_ib]\n __mmu_notifier_invalidate_range_start+0x1e1/0x240\n zap_page_range_single+0xf1/0x1a0\n madvise_vma_behavior+0x677/0x6e0\n do_madvise+0x1a2/0x4b0\n __x64_sys_madvise+0x25/0x30\n do_syscall_64+0x6b/0x140\n entry_SYSCALL_64_after_hwframe+0x76/0x7e(CVE-2025-21732)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnilfs2: fix possible int overflows in nilfs_fiemap()\n\nSince nilfs_bmap_lookup_contig() in nilfs_fiemap() calculates its result\nby being prepared to go through potentially maxblocks == INT_MAX blocks,\nthe value in n may experience an overflow caused by left shift of blkbits.\n\nWhile it is extremely unlikely to occur, play it safe and cast right hand\nexpression to wider type to mitigate the issue.\n\nFound by Linux Verification Center (linuxtesting.org) with static analysis\ntool SVACE.(CVE-2025-21736)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusbnet: ipheth: fix possible overflow in DPE length check\n\nOriginally, it was possible for the DPE length check to overflow if\nwDatagramIndex + wDatagramLength \u0026gt; U16_MAX. This could lead to an OoB\nread.\n\nMove the wDatagramIndex term to the other side of the inequality.\n\nAn existing condition ensures that wDatagramIndex \u0026lt; urb-\u0026gt;actual_length.(CVE-2025-21743)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nclocksource: Use migrate_disable() to avoid calling get_random_u32() in atomic context\n\nThe following bug report happened with a PREEMPT_RT kernel:\n\n BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48\n in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 2012, name: kwatchdog\n preempt_count: 1, expected: 0\n RCU nest depth: 0, expected: 0\n get_random_u32+0x4f/0x110\n clocksource_verify_choose_cpus+0xab/0x1a0\n clocksource_verify_percpu.part.0+0x6b/0x330\n clocksource_watchdog_kthread+0x193/0x1a0\n\nIt is due to the fact that clocksource_verify_choose_cpus() is invoked with\npreemption disabled. This function invokes get_random_u32() to obtain\nrandom numbers for choosing CPUs. The batched_entropy_32 local lock and/or\nthe base_crng.lock spinlock in driver/char/random.c will be acquired during\nthe call. In PREEMPT_RT kernel, they are both sleeping locks and so cannot\nbe acquired in atomic context.\n\nFix this problem by using migrate_disable() to allow smp_processor_id() to\nbe reliably used without introducing atomic context. preempt_disable() is\nthen called after clocksource_verify_choose_cpus() but before the\nclocksource measurement is being run to avoid introducing unexpected\nlatency.(CVE-2025-21767)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nUSB: hub: Ignore non-compliant devices with too many configs or interfaces\n\nRobert Morris created a test program which can cause\nusb_hub_to_struct_hub() to dereference a NULL or inappropriate\npointer:\n\nOops: general protection fault, probably for non-canonical address\n0xcccccccccccccccc: 0000 [#1] SMP DEBUG_PAGEALLOC PTI\nCPU: 7 UID: 0 PID: 117 Comm: kworker/7:1 Not tainted 6.13.0-rc3-00017-gf44d154d6e3d #14\nHardware name: FreeBSD BHYVE/BHYVE, BIOS 14.0 10/17/2021\nWorkqueue: usb_hub_wq hub_event\nRIP: 0010:usb_hub_adjust_deviceremovable+0x78/0x110\n...\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? die_addr+0x31/0x80\n ? exc_general_protection+0x1b4/0x3c0\n ? asm_exc_general_protection+0x26/0x30\n ? usb_hub_adjust_deviceremovable+0x78/0x110\n hub_probe+0x7c7/0xab0\n usb_probe_interface+0x14b/0x350\n really_probe+0xd0/0x2d0\n ? __pfx___device_attach_driver+0x10/0x10\n __driver_probe_device+0x6e/0x110\n driver_probe_device+0x1a/0x90\n __device_attach_driver+0x7e/0xc0\n bus_for_each_drv+0x7f/0xd0\n __device_attach+0xaa/0x1a0\n bus_probe_device+0x8b/0xa0\n device_add+0x62e/0x810\n usb_set_configuration+0x65d/0x990\n usb_generic_driver_probe+0x4b/0x70\n usb_probe_device+0x36/0xd0\n\nThe cause of this error is that the device has two interfaces, and the\nhub driver binds to interface 1 instead of interface 0, which is where\nusb_hub_to_struct_hub() looks.\n\nWe can prevent the problem from occurring by refusing to accept hub\ndevices that violate the USB spec by having more than one\nconfiguration or interface.(CVE-2025-21776)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\norangefs: fix a oob in orangefs_debug_write\n\nI got a syzbot report: slab-out-of-bounds Read in\norangefs_debug_write... several people suggested fixes,\nI tested Al Viro\u0026apos;s suggestion and made this patch.(CVE-2025-21782)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ngpiolib: Fix crash on error in gpiochip_get_ngpios()\n\nThe gpiochip_get_ngpios() uses chip_*() macros to print messages.\nHowever these macros rely on gpiodev to be initialised and set,\nwhich is not the case when called via bgpio_init(). In such a case\nthe printing messages will crash on NULL pointer dereference.\nReplace chip_*() macros by the respective dev_*() ones to avoid\nsuch crash.(CVE-2025-21783)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nLoongArch: csum: Fix OoB access in IP checksum code for negative lengths\n\nCommit 69e3a6aa6be2 (\u0026quot;LoongArch: Add checksum optimization for 64-bit\nsystem\u0026quot;) would cause an undefined shift and an out-of-bounds read.\n\nCommit 8bd795fedb84 (\u0026quot;arm64: csum: Fix OoB access in IP checksum code\nfor negative lengths\u0026quot;) fixes the same issue on ARM64.(CVE-2025-21789)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFSD: fix hang in nfsd4_shutdown_callback\n\nIf nfs4_client is in courtesy state then there is no point to send\nthe callback. This causes nfsd4_shutdown_callback to hang since\ncl_cb_inflight is not 0. This hang lasts about 15 minutes until TCP\nnotifies NFSD that the connection was dropped.\n\nThis patch modifies nfsd4_run_cb_work to skip the RPC call if\nnfs4_client is in courtesy state.(CVE-2025-21795)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: clear acl_access/acl_default after releasing them\n\nIf getting acl_default fails, acl_access and acl_default will be released\nsimultaneously. However, acl_access will still retain a pointer pointing\nto the released posix_acl, which will trigger a WARNING in\nnfs3svc_release_getacl like this:\n\n------------[ cut here ]------------\nrefcount_t: underflow; use-after-free.\nWARNING: CPU: 26 PID: 3199 at lib/refcount.c:28\nrefcount_warn_saturate+0xb5/0x170\nModules linked in:\nCPU: 26 UID: 0 PID: 3199 Comm: nfsd Not tainted\n6.12.0-rc6-00079-g04ae226af01f-dirty #8\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS\n1.16.1-2.fc37 04/01/2014\nRIP: 0010:refcount_warn_saturate+0xb5/0x170\nCode: cc cc 0f b6 1d b3 20 a5 03 80 fb 01 0f 87 65 48 d8 00 83 e3 01 75\ne4 48 c7 c7 c0 3b 9b 85 c6 05 97 20 a5 03 01 e8 fb 3e 30 ff \u0026lt;0f\u0026gt; 0b eb\ncd 0f b6 1d 8a3\nRSP: 0018:ffffc90008637cd8 EFLAGS: 00010282\nRAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff83904fde\nRDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff88871ed36380\nRBP: ffff888158beeb40 R08: 0000000000000001 R09: fffff520010c6f56\nR10: ffffc90008637ab7 R11: 0000000000000001 R12: 0000000000000001\nR13: ffff888140e77400 R14: ffff888140e77408 R15: ffffffff858b42c0\nFS: 0000000000000000(0000) GS:ffff88871ed00000(0000)\nknlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000562384d32158 CR3: 000000055cc6a000 CR4: 00000000000006f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? refcount_warn_saturate+0xb5/0x170\n ? __warn+0xa5/0x140\n ? refcount_warn_saturate+0xb5/0x170\n ? report_bug+0x1b1/0x1e0\n ? handle_bug+0x53/0xa0\n ? exc_invalid_op+0x17/0x40\n ? asm_exc_invalid_op+0x1a/0x20\n ? tick_nohz_tick_stopped+0x1e/0x40\n ? refcount_warn_saturate+0xb5/0x170\n ? refcount_warn_saturate+0xb5/0x170\n nfs3svc_release_getacl+0xc9/0xe0\n svc_process_common+0x5db/0xb60\n ? __pfx_svc_process_common+0x10/0x10\n ? __rcu_read_unlock+0x69/0xa0\n ? __pfx_nfsd_dispatch+0x10/0x10\n ? svc_xprt_received+0xa1/0x120\n ? xdr_init_decode+0x11d/0x190\n svc_process+0x2a7/0x330\n svc_handle_xprt+0x69d/0x940\n svc_recv+0x180/0x2d0\n nfsd+0x168/0x200\n ? __pfx_nfsd+0x10/0x10\n kthread+0x1a2/0x1e0\n ? kthread+0xf4/0x1e0\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x34/0x60\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1a/0x30\n \u0026lt;/TASK\u0026gt;\nKernel panic - not syncing: kernel: panic_on_warn set ...\n\nClear acl_access/acl_default after posix_acl_release is called to prevent\nUAF from being triggered.(CVE-2025-21796)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nptp: Ensure info-\u0026gt;enable callback is always set\n\nThe ioctl and sysfs handlers unconditionally call the -\u0026gt;enable callback.\nNot all drivers implement that callback, leading to NULL dereferences.\nExample of affected drivers: ptp_s390.c, ptp_vclock.c and ptp_mock.c.\n\nInstead use a dummy callback if no better was specified by the driver.(CVE-2025-21814)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nblock: mark GFP_NOIO around sysfs -\u0026gt;store()\n\nsysfs -\u0026gt;store is called with queue freezed, meantime we have several\n-\u0026gt;store() callbacks(update_nr_requests, wbt, scheduler) to allocate\nmemory with GFP_KERNEL which may run into direct reclaim code path,\nthen potential deadlock can be caused.\n\nFix the issue by marking NOIO around sysfs -\u0026gt;store()(CVE-2025-21817)",
"id": "OESA-2025-1286",
"modified": "2026-08-06T11:08:23Z",
"published": "2025-03-14T11:08:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1286"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52926"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41935"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47143"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47809"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-48881"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53141"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53148"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53156"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53176"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53177"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53178"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53181"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53185"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53210"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53214"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53216"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53233"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-54456"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56531"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56533"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56539"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56545"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56551"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56558"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56566"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56573"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56574"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56576"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56577"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56579"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56587"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56593"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56600"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56601"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56602"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56603"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56606"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56625"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56628"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56636"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56637"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56643"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56644"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56645"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56650"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56651"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56678"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56689"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56704"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56707"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56723"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56724"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56725"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56727"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56746"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56751"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56754"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56774"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56783"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56785"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57838"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57876"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57899"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57981"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58001"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58070"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21729"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21732"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21736"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21743"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21767"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21776"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21782"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21783"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21789"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21795"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21796"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21814"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21817"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2023-52926",
"CVE-2024-41935",
"CVE-2024-47143",
"CVE-2024-47809",
"CVE-2024-48881",
"CVE-2024-53141",
"CVE-2024-53148",
"CVE-2024-53156",
"CVE-2024-53176",
"CVE-2024-53177",
"CVE-2024-53178",
"CVE-2024-53181",
"CVE-2024-53185",
"CVE-2024-53210",
"CVE-2024-53214",
"CVE-2024-53216",
"CVE-2024-53233",
"CVE-2024-54456",
"CVE-2024-56531",
"CVE-2024-56533",
"CVE-2024-56539",
"CVE-2024-56545",
"CVE-2024-56551",
"CVE-2024-56558",
"CVE-2024-56566",
"CVE-2024-56573",
"CVE-2024-56574",
"CVE-2024-56576",
"CVE-2024-56577",
"CVE-2024-56579",
"CVE-2024-56587",
"CVE-2024-56593",
"CVE-2024-56600",
"CVE-2024-56601",
"CVE-2024-56602",
"CVE-2024-56603",
"CVE-2024-56606",
"CVE-2024-56625",
"CVE-2024-56628",
"CVE-2024-56636",
"CVE-2024-56637",
"CVE-2024-56643",
"CVE-2024-56644",
"CVE-2024-56645",
"CVE-2024-56650",
"CVE-2024-56651",
"CVE-2024-56678",
"CVE-2024-56689",
"CVE-2024-56704",
"CVE-2024-56707",
"CVE-2024-56723",
"CVE-2024-56724",
"CVE-2024-56725",
"CVE-2024-56727",
"CVE-2024-56746",
"CVE-2024-56751",
"CVE-2024-56754",
"CVE-2024-56774",
"CVE-2024-56783",
"CVE-2024-56785",
"CVE-2024-57838",
"CVE-2024-57876",
"CVE-2024-57899",
"CVE-2024-57981",
"CVE-2024-58001",
"CVE-2024-58070",
"CVE-2025-21729",
"CVE-2025-21732",
"CVE-2025-21736",
"CVE-2025-21743",
"CVE-2025-21767",
"CVE-2025-21776",
"CVE-2025-21782",
"CVE-2025-21783",
"CVE-2025-21789",
"CVE-2025-21795",
"CVE-2025-21796",
"CVE-2025-21814",
"CVE-2025-21817"
]
}
OESA-2026-4039 (CVE-2024-56531)
Vulnerability from osv_openeuler – Published: 2026-09-25 01:27 – Updated: 2026-09-25 01:27 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:ALSA: caiaq: Use snd_card_free_when_closed() at disconnectionThe USB disconnect callback is supposed to be short and not too-longwaiting. OTOH, the current code uses snd_card_free() atdisconnection, but this waits for the close of all used fds, hence itcan take long. It eventually blocks the upper layer USB ioctls, whichmay trigger a soft lockup.An easy workaround is to replace snd_card_free() withsnd_card_free_when_closed(). This variant returns immediately whilethe release of resources is done asynchronously by the card devicerelease at the last close.This patch also splits the code to the disconnect and the free phases;the former is called immediately at the USB disconnect callback whilethe latter is called from the card destructor.(CVE-2024-56531)
In the Linux kernel, the following vulnerability has been resolved:xsk: fix OOB map writes when deleting elementsJordy says: In the xsk_map_delete_elem function an unsigned integer(map->max_entries) is compared with a user-controlled signed integer(k). Due to implicit type conversion, a large unsigned value formap->max_entries can bypass the intended bounds check: if (k >= map->max_entries) return -EINVAL;This allows k to hold a negative value (between -2147483648 and -2),which is then used as an array index in m->xsk_map[k], which resultsin an out-of-bounds access. spin_lock_bh(&m->lock); map_entry = &m->xsk_map[k]; // Out-of-bounds map_entry old_xs = unrcu_pointer(xchg(map_entry, NULL)); // Oob write if (old_xs) xsk_map_sock_delete(old_xs, map_entry); spin_unlock_bh(&m->lock);The xchg operation can then be used to cause an out-of-bounds write.Moreover, the invalid map_entry passed to xsk_map_sock_delete can leadto further memory corruption. It indeed results in following splat:[76612.897343] BUG: unable to handle page fault for address: ffffc8fc2e461108[76612.904330] #PF: supervisor write access in kernel mode[76612.909639] #PF: error_code(0x0002) - not-present page[76612.914855] PGD 0 P4D 0[76612.917431] Oops: Oops: 0002 [#1] PREEMPT SMP[76612.921859] CPU: 11 UID: 0 PID: 10318 Comm: a.out Not tainted 6.12.0-rc1+ #470[76612.929189] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019[76612.939781] RIP: 0010:xsk_map_delete_elem+0x2d/0x60[76612.944738] Code: 00 00 41 54 55 53 48 63 2e 3b 6f 24 73 38 4c 8d a7 f8 00 00 00 48 89 fb 4c 89 e7 e8 2d bf 05 00 48 8d b4 eb 00 01 00 00 31 ff <48> 87 3e 48 85 ff 74 05 e8 16 ff ff ff 4c 89 e7 e8 3e bc 05 00 31[76612.963774] RSP: 0018:ffffc9002e407df8 EFLAGS: 00010246[76612.969079] RAX: 0000000000000000 RBX: ffffc9002e461000 RCX: 0000000000000000[76612.976323] RDX: 0000000000000001 RSI: ffffc8fc2e461108 RDI: 0000000000000000[76612.983569] RBP: ffffffff80000001 R08: 0000000000000000 R09: 0000000000000007[76612.990812] R10: ffffc9002e407e18 R11: ffff888108a38858 R12: ffffc9002e4610f8[76612.998060] R13: ffff888108a38858 R14: 00007ffd1ae0ac78 R15: ffffc9002e4610c0[76613.005303] FS: 00007f80b6f59740(0000) GS:ffff8897e0ec0000(0000) knlGS:0000000000000000[76613.013517] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[76613.019349] CR2: ffffc8fc2e461108 CR3: 000000011e3ef001 CR4: 00000000007726f0[76613.026595] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[76613.033841] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400[76613.041086] PKRU: 55555554[76613.043842] Call Trace:[76613.046331] <TASK>[76613.048468] ? __die+0x20/0x60[76613.051581] ? page_fault_oops+0x15a/0x450[76613.055747] ? search_extable+0x22/0x30[76613.059649] ? search_bpf_extables+0x5f/0x80[76613.063988] ? exc_page_fault+0xa9/0x140[76613.067975] ? asm_exc_page_fault+0x22/0x30[76613.072229] ? xsk_map_delete_elem+0x2d/0x60[76613.076573] ? xsk_map_delete_elem+0x23/0x60[76613.080914] __sys_bpf+0x19b7/0x23c0[76613.084555] __x64_sys_bpf+0x1a/0x20[76613.088194] do_syscall_64+0x37/0xb0[76613.091832] entry_SYSCALL_64_after_hwframe+0x4b/0x53[76613.096962] RIP: 0033:0x7f80b6d1e88d[76613.100592] Code: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 73 b5 0f 00 f7 d8 64 89 01 48[76613.119631] RSP: 002b:00007ffd1ae0ac68 EFLAGS: 00000206 ORIG_RAX: 0000000000000141[76613.131330] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f80b6d1e88d[76613.142632] RDX: 0000000000000098 RSI: 00007ffd1ae0ad20 RDI: 0000000000000003[76613.153967] RBP: 00007ffd1ae0adc0 R08: 0000000000000000 R09: 0000000000000000[76613.166030] R10: 00007f80b6f77040 R11: 0000000000000206 R12: 00007ffd1ae0aed8[76613.177130] R13: 000055ddf42ce1e9 R14: 000055ddf42d0d98 R15: 00---truncated---(CVE-2024-56614)
In the Linux kernel, the following vulnerability has been resolved:
ALSA: usb-audio: Fix potential overflow of PCM transfer buffer
The PCM stream data in USB-audio driver is transferred over USB URB packet buffers, and each packet size is determined dynamically. The packet sizes are limited by some factors such as wMaxPacketSize USB descriptor. OTOH, in the current code, the actually used packet sizes are determined only by the rate and the PPS, which may be bigger than the size limit above. This results in a buffer overflow, as reported by syzbot.
Basically when the limit is smaller than the calculated packet size, it implies that something is wrong, most likely a weird USB descriptor. So the best option would be just to return an error at the parameter setup time before doing any further operations.
This patch introduces such a sanity check, and returns -EINVAL when the packet size is greater than maxpacksize. The comparison with ep->packsize[1] alone should suffice since it's always equal or greater than ep->packsize[0].(CVE-2025-40269)
In the Linux kernel, the following vulnerability has been resolved:
wifi: cfg80211: cancel pmsr_free_wk in cfg80211_pmsr_wdev_down
When the nl80211 socket that originated a PMSR request is closed, cfg80211_release_pmsr() sets the request's nl_portid to zero and schedules pmsr_free_wk to process the abort asynchronously. If the interface is concurrently torn down before that work runs, cfg80211_pmsr_wdev_down() calls cfg80211_pmsr_process_abort() directly. However, the already- scheduled pmsr_free_wk work item remains pending and may run after the interface has been removed from the driver. This could cause the driver's abort_pmsr callback to operate on a torn-down interface, leading to undefined behavior and potential crashes.
Cancel pmsr_free_wk synchronously in cfg80211_pmsr_wdev_down() before calling cfg80211_pmsr_process_abort(). This ensures any pending or in-progress work is drained before interface teardown proceeds, preventing the work from invoking the driver abort callback after the interface is gone.(CVE-2026-31548)
In the Linux kernel, the following vulnerability has been resolved:
mm/page_alloc: clear page->private in free_pages_prepare()
Several subsystems (slub, shmem, ttm, etc.) use page->private but don't clear it before freeing pages. When these pages are later allocated as high-order pages and split via split_page(), tail pages retain stale page->private values.
This causes a use-after-free in the swap subsystem. The swap code uses page->private to track swap count continuations, assuming freshly allocated pages have page->private == 0. When stale values are present, swap_count_continued() incorrectly assumes the continuation list is valid and iterates over uninitialized page->lru containing LIST_POISON values, causing a crash:
KASAN: maybe wild-memory-access in range [0xdead000000000100-0xdead000000000107] RIP: 0010:__do_sys_swapoff+0x1151/0x1860
Fix this by clearing page->private in free_pages_prepare(), ensuring all freed pages have clean state regardless of previous use.(CVE-2026-43303)
In the Linux kernel, the following vulnerability has been resolved:
ALSA: caiaq: Handle probe errors properly
The probe procedure of setup_card() in caiaq driver doesn't treat the error cases gracefully, e.g. the error from snd_card_register() calls snd_card_free() but continues. This would lead to a UAF for the further calls like snd_usb_caiaq_control_init(), as Berk suggested in another patch in the link below.
However, the problem is not only that; in general, this function drops the all error handlings (as it's a void function) although its caller can propagate an error to snd_probe(), which eventually calls snd_card_free() as a proper error path. That said, we should treat each error case in setup_card(), and just return the error code promptly, which is then handled later as a fatal error in snd_probe().
This patch achieves it by changing the setup_card() to return an error code. Also, the superfluous snd_card_free() call is removed, too.
Note that card->private_free can be set still safely at returning an error. All called functions in card_free() have checks of the unassigned resources or NULL checks.(CVE-2026-46004)
In the Linux kernel, the following vulnerability has been resolved:
sctp: stream: fully roll back denied add-stream state
When ADD_OUT_STREAMS is denied, SCTP only shrinks the queued chunks and then lowers outcnt. That leaves removed stream metadata behind, so a later re-add can reuse a stale ext and hit a null-pointer dereference in the scheduler get path.
Fix the rollback by tearing down the removed stream state the same way other stream resizes do. Unschedule the current scheduler state, drop the removed stream ext state with sctp_stream_outq_migrate(), and then reschedule the remaining streams.
This keeps scheduler-private RR/FC/PRIO lists consistent while fully rolling back denied outgoing stream additions.(CVE-2026-52929)
In the Linux kernel, the following vulnerability has been resolved:
libceph: handle rbtree insertion error in decode_choose_args()
A message of type CEPH_MSG_OSD_MAP contains an OSD map that itself contains a CRUSH map. The received CRUSH map may optionally contain choose_args that get decoded in decode_choose_args(). In this function, num_choose_arg_maps is read from the message, and a corresponding number of crush_choose_arg_maps gets decoded afterwards. Each crush_choose_arg_map has a choose_args_index, which serves as the key when inserting it into the choose_args rbtree of the decoded crush_map. If a (potentially corrupted) message contains two crush_choose_arg_maps with the same index, the assertion in insert_choose_arg_map() triggers a kernel BUG when trying to insert the second crush_choose_arg_map.
This patch fixes the issue by switching to the non-asserting rbtree insertion function and rejecting the message if the insertion fails.
In the Linux kernel, the following vulnerability has been resolved:
KVM: Reject wrapped offset in kvm_reset_dirty_gfn()
kvm_reset_dirty_gfn() guards the gfn range with
if (!memslot || (offset + __fls(mask)) >= memslot->npages)
return;
but offset is u64 and the addition is unchecked. The check can be silently bypassed by a u64 wrap.
The dirty ring backing those entries is MAP_SHARED at KVM_DIRTY_LOG_PAGE_OFFSET of the vcpu fd, so the VMM can rewrite the slot and offset fields of any entry between when the kernel pushes them and when KVM_RESET_DIRTY_RINGS consumes them. On reset, kvm_dirty_ring_reset() re-reads the values via READ_ONCE() and feeds them straight back into this check; only the flags handshake is treated as the handover, the slot/offset payload is taken on trust.
Crafting two entries
entry[i].offset = 0xffffffffffffffc1
entry[i+1].offset = 0
makes the coalescing loop in kvm_dirty_ring_reset() compute
delta = (s64)(0 - 0xffffffffffffffc1) = 63
which falls in [0, BITS_PER_LONG), so it folds entry[i+1] into the existing mask by setting bit 63. The trailing kvm_reset_dirty_gfn() call then sees offset = 0xffffffffffffffc1 and __fls(mask) = 63; the sum is 0 in u64 and the bounds check passes.
That offset propagates into kvm_arch_mmu_enable_log_dirty_pt_masked() unchanged. On the legacy MMU path -- kvm_memslots_have_rmaps() == true, i.e. shadow paging, any VM that has allocated shadow roots, or a write-tracked slot -- it reaches gfn_to_rmap(), which indexes slot->arch.rmap[0][] with a near-U64_MAX gfn. That is an out-of-bounds load of a kvm_rmap_head, followed by a conditional clear of PT_WRITABLE_MASK in whatever the loaded pointer points at. The path is reachable from any process holding /dev/kvm.
Range-check offset on its own first, so the addition cannot wrap. memslot->npages is bounded well below U64_MAX, so once offset < npages holds, offset + __fls(mask) (with __fls(mask) < BITS_PER_LONG) stays in range.(CVE-2026-52969)
In the Linux kernel, the following vulnerability has been resolved:
net: usb: rtl8150: fix use-after-free in rtl8150_start_xmit()
syzbot reported a KASAN slab-use-after-free read in rtl8150_start_xmit() when accessing skb->len for tx statistics after usb_submit_urb() has been called:
BUG: KASAN: slab-use-after-free in rtl8150_start_xmit+0x71f/0x760 drivers/net/usb/rtl8150.c:712 Read of size 4 at addr ffff88810eb7a930 by task kworker/0:4/5226
The URB completion handler write_bulk_callback() frees the skb via dev_kfree_skb_irq(dev->tx_skb). The URB may complete on another CPU in softirq context before usb_submit_urb() returns in the submitter, so by the time the submitter reads skb->len the skb has already been queued to the per-CPU completion_queue and freed by net_tx_action():
CPU A (xmit) CPU B (USB completion softirq) ------------ ------------------------------ dev->tx_skb = skb; usb_submit_urb() --+ |-------> write_bulk_callback() | dev_kfree_skb_irq(dev->tx_skb) | net_tx_action() | napi_skb_cache_put() <-- free netdev->stats.tx_bytes | += skb->len; <-- UAF read
Fix it by caching skb->len before submitting the URB and using the cached value when updating the tx_bytes counter.
The pre-existing tx_bytes semantics are preserved: the counter tracks the original frame length (skb->len), not the ETH_ZLEN/USB-alignment padded "count" value that is handed to the device. Changing that would be a user-visible accounting change and is out of scope for this UAF fix.(CVE-2026-52982)
In the Linux kernel, the following vulnerability has been resolved:
ALSA: PCM: Fix wait queue list corruption in snd_pcm_drain() on linked streams
snd_pcm_drain() uses init_waitqueue_entry which does not clear entry.prev/next, and add_wait_queue with a conditional remove_wait_queue that is skipped when to_check is no longer in the group after concurrent UNLINK. The orphaned wait entry remains on the unlinked substream sleep queue. On the next drain iteration, add_wait_queue adds the entry to a new queue while still linked on the old one, corrupting both lists. A subsequent wake_up dereferences NULL at the func pointer (mapped from the spinlock at offset 0 of the misinterpreted wait_queue_head_t), causing a kernel panic.
Replace init_waitqueue_entry/add_wait_queue/conditional remove_wait_queue with init_wait_entry/prepare_to_wait/ finish_wait. init_wait_entry clears prev/next via INIT_LIST_HEAD on each iteration and sets autoremove_wake_function which auto-removes the entry on wake-up. finish_wait safely handles both the already-removed and still-queued cases.(CVE-2026-53242)
In the Linux kernel, the following vulnerability has been resolved:
ieee802154: 6lowpan: only accept IPv6 packets in lowpan_xmit()
The aoe driver (or similar) generates a non-IPv6 packet (e.g., ETH_P_AOE) and queues it for transmission via dev_queue_xmit() on a 6LoWPAN interface (configured by the user or test case).
Since the packet is not IPv6, the 6LoWPAN header_ops->create function (lowpan_header_create or header_create) returns early without initializing the lowpan_addr_info structure in the skb headroom.
In the transmit function (lowpan_xmit), the driver calls lowpan_header (or setup_header) which unconditionally copies and uses the lowpan_addr_info from the headroom, which contains uninitialized data.
Fix this by dropping non IPv6 packets.
A similar fix is needed in net/bluetooth/6lowpan.c bt_xmit().(CVE-2026-63870)
In the Linux kernel, the following vulnerability has been resolved:
HID: wacom: Fix OOB write in wacom_hid_set_device_mode()
wacom_hid_set_device_mode() currently assumes that the HID_DG_INPUTMODE usage is always located in the first field (field[0]) of the feature report. However, a device can specify HID_DG_INPUTMODE in a different field.
If HID_DG_INPUTMODE is in a field other than the first one and the first field has a report_count smaller than the usage_index of HID_DG_INPUTMODE, this leads to an out-of-bounds write to r->field[0]->value.
Fix this by storing the field index of HID_DG_INPUTMODE in 'struct hid_data' during feature mapping. In wacom_hid_set_device_mode(), use this stored field index to access the correct field and add bounds checks to ensure both the field index and the value index are within valid ranges before writing.(CVE-2026-63916)
In the Linux kernel, the following vulnerability has been resolved: net/smc: reject CHID-0 ACCEPT that matches an empty ism_dev slot. On the SMC-D client, slot 0 of ini->ism_dev[]/ini->ism_chid[] is reserved for an SMC-Dv1 device. smc_find_ism_v2_device_clnt() populates V2 entries starting at index 1, so when no V1 device is selected slot 0 is left in its kzalloc()'ed state with ism_dev[0] == NULL and ism_chid[0] == 0. smc_v2_determine_accepted_chid() then matches the peer's CHID against the array starting from index 0 using the CHID alone. A malicious peer replying to a SMC-Dv2-only proposal with d1.chid == 0 matches the empty slot, ini->ism_selected becomes 0, and the subsequent ism_dev[0]->lgr_lock dereference in smc_conn_create() causes a NULL pointer dereference. Require ism_dev[i] to be non-NULL before accepting a CHID match.(CVE-2026-64048)
In the Linux kernel, the following vulnerability has been resolved:
staging: vme_user: bound slave read/write to the kern_buf size
The SLAVE-path helpers buffer_to_user() and buffer_from_user() copy 'count' bytes into/out of the fixed-size kern_buf (size_buf == PCI_BUF_SIZE == 0x20000, 128 KiB) using ppos as the offset, without bounding ppos + count against size_buf.
vme_user_write()/vme_user_read() only clamp count to the VME window size (image_size = vme_get_size(resource)), which VME_SET_SLAVE sets from the user-supplied slave.size -- validated against the VME address space (up to VME_A32_MAX = 4 GiB), not against PCI_BUF_SIZE. When the window exceeds 128 KiB, a write()/read() copies past the kern_buf allocation.
Clamp count against size_buf in both helpers, with an early return when ppos is already at/after the buffer end. ppos is >= 0 here (the caller rejects negative offsets), so size_buf - *ppos cannot wrap. This mirrors the existing clamp in the MASTER-path helpers resource_to_user() / resource_from_user(), and matches the read()/write() convention of a short transfer at end-of-buffer.
Found by static analysis (CodeQL taint tracking + CBMC bounded model checking) and confirmed dynamically under KASAN with the vme_fake bridge:
BUG: KASAN: slab-out-of-bounds in _copy_from_user+0x2d/0x80 Write of size 262144 at addr ffff888004100000 by task trigger/68 _copy_from_user+0x2d/0x80 vme_user_write+0x13e/0x240 [vme_user] vfs_write+0x1b8/0x7a0 ksys_write+0xb8/0x150(CVE-2026-64449)
In the Linux kernel, the following vulnerability has been resolved:
mm/damon/ops-common: handle extreme intervals in damon_hot_score()
Fix three issues in damon_hot_score() that comes from wrong handling of extreme (zero or too high) monitoring intervals user setup.
When the user sets sampling interval zero, damon_max_nr_accesses(), which is called from damon_hot_score(), causes a divide-by-zero. Needless to say, it is a problem.
When the user sets the aggregation interval zero, the function returns zero. It is wrong, since the real maximum nr_acceses in the setup should be one. Worse yet, it can cause another divide-by-zero from its caller, damon_hot_score(), since it uses damon_max_nr_accesses() return value as a denominator.
When the user sets the aggregation interval very high, damon_hot_score() could return a value out of [0, DAMOS_MAX_SCORE] range. Since the return value is used as an index to the regions_score_histogram array, which is DAMOS_MAX_SCORE+1 size, it causes out of bounds array access.
The issues can be relatively easily reproduced like below. The sysfs write permission is required, though.
# ./damo start --damos_action lru_prio --damos_quota_space 100M \
--damos_quota_interval 1s
# cd /sys/kernel/mm/damon/admin/kdamonds/0
# echo 0 > contexts/0/monitoring_attrs/intervals/sample_us
# echo 0 > contexts/0/monitoring_attrs/intervals/aggr_us
# echo commit > state
# dmesg
[...]
[ 131.329762] Oops: divide error: 0000 [#1] SMP NOPTI
[...]
[ 131.336089] RIP: 0010:damon_hot_score+0x27/0xd0
[...]
Fix the divide-by-zero intervals problems by explicitly handling the zero intervals in damon_max_nr_accesses(). Fix the out-of-bound array access by applying [0, DAMOS_MAX_SCORE] bounds before returning from damon_hot_score().
The issue was discovered [1] by Sashiko.(CVE-2026-64458)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/rxe: Fix a use-after-free problem in rxe_mmap
rxe_mmap() removes a rxe_mmap_info struct from the pending_mmaps list and releases pending_lock while the struct's kref is still at 1:
list_del_init(&ip->pending_mmaps); spin_unlock_bh(&rxe->pending_lock); / ref == 1, no lock held / ret = remap_vmalloc_range(vma, ip->obj, 0); / walks PTEs / [...] rxe_vma_open(vma); / kref_get, ref → 2 / remap_vmalloc_range_partial() walks PTEs without any lock.
A concurrent DESTROY_CQ ioctl on another CPU calls:
kref_put(&q->ip->ref, rxe_mmap_release) /* ref 1→0 */
vfree(ip->obj) /* clears vmalloc PTEs mid-walk */
kfree(ip) /* frees rxe_mmap_info */
This yields:
-
Kernel crash, vmalloc_to_page() returns NULL when vfree wins the per-PTE race -> vm_insert_page(NULL) → GPF in validate_page_before_insert
-
Page UAF, vmalloc_to_page() reads a stale PTE before vfree clears it. User VMA holds a PTE to a free'd page which might eventually get reallocated later by vmalloc which allows the attacker to get a clean page-level UAF.
It is worth noting that even though a page-level UAF is possible given the strong primitive, it is statistically very difficult to achieve given the very short time window (after the last insert_page and before the kref_get).
The call trace are as below:
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] CPU: 0 UID: 1000 PID: 413 Comm: poc Not tainted 7.0.0-rc5-dirty #28 PREEMPT(lazy) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:validate_page_before_insert+0x32/0x300 Code: e5 41 57 41 56 49 89 fe 41 55 41 54 53 48 89 f3 e8 93 b5 a3 ff 48 8d 7b 08 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 7b 02 00 00 4c 8b 63 08 31 ff 4d 89 e5 41 83 e5 RSP: 0018:ffff88811b15f2f0 EFLAGS: 00000202 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000001 RSI: 0000000000000000 RDI: 0000000000000008 RBP: ffff88811b15f318 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffff8881181eee00 R13: 0000000000000000 R14: ffff8881181eee00 R15: ffff8881181eee20 FS: 00007b1e000f76c0(0000) GS:ffff8884268e0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007b1e00a24ac0 CR3: 0000000116eb3000 CR4: 00000000000006f0 Call Trace: <TASK> insert_page+0x8f/0x190 ? __pfx_insert_page+0x10/0x10 ? kasan_save_alloc_info+0x38/0x60 vm_insert_page+0x2e7/0x400 remap_vmalloc_range_partial+0x212/0x3e0 remap_vmalloc_range+0x6e/0xb0 ? __kasan_check_write+0x14/0x30 rxe_mmap+0x2e9/0x5d0 ib_uverbs_mmap+0x1ad/0x2c0 __mmap_region+0x12c2/0x2ad0 ? __pfxmmapregion+0x10/0x10 ? sanitizer_cov_trace_switch+0x58/0xb0 ? mas_prev_slot+0x360/0x39c0 ? __sanitizer_cov_trace_switch+0x58/0xb0 ? mas_next_slot+0x1e5b/0x2f40 ? __sanitizer_cov_trace_cmp8+0x18/0x30 ? unmapped_area_topdown+0x4dd/0x610 ? kfree+0x1b1/0x440 ? free_cpumask_var+0x16/0x30 ? __kasan_slab_free+0x7d/0xa0 ? __sanitizer_cov_trace_cmp8+0x18/0x30 mmap_region+0x2e6/0x3c0 do_mmap+0xa3e/0x12a0 ? __pfx_do_mmap+0x10/0x10 ? __kasan_check_write+0x14/0x30 ? down_write_killable+0xba/0x160 ? __pfx_down_write_killable+0x10/0x10 ? __sanitizer_cov_trace_cmp4+0x16/0x30 vm_mmap_pgoff+0x2d4/0x4a0 ? __pfx_vm_mmap_pgoff+0x10/0x10 ? fget+0x1bf/0x270 ksys_mmap_pgoff+0x40c/0x690 ? __sanitizer_cov_trace_const_cmp4+0x16/0x30 ? __pfx_ksys_mmap_pgoff+0x10/0x10 ? __kasan_check_write+0x14/0x30 ? _raw_spin_trylock+0xbb/0x130 ? __pfx__raw_spin_trylock+0x10/0x10 __x64_sys_mmap+0x135/0x1e0 x64_sys_c ---truncated---(CVE-2026-64582)
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu/vce: fix integer overflow in image size
Fix a security vulnerability where malicious VCE command streams with oversized dimensions (e.g. 65536×65536) cause 32-bit integer overflow, wrapping the calculated buffer size to 0. This bypasses validation and allows GPU firmware to perform out-of-bound memory access.
The fix uses 64-bit arithmetic to detect overflow and rejects invalid dimensions before they reach the hardware.
V2: remove redundant check V3: modify max height value V4: remove size64
(cherry picked from commit cbe408dba581755ad1279a487ec786d8927d778d)(CVE-2026-68108)
In the Linux kernel, the following vulnerability has been resolved:
sctp: fix auth_chunk_list capacity check in sctp_auth_ep_add_chunkid
sctp_auth_ep_add_chunkid() uses SCTP_NUM_CHUNK_TYPES (20) as the capacity limit for ep->auth_chunk_list, allowing it to hold up to 20 chunk entries (param_hdr.length up to 24). However, the copy destination asoc->c.auth_chunks in struct sctp_cookie is only SCTP_AUTH_MAX_CHUNKS (16) entries (20 bytes). When more than 16 chunks are added, sctp_association_init() memcpy overflows the destination by up to 4 bytes.
Fix by using SCTP_AUTH_MAX_CHUNKS as the capacity limit, matching the destination capacity.(CVE-2026-68320)
In the Linux kernel, the following vulnerability has been resolved:
wifi: cfg80211: use wiphy work for socket owner autodisconnect
nl80211_netlink_notify() walks the cfg80211 wireless device list when a NETLINK_GENERIC socket is released. If the socket owns a connection, the notifier queues the embedded wdev->disconnect_wk work item.
That work is a plain work_struct today. NETDEV_GOING_DOWN cancels it, but a NETLINK_URELEASE notifier that already observed conn_owner_nlportid can queue it after that cancel returns. _cfg80211_unregister_wdev() then removes the wdev from the list and waits for RCU readers, but synchronize_net() does not drain work queued by such a reader.
Make the autodisconnect work a wiphy_work instead. The callback already needs the wiphy mutex, and wiphy_work runs under that mutex. This lets teardown cancel pending autodisconnect work while holding the mutex, without a cancel_work_sync() vs. worker locking concern.
Also cancel the wiphy work after list_del_rcu() and synchronize_net(). Any NETLINK_URELEASE notifier that had already reached the wdev list has then either queued the work and it is removed, or can no longer find the wdev.(CVE-2026-68404)
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: validate extension-frame layout before RX
Extension frames only have the extension header at the regular 802.11 header offset. The generic RX path can still reach helpers and interface dispatch code that read regular header address fields before unsupported extension subtypes are dropped.
mac80211 currently only handles S1G beacon extension frames. Drop other extension subtypes before they can reach regular-header RX processing. For S1G beacons, linearize the SKB with the management-frame path and require the fixed S1G beacon header, including optional fixed fields indicated by frame control, before generic RX dispatch.
Route S1G beacons through the station/default-link RX path without regular-header station lookup. Avoid regular-header address reads in the mac80211 RX paths that process S1G extension beacons, including accept-frame, duplicate-detection, address-copy, and MLO address-translation paths.
Also make ieee80211_get_bssid() length-safe before returning the S1G source-address pointer.(CVE-2026-68470)
In the Linux kernel, the following vulnerability has been resolved:
dm_early_create: fix freeing used table on dm_resume failure
If dm_resume fails, the kernel attempts to free table with dm_table_destroy, but the table was already instantiated with dm_swap_table. This commit skips the call to dm_table_destroy in this case.(CVE-2026-72102)
In the Linux kernel, the following vulnerability has been resolved:
dm-ioctl: fix a possible overflow in list_version_get_info
sizeof(tt->version) is 12 bytes, but the code writes 16 bytes into the output buffer - info->vers->version[0], info->vers->version[1], info->vers->version[2] and info->vers->next. This can cause buffer overflow.
Fix this buffer overflow by replacing "sizeof(tt->version)" with "sizeof(struct dm_target_versions)".(CVE-2026-72106)
In the Linux kernel, the following vulnerability has been resolved:
dm thin metadata: fix metadata snapshot consistency on commit failure
__reserve_metadata_snap() and __release_metadata_snap() modify the superblock's held_root directly in the block_manager's buffer. If the subsequent metadata commit fails, the held_root gets flushed to disk through the abort_transaction path, resulting in inconsistent metadata.
Reproducer 1: __reserve_metadata_snap()
- Create a 2 MiB metadata device and make the region after the 14th block inaccessible, to trigger metadata commit failure in the subsequent reserve_metadata_snap operation. The 14th block will be the shadow destination for the index block.
dmsetup create tmeta --table "0 112 linear /dev/sdc 0 112 3984 error"
- Create a 16 MiB thin-pool
dmsetup create tdata --table "0 32768 zero" dd if=/dev/zero of=/dev/mapper/tmeta bs=4k count=1 dmsetup create tpool --table "0 32768 thin-pool /dev/mapper/tmeta \ /dev/mapper/tdata 128 0 1 skip_block_zeroing"
- Take a metadata snapshot to trigger metadata commit failure and transaction abort. However, the held_root is written to disk, breaking metadata consistency.
dmsetup message tpool 0 "reserve_metadata_snap"
thin_check v1.2.2 result:
Bad reference count for metadata block 6. Expected 2, but space map contains 1. Bad reference count for metadata block 7. Expected 2, but space map contains 1. Bad reference count for metadata block 13. Expected 1, but space map contains 0.
Reproducer 2: __release_metadata_snap()
- Create a 2 MiB metadata device and make the region after the 16th block inaccessible, to trigger metadata commit failure in the subsequent release_metadata_snap operation. The 16th block will be the shadow destination for the index block.
dmsetup create tmeta --table "0 128 linear /dev/sdc 0 128 3968 error"
- Create a 16 MiB thin-pool
dmsetup create tdata --table "0 32768 zero" dd if=/dev/zero of=/dev/mapper/tmeta bs=4k count=1 dmsetup create tpool --table "0 32768 thin-pool /dev/mapper/tmeta \ /dev/mapper/tdata 128 0 1 skip_block_zeroing"
- Reserve then release the metadata snapshot, to trigger metadata commit failure and transaction abort. The held_root gets removed from the on-disk superblock, causing inconsistent metadata.
dmsetup message tpool 0 "reserve_metadata_snap" dmsetup message tpool 0 "release_metadata_snap"
thin_check v1.2.2 result:
Bad reference count for metadata block 6. Expected 1, but space map contains 2. Bad reference count for metadata block 7. Expected 1, but space map contains 2. 1 metadata blocks have leaked.
Fix by deferring the held_root update to commit time.
Additionally, move the existing-snapshot check in __reserve_metadata_snap before the shadow operation to avoid unnecessary work. In __release_metadata_snap, clear pmd->held_root before btree deletion so partial failure leaks blocks rather than leaving a stale reference, and unlock the snapshot block before decrementing its refcount.(CVE-2026-72108)
In the Linux kernel, the following vulnerability has been resolved:
ntfs: detect mapping-pairs LCN accumulator overflow
The NTFS mapping-pairs parser accumulates relative LCN deltas in a signed integer. A corrupted attribute can drive that addition past the representable range.
One corrupt runlist shape sets the accumulated LCN to S64_MAX and then adds a delta of 1 in the next mapping-pairs entry.
Signed overflow is undefined and can turn an invalid runlist into a different set of physical clusters.
Check the LCN addition for overflow before storing the next run.(CVE-2026-72200)
In the Linux kernel, the following vulnerability has been resolved:
jbd2: fix integer underflow in jbd2_journal_initialize_fast_commit()
jbd2_journal_initialize_fast_commit() validates journal capacity by checking (journal->j_last - num_fc_blks < JBD2_MIN_JOURNAL_BLOCKS). Both j_last and num_fc_blks are unsigned, so when num_fc_blks exceeds j_last the subtraction wraps to a large value, bypassing the bounds check.
The resulting underflow corrupts j_last, j_fc_first, and j_free, leading to journal abort.
Fix by checking num_fc_blks against j_last before the subtraction, returning -EFSCORRUPTED.(CVE-2026-72225)
In the Linux kernel, the following vulnerability has been resolved:
hwmon: (pmbus/core) honor vrm_version in pmbus_data2reg_vid()
pmbus_data2reg_vid() hardcoded the VR11 encoding regardless of the vrm_version configured by the driver, while pmbus_reg2data_vid() already switched on it. Any driver that selects a non-VR11 VID mode and exposes a regulator (or hwmon vout setter) sent dangerously wrong codes to PMBUS_VOUT_COMMAND -- e.g. an nvidia195mv part asked for 200 mV got the VR11 clamp to 500 mV encoded as 0xB2, which the chip interprets as 1080 mV.
Mirror pmbus_reg2data_vid() so writes round-trip with reads.(CVE-2026-72397)
In the Linux kernel, the following vulnerability has been resolved:
configfs: fix lockless traversals of ->s_children
Having the parent directory locked protects entries from removal by another thread, but it does not protect cursors from being moved around by lseek() - or freed, for that matter.(CVE-2026-74330)
In the Linux kernel, the following vulnerability has been resolved:
configfs_lookup(): don't leave ->s_dentry dangling on failure
Normally ->s_dentry is cleared when dentry it's pointing to becomes negative (on eviction, realistically). However, that only happens if dentry gets to be positive in the first place; in case of inode allocation failure dentry never becomes positive, so ->d_iput() is not called at all.
We do part of what normally would've been done by configfs_d_iput() (dropping the reference to configfs_dirent) manually, but we do not clear ->s_dentry there. Sloppy as it is, it does not matter in case of configfs_create_{dir,link}() - there configfs_dirent does not survive dropping the sole reference to it.
However, for configfs_lookup() it does survive, with a dangling pointer to soon to be freed dentry sitting it its ->s_dentry.
Subsequent getdents(2) in that directory will end up dereferencing that pointer in order to pick the inode number. Use after free...
This is the minimal fix; the right approach is to set the linkage between dentry and configfs_dirent only after we know that we have an inode, but that takes more surgery and the bug had been there since 2006, so...(CVE-2026-74359)
In the Linux kernel, the following vulnerability has been resolved:
md/raid1,raid10: fix error-path detection with md_cloned_bio()
Detect the error path using md_cloned_bio() instead of relying on r1_bio in raid1 or r10_bio->read_slot in raid10, which may be NULL or -1 after splitting and resubmitting a failed bio.
As a result, the error path may not be recognized and memory allocations can incorrectly use GFP_NOIO instead of (GFP_NOIO | __GFP_HIGH), which can lead to a deadlock under memory pressure.(CVE-2026-74374)
In the Linux kernel, the following vulnerability has been resolved:
media: uvcvideo: Fix deadlock if uvc_status_stop is called from async_ctrl.work
If a UVC camera has an asynchronous control, uvc_status_stop may be called from async_ctrl.work:
uvc_ctrl_status_event_work() uvc_ctrl_status_event() uvc_ctrl_clear_handle() uvc_pm_put() uvc_status_put() uvc_status_stop() cancel_work_sync()
This will cause a deadlock, since cancel_work_sync will wait for uvc_ctrl_status_event_work to complete before returning.
Fix this by returning early from uvc_status_stop if we are currently in the work function. flush_status now remains false until uvc_status_start is called again, ensuring that uvc_ctrl_status_event_work won't resubmit the URB.(CVE-2026-74437)
In the Linux kernel, the following vulnerability has been resolved:
drm/vmwgfx: bound DMA command body size against suffix pointer
vmw_cmd_dma() locates the DMA suffix at
(unsigned long) &cmd->body + header->size - sizeof(*suffix)
without checking that header->size is large enough to contain both cmd->body and the suffix. An undersized header makes the suffix pointer underflow back into the previous command in the bounce buffer. The verifier later writes suffix->maximumOffset, clobbering verified fields of an already-relocated earlier command -- a TOCTOU on the device-visible command stream that lets one command rewrite another's GMR id, surface id, or other authenticated fields.
Reject the command if the body is too small for the suffix to fit.(CVE-2026-74443)
In the Linux kernel, the following vulnerability has been resolved:
drm/vmwgfx: validate DRAW_PRIMITIVES header size before division
vmw_cmd_draw() computes
maxnum = (header->size - sizeof(cmd->body)) / sizeof(*decl);
where header->size is u32 and is taken straight from the user-supplied command stream. When header->size is less than sizeof(cmd->body) the unsigned subtraction wraps to nearly 4 GiB, producing a huge maxnum. Any user-controlled cmd->body.numVertexDecls then passes the bound and the loop dereferences decl[i] far past the end of the kernel command bounce buffer, producing an out-of-bounds read of kernel memory.
Reject undersized headers up front.(CVE-2026-74444)
In the Linux kernel, the following vulnerability has been resolved:
hwmon: (nct6775-core) Prevent access to unsupported weight registers
Sashiko reports:
During initialization of the nct6116 chip, the driver sets data->pwm_num to 5. However, it assigns several NCT6106 register arrays (such as NCT6106_REG_WEIGHT_DUTY_STEP, NCT6106_REG_WEIGHT_TEMP_SEL, and NCT6106_REG_WEIGHT_TEMP_*) to data->REG_PWM and data->REG_WEIGHT_TEMP. These arrays only contain 3 elements.
In nct6775_update_pwm(), the driver iterates up to data->pwm_num. If data->has_pwm has bits 3 or 4 set (which is structurally possible for nct6116), the loop attempts to read elements at index 3 and 4 from these 3-element arrays. This results in a global out-of-bounds read, which can be caught by KASAN.
Furthermore, the driver uses these garbage out-of-bounds values as hardware register addresses for subsequent read and write operations. This leads to invalid hardware register access, potentially causing hardware misconfiguration or system crashes.
The underlying problem is that the chip does support up to five fan control channels, but only the first three support weight control. Fix the problem by extending the affected weight register arrays with zeroed fields. The driver uses zeroed register addresses to determine if a register is supported or not, and skips accesses for unsupported registers.(CVE-2026-74549)
In the Linux kernel, the following vulnerability has been resolved:
NFS: Pin the 'struct nfs_server' during a FREE_STATEID call
Dan Aloni reports that he was able to hit a use-after-free bug if a FREE_STATEID operation gets delayed for whatever reason. Fix this by bumping the refcount of the 'struct nfs_server' object for the duration of the FREE_STATEID so it doesn't get cleaned up from underneath us while operations are still in flight.(CVE-2026-74730)
In the Linux kernel, the following vulnerability has been resolved:
sctp: validate cookie AUTH state before use
When cookie authentication is disabled, COOKIE_ECHO restores fixed-size AUTH fields directly from peer-controlled cookie bytes. A forged RANDOM length, HMAC list, or CHUNKS list can then reach association consumers with lengths or identifiers that were never validated against the local backing arrays.
A forged RANDOM length can cause out-of-bounds reads during key-vector construction. A forged HMAC identifier also caused a 32-byte write past a zero-length AUTH chunk, providing a primitive for a local privilege escalation chain.
Validate the cookie's RANDOM, HMACS, and CHUNKS parameters at the cookie trust boundary before copying them into the association. Reject invalid types, malformed lengths, unsupported HMAC identifiers, HMAC lists without SHA1, and forbidden chunk ids.(CVE-2026-74752)
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Fix UVD decode image min size calculation
This needs to use pitch instead of width. Also reject pitch over 4096 to avoid overflow.
(cherry picked from commit b41c8cb12e202b220353332ab87dc01a11f69304)(CVE-2026-80540)
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: validate GEM_CREATE domain combinations
AMDGPU_GEM_CREATE checked domain bits against AMDGPU_GEM_DOMAIN_MASK, but did not validate domain combinations. Userspace could combine CPU|GTT|VRAM with DOORBELL, GDS, GWS, or OA, making amdgpu_bo_placement_from_domain() exceed AMDGPU_BO_MAX_PLACEMENTS and hit BUG_ON().
Allow combinations only within CPU/GTT/VRAM, and require non-CPU/GTT/ VRAM domains to be specified one at a time. Return -EINVAL for invalid combinations in amdgpu_gem_create_ioctl().
v2: Rename helper from amdgpu_gem_domain_valid() to amdgpu_gem_are_domains_valid() (Christian)
(cherry picked from commit db39852d0c39843cb02048dfb47e4b8c703e9080)(CVE-2026-80541)
In the Linux kernel, the following vulnerability has been resolved:
Input: synaptics-rmi4 - bound the F54 report size to the allocated buffer
rmi_f54_work() reads a diagnostics report from the device into f54->report_data, sizing the transfer with rmi_f54_get_report_size():
report_size = rmi_f54_get_report_size(f54);
...
for (i = 0; i < report_size; i += F54_REPORT_DATA_SIZE) {
int size = min(F54_REPORT_DATA_SIZE, report_size - i);
...
rmi_read_block(.., f54->report_data + i, size);
}
report_data is allocated once at probe from F54's own electrode counts (array3_size(f54->num_tx_electrodes, f54->num_rx_electrodes, sizeof(u16))), but rmi_f54_get_report_size() computes the size from drv_data->num_*_electrodes when those are set, i.e. from the F55 function's electrode counts. Both counts come straight from device queries (F54 and F55 each report up to 255 electrodes) and nothing constrains the F55 counts to the F54 ones.
A malicious or malfunctioning RMI4 device that reports larger F55 electrode counts than its F54 counts makes report_size exceed the allocation, so the read loop writes past report_data (and the V4L2 dequeue memcpy() then reads past it). On conforming hardware the F55 configured electrodes are a subset of the F54 physical electrodes, so report_size never exceeds the buffer and well-behaved devices are unaffected.
Record the allocation size and reject a report that does not fit, mirroring the existing zero-size check.(CVE-2026-80569)
In the Linux kernel, the following vulnerability has been resolved:
Input: synaptics-rmi4 - zero report size on F54 work error
In rmi_f54_work(), if an error occurs during report request or command verification, the code jumped directly to the 'error' label, bypassing the 'abort' label where f54->report_size was normally zeroed out.
This left f54->report_size containing its previous successful payload size. If a user then altered the V4L2 format to a smaller size, and a subsequent run failed, rmi_f54_buffer_queue() would copy the stale, larger payload size into the shrunken V4L2 buffer, causing a heap buffer overflow.
Fix this by merging the 'abort' and 'error' labels into a single 'out' exit path, and ensuring that f54->report_size is always set to 0 on failure by checking for error and zeroing the local report_size first.(CVE-2026-80570)
In the Linux kernel, the following vulnerability has been resolved:
net: ethernet: mtk_eth_soc: pass eth to mtk_handle_irq_rx in poll_controller
mtk_handle_irq_rx expects a struct mtk_eth * (matching the request_irq cookie), but mtk_poll_controller incorrectly passed the net_device *. Calling ndo_poll_controller with CONFIG_NET_POLL_CONTROLLER enabled would then crash.(CVE-2026-80694)
In the Linux kernel, the following vulnerability has been resolved:
can: j1939: transport: j1939_session_fresh_new(): initialize receive buffer
Zero the allocated buffer in j1939_session_fresh_new() to ensure it contains no residual data.
While there is a potential performance impact if users allocate maximum sized ETP buffers, most real-world use cases are not noticeably affected since the maximum known buffer size is typically around 65K.
In the Linux kernel, the following vulnerability has been resolved:
sctp: validate Adaptation Indication parameter length
The Adaptation Layer Indication parameter contains a fixed 32-bit Adaptation Code Point after its parameter header. However, sctp_verify_param() accepts a header-only parameter because the generic parameter walker only requires the header to be present.
sctp_process_param() then reads adaptation_ind beyond the declared parameter. When the malformed parameter is last in an INIT, the read starts at the receive skb tail, and the value is copied into the state cookie returned in the INIT ACK. This may disclose four receive-buffer tail bytes.
Require the declared parameter length to match the fixed structure size and abort the association through the existing invalid parameter length path otherwise.(CVE-2026-80717)
In the Linux kernel, the following vulnerability has been resolved:
KVM: x86/mmu: WARN and clear role.invalid when creating a child shadow page
Explicitly clear role.invalid when deriving a child shadow page's role from its parent to harden against bugs elsewhere in KVM, as violating KVM's invariant that invalid pages are NOT on the list of active MMU pages leads to use-after-free due to __kvm_mmu_prepare_zap_page() using list_add() instead of list_move() when processing an invalid shadow page, i.e. makes a bad situation far worse.
Yell loudly if the parent is invalid, as it means KVM has missed a validity check, i.e. KVM is attempting to map memory using an invalid/obsolete root, but continue on as the child is otherwise still a valid shadow page.
================================================================== BUG: KASAN: slab-use-after-free in __kvm_mmu_get_shadow_page+0x1817/0x1860 [kvm] Write of size 8 at addr ff11000153dd1368 by task repro/853
CPU: 1 UID: 1000 PID: 853 Comm: repro Not tainted 7.2.0-rc2-3aec122bdcaf-next-vm #5 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: <TASK> dump_stack_lvl+0x4b/0x70 print_report+0x153/0x49c kasan_report+0xbc/0xf0 __kvm_mmu_get_shadow_page+0x1817/0x1860 [kvm] mmu_alloc_root+0x141/0x320 [kvm] kvm_mmu_load+0x612/0x20f0 [kvm] kvm_arch_vcpu_ioctl_run+0x3dd5/0x6150 [kvm] kvm_vcpu_ioctl+0x5e4/0x10d0 [kvm] __x64_sys_ioctl+0x131/0x1b0 do_syscall_64+0x67/0x5f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 </TASK>
Allocated by task 853: kasan_save_stack+0x20/0x40 kasan_save_track+0x14/0x30 __kasan_slab_alloc+0x5f/0x70 kmem_cache_alloc_noprof+0xfe/0x2e0 __kvm_mmu_topup_memory_cache+0x135/0x530 [kvm] paging64_page_fault+0x318/0x1e30 [kvm] kvm_mmu_do_page_fault+0x21d/0x630 [kvm] kvm_mmu_page_fault+0x18c/0x17b0 [kvm] kvm_arch_vcpu_ioctl_run+0x1f35/0x6150 [kvm] kvm_vcpu_ioctl+0x5e4/0x10d0 [kvm] __x64_sys_ioctl+0x131/0x1b0 do_syscall_64+0x67/0x5f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53
Freed by task 853: kasan_save_stack+0x20/0x40 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x43/0x70 kmem_cache_free+0xe2/0x400 kvm_mmu_commit_zap_page.part.0+0x1e2/0x310 [kvm] kvm_mmu_free_roots+0x283/0x560 [kvm] kvm_arch_vcpu_ioctl_run+0x33c8/0x6150 [kvm] kvm_vcpu_ioctl+0x5e4/0x10d0 [kvm] __x64_sys_ioctl+0x131/0x1b0 do_syscall_64+0x67/0x5f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53(CVE-2026-80726)
In the Linux kernel, the following vulnerability has been resolved:
serial: amba-pl011: synchronize DMA teardown
dmaengine_terminate_all() does not wait for a running callback, so the TX callback can still touch the TX buffer after it is freed. The RX poll timer reads the RX buffers without the port lock.
Switch to dmaengine_terminate_sync() and delete the RX timer before freeing the buffers.(CVE-2026-80737)
In the Linux kernel, the following vulnerability has been resolved:
md: do overflow check for sb->bblog_shift in super_1_load()
In super_1_load(), sb->bblog_shift is an __u8 type value loaded from on- disk superblock. It is used for badblocks API badblocks_set() by the following sequence,
1930 rdev->badblocks.shift = sb->bblog_shift; 1931 for (i = 0 ; i < (sectors << (9-3)) ; i++, bbp++) { 1932 u64 bb = le64_to_cpu(*bbp); 1933 int count = bb & (0x3ff); 1934 u64 sector = bb >> 10; 1935 sector <<= sb->bblog_shift; 1936 count <<= sb->bblog_shift; 1937 if (bb + 1 == 0) 1938 break; 1939 if (!badblocks_set(&rdev->badblocks, sector, count, 1)) 1940 return -EINVAL; 1941 }
bb->bblog_shit is in range of 0-255, variable sector is 64bit width, for an invalid bb->bblog_shit, it is possible to make sector be overflowed by the following calculation, 1935 sector <<= sb->bblog_shift; Then in turn when call badblocks_set() at line 1939 with the invalid rdev->badblocks.shift set at line 1930, may result an overflow inside _badblocks_clear() in block/badblocks.c.
Although there are many places to call badblocks APIs, the non-zero shift value is only used in super_1_load(), other places always use 0 as the shift value. Therefore it is unnecessary to do a general shift value overflow check inside badblock API, and just check here as the caller.
This may avoid unnecessary check, make the badblocks API code more simple and elegant.(CVE-2026-89557)
In the Linux kernel, the following vulnerability has been resolved:
ata: libata-scsi: fix DSM TRIM for sector sizes larger than 2048 bytes
ata_scsi_write_same_xlat() translates a SCSI WRITE SAME command with the UNMAP bit set into an ATA DATA SET MANAGEMENT TRIM command. The TRIM descriptor is built by ata_format_dsm_trim_descr() into the 2048-byte ata_scsi_rbuf staging buffer, and the number of bytes copied is compared against the logical sector size by the caller:
size = ata_format_dsm_trim_descr(scmd, trmax, block, n_block);
if (size != len) /* len == sdp->sector_size */
goto invalid_param_len;
ata_format_dsm_trim_descr() clamps the copy length to ATA_SCSI_RBUF_SIZE (2048). On a device whose logical sector size exceeds that (e.g. a 4Kn device, where sector_size == 4096) the function can never return more than 2048, while the caller expects it to return sector_size. The comparison therefore always fails, so every TRIM is rejected with "Parameter list length error" and WARN_ON() splats on each attempt. TRIM / discard is thus completely broken on such devices.
The descriptor was incorrectly sized from the logical sector size. A DSM TRIM payload is a list of 512-byte pages, each holding up to ATA_MAX_TRIM_RNUM (64) LBA Range Entries, and is independent of the logical sector size. The Block Limits VPD page already advertises a single such page as the maximum WRITE SAME length (65535 * ATA_MAX_TRIM_RNUM logical blocks), so the block layer never sends a request that needs more than one page.
Emit exactly one 512-byte page, independent of the logical sector size, and transfer only that page (COUNT == 1). For a 512-byte-sector device this is unchanged; devices with larger logical sectors now work instead of failing every TRIM.(CVE-2026-89586)
In the Linux kernel, the following vulnerability has been resolved:
ecryptfs: pass packet set buffer size to parser
ecryptfs_parse_packet_set() receives a pointer into the file header, but it calculates the remaining packet buffer size from PAGE_SIZE - 8. For version 1 headers the packet set starts later in the header, so this can overstate the available buffer.
Pass the actual packet set buffer length from the caller and calculate per-packet limits from the remaining bytes in that buffer. Recompute the remaining length after consuming a tag 3 packet before parsing the following tag 11 packet.(CVE-2026-89608)
In the Linux kernel, the following vulnerability has been resolved:
smb: client: reject a tree connect response whose byte count is too small
CIFSTCon() bounds its strnlen() over the byte area with the server's ByteCount minus two, which for ByteCount 0 or 1 goes negative as an int and converts to a huge size_t. The later subtraction wraps the __u16 bytes_left, and that is what bounds cifs_strndup_from_utf16(): a bound of up to 65535 against a ~16 KB cifs_req_poolp object runs off the end of the slab object, and the bytes reach userspace through tcon->nativeFileSystem in /proc/fs/cifs/DebugData.
Reject a byte area too small for what the parser consumes. Two bytes is the least it can consume, and no conformant response carries fewer. The new trace point is the 129th smb_eio_trace entry, which __mode(byte) cannot represent, so the attribute goes with it.(CVE-2026-89631)
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix OOB read/write from unvalidated DataOffset in coalesce_t2()
coalesce_t2() computes data pointers directly from server-supplied DataOffset fields with no validation against buffer bounds:
data_area_of_tgt = (char )&pSMBt->hdr.Protocol + get_unaligned_le16(&pSMBt->t2_rsp.DataOffset); data_area_of_src = (char )&pSMBs->hdr.Protocol + get_unaligned_le16(&pSMBs->t2_rsp.DataOffset); data_area_of_tgt += total_in_tgt; ... memcpy(data_area_of_tgt, data_area_of_src, total_in_src);
A small DataOffset can push a pointer below the actual byte area, overwriting header fields; a large one can push it past the buffer end, causing out-of-bounds heap reads (source) or writes (target). The BCC overflow guard does not prevent this: BCC reflects how much data is present, while DataOffset controls where in the buffer it starts.
The "validate target area" comment present since the function was first written in 2005 was a placeholder that was never implemented.
Add lower- and upper-bound checks for both data pointers before the memcpy, and before any target header fields are modified.(CVE-2026-89633)
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix UAF and buffer leak in cifs_check_trans2() for malformed secondary T2
When a valid primary TRANSACT2 response has been received (mid->resp_buf set, mid->multiRsp true) and a subsequent secondary response causes cifs_check_trans2() to return false -- either because the SMB header is invalid (malformed != 0) or because check2ndT2() rejects the PDU -- handle_mid() overwrites mid->resp_buf with the new buffer (leaking the primary buffer) and, because mid->multiRsp is set, skips the server->smallbuf/bigbuf NULL-out. When the user thread frees mid->resp_buf, server->smallbuf or server->bigbuf is left dangling; the demux thread reuses it for the next packet, resulting in a use-after-free.
Combine both early-exit conditions and, when mid->multiRsp is already set, abort the pending transaction inline: set multiEnd, call dequeue_mid() with malformed=true, and return true so handle_mid() exits without touching mid->resp_buf or the server buffer pointers.(CVE-2026-89637)
In the Linux kernel, the following vulnerability has been resolved:
ceph: bound xattr value length in __build_xattrs()
__build_xattrs() decodes the MDS-supplied xattr blob one attribute at a time. For each attribute it reads a 32-bit name length, advances past the name bytes, reads a 32-bit value length, records the value pointer, and advances past the value bytes. The two length fields are read with ceph_decode_32_safe(), but the value bytes themselves are advanced over with a bare "p += len" and no ceph_decode_need() check that "len" bytes remain in the blob.
For every attribute except the last, the next iteration's ceph_decode_32_safe() on the following name length implicitly verifies that the previous value did not run past the blob end. The final attribute has no successor, so its decoded value length is never checked against the blob bounds. A malicious or compromised metadata server can set the last attribute's value length larger than the bytes actually present in the blob.
The blob is a dedicated kvmalloc() allocation sized to the wire length (ceph_buffer_new() in ceph_fill_inode()). __set_xattr() records the oversized length in xattr->val_len verbatim, and a later getxattr(2) runs memcpy(value, xattr->val, xattr->val_len) into a user-supplied buffer, copying bytes past the end of the allocation back to user space.
Impact: a malicious metadata server discloses adjacent kernel heap bytes to a local user via getxattr(2) on a CephFS file. Add the missing ceph_decode_need() so an out-of-bounds value length on the final attribute fails the decode and returns -EIO instead of being stored.(CVE-2026-89649)
In the Linux kernel, the following vulnerability has been resolved:
ceph: bound num_export_targets array for mds info v2/v3
ceph_mdsmap_decode() in fs/ceph/mdsmap.c reads num_export_targets from each per-mds info record and advances the decode cursor by num_export_targets * sizeof(u32) without first checking that many bytes remain. The only upper-bound check that catches a runaway cursor (*p > info_end) is gated on info_v >= 4, because info_end is left NULL for info_v 2 and 3. When the monitor sends an MDS map whose per-mds info version is 2 or 3 with an oversized num_export_targets, the cursor moves past the message front buffer and the later export-targets loop calls the unchecked ceph_decode_32() on out-of-bounds memory.
A kernel client processes CEPH_MSG_MDS_MAP from its monitor session (net/ceph/mon_client.c dispatches it; fs/ceph/super.c routes it to ceph_mdsc_handle_mdsmap(), which sets end to the front buffer bound and calls ceph_mdsmap_decode()). A malicious or compromised monitor, or an on-path attacker on an unsigned/unencrypted messenger session, can therefore drive an out-of-bounds read in the client kernel; on x86_64 with KASAN it is reported as a slab-out-of-bounds read in ceph_mdsmap_decode(). The decoded values land in the internal info->export_targets[] array, so the consequence is a kernel out-of-bounds read, not an information leak to the attacker.
Impact: a malicious or compromised Ceph monitor sending an MDS map with a per-mds info version of 2 or 3 and an oversized num_export_targets field triggers an out-of-bounds read in the CephFS client kernel.
Add a ceph_decode_need() for the export-targets array before advancing the cursor, so the bound is enforced for every info_v >= 2, not only info_v >= 4. This mirrors the count-then-need idiom already used for m_data_pg_pools later in the same function.
Compute the export-targets byte count with size_mul() and reuse that checked length when advancing the cursor, so the attacker-controlled num_export_targets multiplication fails closed on overflow rather than relying on the later kcalloc() guard.(CVE-2026-89650)
In the Linux kernel, the following vulnerability has been resolved:
ceph: bound copied dentry name length in NFS export get_name
ceph_get_name() copies the MDS-supplied name into the caller's NAME_MAX-sized buffer with memcpy(name, rinfo->dname, rinfo->dname_len) and then writes name[rinfo->dname_len] = 0, without checking dname_len against NAME_MAX. A malicious or buggy MDS that returns a LOOKUPNAME reply with dname_len > NAME_MAX overflows the buffer. __get_snap_name() copies rde->name / rde->name_len the same unchecked way.
Impact: a malicious or compromised Ceph MDS overflows the NAME_MAX name buffer in a client's NFS-export get_name path, a slab out-of-bounds write reported by KASAN. Reachable when a CephFS mount is re-exported over NFS.
Add ceph_export_copy_name(), which rejects lengths above NAME_MAX with -ENAMETOOLONG before the copy, and use it in both ceph_get_name() and __get_snap_name().(CVE-2026-89652)
In the Linux kernel, the following vulnerability has been resolved:
ceph: fix UAF in __kick_flushing_caps() on cf entry freed during unlock
list_for_each_entry() iterates ci->i_cap_flush_list but drops i_ceph_lock to send cap messages. During the unlock window, handle_cap_flush_ack() can acquire i_ceph_lock, detach cf entries with tid <= flush_tid from the list, release i_ceph_lock, and free them via ceph_free_cap_flush() outside any lock. When the original thread reacquires i_ceph_lock and the for-loop macro advances via cf = list_next_entry(cf, i_list), it dereferences cf->i_list.next on freed memory.
The race timeline:
__kick_flushing_caps() handle_cap_flush_ack() ----------------------- ----------------------- holds i_ceph_lock <--- iterates to cf (tid=10) prepares FLUSH message drops i_ceph_lock <--- __send_cap() ── FLUSH(tid=10) MDS sends FLUSH_ACK(tid=10) ---> acquires i_ceph_lock cf->tid(10) <= flush_tid(10), detaches cf from i_cap_flush_list drops i_ceph_lock ceph_free_cap_flush(cf) <- frees it! acquires i_ceph_lock <--- for-loop advances: cf = list_next_entry(cf, i_list) -- UAF on freed cf->i_list.next
The cf was just sent by __kick_flushing_caps itself via __send_cap(). The MDS may respond with FLUSH_ACK quickly enough that handle_cap_flush_ack() frees cf before __kick_flushing_caps can finish the iteration.
Fix by converting to a manual while loop: save the next pointer under i_ceph_lock before dropping it, then use the saved pointer after reacquiring, so the potentially-freed cf is never accessed again.(CVE-2026-89655)
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Bound rsp_info_len to avoid OOB sense-data read
In qla2x00_status_entry(), the FWI2 status path advances sense_data and shrinks par_sense_len by rsp_info_len:
if (IS_FWI2_CAPABLE(ha)) {
sense_data += rsp_info_len;
par_sense_len -= rsp_info_len;
}
rsp_info_len is a 32-bit value taken directly from the target's FCP response (sf.rsp_data_len), while par_sense_len is the IOCB data area size (28 bytes for 24xx, 60 bytes for 29xx). A hostile or buggy target reporting an rsp_info_len larger than par_sense_len makes the unsigned subtraction underflow to a huge value and advances sense_data out of bounds.
The underflowed par_sense_len then defeats the cap in qla2x00_handle_sense():
if (sense_len > par_sense_len)
sense_len = par_sense_len;
memcpy(cp->sense_buffer, sense_data, sense_len);
so the memcpy reads up to SCSI_SENSE_BUFFERSIZE bytes from the out-of-bounds sense_data pointer, leaking adjacent response-ring/heap memory into the command's sense buffer.
Clamp rsp_info_len to par_sense_len before the subtraction so par_sense_len can never underflow and sense_data stays within the IOCB data area. The fix sits before the comp_status switch, covering both qla2x00_handle_sense() call sites.(CVE-2026-89846)
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Avoid double completion in async IOCB timeout
qla2x00_async_iocb_timeout() tries to abort a timed-out async IOCB. When qla24xx_async_abort_cmd() fails, both the SRB_LOGIN_CMD path and the SRB_CTRL_VP/default path scan outstanding_cmds[] for the SRB and then call sp->done(sp, QLA_FUNCTION_TIMEOUT) unconditionally, without checking whether the SRB was actually found and removed.
If the response ISR completes the same handle first, it removes the SRB under qp_lock_ptr and runs sp->done() -> complete(sp->comp). The submitter qla24xx_control_vp() wakes from wait_for_completion(), clears sp->comp, drops its reference and returns, reclaiming the on-stack completion. The timer reference keeps the SRB alive across the timeout handler, but not the submitter's stack. The timeout then issues a second sp->done() -> qla_ctrlvp_sp_done(), which evaluates "if (sp->comp) complete(sp->comp)"; with the pointer loaded before the submitter's NULL store, complete() writes into the freed stack frame, a use-after-free.
Track whether this path removed the SRB from outstanding_cmds and only call sp->done() when it did, so the command is completed exactly once by whichever path owns it. This mirrors the sp_found guard already used in qla24xx_abort_iocb_timeout().(CVE-2026-89847)
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Zero dport diagnostics buffer to avoid info leak
qla2x00_do_dport_diagnostics() allocates the qla_dport_diag response buffer with kmalloc_obj() (non-zeroing) and, on success, copies the full sizeof(*dd) back to user space via sg_copy_from_buffer(). The inbound sg_copy_to_buffer() only fills as many bytes as the user request payload provides, and qla26xx_dport_diagnostics() zeroes only dd->buf. The options and unused[] fields are therefore copied out uninitialized, leaking kernel heap contents to user space.
Allocate with kzalloc_obj(), matching qla2x00_do_dport_diagnostics_v2().(CVE-2026-89859)
In the Linux kernel, the following vulnerability has been resolved:
tracing: Take trace_array reference when opening options file
The options files do not take the trace_array reference for the options they represent. This could cause a use-after-free kernel crash if one of these files is opened by one task and another task removes the instance that the option is for. Because it doesn't take a reference upon opening, it will not stop the removal which will free the options descriptor that is being used.
As the options are somewhat dynamic in their creation at boot up, each file represents a flag in the trace_array. The trace_array has an array of indexes to represent each of these flags that is stored in the trace_flags_index array. The address of the index array element is used to pass to the inode->i_private pointer. Then that element is read which holds the index (which represents the flag) and then the index is used to calculate the trace_array descriptor from its trace_flags_index array.
One issue is that the index element can not be referenced until the trace_array's reference is taken. To handle this, create a new helper function called: trace_array_options_get() that will iterate all the existing trace_arrays in the ftrace_trace_arrays list (under the trace_types_lock), and compare the passed in address of the index element with the entire array of the trace_array's trace_flags_index array. If it matches, then up the corresponding trace_array's reference and return.(CVE-2026-90013)
| URL | Type | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-5.10.0-334.0.0.235.oe2203sp4.aarch64.rpm",
"bpftool-debuginfo-5.10.0-334.0.0.235.oe2203sp4.aarch64.rpm",
"kernel-5.10.0-334.0.0.235.oe2203sp4.aarch64.rpm",
"kernel-debuginfo-5.10.0-334.0.0.235.oe2203sp4.aarch64.rpm",
"kernel-debugsource-5.10.0-334.0.0.235.oe2203sp4.aarch64.rpm",
"kernel-devel-5.10.0-334.0.0.235.oe2203sp4.aarch64.rpm",
"kernel-headers-5.10.0-334.0.0.235.oe2203sp4.aarch64.rpm",
"kernel-source-5.10.0-334.0.0.235.oe2203sp4.aarch64.rpm",
"kernel-tools-5.10.0-334.0.0.235.oe2203sp4.aarch64.rpm",
"kernel-tools-debuginfo-5.10.0-334.0.0.235.oe2203sp4.aarch64.rpm",
"kernel-tools-devel-5.10.0-334.0.0.235.oe2203sp4.aarch64.rpm",
"perf-5.10.0-334.0.0.235.oe2203sp4.aarch64.rpm",
"perf-debuginfo-5.10.0-334.0.0.235.oe2203sp4.aarch64.rpm",
"python3-perf-5.10.0-334.0.0.235.oe2203sp4.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-334.0.0.235.oe2203sp4.aarch64.rpm"
],
"src": [
"kernel-5.10.0-334.0.0.235.oe2203sp4.src.rpm"
],
"x86_64": [
"bpftool-5.10.0-334.0.0.235.oe2203sp4.x86_64.rpm",
"bpftool-debuginfo-5.10.0-334.0.0.235.oe2203sp4.x86_64.rpm",
"kernel-5.10.0-334.0.0.235.oe2203sp4.x86_64.rpm",
"kernel-debuginfo-5.10.0-334.0.0.235.oe2203sp4.x86_64.rpm",
"kernel-debugsource-5.10.0-334.0.0.235.oe2203sp4.x86_64.rpm",
"kernel-devel-5.10.0-334.0.0.235.oe2203sp4.x86_64.rpm",
"kernel-headers-5.10.0-334.0.0.235.oe2203sp4.x86_64.rpm",
"kernel-source-5.10.0-334.0.0.235.oe2203sp4.x86_64.rpm",
"kernel-tools-5.10.0-334.0.0.235.oe2203sp4.x86_64.rpm",
"kernel-tools-debuginfo-5.10.0-334.0.0.235.oe2203sp4.x86_64.rpm",
"kernel-tools-devel-5.10.0-334.0.0.235.oe2203sp4.x86_64.rpm",
"perf-5.10.0-334.0.0.235.oe2203sp4.x86_64.rpm",
"perf-debuginfo-5.10.0-334.0.0.235.oe2203sp4.x86_64.rpm",
"python3-perf-5.10.0-334.0.0.235.oe2203sp4.x86_64.rpm",
"python3-perf-debuginfo-5.10.0-334.0.0.235.oe2203sp4.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:22.03-LTS-SP4",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP4"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.10.0-334.0.0.235.oe2203sp4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "Critical"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:ALSA: caiaq: Use snd_card_free_when_closed() at disconnectionThe USB disconnect callback is supposed to be short and not too-longwaiting. OTOH, the current code uses snd_card_free() atdisconnection, but this waits for the close of all used fds, hence itcan take long. It eventually blocks the upper layer USB ioctls, whichmay trigger a soft lockup.An easy workaround is to replace snd_card_free() withsnd_card_free_when_closed(). This variant returns immediately whilethe release of resources is done asynchronously by the card devicerelease at the last close.This patch also splits the code to the disconnect and the free phases;the former is called immediately at the USB disconnect callback whilethe latter is called from the card destructor.(CVE-2024-56531)\n\nIn the Linux kernel, the following vulnerability has been resolved:xsk: fix OOB map writes when deleting elementsJordy says: In the xsk_map_delete_elem function an unsigned integer(map-\u0026gt;max_entries) is compared with a user-controlled signed integer(k). Due to implicit type conversion, a large unsigned value formap-\u0026gt;max_entries can bypass the intended bounds check: if (k \u0026gt;= map-\u0026gt;max_entries) return -EINVAL;This allows k to hold a negative value (between -2147483648 and -2),which is then used as an array index in m-\u0026gt;xsk_map[k], which resultsin an out-of-bounds access. spin_lock_bh(\u0026amp;m-\u0026gt;lock); map_entry = \u0026amp;m-\u0026gt;xsk_map[k]; // Out-of-bounds map_entry old_xs = unrcu_pointer(xchg(map_entry, NULL)); // Oob write if (old_xs) xsk_map_sock_delete(old_xs, map_entry); spin_unlock_bh(\u0026amp;m-\u0026gt;lock);The xchg operation can then be used to cause an out-of-bounds write.Moreover, the invalid map_entry passed to xsk_map_sock_delete can leadto further memory corruption. It indeed results in following splat:[76612.897343] BUG: unable to handle page fault for address: ffffc8fc2e461108[76612.904330] #PF: supervisor write access in kernel mode[76612.909639] #PF: error_code(0x0002) - not-present page[76612.914855] PGD 0 P4D 0[76612.917431] Oops: Oops: 0002 [#1] PREEMPT SMP[76612.921859] CPU: 11 UID: 0 PID: 10318 Comm: a.out Not tainted 6.12.0-rc1+ #470[76612.929189] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019[76612.939781] RIP: 0010:xsk_map_delete_elem+0x2d/0x60[76612.944738] Code: 00 00 41 54 55 53 48 63 2e 3b 6f 24 73 38 4c 8d a7 f8 00 00 00 48 89 fb 4c 89 e7 e8 2d bf 05 00 48 8d b4 eb 00 01 00 00 31 ff \u0026lt;48\u0026gt; 87 3e 48 85 ff 74 05 e8 16 ff ff ff 4c 89 e7 e8 3e bc 05 00 31[76612.963774] RSP: 0018:ffffc9002e407df8 EFLAGS: 00010246[76612.969079] RAX: 0000000000000000 RBX: ffffc9002e461000 RCX: 0000000000000000[76612.976323] RDX: 0000000000000001 RSI: ffffc8fc2e461108 RDI: 0000000000000000[76612.983569] RBP: ffffffff80000001 R08: 0000000000000000 R09: 0000000000000007[76612.990812] R10: ffffc9002e407e18 R11: ffff888108a38858 R12: ffffc9002e4610f8[76612.998060] R13: ffff888108a38858 R14: 00007ffd1ae0ac78 R15: ffffc9002e4610c0[76613.005303] FS: 00007f80b6f59740(0000) GS:ffff8897e0ec0000(0000) knlGS:0000000000000000[76613.013517] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[76613.019349] CR2: ffffc8fc2e461108 CR3: 000000011e3ef001 CR4: 00000000007726f0[76613.026595] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[76613.033841] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400[76613.041086] PKRU: 55555554[76613.043842] Call Trace:[76613.046331] \u0026lt;TASK\u0026gt;[76613.048468] ? __die+0x20/0x60[76613.051581] ? page_fault_oops+0x15a/0x450[76613.055747] ? search_extable+0x22/0x30[76613.059649] ? search_bpf_extables+0x5f/0x80[76613.063988] ? exc_page_fault+0xa9/0x140[76613.067975] ? asm_exc_page_fault+0x22/0x30[76613.072229] ? xsk_map_delete_elem+0x2d/0x60[76613.076573] ? xsk_map_delete_elem+0x23/0x60[76613.080914] __sys_bpf+0x19b7/0x23c0[76613.084555] __x64_sys_bpf+0x1a/0x20[76613.088194] do_syscall_64+0x37/0xb0[76613.091832] entry_SYSCALL_64_after_hwframe+0x4b/0x53[76613.096962] RIP: 0033:0x7f80b6d1e88d[76613.100592] Code: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 8b 0d 73 b5 0f 00 f7 d8 64 89 01 48[76613.119631] RSP: 002b:00007ffd1ae0ac68 EFLAGS: 00000206 ORIG_RAX: 0000000000000141[76613.131330] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f80b6d1e88d[76613.142632] RDX: 0000000000000098 RSI: 00007ffd1ae0ad20 RDI: 0000000000000003[76613.153967] RBP: 00007ffd1ae0adc0 R08: 0000000000000000 R09: 0000000000000000[76613.166030] R10: 00007f80b6f77040 R11: 0000000000000206 R12: 00007ffd1ae0aed8[76613.177130] R13: 000055ddf42ce1e9 R14: 000055ddf42d0d98 R15: 00---truncated---(CVE-2024-56614)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nALSA: usb-audio: Fix potential overflow of PCM transfer buffer\n\nThe PCM stream data in USB-audio driver is transferred over USB URB\npacket buffers, and each packet size is determined dynamically. The\npacket sizes are limited by some factors such as wMaxPacketSize USB\ndescriptor. OTOH, in the current code, the actually used packet sizes\nare determined only by the rate and the PPS, which may be bigger than\nthe size limit above. This results in a buffer overflow, as reported\nby syzbot.\n\nBasically when the limit is smaller than the calculated packet size,\nit implies that something is wrong, most likely a weird USB\ndescriptor. So the best option would be just to return an error at\nthe parameter setup time before doing any further operations.\n\nThis patch introduces such a sanity check, and returns -EINVAL when\nthe packet size is greater than maxpacksize. The comparison with\nep-\u0026gt;packsize[1] alone should suffice since it\u0026apos;s always equal or\ngreater than ep-\u0026gt;packsize[0].(CVE-2025-40269)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: cfg80211: cancel pmsr_free_wk in cfg80211_pmsr_wdev_down\n\nWhen the nl80211 socket that originated a PMSR request is\nclosed, cfg80211_release_pmsr() sets the request\u0026apos;s nl_portid\nto zero and schedules pmsr_free_wk to process the abort\nasynchronously. If the interface is concurrently torn down\nbefore that work runs, cfg80211_pmsr_wdev_down() calls\ncfg80211_pmsr_process_abort() directly. However, the already-\nscheduled pmsr_free_wk work item remains pending and may run\nafter the interface has been removed from the driver. This\ncould cause the driver\u0026apos;s abort_pmsr callback to operate on a\ntorn-down interface, leading to undefined behavior and\npotential crashes.\n\nCancel pmsr_free_wk synchronously in cfg80211_pmsr_wdev_down()\nbefore calling cfg80211_pmsr_process_abort(). This ensures any\npending or in-progress work is drained before interface teardown\nproceeds, preventing the work from invoking the driver abort\ncallback after the interface is gone.(CVE-2026-31548)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/page_alloc: clear page-\u0026gt;private in free_pages_prepare()\n\nSeveral subsystems (slub, shmem, ttm, etc.) use page-\u0026gt;private but don\u0026apos;t\nclear it before freeing pages. When these pages are later allocated as\nhigh-order pages and split via split_page(), tail pages retain stale\npage-\u0026gt;private values.\n\nThis causes a use-after-free in the swap subsystem. The swap code uses\npage-\u0026gt;private to track swap count continuations, assuming freshly\nallocated pages have page-\u0026gt;private == 0. When stale values are present,\nswap_count_continued() incorrectly assumes the continuation list is valid\nand iterates over uninitialized page-\u0026gt;lru containing LIST_POISON values,\ncausing a crash:\n\n KASAN: maybe wild-memory-access in range [0xdead000000000100-0xdead000000000107]\n RIP: 0010:__do_sys_swapoff+0x1151/0x1860\n\nFix this by clearing page-\u0026gt;private in free_pages_prepare(), ensuring all\nfreed pages have clean state regardless of previous use.(CVE-2026-43303)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nALSA: caiaq: Handle probe errors properly\n\nThe probe procedure of setup_card() in caiaq driver doesn\u0026apos;t treat the\nerror cases gracefully, e.g. the error from snd_card_register() calls\nsnd_card_free() but continues. This would lead to a UAF for the\nfurther calls like snd_usb_caiaq_control_init(), as Berk suggested in\nanother patch in the link below.\n\nHowever, the problem is not only that; in general, this function drops\nthe all error handlings (as it\u0026apos;s a void function) although its caller\ncan propagate an error to snd_probe(), which eventually calls\nsnd_card_free() as a proper error path. That said, we should treat\neach error case in setup_card(), and just return the error code\npromptly, which is then handled later as a fatal error in snd_probe().\n\nThis patch achieves it by changing the setup_card() to return an error\ncode. Also, the superfluous snd_card_free() call is removed, too.\n\nNote that card-\u0026gt;private_free can be set still safely at returning an\nerror. All called functions in card_free() have checks of the\nunassigned resources or NULL checks.(CVE-2026-46004)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsctp: stream: fully roll back denied add-stream state\n\nWhen ADD_OUT_STREAMS is denied, SCTP only shrinks the queued chunks and\nthen lowers outcnt. That leaves removed stream metadata behind, so a\nlater re-add can reuse a stale ext and hit a null-pointer dereference in\nthe scheduler get path.\n\nFix the rollback by tearing down the removed stream state the same way\nother stream resizes do. Unschedule the current scheduler state, drop\nthe removed stream ext state with sctp_stream_outq_migrate(), and then\nreschedule the remaining streams.\n\nThis keeps scheduler-private RR/FC/PRIO lists consistent while fully\nrolling back denied outgoing stream additions.(CVE-2026-52929)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nlibceph: handle rbtree insertion error in decode_choose_args()\n\nA message of type CEPH_MSG_OSD_MAP contains an OSD map that itself\ncontains a CRUSH map. The received CRUSH map may optionally contain\nchoose_args that get decoded in decode_choose_args(). In this function,\nnum_choose_arg_maps is read from the message, and a corresponding number\nof crush_choose_arg_maps gets decoded afterwards. Each\ncrush_choose_arg_map has a choose_args_index, which serves as the key\nwhen inserting it into the choose_args rbtree of the decoded crush_map.\nIf a (potentially corrupted) message contains two crush_choose_arg_maps\nwith the same index, the assertion in insert_choose_arg_map() triggers a\nkernel BUG when trying to insert the second crush_choose_arg_map.\n\nThis patch fixes the issue by switching to the non-asserting rbtree\ninsertion function and rejecting the message if the insertion fails.\n\n[ idryomov: changelog ](CVE-2026-52954)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: Reject wrapped offset in kvm_reset_dirty_gfn()\n\nkvm_reset_dirty_gfn() guards the gfn range with\n\n\tif (!memslot || (offset + __fls(mask)) \u0026gt;= memslot-\u0026gt;npages)\n\t\treturn;\n\nbut offset is u64 and the addition is unchecked. The check can be\nsilently bypassed by a u64 wrap.\n\nThe dirty ring backing those entries is MAP_SHARED at\nKVM_DIRTY_LOG_PAGE_OFFSET of the vcpu fd, so the VMM can rewrite the\nslot and offset fields of any entry between when the kernel pushes\nthem and when KVM_RESET_DIRTY_RINGS consumes them. On reset,\nkvm_dirty_ring_reset() re-reads the values via READ_ONCE() and feeds\nthem straight back into this check; only the flags handshake is\ntreated as the handover, the slot/offset payload is taken on trust.\n\nCrafting two entries\n\n\tentry[i].offset = 0xffffffffffffffc1\n\tentry[i+1].offset = 0\n\nmakes the coalescing loop in kvm_dirty_ring_reset() compute\n\n\tdelta = (s64)(0 - 0xffffffffffffffc1) = 63\n\nwhich falls in [0, BITS_PER_LONG), so it folds entry[i+1] into the\nexisting mask by setting bit 63. The trailing kvm_reset_dirty_gfn()\ncall then sees offset = 0xffffffffffffffc1 and __fls(mask) = 63;\nthe sum is 0 in u64 and the bounds check passes.\n\nThat offset propagates into kvm_arch_mmu_enable_log_dirty_pt_masked()\nunchanged. On the legacy MMU path -- kvm_memslots_have_rmaps() ==\ntrue, i.e. shadow paging, any VM that has allocated shadow roots, or\na write-tracked slot -- it reaches gfn_to_rmap(), which indexes\nslot-\u0026gt;arch.rmap[0][] with a near-U64_MAX gfn. That is an\nout-of-bounds load of a kvm_rmap_head, followed by a conditional\nclear of PT_WRITABLE_MASK in whatever the loaded pointer points at.\nThe path is reachable from any process holding /dev/kvm.\n\nRange-check offset on its own first, so the addition cannot wrap.\nmemslot-\u0026gt;npages is bounded well below U64_MAX, so once offset \u0026lt;\nnpages holds, offset + __fls(mask) (with __fls(mask) \u0026lt; BITS_PER_LONG)\nstays in range.(CVE-2026-52969)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: usb: rtl8150: fix use-after-free in rtl8150_start_xmit()\n\nsyzbot reported a KASAN slab-use-after-free read in rtl8150_start_xmit()\nwhen accessing skb-\u0026gt;len for tx statistics after usb_submit_urb() has\nbeen called:\n\n BUG: KASAN: slab-use-after-free in rtl8150_start_xmit+0x71f/0x760\n drivers/net/usb/rtl8150.c:712\n Read of size 4 at addr ffff88810eb7a930 by task kworker/0:4/5226\n\nThe URB completion handler write_bulk_callback() frees the skb via\ndev_kfree_skb_irq(dev-\u0026gt;tx_skb). The URB may complete on another CPU\nin softirq context before usb_submit_urb() returns in the submitter,\nso by the time the submitter reads skb-\u0026gt;len the skb has already been\nqueued to the per-CPU completion_queue and freed by net_tx_action():\n\n CPU A (xmit) CPU B (USB completion softirq)\n ------------ ------------------------------\n dev-\u0026gt;tx_skb = skb;\n usb_submit_urb() --+\n |-------\u0026gt; write_bulk_callback()\n | dev_kfree_skb_irq(dev-\u0026gt;tx_skb)\n | net_tx_action()\n | napi_skb_cache_put() \u0026lt;-- free\n netdev-\u0026gt;stats.tx_bytes |\n += skb-\u0026gt;len; \u0026lt;-- UAF read\n\nFix it by caching skb-\u0026gt;len before submitting the URB and using the\ncached value when updating the tx_bytes counter.\n\nThe pre-existing tx_bytes semantics are preserved: the counter tracks\nthe original frame length (skb-\u0026gt;len), not the ETH_ZLEN/USB-alignment\npadded \u0026quot;count\u0026quot; value that is handed to the device. Changing that\nwould be a user-visible accounting change and is out of scope for\nthis UAF fix.(CVE-2026-52982)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nALSA: PCM: Fix wait queue list corruption in snd_pcm_drain() on linked streams\n\nsnd_pcm_drain() uses init_waitqueue_entry which does not clear\nentry.prev/next, and add_wait_queue with a conditional\nremove_wait_queue that is skipped when to_check is no longer\nin the group after concurrent UNLINK. The orphaned wait entry\nremains on the unlinked substream sleep queue. On the next\ndrain iteration, add_wait_queue adds the entry to a new queue\nwhile still linked on the old one, corrupting both lists. A\nsubsequent wake_up dereferences NULL at the func pointer\n(mapped from the spinlock at offset 0 of the misinterpreted\nwait_queue_head_t), causing a kernel panic.\n\nReplace init_waitqueue_entry/add_wait_queue/conditional\nremove_wait_queue with init_wait_entry/prepare_to_wait/\nfinish_wait. init_wait_entry clears prev/next via\nINIT_LIST_HEAD on each iteration and sets\nautoremove_wake_function which auto-removes the entry on\nwake-up. finish_wait safely handles both the already-removed\nand still-queued cases.(CVE-2026-53242)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nieee802154: 6lowpan: only accept IPv6 packets in lowpan_xmit()\n\nThe aoe driver (or similar) generates a non-IPv6 packet\n(e.g., ETH_P_AOE) and queues it for transmission via dev_queue_xmit()\non a 6LoWPAN interface (configured by the user or test case).\n\nSince the packet is not IPv6, the 6LoWPAN header_ops-\u0026gt;create function\n(lowpan_header_create or header_create) returns early without initializing\nthe lowpan_addr_info structure in the skb headroom.\n\nIn the transmit function (lowpan_xmit), the driver calls lowpan_header\n(or setup_header) which unconditionally copies and uses the lowpan_addr_info\nfrom the headroom, which contains uninitialized data.\n\nFix this by dropping non IPv6 packets.\n\nA similar fix is needed in net/bluetooth/6lowpan.c bt_xmit().(CVE-2026-63870)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: wacom: Fix OOB write in wacom_hid_set_device_mode()\n\nwacom_hid_set_device_mode() currently assumes that the HID_DG_INPUTMODE\nusage is always located in the first field (field[0]) of the feature report.\nHowever, a device can specify HID_DG_INPUTMODE in a different field.\n\nIf HID_DG_INPUTMODE is in a field other than the first one and the first\nfield has a report_count smaller than the usage_index of HID_DG_INPUTMODE,\nthis leads to an out-of-bounds write to r-\u0026gt;field[0]-\u0026gt;value.\n\nFix this by storing the field index of HID_DG_INPUTMODE in \u0026apos;struct\nhid_data\u0026apos; during feature mapping. In wacom_hid_set_device_mode(), use\nthis stored field index to access the correct field and add bounds\nchecks to ensure both the field index and the value index are within\nvalid ranges before writing.(CVE-2026-63916)\n\nIn the Linux kernel, the following vulnerability has been resolved: net/smc: reject CHID-0 ACCEPT that matches an empty ism_dev slot. On the SMC-D client, slot 0 of ini-\u0026gt;ism_dev[]/ini-\u0026gt;ism_chid[] is reserved for an SMC-Dv1 device. smc_find_ism_v2_device_clnt() populates V2 entries starting at index 1, so when no V1 device is selected slot 0 is left in its kzalloc()\u0026apos;ed state with ism_dev[0] == NULL and ism_chid[0] == 0. smc_v2_determine_accepted_chid() then matches the peer\u0026apos;s CHID against the array starting from index 0 using the CHID alone. A malicious peer replying to a SMC-Dv2-only proposal with d1.chid == 0 matches the empty slot, ini-\u0026gt;ism_selected becomes 0, and the subsequent ism_dev[0]-\u0026gt;lgr_lock dereference in smc_conn_create() causes a NULL pointer dereference. Require ism_dev[i] to be non-NULL before accepting a CHID match.(CVE-2026-64048)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nstaging: vme_user: bound slave read/write to the kern_buf size\n\nThe SLAVE-path helpers buffer_to_user() and buffer_from_user() copy\n\u0026apos;count\u0026apos; bytes into/out of the fixed-size kern_buf (size_buf ==\nPCI_BUF_SIZE == 0x20000, 128 KiB) using *ppos as the offset, without\nbounding *ppos + count against size_buf.\n\nvme_user_write()/vme_user_read() only clamp count to the VME window size\n(image_size = vme_get_size(resource)), which VME_SET_SLAVE sets from the\nuser-supplied slave.size -- validated against the VME address space (up\nto VME_A32_MAX = 4 GiB), not against PCI_BUF_SIZE. When the window\nexceeds 128 KiB, a write()/read() copies past the kern_buf allocation.\n\nClamp count against size_buf in both helpers, with an early return when\n*ppos is already at/after the buffer end. *ppos is \u0026gt;= 0 here (the caller\nrejects negative offsets), so size_buf - *ppos cannot wrap. This mirrors\nthe existing clamp in the MASTER-path helpers resource_to_user() /\nresource_from_user(), and matches the read()/write() convention of a\nshort transfer at end-of-buffer.\n\nFound by static analysis (CodeQL taint tracking + CBMC bounded model\nchecking) and confirmed dynamically under KASAN with the vme_fake bridge:\n\n BUG: KASAN: slab-out-of-bounds in _copy_from_user+0x2d/0x80\n Write of size 262144 at addr ffff888004100000 by task trigger/68\n _copy_from_user+0x2d/0x80\n vme_user_write+0x13e/0x240 [vme_user]\n vfs_write+0x1b8/0x7a0\n ksys_write+0xb8/0x150(CVE-2026-64449)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/damon/ops-common: handle extreme intervals in damon_hot_score()\n\nFix three issues in damon_hot_score() that comes from wrong handling of\nextreme (zero or too high) monitoring intervals user setup.\n\nWhen the user sets sampling interval zero, damon_max_nr_accesses(), which\nis called from damon_hot_score(), causes a divide-by-zero. Needless to\nsay, it is a problem.\n\nWhen the user sets the aggregation interval zero, the function returns\nzero. It is wrong, since the real maximum nr_acceses in the setup should\nbe one. Worse yet, it can cause another divide-by-zero from its caller,\ndamon_hot_score(), since it uses damon_max_nr_accesses() return value as a\ndenominator.\n\nWhen the user sets the aggregation interval very high, damon_hot_score()\ncould return a value out of [0, DAMOS_MAX_SCORE] range. Since the return\nvalue is used as an index to the regions_score_histogram array, which is\nDAMOS_MAX_SCORE+1 size, it causes out of bounds array access.\n\nThe issues can be relatively easily reproduced like below. The sysfs\nwrite permission is required, though.\n\n # ./damo start --damos_action lru_prio --damos_quota_space 100M \\\n --damos_quota_interval 1s\n # cd /sys/kernel/mm/damon/admin/kdamonds/0\n # echo 0 \u0026gt; contexts/0/monitoring_attrs/intervals/sample_us\n # echo 0 \u0026gt; contexts/0/monitoring_attrs/intervals/aggr_us\n # echo commit \u0026gt; state\n # dmesg\n [...]\n [ 131.329762] Oops: divide error: 0000 [#1] SMP NOPTI\n [...]\n [ 131.336089] RIP: 0010:damon_hot_score+0x27/0xd0\n [...]\n\nFix the divide-by-zero intervals problems by explicitly handling the zero\nintervals in damon_max_nr_accesses(). Fix the out-of-bound array access\nby applying [0, DAMOS_MAX_SCORE] bounds before returning from\ndamon_hot_score().\n\nThe issue was discovered [1] by Sashiko.(CVE-2026-64458)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/rxe: Fix a use-after-free problem in rxe_mmap\n\nrxe_mmap() removes a rxe_mmap_info struct from the pending_mmaps list\nand releases pending_lock while the struct\u0026apos;s kref is still at 1:\n\n list_del_init(\u0026amp;ip-\u0026gt;pending_mmaps);\n spin_unlock_bh(\u0026amp;rxe-\u0026gt;pending_lock); /* ref == 1, no lock held */\n ret = remap_vmalloc_range(vma, ip-\u0026gt;obj, 0); /* walks PTEs */\n [...]\n rxe_vma_open(vma); /* kref_get, ref \u2192 2 */\n remap_vmalloc_range_partial() walks PTEs without any lock.\n\nA concurrent DESTROY_CQ ioctl on another CPU calls:\n\n kref_put(\u0026amp;q-\u0026gt;ip-\u0026gt;ref, rxe_mmap_release) /* ref 1\u21920 */\n vfree(ip-\u0026gt;obj) /* clears vmalloc PTEs mid-walk */\n kfree(ip) /* frees rxe_mmap_info */\n\nThis yields:\n\n 1. Kernel crash, vmalloc_to_page() returns NULL when vfree wins the\n per-PTE race -\u0026gt; vm_insert_page(NULL) \u2192 GPF in validate_page_before_insert\n\n 2. Page UAF, vmalloc_to_page() reads a stale PTE before vfree clears\n it. User VMA holds a PTE to a free\u0026apos;d page which might eventually get\n reallocated later by vmalloc which allows the attacker to get a clean\n page-level UAF.\n\n It is worth noting that even though a page-level UAF is possible given\n the strong primitive, it is statistically very difficult to achieve\n given the very short time window (after the last insert_page and before\n the kref_get).\n\nThe call trace are as below:\n\n Oops: general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] SMP KASAN NOPTI\n KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]\n CPU: 0 UID: 1000 PID: 413 Comm: poc Not tainted 7.0.0-rc5-dirty #28 PREEMPT(lazy)\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014\n RIP: 0010:validate_page_before_insert+0x32/0x300\n Code: e5 41 57 41 56 49 89 fe 41 55 41 54 53 48 89 f3 e8 93 b5 a3 ff 48 8d 7b 08 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 \u0026lt;80\u0026gt; 3c 02 00 0f 85 7b 02 00 00 4c 8b 63 08 31 ff 4d 89 e5 41 83 e5\n RSP: 0018:ffff88811b15f2f0 EFLAGS: 00000202\n RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000\n RDX: 0000000000000001 RSI: 0000000000000000 RDI: 0000000000000008\n RBP: ffff88811b15f318 R08: 0000000000000000 R09: 0000000000000000\n R10: 0000000000000000 R11: 0000000000000000 R12: ffff8881181eee00\n R13: 0000000000000000 R14: ffff8881181eee00 R15: ffff8881181eee20\n FS: 00007b1e000f76c0(0000) GS:ffff8884268e0000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00007b1e00a24ac0 CR3: 0000000116eb3000 CR4: 00000000000006f0\n Call Trace:\n \u0026lt;TASK\u0026gt;\n insert_page+0x8f/0x190\n ? __pfx_insert_page+0x10/0x10\n ? kasan_save_alloc_info+0x38/0x60\n vm_insert_page+0x2e7/0x400\n remap_vmalloc_range_partial+0x212/0x3e0\n remap_vmalloc_range+0x6e/0xb0\n ? __kasan_check_write+0x14/0x30\n rxe_mmap+0x2e9/0x5d0\n ib_uverbs_mmap+0x1ad/0x2c0\n __mmap_region+0x12c2/0x2ad0\n ? __pfx___mmap_region+0x10/0x10\n ? __sanitizer_cov_trace_switch+0x58/0xb0\n ? mas_prev_slot+0x360/0x39c0\n ? __sanitizer_cov_trace_switch+0x58/0xb0\n ? mas_next_slot+0x1e5b/0x2f40\n ? __sanitizer_cov_trace_cmp8+0x18/0x30\n ? unmapped_area_topdown+0x4dd/0x610\n ? kfree+0x1b1/0x440\n ? free_cpumask_var+0x16/0x30\n ? __kasan_slab_free+0x7d/0xa0\n ? __sanitizer_cov_trace_cmp8+0x18/0x30\n mmap_region+0x2e6/0x3c0\n do_mmap+0xa3e/0x12a0\n ? __pfx_do_mmap+0x10/0x10\n ? __kasan_check_write+0x14/0x30\n ? down_write_killable+0xba/0x160\n ? __pfx_down_write_killable+0x10/0x10\n ? __sanitizer_cov_trace_cmp4+0x16/0x30\n vm_mmap_pgoff+0x2d4/0x4a0\n ? __pfx_vm_mmap_pgoff+0x10/0x10\n ? fget+0x1bf/0x270\n ksys_mmap_pgoff+0x40c/0x690\n ? __sanitizer_cov_trace_const_cmp4+0x16/0x30\n ? __pfx_ksys_mmap_pgoff+0x10/0x10\n ? __kasan_check_write+0x14/0x30\n ? _raw_spin_trylock+0xbb/0x130\n ? __pfx__raw_spin_trylock+0x10/0x10\n __x64_sys_mmap+0x135/0x1e0\n x64_sys_c\n---truncated---(CVE-2026-64582)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu/vce: fix integer overflow in image size\n\nFix a security vulnerability where malicious VCE command streams\nwith oversized dimensions (e.g. 65536\u00d765536) cause 32-bit integer\noverflow, wrapping the calculated buffer size to 0. This bypasses\nvalidation and allows GPU firmware to perform out-of-bound memory\naccess.\n\nThe fix uses 64-bit arithmetic to detect overflow and rejects\ninvalid dimensions before they reach the hardware.\n\nV2: remove redundant check\nV3: modify max height value\nV4: remove size64\n\n(cherry picked from commit cbe408dba581755ad1279a487ec786d8927d778d)(CVE-2026-68108)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsctp: fix auth_chunk_list capacity check in sctp_auth_ep_add_chunkid\n\nsctp_auth_ep_add_chunkid() uses SCTP_NUM_CHUNK_TYPES (20) as the\ncapacity limit for ep-\u0026gt;auth_chunk_list, allowing it to hold up to\n20 chunk entries (param_hdr.length up to 24). However, the copy\ndestination asoc-\u0026gt;c.auth_chunks in struct sctp_cookie is only\nSCTP_AUTH_MAX_CHUNKS (16) entries (20 bytes). When more than 16\nchunks are added, sctp_association_init() memcpy overflows the\ndestination by up to 4 bytes.\n\nFix by using SCTP_AUTH_MAX_CHUNKS as the capacity limit, matching\nthe destination capacity.(CVE-2026-68320)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: cfg80211: use wiphy work for socket owner autodisconnect\n\nnl80211_netlink_notify() walks the cfg80211 wireless device list when a\nNETLINK_GENERIC socket is released. If the socket owns a connection, the\nnotifier queues the embedded wdev-\u0026gt;disconnect_wk work item.\n\nThat work is a plain work_struct today. NETDEV_GOING_DOWN cancels it, but a\nNETLINK_URELEASE notifier that already observed conn_owner_nlportid can\nqueue it after that cancel returns. _cfg80211_unregister_wdev() then\nremoves the wdev from the list and waits for RCU readers, but\nsynchronize_net() does not drain work queued by such a reader.\n\nMake the autodisconnect work a wiphy_work instead. The callback already\nneeds the wiphy mutex, and wiphy_work runs under that mutex. This lets\nteardown cancel pending autodisconnect work while holding the mutex,\nwithout a cancel_work_sync() vs. worker locking concern.\n\nAlso cancel the wiphy work after list_del_rcu() and synchronize_net(). Any\nNETLINK_URELEASE notifier that had already reached the wdev list has then\neither queued the work and it is removed, or can no longer find the wdev.(CVE-2026-68404)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mac80211: validate extension-frame layout before RX\n\nExtension frames only have the extension header at the regular 802.11\nheader offset. The generic RX path can still reach helpers and interface\ndispatch code that read regular header address fields before unsupported\nextension subtypes are dropped.\n\nmac80211 currently only handles S1G beacon extension frames. Drop other\nextension subtypes before they can reach regular-header RX processing.\nFor S1G beacons, linearize the SKB with the management-frame path and\nrequire the fixed S1G beacon header, including optional fixed fields\nindicated by frame control, before generic RX dispatch.\n\nRoute S1G beacons through the station/default-link RX path without\nregular-header station lookup. Avoid regular-header address reads in the\nmac80211 RX paths that process S1G extension beacons, including\naccept-frame, duplicate-detection, address-copy, and MLO\naddress-translation paths.\n\nAlso make ieee80211_get_bssid() length-safe before returning the S1G\nsource-address pointer.(CVE-2026-68470)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndm_early_create: fix freeing used table on dm_resume failure\n\nIf dm_resume fails, the kernel attempts to free table with\ndm_table_destroy, but the table was already instantiated with\ndm_swap_table. This commit skips the call to dm_table_destroy in this\ncase.(CVE-2026-72102)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndm-ioctl: fix a possible overflow in list_version_get_info\n\nsizeof(tt-\u0026gt;version) is 12 bytes, but the code writes 16 bytes into the\noutput buffer - info-\u0026gt;vers-\u0026gt;version[0], info-\u0026gt;vers-\u0026gt;version[1],\ninfo-\u0026gt;vers-\u0026gt;version[2] and info-\u0026gt;vers-\u0026gt;next. This can cause buffer\noverflow.\n\nFix this buffer overflow by replacing \u0026quot;sizeof(tt-\u0026gt;version)\u0026quot; with\n\u0026quot;sizeof(struct dm_target_versions)\u0026quot;.(CVE-2026-72106)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndm thin metadata: fix metadata snapshot consistency on commit failure\n\n__reserve_metadata_snap() and __release_metadata_snap() modify the\nsuperblock\u0026apos;s held_root directly in the block_manager\u0026apos;s buffer. If the\nsubsequent metadata commit fails, the held_root gets flushed to disk\nthrough the abort_transaction path, resulting in inconsistent metadata.\n\nReproducer 1: __reserve_metadata_snap()\n\n1. Create a 2 MiB metadata device and make the region after the 14th\n block inaccessible, to trigger metadata commit failure in the\n subsequent reserve_metadata_snap operation. The 14th block will be\n the shadow destination for the index block.\n\ndmsetup create tmeta --table \u0026quot;0 112 linear /dev/sdc 0\n112 3984 error\u0026quot;\n\n2. Create a 16 MiB thin-pool\n\ndmsetup create tdata --table \u0026quot;0 32768 zero\u0026quot;\ndd if=/dev/zero of=/dev/mapper/tmeta bs=4k count=1\ndmsetup create tpool --table \u0026quot;0 32768 thin-pool /dev/mapper/tmeta \\\n/dev/mapper/tdata 128 0 1 skip_block_zeroing\u0026quot;\n\n3. Take a metadata snapshot to trigger metadata commit failure and\n transaction abort. However, the held_root is written to disk,\n breaking metadata consistency.\n\ndmsetup message tpool 0 \u0026quot;reserve_metadata_snap\u0026quot;\n\nthin_check v1.2.2 result:\n\nBad reference count for metadata block 6. Expected 2, but space map contains 1.\nBad reference count for metadata block 7. Expected 2, but space map contains 1.\nBad reference count for metadata block 13. Expected 1, but space map contains 0.\n\nReproducer 2: __release_metadata_snap()\n\n1. Create a 2 MiB metadata device and make the region after the 16th\n block inaccessible, to trigger metadata commit failure in the\n subsequent release_metadata_snap operation. The 16th block will be\n the shadow destination for the index block.\n\ndmsetup create tmeta --table \u0026quot;0 128 linear /dev/sdc 0\n128 3968 error\u0026quot;\n\n2. Create a 16 MiB thin-pool\n\ndmsetup create tdata --table \u0026quot;0 32768 zero\u0026quot;\ndd if=/dev/zero of=/dev/mapper/tmeta bs=4k count=1\ndmsetup create tpool --table \u0026quot;0 32768 thin-pool /dev/mapper/tmeta \\\n/dev/mapper/tdata 128 0 1 skip_block_zeroing\u0026quot;\n\n3. Reserve then release the metadata snapshot, to trigger metadata\n commit failure and transaction abort. The held_root gets removed\n from the on-disk superblock, causing inconsistent metadata.\n\ndmsetup message tpool 0 \u0026quot;reserve_metadata_snap\u0026quot;\ndmsetup message tpool 0 \u0026quot;release_metadata_snap\u0026quot;\n\nthin_check v1.2.2 result:\n\nBad reference count for metadata block 6. Expected 1, but space map contains 2.\nBad reference count for metadata block 7. Expected 1, but space map contains 2.\n1 metadata blocks have leaked.\n\nFix by deferring the held_root update to commit time.\n\nAdditionally, move the existing-snapshot check in __reserve_metadata_snap\nbefore the shadow operation to avoid unnecessary work. In\n__release_metadata_snap, clear pmd-\u0026gt;held_root before btree deletion so\npartial failure leaks blocks rather than leaving a stale reference, and\nunlock the snapshot block before decrementing its refcount.(CVE-2026-72108)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nntfs: detect mapping-pairs LCN accumulator overflow\n\nThe NTFS mapping-pairs parser accumulates relative LCN deltas in a\nsigned integer. A corrupted attribute can drive that addition past\nthe representable range.\n\nOne corrupt runlist shape sets the accumulated LCN to S64_MAX and\nthen adds a delta of 1 in the next mapping-pairs entry.\n\nSigned overflow is undefined and can turn an invalid runlist into a\ndifferent set of physical clusters.\n\nCheck the LCN addition for overflow before storing the next run.(CVE-2026-72200)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\njbd2: fix integer underflow in jbd2_journal_initialize_fast_commit()\n\njbd2_journal_initialize_fast_commit() validates journal capacity by\nchecking (journal-\u0026gt;j_last - num_fc_blks \u0026lt; JBD2_MIN_JOURNAL_BLOCKS).\nBoth j_last and num_fc_blks are unsigned, so when num_fc_blks exceeds\nj_last the subtraction wraps to a large value, bypassing the bounds\ncheck.\n\nThe resulting underflow corrupts j_last, j_fc_first, and j_free,\nleading to journal abort.\n\nFix by checking num_fc_blks against j_last before the subtraction,\nreturning -EFSCORRUPTED.(CVE-2026-72225)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nhwmon: (pmbus/core) honor vrm_version in pmbus_data2reg_vid()\n\npmbus_data2reg_vid() hardcoded the VR11 encoding regardless of the\nvrm_version configured by the driver, while pmbus_reg2data_vid()\nalready switched on it. Any driver that selects a non-VR11 VID mode\nand exposes a regulator (or hwmon vout setter) sent dangerously\nwrong codes to PMBUS_VOUT_COMMAND -- e.g. an nvidia195mv part asked\nfor 200 mV got the VR11 clamp to 500 mV encoded as 0xB2, which the\nchip interprets as 1080 mV.\n\nMirror pmbus_reg2data_vid() so writes round-trip with reads.(CVE-2026-72397)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nconfigfs: fix lockless traversals of -\u0026gt;s_children\n\nHaving the parent directory locked protects entries from removal\nby another thread, but it does *not* protect cursors from being\nmoved around by lseek() - or freed, for that matter.(CVE-2026-74330)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nconfigfs_lookup(): don\u0026apos;t leave -\u0026gt;s_dentry dangling on failure\n\nNormally -\u0026gt;s_dentry is cleared when dentry it\u0026apos;s pointing to becomes\nnegative (on eviction, realistically). However, that only happens\nif dentry gets to be positive in the first place; in case of inode\nallocation failure dentry never becomes positive, so -\u0026gt;d_iput()\nis not called at all.\n\nWe do part of what normally would\u0026apos;ve been done by configfs_d_iput()\n(dropping the reference to configfs_dirent) manually, but we do\nnot clear -\u0026gt;s_dentry there. Sloppy as it is, it does not matter in\ncase of configfs_create_{dir,link}() - there configfs_dirent does\nnot survive dropping the sole reference to it.\n\nHowever, for configfs_lookup() it *does* survive, with a dangling\npointer to soon to be freed dentry sitting it its -\u0026gt;s_dentry.\n\nSubsequent getdents(2) in that directory will end up dereferencing\nthat pointer in order to pick the inode number. Use after free...\n\nThis is the minimal fix; the right approach is to set the linkage\nbetween dentry and configfs_dirent only after we know that we have\nan inode, but that takes more surgery and the bug had been there\nsince 2006, so...(CVE-2026-74359)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmd/raid1,raid10: fix error-path detection with md_cloned_bio()\n\nDetect the error path using md_cloned_bio() instead of relying\non r1_bio in raid1 or r10_bio-\u0026gt;read_slot in raid10, which may be\nNULL or -1 after splitting and resubmitting a failed bio.\n\nAs a result, the error path may not be recognized and memory\nallocations can incorrectly use GFP_NOIO instead of\n(GFP_NOIO | __GFP_HIGH), which can lead to a deadlock under\nmemory pressure.(CVE-2026-74374)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: uvcvideo: Fix deadlock if uvc_status_stop is called from async_ctrl.work\n\nIf a UVC camera has an asynchronous control, uvc_status_stop may be\ncalled from async_ctrl.work:\n\nuvc_ctrl_status_event_work()\n uvc_ctrl_status_event()\n uvc_ctrl_clear_handle()\n\t uvc_pm_put()\n\t uvc_status_put()\n\t\t uvc_status_stop()\n\t\t cancel_work_sync()\n\nThis will cause a deadlock, since cancel_work_sync will wait for\nuvc_ctrl_status_event_work to complete before returning.\n\nFix this by returning early from uvc_status_stop if we are currently in\nthe work function. flush_status now remains false until uvc_status_start\nis called again, ensuring that uvc_ctrl_status_event_work won\u0026apos;t resubmit\nthe URB.(CVE-2026-74437)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/vmwgfx: bound DMA command body size against suffix pointer\n\nvmw_cmd_dma() locates the DMA suffix at\n\n\t(unsigned long) \u0026amp;cmd-\u0026gt;body + header-\u0026gt;size - sizeof(*suffix)\n\nwithout checking that header-\u0026gt;size is large enough to contain both\ncmd-\u0026gt;body and the suffix. An undersized header makes the suffix\npointer underflow back into the previous command in the bounce\nbuffer. The verifier later writes suffix-\u0026gt;maximumOffset, clobbering\nverified fields of an already-relocated earlier command -- a TOCTOU\non the device-visible command stream that lets one command rewrite\nanother\u0026apos;s GMR id, surface id, or other authenticated fields.\n\nReject the command if the body is too small for the suffix to fit.(CVE-2026-74443)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/vmwgfx: validate DRAW_PRIMITIVES header size before division\n\nvmw_cmd_draw() computes\n\n\tmaxnum = (header-\u0026gt;size - sizeof(cmd-\u0026gt;body)) / sizeof(*decl);\n\nwhere header-\u0026gt;size is u32 and is taken straight from the user-supplied\ncommand stream. When header-\u0026gt;size is less than sizeof(cmd-\u0026gt;body) the\nunsigned subtraction wraps to nearly 4 GiB, producing a huge maxnum.\nAny user-controlled cmd-\u0026gt;body.numVertexDecls then passes the bound and\nthe loop dereferences decl[i] far past the end of the kernel command\nbounce buffer, producing an out-of-bounds read of kernel memory.\n\nReject undersized headers up front.(CVE-2026-74444)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nhwmon: (nct6775-core) Prevent access to unsupported weight registers\n\nSashiko reports:\n\nDuring initialization of the nct6116 chip, the driver sets data-\u0026gt;pwm_num\nto 5. However, it assigns several NCT6106 register arrays (such as\nNCT6106_REG_WEIGHT_DUTY_STEP, NCT6106_REG_WEIGHT_TEMP_SEL, and\nNCT6106_REG_WEIGHT_TEMP_*) to data-\u0026gt;REG_PWM and data-\u0026gt;REG_WEIGHT_TEMP.\nThese arrays only contain 3 elements.\n\nIn nct6775_update_pwm(), the driver iterates up to data-\u0026gt;pwm_num. If\ndata-\u0026gt;has_pwm has bits 3 or 4 set (which is structurally possible for\nnct6116), the loop attempts to read elements at index 3 and 4 from these\n3-element arrays. This results in a global out-of-bounds read, which can\nbe caught by KASAN.\n\nFurthermore, the driver uses these garbage out-of-bounds values as\nhardware register addresses for subsequent read and write operations. This\nleads to invalid hardware register access, potentially causing hardware\nmisconfiguration or system crashes.\n\nThe underlying problem is that the chip does support up to five fan\ncontrol channels, but only the first three support weight control.\nFix the problem by extending the affected weight register arrays with\nzeroed fields. The driver uses zeroed register addresses to determine\nif a register is supported or not, and skips accesses for unsupported\nregisters.(CVE-2026-74549)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFS: Pin the \u0026apos;struct nfs_server\u0026apos; during a FREE_STATEID call\n\nDan Aloni reports that he was able to hit a use-after-free bug if a\nFREE_STATEID operation gets delayed for whatever reason. Fix this by\nbumping the refcount of the \u0026apos;struct nfs_server\u0026apos; object for the duration\nof the FREE_STATEID so it doesn\u0026apos;t get cleaned up from underneath us\nwhile operations are still in flight.(CVE-2026-74730)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsctp: validate cookie AUTH state before use\n\nWhen cookie authentication is disabled, COOKIE_ECHO restores fixed-size\nAUTH fields directly from peer-controlled cookie bytes. A forged RANDOM\nlength, HMAC list, or CHUNKS list can then reach association consumers\nwith lengths or identifiers that were never validated against the local\nbacking arrays.\n\nA forged RANDOM length can cause out-of-bounds reads during key-vector\nconstruction. A forged HMAC identifier also caused a 32-byte write past\na zero-length AUTH chunk, providing a primitive for a local privilege\nescalation chain.\n\nValidate the cookie\u0026apos;s RANDOM, HMACS, and CHUNKS parameters at the cookie\ntrust boundary before copying them into the association. Reject invalid\ntypes, malformed lengths, unsupported HMAC identifiers, HMAC lists\nwithout SHA1, and forbidden chunk ids.(CVE-2026-74752)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu: Fix UVD decode image min size calculation\n\nThis needs to use pitch instead of width. Also reject pitch\nover 4096 to avoid overflow.\n\n(cherry picked from commit b41c8cb12e202b220353332ab87dc01a11f69304)(CVE-2026-80540)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu: validate GEM_CREATE domain combinations\n\nAMDGPU_GEM_CREATE checked domain bits against AMDGPU_GEM_DOMAIN_MASK,\nbut did not validate domain combinations. Userspace could combine\nCPU|GTT|VRAM with DOORBELL, GDS, GWS, or OA, making\namdgpu_bo_placement_from_domain() exceed AMDGPU_BO_MAX_PLACEMENTS and\nhit BUG_ON().\n\nAllow combinations only within CPU/GTT/VRAM, and require non-CPU/GTT/\nVRAM domains to be specified one at a time. Return -EINVAL for invalid\ncombinations in amdgpu_gem_create_ioctl().\n\nv2: Rename helper from amdgpu_gem_domain_valid() to\n amdgpu_gem_are_domains_valid() (Christian)\n\n(cherry picked from commit db39852d0c39843cb02048dfb47e4b8c703e9080)(CVE-2026-80541)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nInput: synaptics-rmi4 - bound the F54 report size to the allocated buffer\n\nrmi_f54_work() reads a diagnostics report from the device into\nf54-\u0026gt;report_data, sizing the transfer with rmi_f54_get_report_size():\n\n\treport_size = rmi_f54_get_report_size(f54);\n\t...\n\tfor (i = 0; i \u0026lt; report_size; i += F54_REPORT_DATA_SIZE) {\n\t\tint size = min(F54_REPORT_DATA_SIZE, report_size - i);\n\t\t...\n\t\trmi_read_block(.., f54-\u0026gt;report_data + i, size);\n\t}\n\nreport_data is allocated once at probe from F54\u0026apos;s own electrode counts\n(array3_size(f54-\u0026gt;num_tx_electrodes, f54-\u0026gt;num_rx_electrodes, sizeof(u16))),\nbut rmi_f54_get_report_size() computes the size from\ndrv_data-\u0026gt;num_*_electrodes when those are set, i.e. from the F55\nfunction\u0026apos;s electrode counts. Both counts come straight from device\nqueries (F54 and F55 each report up to 255 electrodes) and nothing\nconstrains the F55 counts to the F54 ones.\n\nA malicious or malfunctioning RMI4 device that reports larger F55\nelectrode counts than its F54 counts makes report_size exceed the\nallocation, so the read loop writes past report_data (and the V4L2\ndequeue memcpy() then reads past it). On conforming hardware the F55\nconfigured electrodes are a subset of the F54 physical electrodes, so\nreport_size never exceeds the buffer and well-behaved devices are\nunaffected.\n\nRecord the allocation size and reject a report that does not fit,\nmirroring the existing zero-size check.(CVE-2026-80569)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nInput: synaptics-rmi4 - zero report size on F54 work error\n\nIn rmi_f54_work(), if an error occurs during report request or command\nverification, the code jumped directly to the \u0026apos;error\u0026apos; label, bypassing\nthe \u0026apos;abort\u0026apos; label where f54-\u0026gt;report_size was normally zeroed out.\n\nThis left f54-\u0026gt;report_size containing its previous successful payload\nsize. If a user then altered the V4L2 format to a smaller size, and a\nsubsequent run failed, rmi_f54_buffer_queue() would copy the stale,\nlarger payload size into the shrunken V4L2 buffer, causing a heap\nbuffer overflow.\n\nFix this by merging the \u0026apos;abort\u0026apos; and \u0026apos;error\u0026apos; labels into a single \u0026apos;out\u0026apos;\nexit path, and ensuring that f54-\u0026gt;report_size is always set to 0 on\nfailure by checking for error and zeroing the local report_size first.(CVE-2026-80570)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: ethernet: mtk_eth_soc: pass eth to mtk_handle_irq_rx in poll_controller\n\nmtk_handle_irq_rx expects a struct mtk_eth * (matching the request_irq\ncookie), but mtk_poll_controller incorrectly passed the net_device *.\nCalling ndo_poll_controller with CONFIG_NET_POLL_CONTROLLER enabled\nwould then crash.(CVE-2026-80694)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncan: j1939: transport: j1939_session_fresh_new(): initialize receive buffer\n\nZero the allocated buffer in j1939_session_fresh_new() to ensure it\ncontains no residual data.\n\nWhile there is a potential performance impact if users allocate maximum\nsized ETP buffers, most real-world use cases are not noticeably affected\nsince the maximum known buffer size is typically around 65K.\n\n[mkl: add Message-ID](CVE-2026-80707)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsctp: validate Adaptation Indication parameter length\n\nThe Adaptation Layer Indication parameter contains a fixed 32-bit\nAdaptation Code Point after its parameter header. However,\nsctp_verify_param() accepts a header-only parameter because the generic\nparameter walker only requires the header to be present.\n\nsctp_process_param() then reads adaptation_ind beyond the declared\nparameter. When the malformed parameter is last in an INIT, the read\nstarts at the receive skb tail, and the value is copied into the state\ncookie returned in the INIT ACK. This may disclose four receive-buffer\ntail bytes.\n\nRequire the declared parameter length to match the fixed structure size\nand abort the association through the existing invalid parameter length\npath otherwise.(CVE-2026-80717)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: x86/mmu: WARN and clear role.invalid when creating a child shadow page\n\nExplicitly clear role.invalid when deriving a child shadow page\u0026apos;s role from\nits parent to harden against bugs elsewhere in KVM, as violating KVM\u0026apos;s\ninvariant that invalid pages are NOT on the list of active MMU pages leads\nto use-after-free due to __kvm_mmu_prepare_zap_page() using list_add()\ninstead of list_move() when processing an invalid shadow page, i.e. makes a\nbad situation far worse.\n\nYell loudly if the parent is invalid, as it means KVM has missed a validity\ncheck, i.e. KVM is attempting to map memory using an invalid/obsolete root,\nbut continue on as the child is otherwise still a valid shadow page.\n\n ==================================================================\n BUG: KASAN: slab-use-after-free in __kvm_mmu_get_shadow_page+0x1817/0x1860 [kvm]\n Write of size 8 at addr ff11000153dd1368 by task repro/853\n\n CPU: 1 UID: 1000 PID: 853 Comm: repro Not tainted 7.2.0-rc2-3aec122bdcaf-next-vm #5 PREEMPT\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015\n Call Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x4b/0x70\n print_report+0x153/0x49c\n kasan_report+0xbc/0xf0\n __kvm_mmu_get_shadow_page+0x1817/0x1860 [kvm]\n mmu_alloc_root+0x141/0x320 [kvm]\n kvm_mmu_load+0x612/0x20f0 [kvm]\n kvm_arch_vcpu_ioctl_run+0x3dd5/0x6150 [kvm]\n kvm_vcpu_ioctl+0x5e4/0x10d0 [kvm]\n __x64_sys_ioctl+0x131/0x1b0\n do_syscall_64+0x67/0x5f0\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n \u0026lt;/TASK\u0026gt;\n\n Allocated by task 853:\n kasan_save_stack+0x20/0x40\n kasan_save_track+0x14/0x30\n __kasan_slab_alloc+0x5f/0x70\n kmem_cache_alloc_noprof+0xfe/0x2e0\n __kvm_mmu_topup_memory_cache+0x135/0x530 [kvm]\n paging64_page_fault+0x318/0x1e30 [kvm]\n kvm_mmu_do_page_fault+0x21d/0x630 [kvm]\n kvm_mmu_page_fault+0x18c/0x17b0 [kvm]\n kvm_arch_vcpu_ioctl_run+0x1f35/0x6150 [kvm]\n kvm_vcpu_ioctl+0x5e4/0x10d0 [kvm]\n __x64_sys_ioctl+0x131/0x1b0\n do_syscall_64+0x67/0x5f0\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\n Freed by task 853:\n kasan_save_stack+0x20/0x40\n kasan_save_track+0x14/0x30\n kasan_save_free_info+0x3b/0x60\n __kasan_slab_free+0x43/0x70\n kmem_cache_free+0xe2/0x400\n kvm_mmu_commit_zap_page.part.0+0x1e2/0x310 [kvm]\n kvm_mmu_free_roots+0x283/0x560 [kvm]\n kvm_arch_vcpu_ioctl_run+0x33c8/0x6150 [kvm]\n kvm_vcpu_ioctl+0x5e4/0x10d0 [kvm]\n __x64_sys_ioctl+0x131/0x1b0\n do_syscall_64+0x67/0x5f0\n entry_SYSCALL_64_after_hwframe+0x4b/0x53(CVE-2026-80726)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nserial: amba-pl011: synchronize DMA teardown\n\ndmaengine_terminate_all() does not wait for a running callback, so the TX\ncallback can still touch the TX buffer after it is freed. The RX poll\ntimer reads the RX buffers without the port lock.\n\nSwitch to dmaengine_terminate_sync() and delete the RX timer before\nfreeing the buffers.(CVE-2026-80737)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmd: do overflow check for sb-\u0026gt;bblog_shift in super_1_load()\n\nIn super_1_load(), sb-\u0026gt;bblog_shift is an __u8 type value loaded from on-\ndisk superblock. It is used for badblocks API badblocks_set() by the\nfollowing sequence,\n\n 1930 rdev-\u0026gt;badblocks.shift = sb-\u0026gt;bblog_shift;\n 1931 for (i = 0 ; i \u0026lt; (sectors \u0026lt;\u0026lt; (9-3)) ; i++, bbp++) {\n 1932 u64 bb = le64_to_cpu(*bbp);\n 1933 int count = bb \u0026amp; (0x3ff);\n 1934 u64 sector = bb \u0026gt;\u0026gt; 10;\n 1935 sector \u0026lt;\u0026lt;= sb-\u0026gt;bblog_shift;\n 1936 count \u0026lt;\u0026lt;= sb-\u0026gt;bblog_shift;\n 1937 if (bb + 1 == 0)\n 1938 break;\n 1939 if (!badblocks_set(\u0026amp;rdev-\u0026gt;badblocks, sector, count, 1))\n 1940 return -EINVAL;\n 1941 }\n\nbb-\u0026gt;bblog_shit is in range of 0-255, variable sector is 64bit width, for\nan invalid bb-\u0026gt;bblog_shit, it is possible to make sector be overflowed\nby the following calculation,\n 1935 sector \u0026lt;\u0026lt;= sb-\u0026gt;bblog_shift;\nThen in turn when call badblocks_set() at line 1939 with the invalid\nrdev-\u0026gt;badblocks.shift set at line 1930, may result an overflow inside\n_badblocks_clear() in block/badblocks.c.\n\nAlthough there are many places to call badblocks APIs, the non-zero\nshift value is only used in super_1_load(), other places always use 0 as\nthe shift value. Therefore it is unnecessary to do a general shift value\noverflow check inside badblock API, and just check here as the caller.\n\nThis may avoid unnecessary check, make the badblocks API code more simple\nand elegant.(CVE-2026-89557)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nata: libata-scsi: fix DSM TRIM for sector sizes larger than 2048 bytes\n\nata_scsi_write_same_xlat() translates a SCSI WRITE SAME command with the\nUNMAP bit set into an ATA DATA SET MANAGEMENT TRIM command. The TRIM\ndescriptor is built by ata_format_dsm_trim_descr() into the 2048-byte\nata_scsi_rbuf staging buffer, and the number of bytes copied is compared\nagainst the logical sector size by the caller:\n\n\tsize = ata_format_dsm_trim_descr(scmd, trmax, block, n_block);\n\tif (size != len)\t\t/* len == sdp-\u0026gt;sector_size */\n\t\tgoto invalid_param_len;\n\nata_format_dsm_trim_descr() clamps the copy length to ATA_SCSI_RBUF_SIZE\n(2048). On a device whose logical sector size exceeds that (e.g. a 4Kn\ndevice, where sector_size == 4096) the function can never return more than\n2048, while the caller expects it to return sector_size. The comparison\ntherefore always fails, so every TRIM is rejected with \u0026quot;Parameter list\nlength error\u0026quot; and WARN_ON() splats on each attempt. TRIM / discard is\nthus completely broken on such devices.\n\nThe descriptor was incorrectly sized from the logical sector size. A DSM\nTRIM payload is a list of 512-byte pages, each holding up to\nATA_MAX_TRIM_RNUM (64) LBA Range Entries, and is independent of the logical\nsector size. The Block Limits VPD page already advertises a single such\npage as the maximum WRITE SAME length (65535 * ATA_MAX_TRIM_RNUM logical\nblocks), so the block layer never sends a request that needs more than one\npage.\n\nEmit exactly one 512-byte page, independent of the logical sector size,\nand transfer only that page (COUNT == 1). For a 512-byte-sector device\nthis is unchanged; devices with larger logical sectors now work instead of\nfailing every TRIM.(CVE-2026-89586)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\necryptfs: pass packet set buffer size to parser\n\necryptfs_parse_packet_set() receives a pointer into the file header, but\nit calculates the remaining packet buffer size from PAGE_SIZE - 8. For\nversion 1 headers the packet set starts later in the header, so this can\noverstate the available buffer.\n\nPass the actual packet set buffer length from the caller and calculate\nper-packet limits from the remaining bytes in that buffer. Recompute the\nremaining length after consuming a tag 3 packet before parsing the\nfollowing tag 11 packet.(CVE-2026-89608)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: reject a tree connect response whose byte count is too small\n\nCIFSTCon() bounds its strnlen() over the byte area with the server\u0026apos;s\nByteCount minus two, which for ByteCount 0 or 1 goes negative as an int\nand converts to a huge size_t. The later subtraction wraps the __u16\nbytes_left, and that is what bounds cifs_strndup_from_utf16(): a bound of\nup to 65535 against a ~16 KB cifs_req_poolp object runs off the end of the\nslab object, and the bytes reach userspace through tcon-\u0026gt;nativeFileSystem\nin /proc/fs/cifs/DebugData.\n\nReject a byte area too small for what the parser consumes. Two bytes is\nthe least it can consume, and no conformant response carries fewer. The\nnew trace point is the 129th smb_eio_trace entry, which __mode(byte)\ncannot represent, so the attribute goes with it.(CVE-2026-89631)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix OOB read/write from unvalidated DataOffset in coalesce_t2()\n\ncoalesce_t2() computes data pointers directly from server-supplied\nDataOffset fields with no validation against buffer bounds:\n\n data_area_of_tgt = (char *)\u0026amp;pSMBt-\u0026gt;hdr.Protocol +\n get_unaligned_le16(\u0026amp;pSMBt-\u0026gt;t2_rsp.DataOffset);\n data_area_of_src = (char *)\u0026amp;pSMBs-\u0026gt;hdr.Protocol +\n get_unaligned_le16(\u0026amp;pSMBs-\u0026gt;t2_rsp.DataOffset);\n data_area_of_tgt += total_in_tgt;\n ...\n memcpy(data_area_of_tgt, data_area_of_src, total_in_src);\n\nA small DataOffset can push a pointer below the actual byte area,\noverwriting header fields; a large one can push it past the buffer\nend, causing out-of-bounds heap reads (source) or writes (target).\nThe BCC overflow guard does not prevent this: BCC reflects how much\ndata is present, while DataOffset controls where in the buffer it\nstarts.\n\nThe \u0026quot;validate target area\u0026quot; comment present since the function was\nfirst written in 2005 was a placeholder that was never implemented.\n\nAdd lower- and upper-bound checks for both data pointers before the\nmemcpy, and before any target header fields are modified.(CVE-2026-89633)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix UAF and buffer leak in cifs_check_trans2() for malformed secondary T2\n\nWhen a valid primary TRANSACT2 response has been received (mid-\u0026gt;resp_buf\nset, mid-\u0026gt;multiRsp true) and a subsequent secondary response causes\ncifs_check_trans2() to return false -- either because the SMB header is\ninvalid (malformed != 0) or because check2ndT2() rejects the PDU --\nhandle_mid() overwrites mid-\u0026gt;resp_buf with the new buffer (leaking the\nprimary buffer) and, because mid-\u0026gt;multiRsp is set, skips the\nserver-\u0026gt;smallbuf/bigbuf NULL-out. When the user thread frees\nmid-\u0026gt;resp_buf, server-\u0026gt;smallbuf or server-\u0026gt;bigbuf is left dangling; the\ndemux thread reuses it for the next packet, resulting in a use-after-free.\n\nCombine both early-exit conditions and, when mid-\u0026gt;multiRsp is already\nset, abort the pending transaction inline: set multiEnd, call\ndequeue_mid() with malformed=true, and return true so handle_mid() exits\nwithout touching mid-\u0026gt;resp_buf or the server buffer pointers.(CVE-2026-89637)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nceph: bound xattr value length in __build_xattrs()\n\n__build_xattrs() decodes the MDS-supplied xattr blob one attribute at a\ntime. For each attribute it reads a 32-bit name length, advances past the\nname bytes, reads a 32-bit value length, records the value pointer, and\nadvances past the value bytes. The two length fields are read with\nceph_decode_32_safe(), but the value bytes themselves are advanced over\nwith a bare \u0026quot;p += len\u0026quot; and no ceph_decode_need() check that \u0026quot;len\u0026quot; bytes\nremain in the blob.\n\nFor every attribute except the last, the next iteration\u0026apos;s\nceph_decode_32_safe() on the following name length implicitly verifies\nthat the previous value did not run past the blob end. The final\nattribute has no successor, so its decoded value length is never checked\nagainst the blob bounds. A malicious or compromised metadata server can\nset the last attribute\u0026apos;s value length larger than the bytes actually\npresent in the blob.\n\nThe blob is a dedicated kvmalloc() allocation sized to the wire length\n(ceph_buffer_new() in ceph_fill_inode()). __set_xattr() records the\noversized length in xattr-\u0026gt;val_len verbatim, and a later getxattr(2) runs\nmemcpy(value, xattr-\u0026gt;val, xattr-\u0026gt;val_len) into a user-supplied buffer,\ncopying bytes past the end of the allocation back to user space.\n\nImpact: a malicious metadata server discloses adjacent kernel heap bytes\nto a local user via getxattr(2) on a CephFS file. Add the missing\nceph_decode_need() so an out-of-bounds value length on the final\nattribute fails the decode and returns -EIO instead of being stored.(CVE-2026-89649)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nceph: bound num_export_targets array for mds info v2/v3\n\nceph_mdsmap_decode() in fs/ceph/mdsmap.c reads num_export_targets from\neach per-mds info record and advances the decode cursor by\nnum_export_targets * sizeof(u32) without first checking that many bytes\nremain. The only upper-bound check that catches a runaway cursor\n(*p \u0026gt; info_end) is gated on info_v \u0026gt;= 4, because info_end is left NULL\nfor info_v 2 and 3. When the monitor sends an MDS map whose per-mds\ninfo version is 2 or 3 with an oversized num_export_targets, the cursor\nmoves past the message front buffer and the later export-targets loop\ncalls the unchecked ceph_decode_32() on out-of-bounds memory.\n\nA kernel client processes CEPH_MSG_MDS_MAP from its monitor session\n(net/ceph/mon_client.c dispatches it; fs/ceph/super.c routes it to\nceph_mdsc_handle_mdsmap(), which sets end to the front buffer bound and\ncalls ceph_mdsmap_decode()). A malicious or compromised monitor, or an\non-path attacker on an unsigned/unencrypted messenger session, can\ntherefore drive an out-of-bounds read in the client kernel; on x86_64\nwith KASAN it is reported as a slab-out-of-bounds read in\nceph_mdsmap_decode(). The decoded values land in the internal\ninfo-\u0026gt;export_targets[] array, so the consequence is a kernel\nout-of-bounds read, not an information leak to the attacker.\n\nImpact: a malicious or compromised Ceph monitor sending an MDS map with\na per-mds info version of 2 or 3 and an oversized num_export_targets\nfield triggers an out-of-bounds read in the CephFS client kernel.\n\nAdd a ceph_decode_need() for the export-targets array before advancing\nthe cursor, so the bound is enforced for every info_v \u0026gt;= 2, not only\ninfo_v \u0026gt;= 4. This mirrors the count-then-need idiom already used for\nm_data_pg_pools later in the same function.\n\nCompute the export-targets byte count with size_mul() and reuse that\nchecked length when advancing the cursor, so the attacker-controlled\nnum_export_targets multiplication fails closed on overflow rather than\nrelying on the later kcalloc() guard.(CVE-2026-89650)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nceph: bound copied dentry name length in NFS export get_name\n\nceph_get_name() copies the MDS-supplied name into the caller\u0026apos;s\nNAME_MAX-sized buffer with memcpy(name, rinfo-\u0026gt;dname, rinfo-\u0026gt;dname_len)\nand then writes name[rinfo-\u0026gt;dname_len] = 0, without checking dname_len\nagainst NAME_MAX. A malicious or buggy MDS that returns a LOOKUPNAME reply\nwith dname_len \u0026gt; NAME_MAX overflows the buffer. __get_snap_name() copies\nrde-\u0026gt;name / rde-\u0026gt;name_len the same unchecked way.\n\nImpact: a malicious or compromised Ceph MDS overflows the NAME_MAX name\nbuffer in a client\u0026apos;s NFS-export get_name path, a slab out-of-bounds write\nreported by KASAN. Reachable when a CephFS mount is re-exported over NFS.\n\nAdd ceph_export_copy_name(), which rejects lengths above NAME_MAX with\n-ENAMETOOLONG before the copy, and use it in both ceph_get_name() and\n__get_snap_name().(CVE-2026-89652)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nceph: fix UAF in __kick_flushing_caps() on cf entry freed during unlock\n\nlist_for_each_entry() iterates ci-\u0026gt;i_cap_flush_list but drops\ni_ceph_lock to send cap messages. During the unlock window,\nhandle_cap_flush_ack() can acquire i_ceph_lock, detach cf entries\nwith tid \u0026lt;= flush_tid from the list, release i_ceph_lock, and free\nthem via ceph_free_cap_flush() outside any lock. When the original\nthread reacquires i_ceph_lock and the for-loop macro advances via\ncf = list_next_entry(cf, i_list), it dereferences cf-\u0026gt;i_list.next\non freed memory.\n\nThe race timeline:\n\n __kick_flushing_caps() handle_cap_flush_ack()\n ----------------------- -----------------------\n holds i_ceph_lock \u0026lt;---\n iterates to cf (tid=10)\n prepares FLUSH message\n drops i_ceph_lock \u0026lt;---\n __send_cap() \u2500\u2500 FLUSH(tid=10)\n\t MDS sends FLUSH_ACK(tid=10)\n ---\u0026gt; acquires i_ceph_lock\n cf-\u0026gt;tid(10) \u0026lt;= flush_tid(10),\n detaches cf from i_cap_flush_list\n drops i_ceph_lock\n ceph_free_cap_flush(cf) \u0026lt;- frees it!\n acquires i_ceph_lock \u0026lt;---\n for-loop advances:\n cf = list_next_entry(cf, i_list)\n -- UAF on freed cf-\u0026gt;i_list.next\n\nThe cf was just sent by __kick_flushing_caps itself via __send_cap().\nThe MDS may respond with FLUSH_ACK quickly enough that\nhandle_cap_flush_ack() frees cf before __kick_flushing_caps can\nfinish the iteration.\n\nFix by converting to a manual while loop: save the next pointer\nunder i_ceph_lock before dropping it, then use the saved pointer\nafter reacquiring, so the potentially-freed cf is never accessed again.(CVE-2026-89655)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qla2xxx: Bound rsp_info_len to avoid OOB sense-data read\n\nIn qla2x00_status_entry(), the FWI2 status path advances sense_data and\nshrinks par_sense_len by rsp_info_len:\n\n\tif (IS_FWI2_CAPABLE(ha)) {\n\t\tsense_data += rsp_info_len;\n\t\tpar_sense_len -= rsp_info_len;\n\t}\n\nrsp_info_len is a 32-bit value taken directly from the target\u0026apos;s FCP\nresponse (sf.rsp_data_len), while par_sense_len is the IOCB data area\nsize (28 bytes for 24xx, 60 bytes for 29xx). A hostile or buggy target\nreporting an rsp_info_len larger than par_sense_len makes the unsigned\nsubtraction underflow to a huge value and advances sense_data out of\nbounds.\n\nThe underflowed par_sense_len then defeats the cap in\nqla2x00_handle_sense():\n\n\tif (sense_len \u0026gt; par_sense_len)\n\t\tsense_len = par_sense_len;\n\tmemcpy(cp-\u0026gt;sense_buffer, sense_data, sense_len);\n\nso the memcpy reads up to SCSI_SENSE_BUFFERSIZE bytes from the\nout-of-bounds sense_data pointer, leaking adjacent response-ring/heap\nmemory into the command\u0026apos;s sense buffer.\n\nClamp rsp_info_len to par_sense_len before the subtraction so\npar_sense_len can never underflow and sense_data stays within the IOCB\ndata area. The fix sits before the comp_status switch, covering both\nqla2x00_handle_sense() call sites.(CVE-2026-89846)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qla2xxx: Avoid double completion in async IOCB timeout\n\nqla2x00_async_iocb_timeout() tries to abort a timed-out async IOCB. When\nqla24xx_async_abort_cmd() fails, both the SRB_LOGIN_CMD path and the\nSRB_CTRL_VP/default path scan outstanding_cmds[] for the SRB and then\ncall sp-\u0026gt;done(sp, QLA_FUNCTION_TIMEOUT) unconditionally, without checking\nwhether the SRB was actually found and removed.\n\nIf the response ISR completes the same handle first, it removes the SRB\nunder qp_lock_ptr and runs sp-\u0026gt;done() -\u0026gt; complete(sp-\u0026gt;comp). The\nsubmitter qla24xx_control_vp() wakes from wait_for_completion(), clears\nsp-\u0026gt;comp, drops its reference and returns, reclaiming the on-stack\ncompletion. The timer reference keeps the SRB alive across the timeout\nhandler, but not the submitter\u0026apos;s stack. The timeout then issues a second\nsp-\u0026gt;done() -\u0026gt; qla_ctrlvp_sp_done(), which evaluates \u0026quot;if (sp-\u0026gt;comp)\ncomplete(sp-\u0026gt;comp)\u0026quot;; with the pointer loaded before the submitter\u0026apos;s NULL\nstore, complete() writes into the freed stack frame, a use-after-free.\n\nTrack whether this path removed the SRB from outstanding_cmds and only\ncall sp-\u0026gt;done() when it did, so the command is completed exactly once by\nwhichever path owns it. This mirrors the sp_found guard already used in\nqla24xx_abort_iocb_timeout().(CVE-2026-89847)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qla2xxx: Zero dport diagnostics buffer to avoid info leak\n\nqla2x00_do_dport_diagnostics() allocates the qla_dport_diag response\nbuffer with kmalloc_obj() (non-zeroing) and, on success, copies the full\nsizeof(*dd) back to user space via sg_copy_from_buffer(). The inbound\nsg_copy_to_buffer() only fills as many bytes as the user request payload\nprovides, and qla26xx_dport_diagnostics() zeroes only dd-\u0026gt;buf. The\noptions and unused[] fields are therefore copied out uninitialized,\nleaking kernel heap contents to user space.\n\nAllocate with kzalloc_obj(), matching qla2x00_do_dport_diagnostics_v2().(CVE-2026-89859)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Take trace_array reference when opening options file\n\nThe options files do not take the trace_array reference for the options\nthey represent. This could cause a use-after-free kernel crash if one of\nthese files is opened by one task and another task removes the instance\nthat the option is for. Because it doesn\u0026apos;t take a reference upon opening,\nit will not stop the removal which will free the options descriptor that\nis being used.\n\nAs the options are somewhat dynamic in their creation at boot up, each\nfile represents a flag in the trace_array. The trace_array has an array of\nindexes to represent each of these flags that is stored in the\ntrace_flags_index array. The address of the index array element is used to\npass to the inode-\u0026gt;i_private pointer. Then that element is read which\nholds the index (which represents the flag) and then the index is used to\ncalculate the trace_array descriptor from its trace_flags_index array.\n\nOne issue is that the index element can not be referenced until the\ntrace_array\u0026apos;s reference is taken. To handle this, create a new helper\nfunction called: trace_array_options_get() that will iterate all the\nexisting trace_arrays in the ftrace_trace_arrays list (under the\ntrace_types_lock), and compare the passed in address of the index element\nwith the entire array of the trace_array\u0026apos;s trace_flags_index array.\nIf it matches, then up the corresponding trace_array\u0026apos;s reference and\nreturn.(CVE-2026-90013)",
"id": "OESA-2026-4039",
"modified": "2026-09-25T01:27:35Z",
"published": "2026-09-25T01:27:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-4039"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56531"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56614"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40269"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31548"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43303"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46004"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-52929"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-52954"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-52969"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-52982"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53242"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63870"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63916"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64048"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64449"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64458"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64582"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-68108"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-68320"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-68404"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-68470"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72102"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72106"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72108"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72200"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72225"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72397"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74330"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74359"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74374"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74437"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74443"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74444"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74549"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74730"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74752"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-80540"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-80541"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-80569"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-80570"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-80694"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-80707"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-80717"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-80726"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-80737"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89557"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89586"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89608"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89631"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89633"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89637"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89649"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89650"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89652"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89655"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89846"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89847"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89859"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-90013"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2024-56531",
"CVE-2024-56614",
"CVE-2025-40269",
"CVE-2026-31548",
"CVE-2026-43303",
"CVE-2026-46004",
"CVE-2026-52929",
"CVE-2026-52954",
"CVE-2026-52969",
"CVE-2026-52982",
"CVE-2026-53242",
"CVE-2026-63870",
"CVE-2026-63916",
"CVE-2026-64048",
"CVE-2026-64449",
"CVE-2026-64458",
"CVE-2026-64582",
"CVE-2026-68108",
"CVE-2026-68320",
"CVE-2026-68404",
"CVE-2026-68470",
"CVE-2026-72102",
"CVE-2026-72106",
"CVE-2026-72108",
"CVE-2026-72200",
"CVE-2026-72225",
"CVE-2026-72397",
"CVE-2026-74330",
"CVE-2026-74359",
"CVE-2026-74374",
"CVE-2026-74437",
"CVE-2026-74443",
"CVE-2026-74444",
"CVE-2026-74549",
"CVE-2026-74730",
"CVE-2026-74752",
"CVE-2026-80540",
"CVE-2026-80541",
"CVE-2026-80569",
"CVE-2026-80570",
"CVE-2026-80694",
"CVE-2026-80707",
"CVE-2026-80717",
"CVE-2026-80726",
"CVE-2026-80737",
"CVE-2026-89557",
"CVE-2026-89586",
"CVE-2026-89608",
"CVE-2026-89631",
"CVE-2026-89633",
"CVE-2026-89637",
"CVE-2026-89649",
"CVE-2026-89650",
"CVE-2026-89652",
"CVE-2026-89655",
"CVE-2026-89846",
"CVE-2026-89847",
"CVE-2026-89859",
"CVE-2026-90013"
]
}
SSA-355557
Vulnerability from csaf_siemens - Published: 2025-08-12 00:00 - Updated: 2026-02-24 00:00SUSE-SU-2025:0236-1
Vulnerability from csaf_suse - Published: 2025-01-24 17:02 - Updated: 2026-09-20 17:32SUSE-SU-2025:0289-1
Vulnerability from csaf_suse - Published: 2025-01-29 16:11 - Updated: 2026-09-20 17:40SUSE-SU-2025:0428-1
Vulnerability from csaf_suse - Published: 2025-02-11 10:40 - Updated: 2026-09-20 17:54SUSE-SU-2025:0499-1
Vulnerability from csaf_suse - Published: 2025-02-13 08:14 - Updated: 2026-09-20 17:54SUSE-SU-2025:0556-1
Vulnerability from csaf_suse - Published: 2025-02-14 15:26 - Updated: 2026-09-20 17:55SUSE-SU-2025:0557-1
Vulnerability from csaf_suse - Published: 2025-02-14 15:26 - Updated: 2026-09-20 17:55SUSE-SU-2025:0577-1
Vulnerability from csaf_suse - Published: 2025-03-11 15:28 - Updated: 2026-09-20 17:55Sightings
| 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.