Action not permitted
Modal body text goes here.
Modal Title
Modal Body
CVE-2026-23442 (GCVE-0-2026-23442)
Vulnerability from cvelistv5 – Published: 2026-04-03 15:15 – Updated: 2026-06-01 16:11| Vendor | Product | Version | CPE status | |
|---|---|---|---|---|
| Linux | Linux |
Affected:
1ababeba4a21f3dba3da3523c670b207fb2feb62 , < 0348fa0ada37cef7c6b5ab2a428bb2c6aee784e4
(git)
Affected: 1ababeba4a21f3dba3da3523c670b207fb2feb62 , < 83d705d35e583cb1b1eacf196dfe7b77d442018e (git) Affected: 1ababeba4a21f3dba3da3523c670b207fb2feb62 , < d1bd8b9edc6752d10f84d28ff64f842401ce336d (git) Affected: 1ababeba4a21f3dba3da3523c670b207fb2feb62 , < 50352fc103928e10e8729abc79a0d05abef26c4d (git) Affected: 1ababeba4a21f3dba3da3523c670b207fb2feb62 , < bc9843c39f9932a8b36efd1d362ea00bb88e4e78 (git) Affected: 1ababeba4a21f3dba3da3523c670b207fb2feb62 , < c5cedee5d97382176573bbe21e1724e737a5eb64 (git) Affected: 1ababeba4a21f3dba3da3523c670b207fb2feb62 , < a25853c9feea7bbf31d157ff6e004d2d3b4f7f13 (git) Affected: 1ababeba4a21f3dba3da3523c670b207fb2feb62 , < 06413793526251870e20402c39930804f14d59c0 (git) |
guessed | |
| Linux | Linux |
Affected:
4.10
Unaffected: 0 , < 4.10 (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.136 , ≤ 6.6.* (semver) Unaffected: 6.12.83 , ≤ 6.12.* (semver) Unaffected: 6.18.25 , ≤ 6.18.* (semver) Unaffected: 6.19.10 , ≤ 6.19.* (semver) Unaffected: 7.0 , ≤ * (original_commit_for_fix) |
guessed |
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"net/ipv6/exthdrs.c",
"net/ipv6/seg6_hmac.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "0348fa0ada37cef7c6b5ab2a428bb2c6aee784e4",
"status": "affected",
"version": "1ababeba4a21f3dba3da3523c670b207fb2feb62",
"versionType": "git"
},
{
"lessThan": "83d705d35e583cb1b1eacf196dfe7b77d442018e",
"status": "affected",
"version": "1ababeba4a21f3dba3da3523c670b207fb2feb62",
"versionType": "git"
},
{
"lessThan": "d1bd8b9edc6752d10f84d28ff64f842401ce336d",
"status": "affected",
"version": "1ababeba4a21f3dba3da3523c670b207fb2feb62",
"versionType": "git"
},
{
"lessThan": "50352fc103928e10e8729abc79a0d05abef26c4d",
"status": "affected",
"version": "1ababeba4a21f3dba3da3523c670b207fb2feb62",
"versionType": "git"
},
{
"lessThan": "bc9843c39f9932a8b36efd1d362ea00bb88e4e78",
"status": "affected",
"version": "1ababeba4a21f3dba3da3523c670b207fb2feb62",
"versionType": "git"
},
{
"lessThan": "c5cedee5d97382176573bbe21e1724e737a5eb64",
"status": "affected",
"version": "1ababeba4a21f3dba3da3523c670b207fb2feb62",
"versionType": "git"
},
{
"lessThan": "a25853c9feea7bbf31d157ff6e004d2d3b4f7f13",
"status": "affected",
"version": "1ababeba4a21f3dba3da3523c670b207fb2feb62",
"versionType": "git"
},
{
"lessThan": "06413793526251870e20402c39930804f14d59c0",
"status": "affected",
"version": "1ababeba4a21f3dba3da3523c670b207fb2feb62",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"net/ipv6/exthdrs.c",
"net/ipv6/seg6_hmac.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "4.10"
},
{
"lessThan": "4.10",
"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.136",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.83",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.18.*",
"status": "unaffected",
"version": "6.18.25",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.19.*",
"status": "unaffected",
"version": "6.19.10",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "7.0",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.10.258",
"versionStartIncluding": "4.10",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.15.209",
"versionStartIncluding": "4.10",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.1.175",
"versionStartIncluding": "4.10",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6.136",
"versionStartIncluding": "4.10",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.12.83",
"versionStartIncluding": "4.10",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.18.25",
"versionStartIncluding": "4.10",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.19.10",
"versionStartIncluding": "4.10",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "7.0",
"versionStartIncluding": "4.10",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nipv6: add NULL checks for idev in SRv6 paths\n\n__in6_dev_get() can return NULL when the device has no IPv6 configuration\n(e.g. MTU \u003c IPV6_MIN_MTU or after NETDEV_UNREGISTER).\n\nAdd NULL checks for idev returned by __in6_dev_get() in both\nseg6_hmac_validate_skb() and ipv6_srh_rcv() to prevent potential NULL\npointer dereferences."
}
],
"providerMetadata": {
"dateUpdated": "2026-06-01T16:11:11.872Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/0348fa0ada37cef7c6b5ab2a428bb2c6aee784e4"
},
{
"url": "https://git.kernel.org/stable/c/83d705d35e583cb1b1eacf196dfe7b77d442018e"
},
{
"url": "https://git.kernel.org/stable/c/d1bd8b9edc6752d10f84d28ff64f842401ce336d"
},
{
"url": "https://git.kernel.org/stable/c/50352fc103928e10e8729abc79a0d05abef26c4d"
},
{
"url": "https://git.kernel.org/stable/c/bc9843c39f9932a8b36efd1d362ea00bb88e4e78"
},
{
"url": "https://git.kernel.org/stable/c/c5cedee5d97382176573bbe21e1724e737a5eb64"
},
{
"url": "https://git.kernel.org/stable/c/a25853c9feea7bbf31d157ff6e004d2d3b4f7f13"
},
{
"url": "https://git.kernel.org/stable/c/06413793526251870e20402c39930804f14d59c0"
}
],
"title": "ipv6: add NULL checks for idev in SRv6 paths",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2026-23442",
"datePublished": "2026-04-03T15:15:26.851Z",
"dateReserved": "2026-01-13T15:37:46.018Z",
"dateUpdated": "2026-06-01T16:11:11.872Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"epss": {
"cve": "CVE-2026-23442",
"date": "2026-09-19",
"epss": "0.00123",
"percentile": "0.02347"
},
"microsoft_vex": {
"current_release_date": "2026-05-02T14:38:31.000Z",
"cve": "CVE-2026-23442",
"id": "msrc_CVE-2026-23442",
"initial_release_date": "2026-04-02T00:00:00.000Z",
"product_status:fixed": "1",
"product_status:known_affected": "3",
"source": "Microsoft CSAF VEX",
"status": "final",
"title": "ipv6: add NULL checks for idev in SRv6 paths",
"url": "https://msrc.microsoft.com/csaf/vex/2026/msrc_cve-2026-23442.json",
"version": "5"
},
"nvd": {
"cve": {
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"net/ipv6/exthdrs.c",
"net/ipv6/seg6_hmac.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "0348fa0ada37cef7c6b5ab2a428bb2c6aee784e4",
"status": "affected",
"version": "1ababeba4a21f3dba3da3523c670b207fb2feb62",
"versionType": "git"
},
{
"lessThan": "83d705d35e583cb1b1eacf196dfe7b77d442018e",
"status": "affected",
"version": "1ababeba4a21f3dba3da3523c670b207fb2feb62",
"versionType": "git"
},
{
"lessThan": "d1bd8b9edc6752d10f84d28ff64f842401ce336d",
"status": "affected",
"version": "1ababeba4a21f3dba3da3523c670b207fb2feb62",
"versionType": "git"
},
{
"lessThan": "50352fc103928e10e8729abc79a0d05abef26c4d",
"status": "affected",
"version": "1ababeba4a21f3dba3da3523c670b207fb2feb62",
"versionType": "git"
},
{
"lessThan": "bc9843c39f9932a8b36efd1d362ea00bb88e4e78",
"status": "affected",
"version": "1ababeba4a21f3dba3da3523c670b207fb2feb62",
"versionType": "git"
},
{
"lessThan": "c5cedee5d97382176573bbe21e1724e737a5eb64",
"status": "affected",
"version": "1ababeba4a21f3dba3da3523c670b207fb2feb62",
"versionType": "git"
},
{
"lessThan": "a25853c9feea7bbf31d157ff6e004d2d3b4f7f13",
"status": "affected",
"version": "1ababeba4a21f3dba3da3523c670b207fb2feb62",
"versionType": "git"
},
{
"lessThan": "06413793526251870e20402c39930804f14d59c0",
"status": "affected",
"version": "1ababeba4a21f3dba3da3523c670b207fb2feb62",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"net/ipv6/exthdrs.c",
"net/ipv6/seg6_hmac.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "4.10"
},
{
"lessThan": "4.10",
"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.136",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.83",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.18.*",
"status": "unaffected",
"version": "6.18.25",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.19.*",
"status": "unaffected",
"version": "6.19.10",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "7.0",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"configurations": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "C9FB8914-AA64-42C8-B1C5-31091B1EAA92",
"versionEndExcluding": "6.12.83",
"versionStartIncluding": "4.10.1",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "74050944-3704-4081-A5DA-C5DAB1E275E6",
"versionEndExcluding": "6.19.10",
"versionStartIncluding": "6.13",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:4.10:-:*:*:*:*:*:*",
"matchCriteriaId": "C201E405-86F2-4F96-984A-00A865219C86",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:7.0:rc1:*:*:*:*:*:*",
"matchCriteriaId": "F253B622-8837-4245-BCE5-A7BF8FC76A16",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:7.0:rc2:*:*:*:*:*:*",
"matchCriteriaId": "4AE85AD8-4641-4E7C-A2F4-305E2CD9EE64",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:7.0:rc3:*:*:*:*:*:*",
"matchCriteriaId": "F666C8D8-6538-46D4-B318-87610DE64C34",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:7.0:rc4:*:*:*:*:*:*",
"matchCriteriaId": "02259FDA-961B-47BC-AE7F-93D7EC6E90C2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:7.0:rc5:*:*:*:*:*:*",
"matchCriteriaId": "58A9FEFF-C040-420D-8F0A-BFDAAA1DF258",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:7.0:rc6:*:*:*:*:*:*",
"matchCriteriaId": "1D2315C0-D46F-4F85-9754-F9E5E11374A6",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:7.0:rc7:*:*:*:*:*:*",
"matchCriteriaId": "512EE3A8-A590-4501-9A94-5D4B268D6138",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nipv6: add NULL checks for idev in SRv6 paths\n\n__in6_dev_get() can return NULL when the device has no IPv6 configuration\n(e.g. MTU \u003c IPV6_MIN_MTU or after NETDEV_UNREGISTER).\n\nAdd NULL checks for idev returned by __in6_dev_get() in both\nseg6_hmac_validate_skb() and ipv6_srh_rcv() to prevent potential NULL\npointer dereferences."
},
{
"lang": "es",
"value": "En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:\n\nipv6: a\u00f1adir comprobaciones de NULL para idev en las rutas SRv6\n\n__in6_dev_get() puede devolver NULL cuando el dispositivo no tiene configuraci\u00f3n IPv6 (p. ej., MTU \u003c IPV6_MIN_MTU o despu\u00e9s de NETDEV_UNREGISTER).\n\nA\u00f1adir comprobaciones de NULL para idev devuelto por __in6_dev_get() tanto en seg6_hmac_validate_skb() como en ipv6_srh_rcv() para prevenir posibles desreferencias de puntero NULL."
}
],
"id": "CVE-2026-23442",
"lastModified": "2026-07-24T21:10:00.143",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 5.5,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 3.6,
"source": "nvd@nist.gov",
"type": "Primary"
}
]
},
"published": "2026-04-03T16:16:28.423",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/0348fa0ada37cef7c6b5ab2a428bb2c6aee784e4"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/06413793526251870e20402c39930804f14d59c0"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/50352fc103928e10e8729abc79a0d05abef26c4d"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/83d705d35e583cb1b1eacf196dfe7b77d442018e"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/a25853c9feea7bbf31d157ff6e004d2d3b4f7f13"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/bc9843c39f9932a8b36efd1d362ea00bb88e4e78"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/c5cedee5d97382176573bbe21e1724e737a5eb64"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/d1bd8b9edc6752d10f84d28ff64f842401ce336d"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Modified",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "CWE-476"
}
],
"source": "nvd@nist.gov",
"type": "Primary"
}
]
}
},
"redhat_vex": {
"aggregate_severity": "Moderate",
"current_release_date": "2026-09-11T10:33:47+00:00",
"cve": "CVE-2026-23442",
"id": "CVE-2026-23442",
"initial_release_date": "2026-04-03T00:00:00+00:00",
"product_status:fixed": "309",
"product_status:known_affected": "170",
"product_status:known_not_affected": "28",
"source": "Red Hat CSAF VEX",
"status": "final",
"title": "kernel: ipv6: add NULL checks for idev in SRv6 paths",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-23442.json",
"version": "3"
},
"suse_vex": {
"aggregate_severity": "moderate",
"current_release_date": "2026-09-12T16:43:19Z",
"cve": "CVE-2026-23442",
"id": "CVE-2026-23442",
"initial_release_date": "2026-04-03T23:27:43Z",
"product_status:first_fixed": "2",
"product_status:known_affected": "270",
"product_status:known_not_affected": "6",
"product_status:recommended": "345",
"source": "SUSE CSAF VEX",
"status": "interim",
"title": "SUSE CVE CVE-2026-23442",
"url": "https://ftp.suse.com/pub/projects/security/csaf-vex/cve-2026-23442.json",
"version": "21"
}
}
}
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"
}
]
}
FKIE_CVE-2026-23442
Vulnerability from fkie_nvd - Published: 2026-04-03 16:16 - Updated: 2026-07-24 21:10| URL | Tags | ||
|---|---|---|---|
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/0348fa0ada37cef7c6b5ab2a428bb2c6aee784e4 | ||
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/06413793526251870e20402c39930804f14d59c0 | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/50352fc103928e10e8729abc79a0d05abef26c4d | ||
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/83d705d35e583cb1b1eacf196dfe7b77d442018e | ||
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/a25853c9feea7bbf31d157ff6e004d2d3b4f7f13 | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/bc9843c39f9932a8b36efd1d362ea00bb88e4e78 | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/c5cedee5d97382176573bbe21e1724e737a5eb64 | ||
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/d1bd8b9edc6752d10f84d28ff64f842401ce336d |
| Vendor | Product | Version | |
|---|---|---|---|
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | 4.10 | |
| linux | linux_kernel | 7.0 | |
| linux | linux_kernel | 7.0 | |
| linux | linux_kernel | 7.0 | |
| linux | linux_kernel | 7.0 | |
| linux | linux_kernel | 7.0 | |
| linux | linux_kernel | 7.0 | |
| linux | linux_kernel | 7.0 |
{
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"net/ipv6/exthdrs.c",
"net/ipv6/seg6_hmac.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "0348fa0ada37cef7c6b5ab2a428bb2c6aee784e4",
"status": "affected",
"version": "1ababeba4a21f3dba3da3523c670b207fb2feb62",
"versionType": "git"
},
{
"lessThan": "83d705d35e583cb1b1eacf196dfe7b77d442018e",
"status": "affected",
"version": "1ababeba4a21f3dba3da3523c670b207fb2feb62",
"versionType": "git"
},
{
"lessThan": "d1bd8b9edc6752d10f84d28ff64f842401ce336d",
"status": "affected",
"version": "1ababeba4a21f3dba3da3523c670b207fb2feb62",
"versionType": "git"
},
{
"lessThan": "50352fc103928e10e8729abc79a0d05abef26c4d",
"status": "affected",
"version": "1ababeba4a21f3dba3da3523c670b207fb2feb62",
"versionType": "git"
},
{
"lessThan": "bc9843c39f9932a8b36efd1d362ea00bb88e4e78",
"status": "affected",
"version": "1ababeba4a21f3dba3da3523c670b207fb2feb62",
"versionType": "git"
},
{
"lessThan": "c5cedee5d97382176573bbe21e1724e737a5eb64",
"status": "affected",
"version": "1ababeba4a21f3dba3da3523c670b207fb2feb62",
"versionType": "git"
},
{
"lessThan": "a25853c9feea7bbf31d157ff6e004d2d3b4f7f13",
"status": "affected",
"version": "1ababeba4a21f3dba3da3523c670b207fb2feb62",
"versionType": "git"
},
{
"lessThan": "06413793526251870e20402c39930804f14d59c0",
"status": "affected",
"version": "1ababeba4a21f3dba3da3523c670b207fb2feb62",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"net/ipv6/exthdrs.c",
"net/ipv6/seg6_hmac.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "4.10"
},
{
"lessThan": "4.10",
"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.136",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.83",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.18.*",
"status": "unaffected",
"version": "6.18.25",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.19.*",
"status": "unaffected",
"version": "6.19.10",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "7.0",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"configurations": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "C9FB8914-AA64-42C8-B1C5-31091B1EAA92",
"versionEndExcluding": "6.12.83",
"versionStartIncluding": "4.10.1",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "74050944-3704-4081-A5DA-C5DAB1E275E6",
"versionEndExcluding": "6.19.10",
"versionStartIncluding": "6.13",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:4.10:-:*:*:*:*:*:*",
"matchCriteriaId": "C201E405-86F2-4F96-984A-00A865219C86",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:7.0:rc1:*:*:*:*:*:*",
"matchCriteriaId": "F253B622-8837-4245-BCE5-A7BF8FC76A16",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:7.0:rc2:*:*:*:*:*:*",
"matchCriteriaId": "4AE85AD8-4641-4E7C-A2F4-305E2CD9EE64",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:7.0:rc3:*:*:*:*:*:*",
"matchCriteriaId": "F666C8D8-6538-46D4-B318-87610DE64C34",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:7.0:rc4:*:*:*:*:*:*",
"matchCriteriaId": "02259FDA-961B-47BC-AE7F-93D7EC6E90C2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:7.0:rc5:*:*:*:*:*:*",
"matchCriteriaId": "58A9FEFF-C040-420D-8F0A-BFDAAA1DF258",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:7.0:rc6:*:*:*:*:*:*",
"matchCriteriaId": "1D2315C0-D46F-4F85-9754-F9E5E11374A6",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:7.0:rc7:*:*:*:*:*:*",
"matchCriteriaId": "512EE3A8-A590-4501-9A94-5D4B268D6138",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nipv6: add NULL checks for idev in SRv6 paths\n\n__in6_dev_get() can return NULL when the device has no IPv6 configuration\n(e.g. MTU \u003c IPV6_MIN_MTU or after NETDEV_UNREGISTER).\n\nAdd NULL checks for idev returned by __in6_dev_get() in both\nseg6_hmac_validate_skb() and ipv6_srh_rcv() to prevent potential NULL\npointer dereferences."
},
{
"lang": "es",
"value": "En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:\n\nipv6: a\u00f1adir comprobaciones de NULL para idev en las rutas SRv6\n\n__in6_dev_get() puede devolver NULL cuando el dispositivo no tiene configuraci\u00f3n IPv6 (p. ej., MTU \u003c IPV6_MIN_MTU o despu\u00e9s de NETDEV_UNREGISTER).\n\nA\u00f1adir comprobaciones de NULL para idev devuelto por __in6_dev_get() tanto en seg6_hmac_validate_skb() como en ipv6_srh_rcv() para prevenir posibles desreferencias de puntero NULL."
}
],
"id": "CVE-2026-23442",
"lastModified": "2026-07-24T21:10:00.143",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 5.5,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 3.6,
"source": "nvd@nist.gov",
"type": "Primary"
}
]
},
"published": "2026-04-03T16:16:28.423",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/0348fa0ada37cef7c6b5ab2a428bb2c6aee784e4"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/06413793526251870e20402c39930804f14d59c0"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/50352fc103928e10e8729abc79a0d05abef26c4d"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/83d705d35e583cb1b1eacf196dfe7b77d442018e"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/a25853c9feea7bbf31d157ff6e004d2d3b4f7f13"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/bc9843c39f9932a8b36efd1d362ea00bb88e4e78"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/c5cedee5d97382176573bbe21e1724e737a5eb64"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/d1bd8b9edc6752d10f84d28ff64f842401ce336d"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Modified",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "CWE-476"
}
],
"source": "nvd@nist.gov",
"type": "Primary"
}
]
}
GHSA-PRGG-RGFW-VR94
Vulnerability from github – Published: 2026-04-03 18:31 – Updated: 2026-06-01 18:31In the Linux kernel, the following vulnerability has been resolved:
ipv6: add NULL checks for idev in SRv6 paths
__in6_dev_get() can return NULL when the device has no IPv6 configuration (e.g. MTU < IPV6_MIN_MTU or after NETDEV_UNREGISTER).
Add NULL checks for idev returned by __in6_dev_get() in both seg6_hmac_validate_skb() and ipv6_srh_rcv() to prevent potential NULL pointer dereferences.
{
"affected": [],
"aliases": [
"CVE-2026-23442"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-03T16:16:28Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nipv6: add NULL checks for idev in SRv6 paths\n\n__in6_dev_get() can return NULL when the device has no IPv6 configuration\n(e.g. MTU \u003c IPV6_MIN_MTU or after NETDEV_UNREGISTER).\n\nAdd NULL checks for idev returned by __in6_dev_get() in both\nseg6_hmac_validate_skb() and ipv6_srh_rcv() to prevent potential NULL\npointer dereferences.",
"id": "GHSA-prgg-rgfw-vr94",
"modified": "2026-06-01T18:31:23Z",
"published": "2026-04-03T18:31:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23442"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0348fa0ada37cef7c6b5ab2a428bb2c6aee784e4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/06413793526251870e20402c39930804f14d59c0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/50352fc103928e10e8729abc79a0d05abef26c4d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/83d705d35e583cb1b1eacf196dfe7b77d442018e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a25853c9feea7bbf31d157ff6e004d2d3b4f7f13"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bc9843c39f9932a8b36efd1d362ea00bb88e4e78"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c5cedee5d97382176573bbe21e1724e737a5eb64"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d1bd8b9edc6752d10f84d28ff64f842401ce336d"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
MSRC_CVE-2026-23442
Vulnerability from csaf_microsoft - Published: 2026-04-02 00:00 - Updated: 2026-05-02 14:38OESA-2026-2172 (CVE-2025-27558)
Vulnerability from osv_openeuler – Published: 2026-05-03 11:11 – Updated: 2026-08-06 11:11 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
IEEE P802.11-REVme D1.1 through D7.0 allows FragAttacks against mesh networks. In mesh networks using Wi-Fi Protected Access (WPA, WPA2, or WPA3) or Wired Equivalent Privacy (WEP), an adversary can exploit this vulnerability to inject arbitrary frames towards devices that support receiving non-SSP A-MSDU frames. NOTE: this issue exists because of an incorrect fix for CVE-2020-24588. P802.11-REVme, as of early 2025, is a planned release of the 802.11 standard.(CVE-2025-27558)
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:
icmp: fix NULL pointer dereference in icmp_tag_validation()
icmp_tag_validation() unconditionally dereferences the result of rcu_dereference(inet_protos[proto]) without checking for NULL. The inet_protos[] array is sparse -- only about 15 of 256 protocol numbers have registered handlers. When ip_no_pmtu_disc is set to 3 (hardened PMTU mode) and the kernel receives an ICMP Fragmentation Needed error with a quoted inner IP header containing an unregistered protocol number, the NULL dereference causes a kernel panic in softirq context.
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] RIP: 0010:icmp_unreach (net/ipv4/icmp.c:1085 net/ipv4/icmp.c:1143) Call Trace: <IRQ> icmp_rcv (net/ipv4/icmp.c:1527) ip_protocol_deliver_rcu (net/ipv4/ip_input.c:207) ip_local_deliver_finish (net/ipv4/ip_input.c:242) ip_local_deliver (net/ipv4/ip_input.c:262) ip_rcv (net/ipv4/ip_input.c:573) __netif_receive_skb_one_core (net/core/dev.c:6164) process_backlog (net/core/dev.c:6628) handle_softirqs (kernel/softirq.c:561) </IRQ>
Add a NULL check before accessing icmp_strict_tag_validation. If the protocol has no registered handler, return false since it cannot perform strict tag validation.(CVE-2026-23398)
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)
In the Linux kernel, the following vulnerability has been resolved:
ipv6: add NULL checks for idev in SRv6 paths
__in6_dev_get() can return NULL when the device has no IPv6 configuration (e.g. MTU < IPV6_MIN_MTU or after NETDEV_UNREGISTER).
Add NULL checks for idev returned by __in6_dev_get() in both seg6_hmac_validate_skb() and ipv6_srh_rcv() to prevent potential NULL pointer dereferences.(CVE-2026-23442)
In the Linux kernel, the following vulnerability has been resolved:
net: usb: cdc_ncm: add ndpoffset to NDP32 nframes bounds check
The same bounds-check bug fixed for NDP16 in the previous patch also exists in cdc_ncm_rx_verify_ndp32(). The DPE array size is validated against the total skb length without accounting for ndpoffset, allowing out-of-bounds reads when the NDP32 is placed near the end of the NTB.
Add ndpoffset to the nframes bounds check and use struct_size_t() to express the NDP-plus-DPE-array size more clearly.
Compile-tested only.(CVE-2026-23447)
In the Linux kernel, the following vulnerability has been resolved:
net/sched: teql: Fix double-free in teql_master_xmit
Whenever a TEQL devices has a lockless Qdisc as root, qdisc_reset should be called using the seq_lock to avoid racing with the datapath. Failure to do so may cause crashes like the following:
[ 238.028993][ T318] BUG: KASAN: double-free in skb_release_data (net/core/skbuff.c:1139) [ 238.029328][ T318] Free of addr ffff88810c67ec00 by task poc_teql_uaf_ke/318 [ 238.029749][ T318] [ 238.029900][ T318] CPU: 3 UID: 0 PID: 318 Comm: poc_teql_ke Not tainted 7.0.0-rc3-00149-ge5b31d988a41 #704 PREEMPT(full) [ 238.029906][ T318] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 238.029910][ T318] Call Trace: [ 238.029913][ T318] <TASK> [ 238.029916][ T318] dump_stack_lvl (lib/dump_stack.c:122) [ 238.029928][ T318] print_report (mm/kasan/report.c:379 mm/kasan/report.c:482) [ 238.029940][ T318] ? skb_release_data (net/core/skbuff.c:1139) [ 238.029944][ T318] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) ... [ 238.029957][ T318] ? skb_release_data (net/core/skbuff.c:1139) [ 238.029969][ T318] kasan_report_invalid_free (mm/kasan/report.c:221 mm/kasan/report.c:563) [ 238.029979][ T318] ? skb_release_data (net/core/skbuff.c:1139) [ 238.029989][ T318] check_slab_allocation (mm/kasan/common.c:231) [ 238.029995][ T318] kmem_cache_free (mm/slub.c:2637 (discriminator 1) mm/slub.c:6168 (discriminator 1) mm/slub.c:6298 (discriminator 1)) [ 238.030004][ T318] skb_release_data (net/core/skbuff.c:1139) ... [ 238.030025][ T318] sk_skb_reason_drop (net/core/skbuff.c:1256) [ 238.030032][ T318] pfifo_fast_reset (./include/linux/ptr_ring.h:171 ./include/linux/ptr_ring.h:309 ./include/linux/skb_array.h:98 net/sched/sch_generic.c:827) [ 238.030039][ T318] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) ... [ 238.030054][ T318] qdisc_reset (net/sched/sch_generic.c:1034) [ 238.030062][ T318] teql_destroy (./include/linux/spinlock.h:395 net/sched/sch_teql.c:157) [ 238.030071][ T318] __qdisc_destroy (./include/net/pkt_sched.h:328 net/sched/sch_generic.c:1077) [ 238.030077][ T318] qdisc_graft (net/sched/sch_api.c:1062 net/sched/sch_api.c:1053 net/sched/sch_api.c:1159) [ 238.030089][ T318] ? __pfx_qdisc_graft (net/sched/sch_api.c:1091) [ 238.030095][ T318] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 238.030102][ T318] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 238.030106][ T318] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 238.030114][ T318] tc_get_qdisc (net/sched/sch_api.c:1529 net/sched/sch_api.c:1556) ... [ 238.072958][ T318] Allocated by task 303 on cpu 5 at 238.026275s: [ 238.073392][ T318] kasan_save_stack (mm/kasan/common.c:58) [ 238.073884][ T318] kasan_save_track (mm/kasan/common.c:64 (discriminator 5) mm/kasan/common.c:79 (discriminator 5)) [ 238.074230][ T318] __kasan_slab_alloc (mm/kasan/common.c:369) [ 238.074578][ T318] kmem_cache_alloc_node_noprof (./include/linux/kasan.h:253 mm/slub.c:4542 mm/slub.c:4869 mm/slub.c:4921) [ 238.076091][ T318] kmalloc_reserve (net/core/skbuff.c:616 (discriminator 107)) [ 238.076450][ T318] __alloc_skb (net/core/skbuff.c:713) [ 238.076834][ T318] alloc_skb_with_frags (./include/linux/skbuff.h:1383 net/core/skbuff.c:6763) [ 238.077178][ T318] sock_alloc_send_pskb (net/core/sock.c:2997) [ 238.077520][ T318] packet_sendmsg (net/packet/af_packet.c:2926 net/packet/af_packet.c:3019 net/packet/af_packet.c:3108) [ 238.081469][ T318] [ 238.081870][ T318] Freed by task 299 on cpu 1 at 238.028496s: [ 238.082761][ T318] kasan_save_stack (mm/kasan/common.c:58) [ 238.083481][ T318] kasan_save_track (mm/kasan/common.c:64 (discriminator 5) mm/kasan/common.c:79 (discriminator 5)) [ 238.085348][ T318] kasan_save_free_info (mm/kasan/generic.c:587 (discriminator 1)) [ 238.085900][ T318] __kasan_slab_free (mm/ ---truncated---(CVE-2026-23449)
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:
netfilter: nf_conntrack_h323: check for zero length in DecodeQ931()
In DecodeQ931(), the UserUserIE code path reads a 16-bit length from the packet, then decrements it by 1 to skip the protocol discriminator byte before passing it to DecodeH323_UserInformation(). If the encoded length is 0, the decrement wraps to -1, which is then passed as a large value to the decoder, leading to an out-of-bounds read.
Add a check to ensure len is positive after the decrement.(CVE-2026-23455)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_conntrack_h323: fix OOB read in decode_int() CONS case
In decode_int(), the CONS case calls get_bits(bs, 2) to read a length value, then calls get_uint(bs, len) without checking that len bytes remain in the buffer. The existing boundary check only validates the 2 bits for get_bits(), not the subsequent 1-4 bytes that get_uint() reads. This allows a malformed H.323/RAS packet to cause a 1-4 byte slab-out-of-bounds read.
Add a boundary check for len bytes after get_bits() and before get_uint().(CVE-2026-23456)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_conntrack_sip: fix Content-Length u32 truncation in sip_help_tcp()
sip_help_tcp() parses the SIP Content-Length header with simple_strtoul(), which returns unsigned long, but stores the result in unsigned int clen. On 64-bit systems, values exceeding UINT_MAX are silently truncated before computing the SIP message boundary.
For example, Content-Length 4294967328 (2^32 + 32) is truncated to 32, causing the parser to miscalculate where the current message ends. The loop then treats trailing data in the TCP segment as a second SIP message and processes it through the SDP parser.
Fix this by changing clen to unsigned long to match the return type of simple_strtoul(), and reject Content-Length values that exceed the remaining TCP payload length.(CVE-2026-23457)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: ctnetlink: fix use-after-free in ctnetlink_dump_exp_ct()
ctnetlink_dump_exp_ct() stores a conntrack pointer in cb->data for the netlink dump callback ctnetlink_exp_ct_dump_table(), but drops the conntrack reference immediately after netlink_dump_start(). When the dump spans multiple rounds, the second recvmsg() triggers the dump callback which dereferences the now-freed conntrack via nfct_help(ct), leading to a use-after-free on ct->ext.
The bug is that the netlink_dump_control has no .start or .done callbacks to manage the conntrack reference across dump rounds. Other dump functions in the same file (e.g. ctnetlink_get_conntrack) properly use .start/.done callbacks for this purpose.
Fix this by adding .start and .done callbacks that hold and release the conntrack reference for the duration of the dump, and move the nfct_help() call after the cb->args[0] early-return check in the dump callback to avoid dereferencing ct->ext unnecessarily.
BUG: KASAN: slab-use-after-free in ctnetlink_exp_ct_dump_table+0x4f/0x2e0 Read of size 8 at addr ffff88810597ebf0 by task ctnetlink_poc/133
CPU: 1 UID: 0 PID: 133 Comm: ctnetlink_poc Not tainted 7.0.0-rc2+ #3 PREEMPTLAZY Call Trace: <TASK> ctnetlink_exp_ct_dump_table+0x4f/0x2e0 netlink_dump+0x333/0x880 netlink_recvmsg+0x3e2/0x4b0 ? aa_sk_perm+0x184/0x450 sock_recvmsg+0xde/0xf0
Allocated by task 133: kmem_cache_alloc_noprof+0x134/0x440 __nf_conntrack_alloc+0xa8/0x2b0 ctnetlink_create_conntrack+0xa1/0x900 ctnetlink_new_conntrack+0x3cf/0x7d0 nfnetlink_rcv_msg+0x48e/0x510 netlink_rcv_skb+0xc9/0x1f0 nfnetlink_rcv+0xdb/0x220 netlink_unicast+0x3ec/0x590 netlink_sendmsg+0x397/0x690 __sys_sendmsg+0xf4/0x180
Freed by task 0: slab_free_after_rcu_debug+0xad/0x1e0 rcu_core+0x5c3/0x9c0(CVE-2026-23458)
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:
spi: fix use-after-free on controller registration failure
Make sure to deregister from driver core also in the unlikely event that per-cpu statistics allocation fails during controller registration to avoid use-after-free (of driver resources) and unclocked register accesses.(CVE-2026-31389)
In the Linux kernel, the following vulnerability has been resolved:
ipv6: avoid overflows in ip6_datagram_send_ctl()
Yiming Qian reported :
<quote>
I believe I found a locally triggerable kernel bug in the IPv6 sendmsg
ancillary-data path that can panic the kernel via skb_under_panic()
(local DoS).
The core issue is a mismatch between:
- a 16-bit length accumulator (
struct ipv6_txoptions::opt_flen, type__u16) and - a pointer to the last provided destination-options header (
opt->dst1opt)
when multiple IPV6_DSTOPTS control messages (cmsgs) are provided.
include/net/ipv6.h:struct ipv6_txoptions::opt_flenis__u16(wrap possible). (lines 291-307, especially 298)net/ipv6/datagram.c:ip6_datagram_send_ctl():- Accepts repeated
IPV6_DSTOPTSand accumulates intoopt_flenwithout rejecting duplicates. (lines 909-933) net/ipv6/ip6_output.c:__ip6_append_data():- Uses
opt->opt_flen + opt->opt_nflento compute header sizes/headroom decisions. (lines 1448-1466, especially 1463-1465) net/ipv6/ip6_output.c:__ip6_make_skb():- Calls
ipv6_push_frag_opts()ifopt->opt_flenis non-zero. (lines 1930-1934) net/ipv6/exthdrs.c:ipv6_push_frag_opts()/ipv6_push_exthdr():-
Push size comes from
ipv6_optlen(opt->dst1opt)(based on the pointed-to header). (lines 1179-1185 and 1206-1211) -
opt_flenis a 16-bit accumulator: -
include/net/ipv6.h:298defines__u16 opt_flen; /* after fragment hdr */. -
ip6_datagram_send_ctl()accepts repeatedIPV6_DSTOPTScmsgs and incrementsopt_fleneach time: -
In
net/ipv6/datagram.c:909-933, forIPV6_DSTOPTS: - It computes
len = ((hdr->hdrlen + 1) << 3); - It checks
CAP_NET_RAWusingns_capable(net->user_ns, CAP_NET_RAW). (line 922) - Then it does:
opt->opt_flen += len;(line 927)opt->dst1opt = hdr;(line 928)
There is no duplicate rejection here (unlike the legacy
IPV6_2292DSTOPTS path which rejects duplicates at
net/ipv6/datagram.c:901-904).
If enough large IPV6_DSTOPTS cmsgs are provided, opt_flen wraps
while dst1opt still points to a large (2048-byte)
destination-options header.
In the attached PoC (poc.c):
- 32 cmsgs with
hdrlen=255=>len = (255+1)*8 = 2048 - 1 cmsg with
hdrlen=0=>len = 8 - Total increment:
32*2048 + 8 = 65544, so(__u16)opt_flen == 8 -
The last cmsg is 2048 bytes, so
dst1optpoints to a 2048-byte header. -
The transmit path sizes headers using the wrapped
opt_flen: -
In
net/ipv6/ip6_output.c:1463-1465: headersize = sizeof(struct ipv6hdr) + (opt ? opt->opt_flen + opt->opt_nflen : 0) + ...;
With wrapped opt_flen, headersize/headroom decisions underestimate
what will be pushed later.
-
When building the final skb, the actual push length comes from
dst1optand is not limited by wrappedopt_flen: -
In
net/ipv6/ip6_output.c:1930-1934: if (opt->opt_flen) proto = ipv6_push_frag_opts(skb, opt, proto);- In
net/ipv6/exthdrs.c:1206-1211,ipv6_push_frag_opts()pushesdst1optviaipv6_push_exthdr(). - In
net/ipv6/exthdrs.c:1179-1184,ipv6_push_exthdr()does: skb_push(skb, ipv6_optlen(opt));memcpy(h, opt, ipv6_optlen(opt));
With insufficient headroom, skb_push() underflows and triggers
skb_under_panic() -> BUG():
net/core/skbuff.c:2669-2675(skb_push()callsskb_under_panic())-
net/core/skbuff.c:207-214(skb_panic()ends inBUG()) -
The
IPV6_DSTOPTScmsg path requiresCAP_NET_RAWin the target netns user namespace (ns_capable(net->user_ns, CAP_NET_RAW)). - Root (or any task with
CAP_NET_RAW) can trigger this without user namespaces. -
An unprivileged
uid=1000user can trigger this if unprivileged user namespaces are enabled and it can create a userns+netns to obtain namespacedCAP_NET_RAW(the attached PoC does this). -
Local denial of service: kernel BUG/panic (system crash). - ---truncated---(CVE-2026-31415)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nfnetlink_log: account for netlink header size
This is a followup to an old bug fix: NLMSG_DONE needs to account for the netlink header size, not just the attribute size.
This can result in a WARN splat + drop of the netlink message, but other than this there are no ill effects.(CVE-2026-31416)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_conntrack_sip: fix use of uninitialized rtp_addr in process_sdp
process_sdp() declares union nf_inet_addr rtp_addr on the stack and passes it to the nf_nat_sip sdp_session hook after walking the SDP media descriptions. However rtp_addr is only initialized inside the media loop when a recognized media type with a non-zero port is found.
If the SDP body contains no m= lines, only inactive media sections (m=audio 0 ...) or only unrecognized media types, rtp_addr is never assigned. Despite that, the function still calls hooks->sdp_session() with &rtp_addr, causing nf_nat_sdp_session() to format the stale stack value as an IP address and rewrite the SDP session owner and connection lines with it.
With CONFIG_INIT_STACK_ALL_ZERO (default on most distributions) this results in the session-level o= and c= addresses being rewritten to 0.0.0.0 for inactive SDP sessions. Without stack auto-init the rewritten address is whatever happened to be on the stack.
Fix this by pre-initializing rtp_addr from the session-level connection address (caddr) when available, and tracking via a have_rtp_addr flag whether any valid address was established. Skip the sdp_session hook entirely when no valid address exists.(CVE-2026-31427)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nfnetlink_log: fix uninitialized padding leak in NFULA_PAYLOAD
__build_packet_message() manually constructs the NFULA_PAYLOAD netlink attribute using skb_put() and skb_copy_bits(), bypassing the standard nla_reserve()/nla_put() helpers. While nla_total_size(data_len) bytes are allocated (including NLA alignment padding), only data_len bytes of actual packet data are copied. The trailing nla_padlen(data_len) bytes (1-3 when data_len is not 4-byte aligned) are never initialized, leaking stale heap contents to userspace via the NFLOG netlink socket.
Replace the manual attribute construction with nla_reserve(), which handles the tailroom check, header setup, and padding zeroing via __nla_reserve(). The subsequent skb_copy_bits() fills in the payload data on top of the properly initialized attribute.(CVE-2026-31428)
In the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: algif_aead - Revert to operating out-of-place\n\nThis mostly reverts commit 72548b093ee3 except for the copying of the associated data.\n\nThere is no benefit in operating in-place in algif_aead since the source and destination come from different mappings. Get rid of all the complexity added for in-place operation and just copy the AD directly.(CVE-2026-31431)
| URL | Type | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-6.6.0-145.0.7.146.oe2403sp1.aarch64.rpm",
"bpftool-debuginfo-6.6.0-145.0.7.146.oe2403sp1.aarch64.rpm",
"kernel-6.6.0-145.0.7.146.oe2403sp1.aarch64.rpm",
"kernel-debuginfo-6.6.0-145.0.7.146.oe2403sp1.aarch64.rpm",
"kernel-debugsource-6.6.0-145.0.7.146.oe2403sp1.aarch64.rpm",
"kernel-devel-6.6.0-145.0.7.146.oe2403sp1.aarch64.rpm",
"kernel-headers-6.6.0-145.0.7.146.oe2403sp1.aarch64.rpm",
"kernel-source-6.6.0-145.0.7.146.oe2403sp1.aarch64.rpm",
"kernel-tools-6.6.0-145.0.7.146.oe2403sp1.aarch64.rpm",
"kernel-tools-debuginfo-6.6.0-145.0.7.146.oe2403sp1.aarch64.rpm",
"kernel-tools-devel-6.6.0-145.0.7.146.oe2403sp1.aarch64.rpm",
"perf-6.6.0-145.0.7.146.oe2403sp1.aarch64.rpm",
"perf-debuginfo-6.6.0-145.0.7.146.oe2403sp1.aarch64.rpm",
"python3-perf-6.6.0-145.0.7.146.oe2403sp1.aarch64.rpm",
"python3-perf-debuginfo-6.6.0-145.0.7.146.oe2403sp1.aarch64.rpm"
],
"src": [
"kernel-6.6.0-145.0.7.146.oe2403sp1.src.rpm"
],
"x86_64": [
"bpftool-6.6.0-145.0.7.146.oe2403sp1.x86_64.rpm",
"bpftool-debuginfo-6.6.0-145.0.7.146.oe2403sp1.x86_64.rpm",
"kernel-6.6.0-145.0.7.146.oe2403sp1.x86_64.rpm",
"kernel-debuginfo-6.6.0-145.0.7.146.oe2403sp1.x86_64.rpm",
"kernel-debugsource-6.6.0-145.0.7.146.oe2403sp1.x86_64.rpm",
"kernel-devel-6.6.0-145.0.7.146.oe2403sp1.x86_64.rpm",
"kernel-headers-6.6.0-145.0.7.146.oe2403sp1.x86_64.rpm",
"kernel-source-6.6.0-145.0.7.146.oe2403sp1.x86_64.rpm",
"kernel-tools-6.6.0-145.0.7.146.oe2403sp1.x86_64.rpm",
"kernel-tools-debuginfo-6.6.0-145.0.7.146.oe2403sp1.x86_64.rpm",
"kernel-tools-devel-6.6.0-145.0.7.146.oe2403sp1.x86_64.rpm",
"perf-6.6.0-145.0.7.146.oe2403sp1.x86_64.rpm",
"perf-debuginfo-6.6.0-145.0.7.146.oe2403sp1.x86_64.rpm",
"python3-perf-6.6.0-145.0.7.146.oe2403sp1.x86_64.rpm",
"python3-perf-debuginfo-6.6.0-145.0.7.146.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.0.7.146.oe2403sp1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "Critical"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIEEE P802.11-REVme D1.1 through D7.0 allows FragAttacks against mesh networks. In mesh networks using Wi-Fi Protected Access (WPA, WPA2, or WPA3) or Wired Equivalent Privacy (WEP), an adversary can exploit this vulnerability to inject arbitrary frames towards devices that support receiving non-SSP A-MSDU frames. NOTE: this issue exists because of an incorrect fix for CVE-2020-24588. P802.11-REVme, as of early 2025, is a planned release of the 802.11 standard.(CVE-2025-27558)\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\nicmp: fix NULL pointer dereference in icmp_tag_validation()\n\nicmp_tag_validation() unconditionally dereferences the result of\nrcu_dereference(inet_protos[proto]) without checking for NULL.\nThe inet_protos[] array is sparse -- only about 15 of 256 protocol\nnumbers have registered handlers. When ip_no_pmtu_disc is set to 3\n(hardened PMTU mode) and the kernel receives an ICMP Fragmentation\nNeeded error with a quoted inner IP header containing an unregistered\nprotocol number, the NULL dereference causes a kernel panic in\nsoftirq context.\n\n Oops: general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] SMP KASAN NOPTI\n KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]\n RIP: 0010:icmp_unreach (net/ipv4/icmp.c:1085 net/ipv4/icmp.c:1143)\n Call Trace:\n \u0026lt;IRQ\u0026gt;\n icmp_rcv (net/ipv4/icmp.c:1527)\n ip_protocol_deliver_rcu (net/ipv4/ip_input.c:207)\n ip_local_deliver_finish (net/ipv4/ip_input.c:242)\n ip_local_deliver (net/ipv4/ip_input.c:262)\n ip_rcv (net/ipv4/ip_input.c:573)\n __netif_receive_skb_one_core (net/core/dev.c:6164)\n process_backlog (net/core/dev.c:6628)\n handle_softirqs (kernel/softirq.c:561)\n \u0026lt;/IRQ\u0026gt;\n\nAdd a NULL check before accessing icmp_strict_tag_validation. If the\nprotocol has no registered handler, return false since it cannot\nperform strict tag validation.(CVE-2026-23398)\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\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: add NULL checks for idev in SRv6 paths\n\n__in6_dev_get() can return NULL when the device has no IPv6 configuration\n(e.g. MTU \u0026lt; IPV6_MIN_MTU or after NETDEV_UNREGISTER).\n\nAdd NULL checks for idev returned by __in6_dev_get() in both\nseg6_hmac_validate_skb() and ipv6_srh_rcv() to prevent potential NULL\npointer dereferences.(CVE-2026-23442)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: usb: cdc_ncm: add ndpoffset to NDP32 nframes bounds check\n\nThe same bounds-check bug fixed for NDP16 in the previous patch also\nexists in cdc_ncm_rx_verify_ndp32(). The DPE array size is validated\nagainst the total skb length without accounting for ndpoffset, allowing\nout-of-bounds reads when the NDP32 is placed near the end of the NTB.\n\nAdd ndpoffset to the nframes bounds check and use struct_size_t() to\nexpress the NDP-plus-DPE-array size more clearly.\n\nCompile-tested only.(CVE-2026-23447)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: teql: Fix double-free in teql_master_xmit\n\nWhenever a TEQL devices has a lockless Qdisc as root, qdisc_reset should\nbe called using the seq_lock to avoid racing with the datapath. Failure\nto do so may cause crashes like the following:\n\n[ 238.028993][ T318] BUG: KASAN: double-free in skb_release_data (net/core/skbuff.c:1139)\n[ 238.029328][ T318] Free of addr ffff88810c67ec00 by task poc_teql_uaf_ke/318\n[ 238.029749][ T318]\n[ 238.029900][ T318] CPU: 3 UID: 0 PID: 318 Comm: poc_teql_ke Not tainted 7.0.0-rc3-00149-ge5b31d988a41 #704 PREEMPT(full)\n[ 238.029906][ T318] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011\n[ 238.029910][ T318] Call Trace:\n[ 238.029913][ T318] \u0026lt;TASK\u0026gt;\n[ 238.029916][ T318] dump_stack_lvl (lib/dump_stack.c:122)\n[ 238.029928][ T318] print_report (mm/kasan/report.c:379 mm/kasan/report.c:482)\n[ 238.029940][ T318] ? skb_release_data (net/core/skbuff.c:1139)\n[ 238.029944][ T318] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)\n...\n[ 238.029957][ T318] ? skb_release_data (net/core/skbuff.c:1139)\n[ 238.029969][ T318] kasan_report_invalid_free (mm/kasan/report.c:221 mm/kasan/report.c:563)\n[ 238.029979][ T318] ? skb_release_data (net/core/skbuff.c:1139)\n[ 238.029989][ T318] check_slab_allocation (mm/kasan/common.c:231)\n[ 238.029995][ T318] kmem_cache_free (mm/slub.c:2637 (discriminator 1) mm/slub.c:6168 (discriminator 1) mm/slub.c:6298 (discriminator 1))\n[ 238.030004][ T318] skb_release_data (net/core/skbuff.c:1139)\n...\n[ 238.030025][ T318] sk_skb_reason_drop (net/core/skbuff.c:1256)\n[ 238.030032][ T318] pfifo_fast_reset (./include/linux/ptr_ring.h:171 ./include/linux/ptr_ring.h:309 ./include/linux/skb_array.h:98 net/sched/sch_generic.c:827)\n[ 238.030039][ T318] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)\n...\n[ 238.030054][ T318] qdisc_reset (net/sched/sch_generic.c:1034)\n[ 238.030062][ T318] teql_destroy (./include/linux/spinlock.h:395 net/sched/sch_teql.c:157)\n[ 238.030071][ T318] __qdisc_destroy (./include/net/pkt_sched.h:328 net/sched/sch_generic.c:1077)\n[ 238.030077][ T318] qdisc_graft (net/sched/sch_api.c:1062 net/sched/sch_api.c:1053 net/sched/sch_api.c:1159)\n[ 238.030089][ T318] ? __pfx_qdisc_graft (net/sched/sch_api.c:1091)\n[ 238.030095][ T318] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)\n[ 238.030102][ T318] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)\n[ 238.030106][ T318] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)\n[ 238.030114][ T318] tc_get_qdisc (net/sched/sch_api.c:1529 net/sched/sch_api.c:1556)\n...\n[ 238.072958][ T318] Allocated by task 303 on cpu 5 at 238.026275s:\n[ 238.073392][ T318] kasan_save_stack (mm/kasan/common.c:58)\n[ 238.073884][ T318] kasan_save_track (mm/kasan/common.c:64 (discriminator 5) mm/kasan/common.c:79 (discriminator 5))\n[ 238.074230][ T318] __kasan_slab_alloc (mm/kasan/common.c:369)\n[ 238.074578][ T318] kmem_cache_alloc_node_noprof (./include/linux/kasan.h:253 mm/slub.c:4542 mm/slub.c:4869 mm/slub.c:4921)\n[ 238.076091][ T318] kmalloc_reserve (net/core/skbuff.c:616 (discriminator 107))\n[ 238.076450][ T318] __alloc_skb (net/core/skbuff.c:713)\n[ 238.076834][ T318] alloc_skb_with_frags (./include/linux/skbuff.h:1383 net/core/skbuff.c:6763)\n[ 238.077178][ T318] sock_alloc_send_pskb (net/core/sock.c:2997)\n[ 238.077520][ T318] packet_sendmsg (net/packet/af_packet.c:2926 net/packet/af_packet.c:3019 net/packet/af_packet.c:3108)\n[ 238.081469][ T318]\n[ 238.081870][ T318] Freed by task 299 on cpu 1 at 238.028496s:\n[ 238.082761][ T318] kasan_save_stack (mm/kasan/common.c:58)\n[ 238.083481][ T318] kasan_save_track (mm/kasan/common.c:64 (discriminator 5) mm/kasan/common.c:79 (discriminator 5))\n[ 238.085348][ T318] kasan_save_free_info (mm/kasan/generic.c:587 (discriminator 1))\n[ 238.085900][ T318] __kasan_slab_free (mm/\n---truncated---(CVE-2026-23449)\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\nnetfilter: nf_conntrack_h323: check for zero length in DecodeQ931()\n\nIn DecodeQ931(), the UserUserIE code path reads a 16-bit length from\nthe packet, then decrements it by 1 to skip the protocol discriminator\nbyte before passing it to DecodeH323_UserInformation(). If the encoded\nlength is 0, the decrement wraps to -1, which is then passed as a\nlarge value to the decoder, leading to an out-of-bounds read.\n\nAdd a check to ensure len is positive after the decrement.(CVE-2026-23455)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_conntrack_h323: fix OOB read in decode_int() CONS case\n\nIn decode_int(), the CONS case calls get_bits(bs, 2) to read a length\nvalue, then calls get_uint(bs, len) without checking that len bytes\nremain in the buffer. The existing boundary check only validates the\n2 bits for get_bits(), not the subsequent 1-4 bytes that get_uint()\nreads. This allows a malformed H.323/RAS packet to cause a 1-4 byte\nslab-out-of-bounds read.\n\nAdd a boundary check for len bytes after get_bits() and before\nget_uint().(CVE-2026-23456)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_conntrack_sip: fix Content-Length u32 truncation in sip_help_tcp()\n\nsip_help_tcp() parses the SIP Content-Length header with\nsimple_strtoul(), which returns unsigned long, but stores the result in\nunsigned int clen. On 64-bit systems, values exceeding UINT_MAX are\nsilently truncated before computing the SIP message boundary.\n\nFor example, Content-Length 4294967328 (2^32 + 32) is truncated to 32,\ncausing the parser to miscalculate where the current message ends. The\nloop then treats trailing data in the TCP segment as a second SIP\nmessage and processes it through the SDP parser.\n\nFix this by changing clen to unsigned long to match the return type of\nsimple_strtoul(), and reject Content-Length values that exceed the\nremaining TCP payload length.(CVE-2026-23457)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: ctnetlink: fix use-after-free in ctnetlink_dump_exp_ct()\n\nctnetlink_dump_exp_ct() stores a conntrack pointer in cb-\u0026gt;data for the\nnetlink dump callback ctnetlink_exp_ct_dump_table(), but drops the\nconntrack reference immediately after netlink_dump_start(). When the\ndump spans multiple rounds, the second recvmsg() triggers the dump\ncallback which dereferences the now-freed conntrack via nfct_help(ct),\nleading to a use-after-free on ct-\u0026gt;ext.\n\nThe bug is that the netlink_dump_control has no .start or .done\ncallbacks to manage the conntrack reference across dump rounds. Other\ndump functions in the same file (e.g. ctnetlink_get_conntrack) properly\nuse .start/.done callbacks for this purpose.\n\nFix this by adding .start and .done callbacks that hold and release the\nconntrack reference for the duration of the dump, and move the\nnfct_help() call after the cb-\u0026gt;args[0] early-return check in the dump\ncallback to avoid dereferencing ct-\u0026gt;ext unnecessarily.\n\n BUG: KASAN: slab-use-after-free in ctnetlink_exp_ct_dump_table+0x4f/0x2e0\n Read of size 8 at addr ffff88810597ebf0 by task ctnetlink_poc/133\n\n CPU: 1 UID: 0 PID: 133 Comm: ctnetlink_poc Not tainted 7.0.0-rc2+ #3 PREEMPTLAZY\n Call Trace:\n \u0026lt;TASK\u0026gt;\n ctnetlink_exp_ct_dump_table+0x4f/0x2e0\n netlink_dump+0x333/0x880\n netlink_recvmsg+0x3e2/0x4b0\n ? aa_sk_perm+0x184/0x450\n sock_recvmsg+0xde/0xf0\n\n Allocated by task 133:\n kmem_cache_alloc_noprof+0x134/0x440\n __nf_conntrack_alloc+0xa8/0x2b0\n ctnetlink_create_conntrack+0xa1/0x900\n ctnetlink_new_conntrack+0x3cf/0x7d0\n nfnetlink_rcv_msg+0x48e/0x510\n netlink_rcv_skb+0xc9/0x1f0\n nfnetlink_rcv+0xdb/0x220\n netlink_unicast+0x3ec/0x590\n netlink_sendmsg+0x397/0x690\n __sys_sendmsg+0xf4/0x180\n\n Freed by task 0:\n slab_free_after_rcu_debug+0xad/0x1e0\n rcu_core+0x5c3/0x9c0(CVE-2026-23458)\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\nspi: fix use-after-free on controller registration failure\n\nMake sure to deregister from driver core also in the unlikely event that\nper-cpu statistics allocation fails during controller registration to\navoid use-after-free (of driver resources) and unclocked register\naccesses.(CVE-2026-31389)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: avoid overflows in ip6_datagram_send_ctl()\n\nYiming Qian reported :\n\u0026lt;quote\u0026gt;\n I believe I found a locally triggerable kernel bug in the IPv6 sendmsg\n ancillary-data path that can panic the kernel via `skb_under_panic()`\n (local DoS).\n\n The core issue is a mismatch between:\n\n - a 16-bit length accumulator (`struct ipv6_txoptions::opt_flen`, type\n `__u16`) and\n - a pointer to the *last* provided destination-options header (`opt-\u0026gt;dst1opt`)\n\n when multiple `IPV6_DSTOPTS` control messages (cmsgs) are provided.\n\n - `include/net/ipv6.h`:\n - `struct ipv6_txoptions::opt_flen` is `__u16` (wrap possible).\n (lines 291-307, especially 298)\n - `net/ipv6/datagram.c:ip6_datagram_send_ctl()`:\n - Accepts repeated `IPV6_DSTOPTS` and accumulates into `opt_flen`\n without rejecting duplicates. (lines 909-933)\n - `net/ipv6/ip6_output.c:__ip6_append_data()`:\n - Uses `opt-\u0026gt;opt_flen + opt-\u0026gt;opt_nflen` to compute header\n sizes/headroom decisions. (lines 1448-1466, especially 1463-1465)\n - `net/ipv6/ip6_output.c:__ip6_make_skb()`:\n - Calls `ipv6_push_frag_opts()` if `opt-\u0026gt;opt_flen` is non-zero.\n (lines 1930-1934)\n - `net/ipv6/exthdrs.c:ipv6_push_frag_opts()` / `ipv6_push_exthdr()`:\n - Push size comes from `ipv6_optlen(opt-\u0026gt;dst1opt)` (based on the\n pointed-to header). (lines 1179-1185 and 1206-1211)\n\n 1. `opt_flen` is a 16-bit accumulator:\n\n - `include/net/ipv6.h:298` defines `__u16 opt_flen; /* after fragment hdr */`.\n\n 2. `ip6_datagram_send_ctl()` accepts *repeated* `IPV6_DSTOPTS` cmsgs\n and increments `opt_flen` each time:\n\n - In `net/ipv6/datagram.c:909-933`, for `IPV6_DSTOPTS`:\n - It computes `len = ((hdr-\u0026gt;hdrlen + 1) \u0026lt;\u0026lt; 3);`\n - It checks `CAP_NET_RAW` using `ns_capable(net-\u0026gt;user_ns,\n CAP_NET_RAW)`. (line 922)\n - Then it does:\n - `opt-\u0026gt;opt_flen += len;` (line 927)\n - `opt-\u0026gt;dst1opt = hdr;` (line 928)\n\n There is no duplicate rejection here (unlike the legacy\n `IPV6_2292DSTOPTS` path which rejects duplicates at\n `net/ipv6/datagram.c:901-904`).\n\n If enough large `IPV6_DSTOPTS` cmsgs are provided, `opt_flen` wraps\n while `dst1opt` still points to a large (2048-byte)\n destination-options header.\n\n In the attached PoC (`poc.c`):\n\n - 32 cmsgs with `hdrlen=255` =\u0026gt; `len = (255+1)*8 = 2048`\n - 1 cmsg with `hdrlen=0` =\u0026gt; `len = 8`\n - Total increment: `32*2048 + 8 = 65544`, so `(__u16)opt_flen == 8`\n - The last cmsg is 2048 bytes, so `dst1opt` points to a 2048-byte header.\n\n 3. The transmit path sizes headers using the wrapped `opt_flen`:\n\n- In `net/ipv6/ip6_output.c:1463-1465`:\n - `headersize = sizeof(struct ipv6hdr) + (opt ? opt-\u0026gt;opt_flen +\n opt-\u0026gt;opt_nflen : 0) + ...;`\n\n With wrapped `opt_flen`, `headersize`/headroom decisions underestimate\n what will be pushed later.\n\n 4. When building the final skb, the actual push length comes from\n `dst1opt` and is not limited by wrapped `opt_flen`:\n\n - In `net/ipv6/ip6_output.c:1930-1934`:\n - `if (opt-\u0026gt;opt_flen) proto = ipv6_push_frag_opts(skb, opt, proto);`\n - In `net/ipv6/exthdrs.c:1206-1211`, `ipv6_push_frag_opts()` pushes\n `dst1opt` via `ipv6_push_exthdr()`.\n - In `net/ipv6/exthdrs.c:1179-1184`, `ipv6_push_exthdr()` does:\n - `skb_push(skb, ipv6_optlen(opt));`\n - `memcpy(h, opt, ipv6_optlen(opt));`\n\n With insufficient headroom, `skb_push()` underflows and triggers\n `skb_under_panic()` -\u0026gt; `BUG()`:\n\n - `net/core/skbuff.c:2669-2675` (`skb_push()` calls `skb_under_panic()`)\n - `net/core/skbuff.c:207-214` (`skb_panic()` ends in `BUG()`)\n\n - The `IPV6_DSTOPTS` cmsg path requires `CAP_NET_RAW` in the target\n netns user namespace (`ns_capable(net-\u0026gt;user_ns, CAP_NET_RAW)`).\n - Root (or any task with `CAP_NET_RAW`) can trigger this without user\n namespaces.\n - An unprivileged `uid=1000` user can trigger this if unprivileged\n user namespaces are enabled and it can create a userns+netns to obtain\n namespaced `CAP_NET_RAW` (the attached PoC does this).\n\n - Local denial of service: kernel BUG/panic (system crash).\n -\n---truncated---(CVE-2026-31415)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nfnetlink_log: account for netlink header size\n\nThis is a followup to an old bug fix: NLMSG_DONE needs to account\nfor the netlink header size, not just the attribute size.\n\nThis can result in a WARN splat + drop of the netlink message,\nbut other than this there are no ill effects.(CVE-2026-31416)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_conntrack_sip: fix use of uninitialized rtp_addr in process_sdp\n\nprocess_sdp() declares union nf_inet_addr rtp_addr on the stack and\npasses it to the nf_nat_sip sdp_session hook after walking the SDP\nmedia descriptions. However rtp_addr is only initialized inside the\nmedia loop when a recognized media type with a non-zero port is found.\n\nIf the SDP body contains no m= lines, only inactive media sections\n(m=audio 0 ...) or only unrecognized media types, rtp_addr is never\nassigned. Despite that, the function still calls hooks-\u0026gt;sdp_session()\nwith \u0026amp;rtp_addr, causing nf_nat_sdp_session() to format the stale stack\nvalue as an IP address and rewrite the SDP session owner and connection\nlines with it.\n\nWith CONFIG_INIT_STACK_ALL_ZERO (default on most distributions) this\nresults in the session-level o= and c= addresses being rewritten to\n0.0.0.0 for inactive SDP sessions. Without stack auto-init the\nrewritten address is whatever happened to be on the stack.\n\nFix this by pre-initializing rtp_addr from the session-level connection\naddress (caddr) when available, and tracking via a have_rtp_addr flag\nwhether any valid address was established. Skip the sdp_session hook\nentirely when no valid address exists.(CVE-2026-31427)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nfnetlink_log: fix uninitialized padding leak in NFULA_PAYLOAD\n\n__build_packet_message() manually constructs the NFULA_PAYLOAD netlink\nattribute using skb_put() and skb_copy_bits(), bypassing the standard\nnla_reserve()/nla_put() helpers. While nla_total_size(data_len) bytes\nare allocated (including NLA alignment padding), only data_len bytes\nof actual packet data are copied. The trailing nla_padlen(data_len)\nbytes (1-3 when data_len is not 4-byte aligned) are never initialized,\nleaking stale heap contents to userspace via the NFLOG netlink socket.\n\nReplace the manual attribute construction with nla_reserve(), which\nhandles the tailroom check, header setup, and padding zeroing via\n__nla_reserve(). The subsequent skb_copy_bits() fills in the payload\ndata on top of the properly initialized attribute.(CVE-2026-31428)\n\nIn the Linux kernel, the following vulnerability has been resolved:\\n\\ncrypto: algif_aead - Revert to operating out-of-place\\n\\nThis mostly reverts commit 72548b093ee3 except for the copying of the associated data.\\n\\nThere is no benefit in operating in-place in algif_aead since the source and destination come from different mappings. Get rid of all the complexity added for in-place operation and just copy the AD directly.(CVE-2026-31431)",
"id": "OESA-2026-2172",
"modified": "2026-08-06T11:11:09Z",
"published": "2026-05-03T11:11:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-2172"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-27558"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23378"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23398"
},
{
"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-23442"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23447"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23449"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23452"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23455"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23456"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23457"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23458"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23475"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31389"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31415"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31416"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31427"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31428"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31431"
}
],
"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:N",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2025-27558",
"CVE-2026-23378",
"CVE-2026-23398",
"CVE-2026-23406",
"CVE-2026-23407",
"CVE-2026-23442",
"CVE-2026-23447",
"CVE-2026-23449",
"CVE-2026-23452",
"CVE-2026-23455",
"CVE-2026-23456",
"CVE-2026-23457",
"CVE-2026-23458",
"CVE-2026-23475",
"CVE-2026-31389",
"CVE-2026-31415",
"CVE-2026-31416",
"CVE-2026-31427",
"CVE-2026-31428",
"CVE-2026-31431"
]
}
OESA-2026-2176 (CVE-2025-27558)
Vulnerability from osv_openeuler – Published: 2026-05-03 11:11 – Updated: 2026-08-06 11:11 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
IEEE P802.11-REVme D1.1 through D7.0 allows FragAttacks against mesh networks. In mesh networks using Wi-Fi Protected Access (WPA, WPA2, or WPA3) or Wired Equivalent Privacy (WEP), an adversary can exploit this vulnerability to inject arbitrary frames towards devices that support receiving non-SSP A-MSDU frames. NOTE: this issue exists because of an incorrect fix for CVE-2020-24588. P802.11-REVme, as of early 2025, is a planned release of the 802.11 standard.(CVE-2025-27558)
In the Linux kernel, a security vulnerability exists in the IOMMU Shared Virtual Addressing (SVA) feature. On x86 architecture when CONFIG_X86 is set, IOMMU hardware caches kernel page table entries. Due to the lack of notification mechanism for kernel page table changes, when kernel page table pages are freed and reused, the IOMMU may retain stale entries, leading to Use-After-Free (UAF) and Write-After-Free (WAF) conditions. This can be exploited to cause arbitrary physical memory DMA access or privilege escalation.(CVE-2025-71089)
In the Linux kernel, the following vulnerability has been resolved:
uacce: fix cdev handling in the cleanup path
When cdev_device_add fails, it internally releases the cdev memory, and if cdev_device_del is then executed, it will cause a hang error. To fix it, we check the return value of cdev_device_add() and clear uacce->cdev to avoid calling cdev_device_del in the uacce_remove.(CVE-2026-23096)
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:
icmp: fix NULL pointer dereference in icmp_tag_validation()
icmp_tag_validation() unconditionally dereferences the result of rcu_dereference(inet_protos[proto]) without checking for NULL. The inet_protos[] array is sparse -- only about 15 of 256 protocol numbers have registered handlers. When ip_no_pmtu_disc is set to 3 (hardened PMTU mode) and the kernel receives an ICMP Fragmentation Needed error with a quoted inner IP header containing an unregistered protocol number, the NULL dereference causes a kernel panic in softirq context.
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] RIP: 0010:icmp_unreach (net/ipv4/icmp.c:1085 net/ipv4/icmp.c:1143) Call Trace: <IRQ> icmp_rcv (net/ipv4/icmp.c:1527) ip_protocol_deliver_rcu (net/ipv4/ip_input.c:207) ip_local_deliver_finish (net/ipv4/ip_input.c:242) ip_local_deliver (net/ipv4/ip_input.c:262) ip_rcv (net/ipv4/ip_input.c:573) __netif_receive_skb_one_core (net/core/dev.c:6164) process_backlog (net/core/dev.c:6628) handle_softirqs (kernel/softirq.c:561) </IRQ>
Add a NULL check before accessing icmp_strict_tag_validation. If the protocol has no registered handler, return false since it cannot perform strict tag validation.(CVE-2026-23398)
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)
In the Linux kernel, the following vulnerability has been resolved:
ipv6: add NULL checks for idev in SRv6 paths
__in6_dev_get() can return NULL when the device has no IPv6 configuration (e.g. MTU < IPV6_MIN_MTU or after NETDEV_UNREGISTER).
Add NULL checks for idev returned by __in6_dev_get() in both seg6_hmac_validate_skb() and ipv6_srh_rcv() to prevent potential NULL pointer dereferences.(CVE-2026-23442)
In the Linux kernel, the following vulnerability has been resolved:
net: usb: cdc_ncm: add ndpoffset to NDP32 nframes bounds check
The same bounds-check bug fixed for NDP16 in the previous patch also exists in cdc_ncm_rx_verify_ndp32(). The DPE array size is validated against the total skb length without accounting for ndpoffset, allowing out-of-bounds reads when the NDP32 is placed near the end of the NTB.
Add ndpoffset to the nframes bounds check and use struct_size_t() to express the NDP-plus-DPE-array size more clearly.
Compile-tested only.(CVE-2026-23447)
In the Linux kernel, the following vulnerability has been resolved:
net/sched: teql: Fix double-free in teql_master_xmit
Whenever a TEQL devices has a lockless Qdisc as root, qdisc_reset should be called using the seq_lock to avoid racing with the datapath. Failure to do so may cause crashes like the following:
[ 238.028993][ T318] BUG: KASAN: double-free in skb_release_data (net/core/skbuff.c:1139) [ 238.029328][ T318] Free of addr ffff88810c67ec00 by task poc_teql_uaf_ke/318 [ 238.029749][ T318] [ 238.029900][ T318] CPU: 3 UID: 0 PID: 318 Comm: poc_teql_ke Not tainted 7.0.0-rc3-00149-ge5b31d988a41 #704 PREEMPT(full) [ 238.029906][ T318] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 238.029910][ T318] Call Trace: [ 238.029913][ T318] <TASK> [ 238.029916][ T318] dump_stack_lvl (lib/dump_stack.c:122) [ 238.029928][ T318] print_report (mm/kasan/report.c:379 mm/kasan/report.c:482) [ 238.029940][ T318] ? skb_release_data (net/core/skbuff.c:1139) [ 238.029944][ T318] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) ... [ 238.029957][ T318] ? skb_release_data (net/core/skbuff.c:1139) [ 238.029969][ T318] kasan_report_invalid_free (mm/kasan/report.c:221 mm/kasan/report.c:563) [ 238.029979][ T318] ? skb_release_data (net/core/skbuff.c:1139) [ 238.029989][ T318] check_slab_allocation (mm/kasan/common.c:231) [ 238.029995][ T318] kmem_cache_free (mm/slub.c:2637 (discriminator 1) mm/slub.c:6168 (discriminator 1) mm/slub.c:6298 (discriminator 1)) [ 238.030004][ T318] skb_release_data (net/core/skbuff.c:1139) ... [ 238.030025][ T318] sk_skb_reason_drop (net/core/skbuff.c:1256) [ 238.030032][ T318] pfifo_fast_reset (./include/linux/ptr_ring.h:171 ./include/linux/ptr_ring.h:309 ./include/linux/skb_array.h:98 net/sched/sch_generic.c:827) [ 238.030039][ T318] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) ... [ 238.030054][ T318] qdisc_reset (net/sched/sch_generic.c:1034) [ 238.030062][ T318] teql_destroy (./include/linux/spinlock.h:395 net/sched/sch_teql.c:157) [ 238.030071][ T318] __qdisc_destroy (./include/net/pkt_sched.h:328 net/sched/sch_generic.c:1077) [ 238.030077][ T318] qdisc_graft (net/sched/sch_api.c:1062 net/sched/sch_api.c:1053 net/sched/sch_api.c:1159) [ 238.030089][ T318] ? __pfx_qdisc_graft (net/sched/sch_api.c:1091) [ 238.030095][ T318] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 238.030102][ T318] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 238.030106][ T318] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 238.030114][ T318] tc_get_qdisc (net/sched/sch_api.c:1529 net/sched/sch_api.c:1556) ... [ 238.072958][ T318] Allocated by task 303 on cpu 5 at 238.026275s: [ 238.073392][ T318] kasan_save_stack (mm/kasan/common.c:58) [ 238.073884][ T318] kasan_save_track (mm/kasan/common.c:64 (discriminator 5) mm/kasan/common.c:79 (discriminator 5)) [ 238.074230][ T318] __kasan_slab_alloc (mm/kasan/common.c:369) [ 238.074578][ T318] kmem_cache_alloc_node_noprof (./include/linux/kasan.h:253 mm/slub.c:4542 mm/slub.c:4869 mm/slub.c:4921) [ 238.076091][ T318] kmalloc_reserve (net/core/skbuff.c:616 (discriminator 107)) [ 238.076450][ T318] __alloc_skb (net/core/skbuff.c:713) [ 238.076834][ T318] alloc_skb_with_frags (./include/linux/skbuff.h:1383 net/core/skbuff.c:6763) [ 238.077178][ T318] sock_alloc_send_pskb (net/core/sock.c:2997) [ 238.077520][ T318] packet_sendmsg (net/packet/af_packet.c:2926 net/packet/af_packet.c:3019 net/packet/af_packet.c:3108) [ 238.081469][ T318] [ 238.081870][ T318] Freed by task 299 on cpu 1 at 238.028496s: [ 238.082761][ T318] kasan_save_stack (mm/kasan/common.c:58) [ 238.083481][ T318] kasan_save_track (mm/kasan/common.c:64 (discriminator 5) mm/kasan/common.c:79 (discriminator 5)) [ 238.085348][ T318] kasan_save_free_info (mm/kasan/generic.c:587 (discriminator 1)) [ 238.085900][ T318] __kasan_slab_free (mm/ ---truncated---(CVE-2026-23449)
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:
netfilter: nf_conntrack_h323: check for zero length in DecodeQ931()
In DecodeQ931(), the UserUserIE code path reads a 16-bit length from the packet, then decrements it by 1 to skip the protocol discriminator byte before passing it to DecodeH323_UserInformation(). If the encoded length is 0, the decrement wraps to -1, which is then passed as a large value to the decoder, leading to an out-of-bounds read.
Add a check to ensure len is positive after the decrement.(CVE-2026-23455)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_conntrack_h323: fix OOB read in decode_int() CONS case
In decode_int(), the CONS case calls get_bits(bs, 2) to read a length value, then calls get_uint(bs, len) without checking that len bytes remain in the buffer. The existing boundary check only validates the 2 bits for get_bits(), not the subsequent 1-4 bytes that get_uint() reads. This allows a malformed H.323/RAS packet to cause a 1-4 byte slab-out-of-bounds read.
Add a boundary check for len bytes after get_bits() and before get_uint().(CVE-2026-23456)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_conntrack_sip: fix Content-Length u32 truncation in sip_help_tcp()
sip_help_tcp() parses the SIP Content-Length header with simple_strtoul(), which returns unsigned long, but stores the result in unsigned int clen. On 64-bit systems, values exceeding UINT_MAX are silently truncated before computing the SIP message boundary.
For example, Content-Length 4294967328 (2^32 + 32) is truncated to 32, causing the parser to miscalculate where the current message ends. The loop then treats trailing data in the TCP segment as a second SIP message and processes it through the SDP parser.
Fix this by changing clen to unsigned long to match the return type of simple_strtoul(), and reject Content-Length values that exceed the remaining TCP payload length.(CVE-2026-23457)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: ctnetlink: fix use-after-free in ctnetlink_dump_exp_ct()
ctnetlink_dump_exp_ct() stores a conntrack pointer in cb->data for the netlink dump callback ctnetlink_exp_ct_dump_table(), but drops the conntrack reference immediately after netlink_dump_start(). When the dump spans multiple rounds, the second recvmsg() triggers the dump callback which dereferences the now-freed conntrack via nfct_help(ct), leading to a use-after-free on ct->ext.
The bug is that the netlink_dump_control has no .start or .done callbacks to manage the conntrack reference across dump rounds. Other dump functions in the same file (e.g. ctnetlink_get_conntrack) properly use .start/.done callbacks for this purpose.
Fix this by adding .start and .done callbacks that hold and release the conntrack reference for the duration of the dump, and move the nfct_help() call after the cb->args[0] early-return check in the dump callback to avoid dereferencing ct->ext unnecessarily.
BUG: KASAN: slab-use-after-free in ctnetlink_exp_ct_dump_table+0x4f/0x2e0 Read of size 8 at addr ffff88810597ebf0 by task ctnetlink_poc/133
CPU: 1 UID: 0 PID: 133 Comm: ctnetlink_poc Not tainted 7.0.0-rc2+ #3 PREEMPTLAZY Call Trace: <TASK> ctnetlink_exp_ct_dump_table+0x4f/0x2e0 netlink_dump+0x333/0x880 netlink_recvmsg+0x3e2/0x4b0 ? aa_sk_perm+0x184/0x450 sock_recvmsg+0xde/0xf0
Allocated by task 133: kmem_cache_alloc_noprof+0x134/0x440 __nf_conntrack_alloc+0xa8/0x2b0 ctnetlink_create_conntrack+0xa1/0x900 ctnetlink_new_conntrack+0x3cf/0x7d0 nfnetlink_rcv_msg+0x48e/0x510 netlink_rcv_skb+0xc9/0x1f0 nfnetlink_rcv+0xdb/0x220 netlink_unicast+0x3ec/0x590 netlink_sendmsg+0x397/0x690 __sys_sendmsg+0xf4/0x180
Freed by task 0: slab_free_after_rcu_debug+0xad/0x1e0 rcu_core+0x5c3/0x9c0(CVE-2026-23458)
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:
spi: fix use-after-free on controller registration failure
Make sure to deregister from driver core also in the unlikely event that per-cpu statistics allocation fails during controller registration to avoid use-after-free (of driver resources) and unclocked register accesses.(CVE-2026-31389)
In the Linux kernel, the following vulnerability has been resolved:
ipv6: avoid overflows in ip6_datagram_send_ctl()
Yiming Qian reported :
<quote>
I believe I found a locally triggerable kernel bug in the IPv6 sendmsg
ancillary-data path that can panic the kernel via skb_under_panic()
(local DoS).
The core issue is a mismatch between:
- a 16-bit length accumulator (
struct ipv6_txoptions::opt_flen, type__u16) and - a pointer to the last provided destination-options header (
opt->dst1opt)
when multiple IPV6_DSTOPTS control messages (cmsgs) are provided.
include/net/ipv6.h:struct ipv6_txoptions::opt_flenis__u16(wrap possible). (lines 291-307, especially 298)net/ipv6/datagram.c:ip6_datagram_send_ctl():- Accepts repeated
IPV6_DSTOPTSand accumulates intoopt_flenwithout rejecting duplicates. (lines 909-933) net/ipv6/ip6_output.c:__ip6_append_data():- Uses
opt->opt_flen + opt->opt_nflento compute header sizes/headroom decisions. (lines 1448-1466, especially 1463-1465) net/ipv6/ip6_output.c:__ip6_make_skb():- Calls
ipv6_push_frag_opts()ifopt->opt_flenis non-zero. (lines 1930-1934) net/ipv6/exthdrs.c:ipv6_push_frag_opts()/ipv6_push_exthdr():-
Push size comes from
ipv6_optlen(opt->dst1opt)(based on the pointed-to header). (lines 1179-1185 and 1206-1211) -
opt_flenis a 16-bit accumulator: -
include/net/ipv6.h:298defines__u16 opt_flen; /* after fragment hdr */. -
ip6_datagram_send_ctl()accepts repeatedIPV6_DSTOPTScmsgs and incrementsopt_fleneach time: -
In
net/ipv6/datagram.c:909-933, forIPV6_DSTOPTS: - It computes
len = ((hdr->hdrlen + 1) << 3); - It checks
CAP_NET_RAWusingns_capable(net->user_ns, CAP_NET_RAW). (line 922) - Then it does:
opt->opt_flen += len;(line 927)opt->dst1opt = hdr;(line 928)
There is no duplicate rejection here (unlike the legacy
IPV6_2292DSTOPTS path which rejects duplicates at
net/ipv6/datagram.c:901-904).
If enough large IPV6_DSTOPTS cmsgs are provided, opt_flen wraps
while dst1opt still points to a large (2048-byte)
destination-options header.
In the attached PoC (poc.c):
- 32 cmsgs with
hdrlen=255=>len = (255+1)*8 = 2048 - 1 cmsg with
hdrlen=0=>len = 8 - Total increment:
32*2048 + 8 = 65544, so(__u16)opt_flen == 8 -
The last cmsg is 2048 bytes, so
dst1optpoints to a 2048-byte header. -
The transmit path sizes headers using the wrapped
opt_flen: -
In
net/ipv6/ip6_output.c:1463-1465: headersize = sizeof(struct ipv6hdr) + (opt ? opt->opt_flen + opt->opt_nflen : 0) + ...;
With wrapped opt_flen, headersize/headroom decisions underestimate
what will be pushed later.
-
When building the final skb, the actual push length comes from
dst1optand is not limited by wrappedopt_flen: -
In
net/ipv6/ip6_output.c:1930-1934: if (opt->opt_flen) proto = ipv6_push_frag_opts(skb, opt, proto);- In
net/ipv6/exthdrs.c:1206-1211,ipv6_push_frag_opts()pushesdst1optviaipv6_push_exthdr(). - In
net/ipv6/exthdrs.c:1179-1184,ipv6_push_exthdr()does: skb_push(skb, ipv6_optlen(opt));memcpy(h, opt, ipv6_optlen(opt));
With insufficient headroom, skb_push() underflows and triggers
skb_under_panic() -> BUG():
net/core/skbuff.c:2669-2675(skb_push()callsskb_under_panic())-
net/core/skbuff.c:207-214(skb_panic()ends inBUG()) -
The
IPV6_DSTOPTScmsg path requiresCAP_NET_RAWin the target netns user namespace (ns_capable(net->user_ns, CAP_NET_RAW)). - Root (or any task with
CAP_NET_RAW) can trigger this without user namespaces. -
An unprivileged
uid=1000user can trigger this if unprivileged user namespaces are enabled and it can create a userns+netns to obtain namespacedCAP_NET_RAW(the attached PoC does this). -
Local denial of service: kernel BUG/panic (system crash). - ---truncated---(CVE-2026-31415)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nfnetlink_log: account for netlink header size
This is a followup to an old bug fix: NLMSG_DONE needs to account for the netlink header size, not just the attribute size.
This can result in a WARN splat + drop of the netlink message, but other than this there are no ill effects.(CVE-2026-31416)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_conntrack_sip: fix use of uninitialized rtp_addr in process_sdp
process_sdp() declares union nf_inet_addr rtp_addr on the stack and passes it to the nf_nat_sip sdp_session hook after walking the SDP media descriptions. However rtp_addr is only initialized inside the media loop when a recognized media type with a non-zero port is found.
If the SDP body contains no m= lines, only inactive media sections (m=audio 0 ...) or only unrecognized media types, rtp_addr is never assigned. Despite that, the function still calls hooks->sdp_session() with &rtp_addr, causing nf_nat_sdp_session() to format the stale stack value as an IP address and rewrite the SDP session owner and connection lines with it.
With CONFIG_INIT_STACK_ALL_ZERO (default on most distributions) this results in the session-level o= and c= addresses being rewritten to 0.0.0.0 for inactive SDP sessions. Without stack auto-init the rewritten address is whatever happened to be on the stack.
Fix this by pre-initializing rtp_addr from the session-level connection address (caddr) when available, and tracking via a have_rtp_addr flag whether any valid address was established. Skip the sdp_session hook entirely when no valid address exists.(CVE-2026-31427)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nfnetlink_log: fix uninitialized padding leak in NFULA_PAYLOAD
__build_packet_message() manually constructs the NFULA_PAYLOAD netlink attribute using skb_put() and skb_copy_bits(), bypassing the standard nla_reserve()/nla_put() helpers. While nla_total_size(data_len) bytes are allocated (including NLA alignment padding), only data_len bytes of actual packet data are copied. The trailing nla_padlen(data_len) bytes (1-3 when data_len is not 4-byte aligned) are never initialized, leaking stale heap contents to userspace via the NFLOG netlink socket.
Replace the manual attribute construction with nla_reserve(), which handles the tailroom check, header setup, and padding zeroing via __nla_reserve(). The subsequent skb_copy_bits() fills in the payload data on top of the properly initialized attribute.(CVE-2026-31428)
In the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: algif_aead - Revert to operating out-of-place\n\nThis mostly reverts commit 72548b093ee3 except for the copying of the associated data.\n\nThere is no benefit in operating in-place in algif_aead since the source and destination come from different mappings. Get rid of all the complexity added for in-place operation and just copy the AD directly.(CVE-2026-31431)
| URL | Type | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-6.6.0-145.0.7.134.oe2403.aarch64.rpm",
"bpftool-debuginfo-6.6.0-145.0.7.134.oe2403.aarch64.rpm",
"kernel-6.6.0-145.0.7.134.oe2403.aarch64.rpm",
"kernel-debuginfo-6.6.0-145.0.7.134.oe2403.aarch64.rpm",
"kernel-debugsource-6.6.0-145.0.7.134.oe2403.aarch64.rpm",
"kernel-devel-6.6.0-145.0.7.134.oe2403.aarch64.rpm",
"kernel-headers-6.6.0-145.0.7.134.oe2403.aarch64.rpm",
"kernel-source-6.6.0-145.0.7.134.oe2403.aarch64.rpm",
"kernel-tools-6.6.0-145.0.7.134.oe2403.aarch64.rpm",
"kernel-tools-debuginfo-6.6.0-145.0.7.134.oe2403.aarch64.rpm",
"kernel-tools-devel-6.6.0-145.0.7.134.oe2403.aarch64.rpm",
"perf-6.6.0-145.0.7.134.oe2403.aarch64.rpm",
"perf-debuginfo-6.6.0-145.0.7.134.oe2403.aarch64.rpm",
"python3-perf-6.6.0-145.0.7.134.oe2403.aarch64.rpm",
"python3-perf-debuginfo-6.6.0-145.0.7.134.oe2403.aarch64.rpm"
],
"src": [
"kernel-6.6.0-145.0.7.134.oe2403.src.rpm"
],
"x86_64": [
"bpftool-6.6.0-145.0.7.134.oe2403.x86_64.rpm",
"bpftool-debuginfo-6.6.0-145.0.7.134.oe2403.x86_64.rpm",
"kernel-6.6.0-145.0.7.134.oe2403.x86_64.rpm",
"kernel-debuginfo-6.6.0-145.0.7.134.oe2403.x86_64.rpm",
"kernel-debugsource-6.6.0-145.0.7.134.oe2403.x86_64.rpm",
"kernel-devel-6.6.0-145.0.7.134.oe2403.x86_64.rpm",
"kernel-headers-6.6.0-145.0.7.134.oe2403.x86_64.rpm",
"kernel-source-6.6.0-145.0.7.134.oe2403.x86_64.rpm",
"kernel-tools-6.6.0-145.0.7.134.oe2403.x86_64.rpm",
"kernel-tools-debuginfo-6.6.0-145.0.7.134.oe2403.x86_64.rpm",
"kernel-tools-devel-6.6.0-145.0.7.134.oe2403.x86_64.rpm",
"perf-6.6.0-145.0.7.134.oe2403.x86_64.rpm",
"perf-debuginfo-6.6.0-145.0.7.134.oe2403.x86_64.rpm",
"python3-perf-6.6.0-145.0.7.134.oe2403.x86_64.rpm",
"python3-perf-debuginfo-6.6.0-145.0.7.134.oe2403.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:24.03-LTS",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.6.0-145.0.7.134.oe2403"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "Critical"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIEEE P802.11-REVme D1.1 through D7.0 allows FragAttacks against mesh networks. In mesh networks using Wi-Fi Protected Access (WPA, WPA2, or WPA3) or Wired Equivalent Privacy (WEP), an adversary can exploit this vulnerability to inject arbitrary frames towards devices that support receiving non-SSP A-MSDU frames. NOTE: this issue exists because of an incorrect fix for CVE-2020-24588. P802.11-REVme, as of early 2025, is a planned release of the 802.11 standard.(CVE-2025-27558)\n\nIn the Linux kernel, a security vulnerability exists in the IOMMU Shared Virtual Addressing (SVA) feature. On x86 architecture when CONFIG_X86 is set, IOMMU hardware caches kernel page table entries. Due to the lack of notification mechanism for kernel page table changes, when kernel page table pages are freed and reused, the IOMMU may retain stale entries, leading to Use-After-Free (UAF) and Write-After-Free (WAF) conditions. This can be exploited to cause arbitrary physical memory DMA access or privilege escalation.(CVE-2025-71089)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nuacce: fix cdev handling in the cleanup path\n\nWhen cdev_device_add fails, it internally releases the cdev memory,\nand if cdev_device_del is then executed, it will cause a hang error.\nTo fix it, we check the return value of cdev_device_add() and clear\nuacce-\u0026gt;cdev to avoid calling cdev_device_del in the uacce_remove.(CVE-2026-23096)\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\nicmp: fix NULL pointer dereference in icmp_tag_validation()\n\nicmp_tag_validation() unconditionally dereferences the result of\nrcu_dereference(inet_protos[proto]) without checking for NULL.\nThe inet_protos[] array is sparse -- only about 15 of 256 protocol\nnumbers have registered handlers. When ip_no_pmtu_disc is set to 3\n(hardened PMTU mode) and the kernel receives an ICMP Fragmentation\nNeeded error with a quoted inner IP header containing an unregistered\nprotocol number, the NULL dereference causes a kernel panic in\nsoftirq context.\n\n Oops: general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] SMP KASAN NOPTI\n KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]\n RIP: 0010:icmp_unreach (net/ipv4/icmp.c:1085 net/ipv4/icmp.c:1143)\n Call Trace:\n \u0026lt;IRQ\u0026gt;\n icmp_rcv (net/ipv4/icmp.c:1527)\n ip_protocol_deliver_rcu (net/ipv4/ip_input.c:207)\n ip_local_deliver_finish (net/ipv4/ip_input.c:242)\n ip_local_deliver (net/ipv4/ip_input.c:262)\n ip_rcv (net/ipv4/ip_input.c:573)\n __netif_receive_skb_one_core (net/core/dev.c:6164)\n process_backlog (net/core/dev.c:6628)\n handle_softirqs (kernel/softirq.c:561)\n \u0026lt;/IRQ\u0026gt;\n\nAdd a NULL check before accessing icmp_strict_tag_validation. If the\nprotocol has no registered handler, return false since it cannot\nperform strict tag validation.(CVE-2026-23398)\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\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: add NULL checks for idev in SRv6 paths\n\n__in6_dev_get() can return NULL when the device has no IPv6 configuration\n(e.g. MTU \u0026lt; IPV6_MIN_MTU or after NETDEV_UNREGISTER).\n\nAdd NULL checks for idev returned by __in6_dev_get() in both\nseg6_hmac_validate_skb() and ipv6_srh_rcv() to prevent potential NULL\npointer dereferences.(CVE-2026-23442)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: usb: cdc_ncm: add ndpoffset to NDP32 nframes bounds check\n\nThe same bounds-check bug fixed for NDP16 in the previous patch also\nexists in cdc_ncm_rx_verify_ndp32(). The DPE array size is validated\nagainst the total skb length without accounting for ndpoffset, allowing\nout-of-bounds reads when the NDP32 is placed near the end of the NTB.\n\nAdd ndpoffset to the nframes bounds check and use struct_size_t() to\nexpress the NDP-plus-DPE-array size more clearly.\n\nCompile-tested only.(CVE-2026-23447)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: teql: Fix double-free in teql_master_xmit\n\nWhenever a TEQL devices has a lockless Qdisc as root, qdisc_reset should\nbe called using the seq_lock to avoid racing with the datapath. Failure\nto do so may cause crashes like the following:\n\n[ 238.028993][ T318] BUG: KASAN: double-free in skb_release_data (net/core/skbuff.c:1139)\n[ 238.029328][ T318] Free of addr ffff88810c67ec00 by task poc_teql_uaf_ke/318\n[ 238.029749][ T318]\n[ 238.029900][ T318] CPU: 3 UID: 0 PID: 318 Comm: poc_teql_ke Not tainted 7.0.0-rc3-00149-ge5b31d988a41 #704 PREEMPT(full)\n[ 238.029906][ T318] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011\n[ 238.029910][ T318] Call Trace:\n[ 238.029913][ T318] \u0026lt;TASK\u0026gt;\n[ 238.029916][ T318] dump_stack_lvl (lib/dump_stack.c:122)\n[ 238.029928][ T318] print_report (mm/kasan/report.c:379 mm/kasan/report.c:482)\n[ 238.029940][ T318] ? skb_release_data (net/core/skbuff.c:1139)\n[ 238.029944][ T318] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)\n...\n[ 238.029957][ T318] ? skb_release_data (net/core/skbuff.c:1139)\n[ 238.029969][ T318] kasan_report_invalid_free (mm/kasan/report.c:221 mm/kasan/report.c:563)\n[ 238.029979][ T318] ? skb_release_data (net/core/skbuff.c:1139)\n[ 238.029989][ T318] check_slab_allocation (mm/kasan/common.c:231)\n[ 238.029995][ T318] kmem_cache_free (mm/slub.c:2637 (discriminator 1) mm/slub.c:6168 (discriminator 1) mm/slub.c:6298 (discriminator 1))\n[ 238.030004][ T318] skb_release_data (net/core/skbuff.c:1139)\n...\n[ 238.030025][ T318] sk_skb_reason_drop (net/core/skbuff.c:1256)\n[ 238.030032][ T318] pfifo_fast_reset (./include/linux/ptr_ring.h:171 ./include/linux/ptr_ring.h:309 ./include/linux/skb_array.h:98 net/sched/sch_generic.c:827)\n[ 238.030039][ T318] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)\n...\n[ 238.030054][ T318] qdisc_reset (net/sched/sch_generic.c:1034)\n[ 238.030062][ T318] teql_destroy (./include/linux/spinlock.h:395 net/sched/sch_teql.c:157)\n[ 238.030071][ T318] __qdisc_destroy (./include/net/pkt_sched.h:328 net/sched/sch_generic.c:1077)\n[ 238.030077][ T318] qdisc_graft (net/sched/sch_api.c:1062 net/sched/sch_api.c:1053 net/sched/sch_api.c:1159)\n[ 238.030089][ T318] ? __pfx_qdisc_graft (net/sched/sch_api.c:1091)\n[ 238.030095][ T318] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)\n[ 238.030102][ T318] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)\n[ 238.030106][ T318] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)\n[ 238.030114][ T318] tc_get_qdisc (net/sched/sch_api.c:1529 net/sched/sch_api.c:1556)\n...\n[ 238.072958][ T318] Allocated by task 303 on cpu 5 at 238.026275s:\n[ 238.073392][ T318] kasan_save_stack (mm/kasan/common.c:58)\n[ 238.073884][ T318] kasan_save_track (mm/kasan/common.c:64 (discriminator 5) mm/kasan/common.c:79 (discriminator 5))\n[ 238.074230][ T318] __kasan_slab_alloc (mm/kasan/common.c:369)\n[ 238.074578][ T318] kmem_cache_alloc_node_noprof (./include/linux/kasan.h:253 mm/slub.c:4542 mm/slub.c:4869 mm/slub.c:4921)\n[ 238.076091][ T318] kmalloc_reserve (net/core/skbuff.c:616 (discriminator 107))\n[ 238.076450][ T318] __alloc_skb (net/core/skbuff.c:713)\n[ 238.076834][ T318] alloc_skb_with_frags (./include/linux/skbuff.h:1383 net/core/skbuff.c:6763)\n[ 238.077178][ T318] sock_alloc_send_pskb (net/core/sock.c:2997)\n[ 238.077520][ T318] packet_sendmsg (net/packet/af_packet.c:2926 net/packet/af_packet.c:3019 net/packet/af_packet.c:3108)\n[ 238.081469][ T318]\n[ 238.081870][ T318] Freed by task 299 on cpu 1 at 238.028496s:\n[ 238.082761][ T318] kasan_save_stack (mm/kasan/common.c:58)\n[ 238.083481][ T318] kasan_save_track (mm/kasan/common.c:64 (discriminator 5) mm/kasan/common.c:79 (discriminator 5))\n[ 238.085348][ T318] kasan_save_free_info (mm/kasan/generic.c:587 (discriminator 1))\n[ 238.085900][ T318] __kasan_slab_free (mm/\n---truncated---(CVE-2026-23449)\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\nnetfilter: nf_conntrack_h323: check for zero length in DecodeQ931()\n\nIn DecodeQ931(), the UserUserIE code path reads a 16-bit length from\nthe packet, then decrements it by 1 to skip the protocol discriminator\nbyte before passing it to DecodeH323_UserInformation(). If the encoded\nlength is 0, the decrement wraps to -1, which is then passed as a\nlarge value to the decoder, leading to an out-of-bounds read.\n\nAdd a check to ensure len is positive after the decrement.(CVE-2026-23455)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_conntrack_h323: fix OOB read in decode_int() CONS case\n\nIn decode_int(), the CONS case calls get_bits(bs, 2) to read a length\nvalue, then calls get_uint(bs, len) without checking that len bytes\nremain in the buffer. The existing boundary check only validates the\n2 bits for get_bits(), not the subsequent 1-4 bytes that get_uint()\nreads. This allows a malformed H.323/RAS packet to cause a 1-4 byte\nslab-out-of-bounds read.\n\nAdd a boundary check for len bytes after get_bits() and before\nget_uint().(CVE-2026-23456)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_conntrack_sip: fix Content-Length u32 truncation in sip_help_tcp()\n\nsip_help_tcp() parses the SIP Content-Length header with\nsimple_strtoul(), which returns unsigned long, but stores the result in\nunsigned int clen. On 64-bit systems, values exceeding UINT_MAX are\nsilently truncated before computing the SIP message boundary.\n\nFor example, Content-Length 4294967328 (2^32 + 32) is truncated to 32,\ncausing the parser to miscalculate where the current message ends. The\nloop then treats trailing data in the TCP segment as a second SIP\nmessage and processes it through the SDP parser.\n\nFix this by changing clen to unsigned long to match the return type of\nsimple_strtoul(), and reject Content-Length values that exceed the\nremaining TCP payload length.(CVE-2026-23457)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: ctnetlink: fix use-after-free in ctnetlink_dump_exp_ct()\n\nctnetlink_dump_exp_ct() stores a conntrack pointer in cb-\u0026gt;data for the\nnetlink dump callback ctnetlink_exp_ct_dump_table(), but drops the\nconntrack reference immediately after netlink_dump_start(). When the\ndump spans multiple rounds, the second recvmsg() triggers the dump\ncallback which dereferences the now-freed conntrack via nfct_help(ct),\nleading to a use-after-free on ct-\u0026gt;ext.\n\nThe bug is that the netlink_dump_control has no .start or .done\ncallbacks to manage the conntrack reference across dump rounds. Other\ndump functions in the same file (e.g. ctnetlink_get_conntrack) properly\nuse .start/.done callbacks for this purpose.\n\nFix this by adding .start and .done callbacks that hold and release the\nconntrack reference for the duration of the dump, and move the\nnfct_help() call after the cb-\u0026gt;args[0] early-return check in the dump\ncallback to avoid dereferencing ct-\u0026gt;ext unnecessarily.\n\n BUG: KASAN: slab-use-after-free in ctnetlink_exp_ct_dump_table+0x4f/0x2e0\n Read of size 8 at addr ffff88810597ebf0 by task ctnetlink_poc/133\n\n CPU: 1 UID: 0 PID: 133 Comm: ctnetlink_poc Not tainted 7.0.0-rc2+ #3 PREEMPTLAZY\n Call Trace:\n \u0026lt;TASK\u0026gt;\n ctnetlink_exp_ct_dump_table+0x4f/0x2e0\n netlink_dump+0x333/0x880\n netlink_recvmsg+0x3e2/0x4b0\n ? aa_sk_perm+0x184/0x450\n sock_recvmsg+0xde/0xf0\n\n Allocated by task 133:\n kmem_cache_alloc_noprof+0x134/0x440\n __nf_conntrack_alloc+0xa8/0x2b0\n ctnetlink_create_conntrack+0xa1/0x900\n ctnetlink_new_conntrack+0x3cf/0x7d0\n nfnetlink_rcv_msg+0x48e/0x510\n netlink_rcv_skb+0xc9/0x1f0\n nfnetlink_rcv+0xdb/0x220\n netlink_unicast+0x3ec/0x590\n netlink_sendmsg+0x397/0x690\n __sys_sendmsg+0xf4/0x180\n\n Freed by task 0:\n slab_free_after_rcu_debug+0xad/0x1e0\n rcu_core+0x5c3/0x9c0(CVE-2026-23458)\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\nspi: fix use-after-free on controller registration failure\n\nMake sure to deregister from driver core also in the unlikely event that\nper-cpu statistics allocation fails during controller registration to\navoid use-after-free (of driver resources) and unclocked register\naccesses.(CVE-2026-31389)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: avoid overflows in ip6_datagram_send_ctl()\n\nYiming Qian reported :\n\u0026lt;quote\u0026gt;\n I believe I found a locally triggerable kernel bug in the IPv6 sendmsg\n ancillary-data path that can panic the kernel via `skb_under_panic()`\n (local DoS).\n\n The core issue is a mismatch between:\n\n - a 16-bit length accumulator (`struct ipv6_txoptions::opt_flen`, type\n `__u16`) and\n - a pointer to the *last* provided destination-options header (`opt-\u0026gt;dst1opt`)\n\n when multiple `IPV6_DSTOPTS` control messages (cmsgs) are provided.\n\n - `include/net/ipv6.h`:\n - `struct ipv6_txoptions::opt_flen` is `__u16` (wrap possible).\n (lines 291-307, especially 298)\n - `net/ipv6/datagram.c:ip6_datagram_send_ctl()`:\n - Accepts repeated `IPV6_DSTOPTS` and accumulates into `opt_flen`\n without rejecting duplicates. (lines 909-933)\n - `net/ipv6/ip6_output.c:__ip6_append_data()`:\n - Uses `opt-\u0026gt;opt_flen + opt-\u0026gt;opt_nflen` to compute header\n sizes/headroom decisions. (lines 1448-1466, especially 1463-1465)\n - `net/ipv6/ip6_output.c:__ip6_make_skb()`:\n - Calls `ipv6_push_frag_opts()` if `opt-\u0026gt;opt_flen` is non-zero.\n (lines 1930-1934)\n - `net/ipv6/exthdrs.c:ipv6_push_frag_opts()` / `ipv6_push_exthdr()`:\n - Push size comes from `ipv6_optlen(opt-\u0026gt;dst1opt)` (based on the\n pointed-to header). (lines 1179-1185 and 1206-1211)\n\n 1. `opt_flen` is a 16-bit accumulator:\n\n - `include/net/ipv6.h:298` defines `__u16 opt_flen; /* after fragment hdr */`.\n\n 2. `ip6_datagram_send_ctl()` accepts *repeated* `IPV6_DSTOPTS` cmsgs\n and increments `opt_flen` each time:\n\n - In `net/ipv6/datagram.c:909-933`, for `IPV6_DSTOPTS`:\n - It computes `len = ((hdr-\u0026gt;hdrlen + 1) \u0026lt;\u0026lt; 3);`\n - It checks `CAP_NET_RAW` using `ns_capable(net-\u0026gt;user_ns,\n CAP_NET_RAW)`. (line 922)\n - Then it does:\n - `opt-\u0026gt;opt_flen += len;` (line 927)\n - `opt-\u0026gt;dst1opt = hdr;` (line 928)\n\n There is no duplicate rejection here (unlike the legacy\n `IPV6_2292DSTOPTS` path which rejects duplicates at\n `net/ipv6/datagram.c:901-904`).\n\n If enough large `IPV6_DSTOPTS` cmsgs are provided, `opt_flen` wraps\n while `dst1opt` still points to a large (2048-byte)\n destination-options header.\n\n In the attached PoC (`poc.c`):\n\n - 32 cmsgs with `hdrlen=255` =\u0026gt; `len = (255+1)*8 = 2048`\n - 1 cmsg with `hdrlen=0` =\u0026gt; `len = 8`\n - Total increment: `32*2048 + 8 = 65544`, so `(__u16)opt_flen == 8`\n - The last cmsg is 2048 bytes, so `dst1opt` points to a 2048-byte header.\n\n 3. The transmit path sizes headers using the wrapped `opt_flen`:\n\n- In `net/ipv6/ip6_output.c:1463-1465`:\n - `headersize = sizeof(struct ipv6hdr) + (opt ? opt-\u0026gt;opt_flen +\n opt-\u0026gt;opt_nflen : 0) + ...;`\n\n With wrapped `opt_flen`, `headersize`/headroom decisions underestimate\n what will be pushed later.\n\n 4. When building the final skb, the actual push length comes from\n `dst1opt` and is not limited by wrapped `opt_flen`:\n\n - In `net/ipv6/ip6_output.c:1930-1934`:\n - `if (opt-\u0026gt;opt_flen) proto = ipv6_push_frag_opts(skb, opt, proto);`\n - In `net/ipv6/exthdrs.c:1206-1211`, `ipv6_push_frag_opts()` pushes\n `dst1opt` via `ipv6_push_exthdr()`.\n - In `net/ipv6/exthdrs.c:1179-1184`, `ipv6_push_exthdr()` does:\n - `skb_push(skb, ipv6_optlen(opt));`\n - `memcpy(h, opt, ipv6_optlen(opt));`\n\n With insufficient headroom, `skb_push()` underflows and triggers\n `skb_under_panic()` -\u0026gt; `BUG()`:\n\n - `net/core/skbuff.c:2669-2675` (`skb_push()` calls `skb_under_panic()`)\n - `net/core/skbuff.c:207-214` (`skb_panic()` ends in `BUG()`)\n\n - The `IPV6_DSTOPTS` cmsg path requires `CAP_NET_RAW` in the target\n netns user namespace (`ns_capable(net-\u0026gt;user_ns, CAP_NET_RAW)`).\n - Root (or any task with `CAP_NET_RAW`) can trigger this without user\n namespaces.\n - An unprivileged `uid=1000` user can trigger this if unprivileged\n user namespaces are enabled and it can create a userns+netns to obtain\n namespaced `CAP_NET_RAW` (the attached PoC does this).\n\n - Local denial of service: kernel BUG/panic (system crash).\n -\n---truncated---(CVE-2026-31415)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nfnetlink_log: account for netlink header size\n\nThis is a followup to an old bug fix: NLMSG_DONE needs to account\nfor the netlink header size, not just the attribute size.\n\nThis can result in a WARN splat + drop of the netlink message,\nbut other than this there are no ill effects.(CVE-2026-31416)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_conntrack_sip: fix use of uninitialized rtp_addr in process_sdp\n\nprocess_sdp() declares union nf_inet_addr rtp_addr on the stack and\npasses it to the nf_nat_sip sdp_session hook after walking the SDP\nmedia descriptions. However rtp_addr is only initialized inside the\nmedia loop when a recognized media type with a non-zero port is found.\n\nIf the SDP body contains no m= lines, only inactive media sections\n(m=audio 0 ...) or only unrecognized media types, rtp_addr is never\nassigned. Despite that, the function still calls hooks-\u0026gt;sdp_session()\nwith \u0026amp;rtp_addr, causing nf_nat_sdp_session() to format the stale stack\nvalue as an IP address and rewrite the SDP session owner and connection\nlines with it.\n\nWith CONFIG_INIT_STACK_ALL_ZERO (default on most distributions) this\nresults in the session-level o= and c= addresses being rewritten to\n0.0.0.0 for inactive SDP sessions. Without stack auto-init the\nrewritten address is whatever happened to be on the stack.\n\nFix this by pre-initializing rtp_addr from the session-level connection\naddress (caddr) when available, and tracking via a have_rtp_addr flag\nwhether any valid address was established. Skip the sdp_session hook\nentirely when no valid address exists.(CVE-2026-31427)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nfnetlink_log: fix uninitialized padding leak in NFULA_PAYLOAD\n\n__build_packet_message() manually constructs the NFULA_PAYLOAD netlink\nattribute using skb_put() and skb_copy_bits(), bypassing the standard\nnla_reserve()/nla_put() helpers. While nla_total_size(data_len) bytes\nare allocated (including NLA alignment padding), only data_len bytes\nof actual packet data are copied. The trailing nla_padlen(data_len)\nbytes (1-3 when data_len is not 4-byte aligned) are never initialized,\nleaking stale heap contents to userspace via the NFLOG netlink socket.\n\nReplace the manual attribute construction with nla_reserve(), which\nhandles the tailroom check, header setup, and padding zeroing via\n__nla_reserve(). The subsequent skb_copy_bits() fills in the payload\ndata on top of the properly initialized attribute.(CVE-2026-31428)\n\nIn the Linux kernel, the following vulnerability has been resolved:\\n\\ncrypto: algif_aead - Revert to operating out-of-place\\n\\nThis mostly reverts commit 72548b093ee3 except for the copying of the associated data.\\n\\nThere is no benefit in operating in-place in algif_aead since the source and destination come from different mappings. Get rid of all the complexity added for in-place operation and just copy the AD directly.(CVE-2026-31431)",
"id": "OESA-2026-2176",
"modified": "2026-08-06T11:11:09Z",
"published": "2026-05-03T11:11:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-2176"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-27558"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71089"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23096"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23378"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23398"
},
{
"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-23442"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23447"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23449"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23452"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23455"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23456"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23457"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23458"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23475"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31389"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31415"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31416"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31427"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31428"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31431"
}
],
"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:N",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2025-27558",
"CVE-2025-71089",
"CVE-2026-23096",
"CVE-2026-23378",
"CVE-2026-23398",
"CVE-2026-23406",
"CVE-2026-23407",
"CVE-2026-23442",
"CVE-2026-23447",
"CVE-2026-23449",
"CVE-2026-23452",
"CVE-2026-23455",
"CVE-2026-23456",
"CVE-2026-23457",
"CVE-2026-23458",
"CVE-2026-23475",
"CVE-2026-31389",
"CVE-2026-31415",
"CVE-2026-31416",
"CVE-2026-31427",
"CVE-2026-31428",
"CVE-2026-31431"
]
}
OESA-2026-2232 (CVE-2025-71089)
Vulnerability from osv_openeuler – Published: 2026-05-09 11:11 – Updated: 2026-08-06 11:11 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, a security vulnerability exists in the IOMMU Shared Virtual Addressing (SVA) feature. On x86 architecture when CONFIG_X86 is set, IOMMU hardware caches kernel page table entries. Due to the lack of notification mechanism for kernel page table changes, when kernel page table pages are freed and reused, the IOMMU may retain stale entries, leading to Use-After-Free (UAF) and Write-After-Free (WAF) conditions. This can be exploited to cause arbitrary physical memory DMA access or privilege escalation.(CVE-2025-71089)
In the Linux kernel, the following vulnerability has been resolved:
ipv6: add NULL checks for idev in SRv6 paths
__in6_dev_get() can return NULL when the device has no IPv6 configuration (e.g. MTU < IPV6_MIN_MTU or after NETDEV_UNREGISTER).
Add NULL checks for idev returned by __in6_dev_get() in both seg6_hmac_validate_skb() and ipv6_srh_rcv() to prevent potential NULL pointer dereferences.(CVE-2026-23442)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: conntrack: add missing netlink policy validations
Hyunwoo Kim reports out-of-bounds access in sctp and ctnetlink.
These attributes are used by the kernel without any validation. Extend the netlink policies accordingly.
Quoting the reporter: nlattr_to_sctp() assigns the user-supplied CTA_PROTOINFO_SCTP_STATE value directly to ct->proto.sctp.state without checking that it is within the valid range. [..]
and: ... with exp->dir = 100, the access at ct->master->tuplehash[100] reads 5600 bytes past the start of a 320-byte nf_conn object, causing a slab-out-of-bounds read confirmed by UBSAN.(CVE-2026-31407)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: ipset: drop logically empty buckets in mtype_del
mtype_del() counts empty slots below n->pos in k, but it only drops the bucket when both n->pos and k are zero. This misses buckets whose live entries have all been removed while n->pos still points past deleted slots.
Treat a bucket as empty when all positions below n->pos are unused and release it directly instead of shrinking it further.(CVE-2026-31418)
In the Linux kernel, the following vulnerability has been resolved:
bridge: mrp: reject zero test interval to avoid OOM panic
br_mrp_start_test() and br_mrp_start_in_test() accept the user-supplied interval value from netlink without validation. When interval is 0, usecs_to_jiffies(0) yields 0, causing the delayed work (br_mrp_test_work_expired / br_mrp_in_test_work_expired) to reschedule itself with zero delay. This creates a tight loop on system_percpu_wq that allocates and transmits MRP test frames at maximum rate, exhausting all system memory and causing a kernel panic via OOM deadlock.
The same zero-interval issue applies to br_mrp_start_in_test_parse() for interconnect test frames.
Use NLA_POLICY_MIN(NLA_U32, 1) in the nla_policy tables for both IFLA_BRIDGE_MRP_START_TEST_INTERVAL and IFLA_BRIDGE_MRP_START_IN_TEST_INTERVAL, so zero is rejected at the netlink attribute parsing layer before the value ever reaches the workqueue scheduling code. This is consistent with how other bridge subsystems (br_fdb, br_mst) enforce range constraints on netlink attributes.(CVE-2026-31420)
In the Linux kernel, the following vulnerability has been resolved:
net/sched: sch_hfsc: fix divide-by-zero in rtsc_min()
m2sm() converts a u32 slope to a u64 scaled value. For large inputs
(e.g. m1=4000000000), the result can reach 2^32. rtsc_min() stores
the difference of two such u64 values in a u32 variable dsm and
uses it as a divisor. When the difference is exactly 2^32 the
truncation yields zero, causing a divide-by-zero oops in the
concave-curve intersection path:
Oops: divide error: 0000 RIP: 0010:rtsc_min (net/sched/sch_hfsc.c:601) Call Trace: init_ed (net/sched/sch_hfsc.c:629) hfsc_enqueue (net/sched/sch_hfsc.c:1569) [...]
Widen dsm to u64 and replace do_div() with div64_u64() so the full
difference is preserved.(CVE-2026-31423)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: x_tables: restrict xt_check_match/xt_check_target extensions for NFPROTO_ARP
Weiming Shi says:
xt_match and xt_target structs registered with NFPROTO_UNSPEC can be loaded by any protocol family through nft_compat. When such a match/target sets .hooks to restrict which hooks it may run on, the bitmask uses NF_INET_ constants. This is only correct for families whose hook layout matches NF_INET_: IPv4, IPv6, INET, and bridge all share the same five hooks (PRE_ROUTING ... POST_ROUTING).
ARP only has three hooks (IN=0, OUT=1, FORWARD=2) with different semantics. Because NF_ARP_OUT == 1 == NF_INET_LOCAL_IN, the .hooks validation silently passes for the wrong reasons, allowing matches to run on ARP chains where the hook assumptions (e.g. state->in being set on input hooks) do not hold. This leads to NULL pointer dereferences; xt_devgroup is one concrete example:
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000044: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000220-0x0000000000000227] RIP: 0010:devgroup_mt+0xff/0x350 Call Trace: <TASK> nft_match_eval (net/netfilter/nft_compat.c:407) nft_do_chain (net/netfilter/nf_tables_core.c:285) nft_do_chain_arp (net/netfilter/nft_chain_filter.c:61) nf_hook_slow (net/netfilter/core.c:623) arp_xmit (net/ipv4/arp.c:666) </TASK> Kernel panic - not syncing: Fatal exception in interrupt
Fix it by restricting arptables to NFPROTO_ARP extensions only. Note that arptables-legacy only supports:
- arpt_CLASSIFY
- arpt_mangle
- arpt_MARK
that provide explicit NFPROTO_ARP match/target declarations.(CVE-2026-31424)
In the Linux kernel, the following vulnerability has been resolved:
ALSA: ctxfi: Limit PTP to a single page
Commit 391e69143d0a increased CT_PTP_NUM from 1 to 4 to support 256 playback streams, but the additional pages are not used by the card correctly. The CT20K2 hardware already has multiple VMEM_PTPAL registers, but using them separately would require refactoring the entire virtual memory allocation logic.
ct_vm_map() always uses PTEs in vm->ptp[0].area regardless of CT_PTP_NUM. On AMD64 systems, a single PTP covers 512 PTEs (2M). When aggregate memory allocations exceed this limit, ct_vm_map() tries to access beyond the allocated space and causes a page fault:
BUG: unable to handle page fault for address: ffffd4ae8a10a000 Oops: Oops: 0002 [#1] SMP PTI RIP: 0010:ct_vm_map+0x17c/0x280 [snd_ctxfi] Call Trace: atc_pcm_playback_prepare+0x225/0x3b0 ct_pcm_playback_prepare+0x38/0x60 snd_pcm_do_prepare+0x2f/0x50 snd_pcm_action_single+0x36/0x90 snd_pcm_action_nonatomic+0xbf/0xd0 snd_pcm_ioctl+0x28/0x40 __x64_sys_ioctl+0x97/0xe0 do_syscall_64+0x81/0x610 entry_SYSCALL_64_after_hwframe+0x76/0x7e
Revert CT_PTP_NUM to 1. The 256 SRC_RESOURCE_NUM and playback_count remain unchanged.(CVE-2026-31602)
In the Linux kernel, the following vulnerability has been resolved:
net: ipv6: flowlabel: defer exclusive option free until RCU teardown
ip6fl_seq_show() walks the global flowlabel hash under the seq-file
RCU read-side lock and prints fl->opt->opt_nflen when an option block
is present.
Exclusive flowlabels currently free fl->opt as soon as fl->users
drops to zero in fl_release(). However, the surrounding
struct ip6_flowlabel remains visible in the global hash table until
later garbage collection removes it and fl_free_rcu() finally tears it
down.
A concurrent /proc/net/ip6_flowlabel reader can therefore race that
early kfree() and dereference freed option state, triggering a crash
in ip6fl_seq_show().
Fix this by keeping fl->opt alive until fl_free_rcu(). That matches
the lifetime already required for the enclosing flowlabel while readers
can still reach it under RCU.(CVE-2026-31680)
In the Linux kernel, the following vulnerability has been resolved:
perf/x86: Fix potential bad container_of in intel_pmu_hw_config
Auto counter reload may have a group of events with software events present within it. The software event PMU isn't the x86_hybrid_pmu and a container_of operation in intel_pmu_set_acr_caused_constr (via the hybrid helper) could cause out of bound memory reads. Avoid this by guarding the call to intel_pmu_set_acr_caused_constr with an is_x86_event check.(CVE-2026-31782)
| URL | Type | ||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-6.6.0-145.0.9.140.oe2403sp3.aarch64.rpm",
"bpftool-debuginfo-6.6.0-145.0.9.140.oe2403sp3.aarch64.rpm",
"kernel-6.6.0-145.0.9.140.oe2403sp3.aarch64.rpm",
"kernel-debuginfo-6.6.0-145.0.9.140.oe2403sp3.aarch64.rpm",
"kernel-debugsource-6.6.0-145.0.9.140.oe2403sp3.aarch64.rpm",
"kernel-devel-6.6.0-145.0.9.140.oe2403sp3.aarch64.rpm",
"kernel-extra-modules-6.6.0-145.0.9.140.oe2403sp3.aarch64.rpm",
"kernel-headers-6.6.0-145.0.9.140.oe2403sp3.aarch64.rpm",
"kernel-source-6.6.0-145.0.9.140.oe2403sp3.aarch64.rpm",
"kernel-tools-6.6.0-145.0.9.140.oe2403sp3.aarch64.rpm",
"kernel-tools-debuginfo-6.6.0-145.0.9.140.oe2403sp3.aarch64.rpm",
"kernel-tools-devel-6.6.0-145.0.9.140.oe2403sp3.aarch64.rpm",
"perf-6.6.0-145.0.9.140.oe2403sp3.aarch64.rpm",
"perf-debuginfo-6.6.0-145.0.9.140.oe2403sp3.aarch64.rpm",
"python3-perf-6.6.0-145.0.9.140.oe2403sp3.aarch64.rpm",
"python3-perf-debuginfo-6.6.0-145.0.9.140.oe2403sp3.aarch64.rpm"
],
"src": [
"kernel-6.6.0-145.0.9.140.oe2403sp3.src.rpm"
],
"x86_64": [
"bpftool-6.6.0-145.0.9.140.oe2403sp3.x86_64.rpm",
"bpftool-debuginfo-6.6.0-145.0.9.140.oe2403sp3.x86_64.rpm",
"kernel-6.6.0-145.0.9.140.oe2403sp3.x86_64.rpm",
"kernel-debuginfo-6.6.0-145.0.9.140.oe2403sp3.x86_64.rpm",
"kernel-debugsource-6.6.0-145.0.9.140.oe2403sp3.x86_64.rpm",
"kernel-devel-6.6.0-145.0.9.140.oe2403sp3.x86_64.rpm",
"kernel-extra-modules-6.6.0-145.0.9.140.oe2403sp3.x86_64.rpm",
"kernel-headers-6.6.0-145.0.9.140.oe2403sp3.x86_64.rpm",
"kernel-source-6.6.0-145.0.9.140.oe2403sp3.x86_64.rpm",
"kernel-tools-6.6.0-145.0.9.140.oe2403sp3.x86_64.rpm",
"kernel-tools-debuginfo-6.6.0-145.0.9.140.oe2403sp3.x86_64.rpm",
"kernel-tools-devel-6.6.0-145.0.9.140.oe2403sp3.x86_64.rpm",
"perf-6.6.0-145.0.9.140.oe2403sp3.x86_64.rpm",
"perf-debuginfo-6.6.0-145.0.9.140.oe2403sp3.x86_64.rpm",
"python3-perf-6.6.0-145.0.9.140.oe2403sp3.x86_64.rpm",
"python3-perf-debuginfo-6.6.0-145.0.9.140.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.0.9.140.oe2403sp3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, a security vulnerability exists in the IOMMU Shared Virtual Addressing (SVA) feature. On x86 architecture when CONFIG_X86 is set, IOMMU hardware caches kernel page table entries. Due to the lack of notification mechanism for kernel page table changes, when kernel page table pages are freed and reused, the IOMMU may retain stale entries, leading to Use-After-Free (UAF) and Write-After-Free (WAF) conditions. This can be exploited to cause arbitrary physical memory DMA access or privilege escalation.(CVE-2025-71089)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: add NULL checks for idev in SRv6 paths\n\n__in6_dev_get() can return NULL when the device has no IPv6 configuration\n(e.g. MTU \u0026lt; IPV6_MIN_MTU or after NETDEV_UNREGISTER).\n\nAdd NULL checks for idev returned by __in6_dev_get() in both\nseg6_hmac_validate_skb() and ipv6_srh_rcv() to prevent potential NULL\npointer dereferences.(CVE-2026-23442)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: conntrack: add missing netlink policy validations\n\nHyunwoo Kim reports out-of-bounds access in sctp and ctnetlink.\n\nThese attributes are used by the kernel without any validation.\nExtend the netlink policies accordingly.\n\nQuoting the reporter:\n nlattr_to_sctp() assigns the user-supplied CTA_PROTOINFO_SCTP_STATE\n value directly to ct-\u0026gt;proto.sctp.state without checking that it is\n within the valid range. [..]\n\n and: ... with exp-\u0026gt;dir = 100, the access at\n ct-\u0026gt;master-\u0026gt;tuplehash[100] reads 5600 bytes past the start of a\n 320-byte nf_conn object, causing a slab-out-of-bounds read confirmed by\n UBSAN.(CVE-2026-31407)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: ipset: drop logically empty buckets in mtype_del\n\nmtype_del() counts empty slots below n-\u0026gt;pos in k, but it only drops the\nbucket when both n-\u0026gt;pos and k are zero. This misses buckets whose live\nentries have all been removed while n-\u0026gt;pos still points past deleted slots.\n\nTreat a bucket as empty when all positions below n-\u0026gt;pos are unused and\nrelease it directly instead of shrinking it further.(CVE-2026-31418)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbridge: mrp: reject zero test interval to avoid OOM panic\n\nbr_mrp_start_test() and br_mrp_start_in_test() accept the user-supplied\ninterval value from netlink without validation. When interval is 0,\nusecs_to_jiffies(0) yields 0, causing the delayed work\n(br_mrp_test_work_expired / br_mrp_in_test_work_expired) to reschedule\nitself with zero delay. This creates a tight loop on system_percpu_wq\nthat allocates and transmits MRP test frames at maximum rate, exhausting\nall system memory and causing a kernel panic via OOM deadlock.\n\nThe same zero-interval issue applies to br_mrp_start_in_test_parse()\nfor interconnect test frames.\n\nUse NLA_POLICY_MIN(NLA_U32, 1) in the nla_policy tables for both\nIFLA_BRIDGE_MRP_START_TEST_INTERVAL and\nIFLA_BRIDGE_MRP_START_IN_TEST_INTERVAL, so zero is rejected at the\nnetlink attribute parsing layer before the value ever reaches the\nworkqueue scheduling code. This is consistent with how other bridge\nsubsystems (br_fdb, br_mst) enforce range constraints on netlink\nattributes.(CVE-2026-31420)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: sch_hfsc: fix divide-by-zero in rtsc_min()\n\nm2sm() converts a u32 slope to a u64 scaled value. For large inputs\n(e.g. m1=4000000000), the result can reach 2^32. rtsc_min() stores\nthe difference of two such u64 values in a u32 variable `dsm` and\nuses it as a divisor. When the difference is exactly 2^32 the\ntruncation yields zero, causing a divide-by-zero oops in the\nconcave-curve intersection path:\n\n Oops: divide error: 0000\n RIP: 0010:rtsc_min (net/sched/sch_hfsc.c:601)\n Call Trace:\n init_ed (net/sched/sch_hfsc.c:629)\n hfsc_enqueue (net/sched/sch_hfsc.c:1569)\n [...]\n\nWiden `dsm` to u64 and replace do_div() with div64_u64() so the full\ndifference is preserved.(CVE-2026-31423)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: x_tables: restrict xt_check_match/xt_check_target extensions for NFPROTO_ARP\n\nWeiming Shi says:\n\nxt_match and xt_target structs registered with NFPROTO_UNSPEC can be\nloaded by any protocol family through nft_compat. When such a\nmatch/target sets .hooks to restrict which hooks it may run on, the\nbitmask uses NF_INET_* constants. This is only correct for families\nwhose hook layout matches NF_INET_*: IPv4, IPv6, INET, and bridge\nall share the same five hooks (PRE_ROUTING ... POST_ROUTING).\n\nARP only has three hooks (IN=0, OUT=1, FORWARD=2) with different\nsemantics. Because NF_ARP_OUT == 1 == NF_INET_LOCAL_IN, the .hooks\nvalidation silently passes for the wrong reasons, allowing matches to\nrun on ARP chains where the hook assumptions (e.g. state-\u0026gt;in being\nset on input hooks) do not hold. This leads to NULL pointer\ndereferences; xt_devgroup is one concrete example:\n\n Oops: general protection fault, probably for non-canonical address 0xdffffc0000000044: 0000 [#1] SMP KASAN NOPTI\n KASAN: null-ptr-deref in range [0x0000000000000220-0x0000000000000227]\n RIP: 0010:devgroup_mt+0xff/0x350\n Call Trace:\n \u0026lt;TASK\u0026gt;\n nft_match_eval (net/netfilter/nft_compat.c:407)\n nft_do_chain (net/netfilter/nf_tables_core.c:285)\n nft_do_chain_arp (net/netfilter/nft_chain_filter.c:61)\n nf_hook_slow (net/netfilter/core.c:623)\n arp_xmit (net/ipv4/arp.c:666)\n \u0026lt;/TASK\u0026gt;\n Kernel panic - not syncing: Fatal exception in interrupt\n\nFix it by restricting arptables to NFPROTO_ARP extensions only.\nNote that arptables-legacy only supports:\n\n- arpt_CLASSIFY\n- arpt_mangle\n- arpt_MARK\n\nthat provide explicit NFPROTO_ARP match/target declarations.(CVE-2026-31424)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nALSA: ctxfi: Limit PTP to a single page\n\nCommit 391e69143d0a increased CT_PTP_NUM from 1 to 4 to support 256\nplayback streams, but the additional pages are not used by the card\ncorrectly. The CT20K2 hardware already has multiple VMEM_PTPAL\nregisters, but using them separately would require refactoring the\nentire virtual memory allocation logic.\n\nct_vm_map() always uses PTEs in vm-\u0026gt;ptp[0].area regardless of\nCT_PTP_NUM. On AMD64 systems, a single PTP covers 512 PTEs (2M). When\naggregate memory allocations exceed this limit, ct_vm_map() tries to\naccess beyond the allocated space and causes a page fault:\n\n BUG: unable to handle page fault for address: ffffd4ae8a10a000\n Oops: Oops: 0002 [#1] SMP PTI\n RIP: 0010:ct_vm_map+0x17c/0x280 [snd_ctxfi]\n Call Trace:\n atc_pcm_playback_prepare+0x225/0x3b0\n ct_pcm_playback_prepare+0x38/0x60\n snd_pcm_do_prepare+0x2f/0x50\n snd_pcm_action_single+0x36/0x90\n snd_pcm_action_nonatomic+0xbf/0xd0\n snd_pcm_ioctl+0x28/0x40\n __x64_sys_ioctl+0x97/0xe0\n do_syscall_64+0x81/0x610\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nRevert CT_PTP_NUM to 1. The 256 SRC_RESOURCE_NUM and playback_count\nremain unchanged.(CVE-2026-31602)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: ipv6: flowlabel: defer exclusive option free until RCU teardown\n\n`ip6fl_seq_show()` walks the global flowlabel hash under the seq-file\nRCU read-side lock and prints `fl-\u0026gt;opt-\u0026gt;opt_nflen` when an option block\nis present.\n\nExclusive flowlabels currently free `fl-\u0026gt;opt` as soon as `fl-\u0026gt;users`\ndrops to zero in `fl_release()`. However, the surrounding\n`struct ip6_flowlabel` remains visible in the global hash table until\nlater garbage collection removes it and `fl_free_rcu()` finally tears it\ndown.\n\nA concurrent `/proc/net/ip6_flowlabel` reader can therefore race that\nearly `kfree()` and dereference freed option state, triggering a crash\nin `ip6fl_seq_show()`.\n\nFix this by keeping `fl-\u0026gt;opt` alive until `fl_free_rcu()`. That matches\nthe lifetime already required for the enclosing flowlabel while readers\ncan still reach it under RCU.(CVE-2026-31680)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nperf/x86: Fix potential bad container_of in intel_pmu_hw_config\n\nAuto counter reload may have a group of events with software events\npresent within it. The software event PMU isn\u0026apos;t the x86_hybrid_pmu and\na container_of operation in intel_pmu_set_acr_caused_constr (via the\nhybrid helper) could cause out of bound memory reads. Avoid this by\nguarding the call to intel_pmu_set_acr_caused_constr with an\nis_x86_event check.(CVE-2026-31782)",
"id": "OESA-2026-2232",
"modified": "2026-08-06T11:11:12Z",
"published": "2026-05-09T11:11:12Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-2232"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71089"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23442"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31407"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31418"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31420"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31423"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31424"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31602"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31680"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31782"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2025-71089",
"CVE-2026-23442",
"CVE-2026-31407",
"CVE-2026-31418",
"CVE-2026-31420",
"CVE-2026-31423",
"CVE-2026-31424",
"CVE-2026-31602",
"CVE-2026-31680",
"CVE-2026-31782"
]
}
OPENSUSE-SU-2026:20826-1
Vulnerability from csaf_opensuse - Published: 2026-05-28 12:58 - Updated: 2026-09-17 17:33RHSA-2026:64775
Vulnerability from csaf_opensuse - Published: 2026-09-08 09:06 - Updated: 2026-09-17 12:42A flaw was found in the Linux kernel. Missing null pointer checks in the IPv6 Segment Routing (SRv6) implementation, specifically within the `seg6_hmac_validate_skb()` and `ipv6_srh_rcv()` functions, can occur when an IPv6 device lacks proper configuration. This oversight may allow an attacker to trigger a null pointer dereference, potentially leading to a system crash and a Denial of Service (DoS).
RLSA-2026:64775 (CVE-2025-38004)
Vulnerability from osv_rocky – Published: 2026-09-09 12:09 – Updated: 2026-09-20 06:13 – Source websiteThe kernel packages contain the Linux kernel, the core of any Linux operating system.
Security Fix(es):
-
kernel: can: bcm: add locking for bcm_op runtime updates (CVE-2025-38004)
-
kernel: ipv6: add NULL checks for idev in SRv6 paths (CVE-2026-23442)
-
kernel: udp: Fix wildcard bind conflict check when using hash2 (CVE-2026-31503)
-
kernel: ipv6: prevent possible UaF in addrconf_permanent_addr() (CVE-2026-43339)
-
kernel: tcp: call sk_data_ready() after listener migration (CVE-2026-46015)
-
kernel: inet: RAW sockets using IPPROTO_RAW MUST drop incoming ICMP (CVE-2026-46266)
-
kernel: flow_dissector: do not dissect PPPoE PFC frames (CVE-2026-46306)
-
kernel: io_uring/poll: fix signed comparison in io_poll_get_ownership() (CVE-2026-52933)
-
kernel: ppp: require CAP_NET_ADMIN in target netns for unattached ioctls (CVE-2026-53075)
-
kernel: KVM: arm64: Take the SRCU lock for page table walks in fault injection and AT emulation (CVE-2026-53277)
-
kernel: ipv6: sit: reload inner IPv6 header after GSO offloads (CVE-2026-53228)
-
kernel: net: add pskb_may_pull() to skb_gro_receive_list() (CVE-2026-53235)
-
kernel: net: guard timestamp cmsgs to real error queue skbs (CVE-2026-53223)
-
kernel: ipv6: mcast: Fix use-after-free when processing MLD queries (CVE-2026-53275)
-
kernel: ipv6: anycast: insert aca into global hash under idev->lock (CVE-2026-53259)
-
kernel: ipv4: free net->ipv4.sysctl_local_reserved_ports after unregister_net_sysctl_table() (CVE-2026-64002)
-
kernel: vxlan: do not reuse cached ip_hdr() value after skb_tunnel_check_pmtu() (CVE-2026-63993)
-
kernel: fuse: clear intr_entry in fuse_resend and fuse_remove_pending_req (CVE-2026-64265)
-
kernel: nvmet-auth: validate reply message payload bounds against transfer length (CVE-2026-64319)
-
kernel: KVM: arm64: Bound used_lrs when flushing the pKVM hyp vCPU (CVE-2026-64287)
-
kernel: rhashtable: clear stale iter->p on table restart (CVE-2026-64563)
-
kernel: smb: client: fix double-free in SMB2_close() replay (CVE-2026-64597)
Bug Fix(es) and Enhancement(s):
- Customer needs "netfilter: nfnetlink_queue: optimize verdict lookup with hash table" patch [Rocky Linux 10.2] (JIRA:Rocky Linux-132852)
For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.
| URL | Type | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"package": {
"ecosystem": "Rocky Linux:10",
"name": "kernel",
"purl": "pkg:rpm/rocky-linux/kernel?distro=rocky-linux-10\u0026epoch=0"
},
"ranges": [
{
"database_specific": {
"yum_repository": "BaseOS"
},
"events": [
{
"introduced": "0"
},
{
"fixed": "0:6.12.0-211.52.1.el10_2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"credits": [
{
"name": "Rocky Enterprise Software Foundation"
},
{
"name": "Red Hat"
}
],
"database_specific": {
"license": "CC-BY-4.0",
"license_url": "https://creativecommons.org/licenses/by/4.0/",
"source_advisory": "RHSA-2026:64775"
},
"details": "The kernel packages contain the Linux kernel, the core of any Linux operating system.\n\nSecurity Fix(es):\n\n* kernel: can: bcm: add locking for bcm_op runtime updates (CVE-2025-38004)\n\n* kernel: ipv6: add NULL checks for idev in SRv6 paths (CVE-2026-23442)\n\n* kernel: udp: Fix wildcard bind conflict check when using hash2 (CVE-2026-31503)\n\n* kernel: ipv6: prevent possible UaF in addrconf_permanent_addr() (CVE-2026-43339)\n\n* kernel: tcp: call sk_data_ready() after listener migration (CVE-2026-46015)\n\n* kernel: inet: RAW sockets using IPPROTO_RAW MUST drop incoming ICMP (CVE-2026-46266)\n\n* kernel: flow_dissector: do not dissect PPPoE PFC frames (CVE-2026-46306)\n\n* kernel: io_uring/poll: fix signed comparison in io_poll_get_ownership() (CVE-2026-52933)\n\n* kernel: ppp: require CAP_NET_ADMIN in target netns for unattached ioctls (CVE-2026-53075)\n\n* kernel: KVM: arm64: Take the SRCU lock for page table walks in fault injection and AT emulation (CVE-2026-53277)\n\n* kernel: ipv6: sit: reload inner IPv6 header after GSO offloads (CVE-2026-53228)\n\n* kernel: net: add pskb_may_pull() to skb_gro_receive_list() (CVE-2026-53235)\n\n* kernel: net: guard timestamp cmsgs to real error queue skbs (CVE-2026-53223)\n\n* kernel: ipv6: mcast: Fix use-after-free when processing MLD queries (CVE-2026-53275)\n\n* kernel: ipv6: anycast: insert aca into global hash under idev-\u003elock (CVE-2026-53259)\n\n* kernel: ipv4: free net-\u003eipv4.sysctl_local_reserved_ports after unregister_net_sysctl_table() (CVE-2026-64002)\n\n* kernel: vxlan: do not reuse cached ip_hdr() value after skb_tunnel_check_pmtu() (CVE-2026-63993)\n\n* kernel: fuse: clear intr_entry in fuse_resend and fuse_remove_pending_req (CVE-2026-64265)\n\n* kernel: nvmet-auth: validate reply message payload bounds against transfer length (CVE-2026-64319)\n\n* kernel: KVM: arm64: Bound used_lrs when flushing the pKVM hyp vCPU (CVE-2026-64287)\n\n* kernel: rhashtable: clear stale iter-\u003ep on table restart (CVE-2026-64563)\n\n* kernel: smb: client: fix double-free in SMB2_close() replay (CVE-2026-64597)\n\nBug Fix(es) and Enhancement(s):\n\n* Customer needs \"netfilter: nfnetlink_queue: optimize verdict lookup with hash table\" patch [Rocky Linux 10.2] (JIRA:Rocky Linux-132852)\n\nFor more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.",
"id": "RLSA-2026:64775",
"modified": "2026-09-20T06:13:39.624445Z",
"published": "2026-09-09T12:09:16.585859Z",
"references": [
{
"type": "ADVISORY",
"url": "https://errata.rockylinux.org/RLSA-2026:64775"
},
{
"type": "REPORT",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2484456"
},
{
"type": "REPORT",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2370992"
},
{
"type": "REPORT",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2510892"
},
{
"type": "REPORT",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2507041"
},
{
"type": "REPORT",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2460736"
},
{
"type": "REPORT",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2511932"
},
{
"type": "REPORT",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2507096"
},
{
"type": "REPORT",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2492745"
},
{
"type": "REPORT",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2486463"
},
{
"type": "REPORT",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2454807"
},
{
"type": "REPORT",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2492295"
},
{
"type": "REPORT",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2502363"
},
{
"type": "REPORT",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2502369"
},
{
"type": "REPORT",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2492841"
},
{
"type": "REPORT",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2481936"
},
{
"type": "REPORT",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2492725"
},
{
"type": "REPORT",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2492733"
},
{
"type": "REPORT",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2492097"
},
{
"type": "REPORT",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2468102"
},
{
"type": "REPORT",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2492850"
},
{
"type": "REPORT",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2492811"
},
{
"type": "REPORT",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2507129"
},
{
"type": "ADVISORY",
"url": "https://access.redhat.com/errata/RHSA-2026:64775"
}
],
"schema_version": "1.7.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"
}
],
"summary": "Important: kernel security, bug fix, and enhancement update",
"upstream": [
"CVE-2025-38004",
"CVE-2026-23442",
"CVE-2026-31503",
"CVE-2026-43339",
"CVE-2026-46015",
"CVE-2026-46266",
"CVE-2026-46306",
"CVE-2026-52933",
"CVE-2026-53075",
"CVE-2026-53223",
"CVE-2026-53228",
"CVE-2026-53235",
"CVE-2026-53259",
"CVE-2026-53275",
"CVE-2026-53277",
"CVE-2026-63993",
"CVE-2026-64002",
"CVE-2026-64265",
"CVE-2026-64287",
"CVE-2026-64319",
"CVE-2026-64563",
"CVE-2026-64597"
]
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.