Action not permitted
Modal body text goes here.
Modal Title
Modal Body
CVE-2026-46028 (GCVE-0-2026-46028)
Vulnerability from cvelistv5 – Published: 2026-05-27 12:56 – Updated: 2026-06-14 17:49| Vendor | Product | Version | CPE status | |
|---|---|---|---|---|
| Linux | Linux |
Affected:
d887c52d6ae43aeebd249b5f2f1333e60236aa60 , < 08ea39a556ecd39b33c2b4888861001c6706a62e
(git)
Affected: d887c52d6ae43aeebd249b5f2f1333e60236aa60 , < a920cabdb0b7cf1f4e11a20524253ae5bd09092b (git) Affected: d887c52d6ae43aeebd249b5f2f1333e60236aa60 , < fa0fcec9b49d58e71df7ede91ecd86855f608e85 (git) Affected: d887c52d6ae43aeebd249b5f2f1333e60236aa60 , < c2138c9bd02af19e0b407376140cd5435b0d81da (git) Affected: d887c52d6ae43aeebd249b5f2f1333e60236aa60 , < 46fdb39e83227b5d39f7c934a0947ea913f13c18 (git) Affected: d887c52d6ae43aeebd249b5f2f1333e60236aa60 , < ebc235675f24b0e3f8bc92b8419471d42f837d8f (git) Affected: d887c52d6ae43aeebd249b5f2f1333e60236aa60 , < 3d72f8c6490dc79210b64270740cb2a8619361a4 (git) Affected: d887c52d6ae43aeebd249b5f2f1333e60236aa60 , < 5aa58c3a572b3e3b6c786953339f7978b845cc52 (git) |
guessed | |
| Linux | Linux |
Affected:
4.14
Unaffected: 0 , < 4.14 (semver) Unaffected: 5.10.254 , ≤ 5.10.* (semver) Unaffected: 5.15.204 , ≤ 5.15.* (semver) Unaffected: 6.1.170 , ≤ 6.1.* (semver) Unaffected: 6.6.137 , ≤ 6.6.* (semver) Unaffected: 6.12.85 , ≤ 6.12.* (semver) Unaffected: 6.18.27 , ≤ 6.18.* (semver) Unaffected: 7.0.4 , ≤ 7.0.* (semver) Unaffected: 7.1 , ≤ * (original_commit_for_fix) |
guessed |
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"crypto/algif_aead.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "08ea39a556ecd39b33c2b4888861001c6706a62e",
"status": "affected",
"version": "d887c52d6ae43aeebd249b5f2f1333e60236aa60",
"versionType": "git"
},
{
"lessThan": "a920cabdb0b7cf1f4e11a20524253ae5bd09092b",
"status": "affected",
"version": "d887c52d6ae43aeebd249b5f2f1333e60236aa60",
"versionType": "git"
},
{
"lessThan": "fa0fcec9b49d58e71df7ede91ecd86855f608e85",
"status": "affected",
"version": "d887c52d6ae43aeebd249b5f2f1333e60236aa60",
"versionType": "git"
},
{
"lessThan": "c2138c9bd02af19e0b407376140cd5435b0d81da",
"status": "affected",
"version": "d887c52d6ae43aeebd249b5f2f1333e60236aa60",
"versionType": "git"
},
{
"lessThan": "46fdb39e83227b5d39f7c934a0947ea913f13c18",
"status": "affected",
"version": "d887c52d6ae43aeebd249b5f2f1333e60236aa60",
"versionType": "git"
},
{
"lessThan": "ebc235675f24b0e3f8bc92b8419471d42f837d8f",
"status": "affected",
"version": "d887c52d6ae43aeebd249b5f2f1333e60236aa60",
"versionType": "git"
},
{
"lessThan": "3d72f8c6490dc79210b64270740cb2a8619361a4",
"status": "affected",
"version": "d887c52d6ae43aeebd249b5f2f1333e60236aa60",
"versionType": "git"
},
{
"lessThan": "5aa58c3a572b3e3b6c786953339f7978b845cc52",
"status": "affected",
"version": "d887c52d6ae43aeebd249b5f2f1333e60236aa60",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"crypto/algif_aead.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "4.14"
},
{
"lessThan": "4.14",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.254",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.204",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.170",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.137",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.85",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.18.*",
"status": "unaffected",
"version": "6.18.27",
"versionType": "semver"
},
{
"lessThanOrEqual": "7.0.*",
"status": "unaffected",
"version": "7.0.4",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "7.1",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.10.254",
"versionStartIncluding": "4.14",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.15.204",
"versionStartIncluding": "4.14",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.1.170",
"versionStartIncluding": "4.14",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6.137",
"versionStartIncluding": "4.14",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.12.85",
"versionStartIncluding": "4.14",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.18.27",
"versionStartIncluding": "4.14",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "7.0.4",
"versionStartIncluding": "4.14",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "7.1",
"versionStartIncluding": "4.14",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: algif_aead - snapshot IV for async AEAD requests\n\nAF_ALG AEAD AIO requests currently use the socket-wide IV buffer during\nrequest processing. For async requests, later socket activity can\nupdate that shared state before the original request has fully\ncompleted, which can lead to inconsistent IV handling.\n\nSnapshot the IV into per-request storage when preparing the AEAD\nrequest, so in-flight operations no longer depend on mutable socket\nstate."
}
],
"providerMetadata": {
"dateUpdated": "2026-06-14T17:49:01.589Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/08ea39a556ecd39b33c2b4888861001c6706a62e"
},
{
"url": "https://git.kernel.org/stable/c/a920cabdb0b7cf1f4e11a20524253ae5bd09092b"
},
{
"url": "https://git.kernel.org/stable/c/fa0fcec9b49d58e71df7ede91ecd86855f608e85"
},
{
"url": "https://git.kernel.org/stable/c/c2138c9bd02af19e0b407376140cd5435b0d81da"
},
{
"url": "https://git.kernel.org/stable/c/46fdb39e83227b5d39f7c934a0947ea913f13c18"
},
{
"url": "https://git.kernel.org/stable/c/ebc235675f24b0e3f8bc92b8419471d42f837d8f"
},
{
"url": "https://git.kernel.org/stable/c/3d72f8c6490dc79210b64270740cb2a8619361a4"
},
{
"url": "https://git.kernel.org/stable/c/5aa58c3a572b3e3b6c786953339f7978b845cc52"
}
],
"title": "crypto: algif_aead - snapshot IV for async AEAD requests",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2026-46028",
"datePublished": "2026-05-27T12:56:36.847Z",
"dateReserved": "2026-05-13T15:03:33.093Z",
"dateUpdated": "2026-06-14T17:49:01.589Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"epss": {
"cve": "CVE-2026-46028",
"date": "2026-09-19",
"epss": "0.00123",
"percentile": "0.0236"
},
"nvd": {
"cve": {
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"crypto/algif_aead.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "08ea39a556ecd39b33c2b4888861001c6706a62e",
"status": "affected",
"version": "d887c52d6ae43aeebd249b5f2f1333e60236aa60",
"versionType": "git"
},
{
"lessThan": "a920cabdb0b7cf1f4e11a20524253ae5bd09092b",
"status": "affected",
"version": "d887c52d6ae43aeebd249b5f2f1333e60236aa60",
"versionType": "git"
},
{
"lessThan": "fa0fcec9b49d58e71df7ede91ecd86855f608e85",
"status": "affected",
"version": "d887c52d6ae43aeebd249b5f2f1333e60236aa60",
"versionType": "git"
},
{
"lessThan": "c2138c9bd02af19e0b407376140cd5435b0d81da",
"status": "affected",
"version": "d887c52d6ae43aeebd249b5f2f1333e60236aa60",
"versionType": "git"
},
{
"lessThan": "46fdb39e83227b5d39f7c934a0947ea913f13c18",
"status": "affected",
"version": "d887c52d6ae43aeebd249b5f2f1333e60236aa60",
"versionType": "git"
},
{
"lessThan": "ebc235675f24b0e3f8bc92b8419471d42f837d8f",
"status": "affected",
"version": "d887c52d6ae43aeebd249b5f2f1333e60236aa60",
"versionType": "git"
},
{
"lessThan": "3d72f8c6490dc79210b64270740cb2a8619361a4",
"status": "affected",
"version": "d887c52d6ae43aeebd249b5f2f1333e60236aa60",
"versionType": "git"
},
{
"lessThan": "5aa58c3a572b3e3b6c786953339f7978b845cc52",
"status": "affected",
"version": "d887c52d6ae43aeebd249b5f2f1333e60236aa60",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"crypto/algif_aead.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "4.14"
},
{
"lessThan": "4.14",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.254",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.204",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.170",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.137",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.85",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.18.*",
"status": "unaffected",
"version": "6.18.27",
"versionType": "semver"
},
{
"lessThanOrEqual": "7.0.*",
"status": "unaffected",
"version": "7.0.4",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "7.1",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"configurations": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "24B62F9A-357D-465D-97EB-2819B1CD663C",
"versionEndExcluding": "5.10.254",
"versionStartIncluding": "4.14",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "FA800016-0012-4E3F-A528-2A7F378A0A4A",
"versionEndExcluding": "5.15.204",
"versionStartIncluding": "5.11",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "E6653854-B188-42DD-B8C5-0143F1956AB1",
"versionEndExcluding": "6.1.170",
"versionStartIncluding": "5.16",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "3CA3EF52-168A-4348-8F5F-356C9EB69261",
"versionEndExcluding": "6.6.137",
"versionStartIncluding": "6.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "F17D292D-A9B5-4DC7-8002-51AB95335606",
"versionEndExcluding": "6.12.85",
"versionStartIncluding": "6.7",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "A10AC84F-C058-47D5-85B4-E6E51A613B74",
"versionEndExcluding": "6.18.27",
"versionStartIncluding": "6.13",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "CDB78D6D-22C3-4154-B0D0-94AF1CE5C2E3",
"versionEndExcluding": "7.0.4",
"versionStartIncluding": "6.19",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: algif_aead - snapshot IV for async AEAD requests\n\nAF_ALG AEAD AIO requests currently use the socket-wide IV buffer during\nrequest processing. For async requests, later socket activity can\nupdate that shared state before the original request has fully\ncompleted, which can lead to inconsistent IV handling.\n\nSnapshot the IV into per-request storage when preparing the AEAD\nrequest, so in-flight operations no longer depend on mutable socket\nstate."
}
],
"id": "CVE-2026-46028",
"lastModified": "2026-06-17T10:52:55.603",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 5.5,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 3.6,
"source": "nvd@nist.gov",
"type": "Primary"
}
]
},
"published": "2026-05-27T14:17:21.420",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/08ea39a556ecd39b33c2b4888861001c6706a62e"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/3d72f8c6490dc79210b64270740cb2a8619361a4"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/46fdb39e83227b5d39f7c934a0947ea913f13c18"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/5aa58c3a572b3e3b6c786953339f7978b845cc52"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/a920cabdb0b7cf1f4e11a20524253ae5bd09092b"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/c2138c9bd02af19e0b407376140cd5435b0d81da"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/ebc235675f24b0e3f8bc92b8419471d42f837d8f"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/fa0fcec9b49d58e71df7ede91ecd86855f608e85"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Analyzed",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "NVD-CWE-noinfo"
}
],
"source": "nvd@nist.gov",
"type": "Primary"
}
]
}
},
"redhat_vex": {
"aggregate_severity": "Moderate",
"current_release_date": "2026-06-28T06:45:33+00:00",
"cve": "CVE-2026-46028",
"id": "CVE-2026-46028",
"initial_release_date": "2026-05-27T00:00:00+00:00",
"product_status:known_affected": "232",
"product_status:known_not_affected": "42",
"source": "Red Hat CSAF VEX",
"status": "final",
"title": "kernel: crypto: algif_aead - snapshot IV for async AEAD requests",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-46028.json",
"version": "3"
},
"suse_vex": {
"aggregate_severity": "moderate",
"current_release_date": "2026-09-11T01:13:13Z",
"cve": "CVE-2026-46028",
"id": "CVE-2026-46028",
"initial_release_date": "2026-05-28T03:54:06Z",
"product_status:known_affected": "656",
"product_status:known_not_affected": "6",
"product_status:recommended": "132",
"source": "SUSE CSAF VEX",
"status": "interim",
"title": "SUSE CVE CVE-2026-46028",
"url": "https://ftp.suse.com/pub/projects/security/csaf-vex/cve-2026-46028.json",
"version": "14"
}
}
}
CERTFR-2026-AVI-0926
Vulnerability from certfr_avis - Published: 2026-07-24 - Updated: 2026-07-24
De multiples vulnérabilités ont été découvertes dans le noyau Linux d'Ubuntu. Certaines d'entre elles permettent à un attaquant de provoquer une élévation de privilèges, une atteinte à la confidentialité des données et une atteinte à l'intégrité des données.
Solutions
Se référer au bulletin de sécurité de l'éditeur pour l'obtention des correctifs (cf. section Documentation).
None{
"$ref": "https://www.cert.ssi.gouv.fr/openapi.json",
"affected_systems": [
{
"description": "Ubuntu 26.04 LTS",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 20.04 ESM",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 24.04 LTS",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 25.10",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 22.04 LTS",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
}
],
"affected_systems_content": null,
"content": "## Solutions\n\nSe r\u00e9f\u00e9rer au bulletin de s\u00e9curit\u00e9 de l\u0027\u00e9diteur pour l\u0027obtention des correctifs (cf. section Documentation).",
"cves": [
{
"name": "CVE-2026-64141",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64141"
},
{
"name": "CVE-2026-46325",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46325"
},
{
"name": "CVE-2026-31623",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31623"
},
{
"name": "CVE-2026-45842",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45842"
},
{
"name": "CVE-2026-31483",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31483"
},
{
"name": "CVE-2026-64046",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64046"
},
{
"name": "CVE-2026-53091",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53091"
},
{
"name": "CVE-2026-43135",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43135"
},
{
"name": "CVE-2026-31409",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31409"
},
{
"name": "CVE-2026-45864",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45864"
},
{
"name": "CVE-2026-64186",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64186"
},
{
"name": "CVE-2026-31713",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31713"
},
{
"name": "CVE-2026-43113",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43113"
},
{
"name": "CVE-2026-53038",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53038"
},
{
"name": "CVE-2026-31522",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31522"
},
{
"name": "CVE-2026-43366",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43366"
},
{
"name": "CVE-2025-71187",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71187"
},
{
"name": "CVE-2026-43068",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43068"
},
{
"name": "CVE-2026-23167",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23167"
},
{
"name": "CVE-2026-31770",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31770"
},
{
"name": "CVE-2024-46770",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46770"
},
{
"name": "CVE-2026-46119",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46119"
},
{
"name": "CVE-2026-23447",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23447"
},
{
"name": "CVE-2026-43414",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43414"
},
{
"name": "CVE-2026-46211",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46211"
},
{
"name": "CVE-2026-46010",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46010"
},
{
"name": "CVE-2026-63957",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63957"
},
{
"name": "CVE-2026-46118",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46118"
},
{
"name": "CVE-2026-53119",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53119"
},
{
"name": "CVE-2026-52934",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52934"
},
{
"name": "CVE-2026-23129",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23129"
},
{
"name": "CVE-2026-46184",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46184"
},
{
"name": "CVE-2026-64133",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64133"
},
{
"name": "CVE-2026-31582",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31582"
},
{
"name": "CVE-2026-63864",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63864"
},
{
"name": "CVE-2026-53049",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53049"
},
{
"name": "CVE-2026-23387",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23387"
},
{
"name": "CVE-2025-22107",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22107"
},
{
"name": "CVE-2026-46045",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46045"
},
{
"name": "CVE-2026-31619",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31619"
},
{
"name": "CVE-2026-31658",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31658"
},
{
"name": "CVE-2026-64047",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64047"
},
{
"name": "CVE-2026-43413",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43413"
},
{
"name": "CVE-2026-64143",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64143"
},
{
"name": "CVE-2026-31618",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31618"
},
{
"name": "CVE-2026-64067",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64067"
},
{
"name": "CVE-2026-63854",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63854"
},
{
"name": "CVE-2026-31756",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31756"
},
{
"name": "CVE-2026-31467",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31467"
},
{
"name": "CVE-2026-52955",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52955"
},
{
"name": "CVE-2026-23318",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23318"
},
{
"name": "CVE-2026-23098",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23098"
},
{
"name": "CVE-2026-23092",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23092"
},
{
"name": "CVE-2026-23368",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23368"
},
{
"name": "CVE-2026-47329",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47329"
},
{
"name": "CVE-2026-43270",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43270"
},
{
"name": "CVE-2026-46328",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46328"
},
{
"name": "CVE-2026-52957",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52957"
},
{
"name": "CVE-2026-63974",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63974"
},
{
"name": "CVE-2026-46081",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46081"
},
{
"name": "CVE-2026-53116",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53116"
},
{
"name": "CVE-2026-52925",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52925"
},
{
"name": "CVE-2026-23079",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23079"
},
{
"name": "CVE-2026-43227",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43227"
},
{
"name": "CVE-2026-46307",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46307"
},
{
"name": "CVE-2026-46130",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46130"
},
{
"name": "CVE-2026-63943",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63943"
},
{
"name": "CVE-2026-43468",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43468"
},
{
"name": "CVE-2026-63980",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63980"
},
{
"name": "CVE-2026-52968",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52968"
},
{
"name": "CVE-2026-45845",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45845"
},
{
"name": "CVE-2026-53061",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53061"
},
{
"name": "CVE-2026-53292",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53292"
},
{
"name": "CVE-2026-43448",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43448"
},
{
"name": "CVE-2026-46087",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46087"
},
{
"name": "CVE-2026-64172",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64172"
},
{
"name": "CVE-2026-53027",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53027"
},
{
"name": "CVE-2026-64074",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64074"
},
{
"name": "CVE-2026-63843",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63843"
},
{
"name": "CVE-2026-53364",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53364"
},
{
"name": "CVE-2026-43315",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43315"
},
{
"name": "CVE-2026-53374",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53374"
},
{
"name": "CVE-2026-31485",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31485"
},
{
"name": "CVE-2026-23022",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23022"
},
{
"name": "CVE-2026-43314",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43314"
},
{
"name": "CVE-2026-63923",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63923"
},
{
"name": "CVE-2026-43373",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43373"
},
{
"name": "CVE-2026-23475",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23475"
},
{
"name": "CVE-2026-53002",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53002"
},
{
"name": "CVE-2026-53090",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53090"
},
{
"name": "CVE-2026-23126",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23126"
},
{
"name": "CVE-2026-53287",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53287"
},
{
"name": "CVE-2026-46124",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46124"
},
{
"name": "CVE-2026-53301",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53301"
},
{
"name": "CVE-2026-31578",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31578"
},
{
"name": "CVE-2026-64094",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64094"
},
{
"name": "CVE-2026-46082",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46082"
},
{
"name": "CVE-2026-63921",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63921"
},
{
"name": "CVE-2026-63966",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63966"
},
{
"name": "CVE-2026-43251",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43251"
},
{
"name": "CVE-2026-63841",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63841"
},
{
"name": "CVE-2026-43421",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43421"
},
{
"name": "CVE-2026-53117",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53117"
},
{
"name": "CVE-2026-63882",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63882"
},
{
"name": "CVE-2026-23054",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23054"
},
{
"name": "CVE-2026-31754",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31754"
},
{
"name": "CVE-2026-53128",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53128"
},
{
"name": "CVE-2026-23014",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23014"
},
{
"name": "CVE-2026-43211",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43211"
},
{
"name": "CVE-2026-53320",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53320"
},
{
"name": "CVE-2026-63838",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63838"
},
{
"name": "CVE-2026-31402",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31402"
},
{
"name": "CVE-2026-23122",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23122"
},
{
"name": "CVE-2026-23072",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23072"
},
{
"name": "CVE-2026-46134",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46134"
},
{
"name": "CVE-2024-56727",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56727"
},
{
"name": "CVE-2026-46042",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46042"
},
{
"name": "CVE-2026-45852",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45852"
},
{
"name": "CVE-2026-43483",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43483"
},
{
"name": "CVE-2026-23426",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23426"
},
{
"name": "CVE-2026-31758",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31758"
},
{
"name": "CVE-2026-64077",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64077"
},
{
"name": "CVE-2025-68736",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68736"
},
{
"name": "CVE-2026-23159",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23159"
},
{
"name": "CVE-2026-53092",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53092"
},
{
"name": "CVE-2026-53010",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53010"
},
{
"name": "CVE-2026-45856",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45856"
},
{
"name": "CVE-2026-64023",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64023"
},
{
"name": "CVE-2024-53221",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53221"
},
{
"name": "CVE-2026-46121",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46121"
},
{
"name": "CVE-2025-71265",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71265"
},
{
"name": "CVE-2026-23045",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23045"
},
{
"name": "CVE-2026-53378",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53378"
},
{
"name": "CVE-2026-43377",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43377"
},
{
"name": "CVE-2026-46076",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46076"
},
{
"name": "CVE-2026-23450",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23450"
},
{
"name": "CVE-2026-53041",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53041"
},
{
"name": "CVE-2026-23281",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23281"
},
{
"name": "CVE-2026-53066",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53066"
},
{
"name": "CVE-2026-43372",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43372"
},
{
"name": "CVE-2026-64099",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64099"
},
{
"name": "CVE-2026-43457",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43457"
},
{
"name": "CVE-2026-64179",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64179"
},
{
"name": "CVE-2026-31696",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31696"
},
{
"name": "CVE-2026-43168",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43168"
},
{
"name": "CVE-2026-43119",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43119"
},
{
"name": "CVE-2026-31530",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31530"
},
{
"name": "CVE-2026-43060",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43060"
},
{
"name": "CVE-2026-23114",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23114"
},
{
"name": "CVE-2025-71221",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71221"
},
{
"name": "CVE-2026-31704",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31704"
},
{
"name": "CVE-2026-31685",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31685"
},
{
"name": "CVE-2026-63852",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63852"
},
{
"name": "CVE-2026-53109",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53109"
},
{
"name": "CVE-2026-52970",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52970"
},
{
"name": "CVE-2026-53367",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53367"
},
{
"name": "CVE-2026-52958",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52958"
},
{
"name": "CVE-2026-64006",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64006"
},
{
"name": "CVE-2026-53297",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53297"
},
{
"name": "CVE-2026-63995",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63995"
},
{
"name": "CVE-2023-53629",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53629"
},
{
"name": "CVE-2026-43073",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43073"
},
{
"name": "CVE-2026-63911",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63911"
},
{
"name": "CVE-2026-46319",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46319"
},
{
"name": "CVE-2026-53104",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53104"
},
{
"name": "CVE-2026-64042",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64042"
},
{
"name": "CVE-2026-31416",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31416"
},
{
"name": "CVE-2026-43492",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43492"
},
{
"name": "CVE-2026-46013",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46013"
},
{
"name": "CVE-2026-23069",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23069"
},
{
"name": "CVE-2026-63993",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63993"
},
{
"name": "CVE-2026-31656",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31656"
},
{
"name": "CVE-2026-53014",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53014"
},
{
"name": "CVE-2026-52999",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52999"
},
{
"name": "CVE-2026-22992",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22992"
},
{
"name": "CVE-2026-46065",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46065"
},
{
"name": "CVE-2026-46227",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46227"
},
{
"name": "CVE-2026-53305",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53305"
},
{
"name": "CVE-2026-43455",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43455"
},
{
"name": "CVE-2025-39764",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39764"
},
{
"name": "CVE-2026-31453",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31453"
},
{
"name": "CVE-2026-23004",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23004"
},
{
"name": "CVE-2026-43241",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43241"
},
{
"name": "CVE-2025-71191",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71191"
},
{
"name": "CVE-2026-31593",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31593"
},
{
"name": "CVE-2026-53040",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53040"
},
{
"name": "CVE-2026-46007",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46007"
},
{
"name": "CVE-2026-23438",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23438"
},
{
"name": "CVE-2026-43062",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43062"
},
{
"name": "CVE-2026-47330",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47330"
},
{
"name": "CVE-2026-23293",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23293"
},
{
"name": "CVE-2026-23463",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23463"
},
{
"name": "CVE-2026-63988",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63988"
},
{
"name": "CVE-2026-23227",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23227"
},
{
"name": "CVE-2026-46185",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46185"
},
{
"name": "CVE-2026-43145",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43145"
},
{
"name": "CVE-2026-63839",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63839"
},
{
"name": "CVE-2026-46253",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46253"
},
{
"name": "CVE-2026-64151",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64151"
},
{
"name": "CVE-2026-23454",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23454"
},
{
"name": "CVE-2026-31405",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31405"
},
{
"name": "CVE-2026-43136",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43136"
},
{
"name": "CVE-2026-63886",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63886"
},
{
"name": "CVE-2026-64045",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64045"
},
{
"name": "CVE-2026-23009",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23009"
},
{
"name": "CVE-2026-43339",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43339"
},
{
"name": "CVE-2026-53106",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53106"
},
{
"name": "CVE-2026-64025",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64025"
},
{
"name": "CVE-2026-31600",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31600"
},
{
"name": "CVE-2026-63931",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63931"
},
{
"name": "CVE-2026-43054",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43054"
},
{
"name": "CVE-2026-23465",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23465"
},
{
"name": "CVE-2026-46064",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46064"
},
{
"name": "CVE-2026-46298",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46298"
},
{
"name": "CVE-2026-23143",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23143"
},
{
"name": "CVE-2026-45988",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45988"
},
{
"name": "CVE-2026-31698",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31698"
},
{
"name": "CVE-2026-31664",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31664"
},
{
"name": "CVE-2026-45868",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45868"
},
{
"name": "CVE-2026-46112",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46112"
},
{
"name": "CVE-2026-64176",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64176"
},
{
"name": "CVE-2024-27389",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27389"
},
{
"name": "CVE-2026-64128",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64128"
},
{
"name": "CVE-2026-31542",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31542"
},
{
"name": "CVE-2026-31473",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31473"
},
{
"name": "CVE-2026-53278",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53278"
},
{
"name": "CVE-2026-46196",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46196"
},
{
"name": "CVE-2026-31556",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31556"
},
{
"name": "CVE-2026-43123",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43123"
},
{
"name": "CVE-2026-46170",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46170"
},
{
"name": "CVE-2026-31528",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31528"
},
{
"name": "CVE-2026-64059",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64059"
},
{
"name": "CVE-2026-31448",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31448"
},
{
"name": "CVE-2026-31597",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31597"
},
{
"name": "CVE-2025-21709",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21709"
},
{
"name": "CVE-2026-53020",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53020"
},
{
"name": "CVE-2026-53121",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53121"
},
{
"name": "CVE-2026-64132",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64132"
},
{
"name": "CVE-2026-22981",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22981"
},
{
"name": "CVE-2026-31550",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31550"
},
{
"name": "CVE-2026-23220",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23220"
},
{
"name": "CVE-2026-31487",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31487"
},
{
"name": "CVE-2026-23290",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23290"
},
{
"name": "CVE-2026-43408",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43408"
},
{
"name": "CVE-2026-31740",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31740"
},
{
"name": "CVE-2026-31549",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31549"
},
{
"name": "CVE-2025-40103",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40103"
},
{
"name": "CVE-2026-23020",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23020"
},
{
"name": "CVE-2026-31752",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31752"
},
{
"name": "CVE-2025-40016",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40016"
},
{
"name": "CVE-2025-38626",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38626"
},
{
"name": "CVE-2026-46194",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46194"
},
{
"name": "CVE-2026-43476",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43476"
},
{
"name": "CVE-2026-43202",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43202"
},
{
"name": "CVE-2026-52989",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52989"
},
{
"name": "CVE-2026-53370",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53370"
},
{
"name": "CVE-2026-63924",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63924"
},
{
"name": "CVE-2026-46063",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46063"
},
{
"name": "CVE-2026-53291",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53291"
},
{
"name": "CVE-2026-43064",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43064"
},
{
"name": "CVE-2025-71201",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71201"
},
{
"name": "CVE-2026-23468",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23468"
},
{
"name": "CVE-2026-63979",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63979"
},
{
"name": "CVE-2026-23303",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23303"
},
{
"name": "CVE-2026-46280",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46280"
},
{
"name": "CVE-2026-43011",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43011"
},
{
"name": "CVE-2026-63928",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63928"
},
{
"name": "CVE-2026-43132",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43132"
},
{
"name": "CVE-2026-63940",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63940"
},
{
"name": "CVE-2026-43092",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43092"
},
{
"name": "CVE-2025-68175",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68175"
},
{
"name": "CVE-2026-31396",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31396"
},
{
"name": "CVE-2026-53029",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53029"
},
{
"name": "CVE-2026-23136",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23136"
},
{
"name": "CVE-2026-23139",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23139"
},
{
"name": "CVE-2026-23461",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23461"
},
{
"name": "CVE-2026-63879",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63879"
},
{
"name": "CVE-2026-31680",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31680"
},
{
"name": "CVE-2026-43044",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43044"
},
{
"name": "CVE-2026-23017",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23017"
},
{
"name": "CVE-2026-31586",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31586"
},
{
"name": "CVE-2026-46287",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46287"
},
{
"name": "CVE-2026-23340",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23340"
},
{
"name": "CVE-2026-43046",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43046"
},
{
"name": "CVE-2026-46233",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46233"
},
{
"name": "CVE-2026-52918",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52918"
},
{
"name": "CVE-2025-71189",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71189"
},
{
"name": "CVE-2026-46117",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46117"
},
{
"name": "CVE-2026-52963",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52963"
},
{
"name": "CVE-2026-46140",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46140"
},
{
"name": "CVE-2026-53373",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53373"
},
{
"name": "CVE-2025-68334",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68334"
},
{
"name": "CVE-2026-63933",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63933"
},
{
"name": "CVE-2026-53286",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53286"
},
{
"name": "CVE-2026-46303",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46303"
},
{
"name": "CVE-2026-31613",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31613"
},
{
"name": "CVE-2026-46114",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46114"
},
{
"name": "CVE-2026-23090",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23090"
},
{
"name": "CVE-2026-43163",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43163"
},
{
"name": "CVE-2026-23007",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23007"
},
{
"name": "CVE-2026-31738",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31738"
},
{
"name": "CVE-2026-46032",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46032"
},
{
"name": "CVE-2026-23035",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23035"
},
{
"name": "CVE-2026-23441",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23441"
},
{
"name": "CVE-2026-53365",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53365"
},
{
"name": "CVE-2026-64082",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64082"
},
{
"name": "CVE-2025-68307",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68307"
},
{
"name": "CVE-2026-53081",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53081"
},
{
"name": "CVE-2025-40005",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40005"
},
{
"name": "CVE-2026-31574",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31574"
},
{
"name": "CVE-2026-46057",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46057"
},
{
"name": "CVE-2026-43411",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43411"
},
{
"name": "CVE-2026-31751",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31751"
},
{
"name": "CVE-2026-63915",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63915"
},
{
"name": "CVE-2026-43429",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43429"
},
{
"name": "CVE-2026-53360",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53360"
},
{
"name": "CVE-2026-46141",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46141"
},
{
"name": "CVE-2026-52993",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52993"
},
{
"name": "CVE-2026-46080",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46080"
},
{
"name": "CVE-2026-23064",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23064"
},
{
"name": "CVE-2026-63847",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63847"
},
{
"name": "CVE-2026-43284",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43284"
},
{
"name": "CVE-2025-71287",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71287"
},
{
"name": "CVE-2026-46231",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46231"
},
{
"name": "CVE-2026-52996",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52996"
},
{
"name": "CVE-2026-63888",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63888"
},
{
"name": "CVE-2026-23383",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23383"
},
{
"name": "CVE-2026-53095",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53095"
},
{
"name": "CVE-2026-45995",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45995"
},
{
"name": "CVE-2026-43362",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43362"
},
{
"name": "CVE-2026-46034",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46034"
},
{
"name": "CVE-2026-23412",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23412"
},
{
"name": "CVE-2026-45835",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45835"
},
{
"name": "CVE-2026-53007",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53007"
},
{
"name": "CVE-2026-43382",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43382"
},
{
"name": "CVE-2026-64162",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64162"
},
{
"name": "CVE-2026-22987",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22987"
},
{
"name": "CVE-2026-64104",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64104"
},
{
"name": "CVE-2026-23439",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23439"
},
{
"name": "CVE-2026-52956",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52956"
},
{
"name": "CVE-2026-23253",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23253"
},
{
"name": "CVE-2026-52943",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52943"
},
{
"name": "CVE-2026-43025",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43025"
},
{
"name": "CVE-2026-31581",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31581"
},
{
"name": "CVE-2026-31721",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31721"
},
{
"name": "CVE-2026-63896",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63896"
},
{
"name": "CVE-2026-23061",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23061"
},
{
"name": "CVE-2026-23059",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23059"
},
{
"name": "CVE-2026-31617",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31617"
},
{
"name": "CVE-2026-45996",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45996"
},
{
"name": "CVE-2026-46229",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46229"
},
{
"name": "CVE-2026-23115",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23115"
},
{
"name": "CVE-2026-46286",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46286"
},
{
"name": "CVE-2026-31687",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31687"
},
{
"name": "CVE-2026-46019",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46019"
},
{
"name": "CVE-2026-23271",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23271"
},
{
"name": "CVE-2026-43052",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43052"
},
{
"name": "CVE-2026-43496",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43496"
},
{
"name": "CVE-2026-64178",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64178"
},
{
"name": "CVE-2026-23135",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23135"
},
{
"name": "CVE-2026-43324",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43324"
},
{
"name": "CVE-2026-52915",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52915"
},
{
"name": "CVE-2026-64177",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64177"
},
{
"name": "CVE-2026-23047",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23047"
},
{
"name": "CVE-2026-46173",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46173"
},
{
"name": "CVE-2026-46195",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46195"
},
{
"name": "CVE-2026-46204",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46204"
},
{
"name": "CVE-2026-46214",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46214"
},
{
"name": "CVE-2026-63956",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63956"
},
{
"name": "CVE-2026-23119",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23119"
},
{
"name": "CVE-2026-23173",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23173"
},
{
"name": "CVE-2026-53354",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53354"
},
{
"name": "CVE-2026-23434",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23434"
},
{
"name": "CVE-2026-31655",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31655"
},
{
"name": "CVE-2026-31711",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31711"
},
{
"name": "CVE-2026-46182",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46182"
},
{
"name": "CVE-2026-63845",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63845"
},
{
"name": "CVE-2026-53103",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53103"
},
{
"name": "CVE-2026-64017",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64017"
},
{
"name": "CVE-2026-53313",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53313"
},
{
"name": "CVE-2026-31611",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31611"
},
{
"name": "CVE-2026-31502",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31502"
},
{
"name": "CVE-2026-46183",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46183"
},
{
"name": "CVE-2026-53321",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53321"
},
{
"name": "CVE-2026-23123",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23123"
},
{
"name": "CVE-2026-64098",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64098"
},
{
"name": "CVE-2026-43018",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43018"
},
{
"name": "CVE-2026-23137",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23137"
},
{
"name": "CVE-2026-31741",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31741"
},
{
"name": "CVE-2026-43014",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43014"
},
{
"name": "CVE-2026-31714",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31714"
},
{
"name": "CVE-2026-43139",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43139"
},
{
"name": "CVE-2026-45873",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45873"
},
{
"name": "CVE-2026-23222",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23222"
},
{
"name": "CVE-2026-63842",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63842"
},
{
"name": "CVE-2026-46158",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46158"
},
{
"name": "CVE-2026-63929",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63929"
},
{
"name": "CVE-2026-31447",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31447"
},
{
"name": "CVE-2025-22116",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22116"
},
{
"name": "CVE-2026-45870",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45870"
},
{
"name": "CVE-2026-43371",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43371"
},
{
"name": "CVE-2026-23226",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23226"
},
{
"name": "CVE-2026-23285",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23285"
},
{
"name": "CVE-2026-46027",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46027"
},
{
"name": "CVE-2026-64146",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64146"
},
{
"name": "CVE-2026-53309",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53309"
},
{
"name": "CVE-2026-43445",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43445"
},
{
"name": "CVE-2026-46320",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46320"
},
{
"name": "CVE-2026-31645",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31645"
},
{
"name": "CVE-2026-23094",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23094"
},
{
"name": "CVE-2026-23049",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23049"
},
{
"name": "CVE-2026-23470",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23470"
},
{
"name": "CVE-2026-63910",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63910"
},
{
"name": "CVE-2026-46092",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46092"
},
{
"name": "CVE-2026-43488",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43488"
},
{
"name": "CVE-2026-43387",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43387"
},
{
"name": "CVE-2026-23418",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23418"
},
{
"name": "CVE-2026-53097",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53097"
},
{
"name": "CVE-2026-31599",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31599"
},
{
"name": "CVE-2025-21712",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21712"
},
{
"name": "CVE-2026-43028",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43028"
},
{
"name": "CVE-2026-31511",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31511"
},
{
"name": "CVE-2026-63948",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63948"
},
{
"name": "CVE-2026-31614",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31614"
},
{
"name": "CVE-2026-46040",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46040"
},
{
"name": "CVE-2026-46236",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46236"
},
{
"name": "CVE-2026-31482",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31482"
},
{
"name": "CVE-2026-45871",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45871"
},
{
"name": "CVE-2026-23229",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23229"
},
{
"name": "CVE-2026-43475",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43475"
},
{
"name": "CVE-2026-23042",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23042"
},
{
"name": "CVE-2026-64013",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64013"
},
{
"name": "CVE-2026-52913",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52913"
},
{
"name": "CVE-2026-31548",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31548"
},
{
"name": "CVE-2026-46113",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46113"
},
{
"name": "CVE-2025-38710",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38710"
},
{
"name": "CVE-2026-23304",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23304"
},
{
"name": "CVE-2026-31683",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31683"
},
{
"name": "CVE-2024-56557",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56557"
},
{
"name": "CVE-2026-43415",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43415"
},
{
"name": "CVE-2026-43262",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43262"
},
{
"name": "CVE-2026-23101",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23101"
},
{
"name": "CVE-2026-46001",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46001"
},
{
"name": "CVE-2026-23357",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23357"
},
{
"name": "CVE-2026-45946",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45946"
},
{
"name": "CVE-2026-46071",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46071"
},
{
"name": "CVE-2026-23099",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23099"
},
{
"name": "CVE-2026-45860",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45860"
},
{
"name": "CVE-2026-31408",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31408"
},
{
"name": "CVE-2026-43279",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43279"
},
{
"name": "CVE-2026-43058",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43058"
},
{
"name": "CVE-2026-46137",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46137"
},
{
"name": "CVE-2025-38105",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38105"
},
{
"name": "CVE-2026-53071",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53071"
},
{
"name": "CVE-2026-52941",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52941"
},
{
"name": "CVE-2026-45841",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45841"
},
{
"name": "CVE-2026-53102",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53102"
},
{
"name": "CVE-2026-31524",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31524"
},
{
"name": "CVE-2026-46072",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46072"
},
{
"name": "CVE-2026-53044",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53044"
},
{
"name": "CVE-2026-63913",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63913"
},
{
"name": "CVE-2026-46188",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46188"
},
{
"name": "CVE-2026-64068",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64068"
},
{
"name": "CVE-2026-43231",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43231"
},
{
"name": "CVE-2026-31505",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31505"
},
{
"name": "CVE-2026-64038",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64038"
},
{
"name": "CVE-2026-31668",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31668"
},
{
"name": "CVE-2026-64107",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64107"
},
{
"name": "CVE-2026-23066",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23066"
},
{
"name": "CVE-2026-63925",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63925"
},
{
"name": "CVE-2025-38562",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38562"
},
{
"name": "CVE-2026-31478",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31478"
},
{
"name": "CVE-2026-46159",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46159"
},
{
"name": "CVE-2026-63990",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63990"
},
{
"name": "CVE-2026-31546",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31546"
},
{
"name": "CVE-2026-45956",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45956"
},
{
"name": "CVE-2026-46190",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46190"
},
{
"name": "CVE-2026-53051",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53051"
},
{
"name": "CVE-2026-22989",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22989"
},
{
"name": "CVE-2026-46142",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46142"
},
{
"name": "CVE-2026-23085",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23085"
},
{
"name": "CVE-2026-53015",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53015"
},
{
"name": "CVE-2023-52737",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52737"
},
{
"name": "CVE-2026-46066",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46066"
},
{
"name": "CVE-2026-43436",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43436"
},
{
"name": "CVE-2025-54505",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-54505"
},
{
"name": "CVE-2026-53013",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53013"
},
{
"name": "CVE-2026-53317",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53317"
},
{
"name": "CVE-2026-23150",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23150"
},
{
"name": "CVE-2025-38426",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38426"
},
{
"name": "CVE-2026-53054",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53054"
},
{
"name": "CVE-2026-64165",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64165"
},
{
"name": "CVE-2026-31583",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31583"
},
{
"name": "CVE-2026-53064",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53064"
},
{
"name": "CVE-2026-31605",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31605"
},
{
"name": "CVE-2026-23324",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23324"
},
{
"name": "CVE-2026-23236",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23236"
},
{
"name": "CVE-2026-23109",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23109"
},
{
"name": "CVE-2026-52995",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52995"
},
{
"name": "CVE-2026-46209",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46209"
},
{
"name": "CVE-2026-52931",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52931"
},
{
"name": "CVE-2026-23347",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23347"
},
{
"name": "CVE-2026-46031",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46031"
},
{
"name": "CVE-2026-23130",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23130"
},
{
"name": "CVE-2026-53113",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53113"
},
{
"name": "CVE-2026-64003",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64003"
},
{
"name": "CVE-2026-46277",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46277"
},
{
"name": "CVE-2026-46153",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46153"
},
{
"name": "CVE-2026-23163",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23163"
},
{
"name": "CVE-2026-64076",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64076"
},
{
"name": "CVE-2026-31516",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31516"
},
{
"name": "CVE-2026-52951",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52951"
},
{
"name": "CVE-2026-53058",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53058"
},
{
"name": "CVE-2026-23317",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23317"
},
{
"name": "CVE-2026-53094",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53094"
},
{
"name": "CVE-2026-43047",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43047"
},
{
"name": "CVE-2026-53047",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53047"
},
{
"name": "CVE-2025-71235",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71235"
},
{
"name": "CVE-2026-52961",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52961"
},
{
"name": "CVE-2026-43432",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43432"
},
{
"name": "CVE-2026-45866",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45866"
},
{
"name": "CVE-2026-53368",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53368"
},
{
"name": "CVE-2026-53296",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53296"
},
{
"name": "CVE-2026-23057",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23057"
},
{
"name": "CVE-2026-64097",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64097"
},
{
"name": "CVE-2024-46715",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46715"
},
{
"name": "CVE-2026-31389",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31389"
},
{
"name": "CVE-2026-31635",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31635"
},
{
"name": "CVE-2026-31394",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31394"
},
{
"name": "CVE-2026-31545",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31545"
},
{
"name": "CVE-2026-31681",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31681"
},
{
"name": "CVE-2026-31598",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31598"
},
{
"name": "CVE-2026-23456",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23456"
},
{
"name": "CVE-2026-46186",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46186"
},
{
"name": "CVE-2026-43458",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43458"
},
{
"name": "CVE-2026-43023",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43023"
},
{
"name": "CVE-2026-23166",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23166"
},
{
"name": "CVE-2026-53101",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53101"
},
{
"name": "CVE-2026-52919",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52919"
},
{
"name": "CVE-2026-46169",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46169"
},
{
"name": "CVE-2026-23287",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23287"
},
{
"name": "CVE-2026-53006",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53006"
},
{
"name": "CVE-2026-43450",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43450"
},
{
"name": "CVE-2026-63880",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63880"
},
{
"name": "CVE-2026-43345",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43345"
},
{
"name": "CVE-2026-31731",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31731"
},
{
"name": "CVE-2026-31510",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31510"
},
{
"name": "CVE-2026-53324",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53324"
},
{
"name": "CVE-2026-43012",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43012"
},
{
"name": "CVE-2026-63989",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63989"
},
{
"name": "CVE-2026-31622",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31622"
},
{
"name": "CVE-2026-22991",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22991"
},
{
"name": "CVE-2026-43079",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43079"
},
{
"name": "CVE-2026-23457",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23457"
},
{
"name": "CVE-2026-23081",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23081"
},
{
"name": "CVE-2026-63964",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63964"
},
{
"name": "CVE-2026-64102",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64102"
},
{
"name": "CVE-2026-46002",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46002"
},
{
"name": "CVE-2026-46074",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46074"
},
{
"name": "CVE-2026-31595",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31595"
},
{
"name": "CVE-2026-46332",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46332"
},
{
"name": "CVE-2026-43503",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43503"
},
{
"name": "CVE-2026-46101",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46101"
},
{
"name": "CVE-2026-46099",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46099"
},
{
"name": "CVE-2026-45989",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45989"
},
{
"name": "CVE-2026-46091",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46091"
},
{
"name": "CVE-2026-43103",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43103"
},
{
"name": "CVE-2026-43069",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43069"
},
{
"name": "CVE-2026-64041",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64041"
},
{
"name": "CVE-2026-43425",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43425"
},
{
"name": "CVE-2026-64071",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64071"
},
{
"name": "CVE-2026-31496",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31496"
},
{
"name": "CVE-2026-63863",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63863"
},
{
"name": "CVE-2026-53377",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53377"
},
{
"name": "CVE-2026-31642",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31642"
},
{
"name": "CVE-2026-46024",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46024"
},
{
"name": "CVE-2026-64129",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64129"
},
{
"name": "CVE-2026-23399",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23399"
},
{
"name": "CVE-2026-23334",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23334"
},
{
"name": "CVE-2026-53028",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53028"
},
{
"name": "CVE-2026-43350",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43350"
},
{
"name": "CVE-2026-53312",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53312"
},
{
"name": "CVE-2026-23012",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23012"
},
{
"name": "CVE-2026-43376",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43376"
},
{
"name": "CVE-2026-46106",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46106"
},
{
"name": "CVE-2026-23116",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23116"
},
{
"name": "CVE-2026-31659",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31659"
},
{
"name": "CVE-2026-31701",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31701"
},
{
"name": "CVE-2026-45847",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45847"
},
{
"name": "CVE-2026-31591",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31591"
},
{
"name": "CVE-2024-50012",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50012"
},
{
"name": "CVE-2026-43480",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43480"
},
{
"name": "CVE-2026-64083",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64083"
},
{
"name": "CVE-2026-64169",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64169"
},
{
"name": "CVE-2026-23401",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23401"
},
{
"name": "CVE-2026-46041",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46041"
},
{
"name": "CVE-2025-71239",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71239"
},
{
"name": "CVE-2026-46037",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46037"
},
{
"name": "CVE-2026-46116",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46116"
},
{
"name": "CVE-2026-64106",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64106"
},
{
"name": "CVE-2026-43268",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43268"
},
{
"name": "CVE-2026-46203",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46203"
},
{
"name": "CVE-2026-53048",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53048"
},
{
"name": "CVE-2026-23207",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23207"
},
{
"name": "CVE-2025-71200",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71200"
},
{
"name": "CVE-2026-63932",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63932"
},
{
"name": "CVE-2026-43057",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43057"
},
{
"name": "CVE-2026-43426",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43426"
},
{
"name": "CVE-2026-43117",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43117"
},
{
"name": "CVE-2026-63892",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63892"
},
{
"name": "CVE-2026-63850",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63850"
},
{
"name": "CVE-2026-46083",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46083"
},
{
"name": "CVE-2026-43030",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43030"
},
{
"name": "CVE-2024-36898",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36898"
},
{
"name": "CVE-2026-43074",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43074"
},
{
"name": "CVE-2026-46151",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46151"
},
{
"name": "CVE-2026-22980",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22980"
},
{
"name": "CVE-2026-23138",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23138"
},
{
"name": "CVE-2026-64010",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64010"
},
{
"name": "CVE-2026-63947",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63947"
},
{
"name": "CVE-2026-23172",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23172"
},
{
"name": "CVE-2026-63950",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63950"
},
{
"name": "CVE-2026-23046",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23046"
},
{
"name": "CVE-2026-43493",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43493"
},
{
"name": "CVE-2026-45912",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45912"
},
{
"name": "CVE-2026-45911",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45911"
},
{
"name": "CVE-2026-43383",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43383"
},
{
"name": "CVE-2025-38250",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38250"
},
{
"name": "CVE-2026-46220",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46220"
},
{
"name": "CVE-2026-52975",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52975"
},
{
"name": "CVE-2026-46259",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46259"
},
{
"name": "CVE-2026-31525",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31525"
},
{
"name": "CVE-2026-31638",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31638"
},
{
"name": "CVE-2026-64008",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64008"
},
{
"name": "CVE-2026-43500",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43500"
},
{
"name": "CVE-2026-31772",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31772"
},
{
"name": "CVE-2026-53315",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53315"
},
{
"name": "CVE-2026-64163",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64163"
},
{
"name": "CVE-2026-31588",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31588"
},
{
"name": "CVE-2026-46147",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46147"
},
{
"name": "CVE-2026-43334",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43334"
},
{
"name": "CVE-2026-23234",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23234"
},
{
"name": "CVE-2026-23391",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23391"
},
{
"name": "CVE-2026-64050",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64050"
},
{
"name": "CVE-2026-31415",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31415"
},
{
"name": "CVE-2026-46127",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46127"
},
{
"name": "CVE-2026-23133",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23133"
},
{
"name": "CVE-2026-45869",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45869"
},
{
"name": "CVE-2026-31703",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31703"
},
{
"name": "CVE-2026-63975",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63975"
},
{
"name": "CVE-2026-23131",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23131"
},
{
"name": "CVE-2026-23212",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23212"
},
{
"name": "CVE-2026-23032",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23032"
},
{
"name": "CVE-2026-23170",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23170"
},
{
"name": "CVE-2026-63859",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63859"
},
{
"name": "CVE-2026-63952",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63952"
},
{
"name": "CVE-2026-53114",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53114"
},
{
"name": "CVE-2026-46097",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46097"
},
{
"name": "CVE-2024-47809",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47809"
},
{
"name": "CVE-2026-63965",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63965"
},
{
"name": "CVE-2026-23204",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23204"
},
{
"name": "CVE-2026-64051",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64051"
},
{
"name": "CVE-2026-23462",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23462"
},
{
"name": "CVE-2026-53046",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53046"
},
{
"name": "CVE-2026-31563",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31563"
},
{
"name": "CVE-2026-53050",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53050"
},
{
"name": "CVE-2026-23019",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23019"
},
{
"name": "CVE-2026-46176",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46176"
},
{
"name": "CVE-2026-23372",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23372"
},
{
"name": "CVE-2026-43080",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43080"
},
{
"name": "CVE-2026-46146",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46146"
},
{
"name": "CVE-2025-71188",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71188"
},
{
"name": "CVE-2026-46030",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46030"
},
{
"name": "CVE-2026-45836",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45836"
},
{
"name": "CVE-2026-46318",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46318"
},
{
"name": "CVE-2026-64181",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64181"
},
{
"name": "CVE-2026-64039",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64039"
},
{
"name": "CVE-2026-23055",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23055"
},
{
"name": "CVE-2026-63855",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63855"
},
{
"name": "CVE-2026-46178",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46178"
},
{
"name": "CVE-2026-45846",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45846"
},
{
"name": "CVE-2026-45919",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45919"
},
{
"name": "CVE-2026-43499",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43499"
},
{
"name": "CVE-2026-23125",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23125"
},
{
"name": "CVE-2026-45862",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45862"
},
{
"name": "CVE-2026-46174",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46174"
},
{
"name": "CVE-2026-43036",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43036"
},
{
"name": "CVE-2026-43495",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43495"
},
{
"name": "CVE-2026-53021",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53021"
},
{
"name": "CVE-2026-46171",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46171"
},
{
"name": "CVE-2026-31689",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31689"
},
{
"name": "CVE-2026-43200",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43200"
},
{
"name": "CVE-2026-45857",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45857"
},
{
"name": "CVE-2026-45848",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45848"
},
{
"name": "CVE-2026-43327",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43327"
},
{
"name": "CVE-2026-23319",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23319"
},
{
"name": "CVE-2026-64061",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64061"
},
{
"name": "CVE-2026-23005",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23005"
},
{
"name": "CVE-2024-56719",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56719"
},
{
"name": "CVE-2026-47328",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47328"
},
{
"name": "CVE-2026-46133",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46133"
},
{
"name": "CVE-2026-31566",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31566"
},
{
"name": "CVE-2026-46005",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46005"
},
{
"name": "CVE-2026-31494",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31494"
},
{
"name": "CVE-2026-64040",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64040"
},
{
"name": "CVE-2026-63917",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63917"
},
{
"name": "CVE-2026-31565",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31565"
},
{
"name": "CVE-2026-31718",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31718"
},
{
"name": "CVE-2026-31697",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31697"
},
{
"name": "CVE-2026-43381",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43381"
},
{
"name": "CVE-2026-46308",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46308"
},
{
"name": "CVE-2025-62626",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-62626"
},
{
"name": "CVE-2026-23270",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23270"
},
{
"name": "CVE-2026-31763",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31763"
},
{
"name": "CVE-2026-23030",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23030"
},
{
"name": "CVE-2026-63926",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63926"
},
{
"name": "CVE-2026-46069",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46069"
},
{
"name": "CVE-2026-23279",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23279"
},
{
"name": "CVE-2026-64150",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64150"
},
{
"name": "CVE-2026-46288",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46288"
},
{
"name": "CVE-2026-22997",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22997"
},
{
"name": "CVE-2026-53110",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53110"
},
{
"name": "CVE-2026-52937",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52937"
},
{
"name": "CVE-2026-31616",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31616"
},
{
"name": "CVE-2026-31670",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31670"
},
{
"name": "CVE-2026-46122",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46122"
},
{
"name": "CVE-2026-64022",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64022"
},
{
"name": "CVE-2026-31724",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31724"
},
{
"name": "CVE-2026-31609",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31609"
},
{
"name": "CVE-2026-23228",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23228"
},
{
"name": "CVE-2026-46022",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46022"
},
{
"name": "CVE-2026-23244",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23244"
},
{
"name": "CVE-2026-64091",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64091"
},
{
"name": "CVE-2026-46241",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46241"
},
{
"name": "CVE-2026-23246",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23246"
},
{
"name": "CVE-2025-71196",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71196"
},
{
"name": "CVE-2026-63865",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63865"
},
{
"name": "CVE-2026-64052",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64052"
},
{
"name": "CVE-2026-31422",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31422"
},
{
"name": "CVE-2025-71304",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71304"
},
{
"name": "CVE-2026-23286",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23286"
},
{
"name": "CVE-2026-23359",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23359"
},
{
"name": "CVE-2026-46059",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46059"
},
{
"name": "CVE-2026-43232",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43232"
},
{
"name": "CVE-2026-23298",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23298"
},
{
"name": "CVE-2026-46323",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46323"
},
{
"name": "CVE-2026-46181",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46181"
},
{
"name": "CVE-2026-31469",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31469"
},
{
"name": "CVE-2026-45867",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45867"
},
{
"name": "CVE-2026-43264",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43264"
},
{
"name": "CVE-2026-46213",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46213"
},
{
"name": "CVE-2026-53288",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53288"
},
{
"name": "CVE-2026-31498",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31498"
},
{
"name": "CVE-2026-31615",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31615"
},
{
"name": "CVE-2026-46103",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46103"
},
{
"name": "CVE-2026-43348",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43348"
},
{
"name": "CVE-2026-45879",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45879"
},
{
"name": "CVE-2026-45883",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45883"
},
{
"name": "CVE-2026-31520",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31520"
},
{
"name": "CVE-2026-64109",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64109"
},
{
"name": "CVE-2026-31449",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31449"
},
{
"name": "CVE-2026-64085",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64085"
},
{
"name": "CVE-2026-46226",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46226"
},
{
"name": "CVE-2026-46043",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46043"
},
{
"name": "CVE-2026-46120",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46120"
},
{
"name": "CVE-2026-46198",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46198"
},
{
"name": "CVE-2026-43336",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43336"
},
{
"name": "CVE-2026-43104",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43104"
},
{
"name": "CVE-2026-31601",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31601"
},
{
"name": "CVE-2026-52954",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52954"
},
{
"name": "CVE-2026-23078",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23078"
},
{
"name": "CVE-2026-43269",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43269"
},
{
"name": "CVE-2026-64166",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64166"
},
{
"name": "CVE-2026-31418",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31418"
},
{
"name": "CVE-2026-47332",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47332"
},
{
"name": "CVE-2026-46189",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46189"
},
{
"name": "CVE-2026-23169",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23169"
},
{
"name": "CVE-2026-52997",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52997"
},
{
"name": "CVE-2026-43466",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43466"
},
{
"name": "CVE-2026-46315",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46315"
},
{
"name": "CVE-2026-64020",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64020"
},
{
"name": "CVE-2026-63875",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63875"
},
{
"name": "CVE-2026-63898",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63898"
},
{
"name": "CVE-2026-31620",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31620"
},
{
"name": "CVE-2026-52987",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52987"
},
{
"name": "CVE-2026-43197",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43197"
},
{
"name": "CVE-2026-46278",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46278"
},
{
"name": "CVE-2026-46011",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46011"
},
{
"name": "CVE-2026-23296",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23296"
},
{
"name": "CVE-2026-46296",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46296"
},
{
"name": "CVE-2026-46095",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46095"
},
{
"name": "CVE-2026-64148",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64148"
},
{
"name": "CVE-2026-64090",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64090"
},
{
"name": "CVE-2026-53130",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53130"
},
{
"name": "CVE-2026-46128",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46128"
},
{
"name": "CVE-2026-53070",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53070"
},
{
"name": "CVE-2026-52984",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52984"
},
{
"name": "CVE-2026-64004",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64004"
},
{
"name": "CVE-2026-31427",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31427"
},
{
"name": "CVE-2026-53088",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53088"
},
{
"name": "CVE-2026-31555",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31555"
},
{
"name": "CVE-2026-31594",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31594"
},
{
"name": "CVE-2026-31392",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31392"
},
{
"name": "CVE-2026-63992",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63992"
},
{
"name": "CVE-2026-46317",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46317"
},
{
"name": "CVE-2026-64155",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64155"
},
{
"name": "CVE-2026-43439",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43439"
},
{
"name": "CVE-2022-50073",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50073"
},
{
"name": "CVE-2026-23360",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23360"
},
{
"name": "CVE-2026-64147",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64147"
},
{
"name": "CVE-2026-43183",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43183"
},
{
"name": "CVE-2026-23103",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23103"
},
{
"name": "CVE-2026-63909",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63909"
},
{
"name": "CVE-2025-40150",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40150"
},
{
"name": "CVE-2026-31580",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31580"
},
{
"name": "CVE-2026-43099",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43099"
},
{
"name": "CVE-2026-43491",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43491"
},
{
"name": "CVE-2026-46242",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46242"
},
{
"name": "CVE-2026-53065",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53065"
},
{
"name": "CVE-2026-63976",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63976"
},
{
"name": "CVE-2026-52960",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52960"
},
{
"name": "CVE-2026-46100",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46100"
},
{
"name": "CVE-2026-63996",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63996"
},
{
"name": "CVE-2025-71199",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71199"
},
{
"name": "CVE-2026-53079",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53079"
},
{
"name": "CVE-2026-31515",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31515"
},
{
"name": "CVE-2026-31661",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31661"
},
{
"name": "CVE-2026-46293",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46293"
},
{
"name": "CVE-2026-43380",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43380"
},
{
"name": "CVE-2026-43452",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43452"
},
{
"name": "CVE-2026-64021",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64021"
},
{
"name": "CVE-2026-46012",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46012"
},
{
"name": "CVE-2026-31737",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31737"
},
{
"name": "CVE-2026-31606",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31606"
},
{
"name": "CVE-2025-68358",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68358"
},
{
"name": "CVE-2026-64152",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64152"
},
{
"name": "CVE-2026-46197",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46197"
},
{
"name": "CVE-2026-52952",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52952"
},
{
"name": "CVE-2026-63984",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63984"
},
{
"name": "CVE-2026-52973",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52973"
},
{
"name": "CVE-2026-46301",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46301"
},
{
"name": "CVE-2026-46223",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46223"
},
{
"name": "CVE-2026-64057",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64057"
},
{
"name": "CVE-2026-43017",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43017"
},
{
"name": "CVE-2026-46224",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46224"
},
{
"name": "CVE-2026-52914",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52914"
},
{
"name": "CVE-2026-43467",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43467"
},
{
"name": "CVE-2026-52916",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52916"
},
{
"name": "CVE-2026-53009",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53009"
},
{
"name": "CVE-2026-64167",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64167"
},
{
"name": "CVE-2026-45999",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45999"
},
{
"name": "CVE-2026-64180",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64180"
},
{
"name": "CVE-2026-23006",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23006"
},
{
"name": "CVE-2026-53034",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53034"
},
{
"name": "CVE-2026-53294",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53294"
},
{
"name": "CVE-2026-23165",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23165"
},
{
"name": "CVE-2026-45960",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45960"
},
{
"name": "CVE-2026-53084",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53084"
},
{
"name": "CVE-2026-43019",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43019"
},
{
"name": "CVE-2026-53105",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53105"
},
{
"name": "CVE-2026-43252",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43252"
},
{
"name": "CVE-2026-63866",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63866"
},
{
"name": "CVE-2026-23013",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23013"
},
{
"name": "CVE-2026-64105",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64105"
},
{
"name": "CVE-2025-71267",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71267"
},
{
"name": "CVE-2026-46243",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46243"
},
{
"name": "CVE-2026-64125",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64125"
},
{
"name": "CVE-2026-53283",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53283"
},
{
"name": "CVE-2026-43043",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43043"
},
{
"name": "CVE-2026-63884",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63884"
},
{
"name": "CVE-2025-71195",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71195"
},
{
"name": "CVE-2026-22994",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22994"
},
{
"name": "CVE-2026-23308",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23308"
},
{
"name": "CVE-2026-31705",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31705"
},
{
"name": "CVE-2026-52905",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52905"
},
{
"name": "CVE-2026-43140",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43140"
},
{
"name": "CVE-2026-43223",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43223"
},
{
"name": "CVE-2026-53111",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53111"
},
{
"name": "CVE-2026-31684",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31684"
},
{
"name": "CVE-2026-43205",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43205"
},
{
"name": "CVE-2026-23396",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23396"
},
{
"name": "CVE-2026-23083",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23083"
},
{
"name": "CVE-2026-31423",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31423"
},
{
"name": "CVE-2026-52922",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52922"
},
{
"name": "CVE-2026-46180",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46180"
},
{
"name": "CVE-2026-23088",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23088"
},
{
"name": "CVE-2026-53053",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53053"
},
{
"name": "CVE-2026-46038",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46038"
},
{
"name": "CVE-2026-64089",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64089"
},
{
"name": "CVE-2026-46295",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46295"
},
{
"name": "CVE-2026-64131",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64131"
},
{
"name": "CVE-2026-64048",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64048"
},
{
"name": "CVE-2026-31625",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31625"
},
{
"name": "CVE-2026-43051",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43051"
},
{
"name": "CVE-2026-31759",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31759"
},
{
"name": "CVE-2026-52992",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52992"
},
{
"name": "CVE-2026-31432",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31432"
},
{
"name": "CVE-2026-63987",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63987"
},
{
"name": "CVE-2023-45896",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-45896"
},
{
"name": "CVE-2026-64080",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64080"
},
{
"name": "CVE-2026-23370",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23370"
},
{
"name": "CVE-2026-43360",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43360"
},
{
"name": "CVE-2026-53112",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53112"
},
{
"name": "CVE-2026-63858",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63858"
},
{
"name": "CVE-2026-64170",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64170"
},
{
"name": "CVE-2026-46206",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46206"
},
{
"name": "CVE-2026-53124",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53124"
},
{
"name": "CVE-2026-52979",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52979"
},
{
"name": "CVE-2026-64100",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64100"
},
{
"name": "CVE-2026-23108",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23108"
},
{
"name": "CVE-2026-23302",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23302"
},
{
"name": "CVE-2025-71180",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71180"
},
{
"name": "CVE-2026-46000",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46000"
},
{
"name": "CVE-2026-43246",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43246"
},
{
"name": "CVE-2026-53086",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53086"
},
{
"name": "CVE-2026-23414",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23414"
},
{
"name": "CVE-2026-53371",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53371"
},
{
"name": "CVE-2026-31781",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31781"
},
{
"name": "CVE-2026-43449",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43449"
},
{
"name": "CVE-2026-23315",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23315"
},
{
"name": "CVE-2026-45948",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45948"
},
{
"name": "CVE-2026-43147",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43147"
},
{
"name": "CVE-2026-52965",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52965"
},
{
"name": "CVE-2026-47334",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47334"
},
{
"name": "CVE-2026-63978",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63978"
},
{
"name": "CVE-2025-71194",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71194"
},
{
"name": "CVE-2026-31523",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31523"
},
{
"name": "CVE-2026-53067",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53067"
},
{
"name": "CVE-2026-52994",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52994"
},
{
"name": "CVE-2026-23023",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23023"
},
{
"name": "CVE-2026-52988",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52988"
},
{
"name": "CVE-2026-46297",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46297"
},
{
"name": "CVE-2026-64112",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64112"
},
{
"name": "CVE-2026-43459",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43459"
},
{
"name": "CVE-2026-43419",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43419"
},
{
"name": "CVE-2026-31669",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31669"
},
{
"name": "CVE-2026-46154",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46154"
},
{
"name": "CVE-2026-31450",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31450"
},
{
"name": "CVE-2026-63853",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63853"
},
{
"name": "CVE-2026-46302",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46302"
},
{
"name": "CVE-2026-31671",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31671"
},
{
"name": "CVE-2026-31749",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31749"
},
{
"name": "CVE-2026-52971",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52971"
},
{
"name": "CVE-2026-22999",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22999"
},
{
"name": "CVE-2026-46234",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46234"
},
{
"name": "CVE-2026-46250",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46250"
},
{
"name": "CVE-2026-43328",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43328"
},
{
"name": "CVE-2026-23068",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23068"
},
{
"name": "CVE-2026-64018",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64018"
},
{
"name": "CVE-2024-41079",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41079"
},
{
"name": "CVE-2026-23089",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23089"
},
{
"name": "CVE-2026-43024",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43024"
},
{
"name": "CVE-2026-53099",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53099"
},
{
"name": "CVE-2026-46109",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46109"
},
{
"name": "CVE-2026-46062",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46062"
},
{
"name": "CVE-2026-53279",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53279"
},
{
"name": "CVE-2026-31723",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31723"
},
{
"name": "CVE-2026-45985",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45985"
},
{
"name": "CVE-2026-64069",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64069"
},
{
"name": "CVE-2026-46276",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46276"
},
{
"name": "CVE-2026-23071",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23071"
},
{
"name": "CVE-2026-43207",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43207"
},
{
"name": "CVE-2026-63916",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63916"
},
{
"name": "CVE-2025-23141",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23141"
},
{
"name": "CVE-2026-23056",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23056"
},
{
"name": "CVE-2026-63920",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63920"
},
{
"name": "CVE-2026-52981",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52981"
},
{
"name": "CVE-2026-46108",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46108"
},
{
"name": "CVE-2026-52927",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52927"
},
{
"name": "CVE-2026-31608",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31608"
},
{
"name": "CVE-2026-53060",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53060"
},
{
"name": "CVE-2026-31694",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31694"
},
{
"name": "CVE-2026-23352",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23352"
},
{
"name": "CVE-2026-53096",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53096"
},
{
"name": "CVE-2026-31720",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31720"
},
{
"name": "CVE-2026-46321",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46321"
},
{
"name": "CVE-2026-31554",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31554"
},
{
"name": "CVE-2026-31748",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31748"
},
{
"name": "CVE-2026-63930",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63930"
},
{
"name": "CVE-2026-31699",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31699"
},
{
"name": "CVE-2026-64171",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64171"
},
{
"name": "CVE-2026-64127",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64127"
},
{
"name": "CVE-2026-64027",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64027"
},
{
"name": "CVE-2026-53076",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53076"
},
{
"name": "CVE-2026-46049",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46049"
},
{
"name": "CVE-2026-46289",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46289"
},
{
"name": "CVE-2026-46285",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46285"
},
{
"name": "CVE-2026-43472",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43472"
},
{
"name": "CVE-2026-23367",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23367"
},
{
"name": "CVE-2026-31628",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31628"
},
{
"name": "CVE-2026-46283",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46283"
},
{
"name": "CVE-2026-43407",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43407"
},
{
"name": "CVE-2026-23063",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23063"
},
{
"name": "CVE-2026-63861",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63861"
},
{
"name": "CVE-2026-23427",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23427"
},
{
"name": "CVE-2026-45899",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45899"
},
{
"name": "CVE-2026-31662",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31662"
},
{
"name": "CVE-2026-23073",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23073"
},
{
"name": "CVE-2026-53018",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53018"
},
{
"name": "CVE-2026-46020",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46020"
},
{
"name": "CVE-2026-53302",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53302"
},
{
"name": "CVE-2026-53035",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53035"
},
{
"name": "CVE-2026-23058",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23058"
},
{
"name": "CVE-2024-36922",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36922"
},
{
"name": "CVE-2026-31768",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31768"
},
{
"name": "CVE-2026-23238",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23238"
},
{
"name": "CVE-2025-71182",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71182"
},
{
"name": "CVE-2026-43026",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43026"
},
{
"name": "CVE-2026-45997",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45997"
},
{
"name": "CVE-2026-31480",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31480"
},
{
"name": "CVE-2026-64055",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64055"
},
{
"name": "CVE-2026-43405",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43405"
},
{
"name": "CVE-2026-46070",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46070"
},
{
"name": "CVE-2026-23038",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23038"
},
{
"name": "CVE-2026-43430",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43430"
},
{
"name": "CVE-2026-43402",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43402"
},
{
"name": "CVE-2026-53375",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53375"
},
{
"name": "CVE-2026-43437",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43437"
},
{
"name": "CVE-2026-45920",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45920"
},
{
"name": "CVE-2026-46150",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46150"
},
{
"name": "CVE-2026-63938",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63938"
},
{
"name": "CVE-2026-53314",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53314"
},
{
"name": "CVE-2026-46090",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46090"
},
{
"name": "CVE-2026-22990",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22990"
},
{
"name": "CVE-2026-53123",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53123"
},
{
"name": "CVE-2026-23000",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23000"
},
{
"name": "CVE-2026-53126",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53126"
},
{
"name": "CVE-2025-71186",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71186"
},
{
"name": "CVE-2026-64060",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64060"
},
{
"name": "CVE-2026-43007",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43007"
},
{
"name": "CVE-2026-64026",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64026"
},
{
"name": "CVE-2026-46228",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46228"
},
{
"name": "CVE-2026-43184",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43184"
},
{
"name": "CVE-2026-53311",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53311"
},
{
"name": "CVE-2026-45840",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45840"
},
{
"name": "CVE-2026-23026",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23026"
},
{
"name": "CVE-2026-52950",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52950"
},
{
"name": "CVE-2026-46044",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46044"
},
{
"name": "CVE-2026-23255",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23255"
},
{
"name": "CVE-2026-63970",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63970"
},
{
"name": "CVE-2026-23446",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23446"
},
{
"name": "CVE-2026-23128",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23128"
},
{
"name": "CVE-2026-46300",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46300"
},
{
"name": "CVE-2026-43361",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43361"
},
{
"name": "CVE-2026-46219",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46219"
},
{
"name": "CVE-2026-64173",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64173"
},
{
"name": "CVE-2026-53043",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53043"
},
{
"name": "CVE-2026-43075",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43075"
},
{
"name": "CVE-2026-43035",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43035"
},
{
"name": "CVE-2025-71190",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71190"
},
{
"name": "CVE-2026-63914",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63914"
},
{
"name": "CVE-2026-23140",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23140"
},
{
"name": "CVE-2026-46172",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46172"
},
{
"name": "CVE-2026-63935",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63935"
},
{
"name": "CVE-2026-31627",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31627"
},
{
"name": "CVE-2026-43441",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43441"
},
{
"name": "CVE-2025-71269",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71269"
},
{
"name": "CVE-2026-46311",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46311"
},
{
"name": "CVE-2026-31429",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31429"
},
{
"name": "CVE-2025-71203",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71203"
},
{
"name": "CVE-2024-56657",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56657"
},
{
"name": "CVE-2026-31665",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31665"
},
{
"name": "CVE-2026-46161",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46161"
},
{
"name": "CVE-2026-46026",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46026"
},
{
"name": "CVE-2026-53285",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53285"
},
{
"name": "CVE-2026-63901",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63901"
},
{
"name": "CVE-2026-23300",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23300"
},
{
"name": "CVE-2026-45941",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45941"
},
{
"name": "CVE-2026-23067",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23067"
},
{
"name": "CVE-2026-64184",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64184"
},
{
"name": "CVE-2026-23107",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23107"
},
{
"name": "CVE-2026-43261",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43261"
},
{
"name": "CVE-2026-23444",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23444"
},
{
"name": "CVE-2026-43304",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43304"
},
{
"name": "CVE-2026-31391",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31391"
},
{
"name": "CVE-2026-63951",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63951"
},
{
"name": "CVE-2026-22978",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22978"
},
{
"name": "CVE-2026-43378",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43378"
},
{
"name": "CVE-2026-52949",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52949"
},
{
"name": "CVE-2026-64115",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64115"
},
{
"name": "CVE-2026-45844",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45844"
},
{
"name": "CVE-2026-52985",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52985"
},
{
"name": "CVE-2026-46110",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46110"
},
{
"name": "CVE-2026-43384",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43384"
},
{
"name": "CVE-2026-43158",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43158"
},
{
"name": "CVE-2026-31672",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31672"
},
{
"name": "CVE-2026-23146",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23146"
},
{
"name": "CVE-2026-43501",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43501"
},
{
"name": "CVE-2026-64031",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64031"
},
{
"name": "CVE-2026-53059",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53059"
},
{
"name": "CVE-2026-23018",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23018"
},
{
"name": "CVE-2026-43093",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43093"
},
{
"name": "CVE-2026-45998",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45998"
},
{
"name": "CVE-2026-31780",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31780"
},
{
"name": "CVE-2026-43342",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43342"
},
{
"name": "CVE-2026-64164",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64164"
},
{
"name": "CVE-2026-63918",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63918"
},
{
"name": "CVE-2026-23037",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23037"
},
{
"name": "CVE-2026-23243",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23243"
},
{
"name": "CVE-2026-31675",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31675"
},
{
"name": "CVE-2026-46266",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46266"
},
{
"name": "CVE-2026-53024",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53024"
},
{
"name": "CVE-2026-31521",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31521"
},
{
"name": "CVE-2026-43059",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43059"
},
{
"name": "CVE-2026-53307",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53307"
},
{
"name": "CVE-2026-23363",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23363"
},
{
"name": "CVE-2026-31626",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31626"
},
{
"name": "CVE-2026-23106",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23106"
},
{
"name": "CVE-2026-23001",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23001"
},
{
"name": "CVE-2026-53087",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53087"
},
{
"name": "CVE-2026-43357",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43357"
},
{
"name": "CVE-2026-64160",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64160"
},
{
"name": "CVE-2026-63891",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63891"
},
{
"name": "CVE-2026-46111",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46111"
},
{
"name": "CVE-2026-31634",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31634"
},
{
"name": "CVE-2026-43061",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43061"
},
{
"name": "CVE-2026-46018",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46018"
},
{
"name": "CVE-2026-63945",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63945"
},
{
"name": "CVE-2026-31610",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31610"
},
{
"name": "CVE-2026-52932",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52932"
},
{
"name": "CVE-2025-71237",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71237"
},
{
"name": "CVE-2026-46008",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46008"
},
{
"name": "CVE-2026-31412",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31412"
},
{
"name": "CVE-2026-46240",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46240"
},
{
"name": "CVE-2026-31592",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31592"
},
{
"name": "CVE-2026-46104",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46104"
},
{
"name": "CVE-2026-53012",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53012"
},
{
"name": "CVE-2026-46179",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46179"
},
{
"name": "CVE-2026-43453",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43453"
},
{
"name": "CVE-2026-64096",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64096"
},
{
"name": "CVE-2026-53118",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53118"
},
{
"name": "CVE-2026-43032",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43032"
},
{
"name": "CVE-2026-43484",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43484"
},
{
"name": "CVE-2026-45954",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45954"
},
{
"name": "CVE-2026-45991",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45991"
},
{
"name": "CVE-2026-63985",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63985"
},
{
"name": "CVE-2026-63848",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63848"
},
{
"name": "CVE-2026-23025",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23025"
},
{
"name": "CVE-2026-64140",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64140"
},
{
"name": "CVE-2026-23362",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23362"
},
{
"name": "CVE-2026-23379",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23379"
},
{
"name": "CVE-2026-23118",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23118"
},
{
"name": "CVE-2026-31648",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31648"
},
{
"name": "CVE-2026-43076",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43076"
},
{
"name": "CVE-2026-45984",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45984"
},
{
"name": "CVE-2026-63968",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63968"
},
{
"name": "CVE-2026-64035",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64035"
},
{
"name": "CVE-2026-43427",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43427"
},
{
"name": "CVE-2026-43498",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43498"
},
{
"name": "CVE-2026-46291",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46291"
},
{
"name": "CVE-2022-50116",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50116"
},
{
"name": "CVE-2026-31421",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31421"
},
{
"name": "CVE-2026-31677",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31677"
},
{
"name": "CVE-2026-53069",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53069"
},
{
"name": "CVE-2026-23162",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23162"
},
{
"name": "CVE-2026-46215",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46215"
},
{
"name": "CVE-2026-63906",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63906"
},
{
"name": "CVE-2026-63877",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63877"
},
{
"name": "CVE-2026-53073",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53073"
},
{
"name": "CVE-2023-53545",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53545"
},
{
"name": "CVE-2026-46312",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46312"
},
{
"name": "CVE-2026-43365",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43365"
},
{
"name": "CVE-2022-50552",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50552"
},
{
"name": "CVE-2026-23381",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23381"
},
{
"name": "CVE-2026-31518",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31518"
},
{
"name": "CVE-2026-43296",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43296"
},
{
"name": "CVE-2026-31712",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31712"
},
{
"name": "CVE-2026-46046",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46046"
},
{
"name": "CVE-2026-52944",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52944"
},
{
"name": "CVE-2025-68256",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68256"
},
{
"name": "CVE-2026-43086",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43086"
},
{
"name": "CVE-2026-63904",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63904"
},
{
"name": "CVE-2026-46145",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46145"
},
{
"name": "CVE-2026-53031",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53031"
},
{
"name": "CVE-2026-31470",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31470"
},
{
"name": "CVE-2026-23221",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23221"
},
{
"name": "CVE-2026-31686",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31686"
},
{
"name": "CVE-2026-31730",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31730"
},
{
"name": "CVE-2026-31707",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31707"
},
{
"name": "CVE-2026-23151",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23151"
},
{
"name": "CVE-2026-31660",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31660"
},
{
"name": "CVE-2026-46156",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46156"
},
{
"name": "CVE-2026-23392",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23392"
},
{
"name": "CVE-2026-23245",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23245"
},
{
"name": "CVE-2026-64142",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64142"
},
{
"name": "CVE-2026-45916",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45916"
},
{
"name": "CVE-2026-64139",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64139"
},
{
"name": "CVE-2026-46294",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46294"
},
{
"name": "CVE-2026-31728",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31728"
},
{
"name": "CVE-2026-23008",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23008"
},
{
"name": "CVE-2026-23152",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23152"
},
{
"name": "CVE-2026-53125",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53125"
},
{
"name": "CVE-2026-53107",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53107"
},
{
"name": "CVE-2026-46125",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46125"
},
{
"name": "CVE-2026-46067",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46067"
},
{
"name": "CVE-2026-43349",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43349"
},
{
"name": "CVE-2026-46152",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46152"
},
{
"name": "CVE-2026-22982",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22982"
},
{
"name": "CVE-2026-31403",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31403"
},
{
"name": "CVE-2026-46290",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46290"
},
{
"name": "CVE-2026-52980",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52980"
},
{
"name": "CVE-2026-64117",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64117"
},
{
"name": "CVE-2026-64079",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64079"
},
{
"name": "CVE-2026-64084",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64084"
},
{
"name": "CVE-2026-64014",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64014"
},
{
"name": "CVE-2026-31400",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31400"
},
{
"name": "CVE-2026-31512",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31512"
},
{
"name": "CVE-2026-46036",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46036"
},
{
"name": "CVE-2026-43124",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43124"
},
{
"name": "CVE-2026-64001",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64001"
},
{
"name": "CVE-2026-43094",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43094"
},
{
"name": "CVE-2026-64036",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64036"
},
{
"name": "CVE-2026-46279",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46279"
},
{
"name": "CVE-2026-43395",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43395"
},
{
"name": "CVE-2026-23330",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23330"
},
{
"name": "CVE-2026-53293",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53293"
},
{
"name": "CVE-2026-46135",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46135"
},
{
"name": "CVE-2026-43141",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43141"
},
{
"name": "CVE-2026-31726",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31726"
},
{
"name": "CVE-2026-45990",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45990"
},
{
"name": "CVE-2026-43225",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43225"
},
{
"name": "CVE-2026-43370",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43370"
},
{
"name": "CVE-2026-43409",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43409"
},
{
"name": "CVE-2026-31773",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31773"
},
{
"name": "CVE-2026-43056",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43056"
},
{
"name": "CVE-2026-43134",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43134"
},
{
"name": "CVE-2026-64108",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64108"
},
{
"name": "CVE-2026-63937",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63937"
},
{
"name": "CVE-2023-52682",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52682"
},
{
"name": "CVE-2026-46075",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46075"
},
{
"name": "CVE-2026-23142",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23142"
},
{
"name": "CVE-2025-71150",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71150"
},
{
"name": "CVE-2026-23364",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23364"
},
{
"name": "CVE-2026-46167",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46167"
},
{
"name": "CVE-2026-43162",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43162"
},
{
"name": "CVE-2026-31607",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31607"
},
{
"name": "CVE-2026-23242",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23242"
},
{
"name": "CVE-2026-64119",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64119"
},
{
"name": "CVE-2026-43015",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43015"
},
{
"name": "CVE-2026-46054",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46054"
},
{
"name": "CVE-2026-31509",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31509"
},
{
"name": "CVE-2025-71292",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71292"
},
{
"name": "CVE-2026-43066",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43066"
},
{
"name": "CVE-2026-46139",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46139"
},
{
"name": "CVE-2026-64175",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64175"
},
{
"name": "CVE-2026-43242",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43242"
},
{
"name": "CVE-2026-23237",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23237"
},
{
"name": "CVE-2026-31679",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31679"
},
{
"name": "CVE-2026-46282",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46282"
},
{
"name": "CVE-2026-64066",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64066"
},
{
"name": "CVE-2026-46191",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46191"
},
{
"name": "CVE-2026-43120",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43120"
},
{
"name": "CVE-2026-45970",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45970"
},
{
"name": "CVE-2025-71192",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71192"
},
{
"name": "CVE-2026-47327",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47327"
},
{
"name": "CVE-2023-53596",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53596"
},
{
"name": "CVE-2026-52978",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52978"
},
{
"name": "CVE-2026-43265",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43265"
},
{
"name": "CVE-2026-53310",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53310"
},
{
"name": "CVE-2026-64095",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64095"
},
{
"name": "CVE-2026-63887",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63887"
},
{
"name": "CVE-2026-43469",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43469"
},
{
"name": "CVE-2026-31716",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31716"
},
{
"name": "CVE-2025-40135",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40135"
},
{
"name": "CVE-2026-43085",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43085"
},
{
"name": "CVE-2026-23121",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23121"
},
{
"name": "CVE-2026-31637",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31637"
},
{
"name": "CVE-2026-31779",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31779"
},
{
"name": "CVE-2026-23051",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23051"
},
{
"name": "CVE-2026-31612",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31612"
},
{
"name": "CVE-2026-64062",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64062"
},
{
"name": "CVE-2026-23428",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23428"
},
{
"name": "CVE-2026-53025",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53025"
},
{
"name": "CVE-2026-64113",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64113"
},
{
"name": "CVE-2026-43330",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43330"
},
{
"name": "CVE-2026-53008",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53008"
},
{
"name": "CVE-2026-31590",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31590"
},
{
"name": "CVE-2026-46192",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46192"
},
{
"name": "CVE-2026-46073",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46073"
},
{
"name": "CVE-2026-63972",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63972"
},
{
"name": "CVE-2026-23034",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23034"
},
{
"name": "CVE-2026-64103",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64103"
},
{
"name": "CVE-2026-64078",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64078"
},
{
"name": "CVE-2026-31621",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31621"
},
{
"name": "CVE-2026-46105",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46105"
},
{
"name": "CVE-2026-22993",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22993"
},
{
"name": "CVE-2026-45855",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45855"
},
{
"name": "CVE-2026-46274",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46274"
},
{
"name": "CVE-2026-63849",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63849"
},
{
"name": "CVE-2026-23361",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23361"
},
{
"name": "CVE-2025-38192",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38192"
},
{
"name": "CVE-2026-43020",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43020"
},
{
"name": "CVE-2026-31417",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31417"
},
{
"name": "CVE-2025-71236",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71236"
},
{
"name": "CVE-2026-43041",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43041"
},
{
"name": "CVE-2026-31761",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31761"
},
{
"name": "CVE-2026-31767",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31767"
},
{
"name": "CVE-2026-45943",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45943"
},
{
"name": "CVE-2026-31466",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31466"
},
{
"name": "CVE-2026-47326",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47326"
},
{
"name": "CVE-2026-63900",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63900"
},
{
"name": "CVE-2026-43313",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43313"
},
{
"name": "CVE-2026-64136",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64136"
},
{
"name": "CVE-2026-63953",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63953"
},
{
"name": "CVE-2026-31527",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31527"
},
{
"name": "CVE-2026-53042",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53042"
},
{
"name": "CVE-2026-53289",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53289"
},
{
"name": "CVE-2026-31604",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31604"
},
{
"name": "CVE-2026-23448",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23448"
},
{
"name": "CVE-2026-53304",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53304"
},
{
"name": "CVE-2026-64174",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64174"
},
{
"name": "CVE-2026-64000",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64000"
},
{
"name": "CVE-2025-54518",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-54518"
},
{
"name": "CVE-2026-64158",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64158"
},
{
"name": "CVE-2026-43111",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43111"
},
{
"name": "CVE-2024-56584",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56584"
},
{
"name": "CVE-2026-63967",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63967"
},
{
"name": "CVE-2026-63897",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63897"
},
{
"name": "CVE-2026-52936",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52936"
},
{
"name": "CVE-2026-53376",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53376"
},
{
"name": "CVE-2026-23235",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23235"
},
{
"name": "CVE-2026-22985",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22985"
},
{
"name": "CVE-2025-71152",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71152"
},
{
"name": "CVE-2026-46313",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46313"
},
{
"name": "CVE-2026-23144",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23144"
},
{
"name": "CVE-2026-23087",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23087"
},
{
"name": "CVE-2026-31414",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31414"
},
{
"name": "CVE-2026-53005",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53005"
},
{
"name": "CVE-2026-46309",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46309"
},
{
"name": "CVE-2026-64034",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64034"
},
{
"name": "CVE-2026-46244",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46244"
},
{
"name": "CVE-2026-31584",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31584"
},
{
"name": "CVE-2026-45958",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45958"
},
{
"name": "CVE-2026-53298",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53298"
},
{
"name": "CVE-2025-71185",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71185"
},
{
"name": "CVE-2026-43257",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43257"
},
{
"name": "CVE-2026-31778",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31778"
},
{
"name": "CVE-2026-46281",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46281"
},
{
"name": "CVE-2026-23096",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23096"
},
{
"name": "CVE-2026-53372",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53372"
},
{
"name": "CVE-2026-64093",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64093"
},
{
"name": "CVE-2026-43291",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43291"
},
{
"name": "CVE-2026-53039",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53039"
},
{
"name": "CVE-2026-43180",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43180"
},
{
"name": "CVE-2026-31557",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31557"
},
{
"name": "CVE-2026-31717",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31717"
},
{
"name": "CVE-2026-31426",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31426"
},
{
"name": "CVE-2026-43196",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43196"
},
{
"name": "CVE-2026-23325",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23325"
},
{
"name": "CVE-2026-53290",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53290"
},
{
"name": "CVE-2026-53080",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53080"
},
{
"name": "CVE-2026-23044",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23044"
},
{
"name": "CVE-2026-43490",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43490"
},
{
"name": "CVE-2026-53316",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53316"
},
{
"name": "CVE-2026-45968",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45968"
},
{
"name": "CVE-2026-53004",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53004"
},
{
"name": "CVE-2022-49961",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49961"
},
{
"name": "CVE-2026-43040",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43040"
},
{
"name": "CVE-2026-43152",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43152"
},
{
"name": "CVE-2026-52912",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52912"
},
{
"name": "CVE-2026-23440",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23440"
},
{
"name": "CVE-2026-63955",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63955"
},
{
"name": "CVE-2026-43287",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43287"
},
{
"name": "CVE-2026-46129",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46129"
},
{
"name": "CVE-2026-31552",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31552"
},
{
"name": "CVE-2026-64101",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64101"
},
{
"name": "CVE-2026-23284",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23284"
},
{
"name": "CVE-2026-52976",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52976"
},
{
"name": "CVE-2026-23164",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23164"
},
{
"name": "CVE-2026-43133",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43133"
},
{
"name": "CVE-2026-46292",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46292"
},
{
"name": "CVE-2026-46035",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46035"
},
{
"name": "CVE-2026-46006",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46006"
},
{
"name": "CVE-2026-43428",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43428"
},
{
"name": "CVE-2026-31715",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31715"
},
{
"name": "CVE-2026-52998",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52998"
},
{
"name": "CVE-2026-53011",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53011"
},
{
"name": "CVE-2026-63991",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63991"
},
{
"name": "CVE-2026-31488",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31488"
},
{
"name": "CVE-2026-63982",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63982"
},
{
"name": "CVE-2026-23278",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23278"
},
{
"name": "CVE-2026-52920",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52920"
},
{
"name": "CVE-2026-31532",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31532"
},
{
"name": "CVE-2026-23124",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23124"
},
{
"name": "CVE-2026-53001",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53001"
},
{
"name": "CVE-2026-23397",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23397"
},
{
"name": "CVE-2026-43206",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43206"
},
{
"name": "CVE-2026-23452",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23452"
},
{
"name": "CVE-2026-43273",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43273"
},
{
"name": "CVE-2026-63960",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63960"
},
{
"name": "CVE-2026-23002",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23002"
},
{
"name": "CVE-2026-23474",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23474"
},
{
"name": "CVE-2025-71160",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71160"
},
{
"name": "CVE-2025-71232",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71232"
},
{
"name": "CVE-2026-52911",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52911"
},
{
"name": "CVE-2026-43190",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43190"
},
{
"name": "CVE-2026-43065",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43065"
},
{
"name": "CVE-2026-31434",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31434"
},
{
"name": "CVE-2026-45885",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45885"
},
{
"name": "CVE-2026-53295",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53295"
},
{
"name": "CVE-2026-43182",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43182"
},
{
"name": "CVE-2025-71162",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71162"
},
{
"name": "CVE-2026-43226",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43226"
},
{
"name": "CVE-2026-23343",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23343"
},
{
"name": "CVE-2026-31430",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31430"
},
{
"name": "CVE-2026-23075",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23075"
},
{
"name": "CVE-2026-23077",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23077"
},
{
"name": "CVE-2026-23120",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23120"
},
{
"name": "CVE-2026-63963",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63963"
},
{
"name": "CVE-2026-23336",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23336"
},
{
"name": "CVE-2026-63890",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63890"
},
{
"name": "CVE-2026-45843",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45843"
},
{
"name": "CVE-2026-22996",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22996"
},
{
"name": "CVE-2026-46115",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46115"
},
{
"name": "CVE-2026-46016",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46016"
},
{
"name": "CVE-2026-63997",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63997"
},
{
"name": "CVE-2026-43355",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43355"
},
{
"name": "CVE-2026-47337",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47337"
},
{
"name": "CVE-2026-46148",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46148"
},
{
"name": "CVE-2026-46015",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46015"
},
{
"name": "CVE-2026-23168",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23168"
},
{
"name": "CVE-2026-46136",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46136"
},
{
"name": "CVE-2026-53357",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53357"
},
{
"name": "CVE-2026-46324",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46324"
},
{
"name": "CVE-2026-53052",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53052"
},
{
"name": "CVE-2026-31497",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31497"
},
{
"name": "CVE-2026-43451",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43451"
},
{
"name": "CVE-2026-53318",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53318"
},
{
"name": "CVE-2026-64070",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64070"
},
{
"name": "CVE-2026-46316",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46316"
},
{
"name": "CVE-2026-23105",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23105"
},
{
"name": "CVE-2026-31682",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31682"
},
{
"name": "CVE-2026-64126",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64126"
},
{
"name": "CVE-2026-53280",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53280"
},
{
"name": "CVE-2026-22976",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22976"
},
{
"name": "CVE-2026-46068",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46068"
},
{
"name": "CVE-2026-63977",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63977"
},
{
"name": "CVE-2026-43456",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43456"
},
{
"name": "CVE-2026-43406",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43406"
},
{
"name": "CVE-2026-31570",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31570"
},
{
"name": "CVE-2026-23289",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23289"
},
{
"name": "CVE-2026-31755",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31755"
},
{
"name": "CVE-2026-64168",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64168"
},
{
"name": "CVE-2026-46056",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46056"
},
{
"name": "CVE-2026-23292",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23292"
},
{
"name": "CVE-2026-53108",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53108"
},
{
"name": "CVE-2026-46230",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46230"
},
{
"name": "CVE-2026-23141",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23141"
},
{
"name": "CVE-2026-31451",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31451"
},
{
"name": "CVE-2026-23065",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23065"
},
{
"name": "CVE-2026-64161",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64161"
},
{
"name": "CVE-2026-63881",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63881"
},
{
"name": "CVE-2026-52964",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52964"
},
{
"name": "CVE-2026-46138",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46138"
},
{
"name": "CVE-2025-21739",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21739"
},
{
"name": "CVE-2026-23277",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23277"
},
{
"name": "CVE-2026-31399",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31399"
},
{
"name": "CVE-2026-63969",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63969"
},
{
"name": "CVE-2026-53089",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53089"
},
{
"name": "CVE-2026-22986",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22986"
},
{
"name": "CVE-2026-31709",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31709"
},
{
"name": "CVE-2026-31489",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31489"
},
{
"name": "CVE-2026-31441",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31441"
},
{
"name": "CVE-2026-23086",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23086"
},
{
"name": "CVE-2026-53003",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53003"
},
{
"name": "CVE-2026-46225",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46225"
},
{
"name": "CVE-2026-45964",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45964"
},
{
"name": "CVE-2026-52904",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52904"
},
{
"name": "CVE-2026-64121",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64121"
},
{
"name": "CVE-2026-63939",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63939"
},
{
"name": "CVE-2026-46004",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46004"
},
{
"name": "CVE-2026-63962",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63962"
},
{
"name": "CVE-2026-46086",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46086"
},
{
"name": "CVE-2026-64053",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64053"
},
{
"name": "CVE-2026-63936",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63936"
},
{
"name": "CVE-2026-43343",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43343"
},
{
"name": "CVE-2026-46094",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46094"
},
{
"name": "CVE-2026-63927",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63927"
},
{
"name": "CVE-2026-43289",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43289"
},
{
"name": "CVE-2026-46314",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46314"
},
{
"name": "CVE-2026-31444",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31444"
},
{
"name": "CVE-2026-43187",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43187"
},
{
"name": "CVE-2026-46149",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46149"
},
{
"name": "CVE-2026-23455",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23455"
},
{
"name": "CVE-2026-53017",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53017"
},
{
"name": "CVE-2025-38006",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38006"
},
{
"name": "CVE-2026-64144",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64144"
},
{
"name": "CVE-2026-46208",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46208"
},
{
"name": "CVE-2026-63971",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63971"
},
{
"name": "CVE-2026-53174",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53174"
},
{
"name": "CVE-2026-64086",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64086"
},
{
"name": "CVE-2026-43081",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43081"
},
{
"name": "CVE-2026-43341",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43341"
},
{
"name": "CVE-2026-63983",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63983"
},
{
"name": "CVE-2026-45936",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45936"
},
{
"name": "CVE-2026-46205",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46205"
},
{
"name": "CVE-2026-64029",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64029"
},
{
"name": "CVE-2026-53016",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53016"
},
{
"name": "CVE-2026-45978",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45978"
},
{
"name": "CVE-2026-46218",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46218"
},
{
"name": "CVE-2026-43159",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43159"
},
{
"name": "CVE-2026-23335",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23335"
},
{
"name": "CVE-2026-52986",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52986"
},
{
"name": "CVE-2026-31551",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31551"
},
{
"name": "CVE-2026-63919",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63919"
},
{
"name": "CVE-2026-53077",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53077"
},
{
"name": "CVE-2026-31495",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31495"
},
{
"name": "CVE-2026-46132",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46132"
},
{
"name": "CVE-2026-64111",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64111"
},
{
"name": "CVE-2026-23156",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23156"
},
{
"name": "CVE-2026-46060",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46060"
},
{
"name": "CVE-2026-23158",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23158"
},
{
"name": "CVE-2025-71193",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71193"
},
{
"name": "CVE-2026-23095",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23095"
},
{
"name": "CVE-2026-23369",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23369"
},
{
"name": "CVE-2026-46160",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46160"
},
{
"name": "CVE-2026-46177",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46177"
},
{
"name": "CVE-2026-46131",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46131"
},
{
"name": "CVE-2026-43110",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43110"
},
{
"name": "CVE-2026-46084",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46084"
},
{
"name": "CVE-2026-46079",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46079"
},
{
"name": "CVE-2026-64149",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64149"
},
{
"name": "CVE-2025-71163",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71163"
},
{
"name": "CVE-2026-64075",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64075"
},
{
"name": "CVE-2026-23062",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23062"
},
{
"name": "CVE-2026-31507",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31507"
},
{
"name": "CVE-2026-63876",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63876"
},
{
"name": "CVE-2026-53306",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53306"
},
{
"name": "CVE-2026-23266",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23266"
},
{
"name": "CVE-2026-23389",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23389"
},
{
"name": "CVE-2026-43149",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43149"
},
{
"name": "CVE-2026-53129",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53129"
},
{
"name": "CVE-2026-53277",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53277"
},
{
"name": "CVE-2026-63998",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63998"
},
{
"name": "CVE-2026-23160",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23160"
},
{
"name": "CVE-2026-31762",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31762"
},
{
"name": "CVE-2026-46333",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46333"
},
{
"name": "CVE-2026-64137",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64137"
},
{
"name": "CVE-2026-43236",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43236"
},
{
"name": "CVE-2026-43071",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43071"
},
{
"name": "CVE-2026-31788",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31788"
},
{
"name": "CVE-2026-63959",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63959"
},
{
"name": "CVE-2026-53115",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53115"
},
{
"name": "CVE-2026-31411",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31411"
},
{
"name": "CVE-2026-31428",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31428"
},
{
"name": "CVE-2026-64043",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64043"
},
{
"name": "CVE-2026-53308",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53308"
},
{
"name": "CVE-2026-23420",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23420"
},
{
"name": "CVE-2026-23388",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23388"
},
{
"name": "CVE-2026-53045",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53045"
},
{
"name": "CVE-2026-46085",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46085"
},
{
"name": "CVE-2025-39748",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39748"
},
{
"name": "CVE-2026-43098",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43098"
},
{
"name": "CVE-2026-22984",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22984"
},
{
"name": "CVE-2026-63862",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63862"
},
{
"name": "CVE-2026-23449",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23449"
},
{
"name": "CVE-2026-63954",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63954"
},
{
"name": "CVE-2026-53282",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53282"
},
{
"name": "CVE-2026-63840",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63840"
},
{
"name": "CVE-2026-43277",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43277"
},
{
"name": "CVE-2026-46306",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46306"
},
{
"name": "CVE-2026-43386",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43386"
},
{
"name": "CVE-2026-53085",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53085"
},
{
"name": "CVE-2026-64049",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64049"
},
{
"name": "CVE-2026-43245",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43245"
},
{
"name": "CVE-2026-46210",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46210"
},
{
"name": "CVE-2026-47333",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47333"
},
{
"name": "CVE-2026-64183",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64183"
},
{
"name": "CVE-2026-46029",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46029"
},
{
"name": "CVE-2025-71266",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71266"
},
{
"name": "CVE-2026-64120",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64120"
},
{
"name": "CVE-2026-31492",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31492"
},
{
"name": "CVE-2026-45898",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45898"
},
{
"name": "CVE-2026-43089",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43089"
},
{
"name": "CVE-2026-43037",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43037"
},
{
"name": "CVE-2026-53033",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53033"
},
{
"name": "CVE-2026-46021",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46021"
},
{
"name": "CVE-2026-23070",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23070"
},
{
"name": "CVE-2026-46162",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46162"
},
{
"name": "CVE-2026-23241",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23241"
},
{
"name": "CVE-2026-31596",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31596"
},
{
"name": "CVE-2026-43266",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43266"
},
{
"name": "CVE-2026-53319",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53319"
},
{
"name": "CVE-2026-23033",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23033"
},
{
"name": "CVE-2026-31676",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31676"
},
{
"name": "CVE-2026-52959",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52959"
},
{
"name": "CVE-2026-53120",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53120"
},
{
"name": "CVE-2026-43318",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43318"
},
{
"name": "CVE-2026-43084",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43084"
},
{
"name": "CVE-2026-22977",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22977"
},
{
"name": "CVE-2026-64134",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64134"
},
{
"name": "CVE-2026-23145",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23145"
},
{
"name": "CVE-2026-53026",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53026"
},
{
"name": "CVE-2026-45942",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45942"
},
{
"name": "CVE-2026-43186",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43186"
},
{
"name": "CVE-2026-43112",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43112"
},
{
"name": "CVE-2026-43083",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43083"
},
{
"name": "CVE-2026-64005",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64005"
},
{
"name": "CVE-2026-23442",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23442"
},
{
"name": "CVE-2026-31476",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31476"
},
{
"name": "CVE-2026-31603",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31603"
},
{
"name": "CVE-2026-23104",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23104"
},
{
"name": "CVE-2026-46107",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46107"
},
{
"name": "CVE-2026-46047",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46047"
},
{
"name": "CVE-2026-46273",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46273"
},
{
"name": "CVE-2026-23458",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23458"
},
{
"name": "CVE-2026-23003",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23003"
},
{
"name": "CVE-2026-63981",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63981"
},
{
"name": "CVE-2026-43502",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43502"
},
{
"name": "CVE-2026-23313",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23313"
},
{
"name": "CVE-2026-31649",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31649"
},
{
"name": "CVE-2026-53379",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53379"
},
{
"name": "CVE-2026-31719",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31719"
},
{
"name": "CVE-2026-31674",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31674"
},
{
"name": "CVE-2026-31393",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31393"
},
{
"name": "CVE-2026-43420",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43420"
},
{
"name": "CVE-2026-23310",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23310"
},
{
"name": "CVE-2026-23076",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23076"
},
{
"name": "CVE-2026-53056",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53056"
},
{
"name": "CVE-2026-45994",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45994"
},
{
"name": "CVE-2026-63946",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63946"
},
{
"name": "CVE-2026-63903",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63903"
},
{
"name": "CVE-2026-31577",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31577"
},
{
"name": "CVE-2026-43233",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43233"
},
{
"name": "CVE-2026-43027",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43027"
},
{
"name": "CVE-2026-46267",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46267"
},
{
"name": "CVE-2026-46249",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46249"
},
{
"name": "CVE-2026-63922",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63922"
},
{
"name": "CVE-2026-63949",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63949"
},
{
"name": "CVE-2026-45904",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45904"
},
{
"name": "CVE-2025-68206",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68206"
},
{
"name": "CVE-2026-46163",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46163"
},
{
"name": "CVE-2026-46202",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46202"
},
{
"name": "CVE-2025-71158",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71158"
},
{
"name": "CVE-2022-49803",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49803"
},
{
"name": "CVE-2026-46270",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46270"
},
{
"name": "CVE-2026-45858",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45858"
},
{
"name": "CVE-2026-31576",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31576"
},
{
"name": "CVE-2026-46164",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46164"
},
{
"name": "CVE-2026-46235",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46235"
},
{
"name": "CVE-2026-63907",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63907"
},
{
"name": "CVE-2026-64032",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64032"
},
{
"name": "CVE-2026-45838",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45838"
},
{
"name": "CVE-2026-31506",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31506"
},
{
"name": "CVE-2026-31722",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31722"
},
{
"name": "CVE-2026-64182",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64182"
},
{
"name": "CVE-2026-43295",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43295"
},
{
"name": "CVE-2026-23339",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23339"
},
{
"name": "CVE-2026-23171",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23171"
},
{
"name": "CVE-2026-23010",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23010"
},
{
"name": "CVE-2026-43148",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43148"
},
{
"name": "CVE-2026-63999",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63999"
},
{
"name": "CVE-2026-23272",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23272"
},
{
"name": "CVE-2026-43109",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43109"
},
{
"name": "CVE-2026-45935",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45935"
},
{
"name": "CVE-2026-53023",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53023"
},
{
"name": "CVE-2026-31433",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31433"
},
{
"name": "CVE-2026-53098",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53098"
},
{
"name": "CVE-2026-31458",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31458"
},
{
"name": "CVE-2026-43497",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43497"
},
{
"name": "CVE-2026-53063",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53063"
},
{
"name": "CVE-2026-43312",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43312"
},
{
"name": "CVE-2026-64024",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64024"
},
{
"name": "CVE-2026-45924",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45924"
},
{
"name": "CVE-2026-63944",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63944"
},
{
"name": "CVE-2026-46077",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46077"
},
{
"name": "CVE-2026-31575",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31575"
},
{
"name": "CVE-2026-45891",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45891"
},
{
"name": "CVE-2026-64054",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64054"
},
{
"name": "CVE-2026-64019",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64019"
},
{
"name": "CVE-2026-64056",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64056"
},
{
"name": "CVE-2026-52962",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52962"
},
{
"name": "CVE-2026-63860",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63860"
},
{
"name": "CVE-2026-52953",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52953"
},
{
"name": "CVE-2026-53093",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53093"
},
{
"name": "CVE-2026-31589",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31589"
},
{
"name": "CVE-2026-63899",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63899"
},
{
"name": "CVE-2026-46200",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46200"
},
{
"name": "CVE-2026-23084",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23084"
},
{
"name": "CVE-2026-22979",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22979"
},
{
"name": "CVE-2026-23321",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23321"
},
{
"name": "CVE-2026-64033",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64033"
},
{
"name": "CVE-2026-63893",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63893"
},
{
"name": "CVE-2026-64124",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64124"
},
{
"name": "CVE-2026-23460",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23460"
},
{
"name": "CVE-2026-43114",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43114"
},
{
"name": "CVE-2026-46222",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46222"
},
{
"name": "CVE-2026-43412",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43412"
},
{
"name": "CVE-2026-31702",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31702"
},
{
"name": "CVE-2026-46187",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46187"
},
{
"name": "CVE-2026-43281",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43281"
},
{
"name": "CVE-2026-23011",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23011"
},
{
"name": "CVE-2026-23015",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23015"
},
{
"name": "CVE-2026-31678",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31678"
},
{
"name": "CVE-2026-31587",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31587"
},
{
"name": "CVE-2026-64030",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64030"
},
{
"name": "CVE-2025-71161",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71161"
},
{
"name": "CVE-2026-46168",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46168"
},
{
"name": "CVE-2026-53075",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53075"
},
{
"name": "CVE-2026-31540",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31540"
},
{
"name": "CVE-2026-64072",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64072"
},
{
"name": "CVE-2026-45986",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45986"
},
{
"name": "CVE-2026-46175",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46175"
},
{
"name": "CVE-2026-53323",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53323"
},
{
"name": "CVE-2026-43338",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43338"
},
{
"name": "CVE-2026-53030",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53030"
},
{
"name": "CVE-2026-23395",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23395"
},
{
"name": "CVE-2026-52906",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52906"
},
{
"name": "CVE-2026-45837",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45837"
},
{
"name": "CVE-2026-45987",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45987"
},
{
"name": "CVE-2026-31708",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31708"
},
{
"name": "CVE-2026-31651",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31651"
},
{
"name": "CVE-2026-31413",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31413"
},
{
"name": "CVE-2026-43471",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43471"
},
{
"name": "CVE-2026-23110",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23110"
},
{
"name": "CVE-2026-64015",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64015"
},
{
"name": "CVE-2026-46093",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46093"
},
{
"name": "CVE-2026-64110",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64110"
},
{
"name": "CVE-2026-46299",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46299"
},
{
"name": "CVE-2026-63851",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63851"
},
{
"name": "CVE-2026-63934",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63934"
},
{
"name": "CVE-2026-23100",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23100"
},
{
"name": "CVE-2026-31503",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31503"
},
{
"name": "CVE-2026-53303",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53303"
},
{
"name": "CVE-2026-46239",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46239"
},
{
"name": "CVE-2026-53299",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53299"
},
{
"name": "CVE-2026-53055",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53055"
},
{
"name": "CVE-2025-21863",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21863"
},
{
"name": "CVE-2026-31657",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31657"
},
{
"name": "CVE-2026-64123",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64123"
},
{
"name": "CVE-2026-43125",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43125"
},
{
"name": "CVE-2026-53019",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53019"
},
{
"name": "CVE-2026-46201",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46201"
},
{
"name": "CVE-2026-43359",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43359"
},
{
"name": "CVE-2026-46025",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46025"
},
{
"name": "CVE-2026-43302",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43302"
},
{
"name": "CVE-2026-31747",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31747"
},
{
"name": "CVE-2026-31455",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31455"
},
{
"name": "CVE-2026-64156",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64156"
},
{
"name": "CVE-2026-43316",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43316"
},
{
"name": "CVE-2026-52991",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52991"
},
{
"name": "CVE-2026-43016",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43016"
},
{
"name": "CVE-2026-53322",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53322"
},
{
"name": "CVE-2026-64122",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64122"
},
{
"name": "CVE-2026-43129",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43129"
},
{
"name": "CVE-2026-31624",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31624"
},
{
"name": "CVE-2026-53100",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53100"
},
{
"name": "CVE-2026-46050",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46050"
},
{
"name": "CVE-2026-46221",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46221"
},
{
"name": "CVE-2026-23306",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23306"
},
{
"name": "CVE-2026-46003",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46003"
},
{
"name": "CVE-2025-71233",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71233"
},
{
"name": "CVE-2026-43340",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43340"
},
{
"name": "CVE-2026-53358",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53358"
},
{
"name": "CVE-2026-23148",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23148"
},
{
"name": "CVE-2026-63905",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63905"
},
{
"name": "CVE-2026-46009",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46009"
},
{
"name": "CVE-2026-31585",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31585"
},
{
"name": "CVE-2026-63973",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63973"
},
{
"name": "CVE-2025-71288",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71288"
},
{
"name": "CVE-2026-63857",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63857"
},
{
"name": "CVE-2026-31474",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31474"
},
{
"name": "CVE-2026-46144",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46144"
},
{
"name": "CVE-2026-23374",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23374"
},
{
"name": "CVE-2025-71197",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71197"
},
{
"name": "CVE-2026-23378",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23378"
},
{
"name": "CVE-2026-63837",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63837"
},
{
"name": "CVE-2026-63895",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63895"
},
{
"name": "CVE-2026-31646",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31646"
},
{
"name": "CVE-2026-31519",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31519"
},
{
"name": "CVE-2026-64157",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64157"
},
{
"name": "CVE-2026-23031",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23031"
},
{
"name": "CVE-2026-31729",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31729"
},
{
"name": "CVE-2026-53078",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53078"
},
{
"name": "CVE-2026-52907",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52907"
},
{
"name": "CVE-2025-37786",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37786"
},
{
"name": "CVE-2026-23102",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23102"
},
{
"name": "CVE-2026-52928",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52928"
},
{
"name": "CVE-2026-23464",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23464"
},
{
"name": "CVE-2026-22998",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22998"
},
{
"name": "CVE-2026-23050",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23050"
},
{
"name": "CVE-2026-64138",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64138"
},
{
"name": "CVE-2026-31439",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31439"
},
{
"name": "CVE-2026-23161",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23161"
},
{
"name": "CVE-2026-64153",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64153"
},
{
"name": "CVE-2026-23291",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23291"
},
{
"name": "CVE-2026-53037",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53037"
},
{
"name": "CVE-2026-63986",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63986"
},
{
"name": "CVE-2026-46305",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46305"
},
{
"name": "CVE-2026-53072",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53072"
},
{
"name": "CVE-2026-53284",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53284"
},
{
"name": "CVE-2026-52921",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52921"
},
{
"name": "CVE-2026-46023",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46023"
},
{
"name": "CVE-2026-53281",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53281"
},
{
"name": "CVE-2026-53068",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53068"
},
{
"name": "CVE-2026-46096",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46096"
},
{
"name": "CVE-2026-64012",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64012"
},
{
"name": "CVE-2026-52967",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52967"
},
{
"name": "CVE-2026-23413",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23413"
},
{
"name": "CVE-2026-46304",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46304"
},
{
"name": "CVE-2026-64118",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64118"
},
{
"name": "CVE-2026-46166",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46166"
},
{
"name": "CVE-2026-43156",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43156"
},
{
"name": "CVE-2026-64058",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64058"
},
{
"name": "CVE-2026-43397",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43397"
},
{
"name": "CVE-2026-31706",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31706"
},
{
"name": "CVE-2026-31436",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31436"
},
{
"name": "CVE-2025-68239",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68239"
},
{
"name": "CVE-2026-43194",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43194"
},
{
"name": "CVE-2026-23382",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23382"
},
{
"name": "CVE-2026-64037",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64037"
},
{
"name": "CVE-2026-63912",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63912"
},
{
"name": "CVE-2026-43473",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43473"
},
{
"name": "CVE-2026-52983",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52983"
},
{
"name": "CVE-2026-46216",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46216"
},
{
"name": "CVE-2026-43091",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43091"
},
{
"name": "CVE-2026-43230",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43230"
},
{
"name": "CVE-2026-63942",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63942"
},
{
"name": "CVE-2026-64064",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64064"
},
{
"name": "CVE-2026-64116",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64116"
},
{
"name": "CVE-2026-43209",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43209"
},
{
"name": "CVE-2026-43082",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43082"
},
{
"name": "CVE-2026-31446",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31446"
},
{
"name": "CVE-2026-46275",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46275"
},
{
"name": "CVE-2026-23024",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23024"
},
{
"name": "CVE-2026-23113",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23113"
},
{
"name": "CVE-2026-63889",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63889"
},
{
"name": "CVE-2026-46126",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46126"
},
{
"name": "CVE-2026-46193",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46193"
},
{
"name": "CVE-2026-45902",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45902"
},
{
"name": "CVE-2026-43107",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43107"
},
{
"name": "CVE-2026-53057",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53057"
},
{
"name": "CVE-2026-23157",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23157"
},
{
"name": "CVE-2026-52974",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52974"
},
{
"name": "CVE-2026-53127",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53127"
},
{
"name": "CVE-2026-31464",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31464"
},
{
"name": "CVE-2026-63941",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63941"
},
{
"name": "CVE-2026-46033",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46033"
},
{
"name": "CVE-2026-46143",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46143"
},
{
"name": "CVE-2026-52923",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52923"
},
{
"name": "CVE-2026-64087",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64087"
},
{
"name": "CVE-2025-71274",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71274"
},
{
"name": "CVE-2026-63958",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63958"
},
{
"name": "CVE-2026-31500",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31500"
},
{
"name": "CVE-2026-46212",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46212"
},
{
"name": "CVE-2026-45834",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45834"
},
{
"name": "CVE-2026-43171",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43171"
},
{
"name": "CVE-2026-23097",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23097"
},
{
"name": "CVE-2026-31695",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31695"
},
{
"name": "CVE-2026-63856",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63856"
},
{
"name": "CVE-2026-31700",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31700"
},
{
"name": "CVE-2026-31630",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31630"
},
{
"name": "CVE-2026-46089",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46089"
},
{
"name": "CVE-2026-43424",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43424"
},
{
"name": "CVE-2025-71198",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71198"
},
{
"name": "CVE-2026-43333",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43333"
},
{
"name": "CVE-2026-52933",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52933"
},
{
"name": "CVE-2026-31725",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31725"
},
{
"name": "CVE-2026-46199",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46199"
},
{
"name": "CVE-2026-43049",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43049"
},
{
"name": "CVE-2026-23036",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23036"
},
{
"name": "CVE-2026-43105",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43105"
},
{
"name": "CVE-2026-23312",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23312"
},
{
"name": "CVE-2026-64130",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64130"
},
{
"name": "CVE-2026-31639",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31639"
},
{
"name": "CVE-2026-31508",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31508"
},
{
"name": "CVE-2026-64044",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64044"
},
{
"name": "CVE-2026-23052",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23052"
},
{
"name": "CVE-2026-64185",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64185"
},
{
"name": "CVE-2026-23021",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23021"
},
{
"name": "CVE-2026-53122",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53122"
},
{
"name": "CVE-2026-23365",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23365"
},
{
"name": "CVE-2025-40323",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40323"
},
{
"name": "CVE-2026-43275",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43275"
},
{
"name": "CVE-2026-63878",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63878"
},
{
"name": "CVE-2026-46310",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46310"
},
{
"name": "CVE-2026-45983",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45983"
},
{
"name": "CVE-2026-46123",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46123"
},
{
"name": "CVE-2026-23419",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23419"
},
{
"name": "CVE-2026-43332",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43332"
},
{
"name": "CVE-2026-43329",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43329"
},
{
"name": "CVE-2026-31424",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31424"
},
{
"name": "CVE-2026-23375",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23375"
},
{
"name": "CVE-2026-23093",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23093"
},
{
"name": "CVE-2026-53000",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53000"
},
{
"name": "CVE-2026-64007",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64007"
},
{
"name": "CVE-2026-46028",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46028"
},
{
"name": "CVE-2026-23356",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23356"
},
{
"name": "CVE-2026-46207",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46207"
},
{
"name": "CVE-2026-45875",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45875"
},
{
"name": "CVE-2026-23307",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23307"
},
{
"name": "CVE-2026-53300",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53300"
},
{
"name": "CVE-2026-52969",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52969"
},
{
"name": "CVE-2026-31477",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31477"
},
{
"name": "CVE-2026-46098",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46098"
},
{
"name": "CVE-2025-71183",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71183"
},
{
"name": "CVE-2026-46157",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46157"
},
{
"name": "CVE-2026-43038",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43038"
},
{
"name": "CVE-2026-63994",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63994"
},
{
"name": "CVE-2026-53062",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53062"
},
{
"name": "CVE-2026-52990",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52990"
},
{
"name": "CVE-2026-31710",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31710"
},
{
"name": "CVE-2026-64114",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64114"
},
{
"name": "CVE-2026-45974",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45974"
},
{
"name": "CVE-2026-45965",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45965"
},
{
"name": "CVE-2026-43218",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43218"
},
{
"name": "CVE-2026-43072",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43072"
},
{
"name": "CVE-2026-53380",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53380"
},
{
"name": "CVE-2026-53032",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53032"
},
{
"name": "CVE-2026-46232",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46232"
},
{
"name": "CVE-2026-23053",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23053"
},
{
"name": "CVE-2026-43363",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43363"
},
{
"name": "CVE-2026-46014",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46014"
},
{
"name": "CVE-2026-64159",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64159"
},
{
"name": "CVE-2026-43013",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43013"
},
{
"name": "CVE-2026-64088",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64088"
},
{
"name": "CVE-2026-46165",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46165"
},
{
"name": "CVE-2026-45915",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45915"
},
{
"name": "CVE-2026-64073",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64073"
},
{
"name": "CVE-2026-31454",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31454"
},
{
"name": "CVE-2024-35865",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35865"
},
{
"name": "CVE-2025-71184",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71184"
},
{
"name": "CVE-2025-38659",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38659"
},
{
"name": "CVE-2026-46052",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46052"
},
{
"name": "CVE-2026-46061",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46061"
},
{
"name": "CVE-2026-43130",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43130"
},
{
"name": "CVE-2026-23386",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23386"
},
{
"name": "CVE-2026-31452",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31452"
},
{
"name": "CVE-2026-46053",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46053"
},
{
"name": "CVE-2026-53369",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53369"
},
{
"name": "CVE-2026-31407",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31407"
},
{
"name": "CVE-2026-31499",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31499"
},
{
"name": "CVE-2026-23398",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23398"
},
{
"name": "CVE-2026-53082",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53082"
},
{
"name": "CVE-2026-52926",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52926"
},
{
"name": "CVE-2026-63908",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63908"
},
{
"name": "CVE-2026-43368",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43368"
},
{
"name": "CVE-2026-31602",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31602"
},
{
"name": "CVE-2026-64145",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64145"
},
{
"name": "CVE-2026-31425",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31425"
},
{
"name": "CVE-2026-64002",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64002"
},
{
"name": "CVE-2026-63894",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63894"
},
{
"name": "CVE-2026-46238",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46238"
},
{
"name": "CVE-2026-64081",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64081"
},
{
"name": "CVE-2026-64135",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64135"
},
{
"name": "CVE-2026-63844",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63844"
},
{
"name": "CVE-2026-46051",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46051"
},
{
"name": "CVE-2026-64063",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64063"
},
{
"name": "CVE-2026-52977",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52977"
},
{
"name": "CVE-2025-71238",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71238"
},
{
"name": "CVE-2026-45890",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45890"
},
{
"name": "CVE-2026-46284",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46284"
},
{
"name": "CVE-2026-31440",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31440"
},
{
"name": "CVE-2026-46039",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46039"
},
{
"name": "CVE-2026-46155",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46155"
},
{
"name": "CVE-2026-43255",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43255"
},
{
"name": "CVE-2026-53074",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53074"
},
{
"name": "CVE-2026-63961",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63961"
},
{
"name": "CVE-2026-64154",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64154"
},
{
"name": "CVE-2026-46322",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46322"
},
{
"name": "CVE-2026-53036",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53036"
},
{
"name": "CVE-2026-45839",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45839"
},
{
"name": "CVE-2026-23276",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23276"
},
{
"name": "CVE-2026-31579",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31579"
},
{
"name": "CVE-2026-43283",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43283"
},
{
"name": "CVE-2026-46088",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46088"
},
{
"name": "CVE-2026-64065",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64065"
},
{
"name": "CVE-2026-23147",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23147"
},
{
"name": "CVE-2026-52982",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52982"
},
{
"name": "CVE-2026-31629",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31629"
},
{
"name": "CVE-2026-63902",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63902"
},
{
"name": "CVE-2026-64011",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64011"
},
{
"name": "CVE-2026-23080",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23080"
},
{
"name": "CVE-2026-63846",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63846"
},
{
"name": "CVE-2026-46102",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46102"
},
{
"name": "CVE-2026-64009",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64009"
},
{
"name": "CVE-2026-43050",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43050"
},
{
"name": "CVE-2026-53022",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53022"
},
{
"name": "CVE-2026-46078",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46078"
},
{
"name": "CVE-2026-43088",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43088"
},
{
"name": "CVE-2026-63883",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63883"
},
{
"name": "CVE-2026-31438",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31438"
},
{
"name": "CVE-2026-45969",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45969"
},
{
"name": "CVE-2026-46058",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46058"
},
{
"name": "CVE-2026-43494",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43494"
},
{
"name": "CVE-2026-43203",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43203"
},
{
"name": "CVE-2026-23154",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23154"
},
{
"name": "CVE-2026-31673",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31673"
},
{
"name": "CVE-2026-31667",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31667"
},
{
"name": "CVE-2026-53083",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53083"
}
],
"initial_release_date": "2026-07-24T00:00:00",
"last_revision_date": "2026-07-24T00:00:00",
"links": [],
"reference": "CERTFR-2026-AVI-0926",
"revisions": [
{
"description": "Version initiale",
"revision_date": "2026-07-24T00:00:00.000000"
}
],
"risks": [
{
"description": "Atteinte \u00e0 l\u0027int\u00e9grit\u00e9 des donn\u00e9es"
},
{
"description": "Non sp\u00e9cifi\u00e9 par l\u0027\u00e9diteur"
},
{
"description": "D\u00e9ni de service"
},
{
"description": "Contournement de la politique de s\u00e9curit\u00e9"
},
{
"description": "Atteinte \u00e0 la confidentialit\u00e9 des donn\u00e9es"
},
{
"description": "\u00c9l\u00e9vation de privil\u00e8ges"
}
],
"summary": "De multiples vuln\u00e9rabilit\u00e9s ont \u00e9t\u00e9 d\u00e9couvertes dans le noyau Linux d\u0027Ubuntu. Certaines d\u0027entre elles permettent \u00e0 un attaquant de provoquer une \u00e9l\u00e9vation de privil\u00e8ges, une atteinte \u00e0 la confidentialit\u00e9 des donn\u00e9es et une atteinte \u00e0 l\u0027int\u00e9grit\u00e9 des donn\u00e9es.",
"title": "Multiples vuln\u00e9rabilit\u00e9s dans le noyau Linux d\u0027Ubuntu",
"vendor_advisories": [
{
"published_at": "2026-07-21",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8575-1",
"url": "https://ubuntu.com/security/notices/USN-8575-1"
},
{
"published_at": "2026-07-23",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8575-2",
"url": "https://ubuntu.com/security/notices/USN-8575-2"
},
{
"published_at": "2026-07-23",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8596-1",
"url": "https://ubuntu.com/security/notices/USN-8596-1"
},
{
"published_at": "2026-07-23",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8593-1",
"url": "https://ubuntu.com/security/notices/USN-8593-1"
},
{
"published_at": "2026-07-20",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8568-1",
"url": "https://ubuntu.com/security/notices/USN-8568-1"
},
{
"published_at": "2026-07-20",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8570-1",
"url": "https://ubuntu.com/security/notices/USN-8570-1"
},
{
"published_at": "2026-07-23",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8595-1",
"url": "https://ubuntu.com/security/notices/USN-8595-1"
},
{
"published_at": "2026-07-20",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8566-1",
"url": "https://ubuntu.com/security/notices/USN-8566-1"
},
{
"published_at": "2026-07-21",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8576-1",
"url": "https://ubuntu.com/security/notices/USN-8576-1"
},
{
"published_at": "2026-07-17",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8490-2",
"url": "https://ubuntu.com/security/notices/USN-8490-2"
},
{
"published_at": "2026-07-23",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8594-1",
"url": "https://ubuntu.com/security/notices/USN-8594-1"
},
{
"published_at": "2026-07-23",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8574-2",
"url": "https://ubuntu.com/security/notices/USN-8574-2"
},
{
"published_at": "2026-07-20",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8567-1",
"url": "https://ubuntu.com/security/notices/USN-8567-1"
},
{
"published_at": "2026-07-23",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8597-1",
"url": "https://ubuntu.com/security/notices/USN-8597-1"
},
{
"published_at": "2026-07-23",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8576-2",
"url": "https://ubuntu.com/security/notices/USN-8576-2"
},
{
"published_at": "2026-07-20",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8569-1",
"url": "https://ubuntu.com/security/notices/USN-8569-1"
}
]
}
CERTFR-2026-AVI-0954
Vulnerability from certfr_avis - Published: 2026-07-31 - Updated: 2026-07-31
De multiples vulnérabilités ont été découvertes dans le noyau Linux d'Ubuntu. Certaines d'entre elles permettent à un attaquant de provoquer une élévation de privilèges, une atteinte à la confidentialité des données et une atteinte à l'intégrité des données.
Solutions
Se référer au bulletin de sécurité de l'éditeur pour l'obtention des correctifs (cf. section Documentation).
| Title | Publication Time | Tags | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"$ref": "https://www.cert.ssi.gouv.fr/openapi.json",
"affected_systems": [
{
"description": "Ubuntu 26.04 LTS",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 20.04 ESM",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 24.04 LTS",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 18.04 ESM",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 22.04 LTS",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
}
],
"affected_systems_content": "",
"content": "## Solutions\n\nSe r\u00e9f\u00e9rer au bulletin de s\u00e9curit\u00e9 de l\u0027\u00e9diteur pour l\u0027obtention des correctifs (cf. section Documentation).",
"cves": [
{
"name": "CVE-2024-27389",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27389"
},
{
"name": "CVE-2024-35865",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35865"
},
{
"name": "CVE-2024-36898",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36898"
},
{
"name": "CVE-2024-36922",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36922"
},
{
"name": "CVE-2025-38562",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38562"
},
{
"name": "CVE-2023-52737",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52737"
},
{
"name": "CVE-2025-38659",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38659"
},
{
"name": "CVE-2025-38710",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38710"
},
{
"name": "CVE-2025-39764",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39764"
},
{
"name": "CVE-2025-40005",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40005"
},
{
"name": "CVE-2025-40016",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40016"
},
{
"name": "CVE-2022-48816",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48816"
},
{
"name": "CVE-2025-40103",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40103"
},
{
"name": "CVE-2023-53545",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53545"
},
{
"name": "CVE-2023-53596",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53596"
},
{
"name": "CVE-2024-41079",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41079"
},
{
"name": "CVE-2024-46715",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46715"
},
{
"name": "CVE-2024-46770",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46770"
},
{
"name": "CVE-2023-53673",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53673"
},
{
"name": "CVE-2025-40082",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40082"
},
{
"name": "CVE-2025-38626",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38626"
},
{
"name": "CVE-2025-21709",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21709"
},
{
"name": "CVE-2025-62626",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-62626"
},
{
"name": "CVE-2025-40323",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40323"
},
{
"name": "CVE-2025-39748",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39748"
},
{
"name": "CVE-2024-50012",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50012"
},
{
"name": "CVE-2023-45896",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-45896"
},
{
"name": "CVE-2024-47809",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47809"
},
{
"name": "CVE-2024-56557",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56557"
},
{
"name": "CVE-2024-56584",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56584"
},
{
"name": "CVE-2024-56727",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56727"
},
{
"name": "CVE-2024-53221",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53221"
},
{
"name": "CVE-2024-56657",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56657"
},
{
"name": "CVE-2024-56719",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56719"
},
{
"name": "CVE-2025-21739",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21739"
},
{
"name": "CVE-2025-21712",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21712"
},
{
"name": "CVE-2025-21863",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21863"
},
{
"name": "CVE-2025-22107",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22107"
},
{
"name": "CVE-2025-22116",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22116"
},
{
"name": "CVE-2025-23141",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23141"
},
{
"name": "CVE-2025-37778",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37778"
},
{
"name": "CVE-2025-37924",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37924"
},
{
"name": "CVE-2025-37786",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37786"
},
{
"name": "CVE-2025-37822",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37822"
},
{
"name": "CVE-2022-50073",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50073"
},
{
"name": "CVE-2022-50116",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50116"
},
{
"name": "CVE-2025-38250",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38250"
},
{
"name": "CVE-2025-38105",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38105"
},
{
"name": "CVE-2025-38006",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38006"
},
{
"name": "CVE-2025-38192",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38192"
},
{
"name": "CVE-2025-38426",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38426"
},
{
"name": "CVE-2025-38201",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38201"
},
{
"name": "CVE-2025-40135",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40135"
},
{
"name": "CVE-2025-68214",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68214"
},
{
"name": "CVE-2025-68307",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68307"
},
{
"name": "CVE-2025-68206",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68206"
},
{
"name": "CVE-2025-68239",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68239"
},
{
"name": "CVE-2025-68256",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68256"
},
{
"name": "CVE-2025-68736",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68736"
},
{
"name": "CVE-2025-40150",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40150"
},
{
"name": "CVE-2025-68175",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68175"
},
{
"name": "CVE-2025-68263",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68263"
},
{
"name": "CVE-2025-68358",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68358"
},
{
"name": "CVE-2026-22985",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22985"
},
{
"name": "CVE-2025-71089",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71089"
},
{
"name": "CVE-2025-71150",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71150"
},
{
"name": "CVE-2025-71160",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71160"
},
{
"name": "CVE-2025-71162",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71162"
},
{
"name": "CVE-2025-71163",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71163"
},
{
"name": "CVE-2025-71180",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71180"
},
{
"name": "CVE-2025-71182",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71182"
},
{
"name": "CVE-2025-71183",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71183"
},
{
"name": "CVE-2025-71184",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71184"
},
{
"name": "CVE-2025-71185",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71185"
},
{
"name": "CVE-2025-71186",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71186"
},
{
"name": "CVE-2025-71189",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71189"
},
{
"name": "CVE-2025-71190",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71190"
},
{
"name": "CVE-2025-71191",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71191"
},
{
"name": "CVE-2025-71192",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71192"
},
{
"name": "CVE-2025-71193",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71193"
},
{
"name": "CVE-2025-71194",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71194"
},
{
"name": "CVE-2025-71195",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71195"
},
{
"name": "CVE-2025-71196",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71196"
},
{
"name": "CVE-2025-71197",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71197"
},
{
"name": "CVE-2025-71198",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71198"
},
{
"name": "CVE-2025-71199",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71199"
},
{
"name": "CVE-2026-22976",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22976"
},
{
"name": "CVE-2026-22977",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22977"
},
{
"name": "CVE-2026-22978",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22978"
},
{
"name": "CVE-2026-22979",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22979"
},
{
"name": "CVE-2026-22980",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22980"
},
{
"name": "CVE-2026-22982",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22982"
},
{
"name": "CVE-2026-22984",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22984"
},
{
"name": "CVE-2026-22989",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22989"
},
{
"name": "CVE-2026-22990",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22990"
},
{
"name": "CVE-2026-22991",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22991"
},
{
"name": "CVE-2026-22992",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22992"
},
{
"name": "CVE-2026-22994",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22994"
},
{
"name": "CVE-2026-22996",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22996"
},
{
"name": "CVE-2026-22997",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22997"
},
{
"name": "CVE-2026-22998",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22998"
},
{
"name": "CVE-2026-22999",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22999"
},
{
"name": "CVE-2026-23000",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23000"
},
{
"name": "CVE-2026-23001",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23001"
},
{
"name": "CVE-2026-23002",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23002"
},
{
"name": "CVE-2026-23003",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23003"
},
{
"name": "CVE-2026-23005",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23005"
},
{
"name": "CVE-2026-23006",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23006"
},
{
"name": "CVE-2026-23010",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23010"
},
{
"name": "CVE-2026-23011",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23011"
},
{
"name": "CVE-2026-23013",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23013"
},
{
"name": "CVE-2026-23019",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23019"
},
{
"name": "CVE-2026-23020",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23020"
},
{
"name": "CVE-2026-23021",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23021"
},
{
"name": "CVE-2026-23023",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23023"
},
{
"name": "CVE-2026-23025",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23025"
},
{
"name": "CVE-2026-23026",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23026"
},
{
"name": "CVE-2026-23030",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23030"
},
{
"name": "CVE-2026-23031",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23031"
},
{
"name": "CVE-2026-23032",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23032"
},
{
"name": "CVE-2026-23033",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23033"
},
{
"name": "CVE-2026-23035",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23035"
},
{
"name": "CVE-2026-23037",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23037"
},
{
"name": "CVE-2026-23038",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23038"
},
{
"name": "CVE-2026-23047",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23047"
},
{
"name": "CVE-2026-23049",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23049"
},
{
"name": "CVE-2026-23050",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23050"
},
{
"name": "CVE-2026-23053",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23053"
},
{
"name": "CVE-2026-23054",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23054"
},
{
"name": "CVE-2026-23055",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23055"
},
{
"name": "CVE-2026-23056",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23056"
},
{
"name": "CVE-2026-23057",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23057"
},
{
"name": "CVE-2026-23058",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23058"
},
{
"name": "CVE-2026-23059",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23059"
},
{
"name": "CVE-2026-23061",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23061"
},
{
"name": "CVE-2026-23062",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23062"
},
{
"name": "CVE-2026-23063",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23063"
},
{
"name": "CVE-2026-23064",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23064"
},
{
"name": "CVE-2026-23065",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23065"
},
{
"name": "CVE-2026-23068",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23068"
},
{
"name": "CVE-2026-23069",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23069"
},
{
"name": "CVE-2026-23071",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23071"
},
{
"name": "CVE-2026-23072",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23072"
},
{
"name": "CVE-2026-23073",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23073"
},
{
"name": "CVE-2026-23075",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23075"
},
{
"name": "CVE-2026-23076",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23076"
},
{
"name": "CVE-2026-23078",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23078"
},
{
"name": "CVE-2026-23080",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23080"
},
{
"name": "CVE-2026-23083",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23083"
},
{
"name": "CVE-2026-23084",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23084"
},
{
"name": "CVE-2026-23085",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23085"
},
{
"name": "CVE-2026-23086",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23086"
},
{
"name": "CVE-2026-23087",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23087"
},
{
"name": "CVE-2026-23088",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23088"
},
{
"name": "CVE-2026-23089",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23089"
},
{
"name": "CVE-2026-23090",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23090"
},
{
"name": "CVE-2026-23093",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23093"
},
{
"name": "CVE-2026-23094",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23094"
},
{
"name": "CVE-2026-23095",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23095"
},
{
"name": "CVE-2026-23096",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23096"
},
{
"name": "CVE-2026-23097",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23097"
},
{
"name": "CVE-2026-23098",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23098"
},
{
"name": "CVE-2026-23099",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23099"
},
{
"name": "CVE-2026-23101",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23101"
},
{
"name": "CVE-2026-23102",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23102"
},
{
"name": "CVE-2026-23103",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23103"
},
{
"name": "CVE-2026-23105",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23105"
},
{
"name": "CVE-2026-23107",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23107"
},
{
"name": "CVE-2026-23108",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23108"
},
{
"name": "CVE-2026-23110",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23110"
},
{
"name": "CVE-2026-22993",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22993"
},
{
"name": "CVE-2025-71203",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71203"
},
{
"name": "CVE-2025-71220",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71220"
},
{
"name": "CVE-2025-71222",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71222"
},
{
"name": "CVE-2025-71224",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71224"
},
{
"name": "CVE-2025-71229",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71229"
},
{
"name": "CVE-2025-71231",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71231"
},
{
"name": "CVE-2025-71232",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71232"
},
{
"name": "CVE-2025-71233",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71233"
},
{
"name": "CVE-2025-71235",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71235"
},
{
"name": "CVE-2025-71236",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71236"
},
{
"name": "CVE-2025-71237",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71237"
},
{
"name": "CVE-2026-23169",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23169"
},
{
"name": "CVE-2026-23176",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23176"
},
{
"name": "CVE-2026-23180",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23180"
},
{
"name": "CVE-2026-23182",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23182"
},
{
"name": "CVE-2026-23190",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23190"
},
{
"name": "CVE-2026-23193",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23193"
},
{
"name": "CVE-2026-23198",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23198"
},
{
"name": "CVE-2026-23202",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23202"
},
{
"name": "CVE-2026-23204",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23204"
},
{
"name": "CVE-2026-23206",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23206"
},
{
"name": "CVE-2026-23216",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23216"
},
{
"name": "CVE-2026-23220",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23220"
},
{
"name": "CVE-2026-23222",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23222"
},
{
"name": "CVE-2026-23228",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23228"
},
{
"name": "CVE-2026-23229",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23229"
},
{
"name": "CVE-2026-23230",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23230"
},
{
"name": "CVE-2026-23212",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23212"
},
{
"name": "CVE-2026-22981",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22981"
},
{
"name": "CVE-2026-22986",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22986"
},
{
"name": "CVE-2025-71238",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71238"
},
{
"name": "CVE-2026-23100",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23100"
},
{
"name": "CVE-2026-23221",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23221"
},
{
"name": "CVE-2026-23233",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23233"
},
{
"name": "CVE-2026-23234",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23234"
},
{
"name": "CVE-2026-23235",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23235"
},
{
"name": "CVE-2026-23236",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23236"
},
{
"name": "CVE-2026-23237",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23237"
},
{
"name": "CVE-2026-23238",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23238"
},
{
"name": "CVE-2022-49803",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49803"
},
{
"name": "CVE-2022-49961",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49961"
},
{
"name": "CVE-2022-50552",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50552"
},
{
"name": "CVE-2023-52682",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52682"
},
{
"name": "CVE-2023-53629",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53629"
},
{
"name": "CVE-2025-68334",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68334"
},
{
"name": "CVE-2025-71152",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71152"
},
{
"name": "CVE-2025-71158",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71158"
},
{
"name": "CVE-2025-71161",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71161"
},
{
"name": "CVE-2025-71188",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71188"
},
{
"name": "CVE-2025-71221",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71221"
},
{
"name": "CVE-2026-23004",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23004"
},
{
"name": "CVE-2026-23066",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23066"
},
{
"name": "CVE-2026-23113",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23113"
},
{
"name": "CVE-2026-23118",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23118"
},
{
"name": "CVE-2026-23119",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23119"
},
{
"name": "CVE-2026-23120",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23120"
},
{
"name": "CVE-2026-23121",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23121"
},
{
"name": "CVE-2026-23124",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23124"
},
{
"name": "CVE-2026-23125",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23125"
},
{
"name": "CVE-2026-23126",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23126"
},
{
"name": "CVE-2026-23128",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23128"
},
{
"name": "CVE-2026-23133",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23133"
},
{
"name": "CVE-2026-23137",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23137"
},
{
"name": "CVE-2026-23138",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23138"
},
{
"name": "CVE-2026-23141",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23141"
},
{
"name": "CVE-2026-23145",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23145"
},
{
"name": "CVE-2026-23146",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23146"
},
{
"name": "CVE-2026-23150",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23150"
},
{
"name": "CVE-2026-23154",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23154"
},
{
"name": "CVE-2026-23157",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23157"
},
{
"name": "CVE-2026-23164",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23164"
},
{
"name": "CVE-2026-23167",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23167"
},
{
"name": "CVE-2026-23170",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23170"
},
{
"name": "CVE-2026-23171",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23171"
},
{
"name": "CVE-2026-23207",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23207"
},
{
"name": "CVE-2026-23226",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23226"
},
{
"name": "CVE-2026-23227",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23227"
},
{
"name": "CVE-2025-71200",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71200"
},
{
"name": "CVE-2026-23017",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23017"
},
{
"name": "CVE-2026-23104",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23104"
},
{
"name": "CVE-2026-23116",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23116"
},
{
"name": "CVE-2026-23129",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23129"
},
{
"name": "CVE-2026-23135",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23135"
},
{
"name": "CVE-2026-23139",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23139"
},
{
"name": "CVE-2026-23151",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23151"
},
{
"name": "CVE-2026-23152",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23152"
},
{
"name": "CVE-2026-23156",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23156"
},
{
"name": "CVE-2026-23163",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23163"
},
{
"name": "CVE-2026-23166",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23166"
},
{
"name": "CVE-2026-23172",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23172"
},
{
"name": "CVE-2026-23173",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23173"
},
{
"name": "CVE-2025-71239",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71239"
},
{
"name": "CVE-2025-71265",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71265"
},
{
"name": "CVE-2025-71266",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71266"
},
{
"name": "CVE-2025-71267",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71267"
},
{
"name": "CVE-2026-23241",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23241"
},
{
"name": "CVE-2026-23242",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23242"
},
{
"name": "CVE-2026-23243",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23243"
},
{
"name": "CVE-2026-23266",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23266"
},
{
"name": "CVE-2026-23267",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23267"
},
{
"name": "CVE-2026-31788",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31788"
},
{
"name": "CVE-2026-23070",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23070"
},
{
"name": "CVE-2026-23131",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23131"
},
{
"name": "CVE-2026-23244",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23244"
},
{
"name": "CVE-2026-23245",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23245"
},
{
"name": "CVE-2026-23246",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23246"
},
{
"name": "CVE-2026-23253",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23253"
},
{
"name": "CVE-2026-23271",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23271"
},
{
"name": "CVE-2026-23277",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23277"
},
{
"name": "CVE-2026-23279",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23279"
},
{
"name": "CVE-2026-23281",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23281"
},
{
"name": "CVE-2026-23284",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23284"
},
{
"name": "CVE-2026-23285",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23285"
},
{
"name": "CVE-2026-23286",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23286"
},
{
"name": "CVE-2026-23289",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23289"
},
{
"name": "CVE-2026-23290",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23290"
},
{
"name": "CVE-2026-23291",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23291"
},
{
"name": "CVE-2026-23292",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23292"
},
{
"name": "CVE-2026-23293",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23293"
},
{
"name": "CVE-2026-23296",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23296"
},
{
"name": "CVE-2026-23298",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23298"
},
{
"name": "CVE-2026-23300",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23300"
},
{
"name": "CVE-2026-23303",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23303"
},
{
"name": "CVE-2026-23304",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23304"
},
{
"name": "CVE-2026-23306",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23306"
},
{
"name": "CVE-2026-23307",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23307"
},
{
"name": "CVE-2026-23310",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23310"
},
{
"name": "CVE-2026-23312",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23312"
},
{
"name": "CVE-2026-23315",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23315"
},
{
"name": "CVE-2026-23317",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23317"
},
{
"name": "CVE-2026-23318",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23318"
},
{
"name": "CVE-2026-23319",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23319"
},
{
"name": "CVE-2026-23324",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23324"
},
{
"name": "CVE-2026-23334",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23334"
},
{
"name": "CVE-2026-23336",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23336"
},
{
"name": "CVE-2026-23340",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23340"
},
{
"name": "CVE-2026-23343",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23343"
},
{
"name": "CVE-2026-23347",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23347"
},
{
"name": "CVE-2026-23352",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23352"
},
{
"name": "CVE-2026-23356",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23356"
},
{
"name": "CVE-2026-23357",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23357"
},
{
"name": "CVE-2026-23359",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23359"
},
{
"name": "CVE-2026-23364",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23364"
},
{
"name": "CVE-2026-23365",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23365"
},
{
"name": "CVE-2026-23367",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23367"
},
{
"name": "CVE-2026-23368",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23368"
},
{
"name": "CVE-2026-23370",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23370"
},
{
"name": "CVE-2026-23379",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23379"
},
{
"name": "CVE-2026-23381",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23381"
},
{
"name": "CVE-2026-23382",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23382"
},
{
"name": "CVE-2026-23388",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23388"
},
{
"name": "CVE-2026-23391",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23391"
},
{
"name": "CVE-2026-23392",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23392"
},
{
"name": "CVE-2026-23395",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23395"
},
{
"name": "CVE-2026-23396",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23396"
},
{
"name": "CVE-2026-23397",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23397"
},
{
"name": "CVE-2026-23398",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23398"
},
{
"name": "CVE-2026-31394",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31394"
},
{
"name": "CVE-2026-23144",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23144"
},
{
"name": "CVE-2026-23272",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23272"
},
{
"name": "CVE-2025-54505",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-54505"
},
{
"name": "CVE-2026-31408",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31408"
},
{
"name": "CVE-2026-31414",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31414"
},
{
"name": "CVE-2026-31416",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31416"
},
{
"name": "CVE-2026-31417",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31417"
},
{
"name": "CVE-2026-31418",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31418"
},
{
"name": "CVE-2026-31421",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31421"
},
{
"name": "CVE-2026-31422",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31422"
},
{
"name": "CVE-2026-31423",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31423"
},
{
"name": "CVE-2026-31424",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31424"
},
{
"name": "CVE-2026-31426",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31426"
},
{
"name": "CVE-2026-31427",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31427"
},
{
"name": "CVE-2026-31428",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31428"
},
{
"name": "CVE-2025-71269",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71269"
},
{
"name": "CVE-2026-23136",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23136"
},
{
"name": "CVE-2026-23140",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23140"
},
{
"name": "CVE-2026-23255",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23255"
},
{
"name": "CVE-2026-23262",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23262"
},
{
"name": "CVE-2026-23270",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23270"
},
{
"name": "CVE-2026-23278",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23278"
},
{
"name": "CVE-2026-23335",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23335"
},
{
"name": "CVE-2026-23361",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23361"
},
{
"name": "CVE-2026-23383",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23383"
},
{
"name": "CVE-2026-23386",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23386"
},
{
"name": "CVE-2026-23412",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23412"
},
{
"name": "CVE-2026-23413",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23413"
},
{
"name": "CVE-2026-23414",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23414"
},
{
"name": "CVE-2026-23419",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23419"
},
{
"name": "CVE-2026-31402",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31402"
},
{
"name": "CVE-2026-23360",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23360"
},
{
"name": "CVE-2026-31439",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31439"
},
{
"name": "CVE-2026-31441",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31441"
},
{
"name": "CVE-2026-31444",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31444"
},
{
"name": "CVE-2026-31446",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31446"
},
{
"name": "CVE-2026-31447",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31447"
},
{
"name": "CVE-2026-31448",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31448"
},
{
"name": "CVE-2026-31450",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31450"
},
{
"name": "CVE-2026-31451",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31451"
},
{
"name": "CVE-2026-31452",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31452"
},
{
"name": "CVE-2026-31453",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31453"
},
{
"name": "CVE-2026-31454",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31454"
},
{
"name": "CVE-2026-31455",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31455"
},
{
"name": "CVE-2026-31458",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31458"
},
{
"name": "CVE-2026-31467",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31467"
},
{
"name": "CVE-2026-31469",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31469"
},
{
"name": "CVE-2026-31473",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31473"
},
{
"name": "CVE-2026-31474",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31474"
},
{
"name": "CVE-2026-31476",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31476"
},
{
"name": "CVE-2026-31483",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31483"
},
{
"name": "CVE-2026-31485",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31485"
},
{
"name": "CVE-2026-31494",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31494"
},
{
"name": "CVE-2026-31495",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31495"
},
{
"name": "CVE-2026-31496",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31496"
},
{
"name": "CVE-2026-31497",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31497"
},
{
"name": "CVE-2026-31500",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31500"
},
{
"name": "CVE-2026-31503",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31503"
},
{
"name": "CVE-2026-31507",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31507"
},
{
"name": "CVE-2026-31509",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31509"
},
{
"name": "CVE-2026-31510",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31510"
},
{
"name": "CVE-2026-31515",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31515"
},
{
"name": "CVE-2026-31518",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31518"
},
{
"name": "CVE-2026-31519",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31519"
},
{
"name": "CVE-2026-31520",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31520"
},
{
"name": "CVE-2026-31521",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31521"
},
{
"name": "CVE-2026-31522",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31522"
},
{
"name": "CVE-2026-31523",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31523"
},
{
"name": "CVE-2026-31524",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31524"
},
{
"name": "CVE-2026-31525",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31525"
},
{
"name": "CVE-2026-31528",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31528"
},
{
"name": "CVE-2026-31555",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31555"
},
{
"name": "CVE-2026-31563",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31563"
},
{
"name": "CVE-2026-31565",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31565"
},
{
"name": "CVE-2026-31566",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31566"
},
{
"name": "CVE-2026-31570",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31570"
},
{
"name": "CVE-2026-31589",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31589"
},
{
"name": "CVE-2026-31591",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31591"
},
{
"name": "CVE-2026-31593",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31593"
},
{
"name": "CVE-2026-31600",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31600"
},
{
"name": "CVE-2026-31601",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31601"
},
{
"name": "CVE-2026-31608",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31608"
},
{
"name": "CVE-2026-31609",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31609"
},
{
"name": "CVE-2026-31620",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31620"
},
{
"name": "CVE-2026-31621",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31621"
},
{
"name": "CVE-2026-31674",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31674"
},
{
"name": "CVE-2026-31675",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31675"
},
{
"name": "CVE-2026-31678",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31678"
},
{
"name": "CVE-2026-31679",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31679"
},
{
"name": "CVE-2026-31680",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31680"
},
{
"name": "CVE-2026-31682",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31682"
},
{
"name": "CVE-2026-31430",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31430"
},
{
"name": "CVE-2026-31508",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31508"
},
{
"name": "CVE-2026-31532",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31532"
},
{
"name": "CVE-2026-31577",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31577"
},
{
"name": "CVE-2026-31578",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31578"
},
{
"name": "CVE-2026-31583",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31583"
},
{
"name": "CVE-2026-31585",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31585"
},
{
"name": "CVE-2026-31586",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31586"
},
{
"name": "CVE-2026-31587",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31587"
},
{
"name": "CVE-2026-31588",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31588"
},
{
"name": "CVE-2026-31590",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31590"
},
{
"name": "CVE-2026-31594",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31594"
},
{
"name": "CVE-2026-31595",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31595"
},
{
"name": "CVE-2026-31596",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31596"
},
{
"name": "CVE-2026-31597",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31597"
},
{
"name": "CVE-2026-31599",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31599"
},
{
"name": "CVE-2026-31603",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31603"
},
{
"name": "CVE-2026-31604",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31604"
},
{
"name": "CVE-2026-31605",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31605"
},
{
"name": "CVE-2026-31607",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31607"
},
{
"name": "CVE-2026-31610",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31610"
},
{
"name": "CVE-2026-31611",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31611"
},
{
"name": "CVE-2026-31612",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31612"
},
{
"name": "CVE-2026-31615",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31615"
},
{
"name": "CVE-2026-31618",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31618"
},
{
"name": "CVE-2026-31619",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31619"
},
{
"name": "CVE-2026-31622",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31622"
},
{
"name": "CVE-2026-31623",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31623"
},
{
"name": "CVE-2026-31624",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31624"
},
{
"name": "CVE-2026-31625",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31625"
},
{
"name": "CVE-2026-31626",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31626"
},
{
"name": "CVE-2026-31627",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31627"
},
{
"name": "CVE-2026-31628",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31628"
},
{
"name": "CVE-2026-31629",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31629"
},
{
"name": "CVE-2026-31634",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31634"
},
{
"name": "CVE-2026-31637",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31637"
},
{
"name": "CVE-2026-31638",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31638"
},
{
"name": "CVE-2026-31639",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31639"
},
{
"name": "CVE-2026-31642",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31642"
},
{
"name": "CVE-2026-31646",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31646"
},
{
"name": "CVE-2026-31648",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31648"
},
{
"name": "CVE-2026-31649",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31649"
},
{
"name": "CVE-2026-31651",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31651"
},
{
"name": "CVE-2026-31655",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31655"
},
{
"name": "CVE-2026-31656",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31656"
},
{
"name": "CVE-2026-31657",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31657"
},
{
"name": "CVE-2026-31658",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31658"
},
{
"name": "CVE-2026-31659",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31659"
},
{
"name": "CVE-2026-31660",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31660"
},
{
"name": "CVE-2026-31661",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31661"
},
{
"name": "CVE-2026-31662",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31662"
},
{
"name": "CVE-2026-31664",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31664"
},
{
"name": "CVE-2026-31665",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31665"
},
{
"name": "CVE-2026-31667",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31667"
},
{
"name": "CVE-2026-31668",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31668"
},
{
"name": "CVE-2026-31669",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31669"
},
{
"name": "CVE-2026-31670",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31670"
},
{
"name": "CVE-2026-31671",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31671"
},
{
"name": "CVE-2026-31672",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31672"
},
{
"name": "CVE-2026-31673",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31673"
},
{
"name": "CVE-2026-31676",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31676"
},
{
"name": "CVE-2026-31681",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31681"
},
{
"name": "CVE-2026-31684",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31684"
},
{
"name": "CVE-2026-31685",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31685"
},
{
"name": "CVE-2026-31689",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31689"
},
{
"name": "CVE-2026-31694",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31694"
},
{
"name": "CVE-2026-31696",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31696"
},
{
"name": "CVE-2026-31697",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31697"
},
{
"name": "CVE-2026-31698",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31698"
},
{
"name": "CVE-2026-31699",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31699"
},
{
"name": "CVE-2026-31700",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31700"
},
{
"name": "CVE-2026-31702",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31702"
},
{
"name": "CVE-2026-31704",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31704"
},
{
"name": "CVE-2026-31705",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31705"
},
{
"name": "CVE-2026-31708",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31708"
},
{
"name": "CVE-2026-31711",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31711"
},
{
"name": "CVE-2026-31721",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31721"
},
{
"name": "CVE-2026-23362",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23362"
},
{
"name": "CVE-2026-23287",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23287"
},
{
"name": "CVE-2026-23321",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23321"
},
{
"name": "CVE-2026-23339",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23339"
},
{
"name": "CVE-2026-23372",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23372"
},
{
"name": "CVE-2026-23378",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23378"
},
{
"name": "CVE-2026-23401",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23401"
},
{
"name": "CVE-2026-23420",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23420"
},
{
"name": "CVE-2026-23426",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23426"
},
{
"name": "CVE-2026-23428",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23428"
},
{
"name": "CVE-2026-23434",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23434"
},
{
"name": "CVE-2026-23438",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23438"
},
{
"name": "CVE-2026-23439",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23439"
},
{
"name": "CVE-2026-23446",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23446"
},
{
"name": "CVE-2026-23449",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23449"
},
{
"name": "CVE-2026-23450",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23450"
},
{
"name": "CVE-2026-23452",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23452"
},
{
"name": "CVE-2026-23454",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23454"
},
{
"name": "CVE-2026-23455",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23455"
},
{
"name": "CVE-2026-23456",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23456"
},
{
"name": "CVE-2026-23457",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23457"
},
{
"name": "CVE-2026-23458",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23458"
},
{
"name": "CVE-2026-23460",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23460"
},
{
"name": "CVE-2026-23462",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23462"
},
{
"name": "CVE-2026-23463",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23463"
},
{
"name": "CVE-2026-23474",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23474"
},
{
"name": "CVE-2026-23475",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23475"
},
{
"name": "CVE-2026-31389",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31389"
},
{
"name": "CVE-2026-31391",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31391"
},
{
"name": "CVE-2026-31392",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31392"
},
{
"name": "CVE-2026-31393",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31393"
},
{
"name": "CVE-2026-31396",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31396"
},
{
"name": "CVE-2026-31399",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31399"
},
{
"name": "CVE-2026-31400",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31400"
},
{
"name": "CVE-2026-31403",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31403"
},
{
"name": "CVE-2026-31405",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31405"
},
{
"name": "CVE-2026-31409",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31409"
},
{
"name": "CVE-2026-31411",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31411"
},
{
"name": "CVE-2026-31412",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31412"
},
{
"name": "CVE-2026-31415",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31415"
},
{
"name": "CVE-2026-31425",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31425"
},
{
"name": "CVE-2026-31433",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31433"
},
{
"name": "CVE-2026-31434",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31434"
},
{
"name": "CVE-2026-31464",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31464"
},
{
"name": "CVE-2026-31466",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31466"
},
{
"name": "CVE-2026-31477",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31477"
},
{
"name": "CVE-2026-31478",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31478"
},
{
"name": "CVE-2026-31480",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31480"
},
{
"name": "CVE-2026-31492",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31492"
},
{
"name": "CVE-2026-31498",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31498"
},
{
"name": "CVE-2026-31512",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31512"
},
{
"name": "CVE-2026-31540",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31540"
},
{
"name": "CVE-2026-31545",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31545"
},
{
"name": "CVE-2026-31546",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31546"
},
{
"name": "CVE-2026-31548",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31548"
},
{
"name": "CVE-2026-31549",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31549"
},
{
"name": "CVE-2026-31550",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31550"
},
{
"name": "CVE-2026-31551",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31551"
},
{
"name": "CVE-2026-31552",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31552"
},
{
"name": "CVE-2026-31683",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31683"
},
{
"name": "CVE-2026-31695",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31695"
},
{
"name": "CVE-2026-31720",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31720"
},
{
"name": "CVE-2026-31726",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31726"
},
{
"name": "CVE-2026-31728",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31728"
},
{
"name": "CVE-2026-31737",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31737"
},
{
"name": "CVE-2026-31738",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31738"
},
{
"name": "CVE-2026-31747",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31747"
},
{
"name": "CVE-2026-31748",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31748"
},
{
"name": "CVE-2026-31749",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31749"
},
{
"name": "CVE-2026-31751",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31751"
},
{
"name": "CVE-2026-31752",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31752"
},
{
"name": "CVE-2026-31754",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31754"
},
{
"name": "CVE-2026-31755",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31755"
},
{
"name": "CVE-2026-31756",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31756"
},
{
"name": "CVE-2026-31758",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31758"
},
{
"name": "CVE-2026-31759",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31759"
},
{
"name": "CVE-2026-31761",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31761"
},
{
"name": "CVE-2026-31762",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31762"
},
{
"name": "CVE-2026-31763",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31763"
},
{
"name": "CVE-2026-31768",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31768"
},
{
"name": "CVE-2026-31770",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31770"
},
{
"name": "CVE-2026-31773",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31773"
},
{
"name": "CVE-2026-31778",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31778"
},
{
"name": "CVE-2026-31779",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31779"
},
{
"name": "CVE-2026-31780",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31780"
},
{
"name": "CVE-2026-31781",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31781"
},
{
"name": "CVE-2026-43011",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43011"
},
{
"name": "CVE-2026-43013",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43013"
},
{
"name": "CVE-2026-43014",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43014"
},
{
"name": "CVE-2026-43015",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43015"
},
{
"name": "CVE-2026-43017",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43017"
},
{
"name": "CVE-2026-43018",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43018"
},
{
"name": "CVE-2026-43020",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43020"
},
{
"name": "CVE-2026-43023",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43023"
},
{
"name": "CVE-2026-43024",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43024"
},
{
"name": "CVE-2026-43025",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43025"
},
{
"name": "CVE-2026-43026",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43026"
},
{
"name": "CVE-2026-43027",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43027"
},
{
"name": "CVE-2026-43028",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43028"
},
{
"name": "CVE-2026-43030",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43030"
},
{
"name": "CVE-2026-43032",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43032"
},
{
"name": "CVE-2026-43035",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43035"
},
{
"name": "CVE-2026-43037",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43037"
},
{
"name": "CVE-2026-43038",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43038"
},
{
"name": "CVE-2026-43040",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43040"
},
{
"name": "CVE-2026-43041",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43041"
},
{
"name": "CVE-2026-43043",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43043"
},
{
"name": "CVE-2026-43046",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43046"
},
{
"name": "CVE-2026-43047",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43047"
},
{
"name": "CVE-2026-43050",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43050"
},
{
"name": "CVE-2026-43051",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43051"
},
{
"name": "CVE-2026-43054",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43054"
},
{
"name": "CVE-2026-43057",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43057"
},
{
"name": "CVE-2026-23249",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23249"
},
{
"name": "CVE-2026-23276",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23276"
},
{
"name": "CVE-2026-23302",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23302"
},
{
"name": "CVE-2026-23308",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23308"
},
{
"name": "CVE-2026-23313",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23313"
},
{
"name": "CVE-2026-23325",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23325"
},
{
"name": "CVE-2026-23330",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23330"
},
{
"name": "CVE-2026-23363",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23363"
},
{
"name": "CVE-2026-23369",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23369"
},
{
"name": "CVE-2026-23374",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23374"
},
{
"name": "CVE-2026-23375",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23375"
},
{
"name": "CVE-2026-23387",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23387"
},
{
"name": "CVE-2026-23389",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23389"
},
{
"name": "CVE-2026-23399",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23399"
},
{
"name": "CVE-2026-23427",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23427"
},
{
"name": "CVE-2026-23440",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23440"
},
{
"name": "CVE-2026-23441",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23441"
},
{
"name": "CVE-2026-23442",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23442"
},
{
"name": "CVE-2026-23444",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23444"
},
{
"name": "CVE-2026-23447",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23447"
},
{
"name": "CVE-2026-23448",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23448"
},
{
"name": "CVE-2026-23461",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23461"
},
{
"name": "CVE-2026-23464",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23464"
},
{
"name": "CVE-2026-23465",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23465"
},
{
"name": "CVE-2026-23470",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23470"
},
{
"name": "CVE-2026-31407",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31407"
},
{
"name": "CVE-2026-31429",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31429"
},
{
"name": "CVE-2026-31432",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31432"
},
{
"name": "CVE-2026-31436",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31436"
},
{
"name": "CVE-2026-31438",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31438"
},
{
"name": "CVE-2026-31440",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31440"
},
{
"name": "CVE-2026-31449",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31449"
},
{
"name": "CVE-2026-31470",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31470"
},
{
"name": "CVE-2026-31482",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31482"
},
{
"name": "CVE-2026-31487",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31487"
},
{
"name": "CVE-2026-31488",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31488"
},
{
"name": "CVE-2026-31489",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31489"
},
{
"name": "CVE-2026-31502",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31502"
},
{
"name": "CVE-2026-31505",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31505"
},
{
"name": "CVE-2026-31506",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31506"
},
{
"name": "CVE-2026-31511",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31511"
},
{
"name": "CVE-2026-31516",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31516"
},
{
"name": "CVE-2026-31527",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31527"
},
{
"name": "CVE-2026-31530",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31530"
},
{
"name": "CVE-2026-31542",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31542"
},
{
"name": "CVE-2026-31554",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31554"
},
{
"name": "CVE-2026-31556",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31556"
},
{
"name": "CVE-2026-31557",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31557"
},
{
"name": "CVE-2026-31575",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31575"
},
{
"name": "CVE-2026-31576",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31576"
},
{
"name": "CVE-2026-31580",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31580"
},
{
"name": "CVE-2026-31581",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31581"
},
{
"name": "CVE-2026-31582",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31582"
},
{
"name": "CVE-2026-31584",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31584"
},
{
"name": "CVE-2026-31598",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31598"
},
{
"name": "CVE-2026-31602",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31602"
},
{
"name": "CVE-2026-31606",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31606"
},
{
"name": "CVE-2026-31614",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31614"
},
{
"name": "CVE-2026-31616",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31616"
},
{
"name": "CVE-2026-31617",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31617"
},
{
"name": "CVE-2026-31645",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31645"
},
{
"name": "CVE-2026-31677",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31677"
},
{
"name": "CVE-2026-31686",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31686"
},
{
"name": "CVE-2026-31693",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31693"
},
{
"name": "CVE-2025-71294",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71294"
},
{
"name": "CVE-2026-43201",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43201"
},
{
"name": "CVE-2026-43300",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43300"
},
{
"name": "CVE-2026-43320",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43320"
},
{
"name": "CVE-2025-54518",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-54518"
},
{
"name": "CVE-2026-43284",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43284"
},
{
"name": "CVE-2026-43500",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43500"
},
{
"name": "CVE-2026-23468",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23468"
},
{
"name": "CVE-2026-31709",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31709"
},
{
"name": "CVE-2026-31715",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31715"
},
{
"name": "CVE-2026-23123",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23123"
},
{
"name": "CVE-2026-23142",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23142"
},
{
"name": "CVE-2026-23148",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23148"
},
{
"name": "CVE-2026-23159",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23159"
},
{
"name": "CVE-2026-23160",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23160"
},
{
"name": "CVE-2026-23168",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23168"
},
{
"name": "CVE-2026-23256",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23256"
},
{
"name": "CVE-2026-23257",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23257"
},
{
"name": "CVE-2026-23258",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23258"
},
{
"name": "CVE-2026-31499",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31499"
},
{
"name": "CVE-2026-43088",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43088"
},
{
"name": "CVE-2026-43109",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43109"
},
{
"name": "CVE-2026-43490",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43490"
},
{
"name": "CVE-2026-31635",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31635"
},
{
"name": "CVE-2026-43494",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43494"
},
{
"name": "CVE-2026-43503",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43503"
},
{
"name": "CVE-2026-46174",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46174"
},
{
"name": "CVE-2026-43110",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43110"
},
{
"name": "CVE-2026-43190",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43190"
},
{
"name": "CVE-2026-43255",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43255"
},
{
"name": "CVE-2026-43264",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43264"
},
{
"name": "CVE-2026-43334",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43334"
},
{
"name": "CVE-2026-43437",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43437"
},
{
"name": "CVE-2026-43158",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43158"
},
{
"name": "CVE-2026-43163",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43163"
},
{
"name": "CVE-2026-31613",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31613"
},
{
"name": "CVE-2026-43329",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43329"
},
{
"name": "CVE-2026-46243",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46243"
},
{
"name": "CVE-2026-46028",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46028"
},
{
"name": "CVE-2025-71274",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71274"
},
{
"name": "CVE-2025-71292",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71292"
},
{
"name": "CVE-2025-71304",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71304"
},
{
"name": "CVE-2026-43060",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43060"
},
{
"name": "CVE-2026-43061",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43061"
},
{
"name": "CVE-2026-43062",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43062"
},
{
"name": "CVE-2026-43066",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43066"
},
{
"name": "CVE-2026-43068",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43068"
},
{
"name": "CVE-2026-43069",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43069"
},
{
"name": "CVE-2026-43124",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43124"
},
{
"name": "CVE-2026-43130",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43130"
},
{
"name": "CVE-2026-43132",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43132"
},
{
"name": "CVE-2026-43134",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43134"
},
{
"name": "CVE-2026-43135",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43135"
},
{
"name": "CVE-2026-43136",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43136"
},
{
"name": "CVE-2026-43139",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43139"
},
{
"name": "CVE-2026-43140",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43140"
},
{
"name": "CVE-2026-43141",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43141"
},
{
"name": "CVE-2026-43147",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43147"
},
{
"name": "CVE-2026-43149",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43149"
},
{
"name": "CVE-2026-43152",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43152"
},
{
"name": "CVE-2026-43156",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43156"
},
{
"name": "CVE-2026-43159",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43159"
},
{
"name": "CVE-2026-43168",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43168"
},
{
"name": "CVE-2026-43171",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43171"
},
{
"name": "CVE-2026-43180",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43180"
},
{
"name": "CVE-2026-43183",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43183"
},
{
"name": "CVE-2026-43184",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43184"
},
{
"name": "CVE-2026-43187",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43187"
},
{
"name": "CVE-2026-43194",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43194"
},
{
"name": "CVE-2026-43196",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43196"
},
{
"name": "CVE-2026-43202",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43202"
},
{
"name": "CVE-2026-43203",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43203"
},
{
"name": "CVE-2026-43206",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43206"
},
{
"name": "CVE-2026-43207",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43207"
},
{
"name": "CVE-2026-43209",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43209"
},
{
"name": "CVE-2026-43211",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43211"
},
{
"name": "CVE-2026-43218",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43218"
},
{
"name": "CVE-2026-43223",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43223"
},
{
"name": "CVE-2026-43226",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43226"
},
{
"name": "CVE-2026-43227",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43227"
},
{
"name": "CVE-2026-43230",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43230"
},
{
"name": "CVE-2026-43231",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43231"
},
{
"name": "CVE-2026-43232",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43232"
},
{
"name": "CVE-2026-43233",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43233"
},
{
"name": "CVE-2026-43236",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43236"
},
{
"name": "CVE-2026-43241",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43241"
},
{
"name": "CVE-2026-43242",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43242"
},
{
"name": "CVE-2026-43246",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43246"
},
{
"name": "CVE-2026-43251",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43251"
},
{
"name": "CVE-2026-43257",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43257"
},
{
"name": "CVE-2026-43261",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43261"
},
{
"name": "CVE-2026-43266",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43266"
},
{
"name": "CVE-2026-43268",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43268"
},
{
"name": "CVE-2026-43269",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43269"
},
{
"name": "CVE-2026-43270",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43270"
},
{
"name": "CVE-2026-43273",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43273"
},
{
"name": "CVE-2026-43277",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43277"
},
{
"name": "CVE-2026-43283",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43283"
},
{
"name": "CVE-2026-43287",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43287"
},
{
"name": "CVE-2026-43289",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43289"
},
{
"name": "CVE-2026-43295",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43295"
},
{
"name": "CVE-2026-43296",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43296"
},
{
"name": "CVE-2026-43314",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43314"
},
{
"name": "CVE-2026-43316",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43316"
},
{
"name": "CVE-2026-43327",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43327"
},
{
"name": "CVE-2026-43328",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43328"
},
{
"name": "CVE-2026-43336",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43336"
},
{
"name": "CVE-2026-43339",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43339"
},
{
"name": "CVE-2026-43340",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43340"
},
{
"name": "CVE-2026-43342",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43342"
},
{
"name": "CVE-2026-43343",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43343"
},
{
"name": "CVE-2026-43355",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43355"
},
{
"name": "CVE-2026-43357",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43357"
},
{
"name": "CVE-2026-43363",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43363"
},
{
"name": "CVE-2026-43370",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43370"
},
{
"name": "CVE-2026-43373",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43373"
},
{
"name": "CVE-2026-43381",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43381"
},
{
"name": "CVE-2026-43382",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43382"
},
{
"name": "CVE-2026-43383",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43383"
},
{
"name": "CVE-2026-43386",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43386"
},
{
"name": "CVE-2026-43387",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43387"
},
{
"name": "CVE-2026-43407",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43407"
},
{
"name": "CVE-2026-43411",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43411"
},
{
"name": "CVE-2026-43420",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43420"
},
{
"name": "CVE-2026-43424",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43424"
},
{
"name": "CVE-2026-43425",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43425"
},
{
"name": "CVE-2026-43426",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43426"
},
{
"name": "CVE-2026-43427",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43427"
},
{
"name": "CVE-2026-43428",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43428"
},
{
"name": "CVE-2026-43429",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43429"
},
{
"name": "CVE-2026-43430",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43430"
},
{
"name": "CVE-2026-43432",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43432"
},
{
"name": "CVE-2026-43439",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43439"
},
{
"name": "CVE-2026-43445",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43445"
},
{
"name": "CVE-2026-43449",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43449"
},
{
"name": "CVE-2026-43450",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43450"
},
{
"name": "CVE-2026-43451",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43451"
},
{
"name": "CVE-2026-43452",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43452"
},
{
"name": "CVE-2026-43453",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43453"
},
{
"name": "CVE-2026-43458",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43458"
},
{
"name": "CVE-2026-43459",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43459"
},
{
"name": "CVE-2026-43466",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43466"
},
{
"name": "CVE-2026-43472",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43472"
},
{
"name": "CVE-2026-43475",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43475"
},
{
"name": "CVE-2026-43480",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43480"
},
{
"name": "CVE-2026-45848",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45848"
},
{
"name": "CVE-2026-45852",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45852"
},
{
"name": "CVE-2026-45856",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45856"
},
{
"name": "CVE-2026-45857",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45857"
},
{
"name": "CVE-2026-45860",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45860"
},
{
"name": "CVE-2026-45862",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45862"
},
{
"name": "CVE-2026-45866",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45866"
},
{
"name": "CVE-2026-45867",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45867"
},
{
"name": "CVE-2026-45868",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45868"
},
{
"name": "CVE-2026-45869",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45869"
},
{
"name": "CVE-2026-45870",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45870"
},
{
"name": "CVE-2026-45871",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45871"
},
{
"name": "CVE-2026-45873",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45873"
},
{
"name": "CVE-2026-45875",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45875"
},
{
"name": "CVE-2026-45879",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45879"
},
{
"name": "CVE-2026-45883",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45883"
},
{
"name": "CVE-2026-45885",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45885"
},
{
"name": "CVE-2026-45890",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45890"
},
{
"name": "CVE-2026-45899",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45899"
},
{
"name": "CVE-2026-45904",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45904"
},
{
"name": "CVE-2026-45912",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45912"
},
{
"name": "CVE-2026-45914",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45914"
},
{
"name": "CVE-2026-45915",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45915"
},
{
"name": "CVE-2026-45916",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45916"
},
{
"name": "CVE-2026-45919",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45919"
},
{
"name": "CVE-2026-45920",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45920"
},
{
"name": "CVE-2026-45923",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45923"
},
{
"name": "CVE-2026-45936",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45936"
},
{
"name": "CVE-2026-45941",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45941"
},
{
"name": "CVE-2026-45948",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45948"
},
{
"name": "CVE-2026-45954",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45954"
},
{
"name": "CVE-2026-45956",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45956"
},
{
"name": "CVE-2026-45958",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45958"
},
{
"name": "CVE-2026-45960",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45960"
},
{
"name": "CVE-2026-45964",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45964"
},
{
"name": "CVE-2026-45965",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45965"
},
{
"name": "CVE-2026-45968",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45968"
},
{
"name": "CVE-2026-45970",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45970"
},
{
"name": "CVE-2026-45974",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45974"
},
{
"name": "CVE-2026-45978",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45978"
},
{
"name": "CVE-2026-45981",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45981"
},
{
"name": "CVE-2026-45983",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45983"
},
{
"name": "CVE-2026-45984",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45984"
},
{
"name": "CVE-2026-45985",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45985"
},
{
"name": "CVE-2026-23418",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23418"
},
{
"name": "CVE-2026-31579",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31579"
},
{
"name": "CVE-2026-43044",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43044"
},
{
"name": "CVE-2026-43082",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43082"
},
{
"name": "CVE-2026-43120",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43120"
},
{
"name": "CVE-2026-43153",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43153"
},
{
"name": "CVE-2026-43214",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43214"
},
{
"name": "CVE-2026-43265",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43265"
},
{
"name": "CVE-2026-43330",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43330"
},
{
"name": "CVE-2026-43365",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43365"
},
{
"name": "CVE-2026-43366",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43366"
},
{
"name": "CVE-2026-43419",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43419"
},
{
"name": "CVE-2026-43441",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43441"
},
{
"name": "CVE-2026-45834",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45834"
},
{
"name": "CVE-2026-45835",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45835"
},
{
"name": "CVE-2026-45836",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45836"
},
{
"name": "CVE-2026-45838",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45838"
},
{
"name": "CVE-2026-45839",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45839"
},
{
"name": "CVE-2026-45840",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45840"
},
{
"name": "CVE-2026-45841",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45841"
},
{
"name": "CVE-2026-45842",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45842"
},
{
"name": "CVE-2026-45843",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45843"
},
{
"name": "CVE-2026-45844",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45844"
},
{
"name": "CVE-2026-45845",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45845"
},
{
"name": "CVE-2026-45846",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45846"
},
{
"name": "CVE-2026-45986",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45986"
},
{
"name": "CVE-2026-45987",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45987"
},
{
"name": "CVE-2026-45988",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45988"
},
{
"name": "CVE-2026-45989",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45989"
},
{
"name": "CVE-2026-45991",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45991"
},
{
"name": "CVE-2026-45994",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45994"
},
{
"name": "CVE-2026-45996",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45996"
},
{
"name": "CVE-2026-45997",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45997"
},
{
"name": "CVE-2026-45999",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45999"
},
{
"name": "CVE-2026-46002",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46002"
},
{
"name": "CVE-2026-46003",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46003"
},
{
"name": "CVE-2026-46004",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46004"
},
{
"name": "CVE-2026-46005",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46005"
},
{
"name": "CVE-2026-46006",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46006"
},
{
"name": "CVE-2026-46009",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46009"
},
{
"name": "CVE-2026-46011",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46011"
},
{
"name": "CVE-2026-46012",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46012"
},
{
"name": "CVE-2026-46015",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46015"
},
{
"name": "CVE-2026-46016",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46016"
},
{
"name": "CVE-2026-46018",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46018"
},
{
"name": "CVE-2026-46019",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46019"
},
{
"name": "CVE-2026-46021",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46021"
},
{
"name": "CVE-2026-46022",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46022"
},
{
"name": "CVE-2026-46023",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46023"
},
{
"name": "CVE-2026-46024",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46024"
},
{
"name": "CVE-2026-46026",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46026"
},
{
"name": "CVE-2026-46027",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46027"
},
{
"name": "CVE-2026-46031",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46031"
},
{
"name": "CVE-2026-46033",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46033"
},
{
"name": "CVE-2026-46037",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46037"
},
{
"name": "CVE-2026-46038",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46038"
},
{
"name": "CVE-2026-46040",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46040"
},
{
"name": "CVE-2026-46043",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46043"
},
{
"name": "CVE-2026-46046",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46046"
},
{
"name": "CVE-2026-46047",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46047"
},
{
"name": "CVE-2026-46049",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46049"
},
{
"name": "CVE-2026-46050",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46050"
},
{
"name": "CVE-2026-46051",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46051"
},
{
"name": "CVE-2026-46052",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46052"
},
{
"name": "CVE-2026-46053",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46053"
},
{
"name": "CVE-2026-46056",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46056"
},
{
"name": "CVE-2026-46058",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46058"
},
{
"name": "CVE-2026-46062",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46062"
},
{
"name": "CVE-2026-46063",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46063"
},
{
"name": "CVE-2026-46064",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46064"
},
{
"name": "CVE-2026-46065",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46065"
},
{
"name": "CVE-2026-46068",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46068"
},
{
"name": "CVE-2026-46069",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46069"
},
{
"name": "CVE-2026-46070",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46070"
},
{
"name": "CVE-2026-46072",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46072"
},
{
"name": "CVE-2026-46075",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46075"
},
{
"name": "CVE-2026-46077",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46077"
},
{
"name": "CVE-2026-46078",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46078"
},
{
"name": "CVE-2026-46079",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46079"
},
{
"name": "CVE-2026-46080",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46080"
},
{
"name": "CVE-2026-46082",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46082"
},
{
"name": "CVE-2026-46083",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46083"
},
{
"name": "CVE-2026-46084",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46084"
},
{
"name": "CVE-2026-46085",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46085"
},
{
"name": "CVE-2026-46086",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46086"
},
{
"name": "CVE-2026-46088",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46088"
},
{
"name": "CVE-2026-46089",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46089"
},
{
"name": "CVE-2026-46091",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46091"
},
{
"name": "CVE-2026-46094",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46094"
},
{
"name": "CVE-2026-46098",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46098"
},
{
"name": "CVE-2026-46099",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46099"
},
{
"name": "CVE-2026-46101",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46101"
},
{
"name": "CVE-2026-46102",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46102"
},
{
"name": "CVE-2026-46103",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46103"
},
{
"name": "CVE-2026-46106",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46106"
},
{
"name": "CVE-2026-46107",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46107"
},
{
"name": "CVE-2026-46108",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46108"
},
{
"name": "CVE-2026-46109",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46109"
},
{
"name": "CVE-2026-46110",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46110"
},
{
"name": "CVE-2026-46111",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46111"
},
{
"name": "CVE-2026-46112",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46112"
},
{
"name": "CVE-2026-46113",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46113"
},
{
"name": "CVE-2026-46114",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46114"
},
{
"name": "CVE-2026-46115",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46115"
},
{
"name": "CVE-2026-46116",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46116"
},
{
"name": "CVE-2026-46119",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46119"
},
{
"name": "CVE-2026-46120",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46120"
},
{
"name": "CVE-2026-46122",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46122"
},
{
"name": "CVE-2026-46123",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46123"
},
{
"name": "CVE-2026-46124",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46124"
},
{
"name": "CVE-2026-46125",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46125"
},
{
"name": "CVE-2026-46127",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46127"
},
{
"name": "CVE-2026-46128",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46128"
},
{
"name": "CVE-2026-46129",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46129"
},
{
"name": "CVE-2026-46131",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46131"
},
{
"name": "CVE-2026-46132",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46132"
},
{
"name": "CVE-2026-46133",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46133"
},
{
"name": "CVE-2026-46136",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46136"
},
{
"name": "CVE-2026-46137",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46137"
},
{
"name": "CVE-2026-46138",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46138"
},
{
"name": "CVE-2026-46142",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46142"
},
{
"name": "CVE-2026-46144",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46144"
},
{
"name": "CVE-2026-46145",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46145"
},
{
"name": "CVE-2026-46146",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46146"
},
{
"name": "CVE-2026-46149",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46149"
},
{
"name": "CVE-2026-46150",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46150"
},
{
"name": "CVE-2026-46151",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46151"
},
{
"name": "CVE-2026-46152",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46152"
},
{
"name": "CVE-2026-46155",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46155"
},
{
"name": "CVE-2026-46156",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46156"
},
{
"name": "CVE-2026-46159",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46159"
},
{
"name": "CVE-2026-46160",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46160"
},
{
"name": "CVE-2026-46161",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46161"
},
{
"name": "CVE-2026-46163",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46163"
},
{
"name": "CVE-2026-46164",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46164"
},
{
"name": "CVE-2026-46165",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46165"
},
{
"name": "CVE-2026-46167",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46167"
},
{
"name": "CVE-2026-46168",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46168"
},
{
"name": "CVE-2026-46172",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46172"
},
{
"name": "CVE-2026-46173",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46173"
},
{
"name": "CVE-2026-46176",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46176"
},
{
"name": "CVE-2026-46177",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46177"
},
{
"name": "CVE-2026-46178",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46178"
},
{
"name": "CVE-2026-46180",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46180"
},
{
"name": "CVE-2026-46185",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46185"
},
{
"name": "CVE-2026-46186",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46186"
},
{
"name": "CVE-2026-46187",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46187"
},
{
"name": "CVE-2026-46189",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46189"
},
{
"name": "CVE-2026-46190",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46190"
},
{
"name": "CVE-2026-46191",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46191"
},
{
"name": "CVE-2026-46193",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46193"
},
{
"name": "CVE-2026-46195",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46195"
},
{
"name": "CVE-2026-46196",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46196"
},
{
"name": "CVE-2026-46197",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46197"
},
{
"name": "CVE-2026-46198",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46198"
},
{
"name": "CVE-2026-46199",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46199"
},
{
"name": "CVE-2026-46204",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46204"
},
{
"name": "CVE-2026-46205",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46205"
},
{
"name": "CVE-2026-46206",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46206"
},
{
"name": "CVE-2026-46208",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46208"
},
{
"name": "CVE-2026-46209",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46209"
},
{
"name": "CVE-2026-46212",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46212"
},
{
"name": "CVE-2026-46214",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46214"
},
{
"name": "CVE-2026-46218",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46218"
},
{
"name": "CVE-2026-46219",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46219"
},
{
"name": "CVE-2026-46220",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46220"
},
{
"name": "CVE-2026-46225",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46225"
},
{
"name": "CVE-2026-46226",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46226"
},
{
"name": "CVE-2026-46227",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46227"
},
{
"name": "CVE-2026-46229",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46229"
},
{
"name": "CVE-2026-46230",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46230"
},
{
"name": "CVE-2026-46231",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46231"
},
{
"name": "CVE-2026-46233",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46233"
},
{
"name": "CVE-2026-46234",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46234"
},
{
"name": "CVE-2026-46236",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46236"
},
{
"name": "CVE-2026-46238",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46238"
},
{
"name": "CVE-2026-46273",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46273"
},
{
"name": "CVE-2026-31729",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31729"
},
{
"name": "CVE-2026-43012",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43012"
},
{
"name": "CVE-2026-43112",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43112"
},
{
"name": "CVE-2026-43252",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43252"
},
{
"name": "CVE-2026-43333",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43333"
},
{
"name": "CVE-2026-43338",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43338"
},
{
"name": "CVE-2026-43341",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43341"
},
{
"name": "CVE-2026-43359",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43359"
},
{
"name": "CVE-2026-43360",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43360"
},
{
"name": "CVE-2026-43361",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43361"
},
{
"name": "CVE-2026-43362",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43362"
},
{
"name": "CVE-2026-43414",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43414"
},
{
"name": "CVE-2026-43499",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43499"
},
{
"name": "CVE-2026-43501",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43501"
},
{
"name": "CVE-2026-45910",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45910"
},
{
"name": "CVE-2026-43056",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43056"
},
{
"name": "CVE-2026-43125",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43125"
},
{
"name": "CVE-2026-46054",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46054"
},
{
"name": "CVE-2026-46181",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46181"
},
{
"name": "CVE-2026-31772",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31772"
},
{
"name": "CVE-2026-43279",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43279"
},
{
"name": "CVE-2026-46117",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46117"
},
{
"name": "CVE-2026-46135",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46135"
},
{
"name": "CVE-2026-46166",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46166"
},
{
"name": "CVE-2026-31717",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31717"
},
{
"name": "CVE-2026-43245",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43245"
},
{
"name": "CVE-2026-46158",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46158"
},
{
"name": "CVE-2026-46170",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46170"
},
{
"name": "CVE-2026-46203",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46203"
},
{
"name": "CVE-2026-46216",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46216"
},
{
"name": "CVE-2026-46244",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46244"
},
{
"name": "CVE-2026-46315",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46315"
},
{
"name": "CVE-2026-46320",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46320"
},
{
"name": "CVE-2026-46321",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46321"
},
{
"name": "CVE-2026-46322",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46322"
},
{
"name": "CVE-2026-52911",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52911"
},
{
"name": "CVE-2026-31703",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31703"
},
{
"name": "CVE-2026-31767",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31767"
},
{
"name": "CVE-2026-43052",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43052"
},
{
"name": "CVE-2026-43059",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43059"
},
{
"name": "CVE-2026-43065",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43065"
},
{
"name": "CVE-2026-43150",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43150"
},
{
"name": "CVE-2026-43197",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43197"
},
{
"name": "CVE-2026-43249",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43249"
},
{
"name": "CVE-2026-43332",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43332"
},
{
"name": "CVE-2026-43406",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43406"
},
{
"name": "CVE-2026-43413",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43413"
},
{
"name": "CVE-2026-43455",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43455"
},
{
"name": "CVE-2026-43483",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43483"
},
{
"name": "CVE-2026-45878",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45878"
},
{
"name": "CVE-2026-45886",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45886"
},
{
"name": "CVE-2026-45898",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45898"
},
{
"name": "CVE-2026-45942",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45942"
},
{
"name": "CVE-2026-46090",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46090"
},
{
"name": "CVE-2026-46157",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46157"
},
{
"name": "CVE-2026-46169",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46169"
},
{
"name": "CVE-2026-46259",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46259"
},
{
"name": "CVE-2026-46316",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46316"
},
{
"name": "CVE-2026-46317",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46317"
},
{
"name": "CVE-2026-46274",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46274"
},
{
"name": "CVE-2026-46280",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46280"
},
{
"name": "CVE-2026-46285",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46285"
},
{
"name": "CVE-2026-46287",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46287"
},
{
"name": "CVE-2026-46289",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46289"
},
{
"name": "CVE-2026-46291",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46291"
},
{
"name": "CVE-2026-46292",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46292"
},
{
"name": "CVE-2026-46293",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46293"
},
{
"name": "CVE-2026-46296",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46296"
},
{
"name": "CVE-2026-46299",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46299"
},
{
"name": "CVE-2026-46301",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46301"
},
{
"name": "CVE-2026-46303",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46303"
},
{
"name": "CVE-2026-46304",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46304"
},
{
"name": "CVE-2026-46306",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46306"
},
{
"name": "CVE-2026-46307",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46307"
},
{
"name": "CVE-2026-46312",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46312"
},
{
"name": "CVE-2026-46319",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46319"
},
{
"name": "CVE-2026-46275",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46275"
},
{
"name": "CVE-2026-52912",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52912"
},
{
"name": "CVE-2026-52913",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52913"
},
{
"name": "CVE-2026-52915",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52915"
},
{
"name": "CVE-2026-52916",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52916"
},
{
"name": "CVE-2026-52919",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52919"
},
{
"name": "CVE-2026-52921",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52921"
},
{
"name": "CVE-2026-52922",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52922"
},
{
"name": "CVE-2026-52923",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52923"
},
{
"name": "CVE-2026-52926",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52926"
},
{
"name": "CVE-2026-52927",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52927"
},
{
"name": "CVE-2026-52931",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52931"
},
{
"name": "CVE-2026-52934",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52934"
},
{
"name": "CVE-2026-52941",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52941"
},
{
"name": "CVE-2026-52943",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52943"
},
{
"name": "CVE-2026-53080",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53080"
},
{
"name": "CVE-2026-43074",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43074"
},
{
"name": "CVE-2026-52918",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52918"
},
{
"name": "CVE-2026-52944",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52944"
},
{
"name": "CVE-2025-71272",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71272"
},
{
"name": "CVE-2025-71273",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71273"
},
{
"name": "CVE-2025-71286",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71286"
},
{
"name": "CVE-2025-71291",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71291"
},
{
"name": "CVE-2025-71295",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71295"
},
{
"name": "CVE-2025-71297",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71297"
},
{
"name": "CVE-2025-71305",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71305"
},
{
"name": "CVE-2026-31574",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31574"
},
{
"name": "CVE-2026-31592",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31592"
},
{
"name": "CVE-2026-31687",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31687"
},
{
"name": "CVE-2026-31701",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31701"
},
{
"name": "CVE-2026-31706",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31706"
},
{
"name": "CVE-2026-31707",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31707"
},
{
"name": "CVE-2026-31710",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31710"
},
{
"name": "CVE-2026-31712",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31712"
},
{
"name": "CVE-2026-31713",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31713"
},
{
"name": "CVE-2026-31714",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31714"
},
{
"name": "CVE-2026-31716",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31716"
},
{
"name": "CVE-2026-31718",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31718"
},
{
"name": "CVE-2026-31719",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31719"
},
{
"name": "CVE-2026-43058",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43058"
},
{
"name": "CVE-2026-43071",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43071"
},
{
"name": "CVE-2026-43072",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43072"
},
{
"name": "CVE-2026-43073",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43073"
},
{
"name": "CVE-2026-43083",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43083"
},
{
"name": "CVE-2026-43114",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43114"
},
{
"name": "CVE-2026-43117",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43117"
},
{
"name": "CVE-2026-43123",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43123"
},
{
"name": "CVE-2026-43128",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43128"
},
{
"name": "CVE-2026-43133",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43133"
},
{
"name": "CVE-2026-43137",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43137"
},
{
"name": "CVE-2026-43143",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43143"
},
{
"name": "CVE-2026-43145",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43145"
},
{
"name": "CVE-2026-43148",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43148"
},
{
"name": "CVE-2026-43157",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43157"
},
{
"name": "CVE-2026-43167",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43167"
},
{
"name": "CVE-2026-43169",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43169"
},
{
"name": "CVE-2026-43170",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43170"
},
{
"name": "CVE-2026-43173",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43173"
},
{
"name": "CVE-2026-43175",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43175"
},
{
"name": "CVE-2026-43182",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43182"
},
{
"name": "CVE-2026-43186",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43186"
},
{
"name": "CVE-2026-43189",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43189"
},
{
"name": "CVE-2026-43199",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43199"
},
{
"name": "CVE-2026-43200",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43200"
},
{
"name": "CVE-2026-43205",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43205"
},
{
"name": "CVE-2026-43212",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43212"
},
{
"name": "CVE-2026-43215",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43215"
},
{
"name": "CVE-2026-43221",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43221"
},
{
"name": "CVE-2026-43222",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43222"
},
{
"name": "CVE-2026-43225",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43225"
},
{
"name": "CVE-2026-43238",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43238"
},
{
"name": "CVE-2026-43239",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43239"
},
{
"name": "CVE-2026-43244",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43244"
},
{
"name": "CVE-2026-43248",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43248"
},
{
"name": "CVE-2026-43250",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43250"
},
{
"name": "CVE-2026-43253",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43253"
},
{
"name": "CVE-2026-43256",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43256"
},
{
"name": "CVE-2026-43258",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43258"
},
{
"name": "CVE-2026-43262",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43262"
},
{
"name": "CVE-2026-43271",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43271"
},
{
"name": "CVE-2026-43275",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43275"
},
{
"name": "CVE-2026-43278",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43278"
},
{
"name": "CVE-2026-43288",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43288"
},
{
"name": "CVE-2026-43291",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43291"
},
{
"name": "CVE-2026-43297",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43297"
},
{
"name": "CVE-2026-43302",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43302"
},
{
"name": "CVE-2026-43304",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43304"
},
{
"name": "CVE-2026-43312",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43312"
},
{
"name": "CVE-2026-43313",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43313"
},
{
"name": "CVE-2026-43315",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43315"
},
{
"name": "CVE-2026-43317",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43317"
},
{
"name": "CVE-2026-43318",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43318"
},
{
"name": "CVE-2026-43319",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43319"
},
{
"name": "CVE-2026-43348",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43348"
},
{
"name": "CVE-2026-43349",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43349"
},
{
"name": "CVE-2026-43350",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43350"
},
{
"name": "CVE-2026-43376",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43376"
},
{
"name": "CVE-2026-43378",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43378"
},
{
"name": "CVE-2026-43384",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43384"
},
{
"name": "CVE-2026-43402",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43402"
},
{
"name": "CVE-2026-43491",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43491"
},
{
"name": "CVE-2026-43493",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43493"
},
{
"name": "CVE-2026-45847",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45847"
},
{
"name": "CVE-2026-45849",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45849"
},
{
"name": "CVE-2026-45851",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45851"
},
{
"name": "CVE-2026-45859",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45859"
},
{
"name": "CVE-2026-45861",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45861"
},
{
"name": "CVE-2026-45864",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45864"
},
{
"name": "CVE-2026-45865",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45865"
},
{
"name": "CVE-2026-45872",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45872"
},
{
"name": "CVE-2026-45877",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45877"
},
{
"name": "CVE-2026-45880",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45880"
},
{
"name": "CVE-2026-45881",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45881"
},
{
"name": "CVE-2026-45882",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45882"
},
{
"name": "CVE-2026-45884",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45884"
},
{
"name": "CVE-2026-45891",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45891"
},
{
"name": "CVE-2026-45893",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45893"
},
{
"name": "CVE-2026-45895",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45895"
},
{
"name": "CVE-2026-45902",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45902"
},
{
"name": "CVE-2026-45905",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45905"
},
{
"name": "CVE-2026-45913",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45913"
},
{
"name": "CVE-2026-45917",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45917"
},
{
"name": "CVE-2026-45921",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45921"
},
{
"name": "CVE-2026-45928",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45928"
},
{
"name": "CVE-2026-45935",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45935"
},
{
"name": "CVE-2026-45938",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45938"
},
{
"name": "CVE-2026-45946",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45946"
},
{
"name": "CVE-2026-45947",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45947"
},
{
"name": "CVE-2026-45957",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45957"
},
{
"name": "CVE-2026-45962",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45962"
},
{
"name": "CVE-2026-45969",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45969"
},
{
"name": "CVE-2026-45972",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45972"
},
{
"name": "CVE-2026-45973",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45973"
},
{
"name": "CVE-2026-45976",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45976"
},
{
"name": "CVE-2026-45982",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45982"
},
{
"name": "CVE-2026-45990",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45990"
},
{
"name": "CVE-2026-45995",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45995"
},
{
"name": "CVE-2026-46001",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46001"
},
{
"name": "CVE-2026-46007",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46007"
},
{
"name": "CVE-2026-46008",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46008"
},
{
"name": "CVE-2026-46010",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46010"
},
{
"name": "CVE-2026-46013",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46013"
},
{
"name": "CVE-2026-46014",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46014"
},
{
"name": "CVE-2026-46020",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46020"
},
{
"name": "CVE-2026-46025",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46025"
},
{
"name": "CVE-2026-46029",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46029"
},
{
"name": "CVE-2026-46030",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46030"
},
{
"name": "CVE-2026-46032",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46032"
},
{
"name": "CVE-2026-46034",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46034"
},
{
"name": "CVE-2026-46035",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46035"
},
{
"name": "CVE-2026-46036",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46036"
},
{
"name": "CVE-2026-46039",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46039"
},
{
"name": "CVE-2026-46041",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46041"
},
{
"name": "CVE-2026-46042",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46042"
},
{
"name": "CVE-2026-46044",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46044"
},
{
"name": "CVE-2026-46045",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46045"
},
{
"name": "CVE-2026-46057",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46057"
},
{
"name": "CVE-2026-46059",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46059"
},
{
"name": "CVE-2026-46060",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46060"
},
{
"name": "CVE-2026-46061",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46061"
},
{
"name": "CVE-2026-46066",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46066"
},
{
"name": "CVE-2026-46067",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46067"
},
{
"name": "CVE-2026-46071",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46071"
},
{
"name": "CVE-2026-46073",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46073"
},
{
"name": "CVE-2026-46074",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46074"
},
{
"name": "CVE-2026-46076",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46076"
},
{
"name": "CVE-2026-46081",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46081"
},
{
"name": "CVE-2026-46087",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46087"
},
{
"name": "CVE-2026-46092",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46092"
},
{
"name": "CVE-2026-46093",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46093"
},
{
"name": "CVE-2026-46095",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46095"
},
{
"name": "CVE-2026-46096",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46096"
},
{
"name": "CVE-2026-46097",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46097"
},
{
"name": "CVE-2026-46100",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46100"
},
{
"name": "CVE-2026-46246",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46246"
},
{
"name": "CVE-2026-46247",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46247"
},
{
"name": "CVE-2026-46249",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46249"
},
{
"name": "CVE-2026-46250",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46250"
},
{
"name": "CVE-2026-46251",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46251"
},
{
"name": "CVE-2026-46253",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46253"
},
{
"name": "CVE-2026-46254",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46254"
},
{
"name": "CVE-2026-46255",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46255"
},
{
"name": "CVE-2026-46260",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46260"
},
{
"name": "CVE-2026-46261",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46261"
},
{
"name": "CVE-2026-46265",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46265"
},
{
"name": "CVE-2026-46266",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46266"
},
{
"name": "CVE-2026-46267",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46267"
},
{
"name": "CVE-2026-46270",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46270"
},
{
"name": "CVE-2026-46276",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46276"
},
{
"name": "CVE-2026-46277",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46277"
},
{
"name": "CVE-2026-46278",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46278"
},
{
"name": "CVE-2026-46279",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46279"
},
{
"name": "CVE-2026-46281",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46281"
},
{
"name": "CVE-2026-46282",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46282"
},
{
"name": "CVE-2026-46283",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46283"
},
{
"name": "CVE-2026-46284",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46284"
},
{
"name": "CVE-2026-46286",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46286"
},
{
"name": "CVE-2026-46288",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46288"
},
{
"name": "CVE-2026-46290",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46290"
},
{
"name": "CVE-2026-46325",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46325"
},
{
"name": "CVE-2026-46328",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46328"
},
{
"name": "CVE-2026-46332",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46332"
},
{
"name": "CVE-2026-52904",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52904"
},
{
"name": "CVE-2026-52905",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52905"
},
{
"name": "CVE-2026-52906",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52906"
},
{
"name": "CVE-2026-52907",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52907"
},
{
"name": "CVE-2026-52933",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52933"
},
{
"name": "CVE-2026-53174",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53174"
},
{
"name": "CVE-2026-43036",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43036"
},
{
"name": "CVE-2026-43049",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43049"
},
{
"name": "CVE-2026-43119",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43119"
},
{
"name": "CVE-2026-43345",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43345"
},
{
"name": "CVE-2026-43405",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43405"
},
{
"name": "CVE-2026-43469",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43469"
},
{
"name": "CVE-2026-46162",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46162"
},
{
"name": "CVE-2026-52928",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52928"
},
{
"name": "CVE-2026-46242",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46242"
},
{
"name": "CVE-2026-52975",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52975"
},
{
"name": "CVE-2026-53070",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53070"
},
{
"name": "CVE-2026-53101",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53101"
},
{
"name": "CVE-2026-31630",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31630"
},
{
"name": "CVE-2026-43064",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43064"
},
{
"name": "CVE-2026-43075",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43075"
},
{
"name": "CVE-2026-43076",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43076"
},
{
"name": "CVE-2026-43079",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43079"
},
{
"name": "CVE-2026-43080",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43080"
},
{
"name": "CVE-2026-43085",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43085"
},
{
"name": "CVE-2026-43089",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43089"
},
{
"name": "CVE-2026-43093",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43093"
},
{
"name": "CVE-2026-43094",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43094"
},
{
"name": "CVE-2026-43098",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43098"
},
{
"name": "CVE-2026-43099",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43099"
},
{
"name": "CVE-2026-43103",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43103"
},
{
"name": "CVE-2026-43104",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43104"
},
{
"name": "CVE-2026-43105",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43105"
},
{
"name": "CVE-2026-43111",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43111"
},
{
"name": "CVE-2026-43113",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43113"
},
{
"name": "CVE-2026-43421",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43421"
},
{
"name": "CVE-2026-43492",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43492"
},
{
"name": "CVE-2026-43495",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43495"
},
{
"name": "CVE-2026-43496",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43496"
},
{
"name": "CVE-2026-43497",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43497"
},
{
"name": "CVE-2026-43502",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43502"
},
{
"name": "CVE-2026-46143",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46143"
},
{
"name": "CVE-2026-46179",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46179"
},
{
"name": "CVE-2026-46184",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46184"
},
{
"name": "CVE-2026-46235",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46235"
},
{
"name": "CVE-2026-46294",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46294"
},
{
"name": "CVE-2026-46314",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46314"
},
{
"name": "CVE-2026-52914",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52914"
},
{
"name": "CVE-2026-52920",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52920"
},
{
"name": "CVE-2026-52925",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52925"
},
{
"name": "CVE-2026-52954",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52954"
},
{
"name": "CVE-2026-52955",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52955"
},
{
"name": "CVE-2026-52957",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52957"
},
{
"name": "CVE-2026-52958",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52958"
},
{
"name": "CVE-2026-52962",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52962"
},
{
"name": "CVE-2026-52963",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52963"
},
{
"name": "CVE-2026-52967",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52967"
},
{
"name": "CVE-2026-52968",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52968"
},
{
"name": "CVE-2026-52969",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52969"
},
{
"name": "CVE-2026-52970",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52970"
},
{
"name": "CVE-2026-52974",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52974"
},
{
"name": "CVE-2026-52977",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52977"
},
{
"name": "CVE-2026-52981",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52981"
},
{
"name": "CVE-2026-52982",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52982"
},
{
"name": "CVE-2026-52984",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52984"
},
{
"name": "CVE-2026-52985",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52985"
},
{
"name": "CVE-2026-52986",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52986"
},
{
"name": "CVE-2026-52989",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52989"
},
{
"name": "CVE-2026-52992",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52992"
},
{
"name": "CVE-2026-52993",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52993"
},
{
"name": "CVE-2026-52995",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52995"
},
{
"name": "CVE-2026-52998",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52998"
},
{
"name": "CVE-2026-52999",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52999"
},
{
"name": "CVE-2026-53001",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53001"
},
{
"name": "CVE-2026-53002",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53002"
},
{
"name": "CVE-2026-53003",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53003"
},
{
"name": "CVE-2026-53004",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53004"
},
{
"name": "CVE-2026-43081",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43081"
},
{
"name": "CVE-2026-43086",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43086"
},
{
"name": "CVE-2026-43107",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43107"
},
{
"name": "CVE-2026-43456",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43456"
},
{
"name": "CVE-2026-53053",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53053"
},
{
"name": "CVE-2026-53122",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53122"
},
{
"name": "CVE-2026-53281",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53281"
},
{
"name": "CVE-2026-53006",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53006"
},
{
"name": "CVE-2026-53011",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53011"
},
{
"name": "CVE-2026-53012",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53012"
},
{
"name": "CVE-2026-53016",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53016"
},
{
"name": "CVE-2026-53021",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53021"
},
{
"name": "CVE-2026-53022",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53022"
},
{
"name": "CVE-2026-53023",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53023"
},
{
"name": "CVE-2026-53033",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53033"
},
{
"name": "CVE-2026-53034",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53034"
},
{
"name": "CVE-2026-53035",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53035"
},
{
"name": "CVE-2026-53036",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53036"
},
{
"name": "CVE-2026-53037",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53037"
},
{
"name": "CVE-2026-53039",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53039"
},
{
"name": "CVE-2026-53040",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53040"
},
{
"name": "CVE-2026-53041",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53041"
},
{
"name": "CVE-2026-53043",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53043"
},
{
"name": "CVE-2026-53045",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53045"
},
{
"name": "CVE-2026-53046",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53046"
},
{
"name": "CVE-2026-53047",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53047"
},
{
"name": "CVE-2026-53048",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53048"
},
{
"name": "CVE-2026-53049",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53049"
},
{
"name": "CVE-2026-53050",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53050"
},
{
"name": "CVE-2026-53052",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53052"
},
{
"name": "CVE-2026-53056",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53056"
},
{
"name": "CVE-2026-53059",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53059"
},
{
"name": "CVE-2026-53060",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53060"
},
{
"name": "CVE-2026-53061",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53061"
},
{
"name": "CVE-2026-53062",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53062"
},
{
"name": "CVE-2026-53063",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53063"
},
{
"name": "CVE-2026-53064",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53064"
},
{
"name": "CVE-2026-53065",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53065"
},
{
"name": "CVE-2026-53066",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53066"
},
{
"name": "CVE-2026-53068",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53068"
},
{
"name": "CVE-2026-53069",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53069"
},
{
"name": "CVE-2026-53071",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53071"
},
{
"name": "CVE-2026-53072",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53072"
},
{
"name": "CVE-2026-53073",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53073"
},
{
"name": "CVE-2026-53074",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53074"
},
{
"name": "CVE-2026-53075",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53075"
},
{
"name": "CVE-2026-53077",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53077"
},
{
"name": "CVE-2026-53082",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53082"
},
{
"name": "CVE-2026-53086",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53086"
},
{
"name": "CVE-2026-53088",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53088"
},
{
"name": "CVE-2026-53093",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53093"
},
{
"name": "CVE-2026-53096",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53096"
},
{
"name": "CVE-2026-53111",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53111"
},
{
"name": "CVE-2026-53112",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53112"
},
{
"name": "CVE-2026-53128",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53128"
},
{
"name": "CVE-2026-53130",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53130"
},
{
"name": "CVE-2026-53279",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53279"
},
{
"name": "CVE-2026-53287",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53287"
},
{
"name": "CVE-2026-53289",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53289"
},
{
"name": "CVE-2026-53291",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53291"
},
{
"name": "CVE-2026-53294",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53294"
},
{
"name": "CVE-2026-53295",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53295"
},
{
"name": "CVE-2026-53296",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53296"
},
{
"name": "CVE-2026-53303",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53303"
},
{
"name": "CVE-2026-53304",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53304"
},
{
"name": "CVE-2026-53306",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53306"
},
{
"name": "CVE-2026-53309",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53309"
},
{
"name": "CVE-2026-53314",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53314"
},
{
"name": "CVE-2026-53320",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53320"
},
{
"name": "CVE-2026-53354",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53354"
},
{
"name": "CVE-2026-53357",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53357"
},
{
"name": "CVE-2026-43281",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43281"
},
{
"name": "CVE-2026-52936",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52936"
},
{
"name": "CVE-2026-53013",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53013"
},
{
"name": "CVE-2026-53032",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53032"
},
{
"name": "CVE-2026-53058",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53058"
},
{
"name": "CVE-2026-53076",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53076"
},
{
"name": "CVE-2026-53094",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53094"
},
{
"name": "CVE-2026-53110",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53110"
},
{
"name": "CVE-2026-53126",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53126"
},
{
"name": "CVE-2026-53293",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53293"
},
{
"name": "CVE-2026-43185",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43185"
},
{
"name": "CVE-2026-64208",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64208"
},
{
"name": "CVE-2026-64209",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64209"
},
{
"name": "CVE-2026-64210",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64210"
},
{
"name": "CVE-2026-64211",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64211"
},
{
"name": "CVE-2026-64212",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64212"
},
{
"name": "CVE-2026-64213",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64213"
},
{
"name": "CVE-2026-64214",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64214"
},
{
"name": "CVE-2026-64215",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64215"
},
{
"name": "CVE-2026-64216",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64216"
},
{
"name": "CVE-2026-64217",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64217"
},
{
"name": "CVE-2026-64218",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64218"
},
{
"name": "CVE-2026-64219",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64219"
},
{
"name": "CVE-2026-64220",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64220"
},
{
"name": "CVE-2026-64221",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64221"
},
{
"name": "CVE-2026-64222",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64222"
},
{
"name": "CVE-2026-64223",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64223"
},
{
"name": "CVE-2026-64224",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64224"
},
{
"name": "CVE-2026-64225",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64225"
},
{
"name": "CVE-2026-64226",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64226"
},
{
"name": "CVE-2026-64227",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64227"
},
{
"name": "CVE-2026-64228",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64228"
},
{
"name": "CVE-2026-64229",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64229"
},
{
"name": "CVE-2026-64230",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64230"
},
{
"name": "CVE-2026-64231",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64231"
},
{
"name": "CVE-2026-64232",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64232"
},
{
"name": "CVE-2026-64233",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64233"
},
{
"name": "CVE-2026-64234",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64234"
},
{
"name": "CVE-2026-64235",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64235"
},
{
"name": "CVE-2026-64236",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64236"
},
{
"name": "CVE-2026-64237",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64237"
},
{
"name": "CVE-2026-64238",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64238"
},
{
"name": "CVE-2026-64239",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64239"
},
{
"name": "CVE-2026-64240",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64240"
},
{
"name": "CVE-2026-64241",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64241"
},
{
"name": "CVE-2026-64242",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64242"
},
{
"name": "CVE-2026-64243",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64243"
},
{
"name": "CVE-2026-64515",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64515"
},
{
"name": "CVE-2026-64516",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64516"
},
{
"name": "CVE-2026-64517",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64517"
},
{
"name": "CVE-2026-64518",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64518"
},
{
"name": "CVE-2025-71187",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71187"
},
{
"name": "CVE-2025-71201",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71201"
},
{
"name": "CVE-2025-71287",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71287"
},
{
"name": "CVE-2025-71288",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71288"
},
{
"name": "CVE-2026-22987",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22987"
},
{
"name": "CVE-2026-23007",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23007"
},
{
"name": "CVE-2026-23008",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23008"
},
{
"name": "CVE-2026-23009",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23009"
},
{
"name": "CVE-2026-23012",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23012"
},
{
"name": "CVE-2026-23014",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23014"
},
{
"name": "CVE-2026-23015",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23015"
},
{
"name": "CVE-2026-23018",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23018"
},
{
"name": "CVE-2026-23022",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23022"
},
{
"name": "CVE-2026-23024",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23024"
},
{
"name": "CVE-2026-23034",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23034"
},
{
"name": "CVE-2026-23036",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23036"
},
{
"name": "CVE-2026-23042",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23042"
},
{
"name": "CVE-2026-23044",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23044"
},
{
"name": "CVE-2026-23045",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23045"
},
{
"name": "CVE-2026-23046",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23046"
},
{
"name": "CVE-2026-23051",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23051"
},
{
"name": "CVE-2026-23052",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23052"
},
{
"name": "CVE-2026-23067",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23067"
},
{
"name": "CVE-2026-23077",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23077"
},
{
"name": "CVE-2026-23079",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23079"
},
{
"name": "CVE-2026-23081",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23081"
},
{
"name": "CVE-2026-23092",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23092"
},
{
"name": "CVE-2026-23106",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23106"
},
{
"name": "CVE-2026-23109",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23109"
},
{
"name": "CVE-2026-23114",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23114"
},
{
"name": "CVE-2026-23115",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23115"
},
{
"name": "CVE-2026-23122",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23122"
},
{
"name": "CVE-2026-23130",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23130"
},
{
"name": "CVE-2026-23143",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23143"
},
{
"name": "CVE-2026-23147",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23147"
},
{
"name": "CVE-2026-23158",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23158"
},
{
"name": "CVE-2026-23161",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23161"
},
{
"name": "CVE-2026-23162",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23162"
},
{
"name": "CVE-2026-23165",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23165"
},
{
"name": "CVE-2026-31413",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31413"
},
{
"name": "CVE-2026-31722",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31722"
},
{
"name": "CVE-2026-31723",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31723"
},
{
"name": "CVE-2026-31724",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31724"
},
{
"name": "CVE-2026-31725",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31725"
},
{
"name": "CVE-2026-31730",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31730"
},
{
"name": "CVE-2026-31731",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31731"
},
{
"name": "CVE-2026-31740",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31740"
},
{
"name": "CVE-2026-31741",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31741"
},
{
"name": "CVE-2026-43007",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43007"
},
{
"name": "CVE-2026-43016",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43016"
},
{
"name": "CVE-2026-43019",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43019"
},
{
"name": "CVE-2026-43084",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43084"
},
{
"name": "CVE-2026-43091",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43091"
},
{
"name": "CVE-2026-43092",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43092"
},
{
"name": "CVE-2026-43129",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43129"
},
{
"name": "CVE-2026-43162",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43162"
},
{
"name": "CVE-2026-43324",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43324"
},
{
"name": "CVE-2026-43368",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43368"
},
{
"name": "CVE-2026-43371",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43371"
},
{
"name": "CVE-2026-43372",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43372"
},
{
"name": "CVE-2026-43377",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43377"
},
{
"name": "CVE-2026-43380",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43380"
},
{
"name": "CVE-2026-43395",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43395"
},
{
"name": "CVE-2026-43397",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43397"
},
{
"name": "CVE-2026-43408",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43408"
},
{
"name": "CVE-2026-43409",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43409"
},
{
"name": "CVE-2026-43412",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43412"
},
{
"name": "CVE-2026-43415",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43415"
},
{
"name": "CVE-2026-43436",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43436"
},
{
"name": "CVE-2026-43448",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43448"
},
{
"name": "CVE-2026-43457",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43457"
},
{
"name": "CVE-2026-43467",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43467"
},
{
"name": "CVE-2026-43468",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43468"
},
{
"name": "CVE-2026-43471",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43471"
},
{
"name": "CVE-2026-43473",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43473"
},
{
"name": "CVE-2026-43476",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43476"
},
{
"name": "CVE-2026-43484",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43484"
},
{
"name": "CVE-2026-43488",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43488"
},
{
"name": "CVE-2026-43498",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43498"
},
{
"name": "CVE-2026-45837",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45837"
},
{
"name": "CVE-2026-45855",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45855"
},
{
"name": "CVE-2026-45858",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45858"
},
{
"name": "CVE-2026-45911",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45911"
},
{
"name": "CVE-2026-45924",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45924"
},
{
"name": "CVE-2026-45943",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45943"
},
{
"name": "CVE-2026-46104",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46104"
},
{
"name": "CVE-2026-46105",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46105"
},
{
"name": "CVE-2026-46118",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46118"
},
{
"name": "CVE-2026-46121",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46121"
},
{
"name": "CVE-2026-46126",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46126"
},
{
"name": "CVE-2026-46130",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46130"
},
{
"name": "CVE-2026-46134",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46134"
},
{
"name": "CVE-2026-46139",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46139"
},
{
"name": "CVE-2026-46140",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46140"
},
{
"name": "CVE-2026-46141",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46141"
},
{
"name": "CVE-2026-46147",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46147"
},
{
"name": "CVE-2026-46148",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46148"
},
{
"name": "CVE-2026-46153",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46153"
},
{
"name": "CVE-2026-46154",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46154"
},
{
"name": "CVE-2026-46171",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46171"
},
{
"name": "CVE-2026-46175",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46175"
},
{
"name": "CVE-2026-46182",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46182"
},
{
"name": "CVE-2026-46183",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46183"
},
{
"name": "CVE-2026-46188",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46188"
},
{
"name": "CVE-2026-46192",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46192"
},
{
"name": "CVE-2026-46194",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46194"
},
{
"name": "CVE-2026-46200",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46200"
},
{
"name": "CVE-2026-46201",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46201"
},
{
"name": "CVE-2026-46202",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46202"
},
{
"name": "CVE-2026-46207",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46207"
},
{
"name": "CVE-2026-46210",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46210"
},
{
"name": "CVE-2026-46211",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46211"
},
{
"name": "CVE-2026-46213",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46213"
},
{
"name": "CVE-2026-46215",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46215"
},
{
"name": "CVE-2026-46221",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46221"
},
{
"name": "CVE-2026-46222",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46222"
},
{
"name": "CVE-2026-46223",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46223"
},
{
"name": "CVE-2026-46224",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46224"
},
{
"name": "CVE-2026-46228",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46228"
},
{
"name": "CVE-2026-46232",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46232"
},
{
"name": "CVE-2026-46239",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46239"
},
{
"name": "CVE-2026-46240",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46240"
},
{
"name": "CVE-2026-46241",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46241"
},
{
"name": "CVE-2026-46295",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46295"
},
{
"name": "CVE-2026-46297",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46297"
},
{
"name": "CVE-2026-46298",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46298"
},
{
"name": "CVE-2026-46302",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46302"
},
{
"name": "CVE-2026-46305",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46305"
},
{
"name": "CVE-2026-46308",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46308"
},
{
"name": "CVE-2026-46309",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46309"
},
{
"name": "CVE-2026-46310",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46310"
},
{
"name": "CVE-2026-46311",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46311"
},
{
"name": "CVE-2026-46313",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46313"
},
{
"name": "CVE-2026-46318",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46318"
},
{
"name": "CVE-2026-46324",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46324"
},
{
"name": "CVE-2026-52932",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52932"
},
{
"name": "CVE-2026-52937",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52937"
},
{
"name": "CVE-2026-52949",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52949"
},
{
"name": "CVE-2026-52950",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52950"
},
{
"name": "CVE-2026-52951",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52951"
},
{
"name": "CVE-2026-52952",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52952"
},
{
"name": "CVE-2026-52953",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52953"
},
{
"name": "CVE-2026-52956",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52956"
},
{
"name": "CVE-2026-52959",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52959"
},
{
"name": "CVE-2026-52960",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52960"
},
{
"name": "CVE-2026-52961",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52961"
},
{
"name": "CVE-2026-52964",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52964"
},
{
"name": "CVE-2026-52965",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52965"
},
{
"name": "CVE-2026-52971",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52971"
},
{
"name": "CVE-2026-52973",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52973"
},
{
"name": "CVE-2026-52976",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52976"
},
{
"name": "CVE-2026-52978",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52978"
},
{
"name": "CVE-2026-52979",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52979"
},
{
"name": "CVE-2026-52980",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52980"
},
{
"name": "CVE-2026-52983",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52983"
},
{
"name": "CVE-2026-52987",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52987"
},
{
"name": "CVE-2026-52988",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52988"
},
{
"name": "CVE-2026-52990",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52990"
},
{
"name": "CVE-2026-52991",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52991"
},
{
"name": "CVE-2026-52994",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52994"
},
{
"name": "CVE-2026-52996",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52996"
},
{
"name": "CVE-2026-52997",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52997"
},
{
"name": "CVE-2026-53000",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53000"
},
{
"name": "CVE-2026-53005",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53005"
},
{
"name": "CVE-2026-53007",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53007"
},
{
"name": "CVE-2026-53008",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53008"
},
{
"name": "CVE-2026-53009",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53009"
},
{
"name": "CVE-2026-53010",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53010"
},
{
"name": "CVE-2026-53014",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53014"
},
{
"name": "CVE-2026-53015",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53015"
},
{
"name": "CVE-2026-53017",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53017"
},
{
"name": "CVE-2026-53018",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53018"
},
{
"name": "CVE-2026-53019",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53019"
},
{
"name": "CVE-2026-53020",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53020"
},
{
"name": "CVE-2026-53024",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53024"
},
{
"name": "CVE-2026-53025",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53025"
},
{
"name": "CVE-2026-53026",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53026"
},
{
"name": "CVE-2026-53027",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53027"
},
{
"name": "CVE-2026-53028",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53028"
},
{
"name": "CVE-2026-53029",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53029"
},
{
"name": "CVE-2026-53030",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53030"
},
{
"name": "CVE-2026-53031",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53031"
},
{
"name": "CVE-2026-53038",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53038"
},
{
"name": "CVE-2026-53042",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53042"
},
{
"name": "CVE-2026-53044",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53044"
},
{
"name": "CVE-2026-53051",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53051"
},
{
"name": "CVE-2026-53054",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53054"
},
{
"name": "CVE-2026-53055",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53055"
},
{
"name": "CVE-2026-53057",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53057"
},
{
"name": "CVE-2026-53067",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53067"
},
{
"name": "CVE-2026-53078",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53078"
},
{
"name": "CVE-2026-53079",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53079"
},
{
"name": "CVE-2026-53081",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53081"
},
{
"name": "CVE-2026-53083",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53083"
},
{
"name": "CVE-2026-53084",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53084"
},
{
"name": "CVE-2026-53085",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53085"
},
{
"name": "CVE-2026-53087",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53087"
},
{
"name": "CVE-2026-53089",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53089"
},
{
"name": "CVE-2026-53090",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53090"
},
{
"name": "CVE-2026-53091",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53091"
},
{
"name": "CVE-2026-53092",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53092"
},
{
"name": "CVE-2026-53095",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53095"
},
{
"name": "CVE-2026-53097",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53097"
},
{
"name": "CVE-2026-53098",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53098"
},
{
"name": "CVE-2026-53099",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53099"
},
{
"name": "CVE-2026-53100",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53100"
},
{
"name": "CVE-2026-53102",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53102"
},
{
"name": "CVE-2026-53103",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53103"
},
{
"name": "CVE-2026-53104",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53104"
},
{
"name": "CVE-2026-53105",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53105"
},
{
"name": "CVE-2026-53106",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53106"
},
{
"name": "CVE-2026-53107",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53107"
},
{
"name": "CVE-2026-53108",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53108"
},
{
"name": "CVE-2026-53109",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53109"
},
{
"name": "CVE-2026-53113",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53113"
},
{
"name": "CVE-2026-53114",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53114"
},
{
"name": "CVE-2026-53115",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53115"
},
{
"name": "CVE-2026-53116",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53116"
},
{
"name": "CVE-2026-53117",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53117"
},
{
"name": "CVE-2026-53118",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53118"
},
{
"name": "CVE-2026-53119",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53119"
},
{
"name": "CVE-2026-53120",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53120"
},
{
"name": "CVE-2026-53121",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53121"
},
{
"name": "CVE-2026-53123",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53123"
},
{
"name": "CVE-2026-53124",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53124"
},
{
"name": "CVE-2026-53125",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53125"
},
{
"name": "CVE-2026-53127",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53127"
},
{
"name": "CVE-2026-53129",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53129"
},
{
"name": "CVE-2026-53277",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53277"
},
{
"name": "CVE-2026-53278",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53278"
},
{
"name": "CVE-2026-53280",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53280"
},
{
"name": "CVE-2026-53282",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53282"
},
{
"name": "CVE-2026-53283",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53283"
},
{
"name": "CVE-2026-53284",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53284"
},
{
"name": "CVE-2026-53285",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53285"
},
{
"name": "CVE-2026-53286",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53286"
},
{
"name": "CVE-2026-53288",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53288"
},
{
"name": "CVE-2026-53290",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53290"
},
{
"name": "CVE-2026-53292",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53292"
},
{
"name": "CVE-2026-53297",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53297"
},
{
"name": "CVE-2026-53298",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53298"
},
{
"name": "CVE-2026-53299",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53299"
},
{
"name": "CVE-2026-53300",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53300"
},
{
"name": "CVE-2026-53301",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53301"
},
{
"name": "CVE-2026-53302",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53302"
},
{
"name": "CVE-2026-53305",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53305"
},
{
"name": "CVE-2026-53307",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53307"
},
{
"name": "CVE-2026-53308",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53308"
},
{
"name": "CVE-2026-53310",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53310"
},
{
"name": "CVE-2026-53311",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53311"
},
{
"name": "CVE-2026-53312",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53312"
},
{
"name": "CVE-2026-53313",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53313"
},
{
"name": "CVE-2026-53315",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53315"
},
{
"name": "CVE-2026-53316",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53316"
},
{
"name": "CVE-2026-53317",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53317"
},
{
"name": "CVE-2026-53318",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53318"
},
{
"name": "CVE-2026-53319",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53319"
},
{
"name": "CVE-2026-53321",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53321"
},
{
"name": "CVE-2026-53322",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53322"
},
{
"name": "CVE-2026-53323",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53323"
},
{
"name": "CVE-2026-53324",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53324"
},
{
"name": "CVE-2026-53358",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53358"
},
{
"name": "CVE-2026-53360",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53360"
},
{
"name": "CVE-2026-53364",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53364"
},
{
"name": "CVE-2026-53365",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53365"
},
{
"name": "CVE-2026-53367",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53367"
},
{
"name": "CVE-2026-53368",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53368"
},
{
"name": "CVE-2026-53369",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53369"
},
{
"name": "CVE-2026-53370",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53370"
},
{
"name": "CVE-2026-53371",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53371"
},
{
"name": "CVE-2026-53372",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53372"
},
{
"name": "CVE-2026-53373",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53373"
},
{
"name": "CVE-2026-53374",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53374"
},
{
"name": "CVE-2026-53375",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53375"
},
{
"name": "CVE-2026-53376",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53376"
},
{
"name": "CVE-2026-53377",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53377"
},
{
"name": "CVE-2026-53378",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53378"
},
{
"name": "CVE-2026-53379",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53379"
},
{
"name": "CVE-2026-53380",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53380"
},
{
"name": "CVE-2026-63837",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63837"
},
{
"name": "CVE-2026-63838",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63838"
},
{
"name": "CVE-2026-63839",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63839"
},
{
"name": "CVE-2026-63840",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63840"
},
{
"name": "CVE-2026-63841",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63841"
},
{
"name": "CVE-2026-63842",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63842"
},
{
"name": "CVE-2026-63843",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63843"
},
{
"name": "CVE-2026-63844",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63844"
},
{
"name": "CVE-2026-63845",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63845"
},
{
"name": "CVE-2026-63846",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63846"
},
{
"name": "CVE-2026-63847",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63847"
},
{
"name": "CVE-2026-63848",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63848"
},
{
"name": "CVE-2026-63849",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63849"
},
{
"name": "CVE-2026-63850",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63850"
},
{
"name": "CVE-2026-63851",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63851"
},
{
"name": "CVE-2026-63852",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63852"
},
{
"name": "CVE-2026-63853",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63853"
},
{
"name": "CVE-2026-63854",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63854"
},
{
"name": "CVE-2026-63855",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63855"
},
{
"name": "CVE-2026-63856",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63856"
},
{
"name": "CVE-2026-63857",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63857"
},
{
"name": "CVE-2026-63858",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63858"
},
{
"name": "CVE-2026-63859",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63859"
},
{
"name": "CVE-2026-63860",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63860"
},
{
"name": "CVE-2026-63861",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63861"
},
{
"name": "CVE-2026-63862",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63862"
},
{
"name": "CVE-2026-63863",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63863"
},
{
"name": "CVE-2026-63864",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63864"
},
{
"name": "CVE-2026-63865",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63865"
},
{
"name": "CVE-2026-63866",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63866"
},
{
"name": "CVE-2026-63875",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63875"
},
{
"name": "CVE-2026-63876",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63876"
},
{
"name": "CVE-2026-63877",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63877"
},
{
"name": "CVE-2026-63878",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63878"
},
{
"name": "CVE-2026-63879",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63879"
},
{
"name": "CVE-2026-63880",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63880"
},
{
"name": "CVE-2026-63881",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63881"
},
{
"name": "CVE-2026-63882",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63882"
},
{
"name": "CVE-2026-63883",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63883"
},
{
"name": "CVE-2026-63884",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63884"
},
{
"name": "CVE-2026-63886",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63886"
},
{
"name": "CVE-2026-63887",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63887"
},
{
"name": "CVE-2026-63888",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63888"
},
{
"name": "CVE-2026-63889",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63889"
},
{
"name": "CVE-2026-63890",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63890"
},
{
"name": "CVE-2026-63891",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63891"
},
{
"name": "CVE-2026-63892",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63892"
},
{
"name": "CVE-2026-63893",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63893"
},
{
"name": "CVE-2026-63894",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63894"
},
{
"name": "CVE-2026-63895",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63895"
},
{
"name": "CVE-2026-63896",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63896"
},
{
"name": "CVE-2026-63897",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63897"
},
{
"name": "CVE-2026-63898",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63898"
},
{
"name": "CVE-2026-63899",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63899"
},
{
"name": "CVE-2026-63900",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63900"
},
{
"name": "CVE-2026-63901",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63901"
},
{
"name": "CVE-2026-63902",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63902"
},
{
"name": "CVE-2026-63903",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63903"
},
{
"name": "CVE-2026-63904",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63904"
},
{
"name": "CVE-2026-63905",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63905"
},
{
"name": "CVE-2026-63906",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63906"
},
{
"name": "CVE-2026-63907",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63907"
},
{
"name": "CVE-2026-63908",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63908"
},
{
"name": "CVE-2026-63909",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63909"
},
{
"name": "CVE-2026-63910",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63910"
},
{
"name": "CVE-2026-63911",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63911"
},
{
"name": "CVE-2026-63912",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63912"
},
{
"name": "CVE-2026-63913",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63913"
},
{
"name": "CVE-2026-63914",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63914"
},
{
"name": "CVE-2026-63915",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63915"
},
{
"name": "CVE-2026-63916",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63916"
},
{
"name": "CVE-2026-63917",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63917"
},
{
"name": "CVE-2026-63918",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63918"
},
{
"name": "CVE-2026-63919",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63919"
},
{
"name": "CVE-2026-63920",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63920"
},
{
"name": "CVE-2026-63921",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63921"
},
{
"name": "CVE-2026-63922",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63922"
},
{
"name": "CVE-2026-63923",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63923"
},
{
"name": "CVE-2026-63924",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63924"
},
{
"name": "CVE-2026-63925",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63925"
},
{
"name": "CVE-2026-63926",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63926"
},
{
"name": "CVE-2026-63927",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63927"
},
{
"name": "CVE-2026-63928",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63928"
},
{
"name": "CVE-2026-63929",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63929"
},
{
"name": "CVE-2026-63930",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63930"
},
{
"name": "CVE-2026-63931",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63931"
},
{
"name": "CVE-2026-63932",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63932"
},
{
"name": "CVE-2026-63933",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63933"
},
{
"name": "CVE-2026-63934",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63934"
},
{
"name": "CVE-2026-63935",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63935"
},
{
"name": "CVE-2026-63936",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63936"
},
{
"name": "CVE-2026-63937",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63937"
},
{
"name": "CVE-2026-63938",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63938"
},
{
"name": "CVE-2026-63939",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63939"
},
{
"name": "CVE-2026-63940",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63940"
},
{
"name": "CVE-2026-63941",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63941"
},
{
"name": "CVE-2026-63942",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63942"
},
{
"name": "CVE-2026-63943",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63943"
},
{
"name": "CVE-2026-63944",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63944"
},
{
"name": "CVE-2026-63945",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63945"
},
{
"name": "CVE-2026-63946",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63946"
},
{
"name": "CVE-2026-63947",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63947"
},
{
"name": "CVE-2026-63948",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63948"
},
{
"name": "CVE-2026-63949",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63949"
},
{
"name": "CVE-2026-63950",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63950"
},
{
"name": "CVE-2026-63951",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63951"
},
{
"name": "CVE-2026-63952",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63952"
},
{
"name": "CVE-2026-63953",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63953"
},
{
"name": "CVE-2026-63954",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63954"
},
{
"name": "CVE-2026-63955",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63955"
},
{
"name": "CVE-2026-63956",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63956"
},
{
"name": "CVE-2026-63957",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63957"
},
{
"name": "CVE-2026-63958",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63958"
},
{
"name": "CVE-2026-63959",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63959"
},
{
"name": "CVE-2026-63960",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63960"
},
{
"name": "CVE-2026-63961",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63961"
},
{
"name": "CVE-2026-63962",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63962"
},
{
"name": "CVE-2026-63963",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63963"
},
{
"name": "CVE-2026-63964",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63964"
},
{
"name": "CVE-2026-63965",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63965"
},
{
"name": "CVE-2026-63966",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63966"
},
{
"name": "CVE-2026-63967",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63967"
},
{
"name": "CVE-2026-63968",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63968"
},
{
"name": "CVE-2026-63969",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63969"
},
{
"name": "CVE-2026-63970",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63970"
},
{
"name": "CVE-2026-63971",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63971"
},
{
"name": "CVE-2026-63972",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63972"
},
{
"name": "CVE-2026-63973",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63973"
},
{
"name": "CVE-2026-63974",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63974"
},
{
"name": "CVE-2026-63975",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63975"
},
{
"name": "CVE-2026-63976",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63976"
},
{
"name": "CVE-2026-63977",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63977"
},
{
"name": "CVE-2026-63978",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63978"
},
{
"name": "CVE-2026-63979",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63979"
},
{
"name": "CVE-2026-63980",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63980"
},
{
"name": "CVE-2026-63981",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63981"
},
{
"name": "CVE-2026-63982",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63982"
},
{
"name": "CVE-2026-63983",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63983"
},
{
"name": "CVE-2026-63984",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63984"
},
{
"name": "CVE-2026-63985",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63985"
},
{
"name": "CVE-2026-63986",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63986"
},
{
"name": "CVE-2026-63987",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63987"
},
{
"name": "CVE-2026-63988",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63988"
},
{
"name": "CVE-2026-63989",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63989"
},
{
"name": "CVE-2026-63990",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63990"
},
{
"name": "CVE-2026-63991",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63991"
},
{
"name": "CVE-2026-63992",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63992"
},
{
"name": "CVE-2026-63993",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63993"
},
{
"name": "CVE-2026-63994",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63994"
},
{
"name": "CVE-2026-63995",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63995"
},
{
"name": "CVE-2026-63996",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63996"
},
{
"name": "CVE-2026-63997",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63997"
},
{
"name": "CVE-2026-63998",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63998"
},
{
"name": "CVE-2026-63999",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63999"
},
{
"name": "CVE-2026-64000",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64000"
},
{
"name": "CVE-2026-64001",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64001"
},
{
"name": "CVE-2026-64002",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64002"
},
{
"name": "CVE-2026-64003",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64003"
},
{
"name": "CVE-2026-64004",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64004"
},
{
"name": "CVE-2026-64005",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64005"
},
{
"name": "CVE-2026-64006",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64006"
},
{
"name": "CVE-2026-64007",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64007"
},
{
"name": "CVE-2026-64008",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64008"
},
{
"name": "CVE-2026-64009",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64009"
},
{
"name": "CVE-2026-64010",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64010"
},
{
"name": "CVE-2026-64011",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64011"
},
{
"name": "CVE-2026-64012",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64012"
},
{
"name": "CVE-2026-64013",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64013"
},
{
"name": "CVE-2026-64014",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64014"
},
{
"name": "CVE-2026-64015",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64015"
},
{
"name": "CVE-2026-64017",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64017"
},
{
"name": "CVE-2026-64018",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64018"
},
{
"name": "CVE-2026-64019",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64019"
},
{
"name": "CVE-2026-64020",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64020"
},
{
"name": "CVE-2026-64021",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64021"
},
{
"name": "CVE-2026-64022",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64022"
},
{
"name": "CVE-2026-64023",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64023"
},
{
"name": "CVE-2026-64024",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64024"
},
{
"name": "CVE-2026-64025",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64025"
},
{
"name": "CVE-2026-64026",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64026"
},
{
"name": "CVE-2026-64027",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64027"
},
{
"name": "CVE-2026-64029",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64029"
},
{
"name": "CVE-2026-64030",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64030"
},
{
"name": "CVE-2026-64031",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64031"
},
{
"name": "CVE-2026-64032",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64032"
},
{
"name": "CVE-2026-64033",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64033"
},
{
"name": "CVE-2026-64034",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64034"
},
{
"name": "CVE-2026-64035",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64035"
},
{
"name": "CVE-2026-64036",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64036"
},
{
"name": "CVE-2026-64037",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64037"
},
{
"name": "CVE-2026-64038",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64038"
},
{
"name": "CVE-2026-64039",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64039"
},
{
"name": "CVE-2026-64040",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64040"
},
{
"name": "CVE-2026-64041",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64041"
},
{
"name": "CVE-2026-64042",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64042"
},
{
"name": "CVE-2026-64043",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64043"
},
{
"name": "CVE-2026-64044",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64044"
},
{
"name": "CVE-2026-64045",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64045"
},
{
"name": "CVE-2026-64046",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64046"
},
{
"name": "CVE-2026-64047",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64047"
},
{
"name": "CVE-2026-64048",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64048"
},
{
"name": "CVE-2026-64049",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64049"
},
{
"name": "CVE-2026-64050",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64050"
},
{
"name": "CVE-2026-64051",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64051"
},
{
"name": "CVE-2026-64052",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64052"
},
{
"name": "CVE-2026-64053",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64053"
},
{
"name": "CVE-2026-64054",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64054"
},
{
"name": "CVE-2026-64055",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64055"
},
{
"name": "CVE-2026-64056",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64056"
},
{
"name": "CVE-2026-64057",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64057"
},
{
"name": "CVE-2026-64058",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64058"
},
{
"name": "CVE-2026-64059",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64059"
},
{
"name": "CVE-2026-64060",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64060"
},
{
"name": "CVE-2026-64061",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64061"
},
{
"name": "CVE-2026-64062",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64062"
},
{
"name": "CVE-2026-64063",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64063"
},
{
"name": "CVE-2026-64064",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64064"
},
{
"name": "CVE-2026-64065",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64065"
},
{
"name": "CVE-2026-64066",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64066"
},
{
"name": "CVE-2026-64067",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64067"
},
{
"name": "CVE-2026-64068",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64068"
},
{
"name": "CVE-2026-64069",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64069"
},
{
"name": "CVE-2026-64070",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64070"
},
{
"name": "CVE-2026-64071",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64071"
},
{
"name": "CVE-2026-64072",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64072"
},
{
"name": "CVE-2026-64073",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64073"
},
{
"name": "CVE-2026-64074",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64074"
},
{
"name": "CVE-2026-64075",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64075"
},
{
"name": "CVE-2026-64076",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64076"
},
{
"name": "CVE-2026-64077",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64077"
},
{
"name": "CVE-2026-64078",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64078"
},
{
"name": "CVE-2026-64079",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64079"
},
{
"name": "CVE-2026-64080",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64080"
},
{
"name": "CVE-2026-64081",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64081"
},
{
"name": "CVE-2026-64082",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64082"
},
{
"name": "CVE-2026-64083",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64083"
},
{
"name": "CVE-2026-64084",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64084"
},
{
"name": "CVE-2026-64085",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64085"
},
{
"name": "CVE-2026-64086",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64086"
},
{
"name": "CVE-2026-64087",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64087"
},
{
"name": "CVE-2026-64088",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64088"
},
{
"name": "CVE-2026-64089",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64089"
},
{
"name": "CVE-2026-64090",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64090"
},
{
"name": "CVE-2026-64091",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64091"
},
{
"name": "CVE-2026-64093",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64093"
},
{
"name": "CVE-2026-64094",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64094"
},
{
"name": "CVE-2026-64095",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64095"
},
{
"name": "CVE-2026-64096",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64096"
},
{
"name": "CVE-2026-64097",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64097"
},
{
"name": "CVE-2026-64098",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64098"
},
{
"name": "CVE-2026-64099",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64099"
},
{
"name": "CVE-2026-64100",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64100"
},
{
"name": "CVE-2026-64101",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64101"
},
{
"name": "CVE-2026-64102",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64102"
},
{
"name": "CVE-2026-64103",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64103"
},
{
"name": "CVE-2026-64104",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64104"
},
{
"name": "CVE-2026-64105",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64105"
},
{
"name": "CVE-2026-64106",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64106"
},
{
"name": "CVE-2026-64107",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64107"
},
{
"name": "CVE-2026-64108",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64108"
},
{
"name": "CVE-2026-64109",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64109"
},
{
"name": "CVE-2026-64110",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64110"
},
{
"name": "CVE-2026-64111",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64111"
},
{
"name": "CVE-2026-64112",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64112"
},
{
"name": "CVE-2026-64113",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64113"
},
{
"name": "CVE-2026-64114",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64114"
},
{
"name": "CVE-2026-64115",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64115"
},
{
"name": "CVE-2026-64116",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64116"
},
{
"name": "CVE-2026-64117",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64117"
},
{
"name": "CVE-2026-64118",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64118"
},
{
"name": "CVE-2026-64119",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64119"
},
{
"name": "CVE-2026-64120",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64120"
},
{
"name": "CVE-2026-64121",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64121"
},
{
"name": "CVE-2026-64122",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64122"
},
{
"name": "CVE-2026-64123",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64123"
},
{
"name": "CVE-2026-64124",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64124"
},
{
"name": "CVE-2026-64125",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64125"
},
{
"name": "CVE-2026-64126",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64126"
},
{
"name": "CVE-2026-64127",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64127"
},
{
"name": "CVE-2026-64128",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64128"
},
{
"name": "CVE-2026-64129",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64129"
},
{
"name": "CVE-2026-64130",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64130"
},
{
"name": "CVE-2026-64131",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64131"
},
{
"name": "CVE-2026-64132",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64132"
},
{
"name": "CVE-2026-64133",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64133"
},
{
"name": "CVE-2026-64134",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64134"
},
{
"name": "CVE-2026-64135",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64135"
},
{
"name": "CVE-2026-64136",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64136"
},
{
"name": "CVE-2026-64137",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64137"
},
{
"name": "CVE-2026-64138",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64138"
},
{
"name": "CVE-2026-64139",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64139"
},
{
"name": "CVE-2026-64140",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64140"
},
{
"name": "CVE-2026-64141",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64141"
},
{
"name": "CVE-2026-64142",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64142"
},
{
"name": "CVE-2026-64143",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64143"
},
{
"name": "CVE-2026-64144",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64144"
},
{
"name": "CVE-2026-64145",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64145"
},
{
"name": "CVE-2026-64146",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64146"
},
{
"name": "CVE-2026-64147",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64147"
},
{
"name": "CVE-2026-64148",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64148"
},
{
"name": "CVE-2026-64149",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64149"
},
{
"name": "CVE-2026-64150",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64150"
},
{
"name": "CVE-2026-64151",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64151"
},
{
"name": "CVE-2026-64152",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64152"
},
{
"name": "CVE-2026-64153",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64153"
},
{
"name": "CVE-2026-64154",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64154"
},
{
"name": "CVE-2026-64155",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64155"
},
{
"name": "CVE-2026-64156",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64156"
},
{
"name": "CVE-2026-64157",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64157"
},
{
"name": "CVE-2026-64158",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64158"
},
{
"name": "CVE-2026-64159",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64159"
},
{
"name": "CVE-2026-64160",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64160"
},
{
"name": "CVE-2026-64161",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64161"
},
{
"name": "CVE-2026-64162",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64162"
},
{
"name": "CVE-2026-64163",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64163"
},
{
"name": "CVE-2026-64164",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64164"
},
{
"name": "CVE-2026-64165",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64165"
},
{
"name": "CVE-2026-64166",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64166"
},
{
"name": "CVE-2026-64167",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64167"
},
{
"name": "CVE-2026-64168",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64168"
},
{
"name": "CVE-2026-64169",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64169"
},
{
"name": "CVE-2026-64170",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64170"
},
{
"name": "CVE-2026-64171",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64171"
},
{
"name": "CVE-2026-64172",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64172"
},
{
"name": "CVE-2026-64173",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64173"
},
{
"name": "CVE-2026-64174",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64174"
},
{
"name": "CVE-2026-64175",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64175"
},
{
"name": "CVE-2026-64176",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64176"
},
{
"name": "CVE-2026-64177",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64177"
},
{
"name": "CVE-2026-64178",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64178"
},
{
"name": "CVE-2026-64179",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64179"
},
{
"name": "CVE-2026-64180",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64180"
},
{
"name": "CVE-2026-64181",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64181"
},
{
"name": "CVE-2026-64182",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64182"
},
{
"name": "CVE-2026-64183",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64183"
},
{
"name": "CVE-2026-64184",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64184"
},
{
"name": "CVE-2026-64185",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64185"
},
{
"name": "CVE-2026-64186",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64186"
},
{
"name": "CVE-2026-64519",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64519"
},
{
"name": "CVE-2026-64520",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64520"
},
{
"name": "CVE-2026-64521",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64521"
},
{
"name": "CVE-2026-64522",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64522"
},
{
"name": "CVE-2026-64523",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64523"
},
{
"name": "CVE-2026-64524",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64524"
},
{
"name": "CVE-2026-64525",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64525"
},
{
"name": "CVE-2026-64526",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64526"
},
{
"name": "CVE-2026-64527",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64527"
},
{
"name": "CVE-2026-64528",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64528"
}
],
"initial_release_date": "2026-07-31T00:00:00",
"last_revision_date": "2026-07-31T00:00:00",
"links": [],
"reference": "CERTFR-2026-AVI-0954",
"revisions": [
{
"description": "Version initiale",
"revision_date": "2026-07-31T00:00:00.000000"
}
],
"risks": [
{
"description": "Atteinte \u00e0 l\u0027int\u00e9grit\u00e9 des donn\u00e9es"
},
{
"description": "Non sp\u00e9cifi\u00e9 par l\u0027\u00e9diteur"
},
{
"description": "Contournement de la politique de s\u00e9curit\u00e9"
},
{
"description": "Atteinte \u00e0 la confidentialit\u00e9 des donn\u00e9es"
},
{
"description": "\u00c9l\u00e9vation de privil\u00e8ges"
}
],
"summary": "De multiples vuln\u00e9rabilit\u00e9s ont \u00e9t\u00e9 d\u00e9couvertes dans le noyau Linux d\u0027Ubuntu. Certaines d\u0027entre elles permettent \u00e0 un attaquant de provoquer une \u00e9l\u00e9vation de privil\u00e8ges, une atteinte \u00e0 la confidentialit\u00e9 des donn\u00e9es et une atteinte \u00e0 l\u0027int\u00e9grit\u00e9 des donn\u00e9es.",
"title": "Multiples vuln\u00e9rabilit\u00e9s dans le noyau Linux d\u0027Ubuntu",
"vendor_advisories": [
{
"published_at": "2026-07-29",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8622-1",
"url": "https://ubuntu.com/security/notices/USN-8622-1"
},
{
"published_at": "2026-07-28",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8620-1",
"url": "https://ubuntu.com/security/notices/USN-8620-1"
},
{
"published_at": "2026-07-24",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8604-1",
"url": "https://ubuntu.com/security/notices/USN-8604-1"
},
{
"published_at": "2026-07-28",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8615-1",
"url": "https://ubuntu.com/security/notices/USN-8615-1"
},
{
"published_at": "2026-07-28",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8574-3",
"url": "https://ubuntu.com/security/notices/USN-8574-3"
},
{
"published_at": "2026-07-28",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8619-1",
"url": "https://ubuntu.com/security/notices/USN-8619-1"
},
{
"published_at": "2026-07-24",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8595-2",
"url": "https://ubuntu.com/security/notices/USN-8595-2"
},
{
"published_at": "2026-07-28",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8570-2",
"url": "https://ubuntu.com/security/notices/USN-8570-2"
},
{
"published_at": "2026-07-29",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8623-1",
"url": "https://ubuntu.com/security/notices/USN-8623-1"
},
{
"published_at": "2026-07-24",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8575-3",
"url": "https://ubuntu.com/security/notices/USN-8575-3"
},
{
"published_at": "2026-07-24",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8608-1",
"url": "https://ubuntu.com/security/notices/USN-8608-1"
},
{
"published_at": "2026-07-28",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8547-2",
"url": "https://ubuntu.com/security/notices/USN-8547-2"
},
{
"published_at": "2026-07-29",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8615-2",
"url": "https://ubuntu.com/security/notices/USN-8615-2"
},
{
"published_at": "2026-07-28",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8618-1",
"url": "https://ubuntu.com/security/notices/USN-8618-1"
},
{
"published_at": "2026-07-28",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8617-1",
"url": "https://ubuntu.com/security/notices/USN-8617-1"
},
{
"published_at": "2026-07-24",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8609-1",
"url": "https://ubuntu.com/security/notices/USN-8609-1"
},
{
"published_at": "2026-07-24",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8607-1",
"url": "https://ubuntu.com/security/notices/USN-8607-1"
},
{
"published_at": "2026-07-28",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8595-3",
"url": "https://ubuntu.com/security/notices/USN-8595-3"
},
{
"published_at": "2026-07-24",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8605-1",
"url": "https://ubuntu.com/security/notices/USN-8605-1"
},
{
"published_at": "2026-07-28",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8616-1",
"url": "https://ubuntu.com/security/notices/USN-8616-1"
},
{
"published_at": "2026-07-24",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8603-1",
"url": "https://ubuntu.com/security/notices/USN-8603-1"
},
{
"published_at": "2026-07-29",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8620-2",
"url": "https://ubuntu.com/security/notices/USN-8620-2"
},
{
"published_at": "2026-07-24",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8610-1",
"url": "https://ubuntu.com/security/notices/USN-8610-1"
},
{
"published_at": "2026-07-24",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8606-1",
"url": "https://ubuntu.com/security/notices/USN-8606-1"
}
]
}
FKIE_CVE-2026-46028
Vulnerability from fkie_nvd - Published: 2026-05-27 14:17 - Updated: 2026-06-17 10:52| URL | Tags | ||
|---|---|---|---|
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/08ea39a556ecd39b33c2b4888861001c6706a62e | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/3d72f8c6490dc79210b64270740cb2a8619361a4 | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/46fdb39e83227b5d39f7c934a0947ea913f13c18 | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/5aa58c3a572b3e3b6c786953339f7978b845cc52 | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/a920cabdb0b7cf1f4e11a20524253ae5bd09092b | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/c2138c9bd02af19e0b407376140cd5435b0d81da | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/ebc235675f24b0e3f8bc92b8419471d42f837d8f | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/fa0fcec9b49d58e71df7ede91ecd86855f608e85 | Patch |
| Vendor | Product | Version | |
|---|---|---|---|
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * |
{
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"crypto/algif_aead.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "08ea39a556ecd39b33c2b4888861001c6706a62e",
"status": "affected",
"version": "d887c52d6ae43aeebd249b5f2f1333e60236aa60",
"versionType": "git"
},
{
"lessThan": "a920cabdb0b7cf1f4e11a20524253ae5bd09092b",
"status": "affected",
"version": "d887c52d6ae43aeebd249b5f2f1333e60236aa60",
"versionType": "git"
},
{
"lessThan": "fa0fcec9b49d58e71df7ede91ecd86855f608e85",
"status": "affected",
"version": "d887c52d6ae43aeebd249b5f2f1333e60236aa60",
"versionType": "git"
},
{
"lessThan": "c2138c9bd02af19e0b407376140cd5435b0d81da",
"status": "affected",
"version": "d887c52d6ae43aeebd249b5f2f1333e60236aa60",
"versionType": "git"
},
{
"lessThan": "46fdb39e83227b5d39f7c934a0947ea913f13c18",
"status": "affected",
"version": "d887c52d6ae43aeebd249b5f2f1333e60236aa60",
"versionType": "git"
},
{
"lessThan": "ebc235675f24b0e3f8bc92b8419471d42f837d8f",
"status": "affected",
"version": "d887c52d6ae43aeebd249b5f2f1333e60236aa60",
"versionType": "git"
},
{
"lessThan": "3d72f8c6490dc79210b64270740cb2a8619361a4",
"status": "affected",
"version": "d887c52d6ae43aeebd249b5f2f1333e60236aa60",
"versionType": "git"
},
{
"lessThan": "5aa58c3a572b3e3b6c786953339f7978b845cc52",
"status": "affected",
"version": "d887c52d6ae43aeebd249b5f2f1333e60236aa60",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"crypto/algif_aead.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "4.14"
},
{
"lessThan": "4.14",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.254",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.204",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.170",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.137",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.85",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.18.*",
"status": "unaffected",
"version": "6.18.27",
"versionType": "semver"
},
{
"lessThanOrEqual": "7.0.*",
"status": "unaffected",
"version": "7.0.4",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "7.1",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"configurations": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "24B62F9A-357D-465D-97EB-2819B1CD663C",
"versionEndExcluding": "5.10.254",
"versionStartIncluding": "4.14",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "FA800016-0012-4E3F-A528-2A7F378A0A4A",
"versionEndExcluding": "5.15.204",
"versionStartIncluding": "5.11",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "E6653854-B188-42DD-B8C5-0143F1956AB1",
"versionEndExcluding": "6.1.170",
"versionStartIncluding": "5.16",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "3CA3EF52-168A-4348-8F5F-356C9EB69261",
"versionEndExcluding": "6.6.137",
"versionStartIncluding": "6.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "F17D292D-A9B5-4DC7-8002-51AB95335606",
"versionEndExcluding": "6.12.85",
"versionStartIncluding": "6.7",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "A10AC84F-C058-47D5-85B4-E6E51A613B74",
"versionEndExcluding": "6.18.27",
"versionStartIncluding": "6.13",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "CDB78D6D-22C3-4154-B0D0-94AF1CE5C2E3",
"versionEndExcluding": "7.0.4",
"versionStartIncluding": "6.19",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: algif_aead - snapshot IV for async AEAD requests\n\nAF_ALG AEAD AIO requests currently use the socket-wide IV buffer during\nrequest processing. For async requests, later socket activity can\nupdate that shared state before the original request has fully\ncompleted, which can lead to inconsistent IV handling.\n\nSnapshot the IV into per-request storage when preparing the AEAD\nrequest, so in-flight operations no longer depend on mutable socket\nstate."
}
],
"id": "CVE-2026-46028",
"lastModified": "2026-06-17T10:52:55.603",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 5.5,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 3.6,
"source": "nvd@nist.gov",
"type": "Primary"
}
]
},
"published": "2026-05-27T14:17:21.420",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/08ea39a556ecd39b33c2b4888861001c6706a62e"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/3d72f8c6490dc79210b64270740cb2a8619361a4"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/46fdb39e83227b5d39f7c934a0947ea913f13c18"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/5aa58c3a572b3e3b6c786953339f7978b845cc52"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/a920cabdb0b7cf1f4e11a20524253ae5bd09092b"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/c2138c9bd02af19e0b407376140cd5435b0d81da"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/ebc235675f24b0e3f8bc92b8419471d42f837d8f"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/fa0fcec9b49d58e71df7ede91ecd86855f608e85"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Analyzed",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "NVD-CWE-noinfo"
}
],
"source": "nvd@nist.gov",
"type": "Primary"
}
]
}
GHSA-MCP6-P965-Q62G
Vulnerability from github – Published: 2026-05-27 15:33 – Updated: 2026-06-16 18:32In the Linux kernel, the following vulnerability has been resolved:
crypto: algif_aead - snapshot IV for async AEAD requests
AF_ALG AEAD AIO requests currently use the socket-wide IV buffer during request processing. For async requests, later socket activity can update that shared state before the original request has fully completed, which can lead to inconsistent IV handling.
Snapshot the IV into per-request storage when preparing the AEAD request, so in-flight operations no longer depend on mutable socket state.
{
"affected": [],
"aliases": [
"CVE-2026-46028"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-27T14:17:21Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: algif_aead - snapshot IV for async AEAD requests\n\nAF_ALG AEAD AIO requests currently use the socket-wide IV buffer during\nrequest processing. For async requests, later socket activity can\nupdate that shared state before the original request has fully\ncompleted, which can lead to inconsistent IV handling.\n\nSnapshot the IV into per-request storage when preparing the AEAD\nrequest, so in-flight operations no longer depend on mutable socket\nstate.",
"id": "GHSA-mcp6-p965-q62g",
"modified": "2026-06-16T18:32:28Z",
"published": "2026-05-27T15:33:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46028"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/08ea39a556ecd39b33c2b4888861001c6706a62e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3d72f8c6490dc79210b64270740cb2a8619361a4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/46fdb39e83227b5d39f7c934a0947ea913f13c18"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5aa58c3a572b3e3b6c786953339f7978b845cc52"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a920cabdb0b7cf1f4e11a20524253ae5bd09092b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c2138c9bd02af19e0b407376140cd5435b0d81da"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ebc235675f24b0e3f8bc92b8419471d42f837d8f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fa0fcec9b49d58e71df7ede91ecd86855f608e85"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
OESA-2026-2673 (CVE-2021-47237)
Vulnerability from osv_openeuler – Published: 2026-06-12 11:11 – Updated: 2026-08-06 11:11 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
net: hamradio: fix memory leak in mkiss_close
My local syzbot instance hit memory leak in mkiss_open()[1]. The problem was in missing free_netdev() in mkiss_close().
In mkiss_open() netdevice is allocated and then registered, but in mkiss_close() netdevice was only unregistered, but not freed.
Fail log:
BUG: memory leak unreferenced object 0xffff8880281ba000 (size 4096): comm "syz-executor.1", pid 11443, jiffies 4295046091 (age 17.660s) hex dump (first 32 bytes): 61 78 30 00 00 00 00 00 00 00 00 00 00 00 00 00 ax0............. 00 27 fa 2a 80 88 ff ff 00 00 00 00 00 00 00 00 .'.*............ backtrace: [<ffffffff81a27201>] kvmalloc_node+0x61/0xf0 [<ffffffff8706e7e8>] alloc_netdev_mqs+0x98/0xe80 [<ffffffff84e64192>] mkiss_open+0xb2/0x6f0 [1] [<ffffffff842355db>] tty_ldisc_open+0x9b/0x110 [<ffffffff84236488>] tty_set_ldisc+0x2e8/0x670 [<ffffffff8421f7f3>] tty_ioctl+0xda3/0x1440 [<ffffffff81c9f273>] __x64_sys_ioctl+0x193/0x200 [<ffffffff8911263a>] do_syscall_64+0x3a/0xb0 [<ffffffff89200068>] entry_SYSCALL_64_after_hwframe+0x44/0xae
BUG: memory leak unreferenced object 0xffff8880141a9a00 (size 96): comm "syz-executor.1", pid 11443, jiffies 4295046091 (age 17.660s) hex dump (first 32 bytes): e8 a2 1b 28 80 88 ff ff e8 a2 1b 28 80 88 ff ff ...(.......(.... 98 92 9c aa b0 40 02 00 00 00 00 00 00 00 00 00 .....@.......... backtrace: [<ffffffff8709f68b>] __hw_addr_create_ex+0x5b/0x310 [<ffffffff8709fb38>] __hw_addr_add_ex+0x1f8/0x2b0 [<ffffffff870a0c7b>] dev_addr_init+0x10b/0x1f0 [<ffffffff8706e88b>] alloc_netdev_mqs+0x13b/0xe80 [<ffffffff84e64192>] mkiss_open+0xb2/0x6f0 [1] [<ffffffff842355db>] tty_ldisc_open+0x9b/0x110 [<ffffffff84236488>] tty_set_ldisc+0x2e8/0x670 [<ffffffff8421f7f3>] tty_ioctl+0xda3/0x1440 [<ffffffff81c9f273>] __x64_sys_ioctl+0x193/0x200 [<ffffffff8911263a>] do_syscall_64+0x3a/0xb0 [<ffffffff89200068>] entry_SYSCALL_64_after_hwframe+0x44/0xae
BUG: memory leak unreferenced object 0xffff8880219bfc00 (size 512): comm "syz-executor.1", pid 11443, jiffies 4295046091 (age 17.660s) hex dump (first 32 bytes): 00 a0 1b 28 80 88 ff ff 80 8f b1 8d ff ff ff ff ...(............ 80 8f b1 8d ff ff ff ff 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffff81a27201>] kvmalloc_node+0x61/0xf0 [<ffffffff8706eec7>] alloc_netdev_mqs+0x777/0xe80 [<ffffffff84e64192>] mkiss_open+0xb2/0x6f0 [1] [<ffffffff842355db>] tty_ldisc_open+0x9b/0x110 [<ffffffff84236488>] tty_set_ldisc+0x2e8/0x670 [<ffffffff8421f7f3>] tty_ioctl+0xda3/0x1440 [<ffffffff81c9f273>] __x64_sys_ioctl+0x193/0x200 [<ffffffff8911263a>] do_syscall_64+0x3a/0xb0 [<ffffffff89200068>] entry_SYSCALL_64_after_hwframe+0x44/0xae
BUG: memory leak unreferenced object 0xffff888029b2b200 (size 256): comm "syz-executor.1", pid 11443, jiffies 4295046091 (age 17.660s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffff81a27201>] kvmalloc_node+0x61/0xf0 [<ffffffff8706f062>] alloc_netdev_mqs+0x912/0xe80 [<ffffffff84e64192>] mkiss_open+0xb2/0x6f0 [1] [<ffffffff842355db>] tty_ldisc_open+0x9b/0x110 [<ffffffff84236488>] tty_set_ldisc+0x2e8/0x670 [<ffffffff8421f7f3>] tty_ioctl+0xda3/0x1440 [<ffffffff81c9f273>] __x64_sys_ioctl+0x193/0x200 [<ffffffff8911263a>] do_syscall_64+0x3a/0xb0 [<ffffffff89200068>] entry_SYSCALL_64_after_hwframe+0x44/0xae(CVE-2021-47237)
In the Linux kernel, the following vulnerability has been resolved:
IB/mlx5: Fix initializing CQ fragments buffer
The function init_cq_frag_buf() can be called to initialize the current CQ fragments buffer cq->buf, or the temporary cq->resize_buf that is filled during CQ resize operation.
However, the offending commit started to use function get_cqe() for getting the CQEs, the issue with this change is that get_cqe() always returns CQEs from cq->buf, which leads us to initialize the wrong buffer, and in case of enlarging the CQ we try to access elements beyond the size of the current cq->buf and eventually hit a kernel panic.
[exception RIP: init_cq_frag_buf+103] [ffff9f799ddcbcd8] mlx5_ib_resize_cq at ffffffffc0835d60 [mlx5_ib] [ffff9f799ddcbdb0] ib_resize_cq at ffffffffc05270df [ib_core] [ffff9f799ddcbdc0] llt_rdma_setup_qp at ffffffffc0a6a712 [llt] [ffff9f799ddcbe10] llt_rdma_cc_event_action at ffffffffc0a6b411 [llt] [ffff9f799ddcbe98] llt_rdma_client_conn_thread at ffffffffc0a6bb75 [llt] [ffff9f799ddcbec8] kthread at ffffffffa66c5da1 [ffff9f799ddcbf50] ret_from_fork_nospec_begin at ffffffffa6d95ddd
Fix it by getting the needed CQE by calling mlx5_frag_buf_get_wqe() that takes the correct source buffer as a parameter.(CVE-2021-47261)
In the Linux kernel, the following vulnerability has been resolved:
smackfs: restrict bytes count in smk_set_cipso()
Oops, I failed to update subject line.
From 07571157c91b98ce1a4aa70967531e64b78e8346 Mon Sep 17 00:00:00 2001 Date: Mon, 12 Apr 2021 22:25:06 +0900 Subject: [PATCH] smackfs: restrict bytes count in smk_set_cipso()
Commit 7ef4c19d245f3dc2 ("smackfs: restrict bytes count in smackfs write functions") missed that count > SMK_CIPSOMAX check applies to only format == SMK_FIXED24_FMT case.(CVE-2021-47336)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/cma: Fix rdma_resolve_route() memory leak
Fix a memory leak when "mda_resolve_route() is called more than once on the same "rdma_cm_id".
This is possible if cma_query_handler() triggers the RDMA_CM_EVENT_ROUTE_ERROR flow which puts the state machine back and allows rdma_resolve_route() to be called again.(CVE-2021-47345)
In the Linux kernel, the following vulnerability has been resolved:
i40e: Fix NULL pointer dereference in i40e_dbg_dump_desc
When trying to dump VFs VSI RX/TX descriptors using debugfs there was a crash due to NULL pointer dereference in i40e_dbg_dump_desc. Added a check to i40e_dbg_dump_desc that checks if VSI type is correct for dumping RX/TX descriptors.(CVE-2021-47501)
In the Linux kernel, the following vulnerability has been resolved:
can: pch_can: pch_can_rx_normal: fix use after free
After calling netif_receive_skb(skb), dereferencing skb is unsafe. Especially, the can_frame cf which aliases skb memory is dereferenced just after the call netif_receive_skb(skb).
Reordering the lines solves the issue.(CVE-2021-47520)
In the Linux kernel, the following vulnerability has been resolved:
ALSA: hda: Fix possible null-ptr-deref when assigning a stream
While AudioDSP drivers assign streams exclusively of HOST or LINK type, nothing blocks a user to attempt to assign a COUPLED stream. As supplied substream instance may be a stub, what is the case when code-loading, such scenario ends with null-ptr-deref.(CVE-2023-52806)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: complete validation of user input
In my recent commit, I missed that do_replace() handlers use copy_from_sockptr() (which I fixed), followed by unsafe copy_from_sockptr_offset() calls.
In all functions, we can perform the @optlen validation before even calling xt_alloc_table_info() with the following check:
if ((u64)optlen < (u64)tmp.size + sizeof(tmp)) return -EINVAL;(CVE-2024-35962)
In the Linux kernel, the following vulnerability has been resolved:
crypto: algif_aead - Fix minimum RX size check for decryption
The check for the minimum receive buffer size did not take the tag size into account during decryption. Fix this by adding the required extra length.(CVE-2026-43077)
In the Linux kernel, the following vulnerability has been resolved:
crypto: af_alg - Fix page reassignment overflow in af_alg_pull_tsgl
When page reassignment was added to af_alg_pull_tsgl the original loop wasn't updated so it may try to reassign one more page than necessary.
Add the check to the reassignment so that this does not happen.
Also update the comment which still refers to the obsolete offset argument.(CVE-2026-43078)
In the Linux kernel, the following vulnerability has been resolved:
PCI: Fix pci_slot_trylock() error handling
Commit a4e772898f8b ("PCI: Add missing bridge lock to pci_bus_lock()") delegates the bridge device's pci_dev_trylock() to pci_bus_trylock() in pci_slot_trylock(), but it forgets to remove the corresponding pci_dev_unlock() when pci_bus_trylock() fails.
Before a4e772898f8b, the code did:
if (!pci_dev_trylock(dev)) / <- lock bridge device / goto unlock; if (dev->subordinate) { if (!pci_bus_trylock(dev->subordinate)) { pci_dev_unlock(dev); / <- unlock bridge device / goto unlock; } }
After a4e772898f8b the bridge-device lock is no longer taken, but the pci_dev_unlock(dev) on the failure path was left in place, leading to the bug.
This yields one of two errors:
- A warning that the lock is being unlocked when no one holds it.
- An incorrect unlock of a lock that belongs to another thread.
Fix it by removing the now-redundant pci_dev_unlock(dev) on the failure path.
[Same patch later posted by Keith at https://patch.msgid.link/(CVE-2026-43211)
In the Linux kernel, the following vulnerability has been resolved:
ipv6: prevent possible UaF in addrconf_permanent_addr()
The mentioned helper try to warn the user about an exceptional condition, but the message is delivered too late, accessing the ipv6 after its possible deletion.
Reorder the statement to avoid the possible UaF; while at it, place the warning outside the idev->lock as it needs no protection.(CVE-2026-43339)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/rxe: Fix double free in rxe_srq_from_init
In rxe_srq_from_init(), the queue pointer 'q' is assigned to 'srq->rq.queue' before copying the SRQ number to user space. If copy_to_user() fails, the function calls rxe_queue_cleanup() to free the queue, but leaves the now-invalid pointer in 'srq->rq.queue'.
The caller of rxe_srq_from_init() (rxe_create_srq) eventually calls rxe_srq_cleanup() upon receiving the error, which triggers a second rxe_queue_cleanup() on the same memory, leading to a double free.
The call trace looks like this: kmem_cache_free+0x.../0x... rxe_queue_cleanup+0x1a/0x30 [rdma_rxe] rxe_srq_cleanup+0x42/0x60 [rdma_rxe] rxe_elem_release+0x31/0x70 [rdma_rxe] rxe_create_srq+0x12b/0x1a0 [rdma_rxe] ib_create_srq_user+0x9a/0x150 [ib_core]
Fix this by moving 'srq->rq.queue = q' after copy_to_user.(CVE-2026-45852)
In the Linux kernel, the following vulnerability has been resolved:
sched/rt: Skip currently executing CPU in rto_next_cpu()
CPU0 becomes overloaded when hosting a CPU-bound RT task, a non-CPU-bound RT task, and a CFS task stuck in kernel space. When other CPUs switch from RT to non-RT tasks, RT load balancing (LB) is triggered; with HAVE_RT_PUSH_IPI enabled, they send IPIs to CPU0 to drive the execution of rto_push_irq_work_func. During push_rt_task on CPU0, if next_task->prio < rq->donor->prio, resched_curr() sets NEED_RESCHED and after the push operation completes, CPU0 calls rto_next_cpu(). Since only CPU0 is overloaded in this scenario, rto_next_cpu() should ideally return -1 (no further IPI needed).
However, multiple CPUs invoking tell_cpu_to_push() during LB increments rd->rto_loop_next. Even when rd->rto_cpu is set to -1, the mismatch between rd->rto_loop and rd->rto_loop_next forces rto_next_cpu() to restart its search from -1. With CPU0 remaining overloaded (satisfying rt_nr_migratory && rt_nr_total > 1), it gets reselected, causing CPU0 to queue irq_work to itself and send self-IPIs repeatedly. As long as CPU0 stays overloaded and other CPUs run pull_rt_tasks(), it falls into an infinite self-IPI loop, which triggers a CPU hardlockup due to continuous self-interrupts.
The trigging scenario is as follows:
cpu0 cpu1 cpu2
pull_rt_task
tell_cpu_to_push
<------------irq_work_queue_on
rto_push_irq_work_func push_rt_task resched_curr(rq) pull_rt_task rto_next_cpu tell_cpu_to_push <-------------------------- atomic_inc(rto_loop_next) rd->rto_loop != next rto_next_cpu irq_work_queue_on rto_push_irq_work_func
Fix redundant self-IPI by filtering the initiating CPU in rto_next_cpu(). This solution has been verified to effectively eliminate spurious self-IPIs and prevent CPU hardlockup scenarios.(CVE-2026-45919)
In the Linux kernel, the following vulnerability has been resolved:
bonding: alb: fix UAF in rlb_arp_recv during bond up/down
The ALB RX path may access rx_hashtbl concurrently with bond teardown. During rapid bond up/down cycles, rlb_deinitialize() frees rx_hashtbl while RX handlers are still running, leading to a null pointer dereference detected by KASAN.
However, the root cause is that rlb_arp_recv() can still be accessed after setting recv_probe to NULL, which is actually a use-after-free (UAF) issue. That is the reason for using the referenced commit in the Fixes tag.
[ 214.174138] Oops: general protection fault, probably for non-canonical address 0xdffffc000000001d: 0000 [#1] SMP KASAN PTI [ 214.186478] KASAN: null-ptr-deref in range [0x00000000000000e8-0x00000000000000ef] [ 214.194933] CPU: 30 UID: 0 PID: 2375 Comm: ping Kdump: loaded Not tainted 6.19.0-rc8+ #2 PREEMPT(voluntary) [ 214.205907] Hardware name: Dell Inc. PowerEdge R730/0WCJNT, BIOS 2.14.0 01/14/2022 [ 214.214357] RIP: 0010:rlb_arp_recv+0x505/0xab0 [bonding] [ 214.220320] Code: 0f 85 2b 05 00 00 48 b8 00 00 00 00 00 fc ff df 40 0f b6 ed 48 c1 e5 06 49 03 ad 78 01 00 00 48 8d 7d 28 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 06 0f 8e 12 05 00 00 80 7d 28 00 0f 84 8c 00 [ 214.241280] RSP: 0018:ffffc900073d8870 EFLAGS: 00010206 [ 214.247116] RAX: dffffc0000000000 RBX: ffff888168556822 RCX: ffff88816855681e [ 214.255082] RDX: 000000000000001d RSI: dffffc0000000000 RDI: 00000000000000e8 [ 214.263048] RBP: 00000000000000c0 R08: 0000000000000002 R09: ffffed11192021c8 [ 214.271013] R10: ffff8888c9010e43 R11: 0000000000000001 R12: 1ffff92000e7b119 [ 214.278978] R13: ffff8888c9010e00 R14: ffff888168556822 R15: ffff888168556810 [ 214.286943] FS: 00007f85d2d9cb80(0000) GS:ffff88886ccb3000(0000) knlGS:0000000000000000 [ 214.295966] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 214.302380] CR2: 00007f0d047b5e34 CR3: 00000008a1c2e002 CR4: 00000000001726f0 [ 214.310347] Call Trace: [ 214.313070] <IRQ> [ 214.315318] ? __pfx_rlb_arp_recv+0x10/0x10 [bonding] [ 214.320975] bond_handle_frame+0x166/0xb60 [bonding] [ 214.326537] ? __pfx_bond_handle_frame+0x10/0x10 [bonding] [ 214.332680] __netif_receive_skb_core.constprop.0+0x576/0x2710 [ 214.339199] ? __pfx_arp_process+0x10/0x10 [ 214.343775] ? sched_balance_find_src_group+0x98/0x630 [ 214.349513] ? __pfxnetifreceive_skb_core.constprop.0+0x10/0x10 [ 214.356513] ? arp_rcv+0x307/0x690 [ 214.360311] ? pfx_arp_rcv+0x10/0x10 [ 214.364499] ? __lock_acquire+0x58c/0xbd0 [ 214.368975] __netif_receive_skb_one_core+0xae/0x1b0 [ 214.374518] ? __pfxnetifreceive_skb_one_core+0x10/0x10 [ 214.380743] ? lock_acquire+0x10b/0x140 [ 214.385026] process_backlog+0x3f1/0x13a0 [ 214.389502] ? process_backlog+0x3aa/0x13a0 [ 214.394174] napi_poll.constprop.0+0x9f/0x370 [ 214.399233] net_rx_action+0x8c1/0xe60 [ 214.403423] ? __pfx_net_rx_action+0x10/0x10 [ 214.408193] ? lock_acquire.part.0+0xbd/0x260 [ 214.413058] ? sched_clock_cpu+0x6c/0x540 [ 214.417540] ? mark_held_locks+0x40/0x70 [ 214.421920] handle_softirqs+0x1fd/0x860 [ 214.426302] ? __pfx_handle_softirqs+0x10/0x10 [ 214.431264] ? __neigh_event_send+0x2d6/0xf50 [ 214.436131] do_softirq+0xb1/0xf0 [ 214.439830] </IRQ>
The issue is reproducible by repeatedly running ip link set bond0 up/down while receiving ARP messages, where rlb_arp_recv() can race with rlb_deinitialize() and dereference a freed rx_hashtbl entry.
Fix this by setting recv_probe to NULL and then calling synchronize_net() to wait for any concurrent RX processing to finish. This ensures that no RX handler can access rx_hashtbl after it is freed in bond_alb_deinitialize().(CVE-2026-45970)
In the Linux kernel, the following vulnerability has been resolved:
crypto: algif_aead - snapshot IV for async AEAD requests
AF_ALG AEAD AIO requests currently use the socket-wide IV buffer during request processing. For async requests, later socket activity can update that shared state before the original request has fully completed, which can lead to inconsistent IV handling.
Snapshot the IV into per-request storage when preparing the AEAD request, so in-flight operations no longer depend on mutable socket state.(CVE-2026-46028)
In the Linux kernel, drm_gem_fb_init_with_funcs() computes sub-sampled plane dimensions using plain integer division, while the ioctl-level framebuffer_check() uses DIV_ROUND_UP via drm_format_info_plane_width/height(). This inconsistency causes incorrect GEM object size validation for certain pixel formats and dimensions, e.g., NV12 with height=1 results in height=0, leading to an integer overflow in size check and allowing undersized GEM objects to pass, potentially causing out-of-bounds memory access by the GPU.(CVE-2026-46209)
In the Linux kernel, the following vulnerability has been resolved: procfs: fix missing RCU protection when reading real_parent in do_task_stat() When reading /proc/[pid]/stat, do_task_stat() accesses task->real_parent without proper RCU protection, which leads to: cpu 0 cpu 1 ----- ----- do_task_stat var = task->real_parent release_task call_rcu(delayed_put_task_struct) task_tgid_nr_ns(var) rcu_read_lock <--- Too late to protect task->real_parent! task_pid_ptr <--- UAF! rcu_read_unlock This patch uses task_ppid_nr_ns() instead of task_tgid_nr_ns() to add proper RCU protection for accessing task->real_parent. The Linux kernel CVE team has assigned CVE-2026-46259 to this issue.(CVE-2026-46259)
| URL | Type | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-4.19.90-2606.3.0.0376.oe2003sp4.aarch64.rpm",
"bpftool-debuginfo-4.19.90-2606.3.0.0376.oe2003sp4.aarch64.rpm",
"kernel-4.19.90-2606.3.0.0376.oe2003sp4.aarch64.rpm",
"kernel-debuginfo-4.19.90-2606.3.0.0376.oe2003sp4.aarch64.rpm",
"kernel-debugsource-4.19.90-2606.3.0.0376.oe2003sp4.aarch64.rpm",
"kernel-devel-4.19.90-2606.3.0.0376.oe2003sp4.aarch64.rpm",
"kernel-source-4.19.90-2606.3.0.0376.oe2003sp4.aarch64.rpm",
"kernel-tools-4.19.90-2606.3.0.0376.oe2003sp4.aarch64.rpm",
"kernel-tools-debuginfo-4.19.90-2606.3.0.0376.oe2003sp4.aarch64.rpm",
"kernel-tools-devel-4.19.90-2606.3.0.0376.oe2003sp4.aarch64.rpm",
"perf-4.19.90-2606.3.0.0376.oe2003sp4.aarch64.rpm",
"perf-debuginfo-4.19.90-2606.3.0.0376.oe2003sp4.aarch64.rpm",
"python2-perf-4.19.90-2606.3.0.0376.oe2003sp4.aarch64.rpm",
"python2-perf-debuginfo-4.19.90-2606.3.0.0376.oe2003sp4.aarch64.rpm",
"python3-perf-4.19.90-2606.3.0.0376.oe2003sp4.aarch64.rpm",
"python3-perf-debuginfo-4.19.90-2606.3.0.0376.oe2003sp4.aarch64.rpm"
],
"src": [
"kernel-4.19.90-2606.3.0.0376.oe2003sp4.src.rpm"
],
"x86_64": [
"bpftool-4.19.90-2606.3.0.0376.oe2003sp4.x86_64.rpm",
"bpftool-debuginfo-4.19.90-2606.3.0.0376.oe2003sp4.x86_64.rpm",
"kernel-4.19.90-2606.3.0.0376.oe2003sp4.x86_64.rpm",
"kernel-debuginfo-4.19.90-2606.3.0.0376.oe2003sp4.x86_64.rpm",
"kernel-debugsource-4.19.90-2606.3.0.0376.oe2003sp4.x86_64.rpm",
"kernel-devel-4.19.90-2606.3.0.0376.oe2003sp4.x86_64.rpm",
"kernel-source-4.19.90-2606.3.0.0376.oe2003sp4.x86_64.rpm",
"kernel-tools-4.19.90-2606.3.0.0376.oe2003sp4.x86_64.rpm",
"kernel-tools-debuginfo-4.19.90-2606.3.0.0376.oe2003sp4.x86_64.rpm",
"kernel-tools-devel-4.19.90-2606.3.0.0376.oe2003sp4.x86_64.rpm",
"perf-4.19.90-2606.3.0.0376.oe2003sp4.x86_64.rpm",
"perf-debuginfo-4.19.90-2606.3.0.0376.oe2003sp4.x86_64.rpm",
"python2-perf-4.19.90-2606.3.0.0376.oe2003sp4.x86_64.rpm",
"python2-perf-debuginfo-4.19.90-2606.3.0.0376.oe2003sp4.x86_64.rpm",
"python3-perf-4.19.90-2606.3.0.0376.oe2003sp4.x86_64.rpm",
"python3-perf-debuginfo-4.19.90-2606.3.0.0376.oe2003sp4.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:20.03-LTS-SP4",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-20.03-LTS-SP4"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.19.90-2606.3.0.0376.oe2003sp4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: hamradio: fix memory leak in mkiss_close\n\nMy local syzbot instance hit memory leak in\nmkiss_open()[1]. The problem was in missing\nfree_netdev() in mkiss_close().\n\nIn mkiss_open() netdevice is allocated and then\nregistered, but in mkiss_close() netdevice was\nonly unregistered, but not freed.\n\nFail log:\n\nBUG: memory leak\nunreferenced object 0xffff8880281ba000 (size 4096):\n comm \u0026quot;syz-executor.1\u0026quot;, pid 11443, jiffies 4295046091 (age 17.660s)\n hex dump (first 32 bytes):\n 61 78 30 00 00 00 00 00 00 00 00 00 00 00 00 00 ax0.............\n 00 27 fa 2a 80 88 ff ff 00 00 00 00 00 00 00 00 .\u0026apos;.*............\n backtrace:\n [\u0026lt;ffffffff81a27201\u0026gt;] kvmalloc_node+0x61/0xf0\n [\u0026lt;ffffffff8706e7e8\u0026gt;] alloc_netdev_mqs+0x98/0xe80\n [\u0026lt;ffffffff84e64192\u0026gt;] mkiss_open+0xb2/0x6f0 [1]\n [\u0026lt;ffffffff842355db\u0026gt;] tty_ldisc_open+0x9b/0x110\n [\u0026lt;ffffffff84236488\u0026gt;] tty_set_ldisc+0x2e8/0x670\n [\u0026lt;ffffffff8421f7f3\u0026gt;] tty_ioctl+0xda3/0x1440\n [\u0026lt;ffffffff81c9f273\u0026gt;] __x64_sys_ioctl+0x193/0x200\n [\u0026lt;ffffffff8911263a\u0026gt;] do_syscall_64+0x3a/0xb0\n [\u0026lt;ffffffff89200068\u0026gt;] entry_SYSCALL_64_after_hwframe+0x44/0xae\n\nBUG: memory leak\nunreferenced object 0xffff8880141a9a00 (size 96):\n comm \u0026quot;syz-executor.1\u0026quot;, pid 11443, jiffies 4295046091 (age 17.660s)\n hex dump (first 32 bytes):\n e8 a2 1b 28 80 88 ff ff e8 a2 1b 28 80 88 ff ff ...(.......(....\n 98 92 9c aa b0 40 02 00 00 00 00 00 00 00 00 00 .....@..........\n backtrace:\n [\u0026lt;ffffffff8709f68b\u0026gt;] __hw_addr_create_ex+0x5b/0x310\n [\u0026lt;ffffffff8709fb38\u0026gt;] __hw_addr_add_ex+0x1f8/0x2b0\n [\u0026lt;ffffffff870a0c7b\u0026gt;] dev_addr_init+0x10b/0x1f0\n [\u0026lt;ffffffff8706e88b\u0026gt;] alloc_netdev_mqs+0x13b/0xe80\n [\u0026lt;ffffffff84e64192\u0026gt;] mkiss_open+0xb2/0x6f0 [1]\n [\u0026lt;ffffffff842355db\u0026gt;] tty_ldisc_open+0x9b/0x110\n [\u0026lt;ffffffff84236488\u0026gt;] tty_set_ldisc+0x2e8/0x670\n [\u0026lt;ffffffff8421f7f3\u0026gt;] tty_ioctl+0xda3/0x1440\n [\u0026lt;ffffffff81c9f273\u0026gt;] __x64_sys_ioctl+0x193/0x200\n [\u0026lt;ffffffff8911263a\u0026gt;] do_syscall_64+0x3a/0xb0\n [\u0026lt;ffffffff89200068\u0026gt;] entry_SYSCALL_64_after_hwframe+0x44/0xae\n\nBUG: memory leak\nunreferenced object 0xffff8880219bfc00 (size 512):\n comm \u0026quot;syz-executor.1\u0026quot;, pid 11443, jiffies 4295046091 (age 17.660s)\n hex dump (first 32 bytes):\n 00 a0 1b 28 80 88 ff ff 80 8f b1 8d ff ff ff ff ...(............\n 80 8f b1 8d ff ff ff ff 00 00 00 00 00 00 00 00 ................\n backtrace:\n [\u0026lt;ffffffff81a27201\u0026gt;] kvmalloc_node+0x61/0xf0\n [\u0026lt;ffffffff8706eec7\u0026gt;] alloc_netdev_mqs+0x777/0xe80\n [\u0026lt;ffffffff84e64192\u0026gt;] mkiss_open+0xb2/0x6f0 [1]\n [\u0026lt;ffffffff842355db\u0026gt;] tty_ldisc_open+0x9b/0x110\n [\u0026lt;ffffffff84236488\u0026gt;] tty_set_ldisc+0x2e8/0x670\n [\u0026lt;ffffffff8421f7f3\u0026gt;] tty_ioctl+0xda3/0x1440\n [\u0026lt;ffffffff81c9f273\u0026gt;] __x64_sys_ioctl+0x193/0x200\n [\u0026lt;ffffffff8911263a\u0026gt;] do_syscall_64+0x3a/0xb0\n [\u0026lt;ffffffff89200068\u0026gt;] entry_SYSCALL_64_after_hwframe+0x44/0xae\n\nBUG: memory leak\nunreferenced object 0xffff888029b2b200 (size 256):\n comm \u0026quot;syz-executor.1\u0026quot;, pid 11443, jiffies 4295046091 (age 17.660s)\n hex dump (first 32 bytes):\n 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n backtrace:\n [\u0026lt;ffffffff81a27201\u0026gt;] kvmalloc_node+0x61/0xf0\n [\u0026lt;ffffffff8706f062\u0026gt;] alloc_netdev_mqs+0x912/0xe80\n [\u0026lt;ffffffff84e64192\u0026gt;] mkiss_open+0xb2/0x6f0 [1]\n [\u0026lt;ffffffff842355db\u0026gt;] tty_ldisc_open+0x9b/0x110\n [\u0026lt;ffffffff84236488\u0026gt;] tty_set_ldisc+0x2e8/0x670\n [\u0026lt;ffffffff8421f7f3\u0026gt;] tty_ioctl+0xda3/0x1440\n [\u0026lt;ffffffff81c9f273\u0026gt;] __x64_sys_ioctl+0x193/0x200\n [\u0026lt;ffffffff8911263a\u0026gt;] do_syscall_64+0x3a/0xb0\n [\u0026lt;ffffffff89200068\u0026gt;] entry_SYSCALL_64_after_hwframe+0x44/0xae(CVE-2021-47237)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nIB/mlx5: Fix initializing CQ fragments buffer\n\nThe function init_cq_frag_buf() can be called to initialize the current CQ\nfragments buffer cq-\u0026gt;buf, or the temporary cq-\u0026gt;resize_buf that is filled\nduring CQ resize operation.\n\nHowever, the offending commit started to use function get_cqe() for\ngetting the CQEs, the issue with this change is that get_cqe() always\nreturns CQEs from cq-\u0026gt;buf, which leads us to initialize the wrong buffer,\nand in case of enlarging the CQ we try to access elements beyond the size\nof the current cq-\u0026gt;buf and eventually hit a kernel panic.\n\n [exception RIP: init_cq_frag_buf+103]\n [ffff9f799ddcbcd8] mlx5_ib_resize_cq at ffffffffc0835d60 [mlx5_ib]\n [ffff9f799ddcbdb0] ib_resize_cq at ffffffffc05270df [ib_core]\n [ffff9f799ddcbdc0] llt_rdma_setup_qp at ffffffffc0a6a712 [llt]\n [ffff9f799ddcbe10] llt_rdma_cc_event_action at ffffffffc0a6b411 [llt]\n [ffff9f799ddcbe98] llt_rdma_client_conn_thread at ffffffffc0a6bb75 [llt]\n [ffff9f799ddcbec8] kthread at ffffffffa66c5da1\n [ffff9f799ddcbf50] ret_from_fork_nospec_begin at ffffffffa6d95ddd\n\nFix it by getting the needed CQE by calling mlx5_frag_buf_get_wqe() that\ntakes the correct source buffer as a parameter.(CVE-2021-47261)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmackfs: restrict bytes count in smk_set_cipso()\n\nOops, I failed to update subject line.\n\nFrom 07571157c91b98ce1a4aa70967531e64b78e8346 Mon Sep 17 00:00:00 2001\nDate: Mon, 12 Apr 2021 22:25:06 +0900\nSubject: [PATCH] smackfs: restrict bytes count in smk_set_cipso()\n\nCommit 7ef4c19d245f3dc2 (\u0026quot;smackfs: restrict bytes count in smackfs write\nfunctions\u0026quot;) missed that count \u0026gt; SMK_CIPSOMAX check applies to only\nformat == SMK_FIXED24_FMT case.(CVE-2021-47336)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/cma: Fix rdma_resolve_route() memory leak\n\nFix a memory leak when \u0026quot;mda_resolve_route() is called more than once on\nthe same \u0026quot;rdma_cm_id\u0026quot;.\n\nThis is possible if cma_query_handler() triggers the\nRDMA_CM_EVENT_ROUTE_ERROR flow which puts the state machine back and\nallows rdma_resolve_route() to be called again.(CVE-2021-47345)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni40e: Fix NULL pointer dereference in i40e_dbg_dump_desc\n\nWhen trying to dump VFs VSI RX/TX descriptors\nusing debugfs there was a crash\ndue to NULL pointer dereference in i40e_dbg_dump_desc.\nAdded a check to i40e_dbg_dump_desc that checks if\nVSI type is correct for dumping RX/TX descriptors.(CVE-2021-47501)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncan: pch_can: pch_can_rx_normal: fix use after free\n\nAfter calling netif_receive_skb(skb), dereferencing skb is unsafe.\nEspecially, the can_frame cf which aliases skb memory is dereferenced\njust after the call netif_receive_skb(skb).\n\nReordering the lines solves the issue.(CVE-2021-47520)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nALSA: hda: Fix possible null-ptr-deref when assigning a stream\n\nWhile AudioDSP drivers assign streams exclusively of HOST or LINK type,\nnothing blocks a user to attempt to assign a COUPLED stream. As\nsupplied substream instance may be a stub, what is the case when\ncode-loading, such scenario ends with null-ptr-deref.(CVE-2023-52806)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: complete validation of user input\n\nIn my recent commit, I missed that do_replace() handlers\nuse copy_from_sockptr() (which I fixed), followed\nby unsafe copy_from_sockptr_offset() calls.\n\nIn all functions, we can perform the @optlen validation\nbefore even calling xt_alloc_table_info() with the following\ncheck:\n\nif ((u64)optlen \u0026lt; (u64)tmp.size + sizeof(tmp))\n return -EINVAL;(CVE-2024-35962)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: algif_aead - Fix minimum RX size check for decryption\n\nThe check for the minimum receive buffer size did not take the\ntag size into account during decryption. Fix this by adding the\nrequired extra length.(CVE-2026-43077)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: af_alg - Fix page reassignment overflow in af_alg_pull_tsgl\n\nWhen page reassignment was added to af_alg_pull_tsgl the original\nloop wasn\u0026apos;t updated so it may try to reassign one more page than\nnecessary.\n\nAdd the check to the reassignment so that this does not happen.\n\nAlso update the comment which still refers to the obsolete offset\nargument.(CVE-2026-43078)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nPCI: Fix pci_slot_trylock() error handling\n\nCommit a4e772898f8b (\u0026quot;PCI: Add missing bridge lock to pci_bus_lock()\u0026quot;)\ndelegates the bridge device\u0026apos;s pci_dev_trylock() to pci_bus_trylock() in\npci_slot_trylock(), but it forgets to remove the corresponding\npci_dev_unlock() when pci_bus_trylock() fails.\n\nBefore a4e772898f8b, the code did:\n\n if (!pci_dev_trylock(dev)) /* \u0026lt;- lock bridge device */\n goto unlock;\n if (dev-\u0026gt;subordinate) {\n if (!pci_bus_trylock(dev-\u0026gt;subordinate)) {\n pci_dev_unlock(dev); /* \u0026lt;- unlock bridge device */\n goto unlock;\n }\n }\n\nAfter a4e772898f8b the bridge-device lock is no longer taken, but the\npci_dev_unlock(dev) on the failure path was left in place, leading to the\nbug.\n\nThis yields one of two errors:\n\n 1. A warning that the lock is being unlocked when no one holds it.\n 2. An incorrect unlock of a lock that belongs to another thread.\n\nFix it by removing the now-redundant pci_dev_unlock(dev) on the failure\npath.\n\n[Same patch later posted by Keith at\nhttps://patch.msgid.link/(CVE-2026-43211)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: prevent possible UaF in addrconf_permanent_addr()\n\nThe mentioned helper try to warn the user about an exceptional\ncondition, but the message is delivered too late, accessing the ipv6\nafter its possible deletion.\n\nReorder the statement to avoid the possible UaF; while at it, place the\nwarning outside the idev-\u0026gt;lock as it needs no protection.(CVE-2026-43339)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/rxe: Fix double free in rxe_srq_from_init\n\nIn rxe_srq_from_init(), the queue pointer \u0026apos;q\u0026apos; is assigned to\n\u0026apos;srq-\u0026gt;rq.queue\u0026apos; before copying the SRQ number to user space.\nIf copy_to_user() fails, the function calls rxe_queue_cleanup()\nto free the queue, but leaves the now-invalid pointer in\n\u0026apos;srq-\u0026gt;rq.queue\u0026apos;.\n\nThe caller of rxe_srq_from_init() (rxe_create_srq) eventually\ncalls rxe_srq_cleanup() upon receiving the error, which triggers\na second rxe_queue_cleanup() on the same memory, leading to a\ndouble free.\n\nThe call trace looks like this:\n kmem_cache_free+0x.../0x...\n rxe_queue_cleanup+0x1a/0x30 [rdma_rxe]\n rxe_srq_cleanup+0x42/0x60 [rdma_rxe]\n rxe_elem_release+0x31/0x70 [rdma_rxe]\n rxe_create_srq+0x12b/0x1a0 [rdma_rxe]\n ib_create_srq_user+0x9a/0x150 [ib_core]\n\nFix this by moving \u0026apos;srq-\u0026gt;rq.queue = q\u0026apos; after copy_to_user.(CVE-2026-45852)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsched/rt: Skip currently executing CPU in rto_next_cpu()\n\nCPU0 becomes overloaded when hosting a CPU-bound RT task, a non-CPU-bound\nRT task, and a CFS task stuck in kernel space. When other CPUs switch from\nRT to non-RT tasks, RT load balancing (LB) is triggered; with\nHAVE_RT_PUSH_IPI enabled, they send IPIs to CPU0 to drive the execution\nof rto_push_irq_work_func. During push_rt_task on CPU0,\nif next_task-\u0026gt;prio \u0026lt; rq-\u0026gt;donor-\u0026gt;prio, resched_curr() sets NEED_RESCHED\nand after the push operation completes, CPU0 calls rto_next_cpu().\nSince only CPU0 is overloaded in this scenario, rto_next_cpu() should\nideally return -1 (no further IPI needed).\n\nHowever, multiple CPUs invoking tell_cpu_to_push() during LB increments\nrd-\u0026gt;rto_loop_next. Even when rd-\u0026gt;rto_cpu is set to -1, the mismatch between\nrd-\u0026gt;rto_loop and rd-\u0026gt;rto_loop_next forces rto_next_cpu() to restart its\nsearch from -1. With CPU0 remaining overloaded (satisfying rt_nr_migratory\n\u0026amp;\u0026amp; rt_nr_total \u0026gt; 1), it gets reselected, causing CPU0 to queue irq_work to\nitself and send self-IPIs repeatedly. As long as CPU0 stays overloaded and\nother CPUs run pull_rt_tasks(), it falls into an infinite self-IPI loop,\nwhich triggers a CPU hardlockup due to continuous self-interrupts.\n\nThe trigging scenario is as follows:\n\n cpu0 cpu1 cpu2\n pull_rt_task\n tell_cpu_to_push\n \u0026lt;------------irq_work_queue_on\nrto_push_irq_work_func\n push_rt_task\n resched_curr(rq) pull_rt_task\n rto_next_cpu tell_cpu_to_push\n \u0026lt;-------------------------- atomic_inc(rto_loop_next)\nrd-\u0026gt;rto_loop != next\n rto_next_cpu\n irq_work_queue_on\nrto_push_irq_work_func\n\nFix redundant self-IPI by filtering the initiating CPU in rto_next_cpu().\nThis solution has been verified to effectively eliminate spurious self-IPIs\nand prevent CPU hardlockup scenarios.(CVE-2026-45919)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbonding: alb: fix UAF in rlb_arp_recv during bond up/down\n\nThe ALB RX path may access rx_hashtbl concurrently with bond\nteardown. During rapid bond up/down cycles, rlb_deinitialize()\nfrees rx_hashtbl while RX handlers are still running, leading\nto a null pointer dereference detected by KASAN.\n\nHowever, the root cause is that rlb_arp_recv() can still be accessed\nafter setting recv_probe to NULL, which is actually a use-after-free\n(UAF) issue. That is the reason for using the referenced commit in the\nFixes tag.\n\n[ 214.174138] Oops: general protection fault, probably for non-canonical address 0xdffffc000000001d: 0000 [#1] SMP KASAN PTI\n[ 214.186478] KASAN: null-ptr-deref in range [0x00000000000000e8-0x00000000000000ef]\n[ 214.194933] CPU: 30 UID: 0 PID: 2375 Comm: ping Kdump: loaded Not tainted 6.19.0-rc8+ #2 PREEMPT(voluntary)\n[ 214.205907] Hardware name: Dell Inc. PowerEdge R730/0WCJNT, BIOS 2.14.0 01/14/2022\n[ 214.214357] RIP: 0010:rlb_arp_recv+0x505/0xab0 [bonding]\n[ 214.220320] Code: 0f 85 2b 05 00 00 48 b8 00 00 00 00 00 fc ff df 40 0f b6 ed 48 c1 e5 06 49 03 ad 78 01 00 00 48 8d 7d 28 48 89 fa 48 c1 ea 03 \u0026lt;0f\u0026gt; b6\n 04 02 84 c0 74 06 0f 8e 12 05 00 00 80 7d 28 00 0f 84 8c 00\n[ 214.241280] RSP: 0018:ffffc900073d8870 EFLAGS: 00010206\n[ 214.247116] RAX: dffffc0000000000 RBX: ffff888168556822 RCX: ffff88816855681e\n[ 214.255082] RDX: 000000000000001d RSI: dffffc0000000000 RDI: 00000000000000e8\n[ 214.263048] RBP: 00000000000000c0 R08: 0000000000000002 R09: ffffed11192021c8\n[ 214.271013] R10: ffff8888c9010e43 R11: 0000000000000001 R12: 1ffff92000e7b119\n[ 214.278978] R13: ffff8888c9010e00 R14: ffff888168556822 R15: ffff888168556810\n[ 214.286943] FS: 00007f85d2d9cb80(0000) GS:ffff88886ccb3000(0000) knlGS:0000000000000000\n[ 214.295966] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 214.302380] CR2: 00007f0d047b5e34 CR3: 00000008a1c2e002 CR4: 00000000001726f0\n[ 214.310347] Call Trace:\n[ 214.313070] \u0026lt;IRQ\u0026gt;\n[ 214.315318] ? __pfx_rlb_arp_recv+0x10/0x10 [bonding]\n[ 214.320975] bond_handle_frame+0x166/0xb60 [bonding]\n[ 214.326537] ? __pfx_bond_handle_frame+0x10/0x10 [bonding]\n[ 214.332680] __netif_receive_skb_core.constprop.0+0x576/0x2710\n[ 214.339199] ? __pfx_arp_process+0x10/0x10\n[ 214.343775] ? sched_balance_find_src_group+0x98/0x630\n[ 214.349513] ? __pfx___netif_receive_skb_core.constprop.0+0x10/0x10\n[ 214.356513] ? arp_rcv+0x307/0x690\n[ 214.360311] ? __pfx_arp_rcv+0x10/0x10\n[ 214.364499] ? __lock_acquire+0x58c/0xbd0\n[ 214.368975] __netif_receive_skb_one_core+0xae/0x1b0\n[ 214.374518] ? __pfx___netif_receive_skb_one_core+0x10/0x10\n[ 214.380743] ? lock_acquire+0x10b/0x140\n[ 214.385026] process_backlog+0x3f1/0x13a0\n[ 214.389502] ? process_backlog+0x3aa/0x13a0\n[ 214.394174] __napi_poll.constprop.0+0x9f/0x370\n[ 214.399233] net_rx_action+0x8c1/0xe60\n[ 214.403423] ? __pfx_net_rx_action+0x10/0x10\n[ 214.408193] ? lock_acquire.part.0+0xbd/0x260\n[ 214.413058] ? sched_clock_cpu+0x6c/0x540\n[ 214.417540] ? mark_held_locks+0x40/0x70\n[ 214.421920] handle_softirqs+0x1fd/0x860\n[ 214.426302] ? __pfx_handle_softirqs+0x10/0x10\n[ 214.431264] ? __neigh_event_send+0x2d6/0xf50\n[ 214.436131] do_softirq+0xb1/0xf0\n[ 214.439830] \u0026lt;/IRQ\u0026gt;\n\nThe issue is reproducible by repeatedly running\nip link set bond0 up/down while receiving ARP messages, where\nrlb_arp_recv() can race with rlb_deinitialize() and dereference\na freed rx_hashtbl entry.\n\nFix this by setting recv_probe to NULL and then calling\nsynchronize_net() to wait for any concurrent RX processing to finish.\nThis ensures that no RX handler can access rx_hashtbl after it is freed\nin bond_alb_deinitialize().(CVE-2026-45970)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: algif_aead - snapshot IV for async AEAD requests\n\nAF_ALG AEAD AIO requests currently use the socket-wide IV buffer during\nrequest processing. For async requests, later socket activity can\nupdate that shared state before the original request has fully\ncompleted, which can lead to inconsistent IV handling.\n\nSnapshot the IV into per-request storage when preparing the AEAD\nrequest, so in-flight operations no longer depend on mutable socket\nstate.(CVE-2026-46028)\n\nIn the Linux kernel, drm_gem_fb_init_with_funcs() computes sub-sampled plane dimensions using plain integer division, while the ioctl-level framebuffer_check() uses DIV_ROUND_UP via drm_format_info_plane_width/height(). This inconsistency causes incorrect GEM object size validation for certain pixel formats and dimensions, e.g., NV12 with height=1 results in height=0, leading to an integer overflow in size check and allowing undersized GEM objects to pass, potentially causing out-of-bounds memory access by the GPU.(CVE-2026-46209)\n\n[\u0026apos;This has been assigned CVE-2026-46243, see\u0026apos;, \u0026apos;On Thursday, May 28th, 2026 at 12:07 AM, manizada \u0026lt;manizada () pm me\u0026gt; wrote:\u0026apos;, \u0026apos;Hi folks,\\n\\nEmailing here now that the embargo agreed upon with linux-distros@ has expired.\\n\\nFlagging a local root vulnerability spanning both CIFS in the kernel and\\ncifs-utils in userspace (originally reported to kernel/cifs maintainers on May 16).\\nThe kernel-side (only) fix has now been public for over a week and is queued for stable:\\n\\n3da1fdf4efbc (\u0026quot;smb: client: reject userspace cifs.spnego descriptions\u0026quot;)\\n\\nImpact:\\n Unprivileged user -\u0026gt; root code exec on any system where:\\n - cifs-utils is installed (with the default cifs.spnego rule)\\n - CIFS kernel module is loadable/compiled-in (typically the case), and\\n - unprivileged user/mount namespaces are enabled.\\n\\nSome default AppArmor/SELinux profiles block this.\\n\\nBug:\\n An unprivileged user can call request_key(\u0026quot;cifs.spnego\u0026quot;, ...) with a forged\\n CIFS SPNEGO description. The request-key rule starts cifs.upcall as root.\\n cifs.upcall then trusts attacker-supplied pid, uid, creduid, and\\n upcall_target fields as if they came from kernel CIFS.\\n\\n For upcall_target=app, affected cifs-utils versions switch into the supplied\\n process\\\u0026apos;s namespaces and perform NSS lookup before final privilege drop.\\n A private mount namespace containing attacker-controlled /etc/nsswitch.conf\\n and libnss_*.so.2 is therefore sufficient for code execution in the root\\n helper.\\n\\nAffected distros:\\n This a non-exhaustive summary of some tested distros. The full table, including\\n the cases where stock policy blocks exploitation (but relaxing AppArmor/SELinux/etc.\\n enables exploitation), is in the attachment (and in an easier-to-read format in\\n the writeup linked below).\\n\\n Stock-default exploitable distros\\n (cifs-utils comes preinstalled in the profile + unprivileged namespaces permitted by default\\n + the AA/SELinux policies, if any, do not block the attack):\\n\\n - Linux Mint Cinnamon 21.3 and 22.3\\n - CentOS Stream 9 GNOME\\n - Rocky Linux 9 Workstation\\n - Kali Linux headless 2021.4/2022.4/2023.4/2024.4/2025.4/2026.1\\n - AlmaLinux 9.7 Workstation/Azure cloud image\\n - SLES 15 SP7/SAP 15 SP7/SAP 16\\n\\n Exploitable if cifs-utils is installed, with no other default config changes:\\n - Ubuntu 18.04/20.04/22.04 Desktop/Server\\n - Pop!_OS 22.04 Intel/24.04 Generic\\n - Ubuntu 24.04 Desktop minimal/full and Server\\n - Debian 11/12/13 netinst standard and GNOME/KDE/standard/XFCE\\n - CentOS Stream 9 Cinnamon/KDE/MATE/XFCE\\n - Rocky Linux 9 KDE/Workstation-Lite\\n - openSUSE Leap 15.6 GNOME/KDE\\n - openSUSE Tumbleweed GNOME/KDE\\n - Rocky Linux 8 GenericCloud\\n - Oracle Linux 8/9 KVM\\n - Amazon Linux 2023 KVM\\n\\nImmediate-term mitigations (aside from backporting the kernel fix):\\n - Blocking the CIFS module from loading (assuming it\\\u0026apos;s not built-in)/uninstalling cifs-utils if not used\\n - Deleting/overriding the default cifs.spnego request-key rule (if Kerberos cifs is not required),\\n e.g., after adjusting for your keyctl path:\\n\\n cat \u0026gt;/etc/request-key.d/cifs.spnego.conf \u0026lt;\u0026lt;\\\u0026apos;EOF\\\u0026apos;\\n create cifs.spnego * * /usr/sbin/keyctl negate %k 30 %S\\n EOF\\n\\n - Disabling unprivileged user namespaces\\n\\nThe CVE # assignment is still pending.\\n\\nFull writeup:\u0026apos;, \u0026apos;PoC to validate mitigations:\u0026apos;, \u0026apos;Thanks,\\n-Asim Manizada\u0026apos;](CVE-2026-46243)\n\nIn the Linux kernel, the following vulnerability has been resolved: procfs: fix missing RCU protection when reading real_parent in do_task_stat() When reading /proc/[pid]/stat, do_task_stat() accesses task-\u0026gt;real_parent without proper RCU protection, which leads to: cpu 0 cpu 1 ----- ----- do_task_stat var = task-\u0026gt;real_parent release_task call_rcu(delayed_put_task_struct) task_tgid_nr_ns(var) rcu_read_lock \u0026lt;--- Too late to protect task-\u0026gt;real_parent! task_pid_ptr \u0026lt;--- UAF! rcu_read_unlock This patch uses task_ppid_nr_ns() instead of task_tgid_nr_ns() to add proper RCU protection for accessing task-\u0026gt;real_parent. The Linux kernel CVE team has assigned CVE-2026-46259 to this issue.(CVE-2026-46259)",
"id": "OESA-2026-2673",
"modified": "2026-08-06T11:11:36Z",
"published": "2026-06-12T11:11:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-2673"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47237"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47261"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47336"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47345"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47501"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47520"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52806"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35962"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43077"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43078"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43211"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43339"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45852"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45919"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45970"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46028"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46209"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46243"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46259"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2021-47237",
"CVE-2021-47261",
"CVE-2021-47336",
"CVE-2021-47345",
"CVE-2021-47501",
"CVE-2021-47520",
"CVE-2023-52806",
"CVE-2024-35962",
"CVE-2026-43077",
"CVE-2026-43078",
"CVE-2026-43211",
"CVE-2026-43339",
"CVE-2026-45852",
"CVE-2026-45919",
"CVE-2026-45970",
"CVE-2026-46028",
"CVE-2026-46209",
"CVE-2026-46243",
"CVE-2026-46259"
]
}
OESA-2026-2674 (CVE-2025-39759)
Vulnerability from osv_openeuler – Published: 2026-06-12 11:11 – Updated: 2026-08-06 11:11 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
btrfs: qgroup: fix race between quota disable and quota rescan ioctl
There's a race between a task disabling quotas and another running the rescan ioctl that can result in a use-after-free of qgroup records from the fs_info->qgroup_tree rbtree.
This happens as follows:
1) Task A enters btrfs_ioctl_quota_rescan() -> btrfs_qgroup_rescan();
2) Task B enters btrfs_quota_disable() and calls btrfs_qgroup_wait_for_completion(), which does nothing because at that point fs_info->qgroup_rescan_running is false (it wasn't set yet by task A);
3) Task B calls btrfs_free_qgroup_config() which starts freeing qgroups from fs_info->qgroup_tree without taking the lock fs_info->qgroup_lock;
4) Task A enters qgroup_rescan_zero_tracking() which starts iterating the fs_info->qgroup_tree tree while holding fs_info->qgroup_lock, but task B is freeing qgroup records from that tree without holding the lock, resulting in a use-after-free.
Fix this by taking fs_info->qgroup_lock at btrfs_free_qgroup_config(). Also at btrfs_qgroup_rescan() don't start the rescan worker if quotas were already disabled.(CVE-2025-39759)
In the Linux kernel, the following vulnerability has been resolved:
wifi: wilc1000: avoid buffer overflow in WID string configuration
Fix the following copy overflow warning identified by Smatch checker.
drivers/net/wireless/microchip/wilc1000/wlan_cfg.c:184 wilc_wlan_parse_response_frame() error: '__memcpy()' 'cfg->s[i]->str' copy overflow (512 vs 65537)
This patch introduces size check before accessing the memory buffer. The checks are base on the WID type of received data from the firmware. For WID string configuration, the size limit is determined by individual element size in 'struct wilc_cfg_str_vals' that is maintained in 'len' field of 'struct wilc_cfg_str'.(CVE-2025-39952)
In the Linux kernel, the following vulnerability has been resolved:
iio: accel: bmc150: Fix irq assumption regression
The code in bmc150-accel-core.c unconditionally calls bmc150_accel_set_interrupt() in the iio_buffer_setup_ops, such as on the runtime PM resume path giving a kernel splat like this if the device has no interrupts:
Unable to handle kernel NULL pointer dereference at virtual address 00000001 when read
PC is at bmc150_accel_set_interrupt+0x98/0x194 LR is at __pm_runtime_resume+0x5c/0x64 (...) Call trace: bmc150_accel_set_interrupt from bmc150_accel_buffer_postenable+0x40/0x108 bmc150_accel_buffer_postenable from __iio_update_buffers+0xbe0/0xcbc __iio_update_buffers from enable_store+0x84/0xc8 enable_store from kernfs_fop_write_iter+0x154/0x1b4
This bug seems to have been in the driver since the beginning, but it only manifests recently, I do not know why.
Store the IRQ number in the state struct, as this is a common pattern in other drivers, then use this to determine if we have IRQ support or not.(CVE-2025-68330)
In the Linux kernel, the following vulnerability has been resolved:
staging: most: remove broken i2c driver
The MOST I2C driver has been completely broken for five years without anyone noticing so remove the driver from staging.
Specifically, commit 723de0f9171e ("staging: most: remove device from interface structure") started requiring drivers to set the interface device pointer before registration, but the I2C driver was never updated which results in a NULL pointer dereference if anyone ever tries to probe it.(CVE-2025-68755)
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix NULL dereference on root when tracing inode eviction
When evicting an inode the first thing we do is to setup tracing for it, which implies fetching the root's id. But in btrfs_evict_inode() the root might be NULL, as implied in the next check that we do in btrfs_evict_inode().
Hence, we either should set the ->root_objectid to 0 in case the root is NULL, or we move tracing setup after checking that the root is not NULL. Setting the rootid to 0 at least gives us the possibility to trace this call even in the case when the root is NULL, so that's the solution taken here.(CVE-2025-71184)
In the Linux kernel, the following vulnerability has been resolved:
fbdev: udlfb: avoid divide-by-zero on FBIOPUT_VSCREENINFO
Much like commit 19f953e74356 ("fbdev: fb_pm2fb: Avoid potential divide by zero error"), we also need to prevent that same crash from happening in the udlfb driver as it uses pixclock directly when dividing, which will crash.(CVE-2026-31605)
In the Linux kernel, the following vulnerability has been resolved:
usbip: validate number_of_packets in usbip_pack_ret_submit()
When a USB/IP client receives a RET_SUBMIT response, usbip_pack_ret_submit() unconditionally overwrites urb->number_of_packets from the network PDU. This value is subsequently used as the loop bound in usbip_recv_iso() and usbip_pad_iso() to iterate over urb->iso_frame_desc[], a flexible array whose size was fixed at URB allocation time based on the original number_of_packets from the CMD_SUBMIT.
A malicious USB/IP server can set number_of_packets in the response to a value larger than what was originally submitted, causing a heap out-of-bounds write when usbip_recv_iso() writes to urb->iso_frame_desc[i] beyond the allocated region.
KASAN confirmed this with kernel 7.0.0-rc5:
BUG: KASAN: slab-out-of-bounds in usbip_recv_iso+0x46a/0x640 Write of size 4 at addr ffff888106351d40 by task vhci_rx/69
The buggy address is located 0 bytes to the right of allocated 320-byte region [ffff888106351c00, ffff888106351d40)
The server side (stub_rx.c) and gadget side (vudc_rx.c) already validate number_of_packets in the CMD_SUBMIT path since commits c6688ef9f297 ("usbip: fix stub_rx: harden CMD_SUBMIT path to handle malicious input") and b78d830f0049 ("usbip: fix vudc_rx: harden CMD_SUBMIT path to handle malicious input"). The server side validates against USBIP_MAX_ISO_PACKETS because no URB exists yet at that point. On the client side we have the original URB, so we can use the tighter bound: the response must not exceed the original number_of_packets.
This mirrors the existing validation of actual_length against transfer_buffer_length in usbip_recv_xbuff(), which checks the response value against the original allocation size.
Kelvin Mbogo's series ("usb: usbip: fix integer overflow in usbip_recv_iso()", v2) hardens the receive-side functions themselves; this patch complements that work by catching the bad value at its source -- in usbip_pack_ret_submit() before the overwrite -- and using the tighter per-URB allocation bound rather than the global USBIP_MAX_ISO_PACKETS limit.
Fix this by checking rpdu->number_of_packets against urb->number_of_packets in usbip_pack_ret_submit() before the overwrite. On violation, clamp to zero so that usbip_recv_iso() and usbip_pad_iso() safely return early.(CVE-2026-31607)
In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: renesas_usb3: validate endpoint index in standard request handlers
The GET_STATUS and SET/CLEAR_FEATURE handlers extract the endpoint number from the host-supplied wIndex without any sort of validation. Fix this up by validating the number of endpoints actually match up with the number the device has before attempting to dereference a pointer based on this math.
This is just like what was done in commit ee0d382feb44 ("usb: gadget: aspeed_udc: validate endpoint index for ast udc") for the aspeed driver.(CVE-2026-31615)
In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: f_phonet: fix skb frags[] overflow in pn_rx_complete()
A broken/bored/mean USB host can overflow the skb_shared_info->frags[] array on a Linux gadget exposing a Phonet function by sending an unbounded sequence of full-page OUT transfers.
pn_rx_complete() finalizes the skb only when req->actual < req->length, where req->length is set to PAGE_SIZE by the gadget. If the host always sends exactly PAGE_SIZE bytes per transfer, fp->rx.skb will never be reset and each completion will add another fragment via skb_add_rx_frag(). Once nr_frags exceeds MAX_SKB_FRAGS (default 17), subsequent frag stores overwrite memory adjacent to the shinfo on the heap.
Drop the skb and account a length error when the frag limit is reached, matching the fix applied in t7xx by commit f0813bcd2d9d ("net: wwan: t7xx: fix potential skb->frags overflow in RX path").(CVE-2026-31616)
In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: f_ncm: validate minimum block_len in ncm_unwrap_ntb()
The block_len read from the host-supplied NTB header is checked against ntb_max but has no lower bound. When block_len is smaller than opts->ndp_size, the bounds check of: ndp_index > (block_len - opts->ndp_size) will underflow producing a huge unsigned value that ndp_index can never exceed, defeating the check entirely.
The same underflow occurs in the datagram index checks against block_len - opts->dpe_size. With those checks neutered, a malicious USB host can choose ndp_index and datagram offsets that point past the actual transfer, and the skb_put_data() copies adjacent kernel memory into the network skb.
Fix this by rejecting block lengths that cannot hold at least the NTB header plus one NDP. This will make block_len - opts->ndp_size and block_len - opts->dpe_size both well-defined.
Commit 8d2b1a1ec9f5 ("CDC-NCM: avoid overflow in sanity checking") fixed a related class of issues on the host side of NCM.(CVE-2026-31617)
In the Linux kernel, the following vulnerability has been resolved:
fbdev: tdfxfb: avoid divide-by-zero on FBIOPUT_VSCREENINFO
Much like commit 19f953e74356 ("fbdev: fb_pm2fb: Avoid potential divide by zero error"), we also need to prevent that same crash from happening in the udlfb driver as it uses pixclock directly when dividing, which will crash.(CVE-2026-31618)
In the Linux kernel, the following vulnerability has been resolved:
net/packet: fix TOCTOU race on mmap'd vnet_hdr in tpacket_snd()
In tpacket_snd(), when PACKET_VNET_HDR is enabled, vnet_hdr points directly into the mmap'd TX ring buffer shared with userspace. The kernel validates the header via __packet_snd_vnet_parse() but then re-reads all fields later in virtio_net_hdr_to_skb(). A concurrent userspace thread can modify the vnet_hdr fields between validation and use, bypassing all safety checks.
The non-TPACKET path (packet_snd()) already correctly copies vnet_hdr to a stack-local variable. All other vnet_hdr consumers in the kernel (tun.c, tap.c, virtio_net.c) also use stack copies. The TPACKET TX path is the only caller of virtio_net_hdr_to_skb() that reads directly from user-controlled shared memory.
Fix this by copying vnet_hdr from the mmap'd ring buffer to a stack-local variable before validation and use, consistent with the approach used in packet_snd() and all other callers.(CVE-2026-31700)
In the Linux kernel, the following vulnerability has been resolved:
Buffer overflow in drivers/xen/sys-hypervisor.c
The build id returned by HYPERVISOR_xen_version(XENVER_build_id) is neither NUL terminated nor a string.
The first causes a buffer overflow as sprintf in buildid_show will read and copy till it finds a NUL.
00000000 f4 91 51 f4 dd 38 9e 9d 65 47 52 eb 10 71 db 50 |..Q..8..eGR..q.P| 00000010 b9 a8 01 42 6f 2e 32 |...Bo.2| 00000017
So use a memcpy instead of sprintf to have the correct value:
00000000 f4 91 51 f4 dd 00 9e 9d 65 47 52 eb 10 71 db 50 |..Q.....eGR..q.P| 00000010 b9 a8 01 42 |...B| 00000014
(the above have a hack to embed a zero inside and check it's returned correctly).
This is XSA-485 / CVE-2026-31786(CVE-2026-31786)
In the Linux kernel, the following vulnerability has been resolved:
crypto: algif_aead - Fix minimum RX size check for decryption
The check for the minimum receive buffer size did not take the tag size into account during decryption. Fix this by adding the required extra length.(CVE-2026-43077)
In the Linux kernel, the following vulnerability has been resolved:
crypto: af_alg - Fix page reassignment overflow in af_alg_pull_tsgl
When page reassignment was added to af_alg_pull_tsgl the original loop wasn't updated so it may try to reassign one more page than necessary.
Add the check to the reassignment so that this does not happen.
Also update the comment which still refers to the obsolete offset argument.(CVE-2026-43078)
In the Linux kernel, the following vulnerability has been resolved:
xfrm: Wait for RCU readers during policy netns exit
xfrm_policy_fini() frees the policy_bydst hash tables after flushing the policy work items and deleting all policies, but it does not wait for concurrent RCU readers to leave their read-side critical sections first.
The policy_bydst tables are published via rcu_assign_pointer() and are looked up through rcu_dereference_check(), so netns teardown must also wait for an RCU grace period before freeing the table memory.
Fix this by adding synchronize_rcu() before freeing the policy hash tables.(CVE-2026-43091)
In the Linux kernel, the following vulnerability has been resolved:
xsk: tighten UMEM headroom validation to account for tailroom and min frame
The current headroom validation in xdp_umem_reg() could leave us with insufficient space dedicated to even receive minimum-sized ethernet frame. Furthermore if multi-buffer would come to play then skb_shared_info stored at the end of XSK frame would be corrupted.
HW typically works with 128-aligned sizes so let us provide this value as bare minimum.
Multi-buffer setting is known later in the configuration process so besides accounting for 128 bytes, let us also take care of tailroom space upfront.(CVE-2026-43093)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: ctnetlink: ensure safe access to master conntrack
Holding reference on the expectation is not sufficient, the master conntrack object can just go away, making exp->master invalid.
To access exp->master safely:
-
Grab the nf_conntrack_expect_lock, this gets serialized with clean_from_lists() which also holds this lock when the master conntrack goes away.
-
Hold reference on master conntrack via nf_conntrack_find_get(). Not so easy since the master tuple to look up for the master conntrack is not available in the existing problematic paths.
This patch goes for extending the nf_conntrack_expect_lock section to address this issue for simplicity, in the cases that are described below this is just slightly extending the lock section.
The add expectation command already holds a reference to the master conntrack from ctnetlink_create_expect().
However, the delete expectation command needs to grab the spinlock before looking up for the expectation. Expand the existing spinlock section to address this to cover the expectation lookup. Note that, the nf_ct_expect_iterate_net() calls already grabs the spinlock while iterating over the expectation table, which is correct.
The get expectation command needs to grab the spinlock to ensure master conntrack does not go away. This also expands the existing spinlock section to cover the expectation lookup too. I needed to move the netlink skb allocation out of the spinlock to keep it GFP_KERNEL.
For the expectation events, the IPEXP_DESTROY event is already delivered under the spinlock, just move the delivery of IPEXP_NEW under the spinlock too because the master conntrack event cache is reached through exp->master.
While at it, add lockdep notations to help identify what codepaths need to grab the spinlock.(CVE-2026-43116)
In the Linux kernel, the following vulnerability has been resolved:
dlm: validate length in dlm_search_rsb_tree
The len parameter in dlm_dump_rsb_name() is not validated and comes from network messages. When it exceeds DLM_RESNAME_MAXLEN, it can cause out-of-bounds write in dlm_search_rsb_tree().
Add length validation to prevent potential buffer overflow.(CVE-2026-43125)
In the Linux kernel, the following vulnerability has been resolved:
iommu/vt-d: Flush dev-IOTLB only when PCIe device is accessible in scalable mode
Commit 4fc82cd907ac ("iommu/vt-d: Don't issue ATS Invalidation request when device is disconnected") relies on pci_dev_is_disconnected() to skip ATS invalidation for safely-removed devices, but it does not cover link-down caused by faults, which can still hard-lock the system.
For example, if a VM fails to connect to the PCIe device, "virsh destroy" is executed to release resources and isolate the fault, but a hard-lockup occurs while releasing the group fd.
Call Trace: qi_submit_sync qi_flush_dev_iotlb intel_pasid_tear_down_entry device_block_translation blocking_domain_attach_dev __iommu_attach_device __iommu_device_set_domain __iommu_group_set_domain_internal iommu_detach_group vfio_iommu_type1_detach_group vfio_group_detach_container vfio_group_fops_release __fput
Although pci_device_is_present() is slower than pci_dev_is_disconnected(), it still takes only ~70 µs on a ConnectX-5 (8 GT/s, x2) and becomes even faster as PCIe speed and width increase.
Besides, devtlb_invalidation_with_pasid() is called only in the paths below, which are far less frequent than memory map/unmap.
- mm-struct release
- {attach,release}_dev
- set/remove PASID
- dirty-tracking setup
The gain in system stability far outweighs the negligible cost of using pci_device_is_present() instead of pci_dev_is_disconnected() to decide when to skip ATS invalidation, especially under GDR high-load conditions.(CVE-2026-43130)
In the Linux kernel, the following vulnerability has been resolved:
xfrm6: fix uninitialized saddr in xfrm6_get_saddr()
xfrm6_get_saddr() does not check the return value of ipv6_dev_get_saddr(). When ipv6_dev_get_saddr() fails to find a suitable source address (returns -EADDRNOTAVAIL), saddr->in6 is left uninitialized, but xfrm6_get_saddr() still returns 0 (success).
This causes the caller xfrm_tmpl_resolve_one() to use the uninitialized address in xfrm_state_find(), triggering KMSAN warning:
===================================================== BUG: KMSAN: uninit-value in xfrm_state_find+0x2424/0xa940 xfrm_state_find+0x2424/0xa940 xfrm_resolve_and_create_bundle+0x906/0x5a20 xfrm_lookup_with_ifid+0xcc0/0x3770 xfrm_lookup_route+0x63/0x2b0 ip_route_output_flow+0x1ce/0x270 udp_sendmsg+0x2ce1/0x3400 inet_sendmsg+0x1ef/0x2a0 __sock_sendmsg+0x278/0x3d0 __sys_sendto+0x593/0x720 __x64_sys_sendto+0x130/0x200 x64_sys_call+0x332b/0x3e70 do_syscall_64+0xd3/0xf80 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Local variable tmp.i.i created at: xfrm_resolve_and_create_bundle+0x3e3/0x5a20 xfrm_lookup_with_ifid+0xcc0/0x3770 =====================================================
Fix by checking the return value of ipv6_dev_get_saddr() and propagating the error.(CVE-2026-43139)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: xt_tcpmss: check remaining length before reading optlen
Quoting reporter: In net/netfilter/xt_tcpmss.c (lines 53-68), the TCP option parser reads op[i+1] directly without validating the remaining option length.
If the last byte of the option field is not EOL/NOP (0/1), the code attempts to index op[i+1]. In the case where i + 1 == optlen, this causes an out-of-bounds read, accessing memory past the optlen boundary (either reading beyond the stack buffer _opt or the following payload).(CVE-2026-43190)
In the Linux kernel, the following vulnerability has been resolved:
tcp: fix potential race in tcp_v6_syn_recv_sock()
Code in tcp_v6_syn_recv_sock() after the call to tcp_v4_syn_recv_sock() is done too late.
After tcp_v4_syn_recv_sock(), the child socket is already visible from TCP ehash table and other cpus might use it.
Since newinet->pinet6 is still pointing to the listener ipv6_pinfo bad things can happen as syzbot found.
Move the problematic code in tcp_v6_mapped_child_init() and call this new helper from tcp_v4_syn_recv_sock() before the ehash insertion.
This allows the removal of one tcp_sync_mss(), since tcp_v4_syn_recv_sock() will call it with the correct context.(CVE-2026-43198)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_conntrack_h323: fix OOB read in decode_choice()
In decode_choice(), the boundary check before get_len() uses the
variable len, which is still 0 from its initialization at the top of
the function:
unsigned int type, ext, len = 0;
...
if (ext || (son->attr & OPEN)) {
BYTE_ALIGN(bs);
if (nf_h323_error_boundary(bs, len, 0)) /* len is 0 here */
return H323_ERROR_BOUND;
len = get_len(bs); /* OOB read */
When the bitstream is exactly consumed (bs->cur == bs->end), the check nf_h323_error_boundary(bs, 0, 0) evaluates to (bs->cur + 0 > bs->end), which is false. The subsequent get_len() call then dereferences *bs->cur++, reading 1 byte past the end of the buffer. If that byte has bit 7 set, get_len() reads a second byte as well.
This can be triggered remotely by sending a crafted Q.931 SETUP message with a User-User Information Element containing exactly 2 bytes of PER-encoded data ({0x08, 0x00}) to port 1720 through a firewall with the nf_conntrack_h323 helper active. The decoder fully consumes the PER buffer before reaching this code path, resulting in a 1-2 byte heap-buffer-overflow read confirmed by AddressSanitizer.
Fix this by checking for 2 bytes (the maximum that get_len() may read)
instead of the uninitialized len. This matches the pattern used at
every other get_len() call site in the same file, where the caller
checks for 2 bytes of available data before calling get_len().(CVE-2026-43233)
In the Linux kernel, the following vulnerability has been resolved:
iommu/amd: move wait_on_sem() out of spinlock
With iommu.strict=1, the existing completion wait path can cause soft lockups under stressed environment, as wait_on_sem() busy-waits under the spinlock with interrupts disabled.
Move the completion wait in iommu_completion_wait() out of the spinlock. wait_on_sem() only polls the hardware-updated cmd_sem and does not require iommu->lock, so holding the lock during the busy wait unnecessarily increases contention and extends the time with interrupts disabled.(CVE-2026-43253)
In the Linux kernel, the following vulnerability has been resolved:
spi: spidev: fix lock inversion between spi_lock and buf_lock
The spidev driver previously used two mutexes, spi_lock and buf_lock, but acquired them in different orders depending on the code path:
write()/read(): buf_lock -> spi_lock ioctl(): spi_lock -> buf_lock
This AB-BA locking pattern triggers lockdep warnings and can cause real deadlocks:
WARNING: possible circular locking dependency detected spidev_ioctl() -> mutex_lock(&spidev->buf_lock) spidev_sync_write() -> mutex_lock(&spidev->spi_lock) *** DEADLOCK ***
The issue is reproducible with a simple userspace program that performs write() and SPI_IOC_WR_MAX_SPEED_HZ ioctl() calls from separate threads on the same spidev file descriptor.
Fix this by simplifying the locking model and removing the lock inversion entirely. spidev_sync() no longer performs any locking, and all callers serialize access using spi_lock.
buf_lock is removed since its functionality is fully covered by spi_lock, eliminating the possibility of lock ordering issues.
This removes the lock inversion and prevents deadlocks without changing userspace ABI or behaviour.(CVE-2026-43319)
In the Linux kernel, the following vulnerability has been resolved:
ipv6: prevent possible UaF in addrconf_permanent_addr()
The mentioned helper try to warn the user about an exceptional condition, but the message is delivered too late, accessing the ipv6 after its possible deletion.
Reorder the statement to avoid the possible UaF; while at it, place the warning outside the idev->lock as it needs no protection.(CVE-2026-43339)
In the Linux kernel, the following vulnerability has been resolved:
net/tcp-md5: Fix MAC comparison to be constant-time
To prevent timing attacks, MACs need to be compared in constant time. Use the appropriate helper function for this.(CVE-2026-43383)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nfnetlink_cthelper: fix OOB read in nfnl_cthelper_dump_table()
nfnl_cthelper_dump_table() has a 'goto restart' that jumps to a label inside the for loop body. When the "last" helper saved in cb->args[1] is deleted between dump rounds, every entry fails the (cur != last) check, so cb->args[1] is never cleared. The for loop finishes with cb->args[0] == nf_ct_helper_hsize, and the 'goto restart' jumps back into the loop body bypassing the bounds check, causing an 8-byte out-of-bounds read on nf_ct_helper_hash[nf_ct_helper_hsize].
The 'goto restart' block was meant to re-traverse the current bucket when "last" is no longer found, but it was placed after the for loop instead of inside it. Move the block into the for loop body so that the restart only occurs while cb->args[0] is still within bounds.
BUG: KASAN: slab-out-of-bounds in nfnl_cthelper_dump_table+0x9f/0x1b0 Read of size 8 at addr ffff888104ca3000 by task poc_cthelper/131 Call Trace: nfnl_cthelper_dump_table+0x9f/0x1b0 netlink_dump+0x333/0x880 netlink_recvmsg+0x3e2/0x4b0 sock_recvmsg+0xde/0xf0 __sys_recvfrom+0x150/0x200 __x64_sys_recvfrom+0x76/0x90 do_syscall_64+0xc3/0x6e0
Allocated by task 1: __kvmalloc_node_noprof+0x21b/0x700 nf_ct_alloc_hashtable+0x65/0xd0 nf_conntrack_helper_init+0x21/0x60 nf_conntrack_init_start+0x18d/0x300 nf_conntrack_standalone_init+0x12/0xc0(CVE-2026-43450)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: x_tables: guard option walkers against 1-byte tail reads
When the last byte of options is a non-single-byte option kind, walkers that advance with i += op[i + 1] ? : 1 can read op[i + 1] past the end of the option area.
Add an explicit i == optlen - 1 check before dereferencing op[i + 1] in xt_tcpudp and xt_dccp option walkers.(CVE-2026-43452)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nft_set_pipapo: fix stack out-of-bounds read in pipapo_drop()
pipapo_drop() passes rulemap[i + 1].n to pipapo_unmap() as the to_offset argument on every iteration, including the last one where i == m->field_count - 1. This reads one element past the end of the stack-allocated rulemap array (declared as rulemap[NFT_PIPAPO_MAX_FIELDS] with NFT_PIPAPO_MAX_FIELDS == 16).
Although pipapo_unmap() returns early when is_last is true without using the to_offset value, the argument is evaluated at the call site before the function body executes, making this a genuine out-of-bounds stack read confirmed by KASAN:
BUG: KASAN: stack-out-of-bounds in pipapo_drop+0x50c/0x57c [nf_tables] Read of size 4 at addr ffff8000810e71a4
This frame has 1 object: [32, 160) 'rulemap'
The buggy address is at offset 164 -- exactly 4 bytes past the end of the rulemap array.
Pass 0 instead of rulemap[i + 1].n on the last iteration to avoid the out-of-bounds read.(CVE-2026-43453)
In the Linux kernel, the following vulnerability has been resolved:
rtmutex: Use waiter::task instead of current in remove_waiter()
remove_waiter() is used by the slowlock paths, but it is also used for proxy-lock rollback in rt_mutex_start_proxy_lock() when invoked from futex_requeue().
In the latter case waiter::task is not current, but remove_waiter() operates on current for the dequeue operation. That results in several problems:
1) the rbtree dequeue happens without waiter::task::pi_lock being held
2) the waiter task's pi_blocked_on state is not cleared, which leaves a dangling pointer primed for UAF around.
3) rt_mutex_adjust_prio_chain() operates on the wrong top priority waiter task
Use waiter::task instead of current in all related operations in remove_waiter() to cure those problems.
tglx: Fixup rt_mutex_adjust_prio_chain(), add a comment and amend the changelog
In the Linux kernel, the following vulnerability has been resolved:
openvswitch: cap upcall PID array size and pre-size vport replies
The vport netlink reply helpers allocate a fixed-size skb with nlmsg_new(NLMSG_DEFAULT_SIZE, ...) but serialize the full upcall PID array via ovs_vport_get_upcall_portids(). Since ovs_vport_set_upcall_portids() accepts any non-zero multiple of sizeof(u32) with no upper bound, a CAP_NET_ADMIN user can install a PID array large enough to overflow the reply buffer, causing nla_put() to fail with -EMSGSIZE and hitting BUG_ON(err < 0). On systems with unprivileged user namespaces enabled (e.g., Ubuntu default), this is reachable via unshare -Urn since OVS vport mutation operations use GENL_UNS_ADMIN_PERM.
kernel BUG at net/openvswitch/datapath.c:2414! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI CPU: 1 UID: 0 PID: 65 Comm: poc Not tainted 7.0.0-rc7-00195-geb216e422044 #1 RIP: 0010:ovs_vport_cmd_set+0x34c/0x400 Call Trace: <TASK> genl_family_rcv_msg_doit (net/netlink/genetlink.c:1116) genl_rcv_msg (net/netlink/genetlink.c:1194) netlink_rcv_skb (net/netlink/af_netlink.c:2550) genl_rcv (net/netlink/genetlink.c:1219) netlink_unicast (net/netlink/af_netlink.c:1344) netlink_sendmsg (net/netlink/af_netlink.c:1894) __sys_sendto (net/socket.c:2206) __x64_sys_sendto (net/socket.c:2209) do_syscall_64 (arch/x86/entry/syscall_64.c:63) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) </TASK> Kernel panic - not syncing: Fatal exception
Reject attempts to set more PIDs than nr_cpu_ids in ovs_vport_set_upcall_portids(), and pre-compute the worst-case reply size in ovs_vport_cmd_msg_size() based on that bound, similar to the existing ovs_dp_cmd_msg_size(). nr_cpu_ids matches the cap already used by the per-CPU dispatch configuration on the datapath side (ovs_dp_cmd_fill_info() serialises at most nr_cpu_ids PIDs), so the two sides stay consistent.(CVE-2026-45840)
In the Linux kernel, the following vulnerability has been resolved:
slip: bound decode() reads against the compressed packet length
slhc_uncompress() parses a VJ-compressed TCP header by advancing a pointer through the packet via decode() and pull16(). Neither helper bounds-checks against isize, and decode() masks its return with & 0xffff so it can never return the -1 that callers test for -- those error paths are dead code.
A short compressed frame whose change byte requests optional fields lets decode() read past the end of the packet. The over-read bytes are folded into the cached cstate and reflected into subsequent reconstructed packets.
Make decode() and pull16() take the packet end pointer and return -1 when exhausted. Add a bounds check before the TCP-checksum read. The existing == -1 tests now do what they were always meant to.(CVE-2026-45843)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/rxe: Fix double free in rxe_srq_from_init
In rxe_srq_from_init(), the queue pointer 'q' is assigned to 'srq->rq.queue' before copying the SRQ number to user space. If copy_to_user() fails, the function calls rxe_queue_cleanup() to free the queue, but leaves the now-invalid pointer in 'srq->rq.queue'.
The caller of rxe_srq_from_init() (rxe_create_srq) eventually calls rxe_srq_cleanup() upon receiving the error, which triggers a second rxe_queue_cleanup() on the same memory, leading to a double free.
The call trace looks like this: kmem_cache_free+0x.../0x... rxe_queue_cleanup+0x1a/0x30 [rdma_rxe] rxe_srq_cleanup+0x42/0x60 [rdma_rxe] rxe_elem_release+0x31/0x70 [rdma_rxe] rxe_create_srq+0x12b/0x1a0 [rdma_rxe] ib_create_srq_user+0x9a/0x150 [ib_core]
Fix this by moving 'srq->rq.queue = q' after copy_to_user.(CVE-2026-45852)
In the Linux kernel, the following vulnerability has been resolved:
iommu/vt-d: Flush cache for PASID table before using it
When writing the address of a freshly allocated zero-initialized PASID table to a PASID directory entry, do that after the CPU cache flush for this PASID table, not before it, to avoid the time window when this PASID table may be already used by non-coherent IOMMU hardware while its contents in RAM is still some random old data, not zero-initialized.(CVE-2026-45862)
In the Linux kernel, the following vulnerability has been resolved:
iommu/vt-d: Clear Present bit before tearing down PASID entry
The Intel VT-d Scalable Mode PASID table entry consists of 512 bits (64 bytes). When tearing down an entry, the current implementation zeros the entire 64-byte structure immediately using multiple 64-bit writes.
Since the IOMMU hardware may fetch these 64 bytes using multiple internal transactions (e.g., four 128-bit bursts), updating or zeroing the entire entry while it is active (P=1) risks a "torn" read. If a hardware fetch occurs simultaneously with the CPU zeroing the entry, the hardware could observe an inconsistent state, leading to unpredictable behavior or spurious faults.
Follow the "Guidance to Software for Invalidations" in the VT-d spec (Section 6.5.3.3) by implementing the recommended ownership handshake:
- Clear only the 'Present' (P) bit of the PASID entry.
- Use a dma_wmb() to ensure the cleared bit is visible to hardware before proceeding.
- Execute the required invalidation sequence (PASID cache, IOTLB, and Device-TLB flush) to ensure the hardware has released all cached references.
- Only after the flushes are complete, zero out the remaining fields of the PASID entry.
Also, add a dma_wmb() in pasid_set_present() to ensure that all other fields of the PASID entry are visible to the hardware before the Present bit is set.(CVE-2026-45894)
In the Linux kernel, the following vulnerability has been resolved:
xfrm: fix ip_rt_bug race in icmp_route_lookup reverse path
icmp_route_lookup() performs multiple route lookups to find a suitable route for sending ICMP error messages, with special handling for XFRM (IPsec) policies.
The lookup sequence is: 1. First, lookup output route for ICMP reply (dst = original src) 2. Pass through xfrm_lookup() for policy check 3. If blocked (-EPERM) or dst is not local, enter "reverse path" 4. In reverse path, call xfrm_decode_session_reverse() to get fl4_dec which reverses the original packet's flow (saddr<->daddr swapped) 5. If fl4_dec.saddr is local (we are the original destination), use __ip_route_output_key() for output route lookup 6. If fl4_dec.saddr is NOT local (we are a forwarding node), use ip_route_input() to simulate the reverse packet's input path 7. Finally, pass rt2 through xfrm_lookup() with XFRM_LOOKUP_ICMP flag
The bug occurs in step 6: ip_route_input() is called with fl4_dec.daddr (original packet's source) as destination. If this address becomes local between the initial check and ip_route_input() call (e.g., due to concurrent "ip addr add"), ip_route_input() returns a LOCAL route with dst.output set to ip_rt_bug.
This route is then used for ICMP output, causing dst_output() to call ip_rt_bug(), triggering a WARN_ON:
------------[ cut here ]------------ WARNING: net/ipv4/route.c:1275 at ip_rt_bug+0x21/0x30, CPU#1 Call Trace: <TASK> ip_push_pending_frames+0x202/0x240 icmp_push_reply+0x30d/0x430 __icmp_send+0x1149/0x24f0 ip_options_compile+0xa2/0xd0 ip_rcv_finish_core+0x829/0x1950 ip_rcv+0x2d7/0x420 __netif_receive_skb_one_core+0x185/0x1f0 netif_receive_skb+0x90/0x450 tun_get_user+0x3413/0x3fb0 tun_chr_write_iter+0xe4/0x220 ...
Fix this by checking rt2->rt_type after ip_route_input(). If it's RTN_LOCAL, the route cannot be used for output, so treat it as an error.
The reproducer requires kernel modification to widen the race window, making it unsuitable as a selftest. It is available at:
https://gist.github.com/mrpre/eae853b72ac6a750f5d45d64ddac1e81(CVE-2026-45905)
In the Linux kernel, the following vulnerability has been resolved:
Revert "hwmon: (ibmpex) fix use-after-free in high/low store"
This reverts commit 6946c726c3f4c36f0f049e6f97e88c510b15f65d.
Jean Delvare points out that the patch does not completely fix the reported problem, that it in fact introduces a (new) race condition, and that it may actually not be needed in the first place.
Various AI reviews agree. Specific and relevant AI feedback:
" This reordering sets the driver data to NULL before removing the sensor attributes in the loop below.
ibmpex_show_sensor() retrieves this driver data via dev_get_drvdata() but does not check if it is NULL before dereferencing it to access data->sensors[].
If a userspace process reads a sensor file (like temp1_input) while this delete function is running, could it race with the dev_set_drvdata(..., NULL) call here and crash in ibmpex_show_sensor()?
Would it be safer to keep the original order where device_remove_file() is called before clearing the driver data? device_remove_file() should wait for any active sysfs callbacks to complete, which might already prevent the use-after-free this patch intends to fix. "
Revert the offending patch. If it can be shown that the originally reported alleged race condition does indeed exist, it can always be re-introduced with a complete fix.(CVE-2026-45914)
In the Linux kernel, the following vulnerability has been resolved:
fat: avoid parent link count underflow in rmdir
Corrupted FAT images can leave a directory inode with an incorrect i_nlink (e.g. 2 even though subdirectories exist). rmdir then unconditionally calls drop_nlink(dir) and can drive i_nlink to 0, triggering the WARN_ON in drop_nlink().
Add a sanity check in vfat_rmdir() and msdos_rmdir(): only drop the parent link count when it is at least 3, otherwise report a filesystem error.(CVE-2026-45915)
In the Linux kernel, the following vulnerability has been resolved:
sched/rt: Skip currently executing CPU in rto_next_cpu()
CPU0 becomes overloaded when hosting a CPU-bound RT task, a non-CPU-bound RT task, and a CFS task stuck in kernel space. When other CPUs switch from RT to non-RT tasks, RT load balancing (LB) is triggered; with HAVE_RT_PUSH_IPI enabled, they send IPIs to CPU0 to drive the execution of rto_push_irq_work_func. During push_rt_task on CPU0, if next_task->prio < rq->donor->prio, resched_curr() sets NEED_RESCHED and after the push operation completes, CPU0 calls rto_next_cpu(). Since only CPU0 is overloaded in this scenario, rto_next_cpu() should ideally return -1 (no further IPI needed).
However, multiple CPUs invoking tell_cpu_to_push() during LB increments rd->rto_loop_next. Even when rd->rto_cpu is set to -1, the mismatch between rd->rto_loop and rd->rto_loop_next forces rto_next_cpu() to restart its search from -1. With CPU0 remaining overloaded (satisfying rt_nr_migratory && rt_nr_total > 1), it gets reselected, causing CPU0 to queue irq_work to itself and send self-IPIs repeatedly. As long as CPU0 stays overloaded and other CPUs run pull_rt_tasks(), it falls into an infinite self-IPI loop, which triggers a CPU hardlockup due to continuous self-interrupts.
The trigging scenario is as follows:
cpu0 cpu1 cpu2
pull_rt_task
tell_cpu_to_push
<------------irq_work_queue_on
rto_push_irq_work_func push_rt_task resched_curr(rq) pull_rt_task rto_next_cpu tell_cpu_to_push <-------------------------- atomic_inc(rto_loop_next) rd->rto_loop != next rto_next_cpu irq_work_queue_on rto_push_irq_work_func
Fix redundant self-IPI by filtering the initiating CPU in rto_next_cpu(). This solution has been verified to effectively eliminate spurious self-IPIs and prevent CPU hardlockup scenarios.(CVE-2026-45919)
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix dirtyclusters double decrement on fs shutdown
fstests test generic/388 occasionally reproduces a warning in ext4_put_super() associated with the dirty clusters count:
WARNING: CPU: 7 PID: 76064 at fs/ext4/super.c:1324 ext4_put_super+0x48c/0x590 [ext4]
Tracing the failure shows that the warning fires due to an s_dirtyclusters_counter value of -1. IOW, this appears to be a spurious decrement as opposed to some sort of leak. Further tracing of the dirty cluster count deltas and an LLM scan of the resulting output identified the cause as a double decrement in the error path between ext4_mb_mark_diskspace_used() and the caller ext4_mb_new_blocks().
First, note that generic/388 is a shutdown vs. fsstress test and so produces a random set of operations and shutdown injections. In the problematic case, the shutdown triggers an error return from the ext4_handle_dirty_metadata() call(s) made from ext4_mb_mark_context(). The changed value is non-zero at this point, so ext4_mb_mark_diskspace_used() does not exit after the error bubbles up from ext4_mb_mark_context(). Instead, the former decrements both cluster counters and returns the error up to ext4_mb_new_blocks(). The latter falls into the !ar->len out path which decrements the dirty clusters counter a second time, creating the inconsistency.
To avoid this problem and simplify ownership of the cluster reservation in this codepath, lift the counter reduction to a single place in the caller. This makes it more clear that ext4_mb_new_blocks() is responsible for acquiring cluster reservation (via ext4_claim_free_clusters()) in the !delalloc case as well as releasing it, regardless of whether it ends up consumed or returned due to failure.(CVE-2026-45920)
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Fix slab-out-of-bounds read in DeleteIndexEntryRoot
In the 'DeleteIndexEntryRoot' case of the 'do_action' function, the entry size ('esize') is retrieved from the log record without adequate bounds checking.
Specifically, the code calculates the end of the entry ('e2') using: e2 = Add2Ptr(e1, esize);
It then calculates the size for memmove using 'PtrOffset(e2, ...)', which subtracts the end pointer from the buffer limit. If 'esize' is maliciously large, 'e2' exceeds the used buffer size. This results in a negative offset which, when cast to size_t for memmove, interprets as a massive unsigned integer, leading to a heap buffer overflow.
This commit adds a check to ensure that the entry size ('esize') strictly fits within the remaining used space of the index header before performing memory operations.(CVE-2026-45935)
In the Linux kernel, the following vulnerability has been resolved:
iommu/vt-d: Clear Present bit before tearing down context entry
When tearing down a context entry, the current implementation zeros the entire 128-bit entry using multiple 64-bit writes. This creates a window where the hardware can fetch a "torn" entry — where some fields are already zeroed while the 'Present' bit is still set — leading to unpredictable behavior or spurious faults.
While x86 provides strong write ordering, the compiler may reorder writes to the two 64-bit halves of the context entry. Even without compiler reordering, the hardware fetch is not guaranteed to be atomic with respect to multiple CPU writes.
Align with the "Guidance to Software for Invalidations" in the VT-d spec (Section 6.5.3.3) by implementing the recommended ownership handshake:
- Clear only the 'Present' (P) bit of the context entry first to signal the transition of ownership from hardware to software.
- Use dma_wmb() to ensure the cleared bit is visible to the IOMMU.
- Perform the required cache and context-cache invalidation to ensure hardware no longer has cached references to the entry.
- Fully zero out the entry only after the invalidation is complete.
Also, add a dma_wmb() to context_set_present() to ensure the entry is fully initialized before the 'Present' bit becomes visible.(CVE-2026-45944)
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix memory leak in ext4_ext_shift_extents()
In ext4_ext_shift_extents(), if the extent is NULL in the while loop, the function returns immediately without releasing the path obtained via ext4_find_extent(), leading to a memory leak.
Fix this by jumping to the out label to ensure the path is properly released.(CVE-2026-45948)
In the Linux kernel, the following vulnerability has been resolved:
nfsd: never defer requests during idmap lookup
During v4 request compound arg decoding, some ops (e.g. SETATTR) can trigger idmap lookup upcalls. When those upcall responses get delayed beyond the allowed time limit, cache_check() will mark the request for deferral and cause it to be dropped.
This prevents nfs4svc_encode_compoundres from being executed, and thus the session slot flag NFSD4_SLOT_INUSE never gets cleared. Subsequent client requests will fail with NFSERR_JUKEBOX, given that the slot will be marked as in-use, making the SEQUENCE op fail.
Fix this by making sure that the RQ_USEDEFERRAL flag is always clear during nfs4svc_decode_compoundargs(), since no v4 request should ever be deferred.(CVE-2026-45983)
In the Linux kernel, the following vulnerability has been resolved:
ext4: don't set EXT4_GET_BLOCKS_CONVERT when splitting before submitting I/O
When allocating blocks during within-EOF DIO and writeback with dioread_nolock enabled, EXT4_GET_BLOCKS_PRE_IO was set to split an existing large unwritten extent. However, EXT4_GET_BLOCKS_CONVERT was set when calling ext4_split_convert_extents(), which may potentially result in stale data issues.
Assume we have an unwritten extent, and then DIO writes the second half.
[UUUUUUUUUUUUUUUU] on-disk extent U: unwritten extent [UUUUUUUUUUUUUUUU] extent status tree |<- ->| ----> dio write this range
First, ext4_iomap_alloc() call ext4_map_blocks() with EXT4_GET_BLOCKS_PRE_IO, EXT4_GET_BLOCKS_UNWRIT_EXT and EXT4_GET_BLOCKS_CREATE flags set. ext4_map_blocks() find this extent and call ext4_split_convert_extents() with EXT4_GET_BLOCKS_CONVERT and the above flags set.
Then, ext4_split_convert_extents() calls ext4_split_extent() with EXT4_EXT_MAY_ZEROOUT, EXT4_EXT_MARK_UNWRIT2 and EXT4_EXT_DATA_VALID2 flags set, and it calls ext4_split_extent_at() to split the second half with EXT4_EXT_DATA_VALID2, EXT4_EXT_MARK_UNWRIT1, EXT4_EXT_MAY_ZEROOUT and EXT4_EXT_MARK_UNWRIT2 flags set. However, ext4_split_extent_at() failed to insert extent since a temporary lack -ENOSPC. It zeroes out the first half but convert the entire on-disk extent to written since the EXT4_EXT_DATA_VALID2 flag set, but left the second half as unwritten in the extent status tree.
[0000000000SSSSSS] data S: stale data, 0: zeroed [WWWWWWWWWWWWWWWW] on-disk extent W: written extent [WWWWWWWWWWUUUUUU] extent status tree
Finally, if the DIO failed to write data to the disk, the stale data in the second half will be exposed once the cached extent entry is gone.
Fix this issue by not passing EXT4_GET_BLOCKS_CONVERT when splitting an unwritten extent before submitting I/O, and make ext4_split_convert_extents() to zero out the entire extent range to zero for this case, and also mark the extent in the extent status tree for consistency.(CVE-2026-45985)
In the Linux kernel, the following vulnerability has been resolved:
KVM: nSVM: Sync interrupt shadow to cached vmcb12 after VMRUN of L2
After VMRUN in guest mode, nested_sync_control_from_vmcb02() syncs fields written by the CPU from vmcb02 to the cached vmcb12. This is because the cached vmcb12 is used as the authoritative copy of some of the controls, and is the payload when saving/restoring nested state.
int_state is also written by the CPU, specifically bit 0 (i.e. SVM_INTERRUPT_SHADOW_MASK) for nested VMs, but it is not sync'd to cached vmcb12. This does not cause a problem if KVM_SET_NESTED_STATE preceeds KVM_SET_VCPU_EVENTS in the restore path, as an interrupt shadow would be correctly restored to vmcb02 (KVM_SET_VCPU_EVENTS overwrites what KVM_SET_NESTED_STATE restored in int_state).
However, if KVM_SET_VCPU_EVENTS preceeds KVM_SET_NESTED_STATE, an interrupt shadow would be restored into vmcb01 instead of vmcb02. This would mostly be benign for L1 (delays an interrupt), but not for L2. For L2, the vCPU could hang (e.g. if a wakeup interrupt is delivered before a HLT that should have been in an interrupt shadow).
Sync int_state to the cached vmcb12 in nested_sync_control_from_vmcb02() to avoid this problem. With that, KVM_SET_NESTED_STATE restores the correct interrupt shadow state, and if KVM_SET_VCPU_EVENTS follows it would overwrite it with the same value.(CVE-2026-45987)
In the Linux kernel, the following vulnerability has been resolved:
udf: fix partition descriptor append bookkeeping
Mounting a crafted UDF image with repeated partition descriptors can trigger a heap out-of-bounds write in part_descs_loc[].
handle_partition_descriptor() deduplicates entries by partition number, but appended slots never record partnum. As a result duplicate Partition Descriptors are appended repeatedly and num_part_descs keeps growing.
Once the table is full, the growth path still sizes the allocation from partnum even though inserts are indexed by num_part_descs. If partnum is already aligned to PART_DESC_ALLOC_STEP, ALIGN(partnum, step) can keep the old capacity and the next append writes past the end of the table.
Store partnum in the appended slot and size growth from the next append count so deduplication and capacity tracking follow the same model.(CVE-2026-45991)
In the Linux kernel, the following vulnerability has been resolved:
ALSA: usb-audio: stop parsing UAC2 rates at MAX_NR_RATES
parse_uac2_sample_rate_range() caps the number of enumerated rates at MAX_NR_RATES, but it only breaks out of the current rate loop. A malformed UAC2 RANGE response with additional triplets continues parsing the remaining triplets and repeatedly prints "invalid uac2 rates" while probe still holds register_mutex.
Stop the whole parse once the cap is reached and return the number of rates collected so far.(CVE-2026-46018)
In the Linux kernel, the following vulnerability has been resolved:
dm mirror: fix integer overflow in create_dirty_log()
The argument count calculation in create_dirty_log() performs
*args_used = 2 + param_count before validating against argc. When a
user provides a param_count close to UINT_MAX via the device mapper
table string, this unsigned addition wraps around to a small value,
causing the subsequent argc < *args_used check to be bypassed.
The overflowed param_count is then passed as argc to dm_dirty_log_create(), where it can cause out-of-bounds reads on the argv array.
Fix by comparing param_count against argc - 2 before performing the addition, following the same pattern used by parse_features() in the same file. Since argc >= 2 is already guaranteed, the subtraction is safe.(CVE-2026-46023)
In the Linux kernel, the following vulnerability has been resolved:
crypto: algif_aead - snapshot IV for async AEAD requests
AF_ALG AEAD AIO requests currently use the socket-wide IV buffer during request processing. For async requests, later socket activity can update that shared state before the original request has fully completed, which can lead to inconsistent IV handling.
Snapshot the IV into per-request storage when preparing the AEAD request, so in-flight operations no longer depend on mutable socket state.(CVE-2026-46028)
In the Linux kernel, the following vulnerability has been resolved:
KVM: nSVM: Triple fault if restore host CR3 fails on nested #VMEXIT
If loading L1's CR3 fails on a nested #VMEXIT, nested_svm_vmexit() returns an error code that is ignored by most callers, and continues to run L1 with corrupted state. A sane recovery is not possible in this case, and HW behavior is to cause a shutdown. Inject a triple fault instead, and do not return early from nested_svm_vmexit(). Continue cleaning up the vCPU state (e.g. clear pending exceptions), to handle the failure as gracefully as possible.
From the APM:
Upon #VMEXIT, the processor performs the following actions in order to return to the host execution context:
...
if (illegal host state loaded, or exception while loading host state) shutdown else execute first host instruction following the VMRUN
Remove the return value of nested_svm_vmexit(), which is mostly unchecked anyway.(CVE-2026-46032)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/rxe: Validate pad and ICRC before payload_size() in rxe_rcv
rxe_rcv() currently checks only that the incoming packet is at least header_size(pkt) bytes long before payload_size() is used.
However, payload_size() subtracts both the attacker-controlled BTH pad field and RXE_ICRC_SIZE from pkt->paylen:
payload_size = pkt->paylen - offset[RXE_PAYLOAD] - bth_pad(pkt) - RXE_ICRC_SIZE
This means a short packet can still make payload_size() underflow even if it includes enough bytes for the fixed headers. Simply requiring header_size(pkt) + RXE_ICRC_SIZE is not sufficient either, because a packet with a forged non-zero BTH pad can still leave payload_size() negative and pass an underflowed value to later receive-path users.
Fix this by validating pkt->paylen against the full minimum length required by payload_size(): header_size(pkt) + bth_pad(pkt) + RXE_ICRC_SIZE.(CVE-2026-46043)
In the Linux kernel, the following vulnerability has been resolved:
ALSA: ctxfi: Add fallback to default RSR for S/PDIF
spdif_passthru_playback_get_resources() uses atc->pll_rate as the RSR for the MSR calculation loop. However, pll_rate is only updated in atc_pll_init() and not in hw_pll_init(), so it remains 0 after the card init.
When spdif_passthru_playback_setup() skips atc_pll_init() for 32000 Hz, (rsr * desc.msr) always becomes 0, causing the loop to spin indefinitely.
Add fallback to use atc->rsr when atc->pll_rate is 0. This reflects the hardware state, since hw_card_init() already configures the PLL to the default RSR.(CVE-2026-46049)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_event: fix potential UAF in SSP passkey handlers
hci_conn lookup and field access must be covered by hdev lock in hci_user_passkey_notify_evt() and hci_keypress_notify_evt(), otherwise the connection can be freed concurrently.
Extend the hci_dev_lock critical section to cover all conn usage in both handlers.
Keep the existing keypress notification behavior unchanged by routing the early exits through a common unlock path.(CVE-2026-46056)
In the Linux kernel, the following vulnerability has been resolved:
fbdev: defio: Disconnect deferred I/O from the lifetime of struct fb_info
Hold state of deferred I/O in struct fb_deferred_io_state. Allocate an instance as part of initializing deferred I/O and remove it only after the final mapping has been closed. If the fb_info and the contained deferred I/O meanwhile goes away, clear struct fb_deferred_io_state.info to invalidate the mapping. Any access will then result in a SIGBUS signal.
Fixes a long-standing problem, where a device hot-unplug happens while user space still has an active mapping of the graphics memory. The hot- unplug frees the instance of struct fb_info. Accessing the memory will operate on undefined state.(CVE-2026-46065)
In the Linux kernel, the following vulnerability has been resolved:
spi: fix resource leaks on device setup failure
Make sure to call controller cleanup() if spi_setup() fails while registering a device to avoid leaking any resources allocated by setup().(CVE-2026-46083)
In the Linux kernel, the following vulnerability has been resolved:
ALSA: control: Validate buf_len before strnlen() in snd_ctl_elem_init_enum_names()
snd_ctl_elem_init_enum_names() advances pointer p through the names buffer while decrementing buf_len. If buf_len reaches zero but items remain, the next iteration calls strnlen(p, 0).
While strnlen(p, 0) returns 0 and would hit the existing name_len == 0 error path, CONFIG_FORTIFY_SOURCE's fortified strnlen() first checks maxlen against __builtin_dynamic_object_size(). When Clang loses track of p's object size inside the loop, this triggers a BRK exception panic before the return value is examined.
Add a buf_len == 0 guard at the loop entry to prevent calling fortified strnlen() on an exhausted buffer.
Found by kernel fuzz testing through Xiaomi Smartphone.(CVE-2026-46088)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: reject zero shift in nft_bitwise
Reject zero shift operands for nft_bitwise left and right shift expressions during initialization.
The carry propagation logic computes the carry from the adjacent 32-bit word using BITS_PER_TYPE(u32) - shift. A zero shift operand turns this into a 32-bit shift, which is undefined behaviour.
Reject zero shift operands in the control plane, alongside the existing check for values greater than or equal to 32, so malformed rules never reach the packet path.(CVE-2026-46101)
In the Linux kernel, the following vulnerability has been resolved:
net: strparser: fix skb_head leak in strp_abort_strp()
When the stream parser is aborted, for example after a message assembly timeout, it can still hold a reference to a partially assembled message in strp->skb_head.
That skb is not released in strp_abort_strp(), which leaks the partially assembled message and can be triggered repeatedly to exhaust memory.
Fix this by freeing strp->skb_head and resetting the parser state in the abort path. Leave strp_stop() unchanged so final cleanup still happens in strp_done() after the work and timer have been synchronized.(CVE-2026-46102)
In the Linux kernel, the following vulnerability has been resolved:
dm-thin: fix metadata refcount underflow
There's a bug in dm-thin in the function rebalance_children. If the internal btree node has one entry, the code tries to copy all btree entries from the node's child to the node itself and then decrement the child's reference count.
If the child node is shared (it has reference count > 1), we won't free it, so there would be two pointers to each of the grandchildren nodes. But the reference counts of the grandchildren is not increased, thus the reference count doesn't match the number of pointers that point to the grandchildren. This results in "device mapper: space map common: unable to decrement block" errors.
Fix this bug by incrementing reference counts on the grandchildren if the btree node is shared.(CVE-2026-46107)
In the Linux kernel, the following vulnerability has been resolved:
xfrm: defensively unhash xfrm_state lists in __xfrm_state_delete
KASAN reproduces a slab-use-after-free in __xfrm_state_delete()'s hlist_del_rcu calls under syzkaller load on linux-6.12.y stable (reproduced on 6.12.47, also reachable via the same code path on torvalds/master and on the ipsec tree). Nine unique signatures cluster in the xfrm_state lifecycle, the load-bearing one being:
BUG: KASAN: slab-use-after-free in __hlist_del include/linux/list.h:990 [inline] BUG: KASAN: slab-use-after-free in hlist_del_rcu include/linux/rculist.h:516 [inline] BUG: KASAN: slab-use-after-free in __xfrm_state_delete net/xfrm/xfrm_state.c Write of size 8 at addr ffff8881198bcb70 by task kworker/u8:9/435
Workqueue: netns cleanup_net Call Trace: __hlist_del / hlist_del_rcu __xfrm_state_delete xfrm_state_delete xfrm_state_flush xfrm_state_fini ops_exit_list cleanup_net
The other observed signatures hit the same slab object from __xfrm_state_lookup, xfrm_alloc_spi, __xfrm_state_insert and an OOB write variant of __xfrm_state_delete, all on the byseq/byspi hash chains.
__xfrm_state_delete() guards its byseq and byspi unhashes with value-based predicates:
if (x->km.seq)
hlist_del_rcu(&x->byseq);
if (x->id.spi)
hlist_del_rcu(&x->byspi);
while everywhere else in the file (e.g. state_cache, state_cache_input) the safer hlist_unhashed() check is used. xfrm_alloc_spi() sets x->id.spi = newspi inside xfrm_state_lock and then immediately inserts into byspi, but a path that observes x->id.spi != 0 outside of xfrm_state_lock can still skip-or-hit the byspi unhash inconsistently with whether x is actually on the list. The same holds for x->km.seq versus byseq, and the bydst/bysrc unhashes have no predicate at all, so a second __xfrm_state_delete() on the same object writes through LIST_POISON pprev.
The defensive change here:
- Use hlist_del_init_rcu() instead of hlist_del_rcu() on bydst, bysrc, byseq and byspi so a second deletion is a no-op rather than a write through LIST_POISON pprev. The byseq/byspi nodes are already initialised in xfrm_state_alloc().
- Test hlist_unhashed() rather than the value predicate for byseq/byspi, so the unhash decision tracks list state rather than mutable scalar fields.
Empirical verification: applied this patch on top of v6.12.47, rebuilt, and re-ran the same syzkaller harness for 1h16m on a previously-crashy configuration that produced ~100 hits each of slab-use-after-free Read in xfrm_alloc_spi / Read in __xfrm_state_lookup / Write in __xfrm_state_delete. After the patch, 7.1M execs across 32 VMs at ~1550 exec/sec produced zero xfrm_state UAF/OOB hits. /proc/slabinfo confirms the xfrm_state slab is actively allocated and freed during the run (~143 KiB resident), so the fuzzer is still exercising those code paths -- they just no longer crash.
Reproduction:
- Linux 6.12.47 x86_64 + KASAN_GENERIC + KASAN_INLINE + KCOV
- syzkaller @ 746545b8b1e4c3a128db8652b340d3df90ce61db
- 32 QEMU/KVM VMs x 2 vCPU on AWS c5.metal bare metal
- 9 unique signatures collected in ~9h, all within xfrm_state lifecycle(CVE-2026-46116)
In the Linux kernel, the following vulnerability has been resolved:
net: rtnetlink: zero ifla_vf_broadcast to avoid stack infoleak in rtnl_fill_vfinfo
rtnl_fill_vfinfo() declares struct ifla_vf_broadcast on the stack without initialisation:
struct ifla_vf_broadcast vf_broadcast;
The struct contains a single fixed 32-byte field:
/* include/uapi/linux/if_link.h */
struct ifla_vf_broadcast {
__u8 broadcast[32];
};
The function then copies dev->broadcast into it using dev->addr_len as the length:
memcpy(vf_broadcast.broadcast, dev->broadcast, dev->addr_len);
On Ethernet devices (the overwhelming majority of SR-IOV NICs) dev->addr_len is 6, so only the first 6 bytes of broadcast[] are written. The remaining 26 bytes retain whatever was previously on the kernel stack. The full struct is then handed to userspace via:
nla_put(skb, IFLA_VF_BROADCAST,
sizeof(vf_broadcast), &vf_broadcast)
leaking up to 26 bytes of uninitialised kernel stack per VF per RTM_GETLINK request, repeatable.
The other vf_* structs in the same function are explicitly zeroed for exactly this reason - see the memset() calls for ivi, vf_vlan_info, node_guid and port_guid a few lines above. vf_broadcast was simply missed when it was added.
Reachability: any unprivileged local process can open AF_NETLINK / NETLINK_ROUTE without capabilities and send RTM_GETLINK with an IFLA_EXT_MASK attribute carrying RTEXT_FILTER_VF. The kernel walks each VF and emits IFLA_VF_BROADCAST, leaking 26 bytes of stack per VF per request. Stack residue at this call site can include return addresses and transient sensitive data; KASAN with stack instrumentation, or KMSAN, will flag the nla_put() when reproduced.
Zero the on-stack struct before the partial memcpy, matching the existing pattern used for the other vf_* structs in the same function.(CVE-2026-46132)
In the Linux kernel, xfrm6_rcv_encap() performs an IPv6 route lookup when the skb does not already have a dst attached. ip6_route_input_lookup() returns a referenced dst entry even when the lookup resolves to an error route. If dst->error is set, xfrm6_rcv_encap() drops the skb without attaching the dst to the skb and without releasing the reference returned by the lookup. Repeated packets hitting this path therefore leak dst entries.(CVE-2026-46172)
In the Linux kernel, the mlx4_ib_create_srq() function fails to release resources allocated by mlx4_srq_alloc() in error handling paths, leading to a resource leak. An attacker could exploit this vulnerability to cause resource exhaustion or denial of service.(CVE-2026-46178)
In the Linux kernel, the ua101 driver has a division by zero vulnerability at probe. The detect_usb_format() function lacks a sanity check for the bNrChannels field. When a malicious USB audio device provides bNrChannels=0, frame_bytes becomes zero and is later used as a divisor in playback_urb_complete() and capture_urb_complete(), causing a kernel crash. USB core does not validate class-specific descriptor fields, so drivers must verify them before use.(CVE-2026-46184)
In the Linux kernel, drm_gem_fb_init_with_funcs() computes sub-sampled plane dimensions using plain integer division, while the ioctl-level framebuffer_check() uses DIV_ROUND_UP via drm_format_info_plane_width/height(). This inconsistency causes incorrect GEM object size validation for certain pixel formats and dimensions, e.g., NV12 with height=1 results in height=0, leading to an integer overflow in size check and allowing undersized GEM objects to pass, potentially causing out-of-bounds memory access by the GPU.(CVE-2026-46209)
In the Linux kernel, the following vulnerability has been resolved: MIPS: Work around LLVM bug when gp is used as global register variable On MIPS, current_thread_info is defined as global register variable locating in $gp, and is simply assigned with new address during kernel relocation. This however is broken with LLVM, which always restores $gp if it finds $gp is clobbered in any form, including when intentionally through a global register variable. This is against GCC's documentation[1], which requires a callee-saved register used as global register variable not to be restored if it's clobbered. As a result, $gp will continue to point to the unrelocated kernel after the epilog of relocate_kernel(), leading to an early crash in init_idle, [ 0.000000] CPU 0 Unable to handle kernel paging request at virtual address 0000000000000000, epc == ffffffff81afada8, ra == ffffffff81afad90 [ 0.000000] Oops[#1]: [ 0.000000] CPU: 0 UID: 0 PID: 0 Comm: swapper Tainted: G W 6.19.0-rc5-00262-gd3eeb99bbc99-dirty #188 VOLUNTARY [ 0.000000] Tainted: [W]=WARN [ 0.000000] Hardware name: loongson,loongson64v-4core-virtio [ 0.000000] $ 0 : 0000000000000000 0000000000000000 0000000000000001 0000000000000000 [ 0.000000] $ 4 : ffffffff80b80ec0 ffffffff80b53d48 0000000000000000 00000000000f4240 [ 0.000000] $ 8 : 0000000000000100 ffffffff81d82f80 ffffffff81d82f80 0000000000000001 [ 0.000000] $12 : 0000000000000000 ffffffff81776f58 00000000000005da 0000000000000002 [ 0.000000] $16 : ffffffff80b80e40 0000000000000000 ffffffff80b81614 9800000005dfbe80 [ 0.000000] $20 : 00000000540000e0 ffffffff81980000 0000000000000000 ffffffff80f81c80 [ 0.000000] $24 : 0000000000000a26 ffffffff8114fb90 [ 0.000000] $28 : ffffffff80b50000 ffffffff80b53d40 0000000000000000 ffffffff81afad90 [ 0.000000] Hi : 0000000000000000 [ 0.000000] Lo : 0000000000000000 [ 0.000000] epc : ffffffff81afada8 init_idle+0x130/0x270 [ 0.000000] ra : ffffffff81afad90 init_idle+0x118/0x270 [ 0.000000] Status: 540000e2 KX SX UX KERNEL EXL [ 0.000000] Cause : 00000008 (ExcCode 02) [ 0.000000] BadVA : 0000000000000000 [ 0.000000] PrId : 00006305 (ICT Loongson-3) [ 0.000000] Process swapper (pid: 0, threadinfo=(_ptrval), task=(____ptrval_), tls=0000000000000000) [ 0.000000] Stack : 9800000005dfbf00 ffffffff8178e950 0000000000000000 0000000000000000 [ 0.000000] 0000000000000000 ffffffff81970000 000000000000003f ffffffff810a6528 [ 0.000000] 0000000000000001 9800000005dfbe80 9800000005dfbf00 ffffffff81980000 [ 0.000000] ffffffff810a6450 ffffffff81afb6c0 0000000000000000 ffffffff810a2258 [ 0.000000] ffffffff81d82ec8 ffffffff8198d010 ffffffff81b67e80 ffffffff8197dd98 [ 0.000000] ffffffff81d81c80 ffffffff81930000 0000000000000040 0000000000000000 [ 0.000000] 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 0.000000] 0000000000000000 000000000000009e ffffffff9fc01000 0000000000000000 [ 0.000000] 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 0.000000] 0000000000000000 ffffffff81ae86dc ffffffff81b3c741 0000000000000002 [ 0.000000] ... [ 0.000000] Call Trace: [ 0.000000] [<ffffffff81afada8>] init_idle+0x130/0x270 [ 0.000000] [<ffffffff81afb6c0>] sched_init+0x5c8/0x6c0 [ 0.000000] [<ffffffff81ae86dc>] start_kernel+0x27c/0x7a8 This bug has been reported to LLVM[2] and affects version from (at least) 18 to 21. Let's work around this by using inline assembly to assign $gp before a fix is widely available. The Linux kernel CVE team has assigned CVE-2026-46250 to this issue.(CVE-2026-46250)
In the Linux kernel, the following vulnerability has been resolved: pstore/ram: fix buffer overflow in persistent_ram_save_old() persistent_ram_save_old() can be called multiple times for the same persistent_ram_zone (e.g., via ramoops_pstore_read -> ramoops_get_next_prz for PSTORE_TYPE_DMESG records). Currently, the function only allocates prz->old_log when it is NULL, but it unconditionally updates prz->old_log_size to the current buffer size and then performs memcpy_fromio() using this new size. If the buffer size has grown since the first allocation (which can happen across different kernel boot cycles), this leads to: 1. A heap buffer overflow (OOB write) in the memcpy_fromio() calls 2. A subsequent OOB read when ramoops_pstore_read() accesses the buffer using the incorrect (larger) old_log_size The KASAN splat would look similar to: BUG: KASAN: slab-out-of-bounds in ramoops_pstore_read+0x... Read of size N at addr ... by task ... The conditions are likely extremely hard to hit: 0. Crash with a ramoops write of less-than-record-max-size bytes. 1. Reboot: ramoops registers, pstore_get_records(0) reads old crash, allocates old_log with size X 2. Crash handler registered, timer started (if pstore_update_ms >= 0) 3. Oops happens (non-fatal, system continues) 4. pstore_dump() writes oops via ramoops_pstore_write() size Y (>X) 5. pstore_new_entry = 1, pstore_timer_kick() called 6. System continues running (not a panic oops) 7. Timer fires after pstore_update_ms milliseconds 8. pstore_timefunc() → schedule_work() → pstore_dowork() → pstore_get_records(1) 9. ramoops_get_next_prz() → persistent_ram_save_old() 10. buffer_size() returns Y, but old_log is X bytes 11. Y > X: memcpy_fromio() overflows heap Requirements: - a prior crash record exists that did not fill the record size (almost impossible since the crash handler writes as much as it can possibly fit into the record, capped by max record size and the kmsg buffer almost always exceeds the max record size) - pstore_update_ms >= 0 (disabled by default) - Non-fatal oops (system survives) Free and reallocate the buffer when the new size differs from the previously allocated size. This ensures old_log always has sufficient space for the data being copied. The Linux kernel CVE team has assigned CVE-2026-46253 to this issue.(CVE-2026-46253)
In the Linux kernel, the following vulnerability has been resolved: procfs: fix missing RCU protection when reading real_parent in do_task_stat() When reading /proc/[pid]/stat, do_task_stat() accesses task->real_parent without proper RCU protection, which leads to: cpu 0 cpu 1 ----- ----- do_task_stat var = task->real_parent release_task call_rcu(delayed_put_task_struct) task_tgid_nr_ns(var) rcu_read_lock <--- Too late to protect task->real_parent! task_pid_ptr <--- UAF! rcu_read_unlock This patch uses task_ppid_nr_ns() instead of task_tgid_nr_ns() to add proper RCU protection for accessing task->real_parent. The Linux kernel CVE team has assigned CVE-2026-46259 to this issue.(CVE-2026-46259)
In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix WQ_MEM_RECLAIM warning When sunrpc is used, if a reset triggered, our wq may lead the following trace: workqueue: WQ_MEM_RECLAIM xprtiod:xprt_rdma_connect_worker [rpcrdma] is flushing !WQ_MEM_RECLAIM hns_roce_irq_workq:flush_work_handle [hns_roce_hw_v2] WARNING: CPU: 0 PID: 8250 at kernel/workqueue.c:2644 check_flush_dependency+0xe0/0x144 Call trace: check_flush_dependency+0xe0/0x144 start_flush_work.constprop.0+0x1d0/0x2f0 __flush_work.isra.0+0x40/0xb0 flush_work+0x14/0x30 hns_roce_v2_destroy_qp+0xac/0x1e0 [hns_roce_hw_v2] ib_destroy_qp_user+0x9c/0x2b4 rdma_destroy_qp+0x34/0xb0 rpcrdma_ep_destroy+0x28/0xcc [rpcrdma] rpcrdma_ep_put+0x74/0xb4 [rpcrdma] rpcrdma_xprt_disconnect+0x1d8/0x260 [rpcrdma] xprt_rdma_connect_worker+0xc0/0x120 [rpcrdma] process_one_work+0x1cc/0x4d0 worker_thread+0x154/0x414 kthread+0x104/0x144 ret_from_fork+0x10/0x18 Since QP destruction frees memory, this wq should have the WQ_MEM_RECLAIM. The Linux kernel CVE team has assigned CVE-2026-46265 to this issue.(CVE-2026-46265)
| URL | Type | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-5.10.0-318.0.0.221.oe2203sp4.aarch64.rpm",
"bpftool-debuginfo-5.10.0-318.0.0.221.oe2203sp4.aarch64.rpm",
"kernel-5.10.0-318.0.0.221.oe2203sp4.aarch64.rpm",
"kernel-debuginfo-5.10.0-318.0.0.221.oe2203sp4.aarch64.rpm",
"kernel-debugsource-5.10.0-318.0.0.221.oe2203sp4.aarch64.rpm",
"kernel-devel-5.10.0-318.0.0.221.oe2203sp4.aarch64.rpm",
"kernel-headers-5.10.0-318.0.0.221.oe2203sp4.aarch64.rpm",
"kernel-source-5.10.0-318.0.0.221.oe2203sp4.aarch64.rpm",
"kernel-tools-5.10.0-318.0.0.221.oe2203sp4.aarch64.rpm",
"kernel-tools-debuginfo-5.10.0-318.0.0.221.oe2203sp4.aarch64.rpm",
"kernel-tools-devel-5.10.0-318.0.0.221.oe2203sp4.aarch64.rpm",
"perf-5.10.0-318.0.0.221.oe2203sp4.aarch64.rpm",
"perf-debuginfo-5.10.0-318.0.0.221.oe2203sp4.aarch64.rpm",
"python3-perf-5.10.0-318.0.0.221.oe2203sp4.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-318.0.0.221.oe2203sp4.aarch64.rpm"
],
"src": [
"kernel-5.10.0-318.0.0.221.oe2203sp4.src.rpm"
],
"x86_64": [
"bpftool-5.10.0-318.0.0.221.oe2203sp4.x86_64.rpm",
"bpftool-debuginfo-5.10.0-318.0.0.221.oe2203sp4.x86_64.rpm",
"kernel-5.10.0-318.0.0.221.oe2203sp4.x86_64.rpm",
"kernel-debuginfo-5.10.0-318.0.0.221.oe2203sp4.x86_64.rpm",
"kernel-debugsource-5.10.0-318.0.0.221.oe2203sp4.x86_64.rpm",
"kernel-devel-5.10.0-318.0.0.221.oe2203sp4.x86_64.rpm",
"kernel-headers-5.10.0-318.0.0.221.oe2203sp4.x86_64.rpm",
"kernel-source-5.10.0-318.0.0.221.oe2203sp4.x86_64.rpm",
"kernel-tools-5.10.0-318.0.0.221.oe2203sp4.x86_64.rpm",
"kernel-tools-debuginfo-5.10.0-318.0.0.221.oe2203sp4.x86_64.rpm",
"kernel-tools-devel-5.10.0-318.0.0.221.oe2203sp4.x86_64.rpm",
"perf-5.10.0-318.0.0.221.oe2203sp4.x86_64.rpm",
"perf-debuginfo-5.10.0-318.0.0.221.oe2203sp4.x86_64.rpm",
"python3-perf-5.10.0-318.0.0.221.oe2203sp4.x86_64.rpm",
"python3-perf-debuginfo-5.10.0-318.0.0.221.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-318.0.0.221.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:\n\nbtrfs: qgroup: fix race between quota disable and quota rescan ioctl\n\nThere\u0026apos;s a race between a task disabling quotas and another running the\nrescan ioctl that can result in a use-after-free of qgroup records from\nthe fs_info-\u0026gt;qgroup_tree rbtree.\n\nThis happens as follows:\n\n1) Task A enters btrfs_ioctl_quota_rescan() -\u0026gt; btrfs_qgroup_rescan();\n\n2) Task B enters btrfs_quota_disable() and calls\n btrfs_qgroup_wait_for_completion(), which does nothing because at that\n point fs_info-\u0026gt;qgroup_rescan_running is false (it wasn\u0026apos;t set yet by\n task A);\n\n3) Task B calls btrfs_free_qgroup_config() which starts freeing qgroups\n from fs_info-\u0026gt;qgroup_tree without taking the lock fs_info-\u0026gt;qgroup_lock;\n\n4) Task A enters qgroup_rescan_zero_tracking() which starts iterating\n the fs_info-\u0026gt;qgroup_tree tree while holding fs_info-\u0026gt;qgroup_lock,\n but task B is freeing qgroup records from that tree without holding\n the lock, resulting in a use-after-free.\n\nFix this by taking fs_info-\u0026gt;qgroup_lock at btrfs_free_qgroup_config().\nAlso at btrfs_qgroup_rescan() don\u0026apos;t start the rescan worker if quotas\nwere already disabled.(CVE-2025-39759)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: wilc1000: avoid buffer overflow in WID string configuration\n\nFix the following copy overflow warning identified by Smatch checker.\n\n drivers/net/wireless/microchip/wilc1000/wlan_cfg.c:184 wilc_wlan_parse_response_frame()\n error: \u0026apos;__memcpy()\u0026apos; \u0026apos;cfg-\u0026gt;s[i]-\u0026gt;str\u0026apos; copy overflow (512 vs 65537)\n\nThis patch introduces size check before accessing the memory buffer.\nThe checks are base on the WID type of received data from the firmware.\nFor WID string configuration, the size limit is determined by individual\nelement size in \u0026apos;struct wilc_cfg_str_vals\u0026apos; that is maintained in \u0026apos;len\u0026apos; field\nof \u0026apos;struct wilc_cfg_str\u0026apos;.(CVE-2025-39952)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niio: accel: bmc150: Fix irq assumption regression\n\nThe code in bmc150-accel-core.c unconditionally calls\nbmc150_accel_set_interrupt() in the iio_buffer_setup_ops,\nsuch as on the runtime PM resume path giving a kernel\nsplat like this if the device has no interrupts:\n\nUnable to handle kernel NULL pointer dereference at virtual\n address 00000001 when read\n\nPC is at bmc150_accel_set_interrupt+0x98/0x194\nLR is at __pm_runtime_resume+0x5c/0x64\n(...)\nCall trace:\nbmc150_accel_set_interrupt from bmc150_accel_buffer_postenable+0x40/0x108\nbmc150_accel_buffer_postenable from __iio_update_buffers+0xbe0/0xcbc\n__iio_update_buffers from enable_store+0x84/0xc8\nenable_store from kernfs_fop_write_iter+0x154/0x1b4\n\nThis bug seems to have been in the driver since the beginning,\nbut it only manifests recently, I do not know why.\n\nStore the IRQ number in the state struct, as this is a common\npattern in other drivers, then use this to determine if we have\nIRQ support or not.(CVE-2025-68330)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nstaging: most: remove broken i2c driver\n\nThe MOST I2C driver has been completely broken for five years without\nanyone noticing so remove the driver from staging.\n\nSpecifically, commit 723de0f9171e (\u0026quot;staging: most: remove device from\ninterface structure\u0026quot;) started requiring drivers to set the interface\ndevice pointer before registration, but the I2C driver was never updated\nwhich results in a NULL pointer dereference if anyone ever tries to\nprobe it.(CVE-2025-68755)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix NULL dereference on root when tracing inode eviction\n\nWhen evicting an inode the first thing we do is to setup tracing for it,\nwhich implies fetching the root\u0026apos;s id. But in btrfs_evict_inode() the\nroot might be NULL, as implied in the next check that we do in\nbtrfs_evict_inode().\n\nHence, we either should set the -\u0026gt;root_objectid to 0 in case the root is\nNULL, or we move tracing setup after checking that the root is not\nNULL. Setting the rootid to 0 at least gives us the possibility to trace\nthis call even in the case when the root is NULL, so that\u0026apos;s the solution\ntaken here.(CVE-2025-71184)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfbdev: udlfb: avoid divide-by-zero on FBIOPUT_VSCREENINFO\n\nMuch like commit 19f953e74356 (\u0026quot;fbdev: fb_pm2fb: Avoid potential divide\nby zero error\u0026quot;), we also need to prevent that same crash from happening\nin the udlfb driver as it uses pixclock directly when dividing, which\nwill crash.(CVE-2026-31605)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusbip: validate number_of_packets in usbip_pack_ret_submit()\n\nWhen a USB/IP client receives a RET_SUBMIT response,\nusbip_pack_ret_submit() unconditionally overwrites\nurb-\u0026gt;number_of_packets from the network PDU. This value is\nsubsequently used as the loop bound in usbip_recv_iso() and\nusbip_pad_iso() to iterate over urb-\u0026gt;iso_frame_desc[], a flexible\narray whose size was fixed at URB allocation time based on the\n*original* number_of_packets from the CMD_SUBMIT.\n\nA malicious USB/IP server can set number_of_packets in the response\nto a value larger than what was originally submitted, causing a heap\nout-of-bounds write when usbip_recv_iso() writes to\nurb-\u0026gt;iso_frame_desc[i] beyond the allocated region.\n\nKASAN confirmed this with kernel 7.0.0-rc5:\n\n BUG: KASAN: slab-out-of-bounds in usbip_recv_iso+0x46a/0x640\n Write of size 4 at addr ffff888106351d40 by task vhci_rx/69\n\n The buggy address is located 0 bytes to the right of\n allocated 320-byte region [ffff888106351c00, ffff888106351d40)\n\nThe server side (stub_rx.c) and gadget side (vudc_rx.c) already\nvalidate number_of_packets in the CMD_SUBMIT path since commits\nc6688ef9f297 (\u0026quot;usbip: fix stub_rx: harden CMD_SUBMIT path to handle\nmalicious input\u0026quot;) and b78d830f0049 (\u0026quot;usbip: fix vudc_rx: harden\nCMD_SUBMIT path to handle malicious input\u0026quot;). The server side validates\nagainst USBIP_MAX_ISO_PACKETS because no URB exists yet at that point.\nOn the client side we have the original URB, so we can use the tighter\nbound: the response must not exceed the original number_of_packets.\n\nThis mirrors the existing validation of actual_length against\ntransfer_buffer_length in usbip_recv_xbuff(), which checks the\nresponse value against the original allocation size.\n\nKelvin Mbogo\u0026apos;s series (\u0026quot;usb: usbip: fix integer overflow in\nusbip_recv_iso()\u0026quot;, v2) hardens the receive-side functions themselves;\nthis patch complements that work by catching the bad value at its\nsource -- in usbip_pack_ret_submit() before the overwrite -- and\nusing the tighter per-URB allocation bound rather than the global\nUSBIP_MAX_ISO_PACKETS limit.\n\nFix this by checking rpdu-\u0026gt;number_of_packets against\nurb-\u0026gt;number_of_packets in usbip_pack_ret_submit() before the\noverwrite. On violation, clamp to zero so that usbip_recv_iso() and\nusbip_pad_iso() safely return early.(CVE-2026-31607)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: gadget: renesas_usb3: validate endpoint index in standard request handlers\n\nThe GET_STATUS and SET/CLEAR_FEATURE handlers extract the endpoint\nnumber from the host-supplied wIndex without any sort of validation.\nFix this up by validating the number of endpoints actually match up with\nthe number the device has before attempting to dereference a pointer\nbased on this math.\n\nThis is just like what was done in commit ee0d382feb44 (\u0026quot;usb: gadget:\naspeed_udc: validate endpoint index for ast udc\u0026quot;) for the aspeed driver.(CVE-2026-31615)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: gadget: f_phonet: fix skb frags[] overflow in pn_rx_complete()\n\nA broken/bored/mean USB host can overflow the skb_shared_info-\u0026gt;frags[]\narray on a Linux gadget exposing a Phonet function by sending an\nunbounded sequence of full-page OUT transfers.\n\npn_rx_complete() finalizes the skb only when req-\u0026gt;actual \u0026lt; req-\u0026gt;length,\nwhere req-\u0026gt;length is set to PAGE_SIZE by the gadget. If the host always\nsends exactly PAGE_SIZE bytes per transfer, fp-\u0026gt;rx.skb will never be\nreset and each completion will add another fragment via\nskb_add_rx_frag(). Once nr_frags exceeds MAX_SKB_FRAGS (default 17),\nsubsequent frag stores overwrite memory adjacent to the shinfo on the\nheap.\n\nDrop the skb and account a length error when the frag limit is reached,\nmatching the fix applied in t7xx by commit f0813bcd2d9d (\u0026quot;net: wwan:\nt7xx: fix potential skb-\u0026gt;frags overflow in RX path\u0026quot;).(CVE-2026-31616)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: gadget: f_ncm: validate minimum block_len in ncm_unwrap_ntb()\n\nThe block_len read from the host-supplied NTB header is checked against\nntb_max but has no lower bound. When block_len is smaller than\nopts-\u0026gt;ndp_size, the bounds check of:\n\tndp_index \u0026gt; (block_len - opts-\u0026gt;ndp_size)\nwill underflow producing a huge unsigned value that ndp_index can never\nexceed, defeating the check entirely.\n\nThe same underflow occurs in the datagram index checks against block_len\n- opts-\u0026gt;dpe_size. With those checks neutered, a malicious USB host can\nchoose ndp_index and datagram offsets that point past the actual\ntransfer, and the skb_put_data() copies adjacent kernel memory into the\nnetwork skb.\n\nFix this by rejecting block lengths that cannot hold at least the NTB\nheader plus one NDP. This will make block_len - opts-\u0026gt;ndp_size and\nblock_len - opts-\u0026gt;dpe_size both well-defined.\n\nCommit 8d2b1a1ec9f5 (\u0026quot;CDC-NCM: avoid overflow in sanity checking\u0026quot;) fixed\na related class of issues on the host side of NCM.(CVE-2026-31617)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfbdev: tdfxfb: avoid divide-by-zero on FBIOPUT_VSCREENINFO\n\nMuch like commit 19f953e74356 (\u0026quot;fbdev: fb_pm2fb: Avoid potential divide\nby zero error\u0026quot;), we also need to prevent that same crash from happening\nin the udlfb driver as it uses pixclock directly when dividing, which\nwill crash.(CVE-2026-31618)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/packet: fix TOCTOU race on mmap\u0026apos;d vnet_hdr in tpacket_snd()\n\nIn tpacket_snd(), when PACKET_VNET_HDR is enabled, vnet_hdr points\ndirectly into the mmap\u0026apos;d TX ring buffer shared with userspace. The\nkernel validates the header via __packet_snd_vnet_parse() but then\nre-reads all fields later in virtio_net_hdr_to_skb(). A concurrent\nuserspace thread can modify the vnet_hdr fields between validation\nand use, bypassing all safety checks.\n\nThe non-TPACKET path (packet_snd()) already correctly copies vnet_hdr\nto a stack-local variable. All other vnet_hdr consumers in the kernel\n(tun.c, tap.c, virtio_net.c) also use stack copies. The TPACKET TX\npath is the only caller of virtio_net_hdr_to_skb() that reads directly\nfrom user-controlled shared memory.\n\nFix this by copying vnet_hdr from the mmap\u0026apos;d ring buffer to a\nstack-local variable before validation and use, consistent with the\napproach used in packet_snd() and all other callers.(CVE-2026-31700)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBuffer overflow in drivers/xen/sys-hypervisor.c\n\nThe build id returned by HYPERVISOR_xen_version(XENVER_build_id) is\nneither NUL terminated nor a string.\n\nThe first causes a buffer overflow as sprintf in buildid_show will\nread and copy till it finds a NUL.\n\n00000000 f4 91 51 f4 dd 38 9e 9d 65 47 52 eb 10 71 db 50 |..Q..8..eGR..q.P|\n00000010 b9 a8 01 42 6f 2e 32 |...Bo.2|\n00000017\n\nSo use a memcpy instead of sprintf to have the correct value:\n\n00000000 f4 91 51 f4 dd 00 9e 9d 65 47 52 eb 10 71 db 50 |..Q.....eGR..q.P|\n00000010 b9 a8 01 42 |...B|\n00000014\n\n(the above have a hack to embed a zero inside and check it\u0026apos;s\nreturned correctly).\n\nThis is XSA-485 / CVE-2026-31786(CVE-2026-31786)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: algif_aead - Fix minimum RX size check for decryption\n\nThe check for the minimum receive buffer size did not take the\ntag size into account during decryption. Fix this by adding the\nrequired extra length.(CVE-2026-43077)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: af_alg - Fix page reassignment overflow in af_alg_pull_tsgl\n\nWhen page reassignment was added to af_alg_pull_tsgl the original\nloop wasn\u0026apos;t updated so it may try to reassign one more page than\nnecessary.\n\nAdd the check to the reassignment so that this does not happen.\n\nAlso update the comment which still refers to the obsolete offset\nargument.(CVE-2026-43078)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: Wait for RCU readers during policy netns exit\n\nxfrm_policy_fini() frees the policy_bydst hash tables after flushing the\npolicy work items and deleting all policies, but it does not wait for\nconcurrent RCU readers to leave their read-side critical sections first.\n\nThe policy_bydst tables are published via rcu_assign_pointer() and are\nlooked up through rcu_dereference_check(), so netns teardown must also\nwait for an RCU grace period before freeing the table memory.\n\nFix this by adding synchronize_rcu() before freeing the policy hash tables.(CVE-2026-43091)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxsk: tighten UMEM headroom validation to account for tailroom and min frame\n\nThe current headroom validation in xdp_umem_reg() could leave us with\ninsufficient space dedicated to even receive minimum-sized ethernet\nframe. Furthermore if multi-buffer would come to play then\nskb_shared_info stored at the end of XSK frame would be corrupted.\n\nHW typically works with 128-aligned sizes so let us provide this value\nas bare minimum.\n\nMulti-buffer setting is known later in the configuration process so\nbesides accounting for 128 bytes, let us also take care of tailroom space\nupfront.(CVE-2026-43093)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: ctnetlink: ensure safe access to master conntrack\n\nHolding reference on the expectation is not sufficient, the master\nconntrack object can just go away, making exp-\u0026gt;master invalid.\n\nTo access exp-\u0026gt;master safely:\n\n- Grab the nf_conntrack_expect_lock, this gets serialized with\n clean_from_lists() which also holds this lock when the master\n conntrack goes away.\n\n- Hold reference on master conntrack via nf_conntrack_find_get().\n Not so easy since the master tuple to look up for the master conntrack\n is not available in the existing problematic paths.\n\nThis patch goes for extending the nf_conntrack_expect_lock section\nto address this issue for simplicity, in the cases that are described\nbelow this is just slightly extending the lock section.\n\nThe add expectation command already holds a reference to the master\nconntrack from ctnetlink_create_expect().\n\nHowever, the delete expectation command needs to grab the spinlock\nbefore looking up for the expectation. Expand the existing spinlock\nsection to address this to cover the expectation lookup. Note that,\nthe nf_ct_expect_iterate_net() calls already grabs the spinlock while\niterating over the expectation table, which is correct.\n\nThe get expectation command needs to grab the spinlock to ensure master\nconntrack does not go away. This also expands the existing spinlock\nsection to cover the expectation lookup too. I needed to move the\nnetlink skb allocation out of the spinlock to keep it GFP_KERNEL.\n\nFor the expectation events, the IPEXP_DESTROY event is already delivered\nunder the spinlock, just move the delivery of IPEXP_NEW under the\nspinlock too because the master conntrack event cache is reached through\nexp-\u0026gt;master.\n\nWhile at it, add lockdep notations to help identify what codepaths need\nto grab the spinlock.(CVE-2026-43116)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndlm: validate length in dlm_search_rsb_tree\n\nThe len parameter in dlm_dump_rsb_name() is not validated and comes\nfrom network messages. When it exceeds DLM_RESNAME_MAXLEN, it can\ncause out-of-bounds write in dlm_search_rsb_tree().\n\nAdd length validation to prevent potential buffer overflow.(CVE-2026-43125)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niommu/vt-d: Flush dev-IOTLB only when PCIe device is accessible in scalable mode\n\nCommit 4fc82cd907ac (\u0026quot;iommu/vt-d: Don\u0026apos;t issue ATS Invalidation\nrequest when device is disconnected\u0026quot;) relies on\npci_dev_is_disconnected() to skip ATS invalidation for\nsafely-removed devices, but it does not cover link-down caused\nby faults, which can still hard-lock the system.\n\nFor example, if a VM fails to connect to the PCIe device,\n\u0026quot;virsh destroy\u0026quot; is executed to release resources and isolate\nthe fault, but a hard-lockup occurs while releasing the group fd.\n\nCall Trace:\n qi_submit_sync\n qi_flush_dev_iotlb\n intel_pasid_tear_down_entry\n device_block_translation\n blocking_domain_attach_dev\n __iommu_attach_device\n __iommu_device_set_domain\n __iommu_group_set_domain_internal\n iommu_detach_group\n vfio_iommu_type1_detach_group\n vfio_group_detach_container\n vfio_group_fops_release\n __fput\n\nAlthough pci_device_is_present() is slower than\npci_dev_is_disconnected(), it still takes only ~70 \u00b5s on a\nConnectX-5 (8 GT/s, x2) and becomes even faster as PCIe speed\nand width increase.\n\nBesides, devtlb_invalidation_with_pasid() is called only in the\npaths below, which are far less frequent than memory map/unmap.\n\n1. mm-struct release\n2. {attach,release}_dev\n3. set/remove PASID\n4. dirty-tracking setup\n\nThe gain in system stability far outweighs the negligible cost\nof using pci_device_is_present() instead of pci_dev_is_disconnected()\nto decide when to skip ATS invalidation, especially under GDR\nhigh-load conditions.(CVE-2026-43130)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfrm6: fix uninitialized saddr in xfrm6_get_saddr()\n\nxfrm6_get_saddr() does not check the return value of\nipv6_dev_get_saddr(). When ipv6_dev_get_saddr() fails to find a suitable\nsource address (returns -EADDRNOTAVAIL), saddr-\u0026gt;in6 is left\nuninitialized, but xfrm6_get_saddr() still returns 0 (success).\n\nThis causes the caller xfrm_tmpl_resolve_one() to use the uninitialized\naddress in xfrm_state_find(), triggering KMSAN warning:\n\n=====================================================\nBUG: KMSAN: uninit-value in xfrm_state_find+0x2424/0xa940\n xfrm_state_find+0x2424/0xa940\n xfrm_resolve_and_create_bundle+0x906/0x5a20\n xfrm_lookup_with_ifid+0xcc0/0x3770\n xfrm_lookup_route+0x63/0x2b0\n ip_route_output_flow+0x1ce/0x270\n udp_sendmsg+0x2ce1/0x3400\n inet_sendmsg+0x1ef/0x2a0\n __sock_sendmsg+0x278/0x3d0\n __sys_sendto+0x593/0x720\n __x64_sys_sendto+0x130/0x200\n x64_sys_call+0x332b/0x3e70\n do_syscall_64+0xd3/0xf80\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nLocal variable tmp.i.i created at:\n xfrm_resolve_and_create_bundle+0x3e3/0x5a20\n xfrm_lookup_with_ifid+0xcc0/0x3770\n=====================================================\n\nFix by checking the return value of ipv6_dev_get_saddr() and propagating\nthe error.(CVE-2026-43139)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: xt_tcpmss: check remaining length before reading optlen\n\nQuoting reporter:\n In net/netfilter/xt_tcpmss.c (lines 53-68), the TCP option parser reads\n op[i+1] directly without validating the remaining option length.\n\n If the last byte of the option field is not EOL/NOP (0/1), the code attempts\n to index op[i+1]. In the case where i + 1 == optlen, this causes an\n out-of-bounds read, accessing memory past the optlen boundary\n (either reading beyond the stack buffer _opt or the\n following payload).(CVE-2026-43190)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntcp: fix potential race in tcp_v6_syn_recv_sock()\n\nCode in tcp_v6_syn_recv_sock() after the call to tcp_v4_syn_recv_sock()\nis done too late.\n\nAfter tcp_v4_syn_recv_sock(), the child socket is already visible\nfrom TCP ehash table and other cpus might use it.\n\nSince newinet-\u0026gt;pinet6 is still pointing to the listener ipv6_pinfo\nbad things can happen as syzbot found.\n\nMove the problematic code in tcp_v6_mapped_child_init()\nand call this new helper from tcp_v4_syn_recv_sock() before\nthe ehash insertion.\n\nThis allows the removal of one tcp_sync_mss(), since\ntcp_v4_syn_recv_sock() will call it with the correct\ncontext.(CVE-2026-43198)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_conntrack_h323: fix OOB read in decode_choice()\n\nIn decode_choice(), the boundary check before get_len() uses the\nvariable `len`, which is still 0 from its initialization at the top of\nthe function:\n\n unsigned int type, ext, len = 0;\n ...\n if (ext || (son-\u0026gt;attr \u0026amp; OPEN)) {\n BYTE_ALIGN(bs);\n if (nf_h323_error_boundary(bs, len, 0)) /* len is 0 here */\n return H323_ERROR_BOUND;\n len = get_len(bs); /* OOB read */\n\nWhen the bitstream is exactly consumed (bs-\u0026gt;cur == bs-\u0026gt;end), the check\nnf_h323_error_boundary(bs, 0, 0) evaluates to (bs-\u0026gt;cur + 0 \u0026gt; bs-\u0026gt;end),\nwhich is false. The subsequent get_len() call then dereferences\n*bs-\u0026gt;cur++, reading 1 byte past the end of the buffer. If that byte\nhas bit 7 set, get_len() reads a second byte as well.\n\nThis can be triggered remotely by sending a crafted Q.931 SETUP message\nwith a User-User Information Element containing exactly 2 bytes of\nPER-encoded data ({0x08, 0x00}) to port 1720 through a firewall with\nthe nf_conntrack_h323 helper active. The decoder fully consumes the\nPER buffer before reaching this code path, resulting in a 1-2 byte\nheap-buffer-overflow read confirmed by AddressSanitizer.\n\nFix this by checking for 2 bytes (the maximum that get_len() may read)\ninstead of the uninitialized `len`. This matches the pattern used at\nevery other get_len() call site in the same file, where the caller\nchecks for 2 bytes of available data before calling get_len().(CVE-2026-43233)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niommu/amd: move wait_on_sem() out of spinlock\n\nWith iommu.strict=1, the existing completion wait path can cause soft\nlockups under stressed environment, as wait_on_sem() busy-waits under the\nspinlock with interrupts disabled.\n\nMove the completion wait in iommu_completion_wait() out of the spinlock.\nwait_on_sem() only polls the hardware-updated cmd_sem and does not require\niommu-\u0026gt;lock, so holding the lock during the busy wait unnecessarily\nincreases contention and extends the time with interrupts disabled.(CVE-2026-43253)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nspi: spidev: fix lock inversion between spi_lock and buf_lock\n\nThe spidev driver previously used two mutexes, spi_lock and buf_lock,\nbut acquired them in different orders depending on the code path:\n\n write()/read(): buf_lock -\u0026gt; spi_lock\n ioctl(): spi_lock -\u0026gt; buf_lock\n\nThis AB-BA locking pattern triggers lockdep warnings and can\ncause real deadlocks:\n\n WARNING: possible circular locking dependency detected\n spidev_ioctl() -\u0026gt; mutex_lock(\u0026amp;spidev-\u0026gt;buf_lock)\n spidev_sync_write() -\u0026gt; mutex_lock(\u0026amp;spidev-\u0026gt;spi_lock)\n *** DEADLOCK ***\n\nThe issue is reproducible with a simple userspace program that\nperforms write() and SPI_IOC_WR_MAX_SPEED_HZ ioctl() calls from\nseparate threads on the same spidev file descriptor.\n\nFix this by simplifying the locking model and removing the lock\ninversion entirely. spidev_sync() no longer performs any locking,\nand all callers serialize access using spi_lock.\n\nbuf_lock is removed since its functionality is fully covered by\nspi_lock, eliminating the possibility of lock ordering issues.\n\nThis removes the lock inversion and prevents deadlocks without\nchanging userspace ABI or behaviour.(CVE-2026-43319)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: prevent possible UaF in addrconf_permanent_addr()\n\nThe mentioned helper try to warn the user about an exceptional\ncondition, but the message is delivered too late, accessing the ipv6\nafter its possible deletion.\n\nReorder the statement to avoid the possible UaF; while at it, place the\nwarning outside the idev-\u0026gt;lock as it needs no protection.(CVE-2026-43339)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/tcp-md5: Fix MAC comparison to be constant-time\n\nTo prevent timing attacks, MACs need to be compared in constant\ntime. Use the appropriate helper function for this.(CVE-2026-43383)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nfnetlink_cthelper: fix OOB read in nfnl_cthelper_dump_table()\n\nnfnl_cthelper_dump_table() has a \u0026apos;goto restart\u0026apos; that jumps to a label\ninside the for loop body. When the \u0026quot;last\u0026quot; helper saved in cb-\u0026gt;args[1]\nis deleted between dump rounds, every entry fails the (cur != last)\ncheck, so cb-\u0026gt;args[1] is never cleared. The for loop finishes with\ncb-\u0026gt;args[0] == nf_ct_helper_hsize, and the \u0026apos;goto restart\u0026apos; jumps back\ninto the loop body bypassing the bounds check, causing an 8-byte\nout-of-bounds read on nf_ct_helper_hash[nf_ct_helper_hsize].\n\nThe \u0026apos;goto restart\u0026apos; block was meant to re-traverse the current bucket\nwhen \u0026quot;last\u0026quot; is no longer found, but it was placed after the for loop\ninstead of inside it. Move the block into the for loop body so that\nthe restart only occurs while cb-\u0026gt;args[0] is still within bounds.\n\n BUG: KASAN: slab-out-of-bounds in nfnl_cthelper_dump_table+0x9f/0x1b0\n Read of size 8 at addr ffff888104ca3000 by task poc_cthelper/131\n Call Trace:\n nfnl_cthelper_dump_table+0x9f/0x1b0\n netlink_dump+0x333/0x880\n netlink_recvmsg+0x3e2/0x4b0\n sock_recvmsg+0xde/0xf0\n __sys_recvfrom+0x150/0x200\n __x64_sys_recvfrom+0x76/0x90\n do_syscall_64+0xc3/0x6e0\n\n Allocated by task 1:\n __kvmalloc_node_noprof+0x21b/0x700\n nf_ct_alloc_hashtable+0x65/0xd0\n nf_conntrack_helper_init+0x21/0x60\n nf_conntrack_init_start+0x18d/0x300\n nf_conntrack_standalone_init+0x12/0xc0(CVE-2026-43450)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: x_tables: guard option walkers against 1-byte tail reads\n\nWhen the last byte of options is a non-single-byte option kind, walkers\nthat advance with i += op[i + 1] ? : 1 can read op[i + 1] past the end\nof the option area.\n\nAdd an explicit i == optlen - 1 check before dereferencing op[i + 1]\nin xt_tcpudp and xt_dccp option walkers.(CVE-2026-43452)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nft_set_pipapo: fix stack out-of-bounds read in pipapo_drop()\n\npipapo_drop() passes rulemap[i + 1].n to pipapo_unmap() as the\nto_offset argument on every iteration, including the last one where\ni == m-\u0026gt;field_count - 1. This reads one element past the end of the\nstack-allocated rulemap array (declared as rulemap[NFT_PIPAPO_MAX_FIELDS]\nwith NFT_PIPAPO_MAX_FIELDS == 16).\n\nAlthough pipapo_unmap() returns early when is_last is true without\nusing the to_offset value, the argument is evaluated at the call site\nbefore the function body executes, making this a genuine out-of-bounds\nstack read confirmed by KASAN:\n\n BUG: KASAN: stack-out-of-bounds in pipapo_drop+0x50c/0x57c [nf_tables]\n Read of size 4 at addr ffff8000810e71a4\n\n This frame has 1 object:\n [32, 160) \u0026apos;rulemap\u0026apos;\n\n The buggy address is at offset 164 -- exactly 4 bytes past the end\n of the rulemap array.\n\nPass 0 instead of rulemap[i + 1].n on the last iteration to avoid\nthe out-of-bounds read.(CVE-2026-43453)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nrtmutex: Use waiter::task instead of current in remove_waiter()\n\nremove_waiter() is used by the slowlock paths, but it is also used for\nproxy-lock rollback in rt_mutex_start_proxy_lock() when invoked from\nfutex_requeue().\n\nIn the latter case waiter::task is not current, but remove_waiter()\noperates on current for the dequeue operation. That results in several\nproblems:\n\n 1) the rbtree dequeue happens without waiter::task::pi_lock being held\n\n 2) the waiter task\u0026apos;s pi_blocked_on state is not cleared, which leaves a\n dangling pointer primed for UAF around.\n\n 3) rt_mutex_adjust_prio_chain() operates on the wrong top priority waiter\n task\n\nUse waiter::task instead of current in all related operations in\nremove_waiter() to cure those problems.\n\n[ tglx: Fixup rt_mutex_adjust_prio_chain(), add a comment and amend the\n \tchangelog ](CVE-2026-43499)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nopenvswitch: cap upcall PID array size and pre-size vport replies\n\nThe vport netlink reply helpers allocate a fixed-size skb with\nnlmsg_new(NLMSG_DEFAULT_SIZE, ...) but serialize the full upcall PID\narray via ovs_vport_get_upcall_portids(). Since\novs_vport_set_upcall_portids() accepts any non-zero multiple of\nsizeof(u32) with no upper bound, a CAP_NET_ADMIN user can install a PID\narray large enough to overflow the reply buffer, causing nla_put() to\nfail with -EMSGSIZE and hitting BUG_ON(err \u0026lt; 0). On systems with\nunprivileged user namespaces enabled (e.g., Ubuntu default), this is\nreachable via unshare -Urn since OVS vport mutation operations use\nGENL_UNS_ADMIN_PERM.\n\n kernel BUG at net/openvswitch/datapath.c:2414!\n Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI\n CPU: 1 UID: 0 PID: 65 Comm: poc Not tainted 7.0.0-rc7-00195-geb216e422044 #1\n RIP: 0010:ovs_vport_cmd_set+0x34c/0x400\n Call Trace:\n \u0026lt;TASK\u0026gt;\n genl_family_rcv_msg_doit (net/netlink/genetlink.c:1116)\n genl_rcv_msg (net/netlink/genetlink.c:1194)\n netlink_rcv_skb (net/netlink/af_netlink.c:2550)\n genl_rcv (net/netlink/genetlink.c:1219)\n netlink_unicast (net/netlink/af_netlink.c:1344)\n netlink_sendmsg (net/netlink/af_netlink.c:1894)\n __sys_sendto (net/socket.c:2206)\n __x64_sys_sendto (net/socket.c:2209)\n do_syscall_64 (arch/x86/entry/syscall_64.c:63)\n entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)\n \u0026lt;/TASK\u0026gt;\n Kernel panic - not syncing: Fatal exception\n\nReject attempts to set more PIDs than nr_cpu_ids in\novs_vport_set_upcall_portids(), and pre-compute the worst-case reply\nsize in ovs_vport_cmd_msg_size() based on that bound, similar to the\nexisting ovs_dp_cmd_msg_size(). nr_cpu_ids matches the cap already\nused by the per-CPU dispatch configuration on the datapath side\n(ovs_dp_cmd_fill_info() serialises at most nr_cpu_ids PIDs), so the\ntwo sides stay consistent.(CVE-2026-45840)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nslip: bound decode() reads against the compressed packet length\n\nslhc_uncompress() parses a VJ-compressed TCP header by advancing a\npointer through the packet via decode() and pull16(). Neither helper\nbounds-checks against isize, and decode() masks its return with\n\u0026amp; 0xffff so it can never return the -1 that callers test for -- those\nerror paths are dead code.\n\nA short compressed frame whose change byte requests optional fields\nlets decode() read past the end of the packet. The over-read bytes\nare folded into the cached cstate and reflected into subsequent\nreconstructed packets.\n\nMake decode() and pull16() take the packet end pointer and return -1\nwhen exhausted. Add a bounds check before the TCP-checksum read.\nThe existing == -1 tests now do what they were always meant to.(CVE-2026-45843)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/rxe: Fix double free in rxe_srq_from_init\n\nIn rxe_srq_from_init(), the queue pointer \u0026apos;q\u0026apos; is assigned to\n\u0026apos;srq-\u0026gt;rq.queue\u0026apos; before copying the SRQ number to user space.\nIf copy_to_user() fails, the function calls rxe_queue_cleanup()\nto free the queue, but leaves the now-invalid pointer in\n\u0026apos;srq-\u0026gt;rq.queue\u0026apos;.\n\nThe caller of rxe_srq_from_init() (rxe_create_srq) eventually\ncalls rxe_srq_cleanup() upon receiving the error, which triggers\na second rxe_queue_cleanup() on the same memory, leading to a\ndouble free.\n\nThe call trace looks like this:\n kmem_cache_free+0x.../0x...\n rxe_queue_cleanup+0x1a/0x30 [rdma_rxe]\n rxe_srq_cleanup+0x42/0x60 [rdma_rxe]\n rxe_elem_release+0x31/0x70 [rdma_rxe]\n rxe_create_srq+0x12b/0x1a0 [rdma_rxe]\n ib_create_srq_user+0x9a/0x150 [ib_core]\n\nFix this by moving \u0026apos;srq-\u0026gt;rq.queue = q\u0026apos; after copy_to_user.(CVE-2026-45852)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niommu/vt-d: Flush cache for PASID table before using it\n\nWhen writing the address of a freshly allocated zero-initialized PASID\ntable to a PASID directory entry, do that after the CPU cache flush for\nthis PASID table, not before it, to avoid the time window when this\nPASID table may be already used by non-coherent IOMMU hardware while\nits contents in RAM is still some random old data, not zero-initialized.(CVE-2026-45862)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niommu/vt-d: Clear Present bit before tearing down PASID entry\n\nThe Intel VT-d Scalable Mode PASID table entry consists of 512 bits (64\nbytes). When tearing down an entry, the current implementation zeros the\nentire 64-byte structure immediately using multiple 64-bit writes.\n\nSince the IOMMU hardware may fetch these 64 bytes using multiple\ninternal transactions (e.g., four 128-bit bursts), updating or zeroing\nthe entire entry while it is active (P=1) risks a \u0026quot;torn\u0026quot; read. If a\nhardware fetch occurs simultaneously with the CPU zeroing the entry, the\nhardware could observe an inconsistent state, leading to unpredictable\nbehavior or spurious faults.\n\nFollow the \u0026quot;Guidance to Software for Invalidations\u0026quot; in the VT-d spec\n(Section 6.5.3.3) by implementing the recommended ownership handshake:\n\n1. Clear only the \u0026apos;Present\u0026apos; (P) bit of the PASID entry.\n2. Use a dma_wmb() to ensure the cleared bit is visible to hardware\n before proceeding.\n3. Execute the required invalidation sequence (PASID cache, IOTLB, and\n Device-TLB flush) to ensure the hardware has released all cached\n references.\n4. Only after the flushes are complete, zero out the remaining fields\n of the PASID entry.\n\nAlso, add a dma_wmb() in pasid_set_present() to ensure that all other\nfields of the PASID entry are visible to the hardware before the Present\nbit is set.(CVE-2026-45894)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: fix ip_rt_bug race in icmp_route_lookup reverse path\n\nicmp_route_lookup() performs multiple route lookups to find a suitable\nroute for sending ICMP error messages, with special handling for XFRM\n(IPsec) policies.\n\nThe lookup sequence is:\n1. First, lookup output route for ICMP reply (dst = original src)\n2. Pass through xfrm_lookup() for policy check\n3. If blocked (-EPERM) or dst is not local, enter \u0026quot;reverse path\u0026quot;\n4. In reverse path, call xfrm_decode_session_reverse() to get fl4_dec\n which reverses the original packet\u0026apos;s flow (saddr\u0026lt;-\u0026gt;daddr swapped)\n5. If fl4_dec.saddr is local (we are the original destination), use\n __ip_route_output_key() for output route lookup\n6. If fl4_dec.saddr is NOT local (we are a forwarding node), use\n ip_route_input() to simulate the reverse packet\u0026apos;s input path\n7. Finally, pass rt2 through xfrm_lookup() with XFRM_LOOKUP_ICMP flag\n\nThe bug occurs in step 6: ip_route_input() is called with fl4_dec.daddr\n(original packet\u0026apos;s source) as destination. If this address becomes local\nbetween the initial check and ip_route_input() call (e.g., due to\nconcurrent \u0026quot;ip addr add\u0026quot;), ip_route_input() returns a LOCAL route with\ndst.output set to ip_rt_bug.\n\nThis route is then used for ICMP output, causing dst_output() to call\nip_rt_bug(), triggering a WARN_ON:\n\n ------------[ cut here ]------------\n WARNING: net/ipv4/route.c:1275 at ip_rt_bug+0x21/0x30, CPU#1\n Call Trace:\n \u0026lt;TASK\u0026gt;\n ip_push_pending_frames+0x202/0x240\n icmp_push_reply+0x30d/0x430\n __icmp_send+0x1149/0x24f0\n ip_options_compile+0xa2/0xd0\n ip_rcv_finish_core+0x829/0x1950\n ip_rcv+0x2d7/0x420\n __netif_receive_skb_one_core+0x185/0x1f0\n netif_receive_skb+0x90/0x450\n tun_get_user+0x3413/0x3fb0\n tun_chr_write_iter+0xe4/0x220\n ...\n\nFix this by checking rt2-\u0026gt;rt_type after ip_route_input(). If it\u0026apos;s\nRTN_LOCAL, the route cannot be used for output, so treat it as an error.\n\nThe reproducer requires kernel modification to widen the race window,\nmaking it unsuitable as a selftest. It is available at:\n\n https://gist.github.com/mrpre/eae853b72ac6a750f5d45d64ddac1e81(CVE-2026-45905)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRevert \u0026quot;hwmon: (ibmpex) fix use-after-free in high/low store\u0026quot;\n\nThis reverts commit 6946c726c3f4c36f0f049e6f97e88c510b15f65d.\n\nJean Delvare points out that the patch does not completely\nfix the reported problem, that it in fact introduces a\n(new) race condition, and that it may actually not be needed in\nthe first place.\n\nVarious AI reviews agree. Specific and relevant AI feedback:\n\n\u0026quot;\nThis reordering sets the driver data to NULL before removing the sensor\nattributes in the loop below.\n\nibmpex_show_sensor() retrieves this driver data via dev_get_drvdata() but\ndoes not check if it is NULL before dereferencing it to access\ndata-\u0026gt;sensors[].\n\nIf a userspace process reads a sensor file (like temp1_input) while this\ndelete function is running, could it race with the dev_set_drvdata(...,\nNULL) call here and crash in ibmpex_show_sensor()?\n\nWould it be safer to keep the original order where device_remove_file() is\ncalled before clearing the driver data? device_remove_file() should wait\nfor any active sysfs callbacks to complete, which might already prevent the\nuse-after-free this patch intends to fix.\n\u0026quot;\n\nRevert the offending patch. If it can be shown that the originally reported\nalleged race condition does indeed exist, it can always be re-introduced\nwith a complete fix.(CVE-2026-45914)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfat: avoid parent link count underflow in rmdir\n\nCorrupted FAT images can leave a directory inode with an incorrect\ni_nlink (e.g. 2 even though subdirectories exist). rmdir then\nunconditionally calls drop_nlink(dir) and can drive i_nlink to 0,\ntriggering the WARN_ON in drop_nlink().\n\nAdd a sanity check in vfat_rmdir() and msdos_rmdir(): only drop the\nparent link count when it is at least 3, otherwise report a filesystem\nerror.(CVE-2026-45915)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsched/rt: Skip currently executing CPU in rto_next_cpu()\n\nCPU0 becomes overloaded when hosting a CPU-bound RT task, a non-CPU-bound\nRT task, and a CFS task stuck in kernel space. When other CPUs switch from\nRT to non-RT tasks, RT load balancing (LB) is triggered; with\nHAVE_RT_PUSH_IPI enabled, they send IPIs to CPU0 to drive the execution\nof rto_push_irq_work_func. During push_rt_task on CPU0,\nif next_task-\u0026gt;prio \u0026lt; rq-\u0026gt;donor-\u0026gt;prio, resched_curr() sets NEED_RESCHED\nand after the push operation completes, CPU0 calls rto_next_cpu().\nSince only CPU0 is overloaded in this scenario, rto_next_cpu() should\nideally return -1 (no further IPI needed).\n\nHowever, multiple CPUs invoking tell_cpu_to_push() during LB increments\nrd-\u0026gt;rto_loop_next. Even when rd-\u0026gt;rto_cpu is set to -1, the mismatch between\nrd-\u0026gt;rto_loop and rd-\u0026gt;rto_loop_next forces rto_next_cpu() to restart its\nsearch from -1. With CPU0 remaining overloaded (satisfying rt_nr_migratory\n\u0026amp;\u0026amp; rt_nr_total \u0026gt; 1), it gets reselected, causing CPU0 to queue irq_work to\nitself and send self-IPIs repeatedly. As long as CPU0 stays overloaded and\nother CPUs run pull_rt_tasks(), it falls into an infinite self-IPI loop,\nwhich triggers a CPU hardlockup due to continuous self-interrupts.\n\nThe trigging scenario is as follows:\n\n cpu0 cpu1 cpu2\n pull_rt_task\n tell_cpu_to_push\n \u0026lt;------------irq_work_queue_on\nrto_push_irq_work_func\n push_rt_task\n resched_curr(rq) pull_rt_task\n rto_next_cpu tell_cpu_to_push\n \u0026lt;-------------------------- atomic_inc(rto_loop_next)\nrd-\u0026gt;rto_loop != next\n rto_next_cpu\n irq_work_queue_on\nrto_push_irq_work_func\n\nFix redundant self-IPI by filtering the initiating CPU in rto_next_cpu().\nThis solution has been verified to effectively eliminate spurious self-IPIs\nand prevent CPU hardlockup scenarios.(CVE-2026-45919)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: fix dirtyclusters double decrement on fs shutdown\n\nfstests test generic/388 occasionally reproduces a warning in\next4_put_super() associated with the dirty clusters count:\n\n WARNING: CPU: 7 PID: 76064 at fs/ext4/super.c:1324 ext4_put_super+0x48c/0x590 [ext4]\n\nTracing the failure shows that the warning fires due to an\ns_dirtyclusters_counter value of -1. IOW, this appears to be a\nspurious decrement as opposed to some sort of leak. Further tracing\nof the dirty cluster count deltas and an LLM scan of the resulting\noutput identified the cause as a double decrement in the error path\nbetween ext4_mb_mark_diskspace_used() and the caller\next4_mb_new_blocks().\n\nFirst, note that generic/388 is a shutdown vs. fsstress test and so\nproduces a random set of operations and shutdown injections. In the\nproblematic case, the shutdown triggers an error return from the\next4_handle_dirty_metadata() call(s) made from\next4_mb_mark_context(). The changed value is non-zero at this point,\nso ext4_mb_mark_diskspace_used() does not exit after the error\nbubbles up from ext4_mb_mark_context(). Instead, the former\ndecrements both cluster counters and returns the error up to\next4_mb_new_blocks(). The latter falls into the !ar-\u0026gt;len out path\nwhich decrements the dirty clusters counter a second time, creating\nthe inconsistency.\n\nTo avoid this problem and simplify ownership of the cluster\nreservation in this codepath, lift the counter reduction to a single\nplace in the caller. This makes it more clear that\next4_mb_new_blocks() is responsible for acquiring cluster\nreservation (via ext4_claim_free_clusters()) in the !delalloc case\nas well as releasing it, regardless of whether it ends up consumed\nor returned due to failure.(CVE-2026-45920)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs/ntfs3: Fix slab-out-of-bounds read in DeleteIndexEntryRoot\n\nIn the \u0026apos;DeleteIndexEntryRoot\u0026apos; case of the \u0026apos;do_action\u0026apos; function, the\nentry size (\u0026apos;esize\u0026apos;) is retrieved from the log record without adequate\nbounds checking.\n\nSpecifically, the code calculates the end of the entry (\u0026apos;e2\u0026apos;) using:\n e2 = Add2Ptr(e1, esize);\n\nIt then calculates the size for memmove using \u0026apos;PtrOffset(e2, ...)\u0026apos;,\nwhich subtracts the end pointer from the buffer limit. If \u0026apos;esize\u0026apos; is\nmaliciously large, \u0026apos;e2\u0026apos; exceeds the used buffer size. This results in\na negative offset which, when cast to size_t for memmove, interprets\nas a massive unsigned integer, leading to a heap buffer overflow.\n\nThis commit adds a check to ensure that the entry size (\u0026apos;esize\u0026apos;) strictly\nfits within the remaining used space of the index header before performing\nmemory operations.(CVE-2026-45935)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niommu/vt-d: Clear Present bit before tearing down context entry\n\nWhen tearing down a context entry, the current implementation zeros the\nentire 128-bit entry using multiple 64-bit writes. This creates a window\nwhere the hardware can fetch a \u0026quot;torn\u0026quot; entry \u2014 where some fields are\nalready zeroed while the \u0026apos;Present\u0026apos; bit is still set \u2014 leading to\nunpredictable behavior or spurious faults.\n\nWhile x86 provides strong write ordering, the compiler may reorder writes\nto the two 64-bit halves of the context entry. Even without compiler\nreordering, the hardware fetch is not guaranteed to be atomic with\nrespect to multiple CPU writes.\n\nAlign with the \u0026quot;Guidance to Software for Invalidations\u0026quot; in the VT-d spec\n(Section 6.5.3.3) by implementing the recommended ownership handshake:\n\n1. Clear only the \u0026apos;Present\u0026apos; (P) bit of the context entry first to\n signal the transition of ownership from hardware to software.\n2. Use dma_wmb() to ensure the cleared bit is visible to the IOMMU.\n3. Perform the required cache and context-cache invalidation to ensure\n hardware no longer has cached references to the entry.\n4. Fully zero out the entry only after the invalidation is complete.\n\nAlso, add a dma_wmb() to context_set_present() to ensure the entry\nis fully initialized before the \u0026apos;Present\u0026apos; bit becomes visible.(CVE-2026-45944)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: fix memory leak in ext4_ext_shift_extents()\n\nIn ext4_ext_shift_extents(), if the extent is NULL in the while loop, the\nfunction returns immediately without releasing the path obtained via\next4_find_extent(), leading to a memory leak.\n\nFix this by jumping to the out label to ensure the path is properly\nreleased.(CVE-2026-45948)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: never defer requests during idmap lookup\n\nDuring v4 request compound arg decoding, some ops (e.g. SETATTR)\ncan trigger idmap lookup upcalls. When those upcall responses get\ndelayed beyond the allowed time limit, cache_check() will mark the\nrequest for deferral and cause it to be dropped.\n\nThis prevents nfs4svc_encode_compoundres from being executed, and\nthus the session slot flag NFSD4_SLOT_INUSE never gets cleared.\nSubsequent client requests will fail with NFSERR_JUKEBOX, given\nthat the slot will be marked as in-use, making the SEQUENCE op\nfail.\n\nFix this by making sure that the RQ_USEDEFERRAL flag is always\nclear during nfs4svc_decode_compoundargs(), since no v4 request\nshould ever be deferred.(CVE-2026-45983)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: don\u0026apos;t set EXT4_GET_BLOCKS_CONVERT when splitting before submitting I/O\n\nWhen allocating blocks during within-EOF DIO and writeback with\ndioread_nolock enabled, EXT4_GET_BLOCKS_PRE_IO was set to split an\nexisting large unwritten extent. However, EXT4_GET_BLOCKS_CONVERT was\nset when calling ext4_split_convert_extents(), which may potentially\nresult in stale data issues.\n\nAssume we have an unwritten extent, and then DIO writes the second half.\n\n [UUUUUUUUUUUUUUUU] on-disk extent U: unwritten extent\n [UUUUUUUUUUUUUUUU] extent status tree\n |\u0026lt;- -\u0026gt;| ----\u0026gt; dio write this range\n\nFirst, ext4_iomap_alloc() call ext4_map_blocks() with\nEXT4_GET_BLOCKS_PRE_IO, EXT4_GET_BLOCKS_UNWRIT_EXT and\nEXT4_GET_BLOCKS_CREATE flags set. ext4_map_blocks() find this extent and\ncall ext4_split_convert_extents() with EXT4_GET_BLOCKS_CONVERT and the\nabove flags set.\n\nThen, ext4_split_convert_extents() calls ext4_split_extent() with\nEXT4_EXT_MAY_ZEROOUT, EXT4_EXT_MARK_UNWRIT2 and EXT4_EXT_DATA_VALID2\nflags set, and it calls ext4_split_extent_at() to split the second half\nwith EXT4_EXT_DATA_VALID2, EXT4_EXT_MARK_UNWRIT1, EXT4_EXT_MAY_ZEROOUT\nand EXT4_EXT_MARK_UNWRIT2 flags set. However, ext4_split_extent_at()\nfailed to insert extent since a temporary lack -ENOSPC. It zeroes out\nthe first half but convert the entire on-disk extent to written since\nthe EXT4_EXT_DATA_VALID2 flag set, but left the second half as unwritten\nin the extent status tree.\n\n [0000000000SSSSSS] data S: stale data, 0: zeroed\n [WWWWWWWWWWWWWWWW] on-disk extent W: written extent\n [WWWWWWWWWWUUUUUU] extent status tree\n\nFinally, if the DIO failed to write data to the disk, the stale data in\nthe second half will be exposed once the cached extent entry is gone.\n\nFix this issue by not passing EXT4_GET_BLOCKS_CONVERT when splitting\nan unwritten extent before submitting I/O, and make\next4_split_convert_extents() to zero out the entire extent range\nto zero for this case, and also mark the extent in the extent status\ntree for consistency.(CVE-2026-45985)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: nSVM: Sync interrupt shadow to cached vmcb12 after VMRUN of L2\n\nAfter VMRUN in guest mode, nested_sync_control_from_vmcb02() syncs\nfields written by the CPU from vmcb02 to the cached vmcb12. This is\nbecause the cached vmcb12 is used as the authoritative copy of some of\nthe controls, and is the payload when saving/restoring nested state.\n\nint_state is also written by the CPU, specifically bit 0 (i.e.\nSVM_INTERRUPT_SHADOW_MASK) for nested VMs, but it is not sync\u0026apos;d to\ncached vmcb12. This does not cause a problem if KVM_SET_NESTED_STATE\npreceeds KVM_SET_VCPU_EVENTS in the restore path, as an interrupt shadow\nwould be correctly restored to vmcb02 (KVM_SET_VCPU_EVENTS overwrites\nwhat KVM_SET_NESTED_STATE restored in int_state).\n\nHowever, if KVM_SET_VCPU_EVENTS preceeds KVM_SET_NESTED_STATE, an\ninterrupt shadow would be restored into vmcb01 instead of vmcb02. This\nwould mostly be benign for L1 (delays an interrupt), but not for L2. For\nL2, the vCPU could hang (e.g. if a wakeup interrupt is delivered before\na HLT that should have been in an interrupt shadow).\n\nSync int_state to the cached vmcb12 in nested_sync_control_from_vmcb02()\nto avoid this problem. With that, KVM_SET_NESTED_STATE restores the\ncorrect interrupt shadow state, and if KVM_SET_VCPU_EVENTS follows it\nwould overwrite it with the same value.(CVE-2026-45987)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nudf: fix partition descriptor append bookkeeping\n\nMounting a crafted UDF image with repeated partition descriptors can\ntrigger a heap out-of-bounds write in part_descs_loc[].\n\nhandle_partition_descriptor() deduplicates entries by partition number,\nbut appended slots never record partnum. As a result duplicate\nPartition Descriptors are appended repeatedly and num_part_descs keeps\ngrowing.\n\nOnce the table is full, the growth path still sizes the allocation from\npartnum even though inserts are indexed by num_part_descs. If partnum is\nalready aligned to PART_DESC_ALLOC_STEP, ALIGN(partnum, step) can keep\nthe old capacity and the next append writes past the end of the table.\n\nStore partnum in the appended slot and size growth from the next append\ncount so deduplication and capacity tracking follow the same model.(CVE-2026-45991)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nALSA: usb-audio: stop parsing UAC2 rates at MAX_NR_RATES\n\nparse_uac2_sample_rate_range() caps the number of enumerated\nrates at MAX_NR_RATES, but it only breaks out of the current\nrate loop. A malformed UAC2 RANGE response with additional\ntriplets continues parsing the remaining triplets and repeatedly\nprints \u0026quot;invalid uac2 rates\u0026quot; while probe still holds\nregister_mutex.\n\nStop the whole parse once the cap is reached and return the\nnumber of rates collected so far.(CVE-2026-46018)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndm mirror: fix integer overflow in create_dirty_log()\n\nThe argument count calculation in create_dirty_log() performs\n`*args_used = 2 + param_count` before validating against argc. When a\nuser provides a param_count close to UINT_MAX via the device mapper\ntable string, this unsigned addition wraps around to a small value,\ncausing the subsequent `argc \u0026lt; *args_used` check to be bypassed.\n\nThe overflowed param_count is then passed as argc to dm_dirty_log_create(),\nwhere it can cause out-of-bounds reads on the argv array.\n\nFix by comparing param_count against argc - 2 before performing the\naddition, following the same pattern used by parse_features() in the\nsame file. Since argc \u0026gt;= 2 is already guaranteed, the subtraction is\nsafe.(CVE-2026-46023)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: algif_aead - snapshot IV for async AEAD requests\n\nAF_ALG AEAD AIO requests currently use the socket-wide IV buffer during\nrequest processing. For async requests, later socket activity can\nupdate that shared state before the original request has fully\ncompleted, which can lead to inconsistent IV handling.\n\nSnapshot the IV into per-request storage when preparing the AEAD\nrequest, so in-flight operations no longer depend on mutable socket\nstate.(CVE-2026-46028)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: nSVM: Triple fault if restore host CR3 fails on nested #VMEXIT\n\nIf loading L1\u0026apos;s CR3 fails on a nested #VMEXIT, nested_svm_vmexit()\nreturns an error code that is ignored by most callers, and continues to\nrun L1 with corrupted state. A sane recovery is not possible in this\ncase, and HW behavior is to cause a shutdown. Inject a triple fault\ninstead, and do not return early from nested_svm_vmexit(). Continue\ncleaning up the vCPU state (e.g. clear pending exceptions), to handle\nthe failure as gracefully as possible.\n\nFrom the APM:\n\n Upon #VMEXIT, the processor performs the following actions in order to\n return to the host execution context:\n\n ...\n\n if (illegal host state loaded, or exception while loading host state)\n shutdown\n else\n execute first host instruction following the VMRUN\n\nRemove the return value of nested_svm_vmexit(), which is mostly\nunchecked anyway.(CVE-2026-46032)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/rxe: Validate pad and ICRC before payload_size() in rxe_rcv\n\nrxe_rcv() currently checks only that the incoming packet is at least\nheader_size(pkt) bytes long before payload_size() is used.\n\nHowever, payload_size() subtracts both the attacker-controlled BTH pad\nfield and RXE_ICRC_SIZE from pkt-\u0026gt;paylen:\n\n payload_size = pkt-\u0026gt;paylen - offset[RXE_PAYLOAD] - bth_pad(pkt)\n - RXE_ICRC_SIZE\n\nThis means a short packet can still make payload_size() underflow even\nif it includes enough bytes for the fixed headers. Simply requiring\nheader_size(pkt) + RXE_ICRC_SIZE is not sufficient either, because a\npacket with a forged non-zero BTH pad can still leave payload_size()\nnegative and pass an underflowed value to later receive-path users.\n\nFix this by validating pkt-\u0026gt;paylen against the full minimum length\nrequired by payload_size(): header_size(pkt) + bth_pad(pkt) +\nRXE_ICRC_SIZE.(CVE-2026-46043)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nALSA: ctxfi: Add fallback to default RSR for S/PDIF\n\nspdif_passthru_playback_get_resources() uses atc-\u0026gt;pll_rate as the RSR\nfor the MSR calculation loop. However, pll_rate is only updated in\natc_pll_init() and not in hw_pll_init(), so it remains 0 after the\ncard init.\n\nWhen spdif_passthru_playback_setup() skips atc_pll_init() for\n32000 Hz, (rsr * desc.msr) always becomes 0, causing the loop to spin\nindefinitely.\n\nAdd fallback to use atc-\u0026gt;rsr when atc-\u0026gt;pll_rate is 0. This reflects\nthe hardware state, since hw_card_init() already configures the PLL\nto the default RSR.(CVE-2026-46049)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_event: fix potential UAF in SSP passkey handlers\n\nhci_conn lookup and field access must be covered by hdev lock in\nhci_user_passkey_notify_evt() and hci_keypress_notify_evt(), otherwise\nthe connection can be freed concurrently.\n\nExtend the hci_dev_lock critical section to cover all conn usage in both\nhandlers.\n\nKeep the existing keypress notification behavior unchanged by routing\nthe early exits through a common unlock path.(CVE-2026-46056)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfbdev: defio: Disconnect deferred I/O from the lifetime of struct fb_info\n\nHold state of deferred I/O in struct fb_deferred_io_state. Allocate an\ninstance as part of initializing deferred I/O and remove it only after\nthe final mapping has been closed. If the fb_info and the contained\ndeferred I/O meanwhile goes away, clear struct fb_deferred_io_state.info\nto invalidate the mapping. Any access will then result in a SIGBUS\nsignal.\n\nFixes a long-standing problem, where a device hot-unplug happens while\nuser space still has an active mapping of the graphics memory. The hot-\nunplug frees the instance of struct fb_info. Accessing the memory will\noperate on undefined state.(CVE-2026-46065)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nspi: fix resource leaks on device setup failure\n\nMake sure to call controller cleanup() if spi_setup() fails while\nregistering a device to avoid leaking any resources allocated by\nsetup().(CVE-2026-46083)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nALSA: control: Validate buf_len before strnlen() in snd_ctl_elem_init_enum_names()\n\nsnd_ctl_elem_init_enum_names() advances pointer p through the names\nbuffer while decrementing buf_len. If buf_len reaches zero but items\nremain, the next iteration calls strnlen(p, 0).\n\nWhile strnlen(p, 0) returns 0 and would hit the existing name_len == 0\nerror path, CONFIG_FORTIFY_SOURCE\u0026apos;s fortified strnlen() first checks\nmaxlen against __builtin_dynamic_object_size(). When Clang loses track\nof p\u0026apos;s object size inside the loop, this triggers a BRK exception panic\nbefore the return value is examined.\n\nAdd a buf_len == 0 guard at the loop entry to prevent calling fortified\nstrnlen() on an exhausted buffer.\n\nFound by kernel fuzz testing through Xiaomi Smartphone.(CVE-2026-46088)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: reject zero shift in nft_bitwise\n\nReject zero shift operands for nft_bitwise left and right shift\nexpressions during initialization.\n\nThe carry propagation logic computes the carry from the adjacent 32-bit\nword using BITS_PER_TYPE(u32) - shift. A zero shift operand turns this\ninto a 32-bit shift, which is undefined behaviour.\n\nReject zero shift operands in the control plane, alongside the existing\ncheck for values greater than or equal to 32, so malformed rules never\nreach the packet path.(CVE-2026-46101)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: strparser: fix skb_head leak in strp_abort_strp()\n\nWhen the stream parser is aborted, for example after a message assembly timeout,\nit can still hold a reference to a partially assembled message in\nstrp-\u0026gt;skb_head.\n\nThat skb is not released in strp_abort_strp(), which leaks the partially\nassembled message and can be triggered repeatedly to exhaust memory.\n\nFix this by freeing strp-\u0026gt;skb_head and resetting the parser state in the\nabort path. Leave strp_stop() unchanged so final cleanup still happens in\nstrp_done() after the work and timer have been synchronized.(CVE-2026-46102)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndm-thin: fix metadata refcount underflow\n\nThere\u0026apos;s a bug in dm-thin in the function rebalance_children. If the\ninternal btree node has one entry, the code tries to copy all btree\nentries from the node\u0026apos;s child to the node itself and then decrement the\nchild\u0026apos;s reference count.\n\nIf the child node is shared (it has reference count \u0026gt; 1), we won\u0026apos;t free\nit, so there would be two pointers to each of the grandchildren nodes.\nBut the reference counts of the grandchildren is not increased, thus the\nreference count doesn\u0026apos;t match the number of pointers that point to the\ngrandchildren. This results in \u0026quot;device mapper: space map common: unable\nto decrement block\u0026quot; errors.\n\nFix this bug by incrementing reference counts on the grandchildren if the\nbtree node is shared.(CVE-2026-46107)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: defensively unhash xfrm_state lists in __xfrm_state_delete\n\nKASAN reproduces a slab-use-after-free in __xfrm_state_delete()\u0026apos;s\nhlist_del_rcu calls under syzkaller load on linux-6.12.y stable\n(reproduced on 6.12.47, also reachable via the same code path on\ntorvalds/master and on the ipsec tree). Nine unique signatures cluster\nin the xfrm_state lifecycle, the load-bearing one being:\n\n BUG: KASAN: slab-use-after-free in __hlist_del include/linux/list.h:990 [inline]\n BUG: KASAN: slab-use-after-free in hlist_del_rcu include/linux/rculist.h:516 [inline]\n BUG: KASAN: slab-use-after-free in __xfrm_state_delete net/xfrm/xfrm_state.c\n Write of size 8 at addr ffff8881198bcb70 by task kworker/u8:9/435\n\n Workqueue: netns cleanup_net\n Call Trace:\n __hlist_del / hlist_del_rcu\n __xfrm_state_delete\n xfrm_state_delete\n xfrm_state_flush\n xfrm_state_fini\n ops_exit_list\n cleanup_net\n\nThe other observed signatures hit the same slab object from\n__xfrm_state_lookup, xfrm_alloc_spi, __xfrm_state_insert and an OOB\nwrite variant of __xfrm_state_delete, all on the byseq/byspi\nhash chains.\n\n__xfrm_state_delete() guards its byseq and byspi unhashes with\nvalue-based predicates:\n\n\tif (x-\u0026gt;km.seq)\n\t\thlist_del_rcu(\u0026amp;x-\u0026gt;byseq);\n\tif (x-\u0026gt;id.spi)\n\t\thlist_del_rcu(\u0026amp;x-\u0026gt;byspi);\n\nwhile everywhere else in the file (e.g. state_cache, state_cache_input)\nthe safer hlist_unhashed() check is used. xfrm_alloc_spi() sets\nx-\u0026gt;id.spi = newspi inside xfrm_state_lock and then immediately inserts\ninto byspi, but a path that observes x-\u0026gt;id.spi != 0 outside of\nxfrm_state_lock can still skip-or-hit the byspi unhash inconsistently\nwith whether x is actually on the list. The same holds for x-\u0026gt;km.seq\nversus byseq, and the bydst/bysrc unhashes have no predicate at all,\nso a second __xfrm_state_delete() on the same object writes through\nLIST_POISON pprev.\n\nThe defensive change here:\n\n - Use hlist_del_init_rcu() instead of hlist_del_rcu() on bydst,\n bysrc, byseq and byspi so a second deletion is a no-op rather\n than a write through LIST_POISON pprev. The byseq/byspi nodes\n are already initialised in xfrm_state_alloc().\n - Test hlist_unhashed() rather than the value predicate for\n byseq/byspi, so the unhash decision tracks list state rather than\n mutable scalar fields.\n\nEmpirical verification: applied this patch on top of v6.12.47, rebuilt,\nand re-ran the same syzkaller harness for 1h16m on a previously-crashy\nconfiguration that produced ~100 hits each of slab-use-after-free\nRead in xfrm_alloc_spi / Read in __xfrm_state_lookup / Write in\n__xfrm_state_delete. After the patch, 7.1M execs across 32 VMs at\n~1550 exec/sec produced zero xfrm_state UAF/OOB hits. /proc/slabinfo\nconfirms the xfrm_state slab is actively allocated and freed during\nthe run (~143 KiB resident), so the fuzzer is still exercising those\ncode paths -- they just no longer crash.\n\nReproduction:\n\n - Linux 6.12.47 x86_64 + KASAN_GENERIC + KASAN_INLINE + KCOV\n - syzkaller @ 746545b8b1e4c3a128db8652b340d3df90ce61db\n - 32 QEMU/KVM VMs x 2 vCPU on AWS c5.metal bare metal\n - 9 unique signatures collected in ~9h, all within xfrm_state\n lifecycle(CVE-2026-46116)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: rtnetlink: zero ifla_vf_broadcast to avoid stack infoleak in rtnl_fill_vfinfo\n\nrtnl_fill_vfinfo() declares struct ifla_vf_broadcast on the stack\nwithout initialisation:\n\n\tstruct ifla_vf_broadcast vf_broadcast;\n\nThe struct contains a single fixed 32-byte field:\n\n\t/* include/uapi/linux/if_link.h */\n\tstruct ifla_vf_broadcast {\n\t\t__u8 broadcast[32];\n\t};\n\nThe function then copies dev-\u0026gt;broadcast into it using dev-\u0026gt;addr_len\nas the length:\n\n\tmemcpy(vf_broadcast.broadcast, dev-\u0026gt;broadcast, dev-\u0026gt;addr_len);\n\nOn Ethernet devices (the overwhelming majority of SR-IOV NICs)\ndev-\u0026gt;addr_len is 6, so only the first 6 bytes of broadcast[] are\nwritten. The remaining 26 bytes retain whatever was previously on\nthe kernel stack. The full struct is then handed to userspace via:\n\n\tnla_put(skb, IFLA_VF_BROADCAST,\n\t\tsizeof(vf_broadcast), \u0026amp;vf_broadcast)\n\nleaking up to 26 bytes of uninitialised kernel stack per VF per\nRTM_GETLINK request, repeatable.\n\nThe other vf_* structs in the same function are explicitly zeroed\nfor exactly this reason - see the memset() calls for ivi,\nvf_vlan_info, node_guid and port_guid a few lines above.\nvf_broadcast was simply missed when it was added.\n\nReachability: any unprivileged local process can open AF_NETLINK /\nNETLINK_ROUTE without capabilities and send RTM_GETLINK with an\nIFLA_EXT_MASK attribute carrying RTEXT_FILTER_VF. The kernel walks\neach VF and emits IFLA_VF_BROADCAST, leaking 26 bytes of stack per\nVF per request. Stack residue at this call site can include return\naddresses and transient sensitive data; KASAN with stack\ninstrumentation, or KMSAN, will flag the nla_put() when reproduced.\n\nZero the on-stack struct before the partial memcpy, matching the\nexisting pattern used for the other vf_* structs in the same\nfunction.(CVE-2026-46132)\n\nIn the Linux kernel, xfrm6_rcv_encap() performs an IPv6 route lookup when the skb does not already have a dst attached. ip6_route_input_lookup() returns a referenced dst entry even when the lookup resolves to an error route. If dst-\u0026gt;error is set, xfrm6_rcv_encap() drops the skb without attaching the dst to the skb and without releasing the reference returned by the lookup. Repeated packets hitting this path therefore leak dst entries.(CVE-2026-46172)\n\nIn the Linux kernel, the mlx4_ib_create_srq() function fails to release resources allocated by mlx4_srq_alloc() in error handling paths, leading to a resource leak. An attacker could exploit this vulnerability to cause resource exhaustion or denial of service.(CVE-2026-46178)\n\nIn the Linux kernel, the ua101 driver has a division by zero vulnerability at probe. The detect_usb_format() function lacks a sanity check for the bNrChannels field. When a malicious USB audio device provides bNrChannels=0, frame_bytes becomes zero and is later used as a divisor in playback_urb_complete() and capture_urb_complete(), causing a kernel crash. USB core does not validate class-specific descriptor fields, so drivers must verify them before use.(CVE-2026-46184)\n\nIn the Linux kernel, drm_gem_fb_init_with_funcs() computes sub-sampled plane dimensions using plain integer division, while the ioctl-level framebuffer_check() uses DIV_ROUND_UP via drm_format_info_plane_width/height(). This inconsistency causes incorrect GEM object size validation for certain pixel formats and dimensions, e.g., NV12 with height=1 results in height=0, leading to an integer overflow in size check and allowing undersized GEM objects to pass, potentially causing out-of-bounds memory access by the GPU.(CVE-2026-46209)\n\n[\u0026apos;This has been assigned CVE-2026-46243, see\u0026apos;, \u0026apos;On Thursday, May 28th, 2026 at 12:07 AM, manizada \u0026lt;manizada () pm me\u0026gt; wrote:\u0026apos;, \u0026apos;Hi folks,\\n\\nEmailing here now that the embargo agreed upon with linux-distros@ has expired.\\n\\nFlagging a local root vulnerability spanning both CIFS in the kernel and\\ncifs-utils in userspace (originally reported to kernel/cifs maintainers on May 16).\\nThe kernel-side (only) fix has now been public for over a week and is queued for stable:\\n\\n3da1fdf4efbc (\u0026quot;smb: client: reject userspace cifs.spnego descriptions\u0026quot;)\\n\\nImpact:\\n Unprivileged user -\u0026gt; root code exec on any system where:\\n - cifs-utils is installed (with the default cifs.spnego rule)\\n - CIFS kernel module is loadable/compiled-in (typically the case), and\\n - unprivileged user/mount namespaces are enabled.\\n\\nSome default AppArmor/SELinux profiles block this.\\n\\nBug:\\n An unprivileged user can call request_key(\u0026quot;cifs.spnego\u0026quot;, ...) with a forged\\n CIFS SPNEGO description. The request-key rule starts cifs.upcall as root.\\n cifs.upcall then trusts attacker-supplied pid, uid, creduid, and\\n upcall_target fields as if they came from kernel CIFS.\\n\\n For upcall_target=app, affected cifs-utils versions switch into the supplied\\n process\\\u0026apos;s namespaces and perform NSS lookup before final privilege drop.\\n A private mount namespace containing attacker-controlled /etc/nsswitch.conf\\n and libnss_*.so.2 is therefore sufficient for code execution in the root\\n helper.\\n\\nAffected distros:\\n This a non-exhaustive summary of some tested distros. The full table, including\\n the cases where stock policy blocks exploitation (but relaxing AppArmor/SELinux/etc.\\n enables exploitation), is in the attachment (and in an easier-to-read format in\\n the writeup linked below).\\n\\n Stock-default exploitable distros\\n (cifs-utils comes preinstalled in the profile + unprivileged namespaces permitted by default\\n + the AA/SELinux policies, if any, do not block the attack):\\n\\n - Linux Mint Cinnamon 21.3 and 22.3\\n - CentOS Stream 9 GNOME\\n - Rocky Linux 9 Workstation\\n - Kali Linux headless 2021.4/2022.4/2023.4/2024.4/2025.4/2026.1\\n - AlmaLinux 9.7 Workstation/Azure cloud image\\n - SLES 15 SP7/SAP 15 SP7/SAP 16\\n\\n Exploitable if cifs-utils is installed, with no other default config changes:\\n - Ubuntu 18.04/20.04/22.04 Desktop/Server\\n - Pop!_OS 22.04 Intel/24.04 Generic\\n - Ubuntu 24.04 Desktop minimal/full and Server\\n - Debian 11/12/13 netinst standard and GNOME/KDE/standard/XFCE\\n - CentOS Stream 9 Cinnamon/KDE/MATE/XFCE\\n - Rocky Linux 9 KDE/Workstation-Lite\\n - openSUSE Leap 15.6 GNOME/KDE\\n - openSUSE Tumbleweed GNOME/KDE\\n - Rocky Linux 8 GenericCloud\\n - Oracle Linux 8/9 KVM\\n - Amazon Linux 2023 KVM\\n\\nImmediate-term mitigations (aside from backporting the kernel fix):\\n - Blocking the CIFS module from loading (assuming it\\\u0026apos;s not built-in)/uninstalling cifs-utils if not used\\n - Deleting/overriding the default cifs.spnego request-key rule (if Kerberos cifs is not required),\\n e.g., after adjusting for your keyctl path:\\n\\n cat \u0026gt;/etc/request-key.d/cifs.spnego.conf \u0026lt;\u0026lt;\\\u0026apos;EOF\\\u0026apos;\\n create cifs.spnego * * /usr/sbin/keyctl negate %k 30 %S\\n EOF\\n\\n - Disabling unprivileged user namespaces\\n\\nThe CVE # assignment is still pending.\\n\\nFull writeup:\u0026apos;, \u0026apos;PoC to validate mitigations:\u0026apos;, \u0026apos;Thanks,\\n-Asim Manizada\u0026apos;](CVE-2026-46243)\n\nIn the Linux kernel, the following vulnerability has been resolved: MIPS: Work around LLVM bug when gp is used as global register variable On MIPS, __current_thread_info is defined as global register variable locating in $gp, and is simply assigned with new address during kernel relocation. This however is broken with LLVM, which always restores $gp if it finds $gp is clobbered in any form, including when intentionally through a global register variable. This is against GCC\u0026apos;s documentation[1], which requires a callee-saved register used as global register variable not to be restored if it\u0026apos;s clobbered. As a result, $gp will continue to point to the unrelocated kernel after the epilog of relocate_kernel(), leading to an early crash in init_idle, [ 0.000000] CPU 0 Unable to handle kernel paging request at virtual address 0000000000000000, epc == ffffffff81afada8, ra == ffffffff81afad90 [ 0.000000] Oops[#1]: [ 0.000000] CPU: 0 UID: 0 PID: 0 Comm: swapper Tainted: G W 6.19.0-rc5-00262-gd3eeb99bbc99-dirty #188 VOLUNTARY [ 0.000000] Tainted: [W]=WARN [ 0.000000] Hardware name: loongson,loongson64v-4core-virtio [ 0.000000] $ 0 : 0000000000000000 0000000000000000 0000000000000001 0000000000000000 [ 0.000000] $ 4 : ffffffff80b80ec0 ffffffff80b53d48 0000000000000000 00000000000f4240 [ 0.000000] $ 8 : 0000000000000100 ffffffff81d82f80 ffffffff81d82f80 0000000000000001 [ 0.000000] $12 : 0000000000000000 ffffffff81776f58 00000000000005da 0000000000000002 [ 0.000000] $16 : ffffffff80b80e40 0000000000000000 ffffffff80b81614 9800000005dfbe80 [ 0.000000] $20 : 00000000540000e0 ffffffff81980000 0000000000000000 ffffffff80f81c80 [ 0.000000] $24 : 0000000000000a26 ffffffff8114fb90 [ 0.000000] $28 : ffffffff80b50000 ffffffff80b53d40 0000000000000000 ffffffff81afad90 [ 0.000000] Hi : 0000000000000000 [ 0.000000] Lo : 0000000000000000 [ 0.000000] epc : ffffffff81afada8 init_idle+0x130/0x270 [ 0.000000] ra : ffffffff81afad90 init_idle+0x118/0x270 [ 0.000000] Status: 540000e2\tKX SX UX KERNEL EXL [ 0.000000] Cause : 00000008 (ExcCode 02) [ 0.000000] BadVA : 0000000000000000 [ 0.000000] PrId : 00006305 (ICT Loongson-3) [ 0.000000] Process swapper (pid: 0, threadinfo=(____ptrval____), task=(____ptrval____), tls=0000000000000000) [ 0.000000] Stack : 9800000005dfbf00 ffffffff8178e950 0000000000000000 0000000000000000 [ 0.000000] 0000000000000000 ffffffff81970000 000000000000003f ffffffff810a6528 [ 0.000000] 0000000000000001 9800000005dfbe80 9800000005dfbf00 ffffffff81980000 [ 0.000000] ffffffff810a6450 ffffffff81afb6c0 0000000000000000 ffffffff810a2258 [ 0.000000] ffffffff81d82ec8 ffffffff8198d010 ffffffff81b67e80 ffffffff8197dd98 [ 0.000000] ffffffff81d81c80 ffffffff81930000 0000000000000040 0000000000000000 [ 0.000000] 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 0.000000] 0000000000000000 000000000000009e ffffffff9fc01000 0000000000000000 [ 0.000000] 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 0.000000] 0000000000000000 ffffffff81ae86dc ffffffff81b3c741 0000000000000002 [ 0.000000] ... [ 0.000000] Call Trace: [ 0.000000] [\u0026lt;ffffffff81afada8\u0026gt;] init_idle+0x130/0x270 [ 0.000000] [\u0026lt;ffffffff81afb6c0\u0026gt;] sched_init+0x5c8/0x6c0 [ 0.000000] [\u0026lt;ffffffff81ae86dc\u0026gt;] start_kernel+0x27c/0x7a8 This bug has been reported to LLVM[2] and affects version from (at least) 18 to 21. Let\u0026apos;s work around this by using inline assembly to assign $gp before a fix is widely available. The Linux kernel CVE team has assigned CVE-2026-46250 to this issue.(CVE-2026-46250)\n\nIn the Linux kernel, the following vulnerability has been resolved: pstore/ram: fix buffer overflow in persistent_ram_save_old() persistent_ram_save_old() can be called multiple times for the same persistent_ram_zone (e.g., via ramoops_pstore_read -\u0026gt; ramoops_get_next_prz for PSTORE_TYPE_DMESG records). Currently, the function only allocates prz-\u0026gt;old_log when it is NULL, but it unconditionally updates prz-\u0026gt;old_log_size to the current buffer size and then performs memcpy_fromio() using this new size. If the buffer size has grown since the first allocation (which can happen across different kernel boot cycles), this leads to: 1. A heap buffer overflow (OOB write) in the memcpy_fromio() calls 2. A subsequent OOB read when ramoops_pstore_read() accesses the buffer using the incorrect (larger) old_log_size The KASAN splat would look similar to: BUG: KASAN: slab-out-of-bounds in ramoops_pstore_read+0x... Read of size N at addr ... by task ... The conditions are likely extremely hard to hit: 0. Crash with a ramoops write of less-than-record-max-size bytes. 1. Reboot: ramoops registers, pstore_get_records(0) reads old crash, allocates old_log with size X 2. Crash handler registered, timer started (if pstore_update_ms \u0026gt;= 0) 3. Oops happens (non-fatal, system continues) 4. pstore_dump() writes oops via ramoops_pstore_write() size Y (\u0026gt;X) 5. pstore_new_entry = 1, pstore_timer_kick() called 6. System continues running (not a panic oops) 7. Timer fires after pstore_update_ms milliseconds 8. pstore_timefunc() \u2192 schedule_work() \u2192 pstore_dowork() \u2192 pstore_get_records(1) 9. ramoops_get_next_prz() \u2192 persistent_ram_save_old() 10. buffer_size() returns Y, but old_log is X bytes 11. Y \u0026gt; X: memcpy_fromio() overflows heap Requirements: - a prior crash record exists that did not fill the record size (almost impossible since the crash handler writes as much as it can possibly fit into the record, capped by max record size and the kmsg buffer almost always exceeds the max record size) - pstore_update_ms \u0026gt;= 0 (disabled by default) - Non-fatal oops (system survives) Free and reallocate the buffer when the new size differs from the previously allocated size. This ensures old_log always has sufficient space for the data being copied. The Linux kernel CVE team has assigned CVE-2026-46253 to this issue.(CVE-2026-46253)\n\nIn the Linux kernel, the following vulnerability has been resolved: procfs: fix missing RCU protection when reading real_parent in do_task_stat() When reading /proc/[pid]/stat, do_task_stat() accesses task-\u0026gt;real_parent without proper RCU protection, which leads to: cpu 0 cpu 1 ----- ----- do_task_stat var = task-\u0026gt;real_parent release_task call_rcu(delayed_put_task_struct) task_tgid_nr_ns(var) rcu_read_lock \u0026lt;--- Too late to protect task-\u0026gt;real_parent! task_pid_ptr \u0026lt;--- UAF! rcu_read_unlock This patch uses task_ppid_nr_ns() instead of task_tgid_nr_ns() to add proper RCU protection for accessing task-\u0026gt;real_parent. The Linux kernel CVE team has assigned CVE-2026-46259 to this issue.(CVE-2026-46259)\n\nIn the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix WQ_MEM_RECLAIM warning When sunrpc is used, if a reset triggered, our wq may lead the following trace: workqueue: WQ_MEM_RECLAIM xprtiod:xprt_rdma_connect_worker [rpcrdma] is flushing !WQ_MEM_RECLAIM hns_roce_irq_workq:flush_work_handle [hns_roce_hw_v2] WARNING: CPU: 0 PID: 8250 at kernel/workqueue.c:2644 check_flush_dependency+0xe0/0x144 Call trace: check_flush_dependency+0xe0/0x144 start_flush_work.constprop.0+0x1d0/0x2f0 __flush_work.isra.0+0x40/0xb0 flush_work+0x14/0x30 hns_roce_v2_destroy_qp+0xac/0x1e0 [hns_roce_hw_v2] ib_destroy_qp_user+0x9c/0x2b4 rdma_destroy_qp+0x34/0xb0 rpcrdma_ep_destroy+0x28/0xcc [rpcrdma] rpcrdma_ep_put+0x74/0xb4 [rpcrdma] rpcrdma_xprt_disconnect+0x1d8/0x260 [rpcrdma] xprt_rdma_connect_worker+0xc0/0x120 [rpcrdma] process_one_work+0x1cc/0x4d0 worker_thread+0x154/0x414 kthread+0x104/0x144 ret_from_fork+0x10/0x18 Since QP destruction frees memory, this wq should have the WQ_MEM_RECLAIM. The Linux kernel CVE team has assigned CVE-2026-46265 to this issue.(CVE-2026-46265)",
"id": "OESA-2026-2674",
"modified": "2026-08-06T11:11:36Z",
"published": "2026-06-12T11:11:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-2674"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39759"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39952"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68330"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68755"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71184"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31605"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31607"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31615"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31616"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31617"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31618"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31700"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31786"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43077"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43078"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43091"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43093"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43116"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43125"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43130"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43139"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43190"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43198"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43233"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43253"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43319"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43339"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43383"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43450"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43452"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43453"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43499"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45840"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45843"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45852"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45862"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45894"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45905"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45914"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45915"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45919"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45920"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45935"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45944"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45948"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45983"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45985"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45987"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45991"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46018"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46023"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46028"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46032"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46043"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46049"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46056"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46065"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46083"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46088"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46101"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46102"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46107"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46116"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46132"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46172"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46178"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46184"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46209"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46243"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46250"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46253"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46259"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46265"
}
],
"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-2025-39759",
"CVE-2025-39952",
"CVE-2025-68330",
"CVE-2025-68755",
"CVE-2025-71184",
"CVE-2026-31605",
"CVE-2026-31607",
"CVE-2026-31615",
"CVE-2026-31616",
"CVE-2026-31617",
"CVE-2026-31618",
"CVE-2026-31700",
"CVE-2026-31786",
"CVE-2026-43077",
"CVE-2026-43078",
"CVE-2026-43091",
"CVE-2026-43093",
"CVE-2026-43116",
"CVE-2026-43125",
"CVE-2026-43130",
"CVE-2026-43139",
"CVE-2026-43190",
"CVE-2026-43198",
"CVE-2026-43233",
"CVE-2026-43253",
"CVE-2026-43319",
"CVE-2026-43339",
"CVE-2026-43383",
"CVE-2026-43450",
"CVE-2026-43452",
"CVE-2026-43453",
"CVE-2026-43499",
"CVE-2026-45840",
"CVE-2026-45843",
"CVE-2026-45852",
"CVE-2026-45862",
"CVE-2026-45894",
"CVE-2026-45905",
"CVE-2026-45914",
"CVE-2026-45915",
"CVE-2026-45919",
"CVE-2026-45920",
"CVE-2026-45935",
"CVE-2026-45944",
"CVE-2026-45948",
"CVE-2026-45983",
"CVE-2026-45985",
"CVE-2026-45987",
"CVE-2026-45991",
"CVE-2026-46018",
"CVE-2026-46023",
"CVE-2026-46028",
"CVE-2026-46032",
"CVE-2026-46043",
"CVE-2026-46049",
"CVE-2026-46056",
"CVE-2026-46065",
"CVE-2026-46083",
"CVE-2026-46088",
"CVE-2026-46101",
"CVE-2026-46102",
"CVE-2026-46107",
"CVE-2026-46116",
"CVE-2026-46132",
"CVE-2026-46172",
"CVE-2026-46178",
"CVE-2026-46184",
"CVE-2026-46209",
"CVE-2026-46243",
"CVE-2026-46250",
"CVE-2026-46253",
"CVE-2026-46259",
"CVE-2026-46265"
]
}
OESA-2026-3703 (CVE-2025-37979)
Vulnerability from osv_openeuler – Published: 2026-09-05 15:04 – Updated: 2026-09-05 15:04 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
ASoC: qcom: Fix sc7280 lpass potential buffer overflow
Case values introduced in commit 5f78e1fb7a3e ("ASoC: qcom: Add driver support for audioreach solution") cause out of bounds access in arrays of sc7280 driver data (e.g. in case of RX_CODEC_DMA_RX_0 in sc7280_snd_hw_params()).
Redefine LPASS_MAX_PORTS to consider the maximum possible port id for q6dsp as sc7280 driver utilizes some of those values.
Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-37979)
In the Linux kernel, the following vulnerability has been resolved:
net: usb: asix_devices: Fix PHY address mask in MDIO bus initialization
Syzbot reported shift-out-of-bounds exception on MDIO bus initialization.
The PHY address should be masked to 5 bits (0-31). Without this mask, invalid PHY addresses could be used, potentially causing issues with MDIO bus operations.
Fix this by masking the PHY address with 0x1f (31 decimal) to ensure it stays within the valid range.(CVE-2025-38736)
In the Linux kernel, the following vulnerability has been resolved:
crypto: af_alg - Fix page reassignment overflow in af_alg_pull_tsgl
When page reassignment was added to af_alg_pull_tsgl the original loop wasn't updated so it may try to reassign one more page than necessary.
Add the check to the reassignment so that this does not happen.
Also update the comment which still refers to the obsolete offset argument.(CVE-2026-43078)
In the Linux kernel, the following vulnerability has been resolved:
crypto: algif_aead - snapshot IV for async AEAD requests
AF_ALG AEAD AIO requests currently use the socket-wide IV buffer during request processing. For async requests, later socket activity can update that shared state before the original request has fully completed, which can lead to inconsistent IV handling.
Snapshot the IV into per-request storage when preparing the AEAD request, so in-flight operations no longer depend on mutable socket state.(CVE-2026-46028)
In the Linux kernel, the following vulnerability has been resolved:
xfrm: esp: restore combined single-frag length gate
The ESP out-of-place fast path appends the trailer in esp_output_head() before esp_output_tail() allocates the destination page frag. The head-side gate currently checks skb->data_len and tailen separately, but the tail code allocates a single destination frag from the combined post-trailer skb->data_len.
Reject the page-frag fast path when the combined aligned length exceeds a page. Otherwise skb_page_frag_refill() may fall back to a single page while the destination sg still spans the combined skb->data_len.
Restore this combined-length page gate for both IPv4 and IPv6.(CVE-2026-63912)
In the Linux kernel, the following vulnerability has been resolved: ipvs: reload ip header after head reallocation. __ip_vs_get_out_rt() calls skb_ensure_writable() which may reallocate skb->head, causing the previously obtained IP header pointer to become a dangling pointer, leading to a use-after-free vulnerability.(CVE-2026-68476)
In the Linux kernel, the following vulnerability has been resolved:
ipvs: fix more places with wrong ipv6 transport offsets
Sashiko reports for more incorrect IPv6 transport offsets.
The app code for TCP was assuming IPv4 network header even after the ipvsh argument was provided. This can cause problems with apps over IPv6. As for the only official app in the kernel tree (FTP) this problem is harmless because we use Netfilter to mangle the FTP ports and we do not adjust the TCP seq numbers.
Also, provide correct offset of the ICMPV6 header in ip_vs_out_icmp_v6() for correct checksum checks when the IPv6 packet has extension headers.(CVE-2026-68477)
In the Linux kernel, the following vulnerability has been resolved:
ipvs: use parsed transport offset in SCTP state lookup
set_sctp_state() reads the SCTP chunk header again in order to drive the IPVS SCTP state table. For IPv6 it computes the offset with sizeof(struct ipv6hdr), while the surrounding IPVS code uses iph.len from ip_vs_fill_iph_skb(), where ipv6_find_hdr() has already skipped extension headers and found the real transport header.
This makes the state machine read from the wrong offset for IPv6 SCTP packets that carry extension headers. For example, an INIT packet with an 8-byte destination options header can be scheduled correctly by sctp_conn_schedule(), but set_sctp_state() reads the first byte of the SCTP verification tag as a DATA chunk type. The connection then moves from NONE to ESTABLISHED instead of INIT1, gets the longer established timeout, and updates the active/inactive destination counters incorrectly. This happens even though the SCTP handshake has not completed.
Use the parsed transport offset passed down from ip_vs_set_state() for the SCTP chunk-header lookup. For IPv4 and IPv6 packets without extension headers this preserves the existing offset.(CVE-2026-72021)
In the Linux kernel, the following vulnerability has been resolved:
ieee802154: admin-gate legacy LLSEC dump operations
In net/ieee802154/netlink.c, the legacy IEEE802154_NL family ops table builds the LLSEC dump entries (LLSEC_LIST_KEY, LLSEC_LIST_DEV, LLSEC_LIST_DEVKEY, LLSEC_LIST_SECLEVEL) with IEEE802154_DUMP() which sets no .flags, so generic netlink runs them ungated. The modern nl802154 family admin-gates the equivalent reads via NL802154_CMD_GET_SEC_KEY and friends with .flags = GENL_ADMIN_PERM.
Any local uid that can open AF_NETLINK / NETLINK_GENERIC can resolve the "802.15.4 MAC" family and dump LLSEC_LIST_KEY on any wpan netdev that has an LLSEC key installed; the dump handler writes the raw 16-byte AES-128 key bytes (IEEE802154_ATTR_LLSEC_KEY_BYTES, copied verbatim from struct ieee802154_llsec_key.key) into the reply. Recovering the AES key compromises 802.15.4 LLSEC link confidentiality and authenticity, since LLSEC uses CCM* and the same key authenticates and encrypts frames.
Impact: any local uid with no capabilities can read the raw 16-byte AES-128 LLSEC key from the kernel keytable on any wpan netdev that has an administrator-installed LLSEC key, by issuing an LLSEC_LIST_KEY dump on the legacy IEEE802154_NL generic-netlink family.
Introduce IEEE802154_DUMP_PRIV() mirroring IEEE802154_DUMP() but setting .flags = GENL_ADMIN_PERM, and use it for the four LLSEC dump entries. LIST_PHY and LIST_IFACE retain IEEE802154_DUMP() because the modern nl802154 family exposes their equivalents to unprivileged readers by design (NL802154_CMD_GET_WPAN_PHY and NL802154_CMD_GET_INTERFACE carry "can be retrieved by unprivileged users" annotations).(CVE-2026-72049)
In the Linux kernel, the following vulnerability has been resolved:
net: ip6_gre: require CAP_NET_ADMIN in the device netns for changelink
ip6gre_changelink() and ip6erspan_changelink() operate on at most two netns, dev_net(dev) and the tunnel link netns t->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in t->net can rewrite a tunnel that lives in t->net.
Gate both ops on rtnl_dev_link_net_capable() at their top, before any attribute is parsed.(CVE-2026-72052)
In the Linux kernel, the following vulnerability has been resolved:
net: ipip: require CAP_NET_ADMIN in the device netns for changelink
ipip_changelink() operates on at most two netns, dev_net(dev) and the tunnel link netns t->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in t->net can rewrite a tunnel that lives in t->net.
Gate ipip_changelink() on rtnl_dev_link_net_capable() at its top, before any attribute is parsed.(CVE-2026-72053)
In the Linux kernel, the following vulnerability has been resolved:
net: ip_vti: require CAP_NET_ADMIN in the device netns for changelink
vti_changelink() operates on at most two netns, dev_net(dev) and the tunnel link netns t->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in t->net can rewrite a tunnel that lives in t->net.
Gate vti_changelink() on rtnl_dev_link_net_capable() at its top, before any attribute is parsed.(CVE-2026-72054)
In the Linux kernel, the following vulnerability has been resolved:
net: sit: require CAP_NET_ADMIN in the device netns for changelink
ipip6_changelink() operates on at most two netns, dev_net(dev) and the tunnel link netns t->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in t->net can rewrite a tunnel that lives in t->net.
Gate ipip6_changelink() on rtnl_dev_link_net_capable() at its top, before any attribute is parsed. sit was the one tunnel type not covered by the recent series that added this check to the other changelink() handlers.(CVE-2026-72061)
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: macsec: fix use-after-free of metadata_dst on RX SC delete
When an offloaded MACsec RX SC is deleted, macsec_del_rxsc_ctx() freed the per-SC metadata_dst with metadata_dst_free(), which kfree()s the object unconditionally and ignores the dst reference count. The RX datapath in mlx5e_macsec_offload_handle_rx_skb() looks up the SC under rcu_read_lock() via xa_load(), takes a reference with dst_hold() and attaches the dst to the skb with skb_dst_set(). A reader that already obtained the rx_sc pointer can race with the delete path and operate on freed memory.
Fix the owner side by dropping the reference with dst_release() instead of freeing unconditionally, and convert the RX datapath to dst_hold_safe() so a reader racing the SC delete cannot attach a dst whose last reference was just dropped; only attach it when a reference was actually taken.
mlx5e_macsec_add_rxsc() also published sc_xarray_element via xa_alloc() before rx_sc->md_dst was allocated and initialised, so a datapath reader that looked the SC up by fs_id could observe rx_sc with md_dst still NULL or, on weakly-ordered architectures, a non-NULL md_dst pointer whose contents were not yet visible. NULL-check the xa_load() result and md_dst on the datapath, and reorder add_rxsc() so the xa_alloc() publish happens only after md_dst is fully initialised; the xarray RCU publish then pairs with the rcu_read_lock()/xa_load() in the datapath.
Note: macsec_del_rxsc_ctx() also kfree()s rx_sc->sc_xarray_element without an RCU grace period while the same datapath reads it under rcu_read_lock(); that is a separate pre-existing issue left to a follow-up patch.
Found by 0sec automated security-research tooling (https://0sec.ai).(CVE-2026-72072)
In the Linux kernel, the following vulnerability has been resolved:
nvmet-rdma: handle inline data with a nonzero offset
nvmet_rdma_use_inline_sg() maps the host-controlled inline data offset into the per-command inline scatterlist. The bounds check admits any offset with off + len <= inline_data_size, but the mapping still assumes the data begins in the first inline page:
sg->offset = off;
sg->length = min_t(int, len, PAGE_SIZE - off);
When a port is configured with inline_data_size > PAGE_SIZE (settable up to max(SZ_16K, PAGE_SIZE)), an offset in (PAGE_SIZE, inline_data_size] makes "PAGE_SIZE - off" underflow, so sg->length is set to ~4 GiB and the block backend reads far past the first inline page. num_pages(len) also ignores the offset, so an in-bounds offset whose [off, off+len) span crosses a page boundary under-counts the scatterlist.
Map the offset properly: split it into a page index and an in-page offset, start the scatterlist at that page, and size the page count from page_off + len. Because the request scatterlist may now start at inline_sg[page_idx] rather than inline_sg[0], generalize the inline-SGL identity test in nvmet_rdma_release_rsp() to a range test; otherwise the persistent inline scatterlist is mistaken for an allocated one and nvmet_req_free_sgls() frees an inline page (and warns in free_large_kmalloc()).(CVE-2026-72129)
In the Linux kernel, the following vulnerability has been resolved:
tpm: Make the TPM character devices non-seekable
The TPM character devices expose a sequential command/response interface, but their open handlers leave FMODE_PREAD and FMODE_PWRITE enabled.
After a command leaves a response pending, pread(fd, buf, 16, 0x1400) passes 0x1400 as off to tpm_common_read(). The transfer length is bounded by response_length, but the offset is used unchecked when forming data_buffer + off. A sufficiently large offset therefore causes an out-of-bounds heap read through copy_to_user() and, if the copy succeeds, an out-of-bounds zero-write through the following memset().
Positional I/O does not provide coherent semantics for this interface. An arbitrary pread offset cannot represent how much of a response has been consumed sequentially. The write callback always stores a command at the start of data_buffer, while pwrite() does not update file->f_pos and can leave the sequential read cursor stale.
Call nonseekable_open() from both open handlers. This removes FMODE_PREAD and FMODE_PWRITE, causing positional reads and writes to fail with -ESPIPE before reaching the TPM callbacks, and explicitly marks the files non-seekable. Normal read() and write() continue to use the existing sequential f_pos cursor, leaving the response state machine unchanged.
Tested on Linux 6.12 with KASAN and a swtpm TPM2 device:
- sequential partial reads returned the complete response
- pread() and preadv() with offset 0x1400 returned -ESPIPE
- pwrite() and pwritev() with offset zero returned -ESPIPE
- the pending response remained intact after the rejected operations
- a subsequent normal command/response cycle completed normally
- no KASAN report was produced.(CVE-2026-72135)
In the Linux kernel, the following vulnerability has been resolved:
xfrm: xfrm_interface: require CAP_NET_ADMIN in the device netns for changelink
xfrmi_changelink() operates on at most two netns, dev_net(dev) and the interface link netns xi->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in xi->net can rewrite an interface that lives in xi->net.
Gate xfrmi_changelink() on rtnl_dev_link_net_capable() at its top, before any attribute is parsed.(CVE-2026-72136)
In the Linux kernel, the following vulnerability has been resolved: net: thunderbolt: Fix frags[] overflow by bounding frame_count. tbnet_poll() assembles a multi-frame ThunderboltIP packet into one skb. The first frame goes into the skb linear area and every further frame is added as a page fragment. A packet of frame_count frames therefore ends up with frame_count - 1 fragments. tbnet_check_frame() only bounds the peer supplied frame_count to TBNET_RING_SIZE / 4 (64), which is far above MAX_SKB_FRAGS (17 by default). A peer that sends a packet of 19 or more small frames pushes nr_frags past MAX_SKB_FRAGS, so skb_add_rx_frag() writes past skb_shinfo()->frags[] and corrupts memory after the shared info.(CVE-2026-72157)
In the Linux kernel, the following vulnerability has been resolved: mm/mm_init: fix uninitialized struct pages for ZONE_DEVICE. If DAX memory is hotplugged into an unoccupied subsection of an early section, section_activate() reuses the unoptimized boot memmap. However, compound_nr_pages() still assumes that vmemmap optimization is in effect and initializes only the reduced number of struct pages. As a result, the remaining tail struct pages are left uninitialized, which can later lead to unexpected behavior or crashes. Fix this by treating early sections as unoptimized when calculating how many struct pages to initialize.(CVE-2026-72172)
In the Linux kernel, the following vulnerability has been resolved:
SUNRPC: Bound-check xdr_buf_to_bvec() stores before writing
xdr_buf_to_bvec() writes a bio_vec into the caller's array before testing whether that slot is in range, and the head branch performs the store with no check at all. When the caller's budget is exactly used up, the next store lands one element past the end of the array. The overflow label returns count - 1, which masks the surplus store but cannot undo it.
rq_bvec, the array passed by nfsd_vfs_write(), is allocated to exactly rq_maxpages entries with no slack. The OOB store can land in adjacent slab memory; the bv_len and bv_offset fields written there are derived from client-supplied RPC payload sizes.
Move the in-range check ahead of the store in the head, page-loop, and tail branches. With the check at the top of each sequence, count is incremented only after a successful store, so the overflow label can return count directly.(CVE-2026-72217)
In the Linux kernel, the following vulnerability has been resolved:
sunrpc: wait for in-flight TLS handshake callback when cancel loses race
When wait_for_completion_interruptible_timeout() in svc_tcp_handshake() returns 0 (timeout) or -ERESTARTSYS (signal) and tls_handshake_cancel() then returns false, handshake_complete() has won the cancellation race: it has set HANDSHAKE_F_REQ_COMPLETED and is about to invoke svc_tcp_handshake_done(), but the callback's side effects on xpt_flags and on svsk->sk_handshake_done have not yet committed.
The current code reads xpt_flags immediately to decide whether the session succeeded. Two races result.
If the callback has executed set_bit(XPT_TLS_SESSION) but not yet clear_bit(XPT_HANDSHAKE), svc_tcp_handshake() sees a session, enqueues the transport, and returns. svc_xprt_received() then clears XPT_BUSY, a worker thread picks the transport up, the dispatcher in svc_handle_xprt() observes XPT_HANDSHAKE still set, and xpo_handshake is invoked a second time. That svc_tcp_handshake() calls init_completion(&svsk->sk_handshake_done) while the original callback concurrently calls complete_all() on it, corrupting the embedded swait_queue.
If the callback has set HANDSHAKE_F_REQ_COMPLETED but not yet entered svc_tcp_handshake_done(), svc_tcp_handshake() reads XPT_TLS_SESSION as clear and tears the connection down even though the handshake is about to succeed.
Wait for the callback to commit before inspecting xpt_flags. The completion is guaranteed to fire because handshake_complete() invokes svc_tcp_handshake_done() unconditionally once it has set HANDSHAKE_F_REQ_COMPLETED.(CVE-2026-72221)
In the Linux kernel, the following vulnerability has been resolved:
sunrpc: pin svc_xprt across the asynchronous TLS handshake callback
svc_tcp_handshake() stores the raw svc_xprt pointer in tls_handshake_args.ta_data and submits the request through tls_server_hello_x509(). The handshake core takes only sock_hold(req->hr_sk); nothing references the embedding struct svc_sock that svc_tcp_handshake_done() reaches via container_of().
Two close races leave the in-flight callback writing through a freed svc_sock. svc_sock_free() calls tls_handshake_cancel() and discards its return value: a false return means handshake_complete() has already set HANDSHAKE_F_REQ_COMPLETED but hp_done() may not have finished, yet svc_sock_free() proceeds to kfree(svsk). The cancel-loser fall-through inside svc_tcp_handshake() itself produces the same window: when wait_for_completion_interruptible_timeout() returns <= 0 (timeout or signal) and tls_handshake_cancel() returns false, the function does not drain, returns, and svc_handle_xprt() calls svc_xprt_received(), which clears XPT_BUSY and can drop the last reference. A concurrent close then runs svc_sock_free() while svc_tcp_handshake_done() is still updating xpt_flags and walking svsk->sk_handshake_done.
The corruption surfaces as set_bit/clear_bit RMW into the freed xpt_flags slab slot and as complete_all() walking and writing the freed wait_queue_head_t list embedded in sk_handshake_done -- a slab-corruption primitive, not a benign read. The path is reachable on any TLS-enabled NFS server whenever a connection close overlaps the tlshd downcall delivery window; the interruptible wait means signal delivery suffices, not just SVC_HANDSHAKE_TO expiry.
Take svc_xprt_get(xprt) immediately before tls_server_hello_x509() so the in-flight callback owns its own reference. Release it on the two edges where the callback is guaranteed not to fire -- submission failure from tls_server_hello_x509() and a successful tls_handshake_cancel() -- and at the tail of svc_tcp_handshake_done() after complete_all().
cel: rewrote commit message to describe the actual change
In the Linux kernel, the following vulnerability has been resolved:
batman-adv: retrieve ethhdr after potential skb realloc on RX
pskb_may_pull() in batadv_interface_rx() could reallocate the buffer behind the skb. Variables which were pointing to the old buffer need to be reassigned to avoid an use-after-free.
This was done correctly for the VLAN header but missed for the ethernet header which is later used for the TT and AP isolation handling.(CVE-2026-72235)
In the Linux kernel, the following vulnerability has been resolved:
KVM: Move kvm_io_bus_get_dev() locking responsibilities to callers
kvm_io_bus_get_dev() returns a device that is only matched by the address, and nothing else. This can cause a lifetime issue if the matched device is not the expected type, as by the time the caller can introspect the object, it might be gone (the srcu lock having been dropped).
Given that there is only a single user of this helper, the simplest option is to move the locking responsibility to the caller, which can keep the srcu lock held for as long as it wants.
Note that this aligns with other kvm_io_bus*() helpers, which already require the srcu lock to be held by the callers.(CVE-2026-72282)
In the Linux kernel, the following vulnerability has been resolved: smb: client: fix overflow in passthrough ioctl bounds check. smb2_ioctl_query_info() validates the PASSTHRU_FSCTL response payload before copying it to userspace. The payload offset and length both come from 32-bit fields. The bounds check currently adds OutputOffset and qi.input_buffer_length directly, so the addition can wrap in 32-bit arithmetic before the result is compared against the response buffer length. A malicious server can use a large OutputOffset and a small OutputCount to make the wrapped sum pass the bounds check. The later copy_to_user() then reads from io_rsp + OutputOffset, outside the response buffer, leading to an out-of-bounds read.(CVE-2026-72310)
In the Linux kernel, the following vulnerability has been resolved:
dm era: fix NULL pointer dereference in metadata_open()
metadata_open() returns NULL when kzalloc_obj() fails, but the caller era_ctr() only checks IS_ERR(md). Since IS_ERR(NULL) returns false, the NULL pointer is treated as a valid result and later assigned to era->md, leading to a NULL pointer dereference when the metadata is accessed.
Fix this by returning ERR_PTR(-ENOMEM) on allocation failure, consistent with dm-cache-metadata.c, dm-thin-metadata.c, and dm-clone-metadata.c which all use ERR_PTR(-ENOMEM) for the same pattern.(CVE-2026-72316)
In the Linux kernel, the following vulnerability has been resolved:
SUNRPC: pin upper rpc_clnt across the TLS connect_worker
The TLS connect path has a use-after-free: nothing pins the upper rpc_clnt across the delayed connect_worker. xs_connect() stores task->tk_client in sock_xprt::clnt as a raw pointer and queues the worker; for TLS-secured transports that worker is xs_tcp_tls_setup_socket(), which reads several fields out of the saved pointer (cl_timeout, cl_program, cl_prog, cl_vers, cl_cred, cl_stats) to construct the args for the inner handshake rpc_clnt.
The xprt does not reference the rpc_clnt; the rpc_clnt references the xprt. xs_destroy() does cancel the connect_worker, but it runs only when the xprt's refcount drops to zero, which cannot happen until the rpc_clnt releases its cl_xprt reference in rpc_free_client_work(). When a TLS handshake fails fatally (for example, an mTLS mount whose client cert does not match the server), the connecting task is woken with -EACCES and exits, the mount caller invokes rpc_shutdown_client(), and the upper rpc_clnt is freed before the queued connect_worker fires. xs_tcp_tls_setup_socket() then dereferences the freed clnt, producing the refcount_t underflow Michael Nemanov reported.
Take a reference on the upper rpc_clnt in xs_connect() for TLS transports via a new rpc_hold_client() helper, and drop it in the connect_worker's exit path with rpc_release_client(). The xprt_lock_connect() / xprt_unlock_connect() pairing already serialises xs_connect() with xs_tcp_tls_setup_socket(), so the take and release are balanced one-for-one.
The non-TLS connect worker (xs_tcp_setup_socket) never reads sock_xprt::clnt, so leave that path alone and avoid the clnt-holds-xprt-holds-clnt cycle that would otherwise prevent xprt destruction.(CVE-2026-72317)
In the Linux kernel, the following vulnerability has been resolved:
cifs: validate DFS referral string offsets
parse_dfs_referrals() validates that the response header and referral array fit in the received buffer, but each referral also contains string offsets supplied by the server.
Those offsets are used to compute the DfsPath and NetworkAddress string pointers without checking whether they still point inside the response buffer. A malformed referral can therefore make the computed pointer exceed the end of the buffer. The resulting negative max_len is then passed to cifs_strndup_from_utf16(), and the non-Unicode path forwards it to kstrndup() as a size_t, allowing strnlen() to read out of bounds.
Validate each string offset before deriving the string pointer.(CVE-2026-72318)
In the Linux kernel, the following vulnerability has been resolved:
ipvs: ensure inner headers in ICMP errors are in headroom
Sashiko points out that after stripping the outer headers with pskb_pull() we should ensure the inner IP headers in ICMP errors from tunnels are present in the skb headroom for functions like ipv4_update_pmtu(), icmp_send() and IP_VS_DBG().
Also, add more checks for the length of the inner headers.(CVE-2026-72319)
In the Linux kernel, the following vulnerability has been resolved:
net/tls: Consume empty data records in tls_sw_read_sock()
A peer may send a zero-length TLS application_data record; TLS 1.3 explicitly permits these as a traffic-analysis countermeasure (RFC 8446, Section 5.1). After decryption such a record has full_len == 0. tls_sw_read_sock() hands it to the read_actor, which has no payload to consume and returns zero. The loop treats a zero return as backpressure (used <= 0), requeues the skb at the head of rx_list, and stops. rx_list is serviced head-first on the next call, so the empty record is dequeued, fails the same way, and is requeued again; every later record on the connection is blocked behind it.
tls_sw_recvmsg() does not stall on this: a zero-length data record copies nothing and falls through to consume_skb(). Mirror that in the read_sock() path by recognizing an empty data record before the actor runs, consuming it, and continuing.(CVE-2026-72330)
In the Linux kernel, the following vulnerability has been resolved:
qede: fix off-by-one in BD ring consumption on build_skb failure
qede_rx_build_skb() and qede_tpa_rx_build_skb() do not check for a NULL return from qede_build_skb(). When it returns NULL under memory pressure, the functions still consume a BD from the ring before returning NULL. The callers then recycle additional BDs, resulting in one extra BD being consumed (off-by-one). This desynchronizes the BD ring, which can corrupt DMA page reference counts and lead to SLUB freelist corruption.
Commit 4e910dbe3650 ("qede: confirm skb is allocated before using") added a NULL check inside qede_build_skb() to prevent a NULL pointer dereference, but did not address the missing NULL checks in the callers, making this off-by-one reachable.
Fix this by adding NULL checks for the return value of qede_build_skb() in both qede_rx_build_skb() and qede_tpa_rx_build_skb(), returning NULL immediately before any BD ring manipulation.(CVE-2026-72339)
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Fix HV VHCA stats agent registration race
mlx5e_hv_vhca_stats_create() registers the stats agent through mlx5_hv_vhca_agent_create(). The helper publishes the agent in hv_vhca->agents[type] under agents_lock and immediately schedules an asynchronous control invalidation on the HV VHCA workqueue before returning to mlx5e.
The asynchronous invalidation invokes the control agent's invalidate callback, which reads the hypervisor control block and forwards the command to mlx5e_hv_vhca_stats_control(). That callback may either:
- call cancel_delayed_work_sync(&priv->stats_agent.work), or
- call queue_delayed_work(priv->wq, &sagent->work, sagent->delay).
However, the delayed_work and priv->stats_agent.agent are only initialized after mlx5_hv_vhca_agent_create() returns to mlx5e:
agent = mlx5_hv_vhca_agent_create(...); /* publish + invalidate */
...
priv->stats_agent.agent = agent; /* too late */
INIT_DELAYED_WORK(&priv->stats_agent.work, ...); /* too late */
If the asynchronous control path runs before the two assignments above, it can:
- Operate on an uninitialized delayed_work whose timer.function is NULL. queue_delayed_work() calls add_timer() unconditionally, so when the timer expires the timer softirq invokes a NULL function pointer.
- Re-initialize the timer later through INIT_DELAYED_WORK() while the timer is already enqueued in the timer wheel, corrupting the hlist (entry.pprev cleared while the previous bucket node still points at this entry).
- When the worker eventually runs, mlx5e_hv_vhca_stats_work() reads sagent->agent (NULL) and dereferences it inside mlx5_hv_vhca_agent_write().
Fix this by:
- Initializing priv->stats_agent.work before invoking mlx5_hv_vhca_agent_create(), so the work is always in a valid state when the control callback observes it.
- Adding a struct mlx5_hv_vhca_agent *ctx_update out-parameter to mlx5_hv_vhca_agent_create(). The helper writes the agent pointer to ctx_update before publishing into hv_vhca->agents[] and triggering the agents_update flow, so any callback subsequently invoked from that flow already sees a valid priv->stats_agent.agent. This avoids having the control callback participate in agent initialization.
While at it, access priv->stats_agent.agent with READ_ONCE()/WRITE_ONCE() for the cross-CPU access with the worker, and clear priv->stats_agent.buf on the agent_create() failure path.(CVE-2026-72342)
In the Linux kernel, the following vulnerability has been resolved:
bridge: stp: Fix a potential use-after-free when deleting a bridge
The three STP timers are not supposed to be armed while the bridge is administratively down. They are synchronously deactivated when the bridge is put administratively down and the various call sites check for 'IFF_UP' before arming them.
This check is missing from br_topology_change_detection() and it is possible to engineer a situation in which the topology change timer is armed while the bridge is administratively down, resulting in a use-after-free [1] when the bridge is deleted.
Fix by adding the missing check and for good measures synchronously shutdown the three timers when the bridge is deleted.
[1] ODEBUG: free active (active state 0) object: ffff88811662b9b0 object type: timer_list hint: br_topology_change_timer_expired (net/bridge/br_stp_timer.c:120) WARNING: lib/debugobjects.c:629 at debug_print_object+0x1bc/0x450, CPU#9: ip/359(CVE-2026-72389)
In the Linux kernel, the following vulnerability has been resolved:
seg6: validate SRH length before reading fixed fields
seg6_validate_srh() reads fixed SRH fields such as srh->type and srh->hdrlen before checking that the supplied length covers the fixed struct ipv6_sr_hdr fields.
The BPF SEG6 encap path reaches this with a BPF program-supplied pointer and length: bpf_lwt_push_encap() and the SEG6 local BPF END_B6 and END_B6_ENCAP actions call bpf_push_seg6_encap(), which forwards the length to seg6_validate_srh() with no minimum-size guard. A 2-byte SEG6 encap header can therefore make the validator read srh->type at offset 2 beyond the caller-supplied buffer.
Reject lengths shorter than the fixed SRH at the top of seg6_validate_srh(), before any field is read. This fixes the BPF helper path and keeps the common validator robust.(CVE-2026-72400)
In the Linux kernel, the following vulnerability has been resolved:
ice: fix FDIR CTRL VSI resource leak in ice_reset_all_vfs()
Resetting all VFs causes resource leak on VFs with FDIR filters enabled as CTRL VSIs are only invalidated and not freed. Fix by using ice_vf_ctrl_vsi_release() instead of ice_vf_ctrl_invalidate_vsi() which aligns behavior with the ice_reset_vf() function.
Reproduction: echo 1 > /sys/class/net/$pf/device/sriov_numvfs ethtool -N $vf flow-type ether proto 0x9000 action 0 echo 1 > /sys/class/net/$pf/device/reset(CVE-2026-72425)
In the Linux kernel, the following vulnerability has been resolved:
xfrm: validate selector family and prefixlen during match
syzbot reported a shift-out-of-bounds in xfrm_selector_match() due to AF_UNSPEC selector with large prefixlen (e.g. 128) matched against IPv4 flow (when XFRM_STATE_AF_UNSPEC is set).
Fix this by:
- Rejecting mismatched families in xfrm_selector_match.
- Returning false in addr4_match if prefixlen > 32.
- Returning false in addr_match if prefixlen > 128 (prevents overflow).(CVE-2026-72450)
In the Linux kernel, the following vulnerability has been resolved:
apparmor: aa_label_alloc use aa_label_free on alloc failure
aa_label_alloc() allocates a secid before allocating or taking the label proxy. If the later proxy step fails, the error path only freed the label memory, leaking any resources initialized by aa_label_init().
Use aa_label_free() on the failure path so partially initialized labels release their secid and other label resources before the backing memory is freed.(CVE-2026-72459)
In the Linux kernel, the following vulnerability has been resolved:
apparmor: check label build before no_new_privs test
aa_change_profile() builds a replacement label with fn_label_build_in_scope() before the no_new_privs subset check. The build helper can fail and return NULL or an ERR_PTR, but the result was passed to aa_label_is_unconfined_subset() before the existing IS_ERR_OR_NULL() check.
Reuse the existing target-label build failure handling immediately after the build. This preserves the current audit handling while preventing the subset helper from dereferencing an invalid label.(CVE-2026-72460)
In the Linux kernel, the following vulnerability has been resolved:
xprtrdma: Repost Receive buffers for malformed replies
rpcrdma_wc_receive() decrements the transport's Receive count for every completion before it dispatches a successful Receive to rpcrdma_reply_handler(). The handler must post a replacement Receive WR before returning unless ownership of the rep has moved elsewhere, as on the backchannel path.
Commit 2ae50ad68cd7 ("xprtrdma: Close window between waking RPC senders and posting Receives") moved the Receive refill out of rpcrdma_wc_receive(), where it had run ahead of every reply, into rpcrdma_reply_handler() so that the responder's credit grant could be parsed before reposting. The bad-version and short-reply exits never reach that refill: they recycle the rep and return without calling rpcrdma_post_recvs().
A remote peer can therefore drain the client's posted Receive queue by sending a sustained stream of replies that are shorter than the fixed transport header or that carry an unrecognized RPC/RDMA version. Each such reply consumes one posted Receive without replacing it. Once the queue empties, the peer's next Send finds no posted Receive and the transport stalls until reconnect.
Route both malformed-reply exits through the shared repost tail after recycling the rep, refilling against buf->rb_credits, the most recent accepted credit grant. Neither exit updates the congestion window, so RPCs admitted under the previous grant remain in flight awaiting replies. A smaller refill target would let a stream of malformed replies ratchet the posted Receive count down to the batch floor while the congestion window still admits rb_credits RPCs; a burst of valid replies to those RPCs could then overrun the posted Receives, and because the client connects with rnr_retry_count of zero, a single RNR NAK terminates the connection. Refilling against rb_credits also restores the target that applied to malformed replies before commit 2ae50ad68cd7 ("xprtrdma: Close window between waking RPC senders and posting Receives") when rpcrdma_post_recvs() computed it from rb_credits internally. rb_credits is at least one from connection establishment onward, so the repost path always keeps Receives posted.(CVE-2026-72464)
In the Linux kernel, the following vulnerability has been resolved:
xprtrdma: Fix bcall rep leak and unbounded peek
rpcrdma_is_bcall() decodes a reply's first words to decide whether the frame is a backchannel call. Two issues in that decode path let a short or malformed reply leak the receive buffer and drain the Receive queue.
First, the speculative peek
p = xdr_inline_decode(xdr, 0);
/* five p++ reads follow */
asks xdr_inline_decode() for zero bytes, which returns xdr->p without consulting xdr->end. The five subsequent __be32 reads can then walk up to 20 bytes past the wire payload into stale regbuf contents and misclassify the reply as a backchannel call.
Second, after the post-peek
p = xdr_inline_decode(xdr, 3 * sizeof(*p));
if (unlikely(!p))
return true;
the short-header arm returns true without calling rpcrdma_bc_receive_call(). The contract with the caller is that a true return transfers ownership of rep to the backchannel path:
rpcrdma_reply_handler()
if (rpcrdma_is_bcall(r_xprt, rep))
return; /* bare return, skips out_post */
...
out_post:
rpcrdma_post_recvs(r_xprt, credits + ...);
Because rpcrdma_bc_receive_call() never ran, no one took rep, but rpcrdma_reply_handler still bare-returns past rpcrdma_rep_put() and rpcrdma_post_recvs(). The rep, with its persistently DMA-mapped receive buffer, is orphaned on rb_all_reps and freed only at transport teardown. This completion reposts nothing, so its slot is reclaimed only when a later forward-channel reply reaches out_post and rpcrdma_post_recvs() allocates a fresh rep to backfill; absent that traffic the Receive queue drains and the peer's Sends draw RNR NAKs.
Fix by consulting xdr->end after the zero-length peek so the five __be32 reads cannot run unless 20 bytes of wire payload remain. A byte-precise comparison against xdr->end is required because a non-4-aligned receive rounds the stream's word count up past the true payload. Also return false from the short-header arm so the reply falls through the normal out_norqst cleanup chain (rpcrdma_rep_put() plus rpcrdma_post_recvs()).(CVE-2026-72466)
In the Linux kernel, the following vulnerability has been resolved:
xprtrdma: Decouple req recycling from RPC completion
rl_kref formerly served two distinct lifetimes through a single refcount: it gated when a Reply could wake its RPC task, and it gated when an rpcrdma_req could return to its free pool. The marshal path took the Send-side reference only when SGEs needed DMA-unmap (sc_unmap_count > 0), which made a Send carrying only pre-registered buffers an exception: the Reply handler dropped rl_kref from 1 to 0 and freed the req while the HCA might still be DMA-reading from its send buffer.
Give rl_kref a narrower job. The RPC layer takes one reference when slot allocation hands a req out. rpcrdma_prepare_send_sges() takes a Send-side reference unconditionally after WR preparation succeeds. xprt_rdma_free_slot() and xprt_rdma_bc_free_rqst() drop the RPC-layer reference; rpcrdma_sendctx_unmap() drops the Send-side reference. The req returns to its free pool only after both owners have signed off.
The existing kref_init(&req->rl_kref) call in rpcrdma_prepare_send_sges() is removed. Initialization moves to the slot-allocation paths (xprt_rdma_alloc_slot and rpcrdma_bc_rqst_get), and the release callback re-arms rl_kref before the req returns to a free pool. A re-init in the marshal path would discard the RPC-layer reference that already exists on entry.
Three invariants follow:
-
Any rpcrdma_req held by an rpc_rqst has rl_kref >= 1. xprt_rdma_alloc_slot(), rpcrdma_bc_rqst_get(), and the backlog-wake branch in xprt_rdma_alloc_slot() each kref_init rl_kref before publishing the req. Without this invariant, an RPC task that aborts between slot allocation and marshal (gss_refresh failure or signal during call_connect, for example) would drive xprt_release() -> xprt_rdma_free_slot() -> kref_put against a refcount of zero, saturating refcount_t and stranding the slot.
-
The Send-side reference is taken only after WR prep succeeds. A mapping failure in rpcrdma_prepare_send_sges() runs rpcrdma_sendctx_cancel(), which DMA-unmaps the sendctx and clears sc_req without touching rl_kref. The sendctx ring walks in rpcrdma_sendctx_put_locked() and rpcrdma_sendctxs_destroy() skip entries with sc_req == NULL, so a burst of -EIO marshal failures cannot hold reqs off rb_send_bufs.
-
The release callback re-arms rl_kref so the next consumer enters with the invariant satisfied.
Replies now complete the RPC directly. rpcrdma_reply_handler() calls rpcrdma_complete_rqst() in place of kref_put on the non-LocalInv branch. The LocalInv branch already completes the RPC from frwr_unmap_async() and is unaffected.
Because Send-side references can now outlive RPC completion, connection teardown drains sendctx entries whose unsignaled Sends never had a later signaled completion to walk the ring. rpcrdma_sendctxs_destroy() walks the active range and runs rpcrdma_sendctx_unmap() on each entry with a non-NULL sc_req before the request buffers are reset, and is moved ahead of rpcrdma_reqs_reset() in rpcrdma_xprt_disconnect() so the reqs are still in their pre-reset state when the Send-side refs are released.
The drain creates a teardown-ordering hazard on the backchannel path. With the new lifetime, releasing a bc_prealloc req from rpcrdma_req_release() re-adds it to bc_pa_list. The disconnect in xprt_rdma_destroy() runs after xprt_destroy_backchannel() has already emptied bc_pa_list, so the drained reqs would otherwise leak. xprt_rdma_destroy() now runs xprt_rdma_bc_destroy(xprt, 0) a second time after the disconnect to reclaim them.(CVE-2026-72473)
In the Linux kernel, the following vulnerability has been resolved:
power: supply: core: fix supplied_from allocations
If dts property power-supplies has multiple values, then accessing to psy->supplied_from[i-1] in __power_supply_populate_supplied_from will overrun supplied_from array.(CVE-2026-74271)
In the Linux kernel, the following vulnerability has been resolved:
tipc: require net admin for TIPCv2 netlink mutators
TIPCv2 registers mutating generic-netlink operations without admin permission flags. Generic netlink only checks CAP_NET_ADMIN when an operation sets GENL_ADMIN_PERM or GENL_UNS_ADMIN_PERM, so a local unprivileged process can currently change TIPC state through commands such as TIPC_NL_NET_SET, TIPC_NL_KEY_SET, TIPC_NL_KEY_FLUSH, and bearer enable/disable.
The legacy TIPC netlink API already checks netlink_net_capable(..., CAP_NET_ADMIN) for administrative commands. Give the TIPCv2 mutators the equivalent generic-netlink gate. Use GENL_UNS_ADMIN_PERM, which maps to the same namespace-aware CAP_NET_ADMIN check that netlink_net_capable() performs, so the behaviour matches the legacy path and keeps working for CAP_NET_ADMIN holders in a non-initial user namespace (containers).
A QEMU/KASAN repro run as uid/gid 65534 with zero effective capabilities previously succeeded in changing the network id and node identity, setting and flushing key material, and enabling/disabling a UDP bearer. With this patch applied the same operations fail with -EPERM.(CVE-2026-74283)
In the Linux kernel, the following vulnerability has been resolved:
sctp: validate embedded address parameter length
sctp_verify_asconf() and sctp_verify_param() only validate ADD_IP, DEL_IP, and SET_PRIMARY parameters against a fixed minimum size of sizeof(struct sctp_addip_param) + sizeof(struct sctp_paramhdr). This ensures the outer parameter is large enough to contain an embedded address parameter header, but does not verify that the embedded address parameter's declared length fits within the bounds of the outer parameter.
Later, sctp_process_param() and sctp_process_asconf_param() extract the embedded address parameter and pass it to af->from_addr_param(), which uses the address parameter length to parse the variable-length address payload. A malformed peer can therefore advertise an embedded address parameter length that exceeds the remaining bytes in the enclosing parameter.
Validate that addr_param->p.length does not exceed the space available after the sctp_addip_param header before processing the embedded address parameter. Reject malformed parameters when the embedded address length extends beyond the enclosing parameter bounds.
This prevents out-of-bounds reads when parsing malformed parameters carried in INIT or ASCONF processing paths.(CVE-2026-74287)
In the Linux kernel, the following vulnerability has been resolved:
bpf: Tighten cgroup storage cookie checks for prog arrays
The fix in commit abad3d0bad72 ("bpf: Fix oob access in cgroup local storage") is still incomplete. The prog-array compatibility check treats a program with no cgroup storage as compatible with any stored storage cookie. This allows a storage-less program to bridge a tail call chain between an entry program and a storage-using callee even though cgroup local storage at runtime still follows the caller's context, that is, A -> B(no storage) -> C(storage) path.
Requiring exact cookie equality would break the legitimate case of a storage-less leaf program being tail called from a storage-using one. Instead, only accept a zero storage cookie if the program cannot perform tail calls itself. This keeps A -> B(no storage) working while rejecting the A -> B(no storage) -> C(storage) bridge.(CVE-2026-74305)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/rxe: Copy WQE to local buffer in non-SRQ receive path
For non-SRQ QPs, the responder reads WQE fields directly from the shared queue buffer mapped into userspace. This allows a malicious user to modify fields like num_sge or sge entries while the kernel is processing the WQE, leading to out-of-bounds reads in rxe_resp_check_length() and copy_data().
Introduce get_recv_wqe() that validates num_sge and copies the WQE to a kernel-local buffer before processing, matching the approach already used for SRQ WQEs in get_srq_wqe(). The srq_wqe buffer is reused since SRQ and non-SRQ paths are mutually exclusive per QP.(CVE-2026-74377)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/rxe: Fix TOCTOU heap overflow in get_srq_wqe
get_srq_wqe() reads wqe->dma.num_sge from the shared receive queue buffer, which is mapped into userspace. It validates num_sge against max_sge, but then re-reads the same field to calculate the memcpy size. A concurrent userspace thread can modify num_sge between validation and use, causing a heap buffer overflow when copying the WQE into qp->resp.srq_wqe.
Read num_sge into a local variable and use it for both the bounds check and the size calculation.(CVE-2026-74378)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/srpt: fix integer overflow in immediate data length check
imm_buf->len is a user-controlled uint32_t received from the network. Adding it to imm_data_offset without overflow checking allows a malicious initiator to send len=0xFFFFFFFF, causing req_size to wrap around to a small value, bypassing the bounds check, and subsequently passing a ~4GB length to sg_init_one().
Use check_add_overflow() to detect wrapping before the comparison.(CVE-2026-74394)
In the Linux kernel, the following vulnerability has been resolved:
IB/mlx5: Fix transport-domain rollback and initialize lb mutex earlier
mlx5_ib_alloc_transport_domain() allocates a transport domain and then may fail in mlx5_ib_enable_lb(). In that case, the allocated TD is leaked.
Fix this by deallocating the TD when mlx5_ib_enable_lb() returns an error. Also return 0 explicitly in the no-loopback-capability success branch, and move dev->lb.mutex initialization to mlx5_ib_stage_init_init().(CVE-2026-74397)
In the Linux kernel, the following vulnerability has been resolved:
ipv6: addrconf: bail out of dad_failure when state is no longer POSTDAD
addrconf_dad_failure() transitions ifp->state from DAD to POSTDAD via addrconf_dad_end(), which drops ifp->lock on return. The lock is re-acquired after net_info_ratelimited(). A concurrent ipv6_del_addr() can take the lock in that window, set ifp->state to DEAD and run list_del_rcu(&ifp->if_list).
addrconf_dad_failure() then overwrites DEAD with ERRDAD at errdad: and schedules a new dad_work. The work calls ipv6_del_addr() again, hitting the already-poisoned list entry:
general protection fault: 0000 [#1] SMP NOPTI CPU: 4 PID: 217 Comm: kworker/4:1 Workqueue: ipv6_addrconf addrconf_dad_work RIP: 0010:ipv6_del_addr+0xe9/0x280 RAX: dead000000000122 Call Trace: addrconf_dad_stop+0x113/0x140 addrconf_dad_work+0x28c/0x430 process_one_work+0x1eb/0x3b0 worker_thread+0x4d/0x400 kthread+0x104/0x140 ret_from_fork+0x35/0x40
Fold the addrconf_dad_end() logic into addrconf_dad_failure() under a single ifp->lock critical section. The STABLE_PRIVACY branch temporarily drops ifp->lock around address regeneration, so at lock_errdad: verify the state is still POSTDAD before transitioning to ERRDAD; bail out otherwise to avoid overwriting a state set by another path while the lock was released.(CVE-2026-74398)
In the Linux kernel, the following vulnerability has been resolved:
vxlan: Fix potential null-ptr-deref in vxlan_gro_prepare_receive().
udp_tunnel_sock_release() could set sk->sk_user_data to NULL while vxlan_gro_prepare_receive() is running.
Let's check if rcu_dereference_sk_user_data() is NULL after skb_gro_remcsum_init().(CVE-2026-74406)
| URL | Type | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-6.6.0-145.1.24.161.oe2403sp1.aarch64.rpm",
"bpftool-debuginfo-6.6.0-145.1.24.161.oe2403sp1.aarch64.rpm",
"kernel-6.6.0-145.1.24.161.oe2403sp1.aarch64.rpm",
"kernel-debuginfo-6.6.0-145.1.24.161.oe2403sp1.aarch64.rpm",
"kernel-debugsource-6.6.0-145.1.24.161.oe2403sp1.aarch64.rpm",
"kernel-devel-6.6.0-145.1.24.161.oe2403sp1.aarch64.rpm",
"kernel-headers-6.6.0-145.1.24.161.oe2403sp1.aarch64.rpm",
"kernel-source-6.6.0-145.1.24.161.oe2403sp1.aarch64.rpm",
"kernel-tools-6.6.0-145.1.24.161.oe2403sp1.aarch64.rpm",
"kernel-tools-debuginfo-6.6.0-145.1.24.161.oe2403sp1.aarch64.rpm",
"kernel-tools-devel-6.6.0-145.1.24.161.oe2403sp1.aarch64.rpm",
"perf-6.6.0-145.1.24.161.oe2403sp1.aarch64.rpm",
"perf-debuginfo-6.6.0-145.1.24.161.oe2403sp1.aarch64.rpm",
"python3-perf-6.6.0-145.1.24.161.oe2403sp1.aarch64.rpm",
"python3-perf-debuginfo-6.6.0-145.1.24.161.oe2403sp1.aarch64.rpm"
],
"src": [
"kernel-6.6.0-145.1.24.161.oe2403sp1.src.rpm"
],
"x86_64": [
"bpftool-6.6.0-145.1.24.161.oe2403sp1.x86_64.rpm",
"bpftool-debuginfo-6.6.0-145.1.24.161.oe2403sp1.x86_64.rpm",
"kernel-6.6.0-145.1.24.161.oe2403sp1.x86_64.rpm",
"kernel-debuginfo-6.6.0-145.1.24.161.oe2403sp1.x86_64.rpm",
"kernel-debugsource-6.6.0-145.1.24.161.oe2403sp1.x86_64.rpm",
"kernel-devel-6.6.0-145.1.24.161.oe2403sp1.x86_64.rpm",
"kernel-headers-6.6.0-145.1.24.161.oe2403sp1.x86_64.rpm",
"kernel-source-6.6.0-145.1.24.161.oe2403sp1.x86_64.rpm",
"kernel-tools-6.6.0-145.1.24.161.oe2403sp1.x86_64.rpm",
"kernel-tools-debuginfo-6.6.0-145.1.24.161.oe2403sp1.x86_64.rpm",
"kernel-tools-devel-6.6.0-145.1.24.161.oe2403sp1.x86_64.rpm",
"perf-6.6.0-145.1.24.161.oe2403sp1.x86_64.rpm",
"perf-debuginfo-6.6.0-145.1.24.161.oe2403sp1.x86_64.rpm",
"python3-perf-6.6.0-145.1.24.161.oe2403sp1.x86_64.rpm",
"python3-perf-debuginfo-6.6.0-145.1.24.161.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-145.1.24.161.oe2403sp1"
}
],
"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:\n\nASoC: qcom: Fix sc7280 lpass potential buffer overflow\n\nCase values introduced in commit\n5f78e1fb7a3e (\u0026quot;ASoC: qcom: Add driver support for audioreach solution\u0026quot;)\ncause out of bounds access in arrays of sc7280 driver data (e.g. in case\nof RX_CODEC_DMA_RX_0 in sc7280_snd_hw_params()).\n\nRedefine LPASS_MAX_PORTS to consider the maximum possible port id for\nq6dsp as sc7280 driver utilizes some of those values.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-37979)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: usb: asix_devices: Fix PHY address mask in MDIO bus initialization\n\nSyzbot reported shift-out-of-bounds exception on MDIO bus initialization.\n\nThe PHY address should be masked to 5 bits (0-31). Without this\nmask, invalid PHY addresses could be used, potentially causing issues\nwith MDIO bus operations.\n\nFix this by masking the PHY address with 0x1f (31 decimal) to ensure\nit stays within the valid range.(CVE-2025-38736)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: af_alg - Fix page reassignment overflow in af_alg_pull_tsgl\n\nWhen page reassignment was added to af_alg_pull_tsgl the original\nloop wasn\u0026apos;t updated so it may try to reassign one more page than\nnecessary.\n\nAdd the check to the reassignment so that this does not happen.\n\nAlso update the comment which still refers to the obsolete offset\nargument.(CVE-2026-43078)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: algif_aead - snapshot IV for async AEAD requests\n\nAF_ALG AEAD AIO requests currently use the socket-wide IV buffer during\nrequest processing. For async requests, later socket activity can\nupdate that shared state before the original request has fully\ncompleted, which can lead to inconsistent IV handling.\n\nSnapshot the IV into per-request storage when preparing the AEAD\nrequest, so in-flight operations no longer depend on mutable socket\nstate.(CVE-2026-46028)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: esp: restore combined single-frag length gate\n\nThe ESP out-of-place fast path appends the trailer in esp_output_head()\nbefore esp_output_tail() allocates the destination page frag. The\nhead-side gate currently checks skb-\u0026gt;data_len and tailen separately, but\nthe tail code allocates a single destination frag from the combined\npost-trailer skb-\u0026gt;data_len.\n\nReject the page-frag fast path when the combined aligned length exceeds a\npage. Otherwise skb_page_frag_refill() may fall back to a single page while\nthe destination sg still spans the combined skb-\u0026gt;data_len.\n\nRestore this combined-length page gate for both IPv4 and IPv6.(CVE-2026-63912)\n\nIn the Linux kernel, the following vulnerability has been resolved: ipvs: reload ip header after head reallocation. __ip_vs_get_out_rt() calls skb_ensure_writable() which may reallocate skb-\u0026gt;head, causing the previously obtained IP header pointer to become a dangling pointer, leading to a use-after-free vulnerability.(CVE-2026-68476)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipvs: fix more places with wrong ipv6 transport offsets\n\nSashiko reports for more incorrect IPv6 transport offsets.\n\nThe app code for TCP was assuming IPv4 network header\neven after the ipvsh argument was provided. This can\ncause problems with apps over IPv6. As for the only\nofficial app in the kernel tree (FTP) this problem is\nharmless because we use Netfilter to mangle the FTP\nports and we do not adjust the TCP seq numbers.\n\nAlso, provide correct offset of the ICMPV6 header in\nip_vs_out_icmp_v6() for correct checksum checks when\nthe IPv6 packet has extension headers.(CVE-2026-68477)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipvs: use parsed transport offset in SCTP state lookup\n\nset_sctp_state() reads the SCTP chunk header again in order to drive the\nIPVS SCTP state table. For IPv6 it computes the offset with\nsizeof(struct ipv6hdr), while the surrounding IPVS code uses iph.len from\nip_vs_fill_iph_skb(), where ipv6_find_hdr() has already skipped\nextension headers and found the real transport header.\n\nThis makes the state machine read from the wrong offset for IPv6 SCTP\npackets that carry extension headers. For example, an INIT packet with an\n8-byte destination options header can be scheduled correctly by\nsctp_conn_schedule(), but set_sctp_state() reads the first byte of the\nSCTP verification tag as a DATA chunk type. The connection then moves\nfrom NONE to ESTABLISHED instead of INIT1, gets the longer established\ntimeout, and updates the active/inactive destination counters\nincorrectly. This happens even though the SCTP handshake has not\ncompleted.\n\nUse the parsed transport offset passed down from ip_vs_set_state() for\nthe SCTP chunk-header lookup. For IPv4 and IPv6 packets without\nextension headers this preserves the existing offset.(CVE-2026-72021)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nieee802154: admin-gate legacy LLSEC dump operations\n\nIn net/ieee802154/netlink.c, the legacy IEEE802154_NL family ops table\nbuilds the LLSEC dump entries (LLSEC_LIST_KEY, LLSEC_LIST_DEV,\nLLSEC_LIST_DEVKEY, LLSEC_LIST_SECLEVEL) with IEEE802154_DUMP() which\nsets no .flags, so generic netlink runs them ungated. The modern\nnl802154 family admin-gates the equivalent reads via\nNL802154_CMD_GET_SEC_KEY and friends with .flags = GENL_ADMIN_PERM.\n\nAny local uid that can open AF_NETLINK / NETLINK_GENERIC can resolve\nthe \u0026quot;802.15.4 MAC\u0026quot; family and dump LLSEC_LIST_KEY on any wpan netdev\nthat has an LLSEC key installed; the dump handler writes the raw\n16-byte AES-128 key bytes (IEEE802154_ATTR_LLSEC_KEY_BYTES, copied\nverbatim from struct ieee802154_llsec_key.key) into the reply.\nRecovering the AES key compromises 802.15.4 LLSEC link confidentiality\nand authenticity, since LLSEC uses CCM* and the same key authenticates\nand encrypts frames.\n\nImpact: any local uid with no capabilities can read the raw 16-byte\nAES-128 LLSEC key from the kernel keytable on any wpan netdev that has\nan administrator-installed LLSEC key, by issuing an LLSEC_LIST_KEY\ndump on the legacy IEEE802154_NL generic-netlink family.\n\nIntroduce IEEE802154_DUMP_PRIV() mirroring IEEE802154_DUMP() but\nsetting .flags = GENL_ADMIN_PERM, and use it for the four LLSEC dump\nentries. LIST_PHY and LIST_IFACE retain IEEE802154_DUMP() because the\nmodern nl802154 family exposes their equivalents to unprivileged\nreaders by design (NL802154_CMD_GET_WPAN_PHY and\nNL802154_CMD_GET_INTERFACE carry \u0026quot;can be retrieved by unprivileged\nusers\u0026quot; annotations).(CVE-2026-72049)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: ip6_gre: require CAP_NET_ADMIN in the device netns for changelink\n\nip6gre_changelink() and ip6erspan_changelink() operate on at most two\nnetns, dev_net(dev) and the tunnel link netns t-\u0026gt;net. They differ once\nthe device is created in or moved to a netns other than the one the\nrequest runs in. The rtnl changelink path checks CAP_NET_ADMIN only\nagainst dev_net(dev), so a caller privileged there but not in t-\u0026gt;net can\nrewrite a tunnel that lives in t-\u0026gt;net.\n\nGate both ops on rtnl_dev_link_net_capable() at their top, before any\nattribute is parsed.(CVE-2026-72052)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: ipip: require CAP_NET_ADMIN in the device netns for changelink\n\nipip_changelink() operates on at most two netns, dev_net(dev) and the\ntunnel link netns t-\u0026gt;net. They differ once the device is created in or\nmoved to a netns other than the one the request runs in. The rtnl\nchangelink path checks CAP_NET_ADMIN only against dev_net(dev), so a\ncaller privileged there but not in t-\u0026gt;net can rewrite a tunnel that\nlives in t-\u0026gt;net.\n\nGate ipip_changelink() on rtnl_dev_link_net_capable() at its top,\nbefore any attribute is parsed.(CVE-2026-72053)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: ip_vti: require CAP_NET_ADMIN in the device netns for changelink\n\nvti_changelink() operates on at most two netns, dev_net(dev) and the\ntunnel link netns t-\u0026gt;net. They differ once the device is created in or\nmoved to a netns other than the one the request runs in. The rtnl\nchangelink path checks CAP_NET_ADMIN only against dev_net(dev), so a\ncaller privileged there but not in t-\u0026gt;net can rewrite a tunnel that\nlives in t-\u0026gt;net.\n\nGate vti_changelink() on rtnl_dev_link_net_capable() at its top,\nbefore any attribute is parsed.(CVE-2026-72054)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: sit: require CAP_NET_ADMIN in the device netns for changelink\n\nipip6_changelink() operates on at most two netns, dev_net(dev) and the\ntunnel link netns t-\u0026gt;net. They differ once the device is created in or\nmoved to a netns other than the one the request runs in. The rtnl\nchangelink path checks CAP_NET_ADMIN only against dev_net(dev), so a\ncaller privileged there but not in t-\u0026gt;net can rewrite a tunnel that\nlives in t-\u0026gt;net.\n\nGate ipip6_changelink() on rtnl_dev_link_net_capable() at its top,\nbefore any attribute is parsed. sit was the one tunnel type not covered\nby the recent series that added this check to the other changelink()\nhandlers.(CVE-2026-72061)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: macsec: fix use-after-free of metadata_dst on RX SC delete\n\nWhen an offloaded MACsec RX SC is deleted, macsec_del_rxsc_ctx() freed\nthe per-SC metadata_dst with metadata_dst_free(), which kfree()s the\nobject unconditionally and ignores the dst reference count. The RX\ndatapath in mlx5e_macsec_offload_handle_rx_skb() looks up the SC under\nrcu_read_lock() via xa_load(), takes a reference with dst_hold() and\nattaches the dst to the skb with skb_dst_set(). A reader that already\nobtained the rx_sc pointer can race with the delete path and operate on\nfreed memory.\n\nFix the owner side by dropping the reference with dst_release() instead\nof freeing unconditionally, and convert the RX datapath to\ndst_hold_safe() so a reader racing the SC delete cannot attach a dst\nwhose last reference was just dropped; only attach it when a reference\nwas actually taken.\n\nmlx5e_macsec_add_rxsc() also published sc_xarray_element via xa_alloc()\nbefore rx_sc-\u0026gt;md_dst was allocated and initialised, so a datapath reader\nthat looked the SC up by fs_id could observe rx_sc with md_dst still\nNULL or, on weakly-ordered architectures, a non-NULL md_dst pointer\nwhose contents were not yet visible. NULL-check the xa_load() result and\nmd_dst on the datapath, and reorder add_rxsc() so the xa_alloc() publish\nhappens only after md_dst is fully initialised; the xarray RCU publish\nthen pairs with the rcu_read_lock()/xa_load() in the datapath.\n\nNote: macsec_del_rxsc_ctx() also kfree()s rx_sc-\u0026gt;sc_xarray_element\nwithout an RCU grace period while the same datapath reads it under\nrcu_read_lock(); that is a separate pre-existing issue left to a\nfollow-up patch.\n\nFound by 0sec automated security-research tooling (https://0sec.ai).(CVE-2026-72072)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvmet-rdma: handle inline data with a nonzero offset\n\nnvmet_rdma_use_inline_sg() maps the host-controlled inline data offset\ninto the per-command inline scatterlist. The bounds check admits any\noffset with off + len \u0026lt;= inline_data_size, but the mapping still assumes\nthe data begins in the first inline page:\n\n\tsg-\u0026gt;offset = off;\n\tsg-\u0026gt;length = min_t(int, len, PAGE_SIZE - off);\n\nWhen a port is configured with inline_data_size \u0026gt; PAGE_SIZE (settable up\nto max(SZ_16K, PAGE_SIZE)), an offset in (PAGE_SIZE, inline_data_size]\nmakes \u0026quot;PAGE_SIZE - off\u0026quot; underflow, so sg-\u0026gt;length is set to ~4 GiB and\nthe block backend reads far past the first inline page. num_pages(len)\nalso ignores the offset, so an in-bounds offset whose [off, off+len)\nspan crosses a page boundary under-counts the scatterlist.\n\nMap the offset properly: split it into a page index and an in-page\noffset, start the scatterlist at that page, and size the page count from\npage_off + len. Because the request scatterlist may now start at\ninline_sg[page_idx] rather than inline_sg[0], generalize the inline-SGL\nidentity test in nvmet_rdma_release_rsp() to a range test; otherwise the\npersistent inline scatterlist is mistaken for an allocated one and\nnvmet_req_free_sgls() frees an inline page (and warns in\nfree_large_kmalloc()).(CVE-2026-72129)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntpm: Make the TPM character devices non-seekable\n\nThe TPM character devices expose a sequential command/response\ninterface, but their open handlers leave FMODE_PREAD and FMODE_PWRITE\nenabled.\n\nAfter a command leaves a response pending, pread(fd, buf, 16, 0x1400)\npasses 0x1400 as *off to tpm_common_read(). The transfer length is\nbounded by response_length, but the offset is used unchecked when\nforming data_buffer + *off. A sufficiently large offset therefore causes\nan out-of-bounds heap read through copy_to_user() and, if the copy\nsucceeds, an out-of-bounds zero-write through the following memset().\n\nPositional I/O does not provide coherent semantics for this interface.\nAn arbitrary pread offset cannot represent how much of a response has\nbeen consumed sequentially. The write callback always stores a command\nat the start of data_buffer, while pwrite() does not update file-\u0026gt;f_pos\nand can leave the sequential read cursor stale.\n\nCall nonseekable_open() from both open handlers. This removes\nFMODE_PREAD and FMODE_PWRITE, causing positional reads and writes to\nfail with -ESPIPE before reaching the TPM callbacks, and explicitly\nmarks the files non-seekable. Normal read() and write() continue to use\nthe existing sequential f_pos cursor, leaving the response state machine\nunchanged.\n\nTested on Linux 6.12 with KASAN and a swtpm TPM2 device:\n\n - sequential partial reads returned the complete response\n - pread() and preadv() with offset 0x1400 returned -ESPIPE\n - pwrite() and pwritev() with offset zero returned -ESPIPE\n - the pending response remained intact after the rejected operations\n - a subsequent normal command/response cycle completed normally\n - no KASAN report was produced.(CVE-2026-72135)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: xfrm_interface: require CAP_NET_ADMIN in the device netns for changelink\n\nxfrmi_changelink() operates on at most two netns, dev_net(dev) and the\ninterface link netns xi-\u0026gt;net. They differ once the device is created in\nor moved to a netns other than the one the request runs in. The rtnl\nchangelink path checks CAP_NET_ADMIN only against dev_net(dev), so a\ncaller privileged there but not in xi-\u0026gt;net can rewrite an interface that\nlives in xi-\u0026gt;net.\n\nGate xfrmi_changelink() on rtnl_dev_link_net_capable() at its top,\nbefore any attribute is parsed.(CVE-2026-72136)\n\nIn the Linux kernel, the following vulnerability has been resolved: net: thunderbolt: Fix frags[] overflow by bounding frame_count. tbnet_poll() assembles a multi-frame ThunderboltIP packet into one skb. The first frame goes into the skb linear area and every further frame is added as a page fragment. A packet of frame_count frames therefore ends up with frame_count - 1 fragments. tbnet_check_frame() only bounds the peer supplied frame_count to TBNET_RING_SIZE / 4 (64), which is far above MAX_SKB_FRAGS (17 by default). A peer that sends a packet of 19 or more small frames pushes nr_frags past MAX_SKB_FRAGS, so skb_add_rx_frag() writes past skb_shinfo()-\u0026gt;frags[] and corrupts memory after the shared info.(CVE-2026-72157)\n\nIn the Linux kernel, the following vulnerability has been resolved: mm/mm_init: fix uninitialized struct pages for ZONE_DEVICE. If DAX memory is hotplugged into an unoccupied subsection of an early section, section_activate() reuses the unoptimized boot memmap. However, compound_nr_pages() still assumes that vmemmap optimization is in effect and initializes only the reduced number of struct pages. As a result, the remaining tail struct pages are left uninitialized, which can later lead to unexpected behavior or crashes. Fix this by treating early sections as unoptimized when calculating how many struct pages to initialize.(CVE-2026-72172)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nSUNRPC: Bound-check xdr_buf_to_bvec() stores before writing\n\nxdr_buf_to_bvec() writes a bio_vec into the caller\u0026apos;s array before\ntesting whether that slot is in range, and the head branch performs\nthe store with no check at all. When the caller\u0026apos;s budget is exactly\nused up, the next store lands one element past the end of the array.\nThe overflow label returns count - 1, which masks the surplus store\nbut cannot undo it.\n\nrq_bvec, the array passed by nfsd_vfs_write(), is allocated to\nexactly rq_maxpages entries with no slack. The OOB store can land in\nadjacent slab memory; the bv_len and bv_offset fields written there\nare derived from client-supplied RPC payload sizes.\n\nMove the in-range check ahead of the store in the head, page-loop,\nand tail branches. With the check at the top of each sequence, count\nis incremented only after a successful store, so the overflow label\ncan return count directly.(CVE-2026-72217)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsunrpc: wait for in-flight TLS handshake callback when cancel loses race\n\nWhen wait_for_completion_interruptible_timeout() in\nsvc_tcp_handshake() returns 0 (timeout) or -ERESTARTSYS (signal) and\ntls_handshake_cancel() then returns false, handshake_complete() has\nwon the cancellation race: it has set HANDSHAKE_F_REQ_COMPLETED and\nis about to invoke svc_tcp_handshake_done(), but the callback\u0026apos;s\nside effects on xpt_flags and on svsk-\u0026gt;sk_handshake_done have not\nyet committed.\n\nThe current code reads xpt_flags immediately to decide whether the\nsession succeeded. Two races result.\n\nIf the callback has executed set_bit(XPT_TLS_SESSION) but not yet\nclear_bit(XPT_HANDSHAKE), svc_tcp_handshake() sees a session,\nenqueues the transport, and returns. svc_xprt_received() then\nclears XPT_BUSY, a worker thread picks the transport up, the\ndispatcher in svc_handle_xprt() observes XPT_HANDSHAKE still set,\nand xpo_handshake is invoked a second time. That svc_tcp_handshake()\ncalls init_completion(\u0026amp;svsk-\u0026gt;sk_handshake_done) while the original\ncallback concurrently calls complete_all() on it, corrupting the\nembedded swait_queue.\n\nIf the callback has set HANDSHAKE_F_REQ_COMPLETED but not yet\nentered svc_tcp_handshake_done(), svc_tcp_handshake() reads\nXPT_TLS_SESSION as clear and tears the connection down even though\nthe handshake is about to succeed.\n\nWait for the callback to commit before inspecting xpt_flags. The\ncompletion is guaranteed to fire because handshake_complete()\ninvokes svc_tcp_handshake_done() unconditionally once it has set\nHANDSHAKE_F_REQ_COMPLETED.(CVE-2026-72221)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsunrpc: pin svc_xprt across the asynchronous TLS handshake callback\n\nsvc_tcp_handshake() stores the raw svc_xprt pointer in\ntls_handshake_args.ta_data and submits the request through\ntls_server_hello_x509(). The handshake core takes only\nsock_hold(req-\u0026gt;hr_sk); nothing references the embedding struct\nsvc_sock that svc_tcp_handshake_done() reaches via container_of().\n\nTwo close races leave the in-flight callback writing through a freed\nsvc_sock. svc_sock_free() calls tls_handshake_cancel() and discards\nits return value: a false return means handshake_complete() has\nalready set HANDSHAKE_F_REQ_COMPLETED but hp_done() may not have\nfinished, yet svc_sock_free() proceeds to kfree(svsk). The\ncancel-loser fall-through inside svc_tcp_handshake() itself produces\nthe same window: when wait_for_completion_interruptible_timeout()\nreturns \u0026lt;= 0 (timeout or signal) and tls_handshake_cancel() returns\nfalse, the function does not drain, returns, and svc_handle_xprt()\ncalls svc_xprt_received(), which clears XPT_BUSY and can drop the\nlast reference. A concurrent close then runs svc_sock_free() while\nsvc_tcp_handshake_done() is still updating xpt_flags and walking\nsvsk-\u0026gt;sk_handshake_done.\n\nThe corruption surfaces as set_bit/clear_bit RMW into the freed\nxpt_flags slab slot and as complete_all() walking and writing the\nfreed wait_queue_head_t list embedded in sk_handshake_done -- a\nslab-corruption primitive, not a benign read. The path is reachable\non any TLS-enabled NFS server whenever a connection close overlaps\nthe tlshd downcall delivery window; the interruptible wait means\nsignal delivery suffices, not just SVC_HANDSHAKE_TO expiry.\n\nTake svc_xprt_get(xprt) immediately before tls_server_hello_x509()\nso the in-flight callback owns its own reference. Release it on the\ntwo edges where the callback is guaranteed not to fire -- submission\nfailure from tls_server_hello_x509() and a successful\ntls_handshake_cancel() -- and at the tail of\nsvc_tcp_handshake_done() after complete_all().\n\n[cel: rewrote commit message to describe the actual change](CVE-2026-72222)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbatman-adv: retrieve ethhdr after potential skb realloc on RX\n\npskb_may_pull() in batadv_interface_rx() could reallocate the buffer behind\nthe skb. Variables which were pointing to the old buffer need to be\nreassigned to avoid an use-after-free.\n\nThis was done correctly for the VLAN header but missed for the ethernet\nheader which is later used for the TT and AP isolation handling.(CVE-2026-72235)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: Move kvm_io_bus_get_dev() locking responsibilities to callers\n\nkvm_io_bus_get_dev() returns a device that is only matched by the\naddress, and nothing else. This can cause a lifetime issue if\nthe matched device is not the expected type, as by the time\nthe caller can introspect the object, it might be gone (the srcu\nlock having been dropped).\n\nGiven that there is only a single user of this helper, the simplest\noption is to move the locking responsibility to the caller, which\ncan keep the srcu lock held for as long as it wants.\n\nNote that this aligns with other kvm_io_bus*() helpers, which\nalready require the srcu lock to be held by the callers.(CVE-2026-72282)\n\nIn the Linux kernel, the following vulnerability has been resolved: smb: client: fix overflow in passthrough ioctl bounds check. smb2_ioctl_query_info() validates the PASSTHRU_FSCTL response payload before copying it to userspace. The payload offset and length both come from 32-bit fields. The bounds check currently adds OutputOffset and qi.input_buffer_length directly, so the addition can wrap in 32-bit arithmetic before the result is compared against the response buffer length. A malicious server can use a large OutputOffset and a small OutputCount to make the wrapped sum pass the bounds check. The later copy_to_user() then reads from io_rsp + OutputOffset, outside the response buffer, leading to an out-of-bounds read.(CVE-2026-72310)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndm era: fix NULL pointer dereference in metadata_open()\n\nmetadata_open() returns NULL when kzalloc_obj() fails, but the\ncaller era_ctr() only checks IS_ERR(md). Since IS_ERR(NULL)\nreturns false, the NULL pointer is treated as a valid result\nand later assigned to era-\u0026gt;md, leading to a NULL pointer\ndereference when the metadata is accessed.\n\nFix this by returning ERR_PTR(-ENOMEM) on allocation failure,\nconsistent with dm-cache-metadata.c, dm-thin-metadata.c, and\ndm-clone-metadata.c which all use ERR_PTR(-ENOMEM) for the\nsame pattern.(CVE-2026-72316)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nSUNRPC: pin upper rpc_clnt across the TLS connect_worker\n\nThe TLS connect path has a use-after-free: nothing pins the\nupper rpc_clnt across the delayed connect_worker. xs_connect()\nstores task-\u0026gt;tk_client in sock_xprt::clnt as a raw pointer\nand queues the worker; for TLS-secured transports that worker\nis xs_tcp_tls_setup_socket(), which reads several fields out\nof the saved pointer (cl_timeout, cl_program, cl_prog,\ncl_vers, cl_cred, cl_stats) to construct the args for the\ninner handshake rpc_clnt.\n\nThe xprt does not reference the rpc_clnt; the rpc_clnt\nreferences the xprt. xs_destroy() does cancel the\nconnect_worker, but it runs only when the xprt\u0026apos;s refcount\ndrops to zero, which cannot happen until the rpc_clnt\nreleases its cl_xprt reference in rpc_free_client_work().\nWhen a TLS handshake fails fatally (for example, an mTLS\nmount whose client cert does not match the server), the\nconnecting task is woken with -EACCES and exits, the mount\ncaller invokes rpc_shutdown_client(), and the upper rpc_clnt\nis freed before the queued connect_worker fires.\nxs_tcp_tls_setup_socket() then dereferences the freed clnt,\nproducing the refcount_t underflow Michael Nemanov reported.\n\nTake a reference on the upper rpc_clnt in xs_connect() for\nTLS transports via a new rpc_hold_client() helper, and drop\nit in the connect_worker\u0026apos;s exit path with rpc_release_client().\nThe xprt_lock_connect() / xprt_unlock_connect() pairing\nalready serialises xs_connect() with xs_tcp_tls_setup_socket(),\nso the take and release are balanced one-for-one.\n\nThe non-TLS connect worker (xs_tcp_setup_socket) never reads\nsock_xprt::clnt, so leave that path alone and avoid the\nclnt-holds-xprt-holds-clnt cycle that would otherwise prevent\nxprt destruction.(CVE-2026-72317)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncifs: validate DFS referral string offsets\n\nparse_dfs_referrals() validates that the response header and referral\narray fit in the received buffer, but each referral also contains string\noffsets supplied by the server.\n\nThose offsets are used to compute the DfsPath and NetworkAddress string\npointers without checking whether they still point inside the response\nbuffer. A malformed referral can therefore make the computed pointer\nexceed the end of the buffer. The resulting negative max_len is then\npassed to cifs_strndup_from_utf16(), and the non-Unicode path forwards it\nto kstrndup() as a size_t, allowing strnlen() to read out of bounds.\n\nValidate each string offset before deriving the string pointer.(CVE-2026-72318)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipvs: ensure inner headers in ICMP errors are in headroom\n\nSashiko points out that after stripping the outer headers\nwith pskb_pull() we should ensure the inner IP headers\nin ICMP errors from tunnels are present in the skb headroom\nfor functions like ipv4_update_pmtu(), icmp_send() and\nIP_VS_DBG().\n\nAlso, add more checks for the length of the inner headers.(CVE-2026-72319)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/tls: Consume empty data records in tls_sw_read_sock()\n\nA peer may send a zero-length TLS application_data record; TLS 1.3\nexplicitly permits these as a traffic-analysis countermeasure (RFC\n8446, Section 5.1). After decryption such a record has full_len ==\n0. tls_sw_read_sock() hands it to the read_actor, which has no\npayload to consume and returns zero. The loop treats a zero return\nas backpressure (used \u0026lt;= 0), requeues the skb at the head of\nrx_list, and stops. rx_list is serviced head-first on the next\ncall, so the empty record is dequeued, fails the same way, and is\nrequeued again; every later record on the connection is blocked\nbehind it.\n\ntls_sw_recvmsg() does not stall on this: a zero-length data record\ncopies nothing and falls through to consume_skb(). Mirror that in\nthe read_sock() path by recognizing an empty data record before\nthe actor runs, consuming it, and continuing.(CVE-2026-72330)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nqede: fix off-by-one in BD ring consumption on build_skb failure\n\nqede_rx_build_skb() and qede_tpa_rx_build_skb() do not check for a\nNULL return from qede_build_skb(). When it returns NULL under memory\npressure, the functions still consume a BD from the ring before\nreturning NULL. The callers then recycle additional BDs, resulting in\none extra BD being consumed (off-by-one). This desynchronizes the BD\nring, which can corrupt DMA page reference counts and lead to SLUB\nfreelist corruption.\n\nCommit 4e910dbe3650 (\u0026quot;qede: confirm skb is allocated before using\u0026quot;)\nadded a NULL check inside qede_build_skb() to prevent a NULL pointer\ndereference, but did not address the missing NULL checks in the\ncallers, making this off-by-one reachable.\n\nFix this by adding NULL checks for the return value of\nqede_build_skb() in both qede_rx_build_skb() and\nqede_tpa_rx_build_skb(), returning NULL immediately before any BD ring\nmanipulation.(CVE-2026-72339)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Fix HV VHCA stats agent registration race\n\nmlx5e_hv_vhca_stats_create() registers the stats agent through\nmlx5_hv_vhca_agent_create(). The helper publishes the agent in\nhv_vhca-\u0026gt;agents[type] under agents_lock and immediately schedules an\nasynchronous control invalidation on the HV VHCA workqueue before\nreturning to mlx5e.\n\nThe asynchronous invalidation invokes the control agent\u0026apos;s invalidate\ncallback, which reads the hypervisor control block and forwards the\ncommand to mlx5e_hv_vhca_stats_control(). That callback may either:\n\n - call cancel_delayed_work_sync(\u0026amp;priv-\u0026gt;stats_agent.work), or\n - call queue_delayed_work(priv-\u0026gt;wq, \u0026amp;sagent-\u0026gt;work, sagent-\u0026gt;delay).\n\nHowever, the delayed_work and priv-\u0026gt;stats_agent.agent are only\ninitialized after mlx5_hv_vhca_agent_create() returns to mlx5e:\n\n agent = mlx5_hv_vhca_agent_create(...); /* publish + invalidate */\n ...\n priv-\u0026gt;stats_agent.agent = agent; /* too late */\n INIT_DELAYED_WORK(\u0026amp;priv-\u0026gt;stats_agent.work, ...); /* too late */\n\nIf the asynchronous control path runs before the two assignments\nabove, it can:\n\n - Operate on an uninitialized delayed_work whose timer.function is\n NULL. queue_delayed_work() calls add_timer() unconditionally, so\n when the timer expires the timer softirq invokes a NULL function\n pointer.\n - Re-initialize the timer later through INIT_DELAYED_WORK() while\n the timer is already enqueued in the timer wheel, corrupting the\n hlist (entry.pprev cleared while the previous bucket node still\n points at this entry).\n - When the worker eventually runs, mlx5e_hv_vhca_stats_work() reads\n sagent-\u0026gt;agent (NULL) and dereferences it inside\n mlx5_hv_vhca_agent_write().\n\nFix this by:\n\n - Initializing priv-\u0026gt;stats_agent.work before invoking\n mlx5_hv_vhca_agent_create(), so the work is always in a valid\n state when the control callback observes it.\n - Adding a struct mlx5_hv_vhca_agent **ctx_update out-parameter\n to mlx5_hv_vhca_agent_create(). The helper writes the agent\n pointer to *ctx_update before publishing into hv_vhca-\u0026gt;agents[]\n and triggering the agents_update flow, so any callback\n subsequently invoked from that flow already sees a valid\n priv-\u0026gt;stats_agent.agent. This avoids having the control\n callback participate in agent initialization.\n\nWhile at it, access priv-\u0026gt;stats_agent.agent with\nREAD_ONCE()/WRITE_ONCE() for the cross-CPU access with the worker, and\nclear priv-\u0026gt;stats_agent.buf on the agent_create() failure path.(CVE-2026-72342)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbridge: stp: Fix a potential use-after-free when deleting a bridge\n\nThe three STP timers are not supposed to be armed while the bridge is\nadministratively down. They are synchronously deactivated when the\nbridge is put administratively down and the various call sites check for\n\u0026apos;IFF_UP\u0026apos; before arming them.\n\nThis check is missing from br_topology_change_detection() and it is\npossible to engineer a situation in which the topology change timer is\narmed while the bridge is administratively down, resulting in a\nuse-after-free [1] when the bridge is deleted.\n\nFix by adding the missing check and for good measures synchronously\nshutdown the three timers when the bridge is deleted.\n\n[1]\nODEBUG: free active (active state 0) object: ffff88811662b9b0 object type: timer_list hint: br_topology_change_timer_expired (net/bridge/br_stp_timer.c:120)\nWARNING: lib/debugobjects.c:629 at debug_print_object+0x1bc/0x450, CPU#9: ip/359(CVE-2026-72389)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nseg6: validate SRH length before reading fixed fields\n\nseg6_validate_srh() reads fixed SRH fields such as srh-\u0026gt;type and\nsrh-\u0026gt;hdrlen before checking that the supplied length covers the fixed\nstruct ipv6_sr_hdr fields.\n\nThe BPF SEG6 encap path reaches this with a BPF program-supplied pointer\nand length: bpf_lwt_push_encap() and the SEG6 local BPF END_B6 and\nEND_B6_ENCAP actions call bpf_push_seg6_encap(), which forwards the\nlength to seg6_validate_srh() with no minimum-size guard. A 2-byte SEG6\nencap header can therefore make the validator read srh-\u0026gt;type at offset 2\nbeyond the caller-supplied buffer.\n\nReject lengths shorter than the fixed SRH at the top of\nseg6_validate_srh(), before any field is read. This fixes the BPF helper\npath and keeps the common validator robust.(CVE-2026-72400)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nice: fix FDIR CTRL VSI resource leak in ice_reset_all_vfs()\n\nResetting all VFs causes resource leak on VFs with FDIR filters\nenabled as CTRL VSIs are only invalidated and not freed. Fix by using\nice_vf_ctrl_vsi_release() instead of ice_vf_ctrl_invalidate_vsi() which\naligns behavior with the ice_reset_vf() function.\n\nReproduction:\n echo 1 \u0026gt; /sys/class/net/$pf/device/sriov_numvfs\n ethtool -N $vf flow-type ether proto 0x9000 action 0\n echo 1 \u0026gt; /sys/class/net/$pf/device/reset(CVE-2026-72425)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: validate selector family and prefixlen during match\n\nsyzbot reported a shift-out-of-bounds in xfrm_selector_match()\ndue to AF_UNSPEC selector with large prefixlen (e.g. 128) matched\nagainst IPv4 flow (when XFRM_STATE_AF_UNSPEC is set).\n\nFix this by:\n\n- Rejecting mismatched families in xfrm_selector_match.\n- Returning false in addr4_match if prefixlen \u0026gt; 32.\n- Returning false in addr_match if prefixlen \u0026gt; 128 (prevents overflow).(CVE-2026-72450)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\napparmor: aa_label_alloc use aa_label_free on alloc failure\n\naa_label_alloc() allocates a secid before allocating or taking the label\nproxy. If the later proxy step fails, the error path only freed the label\nmemory, leaking any resources initialized by aa_label_init().\n\nUse aa_label_free() on the failure path so partially initialized labels\nrelease their secid and other label resources before the backing memory is\nfreed.(CVE-2026-72459)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\napparmor: check label build before no_new_privs test\n\naa_change_profile() builds a replacement label with\nfn_label_build_in_scope() before the no_new_privs subset check. The build\nhelper can fail and return NULL or an ERR_PTR, but the result was passed\nto aa_label_is_unconfined_subset() before the existing IS_ERR_OR_NULL()\ncheck.\n\nReuse the existing target-label build failure handling immediately after\nthe build. This preserves the current audit handling while preventing the\nsubset helper from dereferencing an invalid label.(CVE-2026-72460)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxprtrdma: Repost Receive buffers for malformed replies\n\nrpcrdma_wc_receive() decrements the transport\u0026apos;s Receive count for\nevery completion before it dispatches a successful Receive to\nrpcrdma_reply_handler(). The handler must post a replacement\nReceive WR before returning unless ownership of the rep has moved\nelsewhere, as on the backchannel path.\n\nCommit 2ae50ad68cd7 (\u0026quot;xprtrdma: Close window between waking RPC\nsenders and posting Receives\u0026quot;) moved the Receive refill out of\nrpcrdma_wc_receive(), where it had run ahead of every reply, into\nrpcrdma_reply_handler() so that the responder\u0026apos;s credit grant could\nbe parsed before reposting. The bad-version and short-reply exits\nnever reach that refill: they recycle the rep and return without\ncalling rpcrdma_post_recvs().\n\nA remote peer can therefore drain the client\u0026apos;s posted Receive\nqueue by sending a sustained stream of replies that are shorter\nthan the fixed transport header or that carry an unrecognized\nRPC/RDMA version. Each such reply consumes one posted Receive\nwithout replacing it. Once the queue empties, the peer\u0026apos;s next\nSend finds no posted Receive and the transport stalls until\nreconnect.\n\nRoute both malformed-reply exits through the shared repost tail\nafter recycling the rep, refilling against buf-\u0026gt;rb_credits, the\nmost recent accepted credit grant. Neither exit updates the\ncongestion window, so RPCs admitted under the previous grant\nremain in flight awaiting replies. A smaller refill target would\nlet a stream of malformed replies ratchet the posted Receive count\ndown to the batch floor while the congestion window still admits\nrb_credits RPCs; a burst of valid replies to those RPCs could then\noverrun the posted Receives, and because the client connects with\nrnr_retry_count of zero, a single RNR NAK terminates the\nconnection. Refilling against rb_credits also restores the target\nthat applied to malformed replies before commit 2ae50ad68cd7\n(\u0026quot;xprtrdma: Close window between waking RPC senders and posting\nReceives\u0026quot;) when rpcrdma_post_recvs() computed it from rb_credits\ninternally. rb_credits is at least one from connection\nestablishment onward, so the repost path always keeps Receives\nposted.(CVE-2026-72464)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxprtrdma: Fix bcall rep leak and unbounded peek\n\nrpcrdma_is_bcall() decodes a reply\u0026apos;s first words to decide whether\nthe frame is a backchannel call. Two issues in that decode path\nlet a short or malformed reply leak the receive buffer and drain\nthe Receive queue.\n\nFirst, the speculative peek\n\n p = xdr_inline_decode(xdr, 0);\n /* five p++ reads follow */\n\nasks xdr_inline_decode() for zero bytes, which returns xdr-\u0026gt;p\nwithout consulting xdr-\u0026gt;end. The five subsequent __be32 reads can\nthen walk up to 20 bytes past the wire payload into stale regbuf\ncontents and misclassify the reply as a backchannel call.\n\nSecond, after the post-peek\n\n p = xdr_inline_decode(xdr, 3 * sizeof(*p));\n if (unlikely(!p))\n return true;\n\nthe short-header arm returns true without calling\nrpcrdma_bc_receive_call(). The contract with the caller is that a\ntrue return transfers ownership of rep to the backchannel path:\n\n rpcrdma_reply_handler()\n if (rpcrdma_is_bcall(r_xprt, rep))\n return; /* bare return, skips out_post */\n ...\n out_post:\n rpcrdma_post_recvs(r_xprt, credits + ...);\n\nBecause rpcrdma_bc_receive_call() never ran, no one took rep, but\nrpcrdma_reply_handler still bare-returns past rpcrdma_rep_put()\nand rpcrdma_post_recvs(). The rep, with its persistently\nDMA-mapped receive buffer, is orphaned on rb_all_reps and freed\nonly at transport teardown. This completion reposts nothing, so\nits slot is reclaimed only when a later forward-channel reply\nreaches out_post and rpcrdma_post_recvs() allocates a fresh rep to\nbackfill; absent that traffic the Receive queue drains and the\npeer\u0026apos;s Sends draw RNR NAKs.\n\nFix by consulting xdr-\u0026gt;end after the zero-length peek so the five\n__be32 reads cannot run unless 20 bytes of wire payload remain. A\nbyte-precise comparison against xdr-\u0026gt;end is required because a\nnon-4-aligned receive rounds the stream\u0026apos;s word count up past the\ntrue payload. Also return false from the short-header arm so the\nreply falls through the normal out_norqst cleanup chain\n(rpcrdma_rep_put() plus rpcrdma_post_recvs()).(CVE-2026-72466)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxprtrdma: Decouple req recycling from RPC completion\n\nrl_kref formerly served two distinct lifetimes through a single\nrefcount: it gated when a Reply could wake its RPC task, and it\ngated when an rpcrdma_req could return to its free pool. The\nmarshal path took the Send-side reference only when SGEs needed\nDMA-unmap (sc_unmap_count \u0026gt; 0), which made a Send carrying only\npre-registered buffers an exception: the Reply handler dropped\nrl_kref from 1 to 0 and freed the req while the HCA might still\nbe DMA-reading from its send buffer.\n\nGive rl_kref a narrower job. The RPC layer takes one reference\nwhen slot allocation hands a req out. rpcrdma_prepare_send_sges()\ntakes a Send-side reference unconditionally after WR preparation\nsucceeds. xprt_rdma_free_slot() and xprt_rdma_bc_free_rqst() drop\nthe RPC-layer reference; rpcrdma_sendctx_unmap() drops the\nSend-side reference. The req returns to its free pool only after\nboth owners have signed off.\n\nThe existing kref_init(\u0026amp;req-\u0026gt;rl_kref) call in\nrpcrdma_prepare_send_sges() is removed. Initialization moves to\nthe slot-allocation paths (xprt_rdma_alloc_slot and\nrpcrdma_bc_rqst_get), and the release callback re-arms rl_kref\nbefore the req returns to a free pool. A re-init in the marshal\npath would discard the RPC-layer reference that already exists\non entry.\n\nThree invariants follow:\n\n - Any rpcrdma_req held by an rpc_rqst has rl_kref \u0026gt;= 1.\n xprt_rdma_alloc_slot(), rpcrdma_bc_rqst_get(), and the\n backlog-wake branch in xprt_rdma_alloc_slot() each kref_init\n rl_kref before publishing the req. Without this invariant,\n an RPC task that aborts between slot allocation and marshal\n (gss_refresh failure or signal during call_connect, for\n example) would drive xprt_release() -\u0026gt;\n xprt_rdma_free_slot() -\u0026gt; kref_put against a refcount of\n zero, saturating refcount_t and stranding the slot.\n\n - The Send-side reference is taken only after WR prep\n succeeds. A mapping failure in rpcrdma_prepare_send_sges()\n runs rpcrdma_sendctx_cancel(), which DMA-unmaps the sendctx\n and clears sc_req without touching rl_kref. The sendctx\n ring walks in rpcrdma_sendctx_put_locked() and\n rpcrdma_sendctxs_destroy() skip entries with sc_req == NULL,\n so a burst of -EIO marshal failures cannot hold reqs off\n rb_send_bufs.\n\n - The release callback re-arms rl_kref so the next consumer\n enters with the invariant satisfied.\n\nReplies now complete the RPC directly. rpcrdma_reply_handler()\ncalls rpcrdma_complete_rqst() in place of kref_put on the\nnon-LocalInv branch. The LocalInv branch already completes the\nRPC from frwr_unmap_async() and is unaffected.\n\nBecause Send-side references can now outlive RPC completion,\nconnection teardown drains sendctx entries whose unsignaled\nSends never had a later signaled completion to walk the ring.\nrpcrdma_sendctxs_destroy() walks the active range and runs\nrpcrdma_sendctx_unmap() on each entry with a non-NULL sc_req\nbefore the request buffers are reset, and is moved ahead of\nrpcrdma_reqs_reset() in rpcrdma_xprt_disconnect() so the reqs\nare still in their pre-reset state when the Send-side refs are\nreleased.\n\nThe drain creates a teardown-ordering hazard on the backchannel\npath. With the new lifetime, releasing a bc_prealloc req from\nrpcrdma_req_release() re-adds it to bc_pa_list. The disconnect\nin xprt_rdma_destroy() runs after xprt_destroy_backchannel() has\nalready emptied bc_pa_list, so the drained reqs would otherwise\nleak. xprt_rdma_destroy() now runs xprt_rdma_bc_destroy(xprt, 0)\na second time after the disconnect to reclaim them.(CVE-2026-72473)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npower: supply: core: fix supplied_from allocations\n\nIf dts property power-supplies has multiple values, then accessing to\npsy-\u0026gt;supplied_from[i-1] in __power_supply_populate_supplied_from will\noverrun supplied_from array.(CVE-2026-74271)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntipc: require net admin for TIPCv2 netlink mutators\n\nTIPCv2 registers mutating generic-netlink operations without admin\npermission flags. Generic netlink only checks CAP_NET_ADMIN when an\noperation sets GENL_ADMIN_PERM or GENL_UNS_ADMIN_PERM, so a local\nunprivileged process can currently change TIPC state through commands\nsuch as TIPC_NL_NET_SET, TIPC_NL_KEY_SET, TIPC_NL_KEY_FLUSH, and\nbearer enable/disable.\n\nThe legacy TIPC netlink API already checks netlink_net_capable(...,\nCAP_NET_ADMIN) for administrative commands. Give the TIPCv2 mutators\nthe equivalent generic-netlink gate. Use GENL_UNS_ADMIN_PERM, which\nmaps to the same namespace-aware CAP_NET_ADMIN check that\nnetlink_net_capable() performs, so the behaviour matches the legacy\npath and keeps working for CAP_NET_ADMIN holders in a non-initial user\nnamespace (containers).\n\nA QEMU/KASAN repro run as uid/gid 65534 with zero effective\ncapabilities previously succeeded in changing the network id and node\nidentity, setting and flushing key material, and enabling/disabling a\nUDP bearer. With this patch applied the same operations fail with\n-EPERM.(CVE-2026-74283)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsctp: validate embedded address parameter length\n\nsctp_verify_asconf() and sctp_verify_param() only validate ADD_IP, DEL_IP,\nand SET_PRIMARY parameters against a fixed minimum size of sizeof(struct\nsctp_addip_param) + sizeof(struct sctp_paramhdr). This ensures the outer\nparameter is large enough to contain an embedded address parameter header,\nbut does not verify that the embedded address parameter\u0026apos;s declared length\nfits within the bounds of the outer parameter.\n\nLater, sctp_process_param() and sctp_process_asconf_param() extract the\nembedded address parameter and pass it to af-\u0026gt;from_addr_param(), which uses\nthe address parameter length to parse the variable-length address payload.\nA malformed peer can therefore advertise an embedded address parameter\nlength that exceeds the remaining bytes in the enclosing parameter.\n\nValidate that addr_param-\u0026gt;p.length does not exceed the space available\nafter the sctp_addip_param header before processing the embedded address\nparameter. Reject malformed parameters when the embedded address length\nextends beyond the enclosing parameter bounds.\n\nThis prevents out-of-bounds reads when parsing malformed parameters carried\nin INIT or ASCONF processing paths.(CVE-2026-74287)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Tighten cgroup storage cookie checks for prog arrays\n\nThe fix in commit abad3d0bad72 (\u0026quot;bpf: Fix oob access in cgroup local\nstorage\u0026quot;) is still incomplete. The prog-array compatibility check\ntreats a program with no cgroup storage as compatible with any stored\nstorage cookie. This allows a storage-less program to bridge a tail\ncall chain between an entry program and a storage-using callee even\nthough cgroup local storage at runtime still follows the caller\u0026apos;s\ncontext, that is, A -\u0026gt; B(no storage) -\u0026gt; C(storage) path.\n\nRequiring exact cookie equality would break the legitimate case of a\nstorage-less leaf program being tail called from a storage-using one.\nInstead, only accept a zero storage cookie if the program cannot\nperform tail calls itself. This keeps A -\u0026gt; B(no storage) working\nwhile rejecting the A -\u0026gt; B(no storage) -\u0026gt; C(storage) bridge.(CVE-2026-74305)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/rxe: Copy WQE to local buffer in non-SRQ receive path\n\nFor non-SRQ QPs, the responder reads WQE fields directly from the\nshared queue buffer mapped into userspace. This allows a malicious\nuser to modify fields like num_sge or sge entries while the kernel\nis processing the WQE, leading to out-of-bounds reads in\nrxe_resp_check_length() and copy_data().\n\nIntroduce get_recv_wqe() that validates num_sge and copies the WQE\nto a kernel-local buffer before processing, matching the approach\nalready used for SRQ WQEs in get_srq_wqe(). The srq_wqe buffer is\nreused since SRQ and non-SRQ paths are mutually exclusive per QP.(CVE-2026-74377)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/rxe: Fix TOCTOU heap overflow in get_srq_wqe\n\nget_srq_wqe() reads wqe-\u0026gt;dma.num_sge from the shared receive queue\nbuffer, which is mapped into userspace. It validates num_sge against\nmax_sge, but then re-reads the same field to calculate the memcpy\nsize. A concurrent userspace thread can modify num_sge between\nvalidation and use, causing a heap buffer overflow when copying the\nWQE into qp-\u0026gt;resp.srq_wqe.\n\nRead num_sge into a local variable and use it for both the bounds\ncheck and the size calculation.(CVE-2026-74378)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/srpt: fix integer overflow in immediate data length check\n\nimm_buf-\u0026gt;len is a user-controlled uint32_t received from the network.\nAdding it to imm_data_offset without overflow checking allows a\nmalicious initiator to send len=0xFFFFFFFF, causing req_size to wrap\naround to a small value, bypassing the bounds check, and subsequently\npassing a ~4GB length to sg_init_one().\n\nUse check_add_overflow() to detect wrapping before the comparison.(CVE-2026-74394)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nIB/mlx5: Fix transport-domain rollback and initialize lb mutex earlier\n\nmlx5_ib_alloc_transport_domain() allocates a transport domain and then\nmay fail in mlx5_ib_enable_lb(). In that case, the allocated TD is leaked.\n\nFix this by deallocating the TD when mlx5_ib_enable_lb() returns an\nerror. Also return 0 explicitly in the no-loopback-capability success\nbranch, and move dev-\u0026gt;lb.mutex initialization to mlx5_ib_stage_init_init().(CVE-2026-74397)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: addrconf: bail out of dad_failure when state is no longer POSTDAD\n\naddrconf_dad_failure() transitions ifp-\u0026gt;state from DAD to POSTDAD\nvia addrconf_dad_end(), which drops ifp-\u0026gt;lock on return. The lock\nis re-acquired after net_info_ratelimited(). A concurrent\nipv6_del_addr() can take the lock in that window, set ifp-\u0026gt;state\nto DEAD and run list_del_rcu(\u0026amp;ifp-\u0026gt;if_list).\n\naddrconf_dad_failure() then overwrites DEAD with ERRDAD at errdad:\nand schedules a new dad_work. The work calls ipv6_del_addr()\nagain, hitting the already-poisoned list entry:\n\n general protection fault: 0000 [#1] SMP NOPTI\n CPU: 4 PID: 217 Comm: kworker/4:1\n Workqueue: ipv6_addrconf addrconf_dad_work\n RIP: 0010:ipv6_del_addr+0xe9/0x280\n RAX: dead000000000122\n Call Trace:\n addrconf_dad_stop+0x113/0x140\n addrconf_dad_work+0x28c/0x430\n process_one_work+0x1eb/0x3b0\n worker_thread+0x4d/0x400\n kthread+0x104/0x140\n ret_from_fork+0x35/0x40\n\nFold the addrconf_dad_end() logic into addrconf_dad_failure() under\na single ifp-\u0026gt;lock critical section. The STABLE_PRIVACY branch\ntemporarily drops ifp-\u0026gt;lock around address regeneration, so at\nlock_errdad: verify the state is still POSTDAD before transitioning\nto ERRDAD; bail out otherwise to avoid overwriting a state set by\nanother path while the lock was released.(CVE-2026-74398)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvxlan: Fix potential null-ptr-deref in vxlan_gro_prepare_receive().\n\nudp_tunnel_sock_release() could set sk-\u0026gt;sk_user_data to NULL\nwhile vxlan_gro_prepare_receive() is running.\n\nLet\u0026apos;s check if rcu_dereference_sk_user_data() is NULL after\nskb_gro_remcsum_init().(CVE-2026-74406)",
"id": "OESA-2026-3703",
"modified": "2026-09-05T15:04:07Z",
"published": "2026-09-05T15:04:07Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-3703"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37979"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38736"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43078"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46028"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63912"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-68476"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-68477"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72021"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72049"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72052"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72053"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72054"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72061"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72072"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72129"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72135"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72136"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72157"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72172"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72217"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72221"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72222"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72235"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72282"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72310"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72316"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72317"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72318"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72319"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72330"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72339"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72342"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72389"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72400"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72425"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72450"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72459"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72460"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72464"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72466"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72473"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74271"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74283"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74287"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74305"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74377"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74378"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74394"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74397"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74398"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74406"
}
],
"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-2025-37979",
"CVE-2025-38736",
"CVE-2026-43078",
"CVE-2026-46028",
"CVE-2026-63912",
"CVE-2026-68476",
"CVE-2026-68477",
"CVE-2026-72021",
"CVE-2026-72049",
"CVE-2026-72052",
"CVE-2026-72053",
"CVE-2026-72054",
"CVE-2026-72061",
"CVE-2026-72072",
"CVE-2026-72129",
"CVE-2026-72135",
"CVE-2026-72136",
"CVE-2026-72157",
"CVE-2026-72172",
"CVE-2026-72217",
"CVE-2026-72221",
"CVE-2026-72222",
"CVE-2026-72235",
"CVE-2026-72282",
"CVE-2026-72310",
"CVE-2026-72316",
"CVE-2026-72317",
"CVE-2026-72318",
"CVE-2026-72319",
"CVE-2026-72330",
"CVE-2026-72339",
"CVE-2026-72342",
"CVE-2026-72389",
"CVE-2026-72400",
"CVE-2026-72425",
"CVE-2026-72450",
"CVE-2026-72459",
"CVE-2026-72460",
"CVE-2026-72464",
"CVE-2026-72466",
"CVE-2026-72473",
"CVE-2026-74271",
"CVE-2026-74283",
"CVE-2026-74287",
"CVE-2026-74305",
"CVE-2026-74377",
"CVE-2026-74378",
"CVE-2026-74394",
"CVE-2026-74397",
"CVE-2026-74398",
"CVE-2026-74406"
]
}
OESA-2026-3704 (CVE-2025-71112)
Vulnerability from osv_openeuler – Published: 2026-09-05 15:04 – Updated: 2026-09-05 15:04 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
net: hns3: add VLAN id validation before using
Currently, the VLAN id may be used without validation when receive a VLAN configuration mailbox from VF. The length of vlan_del_fail_bmap is BITS_TO_LONGS(VLAN_N_VID). It may cause out-of-bounds memory access once the VLAN id is bigger than or equal to VLAN_N_VID.
Therefore, VLAN id needs to be checked to ensure it is within the range of VLAN_N_VID.(CVE-2025-71112)
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix string copying in parse_apply_sb_mount_options()
strscpy_pad() can't be used to copy a non-NUL-term string into a NUL-term string of possibly bigger size. Commit 0efc5990bca5 ("string.h: Introduce memtostr() and memtostr_pad()") provides additional information in that regard. So if this happens, the following warning is observed:
strnlen: detected buffer overflow: 65 byte read of buffer size 64 WARNING: CPU: 0 PID: 28655 at lib/string_helpers.c:1032 __fortify_report+0x96/0xc0 lib/string_helpers.c:1032 Modules linked in: CPU: 0 UID: 0 PID: 28655 Comm: syz-executor.3 Not tainted 6.12.54-syzkaller-00144-g5f0270f1ba00 #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:__fortify_report+0x96/0xc0 lib/string_helpers.c:1032 Call Trace: <TASK> __fortify_panic+0x1f/0x30 lib/string_helpers.c:1039 strnlen include/linux/fortify-string.h:235 [inline] sized_strscpy include/linux/fortify-string.h:309 [inline] parse_apply_sb_mount_options fs/ext4/super.c:2504 [inline] __ext4_fill_super fs/ext4/super.c:5261 [inline] ext4_fill_super+0x3c35/0xad00 fs/ext4/super.c:5706 get_tree_bdev_flags+0x387/0x620 fs/super.c:1636 vfs_get_tree+0x93/0x380 fs/super.c:1814 do_new_mount fs/namespace.c:3553 [inline] path_mount+0x6ae/0x1f70 fs/namespace.c:3880 do_mount fs/namespace.c:3893 [inline] __do_sys_mount fs/namespace.c:4103 [inline] __se_sys_mount fs/namespace.c:4080 [inline] __x64_sys_mount+0x280/0x300 fs/namespace.c:4080 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x64/0x140 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x76/0x7e
Since userspace is expected to provide s_mount_opts field to be at most 63 characters long with the ending byte being NUL-term, use a 64-byte buffer which matches the size of s_mount_opts, so that strscpy_pad() does its job properly. Return with error if the user still managed to provide a non-NUL-term string here.
Found by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2025-71123)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/umad: Reject negative data_len in ib_umad_write
ib_umad_write computes data_len from user-controlled count and the MAD header sizes. With a mismatched user MAD header size and RMPP header length, data_len can become negative and reach ib_create_send_mad(). This can make the padding calculation exceed the segment size and trigger an out-of-bounds memset in alloc_send_rmpp_list().
Add an explicit check to reject negative data_len before creating the send buffer.
KASAN splat: [ 211.363464] BUG: KASAN: slab-out-of-bounds in ib_create_send_mad+0xa01/0x11b0 [ 211.364077] Write of size 220 at addr ffff88800c3fa1f8 by task spray_thread/102 [ 211.365867] ib_create_send_mad+0xa01/0x11b0 [ 211.365887] ib_umad_write+0x853/0x1c80(CVE-2026-23243)
In the Linux kernel, the following vulnerability has been resolved:
nvme: fix memory allocation in nvme_pr_read_keys()
nvme_pr_read_keys() takes num_keys from userspace and uses it to calculate the allocation size for rse via struct_size(). The upper limit is PR_KEYS_MAX (64K).
A malicious or buggy userspace can pass a large num_keys value that results in a 4MB allocation attempt at most, causing a warning in the page allocator when the order exceeds MAX_PAGE_ORDER.
To fix this, use kvzalloc() instead of kzalloc().
This bug has the same reasoning and fix with the patch below: https://lore.kernel.org/linux-block/(CVE-2026-23244)
In the Linux kernel, the following vulnerability has been resolved:
media: dvb-core: fix wrong reinitialization of ringbuffer on reopen
dvb_dvr_open() calls dvb_ringbuffer_init() when a new reader opens the DVR device. dvb_ringbuffer_init() calls init_waitqueue_head(), which reinitializes the waitqueue list head to empty.
Since dmxdev->dvr_buffer.queue is a shared waitqueue (all opens of the same DVR device share it), this orphans any existing waitqueue entries from io_uring poll or epoll, leaving them with stale prev/next pointers while the list head is reset to {self, self}.
The waitqueue and spinlock in dvr_buffer are already properly initialized once in dvb_dmxdev_init(). The open path only needs to reset the buffer data pointer, size, and read/write positions.
Replace the dvb_ringbuffer_init() call in dvb_dvr_open() with direct assignment of data/size and a call to dvb_ringbuffer_reset(), which properly resets pread, pwrite, and error with correct memory ordering without touching the waitqueue or spinlock.(CVE-2026-23253)
In the Linux kernel, the following vulnerability has been resolved:
apparmor: fix unprivileged local user can do privileged policy management
An unprivileged local user can load, replace, and remove profiles by opening the apparmorfs interfaces, via a confused deputy attack, by passing the opened fd to a privileged process, and getting the privileged process to write to the interface.
This does require a privileged target that can be manipulated to do the write for the unprivileged process, but once such access is achieved full policy management is possible and all the possible implications that implies: removing confinement, DoS of system or target applications by denying all execution, by-passing the unprivileged user namespace restriction, to exploiting kernel bugs for a local privilege escalation.
The policy management interface can not have its permissions simply changed from 0666 to 0600 because non-root processes need to be able to load policy to different policy namespaces.
Instead ensure the task writing the interface has privileges that are a subset of the task that opened the interface. This is already done via policy for confined processes, but unconfined can delegate access to the opened fd, by-passing the usual policy check.(CVE-2026-23268)
In the Linux kernel, the following vulnerability has been resolved:
perf: Fix __perf_event_overflow() vs perf_remove_from_context() race
Make sure that __perf_event_overflow() runs with IRQs disabled for all possible callchains. Specifically the software events can end up running it with only preemption disabled.
This opens up a race vs perf_event_exit_event() and friends that will go and free various things the overflow path expects to be present, like the BPF program.(CVE-2026-23271)
In the Linux kernel, the following vulnerability has been resolved:
drm/vmwgfx: Return the correct value in vmw_translate_ptr functions
Before the referenced fixes these functions used a lookup function that returned a pointer. This was changed to another lookup function that returned an error code with the pointer becoming an out parameter.
The error path when the lookup failed was not changed to reflect this change and the code continued to return the PTR_ERR of the now uninitialized pointer. This could cause the vmw_translate_ptr functions to return success when they actually failed causing further uninitialized and OOB accesses.(CVE-2026-23317)
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix a UAF issue in bpf_trampoline_link_cgroup_shim
The root cause of this bug is that when 'bpf_link_put' reduces the refcount of 'shim_link->link.link' to zero, the resource is considered released but may still be referenced via 'tr->progs_hlist' in 'cgroup_shim_find'. The actual cleanup of 'tr->progs_hlist' in 'bpf_shim_tramp_link_release' is deferred. During this window, another process can cause a use-after-free via 'bpf_trampoline_link_cgroup_shim'.
Based on Martin KaFai Lau's suggestions, I have created a simple patch.
To fix this: Add an atomic non-zero check in 'bpf_trampoline_link_cgroup_shim'. Only increment the refcount if it is not already zero.
Testing: I verified the fix by adding a delay in 'bpf_shim_tramp_link_release' to make the bug easier to trigger:
static void bpf_shim_tramp_link_release(struct bpf_link link) { / ... */ if (!shim_link->trampoline) return;
- msleep(100); WARN_ON_ONCE(bpf_trampoline_unlink_prog(&shim_link->link, shim_link->trampoline, NULL)); bpf_trampoline_put(shim_link->trampoline); }
Before the patch, running a PoC easily reproduced the crash(almost 100%) with a call trace similar to KaiyanM's report. After the patch, the bug no longer occurs even after millions of iterations.(CVE-2026-23319)
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix stack-out-of-bounds write in devmap
get_upper_ifindexes() iterates over all upper devices and writes their indices into an array without checking bounds.
Also the callers assume that the max number of upper devices is MAX_NEST_DEV and allocate excluded_devices[1+MAX_NEST_DEV] on the stack, but that assumption is not correct and the number of upper devices could be larger than MAX_NEST_DEV (e.g., many macvlans), causing a stack-out-of-bounds write.
Add a max parameter to get_upper_ifindexes() to avoid the issue. When there are too many upper devices, return -EOVERFLOW and abort the redirect.
To reproduce, create more than MAX_NEST_DEV(8) macvlans on a device with an XDP program attached using BPF_F_BROADCAST | BPF_F_EXCLUDE_INGRESS. Then send a packet to the device to trigger the XDP redirect path.(CVE-2026-23359)
In the Linux kernel, the following vulnerability has been resolved:
bpf, arm64: Force 8-byte alignment for JIT buffer to prevent atomic tearing
struct bpf_plt contains a u64 target field. Currently, the BPF JIT allocator requests an alignment of 4 bytes (sizeof(u32)) for the JIT buffer.
Because the base address of the JIT buffer can be 4-byte aligned (e.g., ending in 0x4 or 0xc), the relative padding logic in build_plt() fails to ensure that target lands on an 8-byte boundary.
This leads to two issues: 1. UBSAN reports misaligned-access warnings when dereferencing the structure. 2. More critically, target is updated concurrently via WRITE_ONCE() in bpf_arch_text_poke() while the JIT'd code executes ldr. On arm64, 64-bit loads/stores are only guaranteed to be single-copy atomic if they are 64-bit aligned. A misaligned target risks a torn read, causing the JIT to jump to a corrupted address.
Fix this by increasing the allocation alignment requirement to 8 bytes (sizeof(u64)) in bpf_jit_binary_pack_alloc(). This anchors the base of the JIT buffer to an 8-byte boundary, allowing the relative padding math in build_plt() to correctly align the target field.(CVE-2026-23383)
In the Linux kernel, the following vulnerability has been resolved:
Squashfs: check metadata block offset is within range
Syzkaller reports a "general protection fault in squashfs_copy_data"
This is ultimately caused by a corrupted index look-up table, which produces a negative metadata block offset.
This is subsequently passed to squashfs_copy_data (via squashfs_read_metadata) where the negative offset causes an out of bounds access.
The fix is to check that the offset is within range in squashfs_read_metadata. This will trap this and other cases.(CVE-2026-23388)
In the Linux kernel, the following vulnerability has been resolved:
crypto: af_alg - Fix page reassignment overflow in af_alg_pull_tsgl
When page reassignment was added to af_alg_pull_tsgl the original loop wasn't updated so it may try to reassign one more page than necessary.
Add the check to the reassignment so that this does not happen.
Also update the comment which still refers to the obsolete offset argument.(CVE-2026-43078)
In the Linux kernel, the following vulnerability has been resolved:
crypto: algif_aead - snapshot IV for async AEAD requests
AF_ALG AEAD AIO requests currently use the socket-wide IV buffer during request processing. For async requests, later socket activity can update that shared state before the original request has fully completed, which can lead to inconsistent IV handling.
Snapshot the IV into per-request storage when preparing the AEAD request, so in-flight operations no longer depend on mutable socket state.(CVE-2026-46028)
In the Linux kernel, the following vulnerability has been resolved:
sched/fair: Clear rel_deadline when initializing forked entities
A yield-triggered crash can happen when a newly forked sched_entity enters the fair class with se->rel_deadline unexpectedly set.
The failing sequence is:
- A task is forked while se->rel_deadline is still set.
- __sched_fork() initializes vruntime, vlag and other sched_entity state, but does not clear rel_deadline.
- On the first enqueue, enqueue_entity() calls place_entity().
- Because se->rel_deadline is set, place_entity() treats se->deadline as a relative deadline and converts it to an absolute deadline by adding the current vruntime.
- However, the forked entity's deadline is not a valid inherited relative deadline for this new scheduling instance, so the conversion produces an abnormally large deadline.
- If the task later calls sched_yield(), yield_task_fair() advances se->vruntime to se->deadline.
- The inflated vruntime is then used by the following enqueue path, where the vruntime-derived key can overflow when multiplied by the entity weight.
- This corrupts cfs_rq->sum_w_vruntime, breaks EEVDF eligibility calculation, and can eventually make all entities appear ineligible. pick_next_entity() may then return NULL unexpectedly, leading to a later NULL dereference.
A captured trace shows the effect clearly. Before yield, the entity's vruntime was around:
9834017729983308
After yield_task_fair() executed:
se->vruntime = se->deadline
the vruntime jumped to:
19668035460670230
and the deadline was later advanced further to:
19668035463470230
This shows that the deadline had already become abnormally large before yield_task_fair() copied it into vruntime.
rel_deadline is only meaningful when se->deadline really carries a relative deadline that still needs to be placed against vruntime. A freshly forked sched_entity should not inherit or retain this state. Clear se->rel_deadline in __sched_fork(), together with the other sched_entity runtime state, so that the first enqueue does not interpret the new entity's deadline as a stale relative deadline.(CVE-2026-52980)
In the Linux kernel, the following vulnerability has been resolved:
crypto: hisilicon/sec2 - prevent req used-after-free for sec
During packet transmission, if the system is under heavy load, the hardware might complete processing the packet and free the request memory (req) before the transmission function finishes. If the software subsequently accesses this req, a use-after-free error will occur. The qp_ctx memory exists throughout the packet sending process, so replace the req with the qp_ctx.(CVE-2026-53055)
In the Linux kernel, the following vulnerability has been resolved:
sctp: validate cached peer INIT chunk length in COOKIE_ECHO processing
When a listening SCTP server processes a COOKIE_ECHO chunk, the cached peer INIT chunk embedded after the cookie is parsed and its parameters are later walked by sctp_process_init() using sctp_walk_params().
However, the chunk header length of this cached INIT chunk was not validated against the remaining buffer in the COOKIE_ECHO payload. If the length field is inflated, the parameter walk can run beyond the actual received data, leading to out-of-bounds reads and potential memory corruption during later parameter handling (e.g. STATE_COOKIE processing and kmemdup() copies).
Add a bounds check in sctp_unpack_cookie() to ensure the cached INIT chunk length does not exceed the available data in the COOKIE_ECHO buffer before it is used.(CVE-2026-53246)
In the Linux kernel, the following vulnerability has been resolved:
serial: 8250_dw: unregister 8250 port if clk_notifier_register() fails
dw8250_probe() registers the 8250 port via serial8250_register_8250_port() and then, if the device has a clock, registers a clock notifier. If clk_notifier_register() fails, probe returns the error but leaves the 8250 port registered. The matching serial8250_unregister_port() lives in dw8250_remove(), which is not called when probe fails, so the port slot stays occupied until the device is rebound or the system is rebooted. The devm-allocated driver data is freed while the port still references it (via the saved private_data and serial_in/serial_out callbacks), so any access to that port slot before a rebind is a use-after-free hazard.
Unregister the port on the clk_notifier_register() error path.(CVE-2026-53384)
In the Linux kernel, the following vulnerability has been resolved:
pNFS: Fix use-after-free in pnfs_update_layout()
When hitting the NFS_LAYOUT_RETURN branch in pnfs_update_layout(), the code calls pnfs_prepare_to_retry_layoutget(lo). If it succeeds, pnfs_put_layout_hdr(lo) is called before trace_pnfs_update_layout(), which still references 'lo'. This results in a use-after-free when the tracepoint accesses lo's fields.
Fix this by moving the tracepoint call before pnfs_put_layout_hdr(lo).(CVE-2026-63800)
In the Linux kernel, the following vulnerability has been resolved:
net: skmsg: preserve sg.copy across SG transforms
The sk_msg sg.copy bitmap is part of the scatterlist entry ownership state. A set bit tells sk_msg_compute_data_pointers() not to expose the entry through writable BPF ctx->data. This protects entries backed by pages that are not private to the sk_msg, such as splice-backed file page-cache pages.
Several sk_msg transform paths move, copy, split, or compact msg->sg.data[] entries without moving the matching sg.copy bit. This can make an externally backed entry arrive at a new slot with a clear copy bit. A later SK_MSG verdict can then expose sg_virt(sge) as writable ctx->data and BPF stores can modify the original page cache.
Keep sg.copy synchronized with sg.data[] whenever entries are transferred, shifted, split, or copied into a new sk_msg. Clear the bit when an entry is replaced by a newly allocated private page or freed. This covers the BPF pull/push/pop helpers, sk_msg_shift_left/right(), sk_msg_xfer(), and tls_split_open_record(), including the partial tail entry created during TLS open-record splitting.(CVE-2026-63830)
In the Linux kernel, the following vulnerability has been resolved:
scsi: target: iscsi: Validate CHAP_R length before base64 decode
chap_server_compute_hash() allocates client_digest as kzalloc(chap->digest_size) and then, for BASE64-encoded responses, passes chap_r directly to chap_base64_decode() without checking whether the input length could produce more than digest_size bytes of output.
chap_base64_decode() writes to the destination unconditionally as long as there is input to consume. With MAX_RESPONSE_LENGTH set to 128 and the "0b" prefix stripped by extract_param(), up to 127 base64 characters can reach the decoder. 127 characters decode to 95 bytes. For SHA-256 (digest_size=32) this overflows client_digest by 63 bytes; for MD5 (digest_size=16) the overflow is 79 bytes.
The length check at line 344 fires after the write has already happened.
The HEX branch in the same switch statement already validates the length up front. Apply the same approach to the BASE64 branch: strip trailing base64 padding characters, then reject any input whose data length exceeds DIV_ROUND_UP(digest_size * 4, 3) before calling the decoder.
Stripping trailing '=' before the comparison handles both padded and unpadded encodings. chap_base64_decode() already returns early on '=', so the full original string is still passed to the decoder unchanged.
The mutual CHAP path decodes CHAP_C into initiatorchg_binhex, which is kzalloc(CHAP_CHALLENGE_STR_LEN). extract_param() caps initiatorchg at CHAP_CHALLENGE_STR_LEN characters, so at most CHAP_CHALLENGE_STR_LEN-1 base64 characters reach the decoder. The maximum decoded size, DIV_ROUND_UP((CHAP_CHALLENGE_STR_LEN-1) * 3, 4), is less than CHAP_CHALLENGE_STR_LEN, so no overflow is possible there. A comment is added at the call site to document this.(CVE-2026-63886)
In the Linux kernel, the following vulnerability has been resolved:
scsi: target: iscsi: Bound iscsi_encode_text_output() appends to rsp_buf
iscsi_encode_text_output() concatenates "key=value\0" records into login->rsp_buf, an 8192-byte kzalloc(MAX_KEY_VALUE_PAIRS) buffer allocated in iscsit_alloc_login_setup_buffer(). The three sprintf() call sites in this function (lines 1398, 1411, 1424 in v7.1-rc2) never check the remaining buffer capacity:
*length += sprintf(output_buf, "%s=%s", er->key, er->value);
*length += 1;
output_buf = textbuf + *length;
The 8192-byte ceiling at iscsi_target_check_login_request() bounds the input Login PDU payload, but a single PDU can carry up to 2048 minimal four-byte "a=b\0" pairs, each unknown key expanding to a 16-byte "a=NotUnderstood\0" output record via iscsi_add_notunderstood_response(). 2048 * 16 = 32 KiB of output into an 8 KiB buffer, producing a ~24 KiB heap overrun in the kmalloc-8k slab.
The fix introduces a static iscsi_encode_text_record() helper that uses snprintf() with a per-call bounds check against the remaining buffer, and threads a u32 textbuf_size parameter through iscsi_encode_text_output(). Both call sites in iscsi_target_handle_csg_zero() (PHASE_SECURITY) and iscsi_target_handle_csg_one() (PHASE_OPERATIONAL) pass MAX_KEY_VALUE_PAIRS. On overflow the encoder logs the condition, calls iscsi_release_extra_responses() to drop queued records, and returns -1; both caller sites now emit ISCSI_STATUS_CLS_INITIATOR_ERR / ISCSI_LOGIN_STATUS_INIT_ERR via iscsit_tx_login_rsp() before returning, so the initiator sees an explicit failed-login response rather than a silent connection drop. (Prior to this patch only the PHASE_OPERATIONAL caller did that; the PHASE_SECURITY caller is converted to the same shape.)(CVE-2026-63887)
In the Linux kernel, the following vulnerability has been resolved:
scsi: target: iscsi: Fix CRC overread and double-free in iscsit_handle_text_cmd()
Two latent bugs in the Text-phase handler, both present since the original LIO integration in commit e48354ce078c ("iscsi-target: Add iSCSI fabric support for target v4.1"):
1) DataDigest CRC buffer overread (4 bytes past text_in).
text_in is kzalloc()'d at ALIGN(payload_length, 4). rx_size is then incremented by ISCSI_CRC_LEN to make room for the received DataDigest in the iovec, but the same (now-bumped) rx_size is passed as the buffer length to iscsit_crc_buf():
if (conn->conn_ops->DataDigest) {
...
rx_size += ISCSI_CRC_LEN;
}
...
if (conn->conn_ops->DataDigest) {
data_crc = iscsit_crc_buf(text_in, rx_size, 0, NULL);
iscsit_crc_buf() walks rx_size bytes of text_in with crc32c(), so when DataDigest is negotiated it reads 4 bytes past the end of the text_in allocation. KASAN reproduces this directly on the unpatched mainline tree as slab-out-of-bounds in crc32c() called from the Text PDU path. The OOB bytes feed crc32c() and are then compared against the initiator-supplied checksum, so the value does not flow back to the attacker, but the kernel does read past the buffer on every Text PDU with DataDigest=CRC32C.
Fix by passing the actual padded payload length (ALIGN(payload_length, 4)) that was used for the kzalloc().
2) Stale cmd->text_in_ptr re-free (double-free) on ERL>0 bad DataDigest drop.
On DataDigest mismatch with ErrorRecoveryLevel > 0 the handler silently drops the PDU and lets the initiator plug the CmdSN gap:
kfree(text_in);
return 0;
cmd->text_in_ptr still points at the freed buffer. The next Text Request on the same ITT re-enters iscsit_setup_text_cmd(), which unconditionally does
kfree(cmd->text_in_ptr);
cmd->text_in_ptr = NULL;
freeing the same pointer a second time. Session teardown via iscsit_release_cmd() has the same shape and hits the same double-free if the connection is dropped before a second Text Request arrives.
On an unmodified mainline tree the bug-1 CRC overread fires first on the initial valid Text Request and perturbs the subsequent state, so #4 was isolated by building a kernel with only the bug-1 hunk of this patch applied plus temporary printk() observability around the three relevant kfree() sites. The observability prints are not part of this patch. On that build, a three-PDU Text Request sequence after login produces two back-to-back splats:
BUG: KASAN: double-free in iscsit_setup_text_cmd+0x??
BUG: KASAN: double-free in iscsit_release_cmd+0x??
showing the same pointer freed in the ERL>0 drop path and again in iscsit_setup_text_cmd() (next Text Request on the same ITT) and once more in iscsit_release_cmd() (session teardown). On distro kernels with CONFIG_SLAB_FREELIST_HARDENED=y (default) the double-free becomes a remote kernel BUG(); on non-hardened kernels it corrupts the slab freelist.
Fix by clearing cmd->text_in_ptr after the kfree() in the ERL>0 drop path. With both hunks applied #4 is directly observable on the stock tree without observability printks; fixing bug-1 alone would mask #4 less, not more, so the hunks are submitted together.
Both fixes are one-liners. The Text PDU state machine is unchanged and the wire protocol is unaffected.(CVE-2026-63888)
In the Linux kernel, the following vulnerability has been resolved:
scsi: scsi_transport_fc: Widen FPIN pname walker counter to u32
An adjacent Fibre Channel fabric actor that can deliver an FPIN ELS frame to an lpfc or qla2xxx Linux initiator can trigger a non-return in the generic FC transport. This is not a local userspace or IP network path; the attacker must be able to inject fabric traffic, for example as a compromised switch or fabric controller, or as a same-zone N_Port on a fabric that permits source spoofing.
The Link-Integrity and Peer-Congestion FPIN walkers used a u8 loop counter against the 32-bit on-wire pname_count field, and did not bound pname_count by the descriptor body already validated by the TLV walker. A pname_count of 256 therefore wraps the counter and keeps the loop condition true indefinitely.
Factor the shared pname_list[] walk into one helper, widen the counter to u32, and clamp pname_count against the entries that fit in the descriptor body before iterating.(CVE-2026-63889)
In the Linux kernel, the following vulnerability has been resolved:
thunderbolt: property: Cap recursion depth in __tb_property_parse_dir()
A DIRECTORY entry's value field is used as the dir_offset for a recursive call into __tb_property_parse_dir() with no depth counter. A crafted peer that chains DIRECTORY entries into a back-reference loop drives the parser until the kernel stack is exhausted and the guard page fires. Any untrusted XDomain peer (cable, dock, in-line inspector, adjacent host) that reaches the PROPERTIES_REQUEST control-plane exchange can trigger this without authentication.
Thread a depth counter through tb_property_parse() and __tb_property_parse_dir(), and reject blocks that exceed TB_PROPERTY_MAX_DEPTH = 8. That is comfortably larger than any observed legitimate XDomain layout.
Operators who do not need XDomain host-to-host discovery can disable the path entirely with thunderbolt.xdomain=0 on the kernel command line.(CVE-2026-63891)
In the Linux kernel, the following vulnerability has been resolved:
USB: serial: mct_u232: fix memory corruption with small endpoint
The driver overrides the maximum transfer size for a specific device which only accepts 16 byte packets for its 32 byte bulk-out endpoint.
Make sure to never increase the maximum transfer size to prevent slab corruption should a malicious device report a smaller endpoint max packet size than expected.(CVE-2026-63898)
In the Linux kernel, the following vulnerability has been resolved:
USB: serial: mxuport: fix memory corruption with small endpoint
Make sure that the bulk-out endpoint max packet size is at least eight bytes to avoid user-controlled slab corruption should a malicious device report a smaller size.(CVE-2026-63899)
In the Linux kernel, the following vulnerability has been resolved:
USB: serial: digi_acceleport: fix memory corruption with small endpoints
Add the missing bulk-out buffer size sanity checks to avoid out-of-bounds memory accesses or slab corruption should a malicious device report smaller buffers than expected.(CVE-2026-63901)
In the Linux kernel, the following vulnerability has been resolved:
xfrm: esp: restore combined single-frag length gate
The ESP out-of-place fast path appends the trailer in esp_output_head() before esp_output_tail() allocates the destination page frag. The head-side gate currently checks skb->data_len and tailen separately, but the tail code allocates a single destination frag from the combined post-trailer skb->data_len.
Reject the page-frag fast path when the combined aligned length exceeds a page. Otherwise skb_page_frag_refill() may fall back to a single page while the destination sg still spans the combined skb->data_len.
Restore this combined-length page gate for both IPv4 and IPv6.(CVE-2026-63912)
In the Linux kernel, the following vulnerability has been resolved:
ip6: vti: Use ip6_tnl.net in vti6_changelink().
ip netns add ns1 ip netns add ns2 ip -n ns1 link add vti6_test type vti6 remote ::1 local ::2 key 7 ip -n ns1 link set vti6_test netns ns2 ip -n ns2 link set vti6_test type vti6 remote ::3 local ::4 key 9 ip netns del ns2 ip netns del ns1 [ 132.495484] ------------[ cut here ]------------ [ 132.497609] kernel BUG at net/core/dev.c:12376!
Commit 61220ab34948 ("vti6: Enable namespace changing") dropped NETIF_F_NETNS_LOCAL from vti6 devices. A vti6 tunnel can then move through IFLA_NET_NS_FD. After the move dev_net(dev) points at the new netns while t->net stays at the creation netns.
vti6_changelink() and vti6_update() still use dev_net(dev) and dev_net(t->dev). They unlink from one per netns hash and relink into another. The creation netns is left with a stale entry. cleanup_net() of that netns later walks freed memory.
Reachable from an unprivileged user namespace (unshare --user --map-root-user --net). Cross tenant scope on container hosts.(CVE-2026-63917)
In the Linux kernel, the following vulnerability has been resolved:
xfrm: input: hold netns during deferred transport reinjection
Transport-mode reinjection stores a struct net pointer in skb->cb and uses it later from xfrm_trans_reinject(). That pointer must stay valid until the deferred callback runs.
Take a netns reference when queueing deferred reinjection work and drop it after the callback completes. Use maybe_get_net() so the queueing path does not revive a namespace that is already being torn down.
This keeps the existing workqueue design and fixes the netns lifetime handling in one place for all users of xfrm_trans_queue_net().(CVE-2026-63919)
In the Linux kernel, ip6_datagram_recv_specific_ctl() builds IPV6_{HOPOPTS,DSTOPTS,RTHDR} cmsgs (and their IPV6_2292* legacy counterparts) by trusting the on-wire hdrlen byte (ptr[1]) when computing the put_cmsg() length. The length was validated only at parse time (ipv6_parse_hopopts(), etc.). An nftables payload-write expression can rewrite hdrlen after parsing and before the skb reaches recvmsg; the write itself is in-bounds but put_cmsg() then reads up to ((hdrlen+1) << 3) = 2040 bytes from an 8-byte header. nftables is reachable from an unprivileged user namespace, so this is an unprivileged slab-out-of-bounds read.(CVE-2026-63920)
In the Linux kernel, the following vulnerability has been resolved:
ip6: vti: Use ip6_tnl.net in vti6_siocdevprivate().
After patch 1/2 in this series, vti6_update() unlinks and relinks the tunnel through t->net. vti6_siocdevprivate() still uses dev_net(dev) for the collision lookup. For a tunnel moved through IFLA_NET_NS_FD, dev_net(dev) is the new netns, not t->net.
SIOCCHGTUNNEL on a migrated tunnel then runs:
net = dev_net(dev) / migrated netns / t = vti6_locate(net, &p1, false) / misses target in t->net / ... t = netdev_priv(dev) vti6_update(t, &p1, false) / mutates t->net's hash /
A caller in the migrated netns picks params that match a tunnel in the creation netns. The lookup in dev_net(dev) finds nothing. vti6_update() prepends the migrated tunnel at the head of the creation netns hash bucket for those params. Later lookups in the creation netns resolve to the migrated device. xfrm receive delivers the matched packets through a device the caller controls.
Reachable from an unprivileged user namespace (unshare --user --map-root-user --net). Cross tenant scope on container hosts.
Switch the SIOCCHGTUNNEL path on a non fallback device to use t->net for the lookup. The lookup now matches the netns vti6_update() operates on.
Also add ns_capable(self->net->user_ns, CAP_NET_ADMIN) before the lookup. The check at the top of the case is against dev_net(dev)->user_ns, which after migration is the attacker's netns. A caller there can pick params absent from self->net, the lookup returns NULL, t becomes self, and vti6_update() inserts the device into the creation netns hash. The new check requires CAP_NET_ADMIN in the creation netns user_ns too.
SIOCADDTUNNEL and SIOCCHGTUNNEL on the fallback device keep dev_net(dev), which equals init_net there.(CVE-2026-63921)
In the Linux kernel, the following vulnerability has been resolved:
ipv6: exthdrs: refresh nh pointer after ipv6_hop_jumbo()
ipv6_hop_jumbo() calls pskb_trim_rcsum(), which can change skb pointers. Let's recompute nh pointer to make sure any change won't mess things up.(CVE-2026-63924)
In the Linux kernel, the following vulnerability has been resolved:
bpf: sockmap: fix tail fragment offset in bpf_msg_push_data
When bpf_msg_push_data() inserts data in the middle of a scatterlist entry, it splits the original entry into a left fragment and a right fragment.
The right fragment offset is page-local, but the code advances it with
start, which is the message-global insertion point. For inserts into a
non-first SG entry, this over-advances the offset and leaves the split
layout inconsistent.
Advance the right fragment offset by the fragment-local delta,
start - offset, which matches the length removed from the front of the
original entry.(CVE-2026-63926)
In the Linux kernel, the following vulnerability has been resolved:
USB: serial: omninet: fix memory corruption with small endpoint
Make sure that the bulk-out buffers are at least as large as the hardcoded transfer size to avoid user-controlled slab corruption should a malicious device report a smaller endpoint max packet size than expected.(CVE-2026-63928)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_sync: fix UAF in hci_le_create_cis_sync
hci_le_create_cis_sync() dereferences conn->conn_timeout after releasing both rcu_read_lock() and hci_dev_lock(hdev). The conn pointer was obtained from an RCU-protected iteration over hdev->conn_hash.list and is not valid once these locks are dropped. A concurrent disconnect can free the hci_conn between the unlock and the dereference, causing a use-after-free read.
The cancellation mechanism in hci_conn_del() cannot prevent this because hci_le_create_cis_pending() queues hci_create_cis_sync with data=NULL:
hci_cmd_sync_queue(hdev, hci_create_cis_sync, NULL, NULL);
While hci_conn_del() dequeues with data=conn:
hci_cmd_sync_dequeue(hdev, NULL, conn, NULL);
Since NULL != conn, the lookup in _hci_cmd_sync_lookup_entry() never matches, and the pending work item is not cancelled.
Fix this by saving conn->conn_timeout into a local variable while the locks are still held, so the stale conn pointer is never dereferenced after unlock.
This is the same class of bug as the one fixed by commit 035c25007c9e ("Bluetooth: hci_sync: Fix UAF on le_read_features_complete") which addressed the identical pattern in a different function.
This vulnerability was identified using 0sec.ai, an open-source automated security auditing platform (https://github.com/0sec-labs).(CVE-2026-63944)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: ISO: serialize iso_sock_clear_timer with socket lock
iso_sock_close() calls iso_sock_clear_timer() before acquiring lock_sock(sk).
iso_sock_clear_timer() reads iso_pi(sk)->conn twice without the socket lock held:
if (!iso_pi(sk)->conn)
return;
cancel_delayed_work(&iso_pi(sk)->conn->timeout_work);
Concurrently, iso_conn_del() executes under lock_sock(sk) and calls iso_chan_del(), which sets iso_pi(sk)->conn to NULL and may result in the final reference to the connection being dropped:
CPU0 CPU1
---- ----
iso_sock_clear_timer()
if (conn != NULL) ... lock_sock(sk)
iso_chan_del()
iso_pi(sk)->conn = NULL
cancel_delayed_work(conn) /* NULL deref or UAF */
iso_pi(sk)->conn is not stable across the unlock window, causing a NULL pointer dereference or use-after-free.
Serialize iso_sock_clear_timer() with the socket lock by moving it inside lock_sock()/release_sock(), matching the pattern used in iso_conn_del() and all other call sites.(CVE-2026-63945)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: ISO: fix UAF in iso_recv_frame
iso_recv_frame reads conn->sk under iso_conn_lock but releases the lock before using sk, with no reference held. A concurrent iso_sock_kill() can free sk in that window, causing use-after-free on sk->sk_state and sock_queue_rcv_skb().
Fix by replacing the bare pointer read with iso_sock_hold(conn), which calls sock_hold() while the spinlock is held, atomically elevating the refcount before the lock drops. Add a drop_put label so sock_put() is called on all exit paths where the hold succeeded.(CVE-2026-63946)
In the Linux kernel, the following vulnerability has been resolved:
memfd: deny writeable mappings when implying SEAL_WRITE
When SEAL_EXEC is added, SEAL_WRITE is implied to make W^X. But the implied seal is set after the check that makes sure the memfd can not have any writable mappings. This means one can use SEAL_EXEC to apply SEAL_WRITE while having writeable mappings.
This breaks the contract that SEAL_WRITE provides and can be used by an attacker to pass a memfd that appears to be write sealed but can still be modified arbitrarily.
Fix this by adding the implied seals before the call for mapping_deny_writable() is done.(CVE-2026-63952)
In the Linux kernel, the following vulnerability has been resolved:
USB: serial: cypress_m8: fix memory corruption with small endpoint
Make sure that the interrupt-out endpoint max packet size is at least eight bytes to avoid user-controlled slab corruption or NULL-pointer dereference should a malicious device report a smaller size.(CVE-2026-63956)
In the Linux kernel, the following vulnerability has been resolved:
ipv6: fix possible infinite loop in fib6_select_path()
Found while auditing the same pattern Sashiko reported in rt6_fill_node() [1]. Apply the same fix as commit f8d8ce1b515a ("ipv6: fix possible infinite loop in fib6_info_uses_dev()").
Writers holding tb6_lock can list_del_rcu(&first->fib6_siblings) without waiting for RCU readers; first->fib6_siblings.next then still points into the old ring and this softirq-side walker never reaches &first->fib6_siblings as its terminator. fib6_purge_rt() always WRITE_ONCE()s first->fib6_nsiblings to 0 before list_del_rcu(), so an inside-loop check is a reliable detach signal.
[1] https://sashiko.dev/#/patchset/20260526020227.4857-1-jiayuan.chen%40linux.dev(CVE-2026-63968)
In the Linux kernel, the following vulnerability has been resolved:
sctp: fix race between sctp_wait_for_connect and peeloff
sctp_wait_for_connect() drops and re-acquires the socket lock while waiting for the association to reach ESTABLISHED state. During this window, another thread can peeloff the association to a new socket via getsockopt(SCTP_SOCKOPT_PEELOFF), changing asoc->base.sk. After re-acquiring the old socket lock, sctp_wait_for_connect() returns success without noticing the migration — the caller then accesses the association under the wrong lock in sctp_datamsg_from_user().
Add the same sk != asoc->base.sk check that sctp_wait_for_sndbuf() already has, returning an error if the association was migrated while we slept.(CVE-2026-63971)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_sync: Set HCI_CMD_DRAIN_WORKQUEUE during device close
Since hci_dev_close_sync() can now be called during the reset path, we should also set HCI_CMD_DRAIN_WORKQUEUE. This avoids queuing timeouts while the hdev workqueue is being drained.(CVE-2026-63974)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Fix possible crash on l2cap_ecred_conn_rsp
If dcid is received for an already-assigned destination CID the spec requires that both channels to be discarded, but calling l2cap_chan_del may invalidate the tmp cursor created by list_for_each_entry_safe and in fact it is the wrong procedure as the chan->dcid may be assigned previously it really needs to be disconnected.
Calling l2cap_chan_clone directly may still lead to l2cap_chan_del so instead schedule l2cap_chan_timeout with delay 0 to close the channel asynchronously.(CVE-2026-63975)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: l2cap: clear chan->ident on ECRED reconfiguration success
l2cap_ecred_reconf_rsp() returns early on success without clearing chan->ident. Every other L2CAP response handler (l2cap_ecred_conn_rsp, l2cap_le_connect_rsp, l2cap_config_rsp) clears chan->ident after a successful transaction to prevent the channel from matching subsequent responses with the recycled ident value.
A remote attacker that completed a reconfiguration as the peer can replay a failure response with the stale ident, causing the kernel to match and destroy the already-established channel via l2cap_chan_del(chan, ECONNRESET).
Clear chan->ident for all matching channels on success, and harden the failure path by using l2cap_chan_hold_unless_zero() consistent with other L2CAP handlers (l2cap_le_command_rej, __l2cap_get_chan_by_ident).(CVE-2026-63976)
In the Linux kernel, the following vulnerability has been resolved:
ipv6: rpl: fix hdrlen overflow in ipv6_rpl_srh_decompress()
ipv6_rpl_srh_decompress() computes:
outhdr->hdrlen = (((n + 1) * sizeof(struct in6_addr)) >> 3);
hdrlen is __u8. For n >= 127 the result exceeds 255 and silently truncates. With n=127 (cmpri=15, cmpre=15, pad=0, hdrlen=16):
(128 * 16) >> 3 = 256, truncated to 0 as __u8
The caller in ipv6_rpl_srh_rcv() then places the compressed header at buf + ((ohdr->hdrlen + 1) << 3). With hdrlen=0 this is buf + 8, but the decompressed region occupies buf[0..2055] (8-byte header plus 128 full addresses). The compressed header overlaps the decompressed data, and ipv6_rpl_srh_compress() writes into this overlap, corrupting the routing header of the forwarded packet.
The existing guard at exthdrs.c:546 checks (n + 1) > 255, which prevents n+1 from overflowing unsigned char (the segments_left field), but does not prevent the computed hdrlen from overflowing __u8. n=127 passes because 128 <= 255, yet hdrlen=256 does not fit.
Tighten the bound to (n + 1) > 127. This caps n at 126, giving hdrlen = (127 * 16) >> 3 = 254, which fits in __u8. The compressed header then lands at buf + ((254 + 1) << 3) = buf + 2040, exactly past the decompressed region (buf[0..2039]). No overlap. 127 segments is well beyond any realistic RPL deployment.(CVE-2026-63984)
In the Linux kernel, the following vulnerability has been resolved:
ethtool: eeprom: add more safeties to EEPROM Netlink fallback
The Netlink fallback path for reading module EEPROM (fallback_set_params()) validates that offset < eeprom_len, but does not check that offset + length stays within eeprom_len. The ioctl equivalent (ethtool_get_any_eeprom() in ioctl.c) has always enforced both bounds:
if (eeprom.offset + eeprom.len > total_len) return -EINVAL;
This could lead to surprises in both drivers and device FW. Add the missing offset + length validation to fallback_set_params(), mirroring the ioctl.
Similarly - ethtool core in general, and ethtool_get_any_eeprom() in particular tries to zero-init all buffers passed to the drivers to avoid any extra work of zeroing things out. eeprom_fallback() uses a plain kmalloc(), change it to zalloc.(CVE-2026-63985)
In the Linux kernel, the following vulnerability has been resolved:
tunnels: do not assume transport header in iptunnel_pmtud_check_icmp()
In some cases, iptunnel_pmtud_check_icmp() can be called while skb transport header is not set.
This triggers an out-of-bound access, because (typeof(skb->transport_header))~0U is 65535.
Access the icmp header based on IPv4 network header, after making sure icmp->type is present in skb linear part.
Note that iptunnel_pmtud_check_icmpv6()) is fine.(CVE-2026-63992)
In the Linux kernel, the following vulnerability has been resolved:
vxlan: do not reuse cached ip_hdr() value after skb_tunnel_check_pmtu()
skb_tunnel_check_pmtu() can change skb->head.
Reusing old_iph afer skb_tunnel_check_pmtu() can cause an UAF.
Use instead ip_hdr(skb) as done in drivers/net/bareudp.c and drivers/net/geneve.c.
Found by Sashiko.(CVE-2026-63993)
In the Linux kernel, the following vulnerability has been resolved:
tunnels: load network headers after skb_cow() in iptunnel_pmtud_build_icmpv6
Sashiko found that iptunnel_pmtud_build_icmp() and iptunnel_pmtud_build_icmpv6() were caching ip_hdr() and ipv6_hdr() before an skb_cow() call which can reallocate skb->head.
Fix this possible UAF by initializing the local variables after the skb_cow() call.
Remove skb_reset_network_header() calls which were not needed.(CVE-2026-63994)
In the Linux kernel, the following vulnerability has been resolved:
ipv4: free net->ipv4.sysctl_local_reserved_ports after unregister_net_sysctl_table()
ipv4_sysctl_exit_net() is currently freeing net->ipv4.sysctl_local_reserved_ports too soon.
Only after unregister_net_sysctl_table() we can be sure no threads can possibly use the sysctls, including /proc/sys/net/ipv4/ip_local_reserved_ports.(CVE-2026-64002)
In the Linux kernel, the following vulnerability has been resolved:
scsi: core: Run queues for all non-SDEV_DEL devices from scsi_run_host_queues
While a SCSI host is in a recovery state, scsi_mq_requeue_cmd() will not set the requeue list for a requeued command to be kicked in the future. The expectation is a call to scsi_run_host_queues() will kick all SCSI devices once the recovery state is cleared.
However, scsi_run_host_queues() uses shost_for_each_device() which uses scsi_device_get() and so will ignore devices in a partially removed state like SDEV_CANCEL. But these devices may also have requeued requests, leaving their requests stuck from not being kicked and causing the removal process of the device to hang.
scsi_run_host_queues() needs to run against more devices than the macro shost_for_each_device() allows. Instead of using the too limiting scsi_device_get() state checks, only ignore devices in SDEV_DEL state or when unable to acquire a reference. Attempt to run the queues for all other devices when scsi_run_host_queues() is called.(CVE-2026-64003)
In the Linux kernel, the following vulnerability has been resolved:
security/keys: fix missed RCU read section on lookup
Nicholas Carlini reports that the keyring code calls assoc_array_find() in find_key_to_update() without holding the RCU read lock, while the assoc_array_gc() code really is designed around removing the node from the tree and then freeing it after an RCU grace-period.
The regular key handling doesn't see this because holding the keyring semaphore hides any lifetime issues, but the persistent key handling uses a different model.
Instead of extending the keyring locking, just do the simple RCU locking that the assoc_array was designed for.(CVE-2026-64015)
In the Linux kernel, the following vulnerability has been resolved:
bpf, skmsg: fix verdict sk_data_ready racing with ktls rx
sk_psock_strp_data_ready() already checks tls_sw_has_ctx_rx() and defers to psock->saved_data_ready when a TLS RX context is present, avoiding a conflict with the TLS strparser's ownership of the receive queue (commit e91de6afa81c, "bpf: Fix running sk_skb program types with ktls").
sk_psock_verdict_data_ready() has no equivalent guard. When a socket is inserted into a sockmap (BPF_SK_SKB_VERDICT) before TLS RX is configured, tls_sw_strparser_arm() saves sk_psock_verdict_data_ready as rx_ctx->saved_data_ready. On data arrival:
tls_data_ready -> tls_strp_data_ready -> tls_rx_msg_ready -> saved_data_ready() = sk_psock_verdict_data_ready() -> tcp_read_skb() drains sk_receive_queue via __skb_unlink() without calling tcp_eat_skb(), so copied_seq is not advanced.
tls_strp_msg_load() then finds tcp_inq() >= full_len (stale), calls tcp_recv_skb() on the now-empty queue, hits WARN_ON_ONCE(!first), and returns with rx_ctx->strp.anchor.frag_list pointing at a psock-owned (potentially freed) skb. tls_decrypt_sg() subsequently walks that frag_list: use-after-free.
Apply the same fix as sk_psock_strp_data_ready(): if a TLS RX context is present, call psock->saved_data_ready (sock_def_readable) to wake recv() waiters and return immediately, leaving the receive queue untouched. TLS retains sole ownership of the queue and decrypts the record normally through tls_sw_recvmsg().(CVE-2026-64025)
In the Linux kernel, the following vulnerability has been resolved:
bridge: mcast: Fix a possible use-after-free when removing a bridge port
When per-VLAN multicast snooping is enabled, the bridge iterates over all the bridge ports, disables the per-port multicast context on each port and enables the per-{port, VLAN} multicast contexts instead. The reverse happens when per-VLAN multicast snooping is disabled.
When global multicast snooping is enabled, the bridge iterates over all the bridge ports and enables the per-port multicast context on each port. The reverse happens when multicast snooping is disabled.
The above scheme can result in a situation where both types of contexts (per-port and per-{port, VLAN}) are enabled on a single bridge port:
# ip link add name br1 up type bridge mcast_snooping 1 mcast_querier 1 vlan_filtering 1 # ip link add name dummy1 up master br1 type dummy # ip link set dev br1 type bridge mcast_vlan_snooping 1 # ip link set dev br1 type bridge mcast_snooping 0 # ip link set dev br1 type bridge mcast_snooping 1
This is not intended and it is a problem since the commit cited below. Prior to this commit, when removing a bridge port, br_multicast_disable_port() would disable the per-port multicast context and the per-{port, VLAN} multicast contexts would get disabled when flushing VLANs.
After this commit, br_multicast_disable_port() only disables the per-port multicast context if per-VLAN multicast snooping is disabled. If both types of contexts were enabled on the port when it was removed, the per-port multicast context would remain enabled when freeing the bridge port, leading to a use-after-free [1].
Fix by preventing the bridge from enabling / disabling the per-port multicast contexts when toggling global multicast snooping if per-VLAN multicast snooping is enabled.
[1] ODEBUG: free active (active state 0) object: ffff88810f8bda78 object type: timer_list hint: br_ip6_multicast_port_query_expired (net/bridge/br_multicast.c:1927) WARNING: lib/debugobjects.c:629 at debug_print_object+0x1b1/0x3e0, CPU#5: swapper/5/0 [...] Call Trace: <IRQ> __debug_check_no_obj_freed (lib/debugobjects.c:1116) kfree (mm/slub.c:2620 mm/slub.c:6250 mm/slub.c:6565) kobject_cleanup (lib/kobject.c:689) rcu_do_batch (kernel/rcu/tree.c:2617) rcu_core (kernel/rcu/tree.c:2869) handle_softirqs (kernel/softirq.c:622) __irq_exit_rcu (kernel/softirq.c:656 kernel/softirq.c:496 kernel/softirq.c:735) irq_exit_rcu (kernel/softirq.c:752) sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1061 (discriminator 47) arch/x86/kernel/apic/apic.c:1061 (discriminator 47)) </IRQ>(CVE-2026-64032)
In the Linux kernel, the following vulnerability has been resolved: net: tls: prevent chain-after-chain in plain text SG. Sashiko points out that if end = 0 (start != 0) the current code will create a chain link to content type right after the wrap link. This would create a chain where the wrap link points directly to another chain link. The scatterlist API sg_next iterator does not recursively resolve consecutive chain links, meaning this is illegal input to crypto. The wrapping link is unnecessary if end = 0. TLS 1.3 can use the "wrapping slot" for its chaining if end = 0, which avoids the chain-after-chain.(CVE-2026-64046)
In the Linux kernel, the following vulnerability has been resolved:
net: tls: fix off-by-one in sg_chain entry count for wrapped sk_msg ring
When an sk_msg scatterlist ring wraps (sg.end < sg.start), tls_push_record() chains the tail portion of the ring to the head using sg_chain(). An extra entry in the sg array is reserved for this:
struct sk_msg_sg { [...] / The extra two elements: * 1) used for chaining the front and sections when the list becomes * partitioned (e.g. end < start). The crypto APIs require the * chaining; * 2) to chain tailer SG entries after the message. / struct scatterlist data[MAX_MSG_FRAGS + 2];
The current code uses MAX_SKB_FRAGS + 1 as the ring size:
sg_chain(&msg_pl->sg.data[msg_pl->sg.start],
MAX_SKB_FRAGS - msg_pl->sg.start + 1,
msg_pl->sg.data);
This places the chain pointer at
sg_chain(data[start], (MAX_SKB_FRAGS - msg_start + 1) .. = &data[start] + (MAX_SKB_FRAGS - msg_start + 1) - 1 = data[start + (MAX_SKB_FRAGS - start + 1) - 1] = data[MAX_SKB_FRAGS]
instead of the true last entry. This is likely due to a "race" of the commit under Fixes landing close to commit 031097d9e079 ("bpf: sk_msg, zap ingress queue on psock down")
Convert to ARRAY_SIZE and drop the data[start] / - start (as suggested by Sabrina).(CVE-2026-64047)
In the Linux kernel, the following vulnerability has been resolved:
irq_work: Fix use-after-free in irq_work_single() on PREEMPT_RT
On PREEMPT_RT, non-HARD irq_work runs in per-CPU kthreads via run_irq_workd(), so irq_work_sync() uses rcuwait() to wait for BUSY==0.
After irq_work_single() clears BUSY via atomic_cmpxchg(), it still dereferences @work for irq_work_is_hard() and rcuwait_wake_up().
An irq_work_sync() caller on another CPU that enters after BUSY is cleared can observe BUSY==0 immediately, return, and free the work before those accesses complete — causing a use-after-free.
Fix this by wrapping run_irq_workd() in guard(rcu)() so that the entire irq_work_single() execution is within an RCU read-side critical section. Then add synchronize_rcu() in irq_work_sync() after rcuwait_wait_event() to ensure the caller waits for the RCU grace period before returning, preventing premature frees.(CVE-2026-64073)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: bridge: eb_tables: close module init race
sashiko reports for unrelated patch: Does the core ebtables initialization in ebtables.c suffer from a similar race? Once nf_register_sockopt() completes, the sockopts are exposed globally.
sockopt has to be registered last, just like in ip/ip6/arptables.(CVE-2026-64076)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: ebtables: move to two-stage removal scheme
Like previous patches for x_tables, follow same pattern in ebtables. We can't reuse xt helpers: ebt_table struct layout is incompatible.
table->ops assignment is now done while still holding the ebt mutex to make sure we never expose partially-filled table struct.(CVE-2026-64077)
In the Linux kernel, the following vulnerability has been resolved:
batman-adv: tt: fix negative tt_buff_len
batadv_orig_node::tt_buff_len was declared as s16, but the field is never intended to hold a negative value. When a value greater than 32767 is assigned, it wraps to a negative signed integer.
In batadv_send_other_tt_response(), tt_buff_len is temporarily widened to s32. The incorrectly negative s16 value propagates into the s32, causing batadv_tt_prepare_tvlv_global_data() to allocate a full sized buffer but populates only a small portion of it with the collected changeset. All remaining bits are kept uninitialized.
Using an u16 avoids this type confusion and ensures that no (negative) sign extension is performed in batadv_send_other_tt_response().(CVE-2026-64088)
In the Linux kernel, the following vulnerability has been resolved:
batman-adv: tt: fix negative last_changeset_len
batadv_piv_tt::last_changeset_len len was declared as s16, but the field is never intended to hold a negative value. When a value greater than 32767 is assigned, it wraps to a negative signed integer.
In batadv_send_my_tt_response(), last_changeset_len is temporarily widened to s32. The incorrectly negative s16 value propagates into the s32, causing batadv_tt_prepare_tvlv_local_data() to allocate a full sized buffer but populates only a small portion of it with the collected changeset. All remaining bits are kept uninitialized.
Using an u16 avoids this type confusion and ensures that no (negative) sign extension is performed in batadv_send_my_tt_response().(CVE-2026-64089)
In the Linux kernel, the following vulnerability has been resolved:
batman-adv: bla: avoid double decrement of bla.num_requests
The bla.num_requests is increased when no request_sent was in progress. And it is decremented in various places (announcement was received, backbone is purged, periodic work). But the check if the request_sent is actually set to a specific state and the atomic_dec/_inc are not safe because they are not atomic (TOCTOU) and multiple such code portions can run concurrently.
At the same time, it is necessary to modify request_sent (state) and bla.num_requests atomically. Otherwise batadv_bla_send_request() might set request_sent to 1 and is interrupted. batadv_handle_announce() can then set request_sent back to 0 and decrement num_requests before batadv_bla_send_request() incremented it.
The two operations must therefore be locked. And since state (request_sent) and wait_periods are only accessed inside this lock, they can be converted to simpler datatypes. And to avoid that the bla.num_requests is touched by a parallel running context with a valid backbone_gw reference after batadv_bla_purge_backbone_gw() ran, a third state "stopped" is required to correctly signal that a backbone_gw is in the state of being cleaned up.(CVE-2026-64095)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Validate GPIO pin LUT table size before iterating
[Why&How] The GPIO pin table parsers in get_gpio_i2c_info() and bios_parser_get_gpio_pin_info() derive an element count from the VBIOS table_header.structuresize field, then iterate over gpio_pin[] entries. However, GET_IMAGE() only validates that the table header itself fits within the BIOS image. If the VBIOS reports a structuresize larger than the actual mapped data, the loop reads past the end of the BIOS image, causing an out-of-bounds read.
Fix this by calling bios_get_image() to validate that the full claimed structuresize is accessible within the BIOS image before entering the loop in both functions.
(cherry picked from commit ba5e95b43b773ae1bf1f66ee6b31eb774e65afe3)(CVE-2026-64097)
In the Linux kernel, the following vulnerability has been resolved:
drm/virtio: use uninterruptible resv lock for plane updates
virtio_gpu_cursor_plane_update() and virtio_gpu_resource_flush() lock the framebuffer BO's dma_resv via virtio_gpu_array_lock_resv() and ignore its return value. The function can fail with -EINTR from dma_resv_lock_interruptible() (signal during lock wait) or with -ENOMEM from dma_resv_reserve_fences() (fence slot allocation), leaving the resv lock not held. The queue path then walks the object array and calls dma_resv_add_fence(), which requires the lock held; with lockdep enabled this trips dma_resv_assert_held():
WARNING: drivers/dma-buf/dma-resv.c:296 at dma_resv_add_fence+0x71e/0x840 Call Trace: virtio_gpu_array_add_fence virtio_gpu_queue_ctrl_sgs virtio_gpu_queue_fenced_ctrl_buffer virtio_gpu_cursor_plane_update drm_atomic_helper_commit_planes drm_atomic_helper_commit_tail commit_tail drm_atomic_helper_commit drm_atomic_commit drm_atomic_helper_update_plane __setplane_atomic drm_mode_cursor_universal drm_mode_cursor_common drm_mode_cursor_ioctl drm_ioctl __x64_sys_ioctl
Beyond the WARN, mutating the dma_resv fence list without the lock races with concurrent readers/writers and can corrupt the list.
Both call sites run inside the .atomic_update plane callback, which DRM atomic helpers do not allow to fail (by the time it runs, the commit has been signed off to userspace and there is no clean rollback path). Moving the lock acquisition to .prepare_fb was rejected because the broader lock scope deadlocks against other BO locking paths in the same atomic commit.
Introduce virtio_gpu_lock_one_resv_uninterruptible() that uses dma_resv_lock() instead of dma_resv_lock_interruptible(). This eliminates the -EINTR failure mode -- the realistic syzbot trigger -- without extending the lock hold across the commit. The helper locks a single BO and rejects nents > 1 with -EINVAL; both fix sites lock exactly one BO.
Use it from virtio_gpu_cursor_plane_update() and virtio_gpu_resource_flush(); check the return value to handle the remaining -ENOMEM case from dma_resv_reserve_fences() by freeing the objs and skipping the plane update for that frame. The framebuffer BOs touched here are not shared with other contexts and lock contention is expected to be brief, so the loss of signal-interruptibility is acceptable.
Other callers of virtio_gpu_array_lock_resv() (the ioctl paths) continue to use the interruptible variant.
The bug was reported by syzbot, triggered via fault injection (fail_nth) on the DRM_IOCTL_MODE_CURSOR path, which forces the -ENOMEM branch in dma_resv_reserve_fences().(CVE-2026-64098)
In the Linux kernel, the following vulnerability has been resolved:
KVM: arm64: vgic-its: Reject restored DTE with out-of-range num_eventid_bits
Userspace can restore an ITS Device Table Entry whose Size field encodes more EventID bits than the virtual ITS supports. The live MAPD path rejects that state, but vgic_its_restore_dte() accepts it and stores the out-of-range value in dev->num_eventid_bits.
Reject restored DTEs with num_eventid_bits > VITS_TYPER_IDBITS before allocating the device. This mirrors the MAPD check and prevents the restored state from reaching vgic_its_restore_itt(), where the unchecked value can be converted into an oversized scan_its_table() range.(CVE-2026-64106)
In the Linux kernel, the following vulnerability has been resolved:
af_unix: Fix UAF read of tail->len in unix_stream_data_wait()
unix_stream_data_wait() does skb_peek_tail(&sk->sk_receive_queue) without
holding any lock that prevents SKBs on that queue from being dequeued and
freed.
This has been the case since commit 79f632c71bea ("unix/stream: fix
peeking with an offset larger than data in queue").
The first consequence of this is that the pointer comparison
tail != last can be false even if last semantically refers to an
already-freed SKB while tail is a new SKB allocated at the same address;
which can cause unix_stream_data_wait() to wrongly keep blocking after new
data has arrived, but only in a weird scenario where a peeking recv() and
a normal recv() on the same socket are racing, which is probably not a
real problem.
But since commit 2b514574f7e8 ("net: af_unix: implement splice for stream
af_unix sockets"), tail is actually dereferenced, which can cause UAF in
the following race scenario (where test_setup() runs single-threaded,
and afterwards, test_thread1() and test_thread2() run concurrently in
two threads:
static int socks[2];
void test_setup(void) {
socketpair(AF_UNIX, SOCK_STREAM, 0, socks);
send(socks[1], "A", 1, 0);
int peekoff = 1;
setsockopt(socks[0], SOL_SOCKET, SO_PEEK_OFF, &peekoff, sizeof(peekoff));
}
void test_thread1(void) {
char dummy;
recv(socks[0], &dummy, 1, MSG_PEEK);
}
void test_thread2(void) {
char dummy;
recv(socks[0], &dummy, 1, 0);
shutdown(socks[1], SHUT_WR);
}
when racing like this:
thread1 thread2
unix_stream_read_generic
mutex_lock(&u->iolock)
skb_peek(&sk->sk_receive_queue)
skb_peek_next(skb, &sk->sk_receive_queue)
mutex_unlock(&u->iolock)
unix_stream_read_generic
unix_state_lock(sk)
skb_peek(&sk->sk_receive_queue)
unix_state_unlock(sk)
unix_stream_data_wait
unix_state_lock(sk)
tail = skb_peek_tail(&sk->sk_receive_queue)
spin_lock(&sk->sk_receive_queue.lock)
__skb_unlink(skb, &sk->sk_receive_queue)
spin_unlock(&sk->sk_receive_queue.lock)
consume_skb(skb) [frees the SKB]
`tail != last`: false
`tail`: true
`tail->len != last_len` ***UAF***
Fix the UAF by removing the read of tail->len; checking tail->len would only make sense if SKBs in the receive queue of a UNIX socket could grow, which can no longer happen.
Kuniyuki explained:
> When commit 869e7c62486e ("net: af_unix: implement stream sendpage > support") added sendpage() support, data could be appended to the last > skb in the receiver's queue. > > That's why we needed to check if the length of the last skb was changed > while waiting for new data in unix_stream_data_wait(). > > However, commit a0dbf5f818f9 ("af_unix: Support MSG_SPLICE_PAGES") and > commit 57d44a354a43 ("unix: Convert unix_stream_sendpage() to use > MSG_SPLICE_PAGES") refactored sendmsg(), and now data is always added > to a new skb.
That means this fix is not suitable for kernels before 6.5.(CVE-2026-64109)
In the Linux kernel, the following vulnerability has been resolved:
rbd: eliminate a race in lock_dwork draining on unmap
Given how rbd_lock_add_request() and rbd_img_exclusive_lock() are written, lock_dwork may be (re)queued more than it's actually needed: for example in case a new I/O request comes in while we are in the middle of rbd_acquire_lock() on behalf of another I/O request. This is expected and with rbd_release_lock() preemptively canceling lock_dwork is benign under normal operation.
A more problematic example is maybe_kick_acquire():
if (have_requests || delayed_work_pending(&rbd_dev->lock_dwork)) {
dout("%s rbd_dev %p kicking lock_dwork\n", __func__, rbd_dev);
mod_delayed_work(rbd_dev->task_wq, &rbd_dev->lock_dwork, 0);
}
It's not unrealistic for lock_dwork to get canceled right after delayed_work_pending() returns true and for mod_delayed_work() to requeue it right there anyway. This is a classic TOCTOU race.
When it comes to unmapping the image, there is an implicit assumption of no self-initiated exclusive lock activity past the point of return from rbd_dev_image_unlock() which unlocks the lock if it happens to be held. This unlock is assumed to be final and lock_dwork (as well as all other exclusive lock tasks, really) isn't expected to get queued again. However, lock_dwork is canceled only in cancel_tasks_sync() (i.e. later in the unmap sequence) and on top of that the cancellation can get in effect nullified by maybe_kick_acquire(). This may result in rbd_acquire_lock() executing after rbd_dev_device_release() and rbd_dev_image_release() run and free and/or reset a bunch of things. One of the possible failure modes then is a violated
rbd_assert(rbd_image_format_valid(rbd_dev->image_format));
in rbd_dev_header_info() which is called via rbd_dev_refresh() from rbd_post_acquire_action().
Redo exclusive lock task draining to provide saner semantics and try to meet the assumptions around rbd_dev_image_unlock().(CVE-2026-64112)
In the Linux kernel, the following vulnerability has been resolved:
ixgbevf: fix use-after-free in VEPA multicast source pruning
ixgbevf_clean_rx_irq() prunes frames whose source MAC matches the VF's own address (VEPA multicast workaround) by freeing the skb and continuing to the next descriptor:
dev_kfree_skb_irq(skb);
continue;
The skb pointer is declared outside the while loop and persists across iterations. Because the continue skips the "skb = NULL" reset at the bottom of the loop, the next iteration enters the "else if (skb)" path and calls ixgbevf_add_rx_frag() on the freed skb, dereferencing skb_shinfo(skb)->nr_frags - a use-after-free in NAPI softirq context.
The sibling driver iavf already handles this correctly by nulling the pointer before continuing. Apply the same pattern here.
I do not have ixgbevf hardware; the bug was found by static analysis (scan_drop_continue_loops.py + semgrep drop_continue_in_loop, multi-tool corroboration with the highest score in the scan). The UAF was confirmed under KASAN by loading a test module that reproduces the exact code pattern (alloc skb, kfree_skb, then read skb_shinfo(skb)->nr_frags):
BUG: KASAN: slab-use-after-free in ixgbevf_uaf_test_init+0x100/0x1000 Read of size 8 at addr 000000006163ae78 by task insmod/30 freed 208-byte region [000000006163adc0, 000000006163ae90)
QEMU emulates igb (82576) but not ixgbe (82599), and the igbvf VF driver does not include the VEPA source pruning path, so a full end-to-end reproduction with emulated hardware was not possible.(CVE-2026-64113)
In the Linux kernel, the following vulnerability has been resolved:
ipv4: raw: reject IP_HDRINCL packets with ihl < 5
raw_send_hdrinc() validates that the caller-supplied IPv4 header fits within the message length:
iphlen = iph->ihl * 4;
err = -EINVAL;
if (iphlen > length)
goto error_free;
if (iphlen >= sizeof(*iph)) {
/* fix up saddr, tot_len, id, csum, transport_header */
}
It does not, however, reject ihl < 5. For such a packet the "if (iphlen >= sizeof(*iph))" branch is skipped, leaving the crafted iphdr untouched, but the packet is still handed to __ip_local_out() and onward. Downstream consumers that read iph->ihl assume a sane value: net/ipv4/ah4.c:ah_output() in particular subtracts sizeof(struct iphdr) from top_iph->ihl * 4 and passes the (signed-int-negative, then cast to size_t) result to memcpy(), producing an OOB access of length close to SIZE_MAX and a host kernel panic.
An IPv4 header with ihl < 5 is malformed by definition (RFC 791: "Internet Header Length is the length of the internet header in 32 bit words ... Note that the minimum value for a correct header is 5."). The kernel should not be willing to inject such a packet into its own output path.
Reject "iphlen < sizeof(*iph)" alongside the existing "iphlen > length" check. This matches the principle that locally constructed packets that re-enter the IP stack must pass the same basic sanity tests that a foreign packet would be subjected to.
Once this lands, the "if (iphlen >= sizeof(*iph))" wrapper around the fixup branch becomes redundant; left in place to keep the patch minimal and backport-friendly. A follow-up can unwrap it.
Note that commit 86f4c90a1c5c ("ipv4, ipv6: ensure raw socket message is big enough to hold an IP header") ensures the message buffer is large enough to hold an iphdr, but does not constrain the self-reported iph->ihl.
Reachability: the malformed packet source is any caller with CAP_NET_RAW, including an unprivileged process in a user+net namespace on a kernel with CONFIG_USER_NS=y. The reproduced AH crash also requires a matching xfrm AH policy on the outgoing route; a container granted CAP_NET_ADMIN can install that state and policy in its netns. Loopback bypasses xfrm_output, so the trigger uses a real netdev.
Reproduced on UML + KASAN: kernel-mode fault at addr 0x0 with memcpy_orig at the crash site. Same shape reproduces inside a rootless Docker container with --cap-add NET_ADMIN on a stock distro kernel.(CVE-2026-64114)
In the Linux kernel, the following vulnerability has been resolved:
qed: fix double free in qed_cxt_tables_alloc()
If one of the later PF or VF CID bitmap allocations fails, qed_cid_map_alloc() jumps to cid_map_fail and frees the previously allocated CID bitmaps before returning an error. qed_cxt_tables_alloc() then calls qed_cxt_mngr_free(), which invokes qed_cid_map_free() again.
Fix this by setting each CID bitmap pointer to NULL after bitmap_free() to avoid double free.
The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1-rc3.
Runtime reproduction was not attempted because exercising the failing allocation path requires device-specific setup.(CVE-2026-64118)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: MGMT: validate Add Extended Advertising Data length
MGMT_OP_ADD_EXT_ADV_DATA is registered as a variable-length command, with MGMT_ADD_EXT_ADV_DATA_SIZE as the fixed header size. The handler then uses cp->adv_data_len and cp->scan_rsp_len to validate and copy cp->data, but it never checks that those bytes are part of the mgmt command payload.
A short command can therefore make add_ext_adv_data() pass an out-of-bounds pointer into tlv_data_is_valid(). If the bytes beyond the command buffer are addressable, they can also be copied into the advertising instance as scan response data, where the caller can read them back via MGMT_OP_GET_ADV_INSTANCE. The trigger requires CAP_NET_ADMIN in the initial user namespace; KASAN reports an 8-byte slab-out-of-bounds read.
Reject commands whose length does not match the fixed header plus both advertising data lengths before parsing cp->data.(CVE-2026-64126)
In the Linux kernel, the following vulnerability has been resolved:
smb: client: protect tc_count increment in smb2_find_smb_sess_tcon_unlocked()
Commit 96c4af418586 ("cifs: Fix locking usage for tcon fields") refactored cifs code to change cifs_tcp_ses_lock for tc_lock around tc_count changes.
There was missing lock around tc_count increment inside smb2_find_smb_sess_tcon_unlocked().(CVE-2026-64136)
In the Linux kernel, an out-of-bounds read vulnerability exists in the i2c-stub driver. The I2C_SMBUS_I2C_BLOCK_DATA case in stub_xfer() function (drivers/i2c/i2c-stub.c) uses data->block[0] as the transfer length. The existing check only clamps it to avoid overrunning the chip->words[256] register array, but does not validate it against I2C_SMBUS_BLOCK_MAX (32), which is the limit of the union i2c_smbus_data.block buffer. A local user with access to /dev/i2c-* devices can issue an I2C_SMBUS ioctl with I2C_SMBUS_I2C_BLOCK_DATA and data->block[0] > 32, causing stub_xfer() to read or write past the end of the union i2c_smbus_data.block buffer, resulting in a stack out-of-bounds access. This vulnerability affects confidentiality, integrity, and availability.(CVE-2026-64191)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Validate payload length and link_index in dc_process_dmub_aux_transfer_async
[Why&How] dc_process_dmub_aux_transfer_async() copies payload->length bytes into a 16-byte stack buffer (dpaux.data[16]) guarded only by an ASSERT(), which is a no-op in release builds. If a caller ever passes length > 16 this results in a stack buffer overflow via memcpy.
Additionally, link_index is used to dereference dc->links[] without bounds checking against dc->link_count, risking an out-of-bounds access.
Replace the ASSERT with a hard runtime check that returns false when payload->length exceeds the destination buffer size, and add a bounds check for link_index before it is used.
(cherry picked from commit ba4caa9fecdf7a38f98c878ad05a8a64148b6881)(CVE-2026-64219)
In the Linux kernel, the following vulnerability has been resolved:
octeontx2-pf: avoid double free of pool->stack on AQ init failure
otx2_pool_aq_init() frees pool->stack when mailbox sync or retry allocation fails, but leaves the pointer unchanged. Later, otx2_sq_aura_pool_init() unwinds the partial setup through otx2_aura_pool_free(), which frees pool->stack again. The CN20K-specific cn20k_pool_aq_init() implementation has the same bug in its corresponding error path.
Set pool->stack to NULL immediately after the local free so the shared cleanup path does not free the same stack again while cleaning up partially initialized pool state.
The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1-rc3.
Runtime validation was not performed because reproducing this path requires OcteonTX2/CN20K hardware.(CVE-2026-64222)
In the Linux kernel, the following vulnerability has been resolved:
Input: elan_i2c - validate firmware size before use
Ensure that the firmware file is large enough to contain the expected number of pages and the signature (which resides at the end of the firmware blob) before accessing them to prevent potential out-of-bounds reads.(CVE-2026-64237)
In the Linux kernel, the following vulnerability has been resolved:
KVM: x86: hyper-v: Bound the bank index when querying sparse banks
When checking if a VP ID is included in a sparse bank set, explicitly check that the ID can actually be contained in a sparse bank (the TLFS allows for a maximum of 64 banks of 64 vCPUs each). When handling a paravirtual TLB flush for L2, the VP ID is copied verbatim from the enlightened VMCS, without any bounds check, i.e. isn't guaranteed to be under the limit of 4096.
Failure to check the bounds of the VP ID leads to an out-of-bounds read when testing the sparse bank, and super strictly speaking could lead to KVM performing an unnecessary TLB flush for an L2 vCPU.
================================================================== BUG: KASAN: use-after-free in hv_is_vp_in_sparse_set+0x85/0x100 [kvm] Read of size 8 at addr ffff88811ba5f598 by task hyperv_evmcs/2802
CPU: 12 UID: 1000 PID: 2802 Comm: hyperv_evmcs Not tainted 7.1.0-rc2 #7 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: <TASK> dump_stack_lvl+0x51/0x60 print_report+0xcb/0x5d0 kasan_report+0xb4/0xe0 kasan_check_range+0x35/0x1b0 hv_is_vp_in_sparse_set+0x85/0x100 [kvm] kvm_hv_flush_tlb+0xe9e/0x16c0 [kvm] kvm_hv_hypercall+0xe6b/0x1e60 [kvm] vmx_handle_exit+0x485/0x1b60 [kvm_intel] kvm_arch_vcpu_ioctl_run+0x22e3/0x5070 [kvm] kvm_vcpu_ioctl+0x5d0/0x10c0 [kvm] __x64_sys_ioctl+0x129/0x1a0 do_syscall_64+0xb9/0xcf0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f0e62d1a9bf </TASK>
The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffffffffffffffff pfn:0x11ba5f flags: 0x4000000000000000(zone=1) raw: 4000000000000000 0000000000000000 00000000ffffffff 0000000000000000 raw: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected
Memory state around the buggy address: ffff88811ba5f480: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88811ba5f500: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff >ffff88811ba5f580: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ ffff88811ba5f600: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88811ba5f680: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ================================================================== Disabling lock debugging due to kernel taint
Opportunistically add a compile time assertion to ensure the maximum number of sparse banks exactly matches the number of possible bits in the passed in mask.
sean: add KASAN splat, drop comment, add assert, massage changelog
In the Linux kernel, the following vulnerability has been resolved:
NFSv4: include MAY_WRITE in open permission mask for O_TRUNC
POSIX requires write permission to truncate a file, so an open() that specifies O_TRUNC must be authorized for write access regardless of the O_ACCMODE access mode.
nfs_open_permission_mask() builds the access mask passed to nfs_may_open(), which is the local authorization gate for OPENs the client serves itself from a cached write delegation via the can_open_delegated() path in nfs4_try_open_cached(). The mask is derived from O_ACCMODE alone, so an open(O_RDONLY | O_TRUNC) against a file the caller cannot write requests only MAY_READ and passes the local check. The OPEN is then satisfied locally and the truncation is issued to the server as a SETATTR(size=0) over the delegation stateid, which the server accepts under standard write-delegation semantics. POSIX requires that this open fail with EACCES.
Include MAY_WRITE in the mask whenever O_TRUNC is set so the local check matches the access the server would have enforced.(CVE-2026-64298)
In the Linux kernel, the following vulnerability has been resolved:
tracing: Prevent out-of-bounds read in glob matching
String event fields are not necessarily NUL-terminated, so the filter predicate functions (filter_pred_string(), filter_pred_strloc() and filter_pred_strrelloc()) pass the field length to the regex match callbacks, and the length-aware matchers honour it.
regex_match_glob() was the exception: it ignored the length and called glob_match(), which scans the string until it hits a NUL byte. Some string fields are not NUL-terminated. One example is the dynamic char array of the xfs_* namespace tracepoints, which is copied without a trailing NUL. For such a field, glob matching reads past the end of the event field, causing a KASAN slab-out-of-bounds read in glob_match(), reached via regex_match_glob() and filter_match_preds() from the xfs_lookup tracepoint.
Add a length-bounded glob_match_len() and use it from regex_match_glob() so glob matching always stops at the field boundary. The matching loop is factored into a shared helper so glob_match() keeps its behaviour.(CVE-2026-64299)
In the Linux kernel, the following vulnerability has been resolved:
crypto: qat - validate RSA CRT component lengths
The generic RSA key parser (rsa_helper.c) bounds each CRT component (p, q, dp, dq, qinv) by the modulus size n_sz, but qat_rsa_setkey_crt() allocates half-size DMA buffers (key_sz / 2) and right-aligns each component with:
memcpy(dst + half_key_sz - len, src, len)
When a CRT component is larger than half_key_sz the subtraction underflows and memcpy writes past the DMA buffer, causing memory corruption.
Add a len > half_key_sz check next to the existing !len check for each of the five CRT components so the driver falls back to the non-CRT path instead of writing out of bounds.(CVE-2026-64304)
In the Linux kernel, the following vulnerability has been resolved:
crypto: qat - protect service table iterations with service_lock
The service_table list is protected by service_lock when entries are added or removed (in adf_service_add() and adf_service_remove()), but several functions iterate over the list without holding this lock.
A concurrent adf_service_register() or adf_service_unregister() call could modify the list during traversal, leading to list corruption or a use-after-free.
Fix this by holding service_lock across all list_for_each_entry() iterations of service_table in adf_dev_init(), adf_dev_start(), adf_dev_stop(), adf_dev_shutdown(), adf_dev_restarting_notify(), adf_dev_restarted_notify(), and adf_error_notifier().
The lock ordering is safe: callers of the static helpers (adf_dev_up() and adf_dev_down()) acquire state_lock before service_lock, and no event_hld callback or service_lock holder ever acquires state_lock in the reverse order.(CVE-2026-64305)
In the Linux kernel, the following vulnerability has been resolved:
crypto: drbg - Fix returning success on failure in CTR_DRBG
drbg_ctr_generate() sometimes returns success when it fails, leaving the output buffer uninitialized. Fix it.(CVE-2026-64306)
In the Linux kernel, the following vulnerability has been resolved:
crypto: pcrypt - restore callback for non-parallel fallback
pcrypt installs pcrypt_aead_done() on the child AEAD request before trying to submit it through padata. If padata_do_parallel() returns -EBUSY, pcrypt falls back to calling the child AEAD directly.
That fallback must not keep the padata completion callback. Otherwise an asynchronous completion runs pcrypt_aead_done() even though the request was never enrolled in padata.
Restore the original request callback and callback data before calling the child AEAD directly. This keeps the fallback path aligned with a direct AEAD request while leaving the parallel path unchanged.(CVE-2026-64312)
In the Linux kernel, the following vulnerability has been resolved:
crypto: ecc - Fix carry overflow in vli multiplication
The carry flag calculation fails when r01.m_high is saturated (0xFFFFFFFFFFFFFFFF) and addition of lower bits overflows.
The condition (r01.m_high < product.m_high) doesn't handle the case where r01.m_high == product.m_high and an additional carry exists from lower-bit overflow.
When commit 3c4b23901a0c ("crypto: ecdh - Add ECDH software support") introduced crypto/ecc.c, it split the muladd() function in the micro-ecc library into separate mul_64_64() and add_128_128() helpers. It seems the check got lost in translation.
Add proper handling for this boundary by accounting for the carry from the lower addition.(CVE-2026-64313)
In the Linux kernel, the following vulnerability has been resolved:
isofs: bound Rock Ridge symlink components to the SL record
get_symlink_chunk() and the SL handling in parse_rock_ridge_inode_internal() walk the variable-length components of a Rock Ridge "SL" (symbolic link) record. Each component is a two-byte header (flags, len) followed by len bytes of text, so it occupies slp->len + 2 bytes. Both loops read slp->len and advance to the next component, and get_symlink_chunk() additionally does memcpy(rpnt, slp->text, slp->len), but neither checks that the component lies within the SL record before dereferencing it.
A crafted SL record whose component declares a len that runs past the record (rr->len) therefore triggers an out-of-bounds read of up to 255 bytes. When the record sits at the tail of its backing buffer - for example a small kmalloc()ed continuation block reached through a CE record - the read crosses the allocation; get_symlink_chunk() then copies the out-of-bounds bytes into the symlink body returned to user space by readlink(), disclosing adjacent kernel memory.
ISO 9660 images are routinely mounted from untrusted removable media - desktop environments auto-mount them (e.g. via udisks2) without CAP_SYS_ADMIN - so the record contents are attacker-controlled.
Reject any component that does not fit in the remaining record bytes before using it. In get_symlink_chunk() return NULL, like the existing output-buffer (plimit) checks, so a malformed record makes readlink() fail with -EIO rather than silently returning a truncated target; in parse_rock_ridge_inode_internal() stop the inode-size walk.(CVE-2026-64317)
In the Linux kernel, the following vulnerability has been resolved:
nvmet-auth: validate reply message payload bounds against transfer length
nvmet_auth_reply() accesses the variable-length rval[] array using attacker-controlled hl (hash length) and dhvlen (DH value length) fields without verifying they fit within the allocated buffer of tl bytes.
A malicious NVMe-oF initiator can craft a DHCHAP_REPLY message with a small transfer length but large hl/dhvlen values, causing out-of-bounds heap reads when the target processes the DH public key (rval + 2*hl) or performs the host response memcmp.
With DH authentication configured, the OOB pointer is passed directly to sg_init_one() and read by crypto_kpp_compute_shared_secret(), reaching up to 526 bytes past the buffer. This is exploitable pre-authentication.
Add bounds validation ensuring sizeof(data) + 2hl + dhvlen <= tl before any access to the variable-length fields.
Discovered by Atuin - Automated Vulnerability Discovery Engine.(CVE-2026-64319)
In the Linux kernel, the following vulnerability has been resolved:
nvmet: fix pre-auth out-of-bounds heap read in Discovery Get Log Page
nvmet_execute_disc_get_log_page() validates only the dword alignment of the host-supplied Log Page Offset (lpo). The 64-bit offset is then added to a small kzalloc'd buffer that holds the discovery log page and the result is passed straight to nvmet_copy_to_sgl(), which memcpy()s data_len bytes out to the host with no source-side bound check:
u64 offset = nvmet_get_log_page_offset(req->cmd); /* 64-bit host */
size_t data_len = nvmet_get_log_page_len(req->cmd); /* 32-bit host */
...
if (offset & 0x3) { ... } /* only check */
...
alloc_len = sizeof(*hdr) + entry_size * discovery_log_entries(req);
buffer = kzalloc(alloc_len, GFP_KERNEL);
...
status = nvmet_copy_to_sgl(req, 0, buffer + offset, data_len);
The Discovery controller is unauthenticated -- nvmet_host_allowed() returns true unconditionally for the discovery subsystem -- so the call is reachable pre-authentication by any TCP/RDMA/FC peer that can reach the nvmet target. With a discovery log page of ~1 KiB, an attacker requesting up to 4 KiB starting at offset == alloc_len reads the next slab page out and gets its content returned over the fabric (an empirical run on a default nvmet-tcp loopback target leaked 81 canonical kernel pointers in one Get Log Page response). Pointing the offset at unmapped kernel memory faults the in-kernel memcpy and crashes (or panics, on panic_on_oops=1) the target host instead.
The attacker-controlled source-side offset pattern "nvmet_copy_to_sgl(req, 0, buffer + ATTACKER_OFFSET, ...)" is unique to nvmet_execute_disc_get_log_page in the entire nvmet codebase: every other Get Log Page handler in admin-cmd.c either ignores lpo (and silently starts every response at offset 0) or tracks a local destination offset with a fixed source pointer.
Validate the host-supplied offset against the log page size, cap the copy length to what is actually available, and zero-fill any remainder of the host transfer buffer. The zero-fill matches the existing short-response pattern in nvmet_execute_get_log_changed_ns() (admin-cmd.c) and prevents leaking transport SGL contents when the host asks for more bytes than the log page contains.(CVE-2026-64320)
In the Linux kernel, the following vulnerability has been resolved:
udf: validate sparing table length as an entry count, not a byte count
udf_load_sparable_map() accepts a sparing table when
sizeof(*st) + le16_to_cpu(st->reallocationTableLen) > sb->s_blocksize
is false, i.e. it treats reallocationTableLen as a number of BYTES that must fit in the block. But the table is walked as an array of 8-byte sparingEntry elements:
for (i = 0; i < le16_to_cpu(st->reallocationTableLen); i++) {
struct sparingEntry *entry = &st->mapEntry[i];
... entry->origLocation ...
}
in udf_get_pblock_spar15() and udf_relocate_blocks(). A reallocationTableLen of N therefore passes the check whenever sizeof(st) + N <= blocksize, yet the consumers index sizeof(st) + N * sizeof(struct sparingEntry) bytes -- up to ~8x the block. On a crafted UDF image this is an out-of-bounds read in udf_get_pblock_spar15(); udf_relocate_blocks() additionally feeds the same length to udf_update_tag(), whose crc_itu_t() reads far past the block, and its memmove() through st->mapEntry[] is an out-of-bounds write.
Validate reallocationTableLen as the entry count it is, with struct_size().(CVE-2026-64322)
In the Linux kernel, the following vulnerability has been resolved:
udf: validate VAT header length against the VAT inode size
udf_load_vat() takes the virtual partition's start offset straight from the on-disk VAT 2.0 header without checking it against the VAT inode size:
map->s_type_specific.s_virtual.s_start_offset =
le16_to_cpu(vat20->lengthHeader);
map->s_type_specific.s_virtual.s_num_entries =
(sbi->s_vat_inode->i_size -
map->s_type_specific.s_virtual.s_start_offset) >> 2;
lengthHeader is a fully attacker-controlled 16-bit value. If it exceeds the VAT inode size, the s_num_entries subtraction underflows to a huge count, which defeats the "block > s_num_entries" bound in udf_get_pblock_virt15(); and on the ICB-inline path that function reads
((__le32 *)(iinfo->i_data + s_start_offset))[block]
so a large s_start_offset indexes past the inode's in-ICB data. Mounting a crafted UDF image with a virtual (VAT) partition then triggers an out-of-bounds read.
Reject a VAT whose header length does not leave room for at least one entry within the VAT inode.(CVE-2026-64323)
In the Linux kernel, the following vulnerability has been resolved:
udf: validate free block extents against the partition length
udf_free_blocks() checks the logical block number and count against the partition length, but drops the extent offset from that final bound. A crafted extent can pass the guard while logicalBlockNum + offset + count points past the partition, which later indexes past the space bitmap array.
A single ftruncate(2) on a file backed by such an extent reliably panics the kernel. This is a local availability issue. On desktop systems where UDisks/polkit allows the active user to mount removable UDF media without CAP_SYS_ADMIN, an unprivileged local user can supply the crafted filesystem and trigger the panic by truncating a writable file on it. Systems that require root or CAP_SYS_ADMIN to mount the image have a higher prerequisite.
No confidentiality or integrity impact is claimed: the reproduced primitive is an out-of-bounds read of a bitmap pointer slot followed by a kernel panic.
Use the already computed logicalBlockNum + offset + count value for the partition length check. Also make load_block_bitmap() reject an out-of-range block group before indexing s_block_bitmap[], so corrupted callers cannot walk past the flexible array.(CVE-2026-64324)
In the Linux kernel, the following vulnerability has been resolved:
bpf: Reject fragmented frames in devmap
Devmap broadcast redirects clone the packet for all but the last destination.
For native XDP, that clone path copies only the linear xdp_frame data, while fragmented frames keep skb_shared_info in tailroom outside the linear area. Cloning such a frame leaves XDP_FLAGS_HAS_FRAGS set but without valid frag metadata, and the later free path can interpret uninitialized tail data as skb_shared_info, leading to an out-of-bounds access during frame return.
Reject fragmented native XDP frames in dev_map_enqueue_clone().
Add the same restriction to the generic XDP clone path in dev_map_redirect_clone(). Generic XDP represents fragmented packets as nonlinear skbs, and rejecting them here keeps clone-based broadcast support aligned between native and generic XDP.(CVE-2026-64355)
In the Linux kernel, the following vulnerability has been resolved:
HID: multitouch: fix out-of-bounds bit access on mt_io_flags
mt_io_flags is a single unsigned long, but mt_process_slot(), mt_release_pending_palms() and mt_release_contacts() use it as a per-slot bitmap indexed by the slot number. That slot number is only bounded by td->maxcontacts, which is taken from the device's ContactCountMaximum feature report and can be up to 255, not by BITS_PER_LONG.
As a result, a multitouch device that advertises a large contact count makes set_bit()/clear_bit() operate past the mt_io_flags word and corrupt the adjacent members of struct mt_device. The sticky-fingers release timer is the easiest way to reach this. mt_release_contacts() runs
for (i = 0; i < mt->num_slots; i++)
clear_bit(i, &td->mt_io_flags);
with num_slots == maxcontacts. For maxcontacts around 250 the loop clears the bits that overlap td->applications.next, zeroing that list head, and the list_for_each_entry() that immediately follows then dereferences NULL. The kernel panics from timer (softirq) context. On a KASAN build this shows up as a general protection fault in mt_release_contacts() with a null-ptr-deref at offset 0x58, which is offsetof(struct mt_application, num_received).
The state is reachable from an untrusted USB or Bluetooth HID multitouch device; no local privileges are required.
Store the per-slot active state in a separately allocated bitmap sized for maxcontacts, the same pattern already used for pending_palm_slots, and keep only MT_IO_FLAGS_RUNNING in mt_io_flags. The two "mt_io_flags & MT_IO_SLOTS_MASK" arming checks become bitmap_empty(td->active_slots, td->maxcontacts).
Move MT_IO_FLAGS_RUNNING back to bit 0. It was bumped to bit 32 by the same commit to leave the low byte for the slot bits; with the slot bits gone it fits in bit 0 again, which also keeps it within the unsigned long on 32-bit.(CVE-2026-64364)
In the Linux kernel, the following vulnerability has been resolved:
sched/rt: Have RT_PUSH_IPI be default off for non PREEMPT_RT
RT migration is done aggressively. When a CPU schedules out a high priority RT task for a lower priority task, it will look to see if there's any RT tasks that are waiting to run on another CPU that is of higher priority than the task this CPU is about to run. If it finds one, it will pull that task over to the CPU and allow it to run there instead.
Normally, this pulling is done by looking at the RT overloaded mask (rto) which contains all the CPUs in the scheduler domain with RT tasks that are waiting to run due to a higher priority RT task currently running on their CPU. The CPU that is about to schedule a lower priority task will grab the rq lock of the overloaded CPU and move the RT task from that CPU's runqueue to the local one and schedule the higher priority RT task.
This caused issues when a lot of CPUs would schedule a lower priority task at the same time. They would all try to grab the same runqueue lock of the CPU with the overloaded RT tasks. Only the first CPU that got in will get that task. All the others would wait until they got the runqueue lock and see there's nothing to pull and do nothing. On systems with lots of CPUs, this caused a large latency (up to 500us) which is beyond what PREEMPT_RT is to allow.
The solution to that was to create an RT_PUSH_IPI logic. When any CPU wanted to pull a task, instead of grabbing the runqueue lock of the overloaded CPU, it would start by sending an IPI to the overloaded CPU, and that IPI handler would have the CPU with the waiting RT task do a push instead. Then that handler would send an IPI to the next CPU with overloaded RT tasks, and so on. Note, after the first CPU starts this process, if another CPU wanted to do a pull, it would see that the process has already begun and would only increment a counter to have the IPIs continue again.
The RT_PUSH_IPI solved the latency problem with PREEMPT_RT but could cause a new issue with non PREEMPT_RT. Namely, softirqs run in a threaded context on PREEMPT_RT but they can run in an interrupt context in non-RT.
If an IPI lands on a CPU that has just woken up multiple RT tasks and the current CPU is running a non RT or a low priority RT task, instead of doing a push, it would simply do a schedule on that CPU. But if a softirq was also executing on this CPU, the schedule would need to wait until the softirq finished. Until then, the CPU would still be considered overloaded as there are RT tasks still waiting to run on it.
A live lock occurred on a workload that was doing heavy networking traffic on a large machine where the softirqs would run 500us out of 750us. And it would also be waking up RT tasks, causing the RT pull logic to be constantly executed.
When a softirq triggered on a CPU with RT tasks queued but not running yet, and the other CPUs would see this CPU as being overloaded, they would send an IPI over to it. The CPU would notice that the waiting RT tasks are of higher priority than the currently running task and simply schedule that CPU instead. But because the softirq was executing, before it could schedule, it would receive another IPI to do the same. The amount of IPIs would slow down the currently running softirq so much that before it could return back to task context, it would execute another softirq never allowing the CPU to schedule. This live locked that CPU.
As RT_PUSH_IPI was created to help PREEMPT_RT, make it default off if PREEMPT_RT is not enabled.(CVE-2026-64374)
In the Linux kernel, the following vulnerability has been resolved:
writeback: fix race between cgroup_writeback_umount() and inode_switch_wbs()
When a container exits, the following BUG_ON() is occasionally triggered:
================================================================== VFS: Busy inodes after unmount of sdb (ext4) ------------[ cut here ]------------ kernel BUG at fs/super.c:695! CPU: 3 PID: 6 Comm: containerd-shim Tainted: G OE K 6.6 #1 pstate: 63400009 (nZCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : generic_shutdown_super+0xf0/0x100 lr : generic_shutdown_super+0xf0/0x100 Call trace: generic_shutdown_super+0xf0/0x100 kill_block_super+0x20/0x48 ext4_kill_sb+0x28/0x60 deactivate_locked_super+0x54/0x130 deactivate_super+0x84/0xa0 cleanup_mnt+0xa4/0x140 __cleanup_mnt+0x18/0x28 task_work_run+0x78/0xe0 do_notify_resume+0x204/0x240 ==================================================================
The root cause is a race between cgroup_writeback_umount() and inode_switch_wbs()/cleanup_offline_cgwb(). There is a window between inode_prepare_wbs_switch() returning true and the subsequent wb_queue_isw() call. Following is the process that triggers the issue:
CPU A (umount) | CPU B (writeback)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ inode_switch_wbs/cleanup_offline_cgwb atomic_inc(&isw_nr_in_flight) inode_prepare_wbs_switch -> passes SB_ACTIVE check __iget(inode) generic_shutdown_super sb->s_flags &= ~SB_ACTIVE cgroup_writeback_umount(sb) smp_mb() atomic_read(&isw_nr_in_flight) rcu_barrier() -> no pending RCU callbacks flush_workqueue(isw_wq) -> nothing queued, returns evict_inodes(sb) -> Inode skipped as isw still holds a ref. sop->put_super(sb) / destroys percpu counters / -> VFS: Busy inodes after unmount! wb_queue_isw() queue_work(isw_wq, ...) / later in work function / inode_switch_wbs_work_fn process_inode_switch_wbs iput() -> evict percpu_counter_dec() // UAF!
Fix this by extending the RCU read-side critical section in inode_switch_wbs() and cleanup_offline_cgwb() to cover from inode_prepare_wbs_switch() through wb_queue_isw(). Since there is no sleep in this window, rcu_read_lock() can be used. Then add a synchronize_rcu() in cgroup_writeback_umount() before the existing rcu_barrier(), so that all in-flight switchers that have passed the SB_ACTIVE check have completed queue_work() before flush_workqueue() is called.
The existing rcu_barrier() is intentionally retained so this fix can be backported unchanged to stable kernels (5.10.y, 6.6.y, ...) that still queue switches via queue_rcu_work(). It is a no-op on current mainline (since commit e1b849cfa6b6 ("writeback: Avoid contention on wb->list_lock when switching inodes")) and is removed in a follow-up patch.(CVE-2026-64378)
In the Linux kernel, the following vulnerability has been resolved:
smb: client: mask server-provided mode to 07777 in modefromsid
When modefromsid is active, parse_dacl() applies the server-provided sub_auth[2] value from the NFS mode SID to cf_mode without masking to 07777. Apply the correct masking, same as in the read path.(CVE-2026-64379)
In the Linux kernel, the following vulnerability has been resolved:
smb: client: harden POSIX SID length parsing
posix_info_sid_size() reads sid[1] to obtain the subauthority count, but its existing boundary check still accepts buffers with only one remaining byte. Require two bytes before reading sid[1] so all client paths that reuse the helper reject truncated POSIX SIDs safely.(CVE-2026-64380)
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix double-free in SMB2_open() replay
A response-bearing attempt can return a replayable error and free its response buffer. If SMB2_open_init() fails before the next send, cleanup retains the previous buffer type and frees that response again.
Reset response bookkeeping before each attempt to prevent the stale free.(CVE-2026-64382)
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix double-free in SMB2_flush() replay
SMB2_flush() keeps its response buffer bookkeeping across replay attempts. If a replayable flush response is received and the retry then fails before cifs_send_recv() stores a replacement response, flush_exit will free the stale response pointer a second time.
Reinitialize resp_buftype and rsp_iov at the top of the replay loop so cleanup only acts on response state produced by the current attempt. This fixes a double-free without changing replay handling for successful requests.(CVE-2026-64383)
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix change notify replay double-free
A response-bearing attempt can return a replayable error and free its response buffer. If SMB2_notify_init() fails before the next send, cleanup retains the previous buffer type and frees that response again.
Reset response bookkeeping before each attempt to prevent the stale free.(CVE-2026-64384)
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix double-free in SMB2_ioctl() replay
A response-bearing attempt can return a replayable error and free its response buffer. If SMB2_ioctl_init() fails before the next send, cleanup retains the previous buffer type and frees that response again.
Reset response bookkeeping before each attempt to prevent the stale free.(CVE-2026-64385)
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix query_info() replay double-free
A response-bearing attempt can return a replayable error and free its response buffer. If SMB2_query_info_init() fails before the next send, cleanup retains the previous buffer type and frees that response again.
Reset response bookkeeping before each attempt to prevent the stale free.(CVE-2026-64386)
In the Linux kernel, an out-of-bounds read vulnerability exists in the SMB client. smb2_check_message() has a long-standing quirk that accepts a response whose calculated length is one byte larger than the bytes actually received ("server can return one byte more due to implied bcc[0]"). This was introduced to accommodate servers that omit the trailing bcc[0] overlap byte when no data area is present. However, the exemption is applied unconditionally, regardless of whether the command actually carries a data area (has_smb2_data_area[]). When a response with a data area is subject to the +1 exemption, the reported data can extend one byte beyond the bytes actually received, causing the subsequent decoder to read past the end of the receive buffer. This is reachable during NEGOTIATE and SESSION_SETUP, before the session is established. The resulting out-of-bounds reads are visible under KASAN when mounting against a non-conforming server, affecting both the SPNEGO/negTokenInit and the NTLMSSP challenge decoders.(CVE-2026-64448)
In the Linux kernel, the following vulnerability has been resolved:
hwrng: virtio: clamp device-reported used.len at copy_data()
random_recv_done() stores the device-reported used.len directly into vi->data_avail. copy_data() then indexes vi->data[] using vi->data_idx (advanced by previous copy_data() calls) and issues a memcpy() without re-validating either value against the posted buffer size sizeof(vi->data) (SMP_CACHE_BYTES bytes, typically 32 or 64).
A malicious or buggy virtio-rng backend can set used.len beyond sizeof(vi->data), steering the memcpy() past the end of the inline array into adjacent kmalloc-1k slab bytes. hwrng_fillfn() mixes those bytes into the guest RNG, and guest root can also observe them directly via /dev/hwrng.
Concrete impact is inside the guest:
-
Memory-safety / hardening: any virtio-rng backend that over-reports used.len causes the driver to read past vi->data into unrelated slab contents. hwrng_fillfn() is a kernel thread that runs as soon as the device is probed; no guest userspace interaction is required to first-trigger the OOB.
-
Cross-boundary leak (confidential-compute threat model): a malicious hypervisor cooperating with a malicious or compromised guest root userspace can use /dev/hwrng as a leak channel for guest-kernel heap data. The host sets a large used.len, guest root reads /dev/hwrng, and the returned bytes contain guest kernel slab contents that were adjacent to vi->data. In practice, confidential-compute guests (SEV-SNP, TDX) usually disable virtio-rng entirely, so this path is narrow, but the fix is still worth carrying because the underlying memory-safety bug contaminates the guest RNG on any host.
KASAN confirms the OOB on a 7.1-rc4 guest whose virtio-rng backend has been patched to report used.len = 0x10000:
BUG: KASAN: slab-out-of-bounds in virtio_read+0x394/0x5d0 Read of size 64 at addr ffff88800ae0ba20 by task hwrng/52 Call Trace: __asan_memcpy+0x23/0x60 virtio_read+0x394/0x5d0 hwrng_fillfn+0xb2/0x470 kthread+0x2cc/0x3a0 Allocated by task 1: probe_common+0xa5/0x660 virtio_dev_probe+0x549/0xbc0 The buggy address belongs to the object at ffff88800ae0b800 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 0 bytes to the right of allocated 544-byte region [ffff88800ae0b800, ffff88800ae0ba20)
Same class of bug as commit c04db81cd028 ("net/9p: Fix buffer overflow in USB transport layer"), which hardened usb9pfs_rx_complete() against unchecked device-reported length in the USB 9p transport.
With the clamp at point of use and array_index_nospec() in place, the same harness boots cleanly: copy_data() returns zero for the bogus report, the device-supplied bytes after data_idx are discarded, and the driver issues a fresh request.(CVE-2026-64456)
In the Linux kernel, the following vulnerability has been resolved:
ALSA: hda/cs35l41: Fix firmware load work teardown
cs35l41_hda creates ALSA controls whose private data points at the cs35l41_hda object. The firmware load control can also queue fw_load_work.
Those controls are not removed on component unbind, and device remove only cancels fw_load_work through cs35l41_remove_dsp(). That helper is skipped when halo_initialized is false. With firmware_autostart disabled, a firmware load can be requested before the DSP has been initialized. If the component or device is removed before the queued work runs, the worker can run after teardown and dereference driver state that is no longer valid.
Track the created controls and remove them on unbind so no new control callback can reach the driver data or queue more work. Then cancel fw_load_work to drain any request that was already queued. Also cancel the work unconditionally during device remove before runtime PM teardown.(CVE-2026-64481)
In the Linux kernel, the following vulnerability has been resolved:
iio: event: Fix event FIFO reset race
iio_event_getfd() creates the event file descriptor with
anon_inode_getfd(), which allocates a new fd, creates the anonymous
file and installs it in the process fd table before returning to the
caller.
The IIO code resets the event FIFO after anon_inode_getfd() has returned,
but before IIO_GET_EVENT_FD_IOCTL has copied the fd number to userspace.
But since fd tables are shared between threads, another thread can guess
the newly allocated fd number and issue a read() on it as soon as the fd
has been installed.
This means the kfifo_to_user() in iio_event_chrdev_read() can run in
parallel with the kfifo_reset_out() in iio_event_getfd().
The kfifo documentation says that kfifo_reset_out() is only safe when it
is called from the reader thread and there is only one concurrent reader.
Otherwise it is dangerous and must be handled in the same way as
kfifo_reset().
If that happens, kfifo_to_user() can advance the FIFO out index based
on state from before the reset, after the reset has already moved the out
index to the current in index. That can leave the FIFO with an out
index past the in index. A later read() can then see an underflowed
FIFO length and copy more data than the event FIFO buffer contains. This
can result in an out-of-bounds read and leak adjacent kernel memory to
userspace.
Move the FIFO reset before anon_inode_getfd(). At that point the event fd is
marked busy, but the new fd has not been installed yet, so userspace cannot
access it while the FIFO is reset.(CVE-2026-64496)
In the Linux kernel, the following vulnerability has been resolved:
net: openvswitch: reject oversized nested action attrs
Open vSwitch stores generated flow actions as nlattrs, whose nla_len field is u16. Commit a1e64addf3ff ("net: openvswitch: remove misbehaving actions length check") allowed the total sw_flow_actions stream to grow beyond 64 KiB, which is valid, but also removed the last guard preventing a generated nested action attribute from exceeding U16_MAX.
An oversized generated container can thus be closed with a truncated nla_len. A later dump or teardown then walks a structurally different stream than the one that was validated. In particular, an oversized nested CLONE/CT action may cause subsequent bytes in the generated stream to be interpreted as independent actions.
Keep the larger total-action-stream behavior, but make nested action close reject generated containers that do not fit in nla_len, and return the error through all callers. For recursive SAMPLE, CLONE, DEC_TTL, and CHECK_PKT_LEN builders, trim resource-owning action-list tails in reverse construction order before discarding failed wrappers, so resources copied into the rejected tails are released before the wrappers are removed.
Most failed outer wrappers are discarded by truncating actions_len after child resources have been released. CHECK_PKT_LEN also trims its parent after branch resources are gone. SET/TUNNEL close failures unwind their known tun_dst ownership directly, and SET_TO_MASKED has no external ownership and truncates on close failure.(CVE-2026-64531)
In the Linux kernel, the following vulnerability has been resolved:\n\nperf/core: Detach event groups during remove_on_exec\n\nperf_event_remove_on_exec() removes events by calling\nperf_event_exit_event(). For top-level events, this removes the event from\nthe context with DETACH_EXIT only.\n\nThis can leave inconsistent group state when a removed event is a group\nleader and the group contains siblings without remove_on_exec. If the group\nwas active, the surviving siblings can remain active and attached to the\nremoved leader's sibling list, but are no longer represented by a valid\ngroup leader on the PMU context active lists.\n\nA later close of the removed leader uses DETACH_GROUP and can promote the\nstill-active siblings from this stale group state. The next schedule-in can\nthen add an already-linked active_list entry again, corrupting the PMU\ncontext active list.\n\nWith DEBUG_LIST enabled, this is caught as a list_add double-add in\nmerge_sched_in().\n\nFix this by detaching group relationships when remove_on_exec removes an\nevent. This preserves the existing task-exit and revoke behavior, while\nensuring surviving siblings are ungrouped before the removed event leaves\nthe context.(CVE-2026-64556)
In the Linux kernel, a use-after-free (UAF) vulnerability exists caused by a non-leader exec() race condition in posix-cpu-timers. When sys_timer_delete() observes the old leader, while de_thread() executes switch_leader() and releases the old leader, a race condition occurs. Specifically, posix_cpu_timer_del() in sys_timer_delete() obtains the old leader via pid_task(), while de_thread() is executing release_task(old_leader) and setting old_leader->sighand = NULL. When lock_task_sighand() returns NULL, sys_timer_delete() frees the posix timer object. However, if the timer was armed and enqueued in p->signal (a TGID targeted timer is inherited on exec()), run_posix_cpu_timers() or other timerqueue add/delete operations will access the freed object's timerqueue node, resulting in a use-after-free. This issue similarly affects posix_cpu_timer_set() and posix_cpu_timer_rearm(). The history of this vulnerability goes back to the early days of posix CPU timers implementation.(CVE-2026-64560)
In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: x86: Check for invalid/obsolete root after making MMU pages available\n\nCheck for a \"stale\" page fault, i.e. for an invalid and/or obsolete root, after making MMU pages available for the shadow MMU. If reclaiming shadow pages zaps an in-use root, i.e. marks it invalid, then KVM will attempt to map memory into an invalid root. On its own, populating an invalid root is \"fine\", but because child shadow pages inherit their parent's role, any children created during the map/fetch will be created as invalid pages, thus violating KVM's invariant that invalid pages are never on the list of active MMU pages.\n\nNote, the underlying flaw has existed since KVM first started tracking invalid roots in 2008 (commit 2e53d63acba7, \"KVM: MMU: ignore zapped root pagetables\"), but the true badness only came along in 2020 (Linux 5.9) with the invariant that invalid shadow pages can't be on the list of active pages.\n\nNote #2, inheriting role.invalid when creating child shadow pages is also far from ideal; that flaw will be addressed separately.(CVE-2026-64561)
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix double-free in SMB2_close() replay
A response-bearing attempt can return a replayable error and free its response buffer. If SMB2_close_init() fails before the next send, cleanup retains the previous buffer type and frees that response again.
Reset response bookkeeping before each attempt to prevent the stale free.(CVE-2026-64597)
In the Linux kernel, the following vulnerability has been resolved: ipvs: reload ip header after head reallocation. __ip_vs_get_out_rt() calls skb_ensure_writable() which may reallocate skb->head, causing the previously obtained IP header pointer to become a dangling pointer, leading to a use-after-free vulnerability.(CVE-2026-68476)
In the Linux kernel, the following vulnerability has been resolved:
ipvs: fix more places with wrong ipv6 transport offsets
Sashiko reports for more incorrect IPv6 transport offsets.
The app code for TCP was assuming IPv4 network header even after the ipvsh argument was provided. This can cause problems with apps over IPv6. As for the only official app in the kernel tree (FTP) this problem is harmless because we use Netfilter to mangle the FTP ports and we do not adjust the TCP seq numbers.
Also, provide correct offset of the ICMPV6 header in ip_vs_out_icmp_v6() for correct checksum checks when the IPv6 packet has extension headers.(CVE-2026-68477)
In the Linux kernel, the following vulnerability has been resolved:
ipvs: use parsed transport offset in SCTP state lookup
set_sctp_state() reads the SCTP chunk header again in order to drive the IPVS SCTP state table. For IPv6 it computes the offset with sizeof(struct ipv6hdr), while the surrounding IPVS code uses iph.len from ip_vs_fill_iph_skb(), where ipv6_find_hdr() has already skipped extension headers and found the real transport header.
This makes the state machine read from the wrong offset for IPv6 SCTP packets that carry extension headers. For example, an INIT packet with an 8-byte destination options header can be scheduled correctly by sctp_conn_schedule(), but set_sctp_state() reads the first byte of the SCTP verification tag as a DATA chunk type. The connection then moves from NONE to ESTABLISHED instead of INIT1, gets the longer established timeout, and updates the active/inactive destination counters incorrectly. This happens even though the SCTP handshake has not completed.
Use the parsed transport offset passed down from ip_vs_set_state() for the SCTP chunk-header lookup. For IPv4 and IPv6 packets without extension headers this preserves the existing offset.(CVE-2026-72021)
In the Linux kernel, the following vulnerability has been resolved:
ieee802154: admin-gate legacy LLSEC dump operations
In net/ieee802154/netlink.c, the legacy IEEE802154_NL family ops table builds the LLSEC dump entries (LLSEC_LIST_KEY, LLSEC_LIST_DEV, LLSEC_LIST_DEVKEY, LLSEC_LIST_SECLEVEL) with IEEE802154_DUMP() which sets no .flags, so generic netlink runs them ungated. The modern nl802154 family admin-gates the equivalent reads via NL802154_CMD_GET_SEC_KEY and friends with .flags = GENL_ADMIN_PERM.
Any local uid that can open AF_NETLINK / NETLINK_GENERIC can resolve the "802.15.4 MAC" family and dump LLSEC_LIST_KEY on any wpan netdev that has an LLSEC key installed; the dump handler writes the raw 16-byte AES-128 key bytes (IEEE802154_ATTR_LLSEC_KEY_BYTES, copied verbatim from struct ieee802154_llsec_key.key) into the reply. Recovering the AES key compromises 802.15.4 LLSEC link confidentiality and authenticity, since LLSEC uses CCM* and the same key authenticates and encrypts frames.
Impact: any local uid with no capabilities can read the raw 16-byte AES-128 LLSEC key from the kernel keytable on any wpan netdev that has an administrator-installed LLSEC key, by issuing an LLSEC_LIST_KEY dump on the legacy IEEE802154_NL generic-netlink family.
Introduce IEEE802154_DUMP_PRIV() mirroring IEEE802154_DUMP() but setting .flags = GENL_ADMIN_PERM, and use it for the four LLSEC dump entries. LIST_PHY and LIST_IFACE retain IEEE802154_DUMP() because the modern nl802154 family exposes their equivalents to unprivileged readers by design (NL802154_CMD_GET_WPAN_PHY and NL802154_CMD_GET_INTERFACE carry "can be retrieved by unprivileged users" annotations).(CVE-2026-72049)
In the Linux kernel, the following vulnerability has been resolved:
net: ip6_gre: require CAP_NET_ADMIN in the device netns for changelink
ip6gre_changelink() and ip6erspan_changelink() operate on at most two netns, dev_net(dev) and the tunnel link netns t->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in t->net can rewrite a tunnel that lives in t->net.
Gate both ops on rtnl_dev_link_net_capable() at their top, before any attribute is parsed.(CVE-2026-72052)
In the Linux kernel, the following vulnerability has been resolved:
net: ipip: require CAP_NET_ADMIN in the device netns for changelink
ipip_changelink() operates on at most two netns, dev_net(dev) and the tunnel link netns t->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in t->net can rewrite a tunnel that lives in t->net.
Gate ipip_changelink() on rtnl_dev_link_net_capable() at its top, before any attribute is parsed.(CVE-2026-72053)
In the Linux kernel, the following vulnerability has been resolved:
net: ip_vti: require CAP_NET_ADMIN in the device netns for changelink
vti_changelink() operates on at most two netns, dev_net(dev) and the tunnel link netns t->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in t->net can rewrite a tunnel that lives in t->net.
Gate vti_changelink() on rtnl_dev_link_net_capable() at its top, before any attribute is parsed.(CVE-2026-72054)
In the Linux kernel, the following vulnerability has been resolved:
net: sit: require CAP_NET_ADMIN in the device netns for changelink
ipip6_changelink() operates on at most two netns, dev_net(dev) and the tunnel link netns t->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in t->net can rewrite a tunnel that lives in t->net.
Gate ipip6_changelink() on rtnl_dev_link_net_capable() at its top, before any attribute is parsed. sit was the one tunnel type not covered by the recent series that added this check to the other changelink() handlers.(CVE-2026-72061)
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: macsec: fix use-after-free of metadata_dst on RX SC delete
When an offloaded MACsec RX SC is deleted, macsec_del_rxsc_ctx() freed the per-SC metadata_dst with metadata_dst_free(), which kfree()s the object unconditionally and ignores the dst reference count. The RX datapath in mlx5e_macsec_offload_handle_rx_skb() looks up the SC under rcu_read_lock() via xa_load(), takes a reference with dst_hold() and attaches the dst to the skb with skb_dst_set(). A reader that already obtained the rx_sc pointer can race with the delete path and operate on freed memory.
Fix the owner side by dropping the reference with dst_release() instead of freeing unconditionally, and convert the RX datapath to dst_hold_safe() so a reader racing the SC delete cannot attach a dst whose last reference was just dropped; only attach it when a reference was actually taken.
mlx5e_macsec_add_rxsc() also published sc_xarray_element via xa_alloc() before rx_sc->md_dst was allocated and initialised, so a datapath reader that looked the SC up by fs_id could observe rx_sc with md_dst still NULL or, on weakly-ordered architectures, a non-NULL md_dst pointer whose contents were not yet visible. NULL-check the xa_load() result and md_dst on the datapath, and reorder add_rxsc() so the xa_alloc() publish happens only after md_dst is fully initialised; the xarray RCU publish then pairs with the rcu_read_lock()/xa_load() in the datapath.
Note: macsec_del_rxsc_ctx() also kfree()s rx_sc->sc_xarray_element without an RCU grace period while the same datapath reads it under rcu_read_lock(); that is a separate pre-existing issue left to a follow-up patch.
Found by 0sec automated security-research tooling (https://0sec.ai).(CVE-2026-72072)
In the Linux kernel, the following vulnerability has been resolved:
dm-log: fix a bitset_size overflow on 32bit machines
Commit c20e36b7631d ("dm log: fix out-of-bounds write due to region_count overflow") made sure that region_count could fit in an unsigned int. But the bitmap memory isn't allocated based on region_count. It uses bitset_size (a size_t variable). The first step of calculating bitset_size is to set it to region_count, rounded up to a multiple of BITS_PER_LONG. If region_size is less than BITS_PER_LONG smaller than UINT_MAX, it will get rounded up to 2^32. On a 32bit architecture, this will make bitset_size wrap around to 0 and fail, despite region_count being valid.
Since bitset_size gets divided by 8, it can hold any valid region_count. It just needs a special case to handle the rollover. If it is 0, the value rolled over, and bitset size should be set to the number of bytes needed to hold 2^32 bits.(CVE-2026-72105)
In the Linux kernel, the following vulnerability has been resolved:
bpf,fork: wipe ->bpf_storage before bailouts that access it
Currently, copy_process() can bail out to free_task() before p->bpf_storage has been initialized, with this call graph (shown here for the !CONFIG_MEMCG case):
copy_process dup_task_struct arch_dup_task_struct [copies the entire task_struct, including ->bpf_storage member] [RLIMIT_NPROC check fails] delayed_free_task free_task bpf_task_storage_free rcu_dereference(task->bpf_storage) bpf_local_storage_destroy
In this case, the nascent task's ->bpf_storage member that bpf_local_storage_destroy() operates on is a plain copy of the parent's ->bpf_storage pointer, not a real initialized pointer. This leads to badness (kernel hangs, UAF).
This is reachable as long as the process calling fork() has been inserted into a task storage map.(CVE-2026-72110)
In the Linux kernel, the following vulnerability has been resolved:
nvmet-rdma: handle inline data with a nonzero offset
nvmet_rdma_use_inline_sg() maps the host-controlled inline data offset into the per-command inline scatterlist. The bounds check admits any offset with off + len <= inline_data_size, but the mapping still assumes the data begins in the first inline page:
sg->offset = off;
sg->length = min_t(int, len, PAGE_SIZE - off);
When a port is configured with inline_data_size > PAGE_SIZE (settable up to max(SZ_16K, PAGE_SIZE)), an offset in (PAGE_SIZE, inline_data_size] makes "PAGE_SIZE - off" underflow, so sg->length is set to ~4 GiB and the block backend reads far past the first inline page. num_pages(len) also ignores the offset, so an in-bounds offset whose [off, off+len) span crosses a page boundary under-counts the scatterlist.
Map the offset properly: split it into a page index and an in-page offset, start the scatterlist at that page, and size the page count from page_off + len. Because the request scatterlist may now start at inline_sg[page_idx] rather than inline_sg[0], generalize the inline-SGL identity test in nvmet_rdma_release_rsp() to a range test; otherwise the persistent inline scatterlist is mistaken for an allocated one and nvmet_req_free_sgls() frees an inline page (and warns in free_large_kmalloc()).(CVE-2026-72129)
In the Linux kernel, the following vulnerability has been resolved:
tpm: Make the TPM character devices non-seekable
The TPM character devices expose a sequential command/response interface, but their open handlers leave FMODE_PREAD and FMODE_PWRITE enabled.
After a command leaves a response pending, pread(fd, buf, 16, 0x1400) passes 0x1400 as off to tpm_common_read(). The transfer length is bounded by response_length, but the offset is used unchecked when forming data_buffer + off. A sufficiently large offset therefore causes an out-of-bounds heap read through copy_to_user() and, if the copy succeeds, an out-of-bounds zero-write through the following memset().
Positional I/O does not provide coherent semantics for this interface. An arbitrary pread offset cannot represent how much of a response has been consumed sequentially. The write callback always stores a command at the start of data_buffer, while pwrite() does not update file->f_pos and can leave the sequential read cursor stale.
Call nonseekable_open() from both open handlers. This removes FMODE_PREAD and FMODE_PWRITE, causing positional reads and writes to fail with -ESPIPE before reaching the TPM callbacks, and explicitly marks the files non-seekable. Normal read() and write() continue to use the existing sequential f_pos cursor, leaving the response state machine unchanged.
Tested on Linux 6.12 with KASAN and a swtpm TPM2 device:
- sequential partial reads returned the complete response
- pread() and preadv() with offset 0x1400 returned -ESPIPE
- pwrite() and pwritev() with offset zero returned -ESPIPE
- the pending response remained intact after the rejected operations
- a subsequent normal command/response cycle completed normally
- no KASAN report was produced.(CVE-2026-72135)
In the Linux kernel, the following vulnerability has been resolved:
xfrm: xfrm_interface: require CAP_NET_ADMIN in the device netns for changelink
xfrmi_changelink() operates on at most two netns, dev_net(dev) and the interface link netns xi->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in xi->net can rewrite an interface that lives in xi->net.
Gate xfrmi_changelink() on rtnl_dev_link_net_capable() at its top, before any attribute is parsed.(CVE-2026-72136)
In the Linux kernel, the following vulnerability has been resolved: net: thunderbolt: Fix frags[] overflow by bounding frame_count. tbnet_poll() assembles a multi-frame ThunderboltIP packet into one skb. The first frame goes into the skb linear area and every further frame is added as a page fragment. A packet of frame_count frames therefore ends up with frame_count - 1 fragments. tbnet_check_frame() only bounds the peer supplied frame_count to TBNET_RING_SIZE / 4 (64), which is far above MAX_SKB_FRAGS (17 by default). A peer that sends a packet of 19 or more small frames pushes nr_frags past MAX_SKB_FRAGS, so skb_add_rx_frag() writes past skb_shinfo()->frags[] and corrupts memory after the shared info.(CVE-2026-72157)
In the Linux kernel, the following vulnerability has been resolved: mm/mm_init: fix uninitialized struct pages for ZONE_DEVICE. If DAX memory is hotplugged into an unoccupied subsection of an early section, section_activate() reuses the unoptimized boot memmap. However, compound_nr_pages() still assumes that vmemmap optimization is in effect and initializes only the reduced number of struct pages. As a result, the remaining tail struct pages are left uninitialized, which can later lead to unexpected behavior or crashes. Fix this by treating early sections as unoptimized when calculating how many struct pages to initialize.(CVE-2026-72172)
In the Linux kernel, the following vulnerability has been resolved:
SUNRPC: Bound-check xdr_buf_to_bvec() stores before writing
xdr_buf_to_bvec() writes a bio_vec into the caller's array before testing whether that slot is in range, and the head branch performs the store with no check at all. When the caller's budget is exactly used up, the next store lands one element past the end of the array. The overflow label returns count - 1, which masks the surplus store but cannot undo it.
rq_bvec, the array passed by nfsd_vfs_write(), is allocated to exactly rq_maxpages entries with no slack. The OOB store can land in adjacent slab memory; the bv_len and bv_offset fields written there are derived from client-supplied RPC payload sizes.
Move the in-range check ahead of the store in the head, page-loop, and tail branches. With the check at the top of each sequence, count is incremented only after a successful store, so the overflow label can return count directly.(CVE-2026-72217)
In the Linux kernel, the following vulnerability has been resolved:
sunrpc: wait for in-flight TLS handshake callback when cancel loses race
When wait_for_completion_interruptible_timeout() in svc_tcp_handshake() returns 0 (timeout) or -ERESTARTSYS (signal) and tls_handshake_cancel() then returns false, handshake_complete() has won the cancellation race: it has set HANDSHAKE_F_REQ_COMPLETED and is about to invoke svc_tcp_handshake_done(), but the callback's side effects on xpt_flags and on svsk->sk_handshake_done have not yet committed.
The current code reads xpt_flags immediately to decide whether the session succeeded. Two races result.
If the callback has executed set_bit(XPT_TLS_SESSION) but not yet clear_bit(XPT_HANDSHAKE), svc_tcp_handshake() sees a session, enqueues the transport, and returns. svc_xprt_received() then clears XPT_BUSY, a worker thread picks the transport up, the dispatcher in svc_handle_xprt() observes XPT_HANDSHAKE still set, and xpo_handshake is invoked a second time. That svc_tcp_handshake() calls init_completion(&svsk->sk_handshake_done) while the original callback concurrently calls complete_all() on it, corrupting the embedded swait_queue.
If the callback has set HANDSHAKE_F_REQ_COMPLETED but not yet entered svc_tcp_handshake_done(), svc_tcp_handshake() reads XPT_TLS_SESSION as clear and tears the connection down even though the handshake is about to succeed.
Wait for the callback to commit before inspecting xpt_flags. The completion is guaranteed to fire because handshake_complete() invokes svc_tcp_handshake_done() unconditionally once it has set HANDSHAKE_F_REQ_COMPLETED.(CVE-2026-72221)
In the Linux kernel, the following vulnerability has been resolved:
sunrpc: pin svc_xprt across the asynchronous TLS handshake callback
svc_tcp_handshake() stores the raw svc_xprt pointer in tls_handshake_args.ta_data and submits the request through tls_server_hello_x509(). The handshake core takes only sock_hold(req->hr_sk); nothing references the embedding struct svc_sock that svc_tcp_handshake_done() reaches via container_of().
Two close races leave the in-flight callback writing through a freed svc_sock. svc_sock_free() calls tls_handshake_cancel() and discards its return value: a false return means handshake_complete() has already set HANDSHAKE_F_REQ_COMPLETED but hp_done() may not have finished, yet svc_sock_free() proceeds to kfree(svsk). The cancel-loser fall-through inside svc_tcp_handshake() itself produces the same window: when wait_for_completion_interruptible_timeout() returns <= 0 (timeout or signal) and tls_handshake_cancel() returns false, the function does not drain, returns, and svc_handle_xprt() calls svc_xprt_received(), which clears XPT_BUSY and can drop the last reference. A concurrent close then runs svc_sock_free() while svc_tcp_handshake_done() is still updating xpt_flags and walking svsk->sk_handshake_done.
The corruption surfaces as set_bit/clear_bit RMW into the freed xpt_flags slab slot and as complete_all() walking and writing the freed wait_queue_head_t list embedded in sk_handshake_done -- a slab-corruption primitive, not a benign read. The path is reachable on any TLS-enabled NFS server whenever a connection close overlaps the tlshd downcall delivery window; the interruptible wait means signal delivery suffices, not just SVC_HANDSHAKE_TO expiry.
Take svc_xprt_get(xprt) immediately before tls_server_hello_x509() so the in-flight callback owns its own reference. Release it on the two edges where the callback is guaranteed not to fire -- submission failure from tls_server_hello_x509() and a successful tls_handshake_cancel() -- and at the tail of svc_tcp_handshake_done() after complete_all().
cel: rewrote commit message to describe the actual change
In the Linux kernel, the following vulnerability has been resolved:
batman-adv: retrieve ethhdr after potential skb realloc on RX
pskb_may_pull() in batadv_interface_rx() could reallocate the buffer behind the skb. Variables which were pointing to the old buffer need to be reassigned to avoid an use-after-free.
This was done correctly for the VLAN header but missed for the ethernet header which is later used for the TT and AP isolation handling.(CVE-2026-72235)
In the Linux kernel, the following vulnerability has been resolved:
KVM: Move kvm_io_bus_get_dev() locking responsibilities to callers
kvm_io_bus_get_dev() returns a device that is only matched by the address, and nothing else. This can cause a lifetime issue if the matched device is not the expected type, as by the time the caller can introspect the object, it might be gone (the srcu lock having been dropped).
Given that there is only a single user of this helper, the simplest option is to move the locking responsibility to the caller, which can keep the srcu lock held for as long as it wants.
Note that this aligns with other kvm_io_bus*() helpers, which already require the srcu lock to be held by the callers.(CVE-2026-72282)
In the Linux kernel, the following vulnerability has been resolved: smb: client: fix overflow in passthrough ioctl bounds check. smb2_ioctl_query_info() validates the PASSTHRU_FSCTL response payload before copying it to userspace. The payload offset and length both come from 32-bit fields. The bounds check currently adds OutputOffset and qi.input_buffer_length directly, so the addition can wrap in 32-bit arithmetic before the result is compared against the response buffer length. A malicious server can use a large OutputOffset and a small OutputCount to make the wrapped sum pass the bounds check. The later copy_to_user() then reads from io_rsp + OutputOffset, outside the response buffer, leading to an out-of-bounds read.(CVE-2026-72310)
In the Linux kernel, the following vulnerability has been resolved:
dm era: fix NULL pointer dereference in metadata_open()
metadata_open() returns NULL when kzalloc_obj() fails, but the caller era_ctr() only checks IS_ERR(md). Since IS_ERR(NULL) returns false, the NULL pointer is treated as a valid result and later assigned to era->md, leading to a NULL pointer dereference when the metadata is accessed.
Fix this by returning ERR_PTR(-ENOMEM) on allocation failure, consistent with dm-cache-metadata.c, dm-thin-metadata.c, and dm-clone-metadata.c which all use ERR_PTR(-ENOMEM) for the same pattern.(CVE-2026-72316)
In the Linux kernel, the following vulnerability has been resolved:
SUNRPC: pin upper rpc_clnt across the TLS connect_worker
The TLS connect path has a use-after-free: nothing pins the upper rpc_clnt across the delayed connect_worker. xs_connect() stores task->tk_client in sock_xprt::clnt as a raw pointer and queues the worker; for TLS-secured transports that worker is xs_tcp_tls_setup_socket(), which reads several fields out of the saved pointer (cl_timeout, cl_program, cl_prog, cl_vers, cl_cred, cl_stats) to construct the args for the inner handshake rpc_clnt.
The xprt does not reference the rpc_clnt; the rpc_clnt references the xprt. xs_destroy() does cancel the connect_worker, but it runs only when the xprt's refcount drops to zero, which cannot happen until the rpc_clnt releases its cl_xprt reference in rpc_free_client_work(). When a TLS handshake fails fatally (for example, an mTLS mount whose client cert does not match the server), the connecting task is woken with -EACCES and exits, the mount caller invokes rpc_shutdown_client(), and the upper rpc_clnt is freed before the queued connect_worker fires. xs_tcp_tls_setup_socket() then dereferences the freed clnt, producing the refcount_t underflow Michael Nemanov reported.
Take a reference on the upper rpc_clnt in xs_connect() for TLS transports via a new rpc_hold_client() helper, and drop it in the connect_worker's exit path with rpc_release_client(). The xprt_lock_connect() / xprt_unlock_connect() pairing already serialises xs_connect() with xs_tcp_tls_setup_socket(), so the take and release are balanced one-for-one.
The non-TLS connect worker (xs_tcp_setup_socket) never reads sock_xprt::clnt, so leave that path alone and avoid the clnt-holds-xprt-holds-clnt cycle that would otherwise prevent xprt destruction.(CVE-2026-72317)
In the Linux kernel, the following vulnerability has been resolved:
cifs: validate DFS referral string offsets
parse_dfs_referrals() validates that the response header and referral array fit in the received buffer, but each referral also contains string offsets supplied by the server.
Those offsets are used to compute the DfsPath and NetworkAddress string pointers without checking whether they still point inside the response buffer. A malformed referral can therefore make the computed pointer exceed the end of the buffer. The resulting negative max_len is then passed to cifs_strndup_from_utf16(), and the non-Unicode path forwards it to kstrndup() as a size_t, allowing strnlen() to read out of bounds.
Validate each string offset before deriving the string pointer.(CVE-2026-72318)
In the Linux kernel, the following vulnerability has been resolved:
ipvs: ensure inner headers in ICMP errors are in headroom
Sashiko points out that after stripping the outer headers with pskb_pull() we should ensure the inner IP headers in ICMP errors from tunnels are present in the skb headroom for functions like ipv4_update_pmtu(), icmp_send() and IP_VS_DBG().
Also, add more checks for the length of the inner headers.(CVE-2026-72319)
In the Linux kernel, the following vulnerability has been resolved:
net/tls: Consume empty data records in tls_sw_read_sock()
A peer may send a zero-length TLS application_data record; TLS 1.3 explicitly permits these as a traffic-analysis countermeasure (RFC 8446, Section 5.1). After decryption such a record has full_len == 0. tls_sw_read_sock() hands it to the read_actor, which has no payload to consume and returns zero. The loop treats a zero return as backpressure (used <= 0), requeues the skb at the head of rx_list, and stops. rx_list is serviced head-first on the next call, so the empty record is dequeued, fails the same way, and is requeued again; every later record on the connection is blocked behind it.
tls_sw_recvmsg() does not stall on this: a zero-length data record copies nothing and falls through to consume_skb(). Mirror that in the read_sock() path by recognizing an empty data record before the actor runs, consuming it, and continuing.(CVE-2026-72330)
In the Linux kernel, the following vulnerability has been resolved:
qede: fix off-by-one in BD ring consumption on build_skb failure
qede_rx_build_skb() and qede_tpa_rx_build_skb() do not check for a NULL return from qede_build_skb(). When it returns NULL under memory pressure, the functions still consume a BD from the ring before returning NULL. The callers then recycle additional BDs, resulting in one extra BD being consumed (off-by-one). This desynchronizes the BD ring, which can corrupt DMA page reference counts and lead to SLUB freelist corruption.
Commit 4e910dbe3650 ("qede: confirm skb is allocated before using") added a NULL check inside qede_build_skb() to prevent a NULL pointer dereference, but did not address the missing NULL checks in the callers, making this off-by-one reachable.
Fix this by adding NULL checks for the return value of qede_build_skb() in both qede_rx_build_skb() and qede_tpa_rx_build_skb(), returning NULL immediately before any BD ring manipulation.(CVE-2026-72339)
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Fix HV VHCA stats agent registration race
mlx5e_hv_vhca_stats_create() registers the stats agent through mlx5_hv_vhca_agent_create(). The helper publishes the agent in hv_vhca->agents[type] under agents_lock and immediately schedules an asynchronous control invalidation on the HV VHCA workqueue before returning to mlx5e.
The asynchronous invalidation invokes the control agent's invalidate callback, which reads the hypervisor control block and forwards the command to mlx5e_hv_vhca_stats_control(). That callback may either:
- call cancel_delayed_work_sync(&priv->stats_agent.work), or
- call queue_delayed_work(priv->wq, &sagent->work, sagent->delay).
However, the delayed_work and priv->stats_agent.agent are only initialized after mlx5_hv_vhca_agent_create() returns to mlx5e:
agent = mlx5_hv_vhca_agent_create(...); /* publish + invalidate */
...
priv->stats_agent.agent = agent; /* too late */
INIT_DELAYED_WORK(&priv->stats_agent.work, ...); /* too late */
If the asynchronous control path runs before the two assignments above, it can:
- Operate on an uninitialized delayed_work whose timer.function is NULL. queue_delayed_work() calls add_timer() unconditionally, so when the timer expires the timer softirq invokes a NULL function pointer.
- Re-initialize the timer later through INIT_DELAYED_WORK() while the timer is already enqueued in the timer wheel, corrupting the hlist (entry.pprev cleared while the previous bucket node still points at this entry).
- When the worker eventually runs, mlx5e_hv_vhca_stats_work() reads sagent->agent (NULL) and dereferences it inside mlx5_hv_vhca_agent_write().
Fix this by:
- Initializing priv->stats_agent.work before invoking mlx5_hv_vhca_agent_create(), so the work is always in a valid state when the control callback observes it.
- Adding a struct mlx5_hv_vhca_agent *ctx_update out-parameter to mlx5_hv_vhca_agent_create(). The helper writes the agent pointer to ctx_update before publishing into hv_vhca->agents[] and triggering the agents_update flow, so any callback subsequently invoked from that flow already sees a valid priv->stats_agent.agent. This avoids having the control callback participate in agent initialization.
While at it, access priv->stats_agent.agent with READ_ONCE()/WRITE_ONCE() for the cross-CPU access with the worker, and clear priv->stats_agent.buf on the agent_create() failure path.(CVE-2026-72342)
In the Linux kernel, the following vulnerability has been resolved:
seg6: validate SRH length before reading fixed fields
seg6_validate_srh() reads fixed SRH fields such as srh->type and srh->hdrlen before checking that the supplied length covers the fixed struct ipv6_sr_hdr fields.
The BPF SEG6 encap path reaches this with a BPF program-supplied pointer and length: bpf_lwt_push_encap() and the SEG6 local BPF END_B6 and END_B6_ENCAP actions call bpf_push_seg6_encap(), which forwards the length to seg6_validate_srh() with no minimum-size guard. A 2-byte SEG6 encap header can therefore make the validator read srh->type at offset 2 beyond the caller-supplied buffer.
Reject lengths shorter than the fixed SRH at the top of seg6_validate_srh(), before any field is read. This fixes the BPF helper path and keeps the common validator robust.(CVE-2026-72400)
In the Linux kernel, the following vulnerability has been resolved:
ice: fix FDIR CTRL VSI resource leak in ice_reset_all_vfs()
Resetting all VFs causes resource leak on VFs with FDIR filters enabled as CTRL VSIs are only invalidated and not freed. Fix by using ice_vf_ctrl_vsi_release() instead of ice_vf_ctrl_invalidate_vsi() which aligns behavior with the ice_reset_vf() function.
Reproduction: echo 1 > /sys/class/net/$pf/device/sriov_numvfs ethtool -N $vf flow-type ether proto 0x9000 action 0 echo 1 > /sys/class/net/$pf/device/reset(CVE-2026-72425)
In the Linux kernel, the following vulnerability has been resolved:
xfrm: validate selector family and prefixlen during match
syzbot reported a shift-out-of-bounds in xfrm_selector_match() due to AF_UNSPEC selector with large prefixlen (e.g. 128) matched against IPv4 flow (when XFRM_STATE_AF_UNSPEC is set).
Fix this by:
- Rejecting mismatched families in xfrm_selector_match.
- Returning false in addr4_match if prefixlen > 32.
- Returning false in addr_match if prefixlen > 128 (prevents overflow).(CVE-2026-72450)
In the Linux kernel, the following vulnerability has been resolved:
apparmor: aa_label_alloc use aa_label_free on alloc failure
aa_label_alloc() allocates a secid before allocating or taking the label proxy. If the later proxy step fails, the error path only freed the label memory, leaking any resources initialized by aa_label_init().
Use aa_label_free() on the failure path so partially initialized labels release their secid and other label resources before the backing memory is freed.(CVE-2026-72459)
In the Linux kernel, the following vulnerability has been resolved:
apparmor: check label build before no_new_privs test
aa_change_profile() builds a replacement label with fn_label_build_in_scope() before the no_new_privs subset check. The build helper can fail and return NULL or an ERR_PTR, but the result was passed to aa_label_is_unconfined_subset() before the existing IS_ERR_OR_NULL() check.
Reuse the existing target-label build failure handling immediately after the build. This preserves the current audit handling while preventing the subset helper from dereferencing an invalid label.(CVE-2026-72460)
In the Linux kernel, the following vulnerability has been resolved:
xprtrdma: Repost Receive buffers for malformed replies
rpcrdma_wc_receive() decrements the transport's Receive count for every completion before it dispatches a successful Receive to rpcrdma_reply_handler(). The handler must post a replacement Receive WR before returning unless ownership of the rep has moved elsewhere, as on the backchannel path.
Commit 2ae50ad68cd7 ("xprtrdma: Close window between waking RPC senders and posting Receives") moved the Receive refill out of rpcrdma_wc_receive(), where it had run ahead of every reply, into rpcrdma_reply_handler() so that the responder's credit grant could be parsed before reposting. The bad-version and short-reply exits never reach that refill: they recycle the rep and return without calling rpcrdma_post_recvs().
A remote peer can therefore drain the client's posted Receive queue by sending a sustained stream of replies that are shorter than the fixed transport header or that carry an unrecognized RPC/RDMA version. Each such reply consumes one posted Receive without replacing it. Once the queue empties, the peer's next Send finds no posted Receive and the transport stalls until reconnect.
Route both malformed-reply exits through the shared repost tail after recycling the rep, refilling against buf->rb_credits, the most recent accepted credit grant. Neither exit updates the congestion window, so RPCs admitted under the previous grant remain in flight awaiting replies. A smaller refill target would let a stream of malformed replies ratchet the posted Receive count down to the batch floor while the congestion window still admits rb_credits RPCs; a burst of valid replies to those RPCs could then overrun the posted Receives, and because the client connects with rnr_retry_count of zero, a single RNR NAK terminates the connection. Refilling against rb_credits also restores the target that applied to malformed replies before commit 2ae50ad68cd7 ("xprtrdma: Close window between waking RPC senders and posting Receives") when rpcrdma_post_recvs() computed it from rb_credits internally. rb_credits is at least one from connection establishment onward, so the repost path always keeps Receives posted.(CVE-2026-72464)
In the Linux kernel, the following vulnerability has been resolved:
xprtrdma: Sanitize the reply credit grant after parsing
The out_norqst exit in rpcrdma_reply_handler() branches away before the credit clamp, so a reply that matches no pending request reaches out_post carrying the raw credit value parsed from the wire. rpcrdma_post_recvs() does not bound its @needed argument: the refill loop allocates and chains Receive WRs until the count is satisfied or allocation fails. A peer that sends a well-formed reply carrying an unknown XID and an inflated credit grant therefore drives rep allocation and Receive posting past re_max_requests on every such reply.
Move the clamp to immediately after the credit field is parsed, ahead of the first branch that can reach out_post, so every later consumer sees a sanitized value. The cwnd update stays on the matched-request path.(CVE-2026-72465)
In the Linux kernel, the following vulnerability has been resolved:
xprtrdma: Fix bcall rep leak and unbounded peek
rpcrdma_is_bcall() decodes a reply's first words to decide whether the frame is a backchannel call. Two issues in that decode path let a short or malformed reply leak the receive buffer and drain the Receive queue.
First, the speculative peek
p = xdr_inline_decode(xdr, 0);
/* five p++ reads follow */
asks xdr_inline_decode() for zero bytes, which returns xdr->p without consulting xdr->end. The five subsequent __be32 reads can then walk up to 20 bytes past the wire payload into stale regbuf contents and misclassify the reply as a backchannel call.
Second, after the post-peek
p = xdr_inline_decode(xdr, 3 * sizeof(*p));
if (unlikely(!p))
return true;
the short-header arm returns true without calling rpcrdma_bc_receive_call(). The contract with the caller is that a true return transfers ownership of rep to the backchannel path:
rpcrdma_reply_handler()
if (rpcrdma_is_bcall(r_xprt, rep))
return; /* bare return, skips out_post */
...
out_post:
rpcrdma_post_recvs(r_xprt, credits + ...);
Because rpcrdma_bc_receive_call() never ran, no one took rep, but rpcrdma_reply_handler still bare-returns past rpcrdma_rep_put() and rpcrdma_post_recvs(). The rep, with its persistently DMA-mapped receive buffer, is orphaned on rb_all_reps and freed only at transport teardown. This completion reposts nothing, so its slot is reclaimed only when a later forward-channel reply reaches out_post and rpcrdma_post_recvs() allocates a fresh rep to backfill; absent that traffic the Receive queue drains and the peer's Sends draw RNR NAKs.
Fix by consulting xdr->end after the zero-length peek so the five __be32 reads cannot run unless 20 bytes of wire payload remain. A byte-precise comparison against xdr->end is required because a non-4-aligned receive rounds the stream's word count up past the true payload. Also return false from the short-header arm so the reply falls through the normal out_norqst cleanup chain (rpcrdma_rep_put() plus rpcrdma_post_recvs()).(CVE-2026-72466)
In the Linux kernel, the following vulnerability has been resolved:
xprtrdma: Decouple req recycling from RPC completion
rl_kref formerly served two distinct lifetimes through a single refcount: it gated when a Reply could wake its RPC task, and it gated when an rpcrdma_req could return to its free pool. The marshal path took the Send-side reference only when SGEs needed DMA-unmap (sc_unmap_count > 0), which made a Send carrying only pre-registered buffers an exception: the Reply handler dropped rl_kref from 1 to 0 and freed the req while the HCA might still be DMA-reading from its send buffer.
Give rl_kref a narrower job. The RPC layer takes one reference when slot allocation hands a req out. rpcrdma_prepare_send_sges() takes a Send-side reference unconditionally after WR preparation succeeds. xprt_rdma_free_slot() and xprt_rdma_bc_free_rqst() drop the RPC-layer reference; rpcrdma_sendctx_unmap() drops the Send-side reference. The req returns to its free pool only after both owners have signed off.
The existing kref_init(&req->rl_kref) call in rpcrdma_prepare_send_sges() is removed. Initialization moves to the slot-allocation paths (xprt_rdma_alloc_slot and rpcrdma_bc_rqst_get), and the release callback re-arms rl_kref before the req returns to a free pool. A re-init in the marshal path would discard the RPC-layer reference that already exists on entry.
Three invariants follow:
-
Any rpcrdma_req held by an rpc_rqst has rl_kref >= 1. xprt_rdma_alloc_slot(), rpcrdma_bc_rqst_get(), and the backlog-wake branch in xprt_rdma_alloc_slot() each kref_init rl_kref before publishing the req. Without this invariant, an RPC task that aborts between slot allocation and marshal (gss_refresh failure or signal during call_connect, for example) would drive xprt_release() -> xprt_rdma_free_slot() -> kref_put against a refcount of zero, saturating refcount_t and stranding the slot.
-
The Send-side reference is taken only after WR prep succeeds. A mapping failure in rpcrdma_prepare_send_sges() runs rpcrdma_sendctx_cancel(), which DMA-unmaps the sendctx and clears sc_req without touching rl_kref. The sendctx ring walks in rpcrdma_sendctx_put_locked() and rpcrdma_sendctxs_destroy() skip entries with sc_req == NULL, so a burst of -EIO marshal failures cannot hold reqs off rb_send_bufs.
-
The release callback re-arms rl_kref so the next consumer enters with the invariant satisfied.
Replies now complete the RPC directly. rpcrdma_reply_handler() calls rpcrdma_complete_rqst() in place of kref_put on the non-LocalInv branch. The LocalInv branch already completes the RPC from frwr_unmap_async() and is unaffected.
Because Send-side references can now outlive RPC completion, connection teardown drains sendctx entries whose unsignaled Sends never had a later signaled completion to walk the ring. rpcrdma_sendctxs_destroy() walks the active range and runs rpcrdma_sendctx_unmap() on each entry with a non-NULL sc_req before the request buffers are reset, and is moved ahead of rpcrdma_reqs_reset() in rpcrdma_xprt_disconnect() so the reqs are still in their pre-reset state when the Send-side refs are released.
The drain creates a teardown-ordering hazard on the backchannel path. With the new lifetime, releasing a bc_prealloc req from rpcrdma_req_release() re-adds it to bc_pa_list. The disconnect in xprt_rdma_destroy() runs after xprt_destroy_backchannel() has already emptied bc_pa_list, so the drained reqs would otherwise leak. xprt_rdma_destroy() now runs xprt_rdma_bc_destroy(xprt, 0) a second time after the disconnect to reclaim them.(CVE-2026-72473)
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: add bounds check to run_get_highest_vcn()
run_get_highest_vcn() parses a packed NTFS mapping-pairs buffer without any length bound, relying solely on a 0x00 terminator to stop. A crafted $LogFile UpdateMappingPairs record whose embedded attribute contains mapping-pairs runs without a terminator causes the function to read past the slab allocation, triggering a KASAN slab-out-of-bounds read on mount.
The sibling function run_unpack() received an analogous bounds-check in commit b62567bca474 ("ntfs3: add buffer boundary checks to run_unpack()"), but run_get_highest_vcn() was missed.
Take a run_buf_size parameter and reject any run header whose payload would extend past the buffer end, mirroring the pattern used by run_unpack(). The caller in fslog.c passes the remaining attribute bytes after the mapping-pairs offset.
KASAN report (on mainline v7.1 merge window HEAD):
BUG: KASAN: slab-out-of-bounds in run_get_highest_vcn+0x3c0/0x410 Read of size 1 at addr ffff88800e2d5400 by task mount/72 Call Trace: run_get_highest_vcn+0x3c0/0x410 do_action.isra.0+0x3ba8/0x7b50 log_replay+0x9ddd/0x10200 ntfs_loadlog_and_replay+0x4ad/0x610 ntfs_fill_super+0x214a/0x4540(CVE-2026-72478)
In the Linux kernel, the following vulnerability has been resolved:
bpf: Guard __get_user acesss with access_ok for uprobe_multi data
As reported by sashiko [1] we need to use access_ok to check the user space data bounds before we use __get-user to get it.
[1] https://lore.kernel.org/bpf/(CVE-2026-74258)
In the Linux kernel, the following vulnerability has been resolved:
power: supply: core: fix supplied_from allocations
If dts property power-supplies has multiple values, then accessing to psy->supplied_from[i-1] in __power_supply_populate_supplied_from will overrun supplied_from array.(CVE-2026-74271)
In the Linux kernel, the following vulnerability has been resolved:
tipc: require net admin for TIPCv2 netlink mutators
TIPCv2 registers mutating generic-netlink operations without admin permission flags. Generic netlink only checks CAP_NET_ADMIN when an operation sets GENL_ADMIN_PERM or GENL_UNS_ADMIN_PERM, so a local unprivileged process can currently change TIPC state through commands such as TIPC_NL_NET_SET, TIPC_NL_KEY_SET, TIPC_NL_KEY_FLUSH, and bearer enable/disable.
The legacy TIPC netlink API already checks netlink_net_capable(..., CAP_NET_ADMIN) for administrative commands. Give the TIPCv2 mutators the equivalent generic-netlink gate. Use GENL_UNS_ADMIN_PERM, which maps to the same namespace-aware CAP_NET_ADMIN check that netlink_net_capable() performs, so the behaviour matches the legacy path and keeps working for CAP_NET_ADMIN holders in a non-initial user namespace (containers).
A QEMU/KASAN repro run as uid/gid 65534 with zero effective capabilities previously succeeded in changing the network id and node identity, setting and flushing key material, and enabling/disabling a UDP bearer. With this patch applied the same operations fail with -EPERM.(CVE-2026-74283)
In the Linux kernel, the following vulnerability has been resolved:
sctp: validate embedded address parameter length
sctp_verify_asconf() and sctp_verify_param() only validate ADD_IP, DEL_IP, and SET_PRIMARY parameters against a fixed minimum size of sizeof(struct sctp_addip_param) + sizeof(struct sctp_paramhdr). This ensures the outer parameter is large enough to contain an embedded address parameter header, but does not verify that the embedded address parameter's declared length fits within the bounds of the outer parameter.
Later, sctp_process_param() and sctp_process_asconf_param() extract the embedded address parameter and pass it to af->from_addr_param(), which uses the address parameter length to parse the variable-length address payload. A malformed peer can therefore advertise an embedded address parameter length that exceeds the remaining bytes in the enclosing parameter.
Validate that addr_param->p.length does not exceed the space available after the sctp_addip_param header before processing the embedded address parameter. Reject malformed parameters when the embedded address length extends beyond the enclosing parameter bounds.
This prevents out-of-bounds reads when parsing malformed parameters carried in INIT or ASCONF processing paths.(CVE-2026-74287)
In the Linux kernel, the following vulnerability has been resolved:
bpf: Tighten cgroup storage cookie checks for prog arrays
The fix in commit abad3d0bad72 ("bpf: Fix oob access in cgroup local storage") is still incomplete. The prog-array compatibility check treats a program with no cgroup storage as compatible with any stored storage cookie. This allows a storage-less program to bridge a tail call chain between an entry program and a storage-using callee even though cgroup local storage at runtime still follows the caller's context, that is, A -> B(no storage) -> C(storage) path.
Requiring exact cookie equality would break the legitimate case of a storage-less leaf program being tail called from a storage-using one. Instead, only accept a zero storage cookie if the program cannot perform tail calls itself. This keeps A -> B(no storage) working while rejecting the A -> B(no storage) -> C(storage) bridge.(CVE-2026-74305)
In the Linux kernel, the following vulnerability has been resolved:
bpf: Reject sleepable BPF_LSM_CGROUP programs at load time
The cgroup shim runs under rcu_read_lock_dont_migrate(), so we should not attach any sleepable BPF programs there. Add support to the verifier to explicitly reject attempts to load sleepable BPF programs destined for LSM cgroup attachment.
Without this, we get the following splat from a BPF_LSM_CGROUP program marked BPF_F_SLEEPABLE attached to file_open when it calls bpf_get_dentry_xattr():
BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:1567 in_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 34317, name: load preempt_count: 0, expected: 0 RCU nest depth: 2, expected: 0 Call Trace: down_read+0x76/0x480 ext4_xattr_get+0x11f/0x700 __vfs_getxattr+0xf0/0x150 bpf_get_dentry_xattr+0xbb/0xf0 bpf_prog_e76a298dac9218c6_test_open+0x6a/0x85 __cgroup_bpf_run_lsm_current+0x326/0x840 bpf_trampoline_6442534646+0x62/0x14d security_file_open+0x34/0x60 do_dentry_open+0x340/0x1260 vfs_open+0x7a/0x440 path_openat+0x1bac/0x30a0
libbpf provides a .s named section variant for every sleepable program type except lsm_cgroup, reflecting that per-cgroup LSM programs are intended to only run in a non-sleepable context.
The above splat was obtained by bypassing libbpf by using bpf(2) directly.(CVE-2026-74338)
In the Linux kernel, the following vulnerability has been resolved:
bpf: Clear rb node linkage when freeing bpf_rb_root
bpf_rb_root_free() detaches the root by copying the current rb_root_cached and then replacing the live root with RB_ROOT_CACHED. It then walks the copied root and drops each object contained in the tree.
This leaves the rb node state intact while dropping the object. If the object is refcounted and survives the drop, its bpf_rb_node_kern still contains an owner pointer to the freed root and stale rb tree linkage. If a later bpf_rb_root allocation reuses the same address, bpf_rbtree_remove() can incorrectly pass the owner check and call rb_erase_cached() on a node whose rb pointers belong to the old tree.
Mirror the list draining behavior by marking nodes as busy while the root is being detached, then clear the rb node and release the owner before dropping the containing object. This makes surviving nodes unowned and safe to reject from remove or accept for a later add.(CVE-2026-74344)
In the Linux kernel, the following vulnerability has been resolved:
bpf: fix UAF by restoring RCU-delayed inode freeing in bpffs
commit 4f375ade6aa9 ("bpf: Avoid RCU context warning when unpinning htab with internal structs") moved inode cleanup from ->free_inode() into ->destroy_inode() to avoid sleeping in RCU context when calling bpf_any_put(). However this removed the RCU delay on freeing the inode itself and the cached symlink body (i_link), both of which can be accessed by RCU pathwalk (pick_link, may_lookup etc.).
This causes a use-after-free when a concurrent unlinkat() drops the last inode reference and destroy_inode() frees the inode immediately, while another task is still walking the path in RCU mode and reads inode->i_opflags (offset +2) inside current_time() -> is_mgtime().
KASAN reports: BUG: KASAN: slab-use-after-free in is_mgtime include/linux/fs.h:2313 Read of size 2 at addr ffff8880407e4282 (offset +2 = i_opflags)
The rules (per Al Viro): ->destroy_inode() called immediately, can sleep, use for blocking cleanup e.g. bpf_any_put() ->free_inode() called after RCU grace period, use for freeing inode and anything RCU-accessible e.g. i_link
Fix: split the two concerns properly: - keep bpf_any_put() in bpf_destroy_inode() since it is blocking and needs to run promptly - introduce bpf_free_inode() to handle kfree(i_link) and free_inode_nonrcu() with proper RCU delay, preventing the UAF(CVE-2026-74363)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/rxe: Copy WQE to local buffer in non-SRQ receive path
For non-SRQ QPs, the responder reads WQE fields directly from the shared queue buffer mapped into userspace. This allows a malicious user to modify fields like num_sge or sge entries while the kernel is processing the WQE, leading to out-of-bounds reads in rxe_resp_check_length() and copy_data().
Introduce get_recv_wqe() that validates num_sge and copies the WQE to a kernel-local buffer before processing, matching the approach already used for SRQ WQEs in get_srq_wqe(). The srq_wqe buffer is reused since SRQ and non-SRQ paths are mutually exclusive per QP.(CVE-2026-74377)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/rxe: Fix TOCTOU heap overflow in get_srq_wqe
get_srq_wqe() reads wqe->dma.num_sge from the shared receive queue buffer, which is mapped into userspace. It validates num_sge against max_sge, but then re-reads the same field to calculate the memcpy size. A concurrent userspace thread can modify num_sge between validation and use, causing a heap buffer overflow when copying the WQE into qp->resp.srq_wqe.
Read num_sge into a local variable and use it for both the bounds check and the size calculation.(CVE-2026-74378)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/srpt: fix integer overflow in immediate data length check
imm_buf->len is a user-controlled uint32_t received from the network. Adding it to imm_data_offset without overflow checking allows a malicious initiator to send len=0xFFFFFFFF, causing req_size to wrap around to a small value, bypassing the bounds check, and subsequently passing a ~4GB length to sg_init_one().
Use check_add_overflow() to detect wrapping before the comparison.(CVE-2026-74394)
In the Linux kernel, the following vulnerability has been resolved:
IB/mlx5: Fix transport-domain rollback and initialize lb mutex earlier
mlx5_ib_alloc_transport_domain() allocates a transport domain and then may fail in mlx5_ib_enable_lb(). In that case, the allocated TD is leaked.
Fix this by deallocating the TD when mlx5_ib_enable_lb() returns an error. Also return 0 explicitly in the no-loopback-capability success branch, and move dev->lb.mutex initialization to mlx5_ib_stage_init_init().(CVE-2026-74397)
In the Linux kernel, the following vulnerability has been resolved:
ipv6: addrconf: bail out of dad_failure when state is no longer POSTDAD
addrconf_dad_failure() transitions ifp->state from DAD to POSTDAD via addrconf_dad_end(), which drops ifp->lock on return. The lock is re-acquired after net_info_ratelimited(). A concurrent ipv6_del_addr() can take the lock in that window, set ifp->state to DEAD and run list_del_rcu(&ifp->if_list).
addrconf_dad_failure() then overwrites DEAD with ERRDAD at errdad: and schedules a new dad_work. The work calls ipv6_del_addr() again, hitting the already-poisoned list entry:
general protection fault: 0000 [#1] SMP NOPTI CPU: 4 PID: 217 Comm: kworker/4:1 Workqueue: ipv6_addrconf addrconf_dad_work RIP: 0010:ipv6_del_addr+0xe9/0x280 RAX: dead000000000122 Call Trace: addrconf_dad_stop+0x113/0x140 addrconf_dad_work+0x28c/0x430 process_one_work+0x1eb/0x3b0 worker_thread+0x4d/0x400 kthread+0x104/0x140 ret_from_fork+0x35/0x40
Fold the addrconf_dad_end() logic into addrconf_dad_failure() under a single ifp->lock critical section. The STABLE_PRIVACY branch temporarily drops ifp->lock around address regeneration, so at lock_errdad: verify the state is still POSTDAD before transitioning to ERRDAD; bail out otherwise to avoid overwriting a state set by another path while the lock was released.(CVE-2026-74398)
In the Linux kernel, the following vulnerability has been resolved:
vxlan: Fix potential null-ptr-deref in vxlan_gro_prepare_receive().
udp_tunnel_sock_release() could set sk->sk_user_data to NULL while vxlan_gro_prepare_receive() is running.
Let's check if rcu_dereference_sk_user_data() is NULL after skb_gro_remcsum_init().(CVE-2026-74406)
| URL | Type | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-6.6.0-145.3.29.160.oe2403sp3.aarch64.rpm",
"bpftool-debuginfo-6.6.0-145.3.29.160.oe2403sp3.aarch64.rpm",
"kernel-6.6.0-145.3.29.160.oe2403sp3.aarch64.rpm",
"kernel-debuginfo-6.6.0-145.3.29.160.oe2403sp3.aarch64.rpm",
"kernel-debugsource-6.6.0-145.3.29.160.oe2403sp3.aarch64.rpm",
"kernel-devel-6.6.0-145.3.29.160.oe2403sp3.aarch64.rpm",
"kernel-extra-modules-6.6.0-145.3.29.160.oe2403sp3.aarch64.rpm",
"kernel-headers-6.6.0-145.3.29.160.oe2403sp3.aarch64.rpm",
"kernel-source-6.6.0-145.3.29.160.oe2403sp3.aarch64.rpm",
"kernel-tools-6.6.0-145.3.29.160.oe2403sp3.aarch64.rpm",
"kernel-tools-debuginfo-6.6.0-145.3.29.160.oe2403sp3.aarch64.rpm",
"kernel-tools-devel-6.6.0-145.3.29.160.oe2403sp3.aarch64.rpm",
"perf-6.6.0-145.3.29.160.oe2403sp3.aarch64.rpm",
"perf-debuginfo-6.6.0-145.3.29.160.oe2403sp3.aarch64.rpm",
"python3-perf-6.6.0-145.3.29.160.oe2403sp3.aarch64.rpm",
"python3-perf-debuginfo-6.6.0-145.3.29.160.oe2403sp3.aarch64.rpm"
],
"src": [
"kernel-6.6.0-145.3.29.160.oe2403sp3.src.rpm"
],
"x86_64": [
"bpftool-6.6.0-145.3.29.160.oe2403sp3.x86_64.rpm",
"bpftool-debuginfo-6.6.0-145.3.29.160.oe2403sp3.x86_64.rpm",
"kernel-6.6.0-145.3.29.160.oe2403sp3.x86_64.rpm",
"kernel-debuginfo-6.6.0-145.3.29.160.oe2403sp3.x86_64.rpm",
"kernel-debugsource-6.6.0-145.3.29.160.oe2403sp3.x86_64.rpm",
"kernel-devel-6.6.0-145.3.29.160.oe2403sp3.x86_64.rpm",
"kernel-extra-modules-6.6.0-145.3.29.160.oe2403sp3.x86_64.rpm",
"kernel-headers-6.6.0-145.3.29.160.oe2403sp3.x86_64.rpm",
"kernel-source-6.6.0-145.3.29.160.oe2403sp3.x86_64.rpm",
"kernel-tools-6.6.0-145.3.29.160.oe2403sp3.x86_64.rpm",
"kernel-tools-debuginfo-6.6.0-145.3.29.160.oe2403sp3.x86_64.rpm",
"kernel-tools-devel-6.6.0-145.3.29.160.oe2403sp3.x86_64.rpm",
"perf-6.6.0-145.3.29.160.oe2403sp3.x86_64.rpm",
"perf-debuginfo-6.6.0-145.3.29.160.oe2403sp3.x86_64.rpm",
"python3-perf-6.6.0-145.3.29.160.oe2403sp3.x86_64.rpm",
"python3-perf-debuginfo-6.6.0-145.3.29.160.oe2403sp3.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:24.03-LTS-SP3",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS-SP3"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.6.0-145.3.29.160.oe2403sp3"
}
],
"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:\n\nnet: hns3: add VLAN id validation before using\n\nCurrently, the VLAN id may be used without validation when\nreceive a VLAN configuration mailbox from VF. The length of\nvlan_del_fail_bmap is BITS_TO_LONGS(VLAN_N_VID). It may cause\nout-of-bounds memory access once the VLAN id is bigger than\nor equal to VLAN_N_VID.\n\nTherefore, VLAN id needs to be checked to ensure it is within\nthe range of VLAN_N_VID.(CVE-2025-71112)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: fix string copying in parse_apply_sb_mount_options()\n\nstrscpy_pad() can\u0026apos;t be used to copy a non-NUL-term string into a NUL-term\nstring of possibly bigger size. Commit 0efc5990bca5 (\u0026quot;string.h: Introduce\nmemtostr() and memtostr_pad()\u0026quot;) provides additional information in that\nregard. So if this happens, the following warning is observed:\n\nstrnlen: detected buffer overflow: 65 byte read of buffer size 64\nWARNING: CPU: 0 PID: 28655 at lib/string_helpers.c:1032 __fortify_report+0x96/0xc0 lib/string_helpers.c:1032\nModules linked in:\nCPU: 0 UID: 0 PID: 28655 Comm: syz-executor.3 Not tainted 6.12.54-syzkaller-00144-g5f0270f1ba00 #0\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\nRIP: 0010:__fortify_report+0x96/0xc0 lib/string_helpers.c:1032\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __fortify_panic+0x1f/0x30 lib/string_helpers.c:1039\n strnlen include/linux/fortify-string.h:235 [inline]\n sized_strscpy include/linux/fortify-string.h:309 [inline]\n parse_apply_sb_mount_options fs/ext4/super.c:2504 [inline]\n __ext4_fill_super fs/ext4/super.c:5261 [inline]\n ext4_fill_super+0x3c35/0xad00 fs/ext4/super.c:5706\n get_tree_bdev_flags+0x387/0x620 fs/super.c:1636\n vfs_get_tree+0x93/0x380 fs/super.c:1814\n do_new_mount fs/namespace.c:3553 [inline]\n path_mount+0x6ae/0x1f70 fs/namespace.c:3880\n do_mount fs/namespace.c:3893 [inline]\n __do_sys_mount fs/namespace.c:4103 [inline]\n __se_sys_mount fs/namespace.c:4080 [inline]\n __x64_sys_mount+0x280/0x300 fs/namespace.c:4080\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0x64/0x140 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nSince userspace is expected to provide s_mount_opts field to be at most 63\ncharacters long with the ending byte being NUL-term, use a 64-byte buffer\nwhich matches the size of s_mount_opts, so that strscpy_pad() does its job\nproperly. Return with error if the user still managed to provide a\nnon-NUL-term string here.\n\nFound by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2025-71123)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/umad: Reject negative data_len in ib_umad_write\n\nib_umad_write computes data_len from user-controlled count and the\nMAD header sizes. With a mismatched user MAD header size and RMPP\nheader length, data_len can become negative and reach ib_create_send_mad().\nThis can make the padding calculation exceed the segment size and trigger\nan out-of-bounds memset in alloc_send_rmpp_list().\n\nAdd an explicit check to reject negative data_len before creating the\nsend buffer.\n\nKASAN splat:\n[ 211.363464] BUG: KASAN: slab-out-of-bounds in ib_create_send_mad+0xa01/0x11b0\n[ 211.364077] Write of size 220 at addr ffff88800c3fa1f8 by task spray_thread/102\n[ 211.365867] ib_create_send_mad+0xa01/0x11b0\n[ 211.365887] ib_umad_write+0x853/0x1c80(CVE-2026-23243)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvme: fix memory allocation in nvme_pr_read_keys()\n\nnvme_pr_read_keys() takes num_keys from userspace and uses it to\ncalculate the allocation size for rse via struct_size(). The upper\nlimit is PR_KEYS_MAX (64K).\n\nA malicious or buggy userspace can pass a large num_keys value that\nresults in a 4MB allocation attempt at most, causing a warning in\nthe page allocator when the order exceeds MAX_PAGE_ORDER.\n\nTo fix this, use kvzalloc() instead of kzalloc().\n\nThis bug has the same reasoning and fix with the patch below:\nhttps://lore.kernel.org/linux-block/(CVE-2026-23244)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: dvb-core: fix wrong reinitialization of ringbuffer on reopen\n\ndvb_dvr_open() calls dvb_ringbuffer_init() when a new reader opens the\nDVR device. dvb_ringbuffer_init() calls init_waitqueue_head(), which\nreinitializes the waitqueue list head to empty.\n\nSince dmxdev-\u0026gt;dvr_buffer.queue is a shared waitqueue (all opens of the\nsame DVR device share it), this orphans any existing waitqueue entries\nfrom io_uring poll or epoll, leaving them with stale prev/next pointers\nwhile the list head is reset to {self, self}.\n\nThe waitqueue and spinlock in dvr_buffer are already properly\ninitialized once in dvb_dmxdev_init(). The open path only needs to\nreset the buffer data pointer, size, and read/write positions.\n\nReplace the dvb_ringbuffer_init() call in dvb_dvr_open() with direct\nassignment of data/size and a call to dvb_ringbuffer_reset(), which\nproperly resets pread, pwrite, and error with correct memory ordering\nwithout touching the waitqueue or spinlock.(CVE-2026-23253)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\napparmor: fix unprivileged local user can do privileged policy management\n\nAn unprivileged local user can load, replace, and remove profiles by\nopening the apparmorfs interfaces, via a confused deputy attack, by\npassing the opened fd to a privileged process, and getting the\nprivileged process to write to the interface.\n\nThis does require a privileged target that can be manipulated to do\nthe write for the unprivileged process, but once such access is\nachieved full policy management is possible and all the possible\nimplications that implies: removing confinement, DoS of system or\ntarget applications by denying all execution, by-passing the\nunprivileged user namespace restriction, to exploiting kernel bugs for\na local privilege escalation.\n\nThe policy management interface can not have its permissions simply\nchanged from 0666 to 0600 because non-root processes need to be able\nto load policy to different policy namespaces.\n\nInstead ensure the task writing the interface has privileges that\nare a subset of the task that opened the interface. This is already\ndone via policy for confined processes, but unconfined can delegate\naccess to the opened fd, by-passing the usual policy check.(CVE-2026-23268)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nperf: Fix __perf_event_overflow() vs perf_remove_from_context() race\n\nMake sure that __perf_event_overflow() runs with IRQs disabled for all\npossible callchains. Specifically the software events can end up running\nit with only preemption disabled.\n\nThis opens up a race vs perf_event_exit_event() and friends that will go\nand free various things the overflow path expects to be present, like\nthe BPF program.(CVE-2026-23271)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/vmwgfx: Return the correct value in vmw_translate_ptr functions\n\nBefore the referenced fixes these functions used a lookup function that\nreturned a pointer. This was changed to another lookup function that\nreturned an error code with the pointer becoming an out parameter.\n\nThe error path when the lookup failed was not changed to reflect this\nchange and the code continued to return the PTR_ERR of the now\nuninitialized pointer. This could cause the vmw_translate_ptr functions\nto return success when they actually failed causing further uninitialized\nand OOB accesses.(CVE-2026-23317)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix a UAF issue in bpf_trampoline_link_cgroup_shim\n\nThe root cause of this bug is that when \u0026apos;bpf_link_put\u0026apos; reduces the\nrefcount of \u0026apos;shim_link-\u0026gt;link.link\u0026apos; to zero, the resource is considered\nreleased but may still be referenced via \u0026apos;tr-\u0026gt;progs_hlist\u0026apos; in\n\u0026apos;cgroup_shim_find\u0026apos;. The actual cleanup of \u0026apos;tr-\u0026gt;progs_hlist\u0026apos; in\n\u0026apos;bpf_shim_tramp_link_release\u0026apos; is deferred. During this window, another\nprocess can cause a use-after-free via \u0026apos;bpf_trampoline_link_cgroup_shim\u0026apos;.\n\nBased on Martin KaFai Lau\u0026apos;s suggestions, I have created a simple patch.\n\nTo fix this:\n Add an atomic non-zero check in \u0026apos;bpf_trampoline_link_cgroup_shim\u0026apos;.\n Only increment the refcount if it is not already zero.\n\nTesting:\n I verified the fix by adding a delay in\n \u0026apos;bpf_shim_tramp_link_release\u0026apos; to make the bug easier to trigger:\n\nstatic void bpf_shim_tramp_link_release(struct bpf_link *link)\n{\n\t/* ... */\n\tif (!shim_link-\u0026gt;trampoline)\n\t\treturn;\n\n+\tmsleep(100);\n\tWARN_ON_ONCE(bpf_trampoline_unlink_prog(\u0026amp;shim_link-\u0026gt;link,\n\t\tshim_link-\u0026gt;trampoline, NULL));\n\tbpf_trampoline_put(shim_link-\u0026gt;trampoline);\n}\n\nBefore the patch, running a PoC easily reproduced the crash(almost 100%)\nwith a call trace similar to KaiyanM\u0026apos;s report.\nAfter the patch, the bug no longer occurs even after millions of\niterations.(CVE-2026-23319)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix stack-out-of-bounds write in devmap\n\nget_upper_ifindexes() iterates over all upper devices and writes their\nindices into an array without checking bounds.\n\nAlso the callers assume that the max number of upper devices is\nMAX_NEST_DEV and allocate excluded_devices[1+MAX_NEST_DEV] on the stack,\nbut that assumption is not correct and the number of upper devices could\nbe larger than MAX_NEST_DEV (e.g., many macvlans), causing a\nstack-out-of-bounds write.\n\nAdd a max parameter to get_upper_ifindexes() to avoid the issue.\nWhen there are too many upper devices, return -EOVERFLOW and abort the\nredirect.\n\nTo reproduce, create more than MAX_NEST_DEV(8) macvlans on a device with\nan XDP program attached using BPF_F_BROADCAST | BPF_F_EXCLUDE_INGRESS.\nThen send a packet to the device to trigger the XDP redirect path.(CVE-2026-23359)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf, arm64: Force 8-byte alignment for JIT buffer to prevent atomic tearing\n\nstruct bpf_plt contains a u64 target field. Currently, the BPF JIT\nallocator requests an alignment of 4 bytes (sizeof(u32)) for the JIT\nbuffer.\n\nBecause the base address of the JIT buffer can be 4-byte aligned (e.g.,\nending in 0x4 or 0xc), the relative padding logic in build_plt() fails\nto ensure that target lands on an 8-byte boundary.\n\nThis leads to two issues:\n1. UBSAN reports misaligned-access warnings when dereferencing the\n structure.\n2. More critically, target is updated concurrently via WRITE_ONCE() in\n bpf_arch_text_poke() while the JIT\u0026apos;d code executes ldr. On arm64,\n 64-bit loads/stores are only guaranteed to be single-copy atomic if\n they are 64-bit aligned. A misaligned target risks a torn read,\n causing the JIT to jump to a corrupted address.\n\nFix this by increasing the allocation alignment requirement to 8 bytes\n(sizeof(u64)) in bpf_jit_binary_pack_alloc(). This anchors the base of\nthe JIT buffer to an 8-byte boundary, allowing the relative padding math\nin build_plt() to correctly align the target field.(CVE-2026-23383)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nSquashfs: check metadata block offset is within range\n\nSyzkaller reports a \u0026quot;general protection fault in squashfs_copy_data\u0026quot;\n\nThis is ultimately caused by a corrupted index look-up table, which\nproduces a negative metadata block offset.\n\nThis is subsequently passed to squashfs_copy_data (via\nsquashfs_read_metadata) where the negative offset causes an out of bounds\naccess.\n\nThe fix is to check that the offset is within range in\nsquashfs_read_metadata. This will trap this and other cases.(CVE-2026-23388)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: af_alg - Fix page reassignment overflow in af_alg_pull_tsgl\n\nWhen page reassignment was added to af_alg_pull_tsgl the original\nloop wasn\u0026apos;t updated so it may try to reassign one more page than\nnecessary.\n\nAdd the check to the reassignment so that this does not happen.\n\nAlso update the comment which still refers to the obsolete offset\nargument.(CVE-2026-43078)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: algif_aead - snapshot IV for async AEAD requests\n\nAF_ALG AEAD AIO requests currently use the socket-wide IV buffer during\nrequest processing. For async requests, later socket activity can\nupdate that shared state before the original request has fully\ncompleted, which can lead to inconsistent IV handling.\n\nSnapshot the IV into per-request storage when preparing the AEAD\nrequest, so in-flight operations no longer depend on mutable socket\nstate.(CVE-2026-46028)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsched/fair: Clear rel_deadline when initializing forked entities\n\nA yield-triggered crash can happen when a newly forked sched_entity\nenters the fair class with se-\u0026gt;rel_deadline unexpectedly set.\n\nThe failing sequence is:\n\n 1. A task is forked while se-\u0026gt;rel_deadline is still set.\n 2. __sched_fork() initializes vruntime, vlag and other sched_entity\n state, but does not clear rel_deadline.\n 3. On the first enqueue, enqueue_entity() calls place_entity().\n 4. Because se-\u0026gt;rel_deadline is set, place_entity() treats se-\u0026gt;deadline\n as a relative deadline and converts it to an absolute deadline by\n adding the current vruntime.\n 5. However, the forked entity\u0026apos;s deadline is not a valid inherited\n relative deadline for this new scheduling instance, so the conversion\n produces an abnormally large deadline.\n 6. If the task later calls sched_yield(), yield_task_fair() advances\n se-\u0026gt;vruntime to se-\u0026gt;deadline.\n 7. The inflated vruntime is then used by the following enqueue path,\n where the vruntime-derived key can overflow when multiplied by the\n entity weight.\n 8. This corrupts cfs_rq-\u0026gt;sum_w_vruntime, breaks EEVDF eligibility\n calculation, and can eventually make all entities appear ineligible.\n pick_next_entity() may then return NULL unexpectedly, leading to a\n later NULL dereference.\n\nA captured trace shows the effect clearly. Before yield, the entity\u0026apos;s\nvruntime was around:\n\n 9834017729983308\n\nAfter yield_task_fair() executed:\n\n se-\u0026gt;vruntime = se-\u0026gt;deadline\n\nthe vruntime jumped to:\n\n 19668035460670230\n\nand the deadline was later advanced further to:\n\n 19668035463470230\n\nThis shows that the deadline had already become abnormally large before\nyield_task_fair() copied it into vruntime.\n\nrel_deadline is only meaningful when se-\u0026gt;deadline really carries a\nrelative deadline that still needs to be placed against vruntime. A\nfreshly forked sched_entity should not inherit or retain this state.\nClear se-\u0026gt;rel_deadline in __sched_fork(), together with the other\nsched_entity runtime state, so that the first enqueue does not interpret\nthe new entity\u0026apos;s deadline as a stale relative deadline.(CVE-2026-52980)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: hisilicon/sec2 - prevent req used-after-free for sec\n\nDuring packet transmission, if the system is under heavy load,\nthe hardware might complete processing the packet and free the\nrequest memory (req) before the transmission function finishes.\nIf the software subsequently accesses this req, a use-after-free\nerror will occur. The qp_ctx memory exists throughout the packet\nsending process, so replace the req with the qp_ctx.(CVE-2026-53055)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsctp: validate cached peer INIT chunk length in COOKIE_ECHO processing\n\nWhen a listening SCTP server processes a COOKIE_ECHO chunk, the cached\npeer INIT chunk embedded after the cookie is parsed and its parameters\nare later walked by sctp_process_init() using sctp_walk_params().\n\nHowever, the chunk header length of this cached INIT chunk was not\nvalidated against the remaining buffer in the COOKIE_ECHO payload. If\nthe length field is inflated, the parameter walk can run beyond the\nactual received data, leading to out-of-bounds reads and potential\nmemory corruption during later parameter handling (e.g. STATE_COOKIE\nprocessing and kmemdup() copies).\n\nAdd a bounds check in sctp_unpack_cookie() to ensure the cached INIT\nchunk length does not exceed the available data in the COOKIE_ECHO\nbuffer before it is used.(CVE-2026-53246)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nserial: 8250_dw: unregister 8250 port if clk_notifier_register() fails\n\ndw8250_probe() registers the 8250 port via serial8250_register_8250_port()\nand then, if the device has a clock, registers a clock notifier. If\nclk_notifier_register() fails, probe returns the error but leaves the\n8250 port registered. The matching serial8250_unregister_port() lives\nin dw8250_remove(), which is not called when probe fails, so the port\nslot stays occupied until the device is rebound or the system is\nrebooted. The devm-allocated driver data is freed while the port still\nreferences it (via the saved private_data and serial_in/serial_out\ncallbacks), so any access to that port slot before a rebind is a\nuse-after-free hazard.\n\nUnregister the port on the clk_notifier_register() error path.(CVE-2026-53384)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npNFS: Fix use-after-free in pnfs_update_layout()\n\nWhen hitting the NFS_LAYOUT_RETURN branch in pnfs_update_layout(),\nthe code calls pnfs_prepare_to_retry_layoutget(lo). If it succeeds,\npnfs_put_layout_hdr(lo) is called before trace_pnfs_update_layout(),\nwhich still references \u0026apos;lo\u0026apos;. This results in a use-after-free when the\ntracepoint accesses lo\u0026apos;s fields.\n\nFix this by moving the tracepoint call before pnfs_put_layout_hdr(lo).(CVE-2026-63800)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: skmsg: preserve sg.copy across SG transforms\n\nThe sk_msg sg.copy bitmap is part of the scatterlist entry ownership\nstate. A set bit tells sk_msg_compute_data_pointers() not to expose the\nentry through writable BPF ctx-\u0026gt;data. This protects entries backed by\npages that are not private to the sk_msg, such as splice-backed file\npage-cache pages.\n\nSeveral sk_msg transform paths move, copy, split, or compact\nmsg-\u0026gt;sg.data[] entries without moving the matching sg.copy bit. This can\nmake an externally backed entry arrive at a new slot with a clear copy\nbit. A later SK_MSG verdict can then expose sg_virt(sge) as writable\nctx-\u0026gt;data and BPF stores can modify the original page cache.\n\nKeep sg.copy synchronized with sg.data[] whenever entries are\ntransferred, shifted, split, or copied into a new sk_msg. Clear the bit\nwhen an entry is replaced by a newly allocated private page or freed.\nThis covers the BPF pull/push/pop helpers, sk_msg_shift_left/right(),\nsk_msg_xfer(), and tls_split_open_record(), including the partial tail\nentry created during TLS open-record splitting.(CVE-2026-63830)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: target: iscsi: Validate CHAP_R length before base64 decode\n\nchap_server_compute_hash() allocates client_digest as\nkzalloc(chap-\u0026gt;digest_size) and then, for BASE64-encoded responses,\npasses chap_r directly to chap_base64_decode() without checking whether\nthe input length could produce more than digest_size bytes of output.\n\nchap_base64_decode() writes to the destination unconditionally as long\nas there is input to consume. With MAX_RESPONSE_LENGTH set to 128 and\nthe \u0026quot;0b\u0026quot; prefix stripped by extract_param(), up to 127 base64 characters\ncan reach the decoder. 127 characters decode to 95 bytes. For SHA-256\n(digest_size=32) this overflows client_digest by 63 bytes; for MD5\n(digest_size=16) the overflow is 79 bytes.\n\nThe length check at line 344 fires after the write has already happened.\n\nThe HEX branch in the same switch statement already validates the length\nup front. Apply the same approach to the BASE64 branch: strip trailing\nbase64 padding characters, then reject any input whose data length\nexceeds DIV_ROUND_UP(digest_size * 4, 3) before calling the decoder.\n\nStripping trailing \u0026apos;=\u0026apos; before the comparison handles both padded and\nunpadded encodings. chap_base64_decode() already returns early on \u0026apos;=\u0026apos;,\nso the full original string is still passed to the decoder unchanged.\n\nThe mutual CHAP path decodes CHAP_C into initiatorchg_binhex, which is\nkzalloc(CHAP_CHALLENGE_STR_LEN). extract_param() caps initiatorchg at\nCHAP_CHALLENGE_STR_LEN characters, so at most CHAP_CHALLENGE_STR_LEN-1\nbase64 characters reach the decoder. The maximum decoded size,\nDIV_ROUND_UP((CHAP_CHALLENGE_STR_LEN-1) * 3, 4), is less than\nCHAP_CHALLENGE_STR_LEN, so no overflow is possible there. A comment is\nadded at the call site to document this.(CVE-2026-63886)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: target: iscsi: Bound iscsi_encode_text_output() appends to rsp_buf\n\niscsi_encode_text_output() concatenates \u0026quot;key=value\\0\u0026quot; records into\nlogin-\u0026gt;rsp_buf, an 8192-byte kzalloc(MAX_KEY_VALUE_PAIRS) buffer\nallocated in iscsit_alloc_login_setup_buffer(). The three sprintf() call\nsites in this function (lines 1398, 1411, 1424 in v7.1-rc2) never check\nthe remaining buffer capacity:\n\n\t*length += sprintf(output_buf, \u0026quot;%s=%s\u0026quot;, er-\u0026gt;key, er-\u0026gt;value);\n\t*length += 1;\n\toutput_buf = textbuf + *length;\n\nThe 8192-byte ceiling at iscsi_target_check_login_request() bounds the\n*input* Login PDU payload, but a single PDU can carry up to 2048 minimal\nfour-byte \u0026quot;a=b\\0\u0026quot; pairs, each unknown key expanding to a 16-byte\n\u0026quot;a=NotUnderstood\\0\u0026quot; output record via iscsi_add_notunderstood_response().\n2048 * 16 = 32 KiB of output into an 8 KiB buffer, producing a ~24 KiB\nheap overrun in the kmalloc-8k slab.\n\nThe fix introduces a static iscsi_encode_text_record() helper that uses\nsnprintf() with a per-call bounds check against the remaining buffer,\nand threads a u32 textbuf_size parameter through\niscsi_encode_text_output(). Both call sites in\niscsi_target_handle_csg_zero() (PHASE_SECURITY) and\niscsi_target_handle_csg_one() (PHASE_OPERATIONAL) pass\nMAX_KEY_VALUE_PAIRS. On overflow the encoder logs the condition, calls\niscsi_release_extra_responses() to drop queued records, and returns -1;\nboth caller sites now emit ISCSI_STATUS_CLS_INITIATOR_ERR /\nISCSI_LOGIN_STATUS_INIT_ERR via iscsit_tx_login_rsp() before returning,\nso the initiator sees an explicit failed-login response rather than a\nsilent connection drop. (Prior to this patch only the PHASE_OPERATIONAL\ncaller did that; the PHASE_SECURITY caller is converted to the same\nshape.)(CVE-2026-63887)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: target: iscsi: Fix CRC overread and double-free in iscsit_handle_text_cmd()\n\nTwo latent bugs in the Text-phase handler, both present since the\noriginal LIO integration in commit e48354ce078c (\u0026quot;iscsi-target: Add\niSCSI fabric support for target v4.1\u0026quot;):\n\n1) DataDigest CRC buffer overread (4 bytes past text_in).\n\n text_in is kzalloc()\u0026apos;d at ALIGN(payload_length, 4). rx_size is then\n incremented by ISCSI_CRC_LEN to make room for the received DataDigest\n in the iovec, but the same (now-bumped) rx_size is passed as the\n buffer length to iscsit_crc_buf():\n\n if (conn-\u0026gt;conn_ops-\u0026gt;DataDigest) {\n ...\n rx_size += ISCSI_CRC_LEN;\n }\n ...\n if (conn-\u0026gt;conn_ops-\u0026gt;DataDigest) {\n data_crc = iscsit_crc_buf(text_in, rx_size, 0, NULL);\n\n iscsit_crc_buf() walks rx_size bytes of text_in with crc32c(), so\n when DataDigest is negotiated it reads 4 bytes past the end of the\n text_in allocation. KASAN reproduces this directly on the unpatched\n mainline tree as slab-out-of-bounds in crc32c() called from the Text\n PDU path. The OOB bytes feed crc32c() and are then compared against\n the initiator-supplied checksum, so the value does not flow back to\n the attacker, but the kernel does read past the buffer on every Text\n PDU with DataDigest=CRC32C.\n\n Fix by passing the actual padded payload length\n (ALIGN(payload_length, 4)) that was used for the kzalloc().\n\n2) Stale cmd-\u0026gt;text_in_ptr re-free (double-free) on ERL\u0026gt;0 bad DataDigest\n drop.\n\n On DataDigest mismatch with ErrorRecoveryLevel \u0026gt; 0 the handler\n silently drops the PDU and lets the initiator plug the CmdSN gap:\n\n kfree(text_in);\n return 0;\n\n cmd-\u0026gt;text_in_ptr still points at the freed buffer. The next Text\n Request on the same ITT re-enters iscsit_setup_text_cmd(), which\n unconditionally does\n\n kfree(cmd-\u0026gt;text_in_ptr);\n cmd-\u0026gt;text_in_ptr = NULL;\n\n freeing the same pointer a second time. Session teardown via\n iscsit_release_cmd() has the same shape and hits the same double-free\n if the connection is dropped before a second Text Request arrives.\n\n On an unmodified mainline tree the bug-1 CRC overread fires first on\n the initial valid Text Request and perturbs the subsequent state, so\n #4 was isolated by building a kernel with only the bug-1 hunk of this\n patch applied plus temporary printk() observability around the three\n relevant kfree() sites. The observability prints are not part of\n this patch. On that build, a three-PDU Text Request sequence after\n login produces two back-to-back splats:\n\n BUG: KASAN: double-free in iscsit_setup_text_cmd+0x??\n BUG: KASAN: double-free in iscsit_release_cmd+0x??\n\n showing the same pointer freed in the ERL\u0026gt;0 drop path and again in\n iscsit_setup_text_cmd() (next Text Request on the same ITT) and once\n more in iscsit_release_cmd() (session teardown). On distro kernels\n with CONFIG_SLAB_FREELIST_HARDENED=y (default) the double-free\n becomes a remote kernel BUG(); on non-hardened kernels it corrupts\n the slab freelist.\n\n Fix by clearing cmd-\u0026gt;text_in_ptr after the kfree() in the ERL\u0026gt;0 drop\n path. With both hunks applied #4 is directly observable on the stock\n tree without observability printks; fixing bug-1 alone would mask #4\n less, not more, so the hunks are submitted together.\n\nBoth fixes are one-liners. The Text PDU state machine is unchanged and\nthe wire protocol is unaffected.(CVE-2026-63888)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: scsi_transport_fc: Widen FPIN pname walker counter to u32\n\nAn adjacent Fibre Channel fabric actor that can deliver an FPIN ELS\nframe to an lpfc or qla2xxx Linux initiator can trigger a non-return in\nthe generic FC transport. This is not a local userspace or IP network\npath; the attacker must be able to inject fabric traffic, for example as\na compromised switch or fabric controller, or as a same-zone N_Port on a\nfabric that permits source spoofing.\n\nThe Link-Integrity and Peer-Congestion FPIN walkers used a u8 loop\ncounter against the 32-bit on-wire pname_count field, and did not bound\npname_count by the descriptor body already validated by the TLV walker.\nA pname_count of 256 therefore wraps the counter and keeps the loop\ncondition true indefinitely.\n\nFactor the shared pname_list[] walk into one helper, widen the counter\nto u32, and clamp pname_count against the entries that fit in the\ndescriptor body before iterating.(CVE-2026-63889)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nthunderbolt: property: Cap recursion depth in __tb_property_parse_dir()\n\nA DIRECTORY entry\u0026apos;s value field is used as the dir_offset for a\nrecursive call into __tb_property_parse_dir() with no depth counter.\nA crafted peer that chains DIRECTORY entries into a back-reference\nloop drives the parser until the kernel stack is exhausted and the\nguard page fires. Any untrusted XDomain peer (cable, dock, in-line\ninspector, adjacent host) that reaches the PROPERTIES_REQUEST\ncontrol-plane exchange can trigger this without authentication.\n\nThread a depth counter through tb_property_parse() and\n__tb_property_parse_dir(), and reject blocks that exceed\nTB_PROPERTY_MAX_DEPTH = 8. That is comfortably larger than any\nobserved legitimate XDomain layout.\n\nOperators who do not need XDomain host-to-host discovery can disable\nthe path entirely with thunderbolt.xdomain=0 on the kernel command\nline.(CVE-2026-63891)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nUSB: serial: mct_u232: fix memory corruption with small endpoint\n\nThe driver overrides the maximum transfer size for a specific device\nwhich only accepts 16 byte packets for its 32 byte bulk-out endpoint.\n\nMake sure to never increase the maximum transfer size to prevent slab\ncorruption should a malicious device report a smaller endpoint max\npacket size than expected.(CVE-2026-63898)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nUSB: serial: mxuport: fix memory corruption with small endpoint\n\nMake sure that the bulk-out endpoint max packet size is at least eight\nbytes to avoid user-controlled slab corruption should a malicious device\nreport a smaller size.(CVE-2026-63899)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nUSB: serial: digi_acceleport: fix memory corruption with small endpoints\n\nAdd the missing bulk-out buffer size sanity checks to avoid\nout-of-bounds memory accesses or slab corruption should a malicious\ndevice report smaller buffers than expected.(CVE-2026-63901)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: esp: restore combined single-frag length gate\n\nThe ESP out-of-place fast path appends the trailer in esp_output_head()\nbefore esp_output_tail() allocates the destination page frag. The\nhead-side gate currently checks skb-\u0026gt;data_len and tailen separately, but\nthe tail code allocates a single destination frag from the combined\npost-trailer skb-\u0026gt;data_len.\n\nReject the page-frag fast path when the combined aligned length exceeds a\npage. Otherwise skb_page_frag_refill() may fall back to a single page while\nthe destination sg still spans the combined skb-\u0026gt;data_len.\n\nRestore this combined-length page gate for both IPv4 and IPv6.(CVE-2026-63912)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nip6: vti: Use ip6_tnl.net in vti6_changelink().\n\nip netns add ns1\nip netns add ns2\nip -n ns1 link add vti6_test type vti6 remote ::1 local ::2 key 7\nip -n ns1 link set vti6_test netns ns2\nip -n ns2 link set vti6_test type vti6 remote ::3 local ::4 key 9\nip netns del ns2\nip netns del ns1\n[ 132.495484] ------------[ cut here ]------------\n[ 132.497609] kernel BUG at net/core/dev.c:12376!\n\nCommit 61220ab34948 (\u0026quot;vti6: Enable namespace changing\u0026quot;) dropped\nNETIF_F_NETNS_LOCAL from vti6 devices. A vti6 tunnel can then\nmove through IFLA_NET_NS_FD. After the move dev_net(dev) points\nat the new netns while t-\u0026gt;net stays at the creation netns.\n\nvti6_changelink() and vti6_update() still use dev_net(dev) and\ndev_net(t-\u0026gt;dev). They unlink from one per netns hash and relink\ninto another. The creation netns is left with a stale entry.\ncleanup_net() of that netns later walks freed memory.\n\nReachable from an unprivileged user namespace (unshare --user\n--map-root-user --net). Cross tenant scope on container hosts.(CVE-2026-63917)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: input: hold netns during deferred transport reinjection\n\nTransport-mode reinjection stores a struct net pointer in skb-\u0026gt;cb and\nuses it later from xfrm_trans_reinject(). That pointer must stay valid\nuntil the deferred callback runs.\n\nTake a netns reference when queueing deferred reinjection work and drop\nit after the callback completes. Use maybe_get_net() so the queueing\npath does not revive a namespace that is already being torn down.\n\nThis keeps the existing workqueue design and fixes the netns lifetime\nhandling in one place for all users of xfrm_trans_queue_net().(CVE-2026-63919)\n\nIn the Linux kernel, ip6_datagram_recv_specific_ctl() builds IPV6_{HOPOPTS,DSTOPTS,RTHDR} cmsgs (and their IPV6_2292* legacy counterparts) by trusting the on-wire hdrlen byte (ptr[1]) when computing the put_cmsg() length. The length was validated only at parse time (ipv6_parse_hopopts(), etc.). An nftables payload-write expression can rewrite hdrlen after parsing and before the skb reaches recvmsg; the write itself is in-bounds but put_cmsg() then reads up to ((hdrlen+1) \u0026amp;lt;\u0026amp;lt; 3) = 2040 bytes from an 8-byte header. nftables is reachable from an unprivileged user namespace, so this is an unprivileged slab-out-of-bounds read.(CVE-2026-63920)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nip6: vti: Use ip6_tnl.net in vti6_siocdevprivate().\n\nAfter patch 1/2 in this series, vti6_update() unlinks and relinks\nthe tunnel through t-\u0026gt;net. vti6_siocdevprivate() still uses\ndev_net(dev) for the collision lookup. For a tunnel moved through\nIFLA_NET_NS_FD, dev_net(dev) is the new netns, not t-\u0026gt;net.\n\nSIOCCHGTUNNEL on a migrated tunnel then runs:\n\n net = dev_net(dev) /* migrated netns */\n t = vti6_locate(net, \u0026amp;p1, false) /* misses target in t-\u0026gt;net */\n ...\n t = netdev_priv(dev)\n vti6_update(t, \u0026amp;p1, false) /* mutates t-\u0026gt;net\u0026apos;s hash */\n\nA caller in the migrated netns picks params that match a tunnel\nin the creation netns. The lookup in dev_net(dev) finds nothing.\nvti6_update() prepends the migrated tunnel at the head of the\ncreation netns hash bucket for those params. Later lookups in\nthe creation netns resolve to the migrated device. xfrm receive\ndelivers the matched packets through a device the caller controls.\n\nReachable from an unprivileged user namespace (unshare --user\n--map-root-user --net). Cross tenant scope on container hosts.\n\nSwitch the SIOCCHGTUNNEL path on a non fallback device to use\nt-\u0026gt;net for the lookup. The lookup now matches the netns\nvti6_update() operates on.\n\nAlso add ns_capable(self-\u0026gt;net-\u0026gt;user_ns, CAP_NET_ADMIN) before\nthe lookup. The check at the top of the case is against\ndev_net(dev)-\u0026gt;user_ns, which after migration is the attacker\u0026apos;s\nnetns. A caller there can pick params absent from self-\u0026gt;net,\nthe lookup returns NULL, t becomes self, and vti6_update()\ninserts the device into the creation netns hash. The new check\nrequires CAP_NET_ADMIN in the creation netns user_ns too.\n\nSIOCADDTUNNEL and SIOCCHGTUNNEL on the fallback device keep\ndev_net(dev), which equals init_net there.(CVE-2026-63921)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: exthdrs: refresh nh pointer after ipv6_hop_jumbo()\n\nipv6_hop_jumbo() calls pskb_trim_rcsum(), which can change skb pointers.\nLet\u0026apos;s recompute nh pointer to make sure any change won\u0026apos;t mess things up.(CVE-2026-63924)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: sockmap: fix tail fragment offset in bpf_msg_push_data\n\nWhen bpf_msg_push_data() inserts data in the middle of a scatterlist\nentry, it splits the original entry into a left fragment and a right\nfragment.\n\nThe right fragment offset is page-local, but the code advances it with\n`start`, which is the message-global insertion point. For inserts into a\nnon-first SG entry, this over-advances the offset and leaves the split\nlayout inconsistent.\n\nAdvance the right fragment offset by the fragment-local delta,\n`start - offset`, which matches the length removed from the front of the\noriginal entry.(CVE-2026-63926)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nUSB: serial: omninet: fix memory corruption with small endpoint\n\nMake sure that the bulk-out buffers are at least as large as the\nhardcoded transfer size to avoid user-controlled slab corruption should\na malicious device report a smaller endpoint max packet size than\nexpected.(CVE-2026-63928)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_sync: fix UAF in hci_le_create_cis_sync\n\nhci_le_create_cis_sync() dereferences conn-\u0026gt;conn_timeout after releasing\nboth rcu_read_lock() and hci_dev_lock(hdev). The conn pointer was\nobtained from an RCU-protected iteration over hdev-\u0026gt;conn_hash.list and\nis not valid once these locks are dropped. A concurrent disconnect can\nfree the hci_conn between the unlock and the dereference, causing a\nuse-after-free read.\n\nThe cancellation mechanism in hci_conn_del() cannot prevent this because\nhci_le_create_cis_pending() queues hci_create_cis_sync with data=NULL:\n\n hci_cmd_sync_queue(hdev, hci_create_cis_sync, NULL, NULL);\n\nWhile hci_conn_del() dequeues with data=conn:\n\n hci_cmd_sync_dequeue(hdev, NULL, conn, NULL);\n\nSince NULL != conn, the lookup in _hci_cmd_sync_lookup_entry() never\nmatches, and the pending work item is not cancelled.\n\nFix this by saving conn-\u0026gt;conn_timeout into a local variable while the\nlocks are still held, so the stale conn pointer is never dereferenced\nafter unlock.\n\nThis is the same class of bug as the one fixed by commit 035c25007c9e\n(\u0026quot;Bluetooth: hci_sync: Fix UAF on le_read_features_complete\u0026quot;) which\naddressed the identical pattern in a different function.\n\nThis vulnerability was identified using 0sec.ai, an open-source\nautomated security auditing platform (https://github.com/0sec-labs).(CVE-2026-63944)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: ISO: serialize iso_sock_clear_timer with socket lock\n\niso_sock_close() calls iso_sock_clear_timer() before acquiring\nlock_sock(sk).\n\niso_sock_clear_timer() reads iso_pi(sk)-\u0026gt;conn twice without the\nsocket lock held:\n\n if (!iso_pi(sk)-\u0026gt;conn)\n return;\n cancel_delayed_work(\u0026amp;iso_pi(sk)-\u0026gt;conn-\u0026gt;timeout_work);\n\nConcurrently, iso_conn_del() executes under lock_sock(sk) and calls\niso_chan_del(), which sets iso_pi(sk)-\u0026gt;conn to NULL and may result in\nthe final reference to the connection being dropped:\n\n CPU0 CPU1\n ---- ----\n iso_sock_clear_timer()\n if (conn != NULL) ... lock_sock(sk)\n iso_chan_del()\n iso_pi(sk)-\u0026gt;conn = NULL\n cancel_delayed_work(conn) /* NULL deref or UAF */\n\niso_pi(sk)-\u0026gt;conn is not stable across the unlock window, causing a\nNULL pointer dereference or use-after-free.\n\nSerialize iso_sock_clear_timer() with the socket lock by moving it\ninside lock_sock()/release_sock(), matching the pattern used in\niso_conn_del() and all other call sites.(CVE-2026-63945)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: ISO: fix UAF in iso_recv_frame\n\niso_recv_frame reads conn-\u0026gt;sk under iso_conn_lock but releases the lock\nbefore using sk, with no reference held. A concurrent iso_sock_kill()\ncan free sk in that window, causing use-after-free on sk-\u0026gt;sk_state and\nsock_queue_rcv_skb().\n\nFix by replacing the bare pointer read with iso_sock_hold(conn), which\ncalls sock_hold() while the spinlock is held, atomically elevating the\nrefcount before the lock drops. Add a drop_put label so sock_put() is\ncalled on all exit paths where the hold succeeded.(CVE-2026-63946)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmemfd: deny writeable mappings when implying SEAL_WRITE\n\nWhen SEAL_EXEC is added, SEAL_WRITE is implied to make W^X. But the\nimplied seal is set after the check that makes sure the memfd can not have\nany writable mappings. This means one can use SEAL_EXEC to apply\nSEAL_WRITE while having writeable mappings.\n\nThis breaks the contract that SEAL_WRITE provides and can be used by an\nattacker to pass a memfd that appears to be write sealed but can still be\nmodified arbitrarily.\n\nFix this by adding the implied seals before the call for\nmapping_deny_writable() is done.(CVE-2026-63952)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nUSB: serial: cypress_m8: fix memory corruption with small endpoint\n\nMake sure that the interrupt-out endpoint max packet size is at least\neight bytes to avoid user-controlled slab corruption or NULL-pointer\ndereference should a malicious device report a smaller size.(CVE-2026-63956)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: fix possible infinite loop in fib6_select_path()\n\nFound while auditing the same pattern Sashiko reported in\nrt6_fill_node() [1]. Apply the same fix as\ncommit f8d8ce1b515a (\u0026quot;ipv6: fix possible infinite loop in fib6_info_uses_dev()\u0026quot;).\n\nWriters holding tb6_lock can list_del_rcu(\u0026amp;first-\u0026gt;fib6_siblings)\nwithout waiting for RCU readers; first-\u0026gt;fib6_siblings.next then\nstill points into the old ring and this softirq-side walker never\nreaches \u0026amp;first-\u0026gt;fib6_siblings as its terminator. fib6_purge_rt()\nalways WRITE_ONCE()s first-\u0026gt;fib6_nsiblings to 0 before\nlist_del_rcu(), so an inside-loop check is a reliable detach signal.\n\n[1] https://sashiko.dev/#/patchset/20260526020227.4857-1-jiayuan.chen%40linux.dev(CVE-2026-63968)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsctp: fix race between sctp_wait_for_connect and peeloff\n\nsctp_wait_for_connect() drops and re-acquires the socket lock while\nwaiting for the association to reach ESTABLISHED state. During this\nwindow, another thread can peeloff the association to a new socket via\ngetsockopt(SCTP_SOCKOPT_PEELOFF), changing asoc-\u0026gt;base.sk. After\nre-acquiring the old socket lock, sctp_wait_for_connect() returns\nsuccess without noticing the migration \u2014 the caller then accesses\nthe association under the wrong lock in sctp_datamsg_from_user().\n\nAdd the same sk != asoc-\u0026gt;base.sk check that sctp_wait_for_sndbuf()\nalready has, returning an error if the association was migrated while\nwe slept.(CVE-2026-63971)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_sync: Set HCI_CMD_DRAIN_WORKQUEUE during device close\n\nSince hci_dev_close_sync() can now be called during the reset path, we\nshould also set HCI_CMD_DRAIN_WORKQUEUE. This avoids queuing timeouts\nwhile the hdev workqueue is being drained.(CVE-2026-63974)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: L2CAP: Fix possible crash on l2cap_ecred_conn_rsp\n\nIf dcid is received for an already-assigned destination CID the spec\nrequires that both channels to be discarded, but calling l2cap_chan_del\nmay invalidate the tmp cursor created by list_for_each_entry_safe and\nin fact it is the wrong procedure as the chan-\u0026gt;dcid may be assigned\npreviously it really needs to be disconnected.\n\nCalling l2cap_chan_clone directly may still lead to l2cap_chan_del so\ninstead schedule l2cap_chan_timeout with delay 0 to close the channel\nasynchronously.(CVE-2026-63975)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: l2cap: clear chan-\u0026gt;ident on ECRED reconfiguration success\n\nl2cap_ecred_reconf_rsp() returns early on success without clearing\nchan-\u0026gt;ident. Every other L2CAP response handler (l2cap_ecred_conn_rsp,\nl2cap_le_connect_rsp, l2cap_config_rsp) clears chan-\u0026gt;ident after a\nsuccessful transaction to prevent the channel from matching subsequent\nresponses with the recycled ident value.\n\nA remote attacker that completed a reconfiguration as the peer can\nreplay a failure response with the stale ident, causing the kernel to\nmatch and destroy the already-established channel via\nl2cap_chan_del(chan, ECONNRESET).\n\nClear chan-\u0026gt;ident for all matching channels on success, and harden the\nfailure path by using l2cap_chan_hold_unless_zero() consistent with\nother L2CAP handlers (l2cap_le_command_rej, __l2cap_get_chan_by_ident).(CVE-2026-63976)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: rpl: fix hdrlen overflow in ipv6_rpl_srh_decompress()\n\nipv6_rpl_srh_decompress() computes:\n\n outhdr-\u0026gt;hdrlen = (((n + 1) * sizeof(struct in6_addr)) \u0026gt;\u0026gt; 3);\n\nhdrlen is __u8. For n \u0026gt;= 127 the result exceeds 255 and silently\ntruncates. With n=127 (cmpri=15, cmpre=15, pad=0, hdrlen=16):\n\n (128 * 16) \u0026gt;\u0026gt; 3 = 256, truncated to 0 as __u8\n\nThe caller in ipv6_rpl_srh_rcv() then places the compressed header\nat buf + ((ohdr-\u0026gt;hdrlen + 1) \u0026lt;\u0026lt; 3). With hdrlen=0 this is buf + 8,\nbut the decompressed region occupies buf[0..2055] (8-byte header\nplus 128 full addresses). The compressed header overlaps the\ndecompressed data, and ipv6_rpl_srh_compress() writes into this\noverlap, corrupting the routing header of the forwarded packet.\n\nThe existing guard at exthdrs.c:546 checks (n + 1) \u0026gt; 255, which\nprevents n+1 from overflowing unsigned char (the segments_left\nfield), but does not prevent the computed hdrlen from overflowing\n__u8. n=127 passes because 128 \u0026lt;= 255, yet hdrlen=256 does not\nfit.\n\nTighten the bound to (n + 1) \u0026gt; 127. This caps n at 126, giving\nhdrlen = (127 * 16) \u0026gt;\u0026gt; 3 = 254, which fits in __u8. The compressed\nheader then lands at buf + ((254 + 1) \u0026lt;\u0026lt; 3) = buf + 2040, exactly\npast the decompressed region (buf[0..2039]). No overlap. 127\nsegments is well beyond any realistic RPL deployment.(CVE-2026-63984)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nethtool: eeprom: add more safeties to EEPROM Netlink fallback\n\nThe Netlink fallback path for reading module EEPROM\n(fallback_set_params()) validates that offset \u0026lt; eeprom_len,\nbut does not check that offset + length stays within eeprom_len.\nThe ioctl equivalent (ethtool_get_any_eeprom() in ioctl.c) has\nalways enforced both bounds:\n\n if (eeprom.offset + eeprom.len \u0026gt; total_len)\n return -EINVAL;\n\nThis could lead to surprises in both drivers and device FW.\nAdd the missing offset + length validation to fallback_set_params(),\nmirroring the ioctl.\n\nSimilarly - ethtool core in general, and ethtool_get_any_eeprom()\nin particular tries to zero-init all buffers passed to the drivers\nto avoid any extra work of zeroing things out. eeprom_fallback()\nuses a plain kmalloc(), change it to zalloc.(CVE-2026-63985)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntunnels: do not assume transport header in iptunnel_pmtud_check_icmp()\n\nIn some cases, iptunnel_pmtud_check_icmp() can be called while\nskb transport header is not set.\n\nThis triggers an out-of-bound access, because\n(typeof(skb-\u0026gt;transport_header))~0U is 65535.\n\nAccess the icmp header based on IPv4 network header,\nafter making sure icmp-\u0026gt;type is present in skb linear part.\n\nNote that iptunnel_pmtud_check_icmpv6()) is fine.(CVE-2026-63992)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvxlan: do not reuse cached ip_hdr() value after skb_tunnel_check_pmtu()\n\nskb_tunnel_check_pmtu() can change skb-\u0026gt;head.\n\nReusing old_iph afer skb_tunnel_check_pmtu() can cause an UAF.\n\nUse instead ip_hdr(skb) as done in drivers/net/bareudp.c\nand drivers/net/geneve.c.\n\nFound by Sashiko.(CVE-2026-63993)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntunnels: load network headers after skb_cow() in iptunnel_pmtud_build_icmp[v6]()\n\nSashiko found that iptunnel_pmtud_build_icmp() and\niptunnel_pmtud_build_icmpv6() were caching ip_hdr() and ipv6_hdr()\nbefore an skb_cow() call which can reallocate skb-\u0026gt;head.\n\nFix this possible UAF by initializing the local variables\nafter the skb_cow() call.\n\nRemove skb_reset_network_header() calls which were not needed.(CVE-2026-63994)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv4: free net-\u0026gt;ipv4.sysctl_local_reserved_ports after unregister_net_sysctl_table()\n\nipv4_sysctl_exit_net() is currently freeing net-\u0026gt;ipv4.sysctl_local_reserved_ports\ntoo soon.\n\nOnly after unregister_net_sysctl_table() we can be sure no threads can possibly\nuse the sysctls, including /proc/sys/net/ipv4/ip_local_reserved_ports.(CVE-2026-64002)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: core: Run queues for all non-SDEV_DEL devices from scsi_run_host_queues\n\nWhile a SCSI host is in a recovery state, scsi_mq_requeue_cmd() will not\nset the requeue list for a requeued command to be kicked in the future.\nThe expectation is a call to scsi_run_host_queues() will kick all SCSI\ndevices once the recovery state is cleared.\n\nHowever, scsi_run_host_queues() uses shost_for_each_device() which uses\nscsi_device_get() and so will ignore devices in a partially removed\nstate like SDEV_CANCEL. But these devices may also have requeued\nrequests, leaving their requests stuck from not being kicked and causing\nthe removal process of the device to hang.\n\nscsi_run_host_queues() needs to run against more devices than the macro\nshost_for_each_device() allows. Instead of using the too limiting\nscsi_device_get() state checks, only ignore devices in SDEV_DEL state or\nwhen unable to acquire a reference. Attempt to run the queues for all\nother devices when scsi_run_host_queues() is called.(CVE-2026-64003)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsecurity/keys: fix missed RCU read section on lookup\n\nNicholas Carlini reports that the keyring code calls assoc_array_find()\nin find_key_to_update() without holding the RCU read lock, while the\nassoc_array_gc() code really is designed around removing the node from\nthe tree and then freeing it after an RCU grace-period.\n\nThe regular key handling doesn\u0026apos;t see this because holding the keyring\nsemaphore hides any lifetime issues, but the persistent key handling\nuses a different model.\n\nInstead of extending the keyring locking, just do the simple RCU locking\nthat the assoc_array was designed for.(CVE-2026-64015)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf, skmsg: fix verdict sk_data_ready racing with ktls rx\n\nsk_psock_strp_data_ready() already checks tls_sw_has_ctx_rx() and\ndefers to psock-\u0026gt;saved_data_ready when a TLS RX context is present,\navoiding a conflict with the TLS strparser\u0026apos;s ownership of the receive\nqueue (commit e91de6afa81c, \u0026quot;bpf: Fix running sk_skb program types\nwith ktls\u0026quot;).\n\nsk_psock_verdict_data_ready() has no equivalent guard. When a socket\nis inserted into a sockmap (BPF_SK_SKB_VERDICT) before TLS RX is\nconfigured, tls_sw_strparser_arm() saves sk_psock_verdict_data_ready\nas rx_ctx-\u0026gt;saved_data_ready. On data arrival:\n\n tls_data_ready -\u0026gt; tls_strp_data_ready -\u0026gt; tls_rx_msg_ready\n -\u0026gt; saved_data_ready() = sk_psock_verdict_data_ready()\n -\u0026gt; tcp_read_skb() drains sk_receive_queue via __skb_unlink()\n without calling tcp_eat_skb(), so copied_seq is not advanced.\n\ntls_strp_msg_load() then finds tcp_inq() \u0026gt;= full_len (stale), calls\ntcp_recv_skb() on the now-empty queue, hits WARN_ON_ONCE(!first), and\nreturns with rx_ctx-\u0026gt;strp.anchor.frag_list pointing at a psock-owned\n(potentially freed) skb. tls_decrypt_sg() subsequently walks that\nfrag_list: use-after-free.\n\nApply the same fix as sk_psock_strp_data_ready(): if a TLS RX context\nis present, call psock-\u0026gt;saved_data_ready (sock_def_readable) to wake\nrecv() waiters and return immediately, leaving the receive queue\nuntouched. TLS retains sole ownership of the queue and decrypts the\nrecord normally through tls_sw_recvmsg().(CVE-2026-64025)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbridge: mcast: Fix a possible use-after-free when removing a bridge port\n\nWhen per-VLAN multicast snooping is enabled, the bridge iterates over\nall the bridge ports, disables the per-port multicast context on each\nport and enables the per-{port, VLAN} multicast contexts instead. The\nreverse happens when per-VLAN multicast snooping is disabled.\n\nWhen global multicast snooping is enabled, the bridge iterates over all\nthe bridge ports and enables the per-port multicast context on each\nport. The reverse happens when multicast snooping is disabled.\n\nThe above scheme can result in a situation where both types of contexts\n(per-port and per-{port, VLAN}) are enabled on a single bridge port:\n\n # ip link add name br1 up type bridge mcast_snooping 1 mcast_querier 1 vlan_filtering 1\n # ip link add name dummy1 up master br1 type dummy\n # ip link set dev br1 type bridge mcast_vlan_snooping 1\n # ip link set dev br1 type bridge mcast_snooping 0\n # ip link set dev br1 type bridge mcast_snooping 1\n\nThis is not intended and it is a problem since the commit cited below.\nPrior to this commit, when removing a bridge port,\nbr_multicast_disable_port() would disable the per-port multicast context\nand the per-{port, VLAN} multicast contexts would get disabled when\nflushing VLANs.\n\nAfter this commit, br_multicast_disable_port() only disables the\nper-port multicast context if per-VLAN multicast snooping is disabled.\nIf both types of contexts were enabled on the port when it was removed,\nthe per-port multicast context would remain enabled when freeing the\nbridge port, leading to a use-after-free [1].\n\nFix by preventing the bridge from enabling / disabling the per-port\nmulticast contexts when toggling global multicast snooping if per-VLAN\nmulticast snooping is enabled.\n\n[1]\nODEBUG: free active (active state 0) object: ffff88810f8bda78 object type: timer_list hint: br_ip6_multicast_port_query_expired (net/bridge/br_multicast.c:1927)\nWARNING: lib/debugobjects.c:629 at debug_print_object+0x1b1/0x3e0, CPU#5: swapper/5/0\n[...]\nCall Trace:\n\u0026lt;IRQ\u0026gt;\n__debug_check_no_obj_freed (lib/debugobjects.c:1116)\nkfree (mm/slub.c:2620 mm/slub.c:6250 mm/slub.c:6565)\nkobject_cleanup (lib/kobject.c:689)\nrcu_do_batch (kernel/rcu/tree.c:2617)\nrcu_core (kernel/rcu/tree.c:2869)\nhandle_softirqs (kernel/softirq.c:622)\n__irq_exit_rcu (kernel/softirq.c:656 kernel/softirq.c:496 kernel/softirq.c:735)\nirq_exit_rcu (kernel/softirq.c:752)\nsysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1061 (discriminator 47) arch/x86/kernel/apic/apic.c:1061 (discriminator 47))\n\u0026lt;/IRQ\u0026gt;(CVE-2026-64032)\n\nIn the Linux kernel, the following vulnerability has been resolved: net: tls: prevent chain-after-chain in plain text SG. Sashiko points out that if end = 0 (start != 0) the current code will create a chain link to content type right after the wrap link. This would create a chain where the wrap link points directly to another chain link. The scatterlist API sg_next iterator does not recursively resolve consecutive chain links, meaning this is illegal input to crypto. The wrapping link is unnecessary if end = 0. TLS 1.3 can use the \u0026quot;wrapping slot\u0026quot; for its chaining if end = 0, which avoids the chain-after-chain.(CVE-2026-64046)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: tls: fix off-by-one in sg_chain entry count for wrapped sk_msg ring\n\nWhen an sk_msg scatterlist ring wraps (sg.end \u0026lt; sg.start),\ntls_push_record() chains the tail portion of the ring to the head\nusing sg_chain(). An extra entry in the sg array is reserved for\nthis:\n\n struct sk_msg_sg {\n [...]\n /* The extra two elements:\n * 1) used for chaining the front and sections when the list becomes\n * partitioned (e.g. end \u0026lt; start). The crypto APIs require the\n * chaining;\n * 2) to chain tailer SG entries after the message.\n */\n struct scatterlist data[MAX_MSG_FRAGS + 2];\n\nThe current code uses MAX_SKB_FRAGS + 1 as the ring size:\n\n sg_chain(\u0026amp;msg_pl-\u0026gt;sg.data[msg_pl-\u0026gt;sg.start],\n MAX_SKB_FRAGS - msg_pl-\u0026gt;sg.start + 1,\n msg_pl-\u0026gt;sg.data);\n\nThis places the chain pointer at\n\n sg_chain(data[start], (MAX_SKB_FRAGS - msg_start + 1) .. =\n \u0026amp;data[start] + (MAX_SKB_FRAGS - msg_start + 1) - 1 =\n data[start + (MAX_SKB_FRAGS - start + 1) - 1] =\n data[MAX_SKB_FRAGS]\n\ninstead of the true last entry. This is likely due to a \u0026quot;race\u0026quot; of\nthe commit under Fixes landing close to\ncommit 031097d9e079 (\u0026quot;bpf: sk_msg, zap ingress queue on psock down\u0026quot;)\n\nConvert to ARRAY_SIZE and drop the data[start] / - start (as suggested\nby Sabrina).(CVE-2026-64047)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nirq_work: Fix use-after-free in irq_work_single() on PREEMPT_RT\n\nOn PREEMPT_RT, non-HARD irq_work runs in per-CPU kthreads via\nrun_irq_workd(), so irq_work_sync() uses rcuwait() to wait for BUSY==0.\n\nAfter irq_work_single() clears BUSY via atomic_cmpxchg(), it still\ndereferences @work for irq_work_is_hard() and rcuwait_wake_up().\n\nAn irq_work_sync() caller on another CPU that enters after BUSY is cleared\ncan observe BUSY==0 immediately, return, and free the work before those\naccesses complete \u2014 causing a use-after-free.\n\nFix this by wrapping run_irq_workd() in guard(rcu)() so that the entire\nirq_work_single() execution is within an RCU read-side critical\nsection. Then add synchronize_rcu() in irq_work_sync() after\nrcuwait_wait_event() to ensure the caller waits for the RCU grace period\nbefore returning, preventing premature frees.(CVE-2026-64073)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: bridge: eb_tables: close module init race\n\nsashiko reports for unrelated patch:\n Does the core ebtables initialization in ebtables.c suffer from a similar race?\n Once nf_register_sockopt() completes, the sockopts are exposed globally.\n\nsockopt has to be registered last, just like in ip/ip6/arptables.(CVE-2026-64076)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: ebtables: move to two-stage removal scheme\n\nLike previous patches for x_tables, follow same pattern in ebtables.\nWe can\u0026apos;t reuse xt helpers: ebt_table struct layout is incompatible.\n\ntable-\u0026gt;ops assignment is now done while still holding the ebt mutex\nto make sure we never expose partially-filled table struct.(CVE-2026-64077)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbatman-adv: tt: fix negative tt_buff_len\n\nbatadv_orig_node::tt_buff_len was declared as s16, but the field is never\nintended to hold a negative value. When a value greater than 32767 is\nassigned, it wraps to a negative signed integer.\n\nIn batadv_send_other_tt_response(), tt_buff_len is temporarily widened to\ns32. The incorrectly negative s16 value propagates into the s32, causing\nbatadv_tt_prepare_tvlv_global_data() to allocate a full sized buffer but\npopulates only a small portion of it with the collected changeset. All\nremaining bits are kept uninitialized.\n\nUsing an u16 avoids this type confusion and ensures that no (negative) sign\nextension is performed in batadv_send_other_tt_response().(CVE-2026-64088)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbatman-adv: tt: fix negative last_changeset_len\n\nbatadv_piv_tt::last_changeset_len len was declared as s16, but the field is\nnever intended to hold a negative value. When a value greater than 32767 is\nassigned, it wraps to a negative signed integer.\n\nIn batadv_send_my_tt_response(), last_changeset_len is temporarily widened\nto s32. The incorrectly negative s16 value propagates into the s32, causing\nbatadv_tt_prepare_tvlv_local_data() to allocate a full sized buffer but\npopulates only a small portion of it with the collected changeset. All\nremaining bits are kept uninitialized.\n\nUsing an u16 avoids this type confusion and ensures that no (negative) sign\nextension is performed in batadv_send_my_tt_response().(CVE-2026-64089)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbatman-adv: bla: avoid double decrement of bla.num_requests\n\nThe bla.num_requests is increased when no request_sent was in progress. And\nit is decremented in various places (announcement was received, backbone is\npurged, periodic work). But the check if the request_sent is actually set\nto a specific state and the atomic_dec/_inc are not safe because they are\nnot atomic (TOCTOU) and multiple such code portions can run concurrently.\n\nAt the same time, it is necessary to modify request_sent (state) and\nbla.num_requests atomically. Otherwise batadv_bla_send_request() might set\nrequest_sent to 1 and is interrupted. batadv_handle_announce() can then\nset request_sent back to 0 and decrement num_requests before\nbatadv_bla_send_request() incremented it.\n\nThe two operations must therefore be locked. And since state (request_sent)\nand wait_periods are only accessed inside this lock, they can be converted\nto simpler datatypes. And to avoid that the bla.num_requests is touched by\na parallel running context with a valid backbone_gw reference after\nbatadv_bla_purge_backbone_gw() ran, a third state \u0026quot;stopped\u0026quot; is required to\ncorrectly signal that a backbone_gw is in the state of being cleaned up.(CVE-2026-64095)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Validate GPIO pin LUT table size before iterating\n\n[Why\u0026amp;How]\nThe GPIO pin table parsers in get_gpio_i2c_info() and\nbios_parser_get_gpio_pin_info() derive an element count from the VBIOS\ntable_header.structuresize field, then iterate over gpio_pin[] entries.\nHowever, GET_IMAGE() only validates that the table header itself fits\nwithin the BIOS image. If the VBIOS reports a structuresize larger than\nthe actual mapped data, the loop reads past the end of the BIOS image,\ncausing an out-of-bounds read.\n\nFix this by calling bios_get_image() to validate that the full claimed\nstructuresize is accessible within the BIOS image before entering the\nloop in both functions.\n\n(cherry picked from commit ba5e95b43b773ae1bf1f66ee6b31eb774e65afe3)(CVE-2026-64097)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/virtio: use uninterruptible resv lock for plane updates\n\nvirtio_gpu_cursor_plane_update() and virtio_gpu_resource_flush() lock\nthe framebuffer BO\u0026apos;s dma_resv via virtio_gpu_array_lock_resv() and\nignore its return value. The function can fail with -EINTR from\ndma_resv_lock_interruptible() (signal during lock wait) or with\n-ENOMEM from dma_resv_reserve_fences() (fence slot allocation),\nleaving the resv lock not held. The queue path then walks the object\narray and calls dma_resv_add_fence(), which requires the lock held;\nwith lockdep enabled this trips dma_resv_assert_held():\n\n WARNING: drivers/dma-buf/dma-resv.c:296 at dma_resv_add_fence+0x71e/0x840\n Call Trace:\n virtio_gpu_array_add_fence\n virtio_gpu_queue_ctrl_sgs\n virtio_gpu_queue_fenced_ctrl_buffer\n virtio_gpu_cursor_plane_update\n drm_atomic_helper_commit_planes\n drm_atomic_helper_commit_tail\n commit_tail\n drm_atomic_helper_commit\n drm_atomic_commit\n drm_atomic_helper_update_plane\n __setplane_atomic\n drm_mode_cursor_universal\n drm_mode_cursor_common\n drm_mode_cursor_ioctl\n drm_ioctl\n __x64_sys_ioctl\n\nBeyond the WARN, mutating the dma_resv fence list without the lock\nraces with concurrent readers/writers and can corrupt the list.\n\nBoth call sites run inside the .atomic_update plane callback, which\nDRM atomic helpers do not allow to fail (by the time it runs, the\ncommit has been signed off to userspace and there is no clean\nrollback path). Moving the lock acquisition to .prepare_fb was\nrejected because the broader lock scope deadlocks against other BO\nlocking paths in the same atomic commit.\n\nIntroduce virtio_gpu_lock_one_resv_uninterruptible() that uses\ndma_resv_lock() instead of dma_resv_lock_interruptible(). This\neliminates the -EINTR failure mode -- the realistic syzbot trigger\n-- without extending the lock hold across the commit. The helper\nlocks a single BO and rejects nents \u0026gt; 1 with -EINVAL; both fix\nsites lock exactly one BO.\n\nUse it from virtio_gpu_cursor_plane_update() and\nvirtio_gpu_resource_flush(); check the return value to handle the\nremaining -ENOMEM case from dma_resv_reserve_fences() by freeing\nthe objs and skipping the plane update for that frame. The\nframebuffer BOs touched here are not shared with other contexts\nand lock contention is expected to be brief, so the loss of\nsignal-interruptibility is acceptable.\n\nOther callers of virtio_gpu_array_lock_resv() (the ioctl paths)\ncontinue to use the interruptible variant.\n\nThe bug was reported by syzbot, triggered via fault injection\n(fail_nth) on the DRM_IOCTL_MODE_CURSOR path, which forces the\n-ENOMEM branch in dma_resv_reserve_fences().(CVE-2026-64098)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: arm64: vgic-its: Reject restored DTE with out-of-range num_eventid_bits\n\nUserspace can restore an ITS Device Table Entry whose Size field encodes\nmore EventID bits than the virtual ITS supports. The live MAPD path\nrejects that state, but vgic_its_restore_dte() accepts it and stores the\nout-of-range value in dev-\u0026gt;num_eventid_bits.\n\nReject restored DTEs with num_eventid_bits \u0026gt; VITS_TYPER_IDBITS before\nallocating the device. This mirrors the MAPD check and prevents the\nrestored state from reaching vgic_its_restore_itt(), where the unchecked\nvalue can be converted into an oversized scan_its_table() range.(CVE-2026-64106)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\naf_unix: Fix UAF read of tail-\u0026gt;len in unix_stream_data_wait()\n\nunix_stream_data_wait() does skb_peek_tail(\u0026amp;sk-\u0026gt;sk_receive_queue) without\nholding any lock that prevents SKBs on that queue from being dequeued and\nfreed.\nThis has been the case since commit 79f632c71bea (\u0026quot;unix/stream: fix\npeeking with an offset larger than data in queue\u0026quot;).\nThe first consequence of this is that the pointer comparison\n`tail != last` can be false even if `last` semantically refers to an\nalready-freed SKB while `tail` is a new SKB allocated at the same address;\nwhich can cause unix_stream_data_wait() to wrongly keep blocking after new\ndata has arrived, but only in a weird scenario where a peeking recv() and\na normal recv() on the same socket are racing, which is probably not a\nreal problem.\n\nBut since commit 2b514574f7e8 (\u0026quot;net: af_unix: implement splice for stream\naf_unix sockets\u0026quot;), `tail` is actually dereferenced, which can cause UAF in\nthe following race scenario (where test_setup() runs single-threaded,\nand afterwards, test_thread1() and test_thread2() run concurrently in\ntwo threads:\n```\nstatic int socks[2];\nvoid test_setup(void) {\n socketpair(AF_UNIX, SOCK_STREAM, 0, socks);\n send(socks[1], \u0026quot;A\u0026quot;, 1, 0);\n int peekoff = 1;\n setsockopt(socks[0], SOL_SOCKET, SO_PEEK_OFF, \u0026amp;peekoff, sizeof(peekoff));\n}\nvoid test_thread1(void) {\n char dummy;\n recv(socks[0], \u0026amp;dummy, 1, MSG_PEEK);\n}\nvoid test_thread2(void) {\n char dummy;\n recv(socks[0], \u0026amp;dummy, 1, 0);\n shutdown(socks[1], SHUT_WR);\n}\n```\n\nwhen racing like this:\n```\nthread1 thread2\nunix_stream_read_generic\n mutex_lock(\u0026amp;u-\u0026gt;iolock)\n skb_peek(\u0026amp;sk-\u0026gt;sk_receive_queue)\n skb_peek_next(skb, \u0026amp;sk-\u0026gt;sk_receive_queue)\n mutex_unlock(\u0026amp;u-\u0026gt;iolock)\n unix_stream_read_generic\n unix_state_lock(sk)\n skb_peek(\u0026amp;sk-\u0026gt;sk_receive_queue)\n unix_state_unlock(sk)\n unix_stream_data_wait\n unix_state_lock(sk)\n tail = skb_peek_tail(\u0026amp;sk-\u0026gt;sk_receive_queue)\n spin_lock(\u0026amp;sk-\u0026gt;sk_receive_queue.lock)\n __skb_unlink(skb, \u0026amp;sk-\u0026gt;sk_receive_queue)\n spin_unlock(\u0026amp;sk-\u0026gt;sk_receive_queue.lock)\n consume_skb(skb) [frees the SKB]\n `tail != last`: false\n `tail`: true\n `tail-\u0026gt;len != last_len` ***UAF***\n```\n\nFix the UAF by removing the read of tail-\u0026gt;len; checking tail-\u0026gt;len would\nonly make sense if SKBs in the receive queue of a UNIX socket could grow,\nwhich can no longer happen.\n\nKuniyuki explained:\n\n\u0026gt; When commit 869e7c62486e (\u0026quot;net: af_unix: implement stream sendpage\n\u0026gt; support\u0026quot;) added sendpage() support, data could be appended to the last\n\u0026gt; skb in the receiver\u0026apos;s queue.\n\u0026gt;\n\u0026gt; That\u0026apos;s why we needed to check if the length of the last skb was changed\n\u0026gt; while waiting for new data in unix_stream_data_wait().\n\u0026gt;\n\u0026gt; However, commit a0dbf5f818f9 (\u0026quot;af_unix: Support MSG_SPLICE_PAGES\u0026quot;) and\n\u0026gt; commit 57d44a354a43 (\u0026quot;unix: Convert unix_stream_sendpage() to use\n\u0026gt; MSG_SPLICE_PAGES\u0026quot;) refactored sendmsg(), and now data is always added\n\u0026gt; to a new skb.\n\nThat means this fix is not suitable for kernels before 6.5.(CVE-2026-64109)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nrbd: eliminate a race in lock_dwork draining on unmap\n\nGiven how rbd_lock_add_request() and rbd_img_exclusive_lock() are\nwritten, lock_dwork may be (re)queued more than it\u0026apos;s actually needed:\nfor example in case a new I/O request comes in while we are in the\nmiddle of rbd_acquire_lock() on behalf of another I/O request. This is\nexpected and with rbd_release_lock() preemptively canceling lock_dwork\nis benign under normal operation.\n\nA more problematic example is maybe_kick_acquire():\n\n if (have_requests || delayed_work_pending(\u0026amp;rbd_dev-\u0026gt;lock_dwork)) {\n dout(\u0026quot;%s rbd_dev %p kicking lock_dwork\\n\u0026quot;, __func__, rbd_dev);\n mod_delayed_work(rbd_dev-\u0026gt;task_wq, \u0026amp;rbd_dev-\u0026gt;lock_dwork, 0);\n }\n\nIt\u0026apos;s not unrealistic for lock_dwork to get canceled right after\ndelayed_work_pending() returns true and for mod_delayed_work() to\nrequeue it right there anyway. This is a classic TOCTOU race.\n\nWhen it comes to unmapping the image, there is an implicit assumption\nof no self-initiated exclusive lock activity past the point of return\nfrom rbd_dev_image_unlock() which unlocks the lock if it happens to be\nheld. This unlock is assumed to be final and lock_dwork (as well as\nall other exclusive lock tasks, really) isn\u0026apos;t expected to get queued\nagain. However, lock_dwork is canceled only in cancel_tasks_sync()\n(i.e. later in the unmap sequence) and on top of that the cancellation\ncan get in effect nullified by maybe_kick_acquire(). This may result\nin rbd_acquire_lock() executing after rbd_dev_device_release() and\nrbd_dev_image_release() run and free and/or reset a bunch of things.\nOne of the possible failure modes then is a violated\n\n rbd_assert(rbd_image_format_valid(rbd_dev-\u0026gt;image_format));\n\nin rbd_dev_header_info() which is called via rbd_dev_refresh() from\nrbd_post_acquire_action().\n\nRedo exclusive lock task draining to provide saner semantics and try\nto meet the assumptions around rbd_dev_image_unlock().(CVE-2026-64112)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nixgbevf: fix use-after-free in VEPA multicast source pruning\n\nixgbevf_clean_rx_irq() prunes frames whose source MAC matches the VF\u0026apos;s\nown address (VEPA multicast workaround) by freeing the skb and\ncontinuing to the next descriptor:\n\n dev_kfree_skb_irq(skb);\n continue;\n\nThe skb pointer is declared outside the while loop and persists across\niterations. Because the continue skips the \u0026quot;skb = NULL\u0026quot; reset at the\nbottom of the loop, the next iteration enters the \u0026quot;else if (skb)\u0026quot; path\nand calls ixgbevf_add_rx_frag() on the freed skb, dereferencing\nskb_shinfo(skb)-\u0026gt;nr_frags - a use-after-free in NAPI softirq context.\n\nThe sibling driver iavf already handles this correctly by nulling the\npointer before continuing. Apply the same pattern here.\n\nI do not have ixgbevf hardware; the bug was found by static analysis\n(scan_drop_continue_loops.py + semgrep drop_continue_in_loop, multi-tool\ncorroboration with the highest score in the scan). The UAF was confirmed\nunder KASAN by loading a test module that reproduces the exact code\npattern (alloc skb, kfree_skb, then read skb_shinfo(skb)-\u0026gt;nr_frags):\n\n BUG: KASAN: slab-use-after-free in ixgbevf_uaf_test_init+0x100/0x1000\n Read of size 8 at addr 000000006163ae78 by task insmod/30\n freed 208-byte region [000000006163adc0, 000000006163ae90)\n\nQEMU emulates igb (82576) but not ixgbe (82599), and the igbvf VF\ndriver does not include the VEPA source pruning path, so a full\nend-to-end reproduction with emulated hardware was not possible.(CVE-2026-64113)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv4: raw: reject IP_HDRINCL packets with ihl \u0026lt; 5\n\nraw_send_hdrinc() validates that the caller-supplied IPv4 header\nfits within the message length:\n\n iphlen = iph-\u0026gt;ihl * 4;\n err = -EINVAL;\n if (iphlen \u0026gt; length)\n goto error_free;\n\n if (iphlen \u0026gt;= sizeof(*iph)) {\n /* fix up saddr, tot_len, id, csum, transport_header */\n }\n\nIt does not, however, reject ihl \u0026lt; 5. For such a packet the\n\u0026quot;if (iphlen \u0026gt;= sizeof(*iph))\u0026quot; branch is skipped, leaving the\ncrafted iphdr untouched, but the packet is still handed to\n__ip_local_out() and onward. Downstream consumers that read\niph-\u0026gt;ihl assume a sane value: net/ipv4/ah4.c:ah_output() in\nparticular subtracts sizeof(struct iphdr) from top_iph-\u0026gt;ihl * 4\nand passes the (signed-int-negative, then cast to size_t)\nresult to memcpy(), producing an OOB access of length close to\nSIZE_MAX and a host kernel panic.\n\nAn IPv4 header with ihl \u0026lt; 5 is malformed by definition (RFC 791:\n\u0026quot;Internet Header Length is the length of the internet header in\n32 bit words ... Note that the minimum value for a correct header\nis 5.\u0026quot;). The kernel should not be willing to inject such a\npacket into its own output path.\n\nReject \u0026quot;iphlen \u0026lt; sizeof(*iph)\u0026quot; alongside the existing\n\u0026quot;iphlen \u0026gt; length\u0026quot; check. This matches the principle that locally\nconstructed packets that re-enter the IP stack must pass the same\nbasic sanity tests that a foreign packet would be subjected to.\n\nOnce this lands, the \u0026quot;if (iphlen \u0026gt;= sizeof(*iph))\u0026quot; wrapper around\nthe fixup branch becomes redundant; left in place to keep the\npatch minimal and backport-friendly. A follow-up can unwrap it.\n\nNote that commit 86f4c90a1c5c (\u0026quot;ipv4, ipv6: ensure raw socket\nmessage is big enough to hold an IP header\u0026quot;) ensures the message\nbuffer is large enough to hold an iphdr, but does not constrain\nthe self-reported iph-\u0026gt;ihl.\n\nReachability: the malformed packet source is any caller with\nCAP_NET_RAW, including an unprivileged process in a user+net\nnamespace on a kernel with CONFIG_USER_NS=y. The reproduced AH\ncrash also requires a matching xfrm AH policy on the outgoing\nroute; a container granted CAP_NET_ADMIN can install that state\nand policy in its netns. Loopback bypasses xfrm_output, so the\ntrigger uses a real netdev.\n\nReproduced on UML + KASAN: kernel-mode fault at addr 0x0 with\nmemcpy_orig at the crash site. Same shape reproduces inside a\nrootless Docker container with --cap-add NET_ADMIN on a stock\ndistro kernel.(CVE-2026-64114)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nqed: fix double free in qed_cxt_tables_alloc()\n\nIf one of the later PF or VF CID bitmap allocations fails,\nqed_cid_map_alloc() jumps to cid_map_fail and frees the previously\nallocated CID bitmaps before returning an error. qed_cxt_tables_alloc()\nthen calls qed_cxt_mngr_free(), which invokes qed_cid_map_free()\nagain.\n\nFix this by setting each CID bitmap pointer to NULL after bitmap_free()\nto avoid double free.\n\nThe bug was first flagged by an experimental analysis tool we are\ndeveloping for kernel memory-management bugs while analyzing\nv6.13-rc1. The tool is still under development and is not yet publicly\navailable. Manual inspection confirms that the bug is still\npresent in v7.1-rc3.\n\nRuntime reproduction was not attempted because exercising the failing\nallocation path requires device-specific setup.(CVE-2026-64118)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: MGMT: validate Add Extended Advertising Data length\n\nMGMT_OP_ADD_EXT_ADV_DATA is registered as a variable-length command,\nwith MGMT_ADD_EXT_ADV_DATA_SIZE as the fixed header size. The handler\nthen uses cp-\u0026gt;adv_data_len and cp-\u0026gt;scan_rsp_len to validate and copy\ncp-\u0026gt;data, but it never checks that those bytes are part of the mgmt\ncommand payload.\n\nA short command can therefore make add_ext_adv_data() pass an\nout-of-bounds pointer into tlv_data_is_valid(). If the bytes beyond\nthe command buffer are addressable, they can also be copied into the\nadvertising instance as scan response data, where the caller can read\nthem back via MGMT_OP_GET_ADV_INSTANCE. The trigger requires\nCAP_NET_ADMIN in the initial user namespace; KASAN reports an 8-byte\nslab-out-of-bounds read.\n\nReject commands whose length does not match the fixed header plus both\nadvertising data lengths before parsing cp-\u0026gt;data.(CVE-2026-64126)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: protect tc_count increment in smb2_find_smb_sess_tcon_unlocked()\n\nCommit 96c4af418586 (\u0026quot;cifs: Fix locking usage for tcon fields\u0026quot;)\nrefactored cifs code to change cifs_tcp_ses_lock for tc_lock around\ntc_count changes.\n\nThere was missing lock around tc_count increment inside\nsmb2_find_smb_sess_tcon_unlocked().(CVE-2026-64136)\n\nIn the Linux kernel, an out-of-bounds read vulnerability exists in the i2c-stub driver. The I2C_SMBUS_I2C_BLOCK_DATA case in stub_xfer() function (drivers/i2c/i2c-stub.c) uses data-\u0026gt;block[0] as the transfer length. The existing check only clamps it to avoid overrunning the chip-\u0026gt;words[256] register array, but does not validate it against I2C_SMBUS_BLOCK_MAX (32), which is the limit of the union i2c_smbus_data.block buffer. A local user with access to /dev/i2c-* devices can issue an I2C_SMBUS ioctl with I2C_SMBUS_I2C_BLOCK_DATA and data-\u0026gt;block[0] \u0026gt; 32, causing stub_xfer() to read or write past the end of the union i2c_smbus_data.block buffer, resulting in a stack out-of-bounds access. This vulnerability affects confidentiality, integrity, and availability.(CVE-2026-64191)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Validate payload length and link_index in dc_process_dmub_aux_transfer_async\n\n[Why\u0026amp;How]\ndc_process_dmub_aux_transfer_async() copies payload-\u0026gt;length bytes into a\n16-byte stack buffer (dpaux.data[16]) guarded only by an ASSERT(), which\nis a no-op in release builds. If a caller ever passes length \u0026gt; 16 this\nresults in a stack buffer overflow via memcpy.\n\nAdditionally, link_index is used to dereference dc-\u0026gt;links[] without\nbounds checking against dc-\u0026gt;link_count, risking an out-of-bounds access.\n\nReplace the ASSERT with a hard runtime check that returns false when\npayload-\u0026gt;length exceeds the destination buffer size, and add a bounds\ncheck for link_index before it is used.\n\n(cherry picked from commit ba4caa9fecdf7a38f98c878ad05a8a64148b6881)(CVE-2026-64219)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nocteontx2-pf: avoid double free of pool-\u0026gt;stack on AQ init failure\n\notx2_pool_aq_init() frees pool-\u0026gt;stack when mailbox sync or retry\nallocation fails, but leaves the pointer unchanged. Later,\notx2_sq_aura_pool_init() unwinds the partial setup through\notx2_aura_pool_free(), which frees pool-\u0026gt;stack again. The CN20K-specific\ncn20k_pool_aq_init() implementation has the same bug in\nits corresponding error path.\n\nSet pool-\u0026gt;stack to NULL immediately after the local free so the shared\ncleanup path does not free the same stack again while cleaning up\npartially initialized pool state.\n\nThe bug was first flagged by an experimental analysis tool we are\ndeveloping for kernel memory-management bugs while analyzing\nv6.13-rc1. The tool is still under development and is not yet publicly\navailable. Manual inspection confirms that the bug is still present in\nv7.1-rc3.\n\nRuntime validation was not performed because reproducing this path\nrequires OcteonTX2/CN20K hardware.(CVE-2026-64222)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nInput: elan_i2c - validate firmware size before use\n\nEnsure that the firmware file is large enough to contain the expected\nnumber of pages and the signature (which resides at the end of the\nfirmware blob) before accessing them to prevent potential out-of-bounds\nreads.(CVE-2026-64237)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: x86: hyper-v: Bound the bank index when querying sparse banks\n\nWhen checking if a VP ID is included in a sparse bank set, explicitly check\nthat the ID can actually be contained in a sparse bank (the TLFS allows for\na maximum of 64 banks of 64 vCPUs each). When handling a paravirtual TLB\nflush for L2, the VP ID is copied verbatim from the enlightened VMCS,\nwithout any bounds check, i.e. isn\u0026apos;t guaranteed to be under the limit of\n4096.\n\nFailure to check the bounds of the VP ID leads to an out-of-bounds read\nwhen testing the sparse bank, and super strictly speaking could lead to KVM\nperforming an unnecessary TLB flush for an L2 vCPU.\n\n ==================================================================\n BUG: KASAN: use-after-free in hv_is_vp_in_sparse_set+0x85/0x100 [kvm]\n Read of size 8 at addr ffff88811ba5f598 by task hyperv_evmcs/2802\n\n CPU: 12 UID: 1000 PID: 2802 Comm: hyperv_evmcs Not tainted 7.1.0-rc2 #7 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+0x51/0x60\n print_report+0xcb/0x5d0\n kasan_report+0xb4/0xe0\n kasan_check_range+0x35/0x1b0\n hv_is_vp_in_sparse_set+0x85/0x100 [kvm]\n kvm_hv_flush_tlb+0xe9e/0x16c0 [kvm]\n kvm_hv_hypercall+0xe6b/0x1e60 [kvm]\n vmx_handle_exit+0x485/0x1b60 [kvm_intel]\n kvm_arch_vcpu_ioctl_run+0x22e3/0x5070 [kvm]\n kvm_vcpu_ioctl+0x5d0/0x10c0 [kvm]\n __x64_sys_ioctl+0x129/0x1a0\n do_syscall_64+0xb9/0xcf0\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n RIP: 0033:0x7f0e62d1a9bf\n \u0026lt;/TASK\u0026gt;\n\n The buggy address belongs to the physical page:\n page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffffffffffffffff pfn:0x11ba5f\n flags: 0x4000000000000000(zone=1)\n raw: 4000000000000000 0000000000000000 00000000ffffffff 0000000000000000\n raw: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000000\n page dumped because: kasan: bad access detected\n\n Memory state around the buggy address:\n ffff88811ba5f480: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff\n ffff88811ba5f500: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff\n \u0026gt;ffff88811ba5f580: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff\n ^\n ffff88811ba5f600: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff\n ffff88811ba5f680: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff\n ==================================================================\n Disabling lock debugging due to kernel taint\n\nOpportunistically add a compile time assertion to ensure the maximum number\nof sparse banks exactly matches the number of possible bits in the passed\nin mask.\n\n[sean: add KASAN splat, drop comment, add assert, massage changelog](CVE-2026-64247)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFSv4: include MAY_WRITE in open permission mask for O_TRUNC\n\nPOSIX requires write permission to truncate a file, so an open() that\nspecifies O_TRUNC must be authorized for write access regardless of the\nO_ACCMODE access mode.\n\nnfs_open_permission_mask() builds the access mask passed to\nnfs_may_open(), which is the local authorization gate for OPENs the\nclient serves itself from a cached write delegation via the\ncan_open_delegated() path in nfs4_try_open_cached(). The mask is\nderived from O_ACCMODE alone, so an open(O_RDONLY | O_TRUNC) against a\nfile the caller cannot write requests only MAY_READ and passes the\nlocal check. The OPEN is then satisfied locally and the truncation is\nissued to the server as a SETATTR(size=0) over the delegation stateid,\nwhich the server accepts under standard write-delegation semantics.\nPOSIX requires that this open fail with EACCES.\n\nInclude MAY_WRITE in the mask whenever O_TRUNC is set so the local\ncheck matches the access the server would have enforced.(CVE-2026-64298)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Prevent out-of-bounds read in glob matching\n\nString event fields are not necessarily NUL-terminated, so the filter\npredicate functions (filter_pred_string(), filter_pred_strloc() and\nfilter_pred_strrelloc()) pass the field length to the regex match\ncallbacks, and the length-aware matchers honour it.\n\nregex_match_glob() was the exception: it ignored the length and called\nglob_match(), which scans the string until it hits a NUL byte. Some\nstring fields are not NUL-terminated. One example is the dynamic char\narray of the xfs_* namespace tracepoints, which is copied without a\ntrailing NUL. For such a field, glob matching reads past the end of\nthe event field, causing a KASAN slab-out-of-bounds read in\nglob_match(), reached via regex_match_glob() and filter_match_preds()\nfrom the xfs_lookup tracepoint.\n\nAdd a length-bounded glob_match_len() and use it from regex_match_glob()\nso glob matching always stops at the field boundary. The matching loop\nis factored into a shared helper so glob_match() keeps its behaviour.(CVE-2026-64299)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: qat - validate RSA CRT component lengths\n\nThe generic RSA key parser (rsa_helper.c) bounds each CRT component (p,\nq, dp, dq, qinv) by the modulus size n_sz, but qat_rsa_setkey_crt()\nallocates half-size DMA buffers (key_sz / 2) and right-aligns each\ncomponent with:\n\n memcpy(dst + half_key_sz - len, src, len)\n\nWhen a CRT component is larger than half_key_sz the subtraction\nunderflows and memcpy writes past the DMA buffer, causing memory\ncorruption.\n\nAdd a len \u0026gt; half_key_sz check next to the existing !len check for each\nof the five CRT components so the driver falls back to the non-CRT path\ninstead of writing out of bounds.(CVE-2026-64304)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: qat - protect service table iterations with service_lock\n\nThe service_table list is protected by service_lock when entries are\nadded or removed (in adf_service_add() and adf_service_remove()), but\nseveral functions iterate over the list without holding this lock.\n\nA concurrent adf_service_register() or adf_service_unregister() call\ncould modify the list during traversal, leading to list corruption or\na use-after-free.\n\nFix this by holding service_lock across all list_for_each_entry()\niterations of service_table in adf_dev_init(), adf_dev_start(),\nadf_dev_stop(), adf_dev_shutdown(), adf_dev_restarting_notify(),\nadf_dev_restarted_notify(), and adf_error_notifier().\n\nThe lock ordering is safe: callers of the static helpers (adf_dev_up()\nand adf_dev_down()) acquire state_lock before service_lock, and no\nevent_hld callback or service_lock holder ever acquires state_lock in\nthe reverse order.(CVE-2026-64305)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: drbg - Fix returning success on failure in CTR_DRBG\n\ndrbg_ctr_generate() sometimes returns success when it fails, leaving the\noutput buffer uninitialized. Fix it.(CVE-2026-64306)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: pcrypt - restore callback for non-parallel fallback\n\npcrypt installs pcrypt_aead_done() on the child AEAD request before\ntrying to submit it through padata. If padata_do_parallel() returns\n-EBUSY, pcrypt falls back to calling the child AEAD directly.\n\nThat fallback must not keep the padata completion callback. Otherwise\nan asynchronous completion runs pcrypt_aead_done() even though the\nrequest was never enrolled in padata.\n\nRestore the original request callback and callback data before calling\nthe child AEAD directly. This keeps the fallback path aligned with a\ndirect AEAD request while leaving the parallel path unchanged.(CVE-2026-64312)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: ecc - Fix carry overflow in vli multiplication\n\nThe carry flag calculation fails when r01.m_high is saturated\n(0xFFFFFFFFFFFFFFFF) and addition of lower bits overflows.\n\nThe condition (r01.m_high \u0026lt; product.m_high) doesn\u0026apos;t handle the case\nwhere r01.m_high == product.m_high and an additional carry exists\nfrom lower-bit overflow.\n\nWhen commit 3c4b23901a0c (\u0026quot;crypto: ecdh - Add ECDH software support\u0026quot;)\nintroduced crypto/ecc.c, it split the muladd() function in the\nmicro-ecc library into separate mul_64_64() and add_128_128() helpers.\nIt seems the check got lost in translation.\n\nAdd proper handling for this boundary by accounting for the carry\nfrom the lower addition.(CVE-2026-64313)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nisofs: bound Rock Ridge symlink components to the SL record\n\nget_symlink_chunk() and the SL handling in\nparse_rock_ridge_inode_internal() walk the variable-length components of\na Rock Ridge \u0026quot;SL\u0026quot; (symbolic link) record. Each component is a two-byte\nheader (flags, len) followed by len bytes of text, so it occupies\nslp-\u0026gt;len + 2 bytes. Both loops read slp-\u0026gt;len and advance to the next\ncomponent, and get_symlink_chunk() additionally does\nmemcpy(rpnt, slp-\u0026gt;text, slp-\u0026gt;len), but neither checks that the component\nlies within the SL record before dereferencing it.\n\nA crafted SL record whose component declares a len that runs past the\nrecord (rr-\u0026gt;len) therefore triggers an out-of-bounds read of up to 255\nbytes. When the record sits at the tail of its backing buffer - for\nexample a small kmalloc()ed continuation block reached through a CE\nrecord - the read crosses the allocation; get_symlink_chunk() then\ncopies the out-of-bounds bytes into the symlink body returned to user\nspace by readlink(), disclosing adjacent kernel memory.\n\nISO 9660 images are routinely mounted from untrusted removable media -\ndesktop environments auto-mount them (e.g. via udisks2) without\nCAP_SYS_ADMIN - so the record contents are attacker-controlled.\n\nReject any component that does not fit in the remaining record bytes\nbefore using it. In get_symlink_chunk() return NULL, like the existing\noutput-buffer (plimit) checks, so a malformed record makes readlink()\nfail with -EIO rather than silently returning a truncated target; in\nparse_rock_ridge_inode_internal() stop the inode-size walk.(CVE-2026-64317)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvmet-auth: validate reply message payload bounds against transfer length\n\nnvmet_auth_reply() accesses the variable-length rval[] array using\nattacker-controlled hl (hash length) and dhvlen (DH value length) fields\nwithout verifying they fit within the allocated buffer of tl bytes.\n\nA malicious NVMe-oF initiator can craft a DHCHAP_REPLY message with a\nsmall transfer length but large hl/dhvlen values, causing out-of-bounds\nheap reads when the target processes the DH public key (rval + 2*hl) or\nperforms the host response memcmp.\n\nWith DH authentication configured, the OOB pointer is passed directly to\nsg_init_one() and read by crypto_kpp_compute_shared_secret(), reaching\nup to 526 bytes past the buffer. This is exploitable pre-authentication.\n\nAdd bounds validation ensuring sizeof(*data) + 2*hl + dhvlen \u0026lt;= tl before\nany access to the variable-length fields.\n\nDiscovered by Atuin - Automated Vulnerability Discovery Engine.(CVE-2026-64319)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvmet: fix pre-auth out-of-bounds heap read in Discovery Get Log Page\n\nnvmet_execute_disc_get_log_page() validates only the dword alignment\nof the host-supplied Log Page Offset (lpo). The 64-bit offset is then\nadded to a small kzalloc\u0026apos;d buffer that holds the discovery log page\nand the result is passed straight to nvmet_copy_to_sgl(), which\nmemcpy()s data_len bytes out to the host with no source-side bound\ncheck:\n\n u64 offset = nvmet_get_log_page_offset(req-\u0026gt;cmd); /* 64-bit host */\n size_t data_len = nvmet_get_log_page_len(req-\u0026gt;cmd); /* 32-bit host */\n ...\n if (offset \u0026amp; 0x3) { ... } /* only check */\n ...\n alloc_len = sizeof(*hdr) + entry_size * discovery_log_entries(req);\n buffer = kzalloc(alloc_len, GFP_KERNEL);\n ...\n status = nvmet_copy_to_sgl(req, 0, buffer + offset, data_len);\n\nThe Discovery controller is unauthenticated -- nvmet_host_allowed()\nreturns true unconditionally for the discovery subsystem -- so the call\nis reachable pre-authentication by any TCP/RDMA/FC peer that can reach\nthe nvmet target. With a discovery log page of ~1 KiB, an attacker\nrequesting up to 4 KiB starting at offset == alloc_len reads the next\nslab page out and gets its content returned over the fabric (an\nempirical run on a default nvmet-tcp loopback target leaked 81\ncanonical kernel pointers in one Get Log Page response). Pointing the\noffset at unmapped kernel memory faults the in-kernel memcpy and\ncrashes (or panics, on panic_on_oops=1) the target host instead.\n\nThe attacker-controlled source-side offset pattern\n\u0026quot;nvmet_copy_to_sgl(req, 0, buffer + ATTACKER_OFFSET, ...)\u0026quot; is unique\nto nvmet_execute_disc_get_log_page in the entire nvmet codebase: every\nother Get Log Page handler in admin-cmd.c either ignores lpo (and\nsilently starts every response at offset 0) or tracks a local\ndestination offset with a fixed source pointer.\n\nValidate the host-supplied offset against the log page size, cap the\ncopy length to what is actually available, and zero-fill any remainder\nof the host transfer buffer. The zero-fill matches the existing\nshort-response pattern in nvmet_execute_get_log_changed_ns()\n(admin-cmd.c) and prevents leaking transport SGL contents when the\nhost asks for more bytes than the log page contains.(CVE-2026-64320)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nudf: validate sparing table length as an entry count, not a byte count\n\nudf_load_sparable_map() accepts a sparing table when\n\n\tsizeof(*st) + le16_to_cpu(st-\u0026gt;reallocationTableLen) \u0026gt; sb-\u0026gt;s_blocksize\n\nis false, i.e. it treats reallocationTableLen as a number of BYTES that\nmust fit in the block. But the table is walked as an array of 8-byte\nsparingEntry elements:\n\n\tfor (i = 0; i \u0026lt; le16_to_cpu(st-\u0026gt;reallocationTableLen); i++) {\n\t\tstruct sparingEntry *entry = \u0026amp;st-\u0026gt;mapEntry[i];\n\t\t... entry-\u0026gt;origLocation ...\n\t}\n\nin udf_get_pblock_spar15() and udf_relocate_blocks(). A\nreallocationTableLen of N therefore passes the check whenever\nsizeof(*st) + N \u0026lt;= blocksize, yet the consumers index\nsizeof(*st) + N * sizeof(struct sparingEntry) bytes -- up to ~8x the\nblock. On a crafted UDF image this is an out-of-bounds read in\nudf_get_pblock_spar15(); udf_relocate_blocks() additionally feeds the\nsame length to udf_update_tag(), whose crc_itu_t() reads far past the\nblock, and its memmove() through st-\u0026gt;mapEntry[] is an out-of-bounds\nwrite.\n\nValidate reallocationTableLen as the entry count it is, with\nstruct_size().(CVE-2026-64322)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nudf: validate VAT header length against the VAT inode size\n\nudf_load_vat() takes the virtual partition\u0026apos;s start offset straight from\nthe on-disk VAT 2.0 header without checking it against the VAT inode\nsize:\n\n\tmap-\u0026gt;s_type_specific.s_virtual.s_start_offset =\n\t\tle16_to_cpu(vat20-\u0026gt;lengthHeader);\n\tmap-\u0026gt;s_type_specific.s_virtual.s_num_entries =\n\t\t(sbi-\u0026gt;s_vat_inode-\u0026gt;i_size -\n\t\t\tmap-\u0026gt;s_type_specific.s_virtual.s_start_offset) \u0026gt;\u0026gt; 2;\n\nlengthHeader is a fully attacker-controlled 16-bit value. If it exceeds\nthe VAT inode size, the s_num_entries subtraction underflows to a huge\ncount, which defeats the \u0026quot;block \u0026gt; s_num_entries\u0026quot; bound in\nudf_get_pblock_virt15(); and on the ICB-inline path that function reads\n\n\t((__le32 *)(iinfo-\u0026gt;i_data + s_start_offset))[block]\n\nso a large s_start_offset indexes past the inode\u0026apos;s in-ICB data. Mounting\na crafted UDF image with a virtual (VAT) partition then triggers an\nout-of-bounds read.\n\nReject a VAT whose header length does not leave room for at least one\nentry within the VAT inode.(CVE-2026-64323)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nudf: validate free block extents against the partition length\n\nudf_free_blocks() checks the logical block number and count against the\npartition length, but drops the extent offset from that final bound. A\ncrafted extent can pass the guard while logicalBlockNum + offset + count\npoints past the partition, which later indexes past the space bitmap\narray.\n\nA single ftruncate(2) on a file backed by such an extent reliably\npanics the kernel. This is a local availability issue. On desktop\nsystems where UDisks/polkit allows the active user to mount removable\nUDF media without CAP_SYS_ADMIN, an unprivileged local user can supply\nthe crafted filesystem and trigger the panic by truncating a writable\nfile on it. Systems that require root or CAP_SYS_ADMIN to mount the\nimage have a higher prerequisite.\n\nNo confidentiality or integrity impact is claimed: the reproduced\nprimitive is an out-of-bounds read of a bitmap pointer slot followed by\na kernel panic.\n\nUse the already computed logicalBlockNum + offset + count value for the\npartition length check. Also make load_block_bitmap() reject an\nout-of-range block group before indexing s_block_bitmap[], so corrupted\ncallers cannot walk past the flexible array.(CVE-2026-64324)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Reject fragmented frames in devmap\n\nDevmap broadcast redirects clone the packet for all but the last\ndestination.\n\nFor native XDP, that clone path copies only the linear xdp_frame data,\nwhile fragmented frames keep skb_shared_info in tailroom outside the\nlinear area. Cloning such a frame leaves XDP_FLAGS_HAS_FRAGS set but\nwithout valid frag metadata, and the later free path can interpret\nuninitialized tail data as skb_shared_info, leading to an out-of-bounds\naccess during frame return.\n\nReject fragmented native XDP frames in dev_map_enqueue_clone().\n\nAdd the same restriction to the generic XDP clone path in\ndev_map_redirect_clone(). Generic XDP represents fragmented packets as\nnonlinear skbs, and rejecting them here keeps clone-based broadcast\nsupport aligned between native and generic XDP.(CVE-2026-64355)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: multitouch: fix out-of-bounds bit access on mt_io_flags\n\nmt_io_flags is a single unsigned long, but mt_process_slot(),\nmt_release_pending_palms() and mt_release_contacts() use it as a\nper-slot bitmap indexed by the slot number. That slot number is only\nbounded by td-\u0026gt;maxcontacts, which is taken from the device\u0026apos;s\nContactCountMaximum feature report and can be up to 255, not by\nBITS_PER_LONG.\n\nAs a result, a multitouch device that advertises a large contact count\nmakes set_bit()/clear_bit() operate past the mt_io_flags word and\ncorrupt the adjacent members of struct mt_device. The sticky-fingers\nrelease timer is the easiest way to reach this. mt_release_contacts()\nruns\n\n\tfor (i = 0; i \u0026lt; mt-\u0026gt;num_slots; i++)\n\t\tclear_bit(i, \u0026amp;td-\u0026gt;mt_io_flags);\n\nwith num_slots == maxcontacts. For maxcontacts around 250 the loop\nclears the bits that overlap td-\u0026gt;applications.next, zeroing that list\nhead, and the list_for_each_entry() that immediately follows then\ndereferences NULL. The kernel panics from timer (softirq) context. On a\nKASAN build this shows up as a general protection fault in\nmt_release_contacts() with a null-ptr-deref at offset 0x58, which is\noffsetof(struct mt_application, num_received).\n\nThe state is reachable from an untrusted USB or Bluetooth HID\nmultitouch device; no local privileges are required.\n\nStore the per-slot active state in a separately allocated bitmap sized\nfor maxcontacts, the same pattern already used for pending_palm_slots,\nand keep only MT_IO_FLAGS_RUNNING in mt_io_flags. The two\n\u0026quot;mt_io_flags \u0026amp; MT_IO_SLOTS_MASK\u0026quot; arming checks become\nbitmap_empty(td-\u0026gt;active_slots, td-\u0026gt;maxcontacts).\n\nMove MT_IO_FLAGS_RUNNING back to bit 0. It was bumped to bit 32 by the\nsame commit to leave the low byte for the slot bits; with the slot bits\ngone it fits in bit 0 again, which also keeps it within the unsigned\nlong on 32-bit.(CVE-2026-64364)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsched/rt: Have RT_PUSH_IPI be default off for non PREEMPT_RT\n\nRT migration is done aggressively. When a CPU schedules out a high\npriority RT task for a lower priority task, it will look to see if there\u0026apos;s\nany RT tasks that are waiting to run on another CPU that is of higher\npriority than the task this CPU is about to run. If it finds one, it will\npull that task over to the CPU and allow it to run there instead.\n\nNormally, this pulling is done by looking at the RT overloaded mask (rto)\nwhich contains all the CPUs in the scheduler domain with RT tasks that are\nwaiting to run due to a higher priority RT task currently running on their\nCPU. The CPU that is about to schedule a lower priority task will grab the\nrq lock of the overloaded CPU and move the RT task from that CPU\u0026apos;s runqueue\nto the local one and schedule the higher priority RT task.\n\nThis caused issues when a lot of CPUs would schedule a lower priority task\nat the same time. They would all try to grab the same runqueue lock of\nthe CPU with the overloaded RT tasks. Only the first CPU that got in will\nget that task. All the others would wait until they got the runqueue lock\nand see there\u0026apos;s nothing to pull and do nothing. On systems with lots of\nCPUs, this caused a large latency (up to 500us) which is beyond what\nPREEMPT_RT is to allow.\n\nThe solution to that was to create an RT_PUSH_IPI logic. When any CPU\nwanted to pull a task, instead of grabbing the runqueue lock of the\noverloaded CPU, it would start by sending an IPI to the overloaded CPU,\nand that IPI handler would have the CPU with the waiting RT task do a push\ninstead. Then that handler would send an IPI to the next CPU with\noverloaded RT tasks, and so on. Note, after the first CPU starts this\nprocess, if another CPU wanted to do a pull, it would see that the process\nhas already begun and would only increment a counter to have the IPIs\ncontinue again.\n\nThe RT_PUSH_IPI solved the latency problem with PREEMPT_RT but could cause\na new issue with non PREEMPT_RT. Namely, softirqs run in a threaded\ncontext on PREEMPT_RT but they can run in an interrupt context in non-RT.\n\nIf an IPI lands on a CPU that has just woken up multiple RT tasks and the\ncurrent CPU is running a non RT or a low priority RT task, instead of\ndoing a push, it would simply do a schedule on that CPU. But if a softirq\nwas also executing on this CPU, the schedule would need to wait until the\nsoftirq finished. Until then, the CPU would still be considered overloaded\nas there are RT tasks still waiting to run on it.\n\nA live lock occurred on a workload that was doing heavy networking traffic\non a large machine where the softirqs would run 500us out of 750us. And it\nwould also be waking up RT tasks, causing the RT pull logic to be\nconstantly executed.\n\nWhen a softirq triggered on a CPU with RT tasks queued but not running\nyet, and the other CPUs would see this CPU as being overloaded, they would\nsend an IPI over to it. The CPU would notice that the waiting RT tasks are\nof higher priority than the currently running task and simply schedule\nthat CPU instead. But because the softirq was executing, before it could\nschedule, it would receive another IPI to do the same. The amount of IPIs\nwould slow down the currently running softirq so much that before it could\nreturn back to task context, it would execute another softirq never\nallowing the CPU to schedule. This live locked that CPU.\n\nAs RT_PUSH_IPI was created to help PREEMPT_RT, make it default off if\nPREEMPT_RT is not enabled.(CVE-2026-64374)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwriteback: fix race between cgroup_writeback_umount() and inode_switch_wbs()\n\nWhen a container exits, the following BUG_ON() is occasionally triggered:\n\n==================================================================\n VFS: Busy inodes after unmount of sdb (ext4)\n ------------[ cut here ]------------\n kernel BUG at fs/super.c:695!\n CPU: 3 PID: 6 Comm: containerd-shim Tainted: G OE K 6.6 #1\n pstate: 63400009 (nZCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)\n pc : generic_shutdown_super+0xf0/0x100\n lr : generic_shutdown_super+0xf0/0x100\n Call trace:\n generic_shutdown_super+0xf0/0x100\n kill_block_super+0x20/0x48\n ext4_kill_sb+0x28/0x60\n deactivate_locked_super+0x54/0x130\n deactivate_super+0x84/0xa0\n cleanup_mnt+0xa4/0x140\n __cleanup_mnt+0x18/0x28\n task_work_run+0x78/0xe0\n do_notify_resume+0x204/0x240\n==================================================================\n\nThe root cause is a race between cgroup_writeback_umount() and\ninode_switch_wbs()/cleanup_offline_cgwb(). There is a window between\ninode_prepare_wbs_switch() returning true and the subsequent\nwb_queue_isw() call. Following is the process that triggers the issue:\n\n CPU A (umount) | CPU B (writeback)\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n inode_switch_wbs/cleanup_offline_cgwb\n atomic_inc(\u0026amp;isw_nr_in_flight)\n inode_prepare_wbs_switch\n -\u0026gt; passes SB_ACTIVE check\n __iget(inode)\n generic_shutdown_super\n sb-\u0026gt;s_flags \u0026amp;= ~SB_ACTIVE\n cgroup_writeback_umount(sb)\n smp_mb()\n atomic_read(\u0026amp;isw_nr_in_flight)\n rcu_barrier()\n -\u0026gt; no pending RCU callbacks\n flush_workqueue(isw_wq)\n -\u0026gt; nothing queued, returns\n evict_inodes(sb)\n -\u0026gt; Inode skipped as isw still holds a ref.\n sop-\u0026gt;put_super(sb)\n /* destroys percpu counters */\n -\u0026gt; VFS: Busy inodes after unmount!\n wb_queue_isw()\n queue_work(isw_wq, ...)\n /* later in work function */\n inode_switch_wbs_work_fn\n process_inode_switch_wbs\n iput() -\u0026gt; evict\n percpu_counter_dec() // UAF!\n\nFix this by extending the RCU read-side critical section in\ninode_switch_wbs() and cleanup_offline_cgwb() to cover from\ninode_prepare_wbs_switch() through wb_queue_isw(). Since there is\nno sleep in this window, rcu_read_lock() can be used. Then add a\nsynchronize_rcu() in cgroup_writeback_umount() before the existing\nrcu_barrier(), so that all in-flight switchers that have passed the\nSB_ACTIVE check have completed queue_work() before flush_workqueue()\nis called.\n\nThe existing rcu_barrier() is intentionally retained so this fix can\nbe backported unchanged to stable kernels (5.10.y, 6.6.y, ...) that\nstill queue switches via queue_rcu_work(). It is a no-op on current\nmainline (since commit e1b849cfa6b6 (\u0026quot;writeback: Avoid contention on\nwb-\u0026gt;list_lock when switching inodes\u0026quot;)) and is removed in a follow-up\npatch.(CVE-2026-64378)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: mask server-provided mode to 07777 in modefromsid\n\nWhen modefromsid is active, parse_dacl() applies the server-provided\nsub_auth[2] value from the NFS mode SID to cf_mode without masking to\n07777. Apply the correct masking, same as in the read path.(CVE-2026-64379)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: harden POSIX SID length parsing\n\nposix_info_sid_size() reads sid[1] to obtain the subauthority count,\nbut its existing boundary check still accepts buffers with only one\nremaining byte. Require two bytes before reading sid[1] so all client\npaths that reuse the helper reject truncated POSIX SIDs safely.(CVE-2026-64380)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix double-free in SMB2_open() replay\n\nA response-bearing attempt can return a replayable error and free its\nresponse buffer. If SMB2_open_init() fails before the next send, cleanup\nretains the previous buffer type and frees that response again.\n\nReset response bookkeeping before each attempt to prevent the stale free.(CVE-2026-64382)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix double-free in SMB2_flush() replay\n\nSMB2_flush() keeps its response buffer bookkeeping across replay\nattempts. If a replayable flush response is received and the retry then\nfails before cifs_send_recv() stores a replacement response, flush_exit\nwill free the stale response pointer a second time.\n\nReinitialize resp_buftype and rsp_iov at the top of the replay loop so\ncleanup only acts on response state produced by the current attempt.\nThis fixes a double-free without changing replay handling for successful\nrequests.(CVE-2026-64383)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix change notify replay double-free\n\nA response-bearing attempt can return a replayable error and free its\nresponse buffer. If SMB2_notify_init() fails before the next send, cleanup\nretains the previous buffer type and frees that response again.\n\nReset response bookkeeping before each attempt to prevent the stale free.(CVE-2026-64384)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix double-free in SMB2_ioctl() replay\n\nA response-bearing attempt can return a replayable error and free its\nresponse buffer. If SMB2_ioctl_init() fails before the next send, cleanup\nretains the previous buffer type and frees that response again.\n\nReset response bookkeeping before each attempt to prevent the stale free.(CVE-2026-64385)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix query_info() replay double-free\n\nA response-bearing attempt can return a replayable error and free its\nresponse buffer. If SMB2_query_info_init() fails before the next send,\ncleanup retains the previous buffer type and frees that response again.\n\nReset response bookkeeping before each attempt to prevent the stale free.(CVE-2026-64386)\n\nIn the Linux kernel, an out-of-bounds read vulnerability exists in the SMB client. smb2_check_message() has a long-standing quirk that accepts a response whose calculated length is one byte larger than the bytes actually received (\u0026quot;server can return one byte more due to implied bcc[0]\u0026quot;). This was introduced to accommodate servers that omit the trailing bcc[0] overlap byte when no data area is present. However, the exemption is applied unconditionally, regardless of whether the command actually carries a data area (has_smb2_data_area[]). When a response with a data area is subject to the +1 exemption, the reported data can extend one byte beyond the bytes actually received, causing the subsequent decoder to read past the end of the receive buffer. This is reachable during NEGOTIATE and SESSION_SETUP, before the session is established. The resulting out-of-bounds reads are visible under KASAN when mounting against a non-conforming server, affecting both the SPNEGO/negTokenInit and the NTLMSSP challenge decoders.(CVE-2026-64448)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nhwrng: virtio: clamp device-reported used.len at copy_data()\n\nrandom_recv_done() stores the device-reported used.len directly into\nvi-\u0026gt;data_avail. copy_data() then indexes vi-\u0026gt;data[] using\nvi-\u0026gt;data_idx (advanced by previous copy_data() calls) and issues a\nmemcpy() without re-validating either value against the posted\nbuffer size sizeof(vi-\u0026gt;data) (SMP_CACHE_BYTES bytes, typically 32\nor 64).\n\nA malicious or buggy virtio-rng backend can set used.len beyond\nsizeof(vi-\u0026gt;data), steering the memcpy() past the end of the inline\narray into adjacent kmalloc-1k slab bytes. hwrng_fillfn() mixes\nthose bytes into the guest RNG, and guest root can also observe\nthem directly via /dev/hwrng.\n\nConcrete impact is inside the guest:\n\n - Memory-safety / hardening: any virtio-rng backend that\n over-reports used.len causes the driver to read past vi-\u0026gt;data\n into unrelated slab contents. hwrng_fillfn() is a kernel thread\n that runs as soon as the device is probed; no guest userspace\n interaction is required to first-trigger the OOB.\n\n - Cross-boundary leak (confidential-compute threat model): a\n malicious hypervisor cooperating with a malicious or compromised\n guest root userspace can use /dev/hwrng as a leak channel for\n guest-kernel heap data. The host sets a large used.len, guest\n root reads /dev/hwrng, and the returned bytes contain guest\n kernel slab contents that were adjacent to vi-\u0026gt;data. In\n practice, confidential-compute guests (SEV-SNP, TDX) usually\n disable virtio-rng entirely, so this path is narrow, but the\n fix is still worth carrying because the underlying\n memory-safety bug contaminates the guest RNG on any host.\n\nKASAN confirms the OOB on a 7.1-rc4 guest whose virtio-rng backend\nhas been patched to report used.len = 0x10000:\n\n BUG: KASAN: slab-out-of-bounds in virtio_read+0x394/0x5d0\n Read of size 64 at addr ffff88800ae0ba20 by task hwrng/52\n Call Trace:\n __asan_memcpy+0x23/0x60\n virtio_read+0x394/0x5d0\n hwrng_fillfn+0xb2/0x470\n kthread+0x2cc/0x3a0\n Allocated by task 1:\n probe_common+0xa5/0x660\n virtio_dev_probe+0x549/0xbc0\n The buggy address belongs to the object at ffff88800ae0b800\n which belongs to the cache kmalloc-1k of size 1024\n The buggy address is located 0 bytes to the right of\n allocated 544-byte region [ffff88800ae0b800, ffff88800ae0ba20)\n\nSame class of bug as commit c04db81cd028 (\u0026quot;net/9p: Fix buffer\noverflow in USB transport layer\u0026quot;), which hardened\nusb9pfs_rx_complete() against unchecked device-reported length in\nthe USB 9p transport.\n\nWith the clamp at point of use and array_index_nospec() in place,\nthe same harness boots cleanly: copy_data() returns zero for the\nbogus report, the device-supplied bytes after data_idx are\ndiscarded, and the driver issues a fresh request.(CVE-2026-64456)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nALSA: hda/cs35l41: Fix firmware load work teardown\n\ncs35l41_hda creates ALSA controls whose private data points at the\ncs35l41_hda object. The firmware load control can also queue\nfw_load_work.\n\nThose controls are not removed on component unbind, and device remove\nonly cancels fw_load_work through cs35l41_remove_dsp(). That helper is\nskipped when halo_initialized is false. With firmware_autostart\ndisabled, a firmware load can be requested before the DSP has been\ninitialized. If the component or device is removed before the queued\nwork runs, the worker can run after teardown and dereference driver\nstate that is no longer valid.\n\nTrack the created controls and remove them on unbind so no new control\ncallback can reach the driver data or queue more work. Then cancel\nfw_load_work to drain any request that was already queued. Also cancel\nthe work unconditionally during device remove before runtime PM teardown.(CVE-2026-64481)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niio: event: Fix event FIFO reset race\n\n`iio_event_getfd()` creates the event file descriptor with\n`anon_inode_getfd()`, which allocates a new fd, creates the anonymous\nfile and installs it in the process fd table before returning to the\ncaller.\n\nThe IIO code resets the event FIFO after `anon_inode_getfd()` has returned,\nbut before `IIO_GET_EVENT_FD_IOCTL` has copied the fd number to userspace.\nBut since fd tables are shared between threads, another thread can guess\nthe newly allocated fd number and issue a `read()` on it as soon as the fd\nhas been installed.\n\nThis means the `kfifo_to_user()` in `iio_event_chrdev_read()` can run in\nparallel with the `kfifo_reset_out()` in `iio_event_getfd()`.\n\nThe kfifo documentation says that `kfifo_reset_out()` is only safe when it\nis called from the reader thread and there is only one concurrent reader.\nOtherwise it is dangerous and must be handled in the same way as\n`kfifo_reset()`.\n\nIf that happens, `kfifo_to_user()` can advance the FIFO `out` index based\non state from before the reset, after the reset has already moved the `out`\nindex to the current `in` index. That can leave the FIFO with an `out`\nindex past the `in` index. A later `read()` can then see an underflowed\nFIFO length and copy more data than the event FIFO buffer contains. This\ncan result in an out-of-bounds read and leak adjacent kernel memory to\nuserspace.\n\nMove the FIFO reset before `anon_inode_getfd()`. At that point the event fd is\nmarked busy, but the new fd has not been installed yet, so userspace cannot\naccess it while the FIFO is reset.(CVE-2026-64496)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: openvswitch: reject oversized nested action attrs\n\nOpen vSwitch stores generated flow actions as nlattrs, whose nla_len\nfield is u16. Commit a1e64addf3ff (\u0026quot;net: openvswitch: remove\nmisbehaving actions length check\u0026quot;) allowed the total sw_flow_actions\nstream to grow beyond 64 KiB, which is valid, but also removed the last\nguard preventing a generated nested action attribute from exceeding\nU16_MAX.\n\nAn oversized generated container can thus be closed with a truncated\nnla_len. A later dump or teardown then walks a structurally different\nstream than the one that was validated. In particular, an oversized\nnested CLONE/CT action may cause subsequent bytes in the generated\nstream to be interpreted as independent actions.\n\nKeep the larger total-action-stream behavior, but make nested action\nclose reject generated containers that do not fit in nla_len, and return\nthe error through all callers. For recursive SAMPLE, CLONE, DEC_TTL, and\nCHECK_PKT_LEN builders, trim resource-owning action-list tails in reverse\nconstruction order before discarding failed wrappers, so resources copied\ninto the rejected tails are released before the wrappers are removed.\n\nMost failed outer wrappers are discarded by truncating actions_len after\nchild resources have been released. CHECK_PKT_LEN also trims its parent\nafter branch resources are gone. SET/TUNNEL close failures unwind their\nknown tun_dst ownership directly, and SET_TO_MASKED has no external\nownership and truncates on close failure.(CVE-2026-64531)\n\nIn the Linux kernel, the following vulnerability has been resolved:\\n\\nperf/core: Detach event groups during remove_on_exec\\n\\nperf_event_remove_on_exec() removes events by calling\\nperf_event_exit_event(). For top-level events, this removes the event from\\nthe context with DETACH_EXIT only.\\n\\nThis can leave inconsistent group state when a removed event is a group\\nleader and the group contains siblings without remove_on_exec. If the group\\nwas active, the surviving siblings can remain active and attached to the\\nremoved leader\u0026apos;s sibling list, but are no longer represented by a valid\\ngroup leader on the PMU context active lists.\\n\\nA later close of the removed leader uses DETACH_GROUP and can promote the\\nstill-active siblings from this stale group state. The next schedule-in can\\nthen add an already-linked active_list entry again, corrupting the PMU\\ncontext active list.\\n\\nWith DEBUG_LIST enabled, this is caught as a list_add double-add in\\nmerge_sched_in().\\n\\nFix this by detaching group relationships when remove_on_exec removes an\\nevent. This preserves the existing task-exit and revoke behavior, while\\nensuring surviving siblings are ungrouped before the removed event leaves\\nthe context.(CVE-2026-64556)\n\nIn the Linux kernel, a use-after-free (UAF) vulnerability exists caused by a non-leader exec() race condition in posix-cpu-timers. When sys_timer_delete() observes the old leader, while de_thread() executes switch_leader() and releases the old leader, a race condition occurs. Specifically, posix_cpu_timer_del() in sys_timer_delete() obtains the old leader via pid_task(), while de_thread() is executing release_task(old_leader) and setting old_leader-\u0026gt;sighand = NULL. When lock_task_sighand() returns NULL, sys_timer_delete() frees the posix timer object. However, if the timer was armed and enqueued in p-\u0026gt;signal (a TGID targeted timer is inherited on exec()), run_posix_cpu_timers() or other timerqueue add/delete operations will access the freed object\u0026apos;s timerqueue node, resulting in a use-after-free. This issue similarly affects posix_cpu_timer_set() and posix_cpu_timer_rearm(). The history of this vulnerability goes back to the early days of posix CPU timers implementation.(CVE-2026-64560)\n\nIn the Linux kernel, the following vulnerability has been resolved:\\n\\nKVM: x86: Check for invalid/obsolete root *after* making MMU pages available\\n\\nCheck for a \\\u0026quot;stale\\\u0026quot; page fault, i.e. for an invalid and/or obsolete root, after making MMU pages available for the shadow MMU. If reclaiming shadow pages zaps an in-use root, i.e. marks it invalid, then KVM will attempt to map memory into an invalid root. On its own, populating an invalid root is \\\u0026quot;fine\\\u0026quot;, but because child shadow pages inherit their parent\u0026apos;s role, any children created during the map/fetch will be created as invalid pages, thus violating KVM\u0026apos;s invariant that invalid pages are never on the list of active MMU pages.\\n\\nNote, the underlying flaw has existed since KVM first started tracking invalid roots in 2008 (commit 2e53d63acba7, \\\u0026quot;KVM: MMU: ignore zapped root pagetables\\\u0026quot;), but the true badness only came along in 2020 (Linux 5.9) with the invariant that invalid shadow pages can\u0026apos;t be on the list of active pages.\\n\\nNote #2, inheriting role.invalid when creating child shadow pages is also far from ideal; that flaw will be addressed separately.(CVE-2026-64561)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix double-free in SMB2_close() replay\n\nA response-bearing attempt can return a replayable error and free its\nresponse buffer. If SMB2_close_init() fails before the next send, cleanup\nretains the previous buffer type and frees that response again.\n\nReset response bookkeeping before each attempt to prevent the stale free.(CVE-2026-64597)\n\nIn the Linux kernel, the following vulnerability has been resolved: ipvs: reload ip header after head reallocation. __ip_vs_get_out_rt() calls skb_ensure_writable() which may reallocate skb-\u0026gt;head, causing the previously obtained IP header pointer to become a dangling pointer, leading to a use-after-free vulnerability.(CVE-2026-68476)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipvs: fix more places with wrong ipv6 transport offsets\n\nSashiko reports for more incorrect IPv6 transport offsets.\n\nThe app code for TCP was assuming IPv4 network header\neven after the ipvsh argument was provided. This can\ncause problems with apps over IPv6. As for the only\nofficial app in the kernel tree (FTP) this problem is\nharmless because we use Netfilter to mangle the FTP\nports and we do not adjust the TCP seq numbers.\n\nAlso, provide correct offset of the ICMPV6 header in\nip_vs_out_icmp_v6() for correct checksum checks when\nthe IPv6 packet has extension headers.(CVE-2026-68477)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipvs: use parsed transport offset in SCTP state lookup\n\nset_sctp_state() reads the SCTP chunk header again in order to drive the\nIPVS SCTP state table. For IPv6 it computes the offset with\nsizeof(struct ipv6hdr), while the surrounding IPVS code uses iph.len from\nip_vs_fill_iph_skb(), where ipv6_find_hdr() has already skipped\nextension headers and found the real transport header.\n\nThis makes the state machine read from the wrong offset for IPv6 SCTP\npackets that carry extension headers. For example, an INIT packet with an\n8-byte destination options header can be scheduled correctly by\nsctp_conn_schedule(), but set_sctp_state() reads the first byte of the\nSCTP verification tag as a DATA chunk type. The connection then moves\nfrom NONE to ESTABLISHED instead of INIT1, gets the longer established\ntimeout, and updates the active/inactive destination counters\nincorrectly. This happens even though the SCTP handshake has not\ncompleted.\n\nUse the parsed transport offset passed down from ip_vs_set_state() for\nthe SCTP chunk-header lookup. For IPv4 and IPv6 packets without\nextension headers this preserves the existing offset.(CVE-2026-72021)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nieee802154: admin-gate legacy LLSEC dump operations\n\nIn net/ieee802154/netlink.c, the legacy IEEE802154_NL family ops table\nbuilds the LLSEC dump entries (LLSEC_LIST_KEY, LLSEC_LIST_DEV,\nLLSEC_LIST_DEVKEY, LLSEC_LIST_SECLEVEL) with IEEE802154_DUMP() which\nsets no .flags, so generic netlink runs them ungated. The modern\nnl802154 family admin-gates the equivalent reads via\nNL802154_CMD_GET_SEC_KEY and friends with .flags = GENL_ADMIN_PERM.\n\nAny local uid that can open AF_NETLINK / NETLINK_GENERIC can resolve\nthe \u0026quot;802.15.4 MAC\u0026quot; family and dump LLSEC_LIST_KEY on any wpan netdev\nthat has an LLSEC key installed; the dump handler writes the raw\n16-byte AES-128 key bytes (IEEE802154_ATTR_LLSEC_KEY_BYTES, copied\nverbatim from struct ieee802154_llsec_key.key) into the reply.\nRecovering the AES key compromises 802.15.4 LLSEC link confidentiality\nand authenticity, since LLSEC uses CCM* and the same key authenticates\nand encrypts frames.\n\nImpact: any local uid with no capabilities can read the raw 16-byte\nAES-128 LLSEC key from the kernel keytable on any wpan netdev that has\nan administrator-installed LLSEC key, by issuing an LLSEC_LIST_KEY\ndump on the legacy IEEE802154_NL generic-netlink family.\n\nIntroduce IEEE802154_DUMP_PRIV() mirroring IEEE802154_DUMP() but\nsetting .flags = GENL_ADMIN_PERM, and use it for the four LLSEC dump\nentries. LIST_PHY and LIST_IFACE retain IEEE802154_DUMP() because the\nmodern nl802154 family exposes their equivalents to unprivileged\nreaders by design (NL802154_CMD_GET_WPAN_PHY and\nNL802154_CMD_GET_INTERFACE carry \u0026quot;can be retrieved by unprivileged\nusers\u0026quot; annotations).(CVE-2026-72049)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: ip6_gre: require CAP_NET_ADMIN in the device netns for changelink\n\nip6gre_changelink() and ip6erspan_changelink() operate on at most two\nnetns, dev_net(dev) and the tunnel link netns t-\u0026gt;net. They differ once\nthe device is created in or moved to a netns other than the one the\nrequest runs in. The rtnl changelink path checks CAP_NET_ADMIN only\nagainst dev_net(dev), so a caller privileged there but not in t-\u0026gt;net can\nrewrite a tunnel that lives in t-\u0026gt;net.\n\nGate both ops on rtnl_dev_link_net_capable() at their top, before any\nattribute is parsed.(CVE-2026-72052)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: ipip: require CAP_NET_ADMIN in the device netns for changelink\n\nipip_changelink() operates on at most two netns, dev_net(dev) and the\ntunnel link netns t-\u0026gt;net. They differ once the device is created in or\nmoved to a netns other than the one the request runs in. The rtnl\nchangelink path checks CAP_NET_ADMIN only against dev_net(dev), so a\ncaller privileged there but not in t-\u0026gt;net can rewrite a tunnel that\nlives in t-\u0026gt;net.\n\nGate ipip_changelink() on rtnl_dev_link_net_capable() at its top,\nbefore any attribute is parsed.(CVE-2026-72053)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: ip_vti: require CAP_NET_ADMIN in the device netns for changelink\n\nvti_changelink() operates on at most two netns, dev_net(dev) and the\ntunnel link netns t-\u0026gt;net. They differ once the device is created in or\nmoved to a netns other than the one the request runs in. The rtnl\nchangelink path checks CAP_NET_ADMIN only against dev_net(dev), so a\ncaller privileged there but not in t-\u0026gt;net can rewrite a tunnel that\nlives in t-\u0026gt;net.\n\nGate vti_changelink() on rtnl_dev_link_net_capable() at its top,\nbefore any attribute is parsed.(CVE-2026-72054)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: sit: require CAP_NET_ADMIN in the device netns for changelink\n\nipip6_changelink() operates on at most two netns, dev_net(dev) and the\ntunnel link netns t-\u0026gt;net. They differ once the device is created in or\nmoved to a netns other than the one the request runs in. The rtnl\nchangelink path checks CAP_NET_ADMIN only against dev_net(dev), so a\ncaller privileged there but not in t-\u0026gt;net can rewrite a tunnel that\nlives in t-\u0026gt;net.\n\nGate ipip6_changelink() on rtnl_dev_link_net_capable() at its top,\nbefore any attribute is parsed. sit was the one tunnel type not covered\nby the recent series that added this check to the other changelink()\nhandlers.(CVE-2026-72061)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: macsec: fix use-after-free of metadata_dst on RX SC delete\n\nWhen an offloaded MACsec RX SC is deleted, macsec_del_rxsc_ctx() freed\nthe per-SC metadata_dst with metadata_dst_free(), which kfree()s the\nobject unconditionally and ignores the dst reference count. The RX\ndatapath in mlx5e_macsec_offload_handle_rx_skb() looks up the SC under\nrcu_read_lock() via xa_load(), takes a reference with dst_hold() and\nattaches the dst to the skb with skb_dst_set(). A reader that already\nobtained the rx_sc pointer can race with the delete path and operate on\nfreed memory.\n\nFix the owner side by dropping the reference with dst_release() instead\nof freeing unconditionally, and convert the RX datapath to\ndst_hold_safe() so a reader racing the SC delete cannot attach a dst\nwhose last reference was just dropped; only attach it when a reference\nwas actually taken.\n\nmlx5e_macsec_add_rxsc() also published sc_xarray_element via xa_alloc()\nbefore rx_sc-\u0026gt;md_dst was allocated and initialised, so a datapath reader\nthat looked the SC up by fs_id could observe rx_sc with md_dst still\nNULL or, on weakly-ordered architectures, a non-NULL md_dst pointer\nwhose contents were not yet visible. NULL-check the xa_load() result and\nmd_dst on the datapath, and reorder add_rxsc() so the xa_alloc() publish\nhappens only after md_dst is fully initialised; the xarray RCU publish\nthen pairs with the rcu_read_lock()/xa_load() in the datapath.\n\nNote: macsec_del_rxsc_ctx() also kfree()s rx_sc-\u0026gt;sc_xarray_element\nwithout an RCU grace period while the same datapath reads it under\nrcu_read_lock(); that is a separate pre-existing issue left to a\nfollow-up patch.\n\nFound by 0sec automated security-research tooling (https://0sec.ai).(CVE-2026-72072)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndm-log: fix a bitset_size overflow on 32bit machines\n\nCommit c20e36b7631d (\u0026quot;dm log: fix out-of-bounds write due to\nregion_count overflow\u0026quot;) made sure that region_count could fit in an\nunsigned int. But the bitmap memory isn\u0026apos;t allocated based on\nregion_count. It uses bitset_size (a size_t variable). The first step of\ncalculating bitset_size is to set it to region_count, rounded up to a\nmultiple of BITS_PER_LONG. If region_size is less than BITS_PER_LONG\nsmaller than UINT_MAX, it will get rounded up to 2^32. On a 32bit\narchitecture, this will make bitset_size wrap around to 0 and fail,\ndespite region_count being valid.\n\nSince bitset_size gets divided by 8, it can hold any valid region_count.\nIt just needs a special case to handle the rollover. If it is 0, the\nvalue rolled over, and bitset size should be set to the number of bytes\nneeded to hold 2^32 bits.(CVE-2026-72105)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf,fork: wipe -\u0026gt;bpf_storage before bailouts that access it\n\nCurrently, copy_process() can bail out to free_task() before p-\u0026gt;bpf_storage\nhas been initialized, with this call graph (shown here for the\n!CONFIG_MEMCG case):\n\ncopy_process\n dup_task_struct\n arch_dup_task_struct\n [copies the entire task_struct, including -\u0026gt;bpf_storage member]\n [RLIMIT_NPROC check fails]\n delayed_free_task\n free_task\n bpf_task_storage_free\n rcu_dereference(task-\u0026gt;bpf_storage)\n bpf_local_storage_destroy\n\nIn this case, the nascent task\u0026apos;s -\u0026gt;bpf_storage member that\nbpf_local_storage_destroy() operates on is a plain copy of the parent\u0026apos;s\n-\u0026gt;bpf_storage pointer, not a real initialized pointer.\nThis leads to badness (kernel hangs, UAF).\n\nThis is reachable as long as the process calling fork() has been inserted\ninto a task storage map.(CVE-2026-72110)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvmet-rdma: handle inline data with a nonzero offset\n\nnvmet_rdma_use_inline_sg() maps the host-controlled inline data offset\ninto the per-command inline scatterlist. The bounds check admits any\noffset with off + len \u0026lt;= inline_data_size, but the mapping still assumes\nthe data begins in the first inline page:\n\n\tsg-\u0026gt;offset = off;\n\tsg-\u0026gt;length = min_t(int, len, PAGE_SIZE - off);\n\nWhen a port is configured with inline_data_size \u0026gt; PAGE_SIZE (settable up\nto max(SZ_16K, PAGE_SIZE)), an offset in (PAGE_SIZE, inline_data_size]\nmakes \u0026quot;PAGE_SIZE - off\u0026quot; underflow, so sg-\u0026gt;length is set to ~4 GiB and\nthe block backend reads far past the first inline page. num_pages(len)\nalso ignores the offset, so an in-bounds offset whose [off, off+len)\nspan crosses a page boundary under-counts the scatterlist.\n\nMap the offset properly: split it into a page index and an in-page\noffset, start the scatterlist at that page, and size the page count from\npage_off + len. Because the request scatterlist may now start at\ninline_sg[page_idx] rather than inline_sg[0], generalize the inline-SGL\nidentity test in nvmet_rdma_release_rsp() to a range test; otherwise the\npersistent inline scatterlist is mistaken for an allocated one and\nnvmet_req_free_sgls() frees an inline page (and warns in\nfree_large_kmalloc()).(CVE-2026-72129)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntpm: Make the TPM character devices non-seekable\n\nThe TPM character devices expose a sequential command/response\ninterface, but their open handlers leave FMODE_PREAD and FMODE_PWRITE\nenabled.\n\nAfter a command leaves a response pending, pread(fd, buf, 16, 0x1400)\npasses 0x1400 as *off to tpm_common_read(). The transfer length is\nbounded by response_length, but the offset is used unchecked when\nforming data_buffer + *off. A sufficiently large offset therefore causes\nan out-of-bounds heap read through copy_to_user() and, if the copy\nsucceeds, an out-of-bounds zero-write through the following memset().\n\nPositional I/O does not provide coherent semantics for this interface.\nAn arbitrary pread offset cannot represent how much of a response has\nbeen consumed sequentially. The write callback always stores a command\nat the start of data_buffer, while pwrite() does not update file-\u0026gt;f_pos\nand can leave the sequential read cursor stale.\n\nCall nonseekable_open() from both open handlers. This removes\nFMODE_PREAD and FMODE_PWRITE, causing positional reads and writes to\nfail with -ESPIPE before reaching the TPM callbacks, and explicitly\nmarks the files non-seekable. Normal read() and write() continue to use\nthe existing sequential f_pos cursor, leaving the response state machine\nunchanged.\n\nTested on Linux 6.12 with KASAN and a swtpm TPM2 device:\n\n - sequential partial reads returned the complete response\n - pread() and preadv() with offset 0x1400 returned -ESPIPE\n - pwrite() and pwritev() with offset zero returned -ESPIPE\n - the pending response remained intact after the rejected operations\n - a subsequent normal command/response cycle completed normally\n - no KASAN report was produced.(CVE-2026-72135)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: xfrm_interface: require CAP_NET_ADMIN in the device netns for changelink\n\nxfrmi_changelink() operates on at most two netns, dev_net(dev) and the\ninterface link netns xi-\u0026gt;net. They differ once the device is created in\nor moved to a netns other than the one the request runs in. The rtnl\nchangelink path checks CAP_NET_ADMIN only against dev_net(dev), so a\ncaller privileged there but not in xi-\u0026gt;net can rewrite an interface that\nlives in xi-\u0026gt;net.\n\nGate xfrmi_changelink() on rtnl_dev_link_net_capable() at its top,\nbefore any attribute is parsed.(CVE-2026-72136)\n\nIn the Linux kernel, the following vulnerability has been resolved: net: thunderbolt: Fix frags[] overflow by bounding frame_count. tbnet_poll() assembles a multi-frame ThunderboltIP packet into one skb. The first frame goes into the skb linear area and every further frame is added as a page fragment. A packet of frame_count frames therefore ends up with frame_count - 1 fragments. tbnet_check_frame() only bounds the peer supplied frame_count to TBNET_RING_SIZE / 4 (64), which is far above MAX_SKB_FRAGS (17 by default). A peer that sends a packet of 19 or more small frames pushes nr_frags past MAX_SKB_FRAGS, so skb_add_rx_frag() writes past skb_shinfo()-\u0026gt;frags[] and corrupts memory after the shared info.(CVE-2026-72157)\n\nIn the Linux kernel, the following vulnerability has been resolved: mm/mm_init: fix uninitialized struct pages for ZONE_DEVICE. If DAX memory is hotplugged into an unoccupied subsection of an early section, section_activate() reuses the unoptimized boot memmap. However, compound_nr_pages() still assumes that vmemmap optimization is in effect and initializes only the reduced number of struct pages. As a result, the remaining tail struct pages are left uninitialized, which can later lead to unexpected behavior or crashes. Fix this by treating early sections as unoptimized when calculating how many struct pages to initialize.(CVE-2026-72172)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nSUNRPC: Bound-check xdr_buf_to_bvec() stores before writing\n\nxdr_buf_to_bvec() writes a bio_vec into the caller\u0026apos;s array before\ntesting whether that slot is in range, and the head branch performs\nthe store with no check at all. When the caller\u0026apos;s budget is exactly\nused up, the next store lands one element past the end of the array.\nThe overflow label returns count - 1, which masks the surplus store\nbut cannot undo it.\n\nrq_bvec, the array passed by nfsd_vfs_write(), is allocated to\nexactly rq_maxpages entries with no slack. The OOB store can land in\nadjacent slab memory; the bv_len and bv_offset fields written there\nare derived from client-supplied RPC payload sizes.\n\nMove the in-range check ahead of the store in the head, page-loop,\nand tail branches. With the check at the top of each sequence, count\nis incremented only after a successful store, so the overflow label\ncan return count directly.(CVE-2026-72217)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsunrpc: wait for in-flight TLS handshake callback when cancel loses race\n\nWhen wait_for_completion_interruptible_timeout() in\nsvc_tcp_handshake() returns 0 (timeout) or -ERESTARTSYS (signal) and\ntls_handshake_cancel() then returns false, handshake_complete() has\nwon the cancellation race: it has set HANDSHAKE_F_REQ_COMPLETED and\nis about to invoke svc_tcp_handshake_done(), but the callback\u0026apos;s\nside effects on xpt_flags and on svsk-\u0026gt;sk_handshake_done have not\nyet committed.\n\nThe current code reads xpt_flags immediately to decide whether the\nsession succeeded. Two races result.\n\nIf the callback has executed set_bit(XPT_TLS_SESSION) but not yet\nclear_bit(XPT_HANDSHAKE), svc_tcp_handshake() sees a session,\nenqueues the transport, and returns. svc_xprt_received() then\nclears XPT_BUSY, a worker thread picks the transport up, the\ndispatcher in svc_handle_xprt() observes XPT_HANDSHAKE still set,\nand xpo_handshake is invoked a second time. That svc_tcp_handshake()\ncalls init_completion(\u0026amp;svsk-\u0026gt;sk_handshake_done) while the original\ncallback concurrently calls complete_all() on it, corrupting the\nembedded swait_queue.\n\nIf the callback has set HANDSHAKE_F_REQ_COMPLETED but not yet\nentered svc_tcp_handshake_done(), svc_tcp_handshake() reads\nXPT_TLS_SESSION as clear and tears the connection down even though\nthe handshake is about to succeed.\n\nWait for the callback to commit before inspecting xpt_flags. The\ncompletion is guaranteed to fire because handshake_complete()\ninvokes svc_tcp_handshake_done() unconditionally once it has set\nHANDSHAKE_F_REQ_COMPLETED.(CVE-2026-72221)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsunrpc: pin svc_xprt across the asynchronous TLS handshake callback\n\nsvc_tcp_handshake() stores the raw svc_xprt pointer in\ntls_handshake_args.ta_data and submits the request through\ntls_server_hello_x509(). The handshake core takes only\nsock_hold(req-\u0026gt;hr_sk); nothing references the embedding struct\nsvc_sock that svc_tcp_handshake_done() reaches via container_of().\n\nTwo close races leave the in-flight callback writing through a freed\nsvc_sock. svc_sock_free() calls tls_handshake_cancel() and discards\nits return value: a false return means handshake_complete() has\nalready set HANDSHAKE_F_REQ_COMPLETED but hp_done() may not have\nfinished, yet svc_sock_free() proceeds to kfree(svsk). The\ncancel-loser fall-through inside svc_tcp_handshake() itself produces\nthe same window: when wait_for_completion_interruptible_timeout()\nreturns \u0026lt;= 0 (timeout or signal) and tls_handshake_cancel() returns\nfalse, the function does not drain, returns, and svc_handle_xprt()\ncalls svc_xprt_received(), which clears XPT_BUSY and can drop the\nlast reference. A concurrent close then runs svc_sock_free() while\nsvc_tcp_handshake_done() is still updating xpt_flags and walking\nsvsk-\u0026gt;sk_handshake_done.\n\nThe corruption surfaces as set_bit/clear_bit RMW into the freed\nxpt_flags slab slot and as complete_all() walking and writing the\nfreed wait_queue_head_t list embedded in sk_handshake_done -- a\nslab-corruption primitive, not a benign read. The path is reachable\non any TLS-enabled NFS server whenever a connection close overlaps\nthe tlshd downcall delivery window; the interruptible wait means\nsignal delivery suffices, not just SVC_HANDSHAKE_TO expiry.\n\nTake svc_xprt_get(xprt) immediately before tls_server_hello_x509()\nso the in-flight callback owns its own reference. Release it on the\ntwo edges where the callback is guaranteed not to fire -- submission\nfailure from tls_server_hello_x509() and a successful\ntls_handshake_cancel() -- and at the tail of\nsvc_tcp_handshake_done() after complete_all().\n\n[cel: rewrote commit message to describe the actual change](CVE-2026-72222)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbatman-adv: retrieve ethhdr after potential skb realloc on RX\n\npskb_may_pull() in batadv_interface_rx() could reallocate the buffer behind\nthe skb. Variables which were pointing to the old buffer need to be\nreassigned to avoid an use-after-free.\n\nThis was done correctly for the VLAN header but missed for the ethernet\nheader which is later used for the TT and AP isolation handling.(CVE-2026-72235)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: Move kvm_io_bus_get_dev() locking responsibilities to callers\n\nkvm_io_bus_get_dev() returns a device that is only matched by the\naddress, and nothing else. This can cause a lifetime issue if\nthe matched device is not the expected type, as by the time\nthe caller can introspect the object, it might be gone (the srcu\nlock having been dropped).\n\nGiven that there is only a single user of this helper, the simplest\noption is to move the locking responsibility to the caller, which\ncan keep the srcu lock held for as long as it wants.\n\nNote that this aligns with other kvm_io_bus*() helpers, which\nalready require the srcu lock to be held by the callers.(CVE-2026-72282)\n\nIn the Linux kernel, the following vulnerability has been resolved: smb: client: fix overflow in passthrough ioctl bounds check. smb2_ioctl_query_info() validates the PASSTHRU_FSCTL response payload before copying it to userspace. The payload offset and length both come from 32-bit fields. The bounds check currently adds OutputOffset and qi.input_buffer_length directly, so the addition can wrap in 32-bit arithmetic before the result is compared against the response buffer length. A malicious server can use a large OutputOffset and a small OutputCount to make the wrapped sum pass the bounds check. The later copy_to_user() then reads from io_rsp + OutputOffset, outside the response buffer, leading to an out-of-bounds read.(CVE-2026-72310)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndm era: fix NULL pointer dereference in metadata_open()\n\nmetadata_open() returns NULL when kzalloc_obj() fails, but the\ncaller era_ctr() only checks IS_ERR(md). Since IS_ERR(NULL)\nreturns false, the NULL pointer is treated as a valid result\nand later assigned to era-\u0026gt;md, leading to a NULL pointer\ndereference when the metadata is accessed.\n\nFix this by returning ERR_PTR(-ENOMEM) on allocation failure,\nconsistent with dm-cache-metadata.c, dm-thin-metadata.c, and\ndm-clone-metadata.c which all use ERR_PTR(-ENOMEM) for the\nsame pattern.(CVE-2026-72316)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nSUNRPC: pin upper rpc_clnt across the TLS connect_worker\n\nThe TLS connect path has a use-after-free: nothing pins the\nupper rpc_clnt across the delayed connect_worker. xs_connect()\nstores task-\u0026gt;tk_client in sock_xprt::clnt as a raw pointer\nand queues the worker; for TLS-secured transports that worker\nis xs_tcp_tls_setup_socket(), which reads several fields out\nof the saved pointer (cl_timeout, cl_program, cl_prog,\ncl_vers, cl_cred, cl_stats) to construct the args for the\ninner handshake rpc_clnt.\n\nThe xprt does not reference the rpc_clnt; the rpc_clnt\nreferences the xprt. xs_destroy() does cancel the\nconnect_worker, but it runs only when the xprt\u0026apos;s refcount\ndrops to zero, which cannot happen until the rpc_clnt\nreleases its cl_xprt reference in rpc_free_client_work().\nWhen a TLS handshake fails fatally (for example, an mTLS\nmount whose client cert does not match the server), the\nconnecting task is woken with -EACCES and exits, the mount\ncaller invokes rpc_shutdown_client(), and the upper rpc_clnt\nis freed before the queued connect_worker fires.\nxs_tcp_tls_setup_socket() then dereferences the freed clnt,\nproducing the refcount_t underflow Michael Nemanov reported.\n\nTake a reference on the upper rpc_clnt in xs_connect() for\nTLS transports via a new rpc_hold_client() helper, and drop\nit in the connect_worker\u0026apos;s exit path with rpc_release_client().\nThe xprt_lock_connect() / xprt_unlock_connect() pairing\nalready serialises xs_connect() with xs_tcp_tls_setup_socket(),\nso the take and release are balanced one-for-one.\n\nThe non-TLS connect worker (xs_tcp_setup_socket) never reads\nsock_xprt::clnt, so leave that path alone and avoid the\nclnt-holds-xprt-holds-clnt cycle that would otherwise prevent\nxprt destruction.(CVE-2026-72317)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncifs: validate DFS referral string offsets\n\nparse_dfs_referrals() validates that the response header and referral\narray fit in the received buffer, but each referral also contains string\noffsets supplied by the server.\n\nThose offsets are used to compute the DfsPath and NetworkAddress string\npointers without checking whether they still point inside the response\nbuffer. A malformed referral can therefore make the computed pointer\nexceed the end of the buffer. The resulting negative max_len is then\npassed to cifs_strndup_from_utf16(), and the non-Unicode path forwards it\nto kstrndup() as a size_t, allowing strnlen() to read out of bounds.\n\nValidate each string offset before deriving the string pointer.(CVE-2026-72318)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipvs: ensure inner headers in ICMP errors are in headroom\n\nSashiko points out that after stripping the outer headers\nwith pskb_pull() we should ensure the inner IP headers\nin ICMP errors from tunnels are present in the skb headroom\nfor functions like ipv4_update_pmtu(), icmp_send() and\nIP_VS_DBG().\n\nAlso, add more checks for the length of the inner headers.(CVE-2026-72319)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/tls: Consume empty data records in tls_sw_read_sock()\n\nA peer may send a zero-length TLS application_data record; TLS 1.3\nexplicitly permits these as a traffic-analysis countermeasure (RFC\n8446, Section 5.1). After decryption such a record has full_len ==\n0. tls_sw_read_sock() hands it to the read_actor, which has no\npayload to consume and returns zero. The loop treats a zero return\nas backpressure (used \u0026lt;= 0), requeues the skb at the head of\nrx_list, and stops. rx_list is serviced head-first on the next\ncall, so the empty record is dequeued, fails the same way, and is\nrequeued again; every later record on the connection is blocked\nbehind it.\n\ntls_sw_recvmsg() does not stall on this: a zero-length data record\ncopies nothing and falls through to consume_skb(). Mirror that in\nthe read_sock() path by recognizing an empty data record before\nthe actor runs, consuming it, and continuing.(CVE-2026-72330)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nqede: fix off-by-one in BD ring consumption on build_skb failure\n\nqede_rx_build_skb() and qede_tpa_rx_build_skb() do not check for a\nNULL return from qede_build_skb(). When it returns NULL under memory\npressure, the functions still consume a BD from the ring before\nreturning NULL. The callers then recycle additional BDs, resulting in\none extra BD being consumed (off-by-one). This desynchronizes the BD\nring, which can corrupt DMA page reference counts and lead to SLUB\nfreelist corruption.\n\nCommit 4e910dbe3650 (\u0026quot;qede: confirm skb is allocated before using\u0026quot;)\nadded a NULL check inside qede_build_skb() to prevent a NULL pointer\ndereference, but did not address the missing NULL checks in the\ncallers, making this off-by-one reachable.\n\nFix this by adding NULL checks for the return value of\nqede_build_skb() in both qede_rx_build_skb() and\nqede_tpa_rx_build_skb(), returning NULL immediately before any BD ring\nmanipulation.(CVE-2026-72339)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Fix HV VHCA stats agent registration race\n\nmlx5e_hv_vhca_stats_create() registers the stats agent through\nmlx5_hv_vhca_agent_create(). The helper publishes the agent in\nhv_vhca-\u0026gt;agents[type] under agents_lock and immediately schedules an\nasynchronous control invalidation on the HV VHCA workqueue before\nreturning to mlx5e.\n\nThe asynchronous invalidation invokes the control agent\u0026apos;s invalidate\ncallback, which reads the hypervisor control block and forwards the\ncommand to mlx5e_hv_vhca_stats_control(). That callback may either:\n\n - call cancel_delayed_work_sync(\u0026amp;priv-\u0026gt;stats_agent.work), or\n - call queue_delayed_work(priv-\u0026gt;wq, \u0026amp;sagent-\u0026gt;work, sagent-\u0026gt;delay).\n\nHowever, the delayed_work and priv-\u0026gt;stats_agent.agent are only\ninitialized after mlx5_hv_vhca_agent_create() returns to mlx5e:\n\n agent = mlx5_hv_vhca_agent_create(...); /* publish + invalidate */\n ...\n priv-\u0026gt;stats_agent.agent = agent; /* too late */\n INIT_DELAYED_WORK(\u0026amp;priv-\u0026gt;stats_agent.work, ...); /* too late */\n\nIf the asynchronous control path runs before the two assignments\nabove, it can:\n\n - Operate on an uninitialized delayed_work whose timer.function is\n NULL. queue_delayed_work() calls add_timer() unconditionally, so\n when the timer expires the timer softirq invokes a NULL function\n pointer.\n - Re-initialize the timer later through INIT_DELAYED_WORK() while\n the timer is already enqueued in the timer wheel, corrupting the\n hlist (entry.pprev cleared while the previous bucket node still\n points at this entry).\n - When the worker eventually runs, mlx5e_hv_vhca_stats_work() reads\n sagent-\u0026gt;agent (NULL) and dereferences it inside\n mlx5_hv_vhca_agent_write().\n\nFix this by:\n\n - Initializing priv-\u0026gt;stats_agent.work before invoking\n mlx5_hv_vhca_agent_create(), so the work is always in a valid\n state when the control callback observes it.\n - Adding a struct mlx5_hv_vhca_agent **ctx_update out-parameter\n to mlx5_hv_vhca_agent_create(). The helper writes the agent\n pointer to *ctx_update before publishing into hv_vhca-\u0026gt;agents[]\n and triggering the agents_update flow, so any callback\n subsequently invoked from that flow already sees a valid\n priv-\u0026gt;stats_agent.agent. This avoids having the control\n callback participate in agent initialization.\n\nWhile at it, access priv-\u0026gt;stats_agent.agent with\nREAD_ONCE()/WRITE_ONCE() for the cross-CPU access with the worker, and\nclear priv-\u0026gt;stats_agent.buf on the agent_create() failure path.(CVE-2026-72342)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nseg6: validate SRH length before reading fixed fields\n\nseg6_validate_srh() reads fixed SRH fields such as srh-\u0026gt;type and\nsrh-\u0026gt;hdrlen before checking that the supplied length covers the fixed\nstruct ipv6_sr_hdr fields.\n\nThe BPF SEG6 encap path reaches this with a BPF program-supplied pointer\nand length: bpf_lwt_push_encap() and the SEG6 local BPF END_B6 and\nEND_B6_ENCAP actions call bpf_push_seg6_encap(), which forwards the\nlength to seg6_validate_srh() with no minimum-size guard. A 2-byte SEG6\nencap header can therefore make the validator read srh-\u0026gt;type at offset 2\nbeyond the caller-supplied buffer.\n\nReject lengths shorter than the fixed SRH at the top of\nseg6_validate_srh(), before any field is read. This fixes the BPF helper\npath and keeps the common validator robust.(CVE-2026-72400)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nice: fix FDIR CTRL VSI resource leak in ice_reset_all_vfs()\n\nResetting all VFs causes resource leak on VFs with FDIR filters\nenabled as CTRL VSIs are only invalidated and not freed. Fix by using\nice_vf_ctrl_vsi_release() instead of ice_vf_ctrl_invalidate_vsi() which\naligns behavior with the ice_reset_vf() function.\n\nReproduction:\n echo 1 \u0026gt; /sys/class/net/$pf/device/sriov_numvfs\n ethtool -N $vf flow-type ether proto 0x9000 action 0\n echo 1 \u0026gt; /sys/class/net/$pf/device/reset(CVE-2026-72425)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: validate selector family and prefixlen during match\n\nsyzbot reported a shift-out-of-bounds in xfrm_selector_match()\ndue to AF_UNSPEC selector with large prefixlen (e.g. 128) matched\nagainst IPv4 flow (when XFRM_STATE_AF_UNSPEC is set).\n\nFix this by:\n\n- Rejecting mismatched families in xfrm_selector_match.\n- Returning false in addr4_match if prefixlen \u0026gt; 32.\n- Returning false in addr_match if prefixlen \u0026gt; 128 (prevents overflow).(CVE-2026-72450)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\napparmor: aa_label_alloc use aa_label_free on alloc failure\n\naa_label_alloc() allocates a secid before allocating or taking the label\nproxy. If the later proxy step fails, the error path only freed the label\nmemory, leaking any resources initialized by aa_label_init().\n\nUse aa_label_free() on the failure path so partially initialized labels\nrelease their secid and other label resources before the backing memory is\nfreed.(CVE-2026-72459)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\napparmor: check label build before no_new_privs test\n\naa_change_profile() builds a replacement label with\nfn_label_build_in_scope() before the no_new_privs subset check. The build\nhelper can fail and return NULL or an ERR_PTR, but the result was passed\nto aa_label_is_unconfined_subset() before the existing IS_ERR_OR_NULL()\ncheck.\n\nReuse the existing target-label build failure handling immediately after\nthe build. This preserves the current audit handling while preventing the\nsubset helper from dereferencing an invalid label.(CVE-2026-72460)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxprtrdma: Repost Receive buffers for malformed replies\n\nrpcrdma_wc_receive() decrements the transport\u0026apos;s Receive count for\nevery completion before it dispatches a successful Receive to\nrpcrdma_reply_handler(). The handler must post a replacement\nReceive WR before returning unless ownership of the rep has moved\nelsewhere, as on the backchannel path.\n\nCommit 2ae50ad68cd7 (\u0026quot;xprtrdma: Close window between waking RPC\nsenders and posting Receives\u0026quot;) moved the Receive refill out of\nrpcrdma_wc_receive(), where it had run ahead of every reply, into\nrpcrdma_reply_handler() so that the responder\u0026apos;s credit grant could\nbe parsed before reposting. The bad-version and short-reply exits\nnever reach that refill: they recycle the rep and return without\ncalling rpcrdma_post_recvs().\n\nA remote peer can therefore drain the client\u0026apos;s posted Receive\nqueue by sending a sustained stream of replies that are shorter\nthan the fixed transport header or that carry an unrecognized\nRPC/RDMA version. Each such reply consumes one posted Receive\nwithout replacing it. Once the queue empties, the peer\u0026apos;s next\nSend finds no posted Receive and the transport stalls until\nreconnect.\n\nRoute both malformed-reply exits through the shared repost tail\nafter recycling the rep, refilling against buf-\u0026gt;rb_credits, the\nmost recent accepted credit grant. Neither exit updates the\ncongestion window, so RPCs admitted under the previous grant\nremain in flight awaiting replies. A smaller refill target would\nlet a stream of malformed replies ratchet the posted Receive count\ndown to the batch floor while the congestion window still admits\nrb_credits RPCs; a burst of valid replies to those RPCs could then\noverrun the posted Receives, and because the client connects with\nrnr_retry_count of zero, a single RNR NAK terminates the\nconnection. Refilling against rb_credits also restores the target\nthat applied to malformed replies before commit 2ae50ad68cd7\n(\u0026quot;xprtrdma: Close window between waking RPC senders and posting\nReceives\u0026quot;) when rpcrdma_post_recvs() computed it from rb_credits\ninternally. rb_credits is at least one from connection\nestablishment onward, so the repost path always keeps Receives\nposted.(CVE-2026-72464)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxprtrdma: Sanitize the reply credit grant after parsing\n\nThe out_norqst exit in rpcrdma_reply_handler() branches away before\nthe credit clamp, so a reply that matches no pending request reaches\nout_post carrying the raw credit value parsed from the wire.\nrpcrdma_post_recvs() does not bound its @needed argument: the refill\nloop allocates and chains Receive WRs until the count is satisfied or\nallocation fails. A peer that sends a well-formed reply carrying an\nunknown XID and an inflated credit grant therefore drives rep\nallocation and Receive posting past re_max_requests on every such\nreply.\n\nMove the clamp to immediately after the credit field is parsed,\nahead of the first branch that can reach out_post, so every later\nconsumer sees a sanitized value. The cwnd update stays on the\nmatched-request path.(CVE-2026-72465)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxprtrdma: Fix bcall rep leak and unbounded peek\n\nrpcrdma_is_bcall() decodes a reply\u0026apos;s first words to decide whether\nthe frame is a backchannel call. Two issues in that decode path\nlet a short or malformed reply leak the receive buffer and drain\nthe Receive queue.\n\nFirst, the speculative peek\n\n p = xdr_inline_decode(xdr, 0);\n /* five p++ reads follow */\n\nasks xdr_inline_decode() for zero bytes, which returns xdr-\u0026gt;p\nwithout consulting xdr-\u0026gt;end. The five subsequent __be32 reads can\nthen walk up to 20 bytes past the wire payload into stale regbuf\ncontents and misclassify the reply as a backchannel call.\n\nSecond, after the post-peek\n\n p = xdr_inline_decode(xdr, 3 * sizeof(*p));\n if (unlikely(!p))\n return true;\n\nthe short-header arm returns true without calling\nrpcrdma_bc_receive_call(). The contract with the caller is that a\ntrue return transfers ownership of rep to the backchannel path:\n\n rpcrdma_reply_handler()\n if (rpcrdma_is_bcall(r_xprt, rep))\n return; /* bare return, skips out_post */\n ...\n out_post:\n rpcrdma_post_recvs(r_xprt, credits + ...);\n\nBecause rpcrdma_bc_receive_call() never ran, no one took rep, but\nrpcrdma_reply_handler still bare-returns past rpcrdma_rep_put()\nand rpcrdma_post_recvs(). The rep, with its persistently\nDMA-mapped receive buffer, is orphaned on rb_all_reps and freed\nonly at transport teardown. This completion reposts nothing, so\nits slot is reclaimed only when a later forward-channel reply\nreaches out_post and rpcrdma_post_recvs() allocates a fresh rep to\nbackfill; absent that traffic the Receive queue drains and the\npeer\u0026apos;s Sends draw RNR NAKs.\n\nFix by consulting xdr-\u0026gt;end after the zero-length peek so the five\n__be32 reads cannot run unless 20 bytes of wire payload remain. A\nbyte-precise comparison against xdr-\u0026gt;end is required because a\nnon-4-aligned receive rounds the stream\u0026apos;s word count up past the\ntrue payload. Also return false from the short-header arm so the\nreply falls through the normal out_norqst cleanup chain\n(rpcrdma_rep_put() plus rpcrdma_post_recvs()).(CVE-2026-72466)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxprtrdma: Decouple req recycling from RPC completion\n\nrl_kref formerly served two distinct lifetimes through a single\nrefcount: it gated when a Reply could wake its RPC task, and it\ngated when an rpcrdma_req could return to its free pool. The\nmarshal path took the Send-side reference only when SGEs needed\nDMA-unmap (sc_unmap_count \u0026gt; 0), which made a Send carrying only\npre-registered buffers an exception: the Reply handler dropped\nrl_kref from 1 to 0 and freed the req while the HCA might still\nbe DMA-reading from its send buffer.\n\nGive rl_kref a narrower job. The RPC layer takes one reference\nwhen slot allocation hands a req out. rpcrdma_prepare_send_sges()\ntakes a Send-side reference unconditionally after WR preparation\nsucceeds. xprt_rdma_free_slot() and xprt_rdma_bc_free_rqst() drop\nthe RPC-layer reference; rpcrdma_sendctx_unmap() drops the\nSend-side reference. The req returns to its free pool only after\nboth owners have signed off.\n\nThe existing kref_init(\u0026amp;req-\u0026gt;rl_kref) call in\nrpcrdma_prepare_send_sges() is removed. Initialization moves to\nthe slot-allocation paths (xprt_rdma_alloc_slot and\nrpcrdma_bc_rqst_get), and the release callback re-arms rl_kref\nbefore the req returns to a free pool. A re-init in the marshal\npath would discard the RPC-layer reference that already exists\non entry.\n\nThree invariants follow:\n\n - Any rpcrdma_req held by an rpc_rqst has rl_kref \u0026gt;= 1.\n xprt_rdma_alloc_slot(), rpcrdma_bc_rqst_get(), and the\n backlog-wake branch in xprt_rdma_alloc_slot() each kref_init\n rl_kref before publishing the req. Without this invariant,\n an RPC task that aborts between slot allocation and marshal\n (gss_refresh failure or signal during call_connect, for\n example) would drive xprt_release() -\u0026gt;\n xprt_rdma_free_slot() -\u0026gt; kref_put against a refcount of\n zero, saturating refcount_t and stranding the slot.\n\n - The Send-side reference is taken only after WR prep\n succeeds. A mapping failure in rpcrdma_prepare_send_sges()\n runs rpcrdma_sendctx_cancel(), which DMA-unmaps the sendctx\n and clears sc_req without touching rl_kref. The sendctx\n ring walks in rpcrdma_sendctx_put_locked() and\n rpcrdma_sendctxs_destroy() skip entries with sc_req == NULL,\n so a burst of -EIO marshal failures cannot hold reqs off\n rb_send_bufs.\n\n - The release callback re-arms rl_kref so the next consumer\n enters with the invariant satisfied.\n\nReplies now complete the RPC directly. rpcrdma_reply_handler()\ncalls rpcrdma_complete_rqst() in place of kref_put on the\nnon-LocalInv branch. The LocalInv branch already completes the\nRPC from frwr_unmap_async() and is unaffected.\n\nBecause Send-side references can now outlive RPC completion,\nconnection teardown drains sendctx entries whose unsignaled\nSends never had a later signaled completion to walk the ring.\nrpcrdma_sendctxs_destroy() walks the active range and runs\nrpcrdma_sendctx_unmap() on each entry with a non-NULL sc_req\nbefore the request buffers are reset, and is moved ahead of\nrpcrdma_reqs_reset() in rpcrdma_xprt_disconnect() so the reqs\nare still in their pre-reset state when the Send-side refs are\nreleased.\n\nThe drain creates a teardown-ordering hazard on the backchannel\npath. With the new lifetime, releasing a bc_prealloc req from\nrpcrdma_req_release() re-adds it to bc_pa_list. The disconnect\nin xprt_rdma_destroy() runs after xprt_destroy_backchannel() has\nalready emptied bc_pa_list, so the drained reqs would otherwise\nleak. xprt_rdma_destroy() now runs xprt_rdma_bc_destroy(xprt, 0)\na second time after the disconnect to reclaim them.(CVE-2026-72473)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs/ntfs3: add bounds check to run_get_highest_vcn()\n\nrun_get_highest_vcn() parses a packed NTFS mapping-pairs buffer without\nany length bound, relying solely on a 0x00 terminator to stop. A\ncrafted $LogFile UpdateMappingPairs record whose embedded attribute\ncontains mapping-pairs runs without a terminator causes the function to\nread past the slab allocation, triggering a KASAN slab-out-of-bounds\nread on mount.\n\nThe sibling function run_unpack() received an analogous bounds-check in\ncommit b62567bca474 (\u0026quot;ntfs3: add buffer boundary checks to run_unpack()\u0026quot;),\nbut run_get_highest_vcn() was missed.\n\nTake a run_buf_size parameter and reject any run header whose payload\nwould extend past the buffer end, mirroring the pattern used by\nrun_unpack(). The caller in fslog.c passes the remaining attribute\nbytes after the mapping-pairs offset.\n\nKASAN report (on mainline v7.1 merge window HEAD):\n\n BUG: KASAN: slab-out-of-bounds in run_get_highest_vcn+0x3c0/0x410\n Read of size 1 at addr ffff88800e2d5400 by task mount/72\n Call Trace:\n run_get_highest_vcn+0x3c0/0x410\n do_action.isra.0+0x3ba8/0x7b50\n log_replay+0x9ddd/0x10200\n ntfs_loadlog_and_replay+0x4ad/0x610\n ntfs_fill_super+0x214a/0x4540(CVE-2026-72478)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Guard __get_user acesss with access_ok for uprobe_multi data\n\nAs reported by sashiko [1] we need to use access_ok to check the user\nspace data bounds before we use __get-user to get it.\n\n[1] https://lore.kernel.org/bpf/(CVE-2026-74258)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npower: supply: core: fix supplied_from allocations\n\nIf dts property power-supplies has multiple values, then accessing to\npsy-\u0026gt;supplied_from[i-1] in __power_supply_populate_supplied_from will\noverrun supplied_from array.(CVE-2026-74271)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntipc: require net admin for TIPCv2 netlink mutators\n\nTIPCv2 registers mutating generic-netlink operations without admin\npermission flags. Generic netlink only checks CAP_NET_ADMIN when an\noperation sets GENL_ADMIN_PERM or GENL_UNS_ADMIN_PERM, so a local\nunprivileged process can currently change TIPC state through commands\nsuch as TIPC_NL_NET_SET, TIPC_NL_KEY_SET, TIPC_NL_KEY_FLUSH, and\nbearer enable/disable.\n\nThe legacy TIPC netlink API already checks netlink_net_capable(...,\nCAP_NET_ADMIN) for administrative commands. Give the TIPCv2 mutators\nthe equivalent generic-netlink gate. Use GENL_UNS_ADMIN_PERM, which\nmaps to the same namespace-aware CAP_NET_ADMIN check that\nnetlink_net_capable() performs, so the behaviour matches the legacy\npath and keeps working for CAP_NET_ADMIN holders in a non-initial user\nnamespace (containers).\n\nA QEMU/KASAN repro run as uid/gid 65534 with zero effective\ncapabilities previously succeeded in changing the network id and node\nidentity, setting and flushing key material, and enabling/disabling a\nUDP bearer. With this patch applied the same operations fail with\n-EPERM.(CVE-2026-74283)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsctp: validate embedded address parameter length\n\nsctp_verify_asconf() and sctp_verify_param() only validate ADD_IP, DEL_IP,\nand SET_PRIMARY parameters against a fixed minimum size of sizeof(struct\nsctp_addip_param) + sizeof(struct sctp_paramhdr). This ensures the outer\nparameter is large enough to contain an embedded address parameter header,\nbut does not verify that the embedded address parameter\u0026apos;s declared length\nfits within the bounds of the outer parameter.\n\nLater, sctp_process_param() and sctp_process_asconf_param() extract the\nembedded address parameter and pass it to af-\u0026gt;from_addr_param(), which uses\nthe address parameter length to parse the variable-length address payload.\nA malformed peer can therefore advertise an embedded address parameter\nlength that exceeds the remaining bytes in the enclosing parameter.\n\nValidate that addr_param-\u0026gt;p.length does not exceed the space available\nafter the sctp_addip_param header before processing the embedded address\nparameter. Reject malformed parameters when the embedded address length\nextends beyond the enclosing parameter bounds.\n\nThis prevents out-of-bounds reads when parsing malformed parameters carried\nin INIT or ASCONF processing paths.(CVE-2026-74287)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Tighten cgroup storage cookie checks for prog arrays\n\nThe fix in commit abad3d0bad72 (\u0026quot;bpf: Fix oob access in cgroup local\nstorage\u0026quot;) is still incomplete. The prog-array compatibility check\ntreats a program with no cgroup storage as compatible with any stored\nstorage cookie. This allows a storage-less program to bridge a tail\ncall chain between an entry program and a storage-using callee even\nthough cgroup local storage at runtime still follows the caller\u0026apos;s\ncontext, that is, A -\u0026gt; B(no storage) -\u0026gt; C(storage) path.\n\nRequiring exact cookie equality would break the legitimate case of a\nstorage-less leaf program being tail called from a storage-using one.\nInstead, only accept a zero storage cookie if the program cannot\nperform tail calls itself. This keeps A -\u0026gt; B(no storage) working\nwhile rejecting the A -\u0026gt; B(no storage) -\u0026gt; C(storage) bridge.(CVE-2026-74305)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Reject sleepable BPF_LSM_CGROUP programs at load time\n\nThe cgroup shim runs under rcu_read_lock_dont_migrate(), so we should\nnot attach any sleepable BPF programs there. Add support to the verifier\nto explicitly reject attempts to load sleepable BPF programs destined\nfor LSM cgroup attachment.\n\nWithout this, we get the following splat from a BPF_LSM_CGROUP\nprogram marked BPF_F_SLEEPABLE attached to file_open when it calls\nbpf_get_dentry_xattr():\n\n BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:1567\n in_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 34317, name: load\n preempt_count: 0, expected: 0\n RCU nest depth: 2, expected: 0\n Call Trace:\n down_read+0x76/0x480\n ext4_xattr_get+0x11f/0x700\n __vfs_getxattr+0xf0/0x150\n bpf_get_dentry_xattr+0xbb/0xf0\n bpf_prog_e76a298dac9218c6_test_open+0x6a/0x85\n __cgroup_bpf_run_lsm_current+0x326/0x840\n bpf_trampoline_6442534646+0x62/0x14d\n security_file_open+0x34/0x60\n do_dentry_open+0x340/0x1260\n vfs_open+0x7a/0x440\n path_openat+0x1bac/0x30a0\n\nlibbpf provides a .s named section variant for every sleepable\nprogram type except lsm_cgroup, reflecting that per-cgroup LSM programs\nare intended to only run in a non-sleepable context.\n\nThe above splat was obtained by bypassing libbpf by using bpf(2)\ndirectly.(CVE-2026-74338)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Clear rb node linkage when freeing bpf_rb_root\n\nbpf_rb_root_free() detaches the root by copying the current rb_root_cached\nand then replacing the live root with RB_ROOT_CACHED. It then walks the\ncopied root and drops each object contained in the tree.\n\nThis leaves the rb node state intact while dropping the object. If the\nobject is refcounted and survives the drop, its bpf_rb_node_kern still\ncontains an owner pointer to the freed root and stale rb tree linkage. If\na later bpf_rb_root allocation reuses the same address, bpf_rbtree_remove()\ncan incorrectly pass the owner check and call rb_erase_cached() on a node\nwhose rb pointers belong to the old tree.\n\nMirror the list draining behavior by marking nodes as busy while the root\nis being detached, then clear the rb node and release the owner before\ndropping the containing object. This makes surviving nodes unowned and\nsafe to reject from remove or accept for a later add.(CVE-2026-74344)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: fix UAF by restoring RCU-delayed inode freeing in bpffs\n\ncommit 4f375ade6aa9 (\u0026quot;bpf: Avoid RCU context warning when unpinning\nhtab with internal structs\u0026quot;) moved inode cleanup from -\u0026gt;free_inode()\ninto -\u0026gt;destroy_inode() to avoid sleeping in RCU context when calling\nbpf_any_put(). However this removed the RCU delay on freeing the\ninode itself and the cached symlink body (i_link), both of which\ncan be accessed by RCU pathwalk (pick_link, may_lookup etc.).\n\nThis causes a use-after-free when a concurrent unlinkat() drops the\nlast inode reference and destroy_inode() frees the inode immediately,\nwhile another task is still walking the path in RCU mode and reads\ninode-\u0026gt;i_opflags (offset +2) inside current_time() -\u0026gt; is_mgtime().\n\nKASAN reports:\n BUG: KASAN: slab-use-after-free in is_mgtime include/linux/fs.h:2313\n Read of size 2 at addr ffff8880407e4282 (offset +2 = i_opflags)\n\nThe rules (per Al Viro):\n -\u0026gt;destroy_inode() called immediately, can sleep, use for blocking\n cleanup e.g. bpf_any_put()\n -\u0026gt;free_inode() called after RCU grace period, use for freeing\n inode and anything RCU-accessible e.g. i_link\n\nFix: split the two concerns properly:\n - keep bpf_any_put() in bpf_destroy_inode() since it is blocking\n and needs to run promptly\n - introduce bpf_free_inode() to handle kfree(i_link) and\n free_inode_nonrcu() with proper RCU delay, preventing the UAF(CVE-2026-74363)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/rxe: Copy WQE to local buffer in non-SRQ receive path\n\nFor non-SRQ QPs, the responder reads WQE fields directly from the\nshared queue buffer mapped into userspace. This allows a malicious\nuser to modify fields like num_sge or sge entries while the kernel\nis processing the WQE, leading to out-of-bounds reads in\nrxe_resp_check_length() and copy_data().\n\nIntroduce get_recv_wqe() that validates num_sge and copies the WQE\nto a kernel-local buffer before processing, matching the approach\nalready used for SRQ WQEs in get_srq_wqe(). The srq_wqe buffer is\nreused since SRQ and non-SRQ paths are mutually exclusive per QP.(CVE-2026-74377)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/rxe: Fix TOCTOU heap overflow in get_srq_wqe\n\nget_srq_wqe() reads wqe-\u0026gt;dma.num_sge from the shared receive queue\nbuffer, which is mapped into userspace. It validates num_sge against\nmax_sge, but then re-reads the same field to calculate the memcpy\nsize. A concurrent userspace thread can modify num_sge between\nvalidation and use, causing a heap buffer overflow when copying the\nWQE into qp-\u0026gt;resp.srq_wqe.\n\nRead num_sge into a local variable and use it for both the bounds\ncheck and the size calculation.(CVE-2026-74378)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/srpt: fix integer overflow in immediate data length check\n\nimm_buf-\u0026gt;len is a user-controlled uint32_t received from the network.\nAdding it to imm_data_offset without overflow checking allows a\nmalicious initiator to send len=0xFFFFFFFF, causing req_size to wrap\naround to a small value, bypassing the bounds check, and subsequently\npassing a ~4GB length to sg_init_one().\n\nUse check_add_overflow() to detect wrapping before the comparison.(CVE-2026-74394)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nIB/mlx5: Fix transport-domain rollback and initialize lb mutex earlier\n\nmlx5_ib_alloc_transport_domain() allocates a transport domain and then\nmay fail in mlx5_ib_enable_lb(). In that case, the allocated TD is leaked.\n\nFix this by deallocating the TD when mlx5_ib_enable_lb() returns an\nerror. Also return 0 explicitly in the no-loopback-capability success\nbranch, and move dev-\u0026gt;lb.mutex initialization to mlx5_ib_stage_init_init().(CVE-2026-74397)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: addrconf: bail out of dad_failure when state is no longer POSTDAD\n\naddrconf_dad_failure() transitions ifp-\u0026gt;state from DAD to POSTDAD\nvia addrconf_dad_end(), which drops ifp-\u0026gt;lock on return. The lock\nis re-acquired after net_info_ratelimited(). A concurrent\nipv6_del_addr() can take the lock in that window, set ifp-\u0026gt;state\nto DEAD and run list_del_rcu(\u0026amp;ifp-\u0026gt;if_list).\n\naddrconf_dad_failure() then overwrites DEAD with ERRDAD at errdad:\nand schedules a new dad_work. The work calls ipv6_del_addr()\nagain, hitting the already-poisoned list entry:\n\n general protection fault: 0000 [#1] SMP NOPTI\n CPU: 4 PID: 217 Comm: kworker/4:1\n Workqueue: ipv6_addrconf addrconf_dad_work\n RIP: 0010:ipv6_del_addr+0xe9/0x280\n RAX: dead000000000122\n Call Trace:\n addrconf_dad_stop+0x113/0x140\n addrconf_dad_work+0x28c/0x430\n process_one_work+0x1eb/0x3b0\n worker_thread+0x4d/0x400\n kthread+0x104/0x140\n ret_from_fork+0x35/0x40\n\nFold the addrconf_dad_end() logic into addrconf_dad_failure() under\na single ifp-\u0026gt;lock critical section. The STABLE_PRIVACY branch\ntemporarily drops ifp-\u0026gt;lock around address regeneration, so at\nlock_errdad: verify the state is still POSTDAD before transitioning\nto ERRDAD; bail out otherwise to avoid overwriting a state set by\nanother path while the lock was released.(CVE-2026-74398)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvxlan: Fix potential null-ptr-deref in vxlan_gro_prepare_receive().\n\nudp_tunnel_sock_release() could set sk-\u0026gt;sk_user_data to NULL\nwhile vxlan_gro_prepare_receive() is running.\n\nLet\u0026apos;s check if rcu_dereference_sk_user_data() is NULL after\nskb_gro_remcsum_init().(CVE-2026-74406)",
"id": "OESA-2026-3704",
"modified": "2026-09-05T15:04:08Z",
"published": "2026-09-05T15:04:08Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-3704"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71112"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71123"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23243"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23244"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23253"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23268"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23271"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23317"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23319"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23359"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23383"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23388"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43078"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46028"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-52980"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53055"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53246"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53384"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63800"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63830"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63886"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63887"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63888"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63889"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63891"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63898"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63899"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63901"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63912"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63917"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63919"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63920"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63921"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63924"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63926"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63928"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63944"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63945"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63946"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63952"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63956"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63968"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63971"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63974"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63975"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63976"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63984"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63985"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63992"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63993"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63994"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64002"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64003"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64015"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64025"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64032"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64046"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64047"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64073"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64076"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64077"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64088"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64089"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64095"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64097"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64098"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64106"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64109"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64112"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64113"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64114"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64118"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64126"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64136"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64191"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64219"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64222"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64237"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64247"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64298"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64299"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64304"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64305"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64306"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64312"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64313"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64317"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64319"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64320"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64322"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64323"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64324"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64355"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64364"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64374"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64378"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64379"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64380"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64382"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64383"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64384"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64385"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64386"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64448"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64456"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64481"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64496"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64531"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64556"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64560"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64561"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64597"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-68476"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-68477"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72021"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72049"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72052"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72053"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72054"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72061"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72072"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72105"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72110"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72129"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72135"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72136"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72157"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72172"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72217"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72221"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72222"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72235"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72282"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72310"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72316"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72317"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72318"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72319"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72330"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72339"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72342"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72400"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72425"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72450"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72459"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72460"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72464"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72465"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72466"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72473"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72478"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74258"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74271"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74283"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74287"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74305"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74338"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74344"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74363"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74377"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74378"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74394"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74397"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74398"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74406"
}
],
"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-2025-71112",
"CVE-2025-71123",
"CVE-2026-23243",
"CVE-2026-23244",
"CVE-2026-23253",
"CVE-2026-23268",
"CVE-2026-23271",
"CVE-2026-23317",
"CVE-2026-23319",
"CVE-2026-23359",
"CVE-2026-23383",
"CVE-2026-23388",
"CVE-2026-43078",
"CVE-2026-46028",
"CVE-2026-52980",
"CVE-2026-53055",
"CVE-2026-53246",
"CVE-2026-53384",
"CVE-2026-63800",
"CVE-2026-63830",
"CVE-2026-63886",
"CVE-2026-63887",
"CVE-2026-63888",
"CVE-2026-63889",
"CVE-2026-63891",
"CVE-2026-63898",
"CVE-2026-63899",
"CVE-2026-63901",
"CVE-2026-63912",
"CVE-2026-63917",
"CVE-2026-63919",
"CVE-2026-63920",
"CVE-2026-63921",
"CVE-2026-63924",
"CVE-2026-63926",
"CVE-2026-63928",
"CVE-2026-63944",
"CVE-2026-63945",
"CVE-2026-63946",
"CVE-2026-63952",
"CVE-2026-63956",
"CVE-2026-63968",
"CVE-2026-63971",
"CVE-2026-63974",
"CVE-2026-63975",
"CVE-2026-63976",
"CVE-2026-63984",
"CVE-2026-63985",
"CVE-2026-63992",
"CVE-2026-63993",
"CVE-2026-63994",
"CVE-2026-64002",
"CVE-2026-64003",
"CVE-2026-64015",
"CVE-2026-64025",
"CVE-2026-64032",
"CVE-2026-64046",
"CVE-2026-64047",
"CVE-2026-64073",
"CVE-2026-64076",
"CVE-2026-64077",
"CVE-2026-64088",
"CVE-2026-64089",
"CVE-2026-64095",
"CVE-2026-64097",
"CVE-2026-64098",
"CVE-2026-64106",
"CVE-2026-64109",
"CVE-2026-64112",
"CVE-2026-64113",
"CVE-2026-64114",
"CVE-2026-64118",
"CVE-2026-64126",
"CVE-2026-64136",
"CVE-2026-64191",
"CVE-2026-64219",
"CVE-2026-64222",
"CVE-2026-64237",
"CVE-2026-64247",
"CVE-2026-64298",
"CVE-2026-64299",
"CVE-2026-64304",
"CVE-2026-64305",
"CVE-2026-64306",
"CVE-2026-64312",
"CVE-2026-64313",
"CVE-2026-64317",
"CVE-2026-64319",
"CVE-2026-64320",
"CVE-2026-64322",
"CVE-2026-64323",
"CVE-2026-64324",
"CVE-2026-64355",
"CVE-2026-64364",
"CVE-2026-64374",
"CVE-2026-64378",
"CVE-2026-64379",
"CVE-2026-64380",
"CVE-2026-64382",
"CVE-2026-64383",
"CVE-2026-64384",
"CVE-2026-64385",
"CVE-2026-64386",
"CVE-2026-64448",
"CVE-2026-64456",
"CVE-2026-64481",
"CVE-2026-64496",
"CVE-2026-64531",
"CVE-2026-64556",
"CVE-2026-64560",
"CVE-2026-64561",
"CVE-2026-64597",
"CVE-2026-68476",
"CVE-2026-68477",
"CVE-2026-72021",
"CVE-2026-72049",
"CVE-2026-72052",
"CVE-2026-72053",
"CVE-2026-72054",
"CVE-2026-72061",
"CVE-2026-72072",
"CVE-2026-72105",
"CVE-2026-72110",
"CVE-2026-72129",
"CVE-2026-72135",
"CVE-2026-72136",
"CVE-2026-72157",
"CVE-2026-72172",
"CVE-2026-72217",
"CVE-2026-72221",
"CVE-2026-72222",
"CVE-2026-72235",
"CVE-2026-72282",
"CVE-2026-72310",
"CVE-2026-72316",
"CVE-2026-72317",
"CVE-2026-72318",
"CVE-2026-72319",
"CVE-2026-72330",
"CVE-2026-72339",
"CVE-2026-72342",
"CVE-2026-72400",
"CVE-2026-72425",
"CVE-2026-72450",
"CVE-2026-72459",
"CVE-2026-72460",
"CVE-2026-72464",
"CVE-2026-72465",
"CVE-2026-72466",
"CVE-2026-72473",
"CVE-2026-72478",
"CVE-2026-74258",
"CVE-2026-74271",
"CVE-2026-74283",
"CVE-2026-74287",
"CVE-2026-74305",
"CVE-2026-74338",
"CVE-2026-74344",
"CVE-2026-74363",
"CVE-2026-74377",
"CVE-2026-74378",
"CVE-2026-74394",
"CVE-2026-74397",
"CVE-2026-74398",
"CVE-2026-74406"
]
}
OPENSUSE-SU-2026:10954-1
Vulnerability from csaf_opensuse - Published: 2026-06-04 00:00 - Updated: 2026-09-17 17:08SUSE-SU-2026:22521-1
Vulnerability from csaf_suse - Published: 2026-07-06 13:11 - Updated: 2026-09-19 15:41Sightings
| 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.