Action not permitted
Modal body text goes here.
Modal Title
Modal Body
CVE-2026-46178 (GCVE-0-2026-46178)
Vulnerability from cvelistv5 – Published: 2026-05-28 09:36 – Updated: 2026-08-05 12:30| Vendor | Product | Version | CPE status | |
|---|---|---|---|---|
| Linux | Linux |
Affected:
225c7b1feef1b41170f7037a5b10a65cd8a42c54 , < 53fd4c03558672ccb167754fbacbf045c7ab335c
(git)
Affected: 225c7b1feef1b41170f7037a5b10a65cd8a42c54 , < 0be6ae614ca7fa53e7389e3c7462ed20abbd4192 (git) Affected: 225c7b1feef1b41170f7037a5b10a65cd8a42c54 , < 5b3b220d54e6a3d77380cb7caa1ef79cb8f4fc94 (git) Affected: 225c7b1feef1b41170f7037a5b10a65cd8a42c54 , < c5dc30da990045105c9762248d23076223e7878a (git) Affected: 225c7b1feef1b41170f7037a5b10a65cd8a42c54 , < 0dbd619716fb07b7de1acd64fec673ee6e1adde7 (git) Affected: 225c7b1feef1b41170f7037a5b10a65cd8a42c54 , < e01b8c9286c470b71a38acd320106f2c4f2826a1 (git) Affected: 225c7b1feef1b41170f7037a5b10a65cd8a42c54 , < 388617f44d81604a760742a0b5de292d411e63e3 (git) Affected: 225c7b1feef1b41170f7037a5b10a65cd8a42c54 , < c54c7e4cb679c0aaa1cb489b9c3f2cd98e63a44c (git) |
guessed | |
| Linux | Linux |
Affected:
2.6.22
Unaffected: 0 , < 2.6.22 (semver) Unaffected: 5.10.258 , ≤ 5.10.* (semver) Unaffected: 5.15.209 , ≤ 5.15.* (semver) Unaffected: 6.1.175 , ≤ 6.1.* (semver) Unaffected: 6.6.140 , ≤ 6.6.* (semver) Unaffected: 6.12.88 , ≤ 6.12.* (semver) Unaffected: 6.18.30 , ≤ 6.18.* (semver) Unaffected: 7.0.7 , ≤ 7.0.* (semver) Unaffected: 7.1 , ≤ * (original_commit_for_fix) |
guessed |
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/infiniband/hw/mlx4/srq.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "53fd4c03558672ccb167754fbacbf045c7ab335c",
"status": "affected",
"version": "225c7b1feef1b41170f7037a5b10a65cd8a42c54",
"versionType": "git"
},
{
"lessThan": "0be6ae614ca7fa53e7389e3c7462ed20abbd4192",
"status": "affected",
"version": "225c7b1feef1b41170f7037a5b10a65cd8a42c54",
"versionType": "git"
},
{
"lessThan": "5b3b220d54e6a3d77380cb7caa1ef79cb8f4fc94",
"status": "affected",
"version": "225c7b1feef1b41170f7037a5b10a65cd8a42c54",
"versionType": "git"
},
{
"lessThan": "c5dc30da990045105c9762248d23076223e7878a",
"status": "affected",
"version": "225c7b1feef1b41170f7037a5b10a65cd8a42c54",
"versionType": "git"
},
{
"lessThan": "0dbd619716fb07b7de1acd64fec673ee6e1adde7",
"status": "affected",
"version": "225c7b1feef1b41170f7037a5b10a65cd8a42c54",
"versionType": "git"
},
{
"lessThan": "e01b8c9286c470b71a38acd320106f2c4f2826a1",
"status": "affected",
"version": "225c7b1feef1b41170f7037a5b10a65cd8a42c54",
"versionType": "git"
},
{
"lessThan": "388617f44d81604a760742a0b5de292d411e63e3",
"status": "affected",
"version": "225c7b1feef1b41170f7037a5b10a65cd8a42c54",
"versionType": "git"
},
{
"lessThan": "c54c7e4cb679c0aaa1cb489b9c3f2cd98e63a44c",
"status": "affected",
"version": "225c7b1feef1b41170f7037a5b10a65cd8a42c54",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/infiniband/hw/mlx4/srq.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "2.6.22"
},
{
"lessThan": "2.6.22",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.258",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.209",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.175",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.140",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.88",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.18.*",
"status": "unaffected",
"version": "6.18.30",
"versionType": "semver"
},
{
"lessThanOrEqual": "7.0.*",
"status": "unaffected",
"version": "7.0.7",
"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.258",
"versionStartIncluding": "2.6.22",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.15.209",
"versionStartIncluding": "2.6.22",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.1.175",
"versionStartIncluding": "2.6.22",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6.140",
"versionStartIncluding": "2.6.22",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.12.88",
"versionStartIncluding": "2.6.22",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.18.30",
"versionStartIncluding": "2.6.22",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "7.0.7",
"versionStartIncluding": "2.6.22",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "7.1",
"versionStartIncluding": "2.6.22",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/mlx4: Fix resource leak on error in mlx4_ib_create_srq()\n\nSashiko points out that mlx4_srq_alloc() was not undone during error\nunwind, add the missing call to mlx4_srq_free()."
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 7.8,
"baseSeverity": "HIGH",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"scenarios": [
{
"lang": "en",
"value": "AV:L - The vulnerable path is reached only through the local RDMA uverbs device interface (/dev/infiniband/uverbsN) via a create-SRQ command with driver udata present; it is not reachable from a network peer.\nAC:L - The attacker reliably forces the failing path by supplying a bad/unmapped response buffer (`copy_to_user` \u2192 -EFAULT), which deterministically creates the dangling radix-tree pointer to freed memory; per UAF guidance this is Low.\nPR:L - Triggering requires only an unprivileged local account with access to the RDMA verbs device, which is commonly exposed to non-root users in HPC/cloud/RDMA-enabled environments; no real root is needed.\nUI:N - The attacker performs the create-SRQ call and supplies the faulting buffer entirely on their own; no victim action is required.\nS:U - The freed object and its corruption stay within the kernel\u0027s own security authority; there is no crossing of a VM/IOMMU/sandbox boundary.\nC:H - The dangling pointer is a use-after-free; reclaiming the freed `mlx4_ib_srq` lets an attacker control its contents and read kernel memory through the event-handler dereference chain.\nI:H - The UAF causes `mlx4_srq_event()` to write to freed memory and call function pointers (`srq-\u003eevent`, `event_handler`) read from freed memory, giving a heap-spray-based control-flow-hijack / arbitrary-write primitive.\nA:H - Dereferencing the freed object reliably crashes the kernel, and repeatedly exercising the bug also exhausts the finite hardware SRQ/ICM resource pool, denying RDMA service."
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-08-05T12:30:16.484Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/53fd4c03558672ccb167754fbacbf045c7ab335c"
},
{
"url": "https://git.kernel.org/stable/c/0be6ae614ca7fa53e7389e3c7462ed20abbd4192"
},
{
"url": "https://git.kernel.org/stable/c/5b3b220d54e6a3d77380cb7caa1ef79cb8f4fc94"
},
{
"url": "https://git.kernel.org/stable/c/c5dc30da990045105c9762248d23076223e7878a"
},
{
"url": "https://git.kernel.org/stable/c/0dbd619716fb07b7de1acd64fec673ee6e1adde7"
},
{
"url": "https://git.kernel.org/stable/c/e01b8c9286c470b71a38acd320106f2c4f2826a1"
},
{
"url": "https://git.kernel.org/stable/c/388617f44d81604a760742a0b5de292d411e63e3"
},
{
"url": "https://git.kernel.org/stable/c/c54c7e4cb679c0aaa1cb489b9c3f2cd98e63a44c"
}
],
"title": "RDMA/mlx4: Fix resource leak on error in mlx4_ib_create_srq()",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2026-46178",
"datePublished": "2026-05-28T09:36:32.222Z",
"dateReserved": "2026-05-13T15:03:33.103Z",
"dateUpdated": "2026-08-05T12:30:16.484Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"epss": {
"cve": "CVE-2026-46178",
"date": "2026-09-30",
"epss": "0.00176",
"percentile": "0.06398"
},
"microsoft_vex": {
"current_release_date": "2026-06-09T14:44:42.000Z",
"cve": "CVE-2026-46178",
"id": "msrc_CVE-2026-46178",
"initial_release_date": "2026-05-02T00:00:00.000Z",
"product_status:fixed": "1",
"product_status:known_affected": "1",
"source": "Microsoft CSAF VEX",
"status": "final",
"title": "RDMA/mlx4: Fix resource leak on error in mlx4_ib_create_srq()",
"url": "https://msrc.microsoft.com/csaf/vex/2026/msrc_cve-2026-46178.json",
"version": "3"
},
"nvd": {
"cve": {
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/infiniband/hw/mlx4/srq.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "53fd4c03558672ccb167754fbacbf045c7ab335c",
"status": "affected",
"version": "225c7b1feef1b41170f7037a5b10a65cd8a42c54",
"versionType": "git"
},
{
"lessThan": "0be6ae614ca7fa53e7389e3c7462ed20abbd4192",
"status": "affected",
"version": "225c7b1feef1b41170f7037a5b10a65cd8a42c54",
"versionType": "git"
},
{
"lessThan": "5b3b220d54e6a3d77380cb7caa1ef79cb8f4fc94",
"status": "affected",
"version": "225c7b1feef1b41170f7037a5b10a65cd8a42c54",
"versionType": "git"
},
{
"lessThan": "c5dc30da990045105c9762248d23076223e7878a",
"status": "affected",
"version": "225c7b1feef1b41170f7037a5b10a65cd8a42c54",
"versionType": "git"
},
{
"lessThan": "0dbd619716fb07b7de1acd64fec673ee6e1adde7",
"status": "affected",
"version": "225c7b1feef1b41170f7037a5b10a65cd8a42c54",
"versionType": "git"
},
{
"lessThan": "e01b8c9286c470b71a38acd320106f2c4f2826a1",
"status": "affected",
"version": "225c7b1feef1b41170f7037a5b10a65cd8a42c54",
"versionType": "git"
},
{
"lessThan": "388617f44d81604a760742a0b5de292d411e63e3",
"status": "affected",
"version": "225c7b1feef1b41170f7037a5b10a65cd8a42c54",
"versionType": "git"
},
{
"lessThan": "c54c7e4cb679c0aaa1cb489b9c3f2cd98e63a44c",
"status": "affected",
"version": "225c7b1feef1b41170f7037a5b10a65cd8a42c54",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/infiniband/hw/mlx4/srq.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "2.6.22"
},
{
"lessThan": "2.6.22",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.258",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.209",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.175",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.140",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.88",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.18.*",
"status": "unaffected",
"version": "6.18.30",
"versionType": "semver"
},
{
"lessThanOrEqual": "7.0.*",
"status": "unaffected",
"version": "7.0.7",
"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": "24DC2C27-0B51-4D9E-BFA5-A6472A386F01",
"versionEndExcluding": "5.10.258",
"versionStartIncluding": "2.6.22",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "919C10A9-7951-4A74-BADD-C135A0A8D8B4",
"versionEndExcluding": "5.15.209",
"versionStartIncluding": "5.11",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "92385813-D91D-480D-83A1-F423D2CBB2BA",
"versionEndExcluding": "6.1.175",
"versionStartIncluding": "5.16",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "A1A92866-F406-43B5-B2D1-CFC274753E9D",
"versionEndExcluding": "6.6.140",
"versionStartIncluding": "6.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "5AFBE0EC-CCDF-4207-AE92-ABF958125CA4",
"versionEndExcluding": "6.12.88",
"versionStartIncluding": "6.7",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "BF39AE08-AE6D-4410-8FBE-76F6BF5BF55B",
"versionEndExcluding": "6.18.30",
"versionStartIncluding": "6.13",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "D0893CA7-9AE6-4DFE-AC75-48967D73AD8E",
"versionEndExcluding": "7.0.7",
"versionStartIncluding": "6.19",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:7.1:rc1:*:*:*:*:*:*",
"matchCriteriaId": "B1EF7059-E670-45F4-B422-54C40FA86390",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:7.1:rc2:*:*:*:*:*:*",
"matchCriteriaId": "0D38F0BF-A728-4133-A358-D44A2F7EE6D6",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/mlx4: Fix resource leak on error in mlx4_ib_create_srq()\n\nSashiko points out that mlx4_srq_alloc() was not undone during error\nunwind, add the missing call to mlx4_srq_free()."
}
],
"id": "CVE-2026-46178",
"lastModified": "2026-06-17T10:53:13.490",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 7.8,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 5.9,
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"type": "Secondary"
}
]
},
"published": "2026-05-28T10:16:33.423",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/0be6ae614ca7fa53e7389e3c7462ed20abbd4192"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/0dbd619716fb07b7de1acd64fec673ee6e1adde7"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/388617f44d81604a760742a0b5de292d411e63e3"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/53fd4c03558672ccb167754fbacbf045c7ab335c"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/5b3b220d54e6a3d77380cb7caa1ef79cb8f4fc94"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/c54c7e4cb679c0aaa1cb489b9c3f2cd98e63a44c"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/c5dc30da990045105c9762248d23076223e7878a"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/e01b8c9286c470b71a38acd320106f2c4f2826a1"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Analyzed",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "CWE-401"
}
],
"source": "nvd@nist.gov",
"type": "Primary"
}
]
}
},
"redhat_vex": {
"aggregate_severity": "Low",
"current_release_date": "2026-07-02T21:32:25+00:00",
"cve": "CVE-2026-46178",
"id": "CVE-2026-46178",
"initial_release_date": "2026-05-28T00:00:00+00:00",
"product_status:known_affected": "198",
"product_status:known_not_affected": "76",
"source": "Red Hat CSAF VEX",
"status": "final",
"title": "kernel: RDMA/mlx4: Fix resource leak on error in mlx4_ib_create_srq()",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-46178.json",
"version": "3"
},
"suse_vex": {
"aggregate_severity": "moderate",
"current_release_date": "2026-09-11T01:11:34Z",
"cve": "CVE-2026-46178",
"id": "CVE-2026-46178",
"initial_release_date": "2026-05-29T01:15:42Z",
"product_status:first_fixed": "2",
"product_status:known_affected": "649",
"product_status:recommended": "277",
"source": "SUSE CSAF VEX",
"status": "interim",
"title": "SUSE CVE CVE-2026-46178",
"url": "https://ftp.suse.com/pub/projects/security/csaf-vex/cve-2026-46178.json",
"version": "19"
}
}
}
CERTFR-2026-AVI-1093
Vulnerability from certfr_avis - Published: 2026-08-28 - Updated: 2026-08-28
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 16.04 ESM",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"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 14.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": 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-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-43198",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43198"
},
{
"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-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-43113",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43113"
},
{
"name": "CVE-2026-31522",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31522"
},
{
"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-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-53049",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53049"
},
{
"name": "CVE-2025-22107",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22107"
},
{
"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-31618",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31618"
},
{
"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-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-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-2025-27558",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-27558"
},
{
"name": "CVE-2026-53061",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53061"
},
{
"name": "CVE-2026-43315",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43315"
},
{
"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-43373",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43373"
},
{
"name": "CVE-2026-53002",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53002"
},
{
"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-31578",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31578"
},
{
"name": "CVE-2026-46082",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46082"
},
{
"name": "CVE-2026-43251",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43251"
},
{
"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-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-2024-56727",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56727"
},
{
"name": "CVE-2026-45852",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45852"
},
{
"name": "CVE-2026-31758",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31758"
},
{
"name": "CVE-2026-23159",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23159"
},
{
"name": "CVE-2026-45856",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45856"
},
{
"name": "CVE-2024-53221",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53221"
},
{
"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-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-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-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-52970",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52970"
},
{
"name": "CVE-2026-52958",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52958"
},
{
"name": "CVE-2023-53629",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53629"
},
{
"name": "CVE-2026-46319",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46319"
},
{
"name": "CVE-2026-31416",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31416"
},
{
"name": "CVE-2026-23069",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23069"
},
{
"name": "CVE-2026-64531",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64531"
},
{
"name": "CVE-2026-31656",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31656"
},
{
"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-46227",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46227"
},
{
"name": "CVE-2025-39764",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39764"
},
{
"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-53040",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53040"
},
{
"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-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-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-46253",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46253"
},
{
"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-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-64221",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64221"
},
{
"name": "CVE-2026-43054",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43054"
},
{
"name": "CVE-2026-46064",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46064"
},
{
"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-2024-27389",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27389"
},
{
"name": "CVE-2026-31473",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31473"
},
{
"name": "CVE-2026-43123",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43123"
},
{
"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-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-23290",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23290"
},
{
"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-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-53291",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53291"
},
{
"name": "CVE-2025-71201",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71201"
},
{
"name": "CVE-2026-52924",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52924"
},
{
"name": "CVE-2026-23303",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23303"
},
{
"name": "CVE-2026-43011",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43011"
},
{
"name": "CVE-2026-43132",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43132"
},
{
"name": "CVE-2026-31396",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31396"
},
{
"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-31680",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31680"
},
{
"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-43465",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43465"
},
{
"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-2025-71189",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71189"
},
{
"name": "CVE-2026-52963",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52963"
},
{
"name": "CVE-2026-46303",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46303"
},
{
"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-23035",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23035"
},
{
"name": "CVE-2025-68307",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68307"
},
{
"name": "CVE-2025-40005",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40005"
},
{
"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-43429",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43429"
},
{
"name": "CVE-2026-53224",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53224"
},
{
"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-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-45835",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45835"
},
{
"name": "CVE-2026-43382",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43382"
},
{
"name": "CVE-2026-22987",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22987"
},
{
"name": "CVE-2026-23439",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23439"
},
{
"name": "CVE-2026-23253",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23253"
},
{
"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-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-23115",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23115"
},
{
"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-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-46195",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46195"
},
{
"name": "CVE-2026-46214",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46214"
},
{
"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-23434",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23434"
},
{
"name": "CVE-2026-23123",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23123"
},
{
"name": "CVE-2026-23137",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23137"
},
{
"name": "CVE-2026-43014",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43014"
},
{
"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-31447",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31447"
},
{
"name": "CVE-2026-45870",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45870"
},
{
"name": "CVE-2026-31431",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31431"
},
{
"name": "CVE-2026-46027",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46027"
},
{
"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-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-43387",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43387"
},
{
"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-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-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-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-43262",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43262"
},
{
"name": "CVE-2026-64220",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64220"
},
{
"name": "CVE-2026-23101",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23101"
},
{
"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-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-45841",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45841"
},
{
"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-43231",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43231"
},
{
"name": "CVE-2026-31668",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31668"
},
{
"name": "CVE-2026-23066",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23066"
},
{
"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-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-46331",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46331"
},
{
"name": "CVE-2026-22989",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22989"
},
{
"name": "CVE-2026-23085",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23085"
},
{
"name": "CVE-2023-52737",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52737"
},
{
"name": "CVE-2025-54505",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-54505"
},
{
"name": "CVE-2026-23150",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23150"
},
{
"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-23130",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23130"
},
{
"name": "CVE-2026-23163",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23163"
},
{
"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-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-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-2024-46715",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46715"
},
{
"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-23166",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23166"
},
{
"name": "CVE-2026-52919",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52919"
},
{
"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-31510",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31510"
},
{
"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-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-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-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-43425",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43425"
},
{
"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-23399",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23399"
},
{
"name": "CVE-2026-23012",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23012"
},
{
"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-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-23401",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23401"
},
{
"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-43268",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43268"
},
{
"name": "CVE-2026-53048",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53048"
},
{
"name": "CVE-2025-71200",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71200"
},
{
"name": "CVE-2026-43426",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43426"
},
{
"name": "CVE-2026-53176",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53176"
},
{
"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-23172",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23172"
},
{
"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-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-46259",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46259"
},
{
"name": "CVE-2026-31588",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31588"
},
{
"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-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-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-2024-47809",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47809"
},
{
"name": "CVE-2026-23204",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23204"
},
{
"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-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-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-45836",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45836"
},
{
"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-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-53021",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53021"
},
{
"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-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-46133",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46133"
},
{
"name": "CVE-2026-31494",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31494"
},
{
"name": "CVE-2026-31565",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31565"
},
{
"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-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-23279",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23279"
},
{
"name": "CVE-2026-22997",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22997"
},
{
"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-53131",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53131"
},
{
"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-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-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-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-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-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-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-64085",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64085"
},
{
"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-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-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-43466",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43466"
},
{
"name": "CVE-2026-43197",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43197"
},
{
"name": "CVE-2026-23296",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23296"
},
{
"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-52984",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52984"
},
{
"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-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-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-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-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-2025-71199",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71199"
},
{
"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-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-31737",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31737"
},
{
"name": "CVE-2025-68358",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68358"
},
{
"name": "CVE-2026-46197",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46197"
},
{
"name": "CVE-2026-46301",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46301"
},
{
"name": "CVE-2026-52914",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52914"
},
{
"name": "CVE-2026-52916",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52916"
},
{
"name": "CVE-2026-53225",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53225"
},
{
"name": "CVE-2026-23006",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23006"
},
{
"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-23013",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23013"
},
{
"name": "CVE-2025-71267",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71267"
},
{
"name": "CVE-2026-64125",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64125"
},
{
"name": "CVE-2026-43043",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43043"
},
{
"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-31705",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31705"
},
{
"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-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-23088",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23088"
},
{
"name": "CVE-2026-64089",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64089"
},
{
"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-2023-45896",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-45896"
},
{
"name": "CVE-2026-23370",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23370"
},
{
"name": "CVE-2026-53112",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53112"
},
{
"name": "CVE-2026-46206",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46206"
},
{
"name": "CVE-2026-23108",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23108"
},
{
"name": "CVE-2025-71180",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71180"
},
{
"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-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-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-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-23023",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23023"
},
{
"name": "CVE-2026-43459",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43459"
},
{
"name": "CVE-2026-31450",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31450"
},
{
"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-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-46062",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46062"
},
{
"name": "CVE-2026-45985",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45985"
},
{
"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-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-46108",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46108"
},
{
"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-31748",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31748"
},
{
"name": "CVE-2026-31699",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31699"
},
{
"name": "CVE-2026-46049",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46049"
},
{
"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-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-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-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-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-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-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-22990",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22990"
},
{
"name": "CVE-2026-23000",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23000"
},
{
"name": "CVE-2025-71186",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71186"
},
{
"name": "CVE-2026-43184",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43184"
},
{
"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-46044",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46044"
},
{
"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-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-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-31627",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31627"
},
{
"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-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-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-22978",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22978"
},
{
"name": "CVE-2026-43185",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43185"
},
{
"name": "CVE-2026-43378",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43378"
},
{
"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-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-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-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-43379",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43379"
},
{
"name": "CVE-2026-64164",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64164"
},
{
"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-46266",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46266"
},
{
"name": "CVE-2026-31521",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31521"
},
{
"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-43357",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43357"
},
{
"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-2025-71237",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71237"
},
{
"name": "CVE-2026-53012",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53012"
},
{
"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-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-23025",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23025"
},
{
"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-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-43427",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43427"
},
{
"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-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-53228",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53228"
},
{
"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-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-46046",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46046"
},
{
"name": "CVE-2025-68256",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68256"
},
{
"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-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-23392",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23392"
},
{
"name": "CVE-2026-45916",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45916"
},
{
"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-22982",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22982"
},
{
"name": "CVE-2026-46290",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46290"
},
{
"name": "CVE-2026-64084",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64084"
},
{
"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-43124",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43124"
},
{
"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-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-31773",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31773"
},
{
"name": "CVE-2026-43134",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43134"
},
{
"name": "CVE-2023-52682",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52682"
},
{
"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-46167",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46167"
},
{
"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-53212",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53212"
},
{
"name": "CVE-2026-43015",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43015"
},
{
"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-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-31636",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31636"
},
{
"name": "CVE-2021-47378",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47378"
},
{
"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-2023-53596",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53596"
},
{
"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-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-23051",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23051"
},
{
"name": "CVE-2026-23428",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23428"
},
{
"name": "CVE-2026-64113",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64113"
},
{
"name": "CVE-2026-31590",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31590"
},
{
"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-22993",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22993"
},
{
"name": "CVE-2026-46274",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46274"
},
{
"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-53247",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53247"
},
{
"name": "CVE-2026-31761",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31761"
},
{
"name": "CVE-2026-31466",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31466"
},
{
"name": "CVE-2026-43313",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43313"
},
{
"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-2025-54518",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-54518"
},
{
"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-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-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-64034",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64034"
},
{
"name": "CVE-2026-45958",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45958"
},
{
"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-23096",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23096"
},
{
"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-43196",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43196"
},
{
"name": "CVE-2026-23044",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23044"
},
{
"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-43287",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43287"
},
{
"name": "CVE-2026-31552",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31552"
},
{
"name": "CVE-2026-64218",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64218"
},
{
"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-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-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-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-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-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-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-23336",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23336"
},
{
"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-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-64219",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64219"
},
{
"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-23105",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23105"
},
{
"name": "CVE-2026-22976",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22976"
},
{
"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-53215",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53215"
},
{
"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-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-23065",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23065"
},
{
"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-22986",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22986"
},
{
"name": "CVE-2026-31489",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31489"
},
{
"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-45964",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45964"
},
{
"name": "CVE-2026-46004",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46004"
},
{
"name": "CVE-2026-43343",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43343"
},
{
"name": "CVE-2026-43289",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43289"
},
{
"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-2025-38006",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38006"
},
{
"name": "CVE-2026-64086",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64086"
},
{
"name": "CVE-2026-43341",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43341"
},
{
"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-53359",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53359"
},
{
"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-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-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-23156",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23156"
},
{
"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-46177",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46177"
},
{
"name": "CVE-2026-43110",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43110"
},
{
"name": "CVE-2025-71163",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71163"
},
{
"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-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-43149",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43149"
},
{
"name": "CVE-2026-53277",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53277"
},
{
"name": "CVE-2026-64587",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64587"
},
{
"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-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-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-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-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-43277",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43277"
},
{
"name": "CVE-2026-43386",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43386"
},
{
"name": "CVE-2026-47333",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47333"
},
{
"name": "CVE-2025-71266",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71266"
},
{
"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-23070",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23070"
},
{
"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-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-22977",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22977"
},
{
"name": "CVE-2026-23145",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23145"
},
{
"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-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-43502",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43502"
},
{
"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-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-23076",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23076"
},
{
"name": "CVE-2026-45994",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45994"
},
{
"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-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-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-31576",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31576"
},
{
"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-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-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-43497",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43497"
},
{
"name": "CVE-2026-43312",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43312"
},
{
"name": "CVE-2026-45924",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45924"
},
{
"name": "CVE-2026-46077",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46077"
},
{
"name": "CVE-2026-45891",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45891"
},
{
"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-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-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-64033",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64033"
},
{
"name": "CVE-2026-23460",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23460"
},
{
"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-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-53246",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53246"
},
{
"name": "CVE-2026-31540",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31540"
},
{
"name": "CVE-2026-45986",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45986"
},
{
"name": "CVE-2026-23395",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23395"
},
{
"name": "CVE-2026-45987",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45987"
},
{
"name": "CVE-2026-31651",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31651"
},
{
"name": "CVE-2026-23110",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23110"
},
{
"name": "CVE-2026-23100",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23100"
},
{
"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-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-43316",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43316"
},
{
"name": "CVE-2026-31624",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31624"
},
{
"name": "CVE-2026-46050",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46050"
},
{
"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-23148",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23148"
},
{
"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-2025-71197",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71197"
},
{
"name": "CVE-2026-53151",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53151"
},
{
"name": "CVE-2026-23031",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23031"
},
{
"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-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-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-53072",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53072"
},
{
"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-53068",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53068"
},
{
"name": "CVE-2026-46304",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46304"
},
{
"name": "CVE-2026-43156",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43156"
},
{
"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-31633",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31633"
},
{
"name": "CVE-2026-43473",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43473"
},
{
"name": "CVE-2026-43230",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43230"
},
{
"name": "CVE-2026-43209",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43209"
},
{
"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-45902",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45902"
},
{
"name": "CVE-2026-23157",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23157"
},
{
"name": "CVE-2026-31464",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31464"
},
{
"name": "CVE-2026-46033",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46033"
},
{
"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-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-31630",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31630"
},
{
"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-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-31508",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31508"
},
{
"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-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-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-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-23093",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23093"
},
{
"name": "CVE-2026-23356",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23356"
},
{
"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-52969",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52969"
},
{
"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-43038",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43038"
},
{
"name": "CVE-2026-53062",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53062"
},
{
"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-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-64088",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64088"
},
{
"name": "CVE-2026-45915",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45915"
},
{
"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-43130",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43130"
},
{
"name": "CVE-2026-31452",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31452"
},
{
"name": "CVE-2026-31501",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31501"
},
{
"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-23398",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23398"
},
{
"name": "CVE-2025-68263",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68263"
},
{
"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-31602",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31602"
},
{
"name": "CVE-2026-31425",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31425"
},
{
"name": "CVE-2026-46238",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46238"
},
{
"name": "CVE-2026-64135",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64135"
},
{
"name": "CVE-2026-46051",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46051"
},
{
"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-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-45839",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45839"
},
{
"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-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-23080",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23080"
},
{
"name": "CVE-2026-46102",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46102"
},
{
"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-45969",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45969"
},
{
"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"
}
],
"initial_release_date": "2026-08-28T00:00:00",
"last_revision_date": "2026-08-28T00:00:00",
"links": [],
"reference": "CERTFR-2026-AVI-1093",
"revisions": [
{
"description": "Version initiale",
"revision_date": "2026-08-28T00:00:00.000000"
}
],
"risks": [
{
"description": "Atteinte \u00e0 l\u0027int\u00e9grit\u00e9 des donn\u00e9es"
},
{
"description": "Non sp\u00e9cifi\u00e9 par l\u0027\u00e9diteur"
},
{
"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-08-27",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8666-3",
"url": "https://ubuntu.com/security/notices/USN-8666-3"
},
{
"published_at": "2026-08-21",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8643-3",
"url": "https://ubuntu.com/security/notices/USN-8643-3"
},
{
"published_at": "2026-08-26",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8659-4",
"url": "https://ubuntu.com/security/notices/USN-8659-4"
},
{
"published_at": "2026-08-27",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu LSN-0121-1",
"url": "https://ubuntu.com/security/notices/LSN-0121-1"
},
{
"published_at": "2026-08-21",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8669-1",
"url": "https://ubuntu.com/security/notices/USN-8669-1"
},
{
"published_at": "2026-08-21",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8667-1",
"url": "https://ubuntu.com/security/notices/USN-8667-1"
},
{
"published_at": "2026-08-25",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8643-4",
"url": "https://ubuntu.com/security/notices/USN-8643-4"
},
{
"published_at": "2026-08-21",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8662-2",
"url": "https://ubuntu.com/security/notices/USN-8662-2"
},
{
"published_at": "2026-08-25",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8666-2",
"url": "https://ubuntu.com/security/notices/USN-8666-2"
},
{
"published_at": "2026-08-25",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8659-3",
"url": "https://ubuntu.com/security/notices/USN-8659-3"
},
{
"published_at": "2026-08-25",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8630-5",
"url": "https://ubuntu.com/security/notices/USN-8630-5"
},
{
"published_at": "2026-08-27",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8658-4",
"url": "https://ubuntu.com/security/notices/USN-8658-4"
},
{
"published_at": "2026-08-21",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8668-1",
"url": "https://ubuntu.com/security/notices/USN-8668-1"
},
{
"published_at": "2026-08-21",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8661-2",
"url": "https://ubuntu.com/security/notices/USN-8661-2"
},
{
"published_at": "2026-08-21",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8659-2",
"url": "https://ubuntu.com/security/notices/USN-8659-2"
},
{
"published_at": "2026-08-21",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8658-2",
"url": "https://ubuntu.com/security/notices/USN-8658-2"
},
{
"published_at": "2026-08-27",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8644-3",
"url": "https://ubuntu.com/security/notices/USN-8644-3"
},
{
"published_at": "2026-08-27",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8643-5",
"url": "https://ubuntu.com/security/notices/USN-8643-5"
},
{
"published_at": "2026-08-27",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8661-3",
"url": "https://ubuntu.com/security/notices/USN-8661-3"
},
{
"published_at": "2026-08-25",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8658-3",
"url": "https://ubuntu.com/security/notices/USN-8658-3"
}
]
}
CERTFR-2026-AVI-1162
Vulnerability from certfr_avis - Published: 2026-09-11 - Updated: 2026-09-11
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, un déni de service à distance 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 16.04 ESM",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"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 14.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-2022-50401",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50401"
},
{
"name": "CVE-2025-54518",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-54518"
},
{
"name": "CVE-2026-43490",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43490"
},
{
"name": "CVE-2026-46174",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46174"
},
{
"name": "CVE-2026-46243",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46243"
},
{
"name": "CVE-2025-10263",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-10263"
},
{
"name": "CVE-2026-31420",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31420"
},
{
"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-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-46181",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46181"
},
{
"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-46331",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46331"
},
{
"name": "CVE-2025-71289",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71289"
},
{
"name": "CVE-2026-23469",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23469"
},
{
"name": "CVE-2026-31486",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31486"
},
{
"name": "CVE-2026-31560",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31560"
},
{
"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-52908",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52908"
},
{
"name": "CVE-2026-52909",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52909"
},
{
"name": "CVE-2026-52910",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52910"
},
{
"name": "CVE-2026-52911",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52911"
},
{
"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-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-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-52924",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52924"
},
{
"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-52930",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52930"
},
{
"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-52942",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52942"
},
{
"name": "CVE-2026-52943",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52943"
},
{
"name": "CVE-2026-52947",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52947"
},
{
"name": "CVE-2026-53080",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53080"
},
{
"name": "CVE-2026-53133",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53133"
},
{
"name": "CVE-2026-53135",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53135"
},
{
"name": "CVE-2026-53143",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53143"
},
{
"name": "CVE-2026-53146",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53146"
},
{
"name": "CVE-2026-53147",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53147"
},
{
"name": "CVE-2026-53148",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53148"
},
{
"name": "CVE-2026-53149",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53149"
},
{
"name": "CVE-2026-53150",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53150"
},
{
"name": "CVE-2026-53154",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53154"
},
{
"name": "CVE-2026-53158",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53158"
},
{
"name": "CVE-2026-53159",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53159"
},
{
"name": "CVE-2026-53160",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53160"
},
{
"name": "CVE-2026-53161",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53161"
},
{
"name": "CVE-2026-53176",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53176"
},
{
"name": "CVE-2026-53177",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53177"
},
{
"name": "CVE-2026-53181",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53181"
},
{
"name": "CVE-2026-53182",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53182"
},
{
"name": "CVE-2026-53183",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53183"
},
{
"name": "CVE-2026-53184",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53184"
},
{
"name": "CVE-2026-53186",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53186"
},
{
"name": "CVE-2026-53194",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53194"
},
{
"name": "CVE-2026-53196",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53196"
},
{
"name": "CVE-2026-53199",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53199"
},
{
"name": "CVE-2026-53207",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53207"
},
{
"name": "CVE-2026-53209",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53209"
},
{
"name": "CVE-2026-53213",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53213"
},
{
"name": "CVE-2026-53214",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53214"
},
{
"name": "CVE-2026-53215",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53215"
},
{
"name": "CVE-2026-53217",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53217"
},
{
"name": "CVE-2026-53218",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53218"
},
{
"name": "CVE-2026-53219",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53219"
},
{
"name": "CVE-2026-53221",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53221"
},
{
"name": "CVE-2026-53225",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53225"
},
{
"name": "CVE-2026-53227",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53227"
},
{
"name": "CVE-2026-53228",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53228"
},
{
"name": "CVE-2026-53230",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53230"
},
{
"name": "CVE-2026-53236",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53236"
},
{
"name": "CVE-2026-53237",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53237"
},
{
"name": "CVE-2026-53238",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53238"
},
{
"name": "CVE-2026-53239",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53239"
},
{
"name": "CVE-2026-53242",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53242"
},
{
"name": "CVE-2026-53245",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53245"
},
{
"name": "CVE-2026-53247",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53247"
},
{
"name": "CVE-2026-53249",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53249"
},
{
"name": "CVE-2026-53252",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53252"
},
{
"name": "CVE-2026-53253",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53253"
},
{
"name": "CVE-2026-53254",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53254"
},
{
"name": "CVE-2026-53255",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53255"
},
{
"name": "CVE-2026-53263",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53263"
},
{
"name": "CVE-2026-53264",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53264"
},
{
"name": "CVE-2026-53265",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53265"
},
{
"name": "CVE-2026-53266",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53266"
},
{
"name": "CVE-2026-53267",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53267"
},
{
"name": "CVE-2026-53268",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53268"
},
{
"name": "CVE-2026-53270",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53270"
},
{
"name": "CVE-2026-53274",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53274"
},
{
"name": "CVE-2026-53275",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53275"
},
{
"name": "CVE-2026-52917",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52917"
},
{
"name": "CVE-2026-52918",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52918"
},
{
"name": "CVE-2026-52929",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52929"
},
{
"name": "CVE-2026-52935",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52935"
},
{
"name": "CVE-2026-52944",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52944"
},
{
"name": "CVE-2026-53137",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53137"
},
{
"name": "CVE-2026-53168",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53168"
},
{
"name": "CVE-2026-53190",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53190"
},
{
"name": "CVE-2026-53195",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53195"
},
{
"name": "CVE-2026-53212",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53212"
},
{
"name": "CVE-2026-43071",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43071"
},
{
"name": "CVE-2026-46290",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46290"
},
{
"name": "CVE-2026-53174",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53174"
},
{
"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-53138",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53138"
},
{
"name": "CVE-2026-53151",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53151"
},
{
"name": "CVE-2026-53157",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53157"
},
{
"name": "CVE-2026-53163",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53163"
},
{
"name": "CVE-2026-53325",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53325"
},
{
"name": "CVE-2026-53361",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53361"
},
{
"name": "CVE-2026-53362",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53362"
},
{
"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-53139",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53139"
},
{
"name": "CVE-2026-53142",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53142"
},
{
"name": "CVE-2026-53167",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53167"
},
{
"name": "CVE-2026-53179",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53179"
},
{
"name": "CVE-2026-53327",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53327"
},
{
"name": "CVE-2026-53341",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53341"
},
{
"name": "CVE-2026-53359",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53359"
},
{
"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-52939",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52939"
},
{
"name": "CVE-2026-52948",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52948"
},
{
"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-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-53131",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53131"
},
{
"name": "CVE-2026-53134",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53134"
},
{
"name": "CVE-2026-53136",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53136"
},
{
"name": "CVE-2026-53189",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53189"
},
{
"name": "CVE-2026-53198",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53198"
},
{
"name": "CVE-2026-53208",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53208"
},
{
"name": "CVE-2026-53216",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53216"
},
{
"name": "CVE-2026-53223",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53223"
},
{
"name": "CVE-2026-53256",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53256"
},
{
"name": "CVE-2026-53269",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53269"
},
{
"name": "CVE-2026-53273",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53273"
},
{
"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-53329",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53329"
},
{
"name": "CVE-2026-53331",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53331"
},
{
"name": "CVE-2026-53337",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53337"
},
{
"name": "CVE-2026-53339",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53339"
},
{
"name": "CVE-2026-53343",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53343"
},
{
"name": "CVE-2026-53349",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53349"
},
{
"name": "CVE-2026-53350",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53350"
},
{
"name": "CVE-2026-53352",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53352"
},
{
"name": "CVE-2026-53354",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53354"
},
{
"name": "CVE-2026-53355",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53355"
},
{
"name": "CVE-2026-53356",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53356"
},
{
"name": "CVE-2026-53357",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53357"
},
{
"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-53347",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53347"
},
{
"name": "CVE-2026-53353",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53353"
},
{
"name": "CVE-2026-53140",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53140"
},
{
"name": "CVE-2026-53144",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53144"
},
{
"name": "CVE-2026-53156",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53156"
},
{
"name": "CVE-2026-53178",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53178"
},
{
"name": "CVE-2026-53192",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53192"
},
{
"name": "CVE-2026-53202",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53202"
},
{
"name": "CVE-2026-53203",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53203"
},
{
"name": "CVE-2026-53224",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53224"
},
{
"name": "CVE-2026-53229",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53229"
},
{
"name": "CVE-2026-53241",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53241"
},
{
"name": "CVE-2026-53246",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53246"
},
{
"name": "CVE-2026-53258",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53258"
},
{
"name": "CVE-2026-53262",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53262"
},
{
"name": "CVE-2026-53272",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53272"
},
{
"name": "CVE-2026-53366",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53366"
},
{
"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-2026-53226",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53226"
},
{
"name": "CVE-2026-53392",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53392"
},
{
"name": "CVE-2026-53399",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53399"
},
{
"name": "CVE-2026-53402",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53402"
},
{
"name": "CVE-2026-63815",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63815"
},
{
"name": "CVE-2026-63816",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63816"
},
{
"name": "CVE-2026-63818",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63818"
},
{
"name": "CVE-2026-64187",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64187"
},
{
"name": "CVE-2026-64189",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64189"
},
{
"name": "CVE-2026-53381",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53381"
},
{
"name": "CVE-2026-53382",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53382"
},
{
"name": "CVE-2026-53383",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53383"
},
{
"name": "CVE-2026-53384",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53384"
},
{
"name": "CVE-2026-53385",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53385"
},
{
"name": "CVE-2026-53388",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53388"
},
{
"name": "CVE-2026-53390",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53390"
},
{
"name": "CVE-2026-53391",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53391"
},
{
"name": "CVE-2026-53397",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53397"
},
{
"name": "CVE-2026-53398",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53398"
},
{
"name": "CVE-2026-53403",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53403"
},
{
"name": "CVE-2026-63794",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63794"
},
{
"name": "CVE-2026-63795",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63795"
},
{
"name": "CVE-2026-63796",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63796"
},
{
"name": "CVE-2026-63798",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63798"
},
{
"name": "CVE-2026-63800",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63800"
},
{
"name": "CVE-2026-63801",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63801"
},
{
"name": "CVE-2026-63803",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63803"
},
{
"name": "CVE-2026-63807",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63807"
},
{
"name": "CVE-2026-63808",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63808"
},
{
"name": "CVE-2026-63809",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63809"
},
{
"name": "CVE-2026-63814",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63814"
},
{
"name": "CVE-2026-63817",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63817"
},
{
"name": "CVE-2026-63822",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63822"
},
{
"name": "CVE-2026-63823",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63823"
},
{
"name": "CVE-2026-63824",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63824"
},
{
"name": "CVE-2026-63827",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63827"
},
{
"name": "CVE-2026-63828",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63828"
},
{
"name": "CVE-2026-63830",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63830"
},
{
"name": "CVE-2026-63831",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63831"
},
{
"name": "CVE-2026-63833",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63833"
},
{
"name": "CVE-2026-63834",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63834"
},
{
"name": "CVE-2026-63835",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63835"
},
{
"name": "CVE-2026-63836",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63836"
},
{
"name": "CVE-2026-64188",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64188"
},
{
"name": "CVE-2026-64191",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64191"
},
{
"name": "CVE-2026-64246",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64246"
},
{
"name": "CVE-2026-64249",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64249"
},
{
"name": "CVE-2026-64254",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64254"
},
{
"name": "CVE-2026-64529",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64529"
},
{
"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-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-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-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-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"
},
{
"name": "CVE-2026-53260",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53260"
},
{
"name": "CVE-2026-64192",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64192"
},
{
"name": "CVE-2026-64206",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64206"
},
{
"name": "CVE-2026-64286",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64286"
},
{
"name": "CVE-2026-64287",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64287"
},
{
"name": "CVE-2026-64307",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64307"
},
{
"name": "CVE-2026-64341",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64341"
},
{
"name": "CVE-2026-64352",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64352"
},
{
"name": "CVE-2026-64361",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64361"
},
{
"name": "CVE-2026-64363",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64363"
},
{
"name": "CVE-2026-64364",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64364"
},
{
"name": "CVE-2026-64369",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64369"
},
{
"name": "CVE-2026-64371",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64371"
},
{
"name": "CVE-2026-64375",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64375"
},
{
"name": "CVE-2026-64390",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64390"
},
{
"name": "CVE-2026-64401",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64401"
},
{
"name": "CVE-2026-64405",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64405"
},
{
"name": "CVE-2026-64413",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64413"
},
{
"name": "CVE-2026-64416",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64416"
},
{
"name": "CVE-2026-64421",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64421"
},
{
"name": "CVE-2026-64428",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64428"
},
{
"name": "CVE-2026-64434",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64434"
},
{
"name": "CVE-2026-64438",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64438"
},
{
"name": "CVE-2026-64441",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64441"
},
{
"name": "CVE-2026-64461",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64461"
},
{
"name": "CVE-2026-64462",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64462"
},
{
"name": "CVE-2026-64472",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64472"
},
{
"name": "CVE-2026-64481",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64481"
},
{
"name": "CVE-2026-64488",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64488"
},
{
"name": "CVE-2026-64493",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64493"
},
{
"name": "CVE-2026-64507",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64507"
},
{
"name": "CVE-2026-64508",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64508"
},
{
"name": "CVE-2026-64509",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64509"
},
{
"name": "CVE-2026-64510",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64510"
},
{
"name": "CVE-2026-64531",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64531"
},
{
"name": "CVE-2026-53332",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53332"
},
{
"name": "CVE-2026-53393",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53393"
},
{
"name": "CVE-2026-53400",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53400"
},
{
"name": "CVE-2026-63806",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63806"
},
{
"name": "CVE-2026-63829",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63829"
},
{
"name": "CVE-2026-64266",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64266"
},
{
"name": "CVE-2026-64268",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64268"
},
{
"name": "CVE-2026-64271",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64271"
},
{
"name": "CVE-2026-64273",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64273"
},
{
"name": "CVE-2026-64274",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64274"
},
{
"name": "CVE-2026-64275",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64275"
},
{
"name": "CVE-2026-64276",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64276"
},
{
"name": "CVE-2026-64277",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64277"
},
{
"name": "CVE-2026-64296",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64296"
},
{
"name": "CVE-2026-64298",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64298"
},
{
"name": "CVE-2026-64299",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64299"
},
{
"name": "CVE-2026-64303",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64303"
},
{
"name": "CVE-2026-64304",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64304"
},
{
"name": "CVE-2026-64306",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64306"
},
{
"name": "CVE-2026-64312",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64312"
},
{
"name": "CVE-2026-64313",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64313"
},
{
"name": "CVE-2026-64315",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64315"
},
{
"name": "CVE-2026-64316",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64316"
},
{
"name": "CVE-2026-64317",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64317"
},
{
"name": "CVE-2026-64318",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64318"
},
{
"name": "CVE-2026-64322",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64322"
},
{
"name": "CVE-2026-64323",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64323"
},
{
"name": "CVE-2026-64324",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64324"
},
{
"name": "CVE-2026-64329",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64329"
},
{
"name": "CVE-2026-64330",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64330"
},
{
"name": "CVE-2026-64331",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64331"
},
{
"name": "CVE-2026-64332",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64332"
},
{
"name": "CVE-2026-64333",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64333"
},
{
"name": "CVE-2026-64334",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64334"
},
{
"name": "CVE-2026-64335",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64335"
},
{
"name": "CVE-2026-64337",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64337"
},
{
"name": "CVE-2026-64338",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64338"
},
{
"name": "CVE-2026-64340",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64340"
},
{
"name": "CVE-2026-64342",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64342"
},
{
"name": "CVE-2026-64343",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64343"
},
{
"name": "CVE-2026-64344",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64344"
},
{
"name": "CVE-2026-64345",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64345"
},
{
"name": "CVE-2026-64347",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64347"
},
{
"name": "CVE-2026-64348",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64348"
},
{
"name": "CVE-2026-64351",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64351"
},
{
"name": "CVE-2026-64359",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64359"
},
{
"name": "CVE-2026-64360",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64360"
},
{
"name": "CVE-2026-64362",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64362"
},
{
"name": "CVE-2026-64370",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64370"
},
{
"name": "CVE-2026-64372",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64372"
},
{
"name": "CVE-2026-64373",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64373"
},
{
"name": "CVE-2026-64374",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64374"
},
{
"name": "CVE-2026-64378",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64378"
},
{
"name": "CVE-2026-64379",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64379"
},
{
"name": "CVE-2026-64380",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64380"
},
{
"name": "CVE-2026-64381",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64381"
},
{
"name": "CVE-2026-64403",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64403"
},
{
"name": "CVE-2026-64406",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64406"
},
{
"name": "CVE-2026-64408",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64408"
},
{
"name": "CVE-2026-64411",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64411"
},
{
"name": "CVE-2026-64412",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64412"
},
{
"name": "CVE-2026-64420",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64420"
},
{
"name": "CVE-2026-64422",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64422"
},
{
"name": "CVE-2026-64423",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64423"
},
{
"name": "CVE-2026-64425",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64425"
},
{
"name": "CVE-2026-64429",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64429"
},
{
"name": "CVE-2026-64435",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64435"
},
{
"name": "CVE-2026-64436",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64436"
},
{
"name": "CVE-2026-64442",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64442"
},
{
"name": "CVE-2026-64445",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64445"
},
{
"name": "CVE-2026-64446",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64446"
},
{
"name": "CVE-2026-64448",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64448"
},
{
"name": "CVE-2026-64450",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64450"
},
{
"name": "CVE-2026-64452",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64452"
},
{
"name": "CVE-2026-64455",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64455"
},
{
"name": "CVE-2026-64456",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64456"
},
{
"name": "CVE-2026-64465",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64465"
},
{
"name": "CVE-2026-64468",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64468"
},
{
"name": "CVE-2026-64469",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64469"
},
{
"name": "CVE-2026-64470",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64470"
},
{
"name": "CVE-2026-64471",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64471"
},
{
"name": "CVE-2026-64475",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64475"
},
{
"name": "CVE-2026-64478",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64478"
},
{
"name": "CVE-2026-64483",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64483"
},
{
"name": "CVE-2026-64484",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64484"
},
{
"name": "CVE-2026-64487",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64487"
},
{
"name": "CVE-2026-64494",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64494"
},
{
"name": "CVE-2026-64495",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64495"
},
{
"name": "CVE-2026-64496",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64496"
},
{
"name": "CVE-2026-64497",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64497"
},
{
"name": "CVE-2026-64500",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64500"
},
{
"name": "CVE-2026-64503",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64503"
},
{
"name": "CVE-2026-64504",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64504"
},
{
"name": "CVE-2026-64505",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64505"
},
{
"name": "CVE-2026-64514",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64514"
},
{
"name": "CVE-2026-63797",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63797"
},
{
"name": "CVE-2026-63810",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63810"
},
{
"name": "CVE-2026-64269",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64269"
},
{
"name": "CVE-2026-64279",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64279"
},
{
"name": "CVE-2026-64297",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64297"
},
{
"name": "CVE-2026-64301",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64301"
},
{
"name": "CVE-2026-64336",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64336"
},
{
"name": "CVE-2026-64346",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64346"
},
{
"name": "CVE-2026-64350",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64350"
},
{
"name": "CVE-2026-64355",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64355"
},
{
"name": "CVE-2026-64365",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64365"
},
{
"name": "CVE-2026-64376",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64376"
},
{
"name": "CVE-2026-64393",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64393"
},
{
"name": "CVE-2026-64394",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64394"
},
{
"name": "CVE-2026-64395",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64395"
},
{
"name": "CVE-2026-64396",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64396"
},
{
"name": "CVE-2026-64397",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64397"
},
{
"name": "CVE-2026-64398",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64398"
},
{
"name": "CVE-2026-64399",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64399"
},
{
"name": "CVE-2026-64409",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64409"
},
{
"name": "CVE-2026-64417",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64417"
},
{
"name": "CVE-2026-64419",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64419"
},
{
"name": "CVE-2026-64430",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64430"
},
{
"name": "CVE-2026-64432",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64432"
},
{
"name": "CVE-2026-64440",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64440"
},
{
"name": "CVE-2026-64443",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64443"
},
{
"name": "CVE-2026-64444",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64444"
},
{
"name": "CVE-2026-64449",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64449"
},
{
"name": "CVE-2026-64454",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64454"
},
{
"name": "CVE-2026-64458",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64458"
},
{
"name": "CVE-2026-64476",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64476"
},
{
"name": "CVE-2026-64480",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64480"
},
{
"name": "CVE-2026-64482",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64482"
},
{
"name": "CVE-2026-64486",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64486"
},
{
"name": "CVE-2026-64489",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64489"
},
{
"name": "CVE-2026-64512",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64512"
},
{
"name": "CVE-2026-64536",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64536"
},
{
"name": "CVE-2026-64600",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64600"
},
{
"name": "CVE-2026-53175",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53175"
},
{
"name": "CVE-2026-64256",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64256"
},
{
"name": "CVE-2026-64265",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64265"
},
{
"name": "CVE-2026-64270",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64270"
},
{
"name": "CVE-2026-64272",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64272"
},
{
"name": "CVE-2026-64284",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64284"
},
{
"name": "CVE-2026-64289",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64289"
},
{
"name": "CVE-2026-64294",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64294"
},
{
"name": "CVE-2026-64305",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64305"
},
{
"name": "CVE-2026-64308",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64308"
},
{
"name": "CVE-2026-64309",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64309"
},
{
"name": "CVE-2026-64310",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64310"
},
{
"name": "CVE-2026-64319",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64319"
},
{
"name": "CVE-2026-64320",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64320"
},
{
"name": "CVE-2026-64321",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64321"
},
{
"name": "CVE-2026-64326",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64326"
},
{
"name": "CVE-2026-64327",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64327"
},
{
"name": "CVE-2026-64328",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64328"
},
{
"name": "CVE-2026-64354",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64354"
},
{
"name": "CVE-2026-64357",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64357"
},
{
"name": "CVE-2026-64358",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64358"
},
{
"name": "CVE-2026-64367",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64367"
},
{
"name": "CVE-2026-64377",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64377"
},
{
"name": "CVE-2026-64382",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64382"
},
{
"name": "CVE-2026-64383",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64383"
},
{
"name": "CVE-2026-64384",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64384"
},
{
"name": "CVE-2026-64385",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64385"
},
{
"name": "CVE-2026-64386",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64386"
},
{
"name": "CVE-2026-64387",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64387"
},
{
"name": "CVE-2026-64391",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64391"
},
{
"name": "CVE-2026-64392",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64392"
},
{
"name": "CVE-2026-64402",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64402"
},
{
"name": "CVE-2026-64404",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64404"
},
{
"name": "CVE-2026-64407",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64407"
},
{
"name": "CVE-2026-64414",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64414"
},
{
"name": "CVE-2026-64415",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64415"
},
{
"name": "CVE-2026-64418",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64418"
},
{
"name": "CVE-2026-64424",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64424"
},
{
"name": "CVE-2026-64433",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64433"
},
{
"name": "CVE-2026-64457",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64457"
},
{
"name": "CVE-2026-64463",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64463"
},
{
"name": "CVE-2026-64473",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64473"
},
{
"name": "CVE-2026-64474",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64474"
},
{
"name": "CVE-2026-64477",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64477"
},
{
"name": "CVE-2026-64479",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64479"
},
{
"name": "CVE-2026-64490",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64490"
},
{
"name": "CVE-2026-64499",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64499"
},
{
"name": "CVE-2026-64511",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64511"
},
{
"name": "CVE-2026-64556",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64556"
},
{
"name": "CVE-2026-64589",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64589"
},
{
"name": "CVE-2026-64590",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64590"
},
{
"name": "CVE-2026-64592",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64592"
},
{
"name": "CVE-2026-64593",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64593"
},
{
"name": "CVE-2026-64594",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64594"
},
{
"name": "CVE-2026-64597",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64597"
},
{
"name": "CVE-2026-64598",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64598"
},
{
"name": "CVE-2026-64599",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64599"
},
{
"name": "CVE-2026-64602",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64602"
},
{
"name": "CVE-2026-64603",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64603"
},
{
"name": "CVE-2026-64604",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64604"
},
{
"name": "CVE-2026-64300",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64300"
},
{
"name": "CVE-2026-64368",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64368"
},
{
"name": "CVE-2026-53250",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53250"
},
{
"name": "CVE-2026-63802",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63802"
},
{
"name": "CVE-2026-63826",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63826"
},
{
"name": "CVE-2026-64205",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64205"
},
{
"name": "CVE-2026-64280",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64280"
},
{
"name": "CVE-2026-64290",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64290"
},
{
"name": "CVE-2026-53132",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53132"
},
{
"name": "CVE-2026-53152",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53152"
},
{
"name": "CVE-2026-53185",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53185"
},
{
"name": "CVE-2026-53191",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53191"
},
{
"name": "CVE-2026-53193",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53193"
},
{
"name": "CVE-2026-53205",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53205"
},
{
"name": "CVE-2026-53210",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53210"
},
{
"name": "CVE-2026-53233",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53233"
},
{
"name": "CVE-2026-53235",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53235"
},
{
"name": "CVE-2026-53251",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53251"
},
{
"name": "CVE-2026-53345",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53345"
},
{
"name": "CVE-2026-53386",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53386"
},
{
"name": "CVE-2026-53387",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53387"
},
{
"name": "CVE-2026-53394",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53394"
},
{
"name": "CVE-2026-63821",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63821"
},
{
"name": "CVE-2026-63869",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63869"
},
{
"name": "CVE-2026-63871",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63871"
},
{
"name": "CVE-2026-68372",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68372"
},
{
"name": "CVE-2026-53153",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53153"
},
{
"name": "CVE-2026-63825",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63825"
},
{
"name": "CVE-2026-64400",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64400"
},
{
"name": "CVE-2026-68084",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68084"
},
{
"name": "CVE-2026-68085",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68085"
},
{
"name": "CVE-2026-68088",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68088"
},
{
"name": "CVE-2026-68090",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68090"
},
{
"name": "CVE-2026-68091",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68091"
},
{
"name": "CVE-2026-68092",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68092"
},
{
"name": "CVE-2026-68459",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68459"
},
{
"name": "CVE-2026-68460",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68460"
},
{
"name": "CVE-2026-68461",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68461"
},
{
"name": "CVE-2026-80591",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-80591"
},
{
"name": "CVE-2026-52938",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52938"
},
{
"name": "CVE-2026-52940",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52940"
},
{
"name": "CVE-2026-53141",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53141"
},
{
"name": "CVE-2026-53145",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53145"
},
{
"name": "CVE-2026-53155",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53155"
},
{
"name": "CVE-2026-53162",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53162"
},
{
"name": "CVE-2026-53164",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53164"
},
{
"name": "CVE-2026-53165",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53165"
},
{
"name": "CVE-2026-53169",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53169"
},
{
"name": "CVE-2026-53170",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53170"
},
{
"name": "CVE-2026-53171",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53171"
},
{
"name": "CVE-2026-53172",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53172"
},
{
"name": "CVE-2026-53173",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53173"
},
{
"name": "CVE-2026-53180",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53180"
},
{
"name": "CVE-2026-53187",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53187"
},
{
"name": "CVE-2026-53188",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53188"
},
{
"name": "CVE-2026-53197",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53197"
},
{
"name": "CVE-2026-53200",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53200"
},
{
"name": "CVE-2026-53201",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53201"
},
{
"name": "CVE-2026-53204",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53204"
},
{
"name": "CVE-2026-53206",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53206"
},
{
"name": "CVE-2026-53211",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53211"
},
{
"name": "CVE-2026-53220",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53220"
},
{
"name": "CVE-2026-53222",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53222"
},
{
"name": "CVE-2026-53231",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53231"
},
{
"name": "CVE-2026-53232",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53232"
},
{
"name": "CVE-2026-53234",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53234"
},
{
"name": "CVE-2026-53240",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53240"
},
{
"name": "CVE-2026-53243",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53243"
},
{
"name": "CVE-2026-53244",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53244"
},
{
"name": "CVE-2026-53248",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53248"
},
{
"name": "CVE-2026-53257",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53257"
},
{
"name": "CVE-2026-53259",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53259"
},
{
"name": "CVE-2026-53261",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53261"
},
{
"name": "CVE-2026-53271",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53271"
},
{
"name": "CVE-2026-53276",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53276"
},
{
"name": "CVE-2026-53326",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53326"
},
{
"name": "CVE-2026-53328",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53328"
},
{
"name": "CVE-2026-53330",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53330"
},
{
"name": "CVE-2026-53333",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53333"
},
{
"name": "CVE-2026-53334",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53334"
},
{
"name": "CVE-2026-53335",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53335"
},
{
"name": "CVE-2026-53336",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53336"
},
{
"name": "CVE-2026-53338",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53338"
},
{
"name": "CVE-2026-53340",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53340"
},
{
"name": "CVE-2026-53342",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53342"
},
{
"name": "CVE-2026-53344",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53344"
},
{
"name": "CVE-2026-53346",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53346"
},
{
"name": "CVE-2026-53348",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53348"
},
{
"name": "CVE-2026-53351",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53351"
},
{
"name": "CVE-2026-53363",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53363"
},
{
"name": "CVE-2026-53389",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53389"
},
{
"name": "CVE-2026-53395",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53395"
},
{
"name": "CVE-2026-53396",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53396"
},
{
"name": "CVE-2026-53401",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53401"
},
{
"name": "CVE-2026-63799",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63799"
},
{
"name": "CVE-2026-63804",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63804"
},
{
"name": "CVE-2026-63805",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63805"
},
{
"name": "CVE-2026-63811",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63811"
},
{
"name": "CVE-2026-63812",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63812"
},
{
"name": "CVE-2026-63813",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63813"
},
{
"name": "CVE-2026-63819",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63819"
},
{
"name": "CVE-2026-63820",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63820"
},
{
"name": "CVE-2026-63832",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63832"
},
{
"name": "CVE-2026-63867",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63867"
},
{
"name": "CVE-2026-63868",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63868"
},
{
"name": "CVE-2026-63870",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63870"
},
{
"name": "CVE-2026-63873",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63873"
},
{
"name": "CVE-2026-63874",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63874"
},
{
"name": "CVE-2026-64092",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64092"
},
{
"name": "CVE-2026-64207",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64207"
},
{
"name": "CVE-2026-64244",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64244"
},
{
"name": "CVE-2026-64245",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64245"
},
{
"name": "CVE-2026-64247",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64247"
},
{
"name": "CVE-2026-64251",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64251"
},
{
"name": "CVE-2026-64253",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64253"
},
{
"name": "CVE-2026-64255",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64255"
},
{
"name": "CVE-2026-64258",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64258"
},
{
"name": "CVE-2026-64259",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64259"
},
{
"name": "CVE-2026-64260",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64260"
},
{
"name": "CVE-2026-64261",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64261"
},
{
"name": "CVE-2026-64262",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64262"
},
{
"name": "CVE-2026-64263",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64263"
},
{
"name": "CVE-2026-64264",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64264"
},
{
"name": "CVE-2026-64267",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64267"
},
{
"name": "CVE-2026-64278",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64278"
},
{
"name": "CVE-2026-64282",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64282"
},
{
"name": "CVE-2026-64283",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64283"
},
{
"name": "CVE-2026-64285",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64285"
},
{
"name": "CVE-2026-64288",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64288"
},
{
"name": "CVE-2026-64291",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64291"
},
{
"name": "CVE-2026-64292",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64292"
},
{
"name": "CVE-2026-64293",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64293"
},
{
"name": "CVE-2026-64295",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64295"
},
{
"name": "CVE-2026-64302",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64302"
},
{
"name": "CVE-2026-64314",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64314"
},
{
"name": "CVE-2026-64325",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64325"
},
{
"name": "CVE-2026-64339",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64339"
},
{
"name": "CVE-2026-64353",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64353"
},
{
"name": "CVE-2026-64356",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64356"
},
{
"name": "CVE-2026-64366",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64366"
},
{
"name": "CVE-2026-64388",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64388"
},
{
"name": "CVE-2026-64389",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64389"
},
{
"name": "CVE-2026-64410",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64410"
},
{
"name": "CVE-2026-64426",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64426"
},
{
"name": "CVE-2026-64439",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64439"
},
{
"name": "CVE-2026-64447",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64447"
},
{
"name": "CVE-2026-64451",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64451"
},
{
"name": "CVE-2026-64453",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64453"
},
{
"name": "CVE-2026-64459",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64459"
},
{
"name": "CVE-2026-64460",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64460"
},
{
"name": "CVE-2026-64464",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64464"
},
{
"name": "CVE-2026-64466",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64466"
},
{
"name": "CVE-2026-64467",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64467"
},
{
"name": "CVE-2026-64485",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64485"
},
{
"name": "CVE-2026-64491",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64491"
},
{
"name": "CVE-2026-64492",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64492"
},
{
"name": "CVE-2026-64501",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64501"
},
{
"name": "CVE-2026-64502",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64502"
},
{
"name": "CVE-2026-64513",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64513"
},
{
"name": "CVE-2026-64588",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64588"
},
{
"name": "CVE-2026-64591",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64591"
},
{
"name": "CVE-2026-64596",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64596"
},
{
"name": "CVE-2026-64601",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64601"
},
{
"name": "CVE-2026-68087",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68087"
},
{
"name": "CVE-2026-68089",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68089"
},
{
"name": "CVE-2026-74584",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-74584"
}
],
"initial_release_date": "2026-09-11T00:00:00",
"last_revision_date": "2026-09-11T00:00:00",
"links": [],
"reference": "CERTFR-2026-AVI-1162",
"revisions": [
{
"description": "Version initiale",
"revision_date": "2026-09-11T00:00:00.000000"
}
],
"risks": [
{
"description": "D\u00e9ni de service \u00e0 distance"
},
{
"description": "Atteinte \u00e0 l\u0027int\u00e9grit\u00e9 des donn\u00e9es"
},
{
"description": "Non sp\u00e9cifi\u00e9 par l\u0027\u00e9diteur"
},
{
"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, un d\u00e9ni de service \u00e0 distance 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-09-04",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8725-1",
"url": "https://ubuntu.com/security/notices/USN-8725-1"
},
{
"published_at": "2026-09-04",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8714-2",
"url": "https://ubuntu.com/security/notices/USN-8714-2"
},
{
"published_at": "2026-09-10",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8748-1",
"url": "https://ubuntu.com/security/notices/USN-8748-1"
},
{
"published_at": "2026-09-07",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8730-1",
"url": "https://ubuntu.com/security/notices/USN-8730-1"
},
{
"published_at": "2026-09-07",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8728-1",
"url": "https://ubuntu.com/security/notices/USN-8728-1"
},
{
"published_at": "2026-09-07",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8727-1",
"url": "https://ubuntu.com/security/notices/USN-8727-1"
},
{
"published_at": "2026-09-07",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8726-1",
"url": "https://ubuntu.com/security/notices/USN-8726-1"
},
{
"published_at": "2026-09-07",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8729-1",
"url": "https://ubuntu.com/security/notices/USN-8729-1"
}
]
}
CERTFR-2026-AVI-1229
Vulnerability from certfr_avis - Published: 2026-09-25 - Updated: 2026-09-25
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, un déni de service à distance et une atteinte à la confidentialité 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 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-2026-64141",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64141"
},
{
"name": "CVE-2026-31623",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31623"
},
{
"name": "CVE-2026-72436",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72436"
},
{
"name": "CVE-2026-43198",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43198"
},
{
"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-64353",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64353"
},
{
"name": "CVE-2026-64214",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64214"
},
{
"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-68459",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68459"
},
{
"name": "CVE-2026-31409",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31409"
},
{
"name": "CVE-2026-64376",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64376"
},
{
"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-53192",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53192"
},
{
"name": "CVE-2026-64590",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64590"
},
{
"name": "CVE-2026-53230",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53230"
},
{
"name": "CVE-2026-53398",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53398"
},
{
"name": "CVE-2026-53349",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53349"
},
{
"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-43068",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43068"
},
{
"name": "CVE-2026-64287",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64287"
},
{
"name": "CVE-2026-53381",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53381"
},
{
"name": "CVE-2026-64270",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64270"
},
{
"name": "CVE-2026-53132",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53132"
},
{
"name": "CVE-2026-64275",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64275"
},
{
"name": "CVE-2026-64274",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64274"
},
{
"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-74394",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-74394"
},
{
"name": "CVE-2026-64485",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64485"
},
{
"name": "CVE-2026-46211",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46211"
},
{
"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-53272",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53272"
},
{
"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-53179",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53179"
},
{
"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-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-2025-22107",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22107"
},
{
"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-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-74439",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-74439"
},
{
"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-64192",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64192"
},
{
"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-53350",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53350"
},
{
"name": "CVE-2026-23368",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23368"
},
{
"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-53116",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53116"
},
{
"name": "CVE-2026-53214",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53214"
},
{
"name": "CVE-2026-52925",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52925"
},
{
"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-2025-27558",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-27558"
},
{
"name": "CVE-2026-64452",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64452"
},
{
"name": "CVE-2026-63943",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63943"
},
{
"name": "CVE-2026-53210",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53210"
},
{
"name": "CVE-2026-52929",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52929"
},
{
"name": "CVE-2026-64492",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64492"
},
{
"name": "CVE-2026-64483",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64483"
},
{
"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-64322",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64322"
},
{
"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-64470",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64470"
},
{
"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-64461",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64461"
},
{
"name": "CVE-2026-43315",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43315"
},
{
"name": "CVE-2026-64501",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64501"
},
{
"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-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-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-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-53274",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53274"
},
{
"name": "CVE-2026-64094",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64094"
},
{
"name": "CVE-2026-53202",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53202"
},
{
"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-64513",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64513"
},
{
"name": "CVE-2026-43251",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43251"
},
{
"name": "CVE-2026-64413",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64413"
},
{
"name": "CVE-2026-63841",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63841"
},
{
"name": "CVE-2026-68088",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68088"
},
{
"name": "CVE-2026-64388",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64388"
},
{
"name": "CVE-2026-53117",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53117"
},
{
"name": "CVE-2026-64512",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64512"
},
{
"name": "CVE-2026-63882",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63882"
},
{
"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-64409",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64409"
},
{
"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-52947",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52947"
},
{
"name": "CVE-2026-53218",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53218"
},
{
"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-45852",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45852"
},
{
"name": "CVE-2026-64367",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64367"
},
{
"name": "CVE-2026-31758",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31758"
},
{
"name": "CVE-2026-64516",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64516"
},
{
"name": "CVE-2026-64077",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64077"
},
{
"name": "CVE-2026-64380",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64380"
},
{
"name": "CVE-2026-64268",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64268"
},
{
"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-53378",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53378"
},
{
"name": "CVE-2026-53169",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53169"
},
{
"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-64099",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64099"
},
{
"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-64489",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64489"
},
{
"name": "CVE-2026-43168",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43168"
},
{
"name": "CVE-2026-64510",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64510"
},
{
"name": "CVE-2026-53143",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53143"
},
{
"name": "CVE-2026-64480",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64480"
},
{
"name": "CVE-2026-64399",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64399"
},
{
"name": "CVE-2026-43060",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43060"
},
{
"name": "CVE-2026-72494",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72494"
},
{
"name": "CVE-2025-71221",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71221"
},
{
"name": "CVE-2026-80665",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-80665"
},
{
"name": "CVE-2026-74376",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-74376"
},
{
"name": "CVE-2026-53161",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53161"
},
{
"name": "CVE-2026-53271",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53271"
},
{
"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-64385",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64385"
},
{
"name": "CVE-2026-53193",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53193"
},
{
"name": "CVE-2026-64405",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64405"
},
{
"name": "CVE-2026-72130",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72130"
},
{
"name": "CVE-2026-53140",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53140"
},
{
"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-64217",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64217"
},
{
"name": "CVE-2026-63818",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63818"
},
{
"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-64414",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64414"
},
{
"name": "CVE-2026-53229",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53229"
},
{
"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-53244",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53244"
},
{
"name": "CVE-2026-43492",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43492"
},
{
"name": "CVE-2026-64502",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64502"
},
{
"name": "CVE-2026-64454",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64454"
},
{
"name": "CVE-2026-31486",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31486"
},
{
"name": "CVE-2026-64531",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64531"
},
{
"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-64308",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64308"
},
{
"name": "CVE-2026-53014",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53014"
},
{
"name": "CVE-2026-64407",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64407"
},
{
"name": "CVE-2026-52999",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52999"
},
{
"name": "CVE-2026-63832",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63832"
},
{
"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-2025-39764",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39764"
},
{
"name": "CVE-2026-64402",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64402"
},
{
"name": "CVE-2026-43241",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43241"
},
{
"name": "CVE-2026-64527",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64527"
},
{
"name": "CVE-2026-63807",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63807"
},
{
"name": "CVE-2026-53040",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53040"
},
{
"name": "CVE-2026-53231",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53231"
},
{
"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-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-53399",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53399"
},
{
"name": "CVE-2026-53400",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53400"
},
{
"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-43339",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43339"
},
{
"name": "CVE-2026-64221",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64221"
},
{
"name": "CVE-2026-53106",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53106"
},
{
"name": "CVE-2026-64365",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64365"
},
{
"name": "CVE-2026-64025",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64025"
},
{
"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-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-53260",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53260"
},
{
"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-64264",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64264"
},
{
"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-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-72320",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72320"
},
{
"name": "CVE-2026-46196",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46196"
},
{
"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-53185",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53185"
},
{
"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-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-53138",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53138"
},
{
"name": "CVE-2026-31550",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31550"
},
{
"name": "CVE-2026-64241",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64241"
},
{
"name": "CVE-2026-63830",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63830"
},
{
"name": "CVE-2026-23220",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23220"
},
{
"name": "CVE-2026-23290",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23290"
},
{
"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-64256",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64256"
},
{
"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-2026-64319",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64319"
},
{
"name": "CVE-2025-38626",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38626"
},
{
"name": "CVE-2026-53391",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53391"
},
{
"name": "CVE-2026-74345",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-74345"
},
{
"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-72083",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72083"
},
{
"name": "CVE-2026-64591",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64591"
},
{
"name": "CVE-2026-64333",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64333"
},
{
"name": "CVE-2026-53141",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53141"
},
{
"name": "CVE-2026-53291",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53291"
},
{
"name": "CVE-2026-52924",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52924"
},
{
"name": "CVE-2026-53227",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53227"
},
{
"name": "CVE-2026-63979",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63979"
},
{
"name": "CVE-2026-64404",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64404"
},
{
"name": "CVE-2026-23303",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23303"
},
{
"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-64467",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64467"
},
{
"name": "CVE-2026-63940",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63940"
},
{
"name": "CVE-2026-53239",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53239"
},
{
"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-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-53342",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53342"
},
{
"name": "CVE-2026-31586",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31586"
},
{
"name": "CVE-2026-53181",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53181"
},
{
"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-2026-64424",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64424"
},
{
"name": "CVE-2026-64389",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64389"
},
{
"name": "CVE-2026-53220",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53220"
},
{
"name": "CVE-2026-46117",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46117"
},
{
"name": "CVE-2026-64246",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64246"
},
{
"name": "CVE-2026-64223",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64223"
},
{
"name": "CVE-2025-71289",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71289"
},
{
"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-64326",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64326"
},
{
"name": "CVE-2026-53373",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53373"
},
{
"name": "CVE-2026-63933",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63933"
},
{
"name": "CVE-2026-68085",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68085"
},
{
"name": "CVE-2026-74401",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-74401"
},
{
"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-46114",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46114"
},
{
"name": "CVE-2026-63870",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63870"
},
{
"name": "CVE-2026-64386",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64386"
},
{
"name": "CVE-2026-43163",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43163"
},
{
"name": "CVE-2026-72319",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72319"
},
{
"name": "CVE-2026-53331",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53331"
},
{
"name": "CVE-2026-31738",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31738"
},
{
"name": "CVE-2026-64460",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64460"
},
{
"name": "CVE-2026-53365",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53365"
},
{
"name": "CVE-2026-64514",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64514"
},
{
"name": "CVE-2026-64082",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64082"
},
{
"name": "CVE-2026-63821",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63821"
},
{
"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-68091",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68091"
},
{
"name": "CVE-2026-64260",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64260"
},
{
"name": "CVE-2026-63805",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63805"
},
{
"name": "CVE-2026-43411",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43411"
},
{
"name": "CVE-2026-64279",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64279"
},
{
"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-53224",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53224"
},
{
"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-64383",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64383"
},
{
"name": "CVE-2026-63847",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63847"
},
{
"name": "CVE-2026-64337",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64337"
},
{
"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-64430",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64430"
},
{
"name": "CVE-2026-53095",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53095"
},
{
"name": "CVE-2026-45835",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45835"
},
{
"name": "CVE-2026-68083",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68083"
},
{
"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-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-64459",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64459"
},
{
"name": "CVE-2026-23253",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23253"
},
{
"name": "CVE-2026-64232",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64232"
},
{
"name": "CVE-2026-52943",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52943"
},
{
"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-64295",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64295"
},
{
"name": "CVE-2026-31617",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31617"
},
{
"name": "CVE-2026-46229",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46229"
},
{
"name": "CVE-2026-68089",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68089"
},
{
"name": "CVE-2026-72466",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72466"
},
{
"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-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-64592",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64592"
},
{
"name": "CVE-2026-64178",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64178"
},
{
"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-64497",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64497"
},
{
"name": "CVE-2026-53163",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53163"
},
{
"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-64258",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64258"
},
{
"name": "CVE-2026-68090",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68090"
},
{
"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-53146",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53146"
},
{
"name": "CVE-2026-63956",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63956"
},
{
"name": "CVE-2026-64599",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64599"
},
{
"name": "CVE-2026-68461",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68461"
},
{
"name": "CVE-2026-64189",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64189"
},
{
"name": "CVE-2026-72339",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72339"
},
{
"name": "CVE-2026-63798",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63798"
},
{
"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-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-64598",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64598"
},
{
"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-64230",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64230"
},
{
"name": "CVE-2026-53345",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53345"
},
{
"name": "CVE-2026-46183",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46183"
},
{
"name": "CVE-2026-53205",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53205"
},
{
"name": "CVE-2026-53321",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53321"
},
{
"name": "CVE-2026-63810",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63810"
},
{
"name": "CVE-2026-64098",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64098"
},
{
"name": "CVE-2026-63801",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63801"
},
{
"name": "CVE-2026-63815",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63815"
},
{
"name": "CVE-2026-63827",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63827"
},
{
"name": "CVE-2026-64304",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64304"
},
{
"name": "CVE-2026-43014",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43014"
},
{
"name": "CVE-2026-64451",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64451"
},
{
"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-74267",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-74267"
},
{
"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-2026-45870",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45870"
},
{
"name": "CVE-2026-46027",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46027"
},
{
"name": "CVE-2026-64226",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64226"
},
{
"name": "CVE-2026-64146",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64146"
},
{
"name": "CVE-2026-53397",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53397"
},
{
"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-68457",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68457"
},
{
"name": "CVE-2026-72366",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72366"
},
{
"name": "CVE-2026-46320",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46320"
},
{
"name": "CVE-2026-53201",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53201"
},
{
"name": "CVE-2026-63910",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63910"
},
{
"name": "CVE-2026-43387",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43387"
},
{
"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-2026-64276",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64276"
},
{
"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-63948",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63948"
},
{
"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-64475",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64475"
},
{
"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-64508",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64508"
},
{
"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-64237",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64237"
},
{
"name": "CVE-2026-64323",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64323"
},
{
"name": "CVE-2026-64438",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64438"
},
{
"name": "CVE-2026-46113",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46113"
},
{
"name": "CVE-2026-64261",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64261"
},
{
"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-43262",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43262"
},
{
"name": "CVE-2026-64220",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64220"
},
{
"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-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-64271",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64271"
},
{
"name": "CVE-2026-46072",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46072"
},
{
"name": "CVE-2026-53150",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53150"
},
{
"name": "CVE-2026-53327",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53327"
},
{
"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-52939",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52939"
},
{
"name": "CVE-2026-64038",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64038"
},
{
"name": "CVE-2026-64107",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64107"
},
{
"name": "CVE-2026-64462",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64462"
},
{
"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-2026-53147",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53147"
},
{
"name": "CVE-2025-38562",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38562"
},
{
"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-64455",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64455"
},
{
"name": "CVE-2026-52942",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52942"
},
{
"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-46331",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46331"
},
{
"name": "CVE-2026-53051",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53051"
},
{
"name": "CVE-2026-46142",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46142"
},
{
"name": "CVE-2026-53015",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53015"
},
{
"name": "CVE-2026-64421",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64421"
},
{
"name": "CVE-2026-64302",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64302"
},
{
"name": "CVE-2023-52737",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52737"
},
{
"name": "CVE-2026-72129",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72129"
},
{
"name": "CVE-2026-72299",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72299"
},
{
"name": "CVE-2026-64445",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64445"
},
{
"name": "CVE-2026-52935",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52935"
},
{
"name": "CVE-2026-64328",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64328"
},
{
"name": "CVE-2026-72417",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72417"
},
{
"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-53200",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53200"
},
{
"name": "CVE-2026-53183",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53183"
},
{
"name": "CVE-2026-64433",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64433"
},
{
"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-64272",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64272"
},
{
"name": "CVE-2026-23469",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23469"
},
{
"name": "CVE-2026-31605",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31605"
},
{
"name": "CVE-2026-72278",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72278"
},
{
"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-52995",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52995"
},
{
"name": "CVE-2026-53257",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53257"
},
{
"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-53113",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53113"
},
{
"name": "CVE-2026-53338",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53338"
},
{
"name": "CVE-2026-64003",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64003"
},
{
"name": "CVE-2026-64253",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64253"
},
{
"name": "CVE-2026-64213",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64213"
},
{
"name": "CVE-2026-46153",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46153"
},
{
"name": "CVE-2026-68476",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68476"
},
{
"name": "CVE-2026-64076",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64076"
},
{
"name": "CVE-2026-68477",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68477"
},
{
"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-64500",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64500"
},
{
"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-63806",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63806"
},
{
"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-64239",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64239"
},
{
"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-72351",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72351"
},
{
"name": "CVE-2026-63816",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63816"
},
{
"name": "CVE-2026-64330",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64330"
},
{
"name": "CVE-2026-53330",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53330"
},
{
"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-72277",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72277"
},
{
"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-64348",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64348"
},
{
"name": "CVE-2026-53383",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53383"
},
{
"name": "CVE-2026-64469",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64469"
},
{
"name": "CVE-2026-53348",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53348"
},
{
"name": "CVE-2026-43458",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43458"
},
{
"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-74361",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-74361"
},
{
"name": "CVE-2026-64310",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64310"
},
{
"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-64280",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64280"
},
{
"name": "CVE-2026-63880",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63880"
},
{
"name": "CVE-2026-64362",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64362"
},
{
"name": "CVE-2026-64327",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64327"
},
{
"name": "CVE-2026-64415",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64415"
},
{
"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-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-64289",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64289"
},
{
"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-64523",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64523"
},
{
"name": "CVE-2026-63800",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63800"
},
{
"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-64255",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64255"
},
{
"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-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-64314",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64314"
},
{
"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-64486",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64486"
},
{
"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-64267",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64267"
},
{
"name": "CVE-2026-23399",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23399"
},
{
"name": "CVE-2026-72220",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72220"
},
{
"name": "CVE-2026-53028",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53028"
},
{
"name": "CVE-2026-90386",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-90386"
},
{
"name": "CVE-2026-53312",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53312"
},
{
"name": "CVE-2026-64517",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64517"
},
{
"name": "CVE-2026-64341",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64341"
},
{
"name": "CVE-2026-46106",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46106"
},
{
"name": "CVE-2026-31420",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31420"
},
{
"name": "CVE-2026-72194",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72194"
},
{
"name": "CVE-2026-63817",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63817"
},
{
"name": "CVE-2026-64446",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64446"
},
{
"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-53339",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53339"
},
{
"name": "CVE-2026-64534",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64534"
},
{
"name": "CVE-2026-53266",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53266"
},
{
"name": "CVE-2026-64338",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64338"
},
{
"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-53234",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53234"
},
{
"name": "CVE-2026-64169",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64169"
},
{
"name": "CVE-2026-53149",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53149"
},
{
"name": "CVE-2026-23401",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23401"
},
{
"name": "CVE-2025-71239",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71239"
},
{
"name": "CVE-2026-63795",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63795"
},
{
"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-64418",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64418"
},
{
"name": "CVE-2026-64249",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64249"
},
{
"name": "CVE-2026-72222",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72222"
},
{
"name": "CVE-2026-64536",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64536"
},
{
"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-63873",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63873"
},
{
"name": "CVE-2026-63932",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63932"
},
{
"name": "CVE-2026-43426",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43426"
},
{
"name": "CVE-2026-53176",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53176"
},
{
"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-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-53172",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53172"
},
{
"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-64010",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64010"
},
{
"name": "CVE-2026-64364",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64364"
},
{
"name": "CVE-2026-63947",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63947"
},
{
"name": "CVE-2026-63950",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63950"
},
{
"name": "CVE-2026-45912",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45912"
},
{
"name": "CVE-2026-64243",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64243"
},
{
"name": "CVE-2026-45911",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45911"
},
{
"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-64008",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64008"
},
{
"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-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-45869",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45869"
},
{
"name": "CVE-2026-63975",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63975"
},
{
"name": "CVE-2026-53233",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53233"
},
{
"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-53402",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53402"
},
{
"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-64351",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64351"
},
{
"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-63835",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63835"
},
{
"name": "CVE-2026-53050",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53050"
},
{
"name": "CVE-2026-64432",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64432"
},
{
"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-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-53386",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53386"
},
{
"name": "CVE-2026-64181",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64181"
},
{
"name": "CVE-2026-64293",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64293"
},
{
"name": "CVE-2026-64039",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64039"
},
{
"name": "CVE-2026-63855",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63855"
},
{
"name": "CVE-2026-68087",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68087"
},
{
"name": "CVE-2026-63833",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63833"
},
{
"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-63796",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63796"
},
{
"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-45862",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45862"
},
{
"name": "CVE-2026-53332",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53332"
},
{
"name": "CVE-2026-64363",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64363"
},
{
"name": "CVE-2026-46174",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46174"
},
{
"name": "CVE-2026-43495",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43495"
},
{
"name": "CVE-2026-53401",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53401"
},
{
"name": "CVE-2026-53334",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53334"
},
{
"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-64263",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64263"
},
{
"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-64061",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64061"
},
{
"name": "CVE-2024-56719",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56719"
},
{
"name": "CVE-2026-53353",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53353"
},
{
"name": "CVE-2026-64375",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64375"
},
{
"name": "CVE-2026-46133",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46133"
},
{
"name": "CVE-2026-31494",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31494"
},
{
"name": "CVE-2026-64296",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64296"
},
{
"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-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-2026-53335",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53335"
},
{
"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-63926",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63926"
},
{
"name": "CVE-2026-64370",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64370"
},
{
"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-53178",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53178"
},
{
"name": "CVE-2026-53389",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53389"
},
{
"name": "CVE-2026-64439",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64439"
},
{
"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-72322",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72322"
},
{
"name": "CVE-2026-31670",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31670"
},
{
"name": "CVE-2026-64593",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64593"
},
{
"name": "CVE-2026-64254",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64254"
},
{
"name": "CVE-2026-64231",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64231"
},
{
"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-53158",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53158"
},
{
"name": "CVE-2026-53131",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53131"
},
{
"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-64210",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64210"
},
{
"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-64299",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64299"
},
{
"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-72422",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72422"
},
{
"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-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-64374",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64374"
},
{
"name": "CVE-2026-46181",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46181"
},
{
"name": "CVE-2026-64357",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64357"
},
{
"name": "CVE-2026-31469",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31469"
},
{
"name": "CVE-2026-64488",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64488"
},
{
"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-45879",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45879"
},
{
"name": "CVE-2026-64603",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64603"
},
{
"name": "CVE-2026-53219",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53219"
},
{
"name": "CVE-2026-45883",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45883"
},
{
"name": "CVE-2026-64109",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64109"
},
{
"name": "CVE-2026-53190",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53190"
},
{
"name": "CVE-2026-64345",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64345"
},
{
"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-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-64368",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64368"
},
{
"name": "CVE-2026-53251",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53251"
},
{
"name": "CVE-2026-64518",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64518"
},
{
"name": "CVE-2026-43104",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43104"
},
{
"name": "CVE-2026-52954",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52954"
},
{
"name": "CVE-2026-53249",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53249"
},
{
"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-53329",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53329"
},
{
"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-53139",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53139"
},
{
"name": "CVE-2026-53382",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53382"
},
{
"name": "CVE-2026-43466",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43466"
},
{
"name": "CVE-2026-64504",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64504"
},
{
"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-52987",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52987"
},
{
"name": "CVE-2026-53217",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53217"
},
{
"name": "CVE-2026-53276",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53276"
},
{
"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-64148",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64148"
},
{
"name": "CVE-2026-53262",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53262"
},
{
"name": "CVE-2026-53346",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53346"
},
{
"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-72495",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72495"
},
{
"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-63813",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63813"
},
{
"name": "CVE-2026-31594",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31594"
},
{
"name": "CVE-2026-64320",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64320"
},
{
"name": "CVE-2026-63992",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63992"
},
{
"name": "CVE-2026-72287",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72287"
},
{
"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-64398",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64398"
},
{
"name": "CVE-2026-64147",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64147"
},
{
"name": "CVE-2026-72084",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72084"
},
{
"name": "CVE-2026-43183",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43183"
},
{
"name": "CVE-2026-64464",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64464"
},
{
"name": "CVE-2026-64297",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64297"
},
{
"name": "CVE-2026-53243",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53243"
},
{
"name": "CVE-2026-72317",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72317"
},
{
"name": "CVE-2026-72137",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72137"
},
{
"name": "CVE-2026-63909",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63909"
},
{
"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-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-63996",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63996"
},
{
"name": "CVE-2026-53079",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53079"
},
{
"name": "CVE-2026-68092",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68092"
},
{
"name": "CVE-2026-31515",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31515"
},
{
"name": "CVE-2026-64343",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64343"
},
{
"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-64473",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64473"
},
{
"name": "CVE-2026-64021",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64021"
},
{
"name": "CVE-2026-64397",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64397"
},
{
"name": "CVE-2026-31737",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31737"
},
{
"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-53361",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53361"
},
{
"name": "CVE-2026-64371",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64371"
},
{
"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-46224",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46224"
},
{
"name": "CVE-2026-64520",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64520"
},
{
"name": "CVE-2026-52914",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52914"
},
{
"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-53236",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53236"
},
{
"name": "CVE-2026-64471",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64471"
},
{
"name": "CVE-2026-53225",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53225"
},
{
"name": "CVE-2026-64180",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64180"
},
{
"name": "CVE-2026-64468",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64468"
},
{
"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-53222",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53222"
},
{
"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-72033",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72033"
},
{
"name": "CVE-2026-53105",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53105"
},
{
"name": "CVE-2026-64449",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64449"
},
{
"name": "CVE-2026-63866",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63866"
},
{
"name": "CVE-2026-64105",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64105"
},
{
"name": "CVE-2026-64602",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64602"
},
{
"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-2026-64551",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64551"
},
{
"name": "CVE-2026-31705",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31705"
},
{
"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-72472",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72472"
},
{
"name": "CVE-2026-53111",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53111"
},
{
"name": "CVE-2026-53362",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53362"
},
{
"name": "CVE-2026-64410",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64410"
},
{
"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-53168",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53168"
},
{
"name": "CVE-2026-23396",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23396"
},
{
"name": "CVE-2026-64212",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64212"
},
{
"name": "CVE-2026-31423",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31423"
},
{
"name": "CVE-2026-53173",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53173"
},
{
"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-64528",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64528"
},
{
"name": "CVE-2026-53053",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53053"
},
{
"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-53403",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53403"
},
{
"name": "CVE-2026-63871",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63871"
},
{
"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-53209",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53209"
},
{
"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-63797",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63797"
},
{
"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-64456",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64456"
},
{
"name": "CVE-2026-53112",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53112"
},
{
"name": "CVE-2026-72491",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72491"
},
{
"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-72393",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72393"
},
{
"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-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-53371",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53371"
},
{
"name": "CVE-2026-64306",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64306"
},
{
"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-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-64465",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64465"
},
{
"name": "CVE-2026-64313",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64313"
},
{
"name": "CVE-2026-52965",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52965"
},
{
"name": "CVE-2026-63978",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63978"
},
{
"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-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-53157",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53157"
},
{
"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-46154",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46154"
},
{
"name": "CVE-2025-10263",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-10263"
},
{
"name": "CVE-2026-31450",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31450"
},
{
"name": "CVE-2026-53135",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53135"
},
{
"name": "CVE-2026-74434",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-74434"
},
{
"name": "CVE-2026-63853",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63853"
},
{
"name": "CVE-2026-64442",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64442"
},
{
"name": "CVE-2026-46302",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46302"
},
{
"name": "CVE-2026-53333",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53333"
},
{
"name": "CVE-2026-64477",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64477"
},
{
"name": "CVE-2026-64463",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64463"
},
{
"name": "CVE-2026-64401",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64401"
},
{
"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-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-72064",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72064"
},
{
"name": "CVE-2026-53188",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53188"
},
{
"name": "CVE-2026-53392",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53392"
},
{
"name": "CVE-2026-64259",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64259"
},
{
"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-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-45985",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45985"
},
{
"name": "CVE-2026-64541",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64541"
},
{
"name": "CVE-2026-64069",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64069"
},
{
"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-2026-64332",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64332"
},
{
"name": "CVE-2025-23141",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23141"
},
{
"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-53170",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53170"
},
{
"name": "CVE-2026-46108",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46108"
},
{
"name": "CVE-2026-53167",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53167"
},
{
"name": "CVE-2026-52927",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52927"
},
{
"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-64191",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64191"
},
{
"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-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-64458",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64458"
},
{
"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-64476",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64476"
},
{
"name": "CVE-2026-64027",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64027"
},
{
"name": "CVE-2026-64378",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64378"
},
{
"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-72323",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72323"
},
{
"name": "CVE-2026-72065",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72065"
},
{
"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-64318",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64318"
},
{
"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-64521",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64521"
},
{
"name": "CVE-2026-64300",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64300"
},
{
"name": "CVE-2026-72398",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72398"
},
{
"name": "CVE-2026-52908",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52908"
},
{
"name": "CVE-2026-63861",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63861"
},
{
"name": "CVE-2026-45899",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45899"
},
{
"name": "CVE-2026-63794",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63794"
},
{
"name": "CVE-2026-31662",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31662"
},
{
"name": "CVE-2026-53018",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53018"
},
{
"name": "CVE-2026-64394",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64394"
},
{
"name": "CVE-2026-74398",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-74398"
},
{
"name": "CVE-2026-53237",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53237"
},
{
"name": "CVE-2026-80591",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-80591"
},
{
"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-53186",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53186"
},
{
"name": "CVE-2024-36922",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36922"
},
{
"name": "CVE-2026-23238",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23238"
},
{
"name": "CVE-2026-53340",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53340"
},
{
"name": "CVE-2026-43026",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43026"
},
{
"name": "CVE-2026-53182",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53182"
},
{
"name": "CVE-2026-53177",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53177"
},
{
"name": "CVE-2026-31480",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31480"
},
{
"name": "CVE-2026-53208",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53208"
},
{
"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-53255",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53255"
},
{
"name": "CVE-2026-46070",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46070"
},
{
"name": "CVE-2026-53207",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53207"
},
{
"name": "CVE-2026-43430",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43430"
},
{
"name": "CVE-2026-64244",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64244"
},
{
"name": "CVE-2026-53375",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53375"
},
{
"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-53123",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53123"
},
{
"name": "CVE-2026-53347",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53347"
},
{
"name": "CVE-2026-53126",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53126"
},
{
"name": "CVE-2026-53187",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53187"
},
{
"name": "CVE-2026-64060",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64060"
},
{
"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-64228",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64228"
},
{
"name": "CVE-2026-52950",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52950"
},
{
"name": "CVE-2026-72355",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72355"
},
{
"name": "CVE-2026-46044",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46044"
},
{
"name": "CVE-2026-53160",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53160"
},
{
"name": "CVE-2026-74384",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-74384"
},
{
"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-53245",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53245"
},
{
"name": "CVE-2026-53195",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53195"
},
{
"name": "CVE-2026-64309",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64309"
},
{
"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-63824",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63824"
},
{
"name": "CVE-2026-72139",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72139"
},
{
"name": "CVE-2026-53171",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53171"
},
{
"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-2026-63914",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63914"
},
{
"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-64556",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64556"
},
{
"name": "CVE-2026-63825",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63825"
},
{
"name": "CVE-2026-31627",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31627"
},
{
"name": "CVE-2026-46311",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46311"
},
{
"name": "CVE-2026-74433",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-74433"
},
{
"name": "CVE-2026-53164",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53164"
},
{
"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-72463",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72463"
},
{
"name": "CVE-2026-63874",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63874"
},
{
"name": "CVE-2026-53285",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53285"
},
{
"name": "CVE-2026-64224",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64224"
},
{
"name": "CVE-2026-63901",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63901"
},
{
"name": "CVE-2026-53232",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53232"
},
{
"name": "CVE-2026-23300",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23300"
},
{
"name": "CVE-2026-64435",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64435"
},
{
"name": "CVE-2026-45941",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45941"
},
{
"name": "CVE-2026-64184",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64184"
},
{
"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-64336",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64336"
},
{
"name": "CVE-2026-53148",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53148"
},
{
"name": "CVE-2026-63951",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63951"
},
{
"name": "CVE-2026-53189",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53189"
},
{
"name": "CVE-2026-64352",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64352"
},
{
"name": "CVE-2026-72318",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72318"
},
{
"name": "CVE-2026-43378",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43378"
},
{
"name": "CVE-2026-64474",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64474"
},
{
"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-64356",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64356"
},
{
"name": "CVE-2026-63867",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63867"
},
{
"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-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-53133",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53133"
},
{
"name": "CVE-2026-64377",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64377"
},
{
"name": "CVE-2026-43093",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43093"
},
{
"name": "CVE-2026-31780",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31780"
},
{
"name": "CVE-2026-53204",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53204"
},
{
"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-23243",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23243"
},
{
"name": "CVE-2026-64346",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64346"
},
{
"name": "CVE-2026-53351",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53351"
},
{
"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-53307",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53307"
},
{
"name": "CVE-2026-64522",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64522"
},
{
"name": "CVE-2026-31626",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31626"
},
{
"name": "CVE-2026-53087",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53087"
},
{
"name": "CVE-2026-53344",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53344"
},
{
"name": "CVE-2026-43357",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43357"
},
{
"name": "CVE-2026-53263",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53263"
},
{
"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-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-63822",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63822"
},
{
"name": "CVE-2026-72329",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72329"
},
{
"name": "CVE-2026-46240",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46240"
},
{
"name": "CVE-2026-74310",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-74310"
},
{
"name": "CVE-2026-72041",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72041"
},
{
"name": "CVE-2026-64187",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64187"
},
{
"name": "CVE-2026-64342",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64342"
},
{
"name": "CVE-2026-46104",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46104"
},
{
"name": "CVE-2026-64392",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64392"
},
{
"name": "CVE-2026-64360",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64360"
},
{
"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-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-64478",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64478"
},
{
"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-53152",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53152"
},
{
"name": "CVE-2026-53356",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53356"
},
{
"name": "CVE-2026-43076",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43076"
},
{
"name": "CVE-2026-63799",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63799"
},
{
"name": "CVE-2026-64472",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64472"
},
{
"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-53069",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53069"
},
{
"name": "CVE-2026-64335",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64335"
},
{
"name": "CVE-2026-46215",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46215"
},
{
"name": "CVE-2026-53228",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53228"
},
{
"name": "CVE-2026-63906",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63906"
},
{
"name": "CVE-2026-72399",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72399"
},
{
"name": "CVE-2026-63877",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63877"
},
{
"name": "CVE-2026-64301",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64301"
},
{
"name": "CVE-2026-64315",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64315"
},
{
"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-64395",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64395"
},
{
"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-64273",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64273"
},
{
"name": "CVE-2026-53259",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53259"
},
{
"name": "CVE-2026-43296",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43296"
},
{
"name": "CVE-2026-63828",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63828"
},
{
"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-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-72226",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72226"
},
{
"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-63820",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63820"
},
{
"name": "CVE-2026-31660",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31660"
},
{
"name": "CVE-2026-64262",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64262"
},
{
"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-64142",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64142"
},
{
"name": "CVE-2026-64211",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64211"
},
{
"name": "CVE-2026-53336",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53336"
},
{
"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-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-72348",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72348"
},
{
"name": "CVE-2026-46152",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46152"
},
{
"name": "CVE-2026-46290",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46290"
},
{
"name": "CVE-2026-64509",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64509"
},
{
"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-53194",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53194"
},
{
"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-64307",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64307"
},
{
"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-64036",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64036"
},
{
"name": "CVE-2026-53242",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53242"
},
{
"name": "CVE-2026-53293",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53293"
},
{
"name": "CVE-2026-53248",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53248"
},
{
"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-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-31773",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31773"
},
{
"name": "CVE-2026-53341",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53341"
},
{
"name": "CVE-2026-64238",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64238"
},
{
"name": "CVE-2026-43134",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43134"
},
{
"name": "CVE-2026-52910",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52910"
},
{
"name": "CVE-2026-53206",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53206"
},
{
"name": "CVE-2026-64339",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64339"
},
{
"name": "CVE-2026-64108",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64108"
},
{
"name": "CVE-2026-64529",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64529"
},
{
"name": "CVE-2026-53388",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53388"
},
{
"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-2025-71150",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71150"
},
{
"name": "CVE-2026-46167",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46167"
},
{
"name": "CVE-2026-63804",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63804"
},
{
"name": "CVE-2026-64305",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64305"
},
{
"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-53212",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53212"
},
{
"name": "CVE-2026-43015",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43015"
},
{
"name": "CVE-2026-53137",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53137"
},
{
"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-72429",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72429"
},
{
"name": "CVE-2026-43242",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43242"
},
{
"name": "CVE-2026-64400",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64400"
},
{
"name": "CVE-2026-72248",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72248"
},
{
"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-64381",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64381"
},
{
"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-45970",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45970"
},
{
"name": "CVE-2026-64604",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64604"
},
{
"name": "CVE-2026-53393",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53393"
},
{
"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-53337",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53337"
},
{
"name": "CVE-2026-64597",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64597"
},
{
"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-63812",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63812"
},
{
"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-2026-53199",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53199"
},
{
"name": "CVE-2026-43085",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43085"
},
{
"name": "CVE-2026-64496",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64496"
},
{
"name": "CVE-2026-64062",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64062"
},
{
"name": "CVE-2026-64251",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64251"
},
{
"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-64387",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64387"
},
{
"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-52938",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52938"
},
{
"name": "CVE-2026-63972",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63972"
},
{
"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-46105",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46105"
},
{
"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-64408",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64408"
},
{
"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-53247",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53247"
},
{
"name": "CVE-2026-31761",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31761"
},
{
"name": "CVE-2026-31466",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31466"
},
{
"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-53165",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53165"
},
{
"name": "CVE-2026-63953",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63953"
},
{
"name": "CVE-2026-64227",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64227"
},
{
"name": "CVE-2026-53197",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53197"
},
{
"name": "CVE-2026-64481",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64481"
},
{
"name": "CVE-2026-53042",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53042"
},
{
"name": "CVE-2026-53258",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53258"
},
{
"name": "CVE-2026-64316",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64316"
},
{
"name": "CVE-2026-53289",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53289"
},
{
"name": "CVE-2026-64208",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64208"
},
{
"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-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-64417",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64417"
},
{
"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-53268",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53268"
},
{
"name": "CVE-2026-64457",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64457"
},
{
"name": "CVE-2026-46313",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46313"
},
{
"name": "CVE-2026-63819",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63819"
},
{
"name": "CVE-2026-80952",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-80952"
},
{
"name": "CVE-2026-53241",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53241"
},
{
"name": "CVE-2026-53223",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53223"
},
{
"name": "CVE-2026-64423",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64423"
},
{
"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-64443",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64443"
},
{
"name": "CVE-2026-46244",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46244"
},
{
"name": "CVE-2026-53159",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53159"
},
{
"name": "CVE-2026-64588",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64588"
},
{
"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-2026-43257",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43257"
},
{
"name": "CVE-2026-64229",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64229"
},
{
"name": "CVE-2026-31778",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31778"
},
{
"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-43196",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43196"
},
{
"name": "CVE-2026-63868",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63868"
},
{
"name": "CVE-2026-53290",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53290"
},
{
"name": "CVE-2026-64269",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64269"
},
{
"name": "CVE-2026-53080",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53080"
},
{
"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-53267",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53267"
},
{
"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-72296",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72296"
},
{
"name": "CVE-2026-52912",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52912"
},
{
"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-64482",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64482"
},
{
"name": "CVE-2026-64218",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64218"
},
{
"name": "CVE-2026-52976",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52976"
},
{
"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-64495",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64495"
},
{
"name": "CVE-2026-46006",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46006"
},
{
"name": "CVE-2026-53221",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53221"
},
{
"name": "CVE-2026-43428",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43428"
},
{
"name": "CVE-2026-52998",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52998"
},
{
"name": "CVE-2026-63811",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63811"
},
{
"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-64282",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64282"
},
{
"name": "CVE-2026-53275",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53275"
},
{
"name": "CVE-2026-63982",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63982"
},
{
"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-64366",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64366"
},
{
"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-64594",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64594"
},
{
"name": "CVE-2026-64278",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64278"
},
{
"name": "CVE-2026-63960",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63960"
},
{
"name": "CVE-2026-23474",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23474"
},
{
"name": "CVE-2026-64396",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64396"
},
{
"name": "CVE-2025-71232",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71232"
},
{
"name": "CVE-2026-53203",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53203"
},
{
"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-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-2026-43226",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43226"
},
{
"name": "CVE-2026-53269",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53269"
},
{
"name": "CVE-2026-64235",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64235"
},
{
"name": "CVE-2026-64479",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64479"
},
{
"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-64324",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64324"
},
{
"name": "CVE-2026-64329",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64329"
},
{
"name": "CVE-2026-45843",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45843"
},
{
"name": "CVE-2026-64434",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64434"
},
{
"name": "CVE-2026-46115",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46115"
},
{
"name": "CVE-2026-64373",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64373"
},
{
"name": "CVE-2026-63997",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63997"
},
{
"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-46136",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46136"
},
{
"name": "CVE-2026-64219",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64219"
},
{
"name": "CVE-2026-64277",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64277"
},
{
"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-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-53136",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53136"
},
{
"name": "CVE-2026-64503",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64503"
},
{
"name": "CVE-2026-63977",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63977"
},
{
"name": "CVE-2026-31570",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31570"
},
{
"name": "CVE-2026-53215",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53215"
},
{
"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-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-72381",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72381"
},
{
"name": "CVE-2026-23141",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23141"
},
{
"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-2026-53216",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53216"
},
{
"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-74350",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-74350"
},
{
"name": "CVE-2026-31399",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31399"
},
{
"name": "CVE-2026-72496",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72496"
},
{
"name": "CVE-2026-53153",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53153"
},
{
"name": "CVE-2026-63969",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63969"
},
{
"name": "CVE-2026-64291",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64291"
},
{
"name": "CVE-2026-53226",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53226"
},
{
"name": "CVE-2026-53089",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53089"
},
{
"name": "CVE-2026-63809",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63809"
},
{
"name": "CVE-2026-53253",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53253"
},
{
"name": "CVE-2026-31489",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31489"
},
{
"name": "CVE-2026-53250",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53250"
},
{
"name": "CVE-2026-64453",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64453"
},
{
"name": "CVE-2026-53003",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53003"
},
{
"name": "CVE-2026-53394",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53394"
},
{
"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-64436",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64436"
},
{
"name": "CVE-2026-64403",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64403"
},
{
"name": "CVE-2026-52948",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52948"
},
{
"name": "CVE-2026-64222",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64222"
},
{
"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-63836",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63836"
},
{
"name": "CVE-2026-63814",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63814"
},
{
"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-53252",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53252"
},
{
"name": "CVE-2026-64216",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64216"
},
{
"name": "CVE-2026-63927",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63927"
},
{
"name": "CVE-2026-64412",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64412"
},
{
"name": "CVE-2026-64284",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64284"
},
{
"name": "CVE-2026-53355",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53355"
},
{
"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-43187",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43187"
},
{
"name": "CVE-2026-64188",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64188"
},
{
"name": "CVE-2026-46149",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46149"
},
{
"name": "CVE-2026-64491",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64491"
},
{
"name": "CVE-2026-74287",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-74287"
},
{
"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-64487",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64487"
},
{
"name": "CVE-2026-64391",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64391"
},
{
"name": "CVE-2026-64303",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64303"
},
{
"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-64429",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64429"
},
{
"name": "CVE-2026-64344",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64344"
},
{
"name": "CVE-2026-53134",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53134"
},
{
"name": "CVE-2026-63831",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63831"
},
{
"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-64286",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64286"
},
{
"name": "CVE-2026-72412",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72412"
},
{
"name": "CVE-2026-64292",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64292"
},
{
"name": "CVE-2026-53359",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53359"
},
{
"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-63834",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63834"
},
{
"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-64350",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64350"
},
{
"name": "CVE-2026-64321",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64321"
},
{
"name": "CVE-2026-46132",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46132"
},
{
"name": "CVE-2026-72473",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72473"
},
{
"name": "CVE-2026-64111",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64111"
},
{
"name": "CVE-2026-64447",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64447"
},
{
"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-64149",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64149"
},
{
"name": "CVE-2026-53256",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53256"
},
{
"name": "CVE-2026-64075",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64075"
},
{
"name": "CVE-2026-31507",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31507"
},
{
"name": "CVE-2026-72014",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72014"
},
{
"name": "CVE-2026-64411",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64411"
},
{
"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-53235",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53235"
},
{
"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-53396",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53396"
},
{
"name": "CVE-2026-53277",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53277"
},
{
"name": "CVE-2026-64587",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64587"
},
{
"name": "CVE-2026-63998",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63998"
},
{
"name": "CVE-2026-31762",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31762"
},
{
"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-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-72098",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72098"
},
{
"name": "CVE-2026-72249",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72249"
},
{
"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-63862",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63862"
},
{
"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-64242",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64242"
},
{
"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-64334",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64334"
},
{
"name": "CVE-2026-64049",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64049"
},
{
"name": "CVE-2026-46210",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46210"
},
{
"name": "CVE-2026-53384",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53384"
},
{
"name": "CVE-2026-53155",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53155"
},
{
"name": "CVE-2026-72442",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72442"
},
{
"name": "CVE-2026-64183",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64183"
},
{
"name": "CVE-2026-64448",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64448"
},
{
"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-43089",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43089"
},
{
"name": "CVE-2026-72493",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72493"
},
{
"name": "CVE-2026-53033",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53033"
},
{
"name": "CVE-2026-72221",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72221"
},
{
"name": "CVE-2026-72289",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72289"
},
{
"name": "CVE-2026-72251",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72251"
},
{
"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-64347",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64347"
},
{
"name": "CVE-2026-63826",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63826"
},
{
"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-64393",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64393"
},
{
"name": "CVE-2026-64134",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64134"
},
{
"name": "CVE-2026-53026",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53026"
},
{
"name": "CVE-2026-43112",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43112"
},
{
"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-64466",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64466"
},
{
"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-64419",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64419"
},
{
"name": "CVE-2026-46107",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46107"
},
{
"name": "CVE-2026-64524",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64524"
},
{
"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-53145",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53145"
},
{
"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-53270",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53270"
},
{
"name": "CVE-2026-53379",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53379"
},
{
"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-53198",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53198"
},
{
"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-64382",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64382"
},
{
"name": "CVE-2026-64589",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64589"
},
{
"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-53240",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53240"
},
{
"name": "CVE-2026-64372",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64372"
},
{
"name": "CVE-2026-64490",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64490"
},
{
"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-52909",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52909"
},
{
"name": "CVE-2026-46249",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46249"
},
{
"name": "CVE-2026-64236",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64236"
},
{
"name": "CVE-2026-63922",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63922"
},
{
"name": "CVE-2026-64283",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64283"
},
{
"name": "CVE-2026-53395",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53395"
},
{
"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-64444",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64444"
},
{
"name": "CVE-2026-46202",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46202"
},
{
"name": "CVE-2022-49803",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49803"
},
{
"name": "CVE-2026-64233",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64233"
},
{
"name": "CVE-2026-46270",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46270"
},
{
"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-64225",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64225"
},
{
"name": "CVE-2026-64331",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64331"
},
{
"name": "CVE-2026-64511",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64511"
},
{
"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-64361",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64361"
},
{
"name": "CVE-2026-64209",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64209"
},
{
"name": "CVE-2026-31506",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31506"
},
{
"name": "CVE-2026-64182",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64182"
},
{
"name": "CVE-2026-53264",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53264"
},
{
"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-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-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-53142",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53142"
},
{
"name": "CVE-2026-53098",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53098"
},
{
"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-64369",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64369"
},
{
"name": "CVE-2026-53175",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53175"
},
{
"name": "CVE-2026-64024",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64024"
},
{
"name": "CVE-2026-64215",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64215"
},
{
"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-45891",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45891"
},
{
"name": "CVE-2026-53273",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53273"
},
{
"name": "CVE-2026-64054",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64054"
},
{
"name": "CVE-2026-53184",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53184"
},
{
"name": "CVE-2026-64019",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64019"
},
{
"name": "CVE-2026-31560",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31560"
},
{
"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-64265",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64265"
},
{
"name": "CVE-2026-52953",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52953"
},
{
"name": "CVE-2026-64494",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64494"
},
{
"name": "CVE-2026-53093",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53093"
},
{
"name": "CVE-2026-63899",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63899"
},
{
"name": "CVE-2026-74268",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-74268"
},
{
"name": "CVE-2026-46200",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46200"
},
{
"name": "CVE-2026-72451",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72451"
},
{
"name": "CVE-2026-53144",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53144"
},
{
"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-46222",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46222"
},
{
"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-53385",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53385"
},
{
"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-53246",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53246"
},
{
"name": "CVE-2026-64245",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64245"
},
{
"name": "CVE-2026-72279",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72279"
},
{
"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-53326",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53326"
},
{
"name": "CVE-2026-64240",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64240"
},
{
"name": "CVE-2026-63823",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63823"
},
{
"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-53325",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53325"
},
{
"name": "CVE-2026-53323",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53323"
},
{
"name": "CVE-2026-72501",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72501"
},
{
"name": "CVE-2026-64354",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64354"
},
{
"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-64206",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64206"
},
{
"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-31651",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31651"
},
{
"name": "CVE-2026-64530",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64530"
},
{
"name": "CVE-2026-64015",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64015"
},
{
"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-64294",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64294"
},
{
"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-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-2026-64288",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64288"
},
{
"name": "CVE-2025-21863",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21863"
},
{
"name": "CVE-2026-64285",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64285"
},
{
"name": "CVE-2026-64123",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64123"
},
{
"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-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-53363",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53363"
},
{
"name": "CVE-2026-74436",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-74436"
},
{
"name": "CVE-2026-52991",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52991"
},
{
"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-63808",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63808"
},
{
"name": "CVE-2026-53191",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53191"
},
{
"name": "CVE-2026-72217",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72217"
},
{
"name": "CVE-2026-31624",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31624"
},
{
"name": "CVE-2026-64493",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64493"
},
{
"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-52940",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52940"
},
{
"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-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-64535",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64535"
},
{
"name": "CVE-2026-63973",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63973"
},
{
"name": "CVE-2026-63857",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63857"
},
{
"name": "CVE-2026-46144",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46144"
},
{
"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-53352",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53352"
},
{
"name": "CVE-2026-64234",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64234"
},
{
"name": "CVE-2026-53151",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53151"
},
{
"name": "CVE-2026-64416",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64416"
},
{
"name": "CVE-2026-72234",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72234"
},
{
"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-64247",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64247"
},
{
"name": "CVE-2026-64379",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64379"
},
{
"name": "CVE-2026-53254",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53254"
},
{
"name": "CVE-2026-53078",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53078"
},
{
"name": "CVE-2025-37786",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37786"
},
{
"name": "CVE-2026-52928",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52928"
},
{
"name": "CVE-2026-64420",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64420"
},
{
"name": "CVE-2026-64138",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64138"
},
{
"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-53180",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53180"
},
{
"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-53238",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53238"
},
{
"name": "CVE-2026-64205",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64205"
},
{
"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-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-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-64325",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64325"
},
{
"name": "CVE-2026-74427",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-74427"
},
{
"name": "CVE-2026-53213",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53213"
},
{
"name": "CVE-2026-64525",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64525"
},
{
"name": "CVE-2025-68239",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68239"
},
{
"name": "CVE-2026-64596",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64596"
},
{
"name": "CVE-2026-43194",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43194"
},
{
"name": "CVE-2026-53387",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53387"
},
{
"name": "CVE-2026-23382",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23382"
},
{
"name": "CVE-2026-64384",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64384"
},
{
"name": "CVE-2026-64037",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64037"
},
{
"name": "CVE-2026-68084",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68084"
},
{
"name": "CVE-2026-64406",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64406"
},
{
"name": "CVE-2026-63912",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63912"
},
{
"name": "CVE-2026-64425",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64425"
},
{
"name": "CVE-2026-64600",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64600"
},
{
"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-74406",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-74406"
},
{
"name": "CVE-2026-52930",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52930"
},
{
"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-64312",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64312"
},
{
"name": "CVE-2026-43209",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43209"
},
{
"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-68460",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-68460"
},
{
"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-53265",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53265"
},
{
"name": "CVE-2026-64526",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64526"
},
{
"name": "CVE-2026-64428",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64428"
},
{
"name": "CVE-2026-45902",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45902"
},
{
"name": "CVE-2026-64505",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64505"
},
{
"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-64426",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64426"
},
{
"name": "CVE-2026-52974",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52974"
},
{
"name": "CVE-2026-64507",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64507"
},
{
"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-53366",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53366"
},
{
"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-46212",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46212"
},
{
"name": "CVE-2026-64499",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64499"
},
{
"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-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-31630",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31630"
},
{
"name": "CVE-2026-74584",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-74584"
},
{
"name": "CVE-2026-43333",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43333"
},
{
"name": "CVE-2026-53154",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53154"
},
{
"name": "CVE-2026-64358",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64358"
},
{
"name": "CVE-2026-64355",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64355"
},
{
"name": "CVE-2026-46199",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46199"
},
{
"name": "CVE-2026-64515",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64515"
},
{
"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-72069",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72069"
},
{
"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-64290",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64290"
},
{
"name": "CVE-2026-64185",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64185"
},
{
"name": "CVE-2026-64422",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64422"
},
{
"name": "CVE-2026-64519",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64519"
},
{
"name": "CVE-2026-72020",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72020"
},
{
"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-53196",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53196"
},
{
"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-64340",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64340"
},
{
"name": "CVE-2026-64092",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64092"
},
{
"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-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-64450",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64450"
},
{
"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-53156",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53156"
},
{
"name": "CVE-2026-45875",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45875"
},
{
"name": "CVE-2026-64484",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64484"
},
{
"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-64298",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64298"
},
{
"name": "CVE-2026-52969",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52969"
},
{
"name": "CVE-2026-46098",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46098"
},
{
"name": "CVE-2026-46157",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46157"
},
{
"name": "CVE-2026-64207",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64207"
},
{
"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-64114",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64114"
},
{
"name": "CVE-2026-64390",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64390"
},
{
"name": "CVE-2026-45974",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45974"
},
{
"name": "CVE-2026-53390",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53390"
},
{
"name": "CVE-2026-45965",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45965"
},
{
"name": "CVE-2026-74255",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-74255"
},
{
"name": "CVE-2026-72191",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72191"
},
{
"name": "CVE-2026-43218",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43218"
},
{
"name": "CVE-2026-64266",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64266"
},
{
"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-53211",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53211"
},
{
"name": "CVE-2026-43363",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43363"
},
{
"name": "CVE-2026-64159",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64159"
},
{
"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-2026-64441",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64441"
},
{
"name": "CVE-2025-38659",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38659"
},
{
"name": "CVE-2026-43130",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43130"
},
{
"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-53162",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53162"
},
{
"name": "CVE-2026-53343",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53343"
},
{
"name": "CVE-2026-23398",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23398"
},
{
"name": "CVE-2026-74269",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-74269"
},
{
"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-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-63829",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63829"
},
{
"name": "CVE-2026-72192",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72192"
},
{
"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-72288",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72288"
},
{
"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-64440",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64440"
},
{
"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-63803",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63803"
},
{
"name": "CVE-2026-45890",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45890"
},
{
"name": "CVE-2026-46155",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46155"
},
{
"name": "CVE-2026-52917",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52917"
},
{
"name": "CVE-2026-43255",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43255"
},
{
"name": "CVE-2026-64601",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64601"
},
{
"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-72477",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72477"
},
{
"name": "CVE-2026-72046",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72046"
},
{
"name": "CVE-2026-53261",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53261"
},
{
"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-72085",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72085"
},
{
"name": "CVE-2026-52982",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52982"
},
{
"name": "CVE-2026-74428",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-74428"
},
{
"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-64359",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64359"
},
{
"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-64317",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64317"
},
{
"name": "CVE-2026-53328",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53328"
},
{
"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-63883",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63883"
},
{
"name": "CVE-2026-45969",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45969"
},
{
"name": "CVE-2026-43203",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43203"
},
{
"name": "CVE-2026-63802",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63802"
},
{
"name": "CVE-2026-31673",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31673"
},
{
"name": "CVE-2026-63869",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63869"
},
{
"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-09-25T00:00:00",
"last_revision_date": "2026-09-25T00:00:00",
"links": [],
"reference": "CERTFR-2026-AVI-1229",
"revisions": [
{
"description": "Version initiale",
"revision_date": "2026-09-25T00:00:00.000000"
}
],
"risks": [
{
"description": "D\u00e9ni de service \u00e0 distance"
},
{
"description": "Atteinte \u00e0 l\u0027int\u00e9grit\u00e9 des donn\u00e9es"
},
{
"description": "Non sp\u00e9cifi\u00e9 par l\u0027\u00e9diteur"
},
{
"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, un d\u00e9ni de service \u00e0 distance et une atteinte \u00e0 la confidentialit\u00e9 des donn\u00e9es.",
"title": "Multiples vuln\u00e9rabilit\u00e9s dans le noyau Linux d\u0027Ubuntu",
"vendor_advisories": [
{
"published_at": "2026-09-22",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8800-1",
"url": "https://ubuntu.com/security/notices/USN-8800-1"
},
{
"published_at": "2026-09-21",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8668-2",
"url": "https://ubuntu.com/security/notices/USN-8668-2"
},
{
"published_at": "2026-09-22",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8801-1",
"url": "https://ubuntu.com/security/notices/USN-8801-1"
},
{
"published_at": "2026-09-22",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8760-2",
"url": "https://ubuntu.com/security/notices/USN-8760-2"
},
{
"published_at": "2026-09-22",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8728-2",
"url": "https://ubuntu.com/security/notices/USN-8728-2"
},
{
"published_at": "2026-09-22",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8802-1",
"url": "https://ubuntu.com/security/notices/USN-8802-1"
},
{
"published_at": "2026-09-22",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8729-4",
"url": "https://ubuntu.com/security/notices/USN-8729-4"
},
{
"published_at": "2026-09-24",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8816-1",
"url": "https://ubuntu.com/security/notices/USN-8816-1"
},
{
"published_at": "2026-09-21",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8729-3",
"url": "https://ubuntu.com/security/notices/USN-8729-3"
},
{
"published_at": "2026-09-22",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8793-2",
"url": "https://ubuntu.com/security/notices/USN-8793-2"
},
{
"published_at": "2026-09-21",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8761-3",
"url": "https://ubuntu.com/security/notices/USN-8761-3"
},
{
"published_at": "2026-09-24",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8818-1",
"url": "https://ubuntu.com/security/notices/USN-8818-1"
},
{
"published_at": "2026-09-21",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8726-3",
"url": "https://ubuntu.com/security/notices/USN-8726-3"
},
{
"published_at": "2026-09-21",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8730-4",
"url": "https://ubuntu.com/security/notices/USN-8730-4"
},
{
"published_at": "2026-09-22",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8730-5",
"url": "https://ubuntu.com/security/notices/USN-8730-5"
},
{
"published_at": "2026-09-22",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8661-5",
"url": "https://ubuntu.com/security/notices/USN-8661-5"
},
{
"published_at": "2026-09-24",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8817-1",
"url": "https://ubuntu.com/security/notices/USN-8817-1"
},
{
"published_at": "2026-09-22",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8726-4",
"url": "https://ubuntu.com/security/notices/USN-8726-4"
},
{
"published_at": "2026-09-21",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8793-1",
"url": "https://ubuntu.com/security/notices/USN-8793-1"
}
]
}
FKIE_CVE-2026-46178
Vulnerability from fkie_nvd - Published: 2026-05-28 10:16 - Updated: 2026-06-17 10:53| URL | Tags | ||
|---|---|---|---|
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/0be6ae614ca7fa53e7389e3c7462ed20abbd4192 | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/0dbd619716fb07b7de1acd64fec673ee6e1adde7 | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/388617f44d81604a760742a0b5de292d411e63e3 | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/53fd4c03558672ccb167754fbacbf045c7ab335c | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/5b3b220d54e6a3d77380cb7caa1ef79cb8f4fc94 | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/c54c7e4cb679c0aaa1cb489b9c3f2cd98e63a44c | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/c5dc30da990045105c9762248d23076223e7878a | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/e01b8c9286c470b71a38acd320106f2c4f2826a1 | 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 | * | |
| linux | linux_kernel | 7.1 | |
| linux | linux_kernel | 7.1 |
{
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/infiniband/hw/mlx4/srq.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "53fd4c03558672ccb167754fbacbf045c7ab335c",
"status": "affected",
"version": "225c7b1feef1b41170f7037a5b10a65cd8a42c54",
"versionType": "git"
},
{
"lessThan": "0be6ae614ca7fa53e7389e3c7462ed20abbd4192",
"status": "affected",
"version": "225c7b1feef1b41170f7037a5b10a65cd8a42c54",
"versionType": "git"
},
{
"lessThan": "5b3b220d54e6a3d77380cb7caa1ef79cb8f4fc94",
"status": "affected",
"version": "225c7b1feef1b41170f7037a5b10a65cd8a42c54",
"versionType": "git"
},
{
"lessThan": "c5dc30da990045105c9762248d23076223e7878a",
"status": "affected",
"version": "225c7b1feef1b41170f7037a5b10a65cd8a42c54",
"versionType": "git"
},
{
"lessThan": "0dbd619716fb07b7de1acd64fec673ee6e1adde7",
"status": "affected",
"version": "225c7b1feef1b41170f7037a5b10a65cd8a42c54",
"versionType": "git"
},
{
"lessThan": "e01b8c9286c470b71a38acd320106f2c4f2826a1",
"status": "affected",
"version": "225c7b1feef1b41170f7037a5b10a65cd8a42c54",
"versionType": "git"
},
{
"lessThan": "388617f44d81604a760742a0b5de292d411e63e3",
"status": "affected",
"version": "225c7b1feef1b41170f7037a5b10a65cd8a42c54",
"versionType": "git"
},
{
"lessThan": "c54c7e4cb679c0aaa1cb489b9c3f2cd98e63a44c",
"status": "affected",
"version": "225c7b1feef1b41170f7037a5b10a65cd8a42c54",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/infiniband/hw/mlx4/srq.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "2.6.22"
},
{
"lessThan": "2.6.22",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.258",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.209",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.175",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.140",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.88",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.18.*",
"status": "unaffected",
"version": "6.18.30",
"versionType": "semver"
},
{
"lessThanOrEqual": "7.0.*",
"status": "unaffected",
"version": "7.0.7",
"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": "24DC2C27-0B51-4D9E-BFA5-A6472A386F01",
"versionEndExcluding": "5.10.258",
"versionStartIncluding": "2.6.22",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "919C10A9-7951-4A74-BADD-C135A0A8D8B4",
"versionEndExcluding": "5.15.209",
"versionStartIncluding": "5.11",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "92385813-D91D-480D-83A1-F423D2CBB2BA",
"versionEndExcluding": "6.1.175",
"versionStartIncluding": "5.16",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "A1A92866-F406-43B5-B2D1-CFC274753E9D",
"versionEndExcluding": "6.6.140",
"versionStartIncluding": "6.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "5AFBE0EC-CCDF-4207-AE92-ABF958125CA4",
"versionEndExcluding": "6.12.88",
"versionStartIncluding": "6.7",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "BF39AE08-AE6D-4410-8FBE-76F6BF5BF55B",
"versionEndExcluding": "6.18.30",
"versionStartIncluding": "6.13",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "D0893CA7-9AE6-4DFE-AC75-48967D73AD8E",
"versionEndExcluding": "7.0.7",
"versionStartIncluding": "6.19",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:7.1:rc1:*:*:*:*:*:*",
"matchCriteriaId": "B1EF7059-E670-45F4-B422-54C40FA86390",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:7.1:rc2:*:*:*:*:*:*",
"matchCriteriaId": "0D38F0BF-A728-4133-A358-D44A2F7EE6D6",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/mlx4: Fix resource leak on error in mlx4_ib_create_srq()\n\nSashiko points out that mlx4_srq_alloc() was not undone during error\nunwind, add the missing call to mlx4_srq_free()."
}
],
"id": "CVE-2026-46178",
"lastModified": "2026-06-17T10:53:13.490",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 7.8,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 5.9,
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"type": "Secondary"
}
]
},
"published": "2026-05-28T10:16:33.423",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/0be6ae614ca7fa53e7389e3c7462ed20abbd4192"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/0dbd619716fb07b7de1acd64fec673ee6e1adde7"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/388617f44d81604a760742a0b5de292d411e63e3"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/53fd4c03558672ccb167754fbacbf045c7ab335c"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/5b3b220d54e6a3d77380cb7caa1ef79cb8f4fc94"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/c54c7e4cb679c0aaa1cb489b9c3f2cd98e63a44c"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/c5dc30da990045105c9762248d23076223e7878a"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/e01b8c9286c470b71a38acd320106f2c4f2826a1"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Analyzed",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "CWE-401"
}
],
"source": "nvd@nist.gov",
"type": "Primary"
}
]
}
GHSA-WJRJ-6RQP-WH2C
Vulnerability from github – Published: 2026-05-28 12:30 – Updated: 2026-06-01 18:31In the Linux kernel, the following vulnerability has been resolved:
RDMA/mlx4: Fix resource leak on error in mlx4_ib_create_srq()
Sashiko points out that mlx4_srq_alloc() was not undone during error unwind, add the missing call to mlx4_srq_free().
{
"affected": [],
"aliases": [
"CVE-2026-46178"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-28T10:16:33Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/mlx4: Fix resource leak on error in mlx4_ib_create_srq()\n\nSashiko points out that mlx4_srq_alloc() was not undone during error\nunwind, add the missing call to mlx4_srq_free().",
"id": "GHSA-wjrj-6rqp-wh2c",
"modified": "2026-06-01T18:31:40Z",
"published": "2026-05-28T12:30:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46178"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0be6ae614ca7fa53e7389e3c7462ed20abbd4192"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0dbd619716fb07b7de1acd64fec673ee6e1adde7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/388617f44d81604a760742a0b5de292d411e63e3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/53fd4c03558672ccb167754fbacbf045c7ab335c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5b3b220d54e6a3d77380cb7caa1ef79cb8f4fc94"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c54c7e4cb679c0aaa1cb489b9c3f2cd98e63a44c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c5dc30da990045105c9762248d23076223e7878a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e01b8c9286c470b71a38acd320106f2c4f2826a1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
MSRC_CVE-2026-46178
Vulnerability from csaf_microsoft - Published: 2026-05-02 00:00 - Updated: 2026-06-09 14:44OESA-2026-2582 (CVE-2025-39833)
Vulnerability from osv_openeuler – Published: 2026-06-05 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:
mISDN: hfcpci: Fix warning when deleting uninitialized timer
With CONFIG_DEBUG_OBJECTS_TIMERS unloading hfcpci module leads to the following splat:
[ 250.215892] ODEBUG: assert_init not available (active state 0) object: ffffffffc01a3dc0 object type: timer_list hint: 0x0 [ 250.217520] WARNING: CPU: 0 PID: 233 at lib/debugobjects.c:612 debug_print_object+0x1b6/0x2c0 [ 250.218775] Modules linked in: hfcpci(-) mISDN_core [ 250.219537] CPU: 0 UID: 0 PID: 233 Comm: rmmod Not tainted 6.17.0-rc2-g6f713187ac98 #2 PREEMPT(voluntary) [ 250.220940] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 250.222377] RIP: 0010:debug_print_object+0x1b6/0x2c0 [ 250.223131] Code: fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 75 4f 41 56 48 8b 14 dd a0 4e 01 9f 48 89 ee 48 c7 c7 20 46 01 9f e8 cb 84d [ 250.225805] RSP: 0018:ffff888015ea7c08 EFLAGS: 00010286 [ 250.226608] RAX: 0000000000000000 RBX: 0000000000000005 RCX: ffffffff9be93a95 [ 250.227708] RDX: 1ffff1100d945138 RSI: 0000000000000008 RDI: ffff88806ca289c0 [ 250.228993] RBP: ffffffff9f014a00 R08: 0000000000000001 R09: ffffed1002bd4f39 [ 250.230043] R10: ffff888015ea79cf R11: 0000000000000001 R12: 0000000000000001 [ 250.231185] R13: ffffffff9eea0520 R14: 0000000000000000 R15: ffff888015ea7cc8 [ 250.232454] FS: 00007f3208f01540(0000) GS:ffff8880caf5a000(0000) knlGS:0000000000000000 [ 250.233851] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 250.234856] CR2: 00007f32090a7421 CR3: 0000000004d63000 CR4: 00000000000006f0 [ 250.236117] Call Trace: [ 250.236599] <TASK> [ 250.236967] ? trace_irq_enable.constprop.0+0xd4/0x130 [ 250.237920] debug_object_assert_init+0x1f6/0x310 [ 250.238762] ? __pfx_debug_object_assert_init+0x10/0x10 [ 250.239658] ? __lock_acquire+0xdea/0x1c70 [ 250.240369] __try_to_del_timer_sync+0x69/0x140 [ 250.241172] ? __pfxtryto_del_timer_sync+0x10/0x10 [ 250.242058] ? timer_delete_sync+0xc6/0x120 [ 250.242842] ? lock_acquire+0x30/0x80 [ 250.243474] ? __timer_delete_sync+0xc6/0x120 [ 250.244262] __timer_delete_sync+0x98/0x120 [ 250.245015] HFC_cleanup+0x10/0x20 [hfcpci] [ 250.245704] __do_sys_delete_module+0x348/0x510 [ 250.246461] ? __pfx___do_sys_delete_module+0x10/0x10 [ 250.247338] do_syscall_64+0xc1/0x360 [ 250.247924] entry_SYSCALL_64_after_hwframe+0x77/0x7f
Fix this by initializing hfc_tl timer with DEFINE_TIMER macro. Also, use mod_timer instead of manual timeout update.(CVE-2025-39833)
In the Linux kernel, the following vulnerability has been resolved:
platform/x86/amd/pmc: Add support for Van Gogh SoC
The ROG Xbox Ally (non-X) SoC features a similar architecture to the Steam Deck. While the Steam Deck supports S3 (s2idle causes a crash), this support was dropped by the Xbox Ally which only S0ix suspend.
Since the handler is missing here, this causes the device to not suspend and the AMD GPU driver to crash while trying to resume afterwards due to a power hang.(CVE-2025-68334)
In the Linux kernel, the following vulnerability has been resolved:
team: Move team device type change at the end of team_port_add
Attempting to add a port device that is already up will expectedly fail, but not before modifying the team device header_ops.
In the case of the syzbot reproducer the gre0 device is already in state UP when it attempts to add it as a port device of team0, this fails but before that header_ops->create of team0 is changed from eth_header to ipgre_header in the call to team_dev_type_check_change.
Later when we end up in ipgre_header() struct ip_tunnel* points to nonsense as the private data of the device still holds a struct team.
Example sequence of iproute2 commands to reproduce the hang/BUG(): ip link add dev team0 type team ip link add dev gre0 type gre ip link set dev gre0 up ip link set dev gre0 master team0 ip link set dev team0 up ping -I team0 1.1.1.1
Move team_dev_type_check_change down where all other checks have passed as it changes the dev type with no way to restore it in case one of the checks that follow it fail.
Also make sure to preserve the origial mtu assignment: - If port_dev is not the same type as dev, dev takes mtu from port_dev - If port_dev is the same type as dev, port_dev takes mtu from dev
This is done by adding a conditional before the call to dev_set_mtu to prevent it from assigning port_dev->mtu = dev->mtu and instead letting team_dev_type_check_change assign dev->mtu = port_dev->mtu. The conditional is needed because the patch moves the call to team_dev_type_check_change past dev_set_mtu.
Testing: - team device driver in-tree selftests - Add/remove various devices as slaves of team device - syzbot(CVE-2025-68340)
In the Linux kernel, the following vulnerability has been resolved:
mlxsw: spectrum_router: Fix neighbour use-after-free
We sometimes observe use-after-free when dereferencing a neighbour [1]. The problem seems to be that the driver stores a pointer to the neighbour, but without holding a reference on it. A reference is only taken when the neighbour is used by a nexthop.
Fix by simplifying the reference counting scheme. Always take a reference when storing a neighbour pointer in a neighbour entry. Avoid taking a referencing when the neighbour is used by a nexthop as the neighbour entry associated with the nexthop already holds a reference.
Tested by running the test that uncovered the problem over 300 times. Without this patch the problem was reproduced after a handful of iterations.
[1] BUG: KASAN: slab-use-after-free in mlxsw_sp_neigh_entry_update+0x2d4/0x310 Read of size 8 at addr ffff88817f8e3420 by task ip/3929
CPU: 3 UID: 0 PID: 3929 Comm: ip Not tainted 6.18.0-rc4-virtme-g36b21a067510 #3 PREEMPT(full) Hardware name: Nvidia SN5600/VMOD0013, BIOS 5.13 05/31/2023 Call Trace: <TASK> dump_stack_lvl+0x6f/0xa0 print_address_description.constprop.0+0x6e/0x300 print_report+0xfc/0x1fb kasan_report+0xe4/0x110 mlxsw_sp_neigh_entry_update+0x2d4/0x310 mlxsw_sp_router_rif_gone_sync+0x35f/0x510 mlxsw_sp_rif_destroy+0x1ea/0x730 mlxsw_sp_inetaddr_port_vlan_event+0xa1/0x1b0 __mlxsw_sp_inetaddr_lag_event+0xcc/0x130 __mlxsw_sp_inetaddr_event+0xf5/0x3c0 mlxsw_sp_router_netdevice_event+0x1015/0x1580 notifier_call_chain+0xcc/0x150 call_netdevice_notifiers_info+0x7e/0x100 __netdev_upper_dev_unlink+0x10b/0x210 netdev_upper_dev_unlink+0x79/0xa0 vrf_del_slave+0x18/0x50 do_set_master+0x146/0x7d0 do_setlink.isra.0+0x9a0/0x2880 rtnl_newlink+0x637/0xb20 rtnetlink_rcv_msg+0x6fe/0xb90 netlink_rcv_skb+0x123/0x380 netlink_unicast+0x4a3/0x770 netlink_sendmsg+0x75b/0xc90 __sock_sendmsg+0xbe/0x160 _syssendmsg+0x5b2/0x7d0 _sys_sendmsg+0xfd/0x180 __sys_sendmsg+0x124/0x1c0 do_syscall_64+0xbb/0xfd0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 [...]
Allocated by task 109: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x7b/0x90 __kmalloc_noprof+0x2c1/0x790 neigh_alloc+0x6af/0x8f0 ___neigh_create+0x63/0xe90 mlxsw_sp_nexthop_neigh_init+0x430/0x7e0 mlxsw_sp_nexthop_type_init+0x212/0x960 mlxsw_sp_nexthop6_group_info_init.constprop.0+0x81f/0x1280 mlxsw_sp_nexthop6_group_get+0x392/0x6a0 mlxsw_sp_fib6_entry_create+0x46a/0xfd0 mlxsw_sp_router_fib6_replace+0x1ed/0x5f0 mlxsw_sp_router_fib6_event_work+0x10a/0x2a0 process_one_work+0xd57/0x1390 worker_thread+0x4d6/0xd40 kthread+0x355/0x5b0 ret_from_fork+0x1d4/0x270 ret_from_fork_asm+0x11/0x20
Freed by task 154: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x43/0x70 kmem_cache_free_bulk.part.0+0x1eb/0x5e0 kvfree_rcu_bulk+0x1f2/0x260 kfree_rcu_work+0x130/0x1b0 process_one_work+0xd57/0x1390 worker_thread+0x4d6/0xd40 kthread+0x355/0x5b0 ret_from_fork+0x1d4/0x270 ret_from_fork_asm+0x11/0x20
Last potentially related work creation: kasan_save_stack+0x30/0x50 kasan_record_aux_stack+0x8c/0xa0 kvfree_call_rcu+0x93/0x5b0 mlxsw_sp_router_neigh_event_work+0x67d/0x860 process_one_work+0xd57/0x1390 worker_thread+0x4d6/0xd40 kthread+0x355/0x5b0 ret_from_fork+0x1d4/0x270 ret_from_fork_asm+0x11/0x20(CVE-2025-68801)
In the Linux kernel, the following vulnerability has been resolved:
svcrdma: bound check rq_pages index in inline path
svc_rdma_copy_inline_range indexed rqstp->rq_pages[rc_curpage] without verifying rc_curpage stays within the allocated page array. Add guards before the first use and after advancing to a new page.(CVE-2025-71068)
In the Linux kernel, the following vulnerability has been resolved:
iavf: fix off-by-one issues in iavf_config_rss_reg()
There are off-by-one bugs when configuring RSS hash key and lookup table, causing out-of-bounds reads to memory [1] and out-of-bounds writes to device registers.
Before commit 43a3d9ba34c9 ("i40evf: Allow PF driver to configure RSS"), the loop upper bounds were: i <= I40E_VFQF_{HKEY,HLUT}_MAX_INDEX which is safe since the value is the last valid index.
That commit changed the bounds to:
i <= adapter->rss_{key,lut}_size / 4
where rss_{key,lut}_size / 4 is the number of dwords, so the last
valid index is (rss_{key,lut}_size / 4) - 1. Therefore, using <=
accesses one element past the end.
Fix the issues by using < instead of <=, ensuring we do not exceed
the bounds.
[1] KASAN splat about rss_key_size off-by-one BUG: KASAN: slab-out-of-bounds in iavf_config_rss+0x619/0x800 Read of size 4 at addr ffff888102c50134 by task kworker/u8:6/63
CPU: 0 UID: 0 PID: 63 Comm: kworker/u8:6 Not tainted 6.18.0-rc2-enjuk-tnguy-00378-g3005f5b77652-dirty #156 PREEMPT(voluntary) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Workqueue: iavf iavf_watchdog_task Call Trace: <TASK> dump_stack_lvl+0x6f/0xb0 print_report+0x170/0x4f3 kasan_report+0xe1/0x1a0 iavf_config_rss+0x619/0x800 iavf_watchdog_task+0x2be7/0x3230 process_one_work+0x7fd/0x1420 worker_thread+0x4d1/0xd40 kthread+0x344/0x660 ret_from_fork+0x249/0x320 ret_from_fork_asm+0x1a/0x30 </TASK>
Allocated by task 63: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x7f/0x90 __kmalloc_noprof+0x246/0x6f0 iavf_watchdog_task+0x28fc/0x3230 process_one_work+0x7fd/0x1420 worker_thread+0x4d1/0xd40 kthread+0x344/0x660 ret_from_fork+0x249/0x320 ret_from_fork_asm+0x1a/0x30
The buggy address belongs to the object at ffff888102c50100 which belongs to the cache kmalloc-64 of size 64 The buggy address is located 0 bytes to the right of allocated 52-byte region [ffff888102c50100, ffff888102c50134)
The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x102c50 flags: 0x200000000000000(node=0|zone=2) page_type: f5(slab) raw: 0200000000000000 ffff8881000418c0 dead000000000122 0000000000000000 raw: 0000000000000000 0000000080200020 00000000f5000000 0000000000000000 page dumped because: kasan: bad access detected
Memory state around the buggy address: ffff888102c50000: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc ffff888102c50080: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc >ffff888102c50100: 00 00 00 00 00 00 04 fc fc fc fc fc fc fc fc fc ^ ffff888102c50180: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc ffff888102c50200: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc(CVE-2025-71087)
In the Linux kernel, the following vulnerability has been resolved:
drm/i915/gem: Zero-initialize the eb.vma array in i915_gem_do_execbuffer
Initialize the eb.vma array with values of 0 when the eb structure is first set up. In particular, this sets the eb->vma[i].vma pointers to NULL, simplifying cleanup and getting rid of the bug described below.
During the execution of eb_lookup_vmas(), the eb->vma array is successively filled up with struct eb_vma objects. This process includes calling eb_add_vma(), which might fail; however, even in the event of failure, eb->vma[i].vma is set for the currently processed buffer.
If eb_add_vma() fails, eb_lookup_vmas() returns with an error, which prompts a call to eb_release_vmas() to clean up the mess. Since eb_lookup_vmas() might fail during processing any (possibly not first) buffer, eb_release_vmas() checks whether a buffer's vma is NULL to know at what point did the lookup function fail.
In eb_lookup_vmas(), eb->vma[i].vma is set to NULL if either the helper function eb_lookup_vma() or eb_validate_vma() fails. eb->vma[i+1].vma is set to NULL in case i915_gem_object_userptr_submit_init() fails; the current one needs to be cleaned up by eb_release_vmas() at this point, so the next one is set. If eb_add_vma() fails, neither the current nor the next vma is set to NULL, which is a source of a NULL deref bug described in the issue linked in the Closes tag.
When entering eb_lookup_vmas(), the vma pointers are set to the slab poison value, instead of NULL. This doesn't matter for the actual lookup, since it gets overwritten anyway, however the eb_release_vmas() function only recognizes NULL as the stopping value, hence the pointers are being set to NULL as they go in case of intermediate failure. This patch changes the approach to filling them all with NULL at the start instead, rather than handling that manually during failure.
(cherry picked from commit 08889b706d4f0b8d2352b7ca29c2d8df4d0787cd)(CVE-2025-71130)
In the Linux kernel, the following vulnerability has been resolved:
net: dsa: properly keep track of conduit reference
Problem description
DSA has a mumbo-jumbo of reference handling of the conduit net device and its kobject which, sadly, is just wrong and doesn't make sense.
There are two distinct problems.
- The OF path, which uses of_find_net_device_by_node(), never releases the elevated refcount on the conduit's kobject. Nominally, the OF and non-OF paths should result in objects having identical reference counts taken, and it is already suspicious that dsa_dev_to_net_device() has a put_device() call which is missing in dsa_port_parse_of(), but we can actually even verify that an issue exists. With CONFIG_DEBUG_KOBJECT_RELEASE=y, if we run this command "before" and "after" applying this patch:
(unbind the conduit driver for net device eno2) echo 0000:00:00.2 > /sys/bus/pci/drivers/fsl_enetc/unbind
we see these lines in the output diff which appear only with the patch applied:
kobject: 'eno2' (ffff002009a3a6b8): kobject_release, parent 0000000000000000 (delayed 1000) kobject: '109' (ffff0020099d59a0): kobject_release, parent 0000000000000000 (delayed 1000)
- After we find the conduit interface one way (OF) or another (non-OF), it can get unregistered at any time, and DSA remains with a long-lived, but in this case stale, cpu_dp->conduit pointer. Holding the net device's underlying kobject isn't actually of much help, it just prevents it from being freed (but we never need that kobject directly). What helps us to prevent the net device from being unregistered is the parallel netdev reference mechanism (dev_hold() and dev_put()).
Actually we actually use that netdev tracker mechanism implicitly on user ports since commit 2f1e8ea726e9 ("net: dsa: link interfaces with the DSA master to get rid of lockdep warnings"), via netdev_upper_dev_link(). But time still passes at DSA switch probe time between the initial of_find_net_device_by_node() code and the user port creation time, time during which the conduit could unregister itself and DSA wouldn't know about it.
So we have to run of_find_net_device_by_node() under rtnl_lock() to prevent that from happening, and release the lock only with the netdev tracker having acquired the reference.
Do we need to keep the reference until dsa_unregister_switch() / dsa_switch_shutdown()? 1: Maybe yes. A switch device will still be registered even if all user ports failed to probe, see commit 86f8b1c01a0a ("net: dsa: Do not make user port errors fatal"), and the cpu_dp->conduit pointers remain valid. I haven't audited all call paths to see whether they will actually use the conduit in lack of any user port, but if they do, it seems safer to not rely on user ports for that reference. 2. Definitely yes. We support changing the conduit which a user port is associated to, and we can get into a situation where we've moved all user ports away from a conduit, thus no longer hold any reference to it via the net device tracker. But we shouldn't let it go nonetheless - see the next change in relation to dsa_tree_find_first_conduit() and LAG conduits which disappear. We have to be prepared to return to the physical conduit, so the CPU port must explicitly keep another reference to it. This is also to say: the user ports and their CPU ports may not always keep a reference to the same conduit net device, and both are needed.
As for the conduit's kobject for the /sys/class/net/ entry, we don't care about it, we can release it as soon as we hold the net device object itself.
History and blame attribution
The code has been refactored so many times, it is very difficult to follow and properly attribute a blame, but I'll try to make a short history which I hope to be correct.
We have two distinct probing paths: - one for OF, introduced in 2016 i ---truncated---(CVE-2025-71152)
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix deadlock in wait_current_trans() due to ignored transaction type
When wait_current_trans() is called during start_transaction(), it currently waits for a blocked transaction without considering whether the given transaction type actually needs to wait for that particular transaction state. The btrfs_blocked_trans_types[] array already defines which transaction types should wait for which transaction states, but this check was missing in wait_current_trans().
This can lead to a deadlock scenario involving two transactions and pending ordered extents:
-
Transaction A is in TRANS_STATE_COMMIT_DOING state
-
A worker processing an ordered extent calls start_transaction() with TRANS_JOIN
-
join_transaction() returns -EBUSY because Transaction A is in TRANS_STATE_COMMIT_DOING
-
Transaction A moves to TRANS_STATE_UNBLOCKED and completes
-
A new Transaction B is created (TRANS_STATE_RUNNING)
-
The ordered extent from step 2 is added to Transaction B's pending ordered extents
-
Transaction B immediately starts commit by another task and enters TRANS_STATE_COMMIT_START
-
The worker finally reaches wait_current_trans(), sees Transaction B in TRANS_STATE_COMMIT_START (a blocked state), and waits unconditionally
-
However, TRANS_JOIN should NOT wait for TRANS_STATE_COMMIT_START according to btrfs_blocked_trans_types[]
-
Transaction B is waiting for pending ordered extents to complete
-
Deadlock: Transaction B waits for ordered extent, ordered extent waits for Transaction B
This can be illustrated by the following call stacks: CPU0 CPU1 btrfs_finish_ordered_io() start_transaction(TRANS_JOIN) join_transaction() # -EBUSY (Transaction A is # TRANS_STATE_COMMIT_DOING) # Transaction A completes # Transaction B created # ordered extent added to # Transaction B's pending list btrfs_commit_transaction() # Transaction B enters # TRANS_STATE_COMMIT_START # waiting for pending ordered # extents wait_current_trans() # waits for Transaction B # (should not wait!)
Task bstore_kv_sync in btrfs_commit_transaction waiting for ordered extents:
__schedule+0x2e7/0x8a0 schedule+0x64/0xe0 btrfs_commit_transaction+0xbf7/0xda0 [btrfs] btrfs_sync_file+0x342/0x4d0 [btrfs] __x64_sys_fdatasync+0x4b/0x80 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9
Task kworker in wait_current_trans waiting for transaction commit:
Workqueue: btrfs-syno_nocow btrfs_work_helper [btrfs] __schedule+0x2e7/0x8a0 schedule+0x64/0xe0 wait_current_trans+0xb0/0x110 [btrfs] start_transaction+0x346/0x5b0 [btrfs] btrfs_finish_ordered_io.isra.0+0x49b/0x9c0 [btrfs] btrfs_work_helper+0xe8/0x350 [btrfs] process_one_work+0x1d3/0x3c0 worker_thread+0x4d/0x3e0 kthread+0x12d/0x150 ret_from_fork+0x1f/0x30
Fix this by passing the transaction type to wait_current_trans() and checking btrfs_blocked_trans_types[cur_trans->state] against the given type before deciding to wait. This ensures that transaction types which are allowed to join during certain blocked states will not unnecessarily wait and cause deadlocks.(CVE-2025-71194)
In the Linux kernel, the following vulnerability has been resolved:
macvlan: fix possible UAF in macvlan_forward_source()
Add RCU protection on (struct macvlan_source_entry)->vlan.
Whenever macvlan_hash_del_source() is called, we must clear entry->vlan pointer before RCU grace period starts.
This allows macvlan_forward_source() to skip over entries queued for freeing.
Note that macvlan_dev are already RCU protected, as they are embedded in a standard netdev (netdev_priv(ndev)).
https: //lore.kernel.org/netdev/(CVE-2026-23001)
In the Linux kernel, the following vulnerability has been resolved:
ipv4: ip_gre: make ipgre_header() robust
Analog to commit db5b4e39c4e6 ("ip6_gre: make ip6gre_header() robust")
Over the years, syzbot found many ways to crash the kernel in ipgre_header() [1].
This involves team or bonding drivers ability to dynamically change their dev->needed_headroom and/or dev->hard_header_len
In this particular crash mld_newpack() allocated an skb with a too small reserve/headroom, and by the time mld_sendpack() was called, syzbot managed to attach an ipgre device.
[1] skbuff: skb_under_panic: text:ffffffff89ea3cb7 len:2030915468 put:2030915372 head:ffff888058b43000 data:ffff887fdfa6e194 tail:0x120 end:0x6c0 dev:team0 kernel BUG at net/core/skbuff.c:213 ! Oops: invalid opcode: 0000 [#1] SMP KASAN PTI CPU: 1 UID: 0 PID: 1322 Comm: kworker/1:9 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025 Workqueue: mld mld_ifc_work RIP: 0010:skb_panic+0x157/0x160 net/core/skbuff.c:213 Call Trace: <TASK> skb_under_panic net/core/skbuff.c:223 [inline] skb_push+0xc3/0xe0 net/core/skbuff.c:2641 ipgre_header+0x67/0x290 net/ipv4/ip_gre.c:897 dev_hard_header include/linux/netdevice.h:3436 [inline] neigh_connected_output+0x286/0x460 net/core/neighbour.c:1618 NF_HOOK_COND include/linux/netfilter.h:307 [inline] ip6_output+0x340/0x550 net/ipv6/ip6_output.c:247 NF_HOOK+0x9e/0x380 include/linux/netfilter.h:318 mld_sendpack+0x8d4/0xe60 net/ipv6/mcast.c:1855 mld_send_cr net/ipv6/mcast.c:2154 [inline] mld_ifc_work+0x83e/0xd60 net/ipv6/mcast.c:2693 process_one_work kernel/workqueue.c:3257 [inline] process_scheduled_works+0xad1/0x1770 kernel/workqueue.c:3340 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3421 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x510/0xa50 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246(CVE-2026-23011)
In the Linux kernel, the following vulnerability has been resolved:
mm/page_alloc: prevent pcp corruption with SMP=n
The kernel test robot has reported:
BUG: spinlock trylock failure on UP on CPU#0, kcompactd0/28 lock: 0xffff888807e35ef0, .magic: dead4ead, .owner: kcompactd0/28, .owner_cpu: 0 CPU: 0 UID: 0 PID: 28 Comm: kcompactd0 Not tainted 6.18.0-rc5-00127-ga06157804399 #1 PREEMPT 8cc09ef94dcec767faa911515ce9e609c45db470 Call Trace: <IRQ> __dump_stack (lib/dump_stack.c:95) dump_stack_lvl (lib/dump_stack.c:123) dump_stack (lib/dump_stack.c:130) spin_dump (kernel/locking/spinlock_debug.c:71) do_raw_spin_trylock (kernel/locking/spinlock_debug.c:?) _raw_spin_trylock (include/linux/spinlock_api_smp.h:89 kernel/locking/spinlock.c:138) __free_frozen_pages (mm/page_alloc.c:2973) freepages (mm/page_alloc.c:5295) free_pages (mm/page_alloc.c:5334) tlb_remove_table_rcu (include/linux/mm.h:? include/linux/mm.h:3122 include/asm-generic/tlb.h:220 mm/mmu_gather.c:227 mm/mmu_gather.c:290) ? __cfi_tlb_remove_table_rcu (mm/mmu_gather.c:289) ? rcu_core (kernel/rcu/tree.c:?) rcu_core (include/linux/rcupdate.h:341 kernel/rcu/tree.c:2607 kernel/rcu/tree.c:2861) rcu_core_si (kernel/rcu/tree.c:2879) handle_softirqs (arch/x86/include/asm/jump_label.h:36 include/trace/events/irq.h:142 kernel/softirq.c:623) __irq_exit_rcu (arch/x86/include/asm/jump_label.h:36 kernel/softirq.c:725) irq_exit_rcu (kernel/softirq.c:741) sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1052) </IRQ> <TASK> RIP: 0010:_raw_spin_unlock_irqrestore (arch/x86/include/asm/preempt.h:95 include/linux/spinlock_api_smp.h:152 kernel/locking/spinlock.c:194) free_pcppages_bulk (mm/page_alloc.c:1494) drain_pages_zone (include/linux/spinlock.h:391 mm/page_alloc.c:2632) __drain_all_pages (mm/page_alloc.c:2731) drain_all_pages (mm/page_alloc.c:2747) kcompactd (mm/compaction.c:3115) kthread (kernel/kthread.c:465) ? __cfi_kcompactd (mm/compaction.c:3166) ? __cfi_kthread (kernel/kthread.c:412) ret_from_fork (arch/x86/kernel/process.c:164) ? __cfi_kthread (kernel/kthread.c:412) ret_from_fork_asm (arch/x86/entry/entry_64.S:255) </TASK>
Matthew has analyzed the report and identified that in drain_page_zone() we are in a section protected by spin_lock(&pcp->lock) and then get an interrupt that attempts spin_trylock() on the same lock. The code is designed to work this way without disabling IRQs and occasionally fail the trylock with a fallback. However, the SMP=n spinlock implementation assumes spin_trylock() will always succeed, and thus it's normally a no-op. Here the enabled lock debugging catches the problem, but otherwise it could cause a corruption of the pcp structure.
The problem has been introduced by commit 574907741599 ("mm/page_alloc: leave IRQs enabled for per-cpu page allocations"). The pcp locking scheme recognizes the need for disabling IRQs to prevent nesting spin_trylock() sections on SMP=n, but the need to prevent the nesting in spin_lock() has not been recognized. Fix it by introducing local wrappers that change the spin_lock() to spin_lock_iqsave() with SMP=n and use them in all places that do spin_lock(&pcp->lock).
[(CVE-2026-23025)
In the Linux kernel, the following vulnerability has been resolved:
net: hv_netvsc: reject RSS hash key programming without RX indirection table
RSS configuration requires a valid RX indirection table. When the device reports a single receive queue, rndis_filter_device_add() does not allocate an indirection table, accepting RSS hash key updates in this state leads to a hang.
Fix this by gating netvsc_set_rxfh() on ndc->rx_table_sz and return -EOPNOTSUPP when the table is absent. This aligns set_rxfh with the device capabilities and prevents incorrect behavior.(CVE-2026-23054)
In the Linux kernel, the following vulnerability has been resolved:
net/sched: Enforce that teql can only be used as root qdisc
Design intent of teql is that it is only supposed to be used as root qdisc. We need to check for that constraint.
Although not important, I will describe the scenario that unearthed this issue for the curious.
GangMin Kim <(CVE-2026-23074)
In the Linux kernel, the following vulnerability has been resolved:
mm/hugetlb: fix hugetlb_pmd_shared()
Patch series "mm/hugetlb: fixes for PMD table sharing (incl. using mmu_gather)", v3.
One functional fix, one performance regression fix, and two related comment fixes.
I cleaned up my prototype I recently shared [1] for the performance fix, deferring most of the cleanups I had in the prototype to a later point. While doing that I identified the other things.
The goal of this patch set is to be backported to stable trees "fairly" easily. At least patch #1 and #4.
Patch #1 fixes hugetlb_pmd_shared() not detecting any sharing Patch #2 + #3 are simple comment fixes that patch #4 interacts with. Patch #4 is a fix for the reported performance regression due to excessive IPI broadcasts during fork()+exit().
The last patch is all about TLB flushes, IPIs and mmu_gather. Read: complicated
There are plenty of cleanups in the future to be had + one reasonable optimization on x86. But that's all out of scope for this series.
Runtime tested, with a focus on fixing the performance regression using the original reproducer [2] on x86.
This patch (of 4):
We switched from (wrongly) using the page count to an independent shared count. Now, shared page tables have a refcount of 1 (excluding speculative references) and instead use ptdesc->pt_share_count to identify sharing.
We didn't convert hugetlb_pmd_shared(), so right now, we would never detect a shared PMD table as such, because sharing/unsharing no longer touches the refcount of a PMD table.
Page migration, like mbind() or migrate_pages() would allow for migrating folios mapped into such shared PMD tables, even though the folios are not exclusive. In smaps we would account them as "private" although they are "shared", and we would be wrongly setting the PM_MMAP_EXCLUSIVE in the pagemap interface.
Fix it by properly using ptdesc_pmd_is_shared() in hugetlb_pmd_shared().(CVE-2026-23100)
In the Linux kernel, the following vulnerability has been resolved:
tracing: Add recursion protection in kernel stack trace recording
A bug was reported about an infinite recursion caused by tracing the rcu events with the kernel stack trace trigger enabled. The stack trace code called back into RCU which then called the stack trace again.
Expand the ftrace recursion protection to add a set of bits to protect events from recursion. Each bit represents the context that the event is in (normal, softirq, interrupt and NMI).
Have the stack trace code use the interrupt context to protect against recursion.
Note, the bug showed an issue in both the RCU code as well as the tracing stacktrace code. This only handles the tracing stack trace side of the bug. The RCU fix will be handled separately.(CVE-2026-23138)
In the Linux kernel, the following vulnerability has been resolved:
tcp: secure_seq: add back ports to TS offset
This reverts 28ee1b746f49 ("secure_seq: downgrade to per-host timestamp offsets")
tcp_tw_recycle went away in 2017.
Zhouyan Deng reported off-path TCP source port leakage via SYN cookie side-channel that can be fixed in multiple ways.
One of them is to bring back TCP ports in TS offset randomization.
As a bonus, we perform a single siphash() computation to provide both an ISN and a TS offset.(CVE-2026-23247)
In the Linux kernel, a vulnerability exists in the AppArmor module's unpack_pdb function. The vulnerability occurs due to failure to validate that DFA start states are within bounds, which can lead to out-of-bound reads. An attacker can exploit this vulnerability through specially crafted policy files, potentially leading to information disclosure or system crashes.(CVE-2026-23269)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: unconditionally bump set->nelems before insertion
In case that the set is full, a new element gets published then removed without waiting for the RCU grace period, while RCU reader can be walking over it already.
To address this issue, add the element transaction even if set is full, but toggle the set_full flag to report -ENFILE so the abort path safely unwinds the set to its previous state.
As for element updates, decrement set->nelems to restore it.
A simpler fix is to call synchronize_rcu() in the error path. However, with a large batch adding elements to already maxed-out set, this could cause noticeable slowdown of such batches.(CVE-2026-23272)
In the Linux kernel, the following vulnerability has been resolved:
net: usb: kaweth: validate USB endpoints
The kaweth driver should validate that the device it is probing has the proper number and types of USB endpoints it is expecting before it binds to it. If a malicious device were to not have the same urbs the driver will crash later on when it blindly accesses these endpoints.(CVE-2026-23312)
In the Linux kernel, the following vulnerability has been resolved:
net: sched: avoid qdisc_reset_all_tx_gt() vs dequeue race for lockless qdiscs
When shrinking the number of real tx queues, netif_set_real_num_tx_queues() calls qdisc_reset_all_tx_gt() to flush qdiscs for queues which will no longer be used.
qdisc_reset_all_tx_gt() currently serializes qdisc_reset() with qdisc_lock(). However, for lockless qdiscs, the dequeue path is serialized by qdisc_run_begin/end() using qdisc->seqlock instead, so qdisc_reset() can run concurrently with __qdisc_run() and free skbs while they are still being dequeued, leading to UAF.
This can easily be reproduced on e.g. virtio-net by imposing heavy traffic while frequently changing the number of queue pairs:
iperf3 -ub0 -c $peer -t 0 & while :; do ethtool -L eth0 combined 1 ethtool -L eth0 combined 2 done
With KASAN enabled, this leads to reports like:
BUG: KASAN: slab-use-after-free in __qdisc_run+0x133f/0x1760 ... Call Trace: <TASK> ... __qdisc_run+0x133f/0x1760 __dev_queue_xmit+0x248f/0x3550 ip_finish_output2+0xa42/0x2110 ip_output+0x1a7/0x410 ip_send_skb+0x2e6/0x480 udp_send_skb+0xb0a/0x1590 udp_sendmsg+0x13c9/0x1fc0 ... </TASK>
Allocated by task 1270 on cpu 5 at 44.558414s: ... alloc_skb_with_frags+0x84/0x7c0 sock_alloc_send_pskb+0x69a/0x830 __ip_append_data+0x1b86/0x48c0 ip_make_skb+0x1e8/0x2b0 udp_sendmsg+0x13a6/0x1fc0 ...
Freed by task 1306 on cpu 3 at 44.558445s: ... kmem_cache_free+0x117/0x5e0 pfifo_fast_reset+0x14d/0x580 qdisc_reset+0x9e/0x5f0 netif_set_real_num_tx_queues+0x303/0x840 virtnet_set_channels+0x1bf/0x260 [virtio_net] ethnl_set_channels+0x684/0xae0 ethnl_default_set_doit+0x31a/0x890 ...
Serialize qdisc_reset_all_tx_gt() against the lockless dequeue path by taking qdisc->seqlock for TCQ_F_NOLOCK qdiscs, matching the serialization model already used by dev_reset_queue().
Additionally clear QDISC_STATE_NON_EMPTY after reset so the qdisc state reflects an empty queue, avoiding needless re-scheduling.(CVE-2026-23340)
In the Linux kernel, the following vulnerability has been resolved:
net/sched: act_ife: Fix metalist update behavior
Whenever an ife action replace changes the metalist, instead of replacing the old data on the metalist, the current ife code is appending the new metadata. Aside from being innapropriate behavior, this may lead to an unbounded addition of metadata to the metalist which might cause an out of bounds error when running the encode op:
[ 138.423369][ C1] ================================================================== [ 138.424317][ C1] BUG: KASAN: slab-out-of-bounds in ife_tlv_meta_encode (net/ife/ife.c:168) [ 138.424906][ C1] Write of size 4 at addr ffff8880077f4ffe by task ife_out_out_bou/255 [ 138.425778][ C1] CPU: 1 UID: 0 PID: 255 Comm: ife_out_out_bou Not tainted 7.0.0-rc1-00169-gfbdfa8da05b6 #624 PREEMPT(full) [ 138.425795][ C1] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 138.425800][ C1] Call Trace: [ 138.425804][ C1] <IRQ> [ 138.425808][ C1] dump_stack_lvl (lib/dump_stack.c:122) [ 138.425828][ C1] print_report (mm/kasan/report.c:379 mm/kasan/report.c:482) [ 138.425839][ C1] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 138.425844][ C1] ? __virt_addr_valid (./arch/x86/include/asm/preempt.h:95 (discriminator 1) ./include/linux/rcupdate.h:975 (discriminator 1) ./include/linux/mmzone.h:2207 (discriminator 1) arch/x86/mm/physaddr.c:54 (discriminator 1)) [ 138.425853][ C1] ? ife_tlv_meta_encode (net/ife/ife.c:168) [ 138.425859][ C1] kasan_report (mm/kasan/report.c:221 mm/kasan/report.c:597) [ 138.425868][ C1] ? ife_tlv_meta_encode (net/ife/ife.c:168) [ 138.425878][ C1] kasan_check_range (mm/kasan/generic.c:186 (discriminator 1) mm/kasan/generic.c:200 (discriminator 1)) [ 138.425884][ C1] __asan_memset (mm/kasan/shadow.c:84 (discriminator 2)) [ 138.425889][ C1] ife_tlv_meta_encode (net/ife/ife.c:168) [ 138.425893][ C1] ? ife_tlv_meta_encode (net/ife/ife.c:171) [ 138.425898][ C1] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 138.425903][ C1] ife_encode_meta_u16 (net/sched/act_ife.c:57) [ 138.425910][ C1] ? __pfx_do_raw_spin_lock (kernel/locking/spinlock_debug.c:114) [ 138.425916][ C1] ? __asan_memcpy (mm/kasan/shadow.c:105 (discriminator 3)) [ 138.425921][ C1] ? __pfx_ife_encode_meta_u16 (net/sched/act_ife.c:45) [ 138.425927][ C1] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 138.425931][ C1] tcf_ife_act (net/sched/act_ife.c:847 net/sched/act_ife.c:879)
To solve this issue, fix the replace behavior by adding the metalist to the ife rcu data structure.(CVE-2026-23378)
In the Linux kernel, the following vulnerability has been resolved:
ice: Fix memory leak in ice_set_ringparam()
In ice_set_ringparam, tx_rings and xdp_rings are allocated before rx_rings. If the allocation of rx_rings fails, the code jumps to the done label leaking both tx_rings and xdp_rings. Furthermore, if the setup of an individual Rx ring fails during the loop, the code jumps to the free_tx label which releases tx_rings but leaks xdp_rings.
Fix this by introducing a free_xdp label and updating the error paths to ensure both xdp_rings and tx_rings are properly freed if rx_rings allocation or setup fails.
Compile tested only. Issue found using a prototype static analysis tool and code review.(CVE-2026-23389)
In the Linux kernel, the following vulnerability has been resolved:
apparmor: fix side-effect bug in match_char() macro usage
The match_char() macro evaluates its character parameter multiple times when traversing differential encoding chains. When invoked with *str++, the string pointer advances on each iteration of the inner do-while loop, causing the DFA to check different characters at each iteration and therefore skip input characters. This results in out-of-bounds reads when the pointer advances past the input buffer boundary.
[ 94.984676] ================================================================== [ 94.985301] BUG: KASAN: slab-out-of-bounds in aa_dfa_match+0x5ae/0x760 [ 94.985655] Read of size 1 at addr ffff888100342000 by task file/976
[ 94.986319] CPU: 7 UID: 1000 PID: 976 Comm: file Not tainted 6.19.0-rc7-next-20260127 #1 PREEMPT(lazy) [ 94.986322] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 94.986329] Call Trace: [ 94.986341] <TASK> [ 94.986347] dump_stack_lvl+0x5e/0x80 [ 94.986374] print_report+0xc8/0x270 [ 94.986384] ? aa_dfa_match+0x5ae/0x760 [ 94.986388] kasan_report+0x118/0x150 [ 94.986401] ? aa_dfa_match+0x5ae/0x760 [ 94.986405] aa_dfa_match+0x5ae/0x760 [ 94.986408] __aa_path_perm+0x131/0x400 [ 94.986418] aa_path_perm+0x219/0x2f0 [ 94.986424] apparmor_file_open+0x345/0x570 [ 94.986431] security_file_open+0x5c/0x140 [ 94.986442] do_dentry_open+0x2f6/0x1120 [ 94.986450] vfs_open+0x38/0x2b0 [ 94.986453] ? may_open+0x1e2/0x2b0 [ 94.986466] path_openat+0x231b/0x2b30 [ 94.986469] ? __x64_sys_openat+0xf8/0x130 [ 94.986477] do_file_open+0x19d/0x360 [ 94.986487] do_sys_openat2+0x98/0x100 [ 94.986491] __x64_sys_openat+0xf8/0x130 [ 94.986499] do_syscall_64+0x8e/0x660 [ 94.986515] ? count_memcg_events+0x15f/0x3c0 [ 94.986526] ? srso_alias_return_thunk+0x5/0xfbef5 [ 94.986540] ? handle_mm_fault+0x1639/0x1ef0 [ 94.986551] ? vma_start_read+0xf0/0x320 [ 94.986558] ? srso_alias_return_thunk+0x5/0xfbef5 [ 94.986561] ? srso_alias_return_thunk+0x5/0xfbef5 [ 94.986563] ? fpregs_assert_state_consistent+0x50/0xe0 [ 94.986572] ? srso_alias_return_thunk+0x5/0xfbef5 [ 94.986574] ? arch_exit_to_user_mode_prepare+0x9/0xb0 [ 94.986587] ? srso_alias_return_thunk+0x5/0xfbef5 [ 94.986588] ? irqentry_exit+0x3c/0x590 [ 94.986595] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 94.986597] RIP: 0033:0x7fda4a79c3ea
Fix by extracting the character value before invoking match_char, ensuring single evaluation per outer loop.(CVE-2026-23406)
In the Linux kernel, the following vulnerability has been resolved:
apparmor: fix missing bounds check on DEFAULT table in verify_dfa()
The verify_dfa() function only checks DEFAULT_TABLE bounds when the state is not differentially encoded.
When the verification loop traverses the differential encoding chain, it reads k = DEFAULT_TABLE[j] and uses k as an array index without validation. A malformed DFA with DEFAULT_TABLE[j] >= state_count, therefore, causes both out-of-bounds reads and writes.
[ 57.179855] ================================================================== [ 57.180549] BUG: KASAN: slab-out-of-bounds in verify_dfa+0x59a/0x660 [ 57.180904] Read of size 4 at addr ffff888100eadec4 by task su/993
[ 57.181554] CPU: 1 UID: 0 PID: 993 Comm: su Not tainted 6.19.0-rc7-next-20260127 #1 PREEMPT(lazy) [ 57.181558] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 57.181563] Call Trace: [ 57.181572] <TASK> [ 57.181577] dump_stack_lvl+0x5e/0x80 [ 57.181596] print_report+0xc8/0x270 [ 57.181605] ? verify_dfa+0x59a/0x660 [ 57.181608] kasan_report+0x118/0x150 [ 57.181620] ? verify_dfa+0x59a/0x660 [ 57.181623] verify_dfa+0x59a/0x660 [ 57.181627] aa_dfa_unpack+0x1610/0x1740 [ 57.181629] ? __kmalloc_cache_noprof+0x1d0/0x470 [ 57.181640] unpack_pdb+0x86d/0x46b0 [ 57.181647] ? srso_alias_return_thunk+0x5/0xfbef5 [ 57.181653] ? srso_alias_return_thunk+0x5/0xfbef5 [ 57.181656] ? aa_unpack_nameX+0x1a8/0x300 [ 57.181659] aa_unpack+0x20b0/0x4c30 [ 57.181662] ? srso_alias_return_thunk+0x5/0xfbef5 [ 57.181664] ? stack_depot_save_flags+0x33/0x700 [ 57.181681] ? kasan_save_track+0x4f/0x80 [ 57.181683] ? kasan_save_track+0x3e/0x80 [ 57.181686] ? __kasan_kmalloc+0x93/0xb0 [ 57.181688] ? __kvmalloc_node_noprof+0x44a/0x780 [ 57.181693] ? aa_simple_write_to_buffer+0x54/0x130 [ 57.181697] ? policy_update+0x154/0x330 [ 57.181704] aa_replace_profiles+0x15a/0x1dd0 [ 57.181707] ? srso_alias_return_thunk+0x5/0xfbef5 [ 57.181710] ? __kvmalloc_node_noprof+0x44a/0x780 [ 57.181712] ? aa_loaddata_alloc+0x77/0x140 [ 57.181715] ? srso_alias_return_thunk+0x5/0xfbef5 [ 57.181717] ? _copy_from_user+0x2a/0x70 [ 57.181730] policy_update+0x17a/0x330 [ 57.181733] profile_replace+0x153/0x1a0 [ 57.181735] ? rw_verify_area+0x93/0x2d0 [ 57.181740] vfs_write+0x235/0xab0 [ 57.181745] ksys_write+0xb0/0x170 [ 57.181748] do_syscall_64+0x8e/0x660 [ 57.181762] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 57.181765] RIP: 0033:0x7f6192792eb2
Remove the MATCH_FLAG_DIFF_ENCODE condition to validate all DEFAULT_TABLE entries unconditionally.(CVE-2026-23407)
A race condition vulnerability exists in the AppArmor security module of the Linux kernel, leading to a use-after-free issue. This vulnerability can be triggered when an attacker simultaneously opens rawdata files and removes an associated AppArmor profile. Since rawdata inodes are not refcounted, there is a time window during profile removal where the i_private pointer may reference freed memory, causing the system to access freed memory regions. This can result in program crashes, unexpected value usage, or arbitrary code execution, threatening the confidentiality, integrity, and availability of the system.(CVE-2026-23410)
A vulnerability exists in the AppArmor security module of the Linux kernel when handling the i_private field of the inode structure. AppArmor was putting the reference to i_private data on its end after removing the original entry from the file system. However the inode can and does live beyond that point and it is possible that some of the fs callback functions will be invoked after the reference has been put, which results in a race between freeing the data and accessing it through the fs. While the rawdata/loaddata is the most likely candidate to fail the race, as it has the fewest references. If properly crafted it might be possible to trigger a race for the other types stored in i_private. This vulnerability could allow a local attacker to bypass AppArmor's access control policies through a specially crafted request, leading to privilege escalation and impacting system confidentiality, integrity, and availability.(CVE-2026-23411)
In the Linux kernel, the following vulnerability has been resolved:
udp_tunnel: fix NULL deref caused by udp_sock_create6 when CONFIG_IPV6=n
When CONFIG_IPV6 is disabled, the udp_sock_create6() function returns 0 (success) without actually creating a socket. Callers such as fou_create() then proceed to dereference the uninitialized socket pointer, resulting in a NULL pointer dereference.
The captured NULL deref crash: BUG: kernel NULL pointer dereference, address: 0000000000000018 RIP: 0010:fou_nl_add_doit (net/ipv4/fou_core.c:590 net/ipv4/fou_core.c:764) [...] Call Trace: <TASK> genl_family_rcv_msg_doit.constprop.0 (net/netlink/genetlink.c:1114) genl_rcv_msg (net/netlink/genetlink.c:1194 net/netlink/genetlink.c:1209) [...] netlink_rcv_skb (net/netlink/af_netlink.c:2550) genl_rcv (net/netlink/genetlink.c:1219) netlink_unicast (net/netlink/af_netlink.c:1319 net/netlink/af_netlink.c:1344) netlink_sendmsg (net/netlink/af_netlink.c:1894) __sock_sendmsg (net/socket.c:727 (discriminator 1) net/socket.c:742 (discriminator 1)) __sys_sendto (./include/linux/file.h:62 (discriminator 1) ./include/linux/file.h:83 (discriminator 1) net/socket.c:2183 (discriminator 1)) __x64_sys_sendto (net/socket.c:2213 (discriminator 1) net/socket.c:2209 (discriminator 1) net/socket.c:2209 (discriminator 1)) do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1) arch/x86/entry/syscall_64.c:94 (discriminator 1)) entry_SYSCALL_64_after_hwframe (net/arch/x86/entry/entry_64.S:130)
This patch makes udp_sock_create6 return -EPFNOSUPPORT instead, so callers correctly take their error paths. There is only one caller of the vulnerable function and only privileged users can trigger it.(CVE-2026-23439)
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Fix race condition during IPSec ESN update
In IPSec full offload mode, the device reports an ESN (Extended Sequence Number) wrap event to the driver. The driver validates this event by querying the IPSec ASO and checking that the esn_event_arm field is 0x0, which indicates an event has occurred. After handling the event, the driver must re-arm the context by setting esn_event_arm back to 0x1.
A race condition exists in this handling path. After validating the event, the driver calls mlx5_accel_esp_modify_xfrm() to update the kernel's xfrm state. This function temporarily releases and re-acquires the xfrm state lock.
So, need to acknowledge the event first by setting esn_event_arm to 0x1. This prevents the driver from reprocessing the same ESN update if the hardware sends events for other reason. Since the next ESN update only occurs after nearly 2^31 packets are received, there's no risk of missing an update, as it will happen long after this handling has finished.
Processing the event twice causes the ESN high-order bits (esn_msb) to be incremented incorrectly. The driver then programs the hardware with this invalid ESN state, which leads to anti-replay failures and a complete halt of IPSec traffic.
Fix this by re-arming the ESN event immediately after it is validated, before calling mlx5_accel_esp_modify_xfrm(). This ensures that any spurious, duplicate events are correctly ignored, closing the race window.(CVE-2026-23440)
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Prevent concurrent access to IPSec ASO context
The query or updating IPSec offload object is through Access ASO WQE. The driver uses a single mlx5e_ipsec_aso struct for each PF, which contains a shared DMA-mapped context for all ASO operations.
A race condition exists because the ASO spinlock is released before the hardware has finished processing WQE. If a second operation is initiated immediately after, it overwrites the shared context in the DMA area.
When the first operation's completion is processed later, it reads this corrupted context, leading to unexpected behavior and incorrect results.
This commit fixes the race by introducing a private context within each IPSec offload object. The shared ASO context is now copied to this private context while the ASO spinlock is held. Subsequent processing uses this saved, per-object context, ensuring its integrity is maintained.(CVE-2026-23441)
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: always free skb on ieee80211_tx_prepare_skb() failure
ieee80211_tx_prepare_skb() has three error paths, but only two of them free the skb. The first error path (ieee80211_tx_prepare() returning TX_DROP) does not free it, while invoke_tx_handlers() failure and the fragmentation check both do.
Add kfree_skb() to the first error path so all three are consistent, and remove the now-redundant frees in callers (ath9k, mt76, mac80211_hwsim) to avoid double-free.
Document the skb ownership guarantee in the function's kdoc.(CVE-2026-23444)
In the Linux kernel, the following vulnerability has been resolved:
net: usb: cdc_ncm: add ndpoffset to NDP16 nframes bounds check
cdc_ncm_rx_verify_ndp16() validates that the NDP header and its DPE entries fit within the skb. The first check correctly accounts for ndpoffset:
if ((ndpoffset + sizeof(struct usb_cdc_ncm_ndp16)) > skb_in->len)
but the second check omits it:
if ((sizeof(struct usb_cdc_ncm_ndp16) + ret * (sizeof(struct usb_cdc_ncm_dpe16))) > skb_in->len)
This validates the DPE array size against the total skb length as if the NDP were at offset 0, rather than at ndpoffset. When the NDP is placed near the end of the NTB (large wNdpIndex), the DPE entries can extend past the skb data buffer even though the check passes. cdc_ncm_rx_fixup() then reads out-of-bounds memory when iterating the DPE array.
Add ndpoffset to the nframes bounds check and use struct_size_t() to express the NDP-plus-DPE-array size more clearly.(CVE-2026-23448)
In the Linux kernel, the following vulnerability has been resolved:
net/smc: fix NULL dereference and UAF in smc_tcp_syn_recv_sock()
Syzkaller reported a panic in smc_tcp_syn_recv_sock() [1].
smc_tcp_syn_recv_sock() is called in the TCP receive path (softirq) via icsk_af_ops->syn_recv_sock on the clcsock (TCP listening socket). It reads sk_user_data to get the smc_sock pointer. However, when the SMC listen socket is being closed concurrently, smc_close_active() sets clcsock->sk_user_data to NULL under sk_callback_lock, and then the smc_sock itself can be freed via sock_put() in smc_release().
This leads to two issues:
1) NULL pointer dereference: sk_user_data is NULL when accessed. 2) Use-after-free: sk_user_data is read as non-NULL, but the smc_sock is freed before its fields (e.g., queued_smc_hs, ori_af_ops) are accessed.
The race window looks like this (the syzkaller crash [1] triggers via the SYN cookie path: tcp_get_cookie_sock() -> smc_tcp_syn_recv_sock(), but the normal tcp_check_req() path has the same race):
CPU A (softirq) CPU B (process ctx)
tcp_v4_rcv() TCP_NEW_SYN_RECV: sk = req->rsk_listener sock_hold(sk) / No lock on listener / smc_close_active(): write_lock_bh(cb_lock) sk_user_data = NULL write_unlock_bh(cb_lock) ... smc_clcsock_release() sock_put(smc->sk) x2 -> smc_sock freed! tcp_check_req() smc_tcp_syn_recv_sock(): smc = user_data(sk) -> NULL or dangling smc->queued_smc_hs -> crash!
Note that the clcsock and smc_sock are two independent objects with separate refcounts. TCP stack holds a reference on the clcsock, which keeps it alive, but this does NOT prevent the smc_sock from being freed.
Fix this by using RCU and refcount_inc_not_zero() to safely access smc_sock. Since smc_tcp_syn_recv_sock() is called in the TCP three-way handshake path, taking read_lock_bh on sk_callback_lock is too heavy and would not survive a SYN flood attack. Using rcu_read_lock() is much more lightweight.
- Set SOCK_RCU_FREE on the SMC listen socket so that smc_sock freeing is deferred until after the RCU grace period. This guarantees the memory is still valid when accessed inside rcu_read_lock().
- Use rcu_read_lock() to protect reading sk_user_data.
- Use refcount_inc_not_zero(&smc->sk.sk_refcnt) to pin the smc_sock. If the refcount has already reached zero (close path completed), it returns false and we bail out safely.
Note: smc_hs_congested() has a similar lockless read of sk_user_data without rcu_read_lock(), but it only checks for NULL and accesses the global smc_hs_wq, never dereferencing any smc_sock field, so it is not affected.
Reproducer was verified with mdelay injection and smc_run, the issue no longer occurs with this patch applied.
[1] https://syzkaller.appspot.com/bug?extid=827ae2bfb3a3529333e9(CVE-2026-23450)
In the Linux kernel, the following vulnerability has been resolved:
PM: runtime: Fix a race condition related to device removal
The following code in pm_runtime_work() may dereference the dev->parent pointer after the parent device has been freed:
/* Maybe the parent is now able to suspend. */
if (parent && !parent->power.ignore_children) {
spin_unlock(&dev->power.lock);
spin_lock(&parent->power.lock);
rpm_idle(parent, RPM_ASYNC);
spin_unlock(&parent->power.lock);
spin_lock(&dev->power.lock);
}
Fix this by inserting a flush_work() call in pm_runtime_remove().
Without this patch blktest block/001 triggers the following complaint sporadically:
BUG: KASAN: slab-use-after-free in lock_acquire+0x70/0x160 Read of size 1 at addr ffff88812bef7198 by task kworker/u553:1/3081 Workqueue: pm pm_runtime_work Call Trace: <TASK> dump_stack_lvl+0x61/0x80 print_address_description.constprop.0+0x8b/0x310 print_report+0xfd/0x1d7 kasan_report+0xd8/0x1d0 __kasan_check_byte+0x42/0x60 lock_acquire.part.0+0x38/0x230 lock_acquire+0x70/0x160 _raw_spin_lock+0x36/0x50 rpm_suspend+0xc6a/0xfe0 rpm_idle+0x578/0x770 pm_runtime_work+0xee/0x120 process_one_work+0xde3/0x1410 worker_thread+0x5eb/0xfe0 kthread+0x37b/0x480 ret_from_fork+0x6cb/0x920 ret_from_fork_asm+0x11/0x20 </TASK>
Allocated by task 4314: kasan_save_stack+0x2a/0x50 kasan_save_track+0x18/0x40 kasan_save_alloc_info+0x3d/0x50 __kasan_kmalloc+0xa0/0xb0 __kmalloc_noprof+0x311/0x990 scsi_alloc_target+0x122/0xb60 [scsi_mod] __scsi_scan_target+0x101/0x460 [scsi_mod] scsi_scan_channel+0x179/0x1c0 [scsi_mod] scsi_scan_host_selected+0x259/0x2d0 [scsi_mod] store_scan+0x2d2/0x390 [scsi_mod] dev_attr_store+0x43/0x80 sysfs_kf_write+0xde/0x140 kernfs_fop_write_iter+0x3ef/0x670 vfs_write+0x506/0x1470 ksys_write+0xfd/0x230 __x64_sys_write+0x76/0xc0 x64_sys_call+0x213/0x1810 do_syscall_64+0xee/0xfc0 entry_SYSCALL_64_after_hwframe+0x4b/0x53
Freed by task 4314: kasan_save_stack+0x2a/0x50 kasan_save_track+0x18/0x40 kasan_save_free_info+0x3f/0x50 __kasan_slab_free+0x67/0x80 kfree+0x225/0x6c0 scsi_target_dev_release+0x3d/0x60 [scsi_mod] device_release+0xa3/0x220 kobject_cleanup+0x105/0x3a0 kobject_put+0x72/0xd0 put_device+0x17/0x20 scsi_device_dev_release+0xacf/0x12c0 [scsi_mod] device_release+0xa3/0x220 kobject_cleanup+0x105/0x3a0 kobject_put+0x72/0xd0 put_device+0x17/0x20 scsi_device_put+0x7f/0xc0 [scsi_mod] sdev_store_delete+0xa5/0x120 [scsi_mod] dev_attr_store+0x43/0x80 sysfs_kf_write+0xde/0x140 kernfs_fop_write_iter+0x3ef/0x670 vfs_write+0x506/0x1470 ksys_write+0xfd/0x230 __x64_sys_write+0x76/0xc0 x64_sys_call+0x213/0x1810(CVE-2026-23452)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Fix use-after-free in l2cap_unregister_user
After commit ab4eedb790ca ("Bluetooth: L2CAP: Fix corrupted list in hci_chan_del"), l2cap_conn_del() uses conn->lock to protect access to conn->users. However, l2cap_register_user() and l2cap_unregister_user() don't use conn->lock, creating a race condition where these functions can access conn->users and conn->hchan concurrently with l2cap_conn_del().
This can lead to use-after-free and list corruption bugs, as reported by syzbot.
Fix this by changing l2cap_register_user() and l2cap_unregister_user() to use conn->lock instead of hci_dev_lock(), ensuring consistent locking for the l2cap_conn structure.(CVE-2026-23461)
Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2026-23473)
In the Linux kernel, the following vulnerability has been resolved:
spi: fix statistics allocation
The controller per-cpu statistics is not allocated until after the controller has been registered with driver core, which leaves a window where accessing the sysfs attributes can trigger a NULL-pointer dereference.
Fix this by moving the statistics allocation to controller allocation while tying its lifetime to that of the controller (rather than using implicit devres).(CVE-2026-23475)
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix krb5 mount with username option
Customer reported that some of their krb5 mounts were failing against a single server as the client was trying to mount the shares with wrong credentials. It turned out the client was reusing SMB session from first mount to try mounting the other shares, even though a different username= option had been specified to the other mounts.
By using username mount option along with sec=krb5 to search for principals from keytab is supported by cifs.upcall(8) since cifs-utils-4.8. So fix this by matching username mount option in match_session() even with Kerberos.
For example, the second mount below should fail with -ENOKEY as there is no 'foobar' principal in keytab (/etc/krb5.keytab). The client ends up reusing SMB session from first mount to perform the second one, which is wrong.
$ ktutil
ktutil: add_entry -password -p testuser -k 1 -e aes256-cts
Password for (CVE-2026-31392)
In the Linux kernel, the following vulnerability has been resolved:
mm/rmap: fix incorrect pte restoration for lazyfree folios
We batch unmap anonymous lazyfree folios by folio_unmap_pte_batch. If the
batch has a mix of writable and non-writable bits, we may end up setting
the entire batch writable. Fix this by respecting writable bit during
batching.
Although on a successful unmap of a lazyfree folio, the soft-dirty bit is
lost, preserve it on pte restoration by respecting the bit during
batching, to make the fix consistent w.r.t both writable bit and
soft-dirty bit.
I was able to write the below reproducer and crash the kernel.
Explanation of reproducer (set 64K mTHP to always):
Fault in a 64K large folio. Split the VMA at mid-point with
MADV_DONTFORK. fork() - parent points to the folio with 8 writable ptes
and 8 non-writable ptes. Merge the VMAs with MADV_DOFORK so that
folio_unmap_pte_batch() can determine all the 16 ptes as a batch. Do
MADV_FREE on the range to mark the folio as lazyfree. Write to the memory
to dirty the pte, eventually rmap will dirty the folio. Then trigger
reclaim, we will hit the pte restoration path, and the kernel will crash
with the trace given below.
The BUG happens at:
BUG_ON(atomic_inc_return(&ptc->anon_map_count) > 1 && rw);
The code path is asking for anonymous page to be mapped writable into the
pagetable. The BUG_ON() firing implies that such a writable page has been
mapped into the pagetables of more than one process, which breaks
anonymous memory/CoW semantics.
[ 21.134473] kernel BUG at mm/page_table_check.c:118!
[ 21.134497] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP
[ 21.135917] Modules linked in:
[ 21.136085] CPU: 1 UID: 0 PID: 1735 Comm: dup-lazyfree Not tainted 7.0.0-rc1-00116-g018018a17770 #1028 PREEMPT
[ 21.136858] Hardware name: linux,dummy-virt (DT)
[ 21.137019] pstate: 21400005 (nzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
[ 21.137308] pc : page_table_check_set+0x28c/0x2a8
[ 21.137607] lr : page_table_check_set+0x134/0x2a8
[ 21.137885] sp : ffff80008a3b3340
[ 21.138124] x29: ffff80008a3b3340 x28: fffffdffc3d14400 x27: ffffd1a55e03d000
[ 21.138623] x26: 0040000000000040 x25: ffffd1a55f7dd000 x24: 0000000000000001
[ 21.139045] x23: 0000000000000001 x22: 0000000000000001 x21: ffffd1a55f217f30
[ 21.139629] x20: 0000000000134521 x19: 0000000000134519 x18: 005c43e000040000
[ 21.140027] x17: 0001400000000000 x16: 0001700000000000 x15: 000000000000ffff
[ 21.140578] x14: 000000000000000c x13: 005c006000000000 x12: 0000000000000020
[ 21.140828] x11: 0000000000000000 x10: 005c000000000000 x9 : ffffd1a55c079ee0
[ 21.141077] x8 : 0000000000000001 x7 : 005c03e000040000 x6 : 000000004000ffff
[ 21.141490] x5 : ffff00017fffce00 x4 : 0000000000000001 x3 : 0000000000000002
[ 21.141741] x2 : 0000000000134510 x1 : 0000000000000000 x0 : ffff0000c08228c0
[ 21.141991] Call trace:
[ 21.142093] page_table_check_set+0x28c/0x2a8 (P)
[ 21.142265] __page_table_check_ptes_set+0x144/0x1e8
[ 21.142441] __set_ptes_anysz.constprop.0+0x160/0x1a8
[ 21.142766] contpte_set_ptes+0xe8/0x140
[ 21.142907] try_to_unmap_one+0x10c4/0x10d0
[ 21.143177] rmap_walk_anon+0x100/0x250
[ 21.143315] try_to_unmap+0xa0/0xc8
[ 21.143441] shrink_folio_list+0x59c/0x18a8
[ 21.143759] shrink_lruvec+0x664/0xbf0
[ 21.144043] shrink_node+0x218/0x878
[ 21.144285] __node_reclaim.constprop.0+0x98/0x338
[ 21.144763] user_proactive_reclaim+0x2a4/0x340
[ 21.145056] reclaim_store+0x3c/0x60
[ 21.145216] dev_attr_store+0x20/0x40
[ 21.145585] sysfs_kf_write+0x84/0xa8
[ 21.145835] kernfs_fop_write_iter+0x130/0x1c8
[ 21.145994] vfs_write+0x2b8/0x368
[ 21.146119] ksys_write+0x70/0x110
[ 21.146240] __arm64_sys_write+0x24/0x38
[ 21.146380] invoke_syscall+0x50/0x120
[ 21.146513] el0_svc_common.constprop.0+0x48/0xf8
[ 21.146679] do_el0_svc+0x28/0x40
[ 21.146798] el0_svc+0x34/0x110
[ 21.146926] el0t
---truncated---(CVE-2026-31398)
In the Linux kernel, the following vulnerability has been resolved:
nvdimm/bus: Fix potential use after free in asynchronous initialization
Dingisoul with KASAN reports a use after free if device_add() fails in
nd_async_device_register().
Commit b6eae0f61db2 ("libnvdimm: Hold reference on parent while
scheduling async init") correctly added a reference on the parent device
to be held until asynchronous initialization was complete. However, if
device_add() results in an allocation failure the ref count of the
device drops to 0 prior to the parent pointer being accessed. Thus
resulting in use after free.
The bug bot AI correctly identified the fix. Save a reference to the
parent pointer to be used to drop the parent reference regardless of the
outcome of device_add().(CVE-2026-31399)
In the Linux kernel, the following vulnerability has been resolved:
sunrpc: fix cache_request leak in cache_release
When a reader's file descriptor is closed while in the middle of reading
a cache_request (rp->offset != 0), cache_release() decrements the
request's readers count but never checks whether it should free the
request.
In cache_read(), when readers drops to 0 and CACHE_PENDING is clear, the
cache_request is removed from the queue and freed along with its buffer
and cache_head reference. cache_release() lacks this cleanup.
The only other path that frees requests with readers == 0 is
cache_dequeue(), but it runs only when CACHE_PENDING transitions from
set to clear. If that transition already happened while readers was
still non-zero, cache_dequeue() will have skipped the request, and no
subsequent call will clean it up.
Add the same cleanup logic from cache_read() to cache_release(): after
decrementing readers, check if it reached 0 with CACHE_PENDING clear,
and if so, dequeue and free the cache_request.(CVE-2026-31400)
In the Linux kernel, the following vulnerability has been resolved:
NFSD: Hold net reference for the lifetime of /proc/fs/nfs/exports fd
The /proc/fs/nfs/exports proc entry is created at module init
and persists for the module's lifetime. exports_proc_open()
captures the caller's current network namespace and stores
its svc_export_cache in seq->private, but takes no reference
on the namespace. If the namespace is subsequently torn down
(e.g. container destruction after the opener does setns() to a
different namespace), nfsd_net_exit() calls nfsd_export_shutdown()
which frees the cache. Subsequent reads on the still-open fd
dereference the freed cache_detail, walking a freed hash table.
Hold a reference on the struct net for the lifetime of the open
file descriptor. This prevents nfsd_net_exit() from running --
and thus prevents nfsd_export_shutdown() from freeing the cache
-- while any exports fd is open. cache_detail already stores
its net pointer (cd->net, set by cache_create_net()), so
exports_release() can retrieve it without additional per-file
storage.(CVE-2026-31403)
In the Linux kernel, the Bluetooth SCO module's sco_recv_frame() function contains a use-after-free vulnerability. The function reads conn->sk under sco_conn_lock() but immediately releases the lock without holding a reference to the socket. A concurrent close() operation can free the socket between the lock release and the subsequent sk->sk_state access, resulting in a use-after-free vulnerability. Other functions in the same file (sco_sock_timeout(), sco_conn_del()) correctly use sco_sock_hold() to safely hold references under the lock. The vulnerability is fixed by using sco_sock_hold() to acquire a reference before releasing the lock and adding sock_put() on all exit paths.(CVE-2026-31408)
In the Linux kernel, the following vulnerability has been resolved:
net/sched: cls_fw: fix NULL pointer dereference on shared blocks
The old-method path in fw_classify() calls tcf_block_q() and
dereferences q->handle. Shared blocks leave block->q NULL, causing a
NULL deref when an empty cls_fw filter is attached to a shared block
and a packet with a nonzero major skb mark is classified.
Reject the configuration in fw_change() when the old method (no
TCA_OPTIONS) is used on a shared block, since fw_classify()'s
old-method path needs block->q which is NULL for shared blocks.
The fixed null-ptr-deref calling stack:
KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f]
RIP: 0010:fw_classify (net/sched/cls_fw.c:81)
Call Trace:
tcf_classify (./include/net/tc_wrapper.h:197 net/sched/cls_api.c:1764 net/sched/cls_api.c:1860)
tc_run (net/core/dev.c:4401)
__dev_queue_xmit (net/core/dev.c:4535 net/core/dev.c:4790)(CVE-2026-31421)
In the Linux kernel, the following vulnerability has been resolved:
net/sched: cls_flow: fix NULL pointer dereference on shared blocks
flow_change() calls tcf_block_q() and dereferences q->handle to derive
a default baseclass. Shared blocks leave block->q NULL, causing a NULL
deref when a flow filter without a fully qualified baseclass is created
on a shared block.
Check tcf_block_shared() before accessing block->q and return -EINVAL
for shared blocks. This avoids the null-deref shown below:
=======================================================================
KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f]
RIP: 0010:flow_change (net/sched/cls_flow.c:508)
Call Trace:
tc_new_tfilter (net/sched/cls_api.c:2432)
rtnetlink_rcv_msg (net/core/rtnetlink.c:6980)
[...]
=======================================================================(CVE-2026-31422)
In the Linux kernel, the following vulnerability has been resolved:
ACPI: EC: clean up handlers on probe failure in acpi_ec_setup()
When ec_install_handlers() returns -EPROBE_DEFER on reduced-hardware
platforms, it has already started the EC and installed the address
space handler with the struct acpi_ec pointer as handler context.
However, acpi_ec_setup() propagates the error without any cleanup.
The caller acpi_ec_add() then frees the struct acpi_ec for non-boot
instances, leaving a dangling handler context in ACPICA.
Any subsequent AML evaluation that accesses an EC OpRegion field
dispatches into acpi_ec_space_handler() with the freed pointer,
causing a use-after-free:
BUG: KASAN: slab-use-after-free in mutex_lock (kernel/locking/mutex.c:289)
Write of size 8 at addr ffff88800721de38 by task init/1
Call Trace:
<TASK>
mutex_lock (kernel/locking/mutex.c:289)
acpi_ec_space_handler (drivers/acpi/ec.c:1362)
acpi_ev_address_space_dispatch (drivers/acpi/acpica/evregion.c:293)
acpi_ex_access_region (drivers/acpi/acpica/exfldio.c:246)
acpi_ex_field_datum_io (drivers/acpi/acpica/exfldio.c:509)
acpi_ex_extract_from_field (drivers/acpi/acpica/exfldio.c:700)
acpi_ex_read_data_from_field (drivers/acpi/acpica/exfield.c:327)
acpi_ex_resolve_node_to_value (drivers/acpi/acpica/exresolv.c:392)
</TASK>
Allocated by task 1:
acpi_ec_alloc (drivers/acpi/ec.c:1424)
acpi_ec_add (drivers/acpi/ec.c:1692)
Freed by task 1:
kfree (mm/slub.c:6876)
acpi_ec_add (drivers/acpi/ec.c:1751)
The bug triggers on reduced-hardware EC platforms (ec->gpe < 0)
when the GPIO IRQ provider defers probing. Once the stale handler
exists, any unprivileged sysfs read that causes AML to touch an
EC OpRegion (battery, thermal, backlight) exercises the dangling
pointer.
Fix this by calling ec_remove_handlers() in the error path of
acpi_ec_setup() before clearing first_ec. ec_remove_handlers()
checks each EC_FLAGS_* bit before acting, so it is safe to call
regardless of how far ec_install_handlers() progressed:
-ENODEV (handler not installed): only calls acpi_ec_stop()
-EPROBE_DEFER (handler installed): removes handler, stops EC(CVE-2026-31426)
In the Linux kernel, the following vulnerability has been resolved:
net: skb: fix cross-cache free of KFENCE-allocated skb head
SKB_SMALL_HEAD_CACHE_SIZE is intentionally set to a non-power-of-2
value (e.g. 704 on x86_64) to avoid collisions with generic kmalloc
bucket sizes. This ensures that skb_kfree_head() can reliably use
skb_end_offset to distinguish skb heads allocated from
skb_small_head_cache vs. generic kmalloc caches.
However, when KFENCE is enabled, kfence_ksize() returns the exact
requested allocation size instead of the slab bucket size. If a caller
(e.g. bpf_test_init) allocates skb head data via kzalloc() and the
requested size happens to equal SKB_SMALL_HEAD_CACHE_SIZE, then
slab_build_skb() -> ksize() returns that exact value. After subtracting
skb_shared_info overhead, skb_end_offset ends up matching
SKB_SMALL_HEAD_HEADROOM, causing skb_kfree_head() to incorrectly free
the object to skb_small_head_cache instead of back to the original
kmalloc cache, resulting in a slab cross-cache free:
kmem_cache_free(skbuff_small_head): Wrong slab cache. Expected
skbuff_small_head but got kmalloc-1k
Fix this by always calling kfree(head) in skb_kfree_head(). This keeps
the free path generic and avoids allocator-specific misclassification
for KFENCE objects.(CVE-2026-31429)
In the Linux kernel, the following vulnerability has been resolved:
X.509: Fix out-of-bounds access when parsing extensions
Leo reports an out-of-bounds access when parsing a certificate with
empty Basic Constraints or Key Usage extension because the first byte of
the extension is read before checking its length. Fix it.
The bug can be triggered by an unprivileged user by submitting a
specially crafted certificate to the kernel through the keyrings(7) API.
Leo has demonstrated this with a proof-of-concept program responsibly
disclosed off-list.(CVE-2026-31430)
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: idxd: Fix memory leak when a wq is reset
idxd_wq_disable_cleanup() which is called from the reset path for a
workqueue, sets the wq type to NONE, which for other parts of the
driver mean that the wq is empty (all its resources were released).
Only set the wq type to NONE after its resources are released.(CVE-2026-31441)
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: idxd: Fix possible invalid memory access after FLR
In the case that the first Function Level Reset (FLR) concludes
correctly, but in the second FLR the scratch area for the saved
configuration cannot be allocated, it's possible for a invalid memory
access to happen.
Always set the deallocated scratch area to NULL after FLR completes.(CVE-2026-31442)
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix use-after-free in update_super_work when racing with umount
Commit b98535d09179 ("ext4: fix bug_on in start_this_handle during umount
filesystem") moved ext4_unregister_sysfs() before flushing s_sb_upd_work
to prevent new error work from being queued via /proc/fs/ext4/xx/mb_groups
reads during unmount. However, this introduced a use-after-free because
update_super_work calls ext4_notify_error_sysfs() -> sysfs_notify() which
accesses the kobject's kernfs_node after it has been freed by kobject_del()
in ext4_unregister_sysfs():
update_super_work ext4_put_super
----------------- --------------
ext4_unregister_sysfs(sb)
kobject_del(&sbi->s_kobj)
__kobject_del()
sysfs_remove_dir()
kobj->sd = NULL
sysfs_put(sd)
kernfs_put() // RCU free
ext4_notify_error_sysfs(sbi)
sysfs_notify(&sbi->s_kobj)
kn = kobj->sd // stale pointer
kernfs_get(kn) // UAF on freed kernfs_node
ext4_journal_destroy()
flush_work(&sbi->s_sb_upd_work)
Instead of reordering the teardown sequence, fix this by making
ext4_notify_error_sysfs() detect that sysfs has already been torn down
by checking s_kobj.state_in_sysfs, and skipping the sysfs_notify() call
in that case. A dedicated mutex (s_error_notify_mutex) serializes
ext4_notify_error_sysfs() against kobject_del() in ext4_unregister_sysfs()
to prevent TOCTOU races where the kobject could be deleted between the
state_in_sysfs check and the sysfs_notify() call.(CVE-2026-31446)
In the Linux kernel, the following vulnerability has been resolved:
ext4: validate p_idx bounds in ext4_ext_correct_indexes
ext4_ext_correct_indexes() walks up the extent tree correcting
index entries when the first extent in a leaf is modified. Before
accessing path[k].p_idx->ei_block, there is no validation that
p_idx falls within the valid range of index entries for that
level.
If the on-disk extent header contains a corrupted or crafted
eh_entries value, p_idx can point past the end of the allocated
buffer, causing a slab-out-of-bounds read.
Fix this by validating path[k].p_idx against EXT_LAST_INDEX() at
both access sites: before the while loop and inside it. Return
-EFSCORRUPTED if the index pointer is out of range, consistent
with how other bounds violations are handled in the ext4 extent
tree code.(CVE-2026-31449)
In the Linux kernel, the following vulnerability has been resolved:
ext4: publish jinode after initialization
ext4_inode_attach_jinode() publishes ei->jinode to concurrent users.
It used to set ei->jinode before jbd2_journal_init_jbd_inode(),
allowing a reader to observe a non-NULL jinode with i_vfs_inode
still unset.
The fast commit flush path can then pass this jinode to
jbd2_wait_inode_data(), which dereferences i_vfs_inode->i_mapping and
may crash.
Below is the crash I observe:
BUG: unable to handle page fault for address: 000000010beb47f4 PGD 110e51067 P4D 110e51067 PUD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 1 UID: 0 PID: 4850 Comm: fc_fsync_bench_ Not tainted 6.18.0-00764-g795a690c06a5 #1 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.17.0-2-2 04/01/2014 RIP: 0010:xas_find_marked+0x3d/0x2e0 Code: e0 03 48 83 f8 02 0f 84 f0 01 00 00 48 8b 47 08 48 89 c3 48 39 c6 0f 82 fd 01 00 00 48 85 c9 74 3d 48 83 f9 03 77 63 4c 8b 0f <49> 8b 71 08 48 c7 47 18 00 00 00 00 48 89 f1 83 e1 03 48 83 f9 02 RSP: 0018:ffffbbee806e7bf0 EFLAGS: 00010246 RAX: 000000000010beb4 RBX: 000000000010beb4 RCX: 0000000000000003 RDX: 0000000000000001 RSI: 0000002000300000 RDI: ffffbbee806e7c10 RBP: 0000000000000001 R08: 0000002000300000 R09: 000000010beb47ec R10: ffff9ea494590090 R11: 0000000000000000 R12: 0000002000300000 R13: ffffbbee806e7c90 R14: ffff9ea494513788 R15: ffffbbee806e7c88 FS: 00007fc2f9e3e6c0(0000) GS:ffff9ea6b1444000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000010beb47f4 CR3: 0000000119ac5000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: <TASK> filemap_get_folios_tag+0x87/0x2a0 __filemap_fdatawait_range+0x5f/0xd0 ? srso_alias_return_thunk+0x5/0xfbef5 ? __schedule+0x3e7/0x10c0 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 ? preempt_count_sub+0x5f/0x80 ? srso_alias_return_thunk+0x5/0xfbef5 ? cap_safe_nice+0x37/0x70 ? srso_alias_return_thunk+0x5/0xfbef5 ? preempt_count_sub+0x5f/0x80 ? srso_alias_return_thunk+0x5/0xfbef5 filemap_fdatawait_range_keep_errors+0x12/0x40 ext4_fc_commit+0x697/0x8b0 ? ext4_file_write_iter+0x64b/0x950 ? srso_alias_return_thunk+0x5/0xfbef5 ? preempt_count_sub+0x5f/0x80 ? srso_alias_return_thunk+0x5/0xfbef5 ? vfs_write+0x356/0x480 ? srso_alias_return_thunk+0x5/0xfbef5 ? preempt_count_sub+0x5f/0x80 ext4_sync_file+0xf7/0x370 do_fsync+0x3b/0x80 ? syscall_trace_enter+0x108/0x1d0 __x64_sys_fdatasync+0x16/0x20 do_syscall_64+0x62/0x2c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e ... ```
Fix this by initializing the jbd2_inode first. Use smp_wmb() and WRITE_ONCE() to publish ei->jinode after initialization. Readers use READ_ONCE() to fetch the pointer.(CVE-2026-31450)
In the Linux kernel, the following vulnerability has been resolved:
ext4: replace BUG_ON with proper error handling in ext4_read_inline_folio
Replace BUG_ON() with proper error handling when inline data size exceeds PAGE_SIZE. This prevents kernel panic and allows the system to continue running while properly reporting the filesystem corruption.
The error is logged via ext4_error_inode(), the buffer head is released to prevent memory leak, and -EFSCORRUPTED is returned to indicate filesystem corruption.(CVE-2026-31451)
In the Linux kernel, the following vulnerability has been resolved:
ext4: convert inline data to extents when truncate exceeds inline size
Add a check in ext4_setattr() to convert files from inline data storage to extent-based storage when truncate() grows the file size beyond the inline capacity. This prevents the filesystem from entering an inconsistent state where the inline data flag is set but the file size exceeds what can be stored inline.
Without this fix, the following sequence causes a kernel BUG_ON():
- Mount filesystem with inode that has inline flag set and small size
- truncate(file, 50MB) - grows size but inline flag remains set
- sendfile() attempts to write data
- ext4_write_inline_data() hits BUG_ON(write_size > inline_capacity)
The crash occurs because ext4_write_inline_data() expects inline storage to accommodate the write, but the actual inline capacity (~60 bytes for i_block + ~96 bytes for xattrs) is far smaller than the file size and write request.
The fix checks if the new size from setattr exceeds the inode's actual inline capacity (EXT4_I(inode)->i_inline_size) and converts the file to extent-based storage before proceeding with the size change.
This addresses the root cause by ensuring the inline data flag and file size remain consistent during truncate operations.(CVE-2026-31452)
In the Linux kernel, the following vulnerability has been resolved:
erofs: add GFP_NOIO in the bio completion if needed
The bio completion path in the process context (e.g. dm-verity) will directly call into decompression rather than trigger another workqueue context for minimal scheduling latencies, which can then call vm_map_ram() with GFP_KERNEL.
Due to insufficient memory, vm_map_ram() may generate memory swapping I/O, which can cause submit_bio_wait to deadlock in some scenarios.
Trimmed down the call stack, as follows:
f2fs_submit_read_io submit_bio //bio_list is initialized. mmc_blk_mq_recovery z_erofs_endio vm_map_ram __pte_alloc_kernel __alloc_pages_direct_reclaim shrink_folio_list __swap_writepage submit_bio_wait //bio_list is non-NULL, hang!!!
Use memalloc_noio_{save,restore}() to wrap up this path.(CVE-2026-31467)
In the Linux kernel, the following vulnerability has been resolved:
virtio_net: Fix UAF on dst_ops when IFF_XMIT_DST_RELEASE is cleared and napi_tx is false
A UAF issue occurs when the virtio_net driver is configured with napi_tx=N and the device's IFF_XMIT_DST_RELEASE flag is cleared (e.g., during the configuration of tc route filter rules).
When IFF_XMIT_DST_RELEASE is removed from the net_device, the network stack expects the driver to hold the reference to skb->dst until the packet is fully transmitted and freed. In virtio_net with napi_tx=N, skbs may remain in the virtio transmit ring for an extended period.
If the network namespace is destroyed while these skbs are still pending, the corresponding dst_ops structure has freed. When a subsequent packet is transmitted, free_old_xmit() is triggered to clean up old skbs. It then calls dst_release() on the skb associated with the stale dst_entry. Since the dst_ops (referenced by the dst_entry) has already been freed, a UAF kernel paging request occurs.
fix it by adds skb_dst_drop(skb) in start_xmit to explicitly release the dst reference before the skb is queued in virtio_net.
Call Trace: Unable to handle kernel paging request at virtual address ffff80007e150000 CPU: 2 UID: 0 PID: 6236 Comm: ping Kdump: loaded Not tainted 7.0.0-rc1+ #6 PREEMPT ... percpu_counter_add_batch+0x3c/0x158 lib/percpu_counter.c:98 (P) dst_release+0xe0/0x110 net/core/dst.c:177 skb_release_head_state+0xe8/0x108 net/core/skbuff.c:1177 sk_skb_reason_drop+0x54/0x2d8 net/core/skbuff.c:1255 dev_kfree_skb_any_reason+0x64/0x78 net/core/dev.c:3469 napi_consume_skb+0x1c4/0x3a0 net/core/skbuff.c:1527 __free_old_xmit+0x164/0x230 drivers/net/virtio_net.c:611 [virtio_net] free_old_xmit drivers/net/virtio_net.c:1081 [virtio_net] start_xmit+0x7c/0x530 drivers/net/virtio_net.c:3329 [virtio_net] ...
Reproduction Steps: NETDEV="enp3s0"
config_qdisc_route_filter() { tc qdisc del dev $NETDEV root tc qdisc add dev $NETDEV root handle 1: prio tc filter add dev $NETDEV parent 1:0 \ protocol ip prio 100 route to 100 flowid 1:1 ip route add 192.168.1.100/32 dev $NETDEV realm 100 }
test_ns() { ip netns add testns ip link set $NETDEV netns testns ip netns exec testns ifconfig $NETDEV 10.0.32.46/24 ip netns exec testns ping -c 1 10.0.32.1 ip netns del testns }
config_qdisc_route_filter
test_ns sleep 2 test_ns(CVE-2026-31469)
In the Linux kernel, the following vulnerability has been resolved:
spi: use generic driver_override infrastructure
When a driver is probed through __driver_attach(), the bus' match() callback is called without the device lock held, thus accessing the driver_override field without a lock, which can cause a UAF.
Fix this by using the driver-core driver_override infrastructure taking care of proper locking internally.
Note that calling match() from __driver_attach() without the device lock held is intentional. [1]
Also note that we do not enable the driver_override feature of struct bus_type, as SPI - in contrast to most other buses - passes "" to sysfs_emit() when the driver_override pointer is NULL. Thus, printing "\n" instead of "(null)\n".(CVE-2026-31487)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: ctnetlink: use netlink policy range checks
Replace manual range and mask validations with netlink policy annotations in ctnetlink code paths, so that the netlink core rejects invalid values early and can generate extack errors.
- CTA_PROTOINFO_TCP_STATE: reject values > TCP_CONNTRACK_SYN_SENT2 at policy level, removing the manual >= TCP_CONNTRACK_MAX check.
- CTA_PROTOINFO_TCP_WSCALE_ORIGINAL/REPLY: reject values > TCP_MAX_WSCALE (14). The normal TCP option parsing path already clamps to this value, but the ctnetlink path accepted 0-255, causing undefined behavior when used as a u32 shift count.
- CTA_FILTER_ORIG_FLAGS/REPLY_FLAGS: use NLA_POLICY_MASK with CTA_FILTER_F_ALL, removing the manual mask checks.
- CTA_EXPECT_FLAGS: use NLA_POLICY_MASK with NF_CT_EXPECT_MASK, adding a new mask define grouping all valid expect flags.
Extracted from a broader nf-next patch by Florian Westphal, scoped to ctnetlink for the fixes tree.(CVE-2026-31495)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_conntrack_expect: skip expectations in other netns via proc
Skip expectations that do not reside in this netns.
Similar to e77e6ff502ea ("netfilter: conntrack: do not dump other netns's conntrack entries via proc").(CVE-2026-31496)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Fix ERTM re-init and zero pdu_len infinite loop
l2cap_config_req() processes CONFIG_REQ for channels in BT_CONNECTED state to support L2CAP reconfiguration (e.g. MTU changes). However, since both CONF_INPUT_DONE and CONF_OUTPUT_DONE are already set from the initial configuration, the reconfiguration path falls through to l2cap_ertm_init(), which re-initializes tx_q, srej_q, srej_list, and retrans_list without freeing the previous allocations and sets chan->sdu to NULL without freeing the existing skb. This leaks all previously allocated ERTM resources.
Additionally, l2cap_parse_conf_req() does not validate the minimum value of remote_mps derived from the RFC max_pdu_size option. A zero value propagates to l2cap_segment_sdu() where pdu_len becomes zero, causing the while loop to never terminate since len is never decremented, exhausting all available memory.
Fix the double-init by skipping l2cap_ertm_init() and l2cap_chan_ready() when the channel is already in BT_CONNECTED state, while still allowing the reconfiguration parameters to be updated through l2cap_parse_conf_req(). Also add a pdu_len zero check in l2cap_segment_sdu() as a safeguard.(CVE-2026-31498)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Fix deadlock in l2cap_conn_del()
l2cap_conn_del() calls cancel_delayed_work_sync() for both info_timer and id_addr_timer while holding conn->lock. However, the work functions l2cap_info_timeout() and l2cap_conn_update_id_addr() both acquire conn->lock, creating a potential AB-BA deadlock if the work is already executing when l2cap_conn_del() takes the lock.
Move the work cancellations before acquiring conn->lock and use disable_delayed_work_sync() to additionally prevent the works from being rearmed after cancellation, consistent with the pattern used in hci_conn_del().(CVE-2026-31499)
In the Linux kernel, the following vulnerability has been resolved:
iavf: fix out-of-bounds writes in iavf_get_ethtool_stats()
iavf incorrectly uses real_num_tx_queues for ETH_SS_STATS. Since the value could change in runtime, we should use num_tx_queues instead.
Moreover iavf_get_ethtool_stats() uses num_active_queues while iavf_get_sset_count() and iavf_get_stat_strings() use real_num_tx_queues, which triggers out-of-bounds writes when we do "ethtool -L" and "ethtool -S" simultaneously [1].
For example when we change channels from 1 to 8, Thread 3 could be scheduled before Thread 2, and out-of-bounds writes could be triggered in Thread 3:
Thread 1 (ethtool -L) Thread 2 (work) Thread 3 (ethtool -S) iavf_set_channels() ... iavf_alloc_queues() -> num_active_queues = 8 iavf_schedule_finish_config() iavf_get_sset_count() real_num_tx_queues: 1 -> buffer for 1 queue iavf_get_ethtool_stats() num_active_queues: 8 -> out-of-bounds! iavf_finish_config() -> real_num_tx_queues = 8
Use immutable num_tx_queues in all related functions to avoid the issue.
[1] BUG: KASAN: vmalloc-out-of-bounds in iavf_add_one_ethtool_stat+0x200/0x270 Write of size 8 at addr ffffc900031c9080 by task ethtool/5800
CPU: 1 UID: 0 PID: 5800 Comm: ethtool Not tainted 6.19.0-enjuk-08403-g8137e3db7f1c #241 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x6f/0xb0 print_report+0x170/0x4f3 kasan_report+0xe1/0x180 iavf_add_one_ethtool_stat+0x200/0x270 iavf_get_ethtool_stats+0x14c/0x2e0 __dev_ethtool+0x3d0c/0x5830 dev_ethtool+0x12d/0x270 dev_ioctl+0x53c/0xe30 sock_do_ioctl+0x1a9/0x270 sock_ioctl+0x3d4/0x5e0 __x64_sys_ioctl+0x137/0x1c0 do_syscall_64+0xf3/0x690 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f7da0e6e36d ... </TASK>
The buggy address belongs to a 1-page vmalloc region starting at 0xffffc900031c9000 allocated at __dev_ethtool+0x3cc9/0x5830 The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff88813a013de0 pfn:0x13a013 flags: 0x200000000000000(node=0|zone=2) raw: 0200000000000000 0000000000000000 dead000000000122 0000000000000000 raw: ffff88813a013de0 0000000000000000 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected
Memory state around the buggy address: ffffc900031c8f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900031c9000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffffc900031c9080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc900031c9100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900031c9180: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8(CVE-2026-31505)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Fix null-ptr-deref on l2cap_sock_ready_cb
Before using sk pointer, check if it is null.
Fix the following:
KASAN: null-ptr-deref in range [0x0000000000000260-0x0000000000000267] CPU: 0 UID: 0 PID: 5985 Comm: kworker/0:5 Not tainted 7.0.0-rc4-00029-ga989fde763f4 #1 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-9.fc43 06/10/2025 Workqueue: events l2cap_info_timeout RIP: 0010:kasan_byte_accessible+0x12/0x30 Code: 79 ff ff ff 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 40 d6 48 c1 ef 03 48 b8 00 00 00 00 00 fc ff df <0f> b6 04 07 3c 08 0f 92 c0 c3 cc cce veth0_macvtap: entered promiscuous mode RSP: 0018:ffffc90006e0f808 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: ffffffff89746018 RCX: 0000000080000001 RDX: 0000000000000000 RSI: ffffffff89746018 RDI: 000000000000004c RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: dffffc0000000000 R11: ffffffff8aae3e70 R12: 0000000000000000 R13: 0000000000000260 R14: 0000000000000260 R15: 0000000000000001 FS: 0000000000000000(0000) GS:ffff8880983c2000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005582615a5008 CR3: 000000007007e000 CR4: 0000000000752ef0 PKRU: 55555554 Call Trace: <TASK> __kasan_check_byte+0x12/0x40 lock_acquire+0x79/0x2e0 lock_sock_nested+0x48/0x100 ? l2cap_sock_ready_cb+0x46/0x160 l2cap_sock_ready_cb+0x46/0x160 l2cap_conn_start+0x779/0xff0 ? __pfx_l2cap_conn_start+0x10/0x10 ? l2cap_info_timeout+0x60/0xa0 ? __pfxmutexlock+0x10/0x10 l2cap_info_timeout+0x68/0xa0 ? process_scheduled_works+0xa8d/0x18c0 process_scheduled_works+0xb6e/0x18c0 ? pfx_process_scheduled_works+0x10/0x10 ? assign_work+0x3d5/0x5e0 worker_thread+0xa53/0xfc0 kthread+0x388/0x470 ? __pfx_worker_thread+0x10/0x10 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x51e/0xb90 ? __pfx_ret_from_fork+0x10/0x10 veth1_macvtap: entered promiscuous mode ? __switch_to+0xc7d/0x1450 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> Modules linked in: ---[ end trace 0000000000000000 ]--- batman_adv: batadv0: Interface activated: batadv_slave_0 batman_adv: batadv0: Interface activated: batadv_slave_1 netdevsim netdevsim7 netdevsim0: set [1, 0] type 2 family 0 port 6081 - 0 netdevsim netdevsim7 netdevsim1: set [1, 0] type 2 family 0 port 6081 - 0 netdevsim netdevsim7 netdevsim2: set [1, 0] type 2 family 0 port 6081 - 0 netdevsim netdevsim7 netdevsim3: set [1, 0] type 2 family 0 port 6081 - 0 RIP: 0010:kasan_byte_accessible+0x12/0x30 Code: 79 ff ff ff 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 40 d6 48 c1 ef 03 48 b8 00 00 00 00 00 fc ff df <0f> b6 04 07 3c 08 0f 92 c0 c3 cc cce ieee80211 phy39: Selected rate control algorithm 'minstrel_ht' RSP: 0018:ffffc90006e0f808 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: ffffffff89746018 RCX: 0000000080000001 RDX: 0000000000000000 RSI: ffffffff89746018 RDI: 000000000000004c RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: dffffc0000000000 R11: ffffffff8aae3e70 R12: 0000000000000000 R13: 0000000000000260 R14: 0000000000000260 R15: 0000000000000001 FS: 0000000000000000(0000) GS:ffff8880983c2000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f7e16139e9c CR3: 000000000e74e000 CR4: 0000000000752ef0 PKRU: 55555554 Kernel panic - not syncing: Fatal exception(CVE-2026-31510)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: MGMT: Fix dangling pointer on mgmt_add_adv_patterns_monitor_complete
This fixes the condition checking so mgmt_pending_valid is executed whenever status != -ECANCELED otherwise calling mgmt_pending_free(cmd) would kfree(cmd) without unlinking it from the list first, leaving a dangling pointer. Any subsequent list traversal (e.g., mgmt_pending_foreach during __mgmt_power_off, or another mgmt_pending_valid call) would dereference freed memory.(CVE-2026-31511)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Validate PDU length before reading SDU length in l2cap_ecred_data_rcv()
l2cap_ecred_data_rcv() reads the SDU length field from skb->data using get_unaligned_le16() without first verifying that skb contains at least L2CAP_SDULEN_SIZE (2) bytes. When skb->len is less than 2, this reads past the valid data in the skb.
The ERTM reassembly path correctly calls pskb_may_pull() before reading the SDU length (l2cap_reassemble_sdu, L2CAP_SAR_START case). Apply the same validation to the Enhanced Credit Based Flow Control data path.(CVE-2026-31512)
In the Linux kernel, the following vulnerability has been resolved:
xfrm: prevent policy_hthresh.work from racing with netns teardown
A XFRM_MSG_NEWSPDINFO request can queue the per-net work item policy_hthresh.work onto the system workqueue.
The queued callback, xfrm_hash_rebuild(), retrieves the enclosing struct net via container_of(). If the net namespace is torn down before that work runs, the associated struct net may already have been freed, and xfrm_hash_rebuild() may then dereference stale memory.
xfrm_policy_fini() already flushes policy_hash_work during teardown, but it does not synchronize policy_hthresh.work.
Synchronize policy_hthresh.work in xfrm_policy_fini() as well, so the queued work cannot outlive the net namespace teardown and access a freed struct net.(CVE-2026-31516)
In the Linux kernel, the following vulnerability has been resolved:
esp: fix skb leak with espintcp and async crypto
When the TX queue for espintcp is full, esp_output_tail_tcp will return an error and not free the skb, because with synchronous crypto, the common xfrm output code will drop the packet for us.
With async crypto (esp_output_done), we need to drop the skb when esp_output_tail_tcp returns an error.(CVE-2026-31518)
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix undefined behavior in interpreter sdiv/smod for INT_MIN
The BPF interpreter's signed 32-bit division and modulo handlers use the kernel abs() macro on s32 operands. The abs() macro documentation (include/linux/math.h) explicitly states the result is undefined when the input is the type minimum. When DST contains S32_MIN (0x80000000), abs((s32)DST) triggers undefined behavior and returns S32_MIN unchanged on arm64/x86. This value is then sign-extended to u64 as 0xFFFFFFFF80000000, causing do_div() to compute the wrong result.
The verifier's abstract interpretation (scalar32_min_max_sdiv) computes the mathematically correct result for range tracking, creating a verifier/interpreter mismatch that can be exploited for out-of-bounds map value access.
Introduce abs_s32() which handles S32_MIN correctly by casting to u32 before negating, avoiding signed overflow entirely. Replace all 8 abs((s32)...) call sites in the interpreter's sdiv32/smod32 handlers.
s32 is the only affected case -- the s64 division/modulo handlers do not use abs().(CVE-2026-31525)
In the Linux kernel, the following vulnerability has been resolved:
perf: Make sure to use pmu_ctx->pmu for groups
Oliver reported that x86_pmu_del() ended up doing an out-of-bound memory access when group_sched_in() fails and needs to roll back.
This should be handled by the transaction callbacks, but he found that when the group leader is a software event, the transaction handlers of the wrong PMU are used. Despite the move_group case in perf_event_open() and group_sched_in() using pmu_ctx->pmu.
Turns out, inherit uses event->pmu to clone the events, effectively undoing the move_group case for all inherited contexts. Fix this by also making inherit use pmu_ctx->pmu, ensuring all inherited counters end up in the same pmu context.
Similarly, __perf_event_read() should use equally use pmu_ctx->pmu for the group case.(CVE-2026-31528)
In the Linux kernel, the following vulnerability has been resolved:
ipv4: nexthop: allocate skb dynamically in rtm_get_nexthop()
When querying a nexthop object via RTM_GETNEXTHOP, the kernel currently allocates a fixed-size skb using NLMSG_GOODSIZE. While sufficient for single nexthops and small Equal-Cost Multi-Path groups, this fixed allocation fails for large nexthop groups like 512 nexthops.
This results in the following warning splat:
WARNING: net/ipv4/nexthop.c:3395 at rtm_get_nexthop+0x176/0x1c0, CPU#20: rep/4608 [...] RIP: 0010:rtm_get_nexthop (net/ipv4/nexthop.c:3395) [...] Call Trace: <TASK> rtnetlink_rcv_msg (net/core/rtnetlink.c:6989) netlink_rcv_skb (net/netlink/af_netlink.c:2550) netlink_unicast (net/netlink/af_netlink.c:1319 net/netlink/af_netlink.c:1344) netlink_sendmsg (net/netlink/af_netlink.c:1894) _syssendmsg (net/socket.c:721 net/socket.c:736 net/socket.c:2585) _sys_sendmsg (net/socket.c:2641) __sys_sendmsg (net/socket.c:2671) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) </TASK>
Fix this by allocating the size dynamically using nh_nlmsg_size() and using nlmsg_new(), this is consistent with nexthop_notify() behavior. In addition, adjust nh_nlmsg_size_grp() so it calculates the size needed based on flags passed. While at it, also add the size of NHA_FDB for nexthop group size calculation as it was missing too.
This cannot be reproduced via iproute2 as the group size is currently limited and the command fails as follows:
addattr_l ERROR: message exceeded bound of 1048(CVE-2026-31531)
In the Linux kernel, the following vulnerability has been resolved:
can: raw: fix ro->uniq use-after-free in raw_rcv()
raw_release() unregisters raw CAN receive filters via can_rx_unregister(), but receiver deletion is deferred with call_rcu(). This leaves a window where raw_rcv() may still be running in an RCU read-side critical section after raw_release() frees ro->uniq, leading to a use-after-free of the percpu uniq storage.
Move free_percpu(ro->uniq) out of raw_release() and into a raw-specific socket destructor. can_rx_unregister() takes an extra reference to the socket and only drops it from the RCU callback, so freeing uniq from sk_destruct ensures the percpu area is not released until the relevant callbacks have drained.
In the Linux kernel, the following vulnerability has been resolved:
net/tls: fix use-after-free in -EBUSY error path of tls_do_encryption
The -EBUSY handling in tls_do_encryption(), introduced by commit 859054147318 ("net: tls: handle backlogging of crypto requests"), has a use-after-free due to double cleanup of encrypt_pending and the scatterlist entry.
When crypto_aead_encrypt() returns -EBUSY, the request is enqueued to the cryptd backlog and the async callback tls_encrypt_done() will be invoked upon completion. That callback unconditionally restores the scatterlist entry (sge->offset, sge->length) and decrements ctx->encrypt_pending. However, if tls_encrypt_async_wait() returns an error, the synchronous error path in tls_do_encryption() performs the same cleanup again, double-decrementing encrypt_pending and double-restoring the scatterlist.
The double-decrement corrupts the encrypt_pending sentinel (initialized to 1), making tls_encrypt_async_wait() permanently skip the wait for pending async callbacks. A subsequent sendmsg can then free the tls_rec via bpf_exec_tx_verdict() while a cryptd callback is still pending, resulting in a use-after-free when the callback fires on the freed record.
Fix this by skipping the synchronous cleanup when the -EBUSY async wait returns an error, since the callback has already handled encrypt_pending and sge restoration.(CVE-2026-31533)
In the Linux kernel, the following vulnerability has been resolved:
drm/i915/gt: Check set_default_submission() before deferencing
When the i915 driver firmware binaries are not present, the set_default_submission pointer is not set. This pointer is dereferenced during suspend anyways.
Add a check to make sure it is set before dereferencing.
[ 23.289926] PM: suspend entry (deep) [ 23.293558] Filesystems sync: 0.000 seconds [ 23.298010] Freezing user space processes [ 23.302771] Freezing user space processes completed (elapsed 0.000 seconds) [ 23.309766] OOM killer disabled. [ 23.313027] Freezing remaining freezable tasks [ 23.318540] Freezing remaining freezable tasks completed (elapsed 0.001 seconds) [ 23.342038] serial 00:05: disabled [ 23.345719] serial 00:02: disabled [ 23.349342] serial 00:01: disabled [ 23.353782] sd 0:0:0:0: [sda] Synchronizing SCSI cache [ 23.358993] sd 1:0:0:0: [sdb] Synchronizing SCSI cache [ 23.361635] ata1.00: Entering standby power mode [ 23.368863] ata2.00: Entering standby power mode [ 23.445187] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 23.452194] #PF: supervisor instruction fetch in kernel mode [ 23.457896] #PF: error_code(0x0010) - not-present page [ 23.463065] PGD 0 P4D 0 [ 23.465640] Oops: Oops: 0010 [#1] SMP NOPTI [ 23.469869] CPU: 8 UID: 0 PID: 211 Comm: kworker/u48:18 Tainted: G S W 6.19.0-rc4-00020-gf0b9d8eb98df #10 PREEMPT(voluntary) [ 23.482512] Tainted: [S]=CPU_OUT_OF_SPEC, [W]=WARN [ 23.496511] Workqueue: async async_run_entry_fn [ 23.501087] RIP: 0010:0x0 [ 23.503755] Code: Unable to access opcode bytes at 0xffffffffffffffd6. [ 23.510324] RSP: 0018:ffffb4a60065fca8 EFLAGS: 00010246 [ 23.515592] RAX: 0000000000000000 RBX: ffff9f428290e000 RCX: 000000000000000f [ 23.522765] RDX: 0000000000000000 RSI: 0000000000000282 RDI: ffff9f428290e000 [ 23.529937] RBP: ffff9f4282907070 R08: ffff9f4281130428 R09: 00000000ffffffff [ 23.537111] R10: 0000000000000000 R11: 0000000000000001 R12: ffff9f42829070f8 [ 23.544284] R13: ffff9f4282906028 R14: ffff9f4282900000 R15: ffff9f4282906b68 [ 23.551457] FS: 0000000000000000(0000) GS:ffff9f466b2cf000(0000) knlGS:0000000000000000 [ 23.559588] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 23.565365] CR2: ffffffffffffffd6 CR3: 000000031c230001 CR4: 0000000000f70ef0 [ 23.572539] PKRU: 55555554 [ 23.575281] Call Trace: [ 23.577770] <TASK> [ 23.579905] intel_engines_reset_default_submission+0x42/0x60 [ 23.585695] __intel_gt_unset_wedged+0x191/0x200 [ 23.590360] intel_gt_unset_wedged+0x20/0x40 [ 23.594675] gt_sanitize+0x15e/0x170 [ 23.598290] i915_gem_suspend_late+0x6b/0x180 [ 23.602692] i915_drm_suspend_late+0x35/0xf0 [ 23.607008] ? __pfx_pci_pm_suspend_late+0x10/0x10 [ 23.611843] dpm_run_callback+0x78/0x1c0 [ 23.615817] device_suspend_late+0xde/0x2e0 [ 23.620037] async_suspend_late+0x18/0x30 [ 23.624082] async_run_entry_fn+0x25/0xa0 [ 23.628129] process_one_work+0x15b/0x380 [ 23.632182] worker_thread+0x2a5/0x3c0 [ 23.635973] ? __pfx_worker_thread+0x10/0x10 [ 23.640279] kthread+0xf6/0x1f0 [ 23.643464] ? __pfx_kthread+0x10/0x10 [ 23.647263] ? __pfx_kthread+0x10/0x10 [ 23.651045] ret_from_fork+0x131/0x190 [ 23.654837] ? __pfx_kthread+0x10/0x10 [ 23.658634] ret_from_fork_asm+0x1a/0x30 [ 23.662597] </TASK> [ 23.664826] Modules linked in: [ 23.667914] CR2: 0000000000000000 [ 23.671271] ------------[ cut here ]------------
(cherry picked from commit daa199abc3d3d1740c9e3a2c3e9216ae5b447cad)(CVE-2026-31540)
In the Linux kernel, the following vulnerability has been resolved:
x86/platform/uv: Handle deconfigured sockets
When a socket is deconfigured, it's mapped to SOCK_EMPTY (0xffff). This causes a panic while allocating UV hub info structures.
Fix this by using NUMA_NO_NODE, allowing UV hub info structures to be allocated on valid nodes.(CVE-2026-31542)
In the Linux kernel, the following vulnerability has been resolved:
net: bonding: fix NULL deref in bond_debug_rlb_hash_show
rlb_clear_slave intentionally keeps RLB hash-table entries on the rx_hashtbl_used_head list with slave set to NULL when no replacement slave is available. However, bond_debug_rlb_hash_show visites client_info->slave without checking if it's NULL.
Other used-list iterators in bond_alb.c already handle this NULL-slave state safely:
- rlb_update_client returns early on !client_info->slave
- rlb_req_update_slave_clients, rlb_clear_slave, and rlb_rebalance compare slave values before visiting
- lb_req_update_subnet_clients continues if slave is NULL
The following NULL deref crash can be trigger in bond_debug_rlb_hash_show:
[ 1.289791] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 1.292058] RIP: 0010:bond_debug_rlb_hash_show (drivers/net/bonding/bond_debugfs.c:41) [ 1.293101] RSP: 0018:ffffc900004a7d00 EFLAGS: 00010286 [ 1.293333] RAX: 0000000000000000 RBX: ffff888102b48200 RCX: ffff888102b48204 [ 1.293631] RDX: ffff888102b48200 RSI: ffffffff839daad5 RDI: ffff888102815078 [ 1.293924] RBP: ffff888102815078 R08: ffff888102b4820e R09: 0000000000000000 [ 1.294267] R10: 0000000000000000 R11: 0000000000000000 R12: ffff888100f929c0 [ 1.294564] R13: ffff888100f92a00 R14: 0000000000000001 R15: ffffc900004a7ed8 [ 1.294864] FS: 0000000001395380(0000) GS:ffff888196e75000(0000) knlGS:0000000000000000 [ 1.295239] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1.295480] CR2: 0000000000000000 CR3: 0000000102adc004 CR4: 0000000000772ef0 [ 1.295897] Call Trace: [ 1.296134] seq_read_iter (fs/seq_file.c:231) [ 1.296341] seq_read (fs/seq_file.c:164) [ 1.296493] full_proxy_read (fs/debugfs/file.c:378 (discriminator 1)) [ 1.296658] vfs_read (fs/read_write.c:572) [ 1.296981] ksys_read (fs/read_write.c:717) [ 1.297132] do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1) arch/x86/entry/syscall_64.c:94 (discriminator 1)) [ 1.297325] entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
Add a NULL check and print "(none)" for entries with no assigned slave.(CVE-2026-31546)
In the Linux kernel, the following vulnerability has been resolved:
futex: Clear stale exiting pointer in futex_lock_pi() retry path
Fuzzying/stressing futexes triggered:
WARNING: kernel/futex/core.c:825 at wait_for_owner_exiting+0x7a/0x80, CPU#11: futex_lock_pi_s/524
When futex_lock_pi_atomic() sees the owner is exiting, it returns -EBUSY and stores a refcounted task pointer in 'exiting'.
After wait_for_owner_exiting() consumes that reference, the local pointer is never reset to nil. Upon a retry, if futex_lock_pi_atomic() returns a different error, the bogus pointer is passed to wait_for_owner_exiting().
CPU0 CPU1 CPU2 futex_lock_pi(uaddr) // acquires the PI futex exit() futex_cleanup_begin() futex_state = EXITING; futex_lock_pi(uaddr) futex_lock_pi_atomic() attach_to_pi_owner() // observes EXITING exiting = owner; // takes ref return -EBUSY wait_for_owner_exiting(-EBUSY, owner) put_task_struct(); // drops ref // exiting still points to owner goto retry; futex_lock_pi_atomic() lock_pi_update_atomic() cmpxchg(uaddr) uaddr ^= WAITERS // whatever // value changed return -EAGAIN; wait_for_owner_exiting(-EAGAIN, exiting) // stale WARN_ON_ONCE(exiting)
Fix this by resetting upon retry, essentially aligning it with requeue_pi.(CVE-2026-31555)
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Fix fence put before wait in amdgpu_amdkfd_submit_ib
amdgpu_amdkfd_submit_ib() submits a GPU job and gets a fence from amdgpu_ib_schedule(). This fence is used to wait for job completion.
Currently, the code drops the fence reference using dma_fence_put() before calling dma_fence_wait().
If dma_fence_put() releases the last reference, the fence may be freed before dma_fence_wait() is called. This can lead to a use-after-free.
Fix this by waiting on the fence first and releasing the reference only after dma_fence_wait() completes.
Fixes the below: drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c:697 amdgpu_amdkfd_submit_ib() warn: passing freed memory 'f' (line 696)
(cherry picked from commit 8b9e5259adc385b61a6590a13b82ae0ac2bd3482)(CVE-2026-31566)
In the Linux kernel, the following vulnerability has been resolved:
can: gw: fix OOB heap access in cgw_csum_crc8_rel()
cgw_csum_crc8_rel() correctly computes bounds-safe indices via calc_idx():
int from = calc_idx(crc8->from_idx, cf->len);
int to = calc_idx(crc8->to_idx, cf->len);
int res = calc_idx(crc8->result_idx, cf->len);
if (from < 0 || to < 0 || res < 0)
return;
However, the loop and the result write then use the raw s8 fields directly instead of the computed variables:
for (i = crc8->from_idx; ...) /* BUG: raw negative index */
cf->data[crc8->result_idx] = ...; /* BUG: raw negative index */
With from_idx = to_idx = result_idx = -64 on a 64-byte CAN FD frame, calc_idx(-64, 64) = 0 so the guard passes, but the loop iterates with i = -64, reading cf->data[-64], and the write goes to cf->data[-64]. This write might end up to 56 (7.0-rc) or 40 (<= 6.19) bytes before the start of the canfd_frame on the heap.
The companion function cgw_csum_xor_rel() uses from/to/res
correctly throughout; fix cgw_csum_crc8_rel() to match.
Confirmed with KASAN on linux-7.0-rc2: BUG: KASAN: slab-out-of-bounds in cgw_csum_crc8_rel+0x515/0x5b0 Read of size 1 at addr ffff8880076619c8 by task poc_cgw_oob/62
To configure the can-gw crc8 checksums CAP_NET_ADMIN is needed.(CVE-2026-31570)
In the Linux kernel, the following vulnerability has been resolved:
KVM: SEV: Drop WARN on large size for KVM_MEMORY_ENCRYPT_REG_REGION
Drop the WARN in sev_pin_memory() on npages overflowing an int, as the WARN is comically trivially to trigger from userspace, e.g. by doing:
struct kvm_enc_region range = { .addr = 0, .size = -1ul, };
__vm_ioctl(vm, KVM_MEMORY_ENCRYPT_REG_REGION, &range);
Note, the checks in sev_mem_enc_register_region() that presumably exist to verify the incoming address+size are completely worthless, as both "addr" and "size" are u64s and SEV is 64-bit only, i.e. they can't be greater than ULONG_MAX. That wart will be cleaned up in the near future.
if (range->addr > ULONG_MAX || range->size > ULONG_MAX)
return -EINVAL;
Opportunistically add a comment to explain why the code calculates the number of pages the "hard" way, e.g. instead of just shifting @ulen.(CVE-2026-31590)
In the Linux kernel, the following vulnerability has been resolved:
PCI: endpoint: pci-epf-vntb: Stop cmd_handler work in epf_ntb_epc_cleanup
Disable the delayed work before clearing BAR mappings and doorbells to avoid running the handler after resources have been torn down.
Unable to handle kernel paging request at virtual address ffff800083f46004 [...] Internal error: Oops: 0000000096000007 [#1] SMP [...] Call trace: epf_ntb_cmd_handler+0x54/0x200 [pci_epf_vntb] (P) process_one_work+0x154/0x3b0 worker_thread+0x2c8/0x400 kthread+0x148/0x210 ret_from_fork+0x10/0x20(CVE-2026-31595)
In the Linux kernel, the following vulnerability has been resolved:
x86/CPU: Fix FPDSS on Zen1
Zen1's hardware divider can leave, under certain circumstances, partial results from previous operations. Those results can be leaked by another, attacker thread.
Fix that with a chicken bit.(CVE-2026-31628)
In the Linux kernel, the following vulnerability has been resolved:
rxrpc: proc: size address buffers for %pISpc output
The AF_RXRPC procfs helpers format local and remote socket addresses into fixed 50-byte stack buffers with "%pISpc".
That is too small for the longest current-tree IPv6-with-port form the formatter can produce. In lib/vsprintf.c, the compressed IPv6 path uses a dotted-quad tail not only for v4mapped addresses, but also for ISATAP addresses via ipv6_addr_is_isatap().
As a result, a case such as
is possible with the current formatter. That is 50 visible characters, so 51 bytes including the trailing NUL, which does not fit in the existing char[50] buffers used by net/rxrpc/proc.c.
Size the buffers from the formatter's maximum textual form and switch the call sites to scnprintf().
Changes since v1: - correct the changelog to cite the actual maximum current-tree case explicitly - frame the proof around the ISATAP formatting path instead of the earlier mapped-v4 example(CVE-2026-31630)
In the Linux kernel, the following vulnerability has been resolved:
mmc: vub300: fix NULL-deref on disconnect
Make sure to deregister the controller before dropping the reference to the driver data on disconnect to avoid NULL-pointer dereferences or use-after-free.(CVE-2026-31651)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nft_ct: fix use-after-free in timeout object destroy
nft_ct_timeout_obj_destroy() frees the timeout object with kfree() immediately after nf_ct_untimeout(), without waiting for an RCU grace period. Concurrent packet processing on other CPUs may still hold RCU-protected references to the timeout object obtained via rcu_dereference() in nf_ct_timeout_data().
Add an rcu_head to struct nf_ct_timeout and use kfree_rcu() to defer freeing until after an RCU grace period, matching the approach already used in nfnetlink_cttimeout.c.
KASAN report: BUG: KASAN: slab-use-after-free in nf_conntrack_tcp_packet+0x1381/0x29d0 Read of size 4 at addr ffff8881035fe19c by task exploit/80
Call Trace: nf_conntrack_tcp_packet+0x1381/0x29d0 nf_conntrack_in+0x612/0x8b0 nf_hook_slow+0x70/0x100 __ip_local_out+0x1b2/0x210 tcp_sendmsg_locked+0x722/0x1580 __sys_sendto+0x2d8/0x320
Allocated by task 75: nft_ct_timeout_obj_init+0xf6/0x290 nft_obj_init+0x107/0x1b0 nf_tables_newobj+0x680/0x9c0 nfnetlink_rcv_batch+0xc29/0xe00
Freed by task 26: nft_obj_destroy+0x3f/0xa0 nf_tables_trans_destroy_work+0x51c/0x5c0 process_one_work+0x2c4/0x5a0(CVE-2026-31665)
In the Linux kernel, the following vulnerability has been resolved:
Input: uinput - fix circular locking dependency with ff-core
A lockdep circular locking dependency warning can be triggered reproducibly when using a force-feedback gamepad with uinput (for example, playing ELDEN RING under Wine with a Flydigi Vader 5 controller):
ff->mutex -> udev->mutex -> input_mutex -> dev->mutex -> ff->mutex
The cycle is caused by four lock acquisition paths:
-
ff upload: input_ff_upload() holds ff->mutex and calls uinput_dev_upload_effect() -> uinput_request_submit() -> uinput_request_send(), which acquires udev->mutex.
-
device create: uinput_ioctl_handler() holds udev->mutex and calls uinput_create_device() -> input_register_device(), which acquires input_mutex.
-
device register: input_register_device() holds input_mutex and calls kbd_connect() -> input_register_handle(), which acquires dev->mutex.
-
evdev release: evdev_release() calls input_flush_device() under dev->mutex, which calls input_ff_flush() acquiring ff->mutex.
Fix this by introducing a new state_lock spinlock to protect udev->state and udev->dev access in uinput_request_send() instead of acquiring udev->mutex. The function only needs to atomically check device state and queue an input event into the ring buffer via uinput_dev_event() -- both operations are safe under a spinlock (ktime_get_ts64() and wake_up_interruptible() do not sleep). This breaks the ff->mutex -> udev->mutex link since a spinlock is a leaf in the lock ordering and cannot form cycles with mutexes.
To keep state transitions visible to uinput_request_send(), protect writes to udev->state in uinput_create_device() and uinput_destroy_device() with the same state_lock spinlock.
Additionally, move init_completion(&request->done) from uinput_request_send() to uinput_request_submit() before uinput_request_reserve_slot(). Once the slot is allocated, uinput_flush_requests() may call complete() on it at any time from the destroy path, so the completion must be initialised before the request becomes visible.
Lock ordering after the fix:
ff->mutex -> state_lock (spinlock, leaf) udev->mutex -> state_lock (spinlock, leaf) udev->mutex -> input_mutex -> dev->mutex -> ff->mutex (no back-edge)(CVE-2026-31667)
In the Linux kernel, the following vulnerability has been resolved:
net/sched: sch_netem: fix out-of-bounds access in packet corruption
In netem_enqueue(), the packet corruption logic uses get_random_u32_below(skb_headlen(skb)) to select an index for modifying skb->data. When an AF_PACKET TX_RING sends fully non-linear packets over an IPIP tunnel, skb_headlen(skb) evaluates to 0.
Passing 0 to get_random_u32_below() takes the variable-ceil slow path which returns an unconstrained 32-bit random integer. Using this unconstrained value as an offset into skb->data results in an out-of-bounds memory access.
Fix this by verifying skb_headlen(skb) is non-zero before attempting to corrupt the linear data area. Fully non-linear packets will silently bypass the corruption logic.(CVE-2026-31675)
In the Linux kernel, the following vulnerability has been resolved:
crypto: af_alg - limit RX SG extraction by receive buffer budget
Make af_alg_get_rsgl() limit each RX scatterlist extraction to the remaining receive buffer budget.
af_alg_get_rsgl() currently uses af_alg_readable() only as a gate before extracting data into the RX scatterlist. Limit each extraction to the remaining af_alg_rcvbuf(sk) budget so that receive-side accounting matches the amount of data attached to the request.
If skcipher cannot obtain enough RX space for at least one chunk while more data remains to be processed, reject the recvmsg call instead of rounding the request length down to zero.(CVE-2026-31677)
In the Linux kernel, the following vulnerability has been resolved:
openvswitch: defer tunnel netdev_put to RCU release
ovs_netdev_tunnel_destroy() may run after NETDEV_UNREGISTER already detached the device. Dropping the netdev reference in destroy can race with concurrent readers that still observe vport->dev.
Do not release vport->dev in ovs_netdev_tunnel_destroy(). Instead, let vport_netdev_free() drop the reference from the RCU callback, matching the non-tunnel destroy path and avoiding additional synchronization under RTNL.(CVE-2026-31678)
In the Linux kernel, a memory out-of-bounds access vulnerability exists in the act_csum module's tcf_csum_act() function when processing nested VLAN headers. When an skb still carries in-payload VLAN tags, the function walks nested VLAN headers directly from skb->data. The current code reads vlan->h_vlan_encapsulated_proto and then pulls VLAN_HLEN bytes without first ensuring that the full VLAN header is present in the linear area. If only part of an inner VLAN header is linearized, accessing h_vlan_encapsulated_proto reads past the linear area, and the following skb_pull(VLAN_HLEN) may violate skb invariants.(CVE-2026-31684)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: ip6t_eui64: reject invalid MAC header for all packets
eui64_mt6() derives a modified EUI-64 from the Ethernet source address
and compares it with the low 64 bits of the IPv6 source address.
The existing guard only rejects an invalid MAC header when
par->fragoff != 0. For packets with par->fragoff == 0, eui64_mt6()
can still reach eth_hdr(skb) even when the MAC header is not valid.
Fix this by removing the par->fragoff != 0 condition so that packets
with an invalid MAC header are rejected before accessing eth_hdr(skb).(CVE-2026-31685)
In the Linux kernel, the following vulnerability has been resolved:
EDAC/mc: Fix error path ordering in edac_mc_alloc()
When the mci->pvt_info allocation in edac_mc_alloc() fails, the error path will call put_device() which will end up calling the device's release function.
However, the init ordering is wrong such that device_initialize() happens after the failed allocation and thus the device itself and the release function pointer are not initialized yet when they're called:
MCE: In-kernel MCE decoding enabled. ------------[ cut here ]------------ kobject: '(null)': is not initialized, yet kobject_put() is being called. WARNING: lib/kobject.c:734 at kobject_put, CPU#22: systemd-udevd CPU: 22 UID: 0 PID: 538 Comm: systemd-udevd Not tainted 7.0.0-rc1+ #2 PREEMPT(full) RIP: 0010:kobject_put Call Trace: <TASK> edac_mc_alloc+0xbe/0xe0 [edac_core] amd64_edac_init+0x7a4/0xff0 [amd64_edac] ? __pfx_amd64_edac_init+0x10/0x10 [amd64_edac] do_one_initcall ...
Reorder the calling sequence so that the device is initialized and thus the release function pointer is properly set before it can be used.
This was found by Claude while reviewing another EDAC patch.(CVE-2026-31689)
In the Linux kernel, the following vulnerability has been resolved:
crypto: ccp: Don't attempt to copy ID to userspace if PSP command failed
When retrieving the ID for the CPU, don't attempt to copy the ID blob to userspace if the firmware command failed. If the failure was due to an invalid length, i.e. the userspace buffer+length was too small, copying the number of bytes firmware requires will overflow the kernel-allocated buffer and leak data to userspace.
BUG: KASAN: slab-out-of-bounds in instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] BUG: KASAN: slab-out-of-bounds in _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] BUG: KASAN: slab-out-of-bounds in _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 Read of size 64 at addr ffff8881867f5960 by task syz.0.906/24388
CPU: 130 UID: 0 PID: 24388 Comm: syz.0.906 Tainted: G U O 7.0.0-smp-DEV #28 PREEMPTLAZY Tainted: [U]=USER, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 12.62.0-0 11/19/2025 Call Trace: <TASK> dump_stack_lvl+0xc5/0x110 ../lib/dump_stack.c:120 print_address_description ../mm/kasan/report.c:378 [inline] print_report+0xbc/0x260 ../mm/kasan/report.c:482 kasan_report+0xa2/0xe0 ../mm/kasan/report.c:595 check_region_inline ../mm/kasan/generic.c:-1 [inline] kasan_check_range+0x264/0x2c0 ../mm/kasan/generic.c:200 instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 copy_to_user ../include/linux/uaccess.h:236 [inline] sev_ioctl_do_get_id2+0x361/0x490 ../drivers/crypto/ccp/sev-dev.c:2222 sev_ioctl+0x25f/0x490 ../drivers/crypto/ccp/sev-dev.c:2575 vfs_ioctl ../fs/ioctl.c:51 [inline] __do_sys_ioctl ../fs/ioctl.c:597 [inline] __se_sys_ioctl+0x11d/0x1b0 ../fs/ioctl.c:583 do_syscall_x64 ../arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xe0/0x800 ../arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e </TASK>
WARN if the driver says the command succeeded, but the firmware error code says otherwise, as __sev_do_cmd_locked() is expected to return -EIO on any firwmware error.(CVE-2026-31697)
In the Linux kernel, the following vulnerability has been resolved:
crypto: ccp: Don't attempt to copy PDH cert to userspace if PSP command failed
When retrieving the PDH cert, don't attempt to copy the blobs to userspace if the firmware command failed. If the failure was due to an invalid length, i.e. the userspace buffer+length was too small, copying the number of bytes firmware requires will overflow the kernel-allocated buffer and leak data to userspace.
BUG: KASAN: slab-out-of-bounds in instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] BUG: KASAN: slab-out-of-bounds in _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] BUG: KASAN: slab-out-of-bounds in _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 Read of size 2084 at addr ffff8885c4ab8aa0 by task syz.0.186/21033
CPU: 51 UID: 0 PID: 21033 Comm: syz.0.186 Tainted: G U O 7.0.0-smp-DEV #28 PREEMPTLAZY Tainted: [U]=USER, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.84.12-0 11/17/2025 Call Trace: <TASK> dump_stack_lvl+0xc5/0x110 ../lib/dump_stack.c:120 print_address_description ../mm/kasan/report.c:378 [inline] print_report+0xbc/0x260 ../mm/kasan/report.c:482 kasan_report+0xa2/0xe0 ../mm/kasan/report.c:595 check_region_inline ../mm/kasan/generic.c:-1 [inline] kasan_check_range+0x264/0x2c0 ../mm/kasan/generic.c:200 instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 copy_to_user ../include/linux/uaccess.h:236 [inline] sev_ioctl_do_pdh_export+0x3d3/0x7c0 ../drivers/crypto/ccp/sev-dev.c:2347 sev_ioctl+0x2a2/0x490 ../drivers/crypto/ccp/sev-dev.c:2568 vfs_ioctl ../fs/ioctl.c:51 [inline] __do_sys_ioctl ../fs/ioctl.c:597 [inline] __se_sys_ioctl+0x11d/0x1b0 ../fs/ioctl.c:583 do_syscall_x64 ../arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xe0/0x800 ../arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e </TASK>
WARN if the driver says the command succeeded, but the firmware error code says otherwise, as __sev_do_cmd_locked() is expected to return -EIO on any firwmware error.(CVE-2026-31698)
In the Linux kernel, the following vulnerability has been resolved:
crypto: ccp: Don't attempt to copy CSR to userspace if PSP command failed
When retrieving the PEK CSR, don't attempt to copy the blob to userspace if the firmware command failed. If the failure was due to an invalid length, i.e. the userspace buffer+length was too small, copying the number of bytes firmware requires will overflow the kernel-allocated buffer and leak data to userspace.
BUG: KASAN: slab-out-of-bounds in instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] BUG: KASAN: slab-out-of-bounds in _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] BUG: KASAN: slab-out-of-bounds in _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 Read of size 2084 at addr ffff898144612e20 by task syz.9.219/21405
CPU: 14 UID: 0 PID: 21405 Comm: syz.9.219 Tainted: G U O 7.0.0-smp-DEV #28 PREEMPTLAZY Tainted: [U]=USER, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 12.62.0-0 11/19/2025 Call Trace: <TASK> dump_stack_lvl+0xc5/0x110 ../lib/dump_stack.c:120 print_address_description ../mm/kasan/report.c:378 [inline] print_report+0xbc/0x260 ../mm/kasan/report.c:482 kasan_report+0xa2/0xe0 ../mm/kasan/report.c:595 check_region_inline ../mm/kasan/generic.c:-1 [inline] kasan_check_range+0x264/0x2c0 ../mm/kasan/generic.c:200 instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 copy_to_user ../include/linux/uaccess.h:236 [inline] sev_ioctl_do_pek_csr+0x31f/0x590 ../drivers/crypto/ccp/sev-dev.c:1872 sev_ioctl+0x3a4/0x490 ../drivers/crypto/ccp/sev-dev.c:2562 vfs_ioctl ../fs/ioctl.c:51 [inline] __do_sys_ioctl ../fs/ioctl.c:597 [inline] __se_sys_ioctl+0x11d/0x1b0 ../fs/ioctl.c:583 do_syscall_x64 ../arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xe0/0x800 ../arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e </TASK>
WARN if the driver says the command succeeded, but the firmware error code says otherwise, as __sev_do_cmd_locked() is expected to return -EIO on any firwmware error.(CVE-2026-31699)
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix OOB read in smb2_ioctl_query_info QUERY_INFO path
smb2_ioctl_query_info() has two response-copy branches: PASSTHRU_FSCTL and the default QUERY_INFO path. The QUERY_INFO branch clamps qi.input_buffer_length to the server-reported OutputBufferLength and then copies qi.input_buffer_length bytes from qi_rsp->Buffer to userspace, but it never verifies that the flexible-array payload actually fits within rsp_iov[1].iov_len.
A malicious server can return OutputBufferLength larger than the actual QUERY_INFO response, causing copy_to_user() to walk past the response buffer and expose adjacent kernel heap to userspace.
Guard the QUERY_INFO copy with a bounds check on the actual Buffer payload. Use struct_size(qi_rsp, Buffer, qi.input_buffer_length) rather than an open-coded addition so the guard cannot overflow on 32-bit builds.(CVE-2026-31708)
In the Linux kernel, the following vulnerability has been resolved:
vxlan: validate ND option lengths in vxlan_na_create
vxlan_na_create() walks ND options according to option-provided lengths. A malformed option can make the parser advance beyond the computed option span or use a too-short source LLADDR option payload.
Validate option lengths against the remaining NS option area before advancing, and only read source LLADDR when the option is large enough for an Ethernet address.(CVE-2026-31738)
In the Linux kernel, the following vulnerability has been resolved:
bridge: br_nd_send: validate ND option lengths
br_nd_send() walks ND options according to option-provided lengths. A malformed option can make the parser advance beyond the computed option span or use a too-short source LLADDR option payload.
Validate option lengths against the remaining NS option area before advancing, and only read source LLADDR when the option is large enough for an Ethernet address.(CVE-2026-31752)
In the Linux kernel, the following vulnerability has been resolved:
usb: cdns3: gadget: fix NULL pointer dereference in ep_queue
When the gadget endpoint is disabled or not yet configured, the ep->desc pointer can be NULL. This leads to a NULL pointer dereference when __cdns3_gadget_ep_queue() is called, causing a kernel crash.
Add a check to return -ESHUTDOWN if ep->desc is NULL, which is the standard return code for unconfigured endpoints.
This prevents potential crashes when ep_queue is called on endpoints that are not ready.(CVE-2026-31755)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_event: move wake reason storage into validated event handlers
hci_store_wake_reason() is called from hci_event_packet() immediately after stripping the HCI event header but before hci_event_func() enforces the per-event minimum payload length from hci_ev_table. This means a short HCI event frame can reach bacpy() before any bounds check runs.
Rather than duplicating skb parsing and per-event length checks inside hci_store_wake_reason(), move wake-address storage into the individual event handlers after their existing event-length validation has succeeded. Convert hci_store_wake_reason() into a small helper that only stores an already-validated bdaddr while the caller holds hci_dev_lock(). Use the same helper after hci_event_func() with a NULL address to preserve the existing unexpected-wake fallback semantics when no validated event handler records a wake address.
Annotate the helper with __must_hold(&hdev->lock) and add lockdep_assert_held(&hdev->lock) so future call paths keep the lock contract explicit.
Call the helper from hci_conn_request_evt(), hci_conn_complete_evt(), hci_sync_conn_complete_evt(), le_conn_complete_evt(), hci_le_adv_report_evt(), hci_le_ext_adv_report_evt(), hci_le_direct_adv_report_evt(), hci_le_pa_sync_established_evt(), and hci_le_past_received_evt().(CVE-2026-31771)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: SMP: derive legacy responder STK authentication from MITM state
The legacy responder path in smp_random() currently labels the stored STK as authenticated whenever pending_sec_level is BT_SECURITY_HIGH. That reflects what the local service requested, not what the pairing flow actually achieved.
For Just Works/Confirm legacy pairing, SMP_FLAG_MITM_AUTH stays clear and the resulting STK should remain unauthenticated even if the local side requested HIGH security. Use the established MITM state when storing the responder STK so the key metadata matches the pairing result.
This also keeps the legacy path aligned with the Secure Connections code, which already treats JUST_WORKS/JUST_CFM as unauthenticated.(CVE-2026-31773)
In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlwifi: mvm: fix potential out-of-bounds read in iwl_mvm_nd_match_info_handler()
The memcpy function assumes the dynamic array notif->matches is at least as large as the number of bytes to copy. Otherwise, results->matches may contain unwanted data. To guarantee safety, extend the validation in one of the checks to ensure sufficient packet length.
Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2026-31779)
In the Linux kernel, the following vulnerability has been resolved:
drm/ioc32: stop speculation on the drm_compat_ioctl path
The drm compat ioctl path takes a user controlled pointer, and then dereferences it into a table of function pointers, the signature method of spectre problems. Fix this up by calling array_index_nospec() on the index to the function pointer list.(CVE-2026-31781)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: MGMT: validate LTK enc_size on load
Load Long Term Keys stores the user-provided enc_size and later uses it to size fixed-size stack operations when replying to LE LTK requests. An enc_size larger than the 16-byte key buffer can therefore overflow the reply stack buffer.
Reject oversized enc_size values while validating the management LTK record so invalid keys never reach the stored key state.(CVE-2026-43020)
In the Linux kernel, the following vulnerability has been resolved:
net: use skb_header_pointer() for TCPv4 GSO frag_off check
Syzbot reported a KMSAN uninit-value warning in gso_features_check() called from netif_skb_features() [1].
gso_features_check() reads iph->frag_off to decide whether to clear mangleid_features. Accessing the IPv4 header via ip_hdr()/inner_ip_hdr() can rely on skb header offsets that are not always safe for direct dereference on packets injected from PF_PACKET paths.
Use skb_header_pointer() for the TCPv4 frag_off check so the header read is robust whether data is already linear or needs copying.
[1] https://syzkaller.appspot.com/bug?extid=1543a7d954d9c6d00407(CVE-2026-43036)
In the Linux kernel, the following vulnerability has been resolved:
net: ipv6: ndisc: fix ndisc_ra_useropt to initialize nduseropt_padX fields to zero to prevent an info-leak
When processing Router Advertisements with user options the kernel builds an RTM_NEWNDUSEROPT netlink message. The nduseroptmsg struct has three padding fields that are never zeroed and can leak kernel data
The fix is simple, just zeroes the padding fields.(CVE-2026-43040)
In the Linux kernel, the following vulnerability has been resolved:
crypto: af-alg - fix NULL pointer dereference in scatterwalk
The AF_ALG interface fails to unmark the end of a Scatter/Gather List (SGL) when chaining a new af_alg_tsgl structure. If a sendmsg() fills an SGL exactly to MAX_SGL_ENTS, the last entry is marked as the end. A subsequent sendmsg() allocates a new SGL and chains it, but fails to clear the end marker on the previous SGL's last data entry.
This causes the crypto scatterwalk to hit a premature end, returning NULL on sg_next() and leading to a kernel panic during dereference.
Fix this by explicitly unmarking the end of the previous SGL when performing sg_chain() in af_alg_alloc_tsgl().(CVE-2026-43043)
In the Linux kernel, the following vulnerability has been resolved:
serial: 8250: Fix TX deadlock when using DMA
dmaengine_terminate_async does not guarantee that the
__dma_tx_complete callback will run. The callback is currently the
only place where dma->tx_running gets cleared. If the transaction is
canceled and the callback never runs, then dma->tx_running will never
get cleared and we will never schedule new TX DMA transactions again.
This change makes it so we clear dma->tx_running after we terminate
the DMA transaction. This is "safe" because serial8250_tx_dma_flush
is holding the UART port lock. The first thing the callback does is also
grab the UART port lock, so access to dma->tx_running is serialized.(CVE-2026-43061)
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: idxd: Fix not releasing workqueue on .release()
The workqueue associated with an DSA/IAA device is not released when the object is freed.(CVE-2026-43064)
In the Linux kernel, the following vulnerability has been resolved:
perf/x86/intel/uncore: Skip discovery table for offline dies
This warning can be triggered if NUMA is disabled and the system boots with fewer CPUs than the number of CPUs in die 0.
WARNING: CPU: 9 PID: 7257 at uncore.c:1157 uncore_pci_pmu_register+0x136/0x160 [intel_uncore]
Currently, the discovery table continues to be parsed even if all CPUs in the associated die are offline. This can lead to an array overflow at "pmu->boxes[die] = box" in uncore_pci_pmu_register(), which may trigger the warning above or cause other issues.(CVE-2026-43079)
In the Linux kernel, the following vulnerability has been resolved:
ipv4: icmp: fix null-ptr-deref in icmp_build_probe()
ipv6_stub->ipv6_dev_find() may return ERR_PTR(-EAFNOSUPPORT) when the IPv6 stack is not active (CONFIG_IPV6=m and not loaded), and passing this error pointer to dev_hold() will cause a kernel crash with null-ptr-deref.
Instead, silently discard the request. RFC 8335 does not appear to define a specific response for the case where an IPv6 interface identifier is syntactically valid but the implementation cannot perform the lookup at runtime, and silently dropping the request may safer than misreporting "No Such Interface".(CVE-2026-43099)
In the Linux kernel, the following vulnerability has been resolved:
powerpc/smp: Add check for kcalloc() failure in parse_thread_groups()
As kcalloc() may fail, check its return value to avoid a NULL pointer dereference when passing it to of_property_read_u32_array().(CVE-2026-43148)
In the Linux kernel, the following vulnerability has been resolved:
net: usb: pegasus: enable basic endpoint checking
pegasus_probe() fills URBs with hardcoded endpoint pipes without verifying the endpoint descriptors:
- usb_rcvbulkpipe(dev, 1) for RX data
- usb_sndbulkpipe(dev, 2) for TX data
- usb_rcvintpipe(dev, 3) for status interrupts
A malformed USB device can present these endpoints with transfer types that differ from what the driver assumes.
Add a pegasus_usb_ep enum for endpoint numbers, replacing magic constants throughout. Add usb_check_bulk_endpoints() and usb_check_int_endpoints() calls before any resource allocation to verify endpoint types before use, rejecting devices with mismatched descriptors at probe time, and avoid triggering assertion.
Similar fix to - commit 90b7f2961798 ("net: usb: rtl8150: enable basic endpoint checking") - commit 9e7021d2aeae ("net: usb: catc: enable basic endpoint checking")(CVE-2026-43156)
In the Linux kernel, the following vulnerability has been resolved:
md/bitmap: fix GPF in write_page caused by resize race
A General Protection Fault occurs in write_page() during array resize: RIP: 0010:write_page+0x22b/0x3c0 [md_mod]
This is a use-after-free race between bitmap_daemon_work() and
__bitmap_resize(). The daemon iterates over bitmap->storage.filemap
without locking, while the resize path frees that storage via
md_bitmap_file_unmap(). quiesce() does not stop the md thread,
allowing concurrent access to freed pages.
Fix by holding mddev->bitmap_info.mutex during the bitmap update.(CVE-2026-43163)
In the Linux kernel, the following vulnerability has been resolved:
ipv6: ioam: fix heap buffer overflow in __ioam6_fill_trace_data()
On the receive path, __ioam6_fill_trace_data() uses trace->nodelen to decide how much data to write for each node. It trusts this field as-is from the incoming packet, with no consistency check against trace->type (the 24-bit field that tells which data items are present). A crafted packet can set nodelen=0 while setting type bits 0-21, causing the function to write ~100 bytes past the allocated region (into skb_shared_info), which corrupts adjacent heap memory and leads to a kernel panic.
Add a shared helper ioam6_trace_compute_nodelen() in ioam6.c to derive the expected nodelen from the type field, and use it:
- in ioam6_iptunnel.c (send path, existing validation) to replace the open-coded computation;
- in exthdrs.c (receive path, ipv6_hop_ioam) to drop packets whose nodelen is inconsistent with the type field, before any data is written.
Per RFC 9197, bits 12-21 are each short (4-octet) fields, so they are included in IOAM6_MASK_SHORT_FIELDS (changed from 0xff100000 to 0xff1ffc00).(CVE-2026-43186)
In the Linux kernel, the following vulnerability has been resolved:
LoongArch: Make cpumask_of_node() robust against NUMA_NO_NODE
The arch definition of cpumask_of_node() cannot handle NUMA_NO_NODE - which is a valid index - so add a check for this.(CVE-2026-43212)
In the Linux kernel, the following vulnerability has been resolved:
x86/kexec: add a sanity check on previous kernel's ima kexec buffer
When the second-stage kernel is booted via kexec with a limiting command line such as "mem=<size>", the physical range that contains the carried over IMA measurement list may fall outside the truncated RAM leading to a kernel panic.
BUG: unable to handle page fault for address: ffff97793ff47000
RIP: ima_restore_measurement_list+0xdc/0x45a
#PF: error_code(0x0000) – not-present page
Other architectures already validate the range with page_is_ram(), as done in commit cbf9c4b9617b ("of: check previous kernel's ima-kexec-buffer against memory bounds") do a similar check on x86.
Without carrying the measurement list across kexec, the attestation would fail.(CVE-2026-43240)
In the Linux kernel, the following vulnerability has been resolved:
gfs2: fiemap page fault fix
In gfs2_fiemap(), we are calling iomap_fiemap() while holding the inode glock. This can lead to recursive glock taking if the fiemap buffer is memory mapped to the same inode and accessing it triggers a page fault.
Fix by disabling page faults for iomap_fiemap() and faulting in the buffer by hand if necessary.
Fixes xfstest generic/742.(CVE-2026-43262)
In the Linux kernel, the following vulnerability has been resolved:
ceph: supply snapshot context in ceph_zero_partial_object()
The ceph_zero_partial_object function was missing proper snapshot context for its OSD write operations, which could lead to data inconsistencies in snapshots.
Reproducer: ../src/vstart.sh --new -x --localhost --bluestore ./bin/ceph auth caps client.fs_a mds 'allow rwps fsname=a' mon 'allow r fsname=a' osd 'allow rw tag cephfs data=a' mount -t ceph (CVE-2026-43273)
In the Linux kernel, the following vulnerability has been resolved:
ext4: move ext4_percpu_param_init() before ext4_mb_init()
When running kvm-xfstests -c ext4/1k -C 1 generic/383 with the
DOUBLE_CHECK macro defined, the following panic is triggered:
================================================================== EXT4-fs error (device vdc): ext4_validate_block_bitmap:423: comm mount: bg 0: bad block bitmap checksum BUG: unable to handle page fault for address: ff110000fa2cc000 PGD 3e01067 P4D 3e02067 PUD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 0 UID: 0 PID: 2386 Comm: mount Tainted: G W 6.18.0-gba65a4e7120a-dirty #1152 PREEMPT(none) RIP: 0010:percpu_counter_add_batch+0x13/0xa0 Call Trace: <TASK> ext4_mark_group_bitmap_corrupted+0xcb/0xe0 ext4_validate_block_bitmap+0x2a1/0x2f0 ext4_read_block_bitmap+0x33/0x50 mb_group_bb_bitmap_alloc+0x33/0x80 ext4_mb_add_groupinfo+0x190/0x250 ext4_mb_init_backend+0x87/0x290 ext4_mb_init+0x456/0x640 __ext4_fill_super+0x1072/0x1680 ext4_fill_super+0xd3/0x280 get_tree_bdev_flags+0x132/0x1d0 vfs_get_tree+0x29/0xd0 vfs_cmd_create+0x59/0xe0 __do_sys_fsconfig+0x4f6/0x6b0 do_syscall_64+0x50/0x1f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e ==================================================================
This issue can be reproduced using the following commands: mkfs.ext4 -F -q -b 1024 /dev/sda 5G tune2fs -O quota,project /dev/sda mount /dev/sda /tmp/test
With DOUBLE_CHECK defined, mb_group_bb_bitmap_alloc() reads and validates the block bitmap. When the validation fails, ext4_mark_group_bitmap_corrupted() attempts to update sbi->s_freeclusters_counter. However, this percpu_counter has not been initialized yet at this point, which leads to the panic described above.
Fix this by moving the execution of ext4_percpu_param_init() to occur before ext4_mb_init(), ensuring the per-CPU counters are initialized before they are used.(CVE-2026-43288)
In the Linux kernel, the following vulnerability has been resolved:
mm/vmalloc: prevent RCU stalls in kasan_release_vmalloc_node
When CONFIG_PAGE_OWNER is enabled, freeing KASAN shadow pages during vmalloc cleanup triggers expensive stack unwinding that acquires RCU read locks. Processing a large purge_list without rescheduling can cause the task to hold CPU for extended periods (10+ seconds), leading to RCU stalls and potential OOM conditions.
The issue manifests in purge_vmap_node() -> kasan_release_vmalloc_node() where iterating through hundreds or thousands of vmap_area entries and freeing their associated shadow pages causes:
rcu: INFO: rcu_preempt detected stalls on CPUs/tasks: rcu: Tasks blocked on level-0 rcu_node (CPUs 0-1): P6229/1:b..l ... task:kworker/0:17 state:R running task stack:28840 pid:6229 ... kasan_release_vmalloc_node+0x1ba/0xad0 mm/vmalloc.c:2299 purge_vmap_node+0x1ba/0xad0 mm/vmalloc.c:2299
Each call to kasan_release_vmalloc() can free many pages, and with page_owner tracking, each free triggers save_stack() which performs stack unwinding under RCU read lock. Without yielding, this creates an unbounded RCU critical section.
Add periodic cond_resched() calls within the loop to allow: - RCU grace periods to complete - Other tasks to run - Scheduler to preempt when needed
The fix uses need_resched() for immediate response under load, with a batch count of 32 as a guaranteed upper bound to prevent worst-case stalls even under light load.(CVE-2026-43292)
In the Linux kernel, the following vulnerability has been resolved:
net: ipa: fix event ring index not programmed for IPA v5.0+
For IPA v5.0+, the event ring index field moved from CH_C_CNTXT_0 to CH_C_CNTXT_1. The v5.0 register definition intended to define this field in the CH_C_CNTXT_1 fmask array but used the old identifier of ERINDEX instead of CH_ERINDEX.
Without a valid event ring, GSI channels could never signal transfer completions. This caused gsi_channel_trans_quiesce() to block forever in wait_for_completion().
At least for IPA v5.2 this resolves an issue seen where runtime suspend, system suspend, and remoteproc stop all hanged forever. It also meant the IPA data path was completely non functional.(CVE-2026-43345)
In the Linux kernel, the following vulnerability has been resolved:
io_uring/kbuf: check if target buffer list is still legacy on recycle
There's a gap between when the buffer was grabbed and when it potentially gets recycled, where if the list is empty, someone could've upgraded it to a ring provided type. This can happen if the request is forced via io-wq. The legacy recycling is missing checking if the buffer_list still exists, and if it's of the correct type. Add those checks.(CVE-2026-43366)
In the Linux kernel, the following vulnerability has been resolved:
libceph: prevent potential out-of-bounds reads in process_message_header()
If the message frame is (maliciously) corrupted in a way that the length of the control segment ends up being less than the size of the message header or a different frame is made to look like a message frame, out-of-bounds reads may ensue in process_message_header().
Perform an explicit bounds check before decoding the message header.(CVE-2026-43406)
In the Linux kernel, the following vulnerability has been resolved:
ceph: fix memory leaks in ceph_mdsc_build_path()
Add __putname() calls to error code paths that did not free the "path" pointer obtained by __getname(). If ownership of this pointer is not passed to the caller via path_info.path, the function must free it before returning.(CVE-2026-43419)
In the Linux kernel, the following vulnerability has been resolved:
usb: class: cdc-wdm: fix reordering issue in read code path
Quoting the bug report:
Due to compiler optimization or CPU out-of-order execution, the desc->length update can be reordered before the memmove. If this happens, wdm_read() can see the new length and call copy_to_user() on uninitialized memory. This also violates LKMM data race rules [1].
Fix it by using WRITE_ONCE and memory barriers.(CVE-2026-43427)
In the Linux kernel, the following vulnerability has been resolved:
USB: core: Limit the length of unkillable synchronous timeouts
The usb_control_msg(), usb_bulk_msg(), and usb_interrupt_msg() APIs in usbcore allow unlimited timeout durations. And since they use uninterruptible waits, this leaves open the possibility of hanging a task for an indefinitely long time, with no way to kill it short of unplugging the target device.
To prevent this sort of problem, enforce a maximum limit on the length of these unkillable timeouts. The limit chosen here, somewhat arbitrarily, is 60 seconds. On many systems (although not all) this is short enough to avoid triggering the kernel's hung-task detector.
In addition, clear up the ambiguity of negative timeout values by treating them the same as 0, i.e., using the maximum allowed timeout.(CVE-2026-43428)
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: Fix deadlock between devlink lock and esw->wq
esw->work_queue executes esw_functions_changed_event_handler -> esw_vfs_changed_event_handler and acquires the devlink lock.
.eswitch_mode_set (acquires devlink lock in devlink_nl_pre_doit) -> mlx5_devlink_eswitch_mode_set -> mlx5_eswitch_disable_locked -> mlx5_eswitch_event_handler_unregister -> flush_workqueue deadlocks when esw_vfs_changed_event_handler executes.
Fix that by no longer flushing the work to avoid the deadlock, and using a generation counter to keep track of work relevance. This avoids an old handler manipulating an esw that has undergone one or more mode changes: - the counter is incremented in mlx5_eswitch_event_handler_unregister. - the counter is read and passed to the ephemeral mlx5_host_work struct. - the work handler takes the devlink lock and bails out if the current generation is different than the one it was scheduled to operate on. - mlx5_eswitch_cleanup does the final draining before destroying the wq.
No longer flushing the workqueue has the side effect of maybe no longer cancelling pending vport_change_handler work items, but that's ok since those are disabled elsewhere: - mlx5_eswitch_disable_locked disables the vport eq notifier. - mlx5_esw_vport_disable disarms the HW EQ notification and marks vport->enabled under state_lock to false to prevent pending vport handler from doing anything. - mlx5_eswitch_cleanup destroys the workqueue and makes sure all events are disabled/finished.(CVE-2026-43468)
In the Linux kernel, the following vulnerability has been resolved: crypto: pcrypt - Fix handling of MAY_BACKLOG requests MAY_BACKLOG requests can return EBUSY. Handle them by checking for that value and filtering out EINPROGRESS notifications. The Linux kernel CVE team has assigned CVE-2026-43493 to this issue.(CVE-2026-43493)
In the Linux kernel, the following vulnerability has been resolved:
net: skbuff: propagate shared-frag marker through frag-transfer helpers
Two frag-transfer helpers (__pskb_copy_fclone() and skb_shift()) fail to propagate the SKBFL_SHARED_FRAG bit in skb_shinfo()->flags when moving frags from source to destination. __pskb_copy_fclone() defers the rest of the shinfo metadata to skb_copy_header() after copying frag descriptors, but that helper only carries over gso_{size,segs, type} and never touches skb_shinfo()->flags; skb_shift() moves frag descriptors directly and leaves flags untouched. As a result, the destination skb keeps a reference to the same externally-owned or page-cache-backed pages while reporting skb_has_shared_frag() as false.
The mismatch is harmful in any in-place writer that uses skb_has_shared_frag() to decide whether shared pages must be detoured through skb_cow_data(). ESP input is one such writer (esp4.c, esp6.c), and a single nft 'dup to <local>' rule -- or any other nf_dup_ipv4() / xt_TEE caller -- is enough to land a pskb_copy()'d skb in esp_input() with the marker stripped, letting an unprivileged user write into the page cache of a root-owned read-only file via authencesn-ESN stray writes.
Set SKBFL_SHARED_FRAG on the destination whenever frag descriptors were actually moved from the source. skb_copy() and skb_copy_expand() share skb_copy_header() too but linearize all paged data into freshly allocated head storage and emerge with nr_frags == 0, so skb_has_shared_frag() returns false on its own; they need no change.
The same omission exists in skb_gro_receive() and skb_gro_receive_list(). The former moves the incoming skb's frag descriptors into the accumulator's last sub-skb via two paths (a direct frag-move loop and the head_frag + memcpy path); the latter chains the incoming skb whole onto p's frag_list. Downstream skb_segment() reads only skb_shinfo(p)->flags, and skb_segment_list() reuses each sub-skb's shinfo as the nskb -- both p and lp must carry the marker.
The same omission also exists in tcp_clone_payload(), which builds an MTU probe skb by moving frag descriptors from skbs on sk_write_queue into a freshly allocated nskb. The helper falls into the same family and warrants the same fix for consistency; no TCP TX-side in-place writer is currently known to reach a user page through this gap, but a future consumer depending on the marker would regress silently.
The same omission exists in skb_segment(): the per-iteration flag merge takes only head_skb's flag, and the inner switch that rebinds frag_skb to list_skb on head_skb-frags exhaustion does not fold the new frag_skb's flag into nskb. Fold frag_skb's flag at both sites so segments drawing frags from frag_list members carry the marker.(CVE-2026-43503)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Fix null-ptr-deref in l2cap_sock_state_change_cb()
Add the same NULL guard already present in l2cap_sock_resume_cb() and l2cap_sock_ready_cb().(CVE-2026-45834)
In the Linux kernel, the following vulnerability has been resolved:
gfs2: Fix slab-use-after-free in qd_put
Commit a475c5dd16e5 ("gfs2: Free quota data objects synchronously") started freeing quota data objects during filesystem shutdown instead of putting them back onto the LRU list, but it failed to remove these objects from the LRU list, causing LRU list corruption. This caused use-after-free when the shrinker (gfs2_qd_shrink_scan) tried to access already-freed objects on the LRU list.
Fix this by removing qd objects from the LRU list before freeing them in qd_put().
Initial fix from Deepanshu Kartikey <(CVE-2026-45861)
In the Linux kernel, the following vulnerability has been resolved:
usb: cdns3: fix role switching during resume
If the role change while we are suspended, the cdns3 driver switches to the new mode during resume. However, switching to host mode in this context causes a NULL pointer dereference.
The host role's start() operation registers a xhci-hcd device, but its probe is deferred while we are in the resume path. The host role's resume() operation assumes the xhci-hcd device is already probed, which is not the case, leading to the dereference. Since the start() operation of the new role is already called, the resume operation can be skipped.
So skip the resume operation for the new role if a role switch occurs during resume. Once the resume sequence is complete, the xhci-hcd device can be probed in case of host mode.
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000208 Mem abort info: ... Data abort info: ... [0000000000000208] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] SMP Modules linked in: CPU: 0 UID: 0 PID: 146 Comm: sh Not tainted 6.19.0-rc7-00013-g6e64f4aabfae-dirty #135 PREEMPT Hardware name: Texas Instruments J7200 EVM (DT) pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : usb_hcd_is_primary_hcd+0x0/0x1c lr : cdns_host_resume+0x24/0x5c ... Call trace: usb_hcd_is_primary_hcd+0x0/0x1c (P) cdns_resume+0x6c/0xbc cdns3_controller_resume.isra.0+0xe8/0x17c cdns3_plat_resume+0x18/0x24 platform_pm_resume+0x2c/0x68 dpm_run_callback+0x90/0x248 device_resume+0x100/0x24c dpm_resume+0x190/0x2ec dpm_resume_end+0x18/0x34 suspend_devices_and_enter+0x2b0/0xa44 pm_suspend+0x16c/0x5fc state_store+0x80/0xec kobj_attr_store+0x18/0x2c sysfs_kf_write+0x7c/0x94 kernfs_fop_write_iter+0x130/0x1dc vfs_write+0x240/0x370 ksys_write+0x70/0x108 __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x10c el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0x108 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Code: 52800003 f9407ca5 d63f00a0 17ffffe4 (f9410401) ---[ end trace 0000000000000000 ]---(CVE-2026-45911)
In the Linux kernel, the following vulnerability has been resolved:
erofs: fix inline data read failure for ztailpacking pclusters
Compressed folios for ztailpacking pclusters must be valid before adding these pclusters to I/O chains. Otherwise, z_erofs_decompress_pcluster() may assume they are already valid and then trigger a NULL pointer dereference.
It is somewhat hard to reproduce because the inline data is in the same block as the tail of the compressed indexes, which are usually read just before. However, it may still happen if a fatal signal arrives while read_mapping_folio() is running, as shown below:
erofs: (device dm-1): z_erofs_pcluster_begin: failed to get inline data -4 Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008
...
pc : z_erofs_decompress_queue+0x4c8/0xa14 lr : z_erofs_decompress_queue+0x160/0xa14 sp : ffffffc08b3eb3a0 x29: ffffffc08b3eb570 x28: ffffffc08b3eb418 x27: 0000000000001000 x26: ffffff8086ebdbb8 x25: ffffff8086ebdbb8 x24: 0000000000000001 x23: 0000000000000008 x22: 00000000fffffffb x21: dead000000000700 x20: 00000000000015e7 x19: ffffff808babb400 x18: ffffffc089edc098 x17: 00000000c006287d x16: 00000000c006287d x15: 0000000000000004 x14: ffffff80ba8f8000 x13: 0000000000000004 x12: 00000006589a77c9 x11: 0000000000000015 x10: 0000000000000000 x9 : 0000000000000000 x8 : 0000000000000000 x7 : 0000000000000000 x6 : 000000000000003f x5 : 0000000000000040 x4 : ffffffffffffffe0 x3 : 0000000000000020 x2 : 0000000000000008 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: z_erofs_decompress_queue+0x4c8/0xa14 z_erofs_runqueue+0x908/0x97c z_erofs_read_folio+0x128/0x228 filemap_read_folio+0x68/0x128 filemap_get_pages+0x44c/0x8b4 filemap_read+0x12c/0x5b8 generic_file_read_iter+0x4c/0x15c do_iter_readv_writev+0x188/0x1e0 vfs_iter_read+0xac/0x1a4 backing_file_read_iter+0x170/0x34c ovl_read_iter+0xf0/0x140 vfs_read+0x28c/0x344 ksys_read+0x80/0xf0 __arm64_sys_read+0x24/0x34 invoke_syscall+0x60/0x114 el0_svc_common+0x88/0xe4 do_el0_svc+0x24/0x30 el0_svc+0x40/0xa8 el0t_64_sync_handler+0x70/0xbc el0t_64_sync+0x1bc/0x1c0
Fix this by reading the inline data before allocating and adding the pclusters to the I/O chains.(CVE-2026-45943)
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Fix memory leak in amdgpu_acpi_enumerate_xcc()
In amdgpu_acpi_enumerate_xcc(), if amdgpu_acpi_dev_init() returns -ENOMEM, the function returns directly without releasing the allocated xcc_info, resulting in a memory leak.
Fix this by ensuring that xcc_info is properly freed in the error paths.
Compile tested only. Issue found using a prototype static analysis tool and code review.(CVE-2026-45947)
In the Linux kernel, the following vulnerability has been resolved:
gfs2: fix memory leaks in gfs2_fill_super error path
Fix two memory leaks in the gfs2_fill_super() error handling path when transitioning a filesystem to read-write mode fails.
First leak: kthread objects (thread_struct, task_struct, etc.) When gfs2_freeze_lock_shared() fails after init_threads() succeeds, the created kernel threads (logd and quotad) are never destroyed. This occurs because the fail_per_node label doesn't call gfs2_destroy_threads().
Second leak: quota bitmap buffer (8192 bytes) When gfs2_make_fs_rw() fails after gfs2_quota_init() succeeds but before other operations complete, the allocated quota bitmap is never freed.
The fix moves thread cleanup to the fail_per_node label to handle all error paths uniformly. gfs2_destroy_threads() is safe to call unconditionally as it checks for NULL pointers. Quota cleanup is added in gfs2_make_fs_rw() to properly handle the withdrawal case where quota initialization succeeds but the filesystem is then withdrawn.
Thread leak backtrace (gfs2_freeze_lock_shared failure): unreferenced object 0xffff88801d7bca80 (size 4480): copy_process+0x3a1/0x4670 kernel/fork.c:2422 kernel_clone+0xf3/0x6e0 kernel/fork.c:2779 kthread_create_on_node+0x100/0x150 kernel/kthread.c:478 init_threads+0xab/0x350 fs/gfs2/ops_fstype.c:611 gfs2_fill_super+0xe5c/0x1240 fs/gfs2/ops_fstype.c:1265
Quota leak backtrace (gfs2_make_fs_rw failure): unreferenced object 0xffff88812de7c000 (size 8192): gfs2_quota_init+0xe5/0x820 fs/gfs2/quota.c:1409 gfs2_make_fs_rw+0x7a/0xe0 fs/gfs2/super.c:149 gfs2_fill_super+0xfbb/0x1240 fs/gfs2/ops_fstype.c:1275(CVE-2026-45961)
In the Linux kernel, the following vulnerability has been resolved:
ACPICA: Fix NULL pointer dereference in acpi_ev_address_space_dispatch()
Cover a missed execution path with a new check.(CVE-2026-45982)
In the Linux kernel, the following vulnerability has been resolved:
erofs: fix unsigned underflow in z_erofs_lz4_handle_overlap()
Some crafted images can have illegal (!partial_decoding && m_llen < m_plen) extents, and the LZ4 inplace decompression path can be wrongly hit, but it cannot handle (outpages < inpages) properly: "outpages - inpages" wraps to a large value and the subsequent rq->out[] access reads past the decompressed_pages array.
However, such crafted cases can correctly result in a corruption report in the normal LZ4 non-inplace path.
Let's add an additional check to fix this for backporting.
Reproducible image (base64-encoded gzipped blob):
H4sIAJGR12kCA+3SPUoDQRgG4MkmkkZk8QRbRFIIi9hbpEjrHQI5ghfwCN5BLCzTGtLbBI+g dilSJo1CnIm7GEXFxhT6PDDwfrs73/ywIQD/1ePD4r7Ou6ETsrq4mu7XcWfj++Pb58nJU/9i PNtbjhan04/9GtX4qVYc814WDqt6FaX5s+ZwXXeq52lndT6IuVvlblytLMvh4Gzwaf90nsvz 2DF/21+20T/ldgp5s1jXRaN4t/8izsy/OUB6e/Qa79r+JwAAAAAAAL52vQVuGQAAAP6+my1w ywAAAAAAAADwu14ATsEYtgBQAAA=
$ mount -t erofs -o cache_strategy=disabled foo.erofs /mnt $ dd if=/mnt/data of=/dev/null bs=4096 count=1(CVE-2026-45999)
In the Linux kernel, the following vulnerability has been resolved: ipmi:ssif: Clean up kthread on errors If an error occurs after the ssif kthread is created, but before the main IPMI code starts the ssif interface, the ssif kthread will not be stopped. So make sure the kthread is stopped on an error condition if it is running. The Linux kernel CVE team has assigned CVE-2026-46044 to this issue.(CVE-2026-46044)
In the Linux kernel, the following vulnerability has been resolved: md/raid5: fix soft lockup in retry_aligned_read() When retry_aligned_read() encounters an overlapped stripe, it releases the stripe via raid5_release_stripe() which puts it on the lockless released_stripes llist. In the next raid5d loop iteration, release_stripe_list() drains the stripe onto handle_list (since STRIPE_HANDLE is set by the original IO), but retry_aligned_read() runs before handle_active_stripes() and removes the stripe from handle_list via find_get_stripe() -> list_del_init(). This prevents handle_stripe() from ever processing the stripe to resolve the overlap, causing an infinite loop and soft lockup. Fix this by using __release_stripe() with temp_inactive_list instead of raid5_release_stripe() in the failure path, so the stripe does not go through the released_stripes llist. This allows raid5d to break out of its loop, and the overlap will be resolved when the stripe is eventually processed by handle_stripe(). The Linux kernel CVE team has assigned CVE-2026-46051 to this issue.(CVE-2026-46051)
In the Linux kernel, the following vulnerability has been resolved: KVM: nSVM: Raise #UD if unhandled VMMCALL isn't intercepted by L1 Explicitly synthesize a #UD for VMMCALL if L2 is active, L1 does NOT want to intercept VMMCALL, nested_svm_l2_tlb_flush_enabled() is true, and the hypercall is something other than one of the supported Hyper-V hypercalls. When all of the above conditions are met, KVM will intercept VMMCALL but never forward it to L1, i.e. will let L2 make hypercalls as if it were L1. The TLFS says a whole lot of nothing about this scenario, so go with the architectural behavior, which says that VMMCALL #UDs if it's not intercepted. Opportunistically do a 2-for-1 stub trade by stub-ifying the new API instead of the helpers it uses. The last remaining "single" stub will soon be dropped as well. [sean: rewrite changelog and comment, tag for stable, remove defunct stubs] The Linux kernel CVE team has assigned CVE-2026-46076 to this issue.(CVE-2026-46076)
In the Linux kernel, the following vulnerability has been resolved: erofs: fix the out-of-bounds nameoff handling for trailing dirents Currently we already have boundary-checks for nameoffs, but the trailing dirents are special since the namelens are calculated with strnlen() with unchecked nameoffs. If a crafted EROFS has a trailing dirent with nameoff >= maxsize, maxsize - nameoff can underflow, causing strnlen() to read past the directory block. nameoff0 should also be verified to be a multiple of sizeof(struct erofs_dirent) as well [1]. [1] https://sashiko.dev/#/patchset/20260416063511.3173774-1-hsiangkao%40linux.alibaba.com The Linux kernel CVE team has assigned CVE-2026-46078 to this issue.(CVE-2026-46078)
In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Inject #UD for INVLPGA if EFER.SVME=0 INVLPGA should cause a #UD when EFER.SVME is not set. Add a check to properly inject #UD when EFER.SVME=0. [sean: tag for stable@] The Linux kernel CVE team has assigned CVE-2026-46082 to this issue.(CVE-2026-46082)
In the Linux kernel, the following vulnerability has been resolved: mm/vmalloc: take vmap_purge_lock in shrinker decay_va_pool_node() can be invoked concurrently from two paths: __purge_vmap_area_lazy() when pools are being purged, and the shrinker via vmap_node_shrink_scan(). However, decay_va_pool_node() is not safe to run concurrently, and the shrinker path currently lacks serialization, leading to races and possible leaks. Protect decay_va_pool_node() by taking vmap_purge_lock in the shrinker path to ensure serialization with purge users. The Linux kernel CVE team has assigned CVE-2026-46093 to this issue.(CVE-2026-46093)
In the Linux kernel, the following vulnerability has been resolved:mm/damon/sysfs-schemes: protect memcg_path kfree() with damon_sysfs_lockPatch series "mm/damon/sysfs-schemes: fix use-after-free for [memcg_]path".Reads of 'memcg_path' and 'path' files in DAMON sysfs interface could racewith their writes, results in use-after-free. Fix those.This patch (of 2):damon_sysfs_scheme_filter->mmecg_path can be read and written by users,via DAMON sysfs memcg_path file. It can also be indirectly read, for theparameters {on,off}line committing to DAMON. The reads for parameterscommitting are protected by damon_sysfs_lock to avoid the sysfs filesbeing destroyed while any of the parameters are being read. But theuser-driven direct reads and writes are not protected by any lock, whilethe write is deallocating the memcg_path-pointing buffer. As a result,the readers could read the already freed buffer (user-after-free). Notethat the user-reads don't race when the same open file is used by thewriter, due to kernfs's open file locking. Nonetheless, doing the readsand writes with separate open files would be common. Fix it by protectingboth the user-direct reads and writes with damon_sysfs_lock.(CVE-2026-46121)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_event: Fix OOB read and infinite loop in hci_le_create_big_complete_evt
hci_le_create_big_complete_evt() iterates over BT_BOUND connections for a BIG handle using a while loop, accessing ev->bis_handle[i++] on each iteration. However, there is no check that i stays within ev->num_bis before the array access.
When a controller sends a LE_Create_BIG_Complete event with fewer bis_handle entries than there are BT_BOUND connections for that BIG, or with num_bis=0, the loop reads beyond the valid bis_handle[] flex array into adjacent heap memory. Since the out-of-bounds values typically exceed HCI_CONN_HANDLE_MAX (0x0EFF), hci_conn_set_handle() rejects them and the connection remains in BT_BOUND state. The same connection is then found again by hci_conn_hash_lookup_big_state(), creating an infinite loop with hci_dev_lock held.
Fix this by terminating the BIG if in case not all BIS could be setup properly.(CVE-2026-46138)
In the Linux kernel, vports are used concurrently and protected by RCU, so netdev_put() must happen after the RCU grace period. The rtnl_delete_link() must happen under RTNL and cannot be executed in RCU context. Calling synchronize_net() while holding RTNL is not good for performance and system stability, so calling netdev_put() in RCU call is the right solution. However, when the device is deleted, rtnl_unlock() calls netdev_run_todo() and blocks until all references are gone. In the current code, this means that call_rcu() is never reached, the vport is never freed, and the reference is never released, causing a self-deadlock on device removal. The fix moves the rcu_call() before rtnl_unlock(), so the scheduled RCU callback will be executed when synchronize_net() is called from rtnl_unlock()->netdev_run_todo() while RTNL itself is already released.(CVE-2026-46165)
In the Linux kernel's RISC-V KVM subsystem, when the second kzalloc (host_context.vector.datap) fails in kvm_riscv_vcpu_alloc_vector_context, the first allocation (guest_context.vector.datap) is not freed, causing a memory leak. An attacker can trigger this via ioctl(vm_fd, KVM_CREATE_VCPU), potentially leading to resource exhaustion.(CVE-2026-46171)
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 spi_nor_params_show() function uses sizeof(snor_f_names) to calculate the array length. Since snor_f_names is an array of pointers, sizeof returns the total byte size of the pointer array (element_count sizeof(void )), which on 64-bit systems is 8 times larger than intended. This causes an out-of-bounds read when a flag bit is set that exceeds the actual element count but falls within the inflated byte-size count. The fix replaces sizeof with ARRAY_SIZE to pass the actual number of elements.(CVE-2026-46190)
| URL | Type | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-6.6.0-145.3.14.145.oe2403sp3.aarch64.rpm",
"bpftool-debuginfo-6.6.0-145.3.14.145.oe2403sp3.aarch64.rpm",
"kernel-6.6.0-145.3.14.145.oe2403sp3.aarch64.rpm",
"kernel-debuginfo-6.6.0-145.3.14.145.oe2403sp3.aarch64.rpm",
"kernel-debugsource-6.6.0-145.3.14.145.oe2403sp3.aarch64.rpm",
"kernel-devel-6.6.0-145.3.14.145.oe2403sp3.aarch64.rpm",
"kernel-extra-modules-6.6.0-145.3.14.145.oe2403sp3.aarch64.rpm",
"kernel-headers-6.6.0-145.3.14.145.oe2403sp3.aarch64.rpm",
"kernel-source-6.6.0-145.3.14.145.oe2403sp3.aarch64.rpm",
"kernel-tools-6.6.0-145.3.14.145.oe2403sp3.aarch64.rpm",
"kernel-tools-debuginfo-6.6.0-145.3.14.145.oe2403sp3.aarch64.rpm",
"kernel-tools-devel-6.6.0-145.3.14.145.oe2403sp3.aarch64.rpm",
"perf-6.6.0-145.3.14.145.oe2403sp3.aarch64.rpm",
"perf-debuginfo-6.6.0-145.3.14.145.oe2403sp3.aarch64.rpm",
"python3-perf-6.6.0-145.3.14.145.oe2403sp3.aarch64.rpm",
"python3-perf-debuginfo-6.6.0-145.3.14.145.oe2403sp3.aarch64.rpm"
],
"src": [
"kernel-6.6.0-145.3.14.145.oe2403sp3.src.rpm"
],
"x86_64": [
"bpftool-6.6.0-145.3.14.145.oe2403sp3.x86_64.rpm",
"bpftool-debuginfo-6.6.0-145.3.14.145.oe2403sp3.x86_64.rpm",
"kernel-6.6.0-145.3.14.145.oe2403sp3.x86_64.rpm",
"kernel-debuginfo-6.6.0-145.3.14.145.oe2403sp3.x86_64.rpm",
"kernel-debugsource-6.6.0-145.3.14.145.oe2403sp3.x86_64.rpm",
"kernel-devel-6.6.0-145.3.14.145.oe2403sp3.x86_64.rpm",
"kernel-extra-modules-6.6.0-145.3.14.145.oe2403sp3.x86_64.rpm",
"kernel-headers-6.6.0-145.3.14.145.oe2403sp3.x86_64.rpm",
"kernel-source-6.6.0-145.3.14.145.oe2403sp3.x86_64.rpm",
"kernel-tools-6.6.0-145.3.14.145.oe2403sp3.x86_64.rpm",
"kernel-tools-debuginfo-6.6.0-145.3.14.145.oe2403sp3.x86_64.rpm",
"kernel-tools-devel-6.6.0-145.3.14.145.oe2403sp3.x86_64.rpm",
"perf-6.6.0-145.3.14.145.oe2403sp3.x86_64.rpm",
"perf-debuginfo-6.6.0-145.3.14.145.oe2403sp3.x86_64.rpm",
"python3-perf-6.6.0-145.3.14.145.oe2403sp3.x86_64.rpm",
"python3-perf-debuginfo-6.6.0-145.3.14.145.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.14.145.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\nmISDN: hfcpci: Fix warning when deleting uninitialized timer\n\nWith CONFIG_DEBUG_OBJECTS_TIMERS unloading hfcpci module leads\nto the following splat:\n\n[ 250.215892] ODEBUG: assert_init not available (active state 0) object: ffffffffc01a3dc0 object type: timer_list hint: 0x0\n[ 250.217520] WARNING: CPU: 0 PID: 233 at lib/debugobjects.c:612 debug_print_object+0x1b6/0x2c0\n[ 250.218775] Modules linked in: hfcpci(-) mISDN_core\n[ 250.219537] CPU: 0 UID: 0 PID: 233 Comm: rmmod Not tainted 6.17.0-rc2-g6f713187ac98 #2 PREEMPT(voluntary)\n[ 250.220940] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n[ 250.222377] RIP: 0010:debug_print_object+0x1b6/0x2c0\n[ 250.223131] Code: fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 75 4f 41 56 48 8b 14 dd a0 4e 01 9f 48 89 ee 48 c7 c7 20 46 01 9f e8 cb 84d\n[ 250.225805] RSP: 0018:ffff888015ea7c08 EFLAGS: 00010286\n[ 250.226608] RAX: 0000000000000000 RBX: 0000000000000005 RCX: ffffffff9be93a95\n[ 250.227708] RDX: 1ffff1100d945138 RSI: 0000000000000008 RDI: ffff88806ca289c0\n[ 250.228993] RBP: ffffffff9f014a00 R08: 0000000000000001 R09: ffffed1002bd4f39\n[ 250.230043] R10: ffff888015ea79cf R11: 0000000000000001 R12: 0000000000000001\n[ 250.231185] R13: ffffffff9eea0520 R14: 0000000000000000 R15: ffff888015ea7cc8\n[ 250.232454] FS: 00007f3208f01540(0000) GS:ffff8880caf5a000(0000) knlGS:0000000000000000\n[ 250.233851] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 250.234856] CR2: 00007f32090a7421 CR3: 0000000004d63000 CR4: 00000000000006f0\n[ 250.236117] Call Trace:\n[ 250.236599] \u0026lt;TASK\u0026gt;\n[ 250.236967] ? trace_irq_enable.constprop.0+0xd4/0x130\n[ 250.237920] debug_object_assert_init+0x1f6/0x310\n[ 250.238762] ? __pfx_debug_object_assert_init+0x10/0x10\n[ 250.239658] ? __lock_acquire+0xdea/0x1c70\n[ 250.240369] __try_to_del_timer_sync+0x69/0x140\n[ 250.241172] ? __pfx___try_to_del_timer_sync+0x10/0x10\n[ 250.242058] ? __timer_delete_sync+0xc6/0x120\n[ 250.242842] ? lock_acquire+0x30/0x80\n[ 250.243474] ? __timer_delete_sync+0xc6/0x120\n[ 250.244262] __timer_delete_sync+0x98/0x120\n[ 250.245015] HFC_cleanup+0x10/0x20 [hfcpci]\n[ 250.245704] __do_sys_delete_module+0x348/0x510\n[ 250.246461] ? __pfx___do_sys_delete_module+0x10/0x10\n[ 250.247338] do_syscall_64+0xc1/0x360\n[ 250.247924] entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nFix this by initializing hfc_tl timer with DEFINE_TIMER macro.\nAlso, use mod_timer instead of manual timeout update.(CVE-2025-39833)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nplatform/x86/amd/pmc: Add support for Van Gogh SoC\n\nThe ROG Xbox Ally (non-X) SoC features a similar architecture to the\nSteam Deck. While the Steam Deck supports S3 (s2idle causes a crash),\nthis support was dropped by the Xbox Ally which only S0ix suspend.\n\nSince the handler is missing here, this causes the device to not suspend\nand the AMD GPU driver to crash while trying to resume afterwards due to\na power hang.(CVE-2025-68334)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nteam: Move team device type change at the end of team_port_add\n\nAttempting to add a port device that is already up will expectedly fail,\nbut not before modifying the team device header_ops.\n\nIn the case of the syzbot reproducer the gre0 device is\nalready in state UP when it attempts to add it as a\nport device of team0, this fails but before that\nheader_ops-\u0026gt;create of team0 is changed from eth_header to ipgre_header\nin the call to team_dev_type_check_change.\n\nLater when we end up in ipgre_header() struct ip_tunnel* points to nonsense\nas the private data of the device still holds a struct team.\n\nExample sequence of iproute2 commands to reproduce the hang/BUG():\nip link add dev team0 type team\nip link add dev gre0 type gre\nip link set dev gre0 up\nip link set dev gre0 master team0\nip link set dev team0 up\nping -I team0 1.1.1.1\n\nMove team_dev_type_check_change down where all other checks have passed\nas it changes the dev type with no way to restore it in case\none of the checks that follow it fail.\n\nAlso make sure to preserve the origial mtu assignment:\n - If port_dev is not the same type as dev, dev takes mtu from port_dev\n - If port_dev is the same type as dev, port_dev takes mtu from dev\n\nThis is done by adding a conditional before the call to dev_set_mtu\nto prevent it from assigning port_dev-\u0026gt;mtu = dev-\u0026gt;mtu and instead\nletting team_dev_type_check_change assign dev-\u0026gt;mtu = port_dev-\u0026gt;mtu.\nThe conditional is needed because the patch moves the call to\nteam_dev_type_check_change past dev_set_mtu.\n\nTesting:\n - team device driver in-tree selftests\n - Add/remove various devices as slaves of team device\n - syzbot(CVE-2025-68340)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmlxsw: spectrum_router: Fix neighbour use-after-free\n\nWe sometimes observe use-after-free when dereferencing a neighbour [1].\nThe problem seems to be that the driver stores a pointer to the\nneighbour, but without holding a reference on it. A reference is only\ntaken when the neighbour is used by a nexthop.\n\nFix by simplifying the reference counting scheme. Always take a\nreference when storing a neighbour pointer in a neighbour entry. Avoid\ntaking a referencing when the neighbour is used by a nexthop as the\nneighbour entry associated with the nexthop already holds a reference.\n\nTested by running the test that uncovered the problem over 300 times.\nWithout this patch the problem was reproduced after a handful of\niterations.\n\n[1]\nBUG: KASAN: slab-use-after-free in mlxsw_sp_neigh_entry_update+0x2d4/0x310\nRead of size 8 at addr ffff88817f8e3420 by task ip/3929\n\nCPU: 3 UID: 0 PID: 3929 Comm: ip Not tainted 6.18.0-rc4-virtme-g36b21a067510 #3 PREEMPT(full)\nHardware name: Nvidia SN5600/VMOD0013, BIOS 5.13 05/31/2023\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x6f/0xa0\n print_address_description.constprop.0+0x6e/0x300\n print_report+0xfc/0x1fb\n kasan_report+0xe4/0x110\n mlxsw_sp_neigh_entry_update+0x2d4/0x310\n mlxsw_sp_router_rif_gone_sync+0x35f/0x510\n mlxsw_sp_rif_destroy+0x1ea/0x730\n mlxsw_sp_inetaddr_port_vlan_event+0xa1/0x1b0\n __mlxsw_sp_inetaddr_lag_event+0xcc/0x130\n __mlxsw_sp_inetaddr_event+0xf5/0x3c0\n mlxsw_sp_router_netdevice_event+0x1015/0x1580\n notifier_call_chain+0xcc/0x150\n call_netdevice_notifiers_info+0x7e/0x100\n __netdev_upper_dev_unlink+0x10b/0x210\n netdev_upper_dev_unlink+0x79/0xa0\n vrf_del_slave+0x18/0x50\n do_set_master+0x146/0x7d0\n do_setlink.isra.0+0x9a0/0x2880\n rtnl_newlink+0x637/0xb20\n rtnetlink_rcv_msg+0x6fe/0xb90\n netlink_rcv_skb+0x123/0x380\n netlink_unicast+0x4a3/0x770\n netlink_sendmsg+0x75b/0xc90\n __sock_sendmsg+0xbe/0x160\n ____sys_sendmsg+0x5b2/0x7d0\n ___sys_sendmsg+0xfd/0x180\n __sys_sendmsg+0x124/0x1c0\n do_syscall_64+0xbb/0xfd0\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n[...]\n\nAllocated by task 109:\n kasan_save_stack+0x30/0x50\n kasan_save_track+0x14/0x30\n __kasan_kmalloc+0x7b/0x90\n __kmalloc_noprof+0x2c1/0x790\n neigh_alloc+0x6af/0x8f0\n ___neigh_create+0x63/0xe90\n mlxsw_sp_nexthop_neigh_init+0x430/0x7e0\n mlxsw_sp_nexthop_type_init+0x212/0x960\n mlxsw_sp_nexthop6_group_info_init.constprop.0+0x81f/0x1280\n mlxsw_sp_nexthop6_group_get+0x392/0x6a0\n mlxsw_sp_fib6_entry_create+0x46a/0xfd0\n mlxsw_sp_router_fib6_replace+0x1ed/0x5f0\n mlxsw_sp_router_fib6_event_work+0x10a/0x2a0\n process_one_work+0xd57/0x1390\n worker_thread+0x4d6/0xd40\n kthread+0x355/0x5b0\n ret_from_fork+0x1d4/0x270\n ret_from_fork_asm+0x11/0x20\n\nFreed by task 154:\n kasan_save_stack+0x30/0x50\n kasan_save_track+0x14/0x30\n __kasan_save_free_info+0x3b/0x60\n __kasan_slab_free+0x43/0x70\n kmem_cache_free_bulk.part.0+0x1eb/0x5e0\n kvfree_rcu_bulk+0x1f2/0x260\n kfree_rcu_work+0x130/0x1b0\n process_one_work+0xd57/0x1390\n worker_thread+0x4d6/0xd40\n kthread+0x355/0x5b0\n ret_from_fork+0x1d4/0x270\n ret_from_fork_asm+0x11/0x20\n\nLast potentially related work creation:\n kasan_save_stack+0x30/0x50\n kasan_record_aux_stack+0x8c/0xa0\n kvfree_call_rcu+0x93/0x5b0\n mlxsw_sp_router_neigh_event_work+0x67d/0x860\n process_one_work+0xd57/0x1390\n worker_thread+0x4d6/0xd40\n kthread+0x355/0x5b0\n ret_from_fork+0x1d4/0x270\n ret_from_fork_asm+0x11/0x20(CVE-2025-68801)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsvcrdma: bound check rq_pages index in inline path\n\nsvc_rdma_copy_inline_range indexed rqstp-\u0026gt;rq_pages[rc_curpage] without\nverifying rc_curpage stays within the allocated page array. Add guards\nbefore the first use and after advancing to a new page.(CVE-2025-71068)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niavf: fix off-by-one issues in iavf_config_rss_reg()\n\nThere are off-by-one bugs when configuring RSS hash key and lookup\ntable, causing out-of-bounds reads to memory [1] and out-of-bounds\nwrites to device registers.\n\nBefore commit 43a3d9ba34c9 (\u0026quot;i40evf: Allow PF driver to configure RSS\u0026quot;),\nthe loop upper bounds were:\n i \u0026lt;= I40E_VFQF_{HKEY,HLUT}_MAX_INDEX\nwhich is safe since the value is the last valid index.\n\nThat commit changed the bounds to:\n i \u0026lt;= adapter-\u0026gt;rss_{key,lut}_size / 4\nwhere `rss_{key,lut}_size / 4` is the number of dwords, so the last\nvalid index is `(rss_{key,lut}_size / 4) - 1`. Therefore, using `\u0026lt;=`\naccesses one element past the end.\n\nFix the issues by using `\u0026lt;` instead of `\u0026lt;=`, ensuring we do not exceed\nthe bounds.\n\n[1] KASAN splat about rss_key_size off-by-one\n BUG: KASAN: slab-out-of-bounds in iavf_config_rss+0x619/0x800\n Read of size 4 at addr ffff888102c50134 by task kworker/u8:6/63\n\n CPU: 0 UID: 0 PID: 63 Comm: kworker/u8:6 Not tainted 6.18.0-rc2-enjuk-tnguy-00378-g3005f5b77652-dirty #156 PREEMPT(voluntary)\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n Workqueue: iavf iavf_watchdog_task\n Call Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x6f/0xb0\n print_report+0x170/0x4f3\n kasan_report+0xe1/0x1a0\n iavf_config_rss+0x619/0x800\n iavf_watchdog_task+0x2be7/0x3230\n process_one_work+0x7fd/0x1420\n worker_thread+0x4d1/0xd40\n kthread+0x344/0x660\n ret_from_fork+0x249/0x320\n ret_from_fork_asm+0x1a/0x30\n \u0026lt;/TASK\u0026gt;\n\n Allocated by task 63:\n kasan_save_stack+0x30/0x50\n kasan_save_track+0x14/0x30\n __kasan_kmalloc+0x7f/0x90\n __kmalloc_noprof+0x246/0x6f0\n iavf_watchdog_task+0x28fc/0x3230\n process_one_work+0x7fd/0x1420\n worker_thread+0x4d1/0xd40\n kthread+0x344/0x660\n ret_from_fork+0x249/0x320\n ret_from_fork_asm+0x1a/0x30\n\n The buggy address belongs to the object at ffff888102c50100\n which belongs to the cache kmalloc-64 of size 64\n The buggy address is located 0 bytes to the right of\n allocated 52-byte region [ffff888102c50100, ffff888102c50134)\n\n The buggy address belongs to the physical page:\n page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x102c50\n flags: 0x200000000000000(node=0|zone=2)\n page_type: f5(slab)\n raw: 0200000000000000 ffff8881000418c0 dead000000000122 0000000000000000\n raw: 0000000000000000 0000000080200020 00000000f5000000 0000000000000000\n page dumped because: kasan: bad access detected\n\n Memory state around the buggy address:\n ffff888102c50000: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc\n ffff888102c50080: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc\n \u0026gt;ffff888102c50100: 00 00 00 00 00 00 04 fc fc fc fc fc fc fc fc fc\n ^\n ffff888102c50180: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc\n ffff888102c50200: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc(CVE-2025-71087)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/i915/gem: Zero-initialize the eb.vma array in i915_gem_do_execbuffer\n\nInitialize the eb.vma array with values of 0 when the eb structure is\nfirst set up. In particular, this sets the eb-\u0026gt;vma[i].vma pointers to\nNULL, simplifying cleanup and getting rid of the bug described below.\n\nDuring the execution of eb_lookup_vmas(), the eb-\u0026gt;vma array is\nsuccessively filled up with struct eb_vma objects. This process includes\ncalling eb_add_vma(), which might fail; however, even in the event of\nfailure, eb-\u0026gt;vma[i].vma is set for the currently processed buffer.\n\nIf eb_add_vma() fails, eb_lookup_vmas() returns with an error, which\nprompts a call to eb_release_vmas() to clean up the mess. Since\neb_lookup_vmas() might fail during processing any (possibly not first)\nbuffer, eb_release_vmas() checks whether a buffer\u0026apos;s vma is NULL to know\nat what point did the lookup function fail.\n\nIn eb_lookup_vmas(), eb-\u0026gt;vma[i].vma is set to NULL if either the helper\nfunction eb_lookup_vma() or eb_validate_vma() fails. eb-\u0026gt;vma[i+1].vma is\nset to NULL in case i915_gem_object_userptr_submit_init() fails; the\ncurrent one needs to be cleaned up by eb_release_vmas() at this point,\nso the next one is set. If eb_add_vma() fails, neither the current nor\nthe next vma is set to NULL, which is a source of a NULL deref bug\ndescribed in the issue linked in the Closes tag.\n\nWhen entering eb_lookup_vmas(), the vma pointers are set to the slab\npoison value, instead of NULL. This doesn\u0026apos;t matter for the actual\nlookup, since it gets overwritten anyway, however the eb_release_vmas()\nfunction only recognizes NULL as the stopping value, hence the pointers\nare being set to NULL as they go in case of intermediate failure. This\npatch changes the approach to filling them all with NULL at the start\ninstead, rather than handling that manually during failure.\n\n(cherry picked from commit 08889b706d4f0b8d2352b7ca29c2d8df4d0787cd)(CVE-2025-71130)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: dsa: properly keep track of conduit reference\n\nProblem description\n-------------------\n\nDSA has a mumbo-jumbo of reference handling of the conduit net device\nand its kobject which, sadly, is just wrong and doesn\u0026apos;t make sense.\n\nThere are two distinct problems.\n\n1. The OF path, which uses of_find_net_device_by_node(), never releases\n the elevated refcount on the conduit\u0026apos;s kobject. Nominally, the OF and\n non-OF paths should result in objects having identical reference\n counts taken, and it is already suspicious that\n dsa_dev_to_net_device() has a put_device() call which is missing in\n dsa_port_parse_of(), but we can actually even verify that an issue\n exists. With CONFIG_DEBUG_KOBJECT_RELEASE=y, if we run this command\n \u0026quot;before\u0026quot; and \u0026quot;after\u0026quot; applying this patch:\n\n(unbind the conduit driver for net device eno2)\necho 0000:00:00.2 \u0026gt; /sys/bus/pci/drivers/fsl_enetc/unbind\n\nwe see these lines in the output diff which appear only with the patch\napplied:\n\nkobject: \u0026apos;eno2\u0026apos; (ffff002009a3a6b8): kobject_release, parent 0000000000000000 (delayed 1000)\nkobject: \u0026apos;109\u0026apos; (ffff0020099d59a0): kobject_release, parent 0000000000000000 (delayed 1000)\n\n2. After we find the conduit interface one way (OF) or another (non-OF),\n it can get unregistered at any time, and DSA remains with a long-lived,\n but in this case stale, cpu_dp-\u0026gt;conduit pointer. Holding the net\n device\u0026apos;s underlying kobject isn\u0026apos;t actually of much help, it just\n prevents it from being freed (but we never need that kobject\n directly). What helps us to prevent the net device from being\n unregistered is the parallel netdev reference mechanism (dev_hold()\n and dev_put()).\n\nActually we actually use that netdev tracker mechanism implicitly on\nuser ports since commit 2f1e8ea726e9 (\u0026quot;net: dsa: link interfaces with\nthe DSA master to get rid of lockdep warnings\u0026quot;), via netdev_upper_dev_link().\nBut time still passes at DSA switch probe time between the initial\nof_find_net_device_by_node() code and the user port creation time, time\nduring which the conduit could unregister itself and DSA wouldn\u0026apos;t know\nabout it.\n\nSo we have to run of_find_net_device_by_node() under rtnl_lock() to\nprevent that from happening, and release the lock only with the netdev\ntracker having acquired the reference.\n\nDo we need to keep the reference until dsa_unregister_switch() /\ndsa_switch_shutdown()?\n1: Maybe yes. A switch device will still be registered even if all user\n ports failed to probe, see commit 86f8b1c01a0a (\u0026quot;net: dsa: Do not\n make user port errors fatal\u0026quot;), and the cpu_dp-\u0026gt;conduit pointers\n remain valid. I haven\u0026apos;t audited all call paths to see whether they\n will actually use the conduit in lack of any user port, but if they\n do, it seems safer to not rely on user ports for that reference.\n2. Definitely yes. We support changing the conduit which a user port is\n associated to, and we can get into a situation where we\u0026apos;ve moved all\n user ports away from a conduit, thus no longer hold any reference to\n it via the net device tracker. But we shouldn\u0026apos;t let it go nonetheless\n - see the next change in relation to dsa_tree_find_first_conduit()\n and LAG conduits which disappear.\n We have to be prepared to return to the physical conduit, so the CPU\n port must explicitly keep another reference to it. This is also to\n say: the user ports and their CPU ports may not always keep a\n reference to the same conduit net device, and both are needed.\n\nAs for the conduit\u0026apos;s kobject for the /sys/class/net/ entry, we don\u0026apos;t\ncare about it, we can release it as soon as we hold the net device\nobject itself.\n\nHistory and blame attribution\n-----------------------------\n\nThe code has been refactored so many times, it is very difficult to\nfollow and properly attribute a blame, but I\u0026apos;ll try to make a short\nhistory which I hope to be correct.\n\nWe have two distinct probing paths:\n- one for OF, introduced in 2016 i\n---truncated---(CVE-2025-71152)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix deadlock in wait_current_trans() due to ignored transaction type\n\nWhen wait_current_trans() is called during start_transaction(), it\ncurrently waits for a blocked transaction without considering whether\nthe given transaction type actually needs to wait for that particular\ntransaction state. The btrfs_blocked_trans_types[] array already defines\nwhich transaction types should wait for which transaction states, but\nthis check was missing in wait_current_trans().\n\nThis can lead to a deadlock scenario involving two transactions and\npending ordered extents:\n\n 1. Transaction A is in TRANS_STATE_COMMIT_DOING state\n\n 2. A worker processing an ordered extent calls start_transaction()\n with TRANS_JOIN\n\n 3. join_transaction() returns -EBUSY because Transaction A is in\n TRANS_STATE_COMMIT_DOING\n\n 4. Transaction A moves to TRANS_STATE_UNBLOCKED and completes\n\n 5. A new Transaction B is created (TRANS_STATE_RUNNING)\n\n 6. The ordered extent from step 2 is added to Transaction B\u0026apos;s\n pending ordered extents\n\n 7. Transaction B immediately starts commit by another task and\n enters TRANS_STATE_COMMIT_START\n\n 8. The worker finally reaches wait_current_trans(), sees Transaction B\n in TRANS_STATE_COMMIT_START (a blocked state), and waits\n unconditionally\n\n 9. However, TRANS_JOIN should NOT wait for TRANS_STATE_COMMIT_START\n according to btrfs_blocked_trans_types[]\n\n 10. Transaction B is waiting for pending ordered extents to complete\n\n 11. Deadlock: Transaction B waits for ordered extent, ordered extent\n waits for Transaction B\n\nThis can be illustrated by the following call stacks:\n CPU0 CPU1\n btrfs_finish_ordered_io()\n start_transaction(TRANS_JOIN)\n join_transaction()\n # -EBUSY (Transaction A is\n # TRANS_STATE_COMMIT_DOING)\n # Transaction A completes\n # Transaction B created\n # ordered extent added to\n # Transaction B\u0026apos;s pending list\n btrfs_commit_transaction()\n # Transaction B enters\n # TRANS_STATE_COMMIT_START\n # waiting for pending ordered\n # extents\n wait_current_trans()\n # waits for Transaction B\n # (should not wait!)\n\nTask bstore_kv_sync in btrfs_commit_transaction waiting for ordered\nextents:\n\n __schedule+0x2e7/0x8a0\n schedule+0x64/0xe0\n btrfs_commit_transaction+0xbf7/0xda0 [btrfs]\n btrfs_sync_file+0x342/0x4d0 [btrfs]\n __x64_sys_fdatasync+0x4b/0x80\n do_syscall_64+0x33/0x40\n entry_SYSCALL_64_after_hwframe+0x44/0xa9\n\nTask kworker in wait_current_trans waiting for transaction commit:\n\n Workqueue: btrfs-syno_nocow btrfs_work_helper [btrfs]\n __schedule+0x2e7/0x8a0\n schedule+0x64/0xe0\n wait_current_trans+0xb0/0x110 [btrfs]\n start_transaction+0x346/0x5b0 [btrfs]\n btrfs_finish_ordered_io.isra.0+0x49b/0x9c0 [btrfs]\n btrfs_work_helper+0xe8/0x350 [btrfs]\n process_one_work+0x1d3/0x3c0\n worker_thread+0x4d/0x3e0\n kthread+0x12d/0x150\n ret_from_fork+0x1f/0x30\n\nFix this by passing the transaction type to wait_current_trans() and\nchecking btrfs_blocked_trans_types[cur_trans-\u0026gt;state] against the given\ntype before deciding to wait. This ensures that transaction types which\nare allowed to join during certain blocked states will not unnecessarily\nwait and cause deadlocks.(CVE-2025-71194)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmacvlan: fix possible UAF in macvlan_forward_source()\n\nAdd RCU protection on (struct macvlan_source_entry)-\u0026gt;vlan.\n\nWhenever macvlan_hash_del_source() is called, we must clear\nentry-\u0026gt;vlan pointer before RCU grace period starts.\n\nThis allows macvlan_forward_source() to skip over\nentries queued for freeing.\n\nNote that macvlan_dev are already RCU protected, as they\nare embedded in a standard netdev (netdev_priv(ndev)).\n\nhttps: //lore.kernel.org/netdev/(CVE-2026-23001)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv4: ip_gre: make ipgre_header() robust\n\nAnalog to commit db5b4e39c4e6 (\u0026quot;ip6_gre: make ip6gre_header() robust\u0026quot;)\n\nOver the years, syzbot found many ways to crash the kernel\nin ipgre_header() [1].\n\nThis involves team or bonding drivers ability to dynamically\nchange their dev-\u0026gt;needed_headroom and/or dev-\u0026gt;hard_header_len\n\nIn this particular crash mld_newpack() allocated an skb\nwith a too small reserve/headroom, and by the time mld_sendpack()\nwas called, syzbot managed to attach an ipgre device.\n\n[1]\nskbuff: skb_under_panic: text:ffffffff89ea3cb7 len:2030915468 put:2030915372 head:ffff888058b43000 data:ffff887fdfa6e194 tail:0x120 end:0x6c0 dev:team0\n kernel BUG at net/core/skbuff.c:213 !\nOops: invalid opcode: 0000 [#1] SMP KASAN PTI\nCPU: 1 UID: 0 PID: 1322 Comm: kworker/1:9 Not tainted syzkaller #0 PREEMPT(full)\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025\nWorkqueue: mld mld_ifc_work\n RIP: 0010:skb_panic+0x157/0x160 net/core/skbuff.c:213\nCall Trace:\n \u0026lt;TASK\u0026gt;\n skb_under_panic net/core/skbuff.c:223 [inline]\n skb_push+0xc3/0xe0 net/core/skbuff.c:2641\n ipgre_header+0x67/0x290 net/ipv4/ip_gre.c:897\n dev_hard_header include/linux/netdevice.h:3436 [inline]\n neigh_connected_output+0x286/0x460 net/core/neighbour.c:1618\n NF_HOOK_COND include/linux/netfilter.h:307 [inline]\n ip6_output+0x340/0x550 net/ipv6/ip6_output.c:247\n NF_HOOK+0x9e/0x380 include/linux/netfilter.h:318\n mld_sendpack+0x8d4/0xe60 net/ipv6/mcast.c:1855\n mld_send_cr net/ipv6/mcast.c:2154 [inline]\n mld_ifc_work+0x83e/0xd60 net/ipv6/mcast.c:2693\n process_one_work kernel/workqueue.c:3257 [inline]\n process_scheduled_works+0xad1/0x1770 kernel/workqueue.c:3340\n worker_thread+0x8a0/0xda0 kernel/workqueue.c:3421\n kthread+0x711/0x8a0 kernel/kthread.c:463\n ret_from_fork+0x510/0xa50 arch/x86/kernel/process.c:158\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246(CVE-2026-23011)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/page_alloc: prevent pcp corruption with SMP=n\n\nThe kernel test robot has reported:\n\n BUG: spinlock trylock failure on UP on CPU#0, kcompactd0/28\n lock: 0xffff888807e35ef0, .magic: dead4ead, .owner: kcompactd0/28, .owner_cpu: 0\n CPU: 0 UID: 0 PID: 28 Comm: kcompactd0 Not tainted 6.18.0-rc5-00127-ga06157804399 #1 PREEMPT 8cc09ef94dcec767faa911515ce9e609c45db470\n Call Trace:\n \u0026lt;IRQ\u0026gt;\n __dump_stack (lib/dump_stack.c:95)\n dump_stack_lvl (lib/dump_stack.c:123)\n dump_stack (lib/dump_stack.c:130)\n spin_dump (kernel/locking/spinlock_debug.c:71)\n do_raw_spin_trylock (kernel/locking/spinlock_debug.c:?)\n _raw_spin_trylock (include/linux/spinlock_api_smp.h:89 kernel/locking/spinlock.c:138)\n __free_frozen_pages (mm/page_alloc.c:2973)\n ___free_pages (mm/page_alloc.c:5295)\n __free_pages (mm/page_alloc.c:5334)\n tlb_remove_table_rcu (include/linux/mm.h:? include/linux/mm.h:3122 include/asm-generic/tlb.h:220 mm/mmu_gather.c:227 mm/mmu_gather.c:290)\n ? __cfi_tlb_remove_table_rcu (mm/mmu_gather.c:289)\n ? rcu_core (kernel/rcu/tree.c:?)\n rcu_core (include/linux/rcupdate.h:341 kernel/rcu/tree.c:2607 kernel/rcu/tree.c:2861)\n rcu_core_si (kernel/rcu/tree.c:2879)\n handle_softirqs (arch/x86/include/asm/jump_label.h:36 include/trace/events/irq.h:142 kernel/softirq.c:623)\n __irq_exit_rcu (arch/x86/include/asm/jump_label.h:36 kernel/softirq.c:725)\n irq_exit_rcu (kernel/softirq.c:741)\n sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1052)\n \u0026lt;/IRQ\u0026gt;\n \u0026lt;TASK\u0026gt;\n RIP: 0010:_raw_spin_unlock_irqrestore (arch/x86/include/asm/preempt.h:95 include/linux/spinlock_api_smp.h:152 kernel/locking/spinlock.c:194)\n free_pcppages_bulk (mm/page_alloc.c:1494)\n drain_pages_zone (include/linux/spinlock.h:391 mm/page_alloc.c:2632)\n __drain_all_pages (mm/page_alloc.c:2731)\n drain_all_pages (mm/page_alloc.c:2747)\n kcompactd (mm/compaction.c:3115)\n kthread (kernel/kthread.c:465)\n ? __cfi_kcompactd (mm/compaction.c:3166)\n ? __cfi_kthread (kernel/kthread.c:412)\n ret_from_fork (arch/x86/kernel/process.c:164)\n ? __cfi_kthread (kernel/kthread.c:412)\n ret_from_fork_asm (arch/x86/entry/entry_64.S:255)\n \u0026lt;/TASK\u0026gt;\n\nMatthew has analyzed the report and identified that in drain_page_zone()\nwe are in a section protected by spin_lock(\u0026amp;pcp-\u0026gt;lock) and then get an\ninterrupt that attempts spin_trylock() on the same lock. The code is\ndesigned to work this way without disabling IRQs and occasionally fail the\ntrylock with a fallback. However, the SMP=n spinlock implementation\nassumes spin_trylock() will always succeed, and thus it\u0026apos;s normally a\nno-op. Here the enabled lock debugging catches the problem, but otherwise\nit could cause a corruption of the pcp structure.\n\nThe problem has been introduced by commit 574907741599 (\u0026quot;mm/page_alloc:\nleave IRQs enabled for per-cpu page allocations\u0026quot;). The pcp locking scheme\nrecognizes the need for disabling IRQs to prevent nesting spin_trylock()\nsections on SMP=n, but the need to prevent the nesting in spin_lock() has\nnot been recognized. Fix it by introducing local wrappers that change the\nspin_lock() to spin_lock_iqsave() with SMP=n and use them in all places\nthat do spin_lock(\u0026amp;pcp-\u0026gt;lock).\n\n[(CVE-2026-23025)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: hv_netvsc: reject RSS hash key programming without RX indirection table\n\nRSS configuration requires a valid RX indirection table. When the device\nreports a single receive queue, rndis_filter_device_add() does not\nallocate an indirection table, accepting RSS hash key updates in this\nstate leads to a hang.\n\nFix this by gating netvsc_set_rxfh() on ndc-\u0026gt;rx_table_sz and return\n-EOPNOTSUPP when the table is absent. This aligns set_rxfh with the device\ncapabilities and prevents incorrect behavior.(CVE-2026-23054)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: Enforce that teql can only be used as root qdisc\n\nDesign intent of teql is that it is only supposed to be used as root qdisc.\nWe need to check for that constraint.\n\nAlthough not important, I will describe the scenario that unearthed this\nissue for the curious.\n\nGangMin Kim \u0026lt;(CVE-2026-23074)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/hugetlb: fix hugetlb_pmd_shared()\n\nPatch series \u0026quot;mm/hugetlb: fixes for PMD table sharing (incl. using\nmmu_gather)\u0026quot;, v3.\n\nOne functional fix, one performance regression fix, and two related\ncomment fixes.\n\nI cleaned up my prototype I recently shared [1] for the performance fix,\ndeferring most of the cleanups I had in the prototype to a later point. \nWhile doing that I identified the other things.\n\nThe goal of this patch set is to be backported to stable trees \u0026quot;fairly\u0026quot;\neasily. At least patch #1 and #4.\n\nPatch #1 fixes hugetlb_pmd_shared() not detecting any sharing\nPatch #2 + #3 are simple comment fixes that patch #4 interacts with.\nPatch #4 is a fix for the reported performance regression due to excessive\nIPI broadcasts during fork()+exit().\n\nThe last patch is all about TLB flushes, IPIs and mmu_gather.\nRead: complicated\n\nThere are plenty of cleanups in the future to be had + one reasonable\noptimization on x86. But that\u0026apos;s all out of scope for this series.\n\nRuntime tested, with a focus on fixing the performance regression using\nthe original reproducer [2] on x86.\n\n\nThis patch (of 4):\n\nWe switched from (wrongly) using the page count to an independent shared\ncount. Now, shared page tables have a refcount of 1 (excluding\nspeculative references) and instead use ptdesc-\u0026gt;pt_share_count to identify\nsharing.\n\nWe didn\u0026apos;t convert hugetlb_pmd_shared(), so right now, we would never\ndetect a shared PMD table as such, because sharing/unsharing no longer\ntouches the refcount of a PMD table.\n\nPage migration, like mbind() or migrate_pages() would allow for migrating\nfolios mapped into such shared PMD tables, even though the folios are not\nexclusive. In smaps we would account them as \u0026quot;private\u0026quot; although they are\n\u0026quot;shared\u0026quot;, and we would be wrongly setting the PM_MMAP_EXCLUSIVE in the\npagemap interface.\n\nFix it by properly using ptdesc_pmd_is_shared() in hugetlb_pmd_shared().(CVE-2026-23100)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Add recursion protection in kernel stack trace recording\n\nA bug was reported about an infinite recursion caused by tracing the rcu\nevents with the kernel stack trace trigger enabled. The stack trace code\ncalled back into RCU which then called the stack trace again.\n\nExpand the ftrace recursion protection to add a set of bits to protect\nevents from recursion. Each bit represents the context that the event is\nin (normal, softirq, interrupt and NMI).\n\nHave the stack trace code use the interrupt context to protect against\nrecursion.\n\nNote, the bug showed an issue in both the RCU code as well as the tracing\nstacktrace code. This only handles the tracing stack trace side of the\nbug. The RCU fix will be handled separately.(CVE-2026-23138)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntcp: secure_seq: add back ports to TS offset\n\nThis reverts 28ee1b746f49 (\u0026quot;secure_seq: downgrade to per-host timestamp offsets\u0026quot;)\n\ntcp_tw_recycle went away in 2017.\n\nZhouyan Deng reported off-path TCP source port leakage via\nSYN cookie side-channel that can be fixed in multiple ways.\n\nOne of them is to bring back TCP ports in TS offset randomization.\n\nAs a bonus, we perform a single siphash() computation\nto provide both an ISN and a TS offset.(CVE-2026-23247)\n\nIn the Linux kernel, a vulnerability exists in the AppArmor module\u0026apos;s unpack_pdb function. The vulnerability occurs due to failure to validate that DFA start states are within bounds, which can lead to out-of-bound reads. An attacker can exploit this vulnerability through specially crafted policy files, potentially leading to information disclosure or system crashes.(CVE-2026-23269)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_tables: unconditionally bump set-\u0026gt;nelems before insertion\n\nIn case that the set is full, a new element gets published then removed\nwithout waiting for the RCU grace period, while RCU reader can be\nwalking over it already.\n\nTo address this issue, add the element transaction even if set is full,\nbut toggle the set_full flag to report -ENFILE so the abort path safely\nunwinds the set to its previous state.\n\nAs for element updates, decrement set-\u0026gt;nelems to restore it.\n\nA simpler fix is to call synchronize_rcu() in the error path.\nHowever, with a large batch adding elements to already maxed-out set,\nthis could cause noticeable slowdown of such batches.(CVE-2026-23272)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: usb: kaweth: validate USB endpoints\n\nThe kaweth driver should validate that the device it is probing has the\nproper number and types of USB endpoints it is expecting before it binds\nto it. If a malicious device were to not have the same urbs the driver\nwill crash later on when it blindly accesses these endpoints.(CVE-2026-23312)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: sched: avoid qdisc_reset_all_tx_gt() vs dequeue race for lockless qdiscs\n\nWhen shrinking the number of real tx queues,\nnetif_set_real_num_tx_queues() calls qdisc_reset_all_tx_gt() to flush\nqdiscs for queues which will no longer be used.\n\nqdisc_reset_all_tx_gt() currently serializes qdisc_reset() with\nqdisc_lock(). However, for lockless qdiscs, the dequeue path is\nserialized by qdisc_run_begin/end() using qdisc-\u0026gt;seqlock instead, so\nqdisc_reset() can run concurrently with __qdisc_run() and free skbs\nwhile they are still being dequeued, leading to UAF.\n\nThis can easily be reproduced on e.g. virtio-net by imposing heavy\ntraffic while frequently changing the number of queue pairs:\n\n iperf3 -ub0 -c $peer -t 0 \u0026amp;\n while :; do\n ethtool -L eth0 combined 1\n ethtool -L eth0 combined 2\n done\n\nWith KASAN enabled, this leads to reports like:\n\n BUG: KASAN: slab-use-after-free in __qdisc_run+0x133f/0x1760\n ...\n Call Trace:\n \u0026lt;TASK\u0026gt;\n ...\n __qdisc_run+0x133f/0x1760\n __dev_queue_xmit+0x248f/0x3550\n ip_finish_output2+0xa42/0x2110\n ip_output+0x1a7/0x410\n ip_send_skb+0x2e6/0x480\n udp_send_skb+0xb0a/0x1590\n udp_sendmsg+0x13c9/0x1fc0\n ...\n \u0026lt;/TASK\u0026gt;\n\n Allocated by task 1270 on cpu 5 at 44.558414s:\n ...\n alloc_skb_with_frags+0x84/0x7c0\n sock_alloc_send_pskb+0x69a/0x830\n __ip_append_data+0x1b86/0x48c0\n ip_make_skb+0x1e8/0x2b0\n udp_sendmsg+0x13a6/0x1fc0\n ...\n\n Freed by task 1306 on cpu 3 at 44.558445s:\n ...\n kmem_cache_free+0x117/0x5e0\n pfifo_fast_reset+0x14d/0x580\n qdisc_reset+0x9e/0x5f0\n netif_set_real_num_tx_queues+0x303/0x840\n virtnet_set_channels+0x1bf/0x260 [virtio_net]\n ethnl_set_channels+0x684/0xae0\n ethnl_default_set_doit+0x31a/0x890\n ...\n\nSerialize qdisc_reset_all_tx_gt() against the lockless dequeue path by\ntaking qdisc-\u0026gt;seqlock for TCQ_F_NOLOCK qdiscs, matching the\nserialization model already used by dev_reset_queue().\n\nAdditionally clear QDISC_STATE_NON_EMPTY after reset so the qdisc state\nreflects an empty queue, avoiding needless re-scheduling.(CVE-2026-23340)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: act_ife: Fix metalist update behavior\n\nWhenever an ife action replace changes the metalist, instead of\nreplacing the old data on the metalist, the current ife code is appending\nthe new metadata. Aside from being innapropriate behavior, this may lead\nto an unbounded addition of metadata to the metalist which might cause an\nout of bounds error when running the encode op:\n\n[ 138.423369][ C1] ==================================================================\n[ 138.424317][ C1] BUG: KASAN: slab-out-of-bounds in ife_tlv_meta_encode (net/ife/ife.c:168)\n[ 138.424906][ C1] Write of size 4 at addr ffff8880077f4ffe by task ife_out_out_bou/255\n[ 138.425778][ C1] CPU: 1 UID: 0 PID: 255 Comm: ife_out_out_bou Not tainted 7.0.0-rc1-00169-gfbdfa8da05b6 #624 PREEMPT(full)\n[ 138.425795][ C1] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011\n[ 138.425800][ C1] Call Trace:\n[ 138.425804][ C1] \u0026lt;IRQ\u0026gt;\n[ 138.425808][ C1] dump_stack_lvl (lib/dump_stack.c:122)\n[ 138.425828][ C1] print_report (mm/kasan/report.c:379 mm/kasan/report.c:482)\n[ 138.425839][ C1] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)\n[ 138.425844][ C1] ? __virt_addr_valid (./arch/x86/include/asm/preempt.h:95 (discriminator 1) ./include/linux/rcupdate.h:975 (discriminator 1) ./include/linux/mmzone.h:2207 (discriminator 1) arch/x86/mm/physaddr.c:54 (discriminator 1))\n[ 138.425853][ C1] ? ife_tlv_meta_encode (net/ife/ife.c:168)\n[ 138.425859][ C1] kasan_report (mm/kasan/report.c:221 mm/kasan/report.c:597)\n[ 138.425868][ C1] ? ife_tlv_meta_encode (net/ife/ife.c:168)\n[ 138.425878][ C1] kasan_check_range (mm/kasan/generic.c:186 (discriminator 1) mm/kasan/generic.c:200 (discriminator 1))\n[ 138.425884][ C1] __asan_memset (mm/kasan/shadow.c:84 (discriminator 2))\n[ 138.425889][ C1] ife_tlv_meta_encode (net/ife/ife.c:168)\n[ 138.425893][ C1] ? ife_tlv_meta_encode (net/ife/ife.c:171)\n[ 138.425898][ C1] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)\n[ 138.425903][ C1] ife_encode_meta_u16 (net/sched/act_ife.c:57)\n[ 138.425910][ C1] ? __pfx_do_raw_spin_lock (kernel/locking/spinlock_debug.c:114)\n[ 138.425916][ C1] ? __asan_memcpy (mm/kasan/shadow.c:105 (discriminator 3))\n[ 138.425921][ C1] ? __pfx_ife_encode_meta_u16 (net/sched/act_ife.c:45)\n[ 138.425927][ C1] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)\n[ 138.425931][ C1] tcf_ife_act (net/sched/act_ife.c:847 net/sched/act_ife.c:879)\n\nTo solve this issue, fix the replace behavior by adding the metalist to\nthe ife rcu data structure.(CVE-2026-23378)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nice: Fix memory leak in ice_set_ringparam()\n\nIn ice_set_ringparam, tx_rings and xdp_rings are allocated before\nrx_rings. If the allocation of rx_rings fails, the code jumps to\nthe done label leaking both tx_rings and xdp_rings. Furthermore, if\nthe setup of an individual Rx ring fails during the loop, the code jumps\nto the free_tx label which releases tx_rings but leaks xdp_rings.\n\nFix this by introducing a free_xdp label and updating the error paths to\nensure both xdp_rings and tx_rings are properly freed if rx_rings\nallocation or setup fails.\n\nCompile tested only. Issue found using a prototype static analysis tool\nand code review.(CVE-2026-23389)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\napparmor: fix side-effect bug in match_char() macro usage\n\nThe match_char() macro evaluates its character parameter multiple\ntimes when traversing differential encoding chains. When invoked\nwith *str++, the string pointer advances on each iteration of the\ninner do-while loop, causing the DFA to check different characters\nat each iteration and therefore skip input characters.\nThis results in out-of-bounds reads when the pointer advances past\nthe input buffer boundary.\n\n[ 94.984676] ==================================================================\n[ 94.985301] BUG: KASAN: slab-out-of-bounds in aa_dfa_match+0x5ae/0x760\n[ 94.985655] Read of size 1 at addr ffff888100342000 by task file/976\n\n[ 94.986319] CPU: 7 UID: 1000 PID: 976 Comm: file Not tainted 6.19.0-rc7-next-20260127 #1 PREEMPT(lazy)\n[ 94.986322] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n[ 94.986329] Call Trace:\n[ 94.986341] \u0026lt;TASK\u0026gt;\n[ 94.986347] dump_stack_lvl+0x5e/0x80\n[ 94.986374] print_report+0xc8/0x270\n[ 94.986384] ? aa_dfa_match+0x5ae/0x760\n[ 94.986388] kasan_report+0x118/0x150\n[ 94.986401] ? aa_dfa_match+0x5ae/0x760\n[ 94.986405] aa_dfa_match+0x5ae/0x760\n[ 94.986408] __aa_path_perm+0x131/0x400\n[ 94.986418] aa_path_perm+0x219/0x2f0\n[ 94.986424] apparmor_file_open+0x345/0x570\n[ 94.986431] security_file_open+0x5c/0x140\n[ 94.986442] do_dentry_open+0x2f6/0x1120\n[ 94.986450] vfs_open+0x38/0x2b0\n[ 94.986453] ? may_open+0x1e2/0x2b0\n[ 94.986466] path_openat+0x231b/0x2b30\n[ 94.986469] ? __x64_sys_openat+0xf8/0x130\n[ 94.986477] do_file_open+0x19d/0x360\n[ 94.986487] do_sys_openat2+0x98/0x100\n[ 94.986491] __x64_sys_openat+0xf8/0x130\n[ 94.986499] do_syscall_64+0x8e/0x660\n[ 94.986515] ? count_memcg_events+0x15f/0x3c0\n[ 94.986526] ? srso_alias_return_thunk+0x5/0xfbef5\n[ 94.986540] ? handle_mm_fault+0x1639/0x1ef0\n[ 94.986551] ? vma_start_read+0xf0/0x320\n[ 94.986558] ? srso_alias_return_thunk+0x5/0xfbef5\n[ 94.986561] ? srso_alias_return_thunk+0x5/0xfbef5\n[ 94.986563] ? fpregs_assert_state_consistent+0x50/0xe0\n[ 94.986572] ? srso_alias_return_thunk+0x5/0xfbef5\n[ 94.986574] ? arch_exit_to_user_mode_prepare+0x9/0xb0\n[ 94.986587] ? srso_alias_return_thunk+0x5/0xfbef5\n[ 94.986588] ? irqentry_exit+0x3c/0x590\n[ 94.986595] entry_SYSCALL_64_after_hwframe+0x76/0x7e\n[ 94.986597] RIP: 0033:0x7fda4a79c3ea\n\nFix by extracting the character value before invoking match_char,\nensuring single evaluation per outer loop.(CVE-2026-23406)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\napparmor: fix missing bounds check on DEFAULT table in verify_dfa()\n\nThe verify_dfa() function only checks DEFAULT_TABLE bounds when the state\nis not differentially encoded.\n\nWhen the verification loop traverses the differential encoding chain,\nit reads k = DEFAULT_TABLE[j] and uses k as an array index without\nvalidation. A malformed DFA with DEFAULT_TABLE[j] \u0026gt;= state_count,\ntherefore, causes both out-of-bounds reads and writes.\n\n[ 57.179855] ==================================================================\n[ 57.180549] BUG: KASAN: slab-out-of-bounds in verify_dfa+0x59a/0x660\n[ 57.180904] Read of size 4 at addr ffff888100eadec4 by task su/993\n\n[ 57.181554] CPU: 1 UID: 0 PID: 993 Comm: su Not tainted 6.19.0-rc7-next-20260127 #1 PREEMPT(lazy)\n[ 57.181558] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n[ 57.181563] Call Trace:\n[ 57.181572] \u0026lt;TASK\u0026gt;\n[ 57.181577] dump_stack_lvl+0x5e/0x80\n[ 57.181596] print_report+0xc8/0x270\n[ 57.181605] ? verify_dfa+0x59a/0x660\n[ 57.181608] kasan_report+0x118/0x150\n[ 57.181620] ? verify_dfa+0x59a/0x660\n[ 57.181623] verify_dfa+0x59a/0x660\n[ 57.181627] aa_dfa_unpack+0x1610/0x1740\n[ 57.181629] ? __kmalloc_cache_noprof+0x1d0/0x470\n[ 57.181640] unpack_pdb+0x86d/0x46b0\n[ 57.181647] ? srso_alias_return_thunk+0x5/0xfbef5\n[ 57.181653] ? srso_alias_return_thunk+0x5/0xfbef5\n[ 57.181656] ? aa_unpack_nameX+0x1a8/0x300\n[ 57.181659] aa_unpack+0x20b0/0x4c30\n[ 57.181662] ? srso_alias_return_thunk+0x5/0xfbef5\n[ 57.181664] ? stack_depot_save_flags+0x33/0x700\n[ 57.181681] ? kasan_save_track+0x4f/0x80\n[ 57.181683] ? kasan_save_track+0x3e/0x80\n[ 57.181686] ? __kasan_kmalloc+0x93/0xb0\n[ 57.181688] ? __kvmalloc_node_noprof+0x44a/0x780\n[ 57.181693] ? aa_simple_write_to_buffer+0x54/0x130\n[ 57.181697] ? policy_update+0x154/0x330\n[ 57.181704] aa_replace_profiles+0x15a/0x1dd0\n[ 57.181707] ? srso_alias_return_thunk+0x5/0xfbef5\n[ 57.181710] ? __kvmalloc_node_noprof+0x44a/0x780\n[ 57.181712] ? aa_loaddata_alloc+0x77/0x140\n[ 57.181715] ? srso_alias_return_thunk+0x5/0xfbef5\n[ 57.181717] ? _copy_from_user+0x2a/0x70\n[ 57.181730] policy_update+0x17a/0x330\n[ 57.181733] profile_replace+0x153/0x1a0\n[ 57.181735] ? rw_verify_area+0x93/0x2d0\n[ 57.181740] vfs_write+0x235/0xab0\n[ 57.181745] ksys_write+0xb0/0x170\n[ 57.181748] do_syscall_64+0x8e/0x660\n[ 57.181762] entry_SYSCALL_64_after_hwframe+0x76/0x7e\n[ 57.181765] RIP: 0033:0x7f6192792eb2\n\nRemove the MATCH_FLAG_DIFF_ENCODE condition to validate all DEFAULT_TABLE\nentries unconditionally.(CVE-2026-23407)\n\nA race condition vulnerability exists in the AppArmor security module of the Linux kernel, leading to a use-after-free issue. This vulnerability can be triggered when an attacker simultaneously opens rawdata files and removes an associated AppArmor profile. Since rawdata inodes are not refcounted, there is a time window during profile removal where the i_private pointer may reference freed memory, causing the system to access freed memory regions. This can result in program crashes, unexpected value usage, or arbitrary code execution, threatening the confidentiality, integrity, and availability of the system.(CVE-2026-23410)\n\nA vulnerability exists in the AppArmor security module of the Linux kernel when handling the i_private field of the inode structure. AppArmor was putting the reference to i_private data on its end after removing the original entry from the file system. However the inode can and does live beyond that point and it is possible that some of the fs callback functions will be invoked after the reference has been put, which results in a race between freeing the data and accessing it through the fs. While the rawdata/loaddata is the most likely candidate to fail the race, as it has the fewest references. If properly crafted it might be possible to trigger a race for the other types stored in i_private. This vulnerability could allow a local attacker to bypass AppArmor\u0026apos;s access control policies through a specially crafted request, leading to privilege escalation and impacting system confidentiality, integrity, and availability.(CVE-2026-23411)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nudp_tunnel: fix NULL deref caused by udp_sock_create6 when CONFIG_IPV6=n\n\nWhen CONFIG_IPV6 is disabled, the udp_sock_create6() function returns 0\n(success) without actually creating a socket. Callers such as\nfou_create() then proceed to dereference the uninitialized socket\npointer, resulting in a NULL pointer dereference.\n\nThe captured NULL deref crash:\n BUG: kernel NULL pointer dereference, address: 0000000000000018\n RIP: 0010:fou_nl_add_doit (net/ipv4/fou_core.c:590 net/ipv4/fou_core.c:764)\n [...]\n Call Trace:\n \u0026lt;TASK\u0026gt;\n genl_family_rcv_msg_doit.constprop.0 (net/netlink/genetlink.c:1114)\n genl_rcv_msg (net/netlink/genetlink.c:1194 net/netlink/genetlink.c:1209)\n [...]\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:1319 net/netlink/af_netlink.c:1344)\n netlink_sendmsg (net/netlink/af_netlink.c:1894)\n __sock_sendmsg (net/socket.c:727 (discriminator 1) net/socket.c:742 (discriminator 1))\n __sys_sendto (./include/linux/file.h:62 (discriminator 1) ./include/linux/file.h:83 (discriminator 1) net/socket.c:2183 (discriminator 1))\n __x64_sys_sendto (net/socket.c:2213 (discriminator 1) net/socket.c:2209 (discriminator 1) net/socket.c:2209 (discriminator 1))\n do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1) arch/x86/entry/syscall_64.c:94 (discriminator 1))\n entry_SYSCALL_64_after_hwframe (net/arch/x86/entry/entry_64.S:130)\n\nThis patch makes udp_sock_create6 return -EPFNOSUPPORT instead, so\ncallers correctly take their error paths. There is only one caller of\nthe vulnerable function and only privileged users can trigger it.(CVE-2026-23439)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Fix race condition during IPSec ESN update\n\nIn IPSec full offload mode, the device reports an ESN (Extended\nSequence Number) wrap event to the driver. The driver validates this\nevent by querying the IPSec ASO and checking that the esn_event_arm\nfield is 0x0, which indicates an event has occurred. After handling\nthe event, the driver must re-arm the context by setting esn_event_arm\nback to 0x1.\n\nA race condition exists in this handling path. After validating the\nevent, the driver calls mlx5_accel_esp_modify_xfrm() to update the\nkernel\u0026apos;s xfrm state. This function temporarily releases and\nre-acquires the xfrm state lock.\n\nSo, need to acknowledge the event first by setting esn_event_arm to\n0x1. This prevents the driver from reprocessing the same ESN update if\nthe hardware sends events for other reason. Since the next ESN update\nonly occurs after nearly 2^31 packets are received, there\u0026apos;s no risk of\nmissing an update, as it will happen long after this handling has\nfinished.\n\nProcessing the event twice causes the ESN high-order bits (esn_msb) to\nbe incremented incorrectly. The driver then programs the hardware with\nthis invalid ESN state, which leads to anti-replay failures and a\ncomplete halt of IPSec traffic.\n\nFix this by re-arming the ESN event immediately after it is validated,\nbefore calling mlx5_accel_esp_modify_xfrm(). This ensures that any\nspurious, duplicate events are correctly ignored, closing the race\nwindow.(CVE-2026-23440)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Prevent concurrent access to IPSec ASO context\n\nThe query or updating IPSec offload object is through Access ASO WQE.\nThe driver uses a single mlx5e_ipsec_aso struct for each PF, which\ncontains a shared DMA-mapped context for all ASO operations.\n\nA race condition exists because the ASO spinlock is released before\nthe hardware has finished processing WQE. If a second operation is\ninitiated immediately after, it overwrites the shared context in the\nDMA area.\n\nWhen the first operation\u0026apos;s completion is processed later, it reads\nthis corrupted context, leading to unexpected behavior and incorrect\nresults.\n\nThis commit fixes the race by introducing a private context within\neach IPSec offload object. The shared ASO context is now copied to\nthis private context while the ASO spinlock is held. Subsequent\nprocessing uses this saved, per-object context, ensuring its integrity\nis maintained.(CVE-2026-23441)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mac80211: always free skb on ieee80211_tx_prepare_skb() failure\n\nieee80211_tx_prepare_skb() has three error paths, but only two of them\nfree the skb. The first error path (ieee80211_tx_prepare() returning\nTX_DROP) does not free it, while invoke_tx_handlers() failure and the\nfragmentation check both do.\n\nAdd kfree_skb() to the first error path so all three are consistent,\nand remove the now-redundant frees in callers (ath9k, mt76,\nmac80211_hwsim) to avoid double-free.\n\nDocument the skb ownership guarantee in the function\u0026apos;s kdoc.(CVE-2026-23444)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: usb: cdc_ncm: add ndpoffset to NDP16 nframes bounds check\n\ncdc_ncm_rx_verify_ndp16() validates that the NDP header and its DPE\nentries fit within the skb. The first check correctly accounts for\nndpoffset:\n\n if ((ndpoffset + sizeof(struct usb_cdc_ncm_ndp16)) \u0026gt; skb_in-\u0026gt;len)\n\nbut the second check omits it:\n\n if ((sizeof(struct usb_cdc_ncm_ndp16) +\n ret * (sizeof(struct usb_cdc_ncm_dpe16))) \u0026gt; skb_in-\u0026gt;len)\n\nThis validates the DPE array size against the total skb length as if\nthe NDP were at offset 0, rather than at ndpoffset. When the NDP is\nplaced near the end of the NTB (large wNdpIndex), the DPE entries can\nextend past the skb data buffer even though the check passes.\ncdc_ncm_rx_fixup() then reads out-of-bounds memory when iterating\nthe DPE array.\n\nAdd ndpoffset to the nframes bounds check and use struct_size_t() to\nexpress the NDP-plus-DPE-array size more clearly.(CVE-2026-23448)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/smc: fix NULL dereference and UAF in smc_tcp_syn_recv_sock()\n\nSyzkaller reported a panic in smc_tcp_syn_recv_sock() [1].\n\nsmc_tcp_syn_recv_sock() is called in the TCP receive path\n(softirq) via icsk_af_ops-\u0026gt;syn_recv_sock on the clcsock (TCP\nlistening socket). It reads sk_user_data to get the smc_sock\npointer. However, when the SMC listen socket is being closed\nconcurrently, smc_close_active() sets clcsock-\u0026gt;sk_user_data\nto NULL under sk_callback_lock, and then the smc_sock itself\ncan be freed via sock_put() in smc_release().\n\nThis leads to two issues:\n\n1) NULL pointer dereference: sk_user_data is NULL when\n accessed.\n2) Use-after-free: sk_user_data is read as non-NULL, but the\n smc_sock is freed before its fields (e.g., queued_smc_hs,\n ori_af_ops) are accessed.\n\nThe race window looks like this (the syzkaller crash [1]\ntriggers via the SYN cookie path: tcp_get_cookie_sock() -\u0026gt;\nsmc_tcp_syn_recv_sock(), but the normal tcp_check_req() path\nhas the same race):\n\n CPU A (softirq) CPU B (process ctx)\n\n tcp_v4_rcv()\n TCP_NEW_SYN_RECV:\n sk = req-\u0026gt;rsk_listener\n sock_hold(sk)\n /* No lock on listener */\n smc_close_active():\n write_lock_bh(cb_lock)\n sk_user_data = NULL\n write_unlock_bh(cb_lock)\n ...\n smc_clcsock_release()\n sock_put(smc-\u0026gt;sk) x2\n -\u0026gt; smc_sock freed!\n tcp_check_req()\n smc_tcp_syn_recv_sock():\n smc = user_data(sk)\n -\u0026gt; NULL or dangling\n smc-\u0026gt;queued_smc_hs\n -\u0026gt; crash!\n\nNote that the clcsock and smc_sock are two independent objects\nwith separate refcounts. TCP stack holds a reference on the\nclcsock, which keeps it alive, but this does NOT prevent the\nsmc_sock from being freed.\n\nFix this by using RCU and refcount_inc_not_zero() to safely\naccess smc_sock. Since smc_tcp_syn_recv_sock() is called in\nthe TCP three-way handshake path, taking read_lock_bh on\nsk_callback_lock is too heavy and would not survive a SYN\nflood attack. Using rcu_read_lock() is much more lightweight.\n\n- Set SOCK_RCU_FREE on the SMC listen socket so that\n smc_sock freeing is deferred until after the RCU grace\n period. This guarantees the memory is still valid when\n accessed inside rcu_read_lock().\n- Use rcu_read_lock() to protect reading sk_user_data.\n- Use refcount_inc_not_zero(\u0026amp;smc-\u0026gt;sk.sk_refcnt) to pin the\n smc_sock. If the refcount has already reached zero (close\n path completed), it returns false and we bail out safely.\n\nNote: smc_hs_congested() has a similar lockless read of\nsk_user_data without rcu_read_lock(), but it only checks for\nNULL and accesses the global smc_hs_wq, never dereferencing\nany smc_sock field, so it is not affected.\n\nReproducer was verified with mdelay injection and smc_run,\nthe issue no longer occurs with this patch applied.\n\n[1] https://syzkaller.appspot.com/bug?extid=827ae2bfb3a3529333e9(CVE-2026-23450)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nPM: runtime: Fix a race condition related to device removal\n\nThe following code in pm_runtime_work() may dereference the dev-\u0026gt;parent\npointer after the parent device has been freed:\n\n\t/* Maybe the parent is now able to suspend. */\n\tif (parent \u0026amp;\u0026amp; !parent-\u0026gt;power.ignore_children) {\n\t\tspin_unlock(\u0026amp;dev-\u0026gt;power.lock);\n\n\t\tspin_lock(\u0026amp;parent-\u0026gt;power.lock);\n\t\trpm_idle(parent, RPM_ASYNC);\n\t\tspin_unlock(\u0026amp;parent-\u0026gt;power.lock);\n\n\t\tspin_lock(\u0026amp;dev-\u0026gt;power.lock);\n\t}\n\nFix this by inserting a flush_work() call in pm_runtime_remove().\n\nWithout this patch blktest block/001 triggers the following complaint\nsporadically:\n\nBUG: KASAN: slab-use-after-free in lock_acquire+0x70/0x160\nRead of size 1 at addr ffff88812bef7198 by task kworker/u553:1/3081\nWorkqueue: pm pm_runtime_work\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x61/0x80\n print_address_description.constprop.0+0x8b/0x310\n print_report+0xfd/0x1d7\n kasan_report+0xd8/0x1d0\n __kasan_check_byte+0x42/0x60\n lock_acquire.part.0+0x38/0x230\n lock_acquire+0x70/0x160\n _raw_spin_lock+0x36/0x50\n rpm_suspend+0xc6a/0xfe0\n rpm_idle+0x578/0x770\n pm_runtime_work+0xee/0x120\n process_one_work+0xde3/0x1410\n worker_thread+0x5eb/0xfe0\n kthread+0x37b/0x480\n ret_from_fork+0x6cb/0x920\n ret_from_fork_asm+0x11/0x20\n \u0026lt;/TASK\u0026gt;\n\nAllocated by task 4314:\n kasan_save_stack+0x2a/0x50\n kasan_save_track+0x18/0x40\n kasan_save_alloc_info+0x3d/0x50\n __kasan_kmalloc+0xa0/0xb0\n __kmalloc_noprof+0x311/0x990\n scsi_alloc_target+0x122/0xb60 [scsi_mod]\n __scsi_scan_target+0x101/0x460 [scsi_mod]\n scsi_scan_channel+0x179/0x1c0 [scsi_mod]\n scsi_scan_host_selected+0x259/0x2d0 [scsi_mod]\n store_scan+0x2d2/0x390 [scsi_mod]\n dev_attr_store+0x43/0x80\n sysfs_kf_write+0xde/0x140\n kernfs_fop_write_iter+0x3ef/0x670\n vfs_write+0x506/0x1470\n ksys_write+0xfd/0x230\n __x64_sys_write+0x76/0xc0\n x64_sys_call+0x213/0x1810\n do_syscall_64+0xee/0xfc0\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\nFreed by task 4314:\n kasan_save_stack+0x2a/0x50\n kasan_save_track+0x18/0x40\n kasan_save_free_info+0x3f/0x50\n __kasan_slab_free+0x67/0x80\n kfree+0x225/0x6c0\n scsi_target_dev_release+0x3d/0x60 [scsi_mod]\n device_release+0xa3/0x220\n kobject_cleanup+0x105/0x3a0\n kobject_put+0x72/0xd0\n put_device+0x17/0x20\n scsi_device_dev_release+0xacf/0x12c0 [scsi_mod]\n device_release+0xa3/0x220\n kobject_cleanup+0x105/0x3a0\n kobject_put+0x72/0xd0\n put_device+0x17/0x20\n scsi_device_put+0x7f/0xc0 [scsi_mod]\n sdev_store_delete+0xa5/0x120 [scsi_mod]\n dev_attr_store+0x43/0x80\n sysfs_kf_write+0xde/0x140\n kernfs_fop_write_iter+0x3ef/0x670\n vfs_write+0x506/0x1470\n ksys_write+0xfd/0x230\n __x64_sys_write+0x76/0xc0\n x64_sys_call+0x213/0x1810(CVE-2026-23452)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: L2CAP: Fix use-after-free in l2cap_unregister_user\n\nAfter commit ab4eedb790ca (\u0026quot;Bluetooth: L2CAP: Fix corrupted list in\nhci_chan_del\u0026quot;), l2cap_conn_del() uses conn-\u0026gt;lock to protect access to\nconn-\u0026gt;users. However, l2cap_register_user() and l2cap_unregister_user()\ndon\u0026apos;t use conn-\u0026gt;lock, creating a race condition where these functions can\naccess conn-\u0026gt;users and conn-\u0026gt;hchan concurrently with l2cap_conn_del().\n\nThis can lead to use-after-free and list corruption bugs, as reported\nby syzbot.\n\nFix this by changing l2cap_register_user() and l2cap_unregister_user()\nto use conn-\u0026gt;lock instead of hci_dev_lock(), ensuring consistent locking\nfor the l2cap_conn structure.(CVE-2026-23461)\n\nRejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2026-23473)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nspi: fix statistics allocation\n\nThe controller per-cpu statistics is not allocated until after the\ncontroller has been registered with driver core, which leaves a window\nwhere accessing the sysfs attributes can trigger a NULL-pointer\ndereference.\n\nFix this by moving the statistics allocation to controller allocation\nwhile tying its lifetime to that of the controller (rather than using\nimplicit devres).(CVE-2026-23475)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix krb5 mount with username option\n\nCustomer reported that some of their krb5 mounts were failing against\na single server as the client was trying to mount the shares with\nwrong credentials. It turned out the client was reusing SMB session\nfrom first mount to try mounting the other shares, even though a\ndifferent username= option had been specified to the other mounts.\n\nBy using username mount option along with sec=krb5 to search for\nprincipals from keytab is supported by cifs.upcall(8) since\ncifs-utils-4.8. So fix this by matching username mount option in\nmatch_session() even with Kerberos.\n\nFor example, the second mount below should fail with -ENOKEY as there\nis no \u0026apos;foobar\u0026apos; principal in keytab (/etc/krb5.keytab). The client\nends up reusing SMB session from first mount to perform the second\none, which is wrong.\n\n```\n$ ktutil\nktutil: add_entry -password -p testuser -k 1 -e aes256-cts\nPassword for (CVE-2026-31392)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/rmap: fix incorrect pte restoration for lazyfree folios\n\nWe batch unmap anonymous lazyfree folios by folio_unmap_pte_batch. If the\nbatch has a mix of writable and non-writable bits, we may end up setting\nthe entire batch writable. Fix this by respecting writable bit during\nbatching.\n\nAlthough on a successful unmap of a lazyfree folio, the soft-dirty bit is\nlost, preserve it on pte restoration by respecting the bit during\nbatching, to make the fix consistent w.r.t both writable bit and\nsoft-dirty bit.\n\nI was able to write the below reproducer and crash the kernel. \nExplanation of reproducer (set 64K mTHP to always):\n\nFault in a 64K large folio. Split the VMA at mid-point with\nMADV_DONTFORK. fork() - parent points to the folio with 8 writable ptes\nand 8 non-writable ptes. Merge the VMAs with MADV_DOFORK so that\nfolio_unmap_pte_batch() can determine all the 16 ptes as a batch. Do\nMADV_FREE on the range to mark the folio as lazyfree. Write to the memory\nto dirty the pte, eventually rmap will dirty the folio. Then trigger\nreclaim, we will hit the pte restoration path, and the kernel will crash\nwith the trace given below.\n\nThe BUG happens at:\n\n\tBUG_ON(atomic_inc_return(\u0026amp;ptc-\u0026gt;anon_map_count) \u0026gt; 1 \u0026amp;\u0026amp; rw);\n\nThe code path is asking for anonymous page to be mapped writable into the\npagetable. The BUG_ON() firing implies that such a writable page has been\nmapped into the pagetables of more than one process, which breaks\nanonymous memory/CoW semantics.\n\n[ 21.134473] kernel BUG at mm/page_table_check.c:118!\n[ 21.134497] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP\n[ 21.135917] Modules linked in:\n[ 21.136085] CPU: 1 UID: 0 PID: 1735 Comm: dup-lazyfree Not tainted 7.0.0-rc1-00116-g018018a17770 #1028 PREEMPT\n[ 21.136858] Hardware name: linux,dummy-virt (DT)\n[ 21.137019] pstate: 21400005 (nzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)\n[ 21.137308] pc : page_table_check_set+0x28c/0x2a8\n[ 21.137607] lr : page_table_check_set+0x134/0x2a8\n[ 21.137885] sp : ffff80008a3b3340\n[ 21.138124] x29: ffff80008a3b3340 x28: fffffdffc3d14400 x27: ffffd1a55e03d000\n[ 21.138623] x26: 0040000000000040 x25: ffffd1a55f7dd000 x24: 0000000000000001\n[ 21.139045] x23: 0000000000000001 x22: 0000000000000001 x21: ffffd1a55f217f30\n[ 21.139629] x20: 0000000000134521 x19: 0000000000134519 x18: 005c43e000040000\n[ 21.140027] x17: 0001400000000000 x16: 0001700000000000 x15: 000000000000ffff\n[ 21.140578] x14: 000000000000000c x13: 005c006000000000 x12: 0000000000000020\n[ 21.140828] x11: 0000000000000000 x10: 005c000000000000 x9 : ffffd1a55c079ee0\n[ 21.141077] x8 : 0000000000000001 x7 : 005c03e000040000 x6 : 000000004000ffff\n[ 21.141490] x5 : ffff00017fffce00 x4 : 0000000000000001 x3 : 0000000000000002\n[ 21.141741] x2 : 0000000000134510 x1 : 0000000000000000 x0 : ffff0000c08228c0\n[ 21.141991] Call trace:\n[ 21.142093] page_table_check_set+0x28c/0x2a8 (P)\n[ 21.142265] __page_table_check_ptes_set+0x144/0x1e8\n[ 21.142441] __set_ptes_anysz.constprop.0+0x160/0x1a8\n[ 21.142766] contpte_set_ptes+0xe8/0x140\n[ 21.142907] try_to_unmap_one+0x10c4/0x10d0\n[ 21.143177] rmap_walk_anon+0x100/0x250\n[ 21.143315] try_to_unmap+0xa0/0xc8\n[ 21.143441] shrink_folio_list+0x59c/0x18a8\n[ 21.143759] shrink_lruvec+0x664/0xbf0\n[ 21.144043] shrink_node+0x218/0x878\n[ 21.144285] __node_reclaim.constprop.0+0x98/0x338\n[ 21.144763] user_proactive_reclaim+0x2a4/0x340\n[ 21.145056] reclaim_store+0x3c/0x60\n[ 21.145216] dev_attr_store+0x20/0x40\n[ 21.145585] sysfs_kf_write+0x84/0xa8\n[ 21.145835] kernfs_fop_write_iter+0x130/0x1c8\n[ 21.145994] vfs_write+0x2b8/0x368\n[ 21.146119] ksys_write+0x70/0x110\n[ 21.146240] __arm64_sys_write+0x24/0x38\n[ 21.146380] invoke_syscall+0x50/0x120\n[ 21.146513] el0_svc_common.constprop.0+0x48/0xf8\n[ 21.146679] do_el0_svc+0x28/0x40\n[ 21.146798] el0_svc+0x34/0x110\n[ 21.146926] el0t\n---truncated---(CVE-2026-31398)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvdimm/bus: Fix potential use after free in asynchronous initialization\n\nDingisoul with KASAN reports a use after free if device_add() fails in\nnd_async_device_register().\n\nCommit b6eae0f61db2 (\u0026quot;libnvdimm: Hold reference on parent while\nscheduling async init\u0026quot;) correctly added a reference on the parent device\nto be held until asynchronous initialization was complete. However, if\ndevice_add() results in an allocation failure the ref count of the\ndevice drops to 0 prior to the parent pointer being accessed. Thus\nresulting in use after free.\n\nThe bug bot AI correctly identified the fix. Save a reference to the\nparent pointer to be used to drop the parent reference regardless of the\noutcome of device_add().(CVE-2026-31399)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsunrpc: fix cache_request leak in cache_release\n\nWhen a reader\u0026apos;s file descriptor is closed while in the middle of reading\na cache_request (rp-\u0026gt;offset != 0), cache_release() decrements the\nrequest\u0026apos;s readers count but never checks whether it should free the\nrequest.\n\nIn cache_read(), when readers drops to 0 and CACHE_PENDING is clear, the\ncache_request is removed from the queue and freed along with its buffer\nand cache_head reference. cache_release() lacks this cleanup.\n\nThe only other path that frees requests with readers == 0 is\ncache_dequeue(), but it runs only when CACHE_PENDING transitions from\nset to clear. If that transition already happened while readers was\nstill non-zero, cache_dequeue() will have skipped the request, and no\nsubsequent call will clean it up.\n\nAdd the same cleanup logic from cache_read() to cache_release(): after\ndecrementing readers, check if it reached 0 with CACHE_PENDING clear,\nand if so, dequeue and free the cache_request.(CVE-2026-31400)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFSD: Hold net reference for the lifetime of /proc/fs/nfs/exports fd\n\nThe /proc/fs/nfs/exports proc entry is created at module init\nand persists for the module\u0026apos;s lifetime. exports_proc_open()\ncaptures the caller\u0026apos;s current network namespace and stores\nits svc_export_cache in seq-\u0026gt;private, but takes no reference\non the namespace. If the namespace is subsequently torn down\n(e.g. container destruction after the opener does setns() to a\ndifferent namespace), nfsd_net_exit() calls nfsd_export_shutdown()\nwhich frees the cache. Subsequent reads on the still-open fd\ndereference the freed cache_detail, walking a freed hash table.\n\nHold a reference on the struct net for the lifetime of the open\nfile descriptor. This prevents nfsd_net_exit() from running --\nand thus prevents nfsd_export_shutdown() from freeing the cache\n-- while any exports fd is open. cache_detail already stores\nits net pointer (cd-\u0026gt;net, set by cache_create_net()), so\nexports_release() can retrieve it without additional per-file\nstorage.(CVE-2026-31403)\n\nIn the Linux kernel, the Bluetooth SCO module\u0026apos;s sco_recv_frame() function contains a use-after-free vulnerability. The function reads conn-\u0026gt;sk under sco_conn_lock() but immediately releases the lock without holding a reference to the socket. A concurrent close() operation can free the socket between the lock release and the subsequent sk-\u0026gt;sk_state access, resulting in a use-after-free vulnerability. Other functions in the same file (sco_sock_timeout(), sco_conn_del()) correctly use sco_sock_hold() to safely hold references under the lock. The vulnerability is fixed by using sco_sock_hold() to acquire a reference before releasing the lock and adding sock_put() on all exit paths.(CVE-2026-31408)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: cls_fw: fix NULL pointer dereference on shared blocks\n\nThe old-method path in fw_classify() calls tcf_block_q() and\ndereferences q-\u0026gt;handle. Shared blocks leave block-\u0026gt;q NULL, causing a\nNULL deref when an empty cls_fw filter is attached to a shared block\nand a packet with a nonzero major skb mark is classified.\n\nReject the configuration in fw_change() when the old method (no\nTCA_OPTIONS) is used on a shared block, since fw_classify()\u0026apos;s\nold-method path needs block-\u0026gt;q which is NULL for shared blocks.\n\nThe fixed null-ptr-deref calling stack:\n KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f]\n RIP: 0010:fw_classify (net/sched/cls_fw.c:81)\n Call Trace:\n tcf_classify (./include/net/tc_wrapper.h:197 net/sched/cls_api.c:1764 net/sched/cls_api.c:1860)\n tc_run (net/core/dev.c:4401)\n __dev_queue_xmit (net/core/dev.c:4535 net/core/dev.c:4790)(CVE-2026-31421)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: cls_flow: fix NULL pointer dereference on shared blocks\n\nflow_change() calls tcf_block_q() and dereferences q-\u0026gt;handle to derive\na default baseclass. Shared blocks leave block-\u0026gt;q NULL, causing a NULL\nderef when a flow filter without a fully qualified baseclass is created\non a shared block.\n\nCheck tcf_block_shared() before accessing block-\u0026gt;q and return -EINVAL\nfor shared blocks. This avoids the null-deref shown below:\n\n=======================================================================\nKASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f]\nRIP: 0010:flow_change (net/sched/cls_flow.c:508)\nCall Trace:\n tc_new_tfilter (net/sched/cls_api.c:2432)\n rtnetlink_rcv_msg (net/core/rtnetlink.c:6980)\n [...]\n=======================================================================(CVE-2026-31422)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nACPI: EC: clean up handlers on probe failure in acpi_ec_setup()\n\nWhen ec_install_handlers() returns -EPROBE_DEFER on reduced-hardware\nplatforms, it has already started the EC and installed the address\nspace handler with the struct acpi_ec pointer as handler context.\nHowever, acpi_ec_setup() propagates the error without any cleanup.\n\nThe caller acpi_ec_add() then frees the struct acpi_ec for non-boot\ninstances, leaving a dangling handler context in ACPICA.\n\nAny subsequent AML evaluation that accesses an EC OpRegion field\ndispatches into acpi_ec_space_handler() with the freed pointer,\ncausing a use-after-free:\n\n BUG: KASAN: slab-use-after-free in mutex_lock (kernel/locking/mutex.c:289)\n Write of size 8 at addr ffff88800721de38 by task init/1\n Call Trace:\n \u0026lt;TASK\u0026gt;\n mutex_lock (kernel/locking/mutex.c:289)\n acpi_ec_space_handler (drivers/acpi/ec.c:1362)\n acpi_ev_address_space_dispatch (drivers/acpi/acpica/evregion.c:293)\n acpi_ex_access_region (drivers/acpi/acpica/exfldio.c:246)\n acpi_ex_field_datum_io (drivers/acpi/acpica/exfldio.c:509)\n acpi_ex_extract_from_field (drivers/acpi/acpica/exfldio.c:700)\n acpi_ex_read_data_from_field (drivers/acpi/acpica/exfield.c:327)\n acpi_ex_resolve_node_to_value (drivers/acpi/acpica/exresolv.c:392)\n \u0026lt;/TASK\u0026gt;\n\n Allocated by task 1:\n acpi_ec_alloc (drivers/acpi/ec.c:1424)\n acpi_ec_add (drivers/acpi/ec.c:1692)\n\n Freed by task 1:\n kfree (mm/slub.c:6876)\n acpi_ec_add (drivers/acpi/ec.c:1751)\n\nThe bug triggers on reduced-hardware EC platforms (ec-\u0026gt;gpe \u0026lt; 0)\nwhen the GPIO IRQ provider defers probing. Once the stale handler\nexists, any unprivileged sysfs read that causes AML to touch an\nEC OpRegion (battery, thermal, backlight) exercises the dangling\npointer.\n\nFix this by calling ec_remove_handlers() in the error path of\nacpi_ec_setup() before clearing first_ec. ec_remove_handlers()\nchecks each EC_FLAGS_* bit before acting, so it is safe to call\nregardless of how far ec_install_handlers() progressed:\n\n -ENODEV (handler not installed): only calls acpi_ec_stop()\n -EPROBE_DEFER (handler installed): removes handler, stops EC(CVE-2026-31426)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: skb: fix cross-cache free of KFENCE-allocated skb head\n\nSKB_SMALL_HEAD_CACHE_SIZE is intentionally set to a non-power-of-2\nvalue (e.g. 704 on x86_64) to avoid collisions with generic kmalloc\nbucket sizes. This ensures that skb_kfree_head() can reliably use\nskb_end_offset to distinguish skb heads allocated from\nskb_small_head_cache vs. generic kmalloc caches.\n\nHowever, when KFENCE is enabled, kfence_ksize() returns the exact\nrequested allocation size instead of the slab bucket size. If a caller\n(e.g. bpf_test_init) allocates skb head data via kzalloc() and the\nrequested size happens to equal SKB_SMALL_HEAD_CACHE_SIZE, then\nslab_build_skb() -\u0026gt; ksize() returns that exact value. After subtracting\nskb_shared_info overhead, skb_end_offset ends up matching\nSKB_SMALL_HEAD_HEADROOM, causing skb_kfree_head() to incorrectly free\nthe object to skb_small_head_cache instead of back to the original\nkmalloc cache, resulting in a slab cross-cache free:\n\n kmem_cache_free(skbuff_small_head): Wrong slab cache. Expected\n skbuff_small_head but got kmalloc-1k\n\nFix this by always calling kfree(head) in skb_kfree_head(). This keeps\nthe free path generic and avoids allocator-specific misclassification\nfor KFENCE objects.(CVE-2026-31429)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nX.509: Fix out-of-bounds access when parsing extensions\n\nLeo reports an out-of-bounds access when parsing a certificate with\nempty Basic Constraints or Key Usage extension because the first byte of\nthe extension is read before checking its length. Fix it.\n\nThe bug can be triggered by an unprivileged user by submitting a\nspecially crafted certificate to the kernel through the keyrings(7) API.\nLeo has demonstrated this with a proof-of-concept program responsibly\ndisclosed off-list.(CVE-2026-31430)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: idxd: Fix memory leak when a wq is reset\n\nidxd_wq_disable_cleanup() which is called from the reset path for a\nworkqueue, sets the wq type to NONE, which for other parts of the\ndriver mean that the wq is empty (all its resources were released).\n\nOnly set the wq type to NONE after its resources are released.(CVE-2026-31441)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: idxd: Fix possible invalid memory access after FLR\n\nIn the case that the first Function Level Reset (FLR) concludes\ncorrectly, but in the second FLR the scratch area for the saved\nconfiguration cannot be allocated, it\u0026apos;s possible for a invalid memory\naccess to happen.\n\nAlways set the deallocated scratch area to NULL after FLR completes.(CVE-2026-31442)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: fix use-after-free in update_super_work when racing with umount\n\nCommit b98535d09179 (\u0026quot;ext4: fix bug_on in start_this_handle during umount\nfilesystem\u0026quot;) moved ext4_unregister_sysfs() before flushing s_sb_upd_work\nto prevent new error work from being queued via /proc/fs/ext4/xx/mb_groups\nreads during unmount. However, this introduced a use-after-free because\nupdate_super_work calls ext4_notify_error_sysfs() -\u0026gt; sysfs_notify() which\naccesses the kobject\u0026apos;s kernfs_node after it has been freed by kobject_del()\nin ext4_unregister_sysfs():\n\n update_super_work ext4_put_super\n ----------------- --------------\n ext4_unregister_sysfs(sb)\n kobject_del(\u0026amp;sbi-\u0026gt;s_kobj)\n __kobject_del()\n sysfs_remove_dir()\n kobj-\u0026gt;sd = NULL\n sysfs_put(sd)\n kernfs_put() // RCU free\n ext4_notify_error_sysfs(sbi)\n sysfs_notify(\u0026amp;sbi-\u0026gt;s_kobj)\n kn = kobj-\u0026gt;sd // stale pointer\n kernfs_get(kn) // UAF on freed kernfs_node\n ext4_journal_destroy()\n flush_work(\u0026amp;sbi-\u0026gt;s_sb_upd_work)\n\nInstead of reordering the teardown sequence, fix this by making\next4_notify_error_sysfs() detect that sysfs has already been torn down\nby checking s_kobj.state_in_sysfs, and skipping the sysfs_notify() call\nin that case. A dedicated mutex (s_error_notify_mutex) serializes\next4_notify_error_sysfs() against kobject_del() in ext4_unregister_sysfs()\nto prevent TOCTOU races where the kobject could be deleted between the\nstate_in_sysfs check and the sysfs_notify() call.(CVE-2026-31446)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: validate p_idx bounds in ext4_ext_correct_indexes\n\next4_ext_correct_indexes() walks up the extent tree correcting\nindex entries when the first extent in a leaf is modified. Before\naccessing path[k].p_idx-\u0026gt;ei_block, there is no validation that\np_idx falls within the valid range of index entries for that\nlevel.\n\nIf the on-disk extent header contains a corrupted or crafted\neh_entries value, p_idx can point past the end of the allocated\nbuffer, causing a slab-out-of-bounds read.\n\nFix this by validating path[k].p_idx against EXT_LAST_INDEX() at\nboth access sites: before the while loop and inside it. Return\n-EFSCORRUPTED if the index pointer is out of range, consistent\nwith how other bounds violations are handled in the ext4 extent\ntree code.(CVE-2026-31449)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: publish jinode after initialization\n\next4_inode_attach_jinode() publishes ei-\u0026gt;jinode to concurrent users.\nIt used to set ei-\u0026gt;jinode before jbd2_journal_init_jbd_inode(),\nallowing a reader to observe a non-NULL jinode with i_vfs_inode\nstill unset.\n\nThe fast commit flush path can then pass this jinode to\njbd2_wait_inode_data(), which dereferences i_vfs_inode-\u0026gt;i_mapping and\nmay crash.\n\nBelow is the crash I observe:\n```\nBUG: unable to handle page fault for address: 000000010beb47f4\nPGD 110e51067 P4D 110e51067 PUD 0\nOops: Oops: 0000 [#1] SMP NOPTI\nCPU: 1 UID: 0 PID: 4850 Comm: fc_fsync_bench_ Not tainted 6.18.0-00764-g795a690c06a5 #1 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.17.0-2-2 04/01/2014\nRIP: 0010:xas_find_marked+0x3d/0x2e0\nCode: e0 03 48 83 f8 02 0f 84 f0 01 00 00 48 8b 47 08 48 89 c3 48 39 c6 0f 82 fd 01 00 00 48 85 c9 74 3d 48 83 f9 03 77 63 4c 8b 0f \u0026lt;49\u0026gt; 8b 71 08 48 c7 47 18 00 00 00 00 48 89 f1 83 e1 03 48 83 f9 02\nRSP: 0018:ffffbbee806e7bf0 EFLAGS: 00010246\nRAX: 000000000010beb4 RBX: 000000000010beb4 RCX: 0000000000000003\nRDX: 0000000000000001 RSI: 0000002000300000 RDI: ffffbbee806e7c10\nRBP: 0000000000000001 R08: 0000002000300000 R09: 000000010beb47ec\nR10: ffff9ea494590090 R11: 0000000000000000 R12: 0000002000300000\nR13: ffffbbee806e7c90 R14: ffff9ea494513788 R15: ffffbbee806e7c88\nFS: 00007fc2f9e3e6c0(0000) GS:ffff9ea6b1444000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 000000010beb47f4 CR3: 0000000119ac5000 CR4: 0000000000750ef0\nPKRU: 55555554\nCall Trace:\n\u0026lt;TASK\u0026gt;\nfilemap_get_folios_tag+0x87/0x2a0\n__filemap_fdatawait_range+0x5f/0xd0\n? srso_alias_return_thunk+0x5/0xfbef5\n? __schedule+0x3e7/0x10c0\n? srso_alias_return_thunk+0x5/0xfbef5\n? srso_alias_return_thunk+0x5/0xfbef5\n? srso_alias_return_thunk+0x5/0xfbef5\n? preempt_count_sub+0x5f/0x80\n? srso_alias_return_thunk+0x5/0xfbef5\n? cap_safe_nice+0x37/0x70\n? srso_alias_return_thunk+0x5/0xfbef5\n? preempt_count_sub+0x5f/0x80\n? srso_alias_return_thunk+0x5/0xfbef5\nfilemap_fdatawait_range_keep_errors+0x12/0x40\next4_fc_commit+0x697/0x8b0\n? ext4_file_write_iter+0x64b/0x950\n? srso_alias_return_thunk+0x5/0xfbef5\n? preempt_count_sub+0x5f/0x80\n? srso_alias_return_thunk+0x5/0xfbef5\n? vfs_write+0x356/0x480\n? srso_alias_return_thunk+0x5/0xfbef5\n? preempt_count_sub+0x5f/0x80\next4_sync_file+0xf7/0x370\ndo_fsync+0x3b/0x80\n? syscall_trace_enter+0x108/0x1d0\n__x64_sys_fdatasync+0x16/0x20\ndo_syscall_64+0x62/0x2c0\nentry_SYSCALL_64_after_hwframe+0x76/0x7e\n...\n```\n\nFix this by initializing the jbd2_inode first.\nUse smp_wmb() and WRITE_ONCE() to publish ei-\u0026gt;jinode after\ninitialization. Readers use READ_ONCE() to fetch the pointer.(CVE-2026-31450)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: replace BUG_ON with proper error handling in ext4_read_inline_folio\n\nReplace BUG_ON() with proper error handling when inline data size\nexceeds PAGE_SIZE. This prevents kernel panic and allows the system to\ncontinue running while properly reporting the filesystem corruption.\n\nThe error is logged via ext4_error_inode(), the buffer head is released\nto prevent memory leak, and -EFSCORRUPTED is returned to indicate\nfilesystem corruption.(CVE-2026-31451)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: convert inline data to extents when truncate exceeds inline size\n\nAdd a check in ext4_setattr() to convert files from inline data storage\nto extent-based storage when truncate() grows the file size beyond the\ninline capacity. This prevents the filesystem from entering an\ninconsistent state where the inline data flag is set but the file size\nexceeds what can be stored inline.\n\nWithout this fix, the following sequence causes a kernel BUG_ON():\n\n1. Mount filesystem with inode that has inline flag set and small size\n2. truncate(file, 50MB) - grows size but inline flag remains set\n3. sendfile() attempts to write data\n4. ext4_write_inline_data() hits BUG_ON(write_size \u0026gt; inline_capacity)\n\nThe crash occurs because ext4_write_inline_data() expects inline storage\nto accommodate the write, but the actual inline capacity (~60 bytes for\ni_block + ~96 bytes for xattrs) is far smaller than the file size and\nwrite request.\n\nThe fix checks if the new size from setattr exceeds the inode\u0026apos;s actual\ninline capacity (EXT4_I(inode)-\u0026gt;i_inline_size) and converts the file to\nextent-based storage before proceeding with the size change.\n\nThis addresses the root cause by ensuring the inline data flag and file\nsize remain consistent during truncate operations.(CVE-2026-31452)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nerofs: add GFP_NOIO in the bio completion if needed\n\nThe bio completion path in the process context (e.g. dm-verity)\nwill directly call into decompression rather than trigger another\nworkqueue context for minimal scheduling latencies, which can\nthen call vm_map_ram() with GFP_KERNEL.\n\nDue to insufficient memory, vm_map_ram() may generate memory\nswapping I/O, which can cause submit_bio_wait to deadlock\nin some scenarios.\n\nTrimmed down the call stack, as follows:\n\nf2fs_submit_read_io\n submit_bio //bio_list is initialized.\n mmc_blk_mq_recovery\n z_erofs_endio\n vm_map_ram\n __pte_alloc_kernel\n __alloc_pages_direct_reclaim\n shrink_folio_list\n __swap_writepage\n submit_bio_wait //bio_list is non-NULL, hang!!!\n\nUse memalloc_noio_{save,restore}() to wrap up this path.(CVE-2026-31467)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvirtio_net: Fix UAF on dst_ops when IFF_XMIT_DST_RELEASE is cleared and napi_tx is false\n\nA UAF issue occurs when the virtio_net driver is configured with napi_tx=N\nand the device\u0026apos;s IFF_XMIT_DST_RELEASE flag is cleared\n(e.g., during the configuration of tc route filter rules).\n\nWhen IFF_XMIT_DST_RELEASE is removed from the net_device, the network stack\nexpects the driver to hold the reference to skb-\u0026gt;dst until the packet\nis fully transmitted and freed. In virtio_net with napi_tx=N,\nskbs may remain in the virtio transmit ring for an extended period.\n\nIf the network namespace is destroyed while these skbs are still pending,\nthe corresponding dst_ops structure has freed. When a subsequent packet\nis transmitted, free_old_xmit() is triggered to clean up old skbs.\nIt then calls dst_release() on the skb associated with the stale dst_entry.\nSince the dst_ops (referenced by the dst_entry) has already been freed,\na UAF kernel paging request occurs.\n\nfix it by adds skb_dst_drop(skb) in start_xmit to explicitly release\nthe dst reference before the skb is queued in virtio_net.\n\nCall Trace:\n Unable to handle kernel paging request at virtual address ffff80007e150000\n CPU: 2 UID: 0 PID: 6236 Comm: ping Kdump: loaded Not tainted 7.0.0-rc1+ #6 PREEMPT\n ...\n percpu_counter_add_batch+0x3c/0x158 lib/percpu_counter.c:98 (P)\n dst_release+0xe0/0x110 net/core/dst.c:177\n skb_release_head_state+0xe8/0x108 net/core/skbuff.c:1177\n sk_skb_reason_drop+0x54/0x2d8 net/core/skbuff.c:1255\n dev_kfree_skb_any_reason+0x64/0x78 net/core/dev.c:3469\n napi_consume_skb+0x1c4/0x3a0 net/core/skbuff.c:1527\n __free_old_xmit+0x164/0x230 drivers/net/virtio_net.c:611 [virtio_net]\n free_old_xmit drivers/net/virtio_net.c:1081 [virtio_net]\n start_xmit+0x7c/0x530 drivers/net/virtio_net.c:3329 [virtio_net]\n ...\n\nReproduction Steps:\nNETDEV=\u0026quot;enp3s0\u0026quot;\n\nconfig_qdisc_route_filter() {\n tc qdisc del dev $NETDEV root\n tc qdisc add dev $NETDEV root handle 1: prio\n tc filter add dev $NETDEV parent 1:0 \\\n\tprotocol ip prio 100 route to 100 flowid 1:1\n ip route add 192.168.1.100/32 dev $NETDEV realm 100\n}\n\ntest_ns() {\n ip netns add testns\n ip link set $NETDEV netns testns\n ip netns exec testns ifconfig $NETDEV 10.0.32.46/24\n ip netns exec testns ping -c 1 10.0.32.1\n ip netns del testns\n}\n\nconfig_qdisc_route_filter\n\ntest_ns\nsleep 2\ntest_ns(CVE-2026-31469)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nspi: use generic driver_override infrastructure\n\nWhen a driver is probed through __driver_attach(), the bus\u0026apos; match()\ncallback is called without the device lock held, thus accessing the\ndriver_override field without a lock, which can cause a UAF.\n\nFix this by using the driver-core driver_override infrastructure taking\ncare of proper locking internally.\n\nNote that calling match() from __driver_attach() without the device lock\nheld is intentional. [1]\n\nAlso note that we do not enable the driver_override feature of struct\nbus_type, as SPI - in contrast to most other buses - passes \u0026quot;\u0026quot; to\nsysfs_emit() when the driver_override pointer is NULL. Thus, printing\n\u0026quot;\\n\u0026quot; instead of \u0026quot;(null)\\n\u0026quot;.(CVE-2026-31487)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: ctnetlink: use netlink policy range checks\n\nReplace manual range and mask validations with netlink policy\nannotations in ctnetlink code paths, so that the netlink core rejects\ninvalid values early and can generate extack errors.\n\n- CTA_PROTOINFO_TCP_STATE: reject values \u0026gt; TCP_CONNTRACK_SYN_SENT2 at\n policy level, removing the manual \u0026gt;= TCP_CONNTRACK_MAX check.\n- CTA_PROTOINFO_TCP_WSCALE_ORIGINAL/REPLY: reject values \u0026gt; TCP_MAX_WSCALE\n (14). The normal TCP option parsing path already clamps to this value,\n but the ctnetlink path accepted 0-255, causing undefined behavior when\n used as a u32 shift count.\n- CTA_FILTER_ORIG_FLAGS/REPLY_FLAGS: use NLA_POLICY_MASK with\n CTA_FILTER_F_ALL, removing the manual mask checks.\n- CTA_EXPECT_FLAGS: use NLA_POLICY_MASK with NF_CT_EXPECT_MASK, adding\n a new mask define grouping all valid expect flags.\n\nExtracted from a broader nf-next patch by Florian Westphal, scoped to\nctnetlink for the fixes tree.(CVE-2026-31495)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_conntrack_expect: skip expectations in other netns via proc\n\nSkip expectations that do not reside in this netns.\n\nSimilar to e77e6ff502ea (\u0026quot;netfilter: conntrack: do not dump other netns\u0026apos;s\nconntrack entries via proc\u0026quot;).(CVE-2026-31496)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: L2CAP: Fix ERTM re-init and zero pdu_len infinite loop\n\nl2cap_config_req() processes CONFIG_REQ for channels in BT_CONNECTED\nstate to support L2CAP reconfiguration (e.g. MTU changes). However,\nsince both CONF_INPUT_DONE and CONF_OUTPUT_DONE are already set from\nthe initial configuration, the reconfiguration path falls through to\nl2cap_ertm_init(), which re-initializes tx_q, srej_q, srej_list, and\nretrans_list without freeing the previous allocations and sets\nchan-\u0026gt;sdu to NULL without freeing the existing skb. This leaks all\npreviously allocated ERTM resources.\n\nAdditionally, l2cap_parse_conf_req() does not validate the minimum\nvalue of remote_mps derived from the RFC max_pdu_size option. A zero\nvalue propagates to l2cap_segment_sdu() where pdu_len becomes zero,\ncausing the while loop to never terminate since len is never\ndecremented, exhausting all available memory.\n\nFix the double-init by skipping l2cap_ertm_init() and\nl2cap_chan_ready() when the channel is already in BT_CONNECTED state,\nwhile still allowing the reconfiguration parameters to be updated\nthrough l2cap_parse_conf_req(). Also add a pdu_len zero check in\nl2cap_segment_sdu() as a safeguard.(CVE-2026-31498)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: L2CAP: Fix deadlock in l2cap_conn_del()\n\nl2cap_conn_del() calls cancel_delayed_work_sync() for both info_timer\nand id_addr_timer while holding conn-\u0026gt;lock. However, the work functions\nl2cap_info_timeout() and l2cap_conn_update_id_addr() both acquire\nconn-\u0026gt;lock, creating a potential AB-BA deadlock if the work is already\nexecuting when l2cap_conn_del() takes the lock.\n\nMove the work cancellations before acquiring conn-\u0026gt;lock and use\ndisable_delayed_work_sync() to additionally prevent the works from\nbeing rearmed after cancellation, consistent with the pattern used in\nhci_conn_del().(CVE-2026-31499)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niavf: fix out-of-bounds writes in iavf_get_ethtool_stats()\n\niavf incorrectly uses real_num_tx_queues for ETH_SS_STATS. Since the\nvalue could change in runtime, we should use num_tx_queues instead.\n\nMoreover iavf_get_ethtool_stats() uses num_active_queues while\niavf_get_sset_count() and iavf_get_stat_strings() use\nreal_num_tx_queues, which triggers out-of-bounds writes when we do\n\u0026quot;ethtool -L\u0026quot; and \u0026quot;ethtool -S\u0026quot; simultaneously [1].\n\nFor example when we change channels from 1 to 8, Thread 3 could be\nscheduled before Thread 2, and out-of-bounds writes could be triggered\nin Thread 3:\n\nThread 1 (ethtool -L) Thread 2 (work) Thread 3 (ethtool -S)\niavf_set_channels()\n...\niavf_alloc_queues()\n-\u0026gt; num_active_queues = 8\niavf_schedule_finish_config()\n iavf_get_sset_count()\n real_num_tx_queues: 1\n -\u0026gt; buffer for 1 queue\n iavf_get_ethtool_stats()\n num_active_queues: 8\n -\u0026gt; out-of-bounds!\n iavf_finish_config()\n -\u0026gt; real_num_tx_queues = 8\n\nUse immutable num_tx_queues in all related functions to avoid the issue.\n\n[1]\n BUG: KASAN: vmalloc-out-of-bounds in iavf_add_one_ethtool_stat+0x200/0x270\n Write of size 8 at addr ffffc900031c9080 by task ethtool/5800\n\n CPU: 1 UID: 0 PID: 5800 Comm: ethtool Not tainted 6.19.0-enjuk-08403-g8137e3db7f1c #241 PREEMPT(full)\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n Call Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x6f/0xb0\n print_report+0x170/0x4f3\n kasan_report+0xe1/0x180\n iavf_add_one_ethtool_stat+0x200/0x270\n iavf_get_ethtool_stats+0x14c/0x2e0\n __dev_ethtool+0x3d0c/0x5830\n dev_ethtool+0x12d/0x270\n dev_ioctl+0x53c/0xe30\n sock_do_ioctl+0x1a9/0x270\n sock_ioctl+0x3d4/0x5e0\n __x64_sys_ioctl+0x137/0x1c0\n do_syscall_64+0xf3/0x690\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n RIP: 0033:0x7f7da0e6e36d\n ...\n \u0026lt;/TASK\u0026gt;\n\n The buggy address belongs to a 1-page vmalloc region starting at 0xffffc900031c9000 allocated at __dev_ethtool+0x3cc9/0x5830\n The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:0000000000000000\n index:0xffff88813a013de0 pfn:0x13a013\n flags: 0x200000000000000(node=0|zone=2)\n raw: 0200000000000000 0000000000000000 dead000000000122 0000000000000000\n raw: ffff88813a013de0 0000000000000000 00000001ffffffff 0000000000000000\n page dumped because: kasan: bad access detected\n\n Memory state around the buggy address:\n ffffc900031c8f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8\n ffffc900031c9000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n \u0026gt;ffffc900031c9080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8\n ^\n ffffc900031c9100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8\n ffffc900031c9180: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8(CVE-2026-31505)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: L2CAP: Fix null-ptr-deref on l2cap_sock_ready_cb\n\nBefore using sk pointer, check if it is null.\n\nFix the following:\n\n KASAN: null-ptr-deref in range [0x0000000000000260-0x0000000000000267]\n CPU: 0 UID: 0 PID: 5985 Comm: kworker/0:5 Not tainted 7.0.0-rc4-00029-ga989fde763f4 #1 PREEMPT(full)\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-9.fc43 06/10/2025\n Workqueue: events l2cap_info_timeout\n RIP: 0010:kasan_byte_accessible+0x12/0x30\n Code: 79 ff ff ff 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 40 d6 48 c1 ef 03 48 b8 00 00 00 00 00 fc ff df \u0026lt;0f\u0026gt; b6 04 07 3c 08 0f 92 c0 c3 cc cce\n veth0_macvtap: entered promiscuous mode\n RSP: 0018:ffffc90006e0f808 EFLAGS: 00010202\n RAX: dffffc0000000000 RBX: ffffffff89746018 RCX: 0000000080000001\n RDX: 0000000000000000 RSI: ffffffff89746018 RDI: 000000000000004c\n RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000\n R10: dffffc0000000000 R11: ffffffff8aae3e70 R12: 0000000000000000\n R13: 0000000000000260 R14: 0000000000000260 R15: 0000000000000001\n FS: 0000000000000000(0000) GS:ffff8880983c2000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00005582615a5008 CR3: 000000007007e000 CR4: 0000000000752ef0\n PKRU: 55555554\n Call Trace:\n \u0026lt;TASK\u0026gt;\n __kasan_check_byte+0x12/0x40\n lock_acquire+0x79/0x2e0\n lock_sock_nested+0x48/0x100\n ? l2cap_sock_ready_cb+0x46/0x160\n l2cap_sock_ready_cb+0x46/0x160\n l2cap_conn_start+0x779/0xff0\n ? __pfx_l2cap_conn_start+0x10/0x10\n ? l2cap_info_timeout+0x60/0xa0\n ? __pfx___mutex_lock+0x10/0x10\n l2cap_info_timeout+0x68/0xa0\n ? process_scheduled_works+0xa8d/0x18c0\n process_scheduled_works+0xb6e/0x18c0\n ? __pfx_process_scheduled_works+0x10/0x10\n ? assign_work+0x3d5/0x5e0\n worker_thread+0xa53/0xfc0\n kthread+0x388/0x470\n ? __pfx_worker_thread+0x10/0x10\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x51e/0xb90\n ? __pfx_ret_from_fork+0x10/0x10\n veth1_macvtap: entered promiscuous mode\n ? __switch_to+0xc7d/0x1450\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1a/0x30\n \u0026lt;/TASK\u0026gt;\n Modules linked in:\n ---[ end trace 0000000000000000 ]---\n batman_adv: batadv0: Interface activated: batadv_slave_0\n batman_adv: batadv0: Interface activated: batadv_slave_1\n netdevsim netdevsim7 netdevsim0: set [1, 0] type 2 family 0 port 6081 - 0\n netdevsim netdevsim7 netdevsim1: set [1, 0] type 2 family 0 port 6081 - 0\n netdevsim netdevsim7 netdevsim2: set [1, 0] type 2 family 0 port 6081 - 0\n netdevsim netdevsim7 netdevsim3: set [1, 0] type 2 family 0 port 6081 - 0\n RIP: 0010:kasan_byte_accessible+0x12/0x30\n Code: 79 ff ff ff 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 40 d6 48 c1 ef 03 48 b8 00 00 00 00 00 fc ff df \u0026lt;0f\u0026gt; b6 04 07 3c 08 0f 92 c0 c3 cc cce\n ieee80211 phy39: Selected rate control algorithm \u0026apos;minstrel_ht\u0026apos;\n RSP: 0018:ffffc90006e0f808 EFLAGS: 00010202\n RAX: dffffc0000000000 RBX: ffffffff89746018 RCX: 0000000080000001\n RDX: 0000000000000000 RSI: ffffffff89746018 RDI: 000000000000004c\n RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000\n R10: dffffc0000000000 R11: ffffffff8aae3e70 R12: 0000000000000000\n R13: 0000000000000260 R14: 0000000000000260 R15: 0000000000000001\n FS: 0000000000000000(0000) GS:ffff8880983c2000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00007f7e16139e9c CR3: 000000000e74e000 CR4: 0000000000752ef0\n PKRU: 55555554\n Kernel panic - not syncing: Fatal exception(CVE-2026-31510)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: MGMT: Fix dangling pointer on mgmt_add_adv_patterns_monitor_complete\n\nThis fixes the condition checking so mgmt_pending_valid is executed\nwhenever status != -ECANCELED otherwise calling mgmt_pending_free(cmd)\nwould kfree(cmd) without unlinking it from the list first, leaving a\ndangling pointer. Any subsequent list traversal (e.g.,\nmgmt_pending_foreach during __mgmt_power_off, or another\nmgmt_pending_valid call) would dereference freed memory.(CVE-2026-31511)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: L2CAP: Validate PDU length before reading SDU length in l2cap_ecred_data_rcv()\n\nl2cap_ecred_data_rcv() reads the SDU length field from skb-\u0026gt;data using\nget_unaligned_le16() without first verifying that skb contains at least\nL2CAP_SDULEN_SIZE (2) bytes. When skb-\u0026gt;len is less than 2, this reads\npast the valid data in the skb.\n\nThe ERTM reassembly path correctly calls pskb_may_pull() before reading\nthe SDU length (l2cap_reassemble_sdu, L2CAP_SAR_START case). Apply the\nsame validation to the Enhanced Credit Based Flow Control data path.(CVE-2026-31512)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: prevent policy_hthresh.work from racing with netns teardown\n\nA XFRM_MSG_NEWSPDINFO request can queue the per-net work item\npolicy_hthresh.work onto the system workqueue.\n\nThe queued callback, xfrm_hash_rebuild(), retrieves the enclosing\nstruct net via container_of(). If the net namespace is torn down\nbefore that work runs, the associated struct net may already have\nbeen freed, and xfrm_hash_rebuild() may then dereference stale memory.\n\nxfrm_policy_fini() already flushes policy_hash_work during teardown,\nbut it does not synchronize policy_hthresh.work.\n\nSynchronize policy_hthresh.work in xfrm_policy_fini() as well, so the\nqueued work cannot outlive the net namespace teardown and access a\nfreed struct net.(CVE-2026-31516)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nesp: fix skb leak with espintcp and async crypto\n\nWhen the TX queue for espintcp is full, esp_output_tail_tcp will\nreturn an error and not free the skb, because with synchronous crypto,\nthe common xfrm output code will drop the packet for us.\n\nWith async crypto (esp_output_done), we need to drop the skb when\nesp_output_tail_tcp returns an error.(CVE-2026-31518)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix undefined behavior in interpreter sdiv/smod for INT_MIN\n\nThe BPF interpreter\u0026apos;s signed 32-bit division and modulo handlers use\nthe kernel abs() macro on s32 operands. The abs() macro documentation\n(include/linux/math.h) explicitly states the result is undefined when\nthe input is the type minimum. When DST contains S32_MIN (0x80000000),\nabs((s32)DST) triggers undefined behavior and returns S32_MIN unchanged\non arm64/x86. This value is then sign-extended to u64 as\n0xFFFFFFFF80000000, causing do_div() to compute the wrong result.\n\nThe verifier\u0026apos;s abstract interpretation (scalar32_min_max_sdiv) computes\nthe mathematically correct result for range tracking, creating a\nverifier/interpreter mismatch that can be exploited for out-of-bounds\nmap value access.\n\nIntroduce abs_s32() which handles S32_MIN correctly by casting to u32\nbefore negating, avoiding signed overflow entirely. Replace all 8\nabs((s32)...) call sites in the interpreter\u0026apos;s sdiv32/smod32 handlers.\n\ns32 is the only affected case -- the s64 division/modulo handlers do\nnot use abs().(CVE-2026-31525)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nperf: Make sure to use pmu_ctx-\u0026gt;pmu for groups\n\nOliver reported that x86_pmu_del() ended up doing an out-of-bound memory access\nwhen group_sched_in() fails and needs to roll back.\n\nThis *should* be handled by the transaction callbacks, but he found that when\nthe group leader is a software event, the transaction handlers of the wrong PMU\nare used. Despite the move_group case in perf_event_open() and group_sched_in()\nusing pmu_ctx-\u0026gt;pmu.\n\nTurns out, inherit uses event-\u0026gt;pmu to clone the events, effectively undoing the\nmove_group case for all inherited contexts. Fix this by also making inherit use\npmu_ctx-\u0026gt;pmu, ensuring all inherited counters end up in the same pmu context.\n\nSimilarly, __perf_event_read() should use equally use pmu_ctx-\u0026gt;pmu for the\ngroup case.(CVE-2026-31528)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv4: nexthop: allocate skb dynamically in rtm_get_nexthop()\n\nWhen querying a nexthop object via RTM_GETNEXTHOP, the kernel currently\nallocates a fixed-size skb using NLMSG_GOODSIZE. While sufficient for\nsingle nexthops and small Equal-Cost Multi-Path groups, this fixed\nallocation fails for large nexthop groups like 512 nexthops.\n\nThis results in the following warning splat:\n\n WARNING: net/ipv4/nexthop.c:3395 at rtm_get_nexthop+0x176/0x1c0, CPU#20: rep/4608\n [...]\n RIP: 0010:rtm_get_nexthop (net/ipv4/nexthop.c:3395)\n [...]\n Call Trace:\n \u0026lt;TASK\u0026gt;\n rtnetlink_rcv_msg (net/core/rtnetlink.c:6989)\n netlink_rcv_skb (net/netlink/af_netlink.c:2550)\n netlink_unicast (net/netlink/af_netlink.c:1319 net/netlink/af_netlink.c:1344)\n netlink_sendmsg (net/netlink/af_netlink.c:1894)\n ____sys_sendmsg (net/socket.c:721 net/socket.c:736 net/socket.c:2585)\n ___sys_sendmsg (net/socket.c:2641)\n __sys_sendmsg (net/socket.c:2671)\n do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94)\n entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)\n \u0026lt;/TASK\u0026gt;\n\nFix this by allocating the size dynamically using nh_nlmsg_size() and\nusing nlmsg_new(), this is consistent with nexthop_notify() behavior. In\naddition, adjust nh_nlmsg_size_grp() so it calculates the size needed\nbased on flags passed. While at it, also add the size of NHA_FDB for\nnexthop group size calculation as it was missing too.\n\nThis cannot be reproduced via iproute2 as the group size is currently\nlimited and the command fails as follows:\n\naddattr_l ERROR: message exceeded bound of 1048(CVE-2026-31531)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncan: raw: fix ro-\u0026gt;uniq use-after-free in raw_rcv()\n\nraw_release() unregisters raw CAN receive filters via can_rx_unregister(),\nbut receiver deletion is deferred with call_rcu(). This leaves a window\nwhere raw_rcv() may still be running in an RCU read-side critical section\nafter raw_release() frees ro-\u0026gt;uniq, leading to a use-after-free of the\npercpu uniq storage.\n\nMove free_percpu(ro-\u0026gt;uniq) out of raw_release() and into a raw-specific\nsocket destructor. can_rx_unregister() takes an extra reference to the\nsocket and only drops it from the RCU callback, so freeing uniq from\nsk_destruct ensures the percpu area is not released until the relevant\ncallbacks have drained.\n\n[mkl: applied manually](CVE-2026-31532)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/tls: fix use-after-free in -EBUSY error path of tls_do_encryption\n\nThe -EBUSY handling in tls_do_encryption(), introduced by commit\n859054147318 (\u0026quot;net: tls: handle backlogging of crypto requests\u0026quot;), has\na use-after-free due to double cleanup of encrypt_pending and the\nscatterlist entry.\n\nWhen crypto_aead_encrypt() returns -EBUSY, the request is enqueued to\nthe cryptd backlog and the async callback tls_encrypt_done() will be\ninvoked upon completion. That callback unconditionally restores the\nscatterlist entry (sge-\u0026gt;offset, sge-\u0026gt;length) and decrements\nctx-\u0026gt;encrypt_pending. However, if tls_encrypt_async_wait() returns an\nerror, the synchronous error path in tls_do_encryption() performs the\nsame cleanup again, double-decrementing encrypt_pending and\ndouble-restoring the scatterlist.\n\nThe double-decrement corrupts the encrypt_pending sentinel (initialized\nto 1), making tls_encrypt_async_wait() permanently skip the wait for\npending async callbacks. A subsequent sendmsg can then free the\ntls_rec via bpf_exec_tx_verdict() while a cryptd callback is still\npending, resulting in a use-after-free when the callback fires on the\nfreed record.\n\nFix this by skipping the synchronous cleanup when the -EBUSY async\nwait returns an error, since the callback has already handled\nencrypt_pending and sge restoration.(CVE-2026-31533)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/i915/gt: Check set_default_submission() before deferencing\n\nWhen the i915 driver firmware binaries are not present, the\nset_default_submission pointer is not set. This pointer is\ndereferenced during suspend anyways.\n\nAdd a check to make sure it is set before dereferencing.\n\n[ 23.289926] PM: suspend entry (deep)\n[ 23.293558] Filesystems sync: 0.000 seconds\n[ 23.298010] Freezing user space processes\n[ 23.302771] Freezing user space processes completed (elapsed 0.000 seconds)\n[ 23.309766] OOM killer disabled.\n[ 23.313027] Freezing remaining freezable tasks\n[ 23.318540] Freezing remaining freezable tasks completed (elapsed 0.001 seconds)\n[ 23.342038] serial 00:05: disabled\n[ 23.345719] serial 00:02: disabled\n[ 23.349342] serial 00:01: disabled\n[ 23.353782] sd 0:0:0:0: [sda] Synchronizing SCSI cache\n[ 23.358993] sd 1:0:0:0: [sdb] Synchronizing SCSI cache\n[ 23.361635] ata1.00: Entering standby power mode\n[ 23.368863] ata2.00: Entering standby power mode\n[ 23.445187] BUG: kernel NULL pointer dereference, address: 0000000000000000\n[ 23.452194] #PF: supervisor instruction fetch in kernel mode\n[ 23.457896] #PF: error_code(0x0010) - not-present page\n[ 23.463065] PGD 0 P4D 0\n[ 23.465640] Oops: Oops: 0010 [#1] SMP NOPTI\n[ 23.469869] CPU: 8 UID: 0 PID: 211 Comm: kworker/u48:18 Tainted: G S W 6.19.0-rc4-00020-gf0b9d8eb98df #10 PREEMPT(voluntary)\n[ 23.482512] Tainted: [S]=CPU_OUT_OF_SPEC, [W]=WARN\n[ 23.496511] Workqueue: async async_run_entry_fn\n[ 23.501087] RIP: 0010:0x0\n[ 23.503755] Code: Unable to access opcode bytes at 0xffffffffffffffd6.\n[ 23.510324] RSP: 0018:ffffb4a60065fca8 EFLAGS: 00010246\n[ 23.515592] RAX: 0000000000000000 RBX: ffff9f428290e000 RCX: 000000000000000f\n[ 23.522765] RDX: 0000000000000000 RSI: 0000000000000282 RDI: ffff9f428290e000\n[ 23.529937] RBP: ffff9f4282907070 R08: ffff9f4281130428 R09: 00000000ffffffff\n[ 23.537111] R10: 0000000000000000 R11: 0000000000000001 R12: ffff9f42829070f8\n[ 23.544284] R13: ffff9f4282906028 R14: ffff9f4282900000 R15: ffff9f4282906b68\n[ 23.551457] FS: 0000000000000000(0000) GS:ffff9f466b2cf000(0000) knlGS:0000000000000000\n[ 23.559588] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 23.565365] CR2: ffffffffffffffd6 CR3: 000000031c230001 CR4: 0000000000f70ef0\n[ 23.572539] PKRU: 55555554\n[ 23.575281] Call Trace:\n[ 23.577770] \u0026lt;TASK\u0026gt;\n[ 23.579905] intel_engines_reset_default_submission+0x42/0x60\n[ 23.585695] __intel_gt_unset_wedged+0x191/0x200\n[ 23.590360] intel_gt_unset_wedged+0x20/0x40\n[ 23.594675] gt_sanitize+0x15e/0x170\n[ 23.598290] i915_gem_suspend_late+0x6b/0x180\n[ 23.602692] i915_drm_suspend_late+0x35/0xf0\n[ 23.607008] ? __pfx_pci_pm_suspend_late+0x10/0x10\n[ 23.611843] dpm_run_callback+0x78/0x1c0\n[ 23.615817] device_suspend_late+0xde/0x2e0\n[ 23.620037] async_suspend_late+0x18/0x30\n[ 23.624082] async_run_entry_fn+0x25/0xa0\n[ 23.628129] process_one_work+0x15b/0x380\n[ 23.632182] worker_thread+0x2a5/0x3c0\n[ 23.635973] ? __pfx_worker_thread+0x10/0x10\n[ 23.640279] kthread+0xf6/0x1f0\n[ 23.643464] ? __pfx_kthread+0x10/0x10\n[ 23.647263] ? __pfx_kthread+0x10/0x10\n[ 23.651045] ret_from_fork+0x131/0x190\n[ 23.654837] ? __pfx_kthread+0x10/0x10\n[ 23.658634] ret_from_fork_asm+0x1a/0x30\n[ 23.662597] \u0026lt;/TASK\u0026gt;\n[ 23.664826] Modules linked in:\n[ 23.667914] CR2: 0000000000000000\n[ 23.671271] ------------[ cut here ]------------\n\n(cherry picked from commit daa199abc3d3d1740c9e3a2c3e9216ae5b447cad)(CVE-2026-31540)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nx86/platform/uv: Handle deconfigured sockets\n\nWhen a socket is deconfigured, it\u0026apos;s mapped to SOCK_EMPTY (0xffff). This causes\na panic while allocating UV hub info structures.\n\nFix this by using NUMA_NO_NODE, allowing UV hub info structures to be\nallocated on valid nodes.(CVE-2026-31542)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: bonding: fix NULL deref in bond_debug_rlb_hash_show\n\nrlb_clear_slave intentionally keeps RLB hash-table entries on\nthe rx_hashtbl_used_head list with slave set to NULL when no\nreplacement slave is available. However, bond_debug_rlb_hash_show\nvisites client_info-\u0026gt;slave without checking if it\u0026apos;s NULL.\n\nOther used-list iterators in bond_alb.c already handle this NULL-slave\nstate safely:\n\n- rlb_update_client returns early on !client_info-\u0026gt;slave\n- rlb_req_update_slave_clients, rlb_clear_slave, and rlb_rebalance\ncompare slave values before visiting\n- lb_req_update_subnet_clients continues if slave is NULL\n\nThe following NULL deref crash can be trigger in\nbond_debug_rlb_hash_show:\n\n[ 1.289791] BUG: kernel NULL pointer dereference, address: 0000000000000000\n[ 1.292058] RIP: 0010:bond_debug_rlb_hash_show (drivers/net/bonding/bond_debugfs.c:41)\n[ 1.293101] RSP: 0018:ffffc900004a7d00 EFLAGS: 00010286\n[ 1.293333] RAX: 0000000000000000 RBX: ffff888102b48200 RCX: ffff888102b48204\n[ 1.293631] RDX: ffff888102b48200 RSI: ffffffff839daad5 RDI: ffff888102815078\n[ 1.293924] RBP: ffff888102815078 R08: ffff888102b4820e R09: 0000000000000000\n[ 1.294267] R10: 0000000000000000 R11: 0000000000000000 R12: ffff888100f929c0\n[ 1.294564] R13: ffff888100f92a00 R14: 0000000000000001 R15: ffffc900004a7ed8\n[ 1.294864] FS: 0000000001395380(0000) GS:ffff888196e75000(0000) knlGS:0000000000000000\n[ 1.295239] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 1.295480] CR2: 0000000000000000 CR3: 0000000102adc004 CR4: 0000000000772ef0\n[ 1.295897] Call Trace:\n[ 1.296134] seq_read_iter (fs/seq_file.c:231)\n[ 1.296341] seq_read (fs/seq_file.c:164)\n[ 1.296493] full_proxy_read (fs/debugfs/file.c:378 (discriminator 1))\n[ 1.296658] vfs_read (fs/read_write.c:572)\n[ 1.296981] ksys_read (fs/read_write.c:717)\n[ 1.297132] do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1) arch/x86/entry/syscall_64.c:94 (discriminator 1))\n[ 1.297325] entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)\n\nAdd a NULL check and print \u0026quot;(none)\u0026quot; for entries with no assigned slave.(CVE-2026-31546)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfutex: Clear stale exiting pointer in futex_lock_pi() retry path\n\nFuzzying/stressing futexes triggered:\n\n WARNING: kernel/futex/core.c:825 at wait_for_owner_exiting+0x7a/0x80, CPU#11: futex_lock_pi_s/524\n\nWhen futex_lock_pi_atomic() sees the owner is exiting, it returns -EBUSY\nand stores a refcounted task pointer in \u0026apos;exiting\u0026apos;.\n\nAfter wait_for_owner_exiting() consumes that reference, the local pointer\nis never reset to nil. Upon a retry, if futex_lock_pi_atomic() returns a\ndifferent error, the bogus pointer is passed to wait_for_owner_exiting().\n\n CPU0\t\t\t CPU1\t\t CPU2\n futex_lock_pi(uaddr)\n // acquires the PI futex\n exit()\n futex_cleanup_begin()\n futex_state = EXITING;\n\t\t\t futex_lock_pi(uaddr)\n\t\t\t futex_lock_pi_atomic()\n\t\t\t\t attach_to_pi_owner()\n\t\t\t\t // observes EXITING\n\t\t\t\t *exiting = owner; // takes ref\n\t\t\t\t return -EBUSY\n\t\t\t wait_for_owner_exiting(-EBUSY, owner)\n\t\t\t\t put_task_struct(); // drops ref\n\t\t\t // exiting still points to owner\n\t\t\t goto retry;\n\t\t\t futex_lock_pi_atomic()\n\t\t\t\t lock_pi_update_atomic()\n\t\t\t\t cmpxchg(uaddr)\n\t\t\t\t\t*uaddr ^= WAITERS // whatever\n\t\t\t\t // value changed\n\t\t\t\t return -EAGAIN;\n\t\t\t wait_for_owner_exiting(-EAGAIN, exiting) // stale\n\t\t\t\t WARN_ON_ONCE(exiting)\n\nFix this by resetting upon retry, essentially aligning it with requeue_pi.(CVE-2026-31555)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu: Fix fence put before wait in amdgpu_amdkfd_submit_ib\n\namdgpu_amdkfd_submit_ib() submits a GPU job and gets a fence\nfrom amdgpu_ib_schedule(). This fence is used to wait for job\ncompletion.\n\nCurrently, the code drops the fence reference using dma_fence_put()\nbefore calling dma_fence_wait().\n\nIf dma_fence_put() releases the last reference, the fence may be\nfreed before dma_fence_wait() is called. This can lead to a\nuse-after-free.\n\nFix this by waiting on the fence first and releasing the reference\nonly after dma_fence_wait() completes.\n\nFixes the below:\ndrivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c:697 amdgpu_amdkfd_submit_ib() warn: passing freed memory \u0026apos;f\u0026apos; (line 696)\n\n(cherry picked from commit 8b9e5259adc385b61a6590a13b82ae0ac2bd3482)(CVE-2026-31566)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncan: gw: fix OOB heap access in cgw_csum_crc8_rel()\n\ncgw_csum_crc8_rel() correctly computes bounds-safe indices via calc_idx():\n\n int from = calc_idx(crc8-\u0026gt;from_idx, cf-\u0026gt;len);\n int to = calc_idx(crc8-\u0026gt;to_idx, cf-\u0026gt;len);\n int res = calc_idx(crc8-\u0026gt;result_idx, cf-\u0026gt;len);\n\n if (from \u0026lt; 0 || to \u0026lt; 0 || res \u0026lt; 0)\n return;\n\nHowever, the loop and the result write then use the raw s8 fields directly\ninstead of the computed variables:\n\n for (i = crc8-\u0026gt;from_idx; ...) /* BUG: raw negative index */\n cf-\u0026gt;data[crc8-\u0026gt;result_idx] = ...; /* BUG: raw negative index */\n\nWith from_idx = to_idx = result_idx = -64 on a 64-byte CAN FD frame,\ncalc_idx(-64, 64) = 0 so the guard passes, but the loop iterates with\ni = -64, reading cf-\u0026gt;data[-64], and the write goes to cf-\u0026gt;data[-64].\nThis write might end up to 56 (7.0-rc) or 40 (\u0026lt;= 6.19) bytes before the\nstart of the canfd_frame on the heap.\n\nThe companion function cgw_csum_xor_rel() uses `from`/`to`/`res`\ncorrectly throughout; fix cgw_csum_crc8_rel() to match.\n\nConfirmed with KASAN on linux-7.0-rc2:\n BUG: KASAN: slab-out-of-bounds in cgw_csum_crc8_rel+0x515/0x5b0\n Read of size 1 at addr ffff8880076619c8 by task poc_cgw_oob/62\n\nTo configure the can-gw crc8 checksums CAP_NET_ADMIN is needed.(CVE-2026-31570)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: SEV: Drop WARN on large size for KVM_MEMORY_ENCRYPT_REG_REGION\n\nDrop the WARN in sev_pin_memory() on npages overflowing an int, as the\nWARN is comically trivially to trigger from userspace, e.g. by doing:\n\n struct kvm_enc_region range = {\n .addr = 0,\n .size = -1ul,\n };\n\n __vm_ioctl(vm, KVM_MEMORY_ENCRYPT_REG_REGION, \u0026amp;range);\n\nNote, the checks in sev_mem_enc_register_region() that presumably exist to\nverify the incoming address+size are completely worthless, as both \u0026quot;addr\u0026quot;\nand \u0026quot;size\u0026quot; are u64s and SEV is 64-bit only, i.e. they _can\u0026apos;t_ be greater\nthan ULONG_MAX. That wart will be cleaned up in the near future.\n\n\tif (range-\u0026gt;addr \u0026gt; ULONG_MAX || range-\u0026gt;size \u0026gt; ULONG_MAX)\n\t\treturn -EINVAL;\n\nOpportunistically add a comment to explain why the code calculates the\nnumber of pages the \u0026quot;hard\u0026quot; way, e.g. instead of just shifting @ulen.(CVE-2026-31590)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nPCI: endpoint: pci-epf-vntb: Stop cmd_handler work in epf_ntb_epc_cleanup\n\nDisable the delayed work before clearing BAR mappings and doorbells to\navoid running the handler after resources have been torn down.\n\n Unable to handle kernel paging request at virtual address ffff800083f46004\n [...]\n Internal error: Oops: 0000000096000007 [#1] SMP\n [...]\n Call trace:\n epf_ntb_cmd_handler+0x54/0x200 [pci_epf_vntb] (P)\n process_one_work+0x154/0x3b0\n worker_thread+0x2c8/0x400\n kthread+0x148/0x210\n ret_from_fork+0x10/0x20(CVE-2026-31595)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nx86/CPU: Fix FPDSS on Zen1\n\nZen1\u0026apos;s hardware divider can leave, under certain circumstances, partial\nresults from previous operations. Those results can be leaked by\nanother, attacker thread.\n\nFix that with a chicken bit.(CVE-2026-31628)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nrxrpc: proc: size address buffers for %pISpc output\n\nThe AF_RXRPC procfs helpers format local and remote socket addresses into\nfixed 50-byte stack buffers with \u0026quot;%pISpc\u0026quot;.\n\nThat is too small for the longest current-tree IPv6-with-port form the\nformatter can produce. In lib/vsprintf.c, the compressed IPv6 path uses a\ndotted-quad tail not only for v4mapped addresses, but also for ISATAP\naddresses via ipv6_addr_is_isatap().\n\nAs a result, a case such as\n\n [ffff:ffff:ffff:ffff:0:5efe:255.255.255.255]:65535\n\nis possible with the current formatter. That is 50 visible characters, so\n51 bytes including the trailing NUL, which does not fit in the existing\nchar[50] buffers used by net/rxrpc/proc.c.\n\nSize the buffers from the formatter\u0026apos;s maximum textual form and switch the\ncall sites to scnprintf().\n\nChanges since v1:\n- correct the changelog to cite the actual maximum current-tree case\n explicitly\n- frame the proof around the ISATAP formatting path instead of the earlier\n mapped-v4 example(CVE-2026-31630)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmmc: vub300: fix NULL-deref on disconnect\n\nMake sure to deregister the controller before dropping the reference to\nthe driver data on disconnect to avoid NULL-pointer dereferences or\nuse-after-free.(CVE-2026-31651)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nft_ct: fix use-after-free in timeout object destroy\n\nnft_ct_timeout_obj_destroy() frees the timeout object with kfree()\nimmediately after nf_ct_untimeout(), without waiting for an RCU grace\nperiod. Concurrent packet processing on other CPUs may still hold\nRCU-protected references to the timeout object obtained via\nrcu_dereference() in nf_ct_timeout_data().\n\nAdd an rcu_head to struct nf_ct_timeout and use kfree_rcu() to defer\nfreeing until after an RCU grace period, matching the approach already\nused in nfnetlink_cttimeout.c.\n\nKASAN report:\n BUG: KASAN: slab-use-after-free in nf_conntrack_tcp_packet+0x1381/0x29d0\n Read of size 4 at addr ffff8881035fe19c by task exploit/80\n\n Call Trace:\n nf_conntrack_tcp_packet+0x1381/0x29d0\n nf_conntrack_in+0x612/0x8b0\n nf_hook_slow+0x70/0x100\n __ip_local_out+0x1b2/0x210\n tcp_sendmsg_locked+0x722/0x1580\n __sys_sendto+0x2d8/0x320\n\n Allocated by task 75:\n nft_ct_timeout_obj_init+0xf6/0x290\n nft_obj_init+0x107/0x1b0\n nf_tables_newobj+0x680/0x9c0\n nfnetlink_rcv_batch+0xc29/0xe00\n\n Freed by task 26:\n nft_obj_destroy+0x3f/0xa0\n nf_tables_trans_destroy_work+0x51c/0x5c0\n process_one_work+0x2c4/0x5a0(CVE-2026-31665)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nInput: uinput - fix circular locking dependency with ff-core\n\nA lockdep circular locking dependency warning can be triggered\nreproducibly when using a force-feedback gamepad with uinput (for\nexample, playing ELDEN RING under Wine with a Flydigi Vader 5\ncontroller):\n\n ff-\u0026gt;mutex -\u0026gt; udev-\u0026gt;mutex -\u0026gt; input_mutex -\u0026gt; dev-\u0026gt;mutex -\u0026gt; ff-\u0026gt;mutex\n\nThe cycle is caused by four lock acquisition paths:\n\n1. ff upload: input_ff_upload() holds ff-\u0026gt;mutex and calls\n uinput_dev_upload_effect() -\u0026gt; uinput_request_submit() -\u0026gt;\n uinput_request_send(), which acquires udev-\u0026gt;mutex.\n\n2. device create: uinput_ioctl_handler() holds udev-\u0026gt;mutex and calls\n uinput_create_device() -\u0026gt; input_register_device(), which acquires\n input_mutex.\n\n3. device register: input_register_device() holds input_mutex and\n calls kbd_connect() -\u0026gt; input_register_handle(), which acquires\n dev-\u0026gt;mutex.\n\n4. evdev release: evdev_release() calls input_flush_device() under\n dev-\u0026gt;mutex, which calls input_ff_flush() acquiring ff-\u0026gt;mutex.\n\nFix this by introducing a new state_lock spinlock to protect\nudev-\u0026gt;state and udev-\u0026gt;dev access in uinput_request_send() instead of\nacquiring udev-\u0026gt;mutex. The function only needs to atomically check\ndevice state and queue an input event into the ring buffer via\nuinput_dev_event() -- both operations are safe under a spinlock\n(ktime_get_ts64() and wake_up_interruptible() do not sleep). This\nbreaks the ff-\u0026gt;mutex -\u0026gt; udev-\u0026gt;mutex link since a spinlock is a leaf in\nthe lock ordering and cannot form cycles with mutexes.\n\nTo keep state transitions visible to uinput_request_send(), protect\nwrites to udev-\u0026gt;state in uinput_create_device() and\nuinput_destroy_device() with the same state_lock spinlock.\n\nAdditionally, move init_completion(\u0026amp;request-\u0026gt;done) from\nuinput_request_send() to uinput_request_submit() before\nuinput_request_reserve_slot(). Once the slot is allocated,\nuinput_flush_requests() may call complete() on it at any time from\nthe destroy path, so the completion must be initialised before the\nrequest becomes visible.\n\nLock ordering after the fix:\n\n ff-\u0026gt;mutex -\u0026gt; state_lock (spinlock, leaf)\n udev-\u0026gt;mutex -\u0026gt; state_lock (spinlock, leaf)\n udev-\u0026gt;mutex -\u0026gt; input_mutex -\u0026gt; dev-\u0026gt;mutex -\u0026gt; ff-\u0026gt;mutex (no back-edge)(CVE-2026-31667)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: sch_netem: fix out-of-bounds access in packet corruption\n\nIn netem_enqueue(), the packet corruption logic uses\nget_random_u32_below(skb_headlen(skb)) to select an index for\nmodifying skb-\u0026gt;data. When an AF_PACKET TX_RING sends fully non-linear\npackets over an IPIP tunnel, skb_headlen(skb) evaluates to 0.\n\nPassing 0 to get_random_u32_below() takes the variable-ceil slow path\nwhich returns an unconstrained 32-bit random integer. Using this\nunconstrained value as an offset into skb-\u0026gt;data results in an\nout-of-bounds memory access.\n\nFix this by verifying skb_headlen(skb) is non-zero before attempting\nto corrupt the linear data area. Fully non-linear packets will silently\nbypass the corruption logic.(CVE-2026-31675)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: af_alg - limit RX SG extraction by receive buffer budget\n\nMake af_alg_get_rsgl() limit each RX scatterlist extraction to the\nremaining receive buffer budget.\n\naf_alg_get_rsgl() currently uses af_alg_readable() only as a gate\nbefore extracting data into the RX scatterlist. Limit each extraction\nto the remaining af_alg_rcvbuf(sk) budget so that receive-side\naccounting matches the amount of data attached to the request.\n\nIf skcipher cannot obtain enough RX space for at least one chunk while\nmore data remains to be processed, reject the recvmsg call instead of\nrounding the request length down to zero.(CVE-2026-31677)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nopenvswitch: defer tunnel netdev_put to RCU release\n\novs_netdev_tunnel_destroy() may run after NETDEV_UNREGISTER already\ndetached the device. Dropping the netdev reference in destroy can race\nwith concurrent readers that still observe vport-\u0026gt;dev.\n\nDo not release vport-\u0026gt;dev in ovs_netdev_tunnel_destroy(). Instead, let\nvport_netdev_free() drop the reference from the RCU callback, matching\nthe non-tunnel destroy path and avoiding additional synchronization\nunder RTNL.(CVE-2026-31678)\n\nIn the Linux kernel, a memory out-of-bounds access vulnerability exists in the act_csum module\u0026apos;s tcf_csum_act() function when processing nested VLAN headers. When an skb still carries in-payload VLAN tags, the function walks nested VLAN headers directly from skb-\u0026gt;data. The current code reads vlan-\u0026gt;h_vlan_encapsulated_proto and then pulls VLAN_HLEN bytes without first ensuring that the full VLAN header is present in the linear area. If only part of an inner VLAN header is linearized, accessing h_vlan_encapsulated_proto reads past the linear area, and the following skb_pull(VLAN_HLEN) may violate skb invariants.(CVE-2026-31684)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: ip6t_eui64: reject invalid MAC header for all packets\n\n`eui64_mt6()` derives a modified EUI-64 from the Ethernet source address\nand compares it with the low 64 bits of the IPv6 source address.\n\nThe existing guard only rejects an invalid MAC header when\n`par-\u0026gt;fragoff != 0`. For packets with `par-\u0026gt;fragoff == 0`, `eui64_mt6()`\ncan still reach `eth_hdr(skb)` even when the MAC header is not valid.\n\nFix this by removing the `par-\u0026gt;fragoff != 0` condition so that packets\nwith an invalid MAC header are rejected before accessing `eth_hdr(skb)`.(CVE-2026-31685)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nEDAC/mc: Fix error path ordering in edac_mc_alloc()\n\nWhen the mci-\u0026gt;pvt_info allocation in edac_mc_alloc() fails, the error path\nwill call put_device() which will end up calling the device\u0026apos;s release\nfunction.\n\nHowever, the init ordering is wrong such that device_initialize() happens\n*after* the failed allocation and thus the device itself and the release\nfunction pointer are not initialized yet when they\u0026apos;re called:\n\n MCE: In-kernel MCE decoding enabled.\n ------------[ cut here ]------------\n kobject: \u0026apos;(null)\u0026apos;: is not initialized, yet kobject_put() is being called.\n WARNING: lib/kobject.c:734 at kobject_put, CPU#22: systemd-udevd\n CPU: 22 UID: 0 PID: 538 Comm: systemd-udevd Not tainted 7.0.0-rc1+ #2 PREEMPT(full)\n RIP: 0010:kobject_put\n Call Trace:\n \u0026lt;TASK\u0026gt;\n edac_mc_alloc+0xbe/0xe0 [edac_core]\n amd64_edac_init+0x7a4/0xff0 [amd64_edac]\n ? __pfx_amd64_edac_init+0x10/0x10 [amd64_edac]\n do_one_initcall\n ...\n\nReorder the calling sequence so that the device is initialized and thus the\nrelease function pointer is properly set before it can be used.\n\nThis was found by Claude while reviewing another EDAC patch.(CVE-2026-31689)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: ccp: Don\u0026apos;t attempt to copy ID to userspace if PSP command failed\n\nWhen retrieving the ID for the CPU, don\u0026apos;t attempt to copy the ID blob to\nuserspace if the firmware command failed. If the failure was due to an\ninvalid length, i.e. the userspace buffer+length was too small, copying\nthe number of bytes _firmware_ requires will overflow the kernel-allocated\nbuffer and leak data to userspace.\n\n BUG: KASAN: slab-out-of-bounds in instrument_copy_to_user ../include/linux/instrumented.h:129 [inline]\n BUG: KASAN: slab-out-of-bounds in _inline_copy_to_user ../include/linux/uaccess.h:205 [inline]\n BUG: KASAN: slab-out-of-bounds in _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26\n Read of size 64 at addr ffff8881867f5960 by task syz.0.906/24388\n\n CPU: 130 UID: 0 PID: 24388 Comm: syz.0.906 Tainted: G U O 7.0.0-smp-DEV #28 PREEMPTLAZY\n Tainted: [U]=USER, [O]=OOT_MODULE\n Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 12.62.0-0 11/19/2025\n Call Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0xc5/0x110 ../lib/dump_stack.c:120\n print_address_description ../mm/kasan/report.c:378 [inline]\n print_report+0xbc/0x260 ../mm/kasan/report.c:482\n kasan_report+0xa2/0xe0 ../mm/kasan/report.c:595\n check_region_inline ../mm/kasan/generic.c:-1 [inline]\n kasan_check_range+0x264/0x2c0 ../mm/kasan/generic.c:200\n instrument_copy_to_user ../include/linux/instrumented.h:129 [inline]\n _inline_copy_to_user ../include/linux/uaccess.h:205 [inline]\n _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26\n copy_to_user ../include/linux/uaccess.h:236 [inline]\n sev_ioctl_do_get_id2+0x361/0x490 ../drivers/crypto/ccp/sev-dev.c:2222\n sev_ioctl+0x25f/0x490 ../drivers/crypto/ccp/sev-dev.c:2575\n vfs_ioctl ../fs/ioctl.c:51 [inline]\n __do_sys_ioctl ../fs/ioctl.c:597 [inline]\n __se_sys_ioctl+0x11d/0x1b0 ../fs/ioctl.c:583\n do_syscall_x64 ../arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xe0/0x800 ../arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n \u0026lt;/TASK\u0026gt;\n\nWARN if the driver says the command succeeded, but the firmware error code\nsays otherwise, as __sev_do_cmd_locked() is expected to return -EIO on any\nfirwmware error.(CVE-2026-31697)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: ccp: Don\u0026apos;t attempt to copy PDH cert to userspace if PSP command failed\n\nWhen retrieving the PDH cert, don\u0026apos;t attempt to copy the blobs to userspace\nif the firmware command failed. If the failure was due to an invalid\nlength, i.e. the userspace buffer+length was too small, copying the number\nof bytes _firmware_ requires will overflow the kernel-allocated buffer and\nleak data to userspace.\n\n BUG: KASAN: slab-out-of-bounds in instrument_copy_to_user ../include/linux/instrumented.h:129 [inline]\n BUG: KASAN: slab-out-of-bounds in _inline_copy_to_user ../include/linux/uaccess.h:205 [inline]\n BUG: KASAN: slab-out-of-bounds in _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26\n Read of size 2084 at addr ffff8885c4ab8aa0 by task syz.0.186/21033\n\n CPU: 51 UID: 0 PID: 21033 Comm: syz.0.186 Tainted: G U O 7.0.0-smp-DEV #28 PREEMPTLAZY\n Tainted: [U]=USER, [O]=OOT_MODULE\n Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.84.12-0 11/17/2025\n Call Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0xc5/0x110 ../lib/dump_stack.c:120\n print_address_description ../mm/kasan/report.c:378 [inline]\n print_report+0xbc/0x260 ../mm/kasan/report.c:482\n kasan_report+0xa2/0xe0 ../mm/kasan/report.c:595\n check_region_inline ../mm/kasan/generic.c:-1 [inline]\n kasan_check_range+0x264/0x2c0 ../mm/kasan/generic.c:200\n instrument_copy_to_user ../include/linux/instrumented.h:129 [inline]\n _inline_copy_to_user ../include/linux/uaccess.h:205 [inline]\n _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26\n copy_to_user ../include/linux/uaccess.h:236 [inline]\n sev_ioctl_do_pdh_export+0x3d3/0x7c0 ../drivers/crypto/ccp/sev-dev.c:2347\n sev_ioctl+0x2a2/0x490 ../drivers/crypto/ccp/sev-dev.c:2568\n vfs_ioctl ../fs/ioctl.c:51 [inline]\n __do_sys_ioctl ../fs/ioctl.c:597 [inline]\n __se_sys_ioctl+0x11d/0x1b0 ../fs/ioctl.c:583\n do_syscall_x64 ../arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xe0/0x800 ../arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n \u0026lt;/TASK\u0026gt;\n\nWARN if the driver says the command succeeded, but the firmware error code\nsays otherwise, as __sev_do_cmd_locked() is expected to return -EIO on any\nfirwmware error.(CVE-2026-31698)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: ccp: Don\u0026apos;t attempt to copy CSR to userspace if PSP command failed\n\nWhen retrieving the PEK CSR, don\u0026apos;t attempt to copy the blob to userspace\nif the firmware command failed. If the failure was due to an invalid\nlength, i.e. the userspace buffer+length was too small, copying the number\nof bytes _firmware_ requires will overflow the kernel-allocated buffer and\nleak data to userspace.\n\n BUG: KASAN: slab-out-of-bounds in instrument_copy_to_user ../include/linux/instrumented.h:129 [inline]\n BUG: KASAN: slab-out-of-bounds in _inline_copy_to_user ../include/linux/uaccess.h:205 [inline]\n BUG: KASAN: slab-out-of-bounds in _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26\n Read of size 2084 at addr ffff898144612e20 by task syz.9.219/21405\n\n CPU: 14 UID: 0 PID: 21405 Comm: syz.9.219 Tainted: G U O 7.0.0-smp-DEV #28 PREEMPTLAZY\n Tainted: [U]=USER, [O]=OOT_MODULE\n Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 12.62.0-0 11/19/2025\n Call Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0xc5/0x110 ../lib/dump_stack.c:120\n print_address_description ../mm/kasan/report.c:378 [inline]\n print_report+0xbc/0x260 ../mm/kasan/report.c:482\n kasan_report+0xa2/0xe0 ../mm/kasan/report.c:595\n check_region_inline ../mm/kasan/generic.c:-1 [inline]\n kasan_check_range+0x264/0x2c0 ../mm/kasan/generic.c:200\n instrument_copy_to_user ../include/linux/instrumented.h:129 [inline]\n _inline_copy_to_user ../include/linux/uaccess.h:205 [inline]\n _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26\n copy_to_user ../include/linux/uaccess.h:236 [inline]\n sev_ioctl_do_pek_csr+0x31f/0x590 ../drivers/crypto/ccp/sev-dev.c:1872\n sev_ioctl+0x3a4/0x490 ../drivers/crypto/ccp/sev-dev.c:2562\n vfs_ioctl ../fs/ioctl.c:51 [inline]\n __do_sys_ioctl ../fs/ioctl.c:597 [inline]\n __se_sys_ioctl+0x11d/0x1b0 ../fs/ioctl.c:583\n do_syscall_x64 ../arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xe0/0x800 ../arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n \u0026lt;/TASK\u0026gt;\n\nWARN if the driver says the command succeeded, but the firmware error code\nsays otherwise, as __sev_do_cmd_locked() is expected to return -EIO on any\nfirwmware error.(CVE-2026-31699)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix OOB read in smb2_ioctl_query_info QUERY_INFO path\n\nsmb2_ioctl_query_info() has two response-copy branches: PASSTHRU_FSCTL\nand the default QUERY_INFO path. The QUERY_INFO branch clamps\nqi.input_buffer_length to the server-reported OutputBufferLength and then\ncopies qi.input_buffer_length bytes from qi_rsp-\u0026gt;Buffer to userspace, but\nit never verifies that the flexible-array payload actually fits within\nrsp_iov[1].iov_len.\n\nA malicious server can return OutputBufferLength larger than the actual\nQUERY_INFO response, causing copy_to_user() to walk past the response\nbuffer and expose adjacent kernel heap to userspace.\n\nGuard the QUERY_INFO copy with a bounds check on the actual Buffer\npayload. Use struct_size(qi_rsp, Buffer, qi.input_buffer_length)\nrather than an open-coded addition so the guard cannot overflow on\n32-bit builds.(CVE-2026-31708)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvxlan: validate ND option lengths in vxlan_na_create\n\nvxlan_na_create() walks ND options according to option-provided\nlengths. A malformed option can make the parser advance beyond the\ncomputed option span or use a too-short source LLADDR option payload.\n\nValidate option lengths against the remaining NS option area before\nadvancing, and only read source LLADDR when the option is large enough\nfor an Ethernet address.(CVE-2026-31738)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbridge: br_nd_send: validate ND option lengths\n\nbr_nd_send() walks ND options according to option-provided lengths.\nA malformed option can make the parser advance beyond the computed\noption span or use a too-short source LLADDR option payload.\n\nValidate option lengths against the remaining NS option area before\nadvancing, and only read source LLADDR when the option is large enough\nfor an Ethernet address.(CVE-2026-31752)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: cdns3: gadget: fix NULL pointer dereference in ep_queue\n\nWhen the gadget endpoint is disabled or not yet configured, the ep-\u0026gt;desc\npointer can be NULL. This leads to a NULL pointer dereference when\n__cdns3_gadget_ep_queue() is called, causing a kernel crash.\n\nAdd a check to return -ESHUTDOWN if ep-\u0026gt;desc is NULL, which is the\nstandard return code for unconfigured endpoints.\n\nThis prevents potential crashes when ep_queue is called on endpoints\nthat are not ready.(CVE-2026-31755)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_event: move wake reason storage into validated event handlers\n\nhci_store_wake_reason() is called from hci_event_packet() immediately\nafter stripping the HCI event header but before hci_event_func()\nenforces the per-event minimum payload length from hci_ev_table.\nThis means a short HCI event frame can reach bacpy() before any bounds\ncheck runs.\n\nRather than duplicating skb parsing and per-event length checks inside\nhci_store_wake_reason(), move wake-address storage into the individual\nevent handlers after their existing event-length validation has\nsucceeded. Convert hci_store_wake_reason() into a small helper that only\nstores an already-validated bdaddr while the caller holds hci_dev_lock().\nUse the same helper after hci_event_func() with a NULL address to\npreserve the existing unexpected-wake fallback semantics when no\nvalidated event handler records a wake address.\n\nAnnotate the helper with __must_hold(\u0026amp;hdev-\u0026gt;lock) and add\nlockdep_assert_held(\u0026amp;hdev-\u0026gt;lock) so future call paths keep the lock\ncontract explicit.\n\nCall the helper from hci_conn_request_evt(), hci_conn_complete_evt(),\nhci_sync_conn_complete_evt(), le_conn_complete_evt(),\nhci_le_adv_report_evt(), hci_le_ext_adv_report_evt(),\nhci_le_direct_adv_report_evt(), hci_le_pa_sync_established_evt(), and\nhci_le_past_received_evt().(CVE-2026-31771)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: SMP: derive legacy responder STK authentication from MITM state\n\nThe legacy responder path in smp_random() currently labels the stored\nSTK as authenticated whenever pending_sec_level is BT_SECURITY_HIGH.\nThat reflects what the local service requested, not what the pairing\nflow actually achieved.\n\nFor Just Works/Confirm legacy pairing, SMP_FLAG_MITM_AUTH stays clear\nand the resulting STK should remain unauthenticated even if the local\nside requested HIGH security. Use the established MITM state when\nstoring the responder STK so the key metadata matches the pairing result.\n\nThis also keeps the legacy path aligned with the Secure Connections code,\nwhich already treats JUST_WORKS/JUST_CFM as unauthenticated.(CVE-2026-31773)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: iwlwifi: mvm: fix potential out-of-bounds read in iwl_mvm_nd_match_info_handler()\n\nThe memcpy function assumes the dynamic array notif-\u0026gt;matches is at least\nas large as the number of bytes to copy. Otherwise, results-\u0026gt;matches may\ncontain unwanted data. To guarantee safety, extend the validation in one\nof the checks to ensure sufficient packet length.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2026-31779)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/ioc32: stop speculation on the drm_compat_ioctl path\n\nThe drm compat ioctl path takes a user controlled pointer, and then\ndereferences it into a table of function pointers, the signature method\nof spectre problems. Fix this up by calling array_index_nospec() on the\nindex to the function pointer list.(CVE-2026-31781)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: MGMT: validate LTK enc_size on load\n\nLoad Long Term Keys stores the user-provided enc_size and later uses\nit to size fixed-size stack operations when replying to LE LTK\nrequests. An enc_size larger than the 16-byte key buffer can therefore\noverflow the reply stack buffer.\n\nReject oversized enc_size values while validating the management LTK\nrecord so invalid keys never reach the stored key state.(CVE-2026-43020)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: use skb_header_pointer() for TCPv4 GSO frag_off check\n\nSyzbot reported a KMSAN uninit-value warning in gso_features_check()\ncalled from netif_skb_features() [1].\n\ngso_features_check() reads iph-\u0026gt;frag_off to decide whether to clear\nmangleid_features. Accessing the IPv4 header via ip_hdr()/inner_ip_hdr()\ncan rely on skb header offsets that are not always safe for direct\ndereference on packets injected from PF_PACKET paths.\n\nUse skb_header_pointer() for the TCPv4 frag_off check so the header read\nis robust whether data is already linear or needs copying.\n\n[1] https://syzkaller.appspot.com/bug?extid=1543a7d954d9c6d00407(CVE-2026-43036)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: ipv6: ndisc: fix ndisc_ra_useropt to initialize nduseropt_padX fields to zero to prevent an info-leak\n\nWhen processing Router Advertisements with user options the kernel\nbuilds an RTM_NEWNDUSEROPT netlink message. The nduseroptmsg struct\nhas three padding fields that are never zeroed and can leak kernel data\n\nThe fix is simple, just zeroes the padding fields.(CVE-2026-43040)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: af-alg - fix NULL pointer dereference in scatterwalk\n\nThe AF_ALG interface fails to unmark the end of a Scatter/Gather List (SGL)\nwhen chaining a new af_alg_tsgl structure. If a sendmsg() fills an SGL\nexactly to MAX_SGL_ENTS, the last entry is marked as the end. A subsequent\nsendmsg() allocates a new SGL and chains it, but fails to clear the end\nmarker on the previous SGL\u0026apos;s last data entry.\n\nThis causes the crypto scatterwalk to hit a premature end, returning NULL\non sg_next() and leading to a kernel panic during dereference.\n\nFix this by explicitly unmarking the end of the previous SGL when\nperforming sg_chain() in af_alg_alloc_tsgl().(CVE-2026-43043)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nserial: 8250: Fix TX deadlock when using DMA\n\n`dmaengine_terminate_async` does not guarantee that the\n`__dma_tx_complete` callback will run. The callback is currently the\nonly place where `dma-\u0026gt;tx_running` gets cleared. If the transaction is\ncanceled and the callback never runs, then `dma-\u0026gt;tx_running` will never\nget cleared and we will never schedule new TX DMA transactions again.\n\nThis change makes it so we clear `dma-\u0026gt;tx_running` after we terminate\nthe DMA transaction. This is \u0026quot;safe\u0026quot; because `serial8250_tx_dma_flush`\nis holding the UART port lock. The first thing the callback does is also\ngrab the UART port lock, so access to `dma-\u0026gt;tx_running` is serialized.(CVE-2026-43061)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: idxd: Fix not releasing workqueue on .release()\n\nThe workqueue associated with an DSA/IAA device is not released when\nthe object is freed.(CVE-2026-43064)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nperf/x86/intel/uncore: Skip discovery table for offline dies\n\nThis warning can be triggered if NUMA is disabled and the system\nboots with fewer CPUs than the number of CPUs in die 0.\n\nWARNING: CPU: 9 PID: 7257 at uncore.c:1157 uncore_pci_pmu_register+0x136/0x160 [intel_uncore]\n\nCurrently, the discovery table continues to be parsed even if all CPUs\nin the associated die are offline. This can lead to an array overflow\nat \u0026quot;pmu-\u0026gt;boxes[die] = box\u0026quot; in uncore_pci_pmu_register(), which may\ntrigger the warning above or cause other issues.(CVE-2026-43079)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv4: icmp: fix null-ptr-deref in icmp_build_probe()\n\nipv6_stub-\u0026gt;ipv6_dev_find() may return ERR_PTR(-EAFNOSUPPORT) when the\nIPv6 stack is not active (CONFIG_IPV6=m and not loaded), and passing\nthis error pointer to dev_hold() will cause a kernel crash with\nnull-ptr-deref.\n\nInstead, silently discard the request. RFC 8335 does not appear to\ndefine a specific response for the case where an IPv6 interface\nidentifier is syntactically valid but the implementation cannot perform\nthe lookup at runtime, and silently dropping the request may safer than\nmisreporting \u0026quot;No Such Interface\u0026quot;.(CVE-2026-43099)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/smp: Add check for kcalloc() failure in parse_thread_groups()\n\nAs kcalloc() may fail, check its return value to avoid a NULL pointer\ndereference when passing it to of_property_read_u32_array().(CVE-2026-43148)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: usb: pegasus: enable basic endpoint checking\n\npegasus_probe() fills URBs with hardcoded endpoint pipes without\nverifying the endpoint descriptors:\n\n - usb_rcvbulkpipe(dev, 1) for RX data\n - usb_sndbulkpipe(dev, 2) for TX data\n - usb_rcvintpipe(dev, 3) for status interrupts\n\nA malformed USB device can present these endpoints with transfer types\nthat differ from what the driver assumes.\n\nAdd a pegasus_usb_ep enum for endpoint numbers, replacing magic\nconstants throughout. Add usb_check_bulk_endpoints() and\nusb_check_int_endpoints() calls before any resource allocation to\nverify endpoint types before use, rejecting devices with mismatched\ndescriptors at probe time, and avoid triggering assertion.\n\nSimilar fix to\n- commit 90b7f2961798 (\u0026quot;net: usb: rtl8150: enable basic endpoint checking\u0026quot;)\n- commit 9e7021d2aeae (\u0026quot;net: usb: catc: enable basic endpoint checking\u0026quot;)(CVE-2026-43156)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmd/bitmap: fix GPF in write_page caused by resize race\n\nA General Protection Fault occurs in write_page() during array resize:\nRIP: 0010:write_page+0x22b/0x3c0 [md_mod]\n\nThis is a use-after-free race between bitmap_daemon_work() and\n__bitmap_resize(). The daemon iterates over `bitmap-\u0026gt;storage.filemap`\nwithout locking, while the resize path frees that storage via\nmd_bitmap_file_unmap(). `quiesce()` does not stop the md thread,\nallowing concurrent access to freed pages.\n\nFix by holding `mddev-\u0026gt;bitmap_info.mutex` during the bitmap update.(CVE-2026-43163)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: ioam: fix heap buffer overflow in __ioam6_fill_trace_data()\n\nOn the receive path, __ioam6_fill_trace_data() uses trace-\u0026gt;nodelen\nto decide how much data to write for each node. It trusts this field\nas-is from the incoming packet, with no consistency check against\ntrace-\u0026gt;type (the 24-bit field that tells which data items are\npresent). A crafted packet can set nodelen=0 while setting type bits\n0-21, causing the function to write ~100 bytes past the allocated\nregion (into skb_shared_info), which corrupts adjacent heap memory\nand leads to a kernel panic.\n\nAdd a shared helper ioam6_trace_compute_nodelen() in ioam6.c to\nderive the expected nodelen from the type field, and use it:\n\n - in ioam6_iptunnel.c (send path, existing validation) to replace\n the open-coded computation;\n - in exthdrs.c (receive path, ipv6_hop_ioam) to drop packets whose\n nodelen is inconsistent with the type field, before any data is\n written.\n\nPer RFC 9197, bits 12-21 are each short (4-octet) fields, so they\nare included in IOAM6_MASK_SHORT_FIELDS (changed from 0xff100000 to\n0xff1ffc00).(CVE-2026-43186)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nLoongArch: Make cpumask_of_node() robust against NUMA_NO_NODE\n\nThe arch definition of cpumask_of_node() cannot handle NUMA_NO_NODE -\nwhich is a valid index - so add a check for this.(CVE-2026-43212)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nx86/kexec: add a sanity check on previous kernel\u0026apos;s ima kexec buffer\n\nWhen the second-stage kernel is booted via kexec with a limiting command\nline such as \u0026quot;mem=\u0026lt;size\u0026gt;\u0026quot;, the physical range that contains the carried\nover IMA measurement list may fall outside the truncated RAM leading to a\nkernel panic.\n\n BUG: unable to handle page fault for address: ffff97793ff47000\n RIP: ima_restore_measurement_list+0xdc/0x45a\n #PF: error_code(0x0000) \u2013 not-present page\n\nOther architectures already validate the range with page_is_ram(), as done\nin commit cbf9c4b9617b (\u0026quot;of: check previous kernel\u0026apos;s ima-kexec-buffer\nagainst memory bounds\u0026quot;) do a similar check on x86.\n\nWithout carrying the measurement list across kexec, the attestation\nwould fail.(CVE-2026-43240)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ngfs2: fiemap page fault fix\n\nIn gfs2_fiemap(), we are calling iomap_fiemap() while holding the inode\nglock. This can lead to recursive glock taking if the fiemap buffer is\nmemory mapped to the same inode and accessing it triggers a page fault.\n\nFix by disabling page faults for iomap_fiemap() and faulting in the\nbuffer by hand if necessary.\n\nFixes xfstest generic/742.(CVE-2026-43262)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nceph: supply snapshot context in ceph_zero_partial_object()\n\nThe ceph_zero_partial_object function was missing proper snapshot\ncontext for its OSD write operations, which could lead to data\ninconsistencies in snapshots.\n\nReproducer:\n../src/vstart.sh --new -x --localhost --bluestore\n./bin/ceph auth caps client.fs_a mds \u0026apos;allow rwps fsname=a\u0026apos; mon \u0026apos;allow r fsname=a\u0026apos; osd \u0026apos;allow rw tag cephfs data=a\u0026apos;\nmount -t ceph (CVE-2026-43273)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: move ext4_percpu_param_init() before ext4_mb_init()\n\nWhen running `kvm-xfstests -c ext4/1k -C 1 generic/383` with the\n`DOUBLE_CHECK` macro defined, the following panic is triggered:\n\n==================================================================\nEXT4-fs error (device vdc): ext4_validate_block_bitmap:423:\n comm mount: bg 0: bad block bitmap checksum\nBUG: unable to handle page fault for address: ff110000fa2cc000\nPGD 3e01067 P4D 3e02067 PUD 0\nOops: Oops: 0000 [#1] SMP NOPTI\nCPU: 0 UID: 0 PID: 2386 Comm: mount Tainted: G W\n 6.18.0-gba65a4e7120a-dirty #1152 PREEMPT(none)\nRIP: 0010:percpu_counter_add_batch+0x13/0xa0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ext4_mark_group_bitmap_corrupted+0xcb/0xe0\n ext4_validate_block_bitmap+0x2a1/0x2f0\n ext4_read_block_bitmap+0x33/0x50\n mb_group_bb_bitmap_alloc+0x33/0x80\n ext4_mb_add_groupinfo+0x190/0x250\n ext4_mb_init_backend+0x87/0x290\n ext4_mb_init+0x456/0x640\n __ext4_fill_super+0x1072/0x1680\n ext4_fill_super+0xd3/0x280\n get_tree_bdev_flags+0x132/0x1d0\n vfs_get_tree+0x29/0xd0\n vfs_cmd_create+0x59/0xe0\n __do_sys_fsconfig+0x4f6/0x6b0\n do_syscall_64+0x50/0x1f0\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n==================================================================\n\nThis issue can be reproduced using the following commands:\n mkfs.ext4 -F -q -b 1024 /dev/sda 5G\n tune2fs -O quota,project /dev/sda\n mount /dev/sda /tmp/test\n\nWith DOUBLE_CHECK defined, mb_group_bb_bitmap_alloc() reads\nand validates the block bitmap. When the validation fails,\next4_mark_group_bitmap_corrupted() attempts to update\nsbi-\u0026gt;s_freeclusters_counter. However, this percpu_counter has not been\ninitialized yet at this point, which leads to the panic described above.\n\nFix this by moving the execution of ext4_percpu_param_init() to occur\nbefore ext4_mb_init(), ensuring the per-CPU counters are initialized\nbefore they are used.(CVE-2026-43288)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/vmalloc: prevent RCU stalls in kasan_release_vmalloc_node\n\nWhen CONFIG_PAGE_OWNER is enabled, freeing KASAN shadow pages during\nvmalloc cleanup triggers expensive stack unwinding that acquires RCU read\nlocks. Processing a large purge_list without rescheduling can cause the\ntask to hold CPU for extended periods (10+ seconds), leading to RCU stalls\nand potential OOM conditions.\n\nThe issue manifests in purge_vmap_node() -\u0026gt; kasan_release_vmalloc_node()\nwhere iterating through hundreds or thousands of vmap_area entries and\nfreeing their associated shadow pages causes:\n\n rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:\n rcu: Tasks blocked on level-0 rcu_node (CPUs 0-1): P6229/1:b..l\n ...\n task:kworker/0:17 state:R running task stack:28840 pid:6229\n ...\n kasan_release_vmalloc_node+0x1ba/0xad0 mm/vmalloc.c:2299\n purge_vmap_node+0x1ba/0xad0 mm/vmalloc.c:2299\n\nEach call to kasan_release_vmalloc() can free many pages, and with\npage_owner tracking, each free triggers save_stack() which performs stack\nunwinding under RCU read lock. Without yielding, this creates an\nunbounded RCU critical section.\n\nAdd periodic cond_resched() calls within the loop to allow:\n- RCU grace periods to complete\n- Other tasks to run\n- Scheduler to preempt when needed\n\nThe fix uses need_resched() for immediate response under load, with a\nbatch count of 32 as a guaranteed upper bound to prevent worst-case stalls\neven under light load.(CVE-2026-43292)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: ipa: fix event ring index not programmed for IPA v5.0+\n\nFor IPA v5.0+, the event ring index field moved from CH_C_CNTXT_0 to\nCH_C_CNTXT_1. The v5.0 register definition intended to define this\nfield in the CH_C_CNTXT_1 fmask array but used the old identifier of\nERINDEX instead of CH_ERINDEX.\n\nWithout a valid event ring, GSI channels could never signal transfer\ncompletions. This caused gsi_channel_trans_quiesce() to block\nforever in wait_for_completion().\n\nAt least for IPA v5.2 this resolves an issue seen where runtime\nsuspend, system suspend, and remoteproc stop all hanged forever. It\nalso meant the IPA data path was completely non functional.(CVE-2026-43345)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nio_uring/kbuf: check if target buffer list is still legacy on recycle\n\nThere\u0026apos;s a gap between when the buffer was grabbed and when it\npotentially gets recycled, where if the list is empty, someone could\u0026apos;ve\nupgraded it to a ring provided type. This can happen if the request\nis forced via io-wq. The legacy recycling is missing checking if the\nbuffer_list still exists, and if it\u0026apos;s of the correct type. Add those\nchecks.(CVE-2026-43366)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nlibceph: prevent potential out-of-bounds reads in process_message_header()\n\nIf the message frame is (maliciously) corrupted in a way that the\nlength of the control segment ends up being less than the size of the\nmessage header or a different frame is made to look like a message\nframe, out-of-bounds reads may ensue in process_message_header().\n\nPerform an explicit bounds check before decoding the message header.(CVE-2026-43406)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nceph: fix memory leaks in ceph_mdsc_build_path()\n\nAdd __putname() calls to error code paths that did not free the \u0026quot;path\u0026quot;\npointer obtained by __getname(). If ownership of this pointer is not\npassed to the caller via path_info.path, the function must free it\nbefore returning.(CVE-2026-43419)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: class: cdc-wdm: fix reordering issue in read code path\n\nQuoting the bug report:\n\nDue to compiler optimization or CPU out-of-order execution, the\ndesc-\u0026gt;length update can be reordered before the memmove. If this\nhappens, wdm_read() can see the new length and call copy_to_user() on\nuninitialized memory. This also violates LKMM data race rules [1].\n\nFix it by using WRITE_ONCE and memory barriers.(CVE-2026-43427)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nUSB: core: Limit the length of unkillable synchronous timeouts\n\nThe usb_control_msg(), usb_bulk_msg(), and usb_interrupt_msg() APIs in\nusbcore allow unlimited timeout durations. And since they use\nuninterruptible waits, this leaves open the possibility of hanging a\ntask for an indefinitely long time, with no way to kill it short of\nunplugging the target device.\n\nTo prevent this sort of problem, enforce a maximum limit on the length\nof these unkillable timeouts. The limit chosen here, somewhat\narbitrarily, is 60 seconds. On many systems (although not all) this\nis short enough to avoid triggering the kernel\u0026apos;s hung-task detector.\n\nIn addition, clear up the ambiguity of negative timeout values by\ntreating them the same as 0, i.e., using the maximum allowed timeout.(CVE-2026-43428)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5: Fix deadlock between devlink lock and esw-\u0026gt;wq\n\nesw-\u0026gt;work_queue executes esw_functions_changed_event_handler -\u0026gt;\nesw_vfs_changed_event_handler and acquires the devlink lock.\n\n.eswitch_mode_set (acquires devlink lock in devlink_nl_pre_doit) -\u0026gt;\nmlx5_devlink_eswitch_mode_set -\u0026gt; mlx5_eswitch_disable_locked -\u0026gt;\nmlx5_eswitch_event_handler_unregister -\u0026gt; flush_workqueue deadlocks\nwhen esw_vfs_changed_event_handler executes.\n\nFix that by no longer flushing the work to avoid the deadlock, and using\na generation counter to keep track of work relevance. This avoids an old\nhandler manipulating an esw that has undergone one or more mode changes:\n- the counter is incremented in mlx5_eswitch_event_handler_unregister.\n- the counter is read and passed to the ephemeral mlx5_host_work struct.\n- the work handler takes the devlink lock and bails out if the current\n generation is different than the one it was scheduled to operate on.\n- mlx5_eswitch_cleanup does the final draining before destroying the wq.\n\nNo longer flushing the workqueue has the side effect of maybe no longer\ncancelling pending vport_change_handler work items, but that\u0026apos;s ok since\nthose are disabled elsewhere:\n- mlx5_eswitch_disable_locked disables the vport eq notifier.\n- mlx5_esw_vport_disable disarms the HW EQ notification and marks\n vport-\u0026gt;enabled under state_lock to false to prevent pending vport\n handler from doing anything.\n- mlx5_eswitch_cleanup destroys the workqueue and makes sure all events\n are disabled/finished.(CVE-2026-43468)\n\nIn the Linux kernel, the following vulnerability has been resolved: crypto: pcrypt - Fix handling of MAY_BACKLOG requests MAY_BACKLOG requests can return EBUSY. Handle them by checking for that value and filtering out EINPROGRESS notifications. The Linux kernel CVE team has assigned CVE-2026-43493 to this issue.(CVE-2026-43493)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: skbuff: propagate shared-frag marker through frag-transfer helpers\n\nTwo frag-transfer helpers (__pskb_copy_fclone() and skb_shift()) fail\nto propagate the SKBFL_SHARED_FRAG bit in skb_shinfo()-\u0026gt;flags when\nmoving frags from source to destination. __pskb_copy_fclone() defers\nthe rest of the shinfo metadata to skb_copy_header() after copying\nfrag descriptors, but that helper only carries over gso_{size,segs,\ntype} and never touches skb_shinfo()-\u0026gt;flags; skb_shift() moves frag\ndescriptors directly and leaves flags untouched. As a result, the\ndestination skb keeps a reference to the same externally-owned or\npage-cache-backed pages while reporting skb_has_shared_frag() as\nfalse.\n\nThe mismatch is harmful in any in-place writer that uses\nskb_has_shared_frag() to decide whether shared pages must be detoured\nthrough skb_cow_data(). ESP input is one such writer (esp4.c,\nesp6.c), and a single nft \u0026apos;dup to \u0026lt;local\u0026gt;\u0026apos; rule -- or any other\nnf_dup_ipv4() / xt_TEE caller -- is enough to land a pskb_copy()\u0026apos;d\nskb in esp_input() with the marker stripped, letting an unprivileged\nuser write into the page cache of a root-owned read-only file via\nauthencesn-ESN stray writes.\n\nSet SKBFL_SHARED_FRAG on the destination whenever frag descriptors\nwere actually moved from the source. skb_copy() and skb_copy_expand()\nshare skb_copy_header() too but linearize all paged data into freshly\nallocated head storage and emerge with nr_frags == 0, so\nskb_has_shared_frag() returns false on its own; they need no change.\n\nThe same omission exists in skb_gro_receive() and skb_gro_receive_list().\nThe former moves the incoming skb\u0026apos;s frag descriptors into the\naccumulator\u0026apos;s last sub-skb via two paths (a direct frag-move loop and\nthe head_frag + memcpy path); the latter chains the incoming skb whole\nonto p\u0026apos;s frag_list. Downstream skb_segment() reads only\nskb_shinfo(p)-\u0026gt;flags, and skb_segment_list() reuses each sub-skb\u0026apos;s\nshinfo as the nskb -- both p and lp must carry the marker.\n\nThe same omission also exists in tcp_clone_payload(), which builds an\nMTU probe skb by moving frag descriptors from skbs on sk_write_queue\ninto a freshly allocated nskb. The helper falls into the same family\nand warrants the same fix for consistency; no TCP TX-side in-place\nwriter is currently known to reach a user page through this gap, but\na future consumer depending on the marker would regress silently.\n\nThe same omission exists in skb_segment(): the per-iteration flag\nmerge takes only head_skb\u0026apos;s flag, and the inner switch that rebinds\nfrag_skb to list_skb on head_skb-frags exhaustion does not fold the\nnew frag_skb\u0026apos;s flag into nskb. Fold frag_skb\u0026apos;s flag at both sites\nso segments drawing frags from frag_list members carry the marker.(CVE-2026-43503)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: L2CAP: Fix null-ptr-deref in l2cap_sock_state_change_cb()\n\nAdd the same NULL guard already present in\nl2cap_sock_resume_cb() and l2cap_sock_ready_cb().(CVE-2026-45834)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ngfs2: Fix slab-use-after-free in qd_put\n\nCommit a475c5dd16e5 (\u0026quot;gfs2: Free quota data objects synchronously\u0026quot;)\nstarted freeing quota data objects during filesystem shutdown instead of\nputting them back onto the LRU list, but it failed to remove these\nobjects from the LRU list, causing LRU list corruption. This caused\nuse-after-free when the shrinker (gfs2_qd_shrink_scan) tried to access\nalready-freed objects on the LRU list.\n\nFix this by removing qd objects from the LRU list before freeing them in\nqd_put().\n\nInitial fix from Deepanshu Kartikey \u0026lt;(CVE-2026-45861)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: cdns3: fix role switching during resume\n\nIf the role change while we are suspended, the cdns3 driver switches to the\nnew mode during resume. However, switching to host mode in this context\ncauses a NULL pointer dereference.\n\nThe host role\u0026apos;s start() operation registers a xhci-hcd device, but its\nprobe is deferred while we are in the resume path. The host role\u0026apos;s resume()\noperation assumes the xhci-hcd device is already probed, which is not the\ncase, leading to the dereference. Since the start() operation of the new\nrole is already called, the resume operation can be skipped.\n\nSo skip the resume operation for the new role if a role switch occurs\nduring resume. Once the resume sequence is complete, the xhci-hcd device\ncan be probed in case of host mode.\n\nUnable to handle kernel NULL pointer dereference at virtual address 0000000000000208\nMem abort info:\n...\nData abort info:\n...\n[0000000000000208] pgd=0000000000000000, p4d=0000000000000000\nInternal error: Oops: 0000000096000004 [#1] SMP\nModules linked in:\nCPU: 0 UID: 0 PID: 146 Comm: sh Not tainted\n6.19.0-rc7-00013-g6e64f4aabfae-dirty #135 PREEMPT\nHardware name: Texas Instruments J7200 EVM (DT)\npstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : usb_hcd_is_primary_hcd+0x0/0x1c\nlr : cdns_host_resume+0x24/0x5c\n...\nCall trace:\n usb_hcd_is_primary_hcd+0x0/0x1c (P)\n cdns_resume+0x6c/0xbc\n cdns3_controller_resume.isra.0+0xe8/0x17c\n cdns3_plat_resume+0x18/0x24\n platform_pm_resume+0x2c/0x68\n dpm_run_callback+0x90/0x248\n device_resume+0x100/0x24c\n dpm_resume+0x190/0x2ec\n dpm_resume_end+0x18/0x34\n suspend_devices_and_enter+0x2b0/0xa44\n pm_suspend+0x16c/0x5fc\n state_store+0x80/0xec\n kobj_attr_store+0x18/0x2c\n sysfs_kf_write+0x7c/0x94\n kernfs_fop_write_iter+0x130/0x1dc\n vfs_write+0x240/0x370\n ksys_write+0x70/0x108\n __arm64_sys_write+0x1c/0x28\n invoke_syscall+0x48/0x10c\n el0_svc_common.constprop.0+0x40/0xe0\n do_el0_svc+0x1c/0x28\n el0_svc+0x34/0x108\n el0t_64_sync_handler+0xa0/0xe4\n el0t_64_sync+0x198/0x19c\nCode: 52800003 f9407ca5 d63f00a0 17ffffe4 (f9410401)\n---[ end trace 0000000000000000 ]---(CVE-2026-45911)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nerofs: fix inline data read failure for ztailpacking pclusters\n\nCompressed folios for ztailpacking pclusters must be valid before adding\nthese pclusters to I/O chains. Otherwise, z_erofs_decompress_pcluster()\nmay assume they are already valid and then trigger a NULL pointer\ndereference.\n\nIt is somewhat hard to reproduce because the inline data is in the same\nblock as the tail of the compressed indexes, which are usually read just\nbefore. However, it may still happen if a fatal signal arrives while\nread_mapping_folio() is running, as shown below:\n\n erofs: (device dm-1): z_erofs_pcluster_begin: failed to get inline data -4\n Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008\n\n ...\n\n pc : z_erofs_decompress_queue+0x4c8/0xa14\n lr : z_erofs_decompress_queue+0x160/0xa14\n sp : ffffffc08b3eb3a0\n x29: ffffffc08b3eb570 x28: ffffffc08b3eb418 x27: 0000000000001000\n x26: ffffff8086ebdbb8 x25: ffffff8086ebdbb8 x24: 0000000000000001\n x23: 0000000000000008 x22: 00000000fffffffb x21: dead000000000700\n x20: 00000000000015e7 x19: ffffff808babb400 x18: ffffffc089edc098\n x17: 00000000c006287d x16: 00000000c006287d x15: 0000000000000004\n x14: ffffff80ba8f8000 x13: 0000000000000004 x12: 00000006589a77c9\n x11: 0000000000000015 x10: 0000000000000000 x9 : 0000000000000000\n x8 : 0000000000000000 x7 : 0000000000000000 x6 : 000000000000003f\n x5 : 0000000000000040 x4 : ffffffffffffffe0 x3 : 0000000000000020\n x2 : 0000000000000008 x1 : 0000000000000000 x0 : 0000000000000000\n Call trace:\n z_erofs_decompress_queue+0x4c8/0xa14\n z_erofs_runqueue+0x908/0x97c\n z_erofs_read_folio+0x128/0x228\n filemap_read_folio+0x68/0x128\n filemap_get_pages+0x44c/0x8b4\n filemap_read+0x12c/0x5b8\n generic_file_read_iter+0x4c/0x15c\n do_iter_readv_writev+0x188/0x1e0\n vfs_iter_read+0xac/0x1a4\n backing_file_read_iter+0x170/0x34c\n ovl_read_iter+0xf0/0x140\n vfs_read+0x28c/0x344\n ksys_read+0x80/0xf0\n __arm64_sys_read+0x24/0x34\n invoke_syscall+0x60/0x114\n el0_svc_common+0x88/0xe4\n do_el0_svc+0x24/0x30\n el0_svc+0x40/0xa8\n el0t_64_sync_handler+0x70/0xbc\n el0t_64_sync+0x1bc/0x1c0\n\nFix this by reading the inline data before allocating and adding\nthe pclusters to the I/O chains.(CVE-2026-45943)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu: Fix memory leak in amdgpu_acpi_enumerate_xcc()\n\nIn amdgpu_acpi_enumerate_xcc(), if amdgpu_acpi_dev_init() returns -ENOMEM,\nthe function returns directly without releasing the allocated xcc_info,\nresulting in a memory leak.\n\nFix this by ensuring that xcc_info is properly freed in the error paths.\n\nCompile tested only. Issue found using a prototype static analysis tool\nand code review.(CVE-2026-45947)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ngfs2: fix memory leaks in gfs2_fill_super error path\n\nFix two memory leaks in the gfs2_fill_super() error handling path when\ntransitioning a filesystem to read-write mode fails.\n\nFirst leak: kthread objects (thread_struct, task_struct, etc.)\nWhen gfs2_freeze_lock_shared() fails after init_threads() succeeds, the\ncreated kernel threads (logd and quotad) are never destroyed. This\noccurs because the fail_per_node label doesn\u0026apos;t call\ngfs2_destroy_threads().\n\nSecond leak: quota bitmap buffer (8192 bytes)\nWhen gfs2_make_fs_rw() fails after gfs2_quota_init() succeeds but\nbefore other operations complete, the allocated quota bitmap is never\nfreed.\n\nThe fix moves thread cleanup to the fail_per_node label to handle all\nerror paths uniformly. gfs2_destroy_threads() is safe to call\nunconditionally as it checks for NULL pointers. Quota cleanup is added\nin gfs2_make_fs_rw() to properly handle the withdrawal case where\nquota initialization succeeds but the filesystem is then withdrawn.\n\nThread leak backtrace (gfs2_freeze_lock_shared failure):\n unreferenced object 0xffff88801d7bca80 (size 4480):\n copy_process+0x3a1/0x4670 kernel/fork.c:2422\n kernel_clone+0xf3/0x6e0 kernel/fork.c:2779\n kthread_create_on_node+0x100/0x150 kernel/kthread.c:478\n init_threads+0xab/0x350 fs/gfs2/ops_fstype.c:611\n gfs2_fill_super+0xe5c/0x1240 fs/gfs2/ops_fstype.c:1265\n\nQuota leak backtrace (gfs2_make_fs_rw failure):\n unreferenced object 0xffff88812de7c000 (size 8192):\n gfs2_quota_init+0xe5/0x820 fs/gfs2/quota.c:1409\n gfs2_make_fs_rw+0x7a/0xe0 fs/gfs2/super.c:149\n gfs2_fill_super+0xfbb/0x1240 fs/gfs2/ops_fstype.c:1275(CVE-2026-45961)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nACPICA: Fix NULL pointer dereference in acpi_ev_address_space_dispatch()\n\nCover a missed execution path with a new check.(CVE-2026-45982)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nerofs: fix unsigned underflow in z_erofs_lz4_handle_overlap()\n\nSome crafted images can have illegal (!partial_decoding \u0026amp;\u0026amp;\nm_llen \u0026lt; m_plen) extents, and the LZ4 inplace decompression path\ncan be wrongly hit, but it cannot handle (outpages \u0026lt; inpages)\nproperly: \u0026quot;outpages - inpages\u0026quot; wraps to a large value and\nthe subsequent rq-\u0026gt;out[] access reads past the decompressed_pages\narray.\n\nHowever, such crafted cases can correctly result in a corruption\nreport in the normal LZ4 non-inplace path.\n\nLet\u0026apos;s add an additional check to fix this for backporting.\n\nReproducible image (base64-encoded gzipped blob):\n\nH4sIAJGR12kCA+3SPUoDQRgG4MkmkkZk8QRbRFIIi9hbpEjrHQI5ghfwCN5BLCzTGtLbBI+g\ndilSJo1CnIm7GEXFxhT6PDDwfrs73/ywIQD/1ePD4r7Ou6ETsrq4mu7XcWfj++Pb58nJU/9i\nPNtbjhan04/9GtX4qVYc814WDqt6FaX5s+ZwXXeq52lndT6IuVvlblytLMvh4Gzwaf90nsvz\n2DF/21+20T/ldgp5s1jXRaN4t/8izsy/OUB6e/Qa79r+JwAAAAAAAL52vQVuGQAAAP6+my1w\nywAAAAAAAADwu14ATsEYtgBQAAA=\n\n$ mount -t erofs -o cache_strategy=disabled foo.erofs /mnt\n$ dd if=/mnt/data of=/dev/null bs=4096 count=1(CVE-2026-45999)\n\nIn the Linux kernel, the following vulnerability has been resolved: ipmi:ssif: Clean up kthread on errors If an error occurs after the ssif kthread is created, but before the main IPMI code starts the ssif interface, the ssif kthread will not be stopped. So make sure the kthread is stopped on an error condition if it is running. The Linux kernel CVE team has assigned CVE-2026-46044 to this issue.(CVE-2026-46044)\n\nIn the Linux kernel, the following vulnerability has been resolved: md/raid5: fix soft lockup in retry_aligned_read() When retry_aligned_read() encounters an overlapped stripe, it releases the stripe via raid5_release_stripe() which puts it on the lockless released_stripes llist. In the next raid5d loop iteration, release_stripe_list() drains the stripe onto handle_list (since STRIPE_HANDLE is set by the original IO), but retry_aligned_read() runs before handle_active_stripes() and removes the stripe from handle_list via find_get_stripe() -\u0026gt; list_del_init(). This prevents handle_stripe() from ever processing the stripe to resolve the overlap, causing an infinite loop and soft lockup. Fix this by using __release_stripe() with temp_inactive_list instead of raid5_release_stripe() in the failure path, so the stripe does not go through the released_stripes llist. This allows raid5d to break out of its loop, and the overlap will be resolved when the stripe is eventually processed by handle_stripe(). The Linux kernel CVE team has assigned CVE-2026-46051 to this issue.(CVE-2026-46051)\n\nIn the Linux kernel, the following vulnerability has been resolved: KVM: nSVM: Raise #UD if unhandled VMMCALL isn\u0026apos;t intercepted by L1 Explicitly synthesize a #UD for VMMCALL if L2 is active, L1 does NOT want to intercept VMMCALL, nested_svm_l2_tlb_flush_enabled() is true, and the hypercall is something other than one of the supported Hyper-V hypercalls. When all of the above conditions are met, KVM will intercept VMMCALL but never forward it to L1, i.e. will let L2 make hypercalls as if it were L1. The TLFS says a whole lot of nothing about this scenario, so go with the architectural behavior, which says that VMMCALL #UDs if it\u0026apos;s not intercepted. Opportunistically do a 2-for-1 stub trade by stub-ifying the new API instead of the helpers it uses. The last remaining \u0026quot;single\u0026quot; stub will soon be dropped as well. [sean: rewrite changelog and comment, tag for stable, remove defunct stubs] The Linux kernel CVE team has assigned CVE-2026-46076 to this issue.(CVE-2026-46076)\n\nIn the Linux kernel, the following vulnerability has been resolved: erofs: fix the out-of-bounds nameoff handling for trailing dirents Currently we already have boundary-checks for nameoffs, but the trailing dirents are special since the namelens are calculated with strnlen() with unchecked nameoffs. If a crafted EROFS has a trailing dirent with nameoff \u0026gt;= maxsize, maxsize - nameoff can underflow, causing strnlen() to read past the directory block. nameoff0 should also be verified to be a multiple of `sizeof(struct erofs_dirent)` as well [1]. [1] https://sashiko.dev/#/patchset/20260416063511.3173774-1-hsiangkao%40linux.alibaba.com The Linux kernel CVE team has assigned CVE-2026-46078 to this issue.(CVE-2026-46078)\n\nIn the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Inject #UD for INVLPGA if EFER.SVME=0 INVLPGA should cause a #UD when EFER.SVME is not set. Add a check to properly inject #UD when EFER.SVME=0. [sean: tag for stable@] The Linux kernel CVE team has assigned CVE-2026-46082 to this issue.(CVE-2026-46082)\n\nIn the Linux kernel, the following vulnerability has been resolved: mm/vmalloc: take vmap_purge_lock in shrinker decay_va_pool_node() can be invoked concurrently from two paths: __purge_vmap_area_lazy() when pools are being purged, and the shrinker via vmap_node_shrink_scan(). However, decay_va_pool_node() is not safe to run concurrently, and the shrinker path currently lacks serialization, leading to races and possible leaks. Protect decay_va_pool_node() by taking vmap_purge_lock in the shrinker path to ensure serialization with purge users. The Linux kernel CVE team has assigned CVE-2026-46093 to this issue.(CVE-2026-46093)\n\nIn the Linux kernel, the following vulnerability has been resolved:mm/damon/sysfs-schemes: protect memcg_path kfree() with damon_sysfs_lockPatch series \u0026quot;mm/damon/sysfs-schemes: fix use-after-free for [memcg_]path\u0026quot;.Reads of \u0026apos;memcg_path\u0026apos; and \u0026apos;path\u0026apos; files in DAMON sysfs interface could racewith their writes, results in use-after-free. Fix those.This patch (of 2):damon_sysfs_scheme_filter-\u0026gt;mmecg_path can be read and written by users,via DAMON sysfs memcg_path file. It can also be indirectly read, for theparameters {on,off}line committing to DAMON. The reads for parameterscommitting are protected by damon_sysfs_lock to avoid the sysfs filesbeing destroyed while any of the parameters are being read. But theuser-driven direct reads and writes are not protected by any lock, whilethe write is deallocating the memcg_path-pointing buffer. As a result,the readers could read the already freed buffer (user-after-free). Notethat the user-reads don\u0026apos;t race when the same open file is used by thewriter, due to kernfs\u0026apos;s open file locking. Nonetheless, doing the readsand writes with separate open files would be common. Fix it by protectingboth the user-direct reads and writes with damon_sysfs_lock.(CVE-2026-46121)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_event: Fix OOB read and infinite loop in hci_le_create_big_complete_evt\n\nhci_le_create_big_complete_evt() iterates over BT_BOUND connections for\na BIG handle using a while loop, accessing ev-\u0026gt;bis_handle[i++] on each\niteration. However, there is no check that i stays within ev-\u0026gt;num_bis\nbefore the array access.\n\nWhen a controller sends a LE_Create_BIG_Complete event with fewer\nbis_handle entries than there are BT_BOUND connections for that BIG,\nor with num_bis=0, the loop reads beyond the valid bis_handle[] flex\narray into adjacent heap memory. Since the out-of-bounds values\ntypically exceed HCI_CONN_HANDLE_MAX (0x0EFF), hci_conn_set_handle()\nrejects them and the connection remains in BT_BOUND state. The same\nconnection is then found again by hci_conn_hash_lookup_big_state(),\ncreating an infinite loop with hci_dev_lock held.\n\nFix this by terminating the BIG if in case not all BIS could be setup\nproperly.(CVE-2026-46138)\n\nIn the Linux kernel, vports are used concurrently and protected by RCU, so netdev_put() must happen after the RCU grace period. The rtnl_delete_link() must happen under RTNL and cannot be executed in RCU context. Calling synchronize_net() while holding RTNL is not good for performance and system stability, so calling netdev_put() in RCU call is the right solution. However, when the device is deleted, rtnl_unlock() calls netdev_run_todo() and blocks until all references are gone. In the current code, this means that call_rcu() is never reached, the vport is never freed, and the reference is never released, causing a self-deadlock on device removal. The fix moves the rcu_call() before rtnl_unlock(), so the scheduled RCU callback will be executed when synchronize_net() is called from rtnl_unlock()-\u0026gt;netdev_run_todo() while RTNL itself is already released.(CVE-2026-46165)\n\nIn the Linux kernel\u0026apos;s RISC-V KVM subsystem, when the second kzalloc (host_context.vector.datap) fails in kvm_riscv_vcpu_alloc_vector_context, the first allocation (guest_context.vector.datap) is not freed, causing a memory leak. An attacker can trigger this via ioctl(vm_fd, KVM_CREATE_VCPU), potentially leading to resource exhaustion.(CVE-2026-46171)\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 spi_nor_params_show() function uses sizeof(snor_f_names) to calculate the array length. Since snor_f_names is an array of pointers, sizeof returns the total byte size of the pointer array (element_count sizeof(void )), which on 64-bit systems is 8 times larger than intended. This causes an out-of-bounds read when a flag bit is set that exceeds the actual element count but falls within the inflated byte-size count. The fix replaces sizeof with ARRAY_SIZE to pass the actual number of elements.(CVE-2026-46190)",
"id": "OESA-2026-2582",
"modified": "2026-08-06T11:11:31Z",
"published": "2026-06-05T11:11:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-2582"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39833"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68334"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68340"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68801"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71068"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71087"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71130"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71152"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71194"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23001"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23011"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23025"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23054"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23074"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23100"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23138"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23247"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23269"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23272"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23312"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23340"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23378"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23389"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23406"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23407"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23410"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23411"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23439"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23440"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23441"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23444"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23448"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23450"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23452"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23461"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23473"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23475"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31392"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31398"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31399"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31400"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31403"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31408"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31421"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31422"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31426"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31429"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31430"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31441"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31442"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31446"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31449"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31450"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31451"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31452"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31467"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31469"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31487"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31495"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31496"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31498"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31499"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31505"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31510"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31511"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31512"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31516"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31518"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31525"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31528"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31531"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31532"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31533"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31540"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31542"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31546"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31555"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31566"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31570"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31590"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31595"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31628"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31630"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31651"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31665"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31667"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31675"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31677"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31678"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31684"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31685"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31689"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31697"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31698"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31699"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31708"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31738"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31752"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31755"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31771"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31773"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31779"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31781"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43020"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43036"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43040"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43043"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43061"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43064"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43079"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43099"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43148"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43156"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43163"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43186"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43212"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43240"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43262"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43273"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43288"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43292"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43345"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43366"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43406"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43419"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43427"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43428"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43468"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43493"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43503"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45834"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45861"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45911"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45943"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45947"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45961"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45982"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45999"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46044"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46051"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46076"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46078"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46082"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46093"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46121"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46138"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46165"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46171"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46178"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46190"
}
],
"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-39833",
"CVE-2025-68334",
"CVE-2025-68340",
"CVE-2025-68801",
"CVE-2025-71068",
"CVE-2025-71087",
"CVE-2025-71130",
"CVE-2025-71152",
"CVE-2025-71194",
"CVE-2026-23001",
"CVE-2026-23011",
"CVE-2026-23025",
"CVE-2026-23054",
"CVE-2026-23074",
"CVE-2026-23100",
"CVE-2026-23138",
"CVE-2026-23247",
"CVE-2026-23269",
"CVE-2026-23272",
"CVE-2026-23312",
"CVE-2026-23340",
"CVE-2026-23378",
"CVE-2026-23389",
"CVE-2026-23406",
"CVE-2026-23407",
"CVE-2026-23410",
"CVE-2026-23411",
"CVE-2026-23439",
"CVE-2026-23440",
"CVE-2026-23441",
"CVE-2026-23444",
"CVE-2026-23448",
"CVE-2026-23450",
"CVE-2026-23452",
"CVE-2026-23461",
"CVE-2026-23473",
"CVE-2026-23475",
"CVE-2026-31392",
"CVE-2026-31398",
"CVE-2026-31399",
"CVE-2026-31400",
"CVE-2026-31403",
"CVE-2026-31408",
"CVE-2026-31421",
"CVE-2026-31422",
"CVE-2026-31426",
"CVE-2026-31429",
"CVE-2026-31430",
"CVE-2026-31441",
"CVE-2026-31442",
"CVE-2026-31446",
"CVE-2026-31449",
"CVE-2026-31450",
"CVE-2026-31451",
"CVE-2026-31452",
"CVE-2026-31467",
"CVE-2026-31469",
"CVE-2026-31487",
"CVE-2026-31495",
"CVE-2026-31496",
"CVE-2026-31498",
"CVE-2026-31499",
"CVE-2026-31505",
"CVE-2026-31510",
"CVE-2026-31511",
"CVE-2026-31512",
"CVE-2026-31516",
"CVE-2026-31518",
"CVE-2026-31525",
"CVE-2026-31528",
"CVE-2026-31531",
"CVE-2026-31532",
"CVE-2026-31533",
"CVE-2026-31540",
"CVE-2026-31542",
"CVE-2026-31546",
"CVE-2026-31555",
"CVE-2026-31566",
"CVE-2026-31570",
"CVE-2026-31590",
"CVE-2026-31595",
"CVE-2026-31628",
"CVE-2026-31630",
"CVE-2026-31651",
"CVE-2026-31665",
"CVE-2026-31667",
"CVE-2026-31675",
"CVE-2026-31677",
"CVE-2026-31678",
"CVE-2026-31684",
"CVE-2026-31685",
"CVE-2026-31689",
"CVE-2026-31697",
"CVE-2026-31698",
"CVE-2026-31699",
"CVE-2026-31708",
"CVE-2026-31738",
"CVE-2026-31752",
"CVE-2026-31755",
"CVE-2026-31771",
"CVE-2026-31773",
"CVE-2026-31779",
"CVE-2026-31781",
"CVE-2026-43020",
"CVE-2026-43036",
"CVE-2026-43040",
"CVE-2026-43043",
"CVE-2026-43061",
"CVE-2026-43064",
"CVE-2026-43079",
"CVE-2026-43099",
"CVE-2026-43148",
"CVE-2026-43156",
"CVE-2026-43163",
"CVE-2026-43186",
"CVE-2026-43212",
"CVE-2026-43240",
"CVE-2026-43262",
"CVE-2026-43273",
"CVE-2026-43288",
"CVE-2026-43292",
"CVE-2026-43345",
"CVE-2026-43366",
"CVE-2026-43406",
"CVE-2026-43419",
"CVE-2026-43427",
"CVE-2026-43428",
"CVE-2026-43468",
"CVE-2026-43493",
"CVE-2026-43503",
"CVE-2026-45834",
"CVE-2026-45861",
"CVE-2026-45911",
"CVE-2026-45943",
"CVE-2026-45947",
"CVE-2026-45961",
"CVE-2026-45982",
"CVE-2026-45999",
"CVE-2026-46044",
"CVE-2026-46051",
"CVE-2026-46076",
"CVE-2026-46078",
"CVE-2026-46082",
"CVE-2026-46093",
"CVE-2026-46121",
"CVE-2026-46138",
"CVE-2026-46165",
"CVE-2026-46171",
"CVE-2026-46178",
"CVE-2026-46190"
]
}
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-3157 (CVE-2025-10263)
Vulnerability from osv_openeuler – Published: 2026-07-24 11:12 – Updated: 2026-08-06 11:12 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
Arm C1-Ultra, C1-Premium, Neoverse V3 & V3AE, Neoverse V2, Neoverse V1, Neoverse-N2, Neoverse-N1, Cortex-X925, Cortex-X4, Cortex-X3, Cortex-X2, Cortex-X1 & X1C, Cortex-A710, Cortex-A78, A78AE & A78C, Cortex-A77, Cortex-A76 & A76A may allow writes to resources owned by a higher exception level.(CVE-2025-10263)
In the Linux kernel, the following vulnerability has been resolved:
smb: client: let smbd_destroy() call disable_work_sync(&info->post_send_credits_work)
In smbd_destroy() we may destroy the memory so we better wait until post_send_credits_work is no longer pending and will never be started again.
I actually just hit the case using rxe:
WARNING: CPU: 0 PID: 138 at drivers/infiniband/sw/rxe/rxe_verbs.c:1032 rxe_post_recv+0x1ee/0x480 [rdma_rxe] ... [ 5305.686979] [ T138] smbd_post_recv+0x445/0xc10 [cifs] [ 5305.687135] [ T138] ? srso_alias_return_thunk+0x5/0xfbef5 [ 5305.687149] [ T138] ? __kasan_check_write+0x14/0x30 [ 5305.687185] [ T138] ? __pfx_smbd_post_recv+0x10/0x10 [cifs] [ 5305.687329] [ T138] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 5305.687356] [ T138] ? srso_alias_return_thunk+0x5/0xfbef5 [ 5305.687368] [ T138] ? srso_alias_return_thunk+0x5/0xfbef5 [ 5305.687378] [ T138] ? _raw_spin_unlock_irqrestore+0x11/0x60 [ 5305.687389] [ T138] ? srso_alias_return_thunk+0x5/0xfbef5 [ 5305.687399] [ T138] ? get_receive_buffer+0x168/0x210 [cifs] [ 5305.687555] [ T138] smbd_post_send_credits+0x382/0x4b0 [cifs] [ 5305.687701] [ T138] ? __pfx_smbd_post_send_credits+0x10/0x10 [cifs] [ 5305.687855] [ T138] ? __pfxschedule+0x10/0x10 [ 5305.687865] [ T138] ? _pfxraw_spin_lock_irq+0x10/0x10 [ 5305.687875] [ T138] ? queue_delayed_work_on+0x8e/0xa0 [ 5305.687889] [ T138] process_one_work+0x629/0xf80 [ 5305.687908] [ T138] ? srso_alias_return_thunk+0x5/0xfbef5 [ 5305.687917] [ T138] ? __kasan_check_write+0x14/0x30 [ 5305.687933] [ T138] worker_thread+0x87f/0x1570 ...
It means rxe_post_recv was called after rdma_destroy_qp(). This happened because put_receive_buffer() was triggered by ib_drain_qp() and called: queue_work(info->workqueue, &info->post_send_credits_work);(CVE-2025-39932)
In the Linux kernel, the following vulnerability has been resolved:
MIPS: ftrace: Fix memory corruption when kernel is located beyond 32 bits
Since commit e424054000878 ("MIPS: Tracing: Reduce the overhead of dynamic Function Tracer"), the macro UASM_i_LA_mostly has been used, and this macro can generate more than 2 instructions. At the same time, the code in ftrace assumes that no more than 2 instructions can be generated, which is why it stores them in an int[2] array. However, as previously noted, the macro UASM_i_LA_mostly (and now UASM_i_LA) causes a buffer overflow when _mcount is beyond 32 bits. This leads to corruption of the variables located in the __read_mostly section.
This corruption was observed because the variable __cpu_primary_thread_mask was corrupted, causing a hang very early during boot.
This fix prevents the corruption by avoiding the generation of instructions if they could exceed 2 instructions in length. Fortunately, insn_la_mcount is only used if the instrumented code is located outside the kernel code section, so dynamic ftrace can still be used, albeit in a more limited scope. This is still preferable to corrupting memory and/or crashing the kernel.(CVE-2025-71109)
In the Linux kernel, the following vulnerability has been resolved:
riscv: Sanitize syscall table indexing under speculation
The syscall number is a user-controlled value used to index into the syscall table. Use array_index_nospec() to clamp this value after the bounds check to prevent speculative out-of-bounds access and subsequent data leakage via cache side channels.(CVE-2025-71203)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/pm: Disable MMIO access during SMU Mode 1 reset
During Mode 1 reset, the ASIC undergoes a reset cycle and becomes temporarily inaccessible via PCIe. Any attempt to access MMIO registers during this window (e.g., from interrupt handlers or other driver threads) can result in uncompleted PCIe transactions, leading to NMI panics or system hangs.
To prevent this, set the no_hw_access flag to true immediately after
triggering the reset. This signals other driver components to skip
register accesses while the device is offline.
A memory barrier smp_mb() is added to ensure the flag update is
globally visible to all cores before the driver enters the sleep/wait
state.
(cherry picked from commit 7edb503fe4b6d67f47d8bb0dfafb8e699bb0f8a4)(CVE-2026-23213)
In the Linux kernel, the following vulnerability has been resolved:
btrfs: reject new transactions if the fs is fully read-only
[BUG] There is a bug report where a heavily fuzzed fs is mounted with all rescue mount options, which leads to the following warnings during unmount:
BTRFS: Transaction aborted (error -22) Modules linked in: CPU: 0 UID: 0 PID: 9758 Comm: repro.out Not tainted 6.19.0-rc5-00002-gb71e635feefc #7 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:find_free_extent_update_loop fs/btrfs/extent-tree.c:4208 [inline] RIP: 0010:find_free_extent+0x52f0/0x5d20 fs/btrfs/extent-tree.c:4611 Call Trace: <TASK> btrfs_reserve_extent+0x2cd/0x790 fs/btrfs/extent-tree.c:4705 btrfs_alloc_tree_block+0x1e1/0x10e0 fs/btrfs/extent-tree.c:5157 btrfs_force_cow_block+0x578/0x2410 fs/btrfs/ctree.c:517 btrfs_cow_block+0x3c4/0xa80 fs/btrfs/ctree.c:708 btrfs_search_slot+0xcad/0x2b50 fs/btrfs/ctree.c:2130 btrfs_truncate_inode_items+0x45d/0x2350 fs/btrfs/inode-item.c:499 btrfs_evict_inode+0x923/0xe70 fs/btrfs/inode.c:5628 evict+0x5f4/0xae0 fs/inode.c:837 __dentry_kill+0x209/0x660 fs/dcache.c:670 finish_dput+0xc9/0x480 fs/dcache.c:879 shrink_dcache_for_umount+0xa0/0x170 fs/dcache.c:1661 generic_shutdown_super+0x67/0x2c0 fs/super.c:621 kill_anon_super+0x3b/0x70 fs/super.c:1289 btrfs_kill_super+0x41/0x50 fs/btrfs/super.c:2127 deactivate_locked_super+0xbc/0x130 fs/super.c:474 cleanup_mnt+0x425/0x4c0 fs/namespace.c:1318 task_work_run+0x1d4/0x260 kernel/task_work.c:233 exit_task_work include/linux/task_work.h:40 [inline] do_exit+0x694/0x22f0 kernel/exit.c:971 do_group_exit+0x21c/0x2d0 kernel/exit.c:1112 __do_sys_exit_group kernel/exit.c:1123 [inline] __se_sys_exit_group kernel/exit.c:1121 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1121 x64_sys_call+0x2210/0x2210 arch/x86/include/generated/asm/syscalls_64.h:232 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xe8/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x44f639 Code: Unable to access opcode bytes at 0x44f60f. RSP: 002b:00007ffc15c4e088 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 00000000004c32f0 RCX: 000000000044f639 RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000001 RBP: 0000000000000001 R08: ffffffffffffffc0 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00000000004c32f0 R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000001 </TASK>
Since rescue mount options will mark the full fs read-only, there should be no new transaction triggered.
But during unmount we will evict all inodes, which can trigger a new transaction, and triggers warnings on a heavily corrupted fs.
[CAUSE] Btrfs allows new transaction even on a read-only fs, this is to allow log replay happen even on read-only mounts, just like what ext4/xfs do.
However with rescue mount options, the fs is fully read-only and cannot be remounted read-write, thus in that case we should also reject any new transactions.
[FIX] If we find the fs has rescue mount options, we should treat the fs as error, so that no new transaction can be started.(CVE-2026-23214)
In the Linux kernel, the following vulnerability has been resolved:
nvme-fc: release admin tagset if init fails
nvme_fabrics creates an NVMe/FC controller in following path:
nvmf_dev_write()
-> nvmf_create_ctrl()
-> nvme_fc_create_ctrl()
-> nvme_fc_init_ctrl()
nvme_fc_init_ctrl() allocates the admin blk-mq resources right after nvme_add_ctrl() succeeds. If any of the subsequent steps fail (changing the controller state, scheduling connect work, etc.), we jump to the fail_ctrl path, which tears down the controller references but never frees the admin queue/tag set. The leaked blk-mq allocations match the kmemleak report seen during blktests nvme/fc.
Check ctrl->ctrl.admin_tagset in the fail_ctrl path and call nvme_remove_admin_tag_set() when it is set so that all admin queue allocations are reclaimed whenever controller setup aborts.(CVE-2026-23261)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_conntrack_expect: use expect->helper
Use expect->helper in ctnetlink and /proc to dump the helper name. Using nfct_help() without holding a reference to the master conntrack is unsafe.
Use exp->master->helper in ctnetlink path if userspace does not provide an explicit helper when creating an expectation to retain the existing behaviour. The ctnetlink expectation path holds the reference on the master conntrack and nf_conntrack_expect lock and the nfnetlink glue path refers to the master ct that is attached to the skb.(CVE-2026-31414)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix OOB write in QUERY_INFO for compound requests
When a compound request such as READ + QUERY_INFO(Security) is received, and the first command (READ) consumes most of the response buffer, ksmbd could write beyond the allocated buffer while building a security descriptor.
The root cause was that smb2_get_info_sec() checked buffer space using ppntsd_size from xattr, while build_sec_desc() often synthesized a significantly larger descriptor from POSIX ACLs.
This patch introduces smb_acl_sec_desc_scratch_len() to accurately compute the final descriptor size beforehand, performs proper buffer checking with smb2_calc_max_out_buf_len(), and uses exact-sized allocation + iov pinning.(CVE-2026-31432)
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: idxd: Fix leaking event log memory
During the device remove process, the device is reset, causing the configuration registers to go back to their default state, which is zero. As the driver is checking if the event log support was enabled before deallocating, it will fail if a reset happened before.
Do not check if the support was enabled, the check for 'idxd->evl' being valid (only allocated if the HW capability is available) is enough.(CVE-2026-31440)
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: idxd: Fix crash when the event log is disabled
If reporting errors to the event log is not supported by the hardware, and an error that causes Function Level Reset (FLR) is received, the driver will try to restore the event log even if it was not allocated.
Also, only try to free the event log if it was properly allocated.(CVE-2026-31443)
In the Linux kernel, the following vulnerability has been resolved:
xfs: avoid dereferencing log items after push callbacks
After xfsaild_push_item() calls iop_push(), the log item may have been freed if the AIL lock was dropped during the push. Background inode reclaim or the dquot shrinker can free the log item while the AIL lock is not held, and the tracepoints in the switch statement dereference the log item after iop_push() returns.
Fix this by capturing the log item type, flags, and LSN before calling xfsaild_push_item(), and introducing a new xfs_ail_push_class trace event class that takes these pre-captured values and the ailp pointer instead of the log item pointer.(CVE-2026-31453)
In the Linux kernel, the following vulnerability has been resolved:
ipv4: nexthop: allocate skb dynamically in rtm_get_nexthop()
When querying a nexthop object via RTM_GETNEXTHOP, the kernel currently allocates a fixed-size skb using NLMSG_GOODSIZE. While sufficient for single nexthops and small Equal-Cost Multi-Path groups, this fixed allocation fails for large nexthop groups like 512 nexthops.
This results in the following warning splat:
WARNING: net/ipv4/nexthop.c:3395 at rtm_get_nexthop+0x176/0x1c0, CPU#20: rep/4608 [...] RIP: 0010:rtm_get_nexthop (net/ipv4/nexthop.c:3395) [...] Call Trace: <TASK> rtnetlink_rcv_msg (net/core/rtnetlink.c:6989) netlink_rcv_skb (net/netlink/af_netlink.c:2550) netlink_unicast (net/netlink/af_netlink.c:1319 net/netlink/af_netlink.c:1344) netlink_sendmsg (net/netlink/af_netlink.c:1894) _syssendmsg (net/socket.c:721 net/socket.c:736 net/socket.c:2585) _sys_sendmsg (net/socket.c:2641) __sys_sendmsg (net/socket.c:2671) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) </TASK>
Fix this by allocating the size dynamically using nh_nlmsg_size() and using nlmsg_new(), this is consistent with nexthop_notify() behavior. In addition, adjust nh_nlmsg_size_grp() so it calculates the size needed based on flags passed. While at it, also add the size of NHA_FDB for nexthop group size calculation as it was missing too.
This cannot be reproduced via iproute2 as the group size is currently limited and the command fails as follows:
addattr_l ERROR: message exceeded bound of 1048(CVE-2026-31531)
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: Fix static_branch_dec() underflow for aql_disable.
syzbot reported static_branch_dec() underflow in aql_enable_write(). [0]
The problem is that aql_enable_write() does not serialise concurrent write()s to the debugfs.
aql_enable_write() checks static_key_false(&aql_disable.key) and later calls static_branch_inc() or static_branch_dec(), but the state may change between the two calls.
aql_disable does not need to track inc/dec.
Let's use static_branch_enable() and static_branch_disable().
[0]: val == 0 WARNING: kernel/jump_label.c:311 at __static_key_slow_dec_cpuslocked.part.0+0x107/0x120 kernel/jump_label.c:311, CPU#0: syz.1.3155/20288 Modules linked in: CPU: 0 UID: 0 PID: 20288 Comm: syz.1.3155 Tainted: G U L syzkaller #0 PREEMPT(full) Tainted: [U]=USER, [L]=SOFTLOCKUP Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/24/2026 RIP: 0010:__static_key_slow_dec_cpuslocked.part.0+0x107/0x120 kernel/jump_label.c:311 Code: f2 c9 ff 5b 5d c3 cc cc cc cc e8 54 f2 c9 ff 48 89 df e8 ac f9 ff ff eb ad e8 45 f2 c9 ff 90 0f 0b 90 eb a2 e8 3a f2 c9 ff 90 <0f> 0b 90 eb 97 48 89 df e8 5c 4b 33 00 e9 36 ff ff ff 0f 1f 80 00 RSP: 0018:ffffc9000b9f7c10 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffffffff9b3e5d40 RCX: ffffffff823c57b4 RDX: ffff8880285a0000 RSI: ffffffff823c5846 RDI: ffff8880285a0000 RBP: 0000000000000000 R08: 0000000000000005 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 000000000000000a R13: 1ffff9200173ef88 R14: 0000000000000001 R15: ffffc9000b9f7e98 FS: 00007f530dd726c0(0000) GS:ffff8881245e3000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000200000001140 CR3: 000000007cc4a000 CR4: 00000000003526f0 Call Trace: <TASK> __static_key_slow_dec_cpuslocked kernel/jump_label.c:297 [inline] __static_key_slow_dec kernel/jump_label.c:321 [inline] static_key_slow_dec+0x7c/0xc0 kernel/jump_label.c:336 aql_enable_write+0x2b2/0x310 net/mac80211/debugfs.c:343 short_proxy_write+0x133/0x1a0 fs/debugfs/file.c:383 vfs_write+0x2aa/0x1070 fs/read_write.c:684 ksys_pwrite64 fs/read_write.c:793 [inline] __do_sys_pwrite64 fs/read_write.c:801 [inline] __se_sys_pwrite64 fs/read_write.c:798 [inline] __x64_sys_pwrite64+0x1eb/0x250 fs/read_write.c:798 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xc9/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f530cf9aeb9 Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f530dd72028 EFLAGS: 00000246 ORIG_RAX: 0000000000000012 RAX: ffffffffffffffda RBX: 00007f530d215fa0 RCX: 00007f530cf9aeb9 RDX: 0000000000000003 RSI: 0000000000000000 RDI: 0000000000000010 RBP: 00007f530d008c1f R08: 0000000000000000 R09: 0000000000000000 R10: 4200000000000005 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f530d216038 R14: 00007f530d215fa0 R15: 00007ffde89fb978 </TASK>(CVE-2026-31551)
In the Linux kernel, the following vulnerability has been resolved:
nvmet: move async event work off nvmet-wq
For target nvmet_ctrl_free() flushes ctrl->async_event_work. If nvmet_ctrl_free() runs on nvmet-wq, the flush re-enters workqueue completion for the same worker:-
A. Async event work queued on nvmet-wq (prior to disconnect): nvmet_execute_async_event() queue_work(nvmet_wq, &ctrl->async_event_work)
nvmet_add_async_event() queue_work(nvmet_wq, &ctrl->async_event_work)
B. Full pre-work chain (RDMA CM path): nvmet_rdma_cm_handler() nvmet_rdma_queue_disconnect() __nvmet_rdma_queue_disconnect() queue_work(nvmet_wq, &queue->release_work) process_one_work() lock((wq_completion)nvmet-wq) <--------- 1st nvmet_rdma_release_queue_work()
C. Recursive path (same worker): nvmet_rdma_release_queue_work() nvmet_rdma_free_queue() nvmet_sq_destroy() nvmet_ctrl_put() nvmet_ctrl_free() flush_work(&ctrl->async_event_work) __flush_work() touch_wq_lockdep_map() lock((wq_completion)nvmet-wq) <--------- 2nd
Lockdep splat:
============================================ WARNING: possible recursive locking detected 6.19.0-rc3nvme+ #14 Tainted: G N
kworker/u192:42/44933 is trying to acquire lock: ffff888118a00948 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: touch_wq_lockdep_map+0x26/0x90
but task is already holding lock: ffff888118a00948 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: process_one_work+0x53e/0x660
3 locks held by kworker/u192:42/44933: #0: ffff888118a00948 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: process_one_work+0x53e/0x660 #1: ffffc9000e6cbe28 ((work_completion)(&queue->release_work)){+.+.}-{0:0}, at: process_one_work+0x1c5/0x660 #2: ffffffff82d4db60 (rcu_read_lock){....}-{1:3}, at: __flush_work+0x62/0x530
Workqueue: nvmet-wq nvmet_rdma_release_queue_work [nvmet_rdma] Call Trace: __flush_work+0x268/0x530 nvmet_ctrl_free+0x140/0x310 [nvmet] nvmet_cq_put+0x74/0x90 [nvmet] nvmet_rdma_free_queue+0x23/0xe0 [nvmet_rdma] nvmet_rdma_release_queue_work+0x19/0x50 [nvmet_rdma] process_one_work+0x206/0x660 worker_thread+0x184/0x320 kthread+0x10c/0x240 ret_from_fork+0x319/0x390
Move async event work to a dedicated nvmet-aen-wq to avoid reentrant flush on nvmet-wq.(CVE-2026-31557)
In the Linux kernel, the following vulnerability has been resolved:
bcache: fix cached_dev.sb_bio use-after-free and crash
In our production environment, we have received multiple crash reports regarding libceph, which have caught our attention:
[6888366.280350] Call Trace:
[6888366.280452] blk_update_request+0x14e/0x370
[6888366.280561] blk_mq_end_request+0x1a/0x130
[6888366.280671] rbd_img_handle_request+0x1a0/0x1b0 [rbd]
[6888366.280792] rbd_obj_handle_request+0x32/0x40 [rbd]
[6888366.280903] __complete_request+0x22/0x70 [libceph]
[6888366.281032] osd_dispatch+0x15e/0xb40 [libceph]
[6888366.281164] ? inet_recvmsg+0x5b/0xd0
[6888366.281272] ? ceph_tcp_recvmsg+0x6f/0xa0 [libceph]
[6888366.281405] ceph_con_process_message+0x79/0x140 [libceph]
[6888366.281534] ceph_con_v1_try_read+0x5d7/0xf30 [libceph]
[6888366.281661] ceph_con_workfn+0x329/0x680 [libceph]
After analyzing the coredump file, we found that the address of dc->sb_bio has been freed. We know that cached_dev is only freed when it is stopped.
Since sb_bio is a part of struct cached_dev, rather than an alloc every time. If the device is stopped while writing to the superblock, the released address will be accessed at endio.
This patch hopes to wait for sb_write to complete in cached_dev_free.
It should be noted that we analyzed the cause of the problem, then tell all details to the QWEN and adopted the modifications it made.(CVE-2026-31580)
In the Linux kernel, the following vulnerability has been resolved:
KVM: x86: Use scratch field in MMIO fragment to hold small write values
When exiting to userspace to service an emulated MMIO write, copy the to-be-written value to a scratch field in the MMIO fragment if the size of the data payload is 8 bytes or less, i.e. can fit in a single chunk, instead of pointing the fragment directly at the source value.
This fixes a class of use-after-free bugs that occur when the emulator initiates a write using an on-stack, local variable as the source, the write splits a page boundary, and both pages are MMIO pages. Because KVM's ABI only allows for physically contiguous MMIO requests, accesses that split MMIO pages are separated into two fragments, and are sent to userspace one at a time. When KVM attempts to complete userspace MMIO in response to KVM_RUN after the first fragment, KVM will detect the second fragment and generate a second userspace exit, and reference the on-stack variable.
The issue is most visible if the second KVM_RUN is performed by a separate task, in which case the stack of the initiating task can show up as truly freed data.
================================================================== BUG: KASAN: use-after-free in complete_emulated_mmio+0x305/0x420 Read of size 1 at addr ffff888009c378d1 by task syz-executor417/984
CPU: 1 PID: 984 Comm: syz-executor417 Not tainted 5.10.0-182.0.0.95.h2627.eulerosv2r13.x86_64 #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack+0xbe/0xfd print_address_description.constprop.0+0x19/0x170 __kasan_report.cold+0x6c/0x84 kasan_report+0x3a/0x50 check_memory_region+0xfd/0x1f0 memcpy+0x20/0x60 complete_emulated_mmio+0x305/0x420 kvm_arch_vcpu_ioctl_run+0x63f/0x6d0 kvm_vcpu_ioctl+0x413/0xb20 __se_sys_ioctl+0x111/0x160 do_syscall_64+0x30/0x40 entry_SYSCALL_64_after_hwframe+0x67/0xd1 RIP: 0033:0x42477d Code: <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007faa8e6890e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00000000004d7338 RCX: 000000000042477d RDX: 0000000000000000 RSI: 000000000000ae80 RDI: 0000000000000005 RBP: 00000000004d7330 R08: 00007fff28d546df R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00000000004d733c R13: 0000000000000000 R14: 000000000040a200 R15: 00007fff28d54720
The buggy address belongs to the page: page:0000000029f6a428 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x9c37 flags: 0xfffffc0000000(node=0|zone=1|lastcpupid=0x1fffff) raw: 000fffffc0000000 0000000000000000 ffffea0000270dc8 0000000000000000 raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected
Memory state around the buggy address: ffff888009c37780: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff888009c37800: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff >ffff888009c37880: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ ffff888009c37900: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff888009c37980: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ==================================================================
The bug can also be reproduced with a targeted KVM-Unit-Test by hacking KVM to fill a large on-stack variable in complete_emulated_mmio(), i.e. by overwrite the data value with garbage.
Limit the use of the scratch fields to 8-byte or smaller accesses, and to just writes, as larger accesses and reads are not affected thanks to implementation details in the emulator, but add a sanity check to ensure those details don't change in the future. Specifically, KVM never uses on-stack variables for accesses larger that 8 bytes, e.g. uses an operand in the emulator context, and *al ---truncated---(CVE-2026-31588)
In the Linux kernel, the following vulnerability has been resolved:
tipc: fix bc_ackers underflow on duplicate GRP_ACK_MSG
The GRP_ACK_MSG handler in tipc_group_proto_rcv() currently decrements bc_ackers on every inbound group ACK, even when the same member has already acknowledged the current broadcast round.
Because bc_ackers is a u16, a duplicate ACK received after the last legitimate ACK wraps the counter to 65535. Once wrapped, tipc_group_bc_cong() keeps reporting congestion and later group broadcasts on the affected socket stay blocked until the group is recreated.
Fix this by ignoring duplicate or stale ACKs before touching bc_acked or bc_ackers. This makes repeated GRP_ACK_MSG handling idempotent and prevents the underflow path.(CVE-2026-31662)
In the Linux kernel, the following vulnerability has been resolved:
xfrm: clear trailing padding in build_polexpire()
build_expire() clears the trailing padding bytes of struct xfrm_user_expire after setting the hard field via memset_after(), but the analogous function build_polexpire() does not do this for struct xfrm_user_polexpire.
The padding bytes after the __u8 hard field are left uninitialized from the heap allocation, and are then sent to userspace via netlink multicast to XFRMNLGRP_EXPIRE listeners, leaking kernel heap memory contents.
Add the missing memset_after() call, matching build_expire().(CVE-2026-31664)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: xt_multiport: validate range encoding in checkentry
ports_match_v1() treats any non-zero pflags entry as the start of a port range and unconditionally consumes the next ports[] element as the range end.
The checkentry path currently validates protocol, flags and count, but it does not validate the range encoding itself. As a result, malformed rules can mark the last slot as a range start or place two range starts back to back, leaving ports_match_v1() to step past the last valid ports[] element while interpreting the rule.
Reject malformed multiport v1 rules in checkentry by validating that each range start has a following element and that the following element is not itself marked as another range start.(CVE-2026-31681)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: validate owner of durable handle on reconnect
Currently, ksmbd does not verify if the user attempting to reconnect to a durable handle is the same user who originally opened the file. This allows any authenticated user to hijack an orphaned durable handle by predicting or brute-forcing the persistent ID.
According to MS-SMB2, the server MUST verify that the SecurityContext of the reconnect request matches the SecurityContext associated with the existing open. Add a durable_owner structure to ksmbd_file to store the original opener's UID, GID, and account name. and catpure the owner information when a file handle becomes orphaned. and implementing ksmbd_vfs_compare_durable_owner() to validate the identity of the requester during SMB2_CREATE (DHnC).(CVE-2026-31717)
In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: f_ecm: Fix net_device lifecycle with device_move
The net_device is allocated during function instance creation and registered during the bind phase with the gadget device as its sysfs parent. When the function unbinds, the parent device is destroyed, but the net_device survives, resulting in dangling sysfs symlinks:
console:/ # ls -l /sys/class/net/usb0 lrwxrwxrwx ... /sys/class/net/usb0 -> /sys/devices/platform/.../gadget.0/net/usb0 console:/ # ls -l /sys/devices/platform/.../gadget.0/net/usb0 ls: .../gadget.0/net/usb0: No such file or directory
Use device_move() to reparent the net_device between the gadget device tree and /sys/devices/virtual across bind and unbind cycles. During the final unbind, calling device_move(NULL) moves the net_device to the virtual device tree before the gadget device is destroyed. On rebinding, device_move() reparents the device back under the new gadget, ensuring proper sysfs topology and power management ordering.
To maintain compatibility with legacy composite drivers (e.g., multi.c), the bound flag is used to indicate whether the network device is shared and pre-registered during the legacy driver's bind phase.(CVE-2026-31725)
In the Linux kernel, the following vulnerability has been resolved:
usb: ulpi: fix double free in ulpi_register_interface() error path
When device_register() fails, ulpi_register() calls put_device() on ulpi->dev.
The device release callback ulpi_dev_release() drops the OF node reference and frees ulpi, but the current error path in ulpi_register_interface() then calls kfree(ulpi) again, causing a double free.
Let put_device() handle the cleanup through ulpi_dev_release() and avoid freeing ulpi again in ulpi_register_interface().(CVE-2026-31759)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_sync: hci_cmd_sync_queue_once() return -EEXIST if exists
hci_cmd_sync_queue_once() needs to indicate whether a queue item was added, so caller can know if callbacks are called, so it can avoid leaking resources.
Change the function to return -EEXIST if queue item already exists.
Modify all callsites to handle that.(CVE-2026-43022)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: ctnetlink: ignore explicit helper on new expectations
Use the existing master conntrack helper, anything else is not really supported and it just makes validation more complicated, so just ignore what helper userspace suggests for this expectation.
This was uncovered when validating CTA_EXPECT_CLASS via different helper provided by userspace than the existing master conntrack helper:
BUG: KASAN: slab-out-of-bounds in nf_ct_expect_related_report+0x2479/0x27c0 Read of size 4 at addr ffff8880043fe408 by task poc/102 Call Trace: nf_ct_expect_related_report+0x2479/0x27c0 ctnetlink_create_expect+0x22b/0x3b0 ctnetlink_new_expect+0x4bd/0x5c0 nfnetlink_rcv_msg+0x67a/0x950 netlink_rcv_skb+0x120/0x350
Allowing to read kernel memory bytes off the expectation boundary.
CTA_EXPECT_HELP_NAME is still used to offer the helper name to userspace via netlink dump.(CVE-2026-43025)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: ctnetlink: zero expect NAT fields when CTA_EXPECT_NAT absent
ctnetlink_alloc_expect() allocates expectations from a non-zeroing slab cache via nf_ct_expect_alloc(). When CTA_EXPECT_NAT is not present in the netlink message, saved_addr and saved_proto are never initialized. Stale data from a previous slab occupant can then be dumped to userspace by ctnetlink_exp_dump_expect(), which checks these fields to decide whether to emit CTA_EXPECT_NAT.
The safe sibling nf_ct_expect_init(), used by the packet path, explicitly zeroes these fields.
Zero saved_addr, saved_proto and dir in the else branch, guarded by IS_ENABLED(CONFIG_NF_NAT) since these fields only exist when NAT is enabled.
Confirmed by priming the expect slab with NAT-bearing expectations, freeing them, creating a new expectation without CTA_EXPECT_NAT, and observing that the ctnetlink dump emits a spurious CTA_EXPECT_NAT containing stale data from the prior allocation.(CVE-2026-43026)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: x_tables: ensure names are nul-terminated
Reject names that lack a \0 character before feeding them to functions that expect c-strings.
Fixes tag is the most recent commit that needs this change.(CVE-2026-43028)
In the Linux kernel, the following vulnerability has been resolved:
net: ioam6: fix OOB and missing lock
When trace->type.bit6 is set:
if (trace->type.bit6) {
...
queue = skb_get_tx_queue(dev, skb);
qdisc = rcu_dereference(queue->qdisc);
This code can lead to an out-of-bounds access of the dev->_tx[] array when is_input is true. In such a case, the packet is on the RX path and skb->queue_mapping contains the RX queue index of the ingress device. If the ingress device has more RX queues than the egress device (dev) has TX queues, skb_get_queue_mapping(skb) will exceed dev->num_tx_queues. Add a check to avoid this situation since skb_get_tx_queue() does not clamp the index. This issue has also revealed that per queue visibility cannot be accurate and will be replaced later as a new feature.
While at it, add missing lock around qdisc_qstats_qlen_backlog(). The function __ioam6_fill_trace_data() is called from both softirq and process contexts, hence the use of spin_lock_bh() here.(CVE-2026-43083)
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:
ipv4: icmp: fix null-ptr-deref in icmp_build_probe()
ipv6_stub->ipv6_dev_find() may return ERR_PTR(-EAFNOSUPPORT) when the IPv6 stack is not active (CONFIG_IPV6=m and not loaded), and passing this error pointer to dev_hold() will cause a kernel crash with null-ptr-deref.
Instead, silently discard the request. RFC 8335 does not appear to define a specific response for the case where an IPv6 interface identifier is syntactically valid but the implementation cannot perform the lookup at runtime, and silently dropping the request may safer than misreporting "No Such Interface".(CVE-2026-43099)
In the Linux kernel, the following vulnerability has been resolved:
ipv6: ioam: fix potential NULL dereferences in __ioam6_fill_trace_data()
We need to check __in6_dev_get() for possible NULL value, as suggested by Yiming Qian.
Also add skb_dst_dev_rcu() instead of skb_dst_dev(), and two missing READ_ONCE().
Note that @dev can't be NULL.(CVE-2026-43101)
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:
ntfs3: fix circular locking dependency in run_unpack_ex
Syzbot reported a circular locking dependency between wnd->rw_lock (sbi->used.bitmap) and ni->file.run_lock.
The deadlock scenario: 1. ntfs_extend_mft() takes ni->file.run_lock then wnd->rw_lock. 2. run_unpack_ex() takes wnd->rw_lock then tries to acquire ni->file.run_lock inside ntfs_refresh_zone().
This creates an AB-BA deadlock.
Fix this by using down_read_trylock() instead of down_read() when acquiring run_lock in run_unpack_ex(). If the lock is contended, skip ntfs_refresh_zone() - the MFT zone will be refreshed on the next MFT operation. This breaks the circular dependency since we never block waiting for run_lock while holding wnd->rw_lock.(CVE-2026-43127)
In the Linux kernel, the following vulnerability has been resolved:
net: usb: pegasus: enable basic endpoint checking
pegasus_probe() fills URBs with hardcoded endpoint pipes without verifying the endpoint descriptors:
- usb_rcvbulkpipe(dev, 1) for RX data
- usb_sndbulkpipe(dev, 2) for TX data
- usb_rcvintpipe(dev, 3) for status interrupts
A malformed USB device can present these endpoints with transfer types that differ from what the driver assumes.
Add a pegasus_usb_ep enum for endpoint numbers, replacing magic constants throughout. Add usb_check_bulk_endpoints() and usb_check_int_endpoints() calls before any resource allocation to verify endpoint types before use, rejecting devices with mismatched descriptors at probe time, and avoid triggering assertion.
Similar fix to - commit 90b7f2961798 ("net: usb: rtl8150: enable basic endpoint checking") - commit 9e7021d2aeae ("net: usb: catc: enable basic endpoint checking")(CVE-2026-43156)
In the Linux kernel, the following vulnerability has been resolved:
md/bitmap: fix GPF in write_page caused by resize race
A General Protection Fault occurs in write_page() during array resize: RIP: 0010:write_page+0x22b/0x3c0 [md_mod]
This is a use-after-free race between bitmap_daemon_work() and
__bitmap_resize(). The daemon iterates over bitmap->storage.filemap
without locking, while the resize path frees that storage via
md_bitmap_file_unmap(). quiesce() does not stop the md thread,
allowing concurrent access to freed pages.
Fix by holding mddev->bitmap_info.mutex during the bitmap update.(CVE-2026-43163)
In the Linux kernel, the following vulnerability has been resolved:
net: usb: kaweth: remove TX queue manipulation in kaweth_set_rx_mode
kaweth_set_rx_mode(), the ndo_set_rx_mode callback, calls netif_stop_queue() and netif_wake_queue(). These are TX queue flow control functions unrelated to RX multicast configuration.
The premature netif_wake_queue() can re-enable TX while tx_urb is still in-flight, leading to a double usb_submit_urb() on the same URB:
kaweth_start_xmit() { netif_stop_queue(); usb_submit_urb(kaweth->tx_urb); }
kaweth_set_rx_mode() { netif_stop_queue(); netif_wake_queue(); // wakes TX queue before URB is done }
kaweth_start_xmit() { netif_stop_queue(); usb_submit_urb(kaweth->tx_urb); // URB submitted while active }
This triggers the WARN in usb_submit_urb():
"URB submitted while active"
This is a similar class of bug fixed in rtl8150 by
- commit 958baf5eaee3 ("net: usb: Remove disruptive netif_wake_queue in rtl8150_set_multicast").
Also kaweth_set_rx_mode() is already functionally broken, the real set_rx_mode action is performed by kaweth_async_set_rx_mode(), which in turn is not a no-op only at ndo_open() time.(CVE-2026-43180)
In the Linux kernel, the following vulnerability has been resolved:
ipv6: ioam: fix heap buffer overflow in __ioam6_fill_trace_data()
On the receive path, __ioam6_fill_trace_data() uses trace->nodelen to decide how much data to write for each node. It trusts this field as-is from the incoming packet, with no consistency check against trace->type (the 24-bit field that tells which data items are present). A crafted packet can set nodelen=0 while setting type bits 0-21, causing the function to write ~100 bytes past the allocated region (into skb_shared_info), which corrupts adjacent heap memory and leads to a kernel panic.
Add a shared helper ioam6_trace_compute_nodelen() in ioam6.c to derive the expected nodelen from the type field, and use it:
- in ioam6_iptunnel.c (send path, existing validation) to replace the open-coded computation;
- in exthdrs.c (receive path, ipv6_hop_ioam) to drop packets whose nodelen is inconsistent with the type field, before any data is written.
Per RFC 9197, bits 12-21 are each short (4-octet) fields, so they are included in IOAM6_MASK_SHORT_FIELDS (changed from 0xff100000 to 0xff1ffc00).(CVE-2026-43186)
In the Linux kernel, the following vulnerability has been resolved:
net: consume xmit errors of GSO frames
udpgro_frglist.sh and udpgro_bench.sh are the flakiest tests currently in NIPA. They fail in the same exact way, TCP GRO test stalls occasionally and the test gets killed after 10min.
These tests use veth to simulate GRO. They attach a trivial ("return XDP_PASS;") XDP program to the veth to force TSO off and NAPI on.
Digging into the failure mode we can see that the connection is completely stuck after a burst of drops. The sender's snd_nxt is at sequence number N [1], but the receiver claims to have received (rcv_nxt) up to N + 3 * MSS [2]. Last piece of the puzzle is that senders rtx queue is not empty (let's say the block in the rtx queue is at sequence number N - 4 * MSS [3]).
In this state, sender sends a retransmission from the rtx queue with a single segment, and sequence numbers N-4MSS:N-3MSS [3]. Receiver sees it and responds with an ACK all the way up to N + 3 * MSS [2]. But sender will reject this ack as TCP_ACK_UNSENT_DATA because it has no recollection of ever sending data that far out [1]. And we are stuck.
The root cause is the mess of the xmit return codes. veth returns an error when it can't xmit a frame. We end up with a loss event like this:
| GSO super frame 1 | GSO super frame 2 | |-----------------------------------------------| | seg | seg | seg | seg | seg | seg | seg | seg | | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 |
x ok ok <ok>| ok ok ok <x>
\\
snd_nxt
"x" means packet lost by veth, and "ok" means it went thru. Since veth has TSO disabled in this test it sees individual segments. Segment 1 is on the retransmit queue and will be resent.
So why did the sender not advance snd_nxt even tho it clearly did send up to seg 8? tcp_write_xmit() interprets the return code from the core to mean that data has not been sent at all. Since TCP deals with GSO super frames, not individual segment the crux of the problem is that loss of a single segment can be interpreted as loss of all. TCP only sees the last return code for the last segment of the GSO frame (in <> brackets in the diagram above).
Of course for the problem to occur we need a setup or a device without a Qdisc. Otherwise Qdisc layer disconnects the protocol layer from the device errors completely.
We have multiple ways to fix this.
1) make veth not return an error when it lost a packet. While this is what I think we did in the past, the issue keeps reappearing and it's annoying to debug. The game of whack a mole is not great.
2) fix the damn return codes We only talk about NETDEV_TX_OK and NETDEV_TX_BUSY in the documentation, so maybe we should make the return code from ndo_start_xmit() a boolean. I like that the most, but perhaps some ancient, not-really-networking protocol would suffer.
3) make TCP ignore the errors It is not entirely clear to me what benefit TCP gets from interpreting the result of ip_queue_xmit()? Specifically once the connection is established and we're pushing data - packet loss is just packet loss?
4) this fix Ignore the rc in the Qdisc-less+GSO case, since it's unreliable. We already always return OK in the TCQ_F_CAN_BYPASS case. In the Qdisc-less case let's be a bit more conservative and only mask the GSO errors. This path is taken by non-IP-"networks" like CAN, MCTP etc, so we could regress some ancient thing. This is the simplest, but also maybe the hackiest fix?
Similar fix has been proposed by Eric in the past but never committed because original reporter was working with an OOT driver and wasn't providing feedback (see Link).(CVE-2026-43194)
In the Linux kernel, the following vulnerability has been resolved:
netconsole: avoid OOB reads, msg is not nul-terminated
msg passed to netconsole from the console subsystem is not guaranteed to be nul-terminated. Before recent commit 7eab73b18630 ("netconsole: convert to NBCON console infrastructure") the message would be placed in printk_shared_pbufs, a static global buffer, so KASAN had harder time catching OOB accesses. Now we see:
printk: console [netcon_ext0] enabled
BUG: KASAN: slab-out-of-bounds in string+0x1f7/0x240
Read of size 1 at addr ffff88813b6d4c00 by task pr/netcon_ext0/594
CPU: 65 UID: 0 PID: 594 Comm: pr/netcon_ext0 Not tainted 6.19.0-11754-g4246fd6547c9
Call Trace:
kasan_report+0xe4/0x120
string+0x1f7/0x240
vsnprintf+0x655/0xba0
scnprintf+0xba/0x120
netconsole_write+0x3fe/0xa10
nbcon_emit_next_record+0x46e/0x860
nbcon_kthread_func+0x623/0x750
Allocated by task 1:
nbcon_alloc+0x1ea/0x450
register_console+0x26b/0xe10
init_netconsole+0xbb0/0xda0
The buggy address belongs to the object at ffff88813b6d4000
which belongs to the cache kmalloc-4k of size 4096
The buggy address is located 0 bytes to the right of
allocated 3072-byte region [ffff88813b6d4000, ffff88813b6d4c00)(CVE-2026-43197)
In the Linux kernel, the following vulnerability has been resolved:
iommu/amd: serialize sequence allocation under concurrent TLB invalidations
With concurrent TLB invalidations, completion wait randomly gets timed out because cmd_sem_val was incremented outside the IOMMU spinlock, allowing CMD_COMPL_WAIT commands to be queued out of sequence and breaking the ordering assumption in wait_on_sem(). Move the cmd_sem_val increment under iommu->lock so completion sequence allocation is serialized with command queuing. And remove the unnecessary return.(CVE-2026-43220)
In the Linux kernel, the following vulnerability has been resolved:
smb: client: prevent races in ->query_interfaces()
It was possible for two query interface works to be concurrently trying to update the interfaces.
Prevent this by checking and updating iface_last_update under iface_lock.(CVE-2026-43239)
In the Linux kernel, the following vulnerability has been resolved:
x86/kexec: add a sanity check on previous kernel's ima kexec buffer
When the second-stage kernel is booted via kexec with a limiting command line such as "mem=<size>", the physical range that contains the carried over IMA measurement list may fall outside the truncated RAM leading to a kernel panic.
BUG: unable to handle page fault for address: ffff97793ff47000
RIP: ima_restore_measurement_list+0xdc/0x45a
#PF: error_code(0x0000) – not-present page
Other architectures already validate the range with page_is_ram(), as done in commit cbf9c4b9617b ("of: check previous kernel's ima-kexec-buffer against memory bounds") do a similar check on x86.
Without carrying the measurement list across kexec, the attestation would fail.(CVE-2026-43240)
In the Linux kernel, the following vulnerability has been resolved:
ext4: move ext4_percpu_param_init() before ext4_mb_init()
When running kvm-xfstests -c ext4/1k -C 1 generic/383 with the
DOUBLE_CHECK macro defined, the following panic is triggered:
================================================================== EXT4-fs error (device vdc): ext4_validate_block_bitmap:423: comm mount: bg 0: bad block bitmap checksum BUG: unable to handle page fault for address: ff110000fa2cc000 PGD 3e01067 P4D 3e02067 PUD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 0 UID: 0 PID: 2386 Comm: mount Tainted: G W 6.18.0-gba65a4e7120a-dirty #1152 PREEMPT(none) RIP: 0010:percpu_counter_add_batch+0x13/0xa0 Call Trace: <TASK> ext4_mark_group_bitmap_corrupted+0xcb/0xe0 ext4_validate_block_bitmap+0x2a1/0x2f0 ext4_read_block_bitmap+0x33/0x50 mb_group_bb_bitmap_alloc+0x33/0x80 ext4_mb_add_groupinfo+0x190/0x250 ext4_mb_init_backend+0x87/0x290 ext4_mb_init+0x456/0x640 __ext4_fill_super+0x1072/0x1680 ext4_fill_super+0xd3/0x280 get_tree_bdev_flags+0x132/0x1d0 vfs_get_tree+0x29/0xd0 vfs_cmd_create+0x59/0xe0 __do_sys_fsconfig+0x4f6/0x6b0 do_syscall_64+0x50/0x1f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e ==================================================================
This issue can be reproduced using the following commands: mkfs.ext4 -F -q -b 1024 /dev/sda 5G tune2fs -O quota,project /dev/sda mount /dev/sda /tmp/test
With DOUBLE_CHECK defined, mb_group_bb_bitmap_alloc() reads and validates the block bitmap. When the validation fails, ext4_mark_group_bitmap_corrupted() attempts to update sbi->s_freeclusters_counter. However, this percpu_counter has not been initialized yet at this point, which leads to the panic described above.
Fix this by moving the execution of ext4_percpu_param_init() to occur before ext4_mb_init(), ensuring the per-CPU counters are initialized before they are used.(CVE-2026-43288)
In the Linux kernel, the following vulnerability has been resolved:
md raid: fix hang when stopping arrays with metadata through dm-raid
When using device-mapper's dm-raid target, stopping a RAID array can cause the system to hang under specific conditions.
This occurs when:
-
A dm-raid managed device tree is suspended from top to bottom (the top-level RAID device is suspended first, followed by its underlying metadata and data devices)
-
The top-level RAID device is then removed
Removing the top-level device triggers a hang in the following sequence: the dm-raid destructor calls md_stop(), which tries to flush the write-intent bitmap by writing to the metadata sub-devices. However, these devices are already suspended, making them unable to complete the write-intent operations and causing an indefinite block.
Fix:
-
Prevent bitmap flushing when md_stop() is called from dm-raid destructor context and avoid a quiescing/unquescing cycle which could also cause I/O
-
Still allow write-intent bitmap flushing when called from dm-raid suspend context
This ensures that RAID array teardown can complete successfully even when the underlying devices are in a suspended state.
This second patch uses md_is_rdwr() to distinguish between suspend and destructor paths as elaborated on above.(CVE-2026-43309)
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:
Bluetooth: SMP: force responder MITM requirements before building the pairing response
smp_cmd_pairing_req() currently builds the pairing response from the initiator auth_req before enforcing the local BT_SECURITY_HIGH requirement. If the initiator omits SMP_AUTH_MITM, the response can also omit it even though the local side still requires MITM.
tk_request() then sees an auth value without SMP_AUTH_MITM and may select JUST_CFM, making method selection inconsistent with the pairing policy the responder already enforces.
When the local side requires HIGH security, first verify that MITM can be achieved from the IO capabilities and then force SMP_AUTH_MITM in the response in both rsp.auth_req and auth. This keeps the responder auth bits and later method selection aligned.(CVE-2026-43334)
In the Linux kernel, the following vulnerability has been resolved:
smb: client: require a full NFS mode SID before reading mode bits
parse_dacl() treats an ACE SID matching sid_unix_NFS_mode as an NFS mode SID and reads sid.sub_auth[2] to recover the mode bits.
That assumes the ACE carries three subauthorities, but compare_sids() only compares min(a, b) subauthorities. A malicious server can return an ACE with num_subauth = 2 and sub_auth[] = {88, 3}, which still matches sid_unix_NFS_mode and then drives the sub_auth[2] read four bytes past the end of the ACE.
Require num_subauth >= 3 before treating the ACE as an NFS mode SID. This keeps the fix local to the special-SID mode path without changing compare_sids() semantics for the rest of cifsacl.(CVE-2026-43350)
In the Linux kernel, the following vulnerability has been resolved:
io_uring/kbuf: check if target buffer list is still legacy on recycle
There's a gap between when the buffer was grabbed and when it potentially gets recycled, where if the list is empty, someone could've upgraded it to a ring provided type. This can happen if the request is forced via io-wq. The legacy recycling is missing checking if the buffer_list still exists, and if it's of the correct type. Add those checks.(CVE-2026-43366)
In the Linux kernel, the following vulnerability has been resolved:
libceph: prevent potential out-of-bounds reads in process_message_header()
If the message frame is (maliciously) corrupted in a way that the length of the control segment ends up being less than the size of the message header or a different frame is made to look like a message frame, out-of-bounds reads may ensue in process_message_header().
Perform an explicit bounds check before decoding the message header.(CVE-2026-43406)
In the Linux kernel, the following vulnerability has been resolved:
e1000/e1000e: Fix leak in DMA error cleanup
If an error is encountered while mapping TX buffers, the driver should unmap any buffers already mapped for that skb.
Because count is incremented after a successful mapping, it will always match the correct number of unmappings needed when dma_error is reached. Decrementing count before the while loop in dma_error causes an off-by-one error. If any mapping was successful before an unsuccessful mapping, exactly one DMA mapping would leak.
In these commits, a faulty while condition caused an infinite loop in dma_error: Commit 03b1320dfcee ("e1000e: remove use of skb_dma_map from e1000e driver") Commit 602c0554d7b0 ("e1000: remove use of skb_dma_map from e1000 driver")
Commit c1fa347f20f1 ("e1000/e1000e/igb/igbvf/ixgb/ixgbe: Fix tests of unsigned in *_tx_map()") fixed the infinite loop, but introduced the off-by-one error.
This issue may still exist in the igbvf driver, but I did not address it in this patch.(CVE-2026-43445)
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Fix DMA FIFO desync on error CQE SQ recovery
In case of a TX error CQE, a recovery flow is triggered, mlx5e_reset_txqsq_cc_pc() resets dma_fifo_cc to 0 but not dma_fifo_pc, desyncing the DMA FIFO producer and consumer.
After recovery, the producer pushes new DMA entries at the old dma_fifo_pc, while the consumer reads from position 0. This causes us to unmap stale DMA addresses from before the recovery.
The DMA FIFO is a purely software construct with no HW counterpart. At the point of reset, all WQEs have been flushed so dma_fifo_cc is already equal to dma_fifo_pc. There is no need to reset either counter, similar to how skb_fifo pc/cc are untouched.
Remove the 'dma_fifo_cc = 0' reset.
This fixes the following WARNING: WARNING: CPU: 0 PID: 0 at drivers/iommu/dma-iommu.c:1240 iommu_dma_unmap_page+0x79/0x90 Modules linked in: mlx5_vdpa vringh vdpa bonding mlx5_ib mlx5_vfio_pci ipip mlx5_fwctl tunnel4 mlx5_core ib_ipoib geneve ip6_gre ip_gre gre nf_tables ip6_tunnel rdma_ucm ib_uverbs ib_umad vfio_pci vfio_pci_core act_mirred act_skbedit act_vlan vhost_net vhost tap ip6table_mangle ip6table_nat ip6table_filter ip6_tables iptable_mangle cls_matchall nfnetlink_cttimeout act_gact cls_flower sch_ingress vhost_iotlb iptable_raw tunnel6 vfio_iommu_type1 vfio openvswitch nsh rpcsec_gss_krb5 auth_rpcgss oid_registry xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink iptable_nat nf_nat xt_addrtype br_netfilter overlay zram zsmalloc rpcrdma ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_cm ib_core fuse [last unloaded: nf_tables] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.13.0-rc5_for_upstream_min_debug_2024_12_30_21_33 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:iommu_dma_unmap_page+0x79/0x90 Code: 2b 4d 3b 21 72 26 4d 3b 61 08 73 20 49 89 d8 44 89 f9 5b 4c 89 f2 4c 89 e6 48 89 ef 5d 41 5c 41 5d 41 5e 41 5f e9 c7 ae 9e ff <0f> 0b 5b 5d 41 5c 41 5d 41 5e 41 5f c3 66 2e 0f 1f 84 00 00 00 00 Call Trace: <IRQ> ? __warn+0x7d/0x110 ? iommu_dma_unmap_page+0x79/0x90 ? report_bug+0x16d/0x180 ? handle_bug+0x4f/0x90 ? exc_invalid_op+0x14/0x70 ? asm_exc_invalid_op+0x16/0x20 ? iommu_dma_unmap_page+0x79/0x90 ? iommu_dma_unmap_page+0x2e/0x90 dma_unmap_page_attrs+0x10d/0x1b0 mlx5e_tx_wi_dma_unmap+0xbe/0x120 [mlx5_core] mlx5e_poll_tx_cq+0x16d/0x690 [mlx5_core] mlx5e_napi_poll+0x8b/0xac0 [mlx5_core] __napi_poll+0x24/0x190 net_rx_action+0x32a/0x3b0 ? mlx5_eq_comp_int+0x7e/0x270 [mlx5_core] ? notifier_call_chain+0x35/0xa0 handle_softirqs+0xc9/0x270 irq_exit_rcu+0x71/0xd0 common_interrupt+0x7f/0xa0 </IRQ> <TASK> asm_common_interrupt+0x22/0x40(CVE-2026-43466)
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: Fix deadlock between devlink lock and esw->wq
esw->work_queue executes esw_functions_changed_event_handler -> esw_vfs_changed_event_handler and acquires the devlink lock.
.eswitch_mode_set (acquires devlink lock in devlink_nl_pre_doit) -> mlx5_devlink_eswitch_mode_set -> mlx5_eswitch_disable_locked -> mlx5_eswitch_event_handler_unregister -> flush_workqueue deadlocks when esw_vfs_changed_event_handler executes.
Fix that by no longer flushing the work to avoid the deadlock, and using a generation counter to keep track of work relevance. This avoids an old handler manipulating an esw that has undergone one or more mode changes: - the counter is incremented in mlx5_eswitch_event_handler_unregister. - the counter is read and passed to the ephemeral mlx5_host_work struct. - the work handler takes the devlink lock and bails out if the current generation is different than the one it was scheduled to operate on. - mlx5_eswitch_cleanup does the final draining before destroying the wq.
No longer flushing the workqueue has the side effect of maybe no longer cancelling pending vport_change_handler work items, but that's ok since those are disabled elsewhere: - mlx5_eswitch_disable_locked disables the vport eq notifier. - mlx5_esw_vport_disable disarms the HW EQ notification and marks vport->enabled under state_lock to false to prevent pending vport handler from doing anything. - mlx5_eswitch_cleanup destroys the workqueue and makes sure all events are disabled/finished.(CVE-2026-43468)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Fix null-ptr-deref in l2cap_sock_state_change_cb()
Add the same NULL guard already present in l2cap_sock_resume_cb() and l2cap_sock_ready_cb().(CVE-2026-45834)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nfnetlink_queue: do shared-unconfirmed check before segmentation
Ulrich reports a regression with nfqueue:
If an application did not set the 'F_GSO' capability flag and a gso packet with an unconfirmed nf_conn entry is received all packets are now dropped instead of queued, because the check happens after skb_gso_segment(). In that case, we did have exclusive ownership of the skb and its associated conntrack entry. The elevated use count is due to skb_clone happening via skb_gso_segment().
Move the check so that its peformed vs. the aggregated packet.
Then, annotate the individual segments except the first one so we can do a 2nd check at reinject time.
For the normal case, where userspace does in-order reinjects, this avoids packet drops: first reinjected segment continues traversal and confirms entry, remaining segments observe the confirmed entry.
While at it, simplify nf_ct_drop_unconfirmed(): We only care about unconfirmed entries with a refcnt > 1, there is no need to special-case dying entries.
This only happens with UDP. With TCP, the only unconfirmed packet will be the TCP SYN, those aren't aggregated by GRO.
Next patch adds a udpgro test case to cover this scenario.(CVE-2026-45859)
In the Linux kernel, the following vulnerability has been resolved:
gfs2: Fix slab-use-after-free in qd_put
Commit a475c5dd16e5 ("gfs2: Free quota data objects synchronously") started freeing quota data objects during filesystem shutdown instead of putting them back onto the LRU list, but it failed to remove these objects from the LRU list, causing LRU list corruption. This caused use-after-free when the shrinker (gfs2_qd_shrink_scan) tried to access already-freed objects on the LRU list.
Fix this by removing qd objects from the LRU list before freeing them in qd_put().
Initial fix from Deepanshu Kartikey <(CVE-2026-45861)
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix bpf_xdp_store_bytes proto for read-only arg
While making some maps in Cilium read-only from the BPF side, we noticed that the bpf_xdp_store_bytes proto is incorrect. In particular, the verifier was throwing the following error:
; ret = ctx_store_bytes(ctx, l3_off + offsetof(struct iphdr, saddr), &nat->address, 4, 0); 635: (79) r1 = (u64 )(r10 -144) ; R1=ctx() R10=fp0 fp-144=ctx() 636: (b4) w2 = 26 ; R2=26 637: (b4) w4 = 4 ; R4=4 638: (b4) w5 = 0 ; R5=0 639: (85) call bpf_xdp_store_bytes#190 write into map forbidden, value_size=6 off=0 size=4
nat comes from a BPF_F_RDONLY_PROG map, so R3 is a PTR_TO_MAP_VALUE. The verifier checks the helper's memory access to R3 in check_mem_size_reg, as it reaches ARG_CONST_SIZE argument. The third argument has expected type ARG_PTR_TO_UNINIT_MEM, which includes the MEM_WRITE flag. The verifier thus checks for a BPF_WRITE access on R3. Given R3 points to a read-only map, the check fails.
Conversely, ARG_PTR_TO_UNINIT_MEM can also lead to the helper reading from uninitialized memory.
This patch simply fixes the expected argument type to match that of bpf_skb_store_bytes.(CVE-2026-45886)
In the Linux kernel, the following vulnerability has been resolved:
usb: cdns3: fix role switching during resume
If the role change while we are suspended, the cdns3 driver switches to the new mode during resume. However, switching to host mode in this context causes a NULL pointer dereference.
The host role's start() operation registers a xhci-hcd device, but its probe is deferred while we are in the resume path. The host role's resume() operation assumes the xhci-hcd device is already probed, which is not the case, leading to the dereference. Since the start() operation of the new role is already called, the resume operation can be skipped.
So skip the resume operation for the new role if a role switch occurs during resume. Once the resume sequence is complete, the xhci-hcd device can be probed in case of host mode.
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000208 Mem abort info: ... Data abort info: ... [0000000000000208] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] SMP Modules linked in: CPU: 0 UID: 0 PID: 146 Comm: sh Not tainted 6.19.0-rc7-00013-g6e64f4aabfae-dirty #135 PREEMPT Hardware name: Texas Instruments J7200 EVM (DT) pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : usb_hcd_is_primary_hcd+0x0/0x1c lr : cdns_host_resume+0x24/0x5c ... Call trace: usb_hcd_is_primary_hcd+0x0/0x1c (P) cdns_resume+0x6c/0xbc cdns3_controller_resume.isra.0+0xe8/0x17c cdns3_plat_resume+0x18/0x24 platform_pm_resume+0x2c/0x68 dpm_run_callback+0x90/0x248 device_resume+0x100/0x24c dpm_resume+0x190/0x2ec dpm_resume_end+0x18/0x34 suspend_devices_and_enter+0x2b0/0xa44 pm_suspend+0x16c/0x5fc state_store+0x80/0xec kobj_attr_store+0x18/0x2c sysfs_kf_write+0x7c/0x94 kernfs_fop_write_iter+0x130/0x1dc vfs_write+0x240/0x370 ksys_write+0x70/0x108 __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x10c el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0x108 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Code: 52800003 f9407ca5 d63f00a0 17ffffe4 (f9410401) ---[ end trace 0000000000000000 ]---(CVE-2026-45911)
In the Linux kernel, the following vulnerability has been resolved:
gfs2: fix memory leaks in gfs2_fill_super error path
Fix two memory leaks in the gfs2_fill_super() error handling path when transitioning a filesystem to read-write mode fails.
First leak: kthread objects (thread_struct, task_struct, etc.) When gfs2_freeze_lock_shared() fails after init_threads() succeeds, the created kernel threads (logd and quotad) are never destroyed. This occurs because the fail_per_node label doesn't call gfs2_destroy_threads().
Second leak: quota bitmap buffer (8192 bytes) When gfs2_make_fs_rw() fails after gfs2_quota_init() succeeds but before other operations complete, the allocated quota bitmap is never freed.
The fix moves thread cleanup to the fail_per_node label to handle all error paths uniformly. gfs2_destroy_threads() is safe to call unconditionally as it checks for NULL pointers. Quota cleanup is added in gfs2_make_fs_rw() to properly handle the withdrawal case where quota initialization succeeds but the filesystem is then withdrawn.
Thread leak backtrace (gfs2_freeze_lock_shared failure): unreferenced object 0xffff88801d7bca80 (size 4480): copy_process+0x3a1/0x4670 kernel/fork.c:2422 kernel_clone+0xf3/0x6e0 kernel/fork.c:2779 kthread_create_on_node+0x100/0x150 kernel/kthread.c:478 init_threads+0xab/0x350 fs/gfs2/ops_fstype.c:611 gfs2_fill_super+0xe5c/0x1240 fs/gfs2/ops_fstype.c:1265
Quota leak backtrace (gfs2_make_fs_rw failure): unreferenced object 0xffff88812de7c000 (size 8192): gfs2_quota_init+0xe5/0x820 fs/gfs2/quota.c:1409 gfs2_make_fs_rw+0x7a/0xe0 fs/gfs2/super.c:149 gfs2_fill_super+0xfbb/0x1240 fs/gfs2/ops_fstype.c:1275(CVE-2026-45961)
In the Linux kernel, the following vulnerability has been resolved:
ACPICA: Fix NULL pointer dereference in acpi_ev_address_space_dispatch()
Cover a missed execution path with a new check.(CVE-2026-45982)
In the Linux kernel, the following vulnerability has been resolved:
gfs2: Fix use-after-free in iomap inline data write path
The inline data buffer head (dibh) is being released prematurely in gfs2_iomap_begin() via release_metapath() while iomap->inline_data still points to dibh->b_data. This causes a use-after-free when iomap_write_end_inline() later attempts to write to the inline data area.
The bug sequence: 1. gfs2_iomap_begin() calls gfs2_meta_inode_buffer() to read inode metadata into dibh 2. Sets iomap->inline_data = dibh->b_data + sizeof(struct gfs2_dinode) 3. Calls release_metapath() which calls brelse(dibh), dropping refcount to 0 4. kswapd reclaims the page (~39ms later in the syzbot report) 5. iomap_write_end_inline() tries to memcpy() to iomap->inline_data 6. KASAN detects use-after-free write to freed memory
Fix by storing dibh in iomap->private and incrementing its refcount with get_bh() in gfs2_iomap_begin(). The buffer is then properly released in gfs2_iomap_end() after the inline write completes, ensuring the page stays alive for the entire iomap operation.
Note: A C reproducer is not available for this issue. The fix is based on analysis of the KASAN report and code review showing the buffer head is freed before use.
In the Linux kernel, the following vulnerability has been resolved:
erofs: fix unsigned underflow in z_erofs_lz4_handle_overlap()
Some crafted images can have illegal (!partial_decoding && m_llen < m_plen) extents, and the LZ4 inplace decompression path can be wrongly hit, but it cannot handle (outpages < inpages) properly: "outpages - inpages" wraps to a large value and the subsequent rq->out[] access reads past the decompressed_pages array.
However, such crafted cases can correctly result in a corruption report in the normal LZ4 non-inplace path.
Let's add an additional check to fix this for backporting.
Reproducible image (base64-encoded gzipped blob):
H4sIAJGR12kCA+3SPUoDQRgG4MkmkkZk8QRbRFIIi9hbpEjrHQI5ghfwCN5BLCzTGtLbBI+g dilSJo1CnIm7GEXFxhT6PDDwfrs73/ywIQD/1ePD4r7Ou6ETsrq4mu7XcWfj++Pb58nJU/9i PNtbjhan04/9GtX4qVYc814WDqt6FaX5s+ZwXXeq52lndT6IuVvlblytLMvh4Gzwaf90nsvz 2DF/21+20T/ldgp5s1jXRaN4t/8izsy/OUB6e/Qa79r+JwAAAAAAAL52vQVuGQAAAP6+my1w ywAAAAAAAADwu14ATsEYtgBQAAA=
$ mount -t erofs -o cache_strategy=disabled foo.erofs /mnt $ dd if=/mnt/data of=/dev/null bs=4096 count=1(CVE-2026-45999)
In the Linux kernel, the following vulnerability has been resolved:
drm/nouveau: fix u32 overflow in pushbuf reloc bounds check
nouveau_gem_pushbuf_reloc_apply() validates each relocation with
if (r->reloc_bo_offset + 4 > nvbo->bo.base.size)
but reloc_bo_offset is __u32 (uapi/drm/nouveau_drm.h) and the integer literal 4 promotes to unsigned int, so the addition is performed in 32 bits and wraps before the comparison against the size_t bo size.
Cast to u64 so the addition happens in 64-bit arithmetic.
In the Linux kernel, the following vulnerability has been resolved:
KVM: SVM: Add missing save/restore handling of LBR MSRs
MSR_IA32_DEBUGCTLMSR and LBR MSRs are currently not enumerated by KVM_GET_MSR_INDEX_LIST, and LBR MSRs cannot be set with KVM_SET_MSRS. So save/restore is completely broken.
Fix it by adding the MSRs to msrs_to_save_base, and allowing writes to LBR MSRs from userspace only (as they are read-only MSRs) if LBR virtualization is enabled. Additionally, to correctly restore L1's LBRs while L2 is running, make sure the LBRs are copied from the captured VMCB01 save area in svm_copy_vmrun_state().
Note, for VMX, this also fixes a flaw where MSR_IA32_DEBUGCTLMSR isn't reported as an MSR to save/restore.
Note #2, over-reporting MSR_IA32_LASTxxx on Intel is ok, as KVM already handles unsupported reads and writes thanks to commit b5e2fec0ebc3 ("KVM: Ignore DEBUGCTL MSRs with no effect") (kvm_do_msr_access() will morph the unsupported userspace write into a nop).
sean: guard with lbrv checks, massage changelog
In the Linux kernel, the following vulnerability has been resolved:
ipmi:ssif: Clean up kthread on errors
If an error occurs after the ssif kthread is created, but before the main IPMI code starts the ssif interface, the ssif kthread will not be stopped.
So make sure the kthread is stopped on an error condition if it is running.(CVE-2026-46044)
In the Linux kernel, the following vulnerability has been resolved:
md/raid5: fix soft lockup in retry_aligned_read()
When retry_aligned_read() encounters an overlapped stripe, it releases the stripe via raid5_release_stripe() which puts it on the lockless released_stripes llist. In the next raid5d loop iteration, release_stripe_list() drains the stripe onto handle_list (since STRIPE_HANDLE is set by the original IO), but retry_aligned_read() runs before handle_active_stripes() and removes the stripe from handle_list via find_get_stripe() -> list_del_init(). This prevents handle_stripe() from ever processing the stripe to resolve the overlap, causing an infinite loop and soft lockup.
Fix this by using __release_stripe() with temp_inactive_list instead of raid5_release_stripe() in the failure path, so the stripe does not go through the released_stripes llist. This allows raid5d to break out of its loop, and the overlap will be resolved when the stripe is eventually processed by handle_stripe().(CVE-2026-46051)
In the Linux kernel, the following vulnerability has been resolved:
ceph: only d_add() negative dentries when they are unhashed
Ceph can call d_add(dentry, NULL) on a negative dentry that is already present in the primary dcache hash.
In the current VFS that is not safe. d_add() goes through __d_add() to __d_rehash(), which unconditionally reinserts dentry->d_hash into the hlist_bl bucket. If the dentry is already hashed, reinserting the same node can corrupt the bucket, including creating a self-loop. Once that happens, __d_lookup() can spin forever in the hlist_bl walk, typically looping only on the d_name.hash mismatch check and eventually triggering RCU stall reports like this one:
rcu: INFO: rcu_sched self-detected stall on CPU rcu: 87-....: (2100 ticks this GP) idle=3a4c/1/0x4000000000000000 softirq=25003319/25003319 fqs=829 rcu: (t=2101 jiffies g=79058445 q=698988 ncpus=192) CPU: 87 UID: 2952868916 PID: 3933303 Comm: php-cgi8.3 Not tainted 6.18.17-i1-amd #950 NONE Hardware name: Dell Inc. PowerEdge R7615/0G9DHV, BIOS 1.6.6 09/22/2023 RIP: 0010:__d_lookup+0x46/0xb0 Code: c1 e8 07 48 8d 04 c2 48 8b 00 49 89 fc 49 89 f5 48 89 c3 48 83 e3 fe 48 83 f8 01 77 0f eb 2d 0f 1f 44 00 00 48 8b 1b 48 85 db <74> 20 39 6b 18 75 f3 48 8d 7b 78 e8 ba 85 d0 00 4c 39 63 10 74 1f RSP: 0018:ff745a70c8253898 EFLAGS: 00000282 RAX: ff26e470054cb208 RBX: ff26e470054cb208 RCX: 000000006e958966 RDX: ff26e48267340000 RSI: ff745a70c82539b0 RDI: ff26e458f74655c0 RBP: 000000006e958966 R08: 0000000000000180 R09: 9cd08d909b919a89 R10: ff26e458f74655c0 R11: 0000000000000000 R12: ff26e458f74655c0 R13: ff745a70c82539b0 R14: d0d0d0d0d0d0d0d0 R15: 2f2f2f2f2f2f2f2f FS: 00007f5770896980(0000) GS:ff26e482c5d88000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f5764de50c0 CR3: 000000a72abb5001 CR4: 0000000000771ef0 PKRU: 55555554 Call Trace: <TASK> lookup_fast+0x9f/0x100 walk_component+0x1f/0x150 link_path_walk+0x20e/0x3d0 path_lookupat+0x68/0x180 filename_lookup+0xdc/0x1e0 vfs_statx+0x6c/0x140 vfs_fstatat+0x67/0xa0 __do_sys_newfstatat+0x24/0x60 do_syscall_64+0x6a/0x230 entry_SYSCALL_64_after_hwframe+0x76/0x7e
This is reachable with reused cached negative dentries. A Ceph lookup or atomic_open can be handed a negative dentry that is already hashed, and fs/ceph/dir.c then hits one of two paths that incorrectly assume "negative" also means "unhashed":
-
ceph_finish_lookup(): MDS reply is -ENOENT with no trace -> d_add(dentry, NULL)
-
ceph_lookup(): local ENOENT fast path for a complete directory with shared caps -> d_add(dentry, NULL)
Both paths can therefore re-add an already-hashed negative dentry.
Ceph already uses the correct pattern elsewhere: ceph_fill_trace() only calls d_add(dn, NULL) for a negative null-dentry reply when d_unhashed(dn) is true.
Fix both fs/ceph/dir.c sites the same way: only call d_add() for a negative dentry when it is actually unhashed. If the negative dentry is already hashed, leave it in place and reuse it as-is.
This preserves the existing behavior for unhashed dentries while avoiding d_hash list corruption for reused hashed negatives.(CVE-2026-46052)
In the Linux kernel, the following vulnerability has been resolved:
KVM: nSVM: Raise #UD if unhandled VMMCALL isn't intercepted by L1
Explicitly synthesize a #UD for VMMCALL if L2 is active, L1 does NOT want to intercept VMMCALL, nested_svm_l2_tlb_flush_enabled() is true, and the hypercall is something other than one of the supported Hyper-V hypercalls. When all of the above conditions are met, KVM will intercept VMMCALL but never forward it to L1, i.e. will let L2 make hypercalls as if it were L1.
The TLFS says a whole lot of nothing about this scenario, so go with the architectural behavior, which says that VMMCALL #UDs if it's not intercepted.
Opportunistically do a 2-for-1 stub trade by stub-ifying the new API instead of the helpers it uses. The last remaining "single" stub will soon be dropped as well.
sean: rewrite changelog and comment, tag for stable, remove defunct stubs
In the Linux kernel, the following vulnerability has been resolved:
erofs: fix the out-of-bounds nameoff handling for trailing dirents
Currently we already have boundary-checks for nameoffs, but the trailing dirents are special since the namelens are calculated with strnlen() with unchecked nameoffs.
If a crafted EROFS has a trailing dirent with nameoff >= maxsize, maxsize - nameoff can underflow, causing strnlen() to read past the directory block.
nameoff0 should also be verified to be a multiple of
sizeof(struct erofs_dirent) as well [1].
[1] https://sashiko.dev/#/patchset/20260416063511.3173774-1-hsiangkao%40linux.alibaba.com(CVE-2026-46078)
In the Linux kernel, the following vulnerability has been resolved:
KVM: SVM: Inject #UD for INVLPGA if EFER.SVME=0
INVLPGA should cause a #UD when EFER.SVME is not set. Add a check to properly inject #UD when EFER.SVME=0.
In the Linux kernel, the following vulnerability has been resolved:
mm/vmalloc: take vmap_purge_lock in shrinker
decay_va_pool_node() can be invoked concurrently from two paths: __purge_vmap_area_lazy() when pools are being purged, and the shrinker via vmap_node_shrink_scan().
However, decay_va_pool_node() is not safe to run concurrently, and the shrinker path currently lacks serialization, leading to races and possible leaks.
Protect decay_va_pool_node() by taking vmap_purge_lock in the shrinker path to ensure serialization with purge users.(CVE-2026-46093)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_event: Fix OOB read and infinite loop in hci_le_create_big_complete_evt
hci_le_create_big_complete_evt() iterates over BT_BOUND connections for a BIG handle using a while loop, accessing ev->bis_handle[i++] on each iteration. However, there is no check that i stays within ev->num_bis before the array access.
When a controller sends a LE_Create_BIG_Complete event with fewer bis_handle entries than there are BT_BOUND connections for that BIG, or with num_bis=0, the loop reads beyond the valid bis_handle[] flex array into adjacent heap memory. Since the out-of-bounds values typically exceed HCI_CONN_HANDLE_MAX (0x0EFF), hci_conn_set_handle() rejects them and the connection remains in BT_BOUND state. The same connection is then found again by hci_conn_hash_lookup_big_state(), creating an infinite loop with hci_dev_lock held.
Fix this by terminating the BIG if in case not all BIS could be setup properly.(CVE-2026-46138)
In the Linux kernel, the following vulnerability has been resolved:
openvswitch: vport: fix self-deadlock on release of tunnel ports
vports are used concurrently and protected by RCU, so netdev_put() must happen after the RCU grace period. So, either in an RCU call or after the synchronize_net(). The rtnl_delete_link() must happen under RTNL and so can't be executed in RCU context. Calling synchronize_net() while holding RTNL is not a good idea for performance and system stability under load in general, so calling netdev_put() in RCU call is the right solution here.
However, when the device is deleted, rtnl_unlock() will call netdev_run_todo() and block until all the references are gone. In the current code this means that we never reach the call_rcu() and the vport is never freed and the reference is never released, causing a self-deadlock on device removal.
Fix that by moving the rcu_call() before the rtnl_unlock(), so the scheduled RCU callback will be executed when synchronize_net() is called from the rtnl_unlock()->netdev_run_todo() while the RTNL itself is already released.(CVE-2026-46165)
In the Linux kernel, the following vulnerability has been resolved:
riscv: kvm: fix vector context allocation leak
When the second kzalloc (host_context.vector.datap) fails in kvm_riscv_vcpu_alloc_vector_context, the first allocation (guest_context.vector.datap) is leaked. Free it before returning.(CVE-2026-46171)
In the Linux kernel, the following vulnerability has been resolved:
x86/CPU/AMD: Prevent improper isolation of shared resources in Zen2's op cache
Make sure resources are not improperly shared in the op cache and cause instruction corruption this way.(CVE-2026-46174)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/mlx4: Fix resource leak on error in mlx4_ib_create_srq()
Sashiko points out that mlx4_srq_alloc() was not undone during error unwind, add the missing call to mlx4_srq_free().(CVE-2026-46178)
In the Linux kernel, the following vulnerability has been resolved:
mtd: spi-nor: debugfs: fix out-of-bounds read in spi_nor_params_show()
Sashiko noticed an out-of-bounds read [1].
In spi_nor_params_show(), the snor_f_names array is passed to spi_nor_print_flags() using sizeof(snor_f_names).
Since snor_f_names is an array of pointers, sizeof() returns the total number of bytes occupied by the pointers (element_count * sizeof(void *)) rather than the element count itself. On 64-bit systems, this makes the passed length 8x larger than intended.
Inside spi_nor_print_flags(), the 'names_len' argument is used to bounds-check the 'names' array access. An out-of-bounds read occurs if a flag bit is set that exceeds the array's actual element count but is within the inflated byte-size count.
Correct this by using ARRAY_SIZE() to pass the actual number of string pointers in the array.(CVE-2026-46190)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nft_inner: Fix IPv6 inner_thoff desync
In nft_inner_parse_l2l3(), when processing inner IPv6 packets, ipv6_find_hdr() correctly computes the transport header offset traversing all extension headers, but the result is immediately overwritten with nhoff + sizeof(_ip6h) (40 bytes), which only accounts for the IPv6 base header. This creates a desync between inner_thoff (wrong — points to extension header start) and l4proto (correct — e.g., IPPROTO_TCP), enabling transport header forgery and potential firewall bypass. This issue affects stable versions from Linux 6.2.
For comparison, the normal (non-inner) IPv6 path correctly preserves ipv6_find_hdr()'s result. Removing the incorrect overwrite ensures that ipv6_find_hdr()'s calculated transport header offset is preserved, thereby fixing the desynchronization.(CVE-2026-46244)
In the Linux kernel, the following vulnerability has been resolved:
tap: free page on error paths in tap_get_user_xdp()
tap_get_user_xdp() rejects a frame shorter than ETH_HLEN with -EINVAL, and returns -ENOMEM when build_skb() fails. Both paths jump to the err label without freeing the page that vhost_net_build_xdp() allocated for the frame. tap_sendmsg() discards the per-buffer return value and always returns 0, so vhost_tx_batch() takes the success path and never frees the page; each rejected frame in a batch leaks one page-frag chunk.
Free the page on both error paths, before the skb is built. This is the tap counterpart of the same leak in tun_xdp_one().(CVE-2026-46320)
In the Linux kernel, the following vulnerability has been resolved:
tun: free page on short-frame rejection in tun_xdp_one()
tun_xdp_one() returns -EINVAL on a frame shorter than ETH_HLEN without freeing the page that vhost_net_build_xdp() allocated for it. tun_sendmsg() discards that -EINVAL and still returns total_len, so vhost_tx_batch() takes the success path and never frees the page; each short frame in a batch leaks one page-frag chunk.
A local process that can open /dev/net/tun and /dev/vhost-net can hit this path: it attaches a tun/tap device as the vhost-net backend and feeds TX descriptors whose length minus the virtio-net header is below ETH_HLEN. Each kick leaks the page-frag chunks for that batch, and a tight submission loop exhausts host memory and triggers an OOM panic. Free the page before returning -EINVAL, matching the XDP-program error path in the same function.(CVE-2026-46321)
In the Linux kernel, the following vulnerability has been resolved:
tun: free page on build_skb failure in tun_xdp_one()
When build_skb() fails in tun_xdp_one(), the function sets ret to -ENOMEM and jumps to the out label, which returns without freeing the page that vhost_net_build_xdp() allocated for the frame. As with the short-frame rejection path, tun_sendmsg() discards the per-buffer error and still returns total_len, so vhost_tx_batch() takes the success path and never frees the page. Each build_skb() failure in a batch leaks one page-frag chunk.
Free the page before taking the error path, matching the put_page() the other error exits of tun_xdp_one() already perform.(CVE-2026-46322)
In the Linux kernel, the following vulnerability has been resolved:
net: gro: don't merge zcopy skbs
skb_gro_receive() can currently copy frags between the source and GRO skb, without checking the zerocopy status, and in particular the SKBFL_MANAGED_FRAG_REFS flag.
When SKBFL_MANAGED_FRAG_REFS is set, the skb doesn't hold a reference on the pages in shinfo->frags. Appending those frags to another skb's frags without fixing up the page refcount can lead to UAF.
When either the last skb in the GRO chain (the one we would append frags to) or the source skb is zerocopy, don't merge the skbs.(CVE-2026-46323)
In the Linux kernel, the following vulnerability has been resolved:
Revert "net/smc: Introduce TCP ULP support"
This reverts commit d7cd421da9da2cc7b4d25b8537f66db5c8331c40.
As reported by Al Viro, the TCP ULP support for SMC is fundamentally
broken. The implementation attempts to convert an active TCP socket
into an SMC socket by modifying the underlying struct file, dentry,
and inode in-place, which violates core VFS invariants that assume
these structures are immutable for an open file, creating a risk of
use after free errors and general system instability.
Given the severity of this design flaw and the fact that cleaner alternatives (e.g., LD_PRELOAD, BPF) exist for legacy application transparency, the correct course of action is to remove this feature entirely.(CVE-2026-46330)
| URL | Type | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-6.6.0-145.1.19.156.oe2403sp1.aarch64.rpm",
"bpftool-debuginfo-6.6.0-145.1.19.156.oe2403sp1.aarch64.rpm",
"kernel-6.6.0-145.1.19.156.oe2403sp1.aarch64.rpm",
"kernel-debuginfo-6.6.0-145.1.19.156.oe2403sp1.aarch64.rpm",
"kernel-debugsource-6.6.0-145.1.19.156.oe2403sp1.aarch64.rpm",
"kernel-devel-6.6.0-145.1.19.156.oe2403sp1.aarch64.rpm",
"kernel-headers-6.6.0-145.1.19.156.oe2403sp1.aarch64.rpm",
"kernel-source-6.6.0-145.1.19.156.oe2403sp1.aarch64.rpm",
"kernel-tools-6.6.0-145.1.19.156.oe2403sp1.aarch64.rpm",
"kernel-tools-debuginfo-6.6.0-145.1.19.156.oe2403sp1.aarch64.rpm",
"kernel-tools-devel-6.6.0-145.1.19.156.oe2403sp1.aarch64.rpm",
"perf-6.6.0-145.1.19.156.oe2403sp1.aarch64.rpm",
"perf-debuginfo-6.6.0-145.1.19.156.oe2403sp1.aarch64.rpm",
"python3-perf-6.6.0-145.1.19.156.oe2403sp1.aarch64.rpm",
"python3-perf-debuginfo-6.6.0-145.1.19.156.oe2403sp1.aarch64.rpm"
],
"src": [
"kernel-6.6.0-145.1.19.156.oe2403sp1.src.rpm"
],
"x86_64": [
"bpftool-6.6.0-145.1.19.156.oe2403sp1.x86_64.rpm",
"bpftool-debuginfo-6.6.0-145.1.19.156.oe2403sp1.x86_64.rpm",
"kernel-6.6.0-145.1.19.156.oe2403sp1.x86_64.rpm",
"kernel-debuginfo-6.6.0-145.1.19.156.oe2403sp1.x86_64.rpm",
"kernel-debugsource-6.6.0-145.1.19.156.oe2403sp1.x86_64.rpm",
"kernel-devel-6.6.0-145.1.19.156.oe2403sp1.x86_64.rpm",
"kernel-headers-6.6.0-145.1.19.156.oe2403sp1.x86_64.rpm",
"kernel-source-6.6.0-145.1.19.156.oe2403sp1.x86_64.rpm",
"kernel-tools-6.6.0-145.1.19.156.oe2403sp1.x86_64.rpm",
"kernel-tools-debuginfo-6.6.0-145.1.19.156.oe2403sp1.x86_64.rpm",
"kernel-tools-devel-6.6.0-145.1.19.156.oe2403sp1.x86_64.rpm",
"perf-6.6.0-145.1.19.156.oe2403sp1.x86_64.rpm",
"perf-debuginfo-6.6.0-145.1.19.156.oe2403sp1.x86_64.rpm",
"python3-perf-6.6.0-145.1.19.156.oe2403sp1.x86_64.rpm",
"python3-perf-debuginfo-6.6.0-145.1.19.156.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.19.156.oe2403sp1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "Critical"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nArm C1-Ultra, C1-Premium, Neoverse V3 \u0026amp; V3AE, Neoverse V2, Neoverse V1, Neoverse-N2, Neoverse-N1, Cortex-X925, Cortex-X4, Cortex-X3, Cortex-X2, Cortex-X1 \u0026amp; X1C, Cortex-A710, Cortex-A78, A78AE \u0026amp; A78C, Cortex-A77, Cortex-A76 \u0026amp; A76A may allow writes to resources owned by a higher exception level.(CVE-2025-10263)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: let smbd_destroy() call disable_work_sync(\u0026amp;info-\u0026gt;post_send_credits_work)\n\nIn smbd_destroy() we may destroy the memory so we better\nwait until post_send_credits_work is no longer pending\nand will never be started again.\n\nI actually just hit the case using rxe:\n\nWARNING: CPU: 0 PID: 138 at drivers/infiniband/sw/rxe/rxe_verbs.c:1032 rxe_post_recv+0x1ee/0x480 [rdma_rxe]\n...\n[ 5305.686979] [ T138] smbd_post_recv+0x445/0xc10 [cifs]\n[ 5305.687135] [ T138] ? srso_alias_return_thunk+0x5/0xfbef5\n[ 5305.687149] [ T138] ? __kasan_check_write+0x14/0x30\n[ 5305.687185] [ T138] ? __pfx_smbd_post_recv+0x10/0x10 [cifs]\n[ 5305.687329] [ T138] ? __pfx__raw_spin_lock_irqsave+0x10/0x10\n[ 5305.687356] [ T138] ? srso_alias_return_thunk+0x5/0xfbef5\n[ 5305.687368] [ T138] ? srso_alias_return_thunk+0x5/0xfbef5\n[ 5305.687378] [ T138] ? _raw_spin_unlock_irqrestore+0x11/0x60\n[ 5305.687389] [ T138] ? srso_alias_return_thunk+0x5/0xfbef5\n[ 5305.687399] [ T138] ? get_receive_buffer+0x168/0x210 [cifs]\n[ 5305.687555] [ T138] smbd_post_send_credits+0x382/0x4b0 [cifs]\n[ 5305.687701] [ T138] ? __pfx_smbd_post_send_credits+0x10/0x10 [cifs]\n[ 5305.687855] [ T138] ? __pfx___schedule+0x10/0x10\n[ 5305.687865] [ T138] ? __pfx__raw_spin_lock_irq+0x10/0x10\n[ 5305.687875] [ T138] ? queue_delayed_work_on+0x8e/0xa0\n[ 5305.687889] [ T138] process_one_work+0x629/0xf80\n[ 5305.687908] [ T138] ? srso_alias_return_thunk+0x5/0xfbef5\n[ 5305.687917] [ T138] ? __kasan_check_write+0x14/0x30\n[ 5305.687933] [ T138] worker_thread+0x87f/0x1570\n...\n\nIt means rxe_post_recv was called after rdma_destroy_qp().\nThis happened because put_receive_buffer() was triggered\nby ib_drain_qp() and called:\nqueue_work(info-\u0026gt;workqueue, \u0026amp;info-\u0026gt;post_send_credits_work);(CVE-2025-39932)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nMIPS: ftrace: Fix memory corruption when kernel is located beyond 32 bits\n\nSince commit e424054000878 (\u0026quot;MIPS: Tracing: Reduce the overhead of\ndynamic Function Tracer\u0026quot;), the macro UASM_i_LA_mostly has been used,\nand this macro can generate more than 2 instructions. At the same\ntime, the code in ftrace assumes that no more than 2 instructions can\nbe generated, which is why it stores them in an int[2] array. However,\nas previously noted, the macro UASM_i_LA_mostly (and now UASM_i_LA)\ncauses a buffer overflow when _mcount is beyond 32 bits. This leads to\ncorruption of the variables located in the __read_mostly section.\n\nThis corruption was observed because the variable\n__cpu_primary_thread_mask was corrupted, causing a hang very early\nduring boot.\n\nThis fix prevents the corruption by avoiding the generation of\ninstructions if they could exceed 2 instructions in\nlength. Fortunately, insn_la_mcount is only used if the instrumented\ncode is located outside the kernel code section, so dynamic ftrace can\nstill be used, albeit in a more limited scope. This is still\npreferable to corrupting memory and/or crashing the kernel.(CVE-2025-71109)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nriscv: Sanitize syscall table indexing under speculation\n\nThe syscall number is a user-controlled value used to index into the\nsyscall table. Use array_index_nospec() to clamp this value after the\nbounds check to prevent speculative out-of-bounds access and subsequent\ndata leakage via cache side channels.(CVE-2025-71203)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/pm: Disable MMIO access during SMU Mode 1 reset\n\nDuring Mode 1 reset, the ASIC undergoes a reset cycle and becomes\ntemporarily inaccessible via PCIe. Any attempt to access MMIO registers\nduring this window (e.g., from interrupt handlers or other driver threads)\ncan result in uncompleted PCIe transactions, leading to NMI panics or\nsystem hangs.\n\nTo prevent this, set the `no_hw_access` flag to true immediately after\ntriggering the reset. This signals other driver components to skip\nregister accesses while the device is offline.\n\nA memory barrier `smp_mb()` is added to ensure the flag update is\nglobally visible to all cores before the driver enters the sleep/wait\nstate.\n\n(cherry picked from commit 7edb503fe4b6d67f47d8bb0dfafb8e699bb0f8a4)(CVE-2026-23213)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: reject new transactions if the fs is fully read-only\n\n[BUG]\nThere is a bug report where a heavily fuzzed fs is mounted with all\nrescue mount options, which leads to the following warnings during\nunmount:\n\n BTRFS: Transaction aborted (error -22)\n Modules linked in:\n CPU: 0 UID: 0 PID: 9758 Comm: repro.out Not tainted\n 6.19.0-rc5-00002-gb71e635feefc #7 PREEMPT(full)\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014\n RIP: 0010:find_free_extent_update_loop fs/btrfs/extent-tree.c:4208 [inline]\n RIP: 0010:find_free_extent+0x52f0/0x5d20 fs/btrfs/extent-tree.c:4611\n Call Trace:\n \u0026lt;TASK\u0026gt;\n btrfs_reserve_extent+0x2cd/0x790 fs/btrfs/extent-tree.c:4705\n btrfs_alloc_tree_block+0x1e1/0x10e0 fs/btrfs/extent-tree.c:5157\n btrfs_force_cow_block+0x578/0x2410 fs/btrfs/ctree.c:517\n btrfs_cow_block+0x3c4/0xa80 fs/btrfs/ctree.c:708\n btrfs_search_slot+0xcad/0x2b50 fs/btrfs/ctree.c:2130\n btrfs_truncate_inode_items+0x45d/0x2350 fs/btrfs/inode-item.c:499\n btrfs_evict_inode+0x923/0xe70 fs/btrfs/inode.c:5628\n evict+0x5f4/0xae0 fs/inode.c:837\n __dentry_kill+0x209/0x660 fs/dcache.c:670\n finish_dput+0xc9/0x480 fs/dcache.c:879\n shrink_dcache_for_umount+0xa0/0x170 fs/dcache.c:1661\n generic_shutdown_super+0x67/0x2c0 fs/super.c:621\n kill_anon_super+0x3b/0x70 fs/super.c:1289\n btrfs_kill_super+0x41/0x50 fs/btrfs/super.c:2127\n deactivate_locked_super+0xbc/0x130 fs/super.c:474\n cleanup_mnt+0x425/0x4c0 fs/namespace.c:1318\n task_work_run+0x1d4/0x260 kernel/task_work.c:233\n exit_task_work include/linux/task_work.h:40 [inline]\n do_exit+0x694/0x22f0 kernel/exit.c:971\n do_group_exit+0x21c/0x2d0 kernel/exit.c:1112\n __do_sys_exit_group kernel/exit.c:1123 [inline]\n __se_sys_exit_group kernel/exit.c:1121 [inline]\n __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1121\n x64_sys_call+0x2210/0x2210 arch/x86/include/generated/asm/syscalls_64.h:232\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xe8/0xf80 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n RIP: 0033:0x44f639\n Code: Unable to access opcode bytes at 0x44f60f.\n RSP: 002b:00007ffc15c4e088 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7\n RAX: ffffffffffffffda RBX: 00000000004c32f0 RCX: 000000000044f639\n RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000001\n RBP: 0000000000000001 R08: ffffffffffffffc0 R09: 0000000000000000\n R10: 0000000000000000 R11: 0000000000000246 R12: 00000000004c32f0\n R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000001\n \u0026lt;/TASK\u0026gt;\n\nSince rescue mount options will mark the full fs read-only, there should\nbe no new transaction triggered.\n\nBut during unmount we will evict all inodes, which can trigger a new\ntransaction, and triggers warnings on a heavily corrupted fs.\n\n[CAUSE]\nBtrfs allows new transaction even on a read-only fs, this is to allow\nlog replay happen even on read-only mounts, just like what ext4/xfs do.\n\nHowever with rescue mount options, the fs is fully read-only and cannot\nbe remounted read-write, thus in that case we should also reject any new\ntransactions.\n\n[FIX]\nIf we find the fs has rescue mount options, we should treat the fs as\nerror, so that no new transaction can be started.(CVE-2026-23214)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvme-fc: release admin tagset if init fails\n\nnvme_fabrics creates an NVMe/FC controller in following path:\n\n nvmf_dev_write()\n -\u0026gt; nvmf_create_ctrl()\n -\u0026gt; nvme_fc_create_ctrl()\n -\u0026gt; nvme_fc_init_ctrl()\n\nnvme_fc_init_ctrl() allocates the admin blk-mq resources right after\nnvme_add_ctrl() succeeds. If any of the subsequent steps fail (changing\nthe controller state, scheduling connect work, etc.), we jump to the\nfail_ctrl path, which tears down the controller references but never\nfrees the admin queue/tag set. The leaked blk-mq allocations match the\nkmemleak report seen during blktests nvme/fc.\n\nCheck ctrl-\u0026gt;ctrl.admin_tagset in the fail_ctrl path and call\nnvme_remove_admin_tag_set() when it is set so that all admin queue\nallocations are reclaimed whenever controller setup aborts.(CVE-2026-23261)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_conntrack_expect: use expect-\u0026gt;helper\n\nUse expect-\u0026gt;helper in ctnetlink and /proc to dump the helper name.\nUsing nfct_help() without holding a reference to the master conntrack\nis unsafe.\n\nUse exp-\u0026gt;master-\u0026gt;helper in ctnetlink path if userspace does not provide\nan explicit helper when creating an expectation to retain the existing\nbehaviour. The ctnetlink expectation path holds the reference on the\nmaster conntrack and nf_conntrack_expect lock and the nfnetlink glue\npath refers to the master ct that is attached to the skb.(CVE-2026-31414)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix OOB write in QUERY_INFO for compound requests\n\nWhen a compound request such as READ + QUERY_INFO(Security) is received,\nand the first command (READ) consumes most of the response buffer,\nksmbd could write beyond the allocated buffer while building a security\ndescriptor.\n\nThe root cause was that smb2_get_info_sec() checked buffer space using\nppntsd_size from xattr, while build_sec_desc() often synthesized a\nsignificantly larger descriptor from POSIX ACLs.\n\nThis patch introduces smb_acl_sec_desc_scratch_len() to accurately\ncompute the final descriptor size beforehand, performs proper buffer\nchecking with smb2_calc_max_out_buf_len(), and uses exact-sized\nallocation + iov pinning.(CVE-2026-31432)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: idxd: Fix leaking event log memory\n\nDuring the device remove process, the device is reset, causing the\nconfiguration registers to go back to their default state, which is\nzero. As the driver is checking if the event log support was enabled\nbefore deallocating, it will fail if a reset happened before.\n\nDo not check if the support was enabled, the check for \u0026apos;idxd-\u0026gt;evl\u0026apos;\nbeing valid (only allocated if the HW capability is available) is\nenough.(CVE-2026-31440)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: idxd: Fix crash when the event log is disabled\n\nIf reporting errors to the event log is not supported by the hardware,\nand an error that causes Function Level Reset (FLR) is received, the\ndriver will try to restore the event log even if it was not allocated.\n\nAlso, only try to free the event log if it was properly allocated.(CVE-2026-31443)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfs: avoid dereferencing log items after push callbacks\n\nAfter xfsaild_push_item() calls iop_push(), the log item may have been\nfreed if the AIL lock was dropped during the push. Background inode\nreclaim or the dquot shrinker can free the log item while the AIL lock\nis not held, and the tracepoints in the switch statement dereference\nthe log item after iop_push() returns.\n\nFix this by capturing the log item type, flags, and LSN before calling\nxfsaild_push_item(), and introducing a new xfs_ail_push_class trace\nevent class that takes these pre-captured values and the ailp pointer\ninstead of the log item pointer.(CVE-2026-31453)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv4: nexthop: allocate skb dynamically in rtm_get_nexthop()\n\nWhen querying a nexthop object via RTM_GETNEXTHOP, the kernel currently\nallocates a fixed-size skb using NLMSG_GOODSIZE. While sufficient for\nsingle nexthops and small Equal-Cost Multi-Path groups, this fixed\nallocation fails for large nexthop groups like 512 nexthops.\n\nThis results in the following warning splat:\n\n WARNING: net/ipv4/nexthop.c:3395 at rtm_get_nexthop+0x176/0x1c0, CPU#20: rep/4608\n [...]\n RIP: 0010:rtm_get_nexthop (net/ipv4/nexthop.c:3395)\n [...]\n Call Trace:\n \u0026lt;TASK\u0026gt;\n rtnetlink_rcv_msg (net/core/rtnetlink.c:6989)\n netlink_rcv_skb (net/netlink/af_netlink.c:2550)\n netlink_unicast (net/netlink/af_netlink.c:1319 net/netlink/af_netlink.c:1344)\n netlink_sendmsg (net/netlink/af_netlink.c:1894)\n ____sys_sendmsg (net/socket.c:721 net/socket.c:736 net/socket.c:2585)\n ___sys_sendmsg (net/socket.c:2641)\n __sys_sendmsg (net/socket.c:2671)\n do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94)\n entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)\n \u0026lt;/TASK\u0026gt;\n\nFix this by allocating the size dynamically using nh_nlmsg_size() and\nusing nlmsg_new(), this is consistent with nexthop_notify() behavior. In\naddition, adjust nh_nlmsg_size_grp() so it calculates the size needed\nbased on flags passed. While at it, also add the size of NHA_FDB for\nnexthop group size calculation as it was missing too.\n\nThis cannot be reproduced via iproute2 as the group size is currently\nlimited and the command fails as follows:\n\naddattr_l ERROR: message exceeded bound of 1048(CVE-2026-31531)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mac80211: Fix static_branch_dec() underflow for aql_disable.\n\nsyzbot reported static_branch_dec() underflow in aql_enable_write(). [0]\n\nThe problem is that aql_enable_write() does not serialise concurrent\nwrite()s to the debugfs.\n\naql_enable_write() checks static_key_false(\u0026amp;aql_disable.key) and\nlater calls static_branch_inc() or static_branch_dec(), but the\nstate may change between the two calls.\n\naql_disable does not need to track inc/dec.\n\nLet\u0026apos;s use static_branch_enable() and static_branch_disable().\n\n[0]:\nval == 0\nWARNING: kernel/jump_label.c:311 at __static_key_slow_dec_cpuslocked.part.0+0x107/0x120 kernel/jump_label.c:311, CPU#0: syz.1.3155/20288\nModules linked in:\nCPU: 0 UID: 0 PID: 20288 Comm: syz.1.3155 Tainted: G U L syzkaller #0 PREEMPT(full)\nTainted: [U]=USER, [L]=SOFTLOCKUP\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/24/2026\nRIP: 0010:__static_key_slow_dec_cpuslocked.part.0+0x107/0x120 kernel/jump_label.c:311\nCode: f2 c9 ff 5b 5d c3 cc cc cc cc e8 54 f2 c9 ff 48 89 df e8 ac f9 ff ff eb ad e8 45 f2 c9 ff 90 0f 0b 90 eb a2 e8 3a f2 c9 ff 90 \u0026lt;0f\u0026gt; 0b 90 eb 97 48 89 df e8 5c 4b 33 00 e9 36 ff ff ff 0f 1f 80 00\nRSP: 0018:ffffc9000b9f7c10 EFLAGS: 00010293\nRAX: 0000000000000000 RBX: ffffffff9b3e5d40 RCX: ffffffff823c57b4\nRDX: ffff8880285a0000 RSI: ffffffff823c5846 RDI: ffff8880285a0000\nRBP: 0000000000000000 R08: 0000000000000005 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000000 R12: 000000000000000a\nR13: 1ffff9200173ef88 R14: 0000000000000001 R15: ffffc9000b9f7e98\nFS: 00007f530dd726c0(0000) GS:ffff8881245e3000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000200000001140 CR3: 000000007cc4a000 CR4: 00000000003526f0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __static_key_slow_dec_cpuslocked kernel/jump_label.c:297 [inline]\n __static_key_slow_dec kernel/jump_label.c:321 [inline]\n static_key_slow_dec+0x7c/0xc0 kernel/jump_label.c:336\n aql_enable_write+0x2b2/0x310 net/mac80211/debugfs.c:343\n short_proxy_write+0x133/0x1a0 fs/debugfs/file.c:383\n vfs_write+0x2aa/0x1070 fs/read_write.c:684\n ksys_pwrite64 fs/read_write.c:793 [inline]\n __do_sys_pwrite64 fs/read_write.c:801 [inline]\n __se_sys_pwrite64 fs/read_write.c:798 [inline]\n __x64_sys_pwrite64+0x1eb/0x250 fs/read_write.c:798\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xc9/0xf80 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7f530cf9aeb9\nCode: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007f530dd72028 EFLAGS: 00000246 ORIG_RAX: 0000000000000012\nRAX: ffffffffffffffda RBX: 00007f530d215fa0 RCX: 00007f530cf9aeb9\nRDX: 0000000000000003 RSI: 0000000000000000 RDI: 0000000000000010\nRBP: 00007f530d008c1f R08: 0000000000000000 R09: 0000000000000000\nR10: 4200000000000005 R11: 0000000000000246 R12: 0000000000000000\nR13: 00007f530d216038 R14: 00007f530d215fa0 R15: 00007ffde89fb978\n \u0026lt;/TASK\u0026gt;(CVE-2026-31551)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvmet: move async event work off nvmet-wq\n\nFor target nvmet_ctrl_free() flushes ctrl-\u0026gt;async_event_work.\nIf nvmet_ctrl_free() runs on nvmet-wq, the flush re-enters workqueue\ncompletion for the same worker:-\n\nA. Async event work queued on nvmet-wq (prior to disconnect):\n nvmet_execute_async_event()\n queue_work(nvmet_wq, \u0026amp;ctrl-\u0026gt;async_event_work)\n\n nvmet_add_async_event()\n queue_work(nvmet_wq, \u0026amp;ctrl-\u0026gt;async_event_work)\n\nB. Full pre-work chain (RDMA CM path):\n nvmet_rdma_cm_handler()\n nvmet_rdma_queue_disconnect()\n __nvmet_rdma_queue_disconnect()\n queue_work(nvmet_wq, \u0026amp;queue-\u0026gt;release_work)\n process_one_work()\n lock((wq_completion)nvmet-wq) \u0026lt;--------- 1st\n nvmet_rdma_release_queue_work()\n\nC. Recursive path (same worker):\n nvmet_rdma_release_queue_work()\n nvmet_rdma_free_queue()\n nvmet_sq_destroy()\n nvmet_ctrl_put()\n nvmet_ctrl_free()\n flush_work(\u0026amp;ctrl-\u0026gt;async_event_work)\n __flush_work()\n touch_wq_lockdep_map()\n lock((wq_completion)nvmet-wq) \u0026lt;--------- 2nd\n\nLockdep splat:\n\n ============================================\n WARNING: possible recursive locking detected\n 6.19.0-rc3nvme+ #14 Tainted: G N\n --------------------------------------------\n kworker/u192:42/44933 is trying to acquire lock:\n ffff888118a00948 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: touch_wq_lockdep_map+0x26/0x90\n\n but task is already holding lock:\n ffff888118a00948 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: process_one_work+0x53e/0x660\n\n 3 locks held by kworker/u192:42/44933:\n #0: ffff888118a00948 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: process_one_work+0x53e/0x660\n #1: ffffc9000e6cbe28 ((work_completion)(\u0026amp;queue-\u0026gt;release_work)){+.+.}-{0:0}, at: process_one_work+0x1c5/0x660\n #2: ffffffff82d4db60 (rcu_read_lock){....}-{1:3}, at: __flush_work+0x62/0x530\n\n Workqueue: nvmet-wq nvmet_rdma_release_queue_work [nvmet_rdma]\n Call Trace:\n __flush_work+0x268/0x530\n nvmet_ctrl_free+0x140/0x310 [nvmet]\n nvmet_cq_put+0x74/0x90 [nvmet]\n nvmet_rdma_free_queue+0x23/0xe0 [nvmet_rdma]\n nvmet_rdma_release_queue_work+0x19/0x50 [nvmet_rdma]\n process_one_work+0x206/0x660\n worker_thread+0x184/0x320\n kthread+0x10c/0x240\n ret_from_fork+0x319/0x390\n\nMove async event work to a dedicated nvmet-aen-wq to avoid reentrant\nflush on nvmet-wq.(CVE-2026-31557)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbcache: fix cached_dev.sb_bio use-after-free and crash\n\nIn our production environment, we have received multiple crash reports\nregarding libceph, which have caught our attention:\n\n```\n[6888366.280350] Call Trace:\n[6888366.280452] blk_update_request+0x14e/0x370\n[6888366.280561] blk_mq_end_request+0x1a/0x130\n[6888366.280671] rbd_img_handle_request+0x1a0/0x1b0 [rbd]\n[6888366.280792] rbd_obj_handle_request+0x32/0x40 [rbd]\n[6888366.280903] __complete_request+0x22/0x70 [libceph]\n[6888366.281032] osd_dispatch+0x15e/0xb40 [libceph]\n[6888366.281164] ? inet_recvmsg+0x5b/0xd0\n[6888366.281272] ? ceph_tcp_recvmsg+0x6f/0xa0 [libceph]\n[6888366.281405] ceph_con_process_message+0x79/0x140 [libceph]\n[6888366.281534] ceph_con_v1_try_read+0x5d7/0xf30 [libceph]\n[6888366.281661] ceph_con_workfn+0x329/0x680 [libceph]\n```\n\nAfter analyzing the coredump file, we found that the address of\ndc-\u0026gt;sb_bio has been freed. We know that cached_dev is only freed when it\nis stopped.\n\nSince sb_bio is a part of struct cached_dev, rather than an alloc every\ntime. If the device is stopped while writing to the superblock, the\nreleased address will be accessed at endio.\n\nThis patch hopes to wait for sb_write to complete in cached_dev_free.\n\nIt should be noted that we analyzed the cause of the problem, then tell\nall details to the QWEN and adopted the modifications it made.(CVE-2026-31580)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: x86: Use scratch field in MMIO fragment to hold small write values\n\nWhen exiting to userspace to service an emulated MMIO write, copy the\nto-be-written value to a scratch field in the MMIO fragment if the size\nof the data payload is 8 bytes or less, i.e. can fit in a single chunk,\ninstead of pointing the fragment directly at the source value.\n\nThis fixes a class of use-after-free bugs that occur when the emulator\ninitiates a write using an on-stack, local variable as the source, the\nwrite splits a page boundary, *and* both pages are MMIO pages. Because\nKVM\u0026apos;s ABI only allows for physically contiguous MMIO requests, accesses\nthat split MMIO pages are separated into two fragments, and are sent to\nuserspace one at a time. When KVM attempts to complete userspace MMIO in\nresponse to KVM_RUN after the first fragment, KVM will detect the second\nfragment and generate a second userspace exit, and reference the on-stack\nvariable.\n\nThe issue is most visible if the second KVM_RUN is performed by a separate\ntask, in which case the stack of the initiating task can show up as truly\nfreed data.\n\n ==================================================================\n BUG: KASAN: use-after-free in complete_emulated_mmio+0x305/0x420\n Read of size 1 at addr ffff888009c378d1 by task syz-executor417/984\n\n CPU: 1 PID: 984 Comm: syz-executor417 Not tainted 5.10.0-182.0.0.95.h2627.eulerosv2r13.x86_64 #3\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 Call Trace:\n dump_stack+0xbe/0xfd\n print_address_description.constprop.0+0x19/0x170\n __kasan_report.cold+0x6c/0x84\n kasan_report+0x3a/0x50\n check_memory_region+0xfd/0x1f0\n memcpy+0x20/0x60\n complete_emulated_mmio+0x305/0x420\n kvm_arch_vcpu_ioctl_run+0x63f/0x6d0\n kvm_vcpu_ioctl+0x413/0xb20\n __se_sys_ioctl+0x111/0x160\n do_syscall_64+0x30/0x40\n entry_SYSCALL_64_after_hwframe+0x67/0xd1\n RIP: 0033:0x42477d\n Code: \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48\n RSP: 002b:00007faa8e6890e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010\n RAX: ffffffffffffffda RBX: 00000000004d7338 RCX: 000000000042477d\n RDX: 0000000000000000 RSI: 000000000000ae80 RDI: 0000000000000005\n RBP: 00000000004d7330 R08: 00007fff28d546df R09: 0000000000000000\n R10: 0000000000000000 R11: 0000000000000246 R12: 00000000004d733c\n R13: 0000000000000000 R14: 000000000040a200 R15: 00007fff28d54720\n\n The buggy address belongs to the page:\n page:0000000029f6a428 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x9c37\n flags: 0xfffffc0000000(node=0|zone=1|lastcpupid=0x1fffff)\n raw: 000fffffc0000000 0000000000000000 ffffea0000270dc8 0000000000000000\n raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected\n\n Memory state around the buggy address:\n ffff888009c37780: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff\n ffff888009c37800: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff\n \u0026gt;ffff888009c37880: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff\n ^\n ffff888009c37900: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff\n ffff888009c37980: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff\n ==================================================================\n\nThe bug can also be reproduced with a targeted KVM-Unit-Test by hacking\nKVM to fill a large on-stack variable in complete_emulated_mmio(), i.e. by\noverwrite the data value with garbage.\n\nLimit the use of the scratch fields to 8-byte or smaller accesses, and to\njust writes, as larger accesses and reads are not affected thanks to\nimplementation details in the emulator, but add a sanity check to ensure\nthose details don\u0026apos;t change in the future. Specifically, KVM never uses\non-stack variables for accesses larger that 8 bytes, e.g. uses an operand\nin the emulator context, and *al\n---truncated---(CVE-2026-31588)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntipc: fix bc_ackers underflow on duplicate GRP_ACK_MSG\n\nThe GRP_ACK_MSG handler in tipc_group_proto_rcv() currently decrements\nbc_ackers on every inbound group ACK, even when the same member has\nalready acknowledged the current broadcast round.\n\nBecause bc_ackers is a u16, a duplicate ACK received after the last\nlegitimate ACK wraps the counter to 65535. Once wrapped,\ntipc_group_bc_cong() keeps reporting congestion and later group\nbroadcasts on the affected socket stay blocked until the group is\nrecreated.\n\nFix this by ignoring duplicate or stale ACKs before touching bc_acked or\nbc_ackers. This makes repeated GRP_ACK_MSG handling idempotent and\nprevents the underflow path.(CVE-2026-31662)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: clear trailing padding in build_polexpire()\n\nbuild_expire() clears the trailing padding bytes of struct\nxfrm_user_expire after setting the hard field via memset_after(),\nbut the analogous function build_polexpire() does not do this for\nstruct xfrm_user_polexpire.\n\nThe padding bytes after the __u8 hard field are left\nuninitialized from the heap allocation, and are then sent to\nuserspace via netlink multicast to XFRMNLGRP_EXPIRE listeners,\nleaking kernel heap memory contents.\n\nAdd the missing memset_after() call, matching build_expire().(CVE-2026-31664)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: xt_multiport: validate range encoding in checkentry\n\nports_match_v1() treats any non-zero pflags entry as the start of a\nport range and unconditionally consumes the next ports[] element as\nthe range end.\n\nThe checkentry path currently validates protocol, flags and count, but\nit does not validate the range encoding itself. As a result, malformed\nrules can mark the last slot as a range start or place two range starts\nback to back, leaving ports_match_v1() to step past the last valid\nports[] element while interpreting the rule.\n\nReject malformed multiport v1 rules in checkentry by validating that\neach range start has a following element and that the following element\nis not itself marked as another range start.(CVE-2026-31681)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: validate owner of durable handle on reconnect\n\nCurrently, ksmbd does not verify if the user attempting to reconnect\nto a durable handle is the same user who originally opened the file.\nThis allows any authenticated user to hijack an orphaned durable handle\nby predicting or brute-forcing the persistent ID.\n\nAccording to MS-SMB2, the server MUST verify that the SecurityContext\nof the reconnect request matches the SecurityContext associated with\nthe existing open.\nAdd a durable_owner structure to ksmbd_file to store the original opener\u0026apos;s\nUID, GID, and account name. and catpure the owner information when a file\nhandle becomes orphaned. and implementing ksmbd_vfs_compare_durable_owner()\nto validate the identity of the requester during SMB2_CREATE (DHnC).(CVE-2026-31717)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: gadget: f_ecm: Fix net_device lifecycle with device_move\n\nThe net_device is allocated during function instance creation and\nregistered during the bind phase with the gadget device as its sysfs\nparent. When the function unbinds, the parent device is destroyed, but\nthe net_device survives, resulting in dangling sysfs symlinks:\n\n console:/ # ls -l /sys/class/net/usb0\n lrwxrwxrwx ... /sys/class/net/usb0 -\u0026gt;\n /sys/devices/platform/.../gadget.0/net/usb0\n console:/ # ls -l /sys/devices/platform/.../gadget.0/net/usb0\n ls: .../gadget.0/net/usb0: No such file or directory\n\nUse device_move() to reparent the net_device between the gadget device\ntree and /sys/devices/virtual across bind and unbind cycles. During the\nfinal unbind, calling device_move(NULL) moves the net_device to the\nvirtual device tree before the gadget device is destroyed. On rebinding,\ndevice_move() reparents the device back under the new gadget, ensuring\nproper sysfs topology and power management ordering.\n\nTo maintain compatibility with legacy composite drivers (e.g., multi.c),\nthe bound flag is used to indicate whether the network device is shared\nand pre-registered during the legacy driver\u0026apos;s bind phase.(CVE-2026-31725)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: ulpi: fix double free in ulpi_register_interface() error path\n\nWhen device_register() fails, ulpi_register() calls put_device() on\nulpi-\u0026gt;dev.\n\nThe device release callback ulpi_dev_release() drops the OF node\nreference and frees ulpi, but the current error path in\nulpi_register_interface() then calls kfree(ulpi) again, causing a\ndouble free.\n\nLet put_device() handle the cleanup through ulpi_dev_release() and\navoid freeing ulpi again in ulpi_register_interface().(CVE-2026-31759)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_sync: hci_cmd_sync_queue_once() return -EEXIST if exists\n\nhci_cmd_sync_queue_once() needs to indicate whether a queue item was\nadded, so caller can know if callbacks are called, so it can avoid\nleaking resources.\n\nChange the function to return -EEXIST if queue item already exists.\n\nModify all callsites to handle that.(CVE-2026-43022)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: ctnetlink: ignore explicit helper on new expectations\n\nUse the existing master conntrack helper, anything else is not really\nsupported and it just makes validation more complicated, so just ignore\nwhat helper userspace suggests for this expectation.\n\nThis was uncovered when validating CTA_EXPECT_CLASS via different helper\nprovided by userspace than the existing master conntrack helper:\n\n BUG: KASAN: slab-out-of-bounds in nf_ct_expect_related_report+0x2479/0x27c0\n Read of size 4 at addr ffff8880043fe408 by task poc/102\n Call Trace:\n nf_ct_expect_related_report+0x2479/0x27c0\n ctnetlink_create_expect+0x22b/0x3b0\n ctnetlink_new_expect+0x4bd/0x5c0\n nfnetlink_rcv_msg+0x67a/0x950\n netlink_rcv_skb+0x120/0x350\n\nAllowing to read kernel memory bytes off the expectation boundary.\n\nCTA_EXPECT_HELP_NAME is still used to offer the helper name to userspace\nvia netlink dump.(CVE-2026-43025)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: ctnetlink: zero expect NAT fields when CTA_EXPECT_NAT absent\n\nctnetlink_alloc_expect() allocates expectations from a non-zeroing\nslab cache via nf_ct_expect_alloc(). When CTA_EXPECT_NAT is not\npresent in the netlink message, saved_addr and saved_proto are\nnever initialized. Stale data from a previous slab occupant can\nthen be dumped to userspace by ctnetlink_exp_dump_expect(), which\nchecks these fields to decide whether to emit CTA_EXPECT_NAT.\n\nThe safe sibling nf_ct_expect_init(), used by the packet path,\nexplicitly zeroes these fields.\n\nZero saved_addr, saved_proto and dir in the else branch, guarded\nby IS_ENABLED(CONFIG_NF_NAT) since these fields only exist when\nNAT is enabled.\n\nConfirmed by priming the expect slab with NAT-bearing expectations,\nfreeing them, creating a new expectation without CTA_EXPECT_NAT,\nand observing that the ctnetlink dump emits a spurious\nCTA_EXPECT_NAT containing stale data from the prior allocation.(CVE-2026-43026)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: x_tables: ensure names are nul-terminated\n\nReject names that lack a \\0 character before feeding them\nto functions that expect c-strings.\n\nFixes tag is the most recent commit that needs this change.(CVE-2026-43028)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: ioam6: fix OOB and missing lock\n\nWhen trace-\u0026gt;type.bit6 is set:\n\n if (trace-\u0026gt;type.bit6) {\n ...\n queue = skb_get_tx_queue(dev, skb);\n qdisc = rcu_dereference(queue-\u0026gt;qdisc);\n\nThis code can lead to an out-of-bounds access of the dev-\u0026gt;_tx[] array\nwhen is_input is true. In such a case, the packet is on the RX path and\nskb-\u0026gt;queue_mapping contains the RX queue index of the ingress device. If\nthe ingress device has more RX queues than the egress device (dev) has\nTX queues, skb_get_queue_mapping(skb) will exceed dev-\u0026gt;num_tx_queues.\nAdd a check to avoid this situation since skb_get_tx_queue() does not\nclamp the index. This issue has also revealed that per queue visibility\ncannot be accurate and will be replaced later as a new feature.\n\nWhile at it, add missing lock around qdisc_qstats_qlen_backlog(). The\nfunction __ioam6_fill_trace_data() is called from both softirq and\nprocess contexts, hence the use of spin_lock_bh() here.(CVE-2026-43083)\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\nipv4: icmp: fix null-ptr-deref in icmp_build_probe()\n\nipv6_stub-\u0026gt;ipv6_dev_find() may return ERR_PTR(-EAFNOSUPPORT) when the\nIPv6 stack is not active (CONFIG_IPV6=m and not loaded), and passing\nthis error pointer to dev_hold() will cause a kernel crash with\nnull-ptr-deref.\n\nInstead, silently discard the request. RFC 8335 does not appear to\ndefine a specific response for the case where an IPv6 interface\nidentifier is syntactically valid but the implementation cannot perform\nthe lookup at runtime, and silently dropping the request may safer than\nmisreporting \u0026quot;No Such Interface\u0026quot;.(CVE-2026-43099)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: ioam: fix potential NULL dereferences in __ioam6_fill_trace_data()\n\nWe need to check __in6_dev_get() for possible NULL value, as\nsuggested by Yiming Qian.\n\nAlso add skb_dst_dev_rcu() instead of skb_dst_dev(),\nand two missing READ_ONCE().\n\nNote that @dev can\u0026apos;t be NULL.(CVE-2026-43101)\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\nntfs3: fix circular locking dependency in run_unpack_ex\n\nSyzbot reported a circular locking dependency between wnd-\u0026gt;rw_lock\n(sbi-\u0026gt;used.bitmap) and ni-\u0026gt;file.run_lock.\n\nThe deadlock scenario:\n1. ntfs_extend_mft() takes ni-\u0026gt;file.run_lock then wnd-\u0026gt;rw_lock.\n2. run_unpack_ex() takes wnd-\u0026gt;rw_lock then tries to acquire\n ni-\u0026gt;file.run_lock inside ntfs_refresh_zone().\n\nThis creates an AB-BA deadlock.\n\nFix this by using down_read_trylock() instead of down_read() when\nacquiring run_lock in run_unpack_ex(). If the lock is contended,\nskip ntfs_refresh_zone() - the MFT zone will be refreshed on the\nnext MFT operation. This breaks the circular dependency since we\nnever block waiting for run_lock while holding wnd-\u0026gt;rw_lock.(CVE-2026-43127)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: usb: pegasus: enable basic endpoint checking\n\npegasus_probe() fills URBs with hardcoded endpoint pipes without\nverifying the endpoint descriptors:\n\n - usb_rcvbulkpipe(dev, 1) for RX data\n - usb_sndbulkpipe(dev, 2) for TX data\n - usb_rcvintpipe(dev, 3) for status interrupts\n\nA malformed USB device can present these endpoints with transfer types\nthat differ from what the driver assumes.\n\nAdd a pegasus_usb_ep enum for endpoint numbers, replacing magic\nconstants throughout. Add usb_check_bulk_endpoints() and\nusb_check_int_endpoints() calls before any resource allocation to\nverify endpoint types before use, rejecting devices with mismatched\ndescriptors at probe time, and avoid triggering assertion.\n\nSimilar fix to\n- commit 90b7f2961798 (\u0026quot;net: usb: rtl8150: enable basic endpoint checking\u0026quot;)\n- commit 9e7021d2aeae (\u0026quot;net: usb: catc: enable basic endpoint checking\u0026quot;)(CVE-2026-43156)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmd/bitmap: fix GPF in write_page caused by resize race\n\nA General Protection Fault occurs in write_page() during array resize:\nRIP: 0010:write_page+0x22b/0x3c0 [md_mod]\n\nThis is a use-after-free race between bitmap_daemon_work() and\n__bitmap_resize(). The daemon iterates over `bitmap-\u0026gt;storage.filemap`\nwithout locking, while the resize path frees that storage via\nmd_bitmap_file_unmap(). `quiesce()` does not stop the md thread,\nallowing concurrent access to freed pages.\n\nFix by holding `mddev-\u0026gt;bitmap_info.mutex` during the bitmap update.(CVE-2026-43163)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: usb: kaweth: remove TX queue manipulation in kaweth_set_rx_mode\n\nkaweth_set_rx_mode(), the ndo_set_rx_mode callback, calls\nnetif_stop_queue() and netif_wake_queue(). These are TX queue flow\ncontrol functions unrelated to RX multicast configuration.\n\nThe premature netif_wake_queue() can re-enable TX while tx_urb is still\nin-flight, leading to a double usb_submit_urb() on the same URB:\n\nkaweth_start_xmit() {\n netif_stop_queue();\n usb_submit_urb(kaweth-\u0026gt;tx_urb);\n}\n\nkaweth_set_rx_mode() {\n netif_stop_queue();\n netif_wake_queue(); // wakes TX queue before URB is done\n}\n\nkaweth_start_xmit() {\n netif_stop_queue();\n usb_submit_urb(kaweth-\u0026gt;tx_urb); // URB submitted while active\n}\n\nThis triggers the WARN in usb_submit_urb():\n\n \u0026quot;URB submitted while active\u0026quot;\n\nThis is a similar class of bug fixed in rtl8150 by\n\n- commit 958baf5eaee3 (\u0026quot;net: usb: Remove disruptive netif_wake_queue in rtl8150_set_multicast\u0026quot;).\n\nAlso kaweth_set_rx_mode() is already functionally broken, the\nreal set_rx_mode action is performed by kaweth_async_set_rx_mode(),\nwhich in turn is not a no-op only at ndo_open() time.(CVE-2026-43180)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: ioam: fix heap buffer overflow in __ioam6_fill_trace_data()\n\nOn the receive path, __ioam6_fill_trace_data() uses trace-\u0026gt;nodelen\nto decide how much data to write for each node. It trusts this field\nas-is from the incoming packet, with no consistency check against\ntrace-\u0026gt;type (the 24-bit field that tells which data items are\npresent). A crafted packet can set nodelen=0 while setting type bits\n0-21, causing the function to write ~100 bytes past the allocated\nregion (into skb_shared_info), which corrupts adjacent heap memory\nand leads to a kernel panic.\n\nAdd a shared helper ioam6_trace_compute_nodelen() in ioam6.c to\nderive the expected nodelen from the type field, and use it:\n\n - in ioam6_iptunnel.c (send path, existing validation) to replace\n the open-coded computation;\n - in exthdrs.c (receive path, ipv6_hop_ioam) to drop packets whose\n nodelen is inconsistent with the type field, before any data is\n written.\n\nPer RFC 9197, bits 12-21 are each short (4-octet) fields, so they\nare included in IOAM6_MASK_SHORT_FIELDS (changed from 0xff100000 to\n0xff1ffc00).(CVE-2026-43186)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: consume xmit errors of GSO frames\n\nudpgro_frglist.sh and udpgro_bench.sh are the flakiest tests\ncurrently in NIPA. They fail in the same exact way, TCP GRO\ntest stalls occasionally and the test gets killed after 10min.\n\nThese tests use veth to simulate GRO. They attach a trivial\n(\u0026quot;return XDP_PASS;\u0026quot;) XDP program to the veth to force TSO off\nand NAPI on.\n\nDigging into the failure mode we can see that the connection\nis completely stuck after a burst of drops. The sender\u0026apos;s snd_nxt\nis at sequence number N [1], but the receiver claims to have\nreceived (rcv_nxt) up to N + 3 * MSS [2]. Last piece of the puzzle\nis that senders rtx queue is not empty (let\u0026apos;s say the block in\nthe rtx queue is at sequence number N - 4 * MSS [3]).\n\nIn this state, sender sends a retransmission from the rtx queue\nwith a single segment, and sequence numbers N-4*MSS:N-3*MSS [3].\nReceiver sees it and responds with an ACK all the way up to\nN + 3 * MSS [2]. But sender will reject this ack as TCP_ACK_UNSENT_DATA\nbecause it has no recollection of ever sending data that far out [1].\nAnd we are stuck.\n\nThe root cause is the mess of the xmit return codes. veth returns\nan error when it can\u0026apos;t xmit a frame. We end up with a loss event\nlike this:\n\n -------------------------------------------------\n | GSO super frame 1 | GSO super frame 2 |\n |-----------------------------------------------|\n | seg | seg | seg | seg | seg | seg | seg | seg |\n | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 |\n -------------------------------------------------\n x ok ok \u0026lt;ok\u0026gt;| ok ok ok \u0026lt;x\u0026gt;\n \\\\\n\t\t\t snd_nxt\n\n\u0026quot;x\u0026quot; means packet lost by veth, and \u0026quot;ok\u0026quot; means it went thru.\nSince veth has TSO disabled in this test it sees individual segments.\nSegment 1 is on the retransmit queue and will be resent.\n\nSo why did the sender not advance snd_nxt even tho it clearly did\nsend up to seg 8? tcp_write_xmit() interprets the return code\nfrom the core to mean that data has not been sent at all. Since\nTCP deals with GSO super frames, not individual segment the crux\nof the problem is that loss of a single segment can be interpreted\nas loss of all. TCP only sees the last return code for the last\nsegment of the GSO frame (in \u0026lt;\u0026gt; brackets in the diagram above).\n\nOf course for the problem to occur we need a setup or a device\nwithout a Qdisc. Otherwise Qdisc layer disconnects the protocol\nlayer from the device errors completely.\n\nWe have multiple ways to fix this.\n\n 1) make veth not return an error when it lost a packet.\n While this is what I think we did in the past, the issue keeps\n reappearing and it\u0026apos;s annoying to debug. The game of whack\n a mole is not great.\n\n 2) fix the damn return codes\n We only talk about NETDEV_TX_OK and NETDEV_TX_BUSY in the\n documentation, so maybe we should make the return code from\n ndo_start_xmit() a boolean. I like that the most, but perhaps\n some ancient, not-really-networking protocol would suffer.\n\n 3) make TCP ignore the errors\n It is not entirely clear to me what benefit TCP gets from\n interpreting the result of ip_queue_xmit()? Specifically once\n the connection is established and we\u0026apos;re pushing data - packet\n loss is just packet loss?\n\n 4) this fix\n Ignore the rc in the Qdisc-less+GSO case, since it\u0026apos;s unreliable.\n We already always return OK in the TCQ_F_CAN_BYPASS case.\n In the Qdisc-less case let\u0026apos;s be a bit more conservative and only\n mask the GSO errors. This path is taken by non-IP-\u0026quot;networks\u0026quot;\n like CAN, MCTP etc, so we could regress some ancient thing.\n This is the simplest, but also maybe the hackiest fix?\n\nSimilar fix has been proposed by Eric in the past but never committed\nbecause original reporter was working with an OOT driver and wasn\u0026apos;t\nproviding feedback (see Link).(CVE-2026-43194)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetconsole: avoid OOB reads, msg is not nul-terminated\n\nmsg passed to netconsole from the console subsystem is not guaranteed\nto be nul-terminated. Before recent\ncommit 7eab73b18630 (\u0026quot;netconsole: convert to NBCON console infrastructure\u0026quot;)\nthe message would be placed in printk_shared_pbufs, a static global\nbuffer, so KASAN had harder time catching OOB accesses. Now we see:\n\n printk: console [netcon_ext0] enabled\n BUG: KASAN: slab-out-of-bounds in string+0x1f7/0x240\n Read of size 1 at addr ffff88813b6d4c00 by task pr/netcon_ext0/594\n\n CPU: 65 UID: 0 PID: 594 Comm: pr/netcon_ext0 Not tainted 6.19.0-11754-g4246fd6547c9\n Call Trace:\n kasan_report+0xe4/0x120\n string+0x1f7/0x240\n vsnprintf+0x655/0xba0\n scnprintf+0xba/0x120\n netconsole_write+0x3fe/0xa10\n nbcon_emit_next_record+0x46e/0x860\n nbcon_kthread_func+0x623/0x750\n\n Allocated by task 1:\n nbcon_alloc+0x1ea/0x450\n register_console+0x26b/0xe10\n init_netconsole+0xbb0/0xda0\n\n The buggy address belongs to the object at ffff88813b6d4000\n which belongs to the cache kmalloc-4k of size 4096\n The buggy address is located 0 bytes to the right of\n allocated 3072-byte region [ffff88813b6d4000, ffff88813b6d4c00)(CVE-2026-43197)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niommu/amd: serialize sequence allocation under concurrent TLB invalidations\n\nWith concurrent TLB invalidations, completion wait randomly gets timed out\nbecause cmd_sem_val was incremented outside the IOMMU spinlock, allowing\nCMD_COMPL_WAIT commands to be queued out of sequence and breaking the\nordering assumption in wait_on_sem().\nMove the cmd_sem_val increment under iommu-\u0026gt;lock so completion sequence\nallocation is serialized with command queuing.\nAnd remove the unnecessary return.(CVE-2026-43220)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: prevent races in -\u0026gt;query_interfaces()\n\nIt was possible for two query interface works to be concurrently trying\nto update the interfaces.\n\nPrevent this by checking and updating iface_last_update under\niface_lock.(CVE-2026-43239)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nx86/kexec: add a sanity check on previous kernel\u0026apos;s ima kexec buffer\n\nWhen the second-stage kernel is booted via kexec with a limiting command\nline such as \u0026quot;mem=\u0026lt;size\u0026gt;\u0026quot;, the physical range that contains the carried\nover IMA measurement list may fall outside the truncated RAM leading to a\nkernel panic.\n\n BUG: unable to handle page fault for address: ffff97793ff47000\n RIP: ima_restore_measurement_list+0xdc/0x45a\n #PF: error_code(0x0000) \u2013 not-present page\n\nOther architectures already validate the range with page_is_ram(), as done\nin commit cbf9c4b9617b (\u0026quot;of: check previous kernel\u0026apos;s ima-kexec-buffer\nagainst memory bounds\u0026quot;) do a similar check on x86.\n\nWithout carrying the measurement list across kexec, the attestation\nwould fail.(CVE-2026-43240)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: move ext4_percpu_param_init() before ext4_mb_init()\n\nWhen running `kvm-xfstests -c ext4/1k -C 1 generic/383` with the\n`DOUBLE_CHECK` macro defined, the following panic is triggered:\n\n==================================================================\nEXT4-fs error (device vdc): ext4_validate_block_bitmap:423:\n comm mount: bg 0: bad block bitmap checksum\nBUG: unable to handle page fault for address: ff110000fa2cc000\nPGD 3e01067 P4D 3e02067 PUD 0\nOops: Oops: 0000 [#1] SMP NOPTI\nCPU: 0 UID: 0 PID: 2386 Comm: mount Tainted: G W\n 6.18.0-gba65a4e7120a-dirty #1152 PREEMPT(none)\nRIP: 0010:percpu_counter_add_batch+0x13/0xa0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ext4_mark_group_bitmap_corrupted+0xcb/0xe0\n ext4_validate_block_bitmap+0x2a1/0x2f0\n ext4_read_block_bitmap+0x33/0x50\n mb_group_bb_bitmap_alloc+0x33/0x80\n ext4_mb_add_groupinfo+0x190/0x250\n ext4_mb_init_backend+0x87/0x290\n ext4_mb_init+0x456/0x640\n __ext4_fill_super+0x1072/0x1680\n ext4_fill_super+0xd3/0x280\n get_tree_bdev_flags+0x132/0x1d0\n vfs_get_tree+0x29/0xd0\n vfs_cmd_create+0x59/0xe0\n __do_sys_fsconfig+0x4f6/0x6b0\n do_syscall_64+0x50/0x1f0\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n==================================================================\n\nThis issue can be reproduced using the following commands:\n mkfs.ext4 -F -q -b 1024 /dev/sda 5G\n tune2fs -O quota,project /dev/sda\n mount /dev/sda /tmp/test\n\nWith DOUBLE_CHECK defined, mb_group_bb_bitmap_alloc() reads\nand validates the block bitmap. When the validation fails,\next4_mark_group_bitmap_corrupted() attempts to update\nsbi-\u0026gt;s_freeclusters_counter. However, this percpu_counter has not been\ninitialized yet at this point, which leads to the panic described above.\n\nFix this by moving the execution of ext4_percpu_param_init() to occur\nbefore ext4_mb_init(), ensuring the per-CPU counters are initialized\nbefore they are used.(CVE-2026-43288)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmd raid: fix hang when stopping arrays with metadata through dm-raid\n\nWhen using device-mapper\u0026apos;s dm-raid target, stopping a RAID array can cause\nthe system to hang under specific conditions.\n\nThis occurs when:\n\n- A dm-raid managed device tree is suspended from top to bottom\n (the top-level RAID device is suspended first, followed by its\n underlying metadata and data devices)\n\n- The top-level RAID device is then removed\n\nRemoving the top-level device triggers a hang in the following sequence:\nthe dm-raid destructor calls md_stop(), which tries to flush the\nwrite-intent bitmap by writing to the metadata sub-devices. However, these\ndevices are already suspended, making them unable to complete the write-intent\noperations and causing an indefinite block.\n\nFix:\n\n- Prevent bitmap flushing when md_stop() is called from dm-raid\ndestructor context\n and avoid a quiescing/unquescing cycle which could also cause I/O\n\n- Still allow write-intent bitmap flushing when called from dm-raid\nsuspend context\n\nThis ensures that RAID array teardown can complete successfully even when the\nunderlying devices are in a suspended state.\n\nThis second patch uses md_is_rdwr() to distinguish between suspend and\ndestructor paths as elaborated on above.(CVE-2026-43309)\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\nBluetooth: SMP: force responder MITM requirements before building the pairing response\n\nsmp_cmd_pairing_req() currently builds the pairing response from the\ninitiator auth_req before enforcing the local BT_SECURITY_HIGH\nrequirement. If the initiator omits SMP_AUTH_MITM, the response can\nalso omit it even though the local side still requires MITM.\n\ntk_request() then sees an auth value without SMP_AUTH_MITM and may\nselect JUST_CFM, making method selection inconsistent with the pairing\npolicy the responder already enforces.\n\nWhen the local side requires HIGH security, first verify that MITM can\nbe achieved from the IO capabilities and then force SMP_AUTH_MITM in the\nresponse in both rsp.auth_req and auth. This keeps the responder auth bits\nand later method selection aligned.(CVE-2026-43334)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: require a full NFS mode SID before reading mode bits\n\nparse_dacl() treats an ACE SID matching sid_unix_NFS_mode as an NFS\nmode SID and reads sid.sub_auth[2] to recover the mode bits.\n\nThat assumes the ACE carries three subauthorities, but compare_sids()\nonly compares min(a, b) subauthorities. A malicious server can return\nan ACE with num_subauth = 2 and sub_auth[] = {88, 3}, which still\nmatches sid_unix_NFS_mode and then drives the sub_auth[2] read four\nbytes past the end of the ACE.\n\nRequire num_subauth \u0026gt;= 3 before treating the ACE as an NFS mode SID.\nThis keeps the fix local to the special-SID mode path without changing\ncompare_sids() semantics for the rest of cifsacl.(CVE-2026-43350)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nio_uring/kbuf: check if target buffer list is still legacy on recycle\n\nThere\u0026apos;s a gap between when the buffer was grabbed and when it\npotentially gets recycled, where if the list is empty, someone could\u0026apos;ve\nupgraded it to a ring provided type. This can happen if the request\nis forced via io-wq. The legacy recycling is missing checking if the\nbuffer_list still exists, and if it\u0026apos;s of the correct type. Add those\nchecks.(CVE-2026-43366)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nlibceph: prevent potential out-of-bounds reads in process_message_header()\n\nIf the message frame is (maliciously) corrupted in a way that the\nlength of the control segment ends up being less than the size of the\nmessage header or a different frame is made to look like a message\nframe, out-of-bounds reads may ensue in process_message_header().\n\nPerform an explicit bounds check before decoding the message header.(CVE-2026-43406)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ne1000/e1000e: Fix leak in DMA error cleanup\n\nIf an error is encountered while mapping TX buffers, the driver should\nunmap any buffers already mapped for that skb.\n\nBecause count is incremented after a successful mapping, it will always\nmatch the correct number of unmappings needed when dma_error is reached.\nDecrementing count before the while loop in dma_error causes an\noff-by-one error. If any mapping was successful before an unsuccessful\nmapping, exactly one DMA mapping would leak.\n\nIn these commits, a faulty while condition caused an infinite loop in\ndma_error:\nCommit 03b1320dfcee (\u0026quot;e1000e: remove use of skb_dma_map from e1000e\ndriver\u0026quot;)\nCommit 602c0554d7b0 (\u0026quot;e1000: remove use of skb_dma_map from e1000 driver\u0026quot;)\n\nCommit c1fa347f20f1 (\u0026quot;e1000/e1000e/igb/igbvf/ixgb/ixgbe: Fix tests of\nunsigned in *_tx_map()\u0026quot;) fixed the infinite loop, but introduced the\noff-by-one error.\n\nThis issue may still exist in the igbvf driver, but I did not address it\nin this patch.(CVE-2026-43445)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Fix DMA FIFO desync on error CQE SQ recovery\n\nIn case of a TX error CQE, a recovery flow is triggered,\nmlx5e_reset_txqsq_cc_pc() resets dma_fifo_cc to 0 but not dma_fifo_pc,\ndesyncing the DMA FIFO producer and consumer.\n\nAfter recovery, the producer pushes new DMA entries at the old\ndma_fifo_pc, while the consumer reads from position 0.\nThis causes us to unmap stale DMA addresses from before the recovery.\n\nThe DMA FIFO is a purely software construct with no HW counterpart.\nAt the point of reset, all WQEs have been flushed so dma_fifo_cc is\nalready equal to dma_fifo_pc. There is no need to reset either counter,\nsimilar to how skb_fifo pc/cc are untouched.\n\nRemove the \u0026apos;dma_fifo_cc = 0\u0026apos; reset.\n\nThis fixes the following WARNING:\n WARNING: CPU: 0 PID: 0 at drivers/iommu/dma-iommu.c:1240 iommu_dma_unmap_page+0x79/0x90\n Modules linked in: mlx5_vdpa vringh vdpa bonding mlx5_ib mlx5_vfio_pci ipip mlx5_fwctl tunnel4 mlx5_core ib_ipoib geneve ip6_gre ip_gre gre nf_tables ip6_tunnel rdma_ucm ib_uverbs ib_umad vfio_pci vfio_pci_core act_mirred act_skbedit act_vlan vhost_net vhost tap ip6table_mangle ip6table_nat ip6table_filter ip6_tables iptable_mangle cls_matchall nfnetlink_cttimeout act_gact cls_flower sch_ingress vhost_iotlb iptable_raw tunnel6 vfio_iommu_type1 vfio openvswitch nsh rpcsec_gss_krb5 auth_rpcgss oid_registry xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink iptable_nat nf_nat xt_addrtype br_netfilter overlay zram zsmalloc rpcrdma ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_cm ib_core fuse [last unloaded: nf_tables]\n CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.13.0-rc5_for_upstream_min_debug_2024_12_30_21_33 #1\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\n RIP: 0010:iommu_dma_unmap_page+0x79/0x90\n Code: 2b 4d 3b 21 72 26 4d 3b 61 08 73 20 49 89 d8 44 89 f9 5b 4c 89 f2 4c 89 e6 48 89 ef 5d 41 5c 41 5d 41 5e 41 5f e9 c7 ae 9e ff \u0026lt;0f\u0026gt; 0b 5b 5d 41 5c 41 5d 41 5e 41 5f c3 66 2e 0f 1f 84 00 00 00 00\n Call Trace:\n \u0026lt;IRQ\u0026gt;\n ? __warn+0x7d/0x110\n ? iommu_dma_unmap_page+0x79/0x90\n ? report_bug+0x16d/0x180\n ? handle_bug+0x4f/0x90\n ? exc_invalid_op+0x14/0x70\n ? asm_exc_invalid_op+0x16/0x20\n ? iommu_dma_unmap_page+0x79/0x90\n ? iommu_dma_unmap_page+0x2e/0x90\n dma_unmap_page_attrs+0x10d/0x1b0\n mlx5e_tx_wi_dma_unmap+0xbe/0x120 [mlx5_core]\n mlx5e_poll_tx_cq+0x16d/0x690 [mlx5_core]\n mlx5e_napi_poll+0x8b/0xac0 [mlx5_core]\n __napi_poll+0x24/0x190\n net_rx_action+0x32a/0x3b0\n ? mlx5_eq_comp_int+0x7e/0x270 [mlx5_core]\n ? notifier_call_chain+0x35/0xa0\n handle_softirqs+0xc9/0x270\n irq_exit_rcu+0x71/0xd0\n common_interrupt+0x7f/0xa0\n \u0026lt;/IRQ\u0026gt;\n \u0026lt;TASK\u0026gt;\n asm_common_interrupt+0x22/0x40(CVE-2026-43466)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5: Fix deadlock between devlink lock and esw-\u0026gt;wq\n\nesw-\u0026gt;work_queue executes esw_functions_changed_event_handler -\u0026gt;\nesw_vfs_changed_event_handler and acquires the devlink lock.\n\n.eswitch_mode_set (acquires devlink lock in devlink_nl_pre_doit) -\u0026gt;\nmlx5_devlink_eswitch_mode_set -\u0026gt; mlx5_eswitch_disable_locked -\u0026gt;\nmlx5_eswitch_event_handler_unregister -\u0026gt; flush_workqueue deadlocks\nwhen esw_vfs_changed_event_handler executes.\n\nFix that by no longer flushing the work to avoid the deadlock, and using\na generation counter to keep track of work relevance. This avoids an old\nhandler manipulating an esw that has undergone one or more mode changes:\n- the counter is incremented in mlx5_eswitch_event_handler_unregister.\n- the counter is read and passed to the ephemeral mlx5_host_work struct.\n- the work handler takes the devlink lock and bails out if the current\n generation is different than the one it was scheduled to operate on.\n- mlx5_eswitch_cleanup does the final draining before destroying the wq.\n\nNo longer flushing the workqueue has the side effect of maybe no longer\ncancelling pending vport_change_handler work items, but that\u0026apos;s ok since\nthose are disabled elsewhere:\n- mlx5_eswitch_disable_locked disables the vport eq notifier.\n- mlx5_esw_vport_disable disarms the HW EQ notification and marks\n vport-\u0026gt;enabled under state_lock to false to prevent pending vport\n handler from doing anything.\n- mlx5_eswitch_cleanup destroys the workqueue and makes sure all events\n are disabled/finished.(CVE-2026-43468)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: L2CAP: Fix null-ptr-deref in l2cap_sock_state_change_cb()\n\nAdd the same NULL guard already present in\nl2cap_sock_resume_cb() and l2cap_sock_ready_cb().(CVE-2026-45834)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nfnetlink_queue: do shared-unconfirmed check before segmentation\n\nUlrich reports a regression with nfqueue:\n\nIf an application did not set the \u0026apos;F_GSO\u0026apos; capability flag and a gso\npacket with an unconfirmed nf_conn entry is received all packets are\nnow dropped instead of queued, because the check happens after\nskb_gso_segment(). In that case, we did have exclusive ownership\nof the skb and its associated conntrack entry. The elevated use\ncount is due to skb_clone happening via skb_gso_segment().\n\nMove the check so that its peformed vs. the aggregated packet.\n\nThen, annotate the individual segments except the first one so we\ncan do a 2nd check at reinject time.\n\nFor the normal case, where userspace does in-order reinjects, this avoids\npacket drops: first reinjected segment continues traversal and confirms\nentry, remaining segments observe the confirmed entry.\n\nWhile at it, simplify nf_ct_drop_unconfirmed(): We only care about\nunconfirmed entries with a refcnt \u0026gt; 1, there is no need to special-case\ndying entries.\n\nThis only happens with UDP. With TCP, the only unconfirmed packet will\nbe the TCP SYN, those aren\u0026apos;t aggregated by GRO.\n\nNext patch adds a udpgro test case to cover this scenario.(CVE-2026-45859)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ngfs2: Fix slab-use-after-free in qd_put\n\nCommit a475c5dd16e5 (\u0026quot;gfs2: Free quota data objects synchronously\u0026quot;)\nstarted freeing quota data objects during filesystem shutdown instead of\nputting them back onto the LRU list, but it failed to remove these\nobjects from the LRU list, causing LRU list corruption. This caused\nuse-after-free when the shrinker (gfs2_qd_shrink_scan) tried to access\nalready-freed objects on the LRU list.\n\nFix this by removing qd objects from the LRU list before freeing them in\nqd_put().\n\nInitial fix from Deepanshu Kartikey \u0026lt;(CVE-2026-45861)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix bpf_xdp_store_bytes proto for read-only arg\n\nWhile making some maps in Cilium read-only from the BPF side, we noticed\nthat the bpf_xdp_store_bytes proto is incorrect. In particular, the\nverifier was throwing the following error:\n\n ; ret = ctx_store_bytes(ctx, l3_off + offsetof(struct iphdr, saddr),\n \u0026amp;nat-\u0026gt;address, 4, 0);\n 635: (79) r1 = *(u64 *)(r10 -144) ; R1=ctx() R10=fp0 fp-144=ctx()\n 636: (b4) w2 = 26 ; R2=26\n 637: (b4) w4 = 4 ; R4=4\n 638: (b4) w5 = 0 ; R5=0\n 639: (85) call bpf_xdp_store_bytes#190\n write into map forbidden, value_size=6 off=0 size=4\n\nnat comes from a BPF_F_RDONLY_PROG map, so R3 is a PTR_TO_MAP_VALUE.\nThe verifier checks the helper\u0026apos;s memory access to R3 in\ncheck_mem_size_reg, as it reaches ARG_CONST_SIZE argument. The third\nargument has expected type ARG_PTR_TO_UNINIT_MEM, which includes the\nMEM_WRITE flag. The verifier thus checks for a BPF_WRITE access on R3.\nGiven R3 points to a read-only map, the check fails.\n\nConversely, ARG_PTR_TO_UNINIT_MEM can also lead to the helper reading\nfrom uninitialized memory.\n\nThis patch simply fixes the expected argument type to match that of\nbpf_skb_store_bytes.(CVE-2026-45886)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: cdns3: fix role switching during resume\n\nIf the role change while we are suspended, the cdns3 driver switches to the\nnew mode during resume. However, switching to host mode in this context\ncauses a NULL pointer dereference.\n\nThe host role\u0026apos;s start() operation registers a xhci-hcd device, but its\nprobe is deferred while we are in the resume path. The host role\u0026apos;s resume()\noperation assumes the xhci-hcd device is already probed, which is not the\ncase, leading to the dereference. Since the start() operation of the new\nrole is already called, the resume operation can be skipped.\n\nSo skip the resume operation for the new role if a role switch occurs\nduring resume. Once the resume sequence is complete, the xhci-hcd device\ncan be probed in case of host mode.\n\nUnable to handle kernel NULL pointer dereference at virtual address 0000000000000208\nMem abort info:\n...\nData abort info:\n...\n[0000000000000208] pgd=0000000000000000, p4d=0000000000000000\nInternal error: Oops: 0000000096000004 [#1] SMP\nModules linked in:\nCPU: 0 UID: 0 PID: 146 Comm: sh Not tainted\n6.19.0-rc7-00013-g6e64f4aabfae-dirty #135 PREEMPT\nHardware name: Texas Instruments J7200 EVM (DT)\npstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : usb_hcd_is_primary_hcd+0x0/0x1c\nlr : cdns_host_resume+0x24/0x5c\n...\nCall trace:\n usb_hcd_is_primary_hcd+0x0/0x1c (P)\n cdns_resume+0x6c/0xbc\n cdns3_controller_resume.isra.0+0xe8/0x17c\n cdns3_plat_resume+0x18/0x24\n platform_pm_resume+0x2c/0x68\n dpm_run_callback+0x90/0x248\n device_resume+0x100/0x24c\n dpm_resume+0x190/0x2ec\n dpm_resume_end+0x18/0x34\n suspend_devices_and_enter+0x2b0/0xa44\n pm_suspend+0x16c/0x5fc\n state_store+0x80/0xec\n kobj_attr_store+0x18/0x2c\n sysfs_kf_write+0x7c/0x94\n kernfs_fop_write_iter+0x130/0x1dc\n vfs_write+0x240/0x370\n ksys_write+0x70/0x108\n __arm64_sys_write+0x1c/0x28\n invoke_syscall+0x48/0x10c\n el0_svc_common.constprop.0+0x40/0xe0\n do_el0_svc+0x1c/0x28\n el0_svc+0x34/0x108\n el0t_64_sync_handler+0xa0/0xe4\n el0t_64_sync+0x198/0x19c\nCode: 52800003 f9407ca5 d63f00a0 17ffffe4 (f9410401)\n---[ end trace 0000000000000000 ]---(CVE-2026-45911)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ngfs2: fix memory leaks in gfs2_fill_super error path\n\nFix two memory leaks in the gfs2_fill_super() error handling path when\ntransitioning a filesystem to read-write mode fails.\n\nFirst leak: kthread objects (thread_struct, task_struct, etc.)\nWhen gfs2_freeze_lock_shared() fails after init_threads() succeeds, the\ncreated kernel threads (logd and quotad) are never destroyed. This\noccurs because the fail_per_node label doesn\u0026apos;t call\ngfs2_destroy_threads().\n\nSecond leak: quota bitmap buffer (8192 bytes)\nWhen gfs2_make_fs_rw() fails after gfs2_quota_init() succeeds but\nbefore other operations complete, the allocated quota bitmap is never\nfreed.\n\nThe fix moves thread cleanup to the fail_per_node label to handle all\nerror paths uniformly. gfs2_destroy_threads() is safe to call\nunconditionally as it checks for NULL pointers. Quota cleanup is added\nin gfs2_make_fs_rw() to properly handle the withdrawal case where\nquota initialization succeeds but the filesystem is then withdrawn.\n\nThread leak backtrace (gfs2_freeze_lock_shared failure):\n unreferenced object 0xffff88801d7bca80 (size 4480):\n copy_process+0x3a1/0x4670 kernel/fork.c:2422\n kernel_clone+0xf3/0x6e0 kernel/fork.c:2779\n kthread_create_on_node+0x100/0x150 kernel/kthread.c:478\n init_threads+0xab/0x350 fs/gfs2/ops_fstype.c:611\n gfs2_fill_super+0xe5c/0x1240 fs/gfs2/ops_fstype.c:1265\n\nQuota leak backtrace (gfs2_make_fs_rw failure):\n unreferenced object 0xffff88812de7c000 (size 8192):\n gfs2_quota_init+0xe5/0x820 fs/gfs2/quota.c:1409\n gfs2_make_fs_rw+0x7a/0xe0 fs/gfs2/super.c:149\n gfs2_fill_super+0xfbb/0x1240 fs/gfs2/ops_fstype.c:1275(CVE-2026-45961)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nACPICA: Fix NULL pointer dereference in acpi_ev_address_space_dispatch()\n\nCover a missed execution path with a new check.(CVE-2026-45982)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ngfs2: Fix use-after-free in iomap inline data write path\n\nThe inline data buffer head (dibh) is being released prematurely in\ngfs2_iomap_begin() via release_metapath() while iomap-\u0026gt;inline_data\nstill points to dibh-\u0026gt;b_data. This causes a use-after-free when\niomap_write_end_inline() later attempts to write to the inline data\narea.\n\nThe bug sequence:\n1. gfs2_iomap_begin() calls gfs2_meta_inode_buffer() to read inode\n metadata into dibh\n2. Sets iomap-\u0026gt;inline_data = dibh-\u0026gt;b_data + sizeof(struct gfs2_dinode)\n3. Calls release_metapath() which calls brelse(dibh), dropping refcount\n to 0\n4. kswapd reclaims the page (~39ms later in the syzbot report)\n5. iomap_write_end_inline() tries to memcpy() to iomap-\u0026gt;inline_data\n6. KASAN detects use-after-free write to freed memory\n\nFix by storing dibh in iomap-\u0026gt;private and incrementing its refcount\nwith get_bh() in gfs2_iomap_begin(). The buffer is then properly\nreleased in gfs2_iomap_end() after the inline write completes,\nensuring the page stays alive for the entire iomap operation.\n\nNote: A C reproducer is not available for this issue. The fix is based\non analysis of the KASAN report and code review showing the buffer head\nis freed before use.\n\n[agruenba: Take buffer head reference in gfs2_iomap_begin() to avoid\nleaks in gfs2_iomap_get() and gfs2_iomap_alloc().](CVE-2026-45984)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nerofs: fix unsigned underflow in z_erofs_lz4_handle_overlap()\n\nSome crafted images can have illegal (!partial_decoding \u0026amp;\u0026amp;\nm_llen \u0026lt; m_plen) extents, and the LZ4 inplace decompression path\ncan be wrongly hit, but it cannot handle (outpages \u0026lt; inpages)\nproperly: \u0026quot;outpages - inpages\u0026quot; wraps to a large value and\nthe subsequent rq-\u0026gt;out[] access reads past the decompressed_pages\narray.\n\nHowever, such crafted cases can correctly result in a corruption\nreport in the normal LZ4 non-inplace path.\n\nLet\u0026apos;s add an additional check to fix this for backporting.\n\nReproducible image (base64-encoded gzipped blob):\n\nH4sIAJGR12kCA+3SPUoDQRgG4MkmkkZk8QRbRFIIi9hbpEjrHQI5ghfwCN5BLCzTGtLbBI+g\ndilSJo1CnIm7GEXFxhT6PDDwfrs73/ywIQD/1ePD4r7Ou6ETsrq4mu7XcWfj++Pb58nJU/9i\nPNtbjhan04/9GtX4qVYc814WDqt6FaX5s+ZwXXeq52lndT6IuVvlblytLMvh4Gzwaf90nsvz\n2DF/21+20T/ldgp5s1jXRaN4t/8izsy/OUB6e/Qa79r+JwAAAAAAAL52vQVuGQAAAP6+my1w\nywAAAAAAAADwu14ATsEYtgBQAAA=\n\n$ mount -t erofs -o cache_strategy=disabled foo.erofs /mnt\n$ dd if=/mnt/data of=/dev/null bs=4096 count=1(CVE-2026-45999)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/nouveau: fix u32 overflow in pushbuf reloc bounds check\n\nnouveau_gem_pushbuf_reloc_apply() validates each relocation with\n\n if (r-\u0026gt;reloc_bo_offset + 4 \u0026gt; nvbo-\u0026gt;bo.base.size)\n\nbut reloc_bo_offset is __u32 (uapi/drm/nouveau_drm.h) and the integer\nliteral 4 promotes to unsigned int, so the addition is performed in 32\nbits and wraps before the comparison against the size_t bo size.\n\nCast to u64 so the addition happens in 64-bit arithmetic.\n\n[ Add Fixes: tag. - Danilo ](CVE-2026-46006)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: SVM: Add missing save/restore handling of LBR MSRs\n\nMSR_IA32_DEBUGCTLMSR and LBR MSRs are currently not enumerated by\nKVM_GET_MSR_INDEX_LIST, and LBR MSRs cannot be set with KVM_SET_MSRS. So\nsave/restore is completely broken.\n\nFix it by adding the MSRs to msrs_to_save_base, and allowing writes to\nLBR MSRs from userspace only (as they are read-only MSRs) if LBR\nvirtualization is enabled. Additionally, to correctly restore L1\u0026apos;s LBRs\nwhile L2 is running, make sure the LBRs are copied from the captured\nVMCB01 save area in svm_copy_vmrun_state().\n\nNote, for VMX, this also fixes a flaw where MSR_IA32_DEBUGCTLMSR isn\u0026apos;t\nreported as an MSR to save/restore.\n\nNote #2, over-reporting MSR_IA32_LASTxxx on Intel is ok, as KVM already\nhandles unsupported reads and writes thanks to commit b5e2fec0ebc3 (\u0026quot;KVM:\nIgnore DEBUGCTL MSRs with no effect\u0026quot;) (kvm_do_msr_access() will morph the\nunsupported userspace write into a nop).\n\n[sean: guard with lbrv checks, massage changelog](CVE-2026-46014)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipmi:ssif: Clean up kthread on errors\n\nIf an error occurs after the ssif kthread is created, but before the\nmain IPMI code starts the ssif interface, the ssif kthread will not\nbe stopped.\n\nSo make sure the kthread is stopped on an error condition if it is\nrunning.(CVE-2026-46044)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmd/raid5: fix soft lockup in retry_aligned_read()\n\nWhen retry_aligned_read() encounters an overlapped stripe, it releases\nthe stripe via raid5_release_stripe() which puts it on the lockless\nreleased_stripes llist. In the next raid5d loop iteration,\nrelease_stripe_list() drains the stripe onto handle_list (since\nSTRIPE_HANDLE is set by the original IO), but retry_aligned_read()\nruns before handle_active_stripes() and removes the stripe from\nhandle_list via find_get_stripe() -\u0026gt; list_del_init(). This prevents\nhandle_stripe() from ever processing the stripe to resolve the\noverlap, causing an infinite loop and soft lockup.\n\nFix this by using __release_stripe() with temp_inactive_list instead\nof raid5_release_stripe() in the failure path, so the stripe does not\ngo through the released_stripes llist. This allows raid5d to break out\nof its loop, and the overlap will be resolved when the stripe is\neventually processed by handle_stripe().(CVE-2026-46051)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nceph: only d_add() negative dentries when they are unhashed\n\nCeph can call d_add(dentry, NULL) on a negative dentry that is already\npresent in the primary dcache hash.\n\nIn the current VFS that is not safe. d_add() goes through __d_add()\nto __d_rehash(), which unconditionally reinserts dentry-\u0026gt;d_hash into\nthe hlist_bl bucket. If the dentry is already hashed, reinserting the\nsame node can corrupt the bucket, including creating a self-loop.\nOnce that happens, __d_lookup() can spin forever in the hlist_bl walk,\ntypically looping only on the d_name.hash mismatch check and\neventually triggering RCU stall reports like this one:\n\n rcu: INFO: rcu_sched self-detected stall on CPU\n rcu: 87-....: (2100 ticks this GP) idle=3a4c/1/0x4000000000000000 softirq=25003319/25003319 fqs=829\n rcu: (t=2101 jiffies g=79058445 q=698988 ncpus=192)\n CPU: 87 UID: 2952868916 PID: 3933303 Comm: php-cgi8.3 Not tainted 6.18.17-i1-amd #950 NONE\n Hardware name: Dell Inc. PowerEdge R7615/0G9DHV, BIOS 1.6.6 09/22/2023\n RIP: 0010:__d_lookup+0x46/0xb0\n Code: c1 e8 07 48 8d 04 c2 48 8b 00 49 89 fc 49 89 f5 48 89 c3 48 83 e3 fe 48 83 f8 01 77 0f eb 2d 0f 1f 44 00 00 48 8b 1b 48 85 db \u0026lt;74\u0026gt; 20 39 6b 18 75 f3 48 8d 7b 78 e8 ba 85 d0 00 4c 39 63 10 74 1f\n RSP: 0018:ff745a70c8253898 EFLAGS: 00000282\n RAX: ff26e470054cb208 RBX: ff26e470054cb208 RCX: 000000006e958966\n RDX: ff26e48267340000 RSI: ff745a70c82539b0 RDI: ff26e458f74655c0\n RBP: 000000006e958966 R08: 0000000000000180 R09: 9cd08d909b919a89\n R10: ff26e458f74655c0 R11: 0000000000000000 R12: ff26e458f74655c0\n R13: ff745a70c82539b0 R14: d0d0d0d0d0d0d0d0 R15: 2f2f2f2f2f2f2f2f\n FS: 00007f5770896980(0000) GS:ff26e482c5d88000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00007f5764de50c0 CR3: 000000a72abb5001 CR4: 0000000000771ef0\n PKRU: 55555554\n Call Trace:\n \u0026lt;TASK\u0026gt;\n lookup_fast+0x9f/0x100\n walk_component+0x1f/0x150\n link_path_walk+0x20e/0x3d0\n path_lookupat+0x68/0x180\n filename_lookup+0xdc/0x1e0\n vfs_statx+0x6c/0x140\n vfs_fstatat+0x67/0xa0\n __do_sys_newfstatat+0x24/0x60\n do_syscall_64+0x6a/0x230\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nThis is reachable with reused cached negative dentries. A Ceph lookup\nor atomic_open can be handed a negative dentry that is already hashed,\nand fs/ceph/dir.c then hits one of two paths that incorrectly assume\n\u0026quot;negative\u0026quot; also means \u0026quot;unhashed\u0026quot;:\n\n - ceph_finish_lookup():\n MDS reply is -ENOENT with no trace\n -\u0026gt; d_add(dentry, NULL)\n\n - ceph_lookup():\n local ENOENT fast path for a complete directory with shared caps\n -\u0026gt; d_add(dentry, NULL)\n\nBoth paths can therefore re-add an already-hashed negative dentry.\n\nCeph already uses the correct pattern elsewhere: ceph_fill_trace() only\ncalls d_add(dn, NULL) for a negative null-dentry reply when d_unhashed(dn)\nis true.\n\nFix both fs/ceph/dir.c sites the same way: only call d_add() for a\nnegative dentry when it is actually unhashed. If the negative dentry\nis already hashed, leave it in place and reuse it as-is.\n\nThis preserves the existing behavior for unhashed dentries while\navoiding d_hash list corruption for reused hashed negatives.(CVE-2026-46052)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: nSVM: Raise #UD if unhandled VMMCALL isn\u0026apos;t intercepted by L1\n\nExplicitly synthesize a #UD for VMMCALL if L2 is active, L1 does NOT want\nto intercept VMMCALL, nested_svm_l2_tlb_flush_enabled() is true, and the\nhypercall is something other than one of the supported Hyper-V hypercalls.\nWhen all of the above conditions are met, KVM will intercept VMMCALL but\nnever forward it to L1, i.e. will let L2 make hypercalls as if it were L1.\n\nThe TLFS says a whole lot of nothing about this scenario, so go with the\narchitectural behavior, which says that VMMCALL #UDs if it\u0026apos;s not\nintercepted.\n\nOpportunistically do a 2-for-1 stub trade by stub-ifying the new API\ninstead of the helpers it uses. The last remaining \u0026quot;single\u0026quot; stub will\nsoon be dropped as well.\n\n[sean: rewrite changelog and comment, tag for stable, remove defunct stubs](CVE-2026-46076)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nerofs: fix the out-of-bounds nameoff handling for trailing dirents\n\nCurrently we already have boundary-checks for nameoffs, but the trailing\ndirents are special since the namelens are calculated with strnlen()\nwith unchecked nameoffs.\n\nIf a crafted EROFS has a trailing dirent with nameoff \u0026gt;= maxsize,\nmaxsize - nameoff can underflow, causing strnlen() to read past the\ndirectory block.\n\nnameoff0 should also be verified to be a multiple of\n`sizeof(struct erofs_dirent)` as well [1].\n\n[1] https://sashiko.dev/#/patchset/20260416063511.3173774-1-hsiangkao%40linux.alibaba.com(CVE-2026-46078)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: SVM: Inject #UD for INVLPGA if EFER.SVME=0\n\nINVLPGA should cause a #UD when EFER.SVME is not set. Add a check to\nproperly inject #UD when EFER.SVME=0.\n\n[sean: tag for stable@](CVE-2026-46082)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/vmalloc: take vmap_purge_lock in shrinker\n\ndecay_va_pool_node() can be invoked concurrently from two paths:\n__purge_vmap_area_lazy() when pools are being purged, and the shrinker via\nvmap_node_shrink_scan().\n\nHowever, decay_va_pool_node() is not safe to run concurrently, and the\nshrinker path currently lacks serialization, leading to races and possible\nleaks.\n\nProtect decay_va_pool_node() by taking vmap_purge_lock in the shrinker\npath to ensure serialization with purge users.(CVE-2026-46093)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_event: Fix OOB read and infinite loop in hci_le_create_big_complete_evt\n\nhci_le_create_big_complete_evt() iterates over BT_BOUND connections for\na BIG handle using a while loop, accessing ev-\u0026gt;bis_handle[i++] on each\niteration. However, there is no check that i stays within ev-\u0026gt;num_bis\nbefore the array access.\n\nWhen a controller sends a LE_Create_BIG_Complete event with fewer\nbis_handle entries than there are BT_BOUND connections for that BIG,\nor with num_bis=0, the loop reads beyond the valid bis_handle[] flex\narray into adjacent heap memory. Since the out-of-bounds values\ntypically exceed HCI_CONN_HANDLE_MAX (0x0EFF), hci_conn_set_handle()\nrejects them and the connection remains in BT_BOUND state. The same\nconnection is then found again by hci_conn_hash_lookup_big_state(),\ncreating an infinite loop with hci_dev_lock held.\n\nFix this by terminating the BIG if in case not all BIS could be setup\nproperly.(CVE-2026-46138)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nopenvswitch: vport: fix self-deadlock on release of tunnel ports\n\nvports are used concurrently and protected by RCU, so netdev_put()\nmust happen after the RCU grace period. So, either in an RCU call or\nafter the synchronize_net(). The rtnl_delete_link() must happen under\nRTNL and so can\u0026apos;t be executed in RCU context. Calling synchronize_net()\nwhile holding RTNL is not a good idea for performance and system\nstability under load in general, so calling netdev_put() in RCU call\nis the right solution here.\n\nHowever,\nwhen the device is deleted, rtnl_unlock() will call netdev_run_todo()\nand block until all the references are gone. In the current code this\nmeans that we never reach the call_rcu() and the vport is never freed\nand the reference is never released, causing a self-deadlock on device\nremoval.\n\nFix that by moving the rcu_call() before the rtnl_unlock(), so the\nscheduled RCU callback will be executed when synchronize_net() is\ncalled from the rtnl_unlock()-\u0026gt;netdev_run_todo() while the RTNL itself\nis already released.(CVE-2026-46165)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nriscv: kvm: fix vector context allocation leak\n\nWhen the second kzalloc (host_context.vector.datap) fails in\nkvm_riscv_vcpu_alloc_vector_context, the first allocation\n(guest_context.vector.datap) is leaked. Free it before returning.(CVE-2026-46171)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nx86/CPU/AMD: Prevent improper isolation of shared resources in Zen2\u0026apos;s op cache\n\nMake sure resources are not improperly shared in the op cache and\ncause instruction corruption this way.(CVE-2026-46174)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/mlx4: Fix resource leak on error in mlx4_ib_create_srq()\n\nSashiko points out that mlx4_srq_alloc() was not undone during error\nunwind, add the missing call to mlx4_srq_free().(CVE-2026-46178)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmtd: spi-nor: debugfs: fix out-of-bounds read in spi_nor_params_show()\n\nSashiko noticed an out-of-bounds read [1].\n\nIn spi_nor_params_show(), the snor_f_names array is passed to\nspi_nor_print_flags() using sizeof(snor_f_names).\n\nSince snor_f_names is an array of pointers, sizeof() returns the total\nnumber of bytes occupied by the pointers\n\t(element_count * sizeof(void *))\nrather than the element count itself. On 64-bit systems, this makes the\npassed length 8x larger than intended.\n\nInside spi_nor_print_flags(), the \u0026apos;names_len\u0026apos; argument is used to\nbounds-check the \u0026apos;names\u0026apos; array access. An out-of-bounds read occurs\nif a flag bit is set that exceeds the array\u0026apos;s actual element count\nbut is within the inflated byte-size count.\n\nCorrect this by using ARRAY_SIZE() to pass the actual number of\nstring pointers in the array.(CVE-2026-46190)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nft_inner: Fix IPv6 inner_thoff desync\n\nIn nft_inner_parse_l2l3(), when processing inner IPv6 packets,\nipv6_find_hdr() correctly computes the transport header offset\ntraversing all extension headers, but the result is immediately\noverwritten with nhoff + sizeof(_ip6h) (40 bytes), which only\naccounts for the IPv6 base header. This creates a desync between\ninner_thoff (wrong \u2014 points to extension header start) and l4proto\n(correct \u2014 e.g., IPPROTO_TCP), enabling transport header forgery\nand potential firewall bypass. This issue affects stable versions\nfrom Linux 6.2.\n\nFor comparison, the normal (non-inner) IPv6 path correctly\npreserves ipv6_find_hdr()\u0026apos;s result. Removing the incorrect overwrite\nensures that ipv6_find_hdr()\u0026apos;s calculated transport header offset is\npreserved, thereby fixing the desynchronization.(CVE-2026-46244)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntap: free page on error paths in tap_get_user_xdp()\n\ntap_get_user_xdp() rejects a frame shorter than ETH_HLEN with -EINVAL,\nand returns -ENOMEM when build_skb() fails. Both paths jump to the err\nlabel without freeing the page that vhost_net_build_xdp() allocated for\nthe frame. tap_sendmsg() discards the per-buffer return value and always\nreturns 0, so vhost_tx_batch() takes the success path and never frees\nthe page; each rejected frame in a batch leaks one page-frag chunk.\n\nFree the page on both error paths, before the skb is built. This is the\ntap counterpart of the same leak in tun_xdp_one().(CVE-2026-46320)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntun: free page on short-frame rejection in tun_xdp_one()\n\ntun_xdp_one() returns -EINVAL on a frame shorter than ETH_HLEN without\nfreeing the page that vhost_net_build_xdp() allocated for it.\ntun_sendmsg() discards that -EINVAL and still returns total_len, so\nvhost_tx_batch() takes the success path and never frees the page; each\nshort frame in a batch leaks one page-frag chunk.\n\nA local process that can open /dev/net/tun and /dev/vhost-net can hit\nthis path: it attaches a tun/tap device as the vhost-net backend and\nfeeds TX descriptors whose length minus the virtio-net header is below\nETH_HLEN. Each kick leaks the page-frag chunks for that batch, and a\ntight submission loop exhausts host memory and triggers an OOM panic.\nFree the page before returning -EINVAL, matching the XDP-program error\npath in the same function.(CVE-2026-46321)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntun: free page on build_skb failure in tun_xdp_one()\n\nWhen build_skb() fails in tun_xdp_one(), the function sets ret to\n-ENOMEM and jumps to the out label, which returns without freeing the\npage that vhost_net_build_xdp() allocated for the frame. As with the\nshort-frame rejection path, tun_sendmsg() discards the per-buffer error\nand still returns total_len, so vhost_tx_batch() takes the success path\nand never frees the page. Each build_skb() failure in a batch leaks one\npage-frag chunk.\n\nFree the page before taking the error path, matching the put_page() the\nother error exits of tun_xdp_one() already perform.(CVE-2026-46322)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: gro: don\u0026apos;t merge zcopy skbs\n\nskb_gro_receive() can currently copy frags between the source and GRO\nskb, without checking the zerocopy status, and in particular the\nSKBFL_MANAGED_FRAG_REFS flag.\n\nWhen SKBFL_MANAGED_FRAG_REFS is set, the skb doesn\u0026apos;t hold a reference\non the pages in shinfo-\u0026gt;frags. Appending those frags to another skb\u0026apos;s\nfrags without fixing up the page refcount can lead to UAF.\n\nWhen either the last skb in the GRO chain (the one we would append\nfrags to) or the source skb is zerocopy, don\u0026apos;t merge the skbs.(CVE-2026-46323)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRevert \u0026quot;net/smc: Introduce TCP ULP support\u0026quot;\n\nThis reverts commit d7cd421da9da2cc7b4d25b8537f66db5c8331c40.\n\nAs reported by Al Viro, the TCP ULP support for SMC is fundamentally\nbroken. The implementation attempts to convert an active TCP socket\ninto an SMC socket by modifying the underlying `struct file`, dentry,\nand inode in-place, which violates core VFS invariants that assume\nthese structures are immutable for an open file, creating a risk of\nuse after free errors and general system instability.\n\nGiven the severity of this design flaw and the fact that cleaner\nalternatives (e.g., LD_PRELOAD, BPF) exist for legacy application\ntransparency, the correct course of action is to remove this feature\nentirely.(CVE-2026-46330)",
"id": "OESA-2026-3157",
"modified": "2026-08-06T11:12:02Z",
"published": "2026-07-24T11:12:02Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-3157"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-10263"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39932"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71109"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71203"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23213"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23214"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23261"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31414"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31432"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31440"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31443"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31453"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31531"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31551"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31557"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31580"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31588"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31662"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31664"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31681"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31717"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31725"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31759"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43022"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43025"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43026"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43028"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43083"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43091"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43099"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43101"
},
{
"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-43127"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43156"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43163"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43180"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43186"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43194"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43197"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43220"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43239"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43240"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43288"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43309"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43319"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43334"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43350"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43366"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43406"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43445"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43466"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43468"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45834"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45859"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45861"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45886"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45911"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45961"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45982"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45984"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45999"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46006"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46014"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46044"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46051"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46052"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46076"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46078"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46082"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46093"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46138"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46165"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46171"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46174"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46178"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46190"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46244"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46320"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46321"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46322"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46323"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46330"
}
],
"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-10263",
"CVE-2025-39932",
"CVE-2025-71109",
"CVE-2025-71203",
"CVE-2026-23213",
"CVE-2026-23214",
"CVE-2026-23261",
"CVE-2026-31414",
"CVE-2026-31432",
"CVE-2026-31440",
"CVE-2026-31443",
"CVE-2026-31453",
"CVE-2026-31531",
"CVE-2026-31551",
"CVE-2026-31557",
"CVE-2026-31580",
"CVE-2026-31588",
"CVE-2026-31662",
"CVE-2026-31664",
"CVE-2026-31681",
"CVE-2026-31717",
"CVE-2026-31725",
"CVE-2026-31759",
"CVE-2026-43022",
"CVE-2026-43025",
"CVE-2026-43026",
"CVE-2026-43028",
"CVE-2026-43083",
"CVE-2026-43091",
"CVE-2026-43099",
"CVE-2026-43101",
"CVE-2026-43116",
"CVE-2026-43125",
"CVE-2026-43127",
"CVE-2026-43156",
"CVE-2026-43163",
"CVE-2026-43180",
"CVE-2026-43186",
"CVE-2026-43194",
"CVE-2026-43197",
"CVE-2026-43220",
"CVE-2026-43239",
"CVE-2026-43240",
"CVE-2026-43288",
"CVE-2026-43309",
"CVE-2026-43319",
"CVE-2026-43334",
"CVE-2026-43350",
"CVE-2026-43366",
"CVE-2026-43406",
"CVE-2026-43445",
"CVE-2026-43466",
"CVE-2026-43468",
"CVE-2026-45834",
"CVE-2026-45859",
"CVE-2026-45861",
"CVE-2026-45886",
"CVE-2026-45911",
"CVE-2026-45961",
"CVE-2026-45982",
"CVE-2026-45984",
"CVE-2026-45999",
"CVE-2026-46006",
"CVE-2026-46014",
"CVE-2026-46044",
"CVE-2026-46051",
"CVE-2026-46052",
"CVE-2026-46076",
"CVE-2026-46078",
"CVE-2026-46082",
"CVE-2026-46093",
"CVE-2026-46138",
"CVE-2026-46165",
"CVE-2026-46171",
"CVE-2026-46174",
"CVE-2026-46178",
"CVE-2026-46190",
"CVE-2026-46244",
"CVE-2026-46320",
"CVE-2026-46321",
"CVE-2026-46322",
"CVE-2026-46323",
"CVE-2026-46330"
]
}
OPENSUSE-SU-2026:10954-1
Vulnerability from csaf_opensuse - Published: 2026-06-04 00:00 - Updated: 2026-09-17 17:08Sightings
| 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.